面向服务环境中基于模板实现BPEL子流程复用的方法及系统

摘要

本发明公开了一种面向服务的开发环境中基于模板机制实现BPEL子流程复用的方法及系统。其包括：对模板进行模型定义，以保存抽取BPEL子流程进行复用所需要的相关信息；对已有的BPEL文件和相关联的WSDL文件进行解析，建立BPEL和WSDL模型，根据所建立的模型，从已有BPEL文件中抽取需要的BPEL子流程，封装成模板并保存到模板库中；开发时从模板库中读取模板信息，将模板调入到BPEL流程可视化开发窗口，使用户在进行BPEL流程开发的同时也能调用模板来辅助流程设计和开发，从而实现模板机制和BPEL流程开发的统一。本发明可实现对BPEL子流程的复用，能通过预先设计的行业内通用流程模板或者用户自定义复用模板，大大减少开发人员的工作量，提高服务组合的开发效率，缩短开发周期。

说明书

技术领域

本发明涉及面向服务的开发技术领域，具体地说，是面向服务的开发环境中基于模板机制实现BPEL子流程复用的方法及系统。

背景技术

随着面向服务思想的出现，用服务组合的方法来构建系统成为了目前的研究热点。而Web Services技术是目前把一个信息系统封装成服务的主要方法，也是SOA(Service-Oriented Architecture，面向服务的体系结构)设计思想的一个重要部分，基于Web Service的服务组合的方法可以降低系统开发的难度和复杂度，提高系统对复杂多变的业务需求的适应能力。技术人员可以通过对已有Web Service的组合，设计并实现一套完整的解决方案来适应复杂多变的业务需求。

在Web Service的服务组合中，一般可以通过某种脚本语言来描述最终的组合流程，并在支持该脚本语言的引擎上部署和运行。这种脚本语言被成为服务编排语言，属于服务编排这一层。目前，比较成熟的服务编排语言主要有BPEL(Business Process Execution Language，业务流程执行语言)。目前，对于BPEL脚本的开发，IBM、Oracle和微软等公司都提供了广泛的支持。这些公司都提供了自己开发的BPEL执行引擎和与之配套的BPEL脚本图形化的开发环境。但是在众多的执行引擎和图形化开发环境中，对于BPEL脚本的复用机制始终缺乏一套灵活完善的解决方案，绝大多数的系统只是提供部分支持，且使用起来难度大。

考虑到在现实生活中，实际上利用BPEL来进行Web Services间的组合和系统开发，大都是基于一定的行业领域内进行开发的。而一个行业领域内部，其实有很多业务的逻辑和功能是可以被重复使用的。但是这种重复使用的层次和粒度也可能是多种多样的。因此希望能够有效的复用这些逻辑功能，也必然需要提供一套灵活性高的服用机制。同时，同一行业领域内部，不同的解决方案间，对于同样的业务也都会有着自己特有的逻辑设计，这就意味着系统也要给用户足够的自主性，让其对复用的逻辑能进行自主控制。

而且，由于系统的复杂性和现实需求的变更等等原因，都不可避免的要对已有的BPEL脚本进行新的开发或者修改。尤其是在创建新的相关流程时，往往会重复使用到以前开发过的BPEL片段，但是如果都进行BPEL流程的封装，又势必会造成在流程结构和层次上的复杂性，带来不便。

因此，现有的BPEL应用方面存在着一些不足：首先，BPEL流程开发对具体实际场景的依赖性较大，针对不同的业务场景需要使用原子粒度的开发单元设计实现新的流程，缺乏一定的灵活性；其次，目前对BPEL的开发缺乏一套完备的复用机制，现有的BPEL Designer仅提供BPEL基本活动，这样导致重复开发的工作量很大，目前，针对这一问题，还没有一套有效的解决方案。

发明内容

本发明要解决的技术问题是提供一种面向服务的开发环境中基于模板机制实现BPEL子流程复用的方法及系统，可以实现对BPEL子流程的复用，也能预先设定行业内通用的业务流程模板，从而大大减少开发人员的工作量，提高面向服务的开发效率，缩短开发周期。

为了解决上述技术问题，本发明提供了一种面向服务的开发环境中基于模板机制的BPEL子流程复用的方法，包括以下步骤：

A.生成模板步骤：解析BPEL流程的结构，接收用户的指令定位需要进行复用的BPEL子流程，然后抽取用户需要复用的BPEL子流程，根据定义的模板模型对子流程进行封装，并且给出封装后模板的接口定义，最后将生成的模板保存到本地的模板库中；

B.组装模板步骤：将模板库中的模板加载到业务流程的编辑开发环境中，并与模板库保持同步更新，并提供对于模板的接口的对接；对模板进行相应的BPEL语法验证和模板相关检验；

