（计算机软件与理论专业论文）面向复杂约束制约应用的业务流管理与定制技术研究.pdf

中文摘要 中文摘要 进入2 0 世纪9 0 年代，随着计算机的普及、网络的延伸，信息资源越来越 表现出异构、分布、松散耦合的特点，分布式处理技术也日益成熟，业务流的 研究进入了一个崭新的阶段。在业务流的应用中，受到各个业务的时间、环境、 活动之间的相互关系影响，需要建立一个约束制约机制，这主要体现在业务流 的定制与执行上，这是当前业务流研究的一个重点问题。 论文首先介绍了国内外对业务流的研究现状，并分析总结了面向复杂约束 制约应用的业务流管理与定制的特点；然后详细研究了业务流管理技术，包括 业务流程定制、业务分解、业务分配执行和业务执行情况监控等；重点讨论了 基于j 2 e e 技术的业务流定制与执行，采用a j a x 技术实现了业务流程的定制， 提出了一套业务流引擎并行协作的实现方案，并用一个业务流定制与执行的原 型系统来验证业务流定制与执行技术；论文的最后指出了今后进一步的研究方 向。 本文首先从理论研究出发，然后通过原型系统进行验证，对于业务流管理 与定制技术的研究具有一定的参考意义。 关键字 业务流复杂约束制约定制与执行 a b s t r a c t a b s t r a c t e n t e r i n g t h e19 9 0 s ，w i t ht h e c o m p u t e r sp o p u l a r i z a t i o n , t h e n e t w o r k s p r o l o n g a t i o n , t h ei n f o r m a t i o nr e s o u r c eh a sb e c o m em o r ea n dm o r eh e t e r o g e n e o u s ， d i s t r i b u t e d ，a n dl a x - c o u p l e d ，t h ed i s t r i b u t e dm a n a g e m e n tt e t ! h n o l o g yb e c o m e sm o r e a n dm o r em a t u r e ，a n dt h er e s e a r c ho ft h eb u s i n e s s f l o we n t e r san e ws t e p i nt h e a p p l i c a t i o no f t h eb u s i n e s s f l o w , b e i n ga f f e c t e db yt h ei n t e r r e l a t i o no fe a c hb u s i n e s s s t i m e ，e n v i r o n m e n t ，a n da c t i o n , w es h o u l db u i l dar e s t r a i nc o n t r o lm e c h a n i s m , w h i c h m a i n l ye m b o d i e si nt h ec u s t o m i z a t i o na n de x e c u t i o no f t h eb u s i n e s s - n o w lw h i c hi sa c u r r e n tl r n p o r t a n tp r o b l e mo ft h eb u s i n e s s f l o wr e s e a r c h t h ed i s s e r t a t i o nf i r s t l yi n t r o d u c e s t h er e s e a r c hs i t u a t i o no ft h eb u s i n e s s f l o w h o m ea n da b r o a d 。a n a l y z e sa n ds u m m a r i z e st h ec h a r a c t e r i s t i c sf o r t h eb u s i n e s s - f l o w s m a n a g e m e n ta n dc u s t o m i z a t i o no r i e n t i n gc o m p l e xr e s t r a i n c o n t r o la p p l i c a t i o n s e c o n d l y , r e s e a r c h e st h eb u s i n e s s - f l o w sm a n a g e m e n tt e c h n o l o g y , i n c l u d i n g t h e b u s i n e s s - f l o w sc u s t o m i z a t i o n , t h eb u s i n e s s sd e c o m p o s i t i o n , t h eb u s i n e s s s d i s t r i b u t i o na n de x e c u t i o na n dt h em o n i t o ro ft h eb u s i n e s s se x e c u t i o n a n dt h e n , d i s c u s s e st h eb u s i n e s s f l o w sc u s t o m i z a t i o na n de x e c u t i o nb a s e do nt h ej 2 e e t e c h n o l o g y , i m p l e m e n t st h eb u s i n e s s f l o w sc u s t o m i z a t i o nu s i n gt h et e c h n o l o g yo f a j a x , p u t sf o r w a r dai m p l e m e n t a t i o ns c h e m eo ft h eb u s i n e s s f l o we n g i n ep a r a l l e l i s m c o o p e r a t i o n , a n d v a l i d a t e st h eb u s i n e s s n o w sc u s t o m i z a t i o na n de x e c u t i o n t e c h n o l o g yu s i n g ap r o t o t y p es y s t e m a tl a s t ，t h ed i s s e r t a t i o ng i v e sas u m m a r ya n da p r o s p e c t t h i sd i s s e r t a t i o nf i r s ts t a r t sf r o mt h et h e o r yr e s e a r c h , a n dt h e nv a l i d a t e si tw i t h t h e p r o t o t y p es y s t e m , s o h a st h er e f e r e n c ev a l u ef o rt h er e s e a r c ho ft h e b u s i n e s s - f l o w sm a n a g e m e n ta n dc u s t o m i z a t i o nt e c h n o l o g y k e yw o r d s b u s i n e s s f l o w , c o m p l e xr e s t r a i nc o n t r o lc u s t o m i z a t i o na n de x e c u t i o n 1 i i 目录 图目录 图1 1a c t i o n w o r k sm e t r o 6 图2 1 基于业务流程图的时间约束信息表示方法示例图1 1 图2 2 职责分离约束状态图15 图2 3g o o g l e 地图17 图2 4 基于目标的业务分解示例图2 0 图2 5 并联关系示意图2 1 图2 6 串联关系示意图2 2 图2 7 与分叉关系示意图2 2 图2 8 或分叉关系示意图2 3 图2 9 与合并关系示意图2 3 图2 1 0 或合并关系示意图2 4 图2 1 1 迭代关系示意图2 4 图2 1 2 业务分解示例图2 5 图2 1 3 “推力模式示例图2 6 图2 1 4 执行者确认模式示例图2 7 目录 图2 1 5 执行者竞争模式示例图2 8 图2 16 “拉一模式示例图2 8 图2 17w i d e 主动规则支持模块结构图。3 2 图3 1 业务流管理系统三层体系结构图3 7 图3 2 模块之间的相互关系示意图4 3 图3 3 业务流执行服务实现方案图4 5 图3 4 业务流执行服务的处理过程4 7 图4 1 业务流定制和执行过程图5 3 图4 2 业务流程定制工具图5 4 图4 3 串行关系图5 6 图4 4 前导关系图5 7 图4 5 并行关系图5 8 图4 6 分支关系图。6 0 图4 7 定制的业务流实例图6 4 i x 目录 表目录 表2 1 职责分离约束属性表l6 表2 2 业务流程存储方式表2 0 表2 3 子业务关系表。2 5 表3 1 用户请求及对应的业务流执行服务表4 5 表4 1 原型系统业务模块中英文对照表5 4 表4 2x m l 文件标签表5 5 表4 3 解析文件r e s u l t 表6 1 表4 4 解析文件r e s u l t 实例表6 2 x 南开大学学位论文版权使用授权书 本人完全了解南开大学关于收集、保存、使用学位论文的规定， 同意如下各项内容：按照学校要求提交学位论文的印刷本和电子版 本；学校有权保存学位论文的印刷本和电子版，并采用影印、缩印、 扫描、数字化或其它手段保存论文；学校有权提供目录检索以及提供 本学位论文全文或者部分的阅览服务；学校有权按有关规定向国家有 关部门或者机构送交论文的复印件和电子版；在不以赢利为目的的前 提下，学校可以适当复制论文的部分或全部内容用于学术活动。 学位论文作者签名：彭娠 2 0 0 扩年，月2 f 日 经指导教师同意，本学位论文属于保密，在年解密后适用 本授权书。 指导教师签名：学位论文作者签名： 解密时间；年月日 各密级的最长保密年限及书写格式规定如下： 南开大学学位论文原创性声明 本人郑重声明：所呈交的学位论文，是本人在导师指导下，进行 研究工作所取得的成果。除文中已经注明引用的内容外，本学位论文 的研究成果不包含任何他人创作的、已公开发表或者没有公开发表的 作品的内容。对本论文所涉及的研究工作做出贡献的其他个人和集 体，均已在文中以明确方式标明。本学位论文原创性声明的法律责任 由本人承担。 学位论文作者签名：彭振 2 d 。扩年t 月力扩日 第一章绪论 第一章绪论 第一节业务流概述 8 0 年代初期，一些公司、企业建立了自己专用的或者可商品化的表单传递 应用系统( f o r m s r o u t i n ga p p l i c a t i o n s ) ，通常运行在大型机或小型机上，用于实 现日常表单处理的电子化与自动化。这种系统可以看成是现代业务流管理系统 的一个雏型。8 0 年代中期，f i l e n e t 和v i e ws t a r 等公司把图像扫描、复合文档、 结构化路由( s t r u c t u r e dr o u t i n g ) 、实例跟踪、关键字索引以及光盘存储等功能 结合在一起，形成了一种全过程支持某些业务流程的集成化软件( 包) ，这便 是早期的业务流管理系统。进入2 0 世纪9 0 年代，随着计算机的普及、网络的延 伸，信息资源越来越表现出异构、分布、松散耦合的特点，分布式处理技术 ( c o r b a ，w w w ，o l e ，j a v a ) 也日益成剥1 1 。这些都说明：集中式信息处 理的时代已经过去，实现大规模的异构分布式执行环境，使得相互关联的任务 能够高效运转并接受密切监控已成为一种趋势。在这个大环境下，业务流管理 与定制技术也进入了一个崭新的发展阶段，使得人们从更深的层次、更广的领 域上对业务流展开了研究。 1 1 1 业务流介绍 1 9 9 3 年，工作流管理联盟( w o r k f l o wm a n a g e m e n tc o a l i t i o n ) 成立，标志着 业务流技术在计算机应用研究领域之中被明确地划分出了自己的一席之地， 相 应的概念与术语也得到了人们的承认。在全球范围内，对业务流的技术研究以 及相关的产品开发进入了更为繁荣的阶段，更多更新的技术被集成进来，文件 管理系统、数据库、电子邮件、移动式计算、i n t e m e t 服务等都已被容纳到业务 流管理系统之中。市场上业务流产品比较丰富，多家供应商纷纷看好这块渐趋 热点的i t 市场。 业务流是通过计算机软件进行定义、执行并监控的经营过程，而这种计算 机软件就是业务流管理系统。这个定义区别了业务流与一般的工作流程：前者 需要借助计算机软件来完成，并完全在软件系统的控制之下；而后者则没有这 第一章绪论 种约束，其中的某些步骤可能也需要用到计算机，但这只不过是局部的计算机 应用，整个过程是不在计算机控制之下的。 业务流模型是对业务流的抽象表示，也就是对经营过程的抽象表示。由于 业务流需要在计算机环境下运行，因此建立相应的业务流模型就是必不可少的。 业务流模型应该能完整地提出支持业务流定义的概念，为建模用户提供业务流 定义所需要的组件或元素。理想的业务流模型能够清楚地定义任意情况下的业 务流，能够适应用户在建模过程中所提出的各种要求。由于业务流必须首先描 述清楚一个经营过程是怎样进行的，因此，许多业务流模型都是从过程定义入 手，比如流程图、状态图、活动网络图等等。这一类基于有向图模型的优点是 比较直观、容易理解。一般情况下，图中的节点表示过程中的活动或者状态， 而有向弧则表示节点间的时序依赖关系。不少业务流产品正是采用了这种模型， 但其缺点是比较简单，不能处理复杂的过程逻辑，缺乏柔性。 在确定了业务流模型的基础上，如何实现整个系统预定的各项功能就成为 设计人员所必须考虑的问题。确定一个业务流系统的实现方案，一般包括以下 两个重要方面：( 1 ) 首先是选择系统所基于的底层通信基础结构。这一基础结构 关系到系统中的各个组成部分之间以怎样的方式来进行互操作，这是分布式应 用赖以存在的基础。比较典型的结构包括远程过程调用r p c 、面向对象的分布计 算环境c o r b a 、基于t c p i p 的w e b 、各类消息传递系统以及代理系统等。( 2 ) 要 确定系统各组成部分之间的协作过程。从模型的提交、运转到结束，这一过程 必然会涉及到多个软件模块间的协作，那么这些具有不同功能且相互独立的模 块之间在所确定的底层通信基础结构上的互操作过程就是实现业务流运转的过 程。这部分工作主要包括确定接口定义、数据维护方式、操作处理过程等。 事务的概念来自于数据库研究领域，用以解决数据的并发访问和出错恢复 问题。事实上，业务流也可以看成是一系列有序操作的集合，只不过这些操作 的对象具有更广的内涵，并不仅仅限于数据库中的数据。因此，业务流也同样 具有事务特性。 1 1 2 国内外对业务流技术的研究 业务流模型u 】一直是国内外研究机构研究的重点，下面列举几个典型的业务 流模型：( 1 ) 基于对话的业务流模型，这种业务流模型是从客户方与服务方这两 2 第一章绪论 个角色之间的语言行为交互上对业务流过程进行定义的。基于语言行为理论的 业务流模型是由一系列闭合的业务流环相互连接而成的，每个业务流环都被4 个 语言行为( s p e e c ha c t s ) 分为4 个阶段，包括需求阶段、协商阶段、执行阶段和 满意阶段。a c t i o nt e c h n o l o g i e s 的业务流产品a c t i o n f l o w 就采用了这种业务流模 型。( 2 ) 活动树( a c t i v i t yt r e e ) 模型，它是以一个树状结构来表达业务流过程的。 从根节点开始，过程被逐层地分解为由各级子节点所代表的活动，而活动间的 执行顺序则是由左至右逐个分支地进行。( 3 ) b r o k e r s e r v i c e s 模型，即代理服务 模型，它定义了较为精确与严格的形式化语义，用代理来表示业务流执行过程 中的处理实体，用服务来表示所要执行的活动，代理的行为是采用e c a ( e v e n t c o n d i t i o n a c t i o n ) 规则来描述的。 业务流的最终实现还是要落实到业务流管理系统上，因此业务流管理系统 也是各大高校和研究机构的研究重点。 o r b w o r k 2 】是美国g e o r g i a 大学计算机系m e t e o r ( m a n a g i n ge n d - t o - e n d o p e r a t i o n s ) 研究项目所开发出的一套业务流管理原型系统，它是基于c o r b a 的 完全分布的业务流执行系统，以c o r b a 产品o r b i x 作为底层的通信支持，并使用 c o r b a 来实现系统的互操作和数据源的封装。在o r b w o r k 中，系统的所有组成 部分，包括任务管理器、任务( 或经过封装的已经存在的应用程序) 、监控单 元和恢复机制都是c o r b a 对象，它们之间通过c o r b a 的i d l 调用进行协作。同 时，o r b w o r k 还为用户提供了w e b 界面以及w e b 与c o r b a 之间的接口。以 c o r b a 作为业务流系统实现的底层基础有许多优点，比如对象请求代理( o i 强) 机制、标准的接口定义语言( i d l ) 、面向对象等等。这些优点都将使c o r b a 成为用户实现企业级业务流解决方案的一种可能的选择。 w e b w o r k t 3 】与o r b w o r k - - 样，也是m e t e o r 项目中的一部分。与o r b w o r k 不同的是，w e b w o r k 是完全基于w e b 技术实现的业务流系统。m e t e o r 的研究 人员考虑到企业可能由于价格等原因而不愿意去购买c o r b a 产品，但是大多数 企业都有自己的w e b 服务器，或者可以连接到某个w e b 服务器上，因此开发出了 一套基于w e b 的业务流管理系统。w e b 浏览器为用户提供了一个通用、友好的界 面，而且它可以很容易地、不附加任何多余代价地布置在多个计算平台上。 i b ma l m a d e n 研究中心所进行的研究项目e x o t i c a l 4 1 在业务流分布执行方面 提出了一种能够完全分布的执行模型，它通过永久消息( p e r s i s t e n tm e s s a g e s ) 的 方式来保存业务流相关执行信息，使得每一个执行节点都相互独立，业务流过 第一章绪论 程的执行不以某一个节点为中心，完全实现了分布。这种方式大大提高了系统 的可靠性、可扩展性以及柔性。e x o t i c a 的这种设计方案是建立在底层的消息传 递系统之上的，类似的产品有d e c 的m e s s a g e q ，n o v e l l 的t u x e d o q ，i b m 的m q s e r i e s 。这些消息系统为上层的应用隐藏了复杂的通信实现代码，并且屏蔽了操 作平台、网络协议的异构性，通过提供a p i 函数来提供各项消息服务。这些产品 的特点很适合用来连接分布式应用，实现业务流管理的功能。 瑞士苏黎士大学计算机系的研究人员提出了一种基于事件的业务流执行服 务中间件平台体系结构，称为e v e 5 】( e v e n te n g i n e ) ，用以集成业务流执行过程 中松散耦合的分布式功能组件( 包括各类企业应用) 。在e v e 体系结构中，业务 流的执行是由分布在网络上的代理( b r o k e r ) 通过响应由e v e i 艮务器检测到的事 件来完成的。同时，代理在提供服务的过程中又会产生新的事件。每一个代理 代表了一种活动任务的处理实体，它的行为也是由e c a 规则来定义的。不同的 代理分别用于提供用户接口、组织管理、外部应用集成以及系统组件等功能。 e v e 服务器是整个e v e 体系的核心。e v ej 艮务器能够直接同本地的代理及远程的 e v e j 艮务器相互通信，而代理则只能通过e v e 适配器( e v e a d a p t e r ) 与本地的e v e 服务器通信。因此，不同代理之间的交互是通过把事件发送给本地e v e 服务器， 进而由本地服务器再发送给本地的相应代理或者再通过远程e v e 服务器发送给 远程的代理来完成的。从e v e 系统的设计思路来看，它也属于一种完全分布的执 行方式，因而很容易克服服务方完全集中于一点而带来的诸多不利，如系统吞 吐量的瓶颈、系统的可靠性问题等。当然，也带来了一些复杂的问题，复合事 件的检测就是一个例子。 d a r t f l o w 6 是达特茅斯大学计算机系设计开发的一种基于可移动代理的业 务流系统。所谓“可移动代理 ，是指一段可以在自身的控制下由异构网络系 统中的一台机器转移到另外一台机器上运行的程序。也就是说，可移动代理能 够在执行到某一点时挂起自身程序，将代码传递到另外的网络节点上继续运行。 可移动代理具有许多优点，比如在一定条件下能够减少网络流量、适合于移动 用户、有利于数据集成、具有并行机制等，因此很适合于业务流管理系统的构 建：企业的每一个经营过程的实例可以由一个移动代理来处理，代理在预先定 义好的步骤下在分布的网络节点上执行，当代理移动时，它携带着过程所需的 执行代码与数据，无需每一步都通过中央的数据库服务器来交换数据。但是， 可移动代理对业务流监控系统提出了更高的要求，加重了监控的负担。 4 第一苹绪论 为了研究业务流的事务性，人们首先研究了在数据库事务模型的基础上所 提出的许多高级事务模型【l 】( a d v a n c e dt r a n s a c t i o n ) ，包括嵌套事务模型、多层 事务模型、s a g a s 、分支汇合事务模型、柔性事务模型、a c t a 等。高级事务模 型通常把一系列的操作分组成为层次化的结构，以便适应不同性质的实际问题， 因此又被称为扩展事务模型。 由于高级事务模型在解决长时间事务方面仍有很多局限性，人们把注意力 由专门的数据库事务扩展到了业务流这一范围。德i 垂i s t u t t g a r t 大学的c o n t r a c t s l i j 研究项目提出了自己的高级数据模型和高级并发控制机制，已经具备了一定的 业务流描述能力。从解决问题的思路来看，c o n t r a c t s 模型跳出了原有的高级事 务模型的局限。他们认为，扩展原有的事务模型并不能解决问题，因为长时间 的计算过程要比一个具有a c i d 特性的事务复杂得多，数量上的变化将导致事物 本质的变化，宏观与微观的差距将使它们的一致性问题变得各具特色，绝不能 一概而论。 a m i ts h e t h 在对高级事务模型进行研究的基础上提出了事务业务流的概 念。他认为，许多高级事务模型的执行结构都很有限，高级事务模型所预先定 义的许多属性对于业务流应用而言可能并不必要；而且在业务流的执行过程中， 有些参与执行的系统可能并不支持这些事务模型；另外，事务模型所注重的是 保护数据的一致性，对于执行不同任务的、相互独立的系统之间的协调则并不 擅长。a m i ts h e t h 完全从业务流的角度提出了任务的结构化定义以及基于任务间 依赖关系的业务流定义，还就系统的实现方法提出了一些意见。 在以上研究的基础上，人们开发出了一大批优秀的业务流系统产品。根据 业务流引擎采用的任务项传递机制的不同，可以将业务流管理系统分为四类1 7 j ： ( 1 ) 基于文件的业务流系统 这类系统以共享文件的方式来完成任务项传递，其产品是产生最早、发展 最成熟、最具多样性的，通常包含有c l i e n t s e r v e r 模式的图像、文档与数据库管 理系统。虽然比较成熟，但是这类产品的可扩展性和维护都比较困难。代表产 品有f i l e n e t 的v i s u a lw o r k f l o w 、i b m 的f l o w m a r k 和i n c o n c e r t 的i n c o n c e r t 等。 ( 2 ) 基于消息的业务流系统 这类系统使用电子邮件来完成过程实例执行过程中消息的传递、数据的分 发与事件的通知。低端的系统所使用的经常就是此种方法，它可以充分发挥电 子邮件系统在广域环境下的数据分发功能，整个系统将运行于一种松散耦合的 第一章绪论 模式下，在对实时性要求不高的情况下经常使用。这种娄型的产品一般都提供 与一种或多种电子邮件系统的集成接口代表产品有- n o v e n 与f i l e n e t 合作开发的 e n s e m b l e 、j e t f o r m 公司的i n t e m p o 和k 啪1 e 公司的k e y f l o w 等。 ( 3 ) 基于w e b 的业务流系统 这类系统通过w w w 来实现任务的协作，其产品起步较晚( 在9 5 年以后) 。 但是发展迅速。具有跨平台性等优点，其市场前景十分看好。许多供应商纷纷 改进原有产品或开发新产品以增加对w e b 的支持。代表产品有a c t i o n t e c h n o l o g i e s 公司的a c t i o n w o r k s m e t r o 和u l t i m u s 公司的u h i m u 3 等 下圈是a c t i o n w o r k s m e t m 在股票交易上的应用。 ( 4 ) 群件与套件系统 虽然这一类产品与上面介绍的三种产品在任务传递方式上有报大程度的重 叠，但是在这里却有必妥把它们单独划分成一共。因为这一类产品都需要依聩 于自己系统的应用基础结构，包括消息传递、目录服务、安全管理、数据库与 文档管理服务等，它们本身就构成了一个完整的应用开发环境，方便7 我们对 其进行第二次开发。但是与其他系统的整合却非常不便。代表产品 n b 肿l s 第一章绪论 公司的l o t u sn o t e s 、m i c r o s o f t 公司的o f f i c e 与e x c h a n g e 和n o v e l l 公司的g r o u p w i s e 等。 纵观业务流软件产品的发展，我们可以把它总结为3 个阶段：第1 阶段， 主要为应用于某些特定领域的、相对独立的应用系统，比如图像、文档管理系 统；第2 阶段，主要表现为具有底层的通信基础结构、能够实现任务协作的应 用系统，比如具有消息传递功能的业务流系统；第3 阶段，具有图形用户界面 的过程定义工具、用户定义与任务执行完全分离的业务流系统，其体系结构基 本上符合工作流管理联盟所提出的标准结构。经历了这3 个阶段的发展，业务 流产品基本上确定了它在计算机应用软件市场上的独立位置。 第二节业务流管理技术研究概述 1 2 1 业务流管理技术介绍 业务流作为经营过程的实现技术能够反映出经营过程的如下几个问题： 经营过程是什么? 怎么做? 由谁来做? 做得怎么样? 其中，“经营过程是什么? ，也就是经营过程由哪些活动、任务组成， 实际上就是对业务流程进行定制，同时也包括了约束条件的建立过程和流程的 存储过程；“怎么做? ，也就是活动间的执行条件、规则以及所交互的信息， 实际上就是对业务进行分解执行的过程；“由谁来做? ，也就是组织角色的 定义，是人或者计算机应用程序，实际上就是将子业务分配到具有相应权限的 用户进行执行；“做得怎么样? 刀，实际上就是通过业务流管理系统对业务流 执行过程进行密切的监控。 这几个过程相互联系，互相作用，共同构成了业务流管理技术的主体。 1 2 2 面向复杂约束制约应用的业务流管理与定制特点 业务流定制是业务流管理技术的基础。也就是说，只有定制了业务流，才 7 第一章绪论 能将各个业务分配到若干个执行实体上执行并对执行情况进行监控。同时，我 们所遇到的一些应用都比较复杂，光靠模块之间简单的排列组合已经满足不了 我们的需求。这就要求我们在定制业务流时建立模块之间较为复杂的约束机制， 兼顾各个业务的时间、环境、活动之间的相互关系。因此，面向复杂约束制约 应用的业务流管理与定制有以下特点： ( 1 ) 定制后的业务模块之间的关系复杂多样。根据一般的应用需要，业务模 块之间的关系可以有串行、并行、分支、迭代等关系。定制后的业务流程中可 以只有一种关系，也可以有几种关系，它们之间还可能存在着嵌套。 ( 2 ) 业务模块之间的关系既可固定，也可不固定。由于时间因素和其他因素 的影响，一个模块必须在另一个模块的前面，这也就是所谓的前导和后继关系； 还有的模块之间不存在这种关系，谁先谁后都可以。 ( 3 ) 业务分配执行时需要考虑到执行实体的负载。由于业务模块之间的关系 比较复杂，所以我们必须要恰当地分配各个业务模块到执行实体上去执行，使 得整个业务流管理系统的性能达到最优。 第三节本文的组织 第一章介绍了业务流的概念，当前国内外对于业务流的研究情况，在此基 础上对业务流管理技术进行了介绍，并进一步分析了面向复杂约束制约应用的 业务流管理与定制的特点。 本文其他部分安排如下： 第二章，对业务流管理技术进行详细研究，包括业务流程定制、业务分解、 业务分配执行和执行情况监控等几个方面，并对相应的技术进行对比分析。 第三章，在第二章研究的基础上，以j 2 e e 技术为背景，详细研究了业务流 定制与执行的技术，包括业务解决方案、体系结构设计和技术实现等几个方面， 为原型系统的实现做好了铺垫。 第四章，在前面研究的基础上，基于展会管理系统实现了一个业务流定制 与执行的原型系统，对业务流程定制和业务流程执行的相关技术进行验证。 第五章，总结全文并提出进一步的研究方向。 第二章业务流管理技术研究 第二章业务流管理技术研究 2 1 1 约束条件的建立 第一节业务流程定制 一般情况下，系统能实现多个业务。因此，需要对各类业务都建立基础约 束条件，在符合约束条件【1 9 】的前提下对业务流程进行定制，从而保证了业务流 程是合理可行的。 根据实际需要建立以下几类约束条件： ( 1 ) 时间约束 时间约束( t c ：t i m ec o n s t r a i n t ) 分为活动开始时间约束( s t a r tt i m e c o n s t r a i n t ) 和活动结束时间约束( c o m p l e t et i m ec o n s t r a i n t ) 两类。在活动开始 时间约束中，t c 活动的开始执行时间不得迟于该时间约束指定的时刻。在活动 结束时间约束中，t c 活动的执行结束时间不得迟于该时间约束指定的时刻。 在业务流程管理中，时间约束包括如下规则： 业务流程( p r o c e s s ) 由一个活动( a c t i v i t y ) 组成，一个活动可以包含 多个子活动。时间约束用以限制活动执行的开始或( 和) 结束的时间， 因此时间约束是与某个活动绑定的，该活动称为“时间约束活动【s 】，( t c 活动：t i m ec o n s t r a i n ta c t i v i t y ) 。 时间约束中的时间只用相对时间来指定。相对时间基于某一参考点，该 参考点或者是t c 活动之前的兄弟活动的执行开始时刻、结束时刻，或 者是父活动的执行开始时刻。参考点相关的活动称为“参照活动【8 ”( r 活动：r e f e r e n c ea c t i v i t y ) 。 父活动的时间约束将作用于所有的子活动，因此作用在某一活动上的时 间约束可以有多个，验证时间约束的一致性时，约束性较强的时间约束 将具有较高的优先级。 时间约束违反后，将触发t c 活动中指定的超时异常处理( t i m e o u t e x c e p t i o nh a n d l i n g ) 活动，若异常处理失败，贝j j t c 活动执行事务失败， 9 第二章业务流管理技术研究 将触发事务补偿( t r a n s a c t i o nc o m p e n s a t i o n ) 活动。为防止死循环，异 常处理或事务补偿中的活动不能再绑定时间约束。 考虑到业务流程定制和存储的需要，我们给出以下两种时间约束表示方法： 一是基于x m l 的表示方法，二是基于业务流程图的表示方法。 基于x m l 的表示方法 采用基于x m l 的表示方法，时间约束信息符合以下s c h e m a 定义： 由以上定义可以看出，活动开始时间约束由“s c h e d u l e 元素表示，活动结 束时间约束由“c o m p l e t e b y 元素表示，若在某活动的子元素中出现这两个元素 中任意一个，则该活动为一个t c 活动。“r e l a t i v e t o 元素的“r e f 属性，取值 为该时间约束r 活动的名字。“r e l a t i v e t o 元素的“e n d ”属性，若取值为 “t r u e ，则时间约束中相对时间的参考点是r 活动的执行结束时刻；若取值为 “f a l s e ，则时间约束中相对时间的参考点是r 活动的执行开始时刻。 “d u r a t i o n ”属性，取值为一个“x p m h 表达式，表示一个时间段。时间约束的 “d u r a t i o n 属性表示了一时间段，它为s c h e m a 规范中定义的“t i m e d u r a t i o n 数 据类型。 基于业务流程图的表示方法 上述方法不够直观方便，故提出等效的基于业务流程图的表示方法，如下 图。 1 0 第二章业务流管理技术研究 | a c t i 、，i t ) ，a 上， a c t i v i t yb 1 l a c t i v i t yc ser t i m e 虚箭头，由t c 活动指向r 活动；s 表示该约束是一个活动 开始时间约束( 活动结束时间约束则用c 表示) ；e 表示参 考点是r 活动的执行结束时刻( 执行开始时刻则为空白) ； r t i m e 是一个相对时间表达式。 图2 1 基于业务流程图的时间约束信息表示方法示例图 当时间约束违反后，将触发与t c 活动绑定的超时异常处理活动。异常处理 活动同时间约束一样，是与某一活动绑定的，一个活动可以同多个异常处理活 动绑定a 如果活动未正常完成，则根据未正常完成的原因触发相应的异常。异 常处理活动由异常代码与具体处理活动组成，异常代码表明了触发异常的原因， 具体处理活动则表明了如何处理该异常。例如超时异常处理活动，是异常代码 为t i m e o u t 的异常处理活动。 ( 2 ) 活动和环境约束 该约束通过一个访问控制模型来实现，由定义期和运行期两个阶段构成， 可以表示为四元组 9 】。其中，p 、c s 与授权定义相关，c t 、 a t 与运行期访问控制相关。 p ( p o l i c y ) 代表针对每个任务的授权策略，它和企业的组织模型与过程 模型紧密联系。授权策略的定义分成五个部分，表示为p = ，各部分含义分别是：业务流定义b d - b 一2 1 ， 即业务流是任务版本组成的集合；任务类型定义t t d t 川，t t t t ； 用户角色映射u r a ：u _ 2 瞰r ，即用户映射成组织里的角色；任务 角色指派t r a ：t _ 2 r ，即任务最终分配给哪些角色去执行；任务许 第二章业务流管理技术研究 可指定t p a ：t _ 2 “o p ，即任务的执行需要获得对哪些类的对象的哪些 访问权限。其中，u 、g 、r 、b 、t 、c 、o p 分别表示用户、组、角色、 业务流、任务版本、数据类和对象访问操作。 c s ( c o n s t r a i n t ) 代表授权约束定义，在任务角色指派和任务许可指定 过程中都可以定义约束，它是业务规则的一种体现。 c t ( c o n t e x t ) 代表授权时刻的环境。用户开始执行具体活动的那一刻 标志着授权事务的开始，此时的环境称为授权环境，可以表示为c t = ( c u ，c g ，c r ，c a ，c t ，c b ，c o ，s o ，l o ) 。其中，c a 、c g 、c r 分别代 表当前用户、组和角色，这一般在用户登陆系统时就已经确定；c a 、c t 、 c b 分别代表当前正在执行的活动、活动对应的任务版本和任务版本所在 的业务流，如果任务是非流程任务，则c b 为空；c o 代表当前活动操作 的对象集，它们必须是任务定义时的数据类的实例；s o 代表对象集元 素当前所处的状态；l o 为对象授权日志，它记录了所有相关对象的授 权历史。 a t u ( a u t h o r i z a t i o nt r a n s a c t i o nu n i t ，简称a t u ) 代表授权事务体对象， 每一次活动的执行都存在一个授权事务体与之对应。每个事务体又由若 干授权步( a u t h o r i z a t i o ns t e p ) 组成，而授权步是访问控制所能控制的 最小单元，它完成对单个数据对象的一次许可授予。因为只有当所有包 含的授权步都授权成功后，授权事务体才能生效，所以活动的授权过程 是一种事务( 即事务体的所有授权步只能同时生效) 。 为了更好地研究该约束并将其应用到流程定制中，下面给出用一阶谓词来 形式化描述的一些业务规则。 组织结构描述谓词 u r o l e ( u ，g ，r ) ，u u ，g g ，r r ：用户u 在组织g 中充当角色r ，即 用户角色映射； r t r e e ( g ，r l ，r 2 ) ，g g ，r l ，r 2 r ：在组织g 中，角色r 1 直接管理r 2 ， 它描述了层次角色树，角色树在角色可继承性任务的执行时可能发挥作用。 任务定义谓词 b t ( b ，t ) ，b e b ，t t ：任务版本t 属于业务流b ： t r ( t ，r ) ，t t ，r r ：为任务版本t 指派了执行角色r ； t i n h e r i t ( t ) ，t t ：任务版本t 属于角色可继承性任务，即如果任务指 第二章业务流管理技术研究 派了角色r 去执行，则r 的父、祖父角色也可以执行该任务； t p ( t ，c ，o p ) ，t e t ，c c ，o p o p ：执行任务t 需要对数据类c 的对象c 执行o p 操作。 活动执行谓词 a t ( a ，t ) ，a a ，t t ：活动a 是任务版本t 的工作实例： a u ( a ，u ) ，a a ，u u ：用户u 执行活动a 。 授权谓词 g r a n t r i g h t ( u ，o ，o p ) ，u u ，0 o ，o p o p ：已授予用户u 对象0 的 o p 操作权。 并发读写谓词 r e a d i n g ( o ) ，0 0 ：表明有用户的操作活动正在读对象o ； w r i t i n g ( o ) ，o 0 ：表明有用户的操作活动正在写对象o 。 对象状态谓词 s t i ( o ) ，o o ：表明对象o 的当前状态为s t i 。 冲突任务和冲突用户谓词 c o n f l i c t u s e r ( u l ，u 2 ) ，u 1 ，u 2 u ：表明u 1 和u 2 是冲突用户，比如 为亲戚关系，因而不能分别去执行同一个业务流实例的冲突任务活动； c o n f l i c t t a s k ( t l ，t 2 ) ，t l ，t 2 t - 表明t l 和t 2 是冲突任务，即它们 不能由相同的用户或者冲突用户去执行。 ( 3 ) 职责分离约束 职责分离