BlogJava-java神谕-文章分类-工作流

BPM≠Workflow＋EAI

java世界畅谈 — Thu, 16 Jun 2005 10:09:00 GMT

作者:梁宾先

转载自:http://taiwan.cnet.com

在谈完 BPM 相关标准之后，这次我想跟读者谈 BPMS 的架构、组成模块及其各自功能，让读者有全盘性的了解，希望能破除一般人对 BPMS 的迷思。

关于 BPM ，业界有些迷思。例如，常听到有人说 BPM = EAI + Workflow ； PBMS 只不过 Workflow 厂商的旧瓶新酒，换汤不换药，只要原来 WfMS 加上系统整合的 Adaptors 就变成 BPMS ；或是 EAI 厂商加上 Activity Modeling 的工具或者是 Routing Engine 重新包装一下，也可以称作 BPMS 。

我认为 BPMS 不只是如此，而是一个生命周期。顺着 BPM 生命周期了解用户的操作场景 (Scenario) ，是理解 BPMS 的组成全貌最好且最直觉的方式。在本文中，我首先介绍完整 BPM 生命周期，并从其中的每一步骤接着介绍工作内容、使用到的工具及其功能、与用户的角色。最后，我会以一张完整的 BPMS 架构图，详细介绍其中组成的模块功能。

BPM ：也要谈生命周期 (Life Cycle)

BPMS 强调让企业可以灵敏反应外部环境的变动并快速变动企业内部的流程作业，所以生命周期所强调的是持续性改善与周而复始的循环。 BPM 生命周期另一个含意就是，它是 BPMS 工具导入的方法论 (Methodology) 。 BPMS 解决方案最重要的核心就是方法论，它至少要包含思考哲理 (Philosophy) 、方法 / 步骤 (Methods / Steps ) 、与伴随的工具 (Tools/Utilities) 。因为没有任何两家的流程，组织，策略目标是全然一样的，因此怎样才能从策略目标规划到最后系统导入执行连贯一体，成功而有效地完成建置所依赖的才是合适的方法论。

目前各家 BPM 厂商所提出的生命周期不尽相同，乃是因为解决方案所面对的产业或应用领域不同，所以有了各自强调与专注的重点。例如， IBM HoloSofx 提出的是：建构 (Create) 、管理 (Manage) 、自动 (Automate) 、协同 (Collaborate) ； Howard Smith & Peter Fingar 在『 BPM - The Third Wave 』一书所提出的是；建模 (Model) 、布署 (Deploy) 、与管理 (Manage) ； Italio 提出的是发掘 (Discovery) 、建模 (Modeling) 、支援 (Supporting) 、 Monitoring ( 监控 ) 、及 Improvement ( 改善 ) 。在此我会提出较为完整的流程步骤，但不见得每家 BPM 厂商的都符合，读者可参考下图－ BPM 生命周期。

图一、 BPM 生命周期

·阶段一、流程发掘 (Discovery) :

要导入 BPM 第一步骤当然要先清楚知道现行流程的作业方式与状况，尤其是流程内的信息流 (Message flow) 、事件流 (Event flow) 、或控制流 (Control flow) 。哪些流程可以自动化？哪些是人工流程？有哪些人参与？流程是在组织内部或外部被执行？ BPMS 在此步骤的主要特征是如何自动找出系统的商业逻辑。通常企业会聘请外部顾问师或领域专家来协助辅导，这个动作有人称为流程评估 (BPA, Business Process Assessment) ，评估范围可能涵盖策略与管理目标与流程的连结。同时企业也会配合导入一些管理的主题而作流程再造 (BPR, Business Process Reengineering) ，例如评分计分卡 (BSC, Balance Score Card) 、六个标准差 (Six Sigma) 、或 ISO 9000 品质管理系统。

· 阶段二、流程设计 (Design) ：

此阶段是一个包含四几个步骤的反复式的小循环 (Iterative mini-cycle) ：建模 (Modeling) 、 ( 分析 Analyzing) 、模拟 (Simulation) 、重构 (Redesigning) 流程。如前所述，面对外部的竞争压力与商机，为了让企业可以快速重构流程，因此一些细致的流程变革 (Fine-grained process change) 只需利用此阶段的步骤就能作出实时的反应。

流程建模所运用的工具称作 Process Designer 通常包含三个模块：组织 (Organization Chart) 、流程图 (Activity Diagram) 、与窗体 (e-Form) 设计工具。它们分别对应流程中三个最重要的元素：人、活动与文件 ( 有兴趣的读者可参阅 Process Modeling Conceptual Framework 有关的资料，后续容我在适当机会再做介绍 ) 。建模之后可以作执行动作前的分析与仿真来验证设计的流程是否正确合适或最佳化；此外它能还提供现行流程可能遇到的瓶颈信息，以避免执行后才发现问题进而导致很大的营运损失。如果分析模拟出来的结果并不满意，可以反复重构流程直到产出满意的结果。分析指的是从流程定义的语意与理论上的推论分析，仿真则可设定机率变量与行为假设让系统自动跑出期望值或变异差数据，有些则仅提供自动执行 (Animation) 或手动逐步执行以观测流程行为。

此阶段 BPMS 的主要特征是图形化的接口，让非 IT 背景的用户可藉由拖曳方式也能轻松组装或分解流程；此外运用流程资产 (Process assets) 的观念，让流程定义隐含业界的最佳实务 (Best practices) 或流程样版 (Process Pattern) ，并且储存于流程仓储 (Process Repository) 以供随时再利用 (reuse) 。

· 阶段三、流程执行 (Execution) ：

意指新上线的流程能被参与者顺利执行完成。负责控制执行的模块可称为工作流程引擎 (Workflow Engine) 或流程服务器 (Process Server) 。在此阶段 BPMS 主要的诉求是分布式交易 (Distributed transaction) 的管理，因为这些交易可能是复杂度高的跨巢状流程 (Nested process) 而且交织着新旧系统，甚至将既有的应用系统当成流程组件来执行。至于流程的执行者通常多是应用系统，可以不用人的参与 (human intervention) 而自动执行，也就是一般所称流程自动化 (BPA, Business Process Automation) 。

此外，排程工具 (Scheduler) 可以应用来设定自动启动流程的时间与周期频率。有些 BPMS 的产品会提供规则引擎 (Rule Engine) 来负责商业规则判别与推理。此阶段另一个重要的特点就是在不用技术人员的参与下，依然可以让流程用户自行编辑与修改商业逻辑。例如，代理人的指派规则通常相当复杂，背后就需要有 Rule-based 的机制来支持。

流程布署 (Deployment) ：意指将设计好的流程推出上线让所有参与者 (Participant ，可能是人，应用系统，或其它流程 ) 来执行。这个步骤的主要特征就是能以最小的力气﹙ effort ﹚达成运算资源 (Computing Resource) 与组织人员的结合 (binding) ，如事先整合应用系统组件 (Application components) 。

与人互动 (Interaction) ：在流程的执行中很重要的就是与人的互动。并非所有流程都可以自动化，所以 BPMS 让人能管理自动流程与人工流程之间的接口。负责与人互动的接口称为工作项目的处理程序 (Workitem Handler) 。有时候流程接口本身也是一个流程，例如动态加会签或在窗体输入下一步流程的分派。过去 Workitem Handler 相当简单，然而现在有倾向丰富化与细致化的趋势。必要的时候还能让用户客制化或整合在不同系统的接口中。由于这个需求有快速提升的趋势，所以各家厂商纷纷提出丰富且个人化的流程入口网站 (Personalized process Portal) 。

第四阶段、管理维护 (Administration) ：

当流程上线后伴随产生了管理维护的问题，如例外状况的介入处理、组织人员的变更、流程重新分派、或流程版本升级的影响。在此，有个重要的模块称作流程活动监控 (BAM, Business Activity Monitoring) ，它可以随时回报流程的执行状态与过程，而且用户也可以设定流程要追踪的关卡并主动回报，具有预警功能并能随时掌握问题处理的时效。另外服务器的流量与执行监控及流程仓储的数据维护的效能也相当重要。

第五阶段、流程最佳化 (Optimization) ：

流程改善 (Improvement) 是个持续性的活动，不断反复朝向最佳化迈进。流程测量 (Measurement) 能提供流程的执行绩效 (Performance) ； BPMS 的报表工具 (Reporting Tools) 能让企业对自己的组织行为充分了解作为持续改善的依据，如此方能策划出改善与最佳化的策略。流程分析 / 仿真着重在执行前的分析，例如自动侦测瓶颈 (bottleneck) 、死结 (deadlock) 与流程定义的不一致 (Consistence) ；而流程测量则是执行后实际资料的分析，可以清楚知道流程消耗时间与资源。这个阶段跟商业智慧 (BI, Business Intelligence) 的技术与主题相似性很高的，差异在 BPMS 可以自动纪录与收集流程相关的数据。尤其 BPMS 所附含的流程绩效仪表版 (Dashboard) ，它提供一个全面式的概观让主管简单掌握且一目了然哪些流程是在标准差内，哪些是在失控状态。当然这些报表，都是用户可以自行定义或查询的，不用 IT 人员的参与。

