轻量级的开源集成：Apache Camel还是Spring集成？

首先，为全面披露信息，在过去的1.5年中，我一直担任 FuseSource（现为Red Hat）的顾问，为零售，运输，银行/金融等不同行业的大型和小型公司提供SOA和集成项目支持。我的专长是使用该领域的一些最佳开源项目来设计具有高可伸缩性和吞吐量要求的解决方案： Apache ActiveMQ ， Apache Camel ， Apache ServiceMix ， Apache CXF等。

我是Apache Camel的DZone Refcardz之一的作者，标题为“ Apache Camel Essential Components” ，也是同一标题的网络广播的发言人。我还是Packt Publishing即将出版的关于Apache Camel的书的技术评论员，我希望很快能公开发布该书。

不用说，我已经使用Apache Camel做过一些工作，对此我有所贡献，并鼓励人们进行检查。

但是在我开始使用FuseSource之前，我曾在其他中间件集成项目中工作过-一些开源，一些商业，但是我第一次尝试轻量级开源集成项目并不是使用Apache Camel。

我在2009年偶然发现了Spring Integration ，非常喜欢它。

我写了有关Spring Integration的博客，对用户论坛做出了贡献，对bug修复和示例做出了贡献等，在社区中保持了一些活跃。我非常尊重Mark，Oleg，Gary，Gunnar等。等在Spring Integration上所做的出色工作。

placeholder_video_spring_projects 我喜欢它如何扩展Spring以及它如何紧密实施由Gregor Hohpe和Bobby Wolf分类的Enterprise Integration Pattens 。那时我在几个项目上使用了它，我坚信除非您在实际项目中使用过它来解决实际问题，否则您对项目没有真正的感觉。但是，由于我有机会足够深入地使用了这两个项目，因此我想为Blogo贡献我的观察和见解

首先，有很多文章比较了两个项目。有些关注统计数据，例如社区活动或组件数量。尽管在某种程度上相关，但我想更深入一点。因此，以下博客文章是我对Apache Camel和Spring Integration的想法，以及（破坏者警报！）为什么我会选择Camel作为集成项目。

抽象，抽象，抽象

这两个项目旨在满足类似的需求：轻量级集成库，具有EIP的完整实现，用于中介和路由，以及在常用技术之上提供抽象以与外部系统接口。一些常见的技术包括Web服务（SOAP / REST），JMS或异步消息传递，基于文件的批处理系统，TCP套接字，FTP / SFTP，RDBMS等。基本上，只要两个异构系统需要同步或异步进行交互并交换数据，轻量级的集成库就可以为您提供极大的帮助。对于那些问“不是ESB做什么的人？” ..恩……有点……但是我可以再写一次。

对于我们这些集成系统的人来说，我们很快就能发现关于集成的两件事。＃1不性感，＃2很难。
了解技术，语义以及系统如何用于实现业务功能方面的差异至关重要。您最终编写的代码应专注于这些业务问题，并应尽可能利用现有的商品组件。编写代码以与文件系统交互或将消息发送到队列绝对被认为是商品代码，只是增加了必须维护的代码库。如果您手工/自己编写代码，那么您还可能承担将错误引入对业务逻辑或业务语义不重要的区域的风险。以我的拙见，这是不必要的风险。

这样便可以使用Apache Camel或Spring Integration。它们通过提供对社区审核过的商品组件的访问以及实现常见的EIP（例如转换，路由，过滤，拆分/聚合等）来帮助简化集成项目。再次..由社区审查。如果您手动编写这些代码，祝您好运。当然可以做到，人们一直都在这样做，但这对大多数项目来说都是不必要的风险。

我在哪里

是的，因此您可以将这两个项目中的任何一个视为特定技术之上的“抽象”。这个抽象概念使您可以专注于“集成应该做什么”。为了解决这个问题，我相信Apache Camel很有意思。

领域特定语言

集成要比编写的要经常读得多..与代码相同。因此，就像您渴望编写具有短函数，描述性变量，适当级别的数据隐藏等的精美代码一样，集成项目的编码也是如此，但将其带入了一个新的高度。您想要对其进行编码，以便您可以阅读并理解它。尽管使用了集成代码，但是即使您的代码编写得井井有条，“正在集成的内容”的全部含义和意图最终仍会丢失在成堆的代码中。您可以利用集成抽象库，但是尽管它们达到了上述目的，但您想要的是清楚地回答“正在集成什么”。

