EJB Assignment of Roles


The specification of Enterprise JavaBeans splits the responsibilities for development into various roles. The idea is to achieve a certain level of abstraction in the EJB model in order to encourage diversification through the allocation of concrete tasks to various expert groups and thereby achieve a synergistic effect. To put it another way, everyone should develop what he or she can best develop. Figure 3-8 provides an overview of the various roles and their interaction.

click to expand
Figure 3-8: EJB assignment of roles.

Server Provider

The server provider is responsible for the provision of basic server functions. It must ensure that a stable run-time environment is available to various containers (e.g., above all, EJB containers). This includes—as already mentioned in the previous chapter—the network connection, thread and process management, sizing (clustering), and resource management.

Container Provider

The container provider sits on top of the interfaces of the server provider and offers the components (Enterprise Beans) a convenient run-time environment. The implementation of a container provider must be in accordance with the conditions set forth in this chapter. It must ensure that accesses to an Enterprise Bean take place solely via the container, and the same holds for the Enterprise Bean's communication with its environment. Primarily, the container provider provides for persistence of components, mechanisms for dealing with transaction-oriented processes, security features, resource pooling, and support for making available versions of components (this last feature is not more precisely defined in the specification). For beans to be installed in a container, the container provider must make available tools that enable the bean deployer (see below) to generate the necessary interface code (EJBHome and EJBObject). The container provider must make tools available to the system administrator for monitoring the container and the beans.

Persistence Manager Provider

The persistence manager provider must provide tools with which the code needed for the persistence of a container-managed entity bean can be generated. The tools are used when an Enterprise Bean is installed in a particular container. The persistence manager provider is typically a specialist in the area of databases. It is therefore necessary that the following conditions hold:

  • The state of an entity bean is stored with container-managed persistence in the database.

  • The referential integrity of the entity bean is ensured with respect to other entity beans to which it is related.

Since the EJB container governs the persistence of an entity bean (that is, it determines, for example, when the state should be saved), an interface between container and persistence manager is necessary. The specification leaves it to the container and persistence manager providers to define such an interface.

Bean Provider

The role of the bean provider belongs to those developers who implement the actual business logic. They package their application knowledge into components that make this knowledge reusable. Building on the products of the server and container providers, the bean developer is freed from the development of basic server tasks (such as multithreading, network connection, transactions). Therefore, such a developer can devote his or her complete energy to the task at hand. In addition to the component, the bean provider provides the deployment descriptor, which contains information about the component itself, as well as about its external dependencies (e.g., on what services from the server the component depends). The deployment descriptor (an extensive example was presented in Listing 3-5) provides all information that the bean deployer (to be discussed shortly) requires for installing the component in a server.

The application assembler (see the next heading) also needs this information in order to assemble applications or modules of an application from various components. The result of the work of a bean provider is a file in JAR (Java Archive) format that contains the bean class(es) and the interfaces of the bean(s) as well as the deployment descriptor.

Application Assembler

Finally, the application assembler is responsible for linking the functionalities of the beans installed in the container to applications. To this can belong the development of client applications and the associated control of information exchange with the Enterprise Beans. The application assembler can, however, also assemble several (smaller) components provided by bean providers into a new (larger) component. The application assembler can enlarge this conglomerate with its own Enterprise Beans, whose task consists, for example, in the coupling of other Enterprise Beans. The resulting "supercomponents" already represent an aspect of a concrete application.

The application assembler documents its work, just like the bean provider in the deployment descriptor. Thereby the bean deployer (see the next section) understands how to install the components so that from the individual building blocks a complete application results. Additionally, the application assembler can provide instructions and information for the bean deployer in regard to the user interface or dependencies on non-EJB components in the deployment descriptor.

Bean Deployer

To install the components selected for a particular business problem in a container is the task of the bean deployer. To this belongs, above all, the provision of the tools of the container and persistence manager providers as well as the correct parameterization of the components to be installed. This operation assumes an extensive knowledge of the application and system contexts as well as of the internal system linkages. In particular, the deployer must resolve the external dependencies defined in the deployment descriptor (for example, by ensuring the existence of required services or related Enterprise Beans) and take into account the instructions of the application assembler contained in the deployment descriptor.

System Administrator

The system administrator monitors the EJB server with the assistance of the tools provided by the producer and takes care of the operation of the required infrastructure (e.g., for an operational network) of an EJB server.

The EJB assignment of roles represents an ideal scenario, and the translation of the EJB specification into practice will show whether it can be maintained in this form. Thus today servers and containers are offered in a single product. The Java-2 platform, Enterprise Edition (J2EE), already provides a variety of containers (at least an EJB container and a web container) for an application server. In the meantime, the specification of Enterprise JavaBeans assumes that server and container are always offered by the same producer and cannot be exchanged for others. The same holds for the persistence manager. As long as the specification defines no protocol between EJB containers and persistence managers, both will be offered in a single product.

This role-playing is supremely adapted (in theory) to component-oriented software, at least from the point of view that one is dealing with a number of individuals. Thus a container provider (a container is, after all, a type of component) does not know during development what beans will later be put into this container. Nor does a bean provider know at the time of development to what purpose those components will later be used. The provider merely packs a well-rounded functionality into a component with the goal of optimal reusability. If the correct components have been installed and parameterized by the bean deployer, then it is simple for the application assembler to link the functionality that is offered to applications or to create modules out of available components. The work of the application assembler is, moreover, not bound temporally to the work of the bean deployer. The application assembler can use, via the deployer, already installed components, or can transmit "supercomponents" that have assembled to the deployer for installation.

The roles of the server and container providers are intended for system specialists, who provide a stable basis. For an application developer (such as described in the introductory chapter, "Motivation") there are a variety of approaches. One could slip into the role of the bean provider by encapsulating one's knowledge into beans and then installing them in a purchased application server that offers an EJB container. Or instead, one could leaf through the catalog of a software manufacturer and look for components that offer a solution to one's problem(s). One's task would then be limited to installing the purchased beans on the server and correctly parameterizing them (corresponding to the role of the bean deployer).

In the next step our developer (or a colleague) could write an application using the installed beans that takes over the interaction between the user and the communication with the components (application assembler, limited to the development of the client scenario).

In any case, one thing is clear to the application developer (above all in the role of the bean provider): He or she can concentrate fully on the solution to his or her problems. Technical problems such as the implementation of a stable, efficient, and scalable server are taken over by the server and container providers.

In the rest of this book we shall for the most part restrict our attention to the roles of the bean provider, the bean deployer, and the application assembler.




Enterprise JavaBeans 2.1
Enterprise JavaBeans 2.1
ISBN: 1590590880
EAN: 2147483647
Year: 2006
Pages: 103

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net