SOAのメディエータとしてのサービス

Question

「通常の」メディエータの設計パターン（いくつかの説明はwikipediaにあります：http://en.wikipedia.org/wiki/Mediator_pattern）を知っています。私のSOAでは、私はNotification Serviceを持っています。あるサービスからこの特定のサービスに加入している他のすべてのサービスにメッセージをブロードキャストする必要があります。実際には、どのようなサービスもそのようなメッセージングのソースになる可能性があります。

このようなサービス実装の私のビジョンは、サービス間の循環依存を引き起こします。ここで（Circular dependency in SOA） 私はそれを解決する方法を尋ね、この目的のために 'Mediator'パターンを使用するためのアドバイスを受けました。

私が正しく理解していれば、私の通知サービスが契約を持っている必要がありますが：

interface IMediator 
{ 
    void PublishMessage(IMessage message); 
} 

サービスは、このインタフェース（ホスト）を実装し、外部サービスとして公開する必要があります。

任意加入者べき：

1. （ホスト）は、自側の同じインタフェースを実装。
2. 通知サービス側に登録してください。

実際の加入者は、例えば、別の意味でのインターフェイスを使用することができます。この場合

interface IReceiver 
{ 
    void ProcessMessage(IMessage message); 
} 

を、私は、次の通信フローを参照してください。

1. どれサービスをメッセージ（IMediator.PublishMessageを呼び出します）に通知する。
2. 通知サービスはサブスクライバのリストを通過し、サブスクライバごとにIReceiver.ProcessMessage（メッセージ）を呼び出します。

質問1：は、このようなデザインと上質すべてですか？

質問2： IMessageの種類は何ですか？私はないと思う

1. ：私は2つの懸念を参照してください

   interface IMessage 
   { 
       string MessageType{get;} 
       string MessageContent{get;} 
   } 
   

   しかし、ここでは：今の私にはとても可能な実装の一つは、以下の可能性があり、単純な文字列を渡すために

   が必要MessageTypeを文字列として渡すことは良い考えです。私は、文字列へのメッセージのいずれかのタイプをエンコードするために好きではない

2. ....

お知らせください。どんな考えも歓迎です！

P.S. WCFサービスは、サービスのベースエンジンとして使用する予定です。

EDITED：いくつかの思考の後に私がいることを参照してください。

1. IMediatorで別の方法は、各メッセージタイプごとに必要です。
2. メッセージタイプごとに別々のReceiverインターフェイスが必要です。片側から

は - ...

大きなオーバーヘッド - 別から、合理的なようですか？

Answer 1

上記のことを述べると、メディエーターパターンの中心的なアイデアは、オブジェクト間の結合を削除することです。 これは、プログラム全体に拡散するのではなく、クラスに限定することで、オブジェクトとのやり取りの複雑さをカプセル化する理由の1つです。 IMHOこのクラスは委任の対象です。 http://en.wikipedia.org/wiki/Event-driven_SOAは、この記事では、メッセージのためのデータ構造の問題に対処 ：http://en.wikipedia.org/wiki/Observer_pattern

これは、ここにも記述されている - あなたがここでの話を

パブリッシュ・サブスクライブの問題は、より多くのは、Observerパターンの領域です。