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

Web-сервисы становятся предпочтительной технологией реализации сервис-ориентированных архитектур (Service-Oriented Architecture, SOA). Они упрощают взаимодействие и, следовательно, интеграцию приложений. Благодаря Web-сервисам появилась возможность создавать «обертки» для унаследованных приложений, так что разработчики могут получать к ним доступ с помощью стандартных языков и протоколов.

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

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

ПРОБЛЕМЫ ИНТЕРОПЕРАБЕЛЬНОСТИ

Проблемы интероперабельности в SOA мы будем рассматривать по нескольким направлениям.

Уровни интеграции

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

Обмен сообщениями. Основой любой спецификации интероперабельности является определение протокола транспортировки информации вне зависимости от ее синтаксиса и семантики. В Web-сервисах на уровне обмена сообщениями самым распространенным является протокол SOAP. Поставщик услуг может дополнительно потребовать, чтобы обмен сообщениями характеризовался определенными свойствами (скажем, взаимодействие может быть надежным или ненадежным, обеспечивать определенные функции защиты). Подобные свойства обеспечиваются спецификациями WS-Reliability и WS-Security. Мы рассматриваем свойства, связанные с обменом сообщениями как часть этого уровня, хотя некоторые стандарты имеют более тонкие степени детализации. Например, WS-Security располагается поверх протокола SOAP, а не является его составной частью.

Базовая координация. Уровень координации определяет требования и свойства, относящиеся к последовательностям обмена сообщениями между двумя или несколькими «партнерами». Например, два сервиса должны скоординировать свою работу, чтобы обеспечить атомарность транзакции на базе двухфазной фиксации. На данном уровне действуют и спецификации управления интегральной безопасностью WS-Federation и Liberty Alliance (www.projectliberty.org). Мы рассматриваем этот вид координации как горизонтальный, подразумевая, что такие протоколы полезны и применимы во многих бизнес-сценариях.

Интерфейсы и протоколы бизнес-уровня. Данный уровень определяет функциональные свойства сервиса. Интерфейс Web-сервиса — это набор операций, которые поддерживают сервис, и набор сообщений, способных отправлять и получать такие операции. WSDL (Web Services Definition Language, язык определения Web-сервисов) — наиболее распространенный язык описания интерфейсов [1]. На этом уровне могут возникнуть следующие неоднородности:

  • синтаксические — различия между сигнатурами операций, т.е. именами операций и входных/выходных сообщений;
  • структурные — различия в ожидаемых типах или значениях входных/выходных сообщений;
  • семантические — различия в интерпретациях значения элемента данных или назначения операции.

Бизнес-протокол определяет допустимые последовательности запуска операций (обмена сообщениями). Неоднородности между бизнес-протоколами могут возникнуть из-за разницы в ограничениях на порядок сообщений или потому, что сервис ожидает/посылает сообщение, которое его «партнер» не готов послать/получить [2]. Например, заказчик ожидает подтверждение посланного сообщения, а поставщик его не выдает. Сейчас самым популярным языком определения бизнес-протоколов является BPEL (WS-Business Process Execution Language, язык выполнения бизнес-процессов). Для организации взаимодействия между сервисами разработчики могут использовать и другие протоколы, такие как протокол установки доверительных отношений (trust-negotiation protocol) или обсуждения контракта (contract-negotiation protocol), что ведет к дополнительным различиям на этом уровне.

Политики и качественные свойства. Определение сервиса может содержать политики (например, конфиденциальности) и другие качественные свойства. Клиенты, взаимодействующие с сервисом, должны понимать, например, такие показатели качества обслуживания (Quality of service, QoS), как время отклика. Скажем, WS-Policy определяет платформу выражения политик сервисов. Подобные спецификации также поддерживают интероперабельность, хотя они необходимы скорее при обнаружении/привязке к сервису, чем при взаимодействии.

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

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

Бизнес-сервисы и сервисы промежуточного слоя

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

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

Языки и спецификации

