- From: Champion, Mike <Mike.Champion@SoftwareAG-USA.com>
- Date: Tue, 1 Jul 2003 03:55:07 -0400
- 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