Data-Distribution Service (DDS)The Ideal Bus for CEP
dds/2008-03-04Gerardo Pardo-Castellote, Ph.D.Co-Chair Data-Distribution SIGCTO, Real-Time Innovations, Inc.13 March 2008
© 2007 Real-Time Innovations, Inc.2
Agenda
Introduction
Middleware and CEP
The OMG DDS standard as a message bus for CEP
Conclusion
© 2007 Real-Time Innovations, Inc.3
History: DDS the Standard
Data Distribution Service for Real-Time Systems– Adopted in June 2003– Finalized in June 2004– Revised June 2005, June 2006– Joint submission (RTI, THALES, OIS)– Specification of API for Data-Centric Publish-Subscribe in real-
time distributed systems.
Interoperability wire protocol– Adopted in July 2006– Revised in July 2007
Multiple Implementations– 4 commercial– 3 open source– Several more in-house
4
LockheedAEGIS Insitu
Unmanned Air Vehicles
BoeingFuture CombatSystems
NorthtropE2C
Hawkeye
RaytheonSSDS
BoeingAWAKS
DDS Adoption – Aerospace & Defense
5
WiTronixTrain and vehicleTracking
Tokyo JapanTraffic Control
Schneider ElectricIndustrial Automation
KukaRobotics
VarianMedical Instruments
DDS Adoption – Transportation, Industrial
EU and USAir Traffic Management
© 2007 Real-Time Innovations, Inc.7
DDS Mandates for Net-Centric Systems
DISR (formerly JTA)– DoD Information Technology
Standards Registry
US Navy Open Architecture
FCS SOSCOE– Future Combat System –
System of System CommonOperating Environment
NESI– Net-centric Enterprise Solutions
for Interoperability
UK MOD & NATO– Advocating Open Systems
© 2007 Real-Time Innovations, Inc.8
Middleware and CEP: The hose that feeds the engine
Inputs
CEP Engine
Outputs
CEP Engine
© 2007 Real-Time Innovations, Inc.9
Middleware and CEP: Scalability & Load Balancing
CEP Engine
CEP Engine
CEP EngineCEP Engine
© 2007 Real-Time Innovations, Inc.10
Middleware and CEP: Integration & Interoperability
Vendor 3
Vendor 2
Vendor 4Vendor 1
© 2007 Real-Time Innovations, Inc.11
Implementing the Global Event Bus/Data Streams
Global Event Bus
EventType2
EventType1
EventType2
ADAPTOR != MIDDLEWAREMultiple adaptor technologies will be needed… but not all are created equalIt is highly desirable to use a middleware where the event model and use-case requirements are handled as first-class citizensEvent semantic model can be pushed into the middleware information model
© 2007 Real-Time Innovations, Inc.12
Standardizing the Adaptor/Transport
NEEDED:Not so much a standard adaptor…
…but:– A standard event meta-model
Relevant OMG standards: UML, MOF, OCL, …– A ‘standard’ way to adapt to the existing Transports/Message
Busses & information modelUsing the same Adaptor technology will not allow CEP engines to “interoperate”Relevant OMG standards: DDS, CORBA Notification Service
Communicate != Interoperate
© 2007 Real-Time Innovations, Inc.13
Requirements on a CEP Message Bus
Fit to the CEP information Model– CEP engines need access to data regardless of its source– CEP operates on structured data, not opaque messages
Performance & Scalability– CEP systems are event-driven– CEP operates on streaming data and has low-latency & high-
throughput requirements
Configurability, QoS, Filtering & Services– CEP is deployed in critical systems that be robust to failures– CEP weaves streams with different QoS requirements (updates
rates, priority)– CEP often needs access to only a subset of the information
© 2007 Real-Time Innovations, Inc.14
DDS: The best “message bus” for CEP?
Fit to the CEP information Model– DDS is Data-Centric, not message centric– Beyond messaging DDS also does “state management”– DDS Supports Topic-Based and Content-Based Subscriptions– DDS built-in Window/Time selectors delivers *only* relevant data
Performance & Scalability– DDS offers notification-based APIs– DDS has the best performance (latency, throughput, jitter, scalability) of
any standard middleware technology
Configurability, QoS, Filtering & Services– DDS Publish-Subscribe model delivers wherever needed– DDS has rich QoS to support real-time event-driven systems (latency
budget, priority, etc.)– DDS Built-in Fault-Tolerance Mechanism allow for redundant sources of
data– DDS built-in services Persistence and Historical Data Services ensures
relevant data is never lost
© 2007 Real-Time Innovations, Inc.15
#1 DDS Data-Centric Model
Data WriterData Writer
Data WriterData Writer
Data ReaderData Reader
Data Reader
Data ReaderData Writer
Topic
“Global Data Space” generalizes Subject-Based Addressing– Data objects addressed by DomainId, Topic and Key– Domains provide a level of isolation – Topic groups homogeneous subjects (same data-type & meaning) – Key is a generalization of subject
Key can be any set of fields, not limited to a “x.y.z …” formatted string– Data Structure is known by the middleware
© 2007 Real-Time Innovations, Inc.16
#1 DDS Data-Centric Model
Data WriterData Writer
Data WriterData Writer
Data ReaderData Reader
Data Reader
Data ReaderData Writer
Key (subject)
“Global Data Space” generalizes Subject-Based Addressing– Data objects addressed by DomainId, Topic and Key– Domains provide a level of isolation – Topic groups homogeneous subjects (same data-type & meaning) – Key is a generalization of subject
Key can be any set of fields, not limited to a “x.y.z …” formatted string– Data Structure is known by the middleware
© 2007 Real-Time Innovations, Inc.17
#1 DDS Data-Centric Model
Data WriterData Writer
Data WriterData Writer
Data ReaderData Reader
Data Reader
Data ReaderData Writer
Data Object
“Global Data Space” generalizes Subject-Based Addressing– Data objects addressed by DomainId, Topic and Key– Domains provide a level of isolation – Topic groups homogeneous subjects (same data-type & meaning) – Key is a generalization of subject
Key can be any set of fields, not limited to a “x.y.z …” formatted string– Data Structure is known by the middleware
© 2007 Real-Time Innovations, Inc.18
Topic: “Market Data”
Subject Filter (for a Reader)
Field
Value
Symbol Type Exchange
* * NYSE *
Subject Filter (for a Reader)
SourceField
Value
Symbol Type Exchange Payload
REUTERS * EQ NYSE Volume > x, Ask < y
Payload Filter (for a Reader)
Topic: “Order Entry”
Topic: “Market Data”
Subscriptions: By Topic, Subject, Content
OrderKind Stop Limit
SourceField
Value
Symbol Type ExchangePayload
* * * * *
Volume Bid Ask …
OrderNumber …
Key Fields Other Fields
Key Fields Other Fields
Key Fields Other Fields
© 2007 Real-Time Innovations, Inc.19
DataReader“Alarm”
DomainParticipant
DataWriter
“Alarm”
DomainParticipant
DDS communications model
Participants scope the global data space (domain)Topics define the data-objects (collections of subjects)Writers publish data on TopicsReaders subscribe to data on TopicsQoS Policies are used configure the systemListeners are used to notify the application of events
ListenerOfferedQoS Listener
Got newdata
OfferedQoS
New subscriber!
© 2007 Real-Time Innovations, Inc.20
Demo: Concepts
Topics– Square, Circle, Triangle– Attributes
Data types (schemas)– Shape (color, x, y, size)
Color is instance Key– Attributes
Shape & color used for key
QoS– Deadline, Liveliness– Reliability, Durability– History, Partition– OwnershipControl Area:
Allows selection of objects and QoS
Display Area: Shows state of objects
Start demo
© 2007 Real-Time Innovations, Inc.21
QoS: Quality of Service
QoS Policy QoS PolicyDURABILITY USER DATA
HISTORY (per subject) TOPIC DATA
READER DATA LIFECYCLE GROUP DATA
WRITER DATA LIFECYCLE PARTITION
LIFESPAN PRESENTATION
ENTITY FACTORY DESTINATION ORDER
RESOURCE LIMITS OWNERSHIP
RELIABILITY OWNERSHIP STRENGTH
TIME BASED FILTER LIVELINESS
DEADLINE LATENCY BUDGET
CONTENT FILTERS TRANSPORT PRIORITY
Standardized Middleware QoS semantics
© 2007 Real-Time Innovations, Inc.22
Demo: Quality of Service (QoS)
Topics– Square, Circle, Triangle– Attributes
Data types (schemas)– Shape (color, x, y, size)
Color is instance Key– Attributes
Shape & color used for key
QoS– Deadline, Liveliness– Reliability, Durability– History, Partition– Ownership
RTI DDS delivers
Writers and readers stateTheir needs
Start demo
© 2007 Real-Time Innovations, Inc.23
DDS: The best “message bus” for CEP?
#1 Fit to the CEP information Model– DDS is Data-Centric, not message centric– DDS Supports Topic-Based and Content-Based Subscriptions– DDS built-in Window/Time selectors delivers *only* relevant data
#2 Performance & Scalability– DDS offers notification-based APIs– DDS has the best performance (latency, throughput, jitter, scalability) of
any standard middleware technology
#3 Configurability, QoS, Filtering & Services– DDS Publish-Subscribe model delivers wherever needed– DDS has rich QoS to support real-time event-driven systems (latency
budget, priority, etc.)– DDS Fault-Tolerance Mechanism allows for redundant sources of data– DDS built-in services Persistence and Historical Data Services ensures
relevant data is never lost
© 2007 Real-Time Innovations, Inc.24
Data-Distribution and Real-Time
Non-real-time Soft real-time Hard real-time Extreme real-time
Java/RMIJava/JMS
CORBA
MPI
Java RTSJ (soft RT) RTSJ (hard RT)
Web Services
Mes
sagi
ng T
echn
olog
ies
and
Stan
dard
sM
essa
ging
Tec
hnol
ogie
s an
d St
anda
rds
Data Distribution Service / DDS
RT CORBA
Adapted from NSWC-DD OA Documentation
© 2007 Real-Time Innovations, Inc.25
Latency – (Linear Scale)
DDS/JMS/Notification Service Comparison - Latency
0
500
1000
1500
2000
2500
16 32 64 128 256 512 1024 2048 4096 8192 16384 32768 65536
Message Size (bytes)
DDS JMS Notification Service
Adapted from Vanderbilt presentation at July 2006 OMG Workshop on RT Systems
IBM HS20 bladesDual 2.8 GHz Xeon, 1 GB RAMGigabit Ethernet
© 2007 Real-Time Innovations, Inc.26
Jitter – (Linear Scale)
DDS/JMS/CORBA Notification Service Comparison - Jitter
0
200
400
600
800
1000
1200
1400
1600
1800
2000
16 32 64 128 256 512 1024 2048 4096 8192 16384 32768 65536
Message Size (bytes)
Stan
dard
Dev
iatio
n (u
secs
)
DDS JMS Notification service
Source: Vanderbilt presentation at July 2006 OMG Workshop on RT Systems
DDS/CORBA Notification Service Comparison - Jitter
0
20
40
60
80
100
16 32 64 128 256 512 1024 2048 4096 8192 16384 32768 65536
Message Size (bytes)
Stan
dard
Dev
iatio
n (u
secs
)
DDS JMS Notification service
© 2007 Real-Time Innovations, Inc.27
DDS : Low Latency and Jitter
Reliable, ordered delivery overGigabit Ethernet between 2.0 GHz Opteron processors running 32-bit Red Hat Enterprise Linux 4.0
Message/Data Size (bytes)
Late
ncy
(mic
rose
cond
s)
Latency and Jitter on Unloaded Network
0
50
100
150
200
250
300
350
400
32 64 128 256 512 1024 2048 4096 8192
Maximum99.99%99%MedianMinimum
© 2007 Real-Time Innovations, Inc.28
DDS: Low Overhead Enables High Throughput
Reliable, ordered delivery overGigabit Ethernet between 2.0 GHz Opteron processors running 32-bit Red Hat Enterprise Linux 4.0
0
10,000
20,000
30,000
40,000
50,000
60,000
70,000
16 32 64 128 256 512 1024 2048 4096 8192 16384 32768Message/Data Size
Upd
ates
per
Sec
ond
0
100
200
300
400
500
600
700
800
900
1000
Meg
abits
per
Sec
ond
© 2007 Real-Time Innovations, Inc.29
DDS: Scalable Performance (Confirmed Reliability)
Reliable, ordered delivery overGigabit Ethernet between 2.0 GHz Opteron processors running 32-bit Red Hat Enterprise Linux 4.0
0
10,000
20,000
30,000
40,000
50,000
60,000
16 32 64 128 256 512 1024
Message/Data Size (bytes - without batching)
Poin
t-to-
Poin
t Upd
ates
per
Sec
ond
1-11-101-24
© 2007 Real-Time Innovations, Inc.30
DDS operates without brokers
DDS Broker-basedMiddleware
No Brokers => Better Performance & Determinism+ Increased Robustness
© 2007 Real-Time Innovations, Inc.31
DDS: The best “message bus” for CEP?
#1 Fit to the CEP information Model– DDS is Data-Centric, not message centric– DDS Supports Topic-Based and Content-Based Subscriptions– DDS built-in Window/Time selectors delivers *only* relevant data
#2 Performance & Scalability– DDS offers notification-based APIs– DDS has the best performance (latency, throughput, jitter, scalability) of
any standard middleware technology
#3 Configurability, QoS, Filtering & Services– DDS Publish-Subscribe model delivers wherever needed– DDS has rich QoS to support real-time event-driven systems (latency
budget, priority, etc.)– DDS Fault-Tolerance Mechanism allows for redundant sources of data– DDS built-in services Persistence and Historical Data Services ensures
relevant data is never lost
© 2007 Real-Time Innovations, Inc.32
#3 QoS and Powerful Services
– Redundancy & Failover
– Persistent Data– Last value cache– Historical cache
QoS Policy QoS Policy
DURABILITY USER DATA
HISTORY (per subject) TOPIC DATA
READER DATA LIFECYCLE
GROUP DATA
WRITER DATA LIFECYCLE
PARTITION
LIFESPAN PRESENTATION
ENTITY FACTORY DESTINATION ORDER
RESOURCE LIMITS OWNERSHIP
RELIABILITY OWNERSHIP STRENGTH
TIME BASED FILTER LIVELINESS
DEADLINE LATENCY BUDGET
CONTENT FILTERS TRANSPORT PRIORITY
© 2007 Real-Time Innovations, Inc.33
Ownership and High Availability
Owner determined per subjectOnly extant writer with highest strength can publish a subject (or topic for non-keyed topics)Automatic failover when highest strength writer:– Loses liveliness– Misses a deadline– Stops writing the subject
Shared Ownership allows any writer to update the subject
Producer / Writerstrength=10
Topic T1
I1 I2Producer / Writer
strength=5
Producer / Writerstrength=1
I1 Primary
I1 BackupI2 Primary
I2 Backup
© 2007 Real-Time Innovations, Inc.34
Data Persistence
A standalone service that persists data outside of the context of a DataWriter
Data Writer
Global Data Space
Data Reader
PersistenceService
PersistenceService
Data Reader
Data Writer
PermanentStorage
PermanentStorage
© 2007 Real-Time Innovations, Inc.35
Conclusion
To get the best performance from your CEP you need the best message bus
DDS is a natural fit for CEP:– The Data-Centric Pub-Sub information model is an
excellent match to the CEP structured event model– DDS supports many of the CEP use-cases and QoS
as first-class citizens– DDS offers the best performance and latency of any
middleware standard