Re: General Choreography and Bi-lateral Choreography

One comment inline.

Thanks.
Monica J. Martin
Sun Microsystems

"Furniss, Peter" wrote:

>      I agree with everything you say.  However, I want to
>      elaborate my view on multi-party choreography.
>
>      Most real life B2B scenario are multi-party interaction.
>      But "multi-party interaction" is NOT equivalent to
>      "multi-party choreography".  For example, a company (or
>      "domain of control") can have an orchestration that span
>      multiple "bi-lateral" choreographies.  In other words,
>      "multi-party interaction" can be realized by multiple
>      "bi-lateral" choreographies linked together by
>      orchestration.  The only thing lost is the sequence
>      dependencies between message exchanges within choreographies
>      is NOT captured externally.
>
>      I honestly don't think bi-lateral choreography is sufficient
>      to capture arbitrary public protocol sequence.  For example,
>      the well-known 2-phase commit protocol cannot be specified
>      using bi-lateral choreography.  So I agree with you that in
>      a generic sense "choreography" should NOT be restricted to 2
>      parties.
>      prf: on the 2-phase commit comment: I'm not sure if you mean
>      *bi-lateral" isn't sufficient, or "choreography" isn't
>      sufficient. As I said before, I think treating 2-pc as an
>      example "application protocol" - i.e. the subject for a
>      choreography description - can be very instructive.2-pc can
>      certainly be defined, precisely and fully, involving only
>      two parties. This was done in the OSI Commitment,
>      Concurrency Recovery (CCR) spec [ in fact, because standards
>      politics meant it wasn't allowed to have normative
>      multi-party text, but also was required to have normative
>      semantic definition], and is also (I hope) complete in the
>      BTP specification of the "outcome" protocol (the
>      superior:inferior bit). There are implications for what is
>      going on with other parts of the transaction tree, but the
>      fundamental protocol is in fact two-party. (my diagram with
>      the 3 dumbells and the box, on about my 4th slide was meant
>      to show this, but I fear may not have explained it well] (I
>      mention CCR and BTP because I know them - there may be other
>      specs of similar nature)What you do need, beyond the simple
>      message exchange rules, are statements of the implied
>      semantics of the messages. This is most certainly part of
>      the contract definition between the parties, and we strongly
>      believe any useful choreography specification needs to have
>      ways of stating the contractual implications (at least the
>      software-contractual implications) of the messages.
>      <mm> The use of a 2-phased commit, using the BTP work, is an
>      implementation decision.  At the definition or design level,
>      the criteria will be driven by business rules that specify
>      what paths (expected or less traveled) occur and to show the
>      criteria to move through those paths.
>

Received on Monday, 17 March 2003 11:32:11 UTC