我们目前正在考虑用可能的ESB或类似工具替换我们的应用程序之一，并且正在寻找有关如何最好地解决此问题的一些见解。
我们目前有一个独立的服务，它使用不同的外部服务和数据源进行消费/交互，一些通过SOAP Web服务提供，另一些我们只使用数据库连接。这项服务是通过SOAP公开的，我们有其他应用程序使用这项服务，但与它紧密耦合，现在我们还有其他应用程序需要使用一些外部服务，并希望将这一切全部替换为ESB或某种SOA平台。
取代这个＆＃39;外部＆＃39;的最佳方式是什么？服务集成层与ESB？我们正在考虑拥有一个全球性的＆＃39;合同/ API，我们使用的所有服务都作为一个单一的合同公开，我们使用的所有可能的操作和数据结构都暴露在一个命名空间下，这是接近这个的最佳方式吗？如果是这样，有什么工具可以帮助我们自动化这个过程，还是我们基本上必须手工制作这个合同/ API？这也意味着对于底层服务/ API的任何更改，我们也必须更新此新API。
如果没有，那么我看到的另一个选择是基本上使用＆＃39; ESB＆＃39;作为“代理人”＃39;我们所有来源都按原样曝光的一层，所以我们最终会得到几个不同的合同＆＃39; / API端点，但我真的没有看到它的价值。
还给出了上述什么是最好的工具？是一个完整的ESB是一个过度杀手还是我们更好地使用像Apache Camel或Spring Integration这样的东西？
更多细节：
我们目前正在整合5种不同的外部服务，未来会有更多。
目前只有几个应用程序正在使用我们当前的应用程序，但未来的其他几个应用程序/系统将需要使用其中一些外部服务。
我们目前在这些服务之间使用单一通信方法（SOAP），但某些应用程序将来可能会使用发布/订阅消息，尽管SOAP仍然是使用的主要协议。
我是ESB集成的新手，所以如果我误解了很多这些技术以及它们要解决的问题，我会提前道歉。
非常感谢任何帮助/提示/指示。
感谢。
答案 0 :(得分：5)
你需要对你想要实现的目标进行一些设计思考。
ESB引入有许多好处和潜在的缺陷。
以下是一些典型的好处/用例
当您的应用程序难以更改或具有非常不同的发布周期时 - 那么convenient中间有一个可以快速采用更改的ESB。当您的组织购买大量COTS产品和云服务时，情况就是如此，这些产品和云服务可能会在第二天发布更新，从而破坏当前的API。
当您需要将数据从一个主数据系统调整到其他几个系统并且它们可能不支持相同的接口时，即CRM系统可能希望一旦可用就通过Web服务导入数据，ERP希望数据通过db / staging表和生产系统每个周末都需要通过FTP传送的平面文件中的数据。为了保持主数据系统的清洁和易维护，只需在主数据系统中实现一个单一的集成服务，并将该接口改为ESB平台内的各种其他应用程序。
从各种来源聚合或拆分数据以保护您的敏感系统可能是一个用例。假设您有一个旧系统，一次可以进行少量信息更新，而且不值得升级此系统 - 那么可以执行aggreggation或splitting或限制的集成解决方案可以是好的解决方案。
其他好处和用例包括跟踪和wire tap系统之间传递的每条消息的能力 - 甚至可以与商业智能工具一起使用来收集KPI：s。
概念ESB还可以引入canonical message格式，用于需要通信的所有服务。如果许多应用程序与其他几个应用程序（不仅是点对点）共享相同的数据 - 那么规范消息格式的好处可能会超过成本（这可能会很高）。 ESB服务器可能是useful来处理规范数据，因为它通常非常擅长从一种格式映射到另一种格式。
然而，在没有计划的情况下引入ESB你想要实现的好处并不是一件好事，因为它引入了开销 - 你需要另一台服务器才能保持活力，你需要另一个团队来理解所有数据流。您需要具备集成产品的特定知识。最后，您需要能够对其进行一些治理，以便您的ESB计划不会偏离您预见的目标/利益。
您应该选择一些您熟悉的技术 - 或者认为您可以放心使用。 Apache Camel确实非常强大，是我最喜欢的集成引擎 - but it's not an ESB，因为它没有运行时可用于部署/管理/监控集成服务。您可以将它与大多数Java EE应用程序服务器一起使用，甚至更好 - Apache ServiceMix（= Karaf + Camel + ActiveMQ + CXF）这个任务。
弹簧集成也是如此 - 你需要在某个地方运行它，app服务器或者不需要。
有大量不同的产品，包括开源和商业用途。