精华内容
下载资源
问答
  • 2021-05-08 17:31:59

    从产品介绍和功能说明、成功案例说明、产品比较、市场占有率等多个方面介绍了IBM与Oracle企业数据总线ESB比较

    1. 产品介绍和功能说明

    1) IBM MB/MQ 产品线

    IBM WebSphere Message Broker/MQ 提供了一个能满足您的应用集成和信息调解需求的解决方案。通过强健的设计、可扩展的架构、优异的性能、便捷的操作,WebSphere Message Broker软件助您轻松满足如下业务需求:

    生成一个先进的企业服务总线(ESB),使您逐步实现企业范围内的面向服务的

    架构(SOA);

    使发生在企业基础架构内所有业务事件具有更快更大的可视化; 连接系统、应用、系统和人员。

    能够给IT基础架构添加组件,同时重用业务需求所涉及的关键应用功能; 扩大基础架构,勿需增加其复杂性;

    保护过去和现在对应用和数据结构的投资; 由此,可以利用下一代的创新——保护、开发、扩展在现有业务应用上的投资。 一个以可靠、值得信赖的消息传递基础架构为基础的企业服务总线平台,可以

    帮助客户有效的利用Web提供商品与服务,实现高效的集成,加快关键业务流程,提高企业所在价值链的生产率。利用WebSphere Message Broker 产品解决方案,用户可以使得企业的业务更容易适应需求的快速变化。 2) Oracle OSB/ODI 产品线

    Oracle Service Bus是业内领先的企业级服务总线,它提供了功能完整、技术统一的基于SOA架构的服务集成平台。

    技术领先 产品成熟度高

    功能完善、技术统一 集成能力强 更可靠的平台 简单的配置化实现

    Oracle Data Integrator(以下简称ODI) 是一个完整的数据集成平台,它可以满足所有数据集成需求 — 从大量、高性能批量数据处理到事件驱动的近实时数据集成流程到支持 SOA 的数据服务。

    支持多种数据源和目标

    设计从数据源到目标数据的映射 流程和计划 监控和调试 元数据管理 增量数据捕获

    更多相关内容
  • 企业服务总线

    2017-07-05 14:58:30
    简介如今似乎每个人都需要使用企业服务总线 (ESB),但关于其实际好处以及这一术语所涉及的各种概念还有诸多困惑。下面这些语句透露出这种不确定性:“求助!老板说我们需要一个 ESB”或者“我究竟为什么需要 ESB?我...

    简介

    如今似乎每个人都需要使用企业服务总线 (ESB),但关于其实际好处以及这一术语所涉及的各种概念还有诸多困惑。下面这些语句透露出这种不确定性:“求助!老板说我们需要一个 ESB”或者“我究竟为什么需要 ESB?我使用 BPEL 或 BPMN 不能实现同样的功能吗?”甚至是“X 语言能满足我们的一切需要。”本文试图用具体示例回答有关该术语的一些最重要的问题,从而阐明被认为是“正确的”ESB 应用领域。

    ESB 的定义到底是什么?是一款产品还是一种架构模式?
    ESB 有何实际用途?
    我需要用 ESB 构建 SOA 平台吗?
    我需要满足什么要求?
    我可以用哪些标准来选择最符合我需求的 ESB?

    定义 ESB

    该术语目前还没有一个公认的定义,很可能是因为缺乏行业标准,然而流程引擎和其他组件却存在 BPEL 和 BPMN 2.0 之类的标准。Gartner 于 2002 年创造了术语“企业服务总线”,分析师 Roy Schulte 进一步引入这个术语来描述当时市场上的一类软件产品。10 年后,关于 EBS 到底是什么或者它应该提供什么依然没有达成共识。根据制造商和来源的不同,有很多不同的定义。其中,ESB 的定义包括:

    “一种集成架构样式,支持提供者和服务用户之间通过由各种点对点连接构成的公共通信总线进行通信”

    “企业用来集成应用程序环境中服务的基础架构。”

    “一种架构模式,使用面向服务支持异构环境之间的互操作性。”(图 1)

    这里写图片描述
    图 1:ESB 架构模式分成这几个主要系统架构
    现在市场上提供的 ESB 在系统架构方面有着本质区别。如上图所示,它们主要基于以下架构:

    扩展的面向消息的中间件 (MOM)

    这些系统对应于 ESB 的原始定义,通常在整个网络中分布多个节点,使用一个 MOM 基础架构支持节点之间可靠的消息传递和事件驱动处理。尽管 ESB 使用专用协议进行通信,但服务端点不需要知道 MOM。可以使用 WSDL 或其他协议公开服务。

    扩展的集成代理

    过去 5 年间,传统的集成代理供应商逐渐加大了对 Web 服务的支持,并将其产品重新定位为 EBS。这些系统与之前的系统相比更符合标准,但与大多数 ESB 相比仍然更倾向于专用。它们还倾向于提供高度集中化的解决方案,所有消息均通过一个中心代理进行传递。

    扩展的应用服务器

    许多 ESB 供应商使用 Java EE 应用服务器作为其 ESB 产品的基础。这些产品在服务创建和组成方面通常比原有集成更强大。尽管它们也支持分布式节点,但它们往往都比较集中。

    基于端点的插件通道

    有几个 ESB 供应商支持极度分布式模型,该模型在服务端点实现服务调节,使用通道插件架构支持异构通信。

    调节代理

    尽管这些产品从技术上来说不能算是 ESB,但是因为提供了一个服务平台,据我们所知,目前已有多家供应商将此类产品列为 ESB。调节代理可以是集中式的或分布式的,支持服务调节。也有相关的产品类别可实现部分 ESB 功能,但是制造商不能将其作为 ESB 正式销售 [REF-1]。

    XML 网关

    XML 网关硬件设备主要支持服务调节,这是 ESB 的主要特性之一。事实上,XML 网关通常支持 ESB 不支持或无法支持的服务调节功能,如转换加速以及 XML 文档加密和解密。但是,XML 网关不提供服务平台,这是一个通常与 ESB 相关联的特性。

    面向消息的中间件 (MOM)

    面向消息的中间件基于消息的异步发送和接收,在应用程序之间提供更松散的耦合。尽管没有定义消息格式,但实际上 XML 已成为首选格式。MOM 产品通常支持通过消息队列以及发布/订阅进行通信。MOM 中通常不提供消息转换,MOM 的应用程序接口相对比较复杂且不够规范。MOM 可以用作通过 EBS 进行可靠消息转发的基础。

    集成代理 (EAI)

    现在,一些传统 EAI 工具开发人员将其产品定位为 EBS。这些产品通常比较复杂并且是专用的,通常基于一个集中星型架构。代理充当中央消息交换器(中央节点),发送者和接收者(远端节点)呈放射状分布。可通过支持所需消息格式的适配器端口连接到代理。

    业务流程管理系统 (BPMS)

    一些 ESB 开发人员将服务编排和自动化业务流程管理(BPEL、BPMN)看作是 ESB 特征,其他人则认为服务总线是一个独立产品,属于 BPMS 类别。尤其是在用流程模型或“编制引擎”类别表达业务方面时,技术集成流程可以表示成一个以不同顺序调用服务的长流程链。

    应用服务器

    许多 ESB 平台都提供一个服务平台来构建和托管服务。在这种情况下,ESB 还是一个应用服务器。许多应用服务器提供容器来操作服务,还提供一个受限功能来处理消息和执行策略。应用服务器适配器支持通过 Java EE Connector Architecture (JCA) 之类的技术集成原有系统。大多数情况下,应用服务器仅支持几个协议,很难精确分离 ESB 和应用服务器。许多开发人员需要一个应用服务器作为其 ESB 基础。

    API 网关

    企业和组织的目标是以一种易于使用的标准化方式、以 API 形式向业务合作伙伴和客户公开部分关键服务的访问。这意味着 API 网关可以解决出现的各种安全性、性能和集成问题。API 网关具备威胁保护功能,可确保服务质量。API 网关不是 ESB,但在功能方面有一定重叠,比如转换和路由。

    一般来说需要注意的是,向外界公开服务时,API 网关是一个需要考虑的工具。如果位于内联网外部,通常是在 DMZ 中。它只管理正在与外部通信的服务子集。

    ESB 用于服务虚拟化,通常管理更大的服务集且位于内联网内部。

    何时使用 ESB?

    有没有确定何时应使用 ESB 实现的最佳实践?需要集成三个或更多的应用程序或服务时,可以考虑使用 ESB。连接两个应用程序时,点对点集成非常简单且更经济划算。如果要从企业无法控制的外部服务提供者处获取服务,也可以考虑使用 ESB。然后,可以使用 ESB 监视外部提供者保证的服务级别协议。可进一步将服务合同调整的影响控制到最小,因为 ESB 对消息进行必要更改的同时将继续提供一个稳定的接口。

    如果要使用多种不同协议(如 HTTP、SOAP 和 FTP)并将它们标准化成一个协议(如 SOAP),ESB 可以执行必要的协议转换。如果始终需要将服务合并成一个架构才能够接收、处理和生成消息,那么使用 ESB 也比较合适。如果需要访问一组预定义的组件和适配器,ESB 也同样适用,这将支持以标准化方式集成各种协议和原有应用程序。如果需要安全、可靠地处理消息,ESB 可以简化两个异构事务性数据源之间事务性消息流的实现。

    如果需要通过总线将大量数据作为大量独立消息进行发送,那么使用 ESB 可能存在一些问题。ESB 绝不应取代传统数据集成,比如 ETC 工具。将数据从一个数据库复制到另一个数据时,使用数据集成可能更高效,因为该操作只会不必要地增加 ESB 的负担。

    如果需要实现长期业务流程,ESB 应支持无状态的消息流。长期运行的业务流程是有状态的,最好使用 BPEL 和/或 BPMN 实现。这些流程通常无法通过 ESB 实现,但可以通过业务流程管理系统 (BPMS) 实现。

    ESB 蓝图

    由于缺乏标准化,ESB 市场相当混乱。很多产品自称是 ESB,但是提供的解决方案却大相径庭,而且基于不同的架构。为了更有效地评估 ESB 产品,我们将分配给 ESB 的各种功能组织成了一个蓝图(图 2)。
    这里写图片描述
    ESB 蓝图不包括“编排”或“流程编排”组件,因为这被视作 BPMS 类别的一部分。它们为长期运行的、有状态的业务流程提供专用的运行时环境,这些流程为此进行了优化,支持 BPMN 或 BPEL 之类的语言。ESB 应该是无状态的,并且应配置为尽可能高效地处理消息。

    操作和管理模块

    该模块中的以下功能组件支持可靠的企业服务总线操作和管理。统计信息与状态 提供服务的 ESB 统计信息,如错误数量、最小和最大响应时间以及处理的消息数。警报 提供一个发送警报消息的机制,可通过各种通道发送,因此也可以集成到现有监视环境中。SLA 规则 是在统计信息与状态 功能组件的信息基础上定义的规则。支持度量和监视 SLA。可以使用警报 组件通知任何 SLA 侵权。

    消息跟踪 可以在 ESB 中轻松跟踪消息,应在需要时激活,以便将相关开销降至最低。消息重新传递 确保在预定义时间后自动重新发送未及时处理的消息。可以配置尝试次数以及它们之间的时间间隔。该组件主要适用于仅持续一段时间的技术错误,如临时网络中断。端点故障切换 可以指定一个备用服务提供者,在主服务提供者不可用时自动调用。

    负载平衡 可以列出一个逻辑服务提供者端点的几个服务端点。它使用冗余服务实现,根据定义的策略交替调用每个请求,可以循环调用,也可根据消息优先级和负载依赖关系进行调用。

    消息限制 可以定义应被发送到服务提供者的服务端点的每单元时间内的最大消息数。它通过缓冲 ESB 队列中超过阈值范围的消息来防止服务提供者在高峰时段重载。消息限制 还支持消息优先级,这样可以确保始终先处理高优先级的消息。记录与报告 支持记录消息,方便以后显示。它还提供功能审计。

    配置管理 支持在操作系统上安全地调整 ESB 配置,同时始终维护配置的完整性。可在操作过程中调整和替换构件和属性。还可以保存变更历史记录,这样 ESB 服务可以随时回滚到早期状态。服务注册表 可以在 ESB 上注册和管理服务。高可用性 确保 ESB 提供的服务是故障安全的,与运行这些服务的服务器的状态无关。

    错误医院 是那些经过多次重新传递尝试仍无法处理的消息的目的地,可以在这里查看、更正(如果需要的话)以及重新处理这些消息。部署 可在 ESB 上自动安装服务。特定于环境的参数(如端点 URI)通常是由该组件重写的。服务使用情况 支持记录服务使用情况并向用户收取费用。

    调节模块

    调节模块包含用于实现 ESB 服务消息流的功能组件。消息路由 支持根据消息的内容将消息其转发至特定服务端点。如果使用的协议或消息格式支持与消息正文无关的消息头区域,转发标准可能源于消息正文或消息头。

    根据消息头进行路由可能是一个极具吸引力的选择,可提高服务性能和可扩展性,因为直接访问消息头比解析来自消息正文的路由信息更高效。这对于大型消息来说尤其重要。

    消息转换 支持从一种消息格式转换为另一种适用于文本和二进制消息的格式以及 XML 格式。此外,还可以从文本(如 CSV 格式)转换为 XML,或者从 XML 转换为文本(如 CSV 格式)。XML 转换使用著名的 XSLT 标准,XSLT 支持对转换进行声明性描述,并且拥有带拖放功能的图形资源以实现创建目的。

    XSLT 转换的主要缺点是,如果处理大型文档,内存使用量过高,这可能会限制解决方案的可扩展性。如果 ESB 提供支持 XML 流转换的选项(比如,通过 XQuery),那就更好了。

    服务调出 可以在 ESB 中访问消息流中的其他服务,比如增强一条消息。服务可能是一个 Web 服务,但 ESB 可以如您所愿地支持直接调用 ESB 中本地安装的程序代码(如 Java 类方法)。可靠的消息传递 支持使用队列或 WS* 标准(如 WS-ReliableMessaging)可靠地传递消息。

    协议转换 意味着无需任何编程工作即可从某个通信协议切换到另一个协议,比如,从 TCP/IP 切换到 HTTP。消息验证 确保消息是有效的。在 XML 中,这意味着消息包含规范定义的 XML 并对应于特定的 XML 模式或 WSDL。不过,ESB 还提供了其他验证方法,如 Schematron 或规则引擎。

    消息交换模式 (MEP) 支持消息交换模式,如同步和异步请求/应答、单向调用以及发布/订阅。结果缓存 可以在缓存中保存服务调用结果,这样返回同样结果的后续调用可从缓存获得应答,无需再次调用服务。如果数据是静态的或者需要零星或少许的改动,此功能尤为适合。可大大减少像访问原有系统这样的开销可能较大的操作。

    事务 支持 ESB 通过消息处理提供事务完整性。ESB 用于支持可靠消息传递 的持久队列通常作为事务数据源,因此可参与异构事务。此外,ESB 还提供了一个分布式事务管理器,可使用两阶段提交协议通过异构数据源协调分布式事务。

    消息重新排序 使属于一个整体但顺序不对的消息流可以重新排序。在并行处理消息的面向消息的解决方案中,消息进入 ESB 的顺序可能会丢失。如果顺序对于服务提供者很重要,消息重新排序 可以合并到消息流中。重新排序器包含一个内部缓冲区,缓冲区对消息进行处理,直至排序完成且可发送。

    直通式消息传递 可以令 ESB 高效转发 ESB 消息。如果要将 ESB 用于服务虚拟化,并且将消息从服务使用者原样转发至服务提供者,这将非常有用。在这种情况下,如果 ESB 不接触消息,只是简单地按原样传递,该功能非常适用。

    安全模块

    该模块使用大量组件支持传输级和消息级安全性。当服务使用者访问 ESB 中的服务时,身份验证 验证其身份,并验证针对服务提供者的 ESB 身份验证。授权 为服务提供了一个授权系统,通常可通过 XACML 对这些服务进行配置,以便分配给用户或角色。

    安全调节 支持交互,通过将一个域的凭证转换成另一个域的相应凭证在安全域之外进行通信。加密/解密 支持消息内容的加密和解密。

    适配器/传输模块

    该模块包括的适配器可通过服务托管模块连接 ESB 提供的服务。假设 ESB 从无到有提供一组适配器,客户或第三方开发人员还可以开发其他适配器以满足具体的用户需求。

    服务托管模块

    该模块支持在 ESB 上直接安装和操作服务,如果 ESB 基于应用服务器,该模块通常是必需的。服务容器 提供一个或多个容器,在其中安装服务和管理生命周期。它提供可访问技术横截面功能(如事务和安全性)的服务。

    组件模型 提供了一个抽象的组件模型(如 Java EJB、Java Spring Framework 或 Microsoft COM+),在此基础上创建服务。

    ESB 的实际应用场景

    图 3 所示的符号用于以图形化方式描述各种场景,无需参考产品或工具。这些符号来自于 [1],根据 ESB 功能不断添加。
    这里写图片描述
    图 3:ESB 符号
    场景 1 — 服务虚拟化
    服务使用者往往更喜欢硬连接实际服务端点,特别是在 BPEL 流程中,因为使用提供的工具可轻松执行。然而,在运行时对服务器地址的改动绝对不能产生需要在服务客户端进行重新部署的改动。这个问题的一个非常好的解决方案是使用 ESB 虚拟化端点。图 4 展示了这个场景,服务提供者提供的 Web 服务接口不再由服使用者直接使用,而是通过 ESB 来使用。ESB 可以完全按照为潜在的服务使用者提供接口那样提供接口。
    这里写图片描述
    图 4:使用额外的监视拦截器虚拟化服务
    在 ESB 配置过程中可以轻松实现需要对端点地址进行的任何改动,因此服务使用者可以像以前一样继续运行。然而,ESB 需要能够合并到现有消息流中。服务虚拟化还支持使用扩展到服务统计信息的 ESB 监视功能,以便检查 SLA 合规性,如果不合规的话,则配置适当的操作。如果服务提供者对服务合同进行了更改但不想影响服务使用者,可以执行服务虚拟化。在这种情况下,对交换的消息进行简单的转换即可解决此问题。

    场景 2 — 服务支持
    当纳入具有功能接口的服务时,通常会出现的情况是,服务使用者和服务提供者在协议级别使用不同的语言。图 5 介绍了两个服务提供者,从技术上来说它们提供的是相同的服务,一个提供的是 SQL 接口,另一个提供的是 FTP 接口。可以将企业服务总线用作协议转换器以保持接口不变,因为它提供的方法可确保使用定义的接口。
    这里写图片描述
    图 5:服务支持
    与场景 1 类似,如果通信协议将来发生变化,ESB 可确保服务使用者或服务提供者端无需后续更改。

    场景 3 — 安全的消息处理
    ESB 还能支持传统集成场景,主要目的是将消息从一个系统转发到另一个系统。在图 6 所示的场景中,ESB 使用来自外部队列的消息,使用对一个 Web 服务的服务调出来丰富这些消息,然后通过数据库适配器将消息发送到目标系统。
    这里写图片描述
    图 6:安全的消息处理
    ESB 中的处理是事务性的,意味着将消息流配置为像其他参与者一样参与分布式 XA 事务。使用队列中的消息时将启动事务,事务还包含数据库适配器执行的数据库操作。如果消息流成功完成,紧接着会提交分布式事务。

    场景 4 — 服务版本控制
    服务往往随着时间而改变,通常需要引入一个新的不兼容版本。在这些情况下,可以使用 ESB 执行从“旧”接口到“新”接口的转换。在图 7 所示的场景中,服务提供者引入了服务的 2.0 版本,服务使用者 B 立即安装了该版本。服务使用者 A 一直使用接口 1.0,不想切换到 2.0 版本,因为不会给业务带来任何附加值。然而,服务提供者不想让这两个版本并行运行。同时运行两个接口可能比较困难,甚至在技术上不可行,而且会导致不必要的资源消耗。
    这里写图片描述
    图 7:服务版本控制
    如果 ESB 通过直通式传递(类似于场景 1)直接提供 2.0 版本,情况可能比较简单。同时,在适应现有消息流的同时必须提供接口 1.0 版本,这样将不再从服务提供者处调用 1.0 版本。相反,消息是从 1.0 版本转换到 2.0,然后发送给新服务。这种转换可能相对比较复杂,具体取决于两个版本之间的差异有多大。为了提供调用 2.0 版本所需的所有信息,可能需要额外丰富 1.0 版本消息。

    需要维护 ESB 中的转换和接口 1.0,直至没有服务使用者使用旧接口。之所以在 ESB 中执行这种转换而不是在服务提供者中从版本 1.0 映射到 2.0,具体原因如下:

    映射是技术问题,与业务相关问题无关
    不会影响外部服务提供者。
    ESB 使旧接口的使用透明。
    当所有服务使用者都改用接口 2.0 后,无需更改服务提供者。
    总结
    ESB 是一个中间件解决方案,使用面向服务的模型来促进和支持异构环境之间的互操作性。没有规范准确定义了什么是 ESB 或者它应该提供什么功能。虽然 ESB 主要与“调节”和“集成”这类概念相关,但它还适合作为一个平台以类似于应用服务器的方式提供服务。ESB 代表被称作“集成”和“应用服务器”的产品类别的整合。

    ESB 的一个关键特性是服务虚拟化。本文提出的 ESB 蓝图提供了各种功能的有序排列,构成了评估 ESB 产品的基础。

    要点
    企业服务总线应被视为一个架构样式或模式,而不是一款产品。
    ESB 没有定义或规范,因此也没有标准。
    ESB 可帮助实现系统间的松散耦合。
    ESB 上的服务是无状态的。长期运行的流程不属于 ESB,但是在使用 BPEL 和 BPMN 之类语言的 BPM 系统中受支持。
    “误用”ESB 来执行批处理时应小心谨慎,因为可能会对性能产生负面影响。

    转自
    http://www.oracle.com/technetwork/cn/articles/soa/ind-soa-esb-1967705-zhs.html

    展开全文
  • 针对目前行业信息化集成项目建设中存在接口具有多样性、数据规范不一致的问题,对企业服务总线技术进行了研究,分析了企业应用集成、面向服务的体系结构及企业服务总线的优缺点,介绍了企业服务总线的工作流程及其关键...
  • 企业服务总线(ESB) 定义 MQ(Message Queue)消息队列。 把要传输的数据放在队列中,通过消息传递队列发送和接收消息数据,实现数据的传递。 ESB(Enterprise Service Bus) 是一个集中式的服务...

    前段时间因需要,回顾了下MQ。将部分整理内容分享备忘:

     消息队列(MQ)企业服务总线(ESB)
    定义MQ(Message Queue)消息队列。
    把要传输的数据放在队列中,通过消息传递队列发送和接收消息数据,实现数据的传递。
    ESB(Enterprise Service Bus)
    是一个集中式的服务总线,它是传统消息中间件技术与XML、Web服务等技术结合的产物。通过ESB,可以实现集成业务处理,监控系统间消息流动,管理系统间交互的业务服务。
    >>传统消息中间件指MQ
    解决的问题传递数据集成(企业应用整合)
    常见产品ActiveMQ,RabbitMQ,ZeroMQ,Kafka,MetaMQ,RocketMQOSB,WebSphere,BizTalk,Orion
    产品形态通常是:运行服务 + 监控API(提供监控数据)通常是:设计器、运行服务、监控管理平台
    消息收发协议相对固定的几种
    MQTT、XMPP、Stomp、AMQP、OpenWire
    支持得比较广泛(能适配外部各种主流系统所使用的协议)
    消息传递模式通常支持两种:点对点模式、发布订阅模式能支持更多(消息的整个路由是可编排的,更为灵活)
    消息路由控制弱。具备基本的消息筛选,但不支持复杂控制。强。支持自定义的编排。
    消息处理不支持(收到是什么消息,发出的数据还是它)。支持。如:格式转换(将hl7转为xml/内容修改)、拆分(收一个消息拆分为多个发出)、聚合(收多个消息合并为一个)、...
    特性支持情况弱,通常交给外部系统自己实现(视具体MQ产品)。
    比如,对消息重复处理的限制机制等,提供了基本保障(一些特殊和异常情况是没有处理的),往往需要外部系统自行扩展实现。
    内置会支持和考虑很多特性,以orion为例,内置支持:重复调用限制机制、熔断机制、隔离机制、消息错误箱/垃圾箱机制等。
    初步小结1、ESB包含MQ
    2、ESB提供了更多的用于系统集成的功能,包括:消息的路由和处理,支持更多通讯协议(从各种不同系统收发消息)。
    3、ESB内置了更多的特性,以支撑对消息的路由控制(重复调用限制、熔断、隔离等)。

     

    分享请注明出处
    本文链接:https://blog.csdn.net/debug_fan/article/details/104993637

    展开全文
  • 在诸多的专题研讨会上,企业架构师们探讨着许多问题,比如面向服务架构(SOA)的相关问题、如何让企业服务总线(ESB)作为构建企业SOA框架的主干问题等。其中,许多人质疑ESB的意义所在,从中也体现出当前IT群体普遍...

    在诸多的专题研讨会上,企业架构师们探讨着许多问题,比如面向服务架构(SOA)的相关问题、如何让企业服务总线(ESB)作为构建企业SOA框架的主干问题等。其中,许多人质疑ESB的意义所在,从中也体现出当前IT群体普遍对ESB存在一定的误解。下面便是笔者总结人们最关心的10个ESB的问题。


    误区1:ESB只是EAI换了个名字

    许多IT架构团体在搭建SOA的同时仍然受到一个问题的困扰:“ESB和EAI到底有什么不同?”ESB是一种用于构建企业SOA的基础设施,它比传统的EAI代理的用途更为广泛。根据福里斯特研究所的报告,ESB可以提高连通性、增加灵活性促进发展、并加强对重要资源的控制,从而帮助企业实现SOA的价值。

    ESB不仅可以用于处理以往依靠EAI工具进行的集成项目,还可以用于建立企业间的B2B关系。

    ESB可以提供EAI所能提供的功能,但其基本架构是不同的:这个架构促进了企业从传统的集成方式转向协调服务交互。EAI通常是采用星形架构以独立应用的形式实现的。

    ESB提供的功能与EAI代理相同--连通器、应用适配器、根据规则进行的消息路由和数据转换引擎--但是这些功能是面向SOA的,它们分布于整个服务总线并寄存在可独立部署的服务容器中。这使我们可以有选择性地部署所需的集成代理功能,不会产生冗余。ESB容器模型的这种分布式特性使以事件驱动服务的形式按需添加到SOA中的集成组件具有独立的可扩展性。

    为了使集成代理能够从真正意义上支持SOA并成为真正意义上的ESB,我们需要把它的基本功能分散到组成部件中,然后才能将各个组件独立地部署到总线中,并使它们协调运作。

    我们来看一个基于XSLT的转换引擎。该引擎可以根据XSLT模式表把一种XML文件转换为另一种XML格式。我可以负责任地告诉你没有什么比分析和处理XML更消耗计算资源的了。如果两个经常互通的应用之间存在XSLT转换,那么这个转换很可能会成为性能与扩展的瓶颈。如果你采用的是独立式的星形集成代理方式,那么为了解决这个瓶颈问题并扩大部署你必须把这个集成代理安装到一个处理能力强大的机器上,或者是安装到多台机器上--而这仅仅是为了解决这个转换的问题。同时,其它的集成代理功能,比如路由规则的处理还在和转换处理抢夺计算资源。

    与集成代理的星型架构不同,ESB的基础核心提供了一种分布式的服务架构。这种架构是面向集成的,它可以对集成代理中的各种功能比如消息路由、数据转换、和应用适配器等进行选择性的按需部署,而这些独立的集成服务正是构成SOA的一部分。

    可以把XSLT转换以服务的形式部署到ESB服务容器中,然后把这个容器的多个实例根据负载平衡分布到许多机器中。如果这个ESB容器是跨平台实现的,那么你还可以灵活地选择转换服务所跨越的平台--Linux主机、Solaris主机、Windows主机等等。如果你不喜欢这种简单的架构,还可以这样考虑:那些对ESB的定义和产品提出非难的供应商同时也为我们提供了方便:你可以部署任意多的轻量级ESB服务容器而无需支付任何额外费用。

    ESB提供的这种集成服务可以与其它服务结合融进基于SOA的处理流程,从而扩大业务范围。ESB中的分布式服务可以结合基于路线(itinerary-based)的路由选择(见误区#7)以实现自定向、面向消息的服务交互,从而使ESB的各个部件能够独立地进行工作,不会对某个集中式的路由引擎产生依赖。

    误区2:微软正在利用"Indigo"创建ESB

    微软的Indigo结合了Messaging Queuing、Component Object Model COM+、.NET、和Web服务。他们在做的是具有Web服务扩展功能的消息总线。这和企业服务总线是有很大不同的。消息总线暴露了低层消息技术的详细内容,它需要编写代码来定义应用与服务之间的关系。而ESB的意义在于配置而不是编码,因此也不需要手工编写内部互通的的各应用之间的关系。ESB有利于提高以事件驱动的形式暴露于总线上的应用之间的松耦合特性。好消息是Indigo上创建的应用至少也是基于消息的,因此通过ESB进行集成也会比较简单。

    也就是说,BizTalk Server中的某些东西与Indigo组合后可能会比较像ESB。不过还有很重要的一点,即BizTalk是星型集成代理,因此它同样受到前面在ESB与EAI中所提到的所有不利方面的影响。你无法在不增加任何费用的前提下把XML转换引擎从BizTalk Server中分离出来并作为负载平衡的服务运行在多台机器上(详见前面EAI与ESB的讨论)。

    误区3:WS-Rliability和WS-Reliable Messaging等WS-*标准终将解除对ESB的需求

    在设计ESB的时候就应该考虑使其能根据这些不断发展并逐渐获得商业应用价值的标准做出调整。WS-*标准的发展使应用终端能更好地通过ESB进行交互。

    由于各种平行进行的工作,WS-*标准作为不断发展的Web服务标准的一部分自然也存在许多不确定因素。即使这些标准最终发展健全并且得到了广泛的应用,它们仍然需要一个能够为其提供支持的平台。ESB可以在与底层协作标准无关的层面上为企业提供一个构建、编排和管理SOA的统一模型。

    WS-Reliability标准的实施需要有可靠的消息持久性和存储转发处理器的支持。企业消息层是ESB的基础组件,它通过消息持久性、存储转发、消息验证等消息协议和与外部XA-compliant事务处理器的接口保证数据传输的服务质量。ESB的部署还可能使复杂网络布局的消息路由透明化,并通过容错的消息服务器架构实现消息设施的持续可用性。在当前高压的企业环境下,要实现所有这些设计还需要许多人的多年劳动。

    也就是说,现在部署具有专有消息层的ESB时还应该同时采用一种或更多的WS-Rel*作为补充协议以为将来作准备。但是,这并不是一种可以解决所有问题的方案,我们仍然需要对多种消息和协议的组合提供支持。

    误区4:模式还是产品?

    企业服务总线(ESB)这个术语实际上并不属于产品的范畴;它只是一个可以实现应用服务器与集成中间件的耦合关系的抽象概念。

    ESB是一个用于构建企业SOA的高度分布化的主干总线。企业要构建面向服务的架构,而ESB则是这个架构的基础总线。由于ESB的产生对集成市场带来不少冲击,某些集成供应商便放出烟雾弹称ESB只是一个可以用于组合当前的中间件与应用服务设施的抽象的模式。实际上,ESB确确实实地是一种硬件设施,而且几年前就已经可以从各供应商处购买到了。目前为止,制造业、金融业、电信和零售等各产业之间已经部署了许多ESB。

    ESB的定义应该包含以下基本要素:

    · 一个分布式的服务架构,包括一个用于寄存集成组件作为远程服务的轻量级容器模型

    · 一个可以为各应用与服务提供可靠的消息传输的企业消息主干总线

    · XML Data转换

    · 服务编排和根据消息内容进行处理的智能路由

    · 一个灵活的安全架构

    · 可以配置、部署、监控以及管理远程服务的管理设施

    由于ESB的分布式服务架构,我们可以通过全球任何位置上的虚拟终端访问服务。这个分布式服务架构是建立在一个由可以通过远程服务进行配置、部署、管理和监控的轻量级服务容器构成的互联系统上的。这些服务容器通过一个实现了可扩展性、持续可用性、低延时处理、安全一致和服务质量(QoS)的标准化的消息主干总线组合到一起。

    误区5:ESB与J2EE应用服务产品之间存在竞争

    ESB与J2EE app服务器是高度互补性质的。通过使用JMS、MDB、JCA或Web服务等标准接口连接到ESB,即使是在非J2EE环境下J2EE app服务器也可以与其它应用服务器很好地集成。

    大部分ESB用户同时也是应用服务器技术的用户。这些用户利用应用服务器和ESB作为他们的集成环境的最优组件--使用应用服务器寄存业务逻辑并以门户的形式提供网站服务,同时使用ESB来集成应用服务器与企业中的各种后端应用和数据源。

    误区6:只要使用Web service call即可把门户网站连接到后端系统上

    虽然理论上Web服务调用可以把门户连接到后端目标系统上,可是这种方式无法扩展到多个后端系统上。通过使用ESB,可以让门户服务器通过唯一的接口连接到总线,而总线则成为门户服务器可能调用到的所有后端系统上的各种连接属性、协议、安全和数据格式的媒介。

    使用了ESB作为门户服务器和可能与门户服务器产生交互的各种后端应用的中间层相当于为ESB用户提供了一个更为灵活、扩展性能更好的SOA,因此当项目更成功、根据业务需求需要发生变化时,他们也能自由地处理各种各样的集成作业。

    误区7:当BPEL获得广泛应用的时候ESB就会退出舞台

    ESB可以支持多种事件驱动的服务调用的编排方式。BPEL只是其中的一种。ESB还有基于路线的路由,可以为消息指定一系列的路由指令。消息因被服务调用而经过总线的时候,这些代表业务过程定义的路由指令始终是和消息绑定的。然后由远程ESB服务容器决定将消息发送到哪里。

    这个过程中没有集中的路由规则引擎,因此基于路线的路由也是ESB分布式的特性一大体现。像星型EAI代理所用的这种集中的消息路由规则引擎则可能会成为系统的瓶颈,并且如果这一部分出现故障将导致整个系统的瘫痪。仅仅使用消息路线、消息和过程定义其实就足够了,这样还能允许ESB的各个不同部分独立地进行工作。

    消息路线可以有效地处理那些包含有限步骤并且无需很长的处理时间即可结束的无状态随机过程。甘特称这种过程定义为"微流(microflows)"。根据基于内容的路由服务的使用情况,路线中可能会产生简单的分支。

    如果需要更复杂的过程定义,还可以在ESB中加入一个流程编排引擎作为补充服务。这个过程编排可以支持可能存在很长时间的状态过程。它还可以支持带分支的平行执行路径,并根据联接条件或转换条件支持消息流执行路径的融合。这样的过程可以支持BPEL和其它的过程定义语法,比如ebXML BPSS。还可以将成熟的过程编排与非状态的基于路线的路由结合,建立一个可以解决复杂的集成问题的SOA。

    误区8:ESB技术和其它技术一样正在经历一个典型的技术发展曲线:凭空产生,迅速发展,然后马上进入“幻灭”阶段。

    ESB这个概念是制造、电子商务、电信、金融服务和零售等多个产业的先导者共同努力产生的结果。其产生是由于需求,是以当时已经比较成功的分布式计算模型和EAI技术为基础建立的新方式。这些IT先导者的最终结果是一致的:"我们的分布式消息基础结构是成功的,所以我们希望能以此为基础建立一个用于集成的基于标准的事件驱动的SOA。我们希望它能包含Web服务、XML数据转换、基于内容的路由和面向分布式过程的服务调用模型。"因此,ESB中所体现的这些概念都是成熟的,是有健全的基础的。也正因为如此,ESB技术正在发挥着它应有的作用。现在已经有数百条ESB在各行业服役,比如供应链、物流自动化、金融服务中的全球直通处理、电信的实时服务、以及零售业的远程店面管理。

    误区9:ESB只是一个推动器,但它并没有提供成熟的工具,比如设计业务流用的图形编辑器。

    现在有一种新的IDE(或Gartner集团所称的ISE)可以让你设计、配置、测试、调试你在建立应用ESB的SOA时开发的集成服务。其使用的是图形界面,集成设计师可以用UML表示法来描述过程定义。你还可以使用ISE图形化地创建不同数据之间的转换方式并建立和调试XSLT模式表。

    误区10:可以使用EJB容器实现ESB容器

    ESB结构中的一个关键组成部分就是一个高度分布式的、轻量级的服务容器。这个服务容器能以事件驱动服务的形式寄存集成组件,比如一个在XML消息中添加XPath表达式来决定路由的基于内容的路由服务。它还能寄存定制的服务或用于接入打包的应用的专门适配器。

    这和它们的远房亲戚应用服务器容器及集成代理可不一样,ESB服务容器可以让你随时在任何地方有选择性地按需部署集成服务,不多也不会少。而另一方面即使只需要添加一点集成功能都需要在所有地方安装完整的应用服务器堆栈。这样就产生了所谓的"到处都是应用服务器"的问题。同时还会产生数目不小的许可证、安装、和随后相关的各种费用。

    而ESB的精髓在于"配置取代编码"。如果是以应用服务器为主的集成方式,你通常要编写代码来描述服务之间的依存关系。EJB模型使用的是client/server的集成模式,服务之间的接口是紧耦合的关系,而这些都要写进代码并编译到类文件中,这样,每次需要改动的时候都要对这些文件进行修改和重新部署。

    在ESB中,服务是以与输入和输出通道有关的信息进行配置的。这些通道发送和接收基于内容的请求和响应模式以及单向事件通知,然后通过其它的调用框架进行处理,而不是服务本身。

    可以对ESB服务进行配置和部署,这只需要从配置仓库里读取XSL模式表、XPath表达式、脚本和参数等信息。一旦部署完成,其性能便是高度灵活的。

    总结

    总的来说,对ESB的理解包含以下方面:

    · ESB是建立企业SOA集成环境的主干总线。

    · WS-*标准的发展将使ESB的交互性能更为完善。今天采用ESB可以让你做好应付未来的准备,并且当WS-*标准具有真正的商业价值的时候你也能做出适当的调整。

    · ESB并不仅仅是一个抽象的模式。它属于产品的范畴,有清晰的定义,也有许多供应商可以选择。

    · ESB与应用服务器的互补性很强。

    · ESB提供了灵活的连接器和可扩展的设施,有利于将门户服务器集成到后端系统。

    · ESB为协调服务之间的交互提供了许多选择。

    · ESB技术是以实际为基础的,并已在许多行业得到应用。

    · ESB可以提供更高层次上的可视化工具在ISE环境下进行服务集成。

    · ESB提供了一个轻量级、可配置、高度分布式的服务容器环境。


    转载于:https://my.oschina.net/abcijkxyz/blog/722241

    展开全文
  • 就是企业数据总线的意思,他的核心功能就是兼容各种协议接口,可以将数据在各种协议之间进行流转,并且可以针对数据格式进行编排转换。(格式转换、协议转换、代理、编排、安全控制、监控、不支持高并发,类似于...
  • ESB系列之企业服务总线ESB简介

    千次阅读 2017-07-03 10:05:25
    为什么不采用传统架构而是采用ESB总线方案ESB应该有哪些服务? 传输服务 安全、可靠的数据传输 永久性/非永久性 同步/异步 仲裁服务 路由 格式转换 事件服务 事件发现和发布 Publish / Subscribe ESB实施方式...
  • 满意答案yf521sy2020.02.01采纳率:57%等级:7已帮助:210人网络拓扑(Topology)结构是指用传输介质互连各种设备的物理布局,各类型优缺点如下:一、总线型:采用一条称为公共总线的传输介质,将各计算机直接与总线...
  • 那么,工业以太网与现场总线技术各自优缺点都有哪些呢?接下来就跟随飞畅科技的小编一起来看看吧! 现场总线 现场总线式应用在生产现场、连接智能现场设备和自动化测量控制系统的数字式、双向传输、多分支结构的...
  • 企业服务总线ESB

    千次阅读 2017-02-23 13:30:54
    企业服务总线(Enterprise service bus). 以往企业已经实现了很多服务, 构成了面向服务的架构,也就是我们常说的SOA. 服务的参与双方都必须建立1对1 的联系,让我们回顾一下SOA架构有哪些基本的要求: SOA在相对较粗...
  • DBus(数据总线)项目就是应这个需求而生的, DBus专注于数据的收集及实时数据流计算,通过简单灵活的配置,无侵入的方式对源端数据进行采集,采用高可用的流式计算框架,对公司各个IT系统在业务流程中产生的数据...
  • 曾今SOA的概念犹如今日“云计算、大数据”一样,被炒得火热,不少企业便纷纷响应,并宣称会拥抱和实施SOA。而事实上,业界出现了两种极端:一种是由于各类文章和书籍关于SOA...
  • 开源企业服务总线ESB汇总与对比

    万次阅读 2011-03-29 09:09:00
    WSO2是基于Apache Synapse产品的,通过它可以在web服务,REST/POX服务以及遗留系统间连接,管理和转换服务交互。它还提供了一个基于AJAX的ESB管理控制台对其配置文件进行统计分析,管理(添加,删除以及修改等),和...
  • 企业服务总线项目集成标准

    千次阅读 2016-11-25 21:33:47
    企业服务总线(Enterprise Service Bus,缩写 ESB),是SOA面向服务架构的骨干,在完成服务的接入、服务间的通信和交互基础上,提供安全性、可靠性、 高性能的服务能力保障。采用 SOA 架构,基于ESB总线进行企业异构...
  • 企业服务总线相关理论和技术的研究
  • 企业服务总线 ESB 介绍和用例

    千次阅读 2021-08-27 14:41:23
    企业服务总线(ESB)看起来非常复杂,但事实上,它可以非常有效地执行几个关键功能,协助开发人员进行应用集成。 什么是ESB(企业服务总线)? ESB是一种IT架构方法。ESB旨在通过”总线式”基础设施将各种应用集成在...
  • 企业服务总线(ESB)已建立为支持应用程序集成的工具。 但是什么是ESB? 什么时候使用集成套件更好? 哪种产品最适合下一个项目? 本文解释了为什么没有灵丹妙药,为什么ESB也可能是错误的选择。 选择正确的产品...
  • 企业服务总线Enterprise service bus介绍

    千次阅读 2013-06-28 10:27:35
    企业服务总线(Enterprise service bus). 以往企业已经实现了很多服务, 构成了面向服务的架构,也就是我们常说的SOA. 服务的参与双方都必须建立1对1 的联系,让我们回顾一下SOA架构有哪些基本的要求: SOA在相对较粗...
  • 随着互联网+和平台化战略的兴起,各个行业的 IT 系统都在向互联网架构发展,涉及的主要技术包括...企业服务总线(ESB)是否真的过时了? 为什么 RocketMQ 是企业服务总线的最佳技术方案之一? 如何设计企业微服...
  • 三分钟了解服务架构演进及优缺点

    千次阅读 2022-02-27 23:58:58
    缺点:测试成本高、可伸缩性差、可靠性差、迭代困难、跨语言程度差、团队协作难 解释:ABC代表三个模块,A->B->C代表调用关系 测试成本高:每个模块都需要测试,所有关联模块有需要测试 我们要测试除了A...
  • 2019独角兽企业重金招聘Python工程师标准>>> ...
  • 目前国内的电梯服务水平大多仍局限于现场电梯出现了问题,通知维修中心,由维修中心派专人到现场勘查并排除故障。该情况存在的缺点是响应速度慢,还需要现场派专人监守。而电梯远程监控系统为提高电梯维保并及时做出...
  • 国产ESB产品介绍

    2018-11-20 11:07:22
    文档列举了三个国产ESB的介绍:金蝶ApusicESB、锐易特软件、合众企业服务总线,希望可以对后来者提供一些建议
  • EventBridge 事件总线及 EDA 架构解析

    千次阅读 2022-03-25 16:58:46
    简介:EventBridge 是事件驱动的具体落地产品,也是 EDA 的最佳实践方式。 作者:肯梦 作为 Gartner 定义的 10 大战略技术趋势之一,事件驱动架构...运营事件或业务形势的变化是时下众多企业关注的焦点,这些变化能
  • 可以认为微服务架构是不包括Web服务规范(WS-)、企业服务总线(ESB)的SOA。基于微服务的应用倾向于使用更简单轻量级的协议,比如 REST 而不是 WS-。微服务自己实现类似 ESB 的功能并且拒绝 SOA 的其他部分(例如:...
  • 近几年来,越来越多的企业开始实施应用集成项目,但是,同时我们听到的对此类项目的抱怨也越来越多,非常打击用户的信心。对一些问题进行分析后,我们发现,大多数情况下,应用集成项目的问题是因为实施过程中,对...
  • 总线架构是数据仓库建设的总体规划,从整体视角描述了解决方案的维度模型,描述了各个子系统的功能以及关系,描述数据从源系统到决策系统的数据流程,提供建立企业数据仓库系统的增量式方法。业务需求回答了要做什么...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 10,675
精华内容 4,270
关键字:

企业服务总线缺点