【IT168 技术文档】由于众多原因，企业服务总线 (ESB) 是任何企业级 SOA 必不可少的一部分。
随着实施面向服务结构体系 (SOA) 这一观念的日渐普及，企业发现自己的服务组合规模日益增大。如果不遵循正确的体系结构模式，则很难有效地利用和重用这些服务。
企业服务总线 (ESB) 是一种相对较新的软件类别，我们可以使用它来满足上述目的。它提供了一个急需的中间层，从而简化了企业 SOA 实施的数据传递、服务访问、服务重用以及服务管理。ESB 还支持智能指导的通信，调解松散耦合业务组件和取消耦合的业务组件之间的关系。
在“精通 SOA”的这一部分中，您将了解 ESB 为什么是企业级 SOA 必不可少的一部分，以及如何实施 ESB（包括常见问题）。
是否需要ESB？
正如本系列第 1 部分中所说明的那样，SOA 是应用程序在设计、开发和集成方面的一次根本性转变。SOA 还有助于将企业应用程序作为可轻松集成和重用的模块化业务服务来进行开发。然而，SOA 还意味着各种挑战，其中许多挑战可直接通过 ESB 解决：
可靠的消息传递：可靠的数据传输仍然是所有集成解决方案的基本需要。虽然 SOA 的原则需要基于标准的、与平台无关的消息协议，但该原则本身并未考虑可靠的数据传递。各项标准（如 WS-RM）正在逐渐支持该功能，但它们还不够成熟或者未被广泛采用。
服务虚拟化：SOA 代表了一种基本的体系结构模式，在该模式中，任何服务使用方均可从任何平台访问一个服务提供方。这又意味着适当的协议和语法调解在适当的位置隔离了使用方和提供方。
动态发现和调用服务：为了优化服务的重用，服务使用方需要一个中介功能来了解服务请求的特性，从而方便与提供方进行连接。在理想的 SOA 中，这种关系将在运行时作为中介。
策略管理：已知和未知服务使用方进行访问都需要一个抽象的策略管理模型，该模型除了强制执行与服务提供方实施无关的更复杂的业务级别策略外，还能够强制执行身份验证、授权和加密。
管理和监视服务：逐渐增加的服务数量导致环境越来越复杂。必须监视该环境以了解其可用性、性能以及任何技术或业务级别错误。
系统异构性：人们通过常用的应用程序以及用来连接它们的软件可以发现，今天的新应用程序就是明天的旧应用程序。这种新技术的普及是必然的，因此，设计系统时必须考虑让其支持这种变化。
从技术实施细节中抽取业务逻辑：SOA 的目标之一是提供一种分层的方法来开发系统，该方法将技术变化从业务流程的变化中隔离出来，并且将业务流程的变化从技术变化中隔离出来。实际上，必须从一开始就将这种“分别考虑”设计到体系结构中。
解决这些问题的标准方法 — 无论是企业范围还是部门范围 — 是任何 SOA 项目成功的基础。不能保证数据传递的 SOA 解决方案对大多数业务事务而言不够强健，不能将业务流程从转换和路由逻辑中抽取出来的 SOA 解决方案不会很敏捷。而且，一个无法适应标准和产品发展变化的体系结构并不会降低 TCO。ESB 模式（以及相关 ESB 产品的引入）是全面的 SOA 解决方案成功的基础。
ESB 部署的先决条件
深入讨论细节之前，我们先进行一下回顾，就会发现并非所有 SOA 实施都需要重大的重用和松散耦合。例如，较小的实施可能只会从 ESB 的增加中获得边际效益。
您需要满足一些战术条件才能建立对 ESB 的需要。按照重要性顺序，这些条件依次为：
1.服务使用方和提供方可能是松散耦合的，或者需要同步、非确定性的路由（其中使用方需要响应，但不会显式知道服务提供方）。
2.执行业务事务之前，需要根据数据、使用方或提供方执行专门的功能（可能包括策略验证、转换等）。
3.必须有一种将端点应用程序连接到总线的方法（通过重新设计或者通过适配器），该方法必须能够在面向服务的模型中运行这些应用程序（并非所有应用程序都能够轻松地支持服务。例如，传统的老式程序（如客户数据应用程序）使用连接到老式屏幕的、基于批处理的编程模型来运行。它们可能不会很容易地适应更基于事务的 SOA 模式。）
对于所有复杂的计算体系结构，这三个条件仅仅是指导方针。肯定存在这样的情况：无需同时满足以上三个条件即可轻松地判别 ESB。着手进行 SOA 规划时，不但要关心战术方面，还要考虑长期策略目标。
自上而下与自下而上
SOA 的两种主要方法通常被称作“自上而下”和“自下而上”。在自上而下的方法中，采用 SOA 是由业务方驱动的，结果是一个专门设计以满足业务需求的体系结构，着重于效率。企业的 IT 部门通常推崇更实用的自下而上的方法，因为该方法更关心服务虚拟化，其主要目标是将成本降至最低并将更多灵活性结合到核心 IT 资产中。
可以想象，人们就哪种方法最适合或最有效展开了激烈的争论。在此，我们不会偏袒任何一方，而是探讨 ESB 是否与这两种方法相关。
答案是肯定的，自上而下和自下而上这两种 SOA 方法通常都需要 ESB。这两种方法所使用的工具没有太大的区别；只不过引入这些工具的时间不同。在自下而上方法中，可能在最初阶段就开始使用 ESB 来执行低级数据和系统集成。在自上而下方法中，最初关注的可能是构建服务，不过稍后这些服务之间需要进行互连时，就该使用 ESB 了。
