Using custom installation packages to install and update WebSphere Application Server in large development environments

Document options Document options requiring JavaScript are not displayed Rate this page Help us improve this content

Level: Intermediate

Tim Fors, Install Architect, WebSphere Application Server, IBM Canada

26 Mar 2008

Install, update, and configure multiple IBM® WebSphere® Application Server V6.0 and V6.1 installations on multiple machines in an optimized fashion and with consistent results.

Introduction

Within a large development organization, there can be dozens, if not hundreds, of application server runtimes installed on developers' workstations. Developers use these server installations as test environments with tools, like IBM Rational® Application Developer, to unit test applications in development. This article provides recommendations for installing, updating, and configuring IBM WebSphere Application Server on such machines in an optimized fashion to achieve consistent and reliable results. These guidelines can also be generally applied in other contexts; for example, as a method to keep development environments in sync with production, to potentially reduce problems that could occur when promoting application code from development to staging and, ultimately, to production.

Back to top

Flexibility and consistency with a unified approach

At a high level, the best approach for optimizing installations of WebSphere Application Server is to:

WebSphere Test Environments (WTE) A WTE is a standard installation of a WebSphere product (such as WebSphere Application Server, WebSphere Portal, and so on); it is not a different version of the product created specifically for development testing. Any installed WebSphere product can be used as a WTE, provided the development tool is configured to use the product as such (and the product is at the required maintenance level).

1. Create a customized installation package (CIP) using the IBM Installation Factory for WebSphere Application Server.
2. Distribute that package out to developers’ workstations.
3. Invoke the package to install or update a developer's WebSphere Test Environment.

Virtually any distribution technology can be used in this process, but these recommendations focus on two examples:

• IBM Solution Assembly Toolkit
• IBM Rational Installation Manager.

The pros and cons of using these tools are discussed later.

A CIP can be used to install a new instance of WebSphere Application Server from scratch at whatever level of maintenance you require. You can also use a CIP to apply updates to an existing installation. In addition to WebSphere product files, a CIP can also contain your own assets, such as EAR files, scripts, and so on, which it can use to automatically configure WebSphere Application Server and deploy your applications. This activity happens in a nearly turnkey fashion to get you up and running quickly and painlessly.

You can think of a CIP as a "gold master" installation image of WebSphere Application Server that you can use to install and configure WebSphere Application Server throughout your organization in a highly consistent manner. Because you can use a CIP for new installations and to update existing installations, you only need to produce one package for installing on all machines; your users will end up with the same results regardless of their starting point. Therefore, a CIP can be used as part of your update and service strategy as well as your installation strategy.

That said, there might be times when you might want to use the more "traditional" service strategy, in which a specific maintenance package is distributed to individual machines and installed using the WebSphere Application Server Update Installer. This method might be more expedient if, for example, there is an urgent interim fix that must be installed, or if there are any concerns about entitlement or licensing (since a CIP can always be used to install WebSphere Application Server from scratch, but not a maintenance package).

Replacing the WTE shipped with Rational Application Developer The WTE that comes bundled with Rational Application Developer is an actual CIP that was created by Rational using Installation Factory. When you create your own CIP, configured as you require, you can either replace the WTE with your CIP, or you can install a new one.

Your overall service strategy will likely consist of a combination of these two approaches: CIPs for major updates that are performed on a regular basis (which might include new versions of your own assets), and the WebSphere Application Server Update Installer for more ad hoc, one-off updates (where the use of Installation Factory is not practical or justifiable). See the Another method for updating for more information on the traditional approach, and the trade-offs between the two methods.

Whether or not you already have the standard WTE installed, you can use this procedure to replace it or to install additional instances of the test environment. You will find a great deal of flexibility in terms of finding an approach that suits your needs.

To create and implement a CIP, you need to:

1. Decide which assets you want to distribute and install
2. Use Installation Factory to create a CIP
3. Distribute the CIP to other workstations
4. Install the CIP on a workstation
5. Configure Rational Application Developer to use your installation as a WTE

These steps are explained in detail below.

1. Decide which assets you want to distribute and install

