Для чего нужно объявление элемента Fault в WSDL?

Question

В WSDL элемент wsdl:Fault объявляет структуру сообщений об ошибках SOAP, которые может возвращать служба. Точнее, он объявляет структуру элемента <detail> сообщения о неисправности SOAP.

Q: Какова цель этого объявления wsdl:Fault? Указывает ли это на то, что деталь сообщения о неисправности SOAP 1008 * ДОЛЖНА иметь объявленные пространство имен и структуру? Или это указывает, что SOAP сообщение о сбое обычно имеет объявленные пространство имен и структуру? Другими словами, если служба SOAP возвращает SOAP сбоев со структурой элемента <detail>, имеющего пространство имен, отличное от объявленного в WSDL, будет ли сообщение недействительным по отношению к WSDL?

In По моему мнению, декларация wsdl:Fault является всего лишь предложением. Ошибка SOAP может быть возвращена другим уровнем, а не самой службой (например, шлюзом-посредником), и этот уровень может возвратить произвольное содержимое в подробности ошибки SOAP. Следовательно, я делаю вывод, что если реализация службы возвращает подробности о сбое, отличные от заявленных в WSDL, все должно быть в порядке, не так ли?

Answer 1

Я не нашел четкого ответа на мой вопрос. Но из различных подсказок в различной документации по inte rnet я могу сделать вывод, что:

1. Сообщение об ошибке может содержать любое количество дочерних элементов элемента <detail>. Даже такие подробные структуры, которые не объявлены в WSDL. См., Например, Пример 16-6 .
2. Заявленные в WSDL неисправности считаются смоделированными неисправностями , другие немоделированными неисправностями . Смоделированные ошибки представляют ошибки бизнес-логики c, другие ошибки обычно представляют ошибки времени выполнения / технические ошибки (см. здесь ).
3. Наличие нескольких элементов под элементом <detail> не противоречит WS -I Basi c Профиль. В частности, требование R1002 гласит:

R1002: ПРИЕМНИК ДОЛЖЕН принимать отказы, которые имеют любое количество элементов, включая ноль, и являются дочерними элементами элемента подробности. Такие дети могут быть квалифицированными или неквалифицированными.

Итак, чтобы подвести итог:

Служба должна возвращать смоделированные ошибки для бизнес-ошибок. Потребители могут обрабатывать эти смоделированные ошибки особым образом, например, чтобы повторить запрос с измененными параметрами. Немоделированные ошибки используются главным образом для технических ошибок, ошибок проверки и других ошибок времени выполнения.

Когда вы начинаете возвращать немоделированную ошибку вместо смоделированной, вы можете нарушить бизнес-логику c для пользовательского приложения.