Choreography Definition Language for Web Services [was: Re: The specs we need (was, RE: Correlation Requirements]

I am not really sure why we need to have 2 docs (1. CHOREOGRAPHY DEFINITION LANGUAGE (CDL) and 2. CHOREOGRAPHY BINDING SPECIFICATION).

I believe that we should create a CHOREOGRAPHY DEFINITION LANGUAGE for Web Services (CDL4WS) that uses WSDL 1.2/XML Schema features to bind the abstract choreography constructs to concrete things like data-types, message formats/protocols, endpoint-references, etc.

The CDL4WS can provide a lot of value add to the Web Services user community compared to what exists now.

BTW, BPEL4WS has taken a similar design approach, where they architect their specs for the WS-stack by using all WS-existing specs and extending/creating new ones only when necessary. As a result of this approach they have created "Business Process Execution Language for Web Services" and not just "Business Process Execution Language".


"Burdett, David" wrote:

>  Comments to your last point, where you said ...[FAC] The choreography definition being used in an exchange is something that the parties agree on either implicitly (by one using the service of the other) or explicitly, through some negotiation process. <DB>This can also include both agreeing to follow some published choreography, for example one developed by their industry association.</DB>The choreography defines the relationship between the public states of the participants. The correlation of messages between two parties can be handled implicitly by a messaging facility or explicitly with a correlation variable carried in the message (defined elsewhere).  If done implicitly, I don't believe it would need to appear in the choreography, but for long-running, asynchronous messaging transactions, it is probably desirable (maybe necessary) to have an explicit correlation variable. <DB>Assaf makes a good point that sometimes multiple correlation variables are needed for a single choreography instance. I can also see how doing correllation by referencing the content of a message can sometimes make sense. My concern would be that if you allow too many different ways: implicit, correlation variables in a header, references to message content, then you are adding to the complexity for no certain benefit.</DB>When we get to composite choreographies, we need to link (correlate) the different conversations that relate to the same composite exchange.  For this purpose, the conversations should reference shared correlation variable(s).  The choreography references to the variable(s) should be symbolic but must bind to actual correlation variables in the implementations (e.g., BPEL).<DB>Rather than one correlation variable you might need to have multiple correlation variables. If you take the three-role choreography described at [1] where the buyer contracts with a shipper to collect and deliver goods from the seller, then you could imagine this being composed out of three lower level choreographies which could exist in their own right, i.e.:a) Order placement: buyer places order with seller and seller confirms; correlation - order nob) Transport booking: Buyer places transport booking with shipper, shipper confirms; correlation - booking refc) Shipment: Shipper collects goods from seller and delivers to buyer, correlation - shipping refSo you could have three different numbers used for correlation.</DB>David[1] http://lists.w3.org/Archives/Public/www-ws-arch/2002Oct/att-0369/eCommerce_Use_Case.pdf
>
>      -----Original Message-----
>      From: Cummins, Fred A [mailto:fred.cummins@eds.com]
>      Sent: Tuesday, August 12, 2003 6:22 AM
>      To: Burdett, David; Cummins, Fred A; 'Keith Swenson'; 'Monica Martin'
>      Cc: 'Martin Chapman'; 'Yves Lafon'; jdart@tibco.com; 'Ugo Corda'; public-ws-chor@w3.org
>      Subject: RE: The specs we need (was, RE: Correlation Requirements
>
>      David,I like this.  I think it pulls most of it together at this point.I think we need a bit more discussion on 2c.  See below.Then we need to get this clearly stated in the requirements.Fred
>
>           -----Original Message-----
>           From: Burdett, David [mailto:david.burdett@commerceone.com]
>           Sent: Monday, August 11, 2003 8: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
>
>           FredI 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 LANGUAGEThis 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 structureb) 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 wayd) Multi-role, i.e. you can involve more than two roles in a choreography, e.g. buyer, seller and shippere) ... some extra things I'm probably missingThe 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, andb) 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 SPECIFICATIONThis 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 reliabilityb) How to map roles to actual service instances, e.g to map the "seller role" to the a WSDL definition that specifies a concrete bindingc) How to identify the actual choreography definition being used and the instance of the choreography being performed when a choreography is being followedIf 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?
>
>           [FAC] The choreography definition being used in an exchange is something that the parties agree on either implicitly (by one using the service of the other) or explicitly, through some negotiation process.  The choreography defines the relationship between the public states of the participants. The correlation of messages between two parties can be handled implicitly by a messaging facility or explicitly with a correlation variable carried in the message (defined elsewhere).  If done implicitly, I don't believe it would need to appear in the choreography, but for long-running, asynchronous messaging transactions, it is probably desirable (maybe necessary) to have an explicit correlation variable.  When we get to composite choreographies, we need to link (correlate) the different conversations that relate to the same composite exchange.  For this purpose, the conversations should reference shared correlation variable(s).  The choreography references to the variable(s) should be symbolic but must bind to actual correlation variables in the implementations (e.g., BPEL).Does this make sense?David
>
>                -----Original Message-----
>                From: Cummins, Fred A [mailto:fred.cummins@eds.com]
>                Sent: Monday, August 11, 2003 5:39 AM
>                To: Burdett, David; 'Keith Swenson'; 'Monica Martin'
>                Cc: 'Martin Chapman'; 'Yves Lafon'; jdart@tibco.com; 'Ugo Corda'; public-ws-chor@w3.org
>                Subject: RE: Correlation Requirements
>
>                Keith,I agree with David, but I would also consider the issue to be a matterof separation of concerns.  The choreography relies on correlationbut it should not define how it is implemented. There is another aspect of correlation when a composite choreographyconsistes of a relationship between binary exchanges as for theseller who interacts with the customer and the bank.  Here thereis correlation between the choreographies, but no message beingpassed, per se.  The correlation occurs within the seller's privateprocess.I would like the choreography language to specify the exchangesindependent of the message formats and transport protocol to havebroadest application.Fred
>
>                     -----Original Message-----
>                     From: Burdett, David [mailto:david.burdett@commerceone.com]
>                     Sent: Monday, August 11, 2003 2:28 AM
>                     To: 'Keith Swenson'; Burdett, David; 'Monica Martin'
>                     Cc: 'Martin Chapman'; 'Yves Lafon'; jdart@tibco.com; 'Ugo Corda'; Cummins, Fred A; public-ws-chor@w3.org
>                     Subject: RE: Correlation Requirements
>
>                     I think you have two use cases:1. Where there is *no* data inside the "payload" that can be used for corellation purposes, and2. Where there *is* data inside the "payload" that can be used for corellationNow, since the first case will sometimes exist, when there is a need for corellation, then you really have no option but to put some type of "choreography instance identifier" in data that is carried with the message, or what, for the purposes of this email, I am calling message "metadata" (Note, for SOAP this would be almost be data in a SOAP header).However if you always insist that the "choreography instance identifier" is present in the message metadata, then, in the second case, there is a risk that the data inside the payload might be inconsistent with choreography instance identifier in the messsage metadata. This inconsistency is almost certainly incorret and so there is an error which would should be flagged.You can avoid this inconsistency, if, message metadata, you reference the data in the payload instead with a "choreography instance reference", but at the expense of more complexity in how the correllation is done since it will be impossible, for example to restrict the type of the correlation which could include a combination of different data of different types. For example you might need to do correllation based on a combination of "supplier identifier, year and order no".My *personal* $0.02c, would be to always have a "choreography instance identifier" in the data carried with the message, e.g. the SOAP header, as:a) There is always just one way to do correlation at "messaging middleware" level, i.e. in the software layer between the transport protocol software and the applicaitonb) The probability of inconsistency between the messagec) It is *much* simpler!Now, before anyone says anything, I know this is talking about a design, but I think that sometimes thinking about design problems actually helps clarify the problems ... with the proviso that you a) record your design decisions (i.e. in emails like this) and b) you are prepared to revisit the problem in the light of a better understanding of the problems/issues. If we try and postpone *all* these things, then we are just creating more problems for later in my opinion!David
>
>                          -----Original Message-----
>                          From: Keith Swenson [mailto:KSwenson@fsw.fujitsu.com]
>                          Sent: Sunday, August 10, 2003 10:46 PM
>                          To: Burdett, David; 'Monica Martin'
>                          Cc: 'Martin Chapman'; 'Yves Lafon'; jdart@tibco.com; 'Ugo Corda'; 'Cummins Fred A'; public-ws-chor@w3.org
>                          Subject: RE: Correlation Requirements
>
>                          I would like to understand why it is important to leave so many different ways of carrying correlation information.  Our job is to produce a specification that will ensure interoperability.  If there are an infinite number of ways to communicate correlation information, then we haven't really specified anything, have we? The reason I am probing this is because I want to understand what is the underlying "requirement" that we avoid being prescriptive.  It clearly would be a benefit to the entire industry if we could stick with your requirements 1 & 2, except change 2 to specify exactly which header field MUST contain the choreography instance id.  Why is it that "you don't want to have to be forced to use an identifier in the header."?  Seems to me that the effort and cost to put this in a consistent place would be far less effort and cost that would be incurred by coding all the various point-to-point variations due to each implementation using a different way of coding correlation information.-Keith Swenson
>
>                               -----Original Message-----
>                               From: Burdett, David [mailto:david.burdett@commerceone.com]
>                               Sent: Thursday, August 07, 2003 3:15 PM
>                               To: 'Monica Martin'; Burdett, David
>                               Cc: 'Martin Chapman'; 'Yves Lafon'; jdart@tibco.com; 'Ugo Corda'; 'Cummins Fred A'; public-ws-chor@w3.org
>                               Subject: RE: Correlation Requirements
>
>                               Monica
>
>                               The reason I included requirements 2 and 3 is that they reflect two use cases ...
>
>                               If we assume that there has to be some data in the message that can be used for correlation when the message is taking part in a choreography then requirement 2 arises becaus it is possible that there is no data in the payload (or anywhere else) that can be used for correlation purposes.
>
>                               Requirement 3 arises because there maybe data that can be used in the payload and therefore you don't want to have to be forced to use an identifier in the header.
>
>                               However, I can also see your point that the existing requirement definitions could be a bit too presrcriptive, so how about these as alternatives, I've added a fourth requirement which hopefully makes it clearer. The complete set is as follows ...
>
>                               Requirement 1 (not changed)
>                               If a message is being sent between roles as part of the "performance" of a choreography, then that message MUST identify the "choreography instance" to which it belongs.
>
>                               Requirement 2 (changed)
>                               A choreography instance MUST be identified by specifying a separate identifier associated with the payloads in the message where there is no combination of data in the "payload(s)" that can be used to uniquely identify the choreography instance that is being performed.
>
>                               Requirement 3 (changed)
>                               A choreography instance MAY be identified by referencing a combination of one or more items of data in the "payload(s)" of the message where that combination of data can be used to uniquely identify the choreography instance that is being performed.
>
>                               Requirement 4 (new)
>                               A choreography  instance MAY be identified by specifying a separate identifier associated with payload(s) in the message even if there is a combination of data in the "payload(s)" that can be used to uniquely identify the choreography instance that is being performed.
>
>                               David
>                               -----Original Message-----
>                               From: Monica Martin [mailto:monica.martin@sun.com]
>                               Sent: Thursday, August 07, 2003 3:03 PM
>                               To: Burdett, David
>                               Cc: 'Martin Chapman'; 'Yves Lafon'; jdart@tibco.com; 'Ugo Corda';
>                               'Cummins Fred A'; public-ws-chor@w3.org
>                               Subject: Re: Correlation Requirements
>
>                               Burdett, David wrote:
>
>                               > A very good point Martin - I was presuming "a" solution which is
>                               > perhaps premature.
>                               >
>                               > So let's do this the "right" way and think about it in terms of
>                               > requirements so here's my $0.02c on what they might be ...
>                               >
>                               > Requirement 1
>                               > If a message is being sent between roles as part of the "performance"
>                               > of a choreography, then that message MUST identify the "choreography
>                               > instance" to which it belongs
>                               >
>                               > Requirement 2
>                               > A choreography instance MAY be identified by specifying a unique
>                               > identifier in "metadata" (e.g. a SOAP header) associated with the message.
>                               >
>                               > Requirement 3
>                               > A choreography instance MAY be identified by referencing a combination
>                               > of one or items of data in the "payload(s)" (e.g. the SOAP body and/or
>                               > attachments) of the message.
>                               >
>                               mm1: I would suggest on Reqt 2 and 3 that we specify the requirement not
>                               the solution, of which these requirements appear to do both.
>                               Particularly, a choreography instance may be referenced, - do we specify
>                               how?
>
>                               > To make these complete, we should also define, roles, performance,
>                               > choreography instance, metadata and payload, but that can come later!
>                               >
>                               > Thoughts?
>                               >
>                               > David
>                               >
>