The EJB Container

The EJB container is a run-time environment for Enterprise Bean components. Just as an EJB container is assigned to the server as a run-time environment and service provider, a bean is dependent on its EJB container, which provides it a run-time environment and services. Such services are provided to the bean via standard programming interfaces. The specification in version 2.1 obliges the EJB container to provide at least the following programming interfaces:

• The API (Application Programming Interface) of the Java 2 platform, Standard Edition, in version 1.4;

• The API of the specification of Enterprise JavaBeans 2.1;

• The API of JNDI 1.2 (Java Naming and Directory Interface);

• The UserTransaction API from JTA 1.0.1 (Java Transaction API);

• The API of the JDBC 2.0 extension (Java Database Connectivity);

• The API of JMS 1.1 (Java Message Service);

• The API of Java Mail 1.3 (for sending e-mail);

• The API of JAXP 1.1, 1.2 (Java XML Parser);

• The API of JAXR and JAX-RPC 1.0 (Java XML Remote Procedure Calls);

• The API of Java Connectors 1.5;

• The API of Java Web Services 1.0.

A provider of a Java application server may offer additional services via the standard interface. Some producers offer, for example, a generic service interface particular to the producer by means of which specially developed services (such as a logging service or user management) can be offered. If an Enterprise Bean uses such proprietary services, then it cannot simply be placed in any available container.

The EJB container provides Enterprise Beans a run-time environment, and also offers the Enterprise Beans particular services at run-time, via the above-mentioned (static) programming interfaces. We now would like to examine the most important aspects of both domains (that of the run-time environment as well as that of provided services).

Control of the Life Cycle of a Bean (Run-Time Environment)

The EJB container is responsible for the life cycle of a bean. The EJB container generates bean instances (for example, when a client requests one), deploys them in various states via callback methods, and manages them in pools in case they will not be needed until a later time. The bean instances are also deleted by the EJB container. The states and respective methods that lead to a state transition depend on the type of bean. They are discussed in detail in Chapter 4, "Session Beans"; Chapter 5, "Entity Beans"; and Chapter 6, "Message-Driven Beans."

Instance Pooling (Run-Time Environment); Activation and Passivation

A system that supports mission-critical applications must be capable of dealing with great demands. It must be capable of serving a large number of concurrent clients without them having to put up with long response times. The greater the number of clients, the greater generally the number of objects generated in the server.

In order to keep the number of bean instances from growing without bound and to prevent bean instances from continually being created and then destroyed, an EJB container maintains a certain number of bean instances in a pool. As long as a bean is in the pool, it is in a Pooled state and is to a certain extent deactivated. On demand (as a rule, as a result of a client request) the first available bean instance of the requisite type is taken from the pool. It is reactivated and placed in a Ready state.

Such instance pooling is common practice in database applications. This practice has also proved itself in the management of thread objects (such as in server development). With pooling, fewer bean instances than the number of client connections are needed, as a rule. By avoiding permanent object generation and destruction, system performance is enhanced. Instance pooling is closely connected with the life-cycle management of a bean. Finally, we note that the specification does not obligate an EJB container to support instance pooling.

A further possibility for the EJB container to save system resources is to make Enterprise Bean instances that are currently not needed (for example, from object serialization) persistent and to remove them from memory (passivation). Upon demand these instances can again be deserialized and made available in memory (activation). Such a temporary storage of bean instances (those, for example, for which a certain time period has expired) on secondary media can reduce the burden on system memory resources. This behavior is similar to that of an operating system page file.

Whether bean instances can be pooled, activated, or passivated depends on their type. In the description of bean types in what follows we shall make the necessary distinctions.

Distribution (Run-Time Environment)

The EJB container ensures that Enterprise Beans can be used by client programs, which as a rule are not running in the same process. The client does not know on what server the Enterprise Bean that it is currently using is located. Even when an Enterprise Bean uses another Enterprise Bean, it is a client. The place where the Enterprise Bean exists is transparent to the client. The use of an Enterprise Bean on another computer is not essentially different for the client from the use of objects that are located in the same address space.

