Book.od.ua Книги для вашего бизнеса



Одесская библиотека бизнес литературы
полезные книги для бизнеса

1.10. Размещение заказов

Размещение заказов - это одна из основных функций создаваемого решения. Заказы приносят прибыль, однако в настоящий момент они обрабатываются вручную, что влечет за собой большие накладные расходы.
Клиент ПРУСТ может разместить заказ с помощью одного из трех каналов: Web-сайта, центра обработки звонков и факса. К сожалению, каждая система основана на применении различных технологий и форматов данных. Система обработки звонков представляет собой коммерческое приложение, Web-сайт - J2EE-приложение, созданное на заказ, а система обработки входящих факсов использует ручной ввод данных в приложение Microsoft Access. Очевидно, что способ обработки заказа не должен зависеть от способа его размещения. Например, заказав товар с помощью центра обработки звонков, клиент должен иметь возможность проверить состояние заказа с помощью Web-приложения.
Поскольку размещение заказа - это асинхронный процесс, охватывающий несколько различных систем, унифицируем его с помощью связующего ПО, ориентированного на обмен сообщениями. Приложение в центре обработки звонков не обладает средствами для интеграции и должно быть подключено к системе обмена сообщениями с помощью адаптера канала (Channel Adapter, с. 154). Адаптер канала - это компонент, который публикует сообщения в канале сообщений (Message Channel, с. 93) при возникновении события в приложении. В некоторых случаях приложение может и вовсе не знать о наличии подключенного к нему адаптера канала. Например, приложение, сохраняющее информацию в базе данных, можно подключить к системе обмена сообщениями с помощью триггеров, срабатывающих при добавлении новых строк в определенные таблицы базы данных и помещающих соответствующие сообщения в канал сообщений. Адаптер канала может выполнять и обратную функцию, извлекая сообщения из канала сообщений и инициируя определенные действия внутри приложения.
Для подключения к системе обмена сообщениями приложения, применяющегося для обработки входящих факсов, воспользуемся адаптером канала, соединенным с базой данных этого приложения. Поскольку Web-приложение разрабатывалось на заказ, создадим внутри него конечную точку сообщения (Message Endpoint, с. 124). Чтобы отделить код Web-приложения от кода конечной точки сообщения, применим шлюз обмена сообщениями (Messaging Gateway, с. 482).
Каждая система размещения заказов использует для их представления разные форматы данных. С целью приведения этих форматов к общему формату сообщения, соответствующего канонической модели данных (Canonical Data Model, с. 367), используются три транслятора сообщений (Message Translator, с. 115). Каноническая модель данных определяет формат сообщений, не зависящий от конкретного приложения. Таким образом, изменение внутреннего формата данных приложения затрагивает только транслятор сообщений, расположенный между этим приложением и общим каналом сообщений. Все оставшиеся приложения, а также соответствующие им трансляторы сообщений, не требуют внесения изменений. Использование канонической модели данных приводит к разделению всех сообщений на две категории: канонические сообщения (общие) и сообщения приложений (частные). Сообщение приложения должно обрабатываться только создавшим его приложением и соответствующим транслятором сообщений. Условимся использовать в именах каналов сообщений, по которым передаются сообщения приложений, соответствующий префикс, например WEB_NEW_ORDER. Имена каналов, по которым передаются канонические сообщения, будут лишены подобного префикса, например NEW_ORDER.
Так как сообщение о размещении нового заказа должен был принять единственный получатель, каждый адаптер канала подключается к транслятору сообщений с помощью канала "точка-точка" (Point-to-Point Channel, с. 131). Следует отметить, что мы могли бы обойтись без транслятора сообщений Web-приложения, запрограммировав логику преобразования в соответствующем шлюзе обмена сообщениями. Однако подобная реализация функций преобразования может привести к возникновению ошибок программирования, а также нарушить целостность предложенного ранее подхода к унификации формата сообщений. Все трансляторы сообщений размещают сообщения в канале "точка-точка" NEW_ORDER, что устраняет различие между заказами, поступившими из разных источников (рис. 1.12).
Канал сообщений NEW_ORDER является так называемым каналом типа данных (Datatype Channel, с. 139), поскольку по нему передаются сообщения одного и того же типа: сообщения о размещении нового заказа. Это облегчает задачу обработки сообщений, поступающих по каналу NEW_ORDER. Само же сообщение о размещении нового заказа представляет собой сообщение с данными документа (Document Message, с. 171), основное назначение которого состоит в передаче данных между приложениями.


Понравился материал? Поделитесь с друзьями!

<< Предыдущая статьяСледующая статья >>
1.9. Пример Приборы и устройства 1.11. Обработка заказов





Убедительная просьба при использовании любых материалов Одесской электронной бизнес-библиотеки ставить активную ссылку на наш сайт. По всем вопросам касательно сайта пожалуйста пишите на почту
      Карта сайта