BPM ＞ Workflow +EAI

相信从上述的介绍，读者可以清楚认识到 BPM 绝对大于 Workflow 加 EAI 。 BPM 的主要精神在于企业流程的管理，且主要的焦点在于业务性用户 (business users) 而非技术性用户 (technical users) ；在于流程弹性实时调整而非数据与应用系统的整合。所以仅是工作流程自动化加上 EAI 企业应用软件的转换机制是不足以的涵盖企业管理流程中所有必要的环节。例如尚有让管理主管能实时掌握流程成本效率 (cost/effective) 评量与流程绩效 (Performance) 管理，业务性用户可以轻易调整组装流程以提供客户最佳业务服务，等等。

我将上述中的工具整合起来，架构如图二所述：

BPMS 系统架构 (System Architecture)

图二、 BPMS 系统架构图

一个完整的 BPMS 系统需由流程设计环境 (Process Design Environment) 、流程仓储或储存库 (Process Repository) 、流程服务器 (Process Server) 、用户执行环境 (User Execution Environment) 等主要元素所架构而成。

· 流程设计环境 (Process Design Environment)

流程设计环境扮演着流程设计阶段中最重要的流程建模工作，通常包含了「组织图」 (Organization chart) 、「电子化窗体」 (e-form) 、活动图 (Activity Diagram) 、与商业规则 (Business Rule) 等相关元素，并可透过直觉图形化的接口，协助流程设计者进行企业流程的建构。

组织图部份大多与组织目录服务系统 (Directory system) 相结合，以协助企业进行组织的调整与管理，如支持 LDAP 、 AD 等相关目录服务。而电子窗体指的是信息呈现的接口，一般而言可将应用系统的数据与流程相关的数据，透过所谓的电子窗体来展现，便于处理与人互动的部分，而呈现的方式可透过特定的工具快速的订制。在了解流程整体运作与规划中，透过活动图可清楚地规划与了解流程中的各个活动彼此的先后顺序与关联，并订定流程的运作条件与事件触发的相关动作，再透过结合商业逻辑（ Business Rule ）的方式，让企业更清楚流程的运作方式且易于修改，在采购流程中，若采购金额大于 100,000 台币者需签核至协理，其余仅需签至经理，就是个明显的例子。

流程仿真（ Simulator ）与流程设计分析（ Analyzer ），则是透过流程数据的仿真得以事先验证流程执行时的结果与流程设计关联的分析（如在复杂的流程中，重要的流程元素或关联未建立），达到流程执行前事先的预防，并确认设计的流程是否正确合适或最佳化。

· 流程数据储存库 (Process Repository)

流程仓储包含了流程定义 (Process Definition) 、流程执行纪录 (Execution Log) 、与应用数据 (Application Data) 。流程定义包括了流程运作所有相关的数据，最明显的就是流程三要素：人、活动与文件，都纪录在流程定义中，藉由流程的规则引擎 (Rule Engine) 的参数即数据的变异数或是各个节点所制定的活动时间限制等定出合适的流程定义，最后透过流程服务器执行定义好的流程；流程执行纪录指的是流程执行过程中所有的纪录，有的 BPMS 将此部份内建于系统中，有的则是需另行将所需纪录抄写到数据库中；应用数据则是指在流程执行的过程中，所使用到其它系统的相关数据并随着流程纪录下来或有所关联，如请采购流程执行中，需依照既有 ERP 系统的相关数据进行逻辑判断，甚至需将其抄写至流程窗体中。而在此所指的应用性数据并没有只局限在内部数据库，也包含了根据流程的定义向组织外可能以 web service 的方式呼叫外部数据来应用。

· 流程引擎 / 服务器 (Process Engine/Server)

流程引擎是整个 BPMS 中最重要的一环，它负责正确无误地将流程在正确的时间传送给正确的人或系统，而由于流程的运作为企业营运的核心，因此能处理复杂且大量的流程工作是流程引擎所必备的条件。分布式交易 (Distributed transaction) 的管理与负载平衡（ Load Balancing ）将是考量的重点。

· 用户执行环境 (User Execution Environment )

这边所说的用户环境指的就是用户与流程沟通的接口。一般简易的用户接口多藉由待办事项（ Work lists ）让用户使用流程工作。而由于企业入口网站的风行，一个面面俱到的 BPM 产品通常透过 Web-based 接口，并加入口网站（ Portal ）的概念，提供所谓的流程入口网站接口（ Process Portal ）作为用户使用流程的沟通接口。如此除了可清楚地看到透过流程引擎指派而产生的的各项任务或工作事项 (work items) 外，并可结合其它入口网站与应用系统整合的机制，如使用协同工作功能促进员工彼此沟通与交流，像是公布栏、行事历或讨论区等。另外也可透过待办事项的启动 (trigger) 能够呼叫 (invoke) 与之相关的应用程序 (applications) 甚至根据各清楚定义的个别关卡 (activity) 自动以 web service 的方式来跨组织地呼叫 (invoke) 外部数据作交易 (transaction) 达到名副其实的 SOA 技术架构概念。

此外藉由流程网站接口用户 ( 通常指中阶以上主管或部门主管 ) 可利用行政管理工具 (Administrator Tools) 与报表工具 (Reporting Tool) 。就行政管理工具来说，进入流程数据储存库捞取流程定义的信息所作出的制式化报表可以清楚的知道员工的工作负荷量的轻重程度；而各种的统计量表包含热门排行、单位时间工作量统计、单位工作量统计、部门工作量统计、流程工作量统计、项目工作量统计提供管理者使用，使管理人员随时了解企业流程运作的各种情况。用户也能以 web service 的方式捞取应用数据作出动态分析。而流程的监控与管理 (Activity Monitor) ，亦可让用户或管理者透过 Web 的方式，实时地追踪目前流程的进度或进行例外的处理以能做到修正或变动的因应。也就是说活动的监控对流程范例的执行提供了一个绩效量测的准则。最后透过上述工具使流程作到实时的修正达到最佳化让工作更有效率。

java世界畅谈 2005-06-16 18:09 发表评论

工作流现状（jBPM作者）

java世界畅谈 — Thu, 16 Jun 2005 09:56:00 GMT

工作流现状（原文）

作者Tom Baeyens 翻译dinghong

前言

如果数据库系统（ database systems）像受人尊敬的智者讲述的条理清晰的故事，那么工作流（workflow）就像一群乳臭未干的小子在大谈各自的“哲理”。之所以这样讲，我是想指出，工作流系统（workflow management systems）还处于技术发展曲线（ technology hype curve）上的初级阶段。在这个领域我们将面临一个激动人心的阶段。为了描述这一点，可以将工作流和关系数据库系统（RDBMS）做一个对比。当在软件开发团队中谈论RDBMS时，大部分人会有一个清晰的概念，在你和他们交流的时候，人们会通过轻微的点头表示认可或理解你所说的。可当使用工作流术语讨论工作流时，他们会摇头表示不同意，因为每个人对工作流术语都有不同的理解。

Figure 1: Workflow vs. RDBMS positioned in the hype-curve

导致形成这种状况的原因之一，是在工作流中使用了过多的概念。在这个领域中的大量规范和工具没有一个是相似的。当然，它们相互之间有重叠并且会相互参考引证。
在介绍工作流时有一个话题必须包括，那就是工作流和业务流程管理（BPM）的关系。术语“工作流”通常描述人与计算机系统的一系列相关交互。在开发人员中，工作流经常被提及。有时，工作流的意思是指一些不同的UI界面。业务流程管理的范围比较广，相比之下工作流多半局限于技术领域。业务流程管理还从管理人员的角度涉及了非技术问题，比如分析、组织的效率。

在本文中，我首先解释什么是工作流管理系统，然后介绍业务流程管理的优点。接下来描述一下为什么工作流市场乍看起来如此混乱。本文给出的主要结论是：选择工作流系统是想用工作流系统的公司，将要面对的最困难的事情。为此，本文的核心部分描述了一个流程定义（process definition）的四个层次，为你选择工作流提供一个基础。本文还用中立的语言描述了工作流和BPM的通用概念。最后，给出了一些规范和工具的指导性描述。

什么是工作流管理系统（WFMS）

定义

工作流系统是以规格化的流程描述作为输入的软件组件,它维护流程的运行状态,并在人和应用之间分派活动。

