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