Responses to The Case Against BPEL
Sunday, November 06, 2005
Of the various responses I’ve seen to my latest Opinari
, perhaps the most interesting came from Oracle’s Edwin Khodabakchian. Edwin was CEO of Collaxa, probably the most visible provider of a BPEL-focused product prior to its acquisition by Oracle. His comments
appeared as a response to this post
The main argument my article makes is this: BPEL is useful for specifying business protocols, which are sets of web services interactions defined by what the BPEL spec calls abstract processes
. It’s significantly less useful for defining portable business processes, referred to as executable processes
by the BPEL spec. Too much is left undefined to allow true portability for a complete solution. Given this short summary, here are a few responses to Edwin’s main points:
- Edwin states “Saying that BPEL is useful for abstract processes but not for executable processes is out of touch with reality. Many vendors have support for executable BPEL processes today”. The point of my article is not that vendors don’t support BPEL executable processes today—they certainly do—but rather that BPEL is so incomplete in this area that it’s not all that much better than a proprietary language would be for describing complete and portable business processes.
- Edwin suggests that the way to solve BPEL’s portability limitations for executable processes is with the Web Services Invocation Framework (WSIF)
. But WSIF is an open source Java spec. What about the half of the world that uses .NET? If the goal is to map BPEL portably to Java, why not just use the BPELJ
proposal made by IBM and BEA some time ago? In fact, why create a separate language for process logic at all? It would certainly be possible to define a Java package with the functionality of BPEL, avoiding the need for yet another language. The truth is that Microsoft’s support for BPEL, and the cross-platform portability this implies, is one of the primary reasons the language has value. Using WSIF to address BPEL’s portability shortcomings would obviate this important part of the language’s potential benefits.
- Edwin points out that BPEL’s lack of support for human-oriented processes isn’t a problem, since solutions are provided by several products, including those from Oracle, IBM, and BEA. True, but the problem is that each one does it differently. Different vendors can add functionality to BPEL in any way they like, but these different solutions make it more difficult to move process definitions from one system to another. And while there may one day be a standard BPEL approach for describing human interaction—the OASIS committee is working on this—widespread support for this in products is surely years away. Having spent many years of my life working in the standards world, I’ve learned to be cynical about claims that something will be fixed in a future version of the spec. In my experience, this is frequently an excuse for vendors to add proprietary extensions that lock users into their products today.
- Edwin tells a story about a CRM vendor whose BPEL processes executed on both Collaxa’s BPEL engine and one from another vendor. Yet this example isn’t relevant to my argument. BPEL certainly is portable for what it defines—I’m not disputing this. The problem lies in what the language doesn’t define.
- Edwin observes that “the only vendors fighting BPEL today are those who are behind in the race to support it”. I’m not sure which vendors Edwin believes are fighting BPEL, since it’s supported today by pretty much every major player in this market. In any case, I’m not a vendor. The observations in my article, like everything I write, reflect my personal perspective. I’m also not fighting BPEL. Instead, my goal is to inject a bit more clarity into the debate around this widely-discussed language.