Simple Object Access Protocol

Simple Object Access Protocol (SOAP) — это протокол обмена структурированными сообщениями в распределённой вычислительной среде, основанный на языке разметки XML. Первоначально разработанный компаниями Microsoft, DevelopMentor и UserLand Software, SOAP предназначен для обеспечения взаимодействия между различными программными компонентами, работающими на разных операционных системах, языках программирования и сетевых платформах. Протокол определяет формат сообщений, правила их обработки и способы привязки к транспортным протоколам, таким как HTTP, SMTP и TCP.

История

Предпосылки создания

В конце 1990-х годов доминирующим подходом к интеграции приложений были технологии удалённого вызова процедур (RPC), такие как CORBA, DCOM и Java RMI. Эти протоколы были сложны в настройке, требовали использования определённых языков программирования и платформ, а также часто блокировались корпоративными межсетевыми экранами из-за использования нестандартных портов. Возникла потребность в простом, платформонезависимом протоколе, который мог бы работать через существующую инфраструктуру веба.

Разработка и стандартизация

SOAP был впервые предложен в 1998 году Дэйвом Винером, Доном Боксом и Мохсеном Аль-Госейном. Первая спецификация (SOAP 0.9) была опубликована в сентябре 1999 года. В 2000 году черновик SOAP 1.1 был передан в Консорциум Всемирной паутины (W3C) для стандартизации. После длительного обсуждения и доработок, в 2003 году W3C выпустил рекомендацию SOAP 1.2, которая является текущей стабильной версией протокола. В отличие от версии 1.1, версия 1.2 отказалась от прямой привязки к RPC, предоставив более гибкий механизм обработки сообщений.

Эволюция и упадок

В середине 2000-х годов SOAP стал основой для веб-сервисов, построенных по принципу WS-* (WS-Security, WS-ReliableMessaging, WS-AtomicTransaction). Однако сложность этих стандартов, громоздкость XML-сообщений и высокая нагрузка на сеть привели к росту популярности альтернативных подходов, в первую очередь RESTful API на основе JSON. К 2010-м годам SOAP утратил доминирующее положение, но продолжает использоваться в корпоративных системах, где требуется строгая типизация, безопасность и транзакционность.

Архитектура и принципы работы

Модель сообщений

SOAP определяет строгую структуру XML-сообщения, которое состоит из трёх основных элементов:

1. Конверт (Envelope) — корневой элемент, который идентифицирует XML-документ как SOAP-сообщение. Он содержит пространство имён SOAP и может включать атрибуты, управляющие обработкой.
2. Заголовок (Header) — необязательный элемент, содержащий метаданные для обработки сообщения: информацию о безопасности, маршрутизации, транзакциях, а также пользовательские расширения. Заголовок может быть помечен атрибутом mustUnderstand, который указывает, что получатель обязан обработать данный блок заголовка, иначе сообщение должно быть отвергнуто.
3. Тело (Body) — обязательный элемент, содержащий собственно данные сообщения: либо запрос на вызов процедуры (с указанием имени метода и параметров), либо ответ (с результатами или ошибкой). В случае ошибки в теле размещается элемент Fault, который содержит код ошибки, описание, причину и детали.

Транспортная привязка

SOAP является транспортно-независимым протоколом. Наиболее распространённой привязкой является HTTP, где SOAP-сообщение передаётся в теле HTTP-запроса (POST) или ответа. При этом в HTTP-заголовке Content-Type указывается значение application/soap+xml (для версии 1.2) или text/xml (для версии 1.1). Другие возможные привязки включают SMTP (для электронной почты), JMS (Java Message Service) и TCP.

Модель взаимодействия

SOAP поддерживает несколько моделей взаимодействия:

• Запрос-ответ (Request-Response) — клиент отправляет сообщение, сервер обрабатывает его и возвращает ответ. Это наиболее распространённая модель, аналогичная RPC.
• Однонаправленная (One-way) — клиент отправляет сообщение, не ожидая ответа. Используется для асинхронной передачи данных.
• Запрос-ответ с задержкой (Request-Response with delay) — клиент отправляет запрос, сервер немедленно возвращает подтверждение, а затем асинхронно отправляет результат.

Формат сообщения

Пример SOAP-запроса

``xml <?xml version="1.0" encoding="UTF-8"?> <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"; xmlns:web="http://example.com/webservice">; <soap:Header> <web:Authentication soap:mustUnderstand="true"> <web:Username>user</web:Username> <web:Password>pass</web:Password> </web:Authentication> </soap:Header> <soap:Body> <web:GetPrice> <web:ItemID>12345</web:ItemID> </web:GetPrice> </soap:Body> </soap:Envelope> ``

Пример SOAP-ответа

``xml <?xml version="1.0" encoding="UTF-8"?> <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"; xmlns:web="http://example.com/webservice">; <soap:Body> <web:GetPriceResponse> <web:Price>29.99</web:Price> <web:Currency>USD</web:Currency> </web:GetPriceResponse> </soap:Body> </soap:Envelope> ``

Обработка ошибок (Fault)

В случае ошибки сервер возвращает сообщение с элементом Fault в теле: ``xml <soap:Body> <soap:Fault> <soap:Code> <soap:Value>soap:Sender</soap:Value> </soap:Code> <soap:Reason> <soap:Text xml:lang="en">Invalid item ID</soap:Text> </soap:Reason> <soap:Detail> <web:ErrorDetails>Item ID must be a positive integer</web:ErrorDetails> </soap:Detail> </soap:Fault> </soap:Body> ``

Связь с WSDL и UDDI

SOAP-сервисы обычно описываются с помощью Web Services Description Language (WSDL) — XML-документа, который определяет доступные операции, форматы сообщений, типы данных и адреса конечных точек (endpoints). WSDL-документ позволяет клиентам автоматически генерировать код для вызова сервиса.

Для обнаружения доступных SOAP-сервисов в сети использовался протокол Universal Description, Discovery and Integration (UDDI), который представлял собой реестр веб-сервисов. Однако UDDI не получил широкого распространения и в значительной степени вытеснен современными подходами к обнаружению API.

Преимущества и недостатки

Преимущества

• Платформонезависимость: SOAP работает с любыми языками программирования и операционными системами, поддерживающими XML.
• Строгая типизация: WSDL-описание обеспечивает точное определение типов данных, что уменьшает количество ошибок при интеграции.
• Расширяемость: Заголовки SOAP позволяют добавлять произвольные метаданные (безопасность, транзакции, маршрутизация) без изменения основного протокола.
• Поддержка стандартов: SOAP интегрируется с набором стандартов WS-* (WS-Security, WS-ReliableMessaging, WS-AtomicTransaction), что обеспечивает высокий уровень безопасности, надёжности и транзакционности.
• Работа через брандмауэры: Использование HTTP (порт 80/443) позволяет SOAP-сообщениям проходить через большинство корпоративных межсетевых экранов.

Недостатки

• Избыточность: XML-формат сообщений приводит к большому объёму передаваемых данных по сравнению с JSON или бинарными протоколами.
• Сложность: Разработка, отладка и поддержка SOAP-сервисов требуют больше времени и ресурсов, чем RESTful API.
• Низкая производительность: Парсинг и генерация XML-сообщений, а также накладные расходы на обработку заголовков снижают скорость работы.
• Сложность кэширования: SOAP-сообщения, передаваемые через HTTP POST, сложнее кэшировать на промежуточных узлах, чем GET-запросы REST.
• Устаревание: Многие современные разработчики предпочитают более простые и лёгкие альтернативы, такие как REST и gRPC.

Применение

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

• Корпоративные системы (ERP, CRM): Системы SAP, Oracle, Microsoft Dynamics часто используют SOAP для интеграции между собой и с внешними приложениями.
• Финансовый сектор: Банковские системы, платёжные шлюзы и системы обработки транзакций требуют высокой надёжности и безопасности, которые обеспечивает SOAP.
• Телекоммуникации: Протоколы управления сетями и биллинговые системы часто используют SOAP.
• Государственные информационные системы: В ряде стран (включая Россию) SOAP является стандартом для взаимодействия между государственными информационными системами, например, в рамках системы межведомственного электронного взаимодействия (СМЭВ).
• Интеграция с устаревшими системами (Legacy Integration): Многие старые системы, разработанные в 2000-х годах, поддерживают только SOAP, и их модернизация требует сохранения этого протокола.

Интересные факты

• Изначально SOAP расшифровывался как Simple Object Access Protocol (Простой протокол доступа к объектам). Однако начиная с версии 1.2, эта расшифровка была официально отменена, так как протокол перестал быть привязанным к объектной модели.
• SOAP-сообщения могут быть подписаны и зашифрованы с использованием стандартов XML Signature и XML Encryption, что обеспечивает сквозную безопасность.
• В спецификации SOAP 1.2 была введена концепция «модели обработки сообщений» (Message Processing Model), которая описывает, как узлы-посредники (intermediaries) могут обрабатывать заголовки сообщения, не затрагивая тело.

Источники

• W3C Recommendation: SOAP Version 1.2 Part 1: Messaging Framework (2003)
• W3C Recommendation: SOAP Version 1.2 Part 2: Adjuncts (2003)
• Box, D., Ehnebuske, D., Kakivaya, G., et al. "Simple Object Access Protocol (SOAP) 1.1", W3C Note (2000)
• Snell, J., Tidwell, D., Kulchenko, P. "Programming Web Services with SOAP", O'Reilly Media (2002)
• Weerawarana, S., Curbera, F., Leymann, F., et al. "Web Services Platform Architecture: SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, and More", Prentice Hall (2005)