ebBP 8/24/2004: BPMN Comments on Extensions

["Monica J. Martin" <Monica.Martin@Sun.COM>]

JJ and I carried on quite a conversation about the BPMN extensions that 
I believe could be valuable in inputs to the BPMN v2.0 team. I provided 
them here as a followup to the initial comments I posted this morning 
and integrated Dale's questions to JJ (see JJ for a few more). Again, 
team, waiting for your comments. Regards.

Initial posting and graphic found at:  
http://www.oasis-open.org/archives/ebxml-bp/200408/msg00038.html
My original posting at: 
http://www.oasis-open.org/archives/ebxml-bp/200408/msg00042.html
Dale's initial comments: 
http://www.oasis-open.org/archives/ebxml-bp/200408/msg00041.html
=======================================================================================================
Dubray: This is my proposal for a few extensions to BPMN to be able to 
represent the choreography of collaborations. Here is an example 
(Process PO collaboration).

|JJ, as the team briefly discussed yesterday, this is a good start. 
Layna Fischer indicated we could well provide comment into BPMN v2.0
|(the board meetings the first week in September) [1]. I have a few 
questions in reviewing the extensions:

|* I discern that the Process PO, Change PO, etc. are the shared 
business collaboration view, correct?

Dubray: Yes, I also wanted to show that we could show (~connect) a 
private process to the notation if needed, hence these little green 
circle at the interface. Normally nothing will be displayed behind it if 
we just want to show either the collaboration view or the private view.
Moberg: It seems to me that BPMN could effectively merge a BPSS with a 
BPEL (or a choregraphy with an orchestration) because it can cover both 
aspects. Might this not be a way to connect BPSS or WS-CDL with BPEL for 
the purposes of a unified display? That way the XML instances could 
still be used separately for different tasks, and we wouldn't have to 
worry about how to annotate BPSS with BPEL bits to cover orchestration?

I  also need to find a good pointer back to a summary on the BPMN 
graphical constructs because some ot the arrows seem funny..
mm2: See:
http://www.bpmi.org/bpmn-spec.esp (the specification v1.0)
http://www.ebpml.org/bpmn.htm (JJ's evaluation)
http://itresearch.forbes.com/detail/RES/1062607177_776.html (Introduction)

|* In this view the Buyer and Seller are effectively where the BSI would 
occur? Is the BSI 'managing the invocations' through our Operations 
Mapping (trying to |think how this affects the BSI)? You show this as 
the private process.

Dubray: I am not clear yet on how to represent the mapping, originally, 
I just wanted to show that you can connect a private process to the
collaboration, with a continuity in using BPMN. For me the mapping it 
more an under the cover thing. The BTA is happening (and represented as
such) regardless of whether it was achieved via operation mapping or not.
mm2: Is it important to recognize the BSI explicitly though?
Dubray2: Why would the BSI show up on the collaboration notation? The 
idea is really to not show the Invoke / Send /Receive at all. I just 
wanted to
show that I was trying to find a notation compatible with the existing 
notation. Because we chose a mapping instead of an operation activity, 
now everything looks like a BTA. Am I missing something?
mm3: No, just asking about layers of granularity visible in the notation 
example.

|* Where you have the Cancel PO that goes back into a Decision point, 
where does it exit the collaboration?

Dubray: Through the time out. It is not actually a decision point but a 
new kind of gateway which is both a fork and a join to enable any number of
cancel / change until the timeout occurs.
mm2: Should the timeout be explicit?
Dubray: What do you mean? Show the timeout value on the notation? I 
think BPMN does it. Again, this is just a starting point. The real work 
is to take
BPMN entirely and define how each concept applies to the collaboration 
notation.

|* Can you explain the dotted (non-arrowed) line going both ways out of 
Cancel PO?

Dubray: When one line cross the BTA, it says that this can only be used 
in one direction. When the BTA is crossed by 2 lines going in opposite 
direction, it means
that the BTA can be initiated by either party.
mm2: The line goes through the Cancel PO but doesn't have an arrow 
either way. Maybe I am a bit confused (although I see other lines with
arrows related to Cancel PO).
Dubray2: Yes, there is a step because of graphical constraint. I just 
meant to draw two opposite arrows.
mm3: Suggest a clarification.
Moberg: Are the arrow heads just links or do they indicate flow or both?

|* I don't see an invoke on the Process Invoice from the Seller. Is 
|that needed?

Dubray: Yes, as I said, I did not mean to write a complete private 
process just yet. In general nothing will be there, everything will stop 
at the endpoint (little green circles at the interface).

|* I believe the pseudo clock indicates that the Change PO can only 
occur up to specific points before it cannot impact timing of the actual 
invoice (thinking about |real-world operations). Am I |reading this 
accurately? Is this how we would show a constraint?

Dubray: Yes, this is a timeout.
mm2: See previous question if this should be explicit.
Dubray2: Yes, if this is what BPMN does (I think it does).
Moberg: Is the clock a timer, indicates a possible delay, or ??
 
|* Would not other acknowledgments be involved? Isn't this important to 
the effective use of patterns?

Dubray: The picture does not represent any pattern (or signal). If this 
is important we could add a symbol within the double line box that
represent a BTA to specify what pattern is being used.
mm2: I think we should. I suggest we get this to the list for comments 
so we can solidify our formal / informal comment back to BPMN for v2.0
or beyond.

|* On the fork-gateway you briefly describe, how could/does this affect 
our schema or technical specification if at all?

Dubray: Yes, we will need a bit of change. I think we already went the 
route of the gateway, this is just a new type of gateway, but I think a 
very important type that does not exist for private processes.

|As I indicated first impressions were positive and we have an  
opportunity to comment back to BPMN through Stephen White and/or Layna  
Fischer to continue |our efforts. I've slated this for discussion 30  
August 2004. I encourage others to comment, please. Thank you.
Dubray: Great !!

[1] See ebBP Meeting notes posted today: 
http://www.oasis-open.org/archives/ebxml-bp/200408/msg00044.html

Dubray original notes:
1. The double line activity represent a business transaction (we may 
want to use special symbols or lining scheme for indicating the need for 
or lack of signals)
2. The dashed line represent the direction (initiating to responder), 
the response flow is not indicating. When two flows cross the activity 
(e.g. Cancel) it means that both parties can initiate that transaction.
3. Optionally, we can represent the message flow ( PO / Ack PO).
4. The little circle on each side of the BTA represent an endpoint. The 
private process connects to these end points (not fully represented here).
5. I had to create a new gateway which acts as both a fork and a join. 
This means that change PO and Cancel PO can happen as many times as we 
need to, until a time out occurs. Note that the semantic of a fork 
gateway in a collaboration means that the BTA is enabled, not that it is 
necessarily executed.

It is start is agreeable, I will do a complete analysis of what maps and 
does not map to a collaboration.