从偶然架构到一个全球规模的统一的集成基础设施可能是像一个使人畏缩的任务。 把一切都准备就绪，然后再象扳动一下开关那样将所有的应用都一下子转移到新的基础设施之上是不现实的。这已经是组织为什么老是要不断添加偶然架构方案作为权益解决之计的一个主要的理由，甚至他们确实知道这样使相关的问题永垂不朽也是如此。

ESB 提供了能力来帮助减轻所介绍的痛苦。 第 9 章将通过一个案例来介绍如何远离一个完全建立在 FTP 和每夜批处理作业之上的早以存在的集成解决方案。

让我们现在重新回到对偶然架构的讨论。 在图 2-6中，实线、虚线、点划线代表用于集成的不同类型的连接技术和通信协议。注意其中有一个用集成Broker表达的已存在的 “集成孤岛”，以及POS应用和财务应用之间的连接是使用FTP 文件传输。在POS应用和ERP应用之间先前已经升级来使用HTTP 之上的SOAP协议，正如销售自动化应用 (SFA) 和客户关系管理 (CRM) 之间的联结。

图表 2‑6 使用SOAP通信、 FTP 、手工插座（Socket）、而且包括一个集成Broker的代表性的偶然架构

2.4.1 从单个项目层面引入 ESB

ESB 可以在一个部门级的层次或在一个项目的基础上被引入。 在项目层次采用 ESB 允许你能够习惯于使用 ESB 服务容器进行基于标准的集成，并且完全可以坚信该项目能够集成到一个更大的集成网络之中，并且与企业级的公司的集成策略目标相一致。

我们采用ESB的例子中的第一个步骤是要集成前端应用（FrontOffice）。在图 2-7 中，前端的CRM、财务和SFA 通过“服务容器”连接到ESB 之中。这些容器是 ESB 架构的主要组件，我们将在第 6 章详细解释。 经过 ESB 服务容器进行的集成的特性可能会不同。 容器和应用之间的接口可以通过使用第三方的应用适配器来完成；容器可以暴露使用WSDL描述的XML数据；或者它可能被实现为完全用户定制的代码。

图表 2‑7 ESB 可以在不打破原有点对点路径的前提下，在单个项目基础上采用

但是也许更有趣的不是那些已经集成到ESB 之内的东西，而是还没有集成进去的东西。图 2-7 表示了已有的 FTP 和SOAP协议之间的通信线，原来是连接到前端应用的，现在直接连接到那些特别配制来使用那些协议进行通信的ESB组件。应用仍然处于总线“之外”，Pos应用和伙伴CRM应用可以与集成到ESB总线“之内”的前端应用进行通信而不需要做任何修改，对他们如何参与ESB基础设施也不需要知道任何东西。注意，现在POS应用是连接到ESB 上的一个 FTP 桥接器，而且伙伴CRM应用则是连接到配置为总线的一部分的Web Services端点。

ESB 已经被引入了，但是对这些配备了ESB能力的应用以前所连接的点对点通信组合区没有产生任何影响。被插入总线的应用如今转而使用连接到ESB 集成容器的一个单一接口， 而且已经省却了对它们先前所有其他类型的通信连接的管理和维护。

我们将会在第 9 章中看到，即使是总线域中最新集成的应用也可以就地将他们转移到完全的ESB方式，并且与它们各自的项目开发时间线相一致。

2.4.2 跨广泛分布的企业传播ESB

在我们的ESB采用的例子得下一阶段中，POS应用将在每一个远端实现ESB能力，并且去除对不可靠的 FTP 联结上的依赖。 这可能会简单如在每一个远端安装一个ESB容器，并且插入到总部的ESB之中，或者涉及到在每一个远端的多个应用之间的一个“迷你”的集成环境。那么二个 ESB节点就可以通过一个基于可靠消息的安全连接进行通信(图 2-8)

图表 2‑8  在各个地点分立安装的ESB可以安全和可靠地连接在一起

此外，远端位置仍然可以在他们自己的分离集成环境里面运行，并且可以按照需要有选择地共享数据。例如，远端位置可以独立地拥有并且运作一个属于集体特许经营的零售店铺。它们没有必须共享关于它们的日常运作的信息，但是的确需要共享诸如价格更新和库存信息之类的数据。远程ESB 节点可以连接到位于总部的 ESB 网络，有选择地暴露消息通道以共享价格变动之类的数据。

2.4.3 保留和分层: 进入现有的 EAI Broker连接

我们的ESB 采用示例项目的第三阶段涉及到桥接进进一个已经部分地与一个集线器-和-插头 EAI Broker集成在一起的部门。我们先前提醒过，采用 ESB 不是一个全有或全无的概念。如图 2-9 所示， ESB 允许IT部门通过将一个已存在的 EAI Broker桥接到ESB之内来保护它里面的IT资产。

图表 2‑9 “保留-和-分层”方式允许将ESB桥接到EAI Broker安装之内

桥接 EAI Broker可以一多种方式进行。比如，它可以通过使用一个Web Services接口来完成，或者绑定到下层的消息通道。依赖于ESB和 EAI Broker 的实现，ESB 更加可以建立在EAI Broker下面的消息队列基础设施之上，因此部分地替换EAI Broker的功能仍然可以保留较低层的、消息通道。

2.4.4 集成伙伴

我们的 ESB 采用示例项目的最后步骤是解决和业务伙伴集成的问题。如图 2-10 所示，这可能包括原样保留SOAP联结，以及在每个伙伴端安装一个 ESB 节点。决定采用哪一种方法完全依赖于你的组织和伙伴之间的关系，以及业务伙伴是否允许你在其地点安装软件，或者他们已经有能够连接到你的ESB之上的ESB。

图表 2‑10 ESB 可以个别地管理与业务伙伴的SOAP联结, 或者可以连接到另一个地点的ESB节点

插入到一个 ESB 扩展的分层的服务能够管理对伙伴的连接的后勤保障。例如，一个特殊的伙伴经理者服务可以在每一个伙伴的基础上管理与伙伴之间的正在进行的协作的细节。这些细节可能包括正在使用哪一个更高层次的业务协议(比如， ebXML、RosettaNet 等)、以及对话的状态，比如消息交换的当前状态、是否收到一个期望的应答消息、以及从业务伙伴接收到一个业务响应所能够接受多长的时延。

2.5小结

本章包含下列主题：

