Another bop at BPEL; What's BPEL4People?

Is Business Process Execution Language executable? Is it a language? David Chappell doesn't like BPEL, and he makes his disdain for Business Process Execution Language known in a new post at his site. "I'm not convinced that BPEL has much of a future as an executable language," says the well-known Web services author and consultant.

That's because many people who "think of BPEL as a programming language," Chappell says. "But unlike Java and every other mainstream programming language, BPEL is defined using XML.  ...masses of developers are never going to work directly in a complex XML-based language."

Instead, Chappell, advises, think of BPEL as 'bytecode'; a language designed to run within a framework, just as Java runs within JVM/Java EE. "As an executable language, BPEL's primary goal is to provide a portable description of logic. Isn't this exactly what Java bytecode strives to do? ...both are tool-generated languages (bytecode by a Java compiler, BPEL by some graphical process design tool) and both can potentially foster portability."

Chappell notes there is an emerging standard that may overshadow BPEL, called Business Process Management Modeling Notation (BPMN). Expect to hear lots more about BPMN, which was first formulated in 2004. by the Object Management Group  "Just as lots of people know Java, lots of people may one day know BPMN. And just as almost nobody except tool vendors works directly in or even thinks much about Java bytecode, the day may come when almost nobody except tool vendors works directly in or thinks much about BPEL."

Another criticism of BPEL is that the spec leaves human interactions -- the things that can really make or break business processes -- out of the equation. A couple of months back in WebServices.Org, I wrote about a proposal being floated called 'BPEL4People' (yes, it rhymes).

IBM and SAP are behind BPEL4People, intended to be an extension "layered on top of BPEL," intended to cover a "broad range of scenarios that involves people within business processes." (White paper available here .) As BPEL4People proponents explain it, getting a process "unstuck" within BPEL would "require undoing parts of the business process. But if the business process has already run for multiple days, invoking partner operations, collecting results, and so on, compensation may not be desirable, since this wastes resources and efforts already spent." Thus an administrator will have to manually intervene to take the corrective action to get the process moving again. BPEL, they say, needs to incorporate a "special kind of implementation of an activity - a communication step which may be called 'people activity.'"

Some critics, such as Bruce Silver, however, say BPEL4People may be just a little too much, and ironically, the current version of BPEL handles people interactions fairly well, thank you.

As I observed in my earlier post on BPEL4People, we are only in the early stages of automating business process management, and few enterprises have begun linking business processes to SOA. Processes get touched by humans many times, and sometimes are required to be by law or regulation. BPEL promises to speed up much of our workflows, but the points requiring human interaction may negate efficiency and speed gains. The question is whether BPEL, BPEL4People, or other approaches can compensate for the continuing need for human intrevention..