W3CHINA.ORG讨论区--从 EAI 到 ESB的发展

从 EAI 到 ESB的发展

IONA Technologies

简介
作为业界的领先者，IONA 是企业集成技术产品的最前沿。为了向用户提供最先进的企业集成功能，IONA 始终如一地改进着自己的产品线。随着面向服务体系结构 (SOA) 的不断普及，这种经过 IONA CORBA 客户多年实践的系统设计、开发和部署方法造就了一类新的集成产品：企业服务总线 (ESB)。
ESB 是软件行业的下一代集成产品的名称。ESB 沿用企业应用程序集成 (EAI) 的技术道路前行，在改进 EAI 中的某些技术环节的同时，采用了 EAI 技术中的更为有效的方面。尽管 EAI 和 ESB 的目标相同，但是在技术体系结构方面，这两项产品的区别仍很大。
EAI 的发展历程
从历史上看，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 的发展
ESB 是下一代的企业集成技术，在 EAI 退出市场后取代了它的位置。与 EAI 一样，ESB 也是一项允许开发人员集成使用不同中间件技术创建的异类系统的技术。ESB 一方面利用了它面向服务的优势，同时还通过使用更有效、更灵活的内部体系结构进一步改进了它的上一代 EAI 产品。
了解 SOA 和 ESB 之间的关系非常重要。SOA 代表策略、惯例以及框架，这些因素使得应用程序可以提供各种功能并且可以作为服务集合供其它应用程序使用。如图 3 所示，服务是一种业务完整的逻辑工作单元，可以通过直接开放的文档接口从独立设计环境以编程方式进行访问。可以调用、发布和发现服务，也可以使用单一的基于标准的接口方式抽象实现。应用程序软件由以松散 1 对 1 耦合关系存在的服务和服务消费者（即客户）构成。

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

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

Artix — 可扩展的 ESB
IONA  提供 ESB 以便进行灵活的分布式集成，这也为 EAI 系统的所有人提供了一种增量的解决方案以便SOA 可以逐步迁移到 SOA。
ESB 是一种更先进的体系结构，但是今天的部分 ESB 产品却欠缺大型企业需要的全部能力。大多数这类产品都依赖单一的协议（例如 SOAP）、程序设计语言（例如 Java）、消息传送工具（例如 JMS）或部署体系结构（例如 J2EE 应用程序服务器），这些特点将限制它们桥接多个平台的能力。除此之外，许多 ESB 都是由新创业的小型公司行销的，这些公司往往缺乏管理复杂企业集成项目的经验。
Artix 是可扩展的企业服务总线 (ESB)，通过部署、管理和保证面向服务的体系结构 (SOA) 的安全性，可以帮助具有复杂和异构 IT 系统的企业极大地降低其运营成本，而且无需集中式交换中心。Artix 使用分布式计算技术利用现有的中间件投资，并采用现代化的方式改进这些投资，以便协助全球 2000 强公司更快、更有效地将它们的产品和服务提交给客户。Artix 具有以下特点
• 以增量方式采用 SOA — Artix 使用现有的基础架构创建智能化且基于标准的端点网络，以便企业可以从低风险、高价值的 SOA 项目开始，逐渐添加所需的服务
• 动态、可修改 — Artix 端点可以独立配置以便可以对服务进行扩展、修改和热部署操作，而且不影响企业中的其他部分
• 技术中立 — Artix 是一种用于连接各式轻量级端点的多平台、多协议解决方案，无需昂贵而笨重的中央服务器，并且不会出现将企业锁定在一家供应商的情况
IONA 在提供关键任务基础架构方面保持着良好的记录，已经为全球 2000 强公司客户建立了多个最早和最大的 SOA 系统，这些客户包括：Credit Suisse、BellSouth、Raymond James & Associates、Marconi 和 Deutsche Post (DHL)。

