Human-centric BPMers’ lack of love for BPEL is today taken for granted, but who knew there were BPEL-haters out there in the SOA world as well? After taking a look at the BPEL 2.0 spec, Dave Linthicum tries to reignite the bashing, based mostly on the facts that 1) processes still aren’t portable and 2) BPEL 2.0 is not backward-compatible with BPEL 1.1. Active Endpoints’ Fred Holahan counters with a spirited defense of BPEL. He says yes, BPEL is not 100% runtime-portable, but it is “knowledge-portable” — I guess sort of a process modeling language for programmers?
While I don’t think of myself as a BPEL-lover, I actually come down more on Fred’s side here than Daves’s. And I’ve moved to a more nuanced view that might provide a middle ground.
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.
[…] In another, more recently, post from Bruce, he talks about BPEL: “Human-centric BPMers’ lack of love for BPEL is today taken for granted, but who knew there were BPEL-haters out there in the SOA world as well?”. Further he goes on saying “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.”. And I think I agree with him on that on, because BPEL has already proved its lack of portability and everyone that has taken a look at the specification knows that the simplicity is no longer a design goal here (the BPEL 2.0 standard are even not backwards compatible, more on BPEL here). So, further I agree with Bruce that BPMN-model should be the best way to model and make portable business processes. Different platforms and vendors then have differents techniques for implementing/converting these models into a executable process language (like BPEL or something else). […]
[…] But yay, now we’re going to have a very nice orchestration and integration topping over all this web services offering. Long live REST and SOAP! And remember kids, REST is for noobs and SOAP is for the leet. And what’s with all the BPEL bashing? (Nice redux, btw.) I think all this antagonism is a bit off-course. Going little off-topic here (like I was having any… harrr!) but I preserve the right to include this reminder: ?BPEL is the XML glue that binds Web Services into cohesive units [and so on].? Isn’t that just great or what? Just all you enterprisey folks keep your durrty BPM hands off of this nice web services programming language. The 2.0 is already working well. All the transportability etc. might be nice extra features, but not that critical ? for me, at least, which admittedly may not be much. Well, on the other hand, I’m the developer programmer… […]
[…] OK, so far that sounds like a complete, but not especially cool, BPMS offering. Here’s the cool part, and it goes back to the recent BPEL discussion. Remember, a problem with BPEL in BPM has always been keeping the executable design in sync with the business analyst’s model once the developer has taken a whack at it — the notorious roundtripping problem. Oracle has solved that here with the Business Process Outline – a model that sits in between BPA (ARIS) and BPEL, with unambiguous mappings to both, and intelligible to business as well as IT. They described their conception of it last spring in Business Integration Journal, and I blogged about it then. But it’s place in the offering was not at all clear back then. Now it is. […]
Hello,
What’s the difference between orchestrating human tasks and system tasks? Behind a service there can be a human, cant it? A human can call a process as a service, cant she?
A sub-process is just another service, isn’t it? Are there any scenarios where abstracting services as sub-processer is ineffective?
– Jonas
Jonas,
Good questions. Human tasks are different from services in 2 ways. First, they are assigned to roles (mapped at runtime to users or groups) not service endpoints (URLs). Second, they are inherently stateful: ready, claimed, done, failed (e.g., see the BPEL4People white paper), whereas services are (from the consumer’s perspective) inherently stateless. The way these are handled in BPEL-based BPMSs is typically via a vendor-proprietary Task Manager service or a vendor-proprietary BPEL extension. In the first of these, BPEL creates tasks by invoking the Task Manager service, and those tasks are performed by users interacting with that service. When the task is done, the service calls back the process. Effectively I suppose you could call that a human-performed service, except that the details of the task are unknown to BPEL and it’s all vendor-proprietary.
Similarly for subprocesses. You can certainly define a second BPEL process and invoke it as a service from the first process, but there is no lifecycle coordination between them. For example, if the calling service has to terminate while the ‘subprocess’ is running, how does the subprocess get terminated? If there is a business transaction involved, how does compensation get triggered? You can do it with custom programming but it’s not built into the language.
These are the reasons IBM and SAP last year offeredthe BPEL4People and BPEL-SPE proposals — which supposedly will become draft specs once BPEL 2.0 is put to bed. The fact that they are pitched as “optional extensions” says there is still a sizable (majority?) segment of the BPEL community that couldn’t care less about these “BPM” concerns.
Take for example a tele-marketing scenario where a sales person calls up a potential customer and makes him buy stuff. Her work can be defined in a workflow with a lot of decision making through out the phone call. She can make the decisions but the workflow decides what the continuation will be. She will interact with the process using calls into the process, and receive tasks from the process. This is actually not different from how a system process works.
The assignment is called routing in relation to SOA, a role is called interface, and the human is called the endpoint. I don’t even see why we cannot use the same repository for both roles, interfaces, humans, and endpoints.
Why should a service be stateless? A call to a long-running process will be similar to a long-running task. The human will call back into the process the same way as a sub-process would do for updating the state of the job.
Wouldn’t just the terminated caller process compensate the sub-process from within a compensation handler?
[…] In another, more recently, post from Bruce, he talks about BPEL: “Human-centric BPMers’ lack of love for BPEL is today taken for granted, but who knew there were BPEL-haters out there in the SOA world as well?”. Further he goes on saying “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.”. And I think I agree with him on that on, because BPEL has already proved its lack of portability and everyone that has taken a look at the specification knows that the simplicity is no longer a design goal here (the BPEL 2.0 standard are even not backwards compatible, more on BPEL here). So, further I agree with Bruce that BPMN-model should be the best way to model and make portable business processes. Different platforms and vendors then have differents techniques for implementing/converting these models into a executable process language (like BPEL or something else). […]