(Author: Atul Singh Chauhan) June 12, 2007

Copyright © 2007 and HCL proprietary material. All rights reserved. No part of this document may be reproduced, reused, modified or distributed, in whole or in parts, in any form by any means without prior written authorization of HCL. The information provided in this document is intended for the sole use of the recipient and not for any commercial purpose. All the information provided is on “AS IS" basis and without warranties of any kind either express or implied or to any derived results obtained by the recipient from the use of the information in the document. HCL does not guarantee the sequence, accuracy or completeness of the information and will not be liable in any way to the recipient for any delays, inaccuracies, errors in, or omissions of, any of the information or in the transmission thereof, or for any damages what so ever arising there from.

WH

ITE

PA

PE

R

J2EE Application Deployment Framework

1. Abstract 3

2. Introduction 3

2.1. Current Approaches 4

2.2. Short Coming of Current Approaches 4

3. Enabler Technology 5

3.1. Overview of J2EE Deployment API 5

3.2. Phases in a Deployment Process 5

3.3. Configuring Applications for Deployment using J2EE Deployment AP6

3.4. Deployment Process in J2EE Deployment API 7

4. Technical Solution 7

4.1. Generic Container Deployment Framework 8

5. Limitations 12

6. Conclusion 12Tabl

e of

Con

tent

s

1. Abstract

2. Introduction

The primary advantage of J2EE based

products/applications is of portability across

different application servers that gives flexibility

to choose between application-server for

production deployment of a particular

application/product based on differentiating

feature of a specifc applicationserver. However

the challenge faced by most of the these J2EE

application/product providers is to 1)automate

the deployment process for various Application-

Servers 2)Make the deployment process

transparent of application-server specific non-

standard deployment mechanism.

This paper proposes a Generic container

deployment framework for automating and

making the deployment process of a given J2EE

application/product smooth, easily maintainable

and transparent of application-server. The

proposed framework is based on the J2EE

Deployment API (JSR88) part of J2EE

specifications since J2EE1.4 and introduces a

new concept of Container deployment descriptor

which is used by the framework utility for

deploying the application/product across

different application-servers. The framework also

provides mechanism to automatically generate

the Container deployment descriptor. The paper

also discusses the limitations of the proposed

framework and the complementing technologies

like JSR77.

In recent times J2EE-standard compliant

application development has gained lot of

popularity and momentum, and captured major

share among the present internet/intranet

application space. These applications are

developed independently purely based on J2EE

standards and are deployable on any of the

specific vendor’s Application server provided that

application server is compliant to J2EE container

specifications.

Following figure describes a typical Development

Life-cycle of a J2EE application:

This paper focuses on the deployment of a

standard J2EE application/component archive

f i le to a J2EE compl iant Appl icat ion

Server/container provided by different vendors.

During the deployment phase of an application’s

life cycle, the application or the archive is installed

on the target J2EE Application server/container

and then is configured and integrated into the

existing infrastructure/services of that application

server. Typically the deployer of the J2EE

application server is responsible for configuring

and installing the J2EE application for the specific

target Application Server and this where

additional manual/development effort is involved

which is not standard and varies from Application

Server vendor to vendor.

CreationEnterprise components created by component provider or developer

AssemblyAssembled into a standard portable archive by application assembler

DeploymentDeploy to target J2EE Container (Application Server) by applicationdeployer

J2EE Compliant Application Server/Container

Enterprise Components

J2EE Components

J2EE Standard Archive

Deploy

Fig: Development Life Cycle of J2EE Application

2.1. Current Approaches

2.2. Short Coming of Current Approaches

Primarily there are three approaches followed for

deployment of J2EE Applications/components to

the target Application Servers as follows:

1. Most of the Application server vendors such as

Weblogic and Websphere provide a

proprietary UI based tool for configuring and

deploying J2EE applications/components, the

end user or the deployer make use of this tool

and manually configure and deploy the J2EE

components onto the target Application server.

2. Some of the application server vendors such

as Websphere also provide a custom scripting

environment for deployment and the end-user

can make use of this environment to create

custom scripts for automating the deployment

process.

3. Few of the application server have neither of

the above two provisions, essentially because

the deployment process is quite simplified

requiring minimum configurations and

whatever configurations are required they can

be done directly into a XML configuration file, a

typical example where this is applicable is

Jboss.

The J2EE specification prior to 1.4 did not focus

on imposing any standards for deployment and it

was left open to the vendors to provide this

support, because of which every vendor has a

