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 3

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.

Dependency Management
Dependency management refers to the ability to control the communication between components in a system. By externalizing (or "wiring") these interdependencies designers intend to create more loosely coupled systems. Systems with looser coupling are generally easier to extend, test, and maintain. Externalizing dependency management is also referred to as inversion of control (IOC) and the act of injecting dependencies into a class is referred to as dependency injection.

There are three primary forms of dependency injection: setter, constructor, and field injection. For a discussion of setter versus constructor injection see "Inversion of Control Containers and the Dependency Injection Pattern" by Martin Fowler. The value of field injection is debatable. It is certainly convenient when using JEE's dependency injection annotations but it violates the principle of encapsulation and makes it more difficult to unit test classes.

Spring and EJB 3.0 both offer support for dependency management but implement different types of dependency injection. Spring supports both setter- and constructor-based injection. EJB 3.0 supports setter and field injection. Neither is a limiting decision, but this subtle difference should be kept in mind when considering Spring and EJB 3.0's support for dependency management.

One of the core features of the Spring framework is its IOC framework and so, not surprisingly, it offers much more mature and configurable support for dependency management then does EJB 3.0. In Spring dependencies are generally mapped (or "wired") via XML configuration files. The primary mechanism for wiring in JEE 5—and in EJB 3.0 specifically—is via source code annotations. Annotations have the advantage of being closer to the code they modify and thus can improve understandability of the system. On the other hand they create compile-time and runtime dependencies on their implementation and thus compromise the portability of annotated classes.

In Spring, applications dependencies are most typically configured via XML:

<bean id="bookingAgentSpring" class="org.jug.flight.booking.spring.BookingAgentSpring">
    <property name="flightDAO" ref="flightDAO" />
    <property name="ticketDAO" ref="ticketDAO" />
By contrast, with JEE 5 and EJB 3.0, dependency injection often takes the form of annotations:

public class BookingAgentEJB extends AbstractStatefulBookingAgent implements BookingAgent
    private FlightDAO flightDAO;

    private TicketDAO ticketDAO;

In larger applications with more interdependencies and resource requirements wiring can be an arduous task. The ability of the dependency injection container to implicitly wire dependencies is referred to as auto-wiring. Both Spring and EJB 3.0 have the ability to wire dependencies by both name and type.

A unique feature to Spring is its ability to invoke factory beans to create object instances. This allows object factories to be invoked to create object instances for injection. It can give developers programmatic control of the object creation process as well as legacy code to be adapted to the Spring dependency management mechanism.

The power of dependency management in the Spring framework is in its ability to manage any object, to integrate with legacy code bases, and to be highly extensible and configurable. The EJB 3.0 dependency management facility is useful, but not nearly as robust as the one offered by Spring. Table 3 summarizes the differences in support for dependency management between Spring and EJB 3.0:

Table 3. Dependency Management Features in Spring and EJB 3.0.

Feature Spring EJB 3.0
Setter Injection
Constructor Injection --
Field Injection --
Autowiring √ (by name and type) √ (by name and type)
Factory Beans --
Factory Methods --
JNDI Injection
Configuration Primarily XML Primarily Annotations
Scope Any Object Specific JEE types

Intermediation means coming between two things in time, place, or order. It is an important concept in enterprise software development as intermediation can address problems not easily solved through traditional object design. One example might be security. In an application where policy requires authentication for all system operations, an object oriented approach that encapsulates that authentication information in a dedicated object makes sense. But programmers must still remember to delegate to this component in each new system operation they create. Alternatively this policy can be applied to the application outside of the code through techniques such as filters, interceptors, or full-blown aspect-oriented programming (AOP). Issues such as the security example I just gave are frequently referred to as crosscutting concerns because they cut through many points in an application. Intermediation can be described as a technique to modularize such concerns.

As AOP is a core feature of Spring it is not surprising that it offers rich capabilities in this area. Spring allows additional behavior to be applied to an application through several mechanisms. In Spring 1.2 such behavior was described through XML configuration files where pointcuts, advice, and advisors were defined and wired into an application. Spring 2.0 provides tight integration with AspectJ and allows aspects to be defined via annotations or via XML.

AspectJ is a powerful AOP framework allowing you to control almost all facets of your application. For more information on implementing AOP techniques consult Brett Schuchert’s excellent wiki page.

As EJB 3.0 was influenced greatly by the success of Spring, the specification has taken a first step in the direction of intermediation by introducing the concept of method interception. Interceptors allow custom code to execute around EJB methods. Interceptors can be either special methods in an EJB or in a separate class entirely. Interceptors can be mapped to methods either via annotations or XML. Interceptors are nowhere near as robust as Spring AOP, especially when coupled with AspectJ, but they do provide very useful functionality in a specification-compliant manner.

Table 4 summarizes the differences in intermediation support offered by Spring and EJB 3.0:

Table 4. Intermediation Features in Spring and EJB 3.0.

Feature Spring EJB 3.0
Method Interception
Scope Any Object Only EJBs
Pointcuts --
Introductions --
Integrations AspectJ --
Standards AOP Alliance JCP

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date