Моделирование. Архитектура системы

5.6 Шаг 4. Применение связей с продуктами

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

5.6.1 Имеющиеся вложения в системы и продукты

На рис. 2.12 показана вся существующая ИТ-инфраструктура и инструменты, использованные для создания имеющейся системы обработки претензий. Существенными являются следующие аспекты:

• объединенный поток претензий обрабатывается на WebSphere MQ Workflow, а компания DirectCar имеет систему работы с процессами WebSphere Application Server Enterprise;
• ESB функционирует на WebSphere MQSeries и WebSphere Business Integration Message Broker, где два существующих соединения Web-служб с внешними поставщиками поддерживаются при помощи Web Services Gateway;
• клиентская Web-часть и некоторые имеющиеся приложения для работы с претензиями функционируют как EJB на WebSphere Application Server.

5.6.2 Имеющиеся клиентские навыки и навыки разработки

В компании LGI имеются довольно хорошие навыки работы с WebSphere MQSeries и WebSphere Application Server. Специалисты компании создавали приложения-Web-службы типа "точка-точка" и EJB-приложения. Они также создавали бизнес-процессы, используя WebSphere Business Integration Modeler 4.3.4 (продукт Holosofx, приобретенный IBM), и выполняли процесс на WebSphere MQ Workflow.

5.6.3 Выбор, сделанный заказчиком

Компания LGI желает разрабатывать больше приложений на основе открытых стандартов, таких, как Java 2 Enterprise Edition (J2EE), Web-службы и BPEL. В частности, специалисты компании хотят использовать данный проект для оценки инструментов и системы для разработки, управляемой моделями с применением UML и BPEL. См. раздел 1.3, "Цели и ограничения, связанные с ИТ".

Выбранная платформа должна подходить к среде заказчика и обеспечивать качество обслуживания, в частности масштабируемость и надежность, чтобы решение могло расти вместе с бизнесом:

• от приложения для обработки претензий не требуется такая высокая производительность, как от приложения для работы с полисами, которое отвечает за завоевание новых ниш бизнеса. Бизнес-аналитик выполнил несколько эмуляций, которые после оценки параметров производительности можно использовать для определения размеров системы и необходимого количества серверов.
• Компания LGI создала надежный каркас обмена сообщениями для своей ESB и желает применять его для асинхронных потоков для повышения надежности. Компания хочет использовать асинхронные взаимодействия там, где ответы являются отсроченными и где соединения производятся за пределами ИТ-инфраструктуры компании, что позволяет повысить готовность системы и уменьшить зависимость процессов LGI от доступности приложений поставщиков.

5.6.4 Связи с продуктами

На рис. 5.23 дается общий обзор связей с выбранными продуктами.

увеличить изображение
Рис. 5.23. External Claim Assessor::Product Mapping

Assessor Systems (Системы работы с оценщиками)

Мы реализуем одну систему работы с оценщиками как EJB-компонент, работающий на WebSphere Application Server. К области ответственности оценщиков относится:

• ответ на запрос о доступности;
• ответ на запрос о выполнении оценки претензии;
• отправка готового отчета об оценке.

Business Rules Engine (Система бизнес-правил)

Система бизнес-правил представляет собой EJB-компонент, работающий на WebSphere Application Server и отвечающий за следующее:

• за предоставление данных о времени обязательного ответа на претензию;
• выбор оценщика для обработки претензии из списка доступных оценщиков.

Assessor Management (Система управления оценщиками)

Создание списка оценщиков, потенциально способных выполнить оценку, на основе типа автомобиля и местоположения

Claim System (Система обработки претензий)

Система управления оценщиками представляет собой EJB-компонент, работающий на WebSphere Application Server и отвечающий за хранение отчета об оценке.

Assessor Automation (Автоматизация работы с оценщиками)

Система автоматизации работы с оценщиками представляет собой BPEL-систему, работающую на WebSphere Business Integration Server Foundation. Она отвечает:

• за получение запроса на оценку претензии от системы управления потоком претензий
• управление процессом создания отчета;
• возврат отчета в систему управления потоком претензий.

Claims Workflow (Система управления потоком претензий)

Система управления потоком претензий представляет собой FDL-систему, работающую на WebSphere MQ Workflow. Она отвечает:

• предоставление специалисту по обработке претензий:
  • списка претензий для изучения;
  • списка претензий, прошедших к данному моменту оценку;
• отправку претензии в процесс Assessor Automation и ожидает окончания оценки.

ESB (Корпоративная сервисная шина)

ESB – это сервисная шина, поддерживающая MQ, SOAP/JMS и SOAP/Http:. Она отвечает за отделение запросов к службам от транспортного протокола и физических адресов конечных точек.

ESB Gateway (Шлюз ESB)

Шлюз ESB – это службы, используемые сервисной шиной. Он отвечает:

• за реализацию соответствующего стиля взаимодействия с каждым из оценщиков (SOAP/http, Web-службы, EDI, браузер и т. д.);
• распределение запросов среди множества оценщиков;
• сбор ответов от нескольких брокеров;
• задание времени ожидания ответов;
• обработку ответов, пришедших с опозданием.

Web services Gateway (Шлюз Web-служб)

Шлюз Web-служб представляет собой демилитаризованную зону (DMZ). Он отвечает:

• за реализацию функции прокси для адресов Web-служб между Интернетом и интранетом;
• за ответы на автоматические запросы по предоставлению WSDL-интерфейсов клиентам Web-служб;
• за обеспечение безопасности связи через Интернет.

5.7 Базовая архитектура

На рис. 5.24 показана базовая физическая архитектура, которую мы будем использовать в данном сценарии. Размещение моделируется в Rational Software Architect с использованием уже созданной компонентной модели.

увеличить изображение
Рис. 5.24. Схема размещения Claim Investigation

1. В Model Explorer выберите пункт ITSO Architecture Claim Investigation, щелкните правой кнопкой мыши и выберите пункт меню Add Diagram (Добавить схему) New Deployment Diagram (Новая схема размещения).
2. Перетащите компоненты на схему (для краткости опустим оценщиков и шлюз Web-служб), выделите их все и нажмите пункт Name Compartment Style (Стиль с отображением имени), чтобы отображались только имена компонентов, но не их атрибуты. ( рис. 5.24).
3. Добавьте следующие артефакты ( Artefacts ): хранилище архивов брокера (Broker Archive Repository, BAR), хранилище корпоративных архивов (Enterprise Archive Repository, EAR) и поток FDL (FDL flow), которые будут размещены в системе. Мы также добавим артефакт Supportpac W0AD, который будет использоваться для соединения WebSphere MQ Workflow и WebSphere Business Integration Server Foundation.
4. Добавьте устройства ( Devices ) или среды выполнения ( Execution Environments ), представляющие собой серверы промежуточного программного обеспечения, на которых будут размещаться эти артефакты.

5.7.1 Чего нет в базовой архитектуре

Есть вещи, которые мы не стали моделировать на этой стадии. Мы не вдавались в детали размещения, например в сведения о физических машинах и сетевых адресах, не моделировали транспортный уровень и не указывали инструменты, используемые для создания артефактов. Все это вполне можно добавлять на данном этапе. Но делать это или не делать, зависит от того, как вы собираетесь использовать модель и есть ли еще архитектурные вопросы, по которым нужно принять решение. Например, мы решили не моделировать надежный транспортный уровень передачи сообщений или решили моделировать уровень SOAP/Http:. Такие части системы вполне стандартны, и мы не планируем строить точную модель размещения, чтобы она определяла конфигурацию артефактов размещения. В других ситуациях это может быть важной частью моделируемого решения.

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

5.8 Заключение

В этой лекции рассматривались три этапа создания архитектуры системы:

• Сведение воедино требований, предъявляемых к ИТ-архитектуре в Rational Software Architect. Эти требования поступают из модели процесса, созданной бизнес-аналитиком, из исходных бизнес-целей и ИТ-целей, а также создаются на семинаре по созданию модели бизнес-процесса.
• Анализ требований для построения базовой архитектуры с помощью подхода Patterns for e-business Integration Design Approach.
• Возврат в Rational Software Architect для фиксации базовой архитектуры в форме схемы размещения.

Следующий этап – это изучение деталей процесса и создание архитектуры решения на основе базовой архитектуры, взаимодействий и интерфейсов компонентов.