Data Centricity vs. Message Centricity

In this blog post, I would like to clarify the difference between data centricity and message centricity when it comes to middleware solutions.

Let’s consider DDS as an example of data-centric middleware and MQTT as an example of message-centric middleware. There are definitely other examples, and all middleware solutions have advantages and disadvantages. They are designed to tackle different use cases, and there is no one-size-fits-all solution.

DDS is a standards-based publish/subscribe integration infrastructure for critical applications of the Industrial Internet of Things (IIoT). It is neither just a middleware solution nor an SDK. One of DDS’s strengths is its data-centricity. MQTT, on the other hand, is a publish/subscribe integration infrastructure for commercial IIoT. Its strength is in its simple and lightweight messaging protocol designed for constrained devices. Both DDS and MQTT are designed for use cases that need to run under low bandwidth, high latency or unreliable networks.

To illustrate the difference between data-centricity and message-centricity, let’s consider the following two approaches to Calendaring, a common, everyday process:

Alternative Process #1 (message-centric):

1. Email: “Meeting Monday at 10:00.”
2. Email: “Here’s dial-in info for meeting…”
3. Email: “Meeting moved to Tuesday”
4. You: “Where do I have to be? When?”
5. You: (sifting through email messages…)

Alternative Process #2: (data-centric)

1. Calendar: (add meeting Monday at 10:00)
2. Calendar: (add dial-in info)
3. Calendar: (move meeting to Tuesday)
4. You: “Where do I have to be? When?”
5. You: (check calendar, contains consolidated state)

The difference between these two scenarios is “state.” In the data-centric approach, the infrastructure consolidates the changes and maintains them. DDS’s approach to implementing data-centricity allows applications to be integrated easily into the information data model without forcing the application developers to write serialization/de-serialization code, and without forcing them to maintain state or make custom mappings. DDS directly supports data-centric actions such as create, dispose and read/take.

Data types are captured in DDS as topics. Topics define a name, type (including a key) and Quality of Service (QoS) settings. Data instances are managed by topic keys. The rich set of QoS settings controls data availability (durability, lifespan, and history), delivery (reliability and ownership) and timeliness (deadline and latency) via XML profiles. This approach immensely reduces the amount of code written and maintained by application developers.

Below you will see how much code must be written to implement the above scenario by utilizing data-centric middleware solutions such as DDS versus message-centric middleware solutions such as MQTT. As seen below, in the case of MQTT, the application developer needs to maintain the code to create an application-defined Collection to hold agenda items, deserialize bytes in the message, insert or replace in the Collection and lookup in the Collection.

Using Data-Centricity: Rich QoS --> less code to maintain data state

QoS for topic (i.e. data type):

Code to maintain data state: none, as the middleware maintains data state:

1. create DDS DomainParticipant to join DDS Domain
2. with DomainParticipant, create DDS Topic "MeetingTopic" and DDS Subscriber
3. with Subscriber and MeetingTopic, create DDS MeetingTopicDataReader
4. when requested by user for agendaId:

        MeetingTopicDataReader.read(in agendaId,
        out {meetingId, meeting time, date}[])

Using Message-Centricity: Not-so-rich QoS --> more code to maintain data state

QoS for message:

Chose one of the three below:

• At most once. The message is delivered at most once, or it is not delivered at all.
  • QoS=0
• At least once. The message is always delivered at least once
  • QoS=1
• Exactly once. The message is always delivered exactly once
  • QoS=2

Code to maintain data state:

1. create MQTT Client to connect to server (IP address or host name) and port number
2. create application-defined Collection to hold agenda items
3. with MQTT Client, subscribe to “MeetingTopic”
4. when message received by MQTT Client:
   • invoke application code to deserialize bytes in message to get {agendaId, meetingId, meeting time, date}
   • insert or replace in Collection {meeting time, date} for agendaId, meetingId
   • when requested by user for agendaId:
   • lookup in Collection all {meetingId, meeting time, date} for agendaId

In this case, the application developer needs to maintain the code to create an application-defined Collection to hold agenda items, deserialize bytes in the message, insert or replace in the Collection and lookup in the Collection.

Learn More:

Autonomous Vehicle Production »

What is DDS? »

Connext DDS Pro »

Connext DDS Micro »

Connext DDS Cert »