And*_*rei 271
诸如(XML,SOAP,WSDL)之类的基本技术提供了以其自身的形式描述,定位和调用服务作为实体的方法.但是,这些技术并未提供有关服务在更复杂的协作中的作用的丰富行为细节.此协作包括一系列活动和活动之间的关系,这些活动构建业务流程.构建此过程有两种方法:服务编排和服务编排.
服务编排
服务编排表示协调不同服务之间交互的单个集中式可执行业务流程(协调器).协调器负责调用和组合服务.
所有参与服务之间的关系由单个端点(即,组合服务)描述.业务流程包括管理各个服务之间的事务.Orchestration采用集中式方法进行服务组合.
服务编排
服务编排是参与服务的全局描述,其通过消息交换,交互规则和两个或多个端点之间的协议来定义.编排采用分散的方法进行服务组合.
编排描述了多个服务之间的交互,其中编排从一方的角度表示控制.这意味着,一个编排 不同从编排相对于其中逻辑控制涉及应驻留在服务之间的交互.
- 精彩的图像展示了两个!你从哪里得到的？ (6认同)
- @DavidMann非常感谢您的评论,如果您认为它对您有用,请立即投票.我在Visio中制作了这些图表,作为灵感,我在服务组合中使用了一些文献.但是,我意识到这个答案是2年前,当时我刚刚开始阅读有关服务组合的内容.我将用参考文献更新这个答案,并扩展两者的优点 (6认同)
- 有些读者可能从您的编排图中推断，编排意味着从控制服务到提供服务的同步调用。我想澄清一下，调用-回复通信也可以使用异步方法来完成，包括异步方法。通过消息代理。 (3认同)
Kar*_*usa 30
服务编排:您通过固定逻辑组合了多个服务.这个逻辑在一个地方描述.您可以想象一个团队的人与经理进行微观管理.经理准确地说出了什么,何时以及应该做什么.团队成员不关心工作的整个目标,经理将输出结合到一个可交付成果中.一个实际的例子是BPEL流程.BPEL流程包含逻辑,可以调用多个服务并将其响应组合到单个服务响应中.
服务编排:决策逻辑是分布式的,没有集中点.你可以想象一个家,每个人都以共同利益为目标,积极主动地工作而不需要微观管理.或者你可以想象一个人体,不同的成员是相互依存的,为共同的目标而努力.一个实际的例子是事件驱动的处理,其中代理由事件激活并完成其工作.所有代理商都在一起制作一个系统.没有集中逻辑.编排的可能性可能远远超出了编排,因为它更符合现实世界.
我的观点是,我们不需要区分这两者,因为我们需要关注业务逻辑.如果单点逻辑完成工作,我们就会进行编排.如果集中逻辑无法解决问题,我们无论如何都被迫编排.这就是为什么我们经常在IT中进行编排,而编舞仍然是一个学术概念和研究课题.而且我们经常在没有实际知识的情况下进行舞蹈编排,就像在现实世界中一样.
kop*_*por 21
可以区分原子服务和由其他服务组成的服务之间的服务.这种组合物称为"编排".有时工作流,有时是业务流程.例如,BPEL是一种编排语言,但称其为"业务流程执行语言".
不要求服务需要按层次结构组成.这意味着,两个服务可以相互通信.它们之间运行的协议称为"编排".它可能是两种服务,但通常涉及两种以上的服务.编排中的每项服务都可以被视为合作伙伴服务的协调者.参与编排的每个服务可以实现为编排/工作流程/过程.
业务流程显示了每个服务的完整行为,而编排结合了每个服务的接口行为描述.
区分编排,界面行为,提供者行为和编排的一篇好的科学文章如下: Dijkman,R.&Dumas,M.面向服务的设计:多视角方法国际合作信息系统期刊,2004,13, 337-368
Cyc*_*3x3 15
由于线程已经陈旧,但仍然写信给那些在我这里偶然发现这个问题的人.这是面向服务架构(SOA)中备受争议的问题,它需要为初学者提供更清晰的解释.
业务流程:可执行流程
- 用于私人业务流程
- 中央进程(可以是另一个Web服务)控制所涉及的Web服务,并协调对操作中涉及的Web服务的不同操作的执行
- 涉及的Web服务不"知道"(并且不需要知道)他们参与合成过程并且他们参与更高级别的业务过程.
- 只有业务流程的中央协调员才知道这个目标,因此业务流程集中了操作的明确定义和Web服务调用的顺序.
编排:多方协作
相反,编舞不依赖于中央协调员.相反,编排中涉及的每个Web服务都准确地知道何时执行其操作以及与谁进行交互.编排是一项协作工作,专注于公共业务流程中的消息交换.
编排中的所有参与者都需要了解业务流程,要执行的操作,要交换的消息以及消息交换的时间.
编排与编排
从组合Web服务到执行业务流程的角度来看,编排是一种更灵活的范例,并且与编排相比具有以下优势:
组件流程的协调由已知的协调员集中管理.
可以合并Web服务,而不必意识到他们正在参与更大的业务流程.
- 如果发生故障,可以采用替代方案.
- 不要关注@RodneyP.Barbati。减轻依赖脆弱性的异步消息总线如何等同于中央协调器。消息代理是完全愚蠢的，并且不知道任何可能依赖它的进程。 (3认同)
- 除了总线不协调任何事情之外，恰恰相反：事件和消费服务形成了总线对此毫无概念的编排。https://solace.com/blog/microservices-choreography-vs-orchestration/ (3认同)
- 实际上，编排通常确实依赖于中央协调器 - 通常该协调器是某种形式的分布式消息代理。不使用消息代理之类的东西会以非常不灵活的方式将您的服务捆绑在一起，从而导致脆弱性和低可重用性。 (2认同)
我会说编舞非常适合内部高度分散的组织。您不需要中央业务流程执行程序。这有利于每个组织子单位的独立成长和发展。
（我订阅了这种对编排与编舞问题的解释：http : //geekexplains.blogspot.com/2008/07/ways-of-combining-web-services.html）
Andrei和其他人在解释什么是编排和什么是编排方面做得很好。对于在这两种选择之间进行选择的软件架构师，将它们在不同质量方面进行比较也很重要。
编排优于编排
- 可靠性：业务流程平台内置了对错误处理和事务管理（补偿事务）的支持。在编排中，自定义开发的工作流和错误处理往往更容易出错。
- 可修改性：在业务流程平台中的可视化BPM工具中，创建和更改流程工作流以及复杂的服务组合变得更加容易。
编排优于编排
性能：由于工作流程脚本的解释和业务流程平台本身的附加层，业务流程会产生性能开销。
成本：编舞不需要额外的中间件或语言，而中间件或语言具有相关的学习曲线和治理负担。
- 编排是否会带来单点故障的缺点，而编排则不会出现这种情况？ (4认同)
- 到目前为止，编排器的最大优点是流程的透明度，而对于编排，流程通常根本不清晰，除非有全面的文档可用（通常没有）。例如，事件驱动的流程（编排）具有很大的优势，但如果有时弄清楚流程如何流动并不是一个完整的难题，那该死的。 (4认同)
- 除了编排确实需要其他中间件。需求（任务）需要匹配到不同的节点。之后，编排，制定，监控和调整编排。所有这些管理都需要通常由中间件提供的工具。 (2认同)
当您控制流程中的所有参与者时,编排很有用 - 当他们都在一个控制域中时,您可以指定活动流.当然,当您指定将在您可以控制的一个组织内部制定的业务流程时,这通常是最常见的.
编排是一种指定两个或更多方的方式 - 无论如何都无法控制其他方的过程,或者可能是对这些过程的任何可见性 - 可以协调其活动和过程以共享信息和价值.当需要跨控制/可见性域协调时,请使用编排.在简单的场景中,您可以将编排想象为网络协议.它规定了各方之间可接受的请求和响应模式.