EJB Roles and Their Responsibilities

As you probably are aware or will most definitely learn by the time you finish this book, there are many pieces to the enterprise application puzzle. Fitting all of them together is sometimes very much like putting together a jigsaw puzzle blindfolded. From building the infrastructure that handles database access to ensuring security of the application, the amount of knowledge that one must posses to build an entire enterprise application is mind-boggling and sometimes can be overwhelming. In fact, just trying to learn how much there is to learn can be tiring and frustrating.

The first thing you need to learn is what pieces make up an EJB application. The second and much harder task is learning how to build each individual piece of the EJB puzzle. Back in Chapter 1, you were introduced to some of the large-grained components of an enterprise application. In Chapter 2, "Setting the Stage ”An Example Auction Site," you were introduced to the fictitious auction site that we will be using and building upon throughout the book to illustrate the different components of an enterprise application built using EJB technology. In this chapter, we start the education process on what pieces make up an application that uses enterprise beans. The rest of the book covers how to build an enterprise application using the EJB architecture. Before we get into details of building an EJB application, you need to know who is responsible for which pieces in the process.

No single software developer can be an expert at all facets of building enterprise applications. Of course, some might believe that they are experts at all things enterprise, but in reality this is typically not the case. For example, building an Object to Relational Mapping architecture framework (ORM) is a very complicated task for any serious production-level implementation. For this, you need to be an expert at database technologies; an expert in the Java Database Connectivity API; and understand issues of caching, pooling, transactions, and many other complicated tasks . One could, and many often do, spend their entire careers learning these technologies alone. Similarly, building an architecture or framework to handle distributed communications is also very complicated, but in different subject areas and technologies. The point here is that you can have a solid understanding and be very proficient at many things, but it's quite a different matter to be an expert at everything related to enterprise application development.

If you are evaluating a particular technology implementation by a vendor, you want to believe that the very best people built that implementation. You hope that the people whose product your company is about to spend big bucks on are complete experts in that area. Because not many are experts in all areas, the EJB specification has separated the development, deployment, and management of an enterprise application into six distinct roles. Each EJB role plays a different part in the overall life cycle of the application development and deployment process. Some of these roles might be merely logical with smaller projects or organizations and might be performed by the same vendor or developer. Nonetheless, it's valuable to understand the distinction that's being made between the roles and responsibilities within the EJB architecture. The six distinct roles are

• Enterprise bean provider

• Application assembler

• EJB deployer

• EJB server provider

• EJB container provider

• System administrator

Bean Provider

The enterprise bean provider is the Java developer that is responsible for creating the EJB components that help solve the business problem. The bean provider may build all three types of enterprise beans. A bean provider is usually a Java developer who understands the domain in which he is operating. It's someone who understands what business logic or functionality should be in an Order component or a ShoppingCart component, for example.

The bean provider generally creates one or more enterprise beans, the required Java interfaces that must accompany the enterprise beans, other Java classes that are used by these enterprise beans, and an XML file that will be used to describe how the beans should be assembled and deployed. The XML file describes certain aspects of the enterprise beans that the bean provider has created. The aspects in the deployment file can include things like the name of the bean or beans, external dependencies the beans have, and other things that you will see later in this book when we talk about deploying EJBs.

The bean provider will normally deliver the beans in an ejb-jar file that typically contains the necessary items to assemble and deploy the enterprise beans with the rest of the application. An ejb-jar file is a standard JAR file that is used by vendor tools to package one or more enterprise beans along with their assembly instructions so that assembly and deployment tools can process the enterprise beans. This JAR file is delivered to an application assembler who takes the responsibility for the next step in the process. Figure 3.1 shows the role of the enterprise bean provider.

Figure 3.1. The bean provider is responsible for creating the EJB components used to solve the business problem.

For more information on how the various EJB roles interact with the ejb-jar file, see "Deployment Descriptors and EJB Roles," p. 422 .

Application Assembler

An application assembler receives enterprise beans in the form of ejb-jar files from one or more bean providers and assembles these beans into larger units of deployment. For example, bean provider A might build and hand over a ShoppingCart component while bean provider B creates and delivers an OrderFulfillment component. Both of these components may be in separate ejb-jar files. The application assembler can choose to leave the beans in separate ejb-jar files or create a single ejb-jar that contains all the enterprise beans being assembled. The decision to put the bean components in a single ejb-jar or into separate ejb-jar files is really up to the assembler and how the application needs to be deployed.

The assembler also will insert assembly instructions into the deployment descriptor files that were created and provided by the bean provider. The type and nature of the assembly instructions depend on the type of enterprise bean being included. With smaller projects or organizations, the bean provider can also function as the application assembler. In fact, if you are including multiple enterprise beans within a single ejb-jar file, you are most likely performing the role of the assembler anyway. The assembler is typically someone with technical knowledge within the development organization. Although the application assembler might also be a domain expert and will understand the interfaces to the bean components, there's no requirement that they understand the implementation details of the beans being assembled. It's sufficient for the assembler to understand the interfaces and external requirements for the enterprise beans.

Generally, application assembly occurs before deployment. However, the specification does not prevent assembly from occurring after deployment. The specification committee members did this primarily so that vendors will have some flexibility with tools that are used for assembly and deployment. It is possible to modify some application assembly instructions after the beans are deployed, but generally this is done beforehand. Figure 3.2 shows the responsibilities of the application assembler.

