jbi后缀_分布式JBI

最新推荐文章于 2024-04-27 15:49:01 发布

cunfu6353

最新推荐文章于 2024-04-27 15:49:01 发布

阅读量262

点赞数

文章标签：分布式大数据编程语言数据库 python

原文链接：https://www.infoq.com/articles/jbi-topologies/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

版权

jbi后缀

抽象

Java业务集成（JBI）规范（称为JSR 208）描述了企业服务总线（ESB）及其交互。这些交互是通过将组件插入软件总线以交换信息来描述的。乍一看，这种构造似乎可以创建一个系统，其中所有组件都驻留在同一进程或虚拟机中。 OpenESB是JBI的开源实现，当在GlassFish Application Server中运行时，它包括使用集群JBI实例的同类拓扑选项。这样可以通过增加群集实例的数量来实现可伸缩性和负载平衡。最近，称为Proxy Binding的组件的原型实现允许OpenESB实例使用异构拓扑透明地链接在一起，就像在网络上扩展总线一样。本文将描述和对比两种不同样式的分布式访问在OpenESB环境中的优缺点，并说明它们最终如何互补。

介绍

人们通常认为JBI规范仅限于单个Java虚拟机（JVM）实例。该规范没有明确说明分布式版本的功能。这不应阻止有兴趣的人探索新领域。实际上，自从规范获得批准以来，就出现了两种不同样式的解决方案，在本次讨论中我们将其称为拓扑。这些解决方案只需要对高级管理功能和一些低级信息挂钩进行少量的少量增强。通过这些更改，以一种几乎透明的方式添加了两种不同的拓扑。

以下各节的目的是：通过插图介绍两种不同的拓扑和组合的拓扑；讨论每种拓扑的具体细节；讨论JBI组件的实现细节在拓扑决策中扮演的角色。最重要的目标是表明两种不同的拓扑结构本身是有用的，但是当它们可以组合在一起时可以提供更大的好处。一个吸引人的地方是突出显示所有这些基础之上的组件如何对整体功能做出很大的贡献。

拓扑概述

我们将从两个不同拓扑的示例开始，然后显示一个组合的示例。由于历史原因，这两种不同的拓扑分别称为同构和异构。这些示例来自在GlassFish环境中运行的OpenESB。

异构拓扑

顾名思义，异构拓扑会创建OpenESB实例，这些实例的JBI内容可能会有所不同。基本的应用程序流程是相同的：HTTP请求导致BPEL流程调用和响应。此拓扑由称为“代理绑定”（在插图中为PB）的特殊组件支持。

图2：异构拓扑

组合拓扑

此示例是前两个示例与包含非复制服务的其他JBI实例的混合。

插图3：组合拓扑

OpenESB拓扑细节

在决定应选择哪种拓扑时，有许多因素会起作用。对于OpenESB，选择均质作为第一个实现，因为它与GlassFish提供的功能相匹配，后者被用作主要的托管环境。异构的实际上拥有第一个原型，并且该原型现在也已可用。实现顺序并不重要，它们本身都有用，并且一起使用时是互补的。

同质

同类拓扑创建具有相同JBI内容的OpenESB实例。 JBI内容包括组成一个或多个复合应用程序的一组组件，服务程序集和配置信息。这些JBI实例映射到基础GlassFish群集实例，可以根据需要创建，销毁，启动和停止。可以在由单个操作系统映像管理的每台计算机上使用一个或多个实例创建群集实例。这种灵活性允许更好地使用cpu资源，并在通常为面向Web的一侧提供服务的多线程处理器上具有更高的可用性。新创建的实例和在执行集群更改时未运行的实例在启动期间从包含整个集群配置的中央管理服务器（CAS）同步了它们的配置。这样可以确保所有群集实例均具有相同的功能。

可扩展性

此拓扑的最常用用法是水平扩展具有很大扇入度的面向Web的服务。轻松适应负载变化是主要优势。此外，GlassFish包括一个软件HTTP负载平衡器，该负载平衡器可以位于群集实例的服务器场之前，并可以补充此用法。

管理

GlassFish应用服务器直接支持此拓扑。 OpenESB包括驻留在CAS上的管理增强功能，可以在本地记录配置更改，然后将更改传播到活动实例。这些增强功能确实允许JBI管理操作以特定实例或一组实例或所有实例为目标。因此严格的同质性不是硬性要求，而是一种典型用法。

范例详细资料

先前的同类插图描绘了一个简单的两实例群集。每个集群实例包含两个组件，一个面向Web的HTTP绑定组件和一个BPEL服务引擎。典型的应用程序可能会具有许多其他组件（数据库访问，电子邮件协议，甚至是非常专门的协议，例如HL7或SAP。）HTTP和BPEL的组合是一种最小的配置，可以执行大量的工作。群集的前面是一个软件HTTP负载平衡器。还描述了集群管理服务器。

