Данный документ представляет собой перевод на русский язык спецификации 
SOAP Version 1.2 Part 0: Primer, W3C Recommendation 24 June 2003, английский вариант которой является единственным 
официальным изданием.

Перевод данной спецификации на русский язык выполнен специалистами компании UBS.
Мы осознаем, что он неидеален, может содержать ошибки и неточности, и работаем над его улучшением. Все комментарии, касающиеся настоящего перевода, просьба направлять по адресу: info@ubs.ru

Copyright © 2003 UBS, Все права защищены. Перевод на русский язык.

w3c

SOAP Версия 1.2 Часть 0: Учебник для начинающих

Рекомендация W3C от 24 июня 2003 года

Эта версия:
http://www.w3.org/TR/2003/REC-soap12-part0-20030624/
Последняя версия:
http://www.w3.org/TR/soap12-part0/
Предыдущая версия:
http://www.w3.org/TR/2003/PR-soap12-part0-20030507/
Редактор:
Nilo Mitra (Ericsson)

Пожалуйста, при чтении используйте Список опечаток, который содержит некоторые нормативные поправки к настоящему документу.

Английская версия - единственная официальная версия настоящего документа. Доступны также неофициальные переводы настоящего документа.


Аннотация

Документ SOAP Версия 1.2 Часть 0: Учебник для начинающих не является нормативным, однако должен стать доступным учебным пособием по функциям SOAP Версия 1.2. В частности, он описывает функции SOAP на примере различных сценариев использования и призван дополнить нормативный текст Части 1 и Части 2 спецификаций SOAP 1.2.

Статус настоящего документа

Этот раздел описывает статус настоящего документа по состоянию на момент его публикации. Настоящий документ могут отменять (либо замещать собой) другие документы. Окончательный статус документов этой серии определен W3C.

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

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

Информацию о реализациях, относящихся к настоящей спецификации, можно найти в Implementation Report по адресу: http://www.w3.org/2000/xp/Group/2/03/soap1.2implementation.html.

Информацию о патентной принадлежности относительно настоящей спецификации, можно, в соответствии с политикой W3C, найти на странице информации о патентной принадлежности Рабочей Группы.

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

Содержание

1. Введение
1.1 Общий обзор документа
1.2 Соглашения об условных обозначениях
2. Основные сценарии использования
2.1 SOAP-сообщения
2.2 Обмен SOAP-сообщениями
2.2.1 Диалоговый обмен сообщениями
2.2.2 Вызовы удаленных процедур (RPC)
2.3 Сценарии обработки сообщений об ошибках
3. Модель обработки SOAP
3.1 Атрибут "role"
3.2 Атрибут "mustUnderstand"
3.3 Атрибут "relay"
4. Использование различных протокольных привязок
4.1 HTTP-привязка SOAP
4.1.1 Использование в SOAP HTTP-метода GET
4.1.2 Использование в SOAP HTTP-метода POST
4.1.3 Использование SOAP в соответствии с архитектурными принципами Web
4.2 Использование SOAP поверх Email
5. Более сложные сценарии использования
5.1 Использование SOAP-посредников
5.2 Использование иных схем написания кода
6. Различия между SOAP 1.1 и SOAP 1.2
7. Ссылки
A. Благодарности
B. Глоссарий (Приложение, составленное переводчиком)

1. Введение

SOAP Версия 1.2 Часть 0: Учебник для начинающих не является нормативным документом, но призван стать доступным учебным пособием по функциям SOAP Версия 1.2. Описывая типичные структуры SOAP-сообщений и шаблоны обмена SOAP-сообщениями, он предназначен для помощи техническим специалистам в понимании того, как использовать SOAP.

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

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

[SOAP Часть 1] определяет оболочку SOAP, описывающую общую структуру представления содержимого SOAP-сообщения, а также идентифицирующую кто должен взаимодействовать с сообщением, надо ли взаимодействовать с сообщением как с целым или же только с какой-либо его составляющей, и является ли обработка этой составляющей сообщения обязательной или необязательной. Оболочка SOAP также определяет структуру протокольной привязки, которая описывает, как может быть создана спецификация привязки SOAP к другому нижележащему протоколу.

[SOAP Часть 2] определяет модель данных SOAP, подробную схему написания кода для типов данных, используемых для передачи вызовов удаленных процедур (RPC), а также конкретную реализацию структуры привязки к нижележащему протоколу, определенную в [SOAP Часть 1]. Эта привязка позволяет обмениваться SOAP-сообщениями либо в качестве полезной нагрузки запросов и откликов посредством HTTP-метода POST, либо отправлять SOAP-сообщение в качестве отклика на HTTP-метод GET.

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

1.1 Общий обзор документа

SOAP Версия 1.2 дает определение основанной на XML информации, которая может быть использована для обмена структурированной и типизированной информацией между узлами в децентрализованной, распределенной среде. [SOAP Часть 1] поясняет, что SOAP-сообщение формально задается как информационное множество XML [XML Infoset]], дающее абстрактное описание его содержимого. Информационные множества могут иметь различные представления, один из общих примеров которых находится в документе XML 1.0 [XML 1.0].

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

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

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

Раздел 4 настоящего документа описывает способы передачи SOAP-сообщений при реализации различных сценариев использования. Он описывает HTTP-привязку SOAP, определенную в [SOAP Часть 2], а также пример того, как SOAP-сообщения могут передаваться с помощью email-сообщений. HTTP-привязка вводит в употребление два доступных приложениям шаблона обмена сообщениями, один из которых использует HTTP-метод POST, а другой - HTTP-метод GET. Также представлены примеры того, как могут быть реализованы вызовы удаленных процедур RPC (в частности те, которые предназначены для "безопасного" поиска информации) при обмене SOAP-сообщениями в соответствии с архитектурными принципами World Wide Web.

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

Раздел 6 описывает различия настоящей спецификации и спецификации SOAP Версия 1.1 [SOAP 1.1].

Раздел 7 содержит ссылки на другие документы.

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

1.2 Соглашения об условных обозначениях

Все примеры SOAP-оболочек и SOAP-сообщений в настоящем учебнике представлены как [XML 1.0] XML-документы. [SOAP Часть 1] поясняет, что SOAP-сообщение формально определяется как информационное множество [XML InfoSet], которое представляет собой абстрактное описание его содержимого. Различие между информационными множествами XML SOAP и упомянутыми выше XML-документами вряд ли интересно тем, кто использует данный учебник в качестве введения в SOAP, те же, кто интересуется этим (как правило, это те, кто портирует SOAP на новые протокольные привязки, где сообщения могут иметь альтернативные представления), должны толковать эти примеры как ссылки на соответствующие информационные множества XML. Дальнейшее изложение этого вопроса можно найти в разделе 4 настоящего документа.

Префиксы пространств имен "env", "enc" и "rpc", используемые в разделах настоящего документа, обозначают пространства имен "http://www.w3.org/2003/05/soap-envelope" , "http://www.w3.org/2003/05/soap-encoding", и "http://www.w3.org/2003/05/soap-rpc" соответственно.

Префиксы пространств имен "xs" и "xsi", используемые в разделах настоящего документа, обозначают пространства имен "http://www.w3.org/2001/XMLSchema" и "http://www.w3.org/2001/XMLSchema-instance" соответственно, которые определены в спецификациях XML Schema [XML Schema Часть 1], [XML Schema Часть 2].

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

Унифицированные идентификаторы ресурсов (Uniform Resource Identifier, URI) пространства имен общей формы "http://example.org/..." и "http://example.com/..." представляют зависимые от конкретного приложения либо контекстно-зависимые URI [RFC 2396].

2. Основные сценарии использования

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

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

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

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

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

Раздел 2.2.2 предполагает, что будущим путешественником были одобрены различные параметры бронирования путешествия, и далее, посредством обмена сообщениями между приложением бронирования путешествий и сервисом продажи билетов, смоделированного как вызов удаленной процедуры (RPC), подтверждается оплата брони.

Раздел 2.3 демонстрирует примеры обработки ошибок.

2.1 SOAP-сообщения

Пример 1 показывает данные, необходимые для работы приложения бронирования путешествий, в виде SOAP-сообщения.

Пример 1
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> 
 <env:Header>
  <m:reservation xmlns:m="http://travelcompany.example.org/reservation" 
          env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
           env:mustUnderstand="true">
   <m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
   <m:dateAndTime>2001-11-29T13:20:00.000-05:00</m:dateAndTime>
  </m:reservation>
  <n:passenger xmlns:n="http://mycompany.example.com/employees"
          env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
           env:mustUnderstand="true">
   <n:name>Еke Jуgvan Шyvind</n:name>
  </n:passenger>
 </env:Header>
 <env:Body>
  <p:itinerary
    xmlns:p="http://travelcompany.example.org/reservation/travel">
   <p:departure>
     <p:departing>New York</p:departing>
     <p:arriving>Los Angeles</p:arriving>
     <p:departureDate>2001-12-14</p:departureDate>
     <p:departureTime>late afternoon</p:departureTime>
     <p:seatPreference>aisle</p:seatPreference>
   </p:departure>
   <p:return>
     <p:departing>Los Angeles</p:departing>
     <p:arriving>New York</p:arriving>
     <p:departureDate>2001-12-20</p:departureDate>
     <p:departureTime>mid-morning</p:departureTime>
     <p:seatPreference/>
   </p:return>
  </p:itinerary>
  <q:lodging
   xmlns:q="http://travelcompany.example.org/reservation/hotels">
   <q:preference>none</q:preference>
  </q:lodging>
 </env:Body>
</env:Envelope>
Образец SOAP-сообщения бронирования путешествия, содержащий заголовочный блок и тело сообщения

SOAP-сообщение примера 1 содержит два специфичных для SOAP субэлемента, находящихся внутри более общего элемента env:Envelope, а именно env:Header и env:Body. Содержимое этих элементов определяется приложением и не рассматривается спецификацией SOAP, хотя в дальнейшем будет немного сказано о том, как подобные элементы должны обрабатываться.

Заголовочный элемент SOAP не является обязательным, однако он был включен в пример для того, чтобы объяснить некоторые функции SOAP. Заголовок SOAP является расширением, предоставляющим способ передачи в SOAP-сообщениях информации, вообще говоря не являющейся полезной для приложения. Подобная "контрольная" информация включает, например, директивы прохождения сообщения или контекстную информацию, относящуюся к обработке сообщения. Это позволяет подстраивать SOAP-сообщения под каждое конкретное приложение. Следующие непосредственно за env:Header дочерние элементы называются заголовочными блоками. Они представляют логическую группировку данных, которые, как показано позже, могут быть индивидуально адресованы SOAP-узлам, встречаемым сообщением на пути от отправителя к конечному получателю.

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

Тело SOAP-сообщения является обязательным элементом внутри env:Envelope, содержащим основную информацию SOAP-сообщения, которая должна быть передана из начальной точки пути сообщения в конечную.

Графическое представление структуры SOAP-сообщения, приведенного в примере 1 выглядит так:

Figure 1: SOAP message structure

В примере 1, заголовок содержит два заголовочных блока, каждый из которых определен в собственном пространстве имен XML, и отражает некоторый аспект общей обработки тела SOAP-сообщения. Для приложения бронирования путешествия, подобная, принадлежащая к запросу в целом, "метаинформация" содержится в заголовочном блоке reservation, который представляет собой ссылку на этот экземпляр запроса, а также содержит его временную отметку. "Метаинформация", служащая для идентификации будущего путешественника, содержится в блоке passenger.

Заголовочные блоки reservation и passenger должны обрабатываться следующим SOAP-посредником, встреченным на пути сообщения, либо, в случае отсутствия узла-посредника, конечным получателем сообщения. На тот факт, что сообщение адресовано следующему SOAP-узлу, встреченному на пути сообщения, указывает присутствие атрибута env:role со значением "http://www.w3.org/2003/05/soap-envelope/role/next" (здесь и далее просто "next"). Этот атрибут реализует роль, исполнять которую обязаны все SOAP-узлы. Присутствие же атрибута env:mustUnderstand со значением "true" указывает на то, что узел (узлы), обрабатывающий заголовочные блоки, должен обрабатывать их в строгом соответствии с их спецификациями либо не обрабатывать SOAP-сообщение вовсе и выдать сообщение об ошибке. Необходимо отметить, что если заголовочный блок обрабатывается, ввиду ли присутствия env:mustUnderstand="true" либо по какой-либо другой причине, такой блок должен быть обработан в соответствии со спецификацией этого блока. Спецификации заголовочных блоков определяются конкретным приложением и не являются предметом рассмотрения SOAP. Подробное изложение обработки SOAP-сообщения в зависимости от значений вышеупомянутых атрибутов содержится в разделе 3.

Решение по поводу того, какие данные поместить в заголовочный блок и тело SOAP-сообщения, должно быть принято на этапе проектирования приложения. Необходимо помнить, что заголовочные блоки могут быть адресованы различным узлам, которые могут встречаться на пути сообщения от отправителя к конечному получателю. Подобные промежуточные SOAP-узлы могут предоставлять дополнительные услуги, используя данные, содержащиеся в этих заголовочных блоках. В примере 1, данные о пассажире помещены в заголовочный блок для того, чтобы проиллюстрировать их использование SOAP-посредником для выполнения некоторой дополнительной обработки. Например, как показано далее в разделе 5.1, уходящее сообщение изменяется SOAP-посредником путем добавления в качестве еще одного заголовочного блока политик совершения путешествия пассажиром.

Элемент env:Body и ассоциированные с ним дочерние элементы itinerary и lodging, вовлечены в обмен информацией между начальным отправителем SOAP-сообщения и SOAP-узлом на его пути, выступающим в роли конечного получателя SOAP-сообщения, которым является сервис продажи билетов. Поэтому элемент env:Body с его содержимым всецело адресован конечному получателю и должен быть им понят. Средства, посредством которых SOAP-узел может выполнять эту роль, не определяются спецификацией SOAP. Они определяются общей семантикой приложения и ассоциированного с ним потоком сообщений.

Необходимо отметить, что SOAP-посредник может играть роль конечного получателя для рассматриваемого сообщения и таким образом также может обрабатывать env:Body. Однако, хотя такой тип поведения и не может быть предугадан, это не означает, что обработка сообщения может производиться без должного внимания, поскольку в этом случае могут быть искажены первоначальные намерения отправителя сообщения. Это может иметь нежелательные побочные эффекты (такие как необработка заголовочных блоков, которые могут быть адресованы узлам-посредникам, находящимся далее на пути следования сообщения).

SOAP-сообщение, подобное представленному в примере 1, может быть передано посредством различных нижележащих протоколов и использоваться в различных шаблонах обмена сообщениями. Например, для web-доступа к сервису продажи билетов, оно может быть помещено в тело HTTP- запроса POST. В случае привязки к другому протоколу, оно может быть отправлено в email-сообщении (см. раздел 4.2). Раздел 4 далее опишет то, как SOAP-сообщения могут передаваться посредством различных нижележащих протоколов. Сейчас же предположим, что механизм для передачи сообщения уже существует, и в дальнейшей части этого раздела сконцентрируемся на деталях SOAP-сообщений и их обработки.

2.2 Обмен SOAP-сообщениями

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

Более широкий набор сценариев использования, которые укладываются в определение шаблона обмена сообщениями типа "запрос-отклик", может быть реализован просто с помощью XML-контента в SOAP-сообщениях при реализации двунаправленного "диалога", где семантика определяется отправляющим и получающим приложениями. Раздел 2.2.1 описывает случай, когда обмен XML-контентом в SOAP-сообщениях между приложением бронирования путешествия и сервисом продажи билетов осуществляется посредством шаблона диалогового обмена сообщениями, в то время как раздел 2.2.2 предлагает пример реализации обмена уже в виде вызовов удаленных процедур (RPC).

2.2.1 Диалоговый обмен сообщениями

Продолжая рассмотрение сценария бронирования путешествия, пример 2 демонстрирует SOAP-сообщение, полученное от сервиса продажи билетов в ответ на запрос о бронировании, реализованный сообщением примера 1. Этот отклик выделяет из запроса некоторую информацию, а именно выбор аэропорта в городе отправления.

Пример 2
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> 
 <env:Header>
  <m:reservation xmlns:m="http://travelcompany.example.org/reservation" 
      env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
           env:mustUnderstand="true">
   <m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
   <m:dateAndTime>2001-11-29T13:35:00.000-05:00</m:dateAndTime>
  </m:reservation>
  <n:passenger xmlns:n="http://mycompany.example.com/employees"
      env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
           env:mustUnderstand="true">
   <n:name>Еke Jуgvan Шyvind</n:name>
  </n:passenger>
 </env:Header>
 <env:Body>
  <p:itineraryClarification 
    xmlns:p="http://travelcompany.example.org/reservation/travel">
   <p:departure>
     <p:departing>
       <p:airportChoices>
          JFK LGA EWR 
       </p:airportChoices>
     </p:departing>
   </p:departure>
   <p:return>
     <p:arriving>
       <p:airportChoices>
         JFK LGA EWR 
       </p:airportChoices>
     </p:arriving>
   </p:return>  
  </p:itineraryClarification>
 </env:Body>
</env:Envelope>
SOAP-сообщение, отправленное в ответ на сообщение примера 1.

Как было описано ранее, элемент env:Body содержит основной контент сообщения, удовлетворяющий схеме описания в пространстве имен XML http://travelcompany.example.org/reservation/travel, который в этом примере включает в себя список различных вариантов аэропортов. В этом примере в качестве отклика возвращены заголовочные блоки примера 1 (с измененными значениями нескольких субэлементов). Это позволяет осуществлять корреляцию сообщений на SOAP-уровне, однако подобные заголовки имеют также и другие применения, определяемые спецификой приложения.

Обмен сообщениями в Примерах 1 и 2 является случаем, когда посредством SOAP-сообщений осуществляется обмен XML-контентом, удовлетворяющим некоторой определенной приложением схеме. Напомним, что обсуждение средств передачи сообщений содержится в разделе 4.

Однако легко видеть, как подобный обмен может быть построен с помощью двунаправленного "диалогового" шаблона обмена сообщениями. Пример 3 демонстрирует SOAP-сообщение, отправленное приложением бронирования путешествия в ответ на сообщение примера 2 и содержащее аэропорт, выбранный из списка доступных аэропортов. Заголовочный блок reservation с тем же значением субэлемента reference содержится в каждом сообщении этого диалога, тем самым предоставляя, в случае необходимости, возможность коррелировать сообщения на уровне приложения.

Пример 3
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> 
 <env:Header>
  <m:reservation 
     xmlns:m="http://travelcompany.example.org/reservation" 
      env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
           env:mustUnderstand="true">
    <m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
    <m:dateAndTime>2001-11-29T13:36:50.000-05:00</m:dateAndTime>
  </m:reservation>
  <n:passenger xmlns:n="http://mycompany.example.com/employees"
      env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
           env:mustUnderstand="true">
   <n:name>Еke Jуgvan Шyvind</n:name>
  </n:passenger>
 </env:Header>
 <env:Body>
  <p:itinerary 
   xmlns:p="http://travelcompany.example.org/reservation/travel">
   <p:departure>
     <p:departing>LGA</p:departing>
   </p:departure>
   <p:return>
     <p:arriving>EWR</p:arriving>
   </p:return>
  </p:itinerary>
 </env:Body>
</env:Envelope>
Отклик на сообщение примера 2, реализующий диалоговый обмен сообщениями.

2.2.2 Вызовы удаленных процедур

Одна из целей SOAP Версия 1.2 - инкапсулировать функциональность, реализуемую посредством вызовов удаленных процедур, используя широкие возможности применения и гибкость XML. Раздел 4 SOAP Часть 2 определяет унифицированное представление вызовов RPC и откликов на них посредством SOAP-сообщений. Этот раздел продолжает разбор сценария бронирования путешествия для иллюстрации использования SOAP-сообщений для вызова удаленных процедур и получения откликов на них.

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

Для вызова SOAP RPC требуется следующая информация:

  1. Адрес SOAP-узла места назначения;
  2. Имя процедуры либо метода;
  3. Наименования и значения всех аргументов, передаваемых процедуре или методу вместе с выходными параметрами и возвращаемым значением;
  4. Четкое разделение аргументов, используемых для идентификации web-ресурса, являющегося действительным местом назначения RPC, от аргументов, содержащих данные и контрольную информацию, используемых для обработки вызова ресурсом места назначения RPC.
  5. Определение шаблона обмена сообщениями, а также так называемого "Web-метода" (о нем будет рассказано несколько позже), которые будут использоваться для передачи RPC.
  6. Данные, которые могут быть переданы как часть заголовочных блоков SOAP. Эти данные не являются обязательными.

Вышеперечисленная информация может быть выражена посредством широкого набора средств, включая формальный Interface Definition Language (IDL, Язык Определения Интерфейсов). Необходимо заметить, что SOAP не предоставляет никаких средств IDL, ни формальных ни неформальных. Надо также отметить, что приведенная выше информация слегка отличается от информации, которая в общем случае необходима для вызова других RPC, не имеющих дела с SOAP.

Относительно пункта 1 приведенного выше списка можно сказать, что, с точки зрения SOAP, существует SOAP-узел, который "удерживает" или "поддерживает" пункт назначения RPC. Это SOAP-узел, играющий роль конечного SOAP-получателя. Как этого требует пункт 1, конечный получатель может идентифицировать пункт назначения поименованной процедуры либо метода по его URI. Каким образом пункт назначения становится доступен по URI - зависит от нижележащего протокола привязки. Одна из возможностей - URI, идентифицирующая пункт назначения, которая может быть включена в заголовочный SOAP-блок. Некоторые протокольные привязки, такие как, например, HTTP-привязка SOAP, определенная в [SOAP Часть 2], предлагают механизм передачи URI вне SOAP-сообщения. Говоря в общем, одним из вопросов, описываемых спецификацией протокольной привязки, должно быть описание способа передачи URI пункта назначения в контексте использования данной привязки. Раздел 4.1 дает несколько конкретных примеров того, как URI передается в случае стандартизованной протокольной HTTP-привязки SOAP.

Пункты 4 и 5 приведенного выше списка необходимы для гарантии того, что RPC-приложения, использующие SOAP, могут делать это (т. е. использовать SOAP) образом, совместимым с архитектурными принципами World Wide Web. В разделе 4.1.3 показывается, как можно использовать информацию пунктов 4 и 5.

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

Пример 4
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" >
 <env:Header>
   <t:transaction
           xmlns:t="http://thirdparty.example.org/transaction"
           env:encodingStyle="http://example.com/encoding"
           env:mustUnderstand="true" >5</t:transaction>
 </env:Header>  
 <env:Body>
  <m:chargeReservation 
      env:encodingStyle="http://www.w3.org/2003/05/soap-encoding"
         xmlns:m="http://travelcompany.example.org/">
   <m:reservation xmlns:m="http://travelcompany.example.org/reservation">
    <m:code>FT35ZBQ</m:code>
   </m:reservation>   
   <o:creditCard xmlns:o="http://mycompany.example.com/financial">
    <n:name xmlns:n="http://mycompany.example.com/employees">
           Еke Jуgvan Шyvind
    </n:name>     
    <o:number>123456789099999</o:number>
    <o:expiration>2005-02</o:expiration>
   </o:creditCard>
  </m:chargeReservation>
 </env:Body>
</env:Envelope>
SOAP-запрос RPC с обязательным заголовком и двумя входными параметрами.

RPC сам по себе переносится как дочерний элемент env:Body и реализован структурой struct , которой присваивается имя процедуры или метода, в данном случае chargeReservation. (Структура struct является понятием модели данных SOAP, определенным в [SOAP Часть 2], которая описывает тип структуры или записи, присутствующий в некоторых широко распространенных языках программирования). Конструкция RPC в примере (чье формальное описание подробно не приводится) имеет на входе два параметра: reservation, соответствующий планируемому путешествию, определяемому посредством кода брони code, и информацию о кредитной карточке creditCard. Дальнейший фрагмент кода также является структурой struct, которая включает три элемента: имя держателя кредитной карточки name, номер кредитной карточки number и дату истечения срока действия кредитной карточки expiration.

В этом примере атрибут env:encodingStyle со значением http://www.w3.org/2003/05/soap-encoding показывает, что содержимое структуры chargeReservation было сериализовано согласно правилам написания кода SOAP - специальным правилам, определенным в SOAP Часть 2 Раздел 3. Хотя SOAP и определяет эту схему написания кода, необязательно использовать именно ее. Из спецификации ясно, что для описания данных, специфичных для конкретного приложения, внутри SOAP-сообщения могут быть использованы другие схемы написания кода. Для упоминания о других схемах написания кода используется атрибут env:encodingStyle, уточняющий заголовочные блоки и субэлементы тела сообщения. Выбор значения этого атрибута зависит от конкретного приложения; способность вызывающего и вызываемого приложений взаимодействовать между собой предполагается установленной "out-of-band". Раздел 5.2 демонстрирует пример использования другой схемы написания кода.

Как было отмечено в пункте 6 вышеприведенного списка, при использовании RPC может также потребоваться передача дополнительной информации, которая может быть важна для обработки вызова в распределенной среде, но не является частью формального описания процедуры или метода. (Необходимо отметить, что предоставление такой дополнительной контекстной информации нехарактерно для RPC, но, вообще говоря, может потребоваться для обработки какими-либо распределенными приложениями.) В примере RPC передается в контексте всей транзакции, которая состоит из несколько процессов, каждый из которых должен успешно завершиться, прежде чем успешно завершится сам RPC. Пример 4 показывает как заголовочный блок transaction, адресованный конечному получателю (это предполагается отсутствием атрибута env:role), используется для передачи подобной информации. (Значение "5" в некоторых идентификаторах транзакции является отвлеченным и имеет смысл только для приложения. Здесь нет необходимости в дальнейшем обсуждении семантики заголовка примера 4, специфичной для конкретного приложения, так как это не является предметом дискуссии о синтаксических аспектах SOAP-сообщений RPC.)

Предположим, что RPC в примере осуществления платежа был спроектирован с целью включения описания процедуры, которое указывает на наличие двух параметров на выходе: один представляет собой код ссылки брони, а другой - URL, по которой могут быть получены детали, касающиеся осуществленной брони. Отклик RPC возвращается в элементе SOAP-сообщения env:Body, который реализован как структура struct, состоящая из имени процедуры chargeReservation и добавляемого, как правило, слова "Response". Двумя параметрами на выходе, сопровождающими отклик RPC, являются: буквенно-цифровой код брони code, и viewAt, - URI местоположения брони.

Это показано в примере 5a, где заголовок идентифицирует транзакцию, в рамках которой этот RPC выполняется.

Пример 5a
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" >
 <env:Header>
     <t:transaction
        xmlns:t="http://thirdparty.example.org/transaction"
          env:encodingStyle="http://example.com/encoding"
           env:mustUnderstand="true">5</t:transaction>
 </env:Header>  
 <env:Body>
     <m:chargeReservationResponse 
         env:encodingStyle="http://www.w3.org/2003/05/soap-encoding"
             xmlns:m="http://travelcompany.example.org/">
       <m:code>FT35ZBQ</m:code>
       <m:viewAt>
         http://travelcompany.example.org/reservations?code=FT35ZBQ
       </m:viewAt>
     </m:chargeReservationResponse>
 </env:Body>
</env:Envelope>
Отклик RPC с двумя параметрами на выходе для RPC, показанного в примере 4

RPC часто имеют описания, в которых какой-либо один параметр на выходе отличен от других - это так называемое "возвращаемое" значение.Соглашение об обозначениях SOAP RPC предоставляет способ, позволяющий отличать это "возвращаемое" значение в описании процедуры от других параметров на выходе. Чтобы продемонстрировать это, пример осуществления платежа изменен так, что описание процедуры, аналогичное описанию процедуры в примере 5a, имеющее те же два параметра на выходе, дополнено "возвращаемым" значением, которое представляет собой список с двумя возможными значениями "confirmed" и "pending". RPC, удовлетворяющий этому описанию, показан в примере 5b, где, как и ранее, SOAP-заголовок идентифицирует транзакцию, выполняемую этим RPC.

Пример 5b
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" >
 <env:Header>
    <t:transaction
       xmlns:t="http://thirdparty.example.org/transaction"
         env:encodingStyle="http://example.com/encoding"
          env:mustUnderstand="true">5</t:transaction>
 </env:Header>  
 <env:Body>
    <m:chargeReservationResponse 
       env:encodingStyle="http://www.w3.org/2003/05/soap-encoding"
           xmlns:rpc="http://www.w3.org/2003/05/soap-rpc"
             xmlns:m="http://travelcompany.example.org/">
       <rpc:result>m:status</rpc:result>
       <m:status>confirmed</m:status>
       <m:code>FT35ZBQ</m:code>
       <m:viewAt>
        http://travelcompany.example.org/reservations?code=FT35ZBQ
       </m:viewAt>
    </m:chargeReservationResponse>
 </env:Body>
</env:Envelope>
RPC с "возвращаемым" значением и двумя параметрами на выходе для RPC, приведенного в примере 4.

В примере 5b возвращаемое значение идентифицируется элементом rpc:result и содержит XML Qualified Name (принадлежащее типу xs:QName) другого элемента внутри структуры struct, которым является m:status. Он, в свою очередь, содержит действительное возвращаемое значение - "confirmed". Эта техника позволяет строго типизировать согласно некоторой схеме действительное возвращаемое значение. Если элемент rpc:result отсутствует, как в примере 5a, возвращаемое значение отсутствует либо принадлежит типу void.

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

В общем случае использования HTTP в качестве нижележащего протокола передачи, стандартизованном в SOAP Часть 2 Раздел 7, вызов RPC естественным образом мапируется на HTTP-запрос, а RPC-отклик мапируется на HTTP-отклик. Раздел 4.1 содержит примеры передачи RPC с использованием HTTP-привязки.

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

2.3 Сценарии обработки сообщений об ошибках

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

SOAP-элемент env:Body имеет также еще одну характерную роль - он может содержать информацию об ошибке. Модель обработки ошибок SOAP (см. SOAP Часть 1 Раздел 2.6) требует, чтобы все специфичные для SOAP и приложений ошибки были описаны с использованием единственного специального элемента env:Fault, содержащегося в элементе env:Body. Элемент env:Fault содержит два обязательных субэлемента, env:Code и env:Reason, и (необязательно) специфичную для приложения информацию в субэлементе env:Detail. Другой необязательный субэлемент env:Node посредством URI определяет SOAP-узел, сгенерировавший ошибку. Отсутствие этого субэлемента означает, что ошибка была сгенерирована конечным получателем сообщения. Существует также еще один необязательный субэлемент, env:Role, определяющий роль, исполняемую сгенерировавшим ошибку узлом.

Субэлемент env:Code элемента env:Fault сам по себе подобен обязательному субэлементу env:Value, назначение которого определено в спецификации SOAP (см. SOAP Часть 1 Раздел 5.4.6), также как и назначение необязательного субэлемента env:Subcode.

Пример 6a демонстрирует SOAP-сообщение, присланное в ответ на RPC примера 4, и указывающее на неудачное завершение обработки RPC.

Пример 6a
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
            xmlns:rpc='http://www.w3.org/2003/05/soap-rpc'>
  <env:Body>
   <env:Fault>
     <env:Code>
       <env:Value>env:Sender</env:Value>
       <env:Subcode>
        <env:Value>rpc:BadArguments</env:Value>
       </env:Subcode>
     </env:Code>
     <env:Reason>
      <env:Text xml:lang="en-US">Processing error</env:Text>
      <env:Text xml:lang="cs">Chyba zpracovбnн</env:Text>
     </env:Reason>
     <env:Detail>
      <e:myFaultDetails 
        xmlns:e="http://travelcompany.example.org/faults">
        <e:message>Name does not match card number</e:message>
        <e:errorcode>999</e:errorcode>
      </e:myFaultDetails>
     </env:Detail>
   </env:Fault>
 </env:Body>
</env:Envelope>
Пример SOAP-сообщения, указывающего на неудачное завершение обработки RPC примера 4

В примере 6a высокоуровневый элемент env:Value использует стандартизованное XML Qualified Name (принадлежащее типу xs:QName) для того, чтобы определить, что оно является ошибкой env:Sender, указывающей на то, что ошибка является синтаксической либо сообщение содержит некорректную информацию. (Когда ошибка env:Sender получена отправителем, предполагается, что будет сделано некоторое корректирующее действие, прежде чем аналогичное сообщение будет отправлено снова). Элемент env:Subcode не является обязательным, но если он присутствует, как в приведенном примере, он уточняет родительское значение. В примере 6a, элемент env:Subcode указывает на то, что специфичная ошибка RPC, rpc:BadArguments, определенная в SOAP Часть 2 Раздел 4.4, является причиной неудачного завершения обработки запроса.

Структура элемента env:Subcode была создана иерархической - каждый дочерний элемент env:Subcode имеет обязательный субэлемент env:Value и необязательный субэлемент env:Subcode - для передачи кода, специфичного для конкретного приложения. Эта иерархическая структура элемента env:Code реализует единый механизм передачи кодов ошибок нескольких уровней. Высокоуровневый элемент env:Value - основная ошибка, описанная в спецификациях SOAP Версия 1.2 (см. SOAP Часть 1 Раздел 5.4.6), она должна быть понятна всем SOAP-узлам. Вложенный элемент env:Value является специфичным для конкретного приложения и представляет собой дальнейшее развитие и улучшение описания вышеупомянутой основной ошибки с точки зрения приложения. Некоторые из этих значений могут быть хорошо стандартизованы SOAP (например коды RPC, стандартизованные в SOAP 1.2 (см. SOAP Часть 2 Раздел 4.4)) или в некоторых других стандартах, использующих SOAP в качестве инкапсулирующего протокола. Единственным требованием для определения подобных специфичных для приложения значений субкодов является их соответствие пространству имен при использовании любого пространства имен отличного от пространства имен SOAP env, определяющего основную классификацию SOAP-ошибок. Со стороны SOAP не существует требований о том, что приложения должны понимать или хотя бы просматривать все уровни значений субкодов.

Субэлемент env:Reason не важен для алгоритмической обработки. Он нужен скорее для лучшего понимания ситуации человеком, и хотя это обязательный элемент, его возможные значения не нуждаются в стандартизации. Все, что необходимо - достаточно точно описать ситуацию, в которой возникла ошибка. Субэлемент env:Text, иметь один или несколько субэлементов xml:lang позволяющий приложениям выдавать сообщения о причинах ошибки на различных языках. (Приложения могут согласовывать конкретный язык текста ошибки посредством встроенного механизма, использующего SOAP-заголовки, однако это находится вне рассмотрения спецификации SOAP.)

Отсутствие субэлемента env:Node внутри env:Fault в примере 6a говорит о том, что сообщение было создано конечным получателем вызова. Содержимое env:Detail, как показано в примере, специфично для конкретного приложения.

Ошибка может быть также сгенерирована во время обработки SOAP-сообщения, если обязательный заголовочный элемент не был понят, либо информация, содержащаяся в нем, не может быть обработана. Ошибки в ходе обработки заголовочного блока могут быть также показаны с использованием элемента env:Fault внутри элемента env:Body, но со специальным заголовочным блоком - env:NotUnderstood, который идентифицирует вызывающий ошибку заголовочный блок.

Пример 6b демонстрирует пример отклика на RPC примера 4, показывающий неудачное завершение обработки заголовочного блока t:transaction. Необходимо отметить присутствие кода ошибки env:MustUnderstand в env:Body, а также идентификацию заголовка, который не был понят с помощью (неприспособленного для этого) атрибута qname в специальном (пустом) заголовочном блоке env:NotUnderstood.

Пример 6b
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope>
 <env:Header>
    <env:NotUnderstood qname="t:transaction"
               xmlns:t="http://thirdparty.example.org/transaction"/>
 </env:Header>  
 <env:Body>
  <env:Fault>
   <env:Code>
    <env:Value>env:MustUnderstand</env:Value>
   </env:Code>
   <env:Reason>
      <env:Text xml:lang="en-US">Header not understood</env:Text>
      <env:Text xml:lang="fr">En-tкte non compris</env:Text>
   </env:Reason>    
  </env:Fault>
 </env:Body>
</env:Envelope>
Пример SOAP-сообщения, показывающего неудачное завершение обработки заголовочного блока примера 4

Если не были поняты несколько обязательных заголовочных блоков, тогда каждый из них может быть определен своим атрибутом qname в сериях таких заголовочных блоков env:NotUnderstood.

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

После того как были установлены различные синтаксические аспекты SOAP-сообщения наряду с некоторыми простыми шаблонами обмена сообщениями, в этом разделе дается общий обзор модели обработки SOAP (определенной в SOAP Часть 1 Раздел 2). Модель обработки SOAP описывает действия SOAP-узла при получении SOAP-сообщения.

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

Пример 7a
<?xml version="1.0" ?>
 <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
   <env:Header>
     <p:oneBlock xmlns:p="http://example.com" 
            env:role="http://example.com/Log">
     ...
     ...
     </p:oneBlock>
     <q:anotherBlock xmlns:q="http://example.com"
       env:role="http://www.w3.org/2003/05/soap-envelope/role/next">
     ...
     ...
     </q:anotherBlock>
     <r:aThirdBlock xmlns:r="http://example.com">
     ...
     ...
     </r:aThirdBlock>
   </env:Header>
   <env:Body >
     ...
     ...
   </env:Body>
 </env:Envelope>
SOAP-сообщение, показывающее многообразие заголовочных блоков.

Модель обработки SOAP описывает (логические) действия, предпринимаемые SOAP-узлом при получении SOAP-сообщения. От узла требуется проанализировать SOAP-составляющие сообщения, а именно те элементы, которые находятся в пространстве имен SOAP "env". Такие элементы являются оболочками сами для себя - они имеют и заголовок и тело. Первым шагом, конечно, является общая проверка синтаксической правильности SOAP-сообщения. То есть проверки того, что оно соответствует информационному множеству XML SOAP при условии соблюдения ограничений использования определенных XML-конструкций - Инструкций Обработки и Определений Типов Документа - как это определено в SOAP Часть 1, Раздел 5.

3.1 Атрибут "role"

Дальнейшая обработка заголовочных блоков и тела зависит от роли (ролей), исполняемой SOAP-узлом при обработке данного сообщения. SOAP определяет (необязательный) атрибут заголовочного блока env:role - синтаксически xs:anyURI - идентифицирующий роль, которую исполняет предполагаемый пункт назначения этого заголовочного блока. SOAP-узел нужен для обработки заголовочного блока, если он исполняет роль, идентифицируемую URI. То, каким образом SOAP-узел исполняет некоторую определенную роль, не является предметом рассмотрения спецификации SOAP.

Определены три стандартизованные роли (см. SOAP Часть 1 Раздел 2.2):

В примере 7a заголовочный блок oneBlock адресован любому SOAP-узлу, играющему определенную приложением роль, определяемую URI http://example.com/Log. Для целей иллюстрации предполагается, что спецификация этого заголовочного блока требует от любого SOAP-узла, играющего эту роль, протоколировать сообщение полностью.

Каждый SOAP-узел, получающий сообщение с заголовочным блоком, имеющим атрибут env:role "next", должен быть в состоянии обработать содержимое элемента, так как это стандартизованная роль, которую каждый SOAP-узел обязан исполнять. Заголовочный блок, имеющий этот атрибут, ожидает рассмотрения и (возможно) будет обработан следующим SOAP-узлом на пути сообщения. (Предполагается, что такой заголовок не был удален в результате обработки каким-либо предшествующим узлом.)

В примере 7a заголовочный блок anotherBlock адресован следующему узлу на пути сообщения. В этом случае, SOAP-сообщение, получено узлом, играющим определенную приложением роль "http://example.com/Log", и этот узел должен быть также способен исполнять определенную SOAP роль "next". Сказанное справедливо и для узла-конечного получателя сообщения, так как он, очевидно (и полностью), также исполняет роль "next" в силу того, что является следующим на пути сообщения.

Третий заголовочный блок в примере 7а, aThirdBlock, не имеет атрибута env:role. Он адресован SOAP-узлу, исполняющему роль "ultimateReceiver". Роль "ultimateReceiver" (эта роль может быть объявлена явно или подразумеваться, если в заголовочном блоке атрибут env:role отсутствует) исполняется SOAP-узлом, являющимся конечным получателем SOAP-сообщения. Отсутствие атрибута env:role в заголовочном блоке aThirdBlock означает, что этот заголовочный блок адресован SOAP-узлу, исполняющего роль "ultimateReceiver".

Необходимо отметить, что элемент env:Body не имеет атрибута env:role. Элемент тела сообщения всегда адресован SOAP-узлу, исполняющему роль "ultimateReceiver". В этом смысле элемент тела сообщения, как и заголовочный блок, адресован конечному получателю, но отличен от него тем, что проходит сквозь SOAP-узлы (как правило, SOAP-посредники) неизмененным, если они исполняют роль иную, нежели роль конечного получателя. SOAP не устанавливает какой-либо структуры элемента env:Body. Существует лишь рекомендация, что любой субэлемент должен удовлетворять пространству имен XML. Некоторые приложения, например, в примере 1, могут выбирать каким образом организовывать субэлементы env:Body в блоки, однако этот вопрос не имеет отношения к модели обработки SOAP.

Другая отличительная роль элемента env:Body, - роль контейнера, куда помещается информация о SOAP-специфичных ошибках, т. е. об ошибках, возникающих в случае неудачного завершения обработки элементов SOAP-сообщения - была описана ранее в разделе 2.3.

Если заголовочный элемент имеет стандартизованный атрибут env:role со значением "none", ни один SOAP-узел не должен обрабатывать содержимое этого элемента, хотя может его просматривать, если это данные, ссылающиеся на другой заголовочный элемент, адресованный определенному SOAP-узлу.

Если атрибут env:role имеет пустое значение, т. е. env:role="", это означает, что соответствующий идентифицирующий роль URI является исходным для SOAP-сообщения. SOAP Версия 1.2 не определяет исходный URI SOAP-сообщения, однако ссылается на механизмы получения исходного URI, определенные в [XMLBase] которые могут быть использованы для работы с любыми относительными URI как с абсолютными. Подобный механизм существует для протокольной привязки с целью определения исходного URI по ссылке на протокол, инкапсулирующий SOAP-сообщение для передачи. (В случае передачи SOAP-сообщений с помощью HTTP, SOAP Часть 2 Раздел 7.1.2 dопределяет исходный URI как URI-запрос HTTP-запроса либо как значение заголовка HTTP Content-Location.)

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

Роль отсутствует "none" "next" "ultimateReceiver"
Узел        
отправитель неприменима неприменима неприменима неприменима
посредник нет нет да нет
конечный получатель да нет да да

3.2 Атрибут "mustUnderstand"

Пример 7b дополняет предыдущий пример, вводя другой (необязательный) атрибут заголовочных блоков - атрибут env:mustUnderstand.

Пример 7b
<?xml version="1.0" ?>
 <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
   <env:Header>
     <p:oneBlock xmlns:p="http://example.com" 
           env:role="http://example.com/Log" 
               env:mustUnderstand="true">
     ...
     ...
     </p:oneBlock>
     <q:anotherBlock xmlns:q="http://example.com"
       env:role="http://www.w3.org/2003/05/soap-envelope/role/next">
     ...
     ...
     </q:anotherBlock>
     <r:aThirdBlock xmlns:r="http://example.com">
     ...
     ...
     </r:aThirdBlock>
   </env:Header>
   <env:Body >
     ...
     ...
   </env:Body>
 </env:Envelope>
SOAP-сообщение, демонстрирующее многообразие заголовочных блоков, один из которых обязателен для обработки

После того, как SOAP-узел с помощью атрибута env:role верно идентифицирует все адресованные ему заголовочные блоки (и, возможно, также тело сообщения), дальнейшие действия по обработке, которые должны быть предприняты, определяются дополнительным атрибутом env:mustUnderstand в заголовочных элементах. Этот необязательный атрибут может включаться в заголовочные блоки SOAP-сообщения для обеспечения уверенности в том, что SOAP-узлы не проигнорируют важные для приложения в целом заголовочные блоки. Если атрибут env:mustUnderstand имеет значение "true", это означает, что SOAP-узел, которому адресовано сообщение, должен обработать блок согласно спецификации этого блока. Фактически обработка SOAP-сообщения даже не должна начинаться, пока узел не идентифицирует и не "поймет" все обязательные блоки, адресованные ему. Под "пониманием" заголовка подразумевается, что узел готов производить действия, описанные в спецификации этого блока. (Спецификации заголовочных блоков не являются предметом рассмотрения спецификации SOAP.)

В примере 7b заголовочный блок oneBlock содержит env:mustUnderstand, с установленным значением "true". Это означает, что блок oneBlock является обязательным для обработки, если SOAP-узел исполняет роль, определенную "http://example.com/Log". Два других заголовочных блока не имеют атрибута env:mustUnderstand, и поэтому SOAP-узел, которому эти блоки адресованы, может их не обрабатывать. (Здесь предполагается, что спецификации блоков позволяют это.)

Значение "true" атрибута env:mustUnderstand означает, что SOAP-узел должен либо обработать заголовок в соответствии с семантикой, описанной в спецификации этого заголовка, либо сгенерировать SOAP-ошибку обработки. Обработка заголовка может включать в себя удаление заголовка из любого SOAP-сообщения, повторное помещение заголовка с тем же либо измененным значением или помещение нового заголовка. Невозможность обработки обязательного заголовка влечет прекращение дальнейшей обработки SOAP-сообщения и генерацию SOAP-ошибки. При этом сообщение дальше не передается.

Элемент env:Body не имеет атрибута env:mustUnderstand , однако должен быть обработан конечным получателем. В примере 7b конечный получатель сообщения - SOAP-узел, исполняющий роль "ultimateReceiver" - должен обработать env:Body и может обработать заголовочный блок aThirdBlock. Он также может обработать заголовочный блок anotherBlock, так как этот блок адресован конечному получателю сообщения (в рамках роли "next"), но не обязан делать это, если спецификации обработки блоков не требуют этого. (Для того, чтобы блок anotherBlock был обработан следующим получателем необходимо, чтобы его спецификация содержала env:mustUnderstand="true".)

Роль (роли), которые SOAP-узлы исполняют во время обработки SOAP-сообщения, могут определяться многими факторами. Роль может быть известна априори (т. е. заранее) либо может быть установлена некоторыми вспомогательными средствами. Узел также может просмотреть все составляющие полученного сообщения перед его обработкой для определения роли, которую он будет исполнять. Интересная ситуация может возникать, когда SOAP-узел во время обработки сообщения выясняет, что он должен исполнять еще и некоторые дополнительные роли. Не имеет значения, в какой момент это происходит, внешне должно казаться, будто узел продолжает свои действия согласно модели обработки. Все должно выглядеть так, будто эти дополнительные роли были известны узлу с самого начала обработки сообщения. Внешним проявлением такого поведения узла должна быть проверка env:mustUnderstand всех заголовков, могущих содержать дополнительные роли, выполненная перед началом какой-либо обработки сообщения. В случае, если SOAP-узел берется исполнять эти дополнительные роли, необходимо быть уверенным, что он готов делать все необходимое согласно спецификациям этих ролей.

Приведенная ниже таблица показывает то, как различные действия по обработке заголовочного блока узлом, которому он был адресован (посредством атрибута env:role), определяются атрибутом env:mustUnderstand.

Узел посредник конечный получатель
mustUnderstand    
"true" должен обработать должен обработать
"false" может обработать может обработать
отсутствует может обработать может обработать

В качестве результата обработки SOAP-сообщения, SOAP-узел может сгенерировать одну единственную SOAP-ошибку, если обработка сообщения завершилась неудачно либо, в зависимости от приложения, сгенерировать дополнительные SOAP-сообщения для отправки другим SOAP-узлам. SOAP Часть 1 Раздел 5.4 описывает структуру сообщения об ошибке в то время как модель обработки SOAP определяет условия, при выполнении которых оно генерируется. Как было показано ранее в разделе 2.3, SOAP-ошибка это SOAP-сообщение со стандартизованным субэлементом env:Body имеющим название env:Fault.

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

3.3 Атрибут "relay"

SOAP Версия 1.2 определяет еще один необязательный атрибут для заголовочных блоков - env:relay , принадлежащий типу xs:boolean, который показывает, что заголовочный блок, адресованный SOAP-посреднику, должен быть передан дальше, если он не был обработан.

Необходимо отметить, что если заголовочный блок обработан, правила обработки SOAP (см. SOAP Часть 1 Раздел 2.7.2) требуют, чтобы он был удален из уходящего сообщения. (Он может, однако, быть вставлен заново, с неизмененным либо измененным содержимым, если в результате обработки других заголовочных блоков стало ясно, что заголовочный блок должен быть оставлен в передаваемом сообщении.) По умолчанию, необработанный заголовочный блок, предназначенный роли, которую исполняет SOAP-посредником, должен быть удален перед отправкой сообщения.

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

Однако бывают случаи, когда проектировщик приложений хотел бы ввести новую функцию, объявляемую с помощью заголовочного блока SOAP, адресованного любому посреднику, который может быть встречен на пути SOAP-сообщения. Подобный заголовочный блок может быть полезен тем посредникам, которые "поймут" его, но будет проигнорирован и передан дальше теми, которые его не "поймут". По крайней мере, на некоторых начальных SOAP-узлах на пути сообщения может быть установлено соответствующее программное обеспечение для обработки заголовочного блока с новой функцией, однако оно может оказаться не на всех узлах. Поэтому включение в такой заголовочный блок атрибута env:mustUnderstand = "false" необходимо для того, чтобы посредники, не имеющие средств обработки подобного заголовочного блока, не генерировали ошибку. Включение в заголовочный блок дополнительного атрибута env:relay со значением "true", позволяет посреднику передать адресованный ему заголовочный блок дальше в том случае, если он не может его обработать.

Адресация заголовочного блока роли "next" наряду с атрибутом env:relay , имеющим значение "true", всегда может служить гарантией того, что каждый посредник имеет возможность просмотреть заголовок, потому что одним из возможных вариантов использования роли "next" является передача посредством заголовочных блоков информации, которая должна быть сохранена неизменной на всем пути SOAP-сообщения. Конечно, проектировщик приложения всегда может определить свою роль, позволяющую адресацию заголовочных блоков специальным посредникам, готовым эту роль исполнять. Вследствие этого, ограничений на использование атрибута env:relay совместно с любой ролью не накладывается (конечно, кроме ролей "none" и "ultimateReceiver", для которых этот атрибут не имеет смысла).

Пример 7c демонстрирует использование атрибута env:relay.

Пример 7c
<?xml version="1.0" ?>
 <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
   <env:Header>
     <p:oneBlock xmlns:p="http://example.com" 
           env:role="http://example.com/Log" 
               env:mustUnderstand="true">
     ...
     ...
     </p:oneBlock>
     <q:anotherBlock xmlns:q="http://example.com"
       env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
       env:relay="true">
     ...
     ...
     </q:anotherBlock>
     <r:aThirdBlock xmlns:r="http://example.com">
     ...
     ...
     </r:aThirdBlock>
   </env:Header>
   <env:Body >
     ...
     ...
   </env:Body>
 </env:Envelope>
SOAP-сообщение, показывающее разнообразие заголовочных блоков, один из которых должен быть передан будучи не обработанным

Заголовочный блок q:anotherBlock, адресованный "следующему" узлу "next" на пути сообщения, имеет дополнительный атрибут env:relay="true". SOAP-узел, который получает это сообщение, сможет обработать этот заголовочный блок, если "поймет" его. Если узел обработает заголовочный блок q:anotherBlock , правила обработки требуют, чтобы этот заголовочный блок был удален из сообщения до его отправления дальше. В то же время, если SOAP-узел проигнорирует q:anotherBlock (что он вполне может сделать, так как этот заголовочный блок не является обязательным для обработки вследствие отсутствия атрибута env:mustUnderstand), в этом случае он должен отправить его дальше по пути следования сообщения.

Обработка заголовочного блока p:oneBlock является обязательной и правила обработки SOAP требуют, чтобы он не отправлялся дальше, пока результаты обработки какого-либо другого заголовочного блока требуют его присутствия в уходящем сообщении. Заголовочный блок r:aThirdBlock не имеет атрибута env:relay, что эквивалентно присутствию этого атрибута со значением env:relay="false". Следовательно, этот заголовок не передается дальше до тех пор, пока не будет обработан.

SOAP 1.2 Часть 1 Таблица 3 сводит воедино условия, определяющие когда SOAP-посреднику, исполняющему заданную роль, разрешается передавать необработанные заголовочные блоки дальше.

4. Использование различных протокольных привязок

Обмен SOAP-сообщениями может быть организован с помощью разнообразных "нижележащих" протоколов, включая протоколы уровня приложения. Спецификация метода передачи SOAP-сообщения от одного SOAP-узла другому с использованием нижележащего протокола называется привязкой протокола SOAP. [SOAP Часть 1] определяет SOAP-сообщение в форме информационного множества XML [XML Infoset], т. е. в терминах элементов и атрибутов информационных параграфов абстрактного "документа", называемого env:Envelope (см. SOAP Часть 1 Раздел 5). Любое представление информационного множества SOAP env:Envelope конкретизируется протокольной привязкой, одна из задач которой - дать сериализованное представление информационного множества, которое может быть передано следующему SOAP-узлу на пути сообщения таким образом, чтобы была возможность перестроить информационное множество без потери информации. В типичных примерах SOAP-сообщений и во всех примерах этого учебника продемонстрированная сериализация является корректно построенным XML-документом [XML 1.0]. Однако, могут быть и другие протокольные привязки - например протокольная привязка между двумя SOAP-узлами поверх интерфейса ограниченной пропускной способности - где также может быть выбрана альтернативная сжатая сериализация того же информационного множества. Другая привязка, выбранная для другой цели, может предоставлять сериализацию, являющуюся зашифрованной структурой и описывающей то же информационное множество.

В дополнение к предоставлению конкретной реализации информационного множества SOAP между смежными SOAP-узлами на пути SOAP-сообщения, протокольная привязка предоставляет механизмы поддержки функций, необходимых SOAP-приложению. Функция является частью спецификации определенной функциональности, предоставляемой привязкой. Описание функции идентифицируется посредством URI, так что все приложения, ссылающиеся на нее, гарантированно используют одну и ту же семантику. Например, типичный сценарий использования может потребовать реализации множества одновременно действующих обменов типа "запрос-отклик" между смежными SOAP-узлами, в этом случае необходима функция корреляции запроса и отклика. Среди других примеров - функция "шифрованного канала", функция "канала надежной доставки" или определенная функция шаблона обмена SOAP-сообщениями.

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

Например, если обмен SOAP-сообщениями происходит напрямую посредством протокола датаграмм UDP, очевидно, что функция, дающая возможность корреляции сообщений, должна быть где-либо реализована - либо непосредственно приложением, либо, что более вероятно, частью информационных множеств SOAP, участвующих в обмене. В последнем случае функция корреляции сообщений в рамках SOAP-оболочки имеет вид, специфичный для конкретной привязки, подобно заголовочному блоку SOAP, определенному в модуле "Корреляция типа запрос-отклик", который в свою очередь идентифицируется посредством URI. Однако, если обмен информационными множествами SOAP происходит с использованием нижележащего протокола, он, очевидно, принадлежит к типу "запрос/отклик". Поэтому приложение могло бы полностью унаследовать эту предоставляемую привязкой функцию, и в ее дальнейшей поддержке на уровне приложения либо на уровне SOAP не было бы необходимости. (Фактически, HTTP-привязка для SOAP имеет преимущество перед той же функцией HTTP.)

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

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

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

[SOAP Часть 2] также предлагает проектировщику приложений общую функцию, называемую Web-методом SOAP, которая позволяет приложениям полностью контролировать выбор так называемого "Web-метода" - одного из GET, POST, PUT, DELETE, чья семантика определена в спецификациях HTTP [HTTP 1.1]. Web-метод может использоваться поверх привязки. Эта функция гарантирует, что SOAP-приложения могут взаимодействовать поверх привязки образом, совместимым с архитектурными принципами World Wide Web. (Говоря кратко, простота и масштабируемость Web существует в значительной степени благодаря существованию множества "общеупотребительных" методов (GET, POST, PUT, DELETE), которые могут быть использованы для взаимодействия с любым ресурсом Web посредством URI.) Функция SOAP Web-метод поддерживается HTTP-привязкой SOAP, хотя, в принципе, она доступна и для всех других привязок SOAP к нижележащим протоколам.

SOAP Часть 2 Раздел 7 специфицирует одну стандартизованную протокольную привязку с помощью структуры привязки [SOAP Часть 1], определяющую как SOAP может быть использован совместно с HTTP в качестве нижележащего протокола. SOAP Версия 1.2 ограничивается определением HTTP-привязки, позволяющей использовать только метод POST в сочетании с шаблоном обмена сообщениями типа "запрос-отклик" и метод GET в сочетании с шаблоном обмена SOAP-сообщениями типа "отклик". В недалеком будущем другие спецификации смогут описать HTTP-привязку SOAP либо привязки к другим транспортным протоколам. Эти спецификации позволят использовать другие Web-методы (т. е. PUT, DELETE).

Следующие разделы демонстрируют примеры двух привязок SOAP к нижележащим протоколам, а именно к [HTTP 1.1] и email. Необходимо снова подчеркнуть, что существует только одна нормативная привязка SOAP 1.2 к HTTP [HTTP 1.1]. Примеры раздела 4.2, показывающие email в качестве транспортного механизма SOAP, тем не менее говорят о том, что для передачи SOAP-сообщений возможно использование и других транспортных протоколов, хотя они в настоящее время и не стандартизованы. Заметка W3C [E-mail-привязка SOAP] описывает реализацию структуры протокольной привязки [SOAP Часть 1] с помощью описания экспериментальной привязки SOAP к email-транспорту, в особенности [RFC 2822] - транспорта передачи сообщений.

4.1 HTTP-привязка SOAP

HTTP имеет хорошо известную модель взаимодействия и шаблон обмена сообщениями. Клиент идентифицирует сервер по URI, подсоединяется к нему с помощью TCP/IP сети, отсылает HTTP-сообщение-запрос и получает HTTP-сообщение-отклик по тому же TCP-соединению. HTTP полностью коррелирует сообщение-запрос и соответствующий ему сообщение-отклик, поэтому приложение, использующее эту привязку, может реализовать корреляцию между отправленным в теле HTTP-запроса SOAP-сообщением и SOAP-сообщением, возвращенным в качестве HTTP-отклика. Подобным образом, HTTP идентифицирует конечный сервер по URI, URI-запросу, который может также служить идентификатором SOAP-узла сервера.

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

HTTP-привязка [SOAP Часть 2] использует функцию SOAP Web-метода, позволяющую приложениям выбирать один из так называемых Web-методов - GET или POST - чтобы использовать для обмена сообщениями с помощью HTTP. Кроме того, она использует два шаблона обмена сообщениями, которые дают приложениям два способа обмена SOAP-сообщениями посредством HTTP: 1) использование HTTP-метода POST для передачи SOAP-сообщений в теле HTTP-запроса и HTTP-отклика, и 2) использование HTTP-метода GET в HTTP-запросе для возвращения SOAP-сообщения в теле HTTP-отклика. Первый шаблон использования является HTTP-реализацией функции привязки - шаблона обмена SOAP-сообщениями типа "запрос-отклик", второй - шаблона обмена SOAP-сообщениями типа "отклик".

Цель разработки этих двух способов - реализовать две парадигмы взаимодействия, одинаково хорошо подходящие для World Wide Web. Первый тип взаимодействия позволяет использовать данные в теле HTTP-метода POST для создания или изменения состояния ресурса, идентифицируемого по URI, в соответствии с которым направлен HTTP-запрос. Второй тип шаблона взаимодействия дает возможность использовать HTTP-запрос GET для получения представления о ресурсе без какого-либо изменения его состояния. В первом случае касающийся SOAP аспект вопроса состоит в том, что тело HTTP-запроса POST является SOAP-сообщением, которое кроме того, что должно быть обработано (согласно модели обработки SOAP) в соответствии со специфичной для приложения обработкой, должно также соответствовать семантике POST. Во втором случае типичной реализацией является получение представления запрашиваемого ресурса в виде SOAP-сообщения, а не в виде HTML- или XML-документа. То есть HTTP-заголовок типа содержимого сообщения идентифицирует это как медиа-тип "application/soap+xml". Вероятно, найдутся создатели Web-ресурсов, которые впоследствии обнаружат, что такие ресурсы проще всего найти и сделать доступными в виде SOAP-сообщений. Надо отметить, однако, что ресурсы могут быть доступны в виде различных представлений; желаемое или предпочтительное представление может быть получено путем опроса приложения с помощью HTTP-заголовка Accept.

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

Следующие подразделы демонстрируют примеры использования этих двух шаблонов обмена сообщениями, определенных для HTTP-привязки.

4.1.1 Использование в SOAP HTTP-метода GET

Использование HTTP-привязки совместно с шаблоном обмена SOAP-сообщениями типа "отклик" ограничивается HTTP-методом GET. Это означает, что откликом на HTTP-запрос GET запрашивающего SOAP-узла будет являться SOAP-сообщение в HTTP-отклике.

Пример 8a показывает HTTP-метод GET, направленный приложением путешественника (продолжая сценария бронирования путешествия) по URI http://travelcompany.example.org/reservations?code=FT35ZBQ , где можно увидеть маршрут путешествия. (Как эта URL стала доступна, можно увидеть в примере 5a.)

Пример 8a
GET /travelcompany.example.org/reservations?code=FT35ZBQ  HTTP/1.1
Host: travelcompany.example.org
Accept: text/html;q=0.5, application/soap+xml
HTTP-запрос GET

HTTP-заголовок Accept используется для индикации предпочитаемого представления запрашиваемого ресурса. В этом примере медиа-тип "application/soap+xml" более предпочтителен для интерпретации компьютером-клиентом, нежели медиа-тип "text/html" - для интерпретации браузером-клиентом человека.

Пример 8b показывает HTTP-отклик на запрос GET в примере 8a. Тело HTTP-отклика содержит SOAP-сообщение, показывающее детали путешествия. Обсуждение содержания SOAP-сообщения отложено до раздела 5.2, поскольку это не имеет отношения к пониманию использования метода GET HTTP-привязки.

Пример 8b
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> 
 <env:Header>
  <m:reservation xmlns:m="http://travelcompany.example.org/reservation" 
       env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
           env:mustUnderstand="true">
   <m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
   <m:dateAndTime>2001-11-30T16:25:00.000-05:00</m:dateAndTime>
  </m:reservation>
 </env:Header>
 <env:Body>
  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
            xmlns:x="http://travelcompany.example.org/vocab#"
     env:encodingStyle="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
   <x:ReservationRequest 
 rdf:about="http://travelcompany.example.org/reservations?code=FT35ZBQ">
      <x:passenger>Еke Jуgvan Шyvind</x:passenger>
      <x:outbound>
       <x:TravelRequest>
        <x:to>LAX</x:to>
        <x:from>LGA</x:from>
        <x:date>2001-12-14</x:date>
       </x:TravelRequest>
      </x:outbound>
      <x:return>
       <x:TravelRequest>
        <x:to>JFK</x:to>
        <x:from>LAX</x:from>
        <x:date>2001-12-20</x:date>
       </x:TravelRequest>
      </x:return>
    </x:ReservationRequest>
  </rdf:RDF>
 </env:Body>
</env:Envelope>
SOAP-сообщение, полученное в качестве отклика на HTTP-запрос GET примера 8a

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

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

4.1.2 Использование в SOAP HTTP-метода POST

Использование HTTP-привязки совместно с шаблоном обмена SOAP-сообщениями типа "запрос-отклик" ограничивается использованием HTTP-метода POST. Необходимо отметить, что использование этого шаблона обмена сообщениями в HTTP-привязке доступно всем приложениям, используют ли они обмен общими XML-данными или обмен RPC, инкапсулированными в SOAP-сообщения (как в следующих примерах).

Примеры 9 и 10 показывают пример HTTP-привязки, использующей шаблон обмена сообщениями типа "запрос-отклик" с тем же набором действий, что в, примере 4 и примере 5a, а именно передачу RPC и ее возврат в теле SOAP-сообщения соответственно. Примеры и содержание этого раздела сконцентрированы исключительно на HTTP-заголовках и их роли.

Пример 9
POST /Reservations HTTP/1.1
Host: travelcompany.example.org
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" >
 <env:Header>
   <t:transaction
           xmlns:t="http://thirdparty.example.org/transaction"
           env:encodingStyle="http://example.com/encoding"
           env:mustUnderstand="true" >5</t:transaction>
 </env:Header>  
 <env:Body>
  <m:chargeReservation 
     env:encodingStyle="http://www.w3.org/2003/05/soap-encoding"
          xmlns:m="http://travelcompany.example.org/">
   <m:reservation xmlns:m="http://travelcompany.example.org/reservation">
    <m:code>FT35ZBQ</m:code>
   </m:reservation>    
    <o:creditCard xmlns:o="http://mycompany.example.com/financial">
     <n:name xmlns:n="http://mycompany.example.com/employees">
           Еke Jуgvan Шyvind
     </n:name>    
     <o:number>123456789099999</o:number>
     <o:expiration>2005-02</o:expiration>
    </o:creditCard>
   </m:chargeReservation>
  </env:Body>
</env:Envelope>
RPC примера 4 , переданный посредством HTTP-запроса POST

Пример 9 демонстрирует RPC-запрос, направленный приложению путешествий. SOAP-сообщение отправляется в теле HTTP-метода POST по URI, идентифицирующего ресурс "Reservations" на сервере travelcompany.example.org. При использовании HTTP URI-запрос указывает на ресурс, которому был "отправлен" вызов. Кроме требования, что URI должен быть корректным, SOAP не накладывает больше никаких формальных ограничений на вид URI-запроса (см. [RFC 2396] для получения дополнительной информации по URI). Однако, одним из архитектурных принципов Web является требование, чтобы все важные ресурсы были идентифицированы URI. Данный факт позволяет предположить, что правильно построенные с точки зрения архитектуры Web SOAP-сервисы будут представлять собой ряд ресурсов, каждый со своим собственным URI. Действительно, многие подобные ресурсы, скорее всего, будут создаваться динамически во время работы сервиса, такого как, например, сервиса продажи билетов, показанного в примере. Так, правильно организованное с архитектурной точки зрения приложение продажи билетов должно иметь различные URI для каждой конкретной брони, и SOAP-запросы, предназначенные для получения или манипулирования этими бронями, будут направлены по их URI, а не по единому URI "Reservations", как это показано в примере 9. Пример 13 раздела 4.1.3 показывает предпочтительный способ обращения к ресурсам, таким как приложение бронирования путешествия. Поэтому отложим до раздела 4.1.3 дальнейшее обсуждение совместимого с архитектурными принципами Web использования SOAP/HTTP.

Если SOAP-сообщение помещается в тело HTTP-сообщения, необходимо выбрать "application/soap+xml" в качестве значения HTTP-заголовка Content-type. (Необязательный символьный параметр, показанный в вышеприведенном примере, может принимать значения "utf-8" или "utf-16", однако если он отсутствует, к телу HTTP-запроса применяются правила кодировки автономного XML-документа [XML 1.0].)

Пример 10 показывает отклик RPC (его детали опущены для краткости), отправленный приложением бронирования путешествий в соответствующем HTTP-отклике на запрос примера 5а. SOAP, используя HTTP-транспорт, полагается на семантику HTTP-кодов статуса для указания в HTTP информации о статусе. Например, серия кодов статуса 2xx показывает, что запрос клиента (включая SOAP-составляющую) был успешно получен, понят, акцептован и т. д.

Пример 10
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" >
 <env:Header>
       ...
       ...
 </env:Header>  
 <env:Body>
       ...
       ...
 </env:Body>
</env:Envelope>
Отклик на RPC примера 5а, вложенный в HTTP-отклик, показывающий успешное завершение

При возникновении ошибки обработки запроса, спецификация HTTP-привязки требует использования HTTP 500 "Internal Server Error" с вложенным SOAP-сообщением, содержащим SOAP-ошибку, указывающую ошибку обработки на стороне сервера.

Пример 11 являет собой то же сообщение об ошибке, что и пример 6а, однако на этот раз в него добавлены HTTP-заголовки.

Пример 11
HTTP/1.1 500 Internal Server Error
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
  <env:Body>
    <env:Fault>
     <env:Code>
       <env:Value>env:Sender</env:Value>
       <env:Subcode>
        <env:Value>rpc:BadArguments</env:Value>
       </env:Subcode>
     </env:Code>
     <env:Reason>
      <env:Text xml:lang="en-US">Processing error</env:Text>
      <env:Text xml:lang="cs">Chyba zpracovбnн</env:Text>
     </env:Reason>
     <env:Detail>
      <e:myFaultDetails 
        xmlns:e="http://travelcompany.example.org/faults" >
        <e:message>Name does not match card number</e:message>
        <e:errorcode>999</e:errorcode>
      </e:myFaultDetails>
     </env:Detail>
   </env:Fault>
 </env:Body>
</env:Envelope>
Пример SOAP-сообщения в HTTP-отклике, указывающего ошибку обработки SOAP-элемента Body примера 4

SOAP Часть 2 Таблица 16 дает детальное описание поведения при обработке различных возможных кодов HTTP-откликов, например, 2xx (успешный), 3xx (перенаправление), 4xx (ошибка на стороне клиента) и 5xx (ошибка на стороне сервера).

4.1.3 Использование SOAP в соответствии с архитектурными принципами Web

Одной из наиболее важных концепций World Wide Web является идентификация ресурса с помощью URI. SOAP-сервисы, которые используют HTTP-привязку и взаимодействуют с другим программным обеспечением Web, должны использовать URI для указания на ресурсы. Например, очень важным - несомненно, преобладающим - использованием World Wide Web является поиск информации, где доступ к ресурсу, идентифицированному с помощью URI, осуществляется при помощи HTTP-запроса GET без оказания какого-либо влияния на сам ресурс. (В терминах HTTP это называется безопасным и идемпотентным методом.) Ключевым моментом здесь является то, что владелец ресурса делает доступным его URI, который пользователи могут получить с помощью запроса GET.

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

Для подчеркивания необходимых изменений пример 12а показывает способ, который не рекомендуется для осуществления безопасного поиска информации в Web. Этот пример RPC, передаваемого SOAP-сообщением, снова использует тему бронирования путешествия, где запрос на получение маршрута конкретной брони идентифицирован одним из параметров RPC, reservationCode. (Для целей этой дискуссии предполагается, что приложение, использующее этот RPC запрос, не нуждается в функциях, требующих использования SOAP-заголовков.)

Пример 12a
POST /Reservations HTTP/1.1
Host: travelcompany.example.org
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" >
  <env:Body>
    <m:retrieveItinerary 
        env:encodingStyle="http://www.w3.org/2003/05/soap-encoding"
             xmlns:m="http://travelcompany.example.org/">
      <m:reservationCode>FT35ZBQ</m:reservationCode>
    </m:retrieveItinerary>
  </env:Body>
</env:Envelope>
Это представление не рекомендуется в случаях, когда осуществляется "безопасный" (т. е. не имеющий побочных эффектов) поиск информации

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

SOAP Часть 2 Раздел 4.1 дает рекомендации по реализации корректных с точки зрения архитектуры Web RPC, осуществляющих безопасный и идемпотентный поиск информации. Это делается посредством разделения аспектов метода и специфичных параметров в определении RPC, которое служит для идентификации нужных ресурсов среди других, осуществляющих иные функции. В примере 12а, запрашиваемый ресурс, идентифицирован с помощью двух признаков: первый из них является маршрутом (часть имени метода), второй же - ссылкой на специальный экземпляр (параметр метода). В подобных случаях рекомендуется идентифицирующие ресурс признаки указывать в идентифицирующем тот же ресурс HTTP URI-запросе. Например:

http://travelcompany.example.org/reservations/itinerary?reservationCode=FT35ZBQ.

Кроме того, если определение RPC таково, что все части его описания метода могут быть истолкованы как идентифицирующие ресурс, целевой узел RPC может быть идентифицирован полностью посредством URI. Если при этом пользователь ресурса может гарантировать, что поисковый запрос является безопасным, в этом случае SOAP Версия 1.2 рекомендует применять Web-метод GET, и шаблон обмена SOAP-сообщениями типа "отклик" используется как описано в разделе 4.1.1. Это гарантирует, что SOAP RPC реализован в соответствии с архитектурными принципами Web. Пример 12b показывает предпочтительный способ того, как запросить SOAP-узел с целью осуществления безопасного поиска ресурса.

Пример 12b
GET /Reservations/itinerary?reservationCode=FT35ZBQ  HTTP/1.1
Host: travelcompany.example.org
Accept: application/soap+xml
Выполненное в соответствии с архитектурными принципами Web альтернативное представление RPC примера 12а

Необходимо отметить, что SOAP Версия 1.2 не определяет какой-либо алгоритм идентификации URI по определению RPC, предназначенного сугубо для поиска информации.

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

Это также требует использования шаблона обмена SOAP-сообщениями типа "запрос-отклик", реализованного с помощью HTTP-метода POST, если описание RPC имеет данные (параметры), которые не идентифицируют ресурс. Даже в этом случае HTTP-метод POST с SOAP-сообщением может быть реализован в соответствии с архитектурными принципами Web. Как и в случае использования GET, [SOAP Часть 2] рекомендует в общем случае включать в HTTP URI-запрос все составляющие SOAP-сообщения, служащие для идентификации ресурса, которому был отправлен запрос POST. Эти же параметры, разумеется, могут быть включены и в SOAP-элемент env:Body . (Параметры должны включаться в параметр Body в случае использующего SOAP RPC, поскольку они относятся к описанию процедуры/метода, ожидаемого принимающим приложением.)

Пример 13 аналогичен примеру 9, за исключением того, что HTTP URI-запрос был изменен включением кода брони code, служащего для идентификации ресурса (бронь, которая должна быть подтверждена и оплачена)..

Пример 13
POST /Reservations?code=FT35ZBQ HTTP/1.1
Host: travelcompany.example.org
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn

<?xml version='1.0'?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" >
 <env:Header>
   <t:transaction
           xmlns:t="http://thirdparty.example.org/transaction"
           env:encodingStyle="http://example.com/encoding"
           env:mustUnderstand="true" >5</t:transaction>
 </env:Header>  
 <env:Body>
  <m:chargeReservation 
      env:encodingStyle="http://www.w3.org/2003/05/soap-encoding"
         xmlns:m="http://travelcompany.example.org/">
   <m:reservation xmlns:m="http://travelcompany.example.org/reservation">
    <m:code>FT35ZBQ</m:code>
   </m:reservation>   
   <o:creditCard xmlns:o="http://mycompany.example.com/financial">
    <n:name xmlns:n="http://mycompany.example.com/employees">
           Еke Jуgvan Шyvind
    </n:name>     
    <o:number>123456789099999</o:number>
    <o:expiration>2005-02</o:expiration>
   </o:creditCard>
  </m:chargeReservation>
 </env:Body>
</env:Envelope>
RPC примера 4, передаваемый в HTTP-запросе POST в соответствии с архитектурными принципами Web

В примере 13, ресурс, с которым будет осуществляться взаимодействие, идентифицирован посредством двух признаков: первый из них - то, что он является бронью (часть названия метода), а второй - специальный экземпляр брони (который является значением параметра code метода). Остальные параметры RPC, такие как номер кредитной карточки creditCard, не идентифицируют ресурс, но являются вспомогательными данными, которые должны быть обработаны ресурсом. [SOAP Часть 2] рекомендует, чтобы ресурсы, запрашиваемые посредством использующего SOAP RPC, по возможности, содержали в своем URI, идентифицирующем вызываемый RPC узел, любую подобную идентифицирующую ресурс информацию. Необходимо отметить, однако, что [SOAP Часть 2] не предлагает каких-либо алгоритмов реализации этого. Подобные алгоритмы могут быть созданы в будущем. Отметьте, однако, что все идентифицирующие ресурс элементы были сохранены, как и в примере 9, в SOAP-элементе env:Body.

Резюмируя, можно сказать: как видно из приведенных выше примеров, рекомендацией спецификаций SOAP является использование URI в соответствии c архитектурными принципами Web - то есть использование URI в качестве идентификаторов ресурсов. При этом неважно используется ли GET или POST.

4.2 Использование SOAP поверх Email

Разработчики приложений могут использовать также email-инфраструктуру для передачи SOAP-сообщений, причем как текст email-сообщений так и их вложения. Примеры, приведенные ниже, иллюстрируют такой метод передачи SOAP-сообщений, однако они не должны трактоваться как некие стандартные способы реализации этого метода. Спецификации SOAP Версия 1.2 не специфицируют подобную привязку. Хотя существует неофициальный W3C Note [E-mail-привязка SOAP], описывающий email-привязку для SOAP. Его основная цель - продемонстрировать применение общей Структуры Протокольной Привязки SOAP, описанной в [SOAP Часть 1].

Пример 14 показывает сообщение, реализующее запрос на бронирование путешествия из примера 1, передаваемый как email-сообщение между отправляющим и принимающим mail-агентами пользователя. (Подразумевается, что отправляющий узел также умеет интерпретировать SOAP и способен обрабатывать любые SOAP-ошибки, полученные в ответ на исходящее сообщение, а также коррелировать любые входящие ответные SOAP-сообщения).

Пример 14
From: a.oyvind@mycompany.example.com
To: reservations@travelcompany.example.org
Subject: Travel to LA
Date: Thu, 29 Nov 2001 13:20:00 EST
Message-Id: <EE492E16A090090276D208424960C0C@mycompany.example.com>
Content-Type: application/soap+xml 

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> 
 <env:Header>
  <m:reservation xmlns:m="http://travelcompany.example.org/reservation" 
      env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
         env:mustUnderstand="true">
   <m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</reference>
   <m:dateAndTime>2001-11-29T13:20:00.000-05:00</m:dateAndTime>
  </m:reservation>
  <n:passenger xmlns:n="http://mycompany.example.com/employees"
      env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
         env:mustUnderstand="true">
   <n:name>Еke Jуgvan Шyvind</n:name>
  </n:passenger>
 </env:Header>
 <env:Body>
  <p:itinerary 
     xmlns:p="http://travelcompany.example.org/reservation/travel">
   <p:departure>
     <p:departing>New York</p:departing>
     <p:arriving>Los Angeles</p:arriving>
     <p:departureDate>2001-12-14</p:departureDate>
     <p:departureTime>late afternoon</p:departureTime>
     <p:seatPreference>aisle</p:seatPreference>
   </p:departure>
   <p:return>
     <p:departing>Los Angeles</p:departing>
     <p:arriving>New York</p:arriving>
     <p:departureDate>2001-12-20</p:departureDate>
     <p:departureTime>mid morning</p:departureTime>
     <p:seatPreference/>
   </p:return>
  </p:itinerary>
  <q:lodging 
     xmlns:q="http://travelcompany.example.org/reservation/hotels">
   <q:preference>none</q:preference>
  </q:lodging>
 </env:Body>
</env:Envelope>
SOAP-сообщение примера 1, передаваемое в SMTP-сообщении

Заголовок в примере 14 реализован в стандартном для email-сообщений виде [RFC 2822].

Хотя email характеризуется односторонним обменом сообщениями и не гарантирует их доставку, транспортные протоколы, подобные Simple Mail Transport Protocol (SMTP) (SMTP) specification [SMTP], все же предоставляют механизм извещения о доставке, который, в случае с SMTP, называется Delivery Status Notification (DSN) и Message Disposition Notification (MDN). Извещения имеют вид email-сообщений, отправленных на email-адрес, указанный в заголовке email-сообщения. Приложения, так же как и email-пользователи, могут использовать эти механизмы для получения статуса передачи email-сообщения, однако эти извещения, будучи доставлены, являются сообщениями SMTP-уровня. Разработчик приложений должен хорошо понимать возможности и ограничения этих извещений о доставке, также как и риск того, что извещение может не быть сформировано в случае успешной доставки email-сообщения.

SMTP-сообщения статуса доставки являются иными, нежели сообщения, обрабатываемые на SOAP-уровне. SOAP-отклики на содержащиеся в email-сообщении SOAP-данные, получаемые в результате, будут возвращены с помощью email-сообщения, которое может содержать (а может и не содержать) SMTP-ссылку на оригинальное email-сообщение. Использование заголовка In-reply-to: [RFC 2822] может помочь в достижении корреляции на SMTP-уровне, но не обязательно позволит коррелировать сообщения на SOAP-уровне.

Пример 15 is продолжает сценарий примера 2 и демонстрирует SOAP-сообщение (детали тела сообщения для краткости опущены), отправленное приложением продажи билетов приложению бронирования путешествия, и проясняющее некоторые детали бронирования, кроме уже переданных email-сообщением. В этом примере Message-Id оригинального email-сообщения передан в дополнительном email-заголовке In-reply-to:, который коррелирует email-сообщения на SMTP-уровне, однако не позволяет корреляцию на SOAP-уровне. В этом примере приложение для корреляции SOAP-сообщений использует заголовочный блок reservation То, каким образом эта корреляция может быть реализована, зависит от конкретного приложения и не является предметом рассмотрения SOAP.

Пример 15
From: reservations@travelcompany.example.org
To: a.oyvind@mycompany.example.com
Subject: Which NY airport?
Date: Thu, 29 Nov 2001 13:35:11 EST
Message-Id: <200109251753.NAA10655@travelcompany.example.org>
In-reply-to:<EE492E16A090090276D208424960C0C@mycompany.example.com>
Content-Type: application/soap+xml

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> 
 <env:Header>
  <m:reservation xmlns:m="http://travelcompany.example.org/reservation" 
     env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
       env:mustUnderstand="true">
   <m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</reference>
   <m:dateAndTime>2001-11-29T13:35:00.000-05:00</m:dateAndTime>
  </m:reservation>
  <n:passenger xmlns:n="http://mycompany.example.com/employees"
      env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
        env:mustUnderstand="true">
   <n:name>Еke Jуgvan Шyvind</n:name>
  </n:passenger>
 </env:Header>
 <env:Body>
  <p:itinerary
     xmlns:p="http://travelcompany.example.org/reservation/travel">
   <p:itineraryClarifications>
      ...
      ...
   </p:itineraryClarifications>
  </p:itinerary>
 </env:Body>
</env:Envelope>
SOAP-сообщение из примера 2, переданное в email-сообщении с заголовком, кореллирующим его с предыдущим сообщением.

5. Более сложные сценарии использования

5.1 Использование SOAP-посредников

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

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

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

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

В следующем примере SOAP-узел, встреченный на пути сообщения между приложением бронирования путешествия и приложением продажи билетов, перехватывает сообщение, приведенное в примере 1. Примером такого SOAP-узла может служить узел протоколирования всех запросов на путешествия для их офлайнового рассмотрения в бюро путешествий. Необходимо отметить, что заголовочные блоки reservation и passenger в том примере применимы для узла (узлов), исполняющих роль "next", означающую, что блок адресован следующему SOAP-узлу на пути сообщения. Заголовочные блоки являются обязательными (атрибут mustUnderstand имеет значение "true"). Это означает, что узел должен знать, что ему необходимо делать (согласно внешней спецификации семантики заголовочных блоков). Спецификация протоколирования для таких заголовочных блоков может требовать, чтобы различные детали сообщения записывались на каждом узле, который получает такое сообщение, а также чтобы сообщение передавалось далее неизмененным. (Надо отметить, что спецификации заголовочных блоков должны требовать, чтобы в исходящее сообщение были вложены одни и те же заголовочные блоки, потому что в ином случае, модель обработки SOAP будет требовать их удаления.) В этом случае SOAP-узел действует как передающий посредник.

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

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

Пример 16
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> 
 <env:Header>
  <m:reservation xmlns:m="http://travelcompany.example.org/reservation" 
     env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
        env:mustUnderstand="true">
   <m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</reference>
   <m:dateAndTime>2001-11-29T13:20:00.000-05:00</m:dateAndTime>
  </m:reservation>
  <n:passenger xmlns:n="http://mycompany.example.com/employees"
     env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
       env:mustUnderstand="true">
   <n:name>Еke Jуgvan Шyvind</n:name>
  </n:passenger>
  <z:travelPolicy 
    xmlns:z="http://mycompany.example.com/policies" 
      env:mustUnderstand="true">
   <z:class>economy</z:class>
   <z:fareBasis>non-refundable<z:fareBasis>
   <z:exceptions>none</z:exceptions>
  </z:travelPolicy>
 </env:Header>
 <env:Body>
  <p:itinerary 
    xmlns:p="http://travelcompany.example.org/reservation/travel">
   <p:departure>
     <p:departing>New York</p:departing>
     <p:arriving>Los Angeles</p:arriving>
     <p:departureDate>2001-12-14</p:departureDate>
     <p:departureTime>late afternoon</p:departureTime>
     <p:seatPreference>aisle</p:seatPreference>
   </p:departure>
   <p:return>
     <p:departing>Los Angeles</p:departing>
     <p:arriving>New York</p:arriving>
     <p:departureDate>2001-12-20</p:departureDate>
     <p:departureTime>mid morning</p:departureTime>
     <p:seatPreference/>
   </p:return>
  </p:itinerary>
  <q:lodging 
    xmlns:q="http://travelcompany.example.org/reservation/hotels">
   <q:preference>none</q:preference>
  </q:lodging>
 </env:Body>
</env:Envelope>
Вид SOAP-сообщения примера 1 после того, как активный посредник вложил в него обязательный заголовок, предназначенный для конечного получателя сообщения

5.2 Использование других схем написания кода

Хотя SOAP Версия 1.2 и определяет некую схему написания кода (см. SOAP Часть 2 Раздел 3), ее использование необязательно. Из спецификации становится ясно, что для специфичных данных конкретного приложения внутри SOAP-сообщения могут использоваться и другие схемы написания кода. Для этой цели спецификация описывает атрибут env:encodingStyle, принадлежащий типу xs:anyURI, Этот атрибут служит для определения заголовочных блоков, любых дочерних элементов SOAP-элемента env:Body, и любых дочерних элементов элемента env:Detail, а также производных от них элементов. Он указывает схему сериализации вложенного содержимого или, по меньшей мере, схему сериализации для одного элемента, которой необходимо придерживаться, пока не будет встречен другой элемент, указывающий на необходимость применения другого стиля написания кода для его содержимого. Выбор значения для атрибута env:encodingStyle определяется конкретным приложением. Возможность взаимодействия предполагает установку атрибута "out-of-band". Если атрибут env:encodingStyle отсутствует, никаких предположений об используемой схеме написания кода не делается.

Использование альтернативной схемы написания кода проиллюстрировано в примере 17. Продолжая тему бронирования путешествия, этот пример показывает SOAP-сообщение, содержащее детали предстоящего путешествия. Оно было отправлено пассажиру приложением продажи билетов после того, как бронь была подтверждена. (То же сообщение было использовано в другом контексте в примере 8b.)

Пример 17
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> 
 <env:Header>
  <m:reservation xmlns:m="http://travelcompany.example.org/reservation" 
     env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
        env:mustUnderstand="true">
   <m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
   <m:dateAndTime>2001-11-30T16:25:00.000-05:00</m:dateAndTime>
  </m:reservation>
 </env:Header>
 <env:Body>
  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
            xmlns:x="http://travelcompany.example.org/vocab#"
    env:encodingStyle="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
   <x:ReservationRequest 
 rdf:about="http://travelcompany.example.org/reservations?code=FT35ZBQ">
      <x:passenger>Еke Jуgvan Шyvind</x:passenger>
      <x:outbound>
       <x:TravelRequest>
        <x:to>LAX</x:to>
        <x:from>LGA</x:from>
        <x:date>2001-12-14</x:date>
       </x:TravelRequest>
      </x:outbound>
      <x:return>
       <x:TravelRequest>
        <x:to>JFK</x:to>
        <x:from>LAX</x:from>
        <x:date>2001-12-20</x:date>
       </x:TravelRequest>
      </x:return>
    </x:ReservationRequest>
  </rdf:RDF>
 </env:Body>
</env:Envelope>
SOAP-сообщение, показывающее использование альтернативной схемы написания кода для элемента Body

В примере 17, тело SOAP-сообщения содержит описание маршрута путешествия с использованием схемы ресурсов и их свойств, описываемые с помощью синтаксиса Resource Description Framework (RDF) [RDF]. (Поскольку синтаксис RDF и его использование не входят в круг вопросов этого учебника, очень кратко можно сказать, что схема RDF сопоставляет ресурсы - такие как ресурс бронирования путешествий, доступный по адресу http://travelcompany.example.org/reservations?code=FT35ZBQ - другим ресурсам (или значениям) посредством свойств, таких как passenger, дат отправления в путешествие и возвращения из него outbound и return соответственно. Составление схем RDF для маршрута может выбираться, например, для того, чтобы приложение бронирования путешествия пассажира могло хранить эти схемы в RDF-совместимом календаре, который в этом случае можно будет использовать в более сложных сценариях.)

6. Различия между SOAP 1.1 и SOAP 1.2

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

Структура документа

Дополнительный или измененный синтаксис

HTTP-привязка SOAP

RPC

Написание кода SOAP

SOAP Часть 1 Приложение А описывает правила управления версиями для SOAP-узла, которые поддерживают переход с версии [SOAP 1.1] на SOAP Версия 1.2. В частности, они определяют заголовочный блок env:Upgrade, который может использоваться SOAP 1.2-узлом при получении [SOAP 1.1]-сообщения для отправки SOAP-сообщения об ошибке отправителю для указания поддерживаемой версии SOAP.

7. Ссылки

[SOAP Part1] W3C Recommendation "SOAP 1.2 Part 1: Messaging Framework", Martin Gudgin, Marc Hadley, Jean-Jacques Moreau, Henrik Frystyk Nielsen, 24 June 2003 (See http://www.w3.org/TR/2003/REC-soap12-part1-20030624/.)

[SOAP Part2] W3C Recommendation "SOAP 1.2 Part 2: Adjuncts", Martin Gudgin, Marc Hadley, Jean-Jacques Moreau, Henrik Frystyk Nielsen, 24 June 2003 (See http://www.w3.org/TR/2003/REC-soap12-part2-20030624/.)

[RFC 2396] IETF "RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax", T. Berners-Lee, R. Fielding, L. Masinter, August 1998. (See http://www.ietf.org/rfc/rfc2396.txt.)

[HTTP 1.1] IETF "RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1", R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, T. Berners-Lee, January 1997. (See http://www.ietf.org/rfc/rfc2616.txt.)

[XML 1.0] W3C Recommendation "Extensible Markup Language (XML) 1.0 (Second Edition)", Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, 6 October 2000. (See http://www.w3.org/TR/REC-xml.

[Namespaces in XML] W3C Recommendation "Namespaces in XML", Tim Bray, Dave Hollander, Andrew Layman, 14 January 1999. (See http://www.w3.org/TR/1999/REC-xml-names-19990114/.)

[XML Schema Part1] W3C Recommendation "XML Schema Part 1: Structures", Henry S. Thompson, David Beech, Murray Maloney, Noah Mendelsohn, 2 May 2001. (See http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/)

[XML Schema Part2] W3C Recommendation "XML Schema Part 2: Datatypes", Paul V. Biron, Ashok Malhotra, 2 May 2001. (See http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/)

[SMTP] SMTP is defined in a series of RFCs:

[RDF] W3C Recommendation "Resource Description Framework (RDF) Model and Syntax Specification", O. Lassila and R. Swick, Editors. World Wide Web Consortium. 22 February 1999. (See http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/.)

[SOAP 1.1] W3C Note "Simple Object Access Protocol (SOAP) 1.1", Don Box et al., 8 May, 2000 (See http://www.w3.org/TR/SOAP/)

[XML Infoset] W3C Recommendation "XML Information Set", John Cowan, Richard Tobin, 24 October 2001. (See http://www.w3.org/TR/xml-infoset/)

[SOAP MediaType] IETF Internet Draft "The 'application/soap+xml' media type", M. Baker, M. Nottingham, "draft-baker-soap-media-reg-03.txt", May 29, 2003. (See http://www.ietf.org/internet-drafts/draft-baker-soap-media-reg-03.txt, note that this Internet Draft expires in November 2003)

[SOAP Email Binding] W3C Note "SOAP Version 1.2 Email Binding", Highland Mary Mountain et al, draft June 13, 2002. (See http://www.w3.org/TR/2002/NOTE-soap12-email-20020626.)

[XML Base] W3C Recommendation "XML Base", Jonathan Marsh, 27 June 2001. (See http://www.w3.org/TR/2001/REC-xmlbase-20010627/)

[RFC 2119] IETF "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, March 1997. (See http://www.ietf.org/rfc/rfc2119.txt.)

A. Благодарности

Highland Mary Mountain (Intel) provided the initial material for the section on the SMTP binding. Paul Denning provided material for a usage scenario, which has since been moved to the SOAP Version 1.2 Usage Scenarios Working Draft. Stuart Williams, Oisin Hurley, Chris Ferris, Lynne Thompson, John Ibbotson, Marc Hadley, Yin-Leng Husband and Jean-Jacques Moreau provided detailed comments on earlier versions of this document, as did many others during the Last Call Working Draft review. Jacek Kopecky provided a list of RPC and SOAP encoding changes.

This document is the work of the W3C XML Protocol Working Group.

Participants in the Working Group are (at the time of writing, and by alphabetical order): Carine Bournez (W3C), Michael Champion (Software AG), Glen Daniels (Macromedia, formerly of Allaire), David Fallside (IBM, Chair), Dietmar Gaertner (Software AG), Tony Graham (Sun Microsystems), Martin Gudgin (Microsoft Corporation, formerly of DevelopMentor), Marc Hadley (Sun Microsystems), Gerd Hoelzing (SAP AG), Oisin Hurley (IONA Technologies), John Ibbotson (IBM), Ryuji Inoue (Matsushita Electric), Kazunori Iwasa (Fujitsu Limited), Mario Jeckle (DaimlerChrysler R. & Tech), Mark Jones (AT&T), Anish Karmarkar (Oracle), Jacek Kopecky (Systinet/Idoox), Yves Lafon (W3C), Michah Lerner (AT&T), Noah Mendelsohn (IBM, formerly of Lotus Development), Jeff Mischkinsky (Oracle), Nilo Mitra (Ericsson), Jean-Jacques Moreau (Canon), Masahiko Narita (Fujitsu Limited), Eric Newcomer (IONA Technologies), Mark Nottingham (BEA Systems, formerly of Akamai Technologies), David Orchard (BEA Systems, formerly of Jamcracker), Andreas Riegg (DaimlerChrysler R. & Tech), Hervй Ruellan (Canon), Jeff Schlimmer (Microsoft Corporation), Miroslav Simek (Systinet/Idoox), Pete Wenzel (SeeBeyond), Volker Wiechers (SAP AG).

Previous participants were: Yasser alSafadi (Philips Research), Bill Anderson (Xerox), Vidur Apparao (Netscape), Camilo Arbelaez (WebMethods), Mark Baker (Idokorro Mobile (Planetfred), formerly of Sun Microsystems), Philippe Bedu (EDF (Electricitй de France)), Olivier Boudeville (EDF (Electricitй de France)), Don Box (Microsoft Corporation, formerly of DevelopMentor), Tom Breuel (Xerox), Dick Brooks (Group 8760), Winston Bumpus (Novell), David Burdett (Commerce One), Charles Campbell (Informix Software), Alex Ceponkus (Bowstreet), David Chappell (Sonic Software), Miles Chaston (Epicentric), David Clay (Oracle), David Cleary (Progress Software), Conleth O'Connell (Vignette), Ugo Corda (Xerox), Paul Cotton (Microsoft Corporation), Fransisco Cubera (IBM), Jim d'Augustine (eXcelon), Ron Daniel (Interwoven), Dug Davis (IBM), Ray Denenberg (Library of Congress), Paul Denning (MITRE), Frank DeRose (Tibco), Mike Dierken (DataChannel), Andrew Eisenberg (Progress Software), Brian Eisenberg (DataChannel), Colleen Evans (Sonic Software), John Evdemon (XMLSolutions), David Ezell (Hewlett-Packard), Eric Fedok (Active Data Exchange), Chris Ferris (Sun Microsystems), Daniela Florescu (Propel), Dan Frantz (BEA Systems), Michael Freeman (Engenia Software), Scott Golubock (Epicentric), Rich Greenfield (Library of Congress), Hugo Haas (W3C), Mark Hale (Interwoven), Randy Hall (Intel), Bjoern Heckel (Epicentric), Erin Hoffman (Tradia), Steve Hole (MessagingDirect Ltd.), Mary Holstege (Calico Commerce), Jim Hughes (Fujitsu Software Corporation), Yin-Leng Husband (Hewlett-Packard, formerly of Compaq), Scott Isaacson (Novell), Murali Janakiraman (Rogue Wave), Eric Jenkins (Engenia Software), Jay Kasi (Commerce One), Jeffrey Kay (Engenia Software), Richard Koo (Vitria Technology Inc.), Alan Kropp (Epicentric), Julian Kumar (Epicentric), Peter Lecuyer (Progress Software), Tony Lee (Vitria Technology Inc.), Amy Lewis (TIBCO), Bob Lojek (Intalio), Henry Lowe (OMG), Brad Lund (Intel), Matthew MacKenzie (XMLGlobal Technologies), Murray Maloney (Commerce One), Richard Martin (Active Data Exchange), Highland Mary Mountain (Intel), Alex Milowski (Lexica), Kevin Mitchell (XMLSolutions), Ed Mooney (Sun Microsystems), Dean Moses (Epicentric), Don Mullen (TIBCO), Rekha Nagarajan (Calico Commerce), Raj Nair (Cisco), Mark Needleman (Data Research Associates), Art Nevarez (Novell), Henrik Nielsen (Microsoft Corporation), Kevin Perkins (Compaq), Jags Ramnaryan (BEA Systems), Vilhelm Rosenqvist (NCR), Marwan Sabbouh (MITRE), Waqar Sadiq (Vitria Technology Inc.), Rich Salz (Zolera), Krishna Sankar (Cisco), George Scott (Tradia), Shane Sesta (Active Data Exchange), Lew Shannon (NCR), John-Paul Sicotte (MessagingDirect Ltd.), Simeon Simeonov (Allaire), Simeon Simeonov (Macromedia), Aaron Skonnard (DevelopMentor), Nick Smilonich (Unisys), Soumitro Tagore (Informix Software), James Tauber (Bowstreet), Lynne Thompson (Unisys), Patrick Thompson (Rogue Wave), Jim Trezzo (Oracle), Asir Vedamuthu (WebMethods), Randy Waldrop (WebMethods), Fred Waskiewicz (OMG), David Webber (XMLGlobal Technologies), Ray Whitmer (Netscape), Stuart Williams (Hewlett-Packard), Yan Xu (DataChannel), Amr Yassin (Philips Research), Susan Yee (Active Data Exchange), Jin Yu (Martsoft).

We also wish to thank all the people who have contributed to discussions on xml-dist-app@w3.org.

B. Глоссарий (Приложение, составленное переводчиком)

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

attachment - зд. вложение, аттачмент сообщения электронной почты, e-mail;

content - зд. контент, содержимое чего-либо;

edge case - зд. частный (пограничный) случай;

encoding scheme - схема написания кода (сознательно не дается перевод "encoding" как "кодирование", дабы не происходило смешения с понятием, обозначающим операцию шифрования);

envelope - перен. оболочка, концептуальное описание чего-либо;

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

framework - зд. структура, строение чего-либо;

idempotent - идемпотентный;

infoset - информационное множество. Переводчик готов выслушать комментарии по поводу введения неологизма "инфосет";

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

media-type - медиа-тип, тип мультимедиа-данных;

message exchange pattern - шаблон обмена сообщениями;

origin server - букв. сервер происхождения сообщения - сервер, инициировавший обмен сообщениями;

payload - зд. полезная нагрузка;

protocol binding - протокольная привязка, привязка к какому-либо протоколу взаимодействия;

return value - зд. возвращаемое значение;

sub-element - субэлемент;

underlying protocol - зд. нижележащий протокол - протокол, находящийся на более низком уровне модели OSI, нежели SOAP.