CN101588388A

CN101588388A - 一种基于分布式适配的服务协作方法及其系统

Info

Publication number: CN101588388A
Application number: CNA2009100848804A
Authority: CN
Inventors: 乔晓强; 魏峻; 黄涛
Original assignee: Institute of Software of CAS
Current assignee: Shandong qianyun Information Technology Group Co., Ltd.
Priority date: 2009-05-26
Filing date: 2009-05-26
Publication date: 2009-11-25
Anticipated expiration: 2029-05-26
Also published as: CN101588388B

Abstract

本发明公开了一种基于分布式适配的服务协作方法及其系统，属于网络服务领域。本发明的方法为：首先依据协作需求建立全局的服务协作流程，并将其投影到各参与角色，得到各角色的抽象服务接口集合；同时建立参与协作的实际服务行为接口模型；然后将抽象服务接口与对应的实际服务行为接口进行可适配的一致性检查；对满足可适配的实际服务的行为接口构造适配器；最后将适配器封装为Web服务分布式地部署在网络执行环境中。本发明的系统的协作流程层包括协作流程建模工具和协作流程投影工具；适配管理层包括映射模型管理模块、一致性检查模块、适配器管理器；本发明可满足开放网络环境对于高效、灵活的服务协作机制的需求。

Description

一种基于分布式适配的服务协作方法及其系统

技术领域

本发明涉及一种服务协作方法和系统，特别是涉及一种通过构造分布式的适配器来实现服务正确交互的协作方法及实现系统，属于面向服务的架构(SOA)以及服务协作的技术领域。

背景技术

Internet技术的发展与普及，为软件开发带来了新的方向与挑战。一方面，Internet计算环境高度动态、高度异构的特点对建筑在其上的分布式软件提出了松散耦合、平台中立、协议无关等新的要求。另一方面，社会的全球化趋势使企业面临快速变化的市场、新的政策法规、灵活的业务协作关系和更大的竞争压力，这一切都要求企业应用能够快速集成、重用、以及响应变化，以适应新的业务模式和需求。

面向服务的体系结构(Service Oriented Architecture)正是在这种背景下应运而生，成为开放网络环境下构建分布式应用的范型(Paradigm)。SOA是分布式动态服务的概念性架构，其思想在于将“服务”作为构造分布式系统的基本计算元素，通过服务之间的交互来构造分布式软件系统和企业应用。SOA作为一种功能组件化的设计模型，屏蔽了不同平台、编程语言、操作系统和硬件架构之间的差异，简化了应用程序的集成方式。Web服务是当前实现SOA计算范型的最有前景的技术，其兴起得益于以下因素的推动：首先，XML技术的不断完善，为数据表示和交换提供了标准，使的跨组织的分布式系统之间的通信和互操作成为可能；其次，Web服务采用的基于文档的消息模型适应不同应用之间松散藕合的需求；而重要的国际组织和厂商如W3C、OASIS，IBM和Microsoft等都大力支持Web服务技术的发展。随着相关技术的不断发展与成熟，Web服务已经成为Internet上一种重要的计算资源，从而又进一步推动了SOA的应用与发展。

服务协作作为面向服务的计算范型中实现资源共享和应用集成的核心技术，是应用、实施和部署SOA过程中需要解决的重要问题。不同的企业通过将资源和应用封装为服务，按照一定的业务逻辑编排成可执行流程，从而实现分布、异构、自治环境下的流程整合与业务协同。服务协作不但可以通过组合现有服务组件实现更为复杂的业务逻辑和业务目标，而且通过选择性地重用已有服务，在降低服务开发周期和成本的同时实现组织之间灵活、高效的业务交互。因此服务协作技术是实现开放网络环境下资源和应用有效聚合的重要技术，具有广泛的应用前景。

然而，由于服务是由彼此独立的企业开发的，无法在开发阶段就预测到其潜在的所有交互可能，因此不同的企业的服务在单个交互操作、以及核心流程的业务逻辑等方面都会存在不一致的情况，从而难以保证服务协作的正确性。而且由于服务计算环境的动态及变化的特性，一方面，根据需求的不同，在每次的协作实例中可能会选择不同的Web服务；另一方面，对于服务提供商而言，其提供的服务会参与到不同的协作环境中，面对不同的差异性，而且服务组件会因为升级演化而改变其接口，从而破坏了原有的协作关系。在这些情况下，无论是针对不同的协作关系和Web服务来定制不同的协作流程的方法，或者是以协作流程的需求为依据，更改服务实现的方法，都存在仅代价高而且灵活性差的问题。

