FUSE ESB入门篇

一，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 容器以一种可插拔的方式集成不同类型的服务，而不是通过编写客户端代码来实现 服务的集成。

架构图：

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 请求发送给 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 

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

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.