Frank's Blog

BPMN 2.0 drafts  

The BPMN 2.0 draft specifications are out for inspection (#1, #2). Yes indeed, there are two different proposals following the request for proposals from the OMG.

The first proposal comes from IBM, Oracle, SAP, and Unisys as submitters, but also IDS Scheer, Software AG, TIBCO, Intalio, etc. are listed as contributors. Interestingly, even two consultants are named: Accenture and CapGemini. This proposal is strongly based on the original specification.

The second proposal comes from Adaptive, Axway Software, EDS, Lombardi Software, MEGA International, Troux, Unisys as submitters (note Unisys twice!). Additional contributors are networks like BPM Focus or large industries such as Lockheed Martin. Their proposal strongly focuses on aligning the existing BPMN notation with the Business Process Definition Metamodel (BPDM) of the OMG.

BPMN itself now seems to be named Business Process Model and Notation instead of Business Process Modeling Notation. The change in the name also points out the major efforts of the 2.0 specifications: the definition of a sound meta-model.

In the following discussion, I focus on the highlights of the first proposal. I personally stick to that one, since it resembles the style of the existing BPMN specification and enhances it further. The second proposal, in contrast, looks more like a set of tables and figures that is hardly readable. It also doesn't seem to contain really noteworthy information beyond a meta-model for BPMN. More interestingly, of course, is the fact that most major BPM vendor stick to the first proposal.

Now, let's discuss the scope of the BPMN 2.0 draft specification (as in all following paragraphs, I consider the first proposal):

"The BPMN 2.0 specification extends the scope and capabilities of the BPMN 1.1 in several areas:
- Formalizes the execution semantics for all BPMN elements
- Defines an extensibility mechanism for both process model extensions and graphical extensions
- Refines event composition and correlation
- Extends the definition of human interactions
- Defines a choreography model
This specification also resolves known BPMN 1.1 inconsistencies and ambiguities."
(cited from the draft)

Out of scope are aspects such as
"- Definition of organizational models and resources
- Modeling of functional breakdowns
- Data and information models
- Modeling of strategy
- Business rules models"
(cited from the draft)

The major enhancements of the specification include an XML Schema-based a meta-model, support for choreographies, execution semantics, a refined BPEL-mapping, and a lot of smaller additions and fixes.

XML Schema-based meta-model

All of the BPMN elements are described in XML schema, so that a standard meta-model is provided. What is still missing---besides the headline---is a visual interchange meta-model. This will be quite useful, since otherwise the models must be auto-layouted.


An optional part of the specification introduces choreography models as a third kind of model type. The other two are orchestrations (private, abstract) and collaborations. Choreography (in terms of the specification) is "a definition of the expected behavior, basically a procedural contract, between interacting Participants. While a normal Process exists within a Pool, a Choreography exists between Pools (or Participants)". A choreography thus basically resembles an interaction view (such as Let's dance), whereas collaboration processes resemble an end-point view. I don't want to go into detail; the picture below shows an example.

The choreography consists of so-called choreography tasks, which denote a set of interacting participants. The name of the interaction is written in the center, whereas the different participants are shown at the top and the bottom (there can be more than two participants). The initiating participant is shown with a shaded background. The draft specification defines a number of rules on how the choreography tasks could be combined.

When we talk about choreographies, we also need to talk about conversations, defined in BPMN as "[a conversation] is a set of message exchanges (Message Flow) that share the same Correlation". The specification also defined several kinds of correlation (key-based, expression-based) which are closely related to BPEL. However, the section on choreographies and conversations is still quite incomplete.

Execution semantics

The BPMN now also sports informal execution semantics. The core concept here is a scope, which describes the context in which execution of an activity happens. The scope has a lifecycle with states like activated, in execution, completed, in compensation, etc. Those lifecycles are also defined for other constructs. The execution semantics itself is described in a tabular fashion for the different flow objects. Furthermore, the description directly points to the corresponding workflow patterns. What is missing, however, is a formal representation. The OR-Join, for instance, is still only described very vague. On the other hand, the informal description keeps a lot of freedom for implementers.


The BPEL-mapping now assumes the BPD to be sound, which I find a quite imprecise requirement, since BPMN doesn’t has a formal semantics based on Petri nets (where soundness is defined on): "To map a BPMN orchestration process to WS-BPEL it must be sound, that is it must contain neither a deadlock nor a lack of synchronization. A deadlock is a reachable state of the process that contains a token on some sequence flow that cannot be removed in any possible future. A lack of synchronization is a reachable state of the process where there is more than one token on some sequence flow. For further explanation of these terms, we refer to the literature."

Still, the provided BPEL-mapping is a major step forward, since it now focuses on the mapping of simple patterns instead of examples. More elaborate BPMN to BPEL mappings are left to tool vendors by stating a rather hard requirement: "The observable behavior of the target WS-BPEL process MUST match the operational semantics of the mapped BPMN process. Also, the mappings described in section 11.1 SHOULD be used where applicable".

Other enhancements

The draft specification also contains a lot of other enhancements such as multiple pool instances, markers for the different task types, collections of data objects, or extensions for human interactions (performers, owners). The specification defines an explicit extensibility model that can be used to integrate other artifacts.

The events have been extended (once more) and some of them are now available in a non-interrupting fashion. A new kind of event resembles the star trek symbol, it is used for escalation. The attached intermediate events can now also be represented as so-called event sub-processes. Those are drawn inside the surrounding process and have access to the context of the parent process.

The specification still does not define a specific data-format or query language, but XML Schema and XPath are highly recommended.

Final remarks

I personally like the draft specification pretty much. Readers familiar with the 1.1 specification will feel right home and find a lot of clarification. I also like the idea of adding a new model type, the choreographies. The key ideas of interactions are, however, difficult to explain to people used to end-point-based choreographies. Furthermore, all the difficult things like enforceability need to be considered.

The specification itself is written rather informal, with sometimes lazy use of keywords, such as activity lifecycle (do they mean an activity instance lifecycle?). I do understand that the specification is not a self-contained book on BPM, but at least they should cite the terminology they use. The same holds for the mentioned concepts like soundness or enforceability. Still, the specification is labeled draft and I suppose many things will be well polished in the final release.

Addition: Torben pointed me to three blog entries of Bruce Silver discussing the IBM et al proposal for BPMN 2.0: #1, #2, #3. Thanks Torben!


gucci outlet 

I personally like the draft specification pretty much. Readers familiar with the 1.1 specification will feel right home and find a lot of clarification.

Just a comment about the visual exchange format: It is coming, but it was just not ready for this draft.

Add Comment

Comments are not available for this entry.