中文繁体 
首页  |  走进易维  |  新闻中心  |  产品中心  |  技术论坛  |  成功案例  |  合作联盟  |  站点地图 销售热线:51292209-808
在线客服
网站客服
首页 >> 新闻中心 >> 公司新闻


易维ESB普及系列之ESB基础知识
 
来源: csdn    作者:王鑫磊

1.1  背景

    随着计算机与网络技术的不断发展,以及近几年信息化系统建设的不断发展,很多的单位(行政事业单位以及企业)都拥有了不止一套的系统。与此同时,业务规则的不断变化,使得越来越多的单位在信息化建设的过程中,不得不加强自己业务的灵活性,同时简化其基础架构,以更好的满足其业务目标。
随着单位系统建设的越来越多 ,各个系统间数据、业务规则、业务流程的整合成为了最终用户非常关心的问题。如何能够通过整合已有系统,使各个系统的综合数据能够成为决策者的决策依据;如何通过系统整合,建设更加完整的、合理的业务流程;如何能够通过系统整合降低工作人员的工作量,提高工作效率,以达到降低成本以及提高工作效率的目的。
    正式因为存在以上种种的需求,人们开始希望能有一种比较好的解决方案,以从业务和架构上满足需求。
ESB的出现令人为之一亮,其为解决以上种种问题,提供了一种完整的设计与实施规范。其以总线为基础,定义了各种功能组件以及一系列的技术规范,从业务角度和系统架构的角度上满足了大多数的需求。

1.2  ESB的特点及作用

     ESB是一种在松散耦合的服务和应用之间进行集成的标准方式,是在SOA架构中实现服务间智能化集成与管理的中介(本文不准备在SOA上着墨过多,虽然这是当前很火的一个名词)。ESB是逻辑上与SOA 所遵循的基本原则保持一致的服务集成基础架构,它提供了服务管理的方法和在分布式异构环境中进行服务交互的功能。同时,其也提供了服务的监控、统计、服务的发现等功能。
     ESB系统中将集成的对象统一到服务,消息在应用服务之间传递时格式是标准的,这使得直接面向消息的处理方式成为可能。ESB能够在底层支持现有的各种通信协议,这样使得开发人员对消息的处理就可以完全不必考虑底层的传输协议,可以将所有的注意力都集中到消息内容的处理上来。使得在ESB中,对消息的处理就会成为ESB的核心,因为通过消息处理来集成服务是最简单可行的方式。这也是ESB中总线(Bus)功能的体现。
其实,总线的概念并不新鲜,传统的EAI系统中,也曾经提出过信息总线的概念,通过某种中间件平台,如CORBA来连接企业信息孤岛,但是,ESB的概念不仅仅是提供消息交互的通道,更重要的是提供服务的智能化集成基础架构。
    事件驱动成为ESB的重要特征。通常服务之间传递的消息有两种形式,一种是调用(Call),即请求/回应方式,这是常见的同步模式。还有一种我们称之为单路消息(One-way),它的目的往往是触发异步的事件,发送者不需要马上得到回复。考虑到有些应用服务是长时间运行的,因此,这种异步服务之间的消息交互也是ESB必须支持的。
    除了上面一段中讲到的,ESB的很多功能都可以利用这种机制来实现,例如,SOA中服务的性能监控等基础架构功能,需要通过ESB来提供数据,当服务的请求通过ESB中转的时候,ESB很容易通过事件驱动机制向SOA的基础架构服务传递信息。

1.3  ESB与SOA

     可以这样说,ESB是特定环境下(SOA架构中)实现EAI的首选方法。首先,在ESB架构中,被集成的系统被明确的定义为服务,并且这些服务都是符合一定标准的,而不是EAI系统中所集成的各种各样的组件。这就极大的简化了在集成异构系统上的可操作性。因为不管是怎样的异构实现,只要其是SOA中的服务即可以,因为SOA中的服务都是遵循一定标准的。
    其次ESB强调消息处理在应用系统集成中的作用。这里的消息是指不同应用系统中,对象与对象之间的沟通。而以往传统的EAI系统,在实施的过程中,最大的问题就是各个不同的系统都有自己的消息格式(方言)。而使用ESB,可以使用一种标准的方式对系统内的所有消息进行转换。
    经过几年的发展,ESB以及SOA领域出现了很多的技术规范,这些技术规范的出现以及在实际中的应用,也大大促进了ESB技术的发展,其也变的越来越成熟。

