Specifying and Measuring Quality of Service
in Distributed Object Systems

Joseph P. Loyall
Richard E. Schantz
John A. Zinky
David E. Bakken

BBN Technologies
10 Moulton Street, Cambridge, Mass. 02138 U.S.A.

Email: jloyall@bbn.com, schantz@bbn.com, jzinky@bbn.com, dbakken@bbn.com

Distributed applications are difficult to build and maintain and are even more difficult when the applications are distributed over wide-area networks. Distributed Object Computing middleware has emerged to simplify the building of distributed applications by hiding implementation details behind functional interfaces. However, critical applications have non-functional requirements, such as real-time performance, dependability, or security, that are as important as the functional requirements, but are also hidden by the middleware. Because current distributed object middleware doesn't support these aspects of critical applications, application developers often find themselves bypassing the distributed object systems, effectively gaining little or no advantage from the middleware. We have developed Quality Objects (QuO), a framework for including Quality of Service (QoS) in distributed object applications. QuO supports the specification of QoS contracts between clients and service providers, runtime monitoring of contracts, and adaptation to changing system conditions. A crucial aspect of QuO is a suite of Quality Description Languages for describing states of QoS, system elements that need to be monitored to measure the current QoS, and notification and adaptation to trigger when the state of QoS in the system changes. This paper gives a brief overview of QuO and describes the syntax and semantics of CDL, the component of QDL for describing QoS contracts.

This work is sponsored by by the Defense Advanced Research Projects Agency under Contracts No. N66001-96-C08529 monitored by NRaD, No. F30602-96-C-0315 monitored by US Air Force Research Laboratory, and No. F30602-97-C-0276 monitored by US Air Force Research Laboratory.

Keywords: CORBA, quality of service, QoS, distributed object computing

1. Introduction

Distributed applications are becoming more prevalent in both local-area networks (LANs) and wide-area networks (WANs) despite the added complexity in developing and maintaining them. Distributed object middleware, such as CORBA [9], has contributed to the prevalence of distributed applications by simplifying their development and maintenance in the following ways:

Object implementations and their interfaces are developed separately, facilitating abstract design of an application's component objects and their interactions without worrying about the low-level specifics of how each object accomplishes its function
Implementation languages, operating systems, and computer architectures are hidden from the application developer, who is building the application at the object interface level
Standard interface definitions and code generators enable heterogeneous objects to interoperate without regard to their implementation details, platform or system dependencies, or distribution across the network.

However, there are increasingly more distributed applications that have quality of service (QoS) requirements along with functional requirements. Applications such as multimedia, video-on-demand, national security, military, health care, medical, and financial systems often have critical requirements, such as real-time performance, synchronization of data, security, dependability, and fault tolerance. Distributed object middleware falls short in providing support for QoS requirements because it hides the details necessary to specify, measure, and control QoS and does not provide support for building systems that can adapt to different levels of QoS. Because of this, developers of critical applications often find themselves programming around the distributed object systems, effectively gaining little or no advantage from the middleware. The problem gets worse when an application is distributed over a WAN, which is inherently more dynamic, unpredictable, and unreliable than a LAN.

We have developed Quality Objects (QuO), a framework for including QoS in distributed object applications [16]. QuO provides an environment in which a programmer can specify possible QoS states, the system elements that need to be monitored and controlled to measure and provide QoS, and behavior for adapting to changes in QoS. In this way, QuO opens up distributed object implementations [4, 7], providing control of both the functional aspects of a program and its implementation strategies, which are often hidden behind IDL interfaces. QuO also supports aspect-oriented programming [5], in which a program is divided into aspects of concern, each of which are programmed separately in a suitable language and then weaved together into a single application. QuO provides a suite of description languages for describing aspects of the QuO application and code generators that weave them together.

In this paper, we give an overview of the QuO framework and describe one of its main components, the Contract Description Language for describing QoS contracts. Section 2 introduces and describes the QuO framework. Section 3 describes QuO's Contract Description Language (CDL) component. Section 4 illustrates CDL and QuO with an application requiring resource reservation. Section 5 describes work related to QDL. Finally, Section 6 provides some concluding remarks.

