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

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 обладает рядом преимуществ:

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

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

1. Технология имеет как логический аспект, представленный типами портов (PortType) и сообщениями (Message), так и физический аспект, представленный службами (Services) и связями (Bindings), которые не соответствуют понятию интерфейса как раннего этапа превращения модели в реализацию. Простым решением будет избирательный подход к заполнению WSDL-определений на всех стадиях проектирования.
2. Данная технология не интегрирована в инструментарий UML до такой степени, чтобы, скажем, EJB могли интегрироваться в Rational Software Architect. Не существует простого способа вводить WSDL-определения в UML модель и исключать их из нее. Мы предлагаем четыре метода обмена WSDL и UML в зависимости от того, откуда архитектор решения получил определения интерфейсов. Обращайтесь к рис. 6.5.
3. Поскольку в различных инструментах отсутствуют средства импорта 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-интерфейсов:

1. Сверху вниз, с помощью редактора WSDL.
2. Снизу вверх, путем генерации WSDL из других реализаций и типов интерфейсов. Например, Rational Software Architect генерирует WSDL-файлы из EJB-компонентов.
3. От краев к центру, путем создания части интерфейсов в 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.