Determine the set of assets which constitute your required level and configuration of WebSphere Application Server that needs to be distributed to developers' machines. This can be some combination of the following:

• Standard WebSphere Application Server installation image (such as from the V6.1 product CD or downloaded from Passport Advantage). This is the only software that is required as input by Installation Factory.

• Maintenance packages, such as a refresh pack, fix packs, or interim fixes, downloaded from the WebSphere Application Server support site. In addition to maintenance packages for the application server, this can also include maintenance packages for the Java™ SDK (installed as part of WebSphere Application Server), which has its own fix packs and interim fixes. If you will be using the CIP to update existing installations, make sure the fix pack level of the Java SDK in the CIP is the same or higher than the one that will be updated. It is a good idea to build a CIP with both WebSphere Application Server and the SDK at the same fix pack level.

• Scripts for one-time execution during installation. Uninstall-time scripts can also be included, typically to undo whatever the install-time scripts did.

Profile templates When you add any profile customization assets to your CIP, Installation Factory will generate what's called a profile template. The CIP will install this template when it installs WebSphere Application Server. These templates are what WebSphere Application Server uses to create profiles. They are also used by other WebSphere products to augment a WebSphere Application Server profile with the configuration for that product. Installation Factory uses profile templates to execute your profile customization actions as an integrated part of profile creation and augmentation. A template contains a series of actions that can perform required configuration and application deployment steps during profile creation or augmentation. The template that is generated by Installation Factory contains actions that will process your profile customization assets in the specified order (for example, import a CAR, deploy an EAR, run a script, and so on). You can simply choose this template within the Profile Management Tool (PMT), or pass the template to the manageprofiles command, just as you would to create a standard WebSphere Application Server profile. The profile creation mechanism within WebSphere Application Server looks at the actions in the template and invokes them one after the other. Using a profile template to execute configuration actions leverages WebSphere Application Server’s rich infrastructure, and provides a user experience that is tightly integrated with the standard profile creation tools.

• Profile customization assets, which can be used to configure WebSphere Application Server and deploy applications during the creation of one or more profiles. These can include:

  • An EAR file or enhanced EAR file, if included, will be deployed automatically when the CIP is installed and a profile is created. Default values will be used for all of the options that are supported by WebSphere Application Server for application deployment. (Advanced deployment of EARs can be performed by including the EAR in the CIP as just an ordinary file and also including a script that deploys the EAR, described below.)

  • A configuration archive (CAR) file contains a snapshot of the configuration documents captured from a profile on some master WebSphere Application Server installation. This file can also contain applications that were deployed in the profile.

    By putting a CAR file into the CIP, you standardize the WebSphere Application Server configuration (and, possibly, the application deployment) at an organization-wide level. Your developers get this standard configuration when the CIP is installed, and then can use the usual WebSphere Application Server admin tools to further customize it, if necessary.

    Using a CAR file can also help reduce the amount of time it takes to create a WebSphere Application Server profile, and since profile creation is usually done during installation, using a CAR file also helps streamline the installation process.The command to create a CAR file is documented in the WebSphere Application Server Information Center (search for exportWasprofile). The Installation Factory documentation also provides information on using CAR files in a CIP.

  • Configuration scripts for configuring the application server and environment at profile creation time. Scripts can be created in ANT, shell/bat scripts, Jython, JACL (deprecated), or Java. (Scripts to be executed during profile deletion can also be included.) These scripts can be used instead of (or in addition to) a CAR file. The CAR captures static, relocateable configuration information, while the scripts can be used to perform more dynamic configuration steps that are specific to the environment in which WebSphere Application Server is installed. A combination of these two mechanisms is typically required.

• Any other miscellaneous files that should be installed, such as JAR files developed in your organization that contain common classes for utilities or frameworks that are typically used in applications.

You can see from the above list that there can be many different assets involved in installing and configuring WebSphere Application Server, all of which depend on the requirements of your specific environment. Once you have determined the set of assets that you need -- and that you have confirmed work together -- it makes sense to bundle them up into a neat and tidy package so that their collective installation and configuration processes can be automated, which is precisely what Installation Factory does when it creates a CIP.

