Re: "Message" semantics and composition -- WAS Grounding Choreographies (the atoms)

Andrew Berry wrote:

>
>>
>> I am less in agreement on this point. While I perfectly understand 
>> the premise and agree with it from one specific perspective, it is 
>> not clear why there would be a constrast since causality can both 
>> occur inside a locality, and can depend on things that may be true 
>> regardless of autonomy or locality.
>>
>> For example, if we know that a service receives X and replies with Y, 
>> as a requestor of that service, without violating my autonomy and 
>> regardless of my location, if I send X I expect to receive Y. I am 
>> fully autonomous in every respect, and my locality can change, but 
>> that causality is something I expect to happen, hence define an 
>> interaction around it.
>
>
> The fact that the service user explicitly identifies a single service 
> as receiving the X and replying with the Y restricts your options with 
> respect to composition.  

That's a separate issue. I don't think anyone here is interested in 
defining choreographies in terms of specific services, which indeed 
hinders reuse. On the other hand, we are talking about a choreography 
between services. Even though you write it using generics (e.g. WSDL 
interfaces) so it can be reused, what eventually transpires is a 
choreography between two services. As far as discussion goes it's much 
more fruitful to talk in terms of services interacting.

> Extending your example, let us say that 'X' is a request for a flight, 
> car, and accomodation and the 'Y' response is booking references for 
> each of them.  Distinguishing between the local behaviour (requesting 
> X and receiving Y) and the way it is bound to one or more service 
> providers allows us to satisfy the request for X using a choreography 
> involving distinct airline, car hire and accomodation providers 
> without changing the behaviour of the requestor.  We only have to 
> change the way that behaviour is bound to one or more providers.
>
> In other words, local behaviour defines your service expectations, and 
> the interaction behaviour defines how those expectations are met by a 
> particular choreography of service providers.  Note that the service 
> providers themselves have a similar view of the interactions, meaning 
> they are also able to participate in different choreographies.  For 
> example, it would be possible for the airline identified above to sell 
> airline tickets with an adventure holiday package using the same 
> service interface as that used above. 

My expectation from a service is based on what eventually the service 
would do. I would write it in terms of the service interface so I can 
use any number of services, e.g. one or more airlines. But I always 
write what I expect some airline (= some service) to do, hence that is 
part of the causality.


What you said in the previous e-mail is consistent with the mobile 
process calculus model which does indeed deal with autonomy and locality 
(or mobility as it happens) and one of the obvious benefits is reuse and 
composition, just as you suggest in this e-mail.

But that model does also point out to the fact that causality does 
extend across two or more interacting processes, since by defining their 
interactions you are extending the casuality model across the chain of 
interactions.

arkin

>
>
> Ciao,
>
> AndyB
>
>>
>> arkin
>


-- 
"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, 22 July 2003 16:08:24 UTC