Возможно, единственно наиболее важное отличие между демо- и готовым сервисом заключается в качестве обработки ошибок. Тем не менее, в литературе этому вопросу удаляется мало внимания.

Определение отдельных сообщений с целью установления различных сбойных ситуаций может быть удобно - структура таких сообщений может меняться согласно возникшей сбойной ситуации. В Листинге определен Web-сервис, который приведет в бешенство системных администраторов: он запускает двоичный код (binary), по запросу вызывающей программой. Читатель, возможно, будет разочарован, не обнаружив примеров использования пространств имен и разделения на модули - этот пример не рассматривает эти особенности. Он иллюстрирует обработку ошибок - при проектировании была предусмотрена возможность появления двух ошибок: первая - если недостаточно памяти, в этом случае возвращается область выделенной динамической памяти и количество используемой памяти; вторая - если программа попытается разыменовывать нулевой указатель, в этой случае возвращается запись стека.

Типы сообщения о сбоях получены из абстрактного типа. Причина использования абстрактных типов может быть объяснена желанием провести аналогию с отображением ошибочных действий в иерархию наследования во многих языках программирования. Поэтому исправленный Листинг - это более компактное описание Web-сервиса. Разница между наборами сообщений о сбоях, которые допустимы согласно соответствующим документам, незначительны.

Замысел, однако, намного яснее в первом документе. Разработчики клиентской реализации, работая со вторым документом вероятно смогут предположить, что может быть возвращено и сообщение OutOfMemoryException. Но из спецификации неясно, имеет ли это значение. Также они не могут быть уверенными, что код клиентской реализации охватывает все сбойные ситуации, поскольку абстрактный класс tException может быть расширен типами, отличными от перечисленных во втором документе.

Автор сталкивался с гибридным подходом, при котором сложный тип не объявлен абстрактным. В этом случае сообщения о сбоях могут быть определены в описании Web-сервиса как производный тип, иногда определяется сложный тип. В результате, возникает еще большая неопределенность относительно точного формата, который получит клиент - автор не рекомендует этот подход.

document/literal против rpc/encoded

Здравый смысл предписывает использовать текстовый формат передачи при вызове документа и кодированный при использовании RPC (Remote Procedure Call, Удаленный вызов процедуры). Однако, фундаментальных причин, почему необходимо следовать этому правилу, нет - это скорее исторически сложившиеся стечение обстоятельств, что инструменты, как правило, поддерживают эти комбинации.

Выбор осуществляется между сложностью модели программирования и сложностью маршалинга (marshalling) сообщений. RPC предлагает удобную модель программирования. Она не без изъянов, как отмечалось в предыдущей статье. Однако, также важно знать об обязательствах, которые форматы передачи, используемые с RPC, накладывают на маршалеров: различие между literal и encoded - это различие между составителем и читателем. Это означает, что у второго формата передачи может быть множество различных представлений для семантически эквивалентных сообщений.

Классический пример - поддержка кодирования SOAP для независимых и встроенных элементов. Понимать все представления - дело получателя. В предыдущем разделе уже говорилось о важности максимально точного определения формата сообщения. Причина тому - высокая стоимость принятия правильного решения читателем. Это, возможно, не имеет значения в средах, в которых доступны сложные инструменты генерации клиентской заглушки (client stub), но при работе на гетерогенных платформах это не всегда так.