SOAP Document and RPC Style

SOAP Fault

Если возникает ошибка, то она возвращается в виде элемента <soap:Fault> содержащегося в элементе <soap:Body>, при этом существует ряд предопределённых дочерних элементов, конкретизирующих ошибку:

• <faultcode> - содержит код идентифицирующий ошибку.
• <faultstring> - содержит текстовое описание ошибки
• <faultactor> - информация о том, какая из сторон привела к ошибке
• <detail> - детальная информация об ошибке (например stack trace)

Возможные значения <faultcode>:

• VersionMismatch - при несовпадении версии или namespace’ов
• MustUnderstand – в случае если принимающая сторона не может или не занет как обработать заголовок помеченный как mustUnderstand=”1”
• Client –если ошибка происходит по вине клиента приславшего информацию в невалидной форме либо неправильно сформированную
• Server – если ошибка происходит во время выполнения сообщения на сервере по причине, отличной от формирования сообщения

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

• RPC style
• Document style

RPC style

Этот подход определяет SOAP сообщение как чётко следующее структуре и сигнатуре вызываемого метода и передаваемых параметров. Т.е., по своей сути является XML описанием контекста вызова метода и включает в себя:

• Имя метода
• Каждый параметр и его значение, представленное в виде XML

Например, если в интерфейсе на Java метод объявлен как:

public void placeOrder(PurchaseOrder purchaseOrder){

…

}

То соответствующее SOAP сообщение вызывающее этот метод будет выглядеть следующим образом:

<env:Body>

<m:placeOrder xmlns:m="someURI">

<m:purchaseOrder>

...

</m:purchaseOrder>

</m:placeOrder>

</env:Body>

Document style

Данный подход в отличие от RPC абстрагируется от понятия «метод» и оперирует с понятием «документ», т.е. по сути является «более сервисно-ориентированным», поскольку не делает акцента на внутренней структуре сервиса и экспортирует понятие принимаемого документа, с которым сервис «что-то» делает. А то, что он делает, определено, например, в контракте. Напрямую для разработчика это означает то, что при данном подходе потребитель сервиса напрямую не завязывается на такие его детали, как например название метода, количество и типы его параметров и т.п.

<env:Body>

<m:purchaseOrder xmlns:m="someURI">

...

</m:purchaseOrder>

</env:Body>

Исторически первым форматом стал RPC style так как SOAP развивался на идейных основах RPC, и как следствием требованием к RPC стилю было то, что бы структура сообщения чётко повторяла сигнатуру метода. Позднее, пришли к выводу, что это накладывает сильное ограничение на клиента, так как фактически привязывает его к сигнатуре, и это ограничение было снято. При этом, в отсутствии такого ограничения, Document style может полностью совпадать с RPC style. И более того, так как большинство WSDL генерируются автоматически, они часто совпадают.

Дата добавления: 2014-01-05