High-level introduction to the OMG Data Distribution Service (DDS) standard and how it provides values beyond what is possible with traditional messaging middleware such as JMS or AMQP.

1. DDS:
The data-centric future
beyond message-based integration
February 2011
Gerardo Pardo-Castellote, Ph.D.
Co-chair OMG DDS SIG
Chief Technology Officer, Real-Time Innovations, Inc.
© 2010 Real-Time Innovations, Inc.

2. Systems that interact with the Real World
 Must adapt to changing environment
 Cannot stop processing the information
 Live within world-imposed timing
Beyond traditional interpretation of real-time
© 2010 Real-Time Innovations, Inc. 2

3. Challenge:
More Data, More Speed, More Sources
TRENDS:
 Growing Information Volume
 Lowering Decision Latency
 Increasing System Availability
 Accelerating technology insertion and
deployment
Next-generation systemsneeds:
 Performance
 Scalability
 Robustness
 Integration & Evolution
© 2010 Real-Time Innovations, Inc. 3

4. “Real World” Systems are integrated using a
Data Model
 Grounded on the ―physics‖ of the problem domain
– Tied to the nature of the sensors and real objects inthe system
(vehicles, device types, …)
 Provides governance across disparate teams & organizations
– Central authority can define data model necessary for interoperability
 Increased decoupling from use-cases and components
– Avoids over constraining applications
 Open, Evolvable, Platform-Independent
– The use-cases, algorithms might change between missions or
versions of the system
App App App
Realizing this data-model requires a middleware infrastructure
© 2010 Real-Time Innovations, Inc. 4

5. Data Centricity 101

6. Everyday Example: Calendaring
Alternative Process #1:
1. Email: ―Meeting Monday at 10:00.‖
2. Email: ―Meeting moved to Tuesday.‖
3. Email: ―Here’s dial-in info for meeting…‖
4. Rick: ―Where do I have to be? When?‖
5. Rick: (sifting through email…)
6

7. Example: Calendaring
Alternative Process #2:
1. Calendar: (add meeting Monday at 10:00)
2. Calendar: (move meeting to Tuesday)
3. Calendar: (add dial-in info)
4. Rick: ―Where do I have to be? When?‖
5. Rick: (check calendar)
7

8. What’s the Difference? State.
 Things have attributes “State” (“data”) is a
and characteristics snapshot of those
– The meeting will run 1:00–2:00
in the conference room. attributes and
– My friend’s phone number is characteristics.
555-1234 and he’s currently
grooming his cat.
– The car is blue and is traveling
north from Sunnyvale at 65 Best Practice: operate
mph. on state directly, not
 …whether they exist in dialogs about state.
the real world, in the
computer, or both
 …whether or not we
observe or acknowledge
them

9. Data-Centricity =
the part of you care about
Describing the world
as it is
at a certain point in time
Implication: State of the world can be maintained by
infrastructure, not each app

10. Not Data-Centricity =
Saying anything else…
 ―Hey you: go do this.‖
 ―The thing changed in this way.‖
Implication: State must be inferred, reconstructed, managed by
each app
(Sometimes called “message-centricity”: focus on what’s said
vs. what is)

11. Why is it better to just describe the world?
 Reconstructing the state of the world is
hard
– Must infer based on all previous messages
– Maintaining all these messages is expensive
– Each app makes these inferences
=> duplicate effort
 People make mistakes
– Many copies of state => may be different =>
bugs
vs.
– Uniform operations on state => fewer bugs

12. So it’s “better.” Who cares?
 Faster to implement
=> Save time and money
 Easier to integrate and update
=> Protect your investment
 More reliable systems
=> Protect your business
12

13. Before We Forget: the Definition
For example, data
structures in IDL file.
A data-centric architecture: Calendar Event =
•Start Time
1. …is based on a data model that is: •Duration
– Appropriately documented— •Location
i.e. understandable by humans
•Organizer
– Formally defined—
i.e. understandable by machines
– Discoverable—i.e. can be found during execution
2. The data model is independent of any domain-
specific functionality / application.
– i.e. made of nouns, not verbs
3. The (instantiated) data model is the only
authoritative source of state in the system.

14. DDS Lets You Observe a Changing World
Other data-centric technologies:
– Databases: SQL
– Web: HTTP (mostly)
 …assume the world changes slowly
Not scalable
 …use network resources inefficiently 100 apps => 100x load
 …are highly centralized
Slow
A few updates/sec
App App
Server
App App
State
App App
Unreliable
Failure here kills many apps

15. DDS Lets You Observe a Changing World
DDS:
 …allows you to observe frequent changes
 …uses network resources efficiently
 …is decentralized
Fast Scalable Managed Reliable
100,000’s updates/sec Load indep. # apps with QoS No single pt. failure
App App App App App App
State: Global Data Space

16. DDS Lets You Observe a Changing World
JBC-P replaced home-brew messaging w/ DDS:
Tracks 20x more objects with fewer failures
…with 97% less code(1.5M lines  50K)
…with 99% less CPU resources (88 cores  0.8)
Fast Scalable Managed Reliable
100,000’s updates/sec Load indep. # apps with QoS No single pt. failure
App App App App App App
State: Global Data Space

17. DDS Lets You Observe a Changing World
 Domain: world you’re talking about
 Topic: group of similar things Domain
(e.g. Yellowstone Park)
– Similar structure (―type‖) what
– Similar way they change when
over time (―QoS‖) how
Topic
 Instance: individual thing (e.g. bears in the park)
 DataWriter: source of observations about
part of the world (topic) Instance
(e.g. Yogi the bear)
 DataReader: observer of part of the world
(topic)

18. The OMG DDS
Standard

19. DDS: Standard Data-Centric middleware for
Application Integration
Streaming
Sensors Events
Data
Data Distribution Service
Real-Time Enterprise
Actuators
Applications Applications
© 2009 Real-Time Innovations, Inc. 19

20. Family of Specifications
2008 2009 2010 2010 2011 2011
UML Profile DDS for DDS DDS-STD-C++ Web-Enabled DDS
for DDS Lw CCM X-Types DDS-JAVA5 DDS Security
App 2004 App App
DDS Spec
DDS 2006 DDS DDS
Implementation DDS Implementation Implementation
Interoperablity
Network / TCP / UDP / IP
© 2009 Real-Time Innovations, Inc. COMPANY CONFIDENTIAL 20

21. DDS adopted by key programs
 DISR
– Mandates DDS for Pub-Sub API
– Mandates DDS-RTPS for Pub-Sub Interop
 US Navy Open Architecture
– Mandates DDS for Pub-Sub
 SPAWAR NESI
– Mandates DDS for Pub-Sub SOA
 European Air Traffic Control
– DDS used to interoperate ATC centers
 UK Generic Vehicle Architecture
– Mandates DDS for vehicle comm.
– Mandates DDS-RTPS for interop.
© 2010 Real-Time Innovations, Inc.

22. Key Civilian Programs Have Adopted DDS
Air-Traffic Management Automation/Scada
INDRA / THALES Schneider PLCs
Eurocontrol
Factory communications
Spain, UK, Germany,
France, Italy, Switzerland
Finance Large Telecopes
Citi, PIMCO ESO, NRAO
High Speed Trading, Coordinated Mirror Control
Compliance checking
SCADA
Automotive Grand Coulee Dam
Non-stop Turbine operation
VW, BMW
Driver Assistance, Car
Ethernet Bus,
© 2010 Real-Time Innovations, Inc. 22

23. Key A&D Programs Have Adopted DDS
Land Vehicles Ship Self Defense System
UK GVA Reagan Class Aircraft Carrier
Base10, Nexter Combat Management System
Vehicle control
UAS Ground Stations & Aegis Weapon System
Vehicles
Lockheed Martin
Predator, SkyWarrior
Radar, weapons, displays, C2
General Atomics Ground
Stations
Korea FFX Frigate
Samsung-Thales AWACS
Radar System
Combat Management
system
© 2010 Real-Time Innovations, Inc.

24. Data-CentricQos-Aware Pub-Sub Model
Virtual, decentralized global data space
Source
Latitude Longitude Altitude
(Key)
UAV1 37.4 -122.0 500.0
UAV2 40.7 -74.0 250.0
UAV3 50.2 -0.7 2000.0
Persistence Recording
CRUD operations Service Service
© 2010 Real-Time Innovations, Inc. 24

25. ShapesDemo
Demo: Publish-Subscribe
25

26. example
DDS communications model
Data Domain Data Domain
New Writer Participant Reader Participant
“Alarm”
Got new “Alarm”
subscriber data
!
Offered Requested
Listener QoS Listener QoS
 Participants scope the global data space (domain)
 Topics define the data-objects (collections of subjects)
 Writers publish data on Topics
 Readers subscribe to data on Topics
 QoS Policies are used configure the system
 Listeners are used to notify the application of events

27. ShapesDemo
Demo: Real-Time Quality of Service
 Content filter
 Time-based filter
 History
 Deadline
Analyzer
© 2009 Real-Time Innovations, Inc. 27

28. Real-Time Quality of Service (QoS)
QoS Policy QoS Policy
DURABILITY USER DATA
User QoS
HISTORY TOPIC DATA
Volatility
READER DATA LIFECYCLE GROUP DATA
WRITER DATA LIFECYCLE PARTITION
Presentation
LIFESPAN PRESENTATION
Infrastructure
ENTITY FACTORY DESTINATION ORDER
RESOURCE LIMITS OWNERSHIP
Redundancy Transport
RELIABILITY OWNERSHIP STRENGTH
Delivery
TIME BASED FILTER LIVELINESS
DEADLINE LATENCY BUDGET
CONTENT FILTERS TRANSPORT PRIORITY
© 2009 Real-Time Innovations, Inc. 28

29. DDS builds Higher quality, Lower TCO
Systems
Pre-built components address many challenging use-cases
 Presence
Comp
 Discovery Comp Comp
 Content-Based Delivery
 Scalable pub-sub DDS
Global
 Real-Time QoS Data Space
 Qos Monitoring
 Historical Cache
 Durable Data Messaging Event Database
& Caching Processing Bridge SQL
 Availability
Persistence Redundancy
 Redundancy & Failover Recording
& Durability & Failover
 Security Guard Hooks
© 2010 Real-Time Innovations, Inc. 30

30. Integrating components to generic
middleware technology
Comp Comp Comp Comp
Custom
Integration Data
Model
Custom Mapping
Middleware Artifacts
Akin to implementing an OO design on a Procedural Language:
Requires mapping inheritance, encapsulation, exceptions, …
© 2010 Real-Time Innovations, Inc. 31

31. Integrating components to data-centric
middleware technology
Comp Comp Comp Comp
Standard API
Data
Model
Standard Mapping(*)
DDS Global Data Space
No custom mappings / code necessary
Direct support for data-centric actions: create, dispose, read/take
© 2010 Real-Time Innovations, Inc. 32

32. Example: Message-Centric Legacy
Define message-sets / handshakes
Nothing to base filters, xforms on
Component or
Use-case based Error checking dev  integration
Schema,
Self-describing data is verbose
Limited QoS)
Subscribe
“My app 0x00000006 id=“AA123”
Publish
knows this 4141010203 x=float(45.6)
means 0042366666
dispose.” 429DC y=float(78.9)
© 2010 Real-Time Innovations, Inc. 33

33. Example: Modern Data-Centric Design
Start with Data Model / Schemas / Meaning
Data Schema Map this into XML; rows + cols
id : string (key) Express content-based filters
x : float
Propagate data efficiently
y : float
Dispose New Update New
Subscribe
Publish
“AA123” “DL987” “AA123” “AA123”
65.4 56.7 45.6
X 32.1 89.0 78.9
© 2010 Real-Time Innovations, Inc. 34

34. ShapesDemo
Demo: What it took to make a demo like this
 Detecting
presence
 History cache
 Deleting objects
 Detecting
Applications
© 2009 Real-Time Innovations, Inc. 35

35. OMG DDS Security:
How to Secure DDS?
 DDS Entities are authenticated
 DDS Entities access only
domains/Topics/… they are
allowed to
 DDS data integrity and
confidentiality is provided
 Non-repudiation is enforced
 DDS provides availability through
reliable access to data
….while maintaining DDS’s high performance
36

36. OMG DDS Security
: A Pluggable Architecture
OMG RFP accepted in Dec 2010
OMG RFP Response due in June 2011
37 OMG standard Dec 2011-Mar 2012

37. Protocol optimized for disadvantaged
networks
 Full peer-to-peer protocol
– No required brokers or servers
 Adaptable via Qos
– Reliability, timeouts, message priority
 Native multicast support DDS Interoperability Wire
– Fully uses transport multicast, if available Protocol adopted in 2007
– Handles reliability, avoids duplicates
 Supports disconnected media
– Based on UDP robust to disconnects
 Efficient data encapsulation
– Binary CDR is 20 X better than XML/SOAP
 Built-in availability and durability
– Durable & Persistent data
– Historical cache
– Failover support
© 2010 Real-Time Innovations, Inc.

38. Summary
 Real-World Systems & Systems of Systems facing
information volume, velocity, and mgmt. challenges
 Common solution is integration around a Data Model
 DDS is a family of OMG specifications that directly
supports data-centric publish-subscribe communications
 DDS includes portable API’s for C, C++, Java, etc. and
an Interoperable Wire Protocol
 Use of DDS results in reduced programming, decreased
cost, and lowered risk
Cost and Interoperability are the key drivers
© 2010 Real-Time Innovations, Inc. 39

39. Thank You
© 2010 Real-Time Innovations, Inc. 40