Adam Bien's Weblog

Monday Jul 06, 2009

Lean Java EE 6 Without Spring And Spring 3.0 In Java EE 6 World: Summary and Conclusion (eJug Session)

It turned out, that both components models are surprisingly similar. You could migrate an EJB 3.1 based application, almost without any additional effort to Spring (search and replace for annotations). It is even possible to run an EJB 3.1 applications without ANY modification just tweaking Spring a bit. 

Although both technologies are almost identical from the programming model perspective - the philosophy is totally different. Spring "is not just a glue-framework" (Juergen clarified that), rather than complete solution - the full stack. Spring was architected as a layer above the actual application server. The idea: you can upgrade your APIs updating Spring and not touching the application server. This is especially important if you have to use the "heavyweights" application servers (=they come with at least with one DVD to install and the installation takes several hours :-)) without having any control about the version. The Dependency Injection is only a small part of the framework. Spring offers you from DI, over Spring MVC with REST support (similar to JAX-RS) and even monitoring. It actually replaces the most parts of the application servers with own services.

What was also interesting - Spring is exactly NOT Convention Over Configuration. The idea is to configure everything is needed explicitly, without relying on conventions. But you don't have to configure everything over and over again - you can use "Stereotypes" for that purpose. Stereotypes are "Meta-Annotations". So you can introduce your own annotations, using "annotation inheritance". Then you only will have to use your own shortcuts (e.g. @Service, @ServiceFacade etc.). 

The philosophy of EJB 3.1 is exactly the opposite. It is not a complete solution, rather than "only" a component model for transactional, serverside applications. It comes with a set of suitable conventions, so you don't have to configure anything an rely on the existing conventions. Neither annotations (except @Stateless), nor XML-configuration is needed. The EJB infrastructure has to be available at the application server - so you only have to deploy your application - without the EJB-"framework" (Glassfish EJB 3 container is about 700kB) bits. The DI are not as sophisticated as Spring's, JSR-299 or JSR-330, but actually absolutely sufficient for most projects (at least my projects :-)).

EJB 3.1 components are aimed to run directly on the server, without any indirections. This also means: you can only use EJB 3.1 in case your application server has support for it. But: I also saw some projects using openEJB container to run EJB 3.1 on tomcat :-). Whats also true: SAP, IBM Websphere, BEA Weblogic, Oracle OC4J, JBoss 4 and 5, openEJB / Geronimo and Glassfish v2 (+several others) comes already with EJB 3 support. In that case your components become vendor neutral. You can move them around, without changing any EJB 3.X setting (JPA is harder to port across different providers). You will, however, have to test them on different servers. 

Spring will support parts of the Java EE 6 specification - except the @Stateless annotations :-). We (Juergen Hoeller, eJug audience and me) discussed a bit longer this issue. We have different opinions on this: If I were SpringSource, I would support @Stateless and few EJB 3.1 annotation to make the transition more easy. Juergen said it would be hard to support @Stateless in completely compliant way - and he would expect some criticism then. But: the differences could be documented - so there should be no problems as well at this point.

In the practice, however, the support issue may be important as well. It is more and more important to provide the support for the full stack from one company. I guess in future you will see SpringSource only (e.g. dm server), and Java EE 6 only solutions. These decisions will be not driven by technical, rather than political / strategic reasons. Imagine Spring will run on a commercial application server in production and something goes wrong. Such support issues could be really "exciting". Some of my involvements in the resolution of "multi-vendor J2EE-only" support cases were already funny enough in the past :-).

I hope this is a unbiased description of this event - otherwise please feel free to drop me an email or comment. The eJug meeting was well organized at a nice venue - the upcoming sessions are interesting as well. My (English) slides are based on some contents from my "Real World Java EE Patterns" book -the slides should be available for download from eJug. See the German (eJug) summary as well. Thanks Juergen Hoeller for the invitation

Btw. I will cover some "extreme" EJB 3.1 / REST with Convention Over Configuration approaches in the upcoming Java Magazin (German only :-)). 


NEW workshop: Microservices with Java EE 7 and Java 8, January 26th, 2015, Airport Munich

