博文
Web服务聚合中的Orchestration和Choreography
|||
如何进行web 服务的聚合
1 、 编制（orchestration）和编排（choreography）
随着Web Service技术的日益成熟，Web Service作为一种切实可行的能够在更大的范围内整合客户，供应商，商业合作伙伴应用的方法而流行。许多企业的很多部门都创建了各自Web Service服务，但真正的价值是企业能够在不改变这些Web Service正常运行的情况下，将这些Web Service集成起来创造出新的业务模型，以满足用户需求和不断变化的市场，为组织带来更大的价值，构建敏捷型企业。
通常已经存在于企业中的业务流程语言不能直接的支持Web Services标准，IT可以先尝试自己组织的非标准协议将Web Services组合起来。但这种方式只能是一种短期目标。就之前的经验来看，要使Web Service建设的投资得到更多的效益，采用一种标准的，开放的集成方式是必须的。编制（orchestration）和编排（choreography）是企业连通性的两种标准解决方法。
Orchestration 和Choreography的中文翻译，“编制和编排”在字面上看不出太多的差别，经常容易混淆。也的确如此，因为他们都是为了实现服务的组合，肯定有很多类似的地方，不是相矛盾的两种方式，但是编制和编排也存在很多不同点，下面我用两个比喻着重讲一下两者的区别：
比喻一：编制（Orchestration）和编排（Choreography）的字面意思，Orchestration:“管弦乐作品”；Choreography：“舞蹈术”。从这个字面上看，可以看出：管弦乐演奏由一名乐队的指挥来统一的进行指挥和控制。而舞蹈表演通常是舞蹈演员对外部感应作出响应比如音乐的响应，并且需要与舞伴的行动和表情进行配合。
比喻二：十字路口的交通控制。在这个例子中，编制（Orchestration）就好像交通信号灯，控制着车辆什么时候可以通行。而编排（Choreography）就好像是环岛，没有集中的控制，只有一系列的规则来来指明车辆在接近十字路口的时候必须要等待，直到有空间进入环岛环绕系统，然后寻找适当的时候离开。
以上的两个比喻都展示了Choreography高度依赖两件事情：
根据以上的两个比喻，我们将编制和编排总结一下：
编制（Orchestration）——面向可执行的流程：流程编制使用一个可执行的中心流程来协同内部及外部的Web Service交互。通过中心流程来控制总体的目标，涉及的操作，服务调用顺序。这种集中化管理使Web服务能够在不了解彼此影响的情况下进行添加和删除，还允许在出现错误和异常的情况下进行补偿。其结果可以看作一个新的Web Service，可以执行，只是执行的过程需要调用别的Web服务。
编制虽然是采用统一控制的方式，但是编制的状态为由里向外的方式来反映，视角集中在具体的参与者的活动。
编排（Choreography）——面向合作：更多的强调协同工作和业务合作能力，通过消息的交互序列来控制各个部分资源的交互。参与交互的资源都是对等的，没有集中的控制。
例如，在供应链方面，实施产品采购可能涉及到多家公司的定单、发货通知单和资金的交互。编排不描述每个公司如何处理操作，只描述不同公司如何彼此交互。实际上我们在具体的调用分析一个流程的时候，经常从Choreography方法开始。每一个参与的人，部门或公司会告诉我们：“如果我得到了一个文档，下面我应该做什么……然后传递给XYZ”，当他们将流程的控制权传递给操作下一步骤的人，部门或公司的时候，他们对流程的控制就结束了。当然我们可以使用这种方式来设计流程。因为这种方式的流程避免了集中控制，可以更好的被度量。缺点是对整个流程状态的控制及分析流程错误的原因是比较困难的，在一个大的公司或组织中是没有人了解谁在负责这一具体的流程。
编制虽然没有采用集中控制，但是编制的视角是从面向整个系统。
2 、 具体的标准支持
BPEL4WS（Business Process Execution Language for Web Services）：从Microsoft和IBM的XLANF和WSFL发展而来，是一种可执行语言。目前由OASIS组织发布为BPEL2.0版本。适合于服务的编制（Orchestration），此标准主要用于组织内部的业务流程管理，目前越来越多的BPM产品基于此规范实现。BPEL4WS定了支持Web Service通讯的基本活动。典型的场景如：BPEL4WS接收到一个消息开始执行流程。流程可能调用一系列的外部服务来收集数据，并且反馈给请求者。<receive>, <reply>, and <invoke>就代表了连接web服务的基本的活动。
WS-CDL (Web Service Choreography Definition Language)：专门的Web服务编排标准，由SUN, SAP,Oracle发起，目前由W3C发布。WS-CDL是一种描述多方契约的语言，有些类似WSDL扩展；可以看作是在已经存在的web service纸上的一个层面。WSCDL中的每一个活动都代表了一组工作。WSDL描述Web服务接口，WS-CDL描述Web服务间的合作。Wscdl是一种编排语言，值得注意的是WSCDL只描述了web service之间的合作活动，并没有定义一个可执行的业务流程。在WSCDL语言中没有一个参与者进行集中控制。
3、 BPEL和WS-CDL共同使用的案例
目前BPEL是最主流的web服务聚合的标准。但是一般BPEL主要用于实现可执行的业务流程，及组织内部的服务的聚合。随着SOA的逐渐发展和成熟，需要基于web service灵活的组建复合的应用及跨组织的合作，这种情况WSDL标准就比较适合。下面我们说明跨组织订单合作的WS-CDL和BPEL标准共同使用。
如何就仅仅使用BPEL来实现跨组织的合作协议，我们需要：
第一步：对于Buyer参与者设计本地的组织活动模型。
第二步：对Seller，Supplier等设计本地的组织活动模型。
然后会发现，这两个分别设计模型并不能相互很好的交互，对这两个模型的组合可能导致全局视图的缺失。
如果我们采用WSCDL标准来构建模型：可以先生成一个统一的视图，然后细分具体的参与部分。
第一步：锁定全局视图：定义buyer和seller之间的合作关系。
第二步：然后切分具体的参与者。通过WSCDL生成BPEL或Java程序。如：Buyer使用Java，Seller使用BPEL。
4、 小结：
编排和编制是与组合web服务以协同工作的两个相关的方式。这两种标准对于建立动态的，可扩展的流程是非常重要的。他们的目标是提供一系列的开放的，标准的协议来设计和执行多个Web服务的交互。
编制让我们可以更好的理解每个个体需要完成的任务。而编排关注将各个个体组合起来成为一个团队的方式，在这个团队中每个个体任务都对总体的结果进行贡献，编排能够理解一个个体与哪一另外的个体进行协同以达到总体的结果。尽管BPEL处理编排的局限性，它仍然会在SOA开发中扮演重要角色，最终随着WSCDL的发展，BPEL在大型的编排流程中可以扮演子流程的作用。
随着Web Service技术的日益成熟，Web Service作为一种切实可行的能够在更大的范围内整合客户，供应商，商业合作伙伴应用的方法而流行。许多企业的很多部门都创建了各自Web Service服务，但真正的价值是企业能够在不改变这些Web Service正常运行的情况下，将这些Web Service集成起来创造出新的业务模型，以满足用户需求和不断变化的市场，为组织带来更大的价值，构建敏捷型企业。
通常已经存在于企业中的业务流程语言不能直接的支持Web Services标准，IT可以先尝试自己组织的非标准协议将Web Services组合起来。但这种方式只能是一种短期目标。就之前的经验来看，要使Web Service建设的投资得到更多的效益，采用一种标准的，开放的集成方式是必须的。编制（orchestration）和编排（choreography）是企业连通性的两种标准解决方法。
Orchestration 和Choreography的中文翻译，“编制和编排”在字面上看不出太多的差别，经常容易混淆。也的确如此，因为他们都是为了实现服务的组合，肯定有很多类似的地方，不是相矛盾的两种方式，但是编制和编排也存在很多不同点，下面我用两个比喻着重讲一下两者的区别：
比喻一：编制（Orchestration）和编排（Choreography）的字面意思，Orchestration:“管弦乐作品”；Choreography：“舞蹈术”。从这个字面上看，可以看出：管弦乐演奏由一名乐队的指挥来统一的进行指挥和控制。而舞蹈表演通常是舞蹈演员对外部感应作出响应比如音乐的响应，并且需要与舞伴的行动和表情进行配合。
比喻二：十字路口的交通控制。在这个例子中，编制（Orchestration）就好像交通信号灯，控制着车辆什么时候可以通行。而编排（Choreography）就好像是环岛，没有集中的控制，只有一系列的规则来来指明车辆在接近十字路口的时候必须要等待，直到有空间进入环岛环绕系统，然后寻找适当的时候离开。
以上的两个比喻都展示了Choreography高度依赖两件事情：
- 协同工作；
- 详细定义的通用规则以保证协同不会导致混乱；
根据以上的两个比喻，我们将编制和编排总结一下：
编制（Orchestration）——面向可执行的流程：流程编制使用一个可执行的中心流程来协同内部及外部的Web Service交互。通过中心流程来控制总体的目标，涉及的操作，服务调用顺序。这种集中化管理使Web服务能够在不了解彼此影响的情况下进行添加和删除，还允许在出现错误和异常的情况下进行补偿。其结果可以看作一个新的Web Service，可以执行，只是执行的过程需要调用别的Web服务。
编制虽然是采用统一控制的方式，但是编制的状态为由里向外的方式来反映，视角集中在具体的参与者的活动。
编排（Choreography）——面向合作：更多的强调协同工作和业务合作能力，通过消息的交互序列来控制各个部分资源的交互。参与交互的资源都是对等的，没有集中的控制。
例如，在供应链方面，实施产品采购可能涉及到多家公司的定单、发货通知单和资金的交互。编排不描述每个公司如何处理操作，只描述不同公司如何彼此交互。实际上我们在具体的调用分析一个流程的时候，经常从Choreography方法开始。每一个参与的人，部门或公司会告诉我们：“如果我得到了一个文档，下面我应该做什么……然后传递给XYZ”，当他们将流程的控制权传递给操作下一步骤的人，部门或公司的时候，他们对流程的控制就结束了。当然我们可以使用这种方式来设计流程。因为这种方式的流程避免了集中控制，可以更好的被度量。缺点是对整个流程状态的控制及分析流程错误的原因是比较困难的，在一个大的公司或组织中是没有人了解谁在负责这一具体的流程。
编制虽然没有采用集中控制，但是编制的视角是从面向整个系统。
2 、 具体的标准支持
BPEL4WS（Business Process Execution Language for Web Services）：从Microsoft和IBM的XLANF和WSFL发展而来，是一种可执行语言。目前由OASIS组织发布为BPEL2.0版本。适合于服务的编制（Orchestration），此标准主要用于组织内部的业务流程管理，目前越来越多的BPM产品基于此规范实现。BPEL4WS定了支持Web Service通讯的基本活动。典型的场景如：BPEL4WS接收到一个消息开始执行流程。流程可能调用一系列的外部服务来收集数据，并且反馈给请求者。<receive>, <reply>, and <invoke>就代表了连接web服务的基本的活动。
WS-CDL (Web Service Choreography Definition Language)：专门的Web服务编排标准，由SUN, SAP,Oracle发起，目前由W3C发布。WS-CDL是一种描述多方契约的语言，有些类似WSDL扩展；可以看作是在已经存在的web service纸上的一个层面。WSCDL中的每一个活动都代表了一组工作。WSDL描述Web服务接口，WS-CDL描述Web服务间的合作。Wscdl是一种编排语言，值得注意的是WSCDL只描述了web service之间的合作活动，并没有定义一个可执行的业务流程。在WSCDL语言中没有一个参与者进行集中控制。
3、 BPEL和WS-CDL共同使用的案例
目前BPEL是最主流的web服务聚合的标准。但是一般BPEL主要用于实现可执行的业务流程，及组织内部的服务的聚合。随着SOA的逐渐发展和成熟，需要基于web service灵活的组建复合的应用及跨组织的合作，这种情况WSDL标准就比较适合。下面我们说明跨组织订单合作的WS-CDL和BPEL标准共同使用。
如何就仅仅使用BPEL来实现跨组织的合作协议，我们需要：
第一步：对于Buyer参与者设计本地的组织活动模型。
第二步：对Seller，Supplier等设计本地的组织活动模型。
然后会发现，这两个分别设计模型并不能相互很好的交互，对这两个模型的组合可能导致全局视图的缺失。
如果我们采用WSCDL标准来构建模型：可以先生成一个统一的视图，然后细分具体的参与部分。
第一步：锁定全局视图：定义buyer和seller之间的合作关系。
第二步：然后切分具体的参与者。通过WSCDL生成BPEL或Java程序。如：Buyer使用Java，Seller使用BPEL。
4、 小结：
编排和编制是与组合web服务以协同工作的两个相关的方式。这两种标准对于建立动态的，可扩展的流程是非常重要的。他们的目标是提供一系列的开放的，标准的协议来设计和执行多个Web服务的交互。
编制让我们可以更好的理解每个个体需要完成的任务。而编排关注将各个个体组合起来成为一个团队的方式，在这个团队中每个个体任务都对总体的结果进行贡献，编排能够理解一个个体与哪一另外的个体进行协同以达到总体的结果。尽管BPEL处理编排的局限性，它仍然会在SOA开发中扮演重要角色，最终随着WSCDL的发展，BPEL在大型的编排流程中可以扮演子流程的作用。
（本文转自北大青鸟社区）
https://blog.sciencenet.cn/blog-298436-278887.html
上一篇：2009年十大即时网络技术
下一篇：人计算-Human Computing
扫一扫，分享此博文