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

Ugo
 
I think that WSDL message abstract definitions would be fine. However, they
must also have a description of what the message means in terms of: a) what
it contains, for example an order is a description of goods and services to
be purchased, as well as, b) what sending a message means in the context of
a choreography, for example sending an order from a buyer to a seller means
the buyer is requesting the seller to satisfy the order. They're not the
same thing.
 
You also said ... >>>By the way, a couple of weeks ago you were talking
about three levels of messages, but here I can see only two.<<<
 
I actually said there were three levels of choreography definitions, to
quote:
1. The pure choreography - i.e. independent of the message formats and also
the port types/interfaces
2. Choreography bound to an abstract interface/port type
3. Interface/port type bound to a specific implementation
 
How to specify a "pure choreography" would be described in the "Choreography
Definition Language" spec. The other two definitions would be in the
"Choreography Binding Specification". However these last two serve different
purposes:
a) Vertical Industry Group. These can usefully define a binding of the "pure
choreography" to a choreography bound to an abstract interface/port but with
concrete definitions of a message format. These service and message
definitions could then be used by the businesses in the vertical industry.
It also makes it easier for vendors to develop solutions that conform to the
"industry binding"
b) Individual implementation. These could take the Vertical Industry Group
and add the bindings to specific ports that the business has used to
implement the services. This is the last piece of the jigsaw puzzle you need
for implementation.
 
If there is no vertical industry group specification then these two bindings
could be combined into one document.
 
David

-----Original Message-----
From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
Sent: Monday, August 11, 2003 6:03 PM
To: Burdett, David
Cc: public-ws-chor@w3.org
Subject: 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