通常我们可以采用适配器的方法来解决服务组件的交互差异问题。由于适配器不涉及实际的业务操作，而只是通过消息的抽取、转换、交互顺序的改变来弥补服务组件之间的差异，因此相对于服务组件，适配器是一种更为轻型的组件形式。那么针对上述的情况，选择不同的Web服务，可以通过配置不同的适配器来满足协作的正确性；当协作流程或服务组件的接口发生变化时，只需动态重配适配器就可以再次实现有效的协作。因此，通过适配机制来满足协作的正确性一方面保证了协作的成功率，提高了服务组件的可重用性，同时降低了系统更新的代价，提高了协作的灵活性。

然而，现有的基于适配的方法，例如消息代理，或ESB中的消息适配器等，只是考虑了单个消息的适配，而没有考虑服务组件的整体行为，即消息的逻辑交互顺序的约束关系对交互正确性的影响。在组件领域，Tivoli等人提出的通过构造集中式适配器的方法来保证协作的正确性，然而集中式的方式并不适用于更为开放、分布的服务计算环境的特点：由于服务组件的交互消息都要经过集中式适配器的中转，因此增加了总的消息流量，从而导致较大的消息通信开销，降低了协作的运行效率；服务协作的性能将受到集中式适配器的计算能力和通信能力的限制，当服务协作的并发客户数较大时，集中式适配器很容易成为系统中的重载结点，从而形成系统的性能瓶颈；此外由于集中式的协调结构存在中心结点，某些情况下服务组件的自治性需求使得集中式结构并不适用于某些特殊的应用场景，例如在B2B应用中业务伙伴的关系往往是对等合作的，由某个结点决定所有的协调方法通常并不合适；再者，许多商业应用出于业务和安全的目的往往要求相关的业务伙伴之间直接交换数据，不允许敏感的业务数据流经第三方结点，因此通过中心结点路由数据是不适宜的。

发明内容

鉴于现有方法的缺陷，本发明的目的在于提供一种基于分布式适配的服务协作方法以及支持该方法的实现系统，为参与协作的每个服务组件生成独立的适配器，并实现各个适配器的分布式部署和运行，从而更加满足开放网络环境对于高效、灵活的服务协作机制的需求，避免集中式的适配方法在运行效率、可伸缩性和可用性等方面存在的局限。

为实现上述的发明目的，基于分布式适配的服务协作方法包括了以下几个步骤：

步骤1：建立全局的服务协作流程，用以描述整体的协作流程，即参与协作的服务组件之间的交互过程，在协作流程中以角色来抽象地表示服务协作的参与者；

步骤2：基于角色实现了全局协作流程的投影方法，得到P2P的分布式服务协作流程，其中包含了各个角色所对应的抽象服务接口，每个抽象服务接口定义了相应的角色需要在协作中满足的行为约束；同时建立参与协作的实际服务的行为接口模型，该模型描述了实际服务组件所提供的操作，以及操作调用之间的逻辑时序关系；

步骤3：以步骤2所得到的抽象服务接口为标准，与对应的实际服务行为接口进行可适配的一致性检查；

步骤4：根据步骤3的结果，如果实际服务的行为接口满足可适配的一致性，为其自动构造适配器；如果实际服务的行为接口不满足可适配的一致性，则返回不可适配的交互路径信息，提供给协作开发者以实现有效的调整；

步骤5：将各个服务组件所对应的适配器转换成相应的实现形式(Java类或者BPEL流程)，并封装为Web服务，从而可以分布式地部署在与实际服务相同的执行环境中，使得适配器作为服务的Wrapper，基于其协调作用来实现正确的服务协作流程。

其中，步骤1具体还包括以下步骤：

1)首先建模服务组件之间的全局协作流程，其中每个活动表示角色之间的消息交互事件，活动之间的控制流则描述了角色之间的控制传递；

2)本发明以CSP形式化方法为基础，来验证投影算法的正确性以及服务的可适配一致性，因此需要将流程模型转换为CSP形式化语言描述的结构。

这里我们所用到的CSP的操作符包括：

前缀(prefix)：设有一活动为a，有一进程为P，则执行活动a，然后按照进程P的描述来执行，用a→P表示；

循环(recursive)：若F(X)是一包含了名称X的有前缀的流程描述，则μX·F(X)给出了循环执行流程X的定义；

外部确定性选择(external deterministic choice)：一个流程可以按照进程P的描述执行，也可以按照Q的描述执行，其选择由外部环境决定，则表示为：P□Q；

内部非确定性选择(internal non-deterministic choice)：一个流程可以按照进程P的描述执行，也可以按照Q的描述执行，其选择由流程自身决定，则表示为

顺序(sequence)：P；Q表示流程首先按照进程P的描述执行，如果成功，则继续按照Q的描述执行；

并发(parallel)：P‖Q表示通常的并行操作，进程P和Q将基于符号表中的相同事件进行同步，即进程P和Q在事件集αP∩αQ上同步；

