Наступающий 2006 год станет рекордным годом для Web-сервисов в общем, и Java Web-сервисов в частности. Разработчики получают доступ к новым шаблонам третьего поколения, обеспечивающим гораздо лучшую поддержку doc/lit SOAP и перспективные улучшения рабочих характеристик. В то же время, стандарты WS-* наконец начинают приобретать законченный вид обычного набора интероперабельных слоев, расширяющих SOAP и WSDL и соответствующих основным корпоративным требованиям.
В первой части публикаций, посвященных Web-сервисам Java, я рассмотрю, как состояние Web-сервисов на сегодняшний день, так и основные изменения, планируемые в 2006, а также опишу взаимосвязь и взаимодейстаие новых шаблонов и технологий. В следующих статьях будут подробно рассмотрены многие из этих шаблонов и технологий с тем, чтобы держать вас в курсе новейших разработок в данной области, а также познакомить с тем, как они могут быть использованы в ваших программных проектах.
Подготовка почвы
Прошло шесть лет после выхода спецификации SOAP 1.0. Задолго до появления спецификации SOAP разработчики обменивались XML-сообщениями посредством протоколов интернет, но введение SOAP обещало формализацию этой техники и обеспечивало лучшую интероперабильность. SOAP также предоставлял возможности для удобного расширения, чтобы можно было добавлять в инфраструктуру функциональные средства более высокого уровня для усовершенствования обмена XML-сообщениями в будущем. Спецификация WSDL, вышедшая вскоре после SOAP, привнесла стандартизированное представление метаданных Web-сервисов. Основные поставщики ПО быстро поняли, каким потенциалом обладает сочетание SOAP и WSDL, и в течение следующих нескольких лет казалось, Web-сервисы на базе SOAP будут технологией будущего.
Сложности, связанные с soap и wsdl
Несмотря на быстрое распространение SOAP+WSDL в отрасли, существует ряд проблем, препятствующих достижению SOAP той популярности, которой многие ожидали. Первой такой проблемой является оперативная совместимость. Хотя оперативная совместимость явилась краеугольным камнем привлекательности SOAP, ее реализация не оправдала ожиданий. Изначально это произошло по причине ориентации Web-сервисов на стиль rpc/encoded (известный также как rpc/enc), где объектная модель преобразуется в XML, а затем восстанавливается на принимающей стороне. Это автоматическое двустороннее преобразование делает rpc/enc простым в использовании (до тех пор, пока вы используете относительно простые структуры данных, поддерживаемые им), но результатом имеет XML, не пригодный для других целей. Более того, различия в поддержке языков программирования и платформ приводят к несовместимости программных реализаций.
Сейчас при разработке Web-сервисов хорошим тоном считается отказ от использования стиля rpc/enc в пользу стиля document/literal (doc/lit). В doc/lit, форматы сообщений XML определены схемой W3C XML. Теоретически этот ход должен был снять любые проблемы оперативной совместимости, поскольку схема определяет реальную структуру XML, а тип обработки этого XML оставлен на усмотрение платформ. Практически разные уровни поддержки для чрезвычайно сложной схемы W3C порождают ряд других проблем оперативной совместимости.
Проблемы совместимости как для более раннего rpc/enc, так и для разработанного гораздо позже doc/lit осложняются отсутствием подтверждения приема сообщения. Это особенно актуально для doc/lit, где интегрированная среда поддерживает разные стандарты схем разного содержания без указания отсутствующих элементов. Даже там, где разные среды поддерживают определенные функции схемы, их реализация часто неполная и порождает проблемы оперативной совместимости при их использовании. Частично переход к doc/lit был обусловлен желанием использовать стандартные корпоративные или промышленные схемы. При проектировании таких схем обычно не учитывается их использование в Web-сервисах, поэтому они часто имеют функциональные характеристики, слабо поддерживаемые средами SOAP.
Другая проблемная область Web-сервисов SOAP - это постоянное смешение над-стуктурных расширений и базовой обработки SOAP - дополнительные слои обработки, применимые для широкого спектра Web-сервисов. Дизайн SOAP позволяет легко добавлять такие расширения, но они обычно приносят пользу лишь тогда, когда поддерживаются несколькими средами. Это условие требует всеотраслевого сотрудничества, что труднодостижимо. Даже наиболее фундаментальные расширения, для таких функций как подсоединение и безопасность, разрабатывались в течение ряда лет и все еще поддерживаются далеко не всеми средами.
Альтернатива soap
Кроме описанных в предыдущем разделе проблем с оперативной совместимостью и стандартизацией, ограничивающих практичность Web-сервисов SOAP, сами среды SOAP также зачастую сложно настроить и нелегко использовать. Такая комбинация ограничения преимуществ и значительной сложности побуждает многих разработчиков к поиску более простых альтернатив SOAP. Большая часть "движения сопротивления" SOAP связана с технологией REST. Строго говоря, REST это формализация основных правил протокола HTTP, которые применимы к Web-сервисам. На практике движение REST часто оставляет в стороне формализацию и охватывает все, что позволяет передавать документы XML через HTTP без надстройки SOAP, по существу кооптируя идею о прямом обмене документами XML, которая предшествовала SOAP.
REST гораздо менее претенциозна, чем SOAP. REST в своей основе ограничена использованием HTTP в качестве транспортного слоя (хотя сходные подходы могут использоваться и для других протоколов передачи данных), тогда как SOAP теоретически является транспортно-агностической (хотя ее широкое применение объясняется использованием протокола передачи данных HTTP). REST не имеет прямых способов добавления инфраструктурных расширений - но лишь когда SOAP действительно станет позволять добавление таких расширений, это ограничение можно будет рассматривать как недостаток.
Поскольку REST менее претенциозна, чем SOAP, нет необходимости использовать какой-либо фреймовый код для реализации клиента или сервера, поэтому разработчикам не нужно разбираться в сложностях инфраструктуры. Согласующим фактором является то, что им действительно нужно реализовать обработку HTTP и XML напрямую, но многие обработчики уже хорошо знакомы с этими технологиями. Прямая обработка XML может даже быть преимуществом, поскольку позволяет разработчикам выбирать из более широкого диапазона средств обработки, чем предлагаемый инфраструктурой SOAP.
Итак, не пора ли попрощаться с SOAP и перейти к более простой альтернативе - REST? Возможно, это практически осуществимо для многих видов приложений Web-сервисов, поэтому я не стану отказываться сразу от этой идеи. Однако существуют другие приложения, в частности на корпоративном уровне, требующие скорее добавленной инфраструктуры и транспортного агностицизма, которые SOAP только обещает разработать. Переход к REST будет означать, что для этих приложений необходимо будет напрямую реализовать такие функции как безопасность, транзакции, и координация, поскольку они не будут обеспечены инфраструктурой. Большинство корпоративных приложений скорее предпочтут обойтись без Web-сервисов, чем затратить такие усилия не преодоление этих трудностей.
Но, также, как и в кино, хотя ситуация выглядит действительно безнадежной для SOAP, появляется шанс на спасение, связанный с появлением инфраструктур нового поколения. Эти инфраструктуры позволяют разработку новых возможностей SOAP, делают доступным весь диапазон SOAP приложений Web-сервисов, в то же время значительно улучшая интероперабельность Web-сервисов doc/lit.