“Machine-to-machine” intelligent systems, like navy combat ships or 500-turbine wind power arrays, face challenges not addressed by most enterprise networking software. Of the thousands of messaging protocol standards, two are becoming most important in this market: the Data Distribution Service (DDS), an international standard by the Object Management Group (OMG), and the Advanced Message Queuing Protocol (AMQP), managed by the Organization for the Advancement of Structured Information Standards (OASIS).
Table Of Contents
- Introduction
- How AMQP Works
- How DDS Works
- State Management
- Message-Centricity Versus Data-Centricity
- Standards
- Configuration
- QoS Control
- Performance
- Mediation And Routing
- What Makes Most Sense
- Connecting The Dots At C2
- References
Introduction
DDS is a data-centric middleware standard with roots in high-performance defense, industrial, and embedded applications. It can efficiently deliver millions of messages per second to many simultaneous receivers. A growing list of vendors provides DDS to thousands of demanding applications.
AMQP is message-centric middleware that arose from the banking industry. It can process thousands of reliable queued transactions. It also has multiple-vendor support and many successful applications.
DDS and AMQP are both messaging standards. Both tout interoperability, and both are used in mission-critical systems. Those new to the technologies can find the choice (or combination) confusing. In actuality, however, they are quite different, even complementary technologies. Their application areas overlap only rarely.
Related Articles
• M2M IWG Enables M2M Development With Open-Source Technologies
• Use Lua To Develop M2M Embedded Applications
• The Future is Here...M2M, Machines are Taking Over!
The right choice can make a dramatic difference. DDS provides the real-time, many-to-many, managed connectivity required by high-performance machine applications. AMQP focuses more on enabling fast and reliable business transactions. Choosing AMQP for a large-fanout use case, or picking DDS for transactional use, can result in complexity, abysmal performance, or even failure.
Thus, this is an important design choice. Application designers must understand the differences between AMQP and DDS, which include state management, message-centricity versus data-centricity, standards, configuration, quality-of-service control, performance, and mediation and routing.
How AMQP Works
AMQP structures communications as a publication to an exchange, routing between exchanges and queues, and then subscribing to queues (Fig. 1). Exchanges control where the messages go. For instance, they can simply pass messages to a single queue, distribute messages among multiple queues, duplicate every message into multiple queues, or deliver messages based on some pattern. Exchanges and queues live in a “broker.” The power of the broker is the flexibility in these delivery patterns, called “routing.” Routing is endemic to AMQP brokers. The level of indirection gives the model its core flexibility. (The newer OASIS specification, AMQP v1.0, does not specify broker behavior. It only describes base messaging and transaction wire protocols. However, the major implementations use this architecture, and it will eventually migrate to the specification as it matures.)
Communications from the publishers to exchanges and from queues to subscribers use TCP, which provides a strictly reliable point-to-point connection. Further, endpoints must acknowledge acceptance of each message. The standard also describes an optional transaction mode with a formal multiphase commit sequence. True to its origins in the banking industry, AMQP middleware focuses on tracking all messages and ensuring each is in fact delivered as intended, regardless of failures or reboots.
How DDS Works
DDS structures communications as reads and writes to a virtual “global data space.” To use it, you define a data model of named topics with specified data types. Then, the infrastructure controls how data is changed and accessed. A topic is akin to a database table and the type to its schema. Any fields in the type can be a key. DDS allows dynamic data model changes, which combine the benefit of structured data with easy system evolution.
Although DDS models all interactions as reads and writes to the global data space, data flows directly from publishers (producers) to subscribers (consumers). There is no broker. Instead, publishers and subscribers connect over a “databus.” A very extensive set of quality-of-service (QoS) parameters controls exactly how information flows from publishers and subscribers through the bus. The middleware matches publishers to subscribers based on their types, topics, and QoS. The result is fast, direct, controlled communications (Fig. 2).
DDS runs over many transports, including TCP, UDP (including multicast), shared memory, switched fabrics, and more. It does not depend on the underlying transport for reliability, instead implementing a configurable, per-stream reliability protocol.
State Management
AMQP arose from the banking industry. The key problem in many financial applications is maintaining accurate transaction histories such as what happened to a trade order or how much was deposited into an account. That’s why AMQP emphasizes the importance of never losing messages and knowing what happened to each. These designs assume the applications are managing the state in local storage. Brokers persist and relay information between the applications without knowledge or control of state.
Because of its roots in high-performance embedded systems, DDS emphasizes speed and scaling, timing control, and flexible delivery control. In direct contrast to AMQP, it strives to simplify applications by delegating much of the state management to the middleware.
Message-Centricity Versus Data-Centricity
The state management goals lead to an even more profound difference. AMQP is a message-centric protocol. DDS is data-centric. While both types of middleware serve to connect distributed systems, the approaches are quite different.
When you use a message-centric design, the unit of information exchange is the message itself. The infrastructure’s role is to ensure that messages get to their intended recipients. Like a file system, a message can include anything in any format. The infrastructure just passes the information around.
Data-centric technologies instead understand the data itself and can therefore manage different types of state behavior. The fundamental unit of communication is a data value. The infrastructure’s job is not to just deliver messages, but to ensure that all nodes have a synchronized and common understanding of the data’s value. Like a database, data-centric middleware understands message formats and enforces access rules.
This philosophical difference has many implications. In a nutshell, data-centric middleware offers better “fanout” scalability and better state management, at the cost of moving some complexity into the middleware. Data-centric systems excel at complex integration problems requiring clear architecture and lifecycle management. The analogy to a database is very apt here.
Standards
The nature of the standards involved is also quite different. AMQP is a wire-protocol specification. Its key goal is to enable interoperability between different implementations of the AMQP specification. System designers, then, can integrate modules built with different products.
AMQP does not consider the application programmer interface (API). Some implementations use Java Messaging Service (JMS), but this applies only to Java and is not tied directly to the protocol features.
On the other hand, DDS includes both wire and API specifications. The API specification allows many languages. Leading vendors support C, C++, Java, C#, Ada, Scala, Python, and more. Communications between languages, operating systems, and processor types are all transparent.
Using a standardized API implies that software is easily ported between vendor implementations. Consequently, users aren’t locked to a vendor, even for a single subsystem. Still, the DDS vendor community regularly tests wire interoperability with demonstrations involving increasingly sophisticated QoS control. Nine vendors have participated so far.
Configuration
A large distributed system may comprise thousands of applications, run on hundreds of computers, and pass millions of discrete pieces of information. Configuring a system like that can be a challenge. Somehow, each application must locate the information it needs, connect sources and sinks, and ensure proper communications.
AMQP systems approach this problem through brokers. Configuration is straightforward. Applications send to exchanges and subscribe to queues by using known names and broker/server addresses. This is simple, but it requires manual maintenance. It is also inflexible at run time.
By contrast, DDS uses an automatic “discovery” technology. Participants simply declare what information they know and what they need by type, topic, and QoS. A background “meta traffic” protocol then automatically connects sources to sinks. Configuration consists of simply informing all players of their potential peers. Runtime changes are natural and expected.
For instance, an AMQP system might publish “temperature” to the “environment” exchange. It has to know, through configuration, where the exchange resides. A DDS publisher would only declare that it publishes “temperature.” The middleware will then find all subscribers to “temperature” and make the appropriate databus contracts.
QoS Control
Perhaps the most distinguishing characteristic of DDS is its QoS matching system. The standard defines more than 20 QoS parameters, covering reliability, volatility, liveliness, resource utilization, filtering and delivery, ownership, redundancy, timing deadlines, and latency. Participants “offer” QoS capabilities that subscribers can “request.” When the middleware matches a request to an offer, it creates a “contract” and ensures that both sides meet the contract.
This offers extreme flexibility. For instance, a single DDS publisher can send 1000 updates a second to a controller on a best-efforts basis, update a logging application in the background with 100% reliability, and multicast updates to another 50 nodes at only 10 times a second. As a data-centric technology, it knows what data is in an update. As a result, it can intelligently filter updates based on content, timing, or other criteria. This QoS control offers per-stream optimization of data flows, but there is a cost. QoS setting configuration requires understanding and care.
By contrast, AMQP uses TCP, which forces strict reliability. Every message put into the pipe must be delivered to the other end, even if it takes many retries. This is simple and handles many common cases, but it doesn’t allow timing control. That can be problematic when the system encounters a slow consumer. TCP’s single-lane traffic can back up many flows. AMQP also supports some other QoS settings, like persistence to disk, exclusivity, and deletion behavior, ensuring that messages are not lost in various failure scenarios.
Performance
Both systems offer peer-to-peer configurations and reasonable performance between nodes. Most AMQP designs use a broker to simplify configuration and routing. Some DDS designs are also brokered, or even optionally brokered, although this is not optimal for most applications.
DDS, with its support of reliable UDP multicast and flexible QoS, shines at “fanout” scalability. Top DDS implementations can deliver hundreds of thousands of messages (or more with batching) to thousands of recipients per second. Timing control also makes DDS uniquely suited for real-time systems.
AMQP doesn’t compete with this fast data distribution, but it does offer configurations that aren’t practical with DDS. For instance, the exchange/queue design can easily handle load balancing by distributing messages that arrive at an exchange to one of several queues.
Queues themselves also offer “take once” semantics to multiple readers. Thus, large systems that must handle many messages across many servers are well served. Combined with the ability to track, persist, and ensure processing of each message, this is a powerful work-distribution technique.
Mediation And Routing
Connecting complex systems isn’t as simple as sending messages or sharing state with every node. Messages or state transitions must often be “routed,” or directed to the proper recipients.
As outlined above, AMQP offers routing as a fundamental part of the broker architecture. It supports several types of exchanges, including round-robin load balancing, duplication, and key or header pattern matching. DDS instead emphasizes direct, fast data flow. Routing is not considered in the standard.
Top DDS vendors do offer routing as an independent service. Implementing routing as a service permits functionality beyond simple message direction. This is especially true because data-centric middleware understands the message data types.
For instance, RTI’s Routing Service can select particular fields from a complex data structure, insert them into a different structure, and even perform transformations. The Routing Service then can act as a “guard,” exporting only the configured data from a complex system in a form usable by a different system (Fig. 3).
Mediation, or the process of translating between communication patterns like publish-subscribe to request-reply, is also important. Enterprise service buses (ESBs) offer this technology to the enterprise market. Similar technology is rapidly appearing in embedded and DDS designs as well. With mediation, a DDS router can connect multiple, different DDS domains or connect DDS domains to other technologies, even including AMQP.
What Makes Most Sense
These protocols have little in common and are about as different as protocols get, yet both seem to be useful in similar application areas. This has been an understandable source of confusion, but it doesn’t have to be! Let’s consider two systems that must coexist on a navy ship as an example.
A ship’s combat management system (CMS) coordinates many radars and sensors to find, classify, and track hundreds of fast-moving objects. This information feeds into operator displays, weapons targeting, and intelligent tactics algorithms. The CMS may comprise hundreds of independent, dynamic applications. Milliseconds, or even microseconds, count.
AMQP is out of place in this setting. The transaction mechanism that is so useful in financial trades gets in the way of informing many recipients about an imminent threat. For instance, a track management system would have to send independent confirmations to each subsystem.
Consider sending a transaction like this to dozens of stations: “There’s an incoming missile at these coordinates; do you agree? … Confirm.” If 20 applications needed this information, AMQP would send at least 40 messages, pausing between each to confirm reception. That’s no way to defend a ship.
On the other hand, DDS would simply multicast this information to every recipient in one message. Those few that needed reliable updates would be confirmed later. Other QoS concerns, like failover, redundancy, and liveliness, optimize the flow to ensure reliable operation, both in delivery and (importantly) timing.
As a result, only DDS is appropriate for these types of demanding, real-time applications. In fact, virtually all modern CMS designs use DDS, including Aegis, the carrier Ship Self Defense System (SSDS), the Littoral Combat Ship (LCS) CMS, Europe’s Tacticos, and the U.S. Navy’s new DDG-1000.
Analysis And Decision Support
On the other end of the spectrum, ships must also work within a complex human command chain. In this scenario, information from off-ship personnel, mission, and weather sources feeds into strategic command, situational awareness, and mission functions. The middleware must fuse this information, interact with map and mission databases, and drive displays that coordinate the various levels of command. These decision-support systems run on enterprise-class servers with only human-speed latency needs (seconds).
Analysis traffic must reliably connect commands and information to human decision makers. AMQP’s reliable-transaction semantics make it a natural fit. Routing the information throughout the hierarchies is simplified by the exchange concept, and easy load balancing helps support work division.
While DDS could be configured to handle this flow, data-centricity and real-time control impose a design and configuration burden that has little payoff. As a result of these constraints, presentation-layer analysis and decision systems can better fit the AMQP protocol.
Connecting The Dots At C2
This explanation makes the choice between DDS and AMQP sound easy, and it is easy at these extremes. However, these systems must connect into a single system-of-systems whole. They meet in the command and control (C2) subsystem. C2 systems merge fast data with human command. Pushing AMQP down into the CMS is not possible. Pushing DDS up into the decision system is not practical. The C2 system must somehow merge both.
So, how best to implement the C2 interface? Often, it isn’t obvious. The relatively new routing services, especially with mediation, offer a practical design option. The DDS databus is ideal for connecting systems at high speeds. With mediation, implementing this databus on the C2 side can make connecting AMQP-based services with the CMS easier. Also, this design permits control of the information flow into and out of the CMS, offering a natural security point.
So, these protocols can work well together. Unfortunately, many architects see their use as an exclusive choice. Even more unfortunately, the choice often comes down to what’s most familiar. That can lead to poor outcomes.
The bottom line is that AMQP is good at ensuring a message gets from point A to point B, while that simple use can seem complex in DDS. On the other hand, DDS simplifies making sure that points A, B, C, and D all have access to complex fast-changing data flows, a difficult task for AMQP.
Both protocols have strengths and weaknesses. The best solution is to learn both and use each where it is appropriate. When integrated solutions have varied needs, combining protocols with mediation and routing technology offers a clean path forward.
References
1. Object Management Group (OMG)
3. Organization for the Advancement of Structured Information Standards (OASIS)
Stan Schneider founded RTI to develop productivity tools for the real-time marketplace. He completed his PhD in electrical engineering and computer science at Stanford University. He holds a BS in applied mathematics (summa cum laude) and an MS in computer engineering from the University of Michigan. He also is a graduate of Stanford’s Advanced Management College.