Q: How do you position OpenSplice DDS against other DDS implementations?

Most (commercial) DDS-implementations are OK and for many use cases are sufficiently ‘technically equal’ (w.r.t. properly implementing the DDS-specification), so that decisions are often made based on non-technical reasons such as locality, support, relationships and licensing, etc.

Yet it’s good to know where we do differ which is, at least partly, based on our ‘heritage’ (i.e. where did we come from, what markets were we operating in, etc.):

• OpenSplice DDS comes from the mission-critical systems world where fault-tolerance & robustness is key as well as long-term-support and guaranteed backwards-compatibility
  • these requirements have driven several architectural choices that are unique to our implementation, such as:
    • the (optional) decoupling of applications and the (networking-part-of-the) middleware so that application misbehavior will be confined
    • and at the same time this ‘federated architecture’ allows the middleware to schedule network-traffic for a complete machine based on importance/urgency of the data-items themselves rather than relating that to the scheduling of individual applications
    • thus, allowing for balancing between high-volume/low-latency also in case of resource-shortage
  • furthermore our ‘durability’ implementation is fundamentally different from that of all other DDS implementations in that
    • our distributed durability-services transparently maintain a consistent set of TRANSIENT/PERSISTENT data for (especially state-based) applications to rely on
    • where network-outages (so-called ‘split-brain’) can be overcome by automated recovery (so-called ‘merge-policies’) to restore a consistent/coherent state

Also, there are differences related to:

• Implementing the full specification
  • OpenSplice DDS is currently the only DDS implementation that implements GROUP coherency (i.e. allow for ‘transactional’ behavior of publishers that write coherent sets of multiple topic-types)
  • and also have a unique capability for (late-joining) applications to obtain a relevant subset of available historical data (filtered on a combination of volume, content or age)
• Performance
  • Scalability
    • OpenSplice DDS is known for its extreme nodal-scalability. Our ability of single-copy-data-sharing (i.e. regardless of the number of applications there’s always only 1 copy of date ‘in-memory’, or in our case in ‘shared-memory’) allows for hundreds of applications on a single machine
    • w.r.t. system/network-scalability, we have a unique capability in OpenSplice DDS that allows for a dynamic (i.e. transparent) mapping between logical DDS-partitions and pre-configured (in the configuration xml-file) so-called ‘NetworkPartitions’ which are basically multicast groups) and with that can exploit the networkbandwidth more effectively
  • Latency and jitter
    • our shared-memory based architecture offers the lowest possible latency (few microseconds within a node)
    • our federated ‘network-scheduling’ capabilities (i.e. exploiting a single ‘arbiter’ for the network that is decoupled from the applications) allow to balance all traffic for/by all applications on a processing-node based on the importance (transportpriority) and urgency (latency-budget) of each sample and with that offer true end-to-end priority-awareness and related bounded latency and jitter
  • Fault tolerance
    • our ability to decouple application-lifecycle from middleware-lifecycle (by exploiting our ‘federated deployment mode’) assures that misbehaving applications (that are either ‘overactive’ and could ‘blow-up’ the whole system, or are ‘under-active’ and could trigger system-wide retransmits of reliable data) have bounded-impact, something essential for mission/business-critical systems
    • furthermore our ‘network-scheduling’ capabilities allow for definition of traffic-shaped priority-lanes thus assuring that low-priority-traffic can never monopolize high-priority traffic
    • finally, as explained already above, our capabilities to recover from network-disconnects and retain a coherent durable-data-set are instrumental in offering fault-tolerant systems

Furthermore, it’s good to realize the following:

• our OpenSplice DDS team was heavily involved in building these mission-critical systems with OpenSplice for world-leading combat-management-system (CMS) providers in the past which gives us a unique capability ‘beyond’ knowing about middleware that extends to how to build these types of mission critical
  systems in a proper/data-centric way
• and also, our (regression-)test and QA process still reflect that focus in that we currently run over 20,000 requirements- as well as design-based tests each night to assure our product’s quality and (backwards-)compatibility over a vast range of machines