Download presentation
Presentation is loading. Please wait.
1
Overview of the OMG Data Distribution Service
Douglas C. Schmidt & Jeff Parsons Professor of EECS Vanderbilt University Nashville, Tennessee
2
RT Info to Cockpit & Track Processing
Overview of the Data Distribution Service (DDS) DDS is an highly efficient OMG pub/sub standard e.g., fewer layers, less overhead Topic R Data Writer R Data Reader R Publisher Subscriber RT Info to Cockpit & Track Processing DDS Pub/Sub Infrastructure Tactical Network & RTOS
3
Overview of the Data Distribution Service (DDS)
DDS is an highly efficient OMG pub/sub standard e.g., fewer layers, less overhead DDS provides meta-events for detecting dynamic changes Topic R NEW TOPIC Data Writer R Data Reader R NEW SUBSCRIBER Publisher Subscriber NEW PUBLISHER
4
Overview of the Data Distribution Service (DDS)
DDS is an highly efficient OMG pub/sub standard e.g., fewer layers, less overhead DDS provides meta-events for detecting dynamic changes DDS provides policies for specifying many QoS requirements of tactical information management systems, e.g., Establish contracts that precisely specify a wide variety of QoS policies at multiple system layers HISTORY Topic R RESOURCE LIMITS Data Writer R S1 Data Reader R S2 S3 S4 S5 Publisher S6 Subscriber S7 LATENCY X S7 S7 S6 S5 S4 S3 S2 S1 COHERENCY RELIABILITY
5
Overview of the Data Distribution Service (DDS)
DDS is an highly efficient OMG pub/sub standard e.g., fewer layers, less overhead DDS provides meta-events for detecting dynamic changes DDS provides policies for specifying many QoS requirements of tactical information management systems, e.g., Establish contracts that precisely specify a wide variety of QoS policies at multiple system layers Move processing closer to data DESTINATION FILTER Topic R Data Writer R S1 Data Reader R SOURCE FILTER S2 S3 S4 S5 Publisher S6 Subscriber S7 TIME-BASED FILTER
6
DDS Architectural Elements
Data-Centric Publish-Subscribe (DCPS) The lower layer APIs apps can use to exchange topic data with other DDS-enabled apps according to designated QoS policies Data Local Reconstruction Layer (DLRL) The upper layer APIs that define how to build a local object cache so apps can access topic data as if it were local DDS spec only defines policies & interfaces between application & service Doesn’t address protocols & techniques for different actors implementing the service Doesn’t address management of internal DDS resources
7
DDS Application Architecture
{ The Application Application Application Application Application DLRL DLRL DLRL DLRL DCPS Communication
8
DDS Domains & Domain Participants
The domain is the basic construct used to bind individual applications together for communication Like a VPN Domain 2 Domain 3 2 Domain 1 3 1 1 Node Node Node 2 3 1 1 Node Node Node DomainParticipant
9
DCPS Entities DCPS Entities include Data can be accessed in two ways
Topics Typed data Publishers Contain DataWriters Subscribers Contain DataReaders DomainParticipants Entry points Data can be accessed in two ways Wait-based (synchronous calls) Listener-based (asynchronous callbacks) Sophisticated support for filtering e.g., Topic, Content-FilteredTopic, or MultiTopic Configurable via (many) QoS policies Topic Topic Topic Domain Participant Data Reader Data Writer Data Writer Data Reader Data Reader Data Writer Subscriber Publisher Subscriber Publisher Data Domain
10
QoS Policies Supported by DDS
DCPS entities (i.e., topics, data readers/writers) configurable via QoS policies QoS tailored to data distribution in tactical information systems Request/offered compatibility checked by DDS DEADLINE Establishes contract regarding rate at which periodic data is refreshed LATENCY_BUDGET Establishes guidelines for acceptable end-to-end delays TIME_BASED_FILTER Mediates exchanges between slow consumers & fast producers RESOURCE_LIMITS Controls resources utilized by service RELIABILITY (BEST_EFFORT, RELIABLE) Enables use of real-time transports for data HISTORY (KEEP_LAST, KEEP_ALL) Controls which (of multiple) data values are delivered DURABILITY (VOLATILE, TRANSIENT, PERSISTENT) Determines if data outlives time when they are written … and many more …
11
Best Effort Reliability QoS in DDS
QoS Reliability = BEST_EFFORT Subscriber Subscriber Publisher Subscriber Notification of new data objects timeout deadline time-based filter no notification notification time Very predictable Data is sent without reply Publishers and subscribers match and obey QoS Deadline policy settings Time-based Filter QoS policy gives bandwidth control
12
Reliable QoS in DDS QoS Reliability = RELIABLE
Topic R history Data Writer R S1 Data Reader R S2 S3 S4 S5 Publisher S6 Subscriber S7 S7 S6 S5 S4 S3 S2 S1 Ordered instance delivery is guaranteed
13
Tradeoff Between Reliability & Determinism
QoS Reliability = BEST_EFFORT Can’t have reliability and determinism. Best effort mode for streaming data. No retries of dropped packets. Minimizes latency. Reliable mode for commands & events. Retry dropped packets until timeout. Every packet received in order. Speculative cache mechanism. DDS reliability is tunable. Can be adjusted per subscription. X QoS Reliability = RELIABLE X X
14
All QoS Policies in DDS Deadline Destination Order Durability
Entity Factory Group Data History Latency Budget Lifespan Liveliness Ownership Ownership Strength Partition Presentation Reader Data Lifecycle Reliability Resource Limits Time-Based Filter Topic Data Transport Priority User Data Writer Data Lifecycle
15
Single vs. Multiple Domain Systems
16
Data Writers & Publishers
Data Writers are the primary access point for an application to publish data into a DDS data domain The Publisher entity is a container to group together individual Data Writers User applications Associate Data Writers with Topics Provide data to Data Writers Data is typically defined using OMG IDL It can therefore be as strongly or weakly typed as you desire
17
Data Readers & Subscribers
A Data Reader is the primary access point for an application to access data that has been received by a Subscriber Subscriber is used to group together Data Readers Subscribers & Data Readers can have their own QoS policies User applications Associate Data Readers with Topics Receive data from Data Readers using Listeners (async) or Wait-Sets (sync)
18
Types & Keys A DDS Type is represented by a collection of data items.
e.g. “IDL struct” in the CORBA PSM struct AnalogSensor { string sensor_id; // key float value; // other sensor data }; A subset of the collection is designated as the Key. The Key can be indicated by IDL annotation in CORBA PSM, e.g., #pragma DDS_KEY AnalogSensor::sensor_id It’s manipulated by means of automatically-generated typed interfaces. IDL compiler may be used in CORBA PSM implementation A Type is associated with generated code: AnalogSensorDataWriter // write values AnalogSensorDataReader // read values AnalogSensorType // can register itself with Domain
19
Topics A DDS Topic is the connection between publishers & subscribers.
A Topic is comprised of a Name and a Type. Name must be unique in the Domain. Many Topics can have the same Type. Provision is made for content-based subscriptions. MultiTopics correspond to SQL join Content-Filtered Topics correspond to SQL select. Domain ID 35 Topic name “MySensor” Type name “AnalogSensor” string sensor_id [ key ] float value
20
Topic-Based Publish/Subscribe
Pressure Temperature DataWriter is bound (at creation time) to a single Topic DataReader is bound (at creation time) with one or more topics (Topic, ContentFilteredTopic, or MultiTopic) ContentFilteredTopic & MultiTopic provide means for content-based subscriptions & “joins”, respectively
21
Subscription = Topic + DataReader
application Topic 2 Topic n Data Reader subscriber QoS
22
Content-based Subscriptions
ContentFilteredTopic (like a DB-selection) Enables subscriber to only receive data-updates whose value verifies a condition. e.g. subscribe to “Pressure” of type AnalogData where “value > 200” MultiTopic (like a DB-join operation) Enables subscription to multiple topics & re-arrangement of the data-format e.g. combine subscription to “Pressure” & “Temperature” & re-arrange the data into a new type: struct { float pres; float temp; };
23
DDS Content-Filtered Topics
Topic Instances in Domain Instance 1 Value = 249 Instance 2 Value = 230 Content-Filtered Topic Instance 3 Value = 275 Topic Instance 4 Value = 262 Filter Expression: Value > 260 Instance 5 Value = 258 Instance 6 Value = 261 Expression Params Instance 7 Value = 259 Filter Expression and Expression Params determine which Topic instances the Subscriber receives.
24
DDS MultiTopic Subscriptions
Domain Participant Domain Participant Data Reader Data Reader Data Reader Data Reader Subscriber Subscriber Subscriber MultiTopics can combine, filter, and rearrange data from multiple Topics.
25
Data Local Reconstruction Layer (DLRL)
Track Track 3D_Track DLRL Cache Track_Topic 3D -Track DCPS
26
Goals of DLRL Data Local Reconstruction Layer (DLRL) model is local to an application “Object-oriented” access to data Application developers can describe classes with their methods, data fields, & relations attach some of those data fields to DCPS entities manipulate these objects (i.e., create, read, write, delete) using native language constructs activate attached DCPS entities to update objects have these objects managed in a cache Like a mapping or binding (intuition only)
27
DLRL Objects DLRL objects are (native) language objects with:
data members and methods Only the data members are relevant to data distribution; they can be: attributes, i.e., values relations, i.e., reference other objects plain local data members (i.e., not known or involved in data distribution) are also supported DLRL classes can be organised by inheritance DLRL objects maps to one or more DCPS Topics
28
DLRL Object Examples
29
DLRL Radar Example Oid x y Class radar Oid comments Class index Oid z
Track x : real y : real comments [*] : string w : integer Track3D z : real Radar tracks a_radar * 0..1 Oid 1 2 x 100 102 y 200 201 TRACK_TOPIC Class Track Track3D radar 11 COMMENTS_TOPIC Oid 1 comments a comment another comment Class Track index 1 Oid 2 z 300 T3D_TOPIC Oid 11 RADAR_TOPIC R_Oid 11 RADAR_TRACKS_TOPIC T_Oid 1 2 T_Class Track Track3D index 1
30
Evaluating DDS Pros Low overhead & efficient use of transport bandwidth e.g., less features/overhead than CORBA in the main request path Dynamically scalable & highly flexible e.g., can receive notification about all sorts of meta-events, such as new topics, publishers, subscribers, etc. Supports one-to-one, one-to-many, many-to-one, & many-to-many communication Large number of configuration parameters & QoS policies that give developers extensive control of message transmission & reception Cons DDS is not well suited to request-reply services, file transfer, & transaction processing The data-distribution paradigm is not optimized for sending a request & waiting for a reply Implementations don’t yet cover the entire spec Lack of interoperability between different vendor’s implementations
31
Comparing CORBA with DDS
Distributed object • Client/server • Remote method calls • Reliable transport Best for • Remote command processing • File transfer • Synchronous transactions Distributed data • Publish/subscribe • Multicast data • Configurable QoS Best for • Quick dissemination to many nodes • Dynamic nets • Flexible delivery requirements DDS & CORBA address different needs Complex systems often need both…
Similar presentations
