JBPM与Spring集成开发指南

 

1         术语

WFMC: Workflow Management Coalition

工作流：全部或者部分，由计算机支持或自动处理的业务过程。

工作流管理系统（ Workflow Management System, WFMS)：工作流管理系统是这样的一个系统，详细定义、管理并执行“workflows”，系统通过运行一些软件来执行workflows，这些软件的执行顺序由工作流逻辑的计算机表示形式（计算机化的业务规则——过程定

义）驱动。

工单：一次申请的提交记录，该记录具有唯一性。工单相关的概念：

l         工单管理：对投诉工单、建议工单、座席建议工单、业务受理工单等不同类型的工单进行派发、接收处理、回复等一系列工单处理操作。

l         工单统计：对各种处理工单的数量，类型进行数据统计和导出、报表打印。

l         工单系统管理：对工单系统进行管理，设置相应的处理部门、处理人员和相应的权限，规定处理流程。

l         工单日志：记录工单操作日志，有效管理日志的处理状况和责任。

2         背景

工作流管理系统一项快速发展的技术，各种行业渐渐的采用工作流技术。工作流技术的主要特点是：过程的自动化处理，这些过程包含由人与以机器为基础的活动相结合；特别是对那些与IT 应用程序、工具交互的过程，进行自动化处理。虽然，工作流技术广泛用于办公环境中，例如保险、银行、法院和行政管理等，然而工作流技术，也可以应用于一些类型的工业和制造业。

3         概述

在人们日常生活和工作中，都将与工作流程发生密切的关系，“工作流”干预过程、业务程序的自动化处理，文档、信息或者任务按照定义好的规则在参与者间传递，来完成整个业务目标或者对整个业务目标的完成做贡献。应用领域广泛，比如：

l         公司或组织内部请假或休假流程、通知分发流程等

l         政府政策审批流程、

l         网上书店图书订阅流程、发送流程等

l         驾照学习流程等等。

同时，“工作流”可能由手工组织，实际上，多数“工作流 ”都在IT系统中进行组织的，从而对过程自动化提供计算机支持。“工作流”采用计算机化后，可以大大提高工作和生活的效率，而信息化过程中，对于采用的技术实现方式的不同，将直接影响到信息化的质量，包括：开发成本、维护成本等。好的工作流解决方案，可以大大提高业务流程流转效率、容易扩展对新流程的支持等。

JBPM是当前优秀的开源工作流引擎。本文档是关于JBPM与Spring框架集成分析文档。包括：基本概念、设计要点、常见问题解答、参考资源等。

本文主要介绍了集成开发的高级内容，基础知识参见： 参考资料

本文档适合所有计算机开发人员。

4         基本概念

4.1         什么是工作流（一）

“工作流”干预过程、业务程序的自动化处理，文档、信息或者任务按照定义好的规则在参与者间传递，来完成整个业务目标或者对整个业务目标的完成做贡献。同时，“工作流”可能由手工组织，实际上，多数“工作流 ”都在IT系统中进行组织的，从而对过程自动化提供计算机支持，WFMC把工作定位在这个方向上。

“工作流”定义：全部或者部分，由计算机支持或自动处理的业务过程。

工作流经常与“过程重组（BPR—Business Process Re-engineering）”联系在一起。BPR 是关于企业（组织）核心业务过程的评估、分析、模拟、定义以及其后的操作实现。尽管，不是所有的BPR都是采用工作流实现的，但工作流技术是最佳的方法，主要因为，工作流技术提供了业务过程逻辑与IT操作支持的分离，从而以后可以修改过程规则来重定义业务过程。相反，工作流技术并不只在BPR中采用，例如用于现有的业务过程中。

“工作流管理系统（WFMS—Workflow Management System）”通过管理工作活动序列，调用与各种活动步骤相关的人员、IT资源，对业务过程提供自动化处理。

“工作流管理系统”定义：工作流管理系统是这样的一个系统，详细定义、管理并执行“workflows”，系统通过运行一些软件来执行workflows，这些软件的执行顺序由工作流逻辑的计算机表示形式（计算机化的业务规则——过程定义）驱动。每个业务过程都有一个生命周期，从几分钟到几天（甚至数月），由过程的复杂性与组成活动的持续时间来决定。有多种方法实现工作流管理系统，使用多种IT和通讯组件，运行环境可以从一个小的本地工作组到企业间。因此，WFMC参考模型从各种角度考虑工作流管理系统，希望提供各种不同的实现技术、运行环境。

尽管实现的方法多种多样，但所有的WFMS都表现出某种共同的特性，这为不同产品间的集成、协同工作提供了基础。参考模型描述了工作流系统的一个公共模型，并且指出参考模型如何能使其与其他各种不同的实现方法相关联。

在最高层，所有的WFMS都相同的特性，即为下边的3个功能提供支持：

● 建立时期（Build-time）功能，定义、模拟工作流过程，及其组成活动。

● 运行时期（Run-time）控制功能，在运行环境中管理工作流过程，管理不同

● 运行时期与用户、IT应用程序（工具）的交互，来处理各种活动的执行。

下图描述WFMS的基本特性，以及上述功能间的关系：

4.2         什么是工作流（二）

工作流（Work Flow ）就是工作流程的计算模型，即将工作流程中的工作如何前后组织在一起的逻辑和规则在计算机中以恰当的模型进行表示并对其实施计算。工作流要解决的 主要问题是：为实现某个业务目标，在多个参与者之间，利用计算机，按某种预定规则自动传递文档、信息或者任务。简单地说，工作流就是一系列相互衔接、自动 进行的业务活动或任务。我们可以将整个业务过程看作是一条河，其中流过的就是工作流。 　　工作流属于计算机支持的协同工作（Computer Supported Cooperative Work ，CSCW ）的一部分。后者是普遍地研究一个群体如何在计算机的帮助下实现协同工作的。 　　许多公司采用纸张表单，手工传递的方式，一级一级审批签字，工作效率非常低下，对于统计报表功能则不能实现。而采用工作流软件，使用者只需在电脑上填 写有关表单，会按照定义好的流程自动往下跑，下一级审批者将会收到相关资料，并可以根据需要修改、跟踪、管理、查询、统计、打印等，大大提高了效率，实现 了知识管理，提升了公司的核心竞争力。

4.3         工作流的适用行业

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

4.4         工作流的具体应用

　　1. 关键业务流程：订单、报价处理、采购处理、合同审核、客户电话处理、供应链管理等 　　2. 行政管理类: 出差申请、加班申请、请假申请、用车申请、各种办公用品申请、购买申请、日报周报等凡是原来手工流转处理的行政表单。 　　3. 人事管理类：员工培训安排、绩效考评、职位变动处理、员工档案信息管理等。 　　4. 财务相关类：付款请求、应收款处理、日常报销处理、出差报销、预算和计划申请等。 　　5. 客户服务类：客户信息管理、客户投诉、请求处理、售后服务管理等管理等。 　　6. 特殊服务类：ISO 系列对应流程、质量管理对应流程、产品数据信息管理、贸易公司报关处理、物流公司货物跟踪处理等各种通过表单逐步手工流转完成的任务均可应用工作流软件自动规范地实施。

4.5         工作流与重规划

