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

Arkin,

I think we are talking about similar things but from different 
viewpoints.  Let me try to clarify.

Getting back to the original reason for this thread, a message has at 
least two viewpoints (sender and receiver) and they differ because the 
viewpoints are phyically distributed and autonomous.  Modelling a 
message as an atomic entity is therefore misleading, somewhat complex 
and potentially incorrect.  This was my primary reason for suggesting 
caution and also suggesting an alternative: modelling all interactions 
as local behaviour (e.g. send@X, receive@Y) with causal relationship 
specifications used to imply messaging (e.g. send@X -> receive@Y).

Regarding the specific discussion we've been having:

On Wednesday, July 23, 2003, at 06:07  AM, Assaf Arkin wrote:
> 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.

It was my understanding that multi-party interaction was one of the 
desired outcomes of this work, so please correct me if I have 
misinterpreted.  The approach I'm suggesting is a single choreography 
between one or more service providers and a service consumer.  If the 
service consumer requires that the request be satisfied by a single 
service provider (which is my interpretation of "between two services" 
above), then you effectively force the service consumer and providers 
to change their "published" behaviour to interact with a multi-party 
choreography, even though their actual behaviour is unchanged.  I don't 
think this is what you meant so I would appreciate further 
clarification of your intent.

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

Again, my intent is that you don't ask for an "airline" service 
specifically, but a "flight+car+accomodation" interaction and this is 
provided through a choreography of one or more service providers.  The 
consumer's behaviour remains constant regardless of the choreography 
used to realise the desired result.

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

It's quite some time since I looked at the mobile process calculus and 
I should probably brush up.  Can you suggest some relevant reading 
material?

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

This is exactly the point: in a multi-party choreography, you do not 
need to explicitly specify or implement direct interactions (messages) 
between parties, rather, you can deterministically imply those 
interactions through a specification of cause/effect relationships 
between visible local behaviours.  By using specification of 
cause/effect relationships, you capture the more abstract 
business-level interactions without constraining how they are realised 
(i.e. you can use any messaging technology you like).  There are a 
number of examples of this in my thesis and papers.  In particular, 
chapter 8 section 8.3 of the thesis has a purchase order "binding" 
(binding == choreography to a large extent) describing a purchasing 
interaction involving a purchaser, supplier, bank and freight provider.

Ciao,

AndyB

Received on Wednesday, 23 July 2003 10:34:43 UTC