| |
People, who needs BPEL?
The recent submission of BPEL4People is a good step in the right direction to bring SOA-type requirements to the carbon side of the business process conundrum. But, and it’s a big but, the BPEL4People extensions to BPEL cannot and does not change the basic block structured design of the underlying language.
The proposed BPEL4People and associated WS-HumanTask specifications introduces the ability to delegate ownership of a task by named user. Yet it's overriding approach has missed the point by introducing a new kind of node for incorporating people, instead of extending current activities to have the capabilities of human activities. This renders it incompatible with other systems supporting people today.
The most worrying aspect for me, however, is that the intended people support changes simply do not go far enough. The BPEL4People extensions still do not offer the richness of language needed to represent the complexities of how people interact with one another or how processes actually work in real life. For example, there is no concept of process versioning nor process migration. These capabilities are critical in a human system because processes can take so long that laws, customs, or competition can change between the time a process starts and ends.
Process experts such as Wil Van der Aalst (noted for his pioneering work with workflow patterns) have shown that some process diagrams can be drawn in BPMN, but still cannot be implemented using a block structured language, such as BPEL. These types of processes are considered by programmers to be "invalid" but in fact they represent the way that people work. It all depends upon whether you want a faithful reflection of the way that people really work, or whether you want to constrain them to the design dictated by a programming language designed for transfer of data.
We can take this lack of understanding a stage further. Take XPDL for instance. According to Tony Baer’s recent blog, the “WS-Folks” suggestion that XPDL is not service-oriented and is in some way “old-fashioned.” This attitude is nothing to do with XPDL itself, but rather is a nervous reaction from those how see the standard as a competitor to the BPEL religion. This is an unfortunate misunderstanding, as the two are both complimentary and orthogonal. They are not competitive, nor is one a substitute for the other. The positioning of XPDL and, indeed, BPEL was made very clear in a paper entitled XPDL, The Silent Workhorse.
XPDL’s primary goal is the storage and exchange of process diagrams, or specifically to allow one tool to model a process diagram, and another to read the diagram and edit, another to "run" the process model on an XPDL-compliant BPM engine, and so on. The XPDL file can provide this design interchange because it offers a one-for-one representation of the original BPMN process diagram. It can be written and re-read to recover the original diagram.
In contrast, mapping BPMN-to-BPEL is a non-trivial exercise, and it is limited to a one-way trip. In other words, with the right tools you can use a BPMN diagram to produce BPEL, but it is difficult or impossible to reproduce the original BPMN diagram from the BPEL code. This is not surprising, however, since BPEL was not designed for process design interchange. It is a block-structured, web services orchestration language.
BPEL4People is indeed a step in the right direction, despite both legitimate and exaggerated criticism. It does help to spotlight that the most critical, and often most challenging aspect of business process management is the human element. And perhaps its greatest contribution to date is that it has certainly proved wrong the folks who said there couldn't be a more misunderstood name than "WS-BPEL."
|
|
