基于ApacheCamel引擎实现企业应用和接口集成

　　今天分享下原来整理的基于Apache Camel来实现企业内部业务系统间的接口集成。
　　包括我们自主研发的ESB服务总线，其底层也是采用了Camel规则引擎来进行底层的协议转换和数据映射等。虽然现在微服务架构下以更加轻量的API网关进行接口集成为主，但是对于企业存在传统IT应用和遗留系统集成的场景下，仍然需要考虑多协议转换和接口适配的问题。Apache Camel概述
　　Apache Camel十一个Java库和引擎，有多种不同的整合模式，然而他并不是BPMN或者ESB，虽然可以在此引擎下实现他们。Apache Camel是一个编程人员调节、整合问题的工具。其核心架构如上图，我们看到的是一些不同的相互链接的构件，而在他们中间起链接作用的粘合剂就是Camel Context了。他将实体链接一起，有的时候被称为Camel运行是容器。
　　Apache Camel是一个轻量级的集成框架，它实现了所有EIP。因此，您可以使用EIP所需的图案容易地集成不同的应用。您可以使用Java，Spring的XML，scala或Groovy。几乎每一个技术，你可以想象是可用的，例如HTTP，FTP，JMS，EJB，JPA，RMI，JMS，JMX，LDAP的Netty，和很多很多（当然大多数ESB还提供了对他们的支持）。此外，自定义的组件可以很容易地被创建。
　　您可以部署Apache的骆驼作为独立的应用程序，在Web容器（如Tomcat或Jetty），在JEE应用服务器（如JBoss应用服务器或WebSphere AS），在OSGi环境或与Spring容器组合。
　　当Camel和其它开源的组件包括OSGI，Maven，Karaf，CXF，ActiveMQ，DataBaseAPI，JMS结合后，即可以实现当前企业应用集成的大部分集成场景。对于当前开源ESB，Apache ServiceMix本身也是基于Camel来实现的一个集成服务总线，其底层核心能力仍然是Camel和ActiveMQ，同时通过Karaf和OSGI来实现了组件化的服务架构。而当前已经商用的redhat JBOSS Fuse也是基于Camel的一个商用化实现，并通过JBOSS Developer Edition来增加了可视化的设计和编排功能。
　　对于Camel我们最关心的还是在哪些集成场景下能够使用的问题，因此我们从集成场景来分析具体可能使用到Camel的地方。首先分析集成场景，再来分析Camel的其它一些扩展能力。
　　Ftp文件集成的场景 : 该场景可以应用到文件集成，即将文件从某一个FTP或目录，传输到一个目标FTP目录上。基于Camel本身的配置，可以实现对目录监听的频率，文件筛选过滤等各种关键属性的配置。
　　消息集成场景：该场景核心是基于ActiveMQ集成来实现，即可以将Camel接受到的各种输入的信息，包括在接收输入过程中产生的事件都发送消息到MQ存储。我们可以再增加一个读取消息的独立配置组件，来从MQ中读取消息。当然我们还可以增加路由和判断功能后，将MQ接收到的消息根据路由规则分发到再下一层的二级MQ消息队列中。消息的输入：可以是Http Request, WS，FTP，JMS，MQ等多种方式。 消息的输出：可以是文件，Log日志，DB数据库，下游MQ，HttpResponse等多种形式。
　　Camel通过和ActiveMQ的集成，基本可以实现传统消息中间件的核心功能，包括基于消息的异步集成，基于消息的发布订阅机制等。通过通过ActiveMQ也可以很好的来实现在服务集成过程中的日志管理能力。
　　Http集成：Camel可以集成Http的能力，其中一方面是可以将Http请求作为输入进行后续处理。一方面是对于原生的Http请求服务，可以通过Camel进行Http服务请求的代理。在实现Http请求代理的过程中我们可以增加处理组件对Http请求的内容进行加工，映射和内容丰富等。
　　WS服务集成：对于WS服务的集成重点是通过Camel和CXF框架的集成来实现。其中既可以对常规的Java API接口发布为标准的Web service服务。也可以对已有的WS服务进行Proxy服务代理，同时在进行服务代理的过程中增加对服务输入内容的处理，数据映射和内容丰富，对服务请求内容进行Log处理等。
　　数据库集成能力：可以看到在Camel的整体集成框架里面既可以通过传统的JDBC同数据库集成，也可以通过Hibernate, iBatis等框架实现和数据库的集成。在和DB的集成中，一方面是读取DB中的数据，一方面是将输入的请求通过SQL语句更新或写入到DB数据库表中。这些都可以通过Camel配置文件来实现。
　　对DB集成和传统的ETL最大的区别就在于Camel的DB集成更加容易将Http，WS和DB数据库操作能力整合起来。即通过Http或WS服务请求调用来触发对DB的读取和数据插入操作。这种集成方式将比传统的ETL数据集成更加灵活和方便。
　　除了以上核心集成能力外，可以看到Camel本身还提供的在集成过程中的扩展能力调度任务：支持该能力，可以将配置的集成组件配置为定时周期性的调度任务进行处理。 日志能力：支持，可以对在集成过程中的消息输入，输出等进行Log日志记录。 数据映射：支持，支持在camel配置过程中消息输入和输出之间的数据映射和转换。 路由能力：支持，路由可以使用过滤器、多播、接收列表、并行处理来定义，从而变得非常灵活。 热插拔：支持，本身基于OSGI框架和Karaf来实现了组件化容器和集成组件的热部署和管理。 异常处理：支持，可以处理在消息集成过程中的异常，并对异常进行管理和Log记录
　　可以看到Camel本身已经具备ESB总线的底层核心能力，这也正是开源的ServiceMix基于Camel来实现的基础。同时由于本身基于OSGI和组件化架构，我们可以很容易的根据集成场景和实际集成需求对Camel进行扩展。对于Camel本身集成的性能当前还没做过详细的性能测试，暂时不进行描述。基于Camel实现接口集成分析
　　业界常见的ESB产品主要包括了三个核心部分的内容，即ESB服务设计器，ESB底层引擎和ESB管控治理平台三方面的内容。
　　而实际上里面最重要的还是ESB底层核心引擎，业界主流的产品主要包括了两种实现标准，一种是类似Oracle和IBM的商业ESB产品里面基于SCA/SDO标准体系来实现，其更加体现了服务为重点，一种是类似ServiceMix，WSO2等产品则基于JBI标准来实现，更多的体现消息为主。
　　在底层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容器。
　　1. Servlet容器只能处理以HTTP/SOAP协议传输的消息（接收与响应）； 2. EJB容器只能处理RMI协议传输的消息； 3. 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的。
　　注：本文为历史文章重新整理，相关开源软件功能可能和当前最新版本有差异。