工作流产品整理

第 I 条                               工作流简介

1        什么是工作流？

简单地讲，工作流就是业务流程（Business Process）的计算机化或自动化。企业或组织内有许多繁琐复杂的业务流程，这些流程构成了企业或组织的日常运营活动。通过现代的技术手段将这些流程自动化，并对其进行有效地管理便是工作流管理需要解决的问题。

2        什么是工作流管理？

工作流管理的许多概念源于企业管理理论和实践，随着企业规模不断扩大，管理的难度也随之上升，信息技术和现代企业管理理论的发展，都为有效地克服这些困难提供了理论和技术手段。工作流技术是一项快速发展的技术，并在各个行业得到广泛应用。其主要特征是业务流程（Business Process）的自动化，这些流程有人工的，也有自动的，其主要特点是，这些流程的处理都是在计算机应用程序和工具协助下进行的，就是说，由计算机系统来帮助人们完成日常事务的处理。

企业实施工作流管理所带来的好处是非常明显的，这包括提高企业运营效率、改善企业资源利用、提高企业运作的灵活性和适应性等等。工作流管理的最终目的都是为了缩短企业运营周期、改善企业内（外）部流程、优化并合理利用资源、减少人为差错和延误，以提高劳动生产率。

3        什么是工作流标准组织WfMC？

有许多软件厂商提供各自的工作流软件产品，而且新的产品也不断涌现，用户有很大的选择余地，但是如果没有可遵循的行业标准，就会使这些产品之间存在巨大差异，导致这些产品之间不能协同工作，成为一个个信息的"孤岛"。

在这种背景下，工作流管理联盟（WfMC）于1993年成立了，这是由多家公司联合成立的国际标准组织，其目的是通过制定工作流技术及其标准，提高不同工作流产品之间的连通性和协同工作能力。通过使用标准可以使不同的产品之间协同工作，也可以改善工作流产品与其他IT服务（电子邮件、文档管理）之间的集成。

该组织由三个委员会组成，分别是技术委员会、对外关系委员会和筹划指导委员会，WfMC目前有270多个成员组织，遍布世界各地。经过该组织的不懈努力，工作流标准的制定和推广工作进展得非常迅速，目前，多数工作流产品的生产厂商已经在产品中遵循了全部和部分标准。

4        工作流标准

工作流管理联盟定义的工作流系统标准中包括一个参考模型及其5个接口的规范，这些规范确定了开发工作流产品所必须遵循的行业标准，只有遵循这些规范开发的产品才可称为真正的工作流产品。

5        工作流包括以下几个要素：

5.1实体(Entity) ：

是工作流的主体，是需要随着工作流一起流动的物件(Object)。例如，在一个采购申请批准流程中，实体就是采购申请单；在公文审批流程中，实体就是公文。

5.2参与者(Participant) ：

是各个处理步骤中的责任人，可能是人，也可能是某个职能部门，还可能是某个自动化的设备；

5.3流程定义(Flow Definition) ：

是预定义的工作步骤，它规定了实体流动的路线。它可能是完全定义的，即对每种可能的情况都能完全确定下一个参与者，也可能是不完全定义的，需要参与者根据情况决定下一个参与者；

5.4工作流引擎(Engine) ：

是驱动实体按流程定义从一个参与者流向下一个参与者的机制

可以看出，前三个要素是静态的，而第四个要素是动态的，它将前三者结合起来，是工作流的核心组成元素。

6        为什么需要电子化的工作流(eWorkFlow)?

手工处理的工作流主要有以下几个缺点：

6.1不能及时得到处理

一个步骤完成后必须将实体物理地转移给下一个参与者，当工作量增大时，很难分清哪些是重要而需要及时处理的，甚至经常出现上一个步骤已经完成了，而下一个步骤还不知道的情况；

6.2无法跟踪

传统的手工操作要求有一个人自始至终地跟着单子（比如采购申请单）走，否则流程中的任何一个人也无法知道一项任务当前的处理位置，当出现停顿时甚至无法知道该找谁解决；

6.3效率不高

