W3C home > Mailing lists > Public > public-ws-chor@w3.org > July 2003

RE: "Message" semantics and composition -- WAS Grounding Choreogr aphies (the atoms)

From: Cummins, Fred A <fred.cummins@eds.com>
Date: Tue, 22 Jul 2003 14:01:33 -0500
Message-ID: <1A254DC4B97D8C4CB4A5611CF8058F5F0148BCF4@USPLM214>
To: Andrew Berry <andyb@whyanbeel.net>, Assaf Arkin <arkin@intalio.com>
Cc: Francis McCabe <fgm@fla.fujitsu.com>, public-ws-chor@w3.org

Andrew, Assaf,

I think it would be useful to put this discussion into the context of more
explicit exchange stack.  In a middleware architecture I proposed at the
Object Managment Group, I defined the following layers for an exchange and
for the middleware that would support the exchange: transport, (reliable)
messaging, packaging and process.  They are discussed further, below.  The
primary goal of this architecture was to define interfaces between
applications and web services middleware, but the stack applies here as
well.  A draft white paper is available at
http://www.omg.org/cgi-bin/doc?bei/02-10-02 .

There is a protocol such as http that defines the exchange at the transport
layer.  There is a reliable messaging protocol at the messaging layer.
There is a message composition/decomposition protocol (e.g., SOAP) at the
packaging layer, and there is a need for a choreography at the process
layer.

This stack was defined to separate these layers so that a participant could
quickly bind to the appropriate implementations of each layer for a
particular exchange, dependent on the protocol requirements of the other
party.  This allows applications to be independent of both the details of
the protocols and changes in protocol standards.

The stack would also allow the messaging and transport layers to be replaced
with a message-oriented middleware layer (e.g., a Java Messaging Service
implementation) and the other layers would be unaffected.

This stack supports the concept of separate specifications of the reliable
messaging protocol (choreograpy?), and the business message exchange
choreography.  I suppose that interfaces might be specified with WSDL at
both levels.  There might be different MEP choreographies, but certainly
relatively few compared to the business message exchange choreographies.

Fred

Additional discussion of the levels follows:

Transport 
The transport function encapsulates the protocols for exchange of
lower-level messages over the communications media.  The goal is to provide
APIs for messaging, security and system management that are consistent for
different transport protocols.

A transport component would establish a connection with the remote
participant, if appropriate to the protocol, and might provide a secure
channel, such as SSL (Secure Socket Layer).  

Messaging
The messaging component would be responsible for the exchange of content and
control messages through the transport component as required to achieve the
appropriate quality of service for delivery or receipt of application
messages.  

The messaging function might also incorporate message-oriented middleware to
accomplish the messaging.  This would allow an application to use web
services technology or message-oriented middleware interchangeably, as
appropriate to the remote participant engaged.

Packaging
A packaging function would be responsible for assembling and disassembling
messages so as to insulate the application from variations in message
structure specifications.  The packaging function would ensure compliance
with appropriate message structure standards such as SOAP.

For example, message may consist of multiple documents with multiple
signatures.  A signature may apply to one or more of the associated
documents.  
The message may also have encrypted components, and it may contain security
tokens that contain security assertions regarding one or more participants
in the collaboration.  

Process 
The process function insulates the application from the details of the
exchange of messages to implement an application transaction.  

The process component may perform a variety of processes designed to
implement the choreography of the exchange and support the operations to be
performed by the application.  If a message received is incorrect or
inconsistent with the current state of the exchange, the process should be
designed to take corrective action or terminate the exchange. 

> -----Original Message-----
> From: Andrew Berry [mailto:andyb@whyanbeel.net]
> Sent: Tuesday, July 22, 2003 10:08 AM
> To: Assaf Arkin
> Cc: Francis McCabe; public-ws-chor@w3.org
> Subject: Re: "Message" semantics and composition -- WAS Grounding
> Choreographies (the atoms)
> 
> 
> 
> 
> On Tuesday, July 22, 2003, at 05:57  AM, Assaf Arkin wrote:
> > Andrew Berry wrote:
> >
> >>
> >> This approach has many advantages.  In particular, when 
> speaking of a 
> >> set of autonomous participants in a choreography, the behaviour of 
> >> each participant will be based entirely on what they are able to 
> >> observe from their locality.  This protects their interests and 
> >> ensures their autonomy.  The choreography should respect their 
> >> autonomy and explicitly specify the behaviour of 
> participants based 
> >> on what they are able to observe locally.  The causal 
> relationships 
> >> defined by the choreography then specify the expectations of other 
> >> participants resulting from local behaviour of a participant.
> >
> > +1
> >
> >> Explicitly separating the local behaviour from causal 
> relationships 
> >> also has considerable advantages for composition.  
> Consider Arkin's 
> >> example in 
> >> 
http://lists.w3.org/Archives/Public/public-ws-chor/2003Jul/0134.html: 
>> we want to re-use the "message" interaction in many choreographies.  
>> If a message is specified from a senders perspective as a send 
>> followed by an acknowledgement, we can use this sender behaviour in a 
>> number of different scenarios, including a simple message, a 
>> delegated message or even a multicast message (e.g. for high 
>> availability).  If we "bind" the sender's message semantics to a 
>> particular interaction model then we significantly reduce the 
>> possible compositions of this behaviour.
>
> 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.  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.

Ciao,

AndyB

>
> arkin
Received on Tuesday, 22 July 2003 15:02:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:00:25 GMT