+1 On 20 Jul 2006, at 17:20, Frank Leymann wrote:
> 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 > > 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 > > > > > > > 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> > > > > ------------------------ Yahoo! Groups Sponsor --------------------~--> See what's inside the new Yahoo! Groups email. http://us.click.yahoo.com/2pRQfA/bOaOAA/yQLSAA/NhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
