Thinking Differently About Messaging
First Published Thursday, 16th July 2009 12:24 am from Real-Time Innovations (RTI) : Rick Warren
The opinions expressed by this blogger and those providing comments are theirs alone, this does not reflect the opinion of Automated Trader or any employee thereof. Automated Trader is not responsible for the accuracy of any of the information supplied by this article.
You may have heard system
architects talking about "data-centric
design," or you may have attended an href="http://www.rti.com/services/training.html">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 href="http://www.rti.com/mk/DDS.html">DDS says
"sample" where href="http://java.sun.com/products/jms/">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 href="http://www.rti.com/products/data_distribution/index.html">RTI
Data Distribution Service, which implements the href="http://www.omg.org/spec/DDS/Current">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 href="http://www.rti.com/products/data_distribution/RTIReal-TimeConnect.html">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 href="http://www.rti.com/products/jms/index.html">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, href="http://www.rti.com/services/architecture-study.html">consider
which paradigm will serve you best most often, and pick
the right tool for the job.
href="http://feeds.wordpress.com/1.0/gocomments/rtidds.wordpress.com/153/">
alt="" border="0"
src="http://feeds.wordpress.com/1.0/comments/rtidds.wordpress.com/153/"
href="http://feeds.wordpress.com/1.0/godelicious/rtidds.wordpress.com/153/">
alt="" border="0"
src="http://feeds.wordpress.com/1.0/delicious/rtidds.wordpress.com/153/"
href="http://feeds.wordpress.com/1.0/gostumble/rtidds.wordpress.com/153/">
alt="" border="0"
src="http://feeds.wordpress.com/1.0/stumble/rtidds.wordpress.com/153/"
href="http://feeds.wordpress.com/1.0/godigg/rtidds.wordpress.com/153/">
alt="" border="0"
src="http://feeds.wordpress.com/1.0/digg/rtidds.wordpress.com/153/"
href="http://feeds.wordpress.com/1.0/goreddit/rtidds.wordpress.com/153/">
alt="" border="0"
src="http://feeds.wordpress.com/1.0/reddit/rtidds.wordpress.com/153/"
/>
src="http://stats.wordpress.com/b.gif?host=blogs.rti.com&blog=7350090&post=153&subd=rtidds&ref=&feed=1"
/>
