Transcript Document

A QoS Policy Modeling Language for
Publish/Subscribe Middleware Platforms
Joe 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, 2007
DEBS 2007, Toronto, Canada
www.dre.vanderbilt.edu
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
2
Challenges in Realizing DRE Systems
Variability in the problem space
(domain expert role)
•Functional diversity
•Composition, deployment and
configuration diversity
•QoS requirements diversity
Variability in the solution space
(systems integrator role)
•Diversity in platforms,
languages, protocols & tool
environments
•Enormous accidental &
inherent complexities
•Continuous
evolutionartifacts
& change
Mapping problem
to solution artifacts is hard
3
The OMG Data Distribution Service (DDS)
Application
Application
Logical Data Store
Application
Application
Application
Provides flexibility, power and modular
structure by decoupling:
• Location – anonymous pub/sub
• Redundancy – any number of
readers & writers
• Time – asynchronous, timeindependent data distribution
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
• Platform – similar to CORBA
middleware
4
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
• 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 …
• Request/offered compatibility checked by DDS at Runtime
• Consistency checked by DDS at Runtime
5
QoS Policy Configuration Challenges
Reliable data
transfer
requested
• QoS Policy
Compatibility
Best effort data
transfer offered
• QoS policies for the
communicating entities
must be compatible
between what’s
requested and offered
X
Data will not be
transferred
Deadline’s period =
5 ms.
Time based filter’s
minimum separation =
10 ms.
X
QoS 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
6
DDS QoS Modeling Language (DQML 1 of 2)
Focus on “correct by construction” – check for errors at design-time
• Models relevant DDS
entities
• Models DDS QoS polices
as first class entities
• Models relationships between
entities and QoS policies
7
DDS QoS Modeling Language (DQML 2 of 2)
• Supports QoS compatibility
and consistency constraint
checking
• Generates implementation artifacts
(currently for DDS Benchmarking
Environment (DBE))
DBE
Interpreter
DataReader
QoS Settings
DBE
DataWriter
QoS Settings
8
Ongoing Work: DQML + Service Orchestration
Component Package
Component
Component
Component
Assembly
Component
Assembly
Component
Component
Component
Component
Component
cka
s
ML
ge
)
Component
(PICML)
assembly
Component
ka
ac
sp
gu
CoSMIC
ec
ific
ati
on
Component
Developer
fee
a
db
ck
Assembly
Component
Deployer
ra t
ion
(6) deployment
Deployment
Application
RACE Framework
(5)
planning
n
si g
d e a ck
(9 ) e d b
fe
(1)
g confi
Deployment
Planner
y  f ( x1 , x2 ,... xn )
(8) reconfiguration
& replanning
Component
Assembler
gin
de
ve
lop
ML
s
&
PI
CM
L)
Component
Assembly
Component
p
(2) assembles
(ID
Component
Assembly
DAnCE
Framework
Assembly
Component
Imp
Imp
Imp
l
l
l
Resource
Requirements
Work supported
by DARPA PCES
& ARMS
Programs
Component
Configurator
pa
IC
(P
(4
)c
on
(O
fig
CM
ur
es
L,Q
oS
ML
)
(3)
Component
Packager
planning
Component
(7) analysis &
benchmarking
System
analyzer
(Cadena & BGML)
Properties
Analysis & Benchmarking
•
•
•
•
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
9
Concluding Remarks
• QoS configuration management
is a significant challenge for pubsub systems
• Need design-time tools to
automate the QoS configuration
management
• Need tools to assure “correct-byconstruction” systems
• Model-driven Engineering is a
promising approach
DataReader
QoS Settings
Invoke the DBE
Interpreter
DBE
QoS Settings DataWriter
10