就像Java业务集成（IEEE互联网计算）中定义的那样——“JBI是由容器和插件（Plug-in）组成的可插入式架构。这个容器托管使用消息路由进行通信的插件组件。架构上，组件通过一个抽象的服务模型（一个消息传递模型，位于任何特殊协议或消息编码之上的抽象层中）进行交互。"

　　在基于JBI的实现中，服务之间并不直接交互。取而代之的是，采用类似EAI实现中广泛应用的消息代理架构，JBI容器扮演在服务之间路由消息的通用中介，（见图1）。



图1通过JBI协调消息交换

　　分离交换的参与者（JBI架构的基础）在服务提供者和消费者之间提供了解耦，以及一个用于协调（mediating）服务通信量（或插入所有额外需要的功能）的明确位置。

　　此时，协调器（Mediation）可以支持广泛的功能，从消息传送和安全加强，到基于内容的路由和服务标本标定。

　　JBI容器托管了2类不同的插件组件：
服务引擎（ServiceEngine，SE）。SE本质上是用来托管JBI环境内部服务提供者和消费者的标准容器f。例如，在JBI环境中经常出现的SE包括数据转换器、业务规则容器和BPEL引擎。绑定组件（BindingComponent，BC）。BC为JBI环境外部的服务消费者和提供者提供互联性。BC允许集成不提供JavaAPI的组件/应用程序，并使用远程存取技术访问它们。

软件开发网

　　组件间的交互利用了基于WSDL2.0的标准化服务定义。WSDL2.0定义在服务消费者和提供者之间提供了共享的协议，并作为JBI实现互操作能力的基础。

　　除了标准化的服务定义，JBI使用“通用化（normalized）”消息的概念支持全局组件互操作能力。消息通用化将协议与业务特定的上下文映射成一个通用的、可传输风格，这与EAI实现中经常使用的“规范（canonical）”消息表示概念非常类似。

　　每个JBI容器存在于一个单独的虚拟机中，并容纳所有的BC和SE，容器提供了一组服务，为SE和BC实现提供操作性支持。

　　JBI也定义了基于JMX的标准控制集合，允许外部管理工具执行不同的系统管理任务，也可以管理组件本身。管理支持为以下情形提供了标准机制：
安装plug-in组件。管理plug-in组件的生命周期（启动/停止等。）。部署服务器件给组件。　　服务组件架构（ServicecomponentArchitecture，SCA）

　　尽管服务组件架构（SCA）被作为规范定义（该规范定义了使用面向服务架构构建系统的模型），但它是一个有效的模型（该模型用来将组件组合成服务），并为服务组合成解决方案提供了额外支持。

　　SCA基于2个主要的元模型：
类型元模型。组合元模型。　　类型元模型

　　这个元模型（见图2）描述组件类型、接口和数据结构。



图2描述组件、接口和它们依赖的元模型

　　一个组件实现由以下的4组规范定义：
被提供的接口——组件定义的接口集。这些接口通常定义为WSDL端口类型或语言接口，如Java或C 。一个组件可以暴露0或多个接口。每个接口包含几个方法。被要求的规范（引用）——组件实现使用的接口集。这些接口通常定义为WSDL端口类型或语言接口，如Java或C 。一个组件可以有0或多个接口。用来裁剪或自定义组件行为的属性。每个属性定义为一个属性元素。一个组件可以包含0或多个属性元素。定义组件实现的实现元件。SCA允许很多不同的实现技术，如Java、BPEL、C 、SQL等。SCA为引入新的实现类型定义了扩展机制。　　组合元模型

　　这个元模型（见图3）定义了组件实例，以及它们是如何连接的。


图3组件实例和它们在组合元模型中的连接