作为SOA中的中介服务

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

我对这种服务实现的看法导致了服务之间的循环依赖。这里（Circular dependency in SOA）我已经问过如何解决这个问题，并收到了为此使用'Mediator'模式的建议。

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

interface IMediator 
{ 
    void PublishMessage(IMessage message); 
}

服务应该实现（主机），该接口与外界公开为服务。

的任何订户应：

实现（主机）上自己的侧相同的接口;
在通知服务方注册。

其实用户可以使用接口与另外的含义，例如：

interface IReceiver 
{ 
    void ProcessMessage(IMessage message); 
}

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

任何服务将调用IMediator.PublishMessage（消息）的通知服务;
通知服务将通过订户列表并将为每个订户调用IReceiver.ProcessMessage（消息）。

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

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

现在我需要通过简单的字符串，所以可能实现的一个可能是以下几点：

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

但在这里我看到2个担忧：

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

请指教。任何想法都欢迎！

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

EDITED：后一些思考我看到：

每每个消息类型是必需的在IMediator一个单独的方法;
每种消息类型都需要单独的Receiver接口。

从一个侧面 - 似乎是合理的，从另一个 - 大开销......

？

来源

2011-01-25 Budda

重申上面刚刚提到的，中介模式的核心思想是消除对象之间的耦合。其中一个原因是通过将与对象交互的复杂性限制为一个类而不是将其分散到整个程序中来封装它。恕我直言，这个班级是为了代表团。

，你说说这里的发布 - 订阅的问题更多的是观察者模式的境界 - 这很好这里描述http://en.wikipedia.org/wiki/Observer_pattern

：http://en.wikipedia.org/wiki/Event-driven_SOA 本文还解决了该消息的数据结构的问题。

来源

2011-01-26 11:48:26

谢谢你，会阅读它们。 – Budda 2011-01-26 14:57:02

作为SOA中的中介服务

回答

相关问题