编排与编舞
从组织内的angular度来看，服务编排和服务编排有什么不同？
诸如（XML，SOAP，WSDL）等基本技术提供了将服务描述，定位和调用为一个实体的方法。 然而，这些技术并没有给出关于服务在更复杂的协作中的作用的丰富的行为细节。 这种协作包括一系列活动之间的活动和关系，build立业务stream程。 有两种方法来构build这个过程：服务编排和服务编排。
服务编排
服务编排表示协调不同服务之间交互的单个集中式可执行业务stream程（编排器）。 协调者负责调用和组合服务。
所有参与服务之间的关系由单个端点（即组合服务）来描述。 编配包括pipe理各项服务之间的交易。 编排采用集中的方式进行服务组合。
服务编排
服务编排是对参与服务的全局描述，由两个或多个端点之间的消息交换，交互规则和协议定义。 编排采用分散的方法来进行服务组合。
编排描述了多个服务之间的交互，其中协调代表了一方的控制。 这意味着编排 与 编排的 区别在于控制所涉及的服务之间的交互的逻辑应该驻留在何处。
服务可以区分primefaces服务和由其他服务组成的服务。 这样的组合被称为“协调”。 有时候工作stream程，有时是业务stream 例如，BPEL是一种编排语言，但是自称“业务stream程执行语言”。
没有要求服务需要分级组成。 这意味着，两个服务可以相互交谈。 在它们之间运行的协议被称为“编排”。 这可能是两个服务，但通常涉及两个以上的服务。 编排中的每项服务都可能被视为合作伙伴服务的协调者。 参与编排的每个服务可以被实现为编排/工作stream程/处理。
编排显示每个服务的完整行为，而编排结合了每个服务的界面行为描述。
一个好的科学文章，区分编排，界面行为，提供者的行为和协调是以下一个： Dijkman，R。和杜马斯M.面向服务的devise：多观点的方法国际合作信息系统杂志，2004年13月， 337-368
服务编排 ：你用一个固定的逻辑把几个服务放在一起。 这个逻辑在一个地方描述。 你可以想象一个有经理的团队正在进行微观pipe理。 经理精确地告诉什么，什么时候和谁应该做什么。 团队成员不关心整个工作的目标，经理将产出结合成一个单一的可交付成果。 一个实际的例子是一个BPELstream程。 BPELstream程包含逻辑，可以调用多个服务，并将其响应组合成一个服务响应。
服务编排 ：决策逻辑是分布式的，没有集中点。 你可以想象一个家庭，每个人都为公共利益而努力，并且在没有微观pipe理的情况下积极主动地工作。 或者你可以想象一个人体，不同的成员是相互依赖的，为共同的目标而工作。 一个实际的例子是事件驱动的处理，一个代理被一个事件激活并完成其工作。 所有的代理人一起制造一个系统。 没有集中的逻辑。 编舞的可能性可能会超越协调，因为它与现实世界更加一致。
我的意见是，我们不需要区分这两者，因为我们需要关注业务逻辑。 在一个单一的逻辑点做的工作，我们做编排。 如果一个问题不能被中央逻辑所覆盖，我们就不得不进行编排。 这就是为什么我们经常在IT方面进行协调的原因，而choreograhy仍然是一个学术概念和研究课题。 我们经常在没有真正知道的情况下进行舞蹈编排，就像在现实世界中一样。
既然线程已经老了，但是仍然写信给那些像我一样在这里寻找这个问题的人。 这在面向服务的体系结构 （SOA）中有很多争议，对于初学者来说，这需要更清晰的解释。
编排：可执行的过程
- 用于私人业务stream程
- 一个中央进程（可以是另一个Web服务）负责控制相关的Web服务，并协调操作中涉及的Web服务的不同操作的执行
- 涉及的Web服务并不知道他们参与到合成过程中，而且他们正在参与更高级的业务stream程。
- 只有编配的中央协调员才知道这个目标，因此编排集中在操作的明确定义和Web服务的调用顺序上。
编排：多方合作
-
相比之下，舞蹈编排并不依赖中央协调员。 相反，参与编排的每个Web服务都知道何时执行操作以及与谁进行交互。 编排是一个专注于公共业务stream程中消息交换的协作性工作。
-
编排中的所有参与者都需要了解业务stream程，执行操作，交换消息以及消息交换的时间。
编排与协调
-
从编写Web服务来执行业务stream程的angular度来看，编排是一个更灵活的范例，与编排相比具有以下优点：
-
组件过程的协调由一个已知的协调员进行集中pipe理。
-
Web服务可以在没有意识到他们正在参与更大的业务stream程的情况下被合并。
- 如果发生故障，可以select其他scheme。
当你控制一个stream程中的所有参与者时， 协调是很有用的 – 当他们都在一个控制域，你可以指定活动的stream程。 这当然是最经常的，当你指定一个业务stream程，将在一个你可以控制的组织内制定。
编排是一种方式，可以指定两方或多方 – 其中没有任何一方能够控制其他方的stream程，或者这些stream程的可见性 – 可以协调其活动和stream程以共享信息和价值。 当需要跨控制/可见性域进行协调时，请使用编排。 在一个简单的场景中，你可以想象编舞，就像networking协议一样。 它决定了各方之间可接受的请求和回应模式。
我认为编舞非常适合高度分散的组织。 你不需要一个中央的业务stream程执行者。 这有利于每个组织单位的独立增长和发展。
（我订阅这种编排与编排问题的解释： http : //geekexplains.blogspot.com/2008/07/ways-of-combining-web-services.html ）
安德烈和其他人做了很好的解释什么是编排和什么是编舞。 对于软件架构师在这两种select之间进行select，将它们与不同的质量进行比较也很重要。
编排加强了舞蹈编排
- 可靠性：编排平台内置了对error handling和事务pipe理（补偿事务）的支持。 在编排中，定制开发的工作stream和error handling往往更容易出错。
- 可修改性：在编排平台中的可视化BPM工具中，创build和更改stream程工作stream和复杂的服务组合更为简单。
编舞加强了编排
-
性能：由于工作stream脚本解释和编排平台本身的附加层，编排会导致性能开销。
-
成本：编排不需要额外的中间件或语言，它们具有相关的学习曲线和治理负担。
在编排中，有一名指挥，还有乐器演奏者。 玩家根据指挥者的行为进行游戏。 如果更换导体，则谐波表示将会不同，即它仍然是相同的播放（服务），但具有不同的结果。 例如，为了提供财务安排build议，编配服务将通过询问（调用）每个参与者（实体或公用事业服务，例如信用检查）来根据指挥者的模板（商业活动）返回结果或调整/更新其演奏规则）。 在舞蹈编排方面，有编舞，还有一些舞者。 编排是一个方向，但是每一个舞者在如何实现这个方向上都是自主的。
编排通常将较低级别的服务联系在一起。 它就像一个中介 。 编排有助于进一步减less耦合。 我在这里更详细地解释了这一点 。
另一种看服务编排与编排的方法：
– 服务编排：围绕业务领域。
– 服务编排：在多个商业领域中。
