7.4 Deployment Tools

Although deployment can be performed directly by editing XML text files, the process best handled by specialized tools. This section describes the actions that a deployment tool performs and outlines requirements on packaging and development tools. The requirements serve as recommendations to vendors of packaging and deployment tools and determine what developers can expect from such tools.

7.4.1 Deployment Tool Actions

This section discusses what happens behind the scenes when a J2EE application is deployed on a J2EE server. Since there can be many J2EE applications deployed on the same J2EE server, the J2EE servers typically register each application under a different identifier. The deployment of a J2EE application involves three different types of components: enterprise beans, Web components, and application clients.

For each enterprise bean, the J2EE server must perform the following tasks:

1. Generate and compile the stubs and skeletons for the enterprise bean.
2. Set up the security environment to host the enterprise bean according to its deployment descriptor. This is needed so that the access to the methods of the enterprise bean can be regulated according to the security policy of the application.
3. Set up the transaction environment for the enterprise bean according to its deployment descriptor. This is needed so that the calls to the methods of the enterprise bean happen in the correct transaction context.
4. Register the enterprise bean, its environment properties, resources references, and so on, in the JNDI name space.
5. Create database tables for enterprise beans that use container-managed persistence.

For each Web component, the J2EE server must perform the following tasks:

1. Transfer the contents of the Web component underneath the document root of the server. Since there can be more than one J2EE application installed, the server may install each under a specific directory. For example, the J2EE SDK installs each application under a context root specified at the deployment time. The sample application is installed under the estore directory.
2. Initialize the security environment of the application. This involves configuring the form-based login mechanism, role-to-principal mappings, and so on.
3. Register environment properties, resource references, and EJB references in the JNDI name space.
4. Set up the environment for the Web application. For example, it performs the alias mappings and configures the servlet context parameters.
5. Precompile JSP pages as specified in the deployment descriptor.

The tool used to deploy an application client, and the mechanism used to install the application client, is not specified by the J2EE specification. Very sophisticated J2EE products may allow the application client to be deployed on a J2EE server and automatically made available to some set of (usually intranet) clients. Other J2EE products may require the J2EE application bundle containing the application client to be manually deployed and installed on each client machine. And yet another approach would be for the deployment tool on the J2EE server to produce an installation package that could be taken to each client to install the application client.

7.4.2 Deployment Tool Requirements

When considering the requirements on deployment tools, it is important to consider the deployment process at two different times: during application development and during production deployment. A developer's deployment needs are different than the needs of a Deployer installing a production application on a mission-critical system. When an application is being developed, it must be deployed before it can be tested. Developers want fast response times, and the ability to undeploy, redeploy, and partially deploy applications easily and quickly. They will often make minor changes to Java classes, and hence will not want to go through a lengthy deployment process over and over again. They also need extensive debugging facilities. Many Java development environments will contain a J2EE server optimized for these purposes.

When deploying a production application on a mission-critical server, the priorities are robustness, performance, and stability. Often, to avoid downtime and unforeseen problems, the application is first brought up on parallel systems. The foremost consideration of the Deployer is to be able to connect all legacy systems to the newly developed application. A Deployer may also want detailed logging of the deployment process.

The following sections explore packaging and deployment issues from a tools perspective and point out differences, if any, in the light of the two different deployment times.

7.4.2.1 Vendor-Specific Information

The J2EE platform specification specifies file formats for each of the three J2EE component types and for a J2EE application itself. This specification defines how such files must be structured to be correctly handled by a J2EE deployment tool. A certain amount of information must be available to each container along with the application code and deployment descriptor for proper runtime support of an application. This information is usually related to bindings of the application in a vendor-specific or environment specific setting. Here is a partial list of information the deployment tool of the J2EE SDK solicits from the Deployer after consuming an application EAR file:

• A JNDI name for each enterprise bean's home interface
• A mapping of abstract security roles of the application to user and group names
• JNDI lookup names and account information for all databases
• JavaMail session configuration information

Note that these issues only come up at deployment time--they in no way affect the ability to deploy an application on servers from different J2EE Product Providers.

There are many ways to represent this information. The J2EE SDK represents this information in an XML document held as a separate entry within the application archive. Code Example 7.19 is an example of the XML document that represents runtime information for the sample application after the runtime bindings have been made with the J2EE SDK:

<j2ee-ri-specific-information>
	<server-name>localhost</server-name>
	<rolemapping>
		<role name="gold_customer">
			<groups>
				<group name="gold" />
			</groups>
		</role>
		<role name="customer">
			<principals>
				<principal>
					<name>j2ee</name>
				</principal>
			</principals>
			<groups>
				<group name="cust" />
			</groups>
		</role>
	</rolemapping>
	<enterprise-beans>
		<ejb>
			<ejb-name>TheAccount</ejb-name>
			<jndi-name>estore/account</jndi-name>
			<resource-ref>
				<res-ref-name>jdbc/EstoreDataSource</res-ref-name>
				<jndi-name>jdbc/EstoreDB</jndi-name>
				<default-resource-principal>
					<name>estoreuser</name>
					<password>estore</password>
				</default-resource-principal>
			</resource-ref>
		</ejb>
	</enterprise-beans>
</j2ee-ri-specific-information>

Different J2EE product vendors will also need to add similar information in the deployment process of a J2EE application. Vendors may find it useful to take advantage of the attribute ID mechanism afforded by document type definitions to link vendor-specific information to components and entities within a J2EE application.

The output of a deployment tool should remain compliant with the J2EE specifications in order that it may be easily opened in other deployment tools even when such extra information has been added. We recommend that the deployment descriptors within an application remain as unchanged as possible to support this. We also recommend that the tools preserve vendor-specific information added to an application across sessions. This can be done by storing such information with or inside the J2EE application file or using an IDE-like project structure.

EJB and Web modules are independently deployable units and hence any deployment tools should be able to accept and deploy them. Although the archive files may be augmented with vendor-specific information, we recommend that other deployment tools be able to accept and deploy these augmented EJB and Web modules and J2EE applications even though they may not understand a particular vendor's runtime binding information. We recommend that the vendor-specific information that the deployment tool expects have reasonable fall-back default options for this purpose.

7.4.2.2 Single Point of Entry for Deployment

A high-end mission-critical server often consists of multiple physical servers. Often the number of Web containers is greater than the number of EJB containers. In such cases, the Deployer to shouldn't have to install applications individually on each machine. We recommend that the deployment process has a single point of entry-- either a stand-alone deployment tool or the deployment component of a J2EE server. For example, the J2EE SDK has a deployment tool that provides a single point of entry to the J2EE server. This central component then takes care of distributing appropriate components on both the Web and the EJB containers.

This approach has following benefits:

• It simplifies the deployment process since the Deployer has to interact with only one deployment tool. The Deployer also has a clear understanding of when deployment is complete. The tool also handles determining which components are required to be deployed on each machine.
• It provides a way to perform centralized logging and auditing.
• It provides better fault tolerance. Since the deployment tool has complete control over all application components on all servers, it can detect server failures and handle them by dynamic load balancing. It can also detect when a server comes back up and redeploy the application to bring it in sync. An added advantage is that the Deployer does not have to worry about load-balancing.
• It simplifies undeployment and upgrading.

7.4.2.3 Remotely Accessible Deployment

Deployers often need to deploy multiple applications on multiple J2EE servers. To handle such scenarios more easily, the deployment tool should be remotely accessible as either a Web-based or client-server application. The deployment tool bundled with the J2EE SDK takes a client-server approach, using RMI-IIOP to communicate with the administration back-end of the J2EE server. The tool has the capability to access multiple J2EE servers and deploy applications on them.

7.4.2.4 Undeployment Capability

In development-time deployment, it is critical to have undeployment capability for quicker updating of new application components. In a high-end implementation, it isn't acceptable to have to bring down the server to add or remove new software applications, so that high-end servers will likely support dynamic deployment and dynamic undeployment. Low-end J2EE servers may not need to support this capability.

For many J2EE servers, deploying a J2EE application may be an atomic process, with no support for incremental deployment of J2EE application components. However, at stages of the application development process, it may be desirable to test portions of an application. This requires the ability to divide a component application into smaller units so that each can be deployed and re-deployed without the wait associated with deploying a full scale application.

7.4.2.5 JNDI Name Space Management

Deployers will need to bind external references in a J2EE application to entities in their environment. Examples of such references include databases and enterprise beans in the system. Since binding happens through the JNDI name space, Container Providers need to provide tools to create and manage the JNDI name space. These tools also need to control the access to the JNDI name space according to the security policy of their environment.

7.4.2.6 Name Collision Management

Application Assemblers may use third-party enterprise beans, without control over the names used for such enterprise beans. As a result, name collisions are bound to occur. Packaging tools should automatically detect and handle such name collisions by adjusting names through the ejb-link element of the bean's deployment descriptors.

7.4.2.7 Deployment Descriptor Versioning

The lifetime of many enterprise applications may be measured in years and even decades. An important goal of the J2EE platform is to provide compatibility even when systems and application components are upgraded. Packaging and deployment tools need to ensure that they do not add anything that is against the general direction of evolution of deployment descriptors. They also need to follow the versioning conventions described in the J2EE, EJB, and servlet specifications.