Common object-oriented analysis and design languages, such as UML [], Objectory [], Booch notation [], and OMT [], generally lack concepts and constructs for QoS specification. In some cases, they have limited support to deal with temporal aspects or call semantics [].
Interface definition languages, such as OMG IDL [], specify functional properties and lack any notion of QoS. TINA ODL [] allows the programmer to associate QoS requirements with streams and operations. A major difference between TINA ODL and our approach is that they syntactically include QoS requirements within interface definitions. Thus, in TINA ODL, one cannot associate different QoS properties with different implementations of the same functional interface. Moreover, TINA ODL does not support refinement of QoS specifications, which is an essential concept in an object-oriented setting.
There are a number of languages that support QoS specification within a single QoS category. The SDL language [] has been extended to include specification of temporal aspects. The RTSynchronizer programming construct allows modular specification of real-time properties []. These languages are all tied to one particular QoS category. In contrast, QML is general purpose; QoS categories are user-defined types in QML, and can be used to specify QoS properties within arbitrary categories.
Zinky et al. [,] present a general framework, called QuO, to implement QoS-enabled distributed object systems. The notion of a connection between a client and a server is a fundamental concept in their framework. A connection is essentially a QoS-aware communication channel; the expected and measured QoS behaviors of a connection are characterized through a number of QoS regions . A region is a predicate over measurable connection quantities, such as latency and throughput. When a connection is established, the client and server agree upon a specific region; this region captures the expected QoS behavior of the connection. After connection establishment, the actual QoS level is continuously monitored, and if the measured QoS level is no longer within the expected region, the client is notified through an upcall. The client and server can then adapt to the current environment and re-negotiate a new expected region.
QuO does not provide anything corresponding to refinement, conformance, or fine-grained characterizations provided by QML.
Within the Object Management Group (OMG) there is an ongoing effort to specify what is required to extend CORBA [] to support QoS-enabled applications. The current status of the OMG QoS effort is described in [], which presents a set of questions on QoS specification and interfaces. We believe that our approach provides an effective answer to some of these questions.