随着Web Service技术的不断成熟和飞速发展越来越多的Web Service涌现在人们的眼前，并且网络上已经存在的和即将产生的Web Service也开始让人们担优，如何重用这些Web Service也逐渐成为科研人员的新课题。诸多国际著名公司如微软、IBM、惠普等也在为从Web服务的整合推出多种整合标准，如BPMI、BPMN、 BPEL4WS、BPSS、WSCI，尤其是BPMN和BPEL4WS越来越被世人所重视但是至今仍然没有一个统一的标准为世人所公认，这一课题仍有待进一步研究。
1 国内外研究现状
Web Service整合的研究目前还处于对整合方法的研究，如何利用现有整合语言描述整合需求，且该整合语言可以直接或间接地驱动执行引擎，是目前对Web Service整合方法研究的主体思路。目前与业务流程管理相关的多种标准己经诞生，BPMI推出的BPNL和BPMN以及微软和IBM联合推出的 BPEL4WS语言，惠普推出的WSCL语言以及BEA推出的WSCI等，但是上述标准中只有BPEL4WS可以与执行引擎相关联，现己推出的执行引擎有 IBM的BPWS4J，Collaxa的BPEL Service和Open Storm的Choreo Server。虽然它们还不够成熟，但比之人工参与操作的优越性是显而易见的。目前国内外对Web Service整合方法的研究范围较广，使用的整合方法有基于UML、BPEL、ZenFlow以及多种基于工作流的动态整合方法。
本文所采用的BPMN首先是基于过程代数Pi-演算的，具有数学的严密性和流程的操作独立性，且BPMN适合跨应用的集成，可以实现关系数据库、其它流程、其它企业级应用以及Web Service之间的整合。此外，BPMN和流程执行语言BPEL4WS、BPML能直接映射，易于被程序实现。与UML一样，BPMN是业务流程的可视化标准，容易被各种商业用户掌握，规范地描述业务流程。诚然，UML也常用来描述业务流程或者工作流，但是BPMN至少在如下3个核心问题上更胜一筹：BPMN提供更完整、更适合于描述业务流程的基本元素；BPMN具有更严密完整的数学基础；BPMN更直接地受各种流程执行语言的直接支持。因此 BPMN是业务流程设计、整合和实现之间的桥梁。
2 Web Service整合的目标和要求
限于篇幅 ，这里仅介绍实现Web Service整合的最低要求。首先，整合后的Web Service必须能够支持Web Service界公认的5个基本控制流模型：顺序模型、并发模型、同步模型、独占模型和归并模型。其中顺序模型保证对象实体能够按照一定的顺序依次执行；并发模型则能够同时在多个进程上处理对象；同步模型可以通过等待锁在流程执行之前将并发的几个进程同步；独占模型确保流程执行时的进程独占性；归并模型则是在流程开始执行前等待前序流程执行完毕。其次，鉴别模型和选择模型，鉴别模型用来在多个功能相似的Web Service中找出第一个响应它所发出请求的Web Service，从而保证整合后Web Service的可用性；选择模型可以根据一定的选择标准在众多候选Web Service中做出优化选择。当我们开始调用一个Web Service时，其输入输出参数是固定的，为了确保各个服务间消息的流畅传输，参数转化规则的制定是必不可少的。
3 Web Service整合的方法
本文所述的整合方法可简述为首先用BPMN构造Web Service整合模型，然后由BPMN模型自动地产生BPEL4WS描述的可执行代码和WSDL规范。鉴于Web Service整合的需求，我们首先要把现有Web Service重新用BPMN进行建模，才能在整合的过程中使多个Web Service达到统一，在这个过程中BPMN就扮演了一个整合平台的角色。
一个Web Service是由多个操作组合而成的，按照BPMN的定义，一个Web Service可以用一个Pool模型表示，各个Pool模型间通过Message Flow相关联，而每个操作都可以用一个Process模型表示，其BPNIN的Pool模型如图1左图所示，如图1右图所示的Process模型表明一个操作可以由一系列的Activity和Sequence Flow来表述，每个Activity模型又描述了操作的执行方式，下面对Web Service整合模型采用BNF范式描述：
<Web Composition>：：＝<Pool>[Message Flow]}�<pool>{<Message Flow><Pool>}
<pool>：：＝<Process>�<Process>{Process}
<Process>：：＝<Activity>[Sequence Flow]�<Activity>{<Sequence Flow><Activity>}
图1 Pool模型和Process模型
本文以化工厂发生毒气泄漏时制定人员紧急撤退预案为例，详细介绍BPMN建模工具实现Web Service整合的方法。
步骤1 定义Web Service原模型的接口模型及其操作属性。实现Web Service的整合，首先要构造一个Web Service的原模型和加入整合Web Service的候选模型，而原模型由接口模型和各个Web Service操作的合成模型两个子模型组成，合成模型将在步骤2中介绍。本案例中鉴子需求，接口模型只涉及到一个操作 CreatGasDispersionMap（），如图2所示，该操作的目标是根据输入参数plantID和emissionRate通过调用该整合模型，最终生成化工厂毒气扩散地图。
图2 Web Service接口模型及操作属性
步骤2 定义Web Service操作的合成模型。合成模型是要对任务进行功能性分解，并将其尽量细化，从而简易、高效的发现和利用现有Web Service。按照BPMN的建模思路，合成模型中的每一个子模型都要符合Pool模型的要求，且各子模型之间的交互可以通过Pool模型中 Process模型的交互实现。针对本文所述案例将其按照如下思路进行分解：
要想获得毒气扩散路径，首先要清楚该造纸厂所在的地理位置，即根据接口模型操作中的输入参数plantID通过寻找获取地理信息的Web Service实现，这里我们假设该Pool模型的名称为Get Plant Location，同理获取该处天气情况的Web Service为Get Weather。然而直接由地址获得当地天气情况的Web Service事实上并不存在，故将其分解为两个可用的Web Service：Get Nearest Airport和Get Airport Weather。通过上述两个子模型的反饮信息以及接口模型的输入参数：emissionRate，可以继续在网络中寻找能够分析这些信息的Web Service；当然也可以将此功能并入原模型。最后分析得出毒气扩散情况，再结合化工厂道路布局绘出毒气扩散地图，从而制定人员撤退方案，其BPMN描述模型如图3所示。
图3 Web Service合成模型
步骤3 Web Service到BPMN描述模型的动态转换。每个Web Service都可以通过它在UDDI注册中心的名字和文本描述来表示，而它所具有的操作信息则可以通过WSDL描述。因WSDL可自动的实现其表示形式与UML的转换，鉴于UML与BPMN构造的相似性，以及BPMN可自动转换为WSDL描述形式，则WSDL必然也可实现与BPMN之间的相互转换。
就本例而言，原模型首先评估候选子模型，按照子模型的需求到Web Service的UDDI注册中心按照其文本描述寻找可以实现相应功能的Web Service，并给该服务命名、转换输入输出参数与该Web Service的输入格式一致之后该Web Service按照要求进行数据处理并产生相关的WSDL信息以及输出结果，如果有多个Web Service可以执行这一操作，则我们按照前面所述的方法，选取首先响应的Web Service作为整合后的一个pool模型。对于那些现有Web Service所不能实现的操作，可以新建一个Web Service或在整合模型中添加一些程序来实现整合后的BPMN模型包含了操作属性，输入输出数据等由于BPMN具有多操作互动的特点和优势，BPMN 模型之间可以通过Message Flow标识连接，实现Web Service的整合。由于WSDL要求每个操作只有一个输入和一个输出，所以每个操作又要包含输入和输出子操作。
针对Get Weather子模型，本文将可以提供天气情况的Web Service的WSDL描述转换成BPMN模型图，从而实现Get Weather模型的披合。通过步骤2的分析，我们知道Get Weather子模型要进一步细化为Get Nearest Airport和Get Airport Weather子模型。Get Airport Weather子模型显示了所有关于天气情况的操作，其转换后的BPMN模型如图4所示。
图4 Get Airport Weather子模型的BPMN表示
整合后的Web Service模型如图5所示，其中每个Pool的操作都包含输入、输出和WSDL描述。最终的模型比预备模型增加了一些新的Pool模型。例如，整合模型的第一个Pool模型根据PlantID返回工厂的地理位置，但很难找到提供任意位置天气情况的Web Service，而提供飞机场所在地天气预报的Web Service却比较普遍，因此创建寻找离工厂最近的飞机场位置的Pool模型Get Airport Weather迂回实现整合需求。任何pool模型都可能存在多个Web Service复合要求，可以利用前文所提到的鉴别器在多个并行的Web Service中找到第一个响应的Web Service，当然也可以更改鉴别器的选择规则来选取最优Web Service。数据格式的统一始终是Web Service整合需要考虑的问题，同样，气象服务的Web Service返回的信息是语言描述形式，因此我们必须建立相关Process将此信息转换成符合规格的数据类型，作为下个Pool子模型的输入参数。
图5 Web Service的整合模型
步骤4 整合后Web Service执行引擎的配置。由于引擎是依据可执行规范来运行的，所以这些规范必须是步骤3中产生的实体模型的完整序列，这样原模型才能将实体模型转换成XML文本形式，从而作为可执行引擎的输入信息。当然这种格式的转换也可以通过转换工具自动实现，比如本文使用的BPEL4WS。
根据以上建模分析，BPEL4WS对该整合方案的程序实现如下：
<partnerWebLinks>
<partnerWebLink
Name＝"IONIC-calculateWeather"…/>
<partnerWebLink
Name＝"IONIC-createGasDispersionMap"…/>
</partnerWebLinks>
<variables>
<variable name＝"weatherLayer"…/>
<variable name＝"dispersionMap"…/>
<variable name＝"weatherInfo"…/>
messageType＝"calculateWeatherRequest"/>
<variable name＝"weather"…/>
</variables>
<sequence>
<invoke partner＝"IONIC-calculateWeather">
portType＝"calculateGasDispersionPlume"
operation＝"calculateWeather"
inputVariable＝"weatherInfo"
outputVariable＝"weatherLayer"
</invoke>
<assign>
<copy>
<form variable＝"weatherLayer">
part＝"calculateWeatherReturn"/>
<to variable＝"weather"
part＝"WeatherGML"/>
</copy>
</assign>
<invoke operation＝"createGasDispersionMap"…/>
<reply partner＝"IONIC-reply"
portType＝"CalculateGasDispersionPlume"
operation＝"calculateWeather"
variable＝"dispersionMap"/>
</sequence>
步骤5 整合服务的部署。首先要完善新的接口模型所具有的整合服务功能；其次，按服BPMN到WSDL的转换规则自动转换成相应的WSDL描述；最后，在UDDI注册中心发布该Web Service。
4 结束语
BPMN作为一个建模工具在整合各种信息系统和构建Web Service方面具有独到的优越性，同时它又与BPEL4WS之间具有紧密地联系，这都说明了BPMN是未来业务流程建模语言的基石。本文正是看到 BPMN的这一优势提出一种基于BPMN的Web Service整合方法，并将其应用于制定化工厂毒气扩散时的紧急预案中，通过实例我们可以更加真实的体会到Web Service整合的重要性及其未来的发展空间。
没有评论:
发表评论