SOAP vs Protobuf

The encoding of messages is one piece of a big puzzle that dictates the behavior and intentions of an application.

For instance, if you'd build a real-time chat application for people, you should pick up a tool that does this job. You could go the old way and start with a REST API that works on top of HTTP and send messages while polling data all the time for receiving new messages. But, as you will realize, it's a waste of resources and does not scale. Then you'd start searching for protocols that allow real-time communication, like websockets, MQTT, STOMP... which are widely used on the internet, each of them with a specific use case, some being used more for the web, others for IoT, fabrics, gaming, and the list goes on.

You will also realize that each component you choose interacts with different types of technologies, so you will end up with a stack of tools that attack the issue you're trying to solve, from a specific perspective.

The way a protocol encodes messages isn’t just a technical detail — it’s the difference between a chatty, resource-heavy connection and an efficient, modern IoT/M2M conversation. In TR-069 and TR-369, message encoding is one of the key evolutionary steps.

I like one specific image that kinds of translate communication differences in both standards:

Credit to QA Cafe team for the image ☝️

SOAP XML

When TR-069 was introduced in the early 2000s, the internet was a very different place. I was not there to see what it looked like, but I'm sure a lot of people reading it were. This blog post travels back in time and can give a nice idea of what it was like back then.

When CWMP emerged, the decision was to use SOAP (Simple Object Access Protocol) with XML as the messaging format, providing a strict envelope structure for requests and responses, while XML stores the actual data in a human-readable, tag-based format.

This approach brought clear advantages: interoperability across systems, self-describing messages that anyone could read and understand, and mature tooling for parsing and processing.

Here is what a TR-069 message looks like:

<?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)

According to the own protobuf website:

Protocol buffers are Google’s language-neutral, platform-neutral, extensible mechanism for serializing structured data – think XML, but smaller, faster, and simpler. You define how you want your data to be structured once, then you can use special generated source code to easily write and read your structured data to and from a variety of data streams and using a variety of languages.

Unlike XML, Protobuf messages are compact and serialized in binary, which drastically reduces message size and parsing overhead on devices that can now read and write messages faster, use less memory, and send data over the network with minimal bandwidth.

XML and JSON are human-readable formats, serialized as text. If you were to open a TR-069 session over HTTP (without TLS) and inspect the packets, you could actually see the messages and understand their contents. TR-369, on the other hand, uses binary encoding, so its messages aren’t directly readable. Fortunately, these packets are meant for computers, not humans 😅.

Here is what a TR-369 message looks like:

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

Here is what it looks like in the wire:

0a03312e30120e6f6b746f7075732d302d6d7174741a0e70726f746f3a3a6f6b746f7075733adb0112d8010a280a2465346462383464362d653930662d346264392d626366372d316331633338343935623162100112ab010aa8010aa5010a1e4465766963652e446576696365496e666f2e4d616e7566616374757265720a1b4465766963652e446576696365496e666f2e4d6f64656c4e616d650a214465766963652e446576696365496e666f2e536f66747761726556657273696f6e0a1e4465766963652e446576696365496e666f2e53657269616c4e756d6265720a1e4465766963652e446576696365496e666f2e50726f64756374436c6173731501000000

There is one advantage of using Protobuf, which I think is incredible: you define a ".proto" file specifying message structures, and this file generates the same structure in different languages! This means that even if you have different projects, teams, and applications, you can make sure they're always understanding each other. In a real-world scenario, you have OBUSPA (built with C) keeping the same messaging structure and contracts of Oktopus (built with Go). It avoids bad implementations of the defined standard.

The Impact

The choice of encoding is more than just a detail; it directly affects device performance, network efficiency, and scalability. With XML, each message is verbose, containing repeated tags and text-based structures that inflate message sizes and require significant CPU and memory to parse. For a single TR-069 request, this might not seem critical, but when managing thousands or millions of devices, the cumulative impact on bandwidth, latency, and server load becomes significant. Protobuf, on the other hand, is fast and lightweight.

This reduction in overhead translates to real-world benefits: devices respond faster, ISPs can push commands or collect telemetry without congesting networks, and scaling to millions of endpoints becomes feasible. Essentially, Protobuf doesn’t just encode data; together with the TR-369 specification, it unlocks efficiency, telemetry, responsiveness, and the ability to manage devices at a massive scale.