Using XML and Jar Utility API to Build a Rule-Based Java EE Auto-Deployer

by Colin (Chun) Lu 11/16/2007
Introduction
Today's Java EE application deployment is a common task, but not an easy job. If you have ever been involved in deploying a Java EE application to a large enterprise environment, no doubt you have faced a number of challenges before you click the deploy button. For instance, you have to figure out how to configure JMS, data sources, database schemas, data migrations, third-party products like Documentum for web publishing, dependencies between components and their deployment order, and so on. Although most of today's application servers support application deployment through their administrative interfaces, the deployment task is still far from being a one-button action.
');
//-->

In the first few sections of this article, I will discuss some of the challenges of Java EE deployment. Then I will introduce an intelligent rule-based auto-deployer application, and explain how it can significantly reduce the complexity of Java EE system deployment. I will also give a comprehensive example on how to build XML rules using XStream utility library, how to extend and analyze the standard Java EE packaging (EAR), and perform a complex deployment task just by pushing one button.
Challenge 1: Package Limitations
A Java EE application is packaged as an enterprise application archive file (EAR). Java EE specification defines the format of an EAR file as depicted in Figure 1.
Figure 1. Standard Java EE EAR file structure
A standard EAR file meets the basic requirements for packaging an application as most of web-based JAVA EE applications are composed solely of web and/or EJB applications. However, it lacks the capability of packaging advanced JAVA EE application modules. For example, the following modules are often used in a JAVA EE application deployment, but cannot be declared in a standard EAR file:
JDBC Connection Pool and DataSource objects
JMS ConnectionFactory and Destination objects
JMX MBeans
SQL statements
Other resource files
Most of Java EE applications require Data sources, schema changes, data migrations, and JMS configurations. Today, these components have to be manually configured and deployed via an administration interface provided by the implementation vendor. This is typically the responsibility of the system administrator.
Challenge 2: Deployment Order and Dependencies
Another challenge to an application deployer is that he has to know the deployment dependencies and follow the exact order to deploy multiple deployments for one application.
A large Java EE application may have complex dependencies on other deployments. For example, corresponding database tables must be created before an application can be deployed; a JDBC data source must be configured ahead of a JMS server. In these situations, the deployer first has to coordinate with the application architect and developers to find out the deployment requirements and dependencies, and then make a detailed deployment plan. This process is not very efficient; we need a better solution.
Solution
How can we help a deployer survive these challenges? Is there a way to simplify this complex deployment process? A possible solution is to use the vendor proprietary capability to extend your EAR to be more intelligent. For example, WebLogic Server supports packaging JDBC and JMS modules into an EAR file, and the WebLogic Deployer can deploy your application as well as application-scope JDBC and JMS modules in one action. Isn't that useful? Wait a second, there are still limitations:
Tightly coupled - By doing this, your EAR is dependent on one vendor's application server. Your application has to be packaged according to the vendor's specification. This means if you want your product to be deployed across different application servers (or if your production wants to support multiple application servers), you have to maintain multiple EARs.
Complicated packaging - Since you have to follow specifications of different vendors, the application packaging is going to be very complicated and hard to understand.
Hard to maintain - For one application, you need to maintain different versions of EARs for different application servers, or even different versions of the same applications server.
Not a true one-button deployment. Since this type of deployment leverages vendor-specific tools, it cannot support deployment tasks that are not supported by application server. For example, one application may need to execute SQL statements to build schemas and load reference data or upload configurations to LDAP server to expose its service endpoints.
A practical solution is to make an intelligent XML rule-based auto-deployer by extending the Java EE packaging.
A Rule-Based Auto-Deployer
This solution has three main parts:
Tool: deployment XML rule generator using XStream
Packaging: extend EAR packaging to include the rule XML document using Ant
Deployer: EAR analyzer and auto-deployer using Java's Jar Utility API
The suggested deployment work flow is illustrated in Figure 2.
Figure 2. Deployment work flow
Case Study
Let's think about the deployment of a Service Order Processing application to a WebLogic server. Here are the deployment tasks that need to be done:
Configure a JDBC connection pool and data source for manipulating the order processing data.
Execute SQL statements for database objects creation (tables, triggers, and reference data, etc.).
Configure a JMS queue to dispatch service order requests.
Upload system properties (e.g., the URL and JNDI name of the JMS queue for order processing) to a LDAP server.
Finally, deploy this application to an application server
1. Deployment Tool: XML Rule Generator using XStream
The first step is to generate an XML rule from a plan by the application assembler.
Step 1: Define a deployment plan
To define a deployment plan, the application assembler discusses the deployment requirements with developers and architects. For the sample service order processing system, a deployment plan is defined below:DataSource,t3://localhost:7001,NONXA,jdbc/testDS,colin,password,jdbc:oracle:thin:@localhost:1521:localdb,oracle.jdbc.driver.OracleDriver
SQL,t3://localhost:7001,jdbc/testDS,sql/testDS.sql
JMS,t3://localhost:7001,PTP,testJmsServer,testJmsRes,jmsTestConnFactory,jms/conn,testQueue,jms/testQueue
LDAP,ldapread-server.com,489,cn=one_button_deployment,o=system_configuration,ldif/test.ldif
APPLICATION,t3://localhost:7001,SOManager,Release v1.0
Step 2: Use the Deployment Tool to generate an XML document from the plan
After the plan is defined, the application assembler runs the deployment tool application to feed in the plan and generate the XML rule document.
The sample application is shown Figure 3.
Figure 3. Sample deployment tool