2. Use Installation Factory to create a CIP

Keeping WTEs in sync with production servers CIPs can also be used in other installation scenarios (installation on production servers, for example) and as such can provide a very convenient mechanism for keeping development environments in sync with production environments.

Use the latest version (6.0 or 6.1) of Installation Factory to assemble the assets you have collected into a custom installation package (CIP). Installation Factory has several panels where each of these asset types can be provided as input. If desired, you can also omit optional features during this process.

To launch Installation Factory, go to the bin directory and execute either the ifgui or ifcli command to launch it in GUI mode or command line mode, respectively. (See the Information Center for details.) Enter the utility and framework JAR files on the Additional Files panel. These files will be installed by the CIP, and can be processed by your configuration scripts to, for example, automatically deploy at profile creation time. Alternatively, they can simply be installed and left to be manually deployed when desired.

You must provide an appropriate identifier and version number for your CIP. The identifier must be universally unique to avoid possible collisions with other CIPs, and when a newer version of a given CIP is created, the version number must be incremented to avoid possible collisions with prior versions of the same CIP (Figure 2).

Create one CIP per platform WebSphere Application Server installation packages are platform-specific, so you'll need to create a CIP for each platform on which WebSphere Application Server will be installed. Conveniently, Installation Factory V6.1 supports cross-platform CIP generation, which means you can use Installation Factory on a Linux® or UNIX® machine to generate a CIP for Windows®.

You can generate a CIP from within Installation Factory, but generally you will want to simply save the input that you've entered into the wizard. This information is saved a build definition file (BDF), which is an XML document that can later be passed to the Installation Factory command line interface (CLI) to perform the actual CIP build. This enables the CIP to be built in an automated "batch" mode, perhaps as part of some overall larger build process.

The BDF itself can also be created or modified during this build process, if desired, as can the various inputs to the CIP; for example, the build process could build or retrieve each of the assets that will go into the CIP, build a BDF, and then build the CIP itself by invoking the Installation Factory CLI and passing in that BDF. If you create or modify a BDF outside of the Installation Factory, be sure to validate it using an XML parser and the XML schema file that is shipped with Installation Factory.

Installation Factory V6.1 now supports WebSphere Application Server feature packs Installation Factory V6.1 contains support for creating CIPs for WebSphere Application Server Feature Packs. You can also create a new type of package, called an integrated installation package (IIP), which combines the WebSphere Application Server installation with a feature pack installation so that both can be installed and configured with a single turnkey package.

If different variations of the WTE are required, you can create multiple CIPs with different sets of assets in each. For example, if two developers (or groups of developers) require different variations of the WTE, you can create two different CIPs and distribute them appropriately. Similarly, if you actively work on different applications that require different levels or configurations of WebSphere Application Server, you can have both CIP variations installed independently on a machine (in different locations) and use them as test environments.

3. Distribute the CIP to other workstations

At this point, you can distribute the CIP to the appropriate machines using the distribution technology of your choice, whether it be a "push" or "pull" mechanism. Once there, a developer can initiate the installation, or the installation can be automatically initiated by the distribution mechanism.

Although virtually any distribution mechanism can be used for this task, the information in this article has been validated with these technologies:

Keep things in sync by using an Installation Manager wrapper to install the CIP Because Installation Manager is also an installation technology, it can be used to drive the installation of the CIP on a developer's machine even if it is not the mechanism that is used to actually pull the CIP from a centralized server. An Installation Manager package is a wrapper around the CIP that can be transferred to a development machine using another distribution technology, and then installed using Installation Manager (which runs the CIP under the covers). This provides consistency with the installation and update of Rational tools, and keeps the registry information within IM up to date, whereas installing the CIP directly would be considered an "out of band" operation, causing the Installation Manager registry to potentially become out of sync with what is actually installed. In general, you should use an Installation Manager wrapper whenever a WebSphere Application Server CIP is being used with a Rational V7 tool. See Resources for a guide explaining the process of creating and using this wrapper.

• IBM Solution Assembly Toolkit (SAT)
  • SAT is a "push" mechanism, requiring that there is a common administrative user account on each machine.
  • It has broad platform support (broader than Installation Manager, below), which may not be particularly important if all you want to do is distribute the CIP to development workstations.
  • SAT can be used to distribute and install WebSphere Application Server beyond just development machines, such as on staging servers, production servers, and so on, thereby offering a unified approach no matter what the scenario.
  • SAT can be used to combine the WebSphere Application Server installation package with other products or packages into a solution that can be distributed and installed as a unit.
  • SAT is very powerful and flexible, but requires effort to learn and use effectively.
• IBM Rational Installation Manager
  • Installation Manager is a "pull" mechanism, and does not require a common administrative user account on each development machine.
  • Installation Manager is the technology that is used to install and update Rational V7 development tools (such as Rational Application Developer), so developers using that version should also use Installation Manager to install and update their WTEs.

4. Install the CIP

Installation can be performed automatically by the distribution system, or it can be initiated manually; further, it can be done using either the silent install mode or the interactive GUI mode. The user experience when installing a CIP is virtually identical to the standard WebSphere Application Server product installation, even though the CIP is doing considerably more under the covers. Naturally, if the CIP is being installed silently by some other technology, such as SAT or Installation Manager, the user experience is determined by that other technology.

As mentioned earlier, a CIP can be used to perform a new WebSphere Application Server installation or to update an existing installation.

New installation

When given an installation location that is new (or empty), the CIP will install a new instance of WebSphere Application Server from scratch in that location. The assets in the CIP are processed in this way:

1. The WebSphere Application Server product files (binaries) will be installed at the level of maintenance carried within the CIP (for example, 6.1.0.13 plus interim fixes A and B).

   • Installing the WebSphere Application Server product files at the 6.1.0.13 level is done in just one step, like a full installation, not in the two steps that would otherwise be needed (to install V6.1 followed by the 6.1.0.13 fix pack). This significantly reduces the amount of time it takes to get WebSphere Application Server installed at the desired level of maintenance. Be aware, however, that this also means that the baseline maintenance level for this installation is 6.1.0.13 and cannot be rolled back to any lower level, such as 6.1.0.0 or 6.1.0.7.
   • Interim fixes are installed one by one by the CIP, in the appropriate order (if the order is significant).
   • An additional XML document, called CustomInstallInfo.xml, is installed to indicate that the installation was created by a CIP, rather than a standard product installation image, and to provide information about the CIP that was used.
   • Post-installation, there are no limitations or restrictions imposed on your newly installed WebSphere Application Server environment; because you used a CIP to install it makes no difference in its operation or maintenance. Significantly, using a CIP for the initial installation does not mandate that you use a CIP to apply further updates. The method you use for any maintenance is entirely at your discretion.

Running your install-time scripts before the first profile is created In a V6.1 CIP, the installation program will create an initial profile before it runs any install-time scripts you might have added to the CIP. If this is undesirable (for example, if you want perform some up-front processing after WebSphere Application Server is installed, but before a profile is created), you can use silent installation mode and pass in the option that suppresses the initial profile creation (-OPT profileType="NONE" ). Your installation-time script can then do whatever processing it needs to and, if desired, can then use the manageprofiles command to create a profile from the profile template that the CIP installed -- which is essentially what the installation program itself would have done. Creating multiple profiles at install time The WebSphere Application Server install program creates one profile (at most) at install time. If you want to create more than one profile, you can use the above technique and simply invoke the manageprofiles command multiple times, passing in any unique option values necessary for each profile.

1. All other assets added to the CIP will be installed within the WebSphere Application Server installation directory in a location that is unique to that CIP (in case other CIPs are installed on top of this one later). After they are installed, these assets will automatically be processed by the CIP as follows:

   • Install-time scripts are executed to perform any custom install-time logic you might require.
   • A profile is created. If you did not add any assets to the CIP to perform profile customization, then the profile that is created will be the standard profile that is created by default by the WebSphere Application Server installer. If you did include profile customization assets in the CIP, then they will be used as follows to create the customized profile:
     1. If the CIP contains a CAR file, the file will be imported during profile creation to restore the saved configuration and applications. CAR files are only applicable to standalone application server profiles, not to a deployment manager or other types of profiles.
     2. If the CIP contains configuration scripts, the scripts will be executed during profile creation to perform additional custom profile configuration. Any Jython or JACL scripts that you added to the CIP will be automatically passed into the wsadmin command for execution; your scripts do not need to explicitly call wsadmin.
     3. If the CIP contains an EAR or enhanced EAR file, then the file will be deployed using default values for the deployment options that WebSphere Application Server supports.
     4. If the CIP contains any of the above profile customization assets, then a new entry is added to the PMT, which enables you to easily create more of these customized profiles post-install. Similarly, the manageprofiles command can be used to create additional profiles from the command line.

        In V6.0, the equivalent of the PMT in WebSphere Application Server V6.0 is the Profile Creation Tool (PCT). Every CIP has its own PCT that gets installed, as opposed to extending a single common tool. Also, the name of the command line tool in V6.0 is wasprofiles.

   • Any additional files that are included in the CIP, such as your utility and framework JAR files, will be installed only and not otherwise processed by the CIP -- unless you add a custom configuration script to the CIP to perform such additional processing. For example, this is an option if you want to deploy an EAR file when the standard "defaults only" approach is not sufficient.

Existing installation

When an existing WebSphere Application Server installation is the target of the CIP, the CIP will apply updates in this manner:

1. The combination of CIP Identifier + Version must be unique to this CIP in this installation. Otherwise, the CIP assumes its contents have already been installed and will not perform the remaining steps.

2. WebSphere Application Server product files (binaries) will be updated if the CIP contains a higher level of maintenance than the existing installation. This includes interim fixes. For example, a 6.1.0.3 installation with iFix A could be updated to 6.1.0.3 with iFixes A and B, if that's the only difference between what's in the CIP and what's currently installed. On the other hand, if the CIP is at the 6.1.0.13 level with iFixes C and D, then the installation will be brought up to that level after the CIP has been applied.

3. All other assets will simply be installed into a directory under <WAS_HOME> that is unique for this CIP. This directory name is made unique by using the CIP Identifier and Version as part of the path. A given installation of WebSphere Application Server can potentially have several CIPs installed on top of it -- along with several versions of a given CIP, which essentially means that the assets from each of those CIPs will be installed along side each other in their own unique directories. It’s important to know that a CIP does not attempt to replace or update the assets of a previous version of the same CIP; both sets of assets will be installed and co-exist.

4. Unlike a new installation, a CIP that updates an existing installation does not automatically perform any additional steps on the assets that are installed. For example, install-time scripts are not executed, a profile is not created, configuration archives are not imported, EAR files are not deployed, and so on. In this respect, CIPs applied to an existing installation leaves the decision to perform any additional steps up to you. (Although a profile is not created automatically in this case, you can easily create a custom profile that leverages these assets post-install, using either the PMT or the manageprofiles command line tool. The PMT will automatically have a new entry in it for creating this customized profile, as explained above. At the end of an interactive CIP installation, the wizard offers an option to launch the PMT so that a new profile can be created.)

Augmenting an existing profile

The profile template that is generated by Installation Factory and installed by the CIP can be used to create new profiles, but it can also be used to augment existing profiles. This is a way for you to make changes to the current WebSphere Application Server configuration (or the set of deployed applications) within an existing profile. For example, this is useful if your organization has made changes to the "gold master" configuration and you want your developers to use those changes without having to create a brand new profile; they can simply apply the template to an existing profile and let it make the required changes.

It's important to understand, however, that while the profile template mechanism can be used for both profile creation as well as profile augmentation, it's up to you to ensure that your configuration actions can be successfully executed on an existing profile -- if this is something that you want to support. To further illustrate the difference between profile creation and profile augmentation:

• During profile creation, a new WebSphere Application Server profile is created automatically, and then the actions in your template are applied to it. If your CIP contains a CAR file, then the profile will contain whatever configuration was captured in that CAR; otherwise, the profile will contain the standard out-of-the-box configuration. In either case, when your actions run, they deal with a relatively fixed, well-known starting configuration that can be modified or have applications deployed into it, as required.

• During profile augmentation, there are no such guarantees regarding the starting configuration; a user could have made any number of changes to the profile since it was first created. Because of this, your configuration actions need to be more robust to gracefully handle any arbitrary starting configuration. For example, when deploying an application, your script should check to see if in fact the target server already exists, whether it is appropriately configured, if there is already a deployed application with the same name, and so on. The script then needs to take appropriate actions based on what it finds. If the script simply proceeds based on assumptions about the existing configuration, the possibility of problems or failure are increased.

5. Configure Rational Application Developer to use your installation as a WTE

Multiple WTEs It might be desirable in some cases to have multiple WebSphere Application Server installations coexisting on the same machine simultaneously. Just as this is supported by the standard WebSphere Application Server installation package, it is also supported with CIPs; simply provide a new installation location and WebSphere Application Server will be installed from scratch as described earlier. This feature provides maximum flexibility to accommodate the needs of your organization.

Having followed the CIP process to install WebSphere Application Server, you now want to make sure that Rational Application Developer uses this new installation as a WTE.

If WebSphere Application Serer is installed into Rational Application Developer's runtimes subdirectory, then it will be automatically recognized and used as a WTE.

If WebSphere Application Server is installed elsewhere, you will need to do one of these things to get Rational Application Developer to recognize it:

• Manually define the server. This requires just a few mouse-clicks and browsing to point to the proper directory, and is what users typically do for secondary or remote servers.
• Manually define the server once, move it to a project, and share the project among the team using CVS, Clearcase, a .ZIP file, and so on.
• Write an Ant script or workspace action to drop in a predefined server (in Preferences or in the workspace).
• Write an Ant script or workspace action that uses a server API to create the server dynamically.

Back to top

Alternative A: Add instead of update

Rather than update an existing WebSphere Application Server installation, you can install a new CIP on your machine from scratch and use it as a WTE, and preserve the old WTE as an additional test environment. The older WTE could be uninstalled first (or later), but there is no harm in having multiple WTEs co-exist. In fact, having multiple WTEs enables you to perform side-by-side comparisons, since you can test new applications with different configurations of WebSphere Application Server. Additionally, since this is essentially a new installation, all assets are processed automatically during the installation, avoiding the manual step required to process these assets when updating an existing installation (during which these assets are installed but not processed). On the other hand, reasons why you might want to uninstall an older WTE include:

• To save disk space.
• You are certain that you will no longer need to develop and test using the previous level of software.
• You want to eliminate the possibility of mistakenly using the wrong WTE.

To use a new installation as a WTE:

1. Create a CIP using Installation Factory, as described earlier.
2. Distribute the CIP to the target machines.
3. Install the CIP to a different location from any currently-installed WTEs. It will detect which ports are already being used by those other installations and choose new port values to avoid conflicts. (If the multiple WTEs will not be used at the same time, it might be preferable to always use the same set of ports.) See the WebSphere Application Server Information Center for details on how to do this.
4. If any custom or private updates were made to the WTE configuration on the target machine, you might want to copy it from their existing WTEs to the new one. If the custom configuration is easy for the developer to recreate, then they can just do so manually using the standard WebSphere Application Server admin tools or by running scripts against the new installation. Alternately, they might also be able to export their configuration into a CAR file and import it into the profile on the new installation. This depends on the nature of the configuration customizations that need to be brought forward from the previous installation.
5. Configure Rational Application Developer to use this new WebSphere Application Server installation as a WTE.
6. If desired, uninstall the older WTE.

Back to top

Alternative B: Another method for updating

Rather than use the Installation Factory for updating a WTE, you can also use the WebSphere Application Server Update Installer to apply individual maintenance packages to an installation. This was the usual approach prior to the introduction of Installation Factory. One advantage to using the Update Installer is that it minimizes the size of the package that needs to be distributed to individual machines, especially if what ia being applied is only a set of interim fixes. Of course, as more maintenance packages are added, the size of the update grows considerably and the advantages diminish.

There are also disadvantages:

• The Update Installer method lacks the consistency and simplicity of using a single CIP for both new installations and updates; a different distributable package must be created, deployed, and installed.
• A CIP can contain more than just updates to WebSphere Application Server product files; it is a complete, turnkey package that can also contain a new WebSphere Application Server configuration, new custom assets (like utility libraries and frameworks), new entries in the PMT for creating customized profiles, and so on.
• The CIP install program "drives" the processing of these assets at install time so that no additional automation mechanism is required.
• A CIP can be applied to any WebSphere Application Server installation at a lower maintenance level to bring the configuration up to the level contained in the CIP, whereas fix packs and interim fixes might not be applicable to the level of WebSphere Application Server that is installed. For example, a CIP at the 6.0.2.17 level can be applied to any WebSphere Application Server installation between 6.0 and 6.0.2.17, whereas the explicit 6.0.2.17 fix pack can only be installed if the current installation is already at the 6.0.2 level or higher. If it is not, the 6.0.2 refresh pack must be installed before the 6.0.2.17 fix pack can be installed.

To use the Update Installer:

1. Obtain the required maintenance packages and the latest version of WebSphere Application Server Update Installer from the WebSphere Application Server support site.
2. Distribute these assets to the desired machines using whichever distribution technology you prefer.
3. Install Update Installer.
4. Run Update Installer to install the maintenance packages.

The Update Installer documentation explains how to install maintenance packages silently or when using the GUI. When performed silently, steps 3 and 4 can be automated to avoid performing multiple steps. A script can be written to automate these steps, making it part of the package that gets distributed and invoked on each target machine. (It is also possible that the distribution technology used in step 3 already provides a way to package the assets and have them processed in an automated fashion.)

Back to top

Conclusion

By following the practices described in this article you can simplify and standardize how WebSphere Application Server is deployed throughout your development organization. With a single customized installation package (CIP), you can install WebSphere Application Server at a given level of maintenance, update existing installations to that same level, customize the WebSphere Application Server configuration, and deploy applications. You can also use these practices to achieve the same goals in other contexts, such as production environments, and doing so will help keep the development environment in sync with others.

Resources

• Cloning a WebSphere Portal V6 installation, IBM developerWorks, April 2007, provides similar guidelines for WebSphere Portal using the IBM Installation Factory.
  
  
• Introducing Installation Factory on WAS 6.1 for i5/OS, provides an overview of using Installation Factory on i5/OS, and is also useful for learning about the tool in general.
  
  
• Consumability Toolkit, IBM alphaWorks, includes references to Installation Factory, Solution Assembly Toolkit (SAT), and other related technologies.
  
  
• Using IBM Installation Manager to deploy WAS Custom Install Packages, includes details on how to use Installation Manager to distribute CIPs and install them in a way that's consistent with the installation of Rational tools.
  
  
• WebSphere Application Server V6.0 Information Center
  
  
• WebSphere Application Server V6.1 Information Center
  
  

• Download WebSphere Application Server maintenance packages
  
  
• Download IBM Installation Factory for WebSphere Application Server V6.0
  
  
• Download IBM Installation Factory for WebSphere Application Server V6.1
  
  
• Download IBM Installation Factory Plugin for WebSphere Extended Deployment V6.0
  
  
• Download IBM Installation Factory Plugin for WebSphere Extended Deployment V6.1

About the author

		Tim Fors is a WebSphere architect focusing on install, update install, and profile management. Tim works at the IBM Software Development Lab in Toronto, Canada. Prior to joining the WebSphere organization, Tim was an architect for the WebSphere Commerce product, and a developer in the compiler and debugger areas within the lab.

Rate this page

Please take a moment to complete this form to help us better serve you. Did the information help you to achieve your goal? Yes No Don't know   Please provide us with comments to help improve this page:   How useful is the information? 1 2 3 4 5 Not useful Extremely useful

Share this.... Digg this story del.icio.us Slashdot it!

Back to top