Re: ebBP / BPMN extensions

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

> 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).
>
mm1: 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?
    * 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.
    * Where you have the Cancel PO that goes back into a Decision point,
      where does it exit the collaboration?
    * Can you explain the dotted (non-arrowed) line going both ways out
      of Cancel PO?
    * I don't see an invoke on the Process Invoice from the Seller. Is
      that needed?
    * 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?
    * Would not other acknowledgments be involved? Isn't this important
      to the effective use of patterns?
    * On the fork-gateway you briefly describe, how could/does this
      affect our schema or technical specification if at all?

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.

[1] See ebBP Meeting notes that I will post today.

>  
>
>  
>
>  
>
> 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)
>
>  
>
> 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.
>
>  
>
> Optionally, we can represent the message flow ( PO / Ack PO).
>
>  
>
> The little circle on each side of the BTA represent an endpoint. The 
> private process connects to these end points (not fully represented 
> here).
>
>  
>
> 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.
>
>  
>
> Thanks,
>
>  
>
> JJ-
>
>  
>
>  
>