•  对更广泛的、更通用的集成基础设施的需要的各种驱动因素
•  偶然架构是今天所使用的主要集成设计。 在这种系统中，当前的企业完全没有很好地联通的。
•  只有 10% 的应用被联接。
•  而这些之中，只有 15%的使用了某种类型中间件。
•  到目前为止，分布式计算技术加重了，而不是解决了，偶然架构的问题。
•  集线器-和- 插头EAI Broker已经有了一定程度的成功。然而，它们:
•  大部分是专有技术
•  没有为组织提供一个标准化的、可以在企业内通用使用的集成平台。
•  ESB 借鉴了在 EAI Broker技术方面学习的经验的价值。
•  集成作为是一个部门层面和公司文化的问题，和它作为一个技术上问题同样重要。
•  ESB 允许逐渐增加的采用，以符合各个部门单独的开发时间表。

2.3借鉴来自 EAI 和 SOA 的最佳实践

在我们继续前进并且牺牲我们的先前努力，丢掉前面的每个技术，并且向失败举起我们的双手之前，还有一条路能够让我们能够利用从学来的宝贵经验，并且仍然远离偶然架构—那就是采用ESB。 集成的最佳实践，已经经过对集成Broker的经验被精炼，如今还可以结合建立于XML、Web Services、可靠的异步消息、以及分布式的ESB集成组件之上的基于标准的架构来一起使用。 他们一起形成一个高度分布的、松散耦合的集成架构，以提供集成Broker的所有主要功能，却没有其所有的障壁。

远离偶然架构并且使用 ESB重构到的一个统一的和一致的集成骨干，涉及到下面小结描述的步骤。

2.3.1 采用XML

虽然ESB 确实能够传送许多类型的数据格式，但是采用XML作为应用间交换数据的手段 (图 2-2)，如同已经被用在一些传统的 EAI 方式中一样，可以由很多好处。我们将会在第 4 章中看到，使用XML可以一劳永逸地隔绝全局的数据格式和接口的变更和偶然架构本身。ESB可以进一步通过检查XML消息的内容，并且控制其向何处提交，有时候还可以改变提交路径来包括可能会修改和增加数据的附加服务，一次来促进业务处理。

图表 2‑2 ESB 使用XML来作为应用间共享数据的方式

2.3.2 采用Web ervices并实现 SOA

以 SOA 的方式来思考和规划在向 ESB重构的一个基本步骤。如图 2-3 所示，服务级接口的引入在提供了一个公共抽象层来创建接口和实现之间的分离。这样就通过使用一种通用的接口定义机制，比如Web Services描述语言(WSDL)，来减轻了由细粒度服务接口组成的复合业务流程定义的构造的难度。

图表 2‑3 Web 服务和 SOA 提供了一个隔离接口和实现的通用抽象层

虽然服务级接口的抽象是正确方向上的一步，结果仍然是一个路由逻辑密合于应用之内的硬连接 ( 注意在图 2-3 中，“流程逻辑”仍然黏附于应用)。Web Services中的传统智慧已经模仿了客户/服务器模式。甚至在一个Web Services分布式网络中，一个应用总是另一个 “客户”。范例用法仍然需要抽象层也包括胶水代码，比如说“调用服务X上的方法a，然后调用服务Y上的方法 b()….”诸如此类。。

Web Services实现中所确实的东西是将流程路由逻辑从接口定义和应用逻辑中分离出来观念。如图 2-4所示，ESB 就提供了那种隔离，并且仍然完全利用SOA。

图表 2‑4 ESB 将业务流程的路由逻辑从接口定义和应用实现中分离出来

通过分离接口定义和流程路由逻辑，我们已经开始看到ESB 形式的总线层(图 2-5)。通过将流程业务路由逻辑和接口定义放入总线层之内，应用能够继续自己集中于实现逻辑。 我们在第 1 章中看到过，ESB 被实际上区分为多个功能层。它为应用间的可靠的、异步的、基于消息的通信提供了一种坚固的底板。也是在这里，流程路由通过基于检查消息中的XML内容来附加的条件决策点，从而变得具具智能。这个智能路由是被可管理地定义的、可以被修改、并且可以加上增值服务，比如补充数据变换功能。ESB 提供了一个可扩展的集成服务网络，并且可以无限伸展，同时仍然可以以逐渐增加的方式进行构建

图表 2‑5 ESB 可靠地连接和协调SOA 的服务之间的交互

这一节将详细讨论，今天各个企业应用怎样进行集成、或者怎样没有集成。还包括对今天很多组织中很流行的集成方式：偶然架构的讨论。

2.2.1 企业大都连接不善

在过去二十年以来，无数分布式计算模型一一登场：包括 DCE、CORBA、DCOM、MOM、 EAI Broker、J2EE、Web Services、.NET。 然而，迹象表明，不管采用何种技术，只有很少数企业的应用时很好连通的。按照来自 Gartner 公司的一个研究报告[1]，这个数字少于10%。

关于应用的连通性，其他的统计数结果更令人吃惊，— 只有 15% 的应用的集成采用了正式的集成中间件。其余则使用 ETL 和批量文件传输技术，其主要以手工编写的脚本和其他定制方案为基础。关于 ETL 和批量文件传输的更多信息，以及他们相关的问题，我们在第9章讨论。

2.2.2 偶然架构

Gartner 15% 统计值提供一个关于当今的集成状态的一个令人深思的数据。那么其他85% 的应用是如何连接的呢? 一种在今天的企业中普遍存在的情形，我将其称为是“偶然架构”。所谓偶然架构就是没有人公开宣布创造的；相反，是多年积累的一种“就事论事”的解决方案。在一个偶然架构中，公司的应用被永远锁定在一个不灵活的刚性基础架构之上。然后他们又被视为是信息“地牢”，因为集成基础设施不能适应新的业务需求。 (图 2-1)

大多数集成尝试都从某个深思熟虑的设计开始，但是经过一段时间后，其他的部分好像都各就各位地“集成”了，但是手工编写的代码却早已飘移出原来的内容之外。经过逐渐进行的螺栓和补丁，所谓整合的系统已经失去了其原来的设计完整性，尤其是如果系统是被很多的人来维护的，而他们对最初的设计意图可能没有很好地沟通。事实上，这种“就事论事”的方法将完全失去集成的一致性，因为工程师总将是“只是做一点点修改”作为解决问题的权益之计。最后甚至对找出那些地方做了修改都变得非常困难，更不要说要理解这些结果导致了那些方面的副作用影响。在一个部署系统中，这可能会对你的业务造成损失惨重的悲惨结果。

