另一种看待服务编排与编排的方法:

—服务编排:围绕业务域。 —服务编排:在多个业务域之间。

Andrei和其他人很好地解释了什么是编排，什么是编排。对于软件架构师在这两种选择之间进行选择，比较它们的不同质量也是很重要的。

配器优于舞蹈编排

Reliability: Orchestration platforms have built-in support for error handling and transaction management (compensating transactions). In choreography, custom-developed workflow and error handling tends to be more error-prone. Also, choreography is often event-driven and much of the processing is asynchronous. Therefore, choreography may require undo/correction events that add complexity to the solution. Modifiability: Creating and changing process workflows and complex service compositions is easier in the visual BPM tools found in orchestration platforms. You gain in "process visibility".

编舞优于编曲

性能:由于工作流脚本解释和编制平台本身的附加层，编制会引起性能开销。 成本:编排不需要额外的中间件或语言，它们有相关的学习曲线和治理负担。

EDIT

如果编配器元素没有采用高可用性机制，编配解决方案可能会引入SPOF。谢谢@Deepak在评论中指出这一点。

我认为编排在内部非常适合高度分散的组织。您不需要中央业务流程执行器。这有利于每个组织子单元的独立成长和发展。

(我赞同编配与编排问题的解释: http://geekexplains.blogspot.com/2008/07/ways-of-combining-web-services.html)

服务可以区分为原子服务和由其他服务组成的服务。这样的作曲被称为“配器”。有时是工作流，有时是业务流程。例如，BPEL是一种编排语言，但自称为“业务流程执行语言”。

没有要求服务必须按层次结构组合。这意味着两个服务可以相互通信。在它们之间运行的协议被称为“编排”。它可能是两个服务，但通常会涉及两个以上的服务。编排中的每个服务都可以视为伙伴服务的编排器。参与编排的每个服务都可以实现为编排/工作流/流程。

编制显示每个服务的完整行为，而编排则组合每个服务的接口行为描述。

一篇区分编排、接口行为、提供者行为和编排的优秀科学文章如下: 杜马。面向服务的设计:一个多视角的方法。国际合作信息系统杂志，2004,13,337-368

当您可以控制流程中的所有参与者时——当它们都在一个控制域中并且您可以指定活动流时，编排非常有用。当然，当您指定将在您拥有控制权的组织内部实施的业务流程时，这是最常见的情况。

编排是一种指定两个或多个参与方如何协调其活动和过程以共享信息和价值的方法——其中任何一方都不能控制其他参与方的过程，或者可能对这些过程没有任何可见性。当需要跨控制/可见性领域进行协调时，使用编排。在一个简单的场景中，您可以把编排想象成一个网络协议。它规定了各方之间可接受的请求和响应模式。

Service orchestration: you put together several services by a fixed logic. This logic is described at a single place. You can imagine a team of people with a manager doing micro-management. The manager precisly tells what, when and who should do. The team members do not care of the entire goal of the job, the manager combines the outputs into a single deliverable. A practical example is a BPEL process. BPEL process contains the logic, can invoke several services and combine their responses into a single service response.

Service choreography: the decision logic is distributed, with no centralized point. You can imagine a home, where everybody aims for the common good and works pro-actively without micro-management. Or you can imagine a human body, where different members are interdependent and work for the common goal. A practical example is event driven processing, where an agent is activated by an event and does its job. All the agents make a system together. There is no centralized logic. Choreography possibilities may go farther beyond orchestration as it is more aligned with the real world.

我的观点是，我们不需要对这两者进行太多区分，因为我们需要关注业务逻辑。在单点逻辑可以完成工作的地方，我们进行编排。如果一个问题不能被集中的逻辑覆盖，我们就不得不编排。这就是为什么我们经常在IT中遇到编排，而编排更多地是一个学术概念和一个研究主题。我们经常在不知情的情况下编舞，就像在现实世界中一样。