"What's the right way to include human tasks in a BPEL process, and why?"

Bruce Silver points to my qualified defence of BPEL4People and asks what the best way to include human tasks in a BPEL process is.

I'm not going to attempt a full answer, and I'm not even going to refer to BPEL4People. Rather, I'm just going to make an argument for why human task support inside a process is useful and why human task support outside a process is useful.

Human tasks outside a process

The idea of being able to "invoke a human as a service" is such a good idea that the process people shouldn't be allowed to keep it for themselves. I can think of hundreds of applications where being able to put a piece of work on someone's worklist - and know when they've done it - would be brilliant. Imagine a banking application that allowed you to leave a message for your bank manager, know when they've read it and which allows them to give their answer directly.

An external human task manager lets you do this and it's really, really useful. WebSphere Process Server has one of these things and it works really well. Once you have it, you keep on thinking of new uses for it.

The obvious next thought, however, is to think that we've succeeded in some unstated goal of abstracting humans into (expensive) web services.

The problem is that, as great as an external task manager component is, a human is not a machine and there are aspects of human behaviour that are qualitatively different. That is: there are behaviours that one would like to model that are not best expressed through a simple (e.g. WSDL) interface.

These behaviours become particularly apparent when developing a solution that automates part of a business process

Human tasks inside a process

BPEL is the industry's current attempt to define an executable language for describing a business process. I think that's a little ambitious - although I do think it is more than just a web services scripting language.

In BPEL, we are encouraged to think about the concept of an "invoke". This is an entity in BPEL that says; "At this point, we need to invoke some functionality that exists elsewhere. Here is the input data and this is where we should store the data that comes back". At execution, the BPEL engine turns this into a web services call (most usually, at least).

This model can be thought of as the archetypal command-and-control approach. "Do this!". "Now do that!". "Did it work? Good! Now do this!"

Many processes are like this and many applications can be built on this model. In such cases, "invoking" a human in this manner is reasonable.

However, many other classes of process can be thought of in terms of a flow. Somebody does something, then a bit of automation happens, then somebody else does something. Such processes are often typified by a collective knowledge of what needs to happen next. People just seem to "know" when they are required.

When trying to model such processes, it is far more productive to model the human interactions inline. The interplay of the various people in the process is intrinsic to the process. "Swapping out" a human for a machine (as could be done in the "invoke" case) just doesn't make sense. Instead, it is useful to be able to say things like: "This step is done by a human. It can't be the one who did the previous step but it must be a manager. If they haven't done it within a day, escalate it to their boss".

Sure... this could be configured external to the process in the external human task manager but the enforced separation seems unnatural to me in such a case.

Conclusion

My claim, therefore, is that we need support for human tasks both inside a process and outside a process. It may well be that BPEL4People is over-complicated (I'm not qualified to say) but I do suspect that it will prove to be on the right lines.