Introduction

WebSphere Commerce V6.0 builds on over nine years of experience delivering market-leading e-commerce solutions. The V6.0 release includes enhancements in the area of foundational leadership: Simplify the development, management, and delivery of business functionality while maximizing reliability, performance, and scalability. In this overview, we help you get started using the following new deployment features in V6.0:

• Leveraging the WebSphere Installation Factory.
• J2EE packaging improvements.
• Profile exploitation.
• Application updates via WebSphere Application Server fine grained updates.
• Update installer (UPDI) extensions for WebSphere Commerce.
• Simplified clustering.

We will also touch on the new features in WebSphere Application Server (hereafter called Application Server) V6.0 that we exploited, and the benefits from leveraging those features.

Back to top

Installation and packaging

We begin with an overview of the Installation Factory, which explains the benefits of using this new component. The next section discusses the new J2EE packaging features that have been added to WebSphere Commerce V6.0.

Back to top

Leveraging the WebSphere Application Server Installation Factory

The existing process for installing, updating, and configuring an application server installation is time consuming and repetitive. The process includes installing Application Server, and then updating the installation with refresh packs, fix packs, and interim fixes. Once the Application Server has been updated to the appropriate version, you need to create and configure profiles before applications are properly installed and tuned. Then depending on the environment and number of systems, this process must be repeated to create multiple installations, often creating the same image on a number of machines.

The installation process for WebSphere Commerce V6.0 takes advantage of the IBM Installation Factory, introduced in WebSphere Application Server V6.0.1. The Installation Factory enables an administrator to build custom, repeatable, pre-packaged installations, including applications and configurations, to facilitate reliable, one-click time-saving installations.

The Installation Factory provides a simple mechanism for grouping numerous inputs and creating a custom install package for Application Server as an output. The inputs to customize the installation can be maintenance packages, scripts, or applications to install. You can use the resulting custom installation package to create installation for deployments, demonstrations, or other purposes.

WebSphere Commerce V6.0 ships a custom install package (CIP) image instead of the standard WebSphere Application Server CD. You can use the new CIP image to:

• Install a new copy of WebSphere Application Server, including the packaged maintenance.
• Update an existing installation of WebSphere Application Server to the level required by WebSphere Commerce V6.0 (included in the CIP image).

By leveraging the Installation Factory, you reduce the total installation time of WebSphere Commerce because you spend less time installing the original image and using the update installer to install the maintenance. You also reduce the complexity of the WebSphere Commerce installation code.

Back to top

J2EE packaging improvements

The J2EE specification outlines the packaging format of J2EE applications. This package is called an Enterprise Application Archive (EAR). It is a single zip file with an .ear extension that contains special files that describe the application. The EAR file contains all of the file assets required to run the J2EE application. These include (but may not be limited to):

• Jar files
• EJB modules
• Web modules
• Connector modules

WebSphere Application Server uses the EAR file to distribute your application throughout your distributed environment. Therefore, it is imperative that this EAR file contains all files needed for your application.

In previous releases of WebSphere Commerce, many files required at runtime were stored outside of the EAR file. This made it difficult to distribute the application throughout your environment. In version 6.0, the WebSphere Commerce application has been repackaged. All files required at runtime are now inside the EAR file. WebSphere Application Server can now easily distribute the application throughout the environment.

Some key files that have been moved into the EAR file:

• Tools Framework configuration files (xml/tools)
• Messaging files (xml/messaging)
• Instance configuration file (instances/instance/instance.xml -> EAR/xml/config/wc-server.xml)

Back to top

Application deployment enhancements

This section focuses on WebSphere profiles and the application updates enhancements in WebSphere Commerce V6.0.

WebSphere profiles

Profiles are a new concept in WebSphere Application Server V6.0 and have been fully exploited in WebSphere Commerce V6.0. Profiles are a replacement of the WebSphere "instances" concept that existed in WebSphere Application Server V5.x. Files that make up the Application Server entail two categories:

• Product files include the application binaries needed to run the Application Server.
• User files contain information used by the Application Server, such as defined variables, resources, log files, and so on.

A profile is a collection of these files, creating an Application Server runtime environment. When combined, the core product files (or the installed binaries) and the configuration files (or a profile) make up a fully functional Application Server installation. This sharing of product binary files and the separation of configuration files is an efficient use of disk space when creating multiple configurations. In addition, updates to the binary files are more easily applied as they reside in one location per physical machine, even when multiple profiles are configured.

You have the option of creating a profile during installation time, or create them later. At least one profile is required to have a functional WebSphere installation.

You can create profiles using the ISMP-based Profile Creation Tool (PCT) or using wasprofile.bat/sh. You can manage profiles using wasprofile.bat/sh. The PCT is mostly used for creating profiles and cannot perform functions like delete, listProfiles, or getName. Only wasprofile.bat/sh can perform these functions.

