工作流产品三大系列

最新推荐文章于 2019-01-07 23:36:35 发布

jbpm_o

最新推荐文章于 2019-01-07 23:36:35 发布

阅读量469

点赞数

分类专栏： bpm产品和厂商文章标签：工作 JBPM Workflow Websphere JBoss

bpm产品和厂商专栏收录该内容

3 篇文章 0 订阅

订阅专栏

作者：杨洪波

工作流一直是实施BPM的重要环节，以往的开源与闭源的划分已经不适合如今的工作流局势，开源已经渗透到了各个领域，如今的工作流已是三分天下的大局。

图1 工作流参考模型基本部件接口

一般在划分工作流产品时，会按是否开源分为商业产品和开源产品两大类。时至今日，业内人士都会同意这样的一个观点:漠视开源是非常可怕的一件事情。所以本文中不再按这样的标准进行划分，而把工作流产品分为如下三大系列:纯工作流系列、BPM系列和融合系列。

纯工作流系列

工作流管理联盟（workflow management coalition, WFMC)定义了工作流参考模型，图1描述了该模型的基本部件和基本接口。

纯工作流系列的产品都是遵循工作流参考模型的，包括OMG/BPMI等组织制定的标准也是如此，很多人都知道OMG是从CORBA开始的。CORBA的思想很超前，但不是很实用。OMG的Workflow Management Facility也秉承了这两大特点，在追求高效轻量的今天，它们注定不是很顺应发展。

BPMI在纯工作流系列处于很尴尬的地位，现在已经销声匿迹，当然它的BPML与XPDL做到了协同发展。XPDL是纯工作流系列剩余力量中最强的，虽然地位一步步削弱，但仍然在靠以前积累的用户数维持着发展。

纯工作流系列并没有产生比较有代表性的作品，而且发展也并不是很好。OsWorkflow的版本更新也很慢，至今没有一个很规范的流程定义工具，流程辅助功能也基本没有。OpenWFE的关注点非常的少。YAWL在学术界有部分人在做研究，因为它是基于PetriNet实现的产品。jBPM被jBoss收购后，jBoss又被Red Hat收购，目前已经进入了融合派角色。OBE很快就不见了影踪。Ofbiz已经基本脱离了工作流领域，在该行业已经没有太多的发言权。下面专门对Shark进行讲解。

Shark是Enhydra系列产品中的一个，所以它的持久层采用了Enhydra DODS来实现。基本上没有什么人使用DODS，也没有人了解它，而且它的表现并不很优秀。在Shark1.0阿尔法版中，有外界人士提供了Shark的Hibernate实现，但Shark并没将该实现集成到产品中，也无计划在将来的版本中转向支持Hibernate。

这不是很符合开源的思想，也在使用和推广中出现了很多的问题。很多人在使用Shark时就花费了很多时间研究学习DODS，本期望后续版本中会支持已经全球流行的Hibernate，但等来的是一次又一次的失望。Shark的版本更新比较慢，代码的更新也没有按照开源的方式完成，k在1.0版本后直接就发展到了2.0版本。

BPM系列局势

BPM系列标准发展非常快，在三年时间内出现了9大标准，如图2所示。

WSCI的几个领导人物如BEA/SAP/Sun等均已经投靠到BPEL，WSCI基本上没有了发展的空间。ebXML只能在电子商务领域发展，由于它的体系结构的全面性，目前还有部分学术界人士在研究ebXML，但应该不会有很大起色。

BPEL在这两年得到了大力的发展。2002年8月9日，BEA/IBM/MS提出BPEL标准。

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的草案也在当时被纳入议事日程。

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

由于这些寒门没有财力支持，发展都比较缓慢。Open ebXML处在不仅没有财力，也缺乏用户的境地。Twister依然没有很大起色。ActiveBPEL由于有后台公司的支持，有一定的发展，但Active Endpoints也缺乏足够的财力支持，所以ActiveBPEL发展也不迅速。

融合系列产品局势

融合系列是新发展出来的派系，它的来源有两个:一是BPM系列中的大户人家，如IBM;二是纯工作流系列中的成员，如jBPM。下面以点带面，分别讨论。

1.IBM Websphere系列

说到IBM的业务整合野心，我们不得不提起2002年IBM的两次收购。2002年1月，IBM用1.29亿收购CrossWorlds软件公司，宣称通过CrossWorlds公司的软件增强IBM的WebSphere中间产品线的自动商务处理程序。

2002年9月，IBM又收购了软件制作公司Holosofx,并计划将Holosofx的技术集成到自己的WebSphere商业集成软件中。收购后，IBM对原有的Websphere系统体系结构根据“On Demand”的要求进行了调整，图3是IBM对Websphere平台的描绘，从中我们可以看到IBM公司对于WebSphere平台的设计蓝图。

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

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

目前，IBM的流程管理工具是市场上占有率最高的，大致为24%左右。

2.BEA AquaLogic系列

BEA收购了一系列的公司，它收购的产品为BEA创造了巨大的财富和影响力。在2006年的3月1日，BEA收购了Fuego，Fuego的产品组合将加入到BEA的AquaLogic产品阵容中，成为BEA新的AquaLogic商业服务互动产品线的基础。现在，Fuego已经发展成了BEA Aqualogic家族的Workspace产品线的BPM Suite系列产品，支持BPMN/BPEL/UML等标准实现。

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

3.Microsoft Biztalk Server

使用过BPEL的朋友都知道，BPEL的前身是WSFL和XLANG，其中XLANG是Microsoft提出的规范。Microsoft Biztalk Server就是依赖于XLANG实现的产品。Microsoft Biztalk Server 2000基本是XLANG的完全实现;Microsoft Biztalk Server 2004中加入了HWS(Human Workflow Service)，实现了人工交互的流程，并且加入了Infopath表单实现表单定制。但是HWS的使用效果并不太好，在Microsoft Biztalk Server 2006中，没有对HWS做任何的改进。

Vista中Microsoft Biztalk Server是基于WWF实现的，按计划去掉了其中的HWS功能，可见BPEL与HWS的发展还是不太协调。

4.jBoss jBPM Server

在融合系列产品中，目前只有jBoss的 jBPM是开源产品。jBPM是从自由派发展而来，最初只实现了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。通过这四大功能，实现了与流程开发人员，旧有系统，管理员和普通用户的协调交互，如图4所示。

jBPM自身有个功能全面的Workflow Engine，有个BPEL扩展，采用jBoss Hibernate实现，集成了jBoss seam，规则引擎准备采用jBoss rules，并准备集成jBoss Messaging。

Red Hat已经收购了jBoss，也就是说，以后安装了Red Hat，就可以直接使用jBPM提供的服务了，这样的特性也为jBPM的普及起到了促进作用。

5.国内工作流

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

部分用户会要求开发公司使用工作流方式进行开发，这样迫使软件公司采用了工作流开发模式。但由于时间、资金投入、重视程度等因素的制约，一直发展非常缓慢。

可能与行业背景有关系，国内工作流技术人员的生存环境不容乐观。公司层面一般以普通的技术来看待工作流技术，不认为这个是和行业认知密切相关的。

其实工作流是一个技术的同时，更是一个行业，它是需要积累的。部分技术人员自己也有问题，只是浮在表面，不能深入进去，所以使用工作流都成问题。还有很多人，因为这个行业不好生存，在有了很多年的工作经验后，转行到其他行业，也是非常可惜的。