ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

ГОСТ Р исо/мэк 40210—

2014

Информационные технологии W3C SOAP —Версия 1.2

Часть 1

Основы обмена сообщениями (Вторая редакция)

ISO/IEC 40210:2011 Information technology — W3C SOAP Version 1.2 Part 1: Messaging Framework (Second Edition) (IDT)

Издание официальное

Москва

Стандартинформ

Предисловие

1    ПОДГОТОВЛЕН Обществом с ограниченной ответственностью «Информационно-аналитический вычислительный центр» (ООО «ИАВЦ») и Закрытым акционерным обществом «ИТ Эксперт» (ЗАО «ИТ Эксперт») на основе собственного аутентичного перевода на русский язык международного стандарта, указанного в пункте 4

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 22 «Информационные технологии»

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 11 июня 2014 г. № 558-ст

4    Настоящий стандарт идентичен международному стандарту ИСО/МЭК 40210:2011 «Информационные технологии. W3C SOAP — Версия 1.2. Часть 1. Основы обмена сообщениями (Вторая редакция)» [ISO/IEC 40210:2011 «Information technology — W3C SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)»]

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА

5    ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в годовом (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячно издаваемом информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (gost.ru)

© Стандартинформ, 2014

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

ГОСТ Р ИСО/МЭК 40210—2014

5.3    Предназначение блоков заголовка SOAP

Блок заголовка SOAP МОЖЕТ нести в себе информационный объект-атрибут role (см. пункт 8.2.2), который используется для указания того, что блок заголовка предназначен для узлов SOAP, действующих в указанной роли. Данная спецификация рассматривает значение информационного объекта-атрибута role SOAP как роль SOAP для соответствующего блока заголовка SOAP.

Считается, что блок заголовка SOAP предназначен для узла SOAP, если роль SOAP в блоке заголовка совпадает с именем роли, в которой действует узел SOAP. Блоки заголовка SOAP, предназначенные для специальной роли «http://www.w3.org/2003/05/soap-envelope/role/none», формально никогда не обрабатываются. Такие блоки заголовка SOAP МОГУТ нести данные, которые необходимы для обработки других блоков заголовка SOAP. Если они не удалены в процессе обработки посредниками (см. пункт 5.7), то такие блоки передаются вместе с сообщением к конечному получателю (см. также пункт 6.3).

5.4    Понимание блоков заголовка SOAP

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

Блок заголовка SOAP МОЖЕТ содержать информационный объект-атрибут mustUnderstand (см. пункт 8.2.3). Считается, что блок заголовка SOAP обязателен в том случае, если значение этого информационного объекта-атрибута равно «true».

Предполагается, что обязательные блоки заголовка SOAP так или иначе изменяют семантику других блоков заголовка SOAP или элементов тела SOAP. Поэтому каждый обязательный блок заголовка SOAP, предназначенный для определенного узла, этот узел ДОЛЖЕН либо обработать, либо отказаться от обработки сообщения SOAP вообще и вместо обработки сгенерировать отказ (см. пункт 5.6 и пункт 8.4). Пометка блока заголовка SOAP как «обязательный» таким образом гарантирует, что подобные изменения не будут (очевидно, ошибочно) проигнорированы без каких-либо сообщений узлом SOAP, для которого предназначен блок заголовка.

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

5.5    Структура и интерпретация тела SOAP

Конечный получатель SOAP ДОЛЖЕН правильно обработать непосредственные дочерние элементы тела SOAP (см. пункт 8.3). Однако, за исключением отказов SOAP (см. пункт 8.4), Часть 1 данной спецификации (настоящий документ) не налагает требований на определенную структуру или интерпретацию этих элементов, и не предоставляет никаких средств для определения технологии необходимой обработки.

5.6    Обработка сообщений SOAP

В данном разделе изложены правила, по которым обрабатываются сообщения SOAP.

В настоящей спецификации ничто не препятствует использованию методов, которые могли бы обеспечить большую гибкость в порядке обработки, таких как оптимистичный параллелизм, откаты и т.д. Если не указано иначе, обработка всех сгенерированных сообщений SOAP, отказов SOAP и побочных эффектов уровня приложения ДОЛЖНА быть семантически эквивалентна выполнению по отдельности следующих шагов в указанном порядке.

1    Определить набор ролей, в которых должен действовать узел. В процессе такого определения МОЖЕТ быть проверено содержимое конверта SOAP, включая любые блоки заголовка SOAP и тело SOAP.

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

3    Если один или больше блоков заголовка SOAP, определенных на предыдущем шаге, не понятны данному узлу, то сгенерировать отдельный отказ SOAP со значением Value кода Code установленным в «env:MustUnderstand» (см. пункт 8.4.8). В случае такого отказа, дальнейшая обработка НЕ ДОЛЖНА производиться. Отказы, относящиеся к содержимому тела SOAP, НЕ ДОЛЖНЫ производиться на данном шаге.

Примечание — Настоящая спецификация использует термин «Расширенное имя XML», подразумевая под этим для значения типа xsd:Qname, заданных как пара из пространства значений {абсолютная ссылка на универсальный идентификатор объекта uri, локальное имя}. Такая терминология обсуждается для включения ее в будущие версии пространства имен в XML [Namespaces in XML], Если в будущих версиях пространства имен в ХМL [Namespaces in XML] будет принята другая терминология, то предполагается, что соответствующие изменения будут внесены в эту рекомендацию либо в виде исправления опечаток, либо будут внесены в будущем пересмотре версии.

4    Обработать все обязательные блоки заголовка SOAP, предназначенные для данного узла в случае конечного получателя SOAP, и тело SOAP. Узел SOAP МОЖЕТ также принять решение обработать необязательные блоки заголовка SOAP, предназначенные для него.

5    В случае, если узел является посредником SOAP и если шаблон обмена сообщениями SOAP и результаты обработки (например, не был сгенерирован какой-либо отказ) требуют, чтобы сообщение SOAP было отправлено далее по пути следования сообщения SOAP, передать сообщение далее, как описано в пункте 5.7.

Во всех случаях, при обработке блока заголовка SOAP, узел SOAP ДОЛЖЕН понять блок заголовка SOAP и ДОЛЖЕН произвести необходимую обработку способом, полностью совместимым со спецификацией для данного блока заголовка. Успешная обработка одного блока заголовка не гарантирует успешной обработки другого блока с тем же развернутым именем XML в том же сообщении. Обстоятельства, при которых такая обработка привела бы к отказу, определяет спецификация блока заголовка. Конечный получатель SOAP ДОЛЖЕН обработать тело SOAP способом, соответствующим пункту 5.5.

Признаком ошибки является генерация отказа (см. пункт 8.4). Обработка сообщения SOAP МОЖЕТ привести к генерации отказа SOAP, однако, при обработке сообщения SOAP НЕ ДОЛЖНО генерироваться более одного отказа SOAP.

Сообщение может содержать или вызывать несколько ошибок во время обработки. За исключением специально оговоренных случаев порядка обнаружения ошибок (как, например, в пункте 5.4), узел SOAP наделен свободой выбора любого отдельного отказа из набора возможных отказов, предписанных для различных возможных ошибок. Выбор отказа для генерации отказа не должен быть основан на выборе применения ключевого слова «ДОЛЖЕН», «СЛЕДУЕТ» или «МОЖЕТ», исключая тот случай, если один или больше установленных отказов квалифицируется с ключевым словом «ДОЛЖЕН». В последнем случае ДОЛЖЕН быть сгенерирован любой отказ из набора возможных отказов.

При обработке блока заголовка SOAP или тела SOAP узлы SOAP МОГУТ сослаться на любую информацию в конверте SOAP. Например, функция кэширования может кэшировать все сообщение SOAP, если это необходимо.

Обработка одного или более блоков заголовка SOAP МОЖЕТ определить или управлять порядком обработки других блоков заголовка SOAP и/или тела SOAP. Например, можно создать блок заголовка SOAP, требующий производить обработку других блоков заголовка SOAP в лексикографическом порядке. При отсутствии подобного управляющего блока заголовка SOAP порядок обработки заголовка и обработки тела определяются непосредственно узлом SOAP. Блоки заголовка МОГУТ быть обработаны в произвольном порядке. Обработка блока заголовка МОЖЕТ предшествовать, МОЖЕТ чередоваться или МОЖЕТ следовать за обработкой тела SOAP. Например, обработка блока заголовка «начать транзакцию» обычно предшествовала бы обработке тела, функция «протоколирования» могла бы работать одновременно с обработкой тела, а обработка блока заголовка «завершение транзакции» могла бы следовать после завершения всей другой работы.

Примечание — Вышеперечисленные правила регламентируют обработку в отдельном узле. Расширения SOAP могут быть разработаны таким образом, чтобы обеспечить, надлежащий порядок обработки блоков заголовка SOAP на всем пути следования сообщения к конечному получателю SOAP. В частности, такие расширения могли бы определить, что должен быть сгенерирован отказ со значением Value кода Code, установленным

ГОСТ Р ИСО/МЭК 40210—2014

«env:Sender», в том случае, если некоторые блоки заголовка SOAP случайно остались после прохождения некоторой намеченной точки в пути следования сообщения. Такие расширения при определении, произошла ли ошибка, могут зависеть от присутствия или значения информационного объекта атрибута mustUnderstand в оставшихся случайно блоках заголовка SOAP.

5.7 Пересылка сообщений SOAP

Как отмечалось ранее в этом разделе, предполагается, что сообщение SOAP создается в начальном отправителе SOAP и отправлено конечному получателю SOAP через ноль или более посредников SOAP. Хотя SOAP сам по себе не определяет маршрутизацию или семантику пересылки, можно ожидать, что такая функциональность может быть определена как одна или более функций расширения SOAP (см. раздел 6). Цель данного раздела заключается в описании взаимодействия передачи сообщения с моделью распределенной разработки SOAP.

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

5.7.1 Пересылка блоков заголовка SOAP

Пересылка блоков заголовка SOAP с узла-посредника SOAP зависит от того, обработаны ли эти блоки заголовка данным узлом SOAP или нет. Блок заголовка SOAP вставляется повторно, если при обработке этого блока заголовка определяется, что блок заголовка должен быть повторно вставлен в передаваемое сообщение. Спецификация блока заголовка SOAP может потребовать пересылки блока заголовка в передаваемом сообщении в том случае, если блок заголовка нацелен на роль, в которой действует посредник SOAP, но не в случае обработки данным посредником. Такие блоки заголовка называются «пересылаемыми» (relayable).

Блок заголовка SOAP МОЖЕТ нести в себе информационный объект-атрибут relay (см. пункт 8.2.4). В случае, если значение такого информационного объекта атрибута «истинно», блок заголовка является пересылаемым (relayable). Передача пересылаемых (relayable) блоков заголовка описана в пункте 5.7.2.

Информационный объект-атрибут relay не влияет на блоки заголовка SOAP, предназначенные для роли отличной от роли, в которой действует посредник SOAP.

Информационный объект-атрибут relay не влияет на модель обработки SOAP в случае, если блок заголовка также содержит информационный объект-атрибута mustUnderstand со значением «true».

Информационный объект-атрибут relay не влияет на обработку сообщений SOAP конечным получателем SOAP.

Таблица 3 суммирует возможные варианты пересылки некоторого блока заголовка узлом SOAP. Каждая строка показывает, будет ли блок заголовка передан или удален в зависимости от значения информационного атрибута role блока заголовка, действует ли узел SOAP в этой роли и был ли блок заголовка понят и обработан.

Таблица 3 — Поведение узлов SOAP по пересылке

Роль Блок заголовка Краткое название Принято Понято и обработано Передано next Да Да Нет, если не вставлено повторно Нет Нет, если relay = «true» Определяемый пользователем Да Да Нет, если не повторно вставлено Нет Нет, если relay = «true» Нет Не применимо Да ultimateReceiver Да Да Не применимо Нет Не применимо None Нет Не применимо Да

9

5.7.2 Пересылающие посредники SOAP

Семантика одного или более блоков заголовка SOAP в сообщении SOAP или использование шаблона МЕР, МОЖЕТ потребовать, чтобы сообщение SOAP было передано к другому узлу SOAP от имени инициатора входящего сообщения SOAP. В этом случае обрабатывающий узел SOAP действует в роли пересылающего посредника SOAP.

Пересылающий посредник SOAP ДОЛЖЕН обработать сообщение согласно модели обработки SOAP, определенной в пункте 5.6. Кроме того, при подготовке сообщения SOAP для пересылки посредник ДОЛЖЕН:

1    Удалить все обработанные блоки заголовка SOAP.

2    Удалить все не пересылаемые (поп-relayable) блоки заголовка SOAP, которые были предназначены для пересылающего узла, но были проигнорированы во время обработки.

3    Сохранить все пересылаемые (relayable) блоки заголовка SOAP, которые были предназначены для пересылающего узла, но были проигнорированы во время обработки.

Пересылающие посредники SOAP ДОЛЖНЫ также соответствовать спецификациям использованных функций пересылки SOAP. Спецификация для каждой такой функции ДОЛЖНА определять необходимую семантику, включая правила, описывающие, как формируется передаваемое сообщение. В таких правилах МОЖЕТ быть описано размещение вставленных или повторно вставленных блоков заголовка SOAP. Вставленные блоки заголовка SOAP могут не отличаться от одного или более блоков заголовка, удаленных посредником. В данном случае обработка определена в терминах повторной вставки блоков заголовка (вместо того, чтобы оставить их на месте) с тем, чтобы подчеркнуть необходимость их обработки в каждом узле SOAP на всем пути следования сообщения SOAP.

5.7.2.1 Пересылаемый инфо-набор

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

В общем случае, если только не переопределено функциями обработки в посреднике SOAP (см. пункт 5.7.2), применяются следующие правила:

1    Все свойства инфо-набора XML сообщения ДОЛЖНЫ быть сохранены, за исключением случаев, перечисленных в правилах 2—22.

2    Информационный объект-элемент для блока заголовка, предназначенного для посредника, МОЖЕТ быть удален этим посредником из свойства [children] информационного объекта-элемента Header SOAP, как это описано в пункте 5.7.2.

3    Информационные объекты-элементы для дополнительных блоков заголовка МОГУТ быть добавлены к свойству [children] информационного объекта-элемента Header SOAP, как это описано в пункте 5.7.2. В таком случае информационный объект-элемент Header SOAP МОЖЕТ быть добавлен как первый элемент свойства [children] информационного объекта-элемента Envelope SOAP, если другого НЕТ.

4    Информационные объекты пробельного символа МОГУТ быть удалены из свойства [children] информационного объекта-элемента Envelope SOAP.

5    Информационные объекты пробельного символа МОГУТ быть добавлены к свойству [children] информационного объекта-элемента Envelope SOAP.

6    Информационные объекты пробельного символа МОГУТ быть удалены из свойства [children] информационного объекта-элемента Header SOAP.

7    Информационные объекты пробельного символа МОГУТ быть добавлены к свойству [children] информационного объекта-элемента Header SOAP.

8    Информационные объекты комментариев МОГУТ быть добавлены к свойству [children] информационного объекта-элемента Envelope SOAP.

9    Информационные объекты комментариев МОГУТ быть удалены из свойства [children] информационного объекта-элемента Envelope SOAP.

10    Информационные объекты комментариев МОГУТ быть добавлены к свойству [children] информационного объекта-элемента Header SOAP.

11    Информационные объекты комментариев МОГУТ быть удалены из свойства [children] информационного объекта-элемента Header SOAP.

12    Информационные объекты атрибута МОГУТ быть добавлены к свойству [attributes] информационного объекта-элемента Envelope SOAP.

13    Информационные объекты атрибута МОГУТ быть добавлены к свойству [attributes] информационного объекта-элемента Header SOAP.

14    Информационные объекты атрибута МОГУТ быть добавлены к свойству [namespace attributes] информационного объекта-элемента Envelope SOAP.

10

ГОСТ Р ИСО/МЭК 40210—2014

15    Информационные объекты атрибутов МОГУТ быть добавлены к свойству [namespace attributes] информационного объекта-элемента Header SOAP.

16    Информационные объекты атрибута role SOAP, которые присутствуют в свойстве [attributes] информационных объектов элементов блока заголовка SOAP, могут быть преобразованы как описано в пункте 8.2.2.

17    Информационные объекты атрибута mustUnderstand SOAP, которые присутствуют в свойстве [attributes] информационных объектов элементов блока заголовка SOAP, могут быть преобразованы, как описано в пункте 8.2.3.

18    Информационные объекты атрибута relay SOAP, присутствующие в свойстве [attributes] информационных объектов элементов блока заголовка SOAP, могут быть преобразованы как описано в пункте 8.2.4.

19    Свойство [base URI] информационного объекта document не обязательно должно сохраняться.

20    Свойство [base URI] информационных объектов элементов МОЖЕТ быть изменено или удалено.

21    Свойство [character encoding scheme] информационного объекта document МОЖЕТ быть изменено или удалено.

Все информационные элементы namespace в [in-scope namespaces] информационных элементов ДОЛЖНЫ быть сохранены. МОГУТ быть добавлены дополнительные информационные объекты namespace.

Примечание — Приведенные правила допускают подписание блоков заголовка SOAP, тела SOAP и комбинаций блоков заголовка SOAP и тела SOAP.

При отсутствии алгоритма канонизации для нормализации преобразований инфо-набора и в случае использования алгоритма канонизации «http://www.w3.org/TR/2001/REC-xml-c14n-20010315», параграфы 1 — 6 и 11 — 14 несовместимы с подписанием конверта SOAP, а параграфы 1, 2, 5, 6, 12 и 14 несовместимы с подписанием заголовка SOAP.

Аналогично, если используется алгоритм канонизации «http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments» то, с подписанием конверта SOAP несовместимы параграфы 7 и 8, а с подписанием заголовка SOAP несовместимы параграфы 9 и 10.

Примечание — Информационными элементами пробельного символа считаются те, свойство [character code] которых имеет значение #х20, #х9, #xD или #хА.

5.7.3 Активные посредники SOAP

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

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

5.8 Модель управления версиями SOAP

Версия сообщения SOAP идентифицируется расширенным именем XML информационного объекта-элемента, дочернего элемента информационного объекта document. У информационного объекта document сообщения SOAP версии 1.2 имеется дочерний информационный объект-элемент с [local name] Envelope и [namespace name] «http://www.w3.org/2003/05/soap-envelope» (см. пункт 8.1).

Узел SOAP определяет, поддерживает ли он версию сообщения SOAP на основании анализа каждого сообщения. В данном контексте «поддерживать» означает понимать семантику данной версии конверта SOAP. Модель управления версиями ограничена только информационным объектом элемента Envelope SOAP. При этом не рассматриваются версии блоков заголовка SOAP, кодировок, привязки протокола или чего-либо еще.

11

Узел 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

ГОСТ Р ИСО/МЭК 40210—2014

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

4    Информация, которую нужно передавать от узла к узлу.

Дополнительные требования к функции расширения МЕР приведены в пункте 6.2.

6.2    Шаблоны обмена сообщениями SOAP (MEPs)

Шаблон обмена сообщениями (МЕР) — это шаблон, который устанавливает образец для обмена сообщениями между узлами SOAP. МЕР — это вид функции расширения, и, если не указано иное, ссылки в этой спецификации на термин «функция расширения» применимы также к MEPs. МЕР «запрос-ответ» определенный в Части 2 SOAP 1.2 [Часть 2 SOAP] иллюстрирует спецификацию функции МЕР.

Спецификация шаблона обмена сообщениями ДОЛЖНА:

-    как требуется в пункте 6.1.1, предоставить URI как имя МЕР;

-    определить жизненный цикл обмена сообщениями, соответствующего шаблону;

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

-    определить нормальное и аварийное завершение процесса обмена сообщения, соответствующего шаблону.

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

МЕР является функцией расширения SOAP, таким образом, спецификация МЕР ДОЛЖНА соответствовать требованиям к спецификации функции расширения SOAP (см. пункт 6.1.1). Спецификация МЕР ДОЛЖНА также включать:

1    Любые требования к генерации дополнительных сообщений (например, ответов на запросы в МЕР «запрос/ответ»),

2    Правила для доставки или других действий с отказами SOAP, произошедших в процессе работы MEPs.

6.3    Модули SOAP

Термин «SOAP модуль» относится к спецификации синтаксиса и семантики одного или более блоков заголовка SOAP. Модуль SOAP реализует ноль или более функций SOAP. Спецификация модуля придерживается следующих правил. Модуль:

1    ДОЛЖЕН идентифицировать себя посредством URI. Это позволяет однозначно ссылаться на модуль на языках описания или во время переговоров.

2    ДОЛЖЕН определить функции, обеспечиваемые модулем (см. пункт 6.1).

3    ДОЛЖЕН четко и полностью определить содержание и семантику блоков заголовка SOAP, используемых для реализации рассматриваемых функциональных возможностей, включая в необходимых случаях внесение каких-либо изменений в модель обработки SOAP. Модель расширяемости SOAP не ограничивает степень возможного расширения SOAP, и при этом не препятствует тому, чтобы расширения изменили модель обработки SOAP, описанную в Части 2 «Модель обработки SOAP».

4    В описании функциональности, которую обеспечивает модуль, МОЖНО использовать соглашения о свойствах, определенные в SOAP 1.2 Части 2 [Часть 2 SOAP], раздел Соглашение по описанию функций расширения и привязки. Если эти соглашения соблюдаются, то спецификация модуля ДОЛЖНА четко определить отношения между абстрактными свойствами и их представлениями в конверте SOAP. Следует отметить, что можно специфицировать функцию расширения исключительно в терминах абстрактных свойств, а затем написать отдельную спецификацию модуля, который реализует эту функцию, отображая в модуле SOAP свойства, определенные в спецификации функции, в блоки заголовка SOAP.

5    ДОЛЖНЫ быть четко определены любые известные взаимодействия с телом SOAP или какие-либо изменения в интерпретации его. Кроме того, ДОЛЖНЫ быть четко определены любые известные взаимодействия с другими функциями расширения SOAP и модулями SOAP или какие-либо изменения в их интерпретации. Например, можно представить себе модуль, который шифрует и удаляет тело SOAP, вставляя вместо этого блок заголовка SOAP, содержащий контрольную сумму и указание относительно используемого механизма шифрования. Спецификация такого модуля указала бы, что алгоритм расшифрования на принимающей стороне должен быть применен ранее выполнения каких-либо других модулей, которые имеют дело с содержимым тела SOAP.

13

7 Структура привязки SOAP к протоколам

SOAP позволяет обмениваться сообщениями SOAP, используя различные надлежащие протоколы. Формальный набор правил передачи сообщения SOAP внутри или поверх другого протокола (нижележащего протокола) с целью обмена сообщениями называют привязкой. Структура привязки протокола SOAP обеспечивает общие правила для спецификации привязки протокола. Структура также определяет отношения между привязкой и узлами SOAP, которые реализуют такую привязку. Привязка к HTTP, описанная в Части 2 SOAP 1.2 [Часть 2 SOAP], иллюстрирует спецификацию привязки. Дополнительные привязки могут быть созданы посредством спецификаций, которые соответствуют структуре привязки, представленной в этой главе.

Спецификация привязки SOAP:

-    определяет функции расширения, обеспечиваемые привязкой;

-    определяет, каким образом службы нижележащего протокола используются, чтобы передать ин-фо-наборы сообщения SOAP;

-    определяет, как службы нижележащего протокола используются для выполнения условий, накладываемых функциями расширения, которые поддерживаются данной привязкой;

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

-    определяет требования к созданию совместимой реализации определенной привязки.

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

Скорее, привязка SOAP — это неотъемлемая часть узла SOAP (см. 5 Модель обработки SOAP).

7.1    Назначение структуры привязки

Назначение структуры привязки заключается в следующем:

1    Определить требования и понятия, которые характерны для всех спецификаций привязки.

2    Упростить однородное описание в ситуациях, когда несколько привязок поддерживает одни и те же функции, способствуя повторному использованию привязок.

3    Обеспечить согласованность спецификаций дополнительных функций.

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

7.2    Структура привязки

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

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

Распределенный конечный автомат, который управляет передачей данного сообщения SOAP на пути следования сообщения, является комбинацией базовой обработки SOAP (см. раздел 5), работающий в каждом узле, в сочетании со спецификацией привязки, соединяющей каждую пару узлов. Спецификация привязки ДОЛЖНА содержать один или более МЕР.

В случаях, когда спецификацией привязки поддерживается несколько функций расширения, спецификации этих функций ДОЛЖНЫ предоставлять всю информацию, необходимую для успешного применения функций в комбинации. Точно так же любые зависимости одной функции от другой (т.е., если успешное использование одной функции зависит от использования или неиспользования другой функции) ДОЛЖНЫ быть определены. Данная структура привязки не обеспечивает явного механизма контроля за использованием таких взаимозависимых функций.

ГОСТ Р ИСО/МЭК 40210—2014

Структура привязки не обеспечивает каких-либо средств для наименования или утилизирования информации, включающей в себя состояние в данном узле. Отдельная функция и спецификация привязки могут вводить собственные соглашения для спецификации состояние. Следует отметить, однако, что согласованность между привязками и функциями расширения, вероятно, будет лучше в тех ситуациях, когда спецификации нескольких функций принимают непротиворечивые соглашения для представления состояния. Например, несколько функций могли бы воспользоваться согласованной спецификацией для учетных данных аутентификации, идентификатора транзакции и т.д. Привязка HTTP в Части 2 SOAP 1.2 [Часть 2 SOAP] иллюстрирует одно из таких соглашений.

Как описано в разделе 8, каждое сообщение SOAP определено как инфо-набор XML, который состоит из информационного объекта document с одним и только одним дочерним элементом — конвертом: информационным объектом элемента Envelope SOAP. Поэтому минимальная задача привязки при передаче сообщения состоит в том, чтобы определить средства, которыми инфо-набор сообщения SOAP передается и воссоздается привязкой на получающем узле SOAP, и определить, каким образом осуществляется передача конверта с использованием функций нижележащего протокола.

В разделе 8 определено, что все конверты SOAP могут быть сериализованы с использованием сериализации XML 1.0. Таким образом привязки МОГУТ в качестве представления для передачи (on the wire) инфо-набора XML использовать XML 1.0 или более поздние версии. Однако структура привязки не требует, чтобы каждая привязка использовала бы сериализацию XML для передачи. Когда это необходимо, могут использоваться сжатие, шифрование, фрагментированные представления и т.д. В случае использования сериализации XML инфо-набора XML привязка МОЖЕТ потребовать использования определенной кодировки символов или набора кодировок.

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

Обработка сообщений в привязке МОЖЕТ обеспечить потоковую передачу. То есть узлы SOAP МОГУТ начать обрабатывать полученное сообщение SOAP сразу же, как только доступна необходимая информация. Обработка SOAP определена в терминах инфо-наборов сообщения SOAP (см. раздел 8). Несмотря на то, что при потоковой передаче получатель SOAP принимает такие инфо-наборы XML постепенно, результат обработки SOAP ДОЛЖЕН быть идентичным результату обработки в случае, когда конверт SOAP полностью был доступен до начала обработки. Например, как предусмотрено в пункте 5.6, идентификация предназначенных блоков заголовка SOAP и проверка всех атрибутов mustUnderstand должны быть сделаны прежде, чем будет продолжена дальнейшая обработка. В зависимости от представления, используемого для инфо-набора XML и порядка, в котором он передается, данное правило может ограничить характеристику потока передачи, которая может быть достигнута.

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

8 Логическая структура сообщения SOAP

Сообщение SOAP определено как инфо-набор XML, в котором информационные объекты комментариев, элементов, атрибутов, пространств имен и символов (character) могут быть сериализованы как XML 1.0. Необходимо отметить, что требование возможности сериализации указанных информационных элементов инфо-наборов сообщения SOAP как XML 1.0 НЕ ЯВЛЯЕТСЯ требованием сериализации с использованием XML 1.0. Инфо-набор сообщения SOAP содержит информационный объект— document с одним и только одним элементом в его свойстве [children], которое ДОЛЖНО быть информационным объектом элемента Envelope SOAP (см. пункт 8.1). Этот информационный объект является также и значением свойства [document element]. Свойства [notations] и [unparsed entities] оба пусты. Рекомендация «Информационный набор XML» [XML InfoSet] допускает контент, который не может быть непосредственно сериализован с использованием XML; например, символ #х0 допускается в инфо-наборе, но запрещен в XML. XML инфо-набор сообщения SOAP ДОЛЖЕН соответствовать требованиям сериализации XML 1.0 [XML 1.0].

Инфо-набор XML сообщения SOAP НЕ ДОЛЖЕН содержать информационный объект декларации типа документа (document type declaration).

15

Сообщения SOAP, отправленные начальными отправителями SOAP, НЕ ДОЛЖНЫ содержать информационные объекты инструкций обработки (processing instruction). Посредники SOAP НЕ ДОЛЖНЫ вставлять информационные объекты инструкций обработки в сообщения SOAP, которые они передают. Получатели SOAP, получающие сообщение SOAP, содержащее информационные объекты инструкций обработки, ДОЛЖНЫ генерировать отказ SOAP со значением Value элемента Code, установленным как «env:Sender». Однако в тех случаях, когда обнаружение посредником информационных элементов объектов инструкций обработки в пересылаемом сообщении нецелесообразно из соображений производительности, посредник МОЖЕТ оставить такие информационные объекты инструкций обработки неизменными в пересылаемом сообщении.

У информационных объектов элементов, определенных данной спецификацией, для которых определено, что свойство [children] может содержать только информационные объекты элементов, может также быть ноль или более дочерних символьных (character) информационных объектов. Символьный код каждого такого символьного информационного объекта ДОЛЖЕН принадлежать множеству пробельных символов, как определено XML 1.0 [XML 1.0]. Если не указано иначе, такие символьные информационные элементы считаются незначащими.

Информационные объекты комментариев МОГУТ присутствовать как дочерние элементы и/или потомки информационного объекта [document element], но не перед или после этого информационного объекта. В модели обработки имеются некоторые ограничения относительно того, когда информационные объекты комментариев могут быть добавлены и/или удалены (см. пункт 5.7.2.1).

8.1    Конверт SOAP

Информационный объект-элемент Envelope SOAP имеет:

-    [local name] Envelope;

-    [namespace name] http://www.w3.org/2003/05/soap-envelope;

-    ноль или более соответствующих требованиям пространства имен информационных объектов атрибутов в свойстве [attributes];

-    один или два информационных объекта элементов в его свойстве [children] в следующем порядке:

1    Необязательный информационный объект-элемент Header (см. пункт 8.2).

2    Обязательный информационный объект-элемент body (см. пункт 8.3).

8.1.1    Атрибут encodingStyle SOAP

Информационный объект-атрибут encodingStyle указывает на правила кодирования, используемые для сериализации частей сообщения SOAP.

Информационный объект-атрибут encodingStyle имеет:

-    [local name] encodingStyle;

-    [namespace name]”http://www.w3.org/2003/05/soap-envelope”.

Информационный объект-атрибут encodingStyle имеет тип xs:anyURI. Его значение идентифицирует набор правил преобразования в последовательную форму, которые могут использоваться, чтобы десериализовать сообщение SOAP.

Информационный объект-атрибут encodingStyle МОЖЕТ присутствовать в следующих компонентах:

1    Блок заголовка SOAP (см. пункт 8.2.1).

2    Дочерний информационный объект-элемент информационного объекта-элемента Body SOAP (см. пункт 8.3.1), если только этот дочерний элемент не является информационным объектом-элементом отказа SOAP (см. пункт 8.4).

3    Дочерний информационный объект-элемент информационного объекта-элемента Detail SOAP (см. пункт 8.4.5.1 Элементы детализации SOAP).

4    Любой потомок для вышеперечисленных в 1,2 и 3.

Информационный объект-атрибут encodingStyle не ДОЛЖЕН появляться ни в каких элементах инфо-набора сообщения SOAP, кроме вышеупомянутых.

Область действия информационного объекта атрибута encodingStyle — это область действия его [owner element] и потомков этого информационного объекта-элемента, за исключением области действия какого-либо внутреннего информационного объекта-атрибута encodingStyle. Если в области действия нет никакого информационного объекта-атрибута encodingStyle или значением такого информационного объекта-атрибута является «http://www.w3.org/2003/05/soap-envelope/encoding/none», то никаких требований относительно кодирования этого информационного объекта-элемента и его потомков не накладывается.

ГОСТ Р ИСО/МЭК 40210—2014

Содержание

1    Область применения....................................................................................................................................1

2    Нормативные ссылки....................................................................................................................................2

3    Условные обозначения.................................................................................................................................2

4    Соответствие.................................................................................................................................................2

4.1    Общие положения.................................................................................................................................2

4.2    Связь с другими спецификациями.......................................................................................................3

4.3    Пример сообщения SOAP.....................................................................................................................4

4.4    Терминология SOAP..............................................................................................................................4

5    Модель обработки SOAP.............................................................................................................................5

5.1    Узлы SOAP.............................................................................................................................................6

5.2    Роли SOAP и узлы SOAP......................................................................................................................6

5.3    Предназначение блоков заголовка SOAP...........................................................................................7

5.4    Понимание блоков заголовка SOAP....................................................................................................7

5.5    Структура и интерпретация тела SOAP...............................................................................................7

5.6    Обработка сообщений SOAP................................................................................................................7

5.7    Пересылка сообщений SOAP...............................................................................................................9

5.8    Модель управления версиями SOAP.................................................................................................11

6    Модель расширяемости SOAP..................................................................................................................12

6.1    Функции расширения SOAP................................................................................................................12

6.2    Шаблоны обмена сообщениями SOAP (MEPs).................................................................................13

6.3    Модули SOAP.......................................................................................................................................13

7    Структура привязки SOAP к протоколам..................................................................................................14

7.1    Назначение структуры привязки.........................................................................................................14

7.2    Структура привязки.............................................................................................................................14

8    Логическая структура сообщения SOAP...................................................................................................15

8.1    Конверт SOAP......................................................................................................................................16

8.2    Заголовок SOAP...................................................................................................................................17

8.3    Тело SOAP...........................................................................................................................................18

8.4    Отказ SOAP..........................................................................................................................................19

9    Использование URL в SOAP......................................................................................................................25

10 Соображения безопасности.....................................................................................................................26

10.1    Узлы SOAP........................................................................................................................................26

10.2    Посредники SOAP............................................................................................................................26

10.3    Привязка нижележащего протокола................................................................................................27

Приложение А (справочное) Переход от версии SOAP/1.1 к SOAP версии 1.2.......................................28

Приложение ДА (справочное) Сведения о соответствии ссылочных международных

стандартов национальным стандартам Российской Федерации..................................29

Библиография................................................................................................................................................30

ГОСТ Р ИСО/МЭК 40210—2014

Пример - Возможные значения для информационного объекта атрибута encodingStyle.

«http://www.w3.org/2003/05/soap-encoding»

«http://example.org/encoding/»

«http://www.w3.org/2003/05/soap-envelope/encoding/none»

8.2 Заголовок SOAP

Информационный объект-элемент Header SOAP обеспечивает механизм расширения сообщения SOAP децентрализованным и модульным способом (см. раздел 6 и пункт 5.4).

Информационный объект-элемент Header имеет:

-    [local name] Header;

-    [namespace name]http://www.w3.org/2003/05/soap-envelope;

-    ноль или более соответствующих требованиям пространства имен информационных объектов атрибута в его свойстве [attributes];

-    ноль или более соответствующих требованиям пространства имен информационных объектов элементов в его свойстве [children].

Каждый дочерний информационный объект-элемент заголовка SOAP называют блоком заголовка SOAP.

8.2.1    Блок заголовка SOAP

Каждый информационный объект-элемент блока заголовка SOAP:

-    ДОЛЖЕН иметь свойство [namespace name], у которого есть значение; т.е. имя элемента ДОЛЖНО быть соответствующим требованиям пространства имен;

-    МОЖЕТ иметь любое число дочерних символьных (character) информационных объектов. Дочерние символьные информационные объекты, символьный код которых принадлежит множеству пробельных символов, как определено в XML 1.0 [XML 1.0], считаются значимыми;

-    МОЖЕТ иметь любое число дочерних информационных объектов элементов. Такие информационные объекты элементов МОГУТ соответствовать требованиям пространства имен;

-    МОЖЕТ иметь ноль или более информационных объектов атрибутов в свойстве [attributes]. Среди них МОГУТ быть любые из следующих, у которых есть специальное назначение для обработки SOAP:

-    информационный объект-атрибут encodingStyle (см. пункт 8.1.1);

-    информационный объект-атрибут role (см. 8.2.2 Атрибут role SOAP);

-    информационный объект-атрибут mustUnderstand (см. пункт 8.2.3);

-    информационный объект-атрибут relay (см. пункт 8.2.4).

Пример - Заголовок SOAP с единственным блоком заголовка SOAP <env:Header xmlns:env = “http://www.w3.org/2003/05/soap-envelope”>

<t:Transaction xmlns:t = “http:llexample.org/2001l06ttx” env.mustUnderstand = “true”>

5

</t:Transaction>

</env:Header>

8.2.2    Атрибут role SOAP

Роль SOAP используется, чтобы указать на узел SOAP, для которого предназначен определенный блок заголовка SOAP (см. пункт 5.2).

Информационный объект-атрибут role имеет следующие свойства инфо-набора XML:

-    [local name] role;

-    [namespace name] http://www.w3.org/2003/05/soap-envelope;

-    свойство [specified] со значением «true».

Тип информационного объекта атрибута role - xs:anyURI. Значение информационного объекта атрибута role - это URI, который определяет роль, которую может выполнять узел SOAP.

Если информационный объект-атрибут role SOAP опущен, то это эквивалентно предоставлению этого атрибута со значением «http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver».

Отправители SOAP НЕ ДОЛЖНЫ генерировать, но получатели SOAP ДОЛЖНЫ воспринимать информационный объект-атрибут role SOAP со значением «http://www.w3.org/2003/05/soap-envelope/role/ ultimateReceiver».

Передавая сообщение, посредник SOAP МОЖЕТ пропустить информационный объект-атрибут role SOAP, если его значение «http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver» (см. пункт 5.7).

17

Введение

SOAP версия 1.2 — это упрощенный протокол, предназначенный для обмена структурированной информацией в децентрализованной, распределенной среде. «Часть 1. Основы обмена сообщениями», используя технологии XML, определяет расширяемые основы обмена сообщениями, определяющие логическую структуру сообщений, которыми можно обмениваться с использованием различных нижележащих протоколов.

Настоящий документ является Рекомендацией W3C. Он был разработан группой XML_Protocol Working Group, которая является частью Web Services Activity. Эта вторая обновленная редакция заменяет исходную версию рекомендации, и в нее включены исправления всех обнаруженных опечаток. Различия между этими двумя версиями описаны в протоколе различий.

Этот документ рецензировался членами консорциума W3C, разработчиками программного обеспечения, и другими группами W3C и заинтересованными сторонами, и утвержден Директором в качестве Рекомендации W3C. Это устоявшийся документ, на который можно ссылаться и который можно цитировать в других документах в качестве нормативного. Участие W3C в разработке Рекомендации должно привлечь внимание к спецификации и способствовать ее широкому применению. Это улучшает функциональность и интероперабельность Всемирной паутины.

В случае обнаружения ошибок в этом документе, пожалуйста, отправьте их по адресу публичного списка рассылки: xmlp-comments@w3.org (архив). Письма дискуссионного характера по этому адресу нежелательны.

Версия 1.2 SOAP заменяет все предыдущие версии SOAP, включая версию SOAP 1.1 [SOAP 1.1].

Отчеты о реализациях SOAP 1.2 представлены в http://www.w3.Org/2000/xp/Group/2/03/soap1.2implementation.html.

Этим документ соответствует Текущей патентной практике СРР от 24 января 2002 с учетом исправлений процедуры перехода патентной политики W3C. W3C поддерживает общедоступный список любых патентных сведений, составленный в соответствии с публикациями группы. Кроме того, на этой странице имеются инструкции, как раскрыть патент. Если кто-либо обладает действительным знанием патенте, который удовлетворяет существенным требованиям, то он должен раскрыть эту информацию в соответствии с разделом 6 патентной политики W3C.

Список текущих рекомендаций W3C и другие технические отчеты можно найти по адресу: http://www.w3.org/TR.

IV

Информационные технологии W3C SOAP —Версия 1.2.

Часть 1

Основы обмена сообщениями (Вторая редакция)

Information technologies. W3C SOAP version 1.2.

Part 1. Messaging framework (second edition)

Дата введения — 2015—06—01

1 Область применения

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

Две главные цели проекта для SOAP — это простота и расширяемость (см. требования XMLP [XMLP Requirements]). При разработке SOAP была сделана попытка удовлетворить этим целям, исключив из структуры обмена сообщениями функции, которые часто обеспечиваются непосредственно распределенными системами. В список таких функций входят «надежность», «безопасность», «взаимозависимость», «маршрутизация» и «шаблоны обмена сообщениями» (MEPs), однако, этот список не ограничен только этими функциями. Несмотря на то, что казалось бы, что многие функции будут определены, данный документ ограничен спецификацией только двух шаблонов MEPs. Остальные функции оставлены для определения другими спецификациями в качестве расширений.

Спецификация SOAP версии 1.2 состоит из трех частей. Часть 1 спецификации SOAP версии 1.2 (настоящий документ) определяет основы обмена сообщениями SOAP и включает в себя:

1)    модель обработки SOAP, определяющую правила обработки сообщений SOAP (см. раздел 5);

2)    модель расширяемости SOAP, определяющую понятия функций SOAP и модулей SOAP (см. раздел 6);

3)    базовую структуру привязки протокола SOAP, описывающую правила задания привязки к нижележащему протоколу, который может использоваться для обмена сообщениями SOAP между узлами SOAP (см. раздел 7);

4)    логическую структуру сообщения SOAP, определяющую структуру сообщения SOAP (см. раздел 8).

Учебник для начинающих по SOAP 1.2 [Part 0: SOAP] является ненормативным документом, предназначенным для использования в качестве доступного учебного пособия по функциям спецификации SOAP версии 1.2.

Часть 2. SOAP 1.2 [Part 2: SOAP] описывает ряд дополнений, которые могут использоваться вместе со структурой обмена сообщениями SOAP.

Примечание — В предыдущих версиях данной спецификации название SOAP было аббревиатурой. Теперь это не так.

Издание официальное

2    Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие международные стандарты. Для датированных документов используют только указанное издание. Для недатированных документов используют самое последнее издание ссылочного документа (с учетом всех его изменений).

ИСО/МЭК 40220:2011 Информационные технологии. Версия 1.2 W3C SOAP. Часть 2. Дополнения (второе издание) (ISO/IEC 40220:2011, Information technology-SOAP Version 1.2 Part 2: Adjuncts (Second Edition)

Гипертекстовый Протокол передачи — HTTP/1.1 (RFC 2616 Hypertext Transfer Protocol — HTTP/1.1) Ключевые слова, используемые в RFCs, чтобы указать на уровни требования (RFC 2119 Key words for use in RFCs to Indicate Requirement Levels)

XML-схема Часть 1. Структуры. Вторая редакция (XML Schema Part 1: Structures Second Edition) XML-схема Часть 2. Типы данных. Вторая редакция (XML Schema Part 2: Datatypes Second Edition) Универсальный идентификатор ресурса (URI): Основы синтаксиса (Uniform Resource Identifiers (URI): Generic Syntax)

Пространства имен в XML (вторая редакция) (Namespaces in XML (Second Edition)

Расширяемый язык разметки (XML) 1.0 (четвертая редакция) (Extensible Markup Language (XML) 1.0 (Fourth Edition)

Информационный набор XML (вторая редакция) (XML Information Set (Second Edition)

Основы XML (XML Base)

3    Условные обозначения

Ключевые слова «ДОЛЖЕН» (MUST), «НЕ ДОЛЖЕН» (MUST NOT), «ТРЕБУЕМЫЙ» (REQUIRED), «БУДЕТ» (SHALL), «НЕ БУДЕТ» (SHALL NOT), «СЛЕДУЕТ» (SHOULD), «НЕ СЛЕДУЕТ» (SHOULD NOT), «РЕКОМЕНДУЕМЫЙ» (RECOMMENDED), «МОЖЕТ» (MAY) и «ДОПОЛНИТЕЛЬНЫЙ» (OPTIONAL) в данном документе должны интерпретироваться в соответствии с RFC2119 [RFC 2119].

Префиксы пространств имен, использующиеся в данной спецификации, перечислены в таблице 1. Необходимо отметить, что выбор любого префикса пространства имен произволен и не является семантически существенным (см. Инфо-набор XML [XML InfoSet]).

Таблица 1— Префиксы и пространства имен, используемые в данной спецификации.

Префикс Пространство имен Примечания ENV http://www.w3.org/2003/05/soap-envelope Описание нормативной схемы XML [Часть 1 XML-схемы], [Часть 2 XML-cxeMbi]XML для пространства имен http://www.w3.org/2003/05/soap-envelope может быть найдено по адресу: http://www.w3.org/2003/05/soap-envelope XS http://www.w3.org/2001/XMLSchema Спецификация пространства имен XML-схемы [Часть 1 XML-схемы], [Часть 2 XML-схемы]

Имена из пространства имен общей формы http://example.org/... и http://example.com/... представляют собой универсальные идентификаторы ресурсов (URI) приложений или контекстно-зависимые URI (см. RFC 3986 [RFC 3986]).

Все части настоящей спецификации являются нормативными, за исключением примеров и разделов, явно отмеченных как «Ненормативные».

4 Соответствие

4.1 Общие положения

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

ГОСТ Р ИСО/МЭК 40210—2014

Для соответствия спецификации SOAP версии 1.2 конкретная реализация ДОЛЖНА корректно реализовать все обязательные (MUST) требования, сформулированные в части 1 спецификации SOAP версии 1.2 (настоящий документ) и которые необходимы для выполнения операций. Необходимо отметить, что от реализации не требуется выполнение всех обязательных требований. Например, специфическая реализация, которая никогда не отправляет блок заголовка SOAP, может претендовать на соответствие при условии, что правильно выполняются обязательные требования для сообщений, которые она фактически отправляет.

В реализации МОЖЕТ быть использовано любое число дополнений, определенных в Части 2 SOAP версии 1.2 [Часть 2 SOAP], Нужно заметить, что соответствие никак не связано с соглашением для описания функций и привязки (см. разделы 6 и 7). Для соответствия дополнениям реализации дополнения ДОЛЖНЫ выполнять все необходимые обязательные требования, определенные в спецификации дополнения.

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

Версия 1.2 SOAP разработана для того, чтобы обеспечить выполнение, по крайней мере, сценариев использования, описанных в «Сценарии использования SOAP 1.2» [Сценарии использования SOAP], и, возможно, других сценариев. Неформальные описания, демонстрирующие XML представление конкретных сообщений SOAP, используемых в некоторых общих сценариях, приводятся в Части 0 SOAP 1.2 [Часть 0 SOAP],

4.2 Связь с другими спецификациями

Сообщение SOAP определено в виде информационного набора (инфо-набора) XML [XML InfoSet], Хотя в настоящем документе все примеры сообщений SOAP приводятся с использованием синтаксиса XML 1.0 [XML 1.0], для передачи сообщения SOAP между узлами МОГУТ использоваться и другие представления (см. раздел 7).

Некоторые информационные объекты, определенные в этом документе (см. раздел 8), идентифицированы с использованием соответствующих требований имен пространства имен [Namespaces in XML], Список имен пространств имен, определенных в этом документе, приводится в Таблице 1.

Примечание — Настоящая спецификация использует термин «Расширенное имя XML», подразумевая под этим для значения типа xsd:Qname, заданных как пара из пространства значений [абсолютная ссылка на универсальный идентификатор объекта uri, локальное имя]. Такая терминология обсуждается для включения ее в будущие версии пространства имен в XML [Namespaces in XML], Если в будущих версиях пространства имен в XML [Namespaces in XML] будет принята другая терминология, то предполагается, что соответствующие изменения будут внесены в эту рекомендацию либо в виде исправления опечаток, либо будут внесены в будущем пересмотре версии.

SOAP не требует обработки XML-схемы (оценка или проверка допустимости) для установления правильности или соответствия схеме значений информационных объектов элементов и атрибутов, определенных разделами 4 и 5 данной спецификации. Значения, связанные с информационными объектами элементов и атрибутов, определенными в этой спецификации, ДОЛЖНЫ явно задаваться в отправленном сообщении SOAP за исключением лишь тех случаев, когда заявлено обратное (см. раздел 8).

Типы информационных объектов-атрибутов SOAP описываются XML-схемой [Часть 2 XML-схемы]. Если не указано иначе, то для каждого такого атрибута поддерживаются все лексические формы. Кроме того, лексические формы, представляющие одно и то же значение в пространстве значений XML-схемы, считаются эквивалентными в смысле обработки SOAP, например, булевы лексические формы «1» и «true» взаимозаменяемы. Для краткости текст в настоящей спецификации дается только в одной лексической форме для каждого значения, например, «если значение информационного объекта-атрибута mustUnderstand равно ‘true’».

Спецификации обработки данных приложений, которые передаются в сообщении SOAP, но не определены данной спецификацией, МОГУТ требовать дополнительной проверки допустимости сообщения SOAP в сочетании с обработкой уровня приложения. В таких случаях выбор языка схемы и/или технологии проверки допустимости определяется приложением.

3

SOAP использует спецификацию XML Base [XML Base] при определении базовых URI для относительных ссылок URI, используемых в качестве значений в информационных объектах, определенных данной спецификацией (см. раздел 9).

Для сериализации инфо-набора XML 1.0 сообщения SOAP ДОЛЖЕН использоваться тип медиа «application/soap+xml» (см. SOAP 1.2. Часть 2 [Часть 2 SOAP], Тип медиа «application/soap+xml»).

4.2.1    Требования к обработке

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

4.3    Пример сообщения SOAP

Следующий пример демонстрирует сообщение-уведомление, выраженное посредством SOAP. Сообщение содержит две части данных, определенных приложением и не определенных данной спецификацией: блок заголовка SOAP с локальным именем alertcontrol и элемент тела с локальным именем alert. Как правило, блоки заголовка SOAP содержат информацию, которая могла бы быть полезной для посредников SOAP, а также для адресата сообщения. В этом примере посредник (intermediary) мог бы установить приоритет доставки сообщения на основе приоритета и информации о сроке действия в блоке заголовка SOAP. Тело содержит фактическую полезную информацию сообщения, в данном случае предупреждение.

Пример — Сообщение SOAP, содержащее блок заголовка SOAP и тело SOAP

<env:Envelope xmlns:env=”http://www.w3.org/2003/05/soap-envelope”>

<env:Header>

<n :alertcon trol xmlns :n=”h ttp .//example. org/alertcontrol”>

<n:priority> 1 </n:priority>

<n:expires>2001-06-22T14:00:00-05:00</n:expires>

</n:alertcontrol>

</env:Header>

<env:Body>

<m:alert xmlns:m=”http://example.org/alert”>

<m:msg>Pick up Mary at school at 2pm</m:msg>

</m:alert>

<Jenv:Body>

</env:Envelope>

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

В этом разделе описываются условия и понятия, представленные в Части 1 спецификации SOAP версии 1.2 (настоящий документ).

4.4.1    Понятия протокола

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

Узел SOAP: Реализация логики обработки, необходимой для посылки, получения, обработки и/или передачи сообщения SOAP в соответствии с набором соглашений, определенных этой рекомендацией. Узел SOAP ответственен за выполнение правил, которые управляют обменом сообщениями SOAP (см. раздел 5). Узел получает доступ к услугам, предоставляемым нижележащими протоколами посредством одной или более привязки SOAP.

Роль SOAP: Ожидаемая функция получателя SOAP в обработке сообщения. Получатель SOAP может действовать более чем в одной роли.

Привязка SOAP: Формальный ряд правил для того, чтобы передать сообщение SOAP внутри или поверх другого протокола (нижележащего протокола) в целях обмена сообщениями (см. раздел 7). Примеры привязки SOAP включают передачу сообщения SOAP в теле объекта HTTP, или по потоку TCP.

ГОСТ Р ИСО/МЭК 40210—2014

Дополнительная функция SOAP: Расширение структуры обмена сообщениями SOAP (см. раздел 6). Примеры дополнительных функций включают «надежность», «безопасность», «взаимодействие», «маршрутизацию» и «шаблоны обмена сообщениями» (МЕР).

Модуль SOAP: Модуль SOAP — это спецификация, которая содержит объединенный синтаксис и семантику блоков заголовка SOAP, определенные согласно правилам из пункта 6.3. Модуль SOAP реализует ноль или более дополнительных функций SOAP.

Шаблон обмена сообщениями SOAP (МЕР): Шаблон для обмена сообщениями SOAP между узлами SOAP, поддерживаемый одной или более привязкой SOAP к нижележащему протоколу (см. раздел 7). SOAP МЕР — пример дополнительной функции SOAP (см. пункт 6.2).

Приложение SOAP: Объект, обычно программное обеспечение, которое производит, использует или иным образом реагирует на сообщения SOAP способом, соответствующим модели обработки SOAP (см. раздел 5).

4.4.2    Понятие инкапсуляции данных

Сообщение SOAP: Основная единица передачи между узлами SOAP.

Конверт SOAP: Информационный объект-элемент, обрамляющий сообщение SOAP.

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

Блок заголовка SOAP: Информационный объект-элемент, используемый, чтобы разграничить данные, которые логически составляют единственный вычислительный модуль внутри заголовка SOAP. Тип блока заголовка SOAP идентифицирован расширенным именем XML информационного объекта-элемента блока заголовка.

Тело SOAP: Набор нуля или больше информационных элементов, предназначенный для конечного получателя SOAP на пути следования сообщения SOAP (см. пункт 8.3).

Отказ SOAP: Информационный объект-элемент SOAP, который содержит информацию об отказе, сгенерированном узлом SOAP.

4.4.3    Понятия отправителя и получателя сообщения

Отправитель 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 (см. раздел 5).

5 Модель обработки SOAP

SOAP реализует модель распределенной разработки, которая предполагает, что сообщение SOAP генерируется начальным отправителем SOAP и отправляется конечному получателю SOAP через ноль или более посредников SOAP. Необходимо отметить, что модель распределенной разработки SOAP может поддерживать многие шаблоны MEPs и включает, не ограничиваясь ими, односторонние сообщения, взаимодействия типа «запрос/ответ» и одноранговые переговоры (описание функциональной зависимости между шаблонами обмена сообщениями SOAP и моделью расширяемости SOAP приводится в пункте 6.2).

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

5

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

Раздел 6 описывает, как SOAP может быть расширен, и как расширения SOAP могут взаимодействовать с моделью обработки SOAP и структурой привязки SOAP. Раздел 4 описывает структуру привязки SOAP к протоколам, определяет схему описания правил обмена сообщениями SOAP с использованием различных нижележащих протоколов.

5.1    Узлы SOAP

Узел SOAP может быть начальным отправителем SOAP, конечным получателем SOAP или посредником SOAP. Узел SOAP, получающий сообщение SOAP, ДОЛЖЕН выполнить обработку согласно модели обработки SOAP как описано в этом разделе и далее в этой спецификации. Узел SOAP идентифицируется универсальным идентификатором ресурса URI (см. пункт 8.4.3).

5.2    Роли SOAP и узлы SOAP

При обработке сообщения SOAP узел SOAP действует в одной или более ролях SOAP, каждая из которых имеет ролевое имя SOAP и идентифицирована URI. Роли, принятые узлом, ДОЛЖНЫ быть инвариантными во время обработки отдельного сообщения SOAP. Настоящая спецификация ограничена только обработкой отдельных сообщений SOAP. Нет никаких ограничений на возможность данного узла SOAP быть или не быть способным действовать в разных ролях при обработке более чем одного сообщения SOAP.

Таблица 2 определяет три ролевых имени, у которых есть специальное значение для сообщений SOAP (см. пункт 5.6).

Таблица 2 — Роли SOAP, определяемые данной спецификацией

Краткое название Имя Описание next http://www.w3.org/2003/05/soap-envelope/role/next Каждый посредник SOAP и конечный получатель SOAP ДОЛЖНЫ действовать в этой роли. none http://www.w3.org/2003/05/soap-envelope/role/none Узлы SOAP не ДОЛЖНЫ действовать в этой роли. ultimateReceiver http://www.w3.org/2003/05/soap-envelope/role/ ultimateReceiver Конечный получатель ДОЛЖЕН действовать в этой роли.

Для удовлетворения потребностей приложений SOAP, по мере необходимости, МОГУТ быть использованы и другие ролевые имена в дополнение к ролевым именам SOAP, определенным в Таблице 2.

Назначение ролевого имени SOAP состоит в том, чтобы идентифицировать узел или узлы SOAP, однако, при этом с ролевым именем SOAP не связана никакая маршрутизация или семантика обмена сообщениями. Например, роль SOAP МОЖЕТ быть идентифицирована URI, применимым для маршрутизации сообщения SOAP к надлежащему узлу SOAP. С другой стороны, целесообразно использовать роли SOAP с именами, менее тесно связанными с маршрутизацией (например, «http://example. org/banking/anyAccountMgr») или совсем с ней не связанными (например, URI, предназначенный для идентификации «всего программного обеспечения управления кэшем». Блок заголовка SOAP, предназначенный для такой роли, мог бы использоваться, чтобы передать любому надлежащему программному обеспечению указание о том, что содержание сообщения SOAP является идемпотентным и может безопасно кэшироваться, и воспроизводиться).

За исключением трех ролевых имен SOAP, определенных в Таблице 2, настоящая спецификация не устанавливает никаких ограничений на определение конкретным узлом набора ролей, в которых он действует при обработке отдельного сообщения. Это может, например, определяться реализациями на основе следующих факторов, однако, не ограничиваться только ими: роли зафиксированы в исходном коде реализации; информация, предоставленная привязкой к нижележащему протоколу (например, URI, к которому сообщение было физически передано); или настроечная информация, предоставленная пользователями во время установки системы.

6