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中遇到编排，而编排更多地是一个学术概念和一个研究主题。我们经常在不知情的情况下编舞，就像在现实世界中一样。

One can use both choreography and orchestration is the same system as we have done in our product. Various actors performing various tasks dispatched to them are choreographed by the event pub/sub system via events they generate. For example, when a prime mover carrying a container arrives at a warehouse, that event, which is subscribed by the warehouse manager app, prompts the warehouse manager to activate the resources to unload the cargo. But when exceptions happen, such as the forklift to carry the load breaks down, that event starts an orchestration engine (a workflow processor) to orchestrate the task for various actors as per the exception handling workflow to handle the exception.

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在评论中指出这一点。

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中遇到编排，而编排更多地是一个学术概念和一个研究主题。我们经常在不知情的情况下编舞，就像在现实世界中一样。

基本技术(如XML、SOAP、WSDL)提供了将服务作为实体来描述、定位和调用的方法。然而，这些技术并没有提供关于服务在更复杂的协作中的角色的丰富行为细节。此协作包括一系列活动和活动之间的关系，这些活动和关系构建业务流程。有两种方法构建此流程:服务编制和服务编排。

服务编制

服务编制表示一个集中的可执行业务流程(编配器)，用于协调不同服务之间的交互。协调器负责调用和组合服务。

所有参与服务之间的关系由单个端点(即组合服务)描述。编制包括管理各个服务之间的事务。业务流程为服务组合采用集中式方法。

服务编排

服务编排是参与服务的全局描述，由两个或多个端点之间的消息交换、交互规则和协议定义。编排为服务组合使用了分散的方法。

编排描述了多个服务之间的交互，其中编排表示从一方的角度进行控制。这意味着编排与编排在控制所涉及服务之间交互的逻辑应该驻留的位置上有所不同。

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

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