2. Overview of the QuO framework

QuO is a framework supporting the development of distributed applications with QoS requirements. QuO provides the ability to specify, monitor, and control aspects of the QoS in an application, similar to the way in which application code and IDL, ORBs, and operating systems specify, monitor, and control the functional behavior. We give a brief overview of QuO in this section. More detailed discussion can be found in [16].

2.1 Execution model of a QuO application

In a traditional CORBA application, a client makes a method call on a remote object through its functional interface. The call is processed by an ORB on the client's host, delivered to an ORB on the object's host, and processed by the remote object. The client sees it strictly as a functional method call. As indicated in Figure 1, a QuO application adds additional steps to this process. The QuO application not only consists of the client program, ORB, and object, it also has the following components provided by the QoS developer:

A local delegate of the remote object. The delegate provides a functional interface identical to the remote object, but can trigger contract evaluation upon each method call and return. The QoS developer can provide alternative behaviors and a dispatch statement which chooses among the alternatives based upon the current state of the contract.
A QoS contract between the client and object. This specifies the level of service desired by the client, the level of service the object expects to provide, operating regions indicating possible measured QoS, and actions to take when the level of QoS changes.
System condition objects interface between the contract and resources, mechanisms, objects, and ORBs in the system. These are used to measure and control QoS.

Figure 1: A remote method invocation in a QuO application

Figure 2 illustrates the steps that can occur during a remote method call in a QuO application. When a client calls a remote method, the call is passed to the object's local delegate instead. This is transparent to the client, since the remote object and the delegate have the same interface. The delegate can trigger contract evaluation, which grabs the current value of all system conditions measuring aspects of the system's state. The contract consists of a set of nested regions which describe the relevant possible states of QoS in the system. Each of these regions is defined by a predicate on the values of system condition objects. The contract evaluates the predicates to determine which regions are active (i.e., their predicates are true) and passes the list to the delegate.

Figure 2: Example remote method call in a QuO application

The delegate chooses how to process the method call based upon the current regions. For example, the delegate might choose between alternate methods, might block or buffer when QoS has degraded, or might simply pass the call through to the remote object. The delegate performs similar processing upon a method return, i.e., it evaluates the contract to obtain the current QoS regions and selects a behavior based upon the current regions.

Contract evaluation can also be triggered by changes in some system condition objects, i.e., those that are observed by the contract. Other system condition objects, especially those whose values change frequently, are non-observed and do not trigger contract evaluation. Regardless of how contract evaluation is triggered (by a method call/return or change in a system condition), a transition from one active region to another can trigger transition behavior, which consists of client callbacks or method calls on system condition objects.

The QuO kernel is multi-threaded, with a single thread that evaluates contracts and snapshots the values of system condition objects serially. Many system condition objects and remote method calls run in other, separate threads. The current prototype implementation of QuO runs under Linux and Solaris, using Visigenic's Java ORB, Visibroker.

2.2 QuO framework support for building QuO applications

As indicated in Figure 1, the development of QuO applications requires an additional role over those necessary to build a distributed application:

Application developers who develop functional code for the clients and distributed objects;
QoS developers who develop QuO contracts, system condition objects, callback mechanisms, and object delegate behavior; and
Mechanism developers who develop system components, ORB wrappers, mechanisms, and libraries providing access to or control of system- or ORB-level capabilities.

To support the added role of QoS developer, the QuO framework consists of the following components:

A suite of Quality Description Languages (QDL) for describing contracts, system condition objects, and the adaptive behavior of objects and delegates
The QuO kernel, which coordinates evaluation of contracts and monitoring of system condition objects
Code generators which weave together QDL descriptions, the QuO kernel code, and client code to produce a single application program.

QDL currently consists of a Contract Description Language (CDL), a Structure Description Language (SDL), and a Resource Description Language (RDL). CDL is used to describe the QoS contract between a client and an object, including the QoS that the client desires from the object; the QoS that the object expects to provide; regions of possible levels of QoS; system conditions that need to be monitored; and behavior to invoke when client desires, object expectations, or actual QoS conditions change. The CDL syntax and semantics are described in Section 3. The CDL code generator generates Java code for contract classes and instances from CDL descriptions.

