Standards-based DDS technology is a great way to implement this approach: it’s fast, dynamic, and fault-tolerant. The cost savings can be dramatic: one large distributed asset-tracking program replaced their proprietary middleware with DDS and realized a 90%+ savings while increasing capacity, performance, and robustness.

Check out the video.

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 performance, scalability, and 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 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.

Data distribution is about observing a changing world. A system whose communication is based on this paradigm tends to become data-centric: it becomes more concerned with modeling the first-class concepts of its business domain and less concerned with managing second-class “who-told-whom-to-do-what” middleware concepts like queues and messages. Along the way, it enjoys the benefits of decreased coupling and improved reliability, scalability, and performance.

Data Distribution and Its Kin

Classically, messaging is an evolution of the remote method invocation (RMI) paradigm — an attempt to make that paradigm less coupled and more scalable by making it asynchronous. A message says “I tell you to do this.” When compared with RMI, “I” and “you” are more abstract, both in identity and multiplicity, and the request can be queued for processing at a later time or by another party without making the sender wait. These are improvements, but the interaction remains coupled, because the roles of “I” and “you” (often in the guises of “client” and “server” or the trendier “service consumer” and “service provider”), as well as the intention of what action should be performed, are still very much in play.

Eventing, like data distribution, is preoccupied with changes to the world. An event says “I changed in this way.” It reduces coupling by entirely removing both the recipient of that information and any notion of intention from you business logic and your mental model; who might receive an event, and what they might choose to do as a result, are not the business of the event source. But state management remains a problem, because in order to understand the change that occurred, all recipients must have an up-to-date understanding of the state of the world prior to the latest event — “the price went up by a dollar” doesn’t do me any good if I don’t know what the price was before. This temporal coupling means that every recipient must process every event in order, whether those events are interesting or not, just in case the interpretation of a subsequent interesting event should happen to require the state established by a previous otherwise-uninteresting one.

The resulting processing and state management are complex and expensive. As a mitigation, they are frequently factored out of the applications that need the data and into state-management “servers” that “clients” must query using a message-centric or even RMI-based approach — a huge regression in engineering practice! The system becomes complicated by the presence of multiple interacting communication paradigms, and the servers (which serve no business role) introduce performance and fault-tolerance choke points.

A data-centric architecture eliminate these problems by simplifying the interactions. A data sample says simply “the world is like this.” It thereby eliminates coupling not only in terms of source, recipients, and their intentions, but also in terms of time. There’s no longer any need for recipients to process or store information they don’t care about, because samples don’t implicitly encompass previous samples. Therefore it becomes perfectly reasonable for one observer to examine the state of the world every second, or every minute, or every hour — and for another to observe every single intermediate state, even if those states change from one to the other many times a second.

Modeling the World with DDS

A set of DDS entities, and the data they distribute and manage, define a view into this changing “world.”

• A “domain” defines the boundaries of the world, the set of information that a collaborating group of applications might find interesting. A “domain participant” defines the presence of some application in that world; it is the data-centric analogue to what is frequently known as a “connection” in the messaging middleware.
• A “type” is a structural description of some part of the world — for example, an Antelope is brown in color and has four legs and two horns; a Ferrari is red in color and has four wheels and two seats. A type has a formal definition, usually (though not always) in a declarative language like XSD or OMG IDL, and it implies a corresponding definition in the target programming language.
• A “quality-of-service” (QoS) definition defines the fidelity with which some party/parties is/are able to describe the world. For example, will the description contain every state the world passes through or only a subset? Will observers have access to new states of the world only, or will they be able to see previous states as well? If the latter, how far back will those previous states go?
• A “topic” defines some aspect or subset of the world consisting of similar objects. As such, it combines a type, which defines the structure of those objects, with a QoS definition, which defines how they can be observed to change.
• An “instance” defines a single object in the group defined by a topic. For example, a topic may be used to distribute the positions of airplanes as detected by a radar. Each plane would be an instance. All radar tracks have the same structure (type) and are updated in the same way (QoS). But they are also distinct from one another: it matters whether the plane at a given location happens to be American Airlines flight 123 or Delta flight 456.
• A “data writer” defines a source of information about a particular subset of the world (topic). As such, it may override the QoS of its topic — multiple parties may provide information about the same part of the world but with different degrees of fidelity.
• A “data reader” defines an observer of a particular subset of the world (topic). As such, it may also override the QoS of its topic. Furthermore, it may only be able and/or interested to observe certain states of the world. For example, it may only be interested in airplanes flying over a particular geographic area or in stocks trading at over $20/share.

