动态业务工作流引擎Superflow研究概要之三-----应用模型

第四章                           应用模型

本人研究了多年的工作流引擎技术，颇有一些心得，愿意把这些点滴的积累奉献出来，与大家共享。
本人研究了多年的工作流引擎技术，颇有一些心得，愿意把这些点滴的积累奉献出来，与大家共享。

是什么使得我如此的狂热？

                                                   -------------一幅凝固的油画。msn: gongfs@163.com. qq:279524300
                                                   -------------一幅凝固的油画。msn: gongfs@163.com. qq:279524300

                                                 

§4-1    工作流系统诠释

在设计工作流应用模型之前，我们有必要对工作流系统作一般意义上的诠释。

§4-1-1  工作流无处不在

企业的运作过程本质上是人、财、物等资源的优化和合理配置，形式上无一不体现为信息流、资金流、物流、价值流等合理的流动。

随着社会分工的日益具体化，合作已成为主题。合作的体现形式必然是一个完整而高效的工作流程，因而工作流无处不在。

§4-1-2    工作流与工作流管理系统

关于工作流与工作流管理系统有不同的说法，但基本上都强调工作流首先是一个动态的过程，同时它应该具备协同工作的能力：

l         工作流是针对工作中具有固定程序的常规活动而提出的一个概念，通过将工作活动分解定义良好的任务、角色、规则和过程来进行执行和监控，达到提高生产组织水平和工作效率的目的。一个工作流包括一组活动及它们的相互顺序关系，还包括过程及活动的启动和终止条件，以及对每个活动的描述。工作流管理系统指运行在一个或多个工作流引擎上用于定义、实现和管理工作流运行的一套软件系统，它与工作流执行者（人、应用）交互，推进工作流实例的执行，并监控工作流的运行状态。

l         1993年，国际工作流管理联盟（Workflow Management Coalition,WFMC）的成立标志着工作流技术开始进入相对成熟的阶段。为了实现不同工作流产品之间的互操作，WFMC在工作流管理系统的相关术语、体系结构及应用编程接口等方面制定了一系列标准，工作流管理联盟给出的工作流定义是：工作流是指整个或部分经营过程在计算机支持下的全自动或半自动化，在实际情况中可以更广泛地把凡是由计算机软件系统（工作流管理系统）控制其执行的过程都称为工作流。为了实现组织目标，有关业务活动依时序或逻辑关系相互连接构成业务流程。在业务开展过程中，文档、信息或任务，依据组织规范在参与者之间传递、处理或执行。

工业界的许多人将工作流管理奉为21世纪的软件技术。近年来，工作流技术得到长足的发展。WFMC成立之后，颁布了一系列工作流产品标准，包括工作流参考模型、工作流术语表、工作流管理系统各部分间接口规格、工作流产品的互操作性标准等。这些举措加速了工作流技术的商品化。现在，许多公司都基于这些标准推出了自己的工作流产品，如Action Technologies Inc.的ActionWorkflow、IBM的FlowMark等。Lotus Notes等群件产品也具备较强的工作流支持功能。

§4-1-3    工作流管理系统的实施

工作流管理系统在实际系统中的应用一般分为三个阶段：即模型建立阶段、模型实例化阶段和模型执行阶段。在模型建立阶段，通过利用工作流建模工具，完成企业经营过程模型的建立，将企业的实际经营过程转化为计算机可处理的工作流模型。模型实例化阶段完成为每个过程设定运行所需的参数，并分配每个活动执行所需要的资源，模型执行阶段完成经营过程的执行，在这一过程中，重要的任务是完成人机交互和应用的执行。

§4-1-4    工作流管理系统的优点

工作流最大的优点是实现了应用逻辑与过程逻辑的分离，因此可以在不修改具体功能的实现情况下，通过修改过程模型来改变系统功能，完成对生产经营部分过程或全部过程的集成管理，有效地把人、信息和应用工具合理地组织在一起，发挥系统的最大效能。工作流技术可以支持企业实现对经营管理和生产组织的过程控制以及决策支持，实现现代企业对“在适当的时间把适当的信息传给适当的人”的要求。此外，工作流还具备下述优点：

l         改进和优化业务流程，提高业务工作效率；

l         实现更好的业务过程控制，提高顾客服务质量；

l         提高业务流程的柔性等。

§4-1-5    工作流管理系统的适用领域

工作流无处不在，因而工作流技术具有广阔的应用的前景。尤其是在当前敏捷制造、并行工程、企业经营过程重组得到企业广泛的认同和重视的情况下，工作流技术可以在以下的一些应用领域得到应用并发挥重要作用。

l         并行工程              工作流技术可以很好地用于产品开发过程的建模和管理，它也可以作为产品协同设计、产品设计中的冲突协调、产品数据管理与流程控制的支撑系统。在这一领域的应用中，需要增强工作流对产品数据及其相关集成文档的描述能力，并且需要在工作流技术融入CSCW的技术和方法。

l         敏捷制造              工作流技术可以作为企业间信息集成的使用工具，基于WEB和基于邮件方式的工作流管理系统可以为企业灵活地组建动态联盟和实现信息交换发挥重要作用。在这一应用领域中，要充分考虑广域网环境下系统之间信息传递的可靠性问题，以及不同工作流系统之间的互操作和重构问题。

l         供应链管理           工作流管理技术可以较好的用于实现供应链建模和管理功能，结合工作流仿真和优化技术，还可以用于进行企业分销体系的优化，需要加强工作流模型的仿真与优化能力。

