SOAの循環依存性

Question

私は推測していることはよくある質問ですが、私は現在の問題点を説明しようとします。

私は "CoreService"という名前のベースサービスを持っています。私は "main"という機能を提供しています：DB内のデータを扱います（私たちのアプリケーションには集中DBがあります）。他の多くのアプリケーションがありますが、その中にはローカルの目的で独自のDBを持っているものもあります。また、単純な「NotificationService」が1つあります。その目的は、異なる加入者にメッセージをブロードキャストすることです。

通常、このNotificationServiceは 'ExternalWorld'から呼び出され、異なるサービス（「CoreService」）に通知を送信します。

今日、「CoreService」から「NotificationService」を呼び出す必要がありました。

ここで私は循環依存を導入しています：NotificationServiceは、（CoreServiceを含む）各サービスにメッセージを送信する方法を知る必要があるため、 'CoreService'インターフェイスについて知る必要があります。 'CoreService'）と 'CoreService'は 'NotificationService'にメッセージを送信する必要があります（参照する必要もあります）。循環依存...

質問：このような問題を処理するためにアーキテクチャをどのように構築する必要がありますか？

ありがとうございます！私は2つのインターフェイス「IMessagesSender」と「IMessagesReceiver」を定義する必要があります「NotificationService」の内部

：私は質問を書いて完了すると

Answer 1

は、私はいくつかのアイデアを見つけました。

1. すべてのサブスクライバは 'IMessagesReceiver'を実装し、そのアドレスは 'NotificationService'の設定ファイルに書き込む必要があります。
2. すべてのメッセージ送信者は、 'IMessageSender'インタフェースを記述する 'wsdl'ファイルを使用し、独自の構成ファイルにNotificationServiceの 'address'を記録する必要があります。この場合

我々は循環依存関係を削除しないであろうが、それは解決策のように思えるが...

今

、私が最善の方法は、プロがあり、何ANS何で言うのは難しいですこのソリューションの欠点は、コメントしてください（および/またはより良いものを提案する）。

ありがとうございます！

Answer 2

ポイントツーポイントからメディエータに切り替える必要があります。メディエータは送信元を送信先にバインドし、メッセージを適切にルーティング/公開する責任を負います（私の頭の中のESBリング）。あなたが直接NotificationServiceまたはその逆からCoreServiceを参照していない

説明

。両方ともからトピックを購読します。 e。グラムCoreServiceはNotificationServiceは（もNotificationServiceがイベントへを公開することを話題に加入し、CoreService）にsubsribeすることを話題にイベントを発行しています。特定のトピックのすべての加入者にイベントを転送するのは、トピック・ハンドラ（メッセージング・システムまたはESBなど）の責任です。このように、サービスは互いに疎結合しており、その存在を知る必要はありません。

現在、メディエータ/ ESBとしてNotificationServiceを使用しているため、インフラストラクチャサービスとなり、したがって循環依存性などの問題はビジネスサービスではなくなります。