对集成遵守标准能够为你创建一个针对所期望功能的基线来遵从。如果基础设施是专有的， 不基于标准的，那么随时间变化保持计划的设计和指导原则就变成棘手问题。虽然也可以构造专有的平台并且变通规则，但是这通常又导致更加“多样性”的后果，结果更加锁定于其上。然而，你应该记住的是简单地遵守标准并不必然地阻止你构建一个偶然架构。

图表 2‑1 偶然架构将永远使公司的应用成为“信息发射井”

在偶然架构背后的技术是各不相同的。图 2-1中的实线、虚线和点划线表示了连接应用的不同技术。这些技术可能包括 FTP 文件传输、直接的socket连接 、专有的MOM、以及有时是 CORBA 或其他类型的远程过程调用(RPC) 机制。某些定向的点对点解决方案可能已经使用了XML信封定义，或者基于SOAP或者其他什么机制的技术，来为集成的应用之间承载数据。

图中间的集成Broker表示了在部门级的层次连接应用的一个岛屿。然而这并不意味着它能够连接任何事物。集成Broker通常只是结交给基础设施中的某一块，因此资金丰富的项目可能会取得适度的成功，但是它们再也不能与其它所承诺的部分进行很好的集成。

偶见架构表现为得到一个刚性的，不能对集成提供一致的、持久的基础设施。它不能如其应该达到的效果那样很好地解决你的组织性的问题。要改变偶然架构一直以来就是个挑战，因为点对点的解决方案的数量不断在增长。这通常也意谓着应用之间的互相依赖性是紧密耦合的。使应用中的数据的表现的修改意谓着你还必须修改共享该数据的其他所有应用。这就限制你快速地改变你的业务流程，以适应变化了的或者新的业务机会。这些紧密耦合的、硬连接的接口不仅仅是偶然架构的问题。因为控制流、业务应用之间的通信的编排被硬编码进应用本身之中，这进一步导致了复杂化。这些都增加了系统之间的紧密耦合和脆弱性，使变更业务流程更加困难，并且导致了厂商所定。

2.2.2.1 部门和组织问题

偶然架构的先天技术不足队组织中的人力协调问题具有推波助澜的作用。不管问题是紧密耦合的接口还是硬编码的流程编排，要想回头或者对其进行较大的翻新改造简直是一件恐怖的事情。这经常需要安排大量的会议，和属于不同项目的不同的开发组的人们开会，就紧紧对要做什么以及何时做这类的问题达成一致。如果应用，以及他们分属的开发项目组，分别处于不同的地理位置和时间区，应用改变所需的协调问题则会变得更加困难。

有时某些应用程序被视为“遗留”系统，对他们你是不愿意或不能够对其进行多少修改，因为它们已经进入维护模式。我们通常说，“遗留系统”的一个定义就是那些你昨天刚安装的系统。即使你对自己开发的应用具有完全的访问和源代码的控制权，当开发人员继续进行其他项目或离开公司的时候，对其进行修改也是非常困难的。我们将会在第 4 章中看到， ESB 大大地减少了随时间变化，修改数据模式和格式所带来的影响。

2.2.2.2 逃离偶然架构

即使你已经对跟踪和修改应用数据及其接口建立了良好的公司实践，偶然架构仍然还有其他缺点。使用不同的连接技术意谓着安全模型可能是混杂的，所以没有确定的方式来建立和执行公司级的安全策略。 对插入新的应用没有一致的 API可以依赖，而且没有基础来在棋上构建公司关于集成的最佳实践。最近与一些领导的专家进行了交流，总结了偶然架构的下列各项问题:

• 不可靠性

应用之间的通信或许能得益于异步的消息的可靠性。如果一个大型业务流程中的某两个应用之间的通信连接失败，整个业务流程可能会事务性地返回或者重启。我们将会在第5章学到更多有关松散耦合的、异步的可靠消息的更多内容。

• 性能和可伸缩性分析

不管你是否你已经有了一个预先的性能规划并且试图分析一个现有的性能问题，由于偶然架构的许许多多的子系统和他们各自的运行特征，这个工作是极其困难的。通常的做法是采用混杂的、“投入资源到其中，直到它能正确运行”式的解决方法，这将造成磁盘、处理器、内存等上面的过度开支。

• 总体排错

没有哪个单一方法能够提供充分的诊断和报告能力。 意外架构需要很多具有很高能力的维护人员围着所有有缺陷得生产系统转，这将导致整体拥有成本 (TCO)的急剧上升。各部分实现的方式差异越大，在其失效时需要用来解决它们的问题的专家经验就越宽。另外，建立一个基线来描述期望的正确行为也是一个挑战。

• 冗余和弹性

没有任何方式能够保证这个泥潭中的所有组建都能够满足你的关于可接受的冗余、弹性和容错度的定义。这意谓着要为依赖于后段系统的新功能定义可达到的服务级别协议 (SLAs) 是很困难的。

• 帐单漏洞

如果你的系统携带又能够收费的帐单数据 ( 比如电信)，那么账单数据的利息就可以被丢失在偶然架构之中。因此，你可能会损失收入并且还一点都不知道。

• 监控和管理

没有一致的方法来监控和管理一个偶然架构。假定你的整合应用系统必须运行 24/7 ，而且你的职员负责关注运行监控工具，并且做出纠正。这些工具将不会以相同的方式工作，那么在无数不同的小方案的基础上进行培训 ( 和再培训) 将是非常昂贵的事情。简单地安装企业级的运行管理工具并不能自动地将自省能力提供给集成基础设施，并且偶然架构通常并不能提供所有可能需要的控制点。

总而言之，偶然架构表现为一种刚性的、高成本的基础设施，并且不能满足你的组织变更的需要，还要承受以下缺点的痛苦：

•  紧密耦合的、易碎的、对变更不灵活的
•  因为多个点对点解决方案导致的昂贵的维护负担
•  修改一个应用程序可能影响其他很多应用
•  路由逻辑是硬编码到应用程序之中的
•  没有通用的安全模型；安全是混杂的
•  没有通用的 API(通常)
•  没有通用的通信协议
•  没有建立和构建最佳实践的通用基础
•  难以支持异步处理
•  不可靠
•  没有对应用和集成组件的健康监控和部署管理

如你所知，偶然架构的创建已经有些年头了，要替换和解决它并不是一蹴而就的事情。随着继承项目的需求的增加，解决方案应该更加柔性的、简单、以及运行便宜，而不是其他什么东西。偶然架构给了你的那些敏捷的竞争者得到好处，而你却不能够在一个合理的时间范围内实现新的业务机会。

