jBPM 工作流应用开发指南


2 | jBPM4 工作流应用开发指南 第 1 章 工作流基础 本章将为您开宗明义地介绍工作流这门科学,使您了解这门“很有前途的”技术 的概念、发展历程以及目前的状况,并给您一个选择 jBPM 的理由。 1.1 工作流概念 工作流管理联盟(即 WfMC,这个组织在后面会介绍)对于“工作流”这个概念 的经典定义为:全部或者部分由计算机支持或自动处理的业务过程。 工作流管理系统(Workflow Management System, WFMS)是这样一个软件包:它 通过执行经过计算的流程定义去支持一批专门设定的业务流程。它被用来支持定义、 管理和执行工作流程。 因此,对于我们来说,工作流管理系统的目标是:管理工作的流程以确保工作在 正确的时间被期望的人员所执行——在自动化进行的业务过程中“插入”人工的执行 和干预,可以说正是工作流管理系统的价值所在,也是工作流系统开发者的主要工作 内容。 1.1.1 工作流管理思想之于企业现代化管理 提示:工作流经常与“业务过程重组(BPR,Business Process Re-engineering)” 联系在一起。BPR 是关于企业(组织)核心业务过程的评估、分析、模拟、定义, 以及其后的操作实现。尽管不是所有的 BPR 都是采用工作流技术实现的,但工作流 技术是实现 BPR 的最佳方法。这主要是因为工作流技术提供了业务过程逻辑与 IT 操作支持的分离,从而可以通过修改过程规则来重定义业务过程。当然,工作流技 术并不只在 BPR 中采用。 第 1 章 工作流基础 | 3 专业分工及组织分层机制是西方国家大规模工业化改造成功的前提。在托福勒的 《第三次浪潮》一书中,对“大就是好”的大规模生产时代进行了详尽的描述,并预 言该时代将终结。但十多年过去了,大企业并未消失,而是采用了 BPR 及其他先进思 想使自己获得了新生。 “铁路警察,各管一段”式的专业分工、精细化的组织机构、职能部门制度是造 成企业(特别是大型企业)僵化的主要原因。企业僵化主要有如下特征:  每个员工取悦的是自己的“上司”,因为上司掌握员工的地位、薪酬,每个员 工可以冷落顾客,但丝毫不敢怠慢“领导”。  职能部门以专业划分,在企业中形成一个个的利益中心,部门之间的边界极 为明显,在一项业务涉及多个部门时,若发生利益冲突,各部门可以把全公 司利益放到一边,维护自己的利益。协调内部矛盾耗去了大量的企业精力。  为了加强“内部管理”,企业建立大量制度及审批手续,但几乎找不到几条是 为了更好、更快地向顾客提供优质服务的条款,基本上全部是监督内部职工 的。层层审批、众多领导“签字”的制度,大大降低了企业的运行效率,也 是推卸责任的最好方式。  所有员工追求的是“当官”,一旦“升迁”,地位、名义、薪酬均将“旧貌换 新颜”,否则“人微言轻”,一切名义、待遇无从谈起。在此情况下,员工要 么跳槽,要么混日子,这是现代企事业单位官职重叠的原因之一。  公文旅行、文牍主义存在于各个企业,对公文、报告、表格的检查、校对及 控制是企业工作极其重要的基础工作,可以压倒一切。大量的人力、物力投 放在此?他们都忘了企业的真正生存目的是什么! 当然,以上是属于较为严重的情况,在国内企业中比较常见。而西方一些大型企 业最常见的问题是各种制度均已健全,但已出现老化,甚至有的已严重阻碍企业的发 展,增大了企业的运营成本,使企业失去了竞争力。 事实上,一些西方企业已经意识到此类问题,尝试了各种解决办法,在 BPR 理论 刚出现时,就立即进行实践,甚至到了“狂热”的地步,许多企业获得了新生,如 IBM、 HP、沃尔玛、宝洁、711、福特等。 实施“BPR/工作流管理”的主要原则有三个: 1) 以顾客为中心——全体员工建立以顾客而不是“上司”为服务中心的原则。 顾客可以是外部的,如零售商业企业,柜台营业员直接面对的是真正的顾客; 可以是内部的,如商场的理货员,他的顾客是卖场的柜台小组。每个人的工 4 | jBPM4 工作流应用开发指南 作质量由他的“顾客”做出评价,而不是“领导”。 2) 企业的业务以“流程”为中心,而不以一个专业职能部门为中心进行——一 个流程是一系列相关职能部门配合完成的,体现于为顾客创造有益的服务。 对“流程”运行不利的障碍将被铲除,职能部门的意义将被减弱,多余的部 门及重叠的“流程”将被合并。 3) “流程”的改进必须具有显效性——改进后的流程必须提高效率,消除浪费, 缩短时间,提高顾客满意度和公司竞争力,达到降低整个企业运营成本的目 标。 最终,“BPR/工作流管理”可能对企业的各方面产生如下积极影响:  对组织机构的影响——业务流程管理对企业的“冲击”是巨大的,实施后企 业的职能部门数量和级别会压缩,企业的组织机构不再是“多级管理”,而是 呈现“扁平化”趋势。以专业技术组织的职能部门仍将存在,但部门之间的 “边界”大大淡化。部门经理的权力有限,一般只是制定战略、培训及管理 人员,员工的直接服务对象是“顾客”,而不是“上司”。  流程团队(Process Team)在企业中体现出重要的地位——按照一定的流程 组成的团队活跃在企业经济活动中,这个“流程团队”可以是临时的,也可 以是永久的。一个流程团队可以跨越许多专业部门,例如在一个计算机公司 内,为了一个项目,可以由市场部、销售部、技术部、维修部、财务部等多 部门共同组成一个临时的流程团队。这样,企业可以以一个整体面向用户, 避免了在销售时,同一公司的不同部门络绎不绝地出现在同一个用户面前; 而在维护系统时,用户则不知道去找谁。同样的,在一个商场内,对于某类 商品的进货业务,可以由商品部、采购部、财务部、小组、库房等组成一个 永久的流程团队,用以提高商品进货的效率和商品的适销度。  对人事管理及考核、薪酬制度的冲击——由于采用“流程”为工作重点,对 以官本位为基础的专业职能及人事管理体制,产生了极其猛烈甚至是残酷无 情的冲击,分析并量化工作流程将是一项复杂及崭新的挑战,对各级管理人 员的评定将不再是主观的判断,整个流程的执行结果将是人员考核、薪酬评 定的新标准。  对员工的积极要求——在运作中,员工将分为具有领导及沟通能力的“流程 领导者”和各类应用专家,每个人可以根据自身特点选择自己的发展方向, 这样只要认真努力,自然会拥有名誉及地位。例如在微软公司的项目组中, 一个级别较低的 PM(项目经理)可以领导一个技术级别等同于比尔∙盖茨的 技术专家。在此情况下,每个人追求的可能将不再是各级“经理”、“处长” 第 1 章 工作流基础 | 5 等职务,而是各种“专家”等称号。  对企业管理方式的冲击——国内有些企业有个误区,提起加强管理,就是制 定出数大本《××企业管理制度汇编》,然后监督执行。但我们同样可以看到, 许多管理制度健全并严格执行的国营企业仍然被市场无情地抛弃了,这就是 只重局部管理、不看整体流程所造成的,可以称之为“见木不见林”。我们可 以在事后埋怨体制,但事实上,整体流程的僵化往往是企业自己套在脖子上 的绳索。 因此,真正的工作流管理思想对于企业的改造是全面彻底的,大部分僵化体制将 被打破、重组。也许您要问,企业能够直面这样的现实吗?但无论如何,只有重视顾 客、关心流程、高效响应的企业,才能生存在今后的市场中。 1.1.2 工作流技术在企业中的应用 工作流技术是一项快速发展的信息化技术,各种行业企业都在逐渐采用工作流管 理系统。 工作流技术的主要特点是过程的自动化处理(这些过程包含人与以机器交互为基 础的人工活动)。 因此,目前工作流技术广泛应用于办公室环境中,例如保险、银行和行政管理等。 其价值主要体现在: 1) 协助涉及多人(或多个部门)相关任务的工作执行。  大部分工作流管理系统都有一个方便的机制,来生成和处理执行任务的电子 表单,使各个部门人员能方便地通过这种机制实现交互,“参与”到业务流程 中来。  对于专注于 ISO 或者 CMM 认证的组织,通过这种方式使用工作流管理系统 能够显著地提升“规范化流程”的运转速度,从而提高生产率。  不用将业务过程用文字的形式记录在纸上——工作流管理系统能使用户方便 地通过流程建模实现业务过程的定义以及自动化执行。 2) 作为企业应用集成(Enterprise Application Integration,EAI)的平台。  对于大型企业来说,各种各样的异构应用和数据运行在企业内部。  工作流管理系统并不是专门的业务系统,但工作流管理系统和专门业务系统 是互补的。  大部分工作流管理系统具有结合专门业务应用、构建统一 EAI 平台的能力。 6 | jBPM4 工作流应用开发指南 3) 嵌入式工作流引擎。  “专门业务应用”将指定业务领域的相关业务流程固化在信息系统中。开发专 门业务应用的公司可以考虑将工作流引擎嵌入到他们的专门业务信息系统中。  在这种情况下,工作流引擎作为一个应用组件,对于应用的最终用户是不可 见的,应用的最终用户也完全不需要知道工作流的存在。将工作流引擎嵌入 到应用中的主要目的是为了加强应用的扩展性和系统的可维护性。 综上所述,引入工作流管理技术对于企业业务过程的提升主要表现在:  提高运转效率——业务流程在“自动化运行”过程中会暴露出一些业务流程 中不必要的步骤。  较好的流程控制——使得大家执行标准的工作方法和跟踪审计成为可能。  改进客户服务——因为流程的一致性控制,提高了对客户响应的可预见性。  使企业变得“灵活”——方便企业业务流程重组。  促进业务改进——使得专注于流程的业务趋向于流畅和简单。 1.1.3 如何从一个开发者的角度看工作流技术 前面说了那么多思想、业务之类的东西,无非是想说明工作流技术对于企业有什 么样的好处,但对于一个开发者,坦白地说就是一个写代码的人,工作流管理对于企 业业务过程改进的提升也许离他们有点远了。使用工作流技术体系开发软件系统对开 发者又有何好处呢? 举个例子说明。 现在我们来看一个简单的业务——订货流程: 1) 客户提交采购订单。 2) 业务员执行订单处理。 3) 如果缺货,转工厂生产。 4) 仓库出货。 5) 物流发货。 整个流程如图 1-1 所示。 不使用工作流技术,从头开始开发这个订购流程的业务系统,我们需要:  每个活动节点都要开发交互界面和后台处理程序。  每次活动的流转都需要硬性判断下一步活动节点及其处理人。 第 1 章 工作流基础 | 7  每次操作都需要维护业务数据和流程的一些相关数据。 订单处理 库存管理 $ $ $ 客户采购 物流发货 工厂生产 图 1-1 订货流程示意图  一旦业务流程变更,就需要大量地更改程序,甚至重新开发以适应新的需求。  监视、控制、分析流程处理情况的应用还需要单独开发,且成本不低。 结果这个业务系统可能是如图 1-2 所示的情况,请注意这还不包括监视、控制、 分析流程的部分。 $ $ $ 客户采购系统 界面 数据 库存管理系统 物流系统 流转控制 业务逻辑 界面 数据 流转控制 业务逻辑 订单处理系统 界面 数据 流转控制 业务逻辑 界面 数据 流转控制 业务逻辑 界面 数据 流转控制 业务逻辑 生产系统 图 1-2 不使用工作流技术实现订货业务流程 8 | jBPM4 工作流应用开发指南 下面我们看看使用工作流技术实现上述的订货流程将会是一种什么情况,如图 1-3 所示。 业务 独立的业务数据 业务交互界面 订单处理 库存管理 $ $ $ 客户采购 物流发货 工厂生产 流程数据 工 作 流 引 擎 流程监控 数据分析 流程设计 简单的业务逻辑 图 1-3 使用工作流技术实现订货业务流程 很明显,位于右侧的工作流管理系统接管了所有订货业务在流程方面的定义和执 行,这包括:  使用专门的“流程数据”系统,维护所有涉及流程流转的数据。  提供“流程设计”工具,帮助用户定义订货流程的模型,这一般都是基于图 形界面可视化的。  工作流引擎作为工作流管理系统的核心,负责解释流程定义、管理流程数据、 计算和驱动流程实例的运行„„其作用如同大脑之于人体 。  工作流引擎提供众多 API(Application Programming Interface,应用编程接口) 供客户端应用程序或外部业务系统调用,将特定的“业务(例如:订货)”纳 入“流程”的管理和控制之中,从而实现工作流管理和业务操作的完美结合。 第 1 章 工作流基础 | 9  工作流引擎还提供众多 API 供流程的“增值”系统使用,例如流程监控系统 可以使用工作流引擎提供的 API 去监视流程的执行过程、挂起和恢复流程实 例的运行;流程数据分析系统可以使用工作流引擎提供的 API 分析出工作完 成的效率、业务流程的瓶颈等结果,以便重组流程、优化业务。 综上所述,引入工作流技术对于技术开发来说,有如下好处:  降低开发风险——通过使用诸如活动、流转、状态、行为这样的术语,使得 业务分析师和开发人员使用同一种语言交谈成为可能。优秀的流程设计建模 工具,甚至能使开发人员不必将用户需求转化成详细设计文档。  流程实现的集中统一—应对业务流程经常变化的情况,使用工作流技术的 最大好处是使业务流程的实现代码,不再散落在各式各样的业务系统中。  加速开发—开发者不用再关注流程的参与者、活动节点的衔接、流转控 制„„因为这些工作很多被工作流框架接管了。因而开发者开发起来更快、 代码出错更少、系统更加容易维护。  提升对迭代开发的支持—如果系统中业务流程部分被硬编码,就不容易更 改,需求分析师就会花费很大的精力在开发前的业务分析中,并且希望一次 成功。但可悲的是,在任何软件项目开发中,这都很少能实现。工作流管理 系统使得业务流程很容易部署和重新编排,业务流程相关的应用开发可以以 一种“迭代/渐进”的方式推进,也就是说工作流技术在某种程度上支持“需 求分析不必一次完全成功”。 1.2 工作流管理系统的发展历程 如果说数据库系统(Database Systems)的发展历程像受人尊敬的智者讲述条理清 晰的故事,那么工作流(Workflow)的发展历程就像一群乳臭未干的小子们在大谈各 自的“哲理”。 之所以这样比喻是想指出,工作流管理系统相对于数据库系统还处于技术曲线上 的发展阶段。这是一个激动人心的阶段,但不是一个成熟的阶段。为了证明这一点, 我们可以拿工作流管理系统和关系型数据库系统(RDBMS)做一个对比:当在软件开 发团队中谈论关系型数据库系统时,例如 Oracle,SQL Server 等,大部分技术人员会 有一个清晰的概念,在您和他们交流的时候,他们会通过轻微的点头表示认可或理解 您所说的。可当您使用工作流术语和他们讨论工作流时,他们很可能会摇头表示其他 意见,因为很多人对工作流术语都有不同的理解。 10 | jBPM4 工作流应用开发指南 形成这种状况的原因之一是,在“早期”的工作流中使用了过多的概念,至今尚 未完全统一。在这个领域中有大量存在差异的规范和工具,当然,它们相互之间有重 叠并且会相互参考引证。 图 1-4 演绎了工作流管理系统从无到有的“进化”历程。 图 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,越来越能适应 变更频繁、复杂化、大型化的需要了„„这时候,瓶颈又出现了,如同本章 前几节所描述的,现代企业对于业务流程的需求正在发生以下变化。  变得更重要(业务流程化)。  越来越需要适应频繁的变化。  变得更复杂。 应用 应用 应用 应用 1965-1975 1975-1985 1985-1995 1995-2005 第 1 章 工作流基础 | 11  企业内部的业务流程总数在不断增加。 „„ 由此催生了工作流管理系统。 这个发展历程的具体时间列表如下:  工作流技术起源于 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 工作流管理系统参考模型 许多软件开发商都有工作流产品,并且不断有新的工作流产品走入市场。市场上 可选择的产品范围很大,因此每个开发商只关注产品的特殊功能,而用户可以采用不 同的产品来满足不同的需求。 12 | jBPM4 工作流应用开发指南 然而,由于各个厂商不兼容的流程控制方式,导致没有统一的规范使得不同的工 作流产品协同工作。对于这个问题,业界一直认为,所有的工作流产品都有一些相同 的特性,只要其各种功能遵循公共的标准,就可以实现不同工作流产品间的协同工作。 由此 WfMC 应运而生,WfMC 的全称是 Workflow Management Coalition——工作 流管理联盟,它是由一些公司联合在一起成立的组织,从事工作流问题的研究和指导。 图 1-5 所示就是 WfMC 提出的工作流管理系统参考模型(Reference Model of the Workflow Management Coalition)。作为工作流技术标准化的工业组织,WfMC 的这个 参考模型无疑为各家工作流管理软件提供者的系统设计规划给出了权威的参考,乃至 标准。 图 1-5 工作流管理系统参考模型 首先,最重要的部分就是中间的工作流引擎,可以说它就是整个工作流管理系统 的心脏,因为所有的工作流管理系统都要使用工作流引擎: 1) 为执行的流程实例解释流程定义——这些流程定义一般都是由接口1获得的。 2) 组织调度流程的实例,推进工作流程的前进,这包括条件流转、分支聚合、 第 1 章 工作流基础 | 13 父子流程„„ 3) 处理工作任务的分配、接受、提交等行为——无论是人工干预或自动执行的 任务,都需要经过工作流引擎计算和持久化(如果需要的话)。 4) 管理调用其他的 4 个接口——这可能包括执行工作流程定义中的一些外部脚本。 工作流引擎做的工作就像心脏把血液不断地送到身体的各个部分一样。关于工作 流引擎应该如何架构和设计,在本书后面章节会涉及。 那么,接下来说说工作流管理系统“身体”的 5 个组成部分吧,也就是图 1-5 所 示的 5 个接口。  接口 1——流程定义工具。 ■ 前面提到过我们使用它来设计业务流程定义供工作流引擎来实例化运 行。所谓的“业务流程定义”一般来说就是一段 XML,它 一般遵循 XPDL (XML Process Define Language)标准、BPEL(Business Process Execution Language)标准或其他厂商自定义的标准(例如 jBPM 的流程定义语言 就是 jPDL)。事实上可以把流程定义工具理解为一个产生 XML 的图形化 设计建模软件。这种软件各个厂商的技术实现可谓五花八门,仅基于 Web 的就有很多种技术实现,例如 Java Swing,Flash,ActiveX;当然,很多 开源项目采用的还是基于客户端的实现,例如 jBPM 使用的是基于 Eclipse 图形化插件的实现,Shark Workflow 使用的则是 JAWE(一种基 于 Java 技术实现的 XPDL 建模工具)。当然,它们的最终目的都是统一 的——产生 XML 格式的流程定义。  接口 2——工作流客户端应用。 ■ 这很有意思,当业务流程设计好了、运行起来了,那么我们——“人类” 如何与工作流引擎交互呢?这时候,工作流引擎就通过接口 2,为我们 提供各种各样的工作任务列表、工作表单、流程列表以及一些查询功能。 我们通过这些接口应用,就可以填写表单、处理任务„„ 从而实现人与 工作流引擎的沟通。  接口 3——执行外部应用。 ■ 工作流引擎通过这个接口去执行一些外部的或面向专门职能领域的应用 程序,例如财务系统、报表系统等,让第三方系统参与进来,从而完成 定义的工作流程。这看起来就像 EAI(Enterprise Application Integration, 企业应用集成)的特性,而事实上它也可以说就是 Workflow EAI。同时 14 | jBPM4 工作流应用开发指南 我们也可以发现接口 2 和接口 3 之间的界定有些模糊,难道接口 2 提到 的“工作任务列表”不能算是外部的应用程序吗?没错!这个问题确实 存在,这也就是为什么荷兰工作流大师 Aalst 在其著作《工作流管理—— 模型、方法和系统》中写道“建议每个应用程序都由此‘应用程序执行 服务’打开”的原因,他是在建议统一这两个接口吗?总之,接口 3 在 标准化方面众口不一。  接口 4——其他工作流应用接口服务。 ■ 用来处理若干自治工作流管理系统之间的工作交换,例如实例转移、工 作任务外包等。事实上,WfMC 组织的初衷是想通过这个接口来连接各 个不同的工作流引擎和系统,使它们在一个统一的标准下工作和交流。 想法是非常不错的,但是,由于种种原因吧,作者认为是商业利益的因 素以及 WfMC 还没有强大到能“号令江湖,莫敢不从”的地步,所以到 目前为止,接口 4 基本不被支持,也就是说,各大厂商的工作流产品并 不能用同一种语言对话。但是,随着 jBPM4 推出的 PVM—流程虚拟 机技术(这在本书的后面会涉及)的发展,实现接口 4 的障碍也许能被 打破。您可以拭目以待。  接口 5——管理和监控工具。 ■ 虽然很多工作流管理系统,特别是开源工作流管理系统实现的最简单部 分就是这个接口,但作者认为最能体现工作流管理系统在企业管理方面 价值的就是这个部分,它主要被用来搜集管理信息,这包括诸如工作流 系统功能管理工具、流程实时监视和控制工具,以及工作效率分析和流 程覆盖面分析等各种商业智能工具,这为提升企业的管理能力、优化重 组企业的业务流程、分析企业内部的工作效率瓶颈等提供了重要的量化 数据支持。我们说“工业化解放人类的体力,信息化解放人类的智力”, 这个接口提供的功能不正是解放了流程企业领导和决策者们的智力吗, 而这正是企业信息化的初衷、工作流管理的最终价值所在。传统的工作 流管理系统在这个接口上的“短板”,正为下一节要说的 BPM(Business Process Management)这个概念的支持者提供了攻击工作流技术的口实, BPM 概念在这个接口上的强化成了很多人认为“Workflow 系统”不等同 于或弱于“BPM 系统”的重要原因。事实上,这都不过是些概念而已, 实现工作流管理系统、解决业务流程改进方面的问题才是我们所要做的。 总结一下,工作流管理系统参考模型的 5 大接口各自强调了什么? 第 1 章 工作流基础 | 15 接口 1——提供流程定义。 接口 2—提供工作任务列表等客户端应用程序,实现使用者与工作流引擎的沟通。 接口 3——支持外部应用程序参与工作流程。 接口 4——支持不同工作流引擎系统间的连接。 接口 5——提供监控工具,搜集管理信息。 还有一些问题供读者思考: 接口 3 和接口 5 标准化工作进展较为缓慢,为什么?读者可以参考上文的说明思 考得出。 接口 3 和接口 4 需要完善的地方很多,例如,流程和工作任务的事务、回滚(包 括被动退回和主动取回的任务)问题,在这两个问题上如何处理、怎么处理好、如何 保持原子性,如何进行“补偿”,乃至如何支持“中国特色”的业务,都是很有思考空 间的。 1.2.2 BPM BPM 即业务流程管理(Business Process Management)。其注重点是通过建模、自 动化、管理和优化流程,来优化公司业务的效率和效果。BPM 打破了跨部门、跨系统 和跨用户,强调端对端的业务流程。BPM 系统运行在公司的内部和外部,不仅员工, 客户、合作伙伴和提供商都能够进入该系统。同时,在公司内部 BPM 的应用系统还包 含了提升业务的可视水平和可预见水平的功能。 BPM 通常以 Internet 方式实现信息传递、数据同步、业务监控和企业业务流程的 持续升级优化。从这方面来说,BPM 不但涵盖了“传统工作流”的流程传递、流程监 控的范畴,而且突破了“传统工作流”技术应用范围的瓶颈。 BPM 同样需要流程定义语言来描述流程。流程定义语言可以将企业中的各种业务 流程表示成一种格式化(甚至可视化)的模型。 BPM 的相关技术标准可以用来定义业务流程和 Web Service 的集成与部署,以达 成企业业务目标。也就是说,BPM 语言不仅拥有 XML 表示的流程定义,还延伸到了 SOAP,WSDL,UDDI 等多项技术规格。 16 | jBPM4 工作流应用开发指南 除了 WfMC 的 XPDL(XML-based Process Definition Language)语言外,当前的 BPM 相关标准和语言为数还不少,较为著名的有:  BPMI 的 BPML(Business Process Modeling Language)。  ebXML 的 BPSS(Business Process Specification Schema)。  BEA,Microsoft,IBM 联合制定的 BPEL4WS(Business Process Execution Language for Web Services, BPEL)。  Sun Microsystems,SAP,Oracle,Italio 等公司共同制定的 WSCI(Web Service Choreography Interface)。 事实上,这些标准都利用活动作为组成流程定义的基本元素,运行过程中,每一 个活动伴随一组流程实例相关数据(Instant-Relevant Data),这个相关数据最重要的作 用就是作为流程传递逻辑(Routing Logic)的评估条件,相关数据在 BPML 中称为 Property,在 XPDL 中称为 Workflow-Relevant Data,在 BPEL 中称为 Container。 在着重点方面,XPDL 标准着重在工作任务分配的相关处理,例如如何指定活动 运行所需的资源与应用程序。BPML 标准着重在定义 Web Service 的相关处理,例如支 持事务与异常处理、定义特定消息交换与事件处置的活动模型。BPEL 标准的着重点与 BPML 相类似。WSCI 标准着重在 Web 服务界面的行为。BPSS 以 ebXML 建议的模型 化方法论为基础,以支持在企业间以各种事务行为节点组合成所谓的企业协同应用为 着重点。 对于最新推出的 jBPM4 来说,由于其开放、可扩展的特性,对于以上标准的着重 点都有所支持或涵盖。因此,对于 jBPM4 的开发者而言,在工作中尽情发挥就好了, 不必担心被这些概念上的东西所束缚。 1.3 开源工作流选型 Optaros(www.optaros.com)是著名的开源软件研究及解决方案咨询公司,表 1-1 是其 2009 年开放源码目录中对于开源工作流管理系统的点评和介绍,值得参考(截止 到 2009 年 3 月)。 第 1 章 工作流基础 | 17 表 1-1 Optaros 2009 年开放源码目录_基础设施解决方案_业务流程和工作流程管理 产品 版本 许可证 支持 功能 社区支持 成熟度 ER-Rating 趋势 Bonita 3.1 LGPL 社区版 ★★★ ★★★ ★★ ★ → 描述:拥有基于“活动预测模型”的工作流引擎,符合 WfMC 规范。只适用于 Jonas 应用服务器和 JBoss 应用服务器。 网址:http://bonita.objectweb.org Enhydra Shark 2.2 LGPL 专业/社 区版 ★★★ ★★★ ★★★ ★★ ↑ 描述:拥有基于 Java 技术、可扩展的工作流引擎,实现了 WfMC 规范,即使 用 XPDL 语言来定义流程。该项目提供了图形化流程设计器。 网址:http://shark.objectweb.org Intalio| BPMS 5.1.1 Apache Eclipse Public License Custom 专业/社 区版 ★★★ ★★ ★★ ★★ ↑ 描述:是一个业务流程管理平台,提供了复杂的工具和底层技术用来支持流 程的运行,包括流程设计器(基于 Eclipse)、流程引擎(ODE)和一些运行 时组件。 网址:http://bpms.intalio.com IX Workflow 1.5 LGPL 专业/社 区版 ★ ★ ★ ★ ↑ 描述:基于 Java 体系的工作流系统,负责持久化以及处理业务流程,能很好 地支持与 Domino,JBoss,Sun Glassfish 应用服务器的集成。流程设计 器是基于 Eclipse 的插件。 网址:http://www.imixs.org 18 | jBPM4 工作流应用开发指南 (续表) 产品 版本 许可证 支持 功能 社区支持 成熟度 ER-Rating 趋势 JBoss jBPM 3.2.3 LGPL 专业/ 社区版 ★★★★ ★★★ ★★★ ★★★ ↑ 描述:灵活且可扩展的工作流管理系统。使用管理者和开发者都可以理解的语 言(如 jPDL 或 BPEL)来定义流程。其图形化流程设计器为 Eclipse 插件。 网址:http://www.jboss.com/products/jbpm ODE (Apache) 1.2 Apache License 2.0 社区版 ★★ ★★★ ★★★ ★ → 描述:基于 Java 组件的工作流引擎,遵循 BPEL4WS 规范。ODE 工作流引 擎早于 PXE 工作流引擎面世。 网址:http://ode.apache.org 根据这份报告可以很明显地看出,在众多的开源工作流管理系统中,jBPM 这个项 目在各项评比中都居于第一位,其许可证为 LGPL,可以在合法的范围内被作为商业应 用。jBPM 不仅有着开源社区的支持,同时作为 RedHat/JBoss 的子项目,也具有一定 的商业支持服务保证。尽管它还有一些不足,例如流程设计器功能过于简化、对企业 应用集成的支持有待完善等,但毫无疑问,它是众多项目型公司低成本工作流应用解 决方案的不二之选。 Shark 在这份报告中应该居于第二位,其严格遵循 WfMC 规范的 XPDL 流程定义 语言无疑是个亮点,这比 jBPM 主要采用自己的 jPDL 语言似乎更标准、更通用一些, 不过 jBPM4 对 BPEL 的支持和 PVM 的设计理念让 Shark 的这个优势显得并不突出。 其他的几个项目或多或少地存在着明显的短板,有的甚至已经停滞不前了,因此, 在国内的应用并不多见。 值得注意的是,在这份报告中,参加评比的 jBPM 版本还是 3.X,而今,jBPM4 已经逐渐成为主流,而 jBPM4 比之 jBPM3 有着“飞跃”性的提升,读者可以在后面 的章节中逐渐体会到。 第 1 章 工作流基础 | 19 1.4 jBPM jBPM,全称是 java Business Process Management,是一种基于 JavaEE 的轻量级工 作流管理软件包,由于 jBPM 架构的开放性,它更像是一个支持面向流程编程的框架 (Framework)。 jBPM 是开放源代码(Open Source)项目,使用 jBPM 要遵循 LGPL 开放源代码协议。以下的介绍将使您对这个著名的项目有一个概念性的认识。 1.4.1 jBPM 前世今生 jBPM 项目于 2002 年 3 月由 Tom Baeyens 发起,2003 年 12 月发布 1.0 版本。jBPM 在 2004 年 10 月 18 日,发布了 2.0 版本,并在同一天加入了 JBoss 组织,成为了 JBoss 企业中间件平台的一个组成部分,它的名称也改成 JBoss jBPM。随着 jBPM 加入 JBoss 组织,以及 JBoss 被 RedHat 公司收购,jBPM 也进入一个全新的发展时代,它获得了 大量的社区和商业支持,因此发展前景十分光明。 jBPM3 主要采用了 UML Activity Diagram(活动图)的模型,借鉴了 Petri Net 的 token 机制,使用“无限状态机”模型控制流程实例的变迁。因此在理论模型基础上, jBPM 无疑是先进工作流产品。jBPM4 则引入了 PVM(流程虚拟机)的设计理念,为 jBPM4 的“无限”扩展和集成提供了有力的底层功能支持。 经过 8 年多的发展,JBoss jBPM 已经成为一流的开源工作流产品:  每月超过 20 000 次的下载量。  极度活跃的用户论坛和开发者论坛。  频繁更新 Web 站点和 Wiki。 本书以 2010 年第一季度最新发布的 jBPM4.3 版本为主要参照,来介绍 jBPM。当 然,本书介绍的很多方法和思想不是与版本号“绑定”的,即适用于所有 jBPM4 版本, 甚至所有工作流系统的研究和开发。 1.4.2 关于 jBPM4 您需要知道的 JBoss jBPM 是一个可扩展、灵活的能够实现工作流/业务流程管理的企业级开发框 架,提供了流程定义、流程部署、流程执行、流程管理等功能。 jBPM 是 JBoss 旗下的子项目,JBoss 下还包括有 Seam(JavaEE 开发框架)、Drools 20 | jBPM4 工作流应用开发指南 (规则引擎)、 Hibernate(ORM 持久化框架)等众多领域的优秀开源项目。由于同属 一个产品家族,它们能与 jBPM 完美地结合,互相都留有支持的接口,方便开发者业 务的扩展,为 jBPM 提供延伸的价值。 同时 jBPM作为 JBoss SOA 平台的一个重要组件,与JBoss Drools 规则引擎和JBoss ESB 企业服务总线配合在一起为用户提供全面、完整的 SOA 解决方案。 JBoss jBPM 是一个支持“嵌入式”的业务流程管理产品,理论上可以运行在任何 JavaEE 应用服务器之上,也可以运行在桌面应用中。JBoss jBPM4 在流程虚拟机(PVM) 技术的基础上,能够同时支持多种流程定义语言,目前已经支持的流程语言有:  jPDL  BPEL  Seam PageFlow 根据 PVM 的设计理念,未来的 JBoss jBPM 还会支持更多的流程定义语言。同时, 用户也能够根据需求定制自己个性化的流程模型和建模语言。 jBPM4 的结构特点如下。 1. 嵌入式的工作流引擎 jBPM4 是完全支持嵌入式应用的业务流程开发框架,可以在事务处理、数据持久 化等各个方面与业务应用程序进行灵活的集成。区别于传统的工作流平台,它不需要 依赖特定的中间件或服务器,减少了硬件和软件的绑定,同时降低了应用部署的网络 复杂度,使应用更加容易实现集群。软件开发者可以把 jBPM4 框架作为业务流程管理 的基础,在此基础上开发自己独特的业务流程管理模块和功能。在部署时,只需要把 jBPM4 作为 Java 依赖库发布就可以了。 2. 可插拔的体系架构 jBPM4 采用了模块化的架构设计,采用了 IOC(依赖注入)的设计理念,各模块 之间可以比较方便地解除耦合或替换不同的实现,例如持久化、事务处理、身份认证、 日志服务等,都由可选模块实现。jBPM 的可插拔体系架构,为软件开发者灵活选择 jBPM 的功能、自定义已有功能和拓展新功能提供了“无限可能”。 3. 易扩展的流程语言 jBPM 框架内置的流程定义活动,包括 start,task,fork,join 和 decision 等,是构 建完整业务流程所必需的组成部分,它们提供了可以将业务逻辑 Java 代码和业务流程 第 1 章 工作流基础 | 21 编排无缝衔接的绑定机制。而除了这些内置的流程定义活动和流程结构之外,软件开 发者还可以通过定制新的活动类型或者完全重新设计一种新的流程定义语言来描述特 定领域的业务流程,满足独特环境下的需求。 从技术角度分析 jBPM4 的特点,简单罗列几点读者必须要了解的:  jBPM4 的模型仍然基于 UML Activity Diagram,以便于需求人员和开发人员 都理解业务流程。  jBPM4 提供了可定制的 Event – Listener 观察者模式来处理事件触发,以辅助 活动扩展的处理。  jBPM4 提供了灵活的 EL 条件表达式机制,来辅助条件解析、简单业务逻辑 脚本计算的处理。  jBPM4 提供了可扩展的 Task 及任务分配机制,来满足复杂人工活动的处理。  借助 Hibernate ORM 的优势,jBPM4 能够支持在几乎所有的数据库系统之上 运行。 jBPM4 作为一款开源的工作流框架,其更多的是关注“如何辅助开发者更容易地 让流程运行完成”,而不是关注“记录流程运行的历史和轨迹”。这一点可能是东西方 文化的差异性所在,因为国内的流程应用,比较关注“运行轨迹”。 同时,jBPM 项目从一开始就是不直接支持自由“回退”、“跳转”等操作的,这也 是因为东西方文化的差异所在。西方人认为“往回流转的情况肯定也是一种业务规则 所定义的,那么肯定可以通过分支或条件流转来解决”,而东方人则把回退作为一个“人 性化管理和处理的潜在特点”来看待。当然,这正是本书所要解决的问题之一,在第 20 章 中国特色工作流的 jBPM 实现中会给出一些参考解决方案。 具体到 jBPM4 的当前发行版,您需要知道的有:  许可证与最终用户许可协议  jBPM 是依据 GNU Lesser General Public License(LGPL)和 JBoss End User License Agreement(EULA)中的协议发布的。  如何获取 jBPM4  可以从 SourceForge.net 上获取发布包:http://sourceforge.net/projects/jbpm/files/。  如何获取 jBPM4 的所有源代码 22 | jBPM4 工作流应用开发指南  可以 从 jBPM 的 SVN 仓库 里下载源代 码:https://anonsvn.jboss.org/ repos/jbpm/jbpm4/。  如何从 jBPM 3 升级到 jBPM 4  很遗憾,没办法实现直接从 jBPM3 升级到 jBPM4。但本书提供一套建议 的方法供读者实践,参见第 11 章 升级 jBPM3 到 jBPM4。  如何报告问题  在开发过程中遇到问题无法解决可以在 jBPM 开 发 者 社 区 http:// community.jboss.org/en/jbpm 寻求帮助,但发布问题需要遵循如下模板。 === Environment ============================== - jBPM Version : 您使用的是哪个版本的 jBPM? - Database : 使用什么数据库以及数据库的版本? - JDK : 使用哪个版本的 JDK?如果不知道,可以使用 java –version 命令查看版本信息 - Container : 使用什么容器?(例如 JBoss, Tomcat) - Configuration : 您的 jbpm.cfg.xml 中是导入了 jbpm.jar 中的默认配置,还是使用了自 定义的配置? - Libraries : 您使用了 jbpm 发布包中完全相同的依赖库的版本,还是您修改了其中一些依赖 库? === Process ================================== 这里填写 jPDL 流程定义 === API =================================== 这里填写您调用 jBPM API 使用的代码片段 === Stacktrace ============================== 这里填写完整的错误堆栈 === Debug logs ============================== 这里填写调试日志 === Problem description ========================= 请保证这部分短小精悍并且切入重点。例如: API 没有如期望中那样工作,或者 ExecutionService.SignalExecutionById 抛出了异常。 发布问题最好使用英文,因为这个社区论坛是英文的。同时,聪明的读者可能已 经注意到了模板上的这些项已经指向了可能导致 jBPM 问题的几点原因,特别是对依 赖库和配置文件的调整是最容易导致问题的操作。所以,开始在本书介绍的知识范围 之外修改配置文件之前,一定要谨慎;同样在使用其他版本的依赖库替换默认的依赖 库之前,也一定要谨慎。 第 1 章 工作流基础 | 23 1.5 小结 通过本章的介绍,相信读者已经对“工作流”和“jBPM”有了概念上的认识,已 经能够阅读一些充满专业术语的 jBPM 应用开发相关的技术文档了。那么,我们言归 正题,进入 jBPM4 应用,开始您的面向流程之旅吧! 在后面的章节中,本书将不再花费大量的精力去解释工作流、jBPM 相关的专业术 语。如果您读到仍然感到迷惑的术语,可以尝试到附录 A jBPM 术语中寻求解释。
还剩21页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 5 金币 [ 分享pdf获得金币 ] 1 人已下载

下载pdf

pdf贡献者

sunboys

贡献于2012-09-25

下载需要 5 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!
下载pdf