Hi Walt,
This is a good question that is often
asked and its clear there is some way to go to make the definitions stick. I cc
the OASIS SEE list in case there are differing opinions.
In the context of WSMO descriptions of
Semantic Web services both choreography and orchestration descriptions are two
aspects of describing the interface of a Web service or Goal. (The definitions
below focus on Web services but hey also hold for Goals. An aid to
understanding why they apply to Goals is to consider them as proxies for Web
services that may be resolved at run-time).
In WSMO chorography is the description of
the public interface a service provides to its potential clients. It defines
the concepts that form the content of messages sent in and out of the service and
it describes the control flow that governs when messages are sent or expected
to be received. The Choreography box in the proposed figure 2 is intended as a
consumer of choreography descriptions that can take such a description,
interpret and execute it (Choreography Engine may be a better label).
Taking the well-worn purchase order
scenario as an example. An car-parts shop may provide a service for ordering
parts. The service’s choreography might describe that it expected an
incoming message containing an instance of a purchase order (PO)
concept (as defined in a specific ontology) and an outgoing message containing
an instance of a purchase order acknowledgement (POA) concept. The control
flow, described in the choreography, would tell potential clients of this
service that a POA would be sent after a PO
was received. The choreography would say nothing about what the service did to
fulfil the order between receiving the PO and
dispatching the POA.
In WSMO, an orchestration is the
description of how a Web service uses other services to achieve its
functionality. It is the description of a service interface from the
perspective of other services that may be used by the orchestration to achieve
its overall functionality. For example, on receipt of a PO
the car-parts service, from the example above, may follow the following simple process.
First it checks its own stock for the required part. If it is out-of-stock, it
uses a third-party MAKE-PARTS service to order the part. Once the part is
received at the shop, it uses another third-part SHIP-PARTS service to ship the
part to the customer. Finally it sends the POA message. The car-parts service may
choose to publish an orchestration description that identifies the descriptions
of the two third party services it uses in its process. Why? Because it may
want to advertise the fact that he needs these two services. In WSMO, an even
more useful scenario is that the orchestration describes this process using
Goal, rather than service, descriptions so that each Goal can be matched to the
most suitable service as it is needed (ideally at run-time). This allows
greater flexibility for adjusting processes as service requesters and providers
are not hard-wired at design time.
Thanks,
Matt
From: Walt Truszkowski
[mailto:Walt.Truszkowski@nasa.gov]
Sent: 14 September 2006 15:43
To: Matthew Moran
Subject: Re: [semantic-ex]
Proposal for fig 2. of architecture document
Dear Matt,
Your diagram looks interesting.
What is the difference between "orchestration" and
"choreography"/
Walt
At 04:45 AM 9/14/2006, you wrote:
Hi,
The attached image is a proposal for replacing Figure 2. SEE Infrastructure in
the SEE Architecture document. My drawing could definitely be improved but I
wanted to get the idea sent out before the phone-con. I’d like to discuss
this today – Mick could you add to the agenda.
The differences are small but I believe important. Essentially, I don’t
believe the problem solving layer should be shown as part of the SEE
architecture but I do believe that we need to show somehow that semantics are
necessary throughout the SEE architecture.
The concept of a problem solving layer and its functionality is important but I
think it’ not in the scope of this document. I don’t think we ever
intended to describe the details of developer tools or applications or domain
ontologies? I believe that we have to be able to describe clearly whatever we include
in this figure.
I’m also including ‘orchestration’ as I believe its not
covered by the ‘composition’. My thinking is that we separate the
functions of composing and executing an orchestration of services (or goals).
The composition component can generate an orchestration description while the
orchestration component executes orchestration descriptions.
Thanks,
Matt
--------------------------------------------------------
Matthew
Moran
Digital Enterprise Research
Institute
Phone: +353
91 49 5017
Mobile : +353
86 196 5648
Fax:
+353 91 49 5541
DERI Web: http://www.deri.ie
Homepage: http://sws.deri.ie/members/matt
--------------------------------------------------------