Figure 3.2. The application assembler is responsible for assembling one or more enterprise beans into a larger set for a specific application.

Other than the ejb-jar file that can contain enterprise beans and Java classes, there are two other types of deployment files you may use when building enterprise applications. One is called web application archive (WAR) and the other is called enterprise application archive (EAR). A WAR file contains the Web components for your application, including server-side utility classes, static Web resources such as HTML files and images, and client-side classes needed to communicate with the server application. The EAR file is a J2EE application deployment file that contains everything needed for deploying an application into a J2EE container. Because this book deals exclusively with EJB, the WAR and EAR deployment files will not be covered. Instead, we will focus exclusively on the enterprise bean deployment information in Chapter 15.

EJB Deployer

The EJB deployer takes one or more of the ejb-jar files produced by the bean provider or application assembler and deploys the bean components into an EJB operational environment. The operational environment consists of the container and server. The deployer must use the specific deployment tools that are provided by the container vendor. The deployer must also understand the external dependencies that are required by each enterprise bean. Among these external dependencies are things such as database connections and JMS administration components. The deployer must also pay attention to the application assembly instructions provided in the deployment descriptor files.

The EJB deployer should be an expert with the particular operational environment and is usually responsible for mapping the security roles defined in the assembly instructions to actual groups and accounts that exist in the environment.

Usually, there are two major steps to deploying beans into an environment. The first is to use the container-specific tools to generate the necessary helper classes that are used by the container to manage the life cycle of the beans. The output of these tools varies somewhat with each vendor, but generally it's another JAR file similar to the ejb-jar file that the deployer started with. The new JAR file contains everything that the container needs to manage the bean life cycle. In smaller development shops , the bean provider might perform this step instead of the deployer.

The second step is to install the entire set of application components into the environment. You do this by placing the appropriate JAR files and classes in a vendor-specific location where the container can locate them. Each vendor is somewhat different, so check the EJB vendor's documentation for exact details on where the files need to go. Figure 3.3 shows the responsibilities for the EJB deployer.

Figure 3.3. The EJB deployer is responsible for installing the bean components into the operational environment.

In a typical development group , it's not uncommon to have a single developer perform the roles of the bean provider, assembler, and deployer. In fact, as you work through the examples of your own and the ones in this book, you are actually performing all three of these roles.

EJB Server Provider

Currently, the EJB specification does not define any specific requirements for the server provider. The specification assumes that the same vendor provides the server and the container. In the future, this might not always be the case. The server provider is responsible for low-level services such as transaction management, thread management, and middleware. It's usually more infrastructure services than bean life-cycle services. Figure 3.4 shows the relationship between the server and container.

Figure 3.4. The EJB server provider provides the server component, which handles the low-level services and management capabilities.

EJB Container Provider

The container provider is the vendor or organization that provides the necessary operational environment for your enterprise beans to function. This includes the deployment tools that were mentioned in the previous sections. In the current EJB 2.0 Specification, there really is no clear separation of server versus container responsibilities. The specification leaves it up to the EJB server and container vendors to figure out which services are managed in the server and which ones the container performs . This is not that difficult right now because vendors generally implement both as a combined set of services, and the distinction is more of a logical one than physical. However, the separation seems to be heading in the direction of the server managing the necessary infrastructure services and the container managing bean life cycle services and the component contract, as well as providing the deployment tools.

Examples of some services that the server might be responsible for are thread management, network management, and other low-level system services. Examples of services handled by the container are bean instance pools, transaction management for beans, and deployment tools. Another responsibility that the container provider might be responsible for is to provide the tools to monitor the set of installed beans and, in some cases, allow for reinstalling existing beans without stopping the server. This is often referred to as a hot-swap or hot-deploy . These examples might not hold for all vendors.

For some vendors, no real distinction is made between the server and container. Usually, the container is more of an abstraction than a physical component. Throughout this book, we will refer to the server and container as the same component and will not draw any further distinction. We will use the terms interchangeably from this point on. In the future, you might be able to buy a container separate from the server. Before that can happen, the specification will need to decide which component will implement which set of services and what the contracts between the two will be. For now, it's safe to treat the server and container as a single component that provides all the necessary EJB contract services, such as transaction and security management, distributed component support, resource management, and other system services.

As was mentioned in the beginning of this chapter, not many developers are experts at all things enterprise. The server and container providers usually are experts with system-level services. It's their job to provide a scalable, secure, transaction-aware environment and to make these low-level services readily available in a set of easy-to-use interfaces. The enterprise beans that are deployed should be insulated from any of the low-level services, and the bean provider should not have to worry about the underlying infrastructure unless it's a unique situation. Figure 3.5 shows the relationship between the EJB components and the server/container.

Figure 3.5. The EJB container provider provides the life cycle services for the enterprise components.

System Administrator

The responsibilities of the system administrator include such things as ensuring that the EJB server is available to other network services and applications and that the EJB servers are configured correctly to handle the current and expected user loads. The administrator will typically use the monitoring tools that are provided by the server and container vendors to ensure that the EJB servers are healthy and running appropriately. The EJB specification does not specify any contracts or specific responsibilities; each organization must establish its own processes for this role. Figure 3.6 shows a typical relationship between the system administrator and the EJB environment.

Figure 3.6. The system administrator is responsible for monitoring the EJB application.