proprietary mechanism for deploying J2EE

applications/components. Though deployment

process of any Application server is not a very

time consuming and complex process, still it

requires some amount effort and knowledge of

the proprietary deployment mechanism. The

J2EE Applications/components can be broadly

divided into two categories 1) Custom J2EE

applications 2) J2EE Applications products. The

short coming or challenges faced with current

deployment approaches for the above two

categories can be summarized as follows:

- It is mostly a manual procedure unless the

vendor provides a scripting environment and

custom scripts created for deployment using

those.

- Familiarity with the vendor specific tool or any

other deployment mechanism provided by the

vendor.

- Learning proprietary features such as

scripting environment, in case provided by the

vendor and automation is required

- In case scripting environment is not provided

by the vendor of target Application server and

repeated or multiple deployments are

required, then manual steps are to be

repeated.

- The most important and significant challenge

is specifically for vendors providing J2EE

Application Products which are supposed to

be compatible with all J2EE compliant

Application Server, since there cannot be a

standard mechanism for deploying their

products on these Application Server and

scripts or manual steps are to be provided by

these vendors for each of the supported

Application server.

The cost of portability and standardization of

application is paid in terms of proprietary and

manual steps for deployment of that application

and this is an overhead and needs to be

eliminated or minimized.

Before getting into the actual solution proposed

for the challenges faced in the currently followed

J2EE application deployment approaches, it is

worth discussing here the core technology on

which the solution is based.

Considering the standardization requirement for

deployment of J2EE application/components

J2EE expert committee started working for a

specification viz. JSR88 or J2EE deployment API

and in J2EE1.4, this was made mandatory for all

compliant Application Servers to provide required

support for it

The Deployment specification architecture

defines the contracts that enable tools from

multiple providers to configure and deploy

applications on any J2EE platform product. The

contracts define a uniform model between tools

and J2EE platform products for application

deployment configuration and deployment. The

Deployment architecture makes it easier to

deploy applications, deployers do not have to

learn all the features of many different J2EE

deployment tools in order to deploy an application

on many different J2EE platform products.

3. Enabler Technology

3.1. Overview of J2EE Deployment API

The Deployment archi tecture def ines

implementation requirements for both tools and

J2EE platform products.

The primary responsibilities of a T

J2EE platform product.

The J2EE platform product ’s pr imary

responsibilities are to:

a) Generate the product-specific deployment

configuration information.

b) To deploy the application.

The API provided by the deployment specification

describes:

a) A minimum set of facilities(Plug-in), that all

J2EE Platform Product Providers must

provide to Deployment Tool Providers so that

portable J2EE applications can be

) Deployment

The J2EE Deployment API s tandard

differentiates between a configuration

session and deployment. They are distinguished

as follows:

a) Application Configuration involves:

Generation of vendor specific descriptors

which, go into a Deployment Plan.

b) Deployment involves:

ool are:

a) To access the J2EE application archive.

b) To display for editing the deployment

configuration information retrieved from the

deployed

to the Product Provider’s platform

b) A minimum set of facilities that all Tool

Providers must provide in order to interact

with the Product Provider’s plug-in.

Any deployer tool would consist of 2 parts:

a) Configuration

b

Distribute, Start, Stop, Redeploy, and

Undeploy an Application.

3.2. Phases in a Deployment Process

3.3. Configuring Applications for

Deployment using J2EE Deployment APIThe term configuration refers to the process of

prepari

e d b y t h e

javax.enterprise.deploy.model package.

These objects provide a generic interface to

elements in standard J2EE deployment

descriptors.

-? The DDBean representation of a descriptor is

a tree of DDBeans, with a specialized

DDBean called DDBeanRoot, at the root of

the tree.

- DDBeans provide accessors for the element

name, id attribute, root, and text of the

descriptor element they represent.

ng an application or deployable resource

for

deployment to an Application Server.

Types of Configuration InformationThe primary configuration information for an

application falls into two distinct but related

categories:

a) J2EE Configuration

b) App Server-specific Configuration

The mapping between standard J2EE

Configuration descriptors and App server-

specific Configuration descriptors is

m a n a g e d v i a D D B e a n s a n d

DConfigBeans object instances, which

are described next.

DDBeans

- D D B e a n s a r e d e s c r i b

-? The DDBeans for an application are

populated by the model plug-in, the tool

p r o v i d e r i m p l e m e n t a t i o n o f

javax.enterprise.deploy. model.

