架构那点事系列三 - 由EAI到ESB

        最近在梳理公司的EAI平台 — JCAPS，顺便翻阅了一些“历史”文献，梳理成文，希望能加深大家对SOA的认识。

        ESB 是软件行业的下一代集成产品的名称。ESB 沿用企业应用程序集成 (EAI) 的技术道路前行，在改进 EAI 中的某些技术环节的同时，采用了 EAI 技术中的更为有效的方面。尽管 EAI 和 ESB 的目标相同，但是在技术体系结构方面，这两项产品的区别仍很大。

       从历史上看，EAI 技术是软件行业首次尝试将市场上各种不同中间件解决方案整合为单一产品套件。当各公司开始寻求在不同的自动化系统间交换信息时，对 EAI 的需求也就应运而生了。在上世纪的九十年代，企业范围内诸如客户关系管理 (CRM) 和企业资源计划 (ERP) 等业务举措是促使 EAI 系统诞生的主要驱动因素。

        在 EAI 面世之前，中间件的蓝图主要是由一系列协议栈（例如 CORBA、Tuxedo 和 MQ）以及数据格式（XML、XDR、固定格式、可变格式等）构成的。这些技术中的每一项都能够在很大程度上满足企业自身的集成需要，但是这需要选定的协议和数据格式在企业中完全通用才能够实现。事与愿违，实际情况却是，大中型 IT 企业都不可避免的具有异构特点。 

                           图 1 EAI 代理程序充当交换中心角色

        如图 1 所示，EAI 采用了一种简单有效的方式来解决不同应用程序间的集成问题。EAI 软件创建了一个交换中心，用于转换不同应用程序间的数据和消息。EAI 交换中心使用这些适配程序将所有进入数据的格式重新转换为一种 EAI 交换中心内部和外发适配程序都可以理解的通用格式，并将其称为规范格式。每个适配程序都是一个有自主权的实体软件，存在多个分别负责管理各种应用程序特定交互操作的管理层，同时还另具有一些传输层，用于管理与应用程序和交换中心的连接。  
        为实现 EAI 各组件间的连接，EAI  交换中心会在所有的内部集成过程中都采用一个如 JMS 的异步消息代理程序。除了重新更改消息负载格式外，所有应用程序间的交互都要经过中间件的多次转换。而且，应用程序所需的，例如事务处理和验证/授权安全等服务质量功能通常都无法实现这些转换。

      图 2  交换中心不断进行数据编组

       作为第一代产品，EAI 是成功的，它提供了一个前所未有的解决方案。但是 EAI 体系结构有其固有的局限性，因此限制了它提供企业级可持续解决方案的能力。如图 2 所示，集中式交换中心使得企业（或者至少是企业中的几个特定的人）可以采用中央控制的方式。但是不断地将数据编组为规范格式或转变回原有格式的代价就是造成额外的处理负担，也就是需要购买高端服务器和管理程序实现对其的管理。虽然大多数 EAI 解决方案都允许您在集群中部署多个交换中心以便获取更大的可缩放性，但这只是在某个限度内是实用，而当您添加更多专用硬件时很快就会变得非常昂贵。

       相对人工编码而言，每次改变企业应用程序组合的中间件和应用程序接口时 EAI 具有明显的优势。这是一项技术上的突破，当整个行业的想法都聚焦在为支持整个企业的举措而需要大型应用程序交换数据时它将发挥最大的作用。因为这是第一代的 EAI 工具，供应商尝试使用增量的方式来处理 EAI 的缺点。但是，因为不断地添加新功能，这使得 EAI 系统变得庞大、缺乏灵活性且难于管理。从长远来看，如果要实现真正的企业集成需要一种更好的技术。

       ESB  是下一代的企业集成技术，在 EAI  退出市场后取代了它的位置。与 EAI 一样，ESB 也是一项允许开发人员集成使用不同中间件技术创建的异构系统的技术。ESB 一方面利用了它面向服务的优势，同时还通过使用更有效、更灵活的内部体系结构进一步改进了它的上一代 EAI 产品。

 
    了解 SOA 和 ESB 之间的关系非常重要。SOA 代表策略、架构，这些因素使得应用程序可以提供各种功能并且可以作为服务集合供其它应用程序使用。服务是一种业务完整的逻辑工作单元，可以通过直接开放的文档接口从独立设计环境以编程方式进行访问。可以调用、发布和发现服务，也可以使用单一的基于标准的接口方式抽象实现。应用程序软件由以松散 1 对 1 耦合关系存在的服务和服务消费者（即客户）构成。 

图3  ESB 提供轻量级的分布式体系结构

       SOA 是软件行业为应对单一大型应用程序的管理问题产生的解决方案。正如我们想象的那样，应用程序体系结构的这一变化对于怎样才能获得最佳的应用程序集成产生了极大的影响。如图 3所示，ESB 为服务提供者和服务消费者之间的集成提供了一个平台。在现代平台上开发的新应用程序，其本质都是面向服务的应用。但是，有一些现有的企业应用程序并没有使用 SOA 的设计理念。在此情况下，ESB 应该能够提供将这些应用程序暴露为服务的能力。而因为以下一些原因，大家正在转而使用最新的 ESB架构：

        a 更智能的端点 — ESB 启用的体系结构在应用程序与外界的接口点处配置了更多的智能功能。ESB 允许每个端点使用各种标准（如 WSDL 等）以服务的形式呈现自己，因此不需要为每个应用程序编写专用接口。可以在端点（客户机和服务器）创建时将集成智能性部署在这些端点上。可以绕过规范格式而将负载直接转换为目标格式。这一方法有效的去除了 EAI 产品所固有众多复杂特性。 
        b 集中式与分布式 — 当 EAI 完全采用中心辐射型通信方式时，ESB 采用了轻量级的分布式体系结构。当必须将程序间的每次交互转换为规范格式时，集中式的交换中心才有意义。ESB可以将更多的处理逻辑分配到端点上。这与大型主机和现代的分布式系统体系结构间的区别相似。交换中心与大型主机一样，仍然可以用于某些需要它的体系结构中，但它们只是开发人员的一项选择，而不是供应商指定的要求。 
       c 无集成堆叠 — 过去，当客户需要使用 EAI 产品来解决更多问题时，各供应商就会在 EAI 中附带添加多种堆叠的专用功能。随着时间的推移，这些堆叠的集成都成为专用的语言，需要具有更高的技术水平才能使用。与此不同的是，ESB 是一个具有相对少层级的软件，您可以使用开放式标准应用其它处理层。例如，如果某个 ESB 用户希望部署某个     c.特定的业务流程管理工具，您只需使用行业标准接口（如用于协调这些业务流程的 BPEL）就可以很轻松地将该工具集成到 ESB 中。

        ESB 方法的立即见效的短期优势在于它在获得与 EAI 方法相同总体效果的同时，花费的总拥有成本更低。这一节省不但可以通过减少硬件和软件的花费来实现，而且还可以通过因使用灵活的分布式框架而节约成本。也正因为此，企业应用也越来越重视SOA，SCA。。。