作为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. 任何服务都会调用Notification服务的IMediator.PublishMessage（消息）;
2. 通知服务将浏览订阅者列表，并为每个订阅者调用IReceiver.ProcessMessage（消息）。

问题1：这样设计的一切都很好吗？

问题2：应该是什么类型的IMessage？

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

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

但在这里我看到了两个问题：

1. 我不认为将MessageType作为字符串传递是一个好主意;
2. 我不喜欢将任何类型的消息编码成字符串....

请指教。欢迎任何想法！

P.S。我计划使用WCF服务作为服务的基础引擎。

编辑：经过一番思考后，我看到了：

1. 每种消息类型都需要IMediator中的单独方法;
2. 每种消息类型都需要单独的Receiver接口。

从一方面看 - 从另一方面来看似乎是合理的 - 大开头......

Answer 1

重申上面提到的内容，中介模式的核心思想是去除对象之间的耦合。 其中一个原因是通过将对象限制为类而不是将其扩展到整个程序来封装与对象交互的复杂性。 恕我直言，该课程是为了授权。

您在此处讨论的发布 - 订阅问题更多是观察者模式的领域 - http://en.wikipedia.org/wiki/Observer_pattern

这里有很好的描述：http://en.wikipedia.org/wiki/Event-driven_SOA 本文还解决了消息的数据结构问题。