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所围绕的业务流程及流程整合应用是一个发展趋势。

      JBoss 宣布发布JBoss Transactions 4.2 和JBoss Rules 3.0 新版本。

      JBoss Transactions 是一款开源的分布式事务管理平台，原来是属于Arjuna 的产品。Arjuna Technologies 公司的事务引擎已有20年的历史，并且已经被升级到可以使用Web服务事务。2005，JBoss 年通过收购Arjuna 而获得此项技术。

      JBoss Rules 是JBoss的企业规则引擎产品，前身是大家都熟悉的Drools。2005年12月，JBoss的创始人兼总裁Marc Fleury在巴塞罗纳举行的“JBoss 世界”的会议上发表的主题演讲中宣布收购Drools。 从此，Drools 项目以及该项目的主要负责人Mark Proctor 都加入了JBOSS。

下载地址：http://jboss.org/jbossBlog/blog/mlittle/?permalink=JBoss_Transactions_4_2_Released.txt

因为的确不好回答，而且这样问的人也太多了。但来的mail中也有问的问题非常不错的（其中包括部分老总级管理人员的问题），下面这个就是

HW 的一个人的来信交流，为了privacy起见，删掉了一部分内容。

1 、

HW

您好：我是工作流方面的兴趣爱好者，当然也只是一个新手，请问BPEL有没有什么比较好的全面的文章推荐？（除了BPEL2.0的规范外）还有就是我想找一个开源项目进行研究，你觉得activeBPEL怎么样？可以推荐一下吗?

HongSoft

您好！BPEL虽然也发展了好多年了，现在使用也开始多了起来，但目前的确没有什么比较全面的文章。开源项目方面，我也跟踪了很多BPEL项目，activeBPEL我也看了很久，目前不看好它。现在BPEL方面我在全力使用jBPM_BPEL项目。应该说jboss旗下的几个项目发展都还不错，hibernate/jboss seam等，jbpm现在也被spring纳入支持列表中。

2 、

HW

您好：非常感谢您的回信，据我所知现在工业界（如IBM,Microsoft,BEA, Oracle等）都非常推崇BPEL，我想问一下你觉得这个语言是否真的很有潜力成为工业界中业务集成方面的标准语言？那WS-CDL这项标准你怎么看待它？会广泛的被用到吗？还有就是关于activeBPEL，能否帮忙讲解一下它有什么缺点啊？相反jBPM_BPEL它有哪方面的优点？>是否有分布式工作流技术的项目啊，（个人感觉一个集中引擎总会产生一些效率之类的瓶颈问题）？是这样的，我们在考虑能否把工作流技术运用到电信业务的集成系统中去，电信业务对系统容量，实时性和稳定性方面要求非常高，读了您的一些文章，感觉你在这方面经验非常丰富，所以向你请教了，问了这么多问题，呵呵，假如对口的话，能够进行一些合作最好了，还有就是不知道你现在是否听说过IBM及Microsoft都在推SOA，你他们推的产品和jBPM_BPEL是否有些竞争关系？。谢谢了！！打扰了！呵呵

HongSoft

您好：

1 ） WS-CDL的问题

　　CDL的全拼是Choreography Description Language，顾名思义它是用来描述Choreography的。它和BPEL的区别是：a)CDL提供一个在所有的参与者间交换的形式化描述，BPEL提供的则是本参与者对外的形式化描述定义；b)CDL提供一个全局的消息交换协议。

　　而BPEL是描述“我和其他人”通信的消息交换协议。理论上看CDL比BPEL更好，但实际上它有2个缺陷：a)业务集成需求的产生，是因为工业界中已经存在的很多的legacy系统，这些系统已经按它自身的业务规则，实现了自己的功能；在这样的情况下，突然安插一个Choreography进来，必然对legacy系统的实现和稳定性产生非常大的影响，这个是业务集成领域应该避免的。b)BPEL从工业界产生，被世界各大公司支持；而CDL的时间和支持力度，则明显不足。

　　从上面的比较和目前工业界的实际情况看，我认为BPEL肯定会成为工业界中业务集成方面的标准语言。

2 ） BPEL的问题

