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

RE: Simple Choreography composition suggestion

From: Ugo Corda <UCorda@SeeBeyond.com>
Date: Thu, 17 Jul 2003 15:02:39 -0700
Message-ID: <EDDE2977F3D216428E903370E3EBDDC9081243@MAIL01.stc.com>
To: "Cummins, Fred A" <fred.cummins@eds.com>
Cc: <public-ws-chor@w3.org>


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


> -----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 Thursday, 17 July 2003 18:03:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:00 UTC