WS-ReliableMessaging

O que é WS-ReliableMessaging?

WS-ReliableMessaging, conhecido pela sigla WS-RM, é um padrão aberto mantido pelo consórcio OASIS. Ele faz parte da família de especificações WS-*, criada para complementar o protocolo SOAP, muito usado na troca de mensagens em XML entre sistemas corporativos.

Seu objetivo é resolver um problema simples de entender: quando um sistema envia uma mensagem pela rede, nada garante que ela chegou. A conexão pode cair, o servidor pode reiniciar ou a resposta pode se perder no caminho. O WS-RM cria regras para que remetente e destinatário saibam exatamente o que foi entregue e o que precisa ser reenviado.

Como funciona o WS-ReliableMessaging?

O padrão define dois papéis: a origem (RM Source), que envia as mensagens, e o destino (RM Destination), que as recebe. Antes de começar, os dois abrem uma sequência, que funciona como uma conversa identificada por um código único.

Cada mensagem enviada recebe um número dentro dessa sequência. O destino devolve confirmações (acknowledgements) informando quais números já recebeu. Se algum número não for confirmado, a origem reenvia apenas aquela mensagem. Ao final, a sequência é encerrada formalmente.

Toda essa informação de controle viaja no cabeçalho da mensagem SOAP, separada do conteúdo de negócio. Assim, a aplicação continua tratando apenas os dados que importam, enquanto a camada de infraestrutura cuida da confiabilidade.

Quais garantias de entrega o WS-ReliableMessaging oferece?

A especificação descreve níveis de garantia que podem ser combinados: no máximo uma vez (a mensagem nunca é entregue em duplicidade, mas pode se perder), pelo menos uma vez (a mensagem sempre chega, mas pode chegar repetida) e exatamente uma vez (chega uma única vez, sem perdas nem duplicatas).

Há ainda a garantia de ordem, que assegura que as mensagens sejam entregues à aplicação na mesma sequência em que foram enviadas. Isso é importante quando a ordem muda o resultado, como em um cancelamento que só faz sentido depois da emissão correspondente.

O WS-ReliableMessaging é usado na emissão de notas fiscais?

Os web services das autoridades fiscais brasileiras, como os usados para NF-e, CT-e e MDF-e, são baseados em SOAP, mas em geral não exigem WS-ReliableMessaging. A confiabilidade nesses ambientes é obtida por outros mecanismos, como consulta de recibo de lote, consulta pela chave de acesso e controle de numeração.

Por isso, quem integra sistemas fiscais costuma aplicar os mesmos princípios do WS-RM por conta própria: identificar cada requisição de forma única, reenviar com cuidado em caso de falha e verificar o status antes de repetir uma emissão, evitando notas duplicadas.

Qual a diferença entre WS-ReliableMessaging e idempotência em APIs REST?

O WS-RM resolve a confiabilidade na camada do protocolo, com sequências e confirmações padronizadas entre os dois lados. Já em APIs REST, que normalmente usam JSON sobre HTTP, não existe um padrão equivalente tão difundido, e a confiabilidade é construída na aplicação.

Nesse modelo, usa-se idempotência (uma chave que impede que a mesma operação seja processada duas vezes), retentativas com backoff exponencial, filas e webhooks para avisar o resultado. O efeito prático é parecido: evitar perdas e duplicidades, mas com ferramentas mais simples e flexíveis.

Exemplos de WS-ReliableMessaging

• Um ERP legado integrado a um parceiro logístico via SOAP usa WS-ReliableMessaging para garantir que cada pedido de coleta chegue exatamente uma vez, mesmo com instabilidade na rede.
• Um banco configura WS-RM em seus serviços SOAP internos para que ordens de transferência sejam entregues na ordem correta e sem duplicidade entre sistemas de diferentes áreas.
• Uma equipe que migra uma integração SOAP para uma API REST de emissão fiscal substitui o WS-RM por chaves de idempotência e consulta de status, mantendo a garantia de não emitir a mesma nota duas vezes.
• Um desenvolvedor configura o WS-RM em um framework de web services Java para que mensagens não confirmadas sejam reenviadas automaticamente após uma queda do servidor de destino.