• Статья

Реестр служб: главное звено для повышения повторного использования служб в сервис-ориентированной архитектуре

Хуан Пабло Гарсия-Гонсалес (Juan Pablo García-González),
компания DATCO Chile S.A.

Вероника Гаситуа-Декар (Verónica Gacitúa-Décar),
ирландский центр исследований в области разработки ПО (Irish Software Engineering Research Centre)

Д-р. Клаус Паль (Dr. Claus Pahl),
ирландский центр исследований в области разработки ПО (Irish Software Engineering Research Centre)

Сентябрь 2009 г.

Краткое содержание.

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

Введение

Повторное использование служб сильно зависит от способности описывать и публиковать функциональность, предлагаемую службами, открывая эту информацию ее потенциальным потребителям (клиентам). Реестр служб позволяет организовывать информацию о службах и предоставлять средства для их публикации и обнаружения [1]. Стандарт универсального описания, поиска и взаимодействия (Universal Description Discovery and Integration, UDDI) и язык описания веб-служб (Web Services Description Language, WSDL) совместно с протоколом SOAP являются стандартами описания служб и их поставщиков, а также способа использования служб.

  • Язык WSDL [2] предоставляет модель и формат XML для описания того, что предлагает веб-служба. Описание службы в WSDL отделяет абстрактную функциональность службы от деталей, например, как и где предлагается служба. Описание абстрактной службы включает типы и абстрактный интерфейс, а конкретные детали – привязки, элемент службы, содержащий доступные реализации абстрактного интерфейса в конечных точках.
  • Стандарт UDDI [3], [4] предоставляет инфраструктуру, поддерживающую описание, публикацию и обнаружение поставщиков служб, предлагаемых служб и технических деталей для доступа к ним. Ключевой аспект UDDI – способ организации информации о службах и их поставщиках. Информационные сущности (данные UDDI) организованы в виде модели данных и хранятся в реестре служб UDDI. Выполнение запросов (поиск и просмотр записей) и публикация(размещение, удаление и обновление информации, связанной с реестром) являются ключевыми API.

На рисунке 1 представлены некоторые отношения между описанием службы на языке WSDL и информацией, хранящейся в реестре служб UDDI.

Рисунок 1. Отношения между WSDL и UDDI (щелкните рисунок, чтобы просмотреть увеличенное изображение)

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

Выделенные (общедоступные) реестры служб UDDI подвергались критике, помимо прочего, за ограниченность при обращениях к службам и их обнаружении. Однако недавно в Интернете появились поисковые машины, которые умеют обходить общедоступные документы WSDL и представляют интерес как инструменты обнаружения общедоступных служб [5].

Проектирование репозитория корпоративных служб

В этом разделе мы рассмотрим несколько правил проектирования, применимых для разработки улучшенного репозитория корпоративных служб. Основное внимание уделяется улучшению повторного использования служб в ИТ-проектах. Цель – повысить прозрачность служб для экспертов предметной области (часто это относится к бизнес-аналитикам) и дополнить описания служб практической информацией для архитекторов. Бизнес-аналитики, обладающие меньшим объемом технических знаний, но располагающие обширным пониманием предметной области, часто играют роль проектировщиков на раннем этапе реализации инициатив по внедрению или изменению программного обеспечения предприятий. Бизнес-аналитикам принадлежит ключевая роль в вопросе повторного использования служб.

Корпоративные службы

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

На основе инициатив SOA, реализованных на нескольких предприятиях, мы выделяем три типа служб:

  • Бизнес-служба (business service, BS) – клиентские приложения используют ее для доступа к функциональности, предоставляемой приложениями поставщика.
  • Служба приложения (application service, AS) – бизнес-службы используют ее для доступа к функциональности приложений поставщика.
  • Расширение бизнес-службы (business-service extension, BSE) – бизнес-службы используют его для обработки запросов служб приложений и для консолидации единого ответа, отправляемого бизнес-службе. В свою очередь бизнес-служба передает консолидированный ответ клиентскому приложению. Шаблон агрегирования [7] играет ключевую роль в проектировании расширений бизнес-служб.

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