C.导出模板步骤：将含有模板扩展标签的BPEL业务流程转换为标准的可执行的BPEL，包括将调用的已经封装的BPEL模板中的变量、条件参数根据接口中的参数进行实例化的转换，得到符合具体流程要求的BPEL片段，然后补充完整BPEL流程，得到可执行的标准BPEL流程。

进一步地，所述步骤A具体包括：

A1.对BPEL文件进行解析；

A2.建立BPEL的树形结构，并把该结构提供给图形化显示模块；

A3.图形化显示模块用可选多叉树的方式来展示整个BPEL的层次结构给用户，清楚表示出节点的层次包含关系、节点的名称、类型和相关属性；

A4.用户从所BPEL树形结构选取自己需要抽取封装成为模板的部分；

A5.将用户选中的BPEL片段提取出来保存至模板中，同时将该BPEL片段相关的属性信息和WSDL信息都一并提取出来；

A6.展示提取的BPEL片段中，需要用户进行操作的接口信息，包括输入变量、输出变量和控制条件，保存至模板文件中，并将得到的模板保存到模板库中。

进一步地，所述步骤A1中对BPEL文件进行解析包括：

a)读取用户指定进行模板抽取的BPEL文件，通过XML解析，首先创建BPEL文档对象；

b)根据用户指定的相关联的WSDL文件，配合解析BPEL文件时，取得所引入的WSDL文件信息，提取WSDL文件中的message、partnerLinkType和portType元素的信息进行保存；

c)采用递归的方式来遍历整个BPEL文件的树形结构，解析每一个BPEL活动，对于BPEL基本活动提取出variable、partnerLinkType和portType属性添加到模板中进行保存；对于BPEL容器活动，如果存在控制条件的，提取其condition的属性值添加到模板信息中进行保存。

进一步地，所述步骤A6中，所述展示的输入变量和输出变量通过以下方式得到：

首先，找出复用的BPEL子流程中的所有变量。保证在封装模板的接口时，不会出现变量的丢失现象；

然后，遍历子流程中的所有活动，确定子流程中的输入变量集合和输出变量集合；

最后，去除两个集合中的公共变量，得到所述BPEL模板封装时所需定义的输入变量和输出变量。

进一步地，所述步骤A中，模板的封装具体包括：

解析抽取出来的BPEL片段，分析得到其包含的所有BPEL活动，并将每个BPEL活动都保存到节点列表nodeList中。

读取nodeList中当前的BPEL活动，判断该BPEL活动是BPEL的基本活动，还是BPEL的容器活动，如果是BPEL基本活动，提取BPEL基本活动中的各个变量；如果是BPEL的容器活动，则继续判断该容器活动是否含有控制条件，如果该容器活动中包含控制条件，先将控制条件抽取出来保存到模板中，然后将控制条件所在的路径也保存到模板中，判断抽取出来的控制条件中是否含有变量，如果有，将所有的变量解析出来保存到输入变量列表中；如果没有，结束节点的变量分析；如果容器活动中不包含控制条件，再判断该容器活动是否是scope活动，如果是，判断该scope活动中是否定义了局部变量，如果定义了局部变量，则将所有的局部变量保存到输出变量中，如果scope活动中没有定义局部变量，结束节点的变量分析。

进一步地，所述步骤B具体包括：

读取模板库中所有的模板信息，并且导入到图形界面显示面板中；

用户从所述图形界面显示面板中选择活动或连线，如果用户选择的是活动，判断用户选择的是BPEL活动还是模板，如果是BPEL活动，先在编辑窗口中显示此BPEL活动的图标，然后由用户对所添加的BPEL活动的属性进行设置：如果是BPEL基本活动，为该活动创建或者导入其依赖的partnerLink，然后再为该活动创建和导入相关的变量；如果用户选择的是容器活动，同时该容器活动有控制条件需要指定，由用户添加对应的控制条件；

如果用户选择了模板，首先在编辑窗口中显示模板图标，提取模板文件中保存的信息，导入该模板所依赖的WSDL文件、partnerLink和变量；

如果用户选择的是连线，由用户指定好该连线的源和目标，在编辑窗口上显示出连线，判断此时连线的目标节点是否为模板，如果是，由用户为模板选择匹配的输入变量，或为模板添加匹配的控制条件，保存用户对于模板做出的修改操作，判断用户是否还继续编辑流程，如果是，重复上述的过程；如果否，保存退出。

进一步地，用户完成模板接口交互操作保存退出时，触发以下操作：

读取变量列表variableList中的变量信息，并获取某节点所在的模板信息；

