Web-сервисы: несуществующие стандарты

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

С наибольшим успехом приложения Web-сервисов эксплуатируются внутри предприятий, где они помогают объединять несовместимые системы. Как правило, основой такого объединения являются довольно простые вариации применения протокола SOAP (Simple Object Access Protocol) и языка описания Web-сервисов (Web Services Description Language, WSDL), кое-где дополненные доморощенными системами безопасности.

А вот существенной стандартизации Web-сервисов за это время не произошло.

Спецификации Web-сервисов

Многочисленность спецификаций Web-сервисов (часто обозначаемых собирательным названием WS-*) просто обескураживает. Большинство из них созданы коалицией архитекторов и разработчиков из компаний BEA Systems, IBM и Microsoft, но свой вклад в отдельные спецификации внесли и не столь крупные компании.

Существуют как минимум два набора спецификаций WS-* (msdn.microsoft.com/Webservices/understanding/specs/ и www-128.ibm.com/developerworks/views/webservices/ libraryview.jsp?type_by=Standards). Они охватывают почти все мыслимые темы, связанные с Web-сервисами: WS-Addressing (механизмы адресации), WS-Attachments (вложения), WS-BusinessActivity (координация длительных транзакций), WS-Coordination (координация приложений), WS-Discovery (поиск сервисов), WS-Enumeration (коллекции данных), WS-Eventing (управление событиями), WS-Federation (единая идентификация), WS-Inspection (инспектирование сервисов), WS-Manageability (управляемость), WS-MetadataExchange (обмен метаданными), WS-Notification (уведомление подписчиков), WS-PolicyFramework (управление политиками), WS-Provisioning (предоставление ресурсов), WS-ReliableMessaging (надежная доставка сообщений), WS-Resource (управление ресурсами), WS-Security (безопасность), WS-Topics (категории подписки), WS-Transactions (транзакции), WS-Transfer (передача данных).

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

WS-архитектура

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

Естественно, Microsoft, IBM, BEA Systems и другие компании, выпускающие WS-спецификации, имеют свои представления о том, какой должна быть архитектура стека Web-сервисов. И неудивительно, что их представления отличаются друг от друга. Не имея общеотраслевой архитектуры, фирмы «проталкивают» собственные решения. В некоторых вопросах они соглашаются между собой, в других расходятся. В результате список спецификаций WS-* представляет собой объединение конкурирующих частных архитектур, засоренное повторениями, частичными совпадениями и тупиковыми вариантами.

Рабочая группа по архитектуре Web-сервисов (Web Services Architecture working group, WSAWG) консорциума World Wide Web Consortium была создана в 2002 году. Многие из ее членов возлагали большие надежды на эту группу, поскольку было ясно, что общеотраслевая архитектура Web-сервисов поможет WS-стандартам развиваться в правильном направлении. К моменту завершения своей работы в начале 2004 года группа WSAWG сумела выпустить лишь рабочий документ [2], описывающий ряд архитектурных направлений, в которых удалось достичь некоторого прогресса. К сожалению, этот документ никак нельзя считать спецификацией архитектуры Web-сервисов.

Обреченность группы стала очевидной еще в самом начале ее деятельности, когда потребовались две итерации примерно по три месяца каждая для достижения согласия по основополагающему определению Web-сервиса. Причиной провала WSAWG отчасти послужили споры между теми, кто видел в Web-сервисах прежде всего «Web», и теми, кто упирал на «сервисы». Сторонникам «Web» вполне хватало Web-архитектуры REST (Representational State Transfer) [1], и группа WSAWG должна была просто вписать в нее Web-сервисы. Их противники ссылались на то, что Всемирная паутина изначально предназначена для интерактивной доставки гипертекстовых документов через браузер, вследствие чего совершенно не приспособлена для связи и интеграции приложений. Этот нерешенный спор продолжается и поныне.

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

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

Нужны ли все эти спецификации?

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

В начале 2004 года, например, две группы компаний (в одну из которых входила Microsoft, а в другую IBM) выпустили спецификации WS-Eventing и WS-Notification [4, 5]. Поскольку обе спецификации были направлены на поддержку Web-сервисов на основе событий, они существенно пересекались на концептуальном уровне, но, как и следовало ожидать, различались в деталях. К счастью, в данном случае конкурирующие группы продвигаются к соглашению, ибо впоследствии IBM вошла в число авторов спецификации WS-Eventing. Неясно, однако, удастся ли достигнуть согласия и в других перекрывающихся областях.

В ходе широкого обсуждения на страницах нескольких сетевых дневников в сентябре 2004 года отмечалось, что развитие других областей, таких как Internet и Всемирная паутина, также регламентируется огромным количеством спецификаций, но эти области не страдают от перекрытий и противоречий в стандартах. Например, Крис Феррис из IBM напоминает, что IETF (Internet Engineering Task Force, www.ietf.org) выпустила в общей сложности около 4 тыс. спецификаций RFC.

Однако их сравнение со спецификациями WS-* некорректно по нескольким причинам. Одна из них состоит в том, что первые спецификации RFC относятся к 1969 году, и в ряде случаев устаревшие спецификации заменялись новыми. Кроме того, не все они являются стандартами, часть из них — просто информационные документы. Важно также, что организация IETF открыта для всех, кто хочет участвовать в ее работе. Напротив, большая часть спецификаций WS-* подготовлена в закрытых группах, в основном состоящих из нескольких сотрудников крупных компаний наподобие IBM и Microsoft.

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

Продвижение к стандартизации

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

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

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

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

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

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

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

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

Литература

R.T. Fielding. Architectural Styles and the Design of Network-Based Software Architectures, doctoral dissertation, Dept. of Computer Science, Univ. of California, Irvine, 2000.
D. Booth et al. Web Services Architecture. W3C Working Group Note, 2004; www.w3.org/TR/ws-arch/.
L.F. Cabrera, K. Christopher, D. Box. An Introduction to the Web Services Architecture and Its Specifications, version 1.0, Microsoft, 2004.
S. Vinoski. Web Service Notifications. IEEE Internet Computing, vol. 8, no. 2, 2004.
S. Vinoski. More Web Service Notifications. IEEE Internet Computing, vol. 8, no. 3, 2004.

Стив Виноски (vinoski@ieee.org) — главный инженер по инновационному развитию продуктов компании IONA Technologies. В течение 16 лет занимался разработкой программного обеспечения промежуточного слоя, участвовал в создании стандартов группы Object Management Group и консорциума World Wide Web Consortium.