【毕业学位论文】（Word原稿） BPEL引擎监控平台的设计与实现-计算机软件与理论

分类号 密级 编号 中国科学院研究生院 硕士学位论文 擎监控平台的设计与实现 指导教师 魏峻 研究员 中国科学院软件研究所 申请学位级别 硕士 学科专业名称 计算 机软件与理论 论文提交日期 2008论文答辩日期 2008培养单位 中国科学院软件研究所 学位授予单位 中国科学院研究生院 答辩委员会主席 独创性声明 本人声明所呈交的论文是我个人在导师指导下进行的研究工作及取得的研究成果。尽我所知，除了文中特别加以标注和致谢的地方外，论文中不包含其他人已经发表或撰写过的研究成果。与我一同工作的同志对本 研究所做的任何贡献均已在论文中作了明确的说明。 签名： _ 日期： _ 关于论文使用授权的说明 本人完全了解中国科学院软件研究所有关保留、使用学位论文的规定，即：中国科学院软件研究所有权保留送交论文的复印件，允许论文被查阅和借阅；中国科学院软件研究所可以公布论文的全部或部分内容，可以采用影印、缩印或其它复制手段保存论文。 （保密的论文在解密后应遵守此规定） 签名： _ 导师签名： _ 日期： _ 中文摘要 摘 要 为 务复合事实上的标准正引起越来越多的关注， 它可以用来整合物理上分布的服务，构建复杂的业务流程 。 但是，目前的 范只关注对业务逻辑的建模， 缺乏对监控需求描述的支持 。另一方面，在面向服务的计算环境下，许多应用场景需要一种运行期的监控机制来 对业务流程的行为进行约束 及性能分析 。 本文首先对业务流程运行时的监控需求进行了分析，然后针对这些监控需求， 结合 出了一种新型的 基于事件驱动的 监控需求描述语言 以精确的 刻画功能性和非功能性的监控需求 ，同时具有简洁易懂 ， 易 于实现等特点。 此外，本文 研究了基于 术实现业务流程监控机制的方案 。 利用 术，我们可以在业务流程实例 运行期间 动态定义监控规则 。 同时， 它 使得流程的业务逻辑和监控逻辑分离开来， 在不影响 程 可移植性 的情况下 ，为业务流程执行引擎引入监控机制 。 最后，论文探讨了监控平台 在自主研发的新一代 擎 的实现， 并对监控平台进行了 功能 和性能方面的 测试 。 关键词 ： 运行期 ，监控需求 英文摘要 s de It be to to on to of oS of On a to of In to we a in be to it is be an to we no to we on a of 录 - 1 - 目 录 目 录 第一章 绪论 究背景 务复合的兴起 务复合的监控 文工作 文组织 第二章 务复合与监控技术 向服务体系架构 构介绍 抽象级别 务复合 务协议栈 绍 1 特点 2 合服务监控技术相关研究 3 于断言的监控技术 3 于事件演算的监控技术 4 于线性时序逻辑的监控技术 5 第三章 监控需求描述语言 7 程中的监控需求 7 个业务流程实例 7 务流程监控需求分类 8 绍 9 构成 9 0 1 1 用 描述监控需求 2 章小结 3 第四章 流程监控 4 绍 4 本概念 4 编织时机 6 术的优势 7 目 录 - - 2 的横切关注点 7 展 9 9 0 0 入 0 1 获 本事件 1 自动机语义 2 计算 4 计算 5 章小结 5 第五章 监控平台在 擎中的实现 6 擎简介 6 统架构图 6 件图 7 功能与特色 7 控平台系统架 构 8 控平台概念视图 8 控平台组件图 9 控平台组件交互图 0 控框架的实现 2 控消息的处理 2 件树的组织 5 控配置文件的解析 7 架的实现 0 置文件的自动生成 0 流程实例的绑定 1 动态编织 3 统测试 4 试环境 4 试用例场景 5 试结果 7 第六章 结束语 9 文主要贡献 9 来工作 9 附录：监控配置部署描述符 1 参考文献 3 发表文章 5 致 谢 6 第一章 绪论 - - 3 第一章 绪论 本章介绍研究背景、论文工作和论文组织 。 究背景 自从 二十 世纪七十年代软件工程诞生以来，软件开发方法经历了面向过程，面向对象，到后来的面向组件，面向集成 这么几个阶段，一直致力于解决软件开发中面临的种种问题，力求以较低的开发成本，开发出 能快速响应不断变化 业务需求的，具有较好性能的，可扩展性和可维护姓较好的软件系统。 但是， 随着 二十世纪九十年代 发展与普及 ， 软件技术 面临着 新的 挑战。 台具有如下基本特征 1:无统一控制的“ 真”分布性 ； 节点的高度自治性 ； 节点链接的开放性和动态性 ； 人、设备和软件的多重异构性 ；实体行为的不可预测性 ； 运行环境的潜在不安全性 ； 使用方式的个性化和灵活性 ；网络连接环境的多样性等 。而 传统计算范型难以刻画计算单元的分布、自治特征，交互的开放、松散耦合特性，以及应用的敏捷特质 。 针对上述问题，面向服务计算范型应运而生。面向服务计算范型通过定义良好的契约整合异构资源，强调自治、面向重用的计算单元间松散耦合的自动化交互，倡导通过面向业务的灵活流程来构造应用。比较传统计算范型，面向服务计算范型引入了更具柔性和适应 算环境特征的软件体系结构，即面向服务体系结构（ 2。面向服务的体系结构是一种组织和利用处于不同所有权域控制下的分布式能力的计算范型 3。其服务自治、松散耦合、面向重用、基于契约的特点能够很好地适应 务复合的兴起 目前，复合服务已经成为开发企业内部业务应用和企业间业务协作一种新的模式，即 一个中心节点协调参与方之间的交互，通过 务 4来执行具体的活动 。 这种计算模式的优势在于 企业 用 务方式提供自己 的业务功能，客户可以 不关注 实现服务的具体技术，查找和绑定这些服务。 这种企业计算模式 和其它企业 计算模式 的不同之处在于 前者能 提供业务敏捷性 ，即企业能快速、有效地响应变化并且利用各种变化 获得竞争优势 5。 但是， 这种业务敏捷性能否真正获得还取决于该计算模式的实现。 在 企业信息基础设施之上集成涵盖整个业务流程的企业业务应用， 一方面 ， 提供服务 的信息基础设施必须满足业务需求的动态变化 ，另一方面， 业务模型也要能适应信息基础设施 的 变迁和多样性。因此，在业务模型和信息基础设施之间，需要有新的第一章 绪论 - - 4 中间模型作 为中介，使得企业业务需求的任何变化，都可以反映到中间模型中；同样，该中间模型需要适应 底层 的信息基础设施变化，屏蔽信息基础设施的变化对业务模型的影响。具体来说，在基于 务的 要 一种能够以平台无关的方式充分反映 企业 业务 流程的 服务 模型及相关工具；而且该模型及相关工具应该支持对组成企业业务系统的 持 合模式以及应该满足的约束关系的定义和支持 从 服务 模型自动生成 运行 代码 。通过 创建位于 企业业务 和底层 信息基础设施 之间的抽象 的中间模型，进而保证底层技术的 实现与企业业务需求的一致性。 务复合的本质是协调若干 务共同工作，它在面向服务的企业计算模式中扮演着中间模型的角色，即通过 务的复合，最终能灵活实现上层的业务模型，屏蔽底层信息基础设施的变迁。从 理论上 讲 ，新的 业务应用 可以 由 一系列 合 ，而且这个过程不需要任何编程工作 。 可视化工具能够把多个服务按照合适的次序连接在一起，并生成实施复合操作所必需的消息代码 . 因此，如何复合这些已有的、自治的 务构筑企业新的业务应用的问题也成为软件工程领域一个新的热点 问题 6. 由 结构化信 息标准促进组织 (7标准化的 范 8已经是 务复合事实上的标准，本 文 的第二章将详细介绍 范。 务复合的 监控 基于服务组合的流程（如 于其本身固有的灵活性和动态性，其行为在执行期间可能发生重大的改变 9， 因此 ，需要一种在流程执行期间对其行为进行监控的机制 10。 对于传统的企业应用程序来说，由于其运行环境的稳定性，在程序部署前对其进行完备的测试，可以有效的发现程序中的缺陷和错误。但是，对于基于 的运行环境 是不可预知的，典型的有如下几种情况： 第三方服务在不改变接口的情况下，改变了该服务的内部实现 流程在运行期动态的选择 第三方服务的提供商 流程在运行期 动态的选择同一服务提供商的服务新版本 所依赖的第三方服务的执行环境可能发生动态的改变 这些 问题 是服务复合 程序 特有的问题，而在流程在执行前是不可能预知这些问题的，因此， 我们需要引入一种在执行期对流程进行监控的机制，来解决 这些传统的部署前的测试活动 无法 有效 解决的问题 。 复合服务执行期监控可以分为如下两大类： 功能性监控 主要是对 业务流程和第三方服务进行功能正确性方 面的监控，确保业务规则的正确和有效实施，一旦发现有业务规则被违反，则可以实时的做第一章 绪论 - - 5 出反应，快速采取应对措施，避免错误扩散。 非功能性监控 主要是对业务流程本身和所依赖的第三方服务的服务质量进行监控，如某个服务的调用时间，某个活动的执行次数等。这可以为业务流程在执行期间动态选择服务提供和流程本身的优化提供参考依据。 本文 第三章将详细介绍服务复合监控技术。 文工作 论文工作主要围绕 如何在 擎中引入监控机制展开研究，主要包括如下三个方面： 1) 程监控需求描述 论文首先阐述了为业务流程的执行引入监控机 制的必要性，接着分析了业务流程中监控需求的分类。针对业务流程的监控需求，并结合 程执行的特点，提出了 基于事件的 监控需求描述语言 种 控语言不仅能精确描述业务流程监控需求，同时 引入参数约束（ 概念， 可以极大的减小由于监控机制的引入对流程执行效率的影响 。 此外，具有简洁易懂的优点。 2) 面向方面的监控机制 在确定了 程的监控需求描述语言之后，需要将监控功能引入擎，使得监控平台能够接收从引擎转发过来的监控消息（或事件）。传统的方法是通过扩 展 范，增加支持监控机制的语言要素来实现11。但这种方法影响了 件的可移植性，本文引入了 面向方面编程（ 12技术，从而使得监控平台和 擎实现松散耦合，并且无须修改 件，无损其移植性。 3) 控平台的设计与实现 3是由中科院软件所软件工程技术中心设计开发的 业务流程执行环境 ，在其基础上，我们设计并实现了监控平台。 它可以对业务流程进行功能性和非功能性的监控，同时支持监控器的热部署 ， 从而极大的增强了 为企业级业务流程运行 平台的竞争力。 文组织 论文的后续章节按以下方式组织： 第一章 绪论 - - 6 第二章 首先介绍面向服务体系结构（ 然后对服务复合在 扮演的角色进行了阐述。接着介绍了服务复合事实上的标准 后着重分析了业务流程监控技术的相关技术。 第三章 通过 引入一个业务流程实例，阐述了复合服务中的各方面的监控需求。然后介绍了 程执行过程中的基本事件，最后针对复合服务的监控需求，结合 特点，提出了 控 需求 描述语言 ，并对该语言的语言元素 进行了详尽的说明 。 第四章 介绍 了面向方面编程（ 包括其基本概念、工作原理、优点等。然后提出 基于 术的 流程监控的方案，将 各个基本概念对应到业务流程监控中去，对其工作原理进行了详尽的阐述。 第五章 介绍了 擎 整体架构以及 监控平台的设计和实现方案，并通过一个一个具体的案例 ， 对监控平台 的实现 进行了 功能 和性能方面的测试 。 第六章全文工作进行总结，列举了论文工作的主要贡献，并且对进一步研究进行 展望。 第二章 务复合与监控技术 - - 7 第二章 务 复合 与监控技术 本章首先介绍面向服务体系结构（ 然后对服务复合在 扮 演的角色进行了阐述。接着介绍了服务复合事实上的标准 后着重分析了业务流程监控技术的相关技术。 向服务体系 架 构 绪论中我们曾提到，面向服务体系架构（ 企业构建快速响应业务需求变化 ，可维护性和可扩展性的软件系统提供了一种新的解决方案，那么，什么是 ？ 构 介绍 关于 前尚未有一个统一的、业界广泛接受的定义。一般认为： 它将应用程序的不同功能单元 服务（ 通过服务间定义良好的接口和契约（ 系起来。接口采用中立的方式定义，独立于具体实现服务的硬件平台、操作系统和编程语言，使得构建在这样的系统中的服务可以使用统一和标准的方式进行通信。这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。 图 4给出的 型中三种不同角色的关系示意图： 图 面向服务体系架构图 该架构刻画了服务提供者、服务请求者和服务注册中心三类角色，以及这些角色之间通过发布、发现、绑定三种基本操作建立的交互关系。 面向服务架构由三个参与者和三个基本操作构 成。三个参与者分别是服务提供者、服务请求者和服务注册中心，而三个基本操作分别为发布 (查找(绑定 (服务提供者将其服务发布到服务注册中心的一个目录上；当服务请求者需要调用该服务时 ,他首先利用服务注册中心提供的目录去搜索该服务，得到如何调用该服务的信息；然后根据这些信息去调用服务提供者发布的服务。当服务请求者从服务注册中心得到调用所需服务的信息之后，通信是在服第二章 务复合与监控技术 - - 8 务请求者和提供者之间直接进行，而无须经过服务注册中心。 例如 :使用 5来描述服务 ,使用6来发布、查找服务，而 7被用来执行服务调用。 有如下特点： 1) 服务的封装（ 将服务封装成用于业务流程的可重用组件。它提供信息或简化业务数据从一个有效的、一致的状态向另一个状态的转变。封装隐藏了复杂性。服务的 持不变，使得用户远离具体实施上的变更。 2) 服务的重用（ 服务的可重用性设计显著地降低了成本。为了实现可重用性，服务只工作在特定处理过程的上下文（ ，独立于底层实现和客户需求的变更 。 3) 服务的互操作（ 互操作并不是一个新概念。在8、 9、 就已经采用互操作技术了。在，通过服务之间既定的通信协议进行互操作。 供服务的互操作特性更利于其在多个场合被重用。 4) 服务是自治的（ 能实体。服务是由组件组成的组合模块，是自包含和模块化的。 常强调架构中提供服务的功能实体的完全独立自主以及 自我管理和恢复能力。 5) 服务之间的松耦合度（ 服务请求者到服务提 供者的绑定与服务之间应该是松耦合的。这就意味着，服务请求者不知道提供者实现的技术细节，比如程序设计语言、部署平台，等等。这个松耦合使会话一端的软件可以在不影响另一端的情况下发生改变，前提是消息模式保持不变。 服务是位置透明的（ 服务是针对业务需求设计的。要想真正实现业务与服务的分离 ， 就必须使得服务的设计和部署对用户来说是完全透明的。也就是说，用户完全不必知道响应自己需求的服务的位置，甚至不必知道具体是哪个服务参与了响应。 抽象级别 从概念上讲， 有三个主要的抽象级别： 1) 操作：代表单个逻辑工作单元（ 事务。执行操作通常会导致读、写或修改一个或多个持久性数据。 作可以直接与面向对象 (的方法相比。它们都有特定的结构化接口，并且返回结构化的响应。同方法一样，特定操作的执行可能涉及调用附加的操作。 第二章 务复合与监控技术 - - 9 2) 服务：代表操作的逻辑分组。服务可以分层，以降低耦合度和复杂性。一个服务的粒度（ 小也与系统的性能息息相关。粒度太小，会增加服务间互操作通信的开销；粒度太大，又会影响服务面对需求变化的敏捷性。 3) 复合服 务 ：为实现特定业务目标而执行的一组长期运行的动作或活动。复合服务 通常包括多个 服 务调用。 复合服务在 现中扮演了重要角色，它带来了以下优点： 改善可重用性。复合服务为重用现有的服务提供了一种自然的方式。服务提供者可通过复合服务来增加价值。 更快投入市场。新的方案可以在更短时间内被构造出来。现存的服务（假设它们可被复合）以及一个结合并管理它们的机制，或多或少地能够减少构造新服务新方案的时间和精力。尤其是我们可以用现存的已达到生产级质量的服务快速地组装出一个可操作的原型。 改善安全性和审核能力。复合 服务代表了一系列底层服务的单一访问入口。单一访问入口是确保服务调用契约的一种简单而有效的方式，使能够我们控制和测量队成员服务的访问。 更低的重复性。冗余被减少或消灭。与其多次复制同样的业务功能，实现所需功能的一个业务服务可以在多个复合中被重用。 改善可修改性。因为同一个底层服务可以是许多复合服务的组成部分，也就是说对一个地方的修改就可以在整个企业的范围内改变一项功能 接下来我们将详细介绍 务复合 。 务复合 随着 务技术的日益成熟，越来越多的稳定易用的 务共享在网络上。 但单个的 务能够提供的功能有限，为了更加充分地利用共享的 必要将共享的 务组合起来，提供更为强大的服务功能，加快系统开发的速度，快速满足用户需求。 务组合作为 务一项重要的增值功能，为服务的重用与自动化集成提供了应用的基础 。 务复合是构建在务协议栈上的 。 务协议栈 图 务协议栈示意图： 第二章 务复合与监控技术 - - 10 图 务协议栈 如上图所示 ， 务的协议栈分为网络通讯、消息框 架、服务描述、服务服务组合五个层次。 1) 网络传输层 务不和特定的网络协议绑定， 客户可以通过各种不同的网络协议访问 务。例如， 可以是 应用层协议，也可以是 网络层协议。 务一般与 议绑定。 2) 消息层 该层定义 务的消息 传输 框架， 议是 务中使用最广泛的消息 传输方式 ，一般的 务中间件也称为 擎。除了 务还有一些其他访问方式，比如 式允许用户直接通过 用相应的 务 。 3) 服务描 述层 基于 务描述语言，提供功能性描述和非功能性的描述接口。功能性描述 描述了 务的接口，包括可用的操作、操作参数、数据类型和访问协议。 务的客户端可以使用 务的接口信息，绑定到 务的提供者，并且调用其服务。同时， 供非功能性描述的扩展接口，用户可以描述包括服务可用性、可靠性、可扩展性、安全、认证、（事务）集成等非功能性特性。 4) 务的描述语言 身并未定义的服务 性， 务的 性是有 协 议 族 提 供 的 ， 包 括 0 、1和 2等。 5) 服务 复合 层 以上四层均描述了单个服务的信息，服务组合层提供了对复合服务的支第二章 务复合与监控技术 - - 11 持，目前广泛使用的服务复合语言是 绍 一种基于 业务流程编排语言，作为一种 务 复合语言，它描述了一系 列 务交互过程，同时也描述了一个控制流（即服务交互的顺序）和数据流（即各个组成服务之间的数据交换）。 图 出一个 务 流 程的一般 结构。 可以看出， 要由活动(成。要从流程定义 产生一个实例，必须至少要定义一个 消息到达后，则产生一个业务 流 程的新实例并开始运行。所以，在 流程实例 的建立是隐含的。 图 组成 在整合 务和定义业务过程中，一个主要的挑战是如何处理有状态的交互。业务 流程 必 须保存每个实例的状态 。由于有不同的业务 流 程实例，所以消息传递不仅要针对相应的 端口，还要针对相应的实例。为了保证全局协同性和避免执行的依赖性，我们需要消息的动态绑定机制。 这个机制在 过定义诸如 样的集合来提供，即一个在相关群体中被所有消息共享的令牌集合。这个集合被称之为 旦该集合被初始化，则相关的令牌被标示到所有的消息。 在业务 流 程中执行的 活动 可以划分为基础 活动 (结构化 活动 (基础 活动 执行简单的操作，诸如 结构化 活动 则把一系列基础 活动 按某种执行顺序组合，而且结构化 活动 还可以嵌套。结构化 活动 包括 以使 一系列 活动 按部就班的发生， 供了在一系列 活动 中做选择的能力。 以使多个 活动 并发执行。 待一系列实例中的某一个发生，然后执行相应的 活动 。 复地执行一个 活动 ，直到它的条件不再为真。 业务 流 程基于某种 逻辑定义业务成员之间的交互。这些 流 程通常具有较 长的执行时间，并包括异步消息传递。因此， 在这种环境下的出错处理 (不容易，它通过补偿机制来实现，即是企图回复前一个行为的效果 。 这种对异:= , V) := :=| := 二章 务复合与监控技术 - - 12 常进行补偿的能力使得业务 流 程具有长运行事务 (23 特点 建在 务的基础上。它是一个以 基础的语言，支持 务技术的协议群，包括 早期两个工作流语言（ 4和5）的综合。 有以下的特点： 1) 有传统编程语言的一些基本特性， 继承 和发展了编程语言的思想，它包括了以下的操作： 赋值操作 (由 活动实现 )； 循环操作 (由 活动实现 )； 选择操作 (由 活动实现 )； 远程调用操作 (由 活动实现 )； 异常捕捉操作 (由 和 实现 )； 异常抛出操作（由 活动实现） 2) 要用于构造可执行的业务流程，因此它也就自然具备一些流程描述与执行 语言的特点，这体现在以下几个方面： 提供对于远程调用 ()的同步和异步处理： 这主要是由业务流程的特点所决定的。业务流程调用的外部服务有可能具有多种的消息交换模式，而 其中最主要的两种。同步调用方式支持调用 式的服务，在调用后等待返回结果；而异步调用方式则支持调用 式的服务，在发出调用请求后继续执行其他的操作，外部服务在执行完毕以后可以调用程提供的消息接口来返回调用结果。 提供并发操作