- From: Jean-Jacques Dubray <jjd@eigner.com>
- Date: Tue, 8 Jul 2003 07:46:06 -0400
- To: "'Martin Chapman'" <martin.chapman@oracle.com>, "'Champion, Mike'" <Mike.Champion@SoftwareAG-USA.com>, <public-ws-chor@w3.org>
Martin, Mike: There is clearly a concept of "choreography composition" whereby someone is able to reuse a choreography within another choreography. I think that this is the example that you provided. I personally view this as significantly different from "web service composition" . WSC assumes that there will be a specific (system) process that will do the routing and mapping to the back end services. This process is very thin and should be completely metadata driven. My view (fantasy?) on how web services are created is such that people will tend to wrap coarse "modules" (order entry, billing, inventory, shipping, ...) behind web service. The question will inevitably come on how do I use my "n" services in "p" choreographies (each one could require a slightly different format or sequence of message interchanges). It would be very useful to have some Web Service Composition metadata defined somewhere by a spec with standard implementations/engines. Now, is this the task of WS-Chor? is it the task of the WSDL group using WS-CHOR? Is it yet another spec? I view this level as different from Orchestration. For me orchestration is "embedded" within these coarse modules providing them with the ability to manage their long running state. Pretty much every business object or collection of business objects has a long running state within any given module: Every purchase order has a lifecycle within the OE module. Traditionally this long running state management of business object has been address by specific code. Now that these modules are more and more interconnected, there a big need to standardize how we go about managing this long running state. Of course the confusion stems from the fact that all 3 levels (Choreography, WSC, Orchestration) have overlapping semantics. For instance, BPEL has tried to achieve the 3 levels in one specification. Maybe that's a little too much to attempt in one step. It can create cases where semantics are missing in order to fully address one level (e.g. choreography) or offer semantics that cannot not be used at all levels (e.g. the "partner" tag :-). Ultimately, this WSC layer (Martin, I think you called it the glue at some point) is key to both the success of choreography and orchestration. JJ- >>-----Original Message----- >>From: public-ws-chor-request@w3.org [mailto:public-ws-chor-request@w3.org] >>On Behalf Of Martin Chapman >>Sent: Montag, 7. Juli 2003 12:05 >>To: Champion, Mike; public-ws-chor@w3.org >>Subject: RE: Revised: Mission Statement >> >> >>I think Mike has made a good point here. If a composition presents a new >>wsdl, it has to be hosted somewhere, even if its job is just to delegate >>out >>to the parties (Yaron made a similar point the other week). I thought we >>had >>ruled out this sort of central controller, for autonomous peer-peer >>environments. >>Thinking about this a little more, the only way I can see nesting of >>choreographies is for one choreography to take on the role(s) defined in >>another choreography. Something like: >> >>Choreo 1: pay >> role payer >> role payee >> role cardagency >> >> payer sends payment details to cardagency >> //cardagency verifies and does stuff >> cardagency deposits money from payers card >> cardagency credits money (minus fee) to payees account >> >>Choreo 2: Purchase goods >> role buyer >> role seller >> reuses Choreo 1: buyer=payer, seller=payee >> >> buyer submits PO >> seller checks warehouse >> seller send invoice to buyer >> buyer submits payment details (kicks off choreo 1) >> >> blah, blah >> >>Something like that anyway. >> >>Martin. >> >>> -----Original Message----- >>> From: public-ws-chor-request@w3.org >>> [mailto:public-ws-chor-request@w3.org]On Behalf Of Champion, Mike >>> Sent: Monday, July 07, 2003 7:20 AM >>> To: public-ws-chor@w3.org >>> Subject: RE: Revised: Mission Statement >>> >>> >>> >>> >>> >>> > -----Original Message----- >>> > From: Monica J. Martin [mailto:monica.martin@sun.com] >>> > Sent: Monday, July 07, 2003 10:02 AM >>> > To: Jim Hendler >>> > Cc: Steve Ross-Talbot; Nickolas Kavantzas; Cummins, Fred A; Martin >>> > Chapman; Yaron Y. Goland; public-ws-chor@w3.org >>> > Subject: Re: Revised: Mission Statement >>> > >>> >>> > mm1: Then could we revise this working definition? >>> > >>> > > **A service composition is a composition of services that >>> > results in a >>> > > ANOTHER service. THIS service can be the combination of >>> > distinct parts >>> > > to form a whole of the same generic type. The web services could be >>> > > combined to achieve a specific goal.* >>> >>> I appreciate the power of recursion as much as anyone <grin> but >>> defining a >>> service composition as a composition of services is not likely to win us >>> great praise for our grasp of the subtlties here. Could we say "is a >>> [concatenation | embedding | nesting | combination | whatever >>> combination ] >>> ..."? Or something other than "composition" anyway. Or is >>"composition" >>> well-defined somewhere else? >>> >>> Also, we need to keep the other parts of the mision statement in >>> mind here. >>> If, when when one is combining services to present a single WSDL >>interface >>> to the outside world and the global state of the interaction does not >>have >>> to be exposed, one is doing that O-word thing rather than >>"Choreography." >>> How can we distinguish Composition in the BPEL sense from >>> Composition in the >>> Choreography sense? >>> >>>
Received on Tuesday, 8 July 2003 07:47:34 UTC