Thinking Differently About Messaging 7

You may have heard system architects talking about “data-centric design,” or you may have attended an RTI training class and heard one of us use that term. Is data-centricity just a new buzzword to make messaging seem cool again? No indeed!

Message-centric design and data-centric design are similar, but they also differ in important ways. Let’s start with some terminology. There’s a reason why DDS says “sample” where JMS says “message”: those words are intended to suggest a different mental model to you.

Data-Centric Thinking

When you hear the word “sample,” imagine some data value (perhaps the temperature in a certain place) being published periodically. Those values describe a single logical data object — an “instance” in DDS terms — whose state changes over time. Or think of subsequent frames of a movie: the movie is a single logical object, and you view slices of it one after another. In other words, in a data-centric design, as the system’s state changes, it uses the middleware to publish that state directly.

Therefore, a data distribution middleware — such as RTI Data Distribution Service, which implements the DDS specification — needs to understand what that state is and under what circumstances it should be published. That’s why RTI Data Distribution Service allows you to describe your application’s own data types to the middleware (using XML, IDL, or a programmatic API): your application stores its state using those types, so the middleware needs to understand them in order to publish that state. That’s also why DDS-compliant middleware provides applications with such extensive control over which data should be published where and when, including filters on data contents and update rates, duration- and depth-based time-to-live rules, data reliability and availability contracts, deadline enforcement, and so on. A data-centric system uses its network middleware as a lightweight cache to manage its state, thereby replacing programmatic application logic with declarative descriptions of its delivery obligations and expectations.

Message-Centric Thinking

In contrast, a messaging middleware provides no facilities for state maintenance or management. Instead, the system maintains that state externally to the middleware, and when it changes, it sends “messages” about those state changes. The recipient(s) of those messages then decide if and how to update their own state. Because only the application-level logic “above” the middleware has access to its state and knows when and how to update it, there’s no need for the middleware to understand the contents of messages. Messaging middleware implementations therefore typically don’t support content-aware message handling and provide more limited control over delivery contracts than do data distribution middleware implementations.

Choices, Choices

Of course, the lines between these communication paradigms are often blurred, and many complex systems will use both in different places. For example, you may use RTI Data Distribution Service to distribute your data, but use a relational database to maintain and manage that data, and then use a product like RTI Real-Time Connect to make sure changes that occur on one side are automatically propagated to the other. Or you may implement a data-centric system with RTI Data Distribution Service but view that data, in certain subsystems, through a message-centric API with RTI Message Service.

Just as you can write procedural code in C++ or Java by choosing not to use certain object-oriented features of those languages, you can implement a message-centric system using a data distribution middleware by simply choosing to limit the capabilities of that middleware that you leverage. And just as you can write object-oriented code in C if you put your mind to it, you can implement a data-centric system using a messaging middleware. But to get the most value from your middleware, and save yourself the most effort, consider which paradigm will serve you best most often, and pick the right tool for the job.

7 comments

  1. Pingback: The Data-Centric Modus Operandi « Blogs from RTI

  2. Hi Pavan,
    Thanks for your interest. You can find product information about RTI Data Distribution Service at http://www.rti.com/products/dds/index.html. If you’re interested in comparing our product to other middleware technologies, you may be interested in this third-party research into the total cost of system development and implementation, which found a substantial ROI advantage in RTI technology: http://www.rti.com/mk/commercial-middleware-vs-roll-your-own.html.

    I hope that helps,
    – Rick

    Like

  3. Is data-centric the architecture where we have one database, and pub & Sub write and read from it?
    and if we consider over DDS we can distribute data, then don’t you think in a distributed environments we may need to distribute processes? and how this can be done with RTI-DDS?

    thanks

    Like

  4. Hello Haidar,

    The system you describe, with a single database connected over a network using publish-subscribe middleware can absolutely be data-centric if the network representation of the data is designed properly. However, as you are pointing out, when you have the capability to publish and subscribe to data as it is changing in the real world, you have the ability to distribute the processing of the data which allows you to build even more interesting systems.

    In many systems, there is some data that must be stored in a database, and other data that is temporary. RTI Connext can be used to transport both types of data, which allows you to process that data in more than one application.

    A small summary of how to use RTI Connext to send data to the processes that need it is in this video (DDS in a nutshell) – http://www.youtube.com/watch?v=u-saogMmKOo

    Thank you!
    Rose

    Like

    • thank you rose for the prompt reply,
      but
      1) if there is a database to write data in, where this database should be? in each node? or once central database where all read/wrtie from?!
      2) can we classify RTI-DDS as one of the message-oriented middlewares? or not?
      3) so you confirm with RTI-DDS we can distribute data and processes?
      4) finally to classify RTI-DDS, can i say:
      it is a Messaging middleware – Data-Centric Architecture – uses Publish Subscib – more!?

      i am little bit confused about the different available middlewares, and i am trying to classify them in groups and to which umbrella belongs,

      thanks again

      Like

  5. Hello Haidar,

    Data Centricity does not require a database, and as a matter of fact, RTI Connext DDS does not use a database.

    RTI Connext DDS provides:
    – Publish-subscribe communication patterns
    – Request-response communication patterns
    – Data centricity
    – Peer-to-peer communication
    – Automatic discovery
    – You can use message-oriented patterns, but that is not our focus

    Here are two documents that might help to clarify further.

    This has a good comparison between message-oriented middleware and data-centric/publish-subscribe middleware, along with the features that DDS provides:
    http://www.rti.com/whitepapers/Is_DDS_for_You.pdf

    This document describes our implementation of data-centricity – publish/subscribe middleware along with an in-memory data management/caching layer.
    http://www.rti.com/products/dds/data-centric-pub-sub.html

    I think that it might be a good idea to have a phone conversation to discuss this in more detail. Can you e-mail me with your phone number and time zone?

    Rose Wahlin
    rose@rti.com

    Like

Submit a comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s