工作流之大局勢(2006版)

出處：CSDN 作者：Hongbo
 

1．引言
2004年9月，筆者在網絡發布了《工作流之大局勢》的最初版本，技術界朋友們反響非常強烈：很多網站和博客做了轉載；在之后的約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來為客戶服務。
   愿國內外工作流技術工作者都好!