Создание SOA-приложений с повторно используемыми ресурсами: Часть 2. Типовой пример с использованием SOA-рецепта

Опции документа Опции документа, требующие включения JavaScript, не отображаются Обсудить Выскажите мнение об этой странице Помогите нам улучшить содержание

Уровень сложности: средний

Эоин Лэйн, главный инженер решений, IBM, Software Group
Клайв Джи, исполнительный консультант, IBM

01.07.2009

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

Введение

Первая статья данной серии "Повторно используемые ресурсы, рецепты и шаблоны" ввела понятие рецепта как руководящего инструмента, который дает методологию для создания SOA-приложений с использованием шаблонов и многоуровневой архитектуры. Этот рецепт был назван "Implementation and optimization of services" - рецепт для реализации и оптимизации SOA-сервисов. Во второй статье мы изучим этот рецепт более детально и исследуем другие повторно используемые ресурсы, на которые он ссылается. Следует заметить, что этот рецепт отнюдь не закончен, более того, мы используем его, чтобы показать, что можно с ним сделать.

В предыдущей статье мы установили клиент IBM® Rational® Software Architect для связи с RAS - репозиторием IBM Rational сайта developerWorks и импортировали рецепт для реализации и оптимизации SOA-сервисов. Данный рецепт использует для реализации и оптимизации сервисов SOA-шаблоны. Статья рассчитана в первую очередь на архитекторов и разработчиков, которых интересует методология управления в разработке SOA-приложений.

Мы применяем наш рецепт к типовому примеру, чтобы показать, как этот рецепт может быть использован. Пример предполагает использование среды разработки на основе моделей, например, Rational Software Architect. Используя Rational Unified Process, мы строим для нашего примера модель применения (use case), аналитическую модель, проектные модели и модели сервисов.

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

Рецепт "Implementation and optimization of services"

В предыдущей статье мы импортировали SOA-рецепт для реализации и оптимизации сервисов в Rational Software Architect. Данный рецепт касается того, как применять и использовать последовательность SOA-шаблонов. Выбор конкретных шаблонов может основываться на нефункциональных требованиях системы, таких как, например, масштабируемость реализации, функциональная совместимость и т.п. Эти нефункциональные требования задают правила применения. Данный рецепт ориентирован на архитекторов и разработчиков, которых интересуют методологии управления в разработке SOA-приложений.

У данного рецепта есть две большие задачи:

1. Выбор вариантов реализации
2. Применение шаблонов для реализации сервисов

В этой статье мы подробно рассмотрим вариант реализации. Это будет основой для будущей серии статей, где мы рассмотрим применение шаблонов для реализации сервисов.

Выбор вариантов реализации

Как следует из названия, наш рецепт работает с двумя типами сервисов:

1. Сервис "на новом месте": Обычно описание сервиса известно, возможно, из анализа бизнес-процессов. Рецепт также побуждает архитектора или разработчика к поиску предыдущих реализаций сервисов с подобными нефункциональными требованиями. Это позволяет сохранить архитектурную согласованность данной реализации с предыдущими успешными реализациями сервисов.
2. 2. Сервис на основе существующего приложения или сервиса. Обычно речь идет об унаследованном сервисе или приложении, которые с точки зрения разработчика или архитектора неизменяемы. Этот случай охватывает подавляющую часть унаследованных приложений или сервисов, которые необходимо объединить в рамках более широких SOA-реализаций. Теперь необходимо выполнить нефункциональные требования для сервиса, обычно включающие вопросы масштабируемости и производительности.

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

Рецепт использует основанный на моделях подход к разработке (model-driven development - MDD) и позволяет архитектору или разработчику моделей сфокусироваться на различных уровнях абстракции для создания лучшей архитектуры решения.

Характерная особенность этого рецепта - обращение к более богатым источникам информации, где только возможно, и поскольку мы разрабатываем SOA-приложения, используя основанный на моделях подход к разработке, первая задача рецепта – связать Rational Unified Process с SOA. Rational Unified Process управляет процессом разработки программного обеспечения на основании лучшего опыта многочисленных разработок.

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

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

В обоих случаях везде, где это возможно, анализируются модель сервиса и модели сущностей. В среде разработки, основанной на моделях, например, Rational Software Architect, это модели Rational Software Architect, которые устанавливаются вместе с системой и следуют процессу RUP в их понимании пользовательской работы. Рецепт предполагает использование многоуровневой архитектуры, как на рисунке 2, где на соответствующих уровнях могут применяться стандартные SOA IF-шаблоны.

