调研 工作流比较表格.doc

工作流系统关键技术比较2012/12/20目录工作流系统关键技术比较12012/12/201目录2一、消息驱动和事件驱动工作流的区别与应用2二、典型工作流过程定义语言规范的特点与应用3过程定义语言BPEL/BPMN2/XPDL/BPML/JDPL3语言功能的比较4语言结构的比较4语言具体细节的比较5其他比较7三、典型工作流引擎的功能、结构比较101jBPM3112向BPMS努力的jBPM4123jBPM5144. Activiti5155微软工作流186小结22四、基于Web服务的工作流管理系统224.1概述224.2基于Web服务的工作滚模型224.2.1符合Web服务的工作模型234.2.2基于Web服务的工作流管理系统244.3 Web服务在工作流中的应用264.3.1 Web服务作为工作流的任务264.3.2作流作为Web服务的实现机制26一、消息驱动和事件驱动工作流的区别与应用基于“消息驱动”和“事件驱动”的工作流都可应用于一个可行的分布工作流系统。信息传递的分布工作流系统强调了每个节点的功能独立性，使得一个节点的失败只影响到与该结点有关的相应工作流实例或者某一个工作流步骤，从而将影响范围缩小到最小范围，使得系统构造方面有了更好的升级性和适用性，但是它没有提供事件的历史记录，所以该机制现在正在研究如何使用日志文件来管理工作流，并尝试用非连续性的消息驱动来提高性能。信息传递的分布工作流系统目前主要应用于金融支付系统、电子商务系统（如淘宝等）。 事件驱动的机制主要是开发了Brokers/Services模型和EVE平台，从而将分布式工作流的实行分为3步：首先由高层的图形界面提供工作流建模工具，然后由中层的Brokers/Services模型执行工作流，最后由底层的EVE平台提供分布式工作流的实行框架，主要负责事件管理、历史记录和工作流执行者之间的交流。B/S模型提供了一个较完善的语言定义机制，保证建模人可以了解工作流执行者的实际行为，组成工作流说明的工作流执行过程可以被正确定义，工作流执行过程的准确性得到保证，工作流执行完毕后的分析也成为可能。但是，对于活动的工作流或者正在运行的组成部件进行修改所带来的影响还没有得到很好的解决，这将是以后的研究方向。事件驱动的分布工作流系统主要应用于医疗保险信息系统、集装箱物流信息系统 消息驱动模式 用户登陆系统后，向服务器端提交Http Request 请求，接受消息线程后初始化该用户的上下文环境，读消息线程到接受队列中检索属于该用户的消息，并反馈给用户，用户查看消息后可以进行消息处理（这里的消息其实就是用户的任务列表的描述）。当用户处理消息时，依据业务规则对消息进行处理，此时消息接受队列将用户发送的消息，自动转发到消息管理池中去，等待消息轮询查找和调用。二、 典型工作流过程定义语言规范的特点与应用过程定义语言BPEL/BPMN2/XPDL/BPML/JDPLBPML 和XPDL 及BPEL4WS 都是基于XML 的过程定义语言, 它们提供了一个正式模型来表达企业商务过程中的可执行过程。XPDL 是工作流管理联盟( The Workflow Management Coalition, WfMC) 基于XML 定义的XML 过程定义语言( XML Process Definition Language)；XPDL 构成了WfMC 工作流标准的Interface；商业过程建模语言( Business Processes Modeling Language, BPML) 是BPMI 组织( The Business Process Management Initiative) 提出的一种新的过程定义语言, 用来全方位的描述企业商业过程中抽象的可执行过程, 其中包括基于Web Services 的某些特殊的领域。Microsoft 的XLANG 和IBM 的WSFL 同样也是过程定义语言中的分支。2002 年8 月, Microsoft/IBM 发布了一个新的规范: BPEL4WS, 它结合了XLANG 和WSFL。XLANG 和WSFL 共同构成了BPEL4WS( The Business Process Execution Language for Web Services)语言功能的比较XPDL、BPML 都基于XML 分别提出了一个用于表达企业商务（电子商务）过程的抽象模型, 这是一个工作流过程定义的元数据( metadata) 模型。在这个正式的模型中定义了各种复杂的活动、事务及事务补偿、数据管理、异常处理及操作等语义。基于元数据模型, 特定供应商的工具能够借助通用交换格式交换不同的异质系统中产生的工作流定义。由此提供了通用的方法描述和访问工作流定义, 并可以轻松实现不同的异质系统之间工作流定义互换的操作。BPEL4WS 提供了一种XML 注释和语义, 用于指定基于Web Services 的业务流程行为。使用合作伙伴的交互方式, 定义业务流程。合作伙伴可以将服务提供给流程, 也可以向流程请求服务, 或者参与到流程的双向交互中。BPEL4WS 对每个服务分配了合作伙伴的责任, 同时指定了一组Web 服务操作的可能执行顺序、这些Web服务间共享的数据、业务流程涉及哪些伙伴以及这些伙伴在业务流程中扮演什么角色、一组Web 服务的共同异常处理以及关于多个服务和组织是怎样参与的等问题。从语言的功能来看, BPML 和BPEL4WS 重点致力于Web Services 的定义, 反映在以下3 个方面:(1) 活动类型明确划分为消息交换、事件处理、补偿校正、延迟指定等类型。(2) 活动的属性支持实例的相关性、消息部分的抽取、服务实例的定位。(3) 支持事务, 异常处理和补偿校正。XPDL 则重点致力于分布式工作流的相关领域。这主要体现在以下两个方面:（1) 活动属性中明确规定了一项活动执行所需的资源。这是一个表达式, 在系统运行时计算, 用以决定所需的资源。(2) 活动属性中明确规定了完成一项活动所需的应用程序。这表明XPDL 在语言层面上支持工作流程推进过程中的人工参与, 强调系统运行期间的人机交互活动。语言结构的比较BPML 被设计为一种块结构( block-structured) 语言。递归的块状结构在作用域( scoping ) 概念中起关键作用。流程控制( 路由) 完全用块结构概念进行处理( 例如: 顺序执行块中的所有活动) 。XPDL 被设计成一种有向图结构( graph-structured) , 再添加了一些其它的概念来处理块。作用域( scoping)体现在包( package) 和过程( process) 的层次上。过程( process) 定义不能嵌套。“ 路由”由活动( activities) 之间的迁移来处理。一个过程中的活动可视为一个有向图中的节点, 而迁移作为有向图中的有向边。迁移条件在系统运行时决定下一步该执行的活动。BPEL4WS 也是一种块结构的语言。允许定义递归的块, 但是限制在顶层进行定义和声明。在一个块内, 有限支持有向图流程的概念。具体地说, BPEL 只有非循环图, 因此没有循环(loop) 。BPML 在定义和声明中广泛使用块结构。复杂活动引用上下文关联的活动集。在上下文中可以声明或重声明属性, 定义或重定义过程( 嵌套过程) 。这些属性和过程被它们所在区域的上下文限制了作用域。具体包括: 错误处理, 事务处理, 用于消息处理的连接器。由于活动集中可以有复杂的活动, 这样嵌套循环得以实现。XPDL 只允许在顶层定义过程, 因此没有嵌套的过程。由于工作流相关数据同样在顶层定义, 或在一个过程中定义, 因此它被限制在这两层范围内。BPEL4WS 不支持嵌套过程的定义。工作流相关数据的等价物: 容器( container) 是全局数据。XPDL 中的块活动( block activity ) 如同BPML 中的复杂活动。它有属性可以指派复杂活动类型, 以及定义一个活动集上下文的信息。上下文中的data field 声明, 可以起到BPML 中作用域的效果。为了实现嵌套过程,过程定义也需要被包含进来。BPML 中有关复杂活动的很多特性在XPDL 中都可用块活动替代。块活动通过引用活动集( 这种活动集没有向活动集外的迁移活动) 的名称来执行活动集。BPML 定义的所有活动如果要转换为XPDL 的活动, 可简单地在XPDL 活动集中引入一个起始活动和一个结束活动, 这里起始活动是一个与分支( and split ) , 结束活动是一个与连接( and join) 。从起始活动到块内的其它活动, 和从该块中的其它活动到结束活动之间有时可能需要一个迁移条件。因此, 虽然XPDL 不似BPML 有嵌套过程, 但它包含的块活动和活动集可以灵活地扩展实现现BPML 的复杂活动。语言具体细节的比较3 种语言的高层数据结构对照 3种语言对应元素比较3 种语言对事务和异常处理的比较其他比较BPMN2.0BPMN2.0相对于旧的1.0规范以及XPDL、BPML及BPEL等最大的区别是定义了规范的执行语义和格式，利用标准的图元去描述真实的业务发生过程，保证相同的流程在不同的流程引擎得到的执行结果一致。BPMN2.0对流程执行语义定义了三类基本要素，它们是日常业务流程的“三板斧”： Activities（活动）在工作流中所有具备生命周期状态的都可以称之为“活动”，如原子级的任务（Task）、流向（Sequence Flow），以及子流程（Sub-Process）等 Gateways（网关）顾名思义，所谓“网关”就是用来决定流程流转指向的，可能会被用作条件分支或聚合，也可以被用作并行执行或基于事件的排它性条件判断 Events（事件）在BPMN2.0执行语义中也是一个非常重要的概念，像启动、结束、边界条件以及每个活动的创建、开始、流转等都是流程事件，利用事件机制，可以通过事件控制器为系统增加辅助功能，如其它业务系统集成、活动预警等。这三类执行语义的定义涵盖了业务流程常用的Sequence Flow（流程转向）、Task（任务）、Sub-Process（子流程）、Parallel Gateway（并行执行网关）、ExclusiveGateway（排它型网关）、InclusiveGateway（包容型网关）等常用图元。现实业务所有的业务环节都离不开Activities、Gateways和Events，无论是简单的条件审批还是复杂的父子流程循环处理，在一个流程定义描述中，所有的业务环节都离不开Task、Sequence Flow、Exclusive Gateway、Inclusive Gateway，其中Task是一个极具威力的元素，它能描述业务过程中所有能发生工时的行为，它包括User Task、Manual Task、Service Task、Script Task等，可以被用来描述人机交互任务、线下操作任务、服务调用、脚本计算任务等常规功能。User Task:生成人机交互任务，主要被用来描述需要人为在软件系统中进行诸如任务明细查阅、填写审批意见等业务行为的操作，流程引擎流转到此类节点时，系统会自动生成被动触发任务，须人工响应后才能继续向下流转。常用于审批任务的定义。Manual Task:线下人为操作任务，常用于为了满足流程图对实际业务定义的完整性而进行的与流程驱动无关的线下任务，即此类任务不参与实际工作流流转。常用于诸如物流系统中的装货、运输等任务的描述。Service Task:服务任务，通常工作流流转过程中会涉及到与自身系统服务API调用或与外部服务相互调用的情况，此类任务往往由一个具有特定业务服务功能的Java类承担，与User Task不同，流程引擎流经此节点会自动调用Java类中定义的方法，方法执行完毕自动向下一流程节点流转。另外，此类任务还可充当“条件路由”的功能对流程流转可选分支进行自动判断。常用于业务逻辑API的调用。Script Task:脚本任务，在流程流转期间以“脚本”的声明或语法参与流程变量的计算，目前支持的脚本类型有三种：juel（即JSP EL）、groovy和javascript。在Activiti5.9中新增了Shell Task，可以处理系统外部定义的Shell脚本文件，也与Script Task有类似的功能。常用于流程变量的处理。JPDL与BPEL比较1. 流程结构定义：JPDL中定义了一些基于有向图的节点和变换，通过这些 节点和变换来实现流程的定义。而在BPEL中有一些基于XML元素的结构化活动，通过这些活动来实现流程的结构定义。2. 数据处理：JPDL中的变量是基于POJO(Plain Old Java Object)定义的，流程中需要进行处理的数据可以通过ContextInstance在外部类中调用。BPEL中变量是基于xml结构，可以通过assign活动来进行操作。3. 和流程的交互方式：JBPM提供了一组API，通过调用这些API的方法允许客户端代码和流程实例的直接交互。BPEL提供了Web服务的接口，客户端通过这些接口来实现和流程实例之间的交互。4. 服务的调用：JPDL通过action handler来实现和外部服务的交互。在BPEL中，通过invoke等活动来实现。Activiti5与jBPM5都属于业界优秀的开源工作流引擎，都支持BPMN2.0最新规范，均基于Apache License，符合J2EE规范，提供工作流建模、执行以及对流程生命周期过程监控。但两者设计理念和技术组成却有很大不同，见下表三、 典型工作流引擎的功能、结构比较1jBPM3jBPM3的最新版本是3.2.7，其包括了以下组件：基于Eclipse的流程设计器、用于监控案例（流程实例）和处理任务的Web控制台以及jPDL核心库。如下图2所示：图 2：JBPM3组件1. 基于Eclipse的流程设计器提供给开发人员绘制jPDL流程图，因为该设计器基于Eclipse，所以生成的流程文件可以与开发代码一起组织管理，非常容易进行单元测试。Web管理控制台主要有两个功能：一是作为工作流客户端应用接口，给用户提供一种手段，以处理案例运行过程中需要人工处理的任务；二是对案例的状态进行监控与管理。2. jPDL核心库jPDL核心库是一个单独的JAR包，可以嵌入到目标应用中执行，它包括了：o 流程仓库：解析jPDL流程定义文件并存储读取；o 流程引擎：对流程定义进行初始化和调度执行，节点的运行期行为与jPDL里定义的节点类型一一绑定；o 任务管理：生成任务节点所对应的工作项，管理工作项的生命周期（初始化、分配执行者、执行、挂起、结束、终止）；o 事件管理：发布案例和任务的开始、结束事件，通过监听者模式调用相应的事件处理器；o 异步执行机制：通过线程实现了Job Executor，进行异步工作的处理，这些工作包括了时间处理、异步动作。o 身份组件模型：实现了一套简单的身份组件模型，包括了组、用户和权限。通过调用自定义Java代码实现了对外部应用的调用。 jBPM3是一个轻量级的嵌入式工作流系统。它在Java社区的成功得益于两个方面：一是嵌入式，这降低了使用工作流的门槛；二是对开发人员友好，这表现在易读的jPDL、流程的可测试性(Eclipse插件)以及节点行为的可扩展性，我们可以非常容易的在流程运行中加入自己定制的行为（通过事件处理器和Action）。jBPM3面向开发人员，它解决的问题是流程的自动化，它的影响力集中在Java开发社区，是一个完整的工作流系统实现。2向BPMS努力的jBPM4与jBPM3相比，jBPM4最大的变化是引入了流程虚拟机（PVM），同时增加了BPMS的特性。jBPM4不再满足于工作流系统的定位，开始向BPMS努力。1. 为什么引入流程虚拟机尽管jBPM3在Java社区取得了很大的成功，但是有一件事始终被人们诟病，那就是它不支持流程语言规范，从最开始的XPDL、BPEL到后来的BPMN，它采用了自定义的jPDL。在jBPM3中，节点的运行期行为与jPDL里定义的节点类型是一一绑定的，这造成了流程引擎与特定流程语言的绑定，要支持其他的流程语言变得困难。于是在jBPM4中，jBPM提出了流程虚拟机的概念，即流程引擎与流程语言解耦，通过一套通用的流程模型并配以可定制的节点运行期行为实现了对多流程语言的支持。流程虚拟机带来的好处是多方面的：第一也是最重要的是jBPM4支持BPMN。第二是实现了基于流程组件的流程引擎，流程图(语言)与实现解耦，我们使用通用编程语言实现节点运行期行为，称之为流程组件，通过将流程图与流程组件挂接，避免了图的损耗。在这一点上，Tom Baeyens对BPMN到BPEL的转换提出了一针见血的批评：BPMN和jPDL以及XPDL都是基于图的，而BPEL是基于块的，这造成了当将业务人员使用BPMN所建立的流程模型向BPEL执行模型进行转换时，出现许多的不匹配，最初的流程模型会扭曲变形。而扭曲的后果就是业务人员与开发人员之间的协作困难，这影响了流程从业务到技术的实现。第三个好处是我们可以定义领域特定语言（DSL），在特定的应用里，采用DSL约定并隐藏了大部分的技术细节可能做到业务人员对执行流程的直接修改，例如企业文档管理里的审批流程。2. BPMS特性的加入这表现在以下三个方面：第一是支持了BPMN，BPMN已经成为业务人员的流程建模标准；第二是引入了Signavio作为面向业务人员的Web建模器；第三是在已有的Web管理控制台加入了对案例和任务的统计功能。jBPM4的组件如下图3所示：图3：jbpm4组件和jBPM3一样，jBPM4依然是轻量级的、可嵌入的工作流系统。相比jBPM3，它将业务人员作为最终用户之一，增加了部分BPMS特性，同时PVM的引入使得它的可扩展性得到了极大的增强，我们甚至可以定义自己的DSL。在BPMS特性里我们提到了应该避免业务人员的流程建模转换到IT系统时受到损耗，最理想的情况是业务人员与开发人员共用一个流程模型，业务人员能够直接对流程进行调整（在特定应用中，通过DSL是可以做到的）；其次是通过BPMS将业务人员的模型与实际执行的技术模型关联起来（很多商业产品已经做到了这一点，在Activiti5中我们也会看到这一点），业务人员、开发人员以及运营团队之间能够做到很好的协调；最差是业务人员与开发人员各自为政，独立维护各自的流程模型，并且模型之间存在极大的不匹配，此时流程的迅速变化基本上是奢望。3jBPM5jBPM5依旧定位为轻量级的可嵌入的工作流系统。在jBPM5的特性里，有这么两条引人关注：一是引入了Guvnor作为流程仓库，这解决了流程的可视化问题，流程定义作为资源被管理，我们可以对流程定义进行可视化管理以及全文检索（Guvnor使用了Jackrabbit作为了其存储实现，但我们的经验表明Jackrabbit在大数据量情况下性能存在严重问题）；第二是规则引擎(Drools Expert)、事件处理引擎(Drools Fusion)与流程引擎的合三为一，这是jBPM5最让人期待的地方。jBPM5的组件如下图4所示：图 4：jbpm5组件规则引擎在流程中的应用已经非常广泛了，我们这里说说事件处理引擎。事件处理引擎是业务活动监控（BAM）的基础，BAM的功能及执行过程，如下： 捕获：BAM捕获各种事件（通过消息监听器、适配器、代理等）。这些事件来自应用、系统软件、外部交易伙伴。消息是BAM的核心它们反应底层业务流程的状况。 过滤：BAM过滤掉没有直接后果的事件，在很多情况下由支持事件流处理（Event Stream Processing，简称ESP）或复杂事件处理（Complex Event Processing，简称CEP）引擎来进行过滤。 分析：BAM根据分析模型和规则将相关事件联系起来。 警告：BAM向用户提出警告，以便用户在必要时进行控制。如上所示，BAM的执行过程包含四个步骤，而前三个步骤都是对事件进行相关的处理（捕获事件、过滤事件、分析事件、关联事件），因此在大多数BAM的技术实现方案中，都基于CEP和ESP的引擎来实现BAM的功能。与jBPM4相比，jBPM5对PVM的放弃也带来了几个不小的问题：第一是对开发人员来说只支持BPMN，不再支持jPDL（当然提供了迁移工具）；第二是流程执行的可扩展性回到了jBPM3的年代，仅仅支持自定义动作（相当于jBPM3里的Action）。此外，Web建模器由Signavio替换为了Oryx Designer。总而言之，jBPM5通过引入流程仓库和BAM继续向BPMS迈进（目前的进展是与流程仓库的集成还未完成，BAM基于日志进行分析），同时，由于不再支持PVM和jPDL，带来了流程扩展性的降低和社区开发人员的未来流失。4. Activiti5activiti5是Tom Baeyens加入Alfresco后推出的新的基于jBPM4的开源工作流系统，发布的第一个版本。Activiti的开发团队相比与jBPM强大了许多，有23位核心开发者。当然这也是由于activiti规划的功能所致：包括核心引擎、Web的流程建模器、协作工具Activiti Cycle、Activiti Probe、Activiti Explorer、与Spring的集成、与Mule的集成等。图 5：Activiti5的组件如上图所示，Activiti5由三种类型的组件组成，分别是：专用工具（Dedicated Tools）、内容存储工具（Stored Content）和协作工具（Collaboration Tool）。专用工具包括以下： AlfrescoAlfresco公司的企业级内容管理产品Alfresco 是一个开源的、企业级的内容管理系统，功能包括：文档管理、协作、记录管理、知识库管理、Web内容管理等功能。Alfresco与Activiti的深入集成实现了流程及相关文档的可视化。更重要的是Alfresco支持组织模型，能够提供在组织结构内进行不同层次之间的流程导航。 Activiti Modeler建模器基于开源Signavio Web流程编辑器的一个定制版本，提供了对BPMN2.0图形化规范的支持，建模后的流程以文件格式进行存储。 Activiti DesignerEclipse插件形式的建模器 Activiti probe管理及监控组件对流程引擎运行期实例提供管理及监控的Web控制台。包含部署的管理、流程定义的管理、数据库表的检视、日志查看、事务的平均执行时间、失败多次的工作等功能。 Activiti Explorer任务管理组件提供任务管理功能和对案例、任务基于历史数据的统计分析（报表）功能。Web应用程序。内容存储工具：包括了文档仓库、模型仓库、SVN仓库、MVN仓库和Activiti引擎。其中文档仓库、SVN仓库和MVN仓库三个组件为协作工具（Activiti Cycle）提供底层的支撑。Activiti引擎则是以前的PVM。协作工具：与jBPM4相比，Activiti5最令人瞩目的特性就在于它的协作工具组件。Activiti Cycle完全是一种新类型的BPM组件。它是一个用来促进业务人员、开发人员和IT运营人员协作的Web应用程序。 在现实的场景中，业务文档有业务人员所持有，而软件程序由开发团队所管理，被部署的软件应用则被IT管理人员所管理。三者之间不能很好的协作。我们可以想象这样一个场景，业务经理用文档来维护需求和visio格式的流程图，开发人员管理可执行的流程和大量的Java源文件而IT维护人员则管理部署在Tomcat中的.war文件和存储在Activiti数据库中的流程。图6：Activiti Cycle协作组件逻辑示意图Activiti Cycle通过BusinessLink将与流程相关的业务人员、开发团队与IT维护人员关联起来，实现他们之间的协作。总而言之，与jBPM4相比，Activiti5目前最重要的增强就是实现了流程的可视化以及创新的Activiti Cycle协作组件，此外，通过与Mule的集成加强了其集成能力。其对PVM的保留使其继承了jBPM4强大的可扩展能力，对jBPM的老用户来说，这是向其迁移的重要理由。5微软工作流微软工作量架构图微软工作流状态机工作流状态机工作流概述 工作流本身由一组状态组成。 存在一个初始状态。 每个状态都可以接收一组特定事件。 视时间而定，可以转换到另一个状态。 状态机工作流可以有最终状态。 当对最终状态进行转换时，工作流将完成。微软工作流-状态机的相关活动状态机执行相关活动微软工作流-WF的通信WF通讯概述 Windows Workflow Foundation 通信服务使工作流能够使用方法和事件通过消息与外部系统交互。 事件用于将数据发送到工作流，而工作流使用方法将数据发送到主机应用程序。通过事件与工作流进行通信的功能提供了一种将数据发送到工作流的异步方式。WF页面及表单设计(以某一个业务为例)1 新建业务流程2 配置流程节点3 流程监控与管理4 流程催办自动获取流程的处理节点及处理人，点击发送短信，可以手动发送提醒信息6小结jBPM3是一个完整的工作流系统实现，面向开发人员，目的在于简化对组织核心流程进行支撑的软件创建，不支持标准。jBPM4引入PVM，使其拥有更强大的扩展性，同时增加BPMS特性，这些特性包括了对BPMN的支持、面向业务人员的Web建模器和简单统计分析功能的加入。jBPM5基于原先的Drools Flow，支持BPMN，通过与Drools的合并支持BAM，通过内容仓库增加对流程可视化的支持。由于放弃了jBPM4的PVM，引擎的可扩展性受到损害，并且不再支持jPDL。Activiti5基于jBPM4，与Alfresco的集成增加了其流程可视化与管理能力，同时通过创新的Activiti Cycle协作组件支持流程相关人员之间的协调，最后，它加强了集成能力。对于工作流应用或者jBPM3、jBPM4的老用户，建议转向Activiti5。四、 基于Web服务的工作流管理系统4.1概述将Web服务引入工作流系统可以从以下三个方面提高工作流系统的性能。（1） 工作流的活动可以用Web服务实现。在传统的工作流管理系统中，每个企业的工作流干礼系统是一个信息孤岛，他只能调用自己企业内部的应用。但是在引入Web服务后，可以不再自己实现活动，而调用网络上功能相同的Web服务来实现流程活动，不但节约成本，而且缩短了开发周期。把Web服务作为流程定义时绑定某个特点的应用，只需说明相应的Web服务接口类型。只要服务提供的Web借口类型相同，就可以动态替换应用。这对流程实现来说更加灵活，企业可以动态的选择合作商，选择自己需要的服务质量。（2） 将流程发布为Web服务，流程一旦成为Web服务，其他企业的计算机系统便可以在Internet环境下通过程序动态的访问企业内部的工作流服务。这对于合合作双方来说，不仅交互方式更加灵活，交易成本也降低很多。（3）用Web服务实现跨组织的工作流。Web服务本质上来说是一种通过XML文档传递消息的应用集成技术，其互操作性特别好。用Web服务实现跨组织工作流可以充发挥Web服务互操作好的优点，非常容易的实现跨组织的工作流。同时它与前面的两个应用结合，把跨组织的工作流做为Web服务，实现了流程的合成和递归定义，使工作流系统的功能更为强大。4.2基于Web服务的工作滚模型工作流模型是业务流程的计算模型，即业务流程的可被计算机处理的形式化表示。工作流模型的创建有利于业务流程的分析。评价和优化，以及最后借助于计算机进行自动处理。工作流管理系统中使用可视化流程定义工具来帮助创建工作流模型。基本上，1个工作流应用由三种元素构成：任务、参与者和限制。这三个部分验全部特性体现了工作流应用的本质。任务制定了要做的工作，参与者完成这项工作，而限制则控制着工作的正确执行。图41显示了工作流的构成元索和它们之间的关系。 4.2.1 符合Web服务的工作模型传统工作流模型的不足：静态约束性差，可重用性和互操作性差，缺乏对Internet分布式环境的支持。因此将Web暇务引入工作流系统。Web服务在Interne立分布式环境下，动态发布、发现和集成应用的特点，使得对工作流系统的性能有很大的提高。传统的工作流模型主要是在企业内部的单一环境下运用，较少考虑到异构环境和跨组织流程，因而不适合基于Web服务工作流模型。我们将传统的工作流模型进行改进，方便Web服务在工作流系统中的应用。图42是改进工作流概念的模型。4.2.2 基于Web服务的工作流管理系统基于上述的工作流模型，这里提出基于Web服务的工作流管理系统的体系结构如图43所示。整个系统的工作流程如下所述：。(1)用户用某一种形式化方法来抽象自己的业务流程，比如，可以用UML，Petri网等工具进行抽象。确定自己的业务模型。（2)根据抽象出米的业务模型，用可视化建模工具进行具体的建模。具体建模过程如下所述。首先根据其体静工作选取适当类型节点，如果节点完成的工作是调用本地的应用，则节点可以选择普通节点；如果节点完成的任务需要用到远程的Web服务，则调用可视化建模工具中的Web服务搜索模块来匹配适当的Web服务、（3)流程建立完毕，调用建模工具中的模型检查功能对建立的模型进行正确性检查，此时，将会检查出活动之间的匹配问题以及流程逻辑上正确性。(4)建模完成后，通过系统中的建模接口，可以将建好的模型保存到相应的工作流信息库中。 (5)用户在客户端发起某个任务启动请求，服务器的执行接口接到用户的请求后，根据用户所做工作的性质，调用相应的模块。引入Web服务后，工作流机的调度策略应发生相应的变化，以适应Web服务的功能需要。下面给出工作流机的调度算法。 (I)创建一个流程的实例时，找出所有的起始活动节点，找到关于起始活动节点的信息与之关联，并执行起始节点。从此时开始，每当一个活动结束返回时就必须进行路由。 (2)当一个活动结束返回时，计算活动的结束表达式的值。如果结束条件为False，则是用相同的输入在选定的服务提供者上重复执行该活动的实现;如果表达式的值为True，则活动完成。 (3)如果所有的活动都结束了，则流程执行完毕，返回流程的执行结果。否则，继续执行流程的下列步骤。 (4)找出所有当前完成的活动的后继节点执行布尔表达式。 (5)计算这些布尔表达式的值。 (6)确定这些布尔表达式中形参的实际值。 (7)找出所有后继节点中执行表达式值为真的节点，它们是下一步可能要执行的活动的集合。我们要从中选出下一步执行的活动，标上enable。 (8)把目标活动中所有非同步节点转移条件为真的节点标上enable。 (9)计算同步节点的同步条件表达式的布尔值，把目标活动中所有同步条件为真的活动标记为enable。 . 获得每个enable活动的输入消息: . 确定所有指向该活动的数据链接 .确定与数据链相连的源活动的输入消息或该消息中作为数据映射源的那一部分数据 把这些数据映射到所有enable活动输入消息。 (10)匆启动所有标上enable状态的活动，如果活动实现为系统的内部的应用，则运行相关的应用。 (11)如果活动的实现为外部的Web服务，则执行下述步骤。 .确定相关的服务定位器 .计算服务定位器的值 .选择实际的服务提供者进行绑定 . 调用相关的Web服务 （12)到步骤2进行流程路由。 下面介绍其中主要部件的功能以及实现方法。 （I)可视化建模工具:这是整个系统的关键部件之一。功能应该有以下几个方面。 a)定义工作流程 b)定义活动 c)定义节点 d)定义节点属性包括节点类型、入口参数、出口参数、触发逻辑、流转逻辑和业务条件等)。e)指定活动与节点的绑定f）正确性检查 g)设计合适的服务样式的结构 h)选用恰当的Web服务查找机制查找服务实例 i)采取某种策略从查找结果中选择一个Web服务 j)解决这个Web服务和工作流中其它的任务的结构和语义的不一致问题，