Любое сообщение отправляемое получаемое через soap это

Обновлено: 28.06.2024

Применение SOAP при интеграции систем

Для начинающих аналитиков,

не имеющих опыта web-разработки

В предыдущей статье мы говорили про то, что REST — это архитектурный стиль, который Рой Филдинг сформулировал в своей диссертации в 2000 году.

С протоколом SOAP дела обстоят несколько иначе.
SOAP — это не стиль, а протокол. Аббревиатура SOAP так и расшифровывается: Simple Object Access Protocol — простой протокол доступа к объектам. То есть правила передачи информации в SOAP строго стандартизированы, есть спецификация, которой нужно соответствовать.

SOAP появился 1998 году и был передан в организацию World Wide Web Consortium (W3C) — международная организация, которая курирует развитие интернета.

Почему разница в 2 года в появлении REST и SOAP так сказалась на их популярности?

Если сравнить это с тем фактом, что Рой Филдинг просто представил REST в своей диссертации, то вы поймете, почему SOAP завоевал популярность очень быстро.

Тем не менее на данный момент можно говорить о том, что в основном для интеграции систем используется REST.

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

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

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

Обмен файлами по FTP.

Экзотика: сокеты, порты, бинарные объекты.

В данной статье мы поговорим о веб-сервисах. Чем они отличаются от прочих способов и какие они бывают.

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

Главное отличие веб-сервиса от других способов передачи данных: стандартизированность. Приняв решение использовать веб-сервисы, можно сразу переходить к структуре данных и доступным функциям. Например, в SOAP (как более строгом протоколе), уже решён вопрос уведомления об ошибках.

Самые известные способы реализации веб-сервисов:

XML-RPC (XML Remote Procedure Call) — протокол удаленного вызова процедур с использованием XML. Прародитель SOAP. Предельно прост в реализации.

SOAP (Simple Object Access Protocol) — стандартный протокол по версии W3C. Четко структурирован и задокументирован.

JSON-RPC (JSON Remote Procedure Call) — более современный аналог XML-RPC. Основное отличие — данные передаются в формате JSON.

Специализированные протоколы для конкретного вида задач, такие как GraphQL.

Остальные протоколы не так широко распространены. Подробно рассмотрены в статье будут SOAP и REST.

SOAP (Simple Object Access Protocol) — данные передаются в формате XML.

отраслевой стандарт по версии W3C;

наличие строгой спецификации;

широкая поддержка в продуктах Microsoft,

сложность/ресурсоемкость парсинга XML-данных.

Пример SOAP запроса:

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

REST (Representational State Transfer) — на самом деле архитектурный стиль, а не протокол. В отличие от SOAP, REST не подкреплен официальным стандартом. Фактически, он основывается на соглашениях. Веб-сервис, построенный с учетом всех требований и ограничений архитектурного стиля, можно назвать RESTful веб-сервисом.

GET — получить данные;

POST — добавить данные;

PUT — изменить данные;

DELETE — удалить данные.

экономичность в плане ресурсов;

не требует программных надстроек (json_decode есть почти в каждом языке).

неоднозначность методов управления данными.

Пример REST запроса:

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

Что же использовать?

Если же вы разрабатываете публичное API и логика взаимодействия во многом покрывается четверкой методов CRUD — смело выбирайте REST. Он наиболее популярен в WEB. Яндекс, Google и другие используют именно его для своего API.

Веб-сервисы в живом производстве

Разработка веб-сервисов — типичная задача интеграции. ИНТЕРВОЛГА, как веб-интегратор, регулярно сталкивается с задачами разработки веб-сервисов и успешно с ними справляется. Наши сайты были и SOAP/REST серверами, и SOAP/REST клиентами.

Успешным примером внедрения веб-сервисов является проект Enterprise-уровня — Личный кабинет клиентов компании Евраз Металл Инпром. Все функции личного кабинета основываются на взаимодействии с удаленным SOAP веб-сервисом. Сайт выступает клиентом. В процессе эволюции в угоду безопасности сайт переквалифицировался в SOAP-сервер, а учетная система в SOAP-клиента.

Еще один личный кабинет для клиентов компании Евраз — еще один пример сайта в качестве клиента удаленного SOAP веб-сервиса.

Если у вас есть потребность организовать взаимодействие с веб-сервисом, сделать из сайта REST/SOAP/RPC клиент или сервер, пишите нам.

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

Также и с обменом данными. Не нужно тратить месяцы на объяснение новому сотруднику и самому себе, как работает обмен. Есть стандарт, обмен работает по нему.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Атрибут MustUnderstand

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

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

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

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

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

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

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

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

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

Коды ошибок SOAP

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

SOAP-ENV: VersionMismatch

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

SOAP-ENV: MustUnderstand

SOAP-ENV: Клиент

SOAP-ENV: Сервер

SOAP-ENV: VersionMismatch

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

SOAP-ENV: MustUnderstand

SOAP-ENV: Клиент

SOAP-ENV: Сервер

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

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

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

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

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

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

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

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

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

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

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

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

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

Простые типы, встроенные в 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 с двойным типом данных —

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

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

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

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

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

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

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

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

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

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

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

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

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

Взаимодействие с API Яндекс.Директа по протоколу SOAP.

Существует множество библиотек, реализующих протокол SOAP. Некоторые из них перечислены ниже:

WSDL (Web Services Description Language) — это язык описания веб-сервисов, основанный на XML. На нем описываются методы, входные и результирующие структуры данных, типы данных, сетевые адреса для обращения к сервису и другое.

Описание API Яндекс.Директа на WSDL доступно по адресу:

Версия 4 Версия Live 4

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

Запросы в формате SOAP

Версия 4 Версия Live 4

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

Пример запроса в формате SOAP

Пример ответа в формате SOAP

Если элемент locale отсутствует, подразумевается английский язык.

Доступ к финансовым методам

Для вызова финансовых методов CreateInvoice, TransferMoney, GetCreditLimits, PayCampaigns необходимо дополнительно указывать номер финансовой операции и финансовый токен в элементах operation_num и finance_token соответственно, как показано в следующем примере. Об их формировании рассказывается в разделе Доступ к финансовым методам.

Пример вызова финансового метода

Элемент faultcode содержит код ошибки, faultstring — краткое описание ошибки, detail — дополнительные пояснения, если имеются. Краткое описание и дополнительное пояснение могут выводиться на разных языках, что определяется элементом locale.

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

Я вижу вы последовали моей рекомендации почитать про SOAP, чтобы понять, почему XML является востребованным форматом. Это хорошо :-) Чуть позже я напишу вам ответ, где доступными словами объясню назначение и его практическое применение.

Лирическая часть.

Представьте что у вас реализована или реализуется некая система, которая должна быть доступна извне. Т.е. есть некий сервер, с которым вам надо общаться. Например веб-сервер.

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

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

Практическая часть.

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

Для клиентов достаточно знать url веб-сервиса, wsdl всегда будет рядом, по которому можно получить представление о методах и их параметрах, которые предоставляет этот веб-сервис.

Какие плюсы у всех этих наворотов:

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

Описание, имеющее четкую структуру, читается любым soap-клиентом. Т.е. какой бы ни был веб-сервис, клиент поймет какие данные веб-сервис принимает. По этому описанию клиент может построить свою внутреннюю структуру классов объектов, т.н. binding'и. В итоге программисту, использующему веб-сервис, остается написать что-то типа (псевдокод):

xml-валидация. xml должен быть well-formed. невалидный xml - сразу ошибка клиенту, пусть разбирается.
schema-валидация. xml должен иметь определенную структуру. xml не соответствует схеме - сразу ошибка клиенту, пусть разбирается.
проверка данных осуществляется soap-сервером, чтобы типы данных, ограничения соответствовали описанию.

Минусов тоже полно:

В качестве примера есть открытый веб-сервис belavia:

- точка входа, там же текстовое описание методов для сторонних разработчиков. - wsdl описание методов и типов принимаемых и возращаемых данных. - описание конкретного метода с примером вида xml-запроса и xml-ответа.

Можете вручную создать и послать запрос типа:

ЗЫ Раньше был открыт веб-сервис аэрофлота, но после того как 1C добавили поддержку soap в 8ку, куча 1с-бета-тестеров с успехом положили его. Сейчас что-то там поменяли (адреса не знаю, можно поискать, если интересно).
ЗЗЫ Дисклеймер. Рассказал на бытовом уровне. Пинать можно.

Читайте также: