Journal of Software Engineering and Applications, 2013, 6, 140-146
http://dx.doi.org/10.4236/jsea.2013.63018 Published Online March 2013 (http://www.scirp.org/journal/jsea)
Integrating Requirements with SLI Layer for Cloud
Computing Services to Meet SLA and QoS
Muhammad Irfan1, Zhu Hong1, Muhammad Irfan Sharif2, Ahmed Junaid Haq Qureshi3,
Rakhshanda Kanwal4, Muhammad Imran4
1Collage of Computer Science and Technology, Huazhong University of Science and Technology, Wuhan, China; 2Department of
Computer Science COMSATS Institute of Information Technology, Wah Cantt, Pakistan; 3Anwar Chowk, Wah Cantt, Pakistan;
4Courtenay Road, Woking, Surrey, England.
Received January 29th, 2013; revised February 27th, 2013; accepted March 9th, 2013
ABSTRACT
Cloud computing is high techno logy, which fulfills needs of common as well as enterprise level to meet their in forma-
tion and communication technology requirements and so on. Cloud computing extend s existing information techno logy
capabilities and requirements. Many technologies are being merged with cloud computing, same as that orchestrations
can boost cloud service provision ing process. The usage of orchestrations can play vital role to provision cloud services.
Cloud service providers can create scalable cloud services at low cost by organizing cloud infrastructure by using cloud
orchestrations. Dynamic orchestration flows can generate required cloud computing services to meet service level
agreements and quality of services. There is a need to und erstand issues and ba rriers involved to integrate cloud orches-
trations with cloud service provisioning process. There is also need to understand business related problems bordering
cloud computing techno logy. There is much capacity to do targeted research wo rk for cloud orchestrations and its in te-
gration with service level agree ments as well as with SLI (service level integration) layer. In this article we have elabo-
rated detailed analysis and identified a number of issues that will affect the cloud serv ice users as well as cloud service
providers and cloud service provisioning system. We are defining an approach to orchestrate cloud infrastructure by
using orchestration flows, to generate cloud services in order to meet service level agreements and quality of standard.
Keywords: Cloud Computing; Cloud Requirements; Cloud Service Provisioning; Service Level Agreements;
Quality of Service
1. Introduction
The development and civilization of global society, new
technologies are emerging by demand of needs to fulfill
requirements. Cloud computing is one of emerging tech-
nology merging all information and communication
technologies, other indirectly related technologies are
also linking with cloud computing. The cloud infrastruc-
ture is resource pool of cloud computing services; cloud
computing services can be delivered to cloud users any
time anywhere at scalable level. Cloud compu ting [1] is a
recent technology trend aiming to deliver on demand IT
resources on a pay per us e basis. Cloud comp uting intend
to provide global information technology services to
common users and enterprises to host their data and ser-
vices over internet. Enterprises can outsource their total
infrastructure any time anywhere to global data centers
of cloud computing service providers. Fox et al. [2] men-
tioned that, cloud computing refers to both the appli-
cations delivered as services over the internet and the
hardware and system software in the datacenters that
provide those services.
Main layers of cloud computing are: Software as a
Service (SaaS), Platform as a Service (PaaS), and Infra-
structure as a Service (IaaS). SaaS (Software as a Service)
are available at Salesforce.com [3] and Clarizen.com [4].
PaaS solutions and services are available at Google Ap-
pEngine [5], Microsoft Azure [6]. IaaS hardware and its
services can be approach at Amazon EC2 [7] and S3 [8],
and Mosso [9]. Cloud orchestrations integrated with ser-
vice level integration layer can provide cloud services at
scalable level on demand. Cloud orchestrate service solu-
tion provides physical or virtual resources that are app-
ropriate the requirements of the cloud user applications
in term of CPU, memory, operating system and storage.
Cloud orchestrations can enable cloud services to meet
QoS parameters are recognized through a Service Level
Agreement (SLA) between the cloud computing service
user and cloud computing service provider.
Cloud computing recourses are pooled to serve several

