Web Service Composition [Was RE: Revised: Mission Statement]

>>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