RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Make the Right Decision with Our Side-by-Side Comparison of Spring and EJB 3.0, Part 2 : Page 4

Explore the similarities and differences between two of the most popular Java technologies today and learn key distinctions in making a technological decision between the two. Part 2 explores messaging, remoting, dependency injection, and more.

Integration Strategies
As has been seen throughout this article, Spring and EJB 3.0, while being different in nature, address many of the same concerns. As should be expected, each technology addresses these concerns differently and each has its own advantages and disadvantages. There will certainly be some situations where you will want to wholly adopt one technology over the other. But you should also consider blending the strengths of each.

Here are some strategies for doing this:

  • Use the Java Persistence API in your Spring application—Spring 2.0 supports the Java Persistence API allowing you to take advantage of this persistence standard in your Spring application
  • Inject EJB 3 components into your Spring application—This is much simpler as of EJB 3 and can be performed using Spring’s JndiObjectFactoryBean
  • Inject Spring beans into EJB 3 components—This can be accomplished using EJB 3 interceptors or another AOP mechanism. The JBoss Spring deployer (http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossSpringIntegration) is an example of this.
  • Use Pitchfork to allow elements of EJB 3 to be used within Spring—Pitchfork (http://www.interface21.com/pitchfork) provides a Spring-based implementation of some elements of EJB 3 including interceptors, injection, and declarative transaction management.
Another approach that could be appropriate depending on the circumstances is to reinforce the shortcomings of EJB with vendor-specific functionality. For example, the JBoss application server offers robust AOP and dependency injection on top of its EJB 3.0 implementation.

The Bottom Line
EJB 3.0 has succeeded in its goal of simplifying the development of enterprise components while continuing to offer many useful services to support the development of enterprise Java applications. However, as we have seen, the Spring framework succeeds in offering comparable services while still providing great flexibility in development of powerful, flexible, and testable enterprise applications.

In the first article I compared Spring and EJB 3.0 in terms of persistence, transaction management, and statefulness. I highlighted support for statefulness, flexibility, configurability, and standardization as the more characteristic differences between the two frameworks. In this article I explored support for messaging, remoting, dependency management, and intermediation.

Spring and EJB 3.0 offer fairly comparable support for messaging. Message-driven beans are a proven and important part of EJB. By contrast, message-driven POJOs are a new addition to Spring. But Spring does offer additional support for sending JMS messages in the form of templates and message converters.

EJB 3.0 offers stronger support for remoting then the Spring framework. In fact, Rod Johnson's book "J2EE Development without EJB" acknowledges that distribution is one of the things that EJB does well and provides arguably the strongest case for EJB. In part 1 of this article I mentioned that EJB defines itself as a distributed component architecture. As distribution is key to what EJB is it is not surprising that it excels in this area. In many applications however remoting is an unnecessary complexity. If remoting is an important part of your application then you should strongly consider EJB.

Dependency management and intermediation are strong aspects of the Spring framework. In fact, Spring's flexibility and extensibility are due largely to Spring's strength in these two areas. EJB 3.0's support for dependency management and intermediation pale in comparison to Spring's. The value of Spring's support for dependency management and intermediation cannot be understated, particularly in the areas of testability and runtime configurability.

Additionally, it should be noted that Spring can more easily be configured to run in a wider array of environments. For example, EJB 3.0 requires Java 5 while Spring does not. As many large corporations have not yet made the move to Java 5 this is an important distinction. EJB 3.0 requires an EJB container (although this container may be embedded), while Spring can run in a JSE environment. EJB 3.0 also has additional packaging and deployment requirements that Spring does not. There is no doubt that Spring is more configurable and flexible than EJB 3.0, but it does require experience and expertise to be used effectively. Of course, enterprise development always requires skill as these types of applications are among the more complex, and valuable, ones being produced today.

Rod Coffin is an agile technologist at Semantra, helping to develop an innovative natural language ad hoc reporting platform. He has many years of experience mentoring teams on enterprise Java development and agile practices and has written several articles on a range of topics from Aspect-Oriented Programming to EJB 3.0. Rod is a frequent speaker at user groups and technology conferences and can be contacted via his home page.
Email AuthorEmail Author
Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date