design - Service as Mediator in SOA -

i know "usual" mediator design pattern (some description in wikipedia: http://en.wikipedia.org/wiki/mediator_pattern). in soa have notification service: should broadcast messages 1 service other subscribed particular service. actually, service can source of such messaging.

my vision of such service implementation causes circular dependency between services. here (circular dependency in soa) i've asked how resolve , received advice use 'mediator' pattern purpose.

if correctly understand, notification service should have contract:

interface imediator {     void publishmessage(imessage message); } 

service should implement (host) interface , expose service outside.

any subscriber should:

1. implement (host) same interface on own side;
2. be registered on notification service side.

actually subscribers can use interface meaning, example:

interface ireceiver {     void processmessage(imessage message); } 

in case see following communications flow:

1. any service call imediator.publishmessage(message) of notification service;
2. notification service go through list of subscribers , call ireceiver.processmessage(message) each subscriber.

question 1: fine such design?

question 2: should type of imessage?

for need pass simple string, 1 of possible implementation following:

interface imessage {     string messagetype{get;}     string messagecontent{get;} } 

but here see 2 concerns:

1. i don't think passing messagetype string idea;
2. i don't encode type of messages string....

please advise. thoughts welcome!

p.s. plan use wcf service base engine services.

edited: after thinking see that:

1. a separate method in imediator required per each message type;
2. a separate receiver interface required each message type.

from 1 side - seems reasonable, - big overhead...

?

restating mentioned above, central idea of mediator pattern remove coupling between objects. 1 of reasons encapsulate complexity of interacting object limiting class instead of spreading around entire program. imho class meant delegation.

the publish-subscribe problem talk here more realm of observer pattern - http://en.wikipedia.org/wiki/observer_pattern

this described here : http://en.wikipedia.org/wiki/event-driven_soa article addresses issues of data structure message.