Middleware systems support applications in a distributed environment, serve as the glue between two applications, connect and pass data between two sides of an application. Providing QoS support is one of the features of the new generation middleware systems.  QoS support is required by new QoS aware applications as well as for QoS sensitive legacy non-QoS-aware applications like e.g. current VoIP or video-conferencing applications, which properly working is affected by a non-guaranteed and non-predictable best effort network behaviour.

In a QoS-enabled scenario, like the AQUILA one QoS is offered at network level but how can a non QoS aware legacy application profit from this QoS offer?

One solution consists in offering the QoS in parallel to application run time via a so-called web QoS portal. In a first step the portal gets the information from the end-user which application he uses. In a second step the so-called EAT provides the QoS portal with the QoS information appropriate to the corresponding application information. Therefore it uses the so-called Application Profiles. 

The Application Profile concept is on the one hand

• a syntax for describing applications
  • at network level
    • how to describe the AQUILA QoS request - implementation dependent
    • how to describe the QoS expectations / requirements
    • how to describe the produced traffic
  • at application - control plane level
    • protocol used, port used...
  • at application - data plane level
    • implementation issues of service components
  • at end-user level
    • how to build metaphors - portal

on the other hand a repository of files with the concrete application descriptions.

This document presents the specifications of the QoS offer resp. request at different levels used by AQUILA. The aim of the specification is to provide a generic and network independent QoS description language. This aim is not yet completely achieved and, apart from a well-defined component (AQUILATrafficSpecification), all the attributes are generic and network independent.

The following picture, an UML analysis class diagram, depicts the relation between the different elements influencing the QoS attributes.

An application can be described hierarchically. It consists of Service Components like video, voice, music, etc. They provide many quality levels, the so-called Options (e.g. big, medium or small picture size), and have a QoS requirement in terms of the QoS parameters delay, jitter, loss, error and throughput. The options are specified by the description of the produced traffic, the TrafficSpecification, the metaphor for the end-user the so-called SessionCharacteristic, and the proprietary AQUILATrafficSpecification.

• This solution is for non-QoS adaptive applications only
• A QoS enabled network is available

Application Profile

The description of applications relies on a formal QoS description syntax, the so-called Application Profile, which can be seen as a framework for application developers. It is based on the assumption that an end-user cannot express QoS in terms of high-complex technical parameters like RSVP, UMTS, etc. The end-user can express QoS via metaphors corresponding to the human senses: sight, hearing, and on the perception of time-related behaviour. User-friendly descriptions for QoS correspond to a universal apprehension of applications and ideally make reference to well-known similar “services” from everyday life like TV, video recorder, Hi-Fi, or phone. Towards the network the Application Profile semantic offers the possibility to support QoS sensitive applications. This enables the application to present the QoS offer from the network to the end-user and to request QoS. An Application Profile is twofold. It defines for an application at end-user as well as application level: 

1. a syntax for the QoS request,  and 
2. a syntax for the end-user metaphor.

An Application Profile allows on one hand side the precise description of the application's behaviour (how does the traffic, produced by the application, look like; how does the application behave, etc.) with its required QoS parameters (what does the application need from the network in order to work properly), and on the other hand the metaphorical description of the service components with the different quality levels.Beside these two main tasks an Application Profile enables the description of low level information at control plane and data plane level.

An Application Profile is specified by a Document Type Description (DTD): ApplicationProfile.dtd. This DTD is not monolithic and refers to a so-called Service Component Profile.

With this ApplicationProfile.dtd syntax it is possible to:

• Describe the protocol used by an application by applying the protocol syntax
• Describing the different service components composing an application by applying the ServiceComponent syntax
• Describe the transport protocol of each service component by applying the TransportProtocol syntax
• Describe each service component by applying the ServiceComponentProfile syntax

Service Component Profile

The Service Component Profile is the central element of the Application Profile and enables the description of concrete service components like voice, video or data. 

The information that can be described applying the ServiceComponentProfile.dtd syntax  corresponds to:

1. the QoS requirements of the service component, 
2. the different possible quality level options with the description of the produced traffic for each option (TrafficSpecification) and the metaphors for the end-user  (SessionCharacteristic).

The information can be described in an objective (parameter and value) and subjective (words) manner. A weighting system (from 1 to 10) enables a more precise specification of  the QoS requirements and behaviour.

A ServiceComponentProfile is specified by a Document Type Description (DTD): ServiceComponentProfile.dtd. Please note that this solution (apart from the AQUILA component AQUILASpecification) is generic.

With the ServiceComponentProfile syntax it is possible to:

• Describe the different possible QoS options of a service component by applying the Option syntax
• Describe the QoS expectations of the service components by applying the QoSRequirement syntax
• Describe the traffic produced by a service component by applying the TrafficSpecification syntax
• Describe application characteristics at end-user level in a user-friendly manner by applying the SessionCharacteristic syntax

