? 每次操作都需要维护业务数据和流程的一些相关数据。
$ $客户采购$订单处理工厂生产物流发货库存管理
图1-1 订货流程示意图
? 一旦业务流程变更，就需要大量地更改程序，甚至重新开发以适应新的需求。 ? 监视、控制、分析流程处理情况的应用还需要单独开发，且成本不低。 结果这个业务系统可能是如图1-2所示的情况，请注意这还不包括监视、控制、分析流程的部分。
$ $$界面客户采购系统流转控制业务逻辑数据界面订单处理系统流转控制业务逻辑数据界面生产系统流转控制业务逻辑数据界面库存管理系统流转控制业务逻辑数据界面物流系统流转控制业务逻辑数据 图1-2 不使用工作流技术实现订货业务流程
第1章 工作流基础 | 7
下面我们看看使用工作流技术实现上述的订货流程将会是一种什么情况，如图1-3所示。
流程监控业务数据分析流程设计业务交互界面简单的业务逻辑独立的业务数据工作流引擎 $ 客户采购$$订单处理工厂生产物流发货库存管理流程数据 图1-3 使用工作流技术实现订货业务流程
很明显，位于右侧的工作流管理系统接管了所有订货业务在流程方面的定义和执行，这包括：
? 使用专门的“流程数据”系统，维护所有涉及流程流转的数据。
? 提供“流程设计”工具，帮助用户定义订货流程的模型，这一般都是基于图
形界面可视化的。
? 工作流引擎作为工作流管理系统的核心，负责解释流程定义、管理流程数据、
计算和驱动流程实例的运行??其作用如同大脑之于人体。
? 工作流引擎提供众多API（Application Programming Interface，应用编程接口）
供客户端应用程序或外部业务系统调用，将特定的“业务（例如：订货）”纳入“流程”的管理和控制之中，从而实现工作流管理和业务操作的完美结合。
8 | jBPM4工作流应用开发指南
? 工作流引擎还提供众多API供流程的“增值”系统使用，例如流程监控系统
可以使用工作流引擎提供的API去监视流程的执行过程、挂起和恢复流程实例的运行；流程数据分析系统可以使用工作流引擎提供的API分析出工作完成的效率、业务流程的瓶颈等结果，以便重组流程、优化业务。
综上所述，引入工作流技术对于技术开发来说，有如下好处：
? 降低开发风险——通过使用诸如活动、流转、状态、行为这样的术语，使得
业务分析师和开发人员使用同一种语言交谈成为可能。优秀的流程设计建模工具，甚至能使开发人员不必将用户需求转化成详细设计文档。
? 流程实现的集中统一—应对业务流程经常变化的情况，使用工作流技术的
最大好处是使业务流程的实现代码，不再散落在各式各样的业务系统中。 ? 加速开发—开发者不用再关注流程的参与者、活动节点的衔接、流转控
制??因为这些工作很多被工作流框架接管了。因而开发者开发起来更快、代码出错更少、系统更加容易维护。
? 提升对迭代开发的支持—如果系统中业务流程部分被硬编码，就不容易更
改，需求分析师就会花费很大的精力在开发前的业务分析中，并且希望一次成功。但可悲的是，在任何软件项目开发中，这都很少能实现。工作流管理系统使得业务流程很容易部署和重新编排，业务流程相关的应用开发可以以一种“迭代/渐进”的方式推进，也就是说工作流技术在某种程度上支持“需求分析不必一次完全成功”。
1.2 工作流管理系统的发展历程
如果说数据库系统（Database Systems）的发展历程像受人尊敬的智者讲述条理清晰的故事，那么工作流（Workflow）的发展历程就像一群乳臭未干的小子们在大谈各自的“哲理”。
之所以这样比喻是想指出，工作流管理系统相对于数据库系统还处于技术曲线上的发展阶段。这是一个激动人心的阶段，但不是一个成熟的阶段。为了证明这一点，我们可以拿工作流管理系统和关系型数据库系统（RDBMS）做一个对比：当在软件开发团队中谈论关系型数据库系统时，例如Oracle，SQL Server等，大部分技术人员会有一个清晰的概念，在您和他们交流的时候，他们会通过轻微的点头表示认可或理解您所说的。可当您使用工作流术语和他们讨论工作流时，他们很可能会摇头表示其他意见，因为很多人对工作流术语都有不同的理解。
第1章 工作流基础 | 9
形成这种状况的原因之一是，在“早期”的工作流中使用了过多的概念，至今尚未完全统一。在这个领域中有大量存在差异的规范和工具，当然，它们相互之间有重叠并且会相互参考引证。
图1-4演绎了工作流管理系统从无到有的“进化”历程。
应用
应用
1965-1975 1975-1985
应用 应用
1985-1995 1995-2005
图1-4 工作流管理系统的“进化”历程
通过上面这张图，我们了解到企业应用软件的发展走过了这样一个历程：
1） 最初的企业应用直接架设在操作系统（Operation System, OS）之上，应用的
程序和数据混合在一起，耦合之紧，超乎想象。这大约是在1965—1975年。 2） 后来，人们发现程序和数据混合在一起，维护起来太困难了——您能想象把
所有的数据记录都硬编码在程序中吗？于是，人们把数据库管理系统从应用系统中剥离出来，自成一派。这大约是在1975—1985年。
3） 再后来，随着企业应用复杂度的增加，人们对人机交互的需求越来越高，架
构师们发现把应用程序的逻辑和用户界面（User Interface, UI）也分离开是个不错的主意。这样底层的开发者可以专注于业务逻辑的实现，而前端的UI工程师可以全力去追求交互体验，同时一套业务逻辑的实现还可以与不同的UIMS（User Interface Management System，用户界面管理系统）相匹配，应用的灵活性得到了提升，同时成本也能下降。这大约是在1985—1995年。 4） 随着时代的发展，企业应用有了相对独立的DBMS和UIMS，越来越能适应
变更频繁、复杂化、大型化的需要了??这时候，瓶颈又出现了，如同本章
前几节所描述的，现代企业对于业务流程的需求正在发生以下变化。 ? 变得更重要（业务流程化）。 ? 越来越需要适应频繁的变化。 ? 变得更复杂。
10 | jBPM4工作流应用开发指南
? 企业内部的业务流程总数在不断增加。
??
由此催生了工作流管理系统。
这个发展历程的具体时间列表如下：
? 工作流技术起源于20世纪70年代中期办公自动化领域的研究工作。其中的
SCOOP和OfficeTalk系统，不但标志着工作流技术的开始，而且也是最早的OA系统。
? 20世纪80年代初期，工作流技术伴随着OA系统走向商用，但是很少、范围
很有限。
? 20世纪80年代后期，OA系统的研究逐渐走向非主流，取而代之的是群件
（Groupware）和工作流管理系统。
? 20世纪90年代以后，相关的技术条件逐渐成熟，工作流管理系统的开发与研
究进入了一个热潮。但20世纪90年代工作流管理系统的迅速发展也带来了很多问题，例如术语的泛滥、过多的概念、体系结构上的五花八门、没有统一的可交互接口等。
? 1993年8月，工作流技术标准化的工业组织——工作流管理联盟（Workflow
Management Coalition，WfMC）成立。
? 1994年，工作流管理联盟发布了用于规范和指导工作流管理系统架构的“工
作流参考模型”，并相继制定了一系列工业标准。
? 2001年，BPMI （Business Process Management Initiative）标准组织成立，于
同年11月13日发布BPML 1.0业务流程语言规范。
? 2002年8月9日，BEA公司、微软公司和IBM公司共同发布了一个新的业
务流程语言规范BPEL4WS （Business Process Execution Language for Web Services），并提交到了OASIS组织。
以下将重点介绍工作流技术发展历程中的两个重要的里程碑——工作流管理系统参考模型和BPM。
1.2.1 工作流管理系统参考模型
许多软件开发商都有工作流产品，并且不断有新的工作流产品走入市场。市场上可选择的产品范围很大，因此每个开发商只关注产品的特殊功能，而用户可以采用不同的产品来满足不同的需求。
第1章 工作流基础 | 11
jBPM4工作流应用开发指南 01
