* A business perspective on the value of DDS: http://www.rti.com/docs/RTI_Data_Centric_Middleware.pdf

* DDS implementation best practices, including guidance on modeling your data: http://www.rti.com/docs/DDS_Best_Practices_WP.pdf

Enjoy.

For new systems and significant updates to existing systems, RTI frequently recommends a data-centric architectural approach as the lowest-risk path to success over the project lifecycle — in particular because of the “shared data requirement” you mention. The lifecycle includes developing and deploying an initial set of capabilities as well as the integration of new capabilities over time. The approach should be supported by appropriate standards-based technologies, DDS among them. I think this is what you’re getting at when you speak of “the right DDS design … for going DDS all the way.”

Other project and/or other managers will require a more incremental approach. Teams with expertise in a message-centric approach can use DDS in that way and quickly observe benefits in terms of CPU and network utilization, one-to-many scalability, and fault tolerance. They don’t need to go “all the way” in terms of refactoring their system design; they can see incremental gains based on their existing design. Case in point: one RTI customer recently ported an existing system from web-services-based messaging to DDS-based messaging and saw a 10x increase in data-processing capacity with 5x _fewer_ machines. This obviously represents a significant cost savings as well as a significant functional improvement.

RTI can help customers with DDS adoption, whether large or small, in several ways:

* Our Routing Service component (http://www.rti.com/products/dds/routing-service.html) can help you integrate DDS with other communication technologies you may have, such as legacy socket-based protocols or other middlewares. You can adopt DDS on a subsystem-by-subsystem basis; you don’t need a “big bang.”

* Our Message Service component (http://www.rti.com/products/jms/index.html) adapts DDS with the JMS API: engineering teams as well as software components that are JMS-ready can also be DDS-ready is short order.

* Our Professional Services organization (http://www.rti.com/services/) is available to help with architecture studies, design support, and even technology implementation.

I hope that helps put things in perspective. DDS has the potential to be transformative, but people considering adopting it shouldn’t fear that they _have to_ transform in order to take advantage of it. Adoption can be quite straightforward; just download and see for yourself: http://www.rti.com/downloads/dds.html.

Giving away a piece of the action will be felt in someone’s pocket, not? Some major application vendors that started their own middleware solution are, in my observations, a bit struggling in this new field of expertise.
Catching-up with new technology developments, attrackting new customers, etc are a push for middleware, while supporting the existing customerbase is, of course, got their first priority.

DDS seems to push the middleware in a stronger and more prominent midfield place.
I think, the rise of DDS will increase the pressure on the business and enterprise modellers, in order deliver the right design to a promissing model. And did we do a good modelling job so far? Did the ‘invisible middleman’ gained the trust by the desisionmakers?
Customers nowadays tend to choose for standards and out-of-the-box software. Still, modelling the customer’s domain is of major importance. Because, that’s also how we still keep up to new requirements and non-functional necessities.

After reading serveral DDS documents I think I got an understanding of where it’s aiming for.
But in order make DDS mainstream, we have to overcome some conflict’s of interest first. I think the key for succes lies in delivering the right DDS design; it’s this new deliverable we need to present to our managers in order to tempt them for going DDS al-the-way, don’t you agree?

OMG! I can’t believe you said that. Using an RTI IRAD license, I recently built and tested a simple adapter between our app layer and your product – only exposing the QoS features that we needed. In parallel, a colleague built a “free” homegrown contraption directly on top of (blech!) sockets using Boost.asio to lessen the effort. Early on, I encountered a mysterious “lost messages” problem at high topic rates that went undetected by both the DDS publisher and subscriber. After calling your support line, I solved the problem by simply changing the default history QoS “configuration” setting to “keep all history” on the publisher side so that fast writers wouldn’t overwhelm the transport layer – and the problem disappeared. Weeks and $$$ later, we’re still trying to solve the equivalent problem in our homebrew with “custom code” diddling socket buffer sizes in the bowels of the system. It makes me want to cry and wring some necks.

Old school people just don’t get it. It reminds me of the olden days where developers would write their own Rube Goldberg RTOS rather than shelling out some dough for a solid commercial product written by experts in the domain. Boo Hoo.

A “sample” describes the state of an object (instance) as it was observed by a particular party (data writer) as of a particular point in time. That point in time is reflected in the API by the “source time stamp” field of the “sample info” structure.

BTW, do you think topic “sample” should be a first class citizen in your bulleted list?