Рисунок 2. Архитектура, основанная на службах, и ее взаимосвязь с ролями шаблона виртуализации (щелкните рисунок, чтобы просмотреть увеличенное изображение)

Пример № 1

Рассмотрим упрощенную бизнес-службу, которая используется в страховой компании для расчета общего объема продаж продуктов по страхованию жизни и коллективному страхованию. Общий объем продаж продуктов по страхованию жизни и общий объем продаж продуктов по групповому страхованию берутся из соответствующих унаследованных приложений. Каждое унаследованное приложение имеет службу приложения (соответственно lifeInsurance и groupInsurance), предоставляющую данные об общем объеме продаж по каждому типу страхового продукта. Бизнес-служба получает запросы от клиентов, которым нужны данные об общем объеме продаж. После этого она обращается к реестру служб, в котором находится информация, необходимая для применения к сообщениям конкретных политик, и данные о зависимостях служб приложений и расширений бизнес-служб.

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

На рисунке 3 представлено описание взаимодействия.

Рисунок 3. Основные взаимодействия между элементами решения, основанного на службах и описанного в примере № 1 (щелкните рисунок, чтобы просмотреть увеличенное изображение)

Реестр корпоративных служб

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

Базовые функциональные возможности реестра корпоративных служб, основанного на стандарте UDDI, можно расширить с помощью:

  • Управления зависимостями служб.
  • Применения политик во время выполнения.
  • Управления версиями служб.
  • Управления ретроспективными данными (данными журнала) служб.

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

Рисунок 4. Реестр корпоративных служб (щелкните рисунок, чтобы просмотреть увеличенное изображение)

Описания служб

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

  • Бизнес-служба описывается на высоком уровне, часто в виде текста на естественном языке и в виде примеров, помогающих бизнес-аналитикам понять принципы ее работы.
  • Расширения бизнес-служб и службы приложений содержат больше технических деталей. Бизнес-служба реализуется посредством как минимум одной службы приложений и может включать также расширение бизнес-службы. Чтобы связать бизнес-службу с одной или несколькими службами приложений и (или) расширениями бизнес-служб, создается отображение зависимости, управляемое реестром служб.

В таблице 1 более подробно описана информация, управляемая реестром служб:

  • Основные атрибуты, описывающие бизнес-службу, приведены в начале таблицы 1. Расширение бизнес-службы и служба приложения имеют общие атрибуты (см. середину таблицы 1). В конце таблицы 1 описывается информация о привязках, устанавливающих взаимодействие бизнес-службы и ее расширений, а также служб приложений.
  • Информация, описывающая службы и независимая от любой реализации реестра, приведена в столбце Информация о службе, а информация, управляемая реестром служб, – в столбце Информация реестра. Если информация в столбцах Информация о службе и Информация реестра совпадает, в столбце Дублирующая информацияпоявляется символ X.
  • В оставшихся столбцах показаны сведения, имеющие отношение к определенным ролям [8]. Бизнес-аналитики и архитекторы решений управляют информацией о бизнес-вопросах и технических вопросах соответственно. Обе этих роли функционируют на уровне проекта или бизнес-единицы. Корпоративные архитекторы и архитекторы инфраструктуры управляют информацией о службах с глобальной точки зрения (то есть в масштабе всего предприятия). Корпоративные архитекторы могут быть заинтересованы, например, в управлении версиями служб, а архитекторов инфраструктуры заботит то, как предоставить требуемую инфраструктурную поддержку для обеспечения работы служб на должном уровне качества обслуживания (QoS), определенном в соглашениях об уровне обслуживания.

Таблица 1. Основные сведения о службе в реестре корпоративных служб (щелкните рисунок, чтобы просмотреть увеличенное изображение)

