I've been drawn back to TSS again. There is an interesting thread where Bill Burke from JBoss-Seam goes head to head with Rod Johnson of Spring. Now it doesn't surprise me that Rod Johnson is a bit of an egocentric jerk - I know someone who worked him for years who told me as much. It was interesting though to see the JBoss guys break their usual aloof pseudo-intellectual demean a: read here.
Both of these frameworks claim to provide a component model for Java objects. So the first thing to clear up is what is a component? Well as far as I can tell, a component is a course grained object that can be bound to other coarse grained objects after compile time. So components are an invention for static OO languages, in dynamic OO, all objects are components.
Right with that out the way (anyone who is still not convinced, I would suggest exploring the runtime differences between a virtual function call as used in C++/Java/C# etc and polymorphic message sends as used in Smalltalk, Phython, Ruby etc), here is why do I believe that EJB's are a flawed component model.
Let’s take a simple example. Component A uses Component B. A configures B and registers a number of callbacks with B so that B can notify A. A is packaged in its own EAR (or 'war' or 'ejb-jar') and so is B. So what is the problem?
Well A must have access to the Interface of B, I will call this B' and B must also have access to the callback interface of A, which I will call A'. So there is a mutual dependency between A' and B'. With the J2EE class loader model, each component has it's own class loader (CL). Class loaders are arranged hierarchically. So the CL for B can be a dependent of the CL for A, or visa-versa, but two class loaders cannot be mutually dependent.
So you cannot have A<-->B relationships between J2EE components. Apparently OSGi is meant to be addressing this, but it seems a pretty fundamental language flaw to me. It will be interesting to see how they plan to get over this one!
Oh, yes I forgot Spring. Well IoC is nothing new. It allows you to separate interface from implementation, deferring binding untill runtime (back to message sends versus virtual function calls again). So again, by default all dynamic OO objects have this property. In Java it can be achieved with the use of an Interface and the reflection API, which is effectively what the Spring bean factory does. Fortunately Spring doesn’t go in for this separate class loader nonsense - so no class loader hell here - but if you choose to package your Spring application into a WAR, then you have no runtime binding of components either, so A<-->B, with Spring becomes AB. So if you want to change implementation to A<--->C at deploy time, where C implements B' you can't.
So it turns out that Spring isn't a component model at all - oh dear!
So neither of these so-called "Component frameworks" can do what Smalltalk did out of the box, over 30 years ago. Maybe they should have discussed this poignant fact on TSS, instead of squabbling like school girls.