Циркулярная зависимость в SOA

Question

Полагаю, это общий вопрос, но я постараюсь описать мою текущую проблему.

У меня есть базовый сервис, назовем его «CoreService», который обеспечивает, я бы сказал, «основную» функциональность: обрабатывать данные в БД (у нас есть централизованная БД в наших приложениях). Существует ряд других приложений, некоторые из которых имеют свои собственные БД для локальных целей. И есть один простой «Сервис уведомлений». Его целью является трансляция сообщений разным подписчикам.

Обычно этот NotificationService вызывается из «ExternalWorld» и отправляет уведомления различным службам (среди них «CoreService»).

Сегодня я увидел необходимость вызвать NotificationService из CoreService.

Меня беспокоит то, что я ввожу циклическую зависимость: NotificationService необходимо знать, как отправлять сообщения каждому сервису (включая «CoreService», поэтому ему нужно знать об интерфейсе «CoreService» и, следовательно, ссылаться «CoreService») и «CoreService» должны отправлять сообщения в «NotificationService» (поэтому он также должен ссылаться на него) ... Круговая зависимость ...

Вопрос: Как нам построить нашу архитектуру для решения такой проблемы?

Большое спасибо!

Answer 1

Вы должны перейти от точки к точке к медиатору.Посредник теперь возьмет на себя ответственность за привязку источника к адресатам и правильную маршрутизацию / публикацию сообщений (в моей голове звучит ESB).

Объяснение

Вы не делаетепрямая ссылка CoreService из NotificationService или наоборот.Оба будут подписываться на тему их интересов.Например, CoreService публикует события для темы, на которую NotificationService будет подписываться (и CoreService также будет подписываться на тему, NotificationService публикует события в).Тогда обработчик темы (система обмена сообщениями или ESB и т. Д.) Несет ответственность за пересылку событий всем подписчикам данной темы.Таким образом, сервисы слабо связаны друг с другом и даже не нуждаются в информации о своем существовании.

В настоящее время вы используете NotificationService в качестве посредника / ESB, что делает его, если хотите, сервисом инфраструктуры и, следовательно,такие проблемы, как циклические зависимости и т. д. Это больше не бизнес-сервис.

Answer 2

Когда я закончил писать вопрос, я нашел какую-то идею:

Внутри 'NotificationService' мне нужно определить 2 интерфейса: IMessagesSender и IMessagesReceiver.

1. Каждый подписчик долженреализовать IMessagesReceiver, и его адрес должен быть записан в файл конфигурации NotificationService;
2. Каждый отправитель сообщения должен использовать файл wsdl, который описывает интерфейс IMessageSender и должен иметь запись в своем файле конфигурации с адресомNotificationService.

В этом случае мы не будем удалять циклическую зависимость, но это похоже на решение ...

Сейчас мне трудно сказатьКаков наилучший способ и каковы плюсы и минусы этого решения, поэтому, пожалуйста, прокомментируйте его (и / или предложите лучший вариант).

Большое спасибо!