其次，ESB明确强调消息(Message)处理在集成过程中的作用，这里的消息指的是应用环境中被集成对象之间的沟通。以往传统的EAI实施中碰到的最大的问题就是被集成者都有自己的方言，即各自的消息格式。作为基础架构的EAI系统，必须能够对系统范畴内的任何一种消息进行解析。传统的EAI系统中的消息处理大多是被动的，消息的处理需要各自中间件的私有方式支持，例如API的方式。因此尽管消息处理本身很重要，但消息的直接处理不会是传统EAI系统的核心。ESB系统由于集成对象统一到服务，消息在应用服务之间传递时格式是标准的，直接面向消息的处理方式成为可能。如果ESB能够在底层支持现有的各种通讯协议，那么对消息的处理就完全不考虑底层的传输细节，而直接通过消息的标准格式定义来进行。这样，在ESB中，对消息的处理就会成为ESB的核心，因为通过消息处理来集成服务是最简单可行的方式。这也是ESB中总线(Bus)功能的体现。其实，总线的概念并不新鲜，传统的EAI系统中，也曾经提出过信息总线的概念，通过某种中间件平台，如CORBA来连接企业信息孤岛，但是，ESB的概念不仅仅是提供消息交互的通道，更重要的是提供服务的智能化集成基础架构。
最后，事件驱动成为ESB的重要特征。通常服务之间传递的消息有两种形式，一种是调用(Call)， 即请求/回应方式，这是常见的同步模式。还有一种我们称之为单路消息(One-way)，它的目的往往是触发异步的事件， 发送者不需要马上得到回复。考虑到有些应用服务是长时间运行的，因此，这种异步服务之间的消息交互也是ESB必须支持的。除此之外，ESB的很多功能都可以利用这种机制来实现，例如，SOA中服务的性能监控等基础架构功能，需要通过ESB来提供数据，当服务的请求通过ESB中转的时候，ESB很容易通过事件驱动机制向SOA的基础架构服务传递信息。
2.4.2 ESB的要素
ESB连接和企业的IT基础结构，可以跨越不同的地域，支持不同的传输协议，它可以自动路由消息并且提供系统级的功能（例如，消息的格式自动转换），ESB的实现必须是基于标准的规范, 并且这些实现必须是安全的、可靠的，并且在非常高的流量压力情况下可管理。
在
遵循SOA架构的ESB 模式中，服务交互的参与方并不直接交互，而是通过一个总线交互，该总线提供虚拟化和管理功能来实现和扩展 SOA 的核心定义。
因此 ESB 模式使请求者不用了解服务提供者的物理实现——从应用程序开发人员和部署人员的角度来看均是如此。总线负责将请求交付给提供所需功能和 QoS 的服务提供者。提供者接收他们要响应的请求，而不知道消息的来源。ESB 本身对使用它的服务请求者和提供者均不可见。应用程序逻辑可以使用各种编程模型和技术调用或交付服务，而无需考虑是直接连接还是通过 ESB 传递的。连接到 ESB 是部署决策；应用程序源代码不会受到影响。
2.4.3 ESB的功能
ESB 支持许多交互类型，包括单向、请求/响应、异步、同步和发布/订阅。它还支持复杂事件处理（在复杂事件处理中，可能会观测到一系列事件），以产生一个事件作为该系列中的关系的结果。
下图对基本 ESB 模式进行了简单描述。
消息流过将各个通信参与方相互连接在一起的总线,某些参与方会调用其他参与方提供的服务；而其他参与方则会向感兴趣的使用者发布信息。端点与 ESB 交互的位置称为服务交互点 (SIP)。例如，SIP 可以是 Web 服务端点、消息队列或 RMI 远程对象的代理。服务注册表将捕获描述以下内容的元数据：SIP 的要求和功能（例如，提供或需要的接口）、它们希望与其他 SIP 的交互方式（例如，同步或异步，通过 HTTP 或 JMS）、它们的 QoS 要求（例如，首选的安全、可靠交互）以及支持与其他 SIP 交互的其他信息（例如，语义注释）。
将总线插入参与方之间，提供了将它们的交互通过称为”中介”的构造进行协调的机会。中介对请求者和提供者之间动态传递的消息进行操作。对于复杂的交互，可以按顺序将中介连在一起。中介模式部分讨论了实现这些虚拟化、QoS 和管理概念的常用中介模式。
总的来说，ESB的主要功能是：
ESB提供了服务位置和标识的基础功能：参与方不需要知道其他参与方的位置或标识。例如，请求者不需要知道请求是否可以由某个提供者提供服务。您可以随意添加或删除服务提供者，而不会带来任何干扰。这是IT系统实现灵活的服务框架的基础。
交互协议的功能：参与方不需要采用相同的通信协议或交互方式。表达为 SOAP/HTTP 的请求可能由包括 Java 远程方法调用 (RMI)、EJB等的提供者提供服务。
独立的接口处理：请求者和提供者不需要就公共接口达成协议。ESB 可以通过将请求消息转换为提供者所期望的格式来处理此类差异。
交互的服务质量 (QoS)：参与方声明其 QoS 要求，包括性能和可靠性、请求的授权、消息内容的加密/解密、服务交互的自动审核以及如何对请求进行路由（如根据工作负载分布标准将请求路由到可用的实现）。描述请求者和提供者的 QoS 要求和功能的策略可以由服务自己实现或者由进行不匹配补偿的 ESB 实现。因此 ESB 模式使请求者不用了解服务提供者的物理实现——从应用程序开发人员和部署人员的角度来看均是如此。总线负责将请求交付给提供所需功能和 QoS 的服务提供者。提供者接收他们要响应的请求，而不知道消息的来源。
保证不同应用系统之间的高度内聚，同时又保持各个应用系统的相对独立性，使得各个系统之间存在着松散的藕合关系。
保证在一个异构的环境中实现信息稳定、可靠的传输，屏蔽掉用户实际中的硬件层、操作系统层、网络层等相对复杂、烦琐的接口，最大限度地提高用户应用的可移植性、可扩充性和可靠性。
可以将复杂的网状结构变为星型结构，大大简化系统配置；它为各种应用提供一个统一接口，从而大大减少系统间接口的个数；同时，它可以作为一个数据中心，提供各种数据处理服务
提供了消息处理、格式转换和消息路由等功能，用于实现系统扩展性和高可靠性。
2.4.4 ESB的实现模式
从 ESB 的角度来看，所有的服务交互端点都是类似的，因为它们都发送或处理请求/事件；它们都要求特定的 QoS；它们可能都需要交互协助。ESB 模式允许集成开发人员以与处理新业务逻辑、流程编排组件或外部 Web 服务同样（面向服务）的方式对待与用户交互的请求者或提供者。
用于构建基于 ESB 的解决方案的模式大致分为以下几类：
交互模式：允许服务交互点将消息发送到总线或从总线接收消息。
中介模式：允许对消息交换进行操作。
组合模式：综合交互模式和中介模式进行更复杂处理。
部署模式：支持将解决方案部署到联合基础设施中。
2.5 应用系统整合的国内外现状
IDC的调查报告指出：”应用整合市场全球营业收入已经从2000年的50亿美元上升到2006年的240亿美元，这意味着综合年增长率超过了30%。与此相对应，整个IT服务产业的同期综合年增长率预计只有11%。”IDC还报道，北美和西欧等国家产生90%的应用整合服务需求，而日本和拉美将驱动剩下的需求。因此，他们认为：应用整合仍是是最近几年内IT行业中增长最快的部分。其实，IT系统的整合是一个全球性问题，另据有关机构统计，大型企业每年IT预算的40%投给了整合和集成平台，整合和集成还被全球33%的CIO评为最重要的问题，超过90%的CIO认为它是非常重要的问题。
应用整合的前提是企业已经拥有了较为完善但又相互独立的应用信息系统。经过十几年的努力，我国企业信息化已经得到了很大的发展。随着技术的进步以及Internet和电子商务应用的不断深入，企业对信息化应用的要求也在不断提高。同时，为了适应发展变化的形势，企业应用系统也面临着升级的压力。因此，企业面临着两种选择：第一，完全放弃已有的封闭系统，采用全新的开放技术或产品来开发企业的全部应用；第二，维持已有系统的正常运转，采用整合技术将不同的系统集成起来。如果是稍大型的企业应用，完全更换是不现实的。因此绝大多数人倾向于应用整合。
中国应用整合应用行业分布
企业应用整合不仅包括企业内部应用系统的集成，还包括企业与企业间的集成。从集成层面上来讲包括点对点集成、平台集成、数据集成、流程集成以及界面的集成。在电信行业里，去年某省移动成功实施了EAI项目，网通也较早实施了EAI；在金融领域中，某大型商业银行的某省分行应用EAI框架，在金融领域率先完成了EAI项目，将之应用在国际结算业务的单证影像系统中；其他大型商业银行也逐步或者已经用EAI技术构建自身IT架构的信息总线。EAI，如今似乎已成为金融、保险、电信、烟草、保险、石油、电力、航空、汽车等领域愈来愈
以下文章点击率最高
Loading…