判断该节点所在的模板是否为当前正在编辑的模板，如果不是，继续读取variableList中的变量信息；如果是，首先建立对应的BPEL文件即完整的BPEL树，根据模板中保存的变量路径信息，定位到要修改的变量或者是条件在模板中的位置，然后更新BPEL代码的信息，

判断variableList中是否还有变量没有处理，如果有，读取未处理的变量进行上述处理；如果没有，结束循环。

进一步地，所述步骤C具体包括：

C1.首先遍历整个流程代码中的连线，将所有连线连接的节点都添加到nodeList中，在该nodeList中没有相同的节点；找到整个流程的起点，然后读入当前锁定的节点；

C2.判断当前锁定的节点是BPEL活动还是模板；

C3.如果当前节点是BPEL活动，转到步骤C4；如果当前节点是模板，提取模板中保存的BPEL片段，然后根据拼接时保存的修改操作，对提取出的BPEL片段进行更新操作，转到步骤C4；

C4.将该节点按照连线的顺序和层次关系导出到指定的BPEL文件中保存，在为BPEL活动时导出的是本身的活动定义和相关的属性定义；在为模板时导出模板中定义好的但是已经更新过的BPEL片段；

C5.在BPEL文件中导入与当前节点相关的WSDL文件，以及相关的partnerLink和variable的定义；

C6.判断是否还有节点没有导出到指定的BPEL文件中，如果有，读取下一个节点，执行步骤C2～C5；如果没有，跳出循环，完成导出过程。

本发明还提供了一种面向服务的开发环境中基于模板机制实现BPEL子流程复用的系统，包括：

BPEL脚本解析模块，用于对BPEL脚本进行解析，通过基于Dom的XML解析，依赖BPEL的EMF模型，对用户要抽取的BPEL脚本以及相关联的WSDL文件建立树形模型，获取BPEL脚本中的每一个BPEL活动的信息；

模板抽取和封装模块，根据所述BPEL脚本解析模块的解析结果，用于对用户选中的BPEL脚本片段进行抽取，通过给用户展示整个BPEL的结构，由用户选择需要进行抽取和封装的BPEL逻辑；在确定抽取的BPEL代码后，根据已有的Template Schema封装生成模板，保存到模板库中；

服务组合模块，用于开发BPEL业务流程并且融合模板机制，完成对业务流程的开发；完成对模板的组合操作，包括：对接口中定义的所有输入变量进行对应地赋值操作；对接口中定义的所有控制条件进行对应地重设操作；提供了BPEL的基本活动和结构化活动来帮助模板组合以及操作。

进一步地，还包括：

新业务导出模块，用于对已经编辑好的业务流程导出生成可执行的BPEL脚本，包括：对图形化文件的分析，得到一系列有效的节点，同时将其中的模板中包含的有效信息提取出来，最后一个保存到BPEL脚本中。

本发明提供的面向服务的开发环境中基于模板机制实现BPEL子流程复用的方法及系统，其灵活性好，抽取和组合的层次多样，粒度也能进行很好的控制；可以基于图形化的开发界面，同时包含了BPEL流程和模板融合的业务流程开发，能有效的降低用户二次开发的工作；利用本发明，用户可以使用基于模板的扩展标签来协助开发，但是最终可转换成可执行的、符合规范的WS-BPEL脚本，能在不同的BPEL执行引擎上运行；能够很好的根据用户的需求来生成其所需的模板，或者预先设计好行业内的通用业务流程模板，具有很高的可定制性。

附图说明

图1是本发明的面向服务的开发环境中代码复用的方法的示意图；

图2是模板模型的schema的定义结构的一实施例的示意图；

图3是本发明进行服务抽取的流程图；

图4是对BPEL文件进行解析的流程图；

图5是对模板进行封装的示意图；

图6是用户通过调色板使用模板库进行编辑的流程图；

图7是开发过程进行拼接的流程图；

图8是完成对模板连线的编辑后对修改进行保存的流程图；

图9是模板导出的流程图；

图10是本发明的系统验证处理流程图；

图11是本发明的系统的结构图。

具体实施方式

下面结合附图和具体实施例对本发明作进一步说明，以使本领域的技术人员可以更好的理解本发明并能予以实施，但所举实施例不作为对本发明的限定。

本发明是为了增加BPEL开发的灵活性和有效降低开发人员的二次开发的难度，本发明不仅提供了一套完整的BPEL图形化的开发环境，更提出和实现了一套基于模板机制实现BPEL子流程复用的方法和系统，从而让开发人员不仅能通过图形化的方式进行业务流程开发，也能有效的提供一套可行的复用机制降低二次开发的难度，通过预设的行业通用流程模板提高开发效率。本发明拥有独立的模板模型，定义了一套模板标签来扩展实现了模板的抽取、封装、拼接和导出的机制，最终得到的仍然是符合WS-BPEL规范的可执行的BPEL文件，因此，本发明开发的业务流程最终仍然是以BPEL脚本的形式展现，也能在所有的通用的BPEL执行引擎上运行。

