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.