专利名称：：服务协同中基于系统结构的动态演化方法
技术领域：
：本发明涉及Web服务协同和软件动态演化
技术领域：
，尤其涉及服务协同中的基于系统结构的动态演化方法。
背景技术：
：随着Internet在各个领域应用的普及和深化，人们迫切需要能够方便地实现Internet上跨平台、语言独立、松散耦合的异构应用的交互和集成，在这种新要求下，面向服务计算(S0C)和面向服务体系结构(S0A)应运而生，成为构造下一代分布式应用的计算范型和体系结构。Web服务作为面向服务体系结构的一种具体化技术，以其自描述和松耦合等特点，被广泛用于面向服务的分布式系统的实现。Web服务为众多应用领域的信息自动化提供了新的发展机会，包括旅游、办公、智能信息收集与分析等。然后，为了完成某项目标任务，通常需要大量分布异构系统的协作。在面向服务的分布式应用中，服务是基本构造单元，服务之间的协同工作是实现复杂应用的关键所在。S0A基础型概念架构还不足以满足以上需求，面向服务计算近来已从最初的基本服务的"描述、发布、交互"向新的阶段一服务协同阶段发展。由于开放的计算环境以及多变的应用需求，服务协同应用系统在动态演化方面的要求越来越高。演化可以是预设的也可以是非预设的。预设的演化是指在设计系统结构时就预料到的演化行为；非预设的演化则是指无法预料的，在系统投入运行以后才慢慢显示出来的演化需求，此时通常需要重新开发系统新版本，将原系统关闭，再加载系统新版本。而这对一些可用性要求极高的系统是不可接受的或者经济损失太大。因此，服务协同应用系统需要能够在运行时刻进行演化即动态演化或称在线演化。主要表现在以下两方面(1)系统中的服务单元可能出现故障或需要更新，(2)系统结构需要根据环境和业务需求的变更动态调整，例如，在系统运行期间，为了提高性能可能会加入新的服务或需求的变更可能会删除已有的服务。但目前的服务协同领域的相关技术大多关注如何协同组合己有的服务构成新的更具价值的服务，例如基于工作流技术的服务协同，基于AI规划技术的服务协同等。而且还出现不少相关标准，如WS-BPEL、WS-Transaction、WS-Coordination等。但这些技术与标准并没有考虑到面向服务应用系统的动态演化性需求，没有对服务协同中的动态演化提供很好的支持。服务协同系统的动态演化可能导致系统的不一致性，例如，系统中节点向其已退出的邻节点发送服务请求，则会出现异常；又如节点在被替换过程中被调用，也会产生错误。服务协同系统动态演化中的关键问题之一是要保证演化过程中系统的一致性。已有相关工作提出了一种分布式系统动态演化中保证系统一致性的方法，该方法通过在演化操作执行之前将受影响节点驱动进入适当的状态，包括静止状态和被动状态。处于被动状态的节点，只能接受请求，对所有邻节点都不能主动发出请求。若节点处于被动状态并且不会收到其邻节点的请求，则称节点处于静止状态。为保证一致性，在演化实施前往往需要驱动节点进入静止状态，例如节点必须达到静止状态后才能安全退出，为了达到此目的，该方法将驱动静止节点的所有邻节点进入被动状态。然后，这个方法对条件要求过于严格，也就是，为了使某节点达到静止状态，并不需要驱动所有邻节点进入被动状态。这样虽然一致性得到保证，但给系统带来过多不必要的干扰。
发明内容鉴于上述原因，为解决服务协同应用系统中的动态演化问题，本发明提供了一种面向服务协同的基于系统结构的动态演化方法，该方法能够支持运行时刻下服务节点的加入、退出、替换等动态演化操作，并且在保证系统的一致性的前提下尽量减小对整个系统的干扰。本发明的技术解决方案一种服务协同中基于系统结构的动态演化方法，其步骤如下第一步，对基于BPEL的服务协同模型进行扩展，即在单个节点的BPEL服务协同模型中添加服务协同系统的结构信息，完整显示地定义系统内各服务节点之间服务调用的依赖关系；第二步，基于上述扩展的包含结构信息的BPEL服务协同模型，在系统运行态下驱动服务协同应用系统进入安全状态，然后对系统结构进行相应修改以实现动态演化，基本的动态演化操作包括新节点加入、节点退出和节点替换。本发明的原理本发明首先在一般的服务协同模型基础上进行扩展。例如常用的基于BPEL(BusinessProcessExecutionLanguage)的服务协同模型，不能完整地表达节点之间的依赖关系，一般只暗含本节点调用的其它节点的信息，但却无法表达本节点被哪些节点调用。因此，将在一般的服务协同模型中添加系统结构信息即完整显示地定义系统内各服务节点之间的依赖关系。然后基于上述扩展的包含结构信息的协同模型，给出一个驱动系统进入安全状态的方法，以保证在节点加入、退出、替换或迁移时系统的一致性。最后，通过建立或删除节点间连接关系，实施演化操作，修改系统结构。所谓安全状态就是指在这种状态下节点加入、退出、替换或迁移不会影响到系统其它节点的正常运行。在不同演化操作下，安全状态的解释不尽相同。当新节点加入时，直接与某个接口相匹配的节点建立连接即可。在节点退出或被替换前，必须驱动其邻节点停止向它发送请求，同时它自身停止向其它节点发出请求，且必须处理完所有已接收请求。本发明与现有技术相比的优点在于(1)现有的服务协同模型对系统动态演化支持不够，本发明通过在基于BPEL的协同模型基础上进行扩展，丰富其系统结构信息，以支持系统动态演化操作的实施。(2)对于系统动态演化中可能产生的系统不一致性问题，现有的解决方法虽然能够保证系统一致性，但是对系统带来了过多的不必要干扰。图1为本发明方法的实现流程图2为本发明方法在BPEL服务协同模型中添加服务协同系统结构信息的实现方法流程图3为本发明方法中新节点加入实现流程图；图4为本发明方法中节点退出实现流程图；图5为本发明方法中节点替换实现流程图；图6为本发明实施例的效果图；图7为本发明实施例的效果图8为本发明实施例的效果图。具体实施例方式一、如图1所示，本发明的实现方法为1、首先，对基于BPEL的服务协同模型进行扩展。BPEL是一个Web服务业务流程执行语言，它已逐渐成为Web服务协同领域的事实标准。BPEL为描述基于流程和其合作伙伴之间交互的业务流程行为定义了模型和语法。在BPEL中，与业务流程交互的服务被称为合作伙伴partner,通过partnerLink元素描述流程与其合作伙伴之间的交互关系。partnerLink元素中的myRole属性指出了业务流程本身的角色，partnerRole属性指出了合作伙伴的角色，这两个属性必有其一，也可同时存在。BPEL主要通过九种基本活动描述流程与其合作伙伴间的交互流程。其中与partnerLink直接相关联的几个活动包括receive活动、reply活动、invoke活动以及pick活动中的onMessage分支。invoke表示调用合作伙伴提供的Web服务，receive、r印ly、onMessage表示接受或响应合作伙伴的调用请求即对合作伙伴提供Web服务被合作伙伴调用。由此可见，服务协同的BPEL模型描述中只包含被当前流程调用的其它服务的信息，但却不包含当前流程被哪些合作伙伴调用的信息。但由于调用关系在交互节点的流程之间存在相对性，也就是说若节点A调用了合作伙伴B的服务，则说明节点B的服务也就相对地被合作伙伴A调用。因此，本发明在BPEL模型基础上增加邻节点(neighbor)和连接(connection)这两个概念，其中连接具有方向性，它的方向用于指示节点之间的调用依赖关系。例如，假设节点A、B为相邻节点，若A具有一条到B的出向连接，则说明A需要调用B上的服务；若A具有一条到B的入向连接，则说明A会被B调用。通过解析系统中某个节点的BPEL模型以及邻节点通告机制，建立扩展模型的步骤如图2所示，具体如下-(1)由p虹tnerLink列表得到扩展模型中的部分邻节点与连接信息。设其partnerLink列表为PLliste，partnerLink的partnerRole指示的节点记为partner,步骤如下第l步遍历PLlist中的partnerLink;第2步若partnerlink的partnerRole属性为空，转第5步；第3步若partner不在当前节点的邻节点集合中，则将partner加入到neighbor集合中；第4步创建一个出向连接，并将连接关联到partner上；第5步是否遍历完PLlist中的所有partnerLink，若不是转第l步，否则结束。(2)向当前邻节点集合中的所有邻节点发送"邻节点通告"消息，且该消息包含当前节点信息；(3)根据收到的"邻节点通告"消息，补充缺失的邻节点与连接信息，设发送"邻节点通告"消息的源节点记为source,步骤如下第1.步对于收到的每一条"邻节点通告"消息，重复执行第2-3步；第2步若source不在当前节点的邻节点集合中，则将source加入到邻节点集合中；第3步创建一条入向连接，关联到source上。2.然后，基于上述扩展模型，驱动服务协同应用系统进入安全状态并实施演化操作，基本的动态演化操作包括新节点加入、节点退出和节点替换。下面针对新节点加入、节点退出和节点替换的演化操作，分别介绍执行动态演化的步骤(1)新节点加入，如图3所示。新节点分为主动加入和被动加入，其中主动加入为a.新节点向某在线节点发送"加入请求"，该消息中包含新节点调用在线节点服务的端口信息以及新节点自身信息；b.当某在线节点收到"加入请求"后，判断是否满足消息中指示的端口要求，若满足，则返回"接受"消息并将新节点加入到其邻节点集合中，建立一条入向连接并关联到新节点，否则返回"拒绝"消息；c.若新节点收到"接受"响应，则建立一条到在线节点的出向连接，将此在线节点加入到其邻节点集合中。(2)节点退出，如图4所示。a.退出节点向其入向邻节点(即其入向连接关联到的邻节点)发出"退出请求"，并停止主动向所有邻节点发送服务调用请求，但继续接收请求；b.当某节点收到其邻节点的"退出请求"后，阻止主动向该邻节点发出请求，但允许向除此邻节点之外的其他邻节点发送请求，并且继续接收处理来自所有邻节点的请求。等待已向该邻节点发出的请求都得到响应后，向该邻节点返回"退出确认"消息；c.当退出节点得到入向邻接点的"退出确认"后，向所有邻节点发送"退出通告"，删除所有邻节点及连接；d.当节点收到其邻节点的"退出通告"后，删除该邻节点及相关连接。(3)节点替换，如图5所示。旧节点被新节点替换，新旧节点接口保持一致，替换可以看成是退出和加入的一种特殊组合。a.旧节点向其入向邻节点(即其入向连接关联到的邻节点)发出"替换请求"，并停止主动向所有邻节点发送服务调用请求，但继续接收请求；b.当某节点收到某邻节点的"替换请求"后，阻止主动向该邻节点发出请求，但允许向除此邻节点之外的其他邻节点发送请求，并且继续接收处理来自所有邻节点的请求。等待已向该邻节点发出的请求都得到响应后，向旧节点返回"替换确认"；c.旧节点收到"替换确认"后，将其连接信息迁移到新节点上，再删除自身所有连接；d.新节点建立相应连接之后，向所有邻节点发送"替换通告"消息；e.当节点收到"替换通告"消息，将相应的原连接重定向到替换后的新节点上，并被重新激活即允许向替换后的节点发出请求。二、下面以图6所示的服务协同应用系统为例给出上述技术方案的具体实施方法。图6描述的应用系统中包括customer、agent、contractorl、constractor2四个节点，各节点间的交互关系如下customer向agent发出服务请求，agent将请求传递给相应的2个contractor,包括contractorl、contractor2，contractor再与customer交互，同时也将交互情况汇报给agent。在图6中，圆圈代表参与协同的服务节点，线表示节点之间的连接关系(调用关系)。每类节点的BPEL模型片断如下表1、表2和表3所示。表1是customer节点的BPEL模型片断，包含2个partnerLink,其中name为customer2agent的partnerLink表示customer可以i青求agent的月艮务；name为customer2contractor的partnerLink表示customer可以又寸其4也节点提供服务，接受其他节点的请求。表1customer的BPEL模型片断〈processname=〃customer〃〉<table>tableseeoriginaldocumentpage9</column></row><table>表2是agent的BPEL模型片断，包含3个partnerLink,其中name为agent2customer的partnerLink表示agent可以对其他节点提供服务，接受其他节点的请求；name为agent2contractorl禾口agent:2contractor2的partnerLink表示agent既可以请求contractorl、contractor2的服务，也可以接受这两个节点的请求。表2agent的BPEL模型片断<table>tableseeoriginaldocumentpage9</column></row><table>表3是constratorl/2节点的BPEL模型片断，包含2个partnerLink,其中name为customer2customer的partnerLink表示constractor可以i青求agent的月艮务；name为customer2agent的partnerLink表示contractor既可以乂寸agent节点提〈共月艮务，也可以请求agent节点的服务。表3contractor的BPEL模型片断<table>tableseeoriginaldocumentpage10</column></row><table>在系统初始化阶段，各类节点根据其BPEL描述建立扩展模型步骤如下1.customer节点(1)对于"name"属性为"customer2agent"的partnerLink,将其partnerRole指示的节点agent加入customer邻节点集合中，定义一条出向连接CtoA，并关联到agent;(2)向邻节点agent发送"邻节点通告"消息，且该消息包含customer自身的节点信息；(3)当收到contractorl的"邻节点通告"消息，将contractorl加入到邻节点集合中，建立一条入向连接CtoCl，并关联到contractorl，同样地，当收到contractor2的"邻节点通告"消息，将contractor2加入到邻节点集合中，建立一条入向连接CtoC2，并关联到contractor2。2.agent节点(1)对于"name"属性为"agent2contractorl"禾口"agent2contractor2"的partnerLink,将其partnerRole指示的两个节点contractorl禾口contractor2力口入至[Jagent的邻节点集合中，定义两条出向连接AtoC10ut，AtoC20ut，分别关联到contractorl禾口contractor^;(2)向contractorl和contractor2两个邻节点分别发送"邻节点通告"消息，且该消息包含agent自身的节点信息；(3)当收到customer、contractorl、contractor2的"邻节点通告"消息，由于contractorl和contractor2已在邻节点集合中，所以只需将customer加入到其邻节点集合中，建立入向连接.At.o.C,、,AtoCrin、AtoC2In，并分别关联到customer、contractorl、contractor2。3.contractorl(2)节点(1)对于"name"属性为"contractor2customer"禾口"contractor2agent"的partnerLink，将其partnerRole指示的两个节点customer禾口agent力口入至ljcontractorl(2)的邻节点集合中，定义出向连接CtoC和CtoA且分别关联到customer禾口agent;(2)向邻节点ciistomer、agent发送"邻节点通告"消息，且该消息包含contractorl(2)自身的节点信息；(3)当收到agent的"邻节点通告"消息，由于agent巳在邻节点集合中，只需建立一条入向连接AtoC，且关联到contractorl(2)。在系统运行阶段，系统的基本演化操作包括新节点加入、节点退出、节点替换。下面列举三种情形分别描述系统演化方法的实施步骤。1.新节点contractors加入，假设节点之间接口是相匹配的，加入后系统结构如7所示。(1)contractors向agent发出"加入请求"消息，该消息包含contractor3节点自身信息以及对agent提供的端口的要求；(2)当agent收到"加入请求"后，判断是否满足端口要求，若具有要求的端口类型，返回"接受"消息，并将contractor3加入到邻节点集合中，建立一条入向连接CtoA并关联至(Jagent;(3)当agent收到"接受"响应，将contractor3加入到邻节点集合中，并建立一条到contractor3的出向连接AtoC3，且关联到contractor3;(4)contractor3向customer节点发送"加入请求"消息，该消息包含contractor3的节点信息；(5)当customer收到"加入请求"消息后，返回将contrator3加入到邻节点集合中，"接受"消息并，建立一条入向连接CtoC3，且关联到contractor;(6)当contractor3收到"接受"响应，将customer加入到邻节点集合中，并建立一条出向连接CtoC，且关联到customer。2.节点contractorl退出，退出后系统结构如8所示。(1)contractorl向agent发出"退出请求，，，停止主动向customer发出请求，继续接收agent的请求；(2)当agent收到contractorl的"退出请求"后，停止向contractorl发出请求，并等待已向contractorl发出的请求得到响应，这之后，向contractorl返回"退出确认"消息；(3)当contractorl收到"退出确认"消息后，向所有邻节点发送"退出通告"，删除所有邻节点包括agent和customer以及相关连接。(4)当customer收妾廿contractorl的"退出通告"后，将contractorl从令P节点集合中移除并删除相关连接CtoCl;(5)当agent收到contractorl的"退出通告"后，将contractorl从邻节点集合中移除并删除相关连接AtoCl。3.节点agent被agent'，替换后系统结构不变仍如图6所示。(1)agent向customer、contractorl、contractor2发出，，替换请求，，(包含agent，信息)，并停止主动发起对contractorl、contractor2的服务调用请求；(2)当customer收到agent的"替换请求"后，停止主动向agent主动发出请求，等待已向agent发出的请求都得到响应后，向agent返回"替换确认"；(3)当contractorl收到agent的"替换请求"后，停止主动向agent主动发出请求，等待已向agent发出的请求都得到响应后，向agent返回"替换确认"；(4)当contractor2收到agent的"替换请求"后，停止主动向agent主动发出请求，等待已向agent发出的请求都得到响应后，向agent返回"替换确认"(5)当agent收至Ucustomer、contractorl、contractor2的"替换确认'，消息后，将其连接信息迁移到agent'上，再删除自身所有连接；(6)agent'根据agent的原连接信息建立相应的连接并向customer、contractorl、contractor2发送"替换通告"消息；(7)customer、contractorl、contractor2收到替换完成"消息后，将连接重定向到agent'上，并重新激活即允许向agent'发出请求。权利要求1、一种服务协同中基于系统结构的动态演化方法，其特征在于步骤如下第一步，对基于BPEL的服务协同模型进行扩展，即在单个节点的BPEL服务协同模型中添加服务协同系统的结构信息，完整显示地定义系统内各服务节点之间服务调用的依赖关系；第二步，基于上述扩展的包含结构信息的BPEL服务协同模型，在系统运行态下驱动服务协同应用系统进入安全状态，然后对系统结构进行相应修改以实现动态演化，基本的动态演化操作包括新节点加入、节点退出和节点替换。2、根据权利要求l所述的服务协同中基于系统结构的动态演化方法，其特征在于所述步骤(1)在单个节点的BPEL服务协同模型中添加服务协同系统结构信息的实现方法为(1)在节点的BPEL模型基础上增加"邻节点"和"连接"元素，其中连接具有方向性，包括出向和入向，它的方向用于指示节点与其邻节点之间的服务调用关系，一个邻节点关联一到多个连接，一个连接有且仅有一个邻节点与之关联；(2)通过解析节点BPEL模型以及邻节点通告机制，完善扩展模型，其步骤如下a.由partnerLink列表得到扩展模型中的部分邻节点与连接信息；b.向当前邻节点集合中的所有邻节点发送"邻节点通告"消息，且该消息包含当前节点信息；c.根据收到的"邻节点通告"消息，补充缺失的邻节点与连接信息。3、根据权利要求2所述的服务协同中基于系统结构的动态演化方法，其特征在于所述步骤U)a的实现为设其partnerLink列表为PUiste，partnerLink的partnerRole指示的节点记为partner,实现步骤如下第l步遍历PLlist中的partnerLink;第2步若partnerlink的partnerRole属性为空，转第5步；第3步若partner不在当前节点的邻节点集合中，则将partner加入到neighbor集合中；第4步创建一个出向连接，并将连接关联到partner上；第5步是否遍历完PLlist中的所有partnerLink，若不是转第1步，否则结束。4、根据权利要求2所述的服务协同中基于系统结构的动态演化方法，其特征在于所述步骤(1)c的实现为设发送"邻节点通告"消息的源节点记为source,实现步骤如下-第1步对于收到的每一条"邻节点通告"消息，重复执行第2-3步；第2步若souixe不在当前节点的邻节点集合中，则将source加入到邻节点集合中；第3步创建一条入向连接，关联到source上。5、根据权利要求l所述的服务协同中基于系统结构的动态演化方法，其特征在于所述步骤(2)新节点加入的方法为(1)新节点向某在线节点发送"加入请求"，该消息中包含新节点调用在线节点服务的端口信息以及新节点自身信息；(2)当某在线节点收到"加入请求"后，判断是否满足消息中指示的端口要求，若满足，则返回"接受"消息并将新节点加入到其邻节点集合中，建立一条入向连接并关联到新节点，否则返回"拒绝"消息；(3)若新节点收到"接受"响应，则将此在线节点加入到其邻节点集合中，并创建一条出向连接联到该在线节点。6、根据权利要求1所述的服务协同中基于系统结构的动态演化方法，其特征在于所述步骤(2)节点退出的方法为(1)退出节点向其入向邻节点，即其入向连接关联到的邻节点发出"退出请求"，并停止主动向所有邻节点发送服务调用请求，但继续接收请求；(2)当某节点收到其邻节点的"退出请求"后，阻止主动向该邻节点发出请求，但允许向除此邻节点之外的其他邻节点发送请求，并且继续接收处理来自所有邻节点的请求。等待己向该邻节点发出的请求都得到响应后，向该邻节点返回"退出确认"消息；(3)当退出节点得到入向邻接点的"退出确认"后，向所有邻节点发送"退出通告"，删除所有邻节点及连接信息；(4)当节点收到其邻节点的"退出通告"后，删除该邻节点及相关连接。7、根据权利要求l所述的服务协同中基于系统结构的动态演化方法，其特征在于所述步骤(2)中节点替换的方法为(1)旧节点向其入向邻节点，即其入向连接关联到的邻节点发出"替换请求"，并停止主动向所有邻节点发送服务调用请求，但继续接收请求；(2)当某节点收到某邻节点的"替换请求"后，阻止主动向该邻节点发出请求，但允许向除此邻节点之外的其他邻节点发送请求，并且继续接收处理来自所有邻节点的请求。等待已向该邻节点发出的请求都得到响应后，向旧节点返回"替换确认"；(3)旧节点收到"替换确认"后，将其连接信息迁移到新节点上，再删除自身所有连接；(4)新节点建立相应连接之后，向所有邻节点发送"替换通告"消息；(5)当节点收到"替换通告"消息，将相应的原连接重定向到替换后的新节点上，并被重新激活即允许向替换后的节点发出请求。全文摘要用一种服务协同中基于系统结构的动态演化方法，其步骤为第一步，对基于BPEL的服务协同模型进行扩展，即在BPEL服务协同模型中添加服务协同系统结构信息，完整显示地定义系统内各服务节点之间的依赖关系；第二步，基于上述扩展的包含结构信息的BPEL服务协同模型，驱动服务协同应用系统进入安全状态，并针对新节点加入、节点退出、节点替换三种实现演化操作，修改系统结构。本发明能够支持运行时刻下服务节点的加入、退出、替换等动态演化操作，并且在保证系统的一致性的前提下尽量减小对整个系统的干扰。文档编号H04L29/08GK101340453SQ20081011812公开日2009年1月7日申请日期2008年8月12日优先权日2008年8月12日发明者敏刘,斗孙,赵永望,马殿富申请人:北京航空航天大学