-? A deployable module (such as WAR module,

EJB module or EAR application) is

r e p r e s e n t e d b y t h e

javax.enterprise.deploy.model.Deployable

Object interface.

- J2EE descriptor properties are represented

by one or more DDBean objects that reside

beneath the DDBeanRoot. DDBean

components provide standard getter methods

to access individual deployment descriptor

properties, values, and nested descriptor

elements.

DConfigBeans

- ?

DConfigBeans (config beans) are the objects

used to convey server configuration

requirements to a deployer tool, and are also

the primary source of information used to

create deployment plans.Config beans are

Java Beans and can be introspected for their

properties. They also provide basic property

editing capabilities.

- DConfigBeans are created from information in

embedded server descriptors, deployment

plans, and input from a deployer tool. A

DConfigBean is potentially created for every

server descriptor element that is associated

with a dependency of the application.

Descriptors are entities that describe

resources that are available to the application,

represented by a JNDI name provided by the

server.

- D

- The structure of deployment plan is App

Server Specific.

- The server specific deployment configuration

for an application is encapsulated in the

javax.enterprise.deploy.spi.DeploymentConfi

guration interface.

- A DeploymentConfiguration can also be

viewed as the object representation of a

deployment plan.

The deployment Process involves following:

a) Obtaining a Deployment Manager

A deployment manager provides an interface

to the Application Server deployment

infrastructure. To initialize a deployment

session in a tool, we create a new deployment

manager.

b) Application Distribution

The distribution of new applications results in

the application archive and the plan being

staged on the selected targets/instances, and

the application being configured into the

domain.

ConfigBean implementation is provided by

the platform product provider (e.g. the App

server provider).

Deployment Configuration- ? A deployment p lan conta ins the

environmental configuration for an application,

referred to as its front-end configuration, which

is persisted by storing externally.

3.4.Deployment Process in J2EE

Deployment API

c) Application Start

The start operation would start the

applications distributed on the target servers,

as represented by the TargetModuleID.

J2EE deployment specification introduces

standardization for deployment with respect to

contract between Application Servers and

deployment Tool, however it still does not directly

resolves all the challenges associated with

currently followed deployment approaches,

consider the following:

- It only decouples the Deployment Tool from a

Application Server and enables tool vendors

to develop standard application server

independent deployment tools

- The standard deployment tool would still

require human intervention since application

server specific configuration (DConfigBean) is

to be dynamically retrieved by the tool and

provided to user based upon which user

p rov ides appropr ia te conf igura t ion

information

- Automation of deployment is possible for

specific J2EE application by developing a

custom deployment utility, however if there are

changes in the configuration requirement of

the J2EE application then the code of the utility

also needs to be modified resulting in

maintenance overhead of the utility.

- In case an automated deployment service is to

be developed for a particular J2EE

Application/Product then it has to be

developed for all the supported Application

servers which add to maintenance overhead.

4. Technical Solution

Although J2EE Deployment architecture does

not solves the problem entirely, nevertheless it is

a definitely an enabler technology which can be

exploited and extended to achieve the desired

objective of simplified automation of the

deployment process of given J2EE based

Application/Product. This paper introduces the

concept of “Generic Container Deployment

Framework” based upon the J2EE Deployment

Specification and is described below:

The objective of this framework is to automate the

Deployment process and eliminate/minimize the

learning overhead of using Vendor specific

deployment mechanism. Following are some of

the key aspects on basis of which the framework

is designed:

- A typical J2EE Application Deployment

requires to perform two things first is to

configure the Application for the target

Application (resulting in creation of

Application server specific deployment plan)

and second is to actually deploy it on the

t a r g e t ( i n v o l v i n g

distribute/start/stop/redeploy), however since

automation of the second aspect is simple and

straightforward using the J2EE deployment

API therefore this framework focuses more on

the first aspect which is more challenging.

- This framework is built upon the concept of

J2EE deployment API, where (as we have

already discussed) there is a notion of

DDBean and DConfigBean, DDBean

corresponds to the standard configuration

4.1. Generic Container Deployment

Framework

elements in a typical J2EE deployment

descriptor and DConfigBean corresponds to

the associated Application Server specific

configuration details for that DDBean.

- Now since DDBean and DConfigBean are

simple stateful objects (POJOs) representing

the standard J2EE deployment descriptor

element and corresponding Application

Server specific Configuration element details,

therefore their states can be serialized and

stored externally and later on instantiated

when required.

- Each DDBean or DConfigBean objects have

