0%

JBOSS FUSE:你必须知道的那些事

JBoss Fuse:企业级ESB

我没写错,就是“企业级ESB”。尽管“ESB”是“企业服务总线“的缩写,但确实有些”所谓的ESB“并不具备企业级特性。

比如MuleCE,甚至MuleEE。

JBoss Fuse具备了一个企业级平台所需要的特性:

除了实现基本的ESB功能外,JBoss Fuse还提供了IDE、管理和监控、集群支持等特性。这是一个产品进入企业级领域不可或缺的特性。

与Oracle Fusion、Mule ESB、Talend Unified Platform、WSO2 Platform等一样,JBoss Fuse也是一款商业的ESB产品。

JBoss Fuse由大量成熟的开源软件组合而成,包括但不仅限于:

  • JBoss Fuse
    • Apache ServiceMix
      • Apache CXF
      • Apache Camel
      • Apache ActiveMQ
      • SpringDM
      • Karaf
      • BluePrint
    • Fuse Fabric
    • HawtIO

可以说,Fuse使用的这些开源软件是历史的选择,经过长达8年的时间,融合了最广泛使用的同类产品,最终成为一个整体的ESB平台:

Apache ServiceMix

尽管JBoss Fuse官方有意无意的避免提及ServiceMix,比如这张图:

和这段文字:

"JBoss Fuse combines core Enterprise Service Bus capabilities (based on Apache Camel, Apache CXF, Apache ActiveMQ), Apache Karaf and Fuse Fabric in a single integrated distribution."

但是Apache ServiceMix确实是Fuse中最核心的组成部分,实现了ESB的核心功能。

”Apache ServiceMix is a flexible, open-source integration container that unifies the features and functionality of Apache ActiveMQ, Camel, CXF, ODE, Karaf into a powerful runtime platform you can use to build your own integrations solutions. It provides a complete, enterprise ready ESB exclusively powered by OSGi.“

ServiceMix是一个开源的ESB,使用Apache CXF发布服务,使用Apache Camel实现路由,使用Apache ActiveMQ实现可靠的消息传输。
ServiceMix使用OSGi将上述这些组件整合到一起,并使用Apache Karaf作为OSGi容器。

Apache CXF

Apache CXF已经成了Java发布WebService的事实标准。

CXF 继承了 Celtix 和 XFire 两大开源项目的精华,提供了对 JAX-WS 和 JAX-RS 全面的支持,并且提供了多种 Binding 、DataBinding、Transport 以及各种 Format 的支持,并且可以根据实际项目的需要,采用代码优先(Code First)或者 WSDL 优先(WSDL First)来轻松地实现 Web Services 的发布和使用。

关于使用Fuse发布Web Service,可以参考:《JBoss Fuse: 开发和部署Web Service》

Apache Camel

Apache Camel基于规则路由和中介引擎实现了企业集成模式(EIP,Enterprise Integration Patterns)
,可以基于POJO定义路由配置和中介的规则,不需要大量的XML配置文件。

Camel基于OSGi框架并使用依赖注入。支持Blueprint或Spring DM作为OSGi的依赖注入的框架。

这里有关于Camel的介绍:《Camel的核心概念》

Apache Aries Blueprint

有一些项目致力于将OSGi引入到企业级应用环境,比如Apache AriesEclipse Gemini,基于OSGi架构,实现企业应用所需的事务管理(JTA)、命名服务(JNDI)、持久化标准(JPA)、
管理模型(JMX)等功能。

其中,为了解决企业级应用开发所习惯的依赖注入,这些项目都实现了OSGi R4.2中规定了Blueprint标准。
也就是说,Blueprint是OSGi中的依赖注入规范
Apache Aries项目中对应的产品就是Aries Blueprint

Spring DM

Spring DM(Spring Dynamic Modules),其目标是使得用Spring开发的应用能够在OSGi容器中运行。Spring DM设计的Spring应用与OSGi平台的关系如下图:

将应用模块封装为OSGi bundle时,需要将该应用的Spring装配文件放置到jar包的META-INF/spring/目录下。
该装配文件除了传统的bean配置外,还可以配置osgi:service,以引用或发布OSGi服务。