为了后面的描述，我们先定义一些基本的术语：流程定义（process definition）和流程实例（process instance）. 一个流程定义是一个业务流程或过程的规格化描述。一个流程实例是流程定义的一个运行实体。都目前为止，概念还比较清晰是不是？但当再深入一步时，我们就要小心使用文字了。如何阐述流程中的步骤，现在还没有一个统一的方式。这是各种工作流规范和工具之间主要的分歧。

为什么应当禁止使用术语“活动（activity）”...
流程定义通常用一些活动表述。我认为这是导致工作流领域所有混乱的主要原因。我告诉你为什么：因为术语“活动”混淆了状态（state）和动作（action）之间的差异。在流程中，状态 (或者说等待状态)代表了一种对外部参与者（actor）的依赖。在流程运行时，这意味着流程引擎必须等待，直到外部参与者通知工作流管理系统指定的状态完成了。比如，等待可进一步运行的认可。动作是在流程运行过程中，工作流系统为响应指定事件（event）运行的一段程序逻辑（programming logic）。当流程运行过程中指定的事件发生时，工作流系统启动并执行这些动作。比如，当状态分配给一个参与者时，发一封Email。你也能看出，状态和动作是如此不同，因此使用同样的术语去描述这些概念是一个坏习惯。我的建议是避免使用术语“活动”，使用“状态”或者“动作”代替它。

工作流系统另一个重要的职责是维护每一个流程运行的上下文信息。流程上下文变量（process context variable），或简称变量，是与流程实例相关的变量。如，休假申请的开始日期、数据库中一条记录的键值、文档管理系统中一篇文档的索引等。通常在流程定义中声明这些变量，然后在流程实例生成时，这些流程变量被实例化。所有成熟的工作流管理系统都支持定制的变量类型。

目标领域（Target usage）

使用工作流管理系统的目的之一是作为企业应用系统集成（EAI）的平台。在当前大部分企业级IT架构中，各种各样的异构（heterogeneous）应用和数据库运行在企业内网中。在这些系统被应用到组织时，都有一个清晰的目标。例如，客户管理、文档管理、供应链、订单、支付、资源计划等等。让我们称这些系统为专门应用（ dedicated applications）。每一个专门应用都包含它们所支持业务流程的领域知识。这些专门应用中的自动化流程，被拼装到企业中更大的非自动化流程中。每当一个这样的专门应用安装并投入使用，都会带来涉及其他多个应用的新功能需求。企业应用系统集成（EAI）就是通过使用多个专门应用满足软件新需求的方法。有时，这只需要在两个应用之间提供数据通讯的通道。专门应用将很多业务流程硬编码在软件中。可以这么说，在你购买专门应用时，你是购买了一组固定的自动化业务流程。而工作流管理系统是不必事先知道问题域的相关信息的。工作流系统将业务流程描述作为输入并管理流程实例的执行，这使得它比专门应用更灵活（当然你也要花精力编写业务流程的规格化描述）。这就是为什么说工作流系统和专门系统是相互补充的。工作流系统可以用来管理全局的业务流程。如果专门应用支持你所需要的业务流程，那么使用专门应用。在此讨论的工作流系统的第一种使用方式就是：结合所有的专门应用，使用工作流系统构建一个EAI平台。

工作流系统能够发挥很大价值的第二个使用方式是：协助涉及多人相关任务工作流软件的开发。为了达到这个目的，大部分工作流系统都有一个方便的机制，来生成执行任务的表单。对于专注于ISO 或者CMM认证的组织，采用这种方式使用工作流系统能够显著提高生产率。不用将过程用文字的形式写在纸上，工作流系统使你通过流程定义建模实现过程的自动化（如使用基于Web的应用）。

工作流系统的第三种使用方式是：将工作流引擎嵌入到其他应用中。在前面我们谈到，专门应用将指定问题域相关的业务流程固化在软件中。开发专门应用的公司也可以将工作流引擎嵌入到他们的软件中。在这里，工作流引擎只是作为一个软件组件，对于应用的最终用户是不可见的。将工作流引擎嵌入到应用中的主要原因是为了重用（不重复发明轮子）和应用软件的可维护性。

The case for workflow

对于引入工作流的组织，能够在软件开发和业务两个层次受益。

方便开发

工作流管理系统能够简化企业级软件开发甚至维护。

降低开发风险 - 通过使用状态和动作这样的术语，业务分析师和开发人员使用同一种语言交谈。这样开发人员就不必将用户需求转化成软件设计了。
实现的集中统一 -业务流程经常变化，使用工作流系统的最大好处是：业务流程的实现代码，不再是散落在各种各样的系统中。
加快应用开发 - 你的软件不用再关注流程的参与者，开发起来更快，代码更容易维护。

业务流程管理 (BPM)

在自动化业务流程之前，分析并将它们规格化是一件艰苦但会有很好回报的工作。e-workflow.org对于分析流程能够带了的益处有不错的阐述：

提高效率 - 许多流程在自动化过程中会去除一些不必要的步骤
较好的流程控制 - 通过标准的工作方法和跟踪审计，提高了业务流程的管理
改进客户服务 - 因为流程的一致性，提高了对客户响应的可预见性
灵活 - 跨越流程的软件控制，使流程可以按照业务的需要重新设计。
业务流程改进 - 对流程的关注，使它们趋向于流畅和简单

我认为他们还遗漏了一个使用工作流系统最重要的因数：提高对迭代开发的支持。如果软件中业务流程部分不容易更改，组织就会花很大的精力在开发前的业务流程分析中，希望一次成功。但可悲的是，在任何软件项目开发中，这都很少能实现。工作流系统使得新业务流程很容易部署，业务流程相关的软件可以一种迭代的方式开发，因此使用工作流系统使开发更有效、风险更低。

缺失的一环（Missing link）

我确实认为工作流系统是企业应用开发中缺失的一环。将企业业务流程逻辑在企业级软件中实现的缺省方式是分散的。这意味着业务流程逻辑散布在各种系统中，如EJB、数据库触发器、消息代理等等。这样得到的软件难于维护，结果，企业只能将改变业务流程软件作为最后的选择。他们经常能够做的是，改变流程以适应软件。上述问题也适用于采用大型外部ERP软件包的企业。进一步，假设我们认识到这个问题，并打算将一个流程相关的代码都集中起来。对于一个流程来说这很不错，但当你要实现多个流程时，你会看到管理状态和流程变量的代码被到处复制。最后，我们会整理这些代码放到一个集中的库中。好，...这就是一个工作流管理系统了，不用费心自己来实现，你可以从本文后面的列表中选择一个。

A closer look

WFMS interfaces

一个工作流管理系统以流程定义作为输入。在这里，可以将流程定义看作UML活动图、UML状态图或者有限状态机。在提交一张费用单据、申请休假、要求一个报价、...之后，工作流系统负责维护这些流程定义的执行状态和上下文。为此，需要通知工作流系统状态的变化。运行流程的状态变化可以记录下来，以备监控管理。

Figure 2: Interfaces of a WFMS

定义 工作流系统的定义接口使流程开发人员能够部署流程定义。注意，这里的“流程开发人员”可以是业务分析师和软件开发人员的组合。

圈套（Pitfall）
许多工作流管理系统的开发商想使你相信，通过使用他们的图形化流程开发工具，只要业务分析师就可以生成流程定义。这种幻想源于“编程很难”这样的事实。开发商的销售人员喜欢说“看，你不用写一行代码”。不用写代码是好事，可大部分开发商在这点上走的太远，忽略了在某些场合提供一种将代码集成到流程定义中的机制是很适合的。在将工作流系统作为EAI平台时，必须在流程中集成代码。开发流程定义需要业务分析师和软件开发人员的合作。一个好的图形流程设计工具应该能够支持这种合作。

执行执行接口使用户和系统可以操作流程实例。流程实例是流程定义的执行。流程定义的控制流通过状态机描述。执行接口的两个主要方法是启动一个流程实例和通知工作流系统一个状态结束了。
应用应用接口代表了由工作流系统发起的工作流系统和外部系统之间的交互。当一个用户或系统操作一个流程实例的运行时，会生成一些事件（如一个迁移的执行）。流程定义中可以指定一段响应一个事件的可执行代码逻辑，这段代码和组织内外部的其他系统打交道。
监控管理人员通过监控接口获得流程运行的确切数据。有时，运行日志也可用于审计。

这些是WfMC参考模型（reference model of the WfMC）中定义的五个接口中的四个。

流程定义的四个层次

在下面这部分，我尝试回答这样的问题“什么是流程定义包括的内容？”。这是从各种规范和工具所使用模型的原则和概念中总结得来的，反映了大部分模型中通用的基本思想。流程定义的内容可以分为四个不同的层次：状态（state）、上下文（context）、程序逻辑（programming logic）和用户界面（UI）。

