The document discusses a faceted approach to filtering service level agreement (SLA) templates. It presents a two-layered model to categorize SLA template information into distinct modules or facets. An experiment tests the performance of filtering SLA templates stored in either a document-based or relational database as the number of concurrent requests increases. The results show that a NoSQL document-based approach may be better suited for the dynamic web-based scenario. Ongoing work involves transforming SLAs into a dependency graph for evaluation using a graph database.
1. T H E F O U R T H I N T E R N AT I O N AL C O N F E R E N C E O N C L O U D
C O M P U T I N G , G R I D S , AN D V I R T U AL I Z AT I O N
C L O U D C O M P U T I N G 2 0 1 3
SLA Template Filtering:
A Faceted Approach
K. Stamou, V. Kantere and J.H. Morin
{aikaterini.stamou, verena.kantere, jean-henry.morin}@unige.ch
June 1, 2013Institute of Services Science (ISS)
2. Contents
June 1, 2013Institute of Services Science (ISS)
Problem formalization
Faceted navigation
SLA template repository
Experimentation
On-going work, conclusions
3. SLA definition, tree-structure
June 1, 2013Institute of Services Science (ISS)
A Service Level Agreement provides an explicit view on howa
service provisioning is planned
Providers and customers use SLAs to measure actual
consumption of resources during service execution
SLAs represent nested tree structures
According to (Ludwig et al. 2003, Andrieux et
al. 2007) a SLA consists of three primary sections:
o Service description
o Guarantees or obligations
o Aninformativesectionregardinginvolvedpartiesand/or the provisioned
service
4. Research challenges
June 1, 2013Institute of Services Science (ISS)
Obstacle: SLAs hardly appear in marketplaces…
Equilibrium: SLAs as automated processes vs. static, non-
machine readable documents
Semantic and structural heterogeneity of SLA content, semi-
structured data of unbounded length
SLA data model requirements:
Modularity
Dynamic updates
Rapid traversals through branches of diverse, nested information
5. SLA templates
June 1, 2013Institute of Services Science (ISS)
A pre-instantiated SLA that encloses aprovider’s resource
availability and provisioning plan
Customers review SLA templates and proceed with either
agreement initialization or negotiation with service providers
SLA templates:
Can be viewed as ”What You See Is What You Get” (WYSIWIG) snapshots
Include dynamic information that is updated at frequent time intervals
Need to ensure dynamic content updates
Content modularity allows viewing service offer sections as facets
6. Facets, SLA data-model
June 1, 2013Institute of Services Science (ISS)
A facet represents a category of hierarchically ordered
information
SLA faceted filtering enables flexible service navigation that is
driven by customer provisioning requirements
Data-model:
Data categorization into distinct SLA modules
Nesting within a SLA template module depends on information content
Information granularity
7. SLA filtering model
June 1, 2013Institute of Services Science (ISS)
2-layered design
A template may contain up to N
SLAroot-themes
Parameter
combinationsindicate navigation
and filtering options
Data modularity and model
multidimensional structure allow
for quick and selective
navigation through designated
nested information
8. SLA template storage
June 1, 2013Institute of Services Science (ISS)
Document-based
schema (MongoDB)
Relational
schema (MySQL)
9. Experimentation setup
June 1, 2013Institute of Services Science (ISS)
Filters in faceted navigation translate customer choices into conditional
queries
Assumptions:
An IT marketplace provides SLA faceted navigation as an interaction tool for
customers to submit their criteria
One centralized data repository for the SLA template storage
Simulation environment setup:
24 Intel-Xeon 2.50 GHz computing machine, 128GB of RAM, OS: Ubuntu 12.04
Web server deployment: Tornado (Python)
Client: multithreaded Python scripts pass HTTP GET requests to the web server
Both DBMS are deployed on the same machine to reduce TCP overhead
Goal: server response timeto incoming customer requests and scalability
of the filtering operation as the number of simultaneous requests increase
10. Experimentation results
June 1, 2013Institute of Services Science (ISS)
oConcurrent client requests of diverse service parameters reach the server
oIncoming parameters represent SLA facet attributes
oTest 1: total time of the
filtering operation over
HTTP
oTimings include HTTP
and backend processing
overhead
11. Experimentation results
June 1, 2013Institute of Services Science (ISS)
oTest 2: filtering runs are
processed locally on the server to
avoid additional network overhead
oStart with 100 and reach up to
100,000 concurrent requests for
both databases
oUpdate queries are processed
in parallel to filtering requests
and account for an extra 10% of
workload on the total database
processing
12. Conclusions and on-going work
June 1, 2013Institute of Services Science (ISS)
oA NoSQL approach possibly fits better for the web scenario, where SLA
offers are manipulated over HTTP
oCurrent work involves the SLA transformation into a dependency graph
(Ward et al. 2002)
oExperimentation
with regular path
queries can help
evaluate the
pros/cons of the
graph database
approach
13. Thank you!
June 1, 2013Institute of Services Science (ISS)
Q&A: aikaterini.stamou@unige.ch
14. References
June 1, 2013Institute of Services Science (ISS)
Ludwig, H., Keller, A., Dan, A., King, R.P., Franck, R. 2003.
"Web Service Level Agreement (WSLA) Language
Specification," in: IBM Research. IBM Corporation.
Andrieux, A., Czajkowski, K., Dan, A., Keahey, K., Ludwig, H.,
Nakata, T., Pruyne, J., Rofrano, J., Tuecke, S., Xu, M.
2007. "Web Services Agreement Specification (WS-
Agreement)." Open Grid Forum.
Ward, C., Buco, M.J., Chang, R. N., Luan, L. Z. 2002. "A
Generic SLA Semantic Model for the Execution
Management of E-Business Outsourcing Contracts,"
Proceedings of the Third International Conference on E-
Commerce and Web Technologies: Springer-Verlag, pp.
363-376.
Notas del editor
Same number of experiments for both databases.Test 1: total time of the filtering operation over HTTP.Total time starts from the point a client request reaches the server up to the point the server returns the result to the client. Timings include HTTP and backend processing overhead.Concurrent client requests of diverse service parameters reach the server. A Python process handles the requests and returns the results over HTTP.Incoming parameters represent SLA facet attributes. Their number depends from the facet type and its nesting depth.
Test 2: filtering runs are processed locally on the server to avoid additional network overhead. Measurements combine the query processing from filtering and database updates to measure their overhead on the filtering operation.Update queries are processed in parallel to filtering requests and account for an extra 10% of workload on the total database processing. Start with 100 and reach up to 100,000 concurrent requests for both databases.