- From: Jean-Jacques Dubray <jjd@eigner.com>
- Date: Tue, 8 Jul 2003 17:59:58 -0400
- To: "'Cummins, Fred A'" <fred.cummins@eds.com>
- Cc: <public-ws-chor@w3.org>
>>I'm having difficulty netting out your discussion. I see only one >>form of composition relevant to choreography. That is the form >>described by Martin, below. [JJ] I am ok with that. >> >>Composition of web services I see as fundamentally composition of >>a web service where a web service may incorporate and thus encapsulate >>other web services in the performance of its offering. In this case, >>there is choreography between the web service provider (not the role >>of the service offered) and each of the incorporated services. There >>will then be a choreography between the service offered role and >>a user of the service. [JJ] Yes and this is why I thought it was valid to ask the question if it is in scope or not. Is Web Service Composition some semantic sugar on top of ws-chor or is it more? The composite web service is just a "pass-through" (if you keep aside the message transformation problem), and expressing that a message coming out of a back-end service is propagated to the end-user of the composite service should not be that hard to express once you have the ws-chor definition between the back-end service and the composite service. The "composite service" is a very special service that is just forwarding messages back and forth based maybe on some internal (routing) rules. Ultimately having a transformation handy would also be helpful. JJ- >> >>It is possible that we could see a situation where both of these >>apply. For example, if we have a buyer and a seller, and the seller >>is a service composed of a warehouse, as carrier and a bill collector. >>The warehouse may be fully encapsulated, but the carrier and bill >>collector may interact with the buyer. Thus there are several >>choreographies: >> >>buyer-seller >>seller-warehouse >>seller-carrier >>seller bill collector >>carrier-buyer >>bill collector-buyer >> >>and potentially two composite choreographies: >> >>1) buyer-seller, carrier-buyer and bill collector-buyer >>2) buyer-warehouse, buyer-carrier, buyer-bill collector >> >>I don't see a choreography composition that combines >>these two composites since that would break the >>encapsulation of the buyer service. From a buyer >>perspective, the seller, the carrier and the bill collector >>could all be the same entity in different roles without >>any choreography defining the internal business processes. >> >>Fred >> >>> -----Original Message----- >>> From: Jean-Jacques Dubray [mailto:jjd@eigner.com] >>> Sent: Tuesday, July 08, 2003 7:46 AM >>> To: 'Martin Chapman'; 'Champion, Mike'; public-ws-chor@w3.org >>> Subject: RE: Revised: Mission Statement >>> >>> >>> >>> 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 18:01:16 UTC