Library

This library is a living document that benefits from contributions. If you developed applications or profiles based on the previously presented ApplicatioProfile.dtd, we kindly encourage you to send them to Anne Thomas to have them published on this page.

For each particluar (non adaptive) application (legacy or QoS-aware) it is possible to create its Application Profile by following the Application Profile DTD. This task has to be done manually. The person creating the profile has to collect all the information necessary to fullfill the DTD schema. 

Example for a concrete Application Profile: 

The activity on Application Profiles (description of application QoS requirements/expectations toward the network from an end-user point of view as well as at application level, and description of the corresponding network QoS offer) lead to a study of QoS description or specification languages presented in the following:

• The ODP-based QuO (Quality of Service for CORBA Objects) framework provides quality of service (QoS) at the CORBA layer in network-centric distributed applications and extends the CORBA functional Interface Description Language (IDL) with the QoS Description Language (QDL). QDL is a language for describing the QoS aspects such as QoS contracts (specified by the Contract Description Language, CDL), the adaptive behaviour of objects and delegates (specified by the Structure Description Language, SDL) and the configuration of QuO applications (specified by the Configuration Setup Language, CSL).
  
  [QDL] QuO homepage http://quo.bbn.com/
   
  
• The Quality Assurance Language (QuAL) [QuAL] in QoSME [QoSME] enables the specification of how to allocate, monitor, analyse, and adapt to delivered QoS. Applications can express in QuAL their QoS needs and how to handle potential violations. QuAL consists of a programming language for the development of distributed multimedia applications. QuAL abstractions allow the specification of QoS constraints expected from the underlying computing and communication environment. QuAL specifications are compiled into run time components that monitor the actual QoS delivered.
  
  [QoSME] Patrícia Gomes Soares Florissi: QoSME: QoS Management Environment, PhD thesis, Columbia University, 1996
  http://www.cs.columbia.edu/dcc/publications/thesis/pgsf/ 
  
  [QuAL] QuAL homepage http://www.cs.columbia.edu/~pgsf/qual.html 
  
  
• MAQS (Management for Adaptive QoS-enabled Services) includes QIDL, an extension to OMG IDL that supports specification of QoS. QIDL extends IDL by providing the possibility to specify QoS interfaces and to assign these to functional interfaces.
  
  [QIDL] C. Becker and K. Geihs: Generic QoS-Support for CORBA, in Proceedings of 5th IEEE Symposium on Computers and Communications (ISCC'2000) Antibes/France (2000)
  
  
• QML (QoS Modeling Language) [QML] is a general-purpose language for defining QoS properties. QML has three main abstraction mechanisms for QoS specification: contract type, contract and profile. QoS specifications are available both at design time (in QML) and run-time. The QoS fabric (termed QRR - QoS Runtime Representation) enables dynamic specification and manipulation of QoS specifications. Also, it is possible to check conformance between specifications using QRR.
  
  [QML] Svend Frølund, Jari Koistinen: QML: A Language for Quality of Service Specification, Software Technology Laboratory, Hewlett-Packard Company, Report: HPL-98-10, pp. 63
  http://www.hpl.hp.com/techreports/98/HPL-98-159.pdf 
  
  
• Component Quality Modelling Language (CQML) [CQML] is a lexical language for specifying QoS. Using CQML, the QoS a component provides can be specified independently of how the support is to be implemented. Furthermore, the QoS a component provides can be specified without affecting the specification of its functional properties. This means that, if needed, specifications of existing systems with already defined functional properties can be extended to be QoS-aware, without changing any existing part of the specification.
  
  [CQML] Aagedal, J. Ø.: Quality of Service Support in Development of Distributed Systems, Dr. scient. thesis, 250 pages, Department of Informatics, Faculty of Mathematics and Natural Sciences, University of Oslo, March 2001
  http://www.ifi.uio.no/~janoa/papers/thesis.pdf 
  
  
• HQML is an XML-based Hierarchical QoS Markup Language, to enhance distributed multimedia applications on the World Wide Web (WWW) with Quality of Service (QoS) capability. HQML allows distributed multimedia applications to specify all kinds of application-specific QoS policies and requirements. During runtime, the HQML Executor translates the HQML file into desired data structures and cooperates with the QoS proxies, which assist applications in end-to-end QoS negotiation, setup and enforcement according to the user preference.
  
  [HQML] Xiaohui Gu, Klara Nahrstedt, Wanghong Yuan, Duangdao Wichadakul and Dongyan Xu: An XML-based Quality of Service Enabling Language for the Web, Department of Computer Science University of Illinois at Urbana-Champaign, Urbana, UIUCDCS-R-2001-2212, April 2001
  http://www.cs.uiuc.edu/Dienst/Repository/2.0/Body/ncstrl.uiuc_cs/UIUCDCS-R-2001-2212/pdf