作爲SOA中的中介服務

Question

我知道什麼是「通常」中介設計模式（某些說明在維基百科中：http://en.wikipedia.org/wiki/Mediator_pattern）。在我的SOA中，我有通知服務：他應該將消息從一個服務廣播到所有其他訂閱此特定服務的消息。實際上，任何服務都可以成爲這種信息的來源。

我對這種服務實現的看法導致了服務之間的循環依賴。這裏（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？

現在我需要通過簡單的字符串，所以可能實現的一個可能是以下幾點：

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

但在這裏我看到2個擔憂：

1. 我不認爲做將MessageType作爲字符串傳遞是一個好主意;
2. 我不喜歡任何類型的信息編碼成字符串....

請指教。任何想法都歡迎！

P.S.我打算使用WCF服務作爲服務的基礎引擎。

EDITED：後一些思考我看到：

1. 每每個消息類型是必需的在IMediator一個單獨的方法;
2. 每種消息類型都需要單獨的Receiver接口。

從一個側面 - 似乎是合理的，從另一個 - 大開銷......

？

Answer 1

重申上面剛剛提到的，中介模式的核心思想是消除對象之間的耦合。 其中一個原因是通過將與對象交互的複雜性限制爲一個類而不是將其分散到整個程序中來封裝它。 恕我直言，這個班級是爲了代表團。

，你說說這裏的發佈 - 訂閱的問題更多的是觀察者模式的境界 - 這很好這裏描述http://en.wikipedia.org/wiki/Observer_pattern

：http://en.wikipedia.org/wiki/Event-driven_SOA 本文還解決了該消息的數據結構的問題。