另外，CSP中还定义了两种特殊进程：STOP与SKIP，其中STOP表示流程死锁，SKIP表示流程执行成功。

全局协作流程的每个原子活动表示了两个角色之间的一次消息交换，那么采用CSP形式化语言来描述即为：m(r_s，r_d)。表示消息m由角色r_s发送到角色r_d。

所述步骤2还包括以下步骤：

建立实际服务行为接口的形式化描述模型，在实际应用中，通常可以采用抽象WS-BPEL流程描述来描述实际服务的行为，因此这里我们给出了WS-BPEL与CSP形式化语言的模型结构的转换方法，如表1：

表1WS-BPEL的CSP转换方法

这里我们用！x表示消息发送活动，而？x则用来描述消息接收活动。针对WS-BPEL中的结构活动sequence，flow，pick，switch以及while，则分别转换为CSP语言中对应的顺序，并发，确定性选择，非确定性选择以及循环结构。

所述步骤3还进一步包括下列步骤：

1)建立抽象服务接口与实际服务行为接口之间的消息映射模型，即如何实现抽象服务接口与实际服务接口所定义的消息之间的相互转换；

2)基于消息映射模型构造抽象服务接口与实际服务接口之间的适配模型；

3)对得到的适配模型进行死锁检查，以确定对应的实际服务是否存在正确的适配器，使其满足协作流程的需求。

为实现本发明目的，还提供了一种基于分布式适配的服务协作系统，其主要模块按照功能分为三个层次：

协作流程层次：主要包括了协作流程建模工具，CSP映射转换模块以及协作流程投影模块。其中，协作流程建模工具采用图形化的方式建立服务协作流程，用于可视化建模和展示；CSP映射转换模块则将图形化的流程模型转换为CSP表示的模型结构；协作流程投影工具则基于协作角色将全局的协作流程进行投影，得到各个实际服务所对应的抽象服务接口。

适配管理层次：包含三个子模块，分别为服务管理模块，映射模型管理模块以及适配器管理模块。其中，服务管理模块中的协作服务管理器负责参与协作的服务组件的组织与管理，并通过服务接口CSP转换工具将服务组件的行为接口转换为CSP描述模型；映射模型管理模块中包括映射模型管理器、消息映射编辑器以及映射模型构造模块。映射模型管理器负责抽取抽象服务接口以及实际服务接口中的消息，提供给消息映射编辑器，并将消息映射的结果提交给适配器管理模块以进行一致性检查以及适配器的构造。消息映射编辑器通过可视化的界面使得开发者可以方便地编辑消息之间的依赖映射关系，而映射模型构造模块负责映射模型的生成，管理及其持久化存储；适配器管理模块包括了一致性检查模块，适配器生成模块以及适配器管理器。其中一致性检查模块以抽象服务接口，服务的实际接口以及消息映射模型为输入，判断对应的实际服务是否存在有效的适配器；适配器生成模块则依据一致性检查的结果生成适配器，并转换成相应的实现形式(本发明将适配器转换为可执行WS-BPEL流程的形式)；适配器管理器则负责适配器分布式部署及其管理；

协作运行层次：协作运行层分布式地位于各个服务提供者的位置，为适配器提供运行支撑环境。其中协作代理负责与适配器管理器进行通信，接收并部署适配器到相应的执行引擎；适配器执行引擎则实现适配器实例的解释与执行。

本发明提出一种基于分布式适配实现服务协作的方法及相应的支撑实现系统，和现有的方法相比，本发明的技术效果是，通过为每个服务组件分别实现适配器，进一步降低了实际服务与协作环境的耦合关系，使得在不改变源服务组件实现的前提下满足应用协作要求，从而提高了服务组件的可复用性以及协作成功率。而且在协作目标或者单个服务组件发生变化时，只需重新配置适配器就可以再次实现有效的协作，从而降低了系统更新的代价。而且采用了分布式的适配方式，避免了集中式适配方式所带来的通信开销，提高了系统的可伸缩性；取消了集中式适配器的控制中心和数据路由中心，将适配器的执行分布到服务组件所在的各个结点，并在结点之间直接交换数据，从而减少了适配器结点成为系统重载结点的可能，提高了服务协作系统的数据传输效率。在大并发访问量、大数据传输量以及网络带宽受限的应用中，采用基于分布式的适配机制将是更好的选择。因此，本发明所提供的方法在保持了服务组件自治特性的同时，提高了企业间服务协作的灵活性。

附图说明

图1为基于分布式适配的服务协作方法原理图

图2为本发明的服务协作支撑系统的总体架构图

图3为服务之间的全局协作流程的示意图

图4为CSP描述的流程模型的面向对象建模的主要类结构图

图5为适配模型的构造方法原理图

图6为编辑消息映射关系的示意图

图7为适配器的主要结构示意图

图8为基于分布式适配的运行时服务交互示意图。

具体实施方式

以下结合具体实施例和附图对本发明作更详细的说明。

图1给出了基于分布式适配的服务协作方法示意图。本方法中所涉及的主要元素包括有协作流程模型，抽象服务接口，实际服务接口以及服务适配器等等。

图2给出了本发明的服务协作支撑系统的总体架构图，包含了协作流程层，适配管理层以及协作运行层三个层次。

首先依据协作需求，通过协作流程建模工具，建立服务之间的交互协作流程，从全局角度描述参与协作的服务之间的公共交互消息和协作契约关系。本发明所实现的建模工具采用了基于Eclipse的插件开发技术，整体采用MVC(Model-View-Control)的架构，通过继承和实现框架类完成。如图3所示，类似于业务流程建模标注规范BPMN(参见文献：http://www.bpmn.org/，BPMN1.0，OMG Final Adopted Specification，February 6，2006)，协作流程建模工具以泳池(pool)的概念来描述一个协作流程，而参与的角色通过泳道(lane)的概念来进行划分。图形化流程中的每个活动表示一个消息交互事件，活动所属的泳道作为消息的发送者，而通过活动的接收角色(receiver)属性来选择设置相应的消息接收者。消息的具体内容则通过泳池的消息列表(message list)属性来设置。可以看出，协作流程主要描述了服务之间的消息交互活动以及这些活动之间的时序逻辑关系。

接下来需要将服务协作流程投影到各个参与角色，得到各个角色的抽象服务接口集合。这些抽象服务接口的交互则构成了P2P形式的分布式协作流程。为了保证投影前后流程的正确性与一致性，本发明首先将协作流程建模工具所得到的协作流程转换为CSP形式化语言的模型结构，然后再执行投影算法。首先对CSP描述流程的模型结构进行面向对象建模，图4给出了主要类结构的示意图。其中ProcessObject是根类，所有流程相关的类都继承于ProcessObject。ProcessObject包括三种子类，分别是Process，Swimlane和LaneObject。其中Process用来描述整个流程的相关属性，包括消息列表(message list)用以定义整个协作流程中角色之间交互的消息；Swimlane的子类则包括Pool和Lane，Pool用以描述一个具体的协作场景，而Lane用以表示协作中的各个角色；LaneObject则用以定义流程中的元素，其子类包括有ConnectionObject和FlowObject，分别用来描述流程中的连接和基本活动。SequenceFlow继承于ConnectionObject，用来建模流程中的连接线，描述活动之间的时序逻辑关系。FlowObject则包含了Activity(活动)，Event(事件)和Gateway(网关)三个子类。其中Activity的子类ServiceTask用来建模具体的消息交互活动，其属性包括活动标识(ID)，活动名称(Name)，消息(Message)，消息的发送角色(Lane)以及消息的接收角色(Receiver Lane)等等；Event的子类StartEvent和EndEvent则分别用来描述流程的起始点和结束点；GateWay则用来描述流程的分支，其子类分为ParallelGateWay(并发网关)和ExclusiveGateWay(选择网关)，分别用来建模并发分支以及选择分支。具体的转换过程由协作流程层的CSP转换工具实现，转换后得到的CSP描述的协作流程通过协作流程投影工具的作用，转换为各个角色的抽象服务接口的集合，协作流程投影工具主要依据表2所示的投影方法来实现流程的转换：

表2全局协作流程投影方法

投影方法包含原子活动和复杂活动两类。

方法2.1用来实现原子活动的投影，方法如下：对于活动m(r_s，r_d)，如果当前角色为发送角色r_s，那么投影后的活动为消息发送活动！m(r_s，r_d)；如果当前角色为接收角色r_d，则投影后的活动为消息接收活动？m(r_s，r_d)；对于其他角色，活动m(r_s，r_d)投影后为SKIP。

方法2.2给出了顺序活动的投影方法：对于顺序流程P；Q，Head(Q)＝{r_j|1≤j≤n}，是流程Q中所有起始活动的消息发送角色的集合；Tail(P)＝{r_i|1≤i≤l}，则包括了流程P中所有结束活动的消息接收角色。如果当前角色属于集合Tail(P)，那么需要增加相应的顺序同步流程‖_j≤n！m_syn(r，r_j)，即当前角色发送同步消息m_syn到Head(Q)中的每个角色；如果当前角色属于集合Head(Q)，那么需要增加相应的顺序同步流程‖_i≤l？m_syn(r_i，r)，即当前角色从Tail(P)中的每个角色接收同步消息m_syn；从而保证了分布式协作流程中的顺序一致性。

方法2.3给出前缀活动的投影方法，前缀活动属于顺序流程的特例，因此其投影方法同方法2.2一致。

方法2.4对于并发活动P‖Q的投影方法：分别对流程P和Q进行投影，然后再以并发操作符连接投影后的流程即可。

方法2.5是选择活动的投影方法。对于协作流程中的选择操作符，我们要求参与协作的一个角色拥有决策权。假设选择决策角色为r₀，而{r_i|r_i≠r₀∧1≤i≤n}则为所有在流程P或Q中具有相关发送或接收活动的角色，那么需要构造相应的同步选择消息m_P和m_Q，并从r₀发送到每一个r_i，用来通知角色r₀所选择的分支，从而保证分布式协作流程中的选择一致性。

方法2.6为具有选择结构的循环活动投影方法，其只需对循环结构内的选择活动进行投影即可。

得到各个角色对应的CSP描述的抽象接口之后，为了判断实际服务接口的一致性，首先通过协作服务管理器获取实际服务的接口描述，包括WSDL描述的操作接口，以及抽象WS-BPEL描述的行为接口，然后通过服务接口CSP转换工具，将行为接口转换为CSP描述的形式化模型结构。这里的CSP转换工具主要依据表1中给出的转换方法，实现相应的转换算法。然后以抽象接口与实际接口的CSP描述模型为基础，建立实际服务与对应角色之间的适配模型，以进行可适配一致性的检查。

适配模型的构造示意图如图5所示，分为以下三个步骤：

1)首先抽取抽象接口与实际服务接口中的消息，并且建立消息之间的数据依赖关系，即一方所需要接收的消息如何通过另一方的发送消息来构造。通过映射管理模块的消息映射编辑器，本发明所述的系统通过可视化的方式描述消息之间的映射关系，消息映射编辑器如图6所示，界面左半部分给出了一方接口的所有接收消息以及消息的具体格式的描述，界面的右上部分给出了当前接收消息所依赖的另一方接口的发送消息，而右下部分则用来输入消息之间具体的映射转换关系，主要基于XPath语言来实现。

2)然后根据消息依赖关系为每个接收消息建模对应的消息管道，其CSP描述为：

Pipe_m_r＝[(‖_i≤nleft？m_si)→synth→right！m_r→SKIP]□[close→SKIP]

这里m_r是当前的接收消息，m_si∈M_S，M_S是m_r所依赖的发送消息的集合，n是m_r所依赖的发送消息的数目。消息管道通过left信道接收消息，并通过其right信道发送消息。Synth则是消息映射中转换关系的相应实现。

3)最后依据抽象接口和实际服务接口的CSP描述模型构造异步交互流程，其方法为：

(a)对于接口描述中的每个发送消息m，若m在数据映射中有相应的映射关系定义，则将相应活动改写为对消息管道的写入活动(‖_i≤nPipe_m_i.left！m)，Pipe_m_i是依赖于m的接收消息所对应的消息管道，否则将相应的活动改写为SKIP；

(b)对于接口描述中的每个接收消息m，若m在数据映射中有相应的映射关系定义，则将相应的活动改写为对消息管道的读出活动Pipe_m.right？m，否则将相应的活动改写为STOP。

最后得到的适配模型的CSP描述为：(‖_i≤nPipe_m_i)//[P_AI‖P_SI]，其中‖_i≤nPipe_m_i为所有的消息管道的集合，P_AI和P_SI则分别对应了抽象接口和实际服务接口转换得到的异步交互流程。

在得到实际服务接口对应的适配模型之后，本发明通过以下的算法来验证实际服务的可适配一致性：

输入：适配模型(‖_i≤nPipe_m_i)//[P_AI‖P_SI]

输出：对应的实际服务是否满足可适配一致性

Procedure boolean adaptableConsistency

(1)预处理：将异步交互流程中的P_AI和P_SI分别转换成等价的非确定性选择的标准形式

(1.1)if活动为形式，转换为

else if活动为

形式，转换为

else if活动为形式，转换为

else if活动为

形式，转换为

else if活动为

形式，转换为

end if

(1.2)P_AI转换后得到的分支子流程P_AI1，P_AI2，...P_AIm集合存入列表AIList，同样P_SI的分支子流程P_SI1，P_SI2，...P_Sin存入列表SIList。

(2)for each p_i in AIList，

for each p_j in SIList，

while(true)do

result_p_i←move(p_i)，result_p_j←move(p_j)；

if(result_p_i＝STOP∨result_p_j＝STOP)return false；end if

if(result_p_i＝NoMove∧result_p_j＝NoMove)return false；end if

if(result_p_i＝SKIP∧result_p_j＝SKIP)break；end if

end while

end for

return true；

end Procedure

步骤(1)的预处理部分将流程分解为非确定性选择符

连接的分支子流程集合，从而简化了非确定性选择分支的处理，每个分支子流程代表了协作的一条交互路径。步骤(2)对抽象接口与实际服务接口的每条交互路径进行两两的死锁检查，如果所有的交互路径都不存在死锁，那么实际服务就满足可适配一致性的条件。其中调用的算法move，用来检查交互流程各个活动。算法move遍历流程的各个原子活动，并返回当前的检查结果，包括四种类型：SKIP，STOP，NoMove和Move。如果当前流程可以成功执行完，则返回SKIP；如果存在STOP活动，则返回结果STOP。如果不存在可执行的活动，则返回NoMove；或者存在可执行的活动，则返回结果Move。同时每次执行Move算法后将可执行活动的状态标记为已检查。算法中的函数canReceive和canSend分别用来检查相应的消息通道的状态是否可以写入数据，以及是否可以读取数据。其算法描述如下：

输入：待检查的流程p

输出：当前的检查结果result

Procedure result move

(1)if p是顺序活(顺序运算符‘；’连接各个子流程)

for(i:＝n；i＞0；i--)do

q_i:＝subSequentialProcess(p，i)；

if q_i未标记

result←move(q_i)

if(result＝SKIP)hasMoved:＝true，mark(q_i)；

else if(result＝STOP)return STOP；

else if(hasMoved＝true∨result＝Move)return Move；

else return NoMove；

end if

end for

return SKIP；

(2)else if p是并发活动

for(i:＝n；i＞0；i--)do

q_i:＝subParallelProcess(p，i)；

if q_i未标记

result_i←move(q_i)；

if(result_i＝SKIP)mark(q_i)；end if

else result_i:＝SKIP；

end if

end for

if存在一个result_i＝STOP return STOP；

else if存在一个result_i＝Move return Move；

else if所有result_i＝SKIP return SKIP；

else return NoMove；

end if

(3)else if p是外部选择活动

if存在子流程q_i有isChoosed(q_i)＝true，return move(q_i)

else return NoMove；

end if

(4)else if p是形如a₁→a₂→...→a_n的结构

for(i:＝n；i＞0；i--)do

a_i:＝subActivity(p，i)；

if a_i未标记

(4.1)if a_i是发送活动

if canSend(a_i)hasMoved:＝true，mark(a_i)；

else if(hasMoved＝true)return Move；

else return NoMove；

end if

(4.2)else if a_i是接收活动

if canReceive(a_i)hasMoved:＝true，mark(a_i)；

else if(hasMoved＝true)return Move；

else return NoMove；

end if

(4.3)else if a_i＝STOP return STOP；

end if

end for

return SKIP；

end if

end Procedure

当可适配一致性的检查结果为false时，说明即使采用适配技术，服务组件也无法满足协作需求。所有无法适配的路径以及对应的活动节点会可视化地提供给开发者，作为调整服务协作需求的参考，从而更加有效地利用了检查算法的结果。通常存在两类无法适配的情况：

(1)接收活动所对应的消息m，不存在相应的数据映射关系；

(2)存在消息的循环依赖，从而无法进行适配。

对应于第一类情况，开发者需要进一步确认给定的接收消息m是否可以通过以下方式构造：(i)消息m是常量或者空值；(ii)消息m可以由先前接收到的消息来构造。而对于第二种情况，则开发者需要确认是否可以调整协作流程中消息交互的顺序，从而避免造成无法适配的情况。

当可适配一致性的检查结果为true时，适配器生成工具依据适配模型生成适配器的CSP描述。适配器的生成方法的主要思路在于，为异步交互流程的每个活动构造相应的消息发送或者接收活动：

(1)如果异步交互流程中的活动为写入活动(‖_i≤nPipe_m_i.left！m)，则构造相应的消息接收活动？m，并用前缀连接符‘→’连接活动，结果为：？m→(‖_i≤nPipe_m_i.left！m)；

(2)如果异步交互流程中的活动为读出活动(Pipe_m.right？m)，则构造相应的消息发送活动！m，并用前缀连接符‘→’连接活动，结果为：Pipe_m.right？m→！m；

构造的消息发送或者接收活动主要实现了与实际服务或是其他适配器的消息交换，从而实现行为适配；而异步交换流程以及消息管道则主要实现消息缓存、抽取、转换以及协调消息交互顺序的作用，其结构示意图如图7所示。

考虑到实际应用中通常采用WS-BPEL作为服务流程的实现语言，本发明将CSP描述的适配器结构转换为WS-BPEL描述的流程模型，通过适配器生成工具实现这一功能，其转换方法如下：

(1)行为适配流程：与对应实际服务以及与其他适配器的交互部分，分别实现为flow结构的两个并发子流程；并根据定义中的结构化信息生成相应的flow，sequence等结构；

