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