工作流之大局势 (2006 版 )

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 来为客户服务。

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

                                                                                                                                                                                                                    杨洪波(HongSoft)