Apache ServiceMix 3.x User's Guide

http://servicemix.apache.org/users-guide.html

 

2. 介绍

2.1 介绍ESB

问题

企业网络通常会部署多样的应用，平台和业务流程，同时也要求彼此之间能够交换数据。但是这些应用，平台和流程之间有着非兼容的数据格式和通信协议。如果一个企业还需要与外界系统进行交互，那集成的问题甚至会涉及到企业之外，也需要包含它的商业伙伴的IT系统和流程。

近年来有一些技术开始涌现以尝试解决上面的问题，这些技术包括企业应用集成(EAI)，B2B，SOA和Web Services。这些方案的确解决了一些集成问题，但却是专有的，昂贵的，并需要耗时的实施。

ESB方法

基于标准的ESB可以解决集成问题，并且不存在上述方案的缺点。ESB的目的是通过提供分布式处理，智能路由，安全和动态数据转换来促进应用和流程的集成。

ESB集成基础设施的特点是：
1. 分布式
2. 基于消息的 - 促进松耦合
3. 基于标准的
4. 可靠的

作为一种集成基础设施，ESB提供的功能包括
1. 路由
2. 转换
3. 可视性

ESB同样也支持里例如安全性，集群和事务性等需求。这些需求以"硬连线"集成方式存在，但不会在一个基于服务的架构中自动可用。

一个对于ESB的更新要求是不仅为SOA提供松耦合，也要提供事件驱动架构(EDA)的基础支持。SOA和EDA是具有互补性的。EDA是异步的，而SOA消息模型是典型的同步模式。

2.2 什么是Java Business Integration (JBI)

JBI规范是一个基于java的标准，它定义了一个通过中间消息交换模式的插件的runtime架构。这个中间消息交换模式简单地采用了WSDL2.0规范中的消息交换模式(MEP)。组件之间的消息都是通过Normalized Message Router (NMR)进行中转的。插件之间彼此并不直接通信，他们只与NMR通信。这保证了插件之间的位置透明。

JBI组件

上面提到的插件有两种形式：binding components和service engines。它们都被统称为JBI组件。JBI组件被部署到JBI环境，简单地在内存中运行，等待一个配置。

Binding Components (BC)

一个BC有两个目标：
1. 使用远程协议通信
2. 规格化和去规格化接收到的消息

BC被用于与JBI环境外部通信。BC提供的远程协议的例子包括HTTP/S, JMS, FTP, SMTP, XMPP, RMI, CORBA等等。在ServiceMix中的BC包括：servicemix-file, servicemix-ftp, servicemix-http, servicemix-jms, servicemix-xmpp。

消息规格化(Normalization)

BC将所有的消息转化为NormalizedMessage。一个规格化的消息包括：
* 内容。XML负载消息
* 附件。主消息对象的附件（通常是二进制的）
* 安全主体。
* 属性。

Service Engines (SE)

一个SE在JBI环境中提供某种逻辑，并且只与NMR通信。如果一个SE需要与JBI环境外进行通信，它必须经由NMR发送一个消息到某个BC。SE的例子包括rules engines, BPEL engines, XSLT engines, scripting engines, EJB containers等等。在ServiceMix中的Service Engine组件包括servicemix-bean, servicemix-camel, servicemix-jsr181, servicemix-quartz, servicemix-saxon, servicemix-script.

使用JBI组件