很多实际上可以并行处理的步骤（例如公文审批过程中的会签），在手工处理的时候，只能一个接一个的串行处理；

6.4缺乏分析功能

流程是人制定的，是否适合实际情况只能通过实际工作检验。但手工处理无法统计各个环节的处理效率，因此对流程的评估都是大致的，凭感觉的，无法量化，对流程的改造缺乏科学的统计数据做基础。

通过采用先进的信息技术，以上问题可以迎刃而解。软件的力量，是把繁杂而没有条理的工作，分门别类地整理出来，给每个人一个清楚的视图，及时了解当前的工作状态，易于跟踪和查询。同时强大的统计分析功能便于从海量的数据中找出人工统计所无法发现的规律，并据此做出正确的决策。

7        发展阶段

工作流(WorkFlow)的概念是在现代信息系统的建设中逐步形成的，一般把它分为三个阶段:

7.1EDF(电子数据流)阶段

此时的工作流在信息技术中的应用,仅着眼于利用信息技术减轻人们在流程中的计算强度,如设计一个流程用来协调多个会计统计帐目。所以,EDF最主要的特点是仅对企业单项业务进行处理,基本不涉及管理的内容。

7.2TPF(事务处理流)阶段

TPF并没有形成对企业的全局业务的管理,而着眼于对企业局部业务的管理,比如,设计一套工作流程,来管理物资的采购和供应。

7.3IMF(信息管理流)阶段

当今的工作流, IMF强调对企业业务的全局的整体性的管理。在这个阶段,工作流就是为了完成同一目标而相互衔接、自动进行的一系列业务活动或任务。目前,工作流技术与信息技术以及企业管理紧密结合,已经悄悄渗入MIS系统、ERP系统和CRM系统等企业级关键系统中,并迅速成为这些系统的核心。

8        工作流参考模型

8.1Work Flow Enactment Service

这个组件就是我们平常说的工作流机或工作流引擎，主要功能是读取工作流定义、根据工作流定义驱动工作流的流转。一般常用的开源的JAVA工作流机有Shark/OBE/ofbiz等

8.2Process Definition Tool

用于以图形化的方式定义工作流。如著名的JAWE。Process Definition Tool与Work Flow Enactment Service之间的接口就是Interface 1。接口一标准目前就是XPDL标准。

Work Flow Client Application

工作流机的客户端程序。该程序由用户结合业务需求而开发,用它来驱动工作流。客户端程序通过Interface 2与引擎交互。一般的工作流引擎用户不需要懂引擎的实现,只要知道怎么实现客户端程序就可以了。

8.3Invoked Applications

在工作流运作的过程中，可能需要调用工作流机之外的功能，这时可通过定义好的Interface 3来完成。

8.4other Work Flow Enactment Service

Interface 4用于工作流机与其他工作流机的协作。

8.5Administration and Monitoring Tools

用于管理和监视工作流机,这个就是接口5了。

9         工作流引擎的三种定位

应该由谁来负责定义和开发工作流的应用？一般有三种观点，也就是我们对工作流引擎的三种定位：

9.1完全由实际的技术人员来负责定义和开发工作流的应用

我认为这种观点等同于不需要工作流引擎，它只适合简单、变化少的工作流应用；如果业务逻辑和业务规则比较复杂，则需要自己定制相应的应用逻辑，并且不灵活。

9.2业务人员和技术人员结合

工作流产品提供图形化的界面，供业务人员定义业务逻辑；技术人员需要完成具体的应用逻辑。

9.3业务人员独立

该观点认为，应该把信息系统的开发融入工作流引擎中，即工作流引擎完成所有功能。

9.4就国内目前情况看

大部分的关键业务系统没有应用工作流思想，即第一观点，该观点已经被证明是不正确的；国外的开源软件都采用第二种观点，因为它不能预测到所有的用户的应用需求；国内部分公司采用第三种观点，但目前还没有一个比较好的解决方案。

第 II 条                          工作流管理系统比较

1        工作流模型分析

1.1发散模型

在发散模型中,活动A结束后,有M(2<=M<=9999999999..)个直接后继的可选活动