　　activeBPEL和jbpmBPEL的比较，应该说可以从很多方面来看。从系统结构，技术实现等技术角度来看，activeBPEL比jbpmBPEL要差；jbpmBPEL在jboss旗下，它的技术实力要可靠，后续支持也要可靠；active本身是家商业公司，担心它的开源程度和信心不够...等等。

3 ） 工作流的问题

　　我们用Shark和jBPM就已经做过分布式工作流技术的项目，项目有用到电信的故障运维业务中去，也有用到700W用户的网站项目中去。当然是否用分布式工作流技术，还需要具体分析。IBM及Microsoft都在推SOA，这个应该说和所有的BPEL产品都有一定的竞争关系，但我认为更大的是合作关系。SOA是套架构，我们要做的BPEL产品只是这个体系中的一个组成。IBM及Microsoft都有太多自己特性的东西是客户不一定想要的，比如对数据库的指定，在电信领域指定用DB2或者SQL Server就不太可能。在这样的情况下，我们可以理解为IBM及Microsoft帮我们铺路，我们在最少投入的情况下，力求达到最大的产出。

　　 我说的几点是我个人理解，不知道能否让您明白。 希望多交流。

3 、

HW

您好：非常感谢您的回复，考虑到电信业务的系统容量，实时性方面的要求，我们对分布式的工作流很感兴趣，想具体了解一下分布式工作流技术如何运用到业务集成，呵呵，准确的说应该是基于BPEL的分布式引擎之类的东东（因为这边的业务集成主要涉及到如何灵活的快捷的进行业务组合，说工作流可能不是很准确，呵呵），能否详细讲解一下分布式工作流引擎的一些工作原理之类的？呵呵。谢谢了。说白了就是希望利用已有的各种service的能力，加快业务的开发和部署时间（web service是一个不错的选择，但目前为止性能方面还是个比较大的问题，但考虑到各大IT厂商对其的关注度和投入，基本上也是我们非常重视的一个选择），同时又希望保证系统的各种性能，主要还是系统容量和实时性。希望能够加强交流，合适的话能够进行一些合作最好，呵呵。期待您的回复。打扰了！

HongSoft

您好：您说到“分布式工作流引擎的一些工作原理”，这里分为2类：

1 ） 非BPEL类： 就是按WFMC的标准，架构的系统为 一个工作流执行服务=多个工作流引擎，这个是标准实现，每个引擎的具体架设方法是不同的。

2 ） BPEL类  ：这个方法本来就是分布式的，基本是强制性的，不需要我们自己去考虑。

您说到的“加快业务的开发和部署时间”是个比较大的问题，具体可以参考一下我做的smart系统，基本上把开发时间降到了最低，但有一定的局限性；其他的方法也可以一起讨论，和和。

4 、

HW

　您好：不是很明白您说BPEL这个方法本来就是分布式的。。。

可能大家对分布式的理解不一样吧？由BPEL所组合的各种service由于是统一的web service接口，天生就是分布式的，但所有的控制逻辑都停留在BPEL引擎上，在这种情况下，我们担心会产生瓶颈，或许在企业内部的系统集成方面不会出现这种问题，但象电信业务，如短消息，预付费这种本身对性能要求非常高的情况下是否会出现瓶颈？呵呵。对BPEL这块接触的还不是很深入，呵呵，打扰了。

HongSoft

　　您好：在BPEL中，service可以按coordination方式组合，在这个方式下，BPEL引擎一般不只一个，而是多个BPEL引擎的协同。一般来说是按功能进行分解为1，2，3号引擎（这三个引擎的功能是不同业务的实现）；然后如果3号的负载特别重，可以分为3.1和3.2号子引擎（这两个引擎的功能是同一个业务的实现）。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1069051

        BPM概念與BPMS之相關技術是架構在Web Services/SOA之基礎上，未來不僅會改造企業建構IT 系統的方法，也同時改變企業營運模式，或稱商業流程的執行方式。對廠商而言，誰能主導流程定義與執行的相關標準誰就是市場的贏家。

        本篇將要探討，目前有哪些標準與主導的廠商陣營？這些廠商陣營如何既結盟又競爭？又誰能一統江湖而成市場最大贏家？

