Re: Choreography Lower Bound

I think we're on the same page.

I'm not suggesting we pollute the business-level exchange, which should 
be expressed using WSDL + choregraphy language, with details relating to 
the MEP or RM. A combination of RM and business-level choreography can 
be solved by having the RM be defined and acted-upon out-of-bands, which 
was the conclusion of the previous discussion. That way the choreography 
focuses strictly on the business-level choreography using business-level 
WSDL interfaces, but RM exchange does transpire.

Our only concern would be to structure the choreography language such 
that it yeilds well to usage with RM, e.g. to properly define the 
semantics for asynchronous messages, or accept that there would be RM 
faults, etc.

arkin

Cummins, Fred A wrote:

>Assaf, Steve,
>
>In response to Steve's question in closing the conference call and
>considering the business exchange vs the message exchange in the
>context, below, I believe WSDL and choreography should be defined
>for the business exchange level.  A message exchange is
>an implementation of the business exchange.  The message exchange
>interfaces are not appropriately defined in WSDL--there
>are not "operations" to be defined and there are not roles
>in the same sense.  The logic of the message exchange is visible at
>the interface, while the logic supporting the business choreography is
>encapsulated in the respective participants' business logic.
>
>So while you might be able to describe the message exchange
>using choreography, the choreography language will may be lacking
>in logic constructs and will include specifications for message types
>and roles for the business exchange that will not be meaningful for
>the message exchange.
>
>Furthermore, there should be few message exchange protocols,
>and the definition of these protocols will be by technical 
>specialists and implemented in software.  The business exchanges
>described by choreography will be numerous and will be defined
>by business-oriented technical people.  So I see little or no
>value in trying to define a choreography language to address
>both of these problems and audiences.
>
>Fred
>
>  
>
>>-----Original Message-----
>>From: Assaf Arkin [mailto:arkin@intalio.com]
>>Sent: Tuesday, July 22, 2003 4:09 PM
>>To: Cummins, Fred A
>>Cc: Andrew Berry; Francis McCabe; public-ws-chor@w3.org
>>Subject: 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/01
>>>      
>>>
>>34.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 Wednesday, 23 July 2003 12:42:35 UTC