Re: requirements summary

Jean-Jacques Dubray wrote:

>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 mobile process model you express a multi-party choreography but 
clearly define the processes that constrain each party's involvement in 
that choreography. That information can (and in our case is) used to 
monitor the choreography along the firewall concept. By knowing what 
messages are possible at any given state you can enforce policies on 
both send and received messages.

A two-party choreography is simply a case where there are only two such 
processes (one per party). The processes are not identical: when one 
party monitors the sending of a message (e.g. so it can resend/batch it 
or determine latency or actualy QoS), the other process monitors the 
receiving of the same message (e.g. to apply a security policy, QoS 
policy, queuing, etc).

Interestingly, for the two-party case, this model works the same whether 
you start with a language like WSCI/BPEL, or with a language like BPSS.


>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? 
>
Is it possible to establish a multi-party agreement?

In some cases the answer is a no, or yes with very low probability. And 
I'm sure we're all aware of these cases and would consider the viability 
of a two-party choreography for addressing these cases.

In other cases the answer is a yes. There are very valid cases for B2B 
where the parties can negotiate such choreographies with ease. These B2B 
scenarios are not common in consortia based specifications, but we see a 
lot of companies that have relations with their customers/suppliers that 
allow them to explore such scenarios And of course it becomes much 
easier if the services are all bound to some organication but cross 
organization boundaries or systems, where a choreography language is 
required but achieving agreement is a non-issue.

In fact, what is interesting about these cases is that one doesn't even 
bother to try and achieve agreement. There is a certain way in which the 
business works and has probably been operating like that for years - all 
that one has to do is describe how things actually work in real life. So 
the need to agree in many cases is a non-issue. We also have to look at 
this perspsective.


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

Does the patient need to monitor the interaction between the 
receptionist and the doctor, or only the interaction between the patient 
and the receptionist? Does the receptionist need to monito the 
interaction between the patient and the doctor?

But does the receptionist need to understand the relation between its 
interaction with the patient and with the doctor and perform them in the 
right order, passing the doctor's reference to the patient (and vice 
versa)? This is where I see the value in expressing the multi-party 
choreography.

It's not about monitoring everything that goes around the world, only 
monitoring what interactions you are engaged in, but monitoring 
interactions with different participants that have a causal relationship 
to each other.

>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 agree. I haven't seen any difference between n-party and n-party where 
n=2 in terms of language or model, but I concur that we need to sit down 
and consider that such a difference may exist before reaching a conclusion.

>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.
>
+1

External or internal is a matter of observer, that much is obvious. You 
can't just say something is external or internal. However, you may want 
to express what an observer is and what is in scope for that observer. I 
don't know if this is interesting to do right now, or maybe it's just as 
simple as using namespaces, or maybe namespaces bring more issues. My 
personal opinion is that we should leave this open for right now, but we 
should consider that such a layer should exist and the choreography 
should support such a layer when it is introduced.

arkin

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


-- 
"Those who can, do; those who can't, make screenshots"

----------------------------------------------------------------------
Assaf Arkin                                          arkin@intalio.com
Intalio Inc.                                           www.intalio.com
The Business Process Management Company                 (650) 577 4700


This message is intended only for the use of the Addressee and
may contain information that is PRIVILEGED and CONFIDENTIAL.
If you are not the intended recipient, dissemination of this
communication is prohibited. If you have received this communication
in error, please erase all copies of the message and its attachments
and notify us immediately.

Received on Tuesday, 25 March 2003 15:24:33 UTC