set of attributes where each of them can either

have a simple string value or their value can

actually be another DDBean or DConfigBean,

therefore for storing/representing their state

externally XML is the most appropriate format.

- The elements of standard J2EE deployment

descriptors or in other words types of DDBean

are predefined and hence the corresponding

Application Server specific Configuration

elements or in other words types of

DConfigBeans for each of the Application

Server, is also predefined.

- During deployment of J2EE Application on

target Application server broadly four actions

can be performed :

1. CreateDeploymentPlan

2. Distribute

3. DistributeAndStart

4. Redeploy

4.1.1. Basic ArchitectureTaking into consideration the above aspects a

simplified “Generic Container Deployment

Framework”is depicted in the figure below and

describe subsequently.

- The structure of this XML file is predefined

(Schema/Dtd predefined) based on the

existing standard DDBeans types and their

Container Deployment Descriptor (CDD)

XML file which is used by this framework for

storing the application configurations of the

specific J2EE

Application to be deployed on the target

Application Server.

corresponding DConfigBean types for all the

Compliant J2EE Application Servers.-

- The XML file or the Container Deployment

Descriptor only stores the configuration

details of DDBeans and their attributes which

needs to be configured, for rest it assumes

default values as present in the J2EE

deployment descriptor for the Application

archive being deployed.

- XML file or the CDD also captures the

relationship between a given DDBean

deta i l /s ta te and i ts cor respond ing

DConfigBean detail/state.

- The CDD also stores information for

Deployment Actions to be performed during

deployment out of the possible four viz.

Crea teDep loymentP lan , D is t r ibu te ,

DistributeAndStart & Redeploy.

- The CDD is specific to an Application Server

therefore different CDDs would exist for each

Application Server on which the given J2EE

Application is to be deployed.

Generic Container Deployer

This is a command line utility which takes

operation-type, the location of the CDD file and

the deployment URL of the target Application

Server as its argument and performs the actions

specified in the CDD for the target server. The

command would look something like this:

c o n t a i n e r D e p l o y e r - d e p l o y – f i l e

C : \ c o n f i g \ s a m p l e C D D . x m l – u r l

deployer:WebLogic:localhost:7001

This utility implements the Tool Provider part of

J2EE1.4 Compliant

Application Server of any Vendor

J2EE Deployment API

(Server Implementation)

Generic Container Deployer

(command-line utility)

J2EE Deployment API

(Tool Implementation)

Fig: Generic Container Deployment Framework

J2EE

Deployment

API

Contract

Container Deployment Descriptor

Input

the J2EE Deployment specifications, however

unlike the normal implementations (as intended

by the specification, since App-Server specific

configuration

attributes are retrieved dynamically) where the

tool is essentially a GUI for user to interactively

provide application server specific configuration

information, this utility is simple and takes the

consolidated

inputs from a single XML file (CDD) instead,

thereby eliminating any user interaction with tool.

The Generic Container Deployment Framework

i s c a p a b l e o f d e p l o y i n g J 2 E E

Applications/Products

on any Applications Server which is J2EE1.4 or

later compliant, since from J2EE1.4 onwards

support

for J2EE Deployment API specifications is made

mandatory for all th

J2EE1.4 Compliant Application Server

of any Vendor

e compliant Application

Server.

4.1.2. Generation of Container

Deployment Descriptor or CDDThe above framework simplifies or rather

provides a mechanism to automate the

deployment of J2EE Applications/products

across all vendor Application Server, however

there is still some amount of learning/skill

required to generate the target CDD XML files,

and we need to minimize that aspect. Now as we

are targeting to automate deployment specifically

for situations where we need to do repeated or

multiple deployment of the same J2EE

application therefore by adding overhead of

doing a manual deployment just for the first time

we can achieve our objective of automating all the

subsequent deployment of the same application.

The details on how the framework achieves this

follows:

- Considering the fact that there are quite a few

open-source GUI tools based on standard

J2EE Deployment specification, we exploit

them instead re-inventing the wheel, and

essentially enhance them by developing a

“Generic Container Deployment Framework”

specific Plug-in for the tool.

- The Plug-in is responsible for intercepting

each of the Application server specific

configuration and deployment actions

performed by the end user for deploying the

given J2EE Application, and store that

information in the CDD XML file format.

- The End-user has to manually perform the

Configurations and deployment actions for

the first time which would generate the

required CDD file automatically and is used

for all the subsequent deployment of that

J2EE application using the “Generic

