An earlier post of mine, href="http://blogs.rti.com/2010/08/16/the-data-centric-modus-operandi/">The

Data-Centric Modus Operandi, has garnered a

couple of good comments recently. I was in the process of

responding to one of them when it occurred to me that (1) a

response longer than the WordPress comment field probably

didn't belong there and that (2) more readers might

have the same question, and an answer in the comments

wouldn't be very visible. So here it is, my

feature-length response:

href="http://www.cyclops-software.nl/">Frans Ott

says:

Good piece of work

Rick! Does this mean that practising the DDS-perspective, I will

respect the business domain model more as it is? And that, as a

consequence, less domain-burden will be drawn into the

middleware?

This question

is an important and perceptive one. My answer has a couple of

parts.

First, DDS is not a panacea. Adopting

DDS but using it in the same way you used your old messaging

middleware can bring you incremental benefits in terms of href="http://www.rti.com/resources/product-tour/performance-scalability.html">performance,

scalability, and href="http://www.rti.com/resources/product-tour/system-architecture.html">flexibility.

But it cannot by itself provide you transformative benefits in

terms of time-to-market and long-term maintainability.

Those larger benefits accrue as you adopt data-centric

architecture - that is, as you

begin to model your business domain and tie your distributed

applications to that model instead of to each other. You can

start to do this with any middleware, not just with DDS, and

doing so will allow you to more smoothly integrate capabilities

over time without perturbing existing behavior. But when you use

a technology like DDS, which unlike other middlewares provides

functionality to directly support this type of architecture, you

get an additional benefit: the middleware can start to automate

things that you used to have to do yourself.

There's my second point: when you tell your

infrastructure what you're trying to do, it can help

you do it better. I used the word "model,"

which might sound frightening and esoteric. But everyone does

this anyway! They just don't call it that. When people

design a system in a message-centric way, they write long

documents (aka "models")

describing who has to send messages to whom, in what format, at

what times. Then they email these documents to each other and

implement the various components based on what the documents say.

In the process, they write a lot of code to encode and decode

data, validate it, monitor and respond to the system's

status, manage application state, and so on. And once

they've done all of this work, they plug their

components in and find out whether the documents had any

ambiguities in them and whether everyone has correctly

implemented all of those infrastructure pieces I

enumerated.

The truth is, from the point of

view of the real business logic, "the

middleware" isn't just a messaging or

data-distribution component purchased off the shelf. It also

includes all of the stuff your in-house infrastructure developers

had to build on top of that to make the applications work right.

A key innovation in DDS is the answer to this question: what if

we took a lot of the ad hoc content out of

all of those word-processing design documents and replaced it

with a formal structure that the off-the-shelf middleware could

understand? The answer is that the href="http://www.rti.com/resources/product-tour/recording-analysis.html">off-the-shelf

component can start to do a lot of what the in-house

"middleware-above-the-middleware" used to

have to do - based on configuration rather than on

custom code. The result is a more portable, interoperable system

of higher quality and performance that was developed and

integrated in less time. In other words: faster, cheaper,

better.

You can use DDS as just a fast,

interoperable way to send messages from here to there. Lots of

people do. But DDS can do more than that if you're

willing to design differently. DDS does for data in motion

something like what an RDBMS does for data at rest. It

can't make you create a good data

design. But if you teach it what your design is, it can help you

enforce that design, and it can reduce the amount of code you

have to write in between your "middle"ware

and your business logic.

rel="nofollow"

href="http://feeds.wordpress.com/1.0/gocomments/rtidds.wordpress.com/324/"> alt="" border="0"

src="http://feeds.wordpress.com/1.0/comments/rtidds.wordpress.com/324/"

/>

href="http://feeds.wordpress.com/1.0/godelicious/rtidds.wordpress.com/324/"> alt="" border="0"

src="http://feeds.wordpress.com/1.0/delicious/rtidds.wordpress.com/324/"

/>

href="http://feeds.wordpress.com/1.0/gofacebook/rtidds.wordpress.com/324/"> alt="" border="0"

src="http://feeds.wordpress.com/1.0/facebook/rtidds.wordpress.com/324/"

/>

href="http://feeds.wordpress.com/1.0/gotwitter/rtidds.wordpress.com/324/"> alt="" border="0"

src="http://feeds.wordpress.com/1.0/twitter/rtidds.wordpress.com/324/"

/>

href="http://feeds.wordpress.com/1.0/gostumble/rtidds.wordpress.com/324/"> alt="" border="0"

src="http://feeds.wordpress.com/1.0/stumble/rtidds.wordpress.com/324/"

/>

href="http://feeds.wordpress.com/1.0/godigg/rtidds.wordpress.com/324/"> alt="" border="0"

src="http://feeds.wordpress.com/1.0/digg/rtidds.wordpress.com/324/"

/>

href="http://feeds.wordpress.com/1.0/goreddit/rtidds.wordpress.com/324/"> alt="" border="0"

src="http://feeds.wordpress.com/1.0/reddit/rtidds.wordpress.com/324/"

/>

src="http://stats.wordpress.com/b.gif?host=blogs.rti.com&blog=7350090&post=324&subd=rtidds&ref=&feed=1"

width="1" height="1" />