SOA-шаблоны

Перед тем как дать обзор SOA-шаблонов, полезно рассмотреть многоуровневую архитектуру, на которой мы ниже и остановимся. Простая трехуровневая архитектура содержит уровень представления, бизнес-уровень и уровень персистентности. В среде SOA мы можем далее разбить бизнес-уровень на сервис-уровень, уровень контроллера и уровень управления сущностями/объектами. Такое разбиение показано на рисунке 2. Внутренние шаблоны ядра Enterprise JavaBean™, такие как фасад сеанса, фасад сообщения и бизнес-делегат, принадлежат к уровню контроллера.

SOA-шаблоны, используемые в нашем рецепте, относятся к бизнес-уровню. Все эти шаблоны взяты из стратегических проектов IBM в области SOA. Каждый из них был разработан как спецификация и реализация шаблона с помощью Rational Software Architect. Более подробную информацию см. в разделе Ресурсы.

Если говорить о шаблонах - возьмем для примера книгу "банды четырех" (Влиссидес, Гамма, Хелм и Джонсон) "Design Patterns" - есть два самостоятельных интересных аспекта. Первый – это текст, который описывает шаблон. Это то, что вы могли бы найти в книге, скажем, в главе о шаблоне адаптера.

Второй аспект – это компоненты средств разработки, которые реализуют этот шаблон. К примеру, в Rational Software Architect есть UML-компоненты, которые реализуют разнообразные программные шаблоны разработки из книги "Design Patterns". Поэтому, если вы хотите применить адаптер к одной из ваших разработок, вы можете взять этот компонент из палитры и адаптировать его в среде разработки, чтобы его можно было использовать в вашем решении.

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

Мы рассмотрим четыре шаблона, которые будут детально исследованы в следующих статьях данной серии:

• WS Response Template Pattern (шаблон схемы ответа в Web-сервисах) обеспечивает мелкоструктурный доступ к сервису с грубой структурой, а также обеспечивает гибкость в определении сервиса (спецификацию шаблона см. в разделе Ресурсы).
• Requester Side Caching Pattern (шаблон кэширования на стороне запроса) обеспечивает возможности кэширования на стороне запроса (спецификацию шаблона см. в разделе Ресурсы).
• Preferred Data Source Pattern (шаблон приоритетного источника данных) – шаблоны управления микропотоками для объединения сервисов.
• Aspects Patterns (шаблоны аспектов) совмещают аспекты AJDT и разработки, основанной на моделях (MDD).

Такой способ разработки бизнес-уровня имеет множество преимуществ:

1. Отделение самого понятия сервиса от бизнес-логики (уровень контроллера) и доступа к данным (сущностям) гарантирует, что в сущностях не будет проявлений бизнес-логики.
2. В реализации Web-сервиса сервисы могут делегировать контроллеру полномочия для надлежащего разделения ролей. Сервис только перехватывает сообщения, поручая Контроллеру следить за тем, что процесс закончился.
3. Контроллер реализует бизнес-логику сервиса, обращаясь к другим сервисам или к сущностям внутренних информационных систем через их средства создания, чтения, обновления и удаления (CRUD).
4. Теперь для каждого уровня можно применять соответствующие шаблоны, чтобы удовлетворить нефункциональные и системные требования и создать архитектурно согласованные приложения и сервисы.

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

В начало

Типовой пример для SOA

Чтобы показать назначение данного примера, мы интегрировали его в рецепт для реализации и оптимизации сервисов. В этом разделе мы исследуем рецепт, чтобы получить доступ к ресурсам, с помощью которых создавался типовой пример. Для этого нам в первую очередь необходимо загрузить проект в Rational Software Architect, который поддерживает эти ресурсы. В большинстве случаев эти ресурсы будут являться моделью применения, аналитическими и проектными моделями и моделями сервисов. Чтобы создать простой проект в Rational Software Architect, выберите: File > Project > Simple > project call the project "Retail".

Данный пример демонстрирует, как SOA-шаблоны работают совместно друг с другом в качестве составных частей и как они могут взаимодействовать с другими шаблонами. Наш пример в некоторой степени основан на модели розничной сети и фокусируется на бизнес-сервисе, который называется "Lookup Item" (Поиск элемента). В основном Lookup Item мы будем использовать в сценарии розничной торговли, где поиск ведется в системе учета товаров до того, как они будут проданы. "Lookup item" – типовой пример составного бизнес-сервиса, в котором мы хотим понять, какие ИТ-сервисы обеспечивают работу бизнес-сервиса.

Декомпозиция бизнес-процесса помогает лучше понять сложный процесс, обеспечивающий работу этого бизнес-сервиса. На рисунке 4 показана вся сложность бизнес-процесса. Здесь используются два других сервиса: сервисы каталога и учета товаров.

• Сервис каталога ищет шифр или складской номер (SKU) нужного нам товара.
• Сервис учета товаров по номеру (SKU) проверяет, есть ли этот товар в системе учета. Сначала поиск ведется в локальной базе. Если там его нет, то поиск осуществляется по всей сети. Процесс можно продолжать поиском на внешнем сервере и т.д. Мы можем видеть это более подробно на рисунке 4.

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

Модели применения

Данная модель применения хранится как ресурс спецификации повторно используемых ресурсов (Reusable Asset Specification - RAS) в RAS-репозитории dW и может быть использована из рецепта. На рисунке 5 показано, как получить доступ к модели применения и импортировать ее из рецепта. Импортируйте модель применения в ранее созданный проект Retail project.

Модель применения помогает архитектору или разработчику понять, какие программные артефакты и сервисы необходимо создать. Модель применения, показанная на рисунке 6, очень похожа на модель бизнес-процессов на рисунке 3. В данном случае мы видим соответствие между бизнес-сервисом и ИТ-сервисом, но так бывает не всегда. Модель применения показывает поиск с точки зрения ИТ-сервисов.

В начало

Идентификация сервисов

В данном случае у нас взаимно однозначное соответствие между бизнес-сервисами и ИТ-сервисом. Но так бывает не всегда. Существует распространенное и опасное неверное предположение, что ИТ-сервисы и бизнес-сервисы – это одно и то же. Два показанных ИТ-сервиса интересны с точки зрения типовой архитектуры SOA-шаблона:

1. Сервис каталога ищет номер товара в разделах каталога
2. Сервис учета определяет количество выбранного товара на складе по системе учета.

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

К сервис-модели ведут два пути. Не обязательно выбирать либо первый, либо второй путь, просто иногда один из путей будет предпочтительнее. Давайте взглянем на них более подробно:

1. Нисходящий подход: при таком подходе, например, как в IBM Service Oriented Modeling Approach (SOMA), сервисы определяются и располагаются по приоритетам при помощи бизнес-анализа. Элементы сервисов определяются из моделей бизнес-процессов. Примером набора специфичных для конкретной отрасли моделей (таких как модели бизнес-процессов, модели бизнес-объектов) для сферы страхования является IBM Insurance Application Architecture (см. врезку на странице.) Подробная структура сервисов определяется из моделей бизнес-процессов. WSDL, описывающий ИТ-сервисы, генерируется из модели бизнес-процессов, которая создается, например, в WebSphere® Business Integration Modeler.
2. Восходящий подход: при таком подходе сервисы определяются с использованием сведений о существующих пакетах приложений и их интерфейсов и идеологии хореографии процессов для создания композитных сервисов. Для таких сервисов WSDL часто генерируется из моделей классов.

Сервис каталога

Модель сервиса учета, которая содержит как сервис каталога, так и сервис поиска по базе компонентов, хранится как RAS-ресурс в RAS-репозитории dW и может быть использована из рецепта. Выберите расположение рецепта, как показано ниже, и импортируйте Ref Example Asset (SOA-модель сервиса учета) в ранее созданный Rational Software Architect Project Retail. Сервис каталога должен быть вызван из рецепта, как показано ниже:

Сервис каталога ищет номер товара в разделах каталога; в списке хранится либо названия товаров, либо номера SKU. В разработке, основанной на моделях, сервисы – это UML-модели, модели класса, для которых применяется UML 2.0 Profile for Software Services. UML 2.0 Profile for Software Services предоставляет общепринятый язык описания моделей сервисов.

UML 2.0 Profile for Software Services предоставляет общепринятый язык описания сервисов, достаточный для большого числа действий в разработке жизненного цикла модели и предоставляющий обзор для различных заинтересованных сторон. UML-профиль для программных сервисов - это профиль для UML 2.0, в котором можно моделировать сервисы, SOA и сервис-ориентированные решения. Профиль был реализован в среде IBM Rational Software Architect и успешно протестирован при разработке моделей в сложных сценариях заказчиков. В данный момент он используется в образовательных целях для обучения новым понятиям, касающимся разработки сервис-ориентированных решений (см. Ресурсы).

IBM Insurance Application Architecture Пакет IBM Insurance Application Architecture – это всеобъемлющий набор моделей информации, процессов и интеграции, которые воплощают передовой опыт разработки в индустрии страхования. Этот план информационной архитектуры содержит детализированную информацию по бизнесу страхования, которая может быть применена в масштабах всего предприятия или в узкоспециализированных проектах. Он позволяет страховым компаниям создавать детализированные спецификации и общие для многих предприятий архитектуры информационных систем. Эти модели основаны на более чем 300-летнем суммарном опыте разработки, учитывающем отклики ведущих финансовых организаций (см. Ресурсы).

Теперь у нас есть модель подробного представления того, как физически реализуется сервис. Используя такую модель, можно применить шаблоны приложений и архитектуры для удовлетворения соответствующих нефункциональных требований к реализации, масштабируемости и т.д. В примере сервиса каталога используются такие шаблоны, как WS Response Template (см. Ресурсы) и шаблоны безопасности. Из модели сервиса каталога можно применить преобразования из UML в WSDL и из UML в XSD для создания WSDL- и XSD-представлений сервиса, обеспечив, таким образом два разных и дополнительных способа визуализировать сервис на разных уровнях абстракции. Эти преобразования не включены в данную статью, но они будут рассмотрены в следующей, в которой речь пойдет о шаблоне WS Response Template.

• UML-модель сервиса каталога: сервис каталога (см. ниже)
• Спецификация сервиса каталога (WSDL): сервис каталога WSDL

Модель сервиса каталога

На рисунке 8 показана модель сервиса каталога. Модель выполняет две операции:

• Операция getCatalog() принимает первичный ключ и возвращает значение Catalog
• Операция getCatalogs() принимает массив первичных ключей и возвращает массив значений Catalogs

Модель данных каталога

На рисунке 9 показана модель сообщений каталога (catalog message model). Из данной модели следует:

• Каждое сообщение Catalog содержит несколько сообщений CatalogItem
• Каждое сообщение CatalogItem содержит несколько сообщений FeatureValue
• Каждое сообщение FeatureValue содержит одно сообщение Feature

Сервис учета

Сервис учета выполняет две операции. Сначала он выдает запрос, который определяет, имеется ли на складе столько единиц товара, сколько указано в заказе. В розничной торговле количество единиц товара на складе называется наличным количеством (QoH). Вторая операция фиксирует изменения в складских запасах при продаже товара или поступлении нового товара (движение товаров). Этот сервис также можно рассмотреть с на двух уровнях абстракции, подобно описанному выше сервису каталога.

• UML-модель сервиса учета: сервис учета
• Спецификация сервиса учета (WSDL)

Модель сервиса учета

На рисунке 10 показана модель сервиса учета. Следуя описанию этого сервиса выше, модель выполняет две операции:

• Операция getQoH() принимает значение QoHRequest и возвращает значение QoHResponse
• Операция inventoryMovement() принимает значение Integer и возвращает значение Boolean

Модель данных для учета

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

В начало

Идентификация унаследованных приложений

Модель разработки каталога с использованием унаследованных приложений

Модель разработки приложения каталога на базе унаследованных приложений нашего типового примера можно вызвать из рецепта SOA implementation and optimization of service аналогично тому, как были импортированы в Rational Software Architect модель сервиса учета и SOA-модель применения.

На рисунке 13 изображена диаграмма UML-класса приложения каталога на базе унаследованных приложений. Это приложение является Java-компонентом и реализует Java-интерфейс. Операции getCatalog() и getCatalogs() являются весьма крупноблочными, поскольку они возвращают целый каталог и список каталогов соответственно.

В начало

Заключение

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

Сервисы можно определять как через нисходящий подход бизнес-анализа, когда решение конструируется "на новом месте", так и через восходящий подход, когда SOA используется для преобразования унаследованной системы.

Чтобы проиллюстрировать, как можно применять шаблоны для создания сервиса, мы используем типовой пример сервиса, который может быть загружен как RAS-ресурс: этот типовой пример связан с рецептом "SOA implementation and optimization of services" и является пошаговым руководством по применению рецепта.

В следующей статье данной серии мы расскажем, как применить шаблон WS Response Template к модели сервиса каталога, чтобы создать более гибкий и удобный для клиента интерфейс (см. Ресурсы).