<ContainerDeploymentDescriptor>

<CreateDeploymentPlan>

<EnterpriseApplicationConfig>

<DDBean>

<Name>display-name</Name>

<Value>sampleJ2EE-EAR</Value>

</DDBean>

<DConfigBean>

<Name>application-name</Name>

<Value>sampleJ2EE-EAR</Value>

</DConfigBean>

</EnterpriseApplicationConfig>

<WebApplicationConfig>

</WebApplicationConfig>

</CreateDeploymentPlan>

<DistributeAndStart/>

</ContainerDeploymentDescriptor>

Container Deployer” command-line utility.

The above mechanism takes care of generating

the CDD of one target Application Server for the

given J2EE Application and can be used for

automating all the subsequent deployment of that

application on the same target server, however in

case the if the application needs to be deployed

repeatedly or multiple times on different

Application server (particularly required for J2EE

4.1.3. Generation of CDD for multiple

Application Servers

Application products) then additional mechanism

needs to be provided in the framework, same is

described

below.

- The Framework or particularly the “Generic

Container Deployer” utility provides a

mechanism to export the CDD of a given J2EE

Application for one Application Server to a

CDD of the same J2EE Application for another

Application Server, using a command similar

to : containerDeployer -export –file

C : \ c o n f i g \ s a m p l e C D D . x m l – t a r g e t

WebSphere

?

- The challenge for the utility is to translate from

one Application Server specific DConfigBean

to another Application Server specific

DConfigBean for given standard DDBean

information because DConfigBeans are not

standard and each Application Server will

have its own DConfigBean types. However

since each DConfigBean corresponds to

standard DDBean and there are limited

number of popular J2EE compliant

Application Servers, therefore the frameworks

provides a repository of all the DConfigBean

type definition for each popular Application

Server in individual XML files.

- The individual DConfigBean type definition

files also stores the relationship with

corresponding standard DDBean, and during

the export operation the utility read/refers to

this information to translate the DConfigBean

type information for target Application Server

and the value of individual DConfigBean

at t r ibutes are picked up f rom the

corresponding DConfigBean attribute of the

source CDDFig: Generating Container Deployment Descriptor using

Open-Source J2EE Deployment Tool

J2EE Deployment API Based,

Open-Source, GUI Tool

Generic Container

Deployment Plug-In

J2EE1.4

Compliant

Application Server

of any Vendor

J2EE Deployment API

(Server Implementation)

J2EE Deployment API

(Server Implementation)

Container

Deployment

Descriptor

J2EE Deployment

API ContractOutput

User Provides

Configuration

Information

5. Limitations- For creating the DConfigBean type definition

repository there is a dependency on the

Application server vendor to make this

information public and for Application Server

who have not made this information public (or

is not easily determined), cannot be

supported for the export feature of this

framework

- The framework does simplifies the

dep loyment mechan ism o f J2EE

Applications on different vendor Application

servers however for practically installing a

J2EE application on Target Application Server

from scratch still requires some amount

Application server specific steps particularly

for creating platform services such as JDBC

Datasource and connection pools, although

J2EE expert committee has come-out with

JSR77 which standardizes the management

of these services but their creation is still

Application Server specific

Generic Container Deployment Framework

provides, particularly ISVs (having J2EE based

Products) a simple & transparent deployment

user-experience of their product on different

applications servers. It minimizes the learning

curve required by end-customer of their product

with respect to applicationserver specific

deployment process. For ISV it’s also a cost-

saving specially by reducing the overhead of

maintaining Application-Server specif ic

automated deployment scripts for all the

supported Application-Server.

Asvin Ramesh

HCL Technologies , America Inc.

330 Potrero Avenue, Sunnyvale, CA 94085

United States

Phone +1 408 523 8333

Fax +1 408 733 0482 Mobile +1 408 368 6814

6. Conclusion

For More Information contact

Target

Container

Deployment

Descriptor

Repository of every

compliant App.

Server specific

DConfigBeans and

their attributes

Existing Container

Deployment

Descriptor

Output

Reads

Generic

Container

Deployer

(command-

line utility)

Input

Fig: Generating CDD for target Application server from

CDD of existing (different) Application Server

Hello there. I am from HCL Technologies. We work behind the scenes, helping our customers to shift paradigms and start revolutions. We use digital engineering to build superhuman capabilities. We make sure that the rate of progress far exceeds the price. And right now, 45,000 of us bright sparks are busy developing solutions for 500 customers in 17 countries across the world.