Я знаю, что такое «обычный» шаблон проектирования посредника (некоторое описание есть в википедии: http://en.wikipedia.org/wiki/Mediator_pattern). В моем SOA у меня есть Notification Service: он должен транслировать сообщения от одного сервиса ко всем другим, которые подписаны на этот конкретный сервис. Собственно, любой сервис может быть источником таких сообщений.
Мое видение такой реализации сервиса вызывает циклическую зависимость между сервисами. Здесь (Круговая зависимость в SOA) я спросил, как ее решить, и получил совет по использованию Шаблон «Посредник» для этой цели.
Если я правильно понимаю, моя служба уведомлений должна иметь контракт:
interface IMediator
{
void PublishMessage(IMessage message);
}
Служба должна реализовать (разместить) этот интерфейс и выставить его снаружи как службу.
Любой подписчик должен:
- Реализовать (разместить) такой же интерфейс на своей стороне;
- Зарегистрируйтесь на стороне службы уведомлений.
На самом деле подписчики могут использовать интерфейс с другим значением, например:
interface IReceiver
{
void ProcessMessage(IMessage message);
}
В этом случае я вижу следующий поток сообщений:
- Любая служба будет вызывать IMediator.PublishMessage(сообщение) службы уведомлений;
- Служба уведомлений просматривает список подписчиков и вызывает IReceiver.ProcessMessage(message) для каждого подписчика.
Вопрос 1: все ли в порядке с таким дизайном?
Вопрос 2: каким должен быть тип IMessage?
На данный момент мне нужно передать простую строку, поэтому одна из возможных реализаций может быть следующей:
interface IMessage
{
string MessageType{get;}
string MessageContent{get;}
}
Но здесь я вижу 2 опасения:
- Я не думаю, что передача MessageType в виде строки — хорошая идея;
- Мне не нравится кодировать сообщения любого типа в строку....
Пожалуйста, порекомендуйте. Любые мысли приветствуются!
P.S. Я планирую использовать службу WCF в качестве базового механизма для служб.
EDITED: после некоторого размышления я вижу, что:
- для каждого типа сообщения требуется отдельный метод в IMmediator;
- для каждого типа сообщения требуется отдельный интерфейс приемника.
С одной стороны - разумно, с другой - большие накладные расходы...
?