DDS and SOA Interfaces to ESB

DDS and SOA

Interfaces to ESB

NCOIC Plenary, VA Beach

29 Mar 2007

Gerardo Pardo-Castellote

CTO & Co-Author DDS Specification

[email protected]

www.rti.com

Joe Schlesselman

NCOIC OS&P WG Chair

joe.schlesselman

@rti.com

Agenda

Objective is to answer these questions

z

What is DDS?

z

What makes DDS different?

DDS

Point-to-Point Telephone, TCP

Simple, high-bandwidth

Leads to stove-pipe systems

Client-Server

File systems, Database, RPC, CORBA, DCOM Good if information is naturally centralized

Single point failure, performance bottlenecks

Publish/Subscribe Messaging Magazines, Newspaper, TV Excels at many-to-many communication

Excels at distributing time-critical information

Replicated Data

Libraries, Distributed databases Excels at data-mining and analysis

The DDS Standard

z

Data Distribution Service for Real-Time Systems

–

Adopted in June 2003, revised June 2005

–

Specification of API for Data-Centric Publish-Subscribe in

real-time distributed systems.

–

Adopted Interoperability Protocol in Jun 06

z

Multiple Implementations

–

3 commercial, 3 open source

–

Several more in-house

z

Vibrant open community

–

DDS SIG at OMG

–

OMG DDS tutorials, DDS Focus days, Real-Time Embedded

Systems Workshop

DDS Communications model

Provides a “

Global Data Space

” that is accessible to all

interested applications.

–

Data objects addressed by

Domain, Topic

and

Key

–

Subscriptions are

decoupled

from Publications

–

Contracts established by means of

QoS

–

Automatic

discovery

and

configuration

Global Data Space

Participant

Pub Pub Participant

Sub _Sub Participant

Participant _Pub Alarm Track,2 Track,1 Track,3 Participant Sub

Data Reader “Circle” Domain Participant Data Writer “Circle” Domain Participant

DDS communications model

z Publisher declares information it has and specifies the Topic

– and the offered QoS contract

– and an associated listener to be alerted of any significant status changes

z Subscriber declares information it wants and specifies the Topic

– and the requested QoS contract

– and an associated listener to be alerted of any significant status changes

z DDS automatically discovers publishers and subscribers

– DDS ensures QoS matching and alerts of inconsistencies

Failed to produce data Listener Offered

QoS

QoS

Quality of Service (QoS) for Real-Time

QoS Policy

QoS Policy

DURABILITY USER DATA

HISTORY TOPIC DATA

READER DATA LIFECYCLE GROUP DATA WRITER DATA LIFECYCLE PARTITION

LIFESPAN PRESENTATION

CONTENT FILTERS TRANSPORT PRIORITY ENTITY FACTORY DESTINATION ORDER RESOURCE LIMITS OWNERSHIP

RELIABILITY OWNERSHIP STRENGTH TIME BASED FILTER LIVELINESS

DEADLINE LATENCY BUDGET

Volatility Use r QoS Delive ry Presentatio n Redu n dan cy Infras tructure Transp ort

Agenda

Objective is to answer these questions

z

What is DDS?

z

What makes DDS different?

–

Data centricity

–

Performance

–

Configurability and QoS

What makes DDS different from other

messaging e.g. JMS, MQSeries

z

Data-centricity

–

High level of data abstraction: Domain, Topic, Key

–

Proven scalable model for RT systems

–

“Smart” services such as:

z Ownership, Time-Based Filters, Content-Based Filters

z Persistence, Keep-Last History

–

Directly supports state propagation/caching

z

High Performance

–

Real-time messaging

–

As fast as the “network transport” can handle

–

Scalability

z

Configurability by QoS

–

Wide range of applicability: Enterprise to real-time

–

Publish-Subscribe infrastructure:

z Fault-tolerance

Data-Distribution and Real-Time

Non-real-time Soft real-time Hard real-time Extreme real-time

Java/RMI Java/JMS

CORBA

MPI

Java RTSJ (soft RT) RTSJ (hard RT)

Web Services

Messaging Technologies and Standards

Messaging Technologies and Standards

Data Distribution Service / DDS RT CORBA

Low DDS Latency

DDS/GSOAP/JMS/Notification Service Comparison - Latency

0 500 1000 1500 2000 2500 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384

Message Size (bytes)

DDS GSOAP

JMS Notification Service

Message Length (samples)

Low DDS Jitter

DDS/GSOAP/JMS/Notification Service Comparison - Jitter

0 20 40 60 80 100 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384

Message Size (bytes)

S ta n dar d D evi at io n (u s ecs ) DDS GSOAP JMS Notification service

Message Length (samples)

DDS Throughput 25 times better than JMS

Throughput with a single publisher

0 5 10 15 20 25 30 35 40 45 2 4 6 9 11 18 CPU load [%] [1 000's sam pl e/ s]

RTI DDS

JMS

Platform: Linux 2.6 on AMD Athlon, Dual core, 2.2 GHz

( 2KB messages )

Agenda

Objective is to answer these questions

z

What is DDS?

z

What makes DDS different?

SOA

Service Orientation:

“ an architectural style promoting a loosely-coupled component-based approach where each component offers one or more ‘services’. These services encapsulate some business logic behind well-defined service interfaces. Services communicate using standard protocols and can be accessed without knowledge of their implementation or platform.”

Many technologies can be used to implement SOA systems: WebServices, JMS, DDS, CORBA, MQSeries

In practice for enterprise applications the most used technologies are: For request-reply interactions

WSDL to define Interfaces XML to define data

SOAP as the protocol

For pub-sub and messaging

JMS for pub-sub messaging

Emerging: WS-Eventing, WS-Notification (XML based)

DDS is a better fit for messaging in Real-Time and near real-time systems

DDS and SOAP comparison

DDS and SOAP address complementary needs

Distributed systems need both!

DDS (JMS, WS-Events)

z

Distributed data & events

–

Publish/subscribe

–

One-way messages

–

Configurable QoS

z

Best for

–

Hi-performance 1 to many

–

Dynamic, unreliable transports

–

Flexible delivery requirements

–

Events, High performance

messaging

WS/SOAP/CORBA

z

Distributed service

–

Client/server

–

Remote method calls

–

Reliable transport

z

Best for

–

Configuration

–

File transfer

–

Synchronous transactions

–

Sporadic request-reply

Information-Oriented SOA for Pub-Sub

NOT THIS:

NOT THIS:

(connection

(connection--oriented)oriented)

BUT THIS:

BUT THIS: Shared Operational Picture

= System Components

Use of an Information –Oriented design for Pub-Sub

applications avoids creating stovepipe systems

DDS as a Web-Service

z

Exposing DDS as a Web-Service (WS-DDS)

–

WS-DDS provides pub-sub data-distribution

–

This is another (WSDL) API to access DDS

z

Advantage:

–

WS-DDS would be accessible from any tool that can

invoke a web-service

z

Disadvantage:

Enabling Real-Time of SOA

Open, Standard Platform Enabling Integration

–

from the Enterprise Service Bus (ESB)

–

to the Real-Time Service Bus (RTSB)

DDS

RT Application

Enterprise App

Enterprise App Enterprise App

SOA/Web Services (J2EE, NET, …)

SQL

SQL/RDBMS

Global Data Space

DDS DDS Embedded App. SQL Technologies: DDS, CORBA SQL mappings SOA mappings

ESB

RTSB

Thank you

Joe Schlesselman

[email protected]

Gerardo Pardo-Castellote

[email protected]

www.rti.com