QoS Aspect Languages and Their Runtime Integration

Published in the Lecture Notes in Computer Science, Vol. 1511, Springer-Verlag.

Reprinted from the Proceedings of LCR98,
the Fourth Workshop on Languages, Compilers, and Run-time Systems for Scalable Computers
 May28-30, 1998
Pittsburgh, Pennsylvania, USA

Joseph P. Loyall
David E. Bakken
Richard E. Schantz
John A. Zinky
David A. Karr
Rodrigo Vanegas
Kenneth R. Anderson

BBN Technologies
GTE Internetworking
10 Moulton St., Cambridge, Massachusetts 02138 U.S.A

Email: jloyall@bbn.com, dbakken@bbn.com schantz@bbn.com, jzinky@bbn.com, dkarr@bbn.com, vanegas@bbn.com, kanderson@bbn.com,

Distributed object middleware, such as CORBA, hides system- and network-specific characteristics of objects behind functional interface specifications. This simplifies development and maintenance of distributed objects, contributing to their growing acceptance. Critical applications have Quality of Service (QoS) requirements, however, such as real-time performance, dependability, or security, that are hidden by middleware. Because of this, application developers often bypass distributed object systems, thus gaining little or no advantage from the middleware. We have developed Quality Objects (QuO), a framework for developing distributed applications with QoS requirements. QuO provides a set of aspect languages, called Quality Description Languages (QDL), for specifying possible QoS states, the system resources and mechanisms for measuring and controlling QoS, and behavior for adapting to changing levels of available QoS at runtime. This paper describes QuO's aspect languages, their usage, and how they interact with the QuO runtime system to form the QuO framework.

1. INTRODUCTION

Distributed object middleware, such as CORBA [5], hides system- and network-specific characteristics of objects behind Interface Description Language (IDL) specifications, which describe how clients and objects interact functionally, i.e., the methods that can be invoked on an object and the types of data that can be exchanged. This simplifies development and maintenance by promoting abstract design, code reuse, and interoperability, and has contributed to the growth and acceptance of distributed object computing. However, many distributed applications have quality of service (QoS) requirements in addition to their 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, and dependability. Current commercial distributed object middleware products fall short of supporting QoS requirements because they hide the details necessary to specify, measure, and control QoS and to adapt to changing levels of QoS. Because of this, developers of critical applications often find themselves programming around the distributed object abstraction and gaining little or no advantage from middleware. The problem gets worse as the number and diversity of distributed applications increase and as applications are distributed over wide-area networks (WANs), which are inherently more dynamic, unpredictable, and unreliable than LANs.

We have developed Quality Objects (QuO) [4,7], a framework for developing distributed applications with QoS requirements. QuO provides the ability to specify, monitor, and control aspects of the QoS in an application, and to adapt to changing levels of QoS at runtime. A major component of the QuO framework is a set of Quality Description Languages (QDL) for specifying possible QoS states, the system resources and mechanisms for measuring and providing QoS, and behavior for adapting to changes in QoS. This QoS specification, monitoring, and adaptation are aspects of the program that would normally have to be distributed throughout the program, cross-cutting the components and objects comprising the functional decomposition of the program. Because of this, the QuO framework and QDL represent an instance of {\em aspect-oriented programming} (AOP) [1]. AOP allows programmers to divide an application into both functional components and aspects, more global concerns that cross-cut the functional decomposition. QDL consists of aspect languages for describing aspects of a program related to QoS: providing it, monitoring it, and adapting to changing levels of it.

In this paper, we describe QuO's aspect languages; how they are used to specify, measure, control, and adapt to QoS; and how they interact with the QuO runtime system to form the QuO framework.

2. OVERVIEW OF ASPECT-ORIENTED PROGRAMMING

In Aspect-Oriented Programming (AOP) [1], a program is divided into aspects of concern, each of which is programmed separately in a language suitable for expressing the particular aspect. The application is constructed by weaving the aspects together into a single, executable application using code generators. Aspectual decomposition is different from, but complementary to, functional decomposition. In functional decomposition, problems are divided into procedures, objects, modules, etc., each of which is programmed to hide its implementation and expose its functional interface. Each functional module is usually compiled into a specific section of code in the application's executable code.

In contrast, aspectual decomposition divides a problem into aspects, i.e., global concerns that cut across functional module boundaries, such as distribution, synchronization, or security. The executable code that deals with each of these aspects does not exist in a specific section, but occurs throughout the application's executable code. Traditionally, programmers would pepper code throughout each module to satisfy each aspect, until the modules become tangled with concerns. AOP avoids the ``tangling of concerns'' phenomenon [1] by providing abstractions that correspond to the different aspects. AOP allows programmers to divide an application into both function components and aspects. Code generators, called weavers, distribute the aspect code into the proper places throughout the application.