A book about rethinking Java EE Patterns

Comments:

Good comparison, thanks a bunch for that. :) Btw could you give me a short note on "our" JUG Saxony appointment (September 2009)? :)
TIA and all the best,
Kristian

Posted by Kristian Rink on July 06, 2009 at 12:49 PM CEST #

Kristian,

if I'm still invited - I will come :-),

regards,

adam

Posted by Adam Bien on July 06, 2009 at 01:02 PM CEST #

Adam, I think you are missing the biggest benefit of Spring: it's incredibly helpful *Template classes.

They fix all the broken Java APIs, so they're actually usable and productive.

Not to mention project such as Spring Security.

Spring is a lot more than just dependency injection. Not to mention all modern OSS frameworks (e.g. Apache CXF, etc) have Spring integration out of the box.

EJB 3.1 is not even in the same ballpark, sorry.

Posted by Jacek on July 07, 2009 at 08:06 PM CEST #

@Jacek,

"Adam, I think you are missing the biggest benefit of Spring: it's incredibly helpful *Template classes."

Well this is a summary of an eJug meeting in Linz. Juergen Hoeller didn't even mentioned Templates. The reason: he concentrated on the new Spring 3.0 stuff - and I at EJB 3.1 / Java EE 6 architectures. If you like you could also use Templates with EJB 3. But: JPA and DI works very well also without templates. JMS is a bit issue - but is easy to factor that code out into a utility-class.

"...Spring is a lot more than just dependency injection..."

I mentioned this explicitly in this post. Absolutely true.

"EJB 3.1 is not even in the same ballpark, sorry."

You are absolutely right also here. EJB 3.1 is very new. I'm evaluating EJB 3.1 more heavily for my projects.

thanks for your comment!,

adam

Posted by Adam Bien on July 07, 2009 at 09:13 PM CEST #

Adam,

I understand what you are referring to when saying that "Spring is exactly NOT Convention Over Configuration", but I have to disagree on the terminology: Spring follows a "what you request is what you get" approach, which means that there are no hidden services but rather explicitly requested ones only. For example, transactional behavior is always driven by an @Transactional annotation; no standard Spring components have transactions on by default. This increases readability and intuitive understanding of what a component does and which declarative services it will consume. This is arguably convention-based as well (since there is no externalized configuration required), just with a different design than in EJB - in particular with a different approach towards defaults. As you point out, with Spring's stereotype model based on meta annotations, users can define custom shortcuts for specific kinds of components in their own application architecture: e.g. applying transaction defaults to custom @ServiceFacade components.

Juergen

Posted by Juergen Hoeller on July 07, 2009 at 11:28 PM CEST #

@Juergen,

exactly - I mentioned the "Convention Over Configuration" term during our meeting and it ended in longer discussion.
The difference is: Spring comes without any pre-assumptions and EJBs already with conventions which are suitable for serverside applications.

With Stereotypes it is easy to achieve default behavior in Spring as well.
This is what we discussed during the meeting (hopefully :-)).

But Spring is not following the "Convention Over Configuration" out-of-the-box. I guess this is true as well...

I really enjoyed the meeting - thank you for the invitation again. The next time we should fight a bit more...

regards,

adam

Posted by Adam Bien on July 08, 2009 at 09:33 PM CEST #

@Adam, @Juergen: I guess we have to set up another "Spring versus EJB 3.x battle" in future. Next time you guys have to "punch" each other much harder!
See you again at some http://ejug.at session!

Regards,
your eJUG team!

Posted by Martin Ahrer on July 20, 2009 at 01:26 PM CEST #

i think there are several differences between Spring and Java EE6.

You are concentrating just on EJB3, which is one part of the specification.

What really differs in Java EE6 is CDI, aka JSR-299, that Spring deliberatedly refused as a too complex model.

The future will tell whether that statement is true or not.

Posted by naaka on March 24, 2010 at 02:29 PM CET #

Post a Comment:
  • HTML Syntax: NOT allowed
realworldpatterns.com
...the last 150 posts
...the last 10 comments
License