1)M项发散

        后面M项活动同时enabled,正式名称为Parallel Split

2)1项发散

        后面只可能一项活动enabled,正式名称为exclusive choice

3)N项发散

        后面可能有N项活动同时enabled,(1<=n<=m),正式名称为multiple choice

目前,一般的工作流产品及XPDL标准只支持前两项，对N项发散支持的不太强,但已经有产品如MQSeries/Workflow等直接较好的支持N项发散.

1.2聚合模型

1)     M项聚合

只有当M项活动都结束后,A活动才enabled

2)     N项聚合

1<=N<=M,其实就是一个鉴别器,当某N项活动完成后,条件满足,A活动才enabled

3)     单项聚合

任意一个活动结束,A活动都enabled

对于N项聚合和单项聚合有一个问题:A活动能够被几次enabled?根据对这个问题的回答,聚合模型又可以继续进行分类.

基本上所有的工作流标准都支持M项聚合和单项聚合,而对N项聚合,每个标准的支持程度是不一样的,XPDL标准不支持N项聚合.

1.3多实例模型

所谓多实例模型，指的是流程中的同一个活动，同时存在多个实例。

1）              异步
多个实例产生后，这些实例各自为政，互不影响。因为互不影响，所以异步的多实例模型的产生的实例数是任意的。当说到可以产生的实例数时，我们说的都是同步的情况，就如下面三点。

2）              定义期决定实例数
说的简单点，就是在JAWE中可以定义一个活动可以产生的实例数。

3）              运行期决定实例数
在流程运行过程中，动态决定一个活动可以产生的实例数。

4）              任意的实例数
说的粗一点，就是：一个活动，想产生实例就可以产生实例。

一般的标准都只支持前两种模型，包括XPDL标准。

2        业务流程定义语言规范

在工作流管理系统概念的基础上，演进出很多标准，总体上可分为基于标准 XML 文档的和基于 Web 服务技术的两种规范。

2.1基于标准XML文档的规范

此类规范最大的特点就是基于纯 XML 技术。其中包括：

1)      XPDL （Xml Process Definition Language）

在工作流领域第一个致力于标准化工作的是Workflow Management Coalition (WfMC)，它成立于1993年。1994年11月，wfmc发布了工作流管理系统的参考模型。参考模型提出了五类接口，有关过程模型的定义则构成了接口一的核心内容。接口一早期的标准为WPDL（Workflow Process Definition Language），后来,这一接口的规范变更为XPDL。XPDL是至今工作流领域最为重要的一个标准,目前大多数工作流引擎是依据该标准设计开发的。XPDL地位一步步削弱。

2)      BPML （ Business Process Modeling Language ）

BPML 是 BPMI （ Business Process Management Initiative ）组织发布的规范。 WfMC 和 BPMI 在 2002 年 6 月 26 日宣布将合作制定业务流程和工作流标准，即采用 BPML 来描述工作流过程，同时采用 XPDL 所定义的工作流模型。 BPML 规范为表达业务流程和支持实体提供一个抽象模型。 BPML 为表达抽象和执行流程定义了一种正式模型，该模型代表了企业业务流程的面貌，包含了不断变化的复杂行为，事务和数据管理，合作，异常捕获，操作语义。 BPML 为了能够持久化和通过异种系统进行定义交换以及使用建模工具，提供了 XML Schema 形式的语法。BPML基本上销声匿迹。

3)      OMG 的Workflow Management Facility

在 WfMC 所定义的一系列规范基础上， OMG （ Object Management Group ）联合这些规范发布了 Workflow Management Facility 规范，该规范定义了如何将工作流向 CORBA 转换。 CORBA的行情日渐没落。CORBA的两大特点是：思想超前，极不实用。OMG的Workflow Management Facility也秉承了这两大特点，在追求高效轻量的今天，它的没落也就是顺理成章的事情了。

2.2基于 Web 服务技术的规范

1)      WSCI

