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

That also relates to the discussion we had before regarding the 
combination of RM and business-level choreographies.

arkin

Cummins, Fred A wrote:

>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 16:09:55 UTC