Hi All,

Beside of getting the honor to post the very first topic in this forum, I'd like to tell you my personal experience with Data Distribution Service.

I started to get familiar with DDS about 5 years ago, around the time DDS evolved from a two-company-idea to an open standard backed up by the Object Management Group.

Over the years, I've been working with DDS more or less every day: dissecting its guts, writing applications at high level, and digging into transport and connection issues. All that experience gave me an interesting view on the product over the years, but I have to admit, at the beginning, I had quite hard time to understand what DDS was. I'm writing this post in the hope that it could help somebody that is going through the same questions I had.

My very first question was: why do I need it? I can already send data over TCP/IP, UDP/IP with few function calls that are available on all the platforms. Why bother?

Altough I could see the benefit of using a publisher-subscriber network middleware, I could not see why I should pay a vendor for letting me do what I can already do now for free right now... "I can do it with HTTP today"... or "I can use multicast over UDP as today"... why bother then?

The best answer to this question came when I was working on a prototype of an application to show a video stream captured from a series of cameras connected over the internet: by using the features of Data Distribution Service, I was able to implement extremely cool features to my application in a snap of a finger. Discovery of all the cameras, automatic recording of the video, debugging capabilities, performance, and others. All of that was only possible because of the long list of capabilities of DDS. Through a logical association of between DDS entities and my physical entities (the cameras and their features), I managed to add functionalty to my system like controlling the camera's PTZ (pan, tilt, zoom) from the remote application withouth the need of changing my existing infrastructure. Now by adding (not changing) few things here and there, a camera was also advertising its PTZ capabilities (through DDS). The application was now able to understand and enable the controlling buttons simply by reading this extra. I didn't need to modify my communication protocol, I didn't have to write code in the camera viewer on how different cameras implement the PTZ functionality.

Could I have done it without DDS? Sure yes, but how longer would have taken? How many times would I have to refactor my application every time I needed do add a new feature? Although you always need to have a design of what you're trying to achieve, if you use DDS for the communication part, chances are that you won't need to do too many refactoring or drastic modifications to your application over its lifespan. The money that you'll pay upfront for getting a commercial DDS implementation IS going to pay off... sooner than you think.

Another thought I had when I started to use DDS was about the feeling of not being in control of my application. Until then, I was used to write software where I am in total control (end-to-end) of what's under the hood... or, at least that is what I thought.

But then I started to realize the (huge) benefit of delegating the communication part of my application to somebody else: to an expert, to somebody that is very, very good at taking care of taking my data and delivering only to where is needed.

This is what everybody do at the end in real life: we delegate functions to somebody else. Potentially somebody that can achieve our goals in a better way and (often), in a shorter time. Think about delivering that Christmas gift to grandma: sure you can get in the car and drive to grandma... but isn't better to have a parcel service to do that, so you can focus on something else instead of spending hours behind a wheel? Don't you already rely on somebody else to do part of your job? You rely on your compiler to generate your application. You count on the memory allocation library to ensure the success of your product. You (almost) never doubt the scheduler of your OS.

Think of DDS as your preferred parcel service for your network needs. Something you can count on. Something that does only one job, and does it well.

So, coming back to my initial experience with DDS, time pass by and eventually I started to get very excited on the opportunities that Data Distribution Service would offer me. And like many other similar situations, the more I knew about all those features, the more possible applications I was coming up with. Clearly, eventually I reached its limits: a missing feature here, a better approach to an existing problem there,... Slowly all of that came along... but there was one thing that kept DDS running in my head: DDS is alive. It is not a dead standard a-la "take it or leave it". DDS is evolving, the community is expanding, and is becoming more and more powerful day by day.

At RTI we always strive for more. If any of our customer, or one of our engineer has a need for some features that could benefit others, we don't ignore it: our approach is to find a solution, implement it in our middleware, and attempt to push it to the standard, so other DDS users (that are not necessarily using our implementation), can benefit too. Other vendors has been following the same principles to different extent, but overall, the DDS community is dynamic, fast paced, and ready to listen to the input from the user's community.

So, in conclusion. If you are a little skeptical of DDS (like I was)... give it a try. Don't give up on it. You won't regret! And if you want to share your experience, this forum is here for that.

Fabrizio