Integrating Requirements with SLI Layer for Cloud Computing Services to Meet SLA and QoS 141
clients using a multi-tenant model, with dissimilar phy-
sical and virtual resources animatedly assigned and reas-
signed according to cloud user demand. There is logic of
location independence in that the customer generally has
no control or knowledge over the exact location of the
recourse pool, provided resources. Cloud computing re-
course pool consists of storage, processing, memory,
network bandwidth, and virtual machines, known as Data
Center. Cloud computing service provider recourse pool
control and optimize resource use by leveraging a meter-
ing capability at some level of abstraction appropriate to
the type of service requested by cloud user, as per SLA
(Service Level Agreement). There service can be related
to storage, processing, bandwidth, security, hosting and
all kind of information technology services. Reserve us-
age can be monitored, controlled, and reported providing
clearness for both the cloud service provider and cloud
service user. Cloud computing services users do not have
information about, where their data is being processed or
stored, who is accessing their information, how their data
is protected, and what data has been accessed and why?
Privacy and security remain the top concerns when any
service is being provided over internet and remotely re-
sourced across the world. The migration of proprietary
and sensitive data over cloud across the world is con-
cerns for any enterprise or institutions beneficiary of
cloud computing services. Understanding security in an
IT environment requires transparency and control, trans-
parency proves “who has accessed systems and data,
when and where” while transparency can even pay off
lack of control that’s allowing monitoring to display that
unofficial activity is not going on. Cloud computing, in
its existing formation, requires clients to interest at con-
siderable level for transparency and control.
Cloud computing technology has main aim to provid-
ing businesses with an array of on demand computing
infrastructures and services through the internet [10].
Cloud computing therefore, promises businesses signifi-
cant cost savings in procuring “local” IT infrastructures
and hiring/training personnel to handle and maintain
them [11,12]. There are number of problems to meet
cloud computing service user requirements addressed in
[12,13]. Cloud engineering according to requirement for
cloud computing applications using Agile Service Net-
works (ASNs) [14]. There are number of requirements
for cloud computing applications, extracted from litera-
ture [11,12, 15 - 20].
In order to meet service level agreements cloud com-
puting platforms should be flexible to adjust to a variety
of requirements. These cloud computing platforms may
deliver the infrastructure as a service to cloud computing
users on demand. Therefore computing infrastructures of
hardware configuration, software installation and data
access demands should meet with requirements accord-
ing to service level agreements and quality of standard.
Different cloud based-applications have different orches-
tration flow and composition, configuration, and deploy-
ment requirements. The different cloud based-applica-
tions such as business applications, social networks, por-
tals and workflows work at the top layer of the cloud
computing architecture. Usability and time of these ap-
plications are not predictable, same as these applications
have different requirements and different service level
agreements. There are privacy and security requirements,
how could personal information be protected? To protect
and preserve privacy in internet based computing such as
web service, online storage [21].
2. Cloud Computing Orchestrations
The computing “Orchestration” describes the automated
arrangement, coordination, and management of complex
computer systems, middleware, and services. It is often
discussed as having an inherent intelligence or even im-
plicitly autonomic control, but those are largely aspira-
tions or analogies rather than technical descriptions. In
reality, orchestration is largely the effect of automation
or systems deploying elements of control theory [22].
ITU-T superficially concentrates on the cloud orchestra-
tion and broker, functional domain [23] described by FG
Cloud (Focus Group on Cloud) for cloud orchestration.
FG Cloud focused for policy driven automation of re-
source creation, allocation, tearing and operational opti-
mization.
Service broker is an organization that deals between
cloud service providers and cloud users, offering services
including integration, aggregation and customization
with inter cloud function [24] in cloud Ecosystem. This
functionality of service orchestratio n domain is expanded
to service brokers; they are one of component of the ser-
vices orchestration architecture. As much as universe is
progressing toward information an d commun icatio n tech-
nologies same as mobile devices, like Smartphone or
tablet, make cloud users more accessible to cloud ser-
vices, ratio is directly proportional. On the other hand,
standardization of cloud ecosystem and architecture that
completely support inter cloud operation and orchestra-
tion is still in its early stage. Same as mentioned in the
following Figure 1, as FG Cloud [23,24], showing high-
tech cloud architecture.
Cloud service orchestration is composing of architect-
ture, tools and processes by humans to deliver a defined
service stitching of software and hardware components
together to deliver a defined service connecting and
automating of work flows when applicable to deliver a
defined service. The main difference between a work-
flow automation and orchestration is that work flows are
processed and completed as processes within a single
domain [22].

Integrating Requirements with SLI Layer for Cloud Computing Services to Meet SLA and QoS
142
Figure 1. FG Cloud [23,24] high-tech cloud architecture.
3. Web Service Choreography and
Orchestrations in Cloud Computing 4. Cloud Service Level Agreements and QoS
Cloud service providers tries to produce maximum num-
ber of services by using less resource but still meeting
service level agreements and QoS standards.
Web Service Choreography is a specification by the
W3C defining a XML-based business process modeling
language that describes collaboration protocols of coop-
erating web service participants, in which services act as
peers, and interactions may be long-lived and state-full.
The main effort to get choreography, The W3C Web
Services Choreography Working Group, was closed on
the 10th July 2009 leaving WS-CDL as a candidate rec-
ommendation [25]. Service choreography is a form of
service composition in which interaction protocol be-
tween several partner services is defined from a global
perspective [26]. That is, at run-time each participant in
service choreography executes its part of its role accord-
ing to the behavior of the other participants [27]. Chore-
ography’s role specifies the expected messaging behavior
of the participants that will play it in terms of the se-
quencing and timing of the messages that they can con-
sume and produce [2 8].
SLA defines, limits and usages and responsibilities of
cloud service user and cloud service provider. SLA fur-
ther gives certainty, which cloud service provider will
comply with the rules about data storage; these rules are
local government jurisdiction under cloud computing
services. SLA also defines security requirements who
and what need to control, in case of any disaster, there
must be disaster recovery process defined in SLA and
cloud service provider and user both agreed on this spe-
cific SLA. SLA also gives terms and conditions for cloud
service provider in case if clod service is failed to keep
alive. Cloud service provider must be ISO 27001 certi-
fied, in order to meet SLA and QoS standards. In 2008
Hayes pin pointed that [29] “Allowing a third party ser-
vice to get custody of personal documents is awkward
question about control and ownership, if you acquire
cloud service can you take data with you? Could you lose
access to data if you failed to pay timely?” All these is-
sues create need and existence of service level agree-
ments and quality of standards. SLAs can resolve and
gives control over privacy and data security.
Orchestration is another term with a very similar, but
still different meaning as explained in above section,
orchestration is that work flows are processed and com-
pleted as processes among multiple domain [22], while
workflow process with in single domain.

Integrating Requirements with SLI Layer for Cloud Computing Services to Meet SLA and QoS 143
Cloud service provider should provide cloud comput-
ing service by signing Service Level Agreements (SLAs)
with customer. Cloud service user may have SLA with
cloud service provider defining in SLA about memory
usage and throughout in given time, CPU usage and how
much bandwidth user got. Provision ing of recourses must
meet SLAs, in case failed to meet SLA and QoS, cloud
service provider may have penalties. Same as if cloud
service user over use resource by crossing SLA, it would
give loss to cloud service provider. So SLA is bond and
agreement between cloud service provider and cloud
service user. Still there are barriers creating conflicts to
define and sign and meet SLA specifically to security
and privacy. Due to unpredictable customer demand,
power and software and hardware failure, conflicts are
raised that might affect cloud service quality and reliabil-
ity. Data ownership, data transfer, cloud service per-
formance, reliability, security and privacy are main is-
sues need to define clear roadmap to create trusted bond
between cloud computing service provider and cloud
service user. SLAs are the component empowering cloud
computing to bridge this bond. Cloud computing service
users demand high performance service that requires lot
of resource form cloud data center resource pool. Cloud
service provisioning in cloud based technology is totally
depending upon Service Level Agreements (SLAs). SLA
is contract between customer and cloud service provider
that defines requirements of services specified as quality
of service (QoS). SLA contains, functional and non func-
tional both kind of requirements as well as defining pric-
ing and service time line commitments, pricing and pen-
alties. Cloud service provider ensures to meet SLA, by
doing continuous monitoring of recourses and agreed
terms and conditions in SLA. There are some gaps in
monitoring technology, sometime monitoring is don’t at
higher level and lower level is ignored, resulting as
breaking agreements of SLA and QoS.
An SLA is a bilateral agreement, typically between a
service provider and a service consumer. These form a
natural choice for representing the agreed constraints for
individual jobs. While there are technologies for com-
posing SLA (Service Level Agreement) in XML-based
representations, e.g. WSLA [30], these embed domain-
specific terms; no terms for resource reservation have yet
been proposed within the Grid and cloud computing
community. In any case, it is certain that SLA (Service
Level Agreement) can be designed to include acceptable
terms and conditions and standards to deliver services.
For example one of SLA for any cloud computing ser-
vice, start and end time bounds and a simple description
of cloud resource and services requirements. SLA (Ser-
vice Level Agreement) is one instrument which can be
used to reserve resources in advance [31]. The time re-
quirements and dependencies can be modeled in the SLA
to guarantee the resource availability [32].
5. Cloud Service Stacks
Cloud computing architectures, covered following basic
levels of cloud stack as defined in [33] by L. Youseff, M.
Butrico and D. Da Silva Cloud computing systems fall
into one following layers as shown in Figure 2, (ap- pli-
cations, software environments, software infrastruc- ture,
software kernel, and hardware). At the bottom of the
cloud stack is the hardware layer which is the actual
physical components of the system. Some cloud com-
puting offerings have built th eir system on subleasing th e
hardware in this layer as a service.
At the top of the stack is the cloud application layer,
which is the interface of the cloud to the common com-
puter users through web browsers and thin computing
terminals.
Another cloud service stack is defined by R. W.
Anderson [34] as shown in Figure 3. Anderson includes
IaaS (Infrastructure as a Service) to provisioning of
hardware or virtual machines on which one generally has
control over the OS; therefore allowing the execution of
arbitrary software. This definition isn’t really enough,
because there are many other kinds of infrastructu re.
 Connectivity or messaging services. Examples: Mi-
