RE: The specs we need (was, RE: Correlation Requirements

David,
 
In your part 1) I have a problem putting points a and b together. In point b) you say that we use WSDL definitions (abstract ones, as you specify). These definitions will contain specific descriptions of message parts (abstract ones, of course). Is that what you are referring to in point a) as being independent of any message format (i.e. message semantics == WSDL message abstract definitions)? If not, I would have a problem having WSDL definitions in your part 1) which describe message parts at a level that does not correspond to the level of messages described in point a). If that is the case, I would not even mention WSDL in part 1 and introduce it only in part 2.
 
By the way, a couple of weeks ago you were talking about three levels of messages, but here I can see only two.
 
Ugo

-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Monday, August 11, 2003 5:33 PM
To: 'Cummins, Fred A'; Burdett, David; 'Keith Swenson'; 'Monica Martin'
Cc: 'Martin Chapman'; 'Yves Lafon'; jdart@tibco.com; Ugo Corda; public-ws-chor@w3.org
Subject: The specs we need (was, RE: Correlation Requirements


Fred
 
I think we are basically violently agreeing. But let's try and nail this in terms of what we need to define. Here's my thoughts.
 
1. CHOREOGRAPHY DEFINITION LANGUAGE
This spec will describe how to create a "choreography definition" in a way that is:
a) Independent of any message format, i.e. a message is defined in terms of its semantics rather than its structure
b) Independent of any service implementation, i.e. the roles that take part in an implementation are defined abstractly (e.g. using WSDL definitions without any bindings)
b) Independent of implementation specifics, e.g. how you do corellation, security, reliability etc.
c) Composable, i.e. you can build new a choreography out of existing choreographies in a hierachical way
d) Multi-role, i.e. you can involve more than two roles in a choreography, e.g. buyer, seller and shipper
e) ... some extra things I'm probably missing
 
The problem with a Choreography Definition Language like this, is that is not directly implementable as it does not relate to any real implementation. As it stands it would not be much more than something that is (hopefully) rigorous but can only be used by humans!
 
So what we need is a spec that describes how to use a "choreography definition" defined using the Choreography Definition Language so that it can be used:
a) At design time to speed the building of a business process that supports the choreography, and
b) At run time to validate that a choreography is being "performed" correctly, i.e. checking that the sequence in which the interactions between the roles occur is in agreement with the rules defined in the choreography definition.
 
So what we need is a ...
 

2. CHOREOGRAPHY BINDING SPECIFICATION
This spec will describe how to bind a "choreography definition" to an implementation. This spec will need to specify, or refence specs that specify:

a) How to map the message semantics to actual messages including: the payload, the message binding (e.g. SOAP, ebXML, etc), and the use of such things as security and reliability
b) How to map roles to actual service instances, e.g to map the "seller role" to the a WSDL definition that specifies a concrete binding
c) How to identify the actual choreography definition being used and the instance of the choreography being performed when a choreography is being followed
 
If we don't specify HOW to do this last point (2c), then we won't get interoperable implementations. Note that "how" does not mean we have to write the spec, but if we don't write the spec, we need to specify which spec to follow or we won't have a spec that results in interoperable implementations ... isn't interoperabilitry what standards is all about?
 
Does this make sense?
 
David