In his rebuttal to Fred, Dave says:
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.... 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....I, too, was shocked when John Evdemon announced at Think Tank that portability was never a goal of BPEL, and I agree with Dave that hyping process portability was a big factor in getting BPEL's "coalition of the willing" on board in the early days. So his dismay on this point is justified.
But in my view, the basic fallacy of Dave's argument relates to the difference between SOA and BPM. Yes, orchestration is important to SOA -- to create coarse-grained business services out of fine-grained services distributed over the ESB. And orchestration is also important to BPM -- to create end-to-end business processes by orchestrating business services and human tasks. But BPM is not SOA, and business services are not what BPM means by business processes.
BPEL is really good for orchestrating business services out of fine-grained APIs -- how SOA uses orchestration. It's less good -- although it can do it -- for orchestrating end-to-end business processes. I think, in the end, this is how it's going to play out in the marketplace as well: BPEL (or equivalent) within the SOA stack, and a separate process engine in the BPMS. The BPM pureplays, along with BEA and Tibco, are taking this approach, while IBM, Oracle, and SAP are still on the BPEL-or-bust path to 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.
For BPM, I think the portability layer moves to BPMN, probably in some successor version that eliminates the constructs that can't be mapped unambiguously to an execution language. If and when that happens, you may be able to execute a BPMN model on your choice of, say, Lombardi, BEA, or IBM engines, even though the execution languages are different.