RE: Simple Choreography composition suggestion

Ugo

I see things slightly differently. Let's take your example where you have
...
1. A Purchaser interacting with a Purchase Order process. A choreography -
let's say choreography A - describes their interactions
2. The Purchase Order web service ... interacts with other web services:
Invoice, Scheduling and Shipping. The interactions among these four web
services can also be described by a choreography - let's call it
choreography B

The view I would take is that actually there are four choreographies ...
1. Choreography A - between the Purchaser and the Purchase Order Process
2. Choreography B1 - between the Purchase Order Process and the Invoice
process
3. Choreography B2 - between the Purchase Order Process and the Scheduling
process
4. Choreography B3 - between the Purchase Order Process and the Shipping
process

The criteria I use for identifying *separate* choreographies is that
choreographies should not be dependent on each other, e.g. Invoicing does
not need to know *nothing* about purchasing, scheduling or shipping and vice
versa, which, in your example I beleive to be the case.

A "relationship" between these choreographies only occurs when they are
brought together by a single area of "management control" (e.g. the
supplier). Whether composed process becomes another choreography or not is
dependent on whether the resultant choreography needs to be published and
shared because other (non-supplier) roles need to know the complete picture.

For example, if you want to provide the description of the combined
choreography to the purchaser so that they have the complete picture of the
actions that the *purchaser* will have with the bank for invoicing and the
shipper for scheduling and shipping then it would be valid to call it a
choreography.

On the other hand, if the purchaser does not need information on how the
combined choreography works, then all you have is an *internal business
process* which is totally under the control of the single role, in this case
the supplier.

This all boils down to what I see as being the key differentiator of a
choreography from a (business) process which is that with a choreography
there is no single process that is in complete control - therefore the
processes involved have to "cooperate". On the other hand with a process
there is a single entity in control and therefore you have a business
process instead which can be implemented using languages such as BPEL.

David

-----Original Message-----
From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
Sent: Thursday, July 17, 2003 3:03 PM
To: Cummins, Fred A
Cc: public-ws-chor@w3.org
Subject: RE: Simple Choreography composition suggestion



Fred,

The point I was making is that some of the web services in a choreography
(whose mutual relationships are defined by the choreography itself, as you
say) might be "exploded" to reveal an internal behavior that can also be
described via a choreography. 

In the BPEL example I mentioned, we can initially think that there is only a
Purchaser interacting with a Purchase Order process. A choreography - let's
say choreography A - describes their interactions.

But if we look inside the Purchase Order web service we find out that it in
turn interacts with other web services: Invoice, Scheduling and Shipping.
The interactions among these four web services can also be described by a
choreography - let's call it choreography B. (It just happens that in my
specific example the Purchase Order web service is realized by a BPEL
process, but this should not matter for this particular discussion).

So now I have two choreographies, and choreography A interacts with
choreography B via a web service interface (the purchaseOrder portType -
whose messages, as Arkin says, "start" choreography B). 

My point is that the overall interactions of all five web services
(Purchaser, Purchase Order, Invoice, Scheduling and Shipping) can also be
described by a choreography (let's call it choreography C). So choreography
C can be seen as composed of choreographies A and B, where the point of
communication between A and B is a particular portType on the Purchase Order
web service (web service which, from the point of view I described, can be
seen as "encapsulating" choreography B).

Ugo

> -----Original Message-----
> From: Cummins, Fred A [mailto:fred.cummins@eds.com]
> Sent: Thursday, July 17, 2003 2:03 PM
> To: Ugo Corda; Assaf Arkin
> Cc: public-ws-chor@w3.org
> Subject: RE: Simple Choreography composition suggestion
> 
> 
> Ugo,
> 
> This seems to suggest that a choreograpy defines, or
> may define a web service.  On the contrary, I see
> a choreography as defining relationships between
> web services.
> 
> Fred
> 
> > -----Original Message-----
> > From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
> > Sent: Thursday, July 17, 2003 1:07 PM
> > To: Assaf Arkin
> > Cc: public-ws-chor@w3.org
> > Subject: RE: Simple Choreography composition suggestion
> > 
> > 
> > 
> > > A choreography as I understand if is a Web service only if 
> > it has an 
> > > entry point that is used by someone outside the 
> > choreography to start 
> > > it. If the choreography starts when A sends a message to 
> B (A and B 
> > > being roles covered by the choreography), then it's not a 
> > Web service. 
> > > But if the choreography starts by someone sending a message 
> > to A, where 
> > > that role is not otherwise covered by the choreography, then that 
> > > choreography is a Web service. It has an externally 
> > accessible entry 
> > > point, or any other term we may opt to use.
> > > 
> > > Since it's a Web service, it can further be used in a larger 
> > > choreography that may or may not be a Web service. Such a 
> > choreography 
> > > would cover that additional role that starts the Web 
> > service choreography.
> > 
> > Yes, that's basically the point I was making with my BPEL example. 
> > 
> > It seems to me that, since choreographies are "made" of Web 
> > services, establishing this relationship between a 
> > choreography and the Web service that "encapsulates" that 
> > same choreography (if any) would provide a way of talking 
> > about choreographies composition.
> > 
> > Ugo
> >  
> > 
>

Received on Friday, 18 July 2003 16:20:10 UTC