Создание SOA-приложений с применением повторно используемых активов: Часть 5. Шаблон preferred data source

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

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

Эоин Лэйн, главный инженер решений, IBM
Джим Коналлен, старший инженер-программист, IBM

17.08.2009

В данной серии статей исследуются такие повторно используемые активы, как рецепты, шаблоны программирования и модели. Рассматриваются методы ускорения разработки SOA-решений. В данной, пятой, части серии исследуется шаблон preferred data source (шаблон предпочтительного источника данных), обеспечивающий соблюдение нефункциональных требований к согласованности при реализации повторно используемых сервисов. Шаблон preferred data source представляет собой microflow-шаблон (шаблон микропотока) для агрегирования сервисов. Он был создан из реального SOA-решения и использован в нескольких других SOA-приложениях. В данной статье также демонстрируется, как можно использовать реализацию Rational® Software Architect этого шаблона в среде управляемой моделями разработки для создания реализации нового сервиса.

Введение

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

В третьей части данной серии статей было рассказано, как оформить действующее приложение, используя метод "сверху вниз". Был приведен базовый пример, соответствующий рецепту SOA-реализации и оптимизации сервиса, который детализирует, как повторно используемая модель сервиса каталога идентифицируется и специфицируется путем декомпозиции домена бизнес-процесса поиск товара. Затем к модели сервиса каталога был применен шаблон WS response template (шаблон WS-ответа) для формирования более гибкой модели сервиса, предоставляющей запрашивающей стороне мелкоструктурированный доступ к крупноструктурированному интерфейсу. Этот шаблон был использован по причине его соответствия нефункциональным требованиям гибкости и возможности взаимодействия для данной реализации сервиса. Затем с помощью контроллера (применяемого при реализации бизнес-логики сервиса) реализации сервиса каталога было осуществлено подключение к действующему приложению каталога. Это классический пример действующего приложения, обеспечивающий базовую функциональность, необходимую для предоставления сервиса. Однако теперь данное приложение нужно оформить в виде сервиса, и оно должно соответствовать набору нефункциональных требований, отличного от имевшегося при создании оригинального приложения.

Четвертая часть данной серии статей была посвящена реализации других нефункциональных требований для созданного нового сервиса каталога. Данные нефункциональные требования были связаны с производительностью, масштабируемостью и трассируемостью. В SOA-среде, где во время создания сервиса количество его пользователей часто неизвестно, нефункциональные требования производительности и масштабируемости, к счастью, общеизвестны, поэтому их легко найти. Хорошо известным шаблоном, предназначенным для повышения производительности нефункциональных требований, является шаблон requester side caching (кэширование на запрашивающей стороне), представленный в четвертой части серии статей.

В пятой части рассматривается один шаблон, демонстрирующий способ объединения набора отдельных сервисов в единый сервис, называющийся шаблоном preferred data source (шаблон предпочтительного источника данных). Этот шаблон является шаблоном микропотока для агрегирования сервисов. Он был получен из реального SOA-решения IBM и затем использован в нескольких других SOA-приложениях и решениях. Контекст отображения шаблонов на нефункциональные требования и нефункциональных требований на архитектурные решения позволяет SOA-разработчику создавать архитектурно согласованный код, соответствующий передовым методикам и принципам разработки программного обеспечения.

Продолжение истории

В предыдущих статьях данной серии мы настроили RAS-клиент (reusable asset specification - спецификация повторно используемых активов) в IBM Rational Software Architect. При помощи этого клиента мы обратились к повторно используемому активу, называемому рецептом SOA-реализации и оптимизации сервисов. В демонстрационных целях в этот рецепт был интегрирован базовый пример (подробно описанный во второй части ). Для использования данного рецепта необходимо настроить проект в Rational Software Architect, содержащий все остальные повторно используемые активы, на которые ссылается рецепт. Обычно такими повторно используемыми активами являются модели вариантов использования, сервисов, анализа и дизайна. Для создания простого проекта в Rational Software Architect выберите File > Project > Simple > Retail.

Этот базовый пример демонстрирует, как SOA-шаблоны работают совместно и как они могут взаимодействовать с другими шаблонами. Он слабо связан с цепочкой продаж и предназначен для конкретного бизнес-сервиса под названием Lookup Item (поиск товара). Возможное применение Lookup Item - сценарий продаж, в котором товар сначала ищется в складской системе, а затем продается. Сервис Lookup Item является примером крупномодульного бизнес-сервиса. В данной статье рассматриваются также соответствующие IT-сервисы, необходимые для обслуживания этого бизнес-сервиса.

