Интеграция с динамическими клиентами

Question

У меня есть вопрос архитектурного дизайна. Наша компания недавно представила COTS (продукт на основе.NET) для управления делами. Этот продукт имеет сложный модуль интеграции, который выкладывает полную информацию по делу в MQ при каждом действии пользователя. Каждый элемент XML имеет флаги Add, Edit & Delete, чтобы знать, какой элемент был изменен.

Мы должны написать приложение, которое обрабатывает эти события последовательно по мере их поступления и отправляет нескольким внешним партнерам с условием того, что изменилось. Интерфейс с каждым внешним партнером отличается с точки зрения того, какие данные ему нужны, представления (XML, String, JSON и т. Д.) И протоколов (SOAP, REST, MQ, DB-вызов и т. Д.).

Любые предложения о том, как кто-то может разработать такую ​​систему и какие технологии можно использовать? (К вашему сведению, наш существующий стек технологий Java / JEE, Weblogic).

PS. Основная проблема, с которой я столкнулся, заключается в том, что если один из партнеров не работает, мы не должны сдерживать других партнеров. В то же время ни один партнер не должен терять ни одного уведомления.

Спасибо.

Answer 1

Возможный подход:

• COTS помещает сообщения о событиях приложения в очередь сообщений.
• Компонент генератора сообщений прослушивает очередь сообщений и запрашивает базу данных партнеров о известных на данный момент партнерах. Для каждого сообщения COTS будет генерироваться сообщение о событии для каждого партнера, информирующее о том, что произошло. Событие также будет иметь флаг "доставлено". Таким образом, в основном вы преобразуете очередь сообщений, заполненную COTS, в N очередей сообщений, по одной для каждого партнера. Ваши события должны быть неизменяемыми объектами, вы можете хранить их в реляционной БД или БД NoSQL ("БД сообщений" на рисунке).
• На вашем сервере приложений работает N или меньше компонентов конечных точек. Когда они приходят с запросом, они запрашивают у общего компонента ("Общие проблемы с извлечением данных" на рисунке) новые сообщения. Общий компонент запрашивает базу данных сообщений, передает сообщения в виде списка объектов Java, а компонент конечной точки заботится о сериализации. Общий компонент также может заботиться об авторизации, используя информацию из БД партнера.

Внимание: общий компонент должен помечать сообщения как опубликованные, только если они были успешно доставлены. Возможно, вы захотите дождаться подтверждения от компонента партнера. Поскольку вы не можете гарантировать транзакционную атомизацию во время этого процесса, ваши партнеры-клиенты должны быть устойчивы к дубликатам. Программное обеспечение вашего сервера, а также каждый клиент должны управлять идентификатором сообщения (UUID) для каждого события:

• Ваша задача - заботиться о создании уникального идентификатора для каждого сообщения о событии

• Работа ваших партнеров - ведение справочной таблицы, чтобы проверить, обрабатывали ли они уже вечер с определенным идентификатором.