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



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

1.14. Проверка состояния заказа. Продолжение.

Итак, новый вариант интеграционного проекта предусматривает размещение сообщений в хранилище сообщений, а также использование последнего при обработке сообщений. Информация, содержащаяся в хранилище сообщений, позволяет определить следующий этап обработки сообщения, устраняя тем самым необходимость соединения компонентов интеграционного решения с помощью фиксированных каналов сообщений. К примеру, если в базе данных содержится положительный ответ на сообщение о проверке кредитной репутации клиента, а также положительный ответ на сообщение о проверке наличия товара на складе, это означает, что заказ может быть выполнен и его можно передать для дальнейшей обработки системе доставки товара и биллинговой системе. Ранее для принятия подобного решения использовался агрегатор, однако сейчас логику принятия решений можно реализовать непосредственно в хранилище сообщений. Фактически тем самым мы превращаем хранилище сообщений в диспетчер процессов (Process Manager, с. 325).
Диспетчер процессов - это центральный компонент, управляющий потоками сообщений в системе (рис. 1.21). Диспетчер процессов обеспечивает две основные функции:
• хранение данных сообщений (внутри ''экземпляра процесса'');
• определение следующего этапа обработки сообщения (посредством использования ''эталона процесса'').
Проверка состояния заказа
 Новая архитектура превращает системы интеграционного решения (например, систему управления складскими запасами) в общие бизнес-функции, доступные оставшимся компонентам в виде служб. Это упрощает поддержку решения и повышает возможность повторного использования его элементов. Объединяющим фактором для отдельных служб может стать как поток сообщений (например, проверка наличия отдельных элементов заказа с помощью обработчика составного сообщения (Composed Message Processor, с. 307)), так и диспетчер процессов. Тем не менее диспетчер процессов позволяет вносить изменения в поток сообщений гораздо проще, чем это можно было бы сделать с помощью предложенного ранее подхода.
В соответствии с новой архитектурой все службы соединены с общей шиной служб, позволяющей вызывать службу любому компоненту интеграционного решения. IT-инфраструктуру ПРУСТ можно привести в соответствие с SOA-архитектурой, добавив функцию поиска службы в централизованном списке (каталоге) служб. Кроме того, все службы обязаны предоставить контракт интерфейса, описывающий функциональность службы, а каждая служба типа ''запрос-ответ'' должна поддерживать концепцию обратного адреса (Return Address, с. 182). Обратный адрес позволяет вызывающему компоненту (потребителю службы) указать канал, по которому следует передавать сообщение с ответом. Это делает возможным использование одной и той же службы в нескольких различных контекстах, каждому из которых может соответствовать собственный канал для передачи ответных сообщений.
Для хранения данных, относящихся к каждому экземпляру процесса, диспетчер процессов использует постоянное хранилище, такое как файл или реляционная база данных. Чтобы проверить состояние заказа с помощью Web-интерфейса, следует отправить сообщение диспетчеру процессов или выполнить запрос к базе данных заказов. Однако проверка состояния заказа является синхронным процессом, т.е. клиент ожидает получить ответ немедленно. Поскольку Web-интерфейс представляет собой приложение, которое разрабатывалось на заказ, мы приняли решение обратиться к базе данных напрямую. Общая база данных (Shared Database, с. 83) - наиболее простой и эффективный подход, позволяющий узнать состояние заказа за максимально короткое время. Единственный его недостаток заключается в сильном связывании Web-интерфейса и базы данных. Впрочем, в этой ситуации подобный компромисс выглядит вполне допустимым.
Большинство унаследованных систем разрабатывалось без встроенной поддержки таких концепций SOA-архитектуры, как обратный адрес. Чтобы представить эти системы в виде служб, следует воспользоваться интеллектуальным заместителем (Smart Proxy, с. 567). Интеллектуальный заместитель расширяет функциональность системы, перехватывая сообщения с запросом и сообщения с ответом, как показано на рис. 1.22.
Интеллектуальный заместитель сохраняет информацию из сообщения с запросом (например, обратный адрес, указанный запрашивающей стороной), а затем применяет ее для обработки сообщения с ответом (например, помещает сообщение в нужный канал). Интеллектуальный заместитель также удобно использовать для отслеживания качества обслуживания (например, времени отклика) внешней службы.
Проверка состояния заказа


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

<< Предыдущая статьяСледующая статья >>
1.13. Проверка состояния заказа 1.15. Изменение адреса клиента





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