Для лучшего понимания сложных процессов, используемых для обслуживания данного бизнес-сервиса, используется декомпозиция бизнес-процессов. На рисунке 2 показана сложность этого бизнес-процесса. В частности, обратите внимание на использование двух других сервисов: catalog (каталог) и inventory (склад):

• С помощью сервиса catalog проводится поиск конкретного номера или единицы учета для конкретного товара.
  
  
• Сервис inventory по этой единице учета определяет наличие товара на складе. Сначала он просматривает локальные запасы. Если товар отсутствует, поиск осуществляется на складе товаров. Процесс можно продолжить поиском товара у сторонних поставщиков. Более детально процесс показан на рисунке 4.

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

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

• Шаблон ответа Web-сервиса (шаблон Web services response template) для обеспечения возможности взаимодействия с сервисом и для его гибкости.
  
  
• Шаблон requester side caching для повышения производительности сервиса.
  
  
• Шаблон аспектов для трассируемости сервиса.

В случае с сервисом catalog существовало старое приложение catalog, которое мы оформили в виде сервиса. В случае с сервисом inventory такого приложения не существовало, что потребовало от нас создания нового сервиса.

В начало

Создание нового сервиса

В эталонном примере рассматривается организация, управляющая несколькими распределенными складами товаров, каждый из которых представлен в виде отельного Web-сервиса. После анализа вариантов использования было определено одно из функциональных требований, предписывающее наличие у сервиса inventory унифицированного представления для нескольких распределенных источников данных. По существу, разные склады должны отображаться клиенту как единый склад. Кроме объединения сервисов имеется также требование реализации порядка предпочтений, согласно которому определенные склады должны проверяться первыми. Остальные склады проверяются только после неудачной проверки первых. Объединенный сервис inventory должен быть основан на нескольких источниках данных. При проектировании сервиса inventory доступны следующие повторно используемые активы:

• Модель, представляющая сервис inventory и связанные с ним представления данных: модель дизайна сервиса, объединенная в пакет RAS-актива, может импортироваться в проект UML-модели.
  
  
• Нефункциональные требования для варианта использования inventory: файл управления требованиями RequisitePro® тоже мог бы быть доступен в виде RAS-актива, но чаще всего к нему должен быть обеспечен совместный доступ по сети.

Изучите действия по созданию нового сервиса, выделенные в рецепте (рисунок 3). Подробная информация по получению данного рецепта приведена в первой части .

Сервис inventory

Сервис inventory предоставляет две операции. Первой является запрос на определение наличия достаточного количества единиц учета определенного товара, необходимого для выполнения заказа. В сфере розничных продаж количество доступных на складе единиц учета называется QoH (quantity on hand - количество, имеющееся в наличии). Второй операцией является запись изменения в складской системе по причине продажи товара или получения новых товарных запасов. Такая операция называется движением товаров. Этот сервис можно визуализировать на двух различных уровнях абстракции, аналогично рассмотренному выше сервису catalog:

• UML-модель сервиса inventory: Inventory Service.
• Спецификация (WSDL) сервиса inventory.

Более подробно данная тема рассматривается в следующем разделе.

Модель сервиса inventory

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

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

Модель данных inventory

Модель данных inventory (рисунок 5) позволяет указать в запросе месторасположение исходного хранилища. Например, склад или региональное хранилище.

Следующим действием по созданию нового сервиса должен быть анализ нефункциональных требований к нему (рисунок 6).

Анализ нефункциональных требований

Нефункциональные требования к сервису inventory отслеживаются при помощи Rational RequisitePro. На рисунке 7 показан клиент RequisitePro внутри Rational Software Architect, который позволяет проектировщику поддерживать и контролировать удобство манипулирования вариантами использования, функциональными и нефункциональными требованиями. Ниже приведено резюме по высокоуровневым нефункциональным требованиям для сервиса inventory:

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

Следующим шагом по созданию нового сервиса является исследование существующей аналитической модели старого приложения (рисунок 8). Обычно на этом этапе детализируется использование существующего приложения.

