3.1 EJB Roles

The EJB architecture defines six distinct roles in the application development and deployment life cycle. A role may be fulfilled by a single individual or by an organization. The opposite may also occur, depending on the environment; a single party may perform several EJB roles. For example, the EJB container provider and the EJB server provider are typically the same vendor. Or one programmer may perform the two EJB roles of enterprise bean developer and application assembler. Figure 3.1 illustrates how the six roles defined by the EJB architecture may interact when developing and deploying an EJB application in a typical enterprise environment.

Figure 3.1. EJB Roles in an Enterprise Environment

Usually, at least several distinct parties are responsible for these six roles, and these roles or the functional areas they represent are interdependent. Therefore, the EJB architecture specifies a contract, or set of requirements, for each role. These requirements ensure that the product of one EJB role is compatible with the product of the other EJB roles.

How do typical enterprise software people fit in with the EJB architecture roles? That is, how do "traditional" information systems individuals and ISVs fit into EJB roles? In the EJB environment, a "traditional" application programmer becomes an enterprise bean developer and, possibly, an application assembler. Both are responsible for focusing on the business problem of their enterprise environment and for developing the business logic solutions. The EJB tasks defined for a bean developer and an assembler allow that person to focus on the business problem and business logic.

The EJB container and server providers focus on the development of a scalable, secure, and manageable infrastructure used for the deployment of the applications created by the bean developers and application assemblers. In this book, the term EJB container often refers collectively to both the EJB container and the EJB server. The system administrator takes the container product from the EJB container provider and installs it in the enterprise's operational environment.

The deployer defines and sets the deployment policies for individual enterprise applications. The deployer also integrates the applications with the existing operational environment.

3.1.1 Bean Developer

The bean developer is the programmer who writes and produces enterprise beans. The bean developer may

• Work for an ISV that produces enterprise beans components or applications that are comprised of enterprise beans

• Work within a corporate enterprise environment

• Be an application integrator

The bean developer starts with a perceived or existing business problem requiring a solution. For example, an ISV may perceive a need for a generic application to view and modify employee benefits, or an enterprise may want to implement its own application for managing benefits. It is the bean developer who develops reusable enterprise beans that implement business processes or business entities and that provide a solution to the business problem. A bean developer of multiple enterprise beans often performs the role of the application assembler (Section 3.1.2) by specifying how the enterprise beans are assembled that is, how they should work together.

Typically, a bean developer is an expert in the application domain, such as finance or manufacturing. The bean developer implements the business processes and entities. Essentially, the bean developer is responsible for writing the enterprise beans that implement the business processes and entities. The business processes and entities are implemented in the Java language in the form of the enterprise bean classes.

The bean developer also defines the bean's client-view interfaces and the bean's deployment descriptor. The deployment descriptor includes enterprise bean structural information, such as the name of the enterprise bean class. The deployment descriptor also declares all the enterprise bean's external dependencies, which are the names and types of the resource managers used by the enterprise bean. The bean developer outputs an ejb-jar file that contains one or more enterprise beans. An ejb-jar file is a JAR file that contains enterprise beans with their deployment descriptors.

Because the EJB container manages system-level tasks, the bean developer need not be concerned about the distribution, transaction, security, and other non-business-specific aspects of the application. This means that the bean developer is neither required to be an expert at system-level programming nor to program into the enterprise bean such services as transactions, concurrency, security, and remote distribution. The bean developer relies on the EJB container to handle or provide these services.

3.1.2 Application Assembler

The application assembler combines enterprise beans into larger, deployable application units. In a sense, the application assembler composes the application, identifying an application's required pieces and specifying how they fit together so that the application runs successfully.

Applications typically consist of numerous pieces and components. Often, an application requires multiple enterprise beans to carry out its business logic. In our example, one enterprise bean handles the logic for accessing employee data, and another enterprise bean focuses on the logic for benefits information. The application often requires other non enterprise bean pieces, in addition to the enterprise beans components. The application assembler must identify these pieces and combine them with the enterprise beans into the application.

Like the bean developer, the application assembler is also an application domain expert. However, the application assembler focuses on the enterprise bean's deployment descriptor and the enterprise bean's client-view contract. Although the application assembler must be familiar with the functionality provided by the enterprise beans, an intimate knowledge of the implementation of the enterprise beans is not needed.

The application assembler takes as input one or more ejb-jar files produced by the bean developer or developers. The application assembler adds the assembly instructions and outputs one or more ejb-jar files that contain the enterprise beans and their application assembly instructions. For example, the application assembler may take an ejb-jar file that contains the TransferEJB session bean and another ejb-jar file that contains the AccountEJB entity bean and may produce a new ejb-jar file that contains both enterprise beans. The deployment descriptor of the new ejb-jar file includes the linkage between the TransferEJB bean and the AccountEJB bean.

When composing an application, the application assembler can also combine enterprise beans with other types of application components, such as Web applications. For more information on using other types of application components, refer to the J2EE publications listed in the preface.

