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

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

Разбить на страницы
Показывать лекцию целиком

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

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

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

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

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

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

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

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

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

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

    (рис 6.1) Поток в решении

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

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

    Описание взаимодействий
    Поток Описание
    1 Новый процесс запускается из существующего процесса Claim Workflow (Управление потоком претензий) путем отправки запроса на получение отчета внешнего оценщика. Интерфейсом этого запроса является requestAssessor – XML-документ, выпускаемый очередью WebSphere MQ. Это синхронный запрос типа вызов/ответ (см. поток 1а), и для него планируется время ответа 2 дня. Используемые системы параллельной обработки могут эффективно и надежно реализовывать такие длительные синхронные запросы. Процесс автоматизации работы с внешними оценщиками (Assessor Automation), который реализуется через оркестровку бизнес-процессов (Business Process Choreography) получает это сообщение и запускает новый экземпляр процесса
    2 Первая задача процесса автоматизации работы с оценщиками (Assessor Automation) - это вызов системы управления оценщиками (Assessor Management) для получения списка доступных оценщиков. Интерфейс называется assessorManagment. Это синхронный вызов типа вызов/ответ, и для него ожидается ответ в пределах секунды
    2а Вторая задача – это получение времени ответа на основе установленного с клиентом соглашения об уровне обслуживания, которое обрабатывается системой 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. Это синхронный вызов типа вызов/ответ, и для него ожидается ответ в пределах секунды
    1а Система автоматизации работы с оценщиками возвращает управление в Claims Workflow, используя интерфейс requestAssessorResponse

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

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

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

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

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

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

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

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

    6.2 Интерфейсы

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

    Допущения

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

    Мы также предполагаем, что все автоматизированные службы (Assessor Management, Business Rules Engine, Claim System) и процесс Assessor уже доступны в виде EJB. Мы сконцентрируемся на построении бизнес-процесса и интеграции служб, а не на создании программ.

    6.2.1 Выбор языка описания интерфейсов

    Мы планируем использовать для соединения компонентов Web-службы; следовательно, для описания интерфейсов в архитектурной модели мы будем применять язык описания Web-служб (Web Services Description Language, WSDL). WSDL – это вполне естественный способ описания Web-служб.

    Использование WSDL в качестве языка описания интерфейсов

    Как язык описания интерфейсов WSDL обладает рядом преимуществ:

  • Он не зависит от программной технологии, используемой для реализации интерфейсов.
  • Ряд технологий программирования поддерживает применение WSDL для генерации и запуска Web-служб, независимо от того, будут ли это Java Beans, Enterprise Java Beans, службы .NET или потоки сообщений WebSphere Business Integration Message Broker.
  • Он поддерживается прекрасными инструментами.
    •

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

  • Технология имеет как логический аспект, представленный типами портов (PortType) и сообщениями (Message), так и физический аспект, представленный службами (Services) и связями (Bindings), которые не соответствуют понятию интерфейса как раннего этапа превращения модели в реализацию. Простым решением будет избирательный подход к заполнению WSDL-определений на всех стадиях проектирования.
  • Данная технология не интегрирована в инструментарий UML до такой степени, чтобы, скажем, EJB могли интегрироваться в Rational Software Architect. Не существует простого способа вводить WSDL-определения в UML модель и исключать их из нее. Мы предлагаем четыре метода обмена WSDL и UML в зависимости от того, откуда архитектор решения получил определения интерфейсов. Обращайтесь к рис 6.5.
  • Поскольку в различных инструментах отсутствуют средства импорта WSDL, существуют определенные трудности при формировании цепочки инструментов на основе WSDL как языка определения интерфейсов. Однако никаких конкурентов с лучшим охватом инструментов нет, за исключением, пожалуй, XML-схемы. Мы считаем, что WSDL как язык определения интерфейса лучше, чем XML-схема, поскольку XML-схема – это главным образом способ независимого от языка описания типа данных. WSDL описывает интерфейсы компонентов, составленные из операций и типизованных сообщений.
    •

    Комбинированное использование WSDL и встроенных файлов .xsd (XML-схем) имеет определенную привлекательность из-за того, что комбинацию WSDL и схем поддерживает более широкий набор инструментов. Мы склоняемся к тому, чтобы размещать определения типов в WSDL-файлах, поскольку использованные нами EJB- инструменты генерировали типы данных прямо в WSDL-файлах. Если бы мы уделяли больше внимания данным, мы, вероятно, больше использовали бы .xsd-файлы, а в WSDL-файлах применяли инструкции импорта. Выбор между использованием только WSDL или комбинации WSDL и .xsd, по сути, определяется цепочкой инстру- ментов. Мы вернемся к этому обсуждению в разделе 13.1.4, "Метаданные" и придем к противоположному заключению, что для нас нет ничего лучше использования сме- си файлов .WSDL и .xsd. Это действительно сложное решение!

    С точки зрения управления проектом представление о том, что все интерфейсы, используемые в проекте, могут быть подробно описаны в едином формате, весьма ценно, поэтому мы решили, что все интерфейсы в решении будут определены на WSDL и собраны архитектором решения, который отвечает за их определение. В Rational Software Architect входит прекрасный WSDL-редактор. В WebSphere Studio Application Development Integration Edition также предлагается редактор файлов .xsd.

    6.2.2 Создание WSDL-интерфейсов

    Существует три основных способа создания WSDL-интерфейсов:

  • Сверху вниз, с помощью редактора WSDL.
  • Снизу вверх, путем генерации WSDL из других реализаций и типов интерфейсов. Например, Rational Software Architect генерирует WSDL-файлы из EJB-компонентов.
  • От краев к центру, путем создания части интерфейсов в WSDL-редакторе и импортирования остальных из другого формата, например импортирования типов из файлов .xsd.
    •

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

    (рис 6.5) Интеграция WSDL-интерфейсов с UML-моделью
  • A. Этот способ используется, если у нас уже есть WSDL-определения. Подробности приводятся в разделе "А: WSDL в UML".
  • В. Способ создания нового интерфейса. Используйте средство трансформации EJB в Rational Software Architect для генерации EJB, а затем сгенерируйте Web- службу. Процесс создания EJB из UML снабжен пояснениями. Подробности вы можете найти в разделе "В: UML в WSDL".
  • C. Используется для интерфейсов, созданных в WebSphere Business Integration Message Broker. Эти типы интерфейсов создавались как схемы в WebSphere Studio Application Development Integration Edition и импортировались в Broker с созда- нием набора сообщений. Объяснения приводятся в разделе 9.4, "Реализация набо- ров сообщений".

    Схемы также встраиваются в WSDL-файлы в WebSphere Studio Application Development Integration Edition, и генерируется EJB-компонент. Этот EJB-компонент импортируется в Rational Software Architect, и из него извлекается UML-описание интерфейса. Детали этого процесса аналогичны пути А после импортирования .xsd-файла.

    •

    Данный EJB-компонент также может применяться для модульного тестирования клиентов Web-службы без необходимости ждать реализации WebSphere Business Integration Message Broker.

  • D. Существующие EJB-интерфейсы (например, система Assessor Management) импортируются в Rational Software Architect, и из EJB генерируются UML- и WSDL- интерфейсы. Данный метод объясняется в разделе "В: UML в WSDL".
    •

    6.2.3 Источники информации об интерфейсах в нашем сценарии

    WSDL-файлы и файл .xsd с определениями интерфейсов создаются либо из EJB-компонентов, которые должны использоваться для реализации некоторых служб, либо в ходе задачи по определению интерфейсов для процессов AutomatedAssessor и AssessorProxyService. Общим правилом является то, что владелец Web-службы должен при определении интерфейса службы сотрудничать с архитектором решения.

    В табл. 6.2 перечислены WSDL-файлы, которые вы можете найти в директории дополнительных материалов, прилагаемых к этому курсу (.\SG24-6636\). Имена включают в себя номер потока для упрощения перекрестных ссылок. Все WSDL-файлы находятся в директории .\SG24-6636\RSA\Project Interchange\wsdl.

    Сведения о файлах WSDL и .ear
    Поток Компонент (владелец интерфейса) Сведения об интерфейсе. Имя WSDL-файла. Источник, из которого он был сгенерирован
    1 Assessor Automation ExternalClaimAssessorsInterface.wsdl. Происходит из папки в proxy(1).wsdl. Proxy(1).wsdl был создан с помощью инструмента fdl2wsdl и описывается в лекции 11, "Изменение процесса Claim Investigation"
    2 Assessor Management AssessorManagement(2).wsdl .\SG24-6636\WAS\Flow2\Flow2_AssessorManagementSe rvice_SOURCE.ear
    2a Business Rules Engine RequestResponseTimePT(2a).wsdl .\SG24-6636\WAS\Flow2A\Flow2A_ResponseTimeRules_ SOURCE.ear
    3 Proxy Assessor System AssessorAvailability(3).wsdl .\SG24-6636\WBIMB\schemas\AssessorAvailability_3.xsd
    4 Assessor Availability(4).wsdl .\SG24-6636\WAS\Flow4and7\AssessorAvailabilityApplications_withSource.ear
    4a Proxy Assessor System AssessorAvailabilityPT(4a).wsdl .\SG24-6636\WBIMB\schemas\AssessorAvailabilityPT.xsd
    3a Assessor Automation AssessorAvailablityList(3a).wsdl
    5 Business Rules Engine PreferredAssessor(5).wsdl .\SG24-6636\WAS\Flow5\Flow5_AssessorRules_SOURC E.ear
    6 Proxy Assessor System AllocateAssessmentReport(6).wsdl .\SG24-6636\WBIMB\schemas\AllocateAssessmentReque st_6.xsd
    7 Assessor DeliverAssessment(7).wsdl .\SG24-6636\WAS\Flow4and7\AssessorApps.ear
    7a Proxy Assessor System DeliverAssessmentResponse(7a).wsdl .\SG24-6636\WBIMB\schemas\DeliverAssessmentRespon se_7a.xsd
    6a Assessor Automation AllocateAssessorResponse(6a).wsdl
    8 Proxy Assessor System AssessorReport(8).wsdl .\SG24-6636\WBIMB\AssessorReport_8.xsd
    9 Assessor Automation AssessorReport(9).wsdl
    10 Claim System StoreAssessmentReport(10).wsdl .\SG24-6636\WAS\Flow10\Flow10_DocumentHandler_SO URCE.ear

    6.2.4 Создание определений интерфейсов

    Вместо подробного рассмотрения создания интерфейсов и описания полей, мы приводим все интерфейсы в составе дополнительных материалов с указанием источника, который мы использовали для создания WSDL-интерфейса, если только он не создавался с нуля. Для формирования интерфейсов мы использовали одну из процедур, обозначенных буквами с А по D в предыдущем разделе.

    Все WSDL-описания интерфейсов и .ear-файлы можно импортировать в Rational Software Architect и просматривать при помощи редактора Web-служб. Эти файлы можно сохранить в проекте ITSOLGI Architecture.

    Многие из WSDL-файлов были сгенерированы из EJB-реализаций, указанных в табл. 6.2, с использованием подхода "снизу вверх". Этот подход весьма типичен для проектов корпоративной интеграции, где Web-службы употребляются в качестве оболочек существующих интерфейсов, в нашем случае – EJB-реализаций. Здесь мы демонстрируем оба подхода к включению интерфейсов из WSDL-описаний в UML-модель – "сверху вниз" и "снизу вверх".

    А: WSDL в UML

    Подход А начинается с WSDL-файлов. Эти файлы могут быть созданы в Rational Software Architect или формированы в выбранном вами инструменте и импортированы в Rational Software Architect.

    (рис 6.6) WSDL в UML

    Создание нового WSDL-файла в Rational Software Architect

    Чтобы создать новый WSDL-файл в Rational Software Architect, выполните следующие действия:

  • Выберите пункт меню File (Файл) > New (Новый) $$\to$$ Other (Другое) $$\to$$ WSDL $$\to$$ Next (Далее). Выберите проект и имя файла, например Assessor.wsdl. Нажмите Next (Далее). Выберите целевое пространство имен, чтобы обозначения WSDL-определений были уникальными. Мы использовали в качестве корневого имени http://itso.lgi.assessormgmt и добавили к нему в данном случае /Assessor. Затем мы добавляем префикс, например ama. Оставьте выбранной опцию Create WSDL skeleton (Создать каркас WSDL) и укажите опции (рис 6.7) Создание WSDL-файла: опции
  • Теперь вы можете отредактировать WSDL-файл, используя либо графический редактор, либо редактор страниц XML, либо простой текстовый редактор, щелкнув правой кнопкой мыши по файлу Assessor.wsdl и выбрав один из вариантов в пункте меню Open with (Открыть с помощью).Важно! В параметрах пространства имен или проекта добавьте параметр совместимости WS-I SSBP Require.

    • Альтернативным подходом является импортирование WSDL-файла.

    Прямое импортирование WSDL-файла и его отображение

    Чтобы импортировать WSDL-файл, выполните следующие шаги:

  • Переключитесь на перспективу Resources (Ресурсы), поскольку WSDL не интегрирован в UML и нет способа просматривать WSDL из перспективы UML modeling. Переключитесь на перспективу Resource (Ресурсы). В верхнем правом углу рабочего пространства нажмите на значок Perspectives (Перспективы) или выберите пункт меню Window (Окно) $$\to$$ Open Perspective (Открыть перспективу) $$\to$$ Other (Другая) $$\to$$ Resource (Ресурс).
  • Выберите в Model Explorer пункт ITSOLGI Architecture, щелкните правой кнопкой мыши, выберите пункт меню New (Новая) $$\to$$ Folder (Папка) $$\to$$ WSDL $$\to$$ Finish (Готово).
  • Перетащите WSDL-файлы из мест, показанных в табл. 6.2, в только что созданную папку WSDL.
  • Сделайте двойной щелчок по одному из WSDL-файлов, например PreferredAssessor(5). wsdl, чтобы WSDL отобразился в графической форме, или перейдите к исходному WSDL-файлу (см. рис 6.8 и рис 6.9).
    •  (рис 6.9) WSDL-определение PreferredAssessor (1)(рис 6.8) WSDL-определение PreferredAssessor (2)

    Генерация каркаса EJB для Web-службы

    Теперь мы сгенерируем EJB из определения Web-службы. Мы не будем использовать для ear-файлов существующий проект ITSOLGI Architecture, а создадим новый проект корпоративного приложения (Enterprise Application Project).

    Совет. У вас могут оказаться недоступными перспективы J2EE и Web service. В этом случае посмотрите в параметрах возможностей рабочего пространства опцию Web services and J2EE developer (Разработчик Web-служб и J2EE).
  • Создайте новый проект корпоративного приложения:
  • Выберите пункт меню File (Файл) $$\to$$ New (Новый) $$\to$$ Project (Проект) $$\to$$ J2EE $$\to$$ Enterprise Application Project $$\to$$ ITSOLGI Web services $$\to$$ J2EE Version 1.3 $$\to$$ Target Server (Целевой сервер) $$\to$$ WebSphere Application Server 5.1 $$\to$$ Next (Далее) $$\to$$ Finish (Готово). Ответьте Yes на вопрос Switch to the J2EE perspective (Переключиться на перспективу J2EE).Примечание. Мы ведем реализацию на платформе WebSphere 5.1. Чтобы эта опция была доступна в Rational Software Architect 6.0, у вас в Rational Software Architect должна быть установлена тестовая среда WebSphere 5.1 Test environment. Мы выбрали J2EE version 1.3, поскольку мы используем версию 5.1 тестовой среды. Версия J2EE 1.4 впервые появилась в тестовой среде WebSphere Application Server 6.0.
  • Может возникнуть ошибка, связанная с конфигурационным файлом applications.xml. Пока не обращайте на это внимания.
    •
  • Создайте новую Web-службу для интерфейса PreferredAssessor:
  • Выберите проект ITSOLGI Implementation, щелкните правой кнопкой мыши и выберите пункт меню New (Новый) > Other (Другое) > Web services (Web-службы) > Web service (Web-служба) > Skeleton EJB Web service (Каркас EJB для Web-службы). Отключите опцию Start Web service in a Web Project (Запускать Web-службу в Web-проекте), установите опции Overwrite files without warning (Перезапись файлов без предупреждения) и Create folders when necessary (Создавать папки по мере необходимости) и нажмите Next (Далее). Перейдите к импортированному WSDL-файлу PreferredAssessor(5).wsdl и нажмите Next (Далее).
  • Отредактируйте конфигурацию размещения службы, указав использование J2EE 1.3 и WebSphere Application Server test environment 5.1. Нажмите Next (Далее).
  • Оставьте параметры, заданные по умолчанию, без изменений и нажмите Finish (Готово).

    • Включение интерфейса в UML-модель

    Визуализируйте службу [мы ищем интерфейс PreferredAssessor, который в WSDL соответствует типу порта (PortType) PreferredAssessor].

  • Вернитесь к перспективе Modeling (Моделирование).
  • Откройте пакет itso.lgi.assessormgmt в java-проекте WebServiceProjectClient.
  • Щелкните правой кнопкой мыши по файлу PreferredAssessor.java, выберите пункт меню Visualize (Визуализация) $$\to$$ Explore in Browse diagram (Изучить в обзорной cхеме).
    •

    Мы должны увидеть картину, похожую на рис 6.10.

    (рис 6.10) Удаленный EJB-интерфейс Preferred Assessor

    В: UML в WSDL

    Подход ). Чтобы продемонстрировать работу данного подхода, мы используем простой пример службы, которая умножает два числа.

    (рис 6.11) UML в WSDL

    Создание UML-интерфейса

    Чтобы создать интерфейс, выполните следующие шаги:

  • Создайте UML-проект.

    В Rational Software Architect выберите пункт меню File (Файл) > New (Новый) > Other (Другое) > UML Project (UML-проект). Присвойте проекту имя Sums и нажмите Next (Далее). Оставьте выбранные по умолчанию параметры (Blank Model, пустая модель), но измените заданную по умолчанию схему на Class Diagram (Схема классов). Нажмите Next (Далее). Не выбирайте никаких проектов и нажмите Finish (Готово).

  • Создайте UML-интерфейс:
  • Перетащите с правой палитры элемент Interface (Интерфейс) на канву, нажмите на имя Interface1 и измените его на Sums.
  • Щелкните правой кнопкой мыши по элементу Sums и выберите пункт меню Add UML (Добавить UML) $$\to$$ Operation (Операция). Переименуйте операцию в Multiply.
  • Откройте интерфейс Sums в Model Explorer и щелкните правой кнопкой мыши по элементу Multiply(). Выберите пункт меню Add UML (Добавить UML) $$\to$$ Parameter (Параметр). Назовите параметр m1.
  • Повторите операцию, чтобы добавить параметр m2 и элемент Return result с именем result.
  • Укажите тип параметров и результата:
  • Выберите параметр в Model Explorer, откройте закладку Advanced (Дополнительно) в редакторе свойств и найдите свойство Type (Тип), которое будет пустым.
  • Щелкните мышью по второму столбцу свойства Type (Тип) и укажите тип Integer.
  • Повторите эту процедуру для параметров m2 и result.
    •  (рис 6.12) Интерфейс Sums

    Создание Java-интерфейса

    Создайте трансформацию UML в Java (рис 6.13), выполнив следующие шаги:

  • В главном меню выберите пункт Modeling (Моделирование) $$\to$$ Transform (Трансформация) $$\to$$ Configure Transformations (Конфигурация трансформаций). Выберите пункт UML to Java (UML в Java) $$\to$$ New (Новая). Назовите трансформацию SumsTransform.
  • Около поля Source: нажмите ... , выберите пункт Sums Interface (Интерфейс Sums). В области Target (Цель) диалогового окна выберите Create New Target Container (Создать новый целевой контейнер).
  • В диалоговом окне Java Project введите в поле Project name: SumsJava, нажмите Next (Далее), нажмите SumsJava на закладке Order and Export (Порядок и экспорт) и нажмите Finish (Готово).
  • На панели ).
  • Трансформацию можно запустить прямо из редактора конфигурации или из главного меню (рис 6.14).
    •  (рис 6.14) Конфигурация трансформации UML в EJB(рис 6.13) Запуск SumsTransform из главного меню

    При этом в заданном по умолчанию пакете проекта SumsJava создается файл Sums. java. Откройте схему по умолчанию проекта Sums и перетащите на нее файл Sums. java. Вы можете увидеть новый интерфейс Sums, стереотипированный к <<Java Interface>> (рис 6.15).

    (рис 6.15) Java-интерфейс Sums

    Создание соответствий WSDL

    Чтобы создать соответствие, выполните следующие шаги:

  • Создайте Web-проект:
  • Выберите пункт меню File (Файл) $$\to$$ New (Новый) $$\to$$ Project (Проект) $$\to$$ Dynamic Web Project (Динамический Web-проект). Назовите проект SumsWebProject, нажмите Next (Далее), снимите все опции, нажмите Next (Далее), затем Finish (Готово).
  • Щелкните правой кнопкой мыши по пункту JavaSource в проекте SumsWebProject, выберите пункт меню New (Новый) $$\to$$ Package (Пакет) и назовите пакет mathematics.
  • Щелкните мышью при нажатой клавише Ctrl по файлу Sums.java в папке SumsJava и перетащите его в папку JavaSource. Нажмите OK, чтобы элементы были перестроены.
    •
  • Создайте Web-службу Java:
  • Выберите файл Sums.java в пакете mathematics. Выберите пункт New (Новый) $$\to$$ Other (Другое) $$\to$$ Web service (Web-служба) $$\to$$ Next (Далее) $$\to$$ Java Bean Web service (Web-служба Java Bean) (примите остальные параметры как есть). Нажмите Next (Далее).
  • В поле Bean (Компонент) должен быть указан компонент mathematics.Sums (рис 6.16). Нажмите Next (Далее). Если это не так, нажмите Browse files (Обзор файлов) и выберите проект (рис 6.16) Java-интерфейс Sums
  • На следующей панели укажите проект службы SumsWebProject и EA-проект SumsWebProjectEAR. Нажмите Next (Далее). Оставьте без изменений опции интерфейса конечной точки и опции Web-службы (рис 6.17). Нажмите Next (Далее), затем (рис 6.17) Опции Web-службы
  • Просмотрите получившийся WSDL-файл, который можно найти через Project Explorer в перспективе Web. Выберите пункт Dynamic Web Projects (Динамические Web-проекты) $$\to$$ ).(рис 6.18) Web-служба Sums

    • Теперь, когда у нас есть WSDL-определение операции, мы можем сгенерировать EJB, используя процедуру А.

    D: EJB в UML и WSDL

    Для демонстрации мы импортируем один из .ear-файлов, приведенных в табл. 6.2, и генерируем WSDL-определение интерфейса.

  • Импортируйте файл .\SG24-6636\WAS\Flow2\Flow2_AssessorManagementService_SOURCE.ear в новый EAR-проект:
  • Выберите папку ITSOLGI Web services, щелкните правой кнопкой мыши по пункту Import (Импорт) и выберите пункт меню EAR file (EAR-файл), после чего нажмите Next (Далее).
  • Выберите файл Flow2_AssessorManagementService_SOURCE.ear, укажите сущес- твующий проект ITSOLGI Web services (созданный в примере А в разделе "Гене- рация каркаса EJB для Web-службы"), отключите опцию Import Project (Импортировать проект). Выберите опцию Overwrite existing resources without warning (Перезаписывать имеющиеся ресурсы без предупреждения), нажмите Next (Далее), затем снова Next (Далее), включите опцию Allow nested projects overwrites (Разрешать перезапись вложенных проектов).
  • Убедитесь, что выбраны оба файла AssessorManagementServiceEJB.jar и AssessorManagementServiceEJBRouter. jar. Нажмите Finish (Готово).
    •
  • Изучите в WSDL-файле службу AssessorManagement Service:
  • выберите в Model Explorer пункт Web services (Web-службы) $$\to$$ Services (Службы) $$\to$$ AssessorManagementService ;
  • откройте файл WSDL:AssessorManagementServiceEJB/ejbModule/METAINF/wsdl/AssessorManagement.wsdl (рис 6.19и рис 6.20).
    • (рис 6.20) AssessorManagement.wsdl – часть 1(рис 6.19) AssessorManagement.wsdl – часть 2
  • Чтобы использовать EJB-интерфейсы в UML, перетащите удаленный интерфейс EJB на любую UML-схему, с которой вы работаете. В следующем разделе иллюстрируется включение интерфейсов для ExternalClaimsAsessor, созданных по WSDL-определениям, в UML-схему компонентов и UML-схему последовательностей.

    • 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 описываются некоторые важные решения, которые архитектор принимает по поводу интерфейсов.

    Характеристики взаимодействий
    Поток Компонент (владелец интерфейса) Характеристики взаимодействия
    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

    6.3 Контракты архитектора

    Архитектор создает два продукта – PIM и PSM (см. рис 3.7).

    PIM

    В модели PIM (модель, независимая от платформы) архитектор решения должен совместно с бизнес-аналитиком рассмотреть перечисленные ниже материалы, чтобы удостовериться в том, что реализация будет функционировать в соответствии с моделью бизнес-процесса.

  • Общий обзор требований к решению, возможно с использованием шаблона RUP, например документа Vision. Обращайтесь к разделу 5.2, "Шаг 0. Сбор требований".
  • Компонентная архитектура (рис 5.8).
  • Соответствия рабочей системы (рис 5.22).
  • Функционирование решения, отображаемое на схеме потоков или на схеме последовательности (рис 6.1 или рис 6.3 и 6.4).
  • Модель данных, зафиксированную в форме потоков, которыми обмениваются компоненты. Это описывается в разделе messages в WSDL (см. напр. рис 6.9).
    •

    PSM

    В модели PSM (модель, специфическая для платформы) архитектор решения распределяет требования по инфраструктуре системы так, чтобы решение работало, и связывает решение с различными технологиями, чтобы ИТ-специалисты могли вести реализацию. Архитектор решения должен предоставить архитектору инфраструктуры и ИТ-специалистам следующие материалы по PSM (в дополнение к PIM):

  • связь с продуктами (рис 5.23 или рис 5.24);
  • связи WSDL, а также типы портов (PortType) и сообщения (рис 6.8). Заполнением определения службы занимается архитектор инфраструктуры;
  • соответствия рабочей системы (рис 5.22);
  • функционирование решения, отображаемое в виде схемы потоков или схемы последовательностей (рис 6.1 или рис 6.3 и 6.4).
    •

    Создание компонентов Java Beans (которым мы занимались в разделе "Генерация каркаса EJB для Web-службы") выходит за рамки абсолютно обязательной для архитектора работы над PSM. Это было бы полезно для связывания WSDL-определений интерфейсов и UML-модели, но данной цели можно достигнуть и при помощи комментариев к интерфейсам.

    Команда разработки должна решить, будет ли оправданной дополнительная работа архитектора по созданию каркаса EJB. Возможно, она будет оправданна для служб, которые будут создаваться в форме EJB, Java Beans или объектов C++, но будет бесполезной для служб, являющихся оболочками существующих компонентов или созданных с помощью других технологий, например в WebSphere Business Integration Message Broker. Навыки по правильному созданию компонентов больше относятся к компетенции ИТ-специалиста, который будет реализовывать компоненты, а не архитектора.

    6.4 Обеспечение доступа к материалам

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

    Откройте перспективу Resources (Ресурсы) в Rational Software Architect и выберите проект ITSOLGI Architecture $$\to$$ WSDL. Выделите все WSDL-файлы, щелкните правой кнопкой мыши и выберите пункт меню Export (Экспорт) $$\to$$ Zip file (zip-файл) $$\to$$ Next (Далее). Установите опции Compress (Сжатие) и Create directory structure for files (Создавать структуру директорий для файлов) и убедитесь в том, что отмечены все нужные файлы. Укажите имя создаваемого файла, например ClaimInvestigation WSDL files, и нажмите ).

    (рис 6.23) Экспортированные WSDL-файлы

    6.5 Заключение

    В этой лекции архитектор решения занимался детализацией архитектуры системы, созданной в лекции 5, "Архитектура системы", формируя тем самым функционирование системы. Архитектура решения описывается схемами последовательностей, схемами WSDL-интерфейсов и схемами компонентов.

    В WSDL-схемах обеспечивается высокий уровень детализации, от физических транспортных методов и адресов размещаемых компонентов до определения взаимодействий и схем сообщений, используемых при взаимодействиях. Конечно, на данной стадии не обязательно указывать все детали.

    Схемы компонентов имеют двоякое применение. Они связывают исходные определения интерфейсов с детализованными спецификациями интерфейсов, применяемыми в реализации, а также (для компонентов, реализуемых как Java Beans или классы С++) их можно использовать для построения и последующей генерации объектов, реализующих модель.

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

    Страницы:

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

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

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

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

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

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

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

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

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

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

    (рис 6.1) Поток в решении

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

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

    Описание взаимодействий
    Поток Описание
    1 Новый процесс запускается из существующего процесса Claim Workflow (Управление потоком претензий) путем отправки запроса на получение отчета внешнего оценщика. Интерфейсом этого запроса является requestAssessor – XML-документ, выпускаемый очередью WebSphere MQ. Это синхронный запрос типа вызов/ответ (см. поток 1а), и для него планируется время ответа 2 дня. Используемые системы параллельной обработки могут эффективно и надежно реализовывать такие длительные синхронные запросы. Процесс автоматизации работы с внешними оценщиками (Assessor Automation), который реализуется через оркестровку бизнес-процессов (Business Process Choreography) получает это сообщение и запускает новый экземпляр процесса
    2 Первая задача процесса автоматизации работы с оценщиками (Assessor Automation) - это вызов системы управления оценщиками (Assessor Management) для получения списка доступных оценщиков. Интерфейс называется assessorManagment. Это синхронный вызов типа вызов/ответ, и для него ожидается ответ в пределах секунды
    2а Вторая задача – это получение времени ответа на основе установленного с клиентом соглашения об уровне обслуживания, которое обрабатывается системой 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. Это синхронный вызов типа вызов/ответ, и для него ожидается ответ в пределах секунды
    1а Система автоматизации работы с оценщиками возвращает управление в Claims Workflow, используя интерфейс requestAssessorResponse

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

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

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

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

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

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

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

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

    6.2 Интерфейсы

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

    Допущения

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

    Мы также предполагаем, что все автоматизированные службы (Assessor Management, Business Rules Engine, Claim System) и процесс Assessor уже доступны в виде EJB. Мы сконцентрируемся на построении бизнес-процесса и интеграции служб, а не на создании программ.

    6.2.1 Выбор языка описания интерфейсов

    Мы планируем использовать для соединения компонентов Web-службы; следовательно, для описания интерфейсов в архитектурной модели мы будем применять язык описания Web-служб (Web Services Description Language, WSDL). WSDL – это вполне естественный способ описания Web-служб.

    Использование WSDL в качестве языка описания интерфейсов

    Как язык описания интерфейсов WSDL обладает рядом преимуществ:

  • Он не зависит от программной технологии, используемой для реализации интерфейсов.
  • Ряд технологий программирования поддерживает применение WSDL для генерации и запуска Web-служб, независимо от того, будут ли это Java Beans, Enterprise Java Beans, службы .NET или потоки сообщений WebSphere Business Integration Message Broker.
  • Он поддерживается прекрасными инструментами.
    •

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

  • Технология имеет как логический аспект, представленный типами портов (PortType) и сообщениями (Message), так и физический аспект, представленный службами (Services) и связями (Bindings), которые не соответствуют понятию интерфейса как раннего этапа превращения модели в реализацию. Простым решением будет избирательный подход к заполнению WSDL-определений на всех стадиях проектирования.
  • Данная технология не интегрирована в инструментарий UML до такой степени, чтобы, скажем, EJB могли интегрироваться в Rational Software Architect. Не существует простого способа вводить WSDL-определения в UML модель и исключать их из нее. Мы предлагаем четыре метода обмена WSDL и UML в зависимости от того, откуда архитектор решения получил определения интерфейсов. Обращайтесь к рис 6.5.
  • Поскольку в различных инструментах отсутствуют средства импорта WSDL, существуют определенные трудности при формировании цепочки инструментов на основе WSDL как языка определения интерфейсов. Однако никаких конкурентов с лучшим охватом инструментов нет, за исключением, пожалуй, XML-схемы. Мы считаем, что WSDL как язык определения интерфейса лучше, чем XML-схема, поскольку XML-схема – это главным образом способ независимого от языка описания типа данных. WSDL описывает интерфейсы компонентов, составленные из операций и типизованных сообщений.
    •

    Комбинированное использование WSDL и встроенных файлов .xsd (XML-схем) имеет определенную привлекательность из-за того, что комбинацию WSDL и схем поддерживает более широкий набор инструментов. Мы склоняемся к тому, чтобы размещать определения типов в WSDL-файлах, поскольку использованные нами EJB- инструменты генерировали типы данных прямо в WSDL-файлах. Если бы мы уделяли больше внимания данным, мы, вероятно, больше использовали бы .xsd-файлы, а в WSDL-файлах применяли инструкции импорта. Выбор между использованием только WSDL или комбинации WSDL и .xsd, по сути, определяется цепочкой инстру- ментов. Мы вернемся к этому обсуждению в разделе 13.1.4, "Метаданные" и придем к противоположному заключению, что для нас нет ничего лучше использования сме- си файлов .WSDL и .xsd. Это действительно сложное решение!

    С точки зрения управления проектом представление о том, что все интерфейсы, используемые в проекте, могут быть подробно описаны в едином формате, весьма ценно, поэтому мы решили, что все интерфейсы в решении будут определены на WSDL и собраны архитектором решения, который отвечает за их определение. В Rational Software Architect входит прекрасный WSDL-редактор. В WebSphere Studio Application Development Integration Edition также предлагается редактор файлов .xsd.

    6.2.2 Создание WSDL-интерфейсов

    Существует три основных способа создания WSDL-интерфейсов:

  • Сверху вниз, с помощью редактора WSDL.
  • Снизу вверх, путем генерации WSDL из других реализаций и типов интерфейсов. Например, Rational Software Architect генерирует WSDL-файлы из EJB-компонентов.
  • От краев к центру, путем создания части интерфейсов в WSDL-редакторе и импортирования остальных из другого формата, например импортирования типов из файлов .xsd.
    •

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

    (рис 6.5) Интеграция WSDL-интерфейсов с UML-моделью
  • A. Этот способ используется, если у нас уже есть WSDL-определения. Подробности приводятся в разделе "А: WSDL в UML".
  • В. Способ создания нового интерфейса. Используйте средство трансформации EJB в Rational Software Architect для генерации EJB, а затем сгенерируйте Web- службу. Процесс создания EJB из UML снабжен пояснениями. Подробности вы можете найти в разделе "В: UML в WSDL".
  • C. Используется для интерфейсов, созданных в WebSphere Business Integration Message Broker. Эти типы интерфейсов создавались как схемы в WebSphere Studio Application Development Integration Edition и импортировались в Broker с созда- нием набора сообщений. Объяснения приводятся в разделе 9.4, "Реализация набо- ров сообщений".

    Схемы также встраиваются в WSDL-файлы в WebSphere Studio Application Development Integration Edition, и генерируется EJB-компонент. Этот EJB-компонент импортируется в Rational Software Architect, и из него извлекается UML-описание интерфейса. Детали этого процесса аналогичны пути А после импортирования .xsd-файла.

    •

    Данный EJB-компонент также может применяться для модульного тестирования клиентов Web-службы без необходимости ждать реализации WebSphere Business Integration Message Broker.

  • D. Существующие EJB-интерфейсы (например, система Assessor Management) импортируются в Rational Software Architect, и из EJB генерируются UML- и WSDL- интерфейсы. Данный метод объясняется в разделе "В: UML в WSDL".
    •

    6.2.3 Источники информации об интерфейсах в нашем сценарии

    WSDL-файлы и файл .xsd с определениями интерфейсов создаются либо из EJB-компонентов, которые должны использоваться для реализации некоторых служб, либо в ходе задачи по определению интерфейсов для процессов AutomatedAssessor и AssessorProxyService. Общим правилом является то, что владелец Web-службы должен при определении интерфейса службы сотрудничать с архитектором решения.

    В табл. 6.2 перечислены WSDL-файлы, которые вы можете найти в директории дополнительных материалов, прилагаемых к этому курсу (.\SG24-6636\). Имена включают в себя номер потока для упрощения перекрестных ссылок. Все WSDL-файлы находятся в директории .\SG24-6636\RSA\Project Interchange\wsdl.

    Сведения о файлах WSDL и .ear
    Поток Компонент (владелец интерфейса) Сведения об интерфейсе. Имя WSDL-файла. Источник, из которого он был сгенерирован
    1 Assessor Automation ExternalClaimAssessorsInterface.wsdl. Происходит из папки в proxy(1).wsdl. Proxy(1).wsdl был создан с помощью инструмента fdl2wsdl и описывается в лекции 11, "Изменение процесса Claim Investigation"
    2 Assessor Management AssessorManagement(2).wsdl .\SG24-6636\WAS\Flow2\Flow2_AssessorManagementSe rvice_SOURCE.ear
    2a Business Rules Engine RequestResponseTimePT(2a).wsdl .\SG24-6636\WAS\Flow2A\Flow2A_ResponseTimeRules_ SOURCE.ear
    3 Proxy Assessor System AssessorAvailability(3).wsdl .\SG24-6636\WBIMB\schemas\AssessorAvailability_3.xsd
    4 Assessor Availability(4).wsdl .\SG24-6636\WAS\Flow4and7\AssessorAvailabilityApplications_withSource.ear
    4a Proxy Assessor System AssessorAvailabilityPT(4a).wsdl .\SG24-6636\WBIMB\schemas\AssessorAvailabilityPT.xsd
    3a Assessor Automation AssessorAvailablityList(3a).wsdl
    5 Business Rules Engine PreferredAssessor(5).wsdl .\SG24-6636\WAS\Flow5\Flow5_AssessorRules_SOURC E.ear
    6 Proxy Assessor System AllocateAssessmentReport(6).wsdl .\SG24-6636\WBIMB\schemas\AllocateAssessmentReque st_6.xsd
    7 Assessor DeliverAssessment(7).wsdl .\SG24-6636\WAS\Flow4and7\AssessorApps.ear
    7a Proxy Assessor System DeliverAssessmentResponse(7a).wsdl .\SG24-6636\WBIMB\schemas\DeliverAssessmentRespon se_7a.xsd
    6a Assessor Automation AllocateAssessorResponse(6a).wsdl
    8 Proxy Assessor System AssessorReport(8).wsdl .\SG24-6636\WBIMB\AssessorReport_8.xsd
    9 Assessor Automation AssessorReport(9).wsdl
    10 Claim System StoreAssessmentReport(10).wsdl .\SG24-6636\WAS\Flow10\Flow10_DocumentHandler_SO URCE.ear

    6.2.4 Создание определений интерфейсов

    Вместо подробного рассмотрения создания интерфейсов и описания полей, мы приводим все интерфейсы в составе дополнительных материалов с указанием источника, который мы использовали для создания WSDL-интерфейса, если только он не создавался с нуля. Для формирования интерфейсов мы использовали одну из процедур, обозначенных буквами с А по D в предыдущем разделе.

    Все WSDL-описания интерфейсов и .ear-файлы можно импортировать в Rational Software Architect и просматривать при помощи редактора Web-служб. Эти файлы можно сохранить в проекте ITSOLGI Architecture.

    Многие из WSDL-файлов были сгенерированы из EJB-реализаций, указанных в табл. 6.2, с использованием подхода "снизу вверх". Этот подход весьма типичен для проектов корпоративной интеграции, где Web-службы употребляются в качестве оболочек существующих интерфейсов, в нашем случае – EJB-реализаций. Здесь мы демонстрируем оба подхода к включению интерфейсов из WSDL-описаний в UML-модель – "сверху вниз" и "снизу вверх".

    А: WSDL в UML

    Подход А начинается с WSDL-файлов. Эти файлы могут быть созданы в Rational Software Architect или формированы в выбранном вами инструменте и импортированы в Rational Software Architect.

    (рис 6.6) WSDL в UML

    Создание нового WSDL-файла в Rational Software Architect

    Чтобы создать новый WSDL-файл в Rational Software Architect, выполните следующие действия:

  • Выберите пункт меню File (Файл) > New (Новый) $$\to$$ Other (Другое) $$\to$$ WSDL $$\to$$ Next (Далее). Выберите проект и имя файла, например Assessor.wsdl. Нажмите Next (Далее). Выберите целевое пространство имен, чтобы обозначения WSDL-определений были уникальными. Мы использовали в качестве корневого имени http://itso.lgi.assessormgmt и добавили к нему в данном случае /Assessor. Затем мы добавляем префикс, например ama. Оставьте выбранной опцию Create WSDL skeleton (Создать каркас WSDL) и укажите опции (рис 6.7) Создание WSDL-файла: опции
  • Теперь вы можете отредактировать WSDL-файл, используя либо графический редактор, либо редактор страниц XML, либо простой текстовый редактор, щелкнув правой кнопкой мыши по файлу Assessor.wsdl и выбрав один из вариантов в пункте меню Open with (Открыть с помощью).Важно! В параметрах пространства имен или проекта добавьте параметр совместимости WS-I SSBP Require.

    • Альтернативным подходом является импортирование WSDL-файла.

    Прямое импортирование WSDL-файла и его отображение

    Чтобы импортировать WSDL-файл, выполните следующие шаги:

  • Переключитесь на перспективу Resources (Ресурсы), поскольку WSDL не интегрирован в UML и нет способа просматривать WSDL из перспективы UML modeling. Переключитесь на перспективу Resource (Ресурсы). В верхнем правом углу рабочего пространства нажмите на значок Perspectives (Перспективы) или выберите пункт меню Window (Окно) $$\to$$ Open Perspective (Открыть перспективу) $$\to$$ Other (Другая) $$\to$$ Resource (Ресурс).
  • Выберите в Model Explorer пункт ITSOLGI Architecture, щелкните правой кнопкой мыши, выберите пункт меню New (Новая) $$\to$$ Folder (Папка) $$\to$$ WSDL $$\to$$ Finish (Готово).
  • Перетащите WSDL-файлы из мест, показанных в табл. 6.2, в только что созданную папку WSDL.
  • Сделайте двойной щелчок по одному из WSDL-файлов, например PreferredAssessor(5). wsdl, чтобы WSDL отобразился в графической форме, или перейдите к исходному WSDL-файлу (см. рис 6.8 и рис 6.9).
    •  (рис 6.9) WSDL-определение PreferredAssessor (1)(рис 6.8) WSDL-определение PreferredAssessor (2)

    Генерация каркаса EJB для Web-службы

    Теперь мы сгенерируем EJB из определения Web-службы. Мы не будем использовать для ear-файлов существующий проект ITSOLGI Architecture, а создадим новый проект корпоративного приложения (Enterprise Application Project).

    Совет. У вас могут оказаться недоступными перспективы J2EE и Web service. В этом случае посмотрите в параметрах возможностей рабочего пространства опцию Web services and J2EE developer (Разработчик Web-служб и J2EE).
  • Создайте новый проект корпоративного приложения:
  • Выберите пункт меню File (Файл) $$\to$$ New (Новый) $$\to$$ Project (Проект) $$\to$$ J2EE $$\to$$ Enterprise Application Project $$\to$$ ITSOLGI Web services $$\to$$ J2EE Version 1.3 $$\to$$ Target Server (Целевой сервер) $$\to$$ WebSphere Application Server 5.1 $$\to$$ Next (Далее) $$\to$$ Finish (Готово). Ответьте Yes на вопрос Switch to the J2EE perspective (Переключиться на перспективу J2EE).Примечание. Мы ведем реализацию на платформе WebSphere 5.1. Чтобы эта опция была доступна в Rational Software Architect 6.0, у вас в Rational Software Architect должна быть установлена тестовая среда WebSphere 5.1 Test environment. Мы выбрали J2EE version 1.3, поскольку мы используем версию 5.1 тестовой среды. Версия J2EE 1.4 впервые появилась в тестовой среде WebSphere Application Server 6.0.
  • Может возникнуть ошибка, связанная с конфигурационным файлом applications.xml. Пока не обращайте на это внимания.
    •
  • Создайте новую Web-службу для интерфейса PreferredAssessor:
  • Выберите проект ITSOLGI Implementation, щелкните правой кнопкой мыши и выберите пункт меню New (Новый) > Other (Другое) > Web services (Web-службы) > Web service (Web-служба) > Skeleton EJB Web service (Каркас EJB для Web-службы). Отключите опцию Start Web service in a Web Project (Запускать Web-службу в Web-проекте), установите опции Overwrite files without warning (Перезапись файлов без предупреждения) и Create folders when necessary (Создавать папки по мере необходимости) и нажмите Next (Далее). Перейдите к импортированному WSDL-файлу PreferredAssessor(5).wsdl и нажмите Next (Далее).
  • Отредактируйте конфигурацию размещения службы, указав использование J2EE 1.3 и WebSphere Application Server test environment 5.1. Нажмите Next (Далее).
  • Оставьте параметры, заданные по умолчанию, без изменений и нажмите Finish (Готово).

    • Включение интерфейса в UML-модель

    Визуализируйте службу [мы ищем интерфейс PreferredAssessor, который в WSDL соответствует типу порта (PortType) PreferredAssessor].

  • Вернитесь к перспективе Modeling (Моделирование).
  • Откройте пакет itso.lgi.assessormgmt в java-проекте WebServiceProjectClient.
  • Щелкните правой кнопкой мыши по файлу PreferredAssessor.java, выберите пункт меню Visualize (Визуализация) $$\to$$ Explore in Browse diagram (Изучить в обзорной cхеме).
    •

    Мы должны увидеть картину, похожую на рис 6.10.

    (рис 6.10) Удаленный EJB-интерфейс Preferred Assessor

    В: UML в WSDL

    Подход ). Чтобы продемонстрировать работу данного подхода, мы используем простой пример службы, которая умножает два числа.

    (рис 6.11) UML в WSDL

    Создание UML-интерфейса

    Чтобы создать интерфейс, выполните следующие шаги:

  • Создайте UML-проект.

    В Rational Software Architect выберите пункт меню File (Файл) > New (Новый) > Other (Другое) > UML Project (UML-проект). Присвойте проекту имя Sums и нажмите Next (Далее). Оставьте выбранные по умолчанию параметры (Blank Model, пустая модель), но измените заданную по умолчанию схему на Class Diagram (Схема классов). Нажмите Next (Далее). Не выбирайте никаких проектов и нажмите Finish (Готово).

  • Создайте UML-интерфейс:
  • Перетащите с правой палитры элемент Interface (Интерфейс) на канву, нажмите на имя Interface1 и измените его на Sums.
  • Щелкните правой кнопкой мыши по элементу Sums и выберите пункт меню Add UML (Добавить UML) $$\to$$ Operation (Операция). Переименуйте операцию в Multiply.
  • Откройте интерфейс Sums в Model Explorer и щелкните правой кнопкой мыши по элементу Multiply(). Выберите пункт меню Add UML (Добавить UML) $$\to$$ Parameter (Параметр). Назовите параметр m1.
  • Повторите операцию, чтобы добавить параметр m2 и элемент Return result с именем result.
  • Укажите тип параметров и результата:
  • Выберите параметр в Model Explorer, откройте закладку Advanced (Дополнительно) в редакторе свойств и найдите свойство Type (Тип), которое будет пустым.
  • Щелкните мышью по второму столбцу свойства Type (Тип) и укажите тип Integer.
  • Повторите эту процедуру для параметров m2 и result.
    •  (рис 6.12) Интерфейс Sums

    Создание Java-интерфейса

    Создайте трансформацию UML в Java (рис 6.13), выполнив следующие шаги:

  • В главном меню выберите пункт Modeling (Моделирование) $$\to$$ Transform (Трансформация) $$\to$$ Configure Transformations (Конфигурация трансформаций). Выберите пункт UML to Java (UML в Java) $$\to$$ New (Новая). Назовите трансформацию SumsTransform.
  • Около поля Source: нажмите ... , выберите пункт Sums Interface (Интерфейс Sums). В области Target (Цель) диалогового окна выберите Create New Target Container (Создать новый целевой контейнер).
  • В диалоговом окне Java Project введите в поле Project name: SumsJava, нажмите Next (Далее), нажмите SumsJava на закладке Order and Export (Порядок и экспорт) и нажмите Finish (Готово).
  • На панели ).
  • Трансформацию можно запустить прямо из редактора конфигурации или из главного меню (рис 6.14).
    •  (рис 6.14) Конфигурация трансформации UML в EJB(рис 6.13) Запуск SumsTransform из главного меню

    При этом в заданном по умолчанию пакете проекта SumsJava создается файл Sums. java. Откройте схему по умолчанию проекта Sums и перетащите на нее файл Sums. java. Вы можете увидеть новый интерфейс Sums, стереотипированный к <<Java Interface>> (рис 6.15).

    (рис 6.15) Java-интерфейс Sums

    Создание соответствий WSDL

    Чтобы создать соответствие, выполните следующие шаги:

  • Создайте Web-проект:
  • Выберите пункт меню File (Файл) $$\to$$ New (Новый) $$\to$$ Project (Проект) $$\to$$ Dynamic Web Project (Динамический Web-проект). Назовите проект SumsWebProject, нажмите Next (Далее), снимите все опции, нажмите Next (Далее), затем Finish (Готово).
  • Щелкните правой кнопкой мыши по пункту JavaSource в проекте SumsWebProject, выберите пункт меню New (Новый) $$\to$$ Package (Пакет) и назовите пакет mathematics.
  • Щелкните мышью при нажатой клавише Ctrl по файлу Sums.java в папке SumsJava и перетащите его в папку JavaSource. Нажмите OK, чтобы элементы были перестроены.
    •
  • Создайте Web-службу Java:
  • Выберите файл Sums.java в пакете mathematics. Выберите пункт New (Новый) $$\to$$ Other (Другое) $$\to$$ Web service (Web-служба) $$\to$$ Next (Далее) $$\to$$ Java Bean Web service (Web-служба Java Bean) (примите остальные параметры как есть). Нажмите Next (Далее).
  • В поле Bean (Компонент) должен быть указан компонент mathematics.Sums (рис 6.16). Нажмите Next (Далее). Если это не так, нажмите Browse files (Обзор файлов) и выберите проект (рис 6.16) Java-интерфейс Sums
  • На следующей панели укажите проект службы SumsWebProject и EA-проект SumsWebProjectEAR. Нажмите Next (Далее). Оставьте без изменений опции интерфейса конечной точки и опции Web-службы (рис 6.17). Нажмите Next (Далее), затем (рис 6.17) Опции Web-службы
  • Просмотрите получившийся WSDL-файл, который можно найти через Project Explorer в перспективе Web. Выберите пункт Dynamic Web Projects (Динамические Web-проекты) $$\to$$ ).(рис 6.18) Web-служба Sums

    • Теперь, когда у нас есть WSDL-определение операции, мы можем сгенерировать EJB, используя процедуру А.

    D: EJB в UML и WSDL

    Для демонстрации мы импортируем один из .ear-файлов, приведенных в табл. 6.2, и генерируем WSDL-определение интерфейса.

  • Импортируйте файл .\SG24-6636\WAS\Flow2\Flow2_AssessorManagementService_SOURCE.ear в новый EAR-проект:
  • Выберите папку ITSOLGI Web services, щелкните правой кнопкой мыши по пункту Import (Импорт) и выберите пункт меню EAR file (EAR-файл), после чего нажмите Next (Далее).
  • Выберите файл Flow2_AssessorManagementService_SOURCE.ear, укажите сущес- твующий проект ITSOLGI Web services (созданный в примере А в разделе "Гене- рация каркаса EJB для Web-службы"), отключите опцию Import Project (Импортировать проект). Выберите опцию Overwrite existing resources without warning (Перезаписывать имеющиеся ресурсы без предупреждения), нажмите Next (Далее), затем снова Next (Далее), включите опцию Allow nested projects overwrites (Разрешать перезапись вложенных проектов).
  • Убедитесь, что выбраны оба файла AssessorManagementServiceEJB.jar и AssessorManagementServiceEJBRouter. jar. Нажмите Finish (Готово).
    •
  • Изучите в WSDL-файле службу AssessorManagement Service:
  • выберите в Model Explorer пункт Web services (Web-службы) $$\to$$ Services (Службы) $$\to$$ AssessorManagementService ;
  • откройте файл WSDL:AssessorManagementServiceEJB/ejbModule/METAINF/wsdl/AssessorManagement.wsdl (рис 6.19и рис 6.20).
    • (рис 6.20) AssessorManagement.wsdl – часть 1(рис 6.19) AssessorManagement.wsdl – часть 2
  • Чтобы использовать EJB-интерфейсы в UML, перетащите удаленный интерфейс EJB на любую UML-схему, с которой вы работаете. В следующем разделе иллюстрируется включение интерфейсов для ExternalClaimsAsessor, созданных по WSDL-определениям, в UML-схему компонентов и UML-схему последовательностей.

    • 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 описываются некоторые важные решения, которые архитектор принимает по поводу интерфейсов.

    Характеристики взаимодействий
    Поток Компонент (владелец интерфейса) Характеристики взаимодействия
    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

    6.3 Контракты архитектора

    Архитектор создает два продукта – PIM и PSM (см. рис 3.7).

    PIM

    В модели PIM (модель, независимая от платформы) архитектор решения должен совместно с бизнес-аналитиком рассмотреть перечисленные ниже материалы, чтобы удостовериться в том, что реализация будет функционировать в соответствии с моделью бизнес-процесса.

  • Общий обзор требований к решению, возможно с использованием шаблона RUP, например документа Vision. Обращайтесь к разделу 5.2, "Шаг 0. Сбор требований".
  • Компонентная архитектура (рис 5.8).
  • Соответствия рабочей системы (рис 5.22).
  • Функционирование решения, отображаемое на схеме потоков или на схеме последовательности (рис 6.1 или рис 6.3 и 6.4).
  • Модель данных, зафиксированную в форме потоков, которыми обмениваются компоненты. Это описывается в разделе messages в WSDL (см. напр. рис 6.9).
    •

    PSM

    В модели PSM (модель, специфическая для платформы) архитектор решения распределяет требования по инфраструктуре системы так, чтобы решение работало, и связывает решение с различными технологиями, чтобы ИТ-специалисты могли вести реализацию. Архитектор решения должен предоставить архитектору инфраструктуры и ИТ-специалистам следующие материалы по PSM (в дополнение к PIM):

  • связь с продуктами (рис 5.23 или рис 5.24);
  • связи WSDL, а также типы портов (PortType) и сообщения (рис 6.8). Заполнением определения службы занимается архитектор инфраструктуры;
  • соответствия рабочей системы (рис 5.22);
  • функционирование решения, отображаемое в виде схемы потоков или схемы последовательностей (рис 6.1 или рис 6.3 и 6.4).
    •

    Создание компонентов Java Beans (которым мы занимались в разделе "Генерация каркаса EJB для Web-службы") выходит за рамки абсолютно обязательной для архитектора работы над PSM. Это было бы полезно для связывания WSDL-определений интерфейсов и UML-модели, но данной цели можно достигнуть и при помощи комментариев к интерфейсам.

    Команда разработки должна решить, будет ли оправданной дополнительная работа архитектора по созданию каркаса EJB. Возможно, она будет оправданна для служб, которые будут создаваться в форме EJB, Java Beans или объектов C++, но будет бесполезной для служб, являющихся оболочками существующих компонентов или созданных с помощью других технологий, например в WebSphere Business Integration Message Broker. Навыки по правильному созданию компонентов больше относятся к компетенции ИТ-специалиста, который будет реализовывать компоненты, а не архитектора.

    6.4 Обеспечение доступа к материалам

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

    Откройте перспективу Resources (Ресурсы) в Rational Software Architect и выберите проект ITSOLGI Architecture $$\to$$ WSDL. Выделите все WSDL-файлы, щелкните правой кнопкой мыши и выберите пункт меню Export (Экспорт) $$\to$$ Zip file (zip-файл) $$\to$$ Next (Далее). Установите опции Compress (Сжатие) и Create directory structure for files (Создавать структуру директорий для файлов) и убедитесь в том, что отмечены все нужные файлы. Укажите имя создаваемого файла, например ClaimInvestigation WSDL files, и нажмите ).

    (рис 6.23) Экспортированные WSDL-файлы

    6.5 Заключение

    В этой лекции архитектор решения занимался детализацией архитектуры системы, созданной в лекции 5, "Архитектура системы", формируя тем самым функционирование системы. Архитектура решения описывается схемами последовательностей, схемами WSDL-интерфейсов и схемами компонентов.

    В WSDL-схемах обеспечивается высокий уровень детализации, от физических транспортных методов и адресов размещаемых компонентов до определения взаимодействий и схем сообщений, используемых при взаимодействиях. Конечно, на данной стадии не обязательно указывать все детали.

    Схемы компонентов имеют двоякое применение. Они связывают исходные определения интерфейсов с детализованными спецификациями интерфейсов, применяемыми в реализации, а также (для компонентов, реализуемых как Java Beans или классы С++) их можно использовать для построения и последующей генерации объектов, реализующих модель.

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

    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^