一,SOA, ESB, JBI introduction
Service-Oriented Architecture (SOA)
是最近几年新提出的解决应用系统互联互通的
一种新架构和新思想,
SOA
采用了很多业界所共同遵守的标准或规范,这种设计架构
已经逐步成为软件应用系统集成的主流架构
Enterprise Service Bus
(
ESB
),即企业服务总线是
SOA
的一个基础和最佳实现。
它是一个基于标准的,松散耦合的,灵活性和扩展性非常高的平台,适合于对企业组织
的各种异构系统进行整合,并为以后开发的各种面向服务的应用提供自动的集成,当企
业的业务需求有变化时也不需要对原来的系统进行改造,真正达到
“
按需互连
”
的效果。
JSR 208
—
Java Business Integration(JBI)
是标准的组件模型整合,是一种松耦合,
事件驱动方式的整合。
JBI
是一种企业服务总线
(Enterprise Service Bus,ESB)
,用于形
成一种关键基础设施片段,使我们能够用
Java
实现面向服务的架构。
SOA
在
Java
领域有两套标准:一个是
SUN
推出的
JBI
(没有得到
BEA
和
IBM
的承认),另外
一个是:
IBM
和
BEA
等公司推出的
SCA
和
SDO
标准。
JBI
之关注
Java
组件只处理
Java
组件的集成。
SCA
实现了业务组件和传输协议的分离,可以处理各种平台组件的集成。
SDO
可以的自由读取各种不同数据源的数据。
另外,
BPEL
本质上是一种集成
WebService
服务的语言,也可以算作为
SOA
的一部分。
JBI简介:
JBI
的本质是一种服务总线思想
JBI
是一种思想,
JBI
思想的实现就是
JBI
容器。
JBI
容器是为弥补现有
J2EE
容器的不足而出现的。
现有应用服务器的容器
(
ervlet
容器、
JMS
容器
)
不足
:
a)
、每种容器都有自己特殊的传输协议,相互之间不能直接通信。比如:
Servlet
容
器只能接受
HTTP/SOAP
的传输协议,
EJB
容器只能处理
RMI
的传输协议,
JMS
只能处理
JMS
的传输协议。
b)
、是一个纯粹的服务提供者,不是一个服务的集成者。也就是说,容器之间不能
继承服务
c)
、容器间服务的调用需要编写客户端代码。
JBI
容器以一种可插拔的方式集成不同类型的服务,而不是通过编写客户端代码来实现
服务的集成。
架构图:
![](http://hi.csdn.net/attachment/201008/1/0_1280672409WLk8.gif)
JBI
容器的组成的三大部分:
a)
、绑定组件(
BC
:
Binding Components
):专门用来接收各种不同传输协议的请求,原理是
JBI
实现了各种不同协议的绑定组件,绑定组件可以细分为接收
BC
和发送
BC
。接收
BC
主要负责发送请
求和接收响应,发送
BC
主要用来调用外部的服务。
b)
、服务引擎(
SE
:
Service Engines
):这类组件只处理
JBI
容器内部的消息。
JBI
容器通常在接收
到消息后,需要对请求的消息做一些
“
处理
”
,然后再调用外部服务的提供者。根据功能的不同,
将
SE
组件分为以下三种类型:
Transform SE
:专门处理各种传输协议和格式变化。
BPEL SE
:专门负责将
Web Service
进行流程编排。
Rules SE
:专门负责通过规则将各种服务进行集成。
c)
、
JBI
的规格化消息路由器(
Normalized Message Router
):是
JBI
内部消息系统的核心,所有的
组建之间不能交换消息,只能通过
NMR
来传递。
在
JBI
容器内部,只有一种标准的规格化消息(
Normalized Message
)。任务服务组件进入
JBI
环境之前,通过
BC
转换为规格消息
NM
。在
JBI
环境里,所有的服务都不能相互调用,不论是请求还
是回答消息,都要先转给
NMR
,再由
NMR
分发。
JBI
运行环境里面的组件(
SE
、
BC
)和
NMR
都是通
过
NM
来进行信息交换的。
流程图:
![](http://hi.csdn.net/attachment/201008/1/0_1280672451i3oi.gif)
流程介绍:
外部请求者将一个
HTTP
请求发送给
JBI
容器,容器的
HTTP BC
接收请求,并将请求的消
息格式化为
NM
发送给消息接收转换引擎,然后再将
NM
发送给
NMR
,由
NMR
再将
NM
发送
给
SOAP BC
,
SOAP BC
将
NM
转换为
SOAP
消息发送到外部的
WS
组件。执行后,消息按照
原路返回。
JBI defines a common packaging model for all of the artifacts that can be deployed
into the JBI environment. The two most common types used by an application
developer are:
Service Assembly
— A collection of service units. The root element of the JBI
descriptor is a service-assembly element. The contents of the package is a
collection of ZIP archives containing service units. The JBI descriptor specifies the
target JBI component for each of the bundled service units.
Service Unit
— A package that contains functionality to be deployed into a JBI
component. For example, a service unit intended for a routing service engine
contains the definition for one or more routes. Note that service units are packaged
as a ZIP file. The root element of the JBI descriptor is a service-unit element. The
contents of the package are specific to the service engine for which the service unit
is intended.
二,
FUSE ESB kernel Architecture
FUSE ESB 4 still supports JBI, and it is based on OSGi, it provides additional
flexibility. FUSE ESB 4 has the following layered architecture:
Technology layer
—includes technologies such as JBI, JAX-WS, JAX-RS, JMS, Spring,
and JEE
FUSE ESB kernel
—a wrapper layer around the OSGi container implementation,
which provides support for deploying the OSGi container as a runtime server.
Runtime features provided by the FUSE ESB kernel include hot deployment,
management, and administration features.
OSGi framework
—implements OSGi functionality, including managing dependencies
and bundle lifecycles
FUSE ESB kernel is based on
Apache Felix Karaf
, a powerful, lightweight, OSGi-based runtime container for deploying and managing bundles to facilitate componentization of applications
![](http://hi.csdn.net/attachment/201008/1/0_1280672547Cd9u.gif)
FUSE ESB kernel uses
Equinox
as its default OSGi implementation. FUSE ESB kernel
can also use any standard OSGi container, such as
Apache Felix
.
the OSGi framework contains the following:
Bundles
— Logical modules that make up an application.
Service layer
— Provides communication among modules and their contained
components. This layer is tightly integrated with the lifecycle layer.
Lifecycle layer
— Provides access to the underlying OSGi framework. This layer
handles the lifecycle of individual bundles so you can manage your application
dynamically, including starting and stopping bundles.
Module layer
— Provides an API to manage bundle packaging, dependency
resolution, and class loading.
Execution environment
— A configuration of a JVM. This environment uses profiles
that define the environment in which bundles can work.
Security layer
— Optional layer based on Java 2 security, with additional
constraints and enhancements.
FUSE ESB therefore provides a scalable unit of deployment, the feature, which enables you to deploy multiple bundles (and, optionally, dependencies on other features) in a
single step
FUSE NMR:
the OSGi framework provides a model of synchronous communication between
bundles (through method invocations on OSGi services), it currently
does not provide a model of asynchronous communication.
FUSE ESB therefore provides a non-standard mechanism to support asynchronous
messaging, known as the Normalized Message Router (NMR), which is loosely based
on the NMR defined in the JBI standard.
a general overview of the NMR architecture, which spans both the OSGi container and the JBI container
![](http://hi.csdn.net/attachment/201008/1/0_1280672816gCOU.gif)
In architecture diagram, the NMR is represented as a horizontal graphical element
in order to emphasize its role linking together various application bundles. In
practice, however, the NMR is deployed as a collection of bundles, just like any
other application in the OSGi container
Unlike the standard NMR, however, the FUSE ESB NMR is
not
restricted to the JBI
container. You can use the NMR to transmit messages inside the OSGi container or,
if the JBI container is also deployed, to transmit messages between the two
containers.