Versioning human tasks

You can create new versions of your human task, so that multiple versions of those same tasks can co-exist in a runtime environment.

Here are some possible examples of when you would create a version of a human task:

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

Put simply, a version is a copy of an existing task that is slightly different from the original. To understand how this differentiation takes place, you must first understand that a version of a human task 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.

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. In other words, it is with different valid-from dates that multiple versions of the same task are distinguished. In practice, the runtime engine could use a new version of a task that is set to become valid today, even if an older version of that task was still being used.

Invoking a human task

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

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

In other words, if the caller instantiates a task using early binding, a specific version of the task is used to create that instance, and if they use late binding, the currently valid version of the human task 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:
  • 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. Although this example is not specific to human tasks, it can still help you to become more familiar with the concept of versioning.
Note: You will need a connection to the internet for these links to work.

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