The second roundtable that I attended on last Tuesday’s sessions was on BPEL, headed up by Ismael Ghalimi. It was great to finally meet Ismael in person: we’ve been corresponding by email and blog comments for quite a while, and have even done a webinar together, but this is the first time that we’ve been in the same place at the same time.
We started with a discussion of BPEL4People, and how it’s changed from the original specification (which proposed implementing human-facing tasks as web services rather than changing BPEL) to the current specification (which proposes extensions to BPEL for human-facing tasks).
The title of the roundtable was “is BPEL relevant”, and we covered several aspects of that. First, a few people around the table (which included a few vendors with a vested interest in BPEL) stated that BPEL is relevant in the same way that SQL is relevant: as a standardized language that allows a separation of the design/development environment from the execution environment. Based on the lively discussion, some of these guys have spent a lot of time thinking about the BPEL-SQL analogy. My argument (I have no vested interest, so could have easily argued the opposite way) was that maybe it *should* be relevant in that way, but really isn’t in the consolidated model-design-execute environments that we see in BPM today. The real question may be, at what level is BPEL relevant: model, design, code or execution? Everyone agreed that it’s not relevant to business users or analysts, but it’s not clear where the line of relevance lies.
We also discussed how native BPEL execution providing code monitoring during execution, such that any code faults will have more semantic information included without having to build a monitoring stack on top of it. What remains to be seen is if BPEL4People will provide some level of business-relevant monitoring, or if that still has to be built on top of the execution layer.
What we’re seeing is that for the most part, it’s the larger vendors that are adopting BPEL — possibly as a common language to glue together all the BPM pieces that they’re acquiring — whereas the smaller vendors provided a consolidated (and therefore closed) suite environment where the execution language doesn’t matter, and in fact, their engine may be a competitive differentiator.
Regarding your second paragraph: What do you mean with “original specification”? The white paper published in 2005? Wasn’t this BPEL4People proposal always about an extension of the BPEL? (“To support a broad range of scenarios that involve people within business processes, a BPEL extension is required.”)
I, as a business process analyst, appreciate the BPMS that don’t show me the “code”. I think BPEL is difficult to understand to business people and BPMN is there for us. A BPMS that can translate BPMN (or BPDM) to his execution language (what ever it is) is better for me.
Fabian, what I heard from the BPEL experts around the table — primarily Ismael and someone from Oracle — is that the original white paper (probably not truly a specification) from 2005 had human interaction modelled as web service calls such that BPEL didn’t require any extensions, whereas the current specification extends BPEL to include the human-facing task support. I haven’t read either specification, but that’s my understanding.
Gabriel, I agree that BPMN is the way to go for modelling processes; I don’t think that it’s anyone’s intention that you write (or even see) naked BPEL. The only sticking point is that BPEL still doesn’t support the full BPMN standard.