Компания IBM
Опубликован: 14.08.2008 | Доступ: свободный | Студентов: 1090 / 150 | Оценка: 4.75 / 3.75 | Длительность: 27:55:00
Лекция 6:

Моделирование. Архитектура решения

< Лекция 5 || Лекция 6: 123456 || Лекция 7 >
Аннотация: В этой лекции анализируется функционирование процесса для создания архитектуры решения

Комбинация базовой архитектуры и архитектуры решения необходима для того, чтобы ИТ-специалисты могли приступить к реализации решения.

Из базовой архитектуры мы знаем:

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

Архитектура решения будет определять:

  • интерфейсы, которые нужно реализовать;
  • взаимодействия и технологии их реализации;
  • качество обслуживания, необходимое для компонентов и взаимодействий.

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

6.1 Модель взаимодействий

Основа модели взаимодействий имеет два аспекта:

  • шаблон коопераций, который мы выбрали в базовой архитектуре;
  • бизнес-процесс.

На основе этих аспектов мы можем изобразить приблизительный поток для решения ( рис. 6.1). Показаны взаимодействия, происходящие из бизнес-процессов Claims Investigation, в сочетании с шаблоном кооперации, показанным на рис. 5.22. Шаблоны коопераций были упрощены и изображены так, чтобы их можно было читать слева направо. Рисунок начинает напоминать UML-схему последовательностей.

Поток в решении

увеличить изображение
Рис. 6.1. Поток в решении

6.1.1 Описание взаимодействий

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

Таблица 6.1. Описание взаимодействий
Поток Описание
1 Новый процесс запускается из существующего процесса Claim Workflow (Управление потоком претензий) путем отправки запроса на получение отчета внешнего оценщика. Интерфейсом этого запроса является requestAssessor – XML-документ, выпускаемый очередью WebSphere MQ. Это синхронный запрос типа вызов/ответ (см. поток 1а), и для него планируется время ответа 2 дня. Используемые системы параллельной обработки могут эффективно и надежно реализовывать такие длительные синхронные запросы. Процесс автоматизации работы с внешними оценщиками (Assessor Automation), который реализуется через оркестровку бизнес-процессов (Business Process Choreography) получает это сообщение и запускает новый экземпляр процесса
2 Первая задача процесса автоматизации работы с оценщиками (Assessor Automation) - это вызов системы управления оценщиками (Assessor Management) для получения списка доступных оценщиков. Интерфейс называется assessorManagment. Это синхронный вызов типа вызов/ответ, и для него ожидается ответ в пределах секунды
Вторая задача – это получение времени ответа на основе установленного с клиентом соглашения об уровне обслуживания, которое обрабатывается системой Assessor Management параллельно. Интерфейс называется requestResponseTimePT
3 Имея указанную выше информацию, процесс автоматизации работы с оценщиками вызывает на этапе 3 прокси-систему оценщиков. Интерфейс называется assessorAvailability. Процесс ожидает ответ от AssessorProxySystem, подтверждающий, что эта система получила запрос
4 Прокси-система AssessorProxySystem принимает от потока 3 список оценщиков, и служба распределения создает сообщения-запросы, приведенные в формат, необходимый для каждого оценщика. Запросы маршрутизируются через шлюз как односторонние потоки
4a Прокси-система AssessorProxySystem ожидает ответ в течение срока, полученного от RequestResponseTimePT из потока 2a, а затем, по истечении времени ожидания, объединяет ответы, полученные в потоках 4a
3a Процесс автоматизации работы с оценщиками (Assessor Automation) ждет, пока система AssessorProxySystem возвратит список доступных оценщиков в шаге 3a. Планируется, что 3a будет иметь место через несколько часов после 3
5 Процесс Assessor Automation передает список доступных оценщиков в систему бизнес-правил (Business Rules Engine), которая выбирает для выполнения оценки одного оценщика. Процесс использует интерфейс preferredAssessor системы бизнес-правил. Это синхронный вызов типа вызов/ответ, и для него ожидается ответ в пределах секунды
6 Затем процесс запрашивает отчет об оценке, вызывая прокси-систему при помощи интерфейса allocateAssessmentRequest. Это асинхронный вызов, получение ответа на который может занимать несколько часов. Как синхронный вызов/ответ его можно создать только в том случае, если его можно реализовать эффективно и надежно с помощью длительно работающего бизнес-процесса и корпоративной сервисной шины. В версии 5 платформы WebSphere это сделать сложно, поэтому мы реализовали это взаимодействие как односторонние запросы, инициируемые с каждой стороны при помощи SOAP/http
7 Прокси-система AssessorProxySystem передает запрос allocateAssessmentReport выбранному оценщику и ожидает подтверждения
7a Прокси-система AssessorProxySystem доставляет ответ оценщика (положительный или отрицательный) через интерфейс deliverAssessmentReponse
6a Прокси-система AssessorProxySystem доставляет ответ оценщика (положительный или отрицательный) в процесс автоматизации работы с оценщиками (Assessor Automation)
8 Оценщик посылает односторонний поток прокси-системе AssessorProxySystem через интерфейс deliverAssessment
9 Прокси-система AssessorProxySystem передает отчет обратно в процесс Assessor Automation в одностороннем потоке через интерфейс assessorReport
10 Процесс Assessor Automation вызывает обработчик документов (Document Handler) процесса Claim System с помощью интерфейса storeAssessorReport. Это синхронный вызов типа вызов/ответ, и для него ожидается ответ в пределах секунды
Система автоматизации работы с оценщиками возвращает управление в Claims Workflow, используя интерфейс requestAssessorResponse

