The EJB component model offers a framework for the seemingly disparate systems of today's servers without leaning toward one particular implementation. Here's how it works.
Reusability is and long has been a common theme in computing. Component models provide a consistent framework for software reuse. It is difficult to envision a component model that fits every problem context. The Enterprise JavaBean (EJB) specification is a standard for a component model specifically geared toward server-side Java tasks. By server-side Java, we are referring to tasks such as database connection, transaction control, persistence, fault tolerance, and caching. The EJB specification is the first attempt from Sun to address these types of activities and create a model for using Java in such environments.
If you look at the "server" world today, you will see middleware technologies, databases, traditional transaction processing monitors, CORBA, and other technologies. EJB is an attempt to provide a framework for these seemingly disparate systems without leaning towards one particular implementation. In fact, the EJB specification is intended mostly for vendors to make their products EJB compliant. It is not written for developers who want to create EJB components.
EJB is composed of three fundamental components. There are also a number of "auxiliary" components that complete the EJB model. The three core pieces of EJB are:
- The EJB server
- The EJB container
- Enterprise JavaBean
The auxiliary pieces of EJB are:
- Home interface
- Remote interface
- Deployment descriptor
- EJB-jar file
The EJB Server is a vendor-specific implementation which is responsible for providing the services necessary to host a container. Obviously, specialized containers require specialized EJB servers.
The EJB specification does not concern itself about how various services are implemented and whether a certain service is supported by all operating systems or not. It merely outlines what is expected of an EJB server and expects the implementation to provide that. In almost all cases, the implementation is vendor specific and most likely proprietary. That is okay, because Beans do not directly interact with the EJB server. They interact with the container. As long as the container meets the specification, it should be able to deploy any EJB that also conforms to the specification. The EJB server is typically implemented by extending an existing product, although there are some vendors that have started from ground zero and provide EJB servers.
The Bean is wrapped in a container. A container can hold one or more Beans and is responsible for providing the services required by the specification to each Bean requesting it. This is how EJB achieves conformity. It requires a minimal set of services to be provided by a container. This way, each Bean is guaranteed the same set of services regardless of the container in which it is running.
The specification allows for "specialized" containers. These are containers that provide more services than what is required by the specification. Such additional services are required to deploy specialized Beans. This is perfectly within the rules, but such Beans lose their portability, since they will only run inside containers that provide the specialized service they seek. This was a major compromise made by the designers of EJB so they could support a large percentage of existing systems. Furthermore, if there is anything in the EJB that can lead to implementation fragmentation and deviations, the specialized containers are it.
Enterprise JavaBeans are the components you write. They represent the business logic you need to implement. The container and the EJB server take care of details of transaction integrity and transaction control. Therefore, your EJB can focus mostly on the specific business function that it is implementing. EJBs come in two flavors: session Beans and entity Beans.
Regardless of their flavor, EJB methods are never directly invoked by the client. There is an intermediate EJBObject that intercepts method calls from the client and delegates them to the EJB. An EJB must obviously implement the business logic and make this available via a remote interface (again, the client does not call the EJB methods directly) . It must also implement an method, which is called by the container to create it (similar to how a class constructor works).
Session Beans must be supported in any EJB 1.0 compliant container, but support for entity Beans is optional. EJB 2.0 will mandate support for entity Beans as well. A session Bean is short-lived. Actually, it only lives during the session. It exists on behalf of a single client. Once the client terminates, the session Bean terminates. In case of an EJB server crash, all session Beans are destroyed. Clients must then reestablish new session Beans. Entity Beans are the counterpart to session Beans. They last typically longer than session Beans. They represent some data in the database so even when the EJB server crashes, the entity beans continue to exist. Well talk more about entity Beans after we complete the basic EJB architecture.
A client is a piece of the system that uses the Enterprise Bean. This could be a remote application or a tool that is used by the system administrator to manage the Beans. A mechanism is needed for a client to uniquely identify the Bean, to request creation of a Bean, and invoke the Bean's methods. The Home interface provides this functionality. The Home interface is actually defined by the Bean developer. It is implemented by the container. Typically, a tool is used to create a container class based on an enterprise JavaBean. One of the outputs of that tool is the implementation of a home interface. The home interface must extend
Additionally, the home interface must also include a method signature for creating the EJB instance. Note that the home interface must only provide the method signature. The actual implementation is done inside the Bean. So, for each signature, the Bean implements an . Argument counts and types determine the relationship between the method signature and the implementations.
The home interface is the key piece that allows a client to find, create, and remove an EJB. It is one of the interfaces that the container provides to the Bean. The other is a remote interface bundled inside an EJBObject.
The remote interface is based on the business logic inside the Bean. It is also generally generated by a tool provided by the container vendor. The remote interface is actually implemented by the EJBObject (also generated by a tool). While the home interface provides services for creating and destroying an EJB, the remote interface strictly deals with the business logic and methods provided by the Bean. This separation allows the EJB specification to separate business logic from EJB-specific functions. Each EJB must have a remote interface. The remote interface must extend javax.ejb.EJBObject.
The remote interface must provide the signatures for all the business methods supported by the Bean. The EJBObject implements these interfaces, and its implementation is merely a delegation to the actual Bean. This means that all client calls are handled by the EJBObject, not by the EJB itself. This provides another level of isolation for the Bean. The EJBObject intercepts all the calls before sending them to the Bean. Since the EJBObject is created by the tools provided by the container vendor, the container can make sure that "destructive" client requests are never passed to the Bean. It can also coordinate all calls to the Bean to insure transaction integrity and concurrency.
The deployment descriptor is another component of the EJB architecture that is typically generated by a tool. It is a serialized class instance that is shipped with every EJB. The deployment descriptor describes characteristics of the Bean to the container. Examples include the length of time before the session times out, transaction attributes for the Bean, and environment properties. This provides the information the container needs to host the Bean.
EJB jar file
The ejb-jar file is used to package EJB components and all EJB tools must support this format. The format is similar to JAR files used to package JavaBeans, and the concept is similar as well. A JAR file manifest describes the content of an ejb-jar file. All the Java classes that make up the Bean are also included in the ejb-jar file. Another important piece are the instructions for deployment of an enterprise Bean enclosed in the serialized deployment descriptor. The home interface and the remote interface are also included.
Putting it together
Given the above pieces, a typical interaction of a client with a session Bean would be as follows. The client uses JNDI (Java Naming and Directory Interface) to look up a particular Bean. Once found, the
method is used to create the EJBObject and the Bean itself. This part of the operation happens via the home interface. The client now has a handle to the EJBObject and can now invoke Bean-specific methods that are in turn delegated to the Bean itself. The Bean-specific methods are handled by the remote interface and the EJBObject. Once the client decides the Bean is no longer necessary, it will destroy it (again using the home interface).
Unlike session Beans, entity Beans are optional in EJB 1.0. They will likely be required in EJB 2.0, yet many vendors plan on implementing entity Beans with their servers. An entity Bean is shared among multiple clients and represents specific data. Entity Beans are transactional in nature and are persistent. An entity Bean represents an underlying data object or context, such as a record in the database or a connection to an application.
With entity Beans, the container maintains a pool of unused Bean instances. A primary key is used to uniquely identify an EJBObject. Clients can obtain the primary key by using the method implemented by the EJBObject. All EJBs will provide a primary key to their containers at the time they are created. A client can find a Bean by using its home interface to call the
. It can also find a Bean by using application specific primary keys. For example, the method in the home interface, corresponds to the method in the Bean itself.
When the client requests an entity Bean, the container searches the Bean instances inside a pool to see if a match is found. If one is found, then the Bean instance is taken out of the pool and an EJBObject is associated with it.
EJB is often praised for its support of complex transactions. This capability is built on top of the Java Transaction Service (JTS). It represents a subset of OTS 1.1 (CORBA transaction service). You will have to study JTS documents to learn about it. The EJB specification discusses how JTS works in the context of EJB. Transaction control for a Bean is specified in its deployment descriptor. Control can be specified for the entire Bean or for a particular method of the Bean. There are six types of transaction controls supported by EJB. They are:
- TX_NOT_SUPPORTED: existing transactions are suspended and no transaction can begin
- TX_SUPPORTS: will not start a transaction, but an existing transaction is not suspended
- TX_REQUIRED: will use an existing transaction, will start new a transaction, and commit when method completes
- TX_REQUIRED_NEW: always starts a new transaction, commits when completed, and suspends any existing transaction
- TX_BEAN_MANAGED: the Bean may use JTS interface to control the transaction itself
- TX_MANDATORY: must be called within a transaction
Sun's efforts in creating the Enterprise JavaBean specification takes a giant step toward not only a framework for server-based operations but also for promoting Java as a player in the heavy transaction-oriented back-end operations of an enterprise. The vendor community has embraced EJB with much enthusiasm and despite its young age, there are already a number of implementations available. In this article, we have provided an overview of the key parts of the EJB architecture and how they fit together.
The problem space that EJB addresses is inherently complex, but EJB provides a systematic way for developers to create complex applications by focusing on business logic rather than environmental and transactional issues. That combination should be a win-win situation for vendors, developers, and the enterprise alike.
About the author Piroz Mohseni is a senior managing consultant with Automated Concepts Inc. (ACI) in New York City. He specializes in enterprise Java, XML and e-commerce applications. You can contact him at: firstname.lastname@example.org.