JBI规范1.0[3]——概述

Juset

墨衍会员 · AI 创作全网分发码龄20年

关注

翻译最新推荐文章于 2021-02-13 00:00:01 发布 3.7k 阅读 AI 写同款· GEO 优化 ›

AI权益加码！Claude Code、Cursor等20+工具免费用！购周边限时加赠Coding Plan Lite，畅享主流AI工具！学习进阶更高效！阅读详情

1 概述(Overview)

JBI定义了一种通过插接组件间交互传递中间消息（Mediated Message Exchange）的方式构建集成的架构方案。JBI中定义的消息交换模型基于WSDL2.0规范（或WSDL1.1）。

图1 JBI插件系统

图1展示了抽象层次的JBI插接组件概念，JBI为插接组件提供了特定的交互接口，插接组件也为JBI系统提供了特定的交互接口，组件与组件之间并不直接进行交互，相反如图2所示，JBI作为组件之间消息交换的中介。参与数据交换的组件间的分离对于解耦服务提供者和服务消费者是至关重要的，这也是一般的SOA架构，特别是集成解决方案所期望的。这种方式提供了很大的灵活性，因为消费者和提供者之间的纠缠达到了最小化，同时对于JBI实现中的消息处理和监控也是很重要的。同时要注意，因为这种处理模式中固有的异步特征使得提供者和消费者之间从不共享一个线程，从而有助于保持组件间的松耦合。

图2中间消息交换：消息序列图

在这种基于WSDL的面向服务的架构模型中，JBI插接组件负责提供和消费服务。通过提供服务，一个组件为其他组件甚至是它自己提供了一种或多种处理功能（function），这些功能在WSDL2.0模型中定义为操作（operation），参与一个或多个消息的交换。WSDL规范中定义的四种基本的消息交换模式（Message Exchange Patterns，简称MEPs）清楚地定义了上述操作在执行过程中消息的交换顺序。这四种消息交换模式是JBI组件（消费者和提供者）之间进行交互的基础。

JBI组件提供的任何服务都是由组件使用WSDL1.1或2.0规范进行描述的，WSDL为基于XML的消息交换提供了一种抽象的，独立于特定技术的服务模型。WSDL也为服务消费者和JBI环境本身提供了一种声明额外的服务元数据的机制，组件可以通过JBI环境查询可用的WSDL描述的服务。

如图1所示，JBI组件插接在一个称为“JBI框架”(JBI framework)的环境中。这些组件可为来自第三方的终端用户所用，尤其在应用系统集成时遇到问题时，它们可以提供一些通用的或标准的功能。

这些组件可以分为两种不同的类型：

· 服务引擎（Service Engine [SE]）服务引擎既为其他组件提供了业务逻辑和数据转换服务，同时也消费这些服务。服务引擎可以集成基于Java的应用（和其他资源）或提供了Java API接口的应用。

· 绑定组件（Binding Component [BC]）绑定组件为JBI环境以外的服务提供了连通性，这些外部的服务可能包括通信协议或企业信息系统(Enterprise Information System)提供的服务（EIS资源）。绑定组件可以集成使用Java环境不能提供的远程访问技术的应用（或其他资源）。

服务引擎和绑定组件可以是服务提供者，服务消费者或两者兼具。服务引擎和绑定组件基于合理的架构原则，但两者之间的差别完全由实际应用决定。把业务处理逻辑同通信逻辑分离降低了实现的复杂度并提高了灵活性。

JBI不仅为消息系统提供了组件互用性，同时也定义了一个基于JMX(Java Management eXtensions)的管理框架。JBI为以下功能提供了标准的管理机制：

· 组件的安装

· 组件生命周期的管理（启动/停止等）

· 组件服务描述信息（Service Artifacts）的部署

最后要说明的一点是，JBI组件也可以看作一种容器，通过部署服务描述信息添加新的服务消费者或服务提供者逻辑。例如，一个提供基于XSLT转换服务的服务引擎可以部署XSLT样式表，从而添加新的转换操作。这种为特定组件添加功能服务描述信息的过程称为“部署”（Deployment），用于区分组件的安装。JBI将一组部署描述信息及其相关的元数据的集合称为服务集合（Service Assembly）。这些服务描述信息及其关联元数据集在一些文献中称为合成服务描述符（Composite Service Description [CSD]）。

1.1 定义(Definitions)

JBI定义的不是一个传统的应用程序模型，相反地， JBI通过将插接组件抽象为服务提供者和服务消费者而与面向服务的架构紧密结合来构建企业应用。开发人员使用该规范中定义的APIs和SPIs开发插接到JBI环境中的服务引擎和绑定组件。

服务引擎（SE）是指提供业务逻辑处理，数据转换服务等的插接组件。

服务引擎根据其提供的功能可以有多种形式。特别的，一些SE可作为处理容器，为用户提供特定的开发模型，例如：

· 一个XSLT XML转换引擎可以支持多种转换形式，应用开发接口就是XSLT语言本身；

· 对于一个WS-BPEL 2.0业务处理执行引擎，应用开发接口就是WS-BPEL；

· 对于一个EJB容器，API就是符合特定EJB规范的Java。

绑定组件通过提供通信协议处理功能，使得JBI组件可以访问JBI环境以外的外部系统提供的远程服务，同时外部远程服务消费者可以访问JBI环境内部提供的服务。通信协议可以根据系统集成需求的不同而不同，典型的例子包括：

