ESBs again

I've posted in the past about what ESBs really are (and why we need them). As evidenced by this entry in InfoQ the discussion seems to be widespread in the industry. I sense that we are entering one of these "grand" debates like SOAP vs. REST. This time it's the question "do we need an ESB or are WS standards enough".

BPEL4People - The Architecture

As I explained in my last post, the new BPEL4People draft standards are intended to integrate people into those business processes that are being controlled by a “requesting application” ( I think it’s pretty safe to assume that in most SOA implementations this would be a process engine running BPEL). The draft spec itself is split into two parts. The first (WS-BPEL Extension for People) explains how BPEL can be extended with specific process constructs to deal with human interactions and lists a number of ways (called constellations) that the management of these tasks can be implemented. From an architectural point of view the most interesting one is when the task infrastructure is decoupled from the process infrastructure and a separate spec (WS-Human Task) has also been released to cover this. I’ve tried to convert this last “constellation” into a more detailed architecture diagram:

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

To do this the task manager needs to access some information regarding the people. The spec assumes a people directory with an interface for queries, but doesn’t actually fix what this looks like.

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.