For distributed communication between the various parties, Java Remote Method Invocation (Java RMI) is used. To achieve interoperability among application servers supplied by different manufacturers the EJB specification prescribes support for the communications protocol of the CORBA specification, IIOP, for an EJB container that conforms to specifications. Distributed communication thus takes place over the protocol RMI-IIOP (RMI over IIOP). In no case does the developer of an Enterprise Bean have to worry about the bean being able to be accessed from outside. This is the sole task of the EJB container.

This book assumes that the reader is already familiar with the techniques of remote method invocation (or else see [13] and [4] for information on RMI). In particular, the reader should understand the notions of stub and skeleton.

Since version 2.0 of the Enterprise JavaBeans specification the client has had the ability to communicate with an Enterprise Bean via the Local interface. In many applications it is necessary that Enterprise Beans, all of which are installed in the same EJB container (aggregation of components), communicate with one another. In version 1.1 of the EJB specification this means a remote call to a component located in the same address space. The overhead of the RMI protocol is unnecessary, and it leads to a degradation of performance. The advantage of using local interfaces is that RMI is thereby completely ignored. Local interfaces can then be sensibly used only if client and Enterprise Bean are located in the same address space of a Java virtual machine. The location of the Enterprise Bean is thus no longer transparent to the client. Transparency of location applies only to EJB components that are called over the remote interface. Furthermore, the semantics of a method call to a component are altered when a local interface is used. With calls to the local interface, parameters are passed via call by reference, while calls to the remote interface use call by value.

The various chapters on various types of beans will deal extensively with the difference between the remote and local interfaces and will delve deeply into the viewpoint of the client with respect to an Enterprise Bean.

Naming and Directory Service (Service)

If a client wishes to find a bean, it is directed to a naming interface. A naming service offers the possibility of associating references to removed objects under a particular name, which may be assigned arbitrarily, at a definite place (binding). It also offers the possibility of looking up the object bound to the naming service under that name (lookup). This is similar to the white pages, whereby one looks up an object by name.

A directory service is more powerful than a naming service. It supports not only binding of references to a name, it can also manage distributed objects and other resources (such as printers, files, application servers) in hierarchical structures, and it offers wide-ranging possibilities for administration. With a directory service a client can be provided with additional descriptive information about a reference to a remote object. This is similar to the yellow pages, whereby one looks up an object by its attributes.

The interface over which the naming and directory services are accessed is JNDI (Java Naming and Directory Interface). The bean, too, can receive information via the naming and directory service. The EJB container provides the bean instance information, for example, that was established at the time of installation of the component (so-called environment entries). In this way it is possible to influence the behavior of Enterprise Beans by external parameterization. The bean also has the possibility of accessing particular resources, such as database connections or a message service, via the naming and directory services.

Persistence (Service)

The EJB container provides the beans, via the naming and directory services, the possibility of accessing database connections. Beans can thereby themselves ensure that their state is made persistent. However, the specification of Enterprise JavaBeans provides for a mechanism by which the state of certain Enterprise Bean types can be made persistent automatically. (We shall return to this mechanism in Chapter 5, "Entity Beans.")

As a rule, in the case of automatic storage of the state of Enterprise Beans by the EJB container the data are made persistent in a database. One can imagine other EJB containers that provide persistence mechanisms that place the data in other storage systems (for example, in the file system or electronic archives). There is also the possibility of developing EJB containers that make use of the interfaces of other application systems in order to read or write data from or to that location. Thus, for example, the data in an old main-frame system can be bound by means of special EJB containers to component-oriented systems (the container then acts to a certain extent as a wrapper for the old systems).

However, what is really at issue is that in the case of automatic persistence of an Enterprise Bean, the bean couldn't care less where the data are stored. The EJB container takes on the task of ensuring that the data are stored and remain in a consistent state. Thus a particular bean can be installed in various EJB containers that support varying storage systems as persistence medium. For the Enterprise Bean the persistence remains transparent. It doesn't know where its data are stored or where the data come from that the EJB container uses to initialize it.

Transactions (Service and Run-Time Environment)

Transactions are a proven technique for simplifying the development of distributed applications. Among other things, transactions support the applications developer in dealing with error situations that can occur from simultaneous access to particular data by multiple users.

A developer who uses transactions splits up the actions to be executed into atomic units (transactions). The transaction monitor (the EJB container) ensures that the individual actions of a transaction are all executed successfully. If an action fails, the successful actions thus far executed are canceled.

