（计算机科学与技术专业论文）分布式工作流引擎及其负载平衡技术的研究与实现.pdf

国防科学技术大学研究生院学位论文 图目录 图1 1 基于拗消息i i l 列的系统斓3 图1 _ 2f 1 佣a g e n t 系统结陶4 图2 。l 工作流伞i 。，。8 图2 2 工作流平台9 图z 3 盱峪的基本特性，以及b 搠能间的关系1 1 图2 4 工作流管理系统实施的三个阶段l l 图2 5 传统的b s 壤三层模型1 3 图2 6 分稚| 作灞晖晦菇月j 结阻1 4 图3 1 矧籍攀帝彬罐奔姻1 8 图3 2 活动实例状态转换图1 9 图3 3 四种任务管理器的实瑗方法2 2 图生1 负载平蒯旆l 防法一2 6 图4 2 负载平衡控惦去二2 6 图4 3 调度系统鲤2 8 图4 4 t 帆和浠茹辑野事甥之间懒 懒繇：轮 嗍蹴5 4图5 。1 4 豫假掂实照【静哄系负爵醐阑燃5 5 图515孙倒狸实圃防哄系轮旬iil燃5 5 图5 。1 6 豫嬷鲣实赞够蚨系舞鼢髑阔嫩 x 独创性声明 本人声明所呈交的学位论文是我本人在导师指导下进行的研究工作及取得 的研究成果。尽我所知，除了文中特别加以标注和致谢的地方外，论文中不包含 其他人已经发表和撰写过的研究成果，也不包含为获得国防科学技术大学或其它 教育机构的学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任 何贡献均已在论文中作了明确的说明并表示谢意。 学位论文题目：生逋式王佳速! 鍪丞基鱼蔻垩煎垫盔鲍堡塞生塞塑一 学位论文作者签名：；批翌日期：口b 哆i - 年，2 月；。日 学位论文版权使用授权书 本人完全了解国防科学技术大学有关保留、使用学位论文的规定。本人授权 国防科学技术大学可以保留并向国家有关部门或机构送交论文的复印件和电子 文档，允许论文被查阅和借阅；可以将学位论文的全部或部分内容编入有关数据 库进行检索，可以采用影印、缩印或扫描等复制手段保存、汇编学位论文。 ( 保密学位论文在解密后适用本授权书。) 学位论文题目： 佥鱼盛三堡逾到鍪区基筮惑壬煎垫苤鲍盟童曼塞丑 学位论文作者签名：势l翌 作哲指导教师签名： 日期：如心年，2 月，日 日期：z 旷年l ；月了。日 国防科学技术大学研究生院学位论文 第一章绪论 1 1 课题背景 近年来，i n t e r n e t 等新技术为b p r 的实现带来了一个基于网络计算的业务处理新概念 工作流管理系统( w o r k f l o wm a n a g e m e n ts y s t e ，简称w f m s ) 。工作流的概念起源于生 产组织和办公自动化领域。它是针对日常工作中具有固定程序的活动而提出的一个概念。 提出的目的是通过将工作分解成定义良好的任务、角色，按照一定的规则和过程来执行这 些任务并对它们进行监控，达到提高办事效率、降低生产成本、提高企业生产经营管理水 平和企业竞争力的目标。w f m s 系统可以把人工业务或异构环境中的自动应用系统集成到统 一的业务过程中。利用企业已有的计算设施，通过业务任务间的依赖关系，w f m s 系统可以进 行复杂的任务协同调度。大型组织中的业务过程常常涉及到分布在不同地理位置上的许多 资源、工具和人员，所以，w f m s 必须能进行全分布任务及其调度的定义。如果任务和任务 间的携同信息可以被分布到异构环境中，一个任务的改变将不会影响到整个业务过程，这 就增强了w f m s 的可扩充性和可靠性。 如参考文献 3 中，随着c o r b a 和j a v a b e 8 n s 等分布式对象技术的成熟，人们也开始用 它们来构造工作流系统。例如，f 1 0 w m a r k 使用o b j e c t s t o r e 来对分布的工作流客户系统进 行集中的控制管理：w i d e 系统使用c o r b a 环境给分布的工作流客户提供集中的调度策略定 义和控制。工作流技术一出现马上就得到广泛重视和研究。工作流产品的市场每年以两位 数字的速度迅猛增长，目前市场上比较成熟的工作流产品就有2 0 0 多种。其中具有代表的 产品有：i 叫公司的s e r i e s 耳o r k f l o w 、a c t i o n 技术公司的m e t r o 、f i l e n e t 公司的 v i s u a lw o r k f l o 、j e t f o 珊公司的i n t e m p o 和p a v o n e 公司的g r o u p f l o w 。至今工作流管理 技术己成功地运用到图书馆、医院、傈险和银行等行业。1 9 9 3 年工作流管理联盟( w o r k f l o w m a n a g e m e n tc o a l i t i o n ，w f m c ) 的成立标志着工作流技术进入相对成熟的阶段。为了实现 不同工作流产品之间的互操作，w f m c 在工作流管理系统的相关术语、体系结构及编程接口 方面制定了一系列标准。 1 1 1 分布式工作流及工作流引擎需求简介 工作流是针对日常工作中组成工作流程的一系列活动而提出的一个概念。其目的是通 过特定的工作流建模机制将日常工作中的工作流程抽象出来，然后再按照一定的规则对这 个抽象出来的工作流程进行管理和监控。从工作流所需要解决的问题来看，工作流必然需 要以分布的形式出现。无论是从企业的信息环境、组织环境，还是与外界的协作环境来看， 都具有明显的分布式特点： 第l 页 国防科学技术大学研究生院学位论文 网络的延伸 系统的异构 人员的分散 供求关系的全球化 分布式工作流采用分布式策略将工作流系统功能离散化或者模块化，这些模块既可以 在同一个机器上运行，也可以在通过网络连接的几台不同机器上运行，通过各个模块间的 相互协同工作，实现预定的功能。对工作流引擎的分布性要求客观上是由企业的实际运行 环境决定的，工作流管理系统可以采用不同的方法来满足企业应用对于分布性的要求。工 作流引擎是工作流管理系统提供执行服务的核心模块，它的分布是在系统体系结构分布的 基础上所实现的更高层次上的分布。由于工作流引擎直接负责过程实例的解释和执行，它 的性能将直接影响到整个系统的运转效率。集中式工作流引擎是由一个工作流引擎来控制 所有计算机上活动的执行，这种集中式的工作流引擎处理方式在系统的可靠性、可扩展性、 实用性以及吞吐量等方面都不能满足企业执行大规模复杂应用的需求。分布式工作流引擎 是指采用一组分布在不同接点上的工作流引擎来共同协作完成对整个任务实例的执行，每 个工作流引擎完成其中一部分实例的执行，不同的工作流引擎之间通过可靠的通讯机制实 现协作。通过由分布在不同网络节点上的多个工作流引擎协作来运行工作流过程，可以明 显改善集中式工作流引擎的性能瓶颈问题。 1 1 2 工作流研究现状 工作流管理技术在其发展的初期主要是由工作流产品开发的公司推动着其发展，随着 它在实际应用中取得的良好效果而得到了充分的重视，并迅速发展。相对于工作流产品市 场的繁荣，工作流相关理论研究则显得比较滞后。 现有工作流系统比较著名的有i b m 开发的基于持久消息队列的分布式工作流管理系统 e x o t i c a f m q m ，达特茅斯大学计算机系开发的一种基于可移动代理的工作流系统d a r t f l o w ， 美国g e o r g i a 大学m e t e o r 项目中的w e b w o r k 等等。 e x o t i c a f m q m ( f l o w m a r ko nm e s s a g eq u e u e 凇n a g e r ) 在参考文献 5 中是一种基于 i b m 原有工作流管理系统f l o w m a r k 的完全分布的工作流管理系统。整个工作流管理系统由 许多具有自治能力的节点组成，每个执行节点都是相互独立的，工作流过程的执行不以某 一个节点为中心，从而实现了完全分布。e x o t i c a 嗣蛳在解决系统负载平衡是采用的静态 负载均衡的策略，过程模型在建模结束后被绑定到各个节点上，将各个节点执行活动所需 的模型信息发送到各个节点中，也就是对模型进行编译，事先确定执行的地点。过程实例 的执行是由各个节点根据模型的定义和具体实例运行的情况来主动完成实例的推进和运 行，直至运行完毕。在运行过程中，需要传递的只有实例的状态和以前计算的结果。这种 方法避免了由于大量数据传递造成的数据库和服务器负担太重，但是还是不能解决动态负 第2 页 国防科学技术大学研究生院学位论文 载平衡的问题。当工作流中的某一个特定任务被大量执行时，还是会成为系统性能的瓶颈。 1 】e b w o r k 类似e x o t i c a ，根据参考文献 5 也是完全分布的工作流管理系统。如图1 1 所示，它通过持久消息( p e r s i s t e n t 睢e s s a g e s ) 的方式来保存工作流相关执行消息，从 而使得其每个节点都具有一定的自治能力，知道在某个活动完成后，应该执行哪个活动， 这些信息都是在实例执行前进行编译时产生并储存在各个节点中的，采用的是通过o r b 进 行函数调用来传递活动调用信息。检验器中包含了有关下一个活动的信息，由检验器负责 判断下一个应该执行的活动，并调用之。 图1 ，1 基于持久消息队列的系统运行图 基于持久消息队列的分布式模型使得每一个单独的执行节点能够独立完成相应的工 作流活动，从而实现更为彻底的分布式工作流运行方式，大大提高了工作流系统的可靠性， 同时，通过增加具有工作能力的执行节点的数量，可以很容易提高工作流系统的任务处理 能力，增加吞吐量，而避免了集中方式下服务器方很快出现的瓶颈现象。 第3 页 国防科学技术大学研究生院学位论文 但是完全的分布式执行也带来一些麻烦，它使得在集中方式下很简单的一些问题交得 复杂，比如判断工作流过程实例是否完全结束、工作表管理、对实例状态的监控等等。尽 管持久消息在系统出现异常时能够被完全恢复，但是在某些情况下，全部使用持久消息所 带来得开销可能会很大。系统设计人员需要根据实际情况，灵活地选择持久消息与非持久 消息。比如工作流定义节点与其他节点间的联系就可以采用非持久消息。由于持久消息及 队列是建立在底层的消息系统基础上的，而不同的消息系统在具体的功能方面有其自身的 特点和局限。因此，在这一模型的实现上采用不同的消息系统作支持会面临不同的问题。 分布式w f 峪( d i s t r i b u t e dw f m s ) ，为了提高系统的鲁棒性，许多学者研究如何实现 w f m s 的分布处理，一个流程可以使用多个分布的工作流引擎，每个工作流引擎可以调用不 同流程实例或者流程实例的不同任务，一个调度引擎发生故障时，不会影响其它引擎的工 作。分布式系统带来的一系列问题，如数据一致性，并发行，备份和恢复问题，这些都是 当前研究的热点。 国内提出的分布式工作流系统f 1 0 w a g e n t 。参考文献 1 7 中提出相应的动态任务调度 逻辑和适合于工作流动态特性的业务描述结构。如图1 2 ，f 1 0 w a g e n t 是建立在任务代理 ( 我们称为t a s k a g e n t ) 概念上的任务流系统，它采用一个全分布的体系结构来支持任务的 动态调度和工作流过程的高可扩充性。 为处理这些工作流，把接个系统分解成若干相对独立的工作域。工作域中的实体都称 为t a s k a g e n t ( 任务代理) 。每个工作域中都有一个被称为t a s k d o i i l a i n ( 任务域) 的t a s k a g e n t 实体，协同其他实体共同完成“处理工作”，并称其为m o t h e r ( 母亲) 。在这个工作域中的 儿子t a s k a g e n t ，要么是一个t a s k p r o c e s s o r ( 应用程序) ，要么是另一个工作域的 t a s k d o a i n 。由此组成了多任务域层次体系结构。 一一一0 - 一 - - i 埘冒一睇e 一m 杠 - 瑚篡玎 氆r 。a 峨d 图1 2f l o w a g e n t 系统结构 第4 页 国防科学技术大学研究生院学位论文 在这样的多任务域结构( m u l t i _ t a s k d o m a i na r c h i t e c t u r e ) 中，即便非常复杂的工作流 过程也可以被分解在若干层的t a s k d o m a i n 之中。在每个t a s k d o m a i n 中，大多数任务运行 调度的控制逻辑可以独立地被定义和修改，而不必牵涉更高层低层的t a s k d o m a i n 或其他 兄弟t a s k d o m a i n 的调度逻辑。由此，可以控制一个t a s k d o m a i n 的复杂性，实现整个工作。 f l o w a g e n t 系统应用j a v a b e a n s j a v ar m i 等分布式对象设施，设计了一个可以支持跨平台、 企业的工作流过程的分布式体系结构。多任务域结构对于分布式w f m s 系统的一些关键问 题，如可扩充性、动态角色决定等等，提出了比较好的解决方案。不过整个设计实现过程 比较复杂，而且这个调度策略并不能准确及时的反馈分布式工作流系统的负载信息，对于 多引擎间任务调度将出现不平衡，导致某些节点负载过重或是某个节点出现故障的问题还 是不能比较好的解决。 总的来说工作流系统的应用还是处于一个非常谨慎的状态，当前工作流系统存在着各 种各样的缺陷或不足： 工作流的运行必须要有底层的通信基础结构的支持，比如，c o r b a ，d c 0 m ，j 2 e e 都是 选择之一，但是从当前实现分布式计算环境的产品来看，他们在实际应用中仍然 显得不够成熟，而且在价格上也给企业造成一定的负担。 性能问题，当前的大多数工作流产品无法满足企业每天处理成千上万份的业务需 求。 柔性问题，无论是过程模型的表示还是角色解析，现有的工作流系统表现出来柔 性差的特点。企业的实际应用常常有对执行路由的动态需求以及工作执行人员的 动态选派，对于这些需求现在的工作流系统都不能很好地解决。 鲁棒性问题，工作流系统在企业的实际应用中，常常会由于某种不常规的操作从 而造成流程执行的错误。这些不常规操作包括流程定义的不合法性，操作的时间 长等等。对于这些错误问题的妥善解决也是以后的工作流系统需要做的工作。 现在国内使用的工作流系统一般都是采用一些常见的负载平衡算法来平衡各个引擎 的工作负载，比如轮询调度算法( r o u n d r o b i ns c h e d u l i n g ) ，但是这些负载平衡算法远远不 够。轮询调度算法把区别出来的各个任务平均地分配给各个结点。其优点是算法简单易于 实现，缺点是任务的平均化并不等于实际工作负载的平均化，即不能准确地实现预想的基 于负载均衡的分配策略。我们需要根据不同的情况使用不同的负载分析技术，以适应新的 负载要求。 1 2 本文主要工作 在硕士课题研究期间，本文作者主要致力于如下工作： 1 详细了解工作流管理系统的应用背景和基础知识，对要做的工作形成一个整体认识。 着重研究现有的分布式工作流引擎工作和负载平衡技术所采用的方法及其优缺点。 第5 页 2 1 1 工作流基本概念 第二章工作流概述 2 1 工作流介绍 工作流是全部或部分由计算机支持或自动处理的业务过程。工作流的最根本目的是在 正确的顺序下，各项任务由最合适的人员执行，使得业务过程的执行达到最大效率。以工 作流干预过程、业务程序的自动化处理文档、信息或任务按照定义好的规则在参与者间传 递的方式，来完成整个业务目标或者支持整个业务目标的完成。工作流可能由手工组织， 实际上多数工作流都是在i t 系统中进行组织的，从而对过程自动化提供计算机支持，工 作流管理联盟( t h ew o r k f l 0 wm a n a g e m e n tc o a l i t i o n ) 把工作定位在这个方向上。 工作流经常与“过程重组”( b u s i n e s sp r o c e s sr e e n g i n e e r i n g ) 联系在一起。b p r 是关于企业( 组织) 核心业务过程的评估、分析、模拟、定义以及其后的操作实现。如参 考文献 5 ，尽管不是所有的b p r 都是采用工作流实现，但是工作流技术撮佳的方法之一， 这主要是因为工作流技术提供了业务过程逻辑与i t 操作支持的分离，从而以后可以修改 过程规则来重新定义业务规则。 关于工作流的两个基本概念是过程模型( p r o c e s sm o d e l ) 和过程实例( p r o c e s s i n s t a n c e ) 。过程模型( 在有的文献中也称为过程定义、过程模型、过程元数据等，本文 中统称为过程模型) 定义了业务过程中任务( t a s k ) 的执行顺序、执行任务所用的数据和 资源。过程模型实例化后的结果是过程实例。一个保险申请、一批订单、一张税务申报单 等都可以产生一个过程实例，它一般是由外部用户产生，也可以由企业内部成员( 内部用 户) 产生，工作流系统因为定时和特定事件触发等原因也会自动产生过程实例。在过程实 例中，任务对应的实例叫做工作项( w o r ki t e m ) ，例如“登记一个税收账单”、“发送 传真给客户”等。绝大部分的工作项需要被分派资源( r e s o u r c e ) 执行， x 里堕型兰苎查盔兰塑坠圭矍至坠塞垒垒星圣= = = = = = 一 与经营过程发生关联，可以应用于经营过程的不同阶段。图2 1 给出了一个称为工作流伞 的示意图反映了工作流覆盖的经营过程的范围与对应的工作流研究领域。 2 1 2 工作流实例 图2 1 工作流伞 如图2 2 ，工作流实例在运行时由引擎根据工作流模型创建。工作流实例的创建是执 行一个业务流程的开始，创建工作流实例包括创建工作流相关数据、业务数据和控制数据 等，以及分配该实例的全局唯一i d 号，取得实例开始节点的相关信息和激活条件。流程 实例在运行时有初始态、运行态、激活态、挂起态、完成态和终止态共六种状态。工作流 实例刚创建时处于初始态。一个工作流实例的运行是通过启动并激活实例的开始节点而开 始整个流程的。 任务实例是在流程运行过程中由工作流实例启动并执行时开始创建的。任务实例创建 时由工作流实例分配唯一的i d 号，并将工作流实例的相关数据传递给任务实例。任务实 例运行完成时将其相关数据返回给工作流实例，然后任务实例终止。流程启动时创建开始 节点实例，流程结束之前创建结束节点实例。开始节点和结束节点实例除执行相关任务操 作之外，结束节点实例还要修改实例的状态：结束节点的任务完成之后将工作流实例置为 完成态，工作流实例运行结束。 任务实例需要考虑下面两个问题： 超时处理：每一个任务都可以有一定的办理时间限制，如果规定时间到达后任务 还没有被处理完成，将进行超时处理。超时处理一般有以下几种：引发系统异常 处理；原地等待工作流用户进行处理；继续向下流转。 异常处理：异常情况是指流程流转时发生没有预料到的错误，导致流程不能顺利 流转下去。异常处理的方法是当引擎发现有异常情况时抛出异常的任务被挂起， 然后向系统管理员发出异常通知，由管理员进入挂起任务中进行手工处理，如修 第8 页 国防科学技术大学研究生院学位论文 改执行者、重新指定相关数据的值等。 任务实例的状态包括初始态、运行态、激活态、挂起态、完成态和终止态。 2 1 3 活动实例 图2 2 工作流平台 活动实例是任务实例在运行时创建的。任务实例创建活动实例时首先分配唯一的i d 号，然后将任务的相关数据传递给活动实例。一个任务实例包含一个或者多个活动实例， 各活动实例之间的执行顺序是预先定义好的，在某一时刻只能有一个活动实例在执行。 活动实例分为两大类型：一种是具体执行者、由手工完成的活动，我们称之为人工活 动；另一种是由工作流引擎负责完成的自动任务，它没有具体的执行者。人工活动被放入 任务表，由工作流用户通过客户端手动执行，而自动活动通过工作流引擎调用外部应用程 序。 2 1 4 工作流管理系统 工作流管理系统( w o r k f l o wm a n a g e m e n ts y s t e m ，w f m s ) 通过管理工作活动序列，调 用与各种步骤相关的人员、i t 资源，对业务过程提供自动化处理。面对全球范围内的竞争， 各企业都在试图摆脱冗余拖沓的层次组织结构，使企业的业务过程和决策建立在任务组自 第9 页 国防科学技术大学研究生院学位论文 我管理的基础上，这就导致了b p r 研究的出现：把易出错的传统业务过程中的人工或自动 任务集成到分布式企业的i t 环境中。w f m s 系统可以把人工业务或异质环境中的自动应用 系统集成到统一的业务过程中利用企业已有的计算设施，通过业务任务间的依赖关 系，w f m s 系统可以进行复杂的任务协同调度 w f m s 实现工作流的软件环境，概括起来它主要解决以下问题： 做什么( 由那些活动、任务组成，即结构上的定义) 怎么做( 活动间的执行条件、规则以及所交互的信息，即控制流与信息流的定义) 由谁做( 人或者计算机应用程序，即组织角色的定义) 做得怎样( 通过工作流管理系统对执行过程进行监控) 尽管实现工作流系统的方法多种多样，但是所有的w 刚s 都表现出某种共同的特性，这 就为不同产品间的集成、协同工作提供了基础。在最高层，所有的w f m s 都有相同的特性， 即为以下3 个功能提供支持： 1 ) 建立阶段( b u i l d t i m e ) 功能：利用一个或多个建模技术和工具，完成实际的经营过 程到计算机可处理的形式化定义的转化； 2 ) 运行阶段( r u nt i m e ) 的控制功能：定义的过程模型由工作流执行服务软件进行实例 创建并控制其执行过程，在需要人工介入的场合完成计算机应用软件和操作人员的交 互，实现模型中定义的经营过程与现实世界中实际过程之间的连接； 3 ) 运行阶段的人机交互功能：通过任务队列管理器实现各种活动执行过程中用户、i t 应 用程序( 工具) 之间的交互。 图2 3 描述了w f m s 的基本特性，以及上述功能间的关系。 工作流管理系统不同于普通的企业管理信息系统，普通的企业管理信息系统是事务处 理系统，其主要目的是满足企业业务操作功能，提高企业事务处理的效果和水平。工作流管 理系统的着眼点是面向市场、面向客户，其目的是在整个企业的业务层提高企业的业务处 理水平、强化企业的市场意识、提高对市场的应变能力。工作流管理系统在实际系统中的 应用一般分为三个阶段，既模型建立阶段、模型实例化阶段、模型执行阶段。图2 4 给出 了工作流管理系统的应用的三个阶段。模型建立阶段通过利用工作流建模工具完成企业经 营过程模型的建立，将企业的实际经营过程转化为计算机可处理的工作漉模型。模型的实 例化阶段完成为每个过程设定运行所需的参数，并分配每个活动执行所需要的资源( 包括 资源、人员、应用) 。模型执行阶段完成经营过程的执行，在这个过程中重要的任务是完成 人机交互和应用的执行，并对过程与活动的执行情况进行监控与跟踪。 第l o 页 过程设计与定义 运行阶段 过程实例化与控制 与用户、应用程序( 工具) 交 互 u i 工作流执行服务 l 00 l 0 ， l 人夕 i t 应用程序( 工具) 图2 3 删s 的基本特性。以及上述功能间的关系 过程定义过程实例 过程工程师系统管理员一般用户 图2 4 工作流管理系统实旌的三个阶段 果 第1 1 页 国防科学技术大学研究生院学位论文 2 2 1 分布式工作流 2 2 分布式工作流管理系统从工作流所需要解决的问题来看，工作流必然需要以分布的形式出现。因为无论是从 企业的信息环境、组织环境，还是与外界的协作环境来看，都具有明显的分布式特点。 如图25，在这样的环境下要完成不同应用系统的集成、不同组织人员的协作并最终达 到实现经营过程运作的自动化和高效率，所采用的工作流管理系统就必然要具有分布式的 特点。 “分布式工作流”的概念是相对于早期的集中式工作流管理系统而言的。在工作流技 的应用系统，比如图象、文档管理系统。它们以文件共享的方式实现任务间的协作。这种 “集中式”的情况反映了当时工作流技术的状况。 进入2 0 世纪9 0 年代，随着计算机与网络技术的迅速发展，特别是在i n t e r n e t 应用 日益普及的情况下，现代企业信息系统的分布性、异构性和自治性的特点越来越明显，相 信息的要求日益提高，clientserver体系结构和分布式处理技术(c0rba、珊w、ole、 java)被广泛应用。在这种大规模分布式环境下高效地运转互相关联的任务，并对执行的 个新的发展阶段分布式处理阶段。 参考文献 5 将工作流管理系统的分布分为以下三个层次： 工作流系统体系结构的分布：体系结构的分布是指从系统的层次上将工作流管理 系统分成一个相互协调的组成部分。这些组成部分按照其完成的不同功能独立自 擎以及其他外部应用几个部分组成，这些不同的组成部分之间通过wfms定义的五 类互操作接口进行连接。 工作流引擎的分布式执行：工作流引擎是工作流管理系统提供执行服务的核心模 块，它的分布是在系统体系结构分布的基础上所实现的更高层次上的分布。由于 算机上活动的执行，这种集中式的工作流引擎处理方式在系统的可靠性、可扩展 性、实用性以及吞吐量等方面都不能满足企业执行大规模复杂应用的需求。分布 式工作流引擎是指采用一组分布在不同接点上的工作流引擎来共同协作完成对整 第1 2 页 一 里堕型堂垫查查堂堑茎生堕兰垡鲨苎一 个任务实例的执行，每个工作流引擎完成其中一部分实例的执行，不同的工作流 引擎之间通过可靠的通讯机制实现协作。通过由分布在不同网络节点上的多个工 作流引擎协作来运行工作流过程，可以明显改善集中式工作流引擎的性能瓶颈问 题。 图2 5 传统的b s d b 三层模型 客户端 应用层 数据源 工作流模型的分布式定义与柔性执行：工作流模型的分布是指在一个分布的环境 下由参与人员协作完成工作流模型的定义。前提条件要求开发人员熟悉全部的企 业业务过程，并且这些业务过程都是开放的( 不存在保密问题) 。对于跨企业的 工作流管理系统比较可能的实现方法就是由不同的伙伴企业各自完成起内部流程 模型的建立，这些内部模型对外公开其交互的接口，以便实现不同企业工作流模 型之间的连接。 对工作流引擎的分布性要求客观上是有企业的实际运行环境决定的，工作流管理系统 可以采用不同的方法来满足企业应用对于分布性的要求。按照工作流管理系统设计开发的 难易程度，工作流管理系统的分布性也可以分为以上所述的工作流系统体系结构的分布、 工作流引擎的分布执行、工作流模型的分布式定义与柔性执行三种主要的分布方式。分布 式的工作流用户与应用接口通常是工作流管理系统必须提供的分布处理功能，因为企业的 应用软件和用户本身是分布在不同的计算机环境和不同的工作地点。 图2 6 给出了一种分布式的工作流执行服务情况。 其中左面表示的是集中式的工作流引擎模型，右面是分布式工作流引擎模型，整个系统 是一个由异构分布工作流引擎构成的工作流执行环境。对于工作流模型和工作流弓l 擎集中， 而工作流接口分布的工作流管理系统结构，所有计算机上的活动执行由一个工作流引擎来 第1 3 页 国防科学技术大学研究生院学位论文 控制。而对于由多个工作流引擎协作执行一个过程实例这种情况，被控制的过程实例的控制 数据必须是这些不同的工作流引擎都可以访问到的。控制数据可以集中存放在一个主机上 作为一个共享资源使用，也可以将它分布到不同的工作流引擎中。在将控制数据分布到不同 的环境中时，必须定义一套机制来保证这些控制数据之间的一致性。有关分布数据的一致性 问题是多数据库管理系统中最常见的维护问题，在具体实施时，用户可以根据实际需要采用 不同的解决方案。 2 2 2 分布式工作流系统的底层基础结构 不同的硬件平台、操作系统、数据库、网络协议等并存于同一个系统中，这就是分布 式计算中常说的异构性问题。比如，一个典型的企业内部网络存在有大型主机、u n i x 工作 站和p c 机，各种机器所采用的操作系统和网络通讯协议也是千差万别的。这就阻碍了应 用系统之间实现良好的互操作的实现。因此采用一个开放的标准是解决此类问题的关键。 比较典型的基础结构有远程过程调用r p c 、面向对象的分布式计算环境c o r b a 、基于 t c p i p 的w 船、各类消息传递系统以及代理系统等。 集中式模式 图2 6 分布工作流引擎与应用结构 分布式樟式 第1 4 页 国防科学技术大学研究生院学位论文 2 3 分布式工作流模型 工作流建模就是将一系列的活动，活动之间的关系按照事务的需求定义出来，并对相 应的活动安排好起止日期，活动人员资源等然后将此模型加载到工作流引擎中，通过工作 流引擎将任务信息在合适的时间发送到合适的人员。2 3 1 分布式工作流模型 许多标准组织为了一致化业务流程定义的描述，从而解决不同应用系统间业务流程互 通的问题，都着手制定业务流程定义语言，比如： w s f l x p d l w p d l w s c i x l a n g 其中的x p d l 是w f m c 所发布的标准，b p m l 是b p m i 组织发布的。w f 和b p m i 早在2 0 0 2 年就宣布将合作制定业务流程和工作流标准，既采用b p m l 来描述工作流过程，同时采用 x p d l 所定义的工作流模型。 工作流模型有层次支撑模型和核心模型。支撑模型主要包括组织模型，资源模型，权 限模型和时间模型：核心模型则是以过程模型为中心，另外还包含数据模型和应用模型。 支撑模型是任何一个工作流模型所必须的，但是同时他们又经常与企业中其它应用系统相 关联，可以奖他们分为独立的一类。工作流模型定义的好坏，特别是过程模型定义的好坏， 直接影响到工作流引擎的路由调度，状态转换，角色解析和资源调度等方面，从而影响到 工作流系统的效率。 2 3 2 分布式工作流的核心模型 过程模型作为工作流模型的核心，是评价一个工作流引擎好坏的主要标准之一，过 程模型对支撑模型的依赖关系如：时间管理，资源调度，访问控制和角色解析这些也都是 工作流建模的核心部分。过程模型的直接体现就是我们常看到的活动以及活动之间的关系 的反应。 过程模型：作为工作流模型核心的过程模型由流程( p r o c e s s ) ，活动( a c t i v i t y ) 和迁移( t r a n s i t i o n ) 三部分组成。流程是工作流模型的基本概念，是能够实例化 运转的基本单元。流程有活动和活动间的依赖关系也就是迁移组成，而活动又可 以分化成子流程：迁移支持分裂，合并，循环，跳过以及反馈等。 资源模型：用于描述活动执行所需要配备的各种支撑条件，如机器，设备等信息， 第1 5 页 国防科学技术大学研究生院学位论文 此外流程等工作流实体也可归为资源模型的实体范围。资源模乐笞亨墓蚓业_ 广 馥鞫劁翌犁叟兰掣& 娥。 蓥候无法确；曾赫! 鞭列轩鲤静酾野怕朝r 蝣酢拍u 裥鼗醚黔塑蓦礴滞伟掰鞭： 碥际随黼篓蠹黼辫烈列霸掣；d 倍嘲；务焉年动榷诺琵辅茹羚群嚣，补豁型 堪嘎喊测圜嘲哪甚2 _ j ； 疆魁嘴； 薹驰丽鲫”? 曜e 如嘲彭萤班县臻戮笋曼雕捡蓟引擎负责从满足条件的用户集中选取一个或者多个用户把任务 指派给他或他们，这些用户负责完成该任务。主动推又可以分为开放式( o p e n ) 和封闭式 ( c l o s e ) ，开放式允许用户或者是有某种权限的角色按照某种条件选择一个代替者，然后 把任务转寄给他，这一策略容易在用户间产生推委现象。封闭式则规定在引擎把任务指派 给某个具体用户时，不允许该用户再把任务转寄给他人。 被动拉是基于每个可能执行人都有较大的工作积极性的前提下，任务对可能执行人集 合内的每个可能执行人都是开放的，每个潜在执行人都可以公平的竞争任务：同时如果任 何人想要执行任务，必须先向系统申请执行该任务，按照一定的步骤系统同意后就可以获 得该任务。 3 5 工作流引擎与工作流任务管理 工作流模型包括了描述一个能够由工作流执行服务软件系统执行的过程所需要的所 有信息。这些信息包括过程的开始和完成条件、构成过程的活动以及进行活动间导航的规 则、用户所需完成的任务、可能被调用的应用、工作流引擎的引用关系、以及所有与工作 里堕型兰垫查盔兰竺窒垦望二兰垦兰圣兰= = = = = ：= 一适合用于支持集中式工作流管理系统，另外三种适合于分布式工作流管理系统。 基于主机方式的模型( h o s tb a s e dm o d e l ) ： 这种方式适合集中的情况。此时，客户 端应用程序、任务表管理器、任务表和工作流引擎都在中央的主服务器上，用户通过 终端获取任务表。 期毡眦瑚摸型基刊椁姗防i 潍基于屯子由p 蚪力瑚! 麴铷鼎旧埘聃 樾!趔倘彰矧嬲 图3 3 四种任务管理器的实现方法 基于共享文件方式的模型( s h a r e df i l s t o r em o d e l ) ：在这种情况下，客户端应用程序 和任务表管理器位于用户的工作站上，而工作流引擎位于中央服务器上，任务表位于 一个客户应用和工作流引擎都能访问到的共享文件系统中。 电子邮件模型( e 1 e c t r o n i cm a i lm o d e l ) ：客户应用和任务表管理器位于用户的工作 站上，工作流引擎位于中央主机上。所有通讯都使用电子邮件。此时任务表一般位于 客户端。 过程调用或消息传递模型( p r o c e d u r ec a l lo rm e s s a g ep a s s i n gm o d e l ) ：客户应用 程序和任务表管理器位于用户的工作站上，任务表和工作流引擎位于服务器端。用户 通过r p c ( 远程过程调用) 或者其他的消息传递机制来获取任务表。 一个工作流任务表管理器可能与多个不同的工作流引擎和工作流执行服务进行交互，这些 不同工作流引擎和工作流执行服务可能采取的是完全不同的实施方式。因此，连接工作流 第2 2 页 国防科学技术大学研究生院学位论文 引擎与工作流客户应用之间的接口定义必须具有足够的柔性，以能够为实现不同工作流日 擎和应用程序之间交互提供支持。 3 6 工作流引擎与工作流执行服务 工作流执行服务是工作流管理系统的核心，实际上它是企业经营过程的任务调度器， 并且还在某种程度上是企业资源分配器。在采用工作流管理系统支持其经营过程运行的企 业，工作流执行服务可以看成是企业的业务操作系统。企业的业务过程在它的管理、监控 和调度下运行，因此工作流执行服务系统的性能和可靠性就直接决定企业经营过程的运行 效率和安全性。工作流执行服务由一个或多个工作流引擎组成，它提供了过程实例执行的 运行环境，主要完成以下功能： 一实例化及执行过程模型：解释企业经营过程的过程定义，根据过程执行需要的初 始条件和执行参数生成过程实例，运行过程实例并管理其运行过程。这里需要指出的是一 个过程模型实际是企业经营过程的个模板，它可以被执行多次，也可以有多个有关这个 过程模型的实例在同时运行。如订单处理过程，每当来了一个新的订单时，它都启动一个 新的工作流流程，只不过每个流程处理的订单不同而已。因此，运行多个订单处理过程模 型的实例意味着有多个订单在被处理。 二为过程和活动的执行进行导航：根据过程定义和工作流相关数据，为过程实例的 运行进行导航，如果根据过程的进入和退出的条件启动和终止个过程实例；根据活动之 间的关联和活动的执行条件，决定并行或串行执行后继活动；给用户提供需要操作的工作 流任务项信息：或者根据所需激活的应用程序信息启动相应的应用程序等等。 三与外部资源交互完成各项活动：工作流执行服务通过两个途径完成与外部资源和 用户交互来完成各项活动：客户应用接口和直接调用应用接口方式。对于客户应用方式， 工作流引擎通过任务项列表管理器对应用的执行进行管理。任务项列表管理器提供任务项 列表供用户进行选择，并记录监督工作项的完成情况。由用户完成从任务项列表管理器提 供的任务项列表中选择相应的任务项，并在需要的时候调用应用工具完成相应任务的执 行，在任务执行完成后，用户需要修改相关任务项的状态，如置完成标志，供任务项列表 管理器使用。这些通过任务项列表管理器分发并管理的需要用户操作的活动对应于工作流 管理系统中用户手工完成的活动，如在完成对一个产品招标书的评审后，由业务员向提供 商发出通知，并与提供商签定供货合同。对于直接由工作流引擎启动的活动，由工作流引 擎直接调用相应的应用来完成，这些自动执行的应用同样需要将合适的预先定义好的应用 执行完成情况反馈给工作流引擎。工作流引擎自动调用的应用主要是针对基于服务器的无 需用户参与的应用，即自动化活动。如在某个设计图纸完成电子会签后，自动进行版本发 布并将图纸归档。 四维护工作流控制数据和工作流相关数据：工作流在执行过程中要维护不同过程和 第2 3 页 国防科学技术大学研究生院学位论文 活动 实例的内部状态信息，以及用于协调和恢复的各种检查数据和恢复重起信息，还包 括用户传送的必要的相关数据。 在分布式工作流执行服务中，一般由多个工作流引擎协调工作来推动工作流实例的执 行。每个工作流负责控制和管理一个过程中的一部分活动，使用相关的资源和应用工具来 完成这些活动的执行。不同的工作流引擎之间进行分工和协作，在一个工作流引擎完成了 其负责的一部分活动后，需要将相应的完成信息传递给其他工作流引擎。这些不同的工作 流引擎之间的协作需要良好的底层支持系统( 如可靠的消息系统) 的支持。首先这种执行 服务方式需要有共同的命名方式和管理范围，便于维持过程定义和用户应用名称的一致 性。分布式工作流系统采用特定的协议来同步各工作流引擎，并传递相应的控制消息。不 同的工作流执行服务中定义的协议通常是不同的，它们大部分都是厂家自己定义的。在选 用不同的工作流系统进行协同工作时，需要在各工作流引擎之间提供一个标准的接口或者 格式来进行这些不同协议的转换。所提供的标准接口和格式应该包括以下几个方面内容： 一个共同的命名机制 支持共同的过程定义对象和属性 能够传递相关的工作流相关数据，并控制过程实例的生成 能够在异构的工作流引擎间传递过程、子过程及活动信息 支持共同的管理职能 3 7 小结 本章首先阐述了工作流引擎模块及其主要功能。说明引擎是工作流平台系统中为业务 流程实例和任务实例提供运行环境的软件服务，是工作流系统的核心部分。然后介绍四种 任务管理器的实现模型：基于主机方式的模型、基于共享文件方式的模型、电子邮件模型 和过程调用或消息传递模型。最后介绍了，工作流执行服务由一个或多个工作流引擎组成， 提供了过程实例执行的运行环境。工作流执行服务是工作流管理系统的核心，实际上是企 业经营过程的任务调度器。 第2 4 页 = 里些垒垒垒垒兰兰垒堑鲨兰兰圣一 第四章工作流中的负载平衡技术 本章主要在上一章讨论的工作流引擎的基础上，讨论负载平衡在工作流中应用。首先 本章简述了负载平衡技术以及常用的三种负载平衡调度策略。然后在这几种调度策略的基 础上，我们针对工作流系统中的负载平衡技术，提出负载平衡的调度模型和负载指数调 度算法。 4 1 负载平衡技术 如何采取有效的调度策略来平衡多结点( 机) 的负载，从而提高整个系统资源的利用率， 已成为当前研究热点。在下面的讨论中，我们假定每个结点上的任务是动态产生的，每个结 点的负载大小是动态变化的，因而不考虑静态负载平衡调度方法，只考虑动态负载平衡调 度策略。般说来，动态负载平衡调度可分为集中式调度和分布式调度两大类，前者是由一 个调度服务器负责搜集系统负载信息，并由它来决定负载平衡调度方案。集中式调度的主 要优点在于实现比较简单，但在结点数较多的大规模并行分布系统中，由于各结点与调度 服务器的通讯成为瓶颈，所以调度开销比较大。 可以这么认为，负载平衡是分布式作业调度系统的一种实现。负载平衡调度器作为请 求分配的控制者，要根据集群节点的当前处理能力，采用集中或分布策略对服务请求进行 调配，并且在每个服务请求的生命周期里监控各个节点的有效状态。一般的说，负载平衡 调度器对请求的调度具备以下的特征： 服务请求必须是可管理的 请求的分配对用户是透明的 最好能够提供异构系统的支持 能够依据集群节点的资源情况进行动态分配和调整 负载平衡调度器在集群的各个服务节点中分配工作负载。可以静态预先设置或根据当 前的服务器状态来决定负载分发到哪个特定的节点，节点在集群内部可以互相连接，但它 们必须与负载平衡调度器直接或间接相连。 如图4 1 所示，负载平衡调度器向l o a dm o n i t o r 询问w o r kn o d e 的负载或如图4 2 所 示，l o a d n i t o r 将负载主动发送给负载平衡调度器。负载平衡调度器接收到负载反馈后， 根据系统整体的负载情况分发请求，将负载控制消息发送给l o a dm o n i t o r ，并设置当前 w o r k d e 的负载状况。l o a dm o n i t o r 可以对不同类型的资源进行监测，用户只需要定义 不同的对象即可。在对象实现里，用户可以采用不同的度量技术和策略获取给定资源的负 载，通过