Между спецификациями и языками (или метаспецификациями) существует очевидное, но иногда недооцениваемое различие, которое помогает рассматривать предложения по стандартизации в свете общей перспективы. В некоторых случаях стандартизация нацелена на утверждение языка, который разработчики задействуют для определения спецификаций. Например, разработчики сервисов или консорциумы по стандартизации могут использовать WSDL, WS-BPEL и WS-Policy для создания спецификаций интерфейсов, бизнес-протоколов и политик. В других случаях спецификации появляются непосредственно в ходе работ по стандартизации. Например, такие протоколы взаимодействия, как SOAP и WS-Transactions — это не языки, а спецификации, которые можно применять для создания других спецификаций.

Как и на большинстве других платформ интероперабельности, в области Web-сервисов для более низких уровней стека интероперабельности разрабатываются спецификации, а для более высоких уровней — языки. Это хорошо согласуется с наблюдением, что спецификации более высокого уровня являются в большей степени проблемно-ориентированными или даже сервисно-ориентированными. Использование общего стандартизованного языка (например, WS-BPEL) для определения бизнес-протоколов облегчает понимание поведения сервисов и разработку инструментов для анализа бизнес-протоколов, упрощающих создание интероперабельных сервисов.

Разработчики могут описать сервис, ассоциировав его с набором спецификаций на разных уровнях. Некоторые из этих спецификаций (например, предназначенные для сервисов, поддерживающих HTTP, SOAP и WS-Transactions) непосредственно создают консорциумы по стандартизации. Другие предоставляются проблемно-ориентированными консорциумами (вроде автомобилестроителей) или самими разработчиками сервисов (скажем, сервис поддерживает интерфейс InvoicePayment или бизнес-протокол InsuranceQuotation).

Заглядывая вперед, в понятие «спецификация» мы также включаем метаспецификации, если не оговаривается противное.

Пользователи и автоматизированные потребители

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

Приложения могут задействовать описания сервисов для поддержки разных способов их взаимодействия — например, проверять, происходит ли обмен сообщениями в соответствии с определенным протоколом, или обеспечивать невозможность отказа от операций. Для этого приложения обычно читают спецификации сервиса, предоставляемые на некотором стандартном языке, вроде WS-BPEL. В общем случае приложения способны использовать лишь формальные спецификации. Приложения для разработки сервисов также могут получать доступ к формальным спецификациям, чтобы автоматизировать аспекты жизненного цикла разработки. Скажем, это позволяет генерировать заглушки и скелетоны по спецификациям WSDL или помогать пользователям при оценке сходств и различий между двумя сервисами (по крайней мере, на синтаксическом и структурном уровнях).

В отличие от этого, приложения, поддерживающие связывание (особенно динамическое), не заинтересованы в чтении спецификаций, поэтому не заботятся о степени формализации. На самом деле их «интересует» лишь одно — поддерживает ли сервис определенную (не мета-) спецификацию. Например, клиент транспортной компании должен знать, поддерживает ли конкретный сервис протокол SOAP 1.2 и некий интерфейс, например ShippingIntf, разработанный консорциумом по стандартизации в транспортной отрасли.

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

Текущие исследования нацелены на повышение уровня автоматизации процесса определения интероперабельности сервисов. Например, нужно позволить клиентским приложениям читать подробные спецификации сервиса, предоставляемые поставщиком (такие как WSDL-файл сервиса). При выявлении отсутствия интероперабельности обнаруженного сервиса, приложения должны автоматически справляться с проблемой [2]. Спецификации, ориентированные на пользователей, не всегда предназначены для бизнес-сервисов, а спецификации бизнес-сервисов не всегда предназначены для человека. Протокол SOAP, например, является полуформальным. Он рассчитан на понимание людьми ровно настолько, чтобы они могли реализовать программные инструменты промежуточного слоя для его поддержки.

Действия по стадиям жизненного цикла

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

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

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

