Overview of the OMG Data Distribution Service

1
Overview of the OMGData Distribution Service
Douglas C. Schmidt Jeff Parsons
schmidt,parsons_at_dre.vanderbilt.edu http//www.dr
e.vanderbilt.edu/schmidt/
Professor of EECS Vanderbilt University
Nashville, Tennessee
2
Past RD Successes Platform-centric Systems
From this design paradigm
Air Frame

• Legacy DoD systems are designed to be
• Stovepiped
• Proprietary
• Brittle non-adaptive
• Expensive to develop evolve
• Vulnerable

Nav
WTS
AP
FLIR
GPS
IFF
Cyclic Exec
Problem Small changes can break nearly anything
everything
3
Past RD Successes Platform-centric Systems
and this operation paradigm

• Real-time QoS requirements for platform-centric
  DoD systems
• Ensure end-to-end QoS, e.g.,
• Minimize latency, jitter, footprint
• Bound priority inversions
• Allocate manage resources statically

Problem Lack of any resource can break nearly
anything everything
4
Past RD Successes Network-centric Systems
to this design paradigm

• Todays leading-edge DoD systems are designed to
  be
• Layered componentized
• More standard COTS
• Robust to expected failures adaptive for
  non-critical tasks
• Expensive to evolve retarget
• Vulnerable

Air Frame
AP
Nav
WTS
Event Channel
Replication Service
GPS
IFF
FLIR
Object Request Broker
Problem Unanticipated changes can break many
things
5
Past RD Successes Network-centric Systems
and this operational paradigm
Applications
Applications
Interceptor
Interceptor
Sys Cond
Sys Cond
Sys Cond
Sys Cond
Mechanism Property Managers


Workload Replicas
Workload Replicas
Connections priority bands
Connections priority bands
Local Resource Managers
Local Resource Managers
QoS Contracts
QoS Contracts
CPU memory
CPU memory
Network latency bandwidth
Network latency bandwidth
Endsystem
Endsystem
Adaptive Real-time Middleware
6
Past RD Successes Network-centric Systems
and this operational paradigm
Problem Network-centricity is an afterthought in
todays systems
7
New Demands on Enterprise DRE Systems

• Key challenges in the problem space
• Network-centric, dynamic, very large-scale
  systems of systems
• Stringent simultaneous quality of service (QoS)
  demands
• Highly diverse complex problem domains

8
Case Study QoS-enabled Publish/Subscribe
Technologies for Tactical Information Management
Feedback Control
Coordination Of Multiple UAVs
Dynamic Mission Replanning
Image Processing Tracking
DARPA PCES Capstone demo, 4/14/05, White Sands
Missile Range
9
Case Study QoS-enabled Publish/Subscribe
Technologies for Tactical Information Management
Feedback Control
Coordination Of Multiple UAVs
Dynamic Mission Replanning
Image Processing Tracking
Aspect Languages
Modeling Tools
Model Checking
Real-time JVMs
Real-time ORBs
10
Limitations with Demod PCES Information
Management Technologies

• Shooter information management was based on
  platform-centric Real-time CORBA Real-time
  CORBA Event Service
• Well-suited for point-to-point static pub/sub
  command processing over wireline networks
• e.g., statically provisioned QoS policies
• Poorly suited for dynamic pub/sub info
  dissemination to multiple nodes in MANETs
• e.g., too many layers, excessive time/space
  overhead, inflexible QoS policies pub/sub
  model, etc.

Problem Net-centricity is afterthought in
platform-centric technologies
11
Limitations with Demod PCES Information
Management Technologies
Track Processing

• C2 C4ISR information management based on J2EE
  Java Messaging Service (JMS)
• Best suited for operational enterprise
  environments
• e.g., large data centers connect via wireline
  networks
• Poorly suited for tactical environments
• e.g., lack of QoS policies RTOS integration,
  extremely high time/space overhead

Java Messaging Service
J2EE Middleware
Enterprise Network OS
Problem Enterprise technologies are ill suited
for tactical systems
12
Our RD Goal Evaluate QoS-enabled Info Brokering
for Tactical Systems

• Solutions must function properly where
• Communication bandwidth is limited/variable
• Connectivity is intermittent
• Connections are noisy
• Processing storage capacity are limited
• Power weight limits affect usage patterns
• Unanticipated workflows are common
• Dynamic network topology membership changes are
  frequent
• Ideally, solutions should be COTS, standard,
  integrate with heterogeneous legacy systems

Goal is better than best-effort, subject to
resource constraints
13
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
14
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
15
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

Topic R
HISTORY
RESOURCE LIMITS
Data Writer R
S1
Data Reader R
S2
S3
S4
S5
Publisher
Subscriber
S6
S7
LATENCY
X
S6
S5
S4
S3
S2
S1
S7
S7
COHERENCY
RELIABILITY
16
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
Subscriber
S6
S7
TIME-BASED FILTER
17
Promising ApproachThe OMG Data Distribution
Service (DDS)
Application
Application
read
write
write
Global Data Store
Application
write
write
Application
read
read
Application
Workload Replicas
Connections priority bands
CPU memory
Network latency bandwidth

• DDS provides flexibility, power, modular
  structure by decoupling
• Location anonymous pub/sub
• Redundancy any number of readers writers
• QoS async, disconnected, time-sensitive,
  scalable, reliable data distribution at
  multiple layers
• Platform protocols portable interoperable

18
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
• Doesnt address protocols techniques for
  different actors implementing the service
• Doesnt address management of internal DDS
  resources

19
DDS Application Architecture

The Application
Application
Application
Application
Application
DLRL
DLRL
DLRL
DLRL
DCPS
Communication
20
DDS Domains Domain Participants

• The domain is the basic construct used to bind
  individual applications together for
  communication
• Like a VPN

2
3
1
1
Node
Node
Node
3
2
1
1
Node
Node
Node
DomainParticipant
21
DCPS Entities

• DCPS Entities include
• 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 Writer
Data Reader
Data Writer
Data Reader
Data Reader
Data Writer
Subscriber
Publisher
Publisher
Subscriber
Data Domain
22
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

23
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

24
Reliable QoS in DDS
QoS Reliability RELIABLE
Topic R
history
Data Writer R
S1
Data Reader R
S2
S3
S4
S5
Publisher
Subscriber
S6
S7
S7
S6
S5
S4
S3
S2
S1
Ordered instance delivery is guaranteed
25
Tradeoff Between Reliability Determinism
QoS Reliability BEST_EFFORT

• Cant 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
26
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

27
Single vs. Multiple Domain Systems
28
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

29
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)

30
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 AnalogSensorsensor_id
• Its manipulated by means of automatically-generat
  ed 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

31
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
AnalogSensor
name
key
string
sensor_id
float
value
32
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

33
Subscription Topic DataReader
34
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 gt 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

35
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 gt 260
Value 258
Instance 5
Expression Params
Instance 6
Value 261
Instance 7
Value 259
Filter Expression and Expression Params determine
which Topic instances the Subscriber receives.
36
DDS MultiTopic Subscriptions
Topic
Topic
Topic
Topic
MultiTopic
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.
37
Example Create Domain Participant

• DomainParticipant object acts as factory for
  Publisher, Subscriber, Topic and MultiTopic
  entity objects

// used to identify the participant DomainId_t
domain_id ... // get the singleton factory
instance DomainParticipantFactory_var dpf
DomainParticipantFactoryget_instance () //
create domain participant from factory DomainParti
cipant_var dp dpf-gtcreate_participant
(domain_id,
PARTICIPANT_QOS_DEFAULT,
NULL)
38
Example Create Topic
// register the data type associated with the
topic FooDataType foo_dt foo_dt.register_type
(dp, Foo) // create a
topic Topic_var foo_topic dp-gtcreate_topic
(Foo_topic, //topic name
Foo, // type name
TOPIC_QOS_DEFAULT, // Qos policy
NULL) // topic listener
39
Example Create Subscriber and DataReader
// create a subscriber from the domain
participant SubscriberQos sQos dp-gtget_default_su
bscriber_qos (sQos) Subscriber_var s
dp-gtcreate_subscriber (sQos,
NULL) // create a data reader from the
subscriber // and associate it with the created
topic DataReader_var reader
s-gtcreate_datareader (foo_topic.in (),
DATAREADER_QOS_DEFAULT,
NULL) FooDataReader_var foo_reader
FooDataReader_narrow (reader.in ())
40
Example Create Publisher and DataWriter
// create a publisher from the domain
participant PublisherQos pQos dp-gtget_default_pu
blisher_qos (pQos) Publisher_var p
dp-gtcreate_publisher (pQos, NULL) // create a
data writer from the publisher // and associate
it with the created topic DataWriter_var writer
p-gtcreate_datawriter (foo_topic.in (),
DATAWRITER_QOS_DEFAULT,
NULL) // narrow down to specific data
writer FooDataWriter_var foo_writer
FooDataWriter_narrow (writer) // publish
user-defined data Foo foo_data foo_writer-gtwrite
(foo_data)
41
How to Get Data (Async Listener-based)
Listener_var subscriber_listener new
MyListener() foo_reader-gtset_listener(subscriber_
listener) MyListeneron_data_available(DataRead
er reader) FooSeq_var received_data
SampleInfoSeq_var sample_info
reader-gttake(received_data.out (),
sample_info.out (), ANY_SAMPLE_STATE,
ANY_LIFECYCLE_STATE) // Use received_data

42
How to Get Data (Sync Wait-based)
Condition_var foo_condition
reader-gtcreate_readcondition(ANY_SAMPLE_STATE,
ANY_LIFECYCLE_STATE)
WaitSet waitset waitset-gtattach_condition(foo_con
dition) ConditionSeq_var active_conditions Dura
tion_t timeout 3,0 waitset-gtwait(active_condi
tions.out (), timeout) ... FooSeq_var
received_data SampleInfoSeq_var
sample_info reader-gttake_w_condition(received_dat
a.out (),
sample_info.out (),
foo_condition) // Use received_data
43
Benchmark Scenario

• Two processes perform IPC in which a client
  initiates a request to transmit a number of bytes
  to the server along with a seq_num (pubmessage),
  the server simply replies with the same seq_num
  (ackmessage).
• The invocation is essentially a two-way call,
  i.e., the client/server waits for the request to
  be completed.
• The client server are collocated.
• DDS JMS provides topic-based pub/sub model.
• Notification Service uses push model.
• SOAP uses p2p schema-based model.

44
Testbed Configuration

• Hostname
• blade14.isislab.vanderbilt.edu
• OS version (uname -a)
• Linux version 2.6.14-1.1637_FC4smp
  (bhcompile_at_hs20-bc1-4.build.redhat.com)
• GCC Version g (GCC) 3.2.3 20030502 (Red Hat
  Linux 3.2.3-47.fc4)
• CPU info Intel(R) Xeon(TM) CPU 2.80GHz w/ 1GB ram

45
Test Parameters
// Complex Sequence Type struct Inner string
info long index typedef sequenceltInnergt
InnerSeq struct Outer long length
InnerSeq nested_member typedef
sequenceltOutergt ComplexSeq

• Average round-trip latency dispersion
• Message types
• sequence of bytes
• sequence of complex type
• Lengths in powers of 2
• Ack message of 4 bytes
• 100 primer iterations
• 10,000 stats iterations

46
Roundtrip Latency Results (1/2)
47
Roundtrip Latency Results (2/2)
48
Roundtrip Latency Results Analysis

• From the results we can see that DDS has
  significantly better performance than other SOA
  pub/sub services.
• Although there is a wide variation in the
  performance of the DDS implementations, they are
  all at least twice as fast as other pub/sub
  services.

49
Encoding/Decoding Benchmarks

• Measured overhead and dispersion of
• encoding C data types for transmission
• decoding C data types from transmission
• DDS3 and GSOAP implementations compared
• Same data types, platform, compiler and test
  parameters as for roundtrip latency benchmarks

50
Encoding/Decoding Results (1/2)
51
Encoding/Decoding Results (2/2)
52
Encoding/Decoding Results Analysis

• Slowest DDS implementation is compared with
  GSOAP.
• DDS is faster.
• Almost always by a factor of 10 or more.
• GSOAP is encoding XML strings.
• Difference is larger for byte sequences.
• DDS implementation has optimization for byte seq.
• Encodes sequence as a single block no
  iteration.
• GSOAP always iterates to encode sequences.
• Jitter discontinuities occur at consistent
  payload sizes.

53
Summary of DCPS features
DDS
subscribers
publishers
Information consumer subscribe to information of
interest Information producer publish
information DDS matches routes relevant info to
interested subscribers

• Efficient Publish/Subscribe interfaces
• QoS suitable for real-time systems
• deadlines, levels of reliability, latency,
  resource usage, time-based filter
• Listener wait-based data access suits different
  application styles
• Support for content-based subscriptions
• Support for data-ownership
• Support for history persistence of
  data-modifications

54
Data Local Reconstruction Layer (DLRL)
Track
Track
3D_Track
DLRL
Cache
Track_Topic
3D -Track
DCPS
55
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)

56
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

57
DLRL Object Examples
58
DLRL Radar Example
59
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 dont yet cover the entire spec
• Lack of interoperability between different
  vendors implementations

60
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