I should have known that disputing Michael Rowley’s contention that mapping BPMN to BPEL was “simpler” than a straight BPMN 2.0 solution would invite a further response. Two, actually, one from Michael and another from Frank Leymann. Hmmm. In a room with those two, I’m at best the third smartest guy. But unlike the “stacker-bashing” flame wars of 2008, their points are well stated and sort of illuminating. Anyway I can’t resist taking another shot.
I tried to let Michael off the hook the first time by suggesting maybe he meant a hybrid BPMN-BPEL solution was simpler for engine vendors. But no, he says he means simpler for process modelers! OK, I’m thinking of three products: Oracle’s BPA Suite (BPMN) mapped to BPEL Designer through their Blueprint intermediary notation. No way that’s simpler. I think Oracle would be the first to admit it, and Oracle BPM 11gR1 will put the nail in that one. How about IBM’s WebSphere Modeler’s quasi-BPMN mode with “direct deploy”, i.e. avoiding a stop in WID’s BPEL editor? Closer to “simple” I guess, but the direct deploy is just to a test environment that outputs design bugs to be fixed in WID. I can hear the stacker-bashing competitors snickering from here: that’s simple? OK how about Michael’s own ActiveVOS? I just saw a beta demo a couple months back — maybe it’s changed — but that was a BPMN 2.0 diagram with the node names changed to BPEL. Now why would you want to do that? His argument would have a lot more power if he just kept the BPMN names and hid the BPEL execution language under the covers. You only keep the BPEL nomenclature if the diagram is secondary to the XML, the BPEL language. So I guess he means this is “simpler” to BPEL developers, not mainstream process modelers. OK, I’ll concede that point.
Both Michael and Frank take me to task for saying that BPEL is block oriented while BPMN is graph oriented. Yes we know BPEL does support the flow/link construct in addition to the more frequently used sequence block construct, but it still has those restrictions – no freeform loopbacks, no “interleaving.” Try explaining what interleaved topologies means to a typical BPMN modeler. He presents a BPMN diagram that would probably give interleaving errors in my BPMN tool if I tried to export to BPEL, but it works in ActiveVOS because they use eClarus’s more-intelligent-than-the-others’ BPEL mapping algorithms. But even there Michael admits that some diagrams still require a workaround. Again, I think it fails the “simplicity” test.
Frank Leymann’s post is more interesting, I think. Frank was one of IBM’s original BPM gurus. He jumps in to defend BPEL as today’s BPM runtime standard, says I’m flat wrong to deny that. I guess among all the BPM runtime standards BPEL is the most widely adopted, I’ll agree with that. But among all BPMS platforms? BPEL is the runtime of just a few. Most BPMSs today have proprietary runtimes. That’s a plain fact.
But here is where Frank gets to the heart of the BPMN-BPEL issue:
We are faced with the following problem: How can we bridge the gap between BPEL (an execution language with rigor operational semantics) and BPMN (a visual language with informal semantics)…. One possible way to solve this problem is to standardize a visual representation for BPEL… But the problem is that BPMN contains quite a number of constructs that… have no direct correspondence in BPEL. Thus, BPEL extensions would be needed to support
[them]… but extending BPEL is time consuming (see the recent BPEL4People extensions) while BPMN users want to see a solution ?soon?.The other way to solve the problem ? the way that has been taken ? is to move BPMN forward… to make transforming BPMN process models to BPEL much easier. The fundamental enhancements of BPMN 2.0 [now] enable this….
From a BPEL perspective the current situation is as follows: A subset of BPMN 2.0 is ?isomorphic? to BPEL. As a consequence, BPMN 2.0 encompasses a visual modeling language for BPEL ? this subset can be naturally transformed to BPEL and executed in a BPEL engine. From an architectural point of view, a tool supporting this BPMN subset is a layer on top of BPEL engines…. From a BPMN 2.0 perspective,… BPMN 2.0 is a process modeling language with an operational semantics [influenced] by BPEL… Thus, it is now possible to build an engine that directly supports BPMN 2.0 ? without the intermediate step of generating BPEL.
What he fails to explain is that the subset of BPMN that is isomorphic to BPEL is not a subset of BPMN elements or shapes in the diagram palette. It’s a subset of BPMN diagram topologies. We’re back to that same problem of explaining interleaved loops to a business process analyst. A tool that prevents modelers from drawing the problem patterns is probably going to enforce some kind of block structure, like the BPEL drawing tools do today. Alternatively, they can let the modeler have at it and then give the BPEL validation errors at the end.
The answer is just so obvious to me… and I think to Frank as well. He even says it right there: “It is possible to build an engine that directly supports BPMN 2.0 without the intermediate step of generating BPEL.” Duh. Oracle and IBM, two of the biggest BPEL vendors, essentially designed BPMN 2.0 with that specific intention. I’ll grant the obvious: Neither Oracle BPM 11g or IBM BPM v7 are shipping yet. But when they are, it’s hard to see BPEL as the simpler path forward.
I’m with you, Bruce – having to map BPMN to BPEL is a problem only a few vendors face, so they should solve it on their own if they think they have to use BPEL for execution for historic reasons. The rest of us should move on and do everything to spread good BPMN practice amongst the people doing the bulk of process modeling these days, the business consultants. After more than half a decade of BPEL its real value still escapes me. Is it cross-tool portability? Rarely works in real life, plus who cares? Why would I want to do that? Or is it to ease templated process creation and re-use? I doubt, as BPEL processes tend to be so technical, environment-specific and non-generalizable that they’re hard to share. So lets get used to the fact that the importance of BPEL will fade and that soon people will wonder why anybody every worried about mapping the future to the past.
hnehring:
I’m a BPEL developer and from my experience the value of BPEL is more related to the fact its a web service orchestration language and a language aligned to the service oriented model. It’s the same thing as a Java developer would probably say: -The real value of Java is not portability but that Java is very well aligned with the object oriented model. A BPMN guy would probably say the same thing. BPMN is the best notation for the process oriented model and that portability is secondary.
Portability is always a problem, not just technology wise, but also for other reasons like skills. One BPMN diagram is unreadable from one analyst to another (just recall all Bruce’s lecturing of bad process models through the years).
I don’t agree with you that one technology is belonging to the past and the other to the future. Maybe you’re right that the 2 technologies should evolve independently of each other and make both of them drive BPM/SOA forward. Maybe BPMN should be used for modeling only and BPEL for what it does best – web service orchestration. Why should this part of the industry be driving the illusion that we’re required of a zero coding solution. One guy do the model, another do the process, and the third implement the service. If there are just humans involved then use a BPMS with a proprietary implementation.
I doubt that we will ever see a model that executes without round tripping, plus that we need the competition between the technologies and standards.
For those who don’t know him,hnehring above (call him Harald) is SAP’s BPM marketing manager. Not sure if that puts his comments in a different light…
jonase, you raise some good points. I agree BPEL will live on as an orchestration language for SOA developers building business services. And for some shops, maybe even as an end to end BPM runtime. I agree as well there will always be a handoff between business-created “models” and IT-hardened executable designs. But if a single language/metamodel/notation like BPMN can do both ends, I just don’t see how mapping it to a different language and metamodel is better.
Bruce,
From my understanding Active Endpoints goal is to make their own product better by using BPMN over BPEL, not the way around.
(SIGH)
Discussions of suitability of languages is meaningless when abstracted away from the purpose to which you want to put the language.
As you accurately point out, the decision to use BPEL on the backend will limit your expressibility in BPMN. As long as you say only things that BPEL can do, then converting to BPEL will be problem-free.
As I have pointed out elsewhere, Dr. Seuss used a language of 200 words to write amazing stories suitable to kids learning to read, but would be entirely unsuitable for a medical journal.
Discussing the suitability of BPEL in abstract is like asking whether Dr. Seuss picked the right 200 words. Given a particularly purpose for those words, it might be fruitful, but suggesting that 200 words will work for all possible conversations is mind-numbingly futile. Apparently, 80,000 words is not nearly sufficient for a medical journal; they keep making up new ones every day.
I personally think you are right … the debate is over. BPEL has its place, but it not for everything. Thanks for helping the stragglers to understand this.
Thanks Keith. If only the problem were as simple as limiting the BPMN vocabulary. For example you could say the BPEL set means no OR gateways (or conditional sequence flows) and no boundary events (use event subprocesses instead). That would get you close (by the way, I don’t think the BPEL section of BPMN 2.0 even suggests that)… but you can create interleaving with plain old XOR gateways. It’s the diagram topologies that are at issue here… and you just can’t explain that to a typical BPMN modeler. Or maybe even a typical Java developer either.
Jonase, in my sloppy, black-and-white (marketing) view I relegated BPEL to the past in a very general way. You’re absolutely right, it is and remains very valuable for service orchestration. Which is and remains an activity requiring skilled developers knowing the orchestration itself AS WELL AS the environment it takes place in. Business Process Management on the other hand is foremost a management discipline dealing with an organization’s processes REGARDSLESS of the (technical) environment they might be mapped to eventually. That’s why I think the discipline needs a way to express its assets independently of any mapping to a specific software infrastructure. That’s why we need BPMN and should be wary of any attempt to shackle it to BPEL.
Harald
PS: This doesn’t necessarily map 100% to SAP’s view in all aspects.
Harald, I’m not choosing side in this matter but wouldn’t that be the case for all attempts to map BPMN to an underlying executable model (not just BPEL)? Unfortunately that will not align with any BPMS vendor’s roadmap (including SAP’s), would it? I thought that BPMN was tha thing and all vendors are aiming for a BPMN modeler – some mapping it to BPEL, some to its own proprietary execution model, and some to BPMN 2.0 model for execution (if there is one?). Is this path good or bad for whom?
Jonase, don’t know if I’m getting your point completely. Maybe the problem is with the word “map”, implying some loss of fidelity or indicating round-tripping issues. I guess what works well for programming languages (take Java or Ruby and their standardized “mappings” to execution) is harder to achieve in a standardized way on the business process model level (i.e. executable portability). If we can achieve BPMN meta model exchange between different execution environments (e.g. BPMS) without having to imply the way they’re going to be executed (e.g. BPEL, state machines, native code, …) we’ve already achieved a lot.
[…] To Mendling et al, “structured” means “block-structured.” That would make Michael Rowley happy, but not mainstream BPMN modelers. No, I think these guys are living in a BPEL […]
BPEL is a better fit for a integration centric workflow, and BPM is a better fit whenever there is a requirement for Human centric workflow. Comparing BPM and BPEL is just like comparing apples with oranges.