QuO provides an example of aspect-oriented programming. QuO allows an application developer to specify the aspects of QoS contracts, system state monitoring and control, alternate implementations, and adaptation strategies which would traditionally be interleaved throughout a critical application. QuO's code generators weave these together into a single application.

3. OVERVIEW OF QUO

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 [7].

3.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 proxy on the client's host, which marshals the clients data, and passes it to an ORB on the client's host. The ORB delivers the call to an ORB on the object's host, where an ORB proxy unmarshals the data and delivers it to the remote object. The client sees it strictly as a functional method call.

Figure 1: A remote method invocation in a QuO application


As indicated in Figure 1, a QuO application adds additional steps to this process. In addition to the client program, ORB, and remote object (all components of a CORBA application), a QuO application adds the following components:

QuO applications also include property managers, mechanisms, specialized ORBs, and ORB wrappers that provide non-functional (i.e., QoS-related) capabilities. QuO replaces the bind function provided by many CORBA ORBs with connect. When a client calls connect to bind to a remote object, QuO instantiates the appropriate delegate and contract, and hooks up the client, delegate, contract, system condition objects, and ORB proxy.

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 (1). This is transparent to the client, since the remote object and the delegate have the same interface. The delegate can trigger contract evaluation (2), which grabs the current value of all system conditions (3) 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 (4).

Figure 2: Example remote method call in a QuO application


The delegate chooses how to process the method call based upon the current regions (5). For example, the delegate might choose between alternate methods, might buffer the call, or might simply pass the call through to the remote object. Upon a method return (6), the delegate can evaluate the contract to obtain the current QoS regions and select a behavior based upon the current regions. The delegate finally returns control to the client (8), passing back any return values, out, and inout parameters.

Contract evaluation can also be triggered by changes in some system condition objects, i.e., those that are observed by the contract (7). 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.

3.2 The QuO Toolkit 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:

To support the added role of QoS developer, we are developing a QuO toolkit, which consists of the following components:

The QuO kernel and runtime system are described in detail in [15].

4. THE QUO ASPECT LANGUAGES AND CODE GENERATORS

QuO currently provides two aspect languages, collectively called Quality Description Languages (QDL): a Contract Description Language (CDL) and a Structure Description Language (SDL). CDL is used to describe the QoS contract between a client and an object. This includes 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. CDL is described in detail in [4].

SDL describes the structural aspects of the QuO application. This includes the implementation alternatives of remote object, including alternate implementations (i.e., object instances) of IDL interfaces and alternate methods on specific objects, their tradeoffs, and characteristics. It also includes the local adaptive behavior of object delegates and binding and connection strategies.

We are also currently designing a third aspect language, the Resource Description Language (RDL). RDL will describe available system resources and their status.

4.1 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. In this section we briefly describe CDL, by example. A more complete discussion of CDL, including its syntax and semantics, is provided in [4].

Elements of a CDL contract.

A QuO contract consists of the following:

Figure 3: The QuO code generators


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. 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. Any system condition objects local to the contract instance are created and connected to the contract instance. 

