Организация работы Web-сервисов. Веб-сервисы

Валентин Колесов
разработчик красноярского отделения санкт-петербургской компании "Астрософт", сертифицированный специалист Microsoft (MCSD, MCSE, MCDBA)
[email protected]

Демонстрация работы SOAP на примере написания Web-сервера

Что такое SOAP

Широко распространенные в настоящее время технологии удаленного вызова методов (DCOM, CORBA/IIOP и RMI) довольно сложны в настройке и организации взаимодействия. Это влечет за собой трудности в эксплуатации и функционировании распределенных систем (проблемы безопасности, неудобства транспорта через брандмауэры и т. д.). Многие проблемы удалось решить благодаря созданию SOAP (Simple Object Access Protocol, простой протокол доступа к объектам), простого протокола, основанного на XML и служащего для обмена сообщениями в распределенных средах (WWW). Протокол предназначен для создания Web-сервисов и удаленного вызова методов. SOAP можно использовать в сочетании с разными транспортными протоколами, включая HTTP, SMTP и др.

Что такое Web-сервисы

Web-сервисами мы называем активный контент, реализующий некоторую функциональность, и данные, расположенные на Web-серверах и предоставляемые для использования внешним приложениям. Web-сервисы полностью независимы от языка и платформы реализации. Внешние приложения работают с сервисами посредством стандартных протоколов и форматов данных. Технология Web-сервисов является краеугольным камнем программной модели Microsoft .NET.

Для демонстрации возможностей SOAP в статье использована недавно вышедшая реализация SOAP Toolkit версии 2.0 производства Microsoft. Следует заметить, что текущая версия Toolkit заметно отличается от предыдущей (Microsoft SOAP Toolkit for Visual Studio 6.0) и от бета-версии SOAP Toolkit 2.0.

Объектная модель SOAP Toolkit предоставляет как низкоуровневые, так и высокоуровневые интерфейсы (SOAPClient, SOAPServer), скрывающие от программиста всю "внутреннюю кухню" - разбор и формирование пакетов, вызов методов и т. п. С помощью этих интерфейсов можно весьма элегантным образом использовать Web-сервисы в разрабатываемых приложениях. Объект SOAPClient выступает в роли посредника (proxy), предоставляющего интерфейс Web-сервиса и позволяющего работать с ним как с обычным COM-объектом (рис. 1).

1. Клиентское приложение создает экземпляр объекта SOAPClient.
2. SOAPClient читает файлы описания методов Web-сервиса (на языках WSDL и Web Services Meta Language, WSML). Эти файлы могут храниться и на стороне клиента.
3. Клиентское приложение, используя возможности позднего связывания методов объекта SOAPClient, вызывает метод сервиса. SOAPClient формирует пакет запроса (SOAP Envelope) и отправляет его на сервер. Можно применить любой транспортный протокол, но, как правило, используется HTTP.
4. Серверное приложение Listener (это может быть ISAPI-приложение или ASP-страница) принимает пакет, создает объект SOAPServer и передает ему пакет запроса. Помимо этого Listener обрабатывает HTTP-пакеты от клиента, отправляет клиенту пакеты с результатом работы сервиса, обрабатывает ошибки и использует функциональность SOAP-объектов.
5. SOAPServer читает описание Web-сервиса, загружает описание и пакет запроса в деревья XML DOM.
6. SOAPServer вызывает метод объекта или приложения, реализующего сервис.
7. Результаты выполнения метода или описание ошибки конвертируются объектом SOAPServer в пакет ответа и отправляются клиенту.
8. Объект SOAPClient проводит разбор принятого пакета и возвращает клиентскому приложению результаты работы сервиса или описание возникшей ошибки.

WSDL-файл - это документ в формате XML, описывающий методы, предоставляемые Web-сервисом, а также параметры методов, их типы, названия и местонахождение сервиса Listener. Мастер SOAP Toolkit автоматически генерирует этот документ, фрагмент которого приведен ниже:

Тег Envelope должен быть корневым элементом пакета. Элемент Header не обязателен, а Body должен присутствовать и быть прямым потомком элемента Envelope. В случае ошибки выполнения метода сервер формирует пакет, содержащий в теге Body элемент Fault, который содержит подробное описание ошибки.

Если вы пользуетесь высокоуровневыми интерфейсами SOAPClient, SOAPServer, то вам не придется вдаваться в тонкости формата пакета, но при желании можно воспользоваться низкоуровневыми интерфейсами или же вообще создать пакет "вручную", используя любой язык программирования.

Объектная модель SOAP Toolkit дает возможность работать с объектами низкоуровневого API:

• SoapConnector - обеспечивает работу с транспортным протоколом для обмена SOAP-пакетами.
• SoapConnectorFactory - обеспечивает метод создания коннектора для транспортного протокола, указанного в WSDL-файле (тег).
• SoapReader - читает SOAP-сообщения и строит деревья XML DOM.·
• SoapSerializer - содержит методы создания SOAP-сообщения.·
• IsoapTypeMapper, SoapTypeMapperFactory - интерфейсы, позволяющие работать со сложными типами данных.

С помощью объектов высокоуровневого API можно передавать данные только простых типов (int, string, float и т. п.), но спецификация SOAP 1.1 допускает работу с более сложными типами данных, например с массивами, структурами, списками и их комбинациями. Для работы с такими типами приходится использовать интерфейсы IsoapTypeMapper и SoapTypeMapperFactory.

Пример

Чтобы продемонстрировать работу SOAP, напишем несложный Web-сервис, который будет уметь складывать и вычитать числа. Для работы серверного приложения потребуется пакет IIS 5 в среде Windows 2000 или IIS4 на Windows NT 4.0 Service Pack 6, а также установленный SOAP Toolkit 2.0.

Требования клиентского приложения - ОС Microsoft Windows 98/Me или Windows NT 4.0 Service Pack 6/2000 Service Pack 1, а также установленный SOAP Toolkit 2.0.

Создание сервера

Откройте в VB новый проект ActiveX DLL. Измените название класса на SOAPClass, а имя проекта - на SOAPProj.

В классе создайте следующие методы:

В следующем окне Мастера можно выбрать методы, которые войдут в Web-сервис. В данном случае выберите все методы. Затем укажите, где будет находиться Web-приложение (например, http://wsd010/soap/), задайте тип приложения Listener (ASP или ISAPI), выберите ASP, формат схемы (по умолчанию). Укажите путь, где будут находиться файлы описания Web-сервиса, и кодировку. После окончания работы Мастера в Web-каталоге появятся файлы ASP, WSDL и WSML - это Listener для ASP и описания сервиса (см. листинги 1-3).

Осталось только настроить права доступа к Web-приложению - желательно установить NT Challenge/Response authentication. На этом работа по созданию сервера закончена.

Создание клиента

Откройте в VB новый проект Standard EXE. В меню Project/References сделайте ссылку на библиотеку Microsoft SOAP type library. Создайте на форме кнопку, в обработчике нажатия кнопки напишите следующий код:

Dim SoapClient As New SoapClient SoapClient.mssoapinit "http://wsd010/soap/SOAPService.wsdl" MsgBox SoapClient.AddNumbers(4, 3) MsgBox SoapClient.SubtractNumbers(3, 2)

Не забудьте изменить адрес Web-сервера и путь к WSDL-файлу во второй строке на адрес и путь к вашему Web-сервису.

После создания объекта SOAPClient его надо инициализировать - указать путь к документу описания Web-сервиса. После инициализации у объекта появятся методы Web-сервиса. С ними можно работать как с обычным COM-объектом.

С помощью замечательной утилиты MsSoapT.exe (Trace Utility), входящей в Toolkit, можно просматривать в режиме реального времени пакеты, идущие от клиента к серверу и обратно. Для этого надо в WSDL-файле найти тег и вместо строки типа http://wsd010/soap/SOAPService.ASP написать http://wsd010:8080/soap/SOAPService.ASP, то есть указать порт 8080. После этого нужно запустить утилиту трассирования и принять настройки по умолчанию, а затем создать новый объект Formatted Trace. Теперь все SOAP-пакеты работы с Web-сервисом доступны для оперативного просмотра. Если трассировщик не загружен, то в нужно убрать указание порта 8080. На рис. 4 приведено содержимое пакета запроса на выполнение метода SubstractNumbers.

А пакет ответа выглядит следующим образом:

1

Так выглядит пакет сервера, пришедший в ответ на запрос некорректного формата:

SOAP-ENV:Server Connector - Bad request to the server. -2146823238 800a13ba

Дополнительная информация по теме

http://msdn.microsoft.com/webservices/ и http://msdn.microsoft.com/soap/ - последние новости о SOAP и Web-сервисах от Microsoft. Там же можно найти свежие версии ПО.

http://www.vbxml.com/soap/ - много полезной информации для разработчиков. Есть презентации и учебники по SOAP.

http://www.w3.org/TR/SOAP/ - спецификация SOAP от W3C.

http://www.w3.org/TR/wsdl - сведения о стандарте Web Services Definition Language (WSDL) 1.1/

http://microsoft.public.xml.soap - в этой конференции специалисты помогут решить сложные проблемы программирования SOAP.

Листинг 1. Код Listener для ASP <%@ LANGUAGE=VBScript %> <% Option Explicit On Error Resume Next Response.ContentType = "text/xml" Dim SoapServer If Not Application("SoapServerInitialized") Then Application.Lock If Not Application("SoapServerInitialized") Then Dim WSDLFilePath Dim WSMLFilePath WSDLFilePath = Server.MapPath("SOAPService.wsdl") WSMLFilePath = Server.MapPath("SOAPService.wsml") Set SoapServer = Server.CreateObject("MSSOAP.SoapServer") If Err Then SendFault "Cannot create SoapServer object. " & Err.Description SoapServer.Init WSDLFilePath, WSMLFilePath If Err Then SendFault "SoapServer.Init failed. " & Err.Description Set Application("SOAPServiceServer") = SoapServer Application("SoapServerInitialized") = True End If Application.UnLock End If Set SoapServer = Application("SOAPServiceServer") SoapServer.SoapInvoke Request, Response, "" If Err Then SendFault "SoapServer.SoapInvoke failed. " & Err.Description Sub SendFault(ByVal LogMessage) Dim Serializer On Error Resume Next " "URI Query" logging must be enabled for AppendToLog to work Response.AppendToLog " SOAP ERROR: " & LogMessage Set Serializer = Server.CreateObject("MSSOAP.SoapSerializer") If Err Then Response.AppendToLog "Could not create SoapSerializer object. " & Err.Description Response.Status = "500 Internal Server Error" Else Serializer.Init Response If Err Then Response.AppendToLog "SoapSerializer.Init failed. " & Err.Description Response.Status = "500 Internal Server Error" Else Serializer.startEnvelope Serializer.startBody Serializer.startFault "Server", "The request could not be processed due to a problem in the server. Please contact the system administrator. " & LogMessage Serializer.endFault Serializer.endBody Serializer.endEnvelope If Err Then Response.AppendToLog "SoapSerializer failed. " & Err.Description Response.Status = "500 Internal Server Error" End If End If End If Response.End End Sub %>

Листинг 2. Код файла WSDL

Листинг 3. Код файла WSDL

19 ответов

Простое определение: веб-служба - это функция, к которой могут обращаться другие программы через Интернет (Http). Чтобы немного уточнить, когда вы создаете веб-сайт на PHP, который выводит HTML, его целью является браузер и, в дополнение, человек, читающий страницу в браузере. Веб-сервис не предназначен для людей, а скорее для других программ.

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

Полное определение, очевидно, более сложное, но вы попросили простой английский.

Упрощенное, нетехническое объяснение: Веб-сервлет позволяет PROGRAM разговаривать с веб-страницей, вместо того чтобы использовать ваш браузер для открытия веб-страницы.

Пример: Я могу перейти на maps.google.com и ввести свой домашний адрес, а также посмотреть, где я живу в своем браузере.

Но что, если вы пишете компьютерную программу, где вы хотите взять адрес и показать симпатичную карту, точно так же, как карты Google?

Ну, вы могли бы написать совершенно новую программу сопоставления с нуля, или вы могли бы назвать веб-службу, которую карты Google предоставляют, отправить ей адрес, и она вернет графическую карту местоположения, которую вы можете отобразить в своем программа.

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

Да, это простой веб-сервис.

Веб-сервисы - это не что иное, как механизм запроса/ответа, который позволяет клиенту удаленно получать доступ/изменять данные. Существуют официальные стандарты для веб-сервисов (SOAP, SOA и т.д.), Но ваша простая страница также является сервисом.

Основной недостаток печати на странице - это то, что ваша служба вернет HTML. Предпочтительными форматами данных являются JSON и XML, поскольку большинство клиентских фреймворков (и серверных фреймворков) разработаны с использованием JSON и XML.

Итак, если вы изменили свой сервис для возврата:

some random number

... some random number

то это было бы более полезно для большинства клиентов

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

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

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

Примерами веб-сервисов являются такие вещи, как Weather.com, предоставляющие информацию о погоде, которую вы можете использовать на своем сайте, или ИБП, предоставляющий метод запроса кавычек или отслеживания пакетов.

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

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

Веб-сервисы являются ключевым компонентом в "mashups". Mashups - это когда информация с многих сайтов автоматически агрегируется в новый и полезный сервис. Например, есть сайты, которые объединяют Карты Google с информацией о полицейских отчетах, чтобы дать вам графическое представление о преступности в вашем районе. Другим типом mashup было бы получение реальных данных о запасах, предоставляемых другим сайтом, и объединение их с поддельным торговым приложением для создания "рыночной игры" на фондовом рынке.

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

Надеюсь, это поможет!

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

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

Введите веб-службы.

Веб-сервис - это то, что веб-сайт предлагает предложить тем, кто хочет читать, обновлять и/или удалять данные с вашего сайта. Вы можете назвать это "бэкдором" для своих данных. Вместо того, чтобы представлять данные как часть веб-страницы, она предоставляется заранее определенным образом, где некоторые из наиболее популярных - это XML и JSON. Существует несколько способов общения с веб-сервисом, некоторые используют SOAP, другие - веб-службы REST"а и т.д.

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

Лучшее объяснение на английском языке объясняется аналогией:

• Веб-страницы позволяют людям общаться и сотрудничать друг с другом.
• Веб-службы позволяют программам общаться и сотрудничать друг с другом.

Ваш пример PHP - это веб-сервис по этому определению, потому что вывод может быть использован другой программой. Но на самом деле HTML-скребок экрана не является надежным или поддерживаемым способом создания веб-сервисов.

Веб-сервис представляет собой набор открытых протоколов и стандартов, используемых для обмена данными между приложениями или системами. Программные приложения, написанные на разных языках программирования и работающие на разных платформах, могут использовать веб-службы для обмена данными по компьютерным сетям, таким как Интернет, способом, аналогичным межпроцессорной коммуникации на одном компьютере. Эта совместимость (например, между Java и Python, или приложениями Windows и Linux) связана с использованием открытых стандартов (XML, SOAP, HTTP).

Все стандартные веб-службы работают с использованием следующих компонентов:

• SOAP (протокол простого доступа к объектам)
• UDDI (универсальное описание, обнаружение и интеграция)
• WSDL (язык описания веб-служб)

Он работает примерно так:

Webservice - это технология, посредством которой два или более удаленных веб-приложения взаимодействуют друг с другом по сети/Интернету. Он может быть реализован с использованием Java,.net, PHP и т.д.

Особенности веб-службы: -

Операционная система предоставляет интерфейс GUI (и CLI), с которым вы можете взаимодействовать. Он также предоставляет API, с которым вы можете взаимодействовать с программным обеспечением.

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

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

Simple way to explain web service is::

• Веб-сервис - это способ связи между двумя электронными устройствами по Всемирной паутине.
• Его можно назвать процессом, который программист использует для связи с сервером.
• Для вызова этого процесса программист может использовать SOAP и т.д.
• Веб-службы создаются поверх открытых стандартов, таких как TCP/IP, HTTP

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

Поскольку @Vincent Ramdhanie сказал, что веб-сервис не предназначен для просмотра/потребления конечным пользователем, а другой программы. Таким образом, техническая логика в вашей программе будет:

В случае выполнения нормальной программы

User on website -> HTML/JS/JQuery etc -> give me a random number ->ur program

ur program -> generate random number -> generate HTML and encapsulate o/p -> go back to user

Веб-служба - это программа, к которой могут обращаться другие программы через Интернет (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

Подробнее данный вопрос может быть изучен на наших .

Идея веб-сервисов была разработана такими гигантами компьютерной индустрии как 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:env="http://www.w3.org/2001/06/soap-envelope">

xmlns:m="http://www.somesite.com/Postcode">
WC1A8GH
UK

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

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

Xmlns:env="http://www.w3.org/2001/06/soap-envelope" >

Env:encodingStyle="http://www.w3.org/2001/06/soap-encoding"
xmlns:m="http://www.somesite.com/Postcode">
Yes

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

Теперь об UDDI

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

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

Как это все работает

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

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

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

Вместо того, чтобы раскошеливаться на покупку базы данных, писать самому код, следить за целостностью и правильностью всех данных и отлаживать работу скриптов, я просто иду в каталог UDDI и ищу, нет ли там веб-сервиса, который мог бы сделать эту работу за меня. Придя на сайт 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.

Минусы

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

• Использование XML в качестве формата передачи данных приводит к тому, что ваши сообщения будут очень большими по размеру: сами теги XML занимают много места, а это накладывает на нас определенную нагрузку по созданию, передаче и интерпретации сообщений.
• Так как мы используем удаленные компьютеры для выполнения определенных функций, мы полностью полагаемся на Интернет, что создает слишком много ненадежных звеньев в цепи между нашим веб-сервером и веб-сервисом.
• Сейчас лишь немногие компании создают веб-сервисы, и немногие компании ими пользуются. На отладку и улучшение системы веб-сервисов еще требуется длительное время.
• Система лицензирования и взимания платежей за пользование веб-сервисами еще должна быть принята разработчиками. Из-за того, что веб-сервисов еще слишком мало, большинство компаний пытается провести на своих потенциальных клиентов хорошее впечатление намеренно снижая стоимость услуг и предлагая благоприятные условия лицензирования. Должно еще пройти какое-то время, прежде чем будет выяснена реальная стоимость услуг веб-сервисов.

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

Перевод: Александр Качанов (http://webmascon.com)

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

Введение

Начать надо с того, для чего создавалась концепция веб-сервисов. К моменту появления этого понятия в мире уже существовали технологии, позволяющие приложениям взаимодействовать на расстоянии, где одна программа могла вызвать какой-нибудь метод в другой программе, которая при этом могла быть запущена на компьютере, расположенном в другом городе или даже стране. Все этого сокращенно называется RPC (Remote Procedure Calling – удаленный вызов процедур). В качестве примеров можно привести технологии CORBA, а для Java – RMI (Remote Method Invoking – удаленный вызов методов). И все вроде в них хорошо, особенно в CORBA, т.к. с ней можно работать на любом языке программирования, но чего-то все же не хватало. Полагаю, что минусом CORBA является то, что она работает через какие-то свои сетевые протоколы вместо простого HTTP, который пролезет через любой firewall. Идея веб-сервиса заключалась в создании такого RPC, который будет засовываться в HTTP пакеты. Так началась разработка стандарта. Какие у этого стандарта базовые понятия:

1. SOAP . Прежде чем вызвать удаленную процедуру, нужно этот вызов описать в XML файле формата SOAP. SOAP – это просто одна из многочисленных XML разметок, которая используется в веб-сервисах. Все, что мы хотим куда-то отправить через HTTP, сначала превращается в XML описание SOAP, потом засовывается в HTTP пакет и посылается на другой компьютер в сети по TCP/IP.
2. WSDL . Есть веб-сервис, т.е. программа, методы которой можно удаленно вызывать. Но стандарт требует, чтобы к этой программе прилагалось описание, в котором сказано, что «да, вы не ошиблись – это действительно веб-сервис и можно у него вызвать такие-то такие-то методы». Такое описание представляется еще одним файлом XML, который имеет другой формат, а именно WSDL. Т.е. WSDL – это просто XML файл описания веб-сервиса и больше ничего.

Почему так кратко спросите вы? А по подробней нельзя? Наверное можно, но для этого придется обратиться к таким книгам как Машнин Т. «Web-сервисы Java». Там на протяжении первых 200 страниц идет подробнейшее описание каждого тега стандартов SOAP и WSDL. Стоит ли это делать? На мой взгляд нет, т.к. все это на Java создается автоматически, а вам нужно лишь написать содержимое методов, которые предполагается удалено вызывать. Так вот, в Java появился такой API, как JAX-RPC. Если кто не знает, когда говорят, что в Java есть такой-то API, это означает, что есть пакет с набором классов, которые инкапсулируют рассматриваемую технологию. JAX-RPC долго развивался от версии к версии и в конечном итоге превратился в JAX-WS. WS, очевидно, означает WebService и можно подумать, что это простое переименование RPC в популярное нынче словечко. Это не так, т.к. теперь веб-сервисы отошли от первоначальной задумки и позволяют не просто вызывать удаленные методы, но и просто посылать сообщения-документы в формате SOAP. Зачем это нужно я пока не знаю, вряд ли ответ здесь будет «на всякий случай, вдруг понадобится». Сам бы хотел узнать от более опытных товарищей. Ну и последнее, далее появился еще JAX-RS для так называемых RESTful веб-сервисов, но это тема отдельной статьи. На этом введение можно заканчивать, т.к. далее мы будем учиться работать с JAX-WS.

Общий подход

В веб-сервисах всегда есть клиент и сервер. Сервер – это и есть наш веб-сервис и иногда его называют endpoint (типа как, конечная точка, куда доходят SOAP сообщения от клиента). Нам нужно сделать следующее:

1. Описать интерфейс нашего веб-сервиса
2. Реализовать этот интерфейс
3. Запустить наш веб-сервис
4. Написать клиента и удаленно вызвать нужный метод веб-сервиса

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

Сервер

Запустим 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.javarush.ru/" , "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.