Monext: An Accounting Framework For Federated Clouds

Monext: An Accounting Framework for
Federated Clouds
By
Francisco Airton Pereira da Silva

M.Sc. Dissertation
Universidade Federal de Pernambuco

posgraduacao@cin.ufpe.br
www.cin.ufpe.br/~posgraduacao
RECIFE, FEB/2013
Universidade Federal de Pernambuco

Centro de Informtica
Ps-graduao em Cincia da Computao
Francisco Airton Pereira da Silva

Federated Clouds
A M.Sc. Dissertation presented to the Centro de Informtica

of Universidade Federal de Pernambuco in partial fulfillment
of the requirements for the degree of Master of Science in
Computer Science.
Advisor: Vinicius Cardoso Garcia
RECIFE, FEB/2013
Catalogao na fonte
Bibliotecria Jane Souto Maior, CRB4-571
Silva, Francisco Airton Pereira da

Monext: an accounting framework for federated clouds. /
Francisco Airton Pereira da Silva. - Recife: O Autor, 2013.
xvi, 107 folhas: fig., tab.
Orientador: Vinicius Cardoso Garcia.
Dissertao (mestrado) - Universidade
Pernambuco. CIn, Cincia da Computao, 2013.
Federal
de
Inclui bibliografia, glossrio e apndice.

1. Cincia da computao. 2. Sistemas distribudos. 3.
Computao em nuvem. I. Garcia, Vinicius Cardoso (orientador).
II. Ttulo.
004
CDD (23. ed.)
MEI2013 051
Dissertao de Mestrado apresentada por Francisco Airton Pereira da Silva PsGraduao em Cincia da Computao do Centro de Informtica da Universidade Federal
de Pernambuco, sob o ttulo Monext: An Accounting Framework for Federated
Clouds orientada pelo Prof. Vinicius Cardoso Garcia e aprovada pela Banca
Examinadora formada pelos professores:
______________________________________________
Prof. Nelson Souto Rosa
Centro de Informtica / UFPE
______________________________________________
Prof. Francisco Vilar Brasileiro
Departamento de Sistemas e Computao / UFCG
_______________________________________________
Prof. Vinicius Cardoso Garcia
Centro de Informtica / UFPE
Visto e permitida a impresso.

Recife, 27 de fevereiro de 2013
___________________________________________________
Profa. Edna Natividade da Silva Barros
Coordenadora da Ps-Graduao em Cincia da Computao do
Centro de Informtica da Universidade Federal de Pernambuco.
I specially dedicate this dissertation with love and affection

to my mother Maria Jos who suffered for our distance
during all this time.
Acknowledgements
Firstly to God for every blessing, protection, love and strength throughout my life.
To my father Antnio, that has always prayed for me in every step of my life. I would
like to thank him for his reference of love, happiness and father.
To my mother for all support, love and friendship. I am profoundly grateful for her
wisdom in understanding the distance that separates us. Mother, know that even with the
distance we will always be together.
To my sweet girlfriend Patrcia, for all love, affection, support and friendship during
all these years of partnership, in special the two last ones, as well as by welcome and
friendly words in the most adverse moments.
To my friends from the "OsCinFuturo" group for all support and friendship: Lenin
Abadie, Marco Andr, Thiago Vieira, Paulo Fernando, Dhiego Abrantes, Rodolfo Arruda,
Adriano Tito, Hlio Rodrigues and Bruno Felipe. I will never forget the sound of "pxxiiii"
and the "qr naaada!!".
To my other friends Francisco Soares, Edigley Fraga, Sabrina Souto, Josino Rodrigues,
and in special Paulo Silveira who guided me throughout my research.
Last but not least, my sincere thanks to my advisor Vinicius Garcia for all guidance,
support and teachings.
...
iv
When you walk through a storm,

Hold your head up high,
And dont be afraid of the dark.
At the end of a storm,
Theres a golden sky,
And a sweet silver song of a lark
Walk On! Walk On! With hope in your heart,
And youll never walk alone....
RICHARD RODGERS (Youll Never Walk Alone)
Resumo
A Computao na Nuvem se tornou um paradigma consumado para executar servios em

infraestruturas externas, onde de uma forma virtual a capacidade praticamente ilimitada
pode ser alocada dinamicamente. Este paradigma estabelece um novo cenrio para a
implantao de aplicaes e servios de TI. Neste modelo, desde aplicaes completas
at infraestrutura de mquinas so ofertadas a usurios, que so cobrados apenas pelo
uso dos recursos consumidos. Desta forma, os bens de consumo da nuvem so ofertados
atravs de abstraes de servios, onde atualmente so citadas trs principais categorias:
Software como Servio (SaaS), Plataforma como Servio (PaaS) e Infraestrutura como
Servio (IaaS).
No caso do IaaS so oferecidos recursos computacionais na forma de Mquinas
Virtuais para o cliente final. Para atingir o aspecto ilimitado de recursos necessrio
distribuir estas Mquinas Virtuais por vrios Data Centers. Esta distribuio dificulta
atender uma srie de requisitos como Segurana, Confiabilidade, Disponibilidade e a
Tarifao pelos recursos consumidos. A Tarifao refere-se a como os recursos so
registrados, contabilizados e cobrados. Mesmo no caso de um nico provedor esta tarefa
no fcil e existe um contexto em que esta dificuldade se torna ainda maior, conhecida
como Federao de Computao na Nuvem ou tambm chamadas de Nuvens Federadas.
Nuvens Federadas ocorrem quando um provedor de Computao na Nuvem terceiriza
recursos dinamicamente para outros provedores em resposta variao da demanda.
Desta forma ocorre um aglomerado de nuvens, porm seus recursos so heterogneos,
acarretando num maior esforo para gerenciar os recursos distribudos e por consequncia para a Tarifao. Neste contexto foram identificadas pesquisas nesta rea sobre
plataformas para Nuvens Federadas, que no abordam o requisito de Tarifao.
Esta dissertao apresenta um framework voltado tarifao de Infraestrutura como
Servio com foco em Nuvens Federadas. Objetivando colher informaes sobre esta
rea e consequentemente gerar insumos para fundamentar as decises na construo do
framework, foi aplicado um Estudo de Mapeamento Sistemtico.
Esta dissertao tambm apresenta uma validao inicial da ferramenta, atravs de um
estudo experimental, mostrando indcios de que os requisitos gerados pelo Mapeamento
Sistemtico foram atendidos, bem como ser vivel a aplicao da soluo por provedores
de servios de nuvem em um cenrio real.
Palavras-chave: Computao na Nuvem, Infraestrutura como Servio, Tarifao, Contabilidade, Nuvens Federadas, Linguagem Especfica de Domnio
vi
Abstract
Cloud computing has become an established paradigm for running services on external
infrastructure that dynamically allocates virtually unlimited capacity. This paradigm
creates a new scenario for the deployment of applications and information technology
(IT) services. In this model, complete applications and machine infrastructure are offered
to users, who are charged only for the resources they consume. Thus, cloud resources are
offered through service abstractions classified into three main categories: Software as a
Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS).
In IaaS, computing resources are offered as virtual machines to the end user. The aim
to offer such unlimited resources necessitates distributing these virtual machines through
multiple data centers. This distribution makes harder to fulfill a number of requirements
including security, reliability, availability, and accounting. Accounting refers to how
resources are recorded, accounted for, and charged. Even for a single cloud provider
this task is hard, and it becomes more difficult for a federation of cloud computing, or
federated cloud, in which a cloud provider dynamically outsources resources to other
providers in response to demand variation. Thus, a cluster of clouds shares heterogeneous
resources, requiring greater effort to manage and accurately account for the distributed
resources.
Some earlier research has addressed the development of platforms for federated
clouds but without considering the accounting requirement. This dissertation presents
a framework for charging IaaS with a focus on federated cloud. In order to gather
information about this topic area and to generate guidelines for building the framework,
we applied a systematic mapping study. This dissertation also presents an initial validation
of the tool through a case study, showing evidence that the requirements generated
through the mapping study were fulfilled by the framework and presenting indications of
its feasibility in a real cloud service scenario.
Keywords: Cloud Computing, Infrastructure as a Service, Accounting, Billing, Federated Clouds, Domain Specific Language
vii
Contents
List of Figures
ix
List of Tables
List of Acronyms
xi
1
3
4
5
5
6
Introduction
1.1 Motivation . . . . . . . . . . . .
1.2 Problem Statement . . . . . . .
1.3 Out of Scope . . . . . . . . . .
1.4 Statements of the Contributions .
1.5 Dissertation Structure . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Systematic Mapping Study on Cloud Accounting

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Literature Review Method . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Definition of Research Questions . . . . . . . . . . . . . . . .
2.2.2 Conduct Search . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.3 Screening of Papers . . . . . . . . . . . . . . . . . . . . . . . .
2.2.4 Keywording . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.5 Data Extraction . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Mapping Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1 RQ1 - Is there any taxonomy for concepts related to accounting
process in cloud computing? . . . . . . . . . . . . . . . . . . .
2.3.2 RQ2 - What are the existing accounting models for cloud computing? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.3 RQ3 - What are the existing pricing schemes for cloud or grid
computing? . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.4 RQ4 - What are the aspects taken into account to compose a SLA
in cloud/grid computing scenario? . . . . . . . . . . . . . . . .
2.4 Results Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.1 Research Type Classification . . . . . . . . . . . . . . . . . . .
2.4.2 Contribution Type Classification . . . . . . . . . . . . . . . . .
2.4.3 Research Types vs. Research Questions . . . . . . . . . . . . .
7
7
9
10
11
12
15
16
16
17
18
24
28
34
34
35
36
viii
2.5
2.6
2.7
3
2.4.4 Accounting Models Classification

Threats to Validity . . . . . . . . . . . . .
Discussion . . . . . . . . . . . . . . . . .
Chapter Summary . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Monext: An Accounting Framework for Federated Clouds

3.1 Architecture Description . . . . . . . . . . . . . . . . .
3.1.1 Glossary . . . . . . . . . . . . . . . . . . . . .
3.1.2 Use Case View . . . . . . . . . . . . . . . . . .
3.1.3 Logical View . . . . . . . . . . . . . . . . . . .
jit_collector_agent . . . . . . . . . . . . . . . .
accounting_manager . . . . . . . . . . . . . . .
pricing_manager . . . . . . . . . . . . . . . . .
charging_manager . . . . . . . . . . . . . . . .
billing_manager . . . . . . . . . . . . . . . . .
financial_clearing_manager . . . . . . . . . . .
user_manager . . . . . . . . . . . . . . . . . . .
3.1.4 Development View . . . . . . . . . . . . . . . .
3.1.5 Process View . . . . . . . . . . . . . . . . . . .
JiTCollectorAgent . . . . . . . . . . . . . . . .
JiTProcessingService . . . . . . . . . . . . . . .
3.1.6 Physical View . . . . . . . . . . . . . . . . . . .
3.2 VeloZ . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Chapter Conclusion . . . . . . . . . . . . . . . . . . . .
A Preliminary Case Study
4.1 Definition . . . . . . . . . . . . . . . . . .
4.1.1 Goal . . . . . . . . . . . . . . . . .
4.1.2 Questions . . . . . . . . . . . . . .
4.2 Planning . . . . . . . . . . . . . . . . . . .
4.2.1 Context Selection: JiTCloud Project
JiTCloud and Monext Integration .
4.2.2 Evaluation Design . . . . . . . . .
4.3 Operation . . . . . . . . . . . . . . . . . .
4.3.1 Preparation . . . . . . . . . . . . .
4.3.2 Execution . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
37
39
40
44
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
46
47
48
49
52
54
55
56
56
57
58
58
59
62
62
64
67
69
74
.
.
.
.
.
.
.
.
.
.
75
75
75
76
76
76
78
79
81
82
83
ix
4.4
4.5
5
4.3.3 Data Validation . . . . . . .

Interpretation . . . . . . . . . . . .
4.4.1 Analysis for Each Question
Question 1 . . . . . . . . .
Question 2 . . . . . . . . .
Question 3 and Question 4 .
Question 5 . . . . . . . . .
4.4.2 Discussion . . . . . . . . .
4.4.3 Threats to Validity . . . . .
Chapter Summary . . . . . . . . . .
Conclusion
5.1 Research Contributions
5.2 Future Work . . . . . .
5.3 Academic Contribution
5.4 Concluding Remarks .
Bibliography
Appendices
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
83
83
84
84
84
86
86
88
90
91
.
.
.
.
92
92
93
94
94
95
105
A Deploy Instructions
106
A.1 JiTProcessingService Deploy . . . . . . . . . . . . . . . . . . . . . . . 106
A.2 JiTCollectorAgent Deploy . . . . . . . . . . . . . . . . . . . . . . . . 107
List of Figures
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
3.17
3.18
3.19
Systematic Mapping Process Petersen et al. (2008) . . . . . . . . . . .

N. of Papers X Search Engines. . . . . . . . . . . . . . . . . . . . . . .
Filters of the screening process. . . . . . . . . . . . . . . . . . . . . . .
Accounting Process (Ruiz-Agundez et al., 2010b) . . . . . . . . . . . .
IPDR reference model (Ruiz-Agundez et al., 2011) . . . . . . . . . . .
Architecture in Layers for Accounting and Billing within the RESERVOIR Service Manager. (Elmroth et al., 2009) . . . . . . . . . . . . . .
Overall architecture and process flow of THEMIS . . . . . . . . . . . .
Monitoring data flow (Lindner et al., 2011) . . . . . . . . . . . . . . .
Research type vs. Research questions . . . . . . . . . . . . . . . . . .
10
12
13
18
19
Monext Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . .
Monext General View . . . . . . . . . . . . . . . . . . . . . . . . . . .
The 4+1" view model . . . . . . . . . . . . . . . . . . . . . . . . . .
Monext Use Case View . . . . . . . . . . . . . . . . . . . . . . . . . .
Use Cases: Manage Information of Domain Entities and Manage Customer Information in an expanded way. . . . . . . . . . . . . . . . . .
Monext General Architecture . . . . . . . . . . . . . . . . . . . . . . .
Monext Package Structure . . . . . . . . . . . . . . . . . . . . . . . .
jit_collector_agent package . . . . . . . . . . . . . . . . . . . . . . . .
accounting_manager package . . . . . . . . . . . . . . . . . . . . . . .
pricing_manager package . . . . . . . . . . . . . . . . . . . . . . . . .
charging_manager package . . . . . . . . . . . . . . . . . . . . . . . .
billing_manager package . . . . . . . . . . . . . . . . . . . . . . . . .
financial_clearing_manager package . . . . . . . . . . . . . . . . . . .
user_manager package . . . . . . . . . . . . . . . . . . . . . . . . . .
(a) Accounting Process (Ruiz-Agundez et al., 2010b); (b) RESERVOIR
layered architecture (presented in Section 2.3.2); (c) Monext in Layers,
combining the Ruiz Agundezs accounting process and the RESERVOIR
layered architecture idea. . . . . . . . . . . . . . . . . . . . . . . . . .
RabbitMQ Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .
Monext and RabbitMQ . . . . . . . . . . . . . . . . . . . . . . . . . .
Monext Accounting Process . . . . . . . . . . . . . . . . . . . . . . .
Monext - Homepage . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
47
48
50
20
23
24
36
51
53
54
55
55
56
57
57
58
59
61
64
64
65
67
xi
3.20
3.21
3.22
3.23
Monext - Charging Policy Specification Page . . . . . . . . . . . . . .

Monext Deployment View . . . . . . . . . . . . . . . . . . . . . . . .
VeloZ Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Amazon AWS - On Demand Instance Types Pricing (Amazon-AWS, 2012)
67
68
71
73
4.1
4.2
4.3
4.4
4.5
4.6
4.7
Composition of a JiT Cloud (Costa et al., 2010) . . .

JiTCloud Deployment View . . . . . . . . . . . . .
Experimental Environment . . . . . . . . . . . . . .
Charging Policy A Explanation . . . . . . . . . . . .
SLA Example . . . . . . . . . . . . . . . . . . . . .
Usage Time vs. Number of Collected Usage Records
Monext Possible Configuration . . . . . . . . . . . .
77
78
80
81
83
85
85
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
xii
List of Tables
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
Search String . . . . . . . . . . . . . . . . . . . . . . . . . . .
Primary Studies . . . . . . . . . . . . . . . . . . . . . . . . . .
Research Type Facet (Wieringa et al., 2005) . . . . . . . . . . .
Taxonomy of Accounting Process (Ruiz-Agundez et al., 2010b)
Pricing Schemes . . . . . . . . . . . . . . . . . . . . . . . . . .
SLA metrics for IaaS (Alhamad et al., 2010) . . . . . . . . . . .
SLA metrics for PasS (Alhamad et al., 2010) . . . . . . . . . .
SLA metrics for SaaS (Alhamad et al., 2010) . . . . . . . . . .
SLA metrics for Storage as a service (Alhamad et al., 2010) . .
Research Type Classification . . . . . . . . . . . . . . . . . . .
Contribution Type Classification . . . . . . . . . . . . . . . . .
Accounting Models Classification . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
12
14
16
17
26
30
31
31
32
34
35
37
3.1
3.2
3.3
3.4
3.5
General Use Cases Description . . . . . . . . . . . . . . . . .

Specific Use Cases Description . . . . . . . . . . . . . . . . .
Taxonomy of Accounting Process Ruiz-Agundez et al. (2010c)
Default Charging Variables . . . . . . . . . . . . . . . . . . .
Charging Policy Examples . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
50
51
60
72
73
4.1
4.2
4.3
4.4
4.5
Monext Configuration Properties

Evaluated Charging Policies . .
Results from Treatment 2 (T2) .
Generated Fake" Anomalies . .
Results from Treatment 3 (T3) .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
79
81
87
87
88
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
xiii
List of Acronyms
ABC Accounting, Billing, and Compensation

ADB Accounting Database
AMQP Advanced Message Queuing Protocol
API Application Programming Interface
ARPANET Advanced Research Projects Agency Network
AWS Amazon Web Services
BNF Backus-Naur Form
bps bits per second
CCP Current Charging Policy
CNA Cloud Notary Authority
CoE Cost of Execution
CoH Cost of Hosting
CoO Cost of Outsourcing
CR Charging Record
CSP Cloud Service Provider
DSL Domain Specific Language
EC2 Amazon Elastic Compute Cloud
EQ Equality Level
GQM Goal Question Metric
HTTP Hypertext Transfer Protocol
IaaS Infrastructure as a Service
IPDR Internet Protocol Detail Record
xiv
JiT DC Just in Time Data Center

JiT Just in Time
JiTCA Just in Time Cloud Accounting
JiTCA-CPL Just in Time Cloud Accounting - Charging Policy Language
KPI Key Performance Indicator
MV RT Minimum Violating Response Time
MS Mapping Study
NIST National Institute of Standards and Technology
PaaS Platform as a Service
Pen Penalty
Prc Price
POSIX Portable Operating System Interface
PS Primary Study
QoS Quality of Service
REQ Requirement
Revenue Rvn
RQ Research Question
RTP Real-Time Pricing
S3 Amazon Simple Storage Service
SaaS Software as a Service
SC Scenarios
SCA Service Configuration Analyzer
SSF SLA Satisfaction Function
xv
SLA Service Level Agreement

SLM Service Life-cycle Manager
SMAM SM Accounting Manager
SOA Service Oriented Architecture
SUR Summary Usage Record
UFPE Federal University of Pernambuco
VAM VEEM Accounting Manager
VEEM Virtual Execution Environment Manager
VMT Virtual Machine Type
VoIP Voice over Internet Protocol
Wi-Fi Wireless Fidelity
XML eXtensible Markup Language
xvi
1
Introduction
When you affirm big, believe big and pray big, putting faith into action,
big things happen.
NORMAN VINCENT PEALE (1898-1993)
In 1969, Leonard Kleinrock (Kleinrock, 2005), one of the chief scientists of the
original Advanced Research Projects Agency Network (ARPANET) project which seeded
the Internet, said As of now, computer networks are still in their infancy, but as they grow
up and become sophisticated, we will probably see the spread of computer utilities which,
like present electric and telephone utilities, will service individual homes and offices
across the country." This vision of computing utilities based on a service provisioning
model anticipated the massive transformation of the entire computing industry in the
21st century whereby computing services will be readily available on demand, like other
utility services available in todays society.
Similarly, computing service users (consumers) need to pay providers only when they
access computing services. In addition, consumers no longer need to invest heavily or
encounter difficulties in building and maintaining complex IT infrastructure. In such a
model, users access services based on their requirements without regard to where the
services are hosted. This model has been referred to as utility computing, or recently as
Cloud Computing (Buyya et al., 2009a; Weiss, 2007).
The Information Technology Laboratory at the National Institute of Standards and
Technology (NIST) has posted a working definition of cloud computing: Cloud Computing is a model for enabling convenient, on-demand network access to a shared pool
of configurable computing resources (e.g., networks, servers, storage, applications, and
services) that can be rapidly provisioned and released" (Liu et al., 2012). It achieves
the goals of saving hardware cost and energy by reducing idle cycles in the computing
hardware, which is in turn achieved by packing computing tasks to fill up the capacity of
the underlying hardware. In this context, the NIST also defines three types of delivery
models for cloud computing: Software as a Service (SaaS), Platform as a Service (PaaS)
and Infrastructure as a Service (IaaS).
In the Software as a Service (SaaS) the consumer uses an application, but does not
control the operating system, hardware or network infrastructure on which its running.
With SaaS, clients subscribe to applications offered by providers rather than building or
buying them. Developers can also enrich their applications by integrating SaaS services
into them. Examples of SaaS solutions include Google Apps1 and Salesforce2 .
When the consumer uses a hosting environment for their applications it is called
Platform as a Service (PaaS). The consumer controls the applications that run in the
environment (and possibly has some control over the hosting environment), but does
not control the operating system, hardware or network infrastructure on which they are
running. The platform is typically an application framework which supplies users with
development and administration platforms. Examples of PaaS platforms include Google
App Engine3 and Windows Azure4 .
With Infrastructure as a Service (IaaS) the consumer uses "fundamental computing
resources" such as processing power, storage, networking components or middleware.
The consumer can control the operating system, storage, deployed applications and
possibly networking components such as firewalls and load balancers, but not the cloud
infrastructure beneath them. It represents the base of the pyramid without which the whole
architecture cannot exist. Examples of IaaS providers include Amazon5 , Rackspace6 , and
GoGrid7 .
The cloud computing paradigm is gaining a lot of popularity throughout the research
community and all these three delivery models. It is influencing the development of
Information Technology and changing the way that vendors, providers and end-users
view computation. As a matter of fact, cloud computing makes software available as a
service over the Internet and has changed the way in which hardware is designed and
purchased.
1 http://www.google.com/intl/en/enterprise/apps
2 http://www.salesforce.com
3 http://appengine.google.com/
4 http://www.windowsazure.com
5 http://aws.amazon.com
6 http://www.rackspace.com/
7 http://www.gogrid.com/
1.1. MOTIVATION
Amazon started to sell cloud computing services in 2006, giving birth to the Amazon
Web Services (AWS). AWS allowed individuals and enterprises to utilize Amazons network architecture and software expertise to quickly and easily host their own applications
and services on Amazons hardware. Quickly, many prominent information technology
(IT) companies followed suit. Some immediately differentiated themselves as high-level
niche services, while others developed similar, low-level network clouds. Simultaneously,
scientific research started to investigate the subject called cloud accounting.
Accounting is the art of recording, classifying, and summarizing in a significant
manner and in terms of money, transactions and events which are, in part at least, of
financial character, and interpreting the results thereof " (Wahla, 1941). This general
activity is important for business and commercial purposes, and in recent years, it has
been applied to cloud computing scenario. A cloud provider charges a customer a fee for
the usage of a certain service. The fee can be based on hardware, storage, or network, for
instance, and is provided as a utility service, similar to electricity (Brynjolfsson et al.,
2010). This dissertation focuses on the issues surrounding cloud accounting.
The remainder of this chapter describes the content and organization of this dissertation. Section 1.1 presents the motivations for the work, Section 1.2 states the problem,
and Section 1.3 reviews related topics not directly addressed by this work. Section 1.4
gives an overview of the contributions of this research, and finally, Section 1.5 describes
how this dissertation is organized.
1.1
Motivation
Cloud services are usually sold on demand through a pay-as-you-go model: The customer
only pays for what is used and no more (Narayan et al., 2012). However, behind this
general structure, various other factors influence the final price. The cloud accounting field
encompasses many lines of research, such as service level agreement (SLA) monitoring
(Alhamad et al., 2010), economic models (Ben-Yehuda et al., 2012; Ernemann et al.,
2002), or accounting tools (Park et al., 2012; Pandey et al., 2009).
A few recent studies have addressed accounting in federated cloud scenarios (Buyya
et al., 2010; RESERVOIR, 2012). A federated cloud allows a provider to dynamically
outsource resources to other providers in response to demand variations. This complex
mechanism increases the capacity of a group of data centers. They partner with each
other because no single cloud provider has the necessary infrastructure. They may prefer
to construct a federated cloud infrastructure mixing multiple public and private clouds to
provide better support. This requirement often arises in enterprises with global operations
1.2. PROBLEM STATEMENT
and applications such as Internet service, media hosting, and Web 2.0 applications. Thus,
there is a need for building technologies and algorithms for federated clouds. Such
evolution aims at provisioning services across different cloud providers, considering in
particular, among others, the accounting requirement.
According to Celesti et al. (2010), the federated cloud area is considered a trend for
the future of the Internet. He called this change the Horizontal Federation Stage":
The near future evolution of the cloud computing can be hypothesized in
three subsequent stages: Stage 1 Monolithic", cloud services are based
on independent proprietary architectures; Stage 2 Vertical Supply Chain",
cloud providers will leverage cloud services from other providers; Stage
3 Horizontal Federation", smaller, medium, and large cloud providers will
federate themselves to gain economies of scale and an enlargement of their
capabilities.
Today, similarities can be seen between Celestis forecast and real-life commercial
solutions such as ComputeNext8 , ScaleUp9 and RightScale10 which aggregate different
providers. This development encouraged us to study this subject more in depth, and
we identified four federated cloud platforms (Kertesz et al., 2012; Celesti et al., 2010;
Distefano et al., 2011; Costa et al., 2010) which do not address the accounting requirement; that is, they do not have a proper accounting system to charge for their provisioned
resources.
1.2
Problem Statement
The problem statement of this dissertation is formulated as:

There are some federated cloud platforms that does not provide
accounting services. This work proposes an accounting framework to
charge computing resources from federated cloud platforms.
In order to achieve this goal, a systematic mapping study (Chapter 2) was conducted
to collect information needed to guide the framework construction. A systematic mapping
study provides an overview of a research area and identifies the quantity and type of
research and results available within it (Petersen et al., 2008). In Chapter 4, we validated
8 http://www.computenext.com/
9 http://www.scaleupCloud.com/scaleup-solutions/federated-Cloud/
10 http://www.rightscale.com/
1.3. OUT OF SCOPE
the framework with a real federated cloud platform developed by a consortium of Brazilian
Universities.
1.3
Out of Scope
Some subjects were excluded from the scope of this project.

SaaS and PaaS - SaaS and PaaS are not covered in this dissertation, although
the mapping study provides evidence for charging metrics for any type of cloud
service. We identified and focused on the need for an accounting solution for cloud
computing in federated cloud platforms which address only IaaS.
Resource Cost Management - Samimi and Patel (2011) state that advanced strategies regarding pricing and cost tariff specification optimizes return on investment.
Cloud computing faces several major challenges in this area, including electrical
power and human resources mensuration. However, the framework proposed by
this work does not calculate or recommend a price to be applied for purchased
resources, because the entire infrastructure must be well known first.
Security - Some factors related to security were not covered by the framework,
such as cryptography and secure data transfer of usage records (consumption
of information by the customer) due to the high level of access and processing.
Similarly, we needed real-time monitoring of consumption and bureaucracy in data
transfer, which would require lowering the speed of that activity.
Anomaly Detector Mechanism - An anomaly is the occurrence of something
unexpected, different than specified in the SLA. The research does include the
functionality of compensations due to SLA violations, such as problems or delays
to access to resources. However, the mechanism which captures such anomalies
was developed by a group of researchers from the JiTCloud project (Costa et al.,
2010).
1.4
Statements of the Contributions
The research presented in this dissertation makes the following contributions:

A mapping study of state-of-the-art on cloud accounting that provides better understanding of the main trends, gaps, and challenges in this area;
1.5. DISSERTATION STRUCTURE
An accounting framework for federated cloud; and

The definition, planning, operation and interpretation of an experimental study in
order to evaluate the proposed solution.
1.5
Dissertation Structure
The remainder of this dissertation is organized as follows: Chapter 2 presents a mapping

study in order to investigate the state-of-the-art of accounting models for cloud computing, synthesize available evidence to suggest important implications for practice, as well
as identifying research trends, open issues, and areas for improvement; Chapter 3 describes the proposed framework, including its architecture details and a Domain Specific
Language for charging policy specification; Chapter 4 presents the Experimental Study
performed under the JiTCloud platform; and Chapter 5 provides a set of conclusions
discussing our contributions and outline directions for future work.
2
Systematic Mapping Study on Cloud
Accounting
Would you like me to give you a formula for success? Its quite simple,
really. Double your rate of failure.
THOMAS J. WATSON (1874-1956)
Cloud services change the economics of computing by enabling users to pay only
for the capacity that they actually use. In this context, cloud providers have their own
accounting models including their specific billing mechanisms. Thus, it is important to
study this heterogeneity aiming to map out the existing cloud accounting solutions to
become possible new proposals.
This Chapter presents a systematic mapping study. It conducted four research questions, evidencing 580 studies. It applied a formal investigation analysis which highlighted
23 papers. Such research focused on three inherent issues to cloud accounting: accounting
models, pricing schemes and SLA structure. The mapping results can help to understand the cloud accounting constraints by identifying points that still require additional
investigation, since important aspects regarding particular issues have not been addressed
yet.
2.1
Introduction
Cloud computing has become an established paradigm for running services on external
infrastructure, where virtually unlimited capacity can be dynamically allocated. However
this unlimited aspect may become expensive, and research projects have tried to mitigate
2.1. INTRODUCTION
it through the development of new architectures, exploring different accounting models

(Ruiz-Agundez et al., 2011; Elmroth et al., 2009; Pandey et al., 2009; Park et al., 2012).
Accounting in cloud computing is a recent discipline, hence there have been a few
attempts to find a model which considers all the accounting requirements, and no work
has tried to address a mapping of the existing accounting models to identify research gaps
and encourage future proposals presenting, for example, a standardized taxonomy.
In this context, this chapter presents a systematic mapping study (Petersen et al.,
2008) conducted from August to December in 2011. It studied the cloud accounting field,
synthesizing evidence to suggest important implications for practice, as well as identifying
research trends, open issues, and areas for improvement. It addressed accounting models
for cloud computing and other aspects related also to grid computing.
A Mapping Study, according to Petersen et al. (2008) is an evidence-based approach
to provide an overview of a research area, and identify research details available within it.
The results are gained from a defined approach to find, assess and aggregate the outcomes
from relevant studies. Thus, it provides a balanced and objective summary of the relevant
evidence. Hence, the goal of this investigation is to identify, evaluate, and synthesize
state-of-the-art on the cloud accounting area to present what has been achieved so far.
We considered in our studies the grid computing research field, mainly due to three
considerations. The first point is the correlated aspects between cloud and grid computing.
The second point is the older grid origin with probable relevant contributions. As final
reason, the existing mature accounting models under this research area.
In Gohner (2006), the authors perform a comparison between the six most known
accounting systems in grid computing. They evidenced advantages and disadvantages
whereas allowing to realise what aspects the grid accounting systems have in common.
First, they use a proper taxonomy to describe their functions which make part of an
accounting process (a set of operations that manages the data regarding the use of
the resources (Ruiz-Agundez et al., 2010b)). Next, they present a measurement unit
mechanism to apply under the resource consumption and accordingly charge for it,
called pricing scheme (Caracas and Altmann, 2007). Finally, all of them worry about
QoS Requirements and explore how to monitor this Quality of Service. In some cases
establishing SLA.
Based on Gohner (2006) considerations and a previous literature investigation, four
research questions were derived to guide this Mapping Study, as follows:
RQ1: Is there any taxonomy for concepts related to accounting process in cloud
computing?
2.2. LITERATURE REVIEW METHOD
RQ2: What are the existing accounting models for cloud computing?
RQ3: What are the existing pricing schemes for cloud or grid computing?
RQ4: What are the aspects taken into account to compose a SLA in cloud/grid
computing scenario?
The remainder of this chapter is structured as follows: Section 2.2 presents the
systematic mapping study process; Section 2.3 describes the main findings of the study;
Section 2.4 presents the analysis of the results, studies classification and mapping; Section
2.5 introduces some threats to validity; Section 2.6 discusses the results; Finally, Section
2.7 presents a summary of the chapter.
2.2
Literature Review Method
While a Systematic Review is a mean of identifying, evaluating and interpreting all

available research relevant to a particular question (Kitchenham and Charters, 2007), a
MS intends to map out the research undertaken (Budgen et al., 2008; Petersen et al.,
2008). A well organized set of good practices and procedures for undertaking MS is
defined in Budgen et al. (2008); Petersen et al. (2008). It establishes the base for this MS.
The importance and use of MS in the computer science area is observed in several studies
(Afzal et al., 2008; Bailey et al., 2007; Budgen et al., 2008; Condori-Fernandez et al.,
2009; Kitchenham, 2010; Petersen et al., 2008; Pretorius and Budgen, 2008), showing
the relevance and potential of the method.
A MS comprises the analysis of primary studies that investigate aspects related to
predefined research questions. It aims at integrating and synthesizing evidence to support
or refute particular research hypotheses. The main reasons to perform a MS can be stated
as follows, as defined by (Budgen et al., 2008):
To make an unbiased assessment of as many studies as possible, identifying existing
gaps in current research and contributing to the research community with the
reliable synthesis of the data;
To provide a systematic procedure for identifying the nature and extent of the
empirical study data that is available to answer research questions;
To map out the research that has been undertaken;
To help to plan new research, avoiding unnecessary duplication of effort and error;
and
To identify gaps and clusters in a set of primary studies (relevant papers/journals)
and identify topics to perform more complete systematic reviews.
The study follows the Systematic Mapping Process proposed by Kitchenham et al.
(2009) and later used by Petersen et al. (2008). The essential process depicted in Figure
2.1 is composed of five steps with specific outcomes and each phase is discussed in the
next sections (Definition of Research Questions, Conducting Search, Screening of Papers,
Keywording and Data Extraction).
Figure 2.1 Systematic Mapping Process Petersen et al. (2008)
2.2.1
Definition of Research Questions
As previously stated, the objective of this study is to understand, characterize and summarize evidences, identifying issues regarding cloud accounting field aiming to substantiate
our project decisions. Thus, four research questions were derived from the objective of
the study. The research questions, and the rationale for their inclusion, are detailed below.
RQ1: Is there any taxonomy for concepts related to accounting process in
cloud computing?
According to Ruiz-Agundez et al. (2010b) some authors refer to the terms pricing,
charging, or billing to represent the complete process of detecting the specific
usage of a service. The accounting process have to be disambiguated, employing a
precise terminology and splitting all the functions involved. The objective of this
question is to identify a formal taxonomy to underpin our proposal.
RQ2: What are the existing accounting models for cloud computing?
Accounting Models are solutions composed by an entire infrastructure which
consider both, engineering and economic aspects. It is essential to dimension
10
the provider infrastructure, make statistical analysis of the usages, among other
activities (Ernemann et al., 2002). The aim of this research question is to elucidate
the existing accounting models on cloud computing, and this way looking for
different architecture proposals.
RQ3: What are the existing pricing schemes for cloud or grid computing?
Pricing is the process of computing the exchange value of resources relative to a
common form of currency (Mihailescu and Teo, 2010a). Pricing schemes represent
the business interface between the provider and the customer. They are used to
achieve different objectives such as maximizing profit, maximizing social welfare,
or defining certain schemes of fairness. A pricing scheme presents the unit of
trade in a specified time period with a certain quality of service for a class of users
(Caracas and Altmann, 2007). The purpose of this question is to know which
pricing schemes exist since every accounting model must implement it somehow.
RQ4: What are the aspects taken into account to compose a SLA in cloud/grid
computing scenario?
Cloud providers supply clients with services and must meet their constraints.
They both need to negotiate the clients request and the providers infrastructure
capabilities agreeing to certain conditions. This agreement is known as Service
Level Agreement (SLA), and it is what the provider conforms to deliver the client
with what he needs (Lindner et al., 2011). According to Sahai et al. (2001), SLA
formalization is a challenged task mainly in terms of precision. In addition it was
observed a wide adoption of SLA in grid computing area. Therefore, this question
aims to identify what items compound a SLA in this context.
2.2.2
Conduct Search
The primary studies are identified by using search strings on scientific databases or
browsing manually through relevant conference proceedings or journal publications. The
strategy used to construct the search terms follows the same approach used in Kitchenham
et al. (2007), since it is systematized in essence and defines steps to derive the search
strings from the questions and the viewpoints of experts in the area and relevant papers.
The strategy steps are described as follows:
Derive major terms from the questions;
11
Identify, by inquiries with experts in the field and/or subject librarians, alternative
spellings and synonyms for major terms; and
Check the keywords in the relevant paper texts identified by the authors.
The complete list of search strings and their combination are presented in Table 2.1.
Table 2.1 Search String
SLA OR Service Level Agreement OR billing OR
pricing OR payment OR accounting AND cloud
computing OR grid computing OR Infrastructure as a Service OR Platform as a Service OR
Software as a Service
Firstly, an automatic search was conducted in different search engines (IEEEXplore,

ACM Digital Library, Scopus and ScienceDirect digital databases). It is important to be
mentioned that all search strings were calibrated regarding to each search engine. Next, a
manual search was performed by visiting two high classified periodic journals according
to the Brazilian institution CAPES1 (Coordination for the Improvement of Higher Level
Personnel): Journal Concurrency and Computation; and Journal of Supercomputing. As
a result from the application of both search strategies 580 studies were collected. The
result is shown in Figure 2.2.
Figure 2.2 N. of Papers X Search Engines.
2.2.3
Screening of Papers
As the first conducted search includes repeated and low relevant work, filters are necessary
since only unique and relevant primary studies must be included. At this point, the studies
were considered according to Inclusion and Exclusion Criteria.
1 http://www.capes.gov.br/avaliacao/qualis
12
The former, includes:

Research that explores a taxonomy for accounting process in cloud computing
context;
Research that proposes accounting models directed to cloud computing;
Research that provides concepts about pricing schemes in cloud/grid computing;
and
Research related to SLAs composition in cloud/grid computing.
The latter, excludes the studies which:
Studies did not address or just mentioned accounting models/processes, pricing
schemes, SLA composition on cloud/grid computing;
Studies only available as abstracts or presentations; and
Duplicate studies. When a study has been published in more than one publication,
the most complete version will be considered.
Figure 2.3 illustrates such screening process. The exclusion criteria were applied
to the title and abstract of the identified studies, resulting in 98 studies being selected.
The large amount of duplicated studies contributed to this significant difference. Next, a
second filter was applied, analysing the introduction and conclusion remaining 23 primary
studies. Table 2.2 presents a list with the 23 papers.
Figure 2.3 Filters of the screening process.
Kitchenham et al. (2004) advocates the use of study quality assessment to remove
the effect of low-quality studies on results. However, given the small number of primary
13
studies we did not wish to exclude papers based on their quality. This phenomenon was
also acknowledged by Staples and Niazi (2007), who found the strict guidelines to be too
restrictive in the study quality assessment.
Table 2.2: Primary Studies
Code
Primary Study
Reference
PS01
A Framework for SLA-based Cloud services verification and composition
Falasi and Serhani (2011)
PS02
Conceptual SLA framework for Cloud Computing
Alhamad et al. (2010)
PS03
A Service-oriented accounting architecture on the Grid
Yu et al. (2004)
PS04
THEMIS: Towards Mutually Verifiable Billing Transactions in the Cloud
Park et al. (2012)
Computing Environment
PS05
Authentication and Billing Framework for Service Oriented Architecture
Pandey et al. (2009)
PS06
Accounting and Billing for Federated Cloud Infrastructures
Elmroth et al. (2009)
PS07
A pricing information service for Grid computing
Caracas and Altmann

(2007)
PS08
SLA-driven Elastic Cloud Hosting Provider
Comellas et al. (2010)
PS09
The economy of parallel and distributed computing in the Cloud
Jai (2011)
PS10
Pricing strategies of software vendors
Lehmann and Buxmann

(2009)
PS11
PS12
On Economic and Computational-Efficient Resource Pricing in Large
Mihailescu and Teo
Distributed Systems
(2010b)
Dynamic Resource Pricing on Federated Clouds
Mihailescu and Teo

(2010a)
PS13
Accounting, pricing and charging service models for a GUISET Grid-based
Buthelezi et al. (2008)
service provisioning environment

PS14
A Flexible Accounting Model for Cloud Computing
Ruiz-Agundez et al.
(2011)
PS15
An economy-based accounting infrastructure for the dataGrid
Piro et al. (2003)
PS16
Agent-based simulations of the software market under different pricing schemes
Rohitratana and Altmann
for software-as-a-service and perpetual software
(2010)
PS17
Specifying and monitoring guarantees in commercial Grids through SLA
Sahai et al. (2003)
PS18
Review of pricing models for Grid and Cloud Computing
Samimi and Patel (2011)
PS19
Competitive Pricing Model for Resource Scheduling in Grid Computing
Song et al. (2007)
14
PS20
A Taxonomy of the Future Internet Accounting Process
Ruiz-Agundez et al.
(2010b)
PS21
Economic models for resource management and scheduling in Grid computing
Ernemann et al. (2002)
PS22
Debunking Real-Time Pricing in Cloud Computing
Wee (2011)
PS23
The Cloud Supply Chain: A Framework for Information, Monitoring,
Lindner et al. (2011)
Accounting and Billing
2.2.4
Keywording
A classification scheme is a mechanism composed by a set of categories used to classify

the primary studies such a way it extract detailed information and identify research gaps.
Aiming to build our classification scheme we based on the systematic process proposed
by Petersen et al. (2008) called keywording.
Keywording is a way to reduce the time needed in developing the classification
scheme and ensuring that the scheme takes the existing studies into account. Keywording
is done in two steps. First, the reviewers read abstracts and look for keywords and
concepts that reflects the contribution of the paper. While doing so the reviewer also
identifies the context of the research. When this is done, the set of keywords from
different papers are combined together to develop a high level understanding about the
nature and contribution of the research. This helps the reviewers come up with a set of
categories which is representative of the underlying population. When abstracts are too
poor in quality, reviewers can choose to study also the introduction or conclusion sections
of the paper. When a final set of keywords has been chosen, they can be clustered and
used to form the categories for the map (Petersen et al., 2008). This way, three different
facets were used, namely following:
Contribution Type: Method, Process, Technique, Model and Framework (Freitas
et al., 2011);
Accounting Model Features: Pricing, Metering, Mediation, Accounting, Roaming, Billing, Charging, Financial Clearing, Just in Time Clouds, SLA Support,
Multiple Payment Models, Charging Policy Language and Resource as a Service;
Research Type: Validation Research, Evaluation Research, Solution Proposal,
Philosophical Papers, Opinion Papers, and Experience Papers (Wieringa et al.,
2005) (see definitions in Table 2.3).
15
2.3. MAPPING RESULTS
Table 2.3 Research Type Facet (Wieringa et al., 2005)

Class
Description
Validation
Techniques investigated are novel and have not yet been implemented in practice. Techniques used are for
Research
example experiments, i.e., work done in the lab.

Techniques are implemented in practice and an evaluation of the technique is conducted. That means, it is
Evaluation
shown how the technique is implemented in practice (solution implementation) and what are the
Research
consequences of the implementation in terms of benefits and drawbacks (implementation evaluation). This
also includes identification of problems in industry.
A solution for a problem is proposed, the solution can be either novel or a significant extension of an
Solution
existing technique. The potential benefits and the applicability of the solution is shown by a small example
Proposal
or a good line of argumentation.
Philosophical
These papers sketch a new way of looking at existing things by structuring the field inform of a taxonomy
Papers
or conceptual framework.
These papers express the opinion of somebody whether a certain technique is good or bad, or how things
Opinion Papers
should been done. They do not rely on related work and research methodologies.
Experience
Experience papers explain what and how something has been done in practice. It has to be the personal
Papers
experience of the author.
2.2.5
Data Extraction
A data extraction form was designed to gather the required information and address the
objectives of this study. In this step we read the primary studies carefully and extracted
two information: the (i) research categorization (Contribution Type, Accounting Model
Features and Research Type) and the (ii) required information to answer some of the
research questions.
To organize this information we used a spreadsheet to document the data extraction
process. The table contained each category of the classification scheme and the position
inside the paper which answered some of the four research questions.
The analysis of the results focused on presenting the frequencies of publications for
each category. This makes it possible to see which categories have been emphasized in
past research and thus to identify gaps and possibilities for future research.
2.3
Mapping Results
In this section, each topic presents the findings regarding to a specific research question,
highlighting the evidences gathered from the data extraction process. Hereafter, for the
sake of brevity and clarity, an individual primary study will be referenced by its code,
which is comprised of the letters PS" followed by a number indicating its order. Hence,
in the current work, primary studies range from PS01 to PS23. The primary studies and
16
their respective codes can be seen in Table 2.2.
2.3.1
RQ1 - Is there any taxonomy for concepts related to accounting process in cloud computing?
In our research only one primary study effectively answered this question. The study
PS20 presents a taxonomy of full accounting process and its functions from the resource
usage to the financial clearing. It is not applied only to cloud computing, but other areas
related to services on the internet. The accounting functions are presented in Table 2.4.
Table 2.4: Taxonomy of Accounting Process (Ruiz-Agundez
et al., 2010b)
Concept
Function
Pricing
Function of giving a price to a certain resource usage.
Metering
Collects raw information regarding the resource usage of a certain service by a consumer and its usage.
Mediation
Is intended to do a first treatment of raw technical data by transforming these metering records into a data
format that can be used for storing and further processing.
Accounting
Has the function of filtering and treat more accurately the records passed by mediation function.
Roaming
Allows using more than one provider while maintaining a formal, customer-vendor relationship just with one.
Billing
Also called of invoicing, is the process of transforming charge records into the final bill, summarizing the
charge records of a certain time period and indicating the amount of monetary units to be paid by the customer.
Charging
Is the process of calculating the cost of a resource usage, the function that translates technical values into
monetary units by applying a pricing function to the session records.
Financial
Includes activities from a commitment for a transaction to its settlement. In the case of resource accounting,
Clearing
this function implies the payment of a bill.
The process flow is expressed by Figure 2.4. First, resource usages (also called
metering records) are registered by the Metering function. Afterwards, the Mediation
function intercedes by treating the raw data and sending accounting records for the
Accounting function (it is important to highlight that accounting process means the whole
process and the accounting function refers to one step of accounting process). The
Accounting creates session records, which are an appropriate format to be used by the
functions Charging, Pricing and Roaming. The Pricing function generates a formula
defining how to price the session records. The Charging function generates monetary
information called charging records to be aggregated later by the Billing function. There,
17
the final bill is generated and sent to the Financial Clearing function (Ruiz-Agundez
et al., 2010b).
Figure 2.4 Accounting Process (Ruiz-Agundez et al., 2010b)
Although it was found only this taxonomy formally defined, other terms are used with
similar meanings. For example, monitoring has the same sense of metering. According
to Lindner et al. (2011) the metrics generated by the monitoring function can be used
both for accounting purposes as for performance analysis. Ruiz-Agundez et al. (2010b)
also uses the term monitoring but as a sub-function of metering to collect the usage
information as raw data.
2.3.2
RQ2 - What are the existing accounting models for cloud computing?
When performing the analysis, five primary studies were found (PS14, PS06, PS05, PS04
and PS23) that proposed some kind of accounting model, summarized following:
1) Flexible Accounting Model (PS14) - This paper proposes a flexible accounting
model suitable for any service of cloud computing. This model is based on the accounting
process of the Internet identified by RQ1 (Ruiz-Agundez et al., 2010b) and uses basically
two technologies: an accounting platform called jBilling and a protocol called IPDR
(Internet Protocol Detail Record).
jBilling is an open accounting platform responsible for payment tasks. Considering
the accounting process proposed by Ruiz-Agundez et al. (2010b) it encompasses mainly
the financial clearing function. According to this primary study, the jBilling platform
enabled the operators to apply different pricing schemes (e.g. usage-based, volume-based,
18
time-based, flat-rate, quality-of-service-based, etc.). However, it was not exposed how to

choose and apply these pricing schemes in a flexible way.
In other hand, the IPDR was used as a standardized format to exchange the usage
records between IP networks, hosting elements and operations or business support systems. Thus, it provides a standardised framework that enables network and service
accounting comprehensively. This standard is designed to enable cost-effective usage
measurement (Ruiz-Agundez et al., 2011).
Figure 2.5 shows the IPDR reference model. The user consumes a service and the
metering function collects these records in IPDR format through the IPDR Recorder.
These records can be stored or transmitted to the business support system by the mediation
function using the IPDR Transmitter. The rest of the accounting process functions are
allocated in the business support system, similar to other functions such as user management, report generation, fraud management, error management or network elements
configuration (Ruiz-Agundez et al., 2011).
Figure 2.5 IPDR reference model (Ruiz-Agundez et al., 2011)
2) A Model for Federated Clouds (PS06) - This primary study presents a solution
for an accounting and billing architecture for use in federated cloud environments and built
by an European Cloud project called RESERVOIR (funded by the European Union). The
idea of federated cloud is that a single entity serves as a gateway to different independent
solutions, and this is one way to solve the limited interoperability, as different technologies
can be unified and abstracted towards the consumers.
The model is organized in layers (Accounting, Billing and Business Layer). The
Accounting Layer, focused on collecting and managing the data which components
in the Billing Layer use as their input. The Business Layer forms a link between the
19
technical system and the Service Provider in terms of, e.g., pricing, invoicing, and service
management. An overview of the different layers and their components can be seen in
Figure 2.6.
Figure 2.6 Architecture in Layers for Accounting and Billing within the RESERVOIR Service
Manager. (Elmroth et al., 2009)
The Figure 2.6 shows the main components of the suggested architecture. It includes
the connectors indicating the main interactions between components. Components with a
dashed border in the figure handle the communication with other parts of the RESERVOIR
system. As this dissertation focuses on the accounting and billing aspects, only these
parts are following explained in more detail.
The accounting layer is responsible for the interaction with the surrounding infrastructure. It collects usage records and SLA violations from other components. The primary
component is the SM Accounting Manager (SMAM) that together with the underlying
Accounting Database (ADB) offers persistent storage and management of usage records
and violations. The SMAM is supplied with data regarding SLA violations from the SLA
Violation Assessment component, and these SLA violations are taken into account by
components at the Billing layer. Similarly, the VEEM Accounting Manager (VAM) is
responsible for collecting usage data from the local site, mark them with an identification,
and supply this to the SMAM at regular intervals.
The billing layer is primarily made up of the post-paid engine and the pre-paid
engine, supported by the Service Configuration Analyzer (SCA) and the Service Lifecycle Manager (SLM) that are part of both the business and billing layers. SCA is
responsible for validating the deployment of services and generate unique identifiers for
these particular services. This identifier is referred to as the Accounting, Billing, and
20
Compensation(ABC) identifier, and all usage records and SLA violation concerning this
service will contain such identifier. Using this approach, it is possible to address all
services without knowing where they are running or how many they are. Finally, the
SLM monitors the consumed services while it communicates with pre-paid engine to
probably break off the provisioning when the pre-paid credits exceeds.
Another contribution of the RESERVOIR project in the accounting field is related to
a kind of guide which dictates what characteristics an accounting system must be based
in. They outlined usage scenarios with challenges that are typical for federated clouds
and derived eight principles listed following:
Location Unawareness: Account for the VMs as a service, running locally or
remotely no matter where it is running.
Flexible Data Format: It should be possible to include additional usage information metrics.
Service Elasticity: The number of VMs underlying and fulfilling a service can
scale due to service elasticity. The accounting system must be designed to handle
such scenario.
Service Accounting: The accounting system must be suitable for long running
services, and not limited to tasks with a limited execution time.
Compensations: Both usage and compensations (due to breaking SLAs) must be
accounted for.
Service Billing: Billing must be managed on a per service basis and not just for
each VM.
Adaptable Design: The accounting system must be open for modifications to cope
with future changes and enhancements.
Complex Pricing: The function that calculates prices from the accounting information must be able to incorporate complex pricing rules.
3) ABS for SOA (PS05) - This primary study presents an accounting model focused
on Software as a Service (SaaS) provisioning. Mainly the functions authentication of the
clients and billing of services are carried out.
Models proposed by different researchers earlier used different servers for billing and
security (Authentication and Authorization). This needs more running and maintenance
cost. Moreover high level of synchronization is also needed so that same entries are
21
processed on both servers simultaneously. Also two different databases have to be run on
both servers.
In this context, they have integrated both the servers functionalities in a single server
called ABS (Authentication and Billing server) which is capable of performing certain
functions:
Authentication and Authorization of user;
Communicates with the Application server for generating service instances for
particular users, and provides user the direct address of the instance.(user does not
need to contact the application server);
This instance is generated for a particular time period ordered by user. Billing is
done on the basis of this time period.
4) THEMIS (PS04) - This model proposed a mutually (provider and user) verifiable
billing system called THEMIS to cloud computing scenario. It has as main requirements
the transparency, security and low latency in billing transactions.
The system introduces the concept of a Cloud Notary Authority to supervise billing
transactions, using a level of security that is identical to that of a Public Key Infrastructure
(PKI). THEMIS generates mutually verifiable binding information that can be used to
resolve future disputes between a user and a cloud service provider.
Figure 2.7 shows the overall architecture THEMIS billing infrastructure, highlighting
the major components of the architecture (Cloud Service Provider (CSP), Users and
Cloud Notary Authority (CNA)):
Cloud Service Provider (CSP): The CSP enables users to scale their capacity
upwards or downwards in accordance with their computing requirements and to
pay only for the capacity that they actually use.
Users: They assume that users are thin clients who use services in the cloud
computing environment. To use services in such an environment, each user makes
a request to the CSP with a billing transaction.
Cloud Notary Authority (CNA): The cloud notary authority provides a mutually
verifiable integrity mechanism to combat the malicious behaviour of users or the
CSP. The cloud notary authority investigates billing transactions and generates
mutually verifiable binding information
22
Figure 2.7 Overall architecture and process flow of THEMIS
5) Cloud Supply Chain (PS23) - This model proposes the Cloud Supply Chain
concept, which represents a network of interconnected businesses in the cloud computing
area. It involves end-to-end provision of services required by the end customers. The
delivered product is along the way enriched and in parallel the functions supporting
monitoring, accounting and billing are performed.
Although this primary study focus on how IaaS Providers improve their services in a
supply chain, it proposes a architecture directed to collect and aggregate multiple usage
records and Key Performance Indicators (KPI).
This model distinguishes the concepts of producers and consumers. Producers collect
monitoring data from the overall environment, in the form of usage measurements. This
is achieved typically via software probes, which provide the necessary mechanisms to
interact with the infrastructure or service, formulating for example appropriate queries
on a regular basis. This measurement data can come from numerous sources; this may
be raw data gathered from probes in the underlying infrastructure, data gathered from
probes embedded in the application, data which is the combination of the raw data into
composed KPIs, or data derived from the analysis of historical raw data and KPI data held
in a data store. Consumers on the other hand will read the monitoring data and will enact
some form of action, depending on the rules determined by the service or infrastructure
provider. The Figure 2.8 shows the whole structure of the Monitoring data flow.
23
Figure 2.8 Monitoring data flow (Lindner et al., 2011)
In this illustration a single monitoring channel is used to aggregate the measurements

obtained from probes embedded at the service level, within a virtual machine, responsible
for the allocation and placement of service components on physical resources, or at
the resource layer itself. The central part of the architecture is called Service Management Module and resides on Infrastructure Providers level, composed of the Lifecycle
Management, the SLA Protection and the Accounting/Billing functions.
The Lifecycle Management monitors the state of deployed applications. The SLA
Protection ensures a particular level of service. The state of the application service must
be described and exposed in the form of one or more KPIs and enacting resizing actions
when conditions related to these KPIs are met. Lastly the accounting and billing functions
require the collation of measurements into usage records which will summarise the overall
level of activity of a service provider, and from which it can derive an appropriate measure
of usage costs.
2.3.3
RQ3 - What are the existing pricing schemes for cloud or grid
computing?
A pricing scheme is a measurement unit applied under a resource consumption to be

charged (Caracas and Altmann, 2007). However, different terms are used with the
same meaning, as pricing models (Samimi and Patel, 2011) or pricing mechanisms
(Osterwalder, 2004).
Although the current cloud computing literature almost without exception considers
pricing of cloud services, the discussion rarely covers more than a mention about usage
of pay per use pricing mechanism. However, as Harmon et al. (2009) argue, pricing is
one of the most critical decisions that a firm make whether planning the introduction of a
24
new IT service or repositioning an existing IT service. Weinhardt et al. (2009) argue that
a commercial success with cloud services can only be achieved by developing adequate
pricing schemes.
Osterwalder (2004) differentiates between three main categories of pricing schemes:
Fixed, Differential and Market Pricing. Fixed Pricing mechanisms produce prices that
do not differentiate in function of customer characteristics, are not volume dependant,
and are not based on real-time market conditions. Differential Pricing refers to pricing
schemes that produce prices that are either based on customer or product characteristics,
are volume dependant, or are linked to customer preferences, but not based on real-time
market conditions. Market Pricing stands for pricing schemes that produce prices based
on real-time market conditions.
Cloud computing literature discusses some of the pricing schemes (Cai et al., 2009;
Weinhardt et al., 2009; Buyya et al., 2009b; Youseff et al., 2008) discuss pay per use2
mechanism, which is widely hyped to be one of the key changes that cloud computing
brings to IT services business. With pay per use mechanism, capacity units such as
number of transactions, gigabytes of storage or memory or units per time such gigabytes
of memory per hour are associated with resources and assigned fixed price values and
customer pays according to his metered usage of resources.
The capacity unit may be also artificial as Amazon-AWS (2012), that sells instances"
of their capacity pool. Pay per use pricing is typically used with IaaS and PaaS services
and its benefit is that it allows customization to specific application needs. Ouyang et al.
(2007) note that quantification of resources and measurement of dynamic usage may be
challenging task with cloud services. Denne (2007) discusses various advanced ways to
implement pay per use pricing mechanism.
Denne (2007), Prodan and Ostermann (2009) and Buyya et al. (2009b) discuss
advance pricing. In this pricing mechanism, customers prepay for a certain amount
of capacity units that have to be consumed usually in a certain period of time and
overcharging is applied if the customer exceeds the quota of prepaid units.
Youseff et al. (2008) and Weinhardt et al. (2009) discuss subscription pricing in
cloud and Denne (2007) mentions pricing based on pre-purchase of services. With
subscription mechanism, customer subscribes (i.e., signs a contract) for using a preselected combination of service units with a fixed price for a fixed time period such as a
month. In subscription model, pricing is per unit of time and not per unit of consumption.
2 Also
known as pay-as-you-use, pay-as-you-go, per-unit pricing, and resource-consumption-based
pricing.
25
Subscription pricing is most used with SaaS services and it allows prediction of customers
periodic expenses but lacks the accuracy of charging users what they have used.
Therefore, a lot of work mention some type of pricing scheme and as a result of
our investigation the Table 2.5 summarizes all the pricing schemes found with their
respective concepts and in which study they were discussed. Despite this heterogeneous
nomenclature, it was collected 31 different types of pricing schemes, distributed on
10 primary studies (PS14, PS07, PS18, PS09, PS10, PS12, PS15, PS19, PS03 and
PS22). Among these, the most referenced were Time-Based, Flat-Rate, Usage-Based,
Competitor-Oriented Pricing, Supply and Demand Based and Auction Based Model.
The Supply and Demand Model can be divided into three other pricing schemes:
Real-Time Pricing (RTP), Derivative Follower Model and Hybrid Pricing Model. While
Auction Based Model can be divided into English Auction, First-Price Sealed-Bid Auction,
Vickrey, Dutch Auction and Double Auction.
Table 2.5: Pricing Schemes
Pricing Scheme
Definition
Time-based
Pricing based on how long a service is used.
Studies
PS21, PS14,
PS07
Paris-Metro
Used for shared resources. Resources are split by the amount of users per split.
PS14
Priority pricing
Services are labelled and priced according to their priority.
PS14
Flat-rate
A fixed tariff for a specified amount of time.
pricing
PS21, PS14,
PS07
Edge pricing
Calculation is done based on the distance between the service and the user.
PS14
Responsive
Charging is activated only on service congestion.
PS14
Charging is based on an expected usage function.
PS14
Proportional
It is according to the users willingness to pay, in other words, It is based on the
PS10, PS14
fairness pricing
real value of product or service.
Cumulus pricing
Based on flat pricing and dynamically priced by using a credit point system.
PS14
Session-oriented
Based on the use given to the session.
PS14
pricing
Effective
bandwidth
pricing
26
One-off charge
One charge per service session.
PS14
per service
PS07, PS09,
Usage-based
Pricing based on the general use of the service for a period of time, e.g. a moth.
PS14
Content-based
Pricing based on the accessed content.
PS14
QoS-based
Pricing depends on the hired quality of service.
PS19, PS14
Location-based
Pricing based on the access point of the user.
PS14
Service type
Pricing based on the usage of the service.
PS14
Volume-based
Pricing based on the volume of a metric (e.g. downloaded bytes).
PS19, PS14
Differentiation
Pricing based on the hour when the service is used.
PS14
Progressive
Seller and buyer try to convene on a pricing plan. The seller announces a fixed
PS07
Co-design
price pair (p1, p2), where p1 < p2. Subsequently, the buyer commits a
on time-of-day
consumption level quality related to each price announced and if agreed so he

can buy additional units progressively if needed.
PS16, PS19,
Competitor-
At first, the vendor agent needs to select the competitor to compete with. Then,
Oriented (CO)
the vendor simply decreases the price just below of the rivals price. This
Pricing
algorithm requires perfect information of the rivals price.
Cost-based
Following the approach of cost-based pricing, the price level is established
PS10
PS10
using cost accounting. According to it price determination based on costs can

make good sense for SaaS.
PS12, PS03,
Supply and
In general way the unit price will vary until it settles at a point where the
PS21, PS22,
Demand based
quantity demanded by consumers (at current price) will equal the quantity
PS15, PS16
supplied by providers (at current price), resulting in an economic equilibrium of

price and quantity.
Real-Time
Is a pricing model that dynamically changes its rate reacting to the classical
Pricing (RTP)
supply and demand rule, but with the difference that there is only one supplier.
PS22
Amazon Web Services (AWS) offer a simplified form of this pricing model
called Spot Instances.
27
Derivative
Its a kind of supply and demand based model simply adjusts prices by
Follower Model
incrementally increasing or decreasing them until the observed profitability
PS15, PS16
level falls, then the direction of price adjustment is reversed, thus seeking a
local maximum of profitability.
Hybrid Pricing
This model allows a third entity called Price Authority dynamically adjust
Model
prices within static limits to balance the workload on the basis of the queue wait
PS15
times of jobs in grid environments.

PS11, PS12,
Auction based
Services are priced in an auction and carried out by a third party, called the
PS14, PS21
market maker, which collects the bids, selects the winners and computes the
payments.
English Auction
All bidders are free to increase their bids exceeding other offers. When none of
PS21
the bidders are willing to raise the price anymore, the auction ends, and the
highest bidder wins the item at the price of his bid.
First-Price
Each bidder submits one bid without knowing the others bids. The highest
Sealed-Bid
bidder wins the item at the price of his bid.
PS21
Auction
Vickrey
Each bidder submits one bid without knowing the others bids. The highest
PS21
bidder wins the item at the price of the second highest bidder.
Dutch Auction
The auctioneer starts with a high bid/price and continuously lowers the price
PS21
until one of the bidders takes the item at the current price. It is similar to a
first-price sealed-bid auction because in both cases the bid matters only if it is
the highest, and no relevant information is revealed during the auction process.
Double Auction
In the double auction model, buy orders (bids) and sell orders (asks) may be
PS21
submitted at any time during the trading period. If at any time there are open
bids and asks that match or are compatible in terms of price and requirements
(e.g., quantity of goods or shares), a trade is executed immediately.
2.3.4
RQ4 - What are the aspects taken into account to compose a

SLA in cloud/grid computing scenario?
In order for cloud providers supply clients with services that meet their quality constraints,
they both need to negotiate the clients requirements and the providers infrastructure
capabilities. It is known as Service Level Agreement (SLA). However, this is not an easy
task, according to Jain et al. (1988) there are difficulties to formalize a SLA, such as lack
28
of flexibility and precision. This way, to compound a SLA it is important to know which
aspects have to be taken into account.
When performing the analysis, few studies explicitly stated the formalization of SLA
in cloud/grid computing scenario. However 4 primary studies (PS01, PS02, PS08 and
PS17) are complementary. They are summarized following.
1) SLA Description Language (PS01) This primary study introduced a framework
that enables dynamic specification and verification of SLAs in the cloud. Its main
contribution to our research is a format of SLA-Description based on XML specification
which defines the main Quality of Services (QoS) along with their threshold values agreed
upon selection of cloud services. It also defines the period of service provision, the cost
of using the service, and the possible actions that should be taken if QoS provision is
frequently violated. Below, the Code 2.1 describes an example of SLA according to this
description language.
Code 2.1 Example of SLA-Description (Falasi and Serhani, 2011)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
< Cloud WBname : name>

< C l a s s : GOLD>
/ / QoS p r o p e r t i e s d e s c r i p t i o n and t h e i r t h r e s h o l d
<QoS>
Reputation = 5
RTmin= 8ms / / minimum v a l u e o f r e s p o n s e t i m e
RTmax = 10ms / / maximum v a l u e o f r e s p o n s e t i m e
C o s t = "$0.1"
Min A v a i l a b i l i t y = 90%
</QoS>
</ C l a s s GOLD>
< C l a s s : SILVER>
<QoS>
R e p u t a t i o n = NULL
RTmin = 15ms / / minimum v a l u e o f r e s p o n s e t i m e
C o s t = "$005"
Min A v a i l a b i l i t y = 80%
</QoS>
</ C l a s s : SILVER>
...
<Terms >
The t e r m s d e s c r i b e s t h e n e c e s s a r y a c t i o n s i f t h e QoS i s v i o l a t e d .
<Terms >
< Cloud WSname : name>
The provider can specify three Service Levels: Gold, Platinum and Silver which are
called classes. As aforementioned each class addresses a set of Quality of Services (QoS).
In Code 2.1 can be observed the class GOLD and its QoS owes the response times 8 and
10 milliseconds thresholds. This QoS means that when such limit is exceeded a discount
of $0.1" is assigned to the customer.
29
2) SLA Metrics x Service Types (PS02) This paper presents the main criteria which
should be considered at the stage of designing the SLA in cloud computing. In this
work its proposed a framework which the SLA parameters are specified by metrics.
These metrics define how cloud service parameters can be measured and specify values
of measurable parameters. In the cloud computing architecture, there are four types of
services which providers can present to consumers. These services are: (i) Infrastructure
as a Service (IaaS), (ii) Platform as a Service (PaaS), (iii) Software as a Service (SaaS),
and (iv) Storage as a Service.
(i) SLA metrics for IaaS: Companies like Amazon AWS provide IaaS. Most of
the consumers are confused as to which important parameter should be defined in
the hardware part of the SLA. It lists the most important parameters for consumers
who are interested in using cloud as an infrastructure service (Table 2.6).
Table 2.6 SLA metrics for IaaS (Alhamad et al., 2010)
Parameter
Description
CPU capacity
CPU speed for VM
Memory size
Cash memory size for VM
Boot time
Time for MV to be ready for use
Storage
Storage size of data for short or long term of contract
Scale up
Maximum of VMs for one user
Scale down
Minimum number of VMs for one user
Scale up time
Time to increase a specific number of VMs
Scale down time
Time to decrease a specific number of VMs
Auto scaling
Boolean value for auto scaling feature
Max number can be configured on

Maximum number of VMs that can be run on individual server
physical server
Availability
Uptime of service in specific time
Response time
Time to complete and receive the process
(ii) SLA metrics for PaaS: Platform as a Service is a type of cloud computing
that provides all the requirements needed to support application developers in
developing, evaluating, and delivering applications and software for end users
(Hilley, 2009). So, developers using PaaS do not need to download tools or
configure hardware to complete the developmental tasks. For SLA metrics related
to PaaS, Table 2.7 defines the main parameters that can be used as basic criteria
when developers want to negotiate with PaaS providers.
(iii) SLA metrics for SaaS: Software as a service is a common example of cloud
services if an application is hosted on a cloud platform and infrastructure to provide
30
Table 2.7 SLA metrics for PasS (Alhamad et al., 2010)

Parameter
Description
Integration
Integration with e-services and other platforms
Scalability
Degree of use with large number of online users
Pay as you go billing
Charging based on resources or time of service
Environments of deployment
Supporting offline and cloud systems
Servers
How many servers are used
Browsers
Firefox, IExplorer,..
Number of developers
How many developers can access to the platform
built-in services for end users of cloud computing (Muller et al., 2009). Good
examples of SaaS are mail, calendar, and social web sites provided by Google,
Yahoo, and Microsoft. Table 2.8 presents the common metrics parameters for SaaS
as an example of metrics for this type of cloud service.
Table 2.8 SLA metrics for SaaS (Alhamad et al., 2010)
Parameter
Description
Reliability
Ability to keep operating in most cases
Usability
Easy built-in user interfaces
Scalability
Using with individual or large organisations
Availability
Uptime of software for users in specific time
Customizability
Flexible to use with different types of users
(iv) SLA metrics for Storage as a Service: Online users access their data from
different geographical locations. In the past few years, online storage providers
were unable to maintain large size of data because of the lack of huge space in
storage disks, network performance, and data management systems. Now, data
storage service providers such as S3 by Amazon AWS configure large numbers of
storage hardware and they are able to manage and serve millions of users efficiently
with their method of data transference and ensuring these data are compatible with
various types of applications. The parameters for data storage service metrics are
basic requirements for negotiation with storage providers. Such parameters are
presented in Table 2.9.
31
Table 2.9 SLA metrics for Storage as a service (Alhamad et al., 2010)
Parameter
Description
Geographic Location
Availability zones in which data are stored
Scalability
Ability to increase or decrease storage space
Storage space
Number of units of data storage
Storage billing
How the cost of storage is calculated
Security
Cryptography for storage and transferring of data, authentication, and

authorization
Privacy
How the data will be stored and transferred
Backup
How and where images of data are stored
Recovery
Ability to recover data in disasters or failures
System throughput
Amount of data that can be retrieved from system in specific unit of time
Transferring bandwidth
The capacity of communication channels
Data life cycle management
Managing data in data centres, and use of network infrastructure
3) SLA Components (PS17) This primary study proposes an unambiguous and

flexible language for formalizing SLAs and an architecture for specifying and monitoring
SLAs on grid computing scenario. Finally it references a typical SLA formulated by Jain
et al. (1988) that includes the following components:
Purpose: describing the reasons behind the creation of the SLA
Parties: describes the parties involved in the SLA and their respective roles.
Validity Period: defines the period of time that the SLA will cover. This is
delimited by start time and end time of the term.
Scope: defines the services covered in the agreement.
Restrictions: defines the necessary steps to be taken in order for the requested
service levels to be provided.
Service-level objectives: are the levels of service that both the users and the
service providers agree on, and usually include a set of service level indicators,
like availability, performance and reliability. Each aspect of the service level, such
as availability, will have a target level to achieve. Service Level objectives have
day-time constraints associated with them, which delineate their validity.
Service-level indicators: the means by which these levels can be measured. Service Level Indicators (SLI) are the base level indicators.
Penalties: spells out what happens in case the service provider under-performs and
is unable to meet the objectives in the SLA. If the agreement is with an external
32
service provider, the option of terminating the contract in light of unacceptable

service levels should be built in.
Optional Services: provides for any services that are not normally required by the
user, but might be required as an exception.
Exclusions: specifies what is not covered in the SLA.
Administration: describes the processes created in the SLA to meet and measure
its objectives
4) SLA Satisfaction Function (PS08) Here, the authors addressed an elastic web
hosting provider, namely Cloud Hosting Provider (CHP). It uses outsourcing technique
to take advantage of IaaS for web applications deployment. Furthermore, they pursue
maximizing the revenue earned by the provider through both the analysis of SLA and the
employment of an economic model.
Therefore, this primary study does not encompasses a specification language for
example, but an economic model to calculate whether a hosting provider earns or loses
money with a cloud provider service, looking throughout SLA violations and compensations. In this context, it defines a set of Economic Variables and a set of Monitoring
Functions to monitor and calculate Revenues.
Economic Variables
Price (Prc) is the amount of money that a customer will pay if a provider
brings to completion the SLA Si. It is specified in the same SLA and usually
has a predetermined value.
Penalty (Pen) is the amount of monetary units that the provider must pay to
the client if the accorded SLA Si is violated. It is also specified in the SLA
and is a function of diverse parameters.
Cost of Execution (CoE) is a cost for the web hosting provider for executing
a web application with a specified SLA S. In our environment, this cost has to
be split in two prices:
* Cost of Hosting (CoH) is the price of maintaining a local server that
hosts a web application with an associated SLA S. It includes its administration, its cooling, the area where it is placed, etc.
* Cost of Outsourcing (CoO) is the total amount of money that we have
to pay for outsourcing the operation of a given web application to a
third-party.
33
2.4. RESULTS ANALYSIS
Monitoring Functions
The SLA Satisfaction Function (SSF(S)) specifies if a SLA Si is fulfilled or
it is violated
The Minimum Violating Response Time (MV RT(S)) determines the minimum response time from which a SLA S is violated.
The Outsourced Virtual Machines (OV M(S)) is the number of virtual machines that we have externalized for running the servers whose contain the
web application with the associated SLA S.
Revenue (Rvn(S)) is the economic benefit that a provider obtains with the
execution of a web application whose SLA is S. It is defined as:
Rvn(S) = Prci (CoE + Peni)
Punctual Revenue (Rvn(t;M)) is the total (t) gain (or loss) obtained by hosting a set of web applications with the corresponding set M of SLAs.
2.4
Results Analysis
By analysing the results, it can enable us to present the number of studies tabulated
in each category defined in this study. Thus, it is possible to identify what have been
emphasized in past research and determine gaps and opportunities for future research
(Petersen et al., 2008).
2.4.1
Research Type Classification

Table 2.10 Research Type Classification
Research Type
Studies
Quantity
PS08, PS11, PS12, PS18, PS19,PS03, PS23
7 (30,4%)
PS04, PS16, PS14, PS21, PS22, PS23
6 (26%)
PS01, PS02, PS13, PS06, PS09, PS10, PS05, PS04, PS15, PS17, PS19, PS20
12 (52,1%)
PS07
1 (4,3%)
0 (0%)
0 (0%)
Validation
Research
Evaluation
Research
Solution
Proposal
Philosophical
Papers
Opinion Papers
Experience
Papers
34
First, let us analyze the distribution of the type of research performed in the studies
(Table 2.10). The concepts for the research types were presented in Table 2.3 in Section
2.2.4 (Keywording).
Opinion and Experience papers are notoriously nonexistent in this field, while a
number of Validation, Evaluation, and, primarily Solution Proposal papers were found.
There is also a need for Philosophical papers, because they lead the creation of
new ideas. However, another more important point was observed related to Evaluation
Research papers, which concerns techniques implemented in practice mainly in industry;
the small quantity of such studies compared to Solution Proposal papers indicates the low
level of experimentation in industry.
Certainly, progress has been made in this area, but the accelerated growth in the
number of cloud providers, as reported by Jeremy (2010), influences the degree of competitiveness, causing their proposals not be released into the scientific community. This
situation encourages us to perform research analyzing and comparing cloud providers
accounting models in practice.
2.4.2
Contribution Type Classification
Table 2.11 shows the contribution type classification scheme. Most of the studies propose
concrete Models or Frameworks, rather than addressing activities related to accounting
functions. Few Processes, and Techniques and no Methods were registered. One possible
explanation may be the observation made earlier about the lack of practical results
disclosed by industry. In this case, we can conclude that even small companies publish
what they did (models and frameworks) but hide the how they did it (processes, techniques,
and methods).
Table 2.11 Contribution Type Classification
Contribution Type
Studies
Method
0 (0%)
Process
PS01, PS04, PS17, PS20, PS23
5 (21,7%)
Quantity
Technique
PS08
1 (4,3%)
Model
PS13, PS07, PS06, PS09, PS10, PS15, PS16, PS14, PS17, PS18, PS19,
14 (60,8%)
Framework
PS01, PS02, PS07, PS11, PS12, PS05
PS03, PS21, PS23

6 (26%)
35
2.4.3
Research Types vs. Research Questions
We analyzed the relationship between the research questions and the research types, using
a bubble plot to represent the interconnected frequencies (Figure 2.9). This figure is
basically an x-y scatterplot with bubbles at the intersections of categories. The size of
a bubble represents the number of papers in the pair of categories at that intersection
(Petersen et al., 2008).
Figure 2.9 Research type vs. Research questions
The chart shows that only one paper (PS20) fulfilled the RQ1 (accounting taxonomy),
and it was classified as a Solution Proposal. However, it is important to highlight that
PS20 evolved into the study PS14, classified as Evaluation Research. PS14 proposed a
flexible accounting model validated in a real-life scenario, which ensured the taxonomy
validity.
No question was answered by papers that addressed personal Opinions or Experience,
on the other hand one paper (PS02) made a significant contribution, answering RQ2
(accounting models) and RQ3 (pricing schemes); it was classified as a Philosophical
paper and discussed a general pricing scheme that can define pricing variations for any
computational element.
Most of the information related to RQ2 (accounting models) comes from papers
classified as Solution papers. Although four papers were classified as Solution proposals,
five studies were conducted in an academic or industrial environment (validation and
evaluation research), indicating some maturity of accounting models.
Although the majority of studies addressing RQ3 (pricing Schemes) was classified
as Solution Proposal and Validation Research, the papers did not discuss in detail how
36
the pricing schemes could be applied but, rather, presented simple, short concepts. Thus,
as our research aims to give a general mapping of pricing schemes, future research can
focus on explaining how the pricing schemes can work in practice.
Similar to RQ1 (accounting taxonomy), few studies relevant to RQ4 (SLA composition) were found. No studies were conducted in an industrial environment, perhaps
because cloud providers do not publish the specifics of their research and results, as
discussed in Section 2.4.1.
2.4.4
Accounting Models Classification
The accounting models collected during this research were categorized according to their
features (see Table 2.12). In the left side are stated the five accounting models and the
right side the features. If the model attends the feature, then a X is positioned.
PS14
Pricing
Metering
Mediation
Accounting
Roaming
Billing
Charging
Financial Clearing
SLA Support
Multiple Payment Models
Multiple Charging Policy Specification
Resource as a Service
Studies
Features
Table 2.12 Accounting Models Classification
X X X X X X X X X
PS06
X X
PS05
PS04
PS23
X X
First, we used the taxonomy proposed by Ruiz-Agundez et al. (2010b) to determine

what functions the proposed models served. The terms pricing," accounting," and
billing" appeared in more than one paper and carried the same meanings, a homogeneity
which indicates a certain taxonomy validity. Two findings relevant to accounting"
37
deserve attention:
In PS14, the authors disambiguated the expressions accounting process" and
accounting function." Accounting process" refers to a meta-concept that includes
all taxonomy functions, while accounting function" is related to recording and
summarizing technical data in terms of money, transactions, and events.
In PS23, the accounting and billing functions are grouped as integrated subprocesses forming a macro-process.
Finally, it is important to highlight that all primary studies cited the term billing."
We attribute this result to the influence of other fields, such as telephony, that commonly
used this term before cloud computing became a research trend.
Interactive systems increase the usability of applications by providing a convenient
access and allowing the user to spend less time learning how to use the application
and more quickly produce results. The graphical user-interface achieves this usability
(Bencomo et al., 1997). In this context, the Graphical User Interface Support was
analyzed in order to investigate whether the accounting models offered some type of
graphical user interface which could bring usability to access the accounting system. We
noted that some proposed models possess a user interface that gives access control to
managing accounting mechanisms, but not all did so; only 40% had a final graphical user
or admin interface support, which seems to be a research opportunity.
We analyzed the SLA Support feature, which was relevant to one research question,
but the relationships between research type and research questions depicted in Figure
2.9 did not indicate which accounting models provided such support. Thus, we verified
features such as SLA monitoring or whether the customer could choose their desired
service quality, and found that 80% offered such features. Therefore, SLA support has
been shown to be a relevant topic of interest in cloud accounting.
We initially planned to include the term monitoring;" however, the term SLA
support" was preferred because it is a less ambiguous concept. According to Lindner
et al. (2011), SLA and monitoring are strictly related, because the concept of metrics,
considered for the purposes of monitoring, is extremely semantically close to the concept
of key performance indicators, from a SLA point of view.
The accounting model proposed by Ruiz-Agundez et al. (2011) explored the requirement of flexibility in usage records and exchanges between heterogeneous network
components. In other research, (Henzinger et al., 2010) examine flexibility in the pricing
model for the user and cloud provider. Accordingly, the users must be presented with a
38
2.5. THREATS TO VALIDITY
pricing model that offers flexibility as a requirement, such as a choice between different
execution speeds. For the cloud provider, it must present a programming model that offers
flexibility in execution, such as a choice between different scheduling policies. Finally,
Elmroth et al. (2009) claim that an accounting model must allow changing metrics, for
example, to easily record the metric database transactions per second".
Considering these aspects related to flexibility in cloud accounting models, we identified more two features which could be used to analyze the five accounting models:
Multiple Payment Model and a Multiple Charging Policy Specification. First, we
investigated whether the models were prepared to support different payment models, such
as the pre-paid, post-paid, and hybrid models. These models are in no way unique to
cloud computing but, to the contrary, are well known to consumers after being used for
years in other utility markets, most notably the mobile phone industry (Lindner et al.,
2011). Therefore, some accounting models (40%) are ready to work, for example, with
resource consumption based on previous purchased credits (pre-paid) (PS06 and PS23).
We included the flexible charging policy specification and aimed to learn whether the
proposed solutions utilized a mechanism that could enable the provider to easily specify
charging policies through, for example, a language. As presented in Table 2.12, none of
the models include this feature.
According to Ben-Yehuda et al. (2012), over the next few years, a new model of
buying and selling cloud computing resources will evolve. Instead of providers exclusively
selling server equivalent virtual machines for relatively long periods of time (as done
in todays IaaS Clouds), providers will increasingly sell individual resources (such as
CPU, memory, and I/O resources) for a few seconds at a time. Ben-Yehuda et al. (2012)
named this nascent economic model the Resource as a Service (RaaS). Thus, finally,
we analyzed the use of this economic model, and as with the flexible charging policy
specification feature, none of the models applied this model.
In summary, among the analyzed features, only the SLA Support and Billing Function were offered by more than 50% of the accounting models.
2.5
Threats to Validity
There are some threats to the validity of our study.

Research Questions: The research questions we formulated cannot cover all of
the accounting field related to cloud and grid computing. For example, we did not
39
2.6. DISCUSSION
cover payment models (pre- and post-paid), but we had several discussions with
project members (me and the advisor) to validate the questions.
Publication Bias: We cannot guarantee that all relevant studies were selected. It is
possible that some relevant studies were not chosen during the search process. We
mitigated this threat as much as possible by following references in the relevant
studies.
Data Extraction: The studies were classified based on our judgement; however,
some studies could have been classified incorrectly. To mitigate this threat, more
than one researcher performed the classification.
Grid Computing Inclusion: Although this studys main focus is cloud computing,
we also included grid computing. We included it in two questions (RQ03 and
RQ04), aiming to increase the possibility of finding relevant results for cloud
computing. However, it is possible that some findings related to grid computing
are not well applicable in cloud scenarios, because we did conduct experiments to
assess the applicability but, instead, held several discussions with project members
to mitigate this problem.
2.6
Discussion
This systematic mapping study enabled us to analyze the cloud accounting field from
several perspectives. The chosen points of investigation yielded a variety of information
relevant to different types of cloud accounting solutions. We believe that this mapping
study generated state-of-the-art information about the main issues, because the studied
subject can be understood through the answers returned for the four research questions.
The relevant knowledge was obtained, because these questions were based on previous
research into both cloud and grid computing, increasing the reliability of the scope of
research. This section discusses these four research questions, the classification applied
in the primary studies, and what we can draw from it.
The first question was necessary, because we noticed a wide divergence in nomenclatures even in the early stages of research. Although we found only one taxonomy and one
respective accounting process, it was highly robust, based on 36 other studies. Despite
being suitable for use in cloud computing, it was designed to be applied to the Future
Internet," a generic and broad concept. We recommend that everyone who desires to use
this accounting process should consider adapting it before use it by adding or removing
40
2.6. DISCUSSION
functions; for example, the roaming function makes no sense if there is only one service
provider.
In the second question, when we searched for accounting models we hoped to find
a significant number of solutions, but identified only five. We tried to extract the main
features of these account models and ultimately found a couple of limitations which
motivated us to analyze more closely the models peculiarities in order to identify research
opportunities.
The third question considered a broad picture of the 31 types of compiled pricing
schemes. However, it is important to note that they include schemes for both cloud and
grid computing, and no distinction was made between these types because our primary
goal was to map all of the pricing schemes. Although we have condensed several schemes
with different names but the same meanings, the final result includes highly similar types;
it could give rise to doubts, although the references column may clarify these cases.
Future work could apply a series of categorizations to these pricing schemes in order to
answer the following questions:
Which pricing schemes can be used by PaaS, SaaS and IaaS?
Which pricing schemes are used in industry and how are they applied?
Which pricing schemes can be combined, and which combinations could result in
fairer charges?
Which pricing schemes can be used in the context of federated clouds?
Which pricing schemes better suit the pre-paid or post-paid models?
Finally, for the fourth question, we saw the need to study SLAs in cloud computing.
Again, we expected to find many studies, but the four papers we found presented distinct
yet complementary information that could guide new proposal. For example, assume that
a cloud provider wants to add SLA Support to its services. First, the provider needs to
define what high-level information must be included in the contract, such as a validity
period or specific penalties. The study PS17 addressed this possibility. Next, the provider
needs to choose which metrics are appropriate for its provided service type (IaaS, PaaS, or
SaaS). The study PS02 could help with that decision, addressing SLA metrics by service
types. To monitor these metrics, the provider needs to define them. The study PS01
shows how to do so with an XML-based language. Finally, the cloud provider wants to
offer its customers a system to manage their costs for SLA penalties. The study PS08 can
recommend economic models to guide the implementation of such a functionality.
41
2.6. DISCUSSION
The analysis performed on the selected studies focused on four topics: research type
classification, contribution type classification, the relationship between research type
and research questions, and finally accounting models analysis. We next discuss each
classification.
The classification of research type revealed a disparity between the number of studies
we considered more scientific, offering some sort of validation, and the less scientific
studies based, for example, on arguments and experience reports. We suggest focusing
on the 12 studies classified as Solution Proposals and investigating whether these studies
have evolved or whether advances along their lines of inquiry would be possible.
Utilization of the classification of contribution type depends on what the researchers
aims, because he can take advantage whatever contribution. When dealing the types of
contributions which yielded the fewest results (method and technique), any new proposal
is likely to be unique. Working with the types of contributions which yielded more results
(model and framework), the researcher can use these proposals as inputs to build new
ones.
The relationship between research types and research questions can also be used to
identify research opportunities. First, it must be emphasized that RQ1 (accounting taxonomy) and RQ2 (accounting models) restricted the search for papers to cloud computing,
while RQ3 (pricing schemes) and RQ4 (SLAs) also included grid computing. Certainly,
this difference influenced the questions results but also provided more satisfactory outputs.
In the future, we could expand the scope of RQ1 and RQ2 to include grid computing and
see what could be relevant for cloud computing. We can also conclude that the research
types Validation Research and Evaluation Research proved be immature for application
to RQ1 (accounting taxonomy) and RQ4 (SLAs). In RQ1, only one paper was found,
and it focused solely on introducing and not validating the taxonomy. For the same
reason, RQ4 treats a specific aspect of SLA composition, and we searched for proposals
of configurations, not merely how they could be used.
Classification of the accounting models was based on seven features: standard accounting process, federated clouds, graphical user interface, SLA support, multiple
payment model, flexible charging policy specifications, and RaaS. We found that none of
the models offered all of the investigated features, and again research gaps were evident
such as the RaaS model. Considering all these results, we could start to design our
accounting framework, because the mapping study provided all the necessary information
to be filtered for what we judged necessary. From this process was born the Monext
framework.
42
2.6. DISCUSSION
First, an accounting solution needs a process, and RQ1 introduced a robust taxonomy
for this purpose. Previously, we discussed the possibility of not using all the accounting
features when constructing an accounting solution, but we decided to use all of them in
order to build a comprehensive, generic framework.
Regarding the architecture, the framework must encompass complex environments
like federated clouds, so it must also facilitate simpler structures. Given that requirement, among the five accounting models, the studies PS06 and PS23 are related to the
RESERVOIR project and addresses federated clouds. Therefore, at first, we will base our
decisions on RESERVOIR characteristics, aiming to find ideas to design the architecture
of our tool along with as the guidelines and requirements for its construction.
The study PS06 introduces eight principles (introduced in the Section 2.3.2) which
serve as a guide for what requirements an accounting system must fulfill. The study
analyzed usage scenarios presenting typical challenges for federated clouds to derive these
principles. In our solution, we will treat these principles as requirements; however, to
construct a more complete proposal, we will add and implement all the features analyzed
in Section 2.4.4, resulting in 13 requirements:
REQ-01 Location Unawareness: Account for the VMs as a service, running
locally or remotely no matter where it is running.
REQ-02 Flexible Data Format: It should be possible to include additional usage
information metrics.
REQ-03 Service Elasticity: The number of VMs underlying and fulfilling a
service can be scaled due to service elasticity. The accounting system must be
designed to handle such a scenario.
REQ-04 Service Accounting: The accounting system must be suitable for long
running services, and not limited to tasks with a limited execution time.
REQ-05 Compensations: Both usage and compensations (due to breaking SLAs)
must be accounted for.
REQ-06 Service Billing: Billing must be managed on a per service basis and not
just for each VM.
REQ-07 Adaptable Design: The accounting system must be open for modifications to cope with future changes and enhancements.
REQ-08 Complex Pricing: The function that calculates prices from the accounting
information must be able to incorporate complex pricing rules.
43
2.7. CHAPTER SUMMARY
REQ-09 Standard Accounting Process: A unified, formal accounting process

must be used.
REQ-10 SLA Support: It must be offered for the customer a mechanism to specify
a Quality of Service (QoS).
REQ-11 Multiple Payment Models: pre-paid and post-paid models must be
offered.
REQ-12 Multiple Charging Policy Specification: The accounting system administrator must be able to specify charging policies without stopping the system.
REQ-13 Resource as a Service: The economic paradigm RaaS must be supported.
2.7
Chapter Summary
This chapter presented the results of a systematic mapping study of accounting models for
cloud computing. This study was motivated by the lack of an accounting system in some
federated cloud platforms. Therefore, the main goal of this review was to determine what
issues have been studied so far to support the development of a new accounting framework
for this scenario. A secondary objective was to yield guidelines to aid researchers in
planning future research.
Therefore, following a set of strict steps, we searched 580 papers, selecting 23 studies
to answer four research questions. As its major contribution, this chapter provides an
overview of accounting in cloud computing and the specific findings as follows:
The terms pricing, accounting and billing are the most used terms in these studies.
Of these terms, billing is the most commonly used due to the influence of other
fields, such as telephony, that used the term widely before cloud computing became
a research trend.
In general, there are few studies on accounting models for cloud computing, and
the existing ones were conducted mainly in industry environment and report on
real-life experiments. Additionally, there is a need for new proposals related to
federated cloud infrastructure. Topics related to SLA and security, on the other
hand, have gained considerable attention in recent years.
Despite the many existing pricing scheme types, detailed, rather than brief, exploration of their application is needed.
44
For the composition of SLAs, some studies propose general items for the contract
(e.g., scope, penalties, restrictions), and others propose specific metrics. Studying
these results can aid in developing new solutions that combine proposals.
Finally, we filtered much data yielded by the mapping study and generated the generic
accounting framework Monext, which is presented in the next chapter.
45
3
Federated Clouds
Take risks: If you win, you will be happy; if you lose, you will be wise.
ANONYMOUS
Accounting has been applied to many areas, such as Wi-Fi connections (Detal et al.,
2009), VoIP services (Ruiz-Agundez et al., 2010a), grid services (Morariu et al., 2006),
micro-payments (Rob, 2005), packet-switched networks (Karsten et al., 2000), and more
recently cloud computing.
The systematic mapping study presented in last chapter allowed us to observe a set of
limitations among the existing accounting models. These findings in addition to eight
accounting principles generated thirteen requirements. We followed them to build a
flexible accounting framework focused on IaaS, called Monext (illustrated in Figure
3.1). In this context we consider a framework a set of processes and techniques used to
solve a problem. With Monext, private clouds or even simple IT companies may control
their computing resources under a financial aspect enabling to sell these resources to
end customers (Figure 3.2). This chapter presents such an accounting framework which
aims to manage the accounting process as a whole, from usage information recording to
payment.
46
3.1. ARCHITECTURE DESCRIPTION
Figure 3.1 Monext Requirements
Figure 3.2 Monext General View
The remainder of this chapter is structured as follows: Section 3.1 presents the Monext
architecture under five points of view (Use Case, Logical, Development, Process, and
Physical) justifying how each requirement was fulfilled; Section 3.2 shows the details
about a DSL proposal; and Section 3.3 summarizes the chapter.
3.1
Architecture Description
Software architecture deals with the design and implementation of the high-level structure
of the software. It is the result of assembling a certain number of architectural elements
in some well-chosen forms. Usually, aiming to present a software architecture it is used
some View Model through the use of architecture views. This mechanism enables to
introduce a software to different stakeholders from distinct perspectives. Aiming to
accurately describe the Monext architecture we chose the 4+1" View Model (Kruchten,
1995), since it is widely accepted by the software industry to represent application
47
architecture blueprints and explores the biggest number of architecture views, facilitating
its understanding (Systems, 2007).
Philippe Kruchten originally presented the 4+1 View Model to describe softwareintensive systems. However this approach is today an architecture style" to organize any
application architecture into five views, depicted in Figure 3.3 and listed following:
Use Case View: also called Scenarios, it describes the functionality of the system
from the perspective from the outside world.
Logical View: supports the functional requirements which the system should
provide in terms of services to its users, decomposed into a set of key abstractions.
Development View: focuses on software modules and subsystems.
Process View: captures the concurrency and synchronization aspects of the design.
Physical View: describes the mapping(s) of the software onto the hardware and
reflects its distributed aspect.
Figure 3.3 The 4+1" view model
The next sub-sections present the Monext architecture based on 4+1" View Model,
but before that, the main concepts are provided in the form of a Glossary.
3.1.1
Glossary
A glossary, also known as an vocabulary, or clavis, is an alphabetical list of terms in a