Имея эту информацию, мы можем начинать создавать последовательность в Rational Software Architect.

6.1.2 Схема последовательностей

На схеме последовательностей отображается функционирование кооперации. Мы уделяем основное внимание двум моментам: подробному описанию функционирования кооперации RequestExternalReports и интерфейсу, через который она взаимодействует с кооперацией ClaimInvestigation_TOBE.

Архитектору решения нужно создать новую кооперацию для данных функций по ряду причин:

  1. Архитектор добавил в кооперацию новый компонент (proxyAssessorSystem).
  2. Кооперацию, созданную в WebSphere Business Integration Modeler, нельзя изменить в Rational Software Architect.
  3. Мы не собираемся изменять описание бизнес-процесса, согласованного между бизнес-аналитиком и архитектором решения, и включать в него изменения, которые затрагивают только техническую сторону. Если функционирование бизнес-процесса остается тем же, архитектору решения не нужно заново согласовывать контракт с бизнес-аналитиком. Когда архитектор закончит модель PIM, аналитик и архитектор изучат ее и удостоверятся в том, что изменения и расширения, внесенные архитектором, не повлияли на работу модели бизнес-процесса.

Создайте новую кооперацию и перетащите интерфейсы на схему взаимодействий.

  1. В Model Explorer выберите пункт ITSO Architect \to Claim Investigation, щелкните правой кнопкой мыши и выберите пункт меню Add UML (Добавить UML) \to Collaboration (Кооперация) и назовите ее External Claim Assessor.
  2. Щелкните правой кнопкой мыши по кооперации External Claim Assessor и выберите пункт меню Add Diagram (Добавить схему) \to Sequence Diagram (Схема последовательностей) и назовите схему Sequence Diagram. Измените имя взаимо- действия с Interaction1 на что-нибудь более понятное, например на Assessor Automation Interactions.
  3. Заполните схему последовательностей линиями жизни следующих объектов:
    • кооперация ClaimsInvestigation_TOBE из модели WebSphere Business Integration Modeler
    • интерфейсы AssessorAutomation и proxyAssessorSystem, определенные в составе компонентной модели на рис. 5.8.
  4. Перетащите элементы Assessor Management, Business Rules Engine, Document Handler и Assessor из модели WebSphere Business Integration Modeler [пакет RootResourceModel \to Roles (Роли)].
    Совет. Перетаскивайте компоненты на схему в том порядке, в котором вы хотите расположить их на схеме. Порядок должен быть главным образом таким: слева направо в порядке потока итераций. После того как вы поместите линию жизни на схему последовательностей, ее будет трудно переместить. Так что стоит определять нужный порядок с первого раза.
  5. После того как вы заполнили схему последовательностей, вы можете вывести на экран визуализацию кооперации, щелкнув правой кнопкой мыши по кооперации External Claim Assessor и выбрав пункт меню Visualize (Визуализация) \to Show in Browse Diagram (Показать в обзорной схеме).
Кооперация External Claim Assessor

Рис. 6.2. Кооперация External Claim Assessor

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

  • Assessor Automation:
    • ReturnAvailability;
    • ReturnAssessmentConfirmation;
    • ReceiveAssessmentReport;
  • proxyAssessorSystem:
    • ProxyReturnAvailability;
    • ProxyAssesmentConfirm.

Для этого было две причины:

  • В потоках 6 и 7 мы хотели получить от оценщика помимо отчета об оценке (потоки 8 и 9) подтверждение, что он будет выполнять оценку.
  • Существует только одна комбинация потоков (потоки 6, 7, 8 и 9), которую нельзя смоделировать в виде пар вызов/ответ (два ответа подтверждение и посылка данных, получаются в ответ на запрос). Строго говоря, нам в действительности не были бы нужны все эти новые интерфейсы, если бы мы могли полностью положиться на асинхронное промежуточное ПО, такое, как WebSphere MQ, WebSphere MQ Workflow и WebSphere Business Integration Server Foundation. Например, планируется, что выполнение запроса о доступности оценщика займет 2 часа. На уровне бизнеса это очевидное взаимодействие типа запрос/ответ и его можно эффективно реализовать на промежуточном программном обеспечении WebSphere. Однако оказывается, что некоторые транспортные уровни, например http:/SOAP, не являются подходящей реализацией такой схемы, поскольку они должны быть заблокированы на весь срок взаимодействия. Оказывается нерациональным заставлять систему оценщика реализовывать ответ в пределах одной единицы работы.

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

После завершения схема последовательностей будет выглядеть примерно так, как показано на рис. 6.3 и рис. 6.4. Аннотации те же, что на схеме потока решения ( рис. 6.1). Обратите внимание на использование синхронных и асинхронных потоков.

Схема последовательностей External Claim Assessor: левая сторона

увеличить изображение
Рис. 6.3. Схема последовательностей External Claim Assessor: левая сторона
Схема последовательностей External Claim Assessor: правая сторона

увеличить изображение
Рис. 6.4. Схема последовательностей External Claim Assessor: правая сторона
< Лекция 5 || Лекция 6: 123456 || Лекция 7 >
Александр Кудаков
Александр Кудаков
Россия