View On Demand: http://ecast.opensystemsmedia.com/375 Top Three Reasons to Develop Your Next Distributed Application with DDS Developing applications that can run over multiple cores, nodes or networks typically requires a significant amount of network-level programming. This low-level coding detracts from the implementation of application logic, introduces complexity, and is hard to maintain as requirements evolve and systems grow in scale. The challenges are particularly acute for real-time and embedded systems, which often have to address stringent timing, resource and reliability constraints. Just as high-level programming languages and operating systems simplified application development by eliminating hardware dependencies, the Data Distribution Service (DDS) standard does the same for networking. DDS provides application developers with simple publish-subscribe programming interfaces that abstract out all the networking details. Application components simply publish the data they produce and subscribe to the data they consume. The DDS middleware handles all the networking and real-time Quality of Service details. Components can seamlessly communicate across different programming languages and processor families. Applications are also independent of the underlying transport protocol and network type, be it shared memory, a local area network, wide area network or even radio link.

1. Your systems. Working as one.
Top Three Reasons to Develop
Your Next Distributed Application
with DDS
David Barnett
January 23, 2013

2. About RTI
• World leader in communications software for
real-time systems
– 350,000+ deployed copies
– 600+ unique designs
• Standards leader
– Participate in 15+ standards
organizations
– Authored DDS

3. Real-Time and Embedded Systems

4. DDS Is Communications Middleware
Application Application Application
Software Software Software
DDS Library DDS Library DDS Library
Operating System & Operating System & Operating System &
Communication Communication Communication
Mechanism Mechanism Mechanism
Network, backplane, shared memory

5. DDS Scope
Application Application Programming Application
Software Interface (API) Software
DDS Library Communication Model DDS Library
Operating System & Operating System &
Communication Communication
Mechanism Mechanism
Network Protocol
DDS Real-Time Publish Subscribe (RTPS) Wire Interoperability Protocol

6. DDS Is an OMG Standard
• OMG: world’s largest systems software
standards org
– 470+ members
– UML, DDS, CORBA, more
• Open process
• Standards freely available, including to
non-members
• No vendor lock-in
– ~12 implementations
– Proven interoperability

7. Top Three Reasons to Use DDS
1. Accelerate development
2. Future proof your applications
3. Ease integration

8. DDS Eliminates Complex Network
Programming
Replaces low-level communications code with
high-level Data-Centric Publish-Subscribe interfaces
Application
Software
write(data), read(data)
DDS Library
socket(), connect(),
bind(), listen(), Operating System
accept()… & Network Stack

9. Data-Centric Publish-Subscribe
“Data Centricity”
Combines:
• Asynchronous publish/subscribe messaging
• Real-time data management

10. Topic-Based Publish-Subscribe
DDS Bus
Commands
Sensor Data
Sensor Control Actuator
DDS automatically discovers and routes data between
publishers (writers) and subscribers (readers) to the same topic

11. DDS Topics Are Like Database Tables
Subscribe
Publish Line Flight Dest Arv
UA 567 SFO 7:32
AA 432 LAX 9:15
Squawk Line Flight
1234 UA 567
Squawk Long Lat Alt
7654 AA 432
1234 37.4 -122.0 500.0
7654 40.7 -74.0 250.0
Virtual Global Data Space
• Topics can be keyed
• DDS maintains last n values for each topic-key addressed data sample
• Eliminates dependence on startup order
• Automatically synchronizes state if disconnections and reconnections
• “Single source of truth” within a distributed application

12. Decentralized Architecture
Component Component Component Optional
Persistence
DDS DDS DDS
Unlike a traditional database:
• Decentralized with peer-to-peer communication
– Data cached locally for instant access
– No centralized performance bottlenecks or expensive servers
– No single point of failure: non-stop availability
• Asynchronous (event-driven) for real-time and low-latency

13. Designed to Support Real-Time and
Embedded Applications
• Control and visibility over real-time
Quality of Service (QoS)
– Data volatility: Durability, History,
Lifespan
– Data delivery: Reliability, Time based
filter, Content filter, Deadline
– High availability: Liveliness, Ownership,
Ownership Strength
• Applications can be autonomous
– Zero-configuration discovery
– No centralized servers or software
required
– DDS library embedded in application
• Deterministic resource utilization (RTI)

14. DDS Accelerates Development
Application Software Application Software
• Networking details write(topic, data) read(topic, data)
• Addressing (hosts, ports)
• Sockets
• Discovery
• State management
• Startup dependencies
• Disconnections DDS Library
• Failover
• Data routing
• Serialization
• Timing
Operating System Operating System
& Network Stack & Network Stack

15. Top Three Reasons to Use DDS
1. Accelerate development
2. Future proof your applications
3. Ease integration

16. Applications Often Start Small
• Single developer or small team
• Few:
– Processors or nodes
– Processor architectures
– Operating systems
– Programming languages
• Single, known network type
and transport protocol

