1996年，Gartner Group最早提出SOA理念，现在已经成为风靡IT领域的一个重要概念。一项调查显示，表示愿意在2010年之前使用或者正在使用SOA的企业占68％。在全球2000强里，已经采用SOA的企业占到了74％。采用SOA进行企业IT构建，已经成为了一种趋势。

对于SOA这个概念，目前IT界还没有统一的定义，一般认为SOA(Service Oriented Architecture，面向服务的体系结构)是一种创新的应用架构，它着眼于日常的业务应用，并将它们划分为单独的业务功能和流程，即所谓的服务。服务间通过网络彼此通信，进行分布式组合、部署。

另外一种观点，将SOA看做一个组件模型，它将应用程序的不同功能单元(称为服务，Service)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它独立于现实的硬件平台、操作系统和编程语言。

可以看出，服务在SOA中的地位至关重要。服务是一个提供特定功能的软件应用。描述它的另一种方式是在流程中可重复使用的任务。W3C指出：“服务提供者完成一组工作，为服务使用者交付所需的最终结果。最终结果通常会使使用者的状态发生变化，但也可能使提供者的状态发生改变，或者双方都产生变化”。

SOA架构下，服务恰恰为流程的动态化管理提供了条件与可能。

2 BPM在SOA中的角色

目前，人们对BPM和SOA持有两大截然相反的观点。

一种认为，BPM和SOA是两个相对的东西：一个是管理方法，是业务驱动措施，一种是系统架构，是IT驱动措施，两者不可能相互兼容；另外一种观点却认为SOA赋予BPM新的生命并帮助其实现灵活性。同时，BPM也令SOA旧貌换新颜，将业务层面和IT层面紧密联系在一起。现在，大量的事实倾向第二种观点，越来越多的中间件供应商也将SOA和BPM产品联合起来考虑。

IBM公司WebSphere产品销售部的经理StephanieWilkinson认为“BPM是SOA在业务方面的一个切入点。实现服务的重用是SOA的关键；而BPM则是对业务进行管理，重点是对业务流程实现建模和监控。要完成BPM的一些相关工作，需要基于一个灵活的IT架构，SOA就是一个不错的选择，可以将服务和流程结合在一起。

ZapThink公司的高级分析师Ron Schmelzer说“要想建立松耦合、复合的服务定向应用，所有的供应商都需要一个可靠的SOA解决方案，还要考虑其产品的业务流程方面。”他指出IBM和Oracle and Microsoft公司的产品可以提供SOA架构下的流程管理方案。Sonic Systems，Fiorano和SOA Software这样的供应商也可以胜任。甚至最近出台的复合应用供应商如SEEC Systems，Webify Solutions，Tenfold也在他们的SOA基础设施中增加了BPM功能。

BPM在SOA架构中扮演的角色，如图1所示。一个叫做“服务”的名词作为衔接者，将BPM和SOA紧紧的联系在了一起。

 

 图1 BPM在SOA中的角色

业务流程涉及一个或多个参与者、活动、业务规则以及跨多游道的商业规则。服务作为一个细粒度对象将执行一个非常特殊的功能。服务可以以独立的方式脱离上下文，而业务流程在已经定义好上下文的基础上才能执行。

服务是一个提供特定功能的软件应用。描述它的另外一种方式是，服务是在业务流程中可重复的任务。服务可以用公开的接口来描述，而与它们的实现方式无关。业务流程就是由许多这样的所谓松散耦合的软件服务组合而成。

业界有一个很形象的比喻，将传统的IT开发，僵化流程比作“雕版印刷”；将基于SOA架构下的BPM比作“活字印刷”；“活字”就是服务；“排版”就是业务流程的编排； “替换活字"就是服务的重用或业务规则的改写。
 

3 基于SOA架构下的BPM的优势

最近Forrester Research的一份中间件软件市场报告中指出：“如果企业中的系统已经采用了SOA，那么业务部门会非常重视BPM项目，因为他们认识到这些BPM项目很容易实施，并且将带来巨大的经济利益”。IBM的BPM副总Angel Diaz表示:与SOA的结合增强了BPM的适应能力。“你可以在没有SOA的情况下单独实施BPM，但是当你开始使用基础设施，并且通过ESB和服务做投资的时候，会发现基于SOA架构下的BPM是多么的灵活”。

研究SOA和BPM的关系时，首先我们应该明确一点：SOA是一种架构，而BPM是一组协调活动。部署BPM，并不一定要基于SOA架构，以此可以快速的实现目标。但由于SOA架构下，具有易于集成、降低管理复杂性、消除信息孤岛、增加重用和降低成本等特点，在此结构下实施BPM可以将其作用发挥的淋漓尽致。

在单独部署BPM的情况下，流程可以被简单而快速的挖掘、设计、执行、管理和维护、最优化。而BPM的真正实现，还必须与底层的IT系统相集成。在底层的IT系统完全不更改，并且业务人员和IT技术人员一起控制所有的系统的情况下，是否基于SOA架构，没有太大的影响。图2是BPM的单独应用。

 

 

图2 不在SOA架构下的BPM应用

当BPM由一个小组来部署，消费来自另外一个小组的系统的服务，那么协调和管理每个小组中的更改的任务就会相当困难。或者某个组织的IT基础架构十分复杂，并且经常需要改动，在这两种情况下，就应该基于SOA架构柬实施BPM。因为当BPM部署或业务改变时，业务人员会以他们的角度来阐释需求，而IT技术人员要考虑去怎样实现这些需求。技术人员会将他们认为可能重复出现的业务进行代码的封装，以各重用，但技术人员常常不清楚哪些业务上的功能在将来可能会需要进行频繁修改和重复使用。所以在实现企业的业务逻辑时，技术人员通常会使用面向过程的方法对现实业务进行描述。

如此一来，最常见的情况就是实现不同“详细流程”代码常常会掺和在一起、共用一批内存变量。这就直接导致了实现不同流程的程序代码不可分离和重组，这在技术上称为“高耦合”。最终，当企业希望改变流程的顺序时，就不得不对代码进行大量的重新编写和调整：当希望在别的流程中希望使用另一个流程中已实现的详细流程时，代码却无法顺利地从原来的流程中进行分离。所以当企业的业务流程发生变化时，技术人员不得不花费极大的精力去进行维护和修改，这样做不但增加了企业构建IT的成本，对原先程序功能的修改可能还会带来许多无法控制的风险。图3是在SOA架构下的BPM应用。

 

图3 在SOA架构下的BPM应用

总结一下，基于SOA架构下的BPM有如下优势：

(1)屏蔽了底层应用程序和数据库的复杂性。当BPM作为SOA的一部分进行部署的时候，流程可以通过企业服务总线提供的代理服务来接入到底层的IT系统。

(2)业务流程连接到系统的过程会更简单。IT可以公开更有用的接口，例如使用聚合的数据服务或使用标准协议而不是专有协议的服务。这样减少了实现流程所需的IT任务量，从而使流程人员将注意力更倾向于流程本身，而不是流程接入到底层IT系统所用的技术。

(3)BPM的实现更为健壮。因为底层的IT系统的变动与更改都不会影响到流程所用的接口。

(4)简化了流程的本身。在SOA架构下，服务被注册在服务注册中心，流程开发人员可以在构建流程时浏览注册中心，确保了与流程相关的服务可以被正确的使用和重用。这样流程本身的复杂度将降至最低。