1 前言

流程引擎内核仅是“满足Process基本运行”的最微小结构，而整个引擎则要复杂很多，包括“状态存储”、“事件处理”、“组织适配”、“时间调度”、“消息服务”等等外围的服务性功能。引擎内核，仅包含最基本的对象和服务，以及用于解决流程运行问题的调度机制和执行机制。

　如果，你掌握了一个流程引擎的灵魂，你才有能力理解它的全部。否则，一个引擎对你来说，可能只是一个复杂的结构，丰富多彩API、令人眼花缭乱的“功能”和“服务”而已。

　本身工作流这个领域就是一个很“狭窄”的领域，国内的厂商也不是很多，其中有部分实现技术并不弱。但可能涉于安全等因素，并没有多少技术人员探讨“深度的工作流技术实现问题”。而广大的开发爱好者却还在花费大量的时间在摸索“如何理解工作流、如何应用工作流”。 所以在此之前，国内尚未有一篇技术文章探讨工作流引擎内核的实现，当然也没有探讨jBpm引擎内核的文章了。在www.javaeye.com 技术站点和我的blog（http://blog.csdn.net/james999）上有几篇专门探讨jbpm应用的文章，对于初步想了解如何使用jbpm的读者来说，值得看看。

　对于这方面的技术分享，开源是个不错的突破口。

　本篇就是以jBpm为实例，来诠释工作流引擎的内核设计思路和结构。但是这仅仅是从jBpm的实现角度来辅助大家理解，因为工作流引擎内核的设计、实现是有很多方式：这会因所选的模型、调度算法、推进机制、状态变迁机制、执行机制等多方面的不一样，而会差别很大。比如基于Activity Diagram模型的jBpm和基于FSM模型的OSWorkflow引擎内核之间就有很大的差别。
相比较而言，jBpm的模型比较复杂，而引擎内核实现的比较“精简”，非常便于大家“由浅入深的理解”。

2 阅读本篇的基础准备

　2.1 概念的基础

　本文的读者群主要是面向有一定工作流基本概念的开发人员。所以本文认为你已经具备了如下基本工作流知识：
　（1） 初步了解工作流系统结构。比如理解工作流引擎在工作流系统中所处的位置和作用
　（2） 对流程定义（Process Definition）和流程实例（Process Instance）相关对象有所了解。比如理解Process Instance代表什么，工作项（WorkItem）代表什么。

2.2 环境的基础

　在阅读本篇的时候，如果你已经搭建了一套jbpm的开发环境，那么将有助于你更容易理解本篇的很多内容，也便于实际体验代码。从www.jbpm.org官方网站下载jbpm-starters-kit开发包，按照其参考手册，可以很容易在eclipse开发环境中建立项目，效果图类似如下：

　3 什么是流程引擎内核？

　我比较推崇“微内核的流程引擎构架”，并在最近两三年内写了两篇探讨此方面的文章：第一篇是写于05年7月份的《微内核流程引擎架构体系》，第二篇是07年7月份的《微内核过程引擎的设计思路和构架》（受普元《银弹》杂志约稿所写，尚未对外公开）。

　但至今对外阐述引擎内核到底是什么。
 
　正如上面的两张图所示，我们可以通过“微内核”的构架来使得流程引擎的结构更加“清晰”。而能否实现“微内核”的根本，则是看你是否能够设计并抽象出“良好的引擎内核结构”。

　很显然，要想设计出一套结构优良的引擎内核，首要条件就是：明白什么是引擎内核。

　首先我们需要明白引擎是什么，引擎可以做什么。这在WfMC的《工作流参考模型》中已经有很详细的解答，本文不再重复。知道这个仅仅是不够的，你还需要很清晰的明白如何去“为流程建模”，而这则在Aalst大师所著的《工作流管理——模型、方法、系统》一书有细致阐述，本文也不再重复。

