基于C的BPEL流程引擎原型的设计与实现.doc

本科毕业设计（论文）说明书 基于C+的BPEL流程引擎原型的设计与实现 学 院 软 件 学 院 专 业 软 件 工 程 学生姓名 指导教师 提交日期 2009 年 6 月 3 日 华 南 理 工 大 学毕 业 设 计 （论文） 任 务 书兹发给 班学生 毕业设计（论文）任务书，内容如下： 1.毕业设计（论文）题目：基于C+的BPEL流程引擎原型的设计与实现 2.应完成的项目： （1）2009年4月10日前拟定提纲并提交开题报告 （2）2009年5月25日前完成论文初稿 （3）进行基于C+的BPEL引擎原型的设计与开发 （4）参考外文文献资料并提交外文翻译译文 3.参考资料以及说明： （1）杨开诚. 数据结构M. 电子工业出版社. 2008(9). （2）James Gosling, Bill Joy, Guy Steele and Gilad Bracha, The Java language specification third editionM. Addison-Wesley, 2005. （3）Stanley B. Lippman, Jose Lajoie, C+ Primer, 清华大学出版社2003. （4）杨洪波. BPEL4People思想解读J. 软件世界. 2008(11). （5）万露. 基于SOA和BPEL的业务流程管理研究与应用J. 计算机与现代化. 2009(8). （6）APACHE ODE. / （7）Jacob . /jacob.html （8）Boost Serialize. / 4.本毕业设计（论文）任务书于 年 月 日发出，应于 年 月 日前完成，然后提交毕业考试委员会进行答辩。 专业教研组（系）、研究所负责人 审核 年 月 日 指导教师 签发 年 月 日毕业设计（论文）评语： 毕业设计（论文）总评成绩： 毕业设计（论文）答辩负责人签字： 年 月 日54 / 61摘 要本文详细介绍了BPEL流程引擎以及流程管理系统的理论知识与应用。由于目前几乎所有BPEL流程引擎核心都是基于JAVA语言编写的，与操作系统底层交互程度较低，运行效率相对地下，在大规模应用上存在一定的不足。而C+语言的主要特质之一就是高效，与操作系统底层交互良好。针对C+语言各自的特点，和目前计算机软件界使用C+开发的流程引擎的空白，进一步提升流程引擎效率，本文提出了基于C+语言的BPEL流程引擎原型设计方案，并对其进行了实现。流程引擎是运行经过编译的可执行的业务流程语言（通常是BPEL）定义文件的核心部分，其主要三大功能分别是解析业务流程语言定义的活动并运行、支持结构性活动、可以持久化地运行。而其中如何控制处理并发活动、如何持久化运行是流程引擎的设计难点。只有解决了上述两个问题，流程引擎才能真正意义上具备实用价值。本文先对APACHE ODE流程引擎核心（即JACOB）作了深入详尽的研究分析，对其处理并发活动所采用的通信渠道机制和如何处理调度控制的问题进行了详细说明；然后给出了JAVA语言与C+语言的异同，在此基础上指出使用C+语言开发流程引擎时需要注意的重点，并据此提出了基于C+的使用调用堆栈和BOOST序列化库来实现虚拟处理单元以及整个流程引擎的设计方案和实现。成品测试表明，使用C+开发BPEL流程引擎是完全可行的，整合了其余组件后能够实现完整的流程管理系统，其实际运行情况令人满意。C+在Web时代依然有着很强的生命力，使用C+开发的流程引擎应当有广阔的发展前景。关键词：业务流程执行语言，业务流程引擎，虚拟处理单元 AbstractThis paper briefly introduce the theories and applications about BPEL process engine and Business Process Management Systems. Since almost all BPEL engine is based on JAVA language, which do not have good performance with the underlying operating system and low efficiency. And they may cost a certain problem while running large-scale applications as a result. As long as we know, C + + is a language with the main characteristics of high efficiency, and it make good interaction with the underlying operating system. To further improve the efficiency of process engine using the characteristics of C+ language, we put forward a project of BPEL process engine using C+ language.Process engine is the core component that can execute compiled runnable BPEL files. Its three main functions are execute activities defined by BPEL, Persistence of execution state and Concurrency. There into, how to implement to persistence of execution state and how to control concurrency are two big problems while designing process engine. Only solve these two problems, can our engine be worthiness.This article first analyzes APACHE ODE engine core (that is, JACOB) in detail, interpret the channel communication mechanisms of JACOB which is using to solve concurrency problem. And then, shows the important points of designing C+ process engine and our solutions which use stack and Boost serialization to design VPU, by giving the similarities and difference between JAVA and C+ + language. Final test showed that the BPEL process engine developed by C+ is entirely feasible and can easily completely archive a management system after integrated the remaining components, which is satisfied. As far as we can concern, C+ still has a strong vitality in the Web area, and the process engine basis on it should have broad prospects in commerce. Keyword: BPEL, Process engine, VPU目录摘 要IAbstractII第一章绪论11.1研究背景和意义11.2国内外研究现状21.3应解决的主要问题及应达到的技术要求31.4本文组织结构4第二章 BPEL理论概述52.1 BPEL语言理论知识52.1.1 BPEL语言的作用域52.1.2 BPEL活动的标准属性和成员52.1.3 BPEL基础活动62.1.4 BPEL结构化活动72.1.5其他结构化活动72.2 本章小结8第三章 关于Apache ODE流程引擎的研究93.1 Apache ODE结构总览93.1.1 为什么选择参考Apache ODE流程引擎103.1.2 ODE BPEL编译器103.1.3 ODE BPEL引擎运行时103.1.4 ODE数据访问对象(DAOs)103.1.5 ODE 集成层113.2 APACHE ODE流程引擎的JACOB框架113.2.1什么是JACOB113.2.2通道Channels123.2.3 Jacob对象(JacobObject)与Jacob可运行的线程状态(JacobRunnable)123.2.4方法集Method Lists (MLs)133.2.5虚拟处理单元(Virtual Process Unit)和执行队列(ExecutionQueue)133.3 实例解析143.3 本章小结20第四章 提出基于C+特性的BPEL引擎方案214.1 JAVA和C+的异同214.2基于C+的BPEL流程引擎核心的设计方案224.2.1并发控制的设计方案224.2.2 C+的多态机制在BPEL引擎中的应用234.2.3基本活动的处理244.2.4结构性活动的处理254.3 本章小结25第五章 挂起与再启动265.1为什么需要挂机与再启动265.2序列化265.2.1 Boost Serialization265.2.2 Boost Serialization的特点265.2.3 Boost Serialization的使用275.3 本章小结28第六章 基于C+的BPEL引擎原型设计与实现296.1基于C+的BPEL引擎主要模块设计与实现296.1.1系统层次架构296.1.2引擎运行时的VPU模块实现306.1.3引擎运行时的执行队列模块实现306.1.4 BPEL引擎的动态行为描述316.1.5序列化的实现316.2 系统应用实例326.2.1Sequence实例326.2.2 Flow实例366.3 本章小结39第七章 结论407.1结论407.2存在的不足40参考文献41致谢42附录43绪论1.1研究背景和意义什么是业务流程？业务流程可以被定义为一个由各种不同功能的活动相连的一组有相互关系的任务，它们依照一定的业务逻辑和顺序依次执行。业务流程有起点和终点，而且它们都是可重复的。业务流程是企业实现商务目标的方法。对于企业而言，业务流程是企业重要的知识资产，是企业的核心竞争力的体现，一个精心设计和执行的业务流程能够为企业创造价值并节约成本。在著名作家佛里德曼对经济全球化有着精彩的论述，它描绘了一个由互联网、通信基础设施和新型软件搭建的全球舞台；在这个舞台上，人们能够以多种方式分享知识、劳动、娱乐和发现，并且创造新的商业机会。“如今沃尔马是美国最大的公司，然而它什么也不生产，只是建立了这个非凡的供应环节，从世界各地进口非常便宜的商品并把世界各地的产品送到消费者手里。它是一个全球组装线。”世界是平的：21世纪简史1。在经济全球化的过程中，企业的边界变得模糊，企业会将任务分解为一系列的子任务，企业只关注于自己的核心竞争力所在，并将其他工作分包给最合适的人来完成。企业需要通过业务流程将这些片断有机地组织在一起。在这里我们可以深刻地认识到业务流程对企业的重要性2。信息化产业中由此诞生了业务流程管理系统，其核心部分就是流程引擎。定义业务流程并对其做出文档所花费的时间和努力是完全值得的。在一个反映中国传统医学的电视剧中，当配置药剂的时候，掌柜把自己反锁在药房里，只有他会根据“秘方”将不同的药材调配成救死扶伤的灵药。然而只有他一人掌握这个过程是非常危险的。对于现代企业来说这更是不可能的，我们不可能只让配件制造主任了解企业的配件制造知识，然后让他每晚独自装配所有的零件。只要定义了配件制造业务流程，配件制造工人可以随时来去，而且任何配件制造工人都可以随时取代另一个人的工作，这是因为工厂里的所有配件制造工人都理解并遵循业务流程。我们可以学习、改变、评估，然后再次改变配件制造业务流程，因为该流程对于每个人都是可见的，而非局限于配件制造主任。现代业务流程管理系统的历史可以追溯到工作流系统2。业务流程管理系统是自本世纪初以来企业信息技术应用（信息化）背景上最重要和活跃的概念之一。它有两方面的基本含义或理解背景。一方面是企业管理，一方面是企业应用（软件、系统）。综合而言，它是典型的，在企业应用强力推动下产生的跨管理与信息技术领域的流行概念之一。从管理的角度，它可以看作是业务流程再造(BPR)所带来的以业务流程为中心的管理思想的延续与发展；从企业应用角度，它是在工作流(Workflow)等技术基础上发展起来的，基于业务流程建模，支持业务流程的分析、建模、模拟、优化、协同与监控等功能的新一代企业应用系统核心。简单地来讲，工作流定义了业务流程中的参与者(Who)、所执行的工作(What)及何时执行(When)。在企业IT环境中，工作流软件通常与企业应用集成(Enterprise Application Integration, EAI)系统结合在一起，成为企业应用的“黏合剂”，实现业务流程的自动化和流水线化2。传统工作流系统的最大缺陷就是：它们大多采用了专有技术。这使得业务流程与企业应用的结合变得非常复杂，通常需要很长时间进行部署和实施，而与企业外部系统进行集成则更加困难，无法适应全球化浪潮和互联网时代对企业灵活、无缝集成的需求。人们开始考虑利用Web服务的开放性和标准化，来解决业务流程与企业应用之间的互操作性问题。2002年7月，IBM、微软、BEA提交了Business Process Execution Language for Web Services(BPEL4WS)1.0的规范。业务流程执行语言基于XML和Web服务技术，它融合了早期的IBM的Web Services Flow Language(WSFL)及微软的XLANG规范的很多特点。随后许多主要供货商如SAP和Siebel(已被Oracle并购)等公司陆续加入规范的制定，并催生了多项修改和改进，并于2003年3月发布了1.1版。2003年4月，BPEL被提交结构化信息标准促进组织(OASIS)以实现标准化，并组建了Web服务业务流程执行语言技术委员会(WSBPEL TC)，该努力使BPEL在业界获得更为广泛的认可。目前该技术委员会正在致力于下一代规范的制定工作，并将该规范重命名为WS-BPEL 2.0。虽然除BPEL之外还有一些业务流程规范，但是到目前为止，BPEL是最为成熟和被广泛支持的技术6,13,14。“万维网其共通之标准让网络的应用软件沟通无碍1”随着全球经济一体化，社会分工更加的细致，业务流程管理系统的应用广度与深度将越来越大。通过研究、探索其核心部分，有助于提高笔者对新世纪计算机软件技术发展和现代企业软件的认识。1.2国内外研究现状目前国外流行的流程引擎主要有以下几种15：OSWworkFlow：是完全用java语言编写的开放源代码的工作流引擎，具有显著的灵活性及完全面向有技术背景的用户的特点。用户可以根据自身的需求利用这款开源软件设计简单或是复杂的工作流。JBPM：全称是Java Business Process Management（业务流程管理），它是覆盖了业务流程管理、工作流、服务协作等领域的一个开源的、灵活的、易扩展的可执行流程语言框架。JBPM是公开源代码项目，它使用要遵循 Apache License，其最大的特色就是它的商务逻辑定义没有采用目前的一些规范，如WMC、XPDL、BPML、ebXML、BPEL4WS等，而是采用了它自己定义的JBoss jBPM Process definition language (jPdl)。jPdl认为一个商务流程可以被看作是一个UML状态图。jPdl就是详细定义了这个状态图的每个部分，如起始、结束状态，状态之间的转换,过图型化的流程定义，直观地描述业务流程。APACHE ODE (Orchestration Director Engine）：是基于Java 的开源WS-BPEL（简称BPEL） 引擎， 它于2007 年7 月18 日从Apache 的孵化器中诞生成为一个顶级项目。它的主要功能就是执行使用BPEL 描述的业务流程，实现业务流程自动化，它支持长期运行和短期运行的过程。 WebSphere Process Server 基于 WebSphere Application Server 和 WebSphere Enterprise Service Bus，它为面向服务的体系结构 (SOA) 的模块化应用程序提供了基础，并支持应用业务规则，以驱动支持业务流程的应用程序。除此之外还有BEA AquaLogic、Oracle BPEL Process Manager、IONA Artix Orchestration、ActiveBPEL、Intalio BPMS、Microsoft BizTalk Server等等。在国内，主要是使用上述几个引擎做扩展、应用，研究流程引擎核心的团体、组织、个人非常少。同时，目前所有的商业流程引擎或开源流程引擎均使用Java或C#实现。之所以没有使用C+实现的BPEL引擎，主要有三个原因：第一，一般的电子商务应用，主要是在较底层的ESB上提高性能，而不是处于上层的BPM；第二，各大厂商为了使他们生产的产品系列配套，根据其原有产品基础来设计实现BPEL引擎；第三，开源项目实际上也是各大厂商主导推动，为其产品的改进提供活跃技术支持的，因此采用与其产品相关的结构。而C+语言相对其他语言具有性能上的优势，因此本设计将采用C+语言来实现BPEL引擎，进一步提高BPEL引擎的性能。1.3应解决的主要问题及应达到的技术要求BPEL引擎主要功能是执行业务流程，是BPM架构的核心，其设计好坏、效率高低直接影响到整个BPM的性能高低。2,16BPEL引擎的主要功能是提供BPEL流程的部署和运行环境。对于部署在BPEL引擎上的业务流程，首先解析流程文件生成数据对象结构，然后将数据对象结构序列化并保存。执行流程的时候，将已保存的数据对象结构反序列化，并根据流程中的结构和活动执行相应的操作，必要时将变量和流程执行状态持久化。执行流程时，BPEL引擎在与服务的交互过程中扮演了两种角色：服务消费者和服务提供者，区别在于BPEL引擎是作为交互消息的发起者或被发起者。交互的消息类型有In-Only和In-Out两种，区别在于是否需要返回结果。实现BPEL引擎时应该注意这些区别。BPEL引擎的核心BPEL运行时，在执行流程中需要解决两个主要的问题：第一，如何表达流程执行状态，方便需要的时候挂起当前状态，等待重新启动。特别是对于需要长期运行的流程，如果能够随时将流程当前执行状态通过数据持久化机制挂起保存，则可以避免进入长等待时由于出现系统故障而丢失流程执行状态，无法恢复。第二，如何解决流程执行并发性管理问题。一般来说，创建一个流程实例都应该新建一个线程来执行。流程本身也支持并发操作flow，常规做法是为流程内的并发操作新建线程执行。由于流程内并发操作数量不可知，有可能出现线程泛滥甚至系统崩溃12。好的做法应该是将并发性管理建立在每个流程实例占用单个线程的基础之上，避免创建过多的线程而带来的线程调度对系统性能的影响。1.4本文组织结构本文第一章介绍了选题的背景和意义。第二章将阐述与本课题相关的计算机软件知识，提出本课题需要解决的关键问题。第三章与第四章将说明设计原理并进行方案选择。其中第三章将详细分析讲解Apache ODE流程引擎的核心部分，第四章将通过对JAVA语言和C+语言的对比说明设计原理并提出方案，阐明选择这个设计方案的理由以及所采用方案的特点。第五章与第六章将分点详细论述设计，并进行结果分析。其中第五章将致力于解决如何表达流程执行状态的问题；第六章将结合第四章详细阐述基于C+的BPEL引擎的设计与实现，致力于解决如何流程执行并发性管理问题。第七章将对整个研究工作进行归纳和综合，阐述本课题研究中尚存在的问题及进一步开展研究的见解和建议。第二章 BPEL理论概述2.1 BPEL语言理论知识BPEL全称是业务流程可执行语言，用于描述业务流程。流程由一系列活动组成；通过作用域定义变量、合作伙伴链接、相关集和事件响应处理逻辑等；通过合作伙伴链接定义与流程交互的其他服务；流程可以是有状态的长时间运行过程，并且一个流程可以同时存在多个实例，流程引擎通过相关集将一条消息关联到特定的流程实例。以上是BPEL描述业务流程的基本情况，下面详细介绍OASIS制定的WS-BPEL2.0标准中定义的各个元素，以便加深大家对BPEL的理解。6,142.1.1 BPEL语言的作用域作用域Scope提供影响其内部活动执行结果的上下文环境，包括变量Variable，合作伙伴链接PartnerLink，消息交互MessageExchange，相关集CorrelationSet，事件处理EventHandler，异常处理FaultHandler，补偿处理CompensationHandler和终止处理TerminationHandler。作用域上下文环境可以多层次嵌套，父作用域中定义的环境在子作用域中可见。每个流程的根节点Process实际上就是一个顶层作用域。Process和Scope语法上是一致的，但是他们有以下三点区别：Scope是一个活动而Process不是，活动的标准属性和成员在Process中不适用；Scope中包含补偿处理和终止处理而Process中不允许包含；Scope中特有的isolated隔离属性在Process中不适用。尽管Process和Scope有所区别，但BPEL引擎中对他们的处理基本上是一致的，可以认为Process是一个特殊的Scope。每个Scope都包含一个主活动，定义该作用域的业务逻辑，这个活动可以是一个复杂的拥有任意层次嵌套的结构化活动。其他上下文环境相关成员是可选的。BPEL对Scope的处理效率由主活动的处理效率决定。2.1.2 BPEL活动的标准属性和成员在BPEL标准定义的各种元素中，BPEL活动用于表示流程的业务逻辑，可分为基础活动和结构化活动两种类型。基础活动描述流程业务的单个步骤实现，结构化活动则编码控制流逻辑，能递归的包含其他基础活动或者结构化活动。业务流程的执行实际上是BPEL活动的执行，其他元素只是提供辅助BPEL活动实际执行过程中所需的资源。根据BPEL标准提供的各种基础活动和结构化活动的多层次嵌套，可以定义任意复杂的业务逻辑，从而实现所需的业务功能。BPEL引擎对活动的解析和执行效率决定了BPEL引擎的效率。每个活动都包含两个标准的可选属性，name和suppressJoinF属性指定流程中各个活动的机器可读的命名，用于区分不同的活动。suppressJoinFailure是在并发处理的Flow活动执行中定义是否屏蔽接合活动异常，具体详见Flow活动。每个活动都包含两个可选容器，sources和targets，分别存储标准成员source和target。source和target用于通过Flow活动中的Link元素确定并发处理的活动的同步关系，每个Link对应一个source活动和一个target活动，规定了在source活动执行结束之后，才允许target活动开始执行，保证了并发执行的活动中部分活动的同步关系。具体详见Flow活动中的Link元素。2.1.3 BPEL基础活动(1) Invoke调用Web服务操作Invoke活动用于调用服务提供者提供的Web服务，典型的应用是调用Web服务上的一个操作。Invoke可以在其补偿处理和异常处理中内联其他的活动。根据WSDL文件的定义，操作可以是请求响应或者单向调用。BPEL标准对两种方式的调用使用相同的语法，单向调用方式只需提供输入变量或者输入输出变量都不提供，而请求响应方式需要同时提供输入变量和输出变量。(2) Receive和Reply提供Web服务操作Receive和Reply活动用于业务流程为其合作伙伴提供服务。Receive等待合作伙伴发送请求消息，并根据createInstance属性决定是否创建流程实例。流程启动活动包括Receive和Pick两种，流程必须以启动活动开始，其他活动控制依赖于启动活动，否则流程将无法执行。Receive是一个阻塞活动，只有流程实例接收到一个匹配的消息该活动才会结束。Reply用于发送响应消息给之前通过Receive活动等接收的请求。这种响应只对请求响应交互方式有意义。(3) Assign更新变量和合作伙伴链接Assign活动用于从一个变量到另一个变量复制数据，或者使用表达式操作变量、属性和常量来构造和插入新的数据，或者在合作伙伴链接之间复制端点引用。(4) Throw抛出内部异常Throw活动用于显式抛出内部异常。Throw必须提供异常的名称，可选的提供更多异常相关信息，对应的异常处理可以利用这些信息处理异常，并发布异常消息到需要的其他服务。(5) Wait延迟执行Wait活动用于指定一段特定时间的延迟或者直到某个期限到来，当指定时间已过或者某个期限到来时，Wait活动马上结束。(6) Empty什么事都不做Empty活动并不做任何事，但有些场合往往需要这样一个活动，比如一个异常需要被捕获或者禁止。Empty活动的另一个用途是在并发的Flow活动中提供一个同步点。(7) ExtensionActivity增加活动类型ExtensionActivity活动用于引入BPEL标准未定义的新的活动。(8) Exit立即终止流程执行Exit活动用于立即终止业务流程实例。除了终止处理、异常处理和补偿处理外，流程实例中所有当前正在运行的活动都必须立即终止。(9) Rethrow重新抛出已捕获的异常Rethrow活动用于异常处理中重新抛出已捕获的异常。Rethrow只能在异常处理Catch和CatchAll中使用。重新抛出的异常包含的信息是原始捕获到的异常信息，而不是经过异常处理修改过的信息。2.1.4 BPEL结构化活动结构化活动规定了一组活动集合的执行顺序。结构化活动以不同的结构组合基础活动，表示不同控制流模式、异常处理、外部事件以及业务协议中流程实例之间的消息交互协调。结构化活动可以以任意方式嵌套和组合。通过基础活动和结构化活动的多层次嵌套，可以创建出表达任意复杂业务逻辑的流程4。BPEL标准定义多种结构化活动，实现了不同的控制流模式。BPEL标准定义的结构化活动集合并不是最小集，有些情况下一个业务逻辑可以用不同的活动来实现。比如一个顺序业务逻辑可以使用Sequence活动实现，也可以使用定义合适Links的Flow实现。而Sequence和Flow是BPEL结构化活动中最重要的两个。（1）Sequence顺序执行Sequence活动包含一个或多个按照出现顺序先后执行的子活动，当最后一个子活动执行结束时Sequence活动结束。（2）Flow并行和控制依赖处理Flow活动提供并发和同步机制。Flow的子活动并发执行，当所有子活动都结束时Flow才结束。子活动使能判断为假而跳过执行也认为该子活动结束。Flow同时启动各个子活动执行，其子活动的各层次子活动之间可能存在同步依赖，因此Flow通过定义Link提供Flow内部各层次子活动之间的同步依赖。每个活动都有可选的sources和targets容器，分别包含一组source和target元素，这些元素通过Link确定活动之间的同步关系。一个Link分别对应一个source活动和target活动，规定在source活动执行结束之前target活动不允许开始执行。一个活动可以设置多个source，也可以设置多个target。targets容器中有个可选参数joinCondition定义多个target的布尔组合方式，默认是或，即该活动对应的多个source活动只要有一个完成即可开始执行该活动。Link定义的过程中不能形成控制环，即一个source活动对应的target活动是其逻辑在前的。2.1.5其他结构化活动除了Sequence和Flow，结构化活动还有Pick（事件触发选择处理）、ForEach（遍历执行）、While、RepeatUntil（循环执行）、If、Elseif（选择执行）等等。这类结构化活动的定义主要是为了能贴近人类语言，按照用户指定的表达式有选择地执行活动。他们的表达式的解析和条件的判定由该活动本身的执行方法处理，然后按照用户的定义，以串行或者并行的方式来调度他们。我们可以认为，在流程引擎内部，活动总是以串行或者并行的方式进行调度和执行，对其他的活动类型并不关心。Sequence和Flow结构化活动是流程引擎的主要工作模式和设计重点，实现了稳定可靠的串行与并行控制机制，就能在此基础上执行其他结构化活动。因此，我们把Sequence和Flow活动作为关键点进行研究。2.2本章小结本章主要介绍了BPEL语言的基础理论，描述了BPEL基本活动与结构化活动的标准属性和成员，并说明了为什么SEQUENCE和FLOW是流程引擎处理的关键活动类型。为下文铺开APACHE ODE流程引擎的设计，提出基于C+的BPEL流程引擎原型设计方案中如何解决处理并发控制部分作理论知识介绍。第三章 关于Apache ODE流程引擎的研究ODE的主要开发目标是开发可靠的，结构紧凑的，可嵌入的组件，能够管理使用BPEL流程描述语言的长时间运行的业务流程的执行。重点是开发具有最小依赖性的小模块，以便重新组装成一个功能齐全的业务流程管理系统。4,163.1 Apache ODE结构总览ODE架构中的关键组成部分包括BPEL编译器、ODE BPEL引擎运行时，ODE数据访问对象(DAOs），ODE集成层(ILs)，和用户工具16。编译器把BPEL文件转换成运行时可执行的格式，运行时以一种可靠方式执行他们，并通过DAO层把他们保存起来；运行时在集成层中运行，集成层将BPEL引擎连接到更为广阔的外部执行环境。图3.1 APACHE ODE流程引擎架构图3.1.1为什么选择参考Apache ODE流程引擎为了研究流程引擎的内部机制，必需研究学习其源代码，因为我们首先考虑开源项目。而在诸多开源项目中，Apache ODE流程引擎是严格按照BPEL标准制订，有详细规范文档可参阅的项目之一。其他流程引擎，如JBPM，扩展了BPEL，加入了其他繁杂的功能，增加了分析的难度。因此选择参考Apache ODE引擎能抛开其余干扰，在其严格的标准下研究流程引擎的内部机制。3.1.2 ODE BPEL编译器BPEL编译器负责把BPEL来源（即BPEL流程文件， WSDLs和schemas）编译成可执行的形式。编译器的输出结果不是一个“好的”编译表现结果，也不是这些源文件的错误信息列表。编译器生成的结果是一种对象模型，类似于基本BPEL流程文件的结构。但是，这种变异结果解决了BPEL中出现的各种名称引用（如变量名），内联了所需的WSDL和类型信息，并生成了各种结构（如默认的补偿处理）。这些编译结果（通常是一个扩展名为cbp的文件）是BPEL运行所需的唯一对象。3.1.3 ODE BPEL引擎运行时ODE BPEL引擎运行时在BPEL运行时模块中建立，提供给BPEL流程执行的。运行时提供了大量BPEL结构的实现，以处理流程执行中最复杂繁琐的工作。运行时同时也实现了何时应当创建新实例，和把刚收到的消息分发给哪个实例的逻辑。最后，运行时实现了流程管理的API以供用户工具使用。为了在不可靠的环境中实现可靠的执行过程，运行时依赖于数据访问对象(DAOs)提供的持续设施。这些DAOs的实现可自定义，但通常提供了与关系数据库的交互。BPEL结构的运行时在实例级上是通过ODE的Java并发对象(Jacob)框架实现的。Jacob提供了一个应用级的不依赖于线程的并发机制和一个提供执行中断与恢复的透明机制。Jacob是Java实现ACTORSAgha并发模型中非常大的一块，其流程代数有许多功能，如Pi calculus。本质上来说，Jacob为BPEL的执行提供了一个持久稳固的虚拟机。3.1.4 ODE数据访问对象(DAOs)ODE数据访问对象作为BPEL引擎运行时与底层数据存储间交互的媒介。通常，数据存储是一个JDBC关系数据库：既然如此，那么DAOs就是使用OpenJPA数据访问库来实现的。这样就能够创建自定义的DAO实现，即使JDBC没有提供相关实现，也能以某种机制达到持久化保存的目的。BPEL引擎运行时需要DAO对象来以处理以下持久化的问题：（1）积极的情况下知道哪一个实例被创建；（2）消息路由哪一个实例正在等待哪一条消息；（3）变量每一个实例的BPEL变量的值；（4）合作伙伴链接每一个实例的BPEL合作伙伴连接的值；（5）流程执行状态Jacob的持久稳固虚拟机的序列化状态。有关OpenJPA/JDBC DAO的实现，和相关组织信息通常在FIGREF中提供。3.1.5 ODE 集成层ODE BPEL引擎运行时不能在真空中存在：它自己本身是不能影响与外部世界交往的。为此它依赖于一个ODE集成层(ILs)。集成层将运行嵌入一个执行环境。例如，有一个集成层AXIS2和JBI。集成层的基本功能是为运行时提供通道间的通信。AXIS2集成层使用AXIS2库，让运行时以Web服务的方式与外加交互。JBL集成层则尝试把运行时加入JBI消息总线达到同样的目的。除了通讯以外，集成层还为运行时提供了线程管理机制，并管理运行时的整个生命周期，例如配置和启动运行时。3.2 APACHE ODE流程引擎的JACOB框架3.2.1什么是JACOBJACOB，即Java Concurrent Objects（Java并发对象），是APACHE ODE引擎的内核框架。ODE依赖于JACOB 框架去实现BPEL的构建。框架提供一些机制去解决两个构建BPEL的关键问题：执行状态的持久化，并发处理17。即使是用户只有一个线程，代码也能够拆解成并发处理的问题。通过把整个事务分解为一些较小的部分，我们就可以控制到那些真正被调用和执行的部分。比如说，我们有一个按照以下次序来执行一个过程：1. Invoke2. Receive3. Wait4. Invoke 如果有两个进程我们需要同时处理，简单的实现方法是这样：1. Invoke12. Receive13. Wait14. Invoke15. Invoke26. Receive27. Wait28. Invoke2但是如果我们把代码分解，引进一个所谓的“中间人”（或者称为栈），并且不允许活动直接地进行相互调用，我们就有了以下的调用次序：1. Invoke15. Invoke22. Receive13. Wait16. Receive27. Wait24. Invoke18. Invoke2从客户的角度来看，我们就实现了利用单线程达到并发的效果。在实际情况中，一些活动可能会持续几天，倘若进程发生错误时，进程的执行状态就会丢失。所以用类似“挂起”这种能把执行状态保存在磁盘的操作会更好。然而把进程挂起到磁盘上存在着一些实现上的问题。在我们希望“挂起”时，调用栈看起来是这样的：Sequence.run()Wait.run()为了把进程保存到磁盘上，我们需要终止当前的控制进程，这就意味着要弹出所有栈结构。要做到这些，我们只有通过等待活动(Wait)和顺序活动(Sequence)的实现去迎合这种需求，因此带来的会是实现复杂程度的增加。并且这也意味着所谓“自然”（即符合人们正常思维）的模型不能够被直接使用。JACOB的目标就是提供一个可选的“自然”的模型来解决这个问题。这个模型能够允许执行状态被挂起，但是却不需要实现类（如wait，Sequence）等做出特别的更改。JACOB的思想就是不使用调用堆栈，而是以来自外部的通信渠道(communication channel)来控制流程。3.2.2通道Channels如上所述，通道是用于流程执行环境中活动的通信的接口。通道有终结通道(Termination Channel)，父事务范围通道(Parent Scope Channel)和补偿通道(Compensation Channel)等几种。某