作者：人月神话，新浪博客同名

简介：多年SOA规划建设，私有云PaaS平台架构设计经验，长期从事一线项目实践

今天整理下原来写过的开源ESB服务总线产品的简单使用和对比分析。当前微服务架构和去中心化趋势下，虽然ESB服务总线现在大家提起的比较少了，但是对于传统企业仍然是主流的解决数据和应用集成的中间件平台。由于这篇文章是对历史内容的一个整理，有些开源软件版本可能还是比较老的一个版本，特此说明。

Mule ESB产品试用

对于Mule的新版本产品，特别是http组件和datamapper组件，还有就是SOAP消息组件。这也导致网上很多关于用mule esb来实现简单的SOAP WebService代理服务的例子都无法正常运行。

在整个mule esb的功能测试中，整体感觉是mule当前在http消息流的处理上相对优秀，包括http消息流和FTP，SOAP，Database，外部Java代码，MQ集成等，这些访问都能够很好的进行处理。但是如果是单纯的SOAP服务的发布和设计，SOAP+DB的组合实现起来相对麻烦，有很多Talend ESB很容易实现的场景当前在Mule ESB中仍然没有跑通。

简单的WebService代理服务的实现例子

1. 拖入Http Connector组件，配置基本的path和端口信息。这里没有太特别的地方。

2. 拖入CXF组件，设置为Proxy Service类型，在Advance地方要引入已经导入到项目中的wsdl文件。

--设置该组件的namespace，端口号信息，SOAP类型改为1.2 payload类型为envelope

3. 拖入CXF组件，设置为Proxy Client类型，该组件本身不需要再做任何额外的配置。

4. 拖入http组件，注意是放在process里面，自动即为一个http Request组件，处理SOAP请求转发

--设置host信息，本地的话为0.0.0.0，path信息，访问ws的路径信息，method类型为post

处理完以上配置后一个ws代理就可以完全跑通，并可以通过soapui进行测试。

在proxy代理服务的实现过程中，尝试了以前版本的通过spring的wsproxyService组件，通过http简单请求转发，通过webservice comsumer组件配合cxf组件来实现代理，以上方式均没有尝试通过。

在前面一篇文章里面曾经谈到过，mule最近出现的版本升级导致了历史版本很多功能无法跑通同时需要迁移。同时在当前最新的版本中对soap服务的支持能力仍然不是特别方便，下面是近期研究的一些内容总结。

通过web service consumer组件来实现proxy服务代理

前面已经谈到过通过CXF组件配合Http Endpoint简单的来实现服务代理，但是这种代理的实现模式可以看到很难对输入的内容进行加工，包括在输入和输出内容之间进行映射。而通过consumer组件则可以很方便的实现这些扩展能力。对于刚场景大家容易想到的就是简单的将原有的http endpoint节点替换为consumer组件即可以跑通，但是实际情况相对来说复杂的多，具体在该服务配置的时候需要注意的点包括

a.需要增加dom to xml组件，即将cxf代理服务组件的输出首先转换为xml结构信息

b.增加了一个transform组件，对于input，我们采用了xml例子来新生产schema即一个完整的soap request，包括了envenlop和body，因为proxy输出的内容是含了信封的，而实际服务调用需要的是不需要信封。因此进行一次转换后再输出。(这个经过了多次Debug才发现有该问题)，同时注意可以将debug到的xml数据结构单独保持处理，作为shema信息再导入，方便后面映射。

SOAP WebService+DB适配

这也是经常会遇到的场景，该场景本身有包括了两种，一种是对于查询服务，即将SOAP的输入信息作为查询条件，然后根据查询条件去查询数据库，最后将数据库的查询结果通过xml结构返回。另外一种场景即对于导入服务，即将输入信息作为插入到数据库表的记录信息，通过DB适配然后导入到数据库中。