contract Replication(
  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 Replication;

Figure 4: A Sample CDL Contract - Replication

A simple CDL example contract.

Figure 4 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. 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.

4.2 The Structure Description Language (SDL)

SDL allows a QuO programmer to specify adaptation alternatives and strategies based upon the QoS measured in the system. Currently, SDL allows a program to specify behaviors to invoke for method calls and/or returns based upon the current regions of contracts when the calls or returns occur. Later versions of SDL will also allow QuO programmers to specify QuO connections, i.e., the contracts, delegates, system condition objects, remote objects, and clients that need to be created or located and how they are hooked together to create a QuO application.

Elements of an SDL description.

An SDL description is essentially a large table, in textual form, associating method calls or returns with contract regions, and specifying behavior for each relevant association. It consists of the following:

The code generator creates a delegate for each interface in the SDL description. Each delegate acts as a local wrapper around a remote object and presents an interface to the client with the same methods and argument types as are compiled from the remote object's IDL interface. However, it also generates two dispatch statements, i.e., switch statements in Java and C++, within each method, one for the call and one for the return. The dispatch statement checks the current regions of the relevant contracts and dispatches the proper behavior. The code inside each case of the dispatch statement is generated from the behavior specifications in the SDL description. 

interface Targeting {
  long calculate_distance_to_target(long x, long y);
};

Figure 5: Simple IDL for a targeting interface

delegate behavior for Targeting and Replication is
  obj : bind Targeting with name SingleTargetingObject;
  group : bind Targeting with characteristics { Replicated = True };

  call calculate_distance_to_target :
    region Available.Normal :
      pass to group;
    region Low\_Cost.Normal :
      pass to obj;
    region Available.Low :
      throw AvailabilityDegraded;
    default :
      pass to obj;
  return calculate_distance_to_target :
    pass through;
  default :
    pass to obj;
end delegate behavior;

Figure 6: SDL that chooses between replicated and non-replicated server objects

A simple SDL example.

As an example, consider the SDL description in Figure 6. This is a simple SDL description with only one interface, Targeting, specified in Figure 5, and one contract, Replication, specified in Figure 4.

This SDL description creates two bindings for the delegate, one to a specific object (known by a CORBA name server as SingleTargetObject) and a second to a replicated object group, i.e., an object tagged with the characteristic that it is replicated. Since these bindings are specified at the beginning of the SDL description, i.e., before the behavior table, they are established upon delegate creation. That is, the delegate code generated by the code generator will establish these bindings upon creation and initialization of the delegate. As described below, the SDL language also permits dynamic binding to objects.

Following the binding section is the behavior table, arranged as a list of method calls and returns, with region names nested inside them, finally with behavior descriptions nested inside them. The SDL description in Figure 6 essentially chooses between sending a remote method call to a single object or to an object group based upon whether the client desires and is getting availability through object replication.

When the calculate_distance_to_target method is called, the delegate checks the Replication contract and chooses one of the following behaviors:

Overview of SDL features and semantics.

Structure descriptions written in SDL have the following form: 

delegate behavior for interfaces interface_list
    and contracts contract_list is
  local_variable_declarations
  adaptive_behavior_descriptions
  default_behavior_description
end delegate behavior;

The header specifies the interfaces for which delegates need to be generated and the contracts that determine their behaviors. The code generated from SDL code builds a delegate object for each interface in interface_list, containing a dispatch statement for the regions in each contract in contract_list. The next section, i.e., local_variable_declarations, contains a list of statements binding local variables to remote objects. The current version of SDL allows a delegate to bind to remote objects by interface type, by name, or by QoS characteristics. Bindings in the declaration section of an SDL description, as illustrated in Figure 6, are established when a delegate is created and initialized. In the behavior description parts of the SDL description, the variables can be used to refer to the local objects. The variables can be rebound in the behavior descriptions.

The adaptive_behavior_descriptions section describes the dispatch statements for the generated delegates. It takes one of the following forms: 

call method_name : region_behavior_list default_behavior
return method_name : region_behavior_list default_behavior

The first form specifies the behavior to perform when a client calls a remote method. The second specifies the behavior to perform upon the return from a remote method call. The method_name can be simply the name of a unique method in one of the interfaces or can be an interface name followed by a method on that interface.

The region_behavior_list is a list of contract regions, inside of each is nested a behavior specification. Each element of region_behavior_list is of the following form: 

region region_name : behavior_statement_list

The region_name is the name of a unique region in one of the contracts or the name of a contract followed by the name of a region in that contract.

The default_behavior statement above is simply the keyword default: followed by a behavior_statement_list.

A behavior_statement_list is a list of alternative behaviors. SDL currently supports the following specifications of behavior in a behavior_statement_list:

Choosing between methods and/or remote objects. The delegate uses SDL's pass primitive to pass the method call through to any method on any remote object to which the delegate is bound. This statement is one of the following forms: 

pass to var;
pass to var.method;
pass to method;
pass through;

If var is specified, the delegate passes the method call through to the remote object to which var is bound (var must be bound in the declaration section). If var.method is specified, the method call is still passed to the remote object bound to var, but to the alternate method method, which must currently take the same number and type of arguments as the original method.

The third and fourth forms of the pass statement are only meaningful if the delegate has a binding to only one remote object. The pass through statement passes the method call to the corresponding method on the remote object. The pass to method passes the call to the alternate method on the remote object. If the delegate has bindings to more than one remote object (i.e., either the delegate header specifies more than one interface type or there are binding statements in the local_variable_declarations section), the semantics of the third and fourth forms are undefined.

Throwing an exception. A statement of the form 

throw exception;

can be used to throw an exception without making a remote call. Breaking and/or establishing a binding to a remote object. The delegate can choose to rebind any of its bindings or establish a new binding in order to try and improve QoS, access a service previously not available, etc. The following statement specifies this: 

rebind [var] [exclusive] [to iface] [with name name
| with characteristics ch_list];

This rebind statement breaks and/or establishes bindings to objects at runtime by interface type, by name, or by QoS characteristics. Using this feature, a remote connection that is not satisfying its expected QoS can be broken and reestablished with different mechanisms, a different object, or a different implementation of an interface.

The optional keyword exclusive tells the QuO runtime to rebind to an object different from the current binding. Without the exclusive keyword, the QuO runtime is free to bind again to the same object, providing it has the specified interface (iface), name (name), or characteristics (ch_list).

The characteristics are currently specified by a list of keyword/value pairs, as illustrated in Figure 6. The list can use any relative operator, e.g., < or <=, to specify the values that the keyword can take.

Java or C++ functionality. The behavior description can specify Java and/or C++ code that is placed verbatim into the proper delegate, i.e., the Java delegate or the C++ delegate. Using this, the delegate can perform arbitrary local processing in place of, or in addition to, the remote call. This is specified by the following statements: 

Java_code { code }
C++_code { code }

The programmer uses SDL to specify behavior for relevant method calls, method returns, and QoS regions. In addition, the programmer can use SDL's default statement to specify behavior for all other QoS regions for a method, or for all other methods. For example, the SDL code in Figure 3 specifies default behavior (i.e., pass through) for all other methods in the Targeting interface other than calculate_distance_to_target.

5. RELATED WORK

QuO contracts are an example of open implementation [2,3], 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.

As discussed in Section 2, QuO also represents an example of Aspect-Oriented Programming [1], in which a program is divided into aspects of concern, each of which is 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 [9]. Leue describes the use of other formal specification languages, specifically Specification and Description Language (SDL), Message Sequence Charts (MSCs), and temporal logic, to specify QoS [10].

Frolund and Koistinen describe a specification language, QoS Modeling Language (QML), for specifying QoS [11]. QML is an extension of the Unified Modeling Language (UML) [12]. 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 [13]. 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.

Monteiro et al. describe a technique for specifying QoS for congestion in networks [14]. 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

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 aspect languages for describing aspects of QoS and adaptation. QDL supports the specification of 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 QDL aspect languages, concentrating on the Contract Description Language, CDL, and the Structure Description Language, SDL. Each of these enables a QuO programmer to specify aspects of a QuO application, i.e., QoS contracts in CDL and adaptive behavior based upon states of Qos in SDL. A set of code generators generates Java and C++ code from these description languages and weaves the generated code into the QuO runtime and application code.

References

[1] Gregor Kiczales, John Irwin, John Lamping, Jean-Marc Loingtier, Cristina Videria Lopes, Chris Maeda, Anurag Mendhekar: Aspect-Oriented Programming. ACM Computing Surveys 28(4es) (1996)

[2] Gregor Kiczales: Beyond the Black Box: Open Implementation. IEEE Software (1996)

[3] Chris Maeda, Arthur Lee, Gail Murphy, Gregor Kiczales: Open Implementation Analysis and Design

[4] Joseph P. Loyall, Richard E. Schantz, John A. Zinky, David E. Bakken: Specifying and Measuring Quality of Service in Distributed Object Systems. Proceedings of the First International Symposium on Object-oriented Real-time distributed Computing (ISORC '98) (1998) 43-52

[5] Object Management Group: CORBA 2.0, July 96 revision, OMG Document 96-08-04 (1996).

[6] Lixia Zhang, Steve Deering, Deborah Estrin, Scott Shenker, Daniel Zappala: RSVP: A New Resource ReSerVation Protocol. IEEE Network (1993)

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

[8] Sean Landis, Silvano Maffeis: Constructing Reliable Distributed Communications Systems with CORBA. Theory and Practice of Object Systems, 3(1) (1997)

[9] Richard Staelhli, Jonathan Walpole, David Maier: Quality of Service Specification for Multimedia Presentations. Multimedia Systems, 3(5/6) (November, 1995)

[10] Stefan Leue: QoS Specification based on SDL/MSC and Temporal Logic. 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

[11] Svend Frolund, Jari Koistinen: Quality of Service Specification in Distributed Object Systems Design. submitted to COOTS 98.

[12] Grady Booch, Ivar Jacobson, Jim Rumbaugh: Unified Modeling Language, Rational Software Corporation, version 1.0, (1997)

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

[14] Edmundo Monteiro, Fernando Boavida, Gonzalo Quadros, 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, Brussels, Belgium, (October 18-20, 1995) 58-68

[15] Rodrigo Vanegas, John A. Zinky, Joseph P. Loyall, David Karr, Richard E. Schantz, David E. Bakken: QuO's Runtime Support for Quality of Service in Distributed Objects. Middleware'98: IFIP International Conference on Distributed Systems Platforms and Open Distributed Processing, The Lake District, England (September 15-18, 1998)