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

В своей основе 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демонстрирует примеры обработки ошибок. 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-сообщения, которая должна быть передана из начальной точки пути сообщения в конечную.

В примере 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-сообщений и их обработки.