Composing Choreographies (was: RE: Revised: Mission Statement

Here's my (belated) $0.02c ...

There are several different types of composition, for example ...
"Hierarchical" composition (although I'm not sure that "hierarchical" is the
best word to use) where one choreography is built on top of another in a
hierarchy. Consider the following example ...
a) A RM choreography defines how to do Reliable Messaging. This choreography
would define the sequence, timeouts, acknowledgements and retries required
to reliably deliver a single "message" between sender and receiver roles. It
could also have various states associated with each of the roles, such
sender:msgsent, receiver:msgreceived, etc.
b) A MEP that included signals as described by JJ and others. This could
define the sending of an initial message and also the signal messages
returned to say the original messages was processed OK (or not). Note that
each message and signal could be delivered using the RM choreography. This
would then lead to additional states for the sender and receiver such as
sender:msgOK and sender:msgnotOK, etc
c) A "business" choroegraphy such as that described by Martin or the ones I
have often described for placing an order. In this case each Message could
make use of the MEP choreography to define the additional signals associated
with the message which would in turn make use of the RM choreography to
deliver the messages. Note however that in this case you need to map the
"lower level" roles such as sender and receiver to the higher level business
roles. This type of choreography would also introduce its own additional
states.
d) You could also then combine "business" protocols in different ways. For
example by combining an Order choreography with a payment choreography. Or
combining an Invoice choreography with the same payment choreography. These
would also introduce new states.

The common thread in all these choreographies is the idea of exchanging
information which results in a changes of state of the roles involved. This
in turn means that a method of using state information at one level at a
higher level becomes important. For example a business choreography could
use the MsgNotOK state returned by a MEP to carry out some alternative
compensating choreography.

You might also be able to use the idea of state definitions to abstract out
the detail of how a choreography works. For example, if there were a set of
states that define the visible states associated with reliable messaging,
then exactly which Reliable Messaging specification was being followed
should not matter.

David


-----Original Message-----
From: Yaron Y. Goland [mailto:ygoland@bea.com]
Sent: Wednesday, July 09, 2003 11:46 AM
To: public-ws-chor@w3.org
Subject: RE: Revised: Mission Statement



+1

This was the hierarchical requirement in my use cases.

> -----Original Message-----
> From: public-ws-chor-request@w3.org
> [mailto:public-ws-chor-request@w3.org]On Behalf Of Jim Hendler
> Sent: Monday, July 07, 2003 9:22 AM
> To: Martin Chapman; Champion, Mike; public-ws-chor@w3.org
> Subject: RE: Revised: Mission Statement
> 
> 
> 
> At 9:04 AM -0700 7/7/03, Martin Chapman wrote:
> >I think Mike has made a good point here. If a composition presents a new
> >wsdl, it has to be hosted somewhere, even if its job is just to 
> delegate out
> >to the parties (Yaron made a similar point the other week). I 
> thought we had
> >ruled out this sort of central controller, for autonomous peer-peer
> >environments.
> >Thinking about this a little more, the only way I can see nesting of
> >choreographies is for one choreography to take on the role(s) defined in
> >another choreography. Something like:
> >
> >Choreo 1: pay
> >	role payer
> >	role payee
> >	role cardagency
> >
> >	payer sends payment details to cardagency
> >	//cardagency verifies and does stuff
> >	cardagency deposits money from payers card
> >	cardagency credits money (minus fee) to payees account
> >
> >Choreo 2: Purchase goods
> >	role buyer
> >	role seller
> >	reuses Choreo 1: buyer=payer, seller=payee
> >
> >	buyer submits PO
> >	seller checks warehouse
> >	seller send invoice to buyer
> >	buyer submits payment details (kicks off choreo 1)
> >
> >	blah, blah
> >
> >Something like that anyway.
> >
> >Martin.
> 
> I think this is the correct way to do this sort of thing -- assuming 
> the choreographies are able to be designated with a URI or with some 
> other namespace type trick, then I think there is tremendous strength 
> in one choreography being able to use another by pointing (and 
> setting variables)
>   -JH
> 
> -- 
> Professor James Hendler				  hendler@cs.umd.edu
> Director, Semantic Web and Agent Technologies	  301-405-2696
> Maryland Information and Network Dynamics Lab.	  301-405-6707 (Fax)
> Univ of Maryland, College Park, MD 20742	  *** 240-277-3388 (Cell)
> http://www.cs.umd.edu/users/hendler      *** NOTE CHANGED CELL NUMBER ***
> 
>

Received on Tuesday, 15 July 2003 02:36:38 UTC