7.5 Deployment Tools

Although deployment can be configured directly by editing XML text files, the process is handled best by specialized tools such as the DeployTool provided with the J2EE SDK. This section describes the actions that a deployment tool performs and outlines requirements on packaging and development tools. The recommendations in the remainder of this chapter are intended primarily for J2EE product providers who distribute packaging and deployment tools with their products. Developers can better understand what to expect from such tools by understanding the recommendations.

7.5.1 Deployment Tool Actions

This section discusses what happens behind the scenes when a J2EE application is deployed on a J2EE server. Since many J2EE applications may be deployed on an individual J2EE server, 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, enforcing the application's security policy on access to the enterprise bean's methods.
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 namespace.
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 context root of the server. Since there may be more than one J2EE application installed, the server may install each in a specific directory. For example, the J2EE SDK installs each application under a context root specified at deployment time. The sample application is installed in the petstore 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 namespace.
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, are 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. 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. Java Web Start technology is recommended to manage installation and automatic upgrading of application client programs.

7.5.2 Deployment Tool Requirements

Deployment tools have different requirements during 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 light of the two different deployment times.

The J2EE platform specification defines deployment unit requirements for each of the four J2EE module types and for a J2EE application itself. Each specification defines how the archive file must be structured to operate correctly with a J2EE deployment tool. In addition to application code and a deployment descriptor, an application requires a certain amount of additional vendor- or environment-specific binding information. For example, when the J2EE reference implementation receives an application EAR file from a deployer, it also needs the following information:

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

Note that these issues arise only at deployment time--they in no way affect the ability to deploy an application on servers from different J2EE product providers.

Each vendor implements these vendor-specific bindings in a different way. For example, the J2EE reference implementation represents vendor-specific information as a separate XML document (called sun-j2ee-ri.xml) within the application archive. Code Example 7.28 is an excerpt derived from the sample application's vendor-specific deployment information.

<j2ee-ri-specific-information>
	<server-name>localhost</server-name>
	<enterprise-beans>
		<module-name>customerEjb.jar</module-name>
		<unique-id>0</unique-id>
		...
		<ejb>
			<ejb-name>AccountEJB</ejb-name>
			<jndi-name>ejb/local/customer/account</jndi-name>
			<ejb-ref>
				 <ejb-ref-name>ejb/local/creditcard</ejb-ref-name>
				<jndi-name>
				localejbs/BluePrints_Petstore/CreditCardEJB3
				</jndi-name>
			</ejb-ref>
			... 
</j2ee-ri-specific-information>

The J2EE platform specification does not specify how an ejb-name maps to a home interface. Instead, the specification leaves this detail to the platform implementer's discretion, which provides the implementer with more design flexibility in the platform implementation.

The J2EE reference implementation provides one example of how a J2EE platform implementation might map an ejb-name to a home interface. A deployer using the J2EE reference implementation provides vendor-specific deployment information that maps each ejb-name to a jndi-name, which is the name of the actual bean home interface in the naming environment, as configured in the EJB container. As shown in Code Example 7.28, the J2EE reference implementation's vendor-specific deployment information binds the ejb-name AccountEJB to a corresponding jndi-name, localejbs/BluePrints_Petstore/CreditCardEJB3. This separation of standard deployment information from vendor-specific information ensures the reusability of deployment descriptors across vendor platforms and implementation versions while enabling vendor-specific bindings and extensions.

Vendors may find it useful to use XML attribute IDs to link vendor-specific information to components and entities within a J2EE application. The J2EE reference implementation links standard and vendor-specific deployment descriptor information by component name.

The J2EE specifications define the internal structure of deployment units, and the content and structure of deployment descriptors. BluePrints recommends the following practices for deployment tools and descriptors:

• Deployment tools should follow the J2EE specifications closely, so that each deployment unit may be opened and used by the deployment tools of as many vendors as possible.
• Deployment descriptors written by deployment tools should always conform to the DTDs specified in the J2EE specifications.
• Vendor-specific deployment information should be kept outside of the deployment descriptor, but within the deployment unit itself, perhaps in an auxiliary XML such as the one the J2EE reference implementation uses.
• A deployment tool should preserve, not remove, any files that it does not recognize within a deployment unit, because such files might be deployment information from some other tool.
• Likewise, tools should always preserve optional deployment descriptor entries, instead of throwing away entries they don't use or recognize.
• Finally, vendor-specific deployment information should have reasonable fall-back default values to make deployment as simple as possible.

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 shouldn't have to install applications individually on each machine. The deployment process should have a single point of entry--either a stand-alone deployment tool or the deployment component of a J2EE server. For example, the J2EE SDK deployment tool 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 the following benefits:

• It simplifies the deployment process, because the deployer has to interact with only one deployment tool. The deployer also clearly understands when deployment is complete. The tool also determines which components are required to be deployed on each machine.
• It provides a place for 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 perform failovers. 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, because the runtime environment handles it automatically.
• It simplifies undeployment and upgrading.

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 can access and deploy applications on multiple J2EE servers.

In development-time deployment, undeployment capability is critical to quickly update new application components. In a high-end implementation, it isn't acceptable to restart the server to add or remove new software applications. High-end servers will therefore likely support dynamic deployment and undeployment. Low-end J2EE servers may not need to support this capability.

Another useful development feature of high-end J2EE products is incremental deployment and undeployment. For many J2EE servers, deploying a J2EE application may be an atomic (and slow) process. Waiting for an entire application to deploy when an application component changes can slow the development process unacceptably. Servers that allow deployment and undeployment capability of only parts of an application, and that incorporate this feature into their tools, greatly accelerate the development cycle.

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

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.

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. To maintain deployment descriptor portability both across platforms and across implementation versions, separate standard and vendor-specific deployment information. Packaging and deployment tools should follow the versioning conventions described in the J2EE, EJB, and servlet specifications.