Versioning state machines

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

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

To create a version of a business state machine, it is important that you plan ahead. Specifically, you will need to consider how the client interacts with the state machine, and how the state machine 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 state machine versions

Put simply, a version is a copy of an existing state machine that is slightly different from the original. To understand how this differentiation takes place, you must first understand that a version of a business state machine is identified by the following properties:
  1. same component name
  2. same target namespace
  3. different valid-from date
In addition, it is important to note that
  • interface specifications of different versions need to remain the same
  • correlation sets specifications of different 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 state machine are distinguished. In practice, the runtime engine could use a new version of a state machine that is set to become valid today, even if an older version of that state machine was still being used.

Invoking a business state machine

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

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

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

Clients that want to use early binding can do it in one of the following ways:
  • Using SCA wiring
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 state machine.

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 these links to work.

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