对于查询类服务注意在实现的时候仍然需要通过CXF节点，将节点的类型要设置为proxy Service属性。对于该CXF节点可以收下导入一个wsdl文件到项目里面，然后节点引用该Schema信息后发表一个本地的代理服务。对于服务获取调用请求后，由于CXF节点本身没有Schema自动敏感获取的能力。因此在实现的时候还是需要将CXF节点的内容通过dom to xml转换，然后再连接Database节点。

在Database节点连接后，对于Sql语句需要采用参数化查询的模式来实现，在http+DB的例子中可以看到通过脚本很容易获取http请求里面的参数内容。对于SOAP输入消息模式下则需要通过XPATH语句来获取xml里面的节点输入内容。

在查询情况下Database的输出结果是数据敏感的，即组件可以自动的获取到Shema信息方便我们去做数据映射处理，在Database节点后仍然拖入Transform节点，节点的目标需要引用本身WSDl文件的response信息，然后对数据库的查询输出和wsdl输出之间进行数据映射即可。

通过http请求然后转发去调用SOAP Webservice

该场景测试OK，对于http请求如果是json格式，还可以将json样例数据导入后形成dataSense的shema结构，该结构可以和WebService consumer的xsd结构进行dataMapping。处理请求相对方便。

通过http请求然后触发数据库查询操作

该场景测试OK，特别是对于http请求的输入参数，可以在Database组件中进行参数化查询和配置。对于Database本身的输出信息也是Datasense的，即可以获取到具体的schema信息方便后续处理。

直接在mule环境里面开发一个soap webservice并发布

该场景OK，对于简单的webserice我们可以直接编写相关的接口类和实现类，并在CXF组件中配置实现。对于较为复杂的结构，可以采用ws-service类型，同时将外部的wsdl文件导入后自动生成CXF相关的结构和代理类。具体的实现即可以通过java代码实现。

在该场景测试中注意自动生成没有实现类，要通过cxf框架命令行生成后再导入。其次就是在cxf组件后面需要拖入一个java组件，该java组件的class配置为刚才的接口实现类。

部署和管控

在mule 项目里面，对于设计完成的服务可以右键export会导出一个.zip压缩包。然后将压缩包拷贝到mule_server的apps目录下，每隔5秒mule会自动进行部署。

对于mule服务端的启动，可以运行mule_server/bin/mule.bat启动mule的服务器端。对于企业版本mule是提供了MMC管理控制台，如果安装了管控平台，则可以将mule直接部署到管控平台的server里面。对于mule的管理端可以通过http://localhost:8585/mmc-3.7.0登录，用户名和密码都是admin。

简单总结

整体来说mule esb仍然是一款优秀的开源ESB产品，当前主要有社区版和企业版，对于企业版在管控和高可用性上面提供了更多的支持。mule当前在中国没有设置办事处，对于在国内的推广仍然缓慢。如果是更多基于http消费和调用来进行业务和数据的集成，特别是类似open api开放平台的构建，采用mule esb是很不错的一个解决方案。而对于soap服务集成，DB集成能力相对来说talend ESB更加强大。

Talend ESB服务总线研究

由于查找支持Camel的前端设计器插件，比较偶然的留意到了Talent ESB这款开源产品，最近这几天一直在进行该产品的使用，由于配套的文档和使用手册相对齐全，很多实际在ESB服务集成中常遇到的集成场景都可以很好的实现，Talent整个开源生态线多个产品获得过10大优秀开源产品大奖，确实是诸多值得学习和借鉴之处。

下面对近期研究和验证的一些场景做一下简单记录：

SOAP WebService的简单服务代理

这是ESB封装经常会使用到的一个功能，即对提供对原始Web Service服务的proxy代理服务。对于这个功能当前产品支持的很好，具体的操作主要如下。

a. 首先是新建立一个Web Service，注意可以直接导入本地或远程WSDL文件生成Schema信息.

b. 将WebSerice分配到一个新建的Job作业上，会自动在设计器中生成Request和Response节点。

c. 增加XmlMap节点，增加ESBConsumer节点，Consumer即访问服务的原始地址信息。

d. 在XmlMap数据映射设计器上进行数据映射，注意需要手工导入WSDL的Schema文件信息。

