research paper and ppt on on 5 conference papers-cloud computing in software development
beststudent143
paper4-ExploitingSoftwareProductLinestoDevelop.pdf
Exploiting Software Product Lines to Develop Cloud Computing Applications
Everton Cavalcante1, André Almeida1,2, Thais Batista1, Nélio Cacho1, Frederico Lopes3, Flavia C. Delicato4, Thiago Sena1, Paulo F. Pires4
1 Department of Informatics and Applied Mathematics, Federal University of Rio Grande do Norte �– Natal, Brazil 2 Federal Institute of Education, Science and Technology of Rio Grande do Norte �– Parnamirim, Brazil
3 School of Science and Technology, Federal University of Rio Grande do Norte �– Natal, Brazil 4 Department of Computer Science, Federal University of Rio de Janeiro �– Rio de Janeiro, Brazil
{evertonranielly, andregustavoo, thaisbatista, neliocacho, fred.lopes, fdelicato, diegodimap, lord.sena, paulo.f.pires}@gmail.com
ABSTRACT With the advance of the Cloud Computing paradigm, new chal- lenges in terms of models, tools, and techniques to support devel- opers to design, build and deploy complex software systems that make full use of the cloud technology arise. In the heterogeneous scenario of this new paradigm, the development of applications using cloud services becomes hard, and the software product lines (SPL) approach is potentially promising for this context since specificities of the cloud platforms, such as services heterogenei- ty, pricing model, and other aspects can be catered as variabilities to core features. In this perspective, this paper (i) proposes a seamless adaptation of the SPL-based development to include important features of cloud-based applications, and (ii) reports the experience of developing HW-CSPL, a SPL for the Health Watcher (HW) System, which allows citizens to register com- plaints and consult information regarding the public health system of a city. Several functionalities of this system were implemented using different Cloud Computing platforms, and run time specific- ities of this application deployed on the cloud were analyzed, as well as other information such as change impact and pricing.
Categories and Subject Descriptors D.2.13 [Software Engineering]: Reusable software �– domain engineering, reuse models. C.2.4 [Computer-Communication Networks]: Distributed Systems �– distributed applications. K.6.3 [Management of Computing and Information Systems]: Soft- ware Management �– software development, software process.
General Terms Design, Experimentation, Standardization.
Keywords Cloud Computing, software product lines, cloud platforms, ser- vices, Health Watcher system.
1. INTRODUCTION Cloud Computing [1, 2, 3] is a new computing paradigm that enables ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g. networks, applications, and servers) that can be rapidly provisioned and released with minimal management effort or interaction with the service provider [4]. Among the benefits commonly attributed to the adoption of this computing model, it can be highlighted the low initial investment in terms of physical infrastructure, reduc- tion and greater control of operational costs, and high scalability. Although this paradigm provides benefits absent in current tech- nologies, such as a pay-per-use model, and the elasticity of the applications (the capability of quickly increasing or decreasing the use of the computational infrastructure without incurring unneces- sary costs with idle or underutilized resources), the development of Cloud Computing is still in its infancy [5]. In fact, building cloud-based applications is a challenging task as they are signifi- cantly more complex due to the intrinsic complexity of using third-part cloud providers. The major difficulties encompass issues such as the decision of which underlying cloud computing platforms to use, and the need of tracking pricing policies of services provided by different clouds platforms. There are several challenges that must be addressed in the Cloud Computing con- text, especially regarding methods, tools, and techniques to sup- port developers to design, build and deploy complex software systems that make full use of the cloud technology. The particular nature of Cloud Computing applications creates specific require- ments that also demand changes in terms of the development of such applications, encompassing methodologies and techniques for requirements elicitation, architecture, implementation, de- ployment, testing, and evolution of software [6, 7]. Moreover, to realize the vision of Cloud Computing in its full potential, new systems models must be developed in order to allow developers to focus only on the functional aspects of the applications, and han- dle the distribution and parallelization of the cloud as an orthogo- nal concern [8].
In software development, there is an essential need to reduce costs, effort, and time to market of software products [9]. In this perspective, software product lines (SPLs) [10, 13] represent an increasingly popular technology to support the derivation of a wide range of applications by promoting the systematic reuse of components and other software artifacts. SPLs have become a mainstream technique to the development of software systems that share a common set of commonalities and contain variabilities that distinguish specific products, thus supporting the develop-
Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be hon- ored. Abstracting with credit is permitted. To copy otherwise, to repub- lish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SPLC - Vol. II, September 02�–07, 2012, Salvador, Brazil. Copyright 2012 ACM 978-1-4503-1095-6/12/09 $15.00
179
ment of a family (or product line) of related products. Among the benefits achieved with the SPL approach, it can be highlighted a greater reuse of software artifacts, reduction of the production time, greater flexibility, increased quality of the developed prod- ucts, ability to perform customization, etc.
Recent research has approached the synergic development of SPLs to the Service-Oriented Architecture (SOA) [14] concept, which is intrinsically related to the Cloud Computing paradigm. Both have common goals, such as promoting reuse of services, which enable rapid and easy composition of loosely coupled distributed software applications, rather than repeatedly redevel- oping them for new systems. Moreover, they enable capitalizing on reuse to achieve desired benefits such as productivity gains, decreased development costs, higher reliability and others [15, 24].
As Cloud Computing is still an emergent area and it does not have a common standardized technological model, cloud platforms are not implemented using common standards, each one having its own APIs, development tools, virtualization mechanisms and governance characteristics. Considering the fact that such hetero- geneity of Cloud Computing environments hampers the develop- ment of applications using different cloud services, SPL is a promising approach for this context since these specificities re- garding cloud platforms and other aspects can be catered as varia- bilities to core features. The use of the SPL paradigm enables the specification and implementation of cloud applications as the different services facilities provided by cloud platforms, leading to the features that represent the variabilities in SPL. In the do- main engineering phase of the SPL development, the different cloud platform services are represented as alternative features of a given service. In the application engineering phase, SPL enables the configuration of cloud applications according to the require- ments, since it is possible to choose the proper cloud platform service that fit the application needs. However, we need to add expressiveness to the feature model to represent important charac- teristics of the cloud services such as the pricing model (since users pay for the use of the services), availability, and response time.
The goal of this paper is twofold: (i) to propose a seamless adapta- tion of the SPL-based development to support important specifici- ties of cloud-based applications, and; (ii) to report the experience of developing a SPL for the Health Watcher (HW) System [16], a Web-based system that allows citizens to register complaints and consult information regarding the public health system of a city. We have implemented several functionalities of this system using two Cloud Computing platforms, namely, Amazon Web Services (AWS) [17] and Google App Engine (GAE) [18]. As discussed further, one of the main challenges to use the SPL approach for cloud applications is how to find the true development costs, involving all of the cost associated with maintaining the services and data placed on the cloud.
This paper is structured as follows. Section 2 presents the Health Watcher system, that serves as running example used along this paper. Section 3 discusses about Cloud Computing platforms and services, specifically in regards to AWS and GAE platforms. In Section 4 we introduce our approach for developing a SPL for Cloud Computing applications (Section 4.1) and present HW- CSPL, the proposed SPL for the Health Watcher system (Section 4.2), as well as issues related to its development in different cloud platforms. Section 5 presents an evaluation of HW-CSPL in terms of change impact and estimated cost (Sections 5.1 and 5.2) and highlights the benefits and drawbacks of using the SPL approach
in cloud application development, taking into account our experi- ence with HW-CSPL (Section 5.3). Section 6 present related works. Finally, Section 7 contains final remarks.
2. THE HEALTH WATCHER SYSTEM Health Watcher (HW) [16] is a Web-based system that enables citizens to register complaints and consult information related to the public health system of a city. The main goal of this system is to improve the quality of the services offered by health institutions by enabling the public to report complaints about the quality of these services and to obtain information about health care units.
The HW system was selected to serve as running example of this paper because it is a real, non-trivial application, having quality requirements found in several information systems, e.g. Web user interface, persistence, concurrence, distribution, and implementa- tion technologies such as Java servlets [19], JDBC (Java Data- base connection) and RMI (Remote Method Invocation). Moreo- ver, HW was developed in a well-defined and documented layered architecture based on the MVC (Model-View-Control) architec- tural pattern, widely known and used for Web systems [20].
HW was developed to cater the needs of two actors: user and employee. The user can be any citizen that accesses the system through the Internet and that can make his/her complaint or con- sult information related to the public health services. When a complaint is registered by a user, it is forwarded to a specific department, which will deal with the complaint and return a re- sponse upon its investigation. This response will be registered in the system and will be available to be consulted by users.
Users can register a complaint in regards to different elements, having three options to make the register: (i) complaint about food, representing cases of suspected ingestion of contaminated food; (ii) complaint regarding mistreatment of animals or diseases transmitted by contaminated animals, and; (iii) complaints cover- ing other cases (e.g. hygiene problems in restaurants, sewage leaks, etc.). After choosing one of these items, the citizen fills out a form for registering the complaint in the system. In order to investigate the registered complaints, the employees of sanitary control and health system departments can access the HW system by providing their username (login) and password.
3. CLOUD PLATFORMS AND SERVICES Aiming to illustrate our approach, we have implemented several functionalities of HW system using two Cloud Computing plat- forms, Amazon Web Services (AWS) [17] and Google App En- gine (GAE) [18]. These platforms were selected because they are the most known solutions on the market. In addition, they offer a wide range of services, a good support for the development of cloud applications through a well-defined API, and the services provided by these platforms can be viewed as complementary services.
AWS Cloud Computing platform is widely used by companies of various sizes and domains, and provides computational power, storage facilities and several other functionalities that allow com- panies to deploy applications and services at low cost, with great flexibility, scalability and reliability. Among these services, we can highlight: (i) Amazon EC2, which offers elastic computational resources by creating virtual machine instances to host applica- tions; (ii) Amazon SimpleDB, which implements a simple non- relational database mechanism; (iii) Amazon S3, which allows file storage on the cloud, and; (iv) Amazon RDS, which enable creat- ing relational database instances, such as MySQL and Oracle.
180
GAE platform is focused on supporting Web applications hosting. Virtualization and elasticity clearly observed in the AWS platform are practically imperceptible in GAE, since virtualization man- agement and elasticity are automatically done by the platform. Compared to AWS, it restricts the possibilities of configuring the application execution environment. While in AWS we have many possibilities for configuring applications, in GAE developers are constrained by pre-established rules, applied from inside the sandbox, which controls the access to the GAE resources through rules related to the use of multiple threads, sockets and access to the file system. Among the services provided by GAE, the follow- ing can be highlighted: (i) facilities for deploying a cloud applica- tion using the GAE infrastructure; (ii) DataStore, a text-based, non-relational persistence service for storing application�’s data; (iii) Blobstore, which allows storing objects up to 2 GB, and; (iv) Log Service, which stores application logs into an internal specific file.
One of the most remarkable characteristics of Cloud Computing is its pricing model. Cloud providers charge their services per-usage, hence there is no need to up-front commitment by users, thus enabling them to request and use only the necessary amount. In general, the pricing model supported by cloud providers is able to charge for computing at a very fine-grained level. Examples are measuring storage, bandwidth, and computing resources con- sumed.
In order to present a clear idea of what drives costs in cloud pro- viders, we show the pricing model of AWS and GAE platforms. As these cloud providers offer pay-as-you-go services, there is a separate cost for the use of each service. Table 1 depicts some of these costs. The rows of the table represent features implemented for the HW system (first four rows) and infrastructure elements (last two rows), while the columns represent the price for using each feature/service for each provider. It is noteworthy that it is not easy to model the costs to operate HW at scale because cloud providers use many pricing dimensions to charge their services. For instance, when an Amazon EC2 instance is created to host the HW Web application, AWS will charge for the amount of time that the server is running and for the data that it is fetched. Addi- tionally, the pricing for many of the services reflects volume discounts based on usage, that is, the more the service is used, the less it costs per event. Thus, pricing for services tends to decline over time.
Table 1. Costs regarding the use of cloud resources from AWS and GAE platforms for the HW features.
Feature AWS GAE
Persistence
$0.11 per hour for SmallDB, with instance deployed in a single availability zone
$0.24 (GB per month)
Login System No additional charge No additional charge
Log System $0.14 per hour for each Amazon SimpleDB machine
$0.24 (GB per month)
File Storage $0.125 per GB up to 1TB/month $0.13 (GB per month)
Virtual ma- chines in- stances
$0.34 per hour for a large Amazon EC2 instance running Linux
No additional charge
Data transfer (out)
$0.12 per GB up to 10TB/month $0.12 (per GB)
In regards to the SPL development, the task of deploying the HW on the cloud is even more complicated since it is necessary to examine the core assets, the product-specific assets, and the inter- action between them in order to figure out the deployment cost. Therefore, one of the main challenges to use the SPL approach for cloud applications is how to find the true development costs, involving all of the cost associated with maintaining the services and data placed on the cloud. In this context, Section 4 describes an approach to estimate the costs to deploy an application on the cloud by using the information provided by the extended feature model proposed in our approach.
4. DEVELOPING A SPL ON THE CLOUD 4.1 Proposed approach SPL approaches usually identify commonalities (similarities) between all members of the family as well as characteristics that vary among them, the variabilities. Thus, the members of a family have a basic set of common functionalities and associated varia- tions that individualize each of these members. In this perspective, commonality and variability analysis is a powerful concept that enables specifying members of a SPL by taking into account services available by cloud service providers.
We have proposed an adaptation to the domain engineering activi- ty that encompasses the elaboration of the application�’s feature model. Feature models [11, 12] represent commonalities, varia- bilities, and variation-related constraints in terms of features and their relationships, being also used in the domain analysis activity and also in product derivation of a SPL. In general, feature models are structured as a tree, in which features are represented by nodes of this tree and the variations between features are represented by edges and feature groups, so that the hierarchical organization of the diagram describes the key concept starting from more general concepts to more specific concepts as they descend the tree. Fea- tures can be [11]: (i) mandatory, i.e. the feature must necessarily be included in a product; (ii) optional, i.e. the feature may or may not be included if the feature from which it is derived is selected; (iii) or-inclusive, among the set of related features at least one of them is selected, and; (iv) alternative, among the set of related features exactly one of them is selected There are multiple notations for feature modelling. In our ap- proach, we have chosen to use an extended feature model inspired in the proposed one by Czarnecki et al. [21]. The feature model proposed by these authors enables introducing attributes to the features, where an attribute is any characteristic of a feature that can be measured. The reason of introducing attributes or any kind of information is to enable a more concise representation of fea- ture models. Of course, each attribute could be represented as a subfeature, but this quickly leads to very large and less under- standable feature models. In this perspective, we ground on this idea of introducing attributes to features in the feature model with the notion of properties, where these properties (in the form of <name, type, value> triples) regarding a feature represent any information about it, in special, in our context, cloud-related information such as pricing, availability, elasticity support, Quali- ty of Service (QoS) parameters, etc. Figure 1 shows a generic extended feature model that can be used to model cloud SPLs. For instance, the X1 feature contains information about the cloud service that is used by this feature, such as pricing model, availa- bility, response time, etc. In our approach, we use the feature model for distinguishing properties of the system as well as ex- pressing development alternatives.
181
I b f u p p b t a F c t p S t p t P c s b m T t i t a
Figure 1. A g pro
It is noteworthy ble and goes be feature model e useful in such properties rega products genera bles to monitor the choice of a aspect of the Following the combinations o to generate the price of each g Since the price that compose th price of f is add the price of a Pricing proper cloud services service provide because differe models, a typi Thus, with the them in the app is very importa the pricing asp any feature prop
generic extend operties related y that this idea o eyond of simple encompassing a model. Under
arding the featu ated from the S dynamic aspec
a product. For i products gener algorithm depic
of the features th e respective pro generated produ of a product is he product, for ded to the curr feature (proced
rty of the exte used by the fea er about the pr ent cloud prov cal situation in prices of all p
plication enginee ant to highlight pect of cloud se perty to select th
ded feature mod d to cloud appl of including pro attributes but a any sort of info this assumptio
ures to make i SPL. In additio cts of the applic instance, let us rated from a cted in Figure hat represent va oducts (line 1), uct p based on the sum of the
r each feature f ent price of p (
dure price(f) in ended feature m ature f, by cons rices. This can viders can ado n Cloud Comp products, the us ering process ba t that although ervices in this he proper produ
del encompassi lications. operties is very actually augmen ormation that m on, we can use inferences abou
on, our proposa cation that may
consider the p cloud-oriented 2, after definin
ariabilities in the , it is calculate these combina prices of all fea
f of a product p (line 4). To calc
n line 4), we us model regardin sulting the respe n be a complex opt different p puting environm ser can select o ased on their co we are concern paper, we coul uct.
Figure 3. HW-
ing
flexi- nts the
may be these
ut the l ena- affect ricing SPL.
ng the e SPL ed the ations. atures p, the culate se the
ng the ective x task ricing
ments. one of osts. It ned to ld use
Fi In me by and the to ser pro pro
4.2 Th wa [15 Ap ent qui pro sys pla SP Fig mo suc use per wh ces log Fil app the
-CSPL extende
Input: FM �– Output: pri
1: LP = Gen 2: for each 3: for eac 4: pric 5: end fo 6: end for
igure 2. Algorit terms of the a
ethod to gather looking at the
d analyzing how e SPL approach the requiremen rvices that fit th oposed the featu oduct line, as ex
2 The HW he HW-CSPL (H as developed fr 5]. HW was ori pache Tomcat) s t cloud platform irements. The oposed from the stem. In turn, th atforms led to th L.
gure 3 illustrate odel contains m ch as: (i) Depl ed to deploy the rsistence mech hich defines the ss, and; (iv) Lo g information. T le Storage, whi plication data) a ese features, the
ed feature mod
�– feature model ices �– a list cont
nerateProductL product p LP
ch feature f p ces[p] = prices[p or
thm for compu application eng the features tha
e existing or req w they could be , cloud applicat
nts since it is po he application n ures that compo xplained in Sect
W-CSPL sof Health Watche rom the origina iginally designe so that for an ap ms, it was nece
commonalities e requirements he different ser he features that
es the HW-CSP mandatory featu loyment, which e application; (i
hanism of the e infrastructure og System, whic This model als ich defines how are managed in
ere are alternativ
del.
l taining the price
List(FM) P do
do p] + price(f)
uting cost of pr gineering, a sim at will compose quired applicat
e placed on the c tions can be con ossible to choos needs. With this ose the HW-CSP tion 4.2.
ftware prod er Cloud Softwa al Health Watc ed to run in Jav ppropriated exe essary to know s observed in and features in
rvice facilities p t represent the
PL extended fe ures representin
h defines what ii) Persistence, application; (i used for the a
ch defines the so contains one w files (e.g. ima n the application ve feature group
es of all produc
roducts of a SP mple but effect e the cloud SPL tion functionalit cloud. So, throu nfigured accord e the proper clo
s in mind, we ha PL cloud softw
duct line are Product Li cher (HW) syst va containers (e cution over diff
w their specific HW-CSPL w
n the original H provided by clo variabilities in
eature model. T ng commonaliti cloud platform which defines ii) Login Syste
authentication p format for stor e optional featu ages related to n. For each one ps. For instance
ts
PL. tive L is ties ugh
ding oud ave
ware
ine) tem e.g. fer- re-
were HW oud the
This ies,
m is the em,
pro- ring ure, the
e of ,
182
t p b f t t P s m
I t c s v l 4 w F l c R i d u a
F u A h t P
4 I i C b p b
the Persistence persistence, rel by the Relatio features. In tur two additional the Relational Pricing, which service (in this model definitio
In order to enab the well-known compiling, prep should be com variables, and s lines) of code o 4 describes an e which enables t Figure 4, the co lational (lines 1 code regarding Relational Pers implemented u does not have n used a third-par as an Eclipse ID
Figure 4. Exam
Figure 5 depicts using the servic App Engine clo have used the s trates the use o Persistence feat
4.2.1 An exa In its original v in a local relat Connectivity) A base. For the persistence mec by AWS and G
e feature offers lational or non- onal Persistenc rn, the Non-Re options for non Persistence f refers to the p
case it refers n).
ble variation in n conditional c processor direc
mpiled or not b such decision m or to a whole so excerpt of code the access to th onditional comp 10 and 15) are u g two features rsistence) must sing the Java p native support f rty tool called A
DE plug-in, to a
mple of variabi the HealthWa
s the main four ces provided by oud platforms. D same technique of the condition ture since the sa
ample: the P version, HW sto tional database
API, which def Persistence fea chanisms that m
GAE cloud platfo
two options fo -relational, resp ce and Non-Re elational Persis n-relational per feature contains pricing model a to the address
the proposed SP compiling techn ctives indicate based on the va may be at level ource code file. of the HealthW
he business clas piling variables used to determin
(Relational Pe be compiled.
programming la for preprocessor Antenna Prepro annotate the sou
ility with condi atcherFacade c
HW-CSPL afor y Amazon Web Due to space re for all features
nal compiling te ame applies for
Persistence fe res data in mem
e, using the JD fines methods f ature, we have make use of th orms. The local
for application�’s pectively repres elational Persis stence feature sistence. In add s a property c
adopted by the of the AWS p
PL, we have ad nique. In condi pieces of code
alue of preproc of a line (or a For instance, F
WatcherFacade sses of the syste s relational or n ne when the enc ersistence and As HW-CSPL
anguage, and si r directives, we
ocessor [22], rel urce code.
itional compili lass.
rementioned fea Services and G estrictions and s, Section 4.2.1 echnique just fo the other featur
eature mory, using arra DBC (Java Dat for accessing a e implemented he facilities pro relational datab
s data sented stence offers dition, called cloud ricing
dopted itional e that cessor set of
Figure class,
em. In nonre- closed
Non- L was ince it e have leased
ing in
atures Google
as we illus-
for the res.
ays, or tabase
data- other
ovided base
Fi
wa we tha
Ac lay cal cla me rel imp RD per ser pos ma
In pro cla of tion sho rel bus var sid me by
5. In and how rith com an ana lin the
igure 5. Health fr
as replaced by th e have develope at uses the GAE
ccording to the yer is done thro lled AbstractRep asses that manip ents. The UML ated to the Pers ple-ments the G
DBRepositoryFa rsistence mech rvice provided sitoryFactory, w at, which is stori
Figure 6. UM classe
Figure 6, the Ab oviding method ass is used by th the persistence nal compiling ows the method ated to the pers siness layer. In riable persisten
dered to the com echanism will b a new object of
EVALUA Section 3, we
d variabilities o w our proposed hm can be used mpute the costs
evaluation of alyze the desig e, and in Sectio
e features that co
h Watcher func rom AWS and he Amazon RD ed another non- E�’s DataStore se
original HW ar ough the Facto positoryFactory pulate data rela
L Class Diagram sistence feature
GAE�’s non-relat actory class, w hanism using t
by Amazon R which impleme ing data in mem
ML Class Diagr es related to the bstractReposito ds to data persi he business laye e mechanism w is used based o d getRepository sistence implem
line 8 of Figur ce has value �“r mpilation proce
be done using a f the RDBRepos
ATION have described
of cloud-oriente d extended feat
d to derive cloud s of the differen
such proposed gn stability of t on 5.2 we discus ompose differen
ctionalities usin GAE platform
DS relational dat -relational persi ervice, a text-ba
rchitecture, the ory design patt y works as an a
ated to the appl m in Figure 6 e: (i) JDORepos tional persistenc
which impleme the relational
RDS service, an ents the origina mory using array
ram illustrating e Persistence fe oryFactory class istence, so that er to define whic
will be used. To on the selected
yFactory, which mentation that w re 7, if the cond relational�”, then ess. In this cas a relational data sitoryFactory cl
d how to establ ed SPL. We ha ture model and d product line a nt products. Thi d approach. In the HW-CSPL ss about cost est nt products in th
ng cloud servic ms. tabase service, a istence mechani sed database.
access to the d tern [20]. A cl access point to ication model e shows the clas sitory class, wh ce mechanism;
ents the relatio MySQL datab nd; (iii) ArrayR al persistence f ys.
g the Factory eature. s is responsible t an object of t ch implementat do so, the con
d feature. Figur h returns an obj will be used by ditional compil
n the line 9 is c se, the persisten abase, represen lass.
ish commonalit ave also describ d application al applications and is Section prese n Section 5.1,
software prod timation regard he SPL. Finally
ces
and ism
data lass the
ele- sses hich (ii)
onal base Re- for-
for this tion ndi- re 7 ject the
ling on- nce
nted
ties bed go- d to ents we
duct ding y, in
183
S m
5 W o o t m u e o L
A t c t c f a t
5 W W c
Section 5.3, we ment of the pro
Figure 7. getR
5.1 Chang We have quant of each feature original HW im typical change modified lines using these me effects, when in of different lev LOC.
As observed in this paper have changed or rem to the use of compared to d form, for examp added new featu the original HW
Table 2
Action
Chang
Chang
Added
Added
Chang
Added
Chang
Remo
5.2 Cost es We have quant We have also e compose the H
e point out som posed SPL.
RepositoryFact tenc
ge impact an titatively analyz e entails undes mplementation. impact measure of code (LOC
etrics is to qu ntroducing or c vels of abstrac
n Table 2, the S e reduced the am moved, as well a
the conditional developing diffe ple. It is import ures for the exi
W architecture, d
2. Change impa
n
ged classes
ged methods
d classes
d methods
ged inheritance r
d LOC
ged LOC
ved LOC
stimation titatively analyz estimated the d
HW-CSPL in A
me lessons learn
tory method rel ce feature.
nalysis zed to what ex sirable change This analysis es [23], such as C), among othe antitatively ass
changing a spec ction, e.g. clas
SPL developmen mount of LOC as classes and m l compiling tec erent modules tant to highlight isting code but w design patters or
act measures in
relationships
zed to what ex deployment cost Amazon Web S
ned with the dev
lated to the Per
xtent the introdu propagations i relies on a su
s number of add ers. The purpo sess the propag cific feature, in ses, operations
nt process appl needed to be a
methods, mainl chnique, probab for each cloud t that we have s we have not ch r dataflow.
n HW-CSPL.
Measures
83
178
15
171
0
1514
247
4
xtent the introdu t of the feature Services (AWS
velop-
rsis-
uction in the
uite of ded or ose of gation terms
s, and
lied in added, ly due bly if
d plat- imply anged
uction es that S) and
Go hav tion ope
Tab CS um nex it i Per thr pro day no wa the sm ana
Ta
H P
By pla is b pla In che eve ing quo ana
5.3 By sys obt obj clo pre pri cat fig AW
We pla and
oogle App Engi ve generated so ns of the afore erations, simula
ble 3 shows th SPL products in mn of Table 3 xt three column is provided by rsistence (P), a
ree columns sho oduct with the s ys. It is importa costs when the
as not included e application. A
mall for AWS an alysis, this infor
able 3. Estimat in A
HW-CSPL Products P
HW1 AW
HW2 AW
HW3 GA
HW4 GA
HW5 GA
HW6 GA
HW7 AW
HW8 AW
y analyzing Tab atform offers be bigger if comp
atform, the user this analysis, H eapest option to er, as described g the resource u otas provided alysis can be red
3 Lessons y proposing a p stem to generat taining a flexib jective was to
oud platforms, esent the best pr ice for storage a tion, then the ap
gured to store d WS.
e have verified atform would be d a big size pro
ne (GAE) cloud ome products r ementioned feat ating a normal u
he estimated d n the considere labels the HW
ns indicate whic AWS or GAE
and File Storag ow the cost (in selected features ant to highlight Google�’s authe in Table 3, as
As the values f nd GAE platfor rmation was om
ted deploymen AWS and GAE
Features
P FS
WS AWS A
WS GAE A
AE AWS A
AE GAE A
AE GAE G
AE AWS G
WS GAE G
WS AWS G
le 3, it is possib etter options in t ared to AWS. r will start to p HW5 product (h o be deployed u d in Section 5.1, usage, so that by the platform done and anoth
learned process to devel te products to b ble, dynamically analyze the HW intending also rices. For exam and GAE has a pplication can b data using the A
that producing e very tricky an oject. So, we ha
d platforms. Fo esulting from d tures and daily
use of the applic
deployment cos d cloud platfor
W-CSPL genera ch cloud servic E platform) for ge (FS) features n dollars) for ex s for a time peri t that as Login S entication servic well as local op for Log System rms, never reach mitted.
nt costs for HW E cloud platfor
Cost (d
D $/7
AWS 24.83
AWS 24.11
AWS 14.65
AWS 13.93
GAE 9.00
GAE 9.72
GAE 18.64
GAE 19.36
ble to observe th terms of price, s This means tha ay later than A
highlighted row using only GAE , our approach e if costs roughl ms are exceede er product can b
lop a SPL from be run on the c y changeable p W features dep to observe wh
mple, if AWS pla better price for be deployed in Amazon S3 se
different modu nd error prone, w ave decided to u
or this analysis, different combi y execution of cation.
sts for these H rms. The first c ted products. T e is being used
r Deployment ( s. Finally, the l xecuting the clo iod of 7, 30 and System feature h ce is being used ptions for runn
m feature are v hing $0.01 for t
W-CSPL produc rms.
dollars per days
$/30 $/90
98.82 295.8
96.24 288.3
58.40 174.8
55.82 167.2
33.84 101.5
36.42 103.6
74.26 222.5
76.84 230.1
hat the GAE clo since its free qu at, using the GA
AWS, for examp w in Table 3) is E�’s services. Ho envisions monit ly changes or f ed, then this c be selected.
m the original H loud, we aimed
product. Our m ployed in differ hat features wo atform has a be r hosting the app GAE and be c rvice provided
ules for each clo with repeated co use the conditio
we ina- the
HW- col- The d (if (D), last oud
d 90 has d, it ning very this
cts
s)
0
86
32
80
26
52
62
58
12
oud uota AE ple. the
ow- tor- free cost
HW d at
main rent ould tter pli- on- by
oud ode
onal
184
compiling technique that enables the selection of parts of the code according to preprocessor variables, which can be created, changed or excluded anytime. For example, considering the File Storage feature, if it is verified that AWS is offering a cheaper storage service when compared to GAE, then the s3 conditional compiling variable is set to the true value, thus enabling the code responsible for storing the HW images to use Amazon S3 service. In addition, we can disable the code responsible for storing imag- es at GAE Blobstore by setting the conditional variable googleImg to the false value. This process is similar for the other features. After choosing the desired parts of code that are enabled, the developer can easily generate the deployment file and host the application to start using the selected services.
As observed in Table 2, the SPL development process applied in this paper have reduced the amount of LOC needed to be changed, as well as classes and methods to be created. We have simply added new options for the existing code, with caution to not change HW�’s original architecture, design patterns or dataflow.
Although out of the scope of this paper, an important issue to be highlighted is the detailed monitoring of costs at runtime, which will provide information about better costs related to the services that are being used by the features. The optimal case is to dynami- cally deploy the features according to the best prices in the differ- ent cloud platforms. Currently, our cost algorithm computes the cost of all products and the user makes use of this pricing infor- mation to statically choose a product and the respective features to be deployed. However, as the pricing policy adopted by service providers can change at runtime and over time, it is necessary a dynamic monitoring cost algorithm.
6. RELATED WORK To the best of our knowledge, there are no proposals in the litera- ture that apply techniques to develop software product lines in the Cloud Computing context. As SOA and Cloud Computing para- digms share some concepts related to service-orientation (such as the notions of service itself, service provider and consumer and the contractual relationships between them, abstraction, loose coupling, and encapsulation), a natural way of thinking would be to extend or take advantage of some SPL-based approach for SOA. As we already mentioned, SOA and SPL approaches to software development have common goals, such as encouraging an organization to reuse existing assets and capabilities rather than repeatedly redeveloping them for new systems, thus enabling rapid and easy composition of loosely coupled distributed soft- ware applications and other benefits [15, 24]. However, as we present in this Section, the literature does not present many pro- posals for developing service-oriented applications as software product lines. Here we highlight some interesting ideas provided by these works and that could be applied to our approach in future works.
Lee et al. [25] and Lee and Kotonya [26] propose a method that consists of an adaptation from feature-oriented product line engi- neering applied to service-orientation. The key idea is to split the overall method in two main activities, namely feature analysis and service analysis. Somewhat similar to the domain engineering in traditional SPL approaches, the feature analysis is concerned to identify externally visible characteristics (commonalities and variabilities) of products in a product line and organizing them in an exploitable feature model. Then, this feature model is analyzed through a feature binding analysis, which consists of the identifi- cation of services features that represent a major functionality of a system and may be added or removed as a service unit. In turn,
the service analysis is intended to refine and restructure the fea- ture model previously generated by introducing a separation of two distinctive service categories: (i) behavioral (or orchestrating) services, whose main role is the composition of other services and to deal with preconditions, effects, and invariants associated with these services in order to maintain system integrity, and; (ii) com- putational (or molecular) services, which are the basic building blocks (that can be composed of other atomic services) and can be reused as-is by behavioral services. This separation of concerns made in these works seems interesting because it is intended to capture observable service-orientation characteristics (e.g. those regarding system integrity) usually present in service-based appli- cations and to try to correlate them with the feature model used as the main artifact of the SPL approach.
In turn, Medeiros et al. [27] propose an approach in which SOA applications are developed as software product lines. This ap- proach starts with an identification activity separated in two sub- activities: (i) component identification, which receives as input the feature model regarding the product line and produces a list of possible components, and; (ii) service identification, which re- ceives as input business process models and produces a list of service candidates for the product line architecture. Next, the variability analysis activity receives as input the lists of compo- nents and services identified previously and tries to reduce the number of candidates defining how variability will be implement- ed within services and components based on architectural deci- sions. Finally, the architecture specification activity receives the considered architectural decisions and is able to create different architectural views of the components and services, such as struc- tural view, dependency view, etc. As highlighted in this work, an important aspect that can be considered in future works is to take into account business process models and architectural decisions since these elements can provide important information to the product line engineering process.
7. FINAL REMARKS The pay-per-use model and the elastic nature of service provision- ing and de-provisioning of the Cloud Computing paradigm is very appealing to support complex applications mainly those that deal with computational and data-intensive activities. However, the development of complex applications that rely on services provid- ed by several underlying Cloud Computing platforms is a hard task due to the heterogeneity of Cloud Computing environments that hampers the development of applications using different cloud services.
To address this problem, this paper reports our experience in applying the software product lines (SPL) approach in the devel- oping of complex cloud-based applications. The contributions of the paper include: (i) a seamless adaptation of the SPL develop- ment process both at the domain and the application engineering phases in order to represent important information to cloud appli- cations as attributes of the feature model, and to provide an algo- rithm that calculates the cost of the different products to enable a product static selection based on the total pricing; (ii) the details of the development of a complex real-world application following our SPL process and their evaluation considering the design sta- bility and the cost estimation regarding the features that compose different products in the SPL, and; (iii) the lessons learned with the development of the application using the proposed approach.
It is worthwhile to mention that our SPL development process is generic and can be applied to other complex application domains. The use of extended feature model is not new but we are not
185
aware of any other proposal in the cloud domain. According to the evaluation presented in Section 5, we can conclude that our SPL approach is well suited for the use in the development of complex cloud-based applications.
Future works include the extension of this proposal to continuous- ly monitoring [28] the application cost at runtime in order to trigger dynamic adaptation for huge cost saving or even for achieving a trade-off between availability, elasticity, and cost. Once consumer plays an important role in the service-orientation context, we also intend to improve our approach in order to con- sider consumer-side aspects regarding the use of cloud services.
8. ACKNOWLEDGEMENTS This work was partially supported by the Brazilian Academic and Research Network (RNP) through the AltoStratus CTIC Project, and by the Brazilian National Council for Scientific and Techno- logical Development (CNPq). Thais Batista and Flavia C. Delica- to are partially supported by CNPq through the grants 307269/2010-8, 485935/2011-2, and 311363/2011-3. Nélio Cacho and Thiago Sena are partially supported by the Rio Grande do Norte Research Foundation (FAPERN), through the Project PPP- III-013/2009. Nélio Cacho is also partially supported by the Bra- zilian National Institute of Software Engineering (INES), founded by CNPq through the grant 573964/2008-4.
9. REFERENCES [1] Armbrust, M. et al. 2009. Above the clouds: A Berkeley view
of Cloud Computing. Technical Report. Reliable Adaptive Distributed Systems Laboratory, University of California at Berkeley, USA.
[2] Zhang, Q. et al. 2010. Cloud Computing: State-of-the-art and research challenges. Journal of Internet Services and Appli- cations 1, 1 (Apr. 2010), 7-18.
[3] Wang, L. et al. 2010. Cloud Computing: A perspective study. New Generation Computing 28, 2 (Apr. 2010), 137-146.
[4] Mell, P., Grance, T. 2011. The NIST Definition of Cloud Computing. NIST Special Publication. National Institute of Standards and Technology, USA.
[5] Rittinghouse, J., Randsome, J. 2010. Cloud Computing: Implementation, management and security. CRC Press, USA.
[6] Chhabra, B. et al. 2010. Software Engineering issues from the cloud application perspective. International Journal of Information Technology and Knowledge Management 2, 2 (Dec. 2010), 669-673.
[7] Sriram, I., Khajeh-Hosseini, A. 2010. Research agenda in cloud technologies. Computing Research Repository, Cornell University, USA.
[8] Rellermeyer, J., Duller, M., Alonso, G. 2009. Engineering the cloud from software modules. Proc. of the 2009 ICSE Work- shop on Software Enginnering Challenges of Cloud Compu- ting. CLOUD�’09. IEEE Computer Society, USA, 32-37.
[9] van der Linden, F. et al. 2007. Software product lines in action: The best industrial practice in product line engineer- ing. Springer-Verlag New York, USA.
[10] Clements, P., Northrop, L. Software product lines: Practice and patterns. Addison-Wesley, USA.
[11] Kang, K. et. al. 1990. Feature-Oriented Domain Analysis (FODA) Feasibility Study. Technical Report. Software Engi- neering Institute, Carnegie Mellon University, USA.
[12] Czarnecki, K., Helsen, S. Feature-based survey of model transformation approaches, IBM Systems Journal 45, 3 (Jul. 2006), 621-645.
[13] Pohl, K., Böckle, G., Linden, F. 2005. Software Product Line Engineering: Foundations, principles, and techniques. Springer-Verlag New York, USA.
[14] Erl, T. 2007. SOA principles of service design. Prentice-Hall, USA.
[15] ter Beek, M. et al. 2011. Product lines for Service-Oriented Applications �– PL for SOA. Proc. of the 7th Int. Workshop on Automated Specification and Verification of Web Sys- tems. WWV 2011. Electronics Proceedings in Theoretical Computer Science 61, 34-48.
[16] Soares, S., Borba, P., Laureano, E. 2006. Distribution and persistence as aspects, Software �– Practice & Experience 36, 7 (Jun. 2006), 711-759.
[17] Amazon Web Services (AWS): http://aws.amazon.com [18] Google App Engine (GAE): http://code.google.com/appengine [19] Hunter, J., Crawford, W. 2001. Java servlet programming,
2nd edition. O�’Reilly and Associates Inc., USA. [20] Buschmann, F. et al. 1996. Pattern-Oriented Software Archi-
tecture: A system of patterns. John Wiley & Sons, Ltd. [21] Czarnecki, K. et al. 2002. Generative Programing for Em-
bedded Software: An industrial experience and report. Proc. of the 1st ACM SIGPLAN/SIGSOFT Conference on Genera- tive Programming and Component Engineering. GPCE�’02. Lecture Notes in Computer Science 2487. Springer-Verlag London, 156-172.
[22] Antenna Preprocessor: http://antenna.sourceforge.net/wtkpreprocess.php
[23] Yau, S., Collofello, J. 1985. Design stability measures for software maintenance. IEEE Transactions on Software Engi- neering 11, 9 (Sep. 1985), 849-856.
[24] Njima, M. et al. 2011. Product line architectures for SOA. Proc. of the 11th Int. Conf. on Software Engineering Re- search and Practice. SERP�’11. CSREA Press, 227-232.
[25] Lee, J. et al. 2008. An approach for developing service- oriented product lines. Proc. of the 12th Int. Software Prod- uct Line Conference. SPLC 2008. IEEE Computer Society, USA, 275-284.
[26] Lee, J., Kotonya, G. 2010. Combining service orientation with product line engineering. IEEE Software 27, 3 (May 2010), 35-41.
[27] Medeiros, F. et al. 2009. Towards an approach for service- oriented product line architectures. Proc. of the 3rd Work- shop on Service-Oriented Architectures and Software Prod- uct Lines. SOAPL 2009. Software Engineering Institute, Carnegie Mellon University, USA, 151-156.
[28] Foster, I. et al. 2008. Cloud Computing and Grid Computing 360-degree compared. Proc. of the 4th Grid Computing Envi- ronments Workshop. GCE�’08. IEEE Computer Society, USA, 1-10.
186