SDL describes the internal structure of remote objects' implementations, such as implementation alternatives, and the adaptive behavior of object delegates. We currently have an object delegate generator that generates client-side and server-side object delegate code from SDL, CDL, and IDL code. RDL describes the resources available in the system and their status. SDL and RDL are currently under development.

Continuing work on contracts and CDL will address translation between low-level information into application-level information, e.g., network packets into message invocations; negotiation of QoS attributes, e.g., when the client and object have different expectations; and implementation optimizations.

Information in a QuO application is bound at the following different times, according to when it is available and when it is needed:

development time - constant information encoded into the application code, contract, or static system conditions; information such as boundary constants, architecture specifications, or static operating ranges.
configuration time - information available when the application is targeted for a particular configuration, such as a particular ORB and network.
initialization time - information available when a client binds to a remote object using a contract object. This includes information such as contract parameters, initial client and object expectations, system condition initialization information, delegate creation arguments, and ORB bind arguments.
negotiation time - information pertaining to the QoS desired by the client and the QoS that the remote object expects to provide. This information can be expected to change during system execution, although not necessarily frequently. The client and object can change their operating modes, either to adapt to changing QoS or because of their algorithmic needs.
reality time - information about the measured QoS in the system. This information might change frequently during system execution, often in response to external factors, such as other processes competing for resources or resource failures. At other times measured QoS can be affected by system condition, client, or object behavior, such as a client requesting and receiving a number of replicas from a replication ORB or a reserved communication path from an RSVP process.

3. Contract Description Language (CDL)

CDL is a language for specifying a QoS contract between a client and object in an application. The contract describes the QoS that the client desires and that the object expects to provide in terms of a set of operating regions; behavior to invoke to adapt to or notify of changes in QoS; and interfaces to elements of the system that can be used to measure and control QoS.

3.1 Elements of a CDL contract

A QuO contract consists of the following components:

a set of nested operating regions, each representing a possible state of QoS. Each region has a predicate indicating whether it is active (the predicate is true) or not (the predicate is false).
transitions for each level of regions, specifying behavior to trigger when the active region changes.
references to system condition objects for measuring and controlling QoS. These are either passed in as parameters to the contract or declared local to the contract. System condition objects are used in the predicates of regions to get values of system resources, object or client state, etc. and used in transitions to access QoS controls and mechanisms.
callbacks for notifying the client or object. Callbacks are passed in as parameters to the contract and are used in transitions.

The contract organizes the possible states of QoS, the information needed to monitor and control it, the actions to take when QoS changes, and the times at which information is available. The nesting of regions can be used to arrange regions according to logical groupings of information or time. For example, the contract in Figure 3 contains two sets of nested regions, an outer nesting called negotiated regions and an inner nesting called reality regions. The negotiated regions represent the QoS desired by the client and the QoS that the remote object expects to provide and their predicates consist of system condition objects that interface to the client and object. The reality regions represent the QoS measured in the system and have predicates consisting of system condition objects that interface to system resources. This grouping distinguishes the QoS associated with operating modes of the client and object, which will likely change infrequently, from the measured QoS of the system, which will probably change more frequently.

A programmer programs a contract class in CDL, similar to the way a C++ or Java programmer programs an object class instead of an object instance. At runtime, a connection between a client and an object is established, creating an object delegate instance, and creating a contract instance and passing in pointers to the client's expectations, client's callbacks, and any other necessary system condition objects or callbacks. If necessary, relevant system condition objects, i.e., system condition objects local to the contract instance, are created and/or connected to the contract instance.