Использование реестра корпоративных служб для улучшения повторного использования служб

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

  • Бизнес-аналитики, формирующие новые требования к программному обеспечению, могут лучше взаимодействовать с архитекторами решения и корпоративными архитекторами, если будут ссылаться на бизнес-службу, описанную в реестре корпоративных служб. На основе описаний бизнес-служб и их зависимостей от служб приложений и расширений бизнес-служб эксперты предметной области получают сведения о доступной функциональности внутренних приложений. Согласно нашему опыту, это способствует сдвигу от нечетко сформулированных требований к концептуальным схемам решений, содержащим скоординированные службы (созданные бизнес-аналитиками). Долгие совещания архитекторов и бизнес-аналитиков можно сократить или заменить их телефонным разговором, в котором будет идти речь только об информации из реестра служб.
  • Архитекторы ПО могут вносить улучшения в первоначальные концептуальные схемы, составленные бизнес-аналитиками. Впоследствии архитекторы ПО могут прийти к соглашению с корпоративными архитекторами и архитекторами инфраструктуры относительно версий служб и инфраструктурной поддержки. Кроме того, информация, содержащаяся в реестре корпоративных служб, всегда была главным элементом, благодаря которому стороны приходили к соглашению.
  • Информация о зависимостях служб помогла архитекторам инфраструктуры проанализировать, какое влияние окажет привязка новых клиентов к службам приложений. Это критически важно для выполнения соглашения об уровне обслуживания.
  • Конфигурации, определяющие применение политик, содержащихся в реестре служб, во время выполнения, позволили применить специализированный подход к запросам клиентских приложений, связанным с одной бизнес-службой, например, выполнять определенные проверки с учетом форматирования, безопасности и параметризации.
  • Может случиться так, что из-за появления новых требований придется изменить существующие службы.
  • Зачастую расширения или изменения затрагивают только уровень расширений бизнес-служб.
  • Если служба приложения или расширение бизнес-службы изменялись и происходило развертывание новых версий, то версия связанной с ними бизнес-службы оставалась неизменной. (Управление версиями служб обсуждается более подробно в разделе «Как управление версиями служб влияет на реестры служб».)
  • Только несовместимые изменения, ведущие к смене бизнес-функциональности, могут стать причиной появления новых версий бизнес-служб (в целом бизнес-служба проектируется с учетом совместимости с последующими версиями).

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

  • Отделение бизнес-службы от фактической реализации (с использованием одной или нескольких служб приложений и расширений бизнес-служб) – эффективный способ изолировать экспертов предметной области от технической информации, что способствует обнаружению служб на уровне бизнес-логики.
  • Поддержка обнаружения бизнес-служб играет ключевую роль в повторном использовании служб за рамками одного проекта или решения, обеспечивая применение этих служб в нескольких проектах и в масштабах всего предприятия.
  • На практике экспертам предметной области обычно представляются только службы приложений. Последние практически не используются, то есть их повторное применение в ходе последующих разработок происходит редко.
  • Даже в том случае, когда новые требования приводили к изменению существующих решений, использующих службы, уровень повторного применения бизнес-служб оставался высоким. Это происходило благодаря тому, что требуемые изменения выполнялись на уровне расширений бизнес-служб.
  • При переносе унаследованных приложений клиентские приложения продолжали использовать ту же самую бизнес-службу. Изменения происходили по большей части на уровне служб приложений. В реестре корпоративных служб обновлялись описания служб приложений и зависимости служб. Использование бизнес-службы в новых проектах не зависело от того, когда происходил перенос.

Остающиеся открытыми вопросы, имеющиеся в отрасли и академических кругах

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

Стратегии организации и поиска служб в реестрах

Если информацию о службе в корпоративном реестре служб сложно выделить – из-за неадекватной ее организации или неэффективных механизмов поиска – ценность такого реестра падает.

Деление служб на категориипоможет отделить службы друг от друга и классифицировать их в соответствии с одной или несколькими категориями. Реестры UDDI поддерживают эту возможность с помощью категорий служб (tModel). Схемы разделения на категории в UDDI относятся к таксономическим классификациям. В рамках таксономии концепции организуются в иерархическую структуру. К одной сущности UDDI могут быть применены несколько таксономий. Для использования предлагаются стандартные схемы классификации, например, «Система стандартных продуктов и услуг ООН» (UNSPSC [9]). Однако также можно использовать другие стандарты таксономии либо стандарты предприятия. API запросов UDDI поддерживает различные формы запросов, в частности шаблоны просмотра, детализации и вызова. Запросы могут напрямую обращаться к службам, а также к категориям служб.

