In BPEL we distinguish between "executable" processes and "abstract" processes. An abstract process is typically *not* executable, but is -for various kinds of purposes- "vague" on some aspects.
In that sense, I would disagree with this aspect of the quoted definition of "orchestration".
One distinction between orchestration and choreography is that orchestration always deals with describing ordering aspects of the message exchange of ONLY ONE of the partners involved. While choreography in general takes care about "gluing together" the ordering aspects of MORE THAN ONE partners. Stated otherwise, orchestration is focussed on a single partner - considering other partners only as "helper" services to satisfy the single partners goal. Choreography is focussed on weaving the ordering aspects of all affected partners together. In that sense, a Choreography is the "glue" between the individual orchestrations describing each partner.
Thus, I agree with what Paul says a bit less verbous ;-)
----- Ursprüngliche Mail ----
Von: Steve Ross-Talbot <[EMAIL PROTECTED]>
An: [email protected]
Gesendet: Donnerstag, den 20. Juli 2006, 00:31:59 Uhr
Betreff: Re: [service-orientated-architecture] Orchestration, Choreography, and Composition
Von: Steve Ross-Talbot <[EMAIL PROTECTED]>
An: [email protected]
Gesendet: Donnerstag, den 20. Juli 2006, 00:31:59 Uhr
Betreff: Re: [service-orientated-architecture] Orchestration, Choreography, and Composition
I don't what the group thinks of a definitive source for a definition
but this is from W3C.
Maybe not a recommendation but it is as close as we will probably ever
get:
choreography
A choreography is a description of a multi-party contract that
describes from a global view point the external observable behavior
across multiple cooperating clients (which are generally Web services
but not exclusively so) in which external observable behavior is
defined as the those interactions that are externally observable
between Web Services and their clients. (i.e. a choreography is a
description of the externally observable interactions and associated
externally visible state that makes up a contract in which the
participating Web Services adhere to and can be demonstrated to have
done so by using the description.). [WSC Reqs]
orchestration
An orchestration defines the sequence and conditions in which one Web
service invokes other Web services in order to realize some useful
function. (i.e., an orchestration is an executable description of the
pattern of interactions and the conditions that must exist for those
interactions to take place that are both internally and externally
observable that a Web service agent must follow in order to achieve its
goal.
This was as a result of a long and painful dialogue over many months
with Web Services Architecture and then post WSA with the Web Services
lead at W3C.
Cheers
Steve T
On 19 Jul 2006, at 11:58, Paul Fremantle wrote:
> Todd
>
> I like this blog entry from Paul Downey:
> http://blog.whatfettle.com/archives/000250.html
>
> My take on choreography and orchestration is simple. I think
> orchestration is how *I* go about composing services, and choregraphy
> is how *we* go about working together. Maybe that's too simple!
>
> Paul
>
> On 7/19/06, Todd Biske <[EMAIL PROTECTED]> wrote:
> > In a conversation with a colleague on process orchestration and
> > composite services, he asked whether there were any good definitions
> > that would accurately describe the relationship between them. In my
> > brief google-hunt, I didn't really find any clear, concise
> > definitions, and I also threw choreography into the mix as another
> > term frequently used in similar contexts. I did find one whitepaper
> > from someone at Oracle that characterized the difference between
> > Orchestration and Choreography based upon whether a central
> > controller (orchestrator) was used or not.
> >
> > While the definitions may have been simple at one point, I think the
> > contention around BPEL combined with the struggle of vendors to
> > categorize the infrastructure in this space (EAI, MOM, ESB, BPM,
> > Composite Development Environments, XML Gateways) have muddied the
> > waters. For example, if I use a tool from the BPM space, such as
> > Microsoft BizTalk or Tibco BusinessWorks, to build a service which
> > pulls data from three other services and returns some composition of
> > the data, a very simple composite service, is that also a process
> > orchestration?
> >
> > I thought I'd turn this into a group exercise and see how all of you
> > define it. Here are my thoughts (not so much a definition) to get us
> > started.
> >
> > Process orchestration involves a conscious effort to externalize the
> > process from the underlying tasks that constitute the process. It
> > should encompass both human and system tasks, and therefore, must
> > support the notion of "wait" states in the orchestration (e.g. wait
> > for human to do this, wait for JMS message). Orchestration can be
> > delegated to subprocesses, meaning tooling must support the notion
> of
> > process composition. This is a key component in supporting "wait"
> > states, as processes always begin with a wait state. One way of
> > implementing this would be to create separate orchestrations for
> each
> > sub-process so that waits always occur at the beginning. If tooling
> > doesn't support composition, however, the macro view of the true
> > process will be lost.
> >
> > Service composition is an effort to take the capabilities of two or
> > more services and expose the combined capabilities as a more coarse-
> > grained service. Typically, the act of composition will require some
> > manipulation of the output of the constituent services which is
> > performed by the composite service. While orchestration tools can
> > also perform this, as typically a process maintains contextual
> > information that is shared among the individual tasks, service
> > composition does not represent a conscious effort to externalize the
> > process itself. Therefore, the perceived overlap between
> > orchestration and composition is more to due to shared capabilities
> > of the tooling than a relationship between the two concepts.
> >
> > Process choreography is similar to process orchestration in that it
> > is concerned with the execution of a business process. The
> > difference between them lies in the control over the execution. A
> > choreographed approach can, at best, monitor the process execution,
> > but not directly influence it, since there is no centralized
> > controller. An orchestrated approach relies upon a centralized
> > controller to execute the tasks associated with the project. An
> > analogy is that of a symphony. An orchestrated approach requires a
> > conductor to cue the individual musicians, keep time, etc. A
> > choreographed approach would simply give each musician the sheet
> > music, letting them rely solely on their own knowledge of when to
> > play. External monitoring is available in both cases, i.e. the
> > audience.
> >
> > Thoughts? Are there definitions in the OASIS SOA-RM? If not, I'd be
> > happy to help contribute. I just didn't join that TC since their
> > efforts were well underway when I finally convinced my employer to
> > join OASIS.
> >
> > -tb
> >
> >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> [EMAIL PROTECTED]
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
>
>
but this is from W3C.
Maybe not a recommendation but it is as close as we will probably ever
get:
choreography
A choreography is a description of a multi-party contract that
describes from a global view point the external observable behavior
across multiple cooperating clients (which are generally Web services
but not exclusively so) in which external observable behavior is
defined as the those interactions that are externally observable
between Web Services and their clients. (i.e. a choreography is a
description of the externally observable interactions and associated
externally visible state that makes up a contract in which the
participating Web Services adhere to and can be demonstrated to have
done so by using the description.). [WSC Reqs]
orchestration
An orchestration defines the sequence and conditions in which one Web
service invokes other Web services in order to realize some useful
function. (i.e., an orchestration is an executable description of the
pattern of interactions and the conditions that must exist for those
interactions to take place that are both internally and externally
observable that a Web service agent must follow in order to achieve its
goal.
This was as a result of a long and painful dialogue over many months
with Web Services Architecture and then post WSA with the Web Services
lead at W3C.
Cheers
Steve T
On 19 Jul 2006, at 11:58, Paul Fremantle wrote:
> Todd
>
> I like this blog entry from Paul Downey:
> http://blog.whatfettle.com/archives/000250.html
>
> My take on choreography and orchestration is simple. I think
> orchestration is how *I* go about composing services, and choregraphy
> is how *we* go about working together. Maybe that's too simple!
>
> Paul
>
> On 7/19/06, Todd Biske <[EMAIL PROTECTED]> wrote:
> > In a conversation with a colleague on process orchestration and
> > composite services, he asked whether there were any good definitions
> > that would accurately describe the relationship between them. In my
> > brief google-hunt, I didn't really find any clear, concise
> > definitions, and I also threw choreography into the mix as another
> > term frequently used in similar contexts. I did find one whitepaper
> > from someone at Oracle that characterized the difference between
> > Orchestration and Choreography based upon whether a central
> > controller (orchestrator) was used or not.
> >
> > While the definitions may have been simple at one point, I think the
> > contention around BPEL combined with the struggle of vendors to
> > categorize the infrastructure in this space (EAI, MOM, ESB, BPM,
> > Composite Development Environments, XML Gateways) have muddied the
> > waters. For example, if I use a tool from the BPM space, such as
> > Microsoft BizTalk or Tibco BusinessWorks, to build a service which
> > pulls data from three other services and returns some composition of
> > the data, a very simple composite service, is that also a process
> > orchestration?
> >
> > I thought I'd turn this into a group exercise and see how all of you
> > define it. Here are my thoughts (not so much a definition) to get us
> > started.
> >
> > Process orchestration involves a conscious effort to externalize the
> > process from the underlying tasks that constitute the process. It
> > should encompass both human and system tasks, and therefore, must
> > support the notion of "wait" states in the orchestration (e.g. wait
> > for human to do this, wait for JMS message). Orchestration can be
> > delegated to subprocesses, meaning tooling must support the notion
> of
> > process composition. This is a key component in supporting "wait"
> > states, as processes always begin with a wait state. One way of
> > implementing this would be to create separate orchestrations for
> each
> > sub-process so that waits always occur at the beginning. If tooling
> > doesn't support composition, however, the macro view of the true
> > process will be lost.
> >
> > Service composition is an effort to take the capabilities of two or
> > more services and expose the combined capabilities as a more coarse-
> > grained service. Typically, the act of composition will require some
> > manipulation of the output of the constituent services which is
> > performed by the composite service. While orchestration tools can
> > also perform this, as typically a process maintains contextual
> > information that is shared among the individual tasks, service
> > composition does not represent a conscious effort to externalize the
> > process itself. Therefore, the perceived overlap between
> > orchestration and composition is more to due to shared capabilities
> > of the tooling than a relationship between the two concepts.
> >
> > Process choreography is similar to process orchestration in that it
> > is concerned with the execution of a business process. The
> > difference between them lies in the control over the execution. A
> > choreographed approach can, at best, monitor the process execution,
> > but not directly influence it, since there is no centralized
> > controller. An orchestrated approach relies upon a centralized
> > controller to execute the tasks associated with the project. An
> > analogy is that of a symphony. An orchestrated approach requires a
> > conductor to cue the individual musicians, keep time, etc. A
> > choreographed approach would simply give each musician the sheet
> > music, letting them rely solely on their own knowledge of when to
> > play. External monitoring is available in both cases, i.e. the
> > audience.
> >
> > Thoughts? Are there definitions in the OASIS SOA-RM? If not, I'd be
> > happy to help contribute. I just didn't join that TC since their
> > efforts were well underway when I finally convinced my employer to
> > join OASIS.
> >
> > -tb
> >
> >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> [EMAIL PROTECTED]
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
>
>
I don't what the group thinks of a definitive source for a definition
but this is from W3C.
Maybe not a recommendation but it is as close as we will probably ever
get:
<bold><bigger>choreography</bigger></bold>
<italic>A choreography is a description of a multi-party contract that
describes from a global view point the external observable behavior
across multiple cooperating clients (which are generally Web services
but not exclusively so) in which external observable behavior is
defined as the those interactions that are externally observable
between Web Services and their clients. (i.e. a choreography is a
description of the externally observable interactions and associated
externally visible state that makes up a contract in which the
participating Web Services adhere to and can be demonstrated to have
done so by using the description.). [WSC Reqs]
</italic>
<bold><bigger>orchestration</bigger></bold>
<italic>An orchestration defines the sequence and conditions in which
one Web service invokes other Web services in order to realize some
useful function. (i.e., an orchestration is an executable description
of the pattern of interactions and the conditions that must exist for
those interactions to take place that are both internally and
externally observable that a Web service agent must follow in order to
achieve its goal.
</italic>
This was as a result of a long and painful dialogue over many months
with Web Services Architecture and then post WSA with the Web Services
lead at W3C.
Cheers
Steve T
On 19 Jul 2006, at 11:58, Paul Fremantle wrote:
<excerpt>Todd
I like this blog entry from Paul Downey:
http://blog.whatfettle.com/archives/000250.html
My take on choreography and orchestration is simple. I think
orchestration is how *I* go about composing services, and choregraphy
is how *we* go about working together. Maybe that's too simple!
Paul
On 7/19/06, Todd Biske <<[EMAIL PROTECTED]> wrote:
> In a conversation with a colleague on process orchestration and
> composite services, he asked whether there were any good definitions
> that would accurately describe the relationship between them. In my
> brief google-hunt, I didn't really find any clear, concise
> definitions, and I also threw choreography into the mix as another
> term frequently used in similar contexts. I did find one whitepaper
> from someone at Oracle that characterized the difference between
> Orchestration and Choreography based upon whether a central
> controller (orchestrator) was used or not.
>
> While the definitions may have been simple at one point, I think the
> contention around BPEL combined with the struggle of vendors to
> categorize the infrastructure in this space (EAI, MOM, ESB, BPM,
> Composite Development Environments, XML Gateways) have muddied the
> waters. For example, if I use a tool from the BPM space, such as
> Microsoft BizTalk or Tibco BusinessWorks, to build a service which
> pulls data from three other services and returns some composition of
> the data, a very simple composite service, is that also a process
> orchestration?
>
> I thought I'd turn this into a group exercise and see how all of you
> define it. Here are my thoughts (not so much a definition) to get us
> started.
>
> Process orchestration involves a conscious effort to externalize the
> process from the underlying tasks that constitute the process. It
> should encompass both human and system tasks, and therefore, must
> support the notion of "wait" states in the orchestration (e.g. wait
> for human to do this, wait for JMS message). Orchestration can be
> delegated to subprocesses, meaning tooling must support the notion
of
> process composition. This is a key component in supporting "wait"
> states, as processes always begin with a wait state. One way of
> implementing this would be to create separate orchestrations for
each
> sub-process so that waits always occur at the beginning. If tooling
> doesn't support composition, however, the macro view of the true
> process will be lost.
>
> Service composition is an effort to take the capabilities of two or
> more services and expose the combined capabilities as a more coarse-
> grained service. Typically, the act of composition will require some
> manipulation of the output of the constituent services which is
> performed by the composite service. While orchestration tools can
> also perform this, as typically a process maintains contextual
> information that is shared among the individual tasks, service
> composition does not represent a conscious effort to externalize the
> process itself. Therefore, the perceived overlap between
> orchestration and composition is more to due to shared capabilities
> of the tooling than a relationship between the two concepts.
>
> Process choreography is similar to process orchestration in that it
> is concerned with the execution of a business process. The
> difference between them lies in the control over the execution. A
> choreographed approach can, at best, monitor the process execution,
> but not directly influence it, since there is no centralized
> controller. An orchestrated approach relies upon a centralized
> controller to execute the tasks associated with the project. An
> analogy is that of a symphony. An orchestrated approach requires a
> conductor to cue the individual musicians, keep time, etc. A
> choreographed approach would simply give each musician the sheet
> music, letting them rely solely on their own knowledge of when to
> play. External monitoring is available in both cases, i.e. the
> audience.
>
> Thoughts? Are there definitions in the OASIS SOA-RM? If not, I'd be
> happy to help contribute. I just didn't join that TC since their
> efforts were well underway when I finally convinced my employer to
> join OASIS.
>
> -tb
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
[EMAIL PROTECTED]
"Oxygenating the Web Service Platform", www.wso2.com
</excerpt>
but this is from W3C.
Maybe not a recommendation but it is as close as we will probably ever
get:
<bold><bigger>choreography</bigger></bold>
<italic>A choreography is a description of a multi-party contract that
describes from a global view point the external observable behavior
across multiple cooperating clients (which are generally Web services
but not exclusively so) in which external observable behavior is
defined as the those interactions that are externally observable
between Web Services and their clients. (i.e. a choreography is a
description of the externally observable interactions and associated
externally visible state that makes up a contract in which the
participating Web Services adhere to and can be demonstrated to have
done so by using the description.). [WSC Reqs]
</italic>
<bold><bigger>orchestration</bigger></bold>
<italic>An orchestration defines the sequence and conditions in which
one Web service invokes other Web services in order to realize some
useful function. (i.e., an orchestration is an executable description
of the pattern of interactions and the conditions that must exist for
those interactions to take place that are both internally and
externally observable that a Web service agent must follow in order to
achieve its goal.
</italic>
This was as a result of a long and painful dialogue over many months
with Web Services Architecture and then post WSA with the Web Services
lead at W3C.
Cheers
Steve T
On 19 Jul 2006, at 11:58, Paul Fremantle wrote:
<excerpt>Todd
I like this blog entry from Paul Downey:
http://blog.whatfettle.com/archives/000250.html
My take on choreography and orchestration is simple. I think
orchestration is how *I* go about composing services, and choregraphy
is how *we* go about working together. Maybe that's too simple!
Paul
On 7/19/06, Todd Biske <<[EMAIL PROTECTED]> wrote:
> In a conversation with a colleague on process orchestration and
> composite services, he asked whether there were any good definitions
> that would accurately describe the relationship between them. In my
> brief google-hunt, I didn't really find any clear, concise
> definitions, and I also threw choreography into the mix as another
> term frequently used in similar contexts. I did find one whitepaper
> from someone at Oracle that characterized the difference between
> Orchestration and Choreography based upon whether a central
> controller (orchestrator) was used or not.
>
> While the definitions may have been simple at one point, I think the
> contention around BPEL combined with the struggle of vendors to
> categorize the infrastructure in this space (EAI, MOM, ESB, BPM,
> Composite Development Environments, XML Gateways) have muddied the
> waters. For example, if I use a tool from the BPM space, such as
> Microsoft BizTalk or Tibco BusinessWorks, to build a service which
> pulls data from three other services and returns some composition of
> the data, a very simple composite service, is that also a process
> orchestration?
>
> I thought I'd turn this into a group exercise and see how all of you
> define it. Here are my thoughts (not so much a definition) to get us
> started.
>
> Process orchestration involves a conscious effort to externalize the
> process from the underlying tasks that constitute the process. It
> should encompass both human and system tasks, and therefore, must
> support the notion of "wait" states in the orchestration (e.g. wait
> for human to do this, wait for JMS message). Orchestration can be
> delegated to subprocesses, meaning tooling must support the notion
of
> process composition. This is a key component in supporting "wait"
> states, as processes always begin with a wait state. One way of
> implementing this would be to create separate orchestrations for
each
> sub-process so that waits always occur at the beginning. If tooling
> doesn't support composition, however, the macro view of the true
> process will be lost.
>
> Service composition is an effort to take the capabilities of two or
> more services and expose the combined capabilities as a more coarse-
> grained service. Typically, the act of composition will require some
> manipulation of the output of the constituent services which is
> performed by the composite service. While orchestration tools can
> also perform this, as typically a process maintains contextual
> information that is shared among the individual tasks, service
> composition does not represent a conscious effort to externalize the
> process itself. Therefore, the perceived overlap between
> orchestration and composition is more to due to shared capabilities
> of the tooling than a relationship between the two concepts.
>
> Process choreography is similar to process orchestration in that it
> is concerned with the execution of a business process. The
> difference between them lies in the control over the execution. A
> choreographed approach can, at best, monitor the process execution,
> but not directly influence it, since there is no centralized
> controller. An orchestrated approach relies upon a centralized
> controller to execute the tasks associated with the project. An
> analogy is that of a symphony. An orchestrated approach requires a
> conductor to cue the individual musicians, keep time, etc. A
> choreographed approach would simply give each musician the sheet
> music, letting them rely solely on their own knowledge of when to
> play. External monitoring is available in both cases, i.e. the
> audience.
>
> Thoughts? Are there definitions in the OASIS SOA-RM? If not, I'd be
> happy to help contribute. I just didn't join that TC since their
> efforts were well underway when I finally convinced my employer to
> join OASIS.
>
> -tb
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
[EMAIL PROTECTED]
"Oxygenating the Web Service Platform", www.wso2.com
</excerpt>
SPONSORED LINKS
| Computer software | Computer security software | Computer software program |
| Computer fax software | Computer virus software | Discount computer software |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