2002 年 6 月 26 日 BEA 、 Intalio 、 SAP 和 Sun 在美国发布了基于 XML 的 Web 服务协作接口 WSCI （ Web Services Choreography Interface ）。 WSCI 描述了在特殊流程中通过 Web 服务实现消息流的交流，并描述了集合性信息在互动的 Web 服务间的交流，提出了一种涉及到多种 Web 服务的复杂流程的全球观点。当今的服务描述语言对于简单的获取信息是足够的，例如股市报价，但它们没有提供充足的动作细节，来描述服务作为一个大型的、更全面的协作的一部分所扮演的角色。 WSCI 的关键优势之一在于，它通过描述 Web 服务如何在大型的、全面的业务流程中应用，从而在业务流程管理与 Web 服务之间架起了桥梁。这些业务流程可以只是一个公司内的，也可以是跨越多个公司的。后来又发展了几个新的, 如WSFL(属IBM),Xlang(属MS),因有天生缺陷,均没有很大起色。WSCI的几个厂商如BEA/SAP/SUN等均已经投靠到BPEL，WSCI基本上没有了发展的空间。

2)      ebXML

ebXML(Electronic Business XML)是一个规范集，这些规范共同实现了模块化电子商务框架。 ebXML 的构想是实现一个全球电子市场，其中，不同规模和不同地区的企业可以通过交换基于 XML 的消息来合作和进行商业活动。 ebXML 是一项倡议，其参与者与认可者包括几百家大公司和团体。 ebXML 的直接赞助者是 OASIS （ Organization for the Advancement of Structured Information Standards ）和 UN/CEFACT （ United Nations Centre for Trade Facilitation and Electronic Business ）。许多标准团体也参与其中，包括 NIST （ National Institute of Standards and Technology ）和 W3C 。ebXML只能在电子商务领域活动活动拳脚，由于它的体系结构的全面性，目前还有部分学术界人士在研究ebXML，但应该不会有很大起色。

3)      BPEL

（Business Process Execution Language for Web Services）2002年8月9日，Microsoft, BEA, IBM, SAP & Siebel联合提交发布了BPEL规范（他们的产品并不独立地实现BPEL）。 BPEL联合了XLANG, WSFL, BPML。此规范描述如何处理输入的消息，它不是一个关于业务流程规格化定义的规范。简单的说，可以将它看作XML形式的编程语言，提供将WSDL-Services组合成控制流的能力。顾名思义，此规范重点在（也不只限于）Web Service。BPEL在这两年得到了大力的发展。2002年8月9日，BEA/IBM/MS提出BPEL标准（从这里可以看出，BEA是个骑墙派，而IBM/MS则是强势派，因为当时已经有了WSCI标准）。2003年4月6日，OASIS组织用WS-BPEL的名字吸纳了BPEL标准（ebXML也是该组织旗下的大将，OASIS开始并不同意接收BPEL）。2003年5月3日，SAP/SIEBEL加入并共同推出WS-BPEL1.1版。2003年5月16日，SUN和ORACLE见势不妙，也加入了BPEL标准的领导者行列。WS-BPEL2.0的草案也在当时被纳入议事日程。

3        商业工作流软件介绍

3.1 IBM Websphere系列产品

    现在，IBM已经把Websphere作为整合的代名词。Websphere MQ Workflow实现流程整合，Websphere Business Integration Server实现业务整合。而收购的两个产品，改造为自己整合中间件的建模/管理/监控工具。

    这些产品都和IBM自己的其它产品比如：Websphere MQ 或者IBM DB2有直接关系。比如，我们使用MQ Workflow，只能用DB2数据库，不能用Oralce数据库。

    IBM的流程管理工具是市场上占有率最高的，约为 24%。

3.2 BEA AquaLogic系列产品

BEA本身就是一个收购型公司，它收购的产品均为自己公司创造了巨大的财富和影响力。就在今年的3月1日，BEA收购Fuego，Fuego的产品组合将加入到BEA的AquaLogic产品阵容中，将成为BEA新的AquaLogic商业服务互动产品线的基础。

BEA在流程管理工具方面的市场上占有率约为15%。

3.3 Microsoft Biztalk Server

看了资料说它的市场占有率为约17%。