需要注意的一些重要点：

每个群集实例通常都是相同的。如果群集实例部署在相同的操作系统映像和网络接口上，则可以将每个HTTP实例配置为使用不同的端口号。
服务端点在集群中重复，但是它们的作用域对于每个实例都是本地的。
群集实例的数量可以随时间变化。这是使拓扑具有水平缩放的功能。它们可以在同一台物理计算机上，也可以在不同的计算机上，或者可以是混合的。通常，群集实例在物理上位于同一位置。

异质

异构拓扑创建OpenESB实例，这些实例的JBI内容可能不同。此拓扑由称为“代理绑定”的特殊组件支持。代理绑定允许一个实例上的组件托管的服务由另一实例上的组件使用。代理绑定在每个希望成为该松耦合关联的一部分的实例上运行。组件仅使用配置为使用的相同服务端点名称。每个代理绑定实例都会构建并维护实例提供的目录映射服务。如果多个实例导出同一服务，则默认情况下，代理绑定会在提供实例之间平衡请求的负载。异构系统当前作为单个系统进行管理。

代理绑定处理的主要问题是意识和传输。意识是代理绑定能够宣传其共享服务的意愿以及找到具有类似需求的其他代理绑定的能力。解决了感知之后，下一个问题是如何在实例之间传输包含NormalizedMessage（NM）的JBI MessageExchange（ME）。

意识

意识是一个长期而深入研究的问题。 JXTA和JGroups是已经发展成为良好的低级解决方案的项目。 Shoal / GMS是一个较新的项目，它提供了一个基于包括JXTA和JGroups在内的一系列低级技术的高级解决方案。 Shoal是一个功能强大但非常易于使用的项目，可以以独立方式使用，也可以作为GlassFish Application Server提供的服务使用。 GlassFish Application Server本身使用Shoal来管理集群意识，并在集群实例发生故障时为自动XA事务恢复提供基础，并为EJB提供分布式状态缓存。

代理绑定使用Shoal作为其默认感知机制。意识机制在设计时考虑了可插入性。这允许将来创建和使用不同的意识机制。

运输工具

有很多传输协议可供选择。默认情况下，代理绑定使用Shoal作为其传输。 Shoal提供的消息传递原语允许：点对点，一对多和一对多寻址。代理绑定对与服务端点更改相关的消息使用一对一的方式，对组件之间包含ME + NM内容的消息使用点对点的方式。其他各种传输协议正在研究中。调查正在探索两个主题：性能和可靠性。

传输性能是根据消息/秒和总字节吞吐量来衡量的。 HTTP是一个明显的候选者。最终性能可能来自某种形式的低级TCP或UDP传输。带有SSL / TLS分层的传输层可确保安全性和完整性，可以满足大多数要求。基本推力是在不需要可靠性或以其他方式保持可靠性时提供大容量运输工具。

传输可靠性也有类似的性能问题，但有趣的好处是一次性传输。通常使用某种形式的持久性存储来实现。分布式系统中使用的最常见的风味是消息队列系统。消息排队系统还可以通过允许消息存储到接收系统可用之前来隐藏可用性问题。此类传输的可用性可以大大增强部署在此基础结构上的应用程序的整体功能。 JMS消息排队系统与GlassFish捆绑在一起。这使JMS成为自然交通目标。由于JMS具有XA事务感知能力，因此可以使Proxy绑定参与事务。这将大大增强其能力。另外，具有JMS传输的效果类似于在两个组件之间拼接JMS绑定组件。将其作为传输的一部分最终可以节省一些开销。

在传输级别具有选择或选项有助于将应用程序需求映射到平台功能。还应该有可能基于ME中服务注释的质量来选择传输类型。从代理服务器绑定的角度来看，这仅意味着支持实例之间的多个同时传输，并根据任何可用信息选择要使用的一个。

范例详细资料

先前的异构图示描述了3个单独的OpenESB实例。它可以实现与同类示例相同的应用程序。在这种情况下的区别是：只有一个面向Web的HTTP绑定组件，并且有两个不同的BPEL服务引擎组件，每个组件都实现相同的服务（epB。）。

需要注意的一些重要点：

每个实例都包含一个代理绑定组件，该组件可维护分布式感知并在实例之间透明地执行任何消息传递。
当实例1中的NMR带有发往端点epB的消息时，它可以选择在实例2或实例3之间进行路由。默认情况下，NMR当前在可用实例之间进行负载平衡。因此，决策是基于活动ME数量最少的实例。
异构实例具有多种放置选项。它们可能位于同一操作系统映像上，也可能位于世界的相反两端或介于两者之间的任何位置。

组合

前面的组合图是前两个示例的融合。我们首先从面向Web的群集实例开始，然后再使用负载均衡器。每个群集实例也是与第三个实例连接的异构分布式系统的成员。

