JBI消息规范-第一部分

JBI提供了一个插接组件存在的环境。该环境为组件服务运行，组件之间的交互和所有安装组件及整个JBI系统的管理提供了一组基础服务。JBI使用标准的服务描述语言来描述插接组件间基于消息的服务调用方式的交互。这种方式为组件所能提供和消费的服务的描述提供了统一的模型。

1.基于WSDL的消息模型

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命名空间和简单名字组合的名称对组成，用于全局命名；
• 非限定名（Simple [non-qualified] names）：只有简单名字，没有关联的XML命名空间，用于局部命名。

WSDL组件模型示意图如下图所示，该模型在下述章节进行详细讨论。

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”表示，该规范中沿用“接口”术语。抽象服务类型即接口定义如下：

接口名称（interface name）：用于标识服务类型的全局限定名，在JBI中接口名称用于指明服务类型；

扩展的接口（extended interface）：扩展了其他服务类型的服务类型，类似于Java中的接口类型。一个服务类型可以是其他几个服务类型的合并。

1.2具体服务模型（Concrete Service Model）

WSDL中的具体服务模型建立在抽象服务模型之上，为抽象服务与特定通信协议及通信端点的映射提供描述信息。为了尽可能的保持通信协议中立，JBI中组件间的交互主要基于抽象服务模型，但为了与WSDL服务模型一致，组件间的交互使用WSDL具体服务模型来定义。JBI使用的WSDL具体服务模型非常简单，从而为组件间的交互构建了一个简单的处理模型，在大多数情况下可以将其等同为抽象服务模型看待。具体服务模型定义的概念如下：

• 绑定类型（Binding types）：标识该服务所绑定的协议类型；
• 端点（Endpoints）：端点为服务消费者指明了通过特定协议与服务提供者交互所需的通信端点的信息。在JBI中，端点是一种形式上的标识，其内部使用的协议是基于Java的消息契约，而与通常的通信协议无关。JBI中端点的定义包含如下信息：

端点名称（Endpoint name）：用于标识服务中的端点的非限定名；

绑定类型（Binding type）：该端点关联的绑定类型；

• 服务（Service）：服务是提供了访问该服务入口的一组端点的集合，一个服务实现了特定的服务类型（接口）。一个服务包含如下信息：

服务名称（Service Name）：标识特定服务实现的限定名；

服务类型名称（Service Type Name）：标识该服务实现的服务类型即接口；

端点（Endpoints）：该服务“包含”一个或多个端点，通过每个端点都可以访问该服务；

通常，一个端点通过其服务名称和端点名称的结合来识别，称之为服务端点（Service Endpoint）。

2.格式化消息（Normalized Message）

格式化消息（NM）包含两部分：如上所述的抽象的XML消息和消息元数据（即消息上下文信息）。消息上下文可以为特定的消息提供组件处理该消息时所需的额外信息。消息元数据可以影响其所关联的消息在JBI系统中的处理过程。

3.JBI顶层架构

下图是JBI架构的顶层视图。

整个JBI系统存在于单个JVM中。上图中，JBI系统外部的节点是外部服务消费者和服务提供者，也就是JBI系统所要集成的应用系统。这些外部应用系统实体可以通过各种各样的技术与JBI系统中的绑定组件交互。服务引擎是位于JBI系统内部的承载WSDL规范中的服务提供者和服务消费者的标准容器。

上图展示了JBI核心的组件架构，这些组件的集合称作JBI系统（JBI Environment）。在JBI系统中，有一组为各种操作提供支撑的服务，这组服务中的关键是用于调度消息交换和组件交互的基础服务即格式化消息路由（Normalized Message Router[NMR]）。此外，JBI还定义了一个可插拔组件框架，用于添加服务引擎和协议绑定组件。上图JBI系统中右边的部分展示了JBI的管理特性。

JBI核心的消息交换实现了上文所述的WSDL消息交换模型。消费者组件生成服务请求，通过NMR路由分发到提供者组件。【For example, the BPEL SE may generate a request, which happens to be provided by the external service provider connected to the WS-I BC. The NMR will route the request to the WS-I binding. The SE in this case is a service consumer, and the BC a provider.】

JBI系统中所有组件提供的服务都可以发布为WSDL服务（准确的说是“服务端点”）。服务引擎提供的服务与绑定组件提供的服务（实际上是外部系统提供的服务）都可以用服务端点描述，从而为服务的提供定义了统一的模型而不用关心服务的具体位置。

服务消费者可以通过WSDL服务名称定位所需的服务，而不是通过服务端点地址。这种方式使得服务消费者和提供者之间的关联性降低，从而允许NMR选择合适的服务提供者。服务消费者也可以通过解析服务端点引用（Endpoint Reference）来定位服务。例如，这可以使得JBI组件通过解析消息中的服务端点引用回调其指向的服务。

除了组件框架和NMR，JBI系统的其他部分定义了生命周期管理，环境检查，管理和配置等基础服务，这使得JBI系统成为一个完整而可靠的运行环境。

4.格式化消息交换

JBI系统的首要功能是将格式化消息交换（ME）从一个组件路由到另一个组件。交换的消息为格式化消息（NM）。

绑定组件必须将绑定于特定协议的消息转换成格式化消息（NM）。绑定组件和服务引擎通过传输通道（Delivery Channel[DC]）与NMR交互，传输通道为消息的接收和分发定义了双向传输的契约。

