These days more and more applications are being built on so-called lightweight platforms with technologies like Spring and Tomcat rather than on traditional heavyweight application servers. Despite this move, there is still a place for the application server, and there is certainly a place for many of the J2EE APIs. In this chapter, we cover J2EE support in Spring in detail, focusing in particular on the three following APIs:
JNDI: The Java Naming and Directory Interface (JNDI) provides a standard interface on which Java applications can interact with naming and directory services. In a J2EE setting, we see that JNDI is used to access resources bound to the naming service of the application server. This is the traditional way to look up services in a J2EE context. In this section, we look at the convenience APIs provided by Spring to simplify JNDI coding and how the JndiObjectFactoryBean class provided by Spring acts as an adapter between the world of JNDI lookup and Spring Dependency Injection (DI).
EJB: In traditional J2EE applications, Enterprise Java Beans (EJB) often formed the cornerstone of an application's architecture. Although Spring provides simpler versions of many of the services provided by EJB, such as declarative transaction management and object persistence, many applications will continue to be built using EJBs for some time. Thankfully, you can still utilize Spring in an EJB-based solution, and in this section, we look at how Spring can simplify the creation of EJBs and provide a straightforward, DI–friendly way to access EJB resources.
JMS: The Java Message Service (JMS) provides a standard API from which Java applications can access messaging services. JMS provides the ability for an application to run processes in an asynchronous manner, and it also provides a reliable messaging fabric for distributed applications. Spring comes complete with wrapper APIs around both the 1.0.2 and 1.1 JMS APIs, providing an implementation-agnostic way to access JMS resources of both versions. In addition, Spring provides a greatly simplified API for sending and receiving messages in a JMS environment.
A common misunderstanding we have seen with J2EE is that J2EE is all or nothing—that is to say you either get the full stack or nothing at all. Clearly this is not true; many projects such as Tomcat offer simple servlet containers without providing features for EJB and many of the other J2EE APIs.
The servlet API is a classic example of a J2EE API that has enjoyed considerable success outside of the application server. We often see developers who are keen to use Spring and Tomcat, but because they need a feature such as JMS, they feel that they have to use an application server such as JBoss. This is not the case, however, and part of the beauty of Spring is that it encourages us to piece together our own stack, rather than simply settle for an application server that offers the full stack.
In this chapter, when we look at JNDI and EJB, we are going to go down the traditional route and use the JBoss application server. However, when we look at JMS, we are going to use one of our favorite configurations—Spring, Tomcat, and ActiveMQ. In this way, we get the benefit of the lightweight approach with Spring and Tomcat, and we get a high-quality, open source messaging solution with ActiveMQ.
This chapter is not an introduction to JNDI, EJB, or JMS. We assume that you are already familiar with these APIs, what they are used for, and how they are related. If you are not, then we suggest that you read Beginning J2EE 1.4: From Novice to Professional by James L. Weaver, Kevin Mukhar, and Jim Crume (Apress, 2004).