1       JBI系统架构(Architecture of the JBI Environment)
JBI 提供了一个插接组件放置的环境。该环境为组件服务的运行，组件之间的交互和整个JBI系统及其安装组件的管理提供了一套服务。
JBI 使用标准的服务描述语言来描述插接组件间基于消息的服务调用达到组件之间的交互。这种方式为组件所提供和消费的服务提供了统一的模型。
JBI 为JBI环境（包括已安装的组件）的管理提供了一套服务，包括组件的安装和组件生命周期管理服务。
1.1    基于WSDL的消息模型(WSDL-based Messaging Model)
JBI 使用WSDL1.1和2.0规范描述组件所提供和消费的服务模型。在WSDL两个版本中，术语定义存在差异的地方以WSDL2.0为准。WSDL在以下两个层面上定义了基于消息的服务模型：
  • 抽象服务模型（Abstract service model）：使用抽象消息模型定义的，未限定到特定消息交换协议的服务
  • 具体（限定）模型（Concrete[bound] model）：指限定到特定协议和通信端点的抽象服务。
JBI 使用抽象服务模型作为组件交互的基础。组件在交互过程中扮演以下一种或两种角色：
  • 服务提供者（Service Provider）：该组件直接提供该服务或作为外部服务提供者代理。
  • 服务消费者（Service Consumer）：该组件直接调用该服务或作为远程服务消费者代理。
WSDL 模型使用名字来标识模型中的各种组件，WSDL模型使用以下两种类型的模型：
  • 限定名（Qualified names）：一个 XML命名空间(URI)和简单名字组成的名称对，用于全局命名；
  • 简单（非限定）名（Simple [non-qualified] names）：只有简单名字，没有关联的XML命名空间，用于局部命名。
WSDL 组件模型示意图如下所示，该模型将在以下几节详细讨论。
图3 WSDL组件模型示意图
1.1.1   抽象服务模型(Abstract Service Model)
WSDL 服务描述中抽象服务模型的定义如下：
  • 抽象消息类型（Abstract Message Type）：消息类型定义了合法的消息结构和约束，一般通过XML Schema来表示。消息分为两类：常态消息（normal）和故障消息（fault），常态消息是指服务正常处理过程中的消息，故障消息用于描述非正常的处理条件。
  • 抽象操作（Abstract Operation）：与某种服务进行交互时的一次操作，该服务由服务消费者和提供者间交换的常态（或故障）消息来定义。抽象操作定义如下：
    • 操作名称（Operation Name）：定义操作的限定名
    • 消息交换模式MEP（Message Exchange Pattern）：消息（包括常态消息和故障消息）在消费者和提供者之间传递的顺序、方向和基数（Cardinality）
    • 消息类型（Message Types）：MEP中的消息的类型
  • 抽象服务类型（Abstract Service Type）：一组相关联的抽象操作（Abstract Operation）的集合。在WSDL2.0中抽象服务类型用术语“接口（interface）”表示，在WSDL1.1中用术语“端口类型（portType）”表示，本规范中沿用“接口”术语。注意不要同Java语言中的接口混淆。抽象服务类型即接口定义如下：
接口名称（Interface Name） ：用于标识服务类型的全局限定名，在JBI中接口名称还用来指明服务类型；
扩展的接口（Extended Interface） ：扩展了其他服务类型的服务类型，类似于Java中的接口类型。一个服务类型可由其他几个服务类型组成。
WSDL 中的具体服务模型建立在抽象服务模型之上，为抽象服务同特定通信协议及通信端点的映射提供描述信息。为了尽可能的保持通信协议中立，JBI中组件间的交互主要基于抽象服务模型，但为了与WSDL服务模型一致，组件间的交互使用WSDL具体服务模型来定义。JBI使用的WSDL具体服务模型非常简单，在大多数情况下可以将其等同为抽象服务模型看待，从而为组件间的交互构建了一个简单的处理模型。
具体服务模型定义了以下几个概念：
  • 绑定类型（Binding types）：标识服务所绑定的协议类型；
  • 端点（Endpoints）：为服务消费者指明通过特定协议与服务提供者交互所需的通信端点的信息。在JBI中，端点是一种形式上的标识，其内部使用的协议是基于Java的标准JBI消息契约，与通常的通信协议无关。JBI中端点的定义包括以下几个概念：
    • 端点名称（Endpoint name）：用于标识服务中的端点的简单名
    • 绑定类型（Binding type）：该端点关联的绑定类型
  • 服务（Service）：提供访问该服务的一组端点的集合，一个服务实现了特定的服务类型（接口）。一个服务包含如下信息：
    • 服务名称（Service Name）：标识特定服务实现的限定名
    • 服务类型名称（Service Type Name）：服务实现的接口名。
    • 端点（Endpoints）：服务“包含”一个或多个端点，通过每个端点都可以访问该服务
