Веб-служба - это программа, к которой могут обращаться другие программы через Интернет (http). Например, предположим, что у вас есть функция, которая предоставляет текст в формате HTML. Цель приложения - это веб-браузер, который отображает результаты, и человек сможет легко прочитать этот текст на странице.
С другой стороны, целевой аудиторией веб-сервиса являются другие программы или другие веб-службы, которые потребляют данные, обслуживаемые веб-службой. Обычно вывод осуществляется на стандартном языке, который может быть понят другим программам. Возьмите приведенный выше пример, если веб-служба выводит текст в формате XML, тогда другие веб-службы, которые могут читать или понимать XML, могут использовать этот вывод.
Основным преимуществом веб-службы является то, что приложения могут быть написаны на любом языке, но они могут обмениваться данными и обмениваться данными друг с другом через веб-службу. Программные приложения, написанные на разных языках программирования и работающие на различных платформах, могут использовать веб-службы для обмена данными через Интернет (HTTP). Это взаимодействие (например, между Java и Python, или приложениями Windows и Linux) связано с использованием открытых стандартов (XML, SOAP, HTTP).
- SOAP (простой протокол доступа к объектам)
- UDDI (универсальное описание, обнаружение и интеграция)
- WSDL (язык описания веб-сервисов)
Сколько существует различных видов веб-служб?
В первую очередь, существуют два типа веб-служб, простой протокол доступа к объектам (SOAP) и репрезентативный перенос состояний (REST).
- Веб-служба SOAP принимает запрос в формате XML и генерирует вывод в формате XML.
- Веб-служба REST более универсальна и может принимать XML, а также JSON в качестве запроса и генерирует вывод в XML, а также в JSON или даже HTML
Подробнее данный вопрос может быть изучен на наших .
Заголовок топика – это действительно вопрос, т.к. я сам не знаю, что это и впервые попробую поработать с этим в рамках настоящей статьи. Единственное, что могу гарантировать, что код, представленный ниже, будет работать, однако мои фразы будут лишь предположениями и догадками о том, как я сам все это понимаю. Итак, поехали…
Введение
Начать надо с того, для чего создавалась концепция веб-сервисов. К моменту появления этого понятия в мире уже существовали технологии, позволяющие приложениям взаимодействовать на расстоянии, где одна программа могла вызвать какой-нибудь метод в другой программе, которая при этом могла быть запущена на компьютере, расположенном в другом городе или даже стране. Все этого сокращенно называется RPC (Remote Procedure Calling – удаленный вызов процедур). В качестве примеров можно привести технологии CORBA, а для Java – RMI (Remote Method Invoking – удаленный вызов методов). И все вроде в них хорошо, особенно в CORBA, т.к. с ней можно работать на любом языке программирования, но чего-то все же не хватало. Полагаю, что минусом CORBA является то, что она работает через какие-то свои сетевые протоколы вместо простого HTTP, который пролезет через любой firewall. Идея веб-сервиса заключалась в создании такого RPC, который будет засовываться в HTTP пакеты. Так началась разработка стандарта. Какие у этого стандарта базовые понятия:- SOAP . Прежде чем вызвать удаленную процедуру, нужно этот вызов описать в XML файле формата SOAP. SOAP – это просто одна из многочисленных XML разметок, которая используется в веб-сервисах. Все, что мы хотим куда-то отправить через HTTP, сначала превращается в XML описание SOAP, потом засовывается в HTTP пакет и посылается на другой компьютер в сети по TCP/IP.
- WSDL . Есть веб-сервис, т.е. программа, методы которой можно удаленно вызывать. Но стандарт требует, чтобы к этой программе прилагалось описание, в котором сказано, что «да, вы не ошиблись – это действительно веб-сервис и можно у него вызвать такие-то такие-то методы». Такое описание представляется еще одним файлом XML, который имеет другой формат, а именно WSDL. Т.е. WSDL – это просто XML файл описания веб-сервиса и больше ничего.
Общий подход
В веб-сервисах всегда есть клиент и сервер. Сервер – это и есть наш веб-сервис и иногда его называют endpoint (типа как, конечная точка, куда доходят SOAP сообщения от клиента). Нам нужно сделать следующее:- Описать интерфейс нашего веб-сервиса
- Реализовать этот интерфейс
- Запустить наш веб-сервис
- Написать клиента и удаленно вызвать нужный метод веб-сервиса
Сервер
Запустим IDEA и создадим новый проект Create New Project . Укажем имя HelloWebService и нажмем кнопку Next , далее кнопку Finish . В папке src создадим пакет ru.javarush.ws . В этом пакете создадим интерфейс HelloWebService: package ru. javarush. ws; // это аннотации, т.е. способ отметить наши классы и методы, // как связанные с веб-сервисной технологией import javax. jws. WebMethod; import javax. jws. WebService; import javax. jws. soap. SOAPBinding; // говорим, что наш интерфейс будет работать как веб-сервис @WebService // говорим, что веб-сервис будет использоваться для вызова методов @SOAPBinding (style = SOAPBinding. Style. RPC) public interface HelloWebService { // говорим, что этот метод можно вызывать удаленно @WebMethod public String getHelloString (String name) ; } В этом коде классы WebService и WebMethod являются так называемыми аннотациям и ничего не делают, кроме как помечают наш интерфейс и его метод, как веб-сервис. Это же относится и к классу SOAPBinding . Разница лишь в том, что SOAPBinding – это аннотация с параметрами. В данном случае используется параметр style со значением, говорящим, что веб-сервис будет работать не через сообщения-документы, а как классический RPC, т.е. для вызова метода. Давайте реализуем логику нашего интерфейса и создадим в нашем пакете класс HelloWebServiceImpl . Кстати, замечу, что окончание класса на Impl – это соглашение в Java, по которому так обозначают реализацию интерфейсов (Impl – от слова implementation, т.е. реализация). Это не требование и вы вольны назвать класс как хотите, но правила хорошего тона того требуют: package ru. javarush. ws; // таже аннотация, что и при описании интерфейса, import javax. jws. WebService; // но здесь используется с параметром endpointInterface, // указывающим полное имя класса интерфейса нашего веб-сервиса @WebService (endpointInterface = "ru.javarush.ws.HelloWebService" ) public class HelloWebServiceImpl implements HelloWebService { @Override public String getHelloString (String name) { // просто возвращаем приветствие return "Hello, " + name + "!" ; } } Запустим наш веб-сервис как самостоятельный сервер, т.е. без участия всяких Tomcat и серверов приложений (это тема отдельного разговора). Для этого в структуре проекта в папке src создадим пакет ru.javarush.endpoint , а в нем создадим класс HelloWebServicePublisher с методом main: package ru. javarush. endpoint; // класс, для запуска веб-сервера с веб-сервисами import javax. xml. ws. Endpoint; // класс нашего веб-сервиса import ru. javarush. ws. HelloWebServiceImpl; public class HelloWebServicePublisher { public static void main (String. . . args) { // запускаем веб-сервер на порту 1986 // и по адресу, указанному в первом аргументе, // запускаем веб-сервис, передаваемый во втором аргументе Endpoint. publish ("http://localhost:1986/wss/hello" , new HelloWebServiceImpl () ) ; } } Теперь запустим этот класс, нажав Shift+F10 . В консоли ничего не появится, но сервер запущен. В этом можно убедиться набрав в браузере строку http://localhost:1986/wss/hello?wsdl . Открывшаяся страница, с одной стороны, доказывает, что у нас на компьютере (localhost) запустился веб-сервер (http://) на порту 1986, а, с другой стороны, показывает WSDL описание нашего веб-сервиса. Если вы остановите приложение, то описание станет недоступно, как и сам веб-сервис, поэтому делать этого не будем, а перейдем к написанию клиента.Клиент
В папке проекта src создадим пакет ru.javarush.client , а в нем класс HelloWebServiceClient с методом main: package ru. javarush. client; // нужно, чтобы получить wsdl описание и через него // дотянуться до самого веб-сервиса import java. net. URL; // такой эксепшн возникнет при работе с объектом URL import java. net. MalformedURLException; // классы, чтобы пропарсить xml-ку c wsdl описанием // и дотянуться до тега service в нем import javax. xml. namespace. QName; import javax. xml. ws. Service; // интерфейс нашего веб-сервиса (нам больше и нужно) import ru. javarush. ws. HelloWebService; public class HelloWebServiceClient { public static void main (String args) throws MalformedURLException { // создаем ссылку на wsdl описание URL url = new URL ("http://localhost:1986/wss/hello?wsdl" ) ; // Параметры следующего конструктора смотрим в самом первом теге WSDL описания - definitions // 1-ый аргумент смотрим в атрибуте targetNamespace // 2-ой аргумент смотрим в атрибуте name QName qname = new QName ("http://ws.сайт/" , "HelloWebServiceImplService" ) ; // Теперь мы можем дотянуться до тега service в wsdl описании, Service service = Service. create (url, qname) ; // а далее и до вложенного в него тега port, чтобы // получить ссылку на удаленный от нас объект веб-сервиса HelloWebService hello = service. getPort (HelloWebService. class ) ; // Ура! Теперь можно вызывать удаленный метод System. out. println (hello. getHelloString ("JavaRush" ) ) ; } } Максимум комментариев по коду я дал в листинге. Добавить мне нечего, поэтому запускаем (Shift+F10). Мы должны в консоли увидеть текст: Hello, JavaRush! Если не увидели, то видимо забыли запустить веб-сервис.Заключение
В данном топике был представлен краткий экскурс в веб-сервисы. Еще раз скажу, что многое из того, что я написал – это мои догадки по поводу того, как это работает, и поэтому мне не стоит сильно доверять. Буду признателен, если знающие люди меня поправят, ведь тогда я чему-нибудь научусь. UPD.Мы отобрали 10 лучших веб-сервисов, обзоры которых публиковались в «Лайфхакере» в прошлом году. Эти инструменты помогают нам эффективно организовывать время и работать в команде, управлять своим бизнесом, приобретать новые знания и развивать свои способности, получать больше удовольствия от отдыха и развлечений. Попробуйте их в новом году и пусть ваша жизнь станет ярче и комфортнее!
Гениальный мэшап ifttt позволяет устанавливать причинно-следственную связь между событиями в различных веб-сервисах по принципу «Если это произошло в одном сервисе, то то произойдет в другом сервисе». Поддерживается более 20 сервисов, социальных сетей и технологий: Gmail и любая другая почта, RSS, Facebook, Twitter, Evernote, Dropbox, Google Reader, Google Talk, Foursquare, Flickr, Instapaper, ReadItLater, LinkedIn, YouTube и другие. Кроме того, событиями служат SMS, телефонные звонки, изменения котировок акций и даже изменение погоды в заданном регионе. Примеры автоматизированных процессов, созданных с помощью ifttt: «если в Google Reader пост отмечен звездочкой, то он сохраняется в Evernote», «если начался дождь в Нью-Йорке, то приходит уведомление об этом в SMS». А теперь представьте себе возможности ifttt в будущем «интернете вещей », когда разные электронные устройства смогут общаться друг с другом! ;) Впервые я узнал об этом сервисе от друга «Лайфхакера» Виктора Захарченко. Позже он также рассказывал о своем опыте использования ifttt в сольном выпуске подкаста «42» , посвященном продуктивности и управлению стартапами.
Bookmate - ваша личная электронная библиотека, книги из которой можно читать на компьютере и мобильных устройствах (iPhone, iPad, Android, Symbian). При этом происходит синхронизация данных между используемыми вами девайсами - приступив к чтению на компьютере, вы можете продолжить его на смартфоне или планшете с того места, где остановились. В фонде Bookmate хранится несколько тысяч бесплатных книг, множество книг доступны по подписке стоимостью всего 99 рублей в месяц. Если вы не найдете среди них нужной книги, вы можете загрузить ее в библиотеку самостоятельно. Сервис позволяет делиться с друзьями рекомендациями, видеть списки их чтения и брать книги с их книжных полок. Любителям чтения могу порекомендовать также замечательную социальную сеть книголюбов Goodreads ( в «Лайфхакере» c интересными дополнениями от Петра Диденко и Виктора Захарченко), которой уже почти год пользуюсь сам и о которой мы говорили в 40-ом выпуске подкаста «42» вместе с Петром Диденко и Виктором Захарченко.
Современные компании должны использовать новые технологии для повышения конкурентоспособности и стимулирования своего развития. Многие задачи учета и управления бизнесом можно отдавать на аутсорсинг, и во многих случаях удобным для ИП или ООО является использование таких облачных сервисов, как «Мое дело». Этот сервис - выгодная замена привычного аутсорсинга. С его помощью можно в полуавтоматическом режиме вести бухгалтерский учет, рассчитывать налоги, сдавать отчетность в государственные органы в электронном виде через интернет, получать экспертные консультации, за 15 минут создавать пакет документов, необходимых для регистрации ИП (а в скором времени появится возможность готовить документы и для регистрации ООО). Обратите также внимание на аналогичный сервис от компании «СКБ Контур» - электронный бухгалтер «Эльба ». Если вам интересна тема облачных технологий для бизнеса, то слушайте 54-ый выпуск подкаста «42» с участием Петра Диденко и Нины Горбуновой.
Еще одна важная категория облачных сервисов - системы управления проектами. Одной из лучших (и бесплатной) является TeamLab, достойный конкурент Basecamp и других популярных систем. TeamLab поставляется в трех решениях - в виде SaaS для использования в браузере сразу же после регистрации аккаунта; в виде открытого исходного кода, который можно самостоятельно дорабатывать под свои нужды и вкусы, чтобы затем развернуть систему на своих серверах; и в виде виртуальной машины с предустановленным порталом TeamLab на серверах Amazon. TeamLab включает в себя модули управления проектами, совместной работы, управления документами, календарь, CRM-систему (систему управления взаимоотношениями с клиентами). Менеджер по маркетингу TeamLab Нина Горбунова представляла эту систему в 54-ом выпуске подкаста «42» про облачные технологии для бизнеса.
Новый модный сервис Pinterest позволяет создавать красивые виртуальные доски с изображениями различных предметов, зданий, мест, интерьеров, блюд - всего того, что вы любите и хотите показать другим. Новые объекты добавляются на доски очень просто - с помощью букмарклета для браузеров или вручную через веб-интерфейс. В Pinterest вы можете следить за обновлениями виртуальных досок своих друзей, разглядывая интересные картинки в поисках идей, вдохновения и просто хорошего настроения. В качестве примера приведу мою доску «Гости подкаста „42“ » с фотографиями всех замечательных гостей, информацией об их деятельности и ссылками на выпуски подкаста с их участием.
С помощью сервиса для тайм-трекинга Yast можно отслеживать затраты времени на различные проекты и отдельные задачи, находить слабые места в своем рабочем графике и оптимизировать их. Сервис предназначен как для индивидуальных пользователей, так и для небольших команд. Счетчик времени при выполнении задачи запускается и останавливается одним щелчком мыши, а позже вы получаете подробные отчеты в разных разрезах. Тайм-трекеры являются очень полезными инструментами управления временем - не менее важными, чем менеджеры задач и календари. По своему опыту знаю, что личную эффективность можно радикально повысить, глубоко изучив свой рабочий график и уделив немного времени его оптимизации.
Moredays - онлайн-органайзер, стилизованный под бумажные планировщики и чем-то напоминающий легендарные Молескины. Главное его достоинство - изумительная красота. Дизайнеры постарались на славу и сделали один из самых красивых органайзеров в мире. При этом Moredays обладает довольно богатой функциональностью: можно управлять задачами, планировать время в календаре, хранить заметки, контакты, делиться отдельными страницами органайзера с другими людьми через Twitter, Facebook и Google+, синхронизировать данные с Evernote и Google Apps, а в скором времени появятся и клиенты для мобильных устройств.
Если вы - один из основателей Facebook, то любой ваш проект мгновенно становится известным. Так и случилось с системой управления проектами Asana Дастина Московица, со-основателя крупнейшей в мире социальной сети. Однако Asana заслуживает внимания не только из-за личности Дастина - разработчики создали простой и удобный сервис с приятным, но строгим интерфейсом. Asana подойдет для индивидуального использования и для работы в небольшой команде. Функциальность системы трудно назвать богатой, но, возможно, именно в этом и заключается одно из ее главных достоинств для тех, кому не требуются перегруженные функциями инструменты управления проектами. Asana синхронизируется с Google Calendar, Apple iCal и Microsoft Outlook, интегрируется с почтой, имеет клиенты для смартфонов и планшетов.
BO.LT предоставляет простую, но при этом удивительную возможность отредактировать по своему вкусу любую веб-страницу. Достаточно указать ее адрес и вы сможете очень легко, без знания HTML и прочих технологий веб-разработки, вносить любые изменения в текст и дизайн копии этой веб-страницы, а затем отправлять другим людям сокращенную ссылку на результат. Приглашенные к просмотру друзья или коллеги также могут редактировать данную веб-страницу. Сервис незаменим, когда требуется ясно представить внешний вид сайта после различных доработок, провести мозговой штурм по поиску новых идей для дизайна или показать друзьям веб-страницу со своими пояснительными комментариями. Можно переключиться в режим редактирования HТML-кода, чтобы получить еще большую свободу действий.
Уважаемые читатели, а какие веб-сервисы понравились вам в 2011 году? Какие из них вы можете порекомендовать нам для обзоров в «Лайфхакере»?
Web-сервис — это программное обеспечение, которое предоставляет платфор-менно-независимый доступ к своим данным другим программным продуктам через Интернет, с использованием XML и таких стандартов, как SOAP, WSDL и UDDI.
Для чего могут использоваться Web-сервисы на практике? Представьте фондовую биржу, серверы которой имеют полную информацию о текущих котировках всех ценных бумаг, оборачиваемых на данной бирже. Это очень важная информация, онлайн-доступ к которой может быть очень ценным и полезным для удаленных программных систем. Или другой более близкий простому человеку пример: сервер метеобюро может содержать информацию о погодных условиях в некотором регионе или на всей планете. Эта информация также может быть использована сторонними приложениями.
Многим часто приходилось видеть информеры погодных сайтов, однако это не самый удобный метод получения реальной информации для корпоративных приложений, так как он ограничивает возможцости оперирования получаемой информацией. С таким информером можно сделать только две вещи: "повесить" у себя на сайте или убрать его с сайта, если он там уже размещен. Но как быть с приложениями, которым необходимо получать исходные данные f сервера метеобюро и обрабатывать их для выполнения каких-либо сложных операций (например, для графического моделирования карт с нанесением соответствующей температуры на регионы)?
Для решения таких проблем сервер фондовой биржи или метеобюро может стать провайдером (поставщиком) Web-сервисов, а приложения, которые получают от них данные через Интернет, -— потребителями этих данных. Таким образом формируется архитектура клиент-сЬрвер, где поставщик данных является сервером, а потребитель — клиентом, при этом программное обеспечение сервера и клиента не обязательно должно быть совместимым, главное условие – поддержка Web-сервисов.
Обмен между сервером и клиентом производится по стандартным протоколам Интернет, таким, например, как HTTP. Web-сервис сам описывает себя и определяет API взаимодействия с ним. при этом элементы данного API автоматически преобразуются в языковые конструкции для того языка программирования, который использует клиентское приложение. Описание Web-сервисов происходит по спецификации WSDL (Web Services Description Language — язык описания Web-сервисов). Передача самих данных от сервера к клиенту производится в формате SOAP (Simple Object Access Protocol — простой протокол доступа к объектам).
Другими словами, клиентское приложение обращается к файлу WSDL по его URL, т.е. обычным GET-методом. При этом оно получает описание методов Web-сервиса и далее может использовать их как свои (т.е. без написания дополнительного кода на стороне клиента — Web-сервис становится как бы удаленным продолжением клиентской программы).
Александр Качанов
Идея веб-сервисов была разработана такими гигантами компьютерной индустрии как 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 к веб-сервису:
xmlns:m="http://www.somesite.com/Postcode">
Ключевые элементы SOAP-конверта узнать достаточно просто: это два параметра
(
А ответ будет выглядеть вот так:
xmlns:m="http://www.somesite.com/Postcode">
Это сообщение еще проще расшифровать. Элемент
Теперь об UDDI
Даже при всей простоте протокола 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), (e-services), и IBM (Web Services). Существуют также инструментарии с открытыми исходными кодами (open source frameworks). Например, проект Mono Project стремится заменить собой инструментарий Microsoft .NET, предоставив систему компиляции (compilers), исполнения кода (runtime) и библиотек (libraries) для работы одних и тех же веб-сервисов на всех платформах, включая Unix.
Несмотря на многообразие серверов и средств разработки веб-сервисов, все они поддерживают один и тот же протокол SOAP, язык XML и систему UDDI.
Минусы
Прежде чем я полностью откажусь от карьеры программиста и посвящу себя использованию веб-сервисов, я должен задать себе вопрос: "Уж слишком розовая картинка. Что в ней не так?". К сожалению, за великий потенциал веб-сервисов приходится платить определенную цену:
- Использование XML в качестве формата передачи данных приводит к тому, что ваши сообщения будут очень большими по размеру: сами теги XML занимают много места, а это накладывает на нас определенную нагрузку по созданию, передаче и интерпретации сообщений.
- Так как мы используем удаленные компьютеры для выполнения определенных функций, мы полностью полагаемся на Интернет, что создает слишком много ненадежных звеньев в цепи между нашим веб-сервером и веб-сервисом.
- Сейчас лишь немногие компании создают веб-сервисы, и немногие компании ими пользуются. На отладку и улучшение системы веб-сервисов еще требуется длительное время.
- Система лицензирования и взимания платежей за пользование веб-сервисами еще должна быть принята разработчиками. Из-за того, что веб-сервисов еще слишком мало, большинство компаний пытается провести на своих потенциальных клиентов хорошее впечатление намеренно снижая стоимость услуг и предлагая благоприятные условия лицензирования. Должно еще пройти какое-то время, прежде чем будет выяснена реальная стоимость услуг веб-сервисов.
Когда же веб-сервисы займут свое место и станут доступны всем, они станут неоценимой помощью для веб-разработчиков. Они дадут нам гибкий доступ ко всей мощи всех компьютеров Сети. Пришло время для тех, кто делает веб-сайты, заинтересоваться веб-сервисами и узнать побольше о том, что они могут от них получить.
