Transcript

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

Many others

© 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


Recommended