ESB企业服务总线

ESB是企业服务总线（Enterprise Service Bus）的缩写，是中间件技术与Web Service等技术结合的产物，也是SOA系统中的核心基础设施。ESB就是一个服务的中介，形成服务使用者->ESB服务Proxy->服务提供者的生物链，中介的作用在不同应用中各有不同：

• 解耦中介 ：客户对实际服务提供者的身份、物理位置、传输协议和接口定义都是不知道也不关心的，交互集成代码提取到了业务逻辑之外，由ESB平台进行中央的宣告式定义。ESB平台实现协议转换 (WebService，Http，JMS...)，消息转换 (转换、充实、过滤)，消息路由 (同步/异步、发布/订阅、基于内容路由、分支与聚合...)。
• 服务中介 ：ESB平台作为中介提供服务交互中的基础服务。ESB平台实现SLA (可靠性保证，负载均衡，流量控制，缓存，事务控制，加密传输)，服务管理监控 (异常处理，服务调用及消息数据记录，系统及服务的状态监控，ESB配置管理)，统一安全管理 (这个有点理想主义)。
• 服务编排 ：多个服务进行编排形成新的服务。ESB支持一个直观的形式定义新组合服务的流程(工作流、BPEL 或 代码级编排)。

从上面可以看到ESB的基本功能仍然是数据传输，消息协议转化，路由三大核心功能。有这三大核心功能也可以看到在进行异构系统的整合时候往往根据需要 ESB提供这些功能。没有ESB时候也可以实现SOA，比如借助SCA和BPEL来实现SOA，当时却很难实现消息协议转化和动态路由。

ESB在发展过程中有从原有的消息中间件转化为ESB产品的，这类消息中间件和数据总线产品在原有的EAI企业应用集成中应用比较多。而SOA根据强调了基于服务的集成，以Web Service服务为基本的管理单元。一个服务的定位是关于如何把业务逻辑表现成为一组相互独立的，自描述的且能互操作的实体。

对于SOA关注的是服务全生命周期，通过服务实现业务价值。而ESB关注的是服务中介和服务的集成，是SOA的基础设施。SOA有两个核心组件，一个是 ESB，一个是BPEL，而ESB是基础设施，BPEL是业务流程驱动下服务的集成和整合。离开了SOA，ESB将失去它所连接的服务，而仅仅是一个总 线，同时也将变得毫无价值。Bobby做了一个比喻：路是没有任何价值的，除非你利用它把一个东西从一个地方移到另外一个地方。而离开SOA，ESB就像 一个没人使用的道路。

做SOA的事情不要先上来建立一个大而全的ESB，相反是关注你的业务问题，找到用SOA的方法来解决业务上的需求，在解决这个问题的过程当中，你会看到 一系列的业务服务。这些业务服务是会产生业务价值的。它可以灵活地组装，动态地解决你变化的业务需求。这是它的价值，只有这样才能使你的业务敏捷起来，随 需应变起来。而在服务的组装过程中，你再去考虑利用ESB来把他们连接起来。



ESB 需要某种形式的服务路由目录（service routing directory）来路由服务请求。然而，SOA 可能还有单独的业务服务目录（business service directory），其最基本的形式可能是设计时服务目录，用于在组织的整个开发活动中实现服务的重用。Web 服务远景在业务服务目录和服务路由目录的角色中都放置了一个 UDDI 目录，因而使得可以动态发现和调用服务。这样的目录可以视为 ESB 的一部分；然而，在这样的解决方案变得普遍之前，业务服务目录可能与 ESB 是分离的。

标准的 ESB 功能

