IIP overview

An integrated installation package (IIP) is an installation package created with the IBM WebSphere Installation Factory that can install an entire WebSphere software stack, such as an appserver, a supported feature pack, and user files. An IIP can also contain several customized installation packages (CIPs).


Integrated installation packages

To install multiple installation packages in an automated and highly repeatable way, we can create an IIP that aggregates those packages into a single installable package. For example, we can have multiple servers on which we need to deploy WebSphere Application Server and some number of supported feature packs. Instead of having to install each of these products as an independent step on each server, we can create an IIP that will install all of them in a defined sequence.

The Installation Factory user specifies which installation packages to include in the IIP, the order in which they must be installed, and various other details about the desired behavior of the IIP and each of its contained installation packages.

Each product you include in the IIP can be customized separately for greater flexibility. For example, we might run the WebSphere Application Server product installation interactively and then run one or more feature pack installations silently to obtain a seamless installation of the entire set of packages. There is also flexibility as to which contained installation packages actually get installed on any given invocation of the IIP; in other words, we can choose not to install certain packages in the IIP.

Consider the following IIP installation scenario:

  1. Install a CIP containing an appserver product.

  2. Install a feature pack, or a CIP that contains a feature pack and feature pack fixes.

  3. Install another instance of the appserver CIP in another directory on the machine.


An IIP consists of contributions, which are WebSphere products or feature packs. A given contribution can be invoked multiple times if desired. Each of these is referred to as an invocation. For example, we might add an invocation of the contribution for installing WAS multiple times in different directories on the same machine.

Some examples of contributions are the following:

  • A Defined Installation Package (DIP), which is a supported generally available installation package.

  • A CIP that we have previously created

Avoid trouble: Regardless of contribution type, we are responsible for obtaining the software to create installation packages with the Installation Factory (for example, first have the WAS ND product image before including it in an Installation Factory package). The Installation Factory itself is not bundled with any of these packages and it is unable to automatically retrieve them.

Defined Installation Packages

A DIP is a supported installation package such as WAS ND or Feature Pack for Web Services. IBM has provided several pre-configured contribution types which can be added to an IIP and controlled by the IIP installer during installation, which reduces user effort, the possibility of mistakes, and so on. Information about DIPs is not actually built into the Installation Factory, but rather “plugged-in” using XML metadata and the Eclipse plug-in mechanism. The Installation Factory already has extensive metadata for install packages in order to support CIP creation, and this metadata is enhanced to support IIP creation. Without the use of DIPs, you would have to invoke the installation of each package with custom scripts in order for the IIP to be successful. The following contributions are supported:

  • IBM WAS Version 6.1 and 7.0

  • IBM WAS ND V6.1 and 7.0

  • IBM WAS - Express V6.1 and 7.0

  • IBM WAS Trial V6.1 and 7.0

  • IBM WAS - Express Trial V6.1 and 7.0

  • IBM WAS Version 6.1 Feature Pack for Web Services

  • IBM WAS Version 6.1 Feature Pack for EJB 3.0

Installation Integration Bus

Installation packages and related tools can be included in the IIP by the user, and Installation Factory will automatically integrate this installation package with others that might already exist in the IIP, saving time and effort. This integration between the contained installation packages is accomplished by passing information from one package to the next. The underlying infrastructure that enables this integration is referred to as the Installation Integration Bus (IIB, or just Bus). The design allows installation packages and other install-related commands to be plugged in, wired together, and executed through the Bus in a uniform way, allowing otherwise separate installation packages to work together.


We can use macro substitution to take advantage of the Installation Integration Bus. For example, when installing WebSphere Application Server and one or more feature packs using an IIP, the -installLocation option used for the appserver can be automatically reused as the default installation location for each of the feature packs with a macro (for example, $RESV ) so you do not have to specify that location more than once. In many cases only add the feature pack package into the IIP, and Installation Factory integrates it with the other packages. The Bus enables this end-to-end flow of all included packages. See for more information on macros and their use.

IIP installation status and progress

An integrated installation package contains an API which allows an application to launch the IIP installer and retrieve information pertaining to the running installation. The API provides a standardized way to retrieve installation status and progress. The installation status in WAS has been historically captured inside the installation log file. Products and applications which extended the appserver and required its installation status have had to use various means to examine the appserver installation log file. The new API allows you to retrieve the installation status of the appserver in a standard way. See for more information.

Related concepts

Related tasks


Last updated Nov 11, 2010 1:01:09 PM CST