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

Nick
 
Firstly, I don't care if we have one document in two parts or two parts each
in their own separate document. However I DO think we need the two parts.
Here's why ...
 
BUSINESS DON'T JUST USE WEB SERVICES
Choreography languages will be used to define how businesses interact with
each other so that the definition can be shared with the businesses taking
part so that each business can make sure they are following their role in
the choreography correctly.
 
Depending on the implementation, the ways business carry out their
"interactions" will vary. For example, one of the interactions might involve
"delivery confirmation" by the shipper of goods that were ordered. In one
implementation this might require a cell phone call from the cycle courier
who delivered the goods. However, perhaps the contract says that the payment
is not made until delivery is confirmed, so "delivery confirmation" is an
important part of the overall choreography being followed.
 
So, in the middle of this particular implementation of the choreography,
there is, in this instance, a non-Web Services interaction, i.e. the phone
call. However the same choreography, in a different implementation, might be
entirely based on web services.
 
I think that a CDL that ONLY worked with web services would HAVE to be
artificially split in two at this point to handle the cycle courier's cell
phone call. Whereas for the "all web services" solution it would not be
necessary.
 
n the other hand if you separate the choreography definition, from the
binding of that definition to an implementation, then the problem goes away
as you can have multiple implementations of the same choreography using
different technologies.
 
THE STRUCTURE OF MESSAGES CAN VARY
The content of business documents can vary. For example RosettaNet, UBL, OAG
and hundreds of other ogranizations have all invented their own versions of
orders, invoices, delivery notes, etc.
 
Worse than this some of the groups, specifically UBL, have developed fairly
simple "core" versions of these documents with the plan for them to be
extended to take account of the additional data needs of different
industries and countries. This means, that, even if everything else (e.g
Security, Reliable Messaging) etc is the same, there will be variations in
the message content to account for the regional and industry requirements.
 
However all these documents will probably exchanged in a fairly limited set
of sequences or choreographies. If each sequence definition has to be
repeated because of changes in the message format, then you will be
repeating choreography definitions that are semantically identical and only
differ in the detail of the message content.
 
On the other hand, if you have a separate definition of the sequence, that
is defined in a way that is independent of the message format, and then
combine that with a binding which shows how the choreography definition
works with particular message formats then, again, the problem goes away as
the same choreography definition can be used by different industries and
regions.
 
 
Like you, I want to reuse whatever specs make sense, but I think that suport
for the above two requirements is important and the only "efficient" way I
can think of doing this is by having an "abstract" choreography definition
language and a "choreography definition binding" that turns the abstract
into concrete. However, in terms of the target "concrete" environment that
we work on, then that should ONLY be web services backed up with a statement
that other bindings are possible.
 
Thoughts?
 
David
 

-----Original Message-----
From: Nickolas Kavantzas [mailto:nickolas.kavantzas@oracle.com]
Sent: Wednesday, August 13, 2003 12:38 PM
To: Burdett, David
Cc: 'Cummins, Fred A'; 'Keith Swenson'; 'Monica Martin'; 'Martin Chapman';
'Yves Lafon'; jdart@tibco.com; 'Ugo Corda'; public-ws-chor@w3.org
Subject: 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_U
se_Case.pdf
<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
<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
<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
<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
<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
<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
<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
<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 
>