Веб-сервис - что это такое. Что такое Web-сервис
Назовем сервисом (service) ресурс, реализующий бизнес-функцию, обладающий следующими свойствами:
является повторно используемым;
определяется одним или несколькими явными технологически-независимыми интерфейсами;
слабо связан с другими подобными ресурсами и может быть вызван посредством коммуникационных протоколов, обеспечивающих возможность взаимодействия ресурсов между собой.
Веб-сервисом называется программная система, идентифицируемая строкой URI , чьи интерфейсы и привязки определены и описаны посредством XML . Описание этой программной системы может быть найдено другими программными системами, которые могут взаимодействовать с ней согласно этому описанию посредством сообщений, основанных на XML, и передаваемых с помощью Интернет-протоколов.
1.1 Основы Web-сервисов
Web-сервисы - это новая перспективная архитектура, которая обеспечивает новый уровень распределённости. Вместо разработки или приобретения компонентов и их встраивания в ИС предлагается покупать время их работы и формировать программную систему, которая осуществляет вызовы методов из компонентов, которые принадлежат и поддерживаются независимыми провайдерами. Благодаря Web-сервисам функции любой программы в сети могут стать доступными через Интернет. Самый простой пример Web-сервиса - система Passport на Hotmail , которая позволяет создать аутентификацию пользователей на собственном сайте.
В основе Web-сервисов лежат следующие универсальные технологии:
TCP/IP – универсальный протокол, понимаемый всеми сетевыми устройствами, от мэйнфреймов до мобильных телефонов и PDA;
HTML – универсальный язык разметки, применяемый для отображения информации устройствами пользователей;
XML (Extensible Markup Language)– универсальный язык для работы с любыми типами данных.
Универсальность этих технологий – основа для понимания веб-сервисов. Они основаны только на общепринятых, открытых и формально независимых от поставщиков технологиях. Только посредством этого достигается главное преимущество веб-сервисов как концепции построения распределенных ИС – их универсальность, т. е. возможность применения для любых операционных систем, языков программирования, серверов приложений и т. д.
Таким образом, веб-сервисы решают исходную задачу – задачу интеграции приложений различной природы и построения распределенных ИС . В этом и заключается основное принципиальное отличие веб-сервисов от предшественников.
Веб-сервисы - это XML-приложения, осуществляющие связывание данных с программами, объектами, базами данных либо с деловыми операциями целиком. Между веб-сервисом и программой осуществляется обмен XML-документами, оформленными в виде сообщений. Стандарты веб-сервисов определяют формат таких сообщений, интерфейс, которому передается сообщение, правила привязки содержания сообщения к реализующему сервис приложению и обратно, а также механизмы публикации и поиска интерфейсов.
XML (англ. e X tensible M arkup L anguage - расширяемыйязык разметки ; произносится [икc-эм-эль ]). РекомендованКонсорциумом Всемирной паутины (W3C). Спецификация XML описывает XML-документы и частично описывает поведение XML-процессоров (программ, читающих XML-документы и обеспечивающих доступ к их содержимому). XML разрабатывался как язык с простым формальнымсинтаксисом , удобный длясоздания и обработки документов программам и одновременно удобный для чтения и создания документов человеком, с подчёркиванием нацеленности на использование в Интернете. Язык называется расширяемым, поскольку он не фиксирует разметку, используемую в документах: разработчик волен создать разметку в соответствии с потребностями к конкретной области, будучи ограниченным лишь синтаксическими правилами языка. Сочетание простого формального синтаксиса, удобства для человека, расширяемости, а также базирование на кодировкахЮникод для представления содержания документов привело к широкому использованию как собственно XML, так и множества производных специализированных языков на базе XML в самых разнообразных программных средствах.
Стандартные XML-приложения
XML можно использовать не только для описания отдельного документа. Индивидуальный пользователь, компания или комитет по стандартам может определить необходимый набор элементов XML и структуру документа, которые будут применяться для особого класса документов. Подобный набор элементов и описание структуры документа называют XML-приложением или XML-словарем . Например, организация может определить XML-приложение для создания документов, описывающих молекулярные структуры, мультимедиа презентации или содержащих векторную графику.
Веб-сервисы могут использоваться во многих приложениях. Независимо от того, откуда запускаются веб-сервисы, с настольных компьютеров клиентов или с переносных, они могут использоваться для обращения к таким интернет-приложениям, как система предварительных заказов или контроля выполнения заказов.
Веб-сервисы пригодны для В2В-интеграции (business-to-business), замыкая приложения, выполняемые различными организациями, в один производственный процесс. Веб-сервисы также могут решать более широкую проблему интеграции приложений предприятия (Enterprise Application Integration, EAI) , осуществляя связь нескольких приложений одного предприятия с несколькими другими приложениями. Во всех перечисленных случаях технологии веб-сервисов являются "связующим звеном", объединяющим различные части программного обеспечения.
Как видно из рис. 1, веб-сервисы представляют собой оболочку, обеспечивающую стандартный способ взаимодействия с прикладными программными средами, такими как системы управления базами данных (СУБД), .NET, J2EE (Java2 Platform, Enterprise Edition), CORBA (Common Object Request Broker Architecture), посредники пакетов планирования ресурсов предприятия (Enterprise Resource Planning, ERP), брокеров интеграции и пр.
Рис.1. Веб-сервисы взаимодействуют с прикладными системами
Интерфейсы веб-сервисов получают из сетевой среды стандартные XML-сообщения , преобразуют XML-данные в формат, "понимаемый" конкретной прикладной программной системой, и отправляют ответное сообщение (последнее - не обязательно). Программная реализация веб-сервисов (базовое программное обеспечение, нижний уровень) может быть создана на любом языке программирования с использованием любой операционной системы и любого связующего программного обеспечения (middleware ).
Простой пример: поиск информации
В настоящее время большинство сервисов вызываются по Сети посредством ввода данных в HTML-формы и отправки этих данных сервису путем добавления их в строку унифицированного указателя информационного ресурса (Uniform Resource Locator, URL ):
http://www.google.com/search?q=Skate+boots&btnG=Google+Search
Этот пример иллюстрирует простоту веб-взаимодействия (например, поиска, покупки акций или запроса маршрута движения), где параметры и ключевые слова внедряются непосредственно в URL. В данном случае представлен простой запрос поиска skate boots (ботинки с коньками) в строке обращения к поисковой машине Google. Ключевое слово search (искать) представляет сервис, к которому будет осуществлено обращение, а параметр Skate+boots является строкой поиска, которая была введена в HTML-форме на странице веб-сайта Google. Сервис поиска Google передаст этот запрос к различным поисковым машинам, которые вернут список URL для страниц, на которых имеется соответствие параметру поиска Skate+boots. Данный малоэффективный способ поиска в Сети полностью основан на установлении соответствия указанной текстовой строки и индексированных HTML-страниц.
XML - лучший способ отправки данных. XML предоставляет значительные преимущества при передаче данных через Интернет. Теперь предыдущий запрос можно представить в виде XML-документа :
xmlns:s="www.xmlbus.com/SearchService"> Отправка запроса
в виде XML-документа
имеет следующие преимущества: возможность
определения типов данных и структур,
большую гибкость и расширяемость. XML
может представлять структурированные
данные или данные определенного типа
(например, допустимо указывать значение
поля size (размер) как в виде строки цифр,
так и в форме числа с плавающей точкой)
и содержать больший объем информации,
чем это допускает URL. Данный пример
представлен в форме SOAP-сообщения (Simple
Object Access Protocol) - стандартной формы обмена
XML-сообщениями - одной из технологий,
лежащих в основе веб-сервисов. В
SOAP-сообщении имя запрашиваемого сервиса
и входные параметры представлены в виде
отдельных XML-элементов. Рассматриваемый
пример также иллюстрирует использование
пространства имен XML (xmlns:), еще одного
важного элемента веб-сервисов. Благодаря
тому, что XML-документы поддерживают
разные типы данных, сложные структуры
и объединение схем, современные технологии
веб-сервисов обеспечивают значительное
преимущество над существующими
возможностями обращения к программным
приложениям посредством HTML и URL. Веб-служба
, веб-сервис (англ. web service) - идентифицируемая веб-адресом программная система со стандартизированными интерфейсами.
Веб-службы могут взаимодействовать друг с другом и со сторонними приложениями посредством сообщений, основанных на определённых протоколах = Веб-служба является единицей модульности при использовании сервис-ориентированной архитектуры приложения. В обиходе веб-сервисами называют услуги, оказываемые в Интернете. Как показано на рисунке, можно выделить три инстанции, взаимодействующие в рамках веб-службы. Переведем их названия как заказчик, исполнитель и каталог (Service Requestor, Service Provider и Service Broker). Когда служба разработана, исполнитель регистрирует ее в каталоге, где ее могут найти потенциальные заказчики. Заказчик, найдя в каталоге подходящую службу, импортирует оттуда ее WSDL-спецификацию и разрабатывает в соответствии с ней свое программное обеспечение. WSDL описывает формат запросов и ответов, которыми обмениваются заказчик и исполнитель в процессе работы
. Для обеспечения взаимодействия используются следующие стандарты: Каталог веб-служб и сведений о компаниях, предоставляющих веб-службы во всеобщее пользование или конкретным компаниям. Пока UDDI существуют, однако, только в небольших фирменных сетях и еще не нашли широкого распространения в открытом интернете. Существуют средства автоматизации разработки веб-служб, разделяющиеся на две основных группы.
При разработке снизу-вверх сначала пишутся имплементирующие классы, а из их исходного текста генерируются WSDL-файлы, документирующие службу. Недостатком этого метода является подверженность Java-классов частым изменениям.
При подходе сверху-вниз сначала подготавливается WSDL, а из него генерируется скелет Java-класса, имплементирующего службу. Этот путь считается более трудным, зато приводит к более чистым и лучше защищенным от изменений решениям. Пока формат сообщений, которыми обмениваются заказчик и исполнитель, не меняется, изменения в каждом из них не нарушают взаимодействия. Эта техника называется иногда "contract first", так как исходной точкой является WSDL ("договор" между заказчиком и исполнителем). Взамодействие между авиакомпаниями и бюро путешествий. Первые предоставляют через веб-службы полезную информацию, которую вторые используют при поиске оптимальных предложений своим клиентам. Google с 2002 до 2009 года предоставлял веб-службу, которая позволяла заказчикам искать необходимую информацию в интернете так же, как это делают обычные пользователи. По удобству это несравнимо, например, с автоматическим разбором HTML-текста Googleвских страниц. Amazon.com имеет веб-службу, предоставляющую различные веб-базированные услуги (что-то "как услуга" - облачные технологии) Александр Качанов Идея веб-сервисов была разработана такими гигантами компьютерной индустрии
как 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 к веб-сервису: Ключевые элементы SOAP-конверта узнать достаточно просто: это два параметра
( А ответ будет выглядеть вот так: Это сообщение еще проще расшифровать. Элемент Даже при всей простоте протокола 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. Прежде чем я полностью откажусь от карьеры программиста и посвящу себя
использованию веб-сервисов, я должен задать себе вопрос: "Уж слишком
розовая картинка. Что в ней не так?". К сожалению, за великий потенциал
веб-сервисов приходится платить определенную цену: Когда же веб-сервисы займут свое место и станут доступны всем, они станут
неоценимой помощью для веб-разработчиков. Они дадут нам гибкий доступ ко всей
мощи всех компьютеров Сети. Пришло время для тех, кто делает веб-сайты,
заинтересоваться веб-сервисами и узнать побольше о том, что они могут от них
получить. Заголовок топика – это действительно вопрос, т.к. я сам не знаю, что это и впервые попробую поработать с этим в рамках настоящей статьи. Единственное, что могу гарантировать, что код, представленный ниже, будет работать, однако мои фразы будут лишь предположениями и догадками о том, как я сам все это понимаю. Итак, поехали…
Валентин Колесов
Демонстрация работы SOAP на примере написания Web-сервера Широко распространенные в настоящее время технологии удаленного вызова методов (DCOM, CORBA/IIOP и RMI) довольно сложны в настройке и организации взаимодействия. Это влечет за собой трудности в эксплуатации и функционировании распределенных систем (проблемы безопасности, неудобства транспорта через брандмауэры и т. д.). Многие проблемы удалось решить благодаря созданию SOAP (Simple Object Access Protocol, простой протокол доступа к объектам), простого протокола, основанного на XML и служащего для обмена сообщениями в распределенных средах (WWW). Протокол предназначен для создания Web-сервисов и удаленного вызова методов. SOAP можно использовать в сочетании с разными транспортными протоколами, включая HTTP, SMTP и др. 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). WSDL-файл - это документ в формате XML, описывающий методы, предоставляемые Web-сервисом, а также параметры методов, их типы, названия и местонахождение сервиса Listener. Мастер SOAP Toolkit автоматически генерирует этот документ, фрагмент которого приведен ниже: Тег Envelope должен быть корневым элементом пакета. Элемент Header не обязателен, а Body должен присутствовать и быть прямым потомком элемента Envelope. В случае ошибки выполнения метода сервер формирует пакет, содержащий в теге Body элемент Fault, который содержит подробное описание ошибки. Если вы пользуетесь высокоуровневыми интерфейсами SOAPClient, SOAPServer, то вам не придется вдаваться в тонкости формата пакета, но при желании можно воспользоваться низкоуровневыми интерфейсами или же вообще создать пакет "вручную", используя любой язык программирования. Объектная модель SOAP Toolkit дает возможность работать с объектами низкоуровневого
API: С помощью объектов высокоуровневого 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. Создайте на форме кнопку, в обработчике нажатия кнопки напишите следующий код: Не забудьте изменить адрес 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. А пакет ответа выглядит следующим образом: Так выглядит пакет сервера, пришедший в ответ на запрос некорректного формата: 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.
В этом употреблении термин требует уточнения
, идёт ли речь о поиске, веб-почте, хранении документов, файлов, закладок и т. п.
Такими веб-сервисами можно пользоваться независимо от места доступа в Интернет, компьютера или браузера.Архитектура
Методы разработки
Достоинства
Недостатки
Примеры
Что такое веб-сервис?
Основы
Стандарты в основе
xmlns:m="http://www.somesite.com/Postcode">
xmlns:m="http://www.somesite.com/Postcode">Теперь об UDDI
Как это все работает
На это стоит потратить время
Разработка сервиса
Минусы
Введение
Начать надо с того, для чего создавалась концепция веб-сервисов. К моменту появления этого понятия в мире уже существовали технологии, позволяющие приложениям взаимодействовать на расстоянии, где одна программа могла вызвать какой-нибудь метод в другой программе, которая при этом могла быть запущена на компьютере, расположенном в другом городе или даже стране. Все этого сокращенно называется RPC (Remote Procedure Calling – удаленный вызов процедур). В качестве примеров можно привести технологии CORBA, а для Java – RMI (Remote Method Invoking – удаленный вызов методов). И все вроде в них хорошо, особенно в CORBA, т.к. с ней можно работать на любом языке программирования, но чего-то все же не хватало. Полагаю, что минусом CORBA является то, что она работает через какие-то свои сетевые протоколы вместо простого HTTP, который пролезет через любой firewall.
Идея веб-сервиса заключалась в создании такого RPC, который будет засовываться в HTTP пакеты. Так началась разработка стандарта. Какие у этого стандарта базовые понятия:
Почему так кратко спросите вы? А по подробней нельзя? Наверное можно, но для этого придется обратиться к таким книгам как Машнин Т. «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 сообщения от клиента). Нам нужно сделать следующее:
Запуск веб-сервиса можно производить разными способами: либо описать класс с методом 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.
разработчик красноярского отделения санкт-петербургской компании "Астрософт",
сертифицированный специалист Microsoft (MCSD, MCSE, MCDBA)
[email protected]Что такое SOAP
Что такое Web-сервисы
Пример
Создание сервера
Создание клиента
Dim SoapClient As New SoapClient
SoapClient.mssoapinit "http://wsd010/soap/SOAPService.wsdl"
MsgBox SoapClient.AddNumbers(4, 3)
MsgBox SoapClient.SubtractNumbers(3, 2)
Дополнительная информация по теме
Листинг 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