particular domain of knowledge with the definitions for those terms. The following list
explain some important terms of our scope.
48
Account: Represents the proper customer which can pay for the use of VMs.
Anomaly: It happens when something unexpected occurs, something different
from the specified in the SLA.
Charging Policy: A charging policy is a mechanism that establishes rules to
convert technical resource usage records into monetary information. In our context
means a rule which specifies how the customers will be charged.
Credentials: As the name suggests, means a set of mechanisms of identification
(passwords) used to access the VMs.
Key Performance Indicator: Means a special type of Service Level Indicator in
which focus on the performance requirement.
Payment Method: Payment employed by a customer, such as cash, check, money
order, or credit card with order or upon invoicing; also called payment type.
Payment Model: Represents how the customer desires to pay for its consumed
resources, classified in two types: pre-paid model in which he has to pay for the
consumption in advance buying credits; and post-paid model in which he pays only
after the consumption.
Service Level Agreement (SLA): A SLA is a negotiated agreement between two
parties, where one is the customer and the other is the service provider. The SLA
records are common understanding about services, priorities, responsibilities, and
warranties.
Service Level Indicator: Represents the possible metrics included by a SLA to be
monitored, for example, availability of 99%.
Usage Records: Means how much resource the customer have been used. A
unique usage record is a kind of snapshot with the amount of resource used that
time.
Virtual Machine Type: Represents a possible configuration of a Virtual Machine
(VM), including its potential of Memory, CPU and in our context, involving the
corresponding price.
3.1.2
Use Case View
As aforementioned, this view describes the system functionalities from the outside world
perspective. It contains diagrams describing what the system is supposed to do from a
black box perspective. All other views use this view to guide them. The Monext use
49
cases are presented in Figure 3.4 and its descriptions in Table 3.2. Due the limited scope
of a dissertation and our goal to focus on the core aspects of the framework we omitted
the use case flows descriptions.
Figure 3.4 Monext Use Case View
Table 3.1: General Use Cases Description

Use Case
Description
Requirements
Customer
The Customer can visualize reports including financial or usage information.
REQ-11
Inform Bill
A generated Bill may be in one of three states (OPENED, EXPIRED, PAID); when
REQ-09
Paid
created, its state is OPENED, when the bills due date is exceeded it becomes EXPIRED;
Reports
finally when the cloud provider (Admin) receives some customer payment he must
inform the corresponding Bill to change its status to PAID.
Specify
Before the system starts the resources monitoring, the Admin must specify what prices
REQ-08 REQ-14
Prices
he desires to charge for.
REQ-15
Configure
The framework must collect how much resource the customer have been used (usage
REQ-08
Collector
records) to next, charge him. The Admim must specify in what frequency the usage
Agent
records are collected.
Admin
The Admim can visualize reports related to administrative issues.
REQ-11
Reports
50
Generate
The system automatically generates bills for all active Accounts in the last day of each
REQ-08 REQ-05
Bills
month.
REQ-06
Collect
When the instances (VMs) start, usage records are collected.
REQ-03
Monitor
A prePaid model is applied in case of the Customer desires to pay a limited amount of
REQ-05 REQ-12
Pre-Paid
usage credits before use it. When the Customer uses a pre-paid model the system may
REQ-13
Accounts
terminate instances in case of credits completion.
Manage
The Customer can include, exclude and update his profile. This use case is expanded in
Customer
Figure 3.5
Usage
Records
REQ-11
Information
Manage
The Admin can include, exclude and update information about Domain Entities as for
Information
example define what are the types of VMs available. This use case is expanded in Figure
of Domain
3.5
REQ-11
Entities
Figure 3.5 Use Cases: Manage Information of Domain Entities and Manage Customer Information in an expanded way.
Table 3.2: Specific Use Cases Description

Use Case
Description
Requirements
Customer
The Customer can visualize reports including financial or usage information.
REQ-11 REQ-09
Reports
51
Manage
The Admim can include, exclude and update instance types (Virtual Machines
Virtual
configurations). At this moment the Admin may specify the price for each configuration,
Machine
similar to the Amazon AWS EC21 does by default.
REQ-11 REQ-09
Type
Manage
The Admim can include, exclude and update information about data centers which make
REQ-09 REQ-10
Data Centers
part of the federated cloud. Similar to Virtual Machine Type" here the Admin may
REQ-11
specify a tariff for each data center representing its computing potential.
Manage
The Admim can include, exclude and update charging policies. Such charging policies
REQ-08 REQ-11
Charging
are specified using a DSL presented in section 3.2
REQ-05 REQ-12
Policies
REQ-13
Manage
The Customer can include, exclude and update its desired Service Level Indicators for its
REQ-11 REQ-12
SLA
Service Level Agreement. The used metrics are BANDWIDTH (the amount of data that
REQ-05
can be transmitted along the channel during a specified period and measured in bits per
second (bps)), JITTER (measures the variability over time of the packet latency across
the network) and DELAY (time undesired to obtain a response for a requisition)
Manage
The Customer can include, exclude and update its payment information. It involves its
Payment
Payment Method (credit card, cash etc.), and its Payment Model (pre-paid/post-paid).
REQ-11 REQ-13
Information
Manage
The Customer can include, exclude and update its personal identification.
REQ-11
Personal
Information
3.1.3
Logical View
The logical view primarily supports the functional requirements in which the system
should provide in terms of services to its users. The system is decomposed into a set of
key abstractions, taken (mostly) from the problem domain, in the form of object classes.
They exploit the principles of association, abstraction, encapsulation, and inheritance.
This decomposition is not only for the sake of functional analysis, but also serves to
identify common mechanisms and design elements across the various parts of the system
in a more detailed level (Kruchten, 1995).
Monext includes two main modules depicted in Figure 3.6. The first module is called
JiTCollectorAgent. It reads periodically the VMs consumed resources into the cloud and
1 http://aws.amazon.com/pt/ec2/pricing/
52
sends this data to the second module, JiTProcessingService.
Figure 3.6 Monext General Architecture
JiTProcessingService is responsible for the central processing component that performs tasks regarding collected data treatments and generation of bills. This collected data
is called usage record and is stored appropriately after being treated; the charging policies
are also stored, to be used by charging and billing functions later. The JiTAnomalyDetector is responsible for collecting and sending network anomalies to JiTProcessingService.
An anomaly means non-compliance with a SLA. To collect network information, the
JiTAnomalyDetector is hosted in a central server but identifies in which data center the
anomaly occurred. JiTProcessingService receives and stores the anomalies for further
bill compensations so that Monext provides SLA support.
It is important to note that the solution is independent from the complexity of an IaaS
architecture, including federated clouds platforms, since the collecting points are located
inside the virtual machines and the processing points are outside the clouds.
We also used the UML 2.0 to design this view. Figure 3.7 presents the framework
architecture under a package structure. Monext architecture was based on the Accounting Process Taxonomy (Ruiz-Agundez et al., 2011) and it was divided between two
macro modules: jit_collector_agent and jit_processing_service. The jit_collector_agent
is responsible for collecting the usage records from the Virtual Machines whereas
jit_processing_service receives these usage records and charge for them. In addition,
53
jit_processing_service separates the function accounting from others due its frequent
database access characteristic. Others two packages are deployed similar to JiTCollectorAgent: jit_anomaly_detector_agent (responsible for report anomaly occurrences) and
jit_provisioner (terminates instances in case of pre-paid payment models). The next
sub-sections detail this logical view evidencing the main respective classes.
Figure 3.7 Monext Package Structure
jit_collector_agent
Figure 3.8 shows the classes of jit_collector_agent package. The accounting process
starts with collecting information. This function is performed by the class CentralMeter
and it collects information when the VM starts. CentralMeter implements the project
pattern Facade (El Maghawry and Dawood, 2010) and specific classes (CPUMeter
and MemoryMeter) treat specific resource types. In addition, the class CentralMeter
through the getUsageRecord() method provides formatted usage information and the
corresponding VM and Data Center (JiTDC). These identifiers are important because
different data centers may apply different charging policies. Finally, the usage record
will be sent by the method sendCollectedData() in Mediator class which in turn has an
instance of CentralMeter.
54
Figure 3.8 jit_collector_agent package
accounting_manager
The module jit_processing_service includes six sub-packages. The first package, accounting_manager is responsible for treats and persists usage records for subsequent charging
(Figure 3.9). The UsageRecord class keeps information regarding the resource usage, the
Account, VM and data center. A SummaryUsageRecord instance is created for each VM
at each month and grouping usage records is constantly updated until the month ends.
The SchedulerFinishInstances class in turn, monitors pre-paid Accounts and notifies the
external jit_provisioner package when the limit is exceeded. This function fulfill the
REQ-11 Multiple Payment Models requirement, since pre-paid and post-paid models
can be applied with Monext. Finally, the CommunicationServicePool works as a buffer to
effectively receive the usage records from the VMs.
Figure 3.9 accounting_manager package
55
pricing_manager
The pricing_manager package focuses on classes where the cloud administrator must
specify details about the infrastructure and its prices (Figure 3.10). The VM class
represents a virtual machine which is associated with a specific customer (Account). The
VM also keeps its resource consumption through the entity SummaryUsageRecord. It
informs its VMState (e.g. Running), the corresponding data center (JiTDC) with its price
(JiTDCRate) and a VMType. The VMType class keeps the possible VM configurations
(images). It includes individual resource type capacities with a collection of monetary
rates, in the same way as JiTDC.
Figure 3.10 pricing_manager package
charging_manager
The charging_manager package supports the domain between accounting and billing
(Figure 3.11). Here, the debit calculation is individually performed and all the necessary
information is kept in the ChargingRecord class, including: the period (month); which
considered VM/data center; the consumed resources (SummaryUsageRecord); and a
charging policy. The charging policy can be of FlexibleChargingPolicy type (specified
with VeloZ) or of DefaultChargingPolicyEnum type (hard coded charging policies). Using
the CurrentChargingPolicy class, the administrator specifies what policy is the current
one (flexible or default). The ChargingService class calculates the totalPrice field in the
ChargingRecord.
56
Figure 3.11 charging_manager package
billing_manager
The billing_manager package includes only three classes (Figure 3.12). The first, Bill,
aggregates: the calculated ChargingRecords (monetary value per VM); the Account
(customer); the period of consumption (startDate and endDate); when it was generated
(generationDate); a state (BillStateEnum); and the calculated final value (totalValue)
resulted from the charging policy execution. The second class, BillingService performs
two functions: the generation of bills for all or individual Accounts; and the payment of
a specific debit. The third class, SchedulerBillsGeneration, triggers automatically the
generation of bills at the end of each month.
Figure 3.12 billing_manager package
57
financial_clearing_manager
The financial_clearing_manager package joins simple classes related to the payment and
information detail task (Figure 3.13). When the customer is registered in the system it
must specify the PaymentInformation, considering the PaymentMethod (credit card data)
and the PaymentModel (pre-paid or post-paid). Another class, AccountingReport, is a
generic class used to format detailed financial and resource consumption information
presented to the system user.
Figure 3.13 financial_clearing_manager package
user_manager
In the user_manager package (Figure 3.14), the Account class represents the customer
which consumes the cloud resources. It encompasses: the PaymentInformation, declared
in financial_clearing_manager package; a profile with personal information (name,
contact); the corresponding Bills, VMs, SLAs (including metrics to be monitored); a state
(e.g. Active); and a VMs access credential (Credentials class).
58
Figure 3.14 user_manager package
3.1.4
Development View
The Development View focuses on the actual software module organization on the
software development environment. The subsystems are organized in a hierarchy of
layers. Each layer provides a narrow and well-defined interface to the layers above it.
It minimizes dependencies between modules and allow simple release strategies layer
by layer. The Development View takes into account internal requirements related to the
ease of development, software management, reuse or commonality, and to the constraints
imposed by the programming language. The development view serves as the basis for
requirement allocation (Kruchten, 1995).
Arguably, layering is a common best-practice pattern used by software architects
to break apart complex systems. In a layered architecture, the principal elements or
components are arranged in the form of a layered cake where each layer rests on a lower
layer. Generally, a layer represents a grouping of elements that provides related services.
A higher layer might either use services only defined by the immediate lower layer (closed
architecture) or services by all the lower layers (open architecture) (Gerber et al., 2007).
RESERVOIRs architecture is organized in three layers (presented in Section 2.3.2).
The Business Layer, forms the link between the technical system and a possible service
provider (a third entity that resells the service). The Billing Layer is responsible for
payment models management (pre/post paid), and the Accounting Layer focuses on
collecting and managing the usage data.
Although the RESERVOIR layered architecture includes some accounting functions
like Billing, it does not implement other important functions formalized by Ruiz-Agundez
et al. (2010c), like Metering, evidencing the possibility of improvement in adopting a
59
Standard Accounting Process. Thus, Monext combined the RESERVOIR layered architecture idea with such accounting process due the clear separation of responsibilities. So
it was necessary to allocate each function to its appropriate layer, taking into account their
relationships. Table 3.3 presents the functions of the standard accounting process; Figure
3.15 (a) shows the accounting process flow; Figure 3.15 (b) shows the RESERVOIR
layered architecture; and Figure 3.15 (c) represents our new proposed composition.
Table 3.3 Taxonomy of Accounting Process Ruiz-Agundez et al. (2010c)
Concept
Pricing
Function
Function of giving a price to a certain resource usage.
Metering
Collects raw information regarding the resource usage of a certain service by a consumer and its usage.
Mediation
Is intended to do a first treatment of raw technical data by transforming these metering records into a data
format that can be used for storing and further processing.
Accounting
Has the function of filtering and treat more accurately the records passed by mediation function.
Roaming
Allows using more than one provider while maintaining a formal, customer-vendor relationship just with one.
Billing
Also called of invoicing, is the process of transforming charge records into the final bill, summarizing the
charge records of a certain time period and indicating the amount of monetary units to be paid by the customer.
Charging
Is the process of calculating the cost of a resource usage, the function that translates technical values into
monetary units by applying a pricing function to the session records.
Financial
Includes activities from a commitment for a transaction to its settlement. In the case of resource accounting,
Clearing
this function implies the payment of a bill.
60
Figure 3.15 (a) Accounting Process (Ruiz-Agundez et al., 2010b); (b) RESERVOIR layered
architecture (presented in Section 2.3.2); (c) Monext in Layers, combining the Ruiz Agundezs
accounting process and the RESERVOIR layered architecture idea.
As can be seen in Figure 3.15 (c), we kept the Business Layer term but renamed
Billing Layer as the Processing Layer and the Accounting Layer as the Collector Layer.
It made more sense to group those functions with processing characteristics separately
from those functions with low level aspects related to collector actions. In addition,
we named the functions as Managers, emphasizing that they transformed into system
components. Lastly, we split the Business Layer based on two actors: Admin can specify
new charging policies and other system configurations; the Customer can register his
desires related to SLAs as well as access detailed reports. Therefore the Monext was
designed based on this layered architecture style and implementing the Ruiz Agundezs
accounting process, fulfilling the REQ-09 Standard Accounting Process requirement.
Such a strategy enabled us to build an uncoupling solution.
61
3.1.5
Process View
The process view, or process architecture, describes the view of the architecture that
includes running processes and instantiated objects that exist in the system. It describes
important concurrency and synchronization issues. Describes how the run-time system is
structured as a set of elements that have run-time behaviour and interactions. Run-time
structure often bears little resemblance to the code structure. Such view is useful for
thinking about run-time system quality attributes, such as performance and reliability
(Kruchten, 1995). This section complements the previous ones, since it presents the
main framework components JiTCollectorAgent and JiTProcessingService, focusing on
a run-time perspective.
JiTCollectorAgent
VM migration is an inherent characteristic of virtualization and cloud computing. Looking
into this aspect, Monext encompassed such characteristics as collecting usage information
from inside the VM through an agent.
This agent enables the proper machine to inform its consumption. Using percentage
as a unit of measure the agent capture the usage information called usage records. So, it
is stored and processed by the JiTProcessingService, outside the infrastructure or even the
cloud. We called this approach a Remote Collecting Strategy. Since it does not require
complex deployment, this strategy enables charging from both, virtual and physical
machines even in small companies.
Such an option was adopted because it was previously used by Narayan et al. (2012) in
a similar way and attends to the VMs migration, running locally or remotely. Thus, a VM
could migrate even between data centers, making the Remote Collecting Strategy more
appropriate. Using this approach, the REQ-01 Location Unawareness requirement was
attended which says that Accounting must be for the VMs as a service, running locally
or remotely no matter where it is running".
The JiTCollectorAgent was built using Java 6 and the Hyperic SIGAR API 2 to collect
the usage information. The Hyperics System Information Gatherer (SIGAR) provides
a couple of possible metrics like system memory, swap, CPU, load average, uptime,
and network information. However, we focused on collecting only two traditional and
main hardware metrics (memory and CPU) for this Master research, but it is included
as a future work to include other metrics. Next, we provide this information as total
2 http://www.hyperic.com/products/sigar/
62
percentage captured in each second or in a configurable frequency. In this way, merging

the remote collector feature with this API it was possible to solve the REQ-02 Flexible
Data Format requirement which notes that It should be possible to include additional
usage information metrics". Thus the agent can be evolved to also monitor applications
and catch other metrics.
The communication between JiTCollectorAgent and JiTProcessingService utilizes
the Advanced Message Queuing Protocol (AMQP)3 . The organizations JP Morgan,
iMatix, Cisco, IONA, Novell, Redhat jointly developed such protocol, which is an open
standard on application layer protocol. The goal is to provide real-time, low-cost, reliable
middleware communication. It defines the network communication rules and services
built on top of it. AMQP protocol is widely used in the financial industry to publish
and subscribe information. AMQP implementations include OpenAMQP, Apache Qpid,
RabbitMQ and other related products (Xiong and Fu, 2011).
We chose the message broker RabbitMQ4 , since it is a robust messaging for applications; runs on all major operating systems; and is open source. RabbitMQ enables
developers of messaging solutions to benefit not only from AMQP, but also from one of
the most proven systems in use, the Open Telecommunication Platform (OTP). OTP is
used by telecommunications companies to manage switching exchanges for voice calls,
VoIP, and now video. These systems are designed never to go down even when handling
vast user loads. As such systems cannot be taken offline, they have to be extremely flexible; for instance, it must be possible to hot deploy features and fixes whilst managing
consistent user SLAs (RabbitMQ, 2007).
The main idea of RabbitMQ is simple: it accepts and forwards messages. A program
that sends messages is a Producer. A Queue is the name for a mailbox and it lives
inside RabbitMQ. Although messages flow through RabbitMQ and applications, they
can be stored only inside a queue. Besides it can be used an entity called Exchange
which distributes message copies to specific queues using rules named bindings. Finally
a Consumer is a program that waits to receive messages (RabbitMQ, 2012) (Figure 3.16).
3 http://www.amqp.org/
4 http://www.rabbitmq.com
63
Figure 3.16 RabbitMQ Overview
The use of RabbitMQ allowed the JiTCollectorAgent to send messages from the VM
to specific consumers implemented by a CommunicationService class. To mitigate the
overload of receiving messages on the server side, there is a CommunicationService
running as a Java Thread for each Account, representing a customer in the system that
only receives messages from VMs it owns. It is important to mention that this strategy is
used to receive both, usage records and network anomalies (for SLA compensations), as
depicted in Figure 3.17.
Figure 3.17 Monext and RabbitMQ
JiTProcessingService
As previously mentioned, the JiTProcessingService module treats all the accounting
process functions related to formatting and filtering the collected raw data and generate
bills. To keep the architecture consistent, this module was designed following such a
process. Figure 3.18 shows the main entities and their acronyms. It illustrates generally
how we implemented the core functionalities. Monext is a system wherein service
providers can sell computational resources to final customers, which in turn creates a
register with a specific access policy called an Account.
The first task performed by the administrator before turning on" the accounting
system is to specify the possible Virtual Machine Types (VMT) with their capacity and
corresponding monetary rates. This is similar to the Amazon AWS EC25 , which offers
5 http://aws.amazon.com
64
Figure 3.18 Monext Accounting Process
different instance configurations. After this pricing configuration, one Account can create
as many VMs as necessary, composing an elastic service.
This idea addresses the REQ-03 Service Elasticity requirement which says that The
number of VMs underlying and fulfilling a service can scale due to service elasticity.
The accounting system must be designed to handle such scenario", because with Monext
the number of VMs underlying a service can change dynamically, and the accounting
system does not care about where the VM is running. Only if the VM is active, its
JiTCollectorAgent can send usage records. As the system performs constant collecting,
the accounting task is also constant and not time frame dependent enabling long running
services. It fulfills the REQ-04 Service Accounting requirement which advocates that
The accounting system must be suitable for long running services, and not limited to tasks
with a limited execution time".
These usage records (UR) are accounted from anywhere (i.e., any data center). However, as mentioned in Section 3.1.5, there is a Java Thread acting as a subscriber that
receives only the UR owned by its specific Account. This way, when an UR is received,
it is immediately added to an entity called Summary Usage Record (SUR). A SUR is
created for each VM at each month and is constantly updated until the month ends. SUR
allows the use of not only PostPaid but also a PrePaid payment model, since SUR always
keeps the current amount of consumed resources.
When the current month ends, and the functions pricing, metering, mediator, and
65
accounting have been executed, then it is time to calculate the customers debits and
generate the bills automatically. Accordingly, in the charging phase, a Charging Record
(CR) is created. The CR represents the calculated monetary data about one specific VMs
consumption for the current month, considering four items as input.
The first item is the SUR, which provides how much data or load were consumed.
The second, the Current Charging Policy (CCP), previously written in VeloZ, represents
the current policy. The third, VMT, contains the price of that VM configuration. Finally, some compensation is included in case of SLA violations, fulfilling the REQ-05
Compensations and requirement which says: Both usage and compensations (due to
breaking SLAs) must be accounted for". The SLAs are previously specified to each
customer when they are registered, fulfilling the REQ-10 SLA Support requirement
which says: Must be offered for the customer a mechanism to specify a Quality of
Service (QoS)".
With the obtained CR, the next step is to effectively generate the bills in the billing
phase. The REQ-06 Service Billing requirement notes that billing must be managed
on a per service basis and not just for each VM. So one bill encompasses all consumed
services in the month; all CR has to be added to the Bill. A bill has three states (opened,
expired, and paid), and any issue related to payment is resolved in the financial clearing
phase. Roaming is next to billing, meaning that the customer can consume resources
from multiple providers, but it is billed transparently through one provider.
In terms of technology used to implement this module, three aspects were observed.
The first one was robustness. We developed a solution to deal with financial information. It was important to be fault tolerant and provide an advanced suite test tool. The
second aspect was also appointed by the Mapping Study as one limitation in the existing
accounting systems related to the REQ-11 Graphical User Interface requirement. The
third one was related to the REQ-07 Adaptable Design requirement which says: an
accounting system must be open for modifications to cope with future changes and enhancements". The Grails6 framework was chosen to mitigate these respectively problems
as Grails provides such functionalities through an advanced suite test tool, a web-based
interface and a Model-View-Controller (MVC) organization. The MVC architecture style
separates software into models representing core functionality, views which display the
models to the user, and controllers which let the user change the models (Mahemoff and
Johnston, 1999). Figures 3.19 and 3.20 present two web page screenshots.
6 http://grails.org/
66
Figure 3.19 Monext - Homepage
Figure 3.20 Monext - Charging Policy Specification Page
3.1.6
Physical View
The physical view is concerned with the topology of software components of the physical
layer, as well as the physical connections between these components. This view is also
known as the deployment view. It encompasses the nodes that form the systems hardware
topology on which the system executes; it focuses on distribution, communication and
67
provisioning. The software executes on a network of computers, or processing nodes.

