Service as an intermediary in SOA

Question

I know what a “regular” mediator design pattern is (some description is on Wikipedia: http://en.wikipedia.org/wiki/Mediator_pattern ). In my SOA, I have a notification service: it must send messages from one service to all the others that are subscribed to this particular service. In fact, any service can be the source of such messages.

My vision of such a service implementation causes a cyclical dependency between services. Here ( Circular Dependency in SOA ) I asked how to resolve it and got advice on using the Mediator template for this purpose.

If I understand correctly, my notification service should have a contract:

interface IMediator { void PublishMessage(IMessage message); } 

The service must implement (host) this interface and expose it as a service outside.

Any subscriber must:

• Implement (host) the same interface on its side;
• Register with the Notification Service.

In fact, subscribers can use an interface with a different value, for example:

 interface IReceiver { void ProcessMessage(IMessage message); } 

In this case, I see the following message flow:

• Any service will call the IMediator.PublishMessage (message) notification service;
• The notification service will go through the list of subscribers and will call IReceiver.ProcessMessage (message) for each subscriber.

Question 1: is everything ok with this design?

Question 2: What should be the type of message?

Now I need to pass a simple string, so one of the possible implementations could be the following:

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

But here I see 2 problems:

• I do not think that passing MessageType as a string is a good idea;
• I do not like to encode any type of message into a string ....

Please inform. Any thoughts are welcome!

PS I plan to use the WCF service as a base engine for services.

EDITED: after some thought, I see that:

• each type of message requires a separate method in IMediator;
• Each message type requires a separate receiver interface.

On the one hand, it seems reasonable, on the other hand, it is a big overhead ...

?

Answer 1

Repeating the above, the central idea of ​​the mediator template is to remove the connection between objects. One reason for this is to encapsulate the complexity of interacting with an object by restricting it to a class, rather than distributing it throughout the program. IMHO a class is intended for delegation.

The issue of the publishing-subscription you are talking about is more likely the scope of the Observer template - http://en.wikipedia.org/wiki/Observer_pattern

This is described here: http://en.wikipedia.org/wiki/Event-driven_SOA This article also discusses data structure problems for a message.