BPMI.org

[Stephen A White]

The ebXML Business Process Technical Committee has proposed some extensions to BPMN.
These extensions are summarized in this document:
http://www.bpmn.org/Documents/ebXML/workitem48-bpmn-summary-to-bpmi-090204.pdf

Please review and send in comments.

[Derek Miers]

Looks like a mess to me ... but then they are looking at maintaining the internal notation that the ebXML group have been using and mashing that up against the BPMN notation sandwiched in between.

So each Role (Buyer-Seller) does some stuff and the process exists somehow between them. The actual process seems to be in the first part while the lower section is the error and cancelation and somehow the processing of an invoice ...

If I was an end-user looking at this I would be totally confused as to what was being presented.

OTOH, a RAD makes a whole lot more sense trying to draw this sort of interaction. But then you probably expect me to say that.

[Rob Bartel]

I'd feel better if I could see what the requirements for the extensions to the notation are, and to whom they are important (process "owner", "modeler", "analyst", "implementer", etc.)

I *think* I extracted these from the concall today and the pdf of the original proposal:

1) Represent the interactions between the parties that change the state of the collaboration. A collaboration is a legal commitment, and a "state" of the collaboration is a situation that has legal significance. In the example these transitions in the state are represented by "transaction" activities. I'm going to refer to these things as "transitions" because they're neither activities nor data. I think Monica had a better word, which I've forgotten.

2) Associate the transition with a set of one or more more messages between the parties. The successful exchange of these messages (in an unrepresented pattern) results in the transition being activitated.

3) Represent the "activatable" transitions at the current state of the collaboration.

4) Represent situations where non-message (or signal) triggered transitions can occur. For instance, timeout, and perhaps Cancel.

I'd sure feel better if someone using the terminlogy of the BPSS world would come up with this sort of list. Thoughts?

[Stephen A White]

Let's take another look at the proposal based on the latest diagram sent in by Jean-Jacques Dubray (http://www.bpmn.org/Samples/ebXML_Business_Process/ebXML%20Example5.jpg).

This diagram looks a lot cleaner and is close to fitting with BPMN as it is now. Some issues with this diagram though:

* Two Message Flows are used to show one Message that is passed between between two Participants. That is one MF goes from a Participant to a Joint Activity and another MF goes from the Joint Activity to another Participant--but this represents only one Message.
* The Pools in the Diagram (mislabeled as Lanes) are intermixed with the Joint Activities. Typically Pools are more segmented, and it should be noted that all the Joint Activities are actually in a Pool, even though the boundaries of the Pool are not shown.
* There are a couple of modeling issues with the diagram that are probably mistakes and we will see if we can get another version of the diagram.
* It is also possible that the different Pools could have activities within them. In this case, the activities would be the sources or targets of the MF