НОУ ИНТУИТ | Создание бизнес-процесса с помощью инструментов Rational и WebSphere. Лекция 6: Моделирование. Архитектура решения

Учитесь и получайте официальные документы БЕСПЛАТНО. Вы можете поддержать наш проект.

Регистрация Вход

Твой путь к знаниям!

|

Вам нравится? Нравится 20 студентам

| Поделиться |

Поддержать программу

6.2.5 Включение интерфейсов в компонентную модель

Независимо от того какой подход к созданию интерфейсов мы использовали, сейчас у нас есть WSDL-файл и EJB для каждого интерфейса. Мы можем применять EJB для включения реальных интерфейсов, полученных из WSDL-определений, в UML-модель. Продемонстрируем это на примере службы AssessorManagement.

Создайте компонентную схему с именем Assessor Management Component Diagram для компонента Assessor Management в проекте ITSO Architect. Поместите на схему компоненты AssessorAutomation, Assessor Management и роль AssessorManagement (BusinessWorker) из модели WebSphere Business Integration Modeler.
В Model Explorer выберите AssessorManagementServiceEJB $\to$ ejbModule $\to$ itso.lgi.assessormgmt $\to$ AssessorManagement.java. Перетащите java-интерфейс AssessorManagement на схему Assessor Management Component Diagram.
Создайте отношение типа Realizes (Реализует) от компонента AssessorManagement к java-интерфейсу AssessorManagement и детализуйте связь между java-интерфейсом AssessorManagement и ролью Assessor Management Business Worker.
Убедитесь, что в набор необходимых интерфейсов компонента AssessorAutomation входит интерфейс AssessorAutomation. Для этого нужно перетащить элемент Assessor Management Role от компонента AssessorManagement в раздел Required Interfaces (Необходимые интерфейсы) компонента AssessorAutomation.
Если взаимосвязи еще не существуют, создайте взаимосвязь типа use (использует) между компонентом AssessorAutomation и компонентом AssessorManagement. Схема компонентов должна выглядеть так, как показано на рис. 6.21.

Рис. 6.21. Детализация системы AssessorManagement
Теперь мы можем модифицировать схему последовательности ( рис. 6.3), изменив в линии жизни применение роли AssessorManagement на использование java-интерфейса AssessorManagement. Теперь мы можем употребить операцию из java-интерфейса AssessorManagement для указания взаимодействия между системой AssessorAutomation и системой AssessorManagement. Фрагмент схемы, заключающий в себе линию жизни AssessorManagement, показан на рис. 6.22.

Рис. 6.22. Фрагмент детализованной схемы последовательности

6.2.6 Общий обзор интерфейсов

Все детали интерфейсов вы можете найти в дополнительных материалах к этому курсу, либо через обращение к исходным файлам, перечисленным в табл. 6.2, либо путем импортирования в рабочее пространство проекта ITSO Architecture, который находится в директории .\SG24-6636\RSA\Project Interchange\ITSO Architecture дополнительных материалов.

В табл. 6.3 описываются некоторые важные решения, которые архитектор принимает по поводу интерфейсов.

Таблица 6.3. Характеристики взаимодействий
Поток	Компонент (владелец интерфейса)	Характеристики взаимодействия
1	Assessor Automation	Используется JMS, а не SOAP-служба. XML-сообщения передаются через JMS. Выбор транспортного протокола основывался на выборе взаимодействия типа запрос/ответ между длительно работающими процессами. Для такого вида взаимодействий Process choreographer поддерживает только JMS/XML
2	Assessor Management	Это простой интерфейс типа вызов/ответ. Он будет соответствовать связи с партнером в BPEL, и варианты транспорта для него - SOAP/Http или SOAP/JMS. Мы выбрали SOAP/Http. SOAP/JMS как транспортный протокол имел бы здесь небольшое преимущество. Соединение не выходит за пределы LGI, поэтому проблем совместимости не возникает. SOAP/JMS обеспечивает лучшую масштабируемость и лучшие возможности управления, чем SOAP/http, за счет более высокой стоимости первоначальной установки, связанной с формированием очередей, фабрик соединений, точек назначения и инфраструктуры WebSphere MQ. Взаимодействия здесь краткосрочные, поэтому разница в качестве обслуживания для SOAP/JMS и SOAP/http не представляет большой проблемы. Однако в тот момент, когда мы выполняли интеграцию, были опубликованы данные об ограничениях использования SOAP/JMS и Business Process Choreographer, поэтому мы решили стандартно употребить для всего нашего SOAP-транспорта протокол SOAP/http
2a	Business Rules Engine	То же
3	Proxy Assessor System	Это более интересное взаимодействие, поскольку запрос приводит к тому, что процесс распространяет запросы по нескольким оценщикам и ожидает их ответа. Он собирает полученные ответы в единый ответ (поток 3а), отбрасывая ответы, пришедшие с опозданием. Однако с точки зрения потока 3 это простое взаимодействие типа вызов/ответ с длительным промежутком времени между вызовом и ответом. Из-за того что мы приняли решение использовать для всех взаимодействий SOAP/Http, взаимодействие разделяется на два, где реальный ответ (3а) находится во взаимодействии, отличном от того, в котором находится запрос. Запрос можно реализовать как одностороннее или двустороннее SOAP-сообщение. Мы выбрали двусторонний вариант, чтобы процесс AssessorAutomation мог знать, что запрос был получен системой proxyAssessorSystem
4	Assessor	Assessor В требованиях было указано, что поток 4 должен поддерживать несколько разных протоколов. Мы реализовали только SOAP/Http. Как и в случае с потоком 3, ответ находится в отдельном потоке из-за большого интервала между запросом и ответом, а также из-за того, что ответ необязателен (оценщик может решить не браться за работу). Мы использовали для потока 4 взаимодействие типа запрос/ответ
4a	Proxy Assessor System	То же
3a	Assessor Automation	Реализуется как односторонняя дейтаграмма SOAP/http
5	Business Rules Engine	См. поток 2а
6	Proxy Assessor System	См. поток 3
7	Assessor	См. поток 4
7a	Proxy Assessor System	См. поток 4а. На поток 7 выбранный оценщик отвечает двумя потоками – 7a и 8, которые оба выполняются через какое-то время после потока 7.
6a	Assessor Automation	См. поток 3а
8	Proxy Assessor System	См. поток 7а
9	Assessor Automation	См. поток 6а
10	Claim System	Это простой синхронный поток типа запрос/ответ, похожий на поток 5

Дальше >>

Авторизоваться

Создание бизнес-процесса с помощью инструментов Rational и WebSphere

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

6.2.5 Включение интерфейсов в компонентную модель

6.2.6 Общий обзор интерфейсов

Вопросы и ответы