Подобно поисковым машинам в Интернете, шаблон поиска позволяет находить элементы реестра по ключевым словам. Хотя этот механизм автоматизирует часть поисковых служб, результаты ограничены диапазоном значений системы кодирования и прямыми соответствиями значений. Этот способ не подходит для поиска служб, описания которых включают аналогичные или связанные понятия, описанные с применением другого синтаксиса. Кроме того, при использовании различных схем разделения на категории управление пересекающимися категориями может оказаться затратным [10]. Обслуживание таксономии – это дополнительная нагрузка, которую следует учитывать при развертывании реестра служб. Схемы классификации, которые не обновляются, могут влиять на качество результатов поиска [11].

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

Согласно Кюстеру и др. [12], несмотря на то что семантическое расширение описаний служб может повысить качество поиска служб, некоторые проблемы остаются нерешенными, в частности, как снизить вычислительные затраты на осмысление, обслуживание онтологий и улучшение результатов поиска для повышения его эффективности.

Как управление версиями служб влияет на реестры служб

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

  • Службы, реализованные по принципу снизу вверх [13], часто удовлетворяют конкретным требованиям проекта внутри предметной области. Когда любую из этих служб потенциально можно использовать в ином контексте, как правило, требуются изменения или расширения.
  • Аналогичным образом службы, построенные по принципу сверху вниз, тоже часто требуется изменить (уточнить), чтобы они соответствовали определенному контексту.
  • Стратегии управления версиями различаются в зависимости от требований. Одно решение вряд ли будет подходить для всех ситуаций. В WSDL и UDDI правила управления версиями служб не определены. Некоторые авторы предлагают стратегии управления версиями. Большинство этих стратегий относятся к совместимости с предыдущими и последующими версиями [14].
  • Версия, совместимая с предыдущими, способна поддерживать клиентов, использующих предыдущие версии службы.
  • Версия, совместимая с последующими, способна адаптироваться к неизвестным пока требованиям, которые возникнут в будущем, и относятся к новым версиям службы. Этот тип совместимости включает не только стратегию управления версиями, но и стратегию проектированияслужб, связанную со способностью изменения.

Часто новые версии служб являются репликациями предыдущих версий, в которых добавлены новые элементы или изменены существующие. Новым версиям присваивается другое название (согласно соглашению об именах), и их описание сохраняется в реестре как новая запись. Юрич и др. [15] предлагают расширения WSDL и UDDI для управления версиями служб. Этот подход касается управления версиями как во время выполнения, так и во время разработки. Эффективность на уровне кода обеспечивается благодаря тому, что нескольким версиям службы разрешено ссылаться на одну и ту же базу кода. Кроме этого, потребители получают уведомления о новых и нерекомендуемых версиях служб. Для отслеживания изменений поддерживается трассировка. В этом научном исследовании поощряется повторное использование служб при том, что сложность реестра служб остается управляемой.

Применение сведений об использовании службы для улучшения описания и обнаружения служб

История использования службы может стать интересным источником информации не только для воссоздания ее реального поведения [16], но и для ее обнаружения. Сохраненные данные об истории использования службы (журнал) помогут разбить службы на категории в соответствии с их пользователями или с поведением служб. Рассмотрим описание службы, в котором указано, что в контракте заявлен конкретный уровень производительности службы. Однако реально измеренный уровень производительности в заданный период времени (рассчитывается на основании данных журнала) оказался ниже. Эта информация может использоваться при обнаружении службы. Те службы, уровень производительности которых ниже ожидаемого, будут исключены из результатов поиска.

Статистика поведения служб в ретроспективе поможет построить рейтинги с меньшим уровнем отклонения и повысить точность обнаружения служб. Однако необходимо наличие инфраструктуры для непрерывного мониторинга служб и сохранения сведений журналов. На основе журналов служб можно рассчитать вероятности для количественного измерения неопределенности. Кларк и др. [17] рассматривают неопределенность в отношении конфигурирования системы, построенной на основе служб, параметров оценивания компонентов системы и длительности событий. Модель неопределенности используется для предсказания производительности системы при росте нагрузки. Это основной тип анализа, позволяющий определить параметры инфраструктуры для поддержки служб. Данные журналов отдельных служб помогают прогнозировать производительность всей системы.

Спрос и предложение в среде, объединяющей несколько предприятий, зависят от того, в какой степени стороны доверяют друг другу. «Доверие к другим» – один из критериев, используемых для присвоения репутации (свидетельской репутации [18]) общедоступным службам. Если компания X знает, что некоторая служба используется компанией Y, которой доверяет компания X, или была положительно оценена ею, репутация этой службы с точки зрения X возрастет. С этим связана проблема появления отклонений положительных оценок, несправедливых оценок и варьирования качества оценок [19].

Достаточность описаний WSDL для эффективного поиска служб с целью компоновки

Службы используются повторно не только клиентскими приложениями, но и другими службами внутри компоновки служб. Компоновка служб предоставляет более крупномодульную функциональность и точнее соответствует потребностям бизнеса. Одна из проблем при поиске службы (полезной в рамках композиции служб) – это необходимость проверки того, что все используемые службы способны «общаться» друг с другом, то есть проверка протокола, используемого для обмена сообщениями между ними, на совместимость. Основное требование к совместимости – отсутствие взаимных блокировок. Кроме этого, необходима совместимость синтаксиса и семантики сообщений.

На рисунке 5 показан типичный пример несовместимости на уровне протокола между двумя сторонами. На рисунке Покупатель предлагает службу купить Товар, а Продавец предлагает службу продать Товар.

Рисунок 5. Пример несовместимости на уровне протокола (щелкните рисунок, чтобы просмотреть увеличенное изображение)

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

Когда количество служб, предлагаемых и рекламируемых в репозиториях, растет, увеличивается вероятность того, что потребность в новой службе будет удовлетворена путем компоновки существующих. Однако может потребоваться посредничество на уровне протоколов. Конфликты на уровне сообщений и (или) сеансов связи до некоторой степени могут быть разрешены компонентом-посредником [20], [21]. Однако подтверждение совместимости служб и разрешение проблем на уровне поведения является дорогостоящей операцией, поскольку включает исследование возможных состояний служб во время взаимодействия. Для повышения уровня повторного использования в подобных ситуациях требуются эффективные механизмы поиска совместимых служб.

Например, вместо прямой публикации поведения службы в репозитории, ее поставщик может опубликовать «кратко сформулированное описание» ожидаемого поведения служб, совместимых с данной (под совместимостью понимается отсутствие взаимоблокировок). «Кратко сформулированное описание» называется «правилами работы» [22] и разрешает скрывать детали реализации, раскрывая при этом достаточный объем информации для поиска совместимых партнеров. Проверка возможности компоновки службы с другими службами сводится к проверке того, является ли основанное на графах представление потенциального партнера подграфом «правил работы». Это менее дорогостоящая операция, чем обзор всех возможных состояний служб.

Заключение

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