你需要一个内聚的架构，面向实践、标准来解决着大量的问题。ESB 提供了架构和基础设施，并且使你能够逐个项目的基础上采用它。采用 ESB 并不是全有或全无，推倒重来式的方式。而是，你可以渐进式地采用它，同时还能利用你的现有资产-包括偶然架构和集成Broker，以一种“留下而分层”的方式。

2.2.3 ETL，批量传输，和 FTP

提取、转换、和载入 (ETL) 技术，比如 FTP 文件传输和每夜批处理式的集成在今天仍然是最流行的方法。

这通常涉及到将位于各个应用中的数据打包然后上传这样的操作。问题是有很大的可能在应用间的数据失去同步。一个失败的打包上传的处理程序可能要花上一天的时间。在京及和业务全球化的情况下，系统以24/7 的方式运行，再也没有了“夜晚”的概念，那你得批处理又该在何时执行呢？

其他问题也可能与每夜的批处理相关。因为批处理的反应期问题，在分析关键业务数据的时候，最好的情形是24 小时轮转时间。这一延迟可能严重地阻碍你对随时变化的业务事件进行反应的能力。

有时，一次跨越多个面向批处理系统的端对端处理处理甚至会花费一整个星期才能完成。处理从源头到目标的数据的总体潜伏反应期完全阻止了收集具有意义的，反应目前业务情形的数据的洞察力。比如，在供应链的场景中，这将导致你永远不知道你的库存的真实状态。

第 9 章将会呈现一个通过FTP进行成批传输的技术和业务意义的案例研究，并且会研究ESB如何能帮助你逃脱偶然架构的困境。

2.2.4 集成Broker

集线器-和-插头的集成Broker，或者EAI Broker，提供了偶然架构的替代。集成Broker是从上世纪90年代出现在，现在已经被植入到MOM主干或应用服务器平台之中。

集成Broker市场的一些公司包括:

• SeeBeyond
• IBM
• webMethods
• TIBCO
• Ascential (Mercator)
• BEA (more recently)
• Vitria

集成Broker能够使用一个集线器-和-插头架构帮助偶然架构提供应用之间的集中路由。此外，他们还允许使用业务程序管理 (BPM) 软件将业务流程从下层的集成代码中分离出来。到此为止，所有的都是好消息。

然而，对集成Broker方式也有缺点。一个集线器-和- 插头拓扑不允许对局部集成域之上进行局部控制。构建在一个集线器-和-插头拓扑之上的BPM 不能够建立跨越部门和业务单位的业务流程极其编排。 集成Broker也可能受限于下面的MOM不能越过物理的LAN网段和防火墙的能力限制。

有许多公司已经在其集成策略中采用了集线器-和-插头的集成Broker解决方案。 这些技术具有较高的成本，并且成功也值得怀疑。1990 年代后期的昂贵集成Broker项目已经取得了名义上的成功，但是将组织置于专有的集成域的井中。一项Forrester在2001 年十二月发布的研究报告[2] 展示了下列各项统计:

•  集成项目平均 20+ 个月才完成
•  少于 35% 的项目能够准时和在预算内完成
•  35% 的软件维护预算被花费在维护点对点应用连接之上
•  在 2003 年， 全球 3500 家企业平均期望花费六百四十万美元到集成项目上

这项研究还是在EAI 在它的最尖峰的时候进行的，而且几乎没有迹象表明这一数字在那时候起之后得到了改善。注意一年六百四十万美元是公司会在集成项目上花费的平均数的一个预测。当于这些公司的领导们交流这些问题的时候，我进行了一个一般性的求证。

照今天的预算标准来看，EAI Broker项目是很昂贵的。集成软件费用很贵的，通常单独对于软件许可费用，每个项目的价格范围就在从 $250,000 到一百万美元不等。这还不算一起的咨询服务组件，而这个组件的价格往往是软件许可费用的5到12倍。

集成Broker高昂的启动成本又被另一事实所进一步恶化，即从一个项目中学到的知识不能很好地转移到下一个项目。由于传统的 EAI Broker技术的专有特性，通常具有很陡峭的学习曲线，对于每个项目来说，有时候实6个月。要试图弥补这个负担的通常方式是聘请事前对专有技术经过培训的特别的顾问。当然，高特殊性=高价格。这是高昂咨询费用的一个重要组成部分( 另一个大的组成是技术安装、配置、部署、和管理的复杂性)。并且一旦项目完成，顾问就不见了。

集成项目的实现时间普遍是在 6-18 月之间。这意谓着。根据事前针对短期设定的标准、以及项目资金，实施时间吃掉了项目原本想要利用的策略性窗囗。

集成Broker的专有性质，以及高昂的咨询费用通常导致供应商锁定和重启后续项目的巨大成本。这意谓即便对于成功的项目，增长和伸展也是令人恐惧的。而且在你对你的供应商或者实现心生不满的时候，你也得面对到底是就目前的情况继续走下去，还是选择完全重新开始，雇用更多的咨询顾问或者投入另一个新的学习曲线之间左右为难。因为所有这些，一些IT组织通常留下了一些难以再集成到其他项目的“集成孤岛”。总而言之，集成Broker已经证明是偶然架构里面的老套技术，而并非它的解决方案。

当我们更详细地讨论集成Broker的时候，我们将看到导致这里所列的问题的技术屏障。另外，许许多多的非技术因素也导致了对采用ESB的需求的增长。

[1] [2]来自 Gartner 公司的统计,"集成Broker，应用服务器和 APSs,"10/2002.

[2] [3]来自 Forrester 研究的统计学,"减少集成费用,"12/2001.

各种因素，包括技术和业务层面的，导致对新的集成方式的需要。有许多新的业务驱动因素，比如经济条件的改变、新的革命性的硬件技术比如射频识别标签 (RFID)的出现、法规管制的遵从，都预示着从业务视图来看，应用集成和数据共享都要发生重大变革。这些驱动好像与企业中目前的集成状态不一致子，并不象你所想的那样超前。当我们在这一章中详细研究的时候，大多数应该只是简单集成的项目不能很好集成，主要是由于缺乏能够广泛采用的一致的继承策略所致。

下面是影像着对更大规模的集成解决方案的需要的各种需要：

• 经济的驱动器。

这些已经改变了IT花费的形式。经济因素导致IT部门主要集中于使事情能够与他们当前已经有的应用一起工作。

• 最高优先序: 集成。