Стадия управления связана с мониторингом взаимодействия сервисов, предоставлением ресурсов, управлением конфигурациями и взаимоотношениями сервисов. Спецификации управления определяют видимые интерфейсы для отслеживания, учета, аудита, наблюдения и контроля над выполнением сервиса. Для этого предназначены две спецификации — WSDM (Web Services Distributed Management, распределенное управление Web-сервисами) и WS-Resource.

ПОДХОДЫ К ИНТЕРОПЕРАБЕЛЬНОСТИ СЕРВИСОВ

Используются два основных подхода к взаимодействию сервисов с позиций SOA: семейство стандартов WS-* и стандарт ebXML [3].

Основной вклад в спецификации WS-* вносят поставщики промышленного программного обеспечения. Они разрабатывают последовательно расширяемые модульные спецификации, вводя их «снизу вверх» вместе с простыми горизонтальными спецификациями, которые служат базовыми строительными блоками. Их стек постепенно расширяется за счет спецификаций, созданных на более высоком уровне абстракции. Например, WS-Security и WS-Reliability опираются на протокол SOAP при обеспечении безопасного надежного обмена сообщениями.

Центр ООН по содействию торговле и электронному бизнесу (UN/CEFACT) и организация OASIS (Organization for the Advancement of Structured Information Standards; www.oasis-open.org) возглавляют разработку языка ebXML. Они стремятся создать набор спецификаций, отражающих все аспекты B2B-взаимодействий, в том числе договорные отношения. Эти организации развивают как части единого решения спецификации совместного ведения бизнес-процессов, заключения контрактов и безопасного надежного обмена сообщениями.

Мы обсудим несколько подходов к интероперабельности, опустив рассмотрение несколько других спецификаций интероперабельности, в том числе на семантические Web-сервисы (www.daml.org/services), электронный обмен данными (EDI) и на RosettaNet (стандартизация описаний продуктов и взаимодействий бизнес-процессов [4-6]).

Уровни интеграции

Во врезке «Стандартизация SOA» кратко описаны функции основных спецификаций интероперабельности на каждом уровне интеграции.

На уровне сообщений в WS-* и ebXML используется SOAP как базовый протокол обмена сообщениями. Допускается применение и других протоколов, но SOAP имеет самое сильное влияние. Указанные подходы различаются представлениями и способами введения расширенных функций. ebXML (ebXML Messaging, ebMS) охватывает весь набор спецификаций надежного обмена сообщениями и обеспечения безопасности на уровне сообщений, построенных на базе протокола SOAP. Напротив, подходы WS-* являются более гибкими и допускают модульное добавление расширенных функций.

Хотя модульное построение часто оказывается хорошей практикой, несколько групп промышленных поставщиков представили перекрывающиеся, а иногда и конкурирующие предложения, связанные с одинаковыми функциями (например, WS-Reliability и WS-ReliableMessaging). Таким образом эти поставщики порождают неоднородность и препятствуют эффективной стандартизации. Точно так же в области безопасности сразу несколько конкурирующих стандартов (например, такие спецификации на базе XML, как XKMS, WS-Trust и WS-Federation) обеспечивают функции установки доверительных отношений и объединения сервисов на основе WS-Security [7].

Еще одна проблема состоит в том, что при разработке уровней спецификации могут появиться ее новые версии, что потребует пересмотра уровней. Эта проблема свойственна относительно молодым технологиям. Все транзакции ebXML являются двусторонними (даже многосторонние взаимодействия осуществляются как наборы двусторонних), а потому на базовом уровне координации нет спецификации для координации группы торговых партнеров. Подход WS-* дал несколько спецификаций для координации операций сервисов. Например, WS-Transactions использует WS-Coordination, чтобы координировать выполнение бизнес-транзакций несколькими сервисами.

На уровне бизнес-интерфейсов и бизнес-протоколов подход WS-* нацелен на стандартизацию набора языков для определения спецификаций протоколов и интерфейсов. За исключением таких языков, спецификации не налагают ограничений на способы определения интерфейсов. Это придает сервисам большую гибкость, но оставляет их открытыми для синтаксической и семантической неоднородности.