通信	服务交互
路由 寻址 通信技术、协议和标准（例如 IBM® WebSphere® MQ、HTTP 和 HTTPS） 发布/订阅 响应/请求 Fire-and-Forget，事件 同步和异步消息传递	服务接口定义（例如，Web 服务描述语言（Web Services Description Language，WSDL）） 支持替代服务实现 通信和集成所需的服务消息传递模型（例如 SOAP 或企业应用程序集成 (EAI) 中间件模型） 服务目录和发现
集成	服务质量
数据库 服务聚合 遗留系统和应用程序适配器 EAI 中间件的连接性 服务映射 协议转换 应用程序服务器环境（例如 J2EE 和 .NET） 服务调用的语言接口（例如 Java 和 C/C++/C#）	事务（原子事务、补偿、Web 服务事务（WS-Transaction）） 各种确定的传递范例（例如 Web 服务可靠消息传递（WS-ReliableMessaging）或对 EAI 中间件的支持）
安全性	服务级别
身份验证 授权 不可抵赖性 机密性 安全标准（例如 Kerberos 和 Web 服务安全性（WS-Security））	性能 吞吐量 可用性 其他可以构成契约或协定的持久评估方法
消息处理	管理和自治
编码的逻辑 基于内容的逻辑 消息和数据转换 有效性 中介 对象标识映射 数据压缩	服务预置和注册 记录、测量和监控 发现 系统管理和管理工具的集成 自监控和自管理
建模	基础架构智能
对象建模 通用业务对象建模 数据格式库 B2B 集成的公共与私有模型 开发和部署工具	业务规则 策略驱动的行为，特别是对于服务级别、服务功能的安全和质量（例如 Web 服务策略（WS-Policy）） 模式识别

上面的许多功能既可以使用专有技术实现，也可以通过利用开放标准实现。然而，使用不同的技术来实现 ESB 可能会使它们的性能、可伸缩性和可靠性这些特性显著不同，同时 ESB 功能和所支持的开放标准也会有所不同。由于这些原因，再加上最近制订和正在兴起的一些相关标准，当今实现 ESB 的许多关键决策都涉及到成熟的专有技术和不成熟的开放标准之间的权衡。

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

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

•     ESB 是一种逻辑体系结构组件，它提供与 SOA 的原则保持一致的集成基础架构。
•     SOA 原则需要使用与实现无关的的接口、强调位置透明性和可互操作性的通信协议、相对粗粒度和封装可重用功能的服务定义。
•     ESB 可以作为分布式的异构基础架构进行实现。
•     ESB 提供了管理服务基础架构的方法和在分布式异构环境中进行操作的功能。

最低的 ESB 功能

通信	集成
提供位置透明性的路由和寻址服务 控制服务寻址和命名的管理功能 至少一种形式的消息传递范型（例如，请求/响应、发布/订阅等等） 支持至少一种可以广泛使用的传输协议	支持服务提供的多种集成方式，比如 Java 2 连接器、Web 服务、异步通信、适配器等等
服务交互
一个开放且与实现无关的服务消息传递与接口模型，它应该将应用程序代码从路由服务和传输协议中分离出来，并允许替代服务的实现。

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

• URL 寻址和现有的 HTTP 和 DNS 基础架构提供了一个具有路由服务和位置透明性的“总线（bus）”。
• SOAP/HTTP 支持请求-响应（Request-Response）通信规范。
• HTTP 传输协议被广泛地使用。
• SOAP 和 WSDL 是开放、与实现无关的服务通信和连接模型。

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

•     目前还没有用于控制服务寻址和命名的管理功能。服务名称通过每个适配器单独进行控制的，服务路由控制则分散在由服务客户端调用的地址、HTTP 基础架构和分配给适配器的服务名称之间。
•     虽然这种方法依赖于实现细节，但是它往往并不能使服务实现的替代变得简单；服务请求者代码（也可能是开发工具生成的）通常通过特定地址 的特定协议直接绑定到具体的服务提供者实现。如果想要用另一个服务实现来替代原来的服务实现，就需要修改应用程序代码并重新部署这些代码。

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

•  服务质量和服务级别功能。
•  高级 SOA 概念，例如服务编排、目录、转换等等。
•  按需操作环境需求，比如管理与自治功能以及基础架构智能功能。
•  跨越具有不同所有权的多个网络、多个协议以及多个域的真正意义上的异步操作。