调查结果表明集成继续处于CIO的优先序列的最顶层。

• 法规的遵从

Sarbanes-Oxley法案、PATRIOT法案、以及 FCC 法规都强迫公司建立一个必须的内部基础设施来比以前一样更加详细地跟踪、路由、监控、和获取业务数据。

• 直通处理 (STP)

STP 的目标是消除业务流程的无效率，比如数据的人工再输入、传真、纸面邮件、或者不必要的数据批量处理。在行业中，比如金融服务，这可以帮助达到几乎零反应期的交易处理。

• 射频识别标签(RFID)

被视为下一代条形码的革新， RFID 可能会产生大量的新型数据，然后这些数据需要被路由、变换、聚集，和处理。

不幸的是，公司的集成环境的目前状态在这些领域几乎没有取得什么进展。这又使得业界领袖不得不重新寻找更广泛的集成解决方案。而有关集成的目前状态的问题包括:

• 良好连接企业的普遍缺乏。

这阻碍了企业向自动化业务流程进步，然后由阻碍了其对不断变化的业务需求的快速反应。

• 偶然架构

偶然架构是一种一直使用的事实上的集成方式，其结果是没有连贯一致的公司级的集成策略。这表现为老是要留下点对点的集成、每一个都有其自己的连接和集成风格。偶然架构表现为不连贯的脆弱和刚性架构、并且不能经受集成环境的新的附加条件和变化。

• ETL，批量传输和FTP。

使用FTP文件传输和每夜批处理的方式进行提取、变换和载入 (ETL) 的技术仍然是今天“集成”最流行的方法。 这些处理涉及到每夜对各种应用之上的数据进行打包上载的操作。由于这种做法的潜伏反应期和错误率，组织从来不会不真正拥有对它们的关键数据的好的快照。

• 过去使用集成Broker的危险。

上世纪90 年代后期，昂贵的集成Broker项目看似成功，但是给组织留下了大量专有的集成领域难以消化。

这章将会详细讨论这些因素。除此之外，它将会解释通过逐渐采用重构到ESB的好处，同时使用学习自集成Broker技术的最佳实践。

2.1业务驱动激发集成

2.1.1 IT开支的趋势

经济因素导致IT部门主要集中于使事情能够与他们当前已经有的应用一起工作。在Y2K之前，大多数公司都把它们的主要花费集中在准备应付 Y2K之上，包括购买打包的没有Y2K问题的应用。

后来的经济低迷时期，不管是否归结于后Y2K时代、Internet泡沫破灭时代、9/11、或者战争的不确定性，都已经导致了IT花费的急剧变化。这已经有对集成造成了特殊的冲击，不管是正面的还是负面的。IT预算和前 Y2K时代相比已经今非昔比。再也不会出现IT经理手中握着对集成Broker软件和服务的数百万美元预算，并且还要花费18-24个月的时间来等待项目结果这样的事情了。IT花费现在变得都要通过执行层，每一个项目都要经过仔细审查。只有对业务生存能力至关重要的项目才能得到资金。公司在每一个项目的基础上要求在3-6个月的时间片内得到切实的效果和投资回报，虽然他们仍然维持着改良整体运行效率的策略目标。

2.1.2  作为高优先级的集成

新的节俭时代并没有减少对业务流程的改进和对集成的需要。 业务层面的驱动仍然存在；减少业务周转时间需要，减少存货水平的需要，消除重复IT服务的需要，如此等等。

IDC的一分报告指出[1] 他们调查了557个CIO关于他们2004年事情的优先级。关于集成报告中这样说:

在2003年6月举行的IT和执行层交流会上，关于什么可以被称为“市场推动”趋势的问题，集成已经成为2004年IT规划中比安全具有更高优先级的事情。

报告同时指出，集成和安全分别占第三和第四位，在最高的CIO优先级的列表中，仅仅排在“基础设施替换/升级”和“IT费用削减”之后。

总体百分比则受到了有 21% 的“中间市场”公司将集成的重要性排在前面的影响，甚至超过了“减低成本”和“基础设施替换/ 升级”。表 2-1 战士了这个问题的答案:“ 下列各项问题，你认为在 2004 年终期待有最高的优先级吗? 选择一个。”

