（计算机应用技术专业论文）e_comp系统中调度执行机制的研究与实现.pdf

东北大学硕士学位论文 摘要 e c o m p 系统中调度执行机制的研究与实现 摘要 w e b 服务出现给企业电子商务应用带来了前所未有的商机，使得电子商务f 朝着基于互操作的w e b 服务方向前进。i n t e r n e t 为我们提供了可供访问的大量的 w e b 服务，这些服务间常常是孤立的，彼此间没什么联系，各自完成一定的功能， 如何把己有的w e b 服务组合增值服务以完成新的功能成为当6 u 研究的焦点。 在这种情况下，我们提出了通过w e b 服务组合进而提供增值服务的应用模 式一就是把w e b 服务和工作流技术相结合，设计了一个基于w e b 服务的工作流管 理系统e c o m p 。工作流技术作为组合w e b 服务的一个重要机制，对于快速创建 新的、功能更强大的w e b 服务来说至关重要。工作流将为组件w e b 服务之问的 交互提供运行方式。 本文的研究重点是基于w e b 服务的工作流系统的调度执行机制的研究。在进 7 7 - t d h t t p ：w w w i m o r g c h a t s o a p ：d c o m s o m e e n d p o i n t s o a p ：b c o m 4 4 东北大学硕士学位论文第四章基于w e b 服务的工作流系统买现技术的研究 s o a p ：c c o m s o a p a c o m s o m e e n d p o i n t u u d i ：8 4 b 9 f 5 d o 一3 3 f b 一4 a 8 1 一b 0 2 b 一5 b 7 6 0 6 4 l c l d 6 这种方法的局限在于：一方面由于在s o a ph e a d e r 中包含路由信息增加了消 息的规模将抵消减少信息传输数量所带来的好处。另一方面，对s o a ph e a d e r 的 扩展的标准化方面的工作进行得还很少。 尽管有些w e b 服务技术领先得提供商正在作一些有意义的工作，但整个业界 在s o a p 的核心扩展方面并没有达成一致。导致这一不良现状的原因主要有两个： ( 1 ) 当前多数的w e b 服务引擎并没有一个坚实的可扩展的体系结构。因此，目前 消息头的处理相对比较困难。( 2 ) 市场压力促使w e b 服务提供商在封闭的环境下 丌发新技术，他们更重视软件的发布而不是合作伙伴和竞争者的协调。但是w e b 服务更大范围的普及将会迫使整个w e b 服务行业更加重视可交互操作性并在一些 关键领域展开标准化的工作。 4 2w e b 服务的执行与调用机制的研究 4 2 1w e b 服务的通讯机制 尽管人们通常使用简单的基于r p c 的w e b 服务i 弛 ，但是对于可使用w e b 服 务的分布式系统，s o a p 规范并没有限制系统参与者之间的通讯机制和交互模式。 人们对基于w e b 的分布式系统的最常见的疑问，主要是围绕分布式计算领域的一 个由来己久的争论，也就是：在使用r p c 和消息传递( 通常称作面向消息的中间 件即m o m ) 来解决问题时，需要遵循什么规则和原则。面向服务的体系结构从根 本上是支持这两种模型的。为了最好的利用w e b 服务，很好的理解这两种模型是 很有意义的。 作为分郝式系统的一种模型，消息传递值的是系统通过传递消息来进行交互 的机制。一个消息是个封装了些消息的简单的通讯单元。消息传递可以是同 一4 5 东北大学硕士学位论文第四章基于w e b 服务的工作流系统实现技术的研究 步或异步的。在同步消息传递中，发送操作直到目标处理完消息后才结束。要定 义异步消息较为困难。典型地，发送操作不等待目标处理完消息，就立即( 或很 快地) 返回，相应消息，通常是通过回调地方式送达发送者。消息传递的同步性 由传递中间件控制，如排队系统。直接消息传递无需任何中间件，为了交换消息， 需要在源端和目标端建立直接连接。间接的消息传递包括某种类型的消息排队， 队列提供了消息缓冲和分派的能力。 顾名思义，r p c ( r e m o t e p r o c e s s c a l l ) 的目标是使远端的代码的调用就像使用本 地的过程调用。为了进行r p c 调用，需要以下信息：一个要调用的目标，一个操 作的名字，传递给操作的参数。 下面是r p c 和消息传递之间的区别： r p c 把应用层的特定数据和远端代码相结合，而消息传递主要关系数据。这是 消息传递和r p c 之间的一个根本不同。使用r p c 的好处是程序员无需进行数 据编码和解码，而这些是消息传递系统必须做的工作，特别是在跨编程语占和 平台时。 r p c 是直接调用，他没有排队机制，后端必须在运行中，并且能通过已知地址 直接访问。这限制了r p c 中间件的分派能力。m o m 消息分派就灵活多了。 消息传递使用通用的a p i ，如s e n d m e s s a g e ( ) ，g e t m e s s a g e ( ) 。而r p c 使用 有特定用途的a p i ，他们随着被调用目标的接口而变化。 除了这些重要的不同之外，r p c 和消息传递也有很多相似的地方： r p c 可以在请求响应消息传递定式上实现。 r p c 并非一定要采取请求相应消息定式，有些系统支持单向r p c 此外，r p c 并非一定要同步。有些系统将自动生成线程，在后台等待r p c 响 应。 直接同步的一对一消息传递可以通过一个简单的r p c 柬模拟。 由此可见，r p c 是直接的、同步的、请求一响应，把经过编码的应用层数据结 构从客户传递到实现r p c 功能的目标。消息携带x m l 数据，交互定式大多是单向 和请求一响应。简单的体系结构可以使用直接的消息传递。参与者的组织模式是 一对一。更复杂的结构应使用消息队列，因此是异步的。在这两种情况下，都可 以使用s o a p 来表示所需要的传送的消息。 基于消息队列和r p c 的优缺点对照和目前w e b 服务中间件和工具的发展现 ：状，目前通常采用简单的基于r p c 的解决方案或直接消息传递的方案。随着消息 中间件厂商对w e b 服务支持的进一步增强，随着w e b 服务技术在更多有着复杂商 务过程背景的应用中得到使用，消息传递方式将越来越重要。 一4 6 东北大学硕士学位论文第四章基于w e b 服务的x - 作流系统实现技术的研究 4 2 2w e b 服务的交互定式 通常的消息传递交互定式有四种类型。w s d l 规范定义了这四种交互的定式， 并使用术语传输原语来描述这些定式。 操作的请求一响应定式 这是最普通的操作定式。请求一响应操作定义了输入消息、输出消息和一组 可选的错误消息。由于许多的w e b 服务都是部署为使用h t t p 的s o a p ，所以请 求一响应是w s d l 文档中最普遍的操作形式。请求响应的消息可以是信息性的( 用 于获取w e b 服务所表示的一些对象) ，也可以是行为性的( 用于修改服务提供者的 状态，相应消息将包含新状态信息) 。 操作的单向定式 单向操作没有输出元素，因此也没有错误消息。单向操作就如同一个数据接 收器。单向消息可用于修改服务提供者的状态，但不适用于获取信息的目的( 因 为服务提供者不向请求者发送响应消息) 。由于许多w e b 服务的访问都是通过h t t p 的s o a p ，因此许多单向消息也就成为请求响应消息，其相应是一个简单的h t t p 层次的消息确认。 操作的通知定式 通知操作是由服务提供者发出的单向消息，输出消息被发送到服务请求者， 他是服务提供者方的某些事件( 如超时或操作完成) 的结果。服务提供者如何才 能知道应向何处发送消息，w s d l 规范并未直接描述这一点，因此相关的语义必 须由其他途径描述。解决这一问题的一个机制就是将网络地址( u r l 或e m a i l 地 址) 作为另一个消息参数。 操作的通知一响应定式 通知一相应操作由服务提供者先向请求者发出已输出消息，这于通知操作相 同，二者的不同在于，通知一响应操作期望服务请求者针对该输出流作出应答， 即发回输入消息。于通知操作相同，通知一响应操作也面临相同的问题，即：应 向何处发送输出错误消息。其解决方案于同通知定式。 目前的w s d l 工具侧重于请求一响应及单向消息。由于通知响应消息需要 某种形式的相关或注册机制，以便将消息与请求者的某些有意义的事务相关联， 这一关联层次已超出了w s d l 所能表达的简单语义范围，因此无法在生成的代码 中加入操作次序语义。同样，通知消息需要服务请求者先提供出注册消息，w s d l 也无法直接表示这个相关性语义。大多数的w s d l 工具不支持通知一响应或通知 操作，而只支持请求一响应操作。 4 7 东北大学硕士学位论文第四章基于w e b 服务的3 - 作流系统实现技术的研究 4 2 3w e b 服务的传输机制- - s o a p 与传输协议的绑定 在s o a p 规范中，s o a p 是针对基础的传输消息的格式，而采用何种传输协议 并非是s o a p 规范自身的职责。s o a p 的传输无关性使得s o a p 消息可以方便地与 任意通信协议进行绑定，比如h t t p 、s m t p 、f t p 都是可能地绑定协议。事实上， 从原则上说，任意用于传输信息地网络协议都可以与s o a p 进行绑定。在实际地 绑定中，一般而占s o a p 总是依附于这些些传输网络防议地自身语义，依靠这些 传输网络协议地交互模式来表达s o a p 所需要表达地调用模式。 一般来说，传输协议地交互方式总是涵盖了w e b 服务的交互定式模式的，对 于s o a p 消息而言，s o a p 消息的传送是依靠传输协议的传输具体数据的那部分来 完成的。也就是说传输协议的控制部分完成交互模式，而传输协议的数据部分传 送s o a p 消息。 s o a p 的雏形来源于使用h t t p 协议来完成d c o m 调用，因此从一开始s o a p 就和h t t p 捆绑在一起。随着大量的参与者进入s o a p 规范的丌发，以及s o a p 规范的渐渐成型，s o a p 消息和传输协议被严格的分离开来，s o a p 消息具备了与 任意一种传输协议结合的能力。然而由于h t t p 的8 0 端口能够n , t j 地穿越防火墙， 因此s o a p 鉴于通用性和适用性的考虑，最多的应用仍然是通过h t t p 的，s o a p 消息与h t t p 协议进行结合来实施服务交互的方式是最实用并且应用最广泛的方 式。 下面代码给出了一个s o a p 请求的h t t p 绑定的示例。 s o a p 请求的h t t p 绑定示例代码： p o s t s t o c k q u t e h t t p 1 1 h o s t ：w w w s t o c k q o t e s e r v e r c o m c o n t e n t - t y p e ：t e x t x m l ；c h a r s e t = u t f - 8 ” c o n t e n t - l e n g t h ：n n n n s o a p a c t i o n ：”h t t p ：e x a m p l eo r g 2 0 0 i 0 6 q u o t e s e n v ：e n v e l o p ex m l n s ：e n v 2 ”h t t p ：l l w w w , w 3o r g 2 0 0 i 0 6 s o a p e n v e l o p e 。) d e f d e fc o r p 3 4 1 4 8 东北大学硕士学位论文第四章基于w e b 服务的工作流系统实现技术的研究 成功s o a p 响应的h t t p 绑定示例代码 h t t p l12 0 0 0 k c o n t e n t t y p e ：t e x t x m l ；c h a r s e t 2 ”u t f - 8 ” c o n t e n t - l e n g t h ：n n n n 3 4 5 1 0 0 0 0 4 3 系统引擎调度机制的研究 4 3 1 系统流程的状态转换 工作流引擎的一个重要功能就是控制流程实例和活动实例的状态转换。基于 w e b 服务流程实例包括以下几种运行状态： 4 9 东北大学硕士学位论文第四章基于w e b 服务的工作流系统实现技术的研究 图4 2 流程实例状态转换图 f i g 4 2c o n v e r s i o nc h a r to f f l o wi n s t a n c e ss t a t e 1 ) 起始( i n i t i a t e d ) ：一个流程实例已经生成，但该流程实例目前还没有满足 肝始执行的条件。 2 ) 准备运行( r u n n i n g ) ：该过程实例已经可以执行，但是还不满足丌始执行 第一个活动并生成一个任务项的条件。 3 ) 运行中( a c t i v e ) ：一个或多个活动已经丌始执行 4 ) 挂起( s u s p e n d e d ) ：该流程实例正在运行，但处于静止状态，除非有一个 “重肩”的命令或者外部事件促使该流程实例回到准备运行状态，否则所有的活 动都不会执行。 5 ) 结束( c o m p l e t e d ) ：该流程实例执行已经完成，并且满足了结束该实例的 条件，工作流管理系统将执行过程实例结束后的操作，并删除该过程实例。 6 ) 终止( t e r m i n a t e d ) ：该过程实例在正常结束前被迫终止( 如出现错误或者 异常情况) ，工作流管理系统将执行补救措施，并删除该过程实例。 4 3 2 任务管理器的功能及构成 一个w e b 服务的流程是由一组w e b 服务构成的，每个w e b 服务都是这个流程 中的一个环节并由分散在网络不同的服务提供者提供。他的执行会受到其他服务 调用结果的影响，同时这个任务的调用结果也将影响其他服务的执行，为了实现 有效的调度，并有利于简化流程的恢复技术，针对每个w e b 服务设置一个任务管 理器。由于存在集中式和分布式的调度处理机制，任务管理器在两种系统中的功 能和结构也不同。 一5 0 一 东北犬学硕士学位论文第四章基于w e b 服务的s - 作流系统实现技术的研究 分布式调度机制 在分布式的调度处理机制中，任务管理器既要负责任务的执行和状态监控， 同时也要负责工作流的流程调度，即可以接收前导任务管理器的激活信息和数据 信息，也可以激活后继任务管理器。在系统中没有集中的调度器，整个流程的调 度信息分布在这些任务管理器中，任务管理器既有该任务的前导任务信息，也有 改任务的后继任务信息。因而，任务管理器在系统中处于极其重要的位置。 任务管理器的构成如图所示。 n o t u y p 1 n o t 开vp m l 撩 煞f 悠 圈4 3 任务管理器结构幽 f i g 4 3t a s km a n a g e r s t r u c t u r e n o t f y s l 我们将任务管理器的构成描述成如下形式： ：= ( ， ， ， ， ) ：自l f 导任务信息接收器，主要负责接收前导任务发送过来的激活信息和 数据信息，并判定它所关联的任务是否可以启动等。 ：2 ( ， ， ， ) ：l j s j 导信息列表，存放所有前导任务的信息，在工作流实例调度时由接 收器动态填写。 ：接收器，接收前导任务的激活信息和数据信息，在pl i s t 中记录这 些信息。如果时激活信息，还要调用e v e n t g u a r d 。 ：是谓词表达式，表明任务的启动条件。 ：半e j 0c o n d i t i o n s 是否为真，并根据判别结果确定执行行为，如果 启动条件为真，调用任务调度器t s ，启动任务执行；如果废弃条件为真，调用任 务调度器t s ，废弃执行的任务。 ：任务调度器( t a s ks c h e d u l e ) ，启动任务执行，并负责任务的整个执行 过程，具体包括处理前导任务传来的数据，并通过任务调度入口调度任务执行， 同时接收任务的执行状态的反馈信息，设置任务执行状态。 ：后继任务信息发送器，主要完成向该任务的所有后续任务管理器发送 改任务的执行完成信息( 也就是激活信息) 和数据信息。 ：= f ， ) 5 1 东北大学硕士学位论文第四章基于w e b 服务的工作流系统实现技术的研究 ：后继任务列表，存放有任务启动的后继，存放有任务完成的后继和 任务失败后的后继。 ：根据任务执行情况：启动或完成后的状态，以及后继任务信息列表 中的内容，分别向其后继任务管理器发送通知信息。 ：前导任务发来的第个通知信息，包括激活信息和数据信息。_ m ：向后继任务发送第n 个通知信息，包括激活信息和数据信息 集中式的调度机制 在执行集中式的调度处理机制的系统中有集中的流程调度器，任务管理器作 为流程调度器和任务之间的桥梁，负责任务的执行和状态监控。流程调度器向任 务管理器发送关于任务执行的必要信息。任务调度器向流程调度器发送关于任务 执行的状态信息；当一个任务开始执行时，他的状念为执行态，如果它能成功结 束，那么他的状态就变成提交态( 事务型任务) 或完成态( 非事务型任务) ；万一 任务失败，他的状态就变成废弃态( 事务型任务) 或失败态( 非事务型任务) 。 任务本身除完成一定的功能外，它还必须将自身的执行状态通知给任务管理 器，同时任务也必须能理解来自任务管理器的信息，这样才能实现任务管理器对 任务的管理和控制。 4 3 3 任务管理器的定制 每个任务管理器都具有同样的结构，完成同样的功能，所不同的是任务管理 器中的前导任务信息列表和后继任务信息列表内容不同，调度的服务不同。而这 些不同信息在流程定义时，针对每个任务都进行了具体的定义，可以利用定义时 给出的这些信息，快速完成任务管理器的定制工作。 根据流程的模式定义信息为每个任务生成其任务管理器的实现代码，这包括 为前导任务信息接收器生成该任务的启动条件判别式以及空的前导任务信息列 表，这一判别式为一谓词表达式；为任务调度器生成任务输入数据处理、任务调 度入口，任务执行状念初始化变量等信息：为后继任务信息发送器生成后继任务 信息列表内容。 4 3 4 任务的处理方法 不同类型的任务具有不同的性质，任务执行监控、故障恢复处理等机制需要 了解任务的执行过程，因此在任务执行时要把任务的执行状态及时反馈给流程调 5 2 东北大学硕士学位论文第四章基于w e b 服务的工作流系统实现技术的研究 度系统。任务有无继续执行的必要取决于当前的运行环境。下面就针对这些问题 进行讨论。 ( 1 1 任务的结构 对于基于w 色bs e r v i c e 的工作流系统，其任务有其自身特点： 1 每个任务都是一个己发布的w e bs e r v i c e 中的一个操作。 2 根据每个操作的自身特点，把其分为事务型任务和非事务型任务( 包括用 户型任务) 。其中事务型任务必需要定义补偿操作。 3 基于w e bs e r v i c e 的工作流系统的补偿任务，有别于其它工作流系统的补 偿任务。在其它工作流系统中，我们可以认为补偿任务是可靠的；而在本系统中， 由于网络的特点，使得补偿任务的可靠性降低。原任务和补偿任务实质上是定义 在同一个w e bs e r v i c e 下的两个不同操作而已，这两个操作除了在逻辑上互逆之外， 并没有更多的区别。也就是说，在调度原任务时可能遇到的一些网络故障( 如网 络不通等) ，同样可能出现在补偿任务的调度过程中。因此，补偿任务同样存在调 度失败的可能性。 为了进一步改善恢复的粒度，系统应中把任务细分为若干个状态，对于不同 类型的任务可能捕获的执行状态是不同的。监控系统根据这些状态监控任务的执 行；一旦发生故障，恢复系统根据这些状态提供对任务的恢复以及对调度系统的 恢复；调度系统根据这些状态实旋不同的调度方案。为此每个任务都包含一套内 部状态和这些状态的跃迁。为了描述任务的结构，作出如下定义： 任务内状念：任务内的一个状态是任务执行过程过程中语义上意义明确的一 个阶段。 初始态( i n i t i a l ) ：指任务f 在完成初始化工作所处的状态。 结束态：指任务执行结束时所处的状态。每个任务至少有一个结束念，不 同类型的任务其结束态不同。事务型的任务结束态为废弃态( a b o r t e d ) 或提交态( c o m m i t t e d ) ；非事务型任务的结束态为成功态( d o n e ) 或失败 态( f a i l ) 。 开始态( s t a r t i n g ) ：指任务结束初始化工作所处的状态。 执行态( e x e c u t i n g ) ：指任务处于实际功能执行时所处的状态，即处于执 行w e b 服务调用期间的状态。 任务内跃迁：任务内的一个跃迁时任务状念的一次改变。 任务行为的不同产生不同的跃迁( 例如a b o r t 、c o m m i t ) ，进而使任务进入不同 的状态。任务可由执行态进入废弃态，也可以由完成态进入废弃念。即使任务执 5 3 东北大学硕士学位论文第四章基于w e b 服务的工作流系统实现技术的研究 行完成，但当前的调度环境也可能不允许任务提交，凶而允询：任务虽已完成，但 必须废弃。 w e b 服务的内部执行状态是不可见的，因此，无法捕捉w e b 服务执行过程中 的状态，因而w e b 服务的任务结构如下。 任务的结构不能确定任务的执行方法，也不能确定任务的功能，他们只是一 种任务状态变迁的高级表达，为任务调度、外部监控任务执行以及故障恢复提供 依据。所以两个具有相同结构的任务，可能拥有完全不同的功能。 m 事务型w e b i i l i 务结构 图4 4 任务结构 f i g 、4 4t a s ks t r u c t u r e 事务型w e bj t l t 务结构 ( 2 ) 任务间控制流的实现 任务内的这些状态对于流程调度是非常重要的，因为流程调度系统就是根据 这些状态来实现任务间控制流依赖，即控制工作流向不同方向流转。在分布式的 调度系统中，任务管理器接收到任务的执行状态后，将根据任务管理器的后继任 务信息列表，向依赖于该状态的后继任务管理器发送激活信息，控制流程的执行。 而在集中式的调度系统中，是在任务管理器接收到任务的执行状态后，把消息传 递给集中的流程控制器，而有流程控制器根据该任务的后继任务信息向依赖于浚 状态的后继任务管理器发送激活信息柬控制流程的执行。为了说明任务间控制流 5 4 东北天学硕士学位论文第四章基于w e b 服务的工作流系统实现鉴查塑竺壅 的实现，见图。 三个简单的事务型的任务1 、任务2 、任务3 。其执行过程为： 1 1 如果任务1 成功结束，任务3 启动，流程结束； 2 1 如果任务1 执行失败，任务2 启动，当任务2 成功完成后，任务1 又熏新启动 3 1 任务1 的不同执行结果状态将引发1 ) 或2 ) 不同的执行路径。 任务1 ，。 ，。 f 任务2 任务3 说明： 任务问跃迁： 任务内跃迁： 图4 5 任务间的依赖关系 f i g 4 5t h ed e p e n d e n c i e sb e t w e e n t a s k s ( 3 ) 任务间输入输出数据处理 调度机制要解决的一个问题是任务问数据传递问题。一个任务的输出可能成 为另一个任务的输入，而且前一个任务的输入可能是一些复杂的数据。为了在网 络环境中有效地传递这些数据，我们以对象的概念来为基础讨论这个问题。 我们根据数据对象的类型设计了如下的数据处理方案。 任务的输出首先在本地作为对象被实例化。对象实例化后，首先将该输出对 象标识符反馈给任务管理器，而后任务管理器根据数据对象的标识符从数据对象 中获得数据的值。 4 4 系统流程的动态配置 一个好的工作流管理系统在运行时应该可以改变过程原有的定义，从而使系 统具有更强的灵活性，更好的满足现实中企业在处理工作时的要求。但现有工作 流系统对模式的动态修改能力的不足限制了工作流系统的大规模应用。动态配置 为工作流管理系统提供了动态修改工作流模式的机制，极大的扩展了工作流的应 用范围。 5 5 东北大学硕士学位论文第四章基于w e b 服务的5 - 作流系统实现技术的研究 在一个分布式的环境中，运行时间很长( 1 0 n g r u n n i n g ) 的工作流系统需要有动 态配置其业务流程的能力。这是由于：工作流的执行需要很长时间结束。这一方 面是由于工作流的任务本身的执行时间可能很长；另一方面，工作流中的用户型 任务的执行需要与人来交互。在长时间的运行过程中，工作流的执行可能会遇到 各种各样的特殊情况发生，比如错误，用户需求的变化，而这些变化在工作流模 式的设计过程中是无法预见的。这时，如果工作流系统不具备动态配置的能力， 那么该业务流程的执行将被中止，或执行失败。而动态配置机制能允许f 在运行 的应用程序动态的改变内部的业务流程的结构，以便使整个工作流流程继续向前 运行。 动态配置有两种类型：特殊实例的改变，模式的永久改变。特殊实例的改变 是指当工作流执行过程中出现了异常，这时工作流的执行可能会与模式的定义出 现一些偏差，工作流模式的修改只应用到该特定的实例，但工作流模式不会被修 改，其它工作流实例仍按照原有模式执行。例如，在一个医院早，患者就医前， 需要按照医院定义的流程依次完成诸如挂号、看病、丌药、付款等活动。但当有 一名心脏病人需要急诊时，医生当然会先抢救患者( 看病) ，等患者病情稳定后再 要求患者完成挂号等任务。模式的永久改变是指企业由于自身业务流程的永久改 变，需要对工作流模式进行相应的修改。这是通常意义上所指的工作流动态配置。 动态配置机制可能采用的三种策略：r e s t a r t 、p r o c e e d 和t r a n s f e r 。r e s t a r t 是指 当工作流模式发生改变后，所有正在运行的实例都被废弃，然后按照新定义的模 式重新执行。p r o c e e d 是指当工作流模式发生改变后，所有的正在运行的实例仍按 原来的模式正常执行至结束，而新产生的实例按照修改后的新模式执行。t r a n s f e r 这类动态配置影响当前系统内的所有正在运行的工作流实例，但不会使工作流实 例发生r e s t a r t 和p r o c e e d 。当t r a n s f e r 发生后，所有处于等待状态的任务将重新被 建立，并按照新的工作流模式来执行。t r a n s f e r 是动态配置中最复杂的一种类型。 动态配置机制的难点主要有点：一个是正确性问题；一个是对f 在运行的实 例的处理方法。 正确性包含两方面的内容：语法正确性和语义证确性。语法j f 确性是指当工 作流动态配置完成后，新的工作流模式必须在语法上是j 下确的。工作流模式的验 证工具可以完成对这种正确性的检测。语义正确性是指新的工作流模式不能违反 系统中定义的一些语义约束，不能导致工作流执行在语义层次上的错误。如一个 订货系统，如图所示，由三个串行执行的任务构成，包括订货、付款、发货。假 设一个工作流实例按照旧的流程执行到“发货”任务结束，这时工作流模式发生 了变化，第二、三个任务的执行顺序发生了变化，如果系统没有其它有力的措施 来保证工作流实例执行的f 确性，那么该工作流实例将执行结束，但却没有完成 一s 6 东北大学硕士学位论文第四章基于w e b 服务的工作流系统实现技术的研究 “付款”任务，造成流程运行错误。关于语义正确性的研究目标包括：定义语义 f 确性标准，以及提供易于使用的验证方法等。不同组织对正确性有不同的要求， 不存在对j 下确性的单一的好的标准。 ：二! 二h 二兰户c ! 二) 趣 “j ! ：竺：) ( 篡) ( ! 一) 遵 图4 6 订货流程国 f i g 4 6t h e f l o wc h a r to f p u r c h a s e g o o d s 最后，动态配鼍机制也必须提供“撤销”功能，使模式的修改者可以将模式 的定义恢复到最近的一次正确的位置。而这种功能的完成最好不需要用户做更多 的交互，而由系统自动完成。 而对正在运行的实例的处理方法更是动态配置机制的一个难点0 末 别是在w e b 服务环境中，由于w e b 服务具有的松散耦合的特点，缺少一种支持事务的底层架 构。如果想成功完成这个方法，工作流系统在运行时还需要依靠任务管理器实例 的状态而选择不同的执行动作。 通常系统支持六种动态配置操作，分别是添加任务、删除任务、修改任务、 添加跃迁、删除跃迁、修改跃迁。下面详细介绍这六中操作的含义。 添加任务：指在工作流模式中已经存在的两个任务之间添加一个新的任务。 删除任务：指在工作流模式中删除一个任务节点。 修改任务：指修改工作流模式中指定任务的属性，如w e b 服务的w s d l 文档 的u r l 等。 添加跃迁：指在工作流模式中，在指定的两个任务之间添加跃迁关系。 删除跃迁：指在工作流模式中，将指定的两个任务之间添加跃迁关系删除。 修改跃迁：指在工作流模式中，修改跃迁定义的属性。包括，跃迁条件，数 据流上需要传递的数据名。 4 5 流程执行监控及故障恢复的研究 4 5 1 日志管理 同志是流程管理中必不可少的部分，它对流程中的故障恢复起到关键的作用。 艺实时地记录了流程实例中整个流程的运行状况以及每一个任务的状态信息，这 5 7 东北大学硕士学位论文第四章基于w e b 服务的工作流系统实现技术的研究 些信息使得用户实时监控流程的运行过程成为可能，并且为流程的故障恢复提供 了必要的信扈、。 r 志记录的是两方面的信息：状态及状态所对应的数据( 包括输入数据、输 出数据及错误信息) 。根据w e bs e r v i c e 的自身特点，我们在任务管理器调度的不 同阶段进行f i 志记录，共分三个阶段： 1 1 初始状态：任务处于初始状态，即任务管理器即将开始调度任务。其功能是将 任务状态置为“开始执行”。 2 ) 执行完毕：任务执行完毕，将结果返回任务管理器。其功能是记录任务执行结 果，包括输出数据和相关错误信息，并根据执行结果将任务罱为不同状态( “成功” 或“失败”) 。 3 1 准备下一任务：任务管理器找到下一任务的相关信息( 地址、输入数据等) ， 并准备将其发送给后继任务管理器。其功能是记录后继任务的相关信息( 实例i d 、 任务i d 、输入数据、u r l 等) 1日志管理 fff 任务管理器 初始状态执行调用执行结束准备下一任务 图4 7 根据日志管理任务管理器执行阶段划分示意幽 f i g 4 7t h es k e t c hm a p o f t a s km a n a g e re x e c u t i o np h a s eo r d e rb yl o g 通过将任务管理器划分为不同的阶段，并且在各个阶段分别记录相关信息， 即可把整个流程的信息实时、详尽地记录下来，为监控和恢复提供了重要依据。 而且这样的划分粒度还有利于减少调度器的负担，减少不必要的重复工作，如： 当前驱任务管理器a 在成功调度任务、并记录了后继任务b 的相关信息后，即3 ) 阶段执行完毕，调度器突然失败，整个流程不能继续执行下去。当启动恢复模块后 5 8 查! ! 苎堂婴主堂堡笙查整! 兰墨些! 里堑竺三笪堕墨丝壅墨垫查塑翌垄 根据同志，则可判断出从任务b 开始执行即可，而不必重新执行a ，或是重新查 找任务b 的相关信息。 4 5 2 流程执行监控器 为了感知系统的执行情况，一般在工作流系统中都配有工作流执行监控器， 依靠监控器来感知系统当前运行到了那里，某一个流程执行是否顺利，是否需要 人为协调。 监控器主要监控任务的执行情况。任务的执行情况主要通过任务内部状态和 内部跃迁来表示，不同类型的任务具有任务结构不同。在流程执行时，调度系统 要不断地将任务地执行状态送往监控器，监控器将这些状态展示出来，因此监控 器要具有友好的用户界面。 在一个组织范围内，可能有多个工作流模式。在某一时刻，按照每一个流程 运行地流程实例可能又有多个。监控器必须能够监控这些流程地每一个流程实例 地运行情况，而且可以在多个实例之问进行切换。因此我们可以对某一具体实例 的运行状况的实时监控，提供了图形和文本两种反馈信息。 监控部分的实现机制主要是：监控器定时扫描日志，读取同志所记录的流程 状态信息，将这些信息用图形和文本的形式、实时地表达出来。 4 5 3 检测及恢复机制 f 1 1 错误类型 任务执行错误 调度过程中，任务层所遇到的错误，这些错误使得整个流程调度出现问题， 不能正常执行。主要是逻辑错误，如任务内部执行失败等。 解决方案：在一般工作流管理系统中，任务是面向工作流的，也就是说，我 们可以进入工作流任务中，清楚地掌握任务的执行状态，可以尽可能地在错误发 生点捕捉到错误。对于能够就地恢复的错误，我们进行恢复，从而使得整个流程 的执行并不受到影响，比如，对于一些登录错误，我们可以采取r e t r y 的方法，进 行恢复：而对于那些在任务层不能处理的错误，我们将其通报给上一层任务 管理器层，由任务管理器进行恢复。而在基于w e bs e r v i c e 集成的工作流系统中， 那些任务( w e bs e r v i c e ) 是早已经存在的，并不是面向工作流的任务，也就是说， 我们没有办法取得其内部状态。因此，当错误发生时，我们不可能在任务内部捕 捉到该错误，也就无法在任务内部进行恢复，因此我采取的策略是，将任务层的 错误全部通报给任务管理器层，由任务管理器层捕捉到错误，然后根掘不同的方 5 9 东北大学硕士学位论丈第四章基于w e b 服务的工作流系统实现技术的研究 法进行恢复。 任务管理器错误 在基于w e bs e r v i c e 的工作流系统中，任务管理器的错误来源主要有两种： 种是在调度过程中，由于调度引擎失败引起的任务管理器不能进行正常的任务调 度，从而造成失败。如：某一任务管理器线程在执行过程中，突然消亡，从而使 得无法进行调度。另一种错误则是由任务层通报上来的错误。 解决方案：在任务层出现的错误，我们采取两种方式进行处理。对于那些可 以在该层解决的问题，我们就地、自动进行恢复，比如，一旦出现上一段提到的 任务管理器突然消亡的故障，那么检测发现错误后，可以自动调用恢复模块进行 恢复，这样整个错误的出现直至恢复过程对于用户来说是透明的。而对于那些无 法解决的问题则通报给监控模块，由系统管理员手动解决。 系统错误 系统错误，主要是指那些支撑整个工作流系统的底层框架产生的失败，如： 运行环境故障，网络不通等。 解决方案：这种失败，由于发生在工作流系统之外，主要是一些系统故障， 所以无法自动恢复，只能通报给监控系统，由管理员在解决了系统故障后，手动 启动恢复模块，使得工作流实例继续执行。 ( 2 ) 检测机制 在基于w e b 服务地工作流系统中，基于流程的层次结构，系统提供分别提供 了对调度器、任务管理器和任务的检测功能。 对调度器的检测 调度器的运行状况对于整个流程非常重要，系统应该提供了对调度器的检测 功能：调度器提供了调用接口操作，用于响应监控器。监控器定时调用该接口操 作，该操作被调用后，立刻对监控器发出响应，表示此时调度器可以f 常工作。 一旦监控器没有收到正常响应，则表明调度器出现故障，此时监控器将该故障通 知给系统管理员，由系统管理员在做出相应修复后，启动恢复模块，从而使流程 继续运行。这个检测功能类似于操作系统中的p i n g 操作。 对任务管理器的检测 每当调度器生成一个新的任务管理器的时候，则在系统中产生一个新的线程， 改线程完成任务的调度功能。大部分情况下，该线程从产生到消1 1 l = 的整个过程可 以正常执行，但是并不能排除某一线程意外中止的情况，因此，我们需要对每一 个线程( 即任务管理器实例) ，在其存活期间进行检测，以确保流程正常运行。实 现机制如下： a ) 当一个新的任务管理器实例生成时，它将会自动到仓储中注册，表明其处 6 0 一 东北大学硕士学位论文第四章基于w e b 服务的工作流系统实现技术的研究 于存活剜 b 1 处于存活期的任务管理器实例，每隔一段时间，到仓储中登记一次，将当 前系统时间戳写入日志 c 1 当一个处于存活期的任务管理器实例完成所有调度功能后，在其消亡之 前，到仓储中将其自身注销 基于上述机制，在检测模块中，定时启动一个线程，该线程扫描同志仓储， 对所有处于存活期的任务管理器实例，将最新记录的时间戳和当前系统时间作比 较。如果时恻差大于某个定值，我们则认为该任务管理器实例出现异常。此时， 恢复模块自动启动，根据日志信息，恢复断点处上下文，重新启动一个新的任务 管理器实例，保证整个流程继续运行。这一恢复过程完全由恢复模块自动运行， 对于用户来说是完全透明的。 对任务的检测 当系统中的任务发生执行故障时，即某一场地的w e b 服务无法正常工作时， 将会影响整个工作流系统的运行。而一旦任务发生调度异常，它是无法主动通知 监控系统的，只能在任务管理器中捕获该异常。这样任务管理器还同时承担若报 告任务异常的职责，它们把所捕获的任务异常信息通报给监控器，由管理员根据 任务的性质和流程的特点，使用不同的策略进行恢复。 ( 3 ) 恢复策略 在基于w e bs e r v i c e 的工作流系统的恢复模块中，主要采用了两种恢复策略： 回滚恢复( r o l l b a c kr e c o v e r y ) 和向前恢复( f o r w a r de x e c u t i o n ) 。这是由工作流恢 复机制和w e b 服务的自身特点共同决定的。 在基于w e b 服务的工作流系统中，主要有两种流程执行交互方式：请求响应 ( r e q u e s t r e s p o n s e ) 和单向( o n e w a y ) 。 1 r e q u e s t r e s p o n s e 类型 这种类型的流程，是由客户端向服务器端发出调用流程的请求并等待结果。 服务器收到请求后，启动工作流系统，完成一系列的任务调用，最后将结果反馈 给发出请求的客户端。这就说，客户端发出请求后，将会一直等待服务器的反馈 结果。而由于网络的特点，使得客户端等待的时间有一个限制，即在规定的时间 内如果发出请求的客户端仍没有收到最后的结果，那么将会超时报错。因此，对 于这种r r 类型的流程，一旦在调度过程中出现异常，则必须进行回滚操作，放 弃流程；否则，即使经过管理员排除异常、继续向下运行并得出最终结果，那这 个结果也毫无意义，因为此时发出请求的客户端，已经由于连接超时失败，而不 得不放弃了这个流程，因此，客户端是得不到服务器的反馈结果的。 2 o n e w a y 类型 6 1 ， 东北大学硕士学位论文第四章基于w e b 服务的工作流系统实现技术的研究 显然，相对于r r 类型的流程而言，o n e w a y 类型的流程只是种单项的操作。 客户端发出请求之后，即可断丌连接，并不再等待最终结果的反馈，因此不存在 超时的问题。对于这类流程，我们完全可以采用继续向前执行的方法进行恢复。 恢复过程 1 o n e w a y 类型 遍历该实例的所有任务，对于那些处于“初始状态”或“丌始执行”状态的 任务，则需重新执行；对于己执行成功，但尚未查找后继任务的任务，则不需再 次执行，只需根据仓储查找到后继任务并将后继任务所需的输入数据传给它即可。 对于那些需要重新执行的任务，在日志仓储中查找输入数据，在进行必要的 格式转换后( 转换为任务管理器能够接受的格式) ，重启任务管理器，并传递相关 数据，恢复断点处上下文，使得该任务得以重新执行。 2 r e q u e s t r e s p o n s e 类型 对于r l r 类型流程的恢复，要采用r o l l b a c k 策略。在进行级联回滚( c a s c a d i n g r o l l b a c k ) 时，我们可以引用数据结构中“栈”的思想。为此，在流程执行过程中， 每当开始调用一个任务时，在日志仓储中，都将此任务“压栈”。一旦需要回滚， 则依次将任务从栈中“弹出”，调用该任务的补偿任务。当栈中最后一个任务( 调 度的第一个任务) 的补偿任务执行完毕后，整个流程也就补偿完毕。通过引入“栈” 的思想，可以保证补偿过程严格按照调度过程的逆序进行，这样可以保证流程能 够成功补偿。 调用补偿操作时，通过查找日志仓得到补偿操作的u r l 地址以及补偿操作所需 的输入数据，启动任务管理器，执行补偿操作。 ( 4 ) 恢复处理方法 根据工作流中流程的不同特点和任务的不同性质，工作流的恢复处理方法可 分为两种： 自动恢复：工作流的错误检测机制可以自动发现系统运行期故障，并启动相 应的应急程序来完成恢复操作。例如，对于有些工作流的补偿任务和应急任务的 启动，通常都是由工作流的恢复系统发现问题后自动完成的。 手动恢复：工作流管理系统发生故障后，由工作流的检测机制发现异常情况， 通知监控器。系统维护人员发现报警信息后，分析故障原因并做出相应处理。排 除故障后，维护人员根据故障所导致的结果，进一步查询和分析工作流的任务执 行情况，从而采用相应的恢复手段。例如，通信故障和：r ：作流组件故障都可以通 6 2 东北大学硕士学位论文第四章基于w e b 服务的工作流系统实现技术的研冤 过手动恢复的方式来完成。 东北大学硕士学位论文第五章e _ c o m p 系统调度引擎的设计与实现 第五章e c o m p 系统调度引擎的设计与实现 从本质上说，ec o m p 系统本身也是一个工作流系统，只是流程中的每个任务 是由w b 服务包装实现的。所以，它既有普通工作流系统的特性，同时由于w e b 服务的引入又有了自身的特点。工作流流程控制器提供工作流的使动服务，它是 由一个或多个工作流引擎组成，它们负责运行时的全部控制环境。本章