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

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

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

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

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

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

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

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

服务编制

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

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

服务编排

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

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

因为线程已经很老了，但仍然在为那些像我一样在这里跌跌撞撞地寻找这个问题的人写信。这在面向服务的体系结构 (SOA)中是一个很有争议的问题，初学者需要更清楚的解释。

业务流程:可执行过程

• 用于私有业务流程
• 中心进程(可以是另一个Web服务)控制 所涉及的Web服务和协调执行的不同 操作
所涉及的Web服务的所有操作 所涉及的Web服务不“知道”(也不需要知道) 它们参与了合成过程，而且确实如此 .参与更高级别的业务流程
• 只有业务流程的中央协调器知道这一点 目标，因此业务流程是通过显式定义集中的 操作和Web服务调用的顺序

编排:多方合作

相比之下，编排不依赖于中央协调器。 相反，编排中涉及的每个Web服务都确切地知道 何时执行其操作以及与谁进行交互。 编舞是一种专注于交流的协作
.公共业务流程中的消息 编排的所有参与者都需要了解业务 流程、要执行的操作、要交换的消息和定时

编排与编排

• 从组合Web服务执行业务的角度来看 流程、编排是一种更灵活的范式，并且具有 与编排相比，以下优点:

• 组件进程的协调由a集中管理 李协调员。< / p > < / > Web服务可以在它们不知道它们的情况下被合并

• 在出现故障时，可以设置备用场景。

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

配器优于编舞

• 可靠性:编排平台有内置的错误处理和事务管理支持(补偿事务)。在编排中，定制开发的工作流和错误处理往往更容易出错。此外，编排通常是事件驱动的，许多处理都是异步的。因此，编排可能需要撤销/更正事件，这增加了解决方案的复杂性。
• 在编排平台中的可视化BPM工具中，创建和更改流程工作流和复杂的服务组合更容易。你获得了“过程能见度”。

编舞优于编曲

• 由于工作流脚本解释和编排平台本身的附加层，编排会引起性能开销。

• 编排不需要额外的中间件或语言，它们有相关的学习曲线和治理负担。

编辑

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

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

-服务编排:围绕业务域 —业务编排:在多个业务域中

服务编制:你通过一个固定的逻辑把几个服务放在一起。这个逻辑是在一个单独的地方描述的。你可以想象一个由经理负责微观管理的团队。经理精确地告诉我们应该做什么，什么时候做，谁应该做。团队成员不关心工作的整个目标，经理将输出整合成一个单一的可交付成果。 一个实际的例子是BPEL流程。BPEL流程包含逻辑，可以调用多个服务，并将它们的响应组合成单个服务响应

服务编排:决策逻辑是分布式的，没有中心点。你可以想象一个家庭，每个人都以共同利益为目标，积极主动地工作，没有微观管理。或者你可以想象一个人的身体，不同的成员相互依赖，为共同的目标而工作。 一个实际的例子是事件驱动处理，其中代理由事件激活并完成其工作。所有的代理一起组成一个系统。没有集中的逻辑。 编排的可能性可能远远超出编排，因为它更符合现实世界

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

编配和编排都是大规模的过程形式主义的两种哲学，即协作空间。协作空间是一个行业的正式表示，例如健康行业、食品行业、汽车行业或... .因此，在您决定编排它们或使用编排来提供对终端消费者有意义的需求之前，您应该有一些小规模的能够使用某种交流语言的服务提供者。

编排通常遵循分布式系统中著名的中间件。IT行业中一些好的工具示例可以是护符， Zapier IFTTT。您可以对所使用的服务进行集中控制、听觉、修改和故障排除。

编排比编排更分散，因为它接受更多自主的合作者。例如，比特币网络是一个称为节点的服务提供商的集合，它们共同向其服务终端消费者提供一个Defi服务，即分布式账本功能。但这没有任何集中的权力负责，并没有全网的总览。只有一个共识机构，如果受人尊敬的候选服务提供商加入网络并参与最终消费者服务提供。在任何需要攻击受信任的第三方及其副作用(如损坏)的地方，一个编排是不够的。

同样，任何行业参与者之间的任何协作都可能受到编排或编排的影响，因此我希望将示例仅限于IT行业不会造成误导。

我还可以补充一点，命名暗示了两者与舞台表演的相似之处。在管弦乐队中，如果每个乐器演奏者都跟随指挥，他/她就能与其他成员和谐相处。另一方面，类似于编舞中的舞台舞蹈，没有指挥，每个舞台舞者只与他/她的搭档协调(最好是作为同伴)，没有单一的协调领导。但两者仍然向观众呈现和谐。