By creating a data reader with a certain QoS definition, an application makes an affirmative statement that it wishes to observe a certain portion of the world under a certain set of circumstances. For example, it may state that it is interested in observing the most recent five states (samples) to the objects (instances) in its part of the world (topic), but it doesn’t need to process changes more frequently than once every second.

This statement is one of interest only; it in no way requires the observer to actually observe a certain set of samples in a certain way or within a certain period of time. On the one hand, the observer may choose to be notified asynchronously of every new sample and to respond to it immediately. On the other, it may “go away” to other business and return hours later; when it does, it will find the most recent five samples of each instance, occurring no more frequently than once every second, waiting for it. In the mean time, DDS will have taken care of all of the necessary data reception, filtering, and replacement in order to make that happen.

DDS’s ability to combine notification and lightweight caching — in effect, to maintain an application’s observed state of the world on its behalf — is something no other standards-based technology provides. Developers of data-centric systems reap the benefits: higher performance and scalability, greater tolerance to dynamic network conditions, and ultimately improved ROI and time-to-market.

• Perhaps the most important milestone for DDS followers was the recommendation for adoption of the new specification Extensible and Dynamic Topic Types for DDS (sometimes abbreviated “DDS-XTypes”). I wrote about DDS-XTypes late last year; it will make it much easier for DDS users to upgrade and evolve their systems over time. It will also enable whole new categories of plug-and-play tools and integration components — such as database connectors, recorders, and bridging/routing services — to be developed in a way that’s portable and interoperable across DDS implementations, increasing the size and diversity of the DDS marketplace and increasing competition. RTI was a lead author of this specification, and a number of the capabilities defined in it are available in pre-standard form in RTI Data Distribution Service today.
• The meeting also saw the presentation of three initial submissions, representing six different companies, to the Web-Enabled DDS RFP that was released last year. (The previous link is only accessible to OMG members; sorry. When it’s finished, the specification will be publicly available.) This very strategic initiative will produce a specification for the integration of systems based on DDS with those based on web technologies. For the first time, it will be possible for SOAP- or REST-based client applications to consume data flowing along a DDS data plane, and for them to provide services back to applications in that plane, in a standards-based way with COTS technology. RTI is currently developing an implementation of this technology in parallel with the standard; this component, called RTI Web Integration Service, will be included in the Professional and Elite Editions of RTI Data Distribution Service. You can see a video demo of DDS-web integration, based on a pre-release version of this component, on YouTube.
• Work continues on further improving the portability and usability of DDS implementations with updated C++ and Java API bindings. The improved C++ APIs are already in the revised submission stage, and we expect them to be adopted within the next small number of OMG meetings. The improved Java APIs will be presented as initial submissions at the next OMG meeting, to be held in Minneapolis in June. RTI’s initial proposal will be based on the DataDistrib4J APIs, which we have made available in open source.
• Finally, the group had a lively discussion of DDS security, especially with respect to data tagging and labeling. We expect to take these discussions to a formal RFP in the coming months.

I think it’s a testament to the strength of the DDS ecosystem that while its core standards remain stable and support significant real-world deployments, at the same time the depth and breadth of that ecosystem continues to grow. It’s an exciting time to be involved with this technology.

We’re dropping that time again. Recently, we rolled out an additional new capability on our web site: the RTI Product Tour. (At least for now, the Product Tour is also linked from the www.rti.com home page.) The Product Tour covers many of the components of RTI Data Distribution Service in a streamlined way with embedded screenshots and demonstration videos. Instead of downloading the software, installing it, and reading through the documentation, you can just click on a couple of five-minute videos to get some basic information with a lot less effort. (We hope that afterward you’ll still want to download the software to try it for yourself!)