Ресурсы

  1. Pijanowski, Keith. “Visibility and Control in a Service-Oriented Architecture.” MSDN, May 2007.
  2. W3C.org. Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language.
  3. UDDI.org. UDDI Version 3.0.2. UDDI Spec Technical Committee Draft, October 19, 2004.
  4. Microsoft Corporation. “UDDI Specification Index Page.” MSDN, July 2009.
  5. Al-Masri, Eyhab, and Qusay H. Mahmoud. “Investigating Web Services on the World Wide Web.” WWW 2008: Web Engineering— Web Service Deployment Track, April 21–25, 2008, 795–804.
  6. Madrid, Chris. “SOA Realization Through Service Virtualization.” SOA Magazine, September 3, 2007. (Статья представлена также здесь.)
  7.  
  8. Hohpe, Gregor, and Bobby Woolf. Enterprise Integration Patterns. Boston: Addison-Wesley, 2004.
  9. Cardinal, Mario. “The Hidden Roles of Software Architects: The Three Types of Architect.” MSDN, March 2008.
  10. UNSPSC.org. “UNSPSC Codeset.” (Managed by the Electronic Commerce Code Management Association (ECCMA).) August 2007.
  11. Klein, Michel. “Combining and Relating Ontologies: An Analysis of Problems and Solutions.” Proceedings of Workshop on Ontologies and Information Sharing at 17th International Joint Conference on Artificial Intelligence (IJCAI-01), 2001, 53–62.
  12. Hepp, Martin, Joerg Leukel, and Volker Schmitz. “A Quantitative Analysis of eClass, UNSPSC, eOTD, and RNTD: Content, Coverage, and Maintenance.” Proceedings of IEEE International Conference on e-Business Engineering (ICEBE’05), 2005, 572–581.
  13. Küster, Ulrich, Holger Lausen, and Birgitta König-Ries. “Evaluation of Semantic Service Discovery: A Survey and Directions for Future Research.” Emerging Web Services Technology. Volume II, 2008, 41–58.
  14. Erl, Thomas. Service-Oriented Architecture: Concepts, Technology, and Design. Prentice Hall Service-Oriented Computing Series from Thomas Erl, 2004.
  15. Parrish, Allen, Brandon Dixon, and David Cordes. “A Conceptual Foundation for Component-Based Software Deployment.” Journal of Systems and Software. Vol. 57, Issue 3, July 2001, 193–200.
  16. Juric, Matjaz B., Ana Sasa, Bostjan Brumen, and Ivan Rozman. “WSDL and UDDI Extensions for Version Support in Web Services.” Journal of Systems and Software. Vol. 82, Issue 8 (doi:10.1016/j.jss.2009.03.001), August 2009, 1326–1343.
  17. van der Aalst, W. M. P., and A. J. M. M Weijters. “Process Mining: A Research Agenda.” Computers in Industry. Vol. 53, Issue 3 (doi: 10.1016/j.compind.2003.10.001), April 2004, 231–244.
  18. Clark, Allan, Stephen Gilmore, and Mirco Tribastone. “Quantitative Analysis of Web Services Using SRMC.” SFM. Vol. 5569, 2009, 296–339.
  19. Huynh, Trung Dong, Nicholas R. Jennings, and Nigel R. Shadbolt. “An Integrated Trust and Reputation Model for Open Multi-Agent Systems.” Journal of Autonomous Agents and Multi-Agent Systems. Vol. 13, Issue 2, March 2006, 119–154.
  20. Jøsang, Audun, Roslan Ismail, and Colin Boyd. “A Survey of Trust and Reputation Systems for Online Service Provision.” Decision Support Systems. Vol. 43, Issue 2, March 2007, 618–644.
  21. Dustdar, Schahram, and Wolfgang Schreiner. “A Survey on Web Services Composition.” International Journal of Web and Grid Services (IJWGS). Vol. 1, Issue 1, 2005, 1–30.
  22. Li, Xitong, Yushun Fan, Jian Wang, Li Wang, and Feng Jiang. “A Pattern-Based Approach to Development of Service Mediators for Protocol Mediation.” Proceedings of the Seventh Working IEEE/IFIP Conference on Software Architecture (WICSA 2008), February 2008, 137–146.
  23. Kaschner, Kathrin, Peter Massuthe, and Karsten Wolf. “Symbolic Representation of Operating Guidelines for Services.” Petri Net Newsletter. Vol. 72, April 2007, 21–28.

Об авторах

Хуан Пабло Гарсия-Гонсалес – ведущий разработчик ПО и главный архитектор компании DATCO Chile S.A. Принимал участие во многих проектах по разработке ПО, в том числе решений, основанных на службах. Помимо работ над постоянными проектами, он со своей командой занимается созданием инновационных мобильных решений для банковской сферы, основанных на службах.

Вероника Гаситуа-Декар– аспирант-исследователь факультета вычислительной техники Городского университета Дублина и Ирландского центра исследований в области разработки ПО (Irish Software Engineering Research Centre). Основным предметом ее исследований является разработка инструментов и методов проектирования архитектур служб, основанных на процессах. Ранее она работала ИТ-архитектором в крупной горнодобывающей компании.

Д-р. Клаус Паль – старший преподаватель факультета вычислительной техники Городского университета Дублина, где он возглавляет группу по разработке ПО и систем. Он также работает в Ирландском центре исследований в области разработки ПО и центре нового поколения локализации (Centre for Next Generation Location, CNGL).