如图1所示，本发明通过基于模板的机制来对需要重复利用的BPEL片段进行有效的封装，然后存入到模板库中保存。本发明提供了一套完备的图形化开发环境，不仅能有效的提高开发人员的效率，也能将模板机制和BPEL流程的开发融合在一起，提供一套完整高效的开发方式。在完成流程的编辑之后，系统会将编辑好的流程导出成可执行的BPEL文件，去除之前对于BPEL片段所增加的封装，完成到BPEL脚本的转换。此外，整个系统也提供了完整的验证机制，能对模板抽取、模板组装和模板导出这几个部分都提供BPEL的语法验证支持。同时，对于模板复用机制提供了相应的验证机制。

本发明的代码复用系统为了有效的复用BPEL代码，首先需要完成对于BPEL代码段的描述工作。当系统用户将自己需要进行封装的BPEL代码段抽取出来后，该系统会自动将其封装成为统一形式的模板，通过系统的解析，该模板会详细记录下抽取出来的BPEL代码段的接口信息。因此，该系统必须首先提供了一套模板封装的模型定义，用来保存所需要的相关信息。

系统的模型层完成了对于模板的定义，系统主要通过自定义的扩展标签来完成对模板的各项操作。所以，系统通过定义模板的schema来实现建模的过程。对于需要被复用的BPEL片段，可以理解为一个函数中的代码，而模板就是要给这段代码进行类似函数接口的定义和描述工作。那么作为一个模板，暴露给用户使用时，就必须声明其中的接口定义，主要包括几个方面：

<template>保存当前模板的自身信息，如命名空间和模板名称；

<inputVariable>保存模板中作为输入变量的变量相关信息。包括输入消息中的所有输入参数和参数的结构，以及在哪个活动中使用该输入变量。

<outputVariable>保存模板中作为输出变量的变量相关信息。包括输出消息中的所有输出参数和参数的结构，以及在哪个活动使用了该输出变量。

<element>说明了在变量中定义的具体参数的信息。

<condition>保存模板中作为控制条件的相关信息。包括该控制条件所在的控制活动以及该控制条件的内容和抽取时用户增加的注释。

<activity>保存在抽取的BPEL片段中包含的BPEL活动信息。

<bpelCode>保存模板封装的BPEL片段。

<wsdlCode>保存模板封装的BPEL片段相关联的WSDL文件信息。

模板模型的schema的定义如图2所示。

本发明的系统为用户提供了一套定制自己所需要的BPEL模板，也就是模板抽取的机制。在开发BPEL流程时，尤其是在开发行业领域相关的流程时，有不少的业务逻辑其实都是类似的，或者是部分类似的。对于这些会被频繁使用到的业务逻辑，如果能够将其封装成模板，在开发时作为一个整体使用，必然给开发人员带来极大的便利。

模板抽取是从一个已有的BPEL文件开始的。用户对于自己感兴趣的BPEL流程以及相关联的WSDL文件，通过系统的向导引入到系统中来，然后系统会自动解析该BPEL流程和相关联的WSDL文件，建立BPEL和WSDL模型。然后将BPEL流程的整个结构都以图形化的树形结构展示给用户。用户此时可以选择自己需要复用的BPEL逻辑，让系统进行模板的抽取和封装，生成用户感兴趣的模板，或者是用户创建自己行业内通用的业务流程模板，然后保存到模板库中。

该系统提供了良好的灵活性和定制性，能让用户使用该系统建立自己的模板库，可以将自己感兴趣的BPEL业务逻辑封装成模板保存到模板库中。系统提供给用户一套完整的模板抽取和封装的功能。而这些抽取出来的模板能有效降低用户的开发难度。

如图3所示，该系统在进行服务抽取的时候主要包括以下步骤：

1.BPEL文件的解析。其具体的过程如图4所示。

a)读取用户指定进行模板抽取的BPEL文件，通过XML解析，首先创建BPEL Document对象。

b)根据用户指定的WSDL文件，配合解析BPEL文件时，取得所引入的WSDL文件信息。提取WSDL文件中的message、partnerLinkType和portType元素的信息进行保存。

c)采用递归的方式来遍历整个BPEL文件的树形结构，解析每一个BPEL活动。对于是BPEL基本活动提取出variable、partnerLinkType和portType等属性添加到模板中进行保存。对于BPEL容器活动，如果存在控制条件的，应该提取其condition的属性值添加到模板信息中进行保存。

