Why EJB?

The EJB architecture allows enterprise applications to be portable by running on a J2EE-compliant application server. An EJB application can be partitioned in a more usable, flexible, and expandable fashion. For example, new clients to access legacy systems can be easily built to meet user requirements. Moreover, the EJB architecture helps create a service-based model in which services are location-transparent components that can be delivered to their target clients. EJBs are highly reusable components, and represent the next step in the progression of Java technology for the development of application platforms capable of supporting mission-critical, component-based, enterprise applications. EJB components allow the development of business logic to be used across enterprise applications and to be portable across different platforms.

The EJB model is based on Java Remote Method Invocation (RMI) technology, which supports the separation of executable components across multiple tiers. This separation permits maximum implementation flexibility and high scalability. RMI allows access to remote components to appear as if it were local to the invoking client. Moreover, the introduction of infrastructure services provided by the container help to manage and offer such services to the deployed EJBs. These runtime services make it possible for the EJB developer to focus on writing robust and reliable applications.

The following summarizes the benefits gained by the enterprise and developers from using EJB technology:

• Simplicity: The EJB architecture simplifies the development of complex enterprise applications by providing built-in common services. This allows an EJB application developer to access and utilize these services, and results in a reduction of the overall development effort.

• Application portability: Portability can be accomplished by deploying an EJB application on any J2EE-compliant application server. Many Java application servers today implement all the services provided by J2EE-standard specifications.

• Component reusability: An EJB is a highly reusable building block. J2EE applications can be composed of custom-based EJBs, off-the-shelf EJBs, or both. In addition, the application business logic of a certain EJB can be reused through Java subclassing of the EJB class.

• Application partitioning: The separation of an application's business logic from its presentation allows ease of development and helps business programmers to work independently from Web page designers. Again, the separation of the application's business logic from its data helps manage each team independently. Any change of a component hosted in one tier does not affect the other tiers.

• Distributed applications: The EJB architecture helps create distributed applications, which can span multiple environments. Each subsystem can work independently of the others, but still can interact with one another to deliver enterprise services to the target users. A user transaction, for example, can be executed across multiple servers within a single context, and will be perceived by the user as a single unit of work.

• Application interoperability: The EJB architecture helps EJB components to access other components written in other component-based models, such as CORBA and .NET.

• Application integration: One of the main objectives of the EJB architecture is to allow the integration of new applications with existing applications, such as legacy systems. Today, Enterprise Application Integration (EAI) is a hot topic for the corporate world. The related J2EE APIs, such as the J2EE Connector Architecture (JCA) and the Java Message Service (JMS) specification, make it possible to integrate enterprise bean applications with various non-Java applications, such as ERP systems or mainframe applications, in a standard way.

• Availability of Java application servers: An enterprise has many J2EE-compliant application servers to choose from. Each application server provides J2EE services at a minimum, with the addition of other value-added services. A J2EE-compliant server can be selected to meet the customer's needs, which prevents vendor lock-in.

The most significant value provided by the EJB architecture is the separation of business logic programming from the challenge of integrating business logic with the complexities of enterprise-class server-side runtime environments. If the containers in which EJB components are deployed assume responsibility for managing runtime services such as persistence, transactions, and concurrent database access, bean developers are free to focus on developing software components that encapsulate business logic.

The EJB architecture is flexible enough to implement components such as the following:

• An object that represents a stateless service, which is modeled using a stateless session bean.

• An object that represents a stateless service whose invocation is asynchronous and driven by the arrival of enterprise messages. This is modeled by EJB with a message-driven bean.

• An object that represents a conversational session with a particular client. Such session objects automatically maintain their conversational state across multiple client-invoked methods. This is modeled by EJB with a stateful session bean.

• An entity object that represents a business object that can be shared among multiple clients, which is modeled with an entity bean.

• An entity object that represents a fine-grained persistent object that embodies the persistent state of a coarse-grained business object. This is also modeled with an entity bean.

EJB introduces the following flavors of beans (see Figure 1.2):

• Session beans, which are divided into stateless session beans and stateful session beans

• Entity beans, which are divided into bean-managed persistence and container-managed persistence

• Message-driven beans

Later in this book, you'll be provided with a more detailed explanation of each bean type. But for now, as a general rule, a session bean represents a user session (stateful or stateless), and implements the workflow of an arbitrary business process. An entity bean, on the other hand, represents a data row (record), in a database that can be accessed to satisfy user requests. Although both session and entity beans are synchronous in nature, message-driven beans are used to receive asynchronous messages, and process them accordingly.

EJB Design Goals

Since its inception by Sun Microsystems in 1997, the EJB architecture has had the following goals:

• To be the standard component-based architecture for building distributed object-oriented business applications in the Java programming language.

• To make it easy to write enterprise applications. Developers will not have to understand low-level transaction and state management details, multi-threading, connection pooling, and other complex low-level APIs.

• To enable an EJB to be developed once, and then deployed on multiple platforms without recompilation or source code modification.

• To address the development, deployment, and runtime aspects of an enterprise application's life cycle. Also, to define those contracts that enable tools from multiple vendors to develop and deploy components that can interoperate at runtime.

• To be compatible with existing server platforms and with other Java programming language APIs.

• To provide interoperability between EJBs and J2EE components as well as non-Java programming language applications.

• To be compatible with the CORBA protocols.