Soap envelope что это
Что такое SOAP?
Объясните, пожалуйста, простыми словами, что такое SOAP, для чего нужен, и, если можно, пару примеров использования.
6 ответов 6
Лирическая часть.
Представьте что у вас реализована или реализуется некая система, которая должна быть доступна извне. Т.е. есть некий сервер, с которым вам надо общаться. Например веб-сервер.
Этот сервер может выполнять множество действий, работать с базой, выполнять какие-то сторонние запросы к другим серверам, заниматься каким-то вычислениями и т.д. жить и возможно развиваться по ему известному сценарию (т.е. по сценарию разработчиков). С таким сервером общаться человеку неинтересно, потому что он может не уметь/не хотеть отдавать красивые странички с картинками и прочим юзер-френдли контентом. Он написан и работает чтобы работать и выдавать на запросы к нему данные, не заботясь, чтоб они были человекочитаемые, клиент сам с ними разберется.
Практическая часть.
Веб-сервис (так называется то, что предоставляет сервер и то, что используют клиенты) дает возможность общения с сервером четко структурированными сообщениями. Дело в том, что веб-сервис не принимает абы какие данные. На любое сообщение, которое не соответствует правилам, веб-сервис ответит ошибкой. Ошибка будет, кстати, тоже в виде xml с четкой структурой (чего нельзя сказать правда о тексте сообщения).
WSDL (Web Services Description Language). Правила, по которым составляются сообщения для веб-сервиса описываются так же с помощью xml и также имеют четкую структуру. Т.е. если веб-сервис предоставляет возможность вызова какого-то метода, он должен дать возможность клиентам узнать какие параметры для данного метода используются. Если веб-сервис ждет строку для метода Method1 в качестве параметра и строка должна иметь имя Param1, то в описании веб-сервиса эти правила будут указаны.
Для клиентов достаточно знать url веб-сервиса, wsdl всегда будет рядом, по которому можно получить представление о методах и их параметрах, которые предоставляет этот веб-сервис.
Какие плюсы у всех этих наворотов:
Описание, имеющее четкую структуру, читается любым soap-клиентом. Т.е. какой бы ни был веб-сервис, клиент поймет какие данные веб-сервис принимает. По этому описанию клиент может построить свою внутреннюю структуру классов объектов, т.н. binding’и. В итоге программисту, использующему веб-сервис, остается написать что-то типа (псевдокод):
Минусов тоже полно:
В качестве примера есть открытый веб-сервис belavia:
Можете вручную создать и послать запрос типа:
ЗЫ Раньше был открыт веб-сервис аэрофлота, но после того как 1C добавили поддержку soap в 8ку, куча 1с-бета-тестеров с успехом положили его. Сейчас что-то там поменяли (адреса не знаю, можно поискать, если интересно).
ЗЗЫ Дисклеймер. Рассказал на бытовом уровне. Пинать можно.
Введение в SOAP
Что такое 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):
Выглядит отлично, но проблема в том, что это – Pascal. Какая польза от этого простого определения для Java-разработчика? Или для кого-то, кто работает с VB? Нам нужно что-то, что будет понятно всем, даже VB-программистам. Так дайте им XML, содержащий одну и ту же инфрмацию (параметры, значения биржевых котировок и т.д.). Вы создаете SOAP пакет, который по сути является вызовом вашей функции, обернутый в XML, чтобы любое приложения на любой платформе могло его понять. Теперь посмотрим, как выглядит наш SOAP вызов:
Информативно, правда? SOAP упрощается на глазах. Ладно, шутки в сторону. Теперь я постараюсь объяснить вам, как разобраться в этом SOAP вызове.
Расшифровка тегов
Лирическое отступление на счет пространств имен: Пространство имен дает возможность квалифицировать XML тег. Нельзя, к примеру, иметь две переменные с одинаковым именем в одной процедуре, но если они в двух разных процедурах, проблем не возникает. Таким образом процедура – это пространство имен, так как все имена в ней уникальны. Точно так же XML теги имеют свою область видимости внутри пространств имен, так что имея пространство имен и имя тега, можно однозначно его идентифицировать. Мы определим пространство имен как URI, чтобы отличать наш NS1 от подражателей. В приведенном выше примере NS1 – это алиас, указывающий на urn:xmethods-quotes.
Обратите внимание также на атрибут encodingStyle – этот атрибут определяет каким образом сериализуется SOAP вызов.
Внутри тега указано «IBM». Это – значение параметра symbol функции GetStockQuote.
Ну и в конце, как порядочные люди, мы закрыли все теги.
Вот и разобрались с SOAP пакетом, определяющим вызов к SOAP серверу. А SOAP сервер с помощью XML парсеров, красной кнопки и космической станции «МИР» декодирует этот вызов и определяет, что вам нужна биржевая котировка. Он тут же находит нужную котировку и возвращает вам ее в таком виде:
После разворачивания SOAP конверта, срывания ленточек и шуршания оберткой, мы узнаем, что цена акции IBM – 34.5.
Большинство коммерческих серверов вернуло бы гораздо больше информации, например, в какой валюте и за какую цену была куплена последняя акция. Да и цена акции, пожалуй, была бы поточнее.
Таким образом мы знаем, чего ожидает SOAP сервер и что он вернет. Так КАК же отправить эту информацию? Использовать можно любой транспорт. Самым освещенным является HTTP. Я не стану вдаваться в подробности HTTP, для тех, кто не знает – это то, что использует ваш браузер, чтобы общаться с сайтами, на которые вы заходите.
Нужный HTTP запрос будт выглядеть приблизительно так:
Единственное, что еще стоит отметить – это заголовок SOAPAction. Этот заголовок указывает на цель запроса и является обязательным. Каждый SOAP сервер может иметь неограниченное количество функций и может использовать заголовок SOAPAction чтобы определить какую функцию вызывают. Брандмауэры и мультиплексоры также могут фильтровать контент на основании этого заголовка.
SOAP ответ от HTTP сервера будет выглядеть следующим образом:
Почему HTTP? Во-первых, сетевым администраторам не придется открывать уйму отдельных портов для SOAP вызовов. веб-сервер может спокойно обрабатывать вызовы, т.к. 80-й порт обычно открыт для всех для приема входящих запросов. Еще одним преимуществом является расширяемость веб-серверов с помощью CGI, ISAPI и других нативных модулей. Эта расширяемость позволяет написать модуль, обрабатывающий SOAP запросы не задевая другого веб-контента.
Надеюсь, эта статья помогла пролить немного света на SOAP. Если вы еще здесь и хотите почитать больше на эту тему, посетите сайт авторов: http://www.agnisoft.com/soap
Если Вам понравилась статья, проголосуйте за нее
Голосов: 15 Голосовать 
Soap envelope что это
Применение SOAP при интеграции систем
Для начинающих аналитиков,
не имеющих опыта web-разработки
В предыдущей статье мы говорили про то, что REST — это архитектурный стиль, который Рой Филдинг сформулировал в своей диссертации в 2000 году.
С протоколом SOAP дела обстоят несколько иначе.
SOAP — это не стиль, а протокол. Аббревиатура SOAP так и расшифровывается: Simple Object Access Protocol — простой протокол доступа к объектам. То есть правила передачи информации в SOAP строго стандартизированы, есть спецификация, которой нужно соответствовать.
SOAP появился 1998 году и был передан в организацию World Wide Web Consortium (W3C) — международная организация, которая курирует развитие интернета.
Почему разница в 2 года в появлении REST и SOAP так сказалась на их популярности?
Если сравнить это с тем фактом, что Рой Филдинг просто представил REST в своей диссертации, то вы поймете, почему SOAP завоевал популярность очень быстро.
Тем не менее на данный момент можно говорить о том, что в основном для интеграции систем используется REST.
Для того, чтобы наглядно показать отличие REST от SOAP, приведем вот такую аналогию. Представьте себе дерево, в котором есть дупло, и из этого дупла выглядывает птичка. Когда вы обращаетесь к какому-то приложению, вы как будто обращайтесь к такому дереву и стучитесь в окошко. Условно можно считать, что в это окошко выглядывает некоторая функция.
Если вы работаете с REST, то можно себе представить дерево, в котором есть много таких окошек — большое количество птичек, каждая из которых выглядывает из своего дупла. Это дупло называется Endpoint, но это отдельный разговор. Важно, что каждый раз, обращаясь к дуплу, вы обращаетесь только к одной функции.
SOAP основывается на технологии удаленного вызова процедур. Сервис, который работает на базе SOAP — это дерево с одним-единственным дуплом. Но каждый раз, обращаясь к этому дуплу, вы должны указать название процедуры, то есть название функции, которую вы хотите вызвать, потому что функций там может быть несколько. И, разумеется, вы должны передать те входные данные, которые нужны для процедуры, которую вы собираетесь вызвать.
В SOAP передача данных идет по протоколу HTTP, то есть также, как это происходит и в случает REST-запросов.
Давайте рассмотрим на примере. Если я зайду на сайт какой-нибудь биржи акций, то могу узнать курс интересующей меня акции. Откуда поступает эта информация? Давайте разберемся.
Я открываю на своем компьютере браузер, который является клиентом. По протоколу HTTP он обращается к серверу (назовем его HTTP-server).
На этом HTTP-сервере живёт приложение, которое отдает мне информацию, о том, что акция Facebook стоит, к примеру, 252 доллара. Однако, откуда само приложение, живущее на HTTP-сервере, знает стоимость акции?
А все очень просто — приложение в данном случае выступило как SOAP-client и запросило эту информацию на другом сервере (назовем его SOAP-server).
Взаимодействие SOAP-client и SOAP-server происходит по протоколу SOAP поверх HTTP. Что значит поверх? Это значит, что клиент и сервер общаются по протоколу HTTP, но по этому протоколу передаётся не просто стандартное сообщение HTTP, а некий конвертик с письмом, причем это письмо написано по правилам протокола SOAP.
То есть сайт, который передал мне информацию о Facebook, сам запросил SOAP-server (то есть биржу акций) по протоколу HTTP и вложил сообщение в конвертик SOAP.
Таким образом, информация о курсе акции пришла ко мне не напрямую с биржи, а через посредника — через SOAP-client.
Когда мы работаем по сети, мы работаем с протоколами TCP/IP — это нижний, сетевой уровень протоколов. Весь интернет базируется на протоколе HTTP, который мы рассматривали в предыдущей статье. HTTP является просто транспортом, с помощью которого информация передается по сети.
Чтобы передать какое-либо сообщение по сети, оно должно соответствовать правилам протокола HTTP. А дальше в пакетик, передаваемый по протоколу HTTP, вкладывается сообщение по протоколу SOAP. И все это живет по правилам, описанным в файле WSDL.
Представьте себе, что вы хотите передать по сети некоторую записочку. И вы хотите, чтобы информация в ней была структурирована так, чтобы записку могла прочитать программа.
В качестве примера приведу записку, которую Анна пишет Марии: «Приходи ко мне в гости в воскресенье!». И заголовок: «Напоминалка» (Reminder). Здесь могла бы быть ещё подпись signature, но, как видите, подпись оказалась пустой, информация в теге не передана (такое тоже возможно).
Тег — это текстовая строка, завернутая в уголочки (<>).
То есть, когда мы передаем XML-документ, мы информацию «заворачиваем» в теги. Они предназначены для того, чтобы объяснять, что лежит внутри. Теги бывают открывающие (перед текстовым содержимым) и закрывающие (начинается с символа «/»).
В HTML такие же теги, но они применяются немного по-другому: в языке XML эти теги предназначены для того, чтобы объяснить приложению, которое принимает сообщение, что именно вложено внутрь.
Приложение, которое принимает записку, заранее знает, какие должны прийти данные внутри каких тегов. И знает оно это благодаря WSDL.
Что такое WSDL? В SOAP для описания своего сервиса нужно использовать строгие правила в виде файлов WSDL. Ниже мы разберем это подробнее, но вообще WSDL — это Web Services Description Language, ещё один язык описания веб-сервисов и доступа к ним.
Разберем приведенный ранее пример детальнее.
Первая строка документа — XML-декларация, она указывает на версию XML ( version=»1.0″ ) и тип кодировки документа ( encoding=»utf-8″ ).
Что ещё есть в xml-документе?
Всё XML-сообщение (наша записочка) заворачивается в так называемый корневой тег. В данном случае, корневым является тег note, который выделен зеленым.
Правильно оформленный XML это такой XML, который соответствует стандартам языка и может быть разобран приложением, то есть приложение его получит, проверит синтаксис и начнет разбирать.
Важно понимать, что приложение не будет разбирать XML если он не будет правильно оформлен. В этом случае приложение придёт к выводу, что XML повредили или подменили по дороге.
Если мы посмотрим на XML-документ внимательно, то сможем построить вот такое дерево:
То есть с точки зрения приложения XML представляет собой дерево, состоящее из узлов. Например на картинке вы можете видеть имена узлов: note, to, from, heading, body, signature.
Узлы вкладываются друг друга, и получается, что XML-документ можно представить в виде перевернутого дерева, только дерево растет вниз. Тeг note является корнем и в него вложены остальные теги, все они являются детьми этого корня. Кроме того, есть ещё текстовых узлы Мария, Анна и т. д.
Разговоры о том, что какая-то буква потерялась, не очень актуальны сейчас, так как современные протоколы обеспечивают целостную доставку. Данный пример призван продемонстрировать, что XML-документ в первую очередь создаётся для того, чтобы информацию вкладывать в теги.
Атрибуты — это пары имя/значение, поставленные в соответствие одному из элементов. Они должны находиться при открывающем теге, но не при закрывающем.
Атрибуты всегда должны иметь значение, даже если значением является всего лишь пустая строка. Значения атрибутов должны заключаться в кавычки. При этом согласно синтаксису XML допускаются как двойные, так и одинарные кавычки.
Если вам придется руками формировать XML-документ, никогда не пишите в одном документе и двойные и одинарные кавычки, просто потому что вам лень аккуратненько расставить однотипные, поскольку это может привести к ошибкам.
Чтобы наглядно объяснить, что такое пространство имён, рассмотрим следующий пример.
Например, в первом случае тег table — это текст, который используется в языке HTML для указания того факта, что дальше идет описание таблицы. А во втором — предназначен для того, чтобы описать африканский кофейный стол и его размеры.
Как сделать так, чтобы приложение определило, что это разные теги table?
Чтобы раскрыть тему, давайте рассмотрим бытовую аналогию: как учителя различают детей, которые приходят в класс.
У себя дома имя мальчика Серёжи, скорее всего, является уникальным идентификатором. То есть, вероятнее всего, ни одного Серёжи в семье больше нет. Но когда Серёжа приходит в школу, он обнаруживает, что в классе ещё три Серёжи, и учителю их надо как-то различать.
Как это сделать? Как правило, в классе для этого используется фамилия ребенка. Но если в классе есть однофамильцы Серёжи? Что ж, и такое бывает. В этом случае отличать Серёж можно по их домашнему адресу.
Интересный момент: если учитель знает, что Серёжа Васильев живёт по этому адресу, а тут в класс приходит некая Аня Васильева, живущая по этому же адресу, то можно сделать логичный вывод, что, скорее всего, Серёжа и Аня — брат и сестра. Именно адрес и указывает учителю на то, какая это семья и где она живёт. В XML-документах точно такая же логика.
Если нам нужно определить пространство имён (семью), к которому относится тег, мы заводим специальный атрибут. Этот атрибут называется XML namespace, сокращенно xmlns. Именно в xmlns мы пишем адрес — то место, где публикуется стандарт стандарта языка (то есть в атрибуте xmlns указывается адрес документа, в котором явно описано, что такое table для документа HTML).
В случае с кофейным столиком мы, разумеется, пишем другой адрес. Интересно, что это может быть абсолютно любой адрес, он может даже не существовать на самом деле, поскольку используется только для идентификации. То есть, вот этот тег table живет по этому конкретному адресу, и там же живёт вся его семья.
Что из себя представляет семья тегов?
Правило такое: если тег, у которого указано пространство имён, содержит вложенные теги, то эти вложенные теги относятся к тому же пространству имён.
Ранее в примерах мы говорили про обмен данными между сайтом и биржей акций. Как это происходит?
Чтобы отправить запрос в биржу акций, нужно ответить на простой вопрос. Facebook и сайт биржи акций должны ответить «252.36» — это содержимое, которое надо передать. Протокол SOAP предполагает, что это текстовое содержимое вложено внутрь XML-тегов и прописано в стандарте в виде XML-дерева.
Давайте разберем на составляющие данный запрос.
Envelope и Body — теги, которые прописаны в протоколе SOAP. То есть, если вы отправляете запрос по протоколу SOAP, то у вас должен быть тег Envelope и вложенный в него тег Body. Это нужно просто запомнить.
SOAP-ENV — обозначение пространства имён, то есть теги Envelope и Body относятся к пространству имён SOAP-овского окружения и это не что иное, как краткое указание на то, что есть определенное семейство тегов. А где описывается пространство имён, мы разберем немного позже.
getQuote (получить котировку) — имя процедуры, которую мы хотим вызвать. Она относится уже к другому пространству имён, а именно «ns1».
« Faсebook » — это входной параметр, который мы передаем, и он завернут в тег Symbol. Обратите внимание на атрибут, который есть в этом теге «string» — он описывает, что передаваться должно не число, а строка.
Давайте теперь вернемся к WSDL — документу, благодаря которому приложение заранее знает, какие должны прийти данные внутри каких тегов.
Основные теги с которыми вы столкнетесь в описании WSDL-сервера:
Как все это выглядит?
На веб-сервисе лежит файл WSDL. И клиент, и сервер руководствуются в своей работе этим файлом: читают его и разбираются, как устроен сервис. И клиент, и сервер умею читать этот файл и получать из него информацию, так как они знают стандарт SOAP и то, как должен быть устроен файл WSDL.
Давайте разберем этот wsdl-файл:
Operation — это тег, который описывает функции. То есть он указывает на имя функции и то, как должен выглядеть запрос и ответ.
Вложенные в operation теги input и output содержат информацию о входных и выходных параметрах функции. То есть getQuoteRequest — это запрос, который представляет собой строку и должен иметь вид числа с плавающей точкой.
Тег binding описывает все технические сведения, о том, что из себя представляет сервис.
Тег servisce описывает, где живет наш сервис. Если бы мы установили веб-сервисом на локальной машине, то адрес написали бы следующим образом: localhost/server1. php/.
Если вы захотите расписать WSDL в виде дерева, то получите следующую картину:
Корневой тег definitions содержит 2 тега message, описывающие входной и выходной параметры.
Далее идет тег portType, включающий в себя тег operation, который также описывает входной и выходной параметры. PortType же собирает вместе информацию из двух тегов message.
Тег binding описывает все технические особенности нашего сервера. Считается довольно сложным в прочтении для начинающих.
Тег service содержит описание нашего сервера.
Главным недостатком SOAP является то, что при его использовании для передачи сообщений, он увеличивает их объём и снижает скорость обработки.
Мы смогли в этом убедиться на примере вопроса «Facebook» и ответа «252.36», которые требуют огромного количества тегов, в которые заворачивается вопрос.
Для того, чтобы еще раз сравнить SOAP и REST, я привела преимущества приложения, созданного на основании REST:
Для SOAP необходимо специальное приложение, чтобы разобрать XML-документ, распарсить его, как говорят в ИТ-среде.
Относительно легкости внесения изменений хочется заметить: для того, чтобы изменить WSDL, мы, разумеется, можем изменить адрес, но это непросто. SOAP — консервативный протокол, он используется преимущественно в Legacy-системах, но, тем ни менее, знание SOAP пользуется достаточно большим спросом.