(2)具体的消息发送与接收活动：根据实际服务行为接口的具体描述信息，分别实现为receive，reply，invoke或pick等活动；

(3)消息管道中的数据存储：对于流程中的每个消息，采用WS-BPEL中的Variable元素来表示，并以此来实现具体消息内容的保存与更新；

(4)消息管道中的转换活动：对于消息管道中的映射转换，则采用WS-BPEL中的Assign活动来实现，并通过其copy和to元素来描述具体的转换方法；

(5)消息转换活动实现为单独的并发子流程，具体的消息转换与行为适配流程之间的同步关系通过WS-BPEL语言中的link活动来实现，从而保证在接收消息之后，以及发送消息之前完成相应的消息转换。

最终生成适配器的WS-BPEL描述文件，并通过各个服务提供者的协作代理模块，部署到各个适配器执行引擎。那么在运行时，适配器通过与相对应的实际服务交互来进行应用数据的交换，而协作流程则通过适配器之间的分布式交互来实现，其运行时的交互协作模型如图8所示。从而通过分布式适配器的应用，在保持服务协作灵活性的前提下，提高了服务组件的可重用性。

Claims

1.一种基于分布式适配的服务协作方法，其步骤为：

1)依据协作需求，建立全局的服务协作流程，采用角色描述所述服务协作流程中的参与者；

2)将服务协作流程投影到各个参与角色，得到各个角色的抽象服务接口集合；同时建立参与协作的实际服务行为接口模型；

3)将抽象服务接口与对应的实际服务行为接口进行可适配的一致性检查；

4)如果实际服务的行为接口满足可适配的一致性，则为其自动构造适配器；如果实际服务的行为接口不满足可适配的一致性，则返回不可适配的交互路径信息；

5)将各个服务组件所对应的适配器转换成相应的实现形式并封装为Web服务，分布式地部署在与实际服务相同的执行环境中。

2.如权利要求1所述的方法，其特征在于通过协作流程建模工具建立服务组件之间的服务协作流程得到所述全局的服务协作流程；所述协作流程建模工具以泳池的概念建立一协作流程，所述参与者的角色以泳道的概念进行划分，其中图形化流程中的每个活动表示一个消息交互事件，活动所属的泳道作为消息的发送者，通过活动的接收角色属性来选择设置相应的消息接收者，消息的具体内容则通过泳池的消息列表属性来设置。

3.如权利要求1所述的方法，其特征在于通过抽象WS-BPEL流程描述建立所述实际服务行为接口模型，然后将所述实际服务行为接口模型转换为CSP形式化语言的模型结构，其方法为：将WS-BPEL语言中的结构活动sequence、flow、pick、switch以及while分别转换为CSP形式化语言中对应的顺序、并发、确定性选择、非确定性选择以及循环结构，同时在CSP形式化语言模型结构中用！x表示消息发送活动，用？x描述消息接收活动。

4.如权利要求3所述的方法，其特征在于所述将服务协作流程投影到各个参与角色方法为：首先服务协作流程转换为CSP形式化语言的模型结构，然后通过投影算法将转换后的服务协作流程投影到各个参与角色。

5.如权利要求4所述的方法，其特征在于所述CSP形式化语言的模型结构包括：一根类，所有流程相关的类都继承于该根类；所述根类包括Process、Swimlane、LaneObject三种子类；其中所述Process用来描述整个流程的相关属性，其包括一消息列表用以定义整个协作流程中角色之间交互的消息；所述Swimlane包括Pool和Lane子类，Pool用以描述一个具体的协作场景，Lane用以表示协作中的各个角色；所述LaneObject用以定义流程中的元素，其包括ConnectionObject和FlowObject子类，ConnectionObject用来描述流程中的连接，FlowObject用来描述流程中的基本活动；SequenceFlow继承于所述ConnectionObject，用来建模流程中的连接线，描述活动之间的时序逻辑关系。

6.如权利要求5所述的方法，其特征在于所述FlowObject包含活动、事件、网关三个子类，其中活动的子类ServiceTask用来建模具体的消息交互活动，其属性包括活动标识、活动名称、消息、消息的发送角色以及消息的接收角色；事件的子类包括StartEvent和EndEvent，StartEvent用来描述流程的起始点，EndEvent用来描述流程的结束点；网关则用来描述流程的分支，其子类分为并发网关、选择网关，分别用来建模并发分支以及选择分支。

7.如权利要求6所述的方法，其特征在于所述将转换后的服务协作流程投影到各个参与角色的方法为：

1)对于原子活动的投影：如果当前角色为发送或接收角色，则将其投影为对应的消息发送或接收活动；对于原子活动中的其他角色投影为SKIP；所述原子活动为表示两个角色之间的一次消息交换；

