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

RE: Correlation Requirements

From: Burdett, David <david.burdett@commerceone.com>
Date: Fri, 5 Sep 2003 14:57:58 -0700
Message-ID: <C1E0143CD365A445A4417083BF6F42CC053D1DCD@c1plenaexm07-b.commerceone.com>
To: "'jdart@tibco.com'" <jdart@tibco.com>, Francis McCabe <fgm@fla.fujitsu.com>
Cc: "Burdett, David" <david.burdett@commerceone.com>, 'Monica Martin' <monica.martin@sun.com>, 'Martin Chapman' <martin.chapman@oracle.com>, 'Yves Lafon' <ylafon@w3.org>, 'Ugo Corda' <UCorda@SeeBeyond.com>, 'Cummins Fred A' <fred.cummins@eds.com>, public-ws-chor@w3.org

>>>There may even be a set of services that you want to coordinate in a
particular fashion to achieve a particular goal (e.g., the warehouse, credit
card, delivery services combine to deliver a book.)<<<

In this case aren't you just defining a business process over which you have
total control where you are just using the existing services within their
already pre-defiined constraints?

If this is true you don't need a CDL and the services you use don't need to
be changed to become choreography aware - i.e. I agree.

But that's not the problem I am thinking of.

Let's suppose a seller has a service that can accept orders. When the
service receives the order it needs to know how to respond, and, also know
what types of messages the buyer might send next. As I said in my earlier
email we have identified 14 different ways of placing an order.

As I see it, there two ways you *could* solve this problem:
1. Define 14 different services where each one corresponds to a different
way of doing business, or
2. Define 1 service that is choreography aware where each message sent
identifies in some way the choreography that is being followed.

I prefer the second approach for solving *this* problem as it is easier to
manage and easier to re-use existing services in new and novel
choreographies as you don't need new service definitions ... at least that
is the way I see it.

I am not actually disagreeing with anything you're saying. I just think that
there are basically two types of problems here:
1. Where a single entity (e.g. a business) is designing a process that is
using existing services in their standard ways in this case a CDL or
choreography aware services is not needed
2. Where two or more entities need to use one or more of their existing
services in various different ways and they need to know which variation to
follow - this is where a CDL and a way of identifiying it in a message is
useful.

David

-----Original Message-----
From: Jon Dart [mailto:jdart@tibco.com]
Sent: Friday, September 05, 2003 1:29 PM
To: Francis McCabe
Cc: Burdett, David; 'Monica Martin'; 'Martin Chapman'; 'Yves Lafon';
'Ugo Corda'; 'Cummins Fred A'; public-ws-chor@w3.org
Subject: Re: Correlation Requirements



+1.

The description of particular service requirements and capabilities is 
generally in WSDL, or in WS-Policy, which can be viewed as a supplement 
to WSDL, not at the choreography layer. The set of such requirements and 
capabilities is expanding all the time.

BPEL hasn't placed correlation-related requirements on services, either, 
but has provided a mechanism through which business processes can 
specify what the correlation mechanism is, in a flexible way that is 
conformable with multiple emerging specs in this area.

--Jon

Francis McCabe wrote:
> A given service will have its *way* of doing things. That may, or may not
be, fully described in a choreography document. There may even be a set of
services that you want to coordinate in a particular fashion to achieve a
particular goal (e.g., the warehouse, credit card, delivery services combine
to deliver a book.) Each of these (say) does its thing in a rich way, and
*I* want to document how to use them to achieve the book delivery service -
I should be able to do that in a CDL without impacting any of the existing
services. A corollary of that is that there may be no way of determining
what choreography a given message is part of (by looking at the messages),
it is simply an interpretation of the CDL. 
Received on Friday, 5 September 2003 17:58:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:00:30 GMT