也可以在MANIFEST.MF中用Spring-Context参数进行指定。比如:

1
2
3
4
5
Spring-Context: config/applicationContext.xml, config/beans-security.xml
Spring-Context: *;create-asynchronously=false
Spring-Context: config/osgi-*.xml;wait-for-dependencies:=false
Spring-Context: *;timeout:=60
Spring-Context: *;publish-context:=false

Spring DM提供了spring-osgi-annotation,spring-osgi-core,spring-osgi-io,spring-osgi-extender等bundle,可以部署到OSGi容器中。

其中,spring-osgi-extender会创建OSGi容器中的“Spring Application Context”,并监听OSGi容器的事件。当有新的bundle部署时,spring-osgi-extender会检查该bundle是否包含Spring-Context或者META-INF/spring/中的装配文件。如果有,则将其视为“spring bundle”,会根据装配文件进行bean的组装,当需要引用或发布OSGi服务时,spring-osgi-extender会调用OSGi框架中相应的方法。
最后,将bean加入到Application Context中。

Spring DM与Blueprint的功能非常类似,实际上,先有Spring DM,然后才有Blueprint。尽管Spring DM项目已经停止了,但是
为了适应“遗留系统”,在ServiceMix中依然集成了SpringDM。

Apache ActiveMQ

Apache ActiveMQ是老牌的开源MQ软件,支持JMS 1.1和2.0,支持集群和容错(Fault Tolerance),可以实现发布/定义、点对点、分组、流等消息传递模式,提供了高可用(HA)和负载均衡机制。

本来差点被RabbitMQ强了位置,但是ActiveMQ迅速支持了AMQP 1.0,估计其地位还会稳固相当一段时间。

Apache Karaf

Apache Karaf是一个轻量级的OSGi容器,使用Apache Felix作为OSGi运行时,提供控制台、日志、热部署、依赖注入等功能。

虽然Equinox与Felix可以单独使用,但Karaf旨在结合这两个框架出色的OSGi功能,并且保证其开箱即用。
比如说,它包含了一个可配置的日志系统(基于Log4J,但针对众多通用的日志系统进行了包装)、通过SSH实现的远程访问、通过ConfigAdmin进行配置以及内建的JAAS支持。不仅如此,Karaf还安装了Pax URL的MVN协议,这样就可以从Maven中央仓库(在必要的情况下会自动将其包装为bundle)安装bundle了。

此外,Karaf还提出了特性的概念,所谓特性就是bundle的集合,能以组的形式安装到运行着的OSGi运行时当中。特性包含了对obr、jetty以及spring的支持,做到了开箱即用。这样,如果需要安装多个bundle,但这些bundle之间并没有严格的运行期依赖,那么这种支持就可以大大简化这种情况。在迁移到Apache Felix项目中前Karaf是ServiceMix Kernel,并且最终成为了Apache的顶级项目。Karaf还加入到了其他框架当中,如Eclipse Virgo和EclipseRT packages,提供了预先配置的框架与好用的OSGi bundle,这样在上手使用OSGi运行时时就会比以往更加简单。

Karaf已经被诸多Apache项目作为基础容器,比如Apache Geronimo, Apache ServiceMix, Fuse ESB等。

Felix和Equinox

OSGi运行时(runtime)的几个实现中,的推广度程度不高,SpringDM已经被放弃

Equinox跟随Eclipse大放光彩之后,却很难进入企业级应用领域。
Felix无论是从自身表现还是推广程度来看,可以说前景非常良好。

Fuse Fabric

由于Fuse基于大量的开源项目,要实现配置管理、集群以及部署就变得非常复杂。

Fuse Fabric是一个开源的集成平台(iPaaS),能够简化部署和变更管理等工作。

Fabirc基于Apache ZooKeeper建立了一个注册中心,利用git的分布式版本控制管理部署描述符(profiles),对各个容器进行管理,包括
变更管理、滚动升级以及版本回退。

Fuse Fabric支持对Fuse ESB, Fuse MQ, Apache ActiveMQ, Camel, CXF, Karaf, ServiceMix等软件的管理。

Apache ZooKeeper

