Служба в качестве посредника в SOA

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

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

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

interface IMediator
{
    void PublishMessage(IMessage message);
}

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

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

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

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

interface IReceiver
{
    void ProcessMessage(IMessage message);
}

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

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

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

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

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

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

Но здесь я вижу 2 опасения:

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

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

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

EDITED: после некоторого размышления я вижу, что:

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

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

?


person Budda    schedule 25.01.2011    source источник


Ответы (1)


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

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

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

person J K    schedule 26.01.2011
comment
Да, после некоторого размышления я выберу «адаптацию» шаблона «Observer» для SOA. - person Budda; 31.01.2011