BPEL流程范文
BPEL流程范文（精选7篇）
BPEL流程 第1篇
在中国电信重组的大背景下, 促进运营商重组后业务的融合有着非比寻常的意义。电信重组, 为移动运营商提供了提升企业管理效率的重要机遇, 而一个好的业务流程管理BPM (Business Process Management) 平台将能够为移动运营商带来管理效率的有力提升, 从而为移动运营商的用户带来更好的服务体验。移动运营商可利用BPM平台来协助其设计流程、实施流程, 使它为客户提供最优质的服务。同时, 在多元化竞争格局下, 移动企业面临国内外同行的激烈竞争, BPM的实施将会协助移动运营商提高企业的核心竞争力, 谁能加速进行市场信息的收集和整合, 快速进行市场响应, 谁就能占有先机, 在市场竞争中处于主动地位, 而BPM恰恰能够帮助移动运营商实现这一目标。
在信息领域, 随着Web服务技术的不断成熟, 相应的标准不断出现, 为整个网络环境提供了相对松散的计算平台。基于Web服务的软件开发模式也在不断完善, 其中, 面向服务架构 (SOA) 的方法在设计和组织业务功能方面体现了很大的优势。在业务与技术的共同驱动下, 业务流程管理技术应运而生, 成为连接技术与业务的纽带。
2 关键技术介绍
2.1 SOA与Web Services
Web服务 (Web Services) 是一个应用逻辑单元, 它通过标准的XML数据格式和通过的Web协议 (比如HTTP、SOAP、WSDL、UDDI等) 为其他应用程序提供信息【5】。Web Services的设计目标是在现有各种不同平台的基础上, 构建一个通用的、平台无关、语言无关的技术层。各种不同平台上的应用程序都可以通过这个技术层来实现彼此间的信息交换和集成。
Web Services采用面向服务的体系结构 (ServiceOriented Architecture, SOA, 也叫面向服务架构) 。SOA是指为了解决在Internet环境下业务集成的需要, 通过连接能完成特定任务的独立功能实体实现的一种软件系统架构。SOA是一个组件模型, 它将应用程序的不同功能单元 (称为服务) 通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的, 它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。
2.2 业务流程执行语言BPEL
业务流程管理 (Business Process Management, BPM) 是流程自动化和信息系统设计领域的最新发展方向。下一代的信息系统被普遍认为将是一个崭新的以BPM为中心、以企业的业务流程为基础的IT产品市场。业务流程管理就是为了实现企业特定的目标, 在一定的约束条件下, 利用资源和信息将输入转换为输出, 从而达到预定业务成果所执行的一系列具有一定逻辑关系的业务活动。
BPEL4WS (简称BPEL) 是IBM的WSFL和Microsoft的XLANG相结合的产物, WSFL和XLANG分别基于Petri网和Pi-calculus, 因此BPEL吸收和借鉴Petri网和Picalculus的优点, 是一种高级的、抽象的、可执行建模语言。它不仅实现Web服务间的交互和流程编排, 也将流程自身暴露为Web服务【3】。由于Web服务具有组件化、开放性、面向Internet和基于标准化的接口等特点, 可以很好的适应企业系统间的分布性和异构性。
因此在业务流程管理领域引入SOA和Web服务技术, 充分利用SOA的粗粒度松耦合特性【2】, 和Web服务的诸多特性与优点来加速业务流程建模的实现, 有效地将业务流程和信息平台更好的结合, 能够帮助企业更灵活有效地支撑企业用户的业务, 直接提升客户服务的响应速度和能力。
3 MiniOSS BPM系统分析与设计
3.1 系统分析
业务流程管理系统是业务流程管理的技术实现, 它使得企业能够对核心流程进行建模, 部署和管理。BPMS用流程演算数学体系表达流程间复杂的交互行为和状态变迁, 并对企业高层透明。BPMS支持高层流程设计与底层流程布置的直接并行工作, 通过提供高层试图对战略语义的转换, 实现流程表达对流程直接实时操作的动态管理。
MiniOSS业务流程管理系统可以电子化管理移动网络部的工作, 通过工作流机制标准化各项工作, 提供统一的业务流程管理平台, 方便部门内部的管理, 有效地避免了工作的无序化和负责人不明确等不利情况的发生。业务流程管理平台以解决投诉为中心, 将直接影响客户的规划、建设、维护、优化及路测项目统一纳入平台管理。系统底层应用架构采用SOA模型, 每个项目流程都由不同的环节构成, 将这些流程的基本环节封装成Web服务, BPEL通过编排这些Web服务操作的执行顺序来定义业务流程, Web服务基于标准化的接口, 符合SOA原则。SOA模型系统结构图如图1所示【6】。
3.2 系统设计
MiniOSS业务流程管理系统首先根据移动的小区、站点及其对象的特点和属性参数进行分析、统计和规划, 通过创建各种指定类型的项目和派发任务对其进行优化建设, 便于从宏观和微观两个角度对本地区的网络进行调整、优化。工作流技术是工作流管理系统中的核心技术, 它监督、控制和协调业务开通过程和计划, 并对工作和信息过程以及资源的利用和投入进行预先的跟踪。目前, 被看作是提高业务过程效率和生产率的关键技术。
MiniOSS业务流程管理系统功能模块分为:我的工作区, 项目管理, 专题管理和系统管理。项目包括建设项目、优化项目、扩容项目、投诉项目、路测项目、接入项目、报障项目和专题项目八大类。所有项目流程的流转过程都一致, 区别在于各种类型的项目对应的属性参数不一样, 这些类型的项目基本覆盖了移动公司网络部的规划、建设、维护、优化、处理投诉、测试等各类工作, 在表面独立的工作之间建立联系, 可以方便地对工作进度进行控制和调整。
图2给出了基于BPEL的业务流程管理框架图, 各部分功能描述, 执行步骤如下:
服务提供者将Web服务在UDDI中进行注册, 供服务请求者调用, 将WSDL文件存储到UDDI中, BPEL流程开发者可获得此Web服务的WSDL描述信息;
BPEL建模工具也就是可视化的流程设计器, 可以自动生成BPEL流程文档, 供BPEL执行引擎调用;
BPEL流程模板池可存储常用的流程模板, BPEL设计者把设计好的流程模板存储到该模板池中, 供以后调用;
BPEL执行引擎当收到请求时, 执行来自模板池或建模工具设计的流程文档, 按照流程描述过程调用相应的Web服务来完成具体服务。
4 MiniOSS BPM系统实现与应用
下面以基站建设流程为例, 描述流程的实现过程。从图3可以看出基站建设流程的过程由提交规划信息-基站规划-预勘察-基站发包-基站谈址-工程勘察一直到基站开通-新站优化等组成, 图3中各环节均由调用相应的Web服务完成。规划信息通过前台输入基站信息保存在数据库中相应表中, 然后查找相应流程模板服务接口调用相应Web服务, 构成整个基站建设业务流程, 然后根据具体业务数据完成GUI设计, 配置业务流程描述文件即完成整个应用的开发。
4.1 服务接口的实现
流程建模之前首先要确定Web服务清单, 创建Web服务描述, 定义流程可能用到的消息类型、服务链接类型及其它相关信息。在此基础上, 通过可视化流程建模工具创建流程模板。WSDL (Web Services Description Language) 是一种用XML语言来描述网络服务的语言。Web服务的一大特点就是自描述性, 因为它自身配有相关的WSDL文档, 该文档提供了Web服务的一些特性, 包括它的功能、接口、结构, 以及使用它的指令等。服务提供者在服务注册中心发布各种Web服务的WSDL文档, 服务请求者可以通过WSDL文档查询到所需的服务, 并获取其中的绑定信息, 进而与服务提供者进行通信。
WSDL首先对访问的操作和访问时使用的请求/响应消息进行抽象描述, 然后将其绑定 (Binding) 到具体的传输协议和消息格式上以最终定义具体部署的服务访问点 (Port) 。WSDL文档把服务访问点和消息的抽象定义与具体的服务部署和数据格式的绑定分离开来, 因此可以对抽象定义进行重用。
4.2 流程编排实现
BPEL流程指定参与的Web服务的确切调用顺序, 包括串行和并行。使用BPEL, 通过组合这些服务, 可以以算法的形式定义复杂业务流程。BPEL流程的本质就是通过BPEL的活动将BPEL的过程组件“串起来”, 所谓“串起来”就是通过BPEL的活动让BPEL的过程组件产生一种动态的交互。比如说讲一个变量赋值给另外一个变量, 就是一种变量之间的动态的交互。
一个业务流程是针对一类具体特定业务而定义的流程, 采用BPEL对业务流程进行描述, 主要就是业务流程包含节点和任务活动信息。实例流程编排采用Netbeans BPEL流程管理器, 它提供了一个图形化和用户友好的方式创建BPEL流程。利用其图形提示和检查器, 简化流程、合作伙伴链接;可以根据运行条件和变量, 快速的创建复杂的并行分支流逻辑, 有效降低了流程集成方案的成本和复杂性, 为创建、部署和管理BPEL流程提供了广泛而易用的基础架构。
一个BPEL流程由多个步骤组成, 每个步骤称为活动, BPEL支持基本活动和结构活动, 基本活动有:
本系统以BPEL服务引擎为底层支撑平台, BPEL服务引擎是一个兼容JSR 208的JBI运行时组件, 它为执行WS-BPEL 2.0兼容的业务流程提供了许多服务。BPEL服务引擎为部署BPEL流程提供运行时服务。要部署BPEL流程, 需要将它作为JBI模块添加到复合应用程序项目中。
4.3 系统应用
该系统已成功运行于南京移动公司中, 方便了南京移动网络部的内部管理。以基站建设流程为例, 移动网络部责任人首先进入流程第一个环节, 收集客户投诉、路测问题点、城建等信息, 对这个环节的信息录入到系统中, 由相应人员审核提交后, 移交给下一个环节, 在地图上综合分析是否需建站, 然后联系网络部、工程部通过现场勘查, 提交审批, 再进入下一环节, 每个环节都是基站建设的一个步骤, 基站建设流程就是按照一个个环节有序的进行下去的, 每个环节由不同的责任班组负责, 并设置时限, 明确了任务信息和分工, 提高了管理效率。通过工作流机制标准化各项工作, 协助其设计实施流程, 有效避免了工作的无序化和责任人不明确等不利情况, 可以方便的对工作进度进行控制和调整, 直接提升客户服务的质量。
5 结束语
本文提出了基于SOA和BPEL的移动运维业务流程管理系统架构和开发模式, 并对关键技术进行了探讨。在分布式的网络环境中, 尤其是移动企业环境下, 业务流程管理首先要解决的就是系统异构问题, 而Web服务与BPEL的结合很好地解决了这个问题。MiniOSS业务流程管理系统能够帮助重组后的中国移动企业更灵活有效地支撑企业用户的业务, 直接提升客户服务的响应速度和能力。
参考文献
[1]刘秦, 叶志辉, 许娇.工作流程管理系统的设计与应用.电信快报.2008.10
[2]胡睿达, 刘连浩.基于SOA和BPEL的电信业务流程管理系统的设计与实现.科学技术与工程.2007.5
[3]王莉, 刘厚泉, 吴雪峰.基于BPEL的业务流程管理系统架构的研究与应用.计算机工程与设计, 2006, 27 (18) :3507～3510
[4]OASIS.Web Sevices business process execution language version2.0.2007, 4
[5]顾宁等编著.Web Services原理与研发实践.机械工业出版社.2006.1
基于BPEL的电厂竞价系统设计 第2篇
为支持发电商预测电价、负荷曲线、市场风险、可用输电能力、竞争对手行为等, 合理报价, 保持信息通道畅通参与交易市场, 确保机组安全稳定运行, 实现经营收益, 相关竞价支持系统已建成并得到完善[1,2,3]。支撑信息来自厂级监控信息系统 (SIS) 、管理信息系统 (MIS) 、集散控制系统 (DCS) , 以及合同管理、电能计量、结算等多个系统。系统实现大多基于J2EE[4,5,6]。各组件通过消息中间件或访问通用数据层集成, 但前者不能管理业务流程执行, 后者资源重用率低、冗余大[7], 而且组件局限于特定应用平台, 不能跨防火墙, 造成竞价系统难以重用和扩展。这有悖于解耦的市场环境中竞价组件改动慢、数量多、组合逻辑复杂且变动频繁的现状。系统以重建应对市场每一次大的调整, 加之没有合适的工具建立业务模型并转化为IT系统, 重建复杂。
本文提出将竞价系统中稳定功能域的业务过程和数据封装为Web服务, 利用面向服务架构 (SOA) 思想, 基于Web服务的业务流程执行语言 (WS-BPEL, 下文简称业务流程执行语言 (BPEL) ) 可视化地组合多个功能模块, 将业务模型转化为可执行的竞价系统。
1 电厂竞价系统的功能模块
1) 经济分析模块:
分析固定成本, 采集运行数据, 基于反平衡法或曲线拟合[6], 在线计算边际成本, 核算企业的成本和利润。
2) 市场分析和预测模块:
采集市场公布的供求、网损、传输限制、备用要求等信息, 分析其他发电商生产运营状况, 通过相关分析和趋势分析等算法预测市场走势、市场出清价 (MCP) 、电网供需关系以及机组相对竞争能力。
3) 报价辅助决策模块:
基于成本、经验、市场预测和市场模拟, 采用神经网络、博弈等模型, 制定、审批报价方案, 提供经济性和风险评估, 最大化电厂利益, 采用评估指标激励电厂提高竞价和经营能力[8]。
4) 交易管理模块:
向交易中心申报上网电量、检修计划等数据, 接收和管理交易、调度、监管机构发送的中标结果等竞价数据;管理发电合同及其完成情况等交易信息。
5) 机组运行优化模块:
管理发电、启停、检修计划, 监控并用图形显示出力、频率等生产经营指标完成情况, 在线计算性能, 及时调整计划, 节能降耗, 最小化发电成本。
6) 市场结算模块:
与交易中心校核发电收入、辅助服务、出力偏差奖惩等费用, 支持电费结算方式的同步校核, 争议管理, 财务、账单及计量数据管理等功能[2]。
7) 系统管理模块:
管理用户角色和竞价流程, 设置系统控制信息, 提供机组参数、报价时段、成本项等基础数据以及经济、运行、市场、交易数据和竞价系统运行日志的管理和查询。
2 基于BPEL的电厂竞价系统设计
2.1 SOA, BPM和BPEL
SOA和基于SOA的业务流程管理最近几年才得到发展[9]。SOA实现既要基于特定规范编排现有服务并维护, 又要避免投资巨大, 或将SOA视为Web服务分支, 缺少充分架构, 造成冗余、不兼容, 难以管理及安全性差。作为SOA的核心, 业务流程管理 (BPM) 扩充了SOA的价值[10]。用于服务组合的流程建模语言有:业务流程建模符号 (BPMN) 、业务流程建模语言 (BPML) 、BPEL、基于可扩展置标语言 (XML) 的过程定义语言 (XPDL) 等。BPEL基于Web服务描述语言 (WSDL) 等XML规范描述Web服务行为和控制逻辑, 将孤立的服务基于流程逻辑整合起来, 已经成为一个事实上的标准。它使得流程的调整仅需要改变文档中的元素或元素属性, 不需要在代码级别重新编译、发布。
BPEL文件通常包括:partnerLink对业务伙伴和角色建模;variables声明变量;correlation sets, faulthandles定义事务和异常处理;含sequence等逻辑的流程主体。变量类型由WSDL消息和XML Schema类型定义。
基于BPEL的竞价系统业务流程管理框架如图1所示。参与者设计消息、事件、控制流, 定义工作流并予以优化, 如改变竞价规则、增删服务或修改活动从属关系、设计和测试BPEL文件。任务清单将人员引入业务流程。BPEL引擎解释、执行流程模型 (多个BPEL引擎可包含在一个BPEL服务器中) , 服务器负责运行中的消息交互和服务通信, 监测服务运行并显示流程状态, 设置性能警戒线。多个公司的应用服务器包含BPEL服务器, 但Microsoft的BizTalk方案不遵循BPEL规范, Weblogic的BPEL引擎和设计平台与应用服务器有关。ActiveVOS产品允许实时信息共享, 重用架构、服务、集成平台, 不需要牺牲安全性和集成性, 成本低、部署快、投资回报率高, 在美国联邦机构、军事部门、Synovus等得到应用[11], 还允许终端用户订制流程[12]。
2.2 基于SOA和BPM的竞价系统整体结构
综合上述分析, 本文选择结合了SOA和BPM能力的ActiveVOS Designer/Server解决电厂竞价问题。主要优点是:①SOA提供一种新的软件架构思想, 实现应用程序解耦以及MIS和SIS等系统功能重用, BPM和基于BPEL的产品则提供一个平台实现服务面向流程协同, 为SOA实施找到了一个可行的切入点, 两者结合, 确保从开始到最后, 应用程序都能与最上层的业务需求以及底层的Web服务功能一致, 并有效结合。②业务流程与Web服务分离, 系统获得最大可能的灵活性和扩展性。③基于BPEL工具, 电厂可以根据业务需求, 像搭积木一样构建新竞价流程, 快速响应市场需求, 并实时管理。
系统总体结构如图2所示。服务层封装可对外暴露地应用。流程层按顺序逻辑组织底层服务, 形成参与各类市场的多个竞价流程, 如集成4个系统的8个不同服务构建日前竞价流程。在用户和接口层, 管理员在控制台管理流程, 普通用户则通过基于JavaScript、异步JavaScript和XML (AJAX) 的Web页面可视化定制流程。
基于ActiveVOS Server的系统部署如图3所示, 能支持发电侧数据申报、竞价决策、交易管理等。ActiveVOS Server部署在J2EE平台中 (WebLogic Server, IBM WebSphere Application Server, Jboss Application Server, Tomcat等) 。若性能需要, 流程引擎还能够运行在集群应用服务器环境下。在大型发电集团, 由于公司主站需要与多个下属电厂交换格式互异的消息, 单纯依靠BPEL引擎不能高效处理大量异构数据。企业服务总线 (ESB) 支持最新的Web服务协议和遗留系统所使用的消息传送协议, 与平台无关[13], 能处理大量消息[14]。此时, 集团主站系统使用ESB和流程服务器分别处理消息和业务逻辑, 能兼顾性能和灵活度。
3 基于BPEL实现日前竞价流程
3.1 竞价系统用例模型
下面通过图4说明服务关联性及系统服务的对象。
仍以日前竞价流程为例, 它包括7个参与者 (参与者和职位不对应) 。系统管理员新建、持久化、发布、监测和优化竞价流程, 管理竞价员权限;其他业务参与者提出更改流程的请求, 评价、认可流程。每天06:0012:00, 电厂将第2天的发电计划报由交易中心批准。首先, 企业管理人员和生产控制人员基于MIS和SIS分析机组固定成本和可变成本。接着, 竞价员根据交易中心前1 d发布的价格预测等信息, 基于市场分析和报价决策模块制定多组建议报价曲线。随后, 审批员确认申报方案, 竞价员向交易中心按“一机一价”报出报价曲线, 并在截止时间之前人工或自动调整。交易中心确认符合要求的报价并反馈给电厂, 基于交易算法、安全校核和可发能力校核, 通知电厂中标电量。竞价员确认中标结果, 生产控制人员据此制定发电计划, 监测实时发电成本, 基于电能计量系统采集关口电量、现地表电量, 考核厂用电损耗等。最后, 交易中心支付发电企业应得的总上网电费, 电厂财务人员基于市场结算模块校核费用、管理结算, 竞价员评估竞价结果。该用例图可向下逐层细化。
3.2 服务构建和部署
服务构建是实现SOA的关键和首要阶段, 基于流程组装、部署服务则是第2个主要阶段[15]。应用已有资产分析、自顶向下业务分解以及业务目标对齐方法构建电厂服务库, 分析业务规则、标准语义和粒度。通过Java消息服务 (JMS) 、J2EE连接器架构 (JCA) 封装基于Java的系统, 使用公共对象模型 (COM) 接口、动态链接库 (DLL) 集成来自 .NET的应用, 基于Java和C语言等实现新Web服务。服务根据功能命名, 基于Eclipse3.2集成环境开发, 运行于Tomcat环境。Java类由Apache Axis即时自动发布或通过配置文件WSDL发布为Web Services。Axis是一个简单对象访问协议 (SOAP) 处理器, 它用SAX (simple API for XML) 方式处理XML文档。通过服务部署, 用户可从Web发布页面下载或从E-mail接收WSDL文件, 并通过http://localhost:8080/plantbid/services/ServiceName?WSDL地址查看。WSDL文件绑定到BPEL文件需要增加2个部分:Partner Link以及重要的消息和相关集属性定义。可扩展样式表转换语言 (XSLT) 等映射技术实现服务间的数据结构匹配。
3.3 竞价流程实现
本文使用ActiveBPEL Designer3.1将业务流程转化为BPEL代码。assign专用于外部消息 (与其他partner进行交互的消息) 和内部变量 (用于存储、处理外部消息) 交互, 设计完成的BPEL流程如图5所示。
BPEL流程与服务、服务之间以及流程本身都有输入输出消息, 定义了这些消息格式的WSDL文件也要导入到BPEL工程中。此外, BPEL可能在技术和业务2个方面出错, 开发者需要在设计阶段进行考虑, 并在流程内部抛出异常由FaultHandler处理。
3.4 竞价流程部署和测试
powerplantbidding.bpel设计好后, Designer提供向导生成流程部署描述 (pdd) 文件, 链接partnerLink元素和实际的Web服务终端, 使得BPEL中定义的调用行为可以与具体的Web服务进行消息通信。在为每一个partenerLink指定终端后, Designer会自动生成*.pdd文件。然后, 将整个程序打包, 生成业务流程存档 (bpr) 文件, 并在指定的tomcat目录下建立一个bpr子目录, 将bpel, WSDL, pdd文件拷贝过去。此时, 部署完成, BPEL流程能被BPEL引擎识别, 并可以在引擎管理界面的Deployed Processes内查看到。同时, 引擎自带的Axis会将此流程生成Web服务, 若流程partnerlink的name属性为powerplantbidding09, 那么服务在本机上执行时可以用http://localhost:8080/active-bpel/servcies/powerPlantBidding09来访问。
服务及其组合模块的测试采用客户端应用程序SOAPUI2.0.2进行, 通过SOAP消息调用流程或者Web服务。测试用例的流程输出文本框显示流程执行的返回信息, 表明报价请求被成功处理。附录A给出了BPEL引擎对测试用例流程运行的记录。
4 结语
基于服务编排的SOA模式, 通过ActiveVOS Designer设计和配置竞价流程, 并由BPEL Server转化为编码交付, 实现了电厂竞价系统。竞价流程可被监测和管理, 并支持服务与人的交互。该模式缩小了业务需求与IT实施之间的距离, 减少了大量手工操作, 基于柔性配置更新的方式, 能快速实现服务增值, 降低研发成本。相对基于ESB的SOA实现, 专注于业务的处理, 支持服务状态的处理。流程引擎嵌入到ESB产品中作为服务引擎, 还可利用ESB的协议转换和绑定等能力。其他的一些平台, 如市场竞价实验平台、发电集团配置的主站市场分析系统等, 只需要通过标准接口即可集成到竞价系统中, 与系统具体部署位置和数量无关, 这对于跨区交易的大型发电集团尤为方便。本文构建的BPEL+SOA环境, 可重用于电厂其他系统实施, 即使用户侧放开带来众多交易流程, 系统也能灵活扩展应对。
附录见本刊网络版 (http://www.aeps-info.com/aeps/ch/index.aspx) 。
摘要：由于电厂竞价系统需要基于重用来灵活地应对竞价规则的频繁变更, 提出采用基于Web服务的业务流程执行语言 (BPEL) 和面向服务架构 (SOA) , 建立电厂竞价系统。设计了系统的架构层次和部署结构, 描述了基于BPEL的系统流程管理框架。最后, 应用Active VOS Desinger对电厂参与日前市场竞价的流程建模, 部署到BPEL Server中, 快速实现了面向竞价流程的组合服务编制和发布。
BPEL流程 第3篇
随着分布式应用的不断发展,Web Services技术逐渐崭露头角,成为最有前途的下一代分布式技术。但是Web Services就像是互联网上孤立的逻辑程序单元,不能很好地融合起来。我们也需要一种把这些功能按正确的顺序组合起来的方法定义使用这些Web Services的业务过程。SOA是一种进行系统开发的新的体系架构,在基于SOA架构的系统中,具体应用程序的功能是由一些松耦合并且具有统一接口定义方式的组件(也就是Web Service)组合构建起来的。在SOA架构中,我们需要一个简单直接的方式来定义这些业务过程,由于业务过程通常易于变化,因此我们需要很容易地修改这些业务过程。这正是业务流程BPEL(Business Process Execution Language for Web Service,也称作WS-BPEL)如此重要的原因。BPEL用于组合这些Web Services,因此它是SOA的一种实现方式,能够很好地将SOA的优势发挥出来。
另一方面,个人数字助理PDA和袖珍PC等移动设备在商业交流和工业生产中的应用也不断扩大,在移动设备上部署Web Services客户端具有广泛的应用前景,这样人们将可以在任意时间、从任何位置方便地访问这些服务。而移动设备自身技术的发展也给部署Web Services客户端提供了可能性,特别是支持J2ME平台的移动设备,使用Java技术可以方便地部署为Web Services的客户端,由于移动设备具有便携性、即时性和信息可交互性,移动设备在SOA架构中发挥的作用是无可替代的。
1 商业流程执行语言BPEL
1.1 BPEL介绍
BPEL构建在XML和Web服务的基础上。它是一个以XML为基础的语言,支持Web服务技术的协议群,包括SOAP,WSDL,UDDI,WS-Reliable Message,WS-Addressing,WS-Coordination和WS-Transaction。BPEL流程定义了参与流程的Web服务执行的确切次序。它可以按顺序执行,也可以并行执行。
BPEL虽然定义为一门商业执行语言,但实际上它并不执行商业流程中的任何细节,也就是说它一点也不涉及到商业数据的存储和处理。BPEL语言从本质上来说应该是一门描述性语言,它只是描述了一系列的操作的调用时机、调用顺序、调用那些Web服位置以及Web Service之间的组织。因此,在 BPEL中并没有出现复杂的数据结构和数据类型,也没有关于数据存储和持久化的操作,唯一涉及显式数据操作的地方就是〈container〉的使用了,但容器中的数据只是一些临时数据,一旦商业处理的流程结束,这些数据也就消失了。说BPEL语言是商业流程执行语言是因为从宏观上看,所有的操作都由BPEL来完成,而其背后的操作是透明的。
在一个典型的BPEL流程中,首先,BPEL业务流程收到一个请求。为响应请求,BPEL执行相关的Web服务,最后响应请求者。因为BPEL流程需要和其他的Web服务协作,它依赖于被调用的Web服务的WSDL描述,基本的执行流程如图1所示。
1.2 BPEL的核心技术
BPEL支持的业务流程指定一组Web服务操作的可能执行顺序,这些Web服务间共享的数据、业务流程涉及哪些伙伴以及这些伙伴在业务流程中扮演什么角色,一组Web服务的共同异常处理以及关于多个服务和组织是怎样参与的其他问题。为了实现这些功能,BPEL引入了活动,服务链接,伙伴和服务引用,容器,相关性,错误处理,作用域和消息属性等关键元素。
(1) 活动
BPEL流程类似于用来表达算法的流程图。流程的每一步称为一个活动。活动包括基本活动和结构化活动。
(2) 服务链接、伙伴和服务引用
BPEL把与流程交互的其他服务称伙伴。每个伙伴由服务链接类型来描述。
(3) 容器
容器提供的方式可用于保存组成业务流程状态的消息,所保存的消息往往是已从伙伴那里接收到的消息或将被发送给伙伴的消息。
(4) 相关性
在业务流程中服务间的交互是有状态的交互,在松散耦合的Web服务的世界中,这种“引用”将造成与实现之间脆弱的依赖关系,当每个业务伙伴采取不同的实现细节的情况下是无法适应的。在松散耦合的情况下,解决的方法是依靠定义伙伴间线路层合同的业务数据和通信协议头,并尽可能地避免在实例路由中使用特定于实现的标记。
(5) 错误处理
类似其他编程语言,BPEL使用Catch元素来响应错误处理。每个定义的Catch活动能拦截某种指定的故障,由全局唯一的故障名和与该故障关联的数据的容器来定义。业务流程中的错误处理在很大程度上依赖于补偿的概念。
为了使BPEL所描述的商业流程能被其他系统或者客户端调用,还要以一定的形式将BPEL发布出去,最纯粹的方式是将其以一个完整的Web Service发布出去,这样,对于客户端来说,一个BPEL流程看起来就像其他的Web服务,可以独立地被调用。当定义一个BPEL流程时,我们实际上定义了一个组合现存Web服务的新Web服务。这个新的BPEL Web服务使用一系列portType,通过这些portType,它提供了类似于其他Web服务的操作。
2 移动设备客户端的BPEL应用模型的体系结构
2.1 J2ME的概念与技术
J2ME 是一种以广泛的消费性产品为目标的高度优化的Java 运行时环境,其提供了创建运行在小型计算设备上的企业级Java 应用程序的工具可移植性,具有如下优点:客户机应用程序能很容易地被移植到其他遵循J2ME 或MIDP 并且符合CLDC规范的设备上。更低的网络资源消耗与服务器负载。J2ME 客户机应用程序能在断开连接模式下工作并保持数据的同步。J2ME 使用配置和简表定制Java运行时环境(JRE) 。作为一个完整的JRE ,J2ME由配置和简表组成,配置决定了使用的JVM,而简表通过添加特定于域的类来定义应用程序。
J2ME 体系结构是基于设备的系列和类别的,一个类别定义了一个特定种类的设备。移动电话、寻呼机和电脑记事本都是单独的类别。对存储器和处理能力有相近需求的若干类别的设备构成设备的一个系列。为此,在J2ME 中引入配置的概念。配置是指为Java 虚拟机定义的最小库,使JVM足够小并且能够运行在相同级别的所有设备上。配置定义了这类设备的共同Java 平台,以及设备无关的Java 虚拟机和核心库,是平台相容性的基础。相同配置所需的内存以及提供的处理能力在同一级别的设备上具有很好的类似性,便于进行兼容性的测试。按照设备的处理能力、电力供应、内存和网络连接等特性将嵌入式设备分为两类:
CLDC(Connected ,Limited Device Configuration):有限连接设备配置,适用于手机,PDA 等运算能力有限、功耗受限、内存较小、网络连接不太稳定的嵌入式设备。
CDC(Connected Device Configu2ration):连接设备配置,适用于置顶盒,Web-TV ,支持Internet 的有屏幕电话,汽车娱乐及导航系统等运算能力相对较强、电力供应较充足、内存较大、网络连接相对稳定的设备。
在通信方面,目前,J2ME不仅支持HTTP,也增加了对HTTPS、报文、socket通信以及串口通信的支持。另外,MIDP2.0还支持服务器Push体系架构。J2ME也支持Over-the-air (OTA) Provisioning,它使得用户能够动态地部署和更新移动设备上的应用程序。在网络安全的问题上,J2ME提供了强大的“端到端”的安全模型。一方面,MIDP2.0支持HTTPS,可以对传输的数据进行加密;另一方面,J2ME采用了安全域来确保未经授权的MIDlet套件无法访问受权限控制的数据、应用程序以及其他网络和设备资源。所以,使用基于J2ME的移动设备作为企业级应用的Web Services的客户端是一种十分方便和安全的解决方案。
2.2 基于J2ME的移动设备作为Web Services客户端的应用模型
BPEL系统可以按照一个独立Web Service来发布和调用,一般的,以J2ME为客户端的移动设备访问远程Web Services有三种方式:
(1) 直接用HttpConnection方式进行访问远程服务器端,然后接收返回的http响应,得到一个封装为XML文本的数据,在客户端,通过其他XML解析工具如KXML解析数据,然后进行处理显示;
(2) 通过JSR172(J2ME Web Services Specification),改标准由两种可选包组成:一个是JAX-RPC(Java API for XML-based RPC),允许从J2ME平台进行基于XML的远程调用;一个是JAXP(Java API for XML Processing),定义了对XML结构数据的基本操作。它们彼此独立,使基于J2ME的软件具有XML的处理能力,但是该标准只能在支持MIDP2.0的移动设备上使用,还有一定的局限性;
(3) 使用第三方API KSOAP,KSOAP 是基于KXML的应用于MIDlet的SOAP协议的轻型实现,它不支持WSDL,只需要SOAPObject 和 Http-Transport这两个必需的组件。该技术已经比较成熟。
无线移动Web Service的客户端堆栈如图2所示。
由于移动设备在处理能力和处理资源上以及网络连接的限制,我们不得不考虑如下一些问题:
(1) 有限的带宽:无线网络与有线网络相比,带宽和数据传输速率较小,因此在具体的应用中,不能一次性传输大数据量的处理结果,否则会导致网络拥塞;
(2) 有限的计算能力与内存资源:无线设备相对于PC来说,其计算能力相当小,内存资源也只有几十K,因此不能在以移动设备作为客户端上做复杂的数据处理。
基于移动设备以上的限制,使得它不能像其他设备如PC机一样可以自由地处理大量的数据信息,而一般对于BPEL系统来说都会有复杂而大量的信息处理,这就要求我们在设计BPEL的系统应用时提供相关的处理来尽可能地减少以J2ME为客户端的移动设备的处理负载。本文提出了如图3的体系模型。在一个大型的应用来说,应用服务器主要负责非流程相关的业务处理,而BPEL则通过SOAP服务器如Apache的Axis服务器来接收和响应流程相关业务处理,当然,在SOA的体系架构中,应用服务器不是必须的,而我们这里提出仍使用应用服务器主要是方便建立数据缓存,使大数据量的处理能够分批发送给客户端,保证移动客户端的正常处理。
在移动客户端,通过MIDlet套间分别向应用服务器或者SOAP服务器发送HTTP请求或者SOAP请求,服务器接到相应的请求后做出适当的分发处理,当需要调用BPEL流程处理时,通过SOAP服务器发送对应于该BPEL的WSDL文件的请求,流程服务器开始执行相应的BPEL流程,按照系统描述组织、调用和协调该流程中的各个Web Service的执行,并处理相应的返回结果,然后将处理结果返回给移动客户端。
通常在设计以移动设备为客户端的BPEL系统应用时,应该在服务器上建立一个数据缓冲区,一般可以在应用服务器上建立该缓冲区,在处理的数据量较大较多时,能够保证系统处理的数据暂时驻存服务器端,而不会因数据的大量传输致使客户端的接收与处理的阻塞,从而保证服务器与客户端的业务流的正确执行。
3 具体应用与系统实现
远程订票系统是一种以移动设备为客户端的BPEL系统,应用该系统,用户可以方便地使用手机、PDA等移动设备作为客户端即时地预定购买电影票。在客户端,要求能够提供安全的连接登录、电影场次查询、电影场次选择、座位选择和在线定购等操作界面,完成整个电影票的预定处理流程;而在服务器端,SOAP服务器接收移动客户端发来的SOAP请求,然后转发给BPEL服务器,调用流程服务,BPEL接收到用户的登录、电影票选择、座位选择和定购的操作请求后,按照流程的设计调用实现操作的具体的Web Service,对于较大数据的返回结果转发到应用服务器上,封装成较小的数据片断,使用XML的文档格式,可以很好地实现该功能,最后异步地将数据返回给移动客户端。
3.1 客户端的设计与实现
J2ME客户端主要由BookTicketsMIDlet套件组成, BookTicketsMIDlet套件实习了以下功能的操作界面:用户登录操作longin()、查询电影场次操作searchMovies()、选择电影场次操作selectMovies()、选择座位操作selectSeats() 和定购电影票操作purchaseTickets()。在BookTicketsMIDlet套件包括多个List,如Theaters List、Movies List等,一个显示座位排列的Canvas,多个Form,如LonginForm和AccountForm,还有多个Button组件等。而对于发送SOAP请求和接收响应,并解析和封装XML文档的功能单独成为一个模块;所以整个客户端由如下一些类组成:
需要注意的是,使用网络连接这种费时操作的时候,一定要单独开线程进行,不要直接写在CommandListener的commandAction()方法里,否则会出现画面被锁住的情况,所以调用时必须要重开线程。
3.2 服务器端的设计
当用户登录后,用户开始查询可选电影场次,服务器即开始执行BPEL的流程,首先执行查询服务,返回满足条件的电影场次,对于数据量较大的返回结果,可以封装为较小的数据文本分多次进行传送;用户选择好电影场次后,流程服务器即开始执行下一流程节点预定座位,调用座位选择服务,返回关于该场次电影座位的预定情况,在客户端解析XML后以图形界面显示出来;最后所有选择操作完成后,进行预订影票的交易,这里可以调用由银行提供的在线交易的Web Service,将它作为流程的一个节点,最终完成整个订票流程。
整个BPEL中需要调用3个Web服务:查询电影信息的服务MovieSearchService、选择座位的服务SeatSelectionService和交易付费服务MakeDealService,按照BPEL描述的流程,BPEL服务器依次调用各个服务。 BPEL的主要代码段如下:
对于在服务器端的缓冲区的设计,可以直接在应用服务器上开辟内存空间,将BPEL服务器上通过调用服务返回的大数据量的结果比如电影场次的查询结果进行封装,转变为数据量较小的XML文件再异步转发给客户端。在应用服务器上,此操作由dataCache()方法来完成。对于较大的系统来说,将缓冲区进行池化是提高系统资源使用率非常有效的方法。
4 结束语
本文对BPEL和J2ME技术进行了介绍和分析,对使用J2ME的移动设备为客户端访问BPEL系统的应用模型进行了研究,提出了一种实际应用的参考模型,并在此基础上进行了应用系统的实现。BPEL作为SOA体系结构的一种实现方式正在迅速的发展和完善,无线设备也必然在互连网络中发挥不可替代的作用。接下来我们需要对动态服务绑定以及如何设计服务器缓冲池的问题进行研究。
参考文献
[1]Tony Andrews,Francisco Curbera,等.Business Process Execution Lan-guage for Web Services Version 1.1.
[2]J2EE平台Web Services Ray Lai.电子工业出版社,2005.
[3]刘涛,高珍,张志浩.基于BPEL4WS的分布式应用系统的研究与实现.计算机应用研究,2004,11.
[4]BPEL in a Service-Oriented Architecture http://www.itlove.net/Ar-ticle/203/207/464/2005/2005111898169.html.
[5]尹星,肖铁军.基于J2ME的Web服务客户端及其在移动设备中的实现.计算机辅助工程,2004,12.
BPEL流程 第4篇
现有的Web服务组合描述语言大部分是半形式化的,容易出错且不容易检测,正确性难以保证,因此Web服务组合的形式化描述与验证是Web服务重要研究方向之一,需要借助某种形式化的方法对Web服务组合建模。随着Web服务组合研究的开展,出现了多种组合服务描述语言,其中BPEL4WS (Business Process Execute on Language for Web Services)语言是影响较大的一种组合服务描述的规范语言,得到了诸多企业、研究团体的支持。PNML(Petri网标记语言)是一种基于XML语言的Petri网文件交换标准。
目前使用BPEL4WS语言进行Web服务组合流程的Petri网建模研究较多,但通过BPEL文件与PNML文件格式转换实现Petri网自动建模的方法还不多见。文献[1]借助PNML,提出BPEL文件与PNML文件转换的思想,以实现Web服务组合的Petri网建模,但未结合建模工具给出转换结果。文献[2]从理论上给出BPEL4WS语言描述的Web服务组合的Petri网模型,但未基于PNML给出BPEL文件如何转换为Petri网模型的实现过程。王艳春等提出使用BPEL4WS 定义业务过程,将其转化基于PNML语言描述的Petri 网模型,但并未给出实现一个BPEL4WS到Petri 网模型的自动转化工具及实现流程[3]。文献[4]给出基于BPEL语言描述的Web服务基础活动与结构化活动的颜色Petri网(CP-nets)模型。
针对当前BPEL文件转换为PNML文件后,无法将PNML文件导入Petri网工具中实现自动建模,本文以Web服务组合流程为研究对象,采用BPEL4WS作为Web服务组合流程建模语言,构建一个BPEL到PNML文件转换框架,通过转换框架将BPEL文件转换为PNML文件,结果导入Petri网工具后,自动实现Web服务组合流程的Petri网建模。
1 Petri网与PNML介绍
1.1 Petri网
Petri网作为一种系统模拟工具具有对较强的系统模拟能力,能以直观的方式表达系统中的并发、顺序、冲突、同步等关系。使用Petri网对系统进行系统建模,可以较好地分析系统的有界性、安全性、活性、可达性等动态性质。
定义 1[5] 满足下列条件的三元组N=(P,T;F)称为一个网:
(1) P∪T≠ϕ
(2) P∩T=ϕ
(3) F⊆((PT)∪(TP))
(4) dom(F)∪cod(F)=P∪T
其中:dom(F)={x∈P∪T|∃y∈P∪T:(x,y)∈F}
cod(F)={x∈P∪T|∃y∈P∪T:(y,x)∈F}
P和T是两个不相交的集合(一般情况下可假定它们为有限集),分别称为网N的库所集和变迁集,P的元素称为库所,T的元素称为变迁。F是网N的流关系。 Petri图形中,库所用小圆圈来表示,变迁画成小矩形,对x,y∈P∪T,若(x,y)∈F,则从x到y画一条有向弧。有向弧存在于库所与变迁之间,任意两个库所之间或任意两个变迁之间都无有向弧连接。
1.2 PNML
PNML独立于任何工具和平台,支持多种Petri网类型,可以用PNTD(Petri Net Type Definition)定义某种具体Petri网类型的合法标签。
图1给出了PNML文件各个组成部分及其相互关系[6]。PNML的体系结构包括元模型、类型与特征定义、协议文档和Petri网文件等部分。其中元模型定义了PNML文件的基本结构,类型定义接口允许定义符合元模型的各种Petri网类型,特征定义接口允许定义Petri网的新特征。协议文档定义所有符合XML语法的PNML标签,利用协议文档可以保证相同的标签在所有的PNML文件中有相同含义。Petri网类型定义PNTD是根据协议文档中的标签定义某种具体Petri网类型的合法标签,Petri网根据PNTD中定义的标签描述PNML文件。PNML把Petri 网看成一个贴了标签的有向图,所有的数据能被储存到网、网的节点和弧的标签中。
元模型定义了PNML文件的基本结构,图2是UML符号表示的元模型组成部分及关系[7]。
2 Web服务组合的BPEL4WS描述
BPEL4WS是描述Web服务组合流程的流程图,它并不执行业务流程中的任何细节,也不涉及业务数据的存储与处理,只是用来描述各服务的调用和流转[8]。流程的每一步称为一个活动,BPEL4WS提供了两种类型的活动:基本活动和结构化活动。基本活动执行简单的任务包括<receive>,<reply>,<invoke>,<assign>等。结构化活动规定了一组活动发生的顺序,包括<sequence>、<while>、<flow>、<switch>和<pick>等,分别表示活动间的顺序、循环、并发和选择。
表1-表4给出Web服务组合流程四种基础结构化活动的BPEL4WS语言描述。S1,S2,S3代表Web服务,C1,C2,C3代表服务执行的条件。
3 BPEL到PNML文件转换框架设计
3.1 总体设计
Web服务组合流程的BPEL4WS语言描述不直观且缺乏形式化方法进行分析验证,BPEL4WS与PNML都基于XML语言,XSLT是一种转换XML文档结构的语言,因此以BPEL4WS四个结构化活动为基础,构造BPEL到 PNML文件转换框架。以此实现Web服务组合流程的Petri网自动建模。
文件转换框架接收Web组合平台生成的BPEL文件,经过转换框架处理后生成完整的PNML文件,结果导入Petri网工具(如PNK[9]),自动完成Web服务组合的Petri网图形化建模。框架具体设计流程见图3所示。
3.2 BPEL到PNML文件转换框架
BPEL到PNML文件转换框架的具体设计思想及组成模块。该框架由BPEL解析器、XSLT转换程序与PNML组合器三个模块组成,如图4所示。
3.2.1 BPEL解析器
BPEL解析器接收Web服务组合平台产生的BPEL文件,将BPEL文件中描述Web服务组合流程的部分解析出来。解析器以BPEL4WS语言的各结构流程为基础,将BPEL文件拆分成各流程文件片段,如Sequence片段、Switch片段、While片段等。经过BPEL解析器处理后的各流程结构的BPEL文件, 交给BPEL到PNML转换程序处理。
3.2.2 BPEL到PNML转换程序
针对四种BPEL流程,编写基于XSLT语言的文件转换程序。
基于BPEL4WS语言的Web服务流程与Petri网模型的映射关系分别是:库所表示Web服务活动发生前条件与发生后条件,变迁表示Web服务的活动,标记(Toke)表示流程的状态,弧(Arc)表示流程活动的关系流。BPEL文件中的每个invoke代表一个Web服务,name是服务名称,operation 代表Web服务操作,input variable 代表服务输入,output variable 代表服务输出。每个Web服务转换后的Petri网模型,有一个输入、输出库所(place)、变迁(transition)及连接库所与变迁之间的弧(arc)。由于Petri网模型是图形化的,为了实现PNML文件导入Petri网工具后,自动完成图形化建模,需为每个元素构造图形信息。
以表1中sequence流程的BPEL文件为例,详细阐述如何转换为PNML文件,转换程序的算法如下。
⑴ 建立BPEL文件的根节点模板,匹配process/sequence元素。生成PNML文件的<pnml>与<net>元素。
⑵ 建立sequence元素模板,匹配invoke元素。生成顺序流程的连接变迁与连接弧。
⑶ 建立invoke元素模板,生成Petri网图形中的输入、输出库所元素(<place>),利用ponsition()函数生成库所ID,分别读取invoke元素的inputvariable与outputvariable属性值,作为输入、输出库所名称。
⑷ 生成变迁元素(transition),读取invoke元素的operation属性值,作为变迁的操作名称。
⑸ 分别生成库所到变迁的连接弧与变迁到库所的连接弧(arc),source、target的取值由position()函数生成,代表弧的起始对象与指向对象。
⑹ 利用position()函数为变迁、库所,弧构造图形信息<graphics>,以X,Y元素定位每个图形对象的位置。
3.2.3 PNML组合器
每个BPEL文件流程片段经过转换程序处理后,生成的PNML文件片段,交由PNML组合器处理。PNML组合器根据Web服务组合平台生成的BPEL文件的流程组合PNML文件片段,生成一个完整的PNML文件,交由Petri网建模工具读取并显示建模结果。
4 BPEL到PNML文件转换框架实现
4.1 实验方案
以PC机为硬件平台,在Oracle BPEL、JDK、Eclipse与PNK2.2等软件支持下,实现BPEL到PNML文件转换框架。利用JAXP规范和DOM接口技术,运行BPEL到PNML转换程序,实现BPEL文件到PNML文件的转换,PNML文件导入PNK软件后,自动完成Web服务组合的Petri网图形化建模。
4.2 BPEL到PNML转换程序的实现过程
BPEL解析器将Web服务组合流程解析为四种基础流程,分别生成sequence流程的BPEL文档、while流程的BPEL文档、flow流程的BPEL文档和switch流程的BPEL文档。分别编写四种流程的XSLT转换程序,生成四种流程的PNML文档。
以表1和图4中的sequence流程的BPEL文件为例,详细阐述其XSLT转换程序的实现过程。其他流程的转换程序类似,不再赘述。 sequence流程的XSLT转换程序的代码片段见表5所示。
创建了一个从根节点开始匹配的XSLT模板。使用xsl:element创建PNML文件中的<pnml>、<net>元素。xsl:apply-templates匹配sequence元素。
创建sequence元素的模板。每个invoke元素代表一个Web服务,读取invoke元素,使用xsl:element创建顺序结构中的两个Web服务之间的连接变迁(transition)及连接弧(arc)。xsl:attribute创建元素的属性,每个元素以id属性唯一标识。name 元素表示每个元素的名称,由value元素指定。arc在Petri网图形是一个有向线,通过source与target属性的赋值指明起始与指向对象,赋值由position()函数自动生成,position()代表上下文节点列表中的位置,文件中第一个节点的位置为1。创建两个顺序流程间的Web服务的连接变迁,用tlink表示。创建两条弧,第一条弧连接第一个Web服务的输出库所与tlink,第二条弧连接tlink与第二个Web服务的输入库所。为每个元素创建graphics存储图形信息,position表示元素的绝对位置,用创建X,Y属性存储具体的位置信息。
创建invoke元素的模板。BPEL文件中的invoke元素内容,最终被转换成输入、输出库所,变迁及连接库所与变迁的弧。operation的取值代表变迁的操作,如register;inputvariable代表输入库所名称,outputvariable代表输出库所名称。创建输入、输出库所(place),position()函数自动生成库所的序号。使用<xsl:apply-templates select="@inputvariable"/>读取BPEL文件中每个Web服务的输入变量(inputvariable)作为输入库所的名称,存储在<value>元素内。使用<xsl:apply-templates select="@outputvariable"/>读取BPEL文件中每个Web服务的输出变量(inputvariable)作为输出库所的名称。创建变迁(transition),position()函数自动生成变迁的序号。使用<xsl:apply-templates select="@operation"/>读取BPEL文件中每个Web服务的操作名称。
创建库所与变迁的连接弧。首先创建输入库所到变迁的弧。通过source代表起始库所,target指向目标变迁,position()函数自动生成source与target的值,指明弧的起始与指向。由于弧是一条很多点组成的线段,因此弧的图形信息以线段的中间点的坐标进行定位,arc中的X、Y的值代表弧线段中间点的坐标。
sequence的BPEL文件经过转换程序运行后,生成对应的PNML文件,如表6所示。
此文件导入至PNK后得到Petri网模型,如图5所示。
其他流程的BPEL文件经过其相应的XSLT转换程序运行后,生成相应的PNML文件。所有流程的PNML文件经PNML组合器组合后,生成完整的Web服务组合流程PNML文件,导入至PNK后,得到Web服务组合流程的Petri网模型。
4.3 实例验证
图6是一个Web服务组合的流程图,其对应的BPEL流程文件片段见表7所示。
首先BPEL解析器接受到BPEL文件后,分析其流程结构,根据BPEL4WS的结构化流程将此文件解析为四个BPEL文件片段。文件片段交由BPEL到PNML文件转换框架的顺序、选择、并发的XSLT转换程序处理,分别生成对应的PNML文件片段,PNML组合器组合PNML文件片段,生成完整的PNML文件。将此PNML文件导入到PNK软件,自动完成Web服务组合流程的Petri网建模,结果如图7所示。
由上述实例分析可知,通过BPEL4WS语言组合的Web服务,生成BPEL文件,交至BPEL到PNML文件转换框架进行处理,生成PNML文件,结果导入支持PNML文件格式的Petri网建模工具后,自动完成Web服务组合流程的Petri网建模。
5 结 语
本文以Web服务组合流程为研究对象,采用BPEL4WS语言组合Web服务,构建一个BPEL文件到PNML文件的转换框架,自动实现Web服务组合的Petri网建模,通过实例验证了该文件转换框架的有效性。下一步研究工作是借助Petri网的分析技术,对Web服务组合流程Petri网建模结果,进行可达性、有界性和活性等性质的分析与验证。
摘要：针对Web服务组合流程的Petri网自动建模问题,以Web服务组合流程为研究对象,采用BPEL4WS作为Web服务组合流程描述语言,设计并实现一个BPEL文件到PNML(Petri Net Markup Language)文件的转换框架,自动实现Web服务组合的Petri网建模。该框架利用XSLT实现基于XML的BPEL文件到PNML文件的转换,转换结果导入到支持PNML的Petri网工具,自动完成Petri网建模。结合一个Web服务组合实例,验证该框架的有效性。
关键词：Web服务组合,Petri网,BPEL4WS,PNML
参考文献
[1]李志伟.以Petri网为基础的网络服务组合前置验证及简化方法[D].台湾:中原大学,2004.
[2]Yang S J H,Hsieh J S F,Lin R T K,et al.Composite Web ServiceModeling and Verification with BPEL4WS and Petri nets[C]//TaiwanSoftware Engineering Conference(TSEC2005),2005.
[3]王艳春,林广艳.基于BPEL4WS和Petri网的服务建模与分析[J].系统仿真学报,2005,17:93-95.
[4]Yang Y P,Tan Q P,Xiao Y.Transformation BPEL to CP-Nets forVerifying Web Services Composition[C]//Proceedings of the Interna-tional Conference on Next Generation Web Services Practices.2005.
[5]吴哲辉.Petri网导论[M].北京:机械工业出版社,2006.
[6]Billington J,Christensen S,Hee K V.The Petri Net Markup Lan-guage:Concepts,technology,and tools[C]//Application and Theoryof Petri Nets 2003,24th International Conference,Berlin:Springer,2003:483-505.
[7]Ekkart Kindler.Concepts,Status,and Future Directions[R].En-twurf Komplexer Automatisierungssysteme,Germany,2006:35-55.
[8]Francisco Curbera,Yaron Goland,Johannes Klein.Web服务的业务流程执行语言[EB/OL].http://www.huihoo.org/openweb/bpel4ws1.0/index.shtml.htm.
BPEL流程 第5篇
为了使工作流程引擎能处理Web服务定制配置的要求, 使不同的租户对同一流程实现不同配置的流程实例 (Instance) , 提高流程的可重复性使用, 满足不同租户的业务要求, 该文提出了多租户感知 (Multi-Tenant Aware) 工作流程引擎的概念, 并基于Paa S模式下, 对开源Orchestra工作流程引擎进行扩展和延伸, 使Orchestra能够支持多租户感知的工作流程引擎, 并支持租户配置的Web服务 (Web Service) , 满足业务流程作为服务 (BPaa S, Business Process as a Service) 的要求, 实现工作流程引擎在云计算平台的可伸缩性 (Elastic) 的部署要求。
1 基本概念说明与描述
为了更好的理解本文, 将文中的一些专业术语进行解释说明:
1) 租户 (Tenants) :代表一个公司或部门, 其租用了云计算平台中的资源并服务自己的用户 (Users) 。
2) 用户 (Users) :租户 (Tenants) 所服务的对象。
3) 业务流程即服务 (Business Process as a Service) :简称BPaa S, 除Iaa S、Paas、Saa S模式外云计算研究领域的另一模式平台。
4) 单实例多租户模型 (Single Instance Muti-Tenancy) :指所有的租户分享一个应用实例, 但每个租户在系统中建立租户独立的环境资源及相关的配置。
5) 多实例多租户模型 (Multiple Instance Multi-Tenancy) :指所有的租户建立了自己独立的应用实例, 只有将硬件和操作系统环境作为共享资源。
2 BPaa S成熟度模型
BPaa S系统提供商为企业信息化流程提供所有网络基础设施及软件、硬件运作平台, 并负责所有前期的实施、后期的维护等一系列服务, 实现企业各个信息系统间或者企业间的信息系统协同工作[1], 同时BPaa S平台主要基于SOA技术为企业的各个信息系统间提供的数据交换的平台。
根据多租户对业务流程平台的可配置性、高性能、伸缩性的要求, 可以将多租户在业务流程平台的流程实例分为四个级别[5]:
级别1:定制开发的架构
每个租户的应用流程实例都有自己的代码, 不支持可配置, 不支持高性能, 不支持可伸缩。
级别2:可配置的架构
每个租户的应用流程实例可以通过租户对流程的不同配置实现满足个性化的需求。
级别3:多租户单实例的架构
通过对应用流程的个性化配置, 实现所有租户共用一个应用流程实例, 发挥软件的规模效应。
级别4:可伸缩的租户的架构
实现多租户多流程实例的架构, 并且在流程实例与用户之间, 通过中间件实现均衡负载, 满足云计算平台可伸缩性要求。
BPaa S软件的四级成熟度特性的比较如表1所示。
本项目研究的多租户感知流程引擎平台要达到级别4的要求, 即平台要求对流程实现可配置, 要求多租户支持多流程实例, 并对系统实现均衡负载的要求。
3 Orchestra工作流程引擎的介绍
Orchestra工作流程引擎是开源的BPEL工作流程引擎, 该引擎基于OASIS的WS-BPEL 2.0的标准, 同时支持BPMN2.0的用户可视化设计[3], 详细的系统架构如图1所示。
在本文中主要涉及修改扩展的组件为Invoker组件以及Web Service组件:Invoker组件主要解析租户的对Web服务的配置, 并根据对应的配置要求调用Web服务;Web Service组件主要解析Web服务中消息的内容, 该功能主要通过Apache CXF的解析器来实现[2]。
4 多感知流程引擎的模型
为了使多感知流程引擎能达到级别4的要求, 本章节将对Orchestra进行修改扩展, 多感知流程引擎的模型如图2所示。
多租户感知流程引擎模型主要由三部分组成:
1) 租户及用户
租户可以根据服务标准对用户分组, 为用户配置具体的工作流程, 以实现不同的计费标准。
2) 业务流程引擎
业务流程引擎要达到级别4的要求, 即流程引擎能实现对流程的可配置, 支持多租户多流程实例, 并对系统实现均衡负载的要求。
要实现以上目标要满足以下条件:
(1) 每个租户发起的流程实例是隔绝的。即除了操作系统及硬件可以共享外, 各流程实例及流程实例中的数据具有独立的数据存储空间。
(2) 每个流程实例可以被租户或者用户动态修改。即每个流程根据具体的业务要求, 可以动态修改与客户互动的内容, 比如发给客户的信息内容, 安全机制, 租用费用等[1]。
(3) 支持大量用户的并发。流程引擎需要能支持群组动态扩展, 单一台服务器超过负载时, 通过负载均衡机制启动一台新的服务器, 以实现云计算中的可伸缩性的特征。
3) 数据库。
数据库存放的内容有: (1) 供租户使用的由流程专家开发的业务流程。 (2) 各业务流程实例隔绝的独立数据。
5 多租户感知流程引擎实现的要求
本章节主要对多租户感知流程引擎的实现从总体要求, 功能要求及非功能要求三个方面进行说明:
5.1 总体要求
根据[6]对工作流程引擎的要求描述:
1) 验证租户行为:工作流程引擎要能检测, 当前工作流程的状态是否能满足租户的操作行为。
2) 验证租户权限:工作流程引擎要能检测, 当前的用户是否有权限支持执行该操作。
3) 满足以上两个条件后, 工作流程引擎将执行操作后的流程实例状态保存到数据库中, 并且将操作结果返回给工作流程引擎。
5.2 功能要求
从功能角度, 多租户感知流程引擎还需满足以下功能:
1) 工作流程引擎能从租户发来消息中提取租户上下文 (Tenant Context) 的内容, 并将上下文内容存储到系统变量中或者数据库中, 实现工作流程引擎对租户的感知。
2) 流程实例能理解并运用租户上下文实现业务流程的个性化配置。
3) SOAP消息的头文件能添加租户上下文中的参数变量, 以便工作流程引擎在调用服务时, 对服务实例进行个性化配置, 同时也能通过Tenant Context ID来确认服务实例所属的流程实例。
4) 工作流程引擎对流程实例、每个流程所所需的数据以及实例的运行进行独立的隔离。从用户的角度看, 各个流程好像单独运行在单用户的工作流程环境中[4]。
5.3 非功能性要求
从非功能的角度, 多租户感知流程引擎还需要满足以下要求:
1) 具有扩展性:多租户感知流程引擎的架构要求具有扩展性, 可以通过修改已有模块的代码或者添加新的模块功能。
2) 已有流程的可重复性使用:多租户感知流程引擎要支持已有的流程对不同租户的重复性使用, 以减少流程重新设计开发的时间。
3) 具有兼容性:多租户感知流程引擎既要支持多租户感知流程, 也要支持原来的非多租户流程。
6 多租户感知流程引擎的实现设计的描述
本节主要根据对多租户流程引擎的要求多租户流程引擎。其整体工作原理如图3所示。首先介绍一下租户上下文 (TenantContext) , Tenant Context是租户SOAP消息中的一个信息块, 主要描述租户及用户配置信息, 它的结构如图4所示。
每个租户都有自己唯一的Tenant Identifier (TID) , 租户通过SOAP消息将租户上下文发送给多租户感知流程引擎, 流程引擎将提取租户上下文的消息, 并存放在数据库中, 同时启动一个流程实例, 在流程执行过程中, 将租户上下文中的内容通过SOAP消息随着Orchestra中的Invoker调用Web服务时, 发送给Web服务, 被调用的Web服务将根据租户及用户的配置要求为客户提供定制化服务。
7 结论与展望
本文提出的多租户感知流程引擎模型主要为了实现云计算平台中流程引擎的部署, 使租户使用流程时按需配置, 按需付费, 减少企业为了搭建业务流程环境所需要的基础设施及专业人员费用的支出, 同时实现了各个租户流程实例的数据的独立隔绝, 提高了数据隐私保护, 在将来的工作中, 为了实现多租户感知系统平台, 还需要升级Orchestra中的ESB模块, 使ESB模块成为多租户感知企业业务总线 (Multi-Tenant Aware Enterpreise Service Bus) , 为企业内部及企业间提供统一企业服务总线, 来提升企业信息系统间的业务通信标准。
摘要：多租户感知工作流程引擎 (Multi-Tenant Aware Workflow Engine) 是针对目前工作流程引擎系统缺少租户对业务流程的灵活、动态的配置, 导致企业信息系统间业务流程的缺乏可重复性使用的现状, 提出了基于PaaS模式下多租户感知流程引擎的概念和模型, 同时对多租户感知流程引擎的实现提出了总体要求, 功能性要求以及非功能性要求, 并通过对Or chestra流程引擎的扩展和延伸实现了多租户感知流程引擎的原型。
关键词：云计算,多租户感知,工作流程引擎,PaaS,BPEL,Workflow Engine,BPaaS,Multiple Instance Multi-Tenancy
参考文献
[1]张坤.面向多租户应用的云数据隐私保护机制研究[D].济南:山东大学, 2012.
[2]Apache CFX Website.Available online at[DB/OL].http://cxf.apache.org.
[3]Orchestra Website.Availabel online at[DB/OL].http://orchestra.ow2.org
[4]Julia Schroeter, Peter Mucha, Marcel Muth Kay Jugel, et al.Dynamic Configuration Management of Cloud-based Application[Z].
BPEL流程 第6篇
由于Web服务具有跨平台、跨语言和低耦合等应用特性,使得Web服务技术已经成为解决企业集成、组件复用问题的一种重要方法[1]。实际业务环境中,单个Web服务的功能是特定的,为了满足快速发展的业务需求,需要对Web服务进行组合。2002年7月在BEA、IBM和微软的努力下,发布了业务流程执行语言(BPEL)来解决Web服务集成问题。在实践中一般使用BPEL设计器来编写BPEL文档。目前市场上有许多BPEL设计器,如Eclipse的BPEL插件、Oracle的BPEL Process Manager以及Active Endpoints的Active BPEL等[2]。这些设计器都是图形化操作,通过手工拖动组件设计业务流程,生成Web服务组合需要的文档。但是使用这些BPEL设计器需要相关的Web服务和BPEL知识,并且创建组合服务的过程非常繁琐。目前针对Web服务组合建模并自动生成BPEL的研究已有一定的成果,如文献[3,4]采用的是Petri网模型来对服务组合建模。文献[5]使用有限自动机来对服务组合建模。但是这两种建模方式可读性比较差。有向图模型的建模过程简单并且模型流程清楚。文献[2]给出了一种基于有向无环图的自动生成组合文档的原型框架,但是此原型框架没有控制流程且组合的活动不能并行执行。由于在BPEL2.0规范中有<If>和<Flow>标签支持流程控制和并行执行,本文在该原型框架的基础上,提出一种新的组合框架,并对生成算法加以改进,解决了原框架生成的组合文档没有控制流程和组合活动不能并行执行的问题。
1 BPEL元模型
BPEL是一种使用XML编写的业务流程执行语言,主要用来对Web服务进行编制,组合成大粒度的服务以满足复杂的业务需求[6]。BPEL定义了一些元素标签用来描述服务组合流程的消息流、控制流、数据流和伙伴会话的通道。消息流部分使用<Receive>、<Reply>和<Invoke>三个基本标签支持接收、响应和调用消息活动,以便与其他服务进行通信。控制流包括<Sequence>、<Flow>和<If>等结构化活动标签,能够用于控制流程的串行和并行执行,以及选择状态转移活动。<Variable>和<Assign>标签可以对流程中的数据进行拷贝和更新活动。<Partner Link>标签用于指定服务组合时角色和提供的接口活动,从而建立对等的会话信道[7]。BPEL还有异常和故障处理的标签元素等,限于篇幅不再赘述。图1是关于BPEL2.0元模型的UML视图[7]。
2 Web服务组合工作流建模
DAG模型的建模过程简单、描述内容丰富,广泛应用于描述业务流程,已成为流程工业系统建模的主要建模方法之一[8]。鉴于DAG建模的简单性,采用DAG对服务组合工作流进行建模,并称这种模型为服务组合DAG(SCDAG)。一个SCDAG主要由3部分组成:开始和结束节点、伙伴节点以及节点之间的连接。
2.1 开始节点和结束节点
开始节点是流程的开始,用来接收整个流程的输入参数,并说明开始调用流程,对应BPEL文档中的<receive>标签。结束节点一般接收整个流程的输出参数,并表明流程的结束,对应BPEL文档中的<reply>标签。在一个SCDAG中只有一个开始节点和结束节点,分别用带有字符S、E的方形表示,如图2所示。
2.2 伙伴节点
伙伴节点和BPEL文档中的<Invoke>标签对应的,用来调用伙伴服务,使用带圈内的小写字母表示,如图2所示。
2.3 连接
连接是用来连接节点之间的弧,并且弧是有方向的。弧的方向表示活动调用的顺序,并且也表示一种依赖关系,只有当该节点父节点全部执行完,该节点才能被调用。一般在连接中会传递一些服务调用的变量参数和一些条件选择信息。节点之间是通过连接串连一起的,节点间是选择执行还是并行执行都可以通过连接来传递。SCDAG中有3种类型的连接,分别是顺序连接、并行连接和带有条件选择的连接。顺序连接只是表明节点之间的依赖关系。并行连接和条件选择连接除了有依赖关系还有其他特性。并行连接表明有唯一相同父节点的节点可以并行执行,如图3所示的节点有两个并行执行节点和。条件选择连接和高级语言中的选择判断语句相似,只有条件满足时,被指向的分支才能够执行。其中顺序连接和并行连接使用实线有向弧表示,在代码生成时,通过模型上下文来区分是哪种连接。条件选择连接使用虚线有向弧表示,如图2所示。
3 Web服务组合文档的生成
Web服务组合时会涉及到3个文档,分别是Web服务描述语言WSDL(Web Services Description Language)文档、BPEL文档、Deploy发布文档。其中WSDL是Web服务的描述文档,为用户提供详细的接口说明书。BPEL文档是描述Web服务组合之间业务流程的文档。Deploy发布文档用来发布新集成的服务。由于这3个文档都使用XML语言描述,可以采用开源的XML解析框架DOM4J来生成和解析这些XML文档。其中WSDL文档和Deploy文档的结构比较固定且内容简单,容易生成,这里不再赘述。
3.1 生成BPEL文档算法选择
对于有向无环图的遍历方法,主要有广度优先遍历和深度优先遍历。但是在SCDAG模型中,节点之间是有依赖的。如图2所示,c节点指向e节点,那么e节点就依赖c节点。如果想要遍历e节点,必须当e的前驱节点c、d、b都被执行后才能遍历e节点。所以一般的广度和深度优先遍历不能满足对SCDGA模型的遍历。对于这种有依赖关系的遍历,可以采用基于一种依赖的遍历方法,具体在3.3节予以描述。
3.2 并行和条件选择设计
BPEL使用<Sequence>、<If>、<Flow>等结构化活动来控制管理整个流程并指定活动的执行顺序。在SCDGA中,有唯一相同父节点的节点可以并行执行。如图3所示,节点a和节点b是兄弟节点,并且节点a和节点b只依赖节点S,那么节点a、b可以并行运行。对于节点e,它依赖节点a和节点b,所以节点e不能和节点c、节点d并行运行。而节点c和节点d可以在节点a流程下嵌套<flow>进行并行执行。对于节点e,则会跳出<flow>标签,在<flow>标签之后生成对节点e的调用。
在SCDGA中,使用条件选择连接控制活动分支的选择。每一个条件选择连接都有一个判断条件,当条件为真时,则会执行该分支。<if>标签里有多个分支,当分支的输出参数作为另一个伙伴节点的输入参数时,会使得伙伴节点的输入参数不知来自哪一分支。如图2所示,伙伴节点f的中的一个输入参数可能来自节点c或节点d。这里采用一个节点执行完后立即对它出度节点赋值。
3.3 整体设计和算法实现
如果把BPEL文档中的服务之间调用看成一个整体,那么BPEL文档结构是比较固定的,可以采用生成器模式来设计。图4是框架的整体实现,Bpel Bulider定义了BPEL文档主要结构的接口,Bpel Bulider Impl是接口实现。Edge表示连接,Vertex表示伙伴节点,Graph表示SCDAG模型。
在对SCDAG模型进行遍历生成BPEL文档前,应该保证SCDAG是一个无环的并且没有孤立节点的有向图,这两点也比较容易实现。在DAG中,若从节点i到节点j有一条有向路径,那么就说节点j依赖节点i,i是j的入度节点,j是i的出度节点。在对DAG进行依赖遍历时,如果遍历i节点,必须把i的依赖节点全部遍历后才能遍历i节点。由于BPEL标签可以嵌套,是有层次结构的,那么在生成BPEL标签时也是分层次。如果节点i有一个出度节点j,那么节点i和节点j生成的BPEL标签是同一层次;如果节点i有多个出度,那么出度节点的生成标签在i后面的<flow>或<if>标签内部;如果i节点有多个依赖节点,那么节点i生成的标签和依赖节点的最近公共父节点在同一个层次,这种情况下要先找到依赖节点最近父节点。下面是依赖遍历算法和依赖算法中会使用的最近公共父节点算法的伪代码。
算法1依赖遍历算法
输入参数v表示当前要遍历的节点,f是节点v的一个入度节点,e当前XML标签。
算法2最近公共父节点算法
在调用算法前,先把v的入度节点放入集合set中。对DAG进行深度优先遍历,如果节点在set集合中则返回,当递归节点w的出度节点有返回多个不同的值时,则说明要找的节点分布在以w出度节点为根子图中,这时递归函数返回w。输入参数root为DAG根节点S。
4 原型系统搭建及验证
用户通过使用UML建模工具Enterprise Architect建立服务组合流程,并生成相应的XML文档,系统对XML文档解析建立SCDAG模型。然后系统再读取伙伴服务的WSDL文档,提取相关信息生成组合服务的WSDL文档,结合SCDAG模型生成BPEL文档和服务发布文档。把生成的文档放入BPEL引擎中进行发布。系统使用的是Apache基金下的开源项目Apache ODE作为BPEL执行引擎。
由于系统主要目的是对服务组合的建模和实现,伙伴服务的构建这里不在赘述,并且伙伴服务功能的复杂性对服务组合并没有影响。现给出5个功能比较简单的服务,分别是加法、减法、乘法、开平方根和平方数学运算服务。分段函数
当把生成的文档在ODE引擎中发布后,可以调用新的组合服务。使用Soap UI对组合服务进行测试,图6是调用组合服务的往返soap消息,其中左边是发送的soap消息,右边是返回的soap消息。
5 结语
针对目前服务之间组合的复杂性,提出了一种基于DGA的BPEL文档生成框架。通过对框架模型的解析,能够自动生成服务组合时所需要的各种文档,有效地隐藏了专业的BPEL知识和繁琐的服务组合流程。实践表明,该框架简单易用,不仅能够清楚地反应服务组合之间的流程而且还不需要BPEL专业方面的知识,减少了服务组合的工作量。
实验验证表明该框架是可行的,但是该框架还不够完善。虽然框架解决了伙伴服务的并行调用,但是没有把<link>融入并行处理中。框架还应该增加对BPEL的故障异常处理的支持。
摘要：针对目前服务之间组合的复杂性,提出一种基于有向无环图的业务流程执行语言文档生成框架。通过对框架模型的解析,提出一种能够自动生成服务组合所需各种文档的改进框架及其算法,有效地隐藏了专业的业务流程执行语言知识和繁琐的服务组合流程。实践表明,该框架简单、易用,不仅能够清楚地反应服务组合之间的流程,而且还不需要BPEL专业方面的知识,减少了服务组合的工作量。
关键词：业务流程执行语言,Web服务,服务组合,有向非循环图
参考文献
[1]岳昆,王晓玲,周傲英.Web服务核心支撑技术:研究综述[J].软件学报,2004,15(3):428-442.
[2]崔福东,乔彦友,常原飞.基于BPEL的Web服务快速组合框架[J].计算机工程,2010,36(7):262-264.
[3]刘贤,李建华,李向,等.基于扩展同步Petri网的BPEL建模[J].计算机工程,2011,37(2):57-60.
[4]杜彦华,范玉顺,李喜彤.基于模块化可达图的服务组合验证及BPEL代码生成[J].软件学报,2010,21(8):1810-1819.
[5]于守健,李卫民,吴国文,等.BPEL中基于有限状态自动机的Web服务自动组合[J].小型微型计算机系统,2007,28(4):742-747.
[6]丁兆青,董传良.基于SOA的分布式应用集成研究[J].计算机工程,2007(10):246-248.
[7]铁威,黄志球,王进.基于BPEL的RESTful Web服务异步交互及组合研究[J].计算机工程与科学,2013,35(4):29-36.
BPEL流程 第7篇
Web 服务是一种网络应用, 它利用一种标准的功能描述语言来描述, 并利用标准的应用层Web协议和定义良好的接口进行交互[1]。Web服务一旦被部署到网上, 其他的应用和Web服务就可以发现和调用这个Web服务, 但是, 为了提高服务可重用性、分散和简化应用逻辑, 单个Web服务一般都不会做得太复杂[2], 要想完成复杂的需求功能, 就必须对Web服务进行组合, 近年来, 随着Web服务数量的不断增加, 可通过已有的Web服务构造Web服务工作流, 实现Web服务的组合, 来完成更大、更复杂的业务流程。
Web服务工作流是以结构化方式执行的一组Web服务[3]。目前, 已有很多研究力图将Web服务应用于工作流系统。其中一项技术是BPEL4WS, 它定义了一种语言用来以业务流程的形式建立Web服务组合[4]。此外, 为了能够从多视角对Web服务进行描述, 从而消除在服务发现和选择等过程中存在的二义性和模糊性, 为Web服务引入了语义, 形成语义Web服务。从而为服务自动发现、组合、执行等提供了良好的基础。目前主要的语义Web服务描述语言有OWL-S、WSMO (Web Service Modeling Ontology) 和SAWSDL (Semantic Annotations for WSDL and XML Schema) 等。
近年来, 针对基于工作流的Web服务组合的研究, 已经有很多, 在文献[5,6]中分别提到了一种利用BPEL实现Web服务组合的方法。文献[5]重点研究了如何通过Web服务的组合以满足用户的请求, 但并没有阐述Web服务自动集成和组合问题。文献[6]中虽然给出了一种语义Web服务动态工作流组合方法, 但他们并没有探讨怎样利用已有的Web服务构造一个新的Web服务工作流。
本文提出了一种基于BPEL4WS的语义Web服务组合框架, 旨在根据BPEL4WS过程模型, 动态地查找、绑定Web服务, 实现Web服务工作流的动态构造。通过对每一类需求功能的商业流程进行分析, 将每一类商业流程用BPEL4WS定义成抽象流程模板APT (Abstract Process Template) ;为了描述每个流程活动所需服务的相关语义信息, 我们为每个APT中参与流程活动的partner定义了一个流程伙伴契约PPC (Process Partner Contract) ;为了使Web服务具有语义信息, 用OWL-S本体语言对其进行语义描述, 通过 OWL-S/UDDI转换器, 使Web服务的语义信息转化为UDDI (Universal Description, Discovery, and Integration) 的注册记录信息并在UDDI注册中心进行注册。
1 BPEL4WS介绍
BPEL4WS是基于Web 服务的商业流程执行语言。它通过编排一组Web服务的执行顺序来定义业务流程, 主要包括两个部分:服务类型定义和业务流程定义。前者主要定义Web服务使用的一些类型定义, 如数据类型、消息类型、端口类型、伙伴链接类型等, 后者主要定义业务流程本身, 包括如下四种:
活动 BPEL4WS流程的每一步都称为一个活动。活动包括基本活动和结构化活动。基本活动负责实现一定的原子功能, 如接收外部请求、调用外部Web服务 (Invoke) ;结构化活动则利用循环、分支等元素对基本活动进行组装整合以实现系统所需的逻辑功能。
伙伴链接及端点引用 BPEL4WS把与流程交互的其他服务称为伙伴。每个伙伴由伙伴链接类型来描述。伙伴链接类型描述了两个服务间的关系, 定义了关系中每个服务所扮演的“角色”, 并指定每个角色所提供的服务接口。端点引用指定了服务的访问地址等相关信息。
变量 变量用于保存组成业务流程状态的消息, 所保存的消息往往是从伙伴那里接收到的消息或将被发送给伙伴的消息。变量可被指定为Invoke、Receive和Reply等活动的输入/输出变量, 保存在服务间流动的数据消息。
相关性 在业务流程中服务间的交互式有状态的交互, 但松散耦合的Web服务却是无状态的。由此, BPEL4WS提出了相关性概念, 通过使用发送和接收消息中特征属性集, 来解决Web服务与流程实例的关联问题。
2 框架概述
2.1 框架结构
本框架主要组件包括工作流引擎组件、可执行流程生成组件 (包括APT解析组件、APT绑定组件、PPC分析组件、语义匹配组件) 、服务语义信息库组件和服务注册组件 (包括Web服务、OWL/UDDI转换器和UDDI注册) , 结构如图1所示。
组合服务的过程首先应是商业流程的建立, 因此为每一类可能的商业流程定义一个抽象流程模板APT文档, 每个APT其实是用BPEL4WS定义的一个抽象商业流程, 使用XML来描述, 只是在APT中并没有明确指定具体参与流程的服务 (即Partner) 以及相关的服务操作, 所有与具体服务相关的技术信息, 在APT中都用一个占位符”?”表示, 故APT是不能直接用于工作流引擎去执行的。被省略去的信息称为未绑定信息, 每一个与服务交互的活动, 如果含有未绑定信息, 则称为绑定点, 绑定点处对应的具体服务通过APT绑定组件进行绑定。
PPC文档是用来描述在对应的APT中绑定点处所需Web服务的相关语义信息, 这些信息用于在运行时和已在UDDI上注册过的具体的Web服务的语义信息进行匹配, 每个PPC包含一个或者多个流程活动契约条目PPCI (Process Partner Contract Item) 。
在图1中, APT解析组件主要是对工作流引擎发送过来的APT文档中的每个绑定点进行编码, 为以后的服务绑定做准备;PPC分析组件主要作用是负责分析PPC文档并从文档中分析出PPCI, 然后将这些条目发送给语义匹配组件;OWL-S/UDDI转换器的功能是把用OWL-S本体语言描述过的Web服务对应的语义信息转换成UDDI记录信息, 并把Web服务在UDDI上进行注册, 注册时UDDI注册中心会为每一个Web服务产生一个全球唯一标识符UUID, OWL-S/UDDI转换器会将Web服务对应的语义信息和在UDDI上所对应的UUID存入到服务语义信息库中以便用于语义匹配;语义匹配组件主要是把PPC分析组件分析出的PPCI和服务语义信息库中所存的已经在UDDI上注册过的Web服务的语义信息进行匹配, 对于和PPCI相匹配的语义信息根据其所对应的UUID查找UDDI服务器, 得到Web服务相关的UDDI记录信息, 并把它填入到PPC对应的PPCI中并发送给APT绑定组件;APT绑定组件是把PPCI中的信息和APT中对应的绑定点进行绑定, 从而生成可执行流程。
2.2 框架运行流程
整个组合过程开始于工作流引擎根据客户端的需求发送相应的APT文档到APT解析组件, APT解析组件对APT文档进行编码并收集绑定点, 然后工作流引擎发送各个绑定点所对应的PPC文档给PPC分析组件, PPC分析组件对PPC文档进行分析并把分析出的PPCI发送给语义匹配器, 语义匹配器根据服务语义信息库中的Web服务语义信息对PPCI进行匹配, 如果找到匹配的Web服务, 把该Web服务对应的UDDI信息填入到PPC对应的PPCI中并发送给APT绑定组件进行绑定, 生成可执行流程并部署到工作流引擎上进行执行, 过程如图2所示。
3 关键问题
3.1 PPC 模型
PPC模型语法形式是通过一个的XML Schema文件来定义的。在XML Schema中包含的元素如图3所示, 即每个PPC包含一个或者多个流程活动契约条目PPCI, 每个PPCI用于描述对应APT绑定点处所需的Web服务功能、QOS、UDDI引用和全局编码等信息;其结构类似于文献[7]中所给出的PPC模型, 不同之处是我们在PPC模型中引入了相关的UDDI记录信息的引用。PPC模型在服务动态组合过程中扮演着两个重要的角色, 一个是对APT中绑定点处的partner的需求描述;另一个是为APT文档与匹配的partner服务之间的绑定起到一个桥梁的作用, 即对于匹配的partner服务来说需要先把自己对应的UDDI记录信息填入到对应的PPCI中, 才能绑定到APT的绑定点处。
通常来说, 一个Web服务可以看作一组操作的集合, 在部署Web服务时对于服务的描述往往可以包括一些关于服务的功能性和服务质量等方面的信息, 由于PPC是用来描述在APT绑定点处期望参与流程的partner的相关信息, 故也应包括这些相应的信息。在图3中可以看出, 服务的相关信息都是用对应的PPCI来描述的, 在PPCI中的功能性描述方面包括了服务的输入、输出、执行条件和执行效果方面的信息;在QoS方面主要包括七个方面的指标, 即可用性、可访问性、响应时间、可靠性、成本、安全性以及完整性, 这些QoS指标的给出有利于更好地选择较好的服务。UDDI引用项主要用于存放与期望参与流程的partner匹配的Web服务的相关UDDI记录信息, 用于APT绑定。全局编码项与APT中相应的绑定点处的编码相对应, 用来识别匹配的服务与那个绑定点进行绑定, APT中绑定点的编码在APT解析的过程中产生。
3.2 OWL-S/UDDI转换器
在OWL-S/UDDI转换器中, 一个主要的部分就是如何从OWL-S本体语言描述的Web服务的语义信息转换成用于在UDDI注册的UDDI记录信息。OWL-S本体语言一般从三个方面对服务进行描述, 即ServiceProfile 、ServiceModel和ServiceGrounding, 其中ServiceProfile用于描述服务的能力, 用Web服务的input, output, precondition, effects属性 (即IOPE指标) 来表示;ServiceModel用于描述服务如何实现, ServiceGrounding则用于描述如何访问服务;而UDDI注册中心的数据从概念上可以分为四类, 即商业实体信息、服务信息、绑定信息和技术规范信息 (tModel) 。针对OWL-S本体语言和UDDI记录信息的表述不同, 在文献[8]中给出了一种二者的对应映射关系, 根据这种关系OWL-S/UDDI转换器可以利用服务提供者、服务名称和服务功能描述等信息构造一条UDDI记录信息, 并将这条记录发送到UDDI注册中心进行注册。注册成功后会把UDDI为该Web服务产生的UUID和相应的语义信息存储到服务语义信息库, 以便用于匹配。
3.3 语义匹配
在文献[9,10]中分别给出了两种不同的语义匹配算法, 在文献[9]中给出的方法主要针对用本体语言DAML-S描述的Web服务之间的匹配, 该算法为Web服务的动态发现、选择和互操作提供了一个可行的途径。在文献[10]中给出了一种基于相似度的多本体匹配算法, 该算法支持两个待匹配的Web服务用不同的本体描述的情况, 算法分别对服务的输入、输出、操作以及用户自定义的规则进行匹配, 适用性比较强。在我们提出的这个框架中, Web服务的语义描述已经明确说明用OWL-S本体描述, 但是对APT中绑定点处所要参与流程的partner的描述并没有固定用那种特定的本体语言, 为了能使框架有更好的扩展性和较好的适用性, 我们在语义匹配算法设计上采用的是一种基于相似度的多本体匹配算法, 关于两个概念相似度的计算采用的是文献[10]给出的, 公式为:
其中synSim、proSim、conSim和neiSim分别表示两个概念之间语法 (名称和描述) 、属性、上下文和邻近点的相似度的值;WS、WP、WC、Wn则分别为这几项的权值。
在结合已有的匹配算法基础上, 下面给出一种适合本框架的匹配算法, 在整个匹配过程中, 主要涉及到的匹配方面有功能 (包括输入、输出、执行条件和执行效果) , 服务质量以及用户自定义的匹配。在Web服务匹配算法中关于输入匹配的算法如下所示, 其余方面匹配算法与此类似。
算法中参数InputA为发布的服务的输入集合, InputR为请求的服务的输入集合, thresHold为指定的InputA和InputR两个输入集合要匹配所需要达到的最低相似度。如果InputA并没有包含任何的输入, 我们认为他们为精确匹配 (exact) 。InputAElement和InputRelement分别表示InputA和InputR的元素, degreeMatch表示一个输入对 (一个是发布的服务的输入一个是请求的服务的输入) 的匹配度。degreeMax表示的是degreeMatch的最大值。CS ( ) 是在两个不同本体之间计算语义相似度的函数。
4 实例分析
本节用一个电子商务领域的一个例子来简单说明本模型是如何动态地产生可执行的BPEL4WS流程并完成语义Web服务动态组合的过程。
在本例中假设由用户提出购买某件衣服的请求, 服务器端接收到来自客户端的请求后, 完成购买过程, 同时选择第三方物流公司对货物进行配送, 其中该衣服的购买过程和选择第三方物流公司进行派送分别用对应的Web服务来完成。下面我们针对该衣服的购买过程来说明可执行流程动态生成的过程。
针对购买衣服这个绑定点处的PPC文档功能性描述信息如表1所示。
根据PPC文档的描述, 经过语义匹配后, 我们选择合适的Web服务进行操作, 得到该服务操作的具体细节如表2所示。
然后把具体的Web服务信息绑定到抽象流程模板APT中编码与PPC模型中的全局编码一致的绑定点处, 生成可执行的BPEL4WS流程, 完成Web服务的动态组合, 绑定前与绑定后的流程描述如表3所示。
通过以上过程可以看出, 本框架可以自动地完成Web服务工作流的动态构造, 从而实现Web服务的动态组合, 大大提高了服务组合的动态性与灵活性。
5 小 结
本文提出了一种基于BPEL4WS的语义Web服务组合框架, 并对框架中所存在的关键问题进行了详细的分析。在框架中用商业流程执行语言BPEL4WS对相似的商业流程定义一个模板, 即抽象流程模板 (APT) 。为了能反映APT中参与流程活动的partner的语义信息, 为每一个APT中绑定点处的partner定义了一个流程伙伴契约PPC;在服务注册阶段通过OWL-S/UDDI转换器把用OWL-S本体语言描述的Web服务语义信息转换成UDDI注册记录信息, 并完成UDDI的注册, 同时把对应的Web服务语义信息存放到语义服务信息库中用于语义匹配;在语义匹配阶段引入了一种基于相似度的多本体匹配算法, 使框架的适用性和扩展性得到增强。
未来的研究工作主要包括:对匹配算法进行优化, 降低其复杂度并提高算法效率;对PPC中关于QoS的描述进行扩展;以及研究Web服务绑定过程中更为复杂的问题, 比如抽象BPEL4WS和可执行BPEL4WS流程之间的语法差异等。
参考文献
[1]W3C:Web Services, http://www.w3.org/2002/ws/.
[2]Fan J, Kambhampati S.A snapshot of public Web services[C]//ACM SIGMOD Record, 2005.
[3]付燕宁, 刘磊, 张家晨.构造语义Web服务工作流的模型[J].吉林大学学报, 2007.
[4]Curbera F, Khalaf R, Mukhi N.The next step in Web Services[J].Communications of the ACM, 2003:35-40.
[5]Daniel J Mandell, Sheila AMcIlraith.Adapting bpel4ws for the seman-tic web the bottom-up approach to web service interoperation[C]//Proceedings of the2nd International Semantic Web Conference, 2003.
[6]Laukkane M, Helin H.Composing workflows of semantic Web service[C]//Proceedings of the Workshop on Web-Services and Agent-based Engineering.AAMAS Workshop on Web Services and Agent2Based Engineering, 2003.
[7]Zhile Zou, Zhenhua Duan, Jianli Wang.Acomprehensive framework for dynamic web services integration[C]//Proceedings of the European Conference on Web Services (ECOWS′06) , 2006.
[8]Paolucci M, Kawamura T, Payne Terry R, et al.Importing the semantic Web in UDDI[C]//Proceedings of Web Services, E-businessand Se-mantic Web Workshop (CAiSE Workshop) .Berlin Heidelberg:Springer Verlag, 2002, 225-236.
[9]Paolucci M, Kawamura K, Payne TR, et al.Semantic Matching of Web Services Capabilities[C]//Proceedings of the1st International Seman-tic Web Service.Las Vegas, Nevada, USA:[s.n.], 2003.
BPEL流程范文
声明：除非特别标注，否则均为本站原创文章，转载时请以链接形式注明文章出处。如若本站内容侵犯了原著者的合法权益，可联系本站删除。