状态层

所有状态和控制流的表述，都属于业务流程的状态层。标准编程语言中的控制流来源于Von Neuman体系。控制流定义了必须被执行的指令的顺序，控制流由我们书写的命令、if语句、循环语句等确定。在业务流程中的控制流基本与此一致。但在业务流程中不是使用命令而是使用状态作为基本元素。

在流程中，状态 (或者说等待状态)代表了一种对外部参与者（actor）的依赖。状态的意思就像“现在X系统或某某人必须作某些事，在此等待直到参与者通知这些任务已完成”。状态定义了一种对外部提供结果的依赖。状态典型的例子是批准步骤（step）。

流程定义中的状态也指定了执行依赖于哪个参与者。在活动图中，泳道（swimlanes）的标注代表这些参与者的名字。工作流系统使用这些信息构建任务列表，这是一般工作流系统都有的功能。如前所述，参与者可以是人也可以是系统。对于需要人参与的状态，工作流系统必须在运行时计算出具体的个人。这样的计算使工作流系统必须依赖于组织结构信息。关于这方面的一篇非常有趣的文章是在further reading section提到的“工作流应用中的组织管理”（ 'Organizational Management in Workflow Applications'）。

流程定义的控制流包含一组状态和它们之间的关系。状态之间的逻辑关系描述了哪些执行路径可以同时执行，那些不可以。同步执行路径用分叉（forks）和联合（joins）建模，异步执行路径用判断（decisions）和合并（ merges）建模。注意在大多数模型中，在每个状态之前都有一个隐式合并。

UML活动图经常被用来做业务流程建模。作为一种直观和通用的表达，活动图在图形表述上有一个主要问题，就是没有区分状态和动作，它们都用活动来表示。缺少这种区分（导致状态概念的缺失）是学术派对UML活动图的主要批评。UML活动图的第二个问题是在UML2.0版中引入的。当多个迁移（transitions）到达一个活动时，以前的版本规定这是一个缺省合并（merge），在2.0版中规定这是一个需要同步的缺省联合（join）。在我看来，UML活动图的图形部分仍旧可以用来对业务流程状态层次建模，只要使用时对两条构建语义作如下的变化：

在用图形表述业务流程时，只建模状态层（状态和控制流），不要包括动作。这意味着图形中的矩形都是状态而不是活动
如果多个迁移到达一个状态，缺省定义为不需要同步的合并（merges）

在流程运行过程中，工作流系统用一个令牌（token）作为指针跟踪流程的状态。这相当于Von Neuman体系中的程序计数器。当令牌到达一个状态时，它被分配给工作流系统等待的外部参与者。外部参与者可以是个人、组织或者计算机系统。我们定义流程运行的执行人或系统为“参与者”（actor）。只有在工作流系统将令牌分配给一个参与者时，才需要访问组织结构信息。工作流系统通过分配令牌构建任务列表。

上下文层

流程上下文变量（process context variable），或简称变量，是与流程实例相关的变量。流程开发人员可以使用流程变量存储跨越流程实例整个生命周期的数据。一些工作流管理系统有固定数目的数据类型，另一些你可以定义自己的数据类型。

注意变量也可以用来存放引用（ references）。一个变量可以引用如数据库中的记录、网络上的文件。什么时候使用引用，取决于使用引用数据的其他应用。

和流程变量相关的另一个令人感兴趣的方面是：工作流系统如何将数据转化为信息。工作流是用于组织内部跨越各种异构系统实现任务和数据协同的。对于业务流程中人工执行的任务，工作流系统负责从其他相关系统，如SAP、数据库、CRM系统、文档管理系统收集数据。在业务流程的每一个人工步骤，只有相关联的数据项被从异构系统中收集和计算。通过这种方式，从不同系统来的数据被转换并展现为信息。

程序逻辑层

如前所述，动作是在流程运行过程中，工作流系统响应指定的事件（event）执行的一段程序逻辑（programming logic）。程序逻辑可以是二进制或源代码形式的、用任何语言或脚本编写的软件。程序逻辑层是所有这些软件片断和关于在什么事件发生时调用它们的信息的组合。程序逻辑的例子包括发Email、通过消息代理发消息、从ERP系统中拿数据和更新数据库。

用户界面层

一个参与者通过向流程变量中填充数据的事件，来触发结束一个状态。比如，在请假的例子中，老板提供“同意”或“不同意”数据到流程中。某些工作流系统允许指定哪些数据可以填充到流程中，以及它们如何在流程变量中存储。通过这些信息，可以生成从用户收集信息的UI表单。基于流程定义生成用户提交表单的Web应用例子，可以访问the jBpm online demo。

工作流全景

可执行流程与工作流管理系统的比较（Executional processes versus a WFMS）

当前在BPM领域中，关于可执行业务流程的规范有趋向于统一集中的趋势。 XLANG, WSFL 和BPML合并为基于交互（消息交换）的BPEL。BPEL在面向服务体系结构(SOA)的大背景下定义。它的前提条件之一是涉及的服务必须用WSDL声明。BPEL规定了一套XML语法，这套语法可以看作一种编程语言，用来描述包括对WSDL定义的服务调用的控制流。

在可执行业务流程和基于状态的工作流管理系统所使用的方法中，我注意到了三点主要的区别：

基于状态与面向消息：基于状态的工作流系统以状态（或者活动）概念为中心。工作流引擎维护状态并计算从一个状态到另一个状态的迁移。另一方面，像BPEL这样的可执行流程以对输入消息响应的定义为中心。一组这些响应外加其他信息（other bells and whistles）可以看作一个业务流程。这也解释了为什么BPEL可以看作是对基于状态的工作流系统的某些方面的补充。一个响应输入消息的BPEL onMessage事件处理器，可以在工作流状态之间的迁移中执行。
流程实例ID与消息相关处理：可执行业务流程的复杂性之一来自消息相关性的处理。流程描述的一部分必须说明BPEL引擎如何从输入消息中确定具体流程的标识。这必须基于输入消息的一个数据项。而工作流系统在每个流程实例生成同时生成了实例ID，客户端在后续调用引擎API时使用这个ID。
工作流引擎API与抽象服务端点（endpoint）：工作流系统提供一组集中的API，客户端通过调用API完成与所有流程实例的交互。在可执行业务流程中，每个流程表现为一个服务。这意味着对于每个流程定义都有一个不同的访问点。

学术界

学术界对工作流的研究可以回溯到上个世纪七十年代。在当前，研究领域趋向于认为petr 网是所有流程定义语言之母。关于petri网已有大量先进的分析技术，去年在 2003 conference on Business Process Management上我有幸会晤了Petri教授。对于大部分人能够访问和理解的有关Petyri网最好的研究之一是工作流模式(workflow patterns)。工作流模式比较了大量的工作流管理系统并以petri网的术语表述了通用流程建模概念。

开放源代码项目

最后我们看看真实世界中的工作流管理系统。选择一个工作流管理系统是一件困难的事情，但有选择总比没有选择好。:-) 本文阐述工作流基本概念的目的之一，就是使你能够作更好的选择。但我也意识到，对于现在的软件架构师来说，选择工作流系统是一件最具挑战性的工作。

下面的列表来源于三个地方：my previous article, the list of Carlos E Perez, 和 list by Topicus.

