Fred Holahan, from Active Endpoints, Inc. did a good job in taking me to task in response to my BPEL post last week. I can understand his frustration and defensiveness giving that BPEL is core to their technology, and the fact that BPEL has been getting hammered recently in the press and blogashere. However, I'm really discussing the quality of the core standard here and not a product instance.
What's more, this is "Real World SOA." It's very important to talk about the issues around technology, approaches, and standards, as well as the benefits, else you're just drinking the SOA hype Kool-Aid. Truth-be-told, standards have good points and bad points, and discussing both does not mean that you're a "naysayer," only that you're seeking a clear view of the reality.
What's most frustrating about the issues here is that orchestration is indeed a core feature of SOA...the configuration component that makes orchestration that part of the architecture providing agility. Quoting myself:
"Orchestration, at least the notion, is a necessity if you are building a SOA. It's the layer that creates business solutions from the vast array of services and information flows found in new and existing systems. Orchestration is a godlike control mechanism that's able to put our SOA to work, as well as provide a point of control. Orchestration layers allow you to change the way your business functions, as needed, to define or redefine any business process on-the-fly. This provides the business with the flexibility and agility needed, and the core value of SOA."
The notion that portability or interoperability was never a promise of BPEL 1.1 does not jive with what has been said and written by the BPEL vendors, analysts, and bloggers. Here are a few examples:
"...therefore the promise of BPEL portability has not yet arrived,..."
"The key goal of BPEL is portability."
"The Business Process Execution Language for Web Services (BPEL4WS or BPEL for short) is an XML-based language for defining business processes that provides an interoperable, portable language for both abstract and executable processes..."
You get the idea, and thus the selling point behind most standards...that your IP will be protected because it's transportable to other technologies (albeit they almost never are).
Moreover, orchestration, and BPEL attempting to provide an enabling standard for orchestration are much more complex and far reaching than database query standards or data interchange standards, that's the problem here. In essence you're defining a standards layer as a "platform" for meta-applications existing above native processes and services. With BPEL 1.1 many of those capabilities are missing, that is why many vendors added them on as proprietary extensions...the issue at hand.
So, you put your hopes on the next release. However, Wikipedia:
"This change in name and version number reflects the significant and in many cases incompatible differences between BPEL4WS 1.1 and WS-BPEL 2.0."
Or, David Ogren:
"On the other side, the vendors know that there will be a huge chasm to cross between BPEL4WS 1.1 and WS-BPEL 2.0, and that even WS-BPEL 2.0 is only a tiny subset of what a BPM vendor needs to include in their product."
Enough said, and there is much work to be done.
Posted by Dave Linthicum on September 23, 2006 06:49 AM
![[VoiceIndigo Mobilize - Listen to podcasts on your mobile phone]](http://www.voiceindigo.com/ht/images/mobilize_logo_sm.gif){kind=logo}
