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

apache camel

首先，为全面披露信息，在过去的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）与通道连接在一起，并将通道的另一端连接到诸如Splitter或Router的EIP。但是对于要连接的每个组件，您还必须注意使用哪个Channel的输入是什么，以及它具有什么输出。

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

例如，看一下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社区，但是您仍然可以利用。