A QoS Policy Modeling Language for Publish/Subscribe Middleware Platforms

1
A QoS Policy Modeling Language for
Publish/Subscribe Middleware Platforms
Joe Hoffert, Doug Schmidt Aniruddha
Gokhale jhoffert,schmidt,gokhale_at_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
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
Challenges in Realizing DRE Systems

• Variability in the problem space (domain expert
  role)
• Functional diversity
• Composition, deployment and configuration
  diversity
• QoS requirements diversity

4
The OMG Data Distribution Service (DDS)

• 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 whats requested and offered

• 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)
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

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))

DBE Interpreter
DBE
9
Ongoing Work DQML Service Orchestration
Work supported by DARPA PCES ARMS Programs

• CoSMIC tools e.g., PICML used to model
  application components, CQML for QoS
• Captures the data model of the OMG DC
  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
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