　　从逻辑上，对工作流的关注和研究可以看作是对业务过程重规划（BPR ）的一种深化。BPR 的观点，要求我们将眼光投向实际业务进行的过程，但这个过程 应当是什么样的，怎样分析、构造？工作流就是一个具体的、操作性的答案，它可以令我们从神秘的、难以预测和控制的“ 头脑风暴式” 的“ 艺术的” 业务过程创 造，变成解析的、技术的、可控制和预测的工程化过程，如此，才真正体现出re-engineering 中engineering 的意义。 　　工作流与BPR 的概念，已经被几乎所有的研究者联系在一起研究和应用。在这个领域有一个非常活跃的组织，即国际工作流与重规划协会（Workflow And Reengineering International Association, WARIA ）。

4.6         工作流与企业工程

　　无论从理论、方法上，还是对象、内容上，我们都有理由将“ 工作流” 看作是企业工程的一部分。实际上，已有的关于工作流体系的描述，本身就是一个通用的业务模型框架。仅仅囿于工作流是不够的，必须对整个体系的目标及所有相关要素综合考虑—— 这正是企业工程。

4.7         工作流与IT应用体系

　　与以往已经被采用的企业IT 应用体系，例如MRPII 或ERP 相比，WFMS 是一个相当重要的里程碑。从用户的角度，WFMS 带来（或将要带来）的变化是极其强烈的，甚至可以形容为一种用户“ 梦想” 的实现。 　　在一些老的“ 模块化” 的产品中，系统的设计是通常是基于任务分割的，作业项目之间是分裂的。面向对象的技术，并不能直接解决这个的问题，相反，往往使 系统变得更加混乱和琐碎。从操作上，典型地，我们必须不断地在层次结构的功能表（比如下拉菜单）或对象之间“ 进进退退” ，或者在“ 神出鬼没” 的对象以及相 关菜单中捉迷藏。 　　工作流管理系统是一个真正的“ 人- 机” 系统，用户是系统中的基本角色，是直接的任务分派对象，他或她可以直接看到电脑针对自己列出的“ 任务清单” ，跟 踪每一项任务的状态，或继续一项任务，而不必从一个模块退出，进入另一个模块，搜索相应任务的线索。前者是面向功能或对象的，而后者是直接面向用户的。这 样，用户的任务分派和任务的完成状态，可以被最大程度地电脑化和受到控制。 　　现在的典型工作流产品是客户- 服务软件。而日益增长的重要途径是通过万维网界面，它可以令客户或远程的职员更好地参与。工作流的定义经常是借助于图形化工具，依照业务过程实例的情况定义相应工作的安排。

4.8         JBPM

4.8.1        介绍

jBPM is a platform for executable process languages ranging from business process management (BPM) over workflow to service orchestration. There are many process languages. Each one is targeted towards a specific function and a specific environment. jBPM allows all of these process languages to be build natively on top of one single technology: the Process Virtual Machine (PVM). jBPM already supports 3 very different process languages: jPDL, WS-BPEL and Seam Pageflow. This might expand in the future as new process languages are added to our platform.

     jBPM（JBoss Business Process Management业务流程管理），它是覆盖了业务流程管理、工作流、服务协作等领域的一个开源的、灵活的、易扩展的可执行流程语言框架。

       jPDL是构建于jBPM框架上的流程语言之一。在jPDL中提供了任务（tasks）、待处理状态 （wait states）、计时器（timers）、自动处理（automated actions）…等术语，并通过图型化的流程定义，很直观地描述业务流程。

       jPDL可以部署于Java语言的任何应用环境下，JavaSE Application(Swing/SWT)、JavaEE Application(Application Server) 。

4.8.2        jPDL分发包组成

目前jPDL的最新版本是3.2.2，您可以在以下地址： http://labs.jboss.com/jbossjbpm/jpdl_downloads/ 获得官方下载包。下载包分为两种，一种是标准包(jbpm-jpdl-3.2.2.zip)只有20M左右；一种是套件包(jbpm-jpdl-suite-3.2.2.zip)将近80M。两者最大的区别是套装包自带一个已经配置好的jboss服务，下载解压缩后，可直接运行。

4.8.3         jPDL的核心程序包(jbpm-jpdl.jar)

它是一个典型的jar文件，它涵盖对流程定义和运行时流程实例上下文环境的操作API。在最简化的业务流程样例中，jPDL将流程定义存储与XML格式的定义文件中，在运行时载入内存，在内存里记录完整的业务实例和执行过程的环境变量，并完成全部操作。显然，在实际应用中，流程信息必须被持久化的存储于数据库中。jPDL使用了Hibernate作为其对象持久化的API。

4.8.4         Graphical Process Designer插件(jbpm-jpdl-designer-3.1.2.zip)

它是一个基于Eclipse的图型编辑插件。使用它可以对业务流程进行可视化的定制，而无须手动编辑XML文件。该插件还提供了流程定义上传功能，可以将新定义的流程发布到在线运行的jPDL系统上。  

4.8.5        jPDL身份包(jbpm-identity.jar)

      它是jPDL的一个轻量级扩展包，简单实现了组Group、用户User、许可权Permission等用户身份认证和鉴权机制。如果您的应用环境只需要简单的用户认证鉴权管理，那么它十分适合您。

4.8.6         jPDL Web控制台(jbpm-console.war)

它是一个标准Web应用（使用了JSF技术），提供了对jPDL平台执行情况的监控程序（对jPDL数据库的监控）。管理员可以通过该程序方便的维护jPDL的数据库，管理流程定义和流程实例的执行情况。同时，它还提供了一个简单的Getting started DEMO，方便初学者了解jPDL。 

4.8.7        静态的流程定义模型

4.8.7.1       流程定义实体（Process Definition）

编号	PD-001
对象	流程定义实体（Process Definition）
描述	流程定义实体是对一个流程抽象的对象化定义，如图-002。一套系统中，用户可以定义保存多个流程定义实体，如：报销流程定义、请假流程定义、人事录用流程定义等。每个流程定义还可以有多个不同的版本，如:针对同样的报销流程可以有修订前和修订后的两个流程定义，同时存储于jPDL数库中。用户可以通过流程名称和版本号获取相应的流程定义。在默认请况下，系统启用最新的流程定义。
Java 对象	org.jbpm.graph.def.ProcessDefinition
数据库表	JBPM_PROCESSDEFINITION该表存储流程定义的通用信息，如：流程名称、版本号
表关联说明	JBPM_PROCESSDEFINITION表中，每条记录有自己的数据库流水号  ID_JBPM_PROCESSDEFINITION的外键（Foreign Keys）： startstate_ 同JBPM_NODE（流程结点）表关联。此外键指向流程定义中的起始结点ID

 

4.8.7.2        流程结点（Node）