l         企业经营过程重组       这是工作流技术应用的主要领域。虽然工作流管理为系统的重构提供了必要的手段，但是要真正实现企业经营过程的快速重组，企业的应用系统需要按照组件的方式进行构建或改造，而且对应用组件的粒度要求应该与过程重组所需的灵活性相匹配。即灵活性要求较高，应用组件的粒度应该越小。

l         企业建模与系统集成           以工作流模型为核心，从功能、信息、组织与资源视图为辅助手段研究集成化的企业建模方法，并开发相应的集成化企业建模工具。在进行这方面的研究工作时，要重点解决不同视图模型之间的集成问题和模型的一致问题，在此基础上，可以建立以工作流管理系统为基础的集成平台和集成框架软件，从而实现方便、快捷、灵活的应用系统集成。

工作流技术综合了计算机科学和管理科学中诸多研究领域的原理、方法和技术，如：数据库管理、面向对象技术、C/S技术、汇编语言、图形化用户界面、系统集成、消息传递、文档管理、防真等等。近些年，企业对过程建模、BPR工具、敏捷制造、并行工程的需要为工作流技术的应用提供了一个广阔的市场，使工作流产品得以迅速发展。同时，工作流产品供应不断将信息技术、WEB技术等研究中的最新研究成果应用也自己的产品开发中，促进了它的普及应用。虽然目前的工作流产品还存在很多问题有待解决，但是随着工作流技术的进一不发展，它必将在提高企业的效率和竞争力，使企业更好地适应市场变化等方面起到举足轻重的作用。

 
 

 

 

§4-1-6    工作流管理系统的应用案例

l         福特汽车公司的采购过程

福特汽车公司通过对采购过程的重组，结果财务部门的员工下降到125人，而且工作效率大大提高。

l         波音飞机制造公司的企业经营过程重组

波音公司是世界上最大的民航喷气飞机制造商，也是应用CIM哲理和BPR理论进行企业经营重组的超大型企业。20世纪90年代末期，波音公司进行大规模企业经营过程重构，投巨资重构工作流管理系统，产生了难以估量的经济效益。

l         沈阳飞机制造公司的企业经营过程重组

沈阳飞机制造公司是我国航空飞机制造行业四大骨干企业之一。企业开展BPR之后，明显提高了企业的生产制造综合能力，年增长产值近2000万元。直接及潜在经济效益异常显著。

l         美国WHIRLPOOL公司重构产品开发过程

美国WHIRLPOOL公司是生产家用和商用仪器的大型公司。公司在实施BPR的过程中，系统地分析了整个产品开发过程，在确保产品质量和可靠性的前提下，节约了大量资金，并使产品开发周期由原来的4年零5个月缩短为2年零10个月。经济效益十分可观。

 
 

 

 

§4-2      功能模型设计的普遍性原则

§4-2-1    目前工作流系统的弊端

同Superflow相比，目前工作流管理系统存在下述问题：

l         实施困难                            国际工作流管理联盟（Workflow Management Coalition，WFMC）定义了完整意义上的工作流体系结构及操作标准。且不说根据WFMC的结构和标准研制工作流管理系统多么复杂和庞大，其浩瀚的实施过程也难以令大部分企业接受。

l         开发难度大                  根据WFMC的描述和标准，工作流管理系统是一个非常浩大的系统工程。而且实际操作过程之中，研发者往往把所谓过程逻辑和应用逻辑捆绑在一起，造成面对不同需求的重复开发。

l         缺少可维护性                     一旦企业实施了工作流管理系统之后，用户必须根据开发商提供的过程描述语言编写流程脚本，这本身对于用户而言就是件困难的事情。如果需求发生变化，用户不得不再次面临尴尬境地。况且目前可见的所谓工作流管理系统大都不具备这种能力。

l         系统缺乏弹性                     企业会根据市场的变化不断的修改和重组业务流程，甚至完全否定以前的业务运作模式，或者新增业务流程。目前见到的工作流管理系统未能真正做到流程重组，充其量只是在某些特定环节做一些应用层面的微调而已。

 
 

 

 

§4-2-2    功能模型的设计目的

l         完整反映工作流应用需求原貌

l         维系工作流管理系统的弹性架构

l         指导并且规范开发过程

§4-2-3    功能模型的设计方法

§4-2-3-1工作流管理系统的功能支持

工作流管理系统（Workflow Management System，WFMS）是定义、创建、执行工作流的系统。在最高层上，WFMS应能提供以下三个方面的功能支持：

l         建造功能                     对工作流过程及其组成活动定义和建模。

l         运行控制功能              在运行环境中管理工作流过程，对工作流过程中的活动进行调度。

l         交互功能                     指在工作流运行中，WFMS与用户（业务工作的参与者或控制者）及外部应用程序工具交互的功能。

 
 

 

 

§4-2-3-2 工作流管理系统的主要构成

工作流管理系统（Workflow Management System，WFMS）主要由下列部件构成。

l         过程定义工具      

过程定义工具被用来创建计算机可处理的业务过程描述。它可以是形式化的过程定义语言或对象关系模型，也可以是简单地规定用户间信息传输的一组路由命令。

l         过程定义

过程定义（数据）包含了所有使业务过程能被工作流执行子系统执行的必要信息。这些信息包括起始和终止条件、各个组成活动、活动调度规则、各业务的参与者需要做的工作、相关应用程序和数据的调用信息等。

l         工作流执行子系统（WES）和工作流引擎

工作流执行子系统也称为（业务）过程执行环境，包括一个或多个工作流引擎。工作流引擎是WFMS的核心软件组元。它的功能包括：解释过程定义；创建过程实例并控制其执行；调度各项活动；为用户工作表添加工作项；通过应用程序接口（API）调用应用程序；提供监督和管理功能等。工作流执行子系统可以包括多个工作流引擎，不同工作流引擎通过协作共同执行工作流。

