Soap протокол что это: Что такое SOAP? — Stack Overflow на русском

Введение в SOAP

[Disclaimer: Данная статья была переведена в рамках «Конкурса на лучший перевод статьи» на сервисе Quizful. Ссылка на оригинал находится внизу страницы.]

Что такое 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 вызов:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" 
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<ns1:GetStockQuote xmlns:ns1="urn:xmethods-quotes">
<SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<symbol xsi:type="xsd:string">IBM</symbol> 
</ns1:GetStockQuote> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope>

Информативно, правда? SOAP упрощается на глазах. Ладно, шутки в сторону. Теперь я постараюсь объяснить вам, как разобраться в этом SOAP вызове.

Расшифровка тегов

Первый тег, который бросается в глаза – это . Этот тег – внешняя оболочка SOAP пакета, содержащая несколько объявлений пространств имен, которые нас особо не интересуют, но очень важны для любого языка программирования или парсера. Пространства имен определяются для того, чтобы последующие префиксы, такие как «SOAP-ENV:» или «xsd:» воспринимались парсером.

Следующий тег – <SOAP-ENV:Body>. (Мы пропустили тег, не представленный здесь – <SOAP-ENV:Header>. Его нет в этом конкретном примере, но если вы хотите почитать о нем больше, обратитесь к спецификации SOAP здесь: http://www.w3.org/TR/SOAP/). Тег <SOAP-ENV:Body> собственно и содержит SOAP вызов.

Следующий тег в списке – <ns1:GetStockQuote …>. Имя тега, GetStockQuote и есть вызываемая функция. Согласно терминологии SOAP, это называется операцией. Таким образом GetStockQuote – операция, которая должна быть выполнена. ns1 – это пространство имен, указывающее на urn:xmethods-quotes в нашем случае.

Лирическое отступление на счет пространств имен: Пространство имен дает возможность квалифицировать XML тег. Нельзя, к примеру, иметь две переменные с одинаковым именем в одной процедуре, но если они в двух разных процедурах, проблем не возникает. Таким образом процедура – это пространство имен, так как все имена в ней уникальны. Точно так же XML теги имеют свою область видимости внутри пространств имен, так что имея пространство имен и имя тега, можно однозначно его идентифицировать. Мы определим пространство имен как URI, чтобы отличать наш NS1 от подражателей. В приведенном выше примере NS1 – это алиас, указывающий на urn:xmethods-quotes.

Обратите внимание также на атрибут encodingStyle – этот атрибут определяет каким образом сериализуется SOAP вызов.

Внутри тега <GetStockQuote> содержатся параметры. В нашем простейшем случаи у нас есть только один параметр – тег <symbol>. Обратите внимание на эту строку возле тега:

xsi:type="xsd:string"

Приблизительно так в XML и определяются типы. (Обратите внимание на то, как хитро я использовал слово «приблизительно», делая обобщение о технологии, которая может измениться как только статья будет опубликована). Что конкретно это означает: тип, определенный в пространстве имен xsi, который, как вы заметили, определен в теге – xsd:string. А это в свою очередь string, определенный в пространстве имен xsd, опять-таки, определенном ранее. (Уверен, юристы бы от этого всего просто млели).

Внутри тега <symbol> указано «IBM». Это – значение параметра symbol функции GetStockQuote.

Ну и в конце, как порядочные люди, мы закрыли все теги.

Вот и разобрались с SOAP пакетом, определяющим вызов к SOAP серверу. А SOAP сервер с помощью XML парсеров, красной кнопки и космической станции «МИР» декодирует этот вызов и определяет, что вам нужна биржевая котировка. Он тут же находит нужную котировку и возвращает вам ее в таком виде:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" 
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
<SOAP-ENV:Body>
<m:GetStockQuoteResponse xmlns:m="urn:xmethods-quotes">
<Price>34.5</Price>
</m:GetStockQuoteResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

После разворачивания SOAP конверта, срывания ленточек и шуршания оберткой, мы узнаем, что цена акции IBM – 34.5.

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

Таким образом мы знаем, чего ожидает SOAP сервер и что он вернет. Так КАК же отправить эту информацию? Использовать можно любой транспорт. Самым освещенным является HTTP. Я не стану вдаваться в подробности HTTP, для тех, кто не знает – это то, что использует ваш браузер, чтобы общаться с сайтами, на которые вы заходите.

Нужный HTTP запрос будт выглядеть приблизительно так:

POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
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

———-
Оригинальный текст статьи: Introduction to SOAP

Протокол SOAP | Computerworld Россия

Определение

Simple Object Access Protocol (SOAP) — это протокол на базе языка XML, который определяет правила передачи сообщений по Internet между различными прикладными системами. В основном он используется для удаленного вызова процедур. Изначально протокол SOAP разрабатывался с тем расчетом, что он будет функционировать «над» HTTP (дабы упростить интеграцию SOAP в Web-приложения), однако теперь могут быть задействованы и иные транспортные протоколы, например SMTP.

Предположим, что вы создаете в Internet службу доступа к приложениям; потребители взаимодействуют с этой службой, передавая ей информацию. Ваши серверы обрабатывают данные и возвращают результаты потребителям. Как лучше всего поддерживать обмен данными с системой?

Вы могли бы создать настраиваемое клиент-серверное приложение и потребовать, чтобы потребители использовали для доступа к вашей службе специальную клиентскую программу. Но если вы намерены всерьез найти себя в Internet-бизнесе, вам придется создать клиент, работающий на всех возможных клиентских платформах — Windows, Macintosh, Unix, Linux и т. д. Другими словами, потребуется написать множество различных клиентов.

А как вы отнесетесь к использованию Web? Такое решение, естественно, вполне приемлемо, но жестко завязано на реализации браузера, и вам опять-таки придется создавать инфраструктуру, чтобы посылать и получать входящую и исходящую информацию, а также форматировать и упаковывать данные для подобного обмена. Для реализации сложных приложений можно выбрать Java или ActiveX, но тогда некоторые пользователи откажутся от ваших услуг из-за явно завышенных требований к полосе пропускания и неадекватной защиты.

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

Достаточно подробно описанный Simple Object Access Protocol (SOAP) представляет собой простой «связующий» протокол, с помощью которого узлы могут удаленно вызывать объекты приложения и возвращать результаты. SOAP предлагает минимальный набор условий, позволяющий приложению передавать сообщения: клиент может посылать сообщение для того, чтобы вызывать программный объект, а сервер может возвращать результаты этого вызова.

SOAP довольно прост: сообщения представляют собой документы XML, содержащие команды SOAP. Хотя теоретически SOAP может быть привязан к любому транспортному протоколу для приложений, как правило, он используется вместе с HTTP.

Кеннард Скрибнер, один из авторов книги Understanding SOAP: The Authoritative Solution (Macmillan USA, 2000), говорит, что SOAP работает за счет преобразования информации, необходимой для вызова метода (например, сюда относятся значения аргументов и идентификаторы транзакций) в формат XML.

Данные инкапсулируются в HTTP или в какой-то другой транспортный протокол и передаются адресату, в качестве которого обычно выступает сервер. Этот сервер выделяет данные SOAP из пакета, выполняет требуемую обработку и возвращает результаты в виде ответа SOAP.

Скрибнер отметил, что SOAP действует как протокол удаленного вызова процедур, во многом так же, как протокол Remote Method Invocation в Java или General Inter-ORB Protocol в CORBA.

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

SOAP не заменяет собой протокол Remote Method Invocation в Java, Distributed Component Object Model и CORBA; он предлагает правила, которые могут использоваться любой из этих моделей. SOAP не является полным решением. Он не поддерживает активацию объектов или защиту. По словам Скрибнера, разработчики SOAP «уверены в том, что пользователи самостоятельно добавят этот код», надстраивая его над SOAP, вместо того чтобы делать его составной частью самого протокола.

На рисунке приводится пример, взятый из спецификации SOAP 1.1, в котором хост запрашивает у службы котировок стоимость определенной акции. Запрос SOAP встраивается в HTTP POST, а в теле запроса указывается тип запроса и параметр — символ акции. Ответ также предоставляет собой объект XML, инкапсулированный в ответ HTTP с единственным возвращаемым значением (34,5 в данном случае).

Особенности SOAP

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

По мнению Марка Стивера, еще одного автора книги Understanding SOAP, именно эту цель преследует Microsoft в своей перспективной платформе .Net. «Здесь SOAP выступает во всем своем блеске. Он дает разработчикам действительно прекрасные возможности для создания приложений, избавляя их от мучений по поводу вероятной несовместимости», — утверждает он.

Пит Лошин — консультант, автор более двадцати книг об Internet. С ним можно связаться по электронной почте по адресу: [email protected]

---

Пример SOAP

Следующий пример иллюстрирует запрос SOAP, называемый GetLastTradePrice, который позволяет клиенту послать запрос о последних котировках определенных акций.

POST/StockQuote HTTP/1.1
Host: www.stockquoteserver.com

Content-Type: text/xml; charset=»utf-8″

Content-Length: nnnn

SOAPAction: «Some-URI»

DIS

В первых пяти строчках (часть заголовка HTTP) указывается тип сообщения (POST), хост, тип и длина информационного наполнения, а заголовок SOAPAction определяет цель запроса SOAP. Само сообщение SOAP представляет собой документ XML, где сначала идет конверт SOAP, затем элемент XML, который указывает пространство имен SOAP и атрибуты, если таковые имеются. Конверт SOAP может включать в себя заголовок (но не в данном случае), за которым следует тело SOAP. В нашем примере в теле содержится запрос GetLastTradePrice и символ акций, для которых запрашиваются последние котировки. Ответ на этот запрос может выглядеть следующим образом.

HTTP/1.1 200 OK
Content-Type: text/xml; charset=»utf-8″

Content-Length: nnnn

34,5

И опять-таки первые три строки — это часть заголовка HTTP; само сообщение SOAP состоит из конверта, который содержит ответ на исходный запрос, помеченный GetLastTradePriceResponse, и включает в себя возвращаемое значение, в нашем случае 34,5.

Поделитесь материалом с коллегами и друзьями

SOAP — Краткое руководство — CoderLessons.com

SOAP — это сокращение от Simple Object Access Protocol. Это протокол обмена сообщениями на основе XML для обмена информацией между компьютерами. SOAP является приложением спецификации XML.

Указывает на заметку

• SOAP — это протокол связи, предназначенный для связи через Интернет.

• SOAP может расширить HTTP для обмена сообщениями XML.

• SOAP обеспечивает транспорт данных для веб-сервисов.

• SOAP может обмениваться полными документами или вызывать удаленную процедуру.

• SOAP может использоваться для трансляции сообщения.

• SOAP не зависит от платформы и языка.

• SOAP — это способ определения, какая информация отправляется и каким образом.

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

SOAP — это протокол связи, предназначенный для связи через Интернет.

SOAP может расширить HTTP для обмена сообщениями XML.

SOAP обеспечивает транспорт данных для веб-сервисов.

SOAP может обмениваться полными документами или вызывать удаленную процедуру.

SOAP может использоваться для трансляции сообщения.

SOAP не зависит от платформы и языка.

SOAP — это способ определения, какая информация отправляется и каким образом.

SOAP позволяет клиентским приложениям легко подключаться к удаленным службам и вызывать удаленные методы.

Хотя SOAP может использоваться в различных системах обмена сообщениями и может доставляться через различные транспортные протоколы, первоначальная цель SOAP — удаленные вызовы процедур, транспортируемые через HTTP.

Другие платформы, в том числе CORBA, DCOM и Java RMI, предоставляют функциональность, аналогичную SOAP, но сообщения SOAP написаны полностью на XML и поэтому уникально независимы от платформы и языка.

SOAP-сообщение — это обычный XML-документ, содержащий следующие элементы:

• Конверт — определяет начало и конец сообщения. Это обязательный элемент.

• Заголовок — содержит любые необязательные атрибуты сообщения, используемые при обработке сообщения, либо в промежуточной точке, либо в конечной конечной точке. Это необязательный элемент.

• Тело — содержит данные XML, содержащие отправляемое сообщение. Это обязательный элемент.

• Неисправность — необязательный элемент неисправности, который предоставляет информацию об ошибках, возникающих при обработке сообщения.

Конверт — определяет начало и конец сообщения. Это обязательный элемент.

Заголовок — содержит любые необязательные атрибуты сообщения, используемые при обработке сообщения, либо в промежуточной точке, либо в конечной конечной точке. Это необязательный элемент.

Тело — содержит данные XML, содержащие отправляемое сообщение. Это обязательный элемент.

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

Все эти элементы объявлены в пространстве имен по умолчанию для конверта SOAP — http://www.w3.org/2001/12/soap-envelope, а пространство имен по умолчанию для кодировки SOAP и типов данных — http: //www.w3 .org / 2001/12 / мыла-кодирования

ПРИМЕЧАНИЕ. — Все эти характеристики могут быть изменены. Так что продолжайте обновлять себя новейшими спецификациями, доступными на сайте W3.

Структура сообщения SOAP

Следующий блок отображает общую структуру сообщения SOAP —

<?xml version = "1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope" 
   SOAP-ENV:encodingStyle = "http://www.w3.org/2001/12/soap-encoding">

   <SOAP-ENV:Header>
      ...
      ...
   </SOAP-ENV:Header>
   <SOAP-ENV:Body>
      ...
      ...
      <SOAP-ENV:Fault>
         ...
         ...
      </SOAP-ENV:Fault>
      ...
   </SOAP-ENV:Body>
</SOAP_ENV:Envelope>

Конверт SOAP указывает начало и конец сообщения, чтобы получатель знал, когда было получено все сообщение. Конверт SOAP решает проблему определения того, когда вы получили сообщение и готовы его обработать. Поэтому конверт SOAP — это, по сути, механизм упаковки.

Указывает на заметку

• Каждое сообщение SOAP имеет корневой элемент Envelope.

• Конверт является обязательной частью сообщения SOAP.

• Каждый элемент Envelope должен содержать ровно один элемент Body.

• Если конверт содержит элемент заголовка, он должен содержать не более одного элемента и должен отображаться как первый дочерний элемент конверта перед телом.

• Конверт изменяется при изменении версий SOAP.

• Конверт SOAP указывается с использованием префикса пространства имен ENV и элемента Envelope.

• Необязательная кодировка SOAP также указывается с использованием имени пространства имен и необязательного элемента encodingStyle , который также может указывать на стиль кодирования, отличный от стиля SOAP.

• SOAP-процессор, совместимый с v1.1, генерирует ошибку при получении сообщения, содержащего пространство имен конверта v1.2.

• SOAP-процессор, совместимый с v1.2, генерирует ошибку VersionMismatch, если он получает сообщение, которое не включает пространство имен конверта v1.2.

Каждое сообщение SOAP имеет корневой элемент Envelope.

Конверт является обязательной частью сообщения SOAP.

Каждый элемент Envelope должен содержать ровно один элемент Body.

Если конверт содержит элемент заголовка, он должен содержать не более одного элемента и должен отображаться как первый дочерний элемент конверта перед телом.

Конверт изменяется при изменении версий SOAP.

Конверт SOAP указывается с использованием префикса пространства имен ENV и элемента Envelope.

Необязательная кодировка SOAP также указывается с использованием имени пространства имен и необязательного элемента encodingStyle , который также может указывать на стиль кодирования, отличный от стиля SOAP.

SOAP-процессор, совместимый с v1.1, генерирует ошибку при получении сообщения, содержащего пространство имен конверта v1.2.

SOAP-процессор, совместимый с v1.2, генерирует ошибку VersionMismatch, если он получает сообщение, которое не включает пространство имен конверта v1.2.

v1.2-совместимое сообщение SOAP

Ниже приведен пример сообщения SOAP, совместимого с v1.2.

<?xml version = "1.0"?>
<SOAP-ENV:Envelope 
   xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope" 
   SOAP-ENV:encodingStyle = " http://www.w3.org/2001/12/soap-encoding">
   ...
   Message information goes here
   ...
</SOAP-ENV:Envelope>

SOAP с HTTP POST

В следующем примере показано использование сообщения SOAP в операции HTTP POST, которая отправляет сообщение на сервер. Он показывает пространства имен для определения схемы конверта и для определения схемы правил кодирования. Ссылка OrderEntry в заголовке HTTP — это имя программы, которая будет вызываться на веб-сайте tutorialspoint.com.

POST /OrderEntry HTTP/1.1
Host: www.tutorialspoint.com
Content-Type: application/soap; charset = "utf-8"
Content-Length: nnnn

<?xml version = "1.0"?>
<SOAP-ENV:Envelope 
   xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope" 
   SOAP-ENV:encodingStyle = " http://www.w3.org/2001/12/soap-encoding">
   ...
   Message information goes here
   ...
</SOAP-ENV:Envelope>

ПРИМЕЧАНИЕ. — Привязка HTTP указывает местоположение службы.

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

Указывает на заметку

• Это необязательная часть сообщения SOAP.

• Элементы заголовка могут встречаться несколько раз.

• Заголовки предназначены для добавления новых функций и возможностей.

• Заголовок SOAP содержит записи заголовка, определенные в пространстве имен.

• Заголовок закодирован как первый непосредственный дочерний элемент конверта SOAP.

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

Это необязательная часть сообщения SOAP.

Элементы заголовка могут встречаться несколько раз.

Заголовки предназначены для добавления новых функций и возможностей.

Заголовок SOAP содержит записи заголовка, определенные в пространстве имен.

Заголовок закодирован как первый непосредственный дочерний элемент конверта SOAP.

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

Атрибуты заголовка SOAP

Заголовок SOAP может иметь следующие два атрибута:

Атрибут актера

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

Атрибут MustUnderstand

Указывает, является ли элемент Header необязательным или обязательным. Если установлено значение true, получатель должен понимать и обрабатывать атрибут Header в соответствии с его определенной семантикой или возвращать ошибку.

В следующем примере показано, как использовать заголовок в сообщении SOAP.

<?xml version = "1.0"?>
<SOAP-ENV:Envelope 
   xmlns:SOAP-ENV = " http://www.w3.org/2001/12/soap-envelope"   
   SOAP-ENV:encodingStyle = " http://www.w3.org/2001/12/soap-encoding">

   <SOAP-ENV:Header>
      <t:Transaction 
         xmlns:t = "http://www.tutorialspoint.com/transaction/" 
         SOAP-ENV:mustUnderstand = "true">5
      </t:Transaction>
   </SOAP-ENV:Header>
   ...
   ...
</SOAP-ENV:Envelope>

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

Тело определяется как дочерний элемент оболочки, а семантика для тела определяется в связанной схеме SOAP.

Тело содержит обязательную информацию, предназначенную для конечного получателя сообщения. Например —

<?xml version = "1.0"?>
<SOAP-ENV:Envelope>
   ........
   <SOAP-ENV:Body>
      <m:GetQuotation xmlns:m = "http://www.tp.com/Quotation">
         <m:Item>Computers</m:Item>
      </m:GetQuotation>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

В приведенном выше примере запрашивается расценка компьютерных комплектов. Обратите внимание, что элементы m: GetQuotation и Item выше являются специфичными для приложения элементами. Они не являются частью стандарта SOAP.

Вот ответ на вышеуказанный запрос —

<?xml version = "1.0"?>
<SOAP-ENV:Envelope>
   ........
   <SOAP-ENV:Body>
      <m:GetQuotationResponse xmlns:m = "http://www.tp.com/Quotation">
         <m:Quotation>This is Qutation</m:Quotation>
      </m:GetQuotationResponse>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Обычно приложение также определяет схему, содержащую семантику, связанную с элементами запроса и ответа.

Сервис Quotation может быть реализован с использованием EJB, работающего на сервере приложений; в этом случае процессор SOAP будет отвечать за отображение информации тела в качестве параметров в и из реализации EJB службы GetQuotationResponse . Процессор SOAP также может отображать информацию тела в объект .NET, объект CORBA, программу COBOL и так далее.

Если во время обработки возникает ошибка, ответ на сообщение SOAP является элементом ошибки SOAP в теле сообщения, и ошибка возвращается отправителю сообщения SOAP.

Механизм сбоя SOAP возвращает конкретную информацию об ошибке, включая предопределенный код, описание и адрес процессора SOAP, который сгенерировал сбой.

Указывает на заметку

• Сообщение SOAP может содержать только один блок отказа.

• Ошибка является необязательной частью сообщения SOAP.

• Для привязки HTTP успешный ответ связан с диапазоном кодов состояния от 200 до 299.

• Ошибка SOAP связана с диапазоном кодов состояния от 500 до 599.

Сообщение SOAP может содержать только один блок отказа.

Ошибка является необязательной частью сообщения SOAP.

Для привязки HTTP успешный ответ связан с диапазоном кодов состояния от 200 до 299.

Ошибка SOAP связана с диапазоном кодов состояния от 500 до 599.

Подэлементы неисправности

Ошибка SOAP имеет следующие подэлементы —

Sr.No	Подэлемент и описание
1	<faultCode> Это текстовый код, используемый для обозначения класса ошибок. В следующей таблице приведен список предопределенных кодов ошибок.
2	<faultString> Это текстовое сообщение, объясняющее ошибку.
3	<faultActor> Это текстовая строка, указывающая, кто вызвал ошибку. Это полезно, если сообщение SOAP проходит через несколько узлов в пути сообщения SOAP, и клиент должен знать, какой узел вызвал ошибку. Узел, который не действует как конечный пункт назначения, должен включать элемент faultActor .
4	<подробно> Это элемент, используемый для передачи сообщений об ошибках приложения. Элемент detail может содержать дочерние элементы, называемые элементами detail.

<faultCode>

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

<faultString>

Это текстовое сообщение, объясняющее ошибку.

<faultActor>

Это текстовая строка, указывающая, кто вызвал ошибку. Это полезно, если сообщение SOAP проходит через несколько узлов в пути сообщения SOAP, и клиент должен знать, какой узел вызвал ошибку. Узел, который не действует как конечный пункт назначения, должен включать элемент faultActor .

<подробно>

Это элемент, используемый для передачи сообщений об ошибках приложения. Элемент detail может содержать дочерние элементы, называемые элементами detail.

Коды ошибок SOAP

Определенные ниже значения faultCode должны использоваться в элементе faultcode при описании неисправностей.

Sr.No	Ошибка и описание
1	SOAP-ENV: VersionMismatch Обнаружено недопустимое пространство имен для элемента конверта SOAP.
2	SOAP-ENV: MustUnderstand Непосредственный дочерний элемент элемента Header с атрибутом mustUnderstand, установленным в «1», не был понят.
3	SOAP-ENV: Клиент Сообщение было неправильно сформировано или содержало неверную информацию.
4	SOAP-ENV: Сервер Возникла проблема с сервером, поэтому сообщение не удалось продолжить.

SOAP-ENV: VersionMismatch

Обнаружено недопустимое пространство имен для элемента конверта SOAP.

SOAP-ENV: MustUnderstand

Непосредственный дочерний элемент элемента Header с атрибутом mustUnderstand, установленным в «1», не был понят.

SOAP-ENV: Клиент

Сообщение было неправильно сформировано или содержало неверную информацию.

SOAP-ENV: Сервер

Возникла проблема с сервером, поэтому сообщение не удалось продолжить.

Пример ошибки SOAP

Следующий код является примером неисправности. Клиент запросил метод с именем ValidateCreditCard , но служба не поддерживает такой метод. Это представляет ошибку запроса клиента, и сервер возвращает следующий ответ SOAP —

<?xml version = '1.0' encoding = 'UTF-8'?>
<SOAP-ENV:Envelope
   xmlns:SOAP-ENV = "http://schemas.xmlsoap.org/soap/envelope/"
   xmlns:xsi = "http://www.w3.org/1999/XMLSchema-instance"
   xmlns:xsd = "http://www.w3.org/1999/XMLSchema">

   <SOAP-ENV:Body>
      <SOAP-ENV:Fault>
         <faultcode xsi:type = "xsd:string">SOAP-ENV:Client</faultcode>
         <faultstring xsi:type = "xsd:string">
            Failed to locate method (ValidateCreditCard) in class (examplesCreditCard) at
               /usr/local/ActivePerl-5.6/lib/site_perl/5.6.0/SOAP/Lite.pm line 1555.
         </faultstring>
      </SOAP-ENV:Fault>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

SOAP включает в себя встроенный набор правил для кодирования типов данных. Это позволяет сообщению SOAP указывать конкретные типы данных, такие как целые числа, числа с плавающей запятой, двойные числа или массивы.

• Типы данных SOAP делятся на две широкие категории — скалярные типы и составные типы.

• Скалярные типы содержат ровно одно значение, такое как фамилия, цена или описание продукта.

• Составные типы содержат несколько значений, таких как заказ на покупку или список котировок акций.

• Типы соединений далее подразделяются на массивы и структуры.

• Стиль кодирования для сообщения SOAP устанавливается через атрибут SOAP-ENV: encodingStyle .

• Чтобы использовать кодировку SOAP 1.1, используйте значение http://schemas.xmlsoap.org/soap/encoding/

• Чтобы использовать кодировку SOAP 1.2, используйте значение http://www.w3.org/2001/12/soap-encoding

• Последняя спецификация SOAP принимает все встроенные типы, определенные XML-схемой. Тем не менее, SOAP поддерживает свое собственное соглашение для определения конструкций, не стандартизированных XML-схемой, таких как массивы и ссылки.

Типы данных SOAP делятся на две широкие категории — скалярные типы и составные типы.

Скалярные типы содержат ровно одно значение, такое как фамилия, цена или описание продукта.

Составные типы содержат несколько значений, таких как заказ на покупку или список котировок акций.

Типы соединений далее подразделяются на массивы и структуры.

Стиль кодирования для сообщения SOAP устанавливается через атрибут SOAP-ENV: encodingStyle .

Чтобы использовать кодировку SOAP 1.1, используйте значение http://schemas.xmlsoap.org/soap/encoding/

Чтобы использовать кодировку SOAP 1.2, используйте значение http://www.w3.org/2001/12/soap-encoding

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

Скалярные Типы

Для скалярных типов SOAP принимает все встроенные простые типы, указанные в спецификации XML-схемы. Это включает в себя строки, числа с плавающей запятой, двойные и целые числа.

В следующей таблице перечислены основные простые типы, взятые из XML-схемы, часть 0 — учебник http://www.w3.org/TR/2000/WD-xmlschema-0-20000407/.

Простые типы, встроенные в XML-схему
Простой тип	Примеры)
строка	Подтвердите, что это электрический.
логический	правда, ложь, 1, 0.
поплавок	-INF, -1E4, -0,0, 12,78E-2, 12, INF, NaN.
двойной	-INF, -1E4, -0,0, 12,78E-2, 12, INF, NaN.
десятичный	-1,23, 0, 123,4, 1000,00.
двоичный	100010
целое число	-126789, -1, 0, 1, 126789.
nonPositiveInteger	-126789, -1, 0.
negativeInteger	-126789, -1.
долго	-1, 12678967543233
ИНТ	-1, 126789675
короткая	-1, 12678
байт	-1, 126
nonNegativeInteger	0, 1, 126789
unsignedLong	0, 12678967543233
Целочисленный Беззнаковый	0, 1267896754
unsignedShort	0, 12678
unsignedByte	0, 126
положительное число	1, 126789.
Дата	1999-05-31, — 05.
время	13: 20: 00.000, 13: 20: 00.000-05: 00

