Versioned modules and libraries
You can create versioned modules and libraries to use on a server at run time.
Versioning is beneficial in a production environment for a number of reasons. You can use versioning to simultaneously deploy multiple versions of an SCA module to the same deployment environment. This is possible because versioning applies to the production environment, not the development and testing environment. You can also use versioning to build a mediation component declaring a version value and matching policy to dynamically route to the determined version during the runtime environment. Set up this mediation process by using the endpoint lookup primitive (which requires WSRR).
Versioning of modules and libraries is optional. You can select versioning based on a scheme provided by IBM, or you can choose to not use versioning at all. The 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. Services and exports inherit their version from the module.
Library scope | Description | Can depend on . . . |
---|---|---|
Module | A copy of this library exists on the server for each module that uses it. | A module-scoped library can depend on all types of libraries. |
Process application or toolkit | The library is shared among all modules in the
scope of the process application or toolkit. This setting takes effect
if deployment is done through the IBM Process
Center.
If deployment occurs outside of the IBM Process
Center,
the library is copied into each module. Note: Libraries created in IBM Integration
Designer version
8 have a sharing level of Process App or Toolkit by
default.
|
A library of this type can depend only on global libraries. |
Global | The library is shared among all modules that are running. | A global library can depend only on other global
libraries. Note: You must configure a WebSphere shared library in
order to deploy the global library.
|