如上图所示，一个外部的服务消费者通过特定协议和通道发送一个服务请求到绑定组件，绑定组件将请求转换成格式化消息，然后，绑定组件根据NM构建消息交换（Message Exchange[ME] 是WSDL消息交换模型中各种交换消息NM的容器），绑定组件在消息交换ME中设定需要执行的服务和操作的元数据信息，最后，在步骤2中，绑定组件将消息交换通过传输通道DC发送给NMR，NMR将消息交换分发到服务提供者。

上述过程中，由NMR选择合适的服务提供者，然后路由消息交换到服务提供者。服务提供者必须从传输通道中主动接收（pull）ME。

相反的操作如下图所示：

如上图所示，一个消费者（SE/BC）构建一个格式化消息NM，将其放入消息交换ME中，该消息交换的地址被设定为一个服务端点（Service Endpoint），服务引擎未指定用哪一个组件来处理该服务请求。消息交换ME的发送和接收如上文例子一样。绑定组件接收到ME后将格式化消息转换为与协议相关的格式，并将其发送给外部服务提供者。

5.管理（Management）

JBI系统包括绑定组件和服务引擎，通过JMX进行管理。该规范中定义了若干管理Bean类型，为JBI系统和插接组件提供了一致的管理环境。管理接口支持的主要功能如下：

• 组件的安装
• 组件生命周期的管理（启动/停止等）
• 组件服务描述信息（Service Artifacts）的部署
• 监控和管理

5.1组件安装（Component Installation）

服务引擎和绑定组件必须通过管理接口部署安装。本规范中动词“安装（install）”指组件的二进制文件及相关资源的安装。安装（install）与部署（deployment）具有不同的含义，部署指根据特定的应用为组件运行提供与应用相关的资源，从而定制组件的行为。例如，一个XSLT转换引擎安装后，可以通过部署不同的转换样式表（.xsl文件）使转换引擎提供不同的转换服务。

5.2生命周期管理（Life Cycle Management）

引擎或组件一旦安装，就可以使用本规范定义的MBean接口启动或停止该组件。该类控制称之为生命周期管理。

5.3服务单元部署（Service Unit Deployment）

如上所述，部署是指为安装的引擎或绑定组件提供与组件功能相关的资源。这些资源称之为服务单元（Service Units）。该规范未对服务单元的内容作任何定义，其对JBI来说是透明的。

服务单元组合成一个聚合的部署文件，该文件称之为服务装配（Service Assembly）工件。该工件包含一个部署描述符，用于指明每个SU所要部署到的目标组件。

6.组件框架

JBI组件框架为绑定组件及服务引擎提供了一套与JBI系统交互的接口。该框架还为所有的JBI操作服务提供了接口。组件与JBI之间的交互有两种机制：SPIs（Service Provider interfaces）和APIs（Application Programming interfaces）。SPIs是绑定组件和服务引擎实现的接口；APIs是组件框架向绑定组件和服务引擎公开的操作接口。组件框架和组件之间的交互契约在“组件框架”和“格式化消息路由”章节进行了详细的描述。该契约为了在JBI系统中实现特定的功能目标而指明了框架和JBI组件各自承担的职责。

7.格式化消息交换（NMR）

格式化消息交换ME的传输依赖于格式化消息路由（NMR）在服务消费者和提供者之间路由。NMR能够根据消息自身的特性和应用系统的需求提供不同的服务品质（QoS）。根据绑定组件和服务引擎协作的需要，NMR支持的QoS包括：

（Best effort）：消息可能被丢弃或多次分发

（At least once）：消息不可能被丢弃，但存在重复发送

（Once and only once）：消息保证只发送一次

详细信息参考“格式化消息交换章节”。

8.组件（Components）

JBI支持两种组件：服务引擎和绑定组件。这两种组件的模型及API定义是一样的，JBI只是通过一个标记来区分这两种组件。在实际实现中， 服务引擎和绑定组件实现不同的功能。（这种区分同样适用于JBI定义的管理接口）

8.1服务引擎

服务引擎（SE）在JBI系统中表现为业务逻辑驱动。引擎可以是服务消费者和服务提供者的结合，例如一个长时间的业务处理进程既可以提供服务同时自身也消费服务。服务引擎可以提供简单的服务，如数据转换；也可以提供复杂的路由或EDI服务【EDI services such as message collation / de-collation facilities.】

服务引擎可以通过聚合其他服务来构造新的服务。WS-BPEL语言正是使用的这种重要的合成模式，通过多个服务构建复杂的处理过程。

8.2绑定组件

绑定组件用于根据特定协议和传输器发送和接收消息。绑定组件通过在特定于协议的消息格式和JBI组件间传递的格式化消息NM之间进行转换，使得JBI系统只需面对处理格式化消息，从而使JBI系统与特定协议隔离。特定于协议的相关信息可以用格式化消息NM或消息交换ME的元数据信息表示，供服务引擎或者绑定组件使用。

9.举例

下面的例子演示了如何使用JBI系统和组件来完成典型的应用系统集成任务。

9.1单向消息适配

在该场景中，JBI系统为一条单向消息提供了一个简单的消息适配服务。一条消息从外部系统发送到JBI系统中，转换后通过JBI系统发送到外部目的地系统。这是一个简单的点对点的消息传输类型，用于应用到应用（A2A）的整合，如下图所示：

上图消息序列中的具有双箭头的连接线表明该消息通过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选择需要执行的转换类型。NMR将REQ1路由到转换服务SE2，SE2执行转换并同步返回转换结果（标记为REQ1A）到SE1。
• SE1完成其操作后将消息转换结果REQ1A发送到Service1（NMR会将该结果路由给BC2）。
• BC2解编格式化消息，将其发送给Service1。