Apache Camel提出了一种领域特定语言，我相信这是两个项目之间的重要区别。使用DSL，即使面对中等到复杂的集成，其他项目也开始变得不清楚，您可以非常简洁明了地表达“正在集成的内容”。 Apache Camel 以Java（我最喜欢的），Spring XML，Scala，Blueprint-OSGI，Groovy ..以及其价值（甚至是Kotlin）提供DSL。

使用DSL，您可以使用“ from”，“ split”，“ choice”和“ to”之类的结构来构建集成“ Routes”。这些使您可以用通用语言指定“集成正在做什么”。

当我使用Spring Integration时，他们没有DSL。您使用Spring XML直接处理了通道和组件（管道和过滤器），而通道是主要的抽象。他们当时在Scala DSL上工作，但是尽管我很喜欢Scala，它仍然没有得到广泛使用，因此出于在通用语言或XML集成项目中使用它的目的，没有太多选择。基本上，您将端点（如jms-gateway或http-gateway）与通道连接在一起，并将通道的另一端连接到EIP（如Splitter或Router）。但是对于要连接的每个组件，您还必须注意所使用的通道是什么，输入是什么，输出是什么。

并且一旦您的项目开始增长，您就会发现通道对象激增。最终稀释了集成的含义。

例如，看一下Cafe Spring Integration Example 。这个例子并不是很复杂，但是它说明了我遇到的问题。想象一下在许多Spring上下文文件中拆分通道和组件，您会看到它如何变得非常混乱。

这是使用Apache Camel实现完全相同的示例的方法：

当然，我不希望人们能够在不了解或未使用每个相应库的情况下准确掌握每个示例的工作，但是毫无疑问，我发现阅读以骆驼式DSL表示的富有表现力的DSL更容易。与尝试解释所有通道的SI路径/流量。这使我更接近“此集成的功能”，而不会为细节所困扰。

测试中

编写集成流程的另一个非常重要的部分是测试。我不会像往常一样大声疾呼，如果不测试代码，你会是个傻瓜，但是如果不测试集成，甚至会加倍。他们所能达到的复杂程度以及所涉及的中介，都需要验证其是否有效！！

当时，Spring Integration没有专门用于测试路由的良好实践。大概是因为他们已经有一个针对Spring本身的通用测试框架。您可以肯定地做到这一点，因为我们都习惯于使用Spring编写单元测试或集成测试，并使用EasyMock或Mockito模拟合作者，对吗？而且，如果您需要任何额外的功能，则必须自己构建它们。

但是，有了Apache Camel，就可以立即使用丰富的测试支持，并且可以很容易地使用它来鼓励测试您的路线。 Camel的测试框架建立在Spring Test的某些功能之上，因此最终成为两全其美。例如，您可以模拟会影响实时系统的路由部分，并专注于路由和中介功能。您可以像使用Mockito一样设置期望和断言行为，但是它内置在库中并添加了其他功能。我的同事David Valeri拥有出色的测试和调试博客，以及他在CamelOne上的演讲

例如，在以下代码段中，我们可以断言在5000ms的时间内在模拟端点上收到了两条消息：

您甚至可以通过应用AOP建议来模拟实时端点，如下所示：

除了模拟组件之外，如果您在执行OSGI时无需部署到容器，您还可以获得协助测试Blueprint XML的功能，可以使用DataSet组件进行浸泡测试或压力测试，以及许多其他复杂的测试方案。

查看这些链接以获取更多信息：

端点测试：数据集
端点测试：模拟
端点测试：测试
淘汰实时技术
骆驼测试
骆驼弹簧测试
蓝图测试

社区

最后，但同样重要的是，我想指出的是，Apache Camel拥有一个充满活力的多元化社区，由来自世界各地的不同公司的不同项目的参与者组成。在写到邮件列表或提交JIRA之后，几分钟之内就可以得到回复。您希望在非营利性的核心开源基金会（如Apache Software Foundation ）中找到的同一生态系统与在其他项目中发现的完全不同。

我当然不是说Spring Integration论坛和JIRA并不活跃，但是我认为Apache Camel项目中非项目或公司（VMWare / SpringSource）人员的活动更多。在我看来，这倾向于培养更多的创造力，更多的外部人做出贡献并使项目变得更好等。这是开源和开放社区发展的核心。当然会有更多的争论，但最终结果是非常积极的。

在有关Spring Integration与Camel的其他一些文章中，作者指出Camel比Spring Integration具有更多的组件。这里有一个更大的连接选项方面的观点，但我认为更重要的一点是，其中许多是由非核心的Camel开发人员贡献的。另外，您可以尝试在github上进行快速搜索，您会发现人们编写的Camel组件甚至还没有带到Apache社区，但是您仍然可以利用。