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

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

面向引擎型：匹馬單槍

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

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

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

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

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

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

面向業(yè)務型：天龍八部

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

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

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

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

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

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

面向消費者型：心心相印

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

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

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

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

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

對等型：打成一片

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

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

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

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

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

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

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