Например, вот ответ SOAP с двойным типом данных —

<?xml version = '1.0' encoding = 'UTF-8'?>
<SOAP-ENV:Envelope 
   xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope"
   xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" 
   xmlns:xsd = "http://www.w3.org/2001/XMLSchema">
   
   <SOAP-ENV:Body>
      <ns1:getPriceResponse 
         xmlns:ns1 = "urn:examples:priceservice"  
         SOAP-ENV:encodingStyle = "http://www.w3.org/2001/12/soap-encoding">
         <return xsi:type = "xsd:double">54.99</return>
      </ns1:getPriceResponse>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Типы соединений

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

Чтобы создать массив, вы должны указать его как массив xsi: type . Массив также должен включать атрибут arrayType . Этот атрибут необходим для указания типа данных для содержащихся элементов и измерений массива.

Например, следующий атрибут задает массив из 10 двойных значений —

arrayType = "xsd:double[10]"

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

arrayType = "xsd:string[5,5]"

Вот пример ответа SOAP с массивом двойных значений:

<?xml version = '1.0' encoding = 'UTF-8'?>
<SOAP-ENV:Envelope
   xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope" 
   xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" 
   xmlns:xsd = "http://www.w3.org/2001/XMLSchema">

   <SOAP-ENV:Body>
      <ns1:getPriceListResponse 
         xmlns:ns1 = "urn:examples:pricelistservice"  
         SOAP-ENV:encodingStyle = "http://www.w3.org/2001/12/soap-encoding">

         <return xmlns:ns2 = "http://www.w3.org/2001/09/soap-encoding"  
            xsi:type = "ns2:Array" ns2:arrayType = "xsd:double[2]">
            <item xsi:type = "xsd:double">54.99</item>
            <item xsi:type = "xsd:double">19.99</item>
         </return>
      </ns1:getPriceListResponse>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Структуры содержат несколько значений, но каждый элемент указан с уникальным элементом доступа. Например, рассмотрим элемент в каталоге продуктов. В этом случае структура может содержать SKU продукта, название продукта, описание и цену. Вот как такая структура будет представлена ​​в сообщении SOAP:

<?xml version = '1.0' encoding = 'UTF-8'?>
<SOAP-ENV:Envelope 
   xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope"
   xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" 
   xmlns:xsd = "http://www.w3.org/2001/XMLSchema">

   <SOAP-ENV:Body>
      <ns1:getProductResponse
         xmlns:ns1 = "urn:examples:productservice" 
         SOAP-ENV:encodingStyle = "http://www.w3.org/2001/12/soap-encoding">
		
         <return xmlns:ns2 = "urn:examples" xsi:type = "ns2:product">
            <name xsi:type = "xsd:string">Red Hat Linux</name>
            <price xsi:type = "xsd:double">54.99</price>
            <description xsi:type = "xsd:string">
               Red Hat Linux Operating System
            </description>
            <SKU xsi:type = "xsd:string">A358185</SKU>
         </return>
      </ns1:getProductResponse>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

ПРИМЕЧАНИЕ. — Пожалуйста, позаботьтесь о правильном отступе при написании кода SOAP. Каждый элемент в структуре указывается с уникальным именем доступа. Например, вышеприведенное сообщение включает в себя четыре элемента доступа — имя, цена, описание и артикул. Каждый элемент может иметь свой собственный тип данных. Например, имя указывается как строка, а цена указывается как двойная.

SOAP не привязан ни к какому транспортному протоколу. SOAP может транспортироваться через SMTP, FTP, IBM MQSeries или Microsoft Message Queuing (MSMQ).

Спецификация SOAP содержит подробности только по HTTP. HTTP остается самым популярным транспортным протоколом SOAP.

SOAP через HTTP

Логично, что SOAP-запросы отправляются через HTTP-запрос, а SOAP-ответы возвращаются в содержимом HTTP-ответа. Хотя запросы SOAP можно отправлять через HTTP GET, в спецификации содержатся сведения только о HTTP POST.

Кроме того, как HTTP-запросы, так и ответы требуются для установки типа контента text / xml.

Спецификация SOAP требует, чтобы клиент предоставил заголовок SOAPAction, но фактическое значение заголовка SOAPAction зависит от реализации сервера SOAP.

Например, чтобы получить доступ к службе перевода AltaVista BabelFish, размещенной в XMethods, в качестве заголовка SOAPAction необходимо указать следующее.

urn:xmethodsBabelFish#BabelFish

Даже если серверу не требуется полный заголовок SOAPAction, клиент должен указать пустую строку («») или нулевое значение. Например —

SOAPAction: ""
SOAPAction:

Вот пример запроса, отправленного через HTTP в службу перевода XMethods Babelfish:

POST /perl/soaplite.cgi HTTP/1.0
Host: services.xmethods.com
Content-Type: text/xml; charset = utf-8
Content-Length: 538
SOAPAction: "urn:xmethodsBabelFish#BabelFish"

