The Enterprise JavaBeans architecture, Page 2
Home interfaceA 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.
Remote interfaceThe 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.
EJBObjectThe 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.
Deployment descriptorThe 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 fileThe 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 togetherGiven 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
Entity BeansUnlike 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.
Transaction supportEJB 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
ConclusionSun'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 authorPiroz 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.