contract repl_contract( 
    syscond  ValueSC ValueSCImpl ClientExpectedReplicas,
    callback AvailCB ClientCallback,
    syscond  ValueSC ValueSCImpl MeasuredNumberReplicas,
    syscond  ReplSC ReplSCImpl ReplMgr ) is

  negotiated regions are
    region Low_Cost : when ClientExpectedReplicas == 1 =>
      reality regions are
        region Low    : when MeasuredNumberReplicas < 1 =>
        region Normal : when MeasuredNumberReplicas == 1 =>
        region High   : when MeasuredNumberReplicas > 1 =>
        transitions are
          transition any->Low    : ClientCallback.availability_degraded();
          transition any->Normal : ClientCallback.availability_back_to_normal();
          transition any->High   : ClientCallback.resources_being_wasted();
        end transitions;
      end reality regions;
    region Available : when ClientExpectedReplicas >= 2 =>
      reality regions are
        region Low    : when MeasuredNumberReplicas < ClientExpectedReplicas =>
        region Normal : when MeasuredNumberReplicas >= ClientExpectedReplicas =>
        transitions are
          transition any->Low    : ClientCallback.availability_degraded();
          transition any->Normal : ClientCallback.availability_back_to_normal();
        end transitions;
      end reality regions;
    transitions are
      transition Low_Cost->Available : 
        ReplMgr.adjust_degree_of_replication(ClientExpectedReplicas);
      transition Available->Low_Cost :
        ReplMgr.adjust_degree_of_replication(ClientExpectedReplicas);
    end transitions;
  end negotiated regions;
end repl_contract;

Figure 3: A Sample CDL Contract - Replication

3.2 A simple CDL example contract

Figure 3 illustrates a sample CDL contract with CDL keywords in boldface. This contract specifies and controls replication for a QuO application. The client has two operating modes, one in which it desires a high level of availability from the remote object and another in which it does not require the high level of availability and desires to use fewer resources. This contract is simple, the client either requests one replica (encoded as the Low_Cost region) or more than one replica (encoded as the Available region). Each negotiated region has a set of reality regions, representing when the measured replication is lower than, higher than, or exactly as desired.

The negotiated region predicates use the client's expectation system condition object, ClientExpectedReplicas. It is passed as an argument to the contract because it is probably shared by all the contracts in which the client is involved, and therefore must be created outside the contract. The reality region predicates use a system condition object called MeasuredNumberReplicas, which observes the actual number of replicas.

The reality region transitions notify the client about changes in the number of replicas. The negotiated region transitions access mechanism routines to control the level of replication. A transition to either of the Low regions notifies the client via the callback method availability_degraded. A transition to either of the Normal regions notifies the client via the callback method availability_back_to_normal. The keyword any is used to indicate that the contract and client don't care in which region the transition originated. Callback behavior is specified in the callback code (probably in the client or a separate object).

The negotiated region transitions use a replication policy manager system condition object, ReplMgr, that is passed into the contract. This system condition object provides methods to suggest to the replication policy manager changes in the amount of replication. When the client changes its desired replication, causing a transition between negotiated regions, the method adjust_degree_of_replication is called to suggest a new level of replication.

3.3 CDL syntax and semantics

Figure 4 illustrates the representative syntax of a CDL contract. The contract definition starts with the contract keyword, followed by the name of the contract class and the list of contract parameters. The contract parameters are system condition objects and callback objects that are created outside the contract and passed in (e.g., because they are shared with other contract instances, the client, or other objects in the system). The contract parameters are one of the following forms:

syscond [nowatch] idl_type impl_type name
callback idl_type name

The tag syscond or callback indicates whether the parameter is a system condition object or a callback object; idl_type is the IDL class of the object; and name is the name by which the object is referenced in the contract. If the parameter is a system condition object, the name of the implementation class must also be specified (impl_type). System condition objects can also be observed (i.e., a change in the system condition object triggers contract evaluation) or not (i.e., changes in the system condition object go unnoticed until the next contract evaluation). The default is for each system condition object to be observed. The optional keyword nowatch tags the system condition object as non-observed.

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 predicate =>
      tag regions are
        region_name : when predicate =>
        ...
        precedences region_name ...;
        transitions are
          transition region_name->region_name :
            synchronous
              cb_name.callback(arg, ...);
              ...
            asynchronous
              cb_name.callback( arg, ... );
              ...
          transition any->name :
            ...	
          transition name->any :
            ...
          transition inactive->name :
            ...
          transition name->inactive :
            ...
        end transitions;
      end tag regions;

    region_name : when predicate =>
      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;

