【问题标题】:REST API Layer Orchestration using Spring Integration使用 Spring 集成的 REST API 层编排
【发布时间】:2015-12-02 09:53:19
【问题描述】:

我们有大约 6 个单独的 REST 服务,我们将在编排层中调用它们。例如“调用 service-1 来检查银行帐户是否属于某种类型,如果是,则调用 service-2,否则调用 service-3”。

Spring Integration 消息传递框架是编排对这些服务的调用的正确工具,还是矫枉过正?请提出是否有更好的方法来完成同样的事情。

【问题讨论】:

    标签: spring rest spring-integration


    【解决方案1】:

    我不能向您推荐更好的工具,因为 Spring Integration 在过去对我来说是最好的,现在它是我的全职工作。因此,请尝试在其他地方找到其他答案。

    现在关于 orchestration 与 Spring 集成的要点。老实说,它只是一个词,它试图描述一个应用程序根据某些条件调用其他外部应用程序时的业务逻辑。

    所以,从 Spring Integration 中的 HTTP 适配器、Transformers、Splitter、Router 和 Gateways 的高度来看,我们可以自信地说 Spring Integration 上的消息传递层符合您的要求,并且确实可以帮助您区分业务逻辑和编排逻辑。

    不知道还能说什么,但我可以推荐看看 Spring Integration Reference Manual 并注意 Routing SlipScatter-Gather 模式。

    【讨论】:

    • 从我的 Orchestration API 实际上我将只调用 3-4 个现有的 REST API(它们不作为 Spring Integration 端点公开)。我的用例也是非常简单的 if-else 条件。话虽如此,如果编排逻辑对业务逻辑的干扰太大,您认为我应该开始以 Spring 方式设计我的编排 API 并引入 Spring 集成(路由滑动、分散-聚集模式)吗?
    • 1.对于<int-http:outbound-gateway>,目标 REST API 是否基于 Spring Integration 构建并不重要。 2. 如果你对 Spring Integration 感觉不太好,就不要将它用于此类任务。 3. 没有理由花时间一头撞墙,如果你能用其他工具来达到目标​​。如果您不喜欢它,我不坚持使用 Spring Integration。这就是为什么您的问题已经有一段时间没有答案了:只是因为您要求提供一些意见,而不是工具的特定问题。
    • 感谢@Artem 的诚实意见,我只是确保不要用大锤杀死蚂蚁 :)
    猜你喜欢
    • 2018-06-22
    • 2016-06-09
    • 1970-01-01
    • 2015-01-25
    • 1970-01-01
    • 2020-10-24
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多