本系列编译自 O'Reilly的《Enterprise Service Bus》，将陆续发布上来。
1 企业服务总线简介
在一个事件驱动型企业中，影响业务流程的正常进程的业务事件可以以任何顺序随时发生。那些以自动化的业务处理方式交换数据的应用需要使用事件驱动的 SOA 来彼此通信，以便能够对不断变化的业务需求具有敏捷的反应。SOA 向业务分析师和集成架构师提供了处理高阶服务的关于应用和集成组件的宽泛的抽象视图。而在 ESB，应用和事件驱动的服务彼此以一种松散耦合的紧密地与流行的 SOA 维系在一起，这允许它们彼此能够独立运行，并且仍然能够提供较宽广的业务功能价值。
在 SOA 的王国，事件被表现为一种开放的XML格式文件，以及经过一个对验证开放的，可以协调的透明管线中的流（Flow）
—John Udell, InfoWorld
SOA 的服务组件暴露的是一种粗粒度的接口，其目的是使应用之间能够异步地共享数据。而使用 ESB，一种集成架构将应用程序和分离的集成组件拉在一起，以产生服务装配组合从而形成复合的业务流程，进而自动化一个即时企业中的业务功能。
ESB 为SOA提供实现骨架。那就是说，它通过一个跨越多种协议的消息总线来提供一个有关命名路由目的地的高度分布的世界来提供松散耦合的，事件驱动的 SOA。ESB 中的应用程序 (和集成组件) 在理论上是彼此解耦的，而且通过总线彼此连接为暴露为事件驱动服务的逻辑端点。
通过分布式的部署配置基础设施， ESB 能有效率地提供对在扩展企业中分布的服务的中心配置、部署和管理。一种普遍集成的新方式应用诸如SOA、EAI、B2B 和Web服务之类的技术的通常目标主要是创建一个集成架构，且能够深入并且跨越整个扩展企业。对于一个集成基础设施到达到这种普遍性，它必须具有下列各项特性:
- 它必须能够适应多种集成情形项目的通常目的需要，不管是大型的还是小型的。适应性包括提供一个能够经受协议、接口技术、甚至流程模型的变化趋势的持久架构。
- 它必须以一种单一和统一的方式，以及一个通用的基础设施来连接扩越扩展企业的各种应用。
- 它必须能够扩展超出单一公司IT中心的边界。并且自动化伙伴关系，比如在B2B 和供应链的情况下。
- 它必须具有设计的简单性和较低的进入门坎，使得日常的IT专业人员也能够成为自我修练的集成架构师。
- 它必须提供一个跨越普遍集成的 SOA，它能使集成架构师能够对公司的应用资产和自动化业务流程有一个广泛的、抽象的视图。
- 它需要有能够反应和符合不断变更的业务需求和竞争的压力需要的灵活性和能力。
在 ESB中，应用和事件驱动服务以一种松散耦合的方式紧密地联系在SOA 中。 这使得它们能够彼此独立运行，并且仍然能够提供广泛的业务功能价值。
ESB 架构解决了这些需要，并且正在被各种通用的集成项目所采用。它也能够在企业应用层面普遍地伸展，不管是物理位置还是技术平台。任何应用都可以通过大量的连接选择插入到一个 ESB 网络中，并且可以立即参与到与那些通过总线暴露为共享服务的应用之间的数据共享之中。这是 ESB 为什么经常被称为集成网络（integration network）或集成构造（fabric）的缘故。
ESB 提供为集成提供了一种高度分布式的架构，并且具有能够让独立的部门和业务单元能够以一种逐渐增加的、可消化的分块来构建它们的集成项目的独特能力。使用 ESB，部门和业务单元仍然能够继续在独立的集成项目中维护它们自己的本地控制和自治，并且仍然能够将它们的集成计划连接到一个更大的、更全局的的集成网络或网格之中。
Web 服务已经通过为应用间的互操作性提供一种基于标准的方式为面向服务架构找到了新的重要性。Web服务的主要目的是提供了一种服务抽象，它允许应用之间的互操作性使用不同的平台和环境来构建。这一个目标的实现将能够提供一个应用之间的普遍集成的更容易的路径。
由于ESB的出现，现在有了一种方式能够将Web Services和SOA合并到一个意义非凡的架构中，以将应用和服务以一种高度伸缩的状态集成到一个扩越扩展企业的骨架之中。ESB使用今天已经成熟的技术立刻使得Web Services、XML、以及其他集成技术更加有用。
SOA 的核心原则对于普遍集成项目的成功至关重要，并且已经在 ESB 中被彻底实现。 Web Services标准正在有朝着正确的方向前进，但是在提供企业级能力方面还未完成，比如安全性、可靠性、事务管理和业务流程编排。ESB 以这些领域中今天已经确定的标准为基础，而且已经有实际实现部署在各种领域和行业中。ESB完全有能力跟上Web Services相关能力的革新进展步伐。第 12 章提供了更详细的关于这一个主题的讨论。
ESB 通过从EAI中介者（Broker）那里学来的概念和技术将Web Services和其他补充标准结合在一起。然而，ESB 并不仅仅是在同一个老式的EAI 集线器之上的简单的Web Services外衣。
传统的形式化的集成方法都有其优缺点。第 1 章就展示了有关集成的一些高阶的显著特色， 范围从左下方最不令人想要的，到右上方象限中的最令人想要的。
图表 1‑1 传统的 EAI 中介器，应用服务器，MOM和 ESB 的特性
传统的 EAI 中介器，包括那些已经构建在应用服务器之上的，使用一种集线器和插头（hub-and-spoke）架构。集线器和插头有一些中心化功能的好处，比如路由逻辑和业务规则的管理，但是不能很好地伸展扩越部门和业务单位的边界。第 2 章将讨论使用集线器在集成中的早期尝试的巨大代价，以及它们的初步成功。
应用服务器可以通过标准协议进行互操作，然而它们是以一种紧密耦合的方式进行连接的，并且集成逻辑和应用程序逻辑纠缠在一起。
EAI 中介器通过将应用逻辑从集成和流程路由逻辑中分离出来提供了增加价值，然而你仍旧要忍受集线器-插头架构的痛苦。
面向消息中间件 (MOM) 提供了以松散耦合和异步的方式连接应用的能力。然而，MOM自身需要在应用中进行低级的编码。使用传统的MOM，以及定制的编程技术，比可以在分布式的集成解决方案上走得更远。然而，没有对路由逻辑的高阶抽象，这种方式仍然要忍受集成逻辑难以连接，并且也和应用逻辑纠缠在一起的痛苦。依赖于MOM的使用，即使是分布式特征也会受到限制，因为一些传统的MOM基础设施对实际的网络边界的跨越也不是做得很好。
最后，在 ESB 中，服务可以被配置而不是编码。处理流程和服务能够透明地跨越整个服务总线。ESB 提供了能够很好地扩越集线器-插头架构范围的高度分布式集成环境，并且清晰地分离了应用逻辑和路由数据变换之类的集成逻辑。一个 ESB 架构形成了一个消息集线器和集成服务的互连接性网格，具有一个彻底分布的集成网络的功能性和智能性。
第 6 章更进一步描述在使用应用服务器集成和使用ESB集成之间的对比。MOM的概念在第 5 章讨论。第 2 章的 “附属架构”继续讨论业务流程路由逻辑和业务逻辑之间的分离。
ESB 的一个关键特性就是要为支持分布式的、松散耦合的业务单位和伙伴，比如自动化供应链，提供支撑基础。ESB 的这些能力是其固有的必要特征，并且是中间件厂商与那些想要创建大规模集成架构的业界专家共同工作的结果。这些业界专家包括了大公司IT架构师、以及电子市集贸易社区中想要基于共享服务、消息、XML何其他众多的连接选择来建立B2B集成骨架的改革者，并且要坚持遵守工业标准。第 3 章将会讨论对 ESB 概念的创造有助益的许多催化剂。
同时，仍然必须解决的最大需要在于如何还没有的最大需要被定址包括该如何有效地提供集成能力、比如应用适配器、数据变换、以及能够用于通用的集成项目，跨越多种集成情性的智能路由。并且需要超越于个别战术性的集成项目之上的，更加通用的技术和更加架构性的方式。
IT专家已经对以前的一些技术趋势失望，比如CORBA、或者EAI什么的。CORBA 有着与SOA 一样的正确理念，但是其与生俱来就太复杂而难以维护，因为它依赖于应用和服务之间的紧密耦合接口。EAI 也痛苦于对单个项目上的陡峭的学习曲线和昂贵的进入负担 (下一章将详细讨论这个内容)。真正需要的是SOA的简单方式，以及可以被采用来适应任何集成工作，大型或者小型，的一种架构。此外，那就是需要一个能够经受协议、接口、甚至业务建模趋势的变革的持久架构。ESB的概念就是创建来解决这些需要的。
自从ESB 概念在 2002 年被首次引入，ESB 的集成方式已经被中间件、集成和Web服务市场中的很多重要的厂商采用。其接受度正在稳定持续地增长。
从2002年早期开始，分析公司，比如 Gartner 公司、IDC、ZapThink等，就已经开始跟踪和编写有关 ESB 的技术趋势。在Gartner 公司于2002年发布的一份报告(DF-18-7304)中，分析师 Roy Schulte 这样写道：
一种新型的 企业服务总线架构- 结合了面向消息中间件（MOM）、Web Services、数据变换和智能路由的基础设施—将会 2005 之前在很多的企业中运行。
这些高功能、低成本的ESB能够被很好地适应作为面向服务架构和企业神经系统的主干。
那四个支柱—MOM、Web Services、数据变换和路由智能 — 表现了任何优秀的ESB 的基础。当我们探究 ESB 的时候，本书将会集中于其中每一个基础和其他必须的组件的角色。我们还要讨论将会讨论 ESB 究竟能为企业做些什么、以及它的基本组件所扮演的角色。我们还要讨论一些高阶主题，包括横越多种行业之上的实践性使用的架构性概述。
有许多中间件和集成厂商已经，或者正在构建，符合ESB描述的某些产品。并且这个名单还在不断增加。附录中列出所有的已知厂商。一些厂商已经声称他们已经开始提供 ESB了 ；而有些则正在计划构建；有些则只是在市场宣传材料中使用这一技术术语而实际上背后还没有实质性的东西。当超过 25个厂商正在为相同的技术空间竞争的时候，这一个技术范畴注定要变成像上世纪90年代的应用服务器一样的炙手可热。
这个清单中有个别厂商应该特别提及。Sonic软件最先倡导了这个概念，此后不久许多其他的较小厂商业进入此领域，声称他们也正在提供 ESB 或是正在开发之中。一但那些著名的集成公司，比如webMethods、SeeBeyond 和 IBM 最终搭上这趟巴士（“BUS”），并且想要开始建立他们的ESB，ESB 术语才真的开始广泛引起业界注意，是一个强大的不断发展技术范畴。
在本书写作的时候，微软公司还没有对其Indigo项目和有关ESB发布任何公开的说明。然而，一些记者和分析师在Indigo项目宣布的时候还是将二者联系起来。2003 年11月 30 日， ComputerWorld 的文章说，“开发人员的兴趣被微软的技术伤害了”，Gartner 公司的 Roy Schulte关于Indigo项目提出。
Roy Schulte，是Gartner 公司在斯坦福的一个分析师，注意到Indigo项目其实是微软消息队列（MSMQ）、公司的COM、COM+、.Net Remoting、以及Web Services技术的超集。“把它想成代表微软公司的通信中间件计划的简化和统一，”他说，并说他认为Indigo是一个非常好的企业服务总线(ESB)。
Indigo以消息为基础，并且打算结合MSMQ 和Web Services。可以提供一个消息总线的基础。然而，其集成能力的其余部分则被锁定到BizTalk 之内，而它是一个集线器-插头风格的集成服务器。为了成为真正的ESB，分布式消息总线和分布式集成能力都要具备。
如果Indigo项目完成，构建于微软平台之上的应用和服务将能够更加吸引人地作为端点连接到ESB之上。将Indigo包含到微软平台和开发环境之内将更加能够使得应用具有松散耦合和消息感知能力。