RE: requirements summary

 
I am sorry, I didn't mean to say choreography needs to "explicitly support" the two styles. 
 
I was only pointing out that the choreography specification should allow (perhaps a better wording can be - should not prohibit) the use of the two patterns, one of which is A "explicitly polling" B.

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: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Tuesday, March 25, 2003 10:39 AM
To: Patil, Sanjaykumar; Burdett, David; Jean-Jacques Dubray; Ricky Ho; jdart@tibco.com; Daniel_Austin@grainger.com
Cc: public-ws-chor@w3.org
Subject: RE: requirements summary


Sanjay, you said ...
 
>>> 
  a> A explicitly polls B for the outcome of the interaction between B and C, and  
  b> A prefers to receive any exceptions (or positive responses) from B in an asynchronous manner.
<<<
 
I'm not sure that these need *explicit support* in a choreography spec as they are just two examples of choreography design patterns that could be included in a "good practice" guide. Specifically:
1. The "Request Response Design Pattern" states that for every message sent there ashould always be a response message that, indicates if the message was not processed correctly.
2. The "Status Request Design Pattern" states that the sender of a message can always start a new "conversation" that inquires on the status of processing of an earlier message.
 
It is then up to choreography designers to use, none, one or the both of these principles in the design of their choreography.
 
Thoughts?
 
David
 

-----Original Message-----
From: Patil, Sanjaykumar [mailto:sanjay.patil@iona.com]
Sent: Tuesday, March 25, 2003 10:28 AM
To: Burdett, David; Jean-Jacques Dubray; Ricky Ho; jdart@tibco.com; Daniel_Austin@grainger.com
Cc: public-ws-chor@w3.org
Subject: RE: requirements summary


Agree. If there is a global significance to conveying of the outcome of the interaction between B and C to A, then this should be part of the overall choreography definition.
 
Further more, I guess the choreography spec should allow both the styles of interactions, that is,  
  a> A explicitly polls B for the outcome of the interaction between B and C, and  
  b> A prefers to receive any exceptions (or positive responses) from B in an asynchronous manner.
 

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: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Tuesday, March 25, 2003 10:06 AM
To: 'Jean-Jacques Dubray'; Burdett, David; 'Ricky Ho'; jdart@tibco.com; Daniel_Austin@grainger.com
Cc: public-ws-chor@w3.org
Subject: RE: requirements summary


Jean-Jaques
 
I think the problem you mention is solved as long as you assume that error/fault messages are included in the choreogrpahy. For example, if Party B can reply to A with either: a "normal" (ie. non-error) message, OR an error/fault message; then if C sends a fault to B, then B can send a fault to A. The two interactions are decoupled.
 
Another alternative to sending a fault message is to allow A to inquire on  the state of B.  If B has failed then A will discover this from B's response.
 
I think that a choreography that does not include appropriate methods of allowing one party to discover the state of another choreography will normally be a badly designed choreography ;). The only exception that I can think of is a choreography that involves a one-way "fire and forget" message where the sender does not care what happened to it - but then one message is hardly a choreography!
 
Thoughts?
 
David

-----Original Message-----
From: Jean-Jacques Dubray [mailto:jjd@eigner.com]
Sent: Tuesday, March 25, 2003 9:26 AM
To: 'Burdett, David'; 'Jean-Jacques Dubray'; 'Ricky Ho'; jdart@tibco.com; Daniel_Austin@grainger.com
Cc: public-ws-chor@w3.org
Subject: RE: requirements summary



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.

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. 

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