對于BPM產品目前尚無公認的分類標準，如果沿用以前對工作流的分類，則可以分為生產型（又可以再細分為自治式和嵌入式兩種）、管理型、協同型和專門型四大類。但這樣一來，市場上主流的通用BPM產品大都會被劃分到生產型，難以分辨出它們之間的本質差異，因此我們需要一種新的分類方法。

筆者建議根據產品內在拓撲結構的差異進行分類，將BPM產品劃分為面向引擎型、面向業務型、面向消費者型、以及對等型四大類。而一些功能較強的產品能同時支持多種拓撲結構。

面向引擎型：匹馬單槍

 

見自性清靜，自修自作法身，自行佛行，自成佛道。

企業內的工作流系統廣泛采用了這種集中控制式拓撲結構，客戶端連接到負責接受請求的中央引擎服務器。當流程上有客戶端完成了任務，它會將結果發送給服務器，服務器接收齊工作數據，就開始組織下一個任務項。大多數BPM產品都支持這種最原始的拓撲形式。

這種方式的長處在于其簡單性，它使得管理和控制都很容易，而且它對客戶端的要求不高，大多數負載和責任都從客戶端轉移到了引擎服務器。

這種模式的缺點在于成敗懸于一線，整個系統完全依賴于一個全能服務器。該服務器必須功能非常強大，并且必須能夠承受巨大的壓力。反過來說，這又限制了系統的可擴展性。

采取這種結構的BPM系統一般非常重視用于自動型活動的企業應用集成（EAI/A2A）和用于人工型活動的人機交互界面。有集成服務器背景的廠商往往側重于應用集成和直通處理（系統到系統的交易），Fuego、SeeBeyond、Vitria和WebMethods屬于此類。有著工作流背景的廠商則往往對需要大量人工干預的應用提供更完善的功能，FileNet、Identitech、Plexus和Staffware就屬于此類，這類廠商對客戶界面和流程設計工具進行了優化，可以支持各種流程的人工干預。新玩家HandySoft和Intalio則介于兩者之間。

歸根到底，應用集成能力的高低是區別諸解決方案的一個主要因素。如果你所考慮的應用需要相當高的集成水平，尤其是與多個系統的集成，集成服務器廠商提供的產品顯然具有優勢，但選擇來自集成服務器廠商的BPM解決方案可能意味著需要采用它們的平臺作為集成標準。 

面向業務型：天龍八部

爾時世尊，天龍八部，四眾圍繞，王及大眾，五體投地，為佛作禮。

許多業務流程管理系統是通過可靠消息通信實現的。消息隊列技術允許系統異步和分布運行，支持跨異構網絡甚至是暫時離線的系統間通信。一個客戶端為了與屬于另一引擎服務器的客戶端進行協作，可以將消息發送到自己所屬引擎的隊列中，引擎會完成剩下的實際消息轉發和傳遞工作，并把最終的返回消息也放在發起者的接收隊列中，供該客戶端隨時提取。

這是一種多引擎的拓撲結構，可以解決許多單純的客戶/服務器拓撲存在的問題，但它仍然采用集中控制的方法，因為一個引擎通常服務于一大堆客戶端，任務只是在相互連接的引擎之間分割和協作。

這一解決方案的優點在于可擴展性好，當負荷太重時可以通過添加引擎來緩解。這一方案的容錯性也更強，當某臺引擎出現故障時，其他引擎可以接管其原來的工作。另外，它可以支持更有效的通信，因為引擎可以與客戶端離得更近。

這一方式的缺點在于引擎必須設計得很精巧，它必須既能處理客戶端請求，又能與其他引擎協調。它還有一點與面向引擎的拓撲類似，即仍然將負荷和責任從客戶端改扛在了引擎服務器肩上，只不過不光是一個引擎罷了。另外，同時維護多個引擎也需要更多的管理開銷。

支持這種拓撲結構的BPM產品一般都擅長于跨企業的應用集成和協調（B2Bi）。許多BPM應用，如支持多賬戶應用處理的金融服務，往往基于應用服務器環境。例如IBM的MQSeries Workflow的產品；BEA的Process Integration。Fujitsu、Intalio、Quovadx、Savvion、Versata等廠商的產品不僅能夠與IBM或BEA的應用服務器兼容，還各自提供常見BPM組件的定制開發環境。對側重于開發流程之間的應用到應用通信并以微軟產品為中心的環境而言，微軟的BizTalk則非常適合。 

