How does this all go together? Let’s start off at the simpler end. The basic assumption is that people provide services by acting on tasks which have been assigned to them. To see and handle the tasks which have been assigned to them is done using a task client. This is not specified by the specification, but it is a relatively safe bet that will take the form of a user interface with some kind of task list which the user can interact with (for instance, in a SAP environment this could be a universal work list). The user interface interacts with a task management component which stores the tasks assigned to the users. Again, it’s pretty likely that the task manager will be a central component that can hold the tasks for a number of users each of who has their own user interface. The spec defines the services which the task manager component exposes to a user interface. I’ve grouped them into three categories:
- Life Cycle, i.e. claiming a task (i.e. saying you’ll do it), starting, suspending and stopping tasks etc.
- Query, i.e. finding tasks based on certain criteria. The most important one here is getMyTasks.
- Administration services such as explicitly nominating someone to a task
So how do the tasks get into the task manager? Conceptually this is very simple. The task manager exposes a service for the business function (or functions) which need to be performed by a human. The service can then be called from another application or a process engine. Once the service has been invoked, the task manager creates a task which, as far the users are concerned, appears in a task list and can be dealt with over the task client. The user can then decide to act on the task until it’s completed. I’ve sketched a simplified scenario (using as an example a credit approval service) in a UML sequence diagram:
I must admit, I find the interface between the requesting application (the process engine in our scenario) and the task manager rather specific to the business logic required. The task manager has to expose specific services such as ApproveCredit rather than use a more general approach with services such as TaskCreate. This implies that any service developer will have to use an API which is specific (i.e. proprietary) to the task management component being used.
The above only sketches some of the main features found in the draft specification. Other features (such as notifications and placing service calls in a context) I haven’t included. The spec also defines in detail the messages between the main components. I look forward to more articles detailing what the specs actually mean for architects.