业界正在广泛寻求解决
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
服务方面的书籍。
请注意！引用、转贴本文应注明原译者：Rosen Jiang 以及出处：
http://www.blogjava.net/rosen