通常，JBI组件与JBI容器一起提供，他们提供了一些最普遍的协议和引擎的支持。为了能使用这些组件，你必须为每一个你想要使用的组件提供一个配置。配置是实现相关的，但是打包(packaging是在JBI规范中定义的。每个组件配置必须打包为一个Service Unit (SU)，并且每个SU必须被包装进一个Service Assembly (SA)。这些简单地是ZIP/JAR文件，其中包括了一个为JBI环境所使用的XML描述器，名字为jbi.xml。

2.3 为什么是ServiceMix

有许多供应商提供ESB方案，但对于那个是最好的ESB设计和架构却没有一个统一的认识。ServiceMix是基于JBI(JSR208)规范的，目的是创建一个基于标准的ESB，结合了SOA和EDA的功能，最终实现敏捷(agile)的企业ESB。

作为一个敏捷的ESB，ServiceMix提供了能够组合在一起创建一个SOA架构的插件式服务。ServiceMix也允许服务以事件驱动的方式操作。ServiceMix为在总线内部以及外部发生的事件提供事件驱动架构。换句话说，JMS BC可以监听消息的到来，这里的消息就是总线外部的在topics或者queues的事件。而其他的组件在规格化的消息总线上监听消息。

尽管解耦(EDA)操作对于高事务性生产环境在可扩展性和可靠性方面是更合适的，ServiceMix同样也支持在SOA实现中的同步的请求/响应通信。所以ServiceMix为企业应用的开发和部署有效的结合了SOA和EDA。

特点概述

ServiceMix是轻量级的，易于嵌入的，集成有Spring支持，并能以standalone ESB提供者在客户端或服务器上运行，或者在另外的ESB中作为一个服务存在。你可以在Java SE或者Java EE应用服务器上使用ServiceMix。

ServiceMix使用ActiveMQ提供远程、集群、可靠性和分布式错误处理。

 

5. JBI

5.1 概述

什么是JBI?

JBI是用于构建系统集成的基于java的标准，JBI使用插件式组件，这些组件通过中间的规格化的消息进行互操作。消息交换模式是基于Web Services Description Language (WSDL)的。

在这个基于WSDL的，面向服务的模型中，JBI插件式组件负责提供或者消费服务。通过提供一项服务，一个组件使得某项功能或者多项功能可用，并能为其他的组件消费。这些功能在WSDL2.0中建模为operations。

组件提供的服务是通过组件使用WSDL 1.1或者2.0对JBI进行描述的。这样就提供了一种抽象的，技术中立的使用基于XML消息交换的服务模型。

JBI 架构

JBI环境通过基于JMX的管理工具提供部署，控制和监控特性。规格化的消息路由器（NMR）提供中间的消息基础设施。组件分成两类：Service Engine和Binding Component。

JBI组件通常充当某种类型的容器，工件(artifact)可以被部署进这样的容器来增加新的服务或者提供逻辑。例如一个提供基于XSLT的转换服务的Service Engine将会需要部署有XSLT样式表，这样才能增加新的转换操作。往已安装的组件中增加这样的组件相关的工件的过程被称为部署。这样的工件被称为Service Unit，而部署工件加上一些相关元数据的集合称为Service Assembly。

 

WSDL消息模型

JBI使用WSDL1.1或2.0来对组件生产或者消费的服务进行建模。WSDL在两个层次上提供基于消息服务的声明式模型：
* 抽象模型。不指向任何特定的协议或者线编码。
* 具体模型。绑定到某个具体的通信协议或者通信端点（endpoint）。

JBI使用抽象服务模型作为组件交互的主要基础。组件在交互过程中充当服务提供者或者消费者。

抽象模型

WSDL服务描述总是包括一个抽象服务模型，这个模型定义了：
* Message types。被XML schema定义。可以是正常消息或错误消息。
* Operations。包括一个operation名称，一个Message Exchange Pattern (MEP)和Message Types。
* Interfaces。是相关Operations的集合。

具体模型

具体服务模型定义了：
* Binding types.定义了服务绑定的协议类型。
* Endpints。一个endpoint代表了服务消费者与服务提供者交互所需要的通信端点信息。包括endpoint name, binding type。
* Service。包括Service name, Service Type Name, Endpoints。

Normalized Message Router (NMR)

NMR从JBI组件接收消息并且将它们路由到合适的组件进行处理。这个过程解耦了服务生产者和服务消费者，并且能够引入额外的处理。

消费者和提供者

JBI组件（Service Engines和Binding Components）既能充当服务提供者，也能充当服务消费者，甚者两者都充当。

提供者通过一个endpoint使得一个用WSDL描述的服务可用。这个服务实现了一个WSDL接口，这个接口是一些操作（operation）的集合。

消费者通过创建一个消息交换能够调用服务中的某个操作。消费者和提供者仅仅是共享了抽象服务定义，因而是解耦的，因为消费者不知道具体的协议和调用服务的位置。

Delivery Channel (DC)

一个DC是在一条组件和NMR中间的双向异步通信管道。一个服务消费者使用DC来发起一个服务调用，而提供者使用它的DC来接受这样的调用。每个组件只有一条DC，即用做入站也用作出战通信。

Endpoint激活

Endpoint激活时服务提供者告诉NMR它提供服务的一个过程，这使得这些服务能够为NMR所知，从而NMR可以将服务调用路由到这些服务。

激活分成了两个步骤：
1. 声明一个服务endpoint。
2. 提供元数据：组件必须提供激活endpoint的WSDL描述。这个WSDL描述将被NMR用于知道这个激活endpoint实现了那些接口和操作。

Endpoints

JBI使用与WSDL2.0一致概念的endpoints。Endpoints引用的是一个特定的地址，这个地址可被某个协议访问，从而获得某个服务。

Endpoints有两种类型：
1. 外部的endpoints。通往JBI环境之外的endpoints。这些endpoints由BC暴露，并充当服务消费者来暴露一个内部的endpoint以供外部的服务消费者使用。
2. 内部的endpoints。由在JBI环境内的服务提供者暴露。他们是通过NMR API获得访问的。

BC服务于提供在内部的endpoints和外部的endpoints之间的映射。

JBI 打包

JBI定义了一个标准的打包用于安装新的组件，以及在这些充当容器的组件上部署工件。所有的工件在META-INIF目录中都有一个jbi.xml的JBI描述器。

有四种类型的工件，它们都被打包为zip或者jar文件：
1. components installers. 包含了运行组件所需要的库和资源。组件可以引用共享的库。
2. 共享库。可以被一些组件所共享的jar集合。
3. Service Units。是意在被部署到某个特定的组件的工件。除了有一个JBI描述器，这个service unit封装是组件相关的，可以以不同的形式出现：单个的XSLT样式表，一个BPEL流程，或者一些java类。
4. Service Assemblies。

 

 

6. 配置 ServiceMix

6.1 目录布局

Main distribution
[root]
 |- ant  用于ant任务管理的文件
 |- bin  用于Unix / Windows 的启动脚本
 |- conf  ServiceMix 容器的配置文件
 |- data  保存持久化数据的工作目录
 |- examples   含有发布范例
 |- hotdeploy  service assemblies和JBI组件installer的热部署目录
 /- lib  容器库
     /- optional  可选的库

Data directory
data
 |- amq  ActiveMQ的工作目录
 |- log  log文件目录
 |- smx  ServiceMix工作目录。被ServiceMix在安装/部署JBI工件的时候填入。
 /- txlog  事务日志存储

ServiceMix working directory
smx
 |- components
 |   |- [component-name]
 |   |   |- version-n
 |   |   /- workspace
 |   /- [other-component]
 |       /- ...
 |- service-assemblies
 |   |- [sa-name]
 |   |   /- version-n
 |   /- [other-sa]
 |       /- ...
 |- sharedlibs
 |   |- [sl-name]
 |   |   /- version-n
 |   /- [other-sl]
 |       /- ...
 /- tmp

配置文件

ServiceMix使用XML配置文件。ServiceMix使用Apache XBean库来完成XML配置，可以使用常规的Spring配置或者我们定制的基于XSD的XML配置。