In some cases — like traversing wide-area networks — TCP support is really important. Network routers may not forward UDP packets at all, they may perform address translation, and/or they may require that “connections” be initiated first on one side of the network. That’s why RTI has been shipping TCP transport support for a while now, both as a native transport for application-to-application communication and with RTI Routing Service as a means to federate DDS systems (which internally may be using another transport such as UDP or shared memory). Today, that layering of RTPS on top of TCP is RTI-specific.

At the OMG technical meeting just concluded in Arlington, VA, RTI and others provided initial proposals for standardization of an interoperable TCP transport for DDS. RTI’s presentation in the OMG’s MARS group is available for OMG members. This will be an exciting extension of DDS interoperability — which now includes five implementations with proven records; look for another post on this — to the wide-area network. It’s still early — an RFP or RFC is yet to be issued — but expect to hear more in a couple of months.

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.

For those who weren’t there, I’ve posted a  short video excerpt along with a slide deck that describes the tested scenarios. (These were validated prior to the demo. Because of time constraints, not all were shown live.)

Note that the applications using each DDS implementation were communicating peer-to-peer over a WiFi network. There were no intermediate brokers, mediation applications, ESBs, servers, smoke or mirrors. The magic is all courtesy of the DDS Real-Time Publish-Subscribe (RTPS) wire interoperability protocol.

This was the fourth time RTI participated in a public interoperability demo. It was also the first time that four vendors participated. Prior demos included two or three vendors.

The latest two vendors to join implemented the DDS-RTPS protocol purely from the specification. They had not participated in its development. This is an excellent testament to the quality and precision of the standard.

• New C++ and Java Application Programming Interfaces (APIs) were recommended for adoption
• A DDS security Request for Proposals (RFP) was issued

New C++ and Java APIs

The new C++ and Java APIs are more user friendly and enhance source code portability between DDS implementations. They provide an alternative to the original DDS APIs, which were indirectly specified by mapping a UML model into the OMG Interface Definition Language (IDL) and then into a specific programming language (using standard IDL-to-language mappings).

The new APIs were created specifically for C++ and Java, not generated from IDL. Thus, they take better advantage of language-specific features and conventions. This makes them more intuitive and concise. The new APIs also improve portability by eliminating the indirection introduced by the IDL to language mappings. The new language bindings are concrete: there is no room for interpretation.

Existing DDS users do not need to worry about backward compatibility. RTI will support both the new and classic APIs. And, of course, applications using both APIs are fully interoperable thanks to the DDS wire interoperability protocol (DDS-RTPS).

DDS Security RFP

The DDS security RFP kicks off the process of defining standard Information Assurance (IA) extensions to DDS. This includes encryption, authentication, access control, labeling and tagging. Initial submissions are due in June 2011.

RTI is contributing a response to the RFP based on experience with our existing security capabilities and a prototype implementation. If you have input, please let us know.

Securty has been a major focus for RTI. We recently completed two security-related research contacts with the U.S. Office of the Secreteary of Defense (OSD), have a on-going contract with the U.S. Air Force, and are just beginning a new contract with the U.S. Navy.

DDS Interoperability Demo

Also at the OMG meeting this week, four vendors participated in a DDS interoperability demonstration. I’ll post more information on this in the next few days. [And here it is]

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.

The answers to these questions are becoming increasingly important as real-time systems scale up and are integrated into Systems of Systems. Without the right underlying architecture and technology, applications will fail to satisfy their performance objectives. For mission-critical systems, the consequences of this could be catastrophic. Integration costs could also explode if proprietary and stovepipe workarounds are required to compensate for limitations in the underlying integration infrastructure.

You can download the white paper here.

Check it out and let us know what you think. What does “Real-Time SOA” mean to you?

• 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.

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.

With the maturity and broad adoption of DDS, we are seeing a couple of trends.

• DDS is being used in larger and more geographically disperse systems
• Customers are moving to second-generation DDS based systems
• Users are integrating multiple systems that already deploy DDS as their underlying integration bus

To support these efforts, RTI recently introduced RTI Routing Service. RTI Routing Service provides a flexible solution for scaling DDS systems and for integrating disparate DDS applications. This includes:

• Applications that cannot directly communicate because they run on different networks (LAN and WAN), use different transport protocols (e.g., shared memory, IPv4 and IPv6), or are members of different security domains
• Applications that natively use different DDS data types, such as new and legacy applications, individual systems within a System of Systems, and applications that support different Communities of Interest (COI)

To learn how RTI Routing Service significantly reduces the costs of real-time system integration, upgrades and of implementing Cross-Domain Solutions (CDS), visit RTI’s web site or watch this video demonstration.