A QoS Policy Modeling Language for Publish/Subscribe Middleware Platforms A QoS Policy Modeling Language for Publish/Subscribe Middleware Platforms Joe.

A QoS Policy Modeling Language A QoS Policy Modeling Language for Publish/Subscribe Middleware for Publish/Subscribe Middleware

PlatformsPlatformsJoe Hoffert, Doug Schmidt &

Aniruddha Gokhale

{jhoffert,schmidt,gokhale}@dre.vanderbilt.edu

www.dre.vanderbilt.edu

ISIS, Dept. of EECS Vanderbilt University Nashville, Tennessee

June 21, 2007DEBS 2007, Toronto, Canada

www.dre.vanderbilt.eduwww.dre.vanderbilt.edu

2

Distributed Real-time & Embedded (DRE) Systems

• Network-centric and large-scale “systems of systems”– e.g., industrial automation, emergency response

• Different communication semantics– e.g., pub-sub

• Satisfying tradeoffs between multiple (often conflicting) QoS demands– e.g., secure, real-time, reliable, etc.

• Regulating & adapting to (dis)continuous changes in runtime environments• e.g., online prognostics, dependable upgrades, keep

mission critical tasks operational, dynamic resource mgmt

DRE systems increasingly realized via system composition of services

3

Variability in the solution space (systems integrator role)

•Diversity in platforms, languages, protocols & tool environments

•Enormous accidental & inherent complexities

•Continuous evolution & change

Challenges in Realizing DRE Systems

Variability in the problem space (domain expert role)

•Functional diversity•Composition, deployment and configuration diversity

•QoS requirements diversity

Mapping problem artifacts to solution artifacts is hard

4

The OMG Data Distribution Service (DDS)

Application

Application

Application

Application

ApplicationLogical Data Store

read

read

read

write

write

write write

Provides flexibility, power and modular structure by decoupling:

• Location – anonymous pub/sub

• Redundancy – any number of readers & writers

• Time – asynchronous, time-independent data distribution

• Platform – similar to CORBA middleware

Architecturally Broken into:• Data Centric Publish/Subscribe (DCPS)

- Lower layer APIs to exchange topic data based on QoS policies

• Data Local Reconstruction Layer (DLRL)

- Upper layer APIs that make topic data appear local

5

QoS Policies Supported by DDS• DCPS entities (e.g., topics, data readers/writers) configurable via QoS

policies

• QoS tailored to data distribution in tactical information systems

• Request/offered compatibility checked by DDS at Runtime

• Consistency checked by DDS at Runtime

• DEADLINE

• Establishes contract regarding rate at which periodic data is refreshed

• LATENCY_BUDGET

• Establishes guidelines for acceptable end-to-end delays

• TIME_BASED_FILTER

• Mediates exchanges between slow consumers & fast producers

• RESOURCE_LIMITS

• Controls resources utilized by service

• RELIABILITY (BEST_EFFORT, RELIABLE)

• Enables use of real-time transports for data

• HISTORY (KEEP_LAST, KEEP_ALL)

• Controls which (of multiple) data values are delivered

• DURABILITY (VOLATILE, TRANSIENT, PERSISTENT)

• Determines if data outlives time when they are written

• … and 15 more …

6

QoS Policy Configuration Challenges

• QoS Policy Compatibility• QoS policies for the

communicating entities must be compatible between what’s requested and offered

Best effort data transfer

offered

Reliable data transfer

requested

XData will not

be transferred

Deadline’s period = 5 ms.

Time based filter’s minimum separation =

10 ms.

XQoS policies

will not be set

• QoS Policy Consistency• QoS policies for any

one entity must be consistent with each other

Need to flag errors earlier in the developmental lifecycle

7

DDS QoS Modeling Language (DQML 1 of 2)

• Models relevant DDS entities

• Models DDS QoS polices as first class entities

• Models relationships between entities and QoS policies

Focus on “correct by construction” – check for errors at design-time

8

DDS QoS Modeling Language (DQML 2 of 2)

• Supports QoS compatibility and consistency constraint checking

• Generates implementation artifacts (currently for DDS Benchmarking Environment (DBE))

Compicon.icoDBEInterpreter

DBEQoS Settings

DataReader

QoS SettingsDataWriter

9

Ongoing Work: DQML + Service Orchestration

Component

ResourceRequirements

Impl

Impl

Impl

Properties

Component Assembler

Component Assembly

Component Component

Component Component

Component Package

Component Assembly

Component Component

Component Component

Component Assembly

Component Component

Component Component

(1) d

evel

ops

(2) assembles

(3) packages

(4) c

onfig

ures

(6) deployment

Assembly

DeploymentApplication

Assembly

Assembly

CoSMIC

(8) reconfiguration &

replanning

Analysis & Benchmarking

packaging

asse

mbl

y

specification

configuration

pla

nnin

g

feedback

(7) analysis & benchmarking

(IDM

L &

PIC

ML)

(PICML)

(PIC

ML)

(OC

ML,

QoS

ML)

(Cadena & BGML)

DAnCE Framework

(5) planning

Component Developer

RACE Framework

),...,( 21 nxxxfy

Deployment Planner

Component Packager

Component Configurator

Systemanalyzer

ComponentDeployer

(9) design

feedback

• CoSMIC tools e.g., PICML used to model application components, CQML for QoS

• Captures the data model of the OMG D&C specification

• Synthesis of static deployment plans for DRE systems

• Capabilities being added for QoS provisioning (real-time, fault tolerance, security)

CoSMIC can be downloaded at www.dre.vanderbilt.edu/cosmic

Work supported by

DARPA PCES & ARMS

Programs

10

Concluding Remarks• QoS configuration management

is a significant challenge for pub-sub systems

• Need design-time tools to automate the QoS configuration management

• Need tools to assure “correct-by-construction” systems

• Model-driven Engineering is a promising approach

Compicon.icoInvoke the DBEInterpreter

DBE

QoS Settings

QoS Settings

DataReader

DataWriter