Джим Амсден ,

инженерно-технический работник,
корпорация IBM

Моделирование SOA:

Часть 2. Спецификация сервиса

Источник: сайт представительства корпорации IBM в России, раздел « developerWorks Россия», http://www.ibm.com/developerworks/ru/library/1009_amsden/ , 0 9.01.2008

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

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

Контекст статьи

В первой статье серии, "Моделирование SOA: Часть 1. Идентификация сервиса" ( http://www.ibm.com/developerworks/ru/library/1002_amsden/index.html ) рассказывалось о принципах идентификации сервисов, отвечающих бизнес-требованиям. Сначала мы определили, какие бизнес-задачи должны быть решены и какие цели достигнуты для реализации бизнес-миссии. Затем мы смоделировали бизнес-операции и бизнес-процессы, необходимые для выполнения задач и достижения целей. После этого мы рассмотрели бизнес-процесс как кооперацию сервисов, представляющую собой контракт о требованиях к сервису, который должен выполняться нашим будущим решением. Впоследствии мы использовали этот контракт о требованиях как вспомогательное средство для идентификации сервисов и потенциальных взаимоотношений между ними. Благодаря этому мы получили формальный механизм идентификации значимых для бизнеса сервисов с привязкой к бизнес-целям и бизнес-задачам, для выполнения которых они предназначены.

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

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

Описание спецификации сервиса

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

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

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

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

Таблица 1. Разработка ролей процессов, задач и инструментов

Полностью эта статья находится на сайте представительства корпорации IBM в России по адресу http://www.ibm.com/developerworks/ru/library/1009_amsden/

Оригинал статьи: Modeling SOA: Part 2. Service specification (EN) ;