Особенности SOAP

Введение: Что делает SOAP уникальным

В предыдущей теме мы разобрали, что такое SOAP — протокол обмена XML-сообщениями для корпоративных интеграций. Но что делает SOAP особенным? Почему в мире, где REST кажется проще и удобнее, SOAP всё ещё жив и активно используется в банках, страховых компаниях и государственных системах?

Ответ — в особенностях SOAP. Это не просто “XML поверх HTTP”. SOAP — это целая экосистема стандартов, которые вместе обеспечивают безопасность, надёжность, транзакционность и формальные контракты. Там, где REST требует “допилить” эти механизмы вручную, SOAP предоставляет их “из коробки”.

Особенности SOAP — это набор характеристик и расширений протокола, которые делают его пригодным для сложных корпоративных сценариев: строгая типизация, формальные контракты (WSDL), встроенная безопасность (WS-Security), поддержка транзакций (WS-AtomicTransaction), гарантированная доставка (WS-ReliableMessaging) и независимость от транспорта.

Понимание этих особенностей помогает ответить на вопрос: “Почему банк использует SOAP, а не REST?”

1. Строгая типизация (Strong Typing)

Что это значит

SOAP использует XML Schema (XSD) для описания типов данных. Каждое поле имеет явно указанный тип: строка, число, дата, массив и так далее.

<!-- XSD определение типа -->
<xsd:complexType name="User">
    <xsd:sequence>
        <xsd:element name="Id" type="xsd:int"/>
        <xsd:element name="Name" type="xsd:string"/>
        <xsd:element name="Email" type="xsd:string"/>
        <xsd:element name="CreatedAt" type="xsd:dateTime"/>
        <xsd:element name="Balance" type="xsd:decimal"/>
    </xsd:sequence>
</xsd:complexType>

Почему это важно

Пример: Ошибка типизации

<!-- Неправильно: Id должен быть числом -->
<soap:Body>
    <GetUser>
        <UserId>abc</UserId>  <!-- Ошибка! Ожидается int -->
    </GetUser>
</soap:Body>

Сервер вернёт ошибку валидации ДО того, как вызов дойдёт до бизнес-логики.

REST аналогия

В REST типизация отсутствует. Это и плюс (гибкость), и минус (меньше гарантий).

{
    "id": "123",     // Может быть строкой или числом — не определено
    "created_at": "2024-01-15"  // Строка, не дата
}

Клиент должен догадываться или читать документацию.

2. Формальный контракт (WSDL)

Что это значит

Каждый SOAP сервис описывается WSDL (Web Services Description Language) — XML документом, который формально описывает:

• Какие операции доступны
• Какие параметры принимает каждая операция
• Какие типы данных используются
• Где находится сервис (URL)
• Какой транспорт используется

Пример фрагмента WSDL

<portType name="UserPort">
    <operation name="GetUser">
        <input message="tns:GetUserRequest"/>
        <output message="tns:GetUserResponse"/>
        <fault message="tns:UserNotFoundFault"/>
    </operation>
</portType>

Почему это важно

REST аналогия

В REST формального контракта нет. OpenAPI (Swagger) — попытка создать аналог, но он не обязателен и не встроен в протокол.

# OpenAPI — опциональная документация, не контракт
openapi: 3.0.0
paths:
  /users/{id}:
    get:
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: integer

3. Расширяемость через заголовки (SOAP Headers)

Что это значит

SOAP сообщение имеет отдельную секцию <soap:Header>, которая может содержать любые метаданные, не влияющие на основное тело.

<soap:Envelope>
    <soap:Header>
        <!-- Аутентификация -->
        <wsse:Security>...</wsse:Security>
        
        <!-- Информация о транзакции -->
        <wsat:AtomicTransaction>...</wsat:AtomicTransaction>
        
        <!-- Маршрутизация -->
        <wsrm:Sequence>...</wsrm:Sequence>
        
        <!-- Пользовательские заголовки -->
        <myapp:CorrelationId>abc-123</myapp:CorrelationId>
        <myapp:TenantId>tenant-456</myapp:TenantId>
    </soap:Header>
    <soap:Body>
        <!-- Основное сообщение -->
    </soap:Body>
</soap:Envelope>

Почему это важно

REST аналогия

В REST метаданные передаются в HTTP заголовках.

Authorization: Bearer token123
X-Correlation-Id: abc-123
X-Tenant-Id: tenant-456

Но HTTP заголовки ограничены по длине и не имеют стандартизированных расширений для транзакций и надёжности.

4. Независимость от транспорта (Transport Independence)

Что это значит

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

• HTTP / HTTPS (самый распространённый)
• SMTP (электронная почта)
• JMS (Java Message Service — очереди)
• MSMQ (Microsoft Message Queuing)
• TCP (прямое сокетное соединение)

Пример: SOAP через SMTP

From: client@example.com
To: soap-service@example.com
Subject: SOAP Request

<?xml version="1.0"?>
<soap:Envelope ...>
    <soap:Body>
        <GetUser>
            <UserId>123</UserId>
        </GetUser>
    </soap:Body>
</soap:Envelope>

Почему это важно

REST аналогия

REST почти всегда работает через HTTP/HTTPS. Есть альтернативы (например, CoAP для IoT), но они не являются стандартом.

5. Встроенная безопасность (WS-Security)

Что это значит

WS-Security — стандарт для безопасности SOAP сообщений. Обеспечивает:

• Аутентификацию — кто отправил сообщение
• Подпись — сообщение не было изменено
• Шифрование — конфиденциальность
• Таймстемпы — защита от повторной отправки (replay attack)

Пример подписанного сообщения

<soap:Header>
    <wsse:Security>
        <ds:Signature>
            <ds:SignedInfo>
                <ds:Reference URI="#Body">
                    <ds:DigestValue>...</ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>...</ds:SignatureValue>
        </ds:Signature>
        
        <wsse:UsernameToken>
            <wsse:Username>ivan</wsse:Username>
            <wsse:Password>***</wsse:Password>
        </wsse:UsernameToken>
        
        <wsu:Timestamp>
            <wsu:Created>2024-01-15T10:30:00Z</wsu:Created>
            <wsu:Expires>2024-01-15T10:35:00Z</wsu:Expires>
        </wsu:Timestamp>
    </wsse:Security>
</soap:Header>
<soap:Body id="Body">
    <!-- Зашифрованное тело -->
    <xenc:EncryptedData>...</xenc:EncryptedData>
</soap:Body>

Почему это важно

REST аналогия

REST полагается на TLS/HTTPS для шифрования и аутентификации на транспортном уровне. Но TLS не даёт подписи сообщения и шифрования на уровне сообщения (приватно для разных получателей).

6. Надёжность (WS-ReliableMessaging)

Что это значит

WS-ReliableMessaging гарантирует доставку сообщений в распределённых системах даже при сбоях сети.

Возможности:

• Подтверждение получения (acknowledgement)
• Повторная отправка при потере
• Упорядочивание сообщений
• Устранение дубликатов

Пример заголовков надёжности

<soap:Header>
    <wsrm:Sequence>
        <wsrm:Identifier>http://example.com/rm/123</wsrm:Identifier>
        <wsrm:MessageNumber>1</wsrm:MessageNumber>
        <wsrm:LastMessage/>
    </wsrm:Sequence>
    <wsrm:Acknowledgement>
        <wsrm:AcknowledgementRange Upper="5" Lower="1"/>
    </wsrm:Acknowledgement>
</soap:Header>

Почему это важно

REST аналогия

REST не имеет встроенного механизма надёжности. Клиент сам должен реализовывать повторные попытки, идемпотентность, отслеживание порядка.

7. Распределённые транзакции (WS-AtomicTransaction)

Что это значит

WS-AtomicTransaction (WS-AT) позволяет выполнять распределённые транзакции, затрагивающие несколько SOAP сервисов, с гарантиями ACID.

Двухфазная фиксация (2PC):

1. Фаза Prepare: Каждый участник проверяет, может ли он выполнить операцию
2. Фаза Commit/Rollback: Если все готовы — commit, если нет — rollback

Пример заголовков транзакции

<soap:Header>
    <wsat:AtomicTransaction>
        <wsat:TransactionID>http://example.com/tx/123</wsat:TransactionID>
    </wsat:AtomicTransaction>
</soap:Header>

Почему это важно

REST аналогия

REST не имеет встроенной поддержки распределённых транзакций. Для их реализации нужны сложные паттерны: Saga, компенсирующие транзакции, 2PC поверх HTTP.

8. Состояние (Stateful)

Что это значит

SOAP может быть stateful (с сохранением состояния). Сервер может запомнить контекст между вызовами.

<!-- Установка контекста -->
<soap:Header>
    <myapp:SessionId>session-123</myapp:SessionId>
</soap:Header>

Почему это важно

REST аналогия

REST stateless по принципу. Каждый запрос должен содержать всю необходимую информацию. Это упрощает масштабирование, но иногда требует передавать много данных в каждом запросе.

9. Многословность (Verbosity)

Что это значит

SOAP сообщения очень многословны. Одно и то же сообщение в SOAP может быть в 10-20 раз больше, чем в JSON.

Сравнение

SOAP (запрос пользователя):

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:user="http://example.com/user">
    <soap:Body>
        <user:GetUserRequest>
            <user:UserId>123</user:UserId>
        </user:GetUserRequest>
    </soap:Body>
</soap:Envelope>

Размер: ~300 байт

REST (тот же запрос):

GET /users/123

Размер: ~20 байт

Почему это важно

10. Поддержка асинхронных операций

Что это значит

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

Request-Response (синхронный):

Клиент → Запрос → Сервер → Ответ → Клиент

Callback (асинхронный):

Клиент → Запрос (с callback адресом) → Сервер
Сервер → Ответ (на callback адрес) → Клиент

Polling (асинхронный):

Клиент → Запрос → Сервер → "В обработке"
Клиент → Проверка статуса → Сервер → "Ещё не готов"
Клиент → Проверка статуса → Сервер → "Готов, вот ответ"

Пример callback заголовка

<soap:Header>
    <ws-addr:ReplyTo>
        <ws-addr:Address>http://client.example.com/callback</ws-addr:Address>
    </ws-addr:ReplyTo>
</soap:Header>

Сводная таблица особенностей SOAP

Резюме для системного аналитика

1. Строгая типизация — каждое поле имеет явный тип. XML Schema валидирует сообщения до бизнес-логики.

2. WSDL — формальный контракт. Описывает всё, что нужно для вызова. Позволяет генерировать клиентский код автоматически.

3. SOAP Headers — отдельная секция для метаданных. Безопасность, транзакции, маршрутизация — в заголовках, не в теле.

4. Независимость от транспорта — SOAP работает через HTTP, SMTP, JMS, TCP. REST почти всегда HTTP.

5. WS-Security — безопасность на уровне сообщений. Подпись, шифрование, аутентификация. REST полагается на TLS.

6. WS-ReliableMessaging — гарантированная доставка, упорядочивание, устранение дубликатов.

7. WS-AtomicTransaction — распределённые транзакции с ACID гарантиями. Двухфазная фиксация.

8. Stateful — SOAP может сохранять состояние между вызовами. REST stateless.

9. Многословность — SOAP сообщения в 10-20 раз больше JSON. XML тяжелее парсить.