RE: requirements summary

Jean Jacques

See comments inline.

David

-----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). 
<DB>I think that this is the best approach to follow otherwise you need to
define a set of separate bilateral agreements where it will be harder to
ensure their consistency.</DB>

Is there a need to establish multi-party agreements based on a
multi-party choreography definition? 
<DB>I don't think so. As long as a party knows the role they are playing,
they only need agreements with the other parties they interact with.</DB>

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>

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>

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.
</DB>

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
>>>
>>>