通常，一个端点通过结合其服务名称和端点名称来识别，该结合称之为服务端点（Service Endpoint）。
规格化消息（NM）包含两部分：如上所述的抽象的XML消息和消息元数据（即消息上下文信息）。消息上下文可以为特定的消息提供组件（插接组件和系统组件）处理该消息时所需的附加信息。消息元数据可以影响其所关联的消息在JBI系统中的处理过程。
1.3    JBI顶层架构(High-Level Architecture)
下图是JBI架构的顶层视图。
图4 JBI架构顶层视图
整个JBI系统存在于单个JVM中。JBI系统外部的节点是外部服务消费者和服务提供者，代表了JBI要集成的外部实体。这些外部实体可以通过各种各样的技术与JBI系统中的绑定组件交互。服务引擎本质上一个容器，用来放置JBI系统内部WSDL定义的服务提供者和服务消费者。
图4展示了JBI核心的组件架构，这些组件的集合称作JBI系统（JBI Environment）。每个JBI系统中都有一组用于提供操作支持的服务，这组服务中的关键是规格化消息路由（Normalized Message Router[NMR]），它提供用于消息交换和组件交互的基础设施。此外，JBI还定义了一个可插拔组件框架，用于添加服务引擎（SE）和协议绑定组件（BC）。组件框架在图4中用黄色C形多边形来表示。
图中JBI系统右边的部分展示了JBI的管理特性。JBI定义了一套标准的基于JMX的控制允许外部管理工具（图中最右边）执行各种系统管理任务，同时也管理组件本身。
JBI 核心的消息交换实现了上文所述的WSDL消息交换模型。消费者组件生成服务请求，通过NMR路由分发到提供者组件。例如，BPEL服务引擎可能请求一个连接到WS-I绑定组件的外部服务提供者提供的服务。NMR把这个请求发送给WS-I绑定组件。此时服务引擎就是一个服务消费者，而绑定组件是一个服务提供者。
JBI 系统提供的所有服务都可以发布为WSDL描述的服务（准确的说是“服务端点”）。服务引擎提供的服务与绑定组件提供的服务（实际上是外部系统提供的服务）都可以用服务端点描述，从而为服务的提供定义了统一的模型而不用关心服务的具体位置。
服务消费者可以通过WSDL服务名称而不是服务端点地址来识别所需的服务。这种方式降低了服务消费者和提供者之间的关联，从而允许NMR选择合适的服务提供者。服务消费者也可以通过解析服务端点引用（Endpoint Reference）来识别服务。例如， JBI组件可以通过解析消息中的服务端点引用回调其指向的服务。
除了组件框架和NMR，JBI系统的其他部分提供了生命周期管理，环境检查，管理和配置等基础服务，这使得JBI系统成为一个完整而可靠的运行环境。
JBI 系统的首要功能是将规格化消息交换（ME）从一个组件路由到另一个组件。交换的消息使用一种规格化的形式。
绑定组件必须将绑定的消息（特定协议和传输格式的消息）转换成规格化形式。绑定组件和服务引擎通过传输通道（Delivery Channel[DC]）与NMR交互，传输通道为消息的接收和分发提供了双向传输的契约。
图5 外部服务消费者消息处理视图
如图所示，一个外部服务消费者通过特定协议和传输器发送一个服务请求到绑定组件，绑定组件将请求转换成规格化消息。然后，绑定组件根据NM构建消息交换（Message Exchange[ME] 是WSDL消息交换模型中各种简单消息交换模式中消息的容器），绑定组件设定描述将要执行的服务和操作的元数据信息，最后，在步骤2中，绑定组件将消息交换通过传输通道（DC）发送给NMR，NMR将消息交换分发到服务提供者。
上述过程中，由NMR选择合适的服务提供者，然后把消息交换(ME)路由到合适的服务提供者。服务提供者必须从传输通道中主动接收（pull）消息交换。
相反的操作图6所示，只在绑定组件处与图5有少许不同。
图6 外部服务提供者消息处理视图
如图所示，一个消费者（SE/BC）创建一个规格化消息NM并将其放入一个新的消息交换(MessageExchange)中.该消息交换的地址被设定为一个服务端点（ServiceEndpoint），服务引擎未指定用哪一个组件来处理该服务请求。消息交换的发送和接收同前例所示。绑定组件接收到ME后将规格化消息转换为与协议和传输相关的格式，并将其发送给外部服务提供者。
JBI 系统（包括绑定组件和服务引擎）通过JMX进行管理。本规范定义了若干管理Bean（MBean）类型，为JBI系统和插接组件提供了一致的管理环境。
管理接口支持的主要功能如下：
·           组件（服务引擎和绑定组件）的安装
·           组件的生命周期管理（启动/停止等）
·           组件服务描述信息（Service Artifacts）的部署。组件描述信息支持在内部运行环境中动态添加新的内容。例如，SE是一个XSLT引擎，要安装到容器中的新XSLT样式表就是服务描述信息。
·           监控和管理
服务引擎和绑定组件必须通过管理接口进行安装。本规范中动词“安装（install）”指提供组件基本功能的二进制文件及相关资源的安装。安装（install）不同于部署（deployment），部署指根据特定的应用为组件运行添加相关的描述信息，从而定制组件的行为。例如，一个XSLT转换引擎安装后，可以通过部署特定的转换样式表（.xsl文件）使转换引擎提供所需的转换服务。
引擎或绑定组件一旦安装，就可以使用本规范定义的MBean接口启动或停止该组件。该类控制称为生命周期管理。
如上所述，部署是指为安装的引擎或绑定组件提供与组件功能相关的资源。这些资源称为服务单元（Service Units）。本规范未对服务单元的内容作任何说明，其对JBI来说是不透明的。
服务单元组合成一个聚合的部署文件称为为服务集合（Service Assembly）。服务集合包含一个部署描述符，用于指明每个服务单元所要部署到的目标组件。
JBI 组件框架为绑定组件及服务引擎提供了一套可插拔的接口用于与JBI系统进行交互。该框架为所有的JBI操作服务提供接口。
组件与JBI之间的交互有两种机制：SPIs（Service Provider interfaces）和APIs（Application Programming interfaces）。SPIs是绑定组件或服务引擎实现的接口；APIs是组件框架向绑定组件和服务引擎发布的接口。组件框架和组件之间的交互契约在“组件框架”和“格式化消息路由”章节进行详细描述。该契约定义了JBI系统中为达到特定的功能目标，组件框架和JBI组件各自应承担的职责。
规格化消息交换的传输依赖于规格化消息路由（NMR）在服务消费者和提供者之间路由。NMR能够根据消息自身的特性和应用系统的需求支持不同服务品质（QoS）的消息传输。
根据绑定组件和服务引擎协作的需要，NMR支持的QoS包括：
·           最大努力（Best effort）： 消息可能被丢弃或分发多次
·           最少一次（At least once）： 消息不可能被丢弃，但存在重复发送
·           仅有一次（Once and only once）： 消息保证只发送一次
详见“规格化消息交换”一章。
JBI 支持两种组件：服务引擎和绑定组件。这两种组件的模型及API定义是一样的，JBI只是通过一个标记来区分这两种组件。实际上，JBI中服务引擎和绑定组件实现不同的功能。（这种区分同样适用于JBI定义的管理接口）
服务引擎（SE）在JBI系统中表现为业务逻辑驱动。引擎可以编排服务的消费和提供，例如一个长时间的业务处理进程既可以提供服务同时自身也消费服务。服务引擎可以提供简单的服务，如数据转换；也可以提供复杂的路由或EDI服务如消息校勘/反校勘（collation/de-collation）。
服务引擎可以通过聚合其他服务来构造新的服务。WS-BPEL语言正是使用的这种重要的合成模式，通过多个服务构造复杂的处理过程。
绑定组件用于根据特定协议和传输器发送和接收消息。绑定组件把消息在特定于协议的格式和规格化格式之间进行转换，使JBI系统只需处理规格化消息，从而把JBI系统与特定协议分离。（注意，特定于协议的相关信息可以用规格化消息或消息交换的元数据信息表示，供服务引擎或者绑定组件使用，这些元数据信息对其他的JBI系统组件是不透明的。）
下面的例子演示了如何使用JBI系统和组件来完成典型的系统集成任务。
在这个场景中，JBI系统为一条单向消息提供了一个简单的消息适配服务。一条消息从外部发送到JBI系统中，经过转换后发送到外部目的地系统。这是一个简单的点对点的消息传输模式，用于应用到应用（A2A）的整合，如下图所示：
图7 单向消息适配器消息序列图
注意，序列图中的双箭头线表明消息通过NMR路由传递。这是一个非常重要的特征：组件之间是松散耦合的。每一个组件只告诉NMR其所发送消息的目的地的服务名称，由NMR来决定消息路由到哪一个组件。
Client1 作为一个服务消费者希望向Service1提供的服务发送一个单向（one-way）服务请求。不幸的是Client1和Service1使用不同的消息格式和消息传输协议，因此需要采用一个集成中间件来适配两种不同的消息格式和消息传输协议。这里的中间件即是JBI系统，上图表示为中间的大圆角矩形。图中单个的对象包括：
·           BC1 ：使用Client1采用的消息协议（可能是遵循WS-I BP 1.1的SOAP协议）的绑定组件。
·           SE1 ：一个提供轻量级排序服务的服务引擎，可以通过配置对消息进行修改和推进。
·           SE2 ：一个采用XSLT1.0转换消息的服务引擎。
·           BC2 ：使用Service1采用的消息协议的绑定组件，该例中是HTTP之上的AS2协议。
消息序列图中的消息交换过程详见以下部分：
·           Client1 到 BC1。Client1向Service1发送请求，请求的载荷为REQ1。Service1的服务端点为BC1，Client1使用自己的消息交换协议与BC1交互。
·           BC1 将传入的请求规格化为NM，然后通过NMR路由该消息。本例中JBI实例将到Service1的请求消息发送到SE1。 （SE1是一个提供轻量级排序和转换服务的引擎）
·           SE1 选择需要执行的转换类型，向转换服务发送一个请求把REQ1转换成REQ1A。NMR将REQ1发送到转换服务SE2，SE2执行转换并同步返回转换结果（标记为REQ1A）到SE1。
·           SE1 完成其操作后将消息转换结果REQ1A发送到Service1（NMR会将该结果路由给BC2）。
·           BC2 解编规格化消息，将其发送给Service1（单向）。
 
