工作流+工作流的特点+工作流的优点

工作流（Workflow）就是“业务过程的部分或整体在计算机应用环境下的自动化”，它主要解决的是“使在多个参与者之间按照某种预定义的规则传递文档、信息或任务的过程自动进行，从而实现某个预期的业务目标，或者促使此目标的实现”。

简单地说，工作流就是一系列相互衔接、自动进行的业务活动或任务。一个工作流包括一组任务（或活动）及它们的相互顺序关系，还包括流程及任务（或活动）的启动和终止条件，以及对每个任务（或活动）的描述。

工作流在大多数的实际应用中的情况可以这样来简单地描述：在网络、服务器和多台计算机客户端的硬件平台上，业务过程按照预先设定的规则并借助应用程序和人对相关数据的处理而完成。例如，在日常办公中，当撰写好某份报告之后，可能需要将其提交给领导进行审阅或批示；审批意见可能需要汇集并提交给另外一个人，以便对报告进行进一步的修改。这样，可能会形成同一篇文档在多个人之间的顺序或同时传递。对于这样的情况，我们可以使用工作流技术来控制和管理文档在各个计算机之间自动传递，而非手工传递。这就可以称之为工作流。

类似的关于文档的自动化处理只是工作流技术的一种简单应用。事实上，工作流技术在现实生活中能够完成更多更复杂的任务。如企业（或机构）内部的各种数据或信息的自动处理，多种业务流程的整合，企业（或机构）之间的数据交换，借助Internet技术实现跨地域的数据传输和处理等等。

某产品销售的工作流示意图：

一、工作流发展

工作流技术起源于二十世纪七十年代中期办公自动化领域的研究，由于当时计算机尚未普及，网络技术水平还很低以及理论基础匮乏，这项新技术并未取得成功。1983年至1985年间，在图像处理领域和电子邮件领域出现了早期的含有工作流特征的商用系统。

进入九十年代以后，随着个人计算机、网络技术的普及和推广，以及信息化建设的日益完善，使得工作流技术的研究与开发进入了一个新的热潮。1993年8月,第一个工作流技术标准化的工业组织——工作流管理联盟（Workflow Management Coalition，简称WFMC，下同）成立。1994年，工作流管理联盟发布了用于工作流管理系统之间互操作的工作流参考模型，并相继制定了一系列工业标准。与此同时，关于工作流技术的学术研究也十分活跃，许多原型系统在实验室里开发出来。进入二十一世纪以来，工作流技术已被越来越多的人认可，与之相关的标准规范、工作流引擎及商业产品不胜枚举。人们在开发推广工作流产品的同时，更加注重工作流的理论研究，以推动该项技术走向成熟。

二、工作流的特点

1，图形化、可视化设计流程图

2，支持各种复杂流程

3，组织结构级处理者指定功能

4，B/S结构，纯浏览器应用

5，强大的安全性特色

6，表单功能强大，扩展便捷

7，灵活的外出、超时管理策略

8，处理过程可跟踪、管理

9，丰富的统计、查询、报表功能

10，与MAIL系统集成

三、工作流的优点

企业实施工作流管理所带来的好处是非常明显的，这包括提高企业运营效率、改善企业资源

利用、提高企业运作的灵活性和适应性、提高工作效率、集中精力处理核心业务、跟踪业务处理过程、量化考核业务处理的效率、减少浪费、增加利润、充分发挥现有计算机网络资源的作用。实施工作流将达到缩短企业运营周期、改善企业内（外）部流程、优化并合理利用资源、减少人为差错和延误，提高劳动生产率等目的。

总结实施工作流带来的好处，可以归纳为以下几点：

1，要处理的事项已自动传递到个人电脑上

2，不再需要对员工进行流程的培训，平滑实现流程变更

3，员工只需将精力集中在处理自己关心的数据上

4，随时得到历史数据

5，随时生成处理效率报表

6，达到无纸化办公的目标

7，完全支持移动办公，使作业同步化

8，科学管理更进一层，办公效率明显提高

9，企业的核心竞争力将有提升

10，通过流程自动化与数据库集成，以及各类表单统计查询功能，提高决策能力

四、工作流WorkFlow技术构架

五、工作流是如何实现的

工作流的实施需要三个基本步骤：映射、建模和管理。映射是第一个步骤，其首要任务是确定并且文档化组织内全部现有的手工和自动化的业务流程；建模则是开发一个有助于建成流线型业务过程的模型。第三阶段是软件实施以及跨越全部工作部门、业务单元甚至是整个企业的无缝系统集成。

为了确保工作流系统能够“无缝地”实施到组织机构中，项目组都必须遵从已经定义好的、经过实践确认的行之有效的工作方法，并且在每个工作阶段都必须有可以度量的结果。一个深思熟虑的实施计划被有经验的团队执行，是成功地采用和实施工作流的决定因素。下图描述了一个推荐的、可供典型组织机构采纳的高层工作流（实施流程）。下面按图中步骤具体阐述。

建立项目管理办公室

项目管理办公室的组成是第一步，也是最重要的一步。项目管理办公室的成员须经过严格谨慎挑选，他们必须在恰当的程度上广泛代表组织内的业务、运营、IT以及审计等部门。产品供应方的产品专家、技术支持人员和管理人员也必须参与其中，以与用户互补。通常在PMO中还包含变更管理顾问，有助于形成组织中人员思路的多样化。每个成员的角色和责任必须定义清楚。PMO从整体上确立项目的实施范围、目标、实施时间框架以及优先级等等。PMO也负责管理和跟踪项目进度、设定检测项目是否成功的指标，以及定期向高层汇报项目状况等。

业务分析

项目组将分析用户现有的业务流程，找出哪些流程需要优化和改进以达到上佳效果，并分析每个流程的时间线和期望的结果。他们将与关键人员进行座谈，收集和鉴别正确的信息及数据，从而决定工作流系统如何满足需求。接下来的业务分析将辨别出哪些流程可以被优化、自动化、流线型化，哪些流程甚至需要重新设计。

确定目标

确定上佳目标是建立在业务流程详细分析的基础之上的。工作流项目的目标定义应该清晰并

可以进行验证，好的目标意味着项目的成功。在实施过程的每一个阶段，项目组必须确认达到的结果是他们所期望的结果。例如，如果目标是缩短开发票周期两周，则必须分析现有的时间跟踪、记账和开发票等流程。

确定实施计划

目标确立后，由用户和软件供应商组成的项目组展示工作流解决方案具备的各种模块，根据用户提出的特定需求定义他们的功能和特性，并基于业务的优先级，共同决定每个模块的上线时间。

