以前在做船舶數字化系統時接觸了工作流技術，當時的知識僅限於JBPM，對其理解也不深刻，知識從技術使用方面有粗淺的認識，比如通過流程設計器也就是流程圖的方式設計業務流程，然後通過XML文件組織這些業務流程，最後通過業務流程引擎分析XML文檔，與其他功能一起完成一整套業務流程的操作，比如常用的辦公自動化啊，船舶系統中的船舶建造流程啊等等。
除了java平臺上有，在微軟等其他平臺上，都有成熟的工作流技術。現在將工作流的三大體系總結歸納如下（具體內容轉載至別處）：
圖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.國內工作流
國內工作流軟件公司其實是比較多的，但發展都不太好。工作流項目競爭激烈，公司層面也是按最初級的項目開發思路一個一個爲用戶定製。這樣開發速度慢，成本高，也不能適應用戶需求多變的特性。
部分用戶會要求開發公司使用工作流方式進行開發，這樣迫使軟件公司採用了工作流開發模式。但由於時間、資金投入、重視程度等因素的制約，一直髮展非常緩慢。
可能與行業背景有關係，國內工作流技術人員的生存環境不容樂觀。公司層面一般以普通的技術來看待工作流技術，不認爲這個是和行業認知密切相關的。
其實工作流是一個技術的同時，更是一個行業，它是需要積累的。部分技術人員自己也有問題，只是浮在表面，不能深入進去，所以使用工作流都成問題。還有很多人，因爲這個行業不好生存，在有了很多年的工作經驗後，轉行到其他行業，也是非常可惜的。
圖2 BPM系列標準發展歷程
圖3 IBM對Websphere平臺的描述
圖4 jBPM實現的協調交互功能
BPM與ERP集成的六大前提：
● 組織具有集成的意願；
● 良好的組織內部環境、企業文化；
● 組織最高管理者的決心和推動力；
● 務實、專業、高效的流程"診治"團隊，包括外部專家和組織內部業務骨幹；
● 流程存在不斷優化的可能；
● 具有平臺化技術的ERP系統。