17. …and Grow over Time
• Large teams; multiple
organizations
• Disparate platforms
and programming
languages
• New networking
environments
• New and evolving
requirements

18. Scalability Challenges

19. Traditional Communications
• Communication logic embedded in application
• E.g., using sockets, RPC, RMI
• Difficult to distribute development
• Costly to evolve, add new functionality

20. With DDS, Modules Are Loosely Coupled
DDS Bus
Sensor Data
Sensor Data
Sensor Sensor Commands
Control Display Actuator
Modules can be added and changed without affecting the rest of an application

21. DDS Easily Scales to Large Projects
• Developers only need to know about shared topics and their types
• Types are well-defined, discoverable and evolvable
struct Position {
struct Position {
unsigned short id;
unsigned short ID;
float latitude;
float latitude;
float longitude;
float longitude;
float altitude;
}
}
• Modules communicate regardless of:
– Programming language
– Operating system
– Processor architecture, word length, endianness
– Underlying transport protocol and network type
– DDS implementation

22. DDS Manages QoS
Reliable, 2 Hz,
Reliable, Western U.S.
100 Hz Line Flight Dest Arv
UA 567 SFO 7:32
Reliable
AA 432 LAX 9:15
Squawk Line Flight
1234 UA 567
Squawk Long Lat Alt Best Effort,
7654 AA 432
1234 37.4 -122.0 500.0 1 Hz, SAN area
7654 40.7 -74.0 250.0
Best Effort, 0.2 Hz,
UA flights
• Each component specifies its offered or requested QoS
• DDS enforces contracts, notifies application if violation
• Retains loose coupling even when disparate requirements

23. Scalable Run-Time Architecture
DDS Is Decentralized Traditional IT Is Centralized
• Efficient communication • Server-based
• No centralized bottlenecks • Assume high-bandwidth,
or choke points reliable network (TCP)
• No expensive servers that • Poor latency, scalability
must scale with volume

24. Throughput – Messages/Second
Gigabit Ethernet InfiniBand
10,000,000
2,141,625
Messages per Second
1,000,000
112,078
100,000
451,209
10,000
14,830
1,000
0 2,000 4,000 6,000 8,000
Message Size (Bytes)

25. Multicast for Scalable One-to-Many
Publisher • Minimizes:
– CPU overhead
– Network overhead
Switch – Latency
• Replication
• Filtering
• Maximizes determinism
Subscriber Subscriber Subscriber

26. Run-Time Scalability
Gigabit Ethernet
600,000
500,000
Messages per Second
400,000
300,000
200,000
100,000
0
0 200 400 600 800 1,000
Subscribers

27. DDS Scales to Large Applications
• Facilitates modular development of loosely
coupled and interoperable components
– Interfaces (topics and types) are well-defined
– Components are loosely coupled
– No custom protocols to document, maintain
– No reverse engineering
• Applications are programming
language, platform and network independent
• Extremely scalable run-time architecture

28. Top Three Reasons to Use DDS
1. Accelerate development
2. Future proof your applications
3. Ease integration

29. If You Provide an Application
• DDS provides a standard interface for
customers and systems integrators
– They can use any DDS implementation
– No need to provide and support a custom
interface library
• Only have to document topics and types
– …not custom protocols
– Topics and types are even run-time discoverable
• Supports real-time Quality of Service

30. If You’re A Systems Integrator
• DDS is decentralized for high scalability and availability
• Alternative to traditional Enterprise Service Bus (ESB)
• Open: integration logic not specific to an ESB implementation
• Real-Time QoS satisfies the requirements of real-time and non-real-
time components
Disparate Disparate
Component Component
Natively Natively
DDS or other protocol
Interoperable Interoperable
Adapter Adapter Component Component
API
DDS Library DDS Library DDS Library DDS Library
DDS-RTPS Wire Interoperability Protocol

31. Tools Support

32. System Overall Health

33. Top Three Reasons to Use DDS
1. Accelerate development
2. Future proof your applications
3. Ease integration

34. RTI Connext Product Family
General
Small Footprint & Disparate
Pub/Sub Purpose, Highly
Safety Critical Apps/Systems
Apps Reliable & Secure
Apps
Apps
Adapt, Xform,
API: Full DDS DDS++ & JMS DDS Subset Route
Connext Connext Connext Connext
DDS Messaging Micro Integrator
DDS-RTPS Wire Interoperability
Administration Recording
Monitoring Replay
System Viz Logging
Connext Tools

35. Next Steps – Learn More
• Contact RTI
– Demo, Q&A
• Download software
– www.rti.com/downloads
– RTI Shapes Demo
– Free trial with comprehensive tutorial
• Watch videos & webinars, read
whitepapers
– www.rti.com/resources
– www.youtube.com/realtimeinnovatio
ns

36. Thank you!