Content deleted Content added
GoingBatty (talk | contribs) Added Template:Multiple issues and other General fixes |
|||
| (41 intermediate revisions by 29 users not shown) | |||
Line 1:
{{Short description|Object Management Group standard}}
{{third-party|date=July 2014}}▼
{{Multiple issues|
{{independent sources|date=July 2014}}
}}
The '''Data Distribution Service''' ('''DDS''') for real-time systems is an [[Object Management Group]] (OMG) [[machine-to-machine]] (sometimes called [[middleware]] or connectivity framework) standard that aims to enable [[Safety-critical|dependable]], [[Many-task computing|high-performance]], [[interoperable]], [[Real-time computing|real-time]], [[Scalability|scalable]] [[data exchange]]s using a [[publish–subscribe pattern]].
DDS addresses the real-time data exchange needs of applications
== Architecture ==
=== Model ===
DDS is a networking [[middleware]] that simplifies complex [[computer network programming|network programming]]. It implements a [[publish–subscribe pattern]] for sending and receiving data, events, and commands among the [[node (networking)|node]]s. Nodes that produce information (publishers) create "topics" (e.g., temperature, ___location, pressure) and publish "samples". DDS delivers the samples to subscribers that declare an interest in that topic.
DDS handles transfer chores: message addressing, [[serialization|data marshalling and
The DDS publish-subscribe model virtually eliminates complex network programming for distributed applications. {{citation needed|date=October 2019}}
DDS supports mechanisms that go beyond the basic publish-subscribe model. {{citation needed|date=October 2019}} The key benefit is that applications that use DDS for their communications are decoupled. Little design time needs be spent on handling their mutual interactions. In particular, the applications never need information about the other participating applications, including their existence or locations. DDS transparently handles message delivery without requiring intervention from the user applications, including:
* determining who should receive the messages
Line 18 ⟶ 23:
* what happens if messages cannot be delivered
DDS allows the user to specify [[quality of service]] (QoS) parameters to configure discovery and behavior mechanisms up-front. By exchanging messages anonymously, DDS simplifies distributed applications and encourages modular, well-structured programs. {{citation needed|date=October 2019}}
DDS also automatically handles hot-swapping redundant publishers if the primary fails. {{citation needed|date=October 2019}} Subscribers always get the sample with the highest priority whose data is still valid (that is, whose publisher-specified validity period has not expired){{citation needed|date=January 2024}}. It automatically switches back to the primary when it recovers, too{{citation needed|date=January 2024}}.
=== Interoperability ===
Both
DDS vendors participated in interoperability demonstrations at the OMG Spring technical meetings from 2009 to 2013.<ref name="2009DemoNotes">{{Cite web|url=http://www.omg.org/news/meetings/GOV-WS/pr/rte-pres/ddsi-demo.pdf|title=DDS Interoperability Demo|author=Angelo Corsaro, Gerardo Pardo-Castellote and Clark Tucker|date=August 12, 2009|publisher=Object Management Group|
During demos, each vendor published and subscribed to each other's topics using a test suite called the shapes demo. For example, one vendor publishes information about a shape and the other vendors can subscribe to the topic and display the results on their own shapes display. Each vendor takes turns publishing the information and the other subscribe.
Two things made the demos possible: the DDS-I or Real-Time Publish-Subscribe (RTPS) protocol,<ref name="RtpsRef">{{Cite web|url=http://www.omg.org/spec/DDSI-RTPS/|title=The Real-time Publish-Subscribe Wire Protocol DDS Interoperability Wire Protocol Specification (DDSI-RTPS)|date=
[[File:Notional OMG DDS Interoperability.jpg|thumb|upright=2.4|OMG Data Distribution Service interoperability]]
Line 43 ⟶ 48:
== History ==
Development of the DDS specification started in 2001
DDS is covered by several US patents,<ref>[https://
The DDS specification describes two levels of interfaces:
Line 51 ⟶ 56:
Other related standards followed the initial core document.
The Real-time Publish-Subscribe Wire Protocol DDS Interoperability Wire Protocol Specification ensured that information published on a topic using one vendor's DDS implementation is consumable by one or more subscribers using the same or different vendor's DDS implementations. Although the specification is targeted at the DDS community, its use is not limited. Versions 2.0 was published in April 2008, version 2.1 in November 2010,
DDS for Lightweight [[CORBA Component Model|CCM]] (dds4ccm) offers an architectural pattern that separates the business logic from the non-functional properties. A 2012 extension added support for streams.<ref>DDS for Lightweight CCM (dds4ccm), Version 1.1, formal/2012-02-01, February 2012, http://www.omg.org/spec/dds4ccm/1.1/PDF/</ref>
Line 59 ⟶ 64:
Extensible and Dynamic Topic Types for DDS (DDS-XTypes) provided support for data-centric publish-subscribe communication where topics are defined with specific data structures. To be ''extensible'', DDS topics use data types defined before compile time and used throughout the DDS global data space. This model is desirable when static type checking is useful.<ref>Extensible and Dynamic Topic Types for DDS (DDS-XTypes), 1.0, formal/2012-11-10, November 2012, http://www.omg.org/spec/DDS-XTypes/1.0/PDF</ref>
A [[Unified Modeling Language]] (UML) profile specified DDS domains and topics to be part of analysis and design modeling.<ref>UML Profile for Data Distribution, version: 1.0, http://www.omg.org/cgi-bin/doc?ptc/10-05-17.pdf
An [[interface definition language]] (IDL) was specified in 2014 independently from the [[Common Object Request Broker Architecture]] (CORBA) specification chapter 3. This IDL 3.5 was compatible with the CORBA 3 specification, but extracted as its own specification allowing it to evolve independently from CORBA.<ref>{{Cite web |title= Interface Definition Language (IDL), Version 3.5 |date= March 1, 2014 |publisher= OMG |url= http://www.omg.org/spec/IDL35/3.5/ |
Other protocols to be mentioned are: DDS-XRCE (DDS for eXtremely Resource Constrained Environments), this specification protocol allows the communication between devices of limited resources, like microcontroller for example and a DDS network. It makes publishing and subscribing to topics via an intermediate service in a DDS ___domain possible <ref>{{Cite web|title=About the DDS For Extremely Resource Constrained Environments Specification Version 1.0|url=https://www.omg.org/spec/DDS-XRCE|access-date=2021-03-12|website=www.omg.org}}</ref> and DDS-RPC (RPC Over DDS) which defines Remote Procedure Calls. These provide a bidirectional request/reply communication and determine distributed services, and are detailed using a service interface. It also supports both synchronous and asynchronous method invocation.<ref>{{Cite web|title=About the RPC Over DDS Specification Version 1.0|url=https://www.omg.org/spec/DDS-RPC/1.0|access-date=2021-03-12|website=www.omg.org}}</ref>
Starting with DDS version 1.4 in 2015, the optional DLRL layer was moved to a separate specification.<ref>{{Cite web |title= DDS Data Local Reconstruction Layer (DDS-DLRL) |date= April 2015 |url= http://www.omg.org/spec/DDS-DLRL/ |accessdate= November 9, 2016 }}</ref>▼
▲Starting with DDS version 1.4 in 2015, the optional DLRL layer was moved to a separate specification.<ref>{{Cite web |title= DDS Data Local Reconstruction Layer (DDS-DLRL) |date= April 2015 |url= http://www.omg.org/spec/DDS-DLRL/ |
== See also ==
Line 72 ⟶ 79:
== References ==
{{Reflist|30em}}
{{Ambient intelligence}}
| |||