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. Continue reading
The WfMC and many other who help have been trying to highlight the positive examples of both BPM and ACM by collecting use cases, judging the best, and publishing in compendia. It was Socrates who said there is value in a focus on the negative: he would rather be refuted than to refute another because being rid oneself of evil of harboring false beliefs is better than ridding it in another. Continue reading
Bruce Silver’s latest post “Reframing the BPMN vs BPEL Debate” calls to question whether it is worth continued discussion of the definition of BPM. Like most of Bruce’s posts, it is insightful and well worth reading. This is in response to a post by Boris Lublinsky on “BPEL: Who Needs It Anyway?”
I am a little surprised by Bruce’s response, Continue reading
Finally a well considered and detailed article on the limitations of the approach to BPEL.
There are a few vendors who promote BPEL as as the one-and-only-true-way to support BPM. In fact, it is good for some things, but fairly bad at a large number of other things. It is my experience that BPEL is promoted primarily by vendors who specialize in products we might rightly call “Enterprise Application Integration” (EAI). These companies have recently taking to calling their products “Business Process Management”. Potential users should be asking the question “Is BPEL appropriate for what I want to do.” Continue reading
I just want to highlight an excellent post by William Vambenepe on the subject of BPMN to BPEL: going to battle with one hand tied? He does a very simple experiment: draw a meaningful diagram in BPMN, in this case a fairly simple one involving an Inclusive-OR branch, and then attempt to convert this to BPEL. He does this conversion and presents the results is quite obviously a diagram that fails in fact to capture the exact meaning. He says he has no solution to this problem. Continue reading
The BPMN specification includes a sample process to use as an example of how you would use BPMN to draw the process and how it would then be converted to BPEL. Bruce Silver has suggested that this be used as an example process to test interoperability between different process diagramming tools. One point in favor of this is that it is fairly well fleshed out and documented. Also, it is a real process that would be reasonable to use in real life.
As I set out to implement this process, it struck me how dramatically different the process would be drawn if you had an implementation engine that supported human activities directly. Continue reading
Bruce Silver put together a summary of The Real Issues with XPDL, BPEL, and BPMN where he explained better than I could that the aspect of portability that is more valuable depends on what you’re trying to do. He correctly points out that “XPDL captures the diagram, while BPEL captures the process semantics.”
Bruce brings BPMN into the discussion as potentially the standard that is possibly the most important. There have been a number of discussions recently of the relation of these three standards, Continue reading
I ran a “Round Table” at the BPM ThinkTank on the subject of BPMN and XPDL. There always is the question: “Why not use BPEL?” Then I explain how XPDL holds the graphical layout, the X & Y coordinates, the size the nodes, the paths of the lines. BPEL has not support for the graphical layout.
“But you don’t need to save the graphical layout!” Continue reading
I got the chance to participate on a panel session at the BPM Think Tank in Arlington VA on May 24 2006 on the subject of BPM Standards. Richard Mark Soley was on one end representing OMG and the BPMN standard. John Evdemon from Microsoft was on the other end representing BPEL for which he is the TC Co-Chairman. I was between them representing XPDL from WfMC. The order was random (although Richard suggested we were ordered by height) but as it turns out this is a natural order of progression for use of these standards. Sandy Kemsley described this as the “BPMN-XPDL-BPEL value chain” in her post about that panel session. (Thanks Sandy for the term!)
Many people today automatically assume that BPEL and XPDL are direct competitors. This is not at all true. BPEL and XPDL are entirely different things for entirely different purposes. I will repeat that statement a few times here to emphasis it. But first, and quick summary of how they are different.
BPEL is an “execution language”. It is a programming language that has variables and operations. The operations can send and receive SOAP messages, and there is strong support for XML and XML transformation. It has constructs that make it easy to call multiple web services at the same time, and synchronize the results. It does not have any concepts to support the graphics of the diagram; activities do not have a position and size, and there is no representation at all of an “arrow”.
XPDL is a process design format. It is a file format that represents the “drawing” of the process definition. It has X & Y coordinates and node size. It has a concept of lines, and points along the line that give it a particular path. The nodes and lines have attributes which can specify executable information such as roles, activity descriptions, timers, web service calls, etc. XPDL 2.0 contains extensions in order to be able to represent all aspects of BPMN (BP Modeling Notation). The goal is to be able to save and exchange the process diagram.
The goal of BPEL is to provide a definition of web service orchestration, the underlying sequence of interactions, the flow of data from point to point. Ultimately BPEL is all about bits and bytes being moved from place to place and manipulated. It does not however attempt to represent the drawing that you used specify the orchestration.
The goal of XPDL is to store and exchange the process diagram. It allows one process design tool to write out the diagram, and another to read the diagram, and for the picture that you see to be as similar as possible. It does not, however, guarantee the precise execution semantics. As you see, BPEL and XPDL are entirely different things for entirely different purposes.
The different usage is best represented the diagram below. At the top are various design level tools. At the bottom are execution environments. XPDL can be used to carry the design from design tool to design tool. BPEL, XPDL, or other formats might be used be used to communicate the executable process to the engine. Generally, a vendor specific design tool is necessary to translate the design into an engine specific format. Generally, it is not possible to take executable code from one vendor’s design tool, and execute it in another vendor’s engine. Even with BPEL, which many believe was for this purpose, does not at this time allow different engines to run identical copies of BPEL code.
The XPDL file can provide this design interchange because it offers one for one representation of the original BPMN process diagram; it can be written, and re-read to recover the original diagram. BPEL, on the other hand is a non trivial mapping which is widely recognized as being one directional: you can take a BPMN diagram and produce BPEL, but it is difficult or impossible to recover the original BPMN diagram from the BPEL. This is not surprising since it was not designed for process design interchange.
Process interchange is ver important to customers who are investing a tremendous value in their process diagrams, and do not want to locked into a single vendor. (The vendors may desire this lock in, but never forget that the customers are paying the bill and have a choice.)
The importance of process design interchange will increase as the market matures. Currently, without design exchange, a single vendor must supply all of the tools that an organization might use. As the market matures, we can expect to find specialized tools that provide one function better than the vendor providing the engine. Or there will be people who are trained on a special tool and don’t want to lose that skill to pick up a new vendor version. The result is that we see a complete ecosystem of specialized tool that all work at the design level. This might be depected as below:
You might ask, if BPEL does not manage to communicate the execution representation to various engines with complete fidelity, why then would we expect XPDL to exchange the process diagram with complete fidelity? The answer is simply that is does not need to. One design tool does not understand the output from another tool completely, but every design tool will understand the most important parts (the form and shape of the diagram) as well as many standard BPM attributes. Because the model is communicated from design tool to design tool, if the transfer is not perfect, you have a chance in the receiving tool to fix it up. Not perfect, but both useful and pragmatic.
Not every tool needs to understand the complete diagram. A simulation tool for instance will use the standard parts of the diagram, but probably ignore things like the attributes that define web service calls, since simulation does not need to know this.
One of the most important aspects of XPDL is the extensibility mechanism. Each tool has specialized requirements on the diagram, it can represent these using extended attributes. Other tools will not understand these extensions, but they will carry the extensions along. Thus a tool specialized to clean up the layout, might manipulate the graphical aspects of the model, and return a cleaned up model including all the extensions back to the original source without losing any information. Enhydra JaWE for instance is an open source XPDL editing tool has been publicly demonstrated to read an XPDL file from Fujitsu’s Interstage BPM, edit, and return without loss of vendor specific extensions. JaWE even allows you to view and modify the extended attribute values.
Some execution engines take XPDL directly. Fujitsu’s Interstage BPM does because it is workflow style BPM and it is important for human activities to retain their identity even while executing, so that run time modification and process migration can be readily supported. That is the choice that a particular engine makes. Some of the more EAI-style engines may use BPEL, but even in that case the portability is not proving viable, and some engines are going straight to the underlying technology such as Java, C#, Ruby, etc.
These are the differences in the roles of these three important standards. Our sitting order on the panel was appropriate and fitting because users will usually start by drawing a BPMN diagram, saving the partial diagrams as XPDL during development, and ultimately translating to BPEL for transmission to an EAI style BPM engine. These are three very different and very compatible roles. But remember this: BPEL and XPDL are entirely different things for entirely different purposes.
A study of the usefulness of the BPEL language, and not just regurgitating the marketing hype from vendors. The paper “ Life After BPEL?” by W.M.P. van der Aalst et. al. is a refreshing view of the good and the bad or missing part of BPEL.
I found another one from David Chappell who points out that BPEL is less important than you think. Gotta agree with that.
Thinking Matters 