e. 可以在节点之间拖入tLogRow节点进行输入和输出内容的Log日志记录。

这个简单的例子可以看到对于ProxyService，数据映射，log日志记录，WSDL Schem元数据管理都已经得到了很好的支持。在设计完成的组件上面可以直接通过运行按钮进行服务运行和测试。

WebService+DB适配数据插入

由于Talend最早本身就是做ETL工具的，可以看到对于ETL相关能力的支持相对强大，基本涵盖了所有常见主流数据的数据查询，数据插入和更新的相关适配器。对于核心操作如下：

a. 首先是新建立一个Web Service，注意可以直接导入本地或远程WSDL文件生成Schema信息.

b. 将WebSerice分配到一个新建的Job作业上，会自动在设计器中生成Request和Response节点。

c. 增加tMysqlOutput节点，并在WS-Request阶段和该节点之间增XMLMap数据映射节点进行数据映射。

d. 对tMysqlOutput进行数据连接和表的配置，配置完成后可以编辑和统计数据库架构信息。

对于DB插入的场景考虑的另外一个重点是由于tMysqlOutput本身没有明确的输出，那么就存在如何将WS-Response节点进行输出的赋值问题。我们实际的场景往往是如果数据处理和插入成功，则将输出参数的Flag信息设置为True，否则设置为False。对于这样一个场景的实现我们采用了通过tAssert和tAssertCatch节点相互配合的方式来实现。

a. 在tMysqlOuput组件运行成功的时候可以触发断言

b. 增加tAssertCatch节点同时捕捉断言和Java异常信息。

c. 在tAssertCatch节点和WS-Response节点之间增加tXMLMap数据映射，将结果信息输出到Response节点。

WebService+DB查询结合

这个结合其实最主要的是需要通过WebService传入的参数来实现DB的动态参数化查询，在实现该场景的时候由于tMysqlInput节点本身不支持结构化参数定义和映射。因此需要考虑用其它方式实现。具体为：

a. 首先是新建立一个Web Service，注意可以直接导入本地或远程WSDL文件生成Schema信息.

b. 将WebSerice分配到一个新建的Job作业上，会自动在设计器中生成Request和Response节点。

c. 增加tMysqlInput节点，并进行数据库连接和查询语句的配置。

d. 增加tJavaRow节点，并在WS-Request阶段和该节点之间增XMLMap数据映射，将输入赋值到Java变量中。

e. 增加全局变量定义，并将Java变量的值赋到全局变量中。

f. 增加一个组件运行OK的触发器连接到tMysqlInput节点，即前面赋值成功才触发。

g. 在tMysqlInput节点和Response节点之间进行数据映射，通过tXMLMap节点进行。

h. 主要在Map设计器上面输出需要选择All-in-One，loop节点需要选择对，否则产生多个Reponse而报错。

在这个场景的实现中，我们使用了全局变量和参数定义赋值，触发器的使用。可以看到能够很好的实现上面的参数化通过服务来触发DB数据库的查询操作。也看到在整个服务设计中平台具备的扩展能力。

WebSerice中的Json对象处理

相关场景就是可以Request请求收到的是结构化的输出和输出信息，但是最终Reponse时候需要将信息组合成一个完整的Json串输出。对于这种场景平台也能够很好的处理，即通过tWriteJsonField节点来实现。在该节点中可以自己定义完整的Json对象格式，然后通过XmlMap和Request信息进行映射。

对于设计完成的服务部署也很方便，即首先在WebService上进行导出操作，可以导出为.kar扩展名的部署包，然后将将部署包拷贝到container的deploy目录下即可以完成部署操作。

对Http Rest API接口的接入和适配能力

在对mule产品研究的时候说到过mule对http类消息请求，对json格式的shema化和映射都做的相当不错，在这点上面Talend基本具备同样的能力，即Talend对Http Rest消息服务的处理能力不弱于mule，同时对soap webservice和DB又提供了更加强大的支持能力。

对于Http Rest的支持我们主要测试和验证了如下场景：