将业务流程在工作流系统中建立模型

在实施过程中建立业务模型是一个极重要的步骤。用户应当紧密地同软件产品应用专家进行合作，以在易用性和功能需求之间达到平衡。

用户可以在部署阶段前对模型进行测试，以确保该模型符合实际要求且没有过多的开销。需要指出的是，如果这个建模步骤没有完全正确地完成，将导致错误的报表或者多余的管理工作。

实现流程和软件集成

在这个阶段，项目组将确定现有的需要与工作流系统交互的流程与系统。如果处理不当，新旧流程的集成将导致失败。流程集成的一个重要方面就是在多系统之间消除或者最小化冗余数据，并在多个系统间复制这些数据。流程必须紧密集成，数据必须能跨越不同的流程和应用，顺畅流动。

项目组也必须确保工作流系统符合用户组织机构的安全标准，这一点经常在部署阶段前被忽视。

部署工作流系统

部署工作流系统包括两部分内容。第一部分自然是技术部分，涵盖了硬件和软件的安装、备份、恢复以及网络安装等等，这与一般的IT应用实施相似。

第二部分是指上线试运行。试运行小组应具有真正的代表性。项目组必须与试运行小组就项目的重要性进行沟通，并确保提供足够的培训，使得试运行小组能够对试运行工作得心应手。建议项目组建立清晰的沟通渠道，保证在试运行期间可以及时反馈用户的意见和建议。试运行将使项目组鉴别出原来设计和计划的弱点和缺点，并在大规模上线运行前加以解决。这也可以提高用户对于新流程的接受程度，因为用户感到他们也参与了项目的开发部分，解决方案不是强加给他们的。

一般认为，采用阶段性实施工作流系统可使用户更快地获得效益。因为用户可以更有效地渐进学习新系统，取得立竿见影的效益。阶段性实施还给予用户更多的时间了解、评估他们进一步的需求，使得项目实施期间的修改更加容易。另外，阶段性实施项目降低了风险。 系统评估

特别注意，在每一个阶段完成后，项目组都应该基于项目开始时设定的目标，对已经完成的结果进行评估，同时分析所达到的结果，并与最初的设计目标相对照。为了确保工作流解决方案在现有的业务环境中优化出更理??通，以了解什么需要更改。

系统支持

为确保实施成功，更佳地使用工作流软件，组织机构必须进行服务投资，组织机构应该委派专业人员提供第一线的服务，也应负责与供应商签订合同，以获得第二级支持。

六、工作流适用行业

消费品行业,制造业,电信服务业,银证险等金融服务业,物流服务业,物业服务业,物业管理,大中型进出口贸易公司,政府事业机构,研究院所及教育服务业等,特别是大的跨国企业和集团公司。

七、工作流具体应用

关键业务流程： 订单、报价处理、采购处理、合同审核、客户电话处理、供应链管理等 行政管理类：出差申请、加班申请、请假申请、用车申请、各种办公用品申请、购买申请、日报周报等凡是原来手工流转处理的行政表单。

人事管理类： 员工培训安排、绩效考评、职位变动处理、员工档案信息管理等。

财务相关类： 付款请求、应收款处理、日常报销处理、出差报销、预算和计划申请等。 客户服务类： 客户信息管理、客户投诉、请求处理、售后服务管理等管理等。

特殊服务类： ISO系列对应流程、质量管理对应流程、产品数据信息管理、贸易公司报关处理、物流公司货物跟踪处理等各种通过表单逐步手工流转完成的任务均可应用工作流软件自动规范地实施。

作为一个成熟稳定的工作流产品，不仅提供日常办公和关键业务流程智能化管理，而且能根据公司的特殊实际要求轻松方便地随时定制各种流程，并可实现不同角色不同的跟踪、查询、统计、打印等强大功能

结论

许多组织机构都有雄心勃勃的计划，为了能够夺回失去的时间和获得竞争优势，希望能够以大的步伐，更深（企业级或多级）、更广（多应用）和更快（短时间）地进入数字工作流时代。我经常发现他们因为许多原因而惨遭失败。根据我个人经验，明智的做法是从小的范围开始做起，并随着工作流的成长而逐步做大。阶段性实施提供了转换到新的流程的平稳方法。由于用户看到了效益，使得用户更易于接纳新的工作流程。阶段性实施的另一个原因，是用户不能够承受一下子丢弃原有的全部流程，从零开始。组织机构应该在当前业务过程中最没有效率的地方，集中寻找他们的“痛处”，然后利用“案例驱动”原则影响他们。

组织机构也必须认识到，当计划实施一个新的工作流程时，行政力量和企业文化必须要考虑进去。

成功与否的最后一个关键要素就是“人”。当我们改变业务流程时，技术是一个方面，但更大的挑战来自员工。的确，数字工作流系统要分阶段进行，使人们“渐进式”地取得经验，而不是“革命式”地得到经验。

工作流：workflow

今天讲的是工作流系统

什么是工作流系统： 工作流（Workflow）就是“业务过程的部分或整体在计算机应用环境下的自动化”，它主要解决的是“使在多个参与者之间按照某种预定义的规则传递文档、信息或任务的过程自动进行，从而实现某个预期的业务目标，或者促使此目标的实现”。

简单地说，工作流系统就是一系列相互衔接、自动进行的业务活动或任务。//一个工作流包括一组任务（或活动）及它们的相互顺序关系，还包括流程及任务（或活动）的启动和终止条件，以及对每个任务（或活动）的描述

例如，在日常办公中，当撰写好某份报告之后，可能需要将其提交给领导进行审阅或批示；审批意见可能需要汇集并提交给另外一个人，以便对报告进行进一步的修改。这样，可能会形成同一篇文档在多个人之间的顺序或同时传递。对于这样的情况，我们可以使用工作流技术来控制和管理文档在各个计算机之间自动传递，而非手工传递。这就可以称之为工作流。 工作流技术架构(图片)

词语解释

Middleware 中间件

Runtime 运行时间

Prebuilt 之前建立

Flowchart 流程图，作业图

Subsystem 子系统

工作流（Workflow）的优点

企业实施工作流管理所带来的好处是非常明显的，这包括提高企业运营效率、改善企业资源利用、提高企业运作的灵活性和适应性、提高工作效率、集中精力处理核心业务、跟踪业务处理过程、量化考核业务处理的效率、减少浪费、增加利润、充分发挥现有计算机网络资源的作用。实施工作流将达到缩短企业运营周期、改善企业内（外）部流程、优化并合理利用资源、减少人为差错和延误，提高劳动生产率等目的。

总结实施工作流带来的好处，可以归纳为以下几点：

1，要处理的事项已自动传递到个人电脑上

2，不再需要对员工进行流程的培训，平滑实现流程变更

3，员工只需将精力集中在处理自己关心的数据上

4，随时得到历史数据

5，随时生成处理效率报表

6，达到无纸化办公的目标

7，完全支持移动办公，使作业同步化

8，科学bsp; 9，企业的核心竞争力将有提升

10，通过流程自动化与数据库集成，以及各类表单统计查询功能，提高决策能力 组织的本质：1 是参与者与技术的聚集

2. 由总体的目标约束

组织的种类：1 理性的(整个集体是追求相当明确的目标和显示出相当高的固定社会结构，如商业) 2 natural(整个集体有同样的兴趣，并且乐于集体活动，如慈善机构)

3. 开放式的组织

数据流中的组织运用：理性的组织是用于计算机化中最成功的 数据流也同时对自然的和开放式的组织进行计算机化

数据流系统的一个联系：1 消息系统 2 工作项目 3 业务规则 4 流程图

消息系统：两类：1 数据流能识别的格式，2 不能识别格式

工作项目 一个工作项目具体说明一个需要被工作者执行的任务

数据流系统的任务是和工作项目相协调

业务规则： 一个典型的数据流有许多业务逻辑块所组成

在其生命周期内，业务规则在任何时候受限于数据流

业务规则在模型化组织时扮演很重要的角色

业务规则的起因：---

流程图：在数据流中一个主要模型结构是流程图

Synchronize ； 相协调； 暂停 解决数据流的例子记忆功能

运行时（runtime）运行语言：--

主机运行一般在组织的服务器，也可在客户端

数据流的中间件框架{中间件”简单解释：为了解决应用程序对网络过分依赖的问题采取了一种有效的方法，在客户机和服务器之间加一层软件。}

执行这些工作：1 初始化和终止

2.执行：即执行在模型中明确规定的行为

3 长期数据流运行的管理

4 管理长期和短期的交易

演讲稿

在英语中working with the flow 是随波逐流的意思，但在这里表示工作流.

工作流的实质：在一个机构内，通过用电子文档来替换纸张文档系统，从而实现文档处理过程的自动化。我们可以将整个业务过程看作是一条河，其中流过的就是工作流。 数据流应用的产生的发展是以下两个因素的结果：

在这里 有两个关键字 在计算机环境下 以及自动化（办转学手续的例子）

数据流如邮件，电子邮件，活动和信息。

数据流的传递 是在一定的逻辑和规则下进行的。

无缝集成系统 就是 实现了平台管理的不同系统间信息交换和数据共享,

那么工作流系统是如何开始被人们所应用的呢？

下面介绍一下工作流中的专业术语

工作项目 一个工作项目具体说明一个需要被工作者执行的任务。打个比方说，就像我们编程时，给出提示信息，让操作者输入所需信息。

业务规则： 一个典型的数据流有许多业务逻辑块所组成

在其生命周期内，业务规则在任何时候受限于数据流

业务规则在模型化组织时扮演很重要的角色

定义和运行一个数据模型：是一个很复杂的工作，要有重要的体系结构，设计，和发展工作，并且工作永远都不会结束，因为模型必须一直调整来反映变化的存在的组织环境。

结论：工作流的核心部分是组织工作的模型，这个模型被用于编译许多部分用来运行一个组织。

接着是已经被广泛应用的一些工作流软件

MRP－III

是由MRP－II与JIT(Just In Time,准时制生产)的混合加上专家系统（ES）、并行工程（CE）和承担该系统运行的管理人员融为一体而成。

ERP

ERP的基本思想是将制造企业的制造流程看作是一个紧密连接的供应链，其中包括供应商、制造工厂、分销网络和客户；将企业内部划分成几个相互协同作业的支持集团，如财务、市场、销售、质量、工程等，还包括竞争对手的监视管理。

与以往已经被采用的企业IT应用体系，例如MRPII或ERP相比，WFMS是一个相当重要的里程碑。从用户的角度，WFMS带来（或将要带来）的变化是极其强烈的，甚至可以形容为一种用户“梦想”的实现。

在一些老的“模块化”的产品中，系统的设计是通常是基于任务分割的，作业项目之间是分裂的。面向对象的技术，并不能直接解决这个的问题，相反，往往使系统变得更加混乱和琐碎。从操作上，典型地，我们必须不断地在层次结构的功能表（比如下拉菜单）或对象之间“进进退退”，或者在“神出鬼没”的对象以及相关菜单中捉迷藏。

工作流管理系统是一个真正的“人-机”系统，用户是系统中的基本角色，是直接的任务分派对象，他或她可以直接看到电脑针对自己列出的“任务清单”，跟踪每一项任务的状态，或继续一项任务，而不必从一个模块退出，进入另一个模块，搜索相应任务的线索。前者是面向功能或对象的，而后者是直接面向用户的。这样，用户的任务分派和任务的完成状态，可以被最大程度地电脑化和受到控制。

现在的典型工作流产品是客户-服务软件。而日益增长的重要途径是通过万维网界面，它可以令客户或远程的职员更好地参与。工作流的定义经常是借助于图形化工具，依照业务过程实例的情况定义相应工作的安排。

1. 已经能够持续自动产生大量的细节数据。这类数据最早出现于传统的银行和股票交易领域，现在则也出现在地质测量、气象、天文观测等方面。尤其是互联网(网络流量监控，点击流)和无线通信网（通话记录）的出现，产生了大量的数据流类型的数据。我们注意到这类数据大都与地理信息有一定关联，这主要是因为地理信息的维度较大，容易产生这类大量的细节数据。

2. 需要以近实时的方式对更新流进行复杂分析。对以上领域的数据进行复杂分析（如趋势分析，预测）以前往往是（在数据仓库中）脱机进行的，然而一些新的应用（尤其是在网络安全和国家安全领域）对时间都非常敏感，如检测互联网上的极端事件、欺诈、入侵、异常，复杂人群监控，趋势监控(track trend)，探查性分析（exploratory analyses），和谐度分析(harmonic analysis)等，都需要进行联机的分析。

OSWorkflow是一个灵活的工作流引擎，设计成可嵌入到企业应用程序中。它提供了许多的持久化API支持包括：EJB,Hibernate,JDBC和其它。OSWorkflow还可以与Spring集成。

jBpm是一个灵活可扩展的工作流管理系统。作为 jBpm运行时server输入的业务流程使用简单强大的语言表达并打包在流程档案中。jBmp将工作流应用开发的便利性和杰出的企业应用集成（EAI）能力结合了起来。jBmp包括一个Web应用程序和一个日程安排程序。jBmp是一组J2SE组件，可以作为J2EE应用集群部署。

OpenWFE是一个开放源码的Java工作流引擎。它是一个完整的业务处理管理套件：一个引擎，一个工作列表，一个Web界面和一个反应器（存放自动代理）。它可以可以跟你的程序很好的给合。

Werkflow是一个灵活可扩展的基于流程和状态的工作流引擎。它的目标是满足可以想象的所有工作流程，从企业级的业务流程到小范围的用户交互流程。通过使用可插拔和分层结构，可以方便地容纳各种工作流语义。

OFBiz是一个非常著名的开源项目，提供了创建基于最新J2EE/XML规范和技术标准，构建大中型企业级、跨平台、跨数据库、跨应用服务器的多层、分布式电子商务类WEB应用系统的框架。 OFBiz最主要的特点是OFBiz提供了一整套的开发基于Java的web应用程序的组件和工具。包括实体引擎, 服务引擎, 消息引擎, 工作流引擎, 规则引擎等。

基于关系结构的轻量级工作流引擎

何清法 李国杰 焦丽梅 刘力力

（中国科学院计算技术研究所 北京 100080）

摘要：针对关键业务的应用的开发离不开工作流技术的支持。通过对关键业务的实际开发需

求的分析，在传统的关系数据库的基础上，提出了一个适用于关键业务开发的基于关系结构

的轻量级工作流引擎的框架结构。此工作流模型由机构模型、信息模型和控制模型三部分组

成。文中深入讨论了采用关系结构和轻量级理念来设计工作流引擎的原因，并详细地给出了

相关的机构模型、信息模型和控制模型的设计原理以及具体的表示和实现方法。其原型已经

应用到实际的应用系统中，实践证明，利用此工作流引擎可以显著地缩短关键业务的开发周

期。

关键词：关系 轻量级 工作流引擎 关键业务 活动

RELATION-BASED LIGHTWEIGHT WORKFLOW ENGINE

HE Qing-Fa LI Guo-Jie JIAO Li-Mei LIU Li-Li

(Institute of Computing Technology, Chinese Academy of Sciences, Beijing 100080)

Abstract: Workflow technology plays an important role in the development of critical business applications. According to the analysis of the requirements to develop

critical business applications, this paper presents a framework of a

relationship-based lightweight workflow engine, which is built over the conventional relational database system. It consists of three components, namely: organization model, information model and control model. The reasons that the concepts of

relationship and lightweight are adopted to design the workflow engine are thoroughly discussed in the paper. Also, this paper sets forth the principle to design, the

representation of and the way to implement the organization, information and control model of the workflow engine, respectively. A prototype of this workflow engine has been applied to a project about the automation of trademark registration and

administration, which shows the application of the workflow engine can markedly

shorten the cycle of the development critical business applications.

Key words: relationship, lightweight, workflow engine, critical business and activity

1引言

目前，针对企业或者部门的计算机应用已不仅仅停留在诸如文档处理、公文流转以及信息发布等这些简单的业务层面上。越来越多的企业或部门要求将信息技术的应用扩展到关键业务中。关键业务的普遍特征是：（1）是企业或部门赖以生存的；（2）业务过程往往由许多业务活动组成，业务逻辑和业务规则复杂；（3）业务的完成依赖于其中众多业务活动之间的交互和众多的业务人员的协作参与；（4）涉及到的数据量经常是海量数据；（5）如果能将信息技术恰当地应用到这些关键业务中，不仅仅能够提高工作效率，还可以减少出错的可能性。例如，产品的设计和制造过程，银行的借贷和划账业务，还有商标的申请、审查和注册业务等等，都属于相应企业或部门的关键业务。工作流技术所具有的协调本质决定了其在关键业务的信息化过程中将扮演重要的角色。

正如文献[1][2]所述，工作流是业务过程的计算模型，即将相应的业务逻辑和业务规则在计算机中以恰当的模型进行表示并对其实施计算。业务过程是若干业务活动的集合，这些业务活动按照一定的规则前后链接在一起，相互协作，以便达到一个共同的目标。业务活动则是能够完成特定的功能的一个实际环节，它在信息系统中通常针对具体的应用逻辑。为了对工作流管理系统的开发起到一个指导作用，工作流管理联盟（WfMC）给出了工作流系统的一个通用框架――工作流参考模型[2]。在工作流参考模型中，工作流引擎是工作流管理系统的核心。工作流引擎是为工作流管理系统在定义提供支持、同时在运行时提供解释和执行服务的一组数据模型和软件。根据文献[3]中对工作流引擎体系结构的讨论，我们认为工作流引擎主要包括机构模型、信息模型和控制模型三种模型，前两者合称为工作流引擎的数据模型。

本文以国家智能计算机研究开发中心所承当的一个具体的应用项目――国家商标局的商标注册与管理信

息化系统为实例，同时分析了其他不同的企业和部门的关键业务的基本特征，针对关键业务的开发需求，在传统的关系DBMS的基础上，讨论一个基于关系结构的轻量级工作流引擎的具体的设计原理与实现方法。它充分考虑了关键业务开发过程中对工作流功能的需求，利用此工作流引擎，可以使用传统的开发工具构造出具有工作流特征的大型信息系统1[1]。

本文的第2部分讨论为什么要采用关系结构和轻量级这两个概念来设计工作流引擎，第3部分给出相关的数据模型及其表示，接着，在第4部分中将描述工作流引擎的控制模型，最后还将给出具体的应用实例。

2与关系结构和轻量级相关的一些讨论

目前，软件开发的一个普遍现象是软件产品的规模和功能越来越向大型化和复杂化的方向发展，而本文所提出的基于关系结构的轻量级工作流引擎却强调其小型化的特征。许多工作流产品从数据存储到运行环境往往都有自己的一整套独特的体系结构，它们除了具备了工作流的基本功能外，还同时宣称可以任意集成第三方的应用，甚至有的还嵌入了程度不等的应用开发的功能。但是，开发人员真正需要的可能并非这些复杂特性。

2.1 工作流的设计中心

所谓工作流的设计中心指的是由谁来定义和开发工作流的应用。那么，工作流的设计中心到底应该在哪里？Patricia Seybold Group的Ronni Marshak曾经对这个问题进行过一些有益的论述：

1) 完全由实际的业务人员来负责工作流应用的定义和开发，一些工作流产品也大力提倡这一点。的确，实际的业务人员对自己的业务规则最为熟悉，但他们对计算机技术了解不多。因此，这只适合简单的工作流应用，一旦业务逻辑比较复杂尤其是面对关键业务时，要他们将业务逻辑转换为工作流并且自己定制相应的应用逻辑，则非常困难。

2) 业务人员和专业技术人员相结合。工作流产品提供图形化的界面供业务人员（或者结合专业人员）定义业务逻辑和规则，具体的应用逻辑则由专业开发人员完成。应用的开发可以利用工作流所提供的集成开发工具，也可以利用第三方的开发工具。可能存在的问题是如果使用工作流产品所集成的开发工具的话，则其所提供的开发应用的功能是否足够；另一方面，如果使用第三方的开发工具的话，又该如何实现工作流机制的集成。

3) 还有一种观点认为，要建立真正复杂、灵活而且可扩展的应用系统，必须将工作流的开发融合到信息

系统的开发过程中，从整个信息系统的角度来定义工作流中的业务规则、任务流转以及相关角色。甚至更有一种极端的观点认为应该把业务规则硬编码到具体的应用中，如果业务规则比较稳定的话，这种方法可以得到非常紧凑的应用系统，其缺点是系统的重构和复用非常困难。

我们认为，对于关键业务，第(2)或者是第(3)种模式是可行的，但必须有一个恰当的工作流引擎的支持，否则会显著地增加实际开发的难度和工作量。

2.2 为什么要基于关系结构

所谓基于关系的工作流引擎指的是工作流引擎中的数据模型（即机构模型和信息模型）全部通过关系结构来表达；控制工作流引擎运作的各种程序逻辑（即控制模型）也是通过常规关系数据库管理系统中所提供的存储过程、包以及触发器等机制来实现；同时，事务的并发控制也通过数据库系统所提供的机制来实现。

从技术角度来说，使用关系结构来表达工作流引擎中的数据模型可以降低工作流引擎开发过程中的技术难度和工作量。具体表现在：（1）与工作流引擎相关的各种控制数据（包括业务活动的状态数据）可以存储在数据库系统中；（2）与此相关的数据的完整性可以由数据库管理系统来维护；（3）利用关系结构可以方便地定义工作流引擎中的各种数据格式和数据结构；（4）可以方便地利用数据库管理系统提供的各种DML语句来操纵工作流引擎所需的各种数据。

从开发应用系统的角度来看，在同一数据库环境下为开发者提供一个基于关系结构的工作流引擎，并且如果这个工作流引擎所提供的功能可以方便地嵌入到应用的开发环境中，则可以降低开发应用的难度。这是因为：（1）针对关键业务的应用系统通常会采用一个常规的关系数据库系统作为后台的支撑；（2）应用系统的开发者往往会采用一种他们所熟悉的并且适合此数据库系统的前端开发工具来开发具体应用，这些前端开发工具一个显著特征是开发功能强大，但一般不具备工作流机制。因此，采用基于关系结构的工作流引擎很容易与应用的开发环境做到无缝的集成。

2.3 为什么要采用轻量级

轻量级的工作流引擎指的是从够用、灵活和低成本的设计原则出发，不追求工作流引擎的功能的完备和复杂，只是实现其中必不可少的功能和特征。在设计工作流引擎时主要考虑对其数据模型的定义和解释、活动之间的协调以及任务的分配和控制等功能提供支持，而不支持诸如提供内建（built-in）的应用开发工具、对应用数据的定义和完整性维护、完善的异常处理以及长事务控制等功能。

我们之所以采用“轻量级”这一特征来刻画工作流引擎主要出于如下考虑：

1）许多现有的工作流产品都在不同程度上提供了对外部工具的集成功能，部分产品还提供了基于表单的

应用逻辑的定制和开发环境。但是，外部工具的多样性和复杂性决定了对外部工具的集成难以做到无缝；而工作流产品内建的开发工具除了与流行的开发工具不兼容外，其开发功能往往都比较简单。因此，对于简单的应用（例如公文流转、订单的审批等），这些产品是合适的。但是，如果是开发关键业务的应用系统（特别是行业应用系统），现有工作流产品所能提供的开发功能是远远不够的。

2）许多针对DBMS的开发工具提供了极强的应用开发手段，但是这些开发工具往往不具备对工作流的机制的支持，而现有的工作流产品由于其出发点不同，很难与其他开发环境有机地融合在一起。因此开发人员往往苦于找不到一套合适的工作流支撑系统来开发具有工作流特征应用。

3）具有工作流特征的应用的形态千变万化，要想在工作流系统中对不同的应用（包括应用数据）进行统一的表示往往不遂人意。利用这种所谓灵活的工作流系统开发出来的应用在实际运作过程中反而表现不灵活。因此，另外一种相反趋势是，应用的逻辑仍旧由专用的应用开发工具去完成，工作流引擎只管理相关的控制数据，对应用数据只提供必要的关联手段将其与控制数据联结在一起。

4）目前已经有许多中间件产品（各种应用服务器、TP等）提供了对应用事务包括长事务的控制能力，对事务控制有特殊需求的应用系统可以使用这些产品。

新西兰Massey大学的Tagg[4]等学者对工作流引擎的描述曾经使用过“轻量级”这一术语，但其侧重点在于如何构造一个“瘦客户端”。我们的侧重点则是设计一个充分支持工作流特征的小型内核，它可以无缝地嵌入到传统的应用开发环境中。

综上所述，基于关系的轻量级工作流引擎是这样一种产品：它可以在传统的关系数据库基础之上定义工作流数据模型；它利用DBMS内嵌的编程语言来实现工作流引擎的控制逻辑；它提供了一系列比较完备的APIs，应用的开发者可以将这些APIs嵌入到自己的应用系统中从而实现具有工作流性质的信息系统。基于关系的轻量级工作流引擎的适用对象并非应用系统的最终用户，而是利用专用开发工具构造相应应用系统的专业开发人员。它为开发人员提供了驱动工作流的机制的支持，从而构造出各种灵活的具有工作流特征的应用系统。其具体表现形式为：一套表结构、一组建模工具和一系列供实际应用调用的APIs。 3数据模型

基于关系结构的轻量级工作流引擎的数据模型包括机构模型和信息模型两部分。机构模型描述的是企业或者部门的组织机构关系，信息模型则定义工作流引擎中所用到的各种控制数据。通过数据模型，可以方便地描述关键业务的业务规则、活动的依赖关系以及任务的指派等特征。它们都通过统一的关系结构来定义。图1给出了基于关系结构的轻量级工作流引擎的数据模型的ER图（限于篇幅只给出核心表结构）。

3.1 机构模型

与机构模型相关的表主要有STAFF、DEPARTMENT、TEAM、STAFF_TEAM、ROLE和STAFF_IN_ROLE，表之间的关系已经在图中通过不同含义的连线标出。下面将有重点地对其中的一些含义作出一些解释。

DEPARTMENT和TEAM分别表示部门和团队，部门通常表示纵向的行政隶属关系，而团队通常表示横向的合作关系。DEPARTMENT和TEAM分别通过相应的SUPER_DEPT_ID和SUPER_TEAM_ID关联使得在部门之间和团队之间分别形成树状的上下级关系

STAFF记录与人员相关的个体信息，其中的LOGGING_ON指示相应的人员目前是否已经登录到系统，ON_LEAVE表示该人员是否正处于休假期，这两种信息在工作流引擎中将被作为任务分配的指示信息。STAFF中的外码DEPT_ID指明该人员所隶属的部门。关系STAFF_TEAM指定了人员与团队之间的隶属关系。

机构模型中的部门、团队、人员以及相互间的关系为大型企业尤其是从事技术工作的企业的机构建模提供了有力的支持，同时也为现代企业流行的管理模式――“矩阵管理”提供了支持。当然，对于小型机构而言，完全可以考虑只定义DEPARTMENT或者TEAM其中之一。由于DEPARTMENT和TEAM之间在ER图中并无联系，因此缺其一并不会破坏机构模型的完整性。

ROLE进一步扩展了机构模型的建模能力，关系STAFF_IN_ROLE在STAFF和ROLE之间建立起来关联。在机构模型中引入角色这一概念主要是为了增强任务指派的能力，在本文的后续内容中将对角色中的有关概念作进一步的解释。

图1 数据模型ER图

3.2 信息模型

信息模型的核心是业务活动表（简称活动）ACTIVITY，其他相关的表结构主要有业务过程PROCESS、业务规则（活动流转规则）ROUTING_RULE、活动前依赖规则PRE_RULE、任务指派规则ASSGN_RULE、任务列表TO_DO_TASK_LIST以及已完成的任务列表HAVE_DONE_TASKS。从图中可以看出，ACTIVITY与其他表之间都存在联系。

3.2.1 活动类型

每个业务过程由若干业务活动组成，不同的业务活动通过各不相同的ACT_ID来唯一标识，ACT_TYPE则指明相应活动的类型。同一个业务活动在工作流运行时可能具有多个实例（instance）。我们将活动的实例称为任务2[2]，将属于同一业务过程的任务称为属于同一批次的任务。有的业务活动可能针对具体的业务环节，即在前台（后台）对应实际的应用逻辑；有的业务活动则不针对具体的业务环节。活动类型可以进行如下分类：

 INITIAL，初始化活动，业务过程的第一个活动，不针对具体业务环节。

 INTERACTION，常规交互活动，INTERACTION活动对应实际的业务环节，在前台对应实际的应用

逻辑，完成此活动需要实际人员的参与。在所有活动类型中，只有INTERACTION活动才需要与实际人员交互。

 AUTOMATION，常规自动活动，同样对应实际的业务环节，但是实际的应用逻辑位于后台，由工作流引擎自动调用完成。AUTO_EXECUTIVE指明相应应用逻辑的执行体。

 AND_BRANCH，与分支活动，不针对具体业务环节，此活动将同时派生出若干后继活动。  AND_MERGE，与汇聚活动，是一同步活动，不针对具体业务环节，流经此处的任务将进行与汇聚同步。此活动将进行活动的前依赖规则检查，只有所有的前依赖规则均被满足，才可流向后继活动。  OR_MERGE，或汇聚活动，是一同步活动，不针对具体业务环节，流经此处的任务将进行或汇聚同步。它同样将进行活动的前依赖规则检查，但是在前依赖规则只要存在一条满足指定条件的，就可以流向后继活动。OR_MERGE_FLAG用于指定或汇聚条件。

 VOTE_MERGE，投票汇聚活动，是一同步活动，不针对具体业务环节，同一批次的任务只有达到NUM_VOTES_NEEDED所指定的票数才可流向后继活动。

 DUMMY，哑活动，不针对具体业务环节，它可以作为某些活动的虚拟后继活动，还可以使用它来构造更为复杂的业务规则。若哑活动有后继活动，则可以立即流向后继活动。

 COMPLETION，终结活动，表明相应业务过程的终结，不针对具体业务环节。

3.2.2 业务规则的表示

在工作流引擎中，业务规则可以分解成活动的前依赖规则和活动的后转发规则。活动的前依赖规则指明相应活动的启动条件，启动条件是通过相应活动的直接前趋活动以及相应的状态标志来表示的，前依赖规则包含顺序、与汇聚、或汇聚和投票汇聚四种规则。活动的后转发规则指的是当前活动所对应的任务结束后该启动哪些后继活动，后转发规则包含顺序、或分支和与分支三种规则。图1中的PRE_RULE表、ROUTING_RULE表以及ACTIVITY表中的ACT_TYPE和RULE_APPLIED等字段联合表示活动的前依赖规则和后转发规则。

由于我们将各种汇聚活动单独抽取出来，因此可以用很简洁的关系结构来表达活动的前依赖和后转发规则。首先ACTIVITY表中的RULE_APPLIED字段指示相应活动应该采用何种规则判断准则，它可以有四种取值：DEFAULT、USER_DEFINED_PRE_RULE、USER_DEFINED_POST_ROUTING_RULE和USER_DEFINED_BOTH_RULE。DEFAULT表示由工作流引擎自动根据PRE_RULE表和

ROUTING_RULE表来进行规则检查。考虑到业务规则的多样性，本文提供了自定义方式来表达那些无法用缺省规则表示的特殊业务规则，ACTIVITY表中的EX_PRE_RULE_FUNC和EX_POST_RULE_FUNC分别指定了前依赖和后转发规则的自定义调用接口。自定义业务规则的行为完全由相应的程序确定。一

般情况下，大多数业务规则都可以直接通过DEFAULT方式表达。接下来将讨论在DEFAULT方式下前依赖规则和后转发规则的表示。

活动的后转发规则主要通过表ROUTING_RULE表示，后转发规则可以用如下四元组来表达： Post_Routing_Rule = (PRE_ACT_ID, CURR_ACT_ID, COMPLETION_FLAG, NEXT_ACT_ID_LIST)

其含义是：在当前活动的ACT_ID为CURR_ACT_ID的情况下，如果当前活动的前趋活动的ACT_ID为PRE_ACT_ID并且当前活动的结束标记为COMPLETION_FLAG的话，工作流将流向由

NEXT_ACT_ID_LIST所指明的后继活动。

前依赖规则则需联合PRE_RULE、ROUTING_RULE和ACTIVITY共同表示，前依赖规则可以用一个三元组来表达，即：

Pre_Dependency_Rule = (PRE_ACT_ID, CURR_ACT_ID, PRE_DEPNT_SET)

PRE_DEPNT_SET为前依赖活动集，其中的每一个元素又可以用另外一个三元组来表示：

Element_Pre_Depnt_Set = (DEPNT_ID, DEPNT_ACT_ID, DEPNT_ACT_STATUS)

Pre_Dependency_Rule的含义是：由前趋活动PRE_ACT_ID流转过来的当前活动CURR_ACT_ID能否启动取决于前依赖活动集PRE_DEPNT_SET中所包含的那些活动是否已经到达各自应该到达的结束状态DEPNT_ACT_STATUS。可以看出，只有在前依赖活动集中出现的那些前趋活动才可以联合构成对当前活动的约束关系，如果某个前依赖规则三元组中的PRE_DEPNT_SET为空集，则表明由此前趋活动流到当前活动的流转过程跟其他前趋活动没有任何关系，与此相应的当前活动可以立即启动。

3.2.3 任务队列和已完成任务队列

一个活动可以同时具有多个实例，即任务，这些实例可以是属于同一批次的，也可能属于不同的批次，流水号SERIAL_NO用来标识任务所属的批次，所有属于同一批次的任务具有相同的流水号；不同的任务之间则通过唯一的TASK_ID进行标识。

本文所讨论的轻量级工作流引擎并不涉及对具体的应用逻辑和应用数据的管理，但是，在工作流引擎中必须提供一种手段将任务与应用实体有机地关联起来，否则，单独的任务将不具有任何实际意义。实体标识ENTITY_ID便起到了这种桥梁作用，其取值的真实含义完全取决于应用逻辑的自身解释，例如它可以是某个编号，也可以是某个文件的名字。ENTITY_ID在业务初始化的时候设置，其值也可以在业务流转过程中被随时改变。

任务队列TO_DO_TASK_LIST用于记录那些已经创建但尚未完成的任务，位于任务队列中的任务具有四种状态：（1）PENDING，任务正处于“与汇聚”同步状态，即正在等待其他相关的前趋任务的结束；

（2）WAITING，任务已经就绪，处于“等待处理”的状态；（3）PROCESSING，任务处于“正在处理”的状态；（4）PAUSING，任务处于“暂停”的状态。

已完成任务队列HAVE_DONE_TASKS用于记录那些已经正常结束的任务，COMPLETION_FLAG表示相应任务的结束标记。

STAFF_ID表示执行此任务的实际人员，GRANTOR_ID若不为空，则表示此次任务的执行过程是经过授权的，GRANTOR_ID指明相应的授权人员。

3.3 任务指派

任务指派指的是依照何种准则将任务分配给具体人员来执行。只有常规交互活动才涉及到任务指派的问题；其他活动要么在前台不具备实际的应用逻辑，要么由工作流引擎自动调用，因此与任务指派没有关系。

在前文中已经提到了机构模型和信息模型中的许多表和字段将联合用于工作流引擎的任务指派，其核心表结构为ASSGN_RULE，每一个常规交互活动在ASSGN_RULE表都对应一条记录。BASED_ON指明任务指派的基准，它可以取如下四值之一：（1）DEPT_BASED，基于部门进行任务指派，DEPT_ID用于指定执行此活动的部门；（2）TEAM_BASED，基于团队进行任务指派，TEAM_ID用于指定执行此活动的团队；（3）ROLE_BASED，基于角色进行任务指派，ROLE_ID用于指定执行此活动的角色；（4）USER_DEFINED，基于自定义的方式进行任务指派，EX_FUNC指明相应的自定义执行程序。 任务指派的基准确定了可以执行相应任务的群体，具体指派到哪些实际人员还取决于任务指派方法METHOD，METHOD可以取如下值：

 ALL，任务将分配给由BASED_ON指定的群体中的所有人员。

 LEAST WORKING LIST，任务将分配给指定群体中的工作量最少的人员，工作量的多少可以通过TO_DO_TASK_LIST的统计数据得到。

 FCFA，先来先分配（First Coming First Assigning），即将任务队列中最早创建的任务分配给相应群体中最先提出执行任务请求的个体，任务的创建时间由DATE_CREATED指示。

 PRIORITY，基于优先数分配，只适合于ROLE_BASED任务指派基准。在表STAFF_IN_ROLE中有个字段PRIORITY_NUM用于指定相应人员的优先数，此方法将把任务分配给优先数最大的人员。

 ROUND ROBIN，轮转法，只适合于ROLE_BASED任务指派基准。

ROUND_ROBIN_TOKEN为轮转令牌，任务将分配给携有轮转令牌的人员。

4

4.1 图2

图2 应用框架

如图2所示，“可视化建模工具”即采用一套恰当的图示化的工具来对对业务过程进行描述，然后将其转换成如机构模型和信息模型中所述及的关系结构，从而建立起工作流引擎的数据模型。因此，“可视化建模工具”是工作流引擎在构造时的定义中心，而“引擎控制器”则是工作流引擎在运行时的控制中心，它负责工作流引擎在运行时的协调、调度和控制功能。根据具体应用的开发环境的不同，工作流引擎在应用框架中为不同类型的应用提供了不同的接口，例如C/C++接口、Java接口以及直接基于数据库通信协议的接口，从而为不同类型的应用与工作流引擎的交互提供了方便。应用框架中的“应用数据”则由具体的应用逻辑自行管理，工作流引擎并不关心这部分的数据格式。

图3 引擎控制器结构图 4.2 引擎控制器

引擎控制器是工作流引擎在运行时的控制中心，图3给出了引擎控制器的控制结构图。

 调度中心

调度中心接受从外部接口发送过来有关流程控制的请求（如业务初始化、获取任务以及结束任务等），然后根据不同的请求类型调用相应的处理模块完成与本次请求相关的操作并将结果返回。由于是在DBMS内部实现工作流引擎的控制模型，因此有关请求的并发处理等问题完全可以交给数据库管理系统来完成，也不需要诸如请求队列等形式的数据结构。因此，事实上可以将调度中心看成一个多线程的并发服务器，它可以对多个外部请求提供并发服务。对外部请求的处理过程中肯定会涉及到对内部数据结构（即工作流引擎的数据模型）中有关数据的读写和更改操作，这些数据的完整性和互斥操作则可以通过DBMS提供的各种加锁机制来实现，从而实现了多个外部请求之间的独立性。

 任务管理

任务管理主要根据调度中心的指示完成诸如任务创建、任务状态的转换以及相关数据的维护等工作。每次“结束任务”的外部请求将触发调度中心调用“任务管理”为后继活动（如果存在的话）创建新的实

图4 任务状态转换图

 任务指派

任务指派处理只是针对常规交互活动，通常情况下，在任务状态由“Pending”切换到“Waiting”过程中完成任务的指派工作，即处于就绪状态的任务在通常情况下都确定了其执行者（FCFA除外）。任务指派过程首先根据任务指派基准确定可以执行此任务的群体人员，通常情况下这是一个包含多个人员的集合；然后根据任务指派方法确定由这个群体中的哪些个体来执行任务，执行任务的个体标识记录在相应任务记录的STAFF_ID字段中。在3．4节中已经对任务指派方法进行了解释，这里有两点需要特别强调：

1）如果任务指派方法是“ALL”的话，将对当前的任务记录进行拷贝，即保证每一执行任务的个体在TO_DO_TASK_LIST中都有一条对应的记录；

2）如果任务指派方法是“FCFA”的话，事实上在任务指派阶段不不作任何工作，即相应任务记录的STAFF_ID字段为空。此时任务指派工作自动隐含在获取任务的请求中，即谁先发出获取任务的请求，就自动将此类型的任务分配给谁。

 依赖检查

依赖检查指的是活动的前依赖规则的检查，调度中心在将任务切换到就绪状态之前将进行相关的前依赖

规则检查，只有满足检查条件的任务才可以进行状态的切换。前文已经描述了前依赖规则在数据模型中的表示方法，这里主要讨论在控制模型中是如何对各种前依赖规则进行处理的。

对于顺序前依赖规则，很显然，从前趋活动流转到当前活动跟其他前趋活动没有关系，PRE_DEPNT_SET为空集，当前活动的启动没有其他约束条件，相应任务可以立即由“Pending”状态转换到“Waiting”状态。

对于与汇聚前依赖规则，PRE_DEPNT_SET中指明所有参与与汇聚的其他前趋活动，只有所有相关的前趋活动均到达各自指定的结束状态DEPNT_ACT_STATUS，当前活动方可启动。

对于或汇聚前依赖规则，PRE_DEPNT_SET为空集，此规则的检查将涉及到ACTIVITY表中的OR_MERGE_FLAG，OR_MERGE_FLAG的取值可以是所有相关的前趋活动的结束标记之一或者是一个特殊的标记“ANY”。如果OR_MERGE_FLAG的值不是“ANY”，则将检查相应前趋活动的结束标记COMPLETION_FLAG是否与OR_MERGE_FLAG相同，若相同，则启动当前活动，若不相同，则不作任何处理；否则，如果OR_MERGE_FLAG的值为“ANY”，则首先结束的前趋活动将启动当前活动，后结束的活动将被丢弃。

对于投票汇聚活动，PRE_DEPNT_SET同样为空集，当前活动要等到属于同一批次任务数目达到NUM_VOTES_NEEDED的要求方可启动。属于同一批次的任务数目可以通过对TO_DO_TASK_LIST按照ACT_ID和SERIAL_NO进行统计得到。

 转发控制

当应用发出“结束任务”的外部请求时，该请求将触发调度中心启动“转发控制”。转发控制的主要依据在工作流数据模型中定义的后转发规则，后转发规则定义了当前活动与其后继活动之间的关系。转发控制的处理过程是根据“结束任务”请求中所携带的“任务结束标记”以及相应前趋活动和当前活动的活动标识匹配ROUTING_RULE表中的记录，从而得到相应的后继活动列表NEXT_ACT_ID_LIST；然后由调度中心根据后继活动列表启动“任务管理”为相应的后继活动新建任务。

对于顺序转发以及或分支转发规则，NEXT_ACT_ID_LIST只包含一个活动；对于与分支转发规则，则NEXT_ACT_ID_LIST中将包含多个活动。

 启动控制

启动控制负责常规自动活动的所对应的自动执行体的启动并对其活动进行监控。

5应用实例

本文所讨论的基于关系结构的轻量级工作流引擎已经有一个具体的应用对象，即国家商标局的商标注册

与管理信息化系统。这是一个大型的信息系统，总共涉及到商标局各个业务处大约18个商标处理业务，如商标新申请业务、商标变更业务以及商标转让业务等等，所有这些业务都属于商标局的关键业务；同时，这也是一个具有海量数据的信息系统，在实施我们的项目之前，商标局已经有一个早期系统存储所有已经注册的商标的信息，总共有约100万条商标，超过10G字节的历史数据，以后随着商标业务的发展以及其他商标业务的电子化，数据量估计还将增加一个数量级。

在所有的商标业务中，大部分业务过程都比较复杂，例如商标新申请业务，光主要的业务活动就超过15个，这些业务活动发生既有顺序关系，也有并行关系，大部分都包含往复关系，相互间的依赖关系也比较复杂。通过调查，我们发现现有的工作流产品在流程控制、数据处理以及应用开发上都难以满足系统的需求。这迫使我们自己去设计和实现一个如本文所述的工作流引擎。我们采用Oracle公司的

Developer/2000开发商标业务的应用逻辑，然后在应用逻辑中嵌入对工作流引擎的调用从而实现流程的控制。目前，该系统已经全部开发完毕和测试工作，马上要投入正式运行。实际的应用实例表明，由于我们有一个基于关系结构的工作流引擎的支持，使得我们可以将注意力集中于应用逻辑的开发。基于关系结构的轻量级工作流引擎在关键业务的开发过程中体现出它的价值。

参考文献

[1] Hollingsworth D. Workflow Management Coalition: The Workflow

Reference Model. Document Number WFMC-TC00-1003, Brussels, 1994

[2] WfMC. Workflow Management Coalition Specification: Terminology &

Glossary. Document Number WFMC-TC-1011, Brussels, 1996

[3] Karl R.P.H. Leung et al. The Liaision Workflow Engine Architecture.

In: Proc of the 32nd Hawaii Int’l Conf on System Sciences, Hawaii, Jan. 1999, http://www.computer.org/proceedings/Hiccs2/

[4] R.Tagg et.al. Preliminary Design of a Lightweight Workflow Server.

In: 8th Australasian Conf on Information Systems, Australia, 1997, http://business.unisa.edu.au/acis97/