编号	PD-002
对象	流程结点（Node）
描述	流程结点是对流程中的过程环节/行为的抽象对象化定义，如图-002中的每个方框即代表一个结点。结点有两个主要职责：一，实现某个指定行为，这在jBPM中就是执行一段制定的Java代码；二，转递、维持流程的延续，直至达到最终结点。在jPDL的结点设计中，系统开放了充分的用户行为模型，程序员可以基于这些行为接口，实现自定义的业务功能。在jPDL中，系统预定义了一系列的Node类型，同时也允许程序员开发定义自己的Node类型。
Java 对象	org.jbpm.graph.def.Node
数据库表	JBPM_NODE该表存储结点的定义信息。
表关联说明	JBPM_NODE表中，每条记录有自己的数据库流水号  ID_JBPM_NODE的外键（Foreign Keys）： processdefinition_ - 此外键说明该Node从属的流程定义对象ID subprocessdefinition_- 此外键指定了一个由该Node发起的子流程。在主流程离开当前结点之前，该子流程必须完成执行过程。action_ - 此外键指定该结点动作类的ID superstate_ - 该外键是一个自关联键，指向结点的上级父结点ID。一个子流程中的多个结点从属于同一个父流程结点。 decisiondelegation_ – 该外键指定了结点委派的判定类ID（所谓委派判定类是指根据用户的业务逻辑，判定流程的下一个流向的Java Class）

 

4.8.7.3         流程转向（Transitions）

 

编号	PD-003
对象	流程转向（Transitions）
描述	流程转向是描述流程中从一个结点到另一个结点的状态转换过程，因此一个转向一定有一个源结点和一个目标结点。 在jPDL中transition的命名是通产是唯一的，结点依靠transition的命名来区别到下一结点的路径，当一个Node中存在有多个同名的transition的时候，第一个transition将会被选中。结点转向的过程中，排在transition列表第一位置的即是默认的transition。
Java 对象	org.jbpm.graph.def.Transition
数据库表	JBPM_TRANSITION该表存储流程定义中的转向对象。
表关联说明	JBPM_TRANSITION表中，每条记录有自己的数据库流水号  ID_JBPM_TRANSITION的外键（Foreign Keys）： processdefinition_ - 该外键指向transition所属的流程定义对象ID from_ - 该外键指向transition的源结点ID to_ -该外键指向transition的目标结点ID

4.8.7.4         动作（Actions）

编号	PD-004
对象	动作（Actions）
描述	Actions是指一系列的在流程事件中运行的Java代码。流程图是软件需求的传达的重要手段，但它只是软件需求的一个投影，隐藏了很多技术实现的细节。Actions则是向流程图添加技术实现细节的一种机制，它可以很好的补充和修饰流程图。这意味着在不改变流程图结构的情况下，可以将Java的代码与之关联。Actions通过事件（Events）同流程绑定，常用的主要事件包括：进入结点、离开结点、进行转向。请注意，同Events关联的Actions和处于Node中的Actions是有不同的。处于Events中的Actions是通过事件触发执行的，它是典型的观察者模式，是无法影响流程控制的流向。而处于Node中的Action则要承担起流程传递的责任。此外，Actions是可以命名的。可以通过Actions的命名在任何地方引用该Actions。命名的Actions可以作为主流程定义的公用子元素。这个功能可以提高对Actions定义的复用。
Java 对象	org.jbpm.graph.def.Action
数据库表	JBPM_ACTION该表存储流程定义中的动作对象。
表关联说明	JBPM_ACTION表中，每条记录有自己的数据库流水号ID_  JBPM_ACTION的外键（Foreign Keys）： processdefinition_ - 指明action所属的流程定义ID event_ - 指明action绑定的event ID actiondelegation_ - 指明action的委派对象ID exceptionhandler_ - 指定action的异常处理ID referencedaction_ - 指向当前action引用的action的ID timeraction_ - 指向当前action引用的计时器action

 

4.8.7.5事件（Events）

编号	PD-005
对象	事件（Events）
描述	事件表示流程执行中的某个特定的时刻。在流程执行的过程中，通过jBPM的引擎触发事件，这通常发生在jbpm计算后续状态的时候。事件总是和流程中的元素绑定，这些元素包括：流程定义（process definition）、流程结点（node）、流程转向（transition）和任务（task）。不同的元素会触发不同的事件，拿node元素来说，有 node-enter事件和node-leave事件。事件是action的钩子，一个事件可以回调一系列的action。当jBPM引擎触发事件的时候，事件中绑定的action就会被执行。在jBPM中，事件模型是可传播的。一个子元素触发的事件，将逐层向上传播到顶层的流程定义元素。这样的设计使得事件可以被集中化处理。
Java 对象	org.jbpm.graph.def. Event
数据库表	JBPM_EVENT该表存储流程定义中的事件对象，这些事件与相关的action绑定。
表关联说明	JBPM_EVENT表中，每条记录有自己的数据库流水号ID_  JBPM_EVENT的外键（Foreign Keys）： processdefinition_  - 指向event所属的流程定义ID node_  - 指向event所属的node ID transition_  - 指向event所属的transition ID task_  -  指向event所属的任务ID

4.8.7.6     任务（Task）

编号	PD-006
对象	任务（Task）
描述	任务作为流程定义中的一部分，定义了如何创建任务实例（Task instances）以及任务分配。任务可以在任务结点（Task-Node）和流程定义（process-definition）两个地方定义。通常会在一个任务结点中定义一个或多个的任务。在这种情况下，任务结点表示在流程中等待用户处理的交互操作。业务流程会停留在任务处，等待用户完成相应的操作之后继续。任务也可在流程定义中声明。通过任务名，可以找到相应的任务定义，并引用他们。实际上任何有命名的任务都可以通过名字被引用。在整个的流程定义中，任务名必须是唯一的。此外，还可以给任务设定优先级，这些优先级属性将成为任务实例化时的默认设置。任务实例可以在之后的运行中改变优先级。.
Java 对象	org.jbpm.taskmgmt.def.Task
数据库表	JBPM_TASK该表存储流程定义中声明的任务对象。
表关联说明	JBPM_TASK表中，每条记录有自己的数据库流水号ID_   JBPM_TASK的外键（Foreign Keys）： processdefinition_  -指向task所属的流程定义ID taskmgmtdefinition_ - 指向task引用的TaskMgmtDefintion对象ID tasknode_ - 指向task所属的任务结点ID startstate_ -指向task所属流程的起始结点ID assignmentdelegation_ - 指定task委派处理的class对象的ID swimlane_ - 指定task要授权的swimlane（角色）ID taskcontroller_ - 指定一个task赋值的委托类

        

4.8.8        具体化的流程实例模型

流程实例中最重要的三个对象：流程实例（Process Instance）、令牌（Token）、任务实例（Task Instance）.

4.8.8.1       流程实例（Process Instance）

编号	PI-001
对象	流程实例（Process Instance）
描述	流程实例是流程定义的运行时状态，它记录了一个流程运行的起始时间、结束时间等状态信息
Java 对象	org.jbpm.graph.exe.ProcessInstance
数据库表	JBPM_PROCESSINSTANCE该表存储运行时的流程对象信息。
表关联说明	JBPM_PROCESSINSTANCE 表中，每条记录有自己的数据库流水号  ID_JBPM_PROCESSINSTANCE 的外键（ Foreign Keys ）： processdefinition_ - 该流程实例对应的流程定义的ID roottoken_ - 该流程实例引用的跟令牌 superprocesstoken_ - 如果当前流程是某个流程实例的子流程，则指向该父流程的ID

4.8.8.2       令牌（Token）

