The environment that surrounds the beans on the EJB server is often referred to as the container. The container is more a concept than a physical construct. Conceptually, the container acts as an intermediary between the bean class and the EJB server. The container manages the EJB objects and EJB homes for a particular type of bean and helps these constructs to manage bean resources and apply primary services like transactions, security, concurrency, naming, and so forth, to the bean instances at runtime. Conceptually, an EJB server may have many containers, each of which may contain one or more types of enterprise beans. As you will discover a little later, the container and the server are not clearly different constructs, but the EJB specification defines the component model in terms of the container responsibilities, so we will follow that convention here.
Enterprise bean components interface with the EJB server through a well-defined component model. The EntityBean and SessionBean interfaces are the bases of this component model. As we learned earlier, these interfaces provide callback methods that notify the bean class of state management events in its life cycle. At runtime, the container invokes the callback methods on the bean instance when appropriate state management events occur. When the container is about to write an entity bean instance's state to the database, for example, it first calls the bean instance's ejbStore() method. This provides the bean instance with an opportunity to do some clean up on its state just before it's written to the database. The ejbLoad() method is called just after the bean's state is populated from the database, providing the bean developer with an opportunity to manage the bean's state before the first business method is called.[2] Other callback methods can be used by the bean class in a similar fashion. EJB defines when these various callback methods are invoked and what can be done within their context. This provides the bean developer with a predictable runtime component model.
[2] The ejbLoad() and ejbStore() behavior illustrated here is for container-managed persistence. With bean-managed persistence the behavior is slightly different. This is examined in detail in Chapter 6, "Entity Beans".
While all the callback methods are declared in bean interfaces, a meaningful implementation of the methods is not mandatory. In other words, the method body of any or all of the callback methods can be left empty in the bean class. Beans that implement one or more callback methods are usually more sophisticated and access resources that are not managed by the EJB system. Enterprise beans that wrap legacy systems often fall into this category.
javax.ejb.EJBContext is an interface that is implemented by the container and is also a part of the bean-container contract. Entity type beans use a subclass of javax.ejb.EJBContext called javax.ejb.EntityContext. Session beans use a subclass called the javax.ejb.SessionContext. These EJBContext types provide the bean class with information about its container, the client using the bean, and the bean itself. They also provide other functionality that is described in more detail in Chapter 6, "Entity Beans" and Chapter 7, "Session Beans". The important thing about the EJBContext types is that they provide the bean with information about the world around it, which the bean can use while processing requests from both clients and callback methods from the container.
NOTE
EJB 1.1 has expanded the bean's interface with the container to include a JNDI name space, called the environment context, which provides the bean with a more flexible and extensible bean-container interface. The JNDI environment context is discussed in detail later in this book.
The container-server contract is not defined by the Enterprise JavaBeans specification. This was done to facilitate maximum flexibility for vendors defining their EJB server technologies. Other than isolating the beans from the server, the container's responsibility in the EJB system is a little vague. The EJB specification only defines a bean-container contract and does not define the container-server contract. It is difficult to determine, for example, exactly where the container ends and the server begins when it comes to resource management and other services.
In the first generation of EJB servers this ambiguity was not a problem because most EJB server vendors also provide EJB containers. Since the vendor provides both the container and the server, the interface between the two can remain proprietary. In future generations of the EJB specification, however, some work may be done to define the container-server interface and delimit the responsibilities of the container.
One advantage of defining a container-server interface is that it allows third-party vendors to produce containers that can plug into any EJB server. If the responsibilities of the container and server are clearly defined, then vendors who specialize in the technologies that support these different responsibilities can focus on developing the container or server as best matches their core competency. The disadvantage of a clearly defined container-server interface is that the plug-and-play approach could impact performance. The high level of abstraction that would be required to clearly separate the container interface from the server, would naturally lead to looser binding between these large components, which always results in lower performance. The following rule of thumb best describes the advantages and disadvantages associated with a container-server interface: the tighter the integration, the better the performance; the higher the abstraction, the greater the flexibility. The biggest deterrent to defining a container-server interface is that it would require the definition of low-level facilities, which was one of the problems that established CTM vendors had with CORBA. Allowing vendors to implement low-level facilities like transactions and security as they see fit is one of EJB's biggest attractions for vendors.
Many EJB-compliant servers actually support several different kinds of middleware technologies. It's quite common, for example, for an EJB server to support the vendor's proprietary CTM model as well as EJB, servlets, web server functionality, and other server technologies. Defining an EJB container concept is useful for clearly distinguishing what part of the server supports EJB from all the other services it provides.
This said, we could define the responsibilities of containers and servers based on current implementations of the EJB specification. In other words, we could examine how current vendors are defining the container in their servers and use this as a guide. Unfortunately, the responsibilities of the container in each EJB server largely depend on the core competency of the vendor in question. Database vendors, for example, implement containers differently from TP monitor vendors. The strategies for assigning responsibilities to the container and server are so varied that it would provide little value in understanding the overall architecture to discuss the container and server separately. Instead, this book addresses the architecture of the EJB system as if the container and server were one component.
The remainder of this book treats the EJB server and the container as the same thing and refers to them collectively as the EJB server, container, system, or environment.
 |  |  |
| 2.2. Using Enterprise Beans |  | 2.4. Summary |
Copyright © 2001 O'Reilly & Associates. All rights reserved.