我正在考虑将一个ESB集成到现有的基于Java/Maven的Web产品中。具体而言，我正在研究ServiceMix和Mule。该产品将连接到多个不同的服务，包括电子邮件、Quartz、通过HTTP的RESTful Web服务、短信和即时通讯（IM）。我只是快速地浏览了文档，这两个选项似乎都比较复杂。这似乎是使用ESB的典型案例，但我不想花太多时间学习其中的任何一个系统。
就像我说的，我已经通过Maven构建了一个Web应用程序，并希望集成其中一个系统会很简单，即使只是像发送一封电子邮件这样简单的操作，但看起来添加任何一个系统都需要引入大量JAR包，并且难以嵌入到现有产品中。
值得尝试引入其中一个选项吗？有没有一种简单的方法可以将它们集成到现有应用程序中，而不完全重构它？有没有其他更轻量级的选项？有哪些方面应该考虑，才能使它们的使用变得有价值？
Mule 在使用上非常简单，通过 XML 将服务插接在一起，他们有大量的视频示例，我发现这真的很有帮助。
ESB 是未来的趋势，就像你所说的 - 你的确是个使用它的教科书式的例子。
我会尽力回答你的所有问题:
值得尝试使用这些选择吗？ 我认为这是你需要问自己的问题 - 你想要实现什么？如果你想要让它更容易实现，纯代码或 ESB 都可能需要同样的时间，包括所有设置。如果你想把它作为学习练习，那么可能会值得尝试。
是否有一种简单的方法将它们集成到现有应用程序中而无需完全重构它？ 简短的回答是不行。你需要进行一些重新工程设计才能与大多数第三方库/框架集成。
是否有其他更轻量级的选项？ Mule 确实非常简单。你可以尝试使用 MQ 来处理 HTTP、SMS 和 IM。可能是 ActiveMQ 或 RabbitMQ。
是否有一些方面需要考虑，使它们的使用值得？ 是的，ESB 设计用于企业，新服务经常添加，配置可能会改变。将所有内容都放在 XML 中使得这种改变更加容易。因此，如果你只是构建一次性的软件，那么它可能不是正确的选择。但是，如果你将来会添加更多内容并不断连接不同的服务，那么这可能是最佳方法。
您可能还想看看 Apache Camel 框架，它对于您所提到的所有集成需求都非常强大，而且没有完整的 ESB 带来的一些缺陷。
Mule 项目的创始人 Ross Mason 在这个主题上写了一篇非常好的文章， To ESB or Not to ESB。我建议您去看看。此外，如果您正在构建 Web 应用程序并且只想进行一些轻量级集成而不感兴趣进行调解，则可以查看 Mule iBeans，它提供了一个更简单的模型。
另一个建议使用ESB或至少消息总线的情况是，你期望或需要其中一个或多个应用程序独立于其他应用程序进行演进。例如，一个正在积极开发中，而其他应用程序则没有。ESB可以将稳定系统与积极开发系统的更改隔离开来，消除了始终需要更新所有内容的需要。
ESB的真正力量在于，应用程序可以将如何通信和与谁通信的所有决策委托给ESB，并让该组件对这些方面负全部责任。所有其他组件都相互隔离，无需过多担心彼此，从而大大减少了依赖组合问题。
就学习曲线而言，我发现Mule ESB相当简单易懂，肯定比尝试学习连接到多个服务所需的所有必需APIs的学习曲线要低得多。
