文章来源:http://www.blogjava.net/SteelHand/archive/2007/08/07/134929.html
Tags: ESBESB | SOASOA
2007-8-10 13:45:18 | 编辑
企业服务总线（ESB）
1 企业服务总线简介
1.1一个事件驱动型企业中的SOA
在一个事件驱动型企业中，影响业 务流程的正常进程的业务事件可以以任何顺序随时发生。那些以自动化的业务处理方式交换数据的应用需要使用事件驱动的 SOA 来彼此通信，以便能够对不断变化的业务需求具有敏捷的反应。SOA 向业务分析师和集成架构师提供了处理高阶服务的关于应用和集成组件的宽泛的抽象视图。而在 ESB，应用和事件驱动的服务彼此以一种松散耦合的紧密地与流行的 SOA 维系在一起，这允许它们彼此能够独立运行，并且仍然能够提供较宽广的业务功能价值。
在 SOA 的王国，事件被表现为一种开放的XML格式文件，以及经过一个对验证开放的，可以协调的透明管线中的流（Flow）
—John Udell, InfoWorld
SOA 的服务组件暴露的是一种粗粒度的接口，其目的是使应用之间能够异步地共享数据。而使用 ESB，一种集成架构将应用程序和分离的集成组件拉在一起，以产生服务装配组合从而形成复合的业务流程，进而自动化一个即时企业中的业务功能。
ESB 为SOA提供实现骨架。那就是说，它通过一个跨越多种协议的消息总线来提供一个有关命名路由目的地的高度分布的世界来提供松散耦合的，事件驱动的 SOA。ESB 中的应用程序 (和集成组件) 在理论上是彼此解耦的，而且通过总线彼此连接为暴露为事件驱动服务的逻辑端点。
通过分 布式的部署配置基础设施， ESB 能有效率地提供对在扩展企业中分布的服务的中心配置、部署和管理。一种普遍集成的新方式应用诸如SOA、EAI、B2B 和Web服务之类的技术的通常目标主要是创建一个集成架构，且能够深入并且跨越整个扩展企业。对于一个集成基础设施到达到这种普遍性，它必须具有下列各项 特性:
n 它必须能够适应多种集成情形项目的通常目的需要，不管是大型的还是小型的。适应性包括提供一个能够经受协议、接口技术、甚至流程模型的变化趋势的持久架构。
n 它必须以一种单一和统一的方式，以及一个通用的基础设施来连接扩越扩展企业的各种应用。
n 它必须能够扩展超出单一公司IT中心的边界。并且自动化伙伴关系，比如在B2B 和供应链的情况下。
n 它必须具有设计的简单性和较低的进入门坎，使得日常的IT专业人员也能够成为自我修练的集成架构师。
n 它必须提供一个跨越普遍集成的 SOA，它能使集成架构师能够对公司的应用资产和自动化业务流程有一个广泛的、抽象的视图。
n 它需要有能够反应和符合不断变更的业务需求和竞争的压力需要的灵活性和能力。
在 ESB中，应用和事件驱动服务以一种松散耦合的方式紧密地联系在SOA 中。 这使得它们能够彼此独立运行，并且仍然能够提供广泛的业务功能价值。
ESB 架构解决了这些需要，并且正在被各种通用的集成项目所采用。它也能够在企业应用层面普遍地伸展，不管是物理位置还是技术平台。任何应用都可以通过大量的连 接选择插入到一个 ESB 网络中，并且可以立即参与到与那些通过总线暴露为共享服务的应用之间的数据共享之中。这是 ESB 为什么经常被称为集成网络（integration network）或集成构造（fabric）的缘故。
ESB 提供为集成提供了一种高度分布式的架构，并且具有能够让独立的部门和业务单元能够以一种逐渐增加的、可消化的分块来构建它们的集成项目的独特能力。使用 ESB，部门和业务单元仍然能够继续在独立的集成项目中维护它们自己的本地控制和自治，并且仍然能够将它们的集成计划连接到一个更大的、更全局的的集成网 络或网格之中。
1.2针对 Web 服务的SOA，如今已经可用
Web 服务已经通过为应用间的互操作性提供一种基于标准的方式为面向服务架构找到了新的重要性。Web服务的主要目的是提供了一种服务抽象，它允许应用之间的互操作性使用不同的平台和环境来构建。这一个目标的实现将能够提供一个应用之间的普遍集成的更容易的路径。
由 于ESB的出现，现在有了一种方式能够将Web Services和SOA合并到一个意义非凡的架构中，以将应用和服务以一种高度伸缩的状态集成到一个扩越扩展企业的骨架之中。ESB使用今天已经成熟的 技术立刻使得Web Services、XML、以及其他集成技术更加有用。
SOA 的核心原则对于普遍集成项目的成功至关重要，并且已经在 ESB 中被彻底实现。 Web Services标准正在有朝着正确的方向前进，但是在提供企业级能力方面还未完成，比如安全性、可靠性、事务管理和业务流程编排。ESB 以这些领域中今天已经确定的标准为基础，而且已经有实际实现部署在各种领域和行业中。ESB完全有能力跟上Web Services相关能力的革新进展步伐。第 12 章提供了更详细的关于这一个主题的讨论。
1.3常规的集成方式
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 章的 “附属架构”继续讨论业务流程路由逻辑和业务逻辑之间的分离。
1.4被IT需要驱动的需求
ESB 的一个关键特性就是要为支持分布式的、松散耦合的业务单位和伙伴，比如自动化供应链，提供支撑基础。ESB 的这些能力是其固有的必要特征，并且是中间件厂商与那些想要创建大规模集成架构的业界专家共同工作的结果。这些业界专家包括了大公司IT架构师、以及电子 市集贸易社区中想要基于共享服务、消息、XML何其他众多的连接选择来建立B2B集成骨架的改革者，并且要坚持遵守工业标准。第 3 章将会讨论对 ESB 概念的创造有助益的许多催化剂。
同时，仍然必须解决的最大需要在于如何还没有的最大需要被定址包括该如何有效地提供集成能力、比如应用适配器、数据变换、以及能够用于通用的集成项目，跨越多种集成情性的智能路由。并且需要超越于个别战术性的集成项目之上的，更加通用的技术和更加架构性的方式。
IT 专家已经对以前的一些技术趋势失望，比如CORBA、或者EAI什么的。CORBA 有着与SOA 一样的正确理念，但是其与生俱来就太复杂而难以维护，因为它依赖于应用和服务之间的紧密耦合接口。EAI 也痛苦于对单个项目上的陡峭的学习曲线和昂贵的进入负担 (下一章将详细讨论这个内容)。真正需要的是SOA的简单方式，以及可以被采用来适应任何集成工作，大型或者小型，的一种架构。此外，那就是需要一个能够 经受协议、接口、甚至业务建模趋势的变革的持久架构。ESB的概念就是创建来解决这些需要的。
1.5行业的牵引
自从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 究竟能为企业做些什么、以及它的基本组件所扮演的角色。我们还要讨论一些高阶主题，包括横越多种行业之上的实践性使用的架构性概述。
1.5.1 采用 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包含到微软平台和开发环境之内将更加能够使得应用具有松散耦合和消息感知能力。
1.6.1ESB 的特性
由于试图快速进入成长中的 ESB 范畴的厂商的慌乱，以及大量行业分析师和记者在分析报告中分别展示他们各自的观点，可以理解，这其中对于ESB 到底是什么还具有很多混淆。这一节将概略说明 ESB 的主要特性。
1.6.1 普遍性
如第 1 章所示， ESB 能形成普遍的网格的核心。它能够跨越和超过扩展企业，并且横跨部门组织、业务单位和贸易伙伴形成全局的范围。ESB 也能很好地适合于局部的集成项目，并且对促进它们采用任何类型的集成环境提供柔性的支撑。
图表 1‑2 ESB 形成一个能跨越了一个全球企业网络的普遍网格
应用可以按需插入总线，并且具有可视性，以及能够与其它已经插入到总线中的任何其他应用和服务共享数据。虽然Web Services是 ESB 架构的一个有机组成部份，但是所有的应用并不是一定要被修改成为真正的Web Services才能参与到 ESB。连接性是通过多种协议、客户端API 技术、遗留消息环境、以及第三方应用适配器来达到的。
1.6.2 基于标准的集成
基于标准的集成是 ESB 的基本概念。对于连接性，ESB 可以使用J2EE组件，比如使用Java Message Service (JMS)来进行MOM连接，使用J2EE 连接器结构 (JCA 或 J2CA) 来连接应用适配器。ESB 也能够非常漂亮地与使用.Net、COM、C#、C/C++构建的应用进行集成。除此之外，ESB 也能集成支持SOAP和Web Services API的任何组件，这其中包括事实上的标准Web Services工具箱的实现，比如Apache Axis。为了处理数据操纵， ESB 可以使用XML标准，比如XSLT、XPath 和 XQuery 来提供数据变换、智能路由、以及在数据流过总线的时候提供“空中”查询。为了处理 SOA 和业务流程路由， ESB 可以使用 Web Services描述语言 (WSDL) 来描述抽象的服务接口，使用针对Web Services的业务流程运行语言(BPEL4WS)、WS- Choreography或者一些其他基于XML的词汇表，如 ebXML BPSS，来描述抽象的业务流程。
如果你还不懂这些深奥的词汇的含义，也不要担心。虽然本书并不想作为是这些各个技术的详细参考或个别指导，我们也会在他们如何与 ESB 有关的语境中足够详细地解释它们。
这些基于标准的接口和组件被整合到一个意义非凡的包含开放端点的可插入架构之中。ESB提供了一种基础设置来同时支持基于工业标准接口集成 组件和使用标准化接口来实现的专有元素。下图展示了一个使用JMS和JCA集成一个 J2EE 应用、使用JCA应用适配器集成第三方打包软件、使用C#客户端程序集成一个.NET应用、使用Web Services集成两个外部应用的案例的高阶视图。
图表 1‑3 ESB 整合多种不同的技术
1.6.3 高度分布的集成和选择性部署
ESB 在其中借鉴了传统EAI Broker的许多功能，比如从它提供集成服务 , 像是业务流程编排、数据路由、数据变换、以及应用适配器。然而，集成中介者通常是高度集中和单一的形态。ESB 将这些集成能力提供为独立的服务，能够以一种高度分布的形态一起工作，并且能够彼此间独立伸缩。在第 6 章中，你将会学习更多有关 ESB“服务容器”，ESB 的一项核心概念的内容，它允许对集成服务进行选择部署。
1.6.4 分布式数据变换
任何集成策略的一个关键部分就是能够轻易地在应用之间转换数据格式的能力。许多应用对描述相似的数据并不共享相同的数据格式。
数据变换是一个 ESB部署的一个固有部份。变换服务特别针对那些被插入总线的个别应用能够在总线的任何地方被定位和访问的需要。因为数据变换是ESB 本身的一个有机组成部份，解决应用之间的阻抗失配问题便可以想到ESB。
1.6.5 通过分层的服务来达到可扩展性
ESB 能够为你提供本质上针对任何集成项目所必需的核心能力，并且可以通过使用分层的服务来处理特定的用途来增加。例如，特殊的能力，比如业务流程管理 (BPM) 软件能处理工作流相关的业务流程，而协作服务器能够提供对伙伴业务流程管理的特殊服务。专门的第三方翻译器能够将外部数据，比如EDI，转换到能进入目标 企业资源规划 (ERP) 系统之内的格式，或者在通用总线之上的规范XML表现。
1.6.6 事件驱动的 SOA
在 ESB驱动的、事件驱动的 SOA中，应用和服务被当做抽象服务端点，能够轻易地对异步事件做出响应。SOA 对其底层的连接性和管线细节提供了一个抽象的方式。服务的实现不需要理解协议。服务也不需要了解消息是如何路由到其它服务的。他们只是简单地将接收自 ESB 的一个消息作为一个事件，然后处理该消息。ESB 可以把消息发送到它想要去的其他任何地方。
在 ESB SOA 中，用户定制服务可以被创建、扩展，并且被重用为ESB 功能。被暴露为服务的应用端点，可以同特殊的集成功能一起构造成复合业务服务和业务流程，并且它们可以根据不同目的重新组合，其目标是在一个即时企业中提供自动化的业务功能。
第 7 章将会更详细地讨论 ESB 中的 SOA 。
1.6.7 处理流
ESB的处理流从简单的优先步骤序列到使用条件分支和联合来并行执行的综合业务流程编排。这些特征可以使用简单的消息元数据或者通过使用诸如BPEL4WS 之类的业务编排语言来控制。
ESB 的处理流能力使得定义属于某个部门或者业务单位局部的，或者共存于一个较大的集成网络中的业务流程成为可能。这点却是一个集线器-插头中介者或一个 BPM 工具自己所不能很好地自己解决的问题。第 7 章将会详细讨论分布式的流程能力，它能提供高度分布的流程编排能力而不需要中心化的流程和规则引擎。
ESB的业务流能力也涉及到基于内容的消息的智能路由的特殊集成服务。
因为ESB 的业务流能力构建于分布式的SOA之上，它也能够跨越高度分布的物理部署拓扑（甚至扩越大洋）而不用痛苦地忍受总线上各种应用和服务之间的物理边界和多协议的鸿沟。
图表 1‑4 跨越物理和逻辑边界之上的部署拓扑的编排和业务流
1.6.8 安全和可靠性
在 ESB 上的节点之间的连结是具有防火墙能力的。应用和 ESB之间的安全性，甚至在 ESB 节点自身之间的安全性，能够建立和维护最高强度的认证、凭证管理、和访问控制。
可靠性是通过处于ESB核心的企业级MOM来达到的。MOM核心提供异步通信能力、业务数据的可靠传输、以及事务的完整性。你们将在第 5 章中学到，这已经不是十年以前的传统MOM技术了。需求从那时以后开始进展，并且已经成熟，而 作为ESB 的核心的MOM必须符合今天的需求。
1.6.9 自治但联邦的环境
传统的集线器-插头中介者方式往往具有组织性的边界问题，这主要是因为EAI Broker对跨越防火墙和网络域的无能的实际限制所引起。更重要的是，即使一个集线器-插头架构能够被伸展而跨过组织的交界，它仍然不允许各个业务单位 彼此半独立地运行所需要的局部自治。与不断扩展的集成范围延伸超过部门层次所相关的最大问题之一是自治和集中控制之间的问题。
作为大多数大型公司环境的业务文化的一部分，每个部门或业务单位需要彼此独立地运作。 然而，他们仍然依赖于共享资源，以及输入到通用业务功能之中的报告和帐户信息。
在这样一个环境中，需要所有的消息流量都流过位于总部的一个集中的消息Broker的集成策略是不合理的。 这不只是一个技术上的障碍；它也是公司文化的问题。在一个松散耦合的业务单元环境中，诸如本地应用之间的业务流程，或者安全域，被一个集中化的公司IT功 能管理简直没有一点道理。组织中的松散耦合业务单元需要彼此独立地运作。他们每一个都应该有其自己的IT功能，而不必须路由所有的消息流量，或代表它的业 务规则和安全域的控制, 经过一个集中的集成经纪人在一个位置或另一个(第 1 章)。
图表 1‑5 如果使用一个集中的集线器，分开业务单位缺乏必需的自治-和-了集成经纪人
本地业务单位和部门需要有对他们自己的局部IT资源的控制，比如在其站点运行的应用。集成基础设施应该支持部署拓扑来支持具有实用性的业务 模型。ESB 也提供这种部署模型， 允许本地流量、集成组件以及适配器能够被本地安装、配置、加固和管理，并且仍然能够以一种集成的安全模型一起将本地集成域插入到一个更大的联邦集成网络之 中。
图表 1‑6 自治的而且公布联邦制,ESB 允许横过组织的交界对合作地同盟的运算组织
ESB 的分布式特征是通过从实际的部署细节和底层的连接协议中抽象出来的将端点定义，以及在那些端点之间的数据的编排和路由来达到的。联邦特征则是通过 ESB 能够隔离和选择地横过应用域和安全边界的能力来达到的。
1.6.10 远程配置和管理
在一些业务模型中，在每一个远程地点都安排有本地的IT职员是不大可能的，虽然仍然需要松散耦合的、自治的联邦的集成网络。举例来说明这一个点，我 们来想象一下部署在零售行业中的ESB 的案例。一个视频租借链可能有数百或数千个包含相同应用的地点，所有以相同的形态运行的操作涉及到目录管理、会计和报表等。
图表 1‑7 和数以千计遥远的储存一个视像零售链,所有的包含应用程序的相同组
使用 ESB，可以建立一个集成蓝图来处理远程店铺中的局部应用之间的通信。这包括店内应用的接口定义、消息流量的路由、消息通道的管理、以及安全许可。它还可 能包括集成组件，比如应用适配器、协议适配器或者数据变换器。这个集成蓝图，或称模板，可以在所有地点进行部署和定制，并且独立地扮演所有其他店铺。
图表 1‑8 ESB 配置蓝图在每个遥远的位置和很远地展开配置而且处理
这个远程部署蓝图的能力并不单针对零售行业，它也可以扩展到所有其他行业的应用。联邦的集成域的远程管理对于在一个高度分布的环境中的任何ESB的成功部署都是非常关键的。
安全、可靠的消息联结
除了在每个店铺的本地应用之间共享数据之外，这些远程店铺还需要同总部共享信息以便进行帐务处理和报表、信用管理以及职员数据的追踪。远程 店铺还需要彼此之间共享信息。举例来说，一个大型的音像连锁店可能会提供这样的服务，顾客可以选择从离家近的店租赁影碟，然后在离办公室近的另一个店归 还。因此，在同一个地理区域内的店铺之间可能会需要以近乎实时的状态共享有关租赁的数据。因为在远程店铺和总部之间的卫星网络通信连接存在较大的反应期和 弹性，要在总部维护一个有关所有租赁信息的实时集中访问点是不现实的。那些有关你只是在两个小时之租借的数据需要共享，或者通过远程店铺之间的一个集成的 数据共享连接来进行访问。
因为总部和远程店铺之间的连接是通过可靠的消息来达到的，因此由于不可靠的卫星电路所造成的网络服务终端可以从消息层得到补偿。也应该注意到，对于远程店铺之间来说，通过Internet来建立一个安全和可靠的消息通道也是可以的。
1.6.11 作为ESB的“原生”数据类型的XML
当数据通过ESB 在应用之间流动的时候，XML是一个表现它们的理想基础。被应用程序的一个巨大的行列生产而且耗尽的数据能以多种的格式存在和包装方案。有大量的应用产生 和消费的数据，可以以各种格式或者打包的Schema存在。对ESB来说虽然的确可以依你喜欢的打包形式或者封装方案来承载数据，但将途中数据表现为 XML具有莫大的好处，包括使用能够结合来自于不同的源数据以创建一个新的数据视图的产生数据的特殊 ESB 服务， 以及针对应用间高级数据共享的浓缩和重定目标。第 4 章将会探究使用XML功能本好处—将避免一个组织的应用间同步升级的需要—并且更详细地讨论分布式XML变换之后的基本原理。
1.6.12 业务数据的实时吞吐
ESB通过为途中数据在总线之上的应用间传输的时候提供实时吞吐消除了潜伏反应问题。目前，最流行的集成方法之一是每夜进行批处理。 然而，打包的成批处理集成策略，不管是每夜还是其它，都具有较高的边际错误率，并且造成信息获取的延迟。其结果是高反应期产生获取了过时数据将使代价高昂 的。第 9 章将详细讨论这个问题，并且研究 ESB 可以如何用来将你的业务数据从每夜批处理模式重构为实时吞吐模式。
1.6.13 运行感知
运行感知意思是业务分析师能够获得对业务运行的状态和健康情况的洞察能力。 一个允许对数据在其以某个业务流程中的某个消息形式在组织中流动时进行实时跟踪和报告的基础设施，对于帮助建立运行感知是一个无价的工具。一个称为是业务 活动监控 (BAM)的产品门类已经出现来解决运行感知的这些问题。
使用XML作为ESB的原生数据格式的好处之一就是消息没有被处理为不透明的数据块。如果应用和服务之间的所有数据都被格式化为XML文 档，ESB提供的基础支撑便允许你在ESB之上再构建一层高级能力，以获得对流过你的企业的业务数据的实时洞察能力。这些能力，不管是否是ESB的固有组 成部分，还是有一个扩展来驱动，都表现为包括了路由、处理流、以及下层的管线，并且不需要再在其上锁定一个第三方的BAM产品的一个通用基础设施的一个有 机组成部分。
作为ESB的一个基础部分的审计和跟踪能力允许对在SOA中的所有流动的业务流程和消息流的健康状况进行监控和跟踪。诸如数据缓存、数据 收集和聚集、以及XML数据的可视化表现之类的增值服务，可以用来创建一个基础服务，该基础服务可以在数据在企业中流动时，产生对业务流程的状况洞察的警 告、提醒和报表能力。
图表 1‑9 增值型服务促成操作的觉察提供对活的业务数据的即时洞察
对ESB中的数据的根踪和报表是通过在业务流中定义审计点来达到的，然后再对从业务消息中收集的重要内容在ESB中流动时提供插入点。可追踪数据例子是业务消息自身，以及指示某业务消息是否通过了某个特定的业务处理步骤的业务事件。
高级的增值服务可以提供数据收集服务、查询机制以及报表能力，它们能够讲所有数据进行收集、进而表现为各种具有意义的形式。XML持久性服 务可以提供缓存和聚集点，这样可以收集将要转换的数据从而向其他应用提供数据输入，或进入到可以被业务分析师使用的人可读的报表机制之内。这意味着流经 ESB的数据可以进行实时分析，以提供有关你的业务状态的实时信息—比如，可以随时提供有关你的供应链中的存货的状态快照。
1.6.14 逐渐采用
区别是否真正是 ESB 的一个主要方面是看其是否具有逐渐采用的能力，相对于另一个“全有-或-全无”的论断。在 Y2K 之后的开支削减中，数百万美元预算的项目数目已经今非昔比。有一些迹象表明，预算资金筹备正在开始释放以解决短期的战术性集成需要，但是预算仍然谨慎地处 于一个执行层面。，然而，同时仍然有一些期望实现较大的公司范围集成策略计划—这些计划严重依赖于集成和现有IT资产的重用。
图1-10说明了 ESB 可以如何用于小项目中，然后它们都可以进入到一个更大的集成网络之内。 当我们深入阅读本书的时候，我们会详细研究这是如何实现的。
图表 1‑10 ESB 支持逐渐采用的集成，同时向着一个策略目标工作
ESB 的联邦/自治能力也对一次一个项目采用 ESB的能力有助益。ESB 集成项目渐进式的分布部署能够在朝着一个更广的企业层面的计划目标的前提下得到立即价值。
逐渐采用的观念将进一步通过桥接到一个已有的集成Broker集线机器和遗留系统Broker来得到进一步支持。集成Broker集线器和他们的特点将在第 2 章中详细研究。
