RE: requirements summary

I tend to disagree with the central infrastructure argument. It is
expected that each role that would be involved in the choreography
(whether belonging to the same domain of control or not) would have to
maintain do level state (i.e. choreography instance state). The
corresponding layer can communicate with other corresponding layers
implemented by other role. Overall, the system would be completely
distributed. I agree that it may not be the most efficient but if you
have nothing in the middle as it is often the case in b2b scenario,
there is little else you can do.

I don't mean to launch a big discussion at this point, I am more looking
for whether this is/is not a requirement. I don't have a strong opinion
either with respect to whether or not this is in scope. I tend to think
that this can be helpful for avoid dead-locks.

JJ- 
 
 

>>-----Original Message-----
>>From: Patil, Sanjaykumar [mailto:sanjay.patil@iona.com]
>>Sent: Tuesday, March 25, 2003 1:15 PM
>>To: Jean-Jacques Dubray; Ricky Ho; jdart@tibco.com;
>>Daniel_Austin@grainger.com
>>Cc: public-ws-chor@w3.org
>>Subject: RE: requirements summary
>>
>>
>>A multi-party choreography definition will most likely also include
>>information above and beyond the set of binary collaborations. For
example,
>>a multi-party definition will also include the temporal and logical
>>conditions which decide the valid order of the binary collaborations.
I
>>guess, Ricky's patient-doctor-receptionist scenario clearly points out
>>such a need.
>>
>>However, I am not sure whether a multi-party choreography definition
is
>>also pivotal to enabling central monitoring of the overall
choreography.
>>Let us consider the following two scenarios (based on whether the
>>participants belong to the same or different domains of control):
>>
>>a> When the participants belong to different domains of control: Each
>>participant in this case would execute its share of the binary
>>collaborations as well as its share of ensuring the overall order of
the
>>binary collaborations. Note that, in this scenario, there is perhaps
no
>>need as such to monitor the overall choreography, besides each side
>>monitoring its own compliance in meeting its obligations.
>>
>>b> When the participants belong to the same domain of control: In this
>>case, a need for central monitoring may sound a bit more obvious. Now
>>there is a choice of the governance of the participants, that is, each
>>participant can either be autonomous (just like the above scenario of
>>different domains of control) or is governed by a central authority
>>(runtime engine). Based on the choice (perhaps an implementation
decision),
>>the infrastructure for monitoring would differ. However, I don't see
how a
>>particular specification of the choreography definition will improve
or
>>reduce the ability to monitor the overall choreography.
>>
>>
>>Sanjay Patil
>>Distinguished Engineer
>>sanjay.patil@iona.com
>>-------------------------------------------------------
>>IONA Technologies
>>2350 Mission College Blvd. Suite 650
>>Santa Clara, CA 95054
>>Tel: (408) 350 9619
>>Fax: (408) 350 9501
>>-------------------------------------------------------
>>Making Software Work Together TM
>>
>>
>>-----Original Message-----
>>From: Jean-Jacques Dubray [mailto:jjd@eigner.com]
>>Sent: Tuesday, March 25, 2003 7:30 AM
>>To: 'Ricky Ho'; jdart@tibco.com; Daniel_Austin@grainger.com
>>Cc: public-ws-chor@w3.org
>>Subject: RE: requirements summary
>>
>>
>>
>>Ricky:
>>
>>It is also interesting to introduce the perspective of why a
multi-party
>>can be used for?
>>
>>Both a multi-party and binary can be used to represent what is going
to
>>happen (see Assaf's presentation on causality).
>>
>>A binary collaboration can easily be used as part of an agreement, as
>>well as to configure run-time engine that "monitor" the choreography
>>(firewall concept).
>>
>>In the case of a multi-party, we might want to ask whether the goal is
>>simply to represent what is going to happen such that each party can
>>infer what they need to do. Hence decompose the multi-party into
>>bilateral behavior (which will itself be decomposed in unilateral
>>behavior).
>>
>>Is there a need to establish multi-party agreements based on a
>>multi-party choreography definition?
>>
>>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?
>>
>>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.
>>
>>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.
>>
>>Cheers,
>>
>>Jean-Jacques
>>
>>
>>
>>>>-----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
>>>>>
>>>>>
>>

Received on Tuesday, 25 March 2003 13:41:24 UTC