在 SOA 中作为中介的服务 [英] Service as Mediator in SOA
问题描述
我知道什么是通常的"中介设计模式(维基百科中有一些描述:http://en.wikipedia.org/wiki/Mediator_pattern).在我的 SOA 中，我有通知服务:他应该将消息从一项服务广播到订阅此特定服务的所有其他服务.实际上，任何服务都可以成为此类消息的来源.
I know what is "usual" mediator design pattern (some description is in wikipedia: http://en.wikipedia.org/wiki/Mediator_pattern). In my SOA I have Notification Service: he should broadcast messages from one service to all other that are subscribed for this particular service. Actually, any service can be a source of such messaging.
我对这种服务实现的看法导致服务之间的循环依赖.此处(SOA 中的循环依赖)我已经询问了如何解决它，并收到了为此目的使用中介"模式的建议.
My vision of such service implementation causes circular dependency between services. Here (Circular dependency in SOA) I've asked how to resolve it and received advice to use 'Mediator' pattern for this purpose.
如果我理解正确，我的通知服务应该有一个合同:
If I correctly understand, my Notification Service should have a contract:
interface IMediator
{
void PublishMessage(IMessage message);
}
服务应该实现(托管)这个接口并将其作为服务对外公开.
Service should implement (host) this interface and expose it as service outside.
任何订阅者都应该:
- 在自己端实现(托管)相同的接口；
- 在通知服务端注册.
实际上订阅者可以使用具有另一种含义的界面，例如:
Actually subscribers can use interface with another meaning, for example:
interface IReceiver
{
void ProcessMessage(IMessage message);
}
在这种情况下，我看到以下通信流程:
In this case I see the following communications flow:
- 任何服务都会调用通知服务的 IMediator.PublishMessage(message)；
- 通知服务将检查订阅者列表，并为每个订阅者调用 IReceiver.ProcessMessage(message).
问题 1:这样的设计一切都好吗?
Question 1: is everything fine with such design?
问题 2: IMessage 的类型应该是什么?
Question 2: what should be a type of IMessage?
现在我需要传递简单的字符串，因此可能的实现之一如下:
For now I need to pass simple string, so one of the possible implementation could be the following:
interface IMessage
{
string MessageType{get;}
string MessageContent{get;}
}
但在这里我看到了两个问题:
But here I see 2 concerns:
- 我认为将 MessageType 作为字符串传递不是一个好主意；
- 我不喜欢将任何类型的消息编码为字符串......
请指教.欢迎提出任何想法！
Please advise. Any thoughts are welcome!
附言我计划使用 WCF 服务作为服务的基础引擎.
P.S. I plan to use WCF service as a base engine for services.
经过一些思考，我看到了:
EDITED: after some thinking I see that:
- 每种消息类型都需要 IMediator 中的单独方法；
- 每种消息类型都需要一个单独的 Receiver 接口.
一方面 - 似乎合理，另一方面 - 开销很大...
From one side - seems reasonable, from another - big overhead...
?
推荐答案
重申上面刚刚提到的内容，中介者模式的中心思想是消除对象之间的耦合.这样做的原因之一是将与对象交互的复杂性封装在一个类中，而不是将其分散到整个程序中.恕我直言，这门课是为了委派.
Restating what you just mentioned above, the central idea of the mediator pattern is to remove the coupling between objects. One of the reasons for this is to encapsulate the complexity of interacting with an object by limiting it to a class instead of spreading it around the entire program. IMHO the class is meant for delegation.
你在这里谈论的发布-订阅问题更像是观察者模式的领域 - http://en.wikipedia.org/wiki/Observer_pattern
The publish-subscribe problem that you talk about here is more the realm of the Observer pattern - http://en.wikipedia.org/wiki/Observer_pattern
这里描述得很好:http://en.wikipedia.org/wiki/Event-驱动_SOA本文还解决了消息的数据结构问题.
This is described well here : http://en.wikipedia.org/wiki/Event-driven_SOA This article also addresses the issues of the data structure for the message.
这篇关于在 SOA 中作为中介的服务的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