l         工作流控制数据

指被WES和工作流引擎管理的系统数据，例如工作流实例的状态信息、每一活动的状态信息等。

l         工作流相关数据

指与业务过程流相关的数据。WFMS使用这些数据确定工作流实例的状态转移，例如过程调度决策数据、活动间的传输数据等。工作流相关数据既可以被工作流引擎使用，也可以被应用程序调用。

l         工作表和工作表处理程序

工作表列出了与业务过程的参与者相关的一系列工作项，工作表处理程序则对用户和工作表之间的交互进行管理。工作表处理程序完成的功能有：支持用户在工作表中选取一个工作项，重新分配工作项，通报工作项的完成，在工作项被处理的过程中调用相应的应用程序等。

l         应用程序和应用数据

应用程序可以直接被WFMS调用或通过应用程序代理被间接调用。通过应用程序调用，WFMS部分或完全自动地完成一个活动，或者对业务参与者的工作提供支持。与工作流控制数据和相关数据不同，应用数据对应用程序来讲是局部数据，对WFMS的其他部件来说是不可见的。

§4-2-3-3 工作流管理系统的参考规范

国际工作流管理联盟（Workflow Management Coalition，WFMC）定义了一套完整的参考规范，主要由5个接口构成。

构建工作流管理系统的过程是一个遵循规范和标准的过程，也是一个不断创新的过程。

一、工作流定义交换

（1）工作流定义交换模型

模拟和定义工具与工作流管理软件之间的接口被称为过程定义输入／输出接口。接口的本质是一个交换格式和一组API调用，它通过一系列物理或电子的媒介进行处理过程定义的交换。定义交换可以完整的或部分的（如只改变某个定义中的某个活动的属性）。

图4-2-3-3-1   工作流定义交换接口

使用这种标准化的形式有明显的好处

l         它在build-Time和runtime之间定义了一个分隔点，使一个工具产生的定义可以用于多个不同的工作流产品，这样，用户可以自由地选择工作流产品。

l         它可以将一个过程定义用于几个协作的工作流产品，实现分布的工作流服务（交换过程定义只是这种分布服务的一个方面)。

  WFMC在这一领域作了两项工作 

l         引出一个元模型，它用于在一个处理过程定义中表示对象及其关系和属性，也可以形成用于产品之间信息交换格式的基础。

l         工作流系统之间或工作流系统与定义工具之间的API调用，提供了一个访问工作流过程定义的公共途径，访问方式可以是只读、读写或只写，并且在元模型或一个特定的产品集（如注册产品）中操作标准对象的定义。

（2）一个基本的元模型

WFMC开发了一个处理过程定义的元模型，它用来确定一组（简单的处理过程定义中初始水平的交换的）基本的对象模型，其他的对象模型由供应商提供或作进一步的探讨。

图4-2-3-3-2   工作流定义交换接口

假定下面的类型有这样一些属性：

工作流类型定义

       工作流处理过程名称

       版本号

       处理过程的开始和结束条件

       安全、审计和其他控制数据

活动

       活动名称

       活动类型（子流、自动流等等）

       活动的开始和结束条件

       其他时序的约束

转换条件

       流或执行条件

工作流相关数据

       数据名称和路径

       数据类型

角色

       角色名称和组织实体

调用的应用程序

       应用程序类型和名称

       参数

       位置或访问路径

       在分布的服务中，工作流引擎中的活动的分配要在处理过程定义中指定（作为活动的一个属性）。处理过程的定义涉及到安全和管理，如过程中受特权控制和超级用户管理的活动，同时也要考虑其他方面。

       在定义交换格式中，假定可以将一个模糊的符号命名方案映射到runtime核心服务的真实名称和地址。这可能需要动态地址机制来处理（如通过目录服务），或通过其他处理过程定义之外的机制处理。有其他的工业组织正在从事这方面的工作，如处理的模拟和CASE交换工具；WFMC的方案是同其他组织共同努力下产生的。

（3）访问处理过程定义的API

WAPI中的一组API是用来访问处理过程定义数据的。期望这些规范能覆盖下面的普通类型。操作一个列表、单独的对象或属性的命令没有提供。

会话的建立

       在参与的系统之间建立/断开会话

工作流定义操作

       从一个仓库或其他资源列表中获取工作流处理过程定义的名称的清单

       从提供给会话处理的处理过程定义清单中，选择/排除一个定义

       读写最高层的工作流处理过程定义对象

工作流定义对象操作

       在工作流定义中创建、获取和删除对象

       获取、设置和删除对象的属性

工作流客户端功能

工作队列处理程序直接同系统的使用者打交道，它可能会作为一个工作流产品一部分来提供，或由用户自己编写，也可能与办公室服务一起集成在一个桌面环境中，如邮件和work-in-progress文件夹，以提供一个任务管理系统。因此，在工作流核心服务与工作流客户端应用程序之间需要一个灵活的通讯机制，以支持由不同操作系统构成的工作流系统。

在工作流模型中，客户端应用程序于工作流引擎之间通过一个接口进行交互操作，这个接口使用了工作队列的概念 - 有工作流引擎赋给特定用户的工作单元的队列。最简单的情况下，工作队列可以被工作流引擎访问，以便赋给用户待处理的工作单元并获取用户处理的结果。工作队列的交互也有其他不同的产品实现途径。

