Shark是体系和功能最为复杂的代表。它是另一款遵循WfMC的XPDL标准开源工作流引擎，并且同时遵循OMG组织的Workflow Management Facility规范。在所有开源工作流引擎中，Shark的体系最为完备和复杂。其一直秉承着“模块化”的思想，所以比较容易扩展。但是自从被Together公司收购后，Shark的商业化色彩已经越来越浓，改称为Together Workflow Server，并仅以Community Edition的形式提供了部分开源代码供参考。

　　OSWorkflow

　　OSWorkflow是最轻量型的代表，也是一款非常灵活和低级别定位的工作流引擎的实现框架。低级别定位的意思是说，它不是定位在解决流程模型对象和运转场景，而是提供一套可维护调度的机制，供开发人员自主扩展。这个维护流程调度机制OSWorkflow选择的是基于行为(Action)的FSM理论，所以OSWorkflow更像是一个复杂而灵活的有限状态调度机。

　　OSWorkflow在国内项目应用得较多，很多国内的简易审批流程项目都是基于其引擎二次开发而来。这主要是由于OSWorkflow是基于Action驱动的，而国内的客户也很容易接受这样的操作习惯。但OSWorkflow所依赖的FSM模型对于分支、聚合、子流程的支持度很低，这一点在实施过程中需要注意。

　　jBpm

　　jBpm是最适合扩展的代表，是在所有开源引擎中最适宜被商业化应用的一款。首先其流程建模模型是基于Activity Diagram(活动图)的，并在引擎构建上融入了FSM和PetriNet思想，所以其内核和根基比较牢固扎实。其次，自从被JBoss收购后，其3. x系列的结构更加趋于微内核，Plug-in思想也更加深入。其同时还提供了对BPEL扩展，存储支持JBoss Hibernate实现，集成了JBoss seam，规则引擎准备采用JBoss rules，并准备集成JBoss Messaging。这样，不论从内核和外围应用，jBpm都具有了强劲的动力。

　　另外，jBpm对Token的应用也很有特色，巧妙地利用Parent-Child Token的机制处理分支、父子流程等复杂应用场景。这个设计思想很值得大家学习参考。

　　YAWL

　　YAWL是算法和模式最值得研究的代表，它是Alast力主倡导的一款基于PetriNet建模的工作流引擎，其将PetriNet的Token与And、XOR、OR算法进行了融合，并对Workflow Patterns(工作流模式)中所有模式提供支持。但YAWL本身仅是一个研究性项目，所以其结构和实现缺少了商业化应用的特点。但有必要研究一下YAWL，一方面可以加深对工作流模式的理解，另一方面，YAWL的一些建模思想、处理算法很值得推敲和吸纳。

　　ActiveBPEL

　　ActiveBPEL 是BPEL引擎的代表，也是一款可执行BPEL4WS规范的开源流程引擎，其结构和实现方式具有很高的参考价值。目前国内很多正在开发基于BPEL产品的中小型软件厂商，其实现的很多基础性内容和思想都参考自ActiveBPEL。受目前国内中小型客户对流程需求的限制，基于BPEL的开源引擎或小型产品被市场接受度还很低。但BPEL所围绕的业务流程及流程整合应用是一个发展趋势。

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

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

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

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

Jbpm的靠山是jboss。Jbpm3的持久层采用hibernate3来实现，也是因为这个原因吧。Jbpm3的图形化流程定义已经决定嵌入到jboss eclipse IDE中，大家看看jboss eclipse IDE preview 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工作流引擎在国内的主要推广者”，呵呵。

http://www.360doc.com/showWeb.aspx?ArticleID=4713

工作流 现状 （原文）

作者Tom Baeyens 翻译dinghong

前言

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

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

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

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

定义

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

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

    工作流系统另一个重要的职责是维护每一个流程运行的上下文信息。 流程上下文变量（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平台时，必须在流程中集成代码。开发流程定义需要业务分析师和软件开发人员的合作。一个好的图形流程设计工具应该能够支持这种合作。

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

流程定义的四个层次

    在下面这部分，我尝试回答这样的问题“什么是流程定义包括的内容？”。这是从各种规范和工具所使用模型的原则和概念中总结得来的，反映了大部分模型中通用的基本思想。流程定义的内容可以分为四个不同的层次：状态（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活动图的图形部分仍旧可以用来对业务流程状态层次建模，只要使用时对两条构建语义作如下的变化：

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

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

上下文层

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

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

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

程序逻辑层

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

用户界面层

工作流全景

可执行流程与工作流管理系统的比较（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完成与所有流程实例的交互。在可执行业务流程中，每个流程表现为一个服务。这意味着对于每个流程定义都有一个不同的访问点。

学术界

开放源代码项目

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

    下面的列表来源于三个地方：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）处理方法，流程由一组具有前后条件的活动组成。

商业软件提供商

• Bea's WLI
• Carnot
• Dralasoft
• Filenet
• Fujitsu's i-Flow
• IBM's holosofx tool
• Intalio
• intelliFlow 
• Lombardi
• Oakgrove's reactor
• Oracle's integration platform
• Q-Link
• SAP's NetWeaver
• Savvion
• Seebeyond
• Sonic's orchestration server
• Staffware
• Ultimus
• Versata
• WebMethod's process modeling

工具目录

• http://dmoz.org/Computers/Software/Workflow/Products/
• A collection of links to tools for modelling business processes and workflows maintained by Bart-Jan Hommes at TU Delft, the Netherlands.

规范

    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）的阶段，但已经有可靠的工具存在了:

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

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

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

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

Further reading

• Workflow Patterns -Wil van der Aalst教授的工作流模式学术研究网站
• ebpml.org - 有关业务流程管理和工作流的网站，信息量大、全面
• 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.
• Enix - 英国流程管理顾问公司，在网站上有不错的内容
• ebizq.net - Commercial community that has booths, webinars and other interesting stuff put together in a nice website.
• An introduction to petri nets - The title says it all.
• Organizational Management in Workflow Applications- An interesting article that discusses the relation between business processes and the organisational data involved.
• Web services orchestration - an HP-paper that reviews the emerging technologies tools and standards. (Januari 2003)
• Business process standards for web services - An article that discusses the various aspects involved in workflow and BPM.

  Thanks

      A special thanks for Gustavo Maciel Dias Vieira and Jef Vanbockryck for their valuable feedback on the draft versions of this article.

  about the author Tom Baeyens leads the jBpm support organisation, specialized in Java, workflow and business process management. His expertises are both at a technical, analysis and at a business level. Tom is the founder of jbpm.org, an open source workflow engine. Tom is also a member of the expertgroup of the JSR 207: Process Definition for Java. Tom Baeyens can be contacted at tom at jbpm.org