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