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 概念，例如服务编排、目录、转换等等。
•  按需操做环境需求，好比管理与自治功能以及基础架构智能功能。
•  跨越具备不一样全部权的多个网络、多个协议以及多个域的真正意义上的异步操做。