支持 SOA 的最低功能的 ESB 实现

    如果在前面确定的功能中只有一部分和大多数 SOA 场景相关，我们可能会问：实现 ESB 所需的一组最低功能由什么构成？为此，考虑最被普遍认同的 ESB 定义的原理：

    1.ESB 是一种逻辑体系结构组件，它提供与 SOA 的原则保持一致的集成基础架构。

    2.SOA 原则需要使用与实现无关的的接口、强调位置透明性和可互操作性的通信协议、相对粗粒度和封装可重用功能的服务定义。

    3.ESB 可以作为分布式的异构基础架构进行实现。

    4.ESB 提供了管理服务基础架构的方法和在分布式异构环境中进行操作的功能。

    表 2展示了根据这些原则定义的最低 ESB 功能

    请注意这些最低功能并不需要使用特别的技术，比如 EAI 中间件、Web 服务、J2EE 或 XML。这些技术的使用非常接近也非常符合需求，但是不必强制要求使用它们。相反，最低功能几乎只需简单地使用 SOAP/HTTP 和 WSDL 就可以实现（当然不是所有的情况都这样）：

    1.URL 寻址和现有的 HTTP 和 DNS 基础架构提供了一个具有路由服务和位置透明性的“总线（bus）”。

    2.SOAP/HTTP 支持请求-响应（Request-Response）通信规范。

    3.HTTP 传输协议被广泛地使用。

    4.SOAP 和 WSDL 是开放、与实现无关的服务通信和连接模型。

    然而，这些 SOAP/HTTP 和 WSDL 的基本应用只是点到点（point-to-point）的集成，并不能实现一些 ESB 需要的关键功能：

    1.目前还没有用于控制服务寻址和命名的管理功能。服务名称通过每个适配器单独进行控制的，服务路由控制则分散在由服务客户端调用的地址、HTTP 基础架构和分配给适配器的服务名称之间。

    2.虽然这种方法依赖于实现细节，但是它往往并不能使服务实现的替代变得简单；服务请求者代码（也可能是开发工具生成的）通常通过特定地址的特定协议直接绑定到具体的服务提供者实现。如果想要用另一个服务实现来替代原来的服务实现，就需要修改应用程序代码并重新部署这些代码。

    当然，在许多甚至是大多数情形中往往需要其他的功能，并且这种需要变得越来越常见。特别地，不管是现在还是以后，下面的需求类型可能会导致更复杂高级的技术的使用：

    1.服务质量和服务级别功能。

    2.高级 SOA 概念，例如服务编排、目录、转换等等。

    3.按需操作环境需求，比如管理与自治功能以及基础架构智能功能。

    4.跨越具有不同所有权的多个网络、多个协议以及多个域的真正意义上的异步操作。