BPM與SOA

        BPM藉由明確表式的流程定義將耦合鬆散的一群獨立服務串聯成新的商業流程，並讓不同的BPMS能相互溝通與執行企業流程。因此標準流程定義扮演著BPMS技術中的核心角色。

        流程定義語言是一種正規(Formal)語言，可以將企業各種流程表示成一種可執行流程(Executable Process)形式的正規模型。

        由於BPM擴展了Web Services的應用，所以能乘駕在巨大的Web Services發展浪潮御風而上。BPM的相關標準大都用來定義BPM和Web Service如何整合與部署以達成企業任務。多家軟體大廠和標準組織都架構在Web Services相關標準的基礎上，也就是說，這些標準都延伸了XML、SOAP、WSDL、和UDDI幾項技術規格。

      目前冒出的BPM相關標準為數不少，大家較為熟悉的有WfMC's XPDL (XML-based Process Definition Language) 、BPMI's BPML (Business Process Modeling Language) 、還有ebXML's BPSS (Business Process Specification Schema) 。除此之外，還有由廠商結盟的陣營，如BEA、 Microsoft、與IBM聯合制定的BPEL4WS (Business Process Execution Language for Web Services，簡稱BPEL)，以及由Sun Microsystems, SAP, Oracle, Italio與其他公司共同制定的WSCI (Web Service Choreography Interface，網路服務編排介面) 。

      這些標準都是利用活動(Activity)作為流程定義之基本元件，每一個活動伴隨一個實體相關資料 (Instant-Relevant Data)，作為流程傳遞的邏輯(Routing Logic)評估條件，在BPML 稱property，XPDL稱 Workflow-relevant data， BPEL 稱 Container。

      XPDL標準著重在工作分配(Distribution)的相關議題，例如如何指定活動執行所須的資源與應用程式。BPML 標準著重在定義Web Service的重要議題，如支援交易(Transactions) 與例外處理，定義特定訊息交換與事件處置的活動型態。BPEL標準的重點與BPML相類似。WSCI 標準著重在Web Service的Choreography，像是服務介面的行為。BPSS以ebXML 建議的UMM (UN/CEFACT Modeling Methodology, 模型化方法論) 為基礎，以便支援在企業間以各種交易行為(Business Transaction)組合成所謂的企業協同(Business Collaboration) 。

標準：群雄稱霸　西瓜偎大邊

      IT產業中，大者恆大是贏得業界標準地位的不變定律。百家爭鳴的戰國時代中，大家都希望成為產業的主流標準，因此為了獲得最後勝利，小型的標準組織會漸漸去依附大的國際標準組織並爭取這些組織的認可。透過大組織的力量將小組織建置的標準推行全世界，將可吸引更多的使用者、獨霸市場形成國際認可標準，而不再僅是規格。

      例如，微軟與IBM各自推出流程標準XLANG與WSFL (Web Service Flow Language)。但在2002年兩家大廠合作共同推出新規格BPEL4WS，並且向OASIS 標準組織提出提案報告，最後也獲得OASIS認可的標準。Sun Micro及Oracle合作的廠商陣營為了推動WSCI，將這個規格標準送往W3C，並都參加了W3C 的Choreography工作小組。同時BPMI組織也向正在研究企業流程標準的OMG提案，希望OMG直接採納它們制定的標準或是與OMG即將訂出的標準可以相對照。

      從許多跡象顯示，目前顯然是BPEL較佔上風。例如，今年WfMC在義大利舉行的技術大會中，與會廠商談論的聚焦從去年的BPMN (Business Process Modeling Notation by BPMI) 轉移到BPEL。今年SAP和Intalio在支援WSCI之外，也決定支援OASIS的BPEL。包括Siebel在內的20幾家廠商也計畫採納BPEL。此外，Oracle今年在Java One發表了以BPEL為基礎的流程模型化工具 (Modeling Tool) 以及工作流程自動化軟體。