Logo
Cloudpods

开源、云原生的融合云平台

更多推荐

面向未来的 IT 基础设施管理架构——融合云（Unified IaaS）

随着数字化时代的到来，IT系统已成为人类社会正常运转不可或缺的组成部分。不远的未来，智能制造，5G和人工智能等技术将成为推动生产力发展的重要引擎，人类社会将面临前所未有的全面彻底的数字化浪潮。IT基础设施作为IT系统运行的平台和载体，是实现数字化的基石。在这场数字化浪潮中，企业必须积极拥抱云计算技术，采用符合技术发展趋势、面向未来的IT基础构架，才能在未来的竞争中赢得先机。 一、云计算历经十余年

avatar Cloudpods

Cloudpods负载均衡的功能介绍

作者:周有松 今天的内容会从以下几个方面展开： 负载均衡产品简介。主要介绍负载均衡作为一个云上产品，它的功能模型是怎样的，日常使用中会遇到的业务词汇负载均衡的功能与典型应用场景。这部分主要结合业务词汇，对负载均衡服务中常见的一些功能选项进行介绍，并举例介绍一些典型的应用场景最后，我们做一下总结，讨论一下负载均衡产品相比传统方式的优点 一、产品简介​ 1. 以NGINX为例​ 提到负载均衡，我们以

avatar Cloudpods

使用Linux vfio将Nvidia GPU透传给QEMU虚拟机

Linux 上虚拟机 GPU 透传需要使用 vfio 的方式。主要是因为在 vfio 方式下对虚拟设备的权限和 DMA 隔离上做的更好。但是这么做也有个缺点，这个物理设备在主机和其他虚拟机都不能使用了。 qemu 直接使用物理设备本身命令行是很简单的，关键在于事先在主机上对系统、内核和物理设备的一些配置。 单纯从 qemu 的命令行来看，其实和普通虚拟机启动就差了最后那个-device的选项。这

avatar Cloudpods