1.4  ESB的功能模型

    任何一种技术架构,都有其基本的功能模型,都应该详细的描述出使用该技术架构,可以完成哪些功能,会给我的产品带来哪些架构上的调整,会给我的业务带来什么样的敏捷性。关于ESB的讨论,在各大社区都讨论的很热烈,本部分将总结给出ESB功能模型。
通信
服务交互
            路由
            寻址
            通信技术、协议和标准(JMS、HTTP、TCP 和 HTTPS等)
            发布/订阅 
            同步和异步消息传递
            服务接口定义(例如 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 的许多关键决策都涉及到成熟的专有技术和不成熟的开放标准之间的权衡。
   在本系列文章中,我们不打算详细讨论上面的每一个功能类别。相反,我们将在接下来的章节张,集中讨论一个ESB应该满足的最低功能需求,即将讨论的这些功能,也是实施国内EAI项目所必须的功能。

1.5  ESB的最低功能要求

    和许多技术架构一样,讨论ESB也需要从系统级的角度来考虑。结合东方易维在EAI项目中的实施经验,以及一些技术规范,可以将ESB的最低功能需求描述为TRANS:其详细说明如下:
           Transforms 转换消息格式,针对已注册的服务提供者的需求将消息从一种格式转换到另一种格式。也就是说,服务提供着暴露给服务消费者的“接口“形式,以及服务提供者与服务消费者质监交互的数据格式,都会转换为一种标准的形式,服务消费者和服务提供者都只针对标准格式的消息进行处理即可。
           Routes 路由消息,将消息传输到已注册的服务,并保证传输的服务质量以及服务层的特性。不论是基于HTTP、HTTPS、SSL、TCP通信,以及与Java、C#,C++、.NET等等系统通信,都应该能够准确无误的保证消息的路由。
           Augments扩展信息,在传输的内容中添加额外信息,比如关于消息请求者的元数据。在消息中添加新的通信协议内容以满足服务提供者的需求
           Notifies通知消息监听者的特定消息请求
           Secures 安全传输,对于传输的消息增加消息认证、授权、不可否认性、机密性,保证消息在传输过程中不被篡改等等。
    其实讨论ESB的最低需求,项目实践是一部分,另外也可以从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 是开放、与实现无关的服务通信和连接模型。
     当然,ESB的这些最低功能需求,只是完成了一些基本功能(听起来好像是真理),这些 SOAP/HTTP 和 WSDL 的基本应用只是点到点(point-to-point)的集成,并不能实现一些 ESB 需要的关键功能,如: 用于控制服务寻址和命名的管理功能。服务名称通过每个适配器单独进行控制的,服务路由控制则分散在由服务客户端调用的地址、HTTP 基础架构和分配给适配器的服务名称之间。
    虽然上面讲到的这中功能需求依赖于实现细节,但是它往往并不能使服务实现的替代变得简单;服务请求者代码(也可能是开发工具生成的)通常通过特定地址的特定协议直接绑定到具体的服务提供者实现。如果想要用另一个服务实现来替代原来的服务实现,就需要修改应用程序代码并重新部署这些代码。
    当然,在许多甚至是大多数情形中往往需要其他的功能,并且这种需要变得越来越常见。特别地,不管是现在还是以后,下面的需求类型可能会导致更复杂高级的技术的使用:
           服务质量和服务级别功能。
           高级 SOA 概念,例如服务编排、目录、转换等等。
           按需操作环境需求,比如管理与自治功能以及基础架构智能功能。
           跨越具有不同所有权的多个网络、多个协议以及多个域的真正意义上的异步操作。

1.6  总结

    ESB毕竟是一个系统级的架构,并不是短短几千字就能够可以描述的。本文仅仅用非常概括的语言,讲述了ESB产生的背景,特点、作用以及其基本的功能要求。如果想要开发ESB的产品,或者进行系统实施,这些内容肯定是不够的。如果您有什么技术或者项目实施中的问题,可以联系我们:
010-51292209-823
 

 

 

 


打印本页 】【  发送给朋友 】【  评论 】【 关闭本页
    北京东方易维软件有限公司©版权所有 地址:北京海淀区上地三街9号嘉华大厦C座303室      咨询热线:62971750   51292209-820/815/808  京ICP备07009996
Produced By cms内容管理系统publishdate:2008/09/24 12:02:20