3.4 Oracle BPEL Process Manager

    Oracle在融合派中是最早推出BPEL编辑器和引擎的产商，功能全面而且非常的稳定，可惜的是Oracle公司的所有产品目前和开源没有任何关联。

4        开源工作流软件产品分类介绍

4.1基于标准XML文档的规范

1)      OFBiz

最主要的特点是OFBiz提供了一整套的开发基于Java的web应用程序的组件和工具。其中包括实体引擎, 服务引擎, 消息引擎, 工作流引擎, 规则引擎等。OFBiz先前的工作流引擎基于WfMC和OMG的规范，使用XPDL作为流程定义语言，OFBiz新版的工作流引擎采用Shark工作流引擎,我们不建议再去学习OFBiz自身的工作流引擎。

http://ofbiz.apache.org/

2)      OBE

是由Adrian Price主持开发的一个开放源码的Java工作流引擎，支持WfMC规范，包括接口1（XPDL）、接口2/3（WAPI）和接口5。OBE主要基于J2EE实现。OBE的接口1实现得非常好。OBE至今没有release版，很是可惜。

3)      Shark

是完全根据WFMC规范实施的，可扩展功能的工作流引擎，它利用xpdl来定义流程，同时还包括服务器端的用于活动节点执行的WFMC工具代理API。Shark和XPDL定义工具的事实标准JAWE同出名门,市场前景被很多人看好。OFBiz新版的工作流引擎采用Shark工作流引擎。Shark工作流引擎与XPDL定义工具JAWE关系密切,是研究重点之一。而MS/IBM/BEA等跨国巨头越来越主推BPEL4WS标准，并且已经发布基于BPEL4WS标准的系列产品，而且，他们还主推Integration/Portal的概念。

http://shark.enhydra.org/

4.2基于 Web 服务技术的规范

1)      OpenebXML

OpenebXML 项目致力于提供一个ebXML框架，主要支持 UN/CEFACT和OASIS发布的ebXML规范2.0版。Open ebXML处在不仅没有财力，连关心的人都没有的悲惨景地。

2)      Bonita （**重点**结合Petri网模型）

Bonita 是一个符合WfMC规范、灵活的协同工作流系统。Bonita基于浏览器、使用SOAP和XML数据绑定技术的Web Services封装了已有的工作流业务方法并将它们以基于J2EE的Web Service形式发布。

3)      Twister

Twister 的目标是提供新一代、易集成、应用Java领域中最新成果、面向B2B的工作流解决方案。流程引擎基于BPEL业务流程规范和Web Service标准。Twister没有很大起色。

4)      ActiveBpel

ActiveBPEL 引擎是一个于今年7月发布的健壮的运行时环境,它能执行用户按BPWL4WS规范编写的业务流程。ActiveBPEL引擎由Active Endpoints公司开发和维护,该公司同时在它的多个商业产品中使用了该技术。ActiveBPEL由于有后台公司的支持，有一定的发展，但由于革新是个花钱的活，而且Active Endpoints没有足够的财力，所以ActiveBPEL发展也不迅速。

http://www.active-endpoints.com/active-bpel-engine-overview.htm

4.3独立于规范外

5)      OSWorkflow

非常灵活的工作流引擎，完全基于插件思想，可扩展性极强，基于状态。 OsWorkflow的版本更新也很慢，至今没有一个象样的流程定义工具，流程辅助功能也基本没有。

http://www.opensymphony.com/osworkflow/

6)      OpenWFE

OpenWFE 是一个java写的开源工作流引擎。
它由四个组件（服务器）组成：一个引擎、一个工作列表、一个反应器（自动参与者的容器）、一个web客户端（一个通用的web应用的例子）。

http://www.openwfe.org/

7)      jbpm

简介 ：基于JBoss+EJB的工作流引擎。 jBpm是tom baeyens编写的一个灵活可扩展的工作流管理系统。jBmp将工作流应用开发的便利性和杰出的企业应用集成（EAI）能力结合了起来。jBmp包括一个Web应用程序和一个日程安排程序。jBmp是一组J2SE组件，可以作为J2EE应用集群部署。

http://www.jboss.com/products/jbpm

5        开源工作流产品比较