多方壓寶？大和解？

      同時我們也可以觀察到一些有趣的現象：廠商同時在不同的聯盟支援兩個不相容的的標準。所以，越來越多的的BPM產品都可以支援多個企業流程語言標準，以避免讓其產品在一群複雜且自成一派的標準中成為孤島。

      不過這也不是無解問題，因為各陣營也出現大和解之勢，尋求標準間之互補性與互通性，讓差異減至最小，同時避免出現不相容的兩套標準。像是今年昇陽和甲骨文藉著參加OASIS BPEL的會議，試圖推動W3C工作小組和OASIS之間的合作，解決兩個重複的標準。甲骨文已經正式加入OASIS BPEL技術委員會，昇陽也有意加入技術委員會。IBM、Oracle、BEA、Sun Microsystems同為WfMC及BPMI會員，但IBM、BEA與微軟卻也積極推動BPEL。

      到最後，哪一個BPM標準會勝出還很難說，雖然BPEL目前較具有冠軍相，不過我相信還需要一番較勁。

      BPM標準涵蓋的範圍相當廣泛，所涵蓋的BPM生命週期也不盡相同。彼此之間有些重疊、又有些相關分類架構，如何清楚瞭解這些標準用途、定位、與跟Web Service標準之關係？請見下回分解。

作者:
         國立交通大學資訊工程學系、學碩士，目前為國立交通大學資訊工程學系博士候選人。長年研究軟體流程及品質，曾獲選為IEEE Computer Society、Association for Computing Machinery(ACM)會員，現並兼任國際電機暨電子工程師學會(IEEE) Softwsare雜誌審稿委員。
http://taiwan.cnet.com/enterprise/column/0,2000062894,20000902,00.htm
http://taiwan.cnet.com/enterprise/column/0,2000062893,20093333,00.htm

工作流之大局势 作者把wfmc派叫做保皇党，web service派叫做革命党～轻松幽默又清晰透彻。看好bpel是未来发展的方向。

誰來一統BPM江湖 台湾的牛人，主推soa架构，比较看好bpel。

工作流现状 经典文章，对工作流领域为什么如此混乱和缺乏标准作了有益的思考。

      看起来，bpel似乎是workflow未来发展的趋势。但是，看看市场的现状，特别是国内，还是基于wfmc的工作流系统居多。为什么呢？这一方面是因为soa和web service的概念还是停留在曲高和寡的阶段；另一方面是bpel本身的问题：bpel更像一个web service composition，而不是business process definition。

      bpel做integration是很合适，但做workflow就好像差了一点点。看看bea的wli(weblogic integration)主页，对wli的定位首先是application integration，其次才是bpm。读过“Microsoft Biztalk 2004 vs IBM WebSphere Business Integration Server Foundation 5.1 ”之后更有这种感觉，bpel的用途在EAI，b2bi上比较强。

      bpel缺乏角色的概念，看看关于biztalk的这篇文章“谈谈工作流引擎及面向服务编程”，我也赞同作者的观点，即biztalk中的orchestration——亦即bpel的核心模型，对workflow，尤其是human workflow的支持很一般。若用bpel来实现workflow，非得外加一套角色管理不可，worklist不用说也要另外实现。

      写到这里，感觉自己对bpel的把握不够深。如何从workflow的角度理解bpel？我打算继续研究activebpel，同时开始看bea的wli。

2,BPML：
BPML是BPMI组织发布的规范。WfMC和BPMI在2002年6月26日宣布将合作制定业务流程和工作流标准，
即采用BPML来描述工作流过程，同时采用XPDL所定义的工作流模型。

3,ebXML：
ebXML是一组支持模块化电子商务框架的规范。ebXML支持一个全球化的电子市场，
它使得任意规模的企业通过交换基于XML的信息，不受地域限制地接洽和处理生意。
ebXML是联合国（UN/CEFACT，贸易促进和电子商务中心）和OASIS（结构化信息标准发展组织）共同倡导、全球参与开发和使用的规范。

4,WSCI：
好像是W3C的规范吧，Oracle,SAP等公司严重支持的。

5,BPEL4WS：
2002年8月9日，微软和IBM共同发布了一个新的规范BPEL4WS，融合了以前的XLANG和WSFL。
好像是提交到OASIS了，近两天出结果，和WSCI是对头。

基于XML的业务流程定义语言规范在不断的发展过程中，需要一段相互融合、达成统一的规范时期，值得关注。