Apache SOA 与 Mule
我正在寻找 Apache ESB/SOA 堆栈（Servicemix、Camel、ActiveMQ、CXF）与同类 Mule 技术的高级技术差距分析。
此外，我试图更好地了解开发人员如何看待这些框架的学习曲线、稳定性、可扩展性和满足客户需求的整体能力......
I'm looking for a high level technical gap analysis of the Apache ESB/SOA stack (Servicemix, Camel, ActiveMQ, CXF) vs. comparable Mule technologies.
As well, I'm trying to better understand how these frameworks are viewed amongst developers in terms of learning curve, stability, scalability and overall ability to meet client requirements...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这不是真正的答案，但太长，无法添加为评论。
Gartner 进行了此类比较（示例），因此福雷斯特 (示例1; href="http://www.forrester.com/rb/Research/wave™_enterprise_service_bus,_q2_2011/q/id/58074/t/2" rel="nofollow">example2），但他们的论文是：
我个人有使用 Oracle Fusion（差）、Tibco（更好）和 Vitria（过时）的经验，但我无法应对进行详细比较的挑战...
It's not really an answer, but too long to be added as a comment.
Gartner does such comparisons (example), so does Forrester (example1; example2), but their papers are:
I personally have experience with Oracle Fusion (bad), Tibco (better) and Vitria (outdated), but I'm not up to the challenge to do a detailed comparison...
除了 Spring XML 之外，Camel 还使用 Java 领域特定语言来配置路由规则并提供企业集成模式
Camel 的 API 更小并且更小。更干净（恕我直言），并且与 JBI、CXF 和 JMS 的 API 紧密结合；基于消息交换（带有输入和可选的输出消息），更紧密地映射到 REST、WS、WSDL 和 REST。 Mule 是基于 JBI 比 UMO 模型
Camel 允许轻松公开底层传输详细信息（例如，JmsExchange、JbiExchange、HttpExchange 对象公开所有底层传输信息和行为（如果需要）。请参阅 Camel API 与
Camel 在核心 API 中支持隐式类型转换器，以便更轻松地将需要不同类型负载和数据的组件连接在一起。标头
Camel 使用 Apache 2 许可证，而不是 Mule 更具限制性的商业许可证
Camel uses a Java Domain Specific Language in addition to Spring XML for configuring the routing rules and providing Enterprise Integration Patterns
Camel's API is smaller & cleaner (IMHO) and is closely aligned with the APIs of JBI, CXF and JMS; based around message exchanges (with in and optional out messages) which more closely maps to REST, WS, WSDL & JBI than the UMO model Mule is based on
Camel allows the underlying transport details to be easily exposed (e.g. the JmsExchange, JbiExchange, HttpExchange objects expose all the underlying transport information & behaviour if its required). See How does the Camel API compare to
Camel supports an implicit Type Converter in the core API to make it simpler to connect components together requiring different types of payload & headers
Camel uses the Apache 2 License rather than Mule's more restrictive commercial license
Mulesoft Anypoint 是一个随时可用的全栈集成平台。 Apache 组件在功能上提供类似的功能，但通常需要更多时间来实现和支持。两者都允许下降到 Spring / Java 级别，因此两者都不存在真正的技术差距。选择取决于业务目标、可用预算以及集成项目的范围和数量。 Mule 可以缩短上市时间，也更容易操作，但价格并不是特别便宜。 Apache 堆栈是免费的，但开发人员的时间（通常）不是免费的。
Mulesoft Anypoint is a ready to use full-stack integration platform. Apache components functionally provide similar capabilities but generally take more time to implement and support. Both allow dropping down to Spring / Java level therefore no true technical gaps in either. The choice would depend on the business goals, available budget, and the scope and number of the integration projects. Mule offers better time to market and is easier to operate, but ain't particularly cheap. Apache stack is free but developers' time (generally) is not.
Camel 是一个 EAI 框架，它没有自己的运行时，但另一方面 Mule 是完整的 ESB 产品，拥有自己的运行时。 Mule 有很多连接器可以与其他系统集成，并作为轻量级 ESB 发挥作用。开发人员可以完全自由地编写自己的连接器或调用现有的 Java 库以避免返工。
Camel is a EAI Framework and It doesn't have it's own runtime but other side Mule is full ESB product having it's own run-time. Mule has lot of connector to integrate with other system and stand itself as light weight ESB. Developers have full liberty to write own connector or invoke existing Java library to avoid rework.