服务组合模式

导读：

　　服务组合模式

　　Intent

　　使用户可以容易地定义并更改组合服务；

　　Context 定义增值的组合服务；

　　Problem

　　如果某一企业决定提供一个增值组合服务，它需要定义一个服务调用时可以执行的业务流程，这个流程需要分解为预先存在的服务。此外，必须描述出那些服务之间的相互关系，最后，这个过程定义需要具有快速的适应和简单的维护性。

　　Forces

　　如何描述确定活动之间的关系？服务如何任意地嵌套？如何保证这种高水准的描述服务得以顺利执行？

　　Solution 这里我们通过控制流和数据流为每个组合服务定义。控制流描述了多个服务以及它们之间的相互依赖关系；数据流基于控制流之上并描述了各服务之间的业务文档流。一个服务成分即可以是一个简单服务也可以是一个组合服务，每个简单服务最终要指派给一个具体的服务。嵌套的组合服务要进一步分解直到确定了最基本的简单服务。

　　Implementation 解决方案是以工作流规范技术为基础，这一方法对于组合服务业务流程是最为合理的。以往正规化的符号标记如Petri网、状态图和活动图它们都具有丰富的表达能力。Aalst建议使用Petri网因为校验它们相对来说比较容易。在Benatallah et al.看来他认为在Petri网中递归的过程定义是不可能的，但以我们图4.2所示的旅游服务这种反对意见就变得比较模糊了。Wirtz，Weske，和Giese提议在UML中加入OCN（Object Coordination Nets）以引入功能强大的模型语言。

　　我们更倾向于状态图，它依赖于有限自动机和事件—条件—动作规则，这些概念很容易掌握。Beek（2001）为状态图提出来了正式的语义，这使它可以实现自动校验，同时作为UML的一部分状态图也广泛地被人们所认识。

　　Known uses ADEPT(Jennings et al., 2000a;Jennings et al.,2000b)，CMI (Schuster et al.,2000)，e-Flow (Casati &Shan, 2001; Casatiet al., 2000)，WebBIS (Benatallah, Medjahed, &Bouguettaya, 2000)，selfserv(Fauvet etal., 2001)，AgFlow (Zeng et al.,2001)。

　　Consequences 明了的、表达丰富的、语义清晰的服务描述语言对于组合服务的建模和修改是至关重要的。为人所熟知的规范化的描述技术还可以简化服务的执行。

　　TOP

本文转自

http://soa.5d6d.com/redirect.php?fid=4&tid=113&goto=nextnewset