从工作队列中激活一个工作单元可能在工作流客户端应用程序或用户的控制之下进行。在工作流客户端应用程序和工作流核心服务之间定义了一组过程，可以用来向队列中添加工作单元、从队列中移走完成的工作单元或挂起正在活动的工作单元等等。

工作队列处理程序也处理应用程序的调用，这些处理或是直接进行或是在用户参与下进行。由工作队列处理程序直接调用的应用程序最好放在本地环境中，虽然没有强制性的约束。

工作队列中，一部分活动的相关数据可以帮助工作队列处理程序调用应用程序。如果一个应用程序的数据类型非常固定，工作队列中就会存储一个关联。其他情况下，工作队列处理程序与工作流引擎之间需要完整的（应用程序名称和路径的）交换，这时，工作流客户端应用程序可以通过应用程序调用接口（接口3）实现一些功能，以获取必要的信息。

一个工作队列中可能包含了多个不同的活动实例，这些实例可能来自不同的处理过程。（根据不同的产品实现途径，每种类型的处理过程使用单独的物理工作队列，或者由工作队列处理程序将不同的工作队列的单元以统一的形式表达给用户。）

因此，客户端工作流应用程序与工作流引擎之间的接口必须在以下方面具有足够的灵活性：

       处理过程和活动的标识符

       资源的名称和位置

       数据的引用和数据结构

       可选的通讯机制

二、工作流客户端应用程序接口

满足上面要求的途径包含多个标准的API集（WAPI），这些API以统一的方式被应用程序、工作流引擎和工作队列访问，而不管实际的产品是如何实现的。

这些API及其参数将映射到不同的通讯机制以适应不同的工作流实现机制。（在基于电子邮件的通讯中，工作队列处理程序可以通过如何本地邮箱访问接口直接访问收件箱，而不是通过WAPI调用。这种情况下，工作队列处理程序将负责过滤所有非工作单元的邮件，并作适当的处理。同样，对工作流引擎的命令或响应可以直接放到发件箱中。这样，通过邮件交换格式实现了一个简单的交互，而没有完全使用WAPI。）

图4-2-3-3-3   客户端应用接口

客户端应用程序API的全部的实现途径如图4-2-3-3-3。

API的规范出版在另一个WFMC文档中；下面只提供一个关于客户端应用程序使用的API的概要。一起提供的还有操作处理过程或活动实例以及操作工作队列的命令。

会话的建立

       在参与的系统之间建立/断开会话

工作流定义操作

       获取或查询工作流处理过程定义的名称或属性

处理过程的控制功能

       创建/启动/终止一个处理过程实例

       挂起/唤醒一个处理过程实例

       在一个处理过程实例或活动实例内部强制状态的转换

       修改或查询一个处理过程实例或活动实例的属性（如优先级）  

处理过程状态功能

       打开/关闭一个处理过程或活动实例的查询，设置过滤标准

       获取处理过程或活动实例的详细资料，并按指定的条件过滤

       获取指定的处理过程或活动实例的详细资料  

工作队列/工作单元处理功能

       打开/关闭一个工作队列查询，设置过滤标准

       获取工作队列单元，，并按指定的条件过滤

       选择/重赋值/完成一个工作单元的通知

       修改或查询工作单元的属性  

处理过程的超级用户功能  

下面的功能面向所有的处理过程或活动实例，并且是在超级用户的特权下才能获得的，或许需要特定的应用程序和用户登录。）

       改变正在运行的工作流处理过程定义及其实例

       改变所有指定类型的处理过程或活动实例的状态

       改变所有指定类型的处理过程或活动实例的属性

       终止所有过程实例  

数据处理功能

       获取或返回工作流相关数据或应用程序数据  

管理功能

可以通过某种客户端应用程序实现由WAPI支持的附加的管理功能。

应用程序调用

通过工作队列处理程序的功能（如提供对处理过程／活动／工作单元属性和工作流相关数据的访问）实现了基本的应用程序调用支持。其中一些应用程序调用功能与客户端应用程序环境有关。

然而，许多工作流系统限制了它们能处理的应用程序的范围，这些应用程序的数据必须是强类型的而且必须能够直接访问（如通过目录），例如字处理或电子表格程序。其它情况下，可以通过标准的金矿机制来调用应用程序，如OSI TP协议或X.400。有些系统的实现中使用了“应用程序代理”的概念，它将应用程序的调用方法同工作流核心服务隔开。也可以通过使用标准API开发工作流应用程序工具于工作流核心服务通讯（接收应用程序数据、发出或接收活动事件等）。这些API可能直接被应用程序工具或应用程序代理使用，作为没有工作流知识的开发者的一个前端。

一些可以用于应用程序调用的接口类型

应用程序调用接口

接口类型	工作流相关数据访问	参考标准
本地处理过程调用	本地文件	没有
Shell脚本	本地文件	POSIX环境？
ORB调用	通过引用（调用参数）	有
远程执行调用	通过引用（调用参数）	有
消息传送（如X.400）	内置或通过引用	有
交易（如OSI-TP）	内置或通过引用	有

进一步讨论将要涉及应用程序调用的所有可能的范围了。WFMC初始的工作着重考虑开发一组接口类型和一些将来用于工作流专用应用程序的API。

三、应用程序调用接口

图4-2-3-3-4显示了接口的框架，适用于应用程序代理和工作流应用程序。

在简单的情况下，应用程序调用都在本地发生，并且使用处理程序定义中的信息（应用程序类型和相关数据）。调用的应用程序可能在本地，也可能在网络上能访问到的其他位置。处理过程定义中包含了足够的应用程序类型和位置信息（工作流引擎需要的）。此时，应用程序命名和地址对处理过程定义和工作流引擎来说是本地的。

