1．引言

2004年9月，笔者在网络发布了《工作流之大局势》的最初版本(http://blog.csdn.net/hongbo781202/archive/2004/09/26/117271.aspx)，技术界朋友们反响非常强烈：很多网站和博客做了转载；在之后的约1年中，我的邮箱每天能够收到超过10封朋友们的来信（由于时间和精力关系，约有一半的比较简单的问题没有回复，笔者对此深表歉意），到现在我仍然不时收到这样的来信；我的博客上的留言也非常多，到写稿时笔者看到该篇文章的最新留言时间是2006-06-06 22:38:00 。

但在技术发展日新月异的今天，一篇综述性文章竟然能够顽强地存活2年，让我时刻心中紧绷一根弦：我该重新写点什么了。于是，就有了今天的这篇《工作流之大局势(2006版)》。

2． 保皇派局势

笔者在上次发文时，有把工作流按是否开源划为大户和寒门两类。时至今日，我想大家都同意这样的一个观点：漠视开源是非常可怕的一件事情。所以本文中不再按这样的标准进行划分，本人目前把工作流产品分为如下4大派别：保皇派，革新派，自由派，融合派。下面先说保皇派局势。

2.1 保皇派分支

笔者最早知道四爷党OMG是6年前学习CORBA的时候开始的，当时对CORBA抱着顶礼膜拜的心态，《CORBA》这门课程是我研究生阶段唯一的每节课都去听的课程。2003年做电信行业的软件开发，才了解到CORBA的日渐没落的行情。CORBA的两大特点是：思想超前，极不实用。OMG的Workflow Management Facility也秉承了这两大特点，在追求高效轻量的今天，它的没落也就是顺理成章的事情了。

八爷党BPML在保皇派本就处于很尴尬的地位，在长时间被太子党和革新派围攻后，基本上销声匿迹。

太子党XPDL是保皇派剩余力量最强的党，虽然地位一步步削弱，但仍然在靠以前搜刮来的钱财和宝玉维持自己的生活。

2.2 保皇派人物

上次的《工作流之大局势》发表后，OBE很快就不见了影踪；Ofbiz已经基本脱离了工作流领域，在该行业没有什么发言权；下面专门说说Shark。

笔者从Shark发展的早期就在国内力推它,有幸成为Shark工作流引擎在国内的主要推广者之一。但我很快就看到了Shark的保皇特性：思想保守，不思进取，排除异己。Shark是Enhydra系列产品中的一个，所以它的持久层采用了Enhydra DODS来实现。基本上没有什么人来使用DODS，也没有人了解它，而且它表现并不很优秀。在Shark1.0阿尔法版中，有外界人士提供了Shark的Hibernate实现；但Shark并不把该实现集成到产品中，也不计划在将来的版本中转向/支持Hibernate。这样并不符合开源思想，也会在使用和推广中出现很多问题。笔者在使用Shark时就花了一定的时间来研究学习DODS，本期望后续版本中会支持已经全球流行的Hibernate，但等来的是一次又一次的失望。

《工作流之大局势》发表后，Shark发展非常快，但我基本是在Shark发展的顶峰转向其他的产品（当然也没有忘记跟踪它的发展情况）。Shark的版本更新比较慢，代码的更新也没有按照开源的方式来完成。Shark在1.0后直接发展到2.0，让人大跌眼镜。

令人好笑的事情，是收到技术朋友的mail说，不知道到哪里下载Shark的最新版。我知道怎么样去下载，但开始也是费了周折的。从这个也可以看出它从1.0后的发展太不职业化，让人不放心。Shark2.0后，有很多组件不开源了，而且都是只有DEMO，如果要用，需要付费。因为不想付费的原因，有朋友准备重新下1.0来学习，结果又跌了一次眼镜：1.0不知道上哪里去下了。

虽然我们使用Shark开发的系统目前仍然在运行，虽然很多人因为我在《工作流E起来》开的Shark版块知道了HongSoft这个名字，但我以后不准备再使用Shark。

3． 革新派局势

3.1 革新派分支

WSCI党的几个领导人物如BEA/SAP/SUN等均已经投靠到BPEL党，WSCI基本上没有了发展的空间。

ebXML党只能在电子商务领域活动活动拳脚，由于它的体系结构的全面性，目前还有部分学术界人士在研究ebXML，但应该不会有很大起色。

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标准的领导者行列。WSCI被瓦解，而WS-BPEL2.0的草案也在当时被纳入议事日程。

3.2 革新派人物

革新派中的几个领导者都是同时支持BPEL和非BPEL的，他们的产品并不独立地实现BPEL，我们称这样的产品为融合派，融合派基本是以前的革新派中的大户人家。本文的革新派指比较独立的BPEL或者ebXML实现，这样的产品基本是以前的革新派中的寒门。

由于这些寒门没有财力支持，发展都比较缓慢。Open ebXML处在不仅没有财力，连关心的人都没有的悲惨景地。Twister没有很大起色。ActiveBPEL由于有后台公司的支持，有一定的发展，但由于革新是个花钱的活，而且Active Endpoints没有足够的财力，所以ActiveBPEL发展也不迅速。

4． 自由派局势

自由派并没有形成力量比较强大的党，都是在小打小闹，发展并不太好。OsWorkflow的版本更新也很慢，至今没有一个象样的流程定义工具，流程辅助功能也基本没有。OpenWFE的关注点也少得可怜。

YAWL在学术界有部分人在做研究，因为它是基于PetriNet实现的产品。

jBPM被jboss收购后，jboss又被redhat收购，目前已经进入了融合派角色。

5． 融合派局势

融合派是新发展出来的派系，它的来源有两个：一是革新派中的大户人家，如IBM；二是自由派中的活力成员，如jBPM。下面以点带面，分别讨论。

5.1 IBM Websphere系列产品

说到IBM的业务整合野心，我们不得不提起2002年IBM的两次收购。2002年1月，IBM用1.29亿收购CrossWorlds软件公司，宣称要通过CrossWorlds公司的软件来增强IBM的WebSphere中间产品线的自动商务处理程序。9月，IBM又收购了软件制作公司Holosofx,并计划将Holosofx的技术集成到自己的WebSphere商业集成软件中。

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

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

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

5.2 BEA AquaLogic系列产品

我在BEA的UG活动(http://dev2dev.bea.com.cn/usergroup/2005111947.html)上知道AquaLogic产品线。BEA本身就是一个收购型公司，它收购的产品均为自己公司创造了巨大的财富和影响力。就在今年的3月1日，BEA收购Fuego，Fuego的产品组合将加入到BEA的AquaLogic产品阵容中，将成为BEA新的AquaLogic商业服务互动产品线的基础。

在收购Fuego前，BEA已有的过程处理工具对面向服务技术并不是特别适合，而面向服务技术是AquaLogic的根基。BEA董事会主席兼首席执行官Alfred Chuang说，BPM细分市场是SOA软件市场增长最快的部分。他说，把Fuego加入到BEA的AquaLogic产品线意味着BEA能够供应集业务流程、应用和传统环境于一身的统一的基于SOA的软件。

如果你准备参加BEA的UG活动，请记住向上第3行中的Chuang的名字，说不定可以拿到大的奖品，呵呵。

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

5.3 Microsoft Biztalk Server

我没有用过Biztalk Server，看了资料说它的市场占有率为约17%。

5.4 Oracle BPEL Process Manager

不知道有多少人用过Oracle内带的工作流工具，我是用过，但没有什么感觉。至到Oracle BPEL发布后，才发现它的工作已经是非常超前了。Oracle在融合派中是最早推出BPEL编辑器和引擎的产商，功能全面而且非常的稳定，可惜的是Oracle公司的所有产品目前和开源没有任何关联。

5.5 jBoss jBPM Server

在融合派中，目前只有jboss jBPM是开源产品。jBPM是从自由派发展而来，最初只实现了jPDL标准，本人在2005年写过jBPM在传统工作流技术方面与其他开源工作流产品的比较(http://blog.csdn.net/hongbo781202/archive/2005/02/28/304751.aspx)。

我们看看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提供的服务了。这样的特性不得不让人倒抽一口冷气。

本人从jBPM2.0开始就研究它的代码，跟踪技术发展情况，当时没有想到它的发展能够如此迅速。本人把jBPM3.0的引擎部分做了一些改造，也用到了一些特殊行业中。从2006年1月开始，陆续有几个工作流项目软件公司请我为他们做工作流的技术和使用培训，我都是推荐的jBPM。这些公司中有的是使用过Shark后，没有完全把握正确的产品开发方向的。在后续的项目情况跟进中，使用jBPM的均效果不错。

6． 国内局势

6.1 工作流组织

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

部分比较懂行的用户会要求用工作流方式来开发，这样逼迫部分公司采用工作流。有的公司会指定某个项目组成员：给你2周时间，研究某某引擎，学习怎么样使用。这样的效果可想而知。

我在给上海复旦金仕达做工作流培训的过程中发现，医疗软件行业很多公司对工作流能够做什么不能够做什么没有基本的认识，工作流在该行业的应用还很少，复旦金仕达是行业中比较早的有工作流需求的公司，可能和他们公司在行业中的地位有关系。

华信邮电咨询设计研究院有限公司研究发展中心的徐总是个对技术人员非常重视的人，他的很多对工作流技术的见解是连我这样做了好多年工作流技术的人都自叹弗如的。他们以前使用的是Shark引擎，现在在工作流和业务流程管理的结合方面有些比较不错的工作，这个其实应该是工作流发展后的最主要的工作和最符合用户高级需求的工作。

普元的EOS应该也算和工作流有一定关系，它有两个特性是我比较认同的：构件化，图形化。构件化在我而言应该是组件化，不完全是EOS的构件的概念。图形化在jBPM的GOP中已经得到很好的体现。但有一点我认为普元没有做好：人性化。这里的人性化并不指其他，而是吸引技术人员来使用本产品的意思。EOS得了一大堆奖，都是没有用的东西，也就能够写在招标书中给人看看；但这样的产品都有一个特点：最后是技术人员来使用。表面上是企业管理人员拍板决定买谁的产品，但本质上还是要看技术人员的（核心的那几个技术人员）。后来，EOS做了很多亲近技术人员的事情：在《程序员》这个靠近技术人员的地方做广告，搞EOS产品体验大赛等。但我认为效果都不好。我认为可行的思路是什么呢？

我在2004年和信雅达公司的石总交流的时候说过工作流产品开发方面自己认为可行的思路（当时我本人还不知道普元公司）。那就是组件化+图形化+人性化+开源化。这里的开源化是指对部分组件开源，并且其他部分组件是技术人员可以自己扩展的。然后在这部分基础上，组织产品体验大赛（决不是挂个网页在那里而已）。我很需要这个方面的讨论，非常欢迎大家在这个方面和我进行讨论，并可向我索取当时我给信雅达公司的石总发的mail中的这部分技术内容。

6.2 工作流人员

可能与行业背景有关系，国内工作流技术人员的生存环境不容乐观。公司层面一般以普通的技术来看待工作流技术，不认为这个是和行业认知密切相关的。所以很多朋友来mail或者在QQ群内讨论就是很急的寻求什么什么技术，老板只给了2周时间等等。其实我认为工作流是一个技术的同时，更认为它是一个行业，是需要积累的。

部分技术人员自己也有问题，只是浮在表面，不能深入进去，所以使用工作流都成问题。还有很多人，因为这个行业不好做，在做了很多年有了一定的经验后，转到其他行业的，不能坚持下去，非常可惜。

6.3 国内开源工作流

Willow是huihoo组织下的开源工作流产品，当属保皇派的吧，虽然文档不多，我了解也不多，但我表示支持，希望国内的工作流技术和组织的发展都越来越好。

AgileFlow是本人发起的，为什么要做这样一个产品，原因写在这里：http://blog.csdn.net/hongbo781202/archive/2004/11/02/163718.aspx。为了支持国内的开源技术，我最初在cosoft申请建立了AgileFlow，但现在cosoft已经瘫痪，让人无比的失望。我现在已经在sourceforge申请了AgileFlow的空间(http://sourceforge.net/projects/agileflow)，以后的代码发布和版本更新将都到sourceforge来进行。AgileFlow的旧版是用来给工作流新人学习，快速入门，不会从sourceforge删掉；而新版将是基于jBPM之上，实现一个产品，目标是提供给工作流项目实施人员，让他们快速简单地使用jBPM来为客户服务。

愿国内外工作流技术工作者都好!