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

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

From: Andrew Berry <andyb@whyanbeel.net>
Date: Sun, 17 Aug 2003 23:06:06 +1000
Cc: public-ws-chor@w3.org
To: "Burdett, David" <david.burdett@commerceone.com>
Message-Id: <8FCD071C-D0B3-11D7-9356-0003936786BC@whyanbeel.net>

David,

A late +1 and I now understand better your need for identifiers.

AndyB.

-----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 aspec 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
>
Received on Sunday, 17 August 2003 09:04:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:10 UTC