jBpm - jBpm是本文作者编写的一个灵活可扩展的工作流管理系统。作为jBpm运行时server输入的业务流程使用简单强大的语言表达并打包在流程档案中。jBmp将工作流应用开发的便利性和杰出的企业应用集成（EAI）能力结合了起来。jBmp包括一个Web应用程序和一个日程安排程序。jBmp是一组J2SE组件，可以作为J2EE应用集群部署。
OpenEbXML - OpenebXML项目致力于提供一个ebXML框架，主要支持不久将由 UN/CEFACT和OASIS发布的ebXML规范2.0版。
Werkflow - Werkflow是一个灵活可扩展的基于流程和状态的工作流引擎。它的目标是满足可以想象的所有工作流程，从企业级的业务流程到小范围的用户交互流程。通过使用可插拔和分层结构，可以方便地容纳各种工作流语义。
OSWorkflow - OSWorkflow最独到之处是绝对的灵活。
wfmOpen - WfMOpen是WfMC和OMG中所谓工作流设施（workflow facility） (工作流引擎)的J2EE实现。工作流通过扩展的XPDL描述。
OFBiz - OFBiz工作流引擎基于WfMC和OMG的规范，使用XPDL作为流程定义语言。
ObjectWeb Bonita - Bonita是一个符合WfMC规范、灵活的协同工作流系统。对于各种动作如流程概念建模、定义、实例化、流程控制和用户交互等提供了全面的集成图形工具。 100% 基于浏览器、使用SOAP和XML数据绑定技术的Web Services封装了已有的工作流业务方法并将它们以基于J2EE的Web Service形式发布。基于活动预测模型的第三代工作流引擎。
Bigbross Bossa -速度非常快、轻量级的引擎，使用富有表达能力的Petri网定义工作流，不要求关系数据库，使用简单，能和Java应用集成。事实上，它是按嵌入式设计的。
XFlow - XFlow运行于EJB和servlet容器中。
Taverna - Taverna项目的目标是提供一种语言和软件工具，方便在eScience中使用工作流和分布计算技术。
Enhydra Shark - Shark完全基于WfMC和OMG标准，使用 XPDL作为工作流定义语言。流程和活动的存储使用Enhydra DODS。
PowerFolder - PowerFolder包括开发人员使用的studio，管理环境和一个运行时引擎。
Breeze - Breeze一个轻量级、跨平台、基于组件的工作流引擎原型。
Open Business Engine - Open Business Engine是一个开放源码的Java工作流引擎，支持WfMC规范，包括接口1（XPDL）、接口2/3（WAPI）和接口5。OBE为活动的运行提供了一个可控的集中环境。OBE主要基于J2EE实现。
OpenWFE - OpenWFE是一个开放源码的Java工作流引擎。它包括可升级的三个组件：引擎、工作列表和Web界面。它的流程定义语言虽然使用XML格式，其灵感来源于 Scheme，一种Lisp方言。
Freefluo - Freefluo是一个使用Web Service的工作流协同工具，可以处理WSDL的Web Service调用。支持两种XML格式的工作流语言：IBM的WSFL和XScufl。Freefluo非常灵活，它的核心是不与任何工作流语言或执行架构关联的可重用协同框架。 Freefluo包括可执行使用WSFL一个子集描述的工作流的运行库。
ZBuilder - ZBuilder3是第二代工作流开发管理系统，也是一个开放源码产品。它为不同的工作流引擎和工作流定义了一组标准的JMX管理接口。
Twister - Twister的目标是提供新一代、易集成、应用Java领域中最新成果、面向B2B的工作流解决方案。流程引擎基于BPEL业务流程规范和Web Service标准。
Con:cern - con:cern工作流引擎基于扩展的案例（case）处理方法，流程由一组具有前后条件的活动组成。

商业软件提供商

工具目录

规范

Michael zur Muehlen作了一个所有工作流相关规范的介绍性的幻灯片，很不错。

我同意John Pyke 和 Wil van der Aalst 的观点：工作流标准还处于制定阶段。现在存在大量相互丛叠的规范。

在我看来，导致规范如此之多而同时每个规范的应用又很有限的原因是，在工作流最基础概念上大家达成的共识很少。工作流是最容易让你感到心烦的话题，因为工作流本身的概念会和其他相关概念和技术混淆在一起。可以举一个具体的例子，比如说工作流完全是对Web Service的补充。你可以通过暴露接口以Web Service的方式访问一个工作流管理系统，但是不能假定总是必须通过Web Service接口访问工作流系统接口。一些规范造成了这样的假设。除了Web Service，其他容易混淆的概念和技术包括：Email、流程之间的通讯、Web应用和组织结构。

在工作流领域第一个致力于标准化工作的是Workflow Management Coalition (WfMC)，开始于 1993。 WfMC发布的参考模型很不错，它定义了工作流管理系统和其他相关部分之间的接口。WfMC的另一项成果是XPDL规范。 XPDL定义了描述工作流声明部分（declarative part）的XML结构。我个人认为，参考模型和XPDL是目前最好的规范。

JSR 207: Java的流程定义 -是由Java Community Process (JCP) 发起，如何在J2EE应用服务器中实现业务流程自动化的标准。其基本模型是定义一个特殊类型的ejb session bean，作为一个业务流程的接口。JSR207标准化一组XML元标记（meta tags）作为JSR175元数据的一部分。JSR207 将session bean和元数据作为ejb容器的输入，然后生成绑定方法的代码，这些方法在元数据中描述。此规范还处于初级阶段，没有发布任何内容。专家小组成立于 March 2003.
WfMC's XPDL - WfMC是由约300家成员参加的组织，基于参考模型定义了一系列的标准。参考模型用用例（use case）的形式描述了工作流系统和其他相关部分之间的关系。XPDL是WfMC制定的描述业务流程控制流（control flow ）的XML格式规范。
ebXML's BPSS - ebXML是协同流程的相关标准集，主要关注不同公司流程之间的通讯。可以看作EDI的继承者。 ebXML是由OASIS和UN/CEFACT联合发起。 BPSS 是ebXML的规范，其中的概念和本文阐述的很接近。
BPMI's BPML & WSCI - (Intalio, Sun, SAP, ...)BPMI 也定义了一个规范 (BPMN) ，描述如何将“可执行”业务流程可视化的表现。
BPEL - (Microsoft, BEA, IBM, SAP & Siebel) BPEL由一系列基于消息交换的规范（ XLANG, WSFL, BPML）产生。还有一个将此规范引入到Java的提案: BPELJ。此规范描述如何处理输入的消息，而不是对流程状态进行建模。就像本文提到的，它不是一个关于业务流程规格化定义的规范。简单的说，可以将它看作XML形式的编程语言，提供将WSDL-Services组合成控制流的能力。顾名思义，此规范重点在（也不只限于）Web Service。
OMG's Workflow management facility - 基于WfMC规范，定义如何向CORBA转换。
UML - UML定义了建模和设计软件系统的9类图。每类图包括可视化的表示和语义。其中活动图的目的就是要可视化的表现业务流程。注意到在一个流程定义包含四个层次的内容，我想指出的是：一个流程定义包含的内容远远多于它的可视化部分。UML只涉及了可视化部分。
RosettaNet - RosettaNet主要定义了一组 Partner Interface Processes (PIP). 一个 PIP 描述了一个有两个交易参与者、包括消息格式的流程。
UBL - The Universal Business Language (UBL)定义了用于不同组织间通讯的XML文档标准库。可以看作是对ebXML的补充，因为ebXML只定义了建立组织间流程的基础。此规范的竞争对手是 RosettaNet标准中的一个子集。

结论

我在本文中指出工作流市场还属于年轻而又混乱（young and wild）的阶段，但已经有可靠的工具存在了:

到目前，像J2EE和.NET这样成熟的集成平台才可用。在这样一个平台上运行工作流管理系统才能真正发挥工作流系统的附加价值。这也是为什么只有在今天，工作流系统才被重新发现。
在 'The case for workflow'一节，我们介绍了引入工作流管理系统，是如何同时在技术和业务上带来投资回报的。
工作流在技术发展曲线的位置表明，BPM和工作流中使用的概念还需要明确。
“开放源代码项目”和“商业软件提供商”列表中的工具，可以让你获得工作流和业务流程管理的益处。

从以上所有这些中能得到的结论是：

规范还没有成熟，没有标准被大范围采用
对于现在想应用BPM的公司来讲，比较工作流系统是一个极其困难的挑战
尽管标准化工作慢了一拍，可好的工作流管理系统还是有的。这对于已经在挑选工作流系统的组织来说是一个好消息。

我希望本文能够激发你对工作流的兴趣并且能够为你进行有效的对比提供正确的背景知识。

jBPM的scheduler、timer、版本等

java世界畅谈 — Thu, 16 Jun 2005 06:12:00 GMT

10. Scheduler(日程安排程序)
This chapter describes how to work with timers in jBPM.

Upon events in the process, timers can be created. When a timer expires(终止), an action can be executed or a transition can be taken.

10.1. Timers
The easiest way to specify a timer is by adding a timer element to the node.

         duedate='3 business hours'
         repeat='10 business minutes'
         transition='time-out-transition' >

A timer that is specified on a node, is not executed after the node is left. Both the transition and the action are optional. When a timer timer is executed, the following events occur in sequence :

an event is fired of type timer
if an action is specified, the action is executed.
if a transition is specified, a signal will be sent to resume execution over the given transition.
Every timer must have a unique name. If no name is specified in the timer element, the name of the node is taken as the name of the timer.

The timer action can be any supported action element like e.g. action or script.

Timers are created and cancelled by actions. The 2 action-elements are create-timer and cancel-timer. Actually, the timer element shown above is just a short notation(符号) for a create-timer action on node-enter and a cancel-timer action on node-leave.

2 action-elements :
create-time node-enter
cancel-time node-leave

Scheduler deployment
Process executions create and cancel timers. The timers are stored in a timer store. A separate timer runner must check the timer store and execute the timers when they are due.

10.2. Scheduler deployment
Process executions create and cancel timers. The timers are stored in a timer store. A separate timer runner must check the timer store and execute the timers when they are due.

