嘿,
如果我们有Apache Camel为什么要使用Apache ServiceMix和Mule等其他解决方案？
Apache Camel与这些产品相比无法做到吗？
何时使用Mule/ServiceMix以及何时使用Camel？
现在是2016年,自从最初提出这个问题以来已经发生了很多变化,所以我想重新审视新观众.
Apache Camel 一直坚持其根源,并没有发展成为重量级的,也不是完全成熟的运行时平台.它是多功能和模块化的,可以运行:
嵌入在任何类型的Java容器(servlet容器,应用程序服务器,Spring Boot)中.
独立作为Java进程.
在OSGi环境中(Apache Karaf).
Apache Camel每月都在不断发展并获得牵引力和活动,正如我从OpenHub中提取的图表所描绘的那样.用户群也在不断增加.
2012年,Red Hat收购了FuseSource,后者是Apache Camel,ActiveMQ,ServiceMix和CXF的主要推动者和开发者之一.Red Hat现在聘请了几个提交者和PMC成员来处理Apache Camel.
Mule ESB提供两种版本的产品:社区(CPAL许可下免费)和企业(付费).他们将社区版本定义为:
非常适合评估或预生产使用.
=>这意味着您应该获得生产使用的付费企业订阅.
事实上,Mule ESB Community Edition是根据CPAL许可证分发的.这意味着如果你仍然决定使用这个版本,骡子需要:
每次启动或最初运行可执行文件和源代码或更大的工作时,最终用户使用的图形用户界面上必须出现Mulesoft的归因信息的显着显示,以访问此类涵盖代码(可能包括在启动画面上显示) ),如果有的话.=>基本上你需要宣传你使用Mule构建的任何内容都在Mule上运行.
如果您通过网络访问Mule ESB的部署(它始终是,因为它是一个集成平台!),您还必须使部署的源可供访问它的任何人使用.
正如上面提到的其他人,Apache Camel是一个完全开放的项目,由社区和社区推动.所有源代码都是公开的,鼓励每个人发送拉取请求,提供组件并在论坛中提供帮助或查询.相反,Mule社区是一个封闭式社区.
最后但并非最不重要的; 也许是最重要的部分.以下是Google趋势对Mule ESB与Apache Camel的看法.请注意,我使用新的语义主题测量来获得更高的准确性,而不是标准的查询关键字.这样我们就不会测量动物(Mule vs Camel)的受欢迎程度,而是测量软件的受欢迎程度!解读:从2007年到2011年,骡子大幅度下降,而阿帕奇骆驼则趋于稳定.自2011年以来,Mule已经达到稳定水平,而Apache Camel则保持健康趋势!
只是想在2010年9月25日(当您最初提出问题时)为您提供有关Apache Camel演变的一些功能指标.这是该时间点的源树.
当时,Camel有88个组件,现在有220个组件,包括与Facebook,Twitter,Salesforce,Apache Ignite,Apache Cassandra,AWS,Apache Kafka,MongoDB,Apache Spark等的集成.
许多技术改进:异步路由引擎,消息历史,断路器EIP,EIP的许多改进和增强,如聚合,拆分,动态路由等.
生态系统已发展到现在还包括Hawtio进行监控和管理,fabric8部署等.
从那时起,已经解决了超过5500张门票,包括新功能,改进,错误等.
还有更多!
在过去的5,25年里,这两种产品都经历了很多发展!但是,由于Mule ESB和Apache Camel的许可证和社区性质不同,我认为它们不再具有可比性.
Apache Camel是完全开源的❤️,而Mule ESB社区要求用户归因于Mulesoft并发布使用Mule的软件的源代码.Apache软件许可证是一种商业友好型许可证:您可以自由使用没有归属的Camel或任何其他要求.真正像啤酒一样免费!
希望过去几年的这种反思有助于新观众!:)
免责声明:我是Apache Camel项目的提交者和PMC成员.
Apache Camel是一个实现企业集成模式(EIP)的库.虽然它可以使用Spring作为其IOC框架,但它甚至不依赖于Spring,因此它完全独立于平台.它只是一个图书馆.因此,您可以在任何JVM环境中运行它,例如简单的jvm,servlet,ejb,osgi.它没有带来容器这样的骡子的任何好处(或开销).在我看来,它在这个领域更清晰地分离了关切.
Mule也可以嵌入不同的环境中,但我认为Mule具有将EIP库耦合到容器的优点和缺点.当你在servlet或ejb环境中部署Mule时,你真的想要携带Mule容器的所有包袱吗？我不是骡子专家,我认为你可能花费相对适度的努力并清理掉一些冗余功能.(注意,在所有情况下这都是不错的功能,如果你在另一个容器中运行嵌入,那就太多了.)
Apache ServiceMix是一个OSGI容器,它使用Camel实现EIP作为ESB的基础.虽然ServiceMix历史上始于JBI,但它已经从JBI转移到了(IMO)一个很好的分层架构,它在OSGI容器中结合了最好的Apache CXF,Camel和ActiveMQ.这里的主要价值不是ServiceMix及其JBI支持,而是基础OSGI容器标准与经过验证的Apache传输相结合,如用于Web服务的CXF和用于JMS的ActiveMQ.OSGI是一个成熟的标准,它提供了一个容器,可以解决在.NET出现之前困扰Microsoft的相同类型的"DLL"地狱.虽然.NET和OSGI都没有解决潜在问题的基本复杂性,但它们至少提供了解决它的方法.OSGI也有其他好处,但从产品选择的角度来看,基于标准的容器是主要的,而Mule(和Java一般)没有解决的基本特性是依赖管理.
将Mule与Apache社区进行比较时需要注意的一些重要事项.从某种意义上说,Mule就像Redhat一样,虽然它是一个开源许可证但在我看来并不是一个开放的社区.任何人都可以参与Apache,而MuleSoft拥有Mule社区和最终路线图.其次,虽然Mule社区可以说非常活跃,但我认为Apache社区要大得多(当然,因为它不是一个封闭的社区).两种方法都有加号和减号.对Apache方法的一个好处是,有多个基于Camel,CXF,ActiveMQ和OSGI的ESB供应商.例如,Talend在没有ServiceMix JBI历史的情况下提供相同核心技术的ESB.这在Apache社区中既有加分也有缺点,但真正的重点是突出Apache和Mule之间的区别.你不会在Mule社区找到多个供应商.所以IMO像Talend或ServiceMix这样的Apache ESB是一个更广泛,更具包容性,最终竞争的社区,而不是像Mule这样的封闭社区.
埃德奥斯特
我的博客文章正好回答了这个问题:http://www.kai-waehner.de/blog/2011/06/02/when-to-use-apache-camel/ => Apache Camel是一个轻量级的集成框架,ServiceMix和等等都是完整的ESB.
Camel是一个中介引擎,而Mule是一个轻量级的集成平台.不同之处在于,Mule提供ESB的所有功能,包括用于部署应用程序,REST和Web服务的容器.Mule可以以相同的方式嵌入Camel,以允许应用程序开发人员使用其集成代码嵌入应用程序代码.两者都与Spring紧密集成.
Mule没有使用JBI 的原因很多,现在JBI规范已被解散(没有工作组,由Oracle拥有,最初传递JBI规范)没有良好的专业或技术理由使用JBI.
京公网安备 11010802040832号 | 京ICP备19059560号-6 