通过http rest请求查询数据库并将数据库的查询结果通过xml格式返回

该集成场景的实现相当简单，主要涉及到使用restRequest，mysqlinput和xmlMap相关组件。在restRequest组件中我们可以设置相应的endpoint端点地址，同时设置rest api信息中的flow，对于每一个flow的定义我们可以详细的设置参数信息。

使用tFLowtoIterate节点，这个是相当有用的一个节点，要注意到对于restRequest输入的参数信息我们需要获取到并且能够传递到mysqlInput节点。该组件的作用就是将flow的参数变量信息读取出来并存储到全局变量中，那么在mysql节点进行配置的时候就可以采用该全局变量信息，比如我们在Flow中定义了From输入参数，则可以通过 globalMap.get("Flow.from")访问到该参数值信息。

拖入Mysql节点对数据库信息进行配置，然后根据前面的访问参数编写参数化查询sql信息。然后我们可以进一步拖入xmlMap节点，将mysql的数据库查询信息map到一个xml结构，作为RestResponse节点的输出。

通过http rest+post方式来导入或插入数据到mysql的数据库中

该集成场景在实现过程中有些曲折，最主要的原因还是对于post的输入文档结构格式没有完全了解清楚。在该例子的实现中仍然需要使用request节点，然后增加一个flow信息，对于flow的方式要修改为POST方式。对于该flow我们需要定义一个变量，该变量的类型为document，该变量必须要命名为body，前面命名为其它名字都导致了后续处理xml结构信息时候出现错误。

将request节点连接到xmlMap节点，在左侧我们手工的增加子节点和子节点元素节点来构造xml树结构，主要由于是可以一次Post多条数据，因此需要对Row的节点设置为loop属性。将xmlMap节点连接到mysqlOutput节点，对于mysqlOutput节点即连接到数据库的一张数据库表，可以通过在mysql节点中点击同步列，刷新xml右侧的schema结构到mysql中。

Camel相关集成场景测试

对于该测试，主要参考Talend提供的集成手册进行，主要对File，ActiveMQ，CXF，HTTP，JavaAPI进行了测试，经过测试整体感觉虽然Camel具备了足够的扩展性和高性能，但是在实际的集成场景中如果期望通过灵活可配置的方式来实现集成，那么Camel集成方式仍然存在大量的不足。特别是在Schema信息的获取和数据映射，对soap webservice的支撑能力上面。

当然如果更多的是对Http请求的处理，消息中间件的集成，那么采用camel提供的集成组件完全足够。在对Camel组件的测试过程中我们发现，通过拖入两个cxf组件就很容易的实现了传统的web service服务请求代理功能。但是如果希望像Integration中对wsdl中的shema进行读取和映射，就相当困难。

对于Talent ESB本身也提供相关的监控能力，其核心是SAM数据日志采集和监控，首先需要配置相关的数据库资源池和数据信息，对于服务的运行态参数需要设置为Use SAM，即对于服务运行的数据输入和输出信息会全部log到数据库的Event事件日志表中。

整个平台还有很多功能没有仔细研究，但是基本可以看到该平台能够很好的满足当前业务和数据集成中出现的各种常见场景。通过该ESB本身还支持和Camel的集成，支持bigData大数据集成能力，可以算得上一款功能相当完善的ESB服务总线产品。

WSO2ESB总线简单使用

前面对主流开源的Mule，Talend，Fuse等都进行了简单的场景测试和验证，对于WSO2由于下载的原因一直没有进行简单的使用，今天从百度网盘下载到WSO-ESB的最新版本，进行了简单的安装和使用。

WSO2ESB是一个为企业准备的完全成熟的ESB。WSO2ESB是建立在Apache Synapse项目基础上的。Apache Synapse是使用Apache Axis2创建的。对于WSO2前面也有文章提到过，拥有足够完整的产品线，包括完整的PaaS平台产品，同时具备足够的开源性和轻量集成服务能力。

对于产品的安装相当比较简单，在运行前首先还是需要配置好JDK 1.7以上版本和相应的JAVA_HOME和Path路径设置。完成后将ESB压缩包解压到某一个目录，运行wso2server.bat即可，具体简单说明如下：