应用程序调用API的语法将由WFMC研究并作为规范收入文档。操作将通过几个接口进行（包括上表中的），有些是同步的、有些是异步的。目前，API的操不考虑是单线程或是多线程（将来会考虑区分线程）。下面提供了应用程序调用可能会用到的命令集。

图4-2-3-3-4   应用程序调用接口

会话的建立

       建立/断开应用程序（或应用程序代理）会话

活动管理功能

（工作流引擎到应用程序）

       启动活动（工作流引擎到应用程序）

       挂起/唤醒/终止活动（用于异步应用程序接口）

（应用程序到工作流引擎）

       活动完成通知

       产生事件（如同步）

       查询活动属性

数据处理功能

       给出工作流相关数据（应用程序的前驱和后继活动）

       给出应用程序数据或数据地址

在更复杂的情况下，包括在不同类型的工作流引擎之间的交互操作，可能需要在工作流引擎之间传诵应用程序调用信息，或者是在运行时通过交换获得，或者是在导入过程定义时获得。

四、协作能力抽象规范

（1）简述

这是一个WFMC标准，它提供了一个抽象的规范用以定义要求不同的工作流引擎间的协作能力的功能。WFMC的一个主要目标是制定工作流系统的标准，以使不同的工作流产品之间可以平滑地交换工作单元。

工作流产品的特点是多种多样的。在制定协同能力标准时，WFMC没有要求工作流产品供应商放弃产品特有的功能性去提供交互能力。因此，WFMC致力于开发一系列交互方案，以满足不同层次的交互（从简单的任务传递到过程定义、工作流相关数据的交换以及完整的工作流应用程序交互）。这种情况下，初始的要求是要支持简单的交互，随着情况的复杂化，在作更多的工作。

虽然可以考虑开发非常复杂的交互方案，使不同供应商提供的引擎之间协作，提供统一的核心服务，这在目前似乎还不能实现，因为这要求所有引擎都能解释公共的处理过程定义，并且它们之间要共享工作流控制数据，以维护在不同的工作流控制引擎之间共享的处理过程状态视图。当前比较现实的目标是实现在不同的核心服务之间传送处理过程。

（2）一些基本概念

工作流协作能力：两个或更多的工作流引擎之间的通讯和协作能力。其目的是整理执行工作流程实例通过这些引擎。

工作流引擎：一个为工作流程实例提供运行时刻的执行环境的软件服务（引擎）。

一个工作流流程定义实例：一个工作流流程定义的实例（包括其自动化部分在内），它是由工作流管理系统创建和管理的。

一个工作流管理系统：通过软件的执行完整的定义，管理，执行工作流流程。此执行的软件命令是由工作流流程逻辑的一个计算机表示来驱动的。

一个工作流管理系统是由一个或更多的工作流设定服务组成。

一个工作流设定服务是由一个或更多的工作流引擎组成的。

（3）协作能力模型

WFMC定义了大量的协同工作能力的模型，如：

l         两个或更多的工作流引擎直接协作

 
 

 

 

 
 

 

 

图4-2-3-3-5   工作流引擎协作

 
 

 

 

l         两个或更多的工作流引擎在同一个设定服务里的运作

图4-2-3-3-6   工作流设定服务

 
 

 

 

l         在一个工作流管理系统范围内的两个或更多的工作流设定服务的协作

图4-2-3-3-7   工作流群组设定服务

l         协作能力的实现

两个软件工具的协作能力一般通过如下几种方式实现：

工具间的直接作用

图4-2-3-3-8   工具间的直接作用

消息传递

图4-2-3-3-9   消息传递

 
 

 

 

此方式在工作协作能力上的应用：

图4-2-3-3-10        工作流协作的消息传递

 
 

 

 

中介（bridging） (采用封装，转化及网关等形式)

图4-2-3-3-11         中介

 
 

 

 

此方式在工作协作能力上的应用：

图4-2-3-3-12    工作流协作的中介应用

共享存储数据

图4-2-3-3-13        工具间的共享数据存储

（4）作流流程在两个协作的引擎里执行的不同方式

链式流程

图4-2-3-3-14        链式流程

嵌套子流程

图4-2-3-3-15    嵌套子流程

  同步并行

图4-2-3-3-16        同步并行

交叉执行

图4-2-3-3-17    交叉执行

 
 

 

 

 
 

 

 

五、WFMC审计数据规范

（1） 概述

WFMC的最终目标是规范一个管理和监视功能的接口标准，通过这个接口，商家的管理应用程序可以同其他的引擎一起工作。这样，几个工作流服务可以在一定范围内共享管理和系统监视功能。此接口试图提供一个全局视图，视图中包括组织内部所有工作流动的完整的状态信息；此接口还包括与管理有关的完整的功能集，包括安全、控制和授权的考虑。

接口实现如图4-2-3-3-18所示。

（2）审计数据

审计数据:从发生在一个工作流设定服务期间的各种事件中捕捉和记录的信息。此信息被称为通用工作流审计数据（CWAD）. 通过定义这种数据的语义规范可使接口5标准化，以达到和不同工作流产品工作的能力。

图4-2-3-3-18        系统管理和监控接口

  （3）CWAD 命名协定    

命名将遵循《WFMC的 WAPI命名协定》中的标准说明。另外，新的关于属性的命名协定提议考虑属性的抽象规范。

（4）CWAD 数据信息

CWAD 审计数据由三类信息组成：基础数据，自由数据，私有数据。