三个Actor:
process executions(流程执行):
    a. scheduler timer (日期安排计时器)
    b. cancel timer    (取消计时器)
timer store(计时器储存) --->cancel timer--->scheduler timer
timer runner(计时器运行者) --->execute timers that are due


Scheduler Service
timer runner

The following class diagram shows the classes that are involved in the scheduler deployment. The interfaces SchedulerService and TimerExecutor are specified to make the timer execution mechanism pluggable.

process execution(actor) ---> SchedulerInstance ---> SchedulerService (接口)<----SchedulerServiceImpl(接口实现)
                                                                       --->JBPM_TIMER database
                             /SchedulerMain                                          |||
Runnable(接口)----TimerRunner(实现接口)--------->TimerExecutor（接口）<---------TimerExecutorImpl(接口实现)
                             \SchedulerServlet

----------------------------------------------------------
11. Business calendar (商业日历)
This chapter describes the business calendar of jBPM. The business calendar knows about business hours and is used in calculation(计划) of due（预期的） dates for tasks and timers<任务和计时器>.

The business calendar is able to calculate(计划) a date by adding a duration(持续时间) and a date.

11.1. Duration(持续时间)
A duration is specified in absolute or in business hours. Let's look at the syntax:

[business]

Where is a piece of text that is parsable with Double.parseDouble(quantity). is one of {second, seconds, minute, minutes, hour, hours, day, days, week, weeks, month, months, year, years}. And adding the optional indication business means that only business hours should be taken into account for this duration. Without the indication business, the duration will be interpreted as an absolute time period.

[business]
<数量>[商业]<单元>

这里是一段文字，用来解析使用Double.parseDouble(quantity). <单元>是{秒、分等等}中的一种。并且增加可选的指示商业意味着仅仅商业时间被考虑为这一段时间。没有这个指示商业，持续时间将被解释为一个完全的时间区域。

11.2. Configuration(配置)
The file org/jbpm/calendar/jbpm.business.calendar.properties specifies what business hours are. The configuration file can be customized and a modified copy can be placed in the root of the classpath.

This is the example business hour specification that is shipped by default in jbpm.business.calendar.properties:

hour.format=HH:mm
#weekday ::= [ [& ]*]
#daypart ::= -
#start-hour and to-hour must be in the hour.format
#dayparts have to be ordered
weekday.monday= 9:00-12:00 & 12:30-17:00
weekday.thuesday= 9:00-12:00 & 12:30-17:00
weekday.wednesday= 9:00-12:00 & 12:30-17:00
weekday.thursday= 9:00-12:00 & 12:30-17:00
weekday.friday= 9:00-12:00 & 12:30-17:00
weekday.saturday=
weekday.sunday=

day.format=dd/MM/yyyy
# holiday syntax:
# holiday period syntax: -
# below are the belgian official holidays
holiday.1= 01/01/2005 # nieuwjaar
holiday.2= 27/3/2005 # pasen
holiday.3= 28/3/2005 # paasmaandag
holiday.4= 1/5/2005 # feest van de arbeid
holiday.5= 5/5/2005 # hemelvaart
holiday.6= 15/5/2005 # pinksteren
holiday.7= 16/5/2005 # pinkstermaandag
holiday.8= 21/7/2005 # my birthday
holiday.9= 15/8/2005 # moederkesdag
holiday.10= 1/11/2005 # allerheiligen
holiday.11= 11/11/2005 # wapenstilstand
holiday.12= 25/12/2005 # kerstmis

business.day.expressed.in.hours= 8
business.week.expressed.in.hours= 40
business.month.expressed.in.business.days= 21
business.year.expressed.in.business.days= 220

----------------------------------------------------
13. jBPM Process Definition Language (JPDL) (jBPM流程定义语言)
JPDL specifies an xml schema and the mechanism to package all the process definition related files into a process archive(存档).

13.1. The process archive
A process archive is a zip file. The central file in the process archive is processdefinition.xml. The main information in that file is the process graph. The processdefinition.xml also contains information about actions and tasks. A process archive can also contain other process related files such as classes, ui-forms for tasks, ...

13.1.1. Deploying a process archive
Deploying process archives can be done in 3 ways: with the process designer tool, with an ant task or programatically.
三种部署方式：
a.流程设计工具
b.ant任务处理
c.程序

Deploying a process archive with the designer tool is still under construction.

Deploying a process archive with an ant task can be done as follows:

To deploy more process archives at once, use the nested fileset elements. The file attribute itself is optional. Other attributes of the ant task are:

cfg:
   cfg is optional, the default value is 'hibernate.cfg.xml'. The hibernate configuration file that contains the jdbc connection properties to the database and the mapping files.
properties:
   properties is optional and overwrites *all* hibernate properties as found in the hibernate.cfg.xml
createschema:
   if set to true, the jbpm database schema is created before the processes get deployed.
Process archives can also be deployed programmatically with the class org.jbpm.jpdl.par.ProcessArchiveDeployer

13.1.2. Process versioning
Process definitions should never change because it is extremely difficult (if not, impossible) to predict(预知) all possible side effects of process definition changes.

To get around this problem, jBPM has a sophicticated process versioning mechanism. The versioning mechanism allows multiple process definitions of the same name to coexist(共存) in the database. A process instance can be started in the latest version available at that time and it will keep on executing in that same process definition for its complete lifetime. When a newer version is deployed, newly created instances will be started in the newest version, while older process instances keep on executing in the older process defintions.

Process definitions are a combination of a declaratively specified process graph and optionally, a set of related java classes. The java classes can be made available to the jBPM runtime environment in 2 ways : by making sure these classes are visible to the jBPM classloader. This usually means that you can put your delegation classes in a .jar file next to the jbpm-[version].jar. The java classes can also be included in the process archive. When you include your delegation classes in the process archive (and they are not visible to the jbpm classloader), jBPM will also apply versioning on these classes. More information about process classloading can be found in Section 13.2, “Delegation”

When a process archive gets deployed, it creates a process definition in the jBPM database. Process definitions can be versioned on the basis of the process definition name. When a named process archive gets deployed, the deployer will assign a version number. To assign this number, the deployer will look up the highest version number for process definitions with the same name and adds 1. Unnamed process definitions will always have version number -1.

java世界畅谈 2005-06-16 14:12 发表评论

jBPM的Graph

java世界畅谈 — Fri, 10 Jun 2005 07:07:00 GMT

Graph(图表)
1. Overview
A process definition represents a formal specification of a business process and is based on a directed graph. The graph is composed of (be composed of 由...组成) nodes and transitions. Every node in the graph is of a specific(明确的) type. The type of the node defines the runtime behaviour.(这个类型定义了运行时间行为。) A process definition has exactly(正确地) one start state.

A token is one path of execution.(token是一个执行路径) A token is the runtime concept that maintains(维护) a pointer to a node in the graph.

A process instance is one execution of a process definition. When a process instance is created, a token is created for the main path of execution. This token is called the root token of the process instance and it is positioned in the start state of the process definition.

A signal(信号) instructs(通知) a token to continue graph execution. When receiving an unnamed signal, the token will leave its current node over the default leaving transition. When a transition-name is specified in the signal, the token will leave its node over the specified transition. A signal given to the process instance is delegated to the root token.

After the token has entered a node, the node is executed. Nodes themselves are responsible for the continuation of the graph execution. Continuation of graph execution is done by making the token leave the node. Each node type can implement a different behaviour for the continuation of the graph execution. A node that does not propagate execution will behave as a state.

Actions are pieces of java code that are executed upon events in the process execution. The graph is an important instrument(工具) in the communication about software requirements. But the graph is just one view (projection) of the software being produced. It hides many technical details. Actions are a mechanism to add technical details outside of the graphical representation. Once the graph is put in place(在适当的位置), it can be decorated(装饰) with actions. The main event types are entering a node, leaving a node and taking a transition.

流程定义(process definition)
转变(transition)
节点(node) 节点-->>类型-->>运行时间行为
记号(token) 执行路径 --->节点
流程实例(process instance) 一个流程定义的一个执行
信号(signal) 通知流程继续进行
行为(action) 在流程执行事件之上的java运行代码

2.Process graph
The basis of a process definition is a graph that is made up of nodes and transitions. That information is expressed in an xml file called processdefinition.xml. Each node has a type like e.g. state, decision, fork, join,... Each node has a set of leaving transitions. A name can be given to the transitions that leave a node in order to make them distinct. For example: The following diagram shows a process graph of the jBAY auction process.

Below is the process graph of the jBAY auction process represented as xml:

    auction(拍卖)

状态有两种转变一种是转向salefork 一种是转向end



分支
    运送
    开出帐单

