我正在考虑将 ESB 集成到现有的基于 Web 的 Java/Maven 产品中。具体来说，我正在研究 ServiceMix 和 Mule。该产品将连接到多种不同的服务，包括电子邮件、Quartz、基于 HTTP、SMS 和 IM 的 RESTful 网络服务。我只是快速浏览了文档，这两个选项似乎相当重量级且相当复杂。这似乎是何时使用 ESB 的教科书示例，但我不想花费大量时间来学习一个或另一个系统。
就像我说的，我已经有一个由 Maven 构建的 Web 应用程序，并且希望集成其中一个系统会相当简单，即使只是像发送电子邮件这样简单的事情，但看起来添加任何一个都会吸引一半的世界罐子的条款，很难嵌入到现有的产品中。
是否值得尝试使用这些选项之一？有没有一种简单的方法可以将它们集成到现有的应用程序中而无需完全重构它？还有其他更轻的选择吗？是否有一些我应该考虑的方面会使它们值得使用？
Mule 在将服务与 XML 一起插入方面非常易于使用，并且它们有大量的视频示例，我发现这些示例非常有用。
ESB 应该是未来的，正如你所说 - 你的似乎是一个教科书的例子，说明在哪里使用它。
我会尽力回答你所有的问题：
是否值得尝试使用这些选项之一？ 我认为这是您需要问自己的一个问题-您要实现什么目标？如果您试图使其更容易实现，那么通过纯代码或 ESB 可能需要相同的时间，包括所有设置。如果您正在考虑将其作为一种学习练习，那么它可能是值得的。
有没有一种简单的方法可以将它们集成到现有的应用程序中而无需完全重构它？ 简短的回答没有。您将需要进行一些重新设计以与大多数第三方库/框架集成。
还有其他更轻的选择吗？ 骡子真的很简单。您也许可以使用 MQ 来执行 HTTP、SMS 和 IM。可能是 ActiveMQ 或 RabbitMQ。
是否有一些我应该考虑的方面会使它们值得使用？ 是的，ESB 是为经常添加新服务并且配置可能会更改的企业而设计的。将这一切都放在 XML 中会使这种更改更容易一些。因此，如果您只是构建一个一次性的软件，它可能不是正确的方法。但是，如果您以后要添加更多内容并不断连接不同的服务，那可能是最好的途径。
您可能还想看看 Apache Camel 框架，它非常强大，可以满足您提到的所有集成需求，而不会受到完全成熟的 ESB 的影响。
Mule 项目的创始人 Ross Mason 就这个主题写了一篇非常好的文章，To ESB or Not to ESB。我建议看一看。此外，如果您将其构建为 Web 应用程序并且只想进行一些轻量级集成并且对中介不感兴趣，您可能想查看Mule iBeans ，它提供了一个更简单的模型。
我建议不要在 MULE 上浪费您的宝贵时间。到目前为止，我的经验并不好。我不会将它用于任何关键系统。离成熟的产品还很远。除此之外，RESTful 服务肯定会承诺很多简单性并具有真实的用例。
我会说，如果您有两个以上的应用程序或数据库需要相互通信，并且它们使用的通信协议不止一种，那么投资是值得的。或者，如果您预计这种情况在未来会发生。听起来你的要求肯定符合这个。
另一种建议使用 ESB 或至少使用消息总线的情况是您期望或需要一个或多个应用程序独立于其他应用程序发展的地方。例如，一个正在积极开发中，而另一个则没有。ESB 可以将稳定系统与积极开发的系统中的更改隔离开来，从而无需始终更新所有内容。
ESB 的真正强大之处在于，应用程序可以将有关如何通信以及与谁通信的所有决策委托给 ESB，并让该组件对这些方面承担全部责任。所有其他组件相互隔离，无需相互担心，大大减少了依赖组合的问题。
就学习曲线而言，我发现 Mule ESB 非常容易上手，并且肯定会是一个更低的学习曲线，它试图学习所有必需的 API 来处理您尝试连接的多个服务。