© Copyright 2002 (c) Patrick Cooney и A List Apart
© перевод, Александр Качанов

Идея веб-сервисов была разработана такими гигантами компьютерной индустрии как Sun, Oracle, HP, Microsoft и IBM. В этой идее нет ничего нового, но это большой шаг вперед к упрощенному доступу к программам через сеть. Основываясь на стандартных форматах связи, веб-сервисы могут вообще поменять наше представление о том, как мы должны делать веб-сайты.

Благодаря веб-сервисам функции любой программы могут стать доступными через Интернет. Таким образом такие программы как PHP, ASP, JSP скрипты, JavaBeans, COM-объекты и все остальные наши любимые средства программирования могут теперь обращаться к какой-нибудь программе, работающей на другом сервере (т.е. к веб-свервису), и использовать ответ, полученный от нее на своем веб-сайте, или приложении.

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

Любой, кто хоть раз работал в последнее время с Hotmail, уже отчасти столкнулся с веб-сервисами: система аутентификации пользователей Passport - это один из сервисов, входящих в инициативу Microsoft .NET. пока он доступен бесплатно, так что создатели веб-сайтов могут запросто внедрить аутентификацию пользователей на своём сайте.

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

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

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

До этого многие компании разрабатывали свои собственные закрытые стандарты и форматы. А сейчас нам для работы нужно знать всего лишь простой XML (eXtensible Markup Language), который передается по старому знакомому протоколу HTTP. Это значит, что информация о работе веб-сервисов доступна для всех, и веб-разработчики, которые по роду профессии знакомы с этими технологиями, могут начать играться с веб-сервисами уже сегодня.

Разница между веб-сервисами и другими технологиями, с которыми разработчикам приходилось сталкиваться (например, DCOM, именованные каналы - named pipes, RMI) в том, что веб-сервисы основаны на открытых стандартах, ими легко овладеть, и эти стандарты широко поддерживаются на всех платформах Unix и Windows.

Протокол Simple Object Access Protocol (SOAP) является стандартным протоколом, разработанным W3C. Он определяет формат запросов к веб-сервисам.

Сообщения между веб-сервисом и его пользователем пакуются в SOAP-конверты (SOAP envelopes). Сообщения содержат либо запрос на осуществление какого-либо действия, либо ответ - результат выполнения этого действия. Конверт и его содержимое закодировано языком XML, и его достаточно просто понять. Вот как выглядит простой SOAP-запрос, который отправляется через HTPP к веб-сервису:

<env:Envelope
xmlns:env="http://www.w3.org/2001/06/soap-envelope">
<env:Body>
<m:ValidatePostcode
env:encodingStyle="http://www.w3.org/2001/06/soap-encoding"
xmlns:m="http://www.somesite.com/Postcode">
<Postcode>WC1A8GH</Postcode>
<Country>UK</Country>
</m:ValidatePostcode>
</env:Body>
</env:Envelope>

Ключевые элементы SOAP-конверта узнать достаточно просто: это два параметра (<postcode> ("почтовый индекс") и <country> ("страна")), которые содержатся внутри элемента под названием <ValidatePostcode>. Этот элемент является названием веб-сервиса, к которому мы обращаемся с запросом. Прочие данные в конверте, такие как кодировка текста и версия SOAP помогают веб-сервису правильно обработать запрос.

А ответ будет выглядеть вот так:

<env:Envelope
xmlns:env="http://www.w3.org/2001/06/soap-envelope" >
<env:Body>
<m:ValidatePostcodeResponse
env:encodingStyle="http://www.w3.org/2001/06/soap-encoding"
xmlns:m="http://www.somesite.com/Postcode">
<Valid>Yes</Valid>
</m:ValidatePostcodeResponse>
</env:Body>
</env:Envelope>

Это сообщение еще проще расшифровать. Элемент <ValidatePostcode> в нашем запросе поменялся на элемент <ValidatePostcodeResponse> в ответе на запрос. В этом элементе содержится только один элемент <Valid>, значение которого обозначает, верен наш почтовый индекс или нет. Таким образом с помощью волшебства SOAP мы создали запрос, который делает для нас полезную работу. В ответ через сеть мы получаем определенного вида ответ на языке XML.

Даже при всей простоте протокола SOAP пользы в веб-сервисах было бы немного, если бы у нас не было никакой возможности их найти. К счастью IBM, Microsoft и компания Ariba выступили с инициативой и создали проект Universal Description, Discovery and Integration (UDDI), который, как они надеются, станет общим каталогом всех веб-сервисов в Web-е.

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

Так как же мне найти нужный веб-сервис?

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

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

Вместо того, чтобы раскошеливаться на покупку базы данных, писать самому код, следить за целостностью и правильностью всех данных и отлаживать работу скриптов, я просто иду в каталог UDDI и ищу, нет ли там веб-сервиса, который мог бы сделать эту работу за меня. Придя на сайт http://www.uddi.org/, я запускаю поиск и нахожу прекрасный сервис от компании XYZ Corp.

Я внимательно рассматриваю определение формата веб-сервиса (определение записано на языке WSDL (Web Services Description Language), убеждаюсь, что сервис делает именно то, что мне нужно. Затем справляюсь у своих коллег о репутации компании XYZ Corp., узнаю, что она солидная, и затем обращаюсь к компании XYZ с вопросом о цене. Если цена на доступ к сервису доступна для моего бюджета, я пишу простую JSP-страницу для своего сайта, который вызывает веб-сервис компании XYZ Corp, и опля, на сайте появляется моментальная проверка почтового индекса.

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

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

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

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

Выбор инструментов для разработки веб-сервисов обширен. В него входят инструментарии таких компании как Sun (Open Net), Microsoft (.NET), HP (e-services), и IBM (Web Services). Существуют также инструментарии с открытыми исходными кодами (open source frameworks). Например, проект Mono Project стремится заменить собой инструментарий Microsoft .NET, предоставив систему компиляции (compilers), исполнения кода (runtime) и библиотек (libraries) для работы одних и тех же веб-сервисов на всех платформах, включая Unix.

Несмотря на многообразие серверов и средств разработки веб-сервисов, все они поддерживают один и тот же протокол SOAP, язык XML и систему UDDI.

Прежде чем я полностью откажусь от карьеры программиста и посвящу себя использованию веб-сервисов, я должен задать себе вопрос: "Уж слишком розовая картинка. Что в ней не так?". К сожалению, за великий потенциал веб-сервисов приходится платить определенную цену:

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

Patrick - веб-разработчик, живущий в Лондоне (Англия).