During replication, a single Integration Server sends (publishes) a specified package to one or more recipient servers. The server on which the package originates is referred to as the publisher, and the recipients are referred to as subscribers.

Subscribing servers receive the package in their inbound directory ( Integration Server_directory \instances\instance_name\replicate\inbound). To activate the new package, an administrator on the subscribing server must install the package after it arrives. (This procedure is explained in About Installing Packages Published by Another Server.)

Either a publisher or a subscriber can request a subscription. A publisher can send (push) the package and the subscriber can request (pull) the package.

Before you send a package to another server, you must create a release. When you create a release, the server creates a distribution file that contains the package and information about the package, and makes the package available to subscribers.

You can have multiple releases for a given package. For example, you might have separate releases for versions 1.0, 1.1, and 1.2 of a given package. Or, you might use different releases to separate packages for different audiences. Each release must have a unique name.

A release can contain the complete package (a full release) or just patches to the package (a patch release). Typically you will publish a full release when you have made major changes to the package and use patches just to correct problems with a package.

With a full release, the new package entirely replaces the old package on the subscriber's server. With a patch release, the files in the patch release replace the versions of those files in the target package; all other files in the target package remain intact.

In addition to specifying a full or patch release, you can select all files to go in the release or just some.

The following diagram illustrates how a patch release replaces files:

The following diagram illustrates the results if you selected a single service for replication and specified a full release instead.

Most often you will select all files and specify a full release, or select some files and specify a patch release. There might be times however when you want to select just some files and specify a full release. For example, there might be files in a package, such as internal documentation files, that a developer does not want released to others. Selecting all files except the extraneous ones and specifying a full release results in a package that contains just the desired files.

There might be other times when you want to replace some files, leave others intact, and delete others. To achieve this greater level of control, you can perform a patch release and specify files to copy and files to delete. Files that you do not specify for copying or deletion remain intact. In the following example, we want to leave Service A intact, replace Service B, and delete Service C from the target package.

The following shows what you must specify on the Specify Files for the Release page to accomplish this task:

The Integration Server keeps track of package versions, Integration Server versions, and JVM versions so that during package installation the subscribing server can make sure the package being installed is compatible with the subscribing server's environment. The type of version checking performed depends on whether the release is a full or patch release.