Today Robert Shapiro of XPDL 2.x fame, also a member of the BPMN 2.0 Finalization Task Force in OMG, delivered an update on progress toward completing both XPDL 2.2 and BPMN 2.0. Here is the link to the unedited replay. Also, Sandy Kemsley does her usual fine job of summarizing the high points here.
I would just add a couple points to the discussion. The first regards an explicit sorting of BPMN 2.0 shapes and symbols into subclasses for the purpose of enabling tool interoperability. I tried hard to get this into the draft last May but IBM, Oracle, and SAP didn’t want to commit to anything specific at that time regarding their initial “BPMN 2.0″-branded offerings. Apparently they are feeling more comfortable about it now, as Robert believes there is a chance this could make the final draft.
Even though BPMN defines only 3 basic flow elements – activity, gateway, and event – counting all the variants defined by border style, icons inside, markers, and diagram placement means there are dozens and dozens of semantically distinct shapes. No tool vendor with an associated BPMN engine, even a simulation engine, is going to support every single one. And that’s just the part of BPMN above the waterline. Beneath each element are countless sub-elements and attributes required to define executable detail.
So if you create a model in tool A and expect to import it to tool B, both of those tools have to support a common subset of elements. That’s what the subclasses are all about. Here is my view of them. The Simple class is setting the bar essentially at floor level. It is meant purely as a lowest common denominator. If a tool cannot support these shapes and serialize to BPMN 2.0 it should not be allowed to call itself a BPMN 2.0 tool, period. The Descriptive class corresponds to the Level 1 palette of my book BPMN Method and Style. It reflects what I believe are the shapes and symbols that should be understood by any business user who wants to read or write BPMN effectively. It is a challenge for tool vendors because it includes collaboration (pools, message flows, message start and end events). I hope those things stay in.
What used to be called the Analytical class, corresponding to my Level 2 “core” palette, got renamed DODAF in Robert’s preso. It is very close to the element set standardized by Michael zur Muehlen in working with the DODAF people. I agree with Sandy that calling this BPMN class DODAF is maybe not the best for an international standard, but realistically it’s all about user buy-in, and DODAF means a lot there. I suspect if OMG goes for it they will change the name. This class includes the most commonly used intermediate events – Message, Timer, Error – plus a few more – Escalation, Signal, Conditional. And additional gateway types, iteration markers, and other things. It sets the bar a bit high for tool vendors, but on the other hand, elements outside of the Analytical/DODAF class are unimportant, almost never used, and stand very little chance of ever being interoperable between tools.
OMG has studiously avoided any actual test of compliance for BPMN 2.0, so getting these subclasses into the final spec would be a major leap. Yes it’s true that most users simply assume that a “standard” implies tool interoperability, but that has been mostly a fake objective in this case. I think there is hope this time. I’ve seen a beta of IBM’s Compass BPMN editor and it is very close to the Descriptive level, maybe a bit more. And I expect Oracle will have something similar.
But you have to understand that these standards are inherently very conservative, and always favor tool vendor “adoption” – even in a proprietary way – over constraints assuring interoperability. That’s why it’s important for OMG to hear from users telling them they demand some level of practical tool interoperability, such as this subclass proposal. If you agree, please email the BPMN group and tell them. The address is bpmn2-ftf@omg.org.
The second point concerns Robert’s comments on the graphics information in BPMN. I wrote about this previously (The DI Mess), and in the end even the BPMN team managers in OMG admitted that what they put forward in the draft spec was unworkable. The new directives were to make the graphics interchange model a real BPMN-specific xsd and eliminate redundancy with the associated semantic model. Scott Schanel and I put forward a BPMNDI.xsd proposal that does this, and Robert’s preso says that the official OMG effort here carries forward our ideas. Having seen a draft of it, I would dispute that — it’s still too much like the old one for my taste — but the good news is that there seems to be forward movement at last on it. More good news is that Denis Gagne is driving the xsd side there (still the tail on the UML dog unfortunately), and since he is launching the Process Incubator tool referenced by Robert – mappings between Visio, BPMN2.0, and XPDL 2.2 representations – he will ultimately force himself to see which parts of BPMNDI are practical in real tools. That’s always helpful.
There is a lot still to do on BPMN 2.0 before the final vote, but all of it “under the covers” so to speak. Nothing significant in the notation or semantics is going to change.
Tags: bpmn 2.0, bpmn interoperability, omg, xpdl


