Welcome!

IBM Cloud Authors: Liz McMillan, Elizabeth White, Yeshim Deniz, Pat Romanski, Stefan Bernbo

Related Topics: IBM Cloud

IBM Cloud: Article

Best Practices in WebSphere Application Packaging and Deployment

Best Practices in WebSphere Application Packaging and Deployment

Most of the time spent in an application development project is in developing and testing the application. Less time is actually spent designing and creating a repeatable and reproducible packaging and deployment model. A well-designed "build, package, and deploy" model has numerous benefits, including improved developer productivity, reduced turnaround time for builds and code fixes, better consistency in application code, and reinforcement of development policies.

In this article I present the best practices to use in packaging and deploying WebSphere applications. The best practices presented here have been applied to small and large enterprise projects with equal success. Although the focus of this article is WebSphere Application Server 3.5, it can be adopted to WebSphere 4.0 as well. I have created a fictitious application called PetStore to illustrate these practices.

What Are Packaging and Deploying?
Packaging is grouping logically-related classes into JAR files and staging these JAR files and related application runtime resources such as HTML and JSP pages, images, and property files into appropriate directories.

Deploying is installing the code on the destination WebSphere Application Server and configuring the application runtime components such as Web Applications, EJBs, servlets, and JSPs in WebSphere.

Characteristics of an Enterprise Application
A typical enterprise application has the following characteristics:

  • It is implemented using servlets, JSPs, and EJBs.
  • It is integrated with one or more enterprise datasources and applications.
  • The source is version managed using version management software such as Rational ClearCase.
  • There are multiple releases of the application. With every release there are new features, enhancements, and bug fixes.
  • It is promoted through multiple stages - development, integration, test, and production.
  • There are frequent (daily, weekly, and monthly) builds and installs within each stage.
  • Developers, not administrators, know how the application components should be configured in WebSphere.
  • Administrators, not developers, deploy the application in WebSphere.

    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:

  • The same package should be deployable across multiple stages - development through production.
  • The package should be deployable across multiple operating systems - such as NT and Unix - without any change.
  • The configuration of the application in WebSphere should be scripted and the install should either be automated or be executed by administrators.
  • Application environment-specific properties such as datasource locations and authentication information should be configurable during deployment.
  • The deployment model should promote a clear separation between development and administration. That is, developers should define and maintain how the application should be configured in WebSphere and administrators should deploy the application.
  • If multiple Web applications are to be deployed on the same application server, each application's WebSphere configuration should be independent. This way each application can be maintained independently.

    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
    JAR Packaging
    Understanding the purpose and behavior of the different classpaths in WebSphere will help you identify the different types of JAR files and what classes go into these. Table 1 lists the WebSphere classpaths and summarizes the types of classes specified on each of these classpaths.

    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
    Table 2 lists all the JAR files and the corresponding WebSphere classpaths for the PetStore application.

    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:

  • The same XMLConfig scripts can be used to configure the application across multiple stages.
  • Scripts eliminate potential errors that are caused if applications are deployed otherwise.
  • If you have Windows NT in development and Unix in the rest of the stages, the same scripts may be used to configure the application across operating systems.
  • Developers who have the most knowledge of how the application components should be configured can update the XMLConfig scripts and administrators can execute them.
  • If you need to restore a new server in cases of server failure, these scripts can speed up the process dramatically.

    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

  • Gissel, Thomas R. "Understanding WebSphere Classloaders." http://www7.software.ibm.com/vadd-bin/ftpdl?1/ vadc/wsdd/pdf/gisell/UnderstandingWebSphereClassLoaders.pdf. Describes the different classpaths and provides tips on how to package applications.
  • Ant - a Java build tool from Apache: http://jakarta.apache.org/ant/index.html
  • Cygwin - the popular GNU development tools and utilities for Windows: http://sources.redhat.com/cygwin
  • More Stories By Prasad Thammineni

    Prasad Thammineni is the President of jPeople, a leading WebSphere and J2EE
    consulting services firm that offers architecture, mentoring, design,
    development, training, performance assessment and tuning services. He and
    his team have designed numerous J2EE and WebSphere solutions since WebSphere
    1.0 days. He can be reached at prasad@jpeople.com and for more details on
    jPeople go to www.jpeople.com

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


    IoT & Smart Cities Stories
    Business professionals no longer wonder if they'll migrate to the cloud; it's now a matter of when. The cloud environment has proved to be a major force in transitioning to an agile business model that enables quick decisions and fast implementation that solidify customer relationships. And when the cloud is combined with the power of cognitive computing, it drives innovation and transformation that achieves astounding competitive advantage.
    Machine learning has taken residence at our cities' cores and now we can finally have "smart cities." Cities are a collection of buildings made to provide the structure and safety necessary for people to function, create and survive. Buildings are a pool of ever-changing performance data from large automated systems such as heating and cooling to the people that live and work within them. Through machine learning, buildings can optimize performance, reduce costs, and improve occupant comfort by ...
    René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
    Early Bird Registration Discount Expires on August 31, 2018 Conference Registration Link ▸ HERE. Pick from all 200 sessions in all 10 tracks, plus 22 Keynotes & General Sessions! Lunch is served two days. EXPIRES AUGUST 31, 2018. Ticket prices: ($1,295-Aug 31) ($1,495-Oct 31) ($1,995-Nov 12) ($2,500-Walk-in)
    According to Forrester Research, every business will become either a digital predator or digital prey by 2020. To avoid demise, organizations must rapidly create new sources of value in their end-to-end customer experiences. True digital predators also must break down information and process silos and extend digital transformation initiatives to empower employees with the digital resources needed to win, serve, and retain customers.
    IoT is rapidly becoming mainstream as more and more investments are made into the platforms and technology. As this movement continues to expand and gain momentum it creates a massive wall of noise that can be difficult to sift through. Unfortunately, this inevitably makes IoT less approachable for people to get started with and can hamper efforts to integrate this key technology into your own portfolio. There are so many connected products already in place today with many hundreds more on the h...
    Digital Transformation: Preparing Cloud & IoT Security for the Age of Artificial Intelligence. As automation and artificial intelligence (AI) power solution development and delivery, many businesses need to build backend cloud capabilities. Well-poised organizations, marketing smart devices with AI and BlockChain capabilities prepare to refine compliance and regulatory capabilities in 2018. Volumes of health, financial, technical and privacy data, along with tightening compliance requirements by...
    Charles Araujo is an industry analyst, internationally recognized authority on the Digital Enterprise and author of The Quantum Age of IT: Why Everything You Know About IT is About to Change. As Principal Analyst with Intellyx, he writes, speaks and advises organizations on how to navigate through this time of disruption. He is also the founder of The Institute for Digital Transformation and a sought after keynote speaker. He has been a regular contributor to both InformationWeek and CIO Insight...
    Digital Transformation is much more than a buzzword. The radical shift to digital mechanisms for almost every process is evident across all industries and verticals. This is often especially true in financial services, where the legacy environment is many times unable to keep up with the rapidly shifting demands of the consumer. The constant pressure to provide complete, omnichannel delivery of customer-facing solutions to meet both regulatory and customer demands is putting enormous pressure on...
    Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...