WHITE PAPER J2EE Application Deployment Framework (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.
Table of Contents 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 12
1. Abstract 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 nonstandard 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. 2. Introduction 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 file to a J2EE compliant Application 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. Creation Enterprise components created by component provider or developer J2EE Components Assembly Assembled into a standard portable archive by application assembler Deployment Deploy to target J2EE Container (Application Server) by applicationdeployer Enterprise Components J2EE Standard Archive Deploy J2EE Compliant Application Server/Container Fig: Development Life Cycle of J2EE Application
2.1. 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. 2.2. Short Coming of Current Approaches 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. 3. Enabler Technology 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 3.1. Overview of J2EE Deployment API 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. The Deployment architecture defines implementation requirements for both tools and J2EE platform products. The primary responsibilities of a Tool are: a) To access the J2EE application archive. b) To display for editing the deployment configuration information retrieved from the J2EE platform product. The J2EE platform product s primary 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 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. 3.2. Phases in a Deployment Process Any deployer tool would consist of 2 parts: a) Configuration b) Deployment The J2EE Deployment API standard 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: Distribute, Start, Stop, Redeploy, and Undeploy an Application.
3.3. Configuring Applications for Deployment using J2EE Deployment API The term configuration refers to the process of preparing an application or deployable resource for deployment to an Application Server. Types of Configuration Information The 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 serverspecific 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 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. -? 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. - DConfigBean implementation is provided by the platform product provider (e.g. the App server provider). Deployment Configuration -? A deployment plan contains the environmental configuration for an application, referred to as its front-end configuration, which is persisted by storing externally. - 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. 3.4.Deployment Process in J2EE Deployment API 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. c) Application Start The start operation would start the applications distributed on the target servers, as represented by the TargetModuleID. 4. Technical Solution 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 provides appropriate configuration 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.
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: 4.1. Generic Container Deployment Framework 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 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 Architecture Taking into consideration the above aspects a simplified Generic Container Deployment Framework is depicted in the figure below and describe subsequently. 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. - The structure of this XML file is predefined (Schema/Dtd predefined) based on the existing standard DDBeans types and their Container Deployment Descriptor Input Generic Container Deployer (command-line utility) J2EE Deployment API (Tool Implementation) J2EE Deployment API Contract J2EE Deployment API (Server Implementation) J2EE1.4 Compliant Application Server of any Vendor Fig: Generic Container Deployment Framework 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 detail/state and its corresponding DConfigBean detail/state. - The CDD also stores information for Deployment Actions to be performed during deployment out of the possible four viz. C r e a tedeploymentplan, D i s tribute, 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
<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> 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. J2EE1.4 Compliant Application Server of any Vendor 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 the compliant Application Server. 4.1.2. Generation of Container Deployment Descriptor or CDD The 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
Container Deployer command-line utility. 4.1.3. Generation of CDD for multiple Application Servers 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 J2EE Deployment API Based, Open-Source, GUI Tool J2EE Deployment API (Server Implementation) J2EE Deployment API Contract J2EE1.4 Compliant Application Server of any Vendor User Provides Configuration Information J2EE Deployment API (Server Implementation) Generic Container Deployment Plug-In Output Container Deployment Descriptor Fig: Generating Container Deployment Descriptor using Open-Source J2EE Deployment Tool 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 attributes are picked up from the corresponding DConfigBean attribute of the source CDD
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 Existing Container Deployment Descriptor Input Generic Container Deployer (commandline utility) Output Target Container Deployment Descriptor Reads Repository of every compliant App. Server specific DConfigBeans and their attributes Fig: Generating CDD for target Application server from CDD of existing (different) Application Server supported for the export feature of this framework - The framework does simplifies the deployment mechanism of 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 6. Conclusion 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 costsaving specially by reducing the overhead of maintaining Application-Server specific automated deployment scripts for all the supported Application-Server. For More Information contact 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 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.