IBM BPM, V8.0.1, All platforms > Get started with IBM BPM > Key concepts > Versioning

Version-aware bindings

Process applications can contain SCA modules that include import and export bindings. When you co-deploy applications, the binding for each version of the application must be unique. Some bindings are automatically updated during deployment to ensure the uniqueness between versions. In other cases, you have to update the binding after deployment to ensure its uniqueness.

A version-aware binding is scoped to a particular version of a process application, which guarantees its uniqueness between process applications. The following sections describe the bindings that are automatically updated to be version-aware as well as any actions you need to take at run time when a binding is not version-aware. For information about things to consider when you create modules, see "Considerations when using bindings".


SCA

The target of an SCA binding is automatically renamed to be version-aware during deployment if the import and export bindings of the module are defined in the same process application scope.

If the bindings are not defined in the same process application scope, an information message is logged. You must modify the import binding after deployment to change the endpoint target address. You can use the administrative console to change the endpoint target address.


Web service (JAX-WS or JAX-RPC)

The endpoint target address of a web service binding is automatically renamed to be version-aware during deployment if all the following conditions are true:

If these conditions are not true, an information message is logged. The action you then take depends on how you are deploying your process application:

For SOAP/ JMS web service binding snapshot co-deployment, the action you take depends on how you are deploying your process application:


HTTP

The endpoint URL address of an HTTP binding is automatically renamed to be version-aware during deployment if all the following conditions are true:

If these conditions are not true, an information message is logged. The action you then take depends on how you are deploying your process application:


JMS and generic JMS

System-generated JMS and generic JMS bindings are automatically version-aware.

For user-defined JMS and generic JMS bindings, no automatic renaming occurs during deployment to enable the bindings to be version-aware. If the binding is user-defined, you must rename the following attributes to be unique between versions of the process application:

Set the matching Send destination if you change the target module endpoint.


MQ/JMS and MQ

No automatic renaming occurs during deployment to enable bindings of type MQ/JMS or MQ to be version-aware.

You must rename the following attributes to be unique between versions of the process application:

Set the matching Send destination if you change the target module endpoint.


EJB

No automatic renaming occurs during deployment to enable bindings of type EJB to be version-aware.

You must rename the JNDI names attribute to be unique between versions of the process application.

If that client applications also need to be updated to use the new JNDI names.


EIS

A resource adapter is automatically renamed to be version-aware during deployment as long as the default resource name ( ModuleNameApp:Adapter Description) was not modified.

If the default resource name was modified, the resource adapter names must be unique between versions of the process application.

If the resource adapter names are not unique, an informational message is logged during deployment to alert you. You can manually rename the resource adapters after deployment using the administrative console.

Versioning


Related concepts:
Considerations when using bindings
Version-aware dynamic invocation


Related tasks:
Administer bindings