Blog Posts Case Management Process Management Process Modeling

Still think you need BPEL?

Blog: Collaborative Planning & Social Business

Fourteen years ago, IBM and Microsoft announced plans to introduce a new language called Business Process Execution Langauge (BPEL) to much fanfare and controversy. This post takes a retrospective look at BPEL, how things have progressed, and ponders the point of it all.

Origins

In 2002, BPM was a new term, and Web Services was a new concept. The term BPM meant a lot of different things in that day, just as it still does today, but of the seven different kinds of BPM, the one that is relevant in this context is Process Driven Server Integration (PDSI). Nobody actually many real web services at that time, but it was clear that unifying such services with a standard protocol passing XML back and forth was a path to the future. Having a way to integrate those web services was needed. Both Microsoft and IBM had offerings in the integration space (BizTalk and FlowMark respectively). Instead of battling against each other, they decided to join forces, and propose a open standard language for such integration processes.

In April 2003 A proposal was made to OASIS to form a working to define a language called BPEL4WS (BPEL for Web Services). I attended the inaugural meeting for that group with about 40 other high tech professionals. It was a rather noisy meeting with people jockeying for position to control what was perceived to be the new lingua franca for business processes. The conference calls were crazy, and we must credit the leaders with a lot of patience to stick with it and work though all the details. The name was changed to WS-BPEL, and after a couple of years a spec was openly published as promised.

Hype

BPEL was originally proposed as an interchange format. That is, one should be able to take a process defined in one product, and move it to another product, and still be executable. It was to be the universal language for Process Driven Server Integration.

Both Microsoft and IBM were on board, as well as whole host of wannabes. A group called the Business Process Management Initiative dumped their similar programming language called BPML in favor of BPEL as a clear case of “it you can’t beat ’em you can join ’em.”

It was designed from the beginning to be a “Turing-Complete Programming Language” which is a great goal for a programming language, but what does that have to do with business? The problem with the hype is that it confused the subject of “server integration” with human business processes. While management was concerned with how to make their businesses run better, they were being sold a programming language for server integration.

The hype exists after the spec was announced, but before it was finally published. This happens with most proposed specs: claim that the proposal can do everything are hard to refute until finally the spec is published. Only then can claims be accurately refuted. For more than 4 years BPEL existed in this intermediate state where inflated expectations could thrive.

Who Needs It?

At the time, I could not see any need for a new programming language. Analysts at Gartner and Forrester were strongly recommending companies go with products that included BPEL. I confronted them, asking “Why is this programming language important?” And the candid answer was “We don’t know, we just know that a lot of major players are backing it, and that means it is going to be a winner.” It was a case of widespread delusion.

My position at the time was clear: as a programming language it is fine, but it has nothing to do with business processes. It was Derek Miers who introduced me to the phrase “BPEL does not have any B in it.” The language had a concept of a “participant”, but a participant was defined to be a web service, something with a WSDL interface.

In 2007 I wrote a article called “BPEL: Who Needs It Anyway?” and it is still one of the most accessed articles on BPM.COM. In that article I point out that translating a BPMN diagram into BPEL presents a limitation on the kinds of diagrams that can be executed. I point out that directly interpreting the BPMN diagram, something that has become more popular in the meantime, does not have this limitation.

If what we need is a language for PDSI, then why not use Java or C#? Both of those languages have proven portability, as well as millions of supporters. When I asked those working on BPEL why they don’t just make an extension to an existing language, the response was the incredible: “We need a language based on XML.” Like you need a hole in the head.

Attempted Rescue

The process wonks knew that BPEL was inappropriate for human processes, but still wanting to join the party, there was a proposal for the cleverly named “BPEL 4 People” together with “WS-HumanTask.” This is the idea that since people are not web services, and since BPEL can only interact with web services, we can define a standardized web service that represents a real person, and push tasks to it. It is not a bad idea, and it incorporates some of the task delegation ideas from WF-XML, it fails to meet the need of a real human process system because it assumes that people are passive receptors of business tasks.

