Service as Mediator in SOA

Question

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.

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.

Any subscriber should:

1. Implement (host) the same interface on own side;
2. Be registered on the Notification Service side.

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:

1. Any service will call IMediator.PublishMessage(message) of the Notification service;
2. Notification Service will go through the list of subscribers and will call IReceiver.ProcessMessage(message) for each subscriber.

Question 1: is everything fine with such design?

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:

1. I don't think that passing MessageType as a string is a good idea;
2. I don't like to encode any type of messages into string....

Please advise. Any thoughts are welcome!

P.S. I plan to use WCF service as a base engine for services.

EDITED: after some thinking I see that:

1. a separate method in IMediator is required per each message type;
2. a separate Receiver interface is required for each message type.

From one side - seems reasonable, from another - big overhead...

?

Answer 1

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.

The publish-subscribe problem that you talk about here is more the realm of the Observer pattern - http://en.wikipedia.org/wiki/Observer_pattern

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.