3. Actions
Actions are pieces of java code that are executed upon events in the process execution. The graph is an important instrument in the communication about software requirements. But the graph is just one view (projection) of the software being produced. It hides many technical details. Actions are a mechanism to add technical details outside of the graphical representation.[行为是一种在图形表现之外加入技术细节的机制 ] Once the graph is put in place, it can be decorated with actions. This means that java code can be associated with the graph without changing the structure of the graph. The main event types are entering a node, leaving a node and taking a transition.

Let's look at an example. Suppose we want to do a database update on a given transition. The database update is technically vital(重大的) but it is not important to the business analyst.

A database update action

public class RemoveEmployeeUpdate implements ActionHandler {
public void execute(ExecutionContext ctx) throws Exception {
    // get the fired employee from the process variables.
    String firedEmployee = (String) ctx.getContextInstance().getVariable("fired employee");

    // by taking the same database connection as used for the jbpm updates, we
    // reuse the jbpm transaction for our database update.
    Connection connection = ctx.getProcessInstance().getJbpmSession().getSession().getConnection();
    Statement statement = connection.createStatement("DELETE FROM EMPLOYEE WHERE ...");
    statement.execute();
    statement.close();
}
}

...





...

Actions can be given a name. Named actions can be referenced from other locations where actions can be specified. Named actions can also be put as child elements in the process definition.

This feature is interesting if you want to limit duplication(复制) of action configurations (e.g. when the action has complicated{复杂的难解的} configurations). Another use case is execution or scheduling of runtime actions.

Events
Events specify moments() in the execution of the process[事件指定了在流程执行中的片刻]. The jBPM engine will fire events during graph execution[jBPM引擎在图表执行时候将激活事件]. This occurs when jbpm calculats the next state (read: processing a signal)[这个集中在当jbpm打算下一个状态(读：传递一个信号)]. An event is always relative to an element in the process definition like e.g. the process definition, a node or a transition[一个事件总是与流程定义中一个元素相关的,例如流程定义、节点或者转变]. Most process elements can fire different types of events[大部分流程元素蚕激活不同类型的事件]. A node for example can fire a node-enter event and a node-leave event. Events are the hooks for actions[事件是行为的挂钩]. Each event has a list of actions[每一个事件有一个行为的列表]. When the jBPM engine fires an event, the list of actions is executed[当jBpm 引擎激活一个事件，行为列表被执行].

Event propagation 时间传播
Superstates create a parent-child relation in the elements of a process definition. Nodes and transitions contained in a superstate have that superstate as a parent. Top level elements have the process definition as a parent. The process definition does not have a parent. When an event is fired, the event will be propagated up the parent hierarchy. This allows e.g. to capture all transition events in a process and associate(交往) actions with these events in a centralized(集中的) location.

Script （脚本）
A script is an action that executes a beanshell script[脚本是执行beanshell脚本的一个行为]. For more information about beanshell, see the beanshell website. By default, all process variables are available in the script[默认的，所有过程变量在脚本中都是可用的]. After the script is executed, variable values of the script interpreter(解释器) can be stored (or created) in the process variables[在脚本执行之后，脚本解释器的变量值可以被存储（创建）在过程变量中]. For example:

//过程结束事件类型

...

The previous script will load all process variables in the interpreter. Then the expression is evaluated(求...的值), which requires that process variables b and c were present in the process variables when the script was executed. The out element specifies that the value of the scripting variable a has to be collected from the interpreter after the evaluation has completed and stored in the process variables (as variable a). When loading all the process variables into the interpreter or when there are variables that are not valid scripting variable names, you can specify the in variables analogue(类似情况) to the out variables.

Custom events[定制事件]
Note that it's possible to fire your own custom events at will during the execution of a process[注意在进程的执行中激活你的定制的事件是有可能的]. Events are uniquely(独特地) defined by the combination(联合) of a graph element (nodes, transitions, process definitions and superstates are graph elements). In actions, in your own custom node implementations, or even outside the execution of a process instance, you can call the GraphElement.fireEvent(String eventType, ExecutionContext executionContext);. The names of the event types can be chosen freely.

GraphElement.fireEvent(String eventType,ExecutionContext executionContext)

Superstates(超状态)
A Superstate is a group of nodes[超状态是一组节点]. Superstates can be nested recursively[超状态可以被递归嵌套]. Superstates can be used to bring some hierarchy in the process definition[超状态可以在进行定义中被用来产生层次]. For example, one application could be to group all the nodes of a process in phases(阶段). Actions can be associated with superstate events. A consequence(结果) is that a token can be in multiple nested nodes at a given time. This can be convenient to check wether a process execution is e.g. in the start-up phase. In the jBPM model, you are free to group any set of nodes in a superstate.

7.4.1. Superstate transitions
All transitions leaving a superstate can be taken by tokens in nodes contained within the super state. Transitions can also arrive in superstates. In that case, the token will be redirected to the first node in the superstate. Nodes from outside the superstate can have transitions directly to nodes inside the superstate. Also, the other way round, nodes within superstates can have transitions to nodes outside the superstate or to the superstate itself. Superstates also can have self references.

7.4.2. Superstate events
There are 2 events unique to superstates: superstate-enter and superstate-leave. These events will be fired no matter over which transitions the node is entered or left respectively. As long as a token takes transitions within the superstate, these events are not fired.

Note that we have created separate event types for states and superstates. This is to make it easy to distinct between superstate events and node events that are propagated from within the superstate.

Exception handling
The exception handling mechanism of jBPM only applies to java exceptions. Graph execution on itself cannot result in problems. It is only the execution of delegation(代理) classes that can lead to exceptions.

On process-definitions, nodes and transitions, a list of exception-handlers can be specified. Each exception-handler has a list of actions(每一个异常处理一批行为). When an exception occurs in a delegation class, the process element parent hierarchy is serached for an appropriate exception-handler. When it is found, the actions of the exception-handler are executed.

Note that the exception handling mechanism of jBPM is not completely similar to the java exception handling. In java, a caught exception can have an influence(改变) on the control flow. In the case of jBPM, control flow cannot be changed by the jBPM exception handling mechanism. The exception is either caught or uncaught. Uncaught exceptions are thrown to the client (e.g. the client that called the token.signal()) or the exception is caught by a jBPM exception-handler. For caught exceptions, the graph execution continues as if no exception has occurred.

Note that in an action that handles an exception, it is possible to put the token in an arbitrary node in the graph with Token.setNode(Node node).

7.6. Process composition
Process composition is supported in jBPM by means of the process-state. The process state is a state that is associated with another process definition. When graph execution arrives in the process state, a new process instance of the sub-process is created and it is associated with the path of execution that arrived in the process state. The path of execution of the super process will wait till the sub process instance has ended. When the sub process instance ends, the path of execution of the super process will leave the process state and continue graph execution in the super process.

When a subprocess is started, start-variables allow feeding of data from the super process into the sub process. Two variable names can be specified for each start-variable : the super process variable name and the sub process variable name. When the sub process is created, the value of the super process variable is copied in the sub process variable. The reverse is done with end-variable's. End variables allow collection of the results of the sub process into the super process.

java世界畅谈 2005-06-10 15:07 发表评论

在JBpm中提到的面向图形编程(GOP)的片段摘录翻译

java世界畅谈 — Tue, 07 Jun 2005 07:25:00 GMT

Graph Oriented Programming(面向图形编程)
Workflow is mostly related to the management of tasks for people. The core focus of a workflow process specifies tasks performed by humans are related to achieve a certain process goal.

工作流主要是与人们任务的管理相关。一个工作流过程限定被人任务执行的核心焦点是与完成一个确定的流程目标。

Suspending an execution in java is not possible. Actually, it is possible to suspend and resume a thread in java (with e.g. Object.wait() and Object.notify()). But this does not match the needs for the process wait states because of persistence. Workflow, BPM and orchestration solutions need to persist(持久层) their execution during wait states. In fact, state changes in a process should correspond to transactions on a server. Inbetween those transactions the suspended（暂停的） execution should be persistable in e.g. a database or on the file system.

Actually, it is not so surprising that java does not have a built-in(内置的) mechansim for suspending and persisting executions. That is because java is built on top of the Von Neumann architecture. This essentially(本质上) comes down to an environment for executing a sequence(序列) of instructions(指令). This article presents a technique for extending the Von Neumann architecture for supporting the suspension and persistence of executions.

Products in the three fields(领域) have all solved this problem in their own way, from their own perspective(观点). As a consequence(推理), each solution combined a technique for suspending an execution with a whole lot of other functionalities. This is the fundamental reason why these topics are perceived(察觉、感知到) as confusing(混淆的) and unclear(不清楚的) by the development community.

