Welcome!

IBM Cloud Authors: Zakia Bouachraoui, Elizabeth White, Yeshim Deniz, Pat Romanski, Liz McMillan

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
    The deluge of IoT sensor data collected from connected devices and the powerful AI required to make that data actionable are giving rise to a hybrid ecosystem in which cloud, on-prem and edge processes become interweaved. Attendees will learn how emerging composable infrastructure solutions deliver the adaptive architecture needed to manage this new data reality. Machine learning algorithms can better anticipate data storms and automate resources to support surges, including fully scalable GPU-c...
    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 ...
    The explosion of new web/cloud/IoT-based applications and the data they generate are transforming our world right before our eyes. In this rush to adopt these new technologies, organizations are often ignoring fundamental questions concerning who owns the data and failing to ask for permission to conduct invasive surveillance of their customers. Organizations that are not transparent about how their systems gather data telemetry without offering shared data ownership risk product rejection, regu...
    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...
    Poor data quality and analytics drive down business value. In fact, Gartner estimated that the average financial impact of poor data quality on organizations is $9.7 million per year. But bad data is much more than a cost center. By eroding trust in information, analytics and the business decisions based on these, it is a serious impediment to digital transformation.
    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...
    Predicting the future has never been more challenging - not because of the lack of data but because of the flood of ungoverned and risk laden information. Microsoft states that 2.5 exabytes of data are created every day. Expectations and reliance on data are being pushed to the limits, as demands around hybrid options continue to grow.
    Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to ...
    Enterprises have taken advantage of IoT to achieve important revenue and cost advantages. What is less apparent is how incumbent enterprises operating at scale have, following success with IoT, built analytic, operations management and software development capabilities - ranging from autonomous vehicles to manageable robotics installations. They have embraced these capabilities as if they were Silicon Valley startups.
    As IoT continues to increase momentum, so does the associated risk. Secure Device Lifecycle Management (DLM) is ranked as one of the most important technology areas of IoT. Driving this trend is the realization that secure support for IoT devices provides companies the ability to deliver high-quality, reliable, secure offerings faster, create new revenue streams, and reduce support costs, all while building a competitive advantage in their markets. In this session, we will use customer use cases...