SOA、BPM和ESB的关系

    有了面向服务的架构（Service-oriented Architecture，SOA），我们离实现这种远景迈出了一大步。 

    SOA是一种企业级的IT架构方式，它把IT资源作为与业务协调的服务来提供，从而满足业务要求。SOA支持面向服务（service orientation），这种方式可以通过相联服务的形式整合公司。面向服务让应用程序能够调用对方的行为作为服务；也就是说，这种可以重复的业务任务是自我描述、可以发现的，可满足服务质量的特定要求，还可以通过治理来加以管理。 

    组件是可以得到执行来提供功能的一段代码；服务是实际运行的一个组件，常常在各自的进程内运行，进程与调用服务的应用程序分开来存放。 

    的确，应用程序本身可以分成多个部分，每个部分都在各自的进程内运行，通过服务调用对方。
这就是组合式应用，这组相关、集成的服务支持在SOA上构建的业务流程。 

    不过，BPM和SOA的驱动因素大不相同：BPM是业务驱动型计划，而SOA是IT驱动型计划。 

    一个相关的概念是企业服务总线（Enterprise Service Bus，ESB），它让在不同平台上运行、用不同编程语言编写、使用不同编程模型的软件应用可以彼此联系，不需要费时又费钱的软件重组。 

    ESB能够在传输期间对消息进行路由和转换处理。它是基于标准的，这有助于方便集成不同厂商的产品，并且避免SOA那样被厂商锁定（vendor lock-in）的现象。 

    ESB执行的主要任务之一就是，把服务使用者（调用服务的一方）与服务提供者（部署服务的一方）联系起来。ESB让使用者能够调用服务，并且把这种调用与执行该服务的提供者对应起来。这样一来，使用者和提供者不需要了解对方，它们只要连接到ESB即可。

SOA和ESB不是什么新概念，只不过用于封装及集成应用功能的不断发展的方法的最新版本。

ESB较之传统解决方案的真正优点在于，它能够跨业务部门的界限很好地扩展。如今的集成应用程序需要在包括本企业、业务合作伙伴及客户的扩展型企业顺畅运行。

这意味着能够跨下面这些系统利用业务信息和实用程序：

•使用不同数据模型的系统
•使用不同技术实施的系统
•往往使用不同安全政策/程序的系统
•通常隐藏在企业或者业务部门防火墙后面的系统

即便是在一家公司里面，如果不同的业务部门在解决方案方面作出不同选择，同样要考虑这样因素。在这样一种环境下，集中式的中心辐射型（hub and spoke）架构即便采用集群也根本不具有良好的扩展性。如果我们试图部署到中心辐射型系统组成的分布式集群，路由和业务规则的集中管理这一传统强项也会变成弱项。

有了ESB，企业就能够从少量充当聚合点的初始容器无缝扩展到由局部化集成点组成的多层网络。

但是新平台迅速成为自己成功的牺牲品，原因在于一旦新平台向外扩展，大多数企业变得完全依赖它们，这样几乎不可能安排时间让系统停运，以便维护或者改进。任何停运时间都会马上影响销售或者增加成本。

能够管理实行变化的成本，这是任何解决方案的关键；而ESB在这方面同样很出色。使用轻便的分布式容器，这意味着新服务随时可以从中央服务器“动态”部署到远程节点上，不会带来任何停运时间。

这还意味着，使用中央消息总线可确保服务下线后，与活动业务流程有关的消息被留在队列上，直到重新开始处理。

比较旧的解决方案，比如中心辐射型引擎，也许能在业务部门内部扮演集成解决方案的角色；而ESB却是把横跨企业、需要利用各组件的诸多业务流程联系起来的必然解决方案，它采用了一种商定、安全的方式，往往有着不同的架构、用不同技术实施。

标准化有望让包括业务流程执行语言（BPEL）引擎在内的异构组件可以连接到不同厂商的ESB。ESB改变了集成的意义，能够迅速引入规范的SOA机制，有望带来技术和经济方面的显著效益。