Q: How do you position OpenSplice DDS against RabbitMQ

RabbitMQ is an implementation of Advanced Message Queuing Protocol (AMQP). We occasionally encounter customers evaluating DDS against AMQP and other technologies, so we produced a white paper that compares and contrasts the technologies (see Internet of Things and Industrial Internet Messaging Technologies Comparison Whitepaper.

Yet for OpenSplice DDS and RabbitMQ, it is foremost comparing DDS with messaging where the most significant differences are that:

•  DDS is data-centric and has many benefits that equal those of ‘typical’ databases:
  • data has structure which is understood by the database
  • it follows a relational scheme, where topics have key-attributes that can represent relationships
  • like databases, DDS also decouples the lifecycle of the data from that of the applications i.e. late-joining applications will be transparently provided with non-volatile data
•  DDS thus ‘understands’ the data and its lifecycle and is ‘aware’ of content, age, lifecycle and thus allows for a higher abstraction level
  • so allowing applications to query on content (content-filters, queries) and lifecycle (first/last appearances, read/not-read)
  • this ability to rely on the right-data to be available at the right time and being able to query on content and/or lifecycle allows for simpler applications
• DDS also understands the non-functionals of the data at a fine-grained data-centric level
  • so well beyond basic ‘plumbing’ choices of best-effort vs. reliable communication
  • it’s aware of urgency, importance, persistency, frequency etc. and with that can balance between high-volume and low-latency (supported via the 22 QoS of DDS
  • resulting again in reduced system-complexity as applications can benefit from delivery and availability guarantees of the data even ‘when the going gets tough’ (i.e. in environments where resources are scarce and need to be arbitrated)
• DDS promotes state-based systems built-up from simple/autonomous applications
  • with strong (robustness) semantics for (eventual-)consistency
  • and offering decoupling in location, time and frequency to application
  • as well as offering high-level API’s to obtain data-of-interest and/or (optional-) awareness of other/remote entities (by both statuses as well as standardized meta-data i.e. built-in-topics)
• Even when combining AMQP/RabbitMQ with GPB, it’s still a plain messaging paradigm rather than a database paradigm
  • of course you can build (messaging-)systems with that, it’s just a different abstraction-level, resulting also in different type-of-system with different ‘sensitivities’ w.r.t. complexity and robustness
  • w.r.t. GPB, we have customers that prefer protobuf over IDL and for that we are offering  GPB-integration (currently for C++ and Java) where we realized a seamless-integration into our DDS where we retain the middleware content-awareness and related features for utilizing key-fields and filtering (by adding annotations for keys and query-able fields)
• Also, with DDS you can benefit from:
  • A decentralized broker-less deployment model, in turn resulting in lower latencies than a brokered approach such as RabbitMQ and eliminating the single point of failure that can result from such an architecture
  • Support for UDP and TCP, where RabbitMQ supports just TCP
  • Dynamic and automatic discovery, where IP address resolution of the server is not required

Summarizing, OpenSplice DDS will equate to less code at the application level and in turn:
– reducing scope for application programming errors
– reducing development time
– reducing the amount of code to maintain
– reducing time to market

So, it is OpenSplice’s  data-centricity and the related complexity-reduction for application (by offering data-centric patterns) in the first place and furthermore QoS-driven fault-tolerance and real-time behavior that make it different from any message-queuing technology.