SOAP vs Protobuf

A codificação de mensagens é uma peça de um grande quebra-cabeça que dita o comportamento e as intenções de uma aplicação.

Por exemplo, se você fosse criar um aplicativo de chat em tempo real para pessoas, deveria escolher uma ferramenta que faça esse trabalho. Você poderia seguir o caminho tradicional e começar com uma API REST que funciona sobre HTTP e enviar mensagens enquanto consulta dados o tempo todo para receber novas mensagens. Mas, como você perceberá, é um desperdício de recursos e não escala. Então, você começaria a procurar protocolos que permitam comunicação em tempo real, como websockets, MQTT, STOMP... que são amplamente utilizados na internet, cada um com um caso de uso específico, alguns sendo usados mais para a web, outros para IoT, redes, jogos, e a lista continua.

Você também perceberá que cada componente que você escolhe interage com diferentes tipos de tecnologias, então você acabará com uma pilha de ferramentas que atacam o problema que você está tentando resolver, a partir de uma perspectiva específica.

A forma como um protocolo codifica mensagens não é apenas um detalhe técnico — é a diferença entre uma conexão lenta e pesada em recursos e uma conversa eficiente e moderna de IoT/M2M. No TR-069 e no TR-369, a codificação de mensagens é um dos principais passos evolutivos.

Gosto de uma imagem específica que traduz as diferenças de comunicação em ambos os padrões:

Créditos à QA Cafe equipe pela imagem ☝️

SOAP XML

Quando o TR-069 foi introduzido no início dos anos 2000, a internet era um lugar muito diferente. Eu não estava lá para ver como era, mas tenho certeza de que muitas pessoas que estão lendo isso estavam. Este post no blog viaja no tempo e pode dar uma boa ideia de como as coisas eram naquela época.

Quando o CWMP surgiu, a decisão foi usar SOAP (Simple Object Access Protocol) com XML como formato de mensagem, fornecendo uma estrutura de envelope rígida para solicitações e respostas, enquanto o XML armazena os dados reais em um formato legível por humanos baseado em tags.

Essa abordagem trouxe vantagens claras: interoperabilidade entre sistemas, mensagens autodescritivas que qualquer pessoa poderia ler e entender, e ferramentas maduras para análise e processamento.

Veja como é uma mensagem TR-069:

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:cwmp="urn:dslforum-org:cwmp-1-0" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:schemaLocation="urn:dslforum-org:cwmp-1-0 ..schemaswt121.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <soap:Header/>
 <soap:Body soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
   <cwmp:GetParameterValues>
     <ParameterNames soapenc:arrayType="cwmp:ParameterValueStruct[1]>
       <string>InternetGatewayDevice.</string>
      </ParameterNames>
   </cwmp:GetParameterValues>
 </soap:Body>
</soap:Envelope>

Protocol Buffers (Protobuf)

De acordo com o próprio site do protobuf:

Protocol buffers são o mecanismo da Google, neutro em relação a linguagem e plataforma, extensível para serializar dados estruturados – pense em XML, mas menor, mais rápido e mais simples. Você define como deseja que seus dados sejam estruturados uma única vez e, em seguida, pode usar um código-fonte gerado especialmente para ler e gravar facilmente seus dados estruturados de e para uma variedade de fluxos de dados, utilizando diversas linguagens.

Ao contrário do XML, as mensagens Protobuf são compactas e serializadas em binário, o que reduz drasticamente o tamanho da mensagem e a sobrecarga de processamento em dispositivos que agora podem ler e gravar mensagens mais rapidamente, usar menos memória e enviar dados pela rede com o mínimo de largura de banda.

XML e JSON são formatos legíveis por humanos, serializados como texto. Se você abrisse uma sessão TR-069 via HTTP (sem TLS) e inspecionasse os pacotes, conseguiria ver as mensagens e entender seu conteúdo. O TR-369, por outro lado, usa codificação binária, portanto suas mensagens não são diretamente legíveis. Felizmente, esses pacotes são destinados a computadores, não a humanos 😅.

Veja como é uma mensagem TR-369:

{
   "header": {
       "msg_id": "b7dc38ea-aefb-4761-aa55-edaa97adb2f0",
       "msg_type": 1
   },
   "body": {
       "request": {
           "get": {
               "paramPaths": [
                   "Device."
               ],
               "maxDepth": 1
           }
       }
   }
}

Veja como isso aparece na rede:

0a03312e30120e6f6b746f7075732d302d6d7174741a0e70726f746f3a3a6f6b746f7075733adb0112d8010a280a2465346462383464362d653930662d346264392d626366372d316331633338343935623162100112ab010aa8010aa5010a1e4465766963652e446576696365496e666f2e4d616e7566616374757265720a1b4465766963652e446576696365496e666f2e4d6f64656c4e616d650a214465766963652e446576696365496e666f2e536f66747761726556657273696f6e0a1e4465766963652e446576696365496e666f2e53657269616c4e756d6265720a1e4465766963652e446576696365496e666f2e50726f64756374436c6173731501000000

Existe uma vantagem em usar Protobuf que considero incrível: você define um arquivo ".proto" especificando as estruturas das mensagens e esse arquivo gera a mesma estrutura em diferentes linguagens! Isso significa que, mesmo com projetos, equipes e aplicações diferentes, você garante que todos se entendam sempre. Em um cenário real, você tem OBUSPA (desenvolvido em C) mantendo a mesma estrutura de mensagens e contratos do Oktopus (desenvolvido em Go). Ele evita implementações inadequadas do padrão definido.

O impacto

A escolha da codificação é mais do que apenas um detalhe; ela afeta diretamente o desempenho do dispositivo, a eficiência da rede e a escalabilidade. Com XML, cada mensagem é prolixa, contendo tags repetidas e estruturas baseadas em texto que aumentam o tamanho das mensagens e exigem CPU e memória significativas para o processamento. Para uma única solicitação TR-069, isso pode não parecer crítico, mas ao gerenciar milhares ou milhões de dispositivos, o impacto cumulativo na largura de banda, latência e carga do servidor torna-se significativo. O Protobuf, por outro lado, é rápido e leve.

Essa redução no overhead traduz-se em benefícios reais: os dispositivos respondem mais rápido, os provedores de internet podem enviar comandos ou coletar telemetria sem congestionar as redes, e a escalabilidade para milhões de terminais torna-se viável. Essencialmente, o Protobuf não apenas codifica dados; juntamente com a especificação TR-369, ele desbloqueia eficiência, telemetria, capacidade de resposta e a possibilidade de gerenciar dispositivos em larga escala.