5.1Ofbiz

ofbiz的主要精力不在于他的workflow engine上，而且他的workflow engine很难和其entity engine以及service engine分离，use all or use none. Ofbiz已经基本脱离了工作流领域，在该行业没有什么发言权；

5.2Osworkflow

osworkflow是一个轻量级的workflow engine，较容易和其他架构做整合；必须要使用他的User模型

Osworkflow的靠山是opensymphony。这个组织做出了很多的好东西如webwork2。

Osworkflow是FSM驱动，你把他类似理解为状态图就可以了。Osworkflow中的State是由step和status联合表达的，一个State就是一个step中的某个status；而state的转换由action来驱动，类似状态图中的event,因为一个event对应一个action嘛。

优点 ：

1.       工作流引擎可工作于JSP Container，EJB Container，WS Container。

2.       引擎支持自动任务和手工任务。

3.       工作流实例以及相关数据可以持久化，可以选择JDBC、EJB、Hibernate等持久化方式。

4.       具有工作流脚本图形编辑器。

5.       各种功能基于插件方式，易于集成已有系统。

6.       工作流可以调用Java、EJB、Bean Shell、BSF等功能。

7.       支持权限。

8.       定时任务调度。

9.       适用于Web和非Web环境。

缺点 ：

1.       非标准脚本语言，工作流引擎对于自动任务支持尚不完善。

5.3Jbpm

jbpm 相对osworkflow复杂一点，但是其开发团队比较active。必须要使用他的User模型

jBPM ，全称是Java Business Process Management，是一种基于J2EE的轻量级工作流管理系统。jBPM是公开源代码项目，它使用要遵循 Apache License。

jBPM 最大的特色就是它的商务逻辑定义没有采用目前的一些规范，如WfMC's XPDL, BPML, ebXML, BPEL4WS等，而是采用了它自己定义的JBoss jBPM Process definition language (jPdl)。jPdl认为一个商务流程可以被看作是一个UML状态图。jPdl就是详细定义了这个状态图的每个部分，如起始、结束状态，状态之间的转换等。

jBPM 的另一个特色是它使用Hibernate来管理它的数据库。Hibernate是目前Java领域最好的一种数据持久层解决方案。通过Hibernate，jBPM将数据的管理职能分离出去，自己专注于商务逻辑的处理。

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

Jbpm 它结合应用了状态图+活动图+PetriNet的知识，而且，这里的活动图还是UML2.0版的。UML2.0的活动图中，节点不叫活动（Activity）而叫动作(action)，活动成了一个高层次的概念，它包含一个动作序列。一个活动图展现一系列的动作，这些动作组成了活动。Jbpm把action也改名了，称为state。Jbpm使用的状态图的概念有transition/event等。Jbpm来内部实现中还采用了PetriNet的概念，如token,signal等。

jBPM 被jboss收购后，jboss又被redhat收购，最初只实现了jPDL标准。

我们看看jBPM的野心：JBoss jBPM is a powerful workflow, BPM, orchestration (BPEL) and web application pageflow platform that enables the creation of business processes that coordinate between people, applications and services.明眼人应该已经看出来，jBPM融合了4大功能：Workflow，BPM，BPEL，PageFlow。

jBPM 本身是个功能全面的Workflow Engine，它自己有个BPEL扩展，采用jboss Hibernate实现，集成了jboss seam，规则引擎准备采用jboss rules，并准备集成jboss Messaging。Redhat已经收购了jboss，也就是说，以后你安装好redhat，就可以直接使用jBPM提供的服务了。

优点：

1.         安装简便，支持动态部署，工作流引擎支持交互界面的脚本，适用于WEB环境。

2.         支持EJB，但不一定需要EJB。 jBPM

3.         使用简单，易上手，源代码也易读，作嵌入式工作流是一个很好的选择。 jBPM

5.4Shark

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

Shark 的特性：思想保守，不思进取，排除异己。Shark是Enhydra系列产品中的一个，所以它的持久层采用了Enhydra DODS来实现。基本上没有什么人来使用DODS，也没有人了解它，而且它表现并不很优秀。在Shark1.0阿尔法版中，有外界人士提供了Shark的Hibernate实现；但Shark并不把该实现集成到产品中，也不计划在将来的版本中转向/支持Hibernate。这样并不符合开源思想，也会在使用和推广中出现很多问题。

