- From: Martin Chapman <martin.chapman@oracle.com>
- Date: Fri, 5 Sep 2003 17:02:00 -0700
- To: "'Burdett, David'" <david.burdett@commerceone.com>, <jdart@tibco.com>, "'Francis McCabe'" <fgm@fla.fujitsu.com>
- Cc: "'Monica Martin'" <monica.martin@sun.com>, "'Yves Lafon'" <ylafon@w3.org>, "'Ugo Corda'" <UCorda@SeeBeyond.com>, "'Cummins Fred A'" <fred.cummins@eds.com>, <public-ws-chor@w3.org>
I think it’s a bit naïve to think that an existing web service can somehow be plugged into a choreography and magically conform to the choreography rules. However I believe that it should be possible to use standard wsdl with no special choreo extensions or interfaces. Is this what you mean Frank? Martin. > -----Original Message----- > From: Burdett, David [mailto:david.burdett@commerceone.com] > Sent: Friday, September 05, 2003 2:58 PM > To: 'jdart@tibco.com'; 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 > > > >>>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 20:01:42 UTC