JBI （ Java ™ Business Integration ）是一种企业服务总线 (Enterprise Service Bus,ESB) ，用于形成一种关键基础设施片段，使我们能够用 Java 实现面向服务的架构，主要目的是提供一个基于服务的平台作为对现有 Java/J2EE 平台功能的扩展。

当前的 J2EE 部署都运行在一个基础上，那就是应用服务器。应用服务器本身由两个独立的部分组成 ——Servlet 容器和 EJB 容器，它们分别用于部署 JSP/Servlets 和 EJB 构件。在它们中的任何一个，你都能使用 Web services 。但是，在任何环境中以分散的方式使用 services 是很困难的工作，而 JBI 的目的就是为完成这个任务提供一个专门的环境。其最底层是一个容器，它与 J2EE 中的容器一样定义了自身的部署构件。

JBI 提供了一种正规消息路由器 (Normalized Message Router,NMR) ，说白了，就是一个地点。在这个地点，所有基于消息的数据片段 ——SOAP 片段、 MOM 消息、 HTTP 数据或其它信息 —— 被聚合、集中、应用到业务逻辑、传输，如果有必要则被转换成其它格式并随后被分派到最终目的地。

　　 JBI 很适合企业级应用，因为它通过一种总线型架构的基于消息的手段到达了适应大范围的消费者和提供者的目的。现在，让我们看看除了 NMR 还有什么构成了 JBI 。

和 JBI 环境直接交互的是两个部分， JBI machine 和 JBI binding 。 JBI machine 定义了部署构件以及在环境中管理它们的方式。本质上，它是提供商设计的黑盒，用于在 JBI 中支持他们自己的模型。另一方面， JBI binding 则被环境通过专门的业务协议与外部世界进行通信。

JBI 是提供了一些简单的 API 定义， 这些定义包括 NormalizedMessage Service , 在一个 Router 组件，以及一个管理模型用来管理服务的部署集成，例如 routing engines, BPEL engines, rule systems, transformation engines

JBI 提供了一个逻辑的 XML 消息网络， 这一网络能够很容易的映射到 HTTP, email 和 JMS/MOM ，并很方便地适应遗留系统，二进制地传输，和 RPC 系统（ EJB 和 CORBA) 。 JBI 可以看做是对 JMS 的更高层次的逻辑抽象，并提供了不同的消息交换方式（ 单步， 请求应答等）

2 、 SCA

服务构件架构 SCA （ Service Component Architecture ）致力于为使用广泛的编程语言来构造服务构件提供一种编程模型，并且也为把这些服务构件组装为一个业务上的解决方案提供了一种模型，这种组装的活动正是采用面向服务的架构 (service-oriented architecture) 来搭建应用系统的核心。   

SCA 为建设基于面向服务的体系结构的应用和系统提供了一种编程模型。这基于一种观点，即业务功能以一系列服务的形式被对外提供出来，然后它们被组合在一起去实现满足特定业务需求的解决方案。这些复合的应用，可以包含专门为此应用程序创建的新服务，也可以包含来自已有的系统和应用程序的业务功能，重复利用就像其中的一部分一样。 SCA 即为组合服务提供了模型，也为服务构件的创建，包括在 SCA 组装中重用已有应用系统的功能提供了模型。

在服务定义中， WSDL （ Web Service Description Language ）是一个很好的范例。 WSDL 在增强应用之间的可连接性以及互操作性方面迈出了一大步。然而， WSDL 只关注了服务接口，它并不提供描述一个服务所依赖的其它服务，以及这个服务所需要使用的配置策略和服务之间的依赖关系。单独通过 WSDL 很难实现服务之间的组合调用。

SCA 比 WSDL 走的更远的方面是定义了一个服务组件模型以及一个服务组装模型。服务模型提供了比 WSDL 更多的功能，它允许服务开发者不单定义服务的接口而且还可以定义 这个服务和其他服务的依赖关系，以及这些交互（事务，安全，以及可靠 传输）之间的策略 还有服务所可能提供的配置功能。

一个 SCA 模型对等于一个 SOA 项目，模型允许开发者组装一组服务组件，解决引用依赖和使用策略。这是一个很大的进步，因为当前的 SOA 平台需要开发者自己获取那些私有的服务部署引用，甚至有时要在他们的服务实现中写 hard code.

3 、 SCA 与 JBI 的区别

SCA 关注的重点只是 SOA 开发所看到和接触到的。 SCA 并没有关注用来执行 SCA 模块的引擎是如何构架的。只是对这个引擎的实现提供一个规范和实现依据。这个引擎可以用任何方式实现。

JBI 从另一个方面来说就是一组关注创建一个开发的，可扩展的以及标准组件的企业服务总线。 这样它的内核是和 SCA 有一些重合的地方。同时两者之间也存在互补的机制。

重合方面：是 JBI 关注的是如果将一组引擎组装并运行于一个 JVM 中，是对编码开发的一种设计方式。 相反 SCA 在另一方面并不将一个模块约束单个 JVM 中。当然一个 SCA 模块可以执行在一个 JVM 中，但同时它也可以很方便的将这些引擎部署在不同的进程甚至是不同的节点上。

最大的区别之处是 SCA 不但支持 Java 而且还支持 C 、 EJB 、 Spring 、 BPEL ，在今后也许还会支持 C# ， php 等。 而 JBI 只是 SCA 的一个实现方式，而不是唯一的选择。