- The client’s view
- Fundamentals of the EJB architecture
- Types of EJB
- Distributed and local EJB semantics
- Anatomy of an EJB
- Principle of operation: session and entity EJBs
- Principle of operation: message-driven EJBs
- The EJB container and its proxies
- Overview of the EJB API
- EJB rules, standards and limitations
- Assembly and deployment
- Configuration
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
3.11 Assembly and deployment
In almost all software development exercises, the computers used to develop the software are not the same as the ones that will be used to run it when in service. Unlike most other forms of software development, the format in which EJBs are packaged for transfer from a development system to a production system is standardized: EJBs are packaged into EJB-JAR files, which are in turn packaged into an EAR file. The EJB server is required by the EJB Specification to be able to take a correctly formatted EAR file from any source and install the EJBs it contains. Many products allow EJB-JAR files to be deployed without constructing an EAR file, which is convenient during development. This process, whether applied to EJB-JARs or to EARs, is called deployment.
An EAR file can contain EJBs from a number of different sources, produced by different developers. When these EJBs are combined into a single application, it may be necessary to resolve name mismatches between EJBs and satisfy references to external databases, among other things. This process is called application assembly.
While deployment and assembly are different processes, most vendors allow both to be carried out with the same software tool. Therefore, many developers don’t distinguish sharply between assembly and deployment tools. When we talk of a ‘deployment tool,’ we usually mean something that can do assembly as well. The term ‘assembly’ is also used for the packaging of classes into an EJB and the construction of a deployment descriptor.
During deployment, the vendor’s tools will normally construct the home and remote objects, and the home and remote stubs. The latter should be made accessible for standalone clients.
Hint
Having set up the structure and contents on the EJB-JAR file, deployment to the server ought to be a trivial job, whether using scripts, command-line tools, or vendors’ graphical tools. If you modify and recompile the EJB classes, updating the EJB-JAR and redeploying to the server should also be trivial. If it requires more than, say, four mouse clicks or two commands, ask the vendor why this is. If you don’t get a straight answer, ask for your money back. Deploying an EJB is not rocket science, and should not present a problem for a modern software tool.
3.11.1 The EJB-JAR file
An EJB file is simply a Java JAR archive, with a particular structure. The class files are organized in the JAR to reflect the package hierarchy, as usual, while deployment descriptors are placed in a directory called META-INF. If we have an EJB called ‘BankTeller,’ for example, whose classes are in the package com.acme.ejb and have been named according to the convention described above, then the EJB-JAR will have the following format:
com
acme
ejb
BankTeller.class
BankTellerHome.class
BankTellerBean.class
META–INF
ejb–jar.xml
(other descriptors)
Note that the EJB Specification allows EJB server vendors to provide facilities to configure their products in ways that are not mandated (or, at least, does not forbid this). For example, the EJB Specification has nothing to say about load sharing, but this is a key feature of all commercial products. This kind of information cannot be placed into the standard deployment descriptor ejb-jar.xml, as the format of this file is strictly defined. So most vendors expect additional deployment descriptors. Ideally, the absence of these additional descriptors should not prevent the application from operating, although its performance may not be optimal. In practice, however, many vendors’ products simply don’t work at all without this extra information. This is one of the reasons why the cross-platform compatibility promised by EJB technology is not as easy to realize as may be hoped.
3.11.2 The EAR file
The EAR file contains a number of EJB-JAR files, along with WAR files that contain Web components (servlets, JSP pages, etc).
If the EJB-JAR file described above was called bankteller.jar, and this was the only EJB-JAR in the application, then the EAR file would have the following structure.
bankteller.jar
META–INF
application.xml
(other descriptors)
The deployment descriptor application.xml contains the following information:
the display name of the application;
a list of the EJB-JAR and WAR files that are to be deployed;
application-wide security roles (see Chapter 16).
Again, the EJB Specification allows the vendor to use deployment descriptors in addition to the standard one to convey product-specific configuration information. It is also conventional to include in the EAR file any additional class libraries that the application requires (that are not part of the EJBs).
3.11.3 Dynamic proxy and stub generation
It should be apparent by now that the home object and the EJB object/local object play key roles in EJB technology. Because these objects are proxies for the EJB, the methods they implement will usually depend on the methods in the EJB they serve. Thus, it is not practical for the EJB server to use general-purpose home and EJB objects. These objects will usually be generated dynamically at deployment time. In addition, the home stub and remote stub will also need to be generated, along with skeletons, if they are used.
The strategy used by most vendors is for their deployment tool to inspect the factory interface and business method interface of each EJB, using Java reflection, and construct the home objects, EJB object, EJB local object, and stubs as Java source files in a temporary directory. These source files are then compiled, and the classes inserted into the appropriate place in the server’s CLASSPATH.
The stubs are required by clients of the EJBs, so these must be made available to install on the client. The usual approach is for the deployment tool to package these up into a JAR file (called, for example, clientstubs.jar) and allow the deployer to select where they should be saved. Although Java RMI supports automatic stub downloading (see page 36), this technique is rarely used by EJB products, and it is normal to distribute the stubs along with the other client code.