2.对进行模板抽取的BPEL文件和WSDL文件的解析工作完成后，系统会相应的建立BPEL的树形结构，并把这个结构提供给wizard的图形化显示模块。

3.图形化显示模块在接收到请求后，会用可选多叉树的方式来展示整个BPEL的层次结构给用户，其中会清楚表示出节点的层次包含关系，以及节点的名称，类型和一些有关的属性，如condition或variable等。

4.然后，用户针对展示出来的BPEL结构图，选取自己需要抽取成为模板的部分。

5.然后，系统就会将用户选中的BPEL片段提取出来，保存至模板中。同时，将这段BPEL代码相关联的属性信息和WSDL信息都一并提取出来。

6.展示提取的BPEL片段中，需要用户进行操作的接口信息，主要包括输入变量、输出变量和控制条件。用户此时还可以对每个变量和条件添加自己的注释，以方便其他的用户使用该模板。

7.然后，将BPEL片段，解析出来的变量值和控制条件等信息都保存至模板文件中，也就完成了对模板的封装工作。

8.最后，将得到的模板保存到指定的模板库中。

系统在对模板进行封装时，需要确定该模板的接口的相关信息，主要是输入变量、输出变量以及模板中包含的控制条件。但是在一个流程片段中存在很多的活动，这些活动都会使用到变量，如何来区分其中哪些是需要外界输入的变量，哪些是输出给外界的变量，还有哪些变量只是在抽取的BPEL片段内部使用的。基本的思路是对抽取出来的BPEL片段进行解析，对其中包含的每一个BPEL活动所使用的变量进行分析。建立两个集合，一个用来存储每个活动需要输入的变量，另一个用来存储每个活动需要输出的变量。采用集合的话，每个集合中不会包含有重复的变量。完成集合后，就将两个集合中公共的变量去除，因为这部分共有的变量也就是在抽取的BPEL片段内部使用的变量，与片段外的流程没有什么联系。在输入集合中剩余的部分就是封装模板中需要的输入变量，而在输出集合中剩余的部分就是封装模板中将会输出的变量。

模板封装具体的实现步骤如图5所示，包括：

1.解析抽取出来的BPEL片段，分析得到其包含的所有BPEL活动，并每个BPEL活动都保存到nodeList中。

2.如果nodeList不为空，进入循环。读取nodeList中当前的BPEL活动。

3.判断从nodeList中读取出来的BPEL活动是BPEL的基本活动，还是BPEL的容器活动。

4.如果此时的BPEL活动是BPEL基本活动，则开始提取BPEL基本活动中的各个变量。由于不同的BPEL基本活动对于变量的使用是不一样的，所以这里需要分别对待。

5.如果读入的BPEL基本活动是invoke活动，则提取invoke活动中的inputVairable保存到输入变量列表中。然后再提取invoke活动中的outputVariable保存到输出变量列表中。

6.如果读入的BPEL基本活动是assign活动，则提取assign活动中的from中的变量保存到输入变量列表中。然后再提取assign活动中的to中的变量保存到输出变量列表中。

7.如果读入的BPEL基本活动是receive活动，则提取receive活动中的variable保存到输入变量列表中。

8.如果读入的BPEL基本活动是reply活动，则提取reply活动中的variable保存到输出变量列表中。

9.如果读入的BPEL基本活动是onMessage活动，则提取onMessage活动中的variable保存到输入变量列表中。

10.如果读入的BPEL基本活动是onEvent活动，则提取onEvent活动中的variable保存到输入变量列表中。

11.判断从nodeList中读取出来的BPEL活动是BPEL的容器活动，则继续判断该容器活动是否含有控制条件。

12.如果该容器活动中包含控制条件的话，先将条件抽取出来保存到模板中，然后将控制条件所在的路径也要保存到模板中。

13.判断抽取出来的控制条件中是否含有变量。

14.如果控制条件中含有变量的话，将所有的变量解析出来保存到输入变量中列表。如果控制条件中没有包含变量的话，结束节点的变量分析。

15.如果判断容器活动中不包含控制条件，接着需要再判断该容器活动是否是scope活动。

16.如果是scope活动还要继续判断该scope中是否定义了局部变量。

17.如果scope活动中定义了局部变量，则将所有的局部变量保存到输出变量中。

18.如果scope活动中没有定义局部变量，结束节点的变量分析。

本发明的系统对于模板的使用和创建一个BPEL活动没有什么区别，也就是说该系统将模板的使用与BPEL的流程开发有机的结合在一起。当该系统的用户打开图形编辑窗口，希望开发一个新的业务流程时，该系统会在提供BPEL的基本编辑能力之外，也提供基于模板的流程编辑方式。

系统会自动读入在模板库中保存的模板的信息，将模板导入到当前的业务流程编辑窗口中，以供用户随时使用。这样用户就能轻松的复用已经抽取出来的模板了。为自己的模板定义上相关的变量信息和控制条件，同时配合上BPEL活动来进行模板的控制和补全，这样就能快速组合开发出用户所需要的新流程了。

当已经建立了对应的模板库后，就可以以模板库中的模板作为起点，配合上BPEL的基本活动和容器活动实现灵活的业务开发方式。

如图6所示，当用户打开编辑窗口开始创建新的业务时，调色板模块会自动读取此时模板库中所有的模板信息，并且导入到图形界面显示，以供调用。然后用户会多次拖拽需要使用的BPEL活动或者是模板进入编辑窗口，通过连线来确定各个活动之间的关系。通过图形化的方式来完成系统和用户之间的交互，帮助用户以图形拖拽的方式来完成流程的编辑工作。

在进行流程的拼接的过程中，其具体的步骤如图7所示，包括：

1.调色板模块会自动读取此时模板库中所有的模板信息，并且导入到图形界面显示面板中，以供调用。

2.用户想要编辑流程，因此从调色板中拖拽一个图标到编辑窗口中。此时，需要判断用户选择的是活动的图标还是选择的连线。

3.如果用户选择的是活动，接着判断用户选择的是一个BPEL活动，还是选择了一个模板。

4.如果用户选择的是一个BPEL活动，那么首先在编辑窗口中显示此BPEL活动的图标。

5.然后用户需要对所添加的BPEL活动的属性进行相应的设置。如果是BPEL基本活动，那么需要为该活动创建或者导入其依赖的partnerLink，然后再为该活动创建和导入相关的变量。如果用户选择的是容器活动，同时该容器活动有控制条件需要指定时，如：if的判断条件，那用户应该添加对应的控制条件。

6.如果用户没有选择BPEL活动，而是选择了添加一个模板。首先也是在编辑窗口中显示模板图标。

7.提取模板文件中保存的信息，导入该模板所依赖的WSDL文件。

8.提取模板文件中保存的信息，导入该模板所依赖的partnerLink。

9.提取模板文件中保存的信息，导入该模板所依赖的变量。

10.如果用户一开始选择的是添加一个连线。用户指定好该连线的源和目标，在编辑窗口上显示出连线。

11.判断此时连线的目标节点是不是一个模板。

12.如果连线的目标节点是一个模板，用户可以双击该连线，系统会弹出一个接口编辑窗口，用来完成与用户的交互操作。在此用户可以为模板选择匹配的输入变量，也可以为模板添加匹配的控制条件。系统保存用户对于模板做出的修改操作。

13.用户是否还继续编辑流程。如果继续则重复上面的过程。如果用户完成了编辑的话，就可以保存退出了。

如图8所示，当用户完成对于模板连线的编辑后，点击保存退出时，会触发下列步骤来实现对修改的保存。

1.首先读取variableList中的变量信息，并获取某节点所在模板信息。

2.判断是否是当前正在编辑的模板。

3.如果不是当前正在编辑的模板，则继续读取variableList中的变量信息。

4.如果是当前正在编辑的模板，则首先建立对应的BPEL Document，即建立完整的BPEL树。

5.根据模板中保存的变量路径信息，定位到要修改的变量或者是条件在模板中的位置。

6.然后更新BPEL代码的信息。

7.判断是否还有variableList中的变量没有处理。

8.如果variableList中还有变量没有处理，回到第1步进行循环。

9.如果variableList中的变量都已经处理了，结束循环。

当用户完成了基于模板的新的业务流程的开发工作后，此时得到的是基于扩展标签完成的包含有模板的文件。此时得到的文件不是标准的BPEL脚本，无法部署到BPEL执行引擎中运行。所以，该系统提供了一套导出的机制，用来实现将包含模板的流程转换为标准的BPEL可执行文件。这样得到的BPEL脚本就能在任何一个BPEL执行引擎上运行了。

当用户完成了基于模板的业务流程的开发之后，都是为了最终能够得到一个可执行的BPEL文件。此时用户需要将自己编辑好的业务流程导出成BPEL文件，也就是调用系统中的模板导出功能，生成可执行的BPEL文件。

如图9所示，模板导出的过程主要步骤如下所示：

1.首先遍历整个流程代码中的连线，将所有连线连接的节点都添加到nodeList中，在该nodeList中没有相同的节点。

