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

Re: Simple Choreography composition suggestion

From: Assaf Arkin <arkin@intalio.com>
Date: Wed, 16 Jul 2003 18:04:01 -0700
Message-ID: <3F15F601.6070204@intalio.com>
To: Ugo Corda <UCorda@SeeBeyond.com>
CC: "Fletcher, Tony" <Tony.Fletcher@choreology.com>, public-ws-chor@w3.org

If a process is involved in two unrelated choreographies than the 
process is a composition of many things, including activities mandated 
in order to participate in these choreographies. But it's not a 
composition of either choreography, it only intersects, not encompasses.

If two choreographies are related, and it so happens that a process 
would be defined to tie them together, the there is some composition 
that include both choreogaphies, and incidentally also one or more 
processes that tie them together, but the two are independent type of 
definitions.

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. If that choreography is itself a Web service, we have 
recursive composition.

arkin

Ugo Corda wrote:

>>The point I disagree with is the notion that something is not a
>>Choreography if somewhere, at some level it involves 'orchestration'
>>within a single system.
>>    
>>
>
>I completely agree with you. If we take BPEL as an example of orchestration, then the BPEL process interacts with a bunch of Web services, and the process itself is a Web service (by definition). So we have a few Web services (the BPEL process itself plus the other Web services that BPEL interacts with) which exchange messages among themselves - messages which most likely involves a change of state of the various Web services involved. So this configuration of Web services should be describable via a choreography (by definition).
>
>For instance, let's look at the Purchase Order process described in BPEL 1.1 (sec. 6.1) as a concrete example. Seen from "outside" this BPEL process is just a Web service exposing a purchaseOrderPT portType, so it can take part in any choreography where other Web services interact with this one using that particular portType.
>
>But if we look "inside" the Purchase Order Web service itself, we find out that it also interacts with other "internal" Web services, i.e. the Invoice, Scheduling and Shipping Web services (by sending messages to those Web services and by receiving messages from them on its invoiceCallbackPT and shippingCallbackPT portTypes - all these message exchanges being controlled by the BPEL process itself). So we can in principle describe these four Web services and their interactions using another choreography. And this latter choreography composes (i.e. interacts) with the former one via messages exchanged over the purchaseOrderPT portType.
>
>Ugo
>
> 
>  
>
Received on Wednesday, 16 July 2003 22:11:10 GMT

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