The essence of data centricity is that DDS knows what data it stores and controls how to share that data . Programmers using traditional message-centric middleware must write code that sends messages . Programmers using data-centric middleware write code that specifies how and when to share data and then directly share data values . Rather than managing all this complexity in the application code , DDS directly implements controlled , managed , secure data sharing for you .
QoS
DATA WRITER
DATA WRITER
QoS
QoS
DATA WRITER
QoS
DATA WRITER
QoS
DATA WRITER
FILTERS
TOPIC A
QoS
QoS
TOPIC B
DDS DOMAIN
TOPIC C
TOPIC D
QoS
QoS
FILTERS
DATA QoS READER
DATA READER
DATA READER
DATA READER
DATA READER
DATA READER
QoS
QoS
QoS
QoS
QoS
WHAT IS DDS ?
DDS provides QoS-controlled data-sharing . Applications communicate by publishing and subscribing to Topics identified by their Topic name . Subscriptions can specify time and content filters and get only a subset of the data being published on the Topic . Different DDS Domains are completely independent from each other . There is no data-sharing across DDS domains .
GLOBAL DATA SPACE
DDS conceptually sees a local store of data called the “ global data space .” To the application , the global data space looks like native memory accessed via an API . You write to what looks like your local storage . In reality , DDS sends messages to update the appropriate stores on remote nodes . You read from what looks like a local store .
Source |
Speed |
Power |
Phase |
WPT1 |
37.4 |
122.0 |
-12.20 |
WPT2 WPTN |
10.7
50.2
|
74.0 150.07 |
-12.23
-11.98
|
Inside a DDS domain the unit of information sharing is data-objects within Topics . The topic is identified by its name and the data-object by some ‘ Key ” attributes . This is similar to how key attributes are used to identify records in a Database . This figure is conceptual . DDS communicates peer-to-peer and does not require the data to be brokered by a server or cloud .
5