2.找到整个流程的起点，即同时满足这样条件的点：一是本身有连线相连的话，只是作为源节点，而不是目标节点；二是如果本事没有连线相连的话，其也没有父亲节点。三是节点本身是容器活动sequence的话，就是他的第一个孩子节点；这样点就是所需要的流程起点。

3.然后读入当前锁定的节点。

4.判断当前锁定的节点是BPEL活动还是模板。

5.如果当前节点是BPEL活动，则直接到第8步继续执行。

6.如果当前节点是模板，则先必须得提取模板中保存的BPEL片段

7.然后根据拼接时保存的修改操作，对提取出的BPEL片段进行更新操作。然后继续执行第8步操作。

8.不论当前节点是BPEL活动还是模板，都要将该节点按照连线的顺序和层次关系导出到指定的BPEL文件中保存。作为BPEL活动需要导出的是本身的活动定义和相关的属性定义。作为模板需要导出模板中定义好的但是已经更新过的BPEL片段，

9.然后在BPEL文件中导入与当前节点相关的WSDL文件，以及相关的partnerLink和variable的定义。

10.查看是否还有节点没有导出到指定的BPEL文件中，如果还有的话，就准备读取下一个节点，然后循环回到第3步继续执行。

11.如果所有的节点都已经正确导出，跳出循环，完成整个导出的过程。

该系统为这个业务流程的开发过程都提供了相应的验证工作。

模板抽取阶段，会对作为模板的BPEL文件和相关的WSDL文件进行BPEL语法验证。从而保证模板抽取是在一个正确的流程的基础上开始的。

模板拼接阶段，验证会对当前编辑的流程进行BPEL语法的验证，同时，也会在编辑的过程中进行语义上的验证。如：当用户未对模板的输入或输出变量进行匹配时，提醒用户完成操作。当模板充当流程测起点时，要检验模板中是否有可以创建实例的receive或是pick活动。

1.创建bpel文件的DOM模型(即建立bpel文件的内存表示，用树形结构表示bpel文件元素节点之间的层次关系)；

2.进行DOM模型和EMF模型的映射，验证工程利用EMF对BPEL文件进行持久化建模，需要建立DOM模型和EMF模型之间的一一映射关系；

3.将EMF模型转换为INode模型，验证工程使用树形结构对bpel文件进行建模，这种树形结构的节点用INode结构表示。

在对BPEL文件进行建模之后，通过对模型进行两次遍历(two pass walk)完成对BPEL模型中每个节点的语法验证，第一次遍历为第二次遍历提供有用的状态信息。这里，验证器被设计成为BPEL树形结构，这样，对于BPEL树中不同的节点都有相应类型的验证器，如：对于变量有VariableValidator，对于While结构有WhileValidator，对于Until结构有UntilValidator等等；

验证器的输入是BPEL模型的根节点(INode类型)和IModelQuery，输出是一个Iproblem类型的数组，用于保存验证中出现的语法问题。

IModelQuery是一个接口，通过查询实现以下方面的验证

某个BPEL节点是否合法(通过返回一个INode类型的节点)；

变量类型是否匹配；

Xpath表达式的合法性；

问题的准确定位。

验证的基本过程：

1.初始化操作按照BPEL的树形结构依次生成每个模型节点的validator，将它们放入到队列fValidator中；

这里，所有的Validator由factories生成。

Factories在org.eclipse.bpel.validation.model.RuleFactory中实现注册。

关于Validator需要注意如下几点：

(1)Validator针对不同的节点，每个BPEL元素节点可能需要调用很多个Validator；

(2)创建Validator的factory必须实现注册，每个factory都必须实现Ifactory接口完成创建和注册。

2.第一遍遍历

(1)访问fValidator队列中，得到每个validator的相关信息；

(2)调用当前需要执行的fCurrentRule，将它放入至堆栈fStackRule中；

(3)调用Validator利用fCurrentRule进行语法验证。

3.第二遍遍历将第一遍遍历中出现的问题依次放入问题队列IProblem类型的数组。

该系统是基于Eclipse插件开发技术来实现的，主要是利用EMF(EclipseModel Framework)和GEF(Graphical Eclipse Framework)来实现的。其中EMF用来完成建模的工作，GEF用来完成图形化的功能。图2是整个系统设计的结构图，该系统采用MVC(Model-View-Controller)的设计思路来实现。

模型层

模型层是整个系统的基础，提供整个系统图形化和各项功能所需要的模型，系统主要建立了两个基本的模型：BPEL模型和模板模型。

BPEL模型

由于是在BPEL的基础上来生成模板的，首先需要对BPEL进行建模。在WS-BPEL2.0的规范中，已经定义好了BPEL语法的schema，此方案也是基于此而完成BPEL的建模。由于使用了EMF来建模，在导入了BPEL的schema定义后，还需要在模型中增加，对于WSDL的建模来支持BPEL与web service的结合。