Shark 的版本更新比较慢，代码的更新也没有按照开源的方式来完成。Shark在1.0后直接发展到2.0，让人大跌眼镜。

Shark2.0 后，有很多组件不开源了，而且都是只有DEMO，如果要用，需要付费。Shark开发的系统目前仍然在运行。

5.5ActiveBPEL

基于多个不同应用内的工作流引擎技术，它的技术实现要依靠web service来进行实现。推荐的实现组合是：AXIS+J2EE+ACTIVEBPEL ，我的J2EE是STRUTS+SPRING+HIBERNATE　的MVC框架，使用SPIRNG和AXIS组合使用。业务流程由BPEL4WS生成，主要有两个文件.bpel和WSDL，由ACTIVEBPEL服务器分析并与AXIS服务交互。

ActiveBPEL 组织是一个主导ActiveBPEL引擎技术的开源组织。ActiveBPEL引擎是一个健壮的运行环境，它能执行用户按BPWL4WS规范编写的业务流程。

ActiveBPEL 引擎由Active Endpoints公司开发和维护，该公司同时在它的多个商业产品中使用了该技术。Active Endpoints公司相信开源模式对于培养社团兴趣和推广标准非常有用，所以建立了该开源产品。

Active Endpoints 公司宣称ActiveBPEL引擎有如下关键优势：

1)       完整性 ：ActiveBPEL引擎完整地实现了BPEL4WS标准。

2)       方便性 ：ActiveBPEL引擎除了完全实现标准，还在包的发布，流程持久化，事件通知等方面加强了方便性。

3)       持续性 ：Active Endpoints公司是一家商业公司，能持续地对ActiveBPEL引擎给予支持。

该新版本中主要的提高是对即将推出的WS-BPEL 2.0的扩展支持。

 

第 III 条                         工作流国内局势

1        工作流组织

国内工作流软件公司其实是比较多的，但99%发展都不太好。工作流项目竞争激烈，公司层面也是按最初级的项目开发思路一个一个为用户定制。这样开发速度慢，成本高，也不能适应用户需求多变的特性。部分比较懂行的用户会要求用工作流方式来开发，这样逼迫部分公司采用工作流。

普元的EOS应该也算和工作流有一定关系，它有两个特性是我比较认同的：构件化，图形化。构件化在我而言应该是组件化，不完全是EOS的构件的概念。图形化在jBPM的GOP中已经得到很好的体现。但有一点我认为普元没有做好：人性化。这里的人性化并不指其他，而是吸引技术人员来使用本产品的意思。EOS得了一大堆奖，都是没有用的东西，也就能够写在招标书中给人看看；但这样的产品都有一个特点：最后是技术人员来使用。表面上是企业管理人员拍板决定买谁的产品，但本质上还是要看技术人员的（核心的那几个技术人员）。组件化+图形化+人性化+开源化。这里的开源化是指对部分组件开源，并且其他部分组件是技术人员可以自己扩展的。

Joinwork是针对J2EE/Java应用开发人员，主要以嵌入上层业务应用的方式部署使用的工作流软件...http://www.joinwork.net/

2        国内开源工作流

    Willow是huihoo组织下的开源工作流产品，当属XML的吧，文档不多。

    AgileFlow（http://sourceforge.net/projects/agileflow）的旧版是用来给工作流新人学习，快速入门；而新版将是基于jBPM之上，实现一个产品，目标是提供给工作流项目实施人员，让他们快速简单地使用jBPM来为客户服务。

 

第 IV 条                             开源工作流产品占有率趋势

1.       2004年前，国内的工作流引擎使用率最高的是osworkflow;

2.       到2004年底，Shark就占有了明显的优势地位，分析有如下原因：

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

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

3.       jbpm3支持bpel4ws的核心部分。所以，Shark在引领风骚数百天后，被jbpm3赶下第一宝座。