Social comments and analytics for this post…
This post was mentioned on Twitter by BPM_news: BPMN 2.0 Update: Today Robert Shapiro of XPDL 2.x fame, also a member of the BPMN 2.0 Finalization Task Force in O… http://bit.ly/a7nGUv...
[...] 2.0 Update Easy AdSense by UnrealArtikel von Bruce Silver zum aktuellen Stand von BPMN 2.0: http://www.brsilver.com/wordpr.....-0-update/ February 4th, 2010 | Tags: BPM, BPMN, Business Process Management | Category: [...]
[...] BPMN 2.0 Update « BPMS Watch Bruce Silver's comments on yesterday's BPMN 2.0 Update webinar with Robert Shapiro (which I covered in a previous post). He has some great comments on interoperability, especially how the subclasses help with that in spite of OMG's avoidance of any tool interoperability compliance tests. (tags: bpa bpmn) Posted by Sandy Kemsley on Thursday, February 4, 2010, at 2:01 pm. Filed under Links. Follow any responses to this post with its comments RSS feed. You can post a comment or trackback from your blog. [...]
Hi,
As I read your update and listened to Shapiro’s presentation, I was surprised that neither of you mentioned the XMI representation of BPMN metamodel, and how it could help solve interoperability and portability of BPDs among applications and tools, respectively.
BPMN-2.0 UML Metamodel is an object representation, but XML is not object-oriented and is not good in representing object models. So, struggling to build XSD for BPMN-2.0 metamodel (as Shapiro pointed out in his presentation) is a normal outcome of trying to tweak a complex object model into XSD. Even if it works, the result will be a bunch of arbitrary XSDs for the same metamodel, since each is a deviation from the standard.
For example, multiple-inheritance is an important feature of object-oriented, and it takes place quietly in BPMN-2.0 metamodel. For example, “Task” is a subclass of “Activity” & “MessageFlowNode” classes. I checked “bpmnxpdl_39.xsd” schema of Dec 30, 2009, by Shapiro, and it does not seem to have this relationship at all. In general, XSD does not support multiple-inheritance, and I’m not sure how XSD would overcome such a problem.
Another issue is related to cross-file linking, which is represented as associations across the packages in BPMN-2.0 metamodel. Without XPointer and XLink, there is no feasible solution; however, using them is very expensive solution in terms of complexity and maintenance.
I think the solution is already delivered by OMG, as XMI representation of metamodel. It’s a standard built upon XML, and more importantly, it’s a native object-oriented solution made to serialize complex metamodels (as BPMN-2.0) in a simple, straight-forward way while reserving all semantics.
You both are well-respected leaders of BPMN community. I would appreciate any feedback as to why you are only focusing on XSD and overlooking the XMI solution. I feel I may be missing something.
Thanks,
Mohamed
Mohamed,
This is a long-debated subject. xmi is part of OMG’s MOF/MDA framework and obviously it has its adherents in OMG. To me it is a “proprietary” format because it doesn’t work in real xml tools. Those tools use xsd, the basis of all other process modeling languages, process execution language, SOA, etc etc. The focus on xmi and inability to produce a proper xsd was one reason (not the only one) that BPDM was thrown out in favor of IBM, Oracle, and SAP’s alternative for BPMN 2.0. This is just my opinion, but you ask. Actually BPMN 2.0 publishes its standard both as xmi and xsd. The subclassing behavior is expressed in xsd as substitutionGroups. It’s not exactly exactly the same way UML does it, but it adequately captures the subclass relationship. The BPMN 2.0 semantic model uses this extensively. XPDL does not, and I don’t think it loses a thing, but that’s also just my opinion. I think the reason Robert and I didn’t mention the xmi version is that in our work, which focuses on BPMN tool interoperability, xmi is irrelevant. That’s an xml/xsd world not a UML/xmi world. If you want to use the xmi variant in your work, you are free to do so.
–Bruce
Thanks Bruce for your feedback.
Let’s agree first that the blueprint of BPMN-2.0 metamodel is the set of UML models/diagrams that come with latest spec. These models define BPMN-2.0 elements, their attributes and the relationships among the elements.
As these models are abstract graphical notations, it does not matter how you represent/serialize them, as long as the representation is correct.
As you said, OMG published two formats; xsd and xmi. My main point is; xsd representation is messed up, it’s not in sync with the metamodel.
According to latest BPMN 2.0 semantic model “Semantic.xsd” by OMG, there no one single multiple-inheritance relationship is represented in that schema. The reason is simple; xsd does not support multiple-inheritance even with substitutionGroup. The more bad news is; many single inheritance/subclassing relationships (in xsd) are incorrect, sorry to state that, but my reference here is the metamodel (UML diagrams), the blueprint.
Again, as Robert pointed out in his presentation about the struggle to come up with a robust xsd for the new spec, I think this struggle will continue for a while until you find another solution, xmi.
Mohamed
Mohamed,
I think this is a pointless argument. The “metamodel” people in OMG would say that the UML is the “real” BPMN 2.0. Most modeling tool vendors and end users would say the xsd is the “real” BPMN 2.0. If you are saying that xsd, what 99% of the world considers THE definition language for xml, is inherently incapable of describing BPMN, I don’t think many people will take you seriously. Your example is that Task in the UML is a subclass of both Activity and MessageFlowNode (i.e. nodes that can send or receive a message), but the xsd substitutionGroup only makes it a subclass of Activity. I think the reason is sharing common child elements and attributes across Activity subclasses. I’m not sure there are any such children or attributes relating to the fact it can send or receive a message. The importance of MessageFlowNode comes in validating a diagram, e.g. are the source and target of message flow legal in the semantic model? You can accomplish such validation easily in xslt, as well as other validation rules that are not described in the UML. So your statement that xsd cannot handle BPMN is not really correct. Better to say that schema validation with xsd does not validate an instance against all of BPMN’s rules, but I doubt that xmi does either.
Sorry Bruce for wasting your time, I thought I have a different point of view.
I’ll stop this argument, however I’ll continue reading your BPM/BPMN blog, as the best source to learn about BPMN.
Thanks,
Mohamed
Mr. Silver, could you please comment on the following two questions:
What is the chance that conformance classes do make it into BPMN 2.0? (25%, 50%, 75%)
If they do make it, would they likely be the ones of Shapiro’s presentation? (Or some mixture of your suggestions and XPDL 2.1?)
This would be very useful to know as a tool developer.
Thanks,
Ebbe