Gavin, Spring will of course happily work in conjunction with EJB3: provide access to EJB3 Session Beans or the EJB3 EntityManager, serve as backbone for fine-granular objects behind EJB3 Session Beans facades. It will work with EJB3 just like it currently works with EJB 1.1 or 2.x; additionally, it will explicitly support the EJB3 EntityManager as data access strategy.

There are reasons why Spring does not build on EJB3 as a cornerstone. For example, one of the goals of Spring is to not require JNDI or JTA unless there is an actual need for them: Many web applications and in particular standalone applications simply don’t need a global registry or a distributed transaction coordinator. EJB3, on the other hand, builds on JNDI and JTA as core underlying services.

But that’s not the most important factor. The main reason why Spring can’t fully support EJB3 Session Beans is deployment: EJB JARs? providing a separate class loader? IIOP remoting endpoints for remote Session Beans? remote transaction propagation? remote Stateful Session Beans? Sorry, that’s not what Spring is about. Spring always runs locally within *existing* deployment units and existing class loaders.

Of course Spring will be able to support the EJB3 programming model directly, to some degree: it can auto-detect EJB3 Stateless Session Bean annotations in Spring-defined beans – and apply injection of JNDI objects, transactional proxying, or instance pooling. But everything else is the job of an application server, not of an application framework (or lightweight container).

Spring is essentially a lightweight container for *local* *stateless* POJO service objects within an application, adapting to any environment (whether J2EE or standalone). It provides rich and flexible services for such POJO services, allowing for a variety of definition formats, transaction demarcation styles, etc. And it integrates with whatever persistence strategy you prefer. EJB3’s focus is significantly different.

Finally, Spring is designed to provide the full richness of its services on JDK >= 1.3 and J2EE >= 1.3. Which means that it happily works on the likes of WebSphere 4-6 or WebLogic 7-9, for example – here and now, using the same component model and configuration format as in any other environment, and integrating with the facilities of the particular server. Without conflicting with the EJB 1.1/2.x containers there.

It’s funny that you talk about maintaining existing applications and migration paths. Many Spring applications run on current or old versions of WebSphere and WebLogic, without any hassle. Spring can also be retrofitted into existing applications easily. EJB3, on the other hand, forces users to upgrade to J2EE 1.5 servers – which is distant future for many WebSphere and WebLogic users.

A couple of things:

a) I am not a proponent of ‘JDO vs. Hibernate’. We use Hibernate in my applications, and it is a great solution. I thank you and the team for that.

b) The Spring guys can’t ‘embrace’ EJB 3, since it is a subset of their world, and they don’t have a way to implement it themselves. I am sure they will embrace it in the sense of: supporting it at a source level, and integrating with it (like they do now with EJB 2.x and below).

The solution also allows people a nice migration path from using Spring now, to when EJB 3 comes out and they can drop it in an EJB container.

In fact, if Spring was baked so closely into the appserver then you could choose to be as standard, or NOT standard as you want. If you just want to drop a jar file that has Spring beans and applicationContext*.xmls and it will deploy and expose itself in other ways. Else, you can deploy it as pure EJB components. Or, a mix.

I think that Spring adds a lot to what we get with EJB 3 though (as it stands now). They have a lot of value adds (including AOP support, enhanced configuration, and the stack on top).

Who knows what will come out w/ the final EJB 3 spec though, and I think the community is open.

Dion