The various elements such as processes, tasks and objects need to be mapped to the nodes
on which they execute (Systems, 2007).
Figure 3.21 presents such perspective of Monext. There are three types of elements
on this diagram: The first represents the nodes, called here as Devices which represents
the proper machines where the software components execute; The second, the Artifacts
represent these software components; and the third is responsible for running the applications called ExecutionEnvironment in which must be a Java container to manage the web
application. From left to right, the users Customer and the framework Administrator can
access the web application (JiTProcessingService) through the HTTP protocol, whereas
a Load Balancer may be configured to distribute these accesses between a cluster of
App Servers. The application needs a database, and the MySQL Server was used as an
example. Finally, the component JiTCollectorAgent must be installed in a VM Image
before to be started, configuring to whom it belongs (which Account) and the frequency
to send usage records.
Figure 3.21 Monext Deployment View
The Appendix A present how to deploy the JiTProcessingService and JiTCollectorAgent respectively, and all artifacts can be downloaded through the URL: http:
//cin.ufpe.br/~faps/monext/.
Next section introduces the details about the DSL VeloZ and what functionalities it
offers illustrated with examples.
68
3.2. VELOZ
3.2
VeloZ
The principle R8 - Complex Pricing of RESERVOIR project says that the function that
calculate prices from the accounting information must be able to incorporate complex
pricing rules". However, for the best of our knowledge there is not a cloud accounting
solution which offers a programming language to leverage this functionality. For this
reason we stated the requirement REQ-12 Multiple Charging Policy Specification and
proposed the VeloZ (Monext-Charging Policy Language), a programming language for
charging policies specifications.
Charging policies are mechanisms that establish rules to convert technical resource
usage records into monetary information. It is a formula or algorithm used every time
when generating a bill. VeloZ allows IaaS providers to specify its own charging policies
and control its consumption in a financial aspect. However, whether the company does
not want to configure it, the Monext framework provides two default hard coded charging
policies:
VOLUME_TIME: The price is calculated using the amount of data in terms of
average resource usage and time consumption;
VOLUME_TIME_LOCATION: The price is calculated using the amount of data
in terms of average resource usage, time consumption, and virtual machine location.
The administrator by default may choose these two charging policies. However,
these two possibilities are not enough when the provider requires more adaptability or
ad hoc" policies. Therefore, in order to offer more flexibility for a cloud provider, the
Monext framework introduces the VeloZ, which is a Domain Specific Language (DSL)
that enables cloud administrators to write charging policies.
According to Backus (1978), DSLs are programming languages or executable specification languages that offer through appropriate notations and abstractions expressive
power focused on, and usually restricted to, a particular problem domain. VeloZ is an
executable language that provides default and pre-calculated variables, proper to the
IaaS accounting domain. VeloZ is based on the expression paradigm. An expression
in a programming language is a combination of explicit values, constants, variables,
operators, and functions. These elements are interpreted according to the particular rules
of precedence and in association with a particular programming language that computes
and then produces another value.
Such a process, as mathematical expressions, is called evaluation. The value can be
of several types, such as numerical, string, and logical. For example, 2+3 is an arithmetic
69
3.2. VELOZ
and a programming expression which results in 5. A variable is an expression because

it denotes a value in memory, so y+6 is also an expression. In general, an expression is
composed of a single entity (constant, variable, etc.) or even of an operator (such as +,
cons, etc.), applied to a number of arguments (or operands) which are also expressions
(Gabbrielli and Martini, 2010).
Aiming to clarify how VeloZ works, Code 3.1 expresses its specification by the
standard BNF (Backus Naur form) grammar notation (Backus, 1978). The grammar of a
language is usually presented with rules that define a precise syntax.
Code 3.1 VeloZ by Backus Naur Form
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
ChagingPolicy ::= Expression

E x p r e s s i o n : : = V a l u e | UnaryExp | B i n a r y E x p | I d
Value : : = ConcreteValue
ConcreteValue : : = I n t e g e r V a l u e | FloatValue | BooleanValue
UnaryExp : : = "not" E x p r e s s i o n
BinaryExp : : =
E x p r e s s i o n "+" E x p r e s s i o n
| E x p r e s s i o n "-" E x p r e s s i o n
| E x p r e s s i o n "*" E x p r e s s i o n
| E x p r e s s i o n "/" E x p r e s s i o n
| E x p r e s s i o n "and" E x p r e s s i o n
| E x p r e s s i o n "or" E x p r e s s i o n
| E x p r e s s i o n "==" E x p r e s s i o n
| E x p r e s s i o n "++" E x p r e s s i o n
DeclarationExp ::=
"dec" "{" L i s t I d "}" "in" "calc" "{" V a r i a b l e D e c l a r a t i o n "}" "in" "total"
"{" E x p r e s s i o n "}"
V a r i a b l e D e c l a r a t i o n : : = I d "=" E x p r e s s i o n |
V a r i a b l e D e c l a r a t i o n "," V a r i a b l e D e c l a r a t i o n
L i s t I d : : = I d | Id , I d
A charging policy is an expression that can be a value, an expression (unary/binary),

or a variable. In this language, we consider only concrete values such as integers,
floats, or Booleans. As examples of unary expressions, we consider exchange signs
of integers or the negation of a Boolean. The binary expressions include arithmetic
operations, conjunction, and logical disjunction, as all types of expressions. Finally the
most significant part of this BNF is DeclarationExp" which establishes the program
structure expressed by three blocks of code, as follows:
70
3.2. VELOZ
Figure 3.22 VeloZ Structure
1. dec {ListId} in: Firstly, dec" and in" are reserved words that limit the declaration
scope of pre calculated variables. The administrator specifies a list of identifications
(ListId) chosen between default variables calculated by the system and previously
defined separated by comma, e.g., dec {cpu_rate, mem_rate} in. Only variables
correctly written will be accepted by the compiler, and values cannot be assigned
to these variables. A list of some default variables is shown in Table 3.4.
The default variables declared inside the dec" block are divided into three types.
The first one is called the Average Type, and these variables indicate the total
average related to a specific resource for a period of time (e.g., a month). The
second group is named Volume Type and reflects the amount of data in terms of
consumed resources, indicating the total sum of usage data logged. Finally, the
Monetary Type, in this case, each Virtual Machine Type has a configuration to
which is assigned a monetary rate related to the potential for each resource type.
2. calc {VariableDeclaration} in: It is responsible for the computing procedures, using the variables defined in the dec" block and new temporary variables. It enables
expression assignments separated by comma, e.g., calc {myVar = location_rate +
mem_rate} in.
3. total {Expression}: Whereas the previous blocks had temporary declarations and
calculations, the total" block receives the variables used to compound the final rule
of charging. For example, if the administrator desires only to charge for memory
consumption, it can be specified as follows: total {mem_sum * mem_rate}.
According to the economic model Resource as a Service (Ben-Yehuda et al., 2012)
renting a fixed combination of cloud resources cannot and does not reflect the interests of
clients. First, as the sizes of servers are likely to continue increasing hundreds of cores
71
3.2. VELOZ
Table 3.4 Default Charging Variables

Variable
Description
cpu_avg
CPU average consumption
mem_avg
Memory average consumption
cpu_sum
CPU consumption volume
mem_sum
Memory consumption volume
used_time
Total used time since the VM started
cpu_rate
Address the CPU price
mem_rate
Address the Memory price
location_rate
Rate assigned to where the VM is running
time_rate
Rate assigned to used time
compensation
Compensation due to SLA violations
and hundreds of gigabytes of memory per server in a few years an entire server equivalent
may be too large for some customer needs. Second, selling a fixed combination of
resources is only efficient when the load customers need is known in advance and remains
strictly constant. As neither condition is likely, the ability to dynamically mix-and-match
different amounts of compute, memory, and I/O resources would probably be highly
valued by clients. By extrapolation, compute, memory, and I/O resources will be rented
and charged for in dynamically changing amounts and not in fixed bundles. The resources
available for rent include CPU, memory, and I/O resources. CPU capacity is sold on a
hardware-thread basis, or even as the number of cycles per unit of time; Memory is sold
on the basis of memory frames; and I/O is sold on the basis of bandwidth.
Using VeloZ, the cloud provider may choose to charge for one or a combination of
resource types. It is possible to specify a different price for each resource type trying
to fulfill the REQ-13 Resource as a Service requirement, because if a customer asks
for more Memory, VeloZ enable the provider to charge for this increased capacity in
an individual way. However, instead of heterogeneous measure types (cycles, memory
frames or bandwidth) JiTCollectorAgent captures and VeloZ uses the relative percentage
of total consumed resources. With such functionality, our solution follows the economic
model Resource as a Service. It provides a different price for each resource type, and
to the best of our knowledge has not been implemented by accounting models thus far.
Table 3.5 presents some valid examples of charging policies.
72
3.2. VELOZ
Table 3.5 Charging Policy Examples

Description
One second using
100% of CPU
capacity costs
Charging Policy
dec { cpu_avg, used_time, cpu_rate} in
calc {fixed_time = 1, fixed_cpu_avg = 100} in
total { cpu_rate/((fixed_time/used_time)*(fixed_cpu_avg/cpu_avg)) }
cpu_rate
(pre-defined in $)
One second using
100% of Memory
capacity costs
mem_rate
dec { mem_avg, used_time, mem_rate} in

calc {fixed_time = 1, fixed_mem_avg = 100} in
total {
mem_rate/((fixed_time/used_time)*(fixed_mem_avg/mem_avg)) }
(pre-defined in $)
One hour (3600
seconds) of use
costs time_rate
dec { time_rate, used_time} in

calc {fixed_time = 3600} in
total { (used_time * time_rate)/fixed_time }
(pre-defined in $)
The first policy considers only CPU, the second only memory, and the third only Time
consumption. In each charging policy the resource has its pre-defined individual price
(cpu_rate, mem_rate, time_rate) and not charged with fixed bundles as, for example, the
Amazon AWS EC27 does by default. However, it is possible, since the third policy in
Table 3.5 considers only the total time of consumption using as basis one hour. So, the
cloud administrator just has to set a price (time_rate variable) for each VM Type as same
as Amazon AWS EC2 uses different instance types (Small, Medium, Large, Extra Large
etc.) (Figure 3.23).
Figure 3.23 Amazon AWS - On Demand Instance Types Pricing (Amazon-AWS, 2012)
7 http://aws.amazon.com/pt/ec2/pricing/
73
3.3. CHAPTER CONCLUSION
3.3
Chapter Conclusion
This chapter introduced Monext, an accounting framework which supports charging of

IaaS. It was based on the results of a systematic mapping study focused on accounting
models. Using these results, VeloZ, a domain specific language for charging policy specification, was developed. This chapter presented the architectural framework following
the 4+1 approach (Kruchten, 1995). In addition, how VeloZ works was detailed and
illustrated with examples.
Using VeloZ, cloud administrators can specify charging policies, instead of depending
on programmers to do it for them. In addition, it is possible to apply one different
charging policy for each data center in a federated cloud. Thus, the prices could vary
according to the resource location.
We believe that the use of a standard accounting process (Ruiz-Agundez et al., 2010c)
enables Monext be better understood and extended by other solutions. Applying the 13
requirements and remote collecting strategy made it possible to perform both complex
federated cloud platforms and small data center management.
We judge Monext to be an interesting solution because it explored the union of
existing accounting model and features to mitigate their limitations. The framework offers
different reports through a web-based interface and provides SLA support, among others
benefits. The next chapter presents the results of an experiment performed jointly with
Monext and a new federated cloud platform, JiTCloud, to see whether the requirements
could be applied effectively in a real-life environment.
74
4
A Preliminary Case Study
Nothing is particularly hard if you divide it into small jobs.

HENRY FORD (1863-1947)
As described in the previous chapters, Monext framework was developed to attend a

specific area of cloud computing, known as federated clouds. Thus, Monext followed a
set of requirements to fulfil such objective, but a validation is needed to provide evidences
that the solution works. In this context, an experimental study was undertaken to evaluate
the feasibility of the tool. We used as case study one of the four federated cloud platforms
evidenced by the motivation of this work, called JiTCloud.
The remainder of this chapter is organized as follows: Section 4.1 presents the
definition of the experiment; Section 4.2 describes the planning of the experiment;
Section 4.3 presents how the case studywas performed; the interpretation of the results
are presented in Section 4.4; and finally, Section 4.5 concludes this chapter.
4.1
Definition
The first activity is called Definition. The foundations of the case study are determined,
presenting why the case study will be conducted. Furthermore, the objective and goals of
the case study must be defined.
4.1.1
Goal
A goal is suggested by the problem to be solved. The goal of this evaluation is summarized
following:
75
4.2. PLANNING
The objective of this experimental study is to analyze the Monext framework

in order to evaluate its feasibility for the JiTCloud platform from the
researchers point of view.
4.1.2
Questions
Flexibility:
Q1. Can the Monext framework charge for different resource types at the
same time?
Efficiency:
Q2. Can the Monext framework handle the scalability of VMs?
Q3. Can the Monext framework charge for long-running services?
Reliability:
Q4. Can the Monext framework calculate bills considering all the customer
usage?
Q5. Can the Monext framework handle anomalies in calculating bills and
considering compensation?
4.2
Planning
After the definition of the case study, the planning phase should prepare how the case
study will be conducted.
4.2.1
Context Selection: JiTCloud Project
As aforementioned we have chosen as a case study the JiTCloud platform. The JiTCloud
is a result from the research of a group which involved eighteen Brazilian universities,
sponsored by the Centro de Pesquisa e Desenvolvimento em Tecnologias Digitais para
Informao e Comunicao (CTIC)1 . It is a federated cloud platform which proposal
addresses an alternative to build computational infrastructure to support cloud computing
which is not based on traditional capacity planning. Inspired by the Toyotas Just in Time
1 http://www.ctic.rnp.br/web/ctic/
76
4.2. PLANNING
Philosophy (JiT) (Toyota, 2012), it introduces the concept of Just in Time Clouds for
representing a new service category in which the provider (here named JiTProvider")
allocates resources only when demanded and until there is use for them. Built upon
amortized resources from a supply chain.
Amortized resource refers to the resource installed and not used to support for example
the operation of peak demand. A JiTProvider is a public cloud computing provider that
instead of assembling and maintaining a structure of data centers for supporting its own
service makes use of a federation of low scale amortized resources already existing
into private contexts. Unlike proxies of conventional providers of cloud computing (e.g.
rightscale.com), a JiTProvider does not represent any public cloud provider, but acts as a
legitimate and fully autonomous provider that takes advantage of resources that would be
irretrievably wasted without its intervention.
Each resource pool amortized over a given environment represents an abstraction
called Just in Time Data Center (JiT DC). Each JiT DC brings some amount of resources
with certain characteristics and capabilities. The JiT DC resources must be raised and
finely graded by the JiT Provider. Depending on the type, it can be specialized as a JiT VM
to represent a specific VM within a specific JiT DC. Among the general characteristics of
a JiT DC, there is the level of service supported by its resources and conditions negotiated
or arbitrated by the owner for its use. A Just in Time Cloud is illustrated in Figure 4.1).
Figure 4.1 Composition of a JiT Cloud (Costa et al., 2010)
The JiT Resources that are integrating in JiT Data Centers can be classified into
dedicated and non-dedicated types. Dedicated is when they are fully allocated for use by
the JiT Provider for a certain period of time. Non-dedicated is when their assignment is
partial, being shared in an opportunistic fashion. It has the possibility of being reclaimed
by their corresponding owners without any prior warning. In the first case, there are
reservation and levels of availability traded. In the second case, the resources are volatile
and can suffer from failures or relocation at any time. In both cases, the provider needs to
77
4.2. PLANNING
deal with migration issues and take into account the necessary time to commission and
decommission the resources.
In a deployment view, depicted in Figure 4.2, the JiTCloud solution is divided into
three modules, or artifacts: CloudClient, CloudMiddleware, and JiTDC. All the three
components were developed using Java, and deploying them requires uncompressing
the jar files and configuring some properties related to credentials. The CloudClient
gives the customer access to the cloud access. Through it, the customer can start and
terminate VM instances and monitor details of his usage through a set of commands. The
CloudMiddleware performs all the control, processing, and load balancing which directs
the requisitions to the JiTDCs. The JiTDC component is deployed in a data center which
must have installed an Eucalyptus2 Instance, a software platform for public and private
IaaS clouds. Finally, the JiTCloud project aims to use its solution to integrate data centers
of Brazilian universities.
Figure 4.2 JiTCloud Deployment View
JiTCloud and Monext Integration

This subsection details the integration of the Monext framework with the JiTCloud
platform. As mentioned, the CloudMiddleware of the JiTCloud works as a central
processor. This component contains the sub-modules responsible for security, monitoring,
and provisioning, while Monext provides the accounting system. The CloudMiddleware
is a completely decoupled module and offers a robust API which enables changing its
sub-modules and their respective functionalities. Thus, Monext was adapted to follow
such an API but had to be separated from its previous structure organized with the ModelView-Controller architecture style, retaining only the Model part. This separation was
2 http://www.eucalyptus.com/
78
4.2. PLANNING
necessary, because the sub-modules are not web applications but merely components.
The client access (View) is provided by the proper JiTCloud.
The CloudMiddeware uses the design pattern Dependency Injection, which allows
removing hard-coded dependencies and changing them at either run-time or compile-time.
Therefore, after we generated a .jar file, we deployed it inside the CloudMiddleware.
Another necessary task was to create a separate database for the component Monext due its
peculiarities of the wide range of saved objects (e.g., usage records). This task motivated
us to externalize some variables into a properties file in order to easily change databases
and specify other configurations. The properties are loaded when the CloudMiddleware
starts. Figure 4.1 shows such properties.
Table 4.1 Monext Configuration Properties
Properties
Description
amqp.host
amqp.port
amqp.ssl_port amqp.username
amqp.password
amqp.exchange.name
amqp.anomaly.exchange.name
These properties refer to the access credentials to the RabbitMQ broker (host,
port, username, passoword). The amqp.exchange.name refers to a specific name
for the exchange of messages containing usage records (discussed in Section
3.1.5). The property amqp.anomaly.exchange.name similarly, refers to the
exchange specific to receive the anomalies.
schedule.billing.time.day
schedule.billing.time.hour
schedule.billing.time.minute
This group defines the day, hour and minute that the bills are generated
automatically every month.
schedule.terminate.vm.hour
schedule.terminate.vm.minute
This group defines the hour and minute that the boundaries of pre-paid
Accounts will be checked to possibly terminate the VMs when credits are
exceeded.
hibernate.connection.driver_class
hibernate.dialect
hibernate.connection.url
hibernate.connection.username
hibernate.connection.password
The third set of properties specifies credentials to access a relational database.

This brings great flexibility for choosing it.
sla.support
pre.paid.model.support
The variable sla.support refers to whether the Administrator desires or not the
charging considering compensations whereas the variable
pre.paid.model.support refers to whether the Administrator desires or not to
enable the schedule which terminate instances automatically in case of pre-paid
payment models.
4.2.2
Evaluation Design
In this phase, the experiments to be executed are detailed, including how many objects
and factors they include. More specifically, we determine the details of the environment
configuration and what charging policies will be addressed.
79
4.2. PLANNING
The case study used a JiTCloud instance composed of two data centers at Brazilian
universities, UFCG and IFPB. These data centers are distributed geographically and
configured with the Eucalyptus solution. To create a more distributed configuration, we
hosted the CloudMiddleware component in the Amazon EC2 service, with a medium"
VM (3.75 GiB mem., 2 EC2 computer, and 410 GB of storage). Finally, the CloudClient
was configured in a personal computer, because it provides a simple access interface and
does not require much computing capacity. Figure 4.3 presents this environment.
Figure 4.3 Experimental Environment
We executed three scenarios, as follows.

Treatment 1 (T1): Successive generations of bills for only one VM using the
charging policy depicted in Table 4.2 that considers two aspects: total CPU volume
(cpu_sum variable) and total time used (used_time variable). For the price of
resources, the dec" block shows the cpu_rate variable. The calc" block sets the
auxiliary variables fixed_time (in seconds) and fixed_cpu_sum (in percentage);
the calculation base was one hour (3,600 seconds) and 2,000 total CPU usage (in
percentage sum). The total" block reports the price for both CPU usage and time.
Treatment 2 (T2): Generation of only one bill after some time of consumption for
a group of VMs using the charging policy depicted in Table 4.2(charging policy
CP2) that considers the CPU, memory, disk, and time resources.
Treatment 3 (T3): Generation of only one bill after some time of consumption for
a group of VMs using the charging policy depicted in Table 4.2 (charging policy
CP3) that considers the time resource and SLA compensation.
To better explain how the charging policy CP1 presented in Table 4.2 works, Figure
4.4 displays a simplified explanation of the total calculation. Such explanation is sufficient
to understand the others CP2 and CP3 charging policies.
80
4.3. OPERATION
Table 4.2 Evaluated Charging Policies

Id
Charging Policy
CP1
dec { cpu_sum, used_time, cpu_rate } in

calc { fixed_time = 3600, fixed_cpu_sum = 2000 } in
total {
cpu_rate/((fixed_cpu_sum/cpu_sum)*(fixed_time/used_time))
}
CP2
dec { cpu_sum, cpu_rate, mem_sum, mem_rate, disk_sum, disk_rate, used_time } in

calc { fixed_cpu_sum = 400000, fixed_mem_sum = 400000, fixed_disk_sum = 400000, fixed_time = 3600
} in
total {
cpu_rate/((fixed_cpu_sum/cpu_sum)*(fixed_time/used_time)) +
mem_rate/((fixed_mem_sum/mem_sum)*(fixed_time/used_time)) +
disk_rate/((fixed_disk_sum/disk_sum)*(fixed_time/used_time))
}
CP3
dec { time_rate, used_time } in

calc { fixed_time = 3600 } in
total {
((used_time * time_rate)/ fixed_time) - compensation
}
Figure 4.4 Charging Policy A Explanation
At this stage, we did not specify how many bills would be generated or how many VMs
initialized, because we did not know the level of autonomy offered by the universities
data centers.
4.3
Operation
When a case study has been designed and planned it must be carried out in order to collect
the data that should be analyzed. This is what we mean with the operation of a case study.
In the operational phase of a case study, the treatments, depicted in Section 4.2.2 are
applied.
The operational phase of this case study consists of three steps: preparation where
81
4.3. OPERATION
the environment and specific details are prepared, execution, where the treatments are
effectively executed and the data is collected, and data validation where the collected
data is validated.
4.3.1
Preparation
Database: We used the database MySQL to retain the Monext data. A cleaned
database scheme was created on the CloudMiddlewares server.
JiTCollectorAgent: We prepared an Ubuntu Image3 to generate VMs Instances
with the following properties: 1GHz of CPU, 2GB of Memory and 100GB of Disk.
Then, we installed the JiTCollectorAgent inside this VM image. However, to simulate the resources usage, we also prepared a mechanism to vary the consumption.
We used Stress4 , a deliberately simple workload generator for POSIX systems. It
imposes a configurable amount of CPU, memory, I/O, and disk stress on the system.
It is written in C, and is free software licensed. Stress runs for a specified amount
of time, so we developed a script to execute the Stress during random periods in
loop.
AMQP Broker: We configured a RabbitMQ server on UFCG Universitys infrastructure to require some level of network quality in order to exchange the messages
between the JiTCollectorAgent and the JiTProcessingService.
Pricing: We specify the prices using properties files. The arbitrary prices used by
the configured Image were:
Treatment T1: cpu_rate = $0.5
Treatments T2 and T3: cpu_rate = $0.05, mem_rate = $0.07, disk_rate =
$0.06
SLA Specification: To control the result variability, we manually generated fake
anomalies and sent them to the JiTProcessingService throughout the AMQP communication. However, we illustrate an SLA specification which we could use in
the case study (Figure 4.5).
3 http://uec-images.ubuntu.com/
4 http://weather.ou.edu/
apw/projects/stress/
82
4.4. INTERPRETATION
Figure 4.5 SLA Example
4.3.2
Execution
The case study was conducted in January 2013. The first action we performed was to
configure the CloudMiddleware to distribute the VMs equally among the data centers.
Next, we performed the three treatments described in Section 4.2.2. The additional
information about them are described following.
Treatment 1 (T1): This treatment was performed for only one VM. We captured
usage records over eight hours while generating 16 bills at half-hour intervals,
simulating a monthly generation. The charging policy used for this treatment was
described in Figure 4.4.
Treatment 2 (T2): One bill for a group of 30 VMs was generated after eight hours.
The charging policy used for this treatment was introduced in Table 4.2 (charging
policy CP2).
Treatment 3 (T3): One bill for a group of 30 VMs was generated after eight hours.
The charging policy used for this treatment was introduced by Table 4.2 (charging
policy CP3).
4.3.3
Data Validation
In this phase, all data are checked in order to verify whether the data are reasonable and
it has been collected correctly. All data was collected correctly and none VM presented
malfunctioning.
4.4
Interpretation
After collecting experimental data in the operation phase, we aim to draw valid conclusions from it, and to do so, we must interpret the experimental data (Wohlin et al., 2000).
In this phase, the quantitative and qualitative data were analyzed.
83
4.4. INTERPRETATION
4.4.1
Analysis for Each Question
Question 1
Question 1 asked whether the Monext framework could charge for different resource
types at the same time. Thus, we verified whether two considered resource types by a
charging policy effectively corroborated for the bill value. T1 supported this analysis. We
captured usage records for one VM over eight hours while generating 16 bills in half-hour
intervals, simulating a monthly generation. This charging policy which considers CPU
and time was introduced by Table 4.2 (charging policy CP1) in Section 4.2.2.
Therefore, we compiled the results, remaining three groups of data: the sum of CPU
usage (variable cpu_sum of VeloZ); time consumed (variable used_time of VeloZ); and
total monetary value, which we called price. We plotted these results on two charts
depicted in Figures 4.6(a) and 4.6(b).
60
50
30000
50
40
15000
30
10000
20
5000
10
0
1
10 11 12 13 14 15 16
bills
(a) Variation of CPU vs. Price
25000
40
20000
30
15000
20
10000
Charged Price ($)
35000
20000
price
used_time
60
Time (seconds)
25000
CPU (Sum of %)
.......
price
cpu_sum
Charged Price ($)
.......
30000
10
5000
0
0
1
10 11 12 13 14 15 16
bills
(b) Variation of Time vs. Price
Figures 4.6(a) and 4.6(b) both provide evidence of a correlation between CPU and
price and between time and price. This result indicates that both, CPU and Time were
considered by the Bills, since there is a correlation among them in the same direction.
Question 2
Question 2 asked whether the framework could handle the scalability of VMs. We
captured usage records for a group of 30 VMs over eight hours, generating only one
bill after that. The charging policy used for this treatment was introduced by Table
4.2 (charging policy CP2) in Section 4.2.2 and considers CPU, memory, disk, and time
resources. Therefore, focusing on the covariance of usage time (usage_time) and the
number of usage records (ur_number) for each VM, we obtained the chart depicted in
Figure 4.6.
84
4.4. INTERPRETATION
usage_time
ur_collected
28680
21890
28660
Usage Time (seconds)
21900
21880
28640
28620
21870
28600
21860
28580
21850
28560
21840
28540
21830
28520
28500
Number of Usage Records Collected
.......
28700
21820
1
9 11 13 15 17 19 21 23 25 27 29
virtual machines
Figure 4.6 Usage Time vs. Number of Collected Usage Records
As can be seen on the chart, the usage records number are almost equal to the used
time. This result suggests that the framework can handle the VMs scalability, but since
usage records are collected for all VMs, this case study presented a problem: There is a
high delay in receiving the usage records by JiTProcessingService. An average of 24%
of usage records were not accounted on time. We speculate this happened due to two
decisions: the geographical distribution of the components and the high frequency of
sending messages.
With components, we mean the JiTProcessingService (inside the CloudMiddleware),
the JiTCollectorAgent and the server RabbitMQ. To mitigate the delay, such components
could be reorganized. In a large scale scenario, would be hosted a CloudMiddleware in
conjunction with a server RabbitMQ for each group of close data centers, as depicted in
Figure 4.7. However such decentralization could bring other problems.
Figure 4.7 Monext Possible Configuration
We configured the JiTCollectorAgent to send usage records at a frequency of one

second. Due to the geographical distribution, it was impossible to use this frequency
in the Remote Collecting Strategy. Mihoob et al. (2010) studied this subject, analyzing
85
4.4. INTERPRETATION
how Amazon EC2 records customer usage records and found that, in some services,
Amazon collects usage records only twice by day, causing inaccurate billing. Unlike
Amazon, we aimed to provide fair, consistent billing, but a frequency of once a second
was impracticable. Therefore, we re-ran T2 with a sending frequency of ten seconds, and
the results were satisfactory, with all usage records accounted for on time.
Question 3 and Question 4
This subsection interprets the results for both Questions 3 and 4, because they use the
same output of T2.
Question 3 asked whether the Monext framework could charge for long-running
services. Table 4.3 shows details from the charging records for each VM, including VM
identification (vm_id); amount of used resources (disk_sum, mem_sum, and cpu_sum);
the (used_time_a and used_time_b); and the monetary value of each VM (cr_value). The
bill was based on the sum of all cr_values and totaled $295.01.
The time used and recorded of all the VMs were equal. Interpreting this result, we can
see that, although the VM may have a problem with network and become unable to send
the usage records, the time consumption will be accounted properly without interruption.
Thus, in the worst-case scenario, the Monext framework can charge the same way as
Amazon EC2, considering only time consumption.
The conclusion for Question 4 is very simple. This question asked whether the
Monext framework could calculate bills considering all the customers usage or, in other
words, whether all the charging records could be properly totaled in the final bill. We
manually added the column cr_value from Table 4.3, and the result was exactly equal to
$295.01.
Question 5
Question 5 asked whether the Monext framework could handle anomalies in calculating
bills and considering compensations. T3 supported this analysis. It generated only one bill
for a group of 30 VMs after eight hours using the charging policy presented in Table Table
4.2 (charging policy CP3) in Section 4.2.2 that considers time and SLA compensation.
The anomalies were generated manually, because we wanted to control the anomalies
attributes in order to better simulate a real-life utilization. Thus, we generated eight
types of anomalies: bandwidth, latency, and jitter. Each anomaly generates a specific
compensation, which is calculated by multiplying three characteristics of the anomaly: its
86
4.4. INTERPRETATION
Table 4.3 Results from Treatment 2 (T2)

vm_id disk_sum (%+) mem_sum (%+) cpu_sum (%+) used_time_a (s) used_time_b (s) cr_value ($)
VM1
51831
36289
25220
28668
28668
10.08
VM2
45821
39682
24682
28669
28669
10.45
VM3
46829
35895
26481
28687
28687
10.29
VM4
54827
32967
26485
28650
28650
9.87
VM5
42576
32918
25619
28628
28628
9.68
VM6
42358
35684
25487
28569
28569
10.02
VM7
53968
31972
23581
28650
28650
9.15
VM8
54386
39542
26581
28651
28651
10.80
VM9
57918
31957
25358
28599
28599
9.48
VM10
53895
38945
25694
28636
28636
10.54
VM11
42587
36791
25896
28611
28611
10.27
VM12
52043
34826
23849
28620
28620
9.59
VM13
42189
39857
23516
28603
28603
10.22
VM14
57824
36827
21537
28643
28643
9.42
VM15
43819
31548
25689
28592
28592
9.49
VM16
53827
32549
25638
28665
28665
9.64
VM17
51287
32457
23516
28585
28585
9.18
VM18
48529
32648
23516
28688
28688
9.24
VM19
41728
32584
25893
28639
28639
9.69
VM20
49681
39962
22658
28635
28635
10.07
VM21
52681
31254
29823
28594
28594
10.27
VM22
45896
36984
28569
28637
28637
10.83
VM23
57823
32654
21358
28632
28632
8.80
VM24
48523
39758
24153
28607
28607
10.33
VM25
45287
32548
28165
28658
28658
10.14
VM26
41938
36258
24715
28602
28602
9.95
VM27
52689
34585
25631
28641
28641
9.92
VM28
42869
35689
29165
28584
28584
10.75
VM29
55862
32694
25413
28673
28673
9.62
VM30
59137
35846
21358
28597
28597
9.23
bill_value:
295.01
gravity (how much it exceeds the SLA threshold), duration, and price. Table 4.4 presents
the eight generated anomalies which totaled $20.64.
Table 4.4 Generated Fake" Anomalies
anomaly_id
type
AN1
bandwidth
AN2
bandwidth
AN3
bandwidth
AN4
latency
AN5
latency
AN6
latency
AN7
jitter
AN8
jitter
gravity
364
319
329
51
67
28
15
49
measurement_unit
bits per second
bits per second
bits per second
bits per second
bits per second
bits per second
miliseconds
miliseconds
duration (s) price ($)

300
0.00002
450
0.00002
531
0.00002
297
0.0003
138
0.0003
249
0.0003
258
0.0001
468
0.0001
total_compensation:
anomaly_compensation ($)
2.18
2.87
3.49
4.54
2.77
2.09
0.39
2.29
20.64
Table 4.5 presents the results from T3 and the charging records for each VM, including:
VM identification (vm_id); the time used, the compensation considered by the bill, the
manually calculated sum from the anomalies (anomalies_sum) and the monetary value
for each charging record (cr_value). All the VMs considered the anomalies properly,
because as can be seen in the Table 4.5 the column anomalies_sum is the equal to the
column compensation (which correspond the sum of anomalies values).
87
4.4. INTERPRETATION
Table 4.5 Results from Treatment 3 (T3)

vm_id
VM1
VM2
VM3
VM4
VM5
VM6
VM7
VM8
VM9
VM10
VM11
VM12
VM13
VM14
VM15
VM16
VM17
VM18
VM19
VM20
VM21
VM22
VM23
VM24
VM25
VM26
VM27
VM28
VM29
VM30
4.4.2
used_time (s)
28668
28669
28687
28650
28628
28569
28650
28651
28599
28636
28611
28620
28603
28643
28592
28665
28585
28688
28639
28635
28594
28637
28632
28607
28658
28602
28641
28584
28673
28597
compensation ($)
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
anomalies_sum ($)
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
bill_value:
cr_value ($)
7.23
7.23
7.25
7.22
7.19
7.14
7.22
7.22
7.17
7.20
7.18
7.19
7.17
7.21
7.16
7.23
7.15
7.25
7.20
7.20
7.16
7.20
7.20
7.17
7.22
7.17
7.21
7.15
7.24
7.16
215.89
Discussion
This subsection presents a discussion of the case study results. We observed whether and
why the 13 Monext requirements were fulfilled.
REQ-01 Location Unawareness: For this requirement, accounting must be performed as a service for VMs running locally or remotely. Therefore, the case
study was organized to create a distributed configuration of resources (JiTDCs) and
other components (CloudMiddleware and CloudClient). The results showed that
all remotely hosted VMs were accounted for using the sending frequency of ten
seconds.
REQ-02 Flexible Data Format: For this requirement, it should be possible to
include additional usage information metrics. Therefore, a new metric related to
disk usage (disk_sum, disk_avg, and disk_rate) was added. It yielded evidence that
additional metrics can be included, due to the technology used and architectural
design.
88
4.4. INTERPRETATION
REQ-03 Service Elasticity: For this requirement, the number of VMs underlying
and fulfilling a service can be scaled due to service elasticity. The accounting
system must be designed to handle such scenario. Q2 focused on this issue and
statistically concluded that the framework can handle the VMs scalability. However,
we recognize that the number of VMs was limited, and we aim to expand the case
study in future work.
REQ-04 Service Accounting: For this requirement, the accounting system must be
suitable for long-running services and not limited to tasks with a limited execution
time. Therefore, the framework must account for as long as the customer desires to
use the services. The case study was limited to eight hours due to the constraints of
the data centers, but the satisfactory outputs showed that the framework is scalable
and prepared to account without interruption.
REQ-05 Compensations: For this requirement, both usage and compensations
(due to breaking SLAs) must be accounted for. T3 used a charging policy considering usage and compensation and aimed to answer Q5 by analyzing whether the
generated anomalies reduced the bill value, which occurred.
REQ-06 Service Billing: For this requirement, billing must be managed on a perservice basis and not just for each VM. The answer to Q4 showed that consumption
by all individual VMs were totaled as charging records in a unique, final bill.
REQ-07 Adaptable Design: For this requirement, the accounting system must be
open for modifications to cope with future changes and enhancements. The case
study fulfilled this requirement, because the constraints of the JiTCloud constraints
the separation of the MVC architecture of Monext so that only the Model part was
used.
REQ-08 Complex Pricing: For this requirement, the function which calculates
prices from the accounting information must be able to incorporate complex pricing
rules. The case study performed three treatments using different charging policies.
In particular, T2 included four metrics and 11 variables in the same rule.
REQ-09 Standard Accounting Process: For this requirement, a unified, formal
accounting process must be followed. The case study utilized almost all accounting
functions, even the roaming function (which makes it clear that more than one
provider is being used). The financial clearing function was not used, since it just
change the bill status and we focused on more complex functionalities.
REQ-10 SLA Support: For this requirement, the customer must be offered a
89
4.4. INTERPRETATION
mechanism by which to specify a QoS desired to generate compensation later. T3

considered compensation, and Figure 4.5 in Section 4.3.1 presented how SLAs are
specified using a XML-based language.
REQ-11 Multiple Payment Models: For this requirement, pre-paid and post-paid
models must be offered. Which model is implemented depends on when the
customer pays and what services are used before (post-paid) or after (pre-paid)
the payment. Therefore, it was more difficult to evaluate the pre-paid model,
because the credits purchased must be controlled. We developed a schedule which
automatically terminates in the case of exceeded credit limits; however, the case
study did not implement this functionality, because we focused on in other central
features.
REQ-12 Multiple Charging Policy Specification: For this requirement, the accounting system administrator must have a way to specify charging policies without
stopping the system. The charging policies written in VeloZ were specified inside
configuration files so that the charging policy could be changed without interrupting
the system.
REQ-13 Resource as a Service: For this requirement, the accounting system must
support the economic paradigm RaaS. Since we based charging policies separate
on resource types, the RaaS philosophy was followed.
4.4.3
Threats to Validity
When repeating the case study, some factors should be considered, because the first
execution had a few limitations.
Size Scalability. According to Tanenbaum and Van Steen (2006), the size of a
distributed system must be scalable; that is, it must be easy to add more users and
resources. Due to the restrictions imposed by the available resources, the case
study used a limited number of data centers and VMs. The framework should be
evaluated with more resources to provide greater assurance of scalability.
Geographical Scalability. Also according to Tanenbaum and Van Steen (2006),
a distributed system must be geographically scalable; that is, system components
can be located far from each other. Due to the small number of resources, the
geographical distribution of components (JiTDCs, CloudMiddleware, and CloudClient) was limited, and they were all hosted in the same country. The distribution
of this framework should be expanded..
90
Time Constraint. The JiTCloud project could include the sub-modules of Monexts JiTProcessingService component only in the final period of my Masters, for
this reason the case study was performed over just few hours. The case study
should be conducted over a month to increase its reliability.
Simulated Context. The JiTCloud project is unfinished and does not have real
customers, so we performed an case study instead of a case study. The case study
should be evaluated in a real-life scenario in future.
4.5
Chapter Summary
This chapter discussed a case study that evaluated the feasibility of Monext framework.
The methodology used by the case study was adapted from the method established by
(Wohlin et al., 2000), which consisted of four phases: definition, planning, operation, and
interpretation. In the definition phase, the foundation of the case study is determined,
including why the case study should be conducted. During the definition phase, we stated
the goal of the case study and then elaborated five questions to guide the process.
During the planning phase, we discussed where the case study should be performed
and undertaken The operation phase determined the specifics of the case studys preconditions and execution. Finally, to draw conclusions from the case studys output, we
analyzed and interpreted the results.
This case study offered evidence that Monext framework fulfilled its purpose works
correctly installed inside he JiTCloud Platform. However, some improvements can be
done so that the system better handles large, complex environments. The next chapter
presents the conclusions of this research, its main contributions, and possible directions
for future work.
91
5
Conclusion
Can you imagine what I would do if I could do all I can?
SUN TZU (544 - 496 .BC)
Federated clouds are a promising cloud computing field. However, few recent studies
have addressed the issue of accounting federated clouds (Buyya et al., 2010; RESERVOIR,
2012), and four federated cloud platforms (Kertesz et al., 2012; Celesti et al., 2010;
Distefano et al., 2011) do not address the accounting requirement, and thus a proper
accounting system to charge for consumed resources. Therefore, the Monext framework
was built (Chapter 3) to support charging IaaS in federated cloud. All design decisions
were based on the results of a systematic mapping study (Chapter 2) and evaluated in a
real federated cloud platform (Chapter 4).
In this chapter, the conclusion of this work is presented. The Chapter remainder is
organized as follows. The research contributions are highlighted in Section 5.1. Future
work concerning to the research are listed in Section 5.2. Section 5.3 presents the
academic contributions. Lastly, the concluding remarks of this dissertation are described
in Section 5.4.
5.1
Research Contributions
The main contributions of this work are (a) a state-of-the-art of cloud accounting system
based on a systematic mapping study, (b) a proposed framework called Monext to support
federated cloud platforms, and (c) an experimental study applied within the JiTCloud
project.
Mapping Study on Cloud Accounting: We presented a study and identified the
main purposes of cloud accounting, emphasizing the key challenges. This study
92
5.2. FUTURE WORK
was conducted based on the good practices of systematic mapping studies proposed
by Petersen et al. (2008), and several important, related works were selected.
Monext Framework: A solution to charge federated clouds was developed. The
requirements, design, and implementation of the proposed solution were presented,
along with its main benefits: a domain specific language called VeloZ for charging
policy specifications; an adaptable design that cloud providers can manipulate to
make the solution fit their intent; It is designed to support large customers demands
independently where the resources are hosted; and support for SLAs and pre- and
post-paid models.
The VeloZ DSL: VeloZ allows IaaS providers to specify its own charging policies
and control its consumption in a financial aspect.
Experimental Study: An experiment evaluating the Monext solution was based on
the process proposed by Wohlin et al. (2000), which is composed of the following
main activities: definition, planning, operation, and interpretation. As a result, five
null hypotheses were rejected, providing evidence of the frameworks quality.
5.2
Future Work
Systematic Mapping Study: The mapping study discussed in this dissertation

was conducted from September to December 2011 and cloud computing area
evolves rapidly, so it is important to repeat the search to identify new scientific
contributions.
Improvements of Monext: To optimize the Monext, enhancements and new features must be implemented: (i) new consumption metrics; (ii) investments in
security of billing transaction and communication between VMs and the JiTProcessingService; (iii) isolation of the JiTCollectorAgent inside the VM, perhaps
changing the Operational System Kernel; and (iv) since all consumption information is recorded, the use of advanced databases may be necessary and NoSQL
solutions probably are a good option. These four features were not implemented
due to the Masters time constraint.
Extension of the Experiment: Since the experiment performed in this dissertation
was applied in the context of the JiTCloud Platform, it is necessary to perform more
experiments with other scenarios with more complex data centers to improve the
93
5.3. ACADEMIC CONTRIBUTION
frameworks reliability. Increasing the number of used VMs is strong recommended

to provide more conclusive results.
5.3
Academic Contribution
The conducted mapping study was published in a scientific conference: SILVA, F. A. P.;
SILVEIRA N., PAULO. A. M.; GARCIA, V. C.; ASSAD, R. E.; TRINTA, F. M. "Accounting
Models for Cloud Computing: A Systematic Mapping Study". In: International Conference on Grid Computing & Applications (GCA), 2012, Las Vegas. Proceedings of the
2012 International Conference on Grid Computing & Applications, 2012. p. 3-9.
5.4
Concluding Remarks
Since Amazon started to sell cloud computing services in 2006 and many others IT
companies quickly followed suit, accounting in cloud computing has slowly gained the
attention of the scientific community, and many gaps still remain to be explored. The
systematic mapping study introduced many of these research opportunities, while Monext
focused on specific points. However, we are confident that Monext is a comprehensive
solution, and we believe that the use of a standard accounting process (Ruiz-Agundez
et al., 2010c) and Monexts layered architectures enables it to be better understood and
extended by other solutions. Applying the 13 guiding requirements and the remote
collecting strategy made it possible to serve both complex federated cloud platforms and
single data centers. In addition, using VeloZ, cloud administrators can specify charging
policies themselves, instead of depending on programmers to do it. Moreover, we judge
Monext to be an interesting solution, because it explored the union of existing accounting
models and feature to mitigate their limitations. This framework offers different reports
through a web-based interface, provides SLA support, and applies the emergent economic
model RaaS, among others benefits. Finally, this dissertation provides one more step in
the maturation of cloud accounting and suggests directions for further work in this field.
94
Bibliography
(2005). Micro payment gateways. Enschede.

Afzal, W., Torkar, R., and Feldt, R. (2008). A systematic mapping study on non-functional
search-based software testing. In SEKE08, pages 488493.
Alhamad, M., Dillon, T., and Chang, E. (2010). Conceptual sla framework for cloud computing. In Digital Ecosystems and Technologies (DEST), 2010 4th IEEE International
Conference on, pages 606 610.
Amazon-AWS (2012). Amazon elastic compute cloud (amazon ec2). http://aws.
amazon.com/ec2/. Acessed: 20/12/2012.
Backus, J. (1978). Can programming be liberated from the von neumann style?: a
functional style and its algebra of programs. Commun. ACM, 21(8), 613641.
Bailey, J., Budgen, D., Turner, M., Kitchenham, B., Brereton, P., and Linkman, S. (2007).
Evidence relating to object-oriented software design: A survey. In Proceedings of the
First International Symposium on Empirical Software Engineering and Measurement,
ESEM 07, pages 482484, Washington, DC, USA. IEEE Computer Society.
Basili, V. R., Caldiera, G., and Rombach, H. D. (1994). The goal question metric
approach. In Encyclopedia of Software Engineering. Wiley.
Ben-Yehuda, O. A., Ben-Yehuda, M., Schuster, A., and Tsafrir, D. (2012). The resourceas-a-service (raas) cloud. In Proceedings of the 4th USENIX conference on Hot Topics
in Cloud Ccomputing, HotCloud12, pages 1212, Berkeley, CA, USA. USENIX
Association.
Bencomo, N., Losavio, F., Marchena, F., and Matteo, A. (1997). Java implementations of
user-interface frameworks. In Technology of Object-Oriented Languages and Systems,
1997. TOOLS 23. Proceedings, pages 232246.
Brynjolfsson, E., Hofmann, P., and Jordan, J. (2010). Cloud computing and electricity:
beyond the utility model. Commun. ACM, 53(5), 3234.
Budgen, D., Turner, M., Brereton, P., and Kitchenham, B. (2008). Using Mapping Studies
in Software Engineering. In Proceedings of PPIG 2008, pages 195204. Lancaster
University.
95
BIBLIOGRAPHY
Buthelezi, M., Adigun, M. O., Ekabua, O. O., and Iyilade, J. (2008). Accounting, pricing
and charging service models for a guiset grid-based service provisioning environment.
In H. R. Arabnia and A. Bahrami, editors, CSREA EEE, pages 350355. CSREA Press.
Buyya, R., Yeo, C. S., Venugopal, S., Broberg, J., and Brandic, I. (2009a). Cloud computing and emerging it platforms: Vision, hype, and reality for delivering computing
as the 5th utility. Future Gener. Comput. Syst., 25(6), 599616.
Buyya, R., Yeo, C. S., Venugopal, S., Broberg, J., and Brandic, I. (2009b). Cloud computing and emerging it platforms: Vision, hype, and reality for delivering computing
as the 5th utility. Future Gener. Comput. Syst., 25(6), 599616.
Buyya, R., Ranjan, R., and Calheiros, R. N. (2010). Intercloud: utility-oriented federation
of cloud computing environments for scaling of application services. In Proceedings
of the 10th international conference on Algorithms and Architectures for Parallel
Processing - Volume Part I, ICA3PP10, pages 1331, Berlin, Heidelberg. SpringerVerlag.
Cai, H., Zhang, K., Wang, M., Li, J., Sun, L., and Mao, X. (2009). Customer centric
cloud service model and a case study on commerce as a service. In Proceedings of the
2009 IEEE International Conference on Cloud Computing, CLOUD 09, pages 5764,
Washington, DC, USA. IEEE Computer Society.
Caracas, A. and Altmann, J. (2007). A pricing information service for grid computing.
In Proceedings of the 5th international workshop on Middleware for grid computing:
held at the ACM/IFIP/USENIX 8th International Middleware Conference, MGC 07,
pages 4:14:6, New York, NY, USA. ACM.
Celesti, A., Tusa, F., Villari, M., and Puliafito, A. (2010). How to enhance cloud
architectures to enable cross-federation. In Cloud Computing (CLOUD), 2010 IEEE
3rd International Conference on, pages 337 345.
Cohen, J. (1988). Statistical power analysis for the behavioral sciences, volume 2nd.
Lawrence Erlbaum Associates.
Comellas, J. O. F., Presa, I. G., and Fernndez, J. G. (2010). Sla-driven elastic cloud
hosting provider. In Proceedings of the 2010 18th Euromicro Conference on Parallel,
Distributed and Network-based Processing, PDP 10, pages 111118, Washington,
DC, USA. IEEE Computer Society.
96
BIBLIOGRAPHY
Condori-Fernandez, N., Daneva, M., Sikkel, K., Wieringa, R., Dieste, O., and Pastor, O.
(2009). A systematic mapping study on empirical evaluation of software requirements
specifications techniques. In L. Williams, J. Miller, and R. Selby, editors, Third
International Symposium on Empirical Software Engineering and Measurement, pages
503505, Los Alamitos. IEEE Computer Society Press.
Costa, R., Brasileiro, F., de Souza Filho, G. L., and Sousa, D. M. (2010). Just in time
clouds: Enabling highly-elastic public clouds over low scale amortized resources.
Technical Reports-Laboratrio de Sistemas Distribudos http://tinyurl.com/
8c3paal.
Denne, M. (2007). Pricing utility computing services. In International Journal of Web
Services Research (IJWSR).
Detal, G., Leroy, D., and Bonaventure, O. (2009). An adaptive three-party accounting
protocol. In Proceedings of the 5th international student workshop on Emerging
networking experiments and technologies, Co-Next Student Workshop 09, pages 34,
New York, NY, USA. ACM.
Distefano, S., Fazio, M., and Puliafito, A. (2011). The cloud@home resource management
system. In Utility and Cloud Computing (UCC), 2011 Fourth IEEE International
Conference on, pages 122 129.
El Maghawry, N. and Dawood, A. (2010). Aspect oriented gof design patterns. In
Informatics and Systems (INFOS), 2010 The 7th International Conference on, pages 1
7.
Elmroth, E., Marquez, F. G., Henriksson, D., and Ferrera, D. P. (2009). Accounting
and billing for federated cloud infrastructures. In Proceedings of the 2009 Eighth
International Conference on Grid and Cooperative Computing, GCC 09, pages 268
275, Washington, DC, USA. IEEE Computer Society.
Ernemann, C., Hamscher, V., and Yahyapour, R. (2002). Economic scheduling in grid
computing. In Revised Papers from the 8th International Workshop on Job Scheduling
Strategies for Parallel Processing, JSSPP 02, pages 128152, London, UK, UK.
Springer-Verlag.
Falasi, A. A. and Serhani, M. A. (2011). A framework for sla-based cloud services
verification and composition. In Proc. Int. Conference on Innovations in Information
Technology (IIT), pages 287292.
97
BIBLIOGRAPHY
Fowler, M. (2012). Inversion of control. http://martinfowler.com/bliki/

InversionOfControl.html. Acessed: 20/12/2012.
Freitas, I., da Mota Silveira Neto, P. A., OLeary, P., de Almeida, E. S., and
de Lemos Meira, S. R. (2011). Agile software product lines: a systematic mapping
study. Softw. Pract. Exper., 41(8), 899920.
Gabbrielli, M. and Martini, S. (2010). Programming Languages: Principles and
Paradigms. Springer Publishing Company, Incorporated, 1st edition.
Gerber, A. J., Barnard, A., and van der Merwe, A. J. (2007). Towards a semantic web
layered architecture. In Proceedings of the 25th conference on IASTED International
Multi-Conference: Software Engineering, SE07, pages 353362, Anaheim, CA, USA.
ACTA Press.
Gohner, M. (2006). Accounting-ansatze im bereich des grid-computing. http://
tinyurl.com/87goucy. Accessed: 30/11/2012.
Goiri, Guitart, J., and Torres, J. (2010). Characterizing cloud federation for enhancing
providers profit. 2012 IEEE Fifth International Conference on Cloud Computing, 0,
123130.
Harmon, R., Demirkan, H., Hefley, B., and Auseklis, N. (2009). Pricing strategies for
information technology services: A value-based approach. In System Sciences, 2009.
HICSS 09. 42nd Hawaii International Conference on, pages 1 10.
Henzinger, T., Singh, A., Singh, V., Wies, T., and Zufferey, D. (2010). Flexprice: Flexible
provisioning of resources in a cloud environment. In Cloud Computing (CLOUD),
2010 IEEE 3rd International Conference on, pages 83 90.
Hilley, D. (2009). Cloud computing: A taxonomy of platform and infrastructure-level
offerings. Georgia Institute of Technology, Tech. Rep. GIT-CERCS-09-13.
Jai, B. (2011). The economy of parallel and distributed computing in the cloud. In Proc.
Int. Symposium on VLSI Design, Automation and Test (VLSI-DAT 2011), pages 2528.
Jain, R., Ramakrishnan, K. K., and Chiu, D.-M. (1988). Innovations in internetworking.
chapter Congestion avoidance in computer networks with a connectionless network
layer, pages 140156. Artech House, Inc., Norwood, MA, USA.
Jeremy, G. (2010). The top 250 players in the cloud computing ecosystem.
98
BIBLIOGRAPHY
Karsten, M., Schmitt, J., Stiller, B., and Wolf, L. (2000). Charging for packet-switched
network communication-motivation and overview. Comput. Commun., 23(3), 290302.
Kertesz, A., Kecskemeti, G., Marosi, A., Oriol, M., Franch, X., and Marco, J. (2012).
Integrated monitoring approach for seamless service provisioning in federated clouds.
In Parallel, Distributed and Network-Based Processing (PDP), 2012 20th Euromicro
International Conference on, pages 567 574.
Kitchenham, B. (2010). Whats up with software metrics? - a preliminary mapping study.
J. Syst. Softw., 83(1), 3751.
Kitchenham, B. and Charters, S. (2007). Guidelines for performing systematic literature
reviews in software engineering. Software Engineering Group School of , 2(EBSE
2007-001), 1051.
Kitchenham, B., Mendes, E., and Travassos, G. (2007). Cross versus within-company
cost estimation studies: A systematic review. Software Engineering, IEEE Transactions
on, 33(5), 316 329.
Kitchenham, B., Pearl Brereton, O., Budgen, D., Turner, M., Bailey, J., and Linkman, S.
(2009). Systematic literature reviews in software engineering - a systematic literature
review. Inf. Softw. Technol., 51(1), 715.
Kitchenham, B. A., Dyba, T., and Jorgensen, M. (2004). Evidence-based software engineering. In Proceedings of the 26th International Conference on Software Engineering,
ICSE 04, pages 273281, Washington, DC, USA. IEEE Computer Society.
Kleinrock, L. (2005). A vision for the Internet. ST Journal for Research, 2(1), 45.
Kruchten, P. (1995). The 4+1 view model of architecture. IEEE Softw., 12(6), 4250.
Lehmann, S. and Buxmann, P. (2009). Pricing strategies of software vendors. Business
and Information Systems Engineering, 1, 452462.
Lindner, M., Galan, F., Chapman, C., Clayman, S., Henriksson, D., and Elmroth, E.
(2011). The cloud supply chain : A framework for information, monitoring, accounting
and billing. In 2nd International ICST Conference on Cloud Computing (CloudComp
2010).
Liu, F., Tong, J., Mao, J., Bohn, R., Messina, J., Badger, L., and Leaf, D. (2012). NIST
Cloud Computing Reference Architecture: Recommendations of the National Institute
99
BIBLIOGRAPHY
of Standards and Technology (Special Publication 500-292). CreateSpace Independent

Publishing Platform, USA.
Mahemoff, M. and Johnston, L. (1999). Handling multiple domain objects with modelview-controller. In Technology of Object-Oriented Languages and Systems, 1999.
TOOLS 32. Proceedings, pages 28 39.
Mihailescu, M. and Teo, Y. (2010a). Dynamic resource pricing on federated clouds. In
Int. Conference on Cluster, Cloud and Grid Computing (CCGrid), pages 513517.
Mihailescu, M. and Teo, Y. M. (2010b). On economic and computational-efficient
resource pricing in large distributed systems. In Proc. Int. Conference on Cluster,
Cloud and Grid Computing (CCGRID 10), pages 838843, Washington, DC, USA.
Mihoob, A., Molina-Jimenez, C., and Shrivastava, S. (2010). A case for consumer
150;centric resource accounting models. In Cloud Computing (CLOUD), 2010 IEEE
3rd International Conference on, pages 506 512.
Morariu, C., Waldburger, M., and Stiller, B. (2006). An integrated accounting and
charging architecture for mobile grids. In Broadband Communications, Networks and
Systems, 2006. BROADNETS 2006. 3rd International Conference on, pages 1 10.
Muller, J., Krugger, J., Enderlein, S., Helmich, M., and Zeier, A. (2009). Customizing
enterprise software as a service applications: Back-end extension in a multi-tenancy
environment. In Enterprise Information Systems, volume 24 of Lecture Notes in
Business Information Processing, pages 6677. Springer Berlin Heidelberg.
Narayan, A., Rao, S., Ranjan, G., and Dheenadayalan, K. (2012). Smart metering of
cloud services. In Systems Conference (SysCon), 2012 IEEE International, pages 1 7.
Osterwalder, A. (2004). The Business Model Ontology a proposition in a design science
approach.
Ouyang, J., Sahai, A., and Prnyne, J. (2007). A mechanism of specifying and determining
pricing in utility computing environments. In Business-Driven IT Management, 2007.
BDIM 07. 2nd IEEE/IFIP International Workshop on, pages 39 44.
Pandey, T., Singh, B., Kushwaha, D., and Misra, A. (2009). Authentication and billing
framework for service oriented architecture. In Systems, 2009. ICONS 09. Fourth
100
BIBLIOGRAPHY
Park, K.-W., Han, J., Chung, J., and Park, K. H. (2012). Themis: A mutually verifiable
billing system for the cloud computing environment. IEEE Transactions on Services
Computing, 99(PrePrints).
Petersen, K., Feldt, R., Mujtaba, S., and Mattsson, M. (2008). Systematic mapping
studies in software engineering. In Proceedings of the 12th international conference on
Evaluation and Assessment in Software Engineering, EASE08, pages 6877, Swinton,
UK, UK. British Computer Society.
Piro, R. M., Guarise, A., and Werbrouck, A. (2003). An economy-based accounting
infrastructure for the datagrid. In Proceedings of the 4th International Workshop on
Grid Computing, GRID 03, pages 202, Washington, DC, USA. IEEE Computer
Society.
Pretorius, R. and Budgen, D. (2008). A mapping study on empirical evidence related
to the models and forms used in the uml. In Proceedings of the Second ACM-IEEE
international symposium on Empirical software engineering and measurement, ESEM
08, pages 342344, New York, NY, USA. ACM.
Prodan, R. and Ostermann, S. (2009). A survey and taxonomy of infrastructure as a
service and web hosting cloud providers. In Grid Computing, 2009 10th IEEE/ACM
RabbitMQ (2007). Open source enterprise messaging. http://www.rabbitmq.
Accessed:
com/resources/RabbitMQ_PressRelease_080207.pdf.
30/11/2012.
RabbitMQ (2012). Open source enterprise messaging. http://www.rabbitmq.
com/tutorials/amqp-concepts.html. Accessed: 30/11/2012.
Reijns, G. L. and van Gemund, A. J. C. (2005). Predicting the execution times of
parallel-independent programs using pearson distributions. Parallel Comput., pages
877899.
RESERVOIR (2012). Resources and services virtualization without barriers. http:
//62.149.240.97/. Accessed: 30/11/2012.
Rochwerger, B., Breitgand, D., Levy, E., Galis, A., Nagin, K., Llorente, I. M., Montero,
R., Wolfsthal, Y., Elmroth, E., Cceres, J., Ben-Yehuda, M., Emmerich, W., and Galn,
101
BIBLIOGRAPHY
F. (2009). The reservoir model and architecture for open federated cloud computing.
IBM J. Res. Dev., 53(4), 535545.
Rohitratana, J. and Altmann, J. (2010). Agent-based simulations of the software market
under different pricing schemes for software-as-a-service and perpetual software. In
J. Altmann and O. Rana, editors, Economics of Grids, Clouds, Systems, and Services,
volume 6296 of Lecture Notes in Computer Science, pages 6277. Springer Berlin
Heidelberg.
Ruiz-Agundez, I., Penya, Y. K., and Bringas, P. G. (2010a). Tarificacion flexible de
servicios en internet. Proceedings of the XX Jornadas de Telecom I+D, Telefonica,
Valladolid, Spain.
Ruiz-Agundez, I., K. Penya, Y., and G. Bringas, P. (2010b). A taxonomy of the future
internet accounting process. In Int. Conference on Advanced Engineering Computing
and Applications in Sciences (ADVCOMP 10), pages 111117.
Ruiz-Agundez, I., Penya, Y., and Bringas, P. (2010c). A taxonomy of the future internet
accounting process. In Advanced Engineering Computing and Applications in Sciences
(ADVCOMP 10), Int. Conference on, pages 111117.
Ruiz-Agundez, I., Penya, Y. K., and Bringas, P. G. (2011). A flexible accounting model
for cloud computing. In Proceedings of the 2011 Annual SRII Global Conference, SRII
11, pages 277284, Washington, DC, USA. IEEE Computer Society.
Sahai, A., Sahai, A., Durante, A., Durante, A., Machiraju, V., and Machiraju, V. (2001).
Towards automated sla management for web services. Technical report.
Sahai, A., Graupner, S., Machiraju, V., and Moorsel, A. v. (2003). Specifying and
monitoring guarantees in commercial grids through sla. In Proceedings of the 3st
International Symposium on Cluster Computing and the Grid, CCGRID 03, pages
292, Washington, DC, USA. IEEE Computer Society.
Samimi, P. and Patel, A. (2011). Review of pricing models for grid and cloud computing.
In Proc. IEEE Symposium on Computers and Informatics (ISCI 11), pages 634639.
Song, J., Liu, W., and Wang, Y. (2007). Competitive pricing model for resource scheduling in grid computing. In Proceedings of the Third International Conference on
Semantics, Knowledge and Grid, SKG 07, pages 406409, Washington, DC, USA.
IEEE Computer Society.
102
BIBLIOGRAPHY
Staples, M. and Niazi, M. (2007). Experiences using systematic review guidelines. J.

Syst. Softw., 80(9), 14251437.
Systems, S. (2007). Applying 4+1 view architecture with uml 2. http://tinyurl.
com/cn34ssr. Accessed: 30/11/2012.
Tanenbaum, A. and Van Steen, M. (2006). Distributed systems. Principles and Paradigms.
Toyota (2012). Toyota production system (tps). http://tinyurl.com/c9wqmh3.
Acessed: 30/11/2012.
Wahla, R. S. (1941). Aicpa committee on terminology. Accounting Terminology Bulletin
Review and Rsum.
Wee, S. (2011). Debunking real-time pricing in cloud computing. In Cluster, Cloud and
Grid Computing (CCGrid), 2011 11th IEEE/ACM International Symposium on, pages
585 590.
Weinhardt, C., Anandasivam, A., Blau, B., Borissov, N., Meinl, T., and Michalk, W.
(2009). Cloud computing a classification, business models, and research directions.
Business and Information Systems Engineering, 1, 391399.
Weiss, A. (2007). Computing in the clouds. netWorker, 11(4), 1625.
Wieringa, R., Maiden, N., Mead, N., and Rolland, C. (2005). Requirements engineering
paper classification and evaluation criteria: a proposal and a discussion. Requir. Eng.,
11(1), 102107.
Wohlin, C., Runeson, P., Hst, M., Ohlsson, M. C., Regnell, B., and Wessln, A. (2000).
Experimentation in software engineering: an introduction. Kluwer Academic Publishers, Norwell, MA, USA.
Xiong, X. and Fu, J. (2011). Active status certificate publish and subscribe based on amqp.
In Computational and Information Sciences (ICCIS), 2011 International Conference
on, pages 725 728.
Youseff, L., Butrico, M., and Da Silva, D. (2008). Toward a unified ontology of cloud
computing. In Grid Computing Environments Workshop, 2008. GCE 08, pages 1 10.
Yu, J., Li, M., Li, Y., Hong, F., and Du, Y. (2004). A service-oriented accounting
architecture on the grid. In Proceedings of the 5th international conference on Parallel
103
BIBLIOGRAPHY
and Distributed Computing: applications and Technologies, PDCAT04, pages 310

313, Berlin, Heidelberg. Springer-Verlag.
104
Appendices
105
A
Deploy Instructions
A.1
JiTProcessingService Deploy
This section describes how to deploy the web application using the Apache Tomcat 6.0
and the MySQL Server 5.1. We omitted the installation of this environment for simplicity.
Therefore, considering these execution environments installed, as the JiTProcessingService is a Grails application its deployable product has an .WAR" extension (the war file
can be found inside the jit_processing_service_web_dist_0.4.zip file). There is a couple
of ways to deploy this product but the easiest is to follow five steps:
1. Create the database scheme on the MySQL Server.
2. Configure the credentials of a database scheme (connection.user, connection.password,
connection.url etc.) in a properties file.
3. Stop Tomcat.
4. Delete an existing deployment. If you have previously deployed jitprocessingservice.war" in TOMCAT_HOME/webapps, then it has been unpacked into webapps/jitprocessingservice/... You must delete this directory and all its contents. On
Unix, this can be done with rm -r $TOMCAT_HOME/webapps/jitprocessingservice.
5. Copy WAR file to TOMCA_HOME/webapps/.
6. Start Tomcat.
7. Access http://localhost:8080/jitprocessingservice.
106
A.2. JITCOLLECTORAGENT DEPLOY
It is important to highlight that the autoDeploy" attribute in the <app>/METAINF/context.xml file must be true", so that, the Host will attempt to deploy and update
web applications dynamically, as needed.
A.2
JiTCollectorAgent Deploy
The most of our experiments were using Linux environment but the JiTCollectorAgent
was also tested with Windows SO. This tutorial uses Ubuntu Linux distribution. Aiming
to deploy JiTCollectorAgent it must uncompress the jit_collector_agent_dist_0.4.zip file
in an appropriate directory of the VM image (in our case we used the /opt directory).
When uncompressed, the jit_collector_agent_dist_0.4.zip artifact shows the following
files:
jit_collector_agent.jar: Executable file in which when started publishes the collected information
jba.properties: Properties file that keeps the message broker credentials
libsigar-amd64-linux.so: Adapter library for the Linux Operational System
libsigar-x86-linux.so: Adapter library for the Linux Operational System
sigar-amd64-winnt.dll: Adapter library for the Windows Operational System
sigar-x86-winnt.dll: Adapter library for the Windows Operational System
To execute jit_collector_agent.jar, it is necessary the Java Runtime Environment installed (1.6 version). Next, just execute the following command: java -jar jit_collector_
agent.jar <interval>. For which <interval> identifies the frequency of sending messages
in seconds. The jba.properties file owns the following configuration information:
virtual.machine: VM identification (it must be related to a specific Account)
amqp.host: Message broker endpoint
amqp.port: Message broker standard port
amqp.ssl_port: Message broker ssl port
Finally, to automatize the agent initialization, the /etc/rc.local file must be updated
with the following command:
java -jar "bash /opt/jit_collector_agent/jit_collector_agent.jar <interval> > /dev/null " -s /bin/bash
107

Monext: An Accounting Framework For Federated Clouds

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Monext: An Accounting Framework For Federated Clouds

Uploaded by

Copyright:

Available Formats

Monext: An Accounting Framework for

Francisco Airton Pereira da Silva

Universidade Federal de Pernambuco

Universidade Federal de Pernambuco

Francisco Airton Pereira da Silva

Monext: An Accounting Framework for

A M.Sc. Dissertation presented to the Centro de Informtica

Advisor: Vinicius Cardoso Garcia

Silva, Francisco Airton Pereira da

Inclui bibliografia, glossrio e apndice.

CDD (23. ed.)

Visto e permitida a impresso.

I specially dedicate this dissertation with love and affection

When you walk through a storm,

A Computao na Nuvem se tornou um paradigma consumado para executar servios em

Systematic Mapping Study on Cloud Accounting

2.4.4 Accounting Models Classification

Monext: An Accounting Framework for Federated Clouds

4.3.3 Data Validation . . . . . . .

Systematic Mapping Process Petersen et al. (2008) . . . . . . . . . . .

Monext - Charging Policy Specification Page . . . . . . . . . . . . . .

Composition of a JiT Cloud (Costa et al., 2010) . . .

General Use Cases Description . . . . . . . . . . . . . . . . .

Monext Configuration Properties

ABC Accounting, Billing, and Compensation

JiT DC Just in Time Data Center

SLA Service Level Agreement

1.2. PROBLEM STATEMENT

The problem statement of this dissertation is formulated as:

1.3. OUT OF SCOPE

Some subjects were excluded from the scope of this project.

Statements of the Contributions

The research presented in this dissertation makes the following contributions:

1.5. DISSERTATION STRUCTURE

An accounting framework for federated cloud; and

The remainder of this dissertation is organized as follows: Chapter 2 presents a mapping

it through the development of new architectures, exploring different accounting models

2.2. LITERATURE REVIEW METHOD

Literature Review Method

While a Systematic Review is a mean of identifying, evaluating and interpreting all

2.2. LITERATURE REVIEW METHOD

Figure 2.1 Systematic Mapping Process Petersen et al. (2008)

Definition of Research Questions

2.2. LITERATURE REVIEW METHOD

2.2. LITERATURE REVIEW METHOD

Firstly, an automatic search was conducted in different search engines (IEEEXplore,

Figure 2.2 N. of Papers X Search Engines.

2.2. LITERATURE REVIEW METHOD

The former, includes:

Figure 2.3 Filters of the screening process.

2.2. LITERATURE REVIEW METHOD

A Framework for SLA-based Cloud services verification and composition

Falasi and Serhani (2011)

Conceptual SLA framework for Cloud Computing

Alhamad et al. (2010)

A Service-oriented accounting architecture on the Grid

THEMIS: Towards Mutually Verifiable Billing Transactions in the Cloud

Park et al. (2012)

Authentication and Billing Framework for Service Oriented Architecture

Pandey et al. (2009)

Accounting and Billing for Federated Cloud Infrastructures

Elmroth et al. (2009)

A pricing information service for Grid computing