crosoft BizTalk Labs and Connectivity Services,
Gnip.
 Identity services. Countless OpenID identity provid-
ers, again the BizTalk Labs Identity Services.
 Data storage. Examples: Amazon’s S3 and SimpleDB,
Microsoft SQL Server Data Services.
There is flexible machine provisioning like Amazon
EC2. These are definitely infrastructure, where the plat-
form is the OS, Web servers, and other software. Calling
this all IaaS is fine, it is all infrastructures but, maybe we
should further divide these:
 Virtual Hardware Infrastructure
 Storage I nfrastr u cture
 (Other) Infrastructure Services
Figure 2. Cloud computing ontology [33].

Integrating Requirements with SLI Layer for Cloud Computing Services to Meet SLA and QoS 144
Figure 3. Cloud service stack [34].
6. User Requirements for Cloud Computing
Roger Clarke defines user requirements for cloud com-
puting infrastructure [35] into main categories as listed
below:
6.1. Integrity Assurance
Cloud computing infrastructure (CCI) must exhibit fea-
tures that enable assurance of:
 Service integrity
 Data integrity
6.2. Compliance Assurance
CCI must exhibit features that enable users to comply
with legal requirements in all jurisdictions that they are
subject to, and to demonstrate that they are compliant.
This encompasses:
 Service security
 Service access controls
 Data transmission security
 Data storage security
 Data use (by the service-provider)
 Data disclosure (by the service-provider to others)
 Data storage jurisdictional location
6.3. Declaration and Measurement
CCI must exhibit features that en able the following to be
declared and measured:
 Levels of service reliability
 Protections for service survival
 Protections for data surv ival
 Service and data compatibility
 Service and data flexibility
6.4. Privacy Policy Enforcement
CCI must exhibit features that enable:
 Server privacy policies to be declared
 User privacy requirements to be declare
 Server privacy policies and user privacy requirements
to be compared
 Cloud usage to be precluded where the requirements
are not satisfied
7. Service Level Tasks for SLI Layer
There is need of such a bridge or interaction point as SLI
layer which can orchestrate service level tasks to provi-