　但很可惜，至今尚未有一本专门的书籍来论述“过程建模方法”的，或者说如何利用这些既有的“过程建模方法（诸如FSM、PetriNet、EPC、Activity Diagram等等）”来解决流程问题。这个只能分别查阅相关资料，此处也不叙述。因为文本只讲“引擎内核”。

　如果我们暂且把那复杂的流程业务性问题，诸如“组织模型分配”、“分支条件计算”、“事件处理”、“消息调度”、“工作项处理”、“存储”、“应用处理”、以及那些“变态的诸如会签、回退之类的模型”都统统的抛弃，只留下“最单纯的过程性问题”，也就是“解决一个过程运行问题，按秩序的从一个节点到另一个节点的执行”。——这就是引擎内核所关注的根本问题。
上面这句话，估计会引起很多人“拍砖”。在很多人看来，工作流之所以看起来很“难”，就是因为这些复杂多变的“业务性问题”都统统绑在一个“引擎”上造成的。

　其实，这是两个“维度”的问题，也就是“引擎的抽象”和“引擎的应用”这两个不同维度，不同层面的问题。但这绝不是两个独立的问题，“引擎的抽象”的好与坏，直接影响到“引擎的应用”的可复杂度和可支持度，当然我们也不能否认，“引擎的应用”问题也是一个很复杂的问题。但本文是站在“引擎的抽象”这个维度来阐述问题的。对于“引擎的应用”问题，可参考我的前作：2003年11月份的《工作流模型分析》、2003年12月份的《工作流授权控制模型》、2004年7月份的《工作流系统中组织模型应用解决方案》。

　也就是说，本文不是指导大家如何去“使用jbpm”，而是阐述“jbpm的引擎的内核部分是如何构建的”。但本文的主旨不是告诉大家“jBpm是如何设计引擎内核的”，而是以jBpm为例，来介绍“引擎内核”。

4 引擎内核所关注的四个主要问题

　引擎内核所关注的是一个非常“抽象”层面的问题，而不同引擎关注的“一套完整的执行环境”。或者我们可以这么来说，引擎内核的职责是非常“精简”的：确保流程按照既有的定义，从一个节点运行到另一个节点，并正确执行当前节点。
总的来说，引擎内核主要关注四个方面的问题：

　（1） 流程定义问题：不是说如何图形化的定义流程，而是如何用一套定义对象，来诠释所定义的流程。
　（2） 流程调度问题：提供什么的机制，可以确保流程能够处理复杂的“流程图结构”，诸如串行、并行、分支、聚合等等，并在这复杂结构中确保流程从一个节点运行到另一个节点。
　（3） 流程执行问题：当流程运行到某个节点的时候，需要一套机制来解决：是否执行此节点，并如何执行此节点的问题，并维持节点状态生命周期。
　（4） 流程实例对象：需要一整套流程实例对象来描述流程实例运行的状态和结果。

4.1 模型与定义对象

　工作流引擎本身就是一种“base on model”的组件，流程实例的执行都是依赖于所定义的“流程定义”，而工作流引擎则是提供了这样一种环境，来维持流程实例的运行。

　所以引擎内核，必须提供一套定义对象来描述“流程定义”，并且这些定义对象必须反映出一种“模型”。比如jBpm的定义对象，是与其所基于的Activity Diagram模型相对应的。

4.2 调度机制与算法

　引擎内核的另一个重要功能，就是保证流程实例准确的从一个节点运行到另一个节点，而这则需要依赖于一套调度机制。

　引擎的调度机制有很多种实现方法，有的甚至是与“所依赖的模型有关”。但普遍来讲，很多引擎都受到Petri Net的影响，而采用token来调度。

　jBpm本身就吸纳的token这套机制，当然，与Petri Net的调度机制还是有所区别。我们将在下面的章节详细介绍。

4.3 执行机制与状态

　经过引擎的调度，实例运行到某个节点了，此时必须必须提供一套机制，来判断当前节点是否可执行，如果可执行，那么需要提供一套runtime envrioment来执行节点——这就是引擎的执行机制。

文章出处：http://www.diybl.com/course/3_program/java/javajs/2008325/107306.html