If you are familiar with the EJB specification, you may have noted that it describes the case in which the application assembly step occurs before the deployment of the enterprise beans. However, the application assembler can assemble the application after the deployment of all the enterprise beans or the deployment of some of the beans. The EJB architecture does not preclude the case of performing application assembly after the deployment of all or some of the enterprise beans.

3.1.3 Deployer

The deployer's job is to deploy enterprise beans in a specific operational environment that includes a specific EJB server and container. The deployer receives enterprise beans in one or more ejb-jar files produced by a bean developer or application assembler. The deployer, who has expert knowledge of the specific EJB container and operational environment, then customizes these beans for the target operational environment. Finally, the deployer deploys these customized enterprise beans or an entire assembled application that includes enterprise beans in a specific EJB container or in multiple containers on the enterprise network.

As part of the deployment process, the deployer must resolve all the external dependencies declared by the bean developer. For example, the deployer must ensure that all resource manager connection factories are present in the operational environment and must bind them to the resource manager connection factory references declared in the deployment descriptor. (A resource manager connection factory is an object that produces connections. For example, a JDBC DataSource object is a factory of JDBC Connection objects.) The deployer must also follow the application assembly instructions defined by the application assembler. The deployer also sets up the security environment for an application by mapping the security roles defined by the application assembler to the user groups and accounts that exist in the operational environment in which the enterprise beans are deployed.

To perform these tasks, the deployer uses tools provided by the EJB container provider. The deployment process typically has two stages:

1. The deployer first generates the additional artifacts that enable the container to manage the enterprise beans at runtime. These artifacts are container specific.

2. The deployer installs the enterprise beans and the additional artifacts into the EJB container.

A qualified deployer may take on some tasks of the roles of the application assembler or bean developer by customizing the enterprise beans when deploying them. For example, a deployer may subclass the enterprise bean class and insert additional business rules into the subclass.

3.1.4 System Administrator

The system administrator configures and administers the enterprise computing and networking infrastructure, which includes the EJB server and the container. The system administrator is also responsible for administering security at the enterprise. For example, the system administrator adds user accounts, groups users into user groups, and manages the various mappings of security information necessary when the enterprise uses multiple systems. In large organizations, the system administrator may have multiple security-based roles. For example, there could be a security officer, separate from the system administrator, who oversees the mapping of users to roles.

The system administrator is also concerned with deployed applications. The administrator oversees the well-being of the deployed enterprise bean applications at runtime. This means that the administrator monitors the running application and takes appropriate actions if the application behaves abnormally.

The EJB architecture does not define the requirements for system management and administration. The system administrator typically uses runtime monitoring and enterprise management tools provided by the EJB server and container providers to accomplish these tasks.

3.1.5 EJB Container Provider

The EJB container provider, or simply container provider, provides

• The deployment tools necessary for the deployment of enterprise beans

• The runtime support for instances of the deployed enterprise beans

From the perspective of the enterprise beans, the container is part of the target operational environment. The container runtime library provides the deployed enterprise beans with transaction and security management, network distribution of clients, scalable management of such resources as connections and threads, and other services generally required as part of a manageable server platform.

The container provider implements an EJB container that meets the functionality requirements set forth by the EJB specification. The container provider vendor may also implement the EJB server. The EJB specification does not dictate the interface between the server and the container; nor does it define how the provider is to devise the required functionality. As a result, the container provider vendor is free to split the implementation of the required functionality between the EJB container and server as needed. Typically, container providers market the EJB container and EJB server in a single product under the name application server.

For the most part, a container provider's expertise is system-level programming. The container provider focuses on the development of a scalable, secure, transaction-enabled container that is integrated with an EJB server. The container provider insulates the enterprise bean from the specifics of an underlying EJB server by providing the simple, standard EJB API between the enterprise bean and the container.

In addition to an API, the container provider provides various tools for system administration. These tools permit a system administrator to monitor and manage the container and its enterprise beans, particularly during runtime. There also may be tools for version control of installed enterprise bean components. For example, the container provider may provide tools to allow an administrator to upgrade enterprise bean classes without invalidating existing clients or losing the state of the existing enterprise bean objects.

The container provider also manages the persistence issues for its entity beans that use container-managed persistence. The container provider's tools generate code that moves data between the enterprise bean's container-managed fields and a database or an existing application. This code generation typically takes place at deployment time.

3.1.6 EJB Server Provider

The EJB server provider is a specialist in the area of distributed transaction management, distributed objects, and other lower-level system services. A typical EJB server provider is an operating system vendor, middleware vendor, or database vendor.

The EJB architecture assumes that the EJB server provider and the EJB container provider roles are the same vendor and therefore does not define any interface requirements for the EJB server provider. The EJB specification draws the separation between the EJB container and the EJB server to illustrate that an EJB container can be developed on top of a preexisting transaction processing system. (The latter would be referred to as the EJB server.)