Пример создания интеграционного решения, основанного на обмене сообщениями | MetodPro.ru

Реклама на сайте

Пример создания интеграционного решения, основанного на обмене сообщениями


Рассмотрим пример создания интеграционного решения, основанного на обмене сообщениями. Предположим, что компания  закупает у производителей продукцию и реализует ее розничным потребителям. Данная система является достаточно большой. Для краткости мы рассмотрим отдельную ее часть – размещение заказов.

Клиент может разместить заказ с помощью одного из трех каналов: Web-сайта, центра обработки звонков и факса. Каждая система основана на применении различных технологий и форматов данных. Система обработки звонков представляет собой коммерческое приложение, Web-сайт— J2ЕЕ-приложение, а система обработки входящих факсов - ручной ввод данных в приложение MicrosoftAccess. Способ обработки заказа не должен зави­сеть от способа его размещения.

Поскольку размещение заказа – это асинхронный процесс, охватывающий несколь­ко различных систем, унифицируем его с помощью связующего ПО, ориентированного на обмен сообщениями. Приложение в центре обработки звонков не обладает средства­ми для интеграции и должно быть подключено к системе обмена сообщениями с помо­щью адаптера канала (ChannelAdapter). Адаптер канала— это компонент, кото­рый публикует сообщения в канале сообщений (MessageChannel) при возникновении события в приложении. Например, приложение, сохраняю­щее информацию в базе данных, можно подключить к системе обмена сообщениями с помощью триггеров, срабатывающих при добавлении новых строк в определенные таб­лицы базы данных и помещающих соответствующие сообщения в канал сообщений.

Адаптер канала может выполнять и обратную функцию, извлекая сообщения из канала сообщений и инициируя определенные действия внутри приложения.

Для подключения к системе обмена сообщениями приложения, применяющегося для обработки входяших факсов, воспользуемся адаптером канала, соединенным с базой данных этого приложения. Поскольку Web-приложение разрабатывалось на заказ, созда­дим внутри него конечную точку сообщения. Чтобы отделить код Web-приложения от кода конечной точки сообщения, применим шлюз обмена сообщениями.

Каждая система размещения заказов использует для их представления разные форма­ты данных. С целью приведения этих форматов к общему формату сообщения, соответ­ствующего канонической модели данных, используются три транслятора сообщений. Каноническая модель данных определя­ет формат сообщений, не зависящий от конкретного приложения. Сообщение приложения должно обрабатываться только создавшим его приложением и соответствующим транслятором сообщений. Условимся использовать в именах каналов сообщений, по которым передаются сообщения приложений, соответст­вующий префикс, напримерwebnew_order. Имена каналов, по которым передаются канонические сообщения, будут лишены подобного префикса, напримерnew_order.

Так как сообщение о размещении нового заказа должен был принять единственный по­лучатель, каждый адаптер канала подключается к транслятору сообщений с помощью кана­ла "точка-точка". Все трансляторы сообщений размещают сообщения в канале "точка-точка"new_order, что устраняет различие между заказами, поступившими из разных источников.

Канал сообщенийnew_order является так называемым каналом типа данных, поскольку по нему передаются сообщения одного и того же типа: сооб­щения о размещении нового заказа. Это облегчает задачу обработки сообщений, посту­пающих по каналуnew_order. Само же сообщение о размещении нового заказа пред­ставляет собой сообщение с данными документа, основное на­значение которого состоит в передаче данных между приложениями.



Методические пособия

  • Системы автоматизированного проектирования
  • Социология молодёжи
  • Общая социология
  • Криптография
  • Проектирование трансляторов
  • Компьютерная графика
  • Моделирование систем
  • Информационная безопасность
  • Теория вычислительных процессов
  • Логические основы искусственного интелекта
  • Проектирование распределённых информационных систем