Transitioning to EJB 2.0
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Although the Enterprise JavaBeans (EJB) 2.0 Specification was finalized in August 2001 and several of the leading application servers support it, many EJB developers are still working with applications based on the 1.1 specification. With the lengthy review process that took place for the latest specification, most developers are at least aware of the advantages EJB 2.0 offers. However, the business case for upgrading an existing application can be hard to justify, especially during an economic downturn.
Depending on your application, it's true that some of the EJB 2.0 changes bring with them a significant amount of rework. However, this doesn't hold true for all of EJB 2.0. Several steps can be taken at a relatively small cost to improve both the portability and the maintainability of an existing application. This article discusses some of the simplest ways that a developer using an EJB 2.0–capable server can begin making the move to the latest and greatest that EJB has to offer.
Stepping Up to EJB 2.0
To set the stage, we'll start with a quick summary of the major changes. The most visible of these is the introduction of a third bean type, the message-driven bean. This addition allows an EJB application to make use of the Java Message Service (JMS) in a standard way. You can implement business logic using a message-driven bean that is executed asynchronously in response to messages sent to a JMS queue or topic. These messages can be sent by an external client of your application or another component within it. Under earlier EJB versions, the use of asynchronous messaging within your applications had to take place outside the EJB framework and often depended on vendor-specific capabilities.
EJB 2.0 has also changed how method calls between beans deployed within the same container can be executed. Under EJB 1.1, all clients of session and entity beans are viewed as remote clients. A remote client creates or locates an EJB object by calling a method on the bean's home interface. The client then invokes business logic by calling the remote interface. The EJB container intercedes on all calls to these interfaces to provide necessary services such as security and support for transactions. This approach leads to location independence, meaning that a client application can be coded and executed the same regardless of whether an EJB that it depends on is deployed on the same machine or somewhere else on the network. Location independence requires that method calls always follow pass-by-value semantics. This means that method arguments and return values are marshaled back and forth even when the client is another EJB instance running in the same JVM. Some application servers include optimizations to reduce this overhead, but there's no standard across implementations. Because of this drawback, some of the EJB design patterns first adopted were aimed at reducing the number of calls made from session beans to entity beans.
To improve the performance of calls between enterprise beans, EJB 2.0 introduced support for local clients in addition to remote clients. If a session or entity bean supports other enterprise beans deployed in the same container as clients, those beans can be treated quite differently than other callers. Instead of the remote and home interfaces used by remote clients, local clients interact with a bean through its local and local home interfaces. Calls made through these interfaces use pass-by-reference semantics and avoid the marshalling and other overhead of remote calls. Local clients give up location independence and are tightly coupled to the beans that they access, but the performance advantages make up for these limitations whenever remote client access isn't needed.
Besides adding local home interfaces, EJB 2.0 added another type of method to an entity bean's home. EJB 1.1 home interfaces declare only the methods that create new instances of a bean and locate existing entity objects—you declare all business methods for a bean in its remote interface. Because static methods aren't allowed in an EJB, you can execute a business method only by invoking it on a particular object through its remote interface. If you need to implement a business method for an entity bean class that doesn't depend on any particular entity instance (or one that depends on more than one of them), using a session bean method is the option most widely used in EJB 1.1. Static methods are still prohibited by EJB 2.0, but you can now implement business methods within a bean class that are independent of any particular instance. You declare these methods, known as home methods, in the home or local home interface. When you call a home method, the container selects an available instance of the bean class from the pool that it manages and invokes the method on that instance. Similar to static methods, a home method cannot reference any fields of the instance used to invoke it.
If you use entity beans with container-managed persistence (CMP), the 2.0 specification introduces a fundamentally different implementation approach. The bean classes that you write for a CMP entity bean are now abstract classes that define their fields through a series of abstract get and set method declarations. Instead of including any actual field declarations, your classes identify their fields using only their method declarations. These declarations form part of what is known as the abstract persistence schema for a CMP bean. It's the responsibility of the container to generate a concrete bean class based on the fields declared by your get and set methods and the relationships that you define in the deployment descriptor. As part of this, the container now manages relationships between entity beans as a standard capability. To address another portability issue, finder methods are defined using a standard syntax known as the EJB Query Language (EJB QL). You can port finder method queries defined with EJB QL to any EJB 2.0 container without having to modify them.
EJB 2.0 includes a few other changes, but those mentioned so far are the only ones we need to look at for our purposes here. The other enhancements deal primarily with the security role applied to calls made by an EJB and the interoperability of EJBs with J2EE applications deployed in another vendor's application server.