图形表现和开发流程
The technical ability to suspend an execution creates a very interesting opportunity(机会、时机) : a direct link between the business process and the technical implementation（商业流程和技术实现）. The business process is a central part of the requirements specified by the business analyst. Without a mechansim for suspending executions, the implementation of the business process requires a complex translation into a software design. In that case(如果是那样的话), the developer will have to store the executional state(执行状态) in some form in the database during wait states. This complexity(复杂性) is added and combined(被结合) with the functional requirements of the business process(商业流程的功能需求).

The conclusion(结论) is that it would be great if we could find a solution for suspending an execution that is related to the graphical representation of a business process. Many (probably all) of the graphical representations of business processes are based upon a directed graph. Some of the process languages are limited to a tree which is a subset of a directed graph. Those languages are called block structured languages(块结构语言).

An important consideration is that the proposed(建议) solution should embrace(包含) iterative(迭代的) development. With UML class diagrams, this is an established（确定的） practice. The analyst(分析家) can draw an analysis model in an UML class diagram. Then the developer takes this model as a starting point and transforms it into a design model. Adding more technical details will result(以...为) in an implementation. Too many proposed solutions ended up in being visual programming environments.

What is Graph Oriented Programming？（什么是面向图形编程？）
Graph oriented programming is a technique for solving problem of suspending and persisting an execution. Because of its limited scope, this technique, is easy to understand and serves as the building block for other functionalities targeted by workflow, BPM and orchestration solutions.

面向图表编程是为解决暂停或持久化执行的问题的一种技术。因为它限定的范围，这种技术，是容易理解并且服务于为其他功能性目标、BPM和orchestration解决方案建造模块。

The central idea of Graph Oriented Programming is that a we complement plain imperative（命令） programming with a runtime model for executing graphs. So a graph is specified as part of the software and at runtime, executions of the graph are coupled to the execution of the imperative programmed software.
面向图表编程的主要概念是，我们使用运行模式为执行图表完成清晰的命令程序。所以一个图表是被限定为软件的一部分，并且图表的执行是连接到命令程序软件的执行。

A process graph is made up of Nodes and Transitions. Transitions have a direction and connect two nodes in the graph.
一个流程图表是由节点和转变(transitions)组成的.转变有一个方向并且连接图表中的两个节点。

The graph can be seen as a state machine. Although, the executional model that we will explain here is concrete and has better support for concurrent paths of execution.
这个图表可以看做是一个状态机器。虽然我们这里解释的执行模式是具体的且更好的为并发路径执行提供更好的支持。

The following UML class diagram sketches（大略） how the process elements can be modelled in an UML class diagram. This also shows that a process graph can be represented(表现) as data. The process graph data can be expressed in different formats : XML, java objects, records in a database,...

The next part is the most difficult part to understand for programmers and technical people. That is because we are specifying an executional model that differs from the well known Von Neumann architecture.

We define a Token as a path of execution. It's a path of execution within one system.
我们定义了一个令牌作为执行路径。它是一个系统中的一个执行路径。

Note that an execution of a process can involve multiple concurrent paths of execution. We now define an execution of a process as a tree of tokens. A token has a pointer to a node in the process graph.
注意：一个流程的执行可以包括多个并发的执行路径。我们现在定义一个流程的执行作为一个令牌树。一个令牌做为流程图表中的一个节点的一个指针。

The following UML class diagram shows the tree of tokens modelled as a UML class diagram（UML 类图）. This is included to show that an execution of a process can be represented as data. This is actually the crucial(至关重要的) part of making an execution persistable.

Now, we'll explain how the execution of java can be coupled to the execution of the graph. The next image shows the methods in Node and Transition that are involved in graph execution. To calculate the next state of an execution, we propose(计划) a modified version of the chain of responsibility pattern(责任链模式) as described by the GOF 'Design Patterns' book.

The Nodes in the graph can represent wait states. During a wait state, a Token points to that Node. Each Token that is in a Node can receive a signal. A Signal can be send to a Token to resume execution after a wait state is finished. This will cause the graph execution to start.

在图表中的节点可以表现为等待状态。在一个等待状态，一个令牌指向那个节点。在节点中每一个令牌可以接受一个信号。一个信号可以在等待状态完成后，可以发送一个令牌来重新执行。这将导致图表执行开始。

A Signal is the trigger that resumes graph execution. 信号是再继续图表执行的触发器。

The effect（结果） of this signal is that the Token will leave the node. In case(万一) the node has more then one leaving transition, the leaving transition has to be specified as part of the signal. Transitions just take a Token to the destination(目的) Node. When a token arrives in a Node, the Node is executed. Each node in the graph is of a specific type that determines(确定) its runtime behaviour. Each node type corresponds to a subclass of Node and the behaviour is implemented in the execute-method.

The node's execute-method has 2 responsibilities.[节点的执行方法有两个责任] First, it can perform some business logic, related to the type of the node. [首先，它可以运行一些商业逻辑，关系到节点的类型]E.g. sending a message, updating a database, creating a task for a user,...[例如发送消息，更新数据库，为用户创建一个任务,......] And the second responsibility of the node's execute-method is the propagation of the graph execution.[节点执行方法的第二个责任是传递图表的执行] If the node does not propagate the execution, it behaves as a wait state.[如果这个节点没有传递执行，它将作为一个等待状态。] It can propagate the token that arrived in the node down(沿着) one of the leaving transitions. Or it can create new Tokens and propagate those down the leaving transitions.

Graph execution ends when all tokens have entered a wait state.[当所有的令牌都进入等待状态，图表执行结束] At that time, the signal has been completely processed and the complete process execution (that is made up of a tree of tokens) enters a new overall(全面的) wait state. At this time, the tree of tokens can be persisted. Each token is now waiting to receive another signal.

One crucial(至关紧要的) refinement(精要) of this model is necessary : Actions(行为　动作). Actions are pieces of java code that are executed upon events in the process.[actions是在进程中事件之上执行的java代码片段] Examples of events are 'leaving a node', 'entering a node' and 'taking a transition'.[示例事件包括“离开一个节点”，"进入一个节点"、“接受一个转变”] These are all instantanious events that cannot span(跨越) wait states.

The refinement of the graph execution model with actions is necessary because this allows the technical developer to add implementation details to the business process, without having to change the graph that was originally(最初) created by the business analyst.

Now we can summarize how this model solves the traditional problems of workflow, BPM and orchestration solutions.
Simple API + chain of responsibility: replaces monolithic systems. 简单API+责任链
Inheriting from Node: gives ultimate(最终) process language power. 从节点中继承
Adding ‘invisible’ Actions: gives modelling freedom to the business analysts.　　加入不视行为
Process development cycle: replaces visual programming. 　过程开发周期

java世界畅谈 2005-06-07 15:25 发表评论

在jBpm3.0指南中几个例子的剖析

java世界畅谈 — Mon, 06 Jun 2005 08:45:00 GMT

在指南中分别有5个例子由简单到复杂，根据测试用例从各个层面展示了jBpm的使用：
1.Hello World 例子：
主要展示了
（1）从XML String 形式中获得 ProcessDefinition
（2）构造实例化ProcessInstance
（3）获得令牌token
（4）使用signal()用法
其中，JpdlXmlReader.parse(String str)
parses a process definition from a string. replaces single quotes with double quotes before parsing the xml.
从XML中解析一个流程定义。在解析先，用双引号代码单引号。
2.数据库例子：
jbpm的一个基本特征就是：当它们在等待状态中，有能力在数据库中持久化流程的执行。
主要展示：
（1）获得JBpmSessionFactory static 对象
（2）创建数据库schema
jBpmSessionFactory.getJbmpSchema().createSchema();
（3）获得创建JbpmSession
（4）引入GraphSession。 are the graph related database operations.
（5）根据流程名获得最近的ProcessDefinition
ProcessDefinition processDefition = jbpmSession.getGraphSession.findLatestedProcessDefinition("hello world");
3.传递变量上下文例子:
主要展示：
（1）ContextInstance 为流程实例维护所有的key-variable对。
ContexrInstance contextInstance = processInstance.getContextInstance();
（2）赋值于获得值，Map机制
contextInstance.setVariable("amout",new Integer(500));
contextInstance.getVariable("amout");
4.任务委派例子：
主要展示：
（１）ProcessInstance .getTaskMgmtInstance() 　为管理任务和行为，传递实例扩展。
（２）任务实例　TaskInstance
TaskInstance taskInstance = (TaskInstance)processInstance.getTaskMgmtInstance().getTaskInstances().iterator.next();
（３）taskInstance对用有actId
5.定制行为例子：
主要展示：
（１）actions是绑定特定java代码到jBpm流程的一种机制。actions可以被用来连接它自己的节点。actions可以替代事件（转变、进入、离开一个节点）。
（２）actionHanlder 要实现ActionHandler接口。 ActionHandler接口定义了一个方法execute(ExecutionContext executionContext) 。

java世界畅谈 2005-06-06 16:45 发表评论