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

RE: Revised: Mission Statement

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>
Message-ID: <018301c34546$87c4ba30$1378050a@JJD>

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 GMT

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