В качестве примера того, что могут делать процедуры 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 Note 8 мая 2000 года. [8] Поскольку версия 1.1 не достигла статуса Рекомендации W3C , ее также нельзя считать «веб-стандартом». Однако версия 1.2 спецификации стала рекомендацией W3C 24 июня 2003 года. Первоначально SOAP расшифровывалось как «Простой протокол доступа к объектам», но в версии 1.2 стандарта эта аббревиатура была удалена. [9]
Спецификация SOAP [10] поддерживалась рабочей группой XML Protocol Working Group [11] Консорциума Всемирной паутины до ее закрытия 10 июля 2009 года.
После того, как SOAP был впервые представлен, он стал базовым слоем более сложного набора веб-сервисов , основанных на WSDL , XSD и UDDI . Эти различные сервисы, особенно UDDI, оказались гораздо менее интересными, но их оценка дает полное понимание ожидаемой роли SOAP по сравнению с тем, как веб-сервисы фактически развивались.
Терминология SOAP
Спецификацию SOAP можно в широком смысле определить как состоящую из следующих трех концептуальных компонентов: концепции протокола, концепции инкапсуляции и концепции сети. [12]
Концепции протокола
МЫЛО
Это набор правил, формализующих и регулирующих формат и правила обработки информации, которой обмениваются отправитель и получатель SOAP.
SOAP-узлы
Это физические/логические машины с процессорными блоками, которые используются для передачи/пересылки, получения и обработки сообщений SOAP. Они аналогичны узлам в сети.
SOAP-роли
На пути сообщения SOAP все узлы принимают на себя определенную роль. Роль узла определяет действие, которое узел выполняет над полученным сообщением. Например, роль " none" означает, что ни один узел не будет обрабатывать заголовок SOAP каким-либо образом и просто передаст сообщение по своему пути.
Привязка протокола SOAP
Сообщение SOAP должно работать в сочетании с другими протоколами для передачи по сети. Например, сообщение SOAP может использовать TCP в качестве протокола нижнего уровня для передачи сообщений. Эти привязки определены в структуре привязки протокола SOAP. [13]
Возможности SOAP
SOAP предоставляет только фреймворк обмена сообщениями. Однако его можно расширить, добавив такие функции, как надежность, безопасность и т. д. При добавлении функций в фреймворк SOAP необходимо соблюдать определенные правила.
SOAP-модуль
Набор спецификаций, касающихся семантики заголовка SOAP, для описания любых новых функций, расширяемых в SOAP. Модуль должен реализовать ноль или более функций. SOAP требует, чтобы модули придерживались предписанных правил. [14]
Концепции инкапсуляции данных
SOAP-сообщение
Представляет собой информацию, которой обмениваются два узла SOAP.
SOAP-конверт
Это охватывающий элемент XML-сообщения, идентифицирующий его как сообщение SOAP.
Блок заголовка SOAP
Заголовок SOAP может содержать более одного из этих блоков, каждый из которых является дискретным вычислительным блоком в заголовке. В общем случае информация о роли SOAP используется для нацеливания узлов на пути. Блок заголовка считается нацеленным на узел SOAP, если роль SOAP для блока заголовка является именем роли, в которой работает узел SOAP. (например: блок заголовка SOAP с атрибутом роли ultimateReceiver нацелен только на узел назначения, который имеет эту роль. Заголовок с атрибутом роли next нацелен на каждого посредника, а также на узел назначения.)
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 , определяющая правила обработки сообщения 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 . Существует также стандарт SOAP-over-UDP OASIS .
Формат сообщения
XML Information Set был выбран в качестве стандартного формата сообщений из-за его широкого использования крупными корпорациями и усилий по разработке программного обеспечения с открытым исходным кодом . Обычно XML Information Set сериализуется как XML . Широкий спектр свободно доступных инструментов значительно облегчает переход к реализации на основе SOAP. Несколько длинный синтаксис XML может быть как преимуществом, так и недостатком. Хотя он облегчает обнаружение ошибок и позволяет избежать проблем взаимодействия, таких как порядок байтов ( endianness ), он может замедлить скорость обработки и быть громоздким. Например, CORBA , GIOP , ICE и DCOM используют гораздо более короткие двоичные форматы сообщений. С другой стороны, доступны аппаратные устройства для ускорения обработки XML- сообщений. [16] [17] Двоичный XML также изучается как средство для оптимизации требований к пропускной способности XML. Сообщения XML в силу своей самодокументируемой природы обычно имеют больше «накладных расходов» (например, заголовков, вложенных тегов, разделителей), чем фактических данных, в отличие от более ранних протоколов, где накладные расходы обычно составляли относительно небольшой процент от общего объема сообщения.
Было обнаружено, что при обмене финансовыми сообщениями SOAP приводит к созданию сообщений в 2–4 раза большего размера, чем предыдущие протоколы FIX (Financial Information Exchange) и CDR (Common Data Representation). [18]
XML Information Set не обязательно сериализовать в XML. Например, существуют представления CSV и JSON XML-infoset. Также нет необходимости указывать общую структуру преобразования. Концепция привязок SOAP допускает определенные привязки для определенного приложения. Недостаток в том, что и отправители, и получатели должны поддерживать эту новую определенную привязку.
Пример сообщения (инкапсулированного в HTTP)
В сообщении ниже запрашивается цена акций AT&T (биржевой код «T»).
POST /InStock HTTP / 1.1 Хост : www.example.org Тип содержимого : application/soap+xml; кодировка=utf-8 Длина содержимого : 299 Действие SOAP : "http://www.w3.org/2003/05/soap-envelope"<?xml version="1.0"?> <soap:Envelope xmlns:soap= "http://www.w3.org/2003/05/soap-envelope" xmlns:m= "http://www.example.org" > <soap:Header> </soap:Header> <soap:Body> <m:GetStockPrice> <m:StockName> T </m:StockName> </m:GetStockPrice> </soap:Body> </soap:Envelope>
Техническая критика
Преимущества
Характеристика нейтральности SOAP явно делает его пригодным для использования с любым транспортным протоколом. Реализации часто используют HTTP в качестве транспортного протокола, но могут использоваться и другие популярные транспортные протоколы. Например, SOAP также может использоваться поверх SMTP, JMS [19] [20] и очередей сообщений .
SOAP в сочетании с обменом постами/ответами HTTP легко туннелируется через существующие брандмауэры и прокси-серверы и, следовательно, не требует изменения широко распространенных вычислительных и коммуникационных инфраструктур, которые существуют для обработки обменов постами/ответами HTTP.
SOAP располагает всеми возможностями XML, включая легкую интернационализацию и расширяемость с помощью пространств имен XML.
Недостатки
При использовании стандартной реализации и привязки SOAP/HTTP по умолчанию набор данных XML сериализуется как XML. Для повышения производительности для особого случая XML со встроенными бинарными объектами был введен механизм оптимизации передачи сообщений .
При использовании HTTP в качестве транспортного протокола и неиспользовании адресации веб-сервисов или Enterprise Service Bus роли взаимодействующих сторон фиксированы. Только одна сторона (клиент) может использовать услуги другой.
SOAP не так «прост», как можно было бы предположить по названию. Многословность протокола, медленная скорость анализа XML и отсутствие стандартизированной модели взаимодействия привели к доминированию служб, использующих протокол HTTP более напрямую. См., например, REST .
Будучи протоколонезависимым, SOAP не может воспользоваться преимуществами специфических для протокола функций и оптимизаций, таких как единый интерфейс REST или кэширование , — вместо этого их приходится реализовывать заново (как в случае с WS-Addressing ).
^ Хирш, Фредерик; Кемп, Джон; Илкка, Яни (2007-01-11). Мобильные веб-сервисы: архитектура и реализация. John Wiley & Sons (опубликовано в 2007 г.). стр. 27. ISBN9780470032596. Получено 15.09.2014 . Простой протокол доступа к объектам (SOAP) определяет структуру конверта сообщений, предназначенную для переноса полезной нагрузки приложения в одной части конверта (тело сообщения) и управляющей информации в другой (заголовок сообщения).
^ "Эксклюзивное интервью для журнала разработчиков .NET "Indigo" с Доном Боксом из Microsoft". Dotnet.sys-con.com. Архивировано из оригинала 2019-01-06 . Получено 2012-10-04 .
^ "XML-титульные страницы по истории SOAP". Coverpages.org. Архивировано из оригинала 2001-03-03 . Получено 2003-07-22 .
^ "Дон Бокс об истории SOAP". XML.com. 2001-04-04. Архивировано из оригинала 2015-06-18 . Получено 2015-09-20 .
^ "XML-RPC для новичков". 1998-07-14. Архивировано из оригинала 12 октября 1999 года.
^ "W3C Note on Simple Object Access Protocol (SOAP) 1.1". W3C. 2000-05-08. Архивировано из оригинала 2021-03-04 . Получено 2015-09-20 .
^ "SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)". W3C . 27 апреля 2007 г. Архивировано из оригинала 2012-06-19 . Получено 2012-06-15 . Примечание: в предыдущих версиях этой спецификации название SOAP было аббревиатурой. Теперь это не так. (Под разделом 1. Введение)
^ "IBM Zurich XML Accelerator Engine" (PDF) . Архивировано из оригинала (PDF) 2012-09-30 . Получено 2012-10-04 .
^ "Оценка SOAP для высокопроизводительных бизнес-приложений: системы торговли в реальном времени". Tenermerx Pty Ltd Технологический университет, Сидней. 2011-11-30. Архивировано из оригинала 2013-08-10 . Получено 2013-03-14 .
^ "SOAP over JMS protocol". IBM. Архивировано из оригинала 22 марта 2020 г. Получено 22 марта 2020 г.
^ "SOAP-JMS FAQ". SOAP-JMS Binding Working Group. Архивировано из оригинала 17 июля 2017 г. Получено 22 марта 2020 г.
Дальнейшее чтение
Бенуа Маршаль, «Soapbox: Почему я использую SOAP», IBM
Уче Огбуджи, «Учебное пособие: обмен сообщениями XML с помощью SOAP», главный консультант, Fourthought, Inc.
