Re: requirements summary

See inline.

Monica

Jean-Jacques Dubray wrote:

> David:
>
> thanks,
>
> At the run-time engine level, things gets far more complicated because
>
> unless there is a party that touches all the "bilateral
> choreographies",
> it is impossible without special run-time to "monitor" the multi-party
>
> choreography. So the question arise, is the goal of a multi-party
> choreography specification to allow configuration of run-time engines?
>
> <DB>It depends what you mean by "Monitor". Each party can monitor
> their own behavior and the behaviors of the other roles with which
> they interact. If one of the parties discovers that some other party
> is not behaving properly, then they can raise errors with that
> party.</DB>
>
> [JJ] Let’s take a more concrete example, such as the propagation of
> exceptions, if a failure happens (e.g. an operation returned a fault),
> to between party B and C. How do we notify party A? Are we expecting
> choreography designers to explicitly define the corresponding message
> exchange between B and A should this happen? Or are we expecting a
> more generic mechanism by which A can be notified of the corresponding
> “state” of the choreography. This could be implemented by the run-time
> infrastructure. Of course that complicates quite a bit this
> implementation.
>
> mm1: I think this gets into various levels of visibility and control.
> Does this infer a management function (gateway, proxy, etc)?
>
>
>
>
> In think in the light of this, we should not conclude that binary is a
>
> special case of multi-party. They may well have both distinct features
>
> (control flow?) and applications.
> <DB>I'm not sure there is difference, but let's keep exploring ;)
> </DB>
>
> [JJ] This is more a question ;-) than an assertion.
>
> I am also wondering if the group wants to keep as a requirement that
> says that in the choreography specification there is no distinction
> between the choreography involving "internal" services as opposed to
> external services. A separate layer of the specification should allow
> for annotating that this particular message exchange is external and
> may
> have more qualifiers. However, at the pure choreography specification
> level, the choreographies should not be distinguished.
> <DB>Am I right in assuming that by "internal" you mean within a
> "domain of control", e.g. a business, and that "External" means
> between domains of control, e.g. between businesses. If so then
> although, in theory, they can be expressed in the same way, there are
> significant *practical* differences:
>
> 1. External choreographies, between domains of control, will be used
> by MULTIPLE (perhaps millions) of different parties and therefore the
> definition MUST be abstract to avoid multiple definitions of
> essentially the same choreography.
>
> 2. For Internal choreographies, within a domain of control, there is
> only ONE implementation and therefore the definition can be very
> concrete and does not need to be abstract at all.
>
> [JJ] I agree that this is generally true but large companies might
> also want to benefit from this abstraction. We have customers that
> have 30 ERP implementations, I also often talk about this large A&D
> company that has 84 procurement systems.
>
> mm1:  We can see that a choreography can have inputs/outputs - some
> known, others not.  Let's also consider that within a choreography,
> the sequence, inputs/outputs, exceptions or less traveled paths are
> known.  Also let's consider that the choreography may receive inputs
> 'external' to its sequence (not a pre- or post-condition).  How is
> that handled?
>
>
>
> JJ-
>
> >>-----Original Message-----
> >>From: public-ws-chor-request@w3.org
> [mailto:public-ws-chor-request@w3.org]
> >>On Behalf Of Ricky Ho
> >>Sent: Monday, March 24, 2003 7:06 PM
> >>To: jdart@tibco.com; Daniel_Austin@grainger.com
> >>Cc: public-ws-chor@w3.org
> >>Subject: Re: requirements summary
> >>
> >>
> >>I was originally thinking that a multi-party choreography can always
>
> be
> >>broken down into multiple "inter-dependent" bi-party choreography.
> But I
> >>am convinced that this is NOT always possible.
> >>
> >>See
> http://lists.w3.org/Archives/Public/public-ws-chor/2003Mar/0052.html
> >>
> >>So I think bi-party choreography is a special case of multi-party
> >>choreography.  Bi-party choreography has some interesting properties
>
> that
> >>can simplify the modeling.  (e.g. Bi-Party choreography doesn't need
>
> to
> >>worry about dynamic participation because any change of a binding
> can
> >>simply terminate the choreography).
> >>
> >>I think we should covered multi-party choreography.  In additional,
> we
> may
> >>also need to investigate this special subset called bi-party
> choreography.
> >>
> >>Best regards,
> >>Ricky
> >>
> >>At 02:28 PM 3/24/2003 -0800, Jon Dart wrote:
> >>
> >>>Daniel_Austin@grainger.com wrote:
> >>>>2. Multi-party vs. bilateral choreography: there is some
> skepticism
> >>>>that modelling bilateral interactions is sufficient.
> >>>>       I certainly don't think that is it sufficient to model only
>
> >>bilateral
> >>>>transactions. Many business transactions have multiple actors, and
>
> we
> >>want
> >>>>to build standards that will work for common service transaction
> models.
> >>>
> >>>Note that it is not exactly all or nothing here. BPSS for example
> >>supports
> >>>"MultiParty Collaborations", but does so by composing them out of
> "Binary
> >>>Collaborations".
> >>>
> >>>--Jon
> >>>
> >>>
>