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

This is the Web Services Choreography Working Group. Not the 'solve every
possible choreography problem in the world' Working Group. Our remit is
quite clear - we only worry about web services. If you are doing something
that is not a web service or using a transport that is not a web service
then you have come to the wrong group.

That having been said I see no harm in being generic where we can but that
must always be a secondary consideration to our primary goal - provide
choreography for Web Services.

        Yaron
  -----Original Message-----
  From: public-ws-chor-request@w3.org
[mailto:public-ws-chor-request@w3.org]On Behalf Of Burdett, David
  Sent: Wednesday, August 13, 2003 2:19 PM
  To: 'Nickolas Kavantzas'; 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: 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
        -----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
                  >