RE: Simple Choreography composition suggestion

below

> -----Original Message-----
> From: public-ws-chor-request@w3.org
> [mailto:public-ws-chor-request@w3.org]On Behalf Of Assaf Arkin
> Sent: Wednesday, July 16, 2003 6:04 PM
> To: Ugo Corda
> Cc: Fletcher, Tony; public-ws-chor@w3.org
> Subject: Re: Simple Choreography composition suggestion
>
>
>
> 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.

<martin> how do i know what is inside or outside the choreogrphy? all a we
can observe is
that a (starting) message is sent from one party to another. if i substiute
the actual instances of the
orginating party the receiving party cant tell the difference. Also there
may be many entry points, on different parties so its not the same as a
single web service described by a single wsdl.

>
> 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 Thursday, 17 July 2003 12:22:09 UTC