J2EE Application Deployment Framework · 3.3. Configuring Applications for Deployment using J2EE...
Transcript of J2EE Application Deployment Framework · 3.3. Configuring Applications for Deployment using J2EE...
(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.