ar-net.ru Представление SOAP RPC не определяет никаких других значений для http://www.w3.org/2003/05/soap/features/web-method/Method.
6.2 RPC и элемент Body SOAP
Как RPC вызовы (за исключением безопасных методов извлечения информации, см. 6.1.2), так и ответы содержат элемент SOAP Body [ИСО/МЭК 40210, подраздел 8.3], используемый для представлений, описанных ниже.
6.2.1 Вызов RPC
Вызов RPC моделируется следующим образом:
- вызов представляется единственной структурой, содержащей исходящее ребро для каждого входящего [in] или входящего/исходящего [in/out] параметра. Структура именуется идентично процедуре или методу. Для представления имен методов, которые не являются допустимыми XML именами, СЛЕДУЕТ использовать соглашения из приложения B;
- у каждого исходящего ребра есть метка, соответствующая имени параметра. Для представления имен параметров, которые не являются допустимыми XML именами, СЛЕДУЕТ использовать соглашения из приложения В.
Приложения МОГУТ обрабатывать вызовы с недостающими параметрами, но также МОГУТ не обрабатывать такие вызовы и возвращать отказы.
6.2.2 Ответ RPC
Ответ RPC моделируется следующим образом:
- ответ представляется единственной структурой, содержащей исходящее ребро для возвращаемого значения и по исходящему ребру для каждого исходящего [out] или входящего/исходящего [in/out] параметра. Имя структуры не имеет значения;
- каждый параметр представляется исходящим ребром с меткой, соответствующей имени параметра. Для представления названий параметров, которые не являются допустимыми XML именами, СЛЕДУЕТ использовать соглашения из приложения B;
- непустое возвращаемое значение представляется следующим образом:
1 ДОЛЖНО присутствовать исходящее ребро с локальным именем result и именем пространства имен "http://www.w3.org/2003/05/soap-rpc", заканчивающееся в конечном узле;
2 Тип конечного узла - xs:QName и его значение - имя исходящего ребра, которое заканчивается в фактическом возвращаемом значении;
- если возвращаемое значение процедуры пустое, то исходящее ребро с локальным именем result и именем пространства имен "http://www.w3.org/2003/05/soap-rpc" НЕ ДОЛЖНО присутствовать;
- отказы вызова обрабатываются согласно правилам, изложенным в 6.4. Если привязка протокола накладывает дополнительные правила для обработки отказа, то они также ДОЛЖНЫ быть выполнены.
6.2.3 Ограничение на кодирование SOAP
При использовании кодирования SOAP (см. раздел 5) в сочетании с соглашением RPC, описанным здесь, элемент Body SOAP ДОЛЖЕН содержать единственный дочерний информационный объект-элемент, который представляет собой сериализованную структуру вызова или ответа RPC.
6.3 RPC и заголовок SOAP
Дополнительная информация, относящаяся к кодированию вызова RPC, но не являющаяся частью формальной сигнатуры процедуры или метода, МОЖЕТ быть представлена в конверте SOAP, переносящем RPC вызов или ответ. Такая дополнительная информация ДОЛЖНА быть представлена в виде блоков заголовка SOAP.
6.4 Отказы RPC
Представление SOAP RPC вводит дополнительные, представленные на внутреннем коде, обозначения отказов SOAP, которые используются в сочетании с кодами отказов (см. [ИСО/МЭК 40210, пункт 8.4.6 "Коды отказа SOAP"]).
Об ошибках, возникающих во время выполнения вызовов RPC, сообщается согласно следующим правилам:
1 Отказ со значением Value элемента Code, равным "env:Receiver", СЛЕДУЕТ генерировать, если получатель временно не может обработать сообщение, например, в случае отсутствия достаточной памяти.
Примечание - Всюду в данном документе термин "значение Value элемента Code" используется как сокращение для "значение дочернего информационного объекта-элементаValue информационного объекта-элемента Code" (см. [ИСО/МЭК 40210, пункт 8.4.1]).
2 Отказ со значением Value элемента Code, равным "env:DataEncoding Unknown", СЛЕДУЕТ генерировать, если параметры закодированы в кодировку, неизвестную получателю.
3 Отказ со значением Value элемента Code, равным "env:Sender", и значением Value элемента Subcode, равным "rpc:ProcedureNotPresent", МОЖЕТ быть сгенерирован, если получатель не поддерживает определенную процедуру или метод.
Примечание - Всюду в данном документе термин "значение Value элемента Subcode" используется как сокращение для "значение дочернего информационного объекта-элементаValue информационного объекта-элемента Subcode" (см. [ИСО/МЭК 40210, подпункт 8.4.1.2]).
4 Отказ со значением Value элемента Code, равным "env:Sender", и значением Value элемента Subcode, равным "rpc:BadArguments", ДОЛЖЕН быть сгенерирован, когда получатель не может произвести анализ параметров или когда есть несоответствие в количестве и/или типах параметров между тем, что ожидает получатель и тем, что было отправлено.
5 Другие отказы, возникающие в расширении или в приложениях, СЛЕДУЕТ генерировать как описано в пункте "Коды Отказа SOAP" [ИСО/МЭК 40210, пункт 8.4.1].
Во всех случаях значения информационных объектов-элементов Detail и Reason определяются реализацией. Детали их использования МОГУТ задаваться внешним документом.
Примечание - В ответ на вызов RPC отправители могут получать различные отказы из перечисленных выше, если получатель не поддерживает описанное здесь (необязательное) соглашение RPC.
7 Соглашение для описания функций и привязок
В данном разделе определяется соглашение, описывающее функции (включая шаблоны обмена сообщениями (ШОС)) и привязки в терминах свойств и значений свойств. Соглашения достаточно для описания распределенных состояний спецификаций функций и привязок, как требует спецификация инфраструктуры привязок [ИСО/МЭК 40210, раздел 7]. Оно также используется для описания ШОС "запрос-ответ" (см. 8.2), ШОС "ответ SOAP" (см. 8.3), функции SOAP "Веб-метод" (см. 8.4) и привязки SOAP к HTTP (см. раздел 9) всюду в настоящем стандарте. Помимо самого соглашения, в данном разделе определена неформальная модель, описывающая процесс передачи свойства через систему SOAP. Отметим, что данная модель только иллюстративна и не включает в себя каких-либо ограничений на структуру или иерархическое представление любой конкретной реализации SOAP.
7.1 Модель и свойства
В целом, сообщение SOAP - это информация, которой один узел SOAP хочет обменяться с другим узлом SOAP согласно определенным соглашениям, включая шаблоны обмена сообщениями. Кроме того, может присутствовать информация, важная для обмена сообщениями, но не являющаяся частью самих сообщений. Такую информацию иногда называют метаданными сообщения. В модели сообщения любые метаданные сообщения и различные информационные объекты, определяющие функции, представляются как абстракции, называемые свойствами.
7.1.1 Свойства
В соответствии с соглашением свойства представляются следующим образом:
- свойства именуются посредством URI;
- где это уместно, спецификации, вводящей свойство, СЛЕДУЕТ определить тип значения свойства в соответствии со спецификацией XML Schema (см. [XML Schema Part 1], [XML Schema Part 2]).
7.1.2 Область применения свойства
Свойства в узле SOAP различаются по области применения и по источникам их значений. Как показано ниже на рисунке 1, свойства делятся на две группы: свойства для обмена сообщениями и свойства с более широкой областью применения, относящиеся к различным контейнерам. Эти группы называются "контекст обмена сообщениями" и "контекст окружения", соответственно. Все свойства, независимо от областей их применения, совместно используются узлом SOAP и определенной привязкой.
7.1.2.1 Контекст обмена сообщениями
Контекст обмена сообщениями - это набор свойств, область применения которых ограничена экземпляром данного шаблона обмена сообщениями. Пример свойства контекста обмена сообщениями - идентификатор используемого шаблона обмена сообщениями.
7.1.2.2 Контекст окружения
Контекст окружения - это набор свойств, область применения которых выходит за рамки экземпляра данного шаблона обмена сообщениями. Примеры свойств контекста окружения - IP-адрес узла SOAP или текущие дата и время.
Значения свойств в контексте окружения могут зависеть от локальных условий (на рисунке 1 это показано стрелкой, исходящей из контейнера "контекст окружения"). В частности, на свойства в примере может повлиять идентификатор пользователя операционной системы, от имени которого выполняется обмен сообщениями. Отображение информации конкретной реализацией в такие свойства выходит за рамки инфраструктуры привязки, хотя она включает в себя абстрактное представление такой информации как свойства.
Рисунок 1 - Модель, описывающая свойства, совместно используемые SOAP и привязкой
 | |
| 522 × 564 пикс. Открыть в новом окне | |