工作流引擎内核入门

        1. 引言
        以WfMC，OASIS，OMG三大组织为代表的群体，围绕BPM相关规范，持续的争论。
        真是一流企业卖标准，二流企业卖技术。当新一轮技术浪潮围绕着BPM展开时，国际上相关厂商首先把眼光放在了“规范”上。这个规范最早是以WfMC为代表的“业务流程开发商”，他们主要拥护以XPDL作为描述语言来描述业务流程；之后是以OASIS组织为代表的，被IBM,MicroSoft,BEA所拥护的BPEL/BPEL4WS规范；之后向来以规范著称的OMG组织也不甘示弱，联合BPMI组织，独辟蹊径以Notation Specification为入口，首先推出了BPMN规范，进而推出了BPDM，也妄想分一杯业务流程描述规范。
        今年6月份，在OMG联合BPTrend、BPMI所发起的“BPM Think Tank Day”讨论会中，三大阵营代表及支持者是各不相让，当然作为主办方也借此机会大肆鼓吹其BPDM的统一设想。
        自从这个Think Tank Day之后，围绕着BPMN，BPDM，BPEL，XPDL之间的讨论在各大BPM相关站点上持续升温。毕竟这几个规范都相应的重量级组织在支持，也有相应的厂商在支持和实现。
        可惜这场“规范”之战，对国内来说，似乎远在天边，没有任何影响。
        国内的开发商依然习惯了泰然处之，既来之则安之——好像哪家规范都对，也都无所谓。早些年大家接受了XPDL；后来见IBM、BEA等大厂商大肆鼓吹BPEL，有些厂商也是蠢蠢欲动了。
        2. 什么是工作流管理系统(WFMS)
        2.1. 概述
        企业在进行业务处理时，政府在进行公文审批时，都是以流程形式而进行的，在信息化的过程中，企业、政府也将这些业务处理、公文审批的过程信息化了，早期通常是通过程序硬编码的方式来处理这些业务、公文的流转，随着业务、公文的复杂的处理情况不断出现以及需求的不断变更，这种硬编码的方式显然已无法应对，这个时候工作流管理系统应运而生，掀起了一股工作流管理系统的热潮。
        那么到底工作流管理系统能够带来什么好处？工作流管理系统通过对业务、公文流转进行分析以及抽象，将不变和变化的部分进行划分，用户可轻松的通过可视化的工具对事项的流程、流程环节涉及的人员(角色)、流程环节的表单、流程环节的操作进行修改，从而到达了应对不断变化的需求的目的，而工作流管理系统通常提供的流程监控、查询统计模块更是极大程度的为用户优化流程提供支持，以提高企业、政府的工作效率。
        本文主要描述工作流管理系统通常的结构、参考模型以及通常使用的调度算法。
        2.2. 构成
        工作流管理系统，简称WFMS，经过对业务、公文流转过程的分析以及抽象，工作流管理系统围绕业务交互逻辑、业务处理逻辑以及参与者三个问题进行解决，业务交互逻辑对应的为业务的流转过程，在工作流管理系统中对应的提出了工作流引擎、工作流设计器、流程操作来解决业务交互逻辑的问题，业务处理逻辑对应业务流转过程中的表单、文档等的处理，在工作流管理系统中对应的提出了表单设计器、与表单的集成来解决业务处理逻辑的问题，参与者对应到的为流转过程中环节对应的人或程序，在工作流管理系统中通过与应用程序的集成来解决参与者的问题。
        工作流管理系统为方便业务交互逻辑、业务处理逻辑以及参与者的修改，多数通过提供可视化的流程设计器以及表单设计器来实现，为实现工作流管理系统的扩展性，多数提供了一系列的API。
        一个完整的工作流管理系统通常由工作流引擎、工作流设计器、流程操作、工作流客户端程序、流程监控、表单设计器、与表单的集成以及与应用程序的集成八个部分组成。
        2.2.1. 工作流引擎 
        工作流引擎作为工作流管理系统的核心部分，主要提供了对于工作流定义的解析以及流程流转的支持。工作流定义文件描述了业务的交互逻辑，工作流引擎通过解析此工作流定义文件按照业务的交互逻辑进行业务的流转，工作流引擎通常通过参考某种模型来进行设计，通过调度算法来进行流程的流转(流程的启动、终止、挂起、恢复等)，通过各种环节调度算法(SPLIT、AND、OR等)来实现对于环节的流转(环节的合并、分叉、选择、条件性的选择等)。
        2.2.2. 工作流设计器
        工作流设计器为可视化的流程设计工具，用户通过拖放等方式来绘制流程，并通过对于环节的配置来实现环节操作、环节表单、环节参与者的配置。
        工作流设计器为用户以及开发商提供了快速绘制、修改流程的方式，工作流设计器的好坏决定到工作流管理系统的易用性。
        2.2.3. 流程操作
        流程操作指所支持的对于流程环节的操作，如启动流程、终止流程、挂起流程、直流、分流(单人办理)、并流(多人同时办理)、联审等，象这些流程操作都是可直接基于引擎所提供的环节调度算法来直接支持的，而在实际的需求中，通常需要自由的对于流程进行干涉，如取回、回退、跳转、追加、传阅、传阅办理等，而这些流程操作对于工作流引擎来说是不合理的，因此必须单独的去实现。
        流程操作支持的好坏直接决定到一个工作流管理系统的实用性。
        2.2.4. 工作流客户端程序
        工作流客户端程序为工作流系统的表现形式，通常使用Web方式进行展现，通过提供待办列表、已办列表、执行流程操作、查看流程历史信息等来展现工作流系统的功能。
        2.2.5. 流程监控
        流程监控通过提供图形化的方式来对流程执行过程进行监控，包括流程运转状况，每个环节所耗费的时间等等，而通过这些可相应的进行流程的优化，以提高工作效率。
        2.2.6. 表单设计器
        表单设计器为可视化的表单设计工具，用户通过拖放的方式来绘制业务所需的表单，并可相应的进行表单数据的绑定。
        表单设计器为客户以及开发商提供了快速修改表单的方法，表单设计器的易用与否以及功能的完善与否影响到工作流管理系统的易用性。
        2.2.7. 与表单的集成
        通常业务流转需要表单来表达实际的业务，因此需要与表单进行集成来实现业务意义，与表单的集成通常包括表单数据的自动获取、存储、修改，表单域的权限控制、流程相关数据的维护以及流程环节表单的绑定。
        与表单的集成的好坏影响到工作流管理系统是否能提高开发效率。
        2.2.8. 与应用程序的集成
        通过与应用程序的集成来完善工作流管理系统的业务意义，主要涉及到的是与权限系统以及组织机构的集成。流程环节需要相应的绑定不同的执行角色，而流程操作通常需要与权限系统、组织机构进行关联。
        2.3. 参考模型
        工作流系统通常通过参考一些标准的模型来进行设计，主要的有WFMC和OMG，在这里主要介绍一下WFMC。
        2.3.1. WFMC
        WFMC是国际工作流管理联盟，它于1993年成立，发布了一系列的工作流定义、软件接口的草案文本，是目前世界上公认的最具权威性的工作流标准制定机构，得到了广泛的支持和应用。
        2002 年10月25日，WFMC发布了基于XML的流程定义语言1.0版的最终文本（Workflow Process Definition Interface----XML Process Definition Language 文档编号：WFMC-TC-1025），以及此前发布的工作流应用软件接口规范WFMC-TC-1009, WFMC-TC-1013等系列文件，构成了工作流定义及系统的设计标准。
        为了实现不同工作流产品之间的互操作，WfMC在工作流管理系统的相关术语、体系结构及应用编程接口等方面制定了一系列标准。工作流管理联盟给出的工作流定义是：工作流是指整个或部分经营过程在计算机支持下的全自动或半自动化。在实际情况中可以更广泛地把凡是由计算机软件系统（工作流管理系统）控制其执行的过程都称为工作流。
        一个工作流包括一组活动及它们的相互顺序关系，还包括过程及活动的启动和终止条件，以及对每个活动的描述。工作流管理系统指运行在一个或多个工作流引擎上用于定义、实现和管理工作流运行的一套软件系统，它与工作流执行者（人、应用）交互，推进工作流实例的执行，并监控工作流的运行状态。
        WFMC主要提出了五个接口与工作流执行服务一起共同组成了工作流系统：
        *接口一(工作流定义交换)，用于在建模和定义工具与执行服务之间交换工作流定义。主要是数据交换格式和API。数据交换通过XPDL，API通过WAPI。
        *接口二(工作流客户端应用接口)，用于工作流客户端应用访问工作流引擎和工作列表，通过WAPI完成。
        *接口三(被调用的应用接口)，用于调用不同的应用系统。
        *接口四(工作流系统互操作接口)，用于不同工作流系统之间的互操作。
        接口五(系统管理和监控)，用于系统管理应用访问工作流执行服务。
        2.4. 核心调度算法
        通常流程引擎采用的核心调度算法主要有FSM以及PetriNet两种，基于调度算法来完成流程的流转。
        2.4.1. FSM(有限状态机)
        FSM 的定义为包含一组状态集（states）、一个起始状态（start state）、一组输入符号集（alphabet）、一个映射输入符号和当前状态到下一状态的转换函数（transition function）的计算模型。当输入符号串，模型随即进入起始状态。它要改变到新的状态，依赖于转换函数。在有限状态机中，会有有许多变量，例如，状态机有很多与动作（actions）转换(Mealy机)或状态（摩尔机）关联的动作，多重起始状态，基于没有输入符号的转换，或者指定符号和状态（非定有限状态机）的多个转换，指派给接收状态（识别者）的一个或多个状态，等等。
        遵循FSM流程引擎通过状态的切换来完成流程的流转。
        2.4.2. PetriNet
        信息流的一个抽象的、形式的模型。指出一系统的静态和动态性质。petrinet通常表示成图。遵循PetriNet流程引擎通过令牌来决定流程的流转。
        注1: 
        目前国外一些大规模、分布式的工作流系统的建模工具就采用的是基于Petri网的图形化建模方式。
        注2: 
        Petri网工具
        3. 透过XPDL来讲解什么是工作流描述语言和基本元素
        3.1. XPDL基本元素介绍
        Package元素
        DataField元素
        WorkflowProcess元素
        Activity元素
        Implementation元素
        Tool元素
        TransitionRestricti
        4. jPdl规范
        5. bpel规范
        5.1.1. 背景知识
        面向 Web 服务的业务流程执行语言（BPEL 或 BPEL4WS）是一种使用 Web 服务定义和执行业务流程的语言。BPEL 使您可以通过组合、编排和协调 Web 服务自上而下地实现面向服务的体系结构 (SOA)。BPEL 提供了一种相对简单易懂的方法，可将多个 Web 服务组合到一个新的复合服务（称作业务流程）中。
        本文将介绍如何创建一个将一系列虚拟的、与旅行相关的 web 服务结合起来的示例业务流程，然后将其部署到 Oracle BPEL Process Manager 运行时环境。
        首先，介绍一些背景知识。BPEL 基于 XML 和 Web 服务构建；它使用一种基于 Web 的语言，该语言支持 web 服务技术系列，包括 SOAP、WSDL、UDDI、Web 服务可靠性消息、Web 服务寻址、Web 服务协调以及 Web 服务事务。
        BPEL 流程指定参与的 Web 服务的确切调用顺序 - 顺序地或并行地。使用 BPEL，您可以表述条件行为。例如，某个 Web 服务的调用可以取决于上次调用的值。还可以构造循环、声明变量、复制和赋予值、定义故障处理程序等。通过组合所有这些构造，您可以以算法的形式定义复杂业务流程。实际上，由于业务流程本质上属于活动图，因此使用统一建模语言 (UML) 活动图表示它们可能很有用。
        通常情况下，BPEL 业务流程接收请求。为了满足请求，该流程调用相关的 Web 服务，然后响应原始调用方。由于 BPEL 流程与其他 Web 服务通信，因此它在很大程度上依赖于复合型 Web 服务调用的 Web 服务 的 WSDL
        5.1.2. 如何构建业务流程
        BPEL 流程指定参与的 Web 服务的确切调用顺序 - 顺序地或并行地。使用 BPEL，您可以表述条件行为。例如，某个 Web 服务的调用可以取决于上次调用的值。还可以构造循环、声明变量、复制和赋予值、定义故障处理程序等。通过组合所有这些构造，您可以以算法的形式定义复杂业务流程。实际上，由于业务流程本质上属于活动图，因此使用统一建模语言 (UML) 活动图表示它们可能很有用。
        通常情况下，BPEL 业务流程接收请求。为了满足请求，该流程调用相关的 Web 服务，然后响应原始调用方。由于 BPEL 流程与其他 Web 服务通信，因此它在很大程度上依赖于复合型 Web 服务调用的 Web 服务 的 WSDL 描述。
