Versioning processes

You can create new versions of your business process, so that multiple versions of those same processes can co-exist in a runtime environment.

Here are some possible examples of when you would create a version of a business process:

To create a version of a business process, it is important that you plan ahead. Specifically, you will need to consider how the client interacts with the process, and how the process itself is set up. To allow for seamless introduction of new versions, it is a good idea to anticipate the need ahead of time, and set things up in the manner described in the associated topics.

Differentiating process versions

Put simply, a version is a copy of an existing process that is slightly different from the original. To understand how this differentiation takes place, you must first understand that a version of a business process is identified by the following properties:
  1. same process component name
  2. same target namespace
  3. different valid-from date
In addition, it is important to note that
  • interface specifications of different process versions need to remain the same
  • correlation sets specifications of different process versions need be the same

Of critical importance, the two versions must have the same name and namespace, but have different valid-from dates. In addition, where applicable, they must also have the same interface, and correlation set specifications. In other words, it is with different valid-from dates that multiple versions of the same business process are distinguished. In practice, at runtime the process engine could use a new version of a process that is set to become valid today, even if an older version of that process was still being used.

Invoking a business process

When a client invokes a process, that client can be configured either to choose a specific version each time, or to pick up the currently valid version of the process. This is the basic concept behind early binding and late binding.

With early binding, a client is hard-wired to a process in such a way as to force a continued relationship between the two of them, even if another version of the process becomes available. In contrast, with late-binding the relationship between the client and the process is dynamic in that it is resolved in the runtime environment.

In other words, if the caller instantiates a process using early binding, a specific version of the process is used to create that instance, and if they use late binding, the currently valid version of the business process is used.

Clients that want to use early binding can do it in one of the following ways:
  • Using SCA wiring
  • Using the Business Process Choreographer APIs (generic EJB API or generic Web Services API)
Clients that want to use late binding can do it in one of the following ways:
  • Through the partner link extension in cases where a process that is acting as a client calls another business process.
  • Using the Business Process Choreographer APIs (generic EJB API or generic Web Services API)

For more information

See the whitepaper on developerWorks called Versioning and dynamicity with WebSphere Process Server and the podcast called WebSphere Technical Podcast series: SOA programming model, Part 5: Managing change in Web services components and applications

Example

To see an example of a versioned process that you can build and run yourself, go to http://publib.boulder.ibm.com/bpcsamp/index.html, and click Process modeling techinques > Versioning.
Note: You will need a connection to the internet for this link to work.

Feedback
(C) Copyright IBM Corporation 2005, 2006. All Rights Reserved.