Обсудить на форуме

"Возня" по протоколу

Web-службы на сегодняшний день являются, пожалуй, одним из наиболее спорных и неоднозначных вопросов в полемике о создании и разработке распределенных систем. Цель этой и следующих статей - понять место Web-служб и то, как они будут развиваться в будущем. Мы поговорим о протоколах, моделях программирования, инструментальных средствах, о возможности взаимодействия приложений и о многом другом. Кроме того, мы попытаемся проанализировать все предложения использовать родственные спецификации конкурирующих Web-служб, например, WSDL, WSFL, XLANG, HTTPR, SOAPRP, UDDI, чтобы объяснить, какие из них, вероятно, окажутся полезными, и почему. Но сначала давайте попробуем дать определение понятию Web-служба.

В общем, все согласны с тем, что целью Web-службы является привлечение традиционной модели Web-программирования, которая проста и гибка, к решению задач, далеких от поставки пользовательского интерфейса тонкого клиента. Например, если бы потребовалось, чтобы традиционное приложение "толстого клиента" на Visual Basic получало бы доступ к данным на сервере от Solaris, эту проблему можно было бы решить с помощью технологий CORBA или же Java RMI. Однако, использовать протокол HTTP проще, поскольку все его понимают, и дешевле, так как практически любая "труба" его поддерживает. Единственное, что нужно сделать - отформатировать данные, которые будут посылаться вперед и назад, и технология XML как нельзя лучше для этого подходит. Итак, вы перенастраиваете клиентское Visual Basic приложение, чтобы посылать HTTP-запросы на основе XML на сервер Solaris, который обрабатывает их с помощью Java-сервлета (servlet). Java-сервлет извлекает данные, преобразует их в XML и возвращает результат. Приложение на Visual Basic разбирает (parse) полученный XML, выгружает данные и позволяет пользователю манипулировать ими, как ему удобно.

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

1. Использует стандартные высокоуровневые протоколы Интернет-связи, такие как: HTTP или SMTP.
2. Передает данные, используя XML-сообщения.
3. Описывает типы своих сообщений с помощью переносной системы типов, которая нейтральна как по отношению к языку, так и платформе.
4. Предоставляет возможность доступа к метаданным, описывающим сообщения, которые она принимает.

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

Итак, первое. Web-службы опираются на стандартные интернет-протоколы: HTTP и SMTP, потому что, во-первых, практически любая платформа поддерживает их, во-вторых, потому что вся инфраструктура Интернета - proxy-серверы, маршрутизаторы (router), шлюзы (gateway) и брандмауэры (firewall) - которые образуют сеть на физическом уровне - разработаны и сконфигурированы так, чтобы передавать и принимать эти протоколы.

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

Третье требование. Web-службы описывают свои сообщения в терминах системы, типы которой нейтральны по отношению к языку и платформе. Таким образом, улучшается определение точных, на уровне проводки, связей между Web-службами и их клиентами, что упрощает построение устойчивых распределенных систем, способных к взаимодействию. Выбрав XML Schema (XSD), вы выбираете систему типов, хотя потребуется разрешить некоторые конфликты, возникающие между XSD и частью спецификаций SOAP.

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

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

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

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

В результате предлагается масса фирменных "стандартов" и протоколов, часто конкурирующих друг с другом, что приводит к путанице и неразберихе в самих названиях спецификаций. Например, Microsoft и IBM определили свои собственные диалекты XML для описания того, как координировать сложные взаимодействия между многочисленными Web-службами: XLANG и WSFL (Web Service Flow Language), соответственно. В принципе, мы не против попыток разрешить сложные проблемы распределенной обработки информации. Если кому-нибудь удастся достигнуть поставленных целей и предоставить инструменты и технологии, позволяющие упростить построение распределенных систем, - честь им и хвала. Но, если двигаясь в этом направлении, мы принесем в жертву простоту и гибкость - именно то, что Web-службы должны использовать - мы окажемся там же, где и начинали, но только потратив массу денег и времени. У нас будут фирменные решения, которые не смогут взаимодействовать. Вряд ли стоит говорить о том, что это нельзя допустить.

Наше рабочее определение Web-службы - всего лишь попытка привлечь внимание к их простоте и гибкости. Разумеется, оно не охватывает всех аспектов рассматриваемого вопроса. Например, мы не совсем уверены, правильно ли требовать соответствия между спецификацией SOAP для форматирования сообщений и спецификацией W3C XML Schema для набора сообщений, когда имеется некоторая несовместимость между ними (т.е., SOAP, часть 5). Забегая вперед, отметим, что общество должно прийти к консенсусу о том, как разрешить эту и многие другие проблемы так, чтобы гибкость на уровне создания сообщений - действительно сильная сторона Web-служб - была бы повсеместно осознана.