Введение в SOAP. Что такое WSDL, SOAP и REST
10 ответов
WSDL - это XML-документ, описывающий веб-службу. Это фактически означает язык определения веб-сервисов.
SOAP - это протокол на основе XML, который позволяет обмениваться информацией по определенному протоколу (например, HTTP или SMTP) между приложениями. Это означает простой протокол доступа к объектам и использует XML для его формата обмена сообщениями для передачи информации.
REST - это архитектурный стиль сетевых систем и выступает за передачу репрезентативного состояния. Это не стандарт сам, но использует такие стандарты, как HTTP, URL, XML и т.д.
Каждый раз, когда кто-то упоминает SOAP/WSDL, я думаю о объектах и классах, определенных в xml...
"Вы используете SOAP так же, как и любой PHP-класс. Однако в этом случае класс не существует в локальной файловой системе приложений, а на удаленном узле, доступ к которому осуществляется через http."... "Если мы думаем использовать SOAP-сервис как еще один класс PHP, тогда документ WSDL является списком всех доступных методов и свойств класса".
И всякий раз, когда кто-то говорит о REST, я думаю о HTTP-командах (методах запроса), таких как POST, GET и DELETE
Пример: простыми словами, если у вас есть веб-сервис калькулятора.
WSDL: WSDL рассказывает о функциях, которые вы можете реализовать или подвергнуть действию клиенту. Например: добавление, удаление, вычитание и т.д.
SOAP: где, используя SOAP, вы фактически выполняете действия, такие как doDelete(), doSubtract(), doAdd(). Таким образом, SOAP и WSDL являются яблоками и апельсинами. Мы не должны сравнивать их. Они оба имеют свою собственную функциональность.
Почему мы используем SOAP и WSDL: для обмена независимыми данными на платформе.
РЕДАКТИРОВАТЬ: В обычной повседневной жизни:
WSDL: Когда мы идем в ресторан, мы видим пункты меню, это WSDL.
Прокси-классы: Теперь, после просмотра элементов меню, мы составляем наш разум (обрабатываем наш взгляд на порядок): Итак, в основном мы делаем классы Proxy на основе документа WSDL.
SOAP: Затем, когда мы фактически заказываем пищу на основе меню: подразумевается, что мы используем прокси-классы для вызова методов обслуживания, которые выполняются с использованием SOAP.:)
SOAP → SOAP (Простой прототип доступа к объектам) - это протокальный уровень приложения, созданный для взаимодействия машины с машиной. Протокол определяет стандартные правила. Все стороны, которые используют конкретный протокол, должны придерживаться правил протокола. Как и TCP, он разматывается на транспортном уровне. Протокол SOAP будет пониматься на уровне приложения (любое приложение, поддерживающее SOAP - Axis2,.Net).
WSDL → SOAP-сообщение состоит из SoapEnevelope- > SoapHeader и SoapBody. Он не определяет, какой будет формат сообщений? какие все транспорты (HTTP, JMS) поддерживаются? без этой информации. Для любого клиента, который хочет использовать конкретный веб-сервис для создания SOAP-сообщения, трудно. Даже если они это сделают, они не будут уверены, это будет работать все время. WSDL - это спасение. WSDL (язык описания веб-служб) определяет операции, форматы сообщений и данные о транспортировке для сообщения SOAP.
REST → REST (передача состояния представления) основана на транспорте. В отличие от SOAP, который нацелен на действия, REST больше относится к ресурсам. REST находит ресурсы с помощью URL-адреса (пример -http://{serverAddress}/employees/employeeNumber/12345) и зависит от транспортного протокола (с HTTP-GET, POST, PUT, DELETE,...) для действий для выполнения ресурсов. Служба REST находит ресурс на основе URL-адреса и выполняет действие на основе глагола действия транспорта. Это больше архитектурный стиль и условности.
SOAP означает простой (sic) протокол доступа к объектам. Он предназначался для того, чтобы делать удаленные вызовы процедур для удаленных объектов, отправляя XML через HTTP.
WSDL - это язык описания веб-сервисов. Запрос, заканчивающийся на ".wsdl" конечной точке, приведет к представлению XML-сообщения, описывающего запрос и ответ, который может ожидать использование. Он описывает контракт между сервисом и клиентом.
REST использует HTTP для отправки сообщений в службы.
SOAP - спецификация, REST - это стиль.
Вы не собираетесь "просто" понимать что-то сложное.
WSDL - это язык, основанный на XML, для описания веб-службы. В нем описываются сообщения, операции и информация о транспортной сети, используемые службой. Эти веб-службы обычно используют SOAP, но могут использовать другие протоколы.
WSDL читается программой и поэтому может использоваться для генерации всего или части кода клиента, необходимого для вызова веб-службы. Это то, что означает вызов SOAP-ориентированных веб-сервисов "самоописанием".
REST вообще не связан с WSDL.
Wikipedia говорит: "Язык описания веб-служб - это язык на основе XML, который предоставляет модель для описания веб-сервисов". Другими словами, WSDL относится к веб-службе, так как javadoc относится к библиотеке java.
Однако очень приятная вещь в WSDL заключается в том, что программное обеспечение может генерировать клиент и сервер, используя WSDL.
Что такое SOAP?
SOAP расшифровывается как Simple Object Access Protocol (Простой Протокол Доступа к Объектам). Надеюсь по прочтении статьи вам останется только недоумевать: "Что за странное название?"
SOAP в теперешней его форме – это метод удаленного вызова (RPC, Remote procedure Call) по сети. (Да, он также используется для передачи документов в виде XML, но мы это пока опустим).
Давайте разбираться. Представьте, что у вас есть сервис, который возвращает биржевую котировку (stock quote) для заданного тикера (stock symbol). Он посылает данные на сайт Nasdaq и формирует на основе возвращенного HTML нужный результат. Дальше, чтобы позволить другим разработчикам использовать его внутри своих приложений, вы делаете из этого сервиса компонент, который через Интернет находит информацию о котировках. Работает он отлично, пока в один прекрасный день Nasdaq не меняет разметку своих страниц. Вам приходится пересмотреть всю логику работы компонента и разослать обновления всем разработчикам, использующим его. А им в свою очередь необходимо разослать обновления всем своим пользователям. Если это происходит на более-менее постоянной основе, вы можете нажить немало врагов среди коллег-разработчиков. А с программистами, как известно, шутки плохи. Вы же не хотите завтра доставать фотографию любимого кота из офисного шредера, правда?
Что же делать? Посмотрим... все, что вам нужно, это предоставить одну функцию, которая будет принимать на вход тикер (типа string) и возвращать биржевую котировку (типа float или double). Так не проще ли было бы просто позволить вашим разработчикам каким-то образом вызвать эту функцию через Интернет? Отлично! Тоже мне новость, есть же COM и Corba, и Java, которые этим занимаются уже годами... что правда – то правда, но эти методы не без изъяна. Удаленная настройка COM не тривиальна. Кроме того, нужно открыть столько портов в брандмауэре, что на системного администратора пива не напасешься. Да, и придется забыть о пользователях всех операционных систем кроме Windows. Но ведь позьзователи Linux тоже иногда интересуются биржей.
Хотя, похоже, что не все потеряно для пользователей Linux, если они используют DCOM, больше здесь: http://www.idevresource.com/com/library/res/articles/comonlinux.asp.
На счет Corba и Java я много сказать не могу, так что в качестве упражнения предлагаю читателям найти минусы в этих подходах.
SOAP – это стандарт, который позволяет вам описать такой удаленный вызов и вид, в котором будет возвращаться результат. Таким образом вам нужно разместить вашу функцию в приложении, доступном по сети и получать вызовы в виде SOAP пакетов. После этого вы валидируете входные данные, запускаете вашу функцию и возвращаете результат в новом SOAP пакете. Весь процесс может работать через HTTP, так что вам не придется открывать кучу портов в брандмауэре. Правда просто?
О чем эта статья
Это первая из серии статей о SOAP, которые мы пишем в Agni Software. В этой статье я постараюсь дать вам представление о том, что такое SOAP и как написать приложение, общающееся с SOAP сервером.Soap и XML
Если вам SOAP пока еще кажется простым, добавим XML. Теперь вместо имени функции и параметров мы получаем довольно сложный XML-конверт, как будто созданный для того, чтобы сбить вас с толку. Но не спешите пугаться. Дальше – больше, и вам нужно увидеть всю картину, чтобы оценить всю сложность SOAP.Если вы не знаете, что такое XML, для начала прочтите мою статью об XML здесь: http://www.agnisoft.com/white_papers/xml_delphi.asp.
Все SOAP пакеты имеют XML формат. Что это значит? Посмотрим. Взгляните на эту функцию (Pascal):
function GetStockQuote(Symbol: string) : double;
Выглядит отлично, но проблема в том, что это – Pascal. Какая польза от этого простого определения для Java-разработчика? Или для кого-то, кто работает с VB? Нам нужно что-то, что будет понятно всем, даже VB-программистам. Так дайте им XML, содержащий одну и ту же инфрмацию (параметры, значения биржевых котировок и т.д.). Вы создаете SOAP пакет, который по сути является вызовом вашей функции, обернутый в XML, чтобы любое приложения на любой платформе могло его понять. Теперь посмотрим, как выглядит наш SOAP вызов:
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
Информативно, правда? SOAP упрощается на глазах. Ладно, шутки в сторону. Теперь я постараюсь объяснить вам, как разобраться в этом SOAP вызове.
Расшифровка тегов
Первый тег, который бросается в глаза – этоСледующий тег –
Следующий тег в списке –
Лирическое отступление на счет пространств имен: Пространство имен дает возможность квалифицировать XML тег. Нельзя, к примеру, иметь две переменные с одинаковым именем в одной процедуре, но если они в двух разных процедурах, проблем не возникает. Таким образом процедура – это пространство имен, так как все имена в ней уникальны. Точно так же XML теги имеют свою область видимости внутри пространств имен, так что имея пространство имен и имя тега, можно однозначно его идентифицировать. Мы определим пространство имен как URI, чтобы отличать наш NS1 от подражателей. В приведенном выше примере NS1 – это алиас, указывающий на urn:xmethods-quotes.
Обратите внимание также на атрибут encodingStyle – этот атрибут определяет каким образом сериализуется SOAP вызов.
Внутри тега
xsi:type="xsd:string"
Приблизительно так в XML и определяются типы. (Обратите внимание на то, как хитро я использовал слово "приблизительно", делая обобщение о технологии, которая может измениться как только статья будет опубликована). Что конкретно это означает: тип, определенный в пространстве имен xsi, который, как вы заметили, определен в теге
Внутри тега
Ну и в конце, как порядочные люди, мы закрыли все теги.
Вот и разобрались с SOAP пакетом, определяющим вызов к SOAP серверу. А SOAP сервер с помощью XML парсеров, красной кнопки и космической станции "МИР" декодирует этот вызов и определяет, что вам нужна биржевая котировка. Он тут же находит нужную котировку и возвращает вам ее в таком виде:
Большинство коммерческих серверов вернуло бы гораздо больше информации, например, в какой валюте и за какую цену была куплена последняя акция. Да и цена акции, пожалуй, была бы поточнее.
Таким образом мы знаем, чего ожидает SOAP сервер и что он вернет. Так КАК же отправить эту информацию? Использовать можно любой транспорт. Самым освещенным является HTTP. Я не стану вдаваться в подробности HTTP, для тех, кто не знает – это то, что использует ваш браузер, чтобы общаться с сайтами, на которые вы заходите.
Нужный HTTP запрос будт выглядеть приблизительно так:
POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Length: nnnn
SOAPAction: "Some-URI"
The soap request packet here... Единственное, что еще стоит отметить – это заголовок SOAPAction. Этот заголовок указывает на цель запроса и является обязательным. Каждый SOAP сервер может иметь неограниченное количество функций и может использовать заголовок SOAPAction чтобы определить какую функцию вызывают. Брандмауэры и мультиплексоры также могут фильтровать контент на основании этого заголовка.
SOAP ответ от HTTP сервера будет выглядеть следующим образом:
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
Soap Response packet here...
Почему HTTP? Во-первых, сетевым администраторам не придется открывать уйму отдельных портов для SOAP вызовов... веб-сервер может спокойно обрабатывать вызовы, т.к. 80-й порт обычно открыт для всех для приема входящих запросов. Еще одним преимуществом является расширяемость веб-серверов с помощью CGI, ISAPI и других нативных модулей. Эта расширяемость позволяет написать модуль, обрабатывающий SOAP запросы не задевая другого веб-контента.
Вот и все
Надеюсь, эта статья помогла пролить немного света на SOAP. Если вы еще здесь и хотите почитать больше на эту тему, посетите сайт авторов: http://www.agnisoft.com/soap
Как уже говорилось в предыдущей главе, Web-службы обмениваются информацией с клиентами и между собой, посылая сообщения на языке XML. Теги этой реализации XML, правила оформления документа XML и порядок обмена документами определены протоколом SOAP. Протокол SOAP создан в 1998 году командой разработчиков под руководством Дейва Винера (Dave Winer), работавшей в корпорации Microsoft и фирме Userland. Название протокола - "Простой протокол доступа к объектам" - отражает его первоначальное назначение - обращаться к методам удаленных объектов. Назначение протокола изменилось, сейчас это протокол всякого взаимодействия Web-служб и компонентов слабо связанных распределенных приложений. Он уже не совсем прост, да и об объектах он ничего не говорит. Многие разработчики предлагают назвать его "Service Oriented Architecture Protocol", оставив прежнее сокращение. Чтобы прекратить эти попытки, в спецификации SOAP 1.2 указано, что слово "SOAP" отныне никак не будет расшифровываться.
В конце 1999 года разработка протокола была передана в консорциум W3C (http: //www.w3.org/ ).
В мае 2000 года консорциум выпустил свою версию SOAP 1.1. Послание, написанное по протоколу SOAP, оформляется документом XML, активно использующим пространства имен. Имена элементов XML версии SOAP 1.1 относятся к пространству имен с идентификатором http://schemas.xmlsoap.org/soap/envelope/.
Черновик второй версии SOAP 1.2 был выпущен в 2001 году, его пространство имен называлось в то время http://www.w3.org/2001/06/soap-envelope.
Заметьте, что именно идентификатор пространства имен, а не номер 1.1 или 1.2 определяет версию SOAP. Сервер не станет рассматривать SOAP- послание и вернет сообщение об ошибке если заметит
несоответствие пространства имен.
В то время как я пишу эти строки, версия SOAP 1.1 остается рабочей. Версия 1.2 никак не может выйти из подготовительной стадии, но уже используется, например, в SOAP::Lite, Apache SOAP 2.3, Apache Axis. Поэтому в этой главе я буду излагать версию 1.2, отмечая ее отличия от версии 1.1.
Спецификация рабочей версии SOAP всегда хранится по адресу http://www.w3.org/TR/SOAP/. Документы, лежащие по этому адресу, заменяются новыми при замене рабочей версии.
Черновая версия SOAP постоянно обновляется, при этом меняется идентификатор пространства имен. Новейший вариант черновой версии на время написания книги хранился по адресу http://www.w3.org/TR/soapl2-partl/, а пространство используемых ею имен называлось http://www.w3.org/2002/06/soap-envelope. Заметьте, что спецификация SOAP 12 состоит из двух частей: part 1 и part2. Вторая часть спецификации - приложение - содержит правила записи сложных типов данных. У спецификации есть еще одна часть partO - примеры посланий, составленных по правилам SOAP 1.2.
Структура SOAP-послания
Спецификация определяет SOAP-послание как документ XML, не содержащий объявление типа документа и инструкций по обработке. Корневой элемент этого документа XML называется
и другие атрибуты, снабженные префиксами. В корневой элемент вкладывается один необязательный элемент содержащий заголовок послания, и один обязательный элемент
, в который записывается содержимое послания. Версия 1.1 позволяла после тела записать произвольные элементы, их имена обязательно следовало снабжать префиксами. Версия 1.2 запрещает писать что-либо после элемента . Короче говоря, общая структура SOAP-послания такова: xmlns:env="http://www.w3.org/2002/06/soap-envelope"> < ! - Блоки заголовка -> Элемент Дело в том, что SOAP-послание может пройти через несколько SOAP- серверов или через несколько приложений на одном сервере. Эти приложения выполняют предварительную обработку блоков заголовка послания и передают его друг другу. Все эти серверы и/или приложения называются SOAP-узлами (SOAP nodes). Спецификация SOAP не определяет правила прохождения послания по цепочке серверов. Для этого разрабатываются другие протоколы, например, Microsoft WS-Routing. Атрибут actor задает целевой SOAP-узел - тот, который расположен в конце цепочки и будет обрабатывать заголовок полностью. Значение атрибута actor показывает, что обрабатывать заголовок будет первый же сервер, получивший Атрибут actor может встречаться в отдельных блоках заголовка, указывая узел- обработчик этого блока. После обработки блок удаляется из SOAP- послания. В версии 1.2 атрибут actor заменен атрибутом role, потому что в этой версии SOAP каждый узел играет одну или несколько ролей. Спецификация пока определяет три роли SOAP-узла. Роль http://^^.w3.org/2002/06/soap-envelope/role/ultimateReceiver играет конечный, целевой узел, который будет обрабатывать заголовок. Роль http://www.w3.org/2002/06/soap-envelope/role/next играет промежуточный или целевой узел. Такой узел может играть и другие, дополнительные роли. Роль http://www.w3.org/2002/06/soap-envelope/role/none не должен играть ни один SOAP-узел. Распределенные приложения, исходя из своих нужд, могут добавить к этим ролям другие роли, например, ввести промежуточный сервер, проверяющий цифровую подпись и определить для него эту роль какой-нибудь строкой URI. Значением атрибута role может быть любая строка URI, показывающая роль узла, которому предназначен данный блок заголовка. Значением по умолчанию для этого атрибута служит пустое значение, то есть, просто пара кавычек, или строка URI http://\vw\v.w3.org/2002/06/soap-envelope/rale/ultimateReceiver. Значение атрибута role показывает, что блок должен быть обработан узлом, играющим роль, определенную такой же строкой. Еще один атрибут элемента В версии SOAP 1.2 вместо цифры о надо писать слово false, а вместо цифры 1 писать слово true. В тело заголовка Листинг 3.1. Заголовок с одним блоком xmlns:t="http://some.com/transaction" env:role= "http://www.w3.org/2002/06/soap-envelope/role/ultimateReceiver" env:mustUnderstand="1"> Элементы, вложенные в блоки заголовка, уже не называются блоками. Они не могут содержать атрибуты role, actor И mustunderstand. Элемент Сообщение об ошибке Если SOAP-сервер, обрабатывая поступившее к нему SOAP-послание, заметит ошибку, то он прекратит обработку и отправит клиенту SOAP- послание, в тело которого запишет один элемент В сообщении, записанном в теле элемента версии SOAP 1.1 выде ляются четыре части, описанные следующими вложенными элементами. Код ошибки Описание ошибки Место обнаружения ошибки Детали ошибки Например: xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> Версия SOAP 1.2 изменила содержание элемента Как описано в пространстве имен http://www.w3.org/2002/06/soap-envelope, в него входят два обязательных элемента и три необязательных элемента. Обязательные элементы. Код ошибки Причина ошибки Необязательные элементы. ? ? ? Листинг 3.2 показывает сообщение об ошибке, возникшей при попытке выполнения процедуры. Ошибка заключается в том, что имена аргументов процедуры неправильно записаны в SOAP-послании и процедура не может их понять. Листинг 3.2. Сообщение об ошибке
xmlns:env="http://www.w3.org/2002/06/soap-envelope" xmlns:rpc=’http://www.w3.org/2002/06/soap-rpc’> xmlns:e="http://www.example.org/faults"> Типы ошибок
Список кодов ошибок постоянно меняется и расширяется. Версия 1.1 определяет четыре типа ошибок. VersionMismatch - пространство имен неопознано. Может быть, оно устарело или его имя написано неправильно. MustUnderstand - блок заголовка, помеченный атрибутом mustUnderstand со значением 1, не отвечает своему синтаксису, определенному в схеме документа. Client - документ XML, содержащий послание, неправильно сформирован и по этой причине сервер не может его обработать. Клиенту следует изменить послание. Server - сервер не может обработать правильно записанное послание по своим внутренним причинам. Версия 1.2 определяет пять типов ошибок. VersionMismatch - пространство имен неопознано. Может быть, оно устарело или его название написано неправильно, или в послании встретилось имя элемента XML, не определенное в этом пространстве имен. В заголовок ответа сервер записывает элемент MustUnderstand - блок заголовка, помеченный атрибутом mustunderstand со значением true, не отвечает своему синтаксису, определенному в схеме документа. Сервер записывает в заголовок ответа элементы DataEncodingUnknown - в послании встретились непонятные данные, может быть, они записаны в неизвестной кодировке. Sender - документ XML, содержащий послание, неправильно сформирован и по этой причине сервер не может его обработать. Клиенту следует изменить послание. Receiver - сервер не может обработать правильно записанное послание по своим внутренним причинам, например, отсутствует нужный XML- парсер. Сервер может добавить к этим типам ошибок какие-то свои типы. Обычно они детализируют стандартные типы, и сообщения о них появляются в элементах ? Листинг 3.3. Ответ сервера с сообщением об ошибке типа VersionMismatch
xmlns:env="http://www.w3.org/2002/06/soap-envelope"> xmlns:upg="http://www.w3.org/2002/06/soap-upgrade"> xmlns:nsl="http://www.w3.org/2002/06/soap-envelope"/> xmlns:ns2="http://schemas.xmlsoap.org/soap/envelope/"/> ЛистонгЗ.4. Ответ сервера с сообщением об ошибке типа MustUnderstand
xmlns:t=’http://some.com/transaction’ /> One or more mandatory headers not understood Литература:
Хабибуллин И. Ш. Разработка Web-служб средствами Java. - СПб.: БХВ-Петербург, 2003. - 400 с: ил.
Вообще сегодня есть стандартные протоколы обмена XML данными: Именно на RPC базируется SOAP (сервис ориентированная архитектура, набор слабосвязанных сервисов, взаимодействующих друг с другом). Главное достоинство RPC - небольшое количество сетевых ресурсов (точек входа) и много задействованных методов. Несмотря на это достоинство, у RPC - это устаревший протокол, у которого ряд недостатков: Все эти недостатки были решены в XML Schema. Это промышленный стандарт описания XML документа. Т.е. это способ моделирования произвольных данных. XML схема может описывать модель (отношения между элементами и атрибутами, и их структура), типы данных (характеризует типы данных) и словарь (названия элементов и атрибутов). Исходя из всех недостатков XML-RPC создали протокол SOAP. SOAP
(Simle Object Access Protocol) - протокол доступа к объекту (к точке входа). Сегодня это основной промышленный стандарт построения распределенных приложений. Он представляет собой расширения языка XML-RPC. Т.е. он построен по принципу: 1 точка входа и любые методы. Сам протокол в плане транспорта (как передать данные) дает широкий выбор: SMTP, FTP, HTTP, MSMQ. SOAP лежит в основе реализации XML веб-сервисов (XML веб служб). Недостаток SOAP - сложен в изучении. SOAP базируется на обмене сообщениями между клиентом и сервером (синхронно и асинхронно). Каждое сообщение несет информацию о данных (какие данные передаются-получаются). SOAP заранее описывает всю структуру сообщения с помощью XML схем: что должно быть в сообщении, как оно будет передаваться. Это дает возможность, не зная сервер, понять, что там происходит, и дает возможность серверу проверить, для него ли это сообщение. Задача схемы - описать структуру данных, т.е. что у нас есть. Все данные делятся на простые и сложные типы (скаляры и структуры). Простой тип (строка, число, boolean, дата) никогда внутри ничего содержать не будет. А структура (объект) может содержать свойства. Структура SOAP сообщений: WSDL
(Web Services Description Language) - язык описания веб служб. Применяется в SOAP. Это некий докуент, который описывает все: какие пространства имен использовались, какие схемы данных использовались, какие типы сообщений сервер ждет от клиента, какие конверты к какому методу принадлежат, какие методы вообще есть, на какой адрес отправлять и т.д. Собственно, WSDL и есть веб сервис. Достаточно клиенту изучить содержимое этого документа, он уже знает о сервере все. Любой сервер должен публиковать WSDL. WSDL состоит из блоков:. Он содержит обязательный вложенный элемент <:value> с кодом ошибки и необязательный вложенный элемент XML схема
Основные операции SOAP
WSDL