Integrating Requirements with SLI Layer for Cloud Computing Services to Meet SLA and QoS 145
sion required cloud computing service. For example,
cloud user order for a server from cloud service provider,
SLA is signed between cloud service provider and cloud
service user. Cloud service provider needs to provision
requested server to meet SLA and QoS. Service level
layer is middle agent that mobilizes cloud computing in-
frastructure and initiate orchestration process, to provi-
sion and deploy server. Followings tasks as shown in
Table 1, interacting with SLI layer to generate required
service according to customer demand.
In Table 1 these service level tasks will be orches-
trated with SLI layer, and SLI layer will run these tasks
in such a way or flow provisioning required service
meeting SLA and QoS.
8. Key Value of SLI Layer
There is need of such a bridge or interaction point as SLI
layer, that is responsible for arbitrate and bridge between
cloud service user and cloud computing infrastructure.
More over lining of orchestrations of orchestration en-
gine can boost cloud service provision process. The SLI
layer orchestrates service tasks across cloud computing
infrastructure, to provision required cloud service ac-
cording to SLA and QoS. SLI layer interacts with cloud
computing recourse pool to deploy service meeting SLA
and QoS requirements such as response time. This speci-
fied designed SLI layer is unified central engine that is
derived by service level agreements and meeting quality
of standard.
9. Conclusion
We have elaborated service level task orchestrated with
Table 1. SLI task level table.
SLI task Service level integration task description
1 Retrieval of server order from customer
2 Collection of server parameters
3 Selection of server from recourse pool.
4 Allocation confirmation of hardware
5 Collection of list of attributes to assign
6 Start hardware assignment
7 Internet protocol allocation
8 Operation system selection
9 OS licensing
10 LAN assignment
11 Security rule configuration
12 Internal test of server
13 Delivered to related customer
SLI layer. Cloud stack engine will run these tasks in or-
der to provision r equired cloud service. Integration cloud
user requirements with service level tasks is associated
by middle level layer named as SLI layer, mobilizing
recourses from cloud recourse poo l. Finally, provisioning
required service, meets SLA and QoS, in order to deliv er
cloud service according to customer requirements. This
idea is useful to integrate requirements with SLI tasks
decreasing use of cloud service provider efforts and re-
courses, resulting increasing return on investment. Fur-
ther work is needed to do to investigate problems to im-
plement this idea, so researchers are invited to work on
our given idea by investing their mind on this useful
technology.
10. Acknowledgements
Thanks to researchers supported us to review piece of
work encouraging us to harvest our mind, resulting as
generation of service level integration with cloud user
requirements.
REFERENCES
[1] L. Vaquero, L. Rodero-Marino, J. Caceres and M. Lind-
ner, “A Break in the Clouds: Towards a Cloud Defini-
tion,” Computer Communication Review, Vol. 39, 2009,
pp. 137-150.
[2] M. Armbrust, A. Fox, R. Griffith, A. D. Joseph, R. Katz,
A. Konwinski, G. Lee, D. Patterson, A. Rabkin, I. Stoika
and M. Zaharia, “Above the Clouds: A Berkeley View of
Cloud Computing, Technical Report, UC Berkeley Reli-
able Adaptive Distributed Systems Laboratory,”
http://abovetheclouds.cs.berkeley.edu
[3] http://www.salesforce.com
[4] http://www.clarenz.com
[5] http://code.google.com/appengine/docs/whatisgoogleappe
ngine.html
[6] http://www.microsoft.com/azure/
[7] http://aws.amazon.com/ec2/
[8] http://aws.amazon.com/s3/
[9] http://www.mosso.com/
[10] D. Villegas, I. Rodero, L. Fong, N. Bobroff, Y. Liu, M.
Parashar and S. M. Sadjadi, “Handbook of Cloud Com-
puting,” Springer, Berlin, 2010.
[11] L. M. V. Gonzalez, L. Rodero-Merino, J. Caceres and M.
A. Lindner, “A Break in the Clouds: Towards a Cloud
Definition,” Computer Communication Review, Vol. 39,
No. 1, 2009, pp. 50-55.
[12] L. Bean, “Cloud Computing: Retro Revival or the New
Paradigm?” Journal of Corporate Accounting & Finance,
Vol. 21, No. 5, 2010, pp. 9-14. doi:10.1002/jcaf.20605
[13] G. Wang, “Cloud Computing,” In: G. Vossen, D. Long
and J. Yu, Eds., Web Information Systems Engineering,
Springer, Berlin, 2009.
[14] N. Carroll, E. Whelan and I. Richardson, “Applying So-