模板模型

针对模板进行建模，主要用来实现对于BPEL代码的封装，从而构建能够重复使用的模板。考虑到模板的几个特点：可重复性，灵活性。需要对抽取出来作为模板使用的BPEL代码进行建模，模板模型能清楚的说明BPEL模板的“输入变量”、“输出变量”、“控制条件”和“结构”等信息。这些都是抽取的BPEL代码形成模板后会进行匹配修改的地方，

控制层

控制层是对整个系统中的可视化进行控制操作，并且实现了BPEL脚本解析、模板抽取和封装、服务组合和新业务导出的功能。

BPEL脚本解析模块

BPEL脚本解析模块提供了对BPEL脚本进行解析的功能，通过基于Dom的XML解析，依赖BPEL的EMF模型，就能对用户要抽取的BPEL脚本以及相关联的WSDL文件建立树形模型，获取BPEL脚本中的每一个BPEL活动的信息。

模板抽取和封装模块

在完成了对BPEL脚本的解析操作之后，模板抽取和封装模块主要完成对于用户选中的BPEL脚本片段进行抽取，通过给用户展示整个BPEL的结构，然后由用户来自主选择需要进行抽取和封装的BPEL逻辑。在确定抽取的BPEL代码后，封装模块会根据已有的Template Schema封装生成模板，保存到模板库中。

服务组合模块

服务组合模块主要用来完成对模板的组合操作。在流程中使用到模板时，需要对模板封装出来的接口进行相应的处理，主要进行以下一些操作：

1.对接口中定义的所有输入变量进行对应的赋值操作。

2.对接口中定义的所以条件进行对应的重设操作。

3.提供了BPEL的基本活动和结构化活动来帮助模板组合，以及操作。

服务组合模块还提供了基于BPEL的可视化的交互界面来方便用户完成以上的操作。分析现在编辑的流程中存在哪些变量，以树形结构将其展示出来，能够快捷的编辑这些变量来完成交互操作。

新业务导出模块

新业务导出模块主要用来对已经编辑好的业务流程导出生成可执行的BPEL脚本。用户在完成新业务的图形化开发后得到的文件并不是标准的BPEL脚本，就需要新业务导出模块来完成到BPEL脚本的转换工作。主要完成对图形化文件的分析，得到一系列有效的节点，同时将其中的模板中包含的有效信息提取出来，最后一个保存到BPEL脚本中。

UI层

UI层主要是整个系统的可视化的部分，主要实现了调色板、编辑窗口、属性视图、大纲视图和向导视图等功能。

调色板

调色板主要用来显示用于流程组合的活动和模板，这里是图形化编辑的起点。

调色板的内容有两部分组成：BPEL活动和模板库中的模板。所以每次打开图形化的编辑界面时，调色板都会完成与模板库的同步跟新操作。

1.读取模板库

2.遍历模板库中的所有模板

3.在调色板中显示出所有的模板，如果模板库添加了新的模板，或者是删除了过时的模板，都能在调色板中保持更新。

编辑窗口

编辑窗口主要用来进行流程的编辑组合。当从调色板中选中一个BPEL活动或者模板，然后拖拽到编辑窗口中。这里能将BPEL活动和模板二者有机的结合在一起进行业务逻辑的开发。

属性视图

属性窗口主要用来显示在编辑窗口中被选中的图标代表的活动的属性，当没有选中任何图标时，属性窗口显示背景的相关信息。

大纲视图

大纲视图主要显示当前窗口中所有的活动的简单信息和层次包含关系。

向导视图

该系统主要实现了两个向导视图，一个是导入向导，另一个是导出向导。导入向导用来完成模板的抽取过程的用户交互，最终实现模板的封装和保存。导出向导用来完成新的业务流程导出成可执行的BPEL脚本的用户交互，有用户来制定导出的目标目录和文件名，并将导出的文件以指定文件名保存到指定目录。

验证层

验证层的主要功能是在系统流程的不同阶段对系统中的相关操作进行必要的验证工作。主要是正对三个阶段来实施对应的验证工作：模板抽取、模板组合和模板导出，进而也是对系统的各个层次的操作进行对应的验证工作：模型建立、BPEL脚本解析、模板抽取、服务组合和新业务生成等操作。

以上所述实施例仅是为充分说明本发明而所举的较佳的实施例，本发明的保护范围不限于此。本技术领域的技术人员在本发明基础上所作的等同替代或变换，均在本发明的保护范围之内。本发明的保护范围以权利要求书为准。