JBI规范.docx

该文来自：/Juset/category/263747.aspxJBI简介JBI（Java Business Integration，Java业务集成，Java业务整合）即JSR 208是一种企业服务总线(Enterprise Service Bus,ESB)，使我们能够用Java实现面向服务的架构。企业正转向以面向服务架构（SOA）和网络服务，以提供灵活的IT系统，用一种成本低廉的方式来支持快速变化的商业需求。 JBI的主要目的是提供一个基于服务的平台作为对现有Java/J2EE平台功能的扩展。下面就是它所使用和定义的术语和模式： 绑定组件：理解特定的协议并能够将其转化为一种标准或常见的系统级协议的软件组件。它们用作系统的入口点和出口点。也称为适配器。 服务引擎：负责处理请求（通常通过转换的手段）的软件组件。例如，XSLT转换程序、BPEL引擎、规则引擎等等。 消息交换：消息交换协议。常见的交换模式有请求-响应、in-only等等。 组建安装：静态或动态地向运行时环境添加可执行的软件组件。 服务部署：静态或动态地向已安装的组件添加可执行的服务（或应用程序）。 服务程序集：一组服务。 标准是用来实现互操作性和可移植性的，但是它们在方便通信方面的重要性也不可忽视。在JavaOne大会上已经能够听到相当数量的关于JBI的谈论了，而且我们也会在近期内首次发布一个开源JBI容器和组件套件ServiceMix，这一切都相当令人高兴。我不清楚是不是所有的人都对JBI有了一定的了解，因为在JavaOne大会上一些关于JBI的讨论中，我看到某些与会者脸上流露出困惑的表情。我想我们需要一些文章来解释一下什么是JBI、其重要的思想是什么，以及如何使用JBI。首先，可以简要的将JBI描述为一个用于规范化信息服务和路由器的简单API，这个API包含了一些用于部署集成服务的组件和管理模型。这里指的需要部署的集成服务主要包括路由引擎、BPEL引擎、角色系统或传输引擎等等。JBI提供了一个合理的XML信息传输网络，通过这个网络对HTTP、电子邮件和JMS/MOM等进行良好的映射，使得这种网络能够方便地应用在现有的遗留系统、二进制传输和RPC系统（例如EJB或CORBA）之中。你可以把它想象成在JMS之上的逻辑抽象层，支持多种不同的消息交换机制（例如传统的“请求与应答”方式）。绑定组件（binding components）处理和所有的传输管道以及协议相关的内容，然后由工作在逻辑XML层的服务引擎组件（service engine components）提供基于路由、控制、规则、传输或自定义增强功能的内容。这样一来，BPEL引擎就不用再处理所有可能用到的协议、传输设备及线缆格式了，这些工作可以全部交给JBI来做，JBI会为物理路由或服务终端点完成这些工作。与此类似，基于内容的路由器、规则引擎、传输引擎也可以搭乘JBI这班车，自己则完成自己分内的工作。基于这点，我认为JBI是一套很棒的适合集成组件开发者的API。当然，很多应用程序开发者仍旧喜欢开发POJO服务、把这些服务放到自己的容器中，然后以Web services的形式进行应用，在这种情况下他们也许不会直接使用到JBI API。但是，JBI提供了一种使得中间件、集成厂商和OSS项目能够在ESB级别共同协作运行的方法，这种方法对于像我们公司这样的集成组件开发公司而言是非常有意义的。JBI规范1.03概述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)的环境中。这些组件可为来自第三方的终端用户所用，尤其在应用系统集成时遇到问题时，它们可以提供一些通用的或标准的功能。这些组件可以分为两种不同的类型：1. 服务引擎（Service Engine SE）-服务引擎既为其他组件提供了业务逻辑和数据转换服务，同时也消费这些服务。服务引擎可以集成基于Java的应用（和其他资源）或提供了Java API接口的应用。2. 绑定组件（Binding Component BC）-绑定组件为JBI环境以外的服务提供了连通性，这些外部的服务可能包括通信协议或企业信息系统(Enterprise Information System)提供的服务（EIS资源）。绑定组件可以集成使用Java环境不能提供的远程访问技术的应用（或其他资源）。3. 服务引擎和绑定组件可以是服务提供者，服务消费者或两者兼具。服务引擎和绑定组件基于合理的架构原则，但两者之间的差别完全由实际应用决定。把业务处理逻辑同通信逻辑分离降低了实现的复杂度并提高了灵活性。4. JBI不仅为消息系统提供了组件互用性，同时也定义了一个基于JMX(Java Management eXtensions)的管理框架。JBI为以下功能提供了标准的管理机制：l 组件的安装l 组件生命周期的管理（启动/停止等）l 组件服务描述信息（Service Artifacts）的部署最后要说明的一点是，JBI组件也可以看作一种容器，通过部署服务描述信息添加新的服务消费者或服务提供者逻辑。例如，一个提供基于XSLT转换服务的服务引擎可以部署XSLT样式表，从而添加新的转换操作。这种为特定组件添加功能服务描述信息的过程称为“部署”（Deployment），用于区分组件的安装。JBI将一组部署描述信息及其相关的元数据的集合称为服务集合（Service Assembly）。这些服务描述信息及其关联元数据集在一些文献中称为合成服务描述符（Composite Service Description CSD）。1.1定义(Definitions)JBI定义的不是一个传统的应用程序模型，相反地， JBI通过将插接组件抽象为服务提供者和服务消费者而与面向服务的架构紧密结合来构建企业应用。开发人员使用该规范中定义的APIs和SPIs开发插接到JBI环境中的服务引擎和绑定组件。服务引擎（SE）是指提供业务逻辑处理，数据转换服务等的插接组件。服务引擎根据其提供的功能可以有多种形式。特别的，一些SE可作为处理容器，为用户提供特定的开发模型，例如：l 一个XSLT XML转换引擎可以支持多种转换形式，应用开发接口就是XSLT语言本身；l 对于一个WS-BPEL 2.0业务处理执行引擎，应用开发接口就是WS-BPEL；l 对于一个EJB容器，API就是符合特定EJB规范的Java。绑定组件通过提供通信协议处理功能，使得JBI组件可以访问JBI环境以外的外部系统提供的远程服务，同时外部远程服务消费者可以访问JBI环境内部提供的服务。通信协议可以根据系统集成需求的不同而不同，典型的例子包括：l 基于HTTP的SOAP/Profiles/BasicProfile-1.1.html；l JMS/MOM/aboutJava/communityprocess/final/jsr914/index.htmll AS1/AS2 EDI /html.charters/ediint-charter.html通信协议栈。一个绑定组件可能会选择实现一种或多种通信协议，提供到SE的连通性服务，使SE把它们的服务发布给远程消费者，同时它们也消费远程服务。JBI的各种用户可以扮演几种不同的角色：l 集成架构师(Integration Architect)设计解决系统集成问题的整体思路，包括选择提供连通性和业务逻辑的JBI组件。l 集成技术员(Integration Technologist)设计解决某个集成问题的具体服务，并对这些服务在JBI系统中的集成进行配置。l 系统管理员(System Administrator)安装、配置、监控和调整JBI系统，提供设计好的集成服务。l JBI组件开发者(JBI Component Developer)JBI组件可以由用户或是第三方来创建。无论谁来创建，JBI插件的开发者必须提供符合本规范定义的具体要求的Java组件。1.2基本原理与假设(Rationale & Assumptions)本规范的基本原理立足于以下几个关键假设、经验数据 、传闻和业务需求。l J2EE 平台提供者越来越把Web服务作为中心而不是作为其产品所使用的辅助工具。l Web服务标准的革命使得在服务集成领域越来越需要大量的新型开发人员，他们需掌握的将不再主要是过程化语言，而是新兴的标记语言。l 能够支持服务合成语言，这主要是因为WSDL可以描述抽象业务消息的含义，尤其是WSDL所定义的消息。l 建立规格化（业务）消息的通用抽象视图，可以将组件特定的应用程序模型（用于设计和开发业务逻辑）从支持这些逻辑的通信基础结构中剥离出来。1.3 目标(Goals)以下是本规范的基本目标：l 为服务引擎和绑定组件的开发者建立一套标准的SPI，即JBI组件。l 抽象的协议无关的消息交换(protocol-neutral Message Exchange)和规格化消息(Normalized Message NM)。l 提供一套标准的JBI组件间消息交换机制。l 建立一个标准来封装JBI组件，并为这些组件部署服务。l 定义一些管理监控挂钩（接口），用于以后开发针对各种特定问题域的标准工具。l 提供服务引擎和绑定组件实现的复合型和多样性，不同的供应商可以发布服务引擎、绑定组件或二者兼具。这些组件之间能够进行可靠性交互，由这些组件（在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 BusESB)系统中定义了“服务容器”的概念。1.5角色(Roles)一个功能完善的集成产品须发布一系列满足或超过标准JBI系统要求的关键组件。设计时，JBI对解决方案的多数必要元素是沉默的。例如，服务引擎应该被看作一个业务逻辑的容器，业务逻辑使用的词汇范围从有注释的Java到XML（如XSLT），这些词汇不是JBI定义的。JBI假定在发布一个总体业务解决方案时，公共的底层对象扮演一些不同的角色。1.5.1引擎开发者(Engine Developers)一个符合JBI规范的服务引擎(SE)实现需要实现规格化消息路由(Nomalized Message RouterNMR).另外，SE开发者须实现组件生命周期和管理接口，并且必要的话还要实现一个部署接口。如果SE作为一个容器，SE开发者可能要提供用于简化特定的SE产品的工具。1.5.2绑定开发者(Binding Developers)一个符合JBI规范的绑定组件(BC)实现的要求同SE。它们同SE主要的不同点在于，绑定组件使用的远程访问协议和提供的服务不同。1.5.3JBI系统提供者(JBI Environment Providers)JBI兼容的系统的提供者须支持本规范指定的标准化接口。JBI系统可选择使用J2EE1.4或更新的平台，但不是必须的。如果不支持J2EE，那么必须支持J2SE1.4或更新的版本。JBI1.0兼容的系统必须支持至少一个WS-I Basic Profile1.1/Profiles/BasicProfile-1.1.html绑定组件的实现。一个符合JBI规范的系统可选择发布一个服务引擎的实现，但不是必须的。1.5.4J2EE平台提供者(J2EE Platform Providers)J2EE平台提供者可选择发布一个包括服务引擎、绑定组件和应用级工具的完整JBI系统。J2EE平台提供者当前并不要求必须支持JBI。1.5.5JBI应用开发者(JBI Application Developers)JBI应用开发者使用特定的SE和BC实现定义的词汇和工具，建模、设计、开发和部署业务组件。这样整个JBI系统变得与JBI应用程序开发者无关了。许多这样的开发者开发XML artifacts来定义服务引擎和绑定组件。这不是传统的重点放在代码编写的J2EE和J2SE领域开发者的工作模式。JBI规范1.04系统架构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）：使用抽象消息模型定义的，未限定到特定消息交换协议的服务 具体（限定）模型（Concretebound 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服务描述中抽象服务模型的定义如下：1) 抽象消息类型（Abstract Message Type）：消息类型定义了合法的消息结构和约束，一般通过XML Schema来表示。消息分为两类：常态消息（normal）和故障消息（fault），常态消息是指服务正常处理过程中的消息，故障消息用于描述非正常的处理条件。 2) 抽象操作（Abstract Operation）：与某种服务进行交互时的一次操作，该服务由服务消费者和提供者间交换的常态（或故障）消息来定义。抽象操作定义如下： 3) 操作名称（Operation Name）：定义操作的限定名 4) 消息交换模式MEP（Message Exchange Pattern）：消息（包括常态消息和故障消息）在消费者和提供者之间传递的顺序、方向和基数（Cardinality） 5) 消息类型（Message Types）：MEP中的消息的类型 6) 抽象服务类型（Abstract Service Type）：一组相关联的抽象操作（Abstract Operation）的集合。在WSDL2.0中抽象服务类型用术语“接口（interface）”表示，在WSDL1.1中用术语“端口类型（portType）”表示，本规范中沿用“接口”术语。注意不要同Java语言中的接口混淆。抽象服务类型即接口定义如下： 接口名称（Interface Name）：用于标识服务类型的全局限定名，在JBI中接口名称还用来指明服务类型； 扩展的接口（Extended Interface）：扩展了其他服务类型的服务类型，类似于Java中的接口类型。一个服务类型可由其他几个服务类型组成。1.1.2 具体服务模型(Concrete Service Model)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）。1.2 规格化消息(Normalized Message)规格化消息（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 RouterNMR），它提供用于消息交换和组件交互的基础设施。此外，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系统成为一个完整而可靠的运行环境。1.4 规格化消息交换(Normalized Message Exchange)JBI系统的首要功能是将规格化消息交换（ME）从一个组件路由到另一个组件。交换的消息使用一种规格化的形式。绑定组件必须将绑定的消息（特定协议和传输格式的消息）转换成规格化形式。绑定组件和服务引擎通过传输通道（Delivery ChannelDC）与NMR交互，传输通道为消息的接收和分发提供了双向传输的契约。图5 外部服务消费者消息处理视图如图所示，一个外部服务消费者通过特定协议和传输器发送一个服务请求到绑定组件，绑定组件将请求转换成规格化消息。然后，绑定组件根据NM构建消息交换（Message ExchangeME 是WSDL消息交换模型中各种简单消息交换模式中消息的容器），绑定组件设定描述将要执行的服务和操作的元数据信息，最后，在步骤2中，绑定组件将消息交换通过传输通道（DC）发送给NMR，NMR将消息交换分发到服务提供者。上述过程中，由NMR选择合适的服务提供者，然后把消息交换(ME)路由到合适的服务提供者。服务提供者必须从传输通道中主动接收（pull）消息交换。相反的操作图6所示，只在绑定组件处与图5有少许不同。图6 外部服务提供者消息处理视图如图所示，一个消费者（SE/BC）创建一个规格化消息NM并将其放入一个新的消息交换(MessageExchange)中.该消息交换的地址被设定为一个服务端点（ServiceEndpoint），服务引擎未指定用哪一个组件来处理该服务请求。消息交换的发送和接收同前例所示。绑定组件接收到ME后将规格化消息转换为与协议和传输相关的格式，并将其发送给外部服务提供者。1.5 管理(Management)JBI系统（包括绑定组件和服务引擎）通过JMX进行管理。本规范定义了若干管理Bean（MBean）类型，为JBI系统和插接组件提供了一致的管理环境。管理接口支持的主要功能如下： 组件（服务引擎和绑定组件）的安装 组件的生命周期管理（启动/停止等） 组件服务描述信息（Service Artifacts）的部署。组件描述信息支持在内部运行环境中动态添加新的内容。例如，SE是一个XSLT引擎，要安装到容器中的新XSLT样式表就是服务描述信息。 监控和管理1.5.1 组件安装(Component Installation)服务引擎和绑定组件必须通过管理接口进行安装。本规范中动词“安装（install）”指提供组件基本功能的二进制文件及相关资源的安装。安装（install）不同于部署（deployment），部署指根据特定的应用为组件运行添加相关的描述信息，从而定制组件的行为。例如，一个XSLT转换引擎安装后，可以通过部署特定的转换样式表（.xsl文件）使转换引擎提供所需的转换服务。1.5.2 生命周期管理(Life Cycle Management)引擎或绑定组件一旦安装，就可以使用本规范定义的MBean接口启动或停止该组件。该类控制称为生命周期管理。1.5.3 服务单元部署(Service Unit Deployment)如上所述，部署是指为安装的引擎或绑定组件提供与组件功能相关的资源。这些资源称为服务单元（Service Units）。本规范未对服务单元的内容作任何说明，其对JBI来说是不透明的。服务单元组合成一个聚合的部署文件称为为服务集合（Service Assembly）。服务集合包含一个部署描述符，用于指明每个服务单元所要部署到的目标组件。1.6 组件框架(Component Framework)JBI组件框架为绑定组件及服务引擎提供了一套可插拔的接口用于与JBI系统进行交互。该框架为所有的JBI操作服务提供接口。组件与JBI之间的交互有两种机制：SPIs（Service Provider interfaces）和APIs（Application Programming interfaces）。SPIs是绑定组件或服务引擎实现的接口；APIs是组件框架向绑定组件和服务引擎发布的接口。组件框架和组件之间的交互契约在“组件框架”和“格式化消息路由”章节进行详细描述。该契约定义了JBI系统中为达到特定的功能目标，组件框架和JBI组件各自应承担的职责。1.7 规格化消息路由(Normalized Message Router)规格化消息交换的传输依赖于规格化消息路由（NMR）在服务消费者和提供者之间路由。NMR能够根据消息自身的特性和应用系统的需求支持不同服务品质（QoS）的消息传输。根据绑定组件和服务引擎协作的需要，NMR支持的QoS包括： 最大努力（Best effort）：消息可能被丢弃或分发多次 最少一次（At least once）：消息不可能被丢弃，但存在重复发送 仅有一次（Once and only once）：消息保证只发送一次详见“规格化消息交换”一章。1.8 组件(Components)JBI支持两种组件：服务引擎和绑定组件。这两种组件的模型及API定义是一样的，JBI只是通过一个标记来区分这两种组件。实际上，JBI中服务引擎和绑定组件实现不同的功能。（这种区分同样适用于JBI定义的管理接口）1.8.1 服务引擎(Service Engines)服务引擎（SE）在JBI系统中表现为业务逻辑驱动。引擎可以编排服务的消费和提供，例如一个长时间的业务处理进程既可以提供服务同时自身也消费服务。服务引擎可以提供简单的服务，如数据转换；也可以提供复杂的路由或EDI服务如消息校勘/反校勘（collation/de-collation）。服务引擎可以通过聚合其他服务来构造新的服务。WS-BPEL语言正是使用的这种重要的合成模式，通过多个服务构造复杂的处理过程。1.8.2 绑定组件(Binding Components)绑定组件用于根据特定协议和传输器发送和接收消息。绑定组件把消息在特定于协议的格式和规格化格式之间进行转换，使JBI系统只需处理规格化消息，从而把JBI系统与特定协议分离。（注意，特定于协议的相关信息可以用规格化消息或消息交换的元数据信息表示，供服务引擎或者绑定组件使用，这些元数据信息对其他的JBI系统组件是不透明的。）1.9 举例(Examples)下面的例子演示了如何使用JBI系统和组件来完成典型的系统集成任务。1.9.1 单向消息适配(One-way Message Adapter)在这个场景中，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（单向）。JBI规范1.05规格化消息路由1 规格化消息路由(Normalized Message Router)规格化消息路由（NMR）从JBI组件（服务引擎或绑定组件）接收消息交换并将其路由到适当的组件进行处理。这种中间消息交换处理模型把服务消费者和提供者分离，并允许NMR在消息交换的生存周期中可以执行一些附加的处理。注意，本章中使用WSDL2.0中的术语而不是WSDL1.1。1.1 关键概念(Key Concepts)本节介绍NMR架构中的几个关键概念。NMR的目标是允许组件之间以服务提供者和服务消费者的身份，使用基于WSDL的服务描述彼此交互。这是组件可以进行混合匹配（mix-and-match）装配、构造集成解决方案和服务基础的关键。WSDL WSDL 2.0, WSDL 1.1为JBI组件的交互提供了基本模型和描述机制。WSDL提供了一个基于XML消息交换操作的抽象服务模型，该模型可以通过扩展提供特定的绑定信息：将抽象模型映射到实际的通信协议和端点WSDL 2.0 bindings 的特定的协议信息。JBI扩展应用了WSDL的抽象消息模型，可以把NMR看作是一个抽象的WSDL消息系统基础平台infrastructure，绑定组件和服务引擎在这个平台上提供和使用WSDL定义的服务。WSDL定义了一项服务提供者和消费者之间的消息交换操作，消息交换的参与者依照各方都能理解的一种消息交换模型进行操作。一组相关联的操作称作“接口”（WSDL1.1中称为端口类型）。一个“服务”实现这样的一个“接口”。一个服务具有一个或多个端点，每个端点通过一种特定的绑定（消息通信协议）为外部系统访问该服务提供入口。所有的这些WSDL概念都被JBI用于在APIs和SPIs中构建服务模型。1.1.1 服务的消费者和提供者 (Service Consumers and Providers)JBI引擎和绑定组件可以作为服务消费者，服务提供者或两者兼具。服务提供者通过端点（endpoint）提供WSDL描述的服务；服务消费者发送消息交换调用特定的操作来使用服务。服务（service）实现了WSDL接口，WSDL接口是通过交换抽象定义的消息来描述的一组相关的操作。服务消费者和服务提供者之间通常只共享抽象的服务定义而不是具体的端点信息，因而两者之间是松耦合的。这种结构把服务的消费者同特定的服务提供者实现（如特定协议）分离开来。一个WSDL接口可以具有多个服务实现，服务消费者在查找实现了某个接口的提供者时，可能会查找到多个实现了该接口的服务提供者（服务和相关联的端点）。1.1.2 规格化消息(Normalized Message)JBI使用“规格化（normalized）”消息的概念描述服务消费者和提供者之间的交互。一条规格化消息由以下三个主要部分组成： 消息载荷（payload）：符合抽象WSDL消息类型，不具有任何协议编码或格式信息的XML文档（这不是一个消息的规范格式）。 消息属性（或元数据）：包含了在消息处理过程中获得的与消息相关的额外信息。消息属性可以包含消息的安全信息（例如消息接收方的签名信息），事务上下文信息和组件特定的信息。消息附件：消息载荷（内容）的一部分可以由附件构成，附件由消息载荷来引用，并且附件中包含一个可以操作附件内容的数据处理器。这些附件可以是非XML格式的。 规格化消息通过抽象WSDL消息类型定义为组件间的交互提供了互操作。1.1.3 传输通道(Delivery Channel)传输通道（DeliveryChannel）是绑定组件和服务引擎与NMR之间通信使用的双向通信管道。传输通道构成了服务消费者，提供者和NMR之间的交互契约，即API接口。服务消费者使用传输通道开始服务调用，服务提供者使用传输通道从NMR接收服务调用。既作为服务提供者又作为消费者的组件使用同一个传输通道完成这两种功能。以一个绑定组件接收JBI系统外部的服务消费者的请求为例，当接收这种传入的服务调用请求后，该绑定组件通过其传输通道与NMR交互时必须扮演服务消费者的角色（在此用例中，绑定组件可以看作是一个服务消费者的代理）。每个组件都具有唯一的一个传输通道，因此传输通道的实现必须支持在多线程环境下的并发使用。1.1.4 运行时端点激活(Run-time Endpoint Activation)运行时激活是服务提供者激活其提供的实际的服务的过程。在该过程中，服务提供者将其提供的服务通知NMR，这样NMR可以将服务调用路由到该服务。端点激活分为两步： 向NRM声明一个服务端点 提供描述该端点定义的元数据信息向NRM声明一个服务端点是绑定组件或服务引擎向NMR激活一个端点名称的过程。在NMR中声明的端点名称必须有相应的元数据信息详细描述该端点的注册，这部分详细信息通过使用SPI来提供。1.1.5 服务调用和消息交换模式(Service Invocation and Message Exchange Patterns)服务调用指服务消费者和服务提供者之间的一个端对端交互的实例。尽管无法在JBI中定义一套完整的服务调用模式，但是JBI实现必须支持以下列表中的交互模式： 单向交互（One-Way）模式：服务消费者向提供者发送一个请求，服务提供者不必向消费者返回任何错误（故障）信息。 可靠的单向交互（Reliable One-Way）模式：服务消费者向提供者发送一个请求。如果服务提供者处理该请求失败，会向消费者返回出错信息。 请求-回复（Request-Response）模式：服务消费者向提供者发送一个请求，并期望服务提供者响应。如果处理请求失败则返回出错信息。 请求-选择回复（Request Optional-Response）模式：服务消费者向提供者发送一个请求，并期望服务提供者响应。消费者和提供者接受到一个消息后，都可以选择是否应答。上述提到的消费者和提供者角色可能是绑定组件也可能是服务引擎。当一个绑定组件作为服务消费者时，说明存在一个外部的服务消费者；同样，当一个绑定组件作为服务提供者时，说明存在一个外部的服务提供者。当服务引擎作为服务提供者或消费者时，说明该服务引擎是一个内部参与者。WSDL 2.0预定义扩展WSDL 2.0 Extensions定义了一个消息交换模式（MEP）作为“一个操作中的所有抽象消息的顺序和基数”。JBI使用该模式定义消费者节点和提供者节点之间的交互。该模式根据消息类型（normal或fault）和消息流向来定义。MEPs总是以提供者的角度来理解。例如，在请求-回复交互模式中， MEP的定义是in-out，其消息流从提供者的角度来看，请求（Request）是输入（in），回复（Response）是输出（out）。从服务消费者的角度看，消息流的方向正好相反，但是NMR在与服务消费者交互过程中使用的MEP总是从服务提供者的角度来说的。当处理WSDL MEPs时，这是一种惯用的处理方式。In-Out模式示意图如图8所示：图8 In-Out消息交换模式如图所示，第一条消息（请求）从消费者发送到提供者，从提供者的角度看其方向是输入（in）。第二条消息（回复）是从提供者到消费者，即输出（out）。这些交换是按给定的顺序执行的，从提供者的角度这种交换首先是输入一条消息（in），跟着是输出（out）一条消息，因此这种交互模式命名为输入输出（in-out）模式。1.1.6 消息交换(Message Exchange)消息交换（ME）作为规格化消息的“容器（container）”。ME不仅封装了其实现的消息交换模型中的输入（in）消息和输出（out）消息，它还包含了这些消息的元数据信息以及正在进行的消息交换的状态信息。消息交换代表了JBI本地服务调用的一部分。下表说明了服务调用和消息交换模式之间的关系。表 2 服务调用与MEP的映射图9 两服务引擎之间的单向服务调用上图描述了两个本地服务引擎间的单向服务调用，包括了一个消息交换实例：SE1作为一个服务消费者，通过创建并初始化一个包含了消息请求的in-only消息交换来调用所需要的服务操作。如图中SE1和NMR之间的对象流所示，SE1将该消息交换实例发送到NMR。NMR决定由哪一个服务提供者提供所请求的服务操作，并把该消息交换实例传输给选定的提供者。在图中表示为NMR到SE2的对象流。注意，该图示并不意味着调用者必须在交换完成之前阻塞当前线程的执行。调用方在发送和接收消息交换时，调用者可以是事件驱动的，服务引擎的内部状态的前进不必占用着线程资源不放。图10 SE调用远程JBI实例提供的服务：Robust In With Fault下面描述图10所示的处于两个不同的JBI环境中的服务引擎之间的可靠的单向调用。注意，规范中未规定如何“联合（federating）”两个分离的JBI实例，该例中两个JBI实例之间通过BC1和BC2提供的通信协议使得两者作为远程的消费者和提供者而相互可见，并不存在影响两者之间服务调用的特殊关系。SE1构建并初始化了一个可靠的单向（robust-in）消息实例，并发送到NMR（在构建ME实例的过程中，NMR为该实例设定了一个唯一标识“X”）。NMR选择合适的服务提供