SOAP позволяет разработчикам вызывать процессы, работающие в различных операционных системах (таких как Windows , macOS и Linux ), для аутентификации, авторизации и взаимодействия с использованием расширяемого языка разметки (XML). Поскольку веб-протоколы, такие как HTTP, установлены и работают практически во всех операционных системах, SOAP позволяет клиентам вызывать веб-службы и получать ответы независимо от языка и платформы.
Характеристики
SOAP обеспечивает уровень протокола обмена сообщениями в стеке протоколов веб-служб для веб-служб. Это протокол на основе XML, состоящий из трех частей:
конверт, который определяет структуру сообщения [1] и способ его обработки
набор правил кодирования для выражения экземпляров типов данных, определенных приложением
соглашение для представления вызовов процедур и ответов
SOAP имеет три основные характеристики:
расширяемость (безопасность и WS-адресация входят в число разрабатываемых расширений)
нейтральность (SOAP может работать по любому протоколу, например HTTP , SMTP , TCP , UDP )
В качестве примера того, что могут делать процедуры SOAP, приложение может отправить запрос SOAP на сервер, на котором включены веб-службы (например, база данных цен на недвижимость), с параметрами для поиска. Затем сервер возвращает ответ SOAP (документ в формате XML) с результирующими данными, например, ценами, местоположением, характеристиками. Поскольку сгенерированные данные поступают в стандартизированном формате, поддающемся машинному анализу, запрашивающее приложение может затем интегрировать их напрямую.
Архитектура SOAP состоит из нескольких уровней спецификаций для:
SOAP развился как преемник XML-RPC , хотя его нейтральность к транспортировке и взаимодействию он заимствовал у адресации веб-сервисов [2] , а конверт/заголовок/тело – из других источников (вероятно, из WDDX ). [ нужна цитата ]
История
SOAP был разработан как протокол доступа к объектам и выпущен как XML-RPC в июне 1998 года как часть Frontier 5.1 Дэйвом Винером , Доном Боксом , Бобом Аткинсоном и Мохсеном Аль-Госейном для Microsoft , где Аткинсон и Аль-Госейн работали. [3] Спецификация не была доступна до тех пор, пока она не была представлена IETF 13 сентября 1999 года. [4] [5] По словам Дона Бокса, это произошло из-за политики внутри Microsoft. [6] Из-за колебаний Microsoft Дэйв Винер выпустил XML-RPC в 1998 году . [7]
Представленный Интернет-проект не получил статуса RFC и поэтому не считается «веб-стандартом» как таковым. Версия 1.1 спецификации была опубликована в виде примечания W3C 8 мая 2000 года. [8] Поскольку версия 1.1 не достигла статуса Рекомендации W3C , ее также нельзя считать «веб-стандартом». Однако версия 1.2 спецификации стала рекомендацией W3C 24 июня 2003 года . Первоначально SOAP означало «Протокол простого доступа к объектам», но в версии 1.2 стандарта эта аббревиатура была исключена. [9]
Спецификация SOAP [10] поддерживалась Рабочей группой по протоколу XML [11] Консорциума Всемирной паутины до закрытия группы 10 июля 2009 года.
После того, как SOAP был впервые представлен, он стал базовым уровнем более сложного набора веб-сервисов , основанных на WSDL , XSD и UDDI . Эти различные сервисы, особенно UDDI, оказались гораздо менее интересными, но их понимание дает полное понимание ожидаемой роли SOAP по сравнению с тем, как на самом деле развивались веб-сервисы.
SOAP-терминология
Спецификацию SOAP можно в широком смысле определить как состоящую из следующих трех концептуальных компонентов: концепции протокола, концепции инкапсуляции и концепции сети. [12]
Концепции протокола
МЫЛО
Это набор правил, формализующих и управляющих форматом и правилами обработки информации, которой обмениваются отправитель SOAP и получатель SOAP.
SOAP-узлы
Это физические/логические машины с процессорами, которые используются для передачи/пересылки, получения и обработки сообщений SOAP. Они аналогичны узлам в сети.
SOAP-роли
На пути сообщения SOAP все узлы принимают на себя определенную роль. Роль узла определяет действие, которое узел выполняет с полученным сообщением. Например, роль « none» означает, что ни один узел не будет каким-либо образом обрабатывать заголовок SOAP и просто передавать сообщение по своему пути.
Привязка протокола SOAP
Сообщение SOAP должно работать совместно с другими протоколами для передачи по сети. Например, сообщение SOAP может использовать TCP в качестве протокола нижнего уровня для передачи сообщений. Эти привязки определены в структуре привязки протокола SOAP. [13]
SOAP-функции
SOAP предоставляет только структуру обмена сообщениями. Однако его можно расширить, добавив такие функции, как надежность, безопасность и т. д. При добавлении функций в структуру SOAP необходимо соблюдать определенные правила.
SOAP-модуль
Набор спецификаций, касающихся семантики заголовка SOAP, для описания любых новых функций, расширяемых SOAP. Модуль должен реализовывать ноль или более функций. SOAP требует, чтобы модули придерживались установленных правил. [14]
Концепции инкапсуляции данных
SOAP-сообщение
Представляет информацию, которой обмениваются два узла SOAP.
Мыльный конверт
Это включающий элемент XML-сообщения, идентифицирующий его как сообщение SOAP.
Блок заголовка SOAP
Заголовок SOAP может содержать более одного из этих блоков, каждый из которых представляет собой отдельный вычислительный блок внутри заголовка. Как правило, информация о роли SOAP используется для определения узлов на пути. Говорят, что блок заголовка нацелен на узел SOAP, если роль SOAP для блока заголовка является именем роли, в которой работает узел SOAP. (пример: блок заголовка SOAP с атрибутом роли UltimateReceiver предназначен только для узла назначения, который имеет эту роль. Заголовок с атрибутом роли как следующий предназначен для каждого посредника, а также узла назначения.)
SOAP-заголовок
Коллекция из одного или нескольких блоков заголовков, предназначенных для каждого получателя SOAP.
Тело мыла
Содержит тело сообщения, предназначенное для получателя SOAP. Интерпретация и обработка тела SOAP определяются блоками заголовков.
Ошибка SOAP
Если узлу SOAP не удается обработать сообщение SOAP, он добавляет информацию об ошибке в элемент ошибки SOAP. Этот элемент содержится в теле SOAP как дочерний элемент.
Концепции отправителя и получателя сообщений
SOAP-отправитель
Узел, передающий сообщение SOAP.
SOAP-приемник
Узел, получающий сообщение SOAP. (Может быть посредником или узлом назначения).
Путь сообщения SOAP
Путь, состоящий из всех узлов, которые прошло сообщение SOAP, чтобы достичь узла назначения.
Начальный отправитель SOAP
Это узел, который отправил сообщение SOAP для передачи. Это корень пути сообщения SOAP.
SOAP-посредник
Все узлы между отправителем SOAP и предполагаемым пунктом назначения SOAP. Он обрабатывает целевые блоки заголовков SOAP и пересылает сообщение SOAP конечному получателю SOAP.
Усовершенствованный SOAP-приемник
Получатель сообщения SOAP. Этот узел отвечает за обработку тела сообщения и всех блоков заголовков, предназначенных для него.
Спецификация
SOAP-структура
Спецификация SOAP определяет структуру обмена сообщениями, которая состоит из:
Модель обработки SOAP , определяющая правила обработки сообщения SOAP [15]
Модель расширяемости SOAP, определяющая концепции функций SOAP и модулей SOAP [15]
Структура привязки базового протокола SOAP , описывающая правила определения привязки к базовому протоколу, который может использоваться для обмена сообщениями SOAP между узлами SOAP [15].
Конструкция сообщения SOAP , определяющая структуру сообщения SOAP [15]
Строительные блоки SOAP
Сообщение SOAP представляет собой обычный XML-документ, содержащий следующие элементы:
Методы транспортировки
И SMTP, и HTTP являются допустимыми протоколами прикладного уровня, используемыми в качестве транспорта для SOAP, но HTTP получил более широкое признание, поскольку он хорошо работает с современной инфраструктурой Интернета; в частности, HTTP хорошо работает с сетевыми брандмауэрами . SOAP также может использоваться поверх HTTPS (который является тем же протоколом, что и HTTP на уровне приложения, но использует зашифрованный транспортный протокол ) с простой или взаимной аутентификацией; это рекомендуемый метод WS-I для обеспечения безопасности веб-служб, как указано в базовом профиле WS-I 1.1.
Это главное преимущество перед другими распределенными протоколами, такими как GIOP/IIOP или DCOM , которые обычно фильтруются брандмауэрами. SOAP поверх AMQP — еще одна возможность, поддерживаемая некоторыми реализациями. SOAP также имеет преимущество перед DCOM , заключающееся в том, что на него не влияют права безопасности, настроенные на машинах, требующих знания как передающих, так и принимающих узлов. Это позволяет SOAP быть слабо связанным, что невозможно с DCOM . Существует также стандарт OASIS SOAP-over-UDP .
Формат сообщения
XML Information Set был выбран в качестве стандартного формата сообщений из-за его широкого использования крупными корпорациями и усилий по разработке открытого исходного кода . Обычно набор информации XML сериализуется как XML . Широкий набор свободно доступных инструментов значительно упрощает переход к реализации на основе SOAP. Несколько длинный синтаксис XML может быть как преимуществом , так и недостатком. Хотя он облегчает обнаружение ошибок и позволяет избежать проблем совместимости, таких как порядок байтов ( endianness ), он может замедлить скорость обработки и быть громоздким. Например, CORBA , GIOP , ICE и DCOM используют гораздо более короткие двоичные форматы сообщений. С другой стороны, доступны аппаратные средства для ускорения обработки сообщений XML . [16] [17] Двоичный XML также исследуется как средство оптимизации требований к пропускной способности XML. XML-сообщения из-за своей самодокументируемой природы обычно имеют больше «служебных данных» (например, заголовков, вложенных тегов, разделителей), чем фактических данных, в отличие от более ранних протоколов, где накладные расходы обычно составляли относительно небольшой процент от общего объема сообщения.
Было обнаружено, что при обмене финансовыми сообщениями SOAP приводит к увеличению размера сообщения в 2–4 раза, чем предыдущие протоколы FIX (обмен финансовой информацией) и CDR (общее представление данных). [18]
Набор информации XML не обязательно сериализовать в XML. Например, существуют представления XML-информационного набора в формате CSV и JSON . Также нет необходимости указывать общую структуру преобразования. Концепция привязок SOAP позволяет использовать определенные привязки для конкретного приложения. Недостаток заключается в том, что и отправители, и получатели должны поддерживать эту новую привязку.
Пример сообщения (инкапсулированный в HTTP)
В сообщении ниже запрашивается цена акций AT&T (тикер акций «T»).
Характеристика нейтральности SOAP явно делает его пригодным для использования с любым транспортным протоколом. Реализации часто используют HTTP в качестве транспортного протокола, но можно использовать и другие популярные транспортные протоколы. Например, SOAP также можно использовать поверх SMTP, JMS [19] [20] и очередей сообщений .
SOAP в сочетании с обменом сообщениями/ответами HTTP легко туннелирует через существующие брандмауэры и прокси-серверы и, следовательно, не требует модификации широко распространенных вычислительных и коммуникационных инфраструктур, существующих для обработки обмена сообщениями/ответами HTTP.
SOAP обладает всеми возможностями XML, включая простую интернационализацию и расширяемость с помощью пространств имен XML.
Недостатки
При использовании стандартной реализации и привязки SOAP/HTTP по умолчанию информационный набор XML сериализуется как XML. Чтобы повысить производительность для особого случая XML со встроенными двоичными объектами, был введен механизм оптимизации передачи сообщений .
Если использовать HTTP в качестве транспортного протокола и не использовать адресацию веб-служб или корпоративную служебную шину , роли взаимодействующих сторон фиксированы. Только одна сторона (клиент) может пользоваться услугами другой.
SOAP не так «прост», как следует из названия. Многословность протокола, низкая скорость синтаксического анализа XML и отсутствие стандартизированной модели взаимодействия привели к доминированию сервисов, напрямую использующих протокол HTTP . См., например, REST .
Будучи независимым от протокола, SOAP не может использовать преимущества специфичных для протокола функций и оптимизаций, таких как унифицированный интерфейс REST или кэширование – вместо этого приходится их переопределять (как в случае с WS-Addressing ).
^ Хирш, Фредерик; Кемп, Джон; Илкка, Яни (11 января 2007 г.). Мобильные веб-сервисы: архитектура и реализация. Джон Уайли и сыновья (опубликовано в 2007 г.). п. 27. ISBN9780470032596. Проверено 15 сентября 2014 г. Простой протокол доступа к объектам (SOAP) определяет структуру конверта сообщений, предназначенную для переноса полезных данных приложения в одной части конверта (тело сообщения) и управляющей информации в другой (заголовок сообщения).
^ «Адресация веб-служб (WS-адресация)» . www.w3.org . Архивировано из оригинала 25 сентября 2016 г. Проверено 15 сентября 2016 г.
^ «Интервью эксклюзивного журнала разработчиков .NET «Indigo» с Доном Боксом из Microsoft» . Dotnet.sys-con.com. Архивировано из оригинала 6 января 2019 г. Проверено 4 октября 2012 г.
^ "Титульные страницы XML по истории SOAP" . Обложки.орг. Архивировано из оригинала 3 марта 2001 г. Проверено 22 июля 2003 г.
^ «SOAP: простой протокол доступа к объектам» . Ietf Datatracker . Сентябрь 1999 г. Архивировано из оригинала 25 февраля 2021 г. Проверено 20 сентября 2015 г.
^ "Дон Бокс об истории SOAP" . XML.com. 04 апреля 2001 г. Архивировано из оригинала 18 июня 2015 г. Проверено 20 сентября 2015 г.
^ «XML-RPC для новичков» . 14 июля 1998 г. Архивировано из оригинала 12 октября 1999 года.
^ «Примечание W3C по простому протоколу доступа к объектам (SOAP) 1.1» . W3C. 08.05.2000. Архивировано из оригинала 04 марта 2021 г. Проверено 20 сентября 2015 г.
^ «SOAP Версия 1.2 Часть 1: Платформа обмена сообщениями (второе издание)» . W3C . 27 апреля 2007 г. Архивировано из оригинала 19 июня 2012 г. Проверено 15 июня 2012 г. Примечание. В предыдущих версиях этой спецификации имя SOAP было аббревиатурой. Это уже не так. (Под разделом 1. Введение)
^ «Спецификации SOAP» . W3C. Архивировано из оригинала 15 апреля 2021 г. Проверено 29 марта 2014 г.
^ «Рабочая группа W3C по протоколу XML» . W3C. Архивировано из оригинала 25 декабря 2018 г. Проверено 29 марта 2014 г.
^ «SOAP Версия 1.2 Часть 1: Платформа обмена сообщениями (второе издание)» . www.w3.org . Архивировано из оригинала 20 сентября 2016 г. Проверено 14 сентября 2016 г.
^ «Предложение обязательной структуры» . www.w3.org . Архивировано из оригинала 11 июля 2017 г. Проверено 14 сентября 2016 г.
^ «SOAP Версия 1.2 Часть 1: Платформа обмена сообщениями (второе издание)» . www.w3.org . Архивировано из оригинала 20 сентября 2016 г. Проверено 14 сентября 2016 г.
^ abcd «SOAP Версия 1.2 Часть 1: Платформа обмена сообщениями (второе издание)» . www.w3.org . Архивировано из оригинала 02 апреля 2017 г. Проверено 24 июня 2020 г.
^ "IBM Datapower" . 306.ibm.com. 30 ноября 2011 г. Архивировано из оригинала 22 июня 2008 г. Проверено 4 октября 2012 г.
^ «IBM Zurich XML Accelerator Engine» (PDF) . Архивировано из оригинала (PDF) 30 сентября 2012 г. Проверено 4 октября 2012 г.
^ «Оценка SOAP для высокопроизводительных бизнес-приложений: торговые системы в реальном времени» . Tenermerx Pty Ltd Технологический университет, Сидней. 30 ноября 2011 г. Архивировано из оригинала 10 августа 2013 г. Проверено 14 марта 2013 г.
^ «SOAP по протоколу JMS» . ИБМ. Архивировано из оригинала 22 марта 2020 года . Проверено 22 марта 2020 г.
^ «Часто задаваемые вопросы по SOAP-JMS» . Рабочая группа по связыванию SOAP-JMS. Архивировано из оригинала 17 июля 2017 года . Проверено 22 марта 2020 г.
дальнейшее чтение
Бенуа Маршаль, «Мыльница: почему я использую SOAP», IBM
Уче Огбуджи, «Учебное пособие: обмен сообщениями XML с помощью SOAP», главный консультант, Four Thought, Inc.
