SOA中的循环依赖

时间:2011-01-24 22:22:12

标签: architecture service soa

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

我有一个基本服务,让它命名为'CoreService',它提供我会说“主要”功能:处理数据库中的数据(我们的应用程序中有一个集中的数据库)。还有许多其他应用程序,其中一些应用程序有自己的DB用于本地目的。还有一个简单的'NotificationService'。其目的是向不同的订户广播消息。

通常,此NotificationService从“ExternalWorld”调用,并将通知发送到不同的服务(其中包括'CoreService')。

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

我担心的是我引入了循环依赖:NotificationService需要知道如何向每个服务发送消息(包括'CoreService',因此它需要了解'CoreService'接口,因此需要引用'CoreService')和'CoreService'需要向'NotificationService发送消息(所以它也需要引用它)......循环依赖...

问题:我们应该如何构建我们的架构来处理这样的问题?

非常感谢!

2 个答案:

答案 0 :(得分:4)

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

<强>解释

您不直接从 NotificationService 引用 CoreService ,反之亦然。两者都订阅到他们感兴趣的主题。例如, CoreService 将事件发布到 NotificationService 将要包含的主题(并且 CoreService 也将订阅 NotificationService 的主题em> 发布事件。然后,主题处理程序(消息传递系统或ESB等)负责将事件转发给给定主题的所有订阅者。通过这种方式,服务彼此松散耦合,甚至不需要知道它们的存在。

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

答案 1 :(得分:0)

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

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

  1. 每个订阅者都应该实现'IMessagesReceiver'并且它的地址应该写入'NotificationService'的配置文件中;
  2. 每个邮件发件人都应该使用描述“IMessageSender”界面的“wsdl”文件,并且应该在自己的配置文件中记录NotificationService的“地址”。
  3. 在这种情况下,我们不会删除循环依赖,但它似乎是一个解决方案......

    目前,我很难说这个解决方案的优缺点是什么,所以请评论(和/或建议更好的解决方案)。

    非常感谢!