Integrating Requirements with SLI Layer for Cloud Computing Services to Meet SLA and QoS
146
cial Network Analysis to Discover Service Innovation
within Agile Service Networks,” Service Science, Vol. 2,
No. 4, 2010, pp. 225-244. doi:10.1287/serv.2.4.225
[15] N. Kshetri, “Cloud computing in Developing Econo-
mies,” IEEE Computer, Vol. 43, No. 10, 2010, pp. 47-55.
doi:10.1109/MC.2010.212
[16] H. C. Lim, S. Babu, J. S. Chase and S. S. Parekh, “Auto-
mated Control in Cloud Computing: Challenges and Op-
portunities,” Proceedings of the 1st Workshop on Auto-
mated Control for Datacenters and Clouds, New York,
2009, pp. 13-18. doi:10.1145/1555271.1555275
[17] M. Armbrust, A. Fox, R. Griffith, A. D. Joseph, R. H.
Katz, A. Konwinski, G. Lee, D. A. Patterson, A. Rabkin,
I. Stoica and M. Zaharia, “A View of Cloud Computing,”
Communications of the ACM, Vol. 53, No. 4, 2010, pp.
50-58. doi:10.1145/1721654.1721672
[18] B. Grobauer and T. Schreck, “Towards Incident Handling
in the Cloud: Challenges and Approaches,” Proceedings
of the ACM Workshop on Cloud Computing Security
Workshop, 2010, pp. 77-86.
[19] S. Tai, J. Nimis, A. Lenk and M. Klems, “Cloud Service
Engineering,” Proceedings of the 32nd ACM/IEEE Inter-
national Conference on Software Engineering, Vol. 2,
Cape Town, 2010, pp. 475-476.
doi:10.1145/1810295.1810437
[20] L. Gu and S.-C. Cheung, “Constructing and Testing Pri-
vacyaware Services in a Cloud Computing Environment:
Challenges and Opportunities,” Proceedings of the First
Asia-Pacific Symposium on Internetware, 2009, pp. 2:1-
2:10. doi:10.1145/1640206.1640208
[21] H. Meziane and S. Benbernou, “A Dynamic Privacy Mo-
del for Web Services,” Computer, Standards and Inter-
faces, Vol. 32, No. 5-6, 2010, pp. 288-304.
doi:10.1016/j.csi.2010.02.001
[22] T. Erl, “Service-Oriented Architecture: Concepts, Tech-
nology & Design,” Prentice Hall, Upper Saddle River,
2005.
[23] ITU-T Focus Group on Cloud Computing, “Cloud-Ref-
erence Architecture,” 2010.
[24] ITU-T Focus Group on Cloud Computing, “Cloud-Ref-
erence Architecture,” 2011.
[25] Web Services Choreography Working Group at W3.
[26] S-Cube Knowledge Model: Service Choreography.
[27] C. Peltz, “Web Services Orchestration and Choreogra-
phy,” IEEE Computer, Vol. 36, No. 10, 2003, pp. 46-52.
doi:10.1109/MC.2003.1236471
[28] Z. Y. Qiu, X. P. Zhao, C. Cai and H. L. Yang, “Towards
the Theoretical Foundation of Choreography,” World
Wide Web Conference (WWW), 2007, pp. 973-982.
[29] B. Hayes, “Cloud Computing,” Communications of the
ACM, Vol. 51, No. 7, 2008, pp. 9-11.
doi:10.1145/1364782.1364786
[30] H. Ludwig, A. Keller, A. Dan and R. King, “A Service
Level Agreement Language for Dynamic Electronic Ser-
vices,” Proceedings of the 4th IEEE International Work-
shop on Advanced Issues of E-Commerce and Web-Based
Information Systems, Los Alamitos, 2002, pp. 25-32.
[31] H. Ludwig, T. Nakata, O. W. Aldrich, P. H. Wieder and
W. Ziegler, “Reliable Orchestration of Resources Using
WS-Agreement,” Proceedings of International Confer-
ence on High Performance Computing and Communica-
tions, Berlin, 13-15 September 2006, pp. 753-762.
[32] J. MacLaren, R. Sakellariou, K. T. Krishnakumar, J.
Garibaldi and D. Ouelhadj, “Towards Service Level Ag-
reement Based Scheduling on the Grid,” Workshop on
Planning and Scheduling for Web and Grid Services,
2004.
[33] L. Youseff, M. Butrico and D. Da Silva, “Toward a Uni-
fied Ontology of Cloud Computing,” Proceedings of Grid
Computing Environments Workshop, Austin, 12-16 No-
vember 2008, pp. 1-10.
[34] R. W. Anderson, “The Cloud Services Stack-Infrastruc-
ture,” 2008.
http://rwandering.net/2008/07/28/the-cloud-services-stack
-infrastructure/
[35] R. Clarke, “User Requirements for Cloud Computing Ar-
chitecture,” 2009.
http://www.rogerclarke.com/II/CCSA-0911.html