Embed Size (px)
DESCRIPTION
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.
Citation preview
Your systems. Working as one.
Top Three Reasons to Develop Your Next Distributed Application with DDS
David BarnettJanuary 23, 2013
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
Real-Time and Embedded Systems
DDS Is Communications Middleware
Application Software
DDS LibraryOperating System &
Communication Mechanism
Application Software
DDS LibraryOperating System &
Communication Mechanism
Application Software
DDS LibraryOperating System &
Communication Mechanism
Network, backplane, shared memory
DDS Scope
Application Software
DDS LibraryOperating System &
Communication Mechanism
Application Software
DDS LibraryOperating System &
Communication Mechanism
Application ProgrammingInterface (API)
Communication Model
DDS Real-Time Publish Subscribe (RTPS) Wire Interoperability Protocol
Network Protocol
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
Top Three Reasons to Use DDS
1. Accelerate development
2. Future proof your applications
3. Ease integration
DDS Eliminates Complex Network Programming
Replaces low-level communications code withhigh-level Data-Centric Publish-Subscribe interfaces
write(data), read(data)
Application Software
DDS Library
Operating System& Network Stack
socket(), connect(),bind(), listen(),
accept()…
Data-Centric Publish-Subscribe“Data Centricity”
Combines:
• Asynchronous publish/subscribe messaging
• Real-time data management
Topic-Based Publish-Subscribe
DDS automatically discovers and routes data between publishers (writers) and subscribers (readers) to the same topic
DDS Bus
Sens
or D
ata
ControlCo
mm
ands
Stat
us
Sensor
Sens
or D
ata
Actuator
Com
man
ds
Stat
us
DDS Topics Are Like Database Tables
• 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
PublishSubscribe
Virtual Global Data Space
Squawk Long Lat Alt
1234 37.4 -122.0 500.0
7654 40.7 -74.0 250.0
Line Flight Dest Arv
UA 567 SFO 7:32
AA 432 LAX 9:15 Squawk Line Flight
1234 UA 567
7654 AA 432
Decentralized Architecture
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
Component
DDS
Component
DDS
Component
DDS
Optional Persistence
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)
Application Software
DDS Accelerates Development
• Networking details• Addressing (hosts, ports)• Sockets
• Discovery• State management• Startup dependencies• Disconnections• Failover• Data routing• Serialization• Timing
Operating System& Network Stack
Application Software
write(topic, data) read(topic, data)
DDS Library
Operating System& Network Stack
Top Three Reasons to Use DDS
1. Accelerate development
2. Future proof your applications
3. Ease integration
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
…and Grow over Time
• Large teams; multiple organizations
• Disparate platforms and programming languages
• New networking environments
• New and evolving requirements
Scalability Challenges
Traditional Communications
• Communication logic embedded in application• E.g., using sockets, RPC, RMI• Difficult to distribute development• Costly to evolve, add new functionality
With DDS, Modules Are Loosely Coupled
Modules can be added and changed without affecting the rest of an application
DDS Bus
Sensor
Sens
or D
ata
Sens
or D
ata
ControlCo
mm
ands
Stat
us
Sensor
Sens
or D
ata
Actuator
Com
man
ds
Stat
us
Display
Sens
or D
ata
Stat
us
DDS Easily Scales to Large Projects
• Developers only need to know about shared topics and their types• Types are well-defined, discoverable and evolvable
• Modules communicate regardless of:– Programming language– Operating system– Processor architecture, word length, endianness– Underlying transport protocol and network type– DDS implementation
struct Position {unsigned short id;float latitude;float longitude;float altitude;
}
struct Position {unsigned short ID;float latitude;float longitude;
}
DDS Manages QoS
• Each component specifies its offered or requested QoS• DDS enforces contracts, notifies application if violation• Retains loose coupling even when disparate requirements
Squawk Long Lat Alt
1234 37.4 -122.0 500.0
7654 40.7 -74.0 250.0
Line Flight Dest Arv
UA 567 SFO 7:32
AA 432 LAX 9:15Squawk Line Flight
1234 UA 567
7654 AA 432
Reliable,100 Hz
Reliable, 2 Hz,Western U.S.
Reliable
Best Effort,1 Hz, SAN area
Best Effort, 0.2 Hz,UA flights
Scalable Run-Time Architecture
• Server-based• Assume high-bandwidth,
reliable network (TCP)• Poor latency, scalability
• Efficient communication• No centralized bottlenecks or
choke points• No expensive servers that
must scale with volume
Traditional IT Is CentralizedDDS Is Decentralized
Throughput – Messages/Second
0 1,000 2,000 3,000 4,000 5,000 6,000 7,000 8,000 1,000
10,000
100,000
1,000,000
10,000,000
2,141,625
112,078
451,209
14,830
Gigabit Ethernet InfiniBand
Message Size (Bytes)
Mes
sage
s per
Sec
ond
Multicast for Scalable One-to-Many
• Minimizes:– CPU overhead– Network overhead– Latency
• Maximizes determinism
Publisher
Subscriber SubscriberSubscriber
Switch• Replication• Filtering
Run-Time Scalability
0 100 200 300 400 500 600 700 800 900 1,0000
100,000
200,000
300,000
400,000
500,000
600,000
Gigabit Ethernet
Subscribers
Mes
sage
s pe
r Sec
ond
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
Top Three Reasons to Use DDS
1. Accelerate development
2. Future proof your applications
3. Ease integration
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
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
DisparateComponent
DDS-RTPS Wire Interoperability Protocol
AdapterDDS Library
DisparateComponent
AdapterDDS Library
Natively InteroperableComponentDDS Library
Natively InteroperableComponentDDS Library
DDS or other protocol
API
Tools Support
System Overall Health
Top Three Reasons to Use DDS
1. Accelerate development
2. Future proof your applications
3. Ease integration
RTI Connext Product Family
DDS-RTPS Wire Interoperability
ConnextDDS
API: Full DDS
Pub/SubApps
ConnextMessaging
DDS++ & JMS
ConnextMicro
DDS Subset
ConnextIntegrator
Adapt, Xform, Route
DisparateApps/Systems
Connext Tools
Administration
Monitoring
Recording
Replay
LoggingSystem Viz
General Purpose, Highly Reliable &
Secure Apps
Small Footprint & Safety Critical
Apps
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/realtimeinnovations
Thank you!
