(this article was posted at SOA World 20-09-2006)
Let's face it, BPEL 1.1 was a bad standard that left so much out that many end users and vendors found it useless. In response, the vendors put a ton of proprietary extensions in their BPEL 1.1 - based products, thus diluting its value to the point of "why bother."
While I've been ranting and raving about this for some time, Dave Chappell does a much better job in explaining the limitations.
"Promoting BPEL's portability helps significantly in the first of these goals, since customers like the idea of not being locked in to a single vendor. But actually making customers successful has typically required extending BPEL in proprietary ways, which works against the language's promised portability. While BPEL purists might argue that all of these extensions should be provided via programming language-neutral web services interfaces, this isn't what?s actually happening in the products."
With huge investment in BPEL by the larger SOA players out there the dirty little secret is that BPEL 1.1 never really worked as advertised, and the amount of custom and proprietary extensions required making the technology useful meant that the money, time, and effort was pretty much wasted if standards and portability was the goal.
Enter WS-BPEL 2.0, and another opportunity for vendors to get BPEL right. You can find the draft specification here, which I read, and discovered that this spec was much improved, but with many issues that remain. For instance, WS-BPEL 2.0 has considerable differences to its previous 1.1 version. The major differences include syntax changes to the language, inclusion of new features including parallel for-each, and modifications to the semantic of existing constructions, such as compensation handling.
Hmmmm. So, what if I already implemented orchestrations using BPEL 1.1, what do I do now? In short, you purchased Beta and the world is moving to VHS (yes, I'm old). I thought that this article by BEA's Alexandre Alves did a good job in summing things up.
"For all but the simplest business processes, migration from BPEL 1.1 to BPEL 2.0 is not an easy task. Some of the syntactic changes can be automated as shown [in this article], however the semantic differences, especially when dealing with links, messaging, compensation handling, and data manipulation, will demand a comprehensive and time-consuming process."
I suspect the BPEL sales guys will get some angry calls around Christmas time from their users, perhaps more so considering the use of many proprietary extensions to get around the limitations of BPEL 1.1. Not a good way to start a standard, I guess that is why my old boss told me never buy products until release 3.0.