编号	PI-002
对象	令牌（Token）
描述	令牌代表一个流程执行的路径，它维护着流程定义中各个结点的指针，同时记录了流程当前执行的位置。
Java 对象	org.jbpm.graph.exe.Token
数据库表	JBPM_TOKEN该表存储运行时令牌对象信息，它表示当前流程执行到的位置。
表关联说明	JBPM_TOKEN 表中，每条记录有自己的数据库流水号 ID_  JBPM_TOKEN 的外键（ Foreign Keys ）： processinstance_  -  指向该令牌所属的流程实例的ID。 subprocessinstance_ - 指向该令牌所属的子流程实例ID。 node_  - 令牌所在（所指向的）的当前节点ID. parent_ - 如果当前令牌是一个分支流程或子流程的令牌，则该值指向其父令牌ID。

4.8.8.3        任务实例（Task Instance）

编号	PI-003
对象	任务实例（Task Instance）
描述	一个任务实例对象可以分配给指定的操作者处理，当任务完成后，将触发流程继续下行。任务实例的生命周期很简单，生成实例-->开始处理-->任务结束。从弹性设计考虑出发，任务的分配不属于实例生命周期的一部分，任务是否被分配是不会影响其生命周期过程的。当流程进入一个任务结点的时候，结点上任务被实例化；用户通过访问系统的界面组件，获取自己的任务列表，可以进行任务委派、处理或直接结束任务。任务实例记录着任务创建的时间、结束时间，这些信息可以通过TaskInstance对象中的getter方法获取。一个任务实例的结束时间标识它的完成，在后绪的任务查询中，该实例不会被取出，但实例的记录仍保留于数据库中。
Java 对象	org.jbpm.taskmgmt.exe.TaskInstance
数据库表	JBPM_ TASKINSTANCE该表存储运行时任务实例信息。
表关联说明	JBPM_ TASKINSTANCE 表中，每条记录有自己的数据库流水号 ID_JBPM_ TASKINSTANCE 的外键（ Foreign Keys ）： task_ - 指向定义该实例的任务ID token_ - 指向任务实例对应的令牌ID swimlaneinstatnce_  - swimlane 实例，表示处理该任务的角色 taskmgmtinstance_  -  管理该任务的模块实例ID

 

4.9         Pluggable architecture

The functionality of jBPM is split into modules. Each module has a definition and an execution (or runtime) part. The central module is the graph module, made up of the ProcessDefinition and the ProcessInstance. The process definition contains a graph and the process instance represents one execution of the graph. All other functionalities of jBPM are grouped into optional modules. Optional modules can extend the graph module with extra features like context (process variables), task management, timers, ...

Figure 21.1. The pluggable architecture

The pluggable architecture in jBPM is also a unique mechanism to add custom capabilities to the jBPM engine. Custom process definition information can be added by adding a ModuleDefinition implementation to the process definition. When the ProcessInstance is created, it will create an instance for every ModuleDefinition in the ProcessDefinition. The ModuleDefinition is used as a factory for ModuleInstances.

4.10     Spring

Spring Framework 是一个 Java/Java EE/.NET 的分层应用程序框架。该框架基于 Expert One-on-One Java EE Design and Development（ISBN 0-7645-4385-7）一文中的代码，并最初由 Rod Johnson 和 Juergen Hoeller et al 开发。Spring Framework 提供了一个简易的开发方式，这种开发方式，将避免那些可能致使底层代码变得繁杂混乱的大量的属性文件和帮助类。 Spring 中包含的关键特性： ◆强大的基于 JavaBeans 的采用控制翻转（Inversion of Control，IoC）原则的配置管理，使得应用程序的组建更加快捷简易。 ◆一个可用于从 applet 到 Java EE 等不同运行环境的核心 Bean 工厂。 ◆数据库事务的一般化抽象层，允许插件式事务管理器，简化事务的划分使之与底层无关。 ◆内建的针对 JTA 和 单个 JDBC 数据源的一般化策略，使 Spring 的事务支持不要求 Java EE 环境，这与一般的 JTA 或者 EJB CMT 相反。 ◆JDBC 抽象层提供了有针对性的异常等级(不再从SQL异常中提取原始代码), 简化了错误处理, 大大减少了程序员的编码量. 再次利用JDBC时，你无需再写出另一个 '终止' 模块. 并且面向JDBC的异常与Spring 通用数据访问对象 (Data Access Object) 异常等级相一致. ◆以资源容器，DAO 实现和事务策略等形式与 Hibernate，JDO 和 iBATIS SQL Maps 集成。利用众多的翻转控制方便特性来全面支持, 解决了许多典型的Hibernate集成问题. 所有这些全部遵从Spring通用事务处理和通用数据访问对象异常等级规范. ◆灵活的基于核心 Spring 功能的 MVC 网页应用程序框架。开发者通过策略接口将拥有对该框架的高度控制，因而该框架将适应于多种呈现技术，例如 JSP，FreeMarker，Velocity，Tiles，iText 以及 POI。值得注意的是，Spring 中间层可以轻易地结合于任何基于 MVC 框架的网页层，例如 Struts，WebWork，或 Tapestry。 ◆提供诸如事务管理等服务的面向方面编程框架。

4.11     Spring Modules

Spring Modules is a sub-project of Spring intended to ease integration with 3rd party products without overloading the core framework with additional dependencies.

The modules included in the 0.9 release are:

• Ant integration.
• Flux suite of products integration.
• HiveMind integration.
• Lucene integration.
• Apache OJB integration.
• O/R Broker integration.
• OSWorkflow integration.
• Tapestry integration.
• Support for declarative caching services including EHCache, JCS, OSCache, GigaSpaces and others.
• Support for db4o
• Support for JSR-94 Rules Engines such as Drools and Jess
• Support for various Jakarta Commons components such as Configuration, Lang, Chain and Commons Validator
• Support for JavaSpaces, including Gigaspaces and Blitz.
• Support for jBPM 3.0.x and 3.1.x
• Support for JSR-170 (Java Content Repository) including Jackrabbit and Jeceira.
• Support for web template engines like Freemarker, Groovy, Velocity, WebMacro and XSLT.
• Valang: Validation Language.
• Bean Validation Framework.
• Spring MVC add-ons.
• XT Framework: Domain-Driven Design oriented framework and Spring MVC AJAX support for developing richer domain models and richer user interfaces.

5         集成

5.1         Introduction

jBPM module offers integration between the Spring and jBPM allowing for reuse of Spring's Hibernate support along with the IoC container. The module allows jBPM's underlying Hibernate sessionFactory to be configured through Spring and jBPM actions to access Spring's context.

5.2         Configuration

Users familiar with Spring will see that the jBPM module structure resembles with the orm package from the main Spring distribution. The module offers a central template class for working with jBPM, a callback to access the native JbpmContext and a local factory bean for configuration and creating a jBPM instance.

