IBM BPM, V8.0.1, All platforms > Administer applications and processes in the runtime environment > Administer service applications and service modules

Versioning in service applications

Service applications support versioning. You can develop and deploy one or more versions of a module and its artifacts into the runtime environment for use by specific clients.

This topic describes how versioning works in a service application deployed directly from IBM Integration Designer. See the related links for information on the versioning of process applications deployed from the repository in Process Center.

What can be versioned?

A module can have a version number, as can the SCA import and export bindings in a module. SCA bindings inherit their version information from the module they are associated with.

At this time, SCA bindings are the only binding type that can be versioned. Versioning is optional for modules. Modules developed and deployed with versions of Integration Designer (previously WebSphere Integration Developer) and WebSphere Enterprise Service Bus before 7.0 do not have versions and continue to function with their current behavior. Refer to the migration topics for more information.

Libraries can also be versioned. Modules that use a library have a dependency on a specific version of that library, and libraries can also have dependencies on specific versions of other libraries.

Considerations for deploying versioned modules

You can deploy a versioned module into the runtime environment and administer it from the SCA modules pages within the WebSphere Application Server administrative console. IBM BPM supports the following versioned deployment scenarios:

• Installing a versioned module to a server or cluster in a cell

• Installing the same version of a module once to each of one or more servers or clusters in a cell

• Installing different versions of a module on the same server or cluster

Deploying a new version of a module does not replace any previous versions of the module. Previous versions of cell-scoped application artifacts are overwritten.

If you want to update an application (for example, to make minor corrections or improvements) without changing the version, that updated application and its artifacts will replace the existing application and artifacts, with the exception of any defined security policies. All security policy artifacts are preserved during an application update.

To preserve versioning information, the installation process automatically changes the module name (by way of the serviceDeploy or createVersionedSCAModule command) to ensure it is unique within the cell. This change is accomplished by adding the version number, a unique cell ID, or both to the original module name.

 moduleName_v versionValue_ uniqueCellID

Considerations for binding versioned modules

After you have deployed multiple versions of a module on a server or multiple instances of a module across clusters, consider how to bind specific versions of modules to clients (which might or might not be versioned).

• Static binding: If you are using static binding, use the existing administrative tools to bind a versioned module to a client. Specify the module version number in the static binding.
• Dynamic binding: To use dynamic binding with versioned modules, use a mediation flow component that contains the module version metadata (versionValue and versionProvider) and service-version-aware routing. If that in order to use service-version-aware routing to dynamically bind versioned modules, all modules must be registered with WebSphere Service Registry and Repository (WSRR).

Administer service applications and service modules

Related information:
Versioning process applications