<?xml version = '1.0' encoding = 'UTF-8'?>
<SOAP-ENV:Envelope 
   xmlns:SOAP-ENV = "http://schemas.xmlsoap.org/soap/envelope/" 
   xmlns:xsi = "http://www.w3.org/1999/XMLSchema-instance"
   xmlns:xsd = "http://www.w3.org/1999/XMLSchema">

   <SOAP-ENV:Body>
      <ns1:BabelFish
         xmlns:ns1 = "urn:xmethodsBabelFish"
         SOAP-ENV:encodingStyle = "http://schemas.xmlsoap.org/soap/encoding/">
         <translationmode xsi:type = "xsd:string">en_fr</translationmode>
         <sourcedata xsi:type = "xsd:string">Hello, world!</sourcedata>
      </ns1:BabelFish>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Обратите внимание на тип содержимого и заголовок SOAPAction. Также обратите внимание, что метод BabelFish требует двух параметров String. Режим перевода en_fr переводит с английского на французский.

Вот ответ от XMethods —

HTTP/1.1 200 OK
Date: Sat, 09 Jun 2001 15:01:55 GMT
Server: Apache/1.3.14 (Unix) tomcat/1.0 PHP/4.0.1pl2
SOAPServer: SOAP::Lite/Perl/0.50
Cache-Control: s-maxage = 60, proxy-revalidate
Content-Length: 539
Content-Type: text/xml

<?xml version = "1.0" encoding = "UTF-8"?>
<SOAP-ENV:Envelope
   xmlns:SOAP-ENC = "http://schemas.xmlsoap.org/soap/encoding/"
   SOAP-ENV:encodingStyle = "http://schemas.xmlsoap.org/soap/encoding/"
   xmlns:xsi = "http://www.w3.org/1999/XMLSchema-instance"
   xmlns:SOAP-ENV = "http://schemas.xmlsoap.org/soap/envelope/"
   xmlns:xsd = "http://www.w3.org/1999/XMLSchema">
   
   <SOAP-ENV:Body>
      <namesp1:BabelFishResponse xmlns:namesp1 = "urn:xmethodsBabelFish">
         <return xsi:type = "xsd:string">Bonjour, monde!</return>
      </namesp1:BabelFishResponse>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Ответы SOAP, доставляемые через HTTP, должны следовать тем же кодам состояния HTTP. Например, код состояния 200 OK указывает на успешный ответ. Код состояния 500 Internal Server Error указывает, что произошла ошибка сервера и что ответ SOAP содержит элемент Fault.

В приведенном ниже примере запрос GetQuotation отправляется на сервер SOAP через HTTP. Запрос имеет параметр QuotationName , и в ответе будет возвращено предложение.

Пространство имен для функции определяется по адресу http://www.xyz.org/quotation .

Вот SOAP-запрос —

POST /Quotation HTTP/1.0
Host: www.xyz.org
Content-Type: text/xml; charset = utf-8
Content-Length: nnn

<?xml version = "1.0"?>
<SOAP-ENV:Envelope
   xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope"
   SOAP-ENV:encodingStyle = "http://www.w3.org/2001/12/soap-encoding">

   <SOAP-ENV:Body xmlns:m = "http://www.xyz.org/quotations">
      <m:GetQuotation>
         <m:QuotationsName>MiscroSoft</m:QuotationsName>
      </m:GetQuotation>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Соответствующий SOAP-ответ выглядит так:

HTTP/1.0 200 OK
Content-Type: text/xml; charset = utf-8
Content-Length: nnn

<?xml version = "1.0"?>
<SOAP-ENV:Envelope
   xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope"
   SOAP-ENV:encodingStyle = "http://www.w3.org/2001/12/soap-encoding">

   <SOAP-ENV:Body xmlns:m = "http://www.xyz.org/quotation">
      <m:GetQuotationResponse>
         <m:Quotation>Here is the quotation</m:Quotation>
      </m:GetQuotationResponse>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

SOAP 1.1 был первоначально представлен W3C в мае 2000 года. Официальными представителями были крупные компании, такие как Microsoft, IBM и Ariba, а также небольшие компании, такие как UserLand Software и DevelopMentor.

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

SOAP версии 1.1 доступен в Интернете по адресу http://www.w3.org/TR/SOAP/.

Рабочий проект SOAP версии 1.2 доступен по адресу http://www.w3.org/TR/soap12/.

Обратите внимание, что W3C также содержит представление для «SOAP-сообщений с вложениями», которое отделено от основной спецификации SOAP. Эта спецификация позволяет сообщениям SOAP включать двоичные вложения, такие как изображения и звуковые файлы. Для получения полной информации см. Примечание W3C по адресу http://www.w3.org/TR/SOAP-attachments .

Что такое REST и SOAP?

REST (Representational state transfer) — подход к разработке клиент-серверных приложений.

Приложения на REST архитектуре должны быть:

• Клиент-серверными.
• Взаимодействие между клиентом и сервером должно быть на HTTP.
• Все операции над ресурсами указываются в самих запросах. В архитектуре REST все данные являются «ресурсами» Все, что необходимо сделать с ресурсом в архитектуре REST, несется в самом запросе.
• Stateless – состояние клиента не сохраняется на сервере. Каждый раз, при обращении клиента к серверу, сервер воспринимает клиента как нового. Для аутентификации клиента на сервере могут использоваться cookies, например: сookies предоставляет дополнительную информацию от клиента пользователю (позиции в корзине пользователя в интернет-магазине).
• Возможность работать с любыми форматами данных (json, xml, text…).

SOAP (Simple Object Access Protocol) является стандартизированным протоколом передачи сообщений между клиентом и сервером. Обычно он используется совместно с HTTP(S), но может работать и с другими протоколами прикладного уровня (например, SMTP и FTP).

В отличие от REST, который может использовать любые форматы данных, SOAP работает только с XML форматом. При работе всегда удобно иметь стандартизированное описание возможных XML-документов и проверять их на корректность заполнения. Для этого существует XML Schema Definition (или сокращенно XSD). Две главные функции XSD для тестировщика – это описание типов данных и наложение ограничений на возможные значения. Например, некоторые элементы ответов сервера можно сделать необязательным для заполнения или ограничить его размер 255 символами с помощью XSD. Чем подробнее описан XSD, тем меньше головной боли доставит Вам тестирование сервиса. С помощью выстроенной схемы сервис сам сможет валидировать полученные данные и возвращать пользователю ошибку. Подробнее прочитать про XSD можно на w3schools и codenet (по-русски).

WSDL
(Web Services Description Language) – это язык на основе XML, который используется для описания веб-сервисов. В WSDL-документе содержится информация о местонахождении сервиса и доступных методах (операциях). Для каждого метода определяются параметры отправляемого и получаемого сообщения. Обратите внимание на то, что XSD может быть «встроен» внутрь WSDL-документа (например, у Yandex Speller API).

SOAP — Википедия

Материал из Википедии — свободной энциклопедии

Структура SOAP-сообщения

SOAP (от англ. Simple Object Access Protocol — простой протокол доступа к объектам) — протокол обмена структурированными сообщениями в распределённой вычислительной среде. Первоначально SOAP предназначался в основном для реализации удалённого вызова процедур (RPC). Сейчас протокол используется для обмена произвольными сообщениями в формате XML, а не только для вызова процедур. Официальная спецификация последней версии 1.2 протокола никак не расшифровывает название SOAP.
SOAP является расширением протокола XML-RPC.

SOAP может использоваться с любым протоколом прикладного уровня: SMTP, FTP, HTTP, HTTPS и др. Однако его взаимодействие с каждым из этих протоколов имеет свои особенности, которые должны быть определены отдельно. Чаще всего SOAP используется поверх HTTP.

SOAP является одним из стандартов, на которых базируются технологии веб-служб.

Структура протокола

Сообщение SOAP выглядит так:

SOAP-конверт 

Пример

Пример SOAP-запроса на сервер интернет-магазина:

 
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
     <getProductDetails xmlns="http://warehouse.example.com/ws">
       <productID>12345</productID>
     </getProductDetails>
   </soap:Body>
</soap:Envelope>

Пример ответа:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
     <getProductDetailsResponse xmlns="http://warehouse.example.com/ws">
       <getProductDetailsResult>
         <productID>12345</productID>
         <productName>Стакан граненый</productName>
         <description>Стакан граненый. 250 мл.</description>
         <price>9.95</price>
         <currency>
             <code>840</code>
             <alpha3>USD</alpha3>
             <sign>$</sign>
             <name>US dollar</name>
             <accuracy>2</accuracy>
         </currency>
         <inStock>true</inStock>
       </getProductDetailsResult>
     </getProductDetailsResponse>
   </soap:Body>
</soap:Envelope>

Недостатки

• Использование SOAP для передачи сообщений увеличивает их объём и снижает скорость обработки. В системах, где скорость важна, чаще используется пересылка XML-документов через HTTP напрямую, где параметры запроса передаются как обычные HTTP-параметры.

См. также

Ссылки

XML веб сервисы и характеристика протокола SOAP

Вообще сегодня есть стандартные протоколы обмена XML данными:

• XML-RPC – вы передаете пакет и указываете, какой метод на сервере хотите вызвать.
• REST — есть некие объекты на сервере. Каждый объект характеризуется каким-то идентификатором. У каждого элемента свой url. С любым элементов можно сделать: insert, delete, update, select. Вы просто посылаете нужный запрос на сервер (например, вставить такой-то элемент). Обмен клиент-сервер базируется либо на JSON, либо на XML.

Именно на RPC базируется SOAP (сервис ориентированная архитектура, набор слабосвязанных сервисов, взаимодействующих друг с другом). Главное достоинство RPC — небольшое количество сетевых ресурсов (точек входа) и много задействованных методов. Несмотря на это достоинство, у RPC — это устаревший протокол, у которого ряд недостатков:

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

Все эти недостатки были решены в XML Schema. Это промышленный стандарт описания XML документа. Т.е. это способ моделирования произвольных данных. XML схема может описывать модель (отношения между элементами и атрибутами, и их структура), типы данных (характеризует типы данных) и словарь (названия элементов и атрибутов).

Исходя из всех недостатков XML-RPC создали протокол SOAP.

Содержание статьи

SOAP

SOAP (Simle Object Access Protocol) — протокол доступа к объекту (к точке входа). Сегодня это основной промышленный стандарт построения распределенных приложений.

Он представляет собой расширения языка XML-RPC. Т.е. он построен по принципу: 1 точка входа и любые методы. Сам протокол в плане транспорта (как передать данные) дает широкий выбор: SMTP, FTP, HTTP, MSMQ.

SOAP лежит в основе реализации XML веб-сервисов (XML веб служб). Недостаток SOAP — сложен в изучении.

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

XML схема

Задача схемы — описать структуру данных, т.е. что у нас есть. Все данные делятся на простые и сложные типы (скаляры и структуры). Простой тип (строка, число, boolean, дата) никогда внутри ничего содержать не будет. А структура (объект) может содержать свойства.

Основные операции SOAP

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

Структура SOAP сообщений:

• SOAP Envelope (конверт) — сюда входит все сообщение. Состоит из заголовка и тела.
• SOAP Header (заголовок) — дополнительная информация (авторизация, например).
• SOAP Body (тело) — само сообщение.
• SOAP Fault (ошибка) — способ передачи ошибки от сервера к клиенту.

WSDL

WSDL (Web Services Description Language) — язык описания веб служб. Применяется в SOAP. Это некий докуент, который описывает все: какие пространства имен использовались, какие схемы данных использовались, какие типы сообщений сервер ждет от клиента, какие конверты к какому методу принадлежат, какие методы вообще есть, на какой адрес отправлять и т.д. Собственно, WSDL и есть веб сервис. Достаточно клиенту изучить содержимое этого документа, он уже знает о сервере все.

Любой сервер должен публиковать WSDL.

WSDL состоит из блоков:

• Определение самой службы, т.е. точки входа, указывается порт.
• Формат методов. Происходит привязка точки входа к операциям, т.е. какие методы поддерживает. Указывается тип вызова, способ передачи. Внутри каждого метода происходит объяснение — в каком виде передаются данные — в виде SOAP.
• Привязка методов к сообщению.
• Описание самих сообщений.

REST vs SOAP. Часть 2. Как проще и эффективнее организовать общение платформ? / Хабр

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

Оглавление цикла статей:

REST vs SOAP. Часть 1. Почувствуйте разницу.
REST vs SOAP. Часть 2. Как проще и эффективнее организовать общение платформ?

Зачем все это?

Зачем вообще нужно взаимодействие приложений, тем более написанных на разных платформах? Глупый вопрос, конечно. В мире программирования параллельно существуют и развиваются несколько абсолютно независимых, а местами и враждующих платформ. Кроме того, огромное количество софта уже написано и успешно работает, поэтому переписывать его под каждую новую платформу никто не будет. Возьмем банк для примера. Все in-house программисты банка всегда писали на JAVA, поэтому у банка есть сервис, который уже 5 лет прекрасно работает, недавно появились красивые мобильные приложения на Android, которые стабильно работают почти на всех версиях ОС, и остался даже сайт с апплетом, которых преподаватели в харьковских вузах до сих показывают в качестве примера передовых веб-технологий (jk). А теперь появилась задача разработки десктопного банковского приложения под Windows. Банк заказал WPF-приложение аутсорсинговой компании. Как же организовать общение платформ?

Немного истории

Отвлечемся пока от примера и обратимся к истории. Мне это делать, наверное, сложнее, чем многим из моих коллег, потому что я вступил в секту программистов во времена .Net, когда не обязательно знать протокол HTTP, чтобы писать сайты, а писать полнофункциональные десктопные приложения можно даже ни разу не слышав о WinAPI. Но я попробую сделать такой экскурс. Времена динозавров особо рассматривать не будем (будем считать, что динозавры вымерли с появлением XML в 1998), чтобы не отдаляться от основной темы. Предположим, у нас есть установленное соединение между двумя приложениями, по которому один может посылать байты, а другой будет их получать. Что дальше? Приложения должны договориться, что, к примеру, «1» значит «вышли список всех клиентов», «2|36782» — «вышли список транзакций для клиента 36782». Возможно, примерно так происходило дело в расцвет Мезозойской Эры. Это обязывало разработчиков изобретать новый велосипед для каждого взаимодействия приложений. С развитием интернета (середина 90-х) приложения смогли обмениваться информацией, предоставляя ее в оговоренном виде по оговоренному URL (позже это назовут “REST”). Какие протоколы были и как приложения общались до появления XML-RPC – писать не буду, просто потому что мало что знаю, может быть у кого-нибудь в комментариях пробьются ностальгические чувства.

RPC

RPC – это «remote procedure call», понятие очень старое, объединяющие древние, средние и современные протоколы, которые позволяют вызвать метод в другом приложении. XML-RPC – это протокол, появившийся в 1998, вскоре после появления XML. Изначально поддерживался Microsoft, но вскоре Microsoft полностью переключилась на SOAP и поэтому в .Net Framework мы не найдем классов для поддержки этого протокола. Несмотря на это, XML-RPC продолжает жить до сих пор в различных языках (особенно в PHP), видимо, заслужил любовь разработчиков своей простотой. Интересное чувство, когда наконец-то разбираешься в том, о чем уже давно писал в резюме. Это про XML-RPC и мое еще студенческое резюме. 🙂

SOAP

SOAP также появился в 1998 году стараниями Microsoft. Он был анонсирован как революция в мире ПО. Нельзя сказать, что все пошло по плану Microsoft, было огромное количество критики из-за сложности и тяжеловесности протокола. В то же время были и те, кто считал SOAP настоящим прорывом. Сам же протокол продолжал развиваться и плодиться десятками новых и новых спецификаций, пока в 2003 года W3C не утвердила в качестве рекомендации SOAP 1.2, который и сейчас является последним. Семейство у SOAP получилось внушительное, вот их семейная фотография:

(на фото — WS-Addressing, WS-Enumeration, WS-Eventing, WS-Transfer, WS-Trust, WS-Federation, Web Single Sign-On… А того второго справа вообще не вспомнить, как зовут)

За более десяти лет споры по поводу SOAP не утихли, он по прежнему яростно критикуется за перегруженность, за низкую скорость работы. Однако протокол не умер, скорее даже наоборот, хотя и мир тоже не захватил. Критика протокола во многом справедлива: не используются заложенные в HTTP фичи, длина сообщений больше, чем у REST, от всех этих WS-Federation и WS-AtomicTransaction часто нету никакой пользы.

Но я хочу заострить внимание на другом – как же быстро можно разрабатывать распределенные приложения, используя семейство протоколов SOAP! Это ли не революция, которую нам обещал Microsoft? По-моему, это именно она. Где еще можно порасставлять аттрибуты в коде, нажать кнопку Publish на сервисе, нажать кнопку Generate Proxy на клиенте и вызывать код, как будто он находится в том же проекте? Поэтому на передний план выходит вопрос о том, в каких языках и средах программирования такая сказка возможна. Попробую свести эти данные в таблицу:

А как же REST, неужели он не нужен?

Несмотря на все лестные слова с адрес в адрес SOAP, я ни в коем случае не собираюсь сказать, что REST подход не нужен. Термин REST появился в 2000, т.е. всего лишь на два года позже первой версии SOAP. Сам же подход появился намного раньше, в 2000 же он просто был осознан, задокументирован и название сменилось с длинного «я тебе даю такую-ту инфу там-то» на непонятное «REST». Происхождение названия и принципы REST подробно обсуждались в первой части статьи. Здесь я заострю внимание на том, где REST лучше использовать и почему:

1. В сервисах, которые будут использоваться из javascript. Тут и говорить нечего, javascript хорошо работает с json, поэтому именно его и надо предоставлять.
2. В сервисах, которые будут использоваться из языков, в которых нет возможности сгенерировать прокси клиента. Это Objective-C, например. Не нужно парсить вручную SOAP-конверт, это незачем.
3. Когда существуют очень высокие требования к производительности. Это, как правило, очень интенсивно используемые API, вроде Twitter API или Google API.

А когда же использовать SOAP:

1. Когда взаимодействие происходит между платформами, под которые существуют инструменты для ускорения разработки с использованием SOAP. Например, правильно писать SOAP-сервис на JAVA, который будет использоваться из .Net и Flex.
2. Когда можно извлечь пользу из всех накруток SOAP. Достоверных сведений о том, что кто-то сумел это сделать, у меня нет. Понятный пример придумать не могу.

Таким образом, у меня все свелось к тому, что использовать SOAP надо там, где он поддерживается, в противном случае использовать REST. Это в разы сократит время разработки клиентов веб-сервиса и внесения изменений в них, позволит вместо детального разбора кода и добавления туда новых полей просто нажать кнопку «Update Service Reference».

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

Дни SOAP сочтены?

Сейчас REST и SOAP оба успешно используются, однако может произойти так, что SOAP действительно исчезнет, как пишут его критики. Такое, по моему мнению, возможно, если для RESTful сервисов начнет использоваться WSDL или подобный протокол, который позволит генерировать клиентские прокси. Поползновения такие были, протокол назывался WADL, однако на данный момент ничего такого не существует. Конечно, для такого сценария потребуется желание и приличные усилия хотя бы одного из основных игроков в мире IT, но я бы не стал исключать такой вариант. И будет у нас тогда лучшее из двух миров – простота и бенефиты от архитектуры сети и автоматизация взаимодействия приложений с помощью клиентских прокси.

Пример

Все уже забыли о примере из начала статьи? Он взят из жизни. Напомню, там разрабатывается WPF приложение, которое должно получать данные из существующего сервиса, написанного на JAVA. В каком формате он мог бы нам отдавать данные чтобы все выглядело бы красиво в соответствии с этой статьей? Правильно, в SOAP. А он отдает json. Надеюсь, ни у кого не возникло мысли «какой json, это в смысле REST?». Конечно REST! REST может возвращать данные в простом XML, json или любом другом запрошенном формате, даже в формате «как Вася попросил», если вам конечно удастся сделать этот формат одним рекомендуемых стандартов W3C или хотя бы договориться с разработчиками сервиса, чтобы они знали, что делать с этим:

Content-Type: application/as-Vasya-asked; charset=utf-8


Мы отвлеклись от дела. Ну возвращает сервис данные в json, и чем это нам грозит? А вот чем: прокси клиента сгенерить не сможем, придется вручную посылать запросы и парсить ответы. Придется использовать HttpWebRequest или надстройки над ним. А был бы SOAP – деньги заказчика были бы сэкономлены.

Заключение

Надеюсь, мне удалось обрисовать достаточно целостную картину взаимодействия приложений вне зависимости от языка и платформы. Хотел добавить, что описанные три подхода (REST, XML-RPC, SOAP) – это не все возможные варианты. Например, игрушки для соцсетей (пишутся на Flex) часто устанавливают прямое соединение через сокеты с серверной частью, написанной на C#. За счет этого получается выигрыш в скорости вместе с необходимостью изобретать мопед для каждого нового приложения. Где-то это уже было…
Вполне возможно, что я упустил что-то важное, особенно если это не касается .Net, буду рад узнать об этом.

P.S. Спасибо int03e, SSSurkv и 1nd1go за то, что повысили мне вчера карму, чтобы я мог опубликовать эту статью.

Что такое SOAP API? | АльтексСофт

Время чтения: 12 минут

