45743 (762134), страница 2

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 2)

xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

22-342439

98-283843

100.00

dave

evad

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

Расширяемость

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

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

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

xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

dave

evad

22-342439

98-283843

100.00

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

xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

soap:mustUnderstand="1"

>

dave

evad

...

Если блок заголовка аннотирован mustUnderstand="1", и получатель не поддерживает данный заголовок, сообщение не будет обработано и отправителю будет возвращен Fault (с кодом состояния soap:MustUnderstand). Когда mustUnderstand="0" или этого атрибута нет, получатель может игнорировать эти заголовки и продолжать обработку. Атрибут mustUnderstand играет центральную роль во всей модели обработки SOAP.

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

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

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

Рисунок 3. Сложный обмен SOAP сообщениями

Посредник располагается между начальным отправителем и конечным получателем и перехватывает SOAP сообщения. Посредник работает одновременно и как SOAP отправитель, и как SOAP получатель. Промежуточные узлы делают возможным разрабатывать некоторые интересные и гибкие сетевые архитектуры, на которые можно воздействовать содержимым сообщения. Маршрутизация SOAP сообщений является хорошим примером того, что значительно усиливает значимость SOAP посредников (более подробно о маршрутизации SOAP сообщений см. в Routing SOAP Messages with Web Services Enhancements 1.0)

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

Как только он определится с ролями, которые будет выполнять, SOAP узел должен обработать все обязательные заголовки (отмеченные mustUnderstand="1"), направленные на одну из его ролей. Также SOAP узел может выбрать для обработки любой необязательный заголовок (отмеченный mustUnderstand="0"), направленный на одну из его ролей.

SOAP 1.1 определяет только одну роль - http://schemas.xmlsoap.org/soap/actor/next (next для краткости). Каждый SOAP узел должен принять роль next. Таким образом, когда SOAP сообщение приходит в любой данный SOAP узел, узел должен обработать все обязательные заголовки, нацеленные на роль next, и он может обработать необязательные заголовки, также нацеленные на роль next. Кроме next, SOAP 1.2 определяет еще несколько ролей (см. Таблица 3), приложениям разрешено также определять собственные роли.

SOAP заголовки нацеливаются на конкретные роли с помощью глобального атрибута actor (в SOAP 1.2 этот атрибут назван role). Если этого атрибута нет, заголовок по умолчанию нацеливается на конечного получателя. Следующее SOAP сообщение иллюстрирует, как использовать actor:

xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

soap:actor="http://schemas.xmlsoap.org/soap/actor/next"

soap:mustUnderstand="1"

>

...

Поскольку заголовок wsrp:path нацелен на роль next и помечен как обязательный (mustUnderstand="1"), первый SOAP узел, получающий это сообщение, должен обработать его в соответствии со спецификацией блока заголовка, в данном случае WS-Routing. Если SOAP узел разработан так, что не понимает обязательного заголовка, нацеленного на одну из его ролей, он должен сгенерировать SOAP ошибку с кодом состояния soap:MustUnderstand и прервать обработку. Чтобы определить, что вызвало ошибку в прохождении сообщения, элемент SOAP Fault предоставляет дочерний элемент faultactor. Значением атрибута faultactor является URI, который идентифицирует SOAP узел, вызвавший ошибку.

Если SOAP узел успешно обработал заголовок, требуется удалить этот заголовок из сообщения. SOAP узлам разрешено повторно вставлять заголовки, но это изменяет участников контракта – теперь заголовки targets между текущим и следующим узлами. Если SOAP узел оказывается конечным получателем, он также должен обработать и SOAP тело.

Таблица 3. Роли SOAP 1.2

Взамодействие протоколов

Интересно, что на Рисунке 3 SOAP обеспечивает обмен сообщениями через различные базовые протоколы. Поскольку оболочка обмена SOAP сообщениями не зависит от базовых протоколов, каждый посредник может использовать различные протоколы обмена без влияния на SOAP сообщения. Однако для обеспечения высоких уровней взаимодействия между SOAP приложениями и инфраструктурой необходимы стандартные взаимодействия протоколов.

Конкретное взаимодействие протоколов определяет как именно SOAP сообщения должны передаваться с помощью данного протокола. Иначе говоря, он определяет детали того, как SOAP согласовывается в рамках другого протокола, который, возможно, имеет собственную оболочку обмена сообщениями наряду с разнообразием заголовков. Что действительно определяет взаимодействие протоколов в большой степени зависит от характеристик и возможностей протокола. Например, взаимодействие протоколов для TCP будет сильно отличаться от взаимодействия для MSMQ или SMTP.

Спецификация SOAP 1.1 кодифицирует взаимодействие протоколов только для HTTP из-за его широкого распространения. SOAP используется и с другими протоколами, но реализации не следовали стандартизованному взаимодействию.

HTTP взаимодействие

Взаимодействие протокола HTTP определяет правила использования SOAP поверх HTTP. SOAP запрос/ответ просто преобразовывается в модель HTTP запроса/ответа. Рисунок 4 иллюстрирует многие детали соединения SOAP HTTP.

Рисунок 4. SOAP HTTP взаимодействие

Заголовок Content-Type для HTTP сообщений запроса и ответа должен быть text/xml (application/soap+xml в SOAP 1.2). Что касается сообщения запроса, оно должно использовать в качестве команды слово POST, и URI должен определять SOAP обработчик. Спецификация SOAP также определяет новый HTTP заголовок – SOAPAction, который должен присутствовать во всех SOAP HTTP запросах (даже если они пустые). Заголовок SOAPAction предназначен для выражения цели сообщения. Что касается HTTP ответа, он должен использовать код состояния 200, если не произошла ошибка, или 500, если тело содержит SOAP Fault.

RPC и кодирование

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

Чтобы сделать вызов метода, используя SOAP, инфраструктуре нужна следующая информация:

1. Местоположение (URI)

2. Имя метода

3. Имена/значения параметра

4. Необязательно сигнатура метода

5. Необязательно данные заголовка

Эта информация может переноситься различными способами, включая библиотеки типов, IDL файлы или лучше WSDL файлы. Взаимодействие SOAP RPC определяет, как инкапсулировать или представить эту информацию в SOAP теле. Сначала определяется, как сигнатура метода преобразовывается в простые структуры запроса/ответа, которые затем могут быть кодированы как XML. Соединение RPC устанавливает, что вызов метода будет сделан как struct, названная так же как и метод. Struct будет содержать аксессор для каждого параметра [in] или [in/out], названный так же как и параметр, и в последовательности, определенной сигнатурой сообщения. Ответ метода также будет смоделирован как struct. Имя struct может быть любым, хотя, согласно соглашению, надо использовать имя метода, оканчивающееся словом "Response" (т.е. для операции add ответ метода, соответственно, будет называться addResponse). Struct ответа содержит аксессор для возвращаемого значения (в SOAP 1.1 имя не имеет значения, но в SOAP 1.2 должно быть rpc:result), за которым следует аксессор для каждого параметра [out] или [in/out].

Давайте рассмотрим пример. Следующая сигнатура метода на C# допускается для операции add:

double add(ref double x, double y)

В соответствии с только что описанными правилами RPC соединения, struct запроса, представляющая вызов метода, будет смоделирована следующим образом:

struct add {

double x;

Характеристики

Список файлов статьи