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.
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.
Note: At this time, SCA
bindings are the only binding type that can be versioned.
Versioning
is optional for 6.2.x modules. Modules developed and deployed with
WebSphere® Integration Developer and
WebSphere ESB 6.1.x
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.
See the WebSphere Integration Developer Information
Center for details about versioning libraries.
Considerations for deploying versioned modules
You can deploy a versioned module into the 6.2.x run time and administer
it from the SCA Modules pages within the administrative console.
WebSphere ESB 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 (in this case, business rules) 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.
In order to preserve versioning information, the installation process
automatically changes the module name (via 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_vversionValue_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 may or may not
be versioned).
- Static binding: If you are using static binding, simply use the
existing administrative tools to bind a versioned module to a client.
You must 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.
Note 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).