The support of transactions is a fundamental part of the specification of Enterprise JavaBeans. In distributed systems in which several users work simultaneously on many separate actions with the same data (which may be distributed among several back-end systems), a transaction service on the level of the application server is unavoidable. It is the task of the EJB container to ensure that the necessary protocols (for example, the two-phase commit protocol between a transaction monitor and a database system, context propagation, and a distributed two-phase commit) for handling transactions are available. The specification of Enterprise JavaBeans supports flat transactions; that is, transactions cannot be nested.

The developer of an Enterprise Bean can choose how he or she wishes to use transactions. On the one hand, transactions can be used explicitly, by communicating over JTA directly with the transaction service of the EJB container. Alternatively, the developer can opt for declarative (or implicit) transactions. In this case, at the time of installation of an Enterprise Bean in the EJB container it is specified what methods should run within which transactions. The EJB container intervenes when these methods are called, and it ensures that they are called within the appropriate transaction context.

In the case of declarative transactions the bean developer does not need to be concerned with manipulating the transactions. During installation in EJB container A, a bean can be installed with a completely different transactional behavior from that during installation in EJB container B. The bean itself remains untouched in each case, since in every case the container remains responsible for guaranteeing the desired transactional behavior. Much more detail on transactions in the EJB context is to be found in Chapter 7, "Transactions."

Message (Service)

With version 2.0 of the specification of Enterprise JavaBeans the EJB container is obligated to integrate a message service via JMS-API (Java Message Service). With the definition of a new bean type—the message-driven bean—the message service is integrated into the EJB container in a significant way. The development of applications based on Enterprise JavaBeans thus gains two additional dimensions: asynchronicity and parallel processing.

Basically, a message system enables the asynchronous exchange of messages among two or more clients. In contrast to the case of a client-server system, here the architecture of a message system is designed around a loose coupling of equal partners. Each client of the message system can send and receive messages asynchronously. The sender of a message remains largely anonymous, and the same holds for the recipient. Message systems are also known under the name message-oriented middleware (MOM).

In addition to the use of message-driven beans, the message service can, of course, also be used for asynchronous message exchange between any two parties. Enterprise Beans, like clients, can also send messages. Through the use of messaging, processes can, for example, decouple from each other or even create interfaces to other systems, making it an excellent component for enterprise integration.

Chapter 6 offers a fuller discussion of Java Message Service message-driven beans.

Security (Run-Time Environment)

The specification obligates the EJB container to provide Enterprise JavaBeans an infrastructure for security management as a part of the run-time environment. It is the task of the system administrator and of the installer of the Enterprise Beans to establish security policy. Once again, the EJB container is responsible for the implementation of this security policy. The goal here is (as with container-managed automatic persistence and declarative transactions) to make the security mechanisms transparent to the Enterprise JavaBeans, so that they can be deployed in as many systems as possible.

If the security strategy were implemented in the bean, it would be problematic to employ the same bean under both more-and less-strict security requirements. On the other hand, it makes much more sense to place the security mechanisms in the run-time environment of the components. They are thereby reusable to a great extent, and the security policy can be adapted from the outside as the situation warrants. The specification of Enterprise JavaBeans specifically mentions that it is preferable that no logic relating to security be present in the code of a bean.

It is possible to define user roles. In every Enterprise Bean particular permissions can be assigned to a particular role. The assignment takes place, as with the establishment of the user roles, at one of the following times:

• The time of bean installation;

• The time at which several beans are combined into an aggregate.

Permissions are focused essentially on whether the user is permitted to call particular methods of an Enterprise Bean. At run time the EJB container determines whether a client call to a bean method should be allowed to be executed. To this end it compares the role of the client with the permissions of the respective Enterprise Bean method.

As a rule, in addition to the security mechanisms that we have described, an EJB container offers the following security attributes:

• Authentication of the user by a user ID and password;

• Secure communication (for example, via the use of secure socket layers).

Chapter 8 contains a more detailed discussion of security in relation to Enterprise JavaBeans.

Finally, we note that the EJB container is the central instance in the component model of Enterprise JavaBeans. It provides the Enterprise Beans (the components) a convenient run-time environment at a very high level of abstraction and makes a variety of services available by way of standard interfaces.