业界正在广泛寻求解决 B2B 以及 EAI （企业应用集成）所存在问题的方案。这些方案不同于基于 JMS 手段的面向消息中间件技术和 Web 服务技术。本文简短地阐述了即将到来的与 SOA （面向服务体系）规范及 ESB （企业服务总线）基础架构有关的 JBI （ Java 业务集成）标准。
面向服务体系
SOA （面向服务体系）是近期推动应用和业务集成领域产生巨大飞跃的新技术之一。 SOA 定义了一系列详尽的体系规范、范例和实现应用程序间进行松散耦合交互的最佳准则。
SOA 基于定义明确的接口，促进多个应用程序间的松散耦合交互。服务的实现是独立的，且不依赖上下文信息以及其他服务的状态。服务间数据交换主要基于文本类型的格式，使用基于标准的消息模型。服务自身并不知道服务提供者和服务消费者之间传输级的通讯交互。
尽管不是强制要求，当今大部分流行的基于 SOA 的系统都利用了 Web 服务以及近似技术为服务间交互提供必要的管道管理。 WSDL （ Web 服务定义语言）扮演了主要的通讯模型角色； SOAP 扮演了消息承载协议、 HTTP 扮演了网络传输协议。当然，这并不意味着你必须利用上述技术实现基于 SOA 的系统。另外，有些术语之前就已经存在了，所以很多企业已利用类似的体系实现了系统的松散耦合交互。不管怎样，主要的不同点在于我们现在已经有标准协议、工具集和软件了，使面向服务体系更健全。
SOA 原则与面向对象范式、原则有着显著不同。主要不同在于服务间交互的接口被定义了更多面向数据的行为。一个孤立的服务也许会采用面向对象原则和技术，但是，服务之间的交互很少采用这些手段。相反，这些接口更适合于基于文档的交换。面向对象的行为是绑定数据，而面向服务从行为中分离数据。
企业服务总线
ESB （企业服务总线）为面向服务体系提供了基础架构。通过设计工具定义服务间交互和规则， ESB 为部署和发现服务提供了运行时环境。
在 ESB 的世界中，服务不会直接彼此交互。“ ESB 运行时”作为一个仲裁者在服务间松散的耦合它们。“ ESB 运行时”将实现协议绑定、消息传输、消息处理，等等。
一个服务总线将包括下列关键项：
为服务提供传输绑定
定义和发现已部署服务
在服务间基于规则的路由和编排消息
包括文档传递在内的增值服务等
大部分的 ESB 提供商基于自己的 SOA 提议来开放标准和技术，包括多种 Web 服务标准和协议。他们提供多种调用服务的传输绑定，包括 HTTP 、 FTP 以及 JMS 等等。大部分 ESB 用户利用 WS-BPEL （ Web 服务的业务流程执行语言）来了解已部署服务之间是如何实现业务流程的。 ESB 提供商同时也提供服务质量特性，包括容错、故障转移、负载平衡、消息缓冲等等。
Java 业务集成
JBI （ Java 业务集成）的提出是基于面向服务体系提倡的方法和原则，为了解决 EAI 和 B2B 若干问题的 Java 标准。当前版本（ 1.0 ）是 2005 年 8 月通过的 JSR （ Java 规范需求） 208 定案。商业和开源界都欢迎 JBI 成为他们 ESB 产品的集成标准。
基于仲裁者体系
JBI 定义了基于插件方式的架构，以便服务能融入“ JBI 运行时”环境。 JBI 提供了详细的接口，使服务能与“ JBI 运行时”环境交互。这些服务要为“ JBI 运行时”环境暴露接口，以便“ JBI 运行时”环境为服务路由消息。“ JBI 运行时”环境在部署在 SOA 环境中的服务间扮演仲裁者的角色。
在同一 JVM 中，“ JBI 运行时”核心主要包括如下组件：
组件框架：组件框架把不同类型的组件部署到“ JBI 运行时”。
归一化消息路由器：归一化消息路由器利用标准机制实现服务间消息交换。
管理框架：管理框架基于 JMX 进行部署、管理以及监控“ JBI 运行时”中的组件。
组件模型
JBI 在“ JBI 运行时”环境中定义了两种组件：
服务引擎组件：该组件负责实现业务逻辑和其他服务。服务引擎组件在其内部可使用多种技术和设计模式。服务引擎组件可提供数据传输和转换这种简单的基础服务，也可实现像 WS-BPEL 实例一样复杂的业务处理。
绑定组件：绑定组件主要为已部署服务提供传输级绑定。绑定组件有多种类型：
利用标准传输协议与外部系统进行远程通讯。
使已部署服务能在同一个 JVM 内部相互调用。
服务间可使用标准的 WS-I （ Web 服务协同工作组织）规范通讯。
JBI 的关键是分离服务引擎和绑定组件，以便业务逻辑不被下面的具体细节所干扰。这种方式促进了体系的灵活性和可扩展性。绑定组件和服务引擎组件在 JBI 内部都可以是服务提供者和 / 或服务消费者。
绑定组件和服务引擎组件为“ JBI 运行时”提供接口以便从“ JBI 运行时”接收消息。同样的，它们也利用 JBI 提供的接口来和“ JBI 运行时”通讯。
消息传输模型
JBI 利用消息传输模型分离服务提供者和服务消费者之间的耦合。消息传输模型利用了 WSDL 。 WSDL 用于描述暴露的服务引擎组件和绑定组件的业务处理。另外， WSDL 也用于定义抽象服务处理的传输级绑定。
JBI 架构中一个关键组件是 NMR （归一化消息路由器，也译作“正规消息路由器”）。 NMR 基于 WSDL 提供了主要的消息传输中枢， NMR 为部署在“ JBI 运行时”中的服务引擎组件和绑定组件间的消息传递提供松散耦合。服务需要有聚合业务处理的接口，每个业务处理由零个或多个消息组成。而一个接口有一个或多个传输级绑定。
“ JBI 运行时”利用归一化格式描述消息。一个归一化消息由以下部分组成：
消息属性
消息有效载荷
消息附件
利用 NMR ， JBI 规范为服务提供者和消费者的消息交换提供标准接口。 NMR 支持服务生产者和消费者之间单向模式和服务响应模式的调用。
管理
JBI 利用 JMX 实现运行时的服务安装、配置和监控。服务必须实现 JBI 接口集，以便这些服务在 JBI 环境中是可管理的。 JBI 环境必须提供一套 JMX MBeans 实现“ JBI 运行时”的管理。
“ JBI 运行时”环境允许服务引擎组件和绑定组件的相关操作如下：
安装组件：使组件接口可使用归一化消息路由器。
安装 artefact 组件：这将允许已部署的 artefacts 组件获得与已安装组件同样的机能。例如，可以部署一个“连接服务”来提供具体的数据库连接。
启动、停止服务以及进行相关服务分组。
JBI 为组件及 artefact 组件定义了标准的部署描述符以及打包模型。
角色
JBI 为基于 JBI 的端到端 EAI 解决方案定义了如下角色：
引擎开发者：引擎开发者提供遵循 NMR 和管理约束的服务引擎组件。
绑定开发者：绑定开发者提供遵循 NMR 和管理约束的绑定组件。
JBI 环境提供者： JBI 环境提供者为“ JBI 运行时”使用 J2EE 1.4 或 J2SE 1.4 或更新的平台提供支持。
J2EE 平台提供者： J2EE 平台提供者把“ JBI 运行时”作为提供应用程序服务的一部分。
JBI 应用程序开发者： JBI 应用程序开发者利用服务引擎组件、绑定组件以及 JBI 环境构建 JBI 应用程序。
结论
当今业界走向越来越开放的标准和规范， JBI 在使 Java 技术利用面向服务体系和 ESB 基础架构实现业务集成方面产生了巨大飞跃。像 Oracle 这样的商用产品提供商和 ServiceMix 这样的开源软件都把 JBI 作为了他们 ESB 方案的一部分。
关于作者
Meeraj Kinnumpurath 是位在 VOCA 有限公司（原来叫 BACS ）就职的 Java 架构师，这家公司是英国最大的票据交换所。他有 8 年的 Java 开发经验，主要从事企业应用程序开发。他已出版了一些 Java 、 J2EE 以及 Web 服务方面的书籍。
