integration - 点对点与 Web 服务集成

Question

有时，组织使用点对点方法来集成应用程序，中间件工具通过允许应用程序专注于其核心区域而不是每个应用程序编写集成逻辑来帮助避免这种情况。

现在应用程序说他们正在使用 Web 服务进行集成，而不需要真正的中间件。我如何让应用程序相信中间件在这种情况下仍然可以提供帮助？在我看来，网络服务只是一种先进的点对点解决方案。SOA 治理是这里唯一的卖点吗？

Answer 1

是的，如果您正在做点对点的网络服务，您将无法控制消息流量。

借助中间件 ESB，ESB 提供了对消息进行排队和控制消息使用速率的工具。

此外，ESB（和消息代理）为您的消息提供有保证的传递。所以，如果你的消费者失败了，你就不会丢失消息。

使用点对点 Web 服务，您必须在每个 Web 服务中实现排队机制和保证交付机制。那时，您只是在重新发明轮子。

此外，您将更多的责任交给 Web 服务使用者或 Web 服务提供者来实现路由/编排逻辑。如果端点不属于您，而是您需要为更改付费的第三方，这可能会变得非常昂贵。

然后，如果您的公司进行收购，而另一家公司使用的软件基于不支持 Web 服务且无法直接与 .NET 或 Java Web 通信的旧技术，您会怎么做？服务。为了使事情尽可能轻松且影响最小，ESB 承担所有路由/编排逻辑，并通过其适配器插入其他系统以检索/创建/更新/删除数据。

使 ESB 丰富的是它的适配器库。他们已经存在了足够长的时间来拥有适用于几乎所有新旧技术的适配器。

学习 ESB 技术时要做的最重要的事情之一是确保您现在和可预见的未来所需的适配器可用

Answer 2

在我的组织中看到它后，我对此有所了解。让我们以我的组织中发生的情况为例，我们之前有一个通用的中间件，但后来的应用程序就像上述案例一样告诉他们不需要中间件，而是可以做自己的集成逻辑。比如Oracle说他们可以用OSB来写他们的逻辑等等。然后是我们有很多 ESB 的时候——OSB、Axis、Message Broker 等等。随着联合 ESB（或编写集成逻辑的应用程序）的出现出现了它们自己的问题：

1.没有单一的服务注册表。

2.服务设计无法标准化。例如，不同团队编写和维护的服务合同各不相同

3.服务重用性完全丧失。

4.如果以后不支持 OSB 版本，技术债务 - 我们必须为单独的 ESB 保留单独的迁移计划

最终，我们不得不只使用一个 ESB 来避免这种混乱和技术债务。

此外，对于您的应用程序编写自己的集成逻辑并且它们不是标准 ESB 的情况，我预见到另一个问题。集成设计模式的实现和标准化问题例如发布者订阅者。希望这可以帮助 。

Answer 3

在物联网时代，在业务领域的能力互联网中，中间件被归入 ESB。大多数内部业务交互都需要实时点对点。以 ReST Web 服务为例。如果我查询一个我不希望它排队的资源，我想要一个响应。再加上服务版本控制（即 uri 上的版本控制）的出现，消费者在很长一段时间内都无法应对变化。您应该调整或缓冲请求吗？那要看！您的消费者应用程序是否介意在不确定的时间内等待响应。所涉及的观点是真正的即时集成与实时集成。在实时集成场景中，如果我下订单，我现在需要一个订单号，而不是以后。这是点对点。在这种情况下，服务总线没有位置。所以这取决于你的方法。但是随着 ReST 的出现，esBus 的车轮已经倒下。最后一个想法：拥有我们可以使用的所有网络功能，lpars，VM，路由；我们是否应该根据系统不可用性来规划集成？我不这么认为。