Figure 4: Skeleton of a CDL Contract
Next is a list of system condition object declarations local to the contract. Each of these is identified by the keyword syscond. The keyword static preceding syscond is optional; the default is non-static. Non-static system condition objects are local to each instance of a contract class, i.e., a new one is created each time an instance of the contract is instantiated. Static system conditions are shared by all instances of a single contract class; one is created when the first instance of the class is instantiated. The other parts of the system condition object declaration are the IDL class of the object (idl_type), the implementation class of the object (impl_type), the local name of the object (name), and a list of actual parameters passed to the object constructor (arg ...). The next section of the contract definition contains a nested set of regions. There can be any number of levels of nested regions. Each set of regions can be labeled with an optional tag, e.g., negotiated or reality and is identified by the keywords regions are. Each region within the set must be identified by a name followed by a colon (:), the keyword when, a predicate, and the keyword =>. The body of a region must have another set of regions or it must be empty.

Each set of regions will have at most one active region at a time. However, the region predicates in a set can overlap and it is possible for the predicates of more than one region to be true at any given time. The precedences statement is a way for the programmer to specify which regions should be active if more than one's predicates are true. The precedences statement is optional; the default precedence is the order in which the regions are listed.

For each set of regions, a set of transitions specifies behavior that is invoked when the active region changes. A transition need not be specified for every possible region change and the set of transitions can be empty. A transition is specified using the keyword transition followed by two region names separated by the keyword ->, indicating a transition from the first region to the second region. One of the region names, but not both, can be replaced with one of the keywords any or inactive. The transition declarations are interpreted as follows:

transition region1 -> region2 is triggered when the contract, with active region region1, is evaluated and region2 becomes the new active region.
transition any->region1 is triggered when the contract, with an active region that is not region1, is evaluated and region1 becomes the new active region. It doesn't matter what region was active previously as long as it was not region1.
transition region1->any is triggered when the contract, with active region region1, is evaluated and another region, not region1, becomes active.
transition inactive->region1 is triggered when the contract has no active region and it is evaluated with region1 becoming active.
transition region1->inactive is triggered when the contract, with active region region1, is evaluated and no region becomes active, i.e., none of the region conditions is true.

Each transition must have at least one region name in its declaration, i.e., any->any, inactive->any, any->inactive, and inactive->inactive are not allowed.

The body of a transition contains a list of methods to be invoked when the transition is triggered. Each of these must be a method on a callback object passed into the contract or a system condition object. The methods can be separated into synchronous and asynchronous sets. These sets and keywords are optional and synchronous is the default. The contract will wait for synchronous callbacks to finish before it can be evaluated again. Asynchronous callbacks are spawned; the contract does not care whether they finish or not.

3.4 Separate regions

Contracts with many levels of regions can quickly become complicated; the grouping of regions could be difficult to identify even with consistent indentation. In addition, the transitions for a level could be distant from the region definitions due to nested regions. Therefore, CDL allows regions at any level to be defined separately. The phrase regions are separate is inserted at the place where the regions would normally be. Then after the contract definition or in a separate file, the set of regions is defined using the keywords separate regions for followed by the scoped name of the region or contract enclosing it (an optional tag can also be provided, i.e., tag regions are separate;).

For example, assume that a contract has a set of topmost regions containing a region A. Inside A is a set of regions, including a region B. Now assume that B contains the statement:

regions are separate;

Somewhere after this contract definition, perhaps in a separate file, there must be the following declaration:

separate regions for A.B are
...
end regions;

4: Controlling and measuring managed communication with QuO

We have developed a prototype managed communication application that uses QuO to establish, control, and measure resource reservations between a client and an object. The contract for this application is illustrated in Figure 5. The client can run in two modes, one in which it desires real-time performance in the form of managed communication and resource reservations; the other in which it does not require managed communication, does not want to monopolize resources possibly needed by other critical applications, and does not want to pay for the (presumably more expensive) managed resources.

