BBN Technologies Craig Rodrigues Gary Duzan QoS Enabled Middleware: Adding QoS Management Capabilities to the CORBA Component Model Real-time CCM Meeting March 1, 2003

Presentation Outline Overview of what CCM offers to DRE application developer Description of what CCM lacks in terms of QoS Management features Description of QoS Management strategies (in-band, out-of- band) Description of cross-cutting nature of QoS Management –QoS management across multiple components –QoS management between components and containers Further references and standards activity

CCM Benefits for DRE Systems DRE systems consist of many Resource Consuming Components (RCC) An RCC is a processing entity which cooperates with other entities in the execution of a certain activity, and consumes some type of system resource (ie. CPU, network, etc.) CCM allows us to: –Specify the properties of an RCC –Specify the services offered by the RCC (facets) and services required by the RCC (receptacles) –Specify how an RCC can be connected to other components in a larger system (assembly)

CCM lacks features for Specifying QoS for Resource Consuming Components CCM does not give us: –Ways to specify end-to-end QoS requirements, i.e. QoS Characteristics and QoS Values –Ways to specify adaptation strategies for how RCC’s can coordinate with other entities in order to meet QoS requirements –Ways to specify QoS management which cross multiple system and application level boundaries

QoS Management in DRE Systems Managing end-to-end QoS involves managing resources which cross multiple system and application-level boundaries Network-level resource management –QoS specific protocols such as RSVP and Diffserv –Enhanced transport protocols (SCTP) –Traffic shapers and firewalls Processor-level resource management –CPU scheduling strategies –CPU reservations Resource management of application specific behaviors –Frame dropping –Compression

CCM Should Allow QoS Management to Cross-Cut Components QoS is a cross-cutting concern that can affect the interaction between multiple components CCM must allow for complex component interactions that will result from implementing cross-cutting QoS management QoS Management Infrastructure QoS Management Infrastructure Client Component Service A Component Service B Component Service C Component

QuO Extends the Distributed Object Model to Provide QoS Management Application Developer Mechanism Developer CLIENT Network operation() in args out args + return value IDL STUBS IDL SKELETON OBJECT ADAPTER ORB IIOP ORB IIOP CLIENT OBJECT (SERVANT) OBJECT (SERVANT) OBJ REF CLIENT Delegate Contract SysCond Contract Network MECHANISM/PROPERTY MANAGER operation() in args out args + return value IDL STUBS Delegate SysCond IDL SKELETON OBJECT ADAPTER ORB IIOP ORB IIOP CLIENT OBJECT (SERVANT) OBJECT (SERVANT) OBJ REF Application Developer QuO Developer Mechanism Developer CORBA DOC MODEL QUO/CORBA DOC MODEL

Adding QoS Management Capabilities to the CORBA Component Model Application Developer Mechanism Developer Network COMPONENT SKELETON OBJECT ADAPTER ORB IIOP ORB IIOP Application Developer QoS Component Developer Mechanism Developer COMPONENT MODEL QUO/COMPONENT MODEL in argsout args + return value Client/Source Component events Server/Sink Component COMPONENT STUBS Contract Component SysCond Network MECHANISM/PROPERTY MANAGER COMPONENT STUBS SysCond COMPONENT SKELETON ORB IIOP ORB IIOP in argsout args + return value Client/Source Component events Server/Sink Component Delegate Component OBJECT ADAPTER Contract Component

Important Places where QoS Can Be Inserted in a Component-based DRE Application Interaction between components (in-band) Interaction between components and environment (out-of- band) Interaction between components and containers

QuO Provides In-Band and Out-of-Band Adaptation and Control In-band adaptation provided by the delegate and gateway –A delegate decides what to do with a method call or return based upon the state of its contract Out-of-band adaptation triggered by transitions in contract regions –Caused by changes in the system observed by system condition objects

Adding QoS Management Between Components (in-band) Modeling QoS infrastructure as components allows us to use standard component assembly mechanisms to introduce QoS behaviors to component-based DRE applications Contract Component SysCond Network MECHANISM/PROPERTY MANAGER COMPONENT STUBS SysCond COMPONENT SKELETON ORB IIOP ORB IIOP in argsout args + return value Client/Source Component events Server/Sink Component Delegate Component OBJECT ADAPTER Contract Component

Adding QoS Management between Components and Environment (out-of-band) Changes in environment as detected by monitoring SysConds (sensors) trigger adaptive behaviors through Callbacks (actuators) Contract Component SysCond Network MECHANISM/PROPERTY MANAGER COMPONENT STUBS SysCond COMPONENT SKELETON ORB IIOP ORB IIOP in argsout args + return value Client/Source Component events Server/Sink Component Delegate Component OBJECT ADAPTER Contract Component

Inserting QoS Management Capabilities into CCM between Components and Containers ORB RT TraderRT Scheduling 2.0CPU SchedulingFT/RT Event ClientClient Container CORBA Component Home POA Container API Container API QoS Management

QoS Management Behaviors can be Added to CCM by Using Reusable “Qoskets” Qosket bundles a set of contracts (CDL), system condition objects (IDL), and QoS adaptive behavior (ASL) Qosket provides reusable QoS Management behavior to application Qoskets are cross-cutting, their interfaces will not map directly to CCM interfaces Qosket Contracts SysConds Callback Objects Delegate Templates Contract Component SysCond Network MECHANISM/PROPERTY MANAGER COMPONENT STUBS SysCond COMPONENT SKELETON ORB IIOP ORB IIOP in argsout args + return value Client/Source Component events Server/Sink Component Delegate Component OBJECT ADAPTER Contract Component

Conclusions Integrating QoS management into the CORBA Component Model will be important for developing component-based DRE applications QuO offers a middleware framework for QoS-enabled applications QuO functionality integrated with CCM would provide more flexible and reusable QoS Management behaviors

Further References and Ongoing Standards Activity CORBA Component Model specification, Quality of Service for CCM draft RFP, UML Profile for QoS and FT Characteristics and Mechanisms, RFP response –Co-authored by I-Logix, THALES, Tri-Pacific –Supported by Lockheed Martin, ARTISAN, Softeam, and others

Extra slides

Overview of Quality of Service Terminology and Concepts * * source: UML Profile for QoS RFP response

QoS: Basic Terminology QoS Characteristics –Represent quantifiable characteristics of services. –Specified independently of the elements they qualify, and represent non-functional aspects such as: –Latency, Throughput, Capacity –Availability, Reliability, Integrity, Safety –Error probability, Accuracy –Confidentiality, Access Control

QoS: Basic Terminology QoS Value Definitions –Quantification of QoS Characteristics – for latency, we can quantify end-to-end delay of a function, the mean time of all executions, or the variance of time delay QoS Capability –A way of grouping together QoS Characteristics for large, complex systems which may have many QoS Characteristics –Performance: refers to timeliness aspects of a system, and incorporates characteristics such as latency and throughput –Dependability: refers to the reliability of the service provided by a system, and incorporates characterstics such as: availability, reliability, safety, integrity –Security: incorporates characteristics such as access control and confidentiality

QoS: Basic Terminology QoS Contract –System requirements that include restrictions that the system must adhere to –Can be specified in terms of QoS Values, which restrict QoS Characteristics, such as maximum latency