Sunday, June 18, 2006


Joe McKendrick links to David Chappell's discussion of BPEL as an executable language (or not). I wrote some short thoughts here.

However, the more interesting part of his article is his discussion of BPEL4People. To my shame, I haven't yet read this spec but I have a fair idea what will be in it (for reasons that will soon become clear).

Joe links to an article by Bruce Silver. Bruce doesn't seem to like BPEL4People very much. It seems that he doesn't see a need to make a "human" a first-class activity type in BPEL... believing that it's sufficient to standardise an interface that human task manager services must implement (externally to the process).

At first glance, a wholly external human task management service does, indeed, have many advantages: assigning work to a person is achieved by "invoking a human as a service" and you can swap between automated and human tasks simply by changing where a particular invoke activity points to... why "hard code" the use of a human in the process?

WebSphere Process Server offers this way of working and it works well.

But there's a problem: and the problem is process context. A tenet of SOA is that it doesn't really matter which system implements an interface provided they do implement it and implement it with a quality of service that you find acceptable. Unfortunately, in BPM, you really, really do care who performs a particular step in a process and the entire context of the process is sometimes needed to determine who this right person is.

The only way you can pass enough context to an external human task manager for the most complicated scenarios is by including a lot of human-task-specific stuff in the interface. That means you can't swap human implementations and automated implementations in a seamless fashion and it means that the interface will be rather unpleasant: huge amounts of process context would be flowed across multiple service calls, regardless of whether it was needed.

The solution in WebSphere Process Server (and, I suspect, also in BPEL4People) is to accept that, in many cases, having human tasks expressed directly in BPEL is the superior way to do things (we offer a choice). If a human task really is performed by a human, it's more natural to drop that human task straight onto the BPEL canvas and, because the task is inline, it has access to all the context it could possibly need (i.e. for complex role resolution such as "this task can only be done by the manager of the person who performed task A", etc, etc).

As for Bruce's claim that mandating support for all five cases in the specification is "overly ambitious and unlikely to be adopted beyond IBM and SAP themselves – if even they can achieve it", I'd urge him to take a closer look at WebSphere Process Server. This product is a gem in IBM's software crown that is beginning to get the wider recognition that it deserves. It's quite amusing to see people discussing features of Process Server that are available today as if they're some sort of unachievable nirvana :-)

And, while I'm talking about it, clients are getting results.

It also means I'm so busy that I barely get any time to spend at home but I guess being busy is a good sign...

No comments: