jbpm系列教程
初识jBPM
一、为什么需要流程、流程管理
有很多人搞了多年的工作流，突然有人问他一个简单的问题“为什么需要流程和流程管理？”，他也许会愣住。对呀，这个问题其实会难倒很多搞技术的人，他们只知道埋头苦干，甚至一头栽进去不能自拔，很少有时间思考这个问题。现在笔者讲讲自己对流程以及流程管理的必要性，毕竟它是我们后面要讲的内容的前提。如果连目标都未认清楚，怎能充分发挥个人的主观能动性将工作流技术学好呢！当然，这个问题我也思考良久，个人愚见仅供参考。综观国内外管理学的发展历程，从著名的汽车组装流水线“福特模式”到如今的“科技以人为本”，管理学家在做的同一件事就是如何让企业运作得更好，小企业如何做大，大企业要如何规避因为组织庞大而造成的管理滞后性，做到“大象也能跳舞”。管理学上认为一个人最多只能同时管理7件事情。基于这个原理，各大企业、政府机构开始划分出等级森严的科层制。以财政厅为例子，机构组织结构如下：
厅长
副厅长A
副厅长B
副厅长C
处长A
处长B
科长 A
科长 B
处长 ……
处长 ……
科员 A
<!--[if !vml]--><!--[endif]-->
图一 组织图
众所周知，这种科制层等级众多，审批要层层上报，任务要层层下达，行事效率低下。同时，处于各层的人员更关注的是与自己直接上下级之间的联系，很少出现跨层的联系，必然导致各层人员看到的是业务的局部，难以把握业务的全局。所以，只有组织扁平化、成立专项小组才能提高企业、政府的行事效率，从而提高客户服务的质量。要站在业务的全局，以客户为中心，必然将流程以及流程管理推到了前台。这也是为什么近年来“流程管理”如此火暴的原因。
二、从工作流管理系统谈起
“工作流管理系统是什么”这个问题在google上可以search出许多不同的答案，在此笔者就不再“重复造轮”，而只是想从另一个侧面谈谈自己对工作流管理系统的看法。谈到工作流管理系统，必然涉及到工作流，其英文为”workflow”，字面的意思来说就是工作流动起来了，就成了工作流。而工作流管理系统自然就是管理工作流的专门的系统。
正如jBPM项目的leader Tom Baeyens在其《工作流现状》的文章中提到的，“如果说数据库系统像受人尊敬的智者在讲述条理清晰的故事，那么工作流就像一群乳臭未干的小子在大谈各自的‘哲理’”，确实如此，各大规范组织都在推销自己的标准，但并没有哪一大标准被广泛的实际采用，整个工作流规范界到目前为止处于混沌的状态（注：具体可以参考本人写的文章《浅谈工作流规范》）。品种繁多的工作流规范足以打败刚刚涉足工作流学习初学者的信心。然而，在规范标准如此百家争鸣的“春秋战国”时期，却存在一个共同的“道”，那就是工作流管理系统负责业务流程的定义、创建、执行、监控等功能，这一说法毋庸质疑。众多的工作流相关的规范主要争夺的就是业务流程建模定义这块主战场。看来只能如荷兰著名工作流领域学者W. van der Aalst所展望的，工作流管理系统最终应该像数据库管理系统一样，以坚实严谨的数学逻辑理论为基础，形成一个统一的国际标准，我想这样应该是工作流领域发展曲线的最好归宿了（注：数据库技术以，而工作流可以以Petri Net为数学理论基础，数据库技术有统一的SQL92标准，工作流技术也应该有一个统一的标准）。
<!--[if !supportLists]-->三、<!--[endif]-->jBPM脱颖而出的理由
如今开源产品如此之多，其中不乏性能优越的工作流产品，为什么会选出jBPM呢？我想从以下几个方面来阐述理由：
<!--[if !supportLists]-->1、 <!--[endif]-->jBPM的理论基础GOP
jBPM的leader Tom Baeyens在业务流程建模语言方面有自己独特的见解，其信奉多种流程语言，相信不同的环境或目标需要不同的特定的流程语言。而面向图编程（GOP）则是一种新的实现技术，且是所有基于图的流程语言的基础。GOP的好处就在于它是所有流程语言的基础性技术。如下图
<!--[if !vml]--><!--[endif]-->
图二 基于图语言的位置
当前的软件开发依赖于越来越多的领域相关语言（Domain Specific Languages）。一个典型的Java开发者就会用到一些领域相关语言。各种框架所需要的XML配置文件内容就可以看做为领域相关语言。工作流、BPM、Pageflow等基于有向图的执行。而hibernate mapping文件， ioc-configuration等则不然。面向图编程（GOP）是所有基于图执行的领域相关语言的基础。同时，jBPM以UML中Activity Diagram为图形元素为基础，易用性自然不用说，大大减少业务人员与软件开发者之间的沟通鸿沟。
<!--[if !supportLists]-->2、 <!--[endif]-->jBPM本身的jPDL设计的合理性
如果用过jBPM的流程建模eclipse插件的开发者都会被其简洁而又强大的jPDL语言所折服。jBPM对流程的建模，把两大主要开发角色（业务分析者 Bussiness Analysist和软件开发者Software developer）的职能区分清晰，但又支持他们之间的合作开发不受影响。在jBPM的建模工具中，最终建模结果中可视化的元素都是由业务分析者所创建的，而隐藏的各种事件（event）以及相应的Action都是由软件开发者构建。业务分析者只要关注各种节点（node）、迁移（transition）以及泳道（swimlane）等元素的创建，同时软件开发者可以在不改变业务分析者所创建的元素的前提下加入相应的编码功能。这种合作与将网站开发模式中的网页美工与程序员的工作分离同时又可支持完美合作开发有异曲同工之妙。
<!--[if !supportLists]-->3、 <!--[endif]-->jBPM的可扩展性
jBPM虽然是以UML中的Activity Diagram的建模元素为基础，但其支持根据需求扩展开发其它种类的图形元素，所以其可扩展性是极强的。而其它建模语言，一般以某一规范为基础，其元素是封闭的，并不开放。同时荷兰工作流领域学者W. van der Aalst给出的21种复杂的工作流模式足以认证工作流建模的复杂性，必须考虑其建模元素的可扩展性，而不应该仅仅绑死在与规范相关的既有建模元素上而无法扩展。