Design patterns SOA中的中介服务

我知道什么是“通常的”中介设计模式（维基百科中有一些描述：）。在我的SOA中，我有一个通知服务：他应该将消息从一个服务广播到订阅此特定服务的所有其他服务。实际上，任何服务都可以成为此类消息传递的来源

我对这种服务实现的设想导致了服务之间的循环依赖。这里（） 我已经询问了如何解决这个问题，并收到了使用“Mediator”模式的建议

如果我理解正确，我的通知服务应该有一个合同：

interface IMediator
{
    void PublishMessage(IMessage message);
}

服务应该实现（托管）这个接口，并将它作为服务公开在外部

任何认购人应：

在本方实现（主机）同一接口

必须在通知服务端注册

实际上，订阅者可以使用另一种含义的界面，例如：

interface IReceiver
{
    void ProcessMessage(IMessage message);
}

在这种情况下，我看到以下通信流：

任何服务都将调用通知服务的IMediator.PublishMessage（message）

通知服务将遍历订阅服务器列表，并为每个订阅服务器调用IReceiver.ProcessMessage（message）

问题1:这样的设计一切都好吗

问题2:什么是IMessage类型

现在，我需要传递简单字符串，因此可能的实现之一是：

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

但在这里，我看到了两个担忧：

我不认为将MessageType作为字符串传递是个好主意

我不喜欢将任何类型的消息编码为字符串

请告知。欢迎有任何想法

我计划使用WCF服务作为服务的基本引擎

编辑：经过思考，我发现：

每个消息类型都需要IMediator中的单独方法

每种消息类型都需要单独的接收器接口

从一个方面看——似乎合理，从另一个方面看——巨大的开销

---

？

重申您刚才提到的内容，中介模式的中心思想是消除对象之间的耦合。 这样做的原因之一是通过将对象限制在一个类中，而不是将其分散到整个程序中，来封装与对象交互的复杂性。 我知道这门课是用来授权的

您在这里讨论的发布-订阅问题更多的是观察者模式的领域-

这在这里有很好的描述：

---

这篇文章还讨论了消息的数据结构问题。

是的，经过一些思考后，我将使用SOA的“观察者”模式“适应”。