Каждый раз, когда вы входите на веб-сайт с помощью своей учетной записи Facebook или перетаскиваете значок выпадающего списка по карте Google в приложении для вызова водителя, приложение, которое вы используете, связывается с Google или Facebook через веб-API. API или интерфейс прикладного программирования — это форма соглашения между веб-службами о том, как они собираются обмениваться данными, например получить карту или учетные данные вашей учетной записи.Сами данные структурированы в сообщениях, которые системы отправляют друг другу. Как только вы откроете, скажем, приложение Uber, ваш телефон отправит запрос сообщения в Google Maps, а Google вернет саму карту.

И если вы когда-либо имели дело с веб-сервисами, вы, вероятно, знаете, что существует несколько способов создания веб-API. Современная сеть управляется API-интерфейсами, использующими шаблон REST. Это легкий и эффективный обмен данными. Но иногда можно встретить другой подход — протокол SOAP. Он не хвастается своей простотой и не так быстр, как REST.Но вы будете удивлены, насколько это часто встречается в корпоративном обмене данными, потому что у протокола SOAP есть свои достоинства.

В этой статье мы выясним, как работает протокол SOAP, почему он так распространен среди корпоративных пользователей и чем отличается от REST.

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

Что такое SOAP?

SOAP или Протокол доступа к простым объектам — это протокол веб-связи, разработанный для Microsoft еще в 1998 году. Сегодня он в основном используется для предоставления доступа к веб-службам и передачи данных по HTTP / HTTPS. Но ими дело не ограничивается. SOAP, в отличие от шаблона REST, поддерживает только формат данных XML и строго следует предустановленным стандартам, таким как структура обмена сообщениями, набор правил кодирования и соглашение о предоставлении процедурных запросов и ответов.

Встроенные функции для создания веб-сервисов позволяют SOAP обрабатывать коммуникации и делать ответы независимыми от языка и платформы.

Хотя большая часть обмена веб-данными происходит через обмен REST, SOAP не исчезнет в ближайшее время, поскольку он очень стандартизирован, позволяет автоматизировать в некоторых случаях и более безопасен. Давайте посмотрим на основные функции SOAP.

SOAP работает только с XML

Данные, передаваемые через Интернет, обычно имеют определенную структуру.Два самых популярных формата данных — это XML и JSON.

XML (или Extensible Markup Language) — это текстовый формат, который устанавливает набор правил для структурирования сообщений в виде как записей, читаемых человеком, так и машинами. Но XML многословен, поскольку он направлен на создание веб-документа со всей его формальностью. JSON , с другой стороны, имеет свободную структуру, которая фокусируется на самих данных. Взгляните на изображение ниже, чтобы получить представление.

Вы видите, что многочисленные закрывающие теги в XML делают его намного длиннее.Спасибо PCMag за изображение.

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

Помимо формата данных, SOAP имеет еще один уровень стандартизации — структуру сообщений.

Структура сообщения SOAP

XML — не единственная причина, по которой протокол SOAP считается многословным и сложным по сравнению с REST.Это также способ составления сообщений SOAP. Стандартные запросы и ответы SOAP API отображаются в виде сообщения в оболочке, состоящего из четырех элементов с определенными функциями для каждого из них.

Заголовки и элементы неисправности не являются обязательными

Конверт — это основной и важный элемент каждого сообщения, которое начинается и заканчивается сообщениями с его тегами, охватывающими его, отсюда и название.

Заголовок (необязательно) определяет особенности, дополнительные требования к сообщению, e.г. аутентификация.

Тело включает запрос или ответ.

Ошибка (необязательно) показывает все данные о любых ошибках, которые могут возникать в запросе и ответе API.

Пример сообщения SOAP. Источник изображения: IBM

Расширяемость SOAP с помощью стандартных протоколов WS

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

Но поскольку веб-приложения обычно решают общие наборы проблем, после выпуска SOAP основной протокол был дополнен многочисленными стандартными протоколами, которые определяют, как вы это делаете. Все эти протоколы обычно имеют маркировку WS- (название протокола), например. WS-Security, WS-ReliableMessaging. Они были предоставлены различными организациями, включая Microsoft, IBM, OASIS и другие.

Стандартные протоколы охватывают несколько областей и аспектов использования SOAP:

• Безопасность
• Сообщения
• транзакции
• Метаданные и т. Д.

Самое замечательное в этих протоколах то, что вы можете выбрать, какой из них использовать. Обычно это называют расширяемостью SOAP. Например, если вам нужно, чтобы ваши финансовые транзакции были безопасными, вы можете применить WS-Atomic Transaction, которые являются ACID-совместимыми.

Соответствие ACID

ACID означает атомарность, согласованность, изоляция и долговечность. — это качество транзакций корпоративного уровня и одна из причин, по которым протокол SOAP все еще используется при обмене конфиденциальной информацией в корпоративных архитектурах.

Соответствие

ACID означает, что транзакции соответствуют следующим требованиям:

Атомарность. Несколько связанных транзакций либо работают как единое целое, либо не работают вообще. Иногда это называют подходом «все или ничего» . Этот набор транзакций сравнивается с атомом, который состоит из нескольких тесно связанных элементов.

Согласованность. Если какая-то часть транзакции терпит неудачу, система возвращается в исходное состояние.

Изоляция. Транзакции независимы друг от друга.

Прочность. Даже при сбое системы завершенные транзакции остаются.

Если вы используете WS-Atomic Transaction, который является еще одним стандартным протоколом, вы сможете добиться соответствия ACID.

Язык описания веб-сервисов (WSDL), документ

Одной из основных особенностей API-интерфейсов SOAP является то, что они почти всегда используют документ WSDL.

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

Так может выглядеть документ WSDL. Источник изображения: Researchgate.net

Самое замечательное в WSDL заключается в том, что он позволяет генерировать клиентский код на разных языках и сразу же начинать обмен сообщениями с сервером.Хотя не все API-интерфейсы SOAP используют документы WSDL, их использование настолько популярно, потому что помогает различным языкам программирования и IDE быстро наладить взаимодействие.

Подробнее о технической документации читайте в специальной статье.

Протоколы передачи: HTTP, TCP, SMTP, FTP и др.

С точки зрения непрофессионала, протокол передачи — это набор правил и команд, используемых для передачи данных через Интернет. Существуют протоколы низкого уровня, такие как IPv4, который просто доставляет пакеты данных из одной точки в другую.Существуют более высокие уровни передачи, такие как TCP, которые обеспечивают действительно доставку данных. И, наконец, существуют протоколы уровня приложений, которые используются веб-браузерами для связи с веб-серверами, но не отвечают за само соединение.

SOAP поддерживает множество протоколов передачи, как высокого, так и низкого уровня. Например, SOAP позволяет обмениваться сообщениями через TCP (протокол управления транзакциями), низкоуровневый метод обмена данными, который работает между портами через IP-сеть.Вы можете выбрать вариант SMTP (простой протокол передачи почты), который представляет собой протокол связи для передачи электронной почты, FTP (протокол передачи файлов) и любой другой метод передачи, поддерживающий обмен текстовыми данными.

Есть ли смысл отправлять данные с использованием других протоколов, кроме HTTP / HTTPS? В большинстве случаев это не так. SOAP в первую очередь был разработан для работы с HTTP. Но могут быть сценарии, такие как ограничения безопасности, требования к серверу, архитектура решения или просто скорость, которые выиграют от этой универсальности SOAP.

SOAP WS-Безопасность

SOAP ценится за способность интегрировать функцию WS-Security . Этот набор протоколов определяет, как обеспечить безопасность внутри транзакций, и предлагает конфиденциальность и целостность данных. Кроме того, он позволяет использовать шифрование и криптографическую подпись.

WS-Security позволяет шифровать ваши сообщения не только по протоколу HTTPS (который уже содержит шифрование), но и на уровне сообщения, имея данные аутентификации в элементе заголовка.Необходимо убедиться, что если ваши данные выходят за пределы HTTPS, когда достигают сервера, их может прочитать только правильный процесс внутри этого сервера, а не сам правильный сервер. Поскольку на стороне сервера может произойти некоторая предварительная обработка данных, прежде чем сообщение достигнет назначенного процесса.

Вот как WS-Security работает со структурой сообщения

Витторио Берточчи, главный программный менеджер Microsoft, объяснил, как работает WS-Security , используя метафору «голого мотоциклиста».

Представьте свое сообщение в виде обнаженного мотоциклиста. Чтобы добраться до места назначения, он может проехать через прозрачный туннель и надеяться, что его никто не увидит (HTTP). Или он может проехать через непрозрачный туннель. В этом случае, хотя никто не видит его, когда он находится внутри туннеля, чтобы добраться до конечного пункта назначения, он все равно должен проехать по некоторым улицам (HTTPS, очевидно, непрозрачный туннель). И, наконец, он может просто носить одежду и шлем, чтобы чувствовать себя в полной безопасности (WS-Security).

Именно из-за этой защиты на уровне сообщений финансовые организации и другие корпоративные пользователи выбирают протокол SOAP.

Обмен сообщениями SOAP и без сохранения состояния

Начало 21 века запомнилось интернет-бумом. Появлялись тысячи интернет-компаний, и миллионы пользователей выходили в Сеть каждый день. А теперь представьте, что один сервер начинает одновременно получать тысячи запросов от пользователей (клиентов). И если этот ресурс делает что-то более сложное, чем отображение стен текста, все может замедлиться. Например, если пользователи проверяют расписание предстоящих рейсов и должны детализировать каждую деталь полета, сервер должен знать, что происходит с клиентом, верно?

Похоже, что вы можете справиться с этой ситуацией двумя способами: используя операции с сохранением состояния и без сохранения состояния .И SOAP поддерживает оба.

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

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

Операции с отслеживанием состояния — одна из причин, по которой протокол SOAP используется для банковских транзакций и другого обмена данными, который требует объединения сообщений.Подробнее о вариантах использования SOAP ниже.

Логика повтора

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

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

Некоторые недостатки SOAP, которые следует учитывать

Ресурсоемко. Из-за большего размера XML-файла и полезной нагрузки, создаваемой массивной структурой сообщения, SOAP API требует большей пропускной способности.Иногда с этим компромиссом не стоит иметь дела. Проще говоря, эти строки тегов, которыми изобилуют сообщения XML, обрабатываются медленно.

Трудное обучение. Поскольку построение серверов SOAP API основано на протоколах, требуется знание и понимание всех протоколов, которые вы можете использовать с ним. Разработчики, занимающиеся созданием этих типов API, должны глубоко погрузиться во все процессы внутри протокола с его строго ограниченными правилами.

Недостаток гибкости. Мы упоминали, что SOAP API служит строгим контрактом между клиентом и сервером.Имея это в виду, эта жесткая схема SOAP требует дополнительных усилий для добавления или удаления свойств сообщения на обеих сторонах связи, на сервере и на клиенте. Это делает обновление запросов и ответов утомительным процессом и замедляет внедрение.

Начало работы с SOAP: основные источники

Если вы только начинаете разработку SOAP, вот основные ссылки, которые вам следует проверить:

Документация по SOAP — ключевой источник истины для тех, кто начинает работать с SOAP

Версии SOAP — поскольку было несколько итераций протокола, проверьте эти версии SOAP

WSDL — как использовать язык описания веб-служб и создавать документы WSDL

WS-Addressing — как добавить информацию о маршрутизации в заголовки SOAP

WS-ReliableMessaging — расширение, обеспечивающее доставку сообщений по назначению.Это также помогает создавать цепочки сообщений

WS-Coordination — координация действий распределенных приложений

WS-Security — как включить защиту на уровне сообщений

WS-Atomic Transaction — как сделать сообщения ACID-совместимыми

Сравнение SOAP и REST

При описании SOAP нельзя не упомянуть его основную альтернативу — REST.

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

REST был представлен в 2000 году — он ненамного моложе SOAP — с целью заставить серверы меньше заботиться о том, что происходит на клиенте.

И вот здесь начинается одно из основных различий между REST и SOAP.

Как скажет вам большинство инженеров, нельзя напрямую сравнивать SOAP и REST, но поскольку оба подхода решают схожий набор проблем, вот краткое описание

Операции с сохранением состояния и без сохранения состояния. REST не имеет состояния; SOAP поддерживает оба подхода.

Структура сообщения. В то время как сообщение SOAP является «конвертом», сообщение REST находится на «открытке»: оно не имеет дополнительных оболочек, заголовков или чего-либо еще, что могло бы изменить его упрощенный характер.

Логическая экспозиция. В отличие от SOAP, который сохраняет свою логику в документе WSDL, у REST есть альтернатива — документ WADL (или документ языка описания веб-приложений). Он не так распространен, как WSDL, но иногда он полезен, если вы работаете в корпоративной среде и не можете легко связаться с людьми со стороны службы, требуя, чтобы у вас были под рукой некоторые формальные соглашения.

Форматы данных. Как мы уже упоминали, SOAP — это строго XML. REST может работать с JSON, XML, HTML и другими форматами, которые вам нравятся.Но самым популярным остается JSON (или объектная нотация JavaScript).

Протоколы передачи. SOAP является гибким с точки зрения протоколов передачи, что позволяет использовать его в различных сценариях. REST ориентирован исключительно на обмен HTTP / HTTPS. Могут быть некоторые исключения, если вы сопоставляете методы обмена HTTP (GET, POST PUT, DELETE и т. Д.), Скажем, с методами FTP. Но REST был разработан с учетом HTTP.

Кеширование. Кэширование означает хранение некоторой информации на стороне клиента, чтобы избежать дополнительной нагрузки на сервер.Например, вы можете кэшировать нединамический контент, такой как изображения, чтобы быстрее загружать их на стороне клиента и не запрашивать сервер делать это каждый раз, когда вы посещаете ресурс. REST позволяет кэшировать данные на уровне HTTP. Если вы хотите реализовать SOAP-кеширование, вам необходимо настроить дополнительный модуль кеширования. Как правило, REST более удобен для кеширования.

Размер сообщения . Отсутствие дополнительного текста и блоков кода в простом файле JSON по сравнению с объемным XML в SOAP приводит к значительному уменьшению размера.Другими словами, скромный файл JSON RESTful API проще и быстрее обрабатывать и передавать.

Кривая обучения. RESTful архитектура проста и проста в реализации. SOAP требует гораздо более глубокого понимания стандартов и дополнительных протоколов WS. Вдобавок ко всему, инженерное сообщество, занимающееся REST, шире. Таким образом, вы можете рассчитывать найти ответы на проблемы намного быстрее.

Обработка ошибок. В отличие от SOAP API, где спецификация позволяет возвращать сообщение Retry XML с кодом ошибки и ее объяснением, REST API оставляет меньше места для прозрачности.REST в основном предоставляет два варианта: Ответ может содержать код ошибки без каких-либо объяснений. Это функция по умолчанию. С другой стороны, технология позволяет вручную прописывать объект ошибки вместе с его кодом.

Безопасность. REST API использует Secure Sockets Layer (или SSL) вместе с HTTPS поверх HTTP, имея простой транспортный механизм в качестве метода шифрования. Покрытие HTTPS действует как щит для безопасности данных. А протокол безопасности SSL применяется через соединение HTTPS для проверки вызовов REST API.С SOAP вы также можете использовать SSL, включая обмен сообщениями TCP, в дополнение к безопасности на уровне сообщений.

Примеры использования SOAP

Учитывая эти различия, становится очевидным, почему обмен веб-сообщениями в основном осуществляется с помощью REST. Подводя итоги, давайте определим случаи, когда SOAP все еще остается основной технологией.

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

Банковские операции и платежные системы. Когда вам нужно, чтобы ваши транзакции всегда были надежными и недоступными для третьих лиц, SOAP имеет множество преимуществ, которые следует учитывать. Во-первых, это уровень безопасности с соблюдением требований ACID и протоколов WS-Security. Кроме того, этот набор сценариев использования обычно требует обмена сообщениями с отслеживанием состояния и , то есть с использованием связанных транзакций, которые не изолированы одна от другой.Поскольку в одной операции платежных систем могут участвовать несколько сторон, протокол SOAP позволяет лучше координировать их поведение.

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

Обмен сообщениями без HTTP и устаревшие среды. Если требования к серверу и существующие системы используют протоколы связи помимо HTTP, SOAP — это первый вариант, на который следует обратить внимание.

Эта статья является частью серии статей, посвященных различным подходам к системам и стандартам цифровой связи. Вы также можете проверить:

Что такое API?

ГрафикQL

Электронный обмен данными (EDI)

.

Что такое SOAP? Зачем нужен протокол SOAP? Преимущества SOAP

Что такое SOAP?

SOAP: простой объектно-ориентированный протокол

1. Это универсальный облегченный протокол на основе XML без сохранения состояния, независимый от платформы, который использует HTTP в качестве транспортной среды и может использоваться для разработки распределенных сложных вычислительных сред.
2. Приложения могут напрямую общаться друг с другом через Интернет с помощью протокола SOAP.
3. Позволяет обмениваться данными между разнородными веб-приложениями.
SOAP поддерживает RPC, как DCOM или CORBA, но использует XML Open Standard для обмена данными между однородными или разнородными распределенными приложениями.
4. Благодаря независимости от платформы, языковой независимости и возможности обмена сообщениями протокол SOAP является надежным и стандартизированным механизмом в однородных или гетерогенных сетях.
5. При удаленном вызове процедуры SOAP клиент отправляет сообщение запроса на сервер. Сервер, в свою очередь, отправляет ответное сообщение клиенту.
6. XML — это основа деятельности SOAP. Все сообщения SOAP передаются в формате XML и являются стандартом для представления и обмена данными в структурированной форме между системами.

Зачем нужен протокол SOAP?

— Такие протоколы, как DCOM, RPC, IIOP, ограничены однородной сетью. Однако распределенные приложения состоят из разнородных сетевых компонентов, что требует передачи информации в общем формате данных между платформами.
— Простой объектно-ориентированный протокол (SOAP) — это протокол открытого стандарта, в котором используется XMl, который уже был принят в качестве стандартной формы передачи информации, что делает использование SOAP решением проблемы.

Преимущества SOAP

Ниже приведены некоторые из многих преимуществ SOAP.

1. Языковая нейтральность: SOAP может быть разработан с использованием любого языка.
2. Взаимодействие и независимость от платформы: SOAP может быть реализован на любом языке и может выполняться на любой платформе.
3. Простота: сообщений SOAP имеют очень простой формат XML.
4. Масштабируемость: SOAP использует протокол HTTP для транспорта, благодаря которому он становится масштабируемым.

Недостатки SOAP.

Ниже приведены недостатки SOAP.

1. Медленно: SOAP использует формат XML, который необходимо анализировать, и он также является более длинным, что делает SOAP медленнее, чем CORBA, RMI или IIOP.
2. Зависимость от WSDL: Он зависит от WSDL и не имеет какого-либо стандартизованного механизма для динамического обнаружения служб.

Состав SOAP.

Согласно спецификации SOAP, протокол SOAP обычно состоит из следующих трех частей:

1. Каркас: Он описывает способ построения и обработки сообщений.
2. Набор правил кодирования: Они используются для обмена типами данных.
3. Соглашение и процедура для представления удаленных вызовов процедур.

.

XML-мыло

---

• SOAP означает S реализация O объект A ccess
  П протокол
• SOAP — это протокол связи приложений
• SOAP — это формат для отправки и получения сообщений
• SOAP не зависит от платформы
• SOAP основан на XML
• SOAP — это рекомендация W3C

---

Почему именно SOAP?

Для веб-приложений важно иметь возможность взаимодействовать через Интернет.

Лучший способ связи между приложениями — через HTTP,
потому что HTTP поддерживается всеми интернет-браузерами и
серверы. SOAP был создан для этого.

SOAP обеспечивает способ связи между приложениями, работающими на разных
операционные системы, с разными технологиями и программированием
языков.

---

Строительные блоки SOAP

Сообщение SOAP — это обычный XML-документ, содержащий следующие элементы:

• Элемент Envelope, который идентифицирует XML-документ как сообщение SOAP
• Элемент заголовка, содержащий информацию заголовка
• Элемент Body, содержащий информацию о вызове и ответе
• Элемент неисправности, содержащий ошибки и информацию о состоянии

Все перечисленные выше элементы объявлены в пространстве имен по умолчанию для конверта SOAP:

http: // www.w3.org/2003/05/soap-envelope/

, а пространство имен по умолчанию для кодировки SOAP и типов данных:

http://www.w3.org/2003/05/soap-encoding

---

Правила синтаксиса

Вот несколько важных правил синтаксиса:

• Сообщение SOAP ДОЛЖНО быть закодировано с использованием XML
• Сообщение SOAP ДОЛЖНО использовать пространство имен SOAP Envelope
• Сообщение SOAP НЕ ДОЛЖНО содержать ссылку на DTD.
• Сообщение SOAP НЕ ДОЛЖНО содержать инструкций по обработке XML.

---

---

Скелет сообщения SOAP

<мыло: Конверт
xmlns: soap = «http: // www.w3.org/2003/05/soap-envelope/ «
soap: encodingStyle = «http://www.w3.org/2003/05/soap-encoding»>

…

…

<мыло: неисправность>

…

---

Элемент конверта SOAP

Требуемый элемент конверта SOAP — это корневой элемент сообщения SOAP.Этот элемент определяет XML-документ как сообщение SOAP.

Пример

<мыло: Конверт
xmlns: soap = «http://www.w3.org/2003/05/soap-envelope/»
мыло: encodingStyle = «http://www.w3.org/2003/05/soap-encoding»>

…

Информация о сообщении находится здесь

…

---

Пространство имен xmlns: soap

Обратите внимание на пространство имен xmlns: soap в приведенном выше примере.Он всегда должен иметь значение: «http://www.w3.org/2003/05/soap-envelope/».

Пространство имен определяет конверт как конверт SOAP.

Если используется другое пространство имен, приложение генерирует ошибку и отклоняет сообщение.

---

Атрибут encodingStyle

Атрибут encodingStyle используется для определения типов данных, используемых в
документ. Этот атрибут может появляться в любом элементе SOAP и применяется к его содержимому и всем дочерним элементам.

Сообщение SOAP не имеет кодировки по умолчанию.

Синтаксис

Пример

<мыло: Конверт
xmlns: soap = «http://www.w3.org/2003/05/soap-envelope/»
мыло: encodingStyle = «http://www.w3.org/2003/05/soap-encoding»>

…

Информация о сообщении находится здесь

…

---

Элемент заголовка SOAP

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

Если присутствует элемент Header, он должен быть первым дочерним элементом элемента Envelope.

Примечание: Все непосредственные дочерние элементы элемента Header должны быть квалифицированы пространством имен.

<мыло: Конверт
xmlns: soap = «http://www.w3.org/2003/05/soap-envelope/»
soap: encodingStyle = «http://www.w3.org/2003/05/soap-encoding»>

мыло: mustUnderstand = «1»> 234

…
…

Пример выше содержит заголовок с элементом «Trans», «mustUnderstand»
атрибут со значением 1 и значением 234.

SOAP определяет три атрибута в пространстве имен по умолчанию. Эти атрибуты: mustUnderstand,
актер и encodingStyle.

Атрибуты, определенные в заголовке SOAP, определяют, как получатель должен обрабатывать сообщение SOAP.

---

Атрибут mustUnderstand

Атрибут SOAP mustUnderstand может использоваться, чтобы указать, является ли запись заголовка обязательной или необязательной для обработки получателем.

Если вы добавляете mustUnderstand = «1» к дочернему элементу элемента Header, это означает, что получатель, обрабатывающий заголовок, должен распознать элемент. Если
получатель не распознает элемент, который не удастся при обработке заголовка.

Синтаксис

мыло: mustUnderstand = «0 | 1»

Пример

<мыло: Конверт
xmlns: soap = «http://www.w3.org/2003/05/soap-envelope/»
soap: encodingStyle = «http://www.w3.org/2003/05/soap-encoding»>

мыло: mustUnderstand = «1»> 234

…
…

---

Атрибут актера

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

Атрибут субъекта SOAP используется для адресации элемента заголовка конкретной конечной точке.

Синтаксис

Пример

<мыло: Конверт
xmlns: soap = «http://www.w3.org/2003/05/soap-envelope/»
soap: encodingStyle = «http://www.w3.org/2003/05/soap-encoding»>

мыло: актер = «https://www.w3schools.com/code/»> 234

…
…

---

Атрибут encodingStyle

Атрибут encodingStyle используется для определения типов данных, используемых в
документ. Этот атрибут может появиться в любом элементе SOAP, и он будет применяться к этому
содержимое элемента и все дочерние элементы.

Сообщение SOAP не имеет кодировки по умолчанию.

Синтаксис

---

Элемент тела SOAP

Требуемый элемент тела SOAP содержит фактическое сообщение SOAP, предназначенное для конечной конечной точки сообщения.

Непосредственные дочерние элементы элемента SOAP Body могут быть квалифицированы пространством имен.

Пример

<мыло: Конверт
xmlns: soap = «http://www.w3.org/2003/05/soap-envelope/»
soap: encodingStyle = «http://www.w3.org/2003/05/soap-encoding»>

Яблоки

В приведенном выше примере запрашивается цена на яблоки.Обратите внимание, что m: GetPrice и
Элементы Item выше относятся к конкретным элементам приложения. Они не являются частью пространства имен SOAP.

Ответ SOAP может выглядеть примерно так:

<мыло: Конверт
xmlns: soap = «http://www.w3.org/2003/05/soap-envelope/»
soap: encodingStyle = «http://www.w3.org/2003/05/soap-encoding»>

1.90

---

Элемент ошибки SOAP

Необязательный элемент ошибки SOAP используется для обозначения ошибки
Сообщения.

Элемент SOAP Fault содержит ошибки и
информация о состоянии для сообщения SOAP.

Если присутствует элемент Fault, он должен отображаться как дочерний элемент
элемента Body. Элемент Fault может появляться только один раз в сообщении SOAP.

Элемент SOAP Fault имеет следующие подэлементы:

Подэлемент	Описание
<код ошибки>	Код для определения неисправности
	Объяснение неисправности, понятное человеку
<фактор неисправности>	Информация о виновнике неисправности
<подробно>	Содержит информацию об ошибках приложения, связанных с Кузовной элемент

Коды ошибок SOAP

Значения кода неисправности, определенные ниже, должны использоваться в элементе кода неисправности, когда
с описанием неисправностей:

Ошибка	Описание
Несоответствие версии	Обнаружено недопустимое пространство имен для элемента конверта SOAP
Должен понять	Непосредственный дочерний элемент элемента Header с атрибутом mustUnderstand, установленным на «1», был не понял
Клиент	Сообщение было неправильно сформировано или содержало неверную информацию
Сервер	Возникла проблема с сервером, поэтому сообщение не может быть продолжено

Протокол HTTP

HTTP обменивается данными через TCP / IP.Клиент HTTP подключается к серверу HTTP с помощью TCP. После установления соединения клиент может отправить на сервер сообщение HTTP-запроса:

POST / item HTTP / 1.1
Хост: 189.123.255.239
Тип содержимого: текст / простой
Content-Length: 200

Затем сервер обрабатывает запрос и отправляет ответ HTTP клиенту. Ответ содержит код состояния, указывающий на статус запроса:

200 ОК
Тип содержимого: текст / простой
Content-Length: 200

В приведенном выше примере сервер вернул код состояния 200.Это стандартный код успеха для HTTP.

Если сервер не смог декодировать запрос, он мог бы вернуть что-то вроде этого:

400 неверный запрос
Content-Length: 0

---

Привязка SOAP

Спецификация SOAP определяет структуру сообщений SOAP, а не то, как
они обмениваются. Этот пробел заполняется так называемыми «привязками SOAP». МЫЛО
привязки — это механизмы, которые позволяют эффективно обмениваться сообщениями SOAP.
с использованием транспортного протокола.

Большинство реализаций SOAP предоставляют привязки для общих транспортных протоколов,
например HTTP или SMTP.

HTTP является синхронным и широко используется. HTTP-запрос SOAP определяет как минимум два заголовка HTTP: Content-Type и Content-Length.

SMTP является асинхронным и используется в крайнем случае или в особых случаях.

Java-реализации SOAP обычно предоставляют конкретную привязку для JMS.
(Система обмена сообщениями Java) протокол.

---

Content-Type

Заголовок Content-Type для запроса и ответа SOAP определяет тип MIME для сообщения и
кодировка символов (необязательно), используемая для тела XML запроса или ответа.

Синтаксис

Тип содержимого: MIMEType; charset = кодировка символов

Пример

POST / item HTTP / 1.1
Content-Type: application / soap + xml; charset = utf-8

---

Длина содержимого

Заголовок Content-Length для запроса и ответа SOAP определяет количество байтов в теле запроса или ответа.

Синтаксис

Пример

POST / item HTTP / 1.1
Content-Type: application / soap + xml; charset = utf-8
Длина содержимого: 250

---

Пример SOAP

В приведенном ниже примере запрос GetStockPrice отправляется на сервер.В запросе есть параметр StockName,
и параметр Price, который будет возвращен в ответе. Пространство имен для функции определено в «http://www.example.org/stock».

Запрос SOAP:

POST / InStock HTTP / 1.1
Хост: www.example.org
Content-Type: application / soap + xml; charset = utf-8
Content-Length: nnn

xmlns: soap = «http://www.w3.org/2003/05/soap-envelope/»
мыло: encodingStyle = «http: // www.w3.org/2003/05/soap-encoding «>

IBM

Ответ SOAP:

HTTP / 1.1 200 ОК
Content-Type: application / soap + xml; charset = utf-8
Content-Length: nnn

<мыло: Конверт
xmlns: soap = «http://www.w3.org/2003/05/soap-envelope/»
soap: encodingStyle = «http://www.w3.org/2003/05/soap-encoding»>

34,5

.

Что означает SOAP?

9004

SOAP

Стандарты академического прогресса

Академические науки и науки

9000anagan Business»

South Компании и фирмы

SOAP	Простой протокол доступа к объектам Вычисления »Программное обеспечение — и многое другое …				Оценить:
SOAP	Субъективная цель Бизнес »Общий бизнес				Оцените:
SOAP	Surrey, Incorporated (исключен из листинга) Бизнес»				Оцените это:
SOAP	Сервисно-ориентированный протокол архитектуры Академия и наука »Архитектура				Оцените:
			Оцените:
SOAP	State Of Art Paper Академия и наука »Университеты			Оценить:
SOAP	Точка доступа с защищенным оверлеем Вычислительная техника »Кибернетика и безопасность				Оцените:
SOAP				Оцените это:
SOAP	Предотвращение ослабления операндов хранилища Вычислительные машины »Сборка
SOAP	Приложение для наблюдения за Священным Писанием и молитва Сообщество				Оцените его:
SOAP	Спасите нашу удивительную растительность 0 14 14 и субъективное план (прогресс) Медицина »Физиология it: 9 0004 SOAP 9004 9000 9000 9000 Подростки, вовлеченные в проституцию Разное »Несекретное Сообщество Оцените: SOAP Sons Of A Preacherman Сообщество »Религия Оцените: SOAP Оцените: SOAP Вычеркните аббревиатуры, ПОЖАЛУЙСТА! Разное »Приколы Оцените: SOAP Печать утвержденной упаковки Бизнес» Общий бизнес 4 SOAP Распространение Священных Писаний Отчетность и молитва Сообщество »Религия Оценить план: Задача SOAP 9000 Цель SOAP Медицина »Больницы Оценить: SOAP Super Over-Rated Action Pig Интернет» Chat Оценить это : Приложение «Наблюдение за Священным Писанием» Молитва Разное »Несекретный Оцените: SOAP Только надежно? Интернет »Чат Оцените: SOAP Snakes On A Plane Сообщество» Новости и СМИ Оцените: SOAP Общество акушерской анестезии и перинатологии Академические и научные »Общества Оцените это: Оцените: SOAP Субъективная объективная оценка и план 5 5 Разное» Разное » Оценить it: SOAP Subjective, Objective, Assessment and Plan Medical »British Medicine Оцените: . No related posts. Share : Добавить комментарий Отменить ответ Ваш адрес email не будет опубликован. Обязательные поля помечены * Комментарий * Имя * Email * Сайт