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.
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.
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.
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.
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