Тело SOAP

Содержимое тела SOAP

В теле SOAP передаются:

• Запросы к веб-сервису — например, вызов метода getUser с параметрами.
• Ответы от веб-сервиса — например, результат выполнения метода getUser в виде структуры данных.
• Данные об ошибках (SOAP Fault) — в случае, если при обработке запроса произошла ошибка.

Пример тела запроса

``xml <soap:Body> <m:GetUserRequest xmlns:m="http://example.com/user">; <m:UserId>12345</m:UserId> </m:GetUserRequest> </soap:Body> ``

Пример тела ответа

``xml <soap:Body> <m:GetUserResponse xmlns:m="http://example.com/user">; <m:UserName>Иван Иванов</m:UserName> <m:Email>ivan@example.com</m:Email> </m:GetUserResponse> </soap:Body> ``

Пример тела с ошибкой (SOAP Fault)

``xml <soap:Body> <soap:Fault> <faultcode>soap:Client</faultcode> <faultstring>Неверный идентификатор пользователя</faultstring> <detail> <m:ErrorDetails xmlns:m="http://example.com/user">; <m:ErrorCode>400</m:ErrorCode> </m:ErrorDetails> </detail> </soap:Fault> </soap:Body> ``

Правила формирования тела SOAP

1. Обязательность: тело SOAP должно присутствовать в каждом сообщении SOAP. Даже если веб-сервис не требует передачи данных, тело должно быть пустым, но не отсутствовать.
2. Одно тело: в одном сообщении может быть только один элемент Body.
3. Отсутствие атрибутов: элемент Body не может иметь атрибутов, кроме атрибутов пространства имён.
4. Порядок: тело следует за заголовком (если заголовок есть) и является последним дочерним элементом Envelope.
5. Сериализация: все данные в теле должны быть сериализованы в XML в соответствии с правилами кодирования SOAP (обычно используется канонический XML или SOAP Encoding).

Отличие от заголовка SOAP

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

Обработка ошибок

Если при обработке запроса возникает ошибка, веб-сервис возвращает сообщение, в теле которого содержится элемент Fault. Это единственный случай, когда тело SOAP содержит не данные прикладного уровня, а информацию об ошибке протокола. Элемент Fault имеет стандартную структуру:

• faultcode — код ошибки (например, soap:Client, soap:Server, soap:VersionMismatch, soap:MustUnderstand).
• faultstring — текстовое описание ошибки.
• faultactor — URI узла, вызвавшего ошибку (необязательно).
• detail — детали ошибки, специфичные для приложения (необязательно).

История и развитие

Протокол SOAP был разработан консорциумом W3C (World Wide Web Consortium) в конце 1990-х годов как стандарт для обмена структурированными данными в распределённых системах. Первая версия (SOAP 1.1) была опубликована в 2000 году, а SOAP 1.2 стал рекомендацией W3C в 2003 году. В обеих версиях концепция тела SOAP оставалась неизменной: тело — это контейнер для полезной нагрузки.

С развитием RESTful веб-сервисов и JSON как формата обмена данными популярность SOAP снизилась, особенно в новых проектах. Однако SOAP по-прежнему широко используется в корпоративных системах, банковской сфере, телекоммуникациях и других областях, где требуется строгая типизация, поддержка транзакций и безопасность.

Применение в современных системах

Тело SOAP используется в:

• Корпоративных интеграционных платформах — например, в продуктах Oracle SOA Suite, IBM WebSphere, SAP NetWeaver.
• Банковских системах — для обмена данными между банками и платёжными системами (например, SWIFT, ISO 20022).
• Государственных информационных системах — в России, например, в системах электронного документооборота и межведомственного взаимодействия (СМЭВ).
• Веб-сервисах с жёсткими требованиями к контракту — где WSDL-описание однозначно определяет структуру запросов и ответов.

Критика и ограничения

Основные недостатки тела SOAP связаны с общими недостатками протокола SOAP:

• Избыточность: XML-формат приводит к большому объёму передаваемых данных по сравнению с JSON.
• Сложность: для работы с SOAP требуется понимание XML-схем, пространств имён и правил кодирования.
• Производительность: парсинг XML медленнее, чем парсинг JSON, особенно на мобильных устройствах.
• Слабая поддержка в браузерах: SOAP-сообщения редко используются в клиент-серверных веб-приложениях из-за сложности работы с XML в JavaScript.

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

Источники

• W3C Recommendation «SOAP Version 1.2 Part 1: Messaging Framework» (2003)
• W3C Note «SOAP Version 1.1» (2000)
• Box, D. et al. «Simple Object Access Protocol (SOAP) 1.1» (2000)
• World Wide Web Consortium. «XML Schema Part 1: Structures» (2001)
• Oracle. «Understanding SOAP Messages» (документация Oracle Fusion Middleware)