1. Extract the wso2esb-4.9.0.zip and go to the extracted directory

2. Run the wso2server.sh or wso2server.bat as appropriate

3. Point your favourite browser to

-->https://localhost:9443/carbon

4. Use the following username and password to login

-->username : admin password : admin

对于服务端运行后访问到具体的管控界面，进行一个简单的服务代理测试。可以看到WSO2提供了多种常用的服务代理模板可以供选择，如果是最简单的基于WSDL服务代理，那直接选择WSDL Based Proxy即可，当然我们也可以选择Custom Proxy以进一步熟悉整个服务过程的配置。下面对核心的几个步骤进行简单说明：

1. 定义代理服务

自己定义一个代理服务的名称，注意需要选择wsdl资源文件，建议最好选择本地仓储库中的资源文件，因此可以先将我们本地的wsdl文件拷贝到Reposity目录下面，然后输入具体访问地址，例如：

file:repository/samples/test1.wsdl

其次对于发布服务可以支持http和https，如果本地测试建议只选http进行服务的发布。

2. 定义inSequence配置信息

在这里我们选择define inline，同时选择创建，这时候会显示可供选择的多种endpoint的列表信息，在这里我们选择address endpoint，输入我们实际访问的原始服务地址并验证即可。

3. 定义outSequence配置信息

对于outSequence配置基本是同样的方法，我们需要选择define inline，同时创建一个send节点处理，具体的位置在设计器上面的core-send即可以选择到。定位完成后保存关闭。

经过以上三个步骤基本就完成了一个最简单的proxy服务代理的配置。在这里补充再说明几点如下

对于Proxy服务默认是没有进行log日志的，因此如果需要进行Log日志记录，则需要在定义Sequence inline的时候，在设计器上面增加log节点，当增加log节点后即可以对服务消息进行日志记录。如果需要对输入和输出都进行日志记录，则需要在inSequence和outSequence都增加log信息。

对于进行了日志记录后，可以转到monitor监控Tab中，在system logs中就可以看到详细的log日志记录。当代理的服务较多的时候，我们可以在定义代理服务的时候输入Service Group属性，即可以对服务进行分组管理，在服务列表里面会按Service Group进行分组显示。

对于服务本身的路由功能在WSO里面实现起来还是比较简单，需要在设计器中增加Swith和Case节点进行最终服务目标点Endpoint的路由。具体的路由判断规则采用XPath语句进行解析。

Camel规则引擎和ServiceMix服务总线

对于近期对于开源ESB产品的研究和分析，结合原有自研的轻量ESB产品以及对大型ESB商业套件多年产品实施的经验分析，准备对公司已有自主研发的轻量ESB产品进行一次大的产品改造。

在前面一篇ESB核心产品功能架构的文章里面已经提到，业界常见的ESB产品主要包括了三个核心部分的内容，即ESB服务设计器，ESB底层引擎和ESB管控治理平台三方面的内容。而实际上里面最重要的还是ESB底层核心引擎，业界主流的产品主要包括了两种实现标准，一种是类似Oracle和IBM的商业ESB产品里面基于SCA/SDO标准体系来实现，其更加体现了服务为重点，一种是类似ServiceMix，WSO2等产品则基于JBI标准来实现，更多的体现消息为主。

Camel规则引擎

在这次的底层ESB核心引擎选择上，初步考虑基于Camel来扩展ESB底层核心引擎。或者也也可以说是基于开源的ServiceMix来进行相应的扩展。Camel是一款优秀的规则引擎产品，特别是其对企业EIP集成模式的完全支持，同时对大量外部开源产品的集成，包括CXF，ActiceMQ，JavaBean，FTP，Http，DB数据库等，这些都使得Camel是一个具备足够扩展性和定制能力的可选引擎。虽然对于Camel当前还没有相应的设计器，但是类似Talend，Fuse已经发布有相应的基于Camel的可视化设计器，我们也可以完全开发自己的设计器，前面也有文章谈到过基于Eclipse GMF插件进行设计器的开发等。

对于基于Camel的ESB底层引擎，基于ESB场景的集成服务场景做一些说明：

1. 最常见的proxy service功能的实现

可以看到Camel实现最简单的Proxy Service是相当简单的，其核心能力还是通过CXF组件来实现。对于最简单的代理我们不需要生产相应的Service类，仅仅是请求转发。在CXF框架使用中，可以通过CXF自带的拦截器和Log组件来增加对输入和输出消息体的Log能力。

2. 在proxy Service的实现过程中需要增加Mapping映射能力

举个简单的场景来说，如果Camel通过CXF发布的代理WebService的Schema和我们需要调用的原生WebService之间的shema不一致，那么我们就需要对消息的结构进行映射处理。在Camel里面本身Mapping能力是相当弱的。在实现的过程中主要有两种方式可以考虑，其一是通过XSLT来实现消息体本身的转换，其重点是对于Route传递的消息格式通过XSLT模板文件进行转换和映射；其二是可以考虑通过Camel集成的Dozer组件来实现映射，其核心是通过CXF框架生成出来的Java类对象之间数据结构进行映射。

3. 消息中间件能力和消息本身的发布订阅等

可以看到Camel本身对消息中间件和消息队列能力的集成是相当完善的，其既支持基于JMS实现的ActiceMQ，也支持基于AMQP高级消息队列实现的RabbitMQ等。我们在ESB集成中遇到有消息发送和接收，1对N的消息发布订阅等场景的时候，两种组件都可以选择使用。如果是需要一个高性能的分布式消息发布订阅系统，我们还可以使用kafka组件，可以看到在Camel 2.13版本后已经完全集成了现在使用广泛的kafka消息中间件。

4. 对于集成过程中的路由，分支和判断能力实现

这个不用细讲，Camel本质就是规则引擎，可以看到在Camel里面实现相应的条件路由，分支判断等相当简单。在这部分不是简单的Choice组件和实现代码，看Camel参考手册里面可以看到Camel有大量的Processor组件可以协助我们完成相关的工作，比如split，filter，enrich，loop等。

5. 对于Http Rest服务的集成和服务代理等

可以看到在Camel里面专门提供了CXFRS组件来实现对rest服务的集成和服务代理能力，整个实现起来相当方便。同时Camel本身也提供了Rest和RestLet两个Rest服务相关的组件，对于Rest组件主要在Camel路由节点中可以将Rest定义为相应的Endpoint端点服务，而对于RestLet组件则其本身就可以用来发布Rest服务或消费Rest服务。

6. 对于FTP和文件的适配能力

在Camel里面有专门的File组件和Ftp组件，要实现对FTP服务器或文件目录的集成是相当容易的事情。例如我们可以通过这些组件实现从特定的FTP服务器或文件目录中读取文件，也可以用来将我们最终的消息流持久化到具体的文件中。

7. 对于DB的适配能力已经WS+DB场景实现

在Camel里面可以看到有不少的DB相关的组件，包括JDBC，SQL组件，也包括了Camel对Hibernate，IBatis等O/R Mapping框架的集成。但是我们也看到，这些都是通用的数据库访问组件，不像Talend这些产品对于DB适配有很强的支撑能力。

如果要实现WS+DB的场景，不管是适配到数据库的查询服务还是插入数据到数据库中的导入服务，我们在前端都可以采用CXF框架来实现对消息输入的获取，也可以在后端通过DB组件适配来实现数据库数据的查询或写入。但是其中关键点还是Mapping能力，即服务本身的Schema和数据库本身的查询和插入Sql语句数据项之间的映射。如果没有这种映射，那么对于这种场景我们都会涉及到要单独编写代码或相应的配置文件才能实现。而在类似Mule或Talend ESB工具里面可以看到，这些场景基本都可以通过设计器在前端动态配置完成。

为了扩展Camel这方面的能力，初步考虑的思路即自己对数据库的查询或导入进行封装，将其封装为独立的Java Bean对象，然后在Route的路由节点中增加Endpoint连接到我们自己的Java Bean类上面。基于这种方式需要做的工作就是定义相应的Mapping XML文件，对于不同的场景我们要修改的仅仅是这个配置文件就能够实现不同的数据查询或数据导入服务。

8.对于大数据本身的服务集成能力

在Oracle里面有专门的ODI来实现大数据服务集成，即可以理解为WS+ETL的组合模式。而在Camel里面，由于Camel本身有的足够的开放性，我们可以将自己开发的ETL JAVA组件定义的标准的Java Bean再集成到Camel Route设计里面。初步考虑可以将淘宝开源的DataX进行适当改造后集成到Camel里面以实现大数据集成。

ServiceMix服务总线

Apache ServiceMix是小巧的开源集成容器，它结合了Apache ActiveMQ、Camel、CXF和Karaf的特性和功能到一个强大的运行平台，你可以用它构建属于自己的集成解决方案。它提供了一个由OSGI技术支持的全面的企业预备ESB。

其主要特性（features）包括：

• 基于Apache ActiveMQ的可靠消息
• 基于Apache Camel的消息、路由和EIP（Enterprise Integration Patterns）
• 基于Apache CXF的WS-*和RESTful web服务
• 由Apache Karaf技术支持的基于OSGI的服务运行环境。

通过另外可安装的特性（features），ServiceMix也支持：

• Activiti的BPM引擎
• Apache OpenJPA的完整的JPA支持
• Apache Aries的XA事务管理

仍旧支持JBI标准（在ServiceMix 3.x系列之后已废弃），通过Apache ServiceMix NMR来支持，Apache ServiceMix NMR包含了丰富的Event、Messaging和Audit API。

构建ServiceMix应用方式主要有OSGI Blueprint，OSGI声明式服务和Spring DM（legacy）。可以看到对于一些常见的基础标准常见，直接使用Bludeprint配置文件即可以完成配置。

ServiceMix的官方网站地址为：http://servicemix.apache.org/ 。 其下载和安装部署也相对简单，在下载完成后，可以直接通过QuickStart里面的例子对ServiceMix的基础功能进行熟悉，以最简单的两个文件目录文件集成传输为例来进行说明如下：

首先是需要编写BluePrint.xml的配置文件，具体如下：

由于ServiceMix本身是基于OSGI和Karaf的组件化热部署框架，因此在配置文件开发完成后，只需要将该配置文件拷贝到Deploy目录下即可以完成该文件路由服务的部署。在部署完成后的服务运行后，我们将文件拷贝到camel/input目录下，可以看到文件会被传输和包括到output目录下。

对于具体部署的日志和状态可以通过 log:display 命令进行显示。

对于ServiceMix本身也提供另一个简单WebConsole端，可以通过：

>>features:install webconsole

进行Console管理端的安装，安装完成后通过 http://localhost:8181/system/console 地址访问，以smx/smx进行登录，登录后可以看到当前安装的组件本身的状态，可以查询总线运行相关的服务日志信息。

当前ServiceMix的版本为6.1版本，虽然仍然有对JBI规范的支持，但是也可以看到其核心已经转换为Camel，ActiveMQ和CXF三个核心开源组件的集成。同时基于Karaf实现的OSGI运行环境和容器。Karaf作为一款成熟而且优秀的OSGi运行环境以及容器已经被诸多Apache项目作为基础容器。

对于ServiceMix本身由于重点是在ESB服务运行引擎和开源组件的集成，因此可以看到在SOA治理管控，可视化的服务设计和开发方面都相对欠缺。而且当前ServiceMix相关的文档资料极少，实际在企业应用的场景也不多，如果要学习ServiceMix其核心需要学习的内容还是基于Camel的集成，消息中间件和CXF服务化框架，这三者本身是ServiceMix的基础。

对于服务开发中存在的个性化规则和逻辑的处理，ServiceMix提供了足够的开放性和灵活性，可以通过Eclipse环境进行plugin插件开发，开发完成的插件可以直接部署到deploy目录中。

在JBOSS Fuse ESB被红帽收购了做了较大的整合和商用化，即推出了JBOSS FUSE ESB引擎和基于JBOSS Developer Editon的服务可视化设计和开发。该ESB引擎本身仍然是基于Camel底层的可视化设计和实现，通过设计器的协助可以更加快速和高效的配置和开发ESB服务。

ESB在JAVA领域主要有两种标准，一种是Sun提供的JBI业务集成规范，一个则是由BEA和IBM提出的SCA/SDO标准。可以看到对IBM和Oracle的ESB平台基本采用的是SCA/SDO的标准。而对于开源的ESB如ServiceMix，JBOSS ESB等更多则是基于JBI规范进行实现。

简单说明下OSGI和JBI规范

OSGi(Open Services Gateway Initiative,开放服务网关协议)提供了一个面向服务组件的编程模型，基于 OSGi 编程，具有模块化，标准化，面向服务，动态性，易复用，易扩展，易部署等诸多优点。

OSGi 带来了规范化的模块划分，低耦合的模块间关系，统一的模块开发方式，可动态插拔的模块管理环境。开发 OSGi 应用程序的第一步是在需求分析的基础上进行精心的模块划分，模块划分的原则是尽量保持单个模块的独立性，使模块与模块之间的耦合降到最小，每一个模块暴露给其它模块的信息最少，尽量让模块之间使用 OSGi 框架提供的服务注册机制来通信。一般可采用一个模块一个 Bundle 的方式，并为每一个 Bundle 在 Eclipse 环境中建立一个 Project 来进行开发，由于模块与模块之间的耦合很小，各个 Bundle 之间并不会像传统的开发方式中的各模块之间那样存在纠缠不清的包和类的引用关系，因此大部分Bundle的开发工作可以并行进行而不会互相影响。

JBI的本质是一种服务总线思想。JBI的目标是创建一个用于各种Java组件服务集成的运行环境。JBI容器以一种可插拔的方式集成不同类型的服务，而不是通过编写客户端代码来实现服务的集成。目前流行的服务容器有Servlet容器、EJB容器、JMS容器。

• Servlet容器只能处理以HTTP/SOAP协议传输的消息（接收与响应）；
• EJB容器只能处理RMI协议传输的消息；
• JMS容器则处理的是JMS协议传输的消息；

它们之间无法进行通讯，如果想集成上面不同类型的容器服务，则必须有一种能融合以上不同容器的 新容器出现。JBI就是基于解决这种问题的思路出现的，JBI提供了各种各样的容器绑定组件（Binding Component,称BC）,BC专门负责接收各种各样的传输协议的消息与发送请收消息给外部容器。当然JBI还提供其它的功能，要不这纯属一种代理 了，就没什么意义；

JBI提供处理各种业务的组件（即Service Engines组件，称SE）的消息，比如接收到HTTP的消息后需要转发给外部组件EJB，则需要SE组件来进行转换（更准确的说是Transform SE组件）。其实BC与SE之间是无法直接通信的，所有的消息都是通过传输通道（Deliver Channel）传送到NMR（Normalized Message Router），再由NMR通过DC将信息转到SE或BC的。

对比分析总结

一般来说，由于ESB产品属于SOA这个更大概念的范畴，因此，在实施SOA项目时，会需要其它产品或组件的支持，比如BPM产品、规则引擎产品、服务注册产品。在比较大规模的SOA项目中，几乎总要用到上述几类产品之一或全部。但是开源的ESB肯定是无法提供如此丰富的产品线，在复杂的应用场景下，开源ESB需要与其它的产品或项目进行配合才能完成任务。

因此，专有的商业套件，从功能的完备性、维护、管控等角度来看，肯定是涵盖面最全的，如果一定要选择开源ESB，那么Mule或ServiceMix是可以考虑的比较成熟的选择，但是自行开发组件的工作量是必不可少。

欢迎关注@人月聊IT 分享SOA，微服务，DevOps平台规划和建设。