如何为不同的外部服务/应用程序设计/开发集成层或总线

Question

我们目前正在考虑用可能的ESB或类似工具替换我们的一个应用程序,并且正在寻找一些有关如何最好地解决这个问题的见解.

我们目前有一个独立的服务,它使用不同的外部服务和数据源进行消费/交互,一些通过SOAP Web服务提供,另一些我们只使用数据库连接.这项服务是通过SOAP公开的,我们有其他应用程序使用这项服务,但与它紧密耦合,现在我们还有其他应用程序需要使用一些外部服务,并希望将这一切全部替换为ESB或某种SOA平台.

用ESB替换这个"外部"服务集成层的最佳方法是什么？我们正在考虑拥有一个"全局"契约/ API,其中我们使用的所有服务都作为一个单一的契约公开,我们使用的所有可能的操作和数据结构都暴露在一个命名空间下,这是最好的方法接近这个？如果是这样,有什么工具可以帮助我们自动化这个过程,还是我们基本上必须手工制作这个合同/ API？这也意味着对于底层服务/ API的任何更改,我们也必须更新这个新API.

如果没有,那么我看到的另一个选择是基本上使用'ESB'作为'代理'层,其中所有源都是按原样公开的,所以我们最终会得到几个不同的'契约'/ API端点,但是我真的没有看到它的价值.

还给出了上述什么是最好的工具？是一个完整的ESB是一个过度杀手还是我们更好地使用像Apache Camel或Spring Integration这样的东西？

更多细节:

我们目前正在整合5种不同的外部服务,未来会有更多.

目前只有几个应用程序消耗我们当前的应用程序,但未来的其他几个应用程序/系统将需要使用这些外部服务.

我们目前在这些服务之间使用单一通信方法(SOAP),但是某些应用程序将来可能会使用发布/订阅消息,尽管SOAP仍然是使用的主要协议.

我是ESB集成的新手,所以如果我误解了很多这些技术以及它们要解决的问题,我会提前道歉.

任何帮助/提示/指示将不胜感激.

谢谢.

Answer 1

你需要对你想要实现的目标进行一些设计思考.

ESB简介有许多好处和潜在的缺陷.

以下是一些典型的好处/用例

• 当您的应用程序难以更改或具有非常不同的发布周期时 - 可以方便地在中间安装可快速采用更改的ESB.当您的组织购买大量COTS产品和云服务时可能会出现这种情况,这些产品和云服务可能会在第二天发布更新,从而破坏当前的API.

• 当您需要将数据从一个主数据系统调整到其他几个系统并且它们可能不支持相同的接口时,即CRM系统可能希望一旦可用就通过Web服务导入数据,ERP就需要数据通过db/staging表和生产系统每周末都希望通过FTP传送平面文件中的数据.为了使主数据系统保持清洁和易于维护,只需在主数据系统中实现单个集成服务,并将此接口改为ESB平台中的各种其他应用程序.

• 从各种来源聚合或拆分数据以保护敏感系统可能是一个用例.假设您有一个旧系统,一次可以进行少量信息更新,并且不值得升级该系统 - 那么可以进行聚合或拆分或限制的集成解决方案可能是一个很好的解决方案.

其他好处和用例包括跟踪和窃听系统之间传递的每条消息的能力- 甚至可以与商业智能工具一起使用来收集KPI:s.

概念性ESB还可以引入规范消息格式,该格式用于需要通信的所有服务.如果许多应用程序与其他几个应用程序(不仅是点对点)共享相同的数据 - 那么规范消息格式的好处可能会超过成本(这可能会很高).一个ESB服务器可能是有用的,因为它通常是在映射非常好,从一种格式转换为另一种处理标准数据.

但是,在没有计划的情况下引入ESB,您试图实现的好处并不是一件好事,因为它会引入开销 - 您需要另一台服务器才能保持活力,您可能需要另一个团队来理解所有数据流.您需要具备集成产品的特定知识.最后,您需要能够围绕它进行一些治理,以便您的ESB计划不会偏离您预见的目标/利益.

您应该选择一些您感觉舒适的技术 - 或者认为您可以放心使用.Apache Camel确实非常强大并且是我最喜欢的集成引擎 - 但它不是ESB,因为它没有运行时可用于部署/管理/监视集成服务.您可以将它与大多数Java EE应用程序服务器一起使用,甚至更好 - Apache ServiceMix(= Karaf + Camel + ActiveMQ + CXF),它是为此任务而构建的.

弹簧集成也是如此 - 你需要在某个地方运行它,app服务器或者不需要.

有大量不同的产品,包括开源和商业用途.