quality objects: advanced middleware for large scale wide area distributed applications

1 Quality Objects: Advanced Middleware for Wide Area Distributed Applications Rick Schantz

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.

[email protected]


Overview of Talk

• Problem Description & Role of Middleware

• QuO as Essential Middleware

• Current QuO Activities

• Summary


Current and Future Distributed Systems have Critical Performance and Dependability Requirements

CINCJ2

CINC OperationsPlanning Group

OPS/ INTELWORKSTATION

TARGET

CJTFPlanners

TARGET

MissionsCenters of GravityTask refinementForces refinementPhases refinementCOA evaluationCOA selection

FLTCINC MaritimePlanning Center

TMS CASES & HPC

Maritime & AirCampaign Assessment

JOINT FORCE MARITIMECOMPONENT CMDR

CASES TARGET

Task refinementIntegrated Target PrioritiesForces refinementSchedule refinementCOA evaluation

JOINT FORCE AIRCOMPONENT CMDR

TARGET ACPT

IDB

MissionsCOAsStrategy

Crisisassessment

COA evalCOA eval AirMar

XIDB

Target Nomination ListMaster Attack PlanAttack Plan Status

JFACCCombat Ops

Target Nomination ListWeaponeering

XIDB

APS/FLEX

TAMPS/COMPASS

JMCISIDB

Air Tasking Order (ATO)

NATOOPS/INTELWORKSTATION

Rear-echelonSim Center

toSHAPE

MasterTargetList

APS/FLEX RAAP

Refinement& eval

collaborative development

rehearse

Refinement& eval

ATO

Target data / Weaponeering


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


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

Host1

Client1

Host2

Client2

Host4

Client3

ObjectResource ConstrainedWide Area Network LAN

Host3

Client4


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


Managing System Properties Involves Cooperation Between Many Parties

GUI ?

A Mode

B Mode

C Mode

ADVISE

EN

FO

RC

E

ADVISE

EN

FO

RC

E

?X Behavior

Y Behavior

Z Behavior

DB

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

LimitedComms

QuO Framework supports multiple roles, such as user, application developer, object developer, mechanism developer, and Qosketeer


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

Dispatch

XBehavior

YBehavior

ZBehavior

Measure

Enforce

Service

Comms Resources

SystemProperties

User

Environment

Service

Client


QuO Clients Connect to CORBA Objects using Functional and Quality Interfaces

A QuO Connection logically moves the object into the client’s address space

The QuO Connection integrates the individual QoS agreements for the Network, Client, and Server, by using a contract

RemoteObject

Network

Server ORB

Client ORB

QuO Delegate

ClientFunctional Quality

QuO Delegate

Interface Description LanguageDefines the Functional Interface

Quality Description Language Defines the System InterfaceIDL QDL

QuO helps spread the object’s functionality to the most desirable location; extending the strict Client-Server implementation of the object

The Client sees NO change in the functional interface,I.e. the language bindings are the same


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


Contracts Summarize System Conditions into Expected and Reality Regions and Define Transitions Between Them

Normal:Expected capacity >= 10

Measured capacity >= 10

As_expected:

Insufficient_resources:Measured capacity < 10

Degraded:Expected capacity < 10Expected capacity >= 2

As_expected:

Extra_resources:

Measured capacity < 10Measured capacity >= 2

Measured capacity < 2

Insufficient_resources:


Unusable:Expected capacity < 2

As_expected:

Extra_resources:

Measured capacity < 2


•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

= Expected Region

=Reality Region


Delegates Change Their Behavior Based on Their Contract’s Current Regions

Dispatch

ContractPa

ss T

hrou

gh

Blo

ck

Shap

e

PreMethodMeasurements

Method Call

Lower Method Call

Current Regions

Result

Lower Result

SysCond

SysCond

Current Regions

PostMethodMeasurements

Delegate

AlternativeBehaviors


The Status of an Object’s Complex Execution Environment is Summarized in Contracts

Logical Method Call

SysCon

SysCon

Client Network Server

SysCon

Client Object

Delegate

ORBProxy

Specialized ORB Specialized ORB

ApplicationDeveloper

Qoskateer

Mechanism Developer

Resource ControlWrapper

Network

Contract Contract

SysCon

SysCon

SysCon

Delegate

ORBProxy

SysCon


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

Implementation

CDL SDL RDL

QDLIDL

QDL + IDLCompiler

SurvivableSystem

QuO Runtime

ORB


contract contract_name (syscond idl_type impl_type sc_name,syscond nowatch idl_type impl_type sc_name,callback idl_type cb_name, ... ) is

syscond idl_type impl_type name( arg, ... );static syscond idl_type impl_type name( arg, … );...tag regions are

region_name :when condition =>

tag regions areregion_name :

when condition => ...

precedences region_name ...;transitions are

transition region_name->region_name :synchronous

cb_name.callback(arg, ...);...

asynchronouscb_name.callback( arg, ... );...

transition any->name :...

transition name->any :...

transition inactive->name :...

transition name->inactive :...

end transitions;end tag regions;

region_name : when condition => tag regions are separate;

precedences region_name ...;transitions are

...end tag regions;

end contract_name;

separate tag regions for region_name are ...end tag regions;


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

Quality Objects in QuO

quality objects: advanced middleware for large scale wide area distributed applications

Documents