需要注意的一些重要点：

异构拓扑可以混合使用。代理绑定组件控制分组。从理论上讲，一个实例可以属于多个组（尚未经过正式测试）。
选择混合拓扑的原因有很多：第三方软件的许可限制，旧系统访问，轻负载，组件体系结构约束（即，在群集中不能很好地运行），地理隔离。
当NMR收到来自HTTP的BPEL资源请求时，现在可以在本地BPEL实例或远程BPEL实例之间进行选择。默认情况下，将在远程实例上选择一个本地实例，并且可以在不涉及代理绑定组件的情况下做出此决定。如果本地BPEL由于某种原因终止，则请求将被路由到尚存的实例。

组件质量

标准化消息路由器（NMR）是ESB的一部分，所有组件都用于发送和接收组件间消息。 NMR专注于在组件之间快速切换消息。 ME执行完成或终止。该机制的设计目的不是持久性或可恢复性。 ME可以包含XA事务信息，该信息可用于使ME的动作具有事务性。 OpenESB中可用的许多组件都是使用中间层构造的，该中间层在此简单原语的基础上增加了各种系统质量。可靠性质量是此讨论中最重要的。最有趣的可靠性质量包括：唯一标识符，重试，重复检测和事务交换。

大多数组件使用前三种质量的混合来支持一次至少一次消息传递。重试失败的消息，直到返回响应或达到阈值为止。唯一标识符附加到ME，以帮助接收组件检测和拒绝重复请求的重播。这一系列操作提供了至少一次的服务水平。

一些组件支持事务操作。这通常是由于组件实现原因而拥有一个持久性存储并另外具有XA事务支持的副产品。这允许事务包含跨越两个组件的ME的动作。使用多个ME可以使单个事务扩展到多个组件，但是当事务跨度太广或时间太长时，事情往往变得笨拙。 ME使用事务可以提供一次仅一次的服务级别。

一些组件支持使用持久共享状态在不同群集实例上同时执行同一组件。此共享状态还可以用于将故障实例孤立的工作故障转移到仍在运行的实例。从可靠性的角度来看，这种类型的组件在灵活性方面是最先进的。 JavaEE引擎和BPEL引擎是该类别中的主要示例，并且JMS绑定到较小的类别程度。

例

下图显示了一个2实例集群和一组忽略或意识到在集群中运行的组件。

插图4：组件质量

一些重要的注意事项：

XLST是一个无状态组件，仅将XSLT转换应用于XML文档。可以重试此操作，而没有任何实质影响。
企业Java Bean（EJB）将其状态保存在数据库中，并将结果缓存在分布式内存缓存中。支持通过多个实例进行访问。
JMS在某种持久性存储中维护其消息队列，这些持久性存储通常基于文件或存储在数据库中。群集实例由单独的进程管理，以处理多个实例访问。
可以将BPEL配置为将其内部流状态持久化到数据库。失败的BPEL实例可以在不同的集群实例上恢复，并且处理引用该流的操作时，处理工作负载将迁移到可用的BPEL实例。
EJB，JMS和BPEL都支持XA事务。这允许原子动作作为JBI Exchange的一部分执行。例如，事务可以包装从JMS队列中获取的内容，然后将其发送到BPEL引擎并作为变量持久化在流中。

摘要

本文的目的是展示OpenESB如何从JVM的世界观逐步发展起来，以包括支持分布式功能的两种不同拓扑。这两种拓扑是互补的。

在这个更广泛的范围内，消息传递质量变得更加重要。基础NMR使用内存中消息传递结构。 NMR上分层的组件会添加外部协议。这些外部协议中的某些（例如JMS）可用于以比组件自身支持更可靠的方式连接组件。 JMS作为分布式传输的使用使内容具有连贯性。使消息成为事务一部分的附加功能增加了可用解决方案的功能。

此外，我们证明了组件还可以在为最终结果的整体功能做出贡献方面发挥关键作用。使组件实现一套可以配置的通用系统质量，使复合应用程序设计人员可以自由地探索大型解决方案空间。较大并不总是更好，但是在处理现有系统的集成时特别有用。集成是产生JBI的最初想法，但在其他情况下它将被证明是有用的。

参考资料

翻译自: https://www.infoq.com/articles/jbi-topologies/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

jbi后缀

cunfu6353

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
jbi后缀_分布式JBI

jbi后缀抽象 Java业务集成（JBI）规范（称为JSR 208）描述了企业服务总线（ESB）及其交互。这些交互是通过将组件插入软件总线以交换信息来描述的。乍一看，这种构造似乎可以创建一个系统，其中所有组件都驻留在同一进程或虚拟机中。 OpenESB是JBI的开源实现，当在GlassFish Application Server中运行时，它包括使用集群JBI实例的同类拓扑选项。这样...
复制链接

扫一扫