2)对于顺序流程P；Q的投影：设流程P中所有结束活动的消息接收角色集合为Tail(P)，而Q中所有起始活动的消息发送角色集合为Head(Q)；如果当前角色属于Tail(P)，那么增加将当前角色发送同步消息m_syn到Head(Q)中的每个角色的顺序同步流程；如果当前角色属于Head(Q)，那么增加将当前角色从Tail(P)中的每个角色接收同步消息m_syn的顺序同步流程；

3)对于前缀活动则采用2)中的投影方法进行投影；

4)对于并发活动P||Q的投影：分别对流程P和Q进行投影，然后再以并发操作符连接投影后的流程；

5)对于选择活动的投影：对于协作流程中的选择操作符，将参与协作的一个角色设置为选择决策角色r₀，而{r_i|r_i≠r₀∧1≤i≤n}则为所有在流程P或Q中具有相关发送或接收活动的角色，然后构造相应的同步选择消息m_P和m_Q，并从r₀发送到每一个r_i，用来通知角色r₀所选择的分支；

6)对于具有选择结构的循环活动的投影：对循环结构内的选择活动直接进行投影。

8.如权利要求4所述的方法，其特征在于建立一实际服务行为接口与对应抽象服务接口之间的适配模型，进行所述一致性检查；所述适配模型建立方法为：1)抽取抽象服务接口与实际服务行为接口中的消息，并且建立消息之间的数据依赖关系；2)根据消息依赖关系为每个接收消息建模对应的消息管道；3)依据抽象服务接口和实际服务行为接口的CSP描述模型构造异步交互流程。

9.如权利要求8所述的方法，其特征在于所述异步交互流程建立方法为：1)对于接口描述中的每个发送消息m，若m在数据映射中有相应的映射关系定义，则将相应活动改写为对消息管道的写入活动，否则将相应的活动改写为SKIP；2)对于接口描述中的每个接收消息m，若m在数据映射中有相应的映射关系定义，则将相应的活动改写为对消息管道的读出活动，否则将相应的活动改写为STOP。

10.如权利要求9所述的方法，其特征在于所述适配模型进行一致性检查的方法为：1)将异步交互流程中的抽象服务接口和实际服务行为接口分别转换成等价的非确定性选择的标准形式；2)采用move算法对抽象服务接口与实际服务行为接口的每条交互路径进行两两的死锁检查，如果所有的交互路径都不存在死锁，那么实际服务就满足可适配一致性的条件；所述move算法的步骤为：遍历交互流程的各个原子活动，如果当前流程可以成功执行完，则返回SKIP；如果存在STOP活动，则返回结果STOP；如果不存在可执行的活动，则返回NoMove；如果存在可执行的活动，则返回结果Move，同将可执行活动的状态标记为已检查。

11.如权利要求8所述的方法，其特征在于所述自动构造适配器的方法为：1)如果异步交互流程中的活动为写入活动，则构造相应的消息接收活动？m，并用前缀连接符‘→’连接活动；2)如果异步交互流程中的活动为读出活动，则构造相应的消息发送活动！m，并用前缀连接符‘→’连接活动。

12.如权利要求11所述的方法，其特征在于将所述适配器转换为WS-BPEL描述的流程模型，其方法为：1)将适配器交互部分的行为适配流程分别实现为flow结构的两个并发子流程，并根据结构化信息生成相应的flow，sequence结构；2)将消息发送与接收活动根据实际服务行为接口的具体描述信息分别实现为receive，reply，invoke或pick活动；3)将流程中的每个消息采用WS-BPEL中的Variable元素来表示，并以此来实现具体消息内容的保存与更新；4)将消息管道中的映射转换采用WS-BPEL中的Assign活动来实现，并通过其copy和to元素来描述具体的转换方法；5)将消息转换活动实现为单独的并发子流程，具体的消息转换与行为适配流程之间的同步关系通过WS-BPEL语言中的link活动来实现。

13.一种基于分布式适配的服务协作系统，其包括协作流程层、适配管理层、协作运行层；所述协作流程层包括：协作流程建模工具，采用图形化的方式建立服务协作流程，用于可视化建模和展示；协作流程投影工具，用于基于协作角色将全局的协作流程进行投影，得到各个实际服务所对应的抽象服务接口；

所述适配管理层包括：映射模型管理模块，负责抽取抽象服务接口以及实际服务接口中的消息，并将消息映射的结果提交给一致性检查模块以进行一致性检查以及适配器的构造；一致性检查模块，用于根据映射模型管理模块的输入判断对应的实际服务是否存在有效的适配器；适配器生成模块，用于依据一致性检查的结果和映射模型管理模块的映射结果生成适配器并转换成相应的实现形式；适配器管理器，负责适配器分布式部署及其管理；

所述协作运行层分布式的位于各个服务提供者的位置，用于为适配器提供运行支撑环境。