<beans>

 <!-- DataSource definition -->

 <bean id="dataSource" class="...">

    ...

 </bean>

 <!-- Hibernate SessionFactory definition -->

 <bean id="hibernateSessionFactory" 

     class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">

    ...

 </bean>

 <!-- helper for reading jBPM process definitions -->

 <bean id="simpleWorkflow" 

      class="org.springmodules.workflow.jbpm31.definition.ProcessDefinitionFactoryBean">

    <property name="definitionLocation" 

      value="classpath:org/springmodules/workflow/jbpm31/simpleWorkflow.xml"/>

 </bean>

 <!-- jBPM configuration -->

 <bean id="jbpmConfiguration" 

      class="org.springmodules.workflow.jbpm31.LocalJbpmConfigurationFactoryBean">

    <property name="sessionFactory" ref="hibernateSessionFactory"/>

    <property name="configuration" value="classpath:jbpm.cfg.xml"/>

    <property name="processDefinitions">

     <list>

      <ref local="simpleWorkflow"/>

     </list>

    </property>

    <property name="createSchema" value="true"/>

    <property name="processDefinitionsResources">

     <list>

      <value>classpath:/org/springmodules/workflow/jbpm31/someOtherWorkflow.xml</value>

     </list>

    </property>

 </bean>

 <!-- jBPM template -->

 <bean id="jbpmTemplate" class="org.springmodules.workflow.jbpm31.JbpmTemplate">

 <constructor-arg index="0" ref="jbpmConfiguration"/>

 <constructor-arg index="1" ref="simpleWorkflow"/>

 </bean>

set

</beans>

The example above shows how (existing) Spring-managed Hibernate SessionFactories and transaction management can be reused with jBPM.

5.3         LocalJbpmConfigurationFactoryBean

The main element is LocalJbpmConfigurationFactoryBean which should be familiar to users acustomed to Spring. Based on the jbpm configuration file and the given SessionFactory, it will create a jBPM configuration which can be used for working with the given process definitions. It is possible to replace jBPM xml configuration with jBPM 3.1.x newly added ObjectFactory - note that if both are present the xml configuration is preffered. LocalJbpmConfigurationFactoryBean allows the creation of the underlying schema based on the process definitions loaded automatically at startup.

Note that the sessionFactory property is not mandatory - Hibernate SessionFactory can be reused with jBPM or jBPM can work by itself without any integration with the existing infrastructure. However, in most scenarios, using LocalJbpmConfigurationFactoryBean allows one to take advantage of Spring transaction management infrastructure so it's possible without any code change to use jBPM, Hibernate and jdbc-based code inside the same transactional context, be it managed locally or globally (JTA). Moreover, it is possible to use thread-bound session or OpenSessionInView patterns with jBPM.

LocalJbpmConfigurationFactoryBean is also aware of the enclosing applicationContext lifecycle - jBPM will be initialized once the context is started (usually application startup) and will be closed properly when the context is destroyed (application is shutdown).

Note that LocalJbpmConfigurationFactoryBean can be configured programatically and can be used standalone only to build an jBPM context which can be used independently of Spring Modules jBPM support.

5.4         Inversion of Control: JbpmTemplate and JbpmCallback

