Enterprise JavaBeans[tm] 2.0 Specification

Download Specification

What's new in the Enterprise JavaBeans^TM 2.0 Specification?

Since its introduction over two years ago, Enterprise JavaBeans^TM (EJB^TM) technology has maintained unprecedented momentum among platform providers and enterprise development teams alike. That's because the EJB server-side component model simplifies development of middleware components that are transactional, scalable, and portable. Enterprise JavaBeans servers reduce the complexity of developing middleware by providing automatic support for middleware services such as transactions, security, database connectivity, and more.

EJB 2.0 technology represents a major new release offering many significant benefits, further simplifying and expediting development and deployment of more feature-rich enterprise applications. On April 26, 2001, Sun released the EJB 2.0 specification Final Proposed Draft #2 to the public through the Java Community Process^SM (JCP 2.0).

This article describes the changes in EJB 2.0, and how these new features can make application development easier and faster.

As EJB technology has been a pivotal technology in enabling e-commerce implementations, an e-commerce retail site example will be utilized in order to describe the key new features of the EJB 2.0 specification.

Integration with Java^TM Message Service (JMS) -- Asynchronous Capabilities Streamline Systems

The use of asynchronous messaging allows the development of loosely-connected systems (or applications). These systems are typically more resilient in the event of failures, and more easily extensible as new applications are developed. Additionally, messaging provides an effective means of transmitting events between applications.

Java Message Service (JMS) brings asynchronous messaging services to Java applications developers.

The integration of JMS and EJB allows enterprise beans to participate fully in loosely connected systems. Through this integration, message-driven beans can receive and act upon JMS messages, without the involvement (or existence) of an application client user interface. This new capability makes EJB an excellent choice for the development of shared business services. Additionally, any EJB can send asynchronous messages via the JMS API.

In the web retail example, when a shopper makes a purchase, an inventory bean could notify an ordering bean or external supply chain management system of a low stock situation. Since this notification is asynchronous, the shopper does not have to wait while this complex business to business reordering operation completes. Furthermore, disconnected users, such as cell phone users, may request a transaction such as selling/buying stock and immediately disconnect. The appropriate asynchronous message will be sent to the trading enterprise bean, which can execute the transaction and then send a notification pager message to the cell phone user upon completion.

As this simple example demonstrates, JMS integration streamlines application behavior, eliminates bottlenecks and reduces wait time for the user, resulting in a better shopping experience and heightened customer retention.

Container-Managed Persistence (CMP) -- Simplifying and Expediting Application Development

The EJB architecture greatly simplifies the connection between the application and the database tiers. The EJB 2.0 specification takes this benefit to the next level by allowing developers to develop portable applications that are database-independent and free of database access code.

Frequently, application developers don't have access to the physical database schema when building their applications. Sometimes this is for security reasons. Sometimes it is because the physical schema has not been designed or finalized. Other times, application developers don't want to know the entire physical database schema, especially when a large, complex database is shared between many less-complex applications.

CMP can be used to isolate the application developer from the physical database schema. This done by creating an abstract schema that matches the needs of the current application, and using CMP to map between the abstract and physical schemas. This technique allows better partitioning of effort in the development staff, requires less code to be written and maintained, and provides faster time to market. Additionally, the use of CMP ensures that applications are portable in the event of vendor or schema changes.

EJB 1.1 provided a simple CMP facility that provided some of these benefits. However, feedback from the development community indicated that this facility was too limited, both in the data modeling capability and in the mechanism used to define the mapping of the CMP bean to the database schema.

EJB 2.0 extends CMP to address these concerns. A far more robust modeling capability is added, with support for declarative management of relationships between entity EJBs. Developers no longer need to re-establish relationships between the various beans that make up their application -- the container will restore the connections automatically as beans are loaded, allowing bean developers to navigate between beans much as they would between any standard Java objects.

EJB 2.0 also introduces for the first time a portable query language, based on the abstract schema, not on the more complex database schema. This provides a database and vendor-independent way to find entity beans at run time, based on a wide variety of search criteria.

What does all this mean? Developers can focus on creating business logic, while the EJB container automatically manages the database access for their applications.

In the context of our web retail example, the benefit of CMP is realized in many places. For example, there are many related database updates that need to occur in response to a purchase, in the inventory database, the purchase order database, the customer database and so on. To complicate the situation, some of these databases may be relational, while others may be customer relationship management systems or other enterprise applications. Declarative relationships between enterprise beans enable the developer to specify the relationship between customers and purchase orders, once. He doesn't need to understand the storage technologies, or foreign key relationships, or to manually write the database access code to facilitate all these database updates. This increases competitiveness of the web retail site by enabling the development team to attain faster time to market, not only for new applications, but also for application updates that are required to adapt to frequently changing market needs. The resulting application will also be smaller in code-base, hence easier to maintain, and portable across application servers and databases systems from different vendors, allowing the selection of different vendors as business needs change.

Local Interfaces -- Streamlining Calls Between Local Beans

EJB was originally designed around remote invocation using the Java Remote Method Invocation (RMI) mechanism, and later extended to support to standard CORBA transport for these calls using RMI/IIOP. This design allowed for maximum flexibility in developing applications without consideration for the deployment scenario, and was a strong feature in support of a goal of component reuse in J2EE.

We received a good deal of community input regarding the way EJBs are used in the field. Many developers are using EJBs locally -- that is, some or all of their EJB calls are between beans in a single container.

With this feedback in mind, the EJB 2.0 expert group has created a local interface mechanism. The local interface may be defined for a bean during development, to allow streamlined calls to the bean if a caller is in the same container. This facility will thus improve the performance of applications in which co-location is planned.

EJB 2.0 local interfaces can be very useful in the situations for which they were designed.

However, it is important to understand that the calling semantics of local interfaces are different from those of remote interfaces. For example, remote interfaces pass parameters using call-by-value semantics, while local interfaces use call-by-reference.

This means that in order to use local interfaces safely, application developers need to carefully consider potential deployment scenarios up front, then decide which interfaces can be local and which remote, and finally, develop the application code with these choices in mind.

While EJB 2.0 local interfaces are extremely useful in some situations, the long-term costs of these choices, especially when changing requirements and component reuse are taken into account, need to be factored into the design decision.

Inter-Server Interoperability -- Enabling Heterogeneous Environments

Cross-server application portability has always been a core premise for EJB technology. The EJB 2.0 specification takes this benefit to the next level by offering inter-server application interoperability. This will enable EJB technology-based applications operating on EJB servers from different vendors to freely interoperate using the RMI-IIOP protocol.

In a web retail site, a shopping cart bean executing on an application server from one vendor will be able to obtain inventory information by communicating with an inventory bean executing on an application server from a different vendor. Thus the retailer will be able to deploy their EJB technology-based application across a heterogeneous environment mixing application servers from different vendors, knowing that beans will be able to effectively communicate across these servers.

Conclusion

The EJB 2.0 specification, developed by the Java Community under the Java Community Process 2, is an important step in streamlining the development and deployment of J2EE applications. When this specification is implemented in J2EE 1.3, application developers will be able to develop applications that take full advantage of the core J2EE value propositions:

• J2EE enables faster solution deliver time to market.


• J2EE prevents vendor lock.


• J2EE simplifies integration.

Download Specification