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

RE: Choreography State Definition (was: RE: More requirement

From: Champion, Mike <Mike.Champion@SoftwareAG-USA.com>
Date: Tue, 1 Jul 2003 03:55:07 -0400
Message-ID: <1057787667.IAA22192@phantom.w3.org>
To: "'WS Chor Public'" <public-ws-chor@w3.org>


> -----Original Message-----
> From: Jon Dart [mailto:jdart@tibco.com] 
> Sent: Monday, June 30, 2003 4:35 PM
> To: Steve
> Cc: Monica J. Martin; Burdett David; Nickolas Kavantzas; 
> Jean-Jacques Dubray; 'Yaron Y. Goland'; 'WS Chor Public'
> Subject: Re: Choreography State Definition (was: RE: More requirement

> The implication is that you have to treat reliable messaging 
> as a "black box" at the choreography layer. I.e., if it 
> exists, its supporting messages are not part of the message 
> exchange captured at the choreography layer. It is a QOS, 
> nothing more.

WSA is wrestling with trying to clarify the distinctions among
"choreography", "MEP", etc.  "RM" seems to be in a similar state -- one
might say that RM is a foundation on which choreography builds, or may say
that the sequence of messages that implement an RM protocol can be described
by a choreography language, or find some way of saying both.  

I'm torn ... On one hand a RM protocol is a "choreography" ... But on the
other hand sensible people will not want to consider RM messages when
describing their application-level choreography.  

I suspect that we can resolve this by somehow referring to the fact that
choreographies can be composed of other choreographies, and the user or
implementer of a choreography can treat the lower level choreographies as a
black box. 
So, MEPs and RM protocols are "choreographies" in a formal sense, but can be
treated as primitive "events" from the point of view of an
"application-level" choreography.
Apologies if this is overly obvious or fuzzy ... My only excuse is that I'm
six time zones away from home and jet lag does my clarity of thought very
little good!
Received on Tuesday, 1 July 2003 03:55:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:00 UTC