第 I 條 工作流簡介
1 什麼是工作流？
簡單地講，工作流就是業務流程（Business Process）的計算機化或自動化。企業或組織內有許多繁瑣複雜的業務流程，這些流程構成了企業或組織的日常運營活動。通過現代的技術手段將這些流程自動化，並對其進行有效地管理便是工作流管理需要解決的問題。
2 什麼是工作流管理？
工作流管理的許多概念源於企業管理理論和實踐，隨着企業規模不斷擴大，管理的難度也隨之上升，信息技術和現代企業管理理論的發展，都爲有效地克服這些困難提供了理論和技術手段。工作流技術是一項快速發展的技術，並在各個行業得到廣泛應用。其主要特徵是業務流程（Business Process）的自動化，這些流程有人工的，也有自動的，其主要特點是，這些流程的處理都是在計算機應用程序和工具協助下進行的，就是說，由計算機系統來幫助人們完成日常事務的處理。
企業實施工作流管理所帶來的好處是非常明顯的，這包括提高企業運營效率、改善企業資源利用、提高企業運作的靈活性和適應性等等。工作流管理的最終目的都是爲了縮短企業運營週期、改善企業內（外）部流程、優化併合理利用資源、減少人爲差錯和延誤，以提高勞動生產率。
3 什麼是工作流標準組織WfMC？
有許多軟件廠商提供各自的工作流軟件產品，而且新的產品也不斷涌現，用戶有很大的選擇餘地，但是如果沒有可遵循的行業標準，就會使這些產品之間存在巨大差異，導致這些產品之間不能協同工作，成爲一個個信息的"孤島"。
在這種背景下，工作流管理聯盟（WfMC）於1993年成立了，這是由多家公司聯合成立的國際標準組織，其目的是通過制定工作流技術及其標準，提高不同工作流產品之間的連通性和協同工作能力。通過使用標準可以使不同的產品之間協同工作，也可以改善工作流產品與其他IT服務（電子郵件、文檔管理）之間的集成。
該組織由三個委員會組成，分別是技術委員會、對外關係委員會和籌劃指導委員會，WfMC目前有270多個成員組織，遍佈世界各地。經過該組織的不懈努力，工作流標準的制定和推廣工作進展得非常迅速，目前，多數工作流產品的生產廠商已經在產品中遵循了全部和部分標準。
4 工作流標準
工作流管理聯盟定義的工作流系統標準中包括一個參考模型及其5個接口的規範，這些規範確定了開發工作流產品所必須遵循的行業標準，只有遵循這些規範開發的產品纔可稱爲真正的工作流產品。
5 工作流包括以下幾個要素：
5.1實體(Entity) ：
是工作流的主體，是需要隨着工作流一起流動的物件(Object)。例如，在一個採購申請批准流程中，實體就是採購申請單；在公文審批流程中，實體就是公文。
5.2參與者(Participant) ：
是各個處理步驟中的責任人，可能是人，也可能是某個職能部門，還可能是某個自動化的設備；
5.3流程定義(Flow Definition) ：
是預定義的工作步驟，它規定了實體流動的路線。它可能是完全定義的，即對每種可能的情況都能完全確定下一個參與者，也可能是不完全定義的，需要參與者根據情況決定下一個參與者；
5.4工作流引擎(Engine) ：
是驅動實體按流程定義從一個參與者流向下一個參與者的機制
可以看出，前三個要素是靜態的，而第四個要素是動態的，它將前三者結合起來，是工作流的核心組成元素。
6 爲什麼需要電子化的工作流(eWorkFlow)?
手工處理的工作流主要有以下幾個缺點：
6.1不能及時得到處理
一個步驟完成後必須將實體物理地轉移給下一個參與者，當工作量增大時，很難分清哪些是重要而需要及時處理的，甚至經常出現上一個步驟已經完成了，而下一個步驟還不知道的情況；
6.2無法跟蹤
傳統的手工操作要求有一個人自始至終地跟着單子（比如採購申請單）走，否則流程中的任何一個人也無法知道一項任務當前的處理位置，當出現停頓時甚至無法知道該找誰解決；
6.3效率不高
很多實際上可以並行處理的步驟（例如公文審批過程中的會籤），在手工處理的時候，只能一個接一個的串行處理；
6.4缺乏分析功能
流程是人制定的，是否適合實際情況只能通過實際工作檢驗。但手工處理無法統計各個環節的處理效率，因此對流程的評估都是大致的，憑感覺的，無法量化，對流程的改造缺乏科學的統計數據做基礎。
通過採用先進的信息技術，以上問題可以迎刃而解。軟件的力量，是把繁雜而沒有條理的工作，分門別類地整理出來，給每個人一個清楚的視圖，及時瞭解當前的工作狀態，易於跟蹤和查詢。同時強大的統計分析功能便於從海量的數據中找出人工統計所無法發現的規律，並據此做出正確的決策。
7 發展階段
工作流(WorkFlow)的概念是在現代信息系統的建設中逐步形成的，一般把它分爲三個階段:
7.1EDF(電子數據流)階段
此時的工作流在信息技術中的應用,僅着眼於利用信息技術減輕人們在流程中的計算強度,如設計一個流程用來協調多個會計統計帳目。所以,EDF最主要的特點是僅對企業單項業務進行處理,基本不涉及管理的內容。
7.2TPF(事務處理流)階段
TPF並沒有形成對企業的全局業務的管理,而着眼於對企業局部業務的管理,比如,設計一套工作流程,來管理物資的採購和供應。
7.3IMF(信息管理流)階段
當今的工作流, IMF強調對企業業務的全局的整體性的管理。在這個階段,工作流就是爲了完成同一目標而相互銜接、自動進行的一系列業務活動或任務。目前,工作流技術與信息技術以及企業管理緊密結合,已經悄悄滲入MIS系統、ERP系統和CRM系統等企業級關鍵系統中,並迅速成爲這些系統的核心。
8 工作流參考模型
8.1Work Flow Enactment Service
這個組件就是我們平常說的工作流機或工作流引擎，主要功能是讀取工作流定義、根據工作流定義驅動工作流的流轉。一般常用的開源的JAVA工作流機有Shark/OBE/ofbiz等
8.2Process Definition Tool
用於以圖形化的方式定義工作流。如著名的JAWE。Process Definition Tool與Work Flow Enactment Service之間的接口就是Interface 1。接口一標準目前就是XPDL標準。
Work Flow Client Application
工作流機的客戶端程序。該程序由用戶結合業務需求而開發,用它來驅動工作流。客戶端程序通過Interface 2與引擎交互。一般的工作流引擎用戶不需要懂引擎的實現,只要知道怎麼實現客戶端程序就可以了。
8.3Invoked Applications
在工作流運作的過程中，可能需要調用工作流機之外的功能，這時可通過定義好的Interface 3來完成。
8.4other Work Flow Enactment Service
Interface 4用於工作流機與其他工作流機的協作。
8.5Administration and Monitoring Tools
用於管理和監視工作流機,這個就是接口5了。
9 工作流引擎的三種定位
應該由誰來負責定義和開發工作流的應用？一般有三種觀點，也就是我們對工作流引擎的三種定位：
9.1完全由實際的技術人員來負責定義和開發工作流的應用
我認爲這種觀點等同於不需要工作流引擎，它只適合簡單、變化少的工作流應用；如果業務邏輯和業務規則比較複雜，則需要自己定製相應的應用邏輯，並且不靈活。
9.2業務人員和技術人員結合
工作流產品提供圖形化的界面，供業務人員定義業務邏輯；技術人員需要完成具體的應用邏輯。
9.3業務人員獨立
該觀點認爲，應該把信息系統的開發融入工作流引擎中，即工作流引擎完成所有功能。
9.4就國內目前情況看
大部分的關鍵業務系統沒有應用工作流思想，即第一觀點，該觀點已經被證明是不正確的；國外的開源軟件都採用第二種觀點，因爲它不能預測到所有的用戶的應用需求；國內部分公司採用第三種觀點，但目前還沒有一個比較好的解決方案。
第 II 條 工作流管理系統比較
1 工作流模型分析
1.1發散模型
在發散模型中,活動A結束後,有M(2<=M<=9999999999..)個直接後繼的可選活動
1)M項發散
後面M項活動同時enabled,正式名稱爲Parallel Split
2)1項發散
後面只可能一項活動enabled,正式名稱爲exclusive choice
3)N項發散
後面可能有N項活動同時enabled,(1<=n<=m),正式名稱爲multiple choice
目前,一般的工作流產品及XPDL標準只支持前兩項，對N項發散支持的不太強,但已經有產品如MQSeries/Workflow等直接較好的支持N項發散.
1.2聚合模型
1) M項聚合
只有當M項活動都結束後,A活動才enabled
2) N項聚合
1<=N<=M,其實就是一個鑑別器,當某N項活動完成後,條件滿足,A活動才enabled
3) 單項聚合
任意一個活動結束,A活動都enabled
對於N項聚合和單項聚合有一個問題:A活動能夠被幾次enabled?根據對這個問題的回答,聚合模型又可以繼續進行分類.
基本上所有的工作流標準都支持M項聚合和單項聚合,而對N項聚合,每個標準的支持程度是不一樣的,XPDL標準不支持N項聚合.
1.3多實例模型
所謂多實例模型，指的是流程中的同一個活動，同時存在多個實例。
1） 異步
多個實例產生後，這些實例各自爲政，互不影響。因爲互不影響，所以異步的多實例模型的產生的實例數是任意的。當說到可以產生的實例數時，我們說的都是同步的情況，就如下面三點。
多個實例產生後，這些實例各自爲政，互不影響。因爲互不影響，所以異步的多實例模型的產生的實例數是任意的。當說到可以產生的實例數時，我們說的都是同步的情況，就如下面三點。
2） 定義期決定實例數
說的簡單點，就是在JAWE中可以定義一個活動可以產生的實例數。
說的簡單點，就是在JAWE中可以定義一個活動可以產生的實例數。
3） 運行期決定實例數
在流程運行過程中，動態決定一個活動可以產生的實例數。
在流程運行過程中，動態決定一個活動可以產生的實例數。
4） 任意的實例數
說的粗一點，就是：一個活動，想產生實例就可以產生實例。
說的粗一點，就是：一個活動，想產生實例就可以產生實例。
一般的標準都只支持前兩種模型，包括XPDL標準。
2 業務流程定義語言規範
在工作流管理系統概念的基礎上，演進出很多標準，總體上可分爲基於標準 XML 文檔的和基於 Web 服務技術的兩種規範。
此類規範最大的特點就是基於純 XML 技術。其中包括：
1) XPDL（Xml Process Definition Language）
在工作流領域第一個致力於標準化工作的是Workflow Management Coalition (WfMC)，它成立於1993年。1994年11月，wfmc發佈了工作流管理系統的參考模型。參考模型提出了五類接口，有關過程模型的定義則構成了接口一的核心內容。接口一早期的標準爲WPDL（Workflow Process Definition Language），後來,這一接口的規範變更爲XPDL。XPDL是至今工作流領域最爲重要的一個標準,目前大多數工作流引擎是依據該標準設計開發的。XPDL地位一步步削弱。
2) BPML （ Business Process Modeling Language ）
BPML 是 BPMI （ Business Process Management Initiative ）組織發佈的規範。 WfMC 和 BPMI 在 2002 年 6 月 26 日宣佈將合作制定業務流程和工作流標準，即採用 BPML 來描述工作流過程，同時採用 XPDL 所定義的工作流模型。 BPML 規範爲表達業務流程和支持實體提供一個抽象模型。 BPML 爲表達抽象和執行流程定義了一種正式模型，該模型代表了企業業務流程的面貌，包含了不斷變化的複雜行爲，事務和數據管理，合作，異常捕獲，操作語義。 BPML 爲了能夠持久化和通過異種系統進行定義交換以及使用建模工具，提供了 XML Schema 形式的語法。BPML基本上銷聲匿跡。
3) OMG的Workflow Management Facility
在 WfMC 所定義的一系列規範基礎上， OMG （ Object Management Group ）聯合這些規範發佈了 Workflow Management Facility 規範，該規範定義瞭如何將工作流向 CORBA 轉換。 CORBA的行情日漸沒落。CORBA的兩大特點是：思想超前，極不實用。OMG的Workflow Management Facility也秉承了這兩大特點，在追求高效輕量的今天，它的沒落也就是順理成章的事情了。
2002 年 6 月 26 日 BEA 、 Intalio 、 SAP 和 Sun 在美國發布了基於 XML 的 Web 服務協作接口 WSCI （ Web Services Choreography Interface ）。 WSCI 描述了在特殊流程中通過 Web 服務實現消息流的交流，並描述了集合性信息在互動的 Web 服務間的交流，提出了一種涉及到多種 Web 服務的複雜流程的全球觀點。當今的服務描述語言對於簡單的獲取信息是足夠的，例如股市報價，但它們沒有提供充足的動作細節，來描述服務作爲一個大型的、更全面的協作的一部分所扮演的角色。 WSCI 的關鍵優勢之一在於，它通過描述 Web 服務如何在大型的、全面的業務流程中應用，從而在業務流程管理與 Web 服務之間架起了橋樑。這些業務流程可以只是一個公司內的，也可以是跨越多個公司的。後來又發展了幾個新的, 如WSFL(屬IBM),Xlang(屬MS),因有天生缺陷,均沒有很大起色。WSCI的幾個廠商如BEA/SAP/SUN等均已經投靠到BPEL，WSCI基本上沒有了發展的空間。
ebXML(Electronic Business XML)是一個規範集，這些規範共同實現了模塊化電子商務框架。 ebXML 的構想是實現一個全球電子市場，其中，不同規模和不同地區的企業可以通過交換基於 XML 的消息來合作和進行商業活動。 ebXML 是一項倡議，其參與者與認可者包括幾百家大公司和團體。 ebXML 的直接贊助者是 OASIS （ Organization for the Advancement of Structured Information Standards ）和 UN/CEFACT （ United Nations Centre for Trade Facilitation and Electronic Business ）。許多標準團體也參與其中，包括 NIST （ National Institute of Standards and Technology ）和 W3C 。ebXML只能在電子商務領域活動活動拳腳，由於它的體系結構的全面性，目前還有部分學術界人士在研究ebXML，但應該不會有很大起色。
3) BPEL
（Business Process Execution Language for Web Services）2002年8月9日，Microsoft, BEA, IBM, SAP & Siebel聯合提交發布了BPEL規範（他們的產品並不獨立地實現BPEL）。 BPEL聯合了XLANG, WSFL, BPML。此規範描述如何處理輸入的消息，它不是一個關於業務流程規格化定義的規範。簡單的說，可以將它看作XML形式的編程語言，提供將WSDL-Services組合成控制流的能力。顧名思義，此規範重點在（也不只限於）Web Service。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標準的領導者行列。WS-BPEL2.0的草案也在當時被納入議事日程。
3 商業工作流軟件介紹
3.1 IBM Websphere系列產品
現在，IBM已經把Websphere作爲整合的代名詞。Websphere MQ Workflow實現流程整合，Websphere Business Integration Server實現業務整合。而收購的兩個產品，改造爲自己整合中間件的建模/管理/監控工具。
這些產品都和IBM自己的其它產品比如：Websphere MQ 或者IBM DB2有直接關係。比如，我們使用MQ Workflow，只能用DB2數據庫，不能用Oralce數據庫。
IBM的流程管理工具是市場上佔有率最高的，約爲 24%。
3.2 BEA AquaLogic系列產品
BEA本身就是一個收購型公司，它收購的產品均爲自己公司創造了巨大的財富和影響力。就在今年的3月1日，BEA收購Fuego，Fuego的產品組合將加入到BEA的AquaLogic產品陣容中，將成爲BEA新的AquaLogic商業服務互動產品線的基礎。
BEA在流程管理工具方面的市場上佔有率約爲15%。
3.3 Microsoft Biztalk Server
看了資料說它的市場佔有率爲約17%。
3.4 Oracle BPEL Process Manager
Oracle在融合派中是最早推出BPEL編輯器和引擎的產商，功能全面而且非常的穩定，可惜的是Oracle公司的所有產品目前和開源沒有任何關聯。
4 開源工作流軟件產品分類介紹
4.1基於標準XML文檔的規範
1) OFBiz
最主要的特點是OFBiz提供了一整套的開發基於Java的web應用程序的組件和工具。其中包括實體引擎, 服務引擎, 消息引擎, 工作流引擎, 規則引擎等。OFBiz先前的工作流引擎基於WfMC和OMG的規範，使用XPDL作爲流程定義語言，OFBiz新版的工作流引擎採用Shark工作流引擎,我們不建議再去學習OFBiz自身的工作流引擎。
http://ofbiz.apache.org/
2) OBE
是由Adrian Price主持開發的一個開放源碼的Java工作流引擎，支持WfMC規範，包括接口1（XPDL）、接口2/3（WAPI）和接口5。OBE主要基於J2EE實現。OBE的接口1實現得非常好。OBE至今沒有release版，很是可惜。
3) Shark
是完全根據WFMC規範實施的，可擴展功能的工作流引擎，它利用xpdl來定義流程，同時還包括服務器端的用於活動節點執行的WFMC工具代理API。Shark和XPDL定義工具的事實標準JAWE同出名門,市場前景被很多人看好。OFBiz新版的工作流引擎採用Shark工作流引擎。Shark工作流引擎與XPDL定義工具JAWE關係密切,是研究重點之一。而MS/IBM/BEA等跨國巨頭越來越主推BPEL4WS標準，並且已經發布基於BPEL4WS標準的系列產品，而且，他們還主推Integration/Portal的概念。
http://shark.enhydra.org/
4.2基於 Web 服務技術的規範
1) OpenebXML
OpenebXML項目致力於提供一個ebXML框架，主要支持 UN/CEFACT和OASIS發佈的ebXML規範2.0版。Open ebXML處在不僅沒有財力，連關心的人都沒有的悲慘景地。
2) Bonita（**重點**結合Petri網模型）
Bonita是一個符合WfMC規範、靈活的協同工作流系統。Bonita基於瀏覽器、使用SOAP和XML數據綁定技術的Web Services封裝了已有的工作流業務方法並將它們以基於J2EE的Web Service形式發佈。
3) Twister
Twister的目標是提供新一代、易集成、應用Java領域中最新成果、面向B2B的工作流解決方案。流程引擎基於BPEL業務流程規範和Web Service標準。Twister沒有很大起色。
4) ActiveBpel
ActiveBPEL引擎是一個於今年7月發佈的健壯的運行時環境,它能執行用戶按BPWL4WS規範編寫的業務流程。ActiveBPEL引擎由Active Endpoints公司開發和維護,該公司同時在它的多個商業產品中使用了該技術。ActiveBPEL由於有後臺公司的支持，有一定的發展，但由於革新是個花錢的活，而且Active Endpoints沒有足夠的財力，所以ActiveBPEL發展也不迅速。
http://www.active-endpoints.com/active-bpel-engine-overview.htm
4.3獨立於規範外
5) OSWorkflow
非常靈活的工作流引擎，完全基於插件思想，可擴展性極強，基於狀態。 OsWorkflow的版本更新也很慢，至今沒有一個象樣的流程定義工具，流程輔助功能也基本沒有。
6) OpenWFE
OpenWFE是一個java寫的開源工作流引擎。
它由四個組件（服務器）組成：一個引擎、一個工作列表、一個反應器（自動參與者的容器）、一個web客戶端（一個通用的web應用的例子）。
它由四個組件（服務器）組成：一個引擎、一個工作列表、一個反應器（自動參與者的容器）、一個web客戶端（一個通用的web應用的例子）。
http://www.openwfe.org/
7) jbpm
簡介：基於JBoss+EJB的工作流引擎。 jBpm是tom baeyens編寫的一個靈活可擴展的工作流管理系統。jBmp將工作流應用開發的便利性和傑出的企業應用集成（EAI）能力結合了起來。jBmp包括一個Web應用程序和一個日程安排程序。jBmp是一組J2SE組件，可以作爲J2EE應用集羣部署。
http://www.jboss.com/products/jbpm
5 開源工作流產品比較
5.1Ofbiz
ofbiz的主要精力不在於他的workflow engine上，而且他的workflow engine很難和其entity engine以及service engine分離，use all or use none. Ofbiz已經基本脫離了工作流領域，在該行業沒有什麼發言權；
5.2Osworkflow
osworkflow是一個輕量級的workflow engine，較容易和其他架構做整合；必須要使用他的User模型
Osworkflow的靠山是opensymphony。這個組織做出了很多的好東西如webwork2。
Osworkflow是FSM驅動，你把他類似理解爲狀態圖就可以了。Osworkflow中的State是由step和status聯合表達的，一個State就是一個step中的某個status；而state的轉換由action來驅動，類似狀態圖中的event,因爲一個event對應一個action嘛。
優點：
1. 工作流引擎可工作於JSP Container，EJB Container，WS Container。
2. 引擎支持自動任務和手工任務。
3. 工作流實例以及相關數據可以持久化，可以選擇JDBC、EJB、Hibernate等持久化方式。
4. 具有工作流腳本圖形編輯器。
5. 各種功能基於插件方式，易於集成已有系統。
6. 工作流可以調用Java、EJB、Bean Shell、BSF等功能。
7. 支持權限。
8. 定時任務調度。
9. 適用於Web和非Web環境。
缺點：
1. 非標準腳本語言，工作流引擎對於自動任務支持尚不完善。
5.3Jbpm
jbpm相對osworkflow複雜一點，但是其開發團隊比較active。必須要使用他的User模型
jBPM，全稱是Java Business Process Management，是一種基於J2EE的輕量級工作流管理系統。jBPM是公開源代碼項目，它使用要遵循 Apache License。
jBPM最大的特色就是它的商務邏輯定義沒有采用目前的一些規範，如WfMC's XPDL, BPML, ebXML, BPEL4WS等，而是採用了它自己定義的JBoss jBPM Process definition language (jPdl)。jPdl認爲一個商務流程可以被看作是一個UML狀態圖。jPdl就是詳細定義了這個狀態圖的每個部分，如起始、結束狀態，狀態之間的轉換等。
jBPM的另一個特色是它使用Hibernate來管理它的數據庫。Hibernate是目前Java領域最好的一種數據持久層解決方案。通過Hibernate，jBPM將數據的管理職能分離出去，自己專注於商務邏輯的處理。
Jbpm的靠山是jboss。Jbpm3的持久層採用hibernate3來實現，也是因爲這個原因吧。Jbpm3的圖形化流程定義已經決定嵌入到jboss eclipse IDE中，我們已經可以用插件方式編輯一個jbpm3流程定義文件了。
Jbpm它結合應用了狀態圖+活動圖+PetriNet的知識，而且，這裏的活動圖還是UML2.0版的。UML2.0的活動圖中，節點不叫活動（Activity）而叫動作(action)，活動成了一個高層次的概念，它包含一個動作序列。一個活動圖展現一系列的動作，這些動作組成了活動。Jbpm把action也改名了，稱爲state。Jbpm使用的狀態圖的概念有transition/event等。Jbpm來內部實現中還採用了PetriNet的概念，如token,signal等。
jBPM被jboss收購後，jboss又被redhat收購，最初只實現了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。
jBPM本身是個功能全面的Workflow Engine，它自己有個BPEL擴展，採用jboss Hibernate實現，集成了jboss seam，規則引擎準備採用jboss rules，並準備集成jboss Messaging。Redhat已經收購了jboss，也就是說，以後你安裝好redhat，就可以直接使用jBPM提供的服務了。
優點：
1. 安裝簡便，支持動態部署，工作流引擎支持交互界面的腳本，適用於WEB環境。
2. 支持EJB，但不一定需要EJB。jBPM
3. 使用簡單，易上手，源代碼也易讀，作嵌入式工作流是一個很好的選擇。jBPM
5.4Shark
Shark的靠山是Enhydra。Enhydra做過什麼呢？多了！從j2ee應用服務器，到o/r mapping工具，到這個工作流引擎等等。爲什麼Shark的持久層採用DODS來實現？就是因爲他們是一家人。
Shark的特性：思想保守，不思進取，排除異己。Shark是Enhydra系列產品中的一個，所以它的持久層採用了Enhydra DODS來實現。基本上沒有什麼人來使用DODS，也沒有人瞭解它，而且它表現並不很優秀。在Shark1.0阿爾法版中，有外界人士提供了Shark的Hibernate實現；但Shark並不把該實現集成到產品中，也不計劃在將來的版本中轉向/支持Hibernate。這樣並不符合開源思想，也會在使用和推廣中出現很多問題。
Shark的版本更新比較慢，代碼的更新也沒有按照開源的方式來完成。Shark在1.0後直接發展到2.0，讓人大跌眼鏡。
Shark2.0後，有很多組件不開源了，而且都是隻有DEMO，如果要用，需要付費。Shark開發的系統目前仍然在運行。
5.5ActiveBPEL
基於多個不同應用內的工作流引擎技術，它的技術實現要依靠web service來進行實現。推薦的實現組合是：AXIS+J2EE+ACTIVEBPEL ，我的J2EE是STRUTS+SPRING+HIBERNATE 的MVC框架，使用SPIRNG和AXIS組合使用。業務流程由BPEL4WS生成，主要有兩個文件.bpel和WSDL，由ACTIVEBPEL服務器分析並與AXIS服務交互。
ActiveBPEL組織是一個主導ActiveBPEL引擎技術的開源組織。ActiveBPEL引擎是一個健壯的運行環境，它能執行用戶按BPWL4WS規範編寫的業務流程。
ActiveBPEL引擎由Active Endpoints公司開發和維護，該公司同時在它的多個商業產品中使用了該技術。Active Endpoints公司相信開源模式對於培養社團興趣和推廣標準非常有用，所以建立了該開源產品。
Active Endpoints公司宣稱ActiveBPEL引擎有如下關鍵優勢：
1) 完整性：ActiveBPEL引擎完整地實現了BPEL4WS標準。
2) 方便性：ActiveBPEL引擎除了完全實現標準，還在包的發佈，流程持久化，事件通知等方面加強了方便性。
3) 持續性：Active Endpoints公司是一家商業公司，能持續地對ActiveBPEL引擎給予支持。
該新版本中主要的提高是對即將推出的WS-BPEL 2.0的擴展支持。
第 III 條 工作流國內局勢
1 工作流組織
國內工作流軟件公司其實是比較多的，但99%發展都不太好。工作流項目競爭激烈，公司層面也是按最初級的項目開發思路一個一個爲用戶定製。這樣開發速度慢，成本高，也不能適應用戶需求多變的特性。部分比較懂行的用戶會要求用工作流方式來開發，這樣逼迫部分公司採用工作流。
普元的EOS應該也算和工作流有一定關係，它有兩個特性是我比較認同的：構件化，圖形化。構件化在我而言應該是組件化，不完全是EOS的構件的概念。圖形化在jBPM的GOP中已經得到很好的體現。但有一點我認爲普元沒有做好：人性化。這裏的人性化並不指其他，而是吸引技術人員來使用本產品的意思。EOS得了一大堆獎，都是沒有用的東西，也就能夠寫在招標書中給人看看；但這樣的產品都有一個特點：最後是技術人員來使用。表面上是企業管理人員拍板決定買誰的產品，但本質上還是要看技術人員的（核心的那幾個技術人員）。組件化+圖形化+人性化+開源化。這裏的開源化是指對部分組件開源，並且其他部分組件是技術人員可以自己擴展的。
Joinwork是針對J2EE/Java應用開發人員，主要以嵌入上層業務應用的方式部署使用的工作流軟件...http://www.joinwork.net/
2 國內開源工作流
Willow是huihoo組織下的開源工作流產品，當屬XML的吧，文檔不多。
AgileFlow（http://sourceforge.net/projects/agileflow）的舊版是用來給工作流新人學習，快速入門；而新版將是基於jBPM之上，實現一個產品，目標是提供給工作流項目實施人員，讓他們快速簡單地使用jBPM來爲客戶服務。
第 IV 條 開源工作流產品佔有率趨勢
1. 2004年前，國內的工作流引擎使用率最高的是osworkflow;
2. 到2004年底，Shark就佔有了明顯的優勢地位，分析有如下原因：
1) 國內的企業都看中XPDL，因爲這意味着在產品說明書中又可以吹牛說“我們遵循WFMC……”
2) Shark的確是一套不錯的工作流引擎，就算你只是想學習XPDL，你也可以從學習Shark開始
3. jbpm3支持bpel4ws的核心部分。所以，Shark在引領風騷數百天後，被jbpm3趕下第一寶座。