Forwarded message 1
JJ,
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.
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.
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?
> >>>
> >>>
>