[1]-- Preface

这里是JBI(Java商业集成)1.0规范的公开最终版本。

1.1 从草案公开后的改变(Changes Since the Public Draft Review)

下面是自2005年三月公开草案版本后变化摘要的清单。

※ 定义了用于脚本系统管理的Ant任务

The Ant tasks for scripted system management have been defined.

※ 添加了处理服务集成生命周期的管理任务

Management tasks for handling the service assembly life cycle have been added.

※ ClassLoader需求被重新定义为普通规则，不再是强制规则的CloassOrder层次结构

Class loader requirements have been restated as ordering rules, rather than a mandated class loader hierarchy

※ 添加了一个“self-first”的class loader代理选择

An option for "self-first" class loader delegation has been added

※ WSDL1.1能被服务提供着用于描述它们的服务

WSDL 1.1 can now be used by service providers to describe their services.

※ 支持端点(endpoint)的动态确定和创建

Dynamic endpoint resolution and creation are now supported.

※ 创建MessageExchange示例的方法被放在一个独立的MessageExchangeFactory类中，不再作为DeliveryChannel的一部分

Methods for creating MessageExchange instances have been put into a separate MessageExchangeFactory, rather than as part of the DeliveryChannel.

※ 添加了WSDL1.1的标准化规则

WSDL 1.1 normalization rules have been added.

※ 添加了发布包时的元数据支持

Connection metadata support has been added to deployment packaging.

[二] -- Introduction

2.1 Summary：

企业应用集成(EAI、Enterprise Application Integration)和B2B解决方案传统上需要使用非标准的技术来建立功能性系统。这种情况导致终端用户要么被提供这些技术的供应商锁住，要么创建他们自己的技术，每一种情况都有缺点。没有任何一个供应商可能全面覆盖EAI和B2B所用到的巨大功能域(成千上万的应用程序和协议要被支持)。这将集成技术的使用者放在对集成问题只能提供较少解决方案的境地，并需要付出巨大努力。

Enterprise application integration (EAI) and business-to-business integration (B2B) solutions have traditionally required the use of non-standard technologies to create functional systems. This has required end users to either “lock in” to a single vendor of such technologies, or create their own. Each approach has disadvantages. No single vendor can cover the vast functional space of EAI and B2B (consider the thousands of applications and protocols to be supported). This leaves users of integration technologies in the uncomfortable position of selecting less than ideal solutions to their integration problems, and paying dearly for them.

JBI寻求通过为集成解决方案建立标准的架构来解决这一问题。这种构造允许第三方组件以插件的形式插入到标准的框架中，并允许这些组件以可预测的、可信的方式交互而无需考虑这些组件被不同供应商提供。Java™ Business Integration (JBI) seeks to address this problem by creating a standards-based architecture for integration solutions. This infrastructure allows third-party components to be “plugged in” to a standard infrastructure, and allows those components to interoperate in a predictable, reliable fashion despite being produced by separate vendors.预期中，这种交互的能力将建立一个多供应商的“生态系统”,引起被终端用户发起的集成相关技术的集中。此外这个“生态系统”将在集成技术领域引发新的创新，因为它使得创新者能够专注于某一特定的技术或者问题域，而不必担心建立一个完全的集成解决方案所需要提供的所有其它方面的东西。It is anticipated that this ability to interoperate will create a multivendor “ecosystem” which will give rise to large pool of integration-related technologies that can be sourced by end users. In addition, this ecosystem will foster new innovations in integration technologies, since it will permit innovators to concentrate on a particular technology or problem area, without having to worry about providing all the other pieces needed to build a complete integration solution.

集成时遇到的问题各有不同，一个合适的JBI规范的组件组合将提供提供量体裁衣的解决方案。通过避免局限于某一特听集成技术的供应商，用户能够自由选择提供特定功能的组件，而且能够确保这个解决方案能够同其它部分集成。

Every integration problem is unique; an appropriate combination of JBI-compliant components will provide a solution that is sized appropriately to the problem at hand. By avoiding lock-in to a particular vendor of integration technologies, the user is free to choose components that provide the particular functions that he or she needs, and be assured that a functional integration solution can be assembled from those pieces.

在过去，试图集成第三方组件到系统中需要有企业系统所要求的特性。JBI通过采用service-oriented architecture（SOA）实现这一特性，最大化的降低了组件之间的耦合，并且基于标准信息建立了定义良好的交互语义。SOA的方式还拥有其它的适合企业集成解决方案的优点。

In the past, attempts to compose third-party components into systems that have the attributes required of enterprise systems have not been very successful. JBI addresses this by adopting a service-oriented architecture (SOA), which maximizes the decoupling between components, and creates well-defined interoperation semantics founded on standards-based messaging. The SOA approach creates many other benefits that are applicable to enterprise integration solutions.

EAI：Enterprise Application Intergration

B2B：Business to Business

SOA：service-oriented Architecture

2.2 Scope

JSR208（JBI）专家组由大量商业方面的工程师和设计者组成，本规范反应了他们的biases、priorities、requirements和experiences。总体而言，本规范定位于商业解决方案提供者的需要。

本规范可以看为是一个完全对J2EE平台无偿奉献的规范。JBI不需要J2EE平台的支持，依赖于J2SE平台。如果将来J2EE平台包含次规范，无需做任何额外的事情。

2.3 读者群体（Target Audience）

本规范的主要读者是要开发以下内容的系统级软件工程师

• JBI基础结构的实现
  implementations of the JBI infrastructure itself
• 提供以下功能的插件组件
  the “plug in” components that provide
• 通信协议支持
  communications protocol support
• 商业逻辑
  business logic
• 交换引擎
  transformation engines
• 智能信息路由
  intelligent message routing

等等

本规范并不适合应用程序开发者和商业分析师。希望本规范能够简化标准服务组合工具的开发和针对特定服务的开发。

It is hoped that this specification will facilitate the development of standard service composition tools and services targeted specifically at this group.

2.4 文档结构(Organization)

本文档的结构为，在开始的章节介绍了一些关于JSR208的内容和基本原理。后来的章节根据不同用户的需要提供了描述Application Programming Interface(API)和Service Provider Interfaces的相关例子。

2.5 约定(Conventions)

本文档中出现的关键字MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, OPTIONAL的解释见RFC2119。

2.6 专家组(Expert Group)

包括Apache、Oracle、Fujitsu、JBoss、SAP、Sun的一些专家，好像还包括一个华裔。

2.7 文档状态（Status of this Document）

本规范是JBI1.0的最终版本。本规范伴有一个RI(Reference Implementation)，RI提供一个本规范的操作定义和一个TCK(Technology Compatibility Kit)。TCK验证一个实现是否符合本规范。注意RI和TCK遵守本规范不同的许可协议。

This specification is the “Final Release” version of JBI 1.0. It is accompanied by a Reference Implementation (RI), which provides an operational definition of this specification, and a Technology Compatibility Kit (TCK), which verifies if an implementation conforms to this specification. Note that the RI and TCK are subject to different licensing terms than this specification. See http://java.sun.com/integration for details.

[3]——概述

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应用程序开发者无关了。

许多这样的开发者开发XML artifacts来定义服务引擎和绑定组件。这不是传统的重点放在代码编写的J2EE和J2SE领域开发者的工作模式。