Ресурсы

• Оригинал статьи "Building SOA applications with reusable assets, Part 2: SOA recipe reference example" (EN).
  
  
• Стандарт OMG Reusable Asset Specification, версия 2.2.(EN)
  
  
• Прочтите "Справочник по структурированию моделей для Rational Software Modeler и Rational Software Architect" (developerWorks, март 2006 г.) (EN), в котором приведена более подробная информация по моделированию в Rational Software Architect и Rational Software Modeler.
  
  
• Статья "Шаблон Web services response template : спецификация" (developerWorks, февраль 2006 г.) (EN) рассматривает спецификацию шаблона WSRT и решения, которые она предлагает для улучшения интерфейсов сервисов.
  
  
• Статья "Спецификация шаблона Requester side caching: обзор" (developerWorks, октябрь 2005 г.) (EN) очень подробно рассматривает спецификацию шаблона requester side caching.
  
  
• Статья "Профиль для моделирования сервиса" (developerWorks, апрель 2005 г.) (EN) описывает UML-профиль для программных сервисов, профиль для UML 2.0, который позволяет моделировать сервисы, SOA и сервис-ориентированные решения.
  
  
• Статья "Разработка J2EE-архитектуры с помощью Rational Software Architect, используя Rational Unified Process" (devdeloperWorks, август 2005 г.) (EN) показывает, как можно использовать IBM Rational Software Architect для определения архитектуры программного обеспечения.
  
  
• Узнайте больше об архитектуре приложений IBM Insurance.(EN)
  
  
• Загрузите электронную версию постера IBM Insurance Application Architecture.(EN)
  
  
• Посетите раздел developerWorks SOA и Web-сервисов для более углубленного изучения и развития своих навыков.
  
  
• Узнайте о группе IBM Enterprise Integration Solutions, которая предлагает техническое руководство и сопровождение при разработке SOA и улучшенных Web-сервисов.(EN)
  
  
• Узнайте больше об архитектуре приложений IBM Insurance.(EN)
  
  
• Следите за техническими событиями и Web-трансляциями developerWorks.

• Загрузите пробную версию Rational RequisitePro Rational RequisitePro V2003.06.15.(EN)
  
  
• Попробуйте в действии RUP для SOA Plug-In V1.0.(EN)
  
  
• Загрузите ознакомительную версию Rational Software Architect Rational Software Architect V6.0.(EN)
  
  
• Используйте в своем следующем проекте пробное программное обеспечение IBM, которое можно загрузить с сайта developerWorks. (EN)
  
  
• IBM Alphawork предоставляет рекомендованную реализацию RAS - Reusable Asset Specification Repository for Workgroups. Ее можно загрузить на сайте alphaWorks. (EN)
  
  
• Узнайте больше о репозитории повторно используемых ресурсах (RAS).(EN)
  
  
• Испытайте на практике средства разработки приложений и связующее ПО от DB2®, Lotus®, Rational®, Tivoli® и WebSphere®. Вы можете бесплатно загрузить ознакомительные версии продуктов или заказать версию Software Evaluation Kit для Linux® или Windows®.(EN)
  
  

• Примите участие в обсуждении материала на форуме.
  
  
• Примите участие в блогах developerWorks и подключайтесь к сообществу developerWorks.(EN)
  
  

Об авторах

		Доктор Эоин Лэйн (Eoin Lane), главный инженер решений, руководит выборкой (и разработкой) шаблонов приложений из ключевых SOA-проектов IBM, а также прохождением этих шаблонов через процесс управления шаблонами IBM для ускорения их принятия. Также, для содействия SOA-разработке Эоин специализируется в Model Driven Development (MDD) (основанной на ресурсах разработке) и Reusable Asset Specification (RAS).

		Клайв Джи (Clive Gee) - исполнительный консультант с почти 30-летним опытом работы в ИТ-индустрии. В течение последних трех лет он работает с SOA, занимаясь разработкой сервисов и вопросами управления.

Выскажите мнение об этой странице

Пожалуйста, найдите минутку и заполните форму, чтобы повысить уровень сервиса. Помогла ли данная информация достичь Вашей цели? Да Нет Не знаю   Пожалуйста, напишите комментарий, чтобы мы могли улучшить данную страницу:   Насколько полезна эта информация? (1 = Бесполезна, 5 = Очень полезна) 1 2 3 4 5

Поделиться этой статьей: забобрить сохранить в memori

В начало