Языки WSCI (Web Service Choreography Interface), WS-CDL (Web Services Choreography Description Language) и WS-BPEL строятся на основе WSDL, что позволяет составлять спецификации бизнес-протоколов [8]. WS-CDL и WS-BPEL привлекают к себе наибольший интерес. Эти языки различаются тем, что WS-BPEL представляет протоколы с точки зрения сервиса, тогда как WS-CDL целиком описывает хореографию обмена сообщениями между несколькими «партнерами». Оба языка обеспечивают модель определения протокола, которая концептуально основана на процессных моделях (блок-схемах и диаграммах деятельности с такими конструкциями, как последовательности, ветвления и соединения), а не на конечных автоматах или диаграммах последовательности. Они воплощают в себе альтернативный формализм, широко применяемый для определения протоколов в разных областях информатики.

ebXML рекомендует настройку набора общих, базовых компонентов для определения документов, которые будут участвовать в обмене. Язык ebXML поддерживает определение последовательностей обмена сообщениями в спецификациях схемы бизнес-процесса (Business-Process Schema Specification, BPSS), а также в профилях и соглашениях протокола сотрудничества (Collaboration Protocol Profile — CPP, Collaboration Protocol Agreement — CPA). Разработчики могут использовать такую комбинацию спецификаций для определения хореографии нескольких сервисов. Эти детальные спецификации охватывают множество аспектов взаимодействия, находящихся далеко за пределами определения хореографии. Например, как часть определения протокола они описывают функции установки требований к безопасности и надежности, а также другие политики обмена сообщениями.

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

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

Что же касается качественных свойств, в подходе WS-* при определении политики сервиса или свойств используются несколько языков. Одним из примеров является семейство WS-Policy. Однако его представители не предписывают, как и какие политики можно определить. Это обычно оставляют на долю предложений, выдвигаемых консорциумами по стандартизации. Недавно опубликованная спецификация WS-RM Policy предоставляет собой набор предопределенных положений политики для WS-Reliable Messaging. Хотя OASIS больше интересуют политики безопасности и контроля над доступом, разработчики могут задействовать ее язык XACML (XML Access Control Markup Language) для выражения политик сервиса. Язык ebXML не поддерживает явную формализацию политик сервисов во фрагментарной манере. Разработчики могут определить политики как возможности и требования сервиса в профилях и соглашениях протокола сотрудничества CPP и CPA.

Другие направления

Табл. 1 суммирует результаты нашего анализа спецификаций интероперабельности при сравнении бизнес-сервисов с сервисами промежуточного слоя. В табл. 2 приведены результаты анализа двух подходов с указанием соответствующих им языков и спецификаций. Некоторые спецификации можно отнести к обеим категориям, например SAML обеспечивает как язык определения безопасности, так и спецификацию обмена параметрами между сервисами. Однако большинство стандартов являются либо языками, либо спецификациями. Например, SOAP и WS-Security — это спецификации, а WSDL и WS-BPEL — языки.

Табл. 3 классифицирует спецификации интероперабельности по отношению к действиям во время жизненного цикла. Хотя при связывании уместны все спецификации, в таблице указаны только современные. Аспект управления сравнительно нов для Web-сервисов. Это не удивительно, ведь проблемы управления начинают возникать, когда базовая технология «встает на место», а поставщики услуг разворачивают и начинают поддерживать множество Web-сервисов. Развитие grid-сред сильно повлияло на спецификации в этой области [9]. В данном отношении идеи grid и технологии Web-сервисов объединяются в набор общих спецификаций на платформе WS-Resource. В подходах ebXML вопросам управления особого внимания не уделяется.

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

Высокоуровневые спецификации, вроде WSDL и WS-BPEL, предназначены как для пользователей, так и для приложений. Разработчики сервисов могут прочесть WSDL, чтобы понять, как построить взаимодействие клиента с сервисом. А инструменты могут автоматически генерировать скелетоны сервисов по спецификациям WSDL. Люди применяют спецификации BPEL при разработке, а инструменты — во время выполнения, чтобы проверить, действительно ли взаимодействия происходят в соответствии со спецификациями.

Такая же ситуация складывается вокруг ebXML. Люди используют базовые компоненты ebMS и отдельные части BPSS, которые обслуживают координационные и транзакциональные свойства, чтобы развивать ПО промежуточного слоя, допускающее взаимодействия согласно этим спецификациям. CPP, CPA и части BPSS, которые обеспечивают шаблоны определений бизнес-процессов, предназначены как для разработчиков, так и для приложений — их можно читать, преобразовывать, объединять и обсуждать.

ОТКРЫТЫЕ ПРОБЛЕМЫ

Организация WS-I (The Web Services Interoperability Organization; www.ws-i.org) пытается собрать возможно более полный список спецификаций интероперабельности, обеспечив руководящие принципы реализации сервисов в соответствии со стандартами, а также использования комбинации спецификаций WS для обеспечения взаимодействия. Большая часть усилий WS-I направлена на разработку профилей интероперабельности для общепринятых спецификаций, таких как SOAP, WSDL, WS-Security и UDDI. Для упрощения интеграции технологий сервисов следует решить и некоторые другие проблемы.

Освоение и применение

SOAP, WSDL и WS-Security являются наиболее распространенными и используемыми спецификациями [10, 11]. Хотя большинство платформ поддерживают UDDI, этот стандарт не получил широкого распространения. По общему мнению, ситуация изменится в ближайшем будущем, когда с ростом числа сервисов появится некоторая возможность динамического связывания. Растущий интерес к моделированию сервисных процессов и композиции сервисов побудил разработчиков к поддержке WS-BPEL и даже выпуску нескольких его бесплатных реализаций с открытым кодом.

Многие среды разработки и интеграции, которые обеспечивают создание интегрированных решений для организации защиты, поддерживают также SAML. Примечательно, что некоторые среды разработки вместо WS-Security поддерживают XML-Encryption и XML-Signature. Недавно OASIS приняла WSDM с целью реализации решений для управления Web-сервисами. Некоторые решения для бизнес-интеграции поддерживают спецификации ebXML, но пока они не очень распространены.

Выбор спецификаций

Взаимосвязи между спецификациями не всегда полностью ясны. Как правило, спецификации семейства WS-* согласованы друг с другом, но на более высоких уровнях ситуация «размывается». Например, BPEL базируется на WSDL, но его отношения с WS-Transactions и WS-Coordination при обеспечении транзакциональных свойств выражены недостаточно ясно. Язык ebXML, вертикальные спецификации типа RosettaNet и семантические подходы к Web-сервисам развиваются в направлении многократного использования (или разрешения использования) спецификаций семейства WS-*, таких как SOAP и WSDL, на более низких уровнях.

Конвергенция

Отраслевые группы выдвигают конкурирующие предложения по стандартизации одного и того же аспекта, а официальные органы стандартизации поддерживают еще одну, собственную версию [10]. Пока это не было препятствием для распространения технологии Web-сервисов, поскольку поставщики программного обеспечения сосредоточились лишь на нескольких спецификациях. Предложенные нами направления интероперабельности будут полезны в качестве платформы развития «дорожной карты» стандартизации. Они обеспечат разработчикам сервисов руководящие принципы поиска пути через сложный лабиринт доступных спецификаций.

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

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

Литература
  1. F. Curbera et al., Unraveling the Web Services Web: An Introduction to SOAP, WSDL, and UDDI // IEEE Internet Computing. March-April 2002.
  2. B. Benatallah et al., Developing Adapters for Web Services Integration. Proc. Int?l Conf. Advanced Information System Eng. (CAISE), Springer-Verlag, 2005.
  3. S. Patil, E. Newcomer, ebXML and Web Services. IEEE Internet Computing, May/June 2003.
  4. C. Bussler, B2B Integration: Concepts and Architecture. Springer, 2003.
  5. G. Alonso et al., Web Services: Concepts, Architectures and Application. Springer, 2004.
  6. D.J. Kim et al., A Comparison of B2B E-Service Solutions. Comm. ACM, Dec. 2003.
  7. M. Naedele, Standards for XML and Web Services Security. Computer, Apr. 2003.
  8. C. Peltz, Web Services Orchestration and Choreography. Computer, Oct. 2003.
  9. I. Foster et al., The Open Grid Services Architecture, v.1.0, GGF informational document. Jan. 2005.
  10. S. Vinoski, WS-Nonexistent. IEEE Internet Computing, November/December 2004.
  11. N.S. Latimer et al., 2002-2003 Web Services Development. North America: User Wants and Needs. Gartner, July 2003.
  12. B. Benatallah, F. Casati, F. Toumani, Representing, Analyzing and Managing Web Service Protocols. Data and Knowledge Eng. J. (DKE); http://dx.doi.org/10.1016/j.datak.2005.07.006.

Хамид Мотахари Нежад (hamidm@cse.unsw.edu.au) — докторант Университета Нового Южного Уэльса. Боалем Бенаталла (boualem@cse.unsw.edu.au) — доцент Университета Нового Южного Уэльса. Фабио Касати (fabio.casati@hp.com) — старший научный сотрудник лаборатории HP Labs в Пало-Альто (Калифорния). Фарук Томани (ftoumani@isima.fr) — старший лектор лаборатории LIMOS-ISIMA (Франция).

Стандартизация SOA

Суммируем предложения по стандартизации на разных уровнях стека интеграции сервисов. Спецификации, предложенные отраслевыми группами, обозначены как IS (индустриальные). Спецификации, одобренные консорциумами W3C и OASIS, снабжены пометкой CS, а только рассматриваемые консорциумами — пометкой CS-R.

Семейство WS-*

Семейство WS-* — группа спецификаций, разработанных преимущественно промышленными поставщиками программного обеспечения.

Обмен сообщениями. SOAP 1.2 (CS) — независимый от транспорта протокол обмена сообщениями на основе XML, базовый строительный блок для более сложных спецификаций на уровне обмена сообщениями. К числу других спецификаций на этом уровне относятся:

  • WS-Addressing (CS-R) — определяет механизмы адресации конечных точек сервиса и включения адресной информации в заголовки сообщений SOAP;
  • WS-Reliability 1.1 (CS) — расширяет заголовки SOAP, чтобы гарантировать доставку сообщения с помощью подтверждающих сообщений;
  • WS-Reliable Messaging (CS-R) — обеспечивает функциональность, подобную возможностям WS-Reliability, но построена на базе WS-Addressing и использует WS-RM Policy для отображения политики надежности;
  • SOAP-Attachments (CS) — позволяет вкладывать документы MIME в сообщения SOAP;
  • WS-Security 1.0 (CS) — расширяет спецификацию SOAP для обеспечения конфиденциальности, целостности и аутентификации; построена на базе W3C XML-Encryption и W3C XML-Signature;
  • SAML 2.0 (Security Assertion Markup Language, CS) — язык определения положений безопасности (аутентификации и авторизации) и соответствующих механизмов обмена.

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

  • WS-Coordination (IS) — обеспечивает платформу для координации действий некоторых сервисов на базе программного обеспечения промежуточного слоя;
  • WS-Transaction (IS) — состоит из WS-AtomicTransaction (поддержка сильно связанных атомарности, согласованности, изолированности и сохранности данных) и WS-BusinessActivity (ослабляет изоляцию и атомарность); для координации деятельности транзакций используется WS-Coordination;
  • Business Transaction Protocol (BTP) 1.0 (CS) — состоит из атомов (слабо связанных, ослабляет изоляцию) и связей (ослабляет изоляцию и атомарность); обеспечивает собственный метод координации;
  • WS-Trust (IS) — построена на базе WS-Security, обеспечивает (через посредников или напрямую) выпуск, обмен, валидацию и распространение токенов безопасности в пределах доверительной области;
  • WS-SecureConversation (IS) — построена на базе WS-Security и WS-Trust; определяет механизмы определения и совместного использования безопасного контекста и получения сессионных ключей в таких контекстах;
  • WS-Federation (IS) — построена на базе WS-Trust; позволяет совместно использовать атрибуты и данные аутентификации в доверительных областях;
  • Liberty Alliance (IS) — построена на базе SAML и WS-Security; имеет назначение, сходное с целями WS-Federation.

Интерфейсы бизнес-уровеня. WSDL (Web Services Definition Language — язык определения Web-сервисов; CS) 1. 1 (2.0) — наиболее распространенный язык на этом уровне. Он определяет сервис как набор конечных точек, которые реализуют общий интерфейс, т.е. набор операций, связанных с сообщениями. WSDL не определяет последовательности обмена сообщениями.

Протоколы бизнес-уровеня. Три спецификации определяют допустимые последовательности обмена сообщениями между партнерами:

  • Web Services Choreography Interface 1.0 (CS) — добавляет в WSDL набор конструкций для определения бизнес-процессов;
  • Web Services Choreography Description Language (WS-CDL) 1.0 (CS) — предлагает набор конструкций для определения глобальной оркестровки сервисов;
  • WS-Business Process Execution Language (BPEL; CS-R) — определяет частные и открытые бизнес-процессы.

Политики и качественные свойства. В семействе WS-* с политиками и качественными свойствами связаны следующие спецификации:

  • WS-Policy (IS) — платформа и общий синтаксис для определения политик Web-сервисов (возможностей и требований);
  • WS-Policy Attachment (IS) — определяет два механизма подключения политики к сервису (встраивание в подчиненные элементы и внешнее подключение);
  • WS-PolicyAssertions (IS) — определяет набор общих положений политики, например шифрования текста, с использованием синтаксиса WS-Policy;
  • WS-SecurityPolicy (IS) — определяет набор общих положений политики для свойств безопасности, поддерживаемых WS-Security;
  • XML Access Control Markup Language (XACML) 2.0 (CS) — обеспечивает детальное выражение политик контроля над доступом для ресурсов на базе XML.

ebXML (CS)

Спецификации семейства ebXML претендуют на большую полноту, чем их аналоги из семейства WS-*, и фокусируются в основном на приложениях «бизнес-бизнес».

Обмен сообщениями. ebXML Messaging 2.0 (CS) — основная спецификация обмена сообщениями из семейства ebXML. Она основана на спецификациях SOAP и SOAP-Attachments. Спецификация CS расширяет протокол SOAP, гарантируя доставку сообщений, обеспечивает безопасность на уровне сообщения с применением SSL, XML-Signature и XML-Encryption, поддерживает синхронный и асинхронный обмен сообщениями.

Базовая координация. Спецификации BPSS (Business-process schema specifications) 1.01 (CS) обеспечивают базовую поддержку координации двусторонних атомарных транзакций между бизнес-партнерами. Спецификации BPSS не поддерживают двухфазной фиксации.

Интерфейсы. Разработку интерфейсов поддерживают две спецификации на базе XML:

  • Core components 1.90 (CS) — набор правил, руководящих принципов и словарей предметной области для определения типов данных, соглашений об именах и сложных структур данных;
  • Collaboration protocol profiles (CPP) 2.0 (CS) — синтаксис на базе XML для выражения возможностей, требований и спецификаций в профиле торгового партнера.

Протоколы. На уровне протоколов спецификации BPSS 1.01 (CS) обеспечивают набор настраиваемых спецификаций бизнес-процессов, хранящихся в бизнес-библиотеке. Кроме того, соглашения CPA (collaboration protocol agreements) 2.0 (CS) моделируют двусторонние условия и соглашения о сотрудничестве.

Политики и качественные свойства. На этом уровне CPP 2.0 (CS) не определяет конкретного языка для определения политик. Политики могут быть определены в CPP как общие возможности и требования партнеров.

Hamid Motahari Nezhad, Boualem Benatallah, Fabio Casati, Farouk Toumani, Web Services Interoperability Specifications, Computer, May 2006. IEEE Computer Society, 2006, All rights reserved. Reprinted with permission.