· 基于HTTP的SOAP[http://www.ws-i.org/Profiles/BasicProfile-1.1.html]；

· JMS/MOM[http://jcp.org/aboutJava/communityprocess/final/jsr914/index.html]

· AS1/AS2 EDI [http://www.ietf.org/html.charters/ediint-charter.html]通信协议栈。

一个绑定组件可能会选择实现一种或多种通信协议，提供到SE的连通性服务，使SE把它们的服务发布给远程消费者，同时它们也消费远程服务。

JBI的各种用户可以扮演几种不同的角色：

· 集成架构师(Integration Architect)设计解决系统集成问题的整体思路，包括选择提供连通性和业务逻辑的JBI组件。

· 集成技术员(Integration Technologist)设计解决某个集成问题的具体服务，并对这些服务在JBI系统中的集成进行配置。

· 系统管理员(System Administrator)安装、配置、监控和调整JBI系统，提供设计好的集成服务。

· JBI组件开发者(JBI Component Developer)JBI组件可以由用户或是第三方来创建。无论谁来创建，JBI插件的开发者必须提供符合本规范定义的具体要求的Java组件。

1.2 基本原理与假设(Rationale & Assumptions)

本规范的基本原理立足于以下几个关键假设、经验数据、传闻和业务需求。

· J2EE™ 平台提供者越来越把Web服务作为中心而不是作为其产品所使用的辅助工具。

· Web服务标准的革命使得在服务集成领域越来越需要大量的新型开发人员，他们需掌握的将不再主要是过程化语言，而是新兴的标记语言。

· 能够支持服务合成语言，这主要是因为WSDL可以描述抽象业务消息的含义，尤其是WSDL所定义的消息。

· 建立规格化（业务）消息的通用抽象视图，可以将组件特定的应用程序模型（用于设计和开发业务逻辑）从支持这些逻辑的通信基础结构中剥离出来。

1.3 目标(Goals)

以下是本规范的基本目标：

· 为服务引擎和绑定组件的开发者建立一套标准的SPI，即JBI组件。

· 抽象的协议无关的消息交换(protocol-neutral Message Exchange)和规格化消息(Normalized Message [NM])。

· 提供一套标准的JBI组件间消息交换机制。

· 建立一个标准来封装JBI组件，并为这些组件部署服务。

· 定义一些管理监控挂钩（接口），用于以后开发针对各种特定问题域的标准工具。

· 提供服务引擎和绑定组件实现的复合型和多样性，不同的供应商可以发布服务引擎、绑定组件或二者兼具。这些组件之间能够进行可靠性交互，由这些组件（在JBI基础设施之上）构建的系统必须能够集中管理。

1.4 与其他规范和技术的关系(Relationship to other Specifications and Technologies)

JBI实现依赖于J2SE1.4或J2EE1.4。

JBI使用Web服务描述语言([WSDL2.0]和[WSDl1.1])作为服务描述语言，在WSDL2.0中，还作为插接式组件交互的基本模型。

交互使用基于XML的消息[XML1.0]。XML的处理遵循当前正在开发的JAX-RPC2.0模型[JAX-RPC2.0]，因此，JAX-RPC2.0和JBI之间的关系是不正式的；本规范将来的版本会制定它和JAX-RPC2.0之间的正式依赖关系。

JBI依赖于Java管理扩展(Java Management eXtensions JMX)[JMX1.2]。

JBI企业服务总线(Enterprise Service Bus[ESB])系统中定义了“服务容器”的概念。

1.5 角色(Roles)

一个功能完善的集成产品须发布一系列满足或超过标准JBI系统要求的关键组件。设计时，JBI对解决方案的多数必要元素是沉默的。例如，服务引擎应该被看作一个业务逻辑的容器，业务逻辑使用的词汇范围从有注释的Java™到XML（如XSLT），这些词汇不是JBI定义的。JBI假定在发布一个总体业务解决方案时，公共的底层对象扮演一些不同的角色。

1.5.1 引擎开发者(Engine Developers)

一个符合JBI规范的服务引擎(SE)实现需要实现规格化消息路由(Nomalized Message Router[NMR]).另外，SE开发者须实现组件生命周期和管理接口，并且必要的话还要实现一个部署接口。如果SE作为一个容器，SE开发者可能要提供用于简化特定的SE产品的工具。

1.5.2 绑定开发者(Binding Developers)

一个符合JBI规范的绑定组件(BC)实现的要求同SE。它们同SE主要的不同点在于，绑定组件使用的远程访问协议和提供的服务不同。

1.5.3 JBI系统提供者(JBI Environment Providers)

JBI兼容的系统的提供者须支持本规范指定的标准化接口。JBI系统可选择使用J2EE™1.4或更新的平台，但不是必须的。如果不支持J2EE，那么必须支持J2SE1.4或更新的版本。

JBI1.0兼容的系统必须支持至少一个WS-I Basic Profile1.1[http://www.ws-i.org/Profiles/BasicProfile-1.1.html]绑定组件的实现。

一个符合JBI规范的系统可选择发布一个服务引擎的实现，但不是必须的。

1.5.4 J2EE™平台提供者(J2EE™ Platform Providers)

J2EE™平台提供者可选择发布一个包括服务引擎、绑定组件和应用级工具的完整JBI系统。J2EE™平台提供者当前并不要求必须支持JBI。

1.5.5 JBI应用开发者(JBI Application Developers)

JBI应用开发者使用特定的SE和BC实现定义的词汇和工具，建模、设计、开发和部署业务组件。这样整个JBI系统变得与JBI应用程序开发者无关了。