Policy-Based Management of QoS in Service Aggregations · Using our QoS meta-model, both service...
3
Policy-based Management of QoS in Service Aggregations Mohan Baruwal Chhetri Swinburne University of Technology Center for Complex Software Systems and Services Hawthorn, Australia [email protected] Bao Quoc Vo Swinburne University of Technology Center for Complex Software Systems and Services Hawthorn, Australia [email protected] Ryszard Kowalczyk Swinburne University of Technology Center for Complex Software Systems and Services Hawthorn, Australia [email protected] Abstract—We present a policy-centered QoS meta-model which can be used by service providers and consumers alike to express capabilities, requirements, constraints, and general management characteristics relevant for SLA establishment in service aggregations. We also provide a QoS assertion model which is generic, domain-independent and conforming to the WS-Policy syntax and semantics. Using these two models, as- sertions over acceptable and required values for QoS properties can be expressed across the different service layers and service roles. Keywords-WS-Policy, QoS meta-model, QoS assertion model I. I NTRODUCTION Policy-based approaches using the WS-Policy specifica- tions and its extensions have been widely proposed for SLA management including automated service selection [1], SLA negotiation [2], runtime monitoring of service executions [3] and general composite service management [4]. However, not much work has been done on identifying and capturing a complete set of concepts necessary for expressing require- ments and capabilities in terms of QoS properties across the different service layers (business, operational/technical service layer and infrastructure/resource layer) and different service roles (such as service aggregator, service consumer and service provider). Additionally, although WS-Policy provides a container structure and simple logic framework allowing policy assertions to be plugged in, a generic as- sertions model which is rich enough to capture expressive descriptions of QoS requirements and capabilities is missing. We address the first issue by developing a policy-centered QoS meta-model which is rich and expressive enough to capture QoS requirements and capabilities at the different service layers and across the different service roles . We address the second issue by developing a simple, generic QoS assertion model which allows the specification of assertions over QoS preferences across the service layers using the QoS meta-model. Assertions can also be made over the relationships and dependencies between QoS properties within and across the service layers and service roles. Using our policy framework, end-users can express their requirements at any level they are comfortable with i.e. business level, technical service level and resource level. Similarly, service providers can also express their non- functional capabilities and constraints at the appropriate lay- ers. Additionally, the service providers and service aggrega- tors can specify policies which determine how the user-level preferences can be mapped to service level capabilities. This mapping is necessary for both QoS-based service selection and for automated negotiation for SLA establishment. II. RELEVANCE TO SERVICE AGGREGATION ON THE CLOUD The Service Oriented Computing (SOC) paradigm has paved the way for a new service-oriented business model which is referred to as Service Aggregation. In this model, the service aggregator, which is a business entity, aggregates several component services in innovative ways to generate new business capabilities that it offers to its clients. This business model is particularly relevant in the cloud computing context where the vision is to offer everything as a service [5], whereby literally any hardware or software resource can be offered as a service. Some example cloud services include Software as a Service (SAAS) e.g. Telstra’s TSuite, Platform as a Service (Paas) e.g. Microsoft’s Azure and Google’s AppEngine, Infrastructure as a Service (IaaS) e.g. Google’s AppEngine, Storage as a Service (Stass) e.g. Amazon’s Simple Storage Service, Data as a Service (DaaS) and potentially Network as a Service (NaaS). Thus a service aggregation on the cloud can include any type of service and the QoS characteristics of these services can be expressed at different layers using different metrics such as business metrics, technical service metrics and resource metrics. The end-consumers generally express their QoS requirements using subjective business metrics. The atomic service providers (who are participating in the service aggregation) express their capabilities using objec- tive technical service metrics. The service aggregators who are responsible for matching the end-consumer requirements to the composite service metrics and further decomposing them into individual service level metrics have to provide the appropriate mapping from the user level QoS requirements to the technical service level requirements. 2010 10th IEEE/ACM International Conference on Cluster, Cloud and Grid Computing 978-0-7695-4039-9/10 $26.00 © 2010 IEEE DOI 10.1109/CCGRID.2010.95 593 Authorized licensed use limited to: SWINBURNE UNIV OF TECHNOLOGY. Downloaded on August 11,2010 at 08:49:06 UTC from IEEE Xplore. Restrictions apply.
Transcript of Policy-Based Management of QoS in Service Aggregations · Using our QoS meta-model, both service...
Policy-based Management of QoS in Service Aggregations
Mohan Baruwal ChhetriSwinburne University of Technology
Center for Complex SoftwareSystems and ServicesHawthorn, Australia
Bao Quoc VoSwinburne University of Technology
Center for Complex SoftwareSystems and ServicesHawthorn, Australia
Ryszard KowalczykSwinburne University of Technology
Center for Complex SoftwareSystems and ServicesHawthorn, Australia
Abstract—We present a policy-centered QoS meta-modelwhich can be used by service providers and consumers aliketo express capabilities, requirements, constraints, and generalmanagement characteristics relevant for SLA establishment inservice aggregations. We also provide a QoS assertion modelwhich is generic, domain-independent and conforming to theWS-Policy syntax and semantics. Using these two models, as-sertions over acceptable and required values for QoS propertiescan be expressed across the different service layers and serviceroles.
Keywords-WS-Policy, QoS meta-model, QoS assertion model
I. INTRODUCTION
Policy-based approaches using the WS-Policy specifica-tions and its extensions have been widely proposed for SLAmanagement including automated service selection [1], SLAnegotiation [2], runtime monitoring of service executions [3]and general composite service management [4]. However,not much work has been done on identifying and capturinga complete set of concepts necessary for expressing require-ments and capabilities in terms of QoS properties acrossthe different service layers (business, operational/technicalservice layer and infrastructure/resource layer) and differentservice roles (such as service aggregator, service consumerand service provider). Additionally, although WS-Policyprovides a container structure and simple logic frameworkallowing policy assertions to be plugged in, a generic as-sertions model which is rich enough to capture expressivedescriptions of QoS requirements and capabilities is missing.
We address the first issue by developing a policy-centeredQoS meta-model which is rich and expressive enough tocapture QoS requirements and capabilities at the differentservice layers and across the different service roles . Weaddress the second issue by developing a simple, genericQoS assertion model which allows the specification ofassertions over QoS preferences across the service layersusing the QoS meta-model. Assertions can also be made overthe relationships and dependencies between QoS propertieswithin and across the service layers and service roles.
Using our policy framework, end-users can express theirrequirements at any level they are comfortable with i.e.business level, technical service level and resource level.
Similarly, service providers can also express their non-functional capabilities and constraints at the appropriate lay-ers. Additionally, the service providers and service aggrega-tors can specify policies which determine how the user-levelpreferences can be mapped to service level capabilities. Thismapping is necessary for both QoS-based service selectionand for automated negotiation for SLA establishment.
II. RELEVANCE TO SERVICE AGGREGATION ON THECLOUD
The Service Oriented Computing (SOC) paradigm haspaved the way for a new service-oriented business modelwhich is referred to as Service Aggregation. In this model,the service aggregator, which is a business entity, aggregatesseveral component services in innovative ways to generatenew business capabilities that it offers to its clients.
This business model is particularly relevant in the cloudcomputing context where the vision is to offer everythingas a service [5], whereby literally any hardware or softwareresource can be offered as a service. Some example cloudservices include Software as a Service (SAAS) e.g. Telstra’sTSuite, Platform as a Service (Paas) e.g. Microsoft’s Azureand Google’s AppEngine, Infrastructure as a Service (IaaS)e.g. Google’s AppEngine, Storage as a Service (Stass) e.g.Amazon’s Simple Storage Service, Data as a Service (DaaS)and potentially Network as a Service (NaaS).
Thus a service aggregation on the cloud can includeany type of service and the QoS characteristics of theseservices can be expressed at different layers using differentmetrics such as business metrics, technical service metricsand resource metrics. The end-consumers generally expresstheir QoS requirements using subjective business metrics.The atomic service providers (who are participating in theservice aggregation) express their capabilities using objec-tive technical service metrics. The service aggregators whoare responsible for matching the end-consumer requirementsto the composite service metrics and further decomposingthem into individual service level metrics have to provide theappropriate mapping from the user level QoS requirementsto the technical service level requirements.
2010 10th IEEE/ACM International Conference on Cluster, Cloud and Grid Computing
978-0-7695-4039-9/10 $26.00 © 2010 IEEE
DOI 10.1109/CCGRID.2010.95
593
Authorized licensed use limited to: SWINBURNE UNIV OF TECHNOLOGY. Downloaded on August 11,2010 at 08:49:06 UTC from IEEE Xplore. Restrictions apply.
III. POLICY MODEL
WS-Policy provides a container structure for clustering orgrouping together different alternatives using the WS-Policyoperators of wsp:Policy, wsp:All and wsp:ExactlyOne. Eachalternative is a conjunction of policy assertions where eachassertion represents a requirement or a capability, as shownin the generic policy model in Figure 1, which is largelyrepresentative of most policy language proposals. The re-quirement or capability assertion is a constraint on a givenQoS attribute. It specifies the accepted and supported valuesfor the QoS attribute (whether it is a single value, a set ofvalues, an allowable range or a range of values). It uses apredicate operator to describe the constraints.
In order to express requirements and capabilities as WS-Policy assertions, there needs to be an appropriate policyvocabulary which describes the different QoS attributes thatare applicable to a given application domain or context. Alsothe appropriate predicates have to be defined which improvethe expressivity of the assertions. The policy-centered QoSmeta-model can be used to define the vocabulary for a givenapplication domain/context. The meta-model also supportsthe specification of preferences over the QoS attributesthrough the use of concepts such as relative importance andutility.
The assertion model can be used to specify the prefer-ences over QoS requirements and capabilities. In addition,it can be used to specify additional management assertionswhich aid participants (service consumers and providers) intheir decision making process (such as evaluating of offers,ranking offers and generating counter offers) during serviceselection and negotiation.
IV. POLICY CENTERED QOS META-MODEL
Our QoS meta-model includes all the concepts that arenecessary for specifying quality attributes across the differ-ent service layers and service roles. Using our QoS meta-model, both service requestors and service providers canspecify assertions over their QoS requirements, capabilitiesand constraints which can be then incorporated into thedecision-making process whether it is QoS based selectionor negotiation.
Our QoS meta-model provides the following key benefits:• Most existing QoS models only support simplistic as-
sertions using attribute-value clauses. Our meta-modelsupports more expressive descriptions through multi-value expressions (such as set of values or ranges)
• WS-Policy currently only supports boolean expressionsover hard constraints. Our meta-model can be used toexpress soft constraints. Since it supports the definitionof weighted values (relative importance) and utility forQoS properties it can be used to measure the degree ofsatisfaction over given offer assertions (as opposed topure boolean matching only).
Figure 1. Generic Policy Model
Figure 2. Important concepts for specifying QoS preferences
• Our QoS meta-model supports both qualitative andquantitative QoS properties. Attribute values can be ex-pressed on the different measurement scales includingnominal, ordinal, interval and ratio scales.
• Most existing QoS models focus purely on the technicalQoS only. However, we allow the description of anynon-functional property, either at the business level, thetechnical service level or resource level.
• Our QoS meta-model currently supports a rich set ofcomparison operators such as ’equalTo’, ’lessThan”,’greaterThan’, ’lessEqual’, ’greaterEqual’, ’atLeast’,’atMost’ in addition to the logical operators of ’AND’,’OR’, ’XOR’.
V. QOS ASSERTION MODEL
Each policy assertion represents a constraint on the QoSattribute at either the business layer, the operational layer orthe resource layer.
A. Preferences Assertion Model
The service requestor can express his/her QoS require-ments using the QoS Assertion model. Each QoS Assertioncan be for a single QoS attribute or for a group of QoSattributes. Our QoS meta-model is flexible enough to repre-sent user level QoS either as classes of service where eachclass maps to a specific user-level configuration, or use amore specific approach where the user has the ability toexplicitly specify preferences over requirements over each
594
Authorized licensed use limited to: SWINBURNE UNIV OF TECHNOLOGY. Downloaded on August 11,2010 at 08:49:06 UTC from IEEE Xplore. Restrictions apply.
Figure 3. Preference Assertion over Qualitative Attributes
individual QoS attribute. Figure 3 shows an simple exampleof a clustering of QoS requirements assertions.
B. Management Assertion Model
The service aggregator knows which services are to beaggregated, how and why. Hence it knows exactly what QoScharacteristics are defined for the various services that areaggregated together. Similarly, it knows what user level QoScharacteristics to expose to the end users. It also knows howthe user level QoS attributes map to the technical servicelevel QoS and resource level QoS. In the management as-sertion model, we have defined the specific assertions listedbelow which aid the decision making process. Additionalmanagement aspects can be defined as policy assertions asrequired.
• QoS Aggregation Assertion - which defines howto aggregate QoS attributes according to the specificaggregation function, taking into account the serviceaggregation pattern.
• QoS Influence Assertion - which defines the influencerelationship a QoS attribute has on others. For example,the throughput has a direct relationship with the pricewhile latency has an inverse relationship.
• QoS Tendency Assertion - which defines what thepreferred tendency for a given QoS attribute is. Forexample, for throughput the impact direction is positiveand for response time the impact direction is negative.
• QoS Mapping Assertion - which defines how theuser perceived QoS maps to technical service QoS.Different types of mappings are possible such as one-to-one, one-to-many and many-to-one. For example, theuser perceived video quality is qualitative (”Excellent”,”Good”, ”Bad”) and maps to the actual media qualitywhich is quantitative and depends upon the technicalQoS attributes of frame rate, frame size and resolutionas shown in Figure 4.
• QoS Value Mapping Assertion - This is an extensionto the QoS Mapping Assertion, which allows to map
Figure 4. Example Management Assertions
specific values of a QoS attribute at one layer (singlevalues, set of values or ranges) to specific values ofother QoS attributes at other layers.
VI. CONCLUSION
In this paper, we have presented a policy-centered QoSmeta-model and QoS assertion model for expressing capabil-ities, requirements and general management characteristicsrelevant for SLA establishment in a syntax which conformsto WS-Policy specifications. The novel contribution of ourQoS meta-model is that it is rich enough to describe QoScharacteristics at any service layer and for any service role.Similarly, our generic assertions model can be used to makestatements about requirements, capabilities and preferencesand constraints over QoS attributes. Our framework aimsto complement existing service selection and negotiationframeworks and is particularly useful for enabling automatedSLA establishment for service aggregations on the cloud.
REFERENCES
[1] S. Chaari, Y. Badr and F. Biennier, Enhancing Web ServiceSelection by QoS-Based Ontology and WS-Policy, In Proceed-ings of the 2008 ACM Symposium on Applied Computing, pp.2426-2431, 2008
[2] F. Zulkernine, P. Martin, C. Craddock and K. Wilson, APolicy-Based Middleware for Web Services SLA Negotiation, inProceedings of 2009 IEEE International COnference on WebServices, Los Angeles, CA, pp. 1043-1050, 2009
[3] A. Erradi, P. Maheshwari and V. Tosic, WS-Policy basedMonitoring of Composite Web Services, in Proceedings of the5th European Conference on Web Services (ECOWS 2007),IEEE Computer Society, pp. 99-108, 2007
[4] Z. Maamar, D. Benslimane and A. Anderson, Using Poli-cies to Manage Composite Web Services, in IT Professional,Volume 8, Issue 5, pp. 47-51, 2006
[5] H. R Motahari-Nezhad, B. Stephenson and S. Sing-hal Outsourcing Business to Cloud Computing Services:Opportunities and Challenges, Technical Report HPL-2009-23, http://www.hpl.hp.com/techreports/2009/HPL-2009-23.html, 2009
595
Authorized licensed use limited to: SWINBURNE UNIV OF TECHNOLOGY. Downloaded on August 11,2010 at 08:49:06 UTC from IEEE Xplore. Restrictions apply.