[1] IDC，应用开发中的集成标准趋势: 着全赖于“开放”的真正含义，2003 年11月 (文件 #30365) ， http:// www.idc.com 。

2.1.3 法规遵从

有时候，对集成的需要在强加于你的，不管你是否喜欢它。 甚至在困难时期，当预算紧张时，为了集成目的而对基础设施进行修补也一定要遵从政府的法规管制。 如大部分它人们会证明,不有而有很多的仅仅继续尝试维持状态.为新的集成策略担忧。 然而,没有像有者监牢时间和强烈的罚款视野得到资深的管理注意。

由于范规管制的问题，一些行业的公司必须向竞争者提供信息，并且对信息访问进行审计。比如，在电信业中，负有职责的电信营运商(ILECs) 应该提供信息给竞争的 LECs 。能源公用事业也应该提供账单信息给竞争者。保健机构和隐私法律需要跟踪客户记录访问以供审计之目的。这需要你的分离的数据能够以标准的协议和以标准的格式轻易被访问。

下面是一些领域，在其中法规遵从是个驱动力。

2.1.3.1 电讯

一个 FCC 法规要求所有的电讯提供商和地方性的向地方性的营运商暴露他们的客户数据的某些部分。 一主修电讯供给者正在有强烈的罚款欺骗它为不遵从这一个需求。很明显，甚至一家主要公司也不能够负担得起继续基础上支付那么多的钱。与法律要求的共享信息相关的许多问题和高额成本，并且过滤掉那些法律不要求的部分。因此，一个过分单纯的方法不能同时满足法律要求又能保护敏感的公司数据。你需要又细粒度的过滤器和有选择的数据变换来只提供必需的数据 (也许只有在最后的一分钟) 来最小化你的竞争者可能访问所导致的对你的数据的利用。所有这些都需要有对业务流程的细粒度的访问和控制。

电信提供商需要一个基于标准的、能够伸展到小的电信提供商的集成解决方案，使用较小的电信商也能够采用来作为集成策略的各种协议。为了满足这个需要，公司最终采用 ESB 。

1.1.1.2 Sarbanes-Oxley

2002年颁布的Sarbanes- Oxley 法案旨在通过改善公司信息披露的准确性和可靠性来保护投资者，它强制了新的报告需求，并且对公司的决策者和他们的企业引入了更高的问责性。 遵从Sarbanes- Oxley 法案需要面临一些真正的挑战。包括费用考虑，后勤复杂性，数据收集和管理问题，以及正确的数据的及时报告，不管数据存在于哪一个企业之中。

2.1.3.3 政府

美国联邦政府已经设定一个目标 在2003 之前变成无纸化。在2003年一月的美国政府CIO高峰会上，Brand Niemann，CIO理事会XML Web Services工作组的主席，对美国政府的集成中采用XML的驱动力是这样说的:

1998年的政府文书工作消除法案，要求联邦政府机构在2003年10月前，如果可行，允许与政府打交道的个人或者实体能够有选择地向政府机构电子化地提交信息和进行交易处理，或者如果可行，允许维持电子记录。

法规遵守产生了巨大驱动能量，并且集中于跨越整个政府机构集成后端应用和数据源。当我们在第 11 章讨论门户环境中的ESB 的时候，ESB能够在门户服务器和多个后端应用之间扮演媒介中介而提供重要的价值。

2.1.3.4 直通处理 (STP)

直通处理 (STP)意味着对于跨越整个系统和组织的业务流程的事务性数据只需要输入一次。在其他行业中， STP 可能被称为“流通供给”、“无纸采集”、“lights-out”或者“hands-free”处理。

达成 STP 的目标要消除业务流程的无效率，比如数据的手工重新输入、传真、纸面邮件、或数据的不必要的批处理。今天阻碍 STP 的事物的例子包括将采购订单重新输入到信用卡验证系统，或者周期性处理的数据分批。

在金融服务、电信和公用事业中，STP 是一个主要驱动。在金融服务中，“T+1”的目标是将交易数据沉淀一天。自动化程序运行可以帮助公司在整个订单和贸易的生命周期中减少成本，更快捷地服务客户，以及更有效地管理业务风险。

2.1.3.5 射频识别标签 (RFID)

射频识别标签(RFID) 正在改变企业跟踪其整个供应链中各处的货物和供应的方式。RFID标签还承诺能够通过消除人们打开外包板条箱和托盘扫描条形码内容的需要从而自动化供应链。装备有RFID标签的货物通过安装在仓库或者装货码头的阅读器时，会差生大量的消息，而这些数据又将会产生大量的需要被捕捉、路由、变换和输入到其他队业务有意义的应用之中的数据。

零售卖场中装备有RFID阅读器的“智能货架”能够自动跟踪货架上的货物数量，并且在货架存量低于标准的时候自动产生补货的订货命令。这些货架阅读器也会知道，消费者从货架上拿起一件商品平，然后可能又因为另一种商品而将它放回货架。这种类型的数据对于那件重新放回货架的商品的制造商来说也是很有价值的。

领导零售商，比如Wal- Mart和 Tesco、和美国防卫部，已经对齐大型供应商强制要求在大外包装级别装备RFID标签了。其最终目标是要驱动标签本身的价格下降，使得最终对每一但见商品，比如一把牙刷或者一罐苏打，进行RFID标签识别变得可行。这样将大大增加在一个托盘经过阅读器是所产生的消息数量。这种数据量在人工扫描外包装上的条码的时候是不会产生的。当一个托盘经过阅读器的时候，ESB能够作为因为而缠身的爆发性数据的缓冲以便能够准确捕获这些数据。那些没有针对这种数据量进行设计的应用可以得到ESB 的消息层的保护，它能够将工作量分配到多个后端系统，或者进入消息队列排队，直到其能够被处理。

因为个体物品级RFID标签而导致的消息的粒度更细，对那些没有针对处理超过大包装级别粒度的数据的应用也是个问题。ESB 能提供殊的缓存、聚集和变换服务，以便能够将收集更细粒度的数据，并将其聚集为大包装级别的数据，以便那些应用能够读取。

EPCglobal 组织正在促使 RFID 标签、阅读器、以及将阅读器整合到应用的软件的标准化。为了要广泛地共享 RFID 数据，需要对整个供应链中的相关应用和阅读器网络定义集成规则。而为了避免网络中的RFID 数据洪水，过滤和聚集规则应该尽可能地分布到最靠近RFID 事件的产生点。ESB 是一个很好的管理和配置那些控制数据流得规则的理想远程集成平台。

许多新生技术都经受过试图找到问题来解决以获得采用的痛苦经历。另一方面，ESB的概念是由业界领袖的架构师和技术社区中的领导厂商一起和定义和构建的，因此，ESB从诞生之时便得到采用。ESB正在或已经被用在多种行业，包括金融服务、保险、制造业、零售、电信、能源、食品分销和政府。下面是一些例子。

1.7.1 金融服务

• 一个领先的Subprime借贷公司实现了 ESB，减少了60% 的业务处理费用。这是通过在eCredit 系统、第三方信用机构、以及他们自己的后端系统之上建立一个统一的客户数据视图来达到的。
• 领先的银行已经使用ESB实现了金融交易的直通处理，很客官地节省了手工处理成本。
• 一个派生的贸易系统依靠ESB每天为1,200用户处理超过100,000 笔交易，记录超过数十亿美元的帐务。

1.7.2 保险

• 世界最大的寿命和健康再保险公司，年收入二百亿美元，将ESB作为理清在总部和销售及管理其政策的保险代理商之间的后端交易数据的交换的解决方案，产生了可观的费用节省。

1.8.3 制造业

• 一个橱柜台面和地板制造商通过使用ESB实现了一个一体化管理的存货系统和“可用性承诺”查询系统，提高了供应链的预见能力，减少了最低库存报警的条件。在部署的第一阶段， ESB被用来连接该制造商和其60个分销商之间的供应链网络。

ESB 的部署模型允许制造商在分销商的地点部署ESB 服务容器。这是在每个远程地点部署一个集成Broker方案的另一选择。

• 一个主要的照明、电视和医学成像的制造商正在使用 ESB 创建一个统一的集成主干来连接其遍布全球的业务单位，并且为全球的客户创建一个统一的产品和订单视图。

1.7.4 零售

•  使用一个基于标准的，集中的管理框架，一个全家的影像零售连锁店正在采用ESB 基础设施来通过一个中央管理和配置控制台动态地配置和管理 1,800个远程店铺，
•  世界最大的邮购公司 (收入一百二十亿美元)依靠 ESB 来从其许许多多的供应商订购产品。

1.7.5 电讯

• 一个电话营运商的Web门户网站依靠ESB来对用户点击进行分析跟踪 (二小时的响应对 30 天的响应时间)， 并且每天处理一千六百万个消息。
• 美国第二大的电信营运商，收入四百三十亿美元，使用 ESB来从内部的系统向竞争者提供信息。

1.7.6 能源和公用事业

• 一家一百亿美元的电力公司可靠地实现了 ESB，用来连接内部系统和政府强制的应用。 对帐务、系统管理、运行报告、以及法规强制的与竞争者的信息共享，提供了实时数据。

1.7.7 食品分销

• 一个主要的欧洲食品分销网 ( 一个十二亿美元的分公司)在八个星期内实现了 ESB，并且节省了使用一个集中的集线器-插头 Broker的集成方式所需的三百万美元。ESB 通过管理供应链中的买、卖和物流协调，从肉类产品的配送到饲养家畜的饲料的生产，从而自动化了整个分销网络。
• 在这个食物分销网络中， ESB 集成了跨越三个不同的运行公司和许多第三方伙伴的应用，导致运行效率增加、可观的费用节省、以及更容易的集成新系统的方法。

1.7.8 政府

n 一个美国政府机构正在使用ESB 来整合多个政府系统，以满足USA PATRIOT法案。USA PATRIOT法案允许政府跟踪金融交易，以防止恐怖份子得到资金。该项目包括使用 ESB 来集成门户服务器和各种政府机构中的后端系统，以提供一个统一的数据视图。

1.8小结

概括起来， ESB 具有下列各项特性:

• 普遍性

ESB 可以采用来适应各种集成情形下的各种通用目的集成项目的需要。它能够构建跨越整个企业和其业务伙伴的集成项目。

• 高度分布的、事件驱动的 SOA。

松散耦合的集成组件可以在总线上以广泛分布的地理拓扑进行部署，并且在总线中可以随处作为共享服务进行访问。

• 选择性的集成组件部署

适配器、分布式的数据变换服务、基于内容的路由服务都可以在需要时有选择地部署，并且可以独立地伸缩。

• 和可靠性

通过总线进行通信的所有组件能得益于可靠消息、事务完整性、以及安全的认证通信机制。

• 编排和处理流

ESB 允许数据流过插入到总线中的任何应用， 不管是本地还是远程。

• 自治而联邦管理的环境。

ESB 支持部门和业务单元级别的本地自治，并且仍然能够在较大的受管的集成环境中整合。

• 逐渐采用。ESB 可用于小项目。

每个个别的项目能进入一个更大的集成网络，它们可以从总线上的任何地方进行远程管理。

• XML支持

ESB 可以充分利用XML作为“原生”数据类型的好处。

• 即时洞察力

ESB 提供了对及时业务数据的实时洞察能力。BAM能力已经被构建到ESB 框架之内。

你现在应该有了关于 ESB的足够的信息来满足你的好奇欲了。 接下来，在更详细的章节中，你将会学到更多有关其底层技术方面的内容。下几章将会讨论 ESB 的进化、目前的集成状态，采用XML来作为一个通用的数据交换架构以在不同的数据表示之间协调的好处，以及异步消息和MOM。

由于试图快速进入成长中的 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 章中详细研究。

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服务之类的技术的通常目标主要是创建一个集成架构，且能够深入并且跨越整个扩展企业。对于一个集成基础设施到达到这种普遍性，它必须具有下列各项特性:

• 它必须能够适应多种集成情形项目的通常目的需要，不管是大型的还是小型的。适应性包括提供一个能够经受协议、接口技术、甚至流程模型的变化趋势的持久架构。
• 它必须以一种单一和统一的方式，以及一个通用的基础设施来连接扩越扩展企业的各种应用。
• 它必须能够扩展超出单一公司IT中心的边界。并且自动化伙伴关系，比如在B2B 和供应链的情况下。
• 它必须具有设计的简单性和较低的进入门坎，使得日常的IT专业人员也能够成为自我修练的集成架构师。
• 它必须提供一个跨越普遍集成的 SOA，它能使集成架构师能够对公司的应用资产和自动化业务流程有一个广泛的、抽象的视图。
• 它需要有能够反应和符合不断变更的业务需求和竞争的压力需要的灵活性和能力。

在 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包含到微软平台和开发环境之内将更加能够使得应用具有松散耦合和消息感知能力。

Web + Services

A lot has been written recently about Service-Orientation and Web services and REST and the massive amounts of confusion that seem to be surrounding the whole subject. After much navel-contemplation, I'm convinced that the root of the problem is that there's two entirely orthogonal concepts that are being tangled up together, and that we need to tease them apart if we're to make any sense whatsoever out of the whole mess. (And it's necessary, I think, to make sense out of it, or else we're going to find ourselves making a LOT of bad decisions that will come to haunt us over the next five to ten years.)

The gist of the idea is simple: that in the term "Web services", there are two basic concepts we keep mixing up and confusing. "Web", meaning interoperability across languages, tools and platforms, and "services", meaning a design philosophy seeking to correct for the flaws we've discovered with distributed objects and components. These two ideas, while definitely complementary, stand alone, and a quick examination of each reveals this.

Interoperability, as an idea, only requires that programs be written with an eye towards doing things that don't exclude any one platform, tool or technology from playing on the playground with the other kids. For example, interoperability is easy if we use text-based protocols, since everybody knows how to read and write text; hence, HTTP and SMTP and POP3 are highly-interoperable protocols, but DCOM's MEOW or Java's JRMP protocols aren't, since each relies on sending binary little-endian or big-endian-encoded data. Interoperability isn't necessarily a hard thing to achieve, but it requires an attention to low-level detail that most developers want to avoid. (This desire to avoid low-level details isn't a criticism--it's our ability to avoid that kind of detail that allows us to write larger- and larger-scale systems in the first place.)

This "seeking to avoid exclusion" requirement for interoperability is why we like using XML so much. Not only is it rooted in plain-text encoding, which makes it relatively easy to pass around multiple platforms, but its ubiquity makes it something that we can reasonably expect to be easily consumed in any given language or platform. Coupled with recent additions to build higher-order constructs on top of XML, we have a pretty good way of representing data elements in a way that lots of platforms can consume. Does interoperability require XML to work? Of course not. We've managed for the better part of forty years to interoperate without XML, and we probably could have kept on doing quite well without it; XML makes things easier, nothing more.

Services, on the other hand, is a design philosophy that seeks to correct for the major failures in distributed object and distributed component design. It's an attempt to create "things" that are more reliable to outages, more secure, and more easily versioned and evolvable, things that objects/components never really addressed or solved.

For example, building services to be autonomous (as per the "Second Tenet of Service-Orientation", as coined by Mr. Box) means that the service has to recognize that it stands alone, and minimize its dependencies on other "things" where possible. Too much dependency in distributed object systems meant that if any one cog in the machine were to go out for some reason, the entire thing came grinding to a halt, a particularly wasteful exercise when over three-quarters of the rest of the code really had nothing to do with the cog that failed. But, because everything was synchronous RPC client/server calls, one piece down somewhere on the back-end meant the whole e-commerce front-end system comes to a shuddering, screeching pause while we figure out why the logging system can't write any more log messages to disk.

Or, as another example, the First Tenet states that "Boundaries are explicit"; this is a well-recognized flaw with any distributed system, as documented back in 1993 by Wolrath and Waldo in their paper "A Note on Distributed Computing". Thanks to the fact that traversing across the network is an expensive and potentially error-prone action, past attempts to abstract away the details of the network ("Just pretend it's a local call") eventually result in nothing but abject failure. Performance failure, scalability failure, data failure, you name it, they're all consequences of treating distributed communication as local. It's enough to draw the conclusion "well-designed distributed objects are just a contradiction in terms".

There's obviously more that can be said of both the "Web" angle as well as the "Services" angle, but hopefully enough is here to recognize the distinction between the two. We have a long ways to go with both ideas, by the way. Interoperability isn't finished just because we have XML, and clearly questions still loom with respect to services, such as the appropriate granularity of a service, and so on. Work remains. Moreover, the larger question still looms: if there is distinction between them, why bring them together into the same space? And the short answer is, "Because individually, each are interesting; collectively, they represent a powerful means for designing future systems." By combining interoperability with services, we create "things" that can effectively stand alone for the forseeable future.

And in the end, isn't that what we're supposed to be doing?

Mule 是一个基于ESB架构理念的消息平台。Mule 的核心是一个基于SEDA的服务容器，该容器管理被称为通用消息对象（Universal Message Objects /UMO）的服务对象，而这些对象都是POJO。所有UMO和其他应用之间的通信都是通过消息端点（message endpoint）来进行的。这些端点为众多的分立的技术，比如Jms, Smtp, Jdbc, Tcp, Http, Xmpp, file等等，提供了简单和一致的接口。

Mule 应用通常是由网络中的许多Mule 实例组成。每一个实例都是一个驻留一个或者多个UMO组件的轻量级容器。每一个UMO 组件都有一个或者多个通过它（们）发送和接收事件的端点。

容器通过UMO组件提供各种各样的服务，比如事务管理、事件转换，路由，事件关联、日志、审计和管理等等。Mule将对象构造从管理手段中分离出来，通常流行框架和IoC/DI 容器，如Spring, PicoContainer 或者 Plexus 可用这种管理手段来构建你的UMO 组件。

很多人认为， "Mule是一个Jms 实现"。实际上，Mule 不是一个Jms server，但是可以配置来使用任何你觉得非常漂亮的Jms server。Mule 的理念是，如果已经有了稳定和广泛接受的实现，就不会直接实现任何传输。例如，Mule 就重用了Axis 和 GLUE 的SOAP栈而不是重新实现一个。Mule 提供了一个一致的服务集来管理任何类型的连接的事件流、关联、事务、安全和审计。

下面是Mule Server 组件的简单图示：

Mule Manager

Mule Manager是Mule server 实例的中心(也称为一个节点户或者Mule Node)。其主要的角色是管理各种对象，比如Mule实例的连接器、端点和转换器。这些对象然后被用来控制进出你的服务组件的消息流，并且为Model和它所管理的组件提供服务。

Model

model 是管理和执行组件的容器。它控制进出组件的消息流，管理线程、生命周期和缓充池。默认的MuleModel是基于SEDA的，它使用一个有效的基于事件的队列模型来获取的最大的性能和直通性。

UMO Components

UMO代表Universal Message Object；它是一个可以接收来自于任何地方的消息的对象。UMO 组件就是你的业务对象。它们是执行引入的事件之上的具体业务逻辑的组件。这些组件是标准的JavaBean，组件中并没有任何Mule特定的代码。Mule 基于你的组件的配置处理所有进出组件的事件的路由和转换。

Endpoints

Endpoint是Mule的通信能力的基础。一个Endpoint定义了两个或者多个组建应用或者存储库之间的通信渠道。并且提供了一个强大的机制来允许你的对象在一个统一的方式上再多种协议之上进行交谈。端点可以通过消息过滤器、安全拦截器和事务信息进行配置来控制什么消息，在何时，以及怎样通过端点进行发送和接收。

External Applications

外部应用可以使任何应用，从应用服务器到遗留的传统应用，主机程序，或者C/S系统。基本上是任何可以产生和操纵数据的应用。因为Mule通过endpoints执行所有通信，UMO 组件并不打算在其中包含应用产生数据，以及应用主流，以及使用传输协议的部分。

关键特性

• 基于J2EE 1.4的企业消息总线（ Enterprise Service Bus (ESB)）和消息代理（broker）
• 可插入性连接，比如Jms (1.0.2b 和 1.1), vm (嵌入), jdbc, tcp, udp, multicast, http, servlet, smtp, pop3, file, xmpp等
• 支持任何传输之上的异步，同步和请求响应事件处理机制
• 支持Axis或者Glue的Web Service.
• 灵活的部署结构[Topologies]包括Client/Server, P2P, ESB 和Enterprise Service Network.
• 支持声明性和编程性事务，包括XA 支持
• 对事件的路由、传输和转换的断到端支持
• Spring 框架集成。可用作ESB 容器，而Mule c也可以很容易的嵌入到Spring 应用中。
• 使用基于SEDA处理模型的高度可伸缩的企业服务器
• 支持REST API 来提供技术独立和语言中立的基于web的对Mule 事件的访问
• 强大的基于EIP模式的事件路由机制
• 动态、声明性的，基于内容和基于规则的路由选项
• 非入侵式的方式。任何对象都可以通过ESB 容器管理
• 强大的应用集成框架
• 完整的可扩展的开发模式

何时使用

一般在这些情形下使用Mule -

• 集成两个或者多个需要互相通信的或者多个现有的系统.
• 需要完全和周围环境去耦合的应用，或者需要在系统中伸缩不止一个组件的系统
• 开发人员不知道未来是否会将其应用分发或者伸缩需求的单VM 应用。

项目地址：http://mule.codehaus.org/