SOA 中的循环依赖答案

【问题标题】：Circular dependency in SOASOA 中的循环依赖
【发布时间】：2011-06-14 20:18:03
【问题描述】：

我猜，这是一个常见问题，但我会尝试描述我当前的问题。

我有一个基础服务，我们将其命名为“CoreService”，它提供我会说的“主要”功能：在 DB 中处理数据（我们的应用程序中有一个集中式 DB）。还有许多其他应用程序，其中一些具有用于本地目的的自己的数据库。还有一个简单的“NotificationService”。它的目的是向不同的订阅者广播消息。

通常，此 NotificationService 从“ExternalWorld”调用，并将通知发送到不同的服务（其中包括“CoreService”）。

今天我看到有必要从“CoreService”调用“NotificationService”。

我在这里担心的是我引入了循环依赖：NotificationService 需要知道如何向每个服务发送消息（包括“CoreService”，因此它需要了解“CoreService”接口，因此它需要引用'CoreService'）和'CoreService'需要向'NotificationService发送消息（所以它也需要引用它）......循环依赖......

问题：我们应该如何构建我们的架构来处理此类问题？

非常感谢！

【问题讨论】：

NotificationService 是这里的中介，不是吗？

标签： architecture service soa

【解决方案1】：

您必须从点对点切换到中介。 Mediator 现在将负责将源绑定到目标并适当地路由/发布消息（ESB 在我脑海中响起）。

说明

您不直接从 NotificationService 引用 CoreService，反之亦然。两者都会订阅他们感兴趣的主题。例如，CoreService 将事件发布到 NotificationService 将订阅的主题（并且 CoreService 还将订阅 NotificationService 的主题em> 发布事件）。然后，主题处理程序（消息系统或 ESB 等）负责将事件转发给给定主题的所有订阅者。这样，服务之间就松散耦合了，甚至不需要知道它们的存在。

目前，您正在使用 NotificationService 作为中介/ESB，因此如果您愿意，可以将其作为基础设施服务，因此会出现循环依赖等问题。它不再是业务服务。

【讨论】：

同意。我的“NotificationService”计划成为调解员不是很明显吗？可能我错过了什么？ 'NotificationService' 应该具有哪些特征作为中介？谢谢
我的意图是使用“NotificationService”作为“主题处理程序”。如果我正确理解了您的建议，请看这里 (stackoverflow.com/questions/4798319/service-as-mediator-in-soa) 吗？

【解决方案2】：

当我完成写作问题时，我发现了一些想法：

在“NotificationService”内部，我需要定义 2 个接口“IMessagesSender”和“IMessagesReceiver”。

每个订阅者都应该实现“IMessagesReceiver”，并将其地址写入“NotificationService”的配置文件中；
每个消息发送者都应该使用描述“IMessageSender”接口的“wsdl”文件，并且应该在自己的配置文件中记录通知服务的“地址”。

在这种情况下，我们不会删除循环依赖，但这似乎是一个解决方案......

现在，我很难说什么是最好的方法以及这个解决方案的优缺点，所以请评论它（和/或建议更好的方法）。

非常感谢！

【讨论】：