QoS-Oriented Service Computing - Advanced Design Approaches to Emerging Software Systems - page 283

(SLA) and associated reference architecture, (ii)
green service, (iii) service metering and metrics,
(iv) service monitoring, (v) service QoS assur-
ance, and (vi) on-demand resource provisioning.

customer/broker finds the appropriate service
provider from Service Marketplace through SLA
template, customer/broker makes a proposal to
the service provider by modifying service level
requirement terms. The service provider will
then check the resources to make sure whether
service level requirements can be guaranteed, and
will accept or /reject the proposal. Once the SLA
proposal is agreed by both parties, it becomes an
SLA instance.

Service Level Agreement and
Reference Architecture

Service Level Agreement (SLA) can be employed
to serve as a bilateral contract that exists between
a customer and a service provider to specify the
user requirements, quality of service, responsibili-
ties and obligations. SLA can contain numerous
service performance metrics with corresponding
Service Level Objectives (SLO). It describes
quality of service and other commitments by a
service provider in exchange for financial com-
mitments based on an agreed schedule of prices
and payments. A high-level and generic SLA
reference architecture has been proposed based
on the key requirements identified, as shown in
Figure 1. One of the innovative features of the
proposed reference architecture is the incorpora-
tion of domain ontology to allow the SLA manager
semantic aware. The SLA manager contains the
following key functional component modules,
and each module is briefly discussed as follows:

MetaScheduler

MetaScheduler can be used for resource metas-
cheduling or resource access control. It involves
the consideration of the current status of all
available suitable computational resources and
selecting the resource that is most suitable for
the simulation in question. It accepts the agreed
SLA instance as one of input, and returns a list
of End Reference Points (ERP) of resources or
returns none ERP. A list of ERPs returned or no
ERP returned can be regarded as a kind of access
control mechanism. For example, in the case that
each job to be submitted has an SLA constraints,
the metascheduler can return an ordered list of
available computing resources on which the job
can be carried out respecting SLA's constraints.

Service Marketplace

Runtime Monitor

Service marketplace provides a store for service
providers to publish their services with price.
Customer can search services not only by func-
tionality but also QoS requirements. The service
market place will return a list of EPRs of match-
ing services with price. The returned list can be
ranked by QoS requirements or price. The service
marketplace can be implemented using standard-
based technologies such as UDDI, ebXML, etc.

It collects the resource usage information to moni-
tor associated parameters related to service level
objectives. This component usually interacts with
a service-side / resource-side resource usage or
QoS measurement component that is responsible
for the acquisition of resource usage data and QoS
measurement data. The monitoring protocol can
be polling protocol, publish/subscribe, call-back,
etc. Runtime Monitor contains the following
functional sub-modules: Negotiator

The negotiator component is responsible for SLA
negotiation based on the SLA template. Once

• Term Interpreter: mapping of high level

application-specific business objectives