A Peek at EJB 2.0, Part 1

Introduction

A few Internet eons ago, Sun Microsystems unleashed a new paradigm in server-side computing, namely Enterprise Java Beans. EJBs were specified as server-side components, i.e., modular, structured and loosely coupled pieces of code that provided a single point of functionality or service.

Using these EJBs, a server-side programmer would be able to construct Web applications and services by simply connecting (also called wiring) various beans, invoking necessary services from them. Server-side computing took a significant step forward with the introduction of the Java 2 Enterprise Edition platform, a comprehensive collection of server-side specific technologies all bundled together. EJBs formed an integral part of this platform. As the platform matured, the EJB specifications also needed revisions. At the time of writing, the latest specification of EJB is a Proposed Final Draft 2 and the latest J2EE is 1.3 Beta. The J2EE specifications have heavy influence on the EJB specs. The EJB 2.0 specification is to be made final very soon, so let's take a peek at what we have in store.

Goals of the EJB 2.0 specification

The Proposed Final Draft 2 specifically lists the goals for the 2.0 specification as:

1. Define the integration of EJB with the Java Message Service (JMS)
2. Provide a local client view and support for efficient, lightweight access to EJBs from local clients
3. Provide improved support for the persistence of entity beans
4. Provide improved support for management of relationships among entity beans
5. Provide a query syntax for entity bean finder methods
6. Provide support for additional methods in the home interface
7. Provide for network interoperability among EJB servers.

Equipped with this set of goals, the EJB architects set out to make modifications and updates to the EJB specifications, which have so far culminated in the EJB Proposed Final Draft 2. In the rest of this series of articles, I will enumerate the changes made to the specification in order to realize goals that had been laid out.

Goal 1: Integration of JMS with EJB

JMS provides loosely coupled messaging facilities through a standard API known as the JMS API. Using the JMS, developers can create asynchronous, event-driven systems that communicate through protocol messages. The JMS provides the middleware plumbing to support creation, transmission, and receipt of messages. The latest revision of the J2EE platform bundles the JMS API (unlike the J2EE 1.2 release where a service provider approach was used to supply the JMS API). With JMS becoming an integral part of the J2EE platform, tight integration with EJB necessitated this specification revision.

In order to provide the integration, the EJB architects choose to define a new type of EJB called Message Driven Beans. These are unlike any other beans that you currently know of, because they neither have a home interface nor a component interface. Further, there is no explicit client interface to the bean. Clients of message-driven beans simply send messages to the JMS queue or Topic. The container that provides the JMS services invokes the message-driven bean to handle the incoming message. In this respect, message-driven beans are "faceless" to the client. The specific purpose of these beans is to process asynchronous messages delivered by the JMS. Typically they are stateless and can participate in transactions. The container provides full life-cycle services to the bean along with transaction, security, and concurrency services.

In terms of code, all message-driven classes implement javax.ejb.MessageDrivenBean and the javax.jms.MessageListener interfaces. The class must be public and have a public constructor that takes no arguments for the container to invoke. Further it must not define the finalize() method and must define the ejbCreate() method, ejbRemove() method and the onMessage(javax.jms.Message) method to handle incoming JMS messages. Also message-driven beans have no home or component interfaces, thereby reducing the quantum of work to create these types of beans.

A usage scenario for these types of beans would be an event-driven process that operates asynchronously. An intranet workflow application based on EJBs fits the profile wherein business objects (examples are leave requests, travel reimbursement requests, etc.) send asynchronous messages to the beans. After the requests have been processed (it may even take a day or two) it could further invoke other message-driven beans to inform the user via email, mobile phone, or pager that the request has been processed.

Goal 2: Provide a local client view to provide quick lightweight access for local clients to EJBs

Historically, all interfaces to the EJB have been remote, i.e., extending from java.rmi.Remote. This means that clients utilizing the services provided by the EJB would invoke them through RMI, even if the client resided in the same container and JVM! This was a slight oversight in the earlier specification, but it has been corrected in this specification.

While it is possible in theory to define both remote and local interfaces to the EJB, one would normally partition their EJBs to be remote or local but not both at the same time. This way it is clear and declarative which EJBs provide remote services that can be accessed across containers and VMs and others that are intended to be invoked within the same container.

Note that local interfaces may be invoked using standard Java language semantics and are not accessible outside the VM in which they are contained. This eliminates the "location transparency" that remote interfaces enjoy. EJBs with local interfaces are bound to the VM in which they run.

To support this, EJB architects have introduced additional interfaces along the lines of the earlier home and component interfaces. So similar to the remote home interface javax.ejb.EJBHome and the remote component interface javax.ejb.EJBObject there are corresponding local interfaces that do not extend java.rmi.Remote, called javax.ejb.EJBLocalHome and javax.ejb.EJBLocalObject.

Though the addition of the local view concepts have introduced some additional complexity (local/remote interfaces, entity/session EJBs, home/remote interfaces), the addition of this level of EJB access will help performance by eliminating RMI calls in favor of VM object binding. It also assists application developers to declare upfront whether an EJB would serve local or remote clients, thereby making the code semantically more readable. These explicit declarations of intent of code are the essence of contract programming, which the J2EE platform relies heavily on.

In Part 2 of this article, we'll discuss the improved support of entity bean persistence.

Resources

Migrating from Enterprise JavaBeans (EJB) 1.1 to 2.0

About the Author