Анализ существующей модели catalog

Локальный и удаленный сервис inventory имеют один и тот же интерфейс. В упрощенном примере имеется единственный метод сервиса: getQoH(). Этот метод принимает объект запроса, содержащий информацию о товаре, который может находиться на складах. Возвращаемый объект указывает имеющееся количество и идентификатор месторасположения. На UML-диаграмме (рисунок 9) показан интерфейс сервиса, реализующий его компонент и сообщения, передаваемые в метод main.

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

В начало

Применение соответствующих шаблонов

В третьей части данной серии статей рассказывалось, как применить шаблон WS response template для моделирования сервиса с целью сделать его более гибким. В данной части рассматриваются шаблоны requester side caching и aspect logging.

Суть SOA - в быстроте адаптации бизнеса к новым условиям. Одним из способов достижения этого является идентификация бизнес-компонентов, являющихся основой бизнес-деятельности. После этого могут быть идентифицированы и определены бизнес-процессы и сервисы, ассоциированные с этими бизнес-компонентами. Декомпозиция таких бизнес-процессов и сервисов помогает выявить повторно используемые ИТ-сервисы, необходимые для их обслуживания. С точки зрения информационных технологий эти сервисы можно моделировать в виде вариантов использования, а их функциональные и нефункциональные требования можно отслеживать при помощи такой инструментальной программы как, Rational RequisitePro. Как можно управлять столь сложной средой с постоянно меняющимися частями? В частности, как спроектировать все эти сервисы, чтобы гарантировать удовлетворение нефункциональных требований к ним?

На помощь приходят шаблоны (patterns). Шаблоны представляют собой воспроизводимое решение проблемы в определенном контексте. Они обычно описываются спецификацией шаблона. Спецификации шаблона содержат раздел forces, в котором описывается, когда нужно использовать шаблон. Применимость для решения в конечном итоге определяется нефункциональными требованиями, такими как масштабируемость, производительность, защищенность, транзакционность, обслуживаемость и способность к взаимодействию. Отображая эти нефункциональные требования в разделе forces спецификации шаблона, можно добиться трассируемости и возможности идентификации в сфере архитектурных решений.

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

• Спецификация шаблона WS response template обеспечивает гибкость интерфейса сервиса, способность к взаимодействию и удобство обслуживания. Ссылка на спецификацию шаблона WS response template приведена в разделе "Ресурсы".
  
  
• Спецификация шаблона requester side caching повышает производительность сервиса. Ссылка на спецификацию шаблона requester side caching приведена в разделе "Ресурсы".
  
  
• Шаблон preferred data source - это шаблон микропотока для объединения сервисов.
  
  
• Шаблон logging (регистрации) обеспечивает трассируемость вызова сервиса. Ссылки на более подробную информацию об управляемой моделями разработке приведены в разделе "Ресурсы".

Перед детальным изучением данных шаблонов полезно рассмотреть n-уровневую архитектуру, представленную ниже. Трехуровневая архитектура имеет уровень представления, бизнес-уровень и уровень персистенции. В SOA-среде при работе с реализациями повторно используемых ИТ-сервисов бизнес-уровень, в свою очередь, можно разделить на уровень сервисов, уровень контроллера и уровень управления объектами. Такое разделение на уровни показано на рисунке 1. На этом рисунке изображено распределение по уровням в контексте контейнера сервера приложений.

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

На уровне сервисов может быть применен шаблон WS response template, описанный в третьей части данной серии статей (на этом уровне можно также применить и другие шаблоны, такие как WS security, который непосредственно влияет на определение сервиса). Шаблон requester side caching, описанный в четвертой части , применяется на уровне контроллера. Шаблон aspect logging (регистрация аспектов), описанный в четвертой части , тоже применяется на уровне контроллера. Базовые шаблоны Enterprise JavaBeans, session facade (фасад сессии), message facade (фасад сообщения) и business delegate (бизнес-делегат), принадлежат уровню контроллера, тогда как базовые корпоративные JavaBeans-шаблоны управления данными логического объекта и объекта доступа к данным принадлежат уровню логических объектов. На рисунке 10 показана n-уровневая архитектура реализации сервиса и место применения перечисленных шаблонов.

В начало

Отображение шаблонов на нефункциональные требования и создание сервиса inventory

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

Для создания сервиса catalog используются три шаблона:

• Унификация/согласованность: шаблон preferred data source (PDS).
  
  
• Производительность: шаблон requestor side cache.
  
  
• Масштабируемость: EJB-архитектура использует широко известные EJB-шаблоны для создания масштабируемой реализации.
  
  
• Трассируемость: Основанный на AspectJ шаблон aspect logging для регистрации всех вызовов сервиса.

Структура объединенных сервисов inventory показана на рисунке 11. Можно заметить, что шаблон preferred data source используется для объединения микропотока. Для повышения производительности объединенного поиска мог бы использоваться шаблон requester side caching. Оба этих шаблона применяются на уровне контроллера.

На рисунке 12 показана компоновка локального сервиса inventory. Для повышения производительности снова можно использовать шаблон requester side caching на уровне контроллера. Также на уровне контроллера тоже можно было бы использовать EJB-шаблоны business delegate и session facade. Наконец, на уровне управления объектами можно применить шаблон data access object (DAO).

Как можно заметить, шаблоны и нефункциональные требования хорошо сбалансированы, особенно при разработке информационных сервисов. Необходимо учитывать нефункциональные требования как для данных, так и для сервиса. При рассмотрении шаблонов, используемых для компоновки информационных сервисов, очень важно учитывать шаблоны данных. Недавно опубликованы две спецификации шаблонов данных для создания информационных SOA-сервисов:

• Шаблон data federation (федерирование данных) виртуализирует данные из нескольких источников информации. Шаблон создает интегрированное представление распределенной информации без избыточности данных и объединяет как структурированную, так и не структурированную информацию. Эта спецификация шаблона помогает разработчикам данных и приложений принимать обоснованные решения по архитектуре данных и документировать рекомендации.
  
  
• Спецификация шаблона data consolidation (консолидация данных) помогает разработчикам данных и приложений принимать обоснованные архитектурные решения и улучшать рекомендации. В данной статье вы узнаете, как применить этот шаблон в контексте SOA. Главным движущим механизмом для шаблона consolidation pattern (называемого также шаблоном data population (заполнение данных)) является сбор и согласование данных из нескольких источников до того, как эта информация потребуется. Для этого шаблон извлекает данные из одного или нескольких источников, преобразовывает их в необходимый целевой формат и загружает в целевой персистентный объект данных. Предварительное заполнение персистентного целевого объекта является ключевым отличием этого шаблона от шаблона federation pattern.

Шаблон preferred data source подробно описан в боковой врезке на странице.

Отображение шаблонов на нефункциональные требования При рассмотрении шаблонов (например, шаблонов проектирования из книги "банды четырех" (Э.Гамма и др., «Шаблоны проектирования») интерес представляют две вещи. Одна из них - реальный текст, описывающий шаблон. Это то, что вы найдете в книге, например, в главе о шаблоне адаптера. Вторая - элементы инструментария проектирования, реализующие данный шаблон. Например, в Rational Software Architect имеются UML-артефакты, реализующие различные шаблоны проектирования из книги "банды четырех". То есть, если вы хотите применить адаптер в одном из ваших проектов, уберите этот элемент из палитры и выполните несколько действий в инструментальной программе по преобразованию проекта для использования шаблона. Результатом одного действия является спецификация шаблона. Результатом другого - реализация шаблона. В данной статье описывается реализация шаблона.

В начало

Использование шаблона preferred data source

Шаблон preferred information source обеспечивает клиентскому приложению возможность извлекать информацию из набора источников информации, не задумываясь (по крайней мере более, чем это нужно на высоком уровне) о количестве этих источников. Одни источники идентифицируются как предпочтительные, другие считаются альтернативными, используемыми только тогда, когда предпочтительный источник не может предоставить нужную информацию. Все источники активизируются в фиксированном порядке.

Нефункциональные требования

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

Схема экземпляров компонентов

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

Диаграмма последовательности

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

В начало

Подробно о реализации шаблона preferred data source

Теперь на основе спецификации шаблона можно создавать различные реализации шаблона preferred data source. Обычно все реализации предоставляют определенный уровень автоматизации применения шаблона. Реализации, описанные в данной статье, используют среду управляемой моделями разработки Rational Software Architect. В этом разделе описывается реализация шаблона preferred data source с использованием механизма шаблонов Rational Software Architect.

Этот механизм шаблонов Rational Software Architect предполагает представление сервиса или интерфейса в UML-модели. Использование данного шаблона следует методам управляемой моделями разработки назначения параметров шаблона конкретным элементам UML-модели сервиса или интерфейса. После связывания параметров шаблона автоматически создаются дополнительные UML-элементы. Преобразование UML-to-Java™, активизируемое в полученной модели, генерирует окончательные артефакты, реализованные на языке Java.

Данная реализация шаблона preferred data source создается с использованием механизма шаблонов Rational Software Architect. При этом в создании шаблона принимает участие плагин Eclipse. Этот плагин может быть спакетирован в повторно используемый актив с использованием спецификации Reusable Asset Specification (RAS) (ссылки на дополнительную информацию о спецификации Reusable Asset Specification приведены в разделе "Ресурсы"; информация о шаблонах и повторно используемых активах приведена также в первой части данной серии статей). Результатом такого пакетирования является RAS-актив. Этот RAS-актив вместе с ассоциированными с ним метаданными может быть развернут на RAS-сервере, например, в RAS-репозитории developerWorks. В следующем разделе вы узнаете о том, как обращаться к этому активу шаблона из RAS-репозитория developerWorks, используя RAS-клиент Rational Software Architect. Этот актив можно импортировать в Rational Software Architect, а функциональность Rational Software Architect можно расширить так, чтобы дать возможность пользователям применять к модели шаблон requester side caching.

В начало

Применение шаблона preferred data source

Созданную реализацию шаблона preferred data source можно импортировать в Rational Software Architect при помощи рецепта. Сначала перейдите в раздел Apply patterns to a service implementation рецепта и разверните раздел Applying the preferred data source pattern. Найдите актив и выберите Import, как показано на рисунке 15.

Демонстрацию использования данного шаблона можно просмотреть, загрузив Flash-файл.

Реализация шаблона preferred data source устанавливается в Rational Software Architect. После этого она появляется в pattern explorer, как показано на рисунке 16.

Теперь примените шаблон. Перечисленные ниже действия демонстрируют, как выполнять навигацию по рецепту и импортировать имеющуюся модель catalog в Rational Software Architect. Затем к этой модели применяется шаблон requester side caching и генерируется соответствующий код, работающий с кэшем, в преобразовании UML-to-Java.

1. Откройте UML Model сервиса и создайте WSDL, используя преобразование UML2WSDL.
   
   
2. Создайте одну первичную WS-реализацию сервера, используя сгенерированный WSD.
   
   
3. Создайте одну или несколько альтернативных WS-реализаций, используя этот же WSDL, при необходимости повторите процесс.
   
   
4. Создайте реализацию простого теста для проверки реализации каждого сервиса. Вообще каждая реализация метода проверяет значение или свойство входящего параметра. Затем она принимает решение, возвратить нулевое значение (или пустой список) или экземпляр объекта, для возврата которого метод предназначен. Вот пример реализации метода getQoH():

   public com.ibm.retail.inventory.QoHResponse getQoH( com.ibm.retail.inventory.QoHRequest qoHRequest) throws java.rmi.RemoteException { System.out.println("Primary"); if (qoHRequest.getLocationID() == 1) { com.ibm.retail.inventory.QoHResponse qoh = new com.ibm.retail.inventory.QoHResponse(); qoh.setQuantityAvailable("some"); return qoh; } return null; }

   
   

   Альтернативой может быть следующая реализация:

   public com.ibm.retail.inventory.QoHResponse getQoH( com.ibm.retail.inventory.QoHRequest qoHRequest) throws java.rmi.RemoteException { System.out.println("Secondary"); if (qoHRequest.getLocationID() == 2) { com.ibm.retail.inventory.QoHResponse qoh = new com.ibm.retail.inventory.QoHResponse(); qoh.setQuantityAvailable("lots"); return qoh; } return null; }

   
   
5. Создайте реализацию виртуального Web-сервиса этого же WSDL. Но при создании данной реализации проследите за тем, чтобы Web-проект являлся не только сервером, но и клиентом этого же WSDL. Отметим, что при этом на одном из шагов мастера отображается предупреждение (см. рисунок 18). Поскольку данный сценарий представляет собой особый случай, можно просто проигнорировать это сообщение.
   
   Рисунок 17. Создание реализации виртуального прокси в виде виртуального Web-сервиса
   
   
   
   
   Рисунок 18. Предупреждение
   
   
   
6. Откройте модель проекта для виртуального сервиса (или создайте новую, если ее не существует).
   
   
7. В этой модели создайте UML-пакет, соответствующий главному пакету реализации виртуального сервиса (например, com.ibm.retail.inventory).
   
   
8. В этом пакете визуализируйте интерфейс сервиса (IInventory) и класс обнаружителя сервиса (IInventoryLocator).
   
   
9. Добавьте в модель новый экземпляр шаблона preferred data source.
   
   
10. Свяжите интерфейс сервиса с шаблоном, например, InventoryService.
    
    
11. Свяжите все методы, перенаправляющие сообщения, например, getQoH().
    
    
12. Свяжите визуализацию обнаружителя с шаблоном. Результатом является создание двух новых классов в модели:
    • Реализация маршрутизатора (router), перехватывающего запросы и направляющего их в первичный и альтернативные сервисы по необходимости.
      
      
    • Класс сервлета, который инициализирует и разрешает обновление списка первичного и альтернативных сервисов во время исполнения.
    
    
    Рисунок 20. Информация, выводимая шаблоном preferred data source
    
    
    
13. Используя преобразование UML-to-Java, сгенерируйте код для этих двух классов в Web-проекте виртуального сервиса. Результатом должно быть создание двух новых классов в главном пакете: новый элемент servlet в дескрипторе развертывания и конфигурационный файл времени исполнения (sources.xml), в который помещаются реальные оконечные точки сервисов. Если указанное определение сервиса имеет исключительные ситуации, класс маршрутизатора должен реализовывать их.
    
    
14. Предоставьте реализацию виртуального Web-сервиса для делегирования вновь созданного маршрутизатора. Например:

    public com.ibm.retail.inventory.QoHResponse getQoH( com.ibm.retail.inventory.QoHRequest qoHRequest) throws java.rmi.RemoteException { InventoryServicePrefSvcRouter router = InventoryServicePrefSvcRouter.getInstance(); return router.getQoH(qoHRequest); }

    
    
15. Измените файл sources.xml. Измените название сервиса на InventoryService и обновите все элементы endpoint, указав реальную информацию об оконечной точке. Эту информацию можно получить путем тестирования и проверки первичной и альтернативной реализаций Web-сервиса.

    <facade service="InventoryService"> <source endpoint="http://localhost:9080/LocalInventory/services/InventoryServicePort"/> <source |--10--------20--------30--------40--------50--------60--------70--------80--------9| |-------- XML error: The previous line is longer than the max of 90 characters ---------| endpoint="http://localhost:9080/RemoteInventory/services/ InventoryServicePort"/> </facade>

    
    
16. Перед тестированием приложения проинициализируйте маршрутизатор сервиса. Щелкните правой кнопкой мыши на узле initialization servlet под дескриптором развертывания и выберите Run.

В начало

Чего мы достигли?

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

В начало

Заключение

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

Данный шаблон в сочетании с другими шаблонами в SOA-реализации и рецепте оптимизации сервисов можно использовать для удовлетворения других функциональных и нефункциональных требований. К реализации шаблона preferred data source можно добавить шаблон requestor side для повышения производительности медленных сервисов. Шаблоны logging, основанные на AspectJ, можно использовать для регистрации и аудита использования сервиса без существенного влияния на функциональность выбора предпочтительного источника данных или на функциональность кэширования.

В начало

Загрузка

Описание	Имя	Размер	Метод загрузки
Окончательный проект для статьи	requesterSideCachingPatternCatalogApp.zip	149 КБ	HTTP
Применение шаблона preferred data source	PDS.swf	2955 КБ	HTTP

	Информация о методах загрузки

Ресурсы

• Оригинал статьи "Building SOA applications with reusable assets, Part 5: Preferred data source pattern" (EN).
  
  
• Подпишитесь на RSS-канал для получения уведомлений о выходящих статьях данной серии (дополнительная информация о RSS-фидах по содержимому developerWorks) (EN).
  
  
• Дополнительная информация об OMG-стандарте спецификации Reusable Asset Specification, версия 2.2 (EN).
  
  
• Дополнительная информация о моделировании в Rational Software Architect и Rational Software Modeler в статье "Руководство по моделированию структуры в Rational Software Modeler и Rational Software Architect" (Билл Смит (Bill Smith), developerWorks, июнь 2005 г.) (EN).
  
  
• Подробная информация об IBM Service Modeling Profile в статье "UML 2.0 Profile для программных сервисов" (Саймон Джонстон (Simon Johnston), developerWorks, апрель 2005 г.) (EN).
  
  
• "Моделирование с Aspects: введение в моделирование с аспектами" (Джим Коналлен (Jim Conallen) и Эоин Лэйн (Eoin Lane), developerWorks, июнь 2006 г.) (EN).
  
  
• Дополнительная информация о новой интегрированной аспектной среде в статье "Aspects для MDD: основанная на аспектах трассировка и получение данных при первом сбое в Rational Software Architect" (Хелен Хокинс (Helen Hawkins) и Шон Джэньюари (Sian January), developerWorks, июль 2006 г.) (EN).
  
  
• "Шаблон Web services response template: спецификация" (Эоин Лэйн (Eoin Lane), developerWorks, февраль 2006 г.) - спецификация шаблона WSRT и предлагаемые им решения для улучшения интерфейсов сервисов (EN).
  
  
• "Спецификация шаблона requester side caching: обзор" (Харини Шринивасан (Harini Srinivasan), Джеймс Коналлен (James Conallen) и Эоин Лэйн (Eoin Lane), developerWorks, октябрь 2005 г.) - подробная спецификация шаблона requester-side caching (EN).
  
  
• Информация о J2EE, RUP и Rational Software Architect в статье "Разработка J2EE-архитектуры в Rational Software Architect с использованием Rational Unified Process" (Жан-Луи Марешо (Jean-Louis Marechaux), developerWorks, август 2005 г.) (EN).
  
  
• Раздел SOA and Web services на сайте IBM developerWorks содержит сотни информативных статей и учебных руководств начального, среднего и повышенного уровня сложности по разработке приложений Web-сервисов .
  
  
• На Web-сайте IBM SOA размещен обзор архитектуры SOA и информация о том, как IBM помогает освоиться с ней (EN).
  
  
• Следите за техническими событиями и web-трансляциями developerWorks. В частности, обратите особое внимание на следующие технические брифинги, посвященные SOA и Web-сервисам:(EN)
  • Приступаем к работе с SOA, используя проверенные, гибкие точки входа WebSphere.
  • Создание SOA-решений и управление циклом жизни сервисов.
  • Повторное использование и способность к взаимодействию SOA.
  
  
• Книги по этим и другим техническим темам в книжном магазине Safari.
  
  

• Загрузите RUP Plug-In for SOA V1.0.(EN)
  
  
• Загрузите бесплатную пробную версию Rational RequisitePro V7.0.(EN)
  
  
• Загрузите RUP для SOA Plug-In V1.0.(EN)
  
  
• Загрузите бесплатную пробную версию Rational Software Architect V6.0.(EN)
  
  
• Разработайте ваш следующий проект, используя пробное программное обеспечение IBM, доступное для загрузки непосредственно на сайте developerWorks.(EN)
  
  
• На IBM alphaWorks размещена эталонная реализация RAS под названием Reusable Asset Specification Repository for Workgroups, доступная для загрузки непосредственно с alphaWorks.(EN)
  
  
• Дополнительная информация о Reusable Asset (RAS) Repository на сайте IBM developerWorks.(EN)
  
  
• Усовершенствуйте ваш следующий проект, используя пробное программное обеспечение IBM, доступное для загрузки или на DVD.(EN)
  
  

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

Об авторах

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

		Джим Коналлен (Jim Conallen) работает инженером по программному обеспечению в группе стратегии разработки на основе моделей IBM Software Group, где активно использует архитектуру на основе моделей (MDA) от Object Management Group (OMG) в разработке средств моделирования IBM Rational. Джим часто выступает на конференциях и является автором множества статей. Он специализируется в разработке Web-приложений, в частности, Web Application Extension (WAE) для UML, расширения UML, позволяющего разработчикам моделировать Web-центричные архитектуры с использованием UML и соответствующими уровнями абстрагирования и детализации. Эта работа служит базой для функций Web-моделирования пакетов IBM Rational Rose и IBM Rational XDE.

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

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

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

В начало