Служить посредником в SOA

Question

Я знаю, что такое «обычный» шаблон проектирования посредника (некоторое описание есть в википедии: http://en.wikipedia.org/wiki/Mediator_pattern). В моем SOA у меня есть служба уведомлений: он должен передавать сообщения от одного сервиса всем другим, которые подписаны на этот конкретный сервис. Фактически, любой сервис может быть источником такого обмена сообщениями.

Мое видение такой реализации службы вызывает круговую зависимость между службами. Здесь ( Круговая зависимость в SOA ) Я спросил, как решить эту проблему, и получил совет использовать для этой цели шаблон «Посредник».

Если я правильно понимаю, у моей службы уведомлений должен быть контракт:

interface IMediator
{
    void PublishMessage(IMessage message);
}

Служба должна реализовывать (размещать) этот интерфейс и предоставлять его как службу извне.

Любой подписчик должен:

1. Реализация (хост) того же интерфейса на собственной стороне;
2. Зарегистрируйтесь на стороне службы уведомлений.

На самом деле подписчики могут использовать интерфейс с другим значением, например:

interface IReceiver
{
    void ProcessMessage(IMessage message);
}

В этом случае я вижу следующий поток сообщений:

1. Любая служба будет вызывать IMediator.PublishMessage (сообщение) службы уведомлений;
2. Служба уведомлений просканирует список подписчиков и вызовет IReceiver.ProcessMessage (message) для каждого подписчика.

Вопрос 1: все ли в порядке с таким дизайном?

Вопрос 2: Каким должен быть тип сообщения?

Сейчас мне нужно передать простую строку, поэтому одна из возможных реализаций может быть следующей:

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

Но здесь я вижу 2 проблемы:

1. Я не думаю, что передача MessageType в виде строки - это хорошая идея;
2. Мне не нравится кодировать сообщения любого типа в строку ....

Пожалуйста, сообщите. Любые мысли приветствуются!

P.S. Я планирую использовать сервис WCF в качестве базового движка для сервисов.

Отредактировано: после некоторых размышлений я вижу, что:

1. для каждого типа сообщения требуется отдельный метод в IMediator;
2. Для каждого типа сообщения требуется отдельный интерфейс Receiver.

С одной стороны - кажется разумным, с другой - большие накладные расходы ...

Answer 1

Возвращаясь к тому, что вы только что упомянули, центральная идея шаблона посредника состоит в том, чтобы удалить связь между объектами.Одна из причин этого заключается в том, чтобы заключать в себе сложность взаимодействия с объектом, ограничивая его классом, а не распространяя его по всей программе.ИМХО, этот класс предназначен для делегирования.

Проблема публикации-подписки, о которой вы здесь говорите, больше относится к области шаблона Observer - http://en.wikipedia.org/wiki/Observer_pattern

Это хорошо описано здесь:*http://en.wikipedia.org/wiki/Event-driven_SOA В этой статье также рассматриваются вопросы структуры данных для сообщения.