1 / 10

A QoS Policy Modeling Language for Publish/Subscribe Middleware Platforms

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

stew
Télécharger la présentation

A QoS Policy Modeling Language for Publish/Subscribe Middleware Platforms

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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 Mapping problem artifacts to solution artifacts is hard Challenges in Realizing DRE Systems • Variability in the problem space (domain expert role) • Functional diversity • Composition, deployment and configuration diversity • QoS requirements diversity

  4. Application Application read write write Logical Data Store Application write write Application read read Application 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. Reliable data transfer requested Best effort data transfer offered Data will not be transferred X Deadline’s period = 5 ms. Time based filter’s minimum separation = 10 ms. X QoS policies will not be set QoS Policy Configuration Challenges • QoS Policy Compatibility • QoS policies for the communicating entities must be compatible between what’s 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. QoS Settings QoS Settings DataReader DataWriter 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 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

  10. QoS Settings QoS Settings Invoke the DBE Interpreter DBE DataReader DataWriter 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

More Related