对于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拓扑大体相似。