Foreword

THE server-side landscape has changed considerably in the short time since the first edition of this book. Adoption of the Java™ 2 Platform, Enterprise Edition (J2EE™ platform) has been rampant; J2EE has taken over the mainstream of enterprise computing; and the J2EE technology is coming of age. The Enterprise JavaBeans™ (EJB) architecture the core component technology of the J2EE platform has evolved significantly from the model originally released as the EJB 1.1 specification, and this evolution has been driven largely by the needs of the J2EE community.

The evolution of the Enterprise JavaBeans architecture in the 2.0 and 2.1 releases reflects recent changes in distributed computing along with changes in the use of component technology.

The major forces driving the evolution of the EJB technology are the change in the way distributed applications are now structured and how EJB components are used to implement these applications.

Although the Enterprise JavaBeans architecture was originally conceived as providing a distributed business component facility, developers tend to use enterprise beans more for their ability to encapsulate business logic rather than to achieve distribution. To meet developer demand for light-weight, high-performance access to enterprise beans in applications where multitier distribution is not desired, the EJB 2.0 architecture introduced the concept of local enterprise beans. Local enterprise beans provide the benefit of EJB encapsulation coupled with the benefits of container services (such as transactions, security, and persistence), but without the additional complexity and overhead associated with distribution. Local EJB interfaces avoid the performance overhead of remote method invocation, and enable the developer to pass objects between enterprise beans using call-by-reference semantics. In the J2EE 1.3 platform, distribution in applications occurs primarily at the Web layer, and enterprise beans are used primarily for their benefits in structuring an application's business logic.

Another factor that has impacted the evolution of the Enterprise JavaBeans architecture is the experience that has been gained by both developers and vendors using EJB 2.0 container-managed persistence (CMP). This experience demonstrated the popularity of the concept, but it also uncovered limitations with the original EJB 1.1 design. The early CMP architecture, by necessity, was somewhat limited in scope. Experience showed that this early CMP architecture did not fully address the needs of EJB product vendors in ensuring a high level of scalability and performance, nor the needs of developers in facilitating more sophisticated modeling and portability.

The architects of the EJB 2.0 architecture therefore completely revamped the architecture's CMP model. The new architecture enables vendors to provide implementations with high performance and added features for ease of use. Such features include container-managed relationships with support for automatic referential integrity management and a portable query language, which allows developers to specify queries over related sets of entity beans using a convenient and portable SQL-like language. The EJB 2.0 CMP architecture allows EJB developers to more rapidly develop sophisticated applications that fully leverage the benefits provided by the EJB architecture. This new architecture retains the original EJB benefits while adding much richer persistence support and better container control of CMP entity bean state.

A third trend that has influenced the EJB architecture's evolution is the interest in more loosely-coupled, asynchronous applications. This led to the introduction of a third enterprise bean type in EJB 2.0 the message-driven bean. Message-driven beans enable the EJB technology and with it the J2EE platform to enter the world of asynchronous computing. Message-driven beans enable enterprise beans to receive asynchronous messages, thus allowing EJB components to integrate with legacy systems that use messaging to provide loosely-coupled application integration. Because the core messaging technology of the J2EE platform is the Java™ Message Service (JMS), EJB 2.0 message-driven beans were initially directly targeted at support for the use of JMS messaging. The EJB 2.1 architecture continues this support for asynchronicity. The EJB 2.1 architecture further generalizes message-driven beans to support the integration of arbitrary messaging types, and the 2.1 architecture also extends the technology by including the EJB timer service.

The evolution of the EJB architecture takes another exciting shift in direction with the EJB 2.1 release. A major new Web distribution model called Web services has emerged in the industry. This is a model for offering services designed to be accessed via programs rather than a browser. The central focus of the new EJB 2.1 architecture is Web services. Web services support in the EJB 2.1 architecture allows the functionality of EJB applications to be exposed over the Web, where they can be dynamically discovered and accessed over HTTP. Most importantly, Web services allow service consumers and providers to be loosely and flexibly coupled; Web services support use from heterogeneous systems and enable integration of non-J2EE systems.

Initially, developers thought that implementing a Web service was equivalent to stripping the browser-support layer from an existing application and directly exposing its business logic. As experience with Web services has grown, it has become clear that Web service applications still require a non-browser service presentation layer to decouple Web services clients from the complexity of business logic. With the Web service support it now provides, the EJB 2.1 architecture is an excellent facility for implementing a Web service's presentation layer.

The EJB 2.1 architecture also enables enterprise beans to be clients of Web services, making it possible for application developers to compose EJB applications from aggregations of such services. The implementation of Web services with the EJB 2.1 architecture is easy and straightforward, and leverages the familiar stateless session bean model.

The global access and interoperability currently provided by the Simple Object Access Protocol (SOAP) and Web Services Description Language (WSDL) Web services standards adds significant value to enterprise bean components and the EJB architecture. With Web services, the EJB architecture gains global reach. Access to a service implemented with enterprise bean components is no longer restricted to EJB-aware clients; this service can now be accessed with the same global, heterogeneous model that empowered browser-based services. In addition to its new role in implementing the service presentation layer for Web services, the EJB 2.1 architecture continues to deliver a robust business component model for implementing the business logic and domain models of both Web sites and Web services.

The Enterprise JavaBeans architecture, at the core of the J2EE platform, has played a key role in its evolution expanding its scope in providing scalable and reliable enterprise computing, and adding new features to promote more rapid development of enterprise applications. In addition to fulfilling its original goals of providing the portable component model for enterprise applications, the EJB architecture has expanded to encompass the key technological underpinnings to support integration with legacy systems, asynchronous communication, and the infrastructure for Web services technologies.

The EJB architecture and its components have thus matured to support today's style of applications applications that focus on the Web for distribution, require loosely-coupled messaging for integrating business flows, and desire formal components for better encapsulation of business logic within multiple service tiers.

The EJB architecture team and expert group have done a great job shepherding the EJB technology through this process of evolution. They have ensured that the EJB architecture has retained all of its original essential benefits while at the same time keeping it closely in tune with today's evolving needs.

Mark Hapner
Lead Architect, J2EE platform
Sun Microsystems