Another important feature of Spring Modules jBPM support is JbpmTemplate. The template offers very convient ways of working directly with process definitions as well as jBPM API taking care of handling exceptions (be it jBPM or Hibernate based) in respect to the ongoing transaction (if it's present), the underlying Hibernate session (if pesistent services are used) and the jBPM context. jBPM exceptions (and the underlying Hibernate information) are translated into Spring's DAO exception hierarchy. Everything happens in a transparent and consistent manner.This is possible, as with every Spring-style template,even when direct access to the native JbpmContext is desired, through the JbpmCallback:

public ProcessInstance findProcessInstance(final Long processInstanceId) {

 return (ProcessInstance) execute(new JbpmCallback() {

     public Object doInJbpm(JbpmContext context) {

      // do something

      ...

      return context.getGraphSession().loadProcessInstance(processInstanceId.longValue());

     }

 });

}

As well, as LocalJbpmConfigurationFactoryBean, the JbpmTemplate can be configured programatically and can be used standalone on a pre-existing jbpmContext (configured through LocalJbpmConfigurationFactoryBean or not) and can be used independently of Spring Modules jBPM support.

5.5          ProcessDefinitionFactoryBean

ProcessDefinitionFactoryBean is a simple reader that loads jBPM process definition using Spring's ResourceLoaders. Thus, the xml files can be load using the classpath, relative or absolute file path or even from the Servlet Context. See the official documentation for more information.

Note

As reported on the forums, using ProcessDefinitionFactoryBean jBPM 3.1.1will trigger a new process definition to be persisted(through deployProcessDefinition) at each startup. While this is useful in development when the database is created on application startup and destroyed on closing, for cases where the definition doesn't change, the process should not be declared inside Spring XML files.

Note

As reported here, due to the static nature of jBPM, process definitions which include sub processes are not loaded properly if a JbpmContext does not exist at the time of the loading (no exception is thrown whatsoever). As a workaround consider using the LocalJbpmConfigurationFactoryBean's processDefinitionsResources property.

5.6         Outside Spring container

It is important to note that while our example showed LocalJbpmConfigurationFactoryBean and JbpmTemplate template inside a Spring xml, these classes do not depend on each other or on Spring application context. They can be just as well configured programatically and can

5.7          Accessing Spring beans from jBPM actions

Another important feature of Spring Modules jBPM integration is allowing Spring configured beans to be reused inside jBPM actions. This allows one to leverage Spring container capabilities (bean lifecycles, scoping, injection, proxying just to name a few) in a transparent way with jBPM. Consider the following Spring application context:

<beans>

 <!-- Spring bean visible inside jBPM processed -->

 <bean id="jbpmAction" class="org.MyJbpmActionHandler" singleton="true">

   <property name="someProp" ref="anotherBean"/>

   ...

 </bean>

..

</beans>

and jBPM process definition:

<?xml version="1.0" encoding="UTF-8"?>

<process-definition name="simpleWorkflow">

 <start-state>

 <transition to="myState">

 </transition>

 </start-state>

 <state name="myState">

 <transition to="end">

   <action name="myAction" config-type="bean" 

      class="org.springmodules.workflow.jbpm31.JbpmHandlerProxy">

    <targetBean>jbpmAction</targetBean>

    <factoryKey>jbpmConfiguration</factoryKey>

   </action>

 </transition>

 </state>

 <end-state name="end"/>

</process-definition>

JbpmHandlerProxy transparently locates Spring applicationContext and searches the bean identified by the targetBean parameter (in this case jbpmAction) and delegate all calls to the jBPM action. This way, one is not limited only to the injection offered by jBPM container and can integrate and communicate in a very easy manner with other Spring managed beans. Moreover, your action lifecycle can be sigleton (one shared instance) or prototype (every call gets a new instance) or in Spring 2.0 scoped to a certain application component (like one instance per http session).

The optional factoryKey parameter specified in this example should be used when one is dealing with more then one jBPM configuration inside the same classloader (not common in practice). The factoryKey should be the same as the bean name of the LocalJbpmConfigurationFactoryBean to be used (in our case jbpmConfiguration).

6         关键设计

6.1         环境配置

6.1.1        Required Jar edition

本文分析和举例时，采用的软件版本为：

1.      spring-2.1-m4.jar

2.      spring-modules-jbpm31.jar

3.      jbpm-jpdl-3.2.2.jar

6.1.2        applicationContext.xml

6.1.2.1       配置jbpm中相关xml文件

<bean id="hibernateSessionFactory

" class = "org.springframework.orm.hibernate3.LocalSessionFactoryBean" >

       < property name = "dataSource" >< ref local = "dataSource" /></ property >

       < property name = "mappingDirectoryLocations" >

           < list >

              < value > classpath:/com/myCompany/jbpmtest/system/po </ value >

             

           </ list >

       </ property >

        <property name="mappingLocations">

           <list>

              <value>classpath*:/org/jbpm/**/*.hbm.xml</value>

           </list>

       </property>

      

       < property name = "hibernateProperties" >

           < props >

              < prop key = "hibernate.dialect" > org.hibernate.dialect.Oracle9Dialect </ prop >

              < prop key = "hibernate.show_sql" > true </ prop >

              < prop key = "hibernate.query.substitutions" > true 1,false 0,yes 'Y',no 'N' </ prop >

              <!-- (JBPM Config)avoid happen: org.hibernate.HibernateException: Could not instantiate cache implementation -->

              <prop key="hibernate.cache.provider_class">org.hibernate.cache.HashtableCacheProvider</prop>

           </ props >

       </ property >

    </ bean >

6.1.2.2       JbpmTemplate和LocalJbpmConfigurationFactoryBean配置

<!--bean id="openApply"

       class="org.springmodules.workflow.jbpm31.definition.ProcessDefinitionFactoryBean">

       <property name="definitionLocation"

           value="classpath:../../jbpmPrcsDef/openApply/processdefinition.xml" />

    </bean-->

 

    <!-- jBPM configuration -->

    < bean id = "jbpmConfiguration"

       class = "org.springmodules.workflow.jbpm31.LocalJbpmConfigurationFactoryBean" >

       < property name = "sessionFactory" ref = "sessionFactory" />

       < property name = "configuration" value = "classpath:jbpm.cfg.xml" />

       < property name = "createSchema" value = "false" />

       <!-- property name="processDefinitions">

           <list>

              <ref local="openApply" /> 

           </list>

       </property-->

    </ bean >

   

    <!-- jBPM template -->

    < bean id = "jbpmTemplate"

       class = "org.springmodules.workflow.jbpm31.JbpmTemplate" >

       < constructor-arg index = "0" ref = "jbpmConfiguration" />

    </ bean >

6.1.3        jbpm-configuration

< jbpm-configuration >

 

  <!--

   This configuration is used when there is no jbpm.cfg.xml file found in the

    root of the classpath. It is a very basic configuration without persistence

    and message services. Only the authorization service installed.

    You can parse and create processes, but when you try to use one of the

    unavailable services, you'll get an exception.

 -->

 

  < jbpm-context >

    <!--service name="persistence" factory="org.jbpm.persistence.db.DbPersistenceServiceFactory" /-->

    < service name = "persistence" >

        < factory >

           < bean class = "org.jbpm.persistence.db.DbPersistenceServiceFactory" >

              < field name = "isTransactionEnabled" >< false /></ field >

              < field name = "isCurrentSessionEnabled" >< true /></ field >

           </ bean >

       </ factory >     

    </ service >

    < service name = "tx" factory = "org.jbpm.tx.TxServiceFactory" />

    < service name = "message" factory = "org.jbpm.msg.db.DbMessageServiceFactory" />

    < service name = "scheduler" factory = "org.jbpm.scheduler.db.DbSchedulerServiceFactory" />

    < service name = "logging" factory = "org.jbpm.logging.db.DbLoggingServiceFactory" />

    < service name = "authentication" factory = "org.jbpm.security.authentication.DefaultAuthenticationServiceFactory" />

  </ jbpm-context >

 

  <!-- configuration property used by persistence service impl org.jbpm.persistence.db.DbPersistenceServiceFactory

 now set using spring configuration file

 <string name="resource.hibernate.cfg.xml" value="hibernate.cfg.xml" />

 -->

  <!-- configuration resource files pointing to default configuration files in jbpm-{version}.jar -->

  < string name = "resource.business.calendar" value = "org/jbpm/calendar/jbpm.business.calendar.properties" />

  < string name = "resource.default.modules" value = "org/jbpm/graph/def/jbpm.default.modules.properties" />

  < string name = "resource.converter" value = "org/jbpm/db/hibernate/jbpm.converter.properties" />

  < string name = "resource.action.types" value = "org/jbpm/graph/action/action.types.xml" />

  < string name = "resource.node.types" value = "org/jbpm/graph/node/node.types.xml" />

  < string name = "resource.parsers" value = "org/jbpm/jpdl/par/jbpm.parsers.xml" />

  < string name = "resource.varmapping" value = "org/jbpm/context/exe/jbpm.varmapping.xml" />

 

  < long   name = "jbpm.msg.wait.timout" value = "5000" singleton = "true" />

  < int    name = "jbpm.byte.block.size" value = "1024" singleton = "true" />

  < string name = "mail.smtp.host" value = "localhost" />

  < bean   name = "jbpm.task.instance.factory" class = "org.jbpm.taskmgmt.impl.DefaultTaskInstanceFactoryImpl" singleton = "true" />

  < bean   name = "jbpm.variable.resolver" class = "org.jbpm.jpdl.el.impl.JbpmVariableResolver" singleton = "true" />

  <!--bean   name="jbpm.mail.address.resolver" class="org.jbpm.identity.mail.IdentityAddressResolver" singleton="true" /-->

 

</ jbpm-configuration >

6.2         流程定义发布

6.2.1        意图

通过servlet方式发布流程定义文件，并通过配置文件参数灵活控制重新发布或更新已有的流程文件。

6.2.2        动机

Deploying process archives can be done in 3 ways: with the process designer tool, with an ant task or programaticall。

随着业务流程的变化，流程定义文件也需要变更进行重新发布，需要一种灵活的发布方式。即要避免每次启动服务器都重新发布，也要避免发布后，不能再次更新的问题。

一个更好的办法就是可以通过一个serlet进行控制是否进行发布。

6.2.3        适用性

当流程定义没有变化时，当启动servlet容器时，不必重复部署。

6.2.4        效果

灵活控制发布方式，避免重复发布。

6.2.5        实现

l         JbpmDeployServlet：获得要发布的文件、部署方式。

l         JbpmDefinitionService：根据部署方式，获得流程实例ProcessDefinition

l         JbpmContext：完成实际部署。

6.3         面向接口的设计

6.3.1        意图

设计独立于具体组件内部逻辑的接口，降低业务程序与具体组件的耦合性，支持变化，可以根据需要增加对新组件的使用。

6.3.2        动机

jbpm组件内部相关的类可能随着版本不同而变化。或者今后想采用其他工作流组件。设计独立于实现的接口提供了一直的规约，屏蔽变化。

6.3.3        适用性

使用第三方组件。

6.3.4        结构

适配器模式。

6.3.5        实现

在jPDL中，对流程的建模被划分为两大部分，一是针对“流程定义”的静态模型部分；二是针对具体“流程实例”的运行时动态模型。

静态的流程定义模型：流程定义实体（Process Definition）、流程结点（Node）、流程转向（Transitions）、动作（Actions）、事件（Events）、任务（Task）。

具体化的流程实例模型（运行时动态模型）：流程实例（Process Instance）、令牌（Token）、任务实例（Task Instance）

可以根据功能范围的不同，可以封装不同的接口和实现不同实现类。对于流程文件的操作、对流程的操作，可以分为两大类接口。

6.3.5.1       接口模型

6.3.5.2       参数约定

为了使得业务程序和工作流组件之间信息交互，这些参数包括：

l         业务流程标识。

n         对于受理系统、工单系统等，可以成为：工单标识

n         可以该标识通过工作流ContextInstance对象中保存到：jbpm_variableinstance表中。

n         它是关联业务信息和工作流信息的之间唯一标识。当启动一个工作流时，业务程序产生一个唯一的值，并需要把该值传递给工作流组件。

n         业务流程标识、流程实例标识是一一对应，可以通过业务流程标识进行查询流程实例标识。

l         用户标识

n         应用于：创建、取消/结束任务、任务回退等操作时

l         任务标识

n         应用于：取消/结束任务等

l         任务名称

n         工作流每一个节点一个名称，业务程序处理到每一个业务环节，都有个环节状态名称，为了便于数据交互，可以把：工单环节状态名称和工作流每一个任务节点名称，命名为一致的。或称为：业务处理环节名称、业务状态名称、工单状态等

l         流程转向名称

n         从一个节点转移到另外一个节点。

n         应用于：创建流程、完成任务、回退任务。

6.3.5.3       参数命名约定

l         命名方式

n         简洁、合乎规范、如果是英文名称，采用通用缩写，或英文全称。

l         节点名称

n         名词+动词

l         转移路径名称

n         动词+名词

6.3.5.4       参数处理方式

l         业务流程具体环节名称（工单状态名称）

n         完成一项工作，通常需要不同的环节才能完成。每一个环节可以与工作流中的某个节点对应。

n         通常它将在页面或流程图中展示。

n         定义在常量类中，并提供帮助方法。

n         建议该名称与工作流流程定义图中的任务节点名称采用一样。不需要额外的转换，降低沟通成本。

l         工作流流程名称

n         根据工作流程的不同，通过采用不同的工作流程，不同的流程有不同环节。

n         一个流程的名称通常是稳定的。可以对不同的流程名称，定义在常量类中。方便在页面展示，数据存储。

n         建议该名称与工作流中流程定义文件名称采用一样。不需要额外的转换，降低沟通成本。

6.3.5.5       操作流程文件接口

l         使用流程存档文件，部署新的流程定义。

n         Param：归档文件名

l         使用流程存档文件，创建一个新版本的流程定义。

n         Param：归档文件名

l         部署新的流程定义

n         Param：普通文件名

l         创建一个新版本的流程定义

n         Param：普通文件名

l         根据流程名称获取流程定义

n         Param：流程名称

n         Return：流程定义对象

l         根据流程标识获取流程定义

n         Param：流程标识

n         Return：流程定义对象

6.3.5.6       操作流程接口

l         创建流程实例,并创建和启动流程的开始任务实例。

n         Param：流程名称、业务流程id、创建人

n         Return: 开始任务实例id

l         删除流程实例

n         Param：业务流程id

l         查询流程实例当前所处节点

n         Param：业务流程id

n         Return: 任务节点名称

l         判断流程实例是否完成

n         Param：业务流程id

n         Return: true/ false

l         完成某个任务实例，并转移到流程的缺省节点

n         Param：用户标识、任务实例id

n         Return: 流程实例当前节点名称

l         完成某个任务实例，并转移到指定的节点。

n         Param：用户标识、任务实例id、任务完成后的转移名

n         Return: 流程实例当前节点名称

l         完成任务实例，取消该任务实例对应的未完成的兄弟任务实例

n         Param：用户标识、任务实例id、任务完成后的转移名

n         Return: 流程实例当前节点名称。

l         任务实例是否完成

n         Param：任务实例id

n         Return: true/ false

l         获取任务实例的转移路径

n         Param：任务实例id 、是否包含缺省转移路径，true：包含；false：不包含。

n         Return: true/ false

l         查询流程实例的根令牌标识

n         业务流程id

n         Return: 根令牌标识

l         关闭工作流服务

6.4         用户管理

6.4.1        The assignment data model

The datamodel for managing assignments of task instances and swimlane instances to actors is the following. Each TaskInstance has an actorId and a set of pooled actors.

Figure 11.1. The assignment model class diagram

The actorId is the responsible for the task, while the set of pooled actors represents a collection of candidates that can become responsible if they would take the task. Both actorId and pooledActors are optional and can also be combined.

6.4.2        意图

系统的用户根据业务发展可以动态的变化，但是系统角色是相对稳定的，对于流程定义文件，在<swimlane>中，<assignmen>中的pooled-actors属性，可以配置为业务系统中的角色标识，一个角色它本身代表一类用户，不需配置为具体的用户标识。

当用户登录系统，如果查看自己工作（或待处理的任务、待处理的工单）

6.4.3        动机

如果没有使用jBPM组件的认证模块，而是采用自己系统的权限管理，当用户的增加、减少时，每次都需要修改流程定义文件，在<assignmen>中的pooled-actors中增加用户标识。每次修改都需要重新发布。维护成本很高。

6.4.4        适用性

系统具有自己权限管理。包括：用户管理、角色管理。

6.4.5        结构

6.4.6        协作

l         参与者可以查询自己曾经受理过的工单。

l         参与者可以查看自己对应角色的未处理的工单。

6.4.7        效果

角色标识是相对稳定的，因此灵活控制发布方式，避免重复发布。

6.4.8        实现

准备：

l         业务系统：定义用户角色标识。例如：两个角色：1：教师 2：校长。用户标识：user001该用户有两个角色。

l         工作流组件：配置用户角色标识。实例：

< swimlane name = " 授课员 " > // 授课员泳道

           < assignment pooled-actors = "1,2" /> // 分配两个角色

    </ swimlane >

实现方式：

1.      根据登录用户user001，获得用户角色列表1、2。

2.      根据用户角色列表，查询相关表或视图，查出“ 授课员”所有对应的角色的工单。

6.5         信息查询

6.5.1        意图

把业务系统产生的业务流程标识，保存到工作流组件表中，作为业务系统和工作流组件之间信息交互的纽带。jBPM提供了在一个流程执行过程中，保存流程上下文变量（Process Context Variables）机制，流程上下文变量类似与java.util.Map，能映射名称到值。

可以在业务系统和工作流系统中相关的表中中字段创建视图，方便查询。

6.5.2        动机

l         查询某个用户的代办工单（记录），包括：曾经处理过的工单（但是流程没有结束，比如：回退的工单）、将要处理的工单。信息包括：业务流程标识、流程实例标识、任务节点标识、节点名称等信息。

l         根据用户标识、任务标识、流程转向等字段，对任务实例进行完成、取消等操作。

6.5.3        适用性

查询待处理或曾经处理的工单记录，同时查询工作流组件表中的任务标识、任务名称等。

6.5.4        结构

6.5.5        协作

业务系统某个用户，可以根据业务流程标识查询到流程实例标识、任务标识等信息。

6.5.6        效果

通过业务流程标识，可以方便查询工作流相关信息。以便精确的控制工作流的流程转向、图形展示等。

6.5.7        实现

l         建立一个任务视图。

n         记录包括：该用户待分配的记录、曾经受理过但打回工单（流程没有结束的记录）。

n         关联表包括：待分配任务的角色表、任务实例用户表、任务实例表。

n         字段包括：业务流程标识、流程实例标识、任务实例标识、任务实例名称、创建时间、结束时间、用户标识、。

6.6         流程图设计

6.6.1        意图

提供一个图形化查询某个业务流程流转情况，并通过特殊的颜色醒目所在的位置。

6.6.2        动机

如果仅展示业务流程所处的文字名称，不能更好获得上下文信息，还得需要查询其他图片或帮助手册查询，易操作性差。

解决办法就是，通过一个图片，该图片标记了各个节点信息，存储于数据库中，并且根据流程定义信息，动态的修改图片并进行展示。

6.6.3        适用性

用户查询业务流程的上下文信息。

6.6.4        结构

6.6.5        协作

客户请求展示。

6.6.6        效果

l         图形化方式展示当前业务流程环节。

l         方便查询业务流程环节上下文信息。

6.6.7        实现

l         Jsp进行展示。

l         Tag类实现具体业务逻辑。

l         Tld文件描述tag约定。

l         Servlet访问db输出图片信息。

7         参考资料

7.1         开源工作流引擎介绍

1.OBE 简介：遵循WfMC所定义的规范的工作流引擎 优点：支持WfMC定义的工作流接口规范，项目开发者也比较有来头。 缺点：不支持工作流实例的持久化，缺少图形编辑环境，尚未全部完成WfMC定义的五类接口 http://www.openbusinessengine.org/index.html 2.OFBiz 简介：OFBiz本身是一套独立完整的企业应用框架，包括了通常的通用中间件和部分领域的逻辑中间件       OFBiz最出名的是它的实体引擎和服务引擎，此外还提供了规则引擎和工作流引擎。 优点：实体引擎和服务引擎，灵活强大稳定，基于其上的工作流引擎也是不错了。用例比较多，参考文档较丰富。 缺点：庞大，不是单独的工作流引擎。 http://www.ofbiz.org/ 3.werkflow 简介：该工作流引擎基于状态和过程，致力于业务集成和用户交互，充分使用分层和插件思想，很容易和其它组件配合使用。 优点：可扩展性好，基于可执行XML脚本的思想 缺点：更新不及时，缺少规范 http://werkflow.codehaus.org/ 4.OSWorkflow 简介：非常灵活的工作流引擎，完全基于插件思想，可扩展性极强，基于状态。 优点：工作流引擎可工作于JSP Container，EJB Container，WS Container。       引擎支持自动任务和手工任务。       工作流实例以及相关数据可以持久化，可以选择JDBC、EJB、Hibernate等持久化方式。       具有工作流脚本图形编辑器。       各种功能基于插件方式，易于集成已有系统。       工作流可以调用Java、EJB、Bean Shell、BSF等功能。       支持权限。       定时任务调度。       适用于Web和非Web环境。 缺点：非标准脚本语言，工作流引擎对于自动任务支持尚不完善。 http://wiki.opensymphony.com/space/OSWorkflow/ 5.jbpm 简介：基于JBoss+EJB的工作流引擎。 优点：安装简便，支持动态部署，工作流引擎支持交互界面的脚本，适用于WEB环境。 缺点：与JBoss和EJB结合过于紧密，不便于分离。 http://www.jbpm.org 6.bonita 简介：非常小巧的工作流引擎 优点：基于PetriNet模型，便于理论分析，支持持久化 缺点：过于简单，只适合研究分析工作流使用 http://bonita.debian-sf.objectweb.org/ 7.其它相关项目 7.1 apache-commons-jelly 其核心思想是“可执行XML”，适合于在编写工作流引擎时使用。 http://jakarta.apache.org/commons/jelly/index.html 7.2 blissed 基于jelly的工作流基础组件。 http://blissed.codehaus.org/index.html 7.3 JSR 207 JSR 207 - Process Definition for JavaTM 不知道是否有标准的实现 7.4 LenyaWorkflow 很抽象的理论，形式化的描述 http://wiki.cocoondev.org/Wiki.jsp?page=LenyaWorkflow 7.5 struts workflow extention 基于struts实现的页面跳转控制器 http://www.livinglogic.de/Struts/introduction.html 7.6 taverna 网格项目中的工作流，致力于集成分布式计算环境，脚本规范、引擎、编辑器一应俱全。 http://taverna.sourceforge.net/

7.2         参考网址

1.        http://www.wfmc.org/

2.        www.jboss.org

3.        Workflow Patterns -Wil van der Aalst教授的工作流模式学术研究网站

4.        ebpml.org - 有关业务流程管理和工作流的网站，信息量大、全面

5.        Business process management group - The Business Process Management Group (founded in 1992) is a global business club exchanging ideas and best practice in business process and change management.

6.        Enix - 英国流程管理顾问公司，在网站上有不错的内容

7.        ebizq.net - Commercial community that has booths, webinars and other interesting stuff put together in a nice website.

8.        An introduction to petri nets - The title says it all.

9.        Organizational Management in Workflow Applications - An interesting article that discusses the relation between business processes and the organisational data involved.

10.    Web services orchestration - an HP-paper that reviews the emerging technologies tools and standards. (Januari 2003)

11.    Business process standards for web services - An article that discusses the various aspects involved in workflow and BPM.

7.3         WfMC

7.3.1        Introduction to the Workflow Management Coalition

Founded in 1993, the Workflow Management Coalition (WfMC) is a global organization of adopters, developers, consultants, analysts, as well as university and research groups engaged in workflow and BPM.  The WfMC creates and contributes to process related standards, educates the market on related issues, and is the only standards organization that concentrates purely on process.  The WfMC created Wf-XML and XPDL, the leading process definition used today in over 80 known solutions to store and exchange process models.  XPDL is not an executable programming language but a process design format for storing the visual diagram and process syntax of business process models, as well as extended product attributes.

7.3.2        Mission Statement

•	Increase the value of customers· investment with business process technology
•	Decrease the risk of using BPM and workflow products through interoperability standards
•	Expand the BPM market through increasing awareness the business value of process management

7.3.3        Why Should a Business Use Workflow?

The Evolution of Workflow Workflow Management consists of the automation of business procedures or "workflows" during which documents, information or tasks are passed from one participant to another in a way that is governed by rules or procedures.

Workflow software products, like other software technologies, have evolved from diverse origins. While some offerings have been developed as pure workflow software, many have evolved from image management systems, document management systems, relational or object database systems, and electronic mail systems. 

Vendors who have developed pure workflow offerings have invented terms and interfaces, while vendors who have evolved products from other technologies have often adapted terminology and interfaces. Each approach offers a variety of strengths from which a user can choose. Adding a standards based approach allows a user to combine these strengths in one infrastructure.

7.3.4        The Key Benefits

•	Improved efficiency - automation of many business processes results in the elimination of many unnecessary steps
•	Better process control - improved management of business processes achieved through standardizing working methods and the availability of audit trails
•	Improved customer service - consistency in the processes leads to greater predictability in levels of response to customers
•	Flexibility - software control over processes enables their re-design in line with changing business needs
•	Business process improvement - focus on business processes leads to their streamlining and simplification