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.” In that aim, there should be a large number of articles discussing what BPEL is good for, and what it is not, but there are very few articles of this nature.
The article “Why BPEL is not the holy grail for BPM” explores the promises and claims of the BPEL proponents and find some serious gaps in what BPEL delivers.
It starts by citing a reference that every should know from the BPMN FAQ: “By design there are some limitations on the process topologies that can be described in BPEL, so it is possible to represent processes in BPMN that cannot be mapped to BPEL”.
In my experience, fans of BPEL make the following assumptions:
1) The people making the processes are programmers
2) The activities in a process only need to send, receive, or transform XML data
3) Any standard will be better than no standard
Assumptions (1) and (2) are valid in some situations; the product category that we call EAI is in fact configured primarily by programmers, and need only to send, receive, and manipulate bytes of data. So for EAI, BPEL might be a reasonable choice. But many BPM products are designed to be configured by non-programmers; by the business people themselves (and that is indeed why we call them business processes in the first place). Non-BPEL approach exist that allow non-programmers to draw up and execute processes, safely and reliably. Those processes are qualitatively different from the processes a programmer might draw up, and many people familiar with EAI-style “BPM” are incredulous, but that basically circular reasoning based on the assumption that the process designer is a programmer. To be fair, some believe that business people will draw up initial process diagrams, that will then be fixed up by programmers. But there are other situations where there is a no programmer at all, and that in those situations BPEL would be a poor choice.
Assumption (3) drives people to think that since there is overwhelming “magazine” evidence that BPEL is the right standard, then anyone not supporting BPEL is simply too lazy or trying to disrupt the marketplace. Unfortunately for these people, the process world is inherently more complex than they realize; the variations among approaches are not simply the randomness of vendor whim, but in fact an appropriates response to the variations in the needs for process support. People should keep in mind real requirements: if BPEL meets the need, then fine, but don’t blindly assume that one size will necessarily fit all.
We need more good articles on the situations that BPEL is, and is not, useful. And let us view with great suspicion any report that states that BPEL is unconditionally the right architecture for all processes.
Yes, you have made excellent points about where BPEL is useful and where it is not. There is no one Holy Grail for BPM, just like there is no one Holy Grail for anything else in technology, or maybe even in life. I recently ran across a blog (http://blog.athico.com/2008/10/rules-and-bpel-joe-white-recondo.html )describing the real experiences of a customer of who went the BPEL route. It might be worthwhile for your users to learn from their experience.
I think that the right answer is a combination of technologies rather than trying to force-fit one technology to do everything.
Pingback: links for 2008-10-27 « steinarcarlsen
Hi Keith. Hope you are doing well. This is an interesting post. I am not going to get involved into the fight but I think that this (BPEL vs. XPDL, notations, etc.) is fundamentally the wrong battle. The key part that is missing today is a standard way of representing activities on the web. I know that given your past work on ASAP and SWAP, that this is something close to your heart. There is huge value in standardizing that interface and JSON+REST over a great foundation for doing so. Why not push for that first and let the various orchestration abstraction align?
Edwin, you make a good point. I recently have been pushed, and am working, in that direction. There is a renewed vigor for a REST adaptation of Wf-XML. How ironic it is that it started originally REST oriented, then we went to tremendous troubl eto fit it to the SOAP paradigm, only to get pushed back towards REST.
But there is a reason for this debate. I think the real problem is “transforming” the diagram to anything else. The diagram should remain the diagram throughout execution. Why? Transforming to another form for execution means that the people using it can no longer “see” what it happening in the same way that they drew it. This means if there are problems it is harder to understand what went wrong. It means if they get analytical results, those result do not necessarily apply to the original diagram. And it also means that round-trip is questionable. But if you don’t transform, if the diagram remains the same (WYDIWYE), then all of these problem go away.
I am investigating JSON. Maybe you can advise. Seems like it is good for server to browser communication for ajax and mashups, but I am not convinced it is best for server to server communications.
For example, is there a JSON equivalent of RSS?