So if you’re interested in RTI’s decoupled system architecture, industry-leading performance and scalability, built-in value-added features like recording and analysis, or powerful connectors to enterprise and legacy systems, check out the RTI Product Tour. It’ll just take a few minutes.

Click here for more articles on DDS. Click here for whitepapers on DDS, including a link to the Embedded Market Forecasters study that finds DDS middleware from RTI improves ROI when compared with other alternatives.

Many developers suffer from confusion with respect to the differences between mutexes and semaphores. Michael Barr of Netrino provides solid information in his article Mutexes and Semaphores Demystified. My summary: mutexes protect shared resources by enforcing mutual exclusion; semaphores should be used for signaling across tasks.

Niall Cooling of Feabhas provides a longer discussion in two parts:

1. Mutex vs. Semaphores – Part 1: Semaphores
2. Mutex vs. Semaphores – Part 2: The Mutex

Cooling focuses especially on the problems that arise when developers use semaphores where they should rather use mutexes. In particular, he discusses accidental lock release, various causes of deadlock, and priority inversion. (The latter is of special interest to developers of real-time software.)

Although semaphores and mutexes are critical concurrency-control structures, the APIs to use them unfortunately differ from platform to platform with respect to both form and function. At the end of his Part 2, Cooling briefly summarizes some of the differences between the semaphore and mutex APIs of several operating systems. This section will be of interest to anyone developing systems that will be ported across very different platforms. Chris Simmonds goes into more depth, with respect to Linux in particular, in his article Mutex mutandis: understanding mutex types and attributes posted on The Inner Penguin.

One of the really powerful things about DDS is that it brings to distributed systems the same kind of type safety that you’ll find in local applications. In addition to reducing errors, this deep knowledge of data types can improve performance and resource usage by reducing the number of data copies in the system and easing integration with other field- and type-aware technologies, including relational databases and even Microsoft Excel.

But as systems evolve over time, type definitions can evolve too, and it’s important that applications that are already deployed don’t break as the types used by new applications change. It’s also desirable to ease the development of infrastructure or cross-cutting components — like tools, recorders, generic data routing and transformation facilities, and others — that shouldn’t be tied to specific data types. DDS users have been solving these problems in a variety of ways for some time, and some implementations address them already, but it’s time for a standardized solution.

To that end, the OMG is working on a new specification, Extensible and Dynamic Topic Types for DDS, that will provide additional capabilities for the following:

• A clarified and extended type system that incorporates keys and extensibility as first-class concepts
• An API for the definition of new data types at run-time without code generation
• A reflective API for the construction, inspection, and manipulation of data samples based on dynamic type definitions
• The ability to define data types declaratively using not only OMG IDL but XML and XML Schema (XSD) as well for easier integration with enterprise systems

The proposed specification will be discussed at the OMG Technical Meeting next month and some outstanding open issues addressed. I expect the proposal to be voted on and approved at a subsequent meeting not far in the future.

If your organization is an OMG member, you can access the in-progress specification proposal documents yourself.

I don’t know a thing about cars, so it seemed to me that there was a flaw in this plan.

“What if,” I asked, feeling like a jerk already, “it turns out that my [part] isn’t broken after all, and the problem is caused by something else? Then I’ll have a brand new [part] on my hands that’s of no use to me.”

The mechanic looked frustrated. “Well, I could run an electrical test first. We charge $35 for that. Do you want me to do it that way?”

I resisted the urge to retort, “You’re the mechanic; you tell me!”

The thing is, he really wanted me to pay him for a part, and I really wanted to pay him to make my car work. If I’d been an expert myself, and knew in detail what my problem was, and how to fix it, I would have been very happy to buy a part. I bought one in any case and crossed my fingers — I got lucky this time. But next time, I’ll be looking for someone else to help me, someone more able to speak to me in my language.

I’m sure there’s an analogy to software in there somewhere.

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.