There is more fallout from my posting a few weeks ago pertaining to the issues around BPEL 1.1, and moving to BPEL 2.0. It seems have started a debate here, and other bloggers have been picking up on it, either for or against.

For instance Joe McKendrick:

"The world has been having a love/hate relationship with BPEL — Business Process Execution Language. It is seen as the glue that will make all the moving parts of SOA work together, but often criticized as laden with vendor extensions and lacking flexibility."

Bruce Silver chimed in, and questioned the future role of BPEL for BPM:

"If you look at why BPEL 1.1 isn't portable for BPM, it comes down to three basic limitations in the language: no support for human tasks, no support for subprocesses, and pitiful data manipulation. BPEL 2.0 mostly fixes the data manipulation part, but not human tasks and subprocesses. So how can you use an orchestration language without support for human tasks and subprocesses? For creating business services! You get more than Fred’s "knowledge-portability." You get actual runtime portability, and a choice of engines at a commodity price. So it has real value there."

The bottom line, if you're a BPEL vendor or a consulting firm doing BPEL, you love BPEL and will defend any issues that guys like me bring up. However, if you're eyes are open, than many questions still emerge...I'm clearly there.

What bothers me most about this issue is not the fact that the standard, at least in some respects, is letting SOA down, but that orchestration is such a powerful need within SOAs, and there are few other alternatives that offer a better approach, standardized or not. Thus, end users who are tasked with building solutions using emerging SOA standards such as BPEL should begin to lean on their vendors now, as well as get involved more with their respective standards organizations.

Posted by Dave Linthicum on October 2, 2006 05:45 AM