SOAP

редактировать
Протокол обмена сообщениями для веб-служб
SOAP
Веб-сервис xrpc.png
СемействоПротокол обмена сообщениями
Разработано от Дэйв Винер, Дон Бокс, Боб Аткинсон и Мохсен Аль-Госейн
Впервые появилсяПервоначально как XML-RPC в 1998; 22 года назад (1998 г.)
Стабильный выпуск 1.2 / 27 апреля 2007 г.; 13 лет назад (2007-04-27)

SOAP (аббревиатура от Simple Object Access Protocol ) - это спецификация протокола обмена сообщениями для обмена структурированной информацией при реализации веб-сервисы в компьютерных сетях. Его цель - обеспечить расширяемость, нейтралитет, многословие и независимость. Он использует набор информации XML для своего формата сообщения и полагается на протоколы прикладного уровня, чаще всего протокол передачи гипертекста (HTTP), хотя некоторые устаревшие системы обмениваются данными по Simple Mail Transfer Protocol (SMTP) для согласования и передачи сообщений.

SOAP позволяет разработчикам вызывать процессы, запущенные в разных операционных системах (например, Windows, macOS и Linux ) для аутентификации, авторизации, и общаться с помощью Extensible Markup Language (XML). Поскольку веб-протоколы, такие как HTTP, установлены и работают во всех операционных системах, SOAP позволяет клиентам вызывать веб-службы и получать ответы независимо от языка и платформ.

Содержание

  • 1 Характеристики
  • 2 История
  • 3 Терминология SOAP
    • 3.1 Концепции протокола
    • 3.2 Концепции инкапсуляции данных
    • 3.3 Концепции отправителя и получателя сообщения
  • 4 Спецификация
  • 5 Строительные блоки SOAP
  • 6 Транспортные методы
  • 7 Формат сообщения
  • 8 Пример сообщения (инкапсулированный в HTTP)
  • 9 Техническая критика
    • 9.1 Преимущества
    • 9.2 Недостатки
  • 10 См. Также
  • 11 Ссылки
  • 12 Дополнительная литература
  • 13 Внешние ссылки

Характеристики

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

  • конверт, который определяет структуру сообщения и способ ее обработки
  • набор правил кодирования для выражения экземпляров определяемых приложением типов данных
  • соглашение для представления вызовов и ответов процедур

SOAP имеет три основные характеристики:

  1. расширяемость (безопасность и WS-Addressing входят в число разрабатываемых расширений)
  2. нейтральность (SOAP может работать по любому протоколу, например HTTP, SMTP, TCP, UDP )
  3. независимость (SOAP допускает любое программирование модель )

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

Архитектура SOAP состоит из нескольких уровней спецификаций для:

  • формата сообщения
  • шаблонов обмена сообщениями (MEP)
  • привязок базового транспортного протокола
  • модели обработки сообщений
  • расширяемость протокола

SOAP развился как преемник XML-RPC, хотя он заимствует свою транспортную и интерактивную нейтральность из адресации веб-сервисов, а конверт / заголовок / тело из где-то еще (вероятно, из WDDX ).

History

SOAP был разработан как протокол объектного доступа в 1998 году Дэйвом Винером, Доном Боксом, Бобом Аткинсоном, и Mohsen Al-Ghosein для Microsoft, где работали Аткинсон и Al-Ghosein. Спецификация не была доступна до тех пор, пока она не была представлена ​​IETF 13 сентября 1999 г. Согласно Дону Боксу, это было связано с политикой Microsoft. Из-за колебаний Microsoft Дэйв Винер отправил XML-RPC в 1998 году.

Отправленный Internet Draft не достиг RFC статус s и поэтому не считается «стандартом» как таковой. Версия 1.1 спецификации была опубликована в виде примечания W3C 8 мая 2000 г. Поскольку версия 1.1 не достигла статуса Рекомендации W3C, ее также нельзя считать "стандартной". Версия 1.2 спецификации, однако, стала рекомендацией W3C 24 июня 2003 г.

Спецификация SOAP поддерживалась Рабочей группой протокола XML консорциума World Wide Web., пока группа не была закрыта 10 июля 2009 г. Изначально SOAP расшифровывался как «протокол простого доступа к объектам», но в версии 1.2 стандарта этот акроним был удален.

После того, как SOAP был впервые представлен, он стал основным уровнем более сложный набор веб-служб, основанный на языке описания веб-служб (WSDL), XML-схеме и обнаружение и интеграция универсального описания (UDDI). Эти различные сервисы, особенно UDDI, оказались гораздо менее интересными, но их понимание дает полное понимание ожидаемой роли SOAP по сравнению с тем, как на самом деле развивались веб-сервисы.

Терминология SOAP

Спецификация SOAP может быть широко определена как состоящая из следующих 3 концептуальных компонентов: концепции протокола, концепции инкапсуляции и концепции сети.

Концепции протокола

SOAP
Это набор правил, формализующих и регулирующих формат и правила обработки информации, передаваемой между отправителем SOAP и получателем SOAP.
Узлы SOAP
Это физические / логические машины с блоками обработки, которые используются для передачи / пересылки, приема и обработки сообщений SOAP. Они аналогичны узлам в сети.
Роли SOAP
На пути сообщения SOAP все узлы принимают на себя определенную роль. Роль узла определяет действие, которое узел выполняет с полученным сообщением. Например, роль «нет» означает, что ни один узел не будет обрабатывать заголовок SOAP каким-либо образом и просто передавать сообщение по своему пути.
Привязка протокола SOAP
Сообщение SOAP должно работать в сочетании с другими протоколами для передачи по сети. Например, сообщение SOAP может использовать TCP в качестве протокола нижнего уровня для передачи сообщений. Эти привязки определены в структуре привязки протокола SOAP.
Функции SOAP
SOAP предоставляет только структуру обмена сообщениями. Однако его можно расширить, добавив такие функции, как надежность, безопасность и т. Д. Существуют правила, которые необходимо соблюдать при добавлении функций в структуру SOAP.
Модуль SOAP
Набор спецификаций, касающихся семантика заголовка SOAP для описания любых новых функций, расширяемых в SOAP. Модуль должен реализовывать ноль или более функций. SOAP требует, чтобы модули придерживались установленных правил.

Концепции инкапсуляции данных

Сообщение SOAP
Представляет информацию, которой обмениваются 2 узла 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, определяющей правила обработки сообщения SOAP
  • Модель расширяемости SOAP, определяющая концепции функций SOAP и модулей SOAP
  • Структура привязки базового протокола SOAP, описывающая правила для определения привязки к базовому протоколу, который может использоваться для обмена сообщениями SOAP между узлами SOAP
  • Конструкция сообщения SOAP, определяющая структуру сообщения SOAP

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

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

ЭлементОписаниеОбязательно
КонвертОпределяет документ XML как сообщение SOAP.Да
ЗаголовокСодержит информацию заголовка.Нет
ТелоСодержит информацию о вызовах и ответах.Да
FaultПредоставляет информацию об ошибках, возникших при обработке сообщения.Нет

Транспортные методы

Оба SMTP и HTTP являются допустимыми протоколами прикладного уровня, используемыми в качестве транспорта для SOAP, но HTTP стал шире признание, поскольку это хорошо работает с современной интернет-инфраструктурой; в частности, HTTP хорошо работает с сетевыми межсетевыми экранами. SOAP также может использоваться поверх HTTPS (который является тем же протоколом, что и HTTP на уровне приложения, но использует зашифрованный транспортный протокол ниже ) с простой или взаимной аутентификацией; это рекомендованный метод WS-I для обеспечения безопасности веб-службы, как указано в базовом профиле WS-I 1.1.

Это главное преимущество перед другими распределенными протоколами, такими как GIOP / IIOP или DCOM, которые обычно фильтруются межсетевыми экранами. SOAP over AMQP - еще одна возможность, поддерживаемая некоторыми реализациями. SOAP также имеет преимущество перед DCOM в том, что на него не влияют права безопасности, настроенные на машинах, которым требуется знание как передающих, так и принимающих узлов. Это позволяет слабо связывать SOAP, что невозможно с DCOM. Также существует стандарт SOAP-over-UDP OASIS.

Формат сообщения

Информационный набор XML был выбран в качестве стандартного формата сообщений из-за его широкого использования крупными корпорациями и при разработке с открытым исходным кодом. Обычно набор информации XML сериализован как XML. Широкий спектр свободно доступных инструментов значительно упрощает переход к реализации на основе SOAP. Несколько длинный синтаксис из XML может быть как преимуществом, так и недостатком. Хотя он способствует удобочитаемости для людей, облегчает обнаружение ошибок и позволяет избежать проблем совместимости, таких как порядок байтов (endianness ), он может снизить скорость обработки и может быть громоздким. Например, CORBA, GIOP, ICE и DCOM используют гораздо более короткие двоичные форматы сообщений. С другой стороны, доступны аппаратные устройства для ускорения обработки сообщений XML. Двоичный XML также исследуется как средство оптимизации требований к пропускной способности XML. XML-сообщения по своей самодокументированной природе обычно имеют больше «накладных расходов» (например, заголовков, вложенных тегов, разделителей), чем фактические данные, в отличие от более ранних протоколов, где накладные расходы обычно составляли относительно небольшой процент от общего сообщения.

При обмене финансовыми сообщениями SOAP приводил к сообщению в 2–4 раза больше, чем предыдущие протоколы FIX (обмен финансовой информацией) и CDR (представление общих данных).

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

Пример сообщения (инкапсулировано в HTTP)

В сообщении ниже запрашивается цена акций ATT (биржевой символ "T").

POST / InStock HTTP / 1.1 Хост: www.example.org Content-Type: application / soap + xml; charset = utf-8 Content-Length: 299 SOAPAction: "http://www.w3.org/2003/05/soap-envelope" T

Техническая критика

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

  • Характеристики нейтральности SOAP явно делает его пригодным для использования с любым транспортным протоколом. Реализации часто используют HTTP в качестве транспортного протокола, но могут использоваться и другие популярные транспортные протоколы. Например, SOAP также может использоваться через SMTP, JMS и очереди сообщений.
  • SOAP, в сочетании с обменом сообщениями / ответами HTTP, легко туннелируется через существующие межсетевые экраны и прокси и, следовательно, не работает. t требуют модификации широко распространенных вычислительных и коммуникационных инфраструктур, существующих для обработки обмена сообщениями и ответами HTTP.
  • SOAP имеет в своем распоряжении все возможности XML, включая простую интернационализацию и расширяемость с помощью пространств имен XML.

Недостатки

  • При использовании стандартной реализации и привязки SOAP / HTTP по умолчанию информационный набор XML сериализуется как XML. Чтобы повысить производительность для особого случая XML со встроенными двоичными объектами, был введен механизм оптимизации передачи сообщений.
  • При использовании HTTP в качестве транспортного протокола и без использования веб-служб Обращаясь к или Enterprise Service Bus, роли взаимодействующих сторон фиксируются. Только одна сторона (клиент) может использовать услуги другой стороны.
  • SOAP менее «прост», чем следует из названия. Многословие протокола, медленная скорость синтаксического анализа XML и отсутствие стандартизированной модели взаимодействия привели к доминированию служб, использующих протокол HTTP напрямую. См., Например, REST.

См. Также

Ссылки

Дополнительная литература

Внешние ссылки

Последняя правка сделана 2021-06-06 04:00:08
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте