Difference between EJB and Spring Framework

Most importantly, Spring is an implementation while EJB 3.0 is a specification. But they do have some areas of overlap, for example both provide a mechanism to deliver middleware services to Java applications. Spring was developed as a reaction against EJB and this makes comparison between the two natural. Particularly now that a new version of EJB is available, it is a good time to re-evaluate how well EJB 3.0 has addressed the shortcomings of previous versions

Characteristics of EJB 2.x, Spring and EJB 3.0

EJB 2.x

a. Made developer to write a bunch of redundant artifacts.

b. Deployment descriptors difficulties

c. Long develop-test-debug cycle with little unit testing.

d. Entity beans are half-baked and non-portable.

e. Entity beans are slow. Remoting and global synchronization are overkill.

Spring Framework

a. POJO programming.

b. Much easier to develop, test and deploy.

c. Gives 90+% of what EJB does.

EJB 3.0

a. EJB 3 embraces POJO programming through annotations.

b. The verbose XML deployment descriptor has been made optional.

c. The Entity Bean concept is no longer managed by the container.

d. Instead, EJB 3 adopts JPA, an API based paradigm similar to Hibernate, TopLink and JDO.

e. Object Relational Mapping and Object queries have been completely defined instead of being left up to container vendors to sort out.

f. EJB 3 makes heavy use of “intelligent defaulting” whenever possible. This is a similar idea to “convention over configuration” in the Rails world.

Comparison Matrix between Spring Vs EJB 3.0

Below table describes the gives the comparison details of various concepts and services involved between EJB 3.0 and Spring framework. The column “Is required for Leicester?” will have the information about if it is really matters or not.

Concepts/Services	EJB 3.0	Spring Framework	Is required for Leicester?
Dependency Injection	Can inject anything in the container including EJBs, data sources, JMS resources and JPA resources	Can inject almost anything including lists, maps, properties and JNDI resources	Implementation choice
Transaction management	Works right out of the box, but only JTA is supported	Have to configure it to make it work, but supports a number of strategies including JTA, JDBC and Hibernate	Highly Required
Persistence	Tightly integrated through JPA	Framework support for JPA, Hibernate, JDBC, iBatis	Highly Required
State management	Robust support through Stateful Session Beans and Extended Persistence Context	Indirect support dependent on web container session management	Highly Required
Web Services	Seamless support for JAX-WS 2.0	Poor direct support, best integration available is via configuring XFire for registered beans.	Highly Required
Messaging	Supported out of the box through Message Driven Beans.	Need to add configuration for message listeners. However, JMSTemplate adds nice abstraction over JMS.	Highly Required
AOP	Simple but limited support through interceptors.	Robust support through AspectJ and Spring AOP alliance.	May be
Security	Integrated support for declarative and programmatic security through JAAS.	Must add and configure Acegi security. However, support beyond JAAS is possible through Acegi.	Highly Required
Scheduling	Simple scheduling possible through EJB Timer service	Must add and configure Quartz for scheduling.	May be or N/A
Remoting	Integrated support through Session Bean remote interfaces. Supports distributed transactions and security.	Remoting support may be added via configuration. Remote transactions and security are not supported. However protocols other than RMI such as Hessian and Burlap are supported.	May be

Conclusion

At this point we have learned many similarities between Spring framework and EJB 3.0. It is totally upto the user’s discretion to choose one of them since both technologies have their own pros and cons and they do have their own work around for each disadvantage.

They are subjected to debatable forever and corresponding technology inventor would justify that“they are the best” and sometimes selection would be based upon the political decision too. (i.e. biased to certain technology)

From the earlier sections of this document, we can summarize list of situations where it might be too appropriate to consider Spring or EJB 3.0

Use Spring if:

  - Your application requires fine-grained control at the container level.

  - Your application requires a lot of configuration beyond gluing together components and resources.

  - You need advance AOP feathers.

Use EJB 3 If:

  - You like annotation and dislike a lot of XML configuration.

  - You prefer a tightly integrated solution stack that makes sensible default choices for you and minimizes configuration.

  - Your application is very stateful.

  - Standardization is an important consideration.

  - You use JSF and are considering using Seam.

Spring gives you more flexibility in many aspects of application development than EJB does—and this is particularly true with regards to persistence and transaction providers. But the trade-off for this added flexibility is increased complexity in configuration. EJB 3.0 provides less flexibility but its tight technology stack, annotations-based configuration, and philosophy of configuration by exception make configuring EJB 3.0 applications quite simple.

Standardization: While Spring integrates many standards such as JTA, JDBC, and JMS it is not itself a Java standard. When standardization (and by extension vendor support, tooling, etc.) is important to our organization or application then it is good to simply go with EJB 3.0.

Recommendations

In order to choose the right choice (close to best) for Leicester we do take the following important factors for consideration and all the other factors for this project could be sufficed by both of them.

  - State Management

  - Configurability

  - Standardization

  - Web Service

  - Security

When the Leicester is highly stateful then it is necessary to consider EJB 3.0 SFSBs might be a good solution. For highly conversational applications we may want to consider SEAM, which provides a very powerful solution for conversational interaction built on SFSBs and JSF.

For all the above potential factors , EJB3.0 would work better for us when compared to Spring framework and because of these factors it is recommended to use Java EE 5 (EJB 3.0) as a technology solution for Leicester project.

Important Note: Luckily Spring and EJB 3.0 are not mutually exclusive choices. There are very powerful ways of integrating these two technologies to take advantage of their relative strengths and weaknesses. When it is highly necessary, with Java EE 5 it’s always possible to make use of some common integration points with the Spring Framework. Specifically, EJB 3.0 and JPA combine naturally with Spring.