One possible reason for this is that BPEL is considered a ?language? while BPMN just a ?notation,? i.e. a drawing format. But any student of my BPMN training (www.bpmessentials.com) ? or anyone who has glanced at the BPMN spec ? can tell you that BPMN is far more than a Visio stencil. The various shapes and lines have specific meanings and rules behind them, and both the shapes and the rules were developed for the purposes of process modeling, independent of an underlying execution language for implementation. (BPMN does assume the runtime engine can support events that interrupt tasks and subprocesses, a natural feature of SOA-era engines missing in some traditional workflow engines.)
Process modeling is inherently a business function that does not require understanding of the technical detail of the implementation. In order to be universally understood by business process analysts, BPMN has only three basic shapes ? activity (a step in the process that performs work), gateway (routing control logic), and event (a signal that something has ?happened?). That?s it, just three. But with a few standard subtypes of these three basic shapes, BPMN is also precise enough to support detailed simulation analysis, and in tools like Appian, Lombardi, Savvion, or Intalio, the front end of executable design as well.
Much of the energy behind adoption of BPMN as a standard is in fact uptake by the BPM suite vendors as a design front end. Its advantage is that it supports a new rapid iterative implementation style based on continuous business/IT collaboration, instead of the alternative ?handoff? style in which changes made in the executable design environment can get out of sync with the model (the notorious ?round-tripping? problem). But we should not lose sight of the fact that BPMN is first and foremost a modeling notation, intended for use by business.
What?s always been missing in BPMN has been portability, the simple idea that a valid model drawn in tool A can be imported into tool B with the assurance that it will still ?work?. To me that means two things we don?t yet have: 1) a specified subset of the BPMN shapes (including subtypes and their attributes) that must be supported; and 2) a unique and unambiguous mapping from the diagram to XML. With BPEL we have neither of these problems. You need to support all of it to be compliant, and BPEL itself defines the XML. In other words, BPEL is a ?language.? (The penalty BPEL pays for this is that the language does not include everything you need, but that?s another story.)
So what would BPMN as a language look like? The logical thing would be to have, underneath the process element, things like activity, gateway, and event. Also, you would need elements like pool, sequenceFlow, and messageFlow, other core BPMN concepts. The mapping between the graphics and the XML would be simple and unambiguous. The metamodel, or interrelationship of these concepts, is already defined in the BPMN 1.0 spec narrative, which is essentially unchanged in three years. The detailed semantics of that metamodel, while perhaps not something you can plug into a developer tool like Eclipse, is precise enough to serve BPMN?s primary purpose, which is process modeling by business. More precise semantics required for detailed process execution or model-driven architecture, could be layered on afterward in the design environment.
The benefits of treating BPMN as a language would be twofold. The first benefit is guaranteed portability of models. This is so absolutely fundamental it?s amazing that BPMN has gotten as far as it has without it. The second benefit is reinforcing to process modelers that there are precise semantics and rules behind the BPMN shapes. People naturally accept there is some rigorous structure behind a language, but somehow think that graphics can mean whatever you want them to mean. The language would not impose constraints such as BPEL?s block-oriented structures on the process modeler ? you can still freely connect anything to anything (more or less) ? but users might be more inclined to learn the rules, and tools would provide validators that make it easier to follow them.
My problem with both BPDM and the Intalio efforts to date are that they are not designed for process modelers, but for developers using Eclipse. Both complicate the modeling ?language? with artifacts of Eclipse?s inherently non-business-friendly model-driven architecture, called EMF. In other words, the XML schema for BPMN is not designed to be a simple tool-independent reflection of the ?language?, but instead something that an Eclipse-based BPMN tool can leverage, along with EMF, to generate executable code. That?s a different purpose entirely.
How does this ?pollute? the schema? Well, for instance, instead of having separate activity, gateway, and event datatypes, the Eclipse Foundation schema includes them all in a single element called vertices. Why? Because each XML element type in the schema generates 15 Java classes using Eclipse MDA, and if you had a ?sensible? schema the implementation code would be too unwieldy. In other words, the Java tail is wagging the BPMN dog. I suspect the BPDM serialization will be even worse from a business modeling perspective. So far the schema they have published is not even valid per the XML schema language, and contains no root elements, something needed by any XML tool (but maybe not by Eclipse).
XPDL 2.0, on the other hand, is based on ?real? XML, but it does not use the language of BPMN. Recall that XPDL originally was intended as a generic interchange format between 100 proprietary workflow tools. To support BPMN, XPDL 2.0 essentially enlarged it to 101. In other words, XPDL guarantees there is a place to stuff any BPMN shape, line, or attribute, but the schema does not reflect the BPMN metamodel, terminology, or semantics. This still might be the best option, but with so many different places to stuff the info, it?s not clear that the BPMN-to-XPDL mapping is unique, i.e. portability without a side agreement between tool vendors may not be assured.
A commonly accepted portability standard for BPMN is still just out of reach. To be fair, both BPDM and the Intalio efforts are still work in progress, and WfMC could always tweak XPDL if they sense an opportunity. I think if we began to think about BPMN as a language instead of just a drawing format, it might show a clearer path to the desired end result.