Critical. Authoritative. Strategic.


CBR is proudly produced & published
by Technews
Issue Date: June 2007

BPEL4People announcement divides SOA, BPM communities

June 2007
Tony Baer

Earlier this week, a group of 'usual suspects' including IBM, SAP, Oracle, BEA and Adobe (plus Active Endpoints) formally announced that they would submit a proposed extension of BPEL to cover human workflow to Oasis later this year.

But, while most of these players have their own BPM tools, conspicuously missing from the sponsoring group were any of the BPM pure play vendors. The big question is whether the new proposal will do anything more than paper over differences that have emerged between the SOA and BPM camps.
To recap, the group proposed two specifications. The first, called BPEL4People, would extend the BPEL process orchestration spec to add a placeholder for manual steps. The other, called WS-HumanTask, would actually specify the steps that people actually perform.
"Our initial objective was to fix an obvious shortcoming in BPEL," explained Ed Cobb, BEA vice president for standards, who added that when it came to developing ways to specify the actual activities, the group realised that it made sense to keep execution options open. "We looked at how that [human tasks] could fit into the rest of the world, and saw that other process engines besides BPEL could use that."
Nonetheless, reception among BPM pure plays was rather underwhelming.
"Critical constructs in workflow and how to deal with organisational hierarchies are left out of the spec and left to the discretion of the implementer," said Rob Risany, vice president of product management for Savvion. For instance, the 'four eyes' principal of workflow, which equates to separation of duties in regulatory regimes like Sarbanes-Oxley, are absent from BPEL.
"BPEL does not understand process," added Phil Gilbert, CTO with Lombardi Software, who equated it with the type of language that only programmers, not business analysts could understand.
Admittedly, the new spec separates out tasks from orchestration with the WS-HumanTask proposal. According to Jon Pyke, director of the Workflow Management Coalition (WfMC), while separating it out from the core BPEL spec is helpful, it still introduces a new kind of code that is incompatible with the terminology and conventions that business analysts currently use.
The root of the schism is that BPEL, like other web service standards, is built on XML and constructs like XML Schema to describe what a service is, its behavior, and other relevant parameters such as security requirements, versioning, and trust or entitlements.
Although XML is technically human readable, it is structured like the code that developers understand. By contrast, business processes are modelled and often represented graphically in a way that business analysts understand.
Compounding matters is the nature of BPEL, which is essentially a series of verbs that instruct different services how to interact in a form of dynamic chain reaction. In other words, BPEL is the type of execution language to which programmers are accustomed.
By nature, it does not account for the subtleties in a process, and does not easily relate to concepts like 'swim lanes' that depict parallel activities in process workflows.
At this point, the BPM pure plays appear to be holding their ground, as they never cared for the original BPEL spec, and obviously, have little more respect for the human workflow extensions. Savvion's Risany claims that BPEL4People and WS-HumanTask's highly structured workflows are far too rigid. "This is where the workflow world was 5-7 years ago. In the modern world, people are starting to rely more on run time processes such as ad hoc collaboration."
So the bottom line for now is continued stalemate.
The BPM players are continuing to regard process orchestration as something that is accomplished at the Java or .NET programming code level, where they claim, the languages and tooling are better suited for handling the subtleties of complex processes. They regard SOA as a way to expose and integrate the outcome of business processes.
Speaking for BEA, both Cobb and his colleague, CTO Rob Levy, stated that at this point BPEL remains a checklist item for their clients.
But both admitted that the jury is still out as to what will become the primary orchestration vehicle for business processes, and especially, the manual workflow assets. "I am on the fence," Levy admitted to us.
Our view
When it comes to exposing human workflows, business processes, or whatever you want to call them, one size will not fit all.
Business analysts and software developers speak different languages.
They always have and they always will. Business analysts claim that developers, and the traditional tools that execute business processes, do not grasp the subtleties of complex business processes, not to mention the dynamic collaborations that are expected in today's business environment. Software development folks on the other hand assert that business analysts know little about matters like scalability and availability. Both are right.
But in all likelihood, the 80/20 rule will drive the way that processes, workflows, or steps are executed. While prospects for BPEL4People are uncertain, WS-HumanTask is another story altogether.
The creators of BPEL wisely guessed that there are many ways that a human step or workflow could be exposed, and by making it a separate specifications, they have opened up the possibility of a standard mechanism for re-using commodity human tasks among multiple applications.
Admittedly, given the fact that WS-HumanTask does not have the richness to represent the complexities of long-lived business processes, it is not going to all of a sudden become the modern workflow execution language. But it could become shorthand for the rudimentary 20% of tasks that comprise 80% of the workflows by volume.
At the other end of the scale, BPM vendors are looking to new execution models that could blow past the bottlenecks of having to interpret process models and convert them to code. In other words, it could enable process analysts reduce, but not eliminate reliance on developers to execute the business process models that they have designed.
The idea is to make models executable. As we reported recently, E2E, a player outside the BPM space, is working on making UML models executable by adding some byte code. It bypasses the step of having to convert UML to code.
In the BPM space, others are likely to follow. Lombardi is working on making BPMN (business process modelling language, which like OMG is managed by OMG) executable. And BEA's Cobb mentions BPEL J, which gives BPEL an assist with Java.
Of course, given the deep cultural divides between business analysts and developers, common methods or technology approaches alone may not bridge the gaps.
Source: Computergram

Others who read this also read these articles

Search Site

Search Directory

  • Search for:


Previous Issues