There are three different types of profiles in WebSphere Application Server V6.0: Application Server, Deployment Manager, and Custom. The functionality and packaging of each of those three types are explained in Table 1.

In WebSphere Commerce V6.0, Configuration Manager was updated to take advantage of Application Server profiles. When you create a WebSphere Commerce instance, Configuration Manager creates an Application Server profile for you. It then deploys the WebSphere Commerce EAR file into that profile. You can override the following properties of the Application Server profile:

• Cell name
• Node name
• Starting port

In addition to installing the EAR into the profile, the Configuration Manager also creates a Web server inside the Application Server profile. The Web server is purely a configuration object. It represents an external Web server that is used with your profile. The Web server plays a key role in generating the configuration file for the Web server plug-in. It is the plug-in that determines which server should handle a request for a particular URL. Applications are now mapped to Web servers. You generate a plug-in configuration file for each Web server. The generated plug-in will only contain information for applications that are mapped to that server. You can now generate multiple Web server plug-in configuration files from one cell.

Figure 2 illustrates the default configuration the Configuration Manager creates. Note that the changes apply for WebSphere Commerce Payments as well.

To summarize, each WebSphere Commerce or Payments instance has the following:

• A separate Application Server profile.
• A separate EAR file.
• A separate Web server process.
• A separate Web server configuration file.
• A separate database.

Back to top

Application updates

WebSphere Commerce provides an extensible application. All customers must make some change or customization to the WebSphere Commerce application to meet their own requirements. This is simple as adding some JSPs, or it could involve adding new EJBs.In the past, updating the WebSphere Commerce application was a cumbersome process; for example, if you were using the clustering feature of Application Server.

The application update process has been improved in WebSphere Commerce V6.0 by leveraging the fine grained application update feature of WebSphere Application Server V6.0. In the past, to update the application, you needed to provide a complete new EAR file. Building, installing, and distributing the new EAR file was a time consuming process. In WebSphere Application Server V6.0, you no longer have to provide an entire EAR file.

You can use the following update packages:

• A full application EAR file: If you want to completely replace the entire EAR file with a new copy, you use this option. The installed EAR will be completely replaced with the new EAR. This approach may not be useful if all you need to update is a single JSP. This type of update is used by the WebSphere Commerce Update Installer when installing maintenance to a WebSphere Commerce instance.
• A single file: This option allows you to update a single file in the EAR. The WebSphere Administrative Console guides you through this process by asking you for the source location of the file to be updated and the location within the EAR.
• A single module: You can use this option if you want to add or update a new J2EE module to the application. You would typically use this option if you are deploying an EJB to WebSphere Commerce.
• A partial application: With this option, you can build a zip file that contains a group of files that are added, updated, or deleted in the application. The structure of the zip file must match the structure of the EAR file. All file paths should be relative to the root of the EAR directory.

All WebSphere Commerce tooling that updates the EAR file has been updated to take advantage of this new function. Some examples of these are:

• Publishing a starter store in the WebSphere Commerce Administrative Console.
• Adding an attachment.
• Updating a store logo using WebSphere Commerce Accelerator.
• Installing WebSphere Commerce fix packs.

In addition to this, the documentation that describes how to deploy customizations to WebSphere Commerce has been updated to use this new application update feature. Tutorials were added to guide you through the process of deploying your customizations using the WebSphere Administrative Console.

By using the fine grained application update feature of Application Server, you ensure that your application will be updated correctly. The Application Server will ensure that the changed application files are distributed to all nodes running the WebSphere Commerce application. This also ensures that when you export the application, your customizations are included in the resulting EAR file.

UPDI extensions for WebSphere Commerce

The Update Installer (UPDI) is a tool used to install maintenance on WebSphere products. This tool has been extended to support updating WebSphere Commerce.

The extensions in UDPI ensure that WebSphere Commerce instances are updated properly. The overall process to update is described below.

Update the product install directory:

1. Download and install Update Installer 6.1.
2. Download the WebSphere Commerce fixpack.
3. Launch the Update Installer.
4. Indicate the install path for WebSphere Commerce.
5. Select the update package file to apply.
6. Select to update the WebSphere Commerce install directory.
7. The update installer applies the fixpack to the WebSphere Commerce install directory.

If there are WebSphere Commerce instances, update each instance as follows:

1. Launch the Update Installer.
2. Indicate the install path for WebSphere Commerce.
3. Select the update package file to apply.
4. Select an instance to be updated.
5. The update installer stops the WebSphere Commerce application. If you are in managed node, your deployment manager must be running to install the fixpack.
6. The update installer exports the WebSphere Commerce application to a temporary directory.
7. The update installer updates the temporary copy of the application.
8. The update installer re-installed the application into Application Server.
9. The Application Server distributes the updated application through the environment.
10. The update installer performs any database updates.
11. Restart the WebSphere Commerce application.