Apache Zookeeper,是Apache Hadoop 的一个子项目,它主要是用来解决分布式应用中经常遇到的一些数据管理问题,如:统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。通常,ZoopKeeper被用于配置文件的管理、集群管理、同步锁、Leader 选举、队列管理等。

HawtIO

Hawt IO 是一个基于HTML5的Web控制台,可以通过配置和使用大量的插件管理基于Java的应用或平台。Hawt IO自带的插件包括基于git的Dashboard, Wiki, 日志, 健康状态, JMX, OSGi, Apache ActiveMQ, Apache Camel, Apache OpenEJB, Apache Tomcat, Jetty, JBoss, Fuse Fabric等,也可以很容易开发自己的插件。

新版本的ActiveMQ、Fuse等都使用HawtIO作为管理控制台。

HawtIO的目标是:”为每一个JVM提供一个基于Web的控制台“。

标准和规范

OSGi

[OSGi(Open Services Gateway initiative)](http://www.osgi.org/Main/HomePage是一个标准,
致力于为Java提供一个模块化的底层环境,以及一系列通用的服务(Service)。

和普通的JVM程序相比,OSGi的程序天生拥有动态模块的特点,不同的模块(OSGi里称之为Bundle)有着独立的生命周期,可以独立进行安装、启动、停止、卸载的操作,模块间的依赖性管理也由OSGi提供。

OSGi非常适合需要进行Plugin管理的项目,一个典型的成功案例就是Eclipse和它众多的Plugin。OSGi标准还规范了一系列我们常间的操作,日志、配置文件、事件队列、Web开发、JPA&JDBC等等,大部分部署OSGi标准的框架都提供了这些服务。

JAX‐WS, JAXB, SAX

JSR 224: JAX-WS (Java API for XML-Based Web Services),一组XML web services的JAVA API规范,允许开发者选择RPC-oriented或者message-oriented 来实现自己的web services。

JAX-WS使用JSR 222: JAXB(Java Architecture for XML Binding)作为绑定的规范,使用JSR 173: SAX(Streaming API for XML)作为XML解析的规范。Java EE 6 引入了对 JAX-WS 的支持。

JAX‐RS

JSR 311: JAX-RS(The Java API for RESTful Web Services),定义一个统一的规范,使得 Java 程序员可以使用一套固定的接口来开发 REST 应用,避免了依赖于第三方框架。同时,JAX-RS 使用 POJO 编程模型和基于标注的配置,并集成了 JAXB,从而可以有效缩短 REST 应用的开发周期。
Java EE 6 引入了对 JAX‐RS 的支持。

Blueprint

Blueprint提供了一个针对OSGi的依赖注入的框架,通过XML文件定义和描述各种元件组的装配。

OSGi R4.2对Blueprint进行了标准化。

目前主要有Apache Aries和Eclipse Gemini两个实现。

EIP

EIP(Enterprise Integration Patterns),企业整合模式。

JBI(TODO)

JSR 208: JBI(Java Business Integration)是一种SOA的组件整合标准模型。

SOA在Java领域有两套标准:

  • 商业的SCA和SDO标准,由IBM和BEA等公司推出。其中SCA实现了业务组件和传输协议的分离,可以处理各种平台组件的集成;SDO可以的自由读取各种不同数据源的数据。
  • JSR组织的JBI标准,由SUN最早推出,但是没有得到BEA和IBM的承认。JBI只关注Java组件的集成。

JBI容器由三部分组成:

  • BC(Binding Components)

    绑定组件用于接收各种不同传输协议的请求。可以细分为接收BC和发送BC:接收BC主要负责发送请求和接收响应,发送BC主要用来调用外部的服务。

  • SE(Service Engines)

    服务引擎处理JBI容器内部的消息。JBI容器通常在接收到消息后,需要对请求的消息做一些“处理”,然后再调用外部服务的提供者。根据功能的不同,将SE组件分为以下三种类型:

    • Transform SE:处理各种传输协议和格式变化
    • BPEL SE:将Web Service进行流程编排
    • Rules SE:按照规则将各种服务进行集成
  • NMB(Normalized Message Router)

    规格化消息路由器是JBI内部消息系统的核心,所有的组建之间不能交换消息,只能通过NMR来传递。