SOA 中的中介服务

Question

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

我对这种服务实现的看法会导致服务之间的循环依赖。在这里 (Circular dependency in SOA) 我询问了如何解决它并收到了为此目的使用“中介”模式的建议。

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

interface IMediator
{
    void PublishMessage(IMessage message);
}

服务应该实现（宿主）这个接口并将它作为服务暴露在外面。

任何订阅者都应该：

1. 在自己端实现（宿主）相同的接口；
2. 在通知服务端注册。

其实订阅者可以使用另外一个含义的接口，例如：

interface IReceiver
{
    void ProcessMessage(IMessage message);
}

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

1. 任何服务都会调用 Notification 服务的 IMediator.PublishMessage(message)；
2. 通知服务将遍历订阅者列表，并为每个订阅者调用 IReceiver.ProcessMessage(message)。

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

问题 2：什么是 IMessage 类型？

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

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

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

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

请指教。欢迎任何想法！

附：我计划使用 WCF 服务作为服务的基础引擎。

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

1. 每种消息类型都需要 IMediator 中的单独方法；
2. 每种消息类型都需要一个单独的接收器接口。

一方面 - 似乎合理，另一方面 - 开销很大......

?

Answer 1

重申您刚才提到的内容，中介者模式的中心思想是消除对象之间的耦合。 造成这种情况的原因之一是通过将对象限制在一个类而不是将其分散到整个程序中来封装与对象交互的复杂性。 恕我直言，该课程用于委派。

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

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