SOA和ESB的关系

SOA定义了一种体系结构
参考
来自:理解SOA体系结构中ESB场景和解决方案
SOA 适用原则:

  • 利用显式的与实现无关的接口来定义服务 – 达到异构环境的交互
  • 利用强调位置透明性和可互操作性的通信协议
  • 封装可重用业务功能的服务的定义


为了实现 SOA,应用程序和基础架构都必须支持 SOA 原则。启用 SOA 应用程序涉及到创建服务接口,服务接口可以直接也可以间接地通过使用适配器用于现有的或新的功能。从最基本的级别来看,启用该基础架构涉及到规划功能来将服务请求路由和传递给正确的服务提供者。然而,基础架构支持在不影响服务的客户端的情况下由另一个 服务实现替代原有的服务实现也是至关重要的。这不仅需要根据 SOA 原则指定服务接口,而且需要基础架构允许客户端代码以独立于所涉及的服务位置和通信协议的方式来调用服务。这样的服务路由和替代是 ESB 的许多功能中的一部分。

ESB 有时被描述为分布式基础架构,这与其他的解决方案形成了对比,比如消息代理技术一般被描述为中心辐射型(hub-and-spoke)。然而,这并不是真正的差别。

毫无疑问,不同的技术对它们所支持的物理部署模式有不同的约束——有些可能适合于非常广泛的分布,以支持在很大的地理范围内进行的集成,而其他的可能更适 合于部署在本地群集中,以支持高可用性和可伸缩性。使物理分布需求与候选技术的功能相匹配是 ESB 设计的一个重要方面。另外的一种能力也是非常重要的,就是以增量方式扩展最初的部署来反映不断变化的需求、集成附加的系统或扩展基础架构的物理范围

最被普遍认同的 ESB 定义的原理:

  • ESB 是一种逻辑体系结构组件,它提供与 SOA 的原则保持一致的集成基础架构。
  • SOA 原则需要使用与实现无关的的接口、强调位置透明性和可互操作性的通信协议、相对粗粒度和封装可重用功能的服务定义。
  • ESB 可以作为分布式的异构基础架构进行实现。
  • ESB 提供了管理服务基础架构的方法和在分布式异构环境中进行操作的功能。

来自:ESB在SOA体系中的功能定位
在SOA体系中,ESB被当作一个集成平台来将企业各种各样的软件资产服务化。这种服务化即将各种各样的私有技术以现代开放,标准的形式暴露为服务供SOA体系中的更高层次(如业务流程管理BPM)使用。

本质上说,SOA需要ESB为服务提供者和消费者之间提供中介服务。ESB作为服务提供者和消费者之间的中介,能够对服务消费者屏蔽提供者位置,协议等技术细节,从而在有多方参与的企业应用集成场景下能够更加灵活并能适应变化的集成服务的调用方与提供方,比如,提供者位置(end point)变化时对服务消费者完全透明。而且,ESB也常常充当服务集成的统一平台,在其上统一多个被集成方的调用协议,通讯方式以及消息语义(统一消息模型),使得其上层(North bound)服务调用者如BPM流程可以以单一且一致的语言与下层(South bound)实现各种各样的会话。
围绕这中介代理这一核心功能,ESB应该具备的具体能力有:
(1)完善的服务组件模型,包括服务组件的编程模型
ESB应该提供定义统一,明确的服务组件模型,所有软件功能都被封装成服务组件。只有这样才能够实现服务之间的松耦合组装。
(2)松耦合链接服务调用者与提供者的组装模型
ESB应该提供独立的服务调用者与提供者的松耦合组装模型。这里“独立”,“松耦合”指服务调用者与提供者的连接关系完全由组装模型定义,对于调用者与提供者的内部实现逻辑完全透明。
为了实现调用者与提供者的具体连接关系对服务实现透明,消息路由,服务提供者寻址(包括分布式服务寻址),以及必要的数据转换,数据填充,同步/异步通讯模式转换等中介功能需要由ESB的组装模型提供而不需要调用者与提供者实现逻辑关心。
(3)支持多种接入方式,通讯协议转换。
包括对服务调用者提供多种调用协议,以及能够连接使用各种私有传统接口的服务提供者

作为SOA体系的支撑平台,ESB将成为整个架构中核心的服务使能者(Service Enabler)。因此需要ESB在提供核心中介服务的基础上,具备下面的扩展功能特性:
(1)安全——ESB需要提供认证,授权,加密等安全功能保证ESB上的服务被安全的调用,以及ESB可以以服务提供者需要的安全机制调用提供者。
(2)与服务注册库的无缝集成——可以有效的使用服务注册库提供的服务管理功能。
(3)简化开发,部署的能力——如提供图形化的开发工具,集中的提供分布式部署能力的部署工具等。
(4)监控与管理——提供必须的ESB运行时监控与管理能力。
(5)高性能,高可靠性——ESB需要是一个高性能服务中介引擎,同时必须提供足够的高可靠性保障机制。

从ESB的发展历史看,ESB并不是天生和SOA密切相关的,他反而更多的是由企业应用集成(Enterprise Application Integration,EAI)的需求发展而来。

从SOA体系的层次结构来看,我们愿意给ESB设定一个相对狭义的功能范畴,即ESB只为SOA上层构件提供透明的,标准的下层功能实体的服务化封装。而将封装好的服务进行业务编排进而实现各种业务集成功能是SOA体系中ESB之上的构件实现的,其中可以是BPM,各个ESB产品的服务编排功能等等。

BPM方式的优势在于:在业务服务已经被封装并能被业务人员理解的前提下,BPM提供业务人员可以理解驾驭的图形化建模手段来编排各种业务服务构成新的标准化的业务流程。BPM的引入可以有效的提升业务人员对IT系统的参与,进而实现业务主导的集成应用快速开发和随需应变。同时,BPM实现目前已经有成熟的标准支持,使用BPM实现的集成功能实现对具体产品的依赖相对较低。因此,BPM是业务层面应用集成的有力支撑技术之一,在有人工介入的长时间流程方面,其更是唯一的选择。但另外一方面,BPM实现的集成应用在运行效率方面则不如另外两种编排方式。

来自:SOA需要ESB吗?
与企业应用集成(EAI)产品一样,ESB也负责转换及发送消息。ESB厂商对自己的产品是否基于标准非常重视,目前大多数使用Java消息服务(JMS)或者某种专有的消息传送协议,目的是为了提供必要的可靠性。

支持者喜欢ESB是因为ESB让他们可以配置服务、管理服务之间的联系。经历了好几年没有ESB的日子后,工资单处理服务市场的巨擘ADP公司最近采用了分布式ESB,因为“很难维护大批一对一的消息传送适配器

Intuit公司集成架构解决方案 部门的首席架构师Martin Moseley说,ESB适用于需要编制的长时间运行流程,譬如订单处理。在这种流程中,各步骤必须按某种次序来进行,而且整个过程都要进行验证。譬如, 在计算运费或者批准使用信用卡之前,订单流程可能需要验证顾客的地址(原因是验证信用卡往往需要地址); 只有完成了所有步骤,才可以发送货物清单。Intuit的订单处理系统就使用这样一种仲裁服务方法。

也有人认为ESB只是改头换面的 EAI而已,他们认为ESB有悖于SOA的开放性。伯顿集团的分析师Anne Thomas Manes认可使用ESB配置服务,甚至把细粒度服务编制成可广泛访问的粗粒度服务,但抨击了总线作为传送所有服务的网关这一概念,尤其当ESB消息的来 回传送带来额外开销时,她更是觉得不能接受。

Comments are closed.