Software Configuration Management

Objectives of an Effective Packaging and Deploying Model
To satisfy the above listed characteristics of an enterprise application and to simplify the tasks in deploying such an application, a good packaging and deployment model should meet the following objectives:

Best Practices
For the rest of the article I will discuss best practices which, when implemented, will satisfy the characteristics and objectives outlined in the previous sections.

Planning
It's always tempting to jump ahead and start building and deploying the application. However, I strongly recommend that you plan all the tasks needed to package and deploy your application before performing them. When planning for an application install in WebSphere you should identify:

• All application components such as classes, third-party libraries, HTML and JSP pages, images, and property files
• All enterprise datasources and the connectivity details the application would use during runtime
• The types of JAR files and what classes make up these JARs
• The deployment directory structure where the application components will be installed

After looking at the different WebSphere classpaths, it is recommended that you package your classes into one or more JAR files, which fall into the following categories:

1. Servlets
2. EJBs
3. EJB client classes
4. EJB dependent classes
5. Classes common to EJBs and Servlets
6. Application classes that do not fall into any of these categories

Deployment Directory Structure
Designing a meaningful directory structure for where your application components will be placed will simplify application management and maintenance. Table 3 lists a manageable directory structure for the PetStore application.

Application Environment Configuration
Datasource connectivity details change as the application is promoted from development through production. Externalizing these details into property files makes your code portable across stages. If the application uses WebSphere connection pools, maintaining the datasource JNDI names in property files will decouple the references made in application classes from the configuration.

For each of the stages, development through production, maintain separate sets of environment property files. During deployment, these property files can either be renamed or copied to the location where the application components look for these files.

Building Applications
As the number of classes, EJBs, and JAR files increases in your application, it is essential that you have a defined build process. This will ensure that your application is built in exactly the same manner each time a build is executed. You should identify, document, and automate all the steps to building your application as much as possible.

An automated build process will speed up the promotion of the application from one stage to another. It also removes any issues related to compilation errors and classpath issues that can cause wasted time and money.

Use build tools such as Ant to create build scripts, which not only compile your classes but also package them into JAR files and create distributable software. Ant is an open source Java-based build tool that lets you construct your build scripts in much the same fashion as the "make" tool in C or C++. You can use a large number of built-in tasks in Ant to create your build scripts. The build scripts, unlike make files, are XML documents. For the majority of applications, the built-in tasks are sufficient. If they're not, you can create your own custom tasks in Java.

In addition to creating build scripts it is recommended that you run these build scripts against the source located in your software configuration management tool. This ensures that your builds are using the latest version of the checked-in source.

Configuring Applications in WebSphere
You can configure an application in WebSphere either interactively, using the WebSphere Administrative Console, or from the command line using the XMLConfig tool. Creating scripts to configure applications offers these benefits:

In this article I will not address WebSphere 3.5 security configurations as most applications do not use them and it isn't easy to script the definitions.

Creating XMLConfig Scripts
When creating reusable XMLConfig scripts I recommend the following procedure:

1.   Use the administrative console the first time you are configuring the application in WebSphere.
2.   Once you have the application tested and you are satisfied with the configuration, create a model from the application server. Models allow you to create configuration that is portable across stages and domains.
3.   Delete all the clones, including the application server from which the model was created.
4.   Export the administrative configuration into an XMLConfig file.

Once you have exported the XMLConfig script file, I recommend that you refactor the script into multiple scripts based on the following guidelines:

1.   A node configuration script containing node-specific configurations such as the node-dependent classpath
2.   A datasource configuration script containing datasource and JDBC driver definitions
3.   A script for virtual host definitions.
4.   An application server model script containing the application server, EJB container, EJBs, servlet engine, Web applications, and servlet definitions
5.   If you have multiple Web applications you can create one script for each application that contains the application-specific Web application, EJBs, and servlet definitions
6.   A script that is used to install JDBC drivers on each node

Based on these guidelines, you would refactor the XMLConfig script for the PetStore application into multiple scripts as shown in Table 4.

As a best practice add these scripts to your software configuration management repository and promote them through the various application stages. Also, while packaging the application include these scripts in the package. This way when the package is installed on the destination server, the scripts needed to deploy the application are available on the server.

Making XMLConfig Scripts Reusable Across Stages
Once you have created the multiple XMLConfig scripts the next step is to make these scripts reusable across multiple stages. The following elements tie the scripts to a particular stage or environment:

1.   IP addresses and database aliases used in data source definitions of the resources.xml script
2.   Authentication details specified on the EJB container, CMP EJBs and Session Manager of the model.xml and petstore.xml scripts
3.   Host aliases specified as attributes for the virtual host in the vhosts.xml script

Replace these configuration elements with XMLConfig substitution variables. For example, replace the occurrence of a host IP address with "$HOST_IP$". When executing these scripts, specify the values to substitute for these variables at the command line.

Making XMLConfig Scripts Portable Across Operating Systems
There are three major differences between Windows NT and Unix that affect our XMLConfig scripts:

1.   The path separator: On NT the class path separator is semi-colon ";" and on Unix it is colon ":".
2.   The directory separator: On NT the directory separator is backslash "\" and on Unix it is the forward slash "/".
3.   The root drive: On NT you have a root drive letter called C: and on Unix you have none.

To make the scripts portable across platforms:

1.   Replace all occurrences of the path separator in the classpaths with the XMLConfig tool's predefined substitution variable $psep$.
2.   Replace all occurrences of the NT-specific directory separator "\" with "/". The Java virtual machine treats the forward slash as it would treat a backslash on Windows NT.
3.   If the application is installed on the same drive as Windows NT, you could safely omit the drive letter from the classpath.

Deploying the Application
Deploying the application is a two-step process. First, you have to copy the application software to the destination server. Second, you have to import the XMLConfig scripts into WebSphere.

When importing the scripts, you need to specify the values to substitute for the variables that you used in the scripts. As a best practice, you can create convenient shell scripts that can be used to import the scripts with the appropriate parameters. If you want to run these shell scripts on NT, you could install software such as CygWin, which provides Unix-like utilities for Windows.

Summary
If you follow the best practices discussed in this article you can create a clear separation between the responsibilities of developers and administrators, and simplify building, distributing, and configuring WebSphere applications across multiple stages and platforms.

Resources