However, BPMN is not ?just a notation.? The semantics are defined in the text of the specification. A non-public draft of BPMN 1.1 metamodel exists ... [but] moving forward, how are BPMN semantics aligned with other OMG process work?That alignment was "supposed" to be what BPMN 2.0 would be about. But as I noted a couple days back, Frank McCabe of Fujitsu and the BPMN TC in OMG leaked that while the BPMN group thought they were defining precise process semantics, others at OMG (I inferred maybe the BPDM guys?) thought the goal was just a drawing notation for business modeling. And at that impasse, things, sez Frank, "seem to be a bit stuck right now."
OK, BPMN 2.0 may or may not exist, may or may not be out in September, and may or may not have anything to do with a notation for portable process design. But it should. The interests of the BPMS vendors (and users) may not be the same as modeling vendors. So if OMG can't do the right thing, I think the BPMS guys should go off and just do it themselves. Otherwise the mantra or dream of "BPEL doesn't matter" can't come to pass.
Here's why.
In my view a key goal of all this has to be portability of the BPMN design. Model/design in tool A and run on engine B. I've written a lot about how BPEL isn't portable, because human workflow, subprocess coordination, even data manipulation are vendor-specific. But it's still 100 times more portable than non-BPEL execution languages; you don't have to start over from scratch when you switch BPMS vendors.
The things that get in the way of unambiguously mapping BPMN to BPEL today are the freeform GOTOs and crazy merge patterns that BPMN allows. Again, see McCabe on this. Some of those pathological use cases, I say throw them out, don't allow them in BPMN 2.0. If they're hard for a computer scientist to understand, why do you think business analysts can use them unambiguously? They're not even that important to BPMN anyway.
The important and interesting part of BPMN is stuff like activity groups with intermediate events, transaction compensation, and pools representing collaborating processes (or independent subprocesses) synchronized through messages. That's the part that let's you do cool things like respond to events. And BPEL has no problem with those, because BPMN was developed with BPEL in mind! (Well, BPML actually, but practically the same thing.) Most workflow vendors dissed BPEL because their existing process engines couldn't do those things... they'd have to break their product to implement it. They don't diss BPMN, but they just ignore the cool parts. Again, they'd have to break the product to implement them. Kudos to Phil, who actually did break his own product to be able to implement the BPMN cool stuff.
So here's the problem. A BPMN where products are allowed to omit diagram semantics they don't like can never be a portable design language. That's obvious. So you need all that MUST-SUPPORT and MAY-SUPPORT kind of thing, where all the important portability considerations are in the MUST-SUPPORT column. The basic tradeoff is ditch the GOTO and merge semantics that make algorithmic mapping to BPEL and other block languages impossible, and make the cool stuff - events, message flows, compensation and exception handlers - required for BPMN 2.0 compliance. Nail it down with a formal metamodel and schema. (In fact, if you did the first part, XPDL 2.0 would probably work just fine -- the metamodel/schema is already done. Without the first part, XPDL 2.0 doesn't give you portability.)
Then you can add on a methodology behind the diagram, and teach business analysts how to map processes to it... including the cool stuff.
I have a feeling this is not the BPM 2.0 that SD Times is promising for September. But if BPMS vendors want a standard that provides portability without commoditizing the runtime, this is the way to go, OMG or not.