图  5：Artix 分布式体系结构
如图 5 和图 6 所示，Artix 体系结构基于一个高效的微内核和一系列插件，这一结构使它可以适应任意中间件和应用程序体系结构的组合。其中包括适应新的传输协议、负载格式、安全模式、会话管理、事务支持和弹性的要求。对于集成系统而言，Artix 的插件扩展方法具有两个方面的重要影响：
 复杂或特殊目的集成要求可以通过专门设计的新插件实现。这种插件方法不但可以让集成运行时间更短而更快，而且可以解决多种集成问题。
 集成部署完毕后，对某个应用程序接口或者是可扩展端点所作的更改，可以在不影响该端点所提供的服务情况下完成。

图 6：Artix 的可扩展端点
对底层体系结构和应用程序基础架构所作的更改对于集成过程的其他参与者来说是透明的。可用来进一步定义 Artix 产品的其它功能包括对以下项目的支持：
 高性能和小核心的集成方式，无需支付因额外的网络数据流量或转换导致传统开销
 主流中间件和基础架构的协议和数据格式（包括 IBM、BEA 和 Microsoft 的 SOA 平台）
 现有企业系统的标准应用程序平台：大型主机事务 (IMS/CICS)、C++ 客户机/服务器应用程序和诸如 CORBA 或 BEA Tuxedo 等的中间件平台
 现有系统的应用方式，其中包括发布/订阅、请求/响应和异步应用等
 SOA 平台和 Web services（WS-Security、Kerberos Tokens 等）的新兴安全标准以及现有企业系统的原有安全模式
 通过 IBM Tivoli、CA Unicenter 和 HP OpenView 等现有企业管理基础架构实现管理
 与主要 SOA 平台套件的运行时和开发工具实现集成
Artix 用户发现 Artix 的可扩展性使他们能够在不更改这些系统的情况下利用并扩展现有系统。这使得他们可以建立易于管理和部署的安全容错系统。产品的可扩展性不但推动了小核心高性能集成解决方案的发展，而且在大幅度降低开销的同时还满足了企业对吞吐量的要求。

总结
正如之前从人工编码到 EAI  技术的发展过程一样，中间件从 EAI 到 ESB 的发展在减少系统的总体创建成本的同时为开发人员和用户带来了更强大、更灵活的工具。在很多方面，从 EAI 到 ESB 的发展与单一的企业应用发展对面向服务的应用都具有同样的原动力。这两种情况下，用户都因为系统的复杂性而遇到了难题，并且都需要一种简单而灵活的方式来解决此问题。IONA 承诺，要为业界提供这一改进所要求的领先理念和产品。
全球 2000 强公司，具有异构系统和各种应用程序，都正在使用 Artix  来简化企业中的复杂系统。IONA 凭借十多年提供高性能关键任务应用程序的历史，正在帮助这些公司重新调整当前的投资方向，使其逐步转向使用开放式的体系结构。
包括 BellSouth、AT&T、Marconi 和 DHL（德国邮政）在内的  IONA 的客户都在使用可扩展 ESB 使现有系统具有服务功能，并且建立一个可缩放、适应性强的 SOA 体系结构。它们之所以选择 Artix，是因为它可以提供广泛的平台支持、具有可扩展性以及企业级的服务质量，现在，这些企业已经开始在常用平台上（例如 Microsoft .NET Framework、IBM WebSphere 或 BEA WebLogic）建立新的业务应用和工作流。
展望未来，IONA 的客户可以信赖 IONA 作为自己的业务伙伴，不论是今天还是将来，IONA 都将为它们提供业界最好的产品和服务。

word 文档参见：http://www.iona.com.cn/docs/docs/Artix_Evolution-of-EAI_cn.doc


	W 3 C h i n a ( since 2003 ) 旗下站点苏ICP备05006046号《全国人大常委会关于维护互联网安全的决定》《计算机信息网络国际联网安全保护管理办法》	69.000ms