面向消費者型：心心相印

昔時圣人互出，乃曰傳燈，爾后賢者差肩，乃曰繼祖，是以心心相傳，法法相印。

近些年，發布/訂閱（Pub/Sub）拓撲結構成為構建、實現和集成復雜流程的搶手貨，被認為是滿足動態需求的一種簡單而有效的手段。很多強大、靈活的BPM系統就建立在這種模式之上，例如，TIBCO便一直是使用Pub/Sub方式構建松散耦合的分布式應用的先驅。在動態演化的系統中應用Pub/Sub模式實現業務流程已被證明相當有效。

Pub/Sub拓撲結構的一大長處是無需復雜的集中式服務器和路由機制，因為消息直接由來源發往目的地。該模式支持高度分散的業務流程間的協作。

它的弱點在于可伸縮性非常有限。每個發布者只能包含有限數目的訂閱者，否則會處理不過來。此外，在沒有集中控制的情況下發現發布者和訂閱者也很困難，因為當你找不到對方的時候，無處去詢問和訴說。最后，它還存在生命期的依賴性。

像抵押貸款、索賠甚至支付處理等BPM應用還需要與流程管理功能緊密相關的圖像處理及內容管理功能，為此，Plexus能把大容量文檔圖像處理和高度可伸縮的流程管理緊密結合在一起；而Identitech等廠商捆綁了基于XML的電子表格和本地記錄管理功能；FileNet的新款Panangon平臺特別提供了企業內容管理（ECM）功能，能同時支持文檔圖像處理、Web內容管理及可靠的集成特性和選項。盡管Handysoft并不提供本地網站門戶，也不提供內容管理功能，但卻提供了與Documentum、Hummingbird、Plumtree和微軟的SharePoint相集成的功能。 

對等型：打成一片

長短好惡，打成一片，一一拈來，更無異見。

P2P（Peer-to-Peer）計算是Internet發展的最新產物，在Internet之上已經有了數不勝數的資源和對等端，它們有潛力克服傳統客戶/服務器系統的大多數限制，如可伸縮性、內容可用性、計算能力等，當然，這也需要比單純將消息轉發給所有對等端更有效的群組通信機制，因為這些對等端可能是在網格計算背景下分布在全球的用戶和廠商。

P2P模式是完全分散的，每個結點都被認為是一個對等端，它會連接到一個或者幾個其他的端口。如果不使用過濾機制的話，那么每個對等端都會把會話轉發給相鄰的所有對等端，形成會話“洪水”。所以在實際應用中，應該使用分割、投影、過濾等策略，只將與該對等端相關的流程部署在它上面，該對等端只接受從其流程上游發來的消息，再將經過處理的結果僅發送給它的下游對等端。

P2P拓撲的好處在于無需集中式服務器，允許任意數量的網絡結點，因為工作負荷可以在各個對等端之間平衡與共享。

它的壞處在于有時候延遲現象嚴重，因為流程有時需要在多個對等端之間協同。另外，部分低效的對等端必然影響整體的性能。

由中科院軟件所和中科國際共同開發的A2E-DI就支持完全分散的數據提取、轉換、傳輸和加載的全過程操作。HandySoft開發的BizFlow則提供了一系列由可伸縮業務流程引擎驅動的基于Web的協作工具，其可伸縮性決定了它亦能應用于對等環境。 

在P2P結構的基礎之上還可能出現P2P Cluster（P2P集群）拓撲結構。它可以通過分而治之的策略解決單純P2P模式中消息通信存在的某些問題。網絡被劃分為一系列集群，每個集群都了解其管轄的對等端。在每個集群中，犧牲一臺服務器用于充當協調者的角色，它知道哪個對等端訂閱了遠程的某個發布者，也知道遠程的某個訂閱者訂閱了集群內部的哪個對等端，這樣就不必把時間花在那些無關的集群內部了。其優缺點與P2P拓撲大體相似。