我们来看一个示例。一个 BPEL 流程由多个步骤组成，每个步骤称作“活动”。BPEL 支持基元活动和结构活动。基元活动表示基本构造，用于如下所示的常见任务：
        * 使用 调用其他 Web 服务
        * 使用 （接收请求）等待客户端通过发送消息调用业务流程
        * 使用 生成同步操作的响应
        * 使用 操作数据变量
        * 使用 指示故障和异常
        * 使用 等待一段时间
        * 使用 终止整个流程。
        然后，我们可以组合这些基元活动以及其他基元活动，以定义准确指定业务流程步骤的复杂算法。为组合基元活动，BPEL 支持几个结构活动。其中最重要的是：
        * 顺序 ()，它允许定义一组将按顺序调用的活动。
        * 流 ()，用于定义一组将并行调用的活动
        * Case-switch 构造 ()，用于实现分支
        * While ()，用于定义循环
        * 使用 能够选择多个替换路径之一。
        每个 BPEL 业务还将使用 定义合作伙伴链接，使用 声明变量。
        为了理解 BPEL 是如何描述业务流程的，我们将定义雇员出差安排的简化业务流程：客户端调用此业务流程，指定雇员姓名、目的地、出发日期以及返回日期。此 BPEL 业务流程首先检查雇员出差状态。我们将假设存在一个可用于进行此类检查的 Web 服务。然后，此 BPEL 流程将检查以下两家航空公司的机票价格：美国航空公司和达美航空公司。我们将再次假设这两家航空公司均提供了可用于进行此类检查的 Web 服务。最后，此 BPEL 流程将选择较低的价格并将出差计划返回给客户端。
        然后，我们将构建一个异步 BPEL 流程。我们将假设用于检查雇员出差状态的 Web 服务是同步的。由于可以立即获取此数据并将其返回给调用方，因此这是一个合理的方法。为了获取机票价格，我们使用异步调用。由于确认飞机航班时刻表可能需要稍长的时间，因此这也是一个合理的方法。为简化示例，我们假设以上两家航空公司均提供了 Web 服务，且这两个 Web 服务完全相同（即提供相同的端口类型和操作）。
        在实际情形下，您通常无法选择 Web 服务，而是必须使用您的合作伙伴提供的服务。如果您有幸能够同时设计 Web 服务和 BPEL 流程，则应考虑用哪个接口更好。通常，您将对持续时间较长的操作使用异步服务，而对在相对较短的时间内返回结果的操作使用同步服务。如果使用异步 Web 服务，则 BPEL 流程通常也是异步的。
        当您用 BPEL 定义业务流程时，您实际上定义了一个由现有服务组成的新 Web 服务。该新 BPEL 复合 Web 服务的接口使用一组端口类型来提供类似任何其他 Web 服务的操作。要调用用 BPEL 描述的业务流程，则必须调用生成的复合 Web 服务。 

        三大主流工作流引擎技术分析与市场预测

        1．从《功夫》说起时下的新新人类看到我，一定会认为在下是个十足的老古董，这不，《功夫》这样的片子我到今年2月底才看。不过看过《功夫》，我想的一定比一般的人多：周星星浪迹江湖，和他胖子大哥出去敲竹杆时，为什么要他大哥胸前画两把斧头？找个假靠山呗！装是斧头帮的人才不会被人欺负啊。 

        这让我想到年前的一则新闻：jbpm joins jboss and becomes jboss-jbpm。也就是说了，jbpm找了个靠山jboss，以后不用自己在外流浪了。 

        好，我们转入正题，谈这里说的三大主流开源工作流引擎：Shark,osworkflow,jbpm。 

        Shark的靠山是Enhydra。Enhydra做过什么呢？多了！从 j2ee应用服务器，到o/r m apping工具，到这个工作流引擎等等。为什么Shark的持久层采用DODS来实现？就是因为他们是一家人。 

        Jbpm的靠山是jboss。Jbpm3的持久层采用hibernate3来实现，也是因为这个原因吧。Jbpm3的图形化流程定义已经决定嵌入到jboss eclipse IDE中，大家看看jboss eclipse IDE prev iew 1.5版，我们已经可以用插件方式编辑一个jbpm3流程定义文件了。 

        Osworkflow的靠山是opensymphony。我是非常喜欢这个组织的，它做出了很多的好东西。在开发工作流管理系统时，我就推荐用它的另外一个东西：webwork2。笔者主持的开源工作流引擎AgileFlow就是基于ww2+spring+hibernate架构实现的。 

        完成本段时说句题外话：现在基本上所有的J2EE应用程序服务器都有自己的工作流引擎，如上面提到的Enhydra,jboss和没有提到的websphere和weblogic等，可见，学习工作流引擎技术的确是非常重要的。 

        2．如来神掌

        光有靠山是不行的，周星星加入了斧头帮还不是被邪神打扁了头？要救自己，还是要靠如来神掌。 

        Shark的流程定义语言是 XPDL，我们知道，XPDL的两个最重要的概念是 Process和Activity。XPDL中的Activity是基于UML1.x中的活动图的概念。活动图天生的适于工作流程建模，它相对于状态图的一个最大的优点是容易做并发线程的分叉控制，这些并发线程可以同时执行也可以顺序执行；它还有一个优点是有泳道的概念，可以控制工作流引擎中的任务的产生。Shark的如来神掌是活动图。 

        Osworkflow的如来神掌又是什么呢？我们知道，它有个重要概念是State……呵呵，我们知道了，它的如来神掌是FSM。不知道FSM是什么东西？？那你读大学时肯定不是好学生；当然了，不知道也不打紧，你把他类似理解为状态图就可以了。Osworkflow中的State是由step和status联合表达的，一个State就是一个step中的某个status；而state的转换由action来驱动，类似状态图中的event,因为一个event对应一个action嘛。 

        Jbpm的如来神掌就没有上面的简单了，它结合应用了状态图+活动图+PetriNet的知识，而且，这里的活动图还是UML2.0版的。UML2.0的活动图中，节点不叫活动（Activity）而叫动作(action)，活动成了一个高层次的概念，它包含一个动作序列。一个活动图展现一系列的动作，这些动作组成了活动。Jbpm把action也改名了，称为state。Jbpm使用的状态图的概念有transition/event等，这个自己去看吧。Jbpm来内部实现中还采用了PetriNet的概念，如token,signal等。什么？又不知道PetriNet什么东东？那你大学是学计算机的吗？不是？那你可能是学文科的，学机械/电气/土木工程/交通运输等专业都有接触PetriNet的课程，如果没有学过，还是看看jbpm吧，反正我们也不搞理论，知道大致概念就行。 

        3．市场预测做预测是件吃力不讨好的事情，好多国外的大师做的预测也是被人骂得……幸亏我去年年中在《工作流之大局势》中做的预测还是基本正确。那时我的预测是：Shark……将登上头号宝座。应该说，在那篇文章发表前，国内的工作流引擎使用率最高的是osworkflow;到去年年底，Shark就占有了明显的优势地位，我分析有如下原因： 

        1） 国内的企业都看中XPDL，因为这意味着在产品说明书中又可以吹牛说“我们遵循WFMC……” 

        2） 因为我自诩“Shark工作流引擎在国内的主要推广者”，大部分给我反馈工作流管理系统开发选用技术的朋友都是用的Shark 

        3） Shark的确是一套不错的工作流引擎，就算你只是想学习XPDL，你也可以从学习Shark开始 

        现在已经到了《工作流之大局势》中说的从封建社会向资本主义转型的时代，而驱动这一转型的，不是别人，正是上面说的jbpm。Jbpm3将在3月发布阿尔发版，jbpm3的最终版将支持bpel4ws的核心部分。所以，我估计，Shark将在引领风骚数百天后，被jbpm3赶下第一宝座。笔者的开源敏捷工作流开发框架AgileFlow将整合jbpm3，同时对agile引擎和jbpm3引擎提供支持。 

        但bpel4ws真的就和我们这么快的亲密接触了吗？没有。我估计在今年它是不会真正走进我们的生活的，那会是什么时候呢？这将是我下篇文章要预测的内容，我现在可不敢乱说，我现在考虑的是，是不是要自诩“jbpm3工作流引擎在国内的主要推广者”，呵呵

        几个概念的注解：
        fsm：有限状态机（finite state machine or finite state automata），指输出决定于过去输入部分和当前输入部分的时序逻辑电路。
        petrinet是离散并行系统的数学表示，适合于并发的、异步的数学模型。经典的pn是简单的过程模型，由两种节点（库所、变迁）及有向弧及令牌（token）组成。描述了完备的支撑过程调度算法，基于petrinet的工作流引擎，其引申了两种节点：一种是state，一种是activity，其中state演化自place，activity演化自transition。