In the past, if you were clustered, you had to install the fixpack on all nodes running your WebSphere Commerce instance. This is no longer the case. You just install the fixpack once and Application Server distributes the changes for you.

Back to top

Simplified clustering

Clusters are a set of application servers with the same applications, grouped logically for workload management. The servers that are members of a cluster can be on different host machines, as opposed to the servers that are part of the same node and must be located on the same host machine. A cell can have no clusters, one cluster, or multiple clusters. For information about WebSphere Application Server cluster, see the WebSphere Application Server online help.

There are two types of cluster topology, vertical cluster or horizontal cluster. A vertical cluster has cluster members on the same node, or a physical machine. A horizontal cluster has cluster members on multiple nodes across many machines in a cell.

WebSphere Commerce configures an Application Server stand alone profile for each WebSphere Commerce instance that is created. To cluster WebSphere Commerce machines, you must create an Application Server deployment manager profile.

After you create the deployment manager, add the original WebSphere Commerce node to the deployment manager. This is an overview of the steps:

1. Run the addNode command from the WebSphere Commerce instance's Application Server profile directory. Be sure to use the -includeapps option to ensure that the Websphere Commerce EAR is sent to the Deployment Manager.
2. Recreate Cell Level documents that are lost when adding the node to a deployment manager.

An example command is WC_installDir/bin/config_ant -DinstanceName=demo ReconfigureCell.

After you have added the WebSphere Commerce node to the deployment manager, you can use the WebSphere Administrative Console to start creating horizontal cluster members. If you want to use horizontal clustering, add additional nodes to the deployment manager. This is an overview of the steps:

1. Install Application Server on the new node using the Application Server custom install package shipped with WebSphere Commerce.
2. Install your database client software on the new node.
3. Configure your database client software to connect to the WebSphere Commerce database.
4. Create an Application Server profile or Custom profile.
5. Use the addNode command to add this new profile's node to the deployment manager.
6. Use the Application Server Administrative Console to:
   1. Set the correct WebSphere variable to the path of your JDBC driver jar file. Set this variable at the node level.
   2. Create cluster members on that node.

For complete instructions, see the clustering topic in the WebSphere Commerce Information Center.

In past releases of WebSphere Commerce, you had to manually copy file assets to the new machines. Since WebSphere Commerce has updated its EAR file package and taken advantage of the Application Server application update feature, you no longer need to copy any file assets amongst the application server nodes. The deployment manager ensures that all nodes have the correct files for running the application.

In short, you can cluster WebSphere Commerce just like any other J2EE application.

Back to top

Conclusion

By leveraging the WebSphere Application Server platform, the deployment process of WebSphere Commerce has been greatly improved in version 6.0. New features in the platform translated into simpler installation and management of WebSphere Commerce.

• Installation of WebSphere Commerce is simplified by using installation factory to install Application Server at the level required for WebSphere Commerce.
• WebSphere Commerce instances build on top of Application Server profiles to allow you to manage your WebSphere Commerce instances using the WebSphere Administrative Console.
• The fine grained application update feature is used in several areas of WebSphere Commerce: installing maintenance, publishing stores, and deploying customizations. This allows you to easily deploy changes to WebSphere Commerce in clustered environments with a single step.

Resources

• WebSphere Application Server 6.0 Information Center
  
  
• WebSphere Commerce 6.0 Information Center
  
  

About the authors

Emad Muhanna is the technical owner of WebSphere Application Server and the Globalization Architect at the Electronic Commerce Development organization in IBM Software Group, Toronto Lab. He holds a degree in Computer Engineering from McGill University in Montreal, Canada. His areas of expertise include software globalization, Java™ internationalization and localization, J2EE, WebSphere Commerce, and WebSphere Application Server.

Scott Guminyis the Deployment Architect for WebSphere Commerce. As a key architect on the WebSphere Commerce team, Scott is responsible for architecting the product's installers (including the base installer and fix pack installer), configuration utilities, and migration strategy. In addition to this, he is also the WebSphere Commerce Compatibility Champion and is responsible for ensuring that the product is compatible between releases.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Installation and packaging
• Leveraging the WebSphere Application Server Installation Factory
• J2EE packaging improvements
• Application deployment enhancements
• Application updates
• Simplified clustering
• Conclusion
• Resources
• About the authors
• Comments

Next steps from IBM

• Try: WebSphere Application Server
• Webcast: Using Rational Application Developer with WebSphere Application Server to increase productivity
• Briefing: Building SOA solutions and managing the service lifecycle
• Buy: WebSphere Application Server

My developerWorks community

Dig deeper into WebSphere on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers