Более сложные сценарии использования Использование 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после того, как активный посредник вложил в него обязательный заголовок, предназначенный для конечного получателя сообщения