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中的循環依賴關係

回答

相關問題