基础数据是被记录且对所有的审计功能有效。在这些信息里，有些定义的元素被指定为强制性的或者是可选择的。如果事件被记录，强制性的元素是必须有的。由于工作流商家的产品操作不同，有些审计信息将不适用且将被考虑作为自由数据。除了一些必须信息之外，由私有数据信息组成的是未被定义且对商家和用户的自身需要是有用的，它可以包括复杂的形式。

§4-3      Superflow的功能模型设计

§4-3-1   Superflow的哲学本质

§4-3-1-1抽象与具体

我们认为，企业应用的过程就是一个由具体到抽象，再到具体的过程。这个过程会不断反复、相互作用并不断深入和深刻。这也符合人类认识论“实践——认识——再实践——再认识”的发展规律。 
 

 

 

图4-3-1-1-1     具体—抽象—具体的企业应用过程

 
 

 

 

如图4-3-1-1-1所示，需求具体是企业对客观需求的原始的真实的理解；应用具体是指构建在需求具体之上的企业应用系统。企业应用的本质体现为用户的客观需求具体，它真实地反映了事物的原貌。在此基础之上，经过需求表达、系统分析和设计等手段抽象出企业的应用逻辑。应用逻辑经过代码化加工，成为应用具体。应用具体和需求具体相互作用。需求具体决定了应用具体的内涵和实质，应用具体是客观需求具体的真实反映；应用具体作为企业应用开发阶段性的产物，经过一段时间的稳定运行之后，必然产生应用积累，从而加深企业对客观需求的认识，导致下一个企业应用过程的循环。由于用户需求表达的非精确性以及技术人员分析和设计方法的客观局限性，应用具体和客观需求具体之间必然存在差异。严格说来这一差异必然存在，如何缩小这一差异性是Superflow的研究方向之一。 
 

 

 

§4-3-1-2  运动中的企业客观实体

运动的永恒性告诉我们，一切均为过程，都有其产生、发展和消亡的历史。企业运作过程的一切客观资源等也在不断的发展变化过程之中，反映企业客观实体的需求具体也必然随着企业客观实体的变化而不断修正，从而导致反映需求具体的应用具体的变更和维护。应用具体如何应对需求具体的变化，从而最小化二次开发和维护力度，也是Superflow的研究方向之一。§4-3-1-3  应用具体与需求具体的差异性

如前所述，应用具体和需求具体之间存在必然的差异性。导致这种差异性的原因如下：（1）用户对企业客观实体的认识偏差企业对自身发展规律和业务本质的认识可能存在偏差，导致需求具体的不完善性。（2）用户对需求具体的表达偏差       企业若对正确理解范围之内的需求具体缺乏适当的描述，将给开发者带来误导。（3）开发者对需求具体的理解偏差       开发者若对需求具体理解不当，将在一个不真实的基础之上分析和设计。 
 

 

 

 
 

 

 

图4-3-1-3-1          需求具体与应用具体的偏差

 
 

 

 

（4）开发者分析和设计方法的局限性软件工程学的发展使得系统分析和设计拥有了强有力的武器，但依赖于人类认识自然的程度，无论如何，这一局限性无法彻底根除。（5）需求具体的多变性需求具体是对运动中的企业客观实体的真实反映，因而其内容具备多变性。（6）应用具体的实践积累应用系统经过一段时间的运行积累之后，必然对需求具体产生修正作用。综上所述，Superflow将重点放在研究如何缩小应用具体于不断变化的需求具体的差异性上。§4-3-2  Superflow的应用之路

我们认为，所有企业资源都是不断运动变化的过程。如何正确理解（需求具体）和客观反映（系统设计）这一变化的过程，是实施企业应用的第一步。在此基础之上，合理的实现（应用具体）企业资源的运动过程则是企业应用的最终表现形式。这一表现形式应该具有相对时期的稳定性和长期自适应性。

图4-3-2-1             企业应用实施的两条路线

一、目前企业工作流应用的现状

企业工作流应用系统在国内已经有多年的发展历史了，但是成功的却不多见。究其原因，不外乎如下几点：

n         没有良好的数学模型           按照软件工程学的观点，良好的数学模型是系统设计的坚强基石，可是开发商在开发应用时，往往为了省时省力而忽略了数学模型，导致系统没有完善而成熟的理论支持，对开发进程中遇到的技术问题采取退而求其次的方法。

n         系统缺乏柔性                     尽管每个开发商都宣称自己的系统具备良好的可伸缩性，但是实际上真正做到的不多见。

n         应用模式固定                     大部分系统在开发过程之中把企业应用逻辑完全绑定在系统的控制逻辑上，当用户需求发生变更时，不得不重新开发系统或者大量修改源代码。由于事先缺乏统一的规划，导致不断的给系统打“补丁”，结果就像“滚雪球”一样，系统越来越庞大，其效率低下和稳定性不良等问题接踵而来。

为了解决上述问题，我们提出并实现了“动态业务工作流引擎(Superflow)”。基于这一模式，可以有效的解决上述诸多问题。

二、目前企业应用的实施模式

（1）目前企业应用的实施过程

考察图4-3-2-1，大部分系统的企业实施模式分为四个步骤。第一步：理解并且表达企业需求

       用户的需求虽然是真实的，但却是原始的，甚至是凌乱不堪的。用户很了解自己需要做什么，却未必能让开发者知道自己需要做什么。因此开发者和用户双方都必须对需求予以正确的理解和表达，作为系统分析和开发的依据之一。第二步：应用逻辑的抽象化

       基于经过理解和表达之后的需求，分析、设计其应用逻辑。应用逻辑是经过加工处理的抽象化的企业需求，企业应用将根据该需求运作。第三步：融合控制逻辑

       根据特定的应用逻辑定义一套算法，以实现和驱动应用逻辑。遗憾的是，这套算法往往和具体的应用逻辑密切相关，于是导致了应用系统在开发、运行和维护等一系列过程中的难以解决的弊端。第四步：应用集成

       应用逻辑和控制逻辑的融合构成企业应用。当然，作为一个应用系统的生命周期而言，还会有测试、验收、运行和维护等步骤。（2）这种应用模式的固有特点

n         应用逻辑与控制逻辑的融合              根据需求抽象应用逻辑，根据应用逻辑设计或定制特定的控制逻辑，使得控制逻辑无处不打上应用逻辑的烙印。如图4-3-2-2所示，应用逻辑和控制逻辑交互融合，密不可分。

图4-3-2-2             应用逻辑与控制逻辑的融合

n         逐层抽象                                          考察图4-3-2-3，这种应用模式事实上是一个企业需求的层层抽象的过程。考虑到用户需求表达的精确性、技术人员理解需求的完整性、系统分析和设计方法的局限性，每一层的抽象，势必会进一步概念化反映企业客观实体的原始的需求具体。 
 

 

 

图4-3-2-3             需求具体的逐层抽象

 
 

 

 

（3）目前企业应用模式的弊端

企业应用模式的固有特点，将导致如下弊端：n         需求具体和应用具体的差异性如图4-3-2-3，企业需求是企业应用系统实施的最终目标，也是系统验收的依据和成败的关键。可是需求具体的逐层抽象加大了企业应用与用户原始需求的偏差，这种偏差是企业应用真正走向实用的桎梏，大部分企业应用系统不能成功实施的原因就是应用具体与需求具体相去甚远。n         控制逻辑对应用逻辑的依赖性图4-3-2-2，控制逻辑和应用逻辑的融合是目前企业应用系统的又一个弊端。造成这种现象的原因，除了系统缺乏良好的数学模型之外，还有开发商追求短期经济效应，一味的降低设计和开发难度，重用不完善的组件、缩短开发周期等。基于前面论述，企业客观实体是一个不断运动的过程，那么最真实反映企业客观实体的需求具体会不断的变更和调整。根据需求具体的逐层抽象模式，变化了的企业需求必然导致应用逻辑的重新抽象，而与企业应用逻辑融合的控制逻辑也必然面临再次定制和重新融合的复杂过程。无论如何，这一过程是痛苦的。n         应用开发的“沙漠之旅”应用具体和需求具体的差异性，导致了应用开发过程的反复甚至重新开发。为了尽量满足企业不断变化的需求具体，开发商不得不经常调整开发策略，明显的缺乏目的性。这就是应用开发过程中最为可怕的“沙漠之旅”。n         应用维护的“雪球效应”控制逻辑对于应用逻辑的依赖性，导致应用系统无法适应变化了的企业需求。出于成本和效益的考虑，开发商和企业不得不对目前应用系统不断的“打补丁”。这种填补漏洞的方法显然是所谓“头痛医头，脚痛医脚”，无法从根本上解决应用具体对需求具体变化的适应性，其结果就像滚雪球一样，系统越来越庞大复杂，从而导致应用系统效率低下，系统维护和修改越来越困难。这一恶性循环的“雪球效应”是企业最不愿意看到的。三、Superflow的企业应用之路

（1）Superflow的两个基本前提

第一个基本前提：面对有管理的企业。

第二个基本前提：有管理的企业的应用过程都是工作流。

基于上述前提，Superflow的企业应用之路事实上就是有管理的企业的工作流解决方案。第一个前提规范了Superflow的应用范围。那么，第二个前提成立吗？

n         企业活动的有序性              有管理的企业的活动过程必然是有序的，这种有序性体现为合理的工作流程。

n         企业活动的协作性              随着社会分工的日益具体化，合作已成为主题。合作的体现形式必然是一个完整而高效的工作流程。

n         孤立企业活动的理解           孤立的企业活动体现为一个起点与终点合一的工作流程。n         企业的运作过程的本质              企业的运作过程本质上是人、财、物等资源的优化和合理配置，形式上无一不体现为信息流、资金流、物流、价值流等合理的流动。因而，在有管理的企业里，工作流无处不在。

（2）Superflow的企业应用实施过程

如4-3-2-1，Superflow的企业应用之路与目前系统的应用模式截然不同。对于用户而言，Superflow体现为一个三层式黑匣子（图4-3-2-4）。Superflow接受用户需求，输出企业应用。

图4-3-2-4   Superflow的三层式黑匣子

那么，Superflow如何运作？下面我们考察图4-3-2-1中Superflow的三个部分。需求规则化专家

用户的原始需求是企业应用本质的最贴切反映。可往往用户的需求是凌乱的，不规则的，这种需求主题必须明确化、语言必须精确化。目前大部分系统由用户提出原始需求，由开发商在用户的协助下完成分析过程并且形成文档，这种最终的文档带有明显开发商意志和烙印，不可避免地导致需求偏差。需求规则化专家构造原始企业需求到规则化需求之间的镜像。如图4-3-2-5，Superflow则采用另外一种完全不同的方式理解和引导用户产生明晰、精确的需求。n         需求馈送机

需求馈送机接受来自用户的尚未整理的原始资料，输送到需求表达机并且反馈来自需求表达机的信息给用户审核、编辑和确认。n         需求表达机

需求表达机接受来自需求馈送机的原始资料，根据来自需求算法库的算法，整理和表达用户需求，并将规则化的需求输入规则化需求库。同时接受来自规则化需求库的需求表达式，通过馈送机反馈给用户确认和审核。n         规则化需求库

规则化需求库存放需求表达机表达之后的规则化的企业工作流应用需求。这种需求将被应用逻辑自适应引擎识别，从而构筑企业工作流应用。n         需求规则化算法库

需求规则化算法库存放和学习需求规则化算法，需求规则化算法库是需求规则化专家的核心。Superflow分析和综合了企业工作流应用的所有确定性和不定性，并以某种数学表达式表示和存贮在该算法库中。图4-3-2-5   Superflow的需求规则化专家

n         应用逻辑自适应引擎

       应用逻辑自适应引擎根据规则化需求库中的规则自适应构建企业工作流应用逻辑，这一个构造过程是动态的。它实时跟踪企业需求的变化，动态构造企业应用逻辑，因而它具有自适应的特性。       应用逻辑自适应引擎构造规则化需求到应用逻辑的镜像。 
 

 

 

图4-3-2-6   应用逻辑的自适应引擎

通用工作流控制引擎

通用工作流控制引擎集成了通用的企业工作流控制逻辑，是Superflow的控制核心。它监视和调度Superflow的各功能部件，协调和控制应用逻辑的运作。上述需求规则化专家和应用逻辑的自适应引擎都在通用工作流程控制引擎的统一调度下运作。企业的应用逻辑通过工作流控制引擎的镜像，形成了企业工作流应用。图4-3-2-7   通用工作流控制引擎

（3）Superflow的固有特点

Superflow走的是一条完全不同的企业应用之路，所以它有如下独特之处。n         应用逻辑与控制逻辑的分离      

 
 

 

 

图4-3-2-8   应用逻辑与控制逻辑的分离

Superflow把企业的应用逻辑和控制逻辑隔离开来，以独创的通用工作流引擎技术实现企业复杂业务的应用控制；以基于用户需求的自适应应用逻辑引擎实现企业的应用需求。控制逻辑引擎驱动应用逻辑的运作。

n         逐层镜像

与逐层抽象不同，Superflow采用的是一种逐层镜像的方式解释和表达企业应用需求。抽象必然导致“失真”，而镜像则是事物原貌的完整再现。所以，逐层镜像维护了企业应用与企业需求的一致性。

（4）Superflow的应用优势

Superflow的逐层镜像和逻辑分离特性，给予Superflow极大的应用优势：

n         Superflow揭示事物的本来

Superflow逐层镜像企业应用需求，保持需求具体和应用具体的一致性，是企业完整、真实工作流程的重现。

n         Superflow体现用户需求之“原汁原味”

需求规则化专家引导用户规则化原始需求，并且通过需求馈送机反馈、审核和认证规则化需求。全过程由最终用户发起和审核，体现了用户需求之“原汁原味”。

n         应用逻辑的具体化和控制逻辑的透明化

由于Superflow隔离了企业的应用逻辑和控制逻辑，使得用户和开发者不用关心纷繁复杂的控制逻辑（控制逻辑对用户而言是透明的），便于集中精力理解和实现需求。一旦需求发生变更，只需通过需求规则化专家规则化需求和生成新的自适应应用逻辑，不用修改控制逻辑。

n         Superflow展现企业应用鲜活的生命力

Superflow揭示企业业务运作的本来，体现了企业需求的“原汁原味”。实时展现了企业工作流应用过程的全貌，并且动态跟踪和自适应业务需求的变化。

企业应用不再是逐层抽象的软件系统，Superflow使它变得同实际业务受理过程一样具有鲜活的生命力。

n         Superflow是智能化与人性化的结合

Superflow是一个动态的自适应工作流程引擎，自动驱动业务流程运作，同时又隔离了复杂的业务控制逻辑，使得企业应用体现为一个活生生的具体过程。因此Superflow是的智能化与人性化的结合。

 
 

 

 

§4-4      Superflow的应用子系统

§4-4-1   Superflow的运行模式

    如图4-4-1-1所示，Superflow为多层分布式结构。

    前台为用户定制的瘦客户机，通过TCP/IP(WAN或LAN)与中间层Socket Server(套接字服务器)连接，通过Socket Server访问工作流引擎,工作流引擎通过数据库引擎访问后台数据库。多个工作流引擎自动容错与负载均衡。

 
 

 

 

图4-4-1-1  Superflow的平台模式

 
 

 

 

§4-4-2 Superflow的子系统拓扑

Superflow是一个面向分布式应用的工作流设计和运行平台，它主要由工作流定义工具、工作流客户端API、工作流管理和监控工具以及工作流引擎等几个部分组成Superflow提供了一套完整的API（SAPI）用于同客户端接口。SAPI以无状态自动化对象（Unstated Automation Object）的方式定义在Superflow的引擎服务器方法库中，为了方便调用，方法库中的大部分方法已经在客户端方法库中重载。

Superflow管理工具用于在本地或远程做系统初始化、运行参数和管理功能的设置。

Superflow监控工具用于在本地或远程监控和跟踪业务受理过程，包括业务受理的动作细节和时间细节。

 
 

 

 

图4-4-2-1      Superflow的子系统结构

 
 

 

 

Superflow定义工具用于在本地或远程定义、管理、编辑、重组业务流程。

    Superflow引擎则是系统的核心，它驱动和掌控系统的运作。包括需求规则化专家、应用逻辑自适应引擎和通用控制逻辑引擎。

§4-5      结论

    针对目前企业应用的逻辑绑定、逐层抽象的应用模式及其导致的一系列弊端，Superflow提出了逻辑隔离、逐层镜像的新思维，从根本上解决了目前企业应用的严重桎梏。