Skip to the main content.

Did you know?

 

RTI is the world’s largest DDS supplier and Connext is the most trusted software framework for critical systems.

Tiered-Support-Plan-DatasheetTiered Support Plans

Our Professional Services team brings extensive experience to train, problem-solve, mentor, and accelerate customer success.

Learn more

Developers

From downloads to Hello World, we've got you covered. Find all of the tutorials, documentation, peer conversations and inspiration you need to get started using Connext today.

Try the Connectivity Selection Tool ⇢

Resources

RTI provides a broad range of technical and high-level resources designed to assist in understanding industry applications, the RTI Connext product line and its underlying data-centric technology.

Company

RTI is the largest software framework company for autonomous systems. The company’s RTI Connext product enables intelligent architecture by sharing information in real time, making large applications work together as one.

News & Events
Cooperation

2 min read

Data Centricity vs. Message Centricity

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

ddsqos

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 »