We could interface to any of a number of resource reservation mechanisms [2, 13, 15]. In this example, we use the Internet ReSerVation Protocol (RSVP) [14], which allows a process to reserve resources along a path from the client to the object. QuO adds the power of allowing a client and object to adapt according to their changing modes of operations, alternate implementations, and success or failure of the resource reservation. In other words, our QuO application utilizing the contract in Figure 5 includes the following:

a client with several modes of operation, some of which are time critical
a remote object with alternate implementations for a single IDL interface, each providing different characteristics such as the size of data it consumes, the speed at which it produces a response, the amount of CPU it uses, and the amount of memory or secondary storage it uses
a local delegate for the remote object that provides adaptive behavior, such as dispatching a method call to different implementations or throwing exceptions without making the remote call
the RSVP mechanism and system condition objects providing interfaces to RSVP.

contract ManagedCommunication(
 syscond nowatch RsvpSC RsvpSCImpl session, // Conn. Mgr to setup the RSVP Session object 
 syscond ValueSC ValueSCImpl RSVPAvailable, // True when RSVP manager is available
 callback ClientCB ClientCallback,
 syscond ValueSC ValueSCImpl ClientDesiresManagedCommunication ) is

 ClientMode regions are
  region CriticalMode : when ClientDesiresManagedCommunication =>
    ReservationMode regions are
     region ReservationAvailable : when RSVPAvailable =>
       SessionMode regions are
        // Session syscond returns 1 if up, 0 if down
        region ReservationUp : when session == 1 =>
        region ReservationDown : when session == 0 =>
        transitions are
          transition inactive -> ReservationDown : session.start();
          transition ReservationUp -> ReservationDown: 
            ClientCallback.lost_rsvp_session();
            session.start();
        end transitions;      
       end SessionMode regions;
     region NoReservation : when not RSVPAvailable =>
     transitions are
       transition inactive -> NoReservation :      ClientCallback.rsvp_not_available();
       transition ReservationAvailable -> NoRSVP : ClientCallback.rsvp_not_available();
     end transitions;
    end ReservationMode regions;
  region NormalMode : when not ClientDesiresManagedCommunication =>
  transitions are
    transition CriticalMode -> NormalMode : session.stop();
  end transitions;
 end ClientMode regions;
end ManagedCommunication;

Figure 5: A Sample CDL Contract - Managed Communication

The example contract in Figure 5 illustrates a different nesting of regions than that provided by the negotiated and reality region grouping in the contract in Figure 3. When the client is running in critical mode, as indicated by the CriticalMode region, there are two subregions, indicating whether resource reservation capabilities are available or not. When resource reservation is available, further subregions indicate whether a session has been started or not (ReservationUp and ReservationDown). This grouping clearly overlaps the negotiated and reality grouping, as both the ReservationMode and SessionMode regions could be seen as reality regions. As we develop more QuO applications we intend to examine more programming styles and grouping metaphors to develop a set of programming guidelines for CDL.

When the client switches to critical mode, this is observed by the ClientDesiresManagedCommunication system condition object and triggers a transition into the CriticalMode region, with its subregions inactive. The keyword inactive indicates that no region in the current nesting is active. This could occur in any of the following cases:

The current nesting is in an initial state, i.e., either the current nesting is the topmost one and the contract has just been created or the parent region has been entered but its subregions have not yet been evaluated
The current nesting contains no regions
None of the predicates on regions in the current nesting are true.

Immediately upon transitioning into the CriticalMode region, the ReservationMode regions will be evaluated to determine which is active. One of them will be, since the RSVPAvailable system condition object must be either true or false. If the RSVPAvailable system condition object is true, the region ReservationAvailable is active with a subregion of inactive. The contract then evaluates the subregion predicates of ReservationAvailable, to determine whether a session has been started (ReservationUp) or not (ReservationDown). If a session has not already been started the transition from inactive to ReservationDown will attempt to start a new session. Once a session has been started, the SessionMode regions will transition to ReservationUp, with no corresponding transition behavior. If the session is lost for any reason, the session system condition object will notice and cause a transition from ReservationUp to ReservationDown, triggering transition behavior that notifies the client through its callback and attempts to restart the RSVP session.

If resource reservation is not available, e.g., because RSVP doesn't exist on the system or it has failed, when the contract is in the CriticalMode region, it will trigger a transition to the NoReservation region. This transition might come from the inactive region (if CriticalMode were just entered) or from the ReservationAvailable region (if RSVP failed while it was being used). In either case, the client desires managed communication, but the mechanisms to provide it are not available. The transition notifies the client through its callback, to enable the client to adapt. In the worst case, the client will have to notify the user that managed communication is not possible and proceed without it. In other cases, the client might be able to establish different connections, utilizing other managed communication mechanisms, other contracts, or other remote objects, to get the performance it desires.

The use of QuO and CDL in this example provides the following feedback, adaptation, and portability that would otherwise have to be directly handcoded into the application code:

The application will run on systems with or without resource reservation present
The application will notify the client of RSVP failure
The application will notify the client of session failure and try to recover
The application can readily relinquish resources when they are not needed.

5. Background and related work

QuO contracts are an example of open implementation [4, 7], which provides programmers control over previously hidden or internal aspects of an application, such as alternate implementations of an algorithm, insight or control over choice of data structures, or control of scheduling. QuO contracts provide programmers control of implementation details affecting QoS.

QuO also represents an example of Aspect-Oriented Programming (AOP) [5], in which a program is divided into aspects of concern, each of which are programmed separately in a language suitable for expressing the particular aspect. The application is constructed by weaving (using code generators) the aspects together into a single, executable application. QuO allows an application developer to separate the aspects of functional behavior, QoS contracts, system state monitoring and control, and alternate implementation and adaptation which would traditionally be interleaved throughout a critical application. QuO's code generators weave these together into a single application.

There are several other groups that have developed or are developing languages for describing aspects of QoS. The QUASAR project is working on techniques for specifying application-level QoS using the Z specification language and translating it into resource reservation requests [10, 12]. [6] describes the use of other formal specification languages, specifically Specification and Description Language (SDL), Message Sequence Charts (MSCs), and temporal logic, to specify QoS.

Frølund and Koistinen describe a specification language, QoS Modeling Language (QML), for specifying QoS [3]. QML is an extension of the Unified Modeling Language (UML) [1]. QML includes concepts of QoS contract types and contracts, similar to QuO's QDL, although QML's contract type and contract concerns a particular dimension of QoS, such as performance or availability. In contrast, a contract in QDL represents more of an application client's view of QoS, combining the QoS desires of the client, the service that an object expects to provide, the resources throughout the system that must be monitored and controlled, and adaptations to adjust to changes in QoS. A contract in QDL does not have to be limited to only one QoS dimension, e.g., a contract might describe aspects of both availability and security, and it does not have to fully describe a QoS dimension, e.g., performance might be captured fully in several contracts describing managed communication, algorithm processing time, and response time.

BeeHive provides a set of service-specific application programming interfaces (APIs), through which objects can request QoS from an underlying resource manager [11]. They are currently developing APIs for real-time, fault-tolerance, and security requirements. Each API allows an object to request a requirement in application terms, e.g., Mean Time to Failure for fault-tolerance. The resource manager translates each request into low-level resource requests.

[8] describes a technique for specifying QoS for congestion in networks. The technique involves selecting a set of quantifiable parameters that comprise the QoS. Then the upper and lower bounds for a correct operating interval are selected, followed by the upper and lower values of an interval in which service is degraded, but the degradation is acceptable. These values are combined into a matrix which defines the service contract between a client and a service provider. The contracts they describe map naturally into CDL; we simply use a programming language syntax in contrast to their matrix notation. The concept of operating regions is implicit in their notion of intervals, but they only support three intervals, normal operating range, degraded but acceptable, and unacceptable (implicit), whereas QuO does not limit the number or types of regions. In addition, there doesn't seem to be any provision for adaptation to changing levels of service.

6. Conclusions and future research

Distributed object applications, especially those with critical requirements, need to be able to specify and control the QoS provided them, monitor it, and adapt as QoS changes. QuO provides a framework for describing, controlling, monitoring, and adapting to changes in QoS. Central to the QuO framework is QDL, a suite of quality description languages for describing QoS contracts between clients and objects, adaptive behavior on the client and object side, and the system resources that must be observed to monitor QoS. In this paper, we described the QuO framework and the Contract Description Language, CDL. We are currently working on other components of QDL, including the Resource Description Language (RDL), which describes available system resources and their status, and the Structure Description Language (SDL), which describes the adaptive behavior of remote objects and their local delegates. A set of code generators generates Java and C++ code from these description languages which is compiled and linked with the QuO kernel to create a QuO application.

Acknowledgments

The authors gratefully acknowledge the contributions of David Karr, Rodrigo Vanegas, and Korrin Fu to the work described in this paper.

References

[1] Grady Booch, Ivar Jacobson, and Jim Rumbaugh. Unified Modeling Language. Rational Software Corporation, version 1.0, January 1997.

[2] Domenico Ferrari, Anindo Banerjea, and Hui Zhang, "Network Support for Multimedia: A Discussion of the Tenet Approach," Computer Networks and ISDN Systems, July 1994, pp. 1267-1280.

[3] Svend Frølund and Jari Koistinen, "Quality of Service Specification in Distributed Object Systems Design," submitted to COOTS 98.

[4] Gregor Kiczales, "Beyond the Black Box: Open Implementation," IEEE Software, January 1996.

[5] Gregor Kiczales, John Irwin, John Lamping, Jean-Marc Loingtier, Cristina Videria Lopes, Chris Maeda, and Anurag Mendhekar, "Aspect-Oriented Programming," ACM Computing Surveys, 28(4es), December 1996, http://www.acm.org/pubs/citations/journals/surveys/1996-28-4es/a154-kiczales/.

[6] Stefan Leue, "QoS Specification based on SDL/MSC and Temporal Logic," in: G. v. Bochmann, J. de Meer, and A. Vogel (eds.), Proceedings of the Montreal Workshop on Multimedia Applications and Quality of Service Verification, Montreal, May 31 - June 2, 1994.

[7] Chris Maeda, Arthur Lee, Gail Murphy, and Gregor Kiczales, "Open Implementation Analysis and Design".

[8] Edmundo Monteiro, Fernando Boavida, GonValo Quadros, and Vasco Freitas, "Specification, Quantification and Provision of Quality of Service and Congestion Control for New Communication Services," Proceedings of the 16th AFCEA Europe Symposium, AFCEA(Association for Communications, Electronics, Intelligence & Information Systems Professionals)/IEEE COMSOC/IEE, October 18-20, Brussels, Belgium, pp. 58-68, 1995.

[9] Object Management Group, CORBA 2.0, July 96 revision, OMG Document 96-08-04, July 1996.

[10] www.cse.ogi.edu/DISC/projects/quasar/.

[11] John A. Stankovic, Sang H. Son, Joerg Liebeherr, "BeeHive: Global Multimedia Database Support for Dependable, Real-Time Applications," Computer Science Report No. CS-97-08, University of Virginia, April 21, 1997.

[12] Richard Staelhli, Jonathan Walpole, and David Maier, "Quality of Service Specification for Multimedia Presentations," Multimedia Systems, November, 1995, volume 3, number 5/6.

[13] C. Topolcic. Experimental Internet Stream Protocol, Version 2 (ST-II). Request for Comments (Experimental) RFC 1190, Internet Engineering Task Force, October 1990.

[14] Lixia Zhang, Steve Deering, Deborah Estrin, Scott Shenker, and Daniel Zappala, "RSVP: A New Resource ReSerVation Protocol," IEEE Network, September 1993.

[15] Wei Zhao and Satish K. Tripathi, "A Resource Reservation Scheme for Synchronized Distributed Multimedia Sessions," 1st Annual Advanced Telecommunications/Information Distribution Research Program Conference, January 21-22, 1997.

[16] John A. Zinky, David E. Bakken, and Richard E. Schantz, "Architectural Support for Quality of Service for CORBA Objects," Theory and Practice of Object Systems, 3(1), 1997

Specifying and Measuring Quality of Servicein Distributed Object Systems