When a task is sent to a web service for handling, there is no way to “change your mind” and reallocate that to someone else. BPEL, which is a programming language for PDSI, unsurprisingly does not include the idea of “changing your mind” about whom to send the task to. Generally, when programming servers, a task sent to a server is completed, period. There is no need to send “reminders” to a server. There are many aspects of a human process which are simply not, and never should be, a part of BPEL. Patching it up with representing people as standardized web services does not address the fundamental problem that people do not at any level interact in the same way that servers do.

Decline of BPEL

Over time the BPM community has learned this lesson. The first version of BPMN specification made the explicit assumption that you would want to translate to BPEL. The latest version of BPMN throws that idea out completely, and proposes a new serialization format instead of BPEL.

Microsoft pulled away from it as well as a core part of their engine. First proposing that BPEL would be an interchange format that they would translate to their internal format. Oracle acquired Collaxa an excellent implementation of BPEL, and they even produced extensions of BPEL that allowed for round trip processing of BPMN diagrams using BPEL as the file format. But Oracle now appear to be pulling away from the BPEL approach in favor of a higher-level direct interpretation of a BPMN-like diagram.

Later it became doubtful that processes expressed in BPEL are interchangeable at any level. Of course, a simple process that sticks to the spec and only calls web services will work everywhere, but it seems that to accomplish something useful every vendor adds extensions — calls to server specific capabilities. Those extensions are valid, and useful, but they limit the ability to exchange processes between vendors.

Where Do We Go From Here?

To be clear, BPEL did not fail as a server programming language. A engine that is internally based on BPEL for Process Driven Server Integration, should be able to continue to do that task well. To the credit of those who designed it for this purpose, they did an exemplary job. As far as I know, BPEL engines run very reliably.

BPEL only failed as

a universal representation of a process for the exchange between engines.
as a representation of a business process that people are involved in.

BPMN is more commonly used as a representation of people oriented processes for direct interpretation. Yet portability of BPMN diagrams is still sketchy — and this has nothing to do with the serialization format, it has to do with the semantics being designed by a committee. But that is a whole other discussion.

The business process holy grail still eludes the industry as we discover that organizations consist of interactions patters that are much more complex than we previously realized. No simple solution will ever be found for this inherently complex problem, but the search for some means to keep it under control goes on. What I hope we learned from this is to be cautious about overblown claims based on simplified assumptions, and to take as more studied and careful approach to standard in the future.

References

BPEL: Who Needs It Anyway? – Keith Swenson, 2007, shows how directly executing the BPNM diagram is better than translating to BPEL.
Why BPEL is not the holy grail for BPM – Pierre Vigneras, Oct 21, 2008, limitation on BPEL executability
WYDIWYE: The Answer to BPEL Transform Problems – Keith Swenson, April 3, 2008, a call for executing the diagram directly, instead of transforming to BPEL
Business Process Modeling Notation (BPMN) Information – OMG FAQ
OASIS, The BPEL Specification (pdf) – OASIS FAQ, 2007
Business Process Execution Language for Web Services version 1.1 – IBM summary page on BPEL
Translating Workflow Nets to BPEL (pdf) – Wil M.P. van der Aalst and Kristian Bisgaard Lassen
The BPMN-XPDL-BPEL value chain – Keith Swenson, May 26, 2006, explains how XPDL and BPEL are for different uses. One of my most popular blog posts of all time.
Life After BPEL (pdf) – van der Aalst, Dumas, ter Hofstede, Russell, Verbeek, Wohed, 2005, discusses the usefulness of BPEL without the vendor hype.
The Case Against BPEL: Why the Language is Less Important Than You Think – David Chappel, October 2005
The Real Issues with XPDL, BPEL, and BPMN – Bruce Sterling, March 21, 2007
The Diagram IS the Meaning – Keith Swenson, March 2007
Reframing the BPMN vs BPEL Debate – Bruce Silver, Feb 2, 2009,
BPM is not Software Engineering – Keith Swenson, November 25, 2008