**Editor's note: Here, see Tony
Baer and Keith
Harrison-Broninski's commentaries on the same announcement.**
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 overriding approach
has missed the point by introducing a new kind of node for incorporating people,
instead 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. So in addition to the issues of incompatibility
presented by BPEL4People, it still does not offer a richness of languaged need
to respresent the complexities of how people interact with one another or how
processes really 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
worklow 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 it is simply a nervous reaction from those how see
the standard as a competitor to the BPEL religion. The positioning of XPDL and,
indeed, BPEL was made very clear in a recent paper entitled XPDL, the Silent Workhorse of BPM.
1
Solution Center Resources
Print this article
Email this article
Talk Back!
Write to Editor
