Quality Objects: Advanced Middleware for Large Scale Wide Area Distributed Applications

1. Quality Objects: Advanced Middleware for Large Scale Wide Area Distributed Applications • Dr. Richard E. Schantz • BBN Technologies (aka the BBN part of GTE) • Cambridge, Mass. • schantz@bbn.com

2. Overview of Talk • Problem Description & Role of Middleware • QuO as Essential Middleware • Current QuO Activities • Summary

3. CINC CINC Operations Planning Group CJTF Planners J2 Missions Centers of Gravity Task refinement Forces refinement Phases refinement COA evaluation COA selection IDB Crisis assessment OPS/ INTEL WORKSTATION TARGET TARGET COA Air COA eval eval Mar Missions COAs Strategy FLTCINC Maritime Planning Center JOINT FORCE MARITIME COMPONENT CMDR JOINT FORCE AIR COMPONENT CMDR Maritime & Air Campaign Assess ment Refinement & eval XIDB Refinement & eval Task refinement Integrated Target Priorities Forces refinement Schedule refinement COA evaluation CASES TARGET TMS CASES & HPC TARGET ACPT Target data / Weaponeering Master Target List TAMPS/ COMPASS ATO JFACC Combat Ops Rear-echelon Sim Center JMCIS IDB rehearse XIDB collaborative development APS/FLEX Target Nomination List Master Attack Plan Attack Plan Status to NATO OPS/INTEL WORKSTATION Air Tasking Order (ATO) APS/FLEX RAAP SHAPE Target Nomination List Weaponeering Current and Future Distributed Systems have Critical Performance and Dependability Requirements

4. Middleware Has Emerged to Help Solve Heterogeneity and Distribution Problems • Middleware has made programming distributed applications easier • Standard programming interfaces hide platform and system dependencies • Standard protocols, e.g., message formats, allow applications on different systems to interoperate • Provides higher level, application oriented programming building blocks • However, current middleware has limitations in building wide-area, complex, distributed systems • Little or no control over non-functional system behavior, such as performance, dependability, and fault tolerance • No support for building systems that can adapt to changing environments • Little support for reusing code in new environments

5. Host4 Host1 Object Client1 Client4 Resource Constrained Wide Area Network LAN Host2 Host3 Client2 Client3 The Problem: Wide-Area Distributed Applications Are (Still) Hard to Build and Maintain • WANs are dynamic with uncertain and sometime intermittent behavior • Hosts span a wide range of platforms and resources • Changing requirements and configurations • Mission critical properties addressed in isolation • Complex interactions in a mobile environment

6. Quality Objects (QuO) as an Organizing Architecture for Integrated System Properties • The goal: Predictable and integrated behavior under uncertain circumstances • The approach: Adding Quality of Service attributes to Distributed Object Computing • QuO Architecture initiates the integration of various dimensions of quality for distributed objects • Underway: Managed communication performance, dependability, information assurance • Other important aspects: real-time constraints, security, ... • Integration Architecture and Framework (in progress): QuO

7. Managing System Properties Involves Cooperation Between Many Parties ADVISE ADVISE G U I ENFORCE A Mode Limited Comms X Behavior D B ENFORCE ? ? B Mode Y Behavior C Mode Z Behavior • User • Understands Impact of Behavior • Changes Behavior • Application • Supports alternative user behavior • Translates System limitations into user terms • Infrastructure • Advises about resource status • Enforces application’s contracts with Comms Resources • Service • Optimize Object Implementation based on available system resources QuO Framework supports multiple roles, such as user, application developer, object developer, mechanism developer, and Qosketeer

8. QuO Middleware Organizes Elements Required for Adaptable Behavior in a Reusable Manner • Organizes System Properties • Observe • Ensure consistency between roles • Translate • Actively negotiate • Execute Behavior • Change policy • Control resources • Emit Events • Reevaluate observations • Change reservations • Recover From Errors • Mask undesirable behavior Client User Dispatch System Properties X Behavior Y Behavior Z Behavior Environment Measure Comms Resources Enforce Service Service

9. Network QuO Clients Connect to CORBA Objects using Functional and Quality Interfaces Functional Quality Client Quality Description Language Defines the System Interface Interface Description Language Defines the Functional Interface IDL QDL The Client sees NO change in the functional interface, I.e. the language bindings are the same QuO Delegate A QuO Connection logically moves the object into the client’s address space Client ORB QuO helps spread the object’s functionality to the most desirable location; extending the strict Client-Server implementation of the object Server ORB QuO Delegate The QuO Connection integrates the individual QoS agreements for the Network, Client, and Server, by using a contract Remote Object

10. Key Abstractions: Operating Regions & Measurement Objects • The quality engineer designs sets of regions, each describing a state in which the contract can exist with regard to QoS • Negotiated regions represent agreements concerning the levels of service a client expects to receive and a server expects to provide • Reality regions represent actual levels of service that are observed during system and contract execution • System conditions represent object expectations and observed resource behavior • Changes in object expectations trigger transitions between negotiated regions • Changes in observed resource behavior trigger transitions between reality regions

11. Contracts Summarize System Conditions into Expected and Reality Regions and Define Transitions Between Them • Contracts will break in hostile and dynamic WANs • Commitment epochs represent the stability of system properties at different time scales • Regions summarize system conditions by using a predicate to bound their range • Transitions occur when one region becomes invalid and another becomes valid Degraded: Expected capacity < 10 Expected capacity >= 2 Unusable: Expected capacity < 2 Normal: Expected capacity >= 10 As_expected: As_expected: As_expected: Measured capacity >= 10 Measured capacity < 10 Measured capacity >= 2 Measured capacity < 2 Insufficient_resources: Extra_resources: Extra_resources: Measured capacity < 10 Measured capacity >= 2 Measured capacity >= 10 Insufficient_resources: = Expected Region Measured capacity < 2 =Reality Region

12. Delegates Change Their Behavior Based on Their Contract’s Current Regions Method Call SysCond Result PreMethod Measurements Delegate Contract Current Regions Dispatch Alternative Behaviors Current Regions Pass Through Block Shape PostMethod Measurements SysCond Lower Result Lower Method Call

13. Contract Contract Network The Status of an Object’s Complex Execution Environment is Summarized in Contracts Application Developer Logical Method Call Object Client SysCon SysCon Delegate Delegate SysCon SysCon SysCon SysCon SysCon Qoskateer Resource Control Wrapper ORB Proxy ORB Proxy Mechanism Developer Specialized ORB Specialized ORB Client Network Server

14. Implementation QDL IDL RDL CDL SDL QDL + IDL Compiler QuO Runtime Survivable System ORB QuO’s QoS Description Language (QDL) • Contract Description Language (CDL) - describes expectations of clients and servers and regions and transitions for adapting to changing levels of service • Structure Description Language (SDL) - describes objects’ internal structures and resource requirements • Resource Description Language (RDL) - describes available system resources and their status

16. Quality Objects in QuO • Provides mechanisms for: • distributed applications to provide expectations to the system regarding the quality of service they desire • the system to inform applications of the quality of service they obtain • adaptation under changing fault, workload, and environmental conditions • Gives applications simplified awareness of system conditions, without total responsibility for managing quality • Permits system to effectively manage applications’ desires in changing system condition. • Makes use of multiple simple languages (for contract specification now, for configuration issues later)