问题：企业应用程序集成（EAI）
由于新产品和新应用，几乎每个公司都必须进行企业应用程序集成。 集成这些应用程序会产生一些问题。 每十年出现新的范例，例如客户端/服务器通信，面向服务的体系结构（SOA）或云计算。
此外，出现了不同的接口，协议和技术。 如今（而不是过去（很多年前））将数据存储在文件中，而不再使用SQL数据库。 有时，在某些用例中甚至需要NoSQL数据库。 同步远程过程调用或异步消息传递用于通过多种技术（如RMI，SOAP Web服务，REST或JMS）进行通信。 存在许多软件孤岛。 尽管如此，这几十年来的所有应用程序和产品都必须相互通信才能完美地协同工作。
企业集成模式（EIP）
当然，您可以彻底解决每个问题，编写一些意大利面条式代码，并使应用程序协同工作。 不幸的是，您的管理层将不喜欢该解决方案的长期前景。
企业集成模式（www.eaipatterns.com）帮助分散问题并使用标准化方法集成应用程序。 使用这些，您总是使用相同的概念来转换和路由消息。 因此，最好在每次遇到问题时都不要重新发明轮子。
集成系统的替代方法
存在用于集成应用程序的三种选择。 EIP可以在每种解决方案中使用。
解决方案1：自己的自定义解决方案
实施适合您的问题的单独解决方案，而不必将问题分成几小部分。 这可行，并且可能是小型用例的最快替代方案。 您必须自己编写所有代码。 如果团队成员更换，维护成本可能会很高。
解决方案2：集成框架
使用有助于使用几种集成模式以标准化方式集成应用程序的框架。 它大大减少了工作量。 每个开发人员都将很容易理解您的工作（如果他知道所使用的框架）。
解决方案3：企业服务总线（ESB）
使用企业服务总线来集成您的应用程序。 在幕后，ESB还使用了集成框架。 但是还有更多功能，例如业务流程管理，注册表或业务活动监视。 通常，您可以在图形用户界面中配置路由和诸如此类的东西–您必须自己决定是否可以降低复杂性和工作量。 通常，ESB是一个复杂的产品。 学习曲线要高得多。 但是，您将获得一个非常强大的工具，该工具应该可以满足您的所有需求。
什么是Apache Camel？
Apache Camel是一个轻量级的集成框架，可实现所有EIP。 因此，您可以使用所需的模式轻松集成不同的应用程序。 您可以使用Java，Spring XML，Scala或Groovy。 您可以想象到的几乎每种技术都可以使用，例如HTTP，FTP，JMS，EJB，JPA，RMI，JMS，JMX，LDAP，Netty，以及许多很多其他技术（当然，大多数ESB也提供对它们的支持）。 此外，可以非常轻松地创建自己的自定义组件。
您可以将Apache Camel作为独立的应用程序部署在Web容器（例如Tomcat或Jetty），JEE应用程序服务器（例如JBoss AS或WebSphere AS），OSGi环境中或与Spring容器结合使用。
如果您需要有关Apache Camel的更多信息，请访问其网站作为起点： http : //camel.apache.org 。 本文暂无技术介绍J
什么时候使用Apache Camel？
如果要集成具有不同协议和技术的多个应用程序，Apache Camel很棒。 为什么？ 我非常欣赏其中一项功能（除了支持多种技术之外，还支持不同的编程语言）： 每个集成都使用相同的概念！ 无论您使用哪种协议。 无论您使用哪种技术。 无论您使用哪种域特定语言（DSL），它都可以是Java，Scala，Groovy或Spring XML。 您以相同的方式进行操作。 总是！ 有生产者，有消费者，有端点，有EIP，有自定义处理器/ bean（例如用于自定义转换）和参数（例如用于凭证）。
这是一个包含使用Java DSL的所有这些概念的示例：
from（„ activeMQ：orderQueue“）.. transaction（）。log（„ processing order“）。to（mock：“ notYetExistingInterface”）
现在让我们看一下使用Scala DSL的另一个示例：
“ file：incomingOrders？noop = true”过程（新的TransformationProcessor）到“ jdbc：orderDatastore”
如果您是开发人员，那么您应该能够认识到这些路线的作用，不是吗？
另外两个非常重要的功能是对错误处理（例如，使用死信队列）的支持和自动测试。 您可以使用Camel扩展的JUnit轻松测试所有内容！ 同样，无论您要支持哪种技术，您都始终使用相同的概念。
Apache Camel已经成熟，可以投入生产了。 它提供可伸缩性，事务支持，并发和监视。 FuseSource可提供商业支持： http : //fusesource.com/products/enterprise-camel
什么时候不使用Apache Camel？
好吧，是的，在某些用例中，我不使用Apache Camel。 我已经在下图中说明了这一点（请记住我上面提到的三种选择：自己的自定义集成，集成框架，企业服务总线）。
如果您只需要集成一种或两种技术（例如读取文件或发送JMS消息），则使用一些众所周知的库（例如Apache Commons IO或Spring JmsTemplate）可能会更容易，更快捷。 但是请务必使用这些帮助程序类，纯净的File或JMS与try-catch-error集成非常丑陋！
尽管FuseSource提供了商业支持，但我不会将Apache Camel用于大型集成项目。 在大多数情况下，ESB是完成此任务的正确工具。 它提供了许多其他功能，例如BPM或BAM。 当然，您也可以使用几个单一的框架或产品并“创建”自己的ESB，但这是浪费时间和金钱（在我看来）。
已经有几种生产就绪的ESB。 通常，开源解决方案比诸如WebSphere Message Broker之类的商业产品更轻巧（您可能只需要一两天即可安装该产品的评估版）！ 著名的开源ESB是Apache ServiceMix，Mule ESB和WSO2 ESB。 顺便说一句：您是否知道某些基于Apache Camel框架的ESB（例如Apache Service Mix和Talend ESB）。 因此，如果您喜欢Apache Camel，则也可以使用Apache ServiceMix或基于ServiceMix的商业化Fuse ESB。
结论
Apache Camel是一个很棒的框架，用于将应用程序与不同的技术集成在一起。 最好的事情是您始终使用相同的概念。 此外，对许多技术的支持，良好的错误处理和轻松的自动测试使其可用于集成项目。
由于每个公司的应用程序和技术的数量将进一步增加，因此Apache Camel拥有美好的未来。 今天，我们有了应用程序孤岛，十年后，我们可能会部署在Goggle App Engine，CloudFoundry，Amazon EC3或任何其他云服务中的云孤岛。 因此，我希望Apache Camel也不会为适应云时代做好准备（例如，通过提供易于连接到云框架的组件）。 但这就是未来。如果您必须在JVM / Java环境中集成应用程序，那么现在您真的应该尝试一下该框架。
顺便说一句：我知道我在本文中赞扬Camel，但我既不是Camel的提交者，也不是FuseSource的工作人员。 我只是真的很喜欢这个框架。
最好的祝福，
参考： 何时使用Apache Camel？ 从我们的JCG合作伙伴 Kai Wahner在关于Java EE / SOA /云计算的博客上的博客。
翻译自: https://www.javacodegeeks.com/2012/07/when-to-use-apache-camel.html
