SOA中的循环依赖关系

我猜测，这是一个常见问题，但我会尝试描述当前的问题。我有一个基本服务，让它命名为'CoreService'，它提供了我会说的“主要”功能：处理数据库中的数据（我们在应用程序中有一个集中的数据库）。还有许多其他应用程序，其中一些应用程序为了本地目的而拥有自己的数据库。还有一个简单的'NotificationService'。其目的是将消息广播给不同的用户。SOA中的循环依赖关系

通常，这个NotificationService是从'ExternalWorld'中调用的，并将通知发送到不同的服务（其中是'CoreService'）。

今天我看到有必要从'CoreService'中调用'NotificationService'。

我的问题在于我引入了一个循环依赖：NotificationService需要知道如何发送消息到每个服务（包括'CoreService'，因此它需要知道'CoreService'接口，因此它需要引用'CoreService'）和'CoreService'需要发送消息到'NotificationService（所以它也需要引用它）...循环依赖...

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

非常感谢！

来源

2011-01-24 Budda

委托给调解员。 – Griff 2011-01-24 22:26:44

NotificationService是这里的调解人，不是吗？ – Budda 2011-01-24 22:28:24

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

里面“NotificationService”我需要定义2个接口“IMessagesSender”和“IMessagesReceiver”的。

每个用户都应该实现'IMessagesReceiver'，它的地址应该写入'NotificationService'的配置文件中;
每个消息发送者都应该使用描述'IMessageSender'接口的'wsdl'文件，并且应该在自己的配置文件中记录NotificationService的'地址'。

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

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

非常感谢！

来源

2011-01-24 22:27:38 Budda

您必须从点对点切换到中介。调解员现在将负责将来源绑定到目的地，并适当地路由/发布消息（ESB环在我脑海中）。

说明

你不直接从NotificationService反之亦然参考CoreService。两者都将订阅到主题他们的兴趣。前面。摹CoreService发布活动，以一个主题，NotificationService将subsribe（和CoreService也将订阅一个主题，NotificationService发布事件）。然后，主题处理程序（消息传递系统或ESB等）负责将事件转发给给定主题的所有订阅者。这样的服务松散耦合，甚至不需要知道它们的存在。

目前，您正在使用NotificationService作为中介/ ESB，因此如果您愿意，可以将其作为基础结构服务，因此也可以处理诸如循环依赖等问题。它不再是业务服务。

来源

2011-01-24 22:28:24

SOA中的循环依赖关系

回答

相关问题