ГОСТ Р ИСО/МЭК 40210—2014
Узел SOAP МОЖЕТ поддерживать несколько версий конверта. Однако, обрабатывая сообщение,
узел SOAP ДОЛЖЕН использовать семантику, определенную версией этого сообщения.
Если узел SOAP получает сообщение, версию которого он не поддерживает, он ДОЛЖЕН генериро
вать отказ (см. пункт 8.4) с значением Value элемента Code, установленным как «env:VersionMismatch».
Любое другое несоответствие логической структуры сообщения ДОЛЖНО привести к генерации
отказа с значением Value элемента Code, установленным как «env.Sender».
Приложение А. Переход версии от SOAP/1.1 к SOAP версии 1.2 определяет механизм перехода от
SOAP/1.1 к SOAP версии 1.2 с использованием информационного объекта-элемента Upgrade (см. пункт 8.4.7).
6 Модель расширяемости SOAP
SOAP обеспечивает простую структуру обмена сообщениями, базовая функциональность которой
разрабатывалась с учетом обеспечения расширяемости. Механизмы расширяемости, описанные ниже,
можно использовать, чтобы добавить дополнительные возможности, доступные в других системах об
мена сообщениями.
6.1 Функции расширения SOAP
Функция расширения SOAP — расширение основ обмена сообщениями SOAP. SOAP не налагает
никаких ограничений на потенциальные возможности таких функций. Например, такио функции вклю
чать в себя «надежность», «безопасность», «взаимозависимость», «маршрутизацию» и «шаблоны об
мена сообщениями» (MEPs), а также запроо’ответ. односторонний и одноранговый обмен сообщениями.
Модель расширяемости SOAP обеспечивается двумя механизмами, посредством которых могут
быть реализованы функции расширения — это: Модель обработки SOAP и Структура привязки прото
кола SOAP (см. разделы 5 и 7). Первый из них определяет функциональные возможности отдельного
узла SOAP, относящиеся к обработке отдельного сообщения. Последний — обеспечивает выполнение
отправки и получения сообщений SOAP узлом SOAP через нижележащий протокол.
Модель обработки SOAP позволяет узлам SOAP, в которых имеются механизмы, необходимые
для выполнения одной или более функций, реализовать такие функции в виде блоков заголовка SOAP
внутри конверта SOAP (см. пункт 5.4). Такие блоки заголовка могут быть предназначены для любого
узла или узлов SOAP на пути следования сообщения SOAP (см. пункт 5.3). Сочетание синтаксиса и се
мантики блоков заголовка SOAP представляет собой модуль SOAP и определено согласно правилам,
перечисленным в пункте 6.3
Напротив, привязка протокола SOAP работает между двумя смежными узлами SOAP на пути сле
дования сообщения SOAP. Не требуется, чтобы один и тот же нижележащий протокол использовался
для всех транзитных участков на пути следования сообщения SOAP В некоторых случаях нижележа
щие протоколы имеют сами по себе или посредством расширения механизмы выполнения определен
ных функций. Посредством спецификации привязки структура привязки протокола SOAP обеспечивает
схему для описания таких функций и их связи с узлами SOAP (см. раздел 7).
Некоторые функции расширения могут требовать семантики обработки от начального узла до
конечного (end-to-end) в отличие от пошаговой от узла до узла (hop-by-hop). Несмотря на то. что струк
тура привязки протокола SOAP позволяет выражать сквозные (end-to-end) функции вне конверта SOAP,
какого-либо стандартного механизма обработки посредниками созданных таким образом сообщений не
предусмотрено. Спецификация привязки, которая определяет такие функции вне конверта SOAP,
должна определять свои собственные правила обработки для таких внешне выраженных функций.
Ожидается, что узел SOAP будет соответствовать этим правилам обработки (например, посредством
описания того, какая информация передается вместе с сообщением SOAP, исходящем от него, как
посредника). Обработка конвертов SOAP в соответствии с моделью обработки SOAP (см. раздел 5) НЕ
ДОЛЖНА переопределяться спецификациями привязки.
Там. где это целесообразно, рекомендуется, чтобы сквозные (end-to-end) функции расширения
были выражены в виде блоков заголовка SOAP таким образом, чтобы могли использоваться правила,
определенные моделью обработки SOAP.
6.1.1 Требования к функциям расширения
Спецификация функции расширения ДОЛЖНА включать следующее:
1 Используемый URI имени функции расширения. Это обеспечивает функции возможность ссы
латься на нее в языках описания или во время переговоров.
2 Информация (состояние), требуемая в каждом узле для реализации функции.
12