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 ISIS, Dept. of EECS Vanderbilt University Nashville, Tennessee June 21, 2007 DEBS 2007, Toronto, Canada

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 Logical Data Store read 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 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

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)) DBE Interpreter DBE QoS SettingsDataReaderQoS Settings DataWriter

9 Ongoing Work: DQML + Service Orchestration 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 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 Invoke the DBE Interpreter DBE QoS Settings DataReader DataWriter