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

Andrew Berry wrote:

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

I actualy think we're talking about the same thing from the same 
viewpoint ;-)


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

Which is precisely my point. Or at least what I think I was arguing for, 
which is modeling activities that are local (send/receive), and looking 
at the relationship which is a non-local causal one (send@X precedes 
receive@Y). So the causality relationship is across all interacting 
systems, but each interacting system is modeled as an autonomous system.

I was agreeing with everything you said in the original e-mail, only 
trying to point out that the causality relationship spans the different 
localities. If the specification implies that send@X -> receive@Y, then 
that's exactly what it does.

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

Multi-party interaction is the desired outcome. But bi-party is also a 
form of multi-party, where n=2. I wasn't trying to restrict the example 
to just two parties, I just used two parties for a specific example. The 
model we are talking about - and I'm pretty sure we're talking about 
exactly the same thing - extends well from 2 to any arbitrary number of 
parties.

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

Following the discussion so far, I think you got all the points 
correctly. There's a published list of resources, specifically 
pi-calculus, somewhere in the archive. SRT can probably point you to 
that list. To summarize the important points:

1. You express the behavior of each autonomous entity (e.g. the 
traveller, or the airline)
2. The behavior is expressed in terms of activities you would perform 
around messages (e.g. send requestX, receive response Y, ...)
3. By virtual of using the same channel/port/name you implicitly express 
causality across localities (send request@X->receive request@Y)
4. While pi-calculus calls it a port, it does not need to represent an 
actual service address but can be an abstract service type (e.g. airline 
not united, car rental not avis)
5. The combination of these autonomous processes is a process in itself 
(the choreography) but they can be combined into any number of 
choreographies (reuse)

Mobility is the fact that a process can reside at any location and you 
don't need to know the location upfront. So you can express an 
interaction with some process representing an airline. It can be a 
different airline at different times. To get the stuff to work you need 
to pick some airline and interact with it, but you don't need to write a 
choreography for the specific airline.

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

+1

As a side point, my presentation during the F2F meeting was all about 
causality. I think this is what we should focus about in a choreography 
language, and if we pick an adequate model for expressing the 
cause/effect relationship that is abstracted from the messaging 
technology, combined with WSDL which allows us to abstract and then 
combine messaging/endpoints, we would end up with a powerful solution.

arkin

>
> Ciao,
>
> AndyB



--

Received on Wednesday, 23 July 2003 12:17:26 UTC