RE: Grounding Choreographies (the atoms) - WAS Simple Choreograph y composition suggestion

Ugo

I think that it is *necessary* to layer our choreography specs so that you
have:
1. A spec for an "abstract" choreography definition that describes the
sequence and conditions in which messages are exchanged between roles, and
2. A spec for binding the abstract choreography definition to: physical
message formats and physical service interface definitions.

The reason for this is that you can have the same abstract choreography,
e.g. the buyer sending a PO and the seller sending a PO Response implemented
in different ways such as:
1. Different formats for the message, e.g. SOAP 1.1 vs 1.2, vs SOAPWA,
RosettaNet PO vs a UBL PO, etc,
2. Different service interfaces, which use different service/actions in the
WSDL to accept/generate SOAP messages

If we don't have these two layers then it means that whenever standards
evolve, e.g. SOAP 1.3 ;) or a new version of the RosettaNet PO, then the
Choreography definition will also *have* to change even though its semantics
have not.

However having this layering also means that you *could* do binding of the
choreography defintion to other protocols, e.g ebXML Messaging. So what I am
proposing though is that we do the abstract choreography spec and just the
SOAP/Web Service binding without necessarily stopping other groups from
doing alternative bindings if they want to.

Hope this answers your question.

David

-----Original Message-----
From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
Sent: Friday, July 18, 2003 1:09 PM
To: Burdett, David; Assaf Arkin; public-ws-chor@w3.org
Subject: RE: Grounding Choreographies (the atoms) - WAS Simple
Choreograph y composition suggestion


> If we say that Choreographies *always* have
> to be *between* web services then it precludes the choreography being used
> by something that is not a web service, which I don't think we want to do.

My understanding of the previous discussion is that we want to include web
service requesters as legitimate choreography participants. In this case the
requester still talks to a web service according to the WSDL interface
associated with that service.

Your statement seems to imply extending our choreography scope beyond web
services and their requesters (e.g. to include services not described by
WSDL). Could you please clarify?

Thank you,
Ugo