Gopalan Suresh Raj's Web Cornucopia
An Oasis for the parched Enterprise Services Engineer/Developer

    Container Managed Models-Enterprise JavaBeans - Part 2


    The EJB Model

    A basic EJB architecture is shown in Figure 2 and consists of:

    • An EJB server
    • EJB containers that run within the server
    • Home objects, remote EJBObjects, and enterprise beans that run within containers
    • EJB clients
    • Auxiliary systems like JNDI, JTS, security services, and so forth.

    Figure 2: The basic Enterprise JavaBean architecture

    Figure 2: The basic Enterprise JavaBean architecture

    Now, let’s examine the primary components of the EJB architecture in greater detail:

    EJB Server

    The EJB server provides an organized framework or execution environment in which EJB containers can run. It makes available system services for multiprocessing, load balancing, and device access for EJB containers. The EJB server also makes EJB containers running within them visible to the outside world. It may also provide vendor-specific features like an optimized data access interface, additional CORBAServices, SSL support, a JNDI-accessible naming service, and transaction management services.

    In some respects, the EJB server is analogous to CORBA’s Object Transaction Monitor (OTM). The OTM, too, provides an execution framework for running server side CORBA components.

    EJB Containers

    An EJB container acts as the interface between an enterprise bean and low-level, platform-specific functionality that supports the bean. In essence, the EJB container is an abstraction that manages one or more EJB classes, while making the required services available to EJB classes through standard interfaces as defined in the EJB specification. The container vendor is also free to provide additional services implemented at either the container or the server level. An EJB client never accesses a bean directly. Any bean access is done through the methods of the container-generated classes, which, in turn, invoke the bean’s methods.

    Having the container interpose on all bean invocations allows the container to manage transactions, load bean instances, if necessary, and, in general, to do all the wonderful things EJBs do.

    Two types of containers exist: session containers that may contain transient, nonpersistent EJBs whose states are not saved and entity containers that contain persistent EJBs whose states are saved between invocations.

    The Home Interface and Home Object

    Factory methods for locating, creating, and removing instances of EJB classes are defined in the home interface. The home object is the implementation of the home interface. The EJB developer first has to define the home interface for his bean. The EJB container vendor provides tools that automatically generate the implementation code for the home interface defined by the EJB developer.

    The Remote Interface and EJBObject

    The remote interface lists the business methods available for the enterprise bean. The EJBObject is the client’s view of the enterprise bean and implements the remote interface. While the enterprise bean developer defines the remote interface, the container vendor provides the tools necessary to generate the implementation code for the corresponding EJBObject. Note, however, the EJB container is still responsible for managing the EJBObject. Each time the client invokes the EJBObject’s methods, the EJB container first handles the request before delegating it to the Enterprise Bean.

    The Enterprise JavaBean

    The real enterprise bean itself is contained within an EJB container and should never be directly accessed by anyone but the container. Although direct access may be possible, this is inadvisable as it breaks the contract between the bean and the container.

    The EJB container should mediate all enterprise bean accesses. For this reason, the enterprise bean developer does not implement the remote interface within the enterprise bean itself. The implementation code for the remote interface is generated automatically by tools the container vendor provides, in the form of the EJBObject. This prevents inadvertent direct accesses from clients or other beans.

    The EJB Clients

    EJB clients locate the specific EJB container that contains the enterprise bean through the Java Naming and Directory Interface (JNDI). They then make use of the EJB container to invoke bean methods. The EJB client only gets a reference to an EJBObject instance and never really gets a reference to the actual Enterprise Bean instance itself. When the client invokes a method, the EJBObject instance receives the request and delegates it to the corresponding bean instance while providing any necessary wrapping functionality.

    The client uses the home object to locate, create, or destroy instances of an enterprise Bean. It then uses the EJBObject instance to invoke the business methods of a bean instance.

    The EJB Lifecycle

    In any enterprise development scenario, numerous complex programming issues are usually involved, which require the involvement of multiple domain experts. Without addressing all these issues and cohesive team-oriented approaches, it is impossible to create successful enterprise applications. To ease enterprise development, the EJB specification assigns responsibilities or roles. The EJB specification also specifies who is responsible for delivering what in an enterprise application that uses EJBs, as shown in Figure 3. Note, the EJB specification does not necessarily preclude the same person from carrying out more than one role.

    Figure 3: The lifecycle of a typical enterprise JavaBean

    Figure 3: The lifecycle of a typical enterprise JavaBean

    Let’s take a closer look at the different roles the EJB specification defines in greater detail:

    EJB Server Provider

    The EJB server provider provides an organized application framework in which to run the EJB containers. The EJB server vendor implements and provides access to a JNDI-compatible naming service and a transaction service that is CORBA-OTS-compatible. Note, the EJB server vendor might also act as the EJB container vendor.

    EJB Container Provider

    The EJB container provider provides software to install an EJB with its supporting classes on an EJB server. The container vendor is also responsible for providing run-time classes that provide the required services to the EJB instances. These include the generation of stub and skeleton classes to provide access to the EJB instance’s home object and EJBObject, installation of references to the home object in a JNDI-accessible namespace. Additionally, it also has to make available a suitable EJBObject implementation that can provide correct proxy services for the enterprise Bean class.

    EJB Developer

    The EJB developer should have knowledge not only of the EJB specification, but also business needs because she or he is responsible for coding the business logic into server-side components. Basically, the developer implements EJB classes that focus on the business logic using the classes and interfaces defined in the EJB specification.

    While the EJB container is responsible for handling all the transaction controls on behalf of the EJB instance, the EJB developer must understands how transactions work. Consequently, the developer is responsible for stipulating the transactional needs of the various methods in the EJB class to the EJB deployer. The EJB specification calls the EJB developer, the enterprise Bean provider.

    EJB Deployer

    Although the EJB deployer may not be a Java developer or understand the business rules an EJB class implements, he or she should understand the application framework in which the EJB instance runs. Additionally, the deployer should have an in-depth understanding of the characteristics of the run-time server environment, such as database types, its location, and so forth. The deployer is responsible for taking the EJB and all its supporting classes and installing them correctly on the EJB server.

    The deployer gets the EJB class requirements from the EJB developer, such as transactional needs, names, and descriptions of the required environment properties, and so forth. The deployer is responsible for making these properties, along with their correct run-time values, available to the EJB class at runtime. The deployer also has to ensure the home object for the EJB class is available in the namespace and is accessible through JNDI. The deployer and the developer must communicate clearly to ensure the EJB class is deployed with the correct deployment attributes.

    Application Developer

    The application developer writes the client applications using pre-built EJB components. Here, a client is defined generally and can be a Java application, applet, servlet, a CORBA application, or even an ActiveX control connecting through a COM-CORBA bridge.

    The application developer can thus plug-in ready-made EJBs without having to develop or test them, or without having any internal knowledge of how to integrate them. This frees the application developer to concentrate on high-level functionality, such as data presentation, without having to worry about how such data is actually obtained. The EJB specification calls the application developer, the application assembler.

    Author Bibliography

    Gopalan Suresh Raj is a Senior Analyst, Software Architect, and Developer with expertise in multi-tiered systems development, enterprise service architectures, and distributed computing. He is also an active author, including contributions to Professional JMS Programming, Wrox Press, 2001, Enterprise Java Computing-Applications and Architecture, Cambridge University Press, 1999, and The Awesome Power of JavaBeans, Manning Publications Co., 1998. He has submitted papers at international fora, and his work has been published in numerous technical journals. Visit him at his Web Cornucopia© site ( or mail him at