G-QoSM: A Framework for Quality of Service Management
Rashid J. Al-Ali, Omer F. Rana and David W. Walker
School of Computer Science
Cardiff University, UK
{Rashid,O.F.Rana,David.W.Walker}@cs.cardiff.ac.uk
Abstract
Some applications utilizing Grid computing infrastructure require the simultaneous allocation of resources, such
as compute servers, networks, memory, disk storage and
other specialized resources. Collaborative working and visualization are examples of such applications. In these applications, Quality of Service (QoS) is related to Grid services, and not just to the network connecting these services.
With the emerging interest in “Service-Oriented Grids”, resources may be advertised and traded as services based
on a Service Level Agreement (SLA). Such a SLA must include both general and technical specifications, including
pricing policy and properties of the resources required to
execute the service – to ensure QoS requirements are satisfied. A framework for QoS management is presented to
enable Service-Oriented Grid users to specify, locate and
execute Grid services with QoS constraints. The framework
provides three particular features: 1) support for resource
and service discovery based on QoS properties, 2) support
for providing QoS guarantees at middleware and network
level, and establishing SLAs to enforce these, and 3) providing QoS management on allocated resources based on a
pre-negotiated SLA.
1 Introduction
Some applications utilising Grid computing infrastructure require the simultaneous allocation of resources, such
as compute servers, networks and memory capacity, disk
storage and other specialised resources. Collaborative
working and distributed visualization provide two examples
of such applications. In such applications, the user generally executes a service remotely, and expects to receive a
result within a particular time period. There is therefore a
more stringent requirement on such services to conform to
particular Quality of Service (QoS) criteria – as not meeting such criteria is paramount to the application producing
incorrect results. Our thesis is that such QoS metrics should
be specified with reference to Grid services, and not just
to the network connecting these services (which has been
the focus of related research in multimedia applications, for
instance). With the emerging interest in Service-Oriented
Grids, resources may be advertised and traded as services
based on a Service Level Agreement (SLA). A user requesting a particular service must identify QoS requirements
(such as networking parameters (eg bandwidth), computational parameters (eg number of processors), the duration
over which the service is required, and the expected cost
the user is willing to pay). Similarly, a service provider
must annotate their service with QoS capabilities. Some
of these capabilities are directly managed by the service
provider (such as cost), whilst others are obtained through
third party resource and network managers. Currently we
make use of Globus Architecture for Reservation and Allocation (GARA) for ‘compute’ resource, which enables
programmers and end users to specify and manage endto-end QoS for Grid-based applications. A Diffserv Bandwidth Broker (in collaboration with the University of New
South Wales, Australia) is used as a network manager over a
Diffserv domain. The definition of these user requirements
are through the SLA, which must include both general and
technical specifications of a service, including pricing policy and properties of the resources required to execute the
service – to ensure QoS requirements are satisfied.
The “Grid QoS Management” (G-QoSM) framework
aims to provide three main functions: 1) support for resource and service discovery based on QoS properties; 2)
provision for QoS guarantees at application, middleware
and network levels, and the establishment of SLAs to enforce QoS parameters; and 3) support for QoS management of allocated resources, on three QoS levels: ‘guaranteed’, ‘controlled load’ and ‘best effort’. G-QoSM also
supports adaptation strategies to share resource capacity between these three user categories.
Functions (1) and (2) above have been investigated and
implemented [2][3], adaptation has been investigated as part
of QoS management [1], and the focus is currently on supporting other QoS management; based on pre-negotiated
SLAs, such as monitoring and re-negotiation. We describe
the G-QoSM framework and outline its current implementation status, which is achieved with the Web Services Toolkit
from IBM, the UDDIe registry service, the Tomcat/Apache
Web server, the Globus/GARA DSRT manager, and the
DiffServ bandwidth broker. We were limited to the use of
particular resource managers, as only a limited set of these
currently support resource reservation. We find this to be a
significant limitation within existing systems for supporting
QoS-based applications.
The rest of the paper is organized as follows: section 2
outlines some related work. Section 3 introduces the GQoSM framework. Sections 4, 5, and 6 present the (3) main
functions of the G-QoSM framework; service discovery,
QoS provision and QoS management (adaptation) respectively. Section 7 presents the current implementation status
and section 8 concludes the paper with possible future directions.
2 Related Work
Discovery of services with QoS has also been explored
in several contexts; in [15] the authors demonstrate how the
inclusion of service feedback could improve QoS of a session. The Wide-Area Discovery Framework was enhanced
to provide a better query responsiveness and QoS awareness. Feedback in this context means that during a service
session a software component monitors the QoS, and generates the numerical average QoS level observed. The QoS
is highly service-specific and does not have a generic specification as is the case with our model. Furthermore, their
work targets queries which have to traverse a number of discovery services in hierarchal fashion. Madja et al. [8] propose a data model for QoS management for the Web. The
data model is a set of QoS characteristics for multimedia
(MM) audio/video documents. This data may be stored in
a database, as text files, or as an extension of HTML tags.
The client specifies the desired quality of the MM document
and the QoS manager accesses the MM document’s metadata to negotiate the requirements identified by the client.
This work is conceptually similar to our approach, with the
exception that their focus is limited to the MM documents,
whereas our focus is on Grid services.
In the context of QoS management, adaptation has been
explored in various contexts, such as communication networks, distributed multimedia applications, real-time systems and Web interfaces (browsers). For example, Mobiware – developed at Columbia University [9] is a toolkit that
supports adaptation at the network level. Mobiware provides programmable network objects that can be manipulated to provide applications with their desired QoS. Applications must state their QoS requirements using an Application Programming Interface (API), in the form of a util-
ity function and an adaptation policy. The utility function
expresses the desired application requirements with different levels of network bandwidth, while the adaptation policy determines how the applications’ bandwidth allocation
should vary as resource availability changes. This work primarily focuses on network QoS.
Hafid et al. [6] have designed and implemented a QoS
manager responsible for undertaking negotiation and adaptation in the context of distributed multimedia applications.
Based on a user profile, the QoS manager considers possible system configurations, called system offers, and selects
an optimal one – called a user offer. During playback of a
multimedia document, if the network or the server become
congested, thereby lowering presentation quality, the QoS
manager dynamically considers another system configuration from the list of system offers. If an alternative system
offer is selected and the required resources reserved, the
QoS manager then automatically changes to the new system offer – demonstrating adaptive behavior. This work is
conceptually similar to that presented here, with one exception. This lies in the way system offers are generated by
the QoS manager. Whereas in [6] these are based on a user
profile, in G-QoSM these are initially specified by the user
as a range, and then automatically selected by the system if
the required range cannot be met.
3 Grid QoS Management Framework
The Grid QoS Management (G-QoSM) [2] framework
aims to operate in Service-Oriented Grids, and to provide
three main functions: 1) support for resource and service
discovery based on QoS properties, 2) support for providing QoS guarantees at middleware and network levels, and
establishing SLAs to enforce these guarantees, and 3) providing QoS adaptation on the allocated resources. The
G-QoSM delivers three types of QoS levels: Guaranteed,
Controlled Load and Best Effort QoS. In the case of the
guaranteed level, constraints related to QoS parameters of
the client need to exactly match the service provision. Controlled Load is similar to Guaranteed with the exception that
the parameters are defined with less stringent constrains,
and the notion of range-based QoS attribute is used along
with range-based SLAs. On the other hand in Best Effort
QoS the resource manager has full control to choose the
QoS level without any constraints (and corresponds to the
default case when no QoS requirements have been specified).
3.1 G-QoSM System Architecture
G-QoSM consists of three main components as in Figure 1: 1) Application QoS manager (AQoS) exists in every
domain, 2) a Resource Manager (RM), and 3) a Network
Domain1
User1
User2
Domain2
User1
AQoS
NRM
User2
User
AQoS
RM
NRM
AQoS
RM
NRM
Serv
RequestService()
RM
QuerySerives()
S1
S2
Sn
S1
S2
Sn
QueryComputation
Resources()
RM
NRM
AQoS
S
Resource manager
Network resource manager
Application QoS management layer
Service
QueryNetwork
Resources()
Interconnections between components within the same domain
Interconnections between components within different domains
SLAnegotiation()
Resource
Allocation()
Figure 1. The G-QoSM Architecture
Resource
Allocation()
4 UDDIe: Supporting Discovery Based on
Service QoS Properties
UDDIe [11] forms the service registry system in the context of the G-QoSM framework – Figure 3 shows where
the UDDIe integrates with the rest of the framework com-
Service
Invocation()
QoSmanagement()
QoSmanagement()
Figure 2. A Sequence Diagram Shows the Interaction between the Various G-QoSM Component
G−QoSM
2
AQoS
HTTP
1
Client /
Application
HTTP
Broker
Resource Manager (NRM). AQoS is the main focus within
our system, and is required to interact with clients, RMs,
NRMs and neighbouring AQoSs. The AQoS also negotiates
SLAs with clients and communicates parameters associated
with an SLA to the corresponding resource manager. Furthermore the AQoS is responsible for ensuring SLA conformance on the allocated resources, and provides scaling
actions in case of SLA violations. In addition, the middleware resource manager (RM) exists within a given administrative domain. A domain can be defined via an IP mask
or as an administrative domain in Globus, for instance, and
contains a set of services over which the RM has administrative and configuration control. A RM is considered in this
context as a combination of Globus and an extended version of the Universal Description and Discovery Integration
(UDDI) registry, called UDDIe [11]. Globus is used to host
services and to create an execution environment with specific QoS specifications; UDDIe on the other hand is used
as a registry service, where services can be registered and
discovered based on their capability and QoS attributes.
The Network Resource Manager (NRM) is conceptually
a Bandwidth Broker (BB) (the concept of a BB can be found
in [12]), and manages the QoS resources within a given
domain based on the SLAs that have been agreed upon in
that domain. The NRM is also responsible for managing interdomain communication, with the NRMs in neighbouring
domains, with a view to coordinating SLAs across the domain boundaries. The NRM may communicate with local
monitoring tools to determine the state of the network and
its present configuration.
RM
. UDDIe
. Globus
4
HTTP
NRM
3
HT
T
P
Service1
Service2
Service3
Figure 3. The G-QoSM architecture showing
the interaction protocol between the various
components of the framework during the discovery phase at 1 and 2 and QoS management, e.g. resource allocation and monitoring at 3 and 4.
ponents. It is used primarily as a registry to publish QoS
attributes of services, and subsequently to search for services based on QoS attributes. The publication process,
as per the Open Grid Service Architecture (OGSA) specifications, requires that service providers supply two separate WSDL documents, namely, service interface and implementation documents that describe the syntax and semantics for accessing the service. Current OGSA specification does not specify a QoS structure to be included in the
services’ WSDL documents. Every service in our framework has two interfaces: functional and management interfaces. The functional interface describes how the given
service could be accessed, whereas the management interface describes attributes related to QoS and performance
characteristics associated with the service. We incorporate
the QoS properties, such as the resources needed to execute the Grid service and service cost, etc., in the service
management interface – as specified in the OGSA specifications [13]. With this extension to the WSDL document,
the service provider would be able to describe their services
in terms of QoS properties. In order for this extension to be
recognised by a registry system such as UDDI and hence be
searched, the UDDI registry needs to be extended to recognise these additional attributes. We design and implement 3
search capabilities by extending UDDI: service properties,
service leasing and range-based search. These properties
together can be used to search for stored services based on
their properties – rather than their keys or tmodels – as undertaken in a standard UDDI implementation. Documents
stored within the registry also have a lease associated with
them, and an event manager to support these leases has been
implemented in UDDIe. In this way, we are able to search
for documents which match a given range of QoS attributes
– for supporting controlled load QoS. More detailed discussion on the UDDIe enhancement can be found in [11].
specification. As shown, each serviceSpecification
has a parameter defined as a tag and an associated value.
The unit attribute indicates how the value is to be interpreted. Hence a cpuQoS tag is asking for 4 processors of
1GHz specification each.
<serviceSpecific>
...
<cpuQoS unit="ghz" value="1">4</cpuQoS>
<memoryQoS unit="mb">64</memoryQoS>
<networkQoS>
<sourceIP unit="raw">192.200.168.33</sourceIP>
<destIP>135.200.50.101</destIP>
<bandwidth unit="mbps">10</bandwidth>
<packetLoss type="lessthan">10</packetLoss>
</networkQoS>
</serviceSpecific>
Table 1. Sample SLA Specification
Assuming the SLA offer has been approved, then the parameters in the SLA which describe the resources are sent
to the Allocation Manager Alloc-M – which provides an
application level interface to the underlying resource managers. The primary role of Alloc-M is to control resource
managers for allocating/de-allocating resources. Further,
a Reservation System (RS) has been designed and implemented that takes requests for resources, with specified start
and end times from the AQoS along with resource specific
parameters. An example of a RM, in the case of computational (CPU) resources is the GARA library [5][10], which
provides an interface to underlying resource managers, such
as the Dynamic Soft Real-Time scheduler (DSRT) [4]. Table 2 shows sample primitives from the GARA API.
globus_gara_reservation_create(gatekeeper,req_rsl,
&reserve_handle)
globus_gara_reservation_bind(reserve_handle,
&bind_param)
globus_gara_reservation_unbind(reserve_handle)
globus_gara_reservation_cancel(reserve_handle)
5 QoS Provision: Resource Reservation
The approach taken in this work for QoS provision (resource reservation and allocation) can be described as follows: based on a client’s request, resources are temporarily reserved for a pre-defined period of time. The QoS
broker generates a SLA offer, which contains parameters
about resource specification needed to execute the Grid service, such as network bandwidth and CPU requirements.
The SLA offer also contains general elements about the
requested service, such as service cost, service URL, etc.
Then the SLA offer is presented to the client for approval. If
the client approves the SLA then it becomes a commitment
to the QoS broker to deliver the agreed upon parameters
within the SLA; otherwise the resources are released from
the reservation status to enable their reservation for other
requests. Table 1 shows a sample SLA portion for resource
Table 2. Sample Primitives Provided by the
GARA API
In the context of GARA, resource specifications are described in Globus Resource Specification Language (RSL)
[7] and used as the input parameters for reservation purposes. A successful reservation returns a reference called
a Reservation Handler. Subsequent reservations need
to be claimed before they can be used. For example,
when a Grid service is launched, its process binds to a
previously-made reservation using GARA primitive globusgara-reservationbind(...). This primitive binds a process
to individual reservations by providing a reservation reference and the parameters needed to claim the reservation; in
the case of computational resources, the process ID of the
launched process is the only parameter required. Based on
the primitives provided by GARA API and GARA reservation concepts, the Reservation System (RS) within the
AQoS broker implements reservation as follows:
terminating the service being delivered due to a major QoS
degradation. Three scenarios in the context of the G-QoSM
framework, where adaptation is required are described.
• During the discovery phase, resources are reserved on
a temporary basis until the proposed SLA is approved
by the client/application.
Scenario 1: New Service Request : In this scenario a
new service request is received but there are insufficient
resources to accommodate the request. Adaptation can be
used to free resources to accommodate the new request by
adjusting resource allocations of active services while still
satisfying their SLAs. The adaptation function queries the
AQoS about the list of currently active services. The list is
filtered to include only those services whose SLAs indicate
willingness to accept a degraded QoS and/or termination of
service to support compensation.
• The RS generates the appropriate resource specification RSL string, which describes the resources, and
submits it to GARA for reservation.
• If reservation succeeds, a reservation reference is sent
to the AQoS broker.
• The RS waits for a pre-defined period of time for
the corresponding reservation confirmation from the
AQoS.
• If the RS does not receive such confirmation within
the pre-defined period of time, it instructs GARA to
cancel the reservation. Otherwise, the resources are
committed.
• When the Grid service is ready to use the reservation,
it must claim the reservation, and initiate a bind call
to GARA with its (process) ID; this call will associate
the previously made reservation with the reserved resources.
6 QoS Management
QoS management covers a range of different activities,
from resource selection and allocation through to resource
release. Adaptation, monitoring and re-negotiation are examples of QoS management functions during the active session. The adaptation approach presented here provides the
dynamic adjustment of behavior of an application based on
changes in the pre-defined SLA. The approach is particularly useful if workload or network traffic changes in unpredictable ways during an active session. The proposed QoS
adaptation scheme is used to compensate for QoS degradation and optimize resource utilization, by increasing the
number of service requests managed by the QoS broker
(AQoS) over a particular time. Such a scenario could take
place, for instance, if the underlying network or resource
are changed in an unpredictable way.
6.1 Adaptation Scenarios
QoS adaptation is a key function of QoS management
during the Active phase of a session. The response of the
AQoS should result in either (a) restoring the agreed upon
QoS (in SLA); (b) re-negotiating QoS as per the SLA; or (c)
Scenario 2: Service Termination : In this scenario a service completes successfully, and its resources are released.
Adaptation can be used to increase resources allocation for
a selected number of existing services while still satisfying
their SLAs; the objective is to make use of the released resources and thus increase the profits of the service provider.
This can be realized by (a) upgrading the QoS of existing
services that had their QoS reduced; or (b) upgrading the
QoS of existing services that are not currently receiving the
‘best’ QoS – as defined in their SLAs; or (c) presenting promotion offers to existing services for upgrading their QoS
to attract additional resource requests.
Scenario 3: QoS Degradation : This scenario is the classical QoS adaptation situation where QoS falls below the
specified QoS level (i.e. minimum acceptable QoS) in the
SLA. The QoS degradation is detected either by the resource monitoring system or by an explicit notification from
the underlying resource manager. Adaptation is used, if
possible, to restore the degraded QoS to an acceptable QoS
as defined in the SLA.
6.2 Resource Allocation Optimization
Within the G-QoSM framework there can be a number
of different users, each requesting a particular set of QoS
parameters. These must be agreed upon in the negotiated
SLA – consisting of the parameters required by a user,
along with other service management parameters, such as
service name, service class and duration. If all the parameters associated with QoS are extracted and expressed as
set QoS, then QoS = {a1 , a2 , ..., an }, where each ai represents a different parameter of interest (e.g. cache, primary memory, CPU capability and bandwidth). One is
now able to compare two different QoS sets, by comparing each element of the set; hence if QoSx = {ax1 , ..., axn }
and QoSy = {ay1 , ..., ayn }, then one can compare axi with
ayi . Furthermore, QoS parameter values ai may be recorded
in the SLA in two forms: (1) based on a parameter range;
such that: ay ≤ ai ≤ ax ; where ax is a better quality than
ay ; implying that the user requires a minimum of ay level of
quality, but it would be better, from the user’s point of view,
to receive an ax level of quality, and (2) based on a list –
where the user states distinct values for a particular QoS
parameter, for example: ai = {x, y, z}; where x, y and z
are integer numbers representing the acceptable values for
QoS parameter ai . Each QoS ai has a corresponding cost
ci 1 ; where ci is a constant, related to the pricing formula
for the class of service assigned to this user. The monetary
cost for a particular QoS parameter may be calculated as
Cost(ai ) = ci ∗ ai , and, subsequently, the monetary cost of
the QoS set for a particular service may be calculated as:
Service Cost(QoS) =
n
X
(ci ∗ ai )
i=1
Given the above assumptions, the optimization problem can
be defined as:
n
X
T otal Cost = max
(Service Cost(QoSi ))
i=1
where n represents the total number of active services. The
AQoS implements this optimization by varying the resource
quality selection, based on supplied levels of quality in
the SLA, which aims to maximize overall monetary profit,
while maintaining the user’s acceptable quality.
6.3 Adaptation Algorithm
Unlike the optimization heuristic, this adaptation algorithm only operates on the ‘guaranteed’ and ‘best effort’
classes. As the ‘guaranteed’ class of user receives the highest level of attention, it is important to provide them with
extra assurances through adaptation approaches. The algorithm requires the system administrator to specify the
total resource capacity specified for the ‘guaranteed’ and
‘best effort’ users. The term ‘resource capacity’ encompasses CPU, network and storage resources. The algorithm reserves an ‘adaptive capacity’, based on the specified rate of resource failure or congestion provided by the
system administrator. The algorithm also considers a minimum capacity for ‘best effort’ clients, as determined by
the system administrator. These capacity allocations are
dynamic in that if the adaptive and/or guaranteed capacities are not used, then the ‘best effort’ capacity compensates and utilizes free resources, provided they are not currently allocated. The Algorithm starts execution by invoking: (a) the Allocate Guaranteed Resource or (b) the Allocate Best Effort Resource function, as outlined in Algorithm 1.
1 Although specified as a “cost”, these weighting parameters may also
have other semantic interpretations, such as priority or user preference
Algorithm 1 QoS adaptation
C: the total resource capacity
CG : the ‘guaranteed QoS’ capacity
CA : the adaptive capacity
CB : the ‘best-effort QoS’ capacity
Then C = CG + CA + CB
U : set of ALL user U = {u1 , ...., un }
G: set of users of class ‘guaranteed’ G = {v1 , ...., vn }
B: set of users of class ‘best effort’ B = {w1 , ...., wn }
c(u, t) = capacity required at time t by user u ∈ G
b(u, t) = capacity required at time t by user u ∈ B
g(u) be the guaranteed capacity with a SLA for user u ∈
G
Available
Guaranteed Resource(g(u))
P
if
g(u)
≤ CG then
u∈G
SLA guarantees to g(u) can be honored
end if
Adapt()
P
Net capacity NG (t) = CG (t) − u∈G g(u)
if NG (t) < 0 , (guarantees cannot be honored at time ‘t’)
then
P
ADD( u∈G g(u)
P− CG (t)) from A to G
ADD(CA (t) − [ u∈G g(u) − CG (t)]) from A to B
end if
Allocate Guaranteed Resource(c(u,t), g(u))
if {c(u, t) ≤ g(u) then
c(u, t) capacity must be given
else if NOT Available Guaranteed Resource(g(u)) then
Adapt; allocate c(u,t) capacity
else if {c(u, t) > g(u) then
only g(u) capacity is given
cnew(u,t) ← g(u)
Allocate Guaranteed Resource(cnew(u,t) , g(u))
end if
Allocate Best Effort Resource(b(u,t))
if b(u, t) ≤ NB (t); (NB (t) = CB (t)) then
allocate b(u, t)
else
cannot allocate the required capacity
end if
The proposed adaptation algorithm has the following advantages: (a) Resources are never under-utilized due to the
dynamic property of the algorithm. The extra reserved capacity is used by ‘best effort’ users as long as it is not
needed by ‘guaranteed’ users; and (b) a minimum resource
capacity is allocated for ‘best effort’ users, therefore users
with no SLAs can always make use of the ‘best effort’ resources – and their applications also have the ability to proceed.
6.4 Adaptation Strategies of Grid Services
The adaptation scheme is based on the above algorithm,
and the resource allocation optimization described in section 6.3 and section 6.2 respectively. The optimization
heuristic is executed periodically by the AQoS broker; if
there is a considerable gain in benefits to the Grid Service
provider (increase in monetary profit and/or admission of
more service requests), resources allocation is adjusted to
match these changes. On receiving a request from a client
requesting a ‘guaranteed’ QoS level, the adaptation algorithm (section 6.3) is applied; if the request cannot be accommodated, the optimization heuristic is executed.
7 Implementation
The implementation testbed is built on RedHat Linux
7.2 and Globus Toolkit v2.0. The programming tools are:
Java2 SDK Version 1.4.0, Java CoG kit [14], UDDIe (an
extended version of the UDDI registry) and the Tomcat application server. A QoS broker (AQoS) which supports the
functions outlined in the sequence diagram of Figure 2 is
implemented. The QoS broker is integrated with the Dynamic Soft Real-Time (DSRT) scheduler [4] as the computation (CPU) scheduler – which can operate with both single processor and multiprocessor systems. GARA’s DSRT
resource manager API is used to facilitate the interaction
between the QoS broker and the DSRT scheduler.
The overall implementation architecture works as follows: a client application communicates with the AQoS
broker using SOAP messages over the HTTP protocol. The
AQoS and the UDDIe are server processes that are hosted
in a Tomcat Web server as servlets, and communicate with
a Globus runtime environment. The AQoS communicates
with the DSRT scheduler through GARA’s DSRT manager
API for resource reservation and allocation.
Figures 4 and 5 are screen shots taken from the prototype
implementation to demonstrate activities outlined in the sequence diagram in Figure 2. Figure 5 is a client interface
screen – the client has to fill out the service request
message and send it to the AQoS ‘servlet’; the lower half of
this screenshot shows the response from the AQoS. In this
case it is a service offer based on the supplied QoS criteria
Figure 4. A screenshot, showing activities undertaken by the AQoS broker
for the desired service. A client interface is used primarily
for demonstration purposes; however, in practice applications should themselves generate the service request
messages and contact a SOAP server to transmit messages.
The client interface screen has four options (on the righthand side): (a) requesting a service with QoS properties,
(b) accepting SLA offers, (c) rejecting SLA offers, or (d)
requesting an explicit SLA verification test. Figure 4 provides a screenshot of activities undertaken by AQoS to accomplish the specified request, such as, contacting the UDDIe registry, reserving resources and computing the total
service QoS cost. The system administrator may also use
this interface to see service offers from the AQoS, and the
subsequent client approval or rejection of the offer.
8 Conclusions
A framework for QoS-based service management in
service-oriented Grids is described. The main focus of this
framework is to provide i) a means for the service requesters
to search, locate and execute services based on QoS criteria
in Grids environment, ii) to provide QoS provisions through
resource advance reservation and to establish SLAs, and iii)
to provide QoS management during active session, such as,
adaptation if there is resource failure, congestion or to optimize resource utilization. This work builds on the Open
Grid Services Infrastructure (OGSI) being developed within
the Global Grid Forum (GGF), and involves close interaction with the Java Commodity Grid Kit (CoG) project team.
As a future topic it is planned to evaluate this framework in
the context of a particular Grid application, such as thermal
[4] H. Chu and K Nahrstedt. A cpu service classes for
multimedia applications. In IEEE Multimedia Systems
’99, 1999.
[5] I. Foster, C. Kesselman, et al. A distributed resource
management architecture that supports advance reservation and co-allocation. In Proceedings of the International Workshop on Quality of Service, pages 27–
36, 1999.
[6] A. Hafid, G.Bochmann, and B. Kerherve. A quality of
service negotiation procedure for distributed multimedia presentational applications. In HPDC ’96, pages
330–339, 1996.
[7] Argonne National Laboratory. The globus project.
See Web Site at: http://www.globus.org/, Last visited:
February 2003.
[8] E. Madja, A. Hafid, R. Dssouli, G.v. Bochmann, and
J. Gecsei. Meta-data modelling for qulaity of service
managment in the world wide web. In Proc. of Int.
Conf. on Multimedia Modeling, 1998.
[9] A. Oguz et al. The mobiware toolkit: Programmable
support for adaptive mobile networking. IEEE Pesronal Communications Magazine, Special Issue on
Adapting to Network and Client Variability, 5(4),
1998.
Figure 5. A client interface screenshot, showing the client entered a ‘service request’ and
the AQoS broker replied with a service offer
chemistry or a bio-informatics applications.
References
[1] R. Al-Ali, A. Hafid, O. Rana, and D. Walker. Qos
adaptation in service-oriented grids. In Proceedings
of the 1st International Workshop on Middleware for
Grid Computing (MGC2003) at ACM/IFIP/USENIX
Middleware 2003, Rio de Janeiro, Brazil, 2003.
[2] R. Al-Ali, O. Rana, D. Walker, S. Jha, and S. Sohail.
G-QoSM: Grid service discovery using QoS properties. Computing and Informatics Journal, Special Issue on Grid Computing, 21(4):363–382, 2002.
[3] R. Al-Ali, A. ShaikhAli, O. Rana, and D. Walker.
Supporting QoS-based discovery in service-oriented
grids. In Proceedings of IEEE Heterogeneous Computing Workshop (HCW’03), Nice, France, 2003.
[10] A. Roy. End-to-End Quality of Service for High-End
Applications. PhD thesis, The University of Chicago,
August 2001.
[11] A. ShaikhAli, O. Rana, R. Al-Ali, and D. Walker. UDDIe: An extended registry for web services. In Proceedings of Workshop on Service Oriented Computing: Models, Architectures and Applications at SAINT
2003, IEEE CS Press, pages 85–90, Orlando FL, USA,
2003.
[12] B. Teitelbaum, S. Hares, L. Dunn, R. Neilson,
R. Vishy Narayan, and F. Reichmeyer. Internet2
qbone: Building a testbed for differentiated services.
IEEE Network, 13(5):8–17, September 1999.
[13] S. Tuecke, K. Czajkowski, et al. Grid service specification. Technical report, Argonne National Laboratory, Chicago, July 2002. Technical Report.
[14] G. von Laszewski, I. Foster, J. Gawor, and P. Lane.
A java commodity grid kit. Concurrency and Computation: Practice and Experience, 13(8-9):643–662,
2001.
[15] D. Xu, K. Nahrstedt, and D. Wichadakul. Qos-aware
discovery of wide-area distributed services. In Proceedings of the First IEEE/ACM CCGrid2001, 2001.