MobiCloUP!: a PaaS for cloud services-based mobile applications

Omar Colombo Mendoza

The integration of cloud computing and mobile computing has recently resulted in the Mobile Cloud Computing (MCC) paradigm which is defined as the availability of cloud services over a mobile ecosystem. Platform as a Service (PaaS) is a model of cloud computing that refers to high-level software systems delivered over Internet. This model typically enables developers to deliver Web applications as Software as a Service. With the aim of providing support to the MCC, in this work a PaaS called MobiCloUP! is proposed for mobile Web and native applications based on third-party cloud services such as Netflix, Instagram and Pinterest, to mention but a few. Unlike other commercial solutions such as force.com, Google TM App Engine and other academic proposals like MOSAIC, MobiCloUP! implements an automatic code generation programming model targeting rich mobile applications based on both Web standards such as HTML5, CSS3 and AJAX and Rich Internet Application frameworks like Adobe ® Flex. The MobiCloUP! core is a wizard tool that covers design, publish/deployment, development and maintenance phases for mobile development life-cycle. In order to validate our proposal, Web 2.0 services-based Web and native mobile applications were developed and deployed to the Cloud using MobiCloUP!. Finally, a qualitative-comparative evaluation was performed in order to validate the legitimacy of our proposal against other similar commercial proposals.

Autom Softw Eng DOI 10.1007/s10515-014-0143-5 MobiCloUP!: a PaaS for cloud services-based mobile applications Luis Omar Colombo-Mendoza · Giner Alor-Hernández · Alejandro Rodríguez-gonzález · Rafael Valencia-garcía Received: 14 December 2012 / Accepted: 9 February 2014 © Springer Science+Business Media New York 2014 Abstract The integration of cloud computing and mobile computing has recently resulted in the Mobile Cloud Computing (MCC) paradigm which is defined as the availability of cloud services over a mobile ecosystem. Platform as a Service (PaaS) is a model of cloud computing that refers to high-level software systems delivered over Internet. This model typically enables developers to deliver Web applications as Software as a Service. With the aim of providing support to the MCC, in this work a PaaS called MobiCloUP! is proposed for mobile Web and native applications based on third-party cloud services such as Netflix, Instagram and Pinterest, to mention but a few. Unlike other commercial solutions such as force.com, GoogleTM App Engine and other academic proposals like MOSAIC, MobiCloUP! implements an automatic code generation programming model targeting rich mobile applications based on both Web standards such as HTML5, CSS3 and AJAX and Rich Internet Application frameworks like Adobe® Flex. The MobiCloUP! core is a wizard tool that covers design, publish/deployment, development and maintenance phases for mobile development life-cycle. In order to validate our proposal, Web 2.0 services-based Web and native mobile applications were developed and deployed to the Cloud using MobiCloUP!. L. O. Colombo-Mendoza · G. Alor-Hernández (B) Instituto Tecnológico de Orizaba, Orizaba, Mexico e-mail: galor@itorizaba.edu.mx L. O. Colombo-Mendoza e-mail: lcolombo@acm.org A. Rodríguez-gonzález Polytechnic University of Madrid, Madrid, Spain e-mail: alejandro.rodriguezg@upm.es R. Valencia-garcía Universidad de Murcia, Murcia, Spain e-mail: valencia@um.es 123 Autom Softw Eng Finally, a qualitative-comparative evaluation was performed in order to validate the legitimacy of our proposal against other similar commercial proposals. Keywords Mobile Cloud Computing · Platform as a Service · Rich Internet Applications · Web 2.0 services 1 Introduction Cloud computing is a style of computing in which dynamically scalable and often virtualized resources are provided as a service over the Internet. Users do not need having knowledge of, expertise in, or control over the underlying infrastructure in the Cloud that supports the services rendered to them. Cloud computing refers to both the applications delivered as services over the Internet and, the hardware and systems software in the data centers that provide those services. The services themselves have long been referred as Software as a Service (SaaS) whereas the underlying high-level systems software and the low-level hardware have been known as Platform as a Service (PaaS) and Infrastructure as a Service (IaaS), respectively. Due to proliferation of mobile devices such as smartphones and tablet computers, which have leaded to ubiquitous mobile applications, i.e., applications that can be accessed at any time and from anywhere over the Internet by using mobile devices, cloud computing has taken advantage of mobile computing. At the same time, cloud computing has addressed the challenges of mobile applications development such as limited computational power, storage space and energy available on mobile devices. This is evidenced by the recent incursion of mobile operators such as Vodafone (Connecting to the Cloud, 2010), Verizon and Orange on the cloud computing market. Mobile computing is a paradigm that enables the use of computing capability without a predefined location and network connection. In this sense, it relies on the concept of mobility which is the ability to change the location of mobile elements while connected to the network (Forman and Zahorjan 1994). The integration of cloud computing and mobile computing has resulted in the Mobile Cloud Computing (MCC) paradigm which was originally defined as the availability of cloud services over a mobile ecosystem (Cox 2012). Besides the evident benefits of merging cloud computing principles in mobile computing, there are other advantages such as: (1) the possibility of maintaining back-ups of personal and enterprise data in the Cloud, especially for data-intensive mobile applications, (2) the possibility of innovating in mobile application marketing, i.e., in the way that applications are delivered to the users and (3) the possibility of offloading and centralizing diverse mobile collaborative applications in the Cloud. Netflix, Instagram and Pinterest are greater examples of companies having mobile applications running in cloud environments instead of physical data centers.1 With the aim of providing support to the MCC, we have developed a PaaS for cloud services-based mobile applications. Our proposal called MobiCloUP! is a cloud computing platform for developing, executing or hosting rich mobile applications based on an automatic code generation approach, Twitter REST, Yahoo! Weather 1 http://www.engineyard.com/infographics/mobile-cloud 123 Autom Softw Eng and finding eBay services are examples of the back-end cloud services used in our proposal. Unlike other available PaaSs like GoogleTM App Engine2 which is targeting Web applications, MobiCloUP! is targeted at rich mobile applications based on both HTML5-JavaScript and Adobe® Flex technologies. Therefore, MobiCloUP!-based applications can be accessed from any Web browser that supports HTML5 or can be installed as native mobile applications on the most popular mobile operating systems such as Apple® iOS and GoogleTM Android. In this sense, Brightcove APPCLOUD3 and Exadel Tiggzi4 mobile application platforms are similar to our proposal; however, they do not provide the infrastructure required to run the applications over Internet as SaaS. This paper is structured as follows: Sect. 2 presents a review of the state-of-theart on MCC. Section 3 presents a survey of the cloud services APIs considered in MobiCloUP!. Section 4 describes the architecture and main internals of MobiCloUP!. Section 5 explains a case study for the generation and deployment of a cloud-based mobile Web application using MobiCloUP!. Section 6 presents the method aimed at assessing the proposed PaaS by comparing it against other similar approaches. Section 7 presents the conclude remarks and the future directions are discussed. 2 State-of-the-art In recent years, several works have been proposed with the aim of supporting the growing field of MCC. According to an Engine Yard’s infographic entitled “A Mobile Storm in the Cloud”,5 PaaS represent an innovation in MCC. It predicts PaaS market will have grown by 30 % in 2015. In fact, two main kinds of proposals have arisen: (1) execution frameworks for bringing the benefits of cloud computing to mobile computing, i.e., frameworks for enabling cloud services in mobile environments and (2) solutions from cloud services providers, specifically PaaS, aimed at supporting mobile development through Standard Development Kits (SDKs), Integrated Development Environments (IDEs) and runtime environment emulators as are used in mobile application development based on native programming languages (Cox 2012). Our proposal tries to innovate the latter by avoiding the code-based development approach and, at the same time, it extends the support to thick clients in order to incorporate rich features such as sophisticated Graphic User Interface (GUI) behavior and client-side business logic. According to Fernando et al. (2013), MCC is still in its infancy; however, it could become the dominant model for mobile applications in the near future. Starting from a taxonomy of issues in MCC covering: end-user, operational, service and application, privacy and security, context-awareness and data management issues, an architecture for supporting the issues not yet sufficiently solved was presented. This architecture is composed of five components: (1) a job handler responsible for dynamically partition the applications and the required data sets, (2) a resource handler responsible for 2 https://developers.google.com/appengine/ 3 http://www.brightcove.com/en/content-app-platform 4 http://tiggzi.com/home 5 http://www.engineyard.com/infographics/mobile-cloud 123 Autom Softw Eng searching for and discovering new mobile resources as well as communicating with external mobile devices, (3) a cost manager responsible for determining the user priorities and deciding whether to offload or not the job, (4) a security and privacy manager and (5) a context manager responsible for providing inputs from device sensors. March et al. (2011) proposed a framework that merges mobile and cloud computing concepts for the development of rich mobile applications, a new generation of distributed mobile applications that provides rich functionalities. This framework called µCloud employs a software composition approach which allows creating the applications by mashing-up modular components. Indeed, the applications are modeled as directed graphs in which nodes represent cloud-side, device-side and hybrid components. µCloud addresses design challenges of cloud-enabled mobile applications, e.g., the reliability under diverse network conditions, including disconnection. It also addresses the typical constraints of stand-alone mobile applications such as the limitations of mobile devices resources and energy which are overcomed by offloading resource-intensive complex tasks to the Cloud. In addition, the application portability is achieved by implementing on the Cloud those tasks that do not require device-specific capabilities. MCC is the result of extending mobile computing paradigm with the possibility of sharing computing resources along distributed environments. In this sense, Mishra et al. (2012) proposed a mobile-based cloud computing framework for the integration of mobile applications with cloud services aimed at processing and data storage. This framework called Mobile-Cloud has a three-tiered architecture: (1) presentation tier which is composed of mobile browser and e-mail client components; (2) application tier which provides business logic through the integration of different cloud service providers, e.g., amazon web servicesTM and GoogleTM Apps; (3) database tier (cloud server) which enables communication with the cloud database for storing user’s and mobile subscriber’s data. It also manages mobile communication and provides security and back-up facilities. Tang et al. (2011) extended the traditional thin-client computing architecture towards a platform-independent design on mobile environments. The resultant multiplatform thin-client architecture uses Virtual Network Computing (VNC) desktop sharing system at client-side taking advantage of its many implementations available for all major operating systems. Considering that virtualization is an enabler of cloud computing, such architect deploys the server-side on cloud. In fact, the core of the architecture is a component that merges virtualization and distributed computing with the aim of running on the Cloud different emulators according to the client mobile operating system. Finally, a new trend in mobile application marketing which allows running applications on cloud for enabling cross-platform markets was issued. According to Hung et al. (2012), application redesign for the Cloud, lack of user control over deployed applications, as well as data privacy and data security on the Cloud are the major issues of cloud computing. In order to address these drawbacks, an execution framework for mobile applications which relies on a cloud-based virtualized execution environment is proposed. This framework prevents the user from redesigning existing client–server mobile applications for accessing resources in the Cloud and, at the same time, it provides a mechanism based on the pause-resume scheme supported by Android-based applications to easily migrating running applications 123 Autom Softw Eng from one mobile device to another. Unlike traditional cloud development, using this framework, the control in deployment, migrating and execution of mobile applications is given to the user and the applications itself. In addition, this framework addresses data privacy and security along cloud provider’s infrastructure by using encryption and isolation techniques. Kao et al. (2012) proposed a Web-based runtime environment for cross-platform offline-able mobile and desktop Web applications. This environment called WOPRE relies on iGoogleTM which is an environment for displaying HTML5-JavaScript gadgets within a customized GoogleTM homepage where gadgets are created by using the GoogleTM Gadgets Application Programing Interface (API). Moreover, WROPE is composed of three main subsystems: (1) a subsystem responsible for offline content management and data synchronization that uses the GoogleTM Gears API, (2) a subsystem responsible for Web content adaptation allowing developers to explicitly select the sections of Web content that can be displayed in mobile versions of Web applications and (3) an application market that represents an interface between developers and end-users for publishing and installing applications. Srirama et al. (2011) proposed a MCC middleware for mobile mash-up applications, i.e., applications that combines data from diverse cloud services. This middleware addresses mobile platform heterogeneity and cloud provider orchestration through an interoperability API engine. This engine is responsible of selecting the most suitable API provided by the requested cloud vendor according to the requester (mobile device) platform. This engine is also in charge of encapsulating the previously selected API in an adapter for accessing the remote cloud service. As a case study, a social group formation Android application was developed based on facial recognition by using diverse cloud services such as face.com® facial recognition service, facebookTM mobile apps service and different cloud storage services like Amazon S3. Following previous efforts on context-awareness mobility, Grønli et al. (2011) proposed a cloud-based mechanism for context-aware adaptation of Android home screens. This mechanism consists of two main components: (1) the customized home screen on device-side, which is adapted by using internal context awareness sources such as accelerometer and orientation mobile device sensors, (2) a Web-based application deployed on GoogleTM App Engine platform that allows users to set the preferences for adapting the home screen, e.g., the value supplied by light sensor that causes a change in home screen background color. The user preferences are saved in the Cloud, and then they are pushed to the Android-based devices taking advantage of the Cloud 2 Device Messaging (C2DM) Google’s framework. In addition, context awareness is also enabled by using cloud services such as GoogleTM Calendar and GoogleTM Contacts. Mao et al. (n.d.) proposed a cloud-based POSIX-compliant file system mainly designed for mobile devices. This file system called Wukong allows mobile applications to transparently access data in a cloud environment through diverse kinds of network connections. The core of the Wukong architecture is a layer called Storage Abstraction Layer (SAL) which abstracts heterogeneous cloud storage services APIs into uniform interfaces using a plug-in mechanism. Each one of the cloud services is directly accessed by a plug-in that is responsible for implementing the corresponding uniform interfaces hiding the details of the back-end services. The SAL layer also 123 Autom Softw Eng enables mash-up development because Wukong-based applications can uniformly use different storage services such as Amazon S3, GoogleTM Docs and GoogleTM Storage at the same time. In order to ensure portability between clouds, Petcu et al. (2012) presented an open source set of language-independent APIs as part of a larger platform proposed by an open source project team called Open Source API and Platform for Multiple Clouds (MOSAIC). In general, the MOSAIC architecture comprises a layered set of APIs, a set of application development tools, a semantic engine, an application resource provisioner, and a service discoverer, among other components. MOSAICbased applications are expressed in terms of two kinds of building blocks: (1) cloud resources which are controlled by cloud providers and (2) cloud components which are controlled by application developers. In this sense, the layered set of APIs comprises: (1) language-dependent implementations for creating cloud components as well as for abstracting cloud resources, (2) an API aimed at providing programming language interoperability and (3) an API for wrapping the cloud resource native APIs. With the aim of enhancing the overall performance of cloud, Li et al. (2009) proposed a middleware framework for mobile agent-enabled cloud computing. This framework called Mobile Cloud Framework (MCF) supports global invocation of cloud services deploying mobile agents which are known as mobile services and, at the same time, it provides a set of mechanism for transparently managing these services. In detail, the MCF architecture comprises three engines defining three kinds of services: (1) a resource services engine which encapsulates infrastructural resources such as computational, storage and I/O resources in the Cloud, (2) a backbone services engine which enables transparent management and utilization of mobile services and (3) a mobile services engine which enables mobile services invocation. Regarding commercial proposals, Force.com is a PaaS developed by Salesforce Inc. Force.com addresses Web, desktop and mobile applications focusing on the social enterprise. It has a metadata-driven multi-tenant architecture where applications are built using a non-general purpose programming language called Apex, an XML-based GUI markup language called Visualforce, Web standards such as HTML, CSS and JavaScript, as well as native programming languages like Objective-C and Java (Weissman and Bobrowski 2009). AMPchroma is an enterprise grade mobile cloud platform from Antenna Inc. It has an architecture composed of three major modules: (1) AMP Client: a runtime environment that enables “write-once” deployment to take advantage of native capabilities across devices, (2) AMP Server: a messaging middleware connecting mobile users to enterprise systems and (3) AMP Manager: a Web-based console for remote management of applications, devices and users. AMPchroma covers the entire mobility life-cycle, including high-level phases such as planning and design (2010). Based on the analysis obtained from the related works reviewed we can conclude that current platforms for MCC suffer from several drawbacks such as: (1) they use a code-based approach which implies more development time and effort and it also involves using diverse tools such as IDEs and runtime environment emulators, (2) they fragment development life-cycle by putting separately the tools for supporting application development and deployment and (3) they do not cover native mobile applications development and deployment. This work tries solving the aforementioned 123 Autom Softw Eng deficiencies by: (1) proposing an automatic code generation approach which allows saving development time, effort and budget, (2) presenting a unique Web-based tool which abstracts both application development and deployment processes starting from a software development process for mobile applications, (3) covering a mixed cloud/native mobile development approach for taking advantage of both computing areas while overcoming the limitations of each other. 3 A survey of cloud services APIs Cloud providers offer uniform APIs that enterprises can use to tailor the Cloud to their business processes. These APIs are typically based on the Representational State Transfer (REST) architectural style where the web services and any other kind of reachable object such as document or image files are viewed as resources. Resources are identified by their Uniform Resource Identifiers (URIs), and they can be accessed through a standard transfer protocol such as the HyperText Transfer Protocol (HTTP) using the GET, POST, PUT, and DELETE methods (REST Application Programming 2010). In this sense, each cloud provider must supply the URI that identifies its cloud itself. Cloud services providers considered on the MobiCloUP! architecture can be classified into four categories: I/O, computing, communication and Web 2.0 providers. This broad spectrum of services enables developers to develop not only Web 2.0 servicesbased applications but also domain-independent applications. However, because of the innovation resulting from integrating Web 2.0 services besides the typical cloud services, the main features of the Web 2.0 services APIs initially integrated in MobiCloUP!, namely, Twitter® REST API, Flickr® API, GoogleTM Custom JSON/Atom Search API, GoogleTM Maps JavaScript API, finding eBay® API, last.fm® API, YouTubeTM Player API, YouTubeTM Data API, DiggTM API and Yahoo!® Weather API are described in Table 1. Most of the aforementioned APIs are REST-based APIs. However, there are a few APIs partially based on both, the SOAP protocol and the REST style. In all cases, MobiCloUP! uses the REST-based style for interacting with these APIs. The functionalities provided by the cloud services APIs integrated in MobiCloUP! are wrapped using PHP-based classes. Therefore, if other cloud services APIs are incorporated to MobicloUP!, only the corresponding wrappers are added. In addition, taking into account that dynamic discoverability is an attribute of PaaS aimed at supporting rapid elasticity (Haddad 2011), we have proposed a passive discovery mechanism based on the HTML5’s Server-Sent Events API standardized by the W3C. This mechanism was inspired in the server push model where services announce their presence without the PaaS explicitly requesting (Marin-Perianu et al. 2005). The layers and components of the MobiCloUP! architecture are outlined below. 4 MobiCloUP! architecture MobiCloUP! has a four-tier architecture aimed at ensuring independence between developers of Cloud-based applications and cloud services providers. The proposed 123 Autom Softw Eng Table 1 Web 2.0 cloud services APIs used by MobiCloUP! Cloud services API Description Request formats Response formats Twitter® REST API The Twitter REST API methods let developers accessing core Twitter data, this includes: tweets and timelines, user information, saved searches, trending topics, among other Twitter data It lets developers interact with Flickr’s user accounts, manage stored photos and photo metadata, uploading new photos, manage photo galleries, manage Flick’ user groups, among other actions It enables developers to retrieve either web search or image search results searching over a website or a collection of websites by using a customized search engine powered by GoogleTM It allows developers to embed GoogleTM maps in desktop applications as well as in applications for mobile devices. It allows manipulating maps just like on the GoogleTM Maps website and customizing them by adding specific content The finding eBay® API allows developers to search for items listed on the eBay® website. It offers both standard search and search refinement capabilities It allows developers to interact with Last.fm® core data i.e. artists, albums and tracks stored on the Last.fm® website. Also, it allows managing user’s Last.fm® libraries and retrieving Last.fm® user accounts and user groups data It has 2 main items: (1) a data API; and (2) a player API. The data API allows to applications carrying out the actions that a user can carry out on the YouTube website. The player API lets developers controlling the YouTubeTM player through JavaScript or ActionScript functions REST REST, JSON, RSS and Atom REST, SOAP and XML-RPC REST, JSON, SOAP, XML-RPC and PHP REST JSON and Atom JSON JSON REST and SOAP REST, JSON and SOAP REST and XML-RPC REST and XML-RPC REST (YouTubeTM Data API) JSON, JSONIN.SCRIPT, JSONC, RSS and Atom (YouTubeTM Data API) Flickr® API GoogleTM JSON/Atom Custom Search API GoogleTM Maps JavaScript API Finding eBay® API Last.fm® API YouTubeTM API 123 Autom Softw Eng Table 1 continued Cloud services API Description Request formats Response formats DiggTM API It lets developers interact programmatically with DiggTM for retrieving information such as digg counts and comments related to the news stories and videos submitted to the DiggTM website. Also, it allows managing DiggTM user accounts It enables developers to get up-to-date weather information about wind, atmospheric pressure, humidity, visibility and astronomical conditions for specific locations Although this is not an official API, there is a public method exposed by GoogleTM that allows obtaining real-time feedback of search criteria similar to that a user enters during a search REST REST REST RSS REST REST Yahoo! Weather API GoogleTM Suggest API architecture enables traditional, static single-tenant deployment. Therefore, it does not address resource pooling which is commonly considered a cloud characteristic. In this sense, the MobiCloUP! architecture resembles the architecture of a cloud washed PaaS which, according to Haddad (2011), simply adds hardware virtualization and application platform provisioning. Moreover, because that the relevance of this work lies on an automatic code generation approach for developing cloud services-based rich mobile applications, the issues related to hardware virtualization are not addressed here. 4.1 Architecture description The proposed architecture is shown in Fig. 1. This architecture is composed of four layers; each layer fulfills a specific function by using a set of components whose tasks are described in following sections. 4.1.1 Cloud-based enterprise mobile applications Depending on their kind, applications built on top of MobiCloUP! architecture are accessed either remotely from mobile Web browsers or locally as native mobile applications. Notice that native mobile applications are not hybrid applications, i.e., applications built using Web technologies, and wrapped in a device-specific native application shell. For instance, PhoneGap is a popular mobile development framework that uses JavaScript, HTML5 and CSS3 technologies for building hybrid mobile applications. MobiCloUP!-based mobile Web applications have 123 Autom Softw Eng Fig. 1 MobiCloUP! architecture HTML/JavaScript-based front-ends whereas MobiCloUP!-based native mobile applications have MXML/ActionScript-based front-ends. In both cases MobiCloUP!based applications have PHP-based back-ends aimed at invoking back-end cloud services through API Wrapper components which actually are PHP-based classes. It is 123 Autom Softw Eng important to notice that this MVC-compliant three-tier architecture enables MobiCloUP!’s development tools to operate over the logic layer of any compatible legacy application in order to able communication with the MobiCloUP!’s Cloud Business tier without affecting the rest of the application. In fact, all the legacy presentation source code is wrapped into a single GUI view by using a set of front-end templates whereas the business logic tier is simply injected to add the PHP-based file (back-end file) aimed at enabling access to the set of cloud services supported by MobiCloUP!. According to the above, the easiest way to treat the legacy presentation source code is to embed an entire HTML5-based Web page into another or an entire ActionScriptbased application into another, according to the type of application to be migrated to MobiCloUP!. For this purpose, the object tag as well as the SWFLoader class must be used, respectively. In this sense, it may be required that the redundant functionalities (legacy presentation source code) are retired by hand once the application has been migrated to MobiCloUP!, i.e., once the legacy and new functionalities are coexisting. Regarding the legacy data, MobiCloUP! is currently able to migrate MySQL databases to the Cloud by using both the GoogleTM Cloud Storage and GoogleTM Cloud SQL third-party services. In detail, it allows migrating MySQL dump files (SQL files) containing both schemas and data. 4.1.2 Cloud business tier This layer is addressed by business consumers, i.e. MobiCloUP!-based applications users. Applications built using the tools in the lower layer are executed at this level. The entry point is the Request Handler component which acts as a gateway receiving all the requests for resource provisioning and workload offloading from applications. 4.1.3 Cloud platform tier This layer is addressed by MobiCloUP!-based application developers. It is designed for developing and deploying new applications from scratch as well as for migrating legacy compatible applications. In this sense, the main component of this layer is a Wizard GUI which allows developers to design, develop and publish (or deploy) both HTML5/JavaScript-based mobile Web applications and Adobe® Flex-based native mobile applications. Furthermore, this layer provides programming language-specific wrapper components for cloud services APIs allocated at lower layer. According to the above, MobiCloUP! implements a development process for rich mobile applications which covers almost all the phases of the typical mobile development life-cycle, namely, design, development, publishing (or deployment) and maintenance (About the Application Development Process 2012; Application Platform Overview for Windows Phone 2012). This development process does not cover neither the highest phase of mobile development life-cycle, i.e., planning nor the testing low-level phase. In detail, it is based on a configuration of the Phases Process for Multi-device RIAs Development (PPMRD) process (Colombo-Mendoza et al. 2012) which is a code generation approach for cloud services-based multi-device RIAs, i.e., Web browser-based RIAs, desktop RIAs and native mobile RIAs. PPMRD only covers 123 Autom Softw Eng design, implementation and deployment phases; hence, maintenance is conducted as an incremental deployment approach. Similarly, MobiCloUP! implements a migration process covering almost all the phases of the typical migration project life-cycle: design, migration, launch and postproduction. In detail, this migration process is based on both: (1) a migration methodology proposed by Oracle Company (Laszewski and Nauduri 2012), which is focused on database migration and (2) a best practices methodology proposed by BinaryTree Company (Binary Tree 2011) as part of a suite of IT solutions for enterprise collaboration and messaging software migration. It is important to notice that the launch (publishing or deployment) phase of the typical migration project life-cycle involves activities consisting on removing the legacy functionality in order to avoid possible redundant functions. Nevertheless, these removing activities are not currently addressed by MobiCloUP! so that they must be performed by hand once the migration phase has concluded. Into this layer, there are set of components with a specific functionality that is explained below. Wizard GUI is the source of GUI events triggered from interaction between application developers and MobiCloUP!’s development tools. In order to guide application developers through the phases of a well-defined process for the development of rich mobile applications starting either from legacy source code or from scratch, this component was designed following the wizard screen design pattern (Neil 2009). In fact, nearly each phase of either the MobiCloUP!’s development process or the MobiCloUP!’s migration process is implemented by means of one phase of the Wizard GUI. Source Code Generator which, depending on the required type of application, is responsible for: (1) generating application directory structures, (2) generating configuration files and (3) generating source code files. In fact, this component generates source code of rich mobile applications either in a deployable or installable form by using a set of templates. In addition, it generates source code files either starting from legacy source code or starting from scratch. In the former case, lexical analysis of source code files are required besides lexical analysis of templates. Native Applications Compiler is responsible for compiling the source code files of native mobile applications, i.e., the MXML/ActionScript-based source code files into SWF files. It is important to remark that the aforementioned files are generated by the Source Code Generator component. Resources Provisioner is responsible for identifying all the cloud services required by the MobiCloUP!-based applications during their initialization as well as for instantiating and provisioning the corresponding API Wrappers components. In fact, the instances of API Wrapper components are used by the applications to make calls to the back-end services and access the results returned in a standardized way. We have proposed using a descriptor file (Petcu et al. 2012) for identifying the cloud services required by an application. Furthermore, this file is an XML-based document encapsulating all the requirements specified by an application developer throughout the initial phases of the Wizard GUI. In this sense, it is automatically generated by the Source Code Generator component during applications design phase and it is used during applications development, deployment and execution. Figure 2 depicts the main elements of the MobiCloUP! application descriptor file. 123 Autom Softw Eng 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 <MobiCloUP!App> <type></type> <platforms> <platform id="" name=""> <certificate password=""></certificate> </platform> </platforms> <cloudServices> <web2.0> <cloudService id=""></cloudService> … </web2.0> <input&output> … </input&output> <computing> … </computing> <communication> … </communication> </cloudServices> <developmentSettings> <generalInfo> … </generalInfo> <mobile> <multiplatform> … </multiplatform> <android> … </android> <iOS> … </iOS> <blackBerryTabletOS> … </blackBerryTabletOS> </mobile> </developmentSettings> <deploymentSettings> <subdomain></subdomain> </deploymentSettings> </MobiCloUP!App> Fig. 2 MobiCloUP! application descriptor file 123 Autom Softw Eng Offloading Handler is responsible for deciding at runtime if a workload from a mobile device can be offloaded to MobiCloUP! in order to avoid the device overload and increase the application performance. For this purpose and considering the major approaches in offloading methods for MCC (Fernando et al. 2013), a client–server communication mechanism based on the W3C’s XMLHTTPRequest API was proposed in this work. During applications design, developers can indicate if common business logic operations, namely data sorting and data filtering, should be offloaded to the Cloud (see Sect. 5 of this paper). Then, during application execution, these preferences are evaluated by the Offloading Handler component considering the usage of hardware resources, namely RAM and CPU. This mechanism represents a first step towards rapid elasticity based on Web technologies (Zhang et al. 2012). According to Haddad (2011) rapid elasticity is another characteristic of cloud. Native Application Packager is responsible for packaging and digitally signing SWF files into application installers, namely .apk, .ipa and .bar files for GoogleTM Android, Apple® iOS and BlackBerry® Tablet OS operating systems, respectively. Thereby, it uses either Adobe® AIR® SDK tools or Blackberry® SDK tools. Furthermore, this component is also responsible for packaging all installation files generated for an application into a single ZIP file which is locally downloaded by the application developer. Once a ZIP file has been unpackaged, application installers can be easily installed on target devices. It is important to notice that unlike other proposals, MobiCloUP!’s development tools are intended to be deployed on remote resources over the Cloud. Web-based Application Deployer is responsible for deploying mobile Web applications to developer’s subdomains. In detail, for each mobile Web application developed, this component is responsible of: (1) generating one sub-directory within the MobiCloUP!’s deployment directory, (2) copying the source code files composing the application to the corresponding application’s sub-directory, (3) setting up the sub-domain required by the developer during the application deployment phase and (4) pointing the required sub-domain to the corresponding application’s sub-directory. This deployment process enables final users to access mobile Web applications via mobile Web browsers by using URIs. In addition, this component enables applications to be incrementally deployed or fully redeployed by using the Maintenance Tool, according to the configuration settings settled by developers during the application deployment phase. Maintenance Tool is responsible for providing facilities to manage already deployed MobiCloUP!-based applications. These functionalities include: applications shutdown, sub-domain changing, cloud provider changing, among others. In addition, in order to support the incremental deployment capability, this component is also responsible for enabling developers to deploy new versions of already deployed MobiCloUP!based applications by simply adding and removing back-end cloud services to the current instance of the application at runtime. Similarly, in order to support the fully redeployment capability, it allows developers to deploy a new version of an already deployed MobiCloUP!-based application by stopping the execution of the current instance of the application and deploying a new instance. API Wrapper Components are responsible for providing programming languagespecific functions that wrap cloud services API methods. These components enable 123 Autom Softw Eng MobiCloUP!-based applications accessing back-end cloud services. There is a wrapper component for each type of cloud service used in MobiCloUP!. Therefore, each wrapper component provides a uniform interface that merges heterogeneous cloud APIs of one type. This mechanism ensures interoperability among cloud services APIs of one type enabling applications to change the cloud service provider to be called at runtime. In the case of Web 2.0 APIs there is a wrapper component for each category of cloud service, namely video, mapping and micro-blogging services to mention but a few. Data Manager allows retrieving the necessary application templates, configuration file templates and Cloud-based components from repositories during source code generation. Furthermore, this component is responsible for performing low-level tasks related to the file system managing during: (1) source code generation (application development phase), (2) application installers packaging (application publishing phase) and (3) ZIP files packaging. It is important to remark that this component is responsible for managing all the resources provided by developers not only during the development of new applications but also during the migration of existing applications. In this sense, all the legacy source code files composing a legacy application must be provided by means of a single ZIP file. According to the above, a migration ZIP file must package: (1) HTML5/JavaScript-based files or MXML/ActionScript-based files, depending on the type of application to be migrated and (2) PHP-based files. 4.1.4 Data tier This layer is mainly aimed at storing XML-based documents by means of a set of repositories which represents the core of the source code generation process. Templates Repository enables persistence for MXML/ActionScript-based application front-end templates, HTML5/JavaScript-based application front-end templates, PHP-based back-end templates as well as configuration files such as Adobe® AIR application descriptor files. On the one hand, MobiCloUP! uses an application frontend template for each type of rich mobile application to be developed, i.e., for mobile Web applications and for native mobile applications. On the other hand, descriptor file templates are specialized according to the mobile operating systems supported by MobiCloUP!, i.e., there is one type of descriptor file template for each mobile operating system supported. Cloud-based Components Repository enables persistence for application building blocks, i.e., source code files that can be reused according to the cloud services required. A Cloud-based component comprises either an MXML/ActionScript-based GUI component (About MXML Components n.d.) or an HTML5/JavaScript-based GUI component (Introduction to Web Components 2012). The use of application frontend and back-end templates in conjunction with Cloud-based components enables MobiCloUP! incrementally deploy mobile Web applications by simply adding and removing Cloud-based components. In fact, this is considered a PaaS attribute aimed at supporting the on-demand self-service cloud characteristic (Haddad 2011). Users Data Repository provides database storage for MobiCloUP! users data, i.e., data of MobiCloUP!-based application developers. 123 Autom Softw Eng 4.1.5 Resources tier Although many cloud services providers offer programming language-specific APIs, i.e., libraries, this layer has a set of cloud services APIs exposed as REST-based APIs. It has not only I/O, processing and communication cloud services but also Web 2.0 cloud services. We have proposed to integrate Web 2.0 services along to the common system resources services such as database storage and message queues. In this sense, MobiCloUP! architecture integrates video, music, photo, e-commerce, search, bookmarking and micro-blogging services. Services API Catalog is a catalog of REST-based services inspired by the Universal, Description, Discovery and Integration (UDDI) registry. This component is the entry point of service discovery process. Like API Wrappers, there is a catalog page for each category of cloud service integrated into MobiCloUP!. These pages abstract cloud APIs data such as services URIs, supported HTTP methods, required parameters, among others. 4.1.6 Cloud services providers Although cloud providers are not involved into the MobiCloUP! architecture, supplied cloud services represent its back-end. Thus, cloud providers are considered secondary actors in the context of MobiCloUP! use cases. In detail, Web 2.0 providers involved in MobiCloUP! design are: Twitter, Yahoo!, eBay, Flickr, Last.fm, Google, Digg and YouTube. 4.2 Workflow description The relationships among components of MobiCloUP! architecture describe two workflows where functionalities are executed in a sequentially way: (1) application publishing/deployment and (2) application execution. These workflows describe the architecture’s functionality. The phases of the application deployment sub-workflow to be processed during the execution of the MobiCloUP! architecture are depicted in Fig. 3. The phases of the application execution workflow are depicted in Fig. 4. 4.2.1 Application deployment sub-workflow (1) Once the message indicating the success of the source code generation process is displayed by the Wizard GUI component, either the native code generation process in the case of native mobile applications or the application deployment process in the case of mobile Web applications are triggered. The Native Applications Packager component listens to the event identifying the completion of the corresponding phase of the wizard. (2) If a native mobile application was generated, then the Native Applications Packager component calls to the Data Manager component for requesting the 123 Autom Softw Eng Fig. 3 Application deployment process Fig. 4 Application execution process execution of the Adobe® Flex SDK ADT tool which allows generating application installers. (a) As outcome, an .apk, .ipa or .bar file is generated by the Data Manager component, and then it is located within the root directory of the application directory structure. Finally, a value that indicates the successful or failed execution of the low-level operation is returned. (b) If the Data Manager component indicates that the application installer was successfully generated, then the Data Manager component is called again for requesting building the response to be presented to the developer. 123 Autom Softw Eng (c) As outcome, a unique ZIP file packaging both the application source code and the application installer is generated by the Data Manager component. The ZIP file can be downloaded by the developer at the end of the wizard. (d) If the Data Manager component indicates that the ZIP file was successfully generated, then the Native Applications Packager component calls the Wizard GUI component for displaying a message as a response to the request initially made by the developer. (e) The Wizard GUI displays both a message indicating the success of the entire code generation process and a “download ZIP file” option. (f) The developer downloads the ZIP file by clicking the “download ZIP file” option. Once the ZIP file was unpacked, a directory structure containing the corresponding application installers is obtained. At this point, the application can be installed on target devices. (3) If a mobile Web application was generated, then the Native Applications Packager component calls the Web-based Applications Deployer component. (a) The Web-based Applications Deployer component parses the MobiCloUP! application descriptor file in order to extract the deployment parameters, and then it uses them for configuring the MobiCloUP! Web server and setting up the sub-domain required by the application developer. Then, application source code files are copied to the MobiCloUP! deployment directory for enabling users to access the application via mobile Web browsers. Finally, the Webbased Applications Deployer component calls the Wizard GUI component for displaying a message as a response to the request initially made by the developer. (b) The Wizard GUI displays a message indicating the success of the entire code generation process. 4.2.2 Application execution workflow (1) Once the application was either deployed on the MobiCloUP! platform or locally installed on a mobile device, its back-end cloud services can be invoked. In detail, mobile Web applications are accessed by using an URI composed of the MobiCloUP! domain, the developer’s sub-domain and the application name. Moreover, although native mobile applications are locally accessed on mobile devices, they have back-ends that communicate with MobiCloUP! via HTTP requests. This workflow treats the execution of a mobile Web application. (2) In order to trigger the initialization process, when an Application Front-end is requested from a Web browser, an asynchronous HTTP request is sent to the Request Handler script via the W3C’s XMLHTTPRequest API (AJAX technology). (3) The Request Handler script identifies the incoming request, and then it determines the Deployment Support’s component to be called. In the case of a resource initialization request, the Resource Provisioner component is called whereas in the case of a workload offloading request, the Offloading Handler component is called. 123 Autom Softw Eng (4) The Resources Provisioner component carries out the application initialization process as follows: (a) it searches for the corresponding MobiCloUP!-based application descriptor file, (b) once the descriptor file is found, it is parsed with the aim of identifying the set of cloud services mapped to the application and (c) finally, the necessary API Wrapper components are instantiated. (5) Once the application initialization process has been finished and the application has been completely rendered (if applicable), the user requests the execution of a back-end cloud service by displaying an application view and submitting a form via AJAX. (6) The Application Back-end analyses the submitted data in order to identify the requested back-end cloud service and determine the API Wrapper to be called. The retrieved data are sent as part of the call. (7) The API Wrapper receives the user parameters, and it builds the final URI adding these parameters to the base URI of the back-end resource. Finally, this component sends an HTTP request to the back-end resource by using the final URI. (8) The Cloud Service Provider’s infrastructure processes the incoming request, and then it calculates the data to be returned as response. (9) The corresponding API Wrapper processes the response from the Cloud Service Provider’s infrastructure. In detail, this component extracts the received data, and then it encapsulates them in an XML-based document if the back-end cloud service uses another format such as JSON, RSS or Atom. In fact, all the responses from back-end cloud services are homogenized by using a common XML-based structure. Finally, this XML-based document is returned to the corresponding Application Back-end. (10) The Application Back-end forwards the XML-based document encapsulating the data from the requested back-end cloud service to the Application Front-end. (11) The Application Front-end parses the retrieved XML-based document with the aim of extracting the relevant data, and then it adds these data to a data structure which is used as source of data binding to a GUI control aimed at displaying data. In order to explain the MobiCloUP!’s functionality, a case study for generating and deploying a Web 2.0 services-based mobile Web and native applications is presented below. 5 Case study: migrating and redesigning a legacy mobile web application MobiCloUP! is a PaaS for both mobile Web applications based on HTML5/JavaScript technologies and native mobile applications based on the Adobe® Flex framework. It guides developers through application development or migration processes in a step by step way by using a unique wizard tool. Furthermore, MobiCloUP! has adopted an automatic code generation approach rather than a code-based development approach. According to the above, MobiCloUP!’s wizard tool implements two different scenarios: (a) new application development and (b) legacy application migration. In detail, these scenarios are abstracted by the wizard’s phases in a way that the developer must perform the following steps: (1) select the type of application to be developed; here, 123 Autom Softw Eng the scenario to be carried out is determined by indicating whether or not existing application source code will be reused. In this sense, the following steps are explained in the context of the legacy application migration scenario, (2) select the cloud services to be used in order to redesign the legacy application, (3) set the development (application configuration) settings, (4) import the source code files of the existing MobiCloUP!-compliant application to be migrated to the Cloud; in addition, existing MySQL databases can be imported by means of SQL dump files and (5) set the packaging or deployment settings. To thoroughly explain the aforementioned steps, a case study for migrating, redesigning and deploying a legacy mobile Web application by implementing a MySQL/HTML5/PHP MVC pattern is explained below. The redesign process implies the usage of Goggle Storage and Yahoo!® Weather Cloud services. At the same time, this case study represents a means to exemplify the RIA-like features of MobiCloUP!-based applications, namely, the support for rich GUIs: interaction design patterns and support for sophisticated client–server communication mechanisms: retrieving data from two or more simultaneous sources, both in asynchronous and synchronous way. Let us suppose that a small enterprise 2.0 needs to carry out a Cloud-based migration process from a traditional Web application optimized for mobile devices and hosted on its data center, i.e., locally, in order to dynamically meet the growing business demands related to the complexity and size of its data and reduce the implied costs. In detail, this application has an MVC-compliant three-tier architecture composed of: (1) an HTML5/JavaScript presentation layer, (2) a PHP-based logic layer and (3) a MySQLbased data layer. It is important to notice that this architecture is compatible with the architecture of the MobiCloUP!-based mobile Web applications. Furthermore, the functionality of this architecture is described as follows: the application allows users to sign up and log in, trace travel routes on maps of GoogleTM Maps, save the routes traced, retrieve lists of stored routes and retrace stored routes. In detail, the application uses a central SQL database for data persistence of travel routes as well as users’ data. In this sense, the GoogleTM Cloud Storage API seems to be a suitable option for the migration of the legacy database. In addition, the application needs to be redesigned in order to allow users to get weather information for the locations composing travel routes. Here, the Yahoo! Weather API seems to be a suitable option. Considering that mobile application developers are increasingly looking for solutions to the typical constraints of mobile devices, proposals such as MobiCloUP! become relevant. Moreover, assuming that time and effort saving are major constraints in software development, MobiCloUP! offers also a solution to this issue in terms of: (1) a set of HTML5/JavaScript-based and MXML/ActionScript-based mobile application templates, (2) a set of HTML5/JavaScript-based and MXML/ActionScript-based reusable GUI components for consuming cloud services and (3) a wizard tool which allows generating and deploying mobile Web applications as well as native mobile applications for different platforms and devices through the following steps: (a) The application developer request accessing MobiCloUP! via a Web browser by using a URL. (b) As a result, the MobiCloUP!’s login form is displayed. An application developer must be authenticated with the corresponding credentials, namely, username and 123 Autom Softw Eng Fig. 5 MobiCloUP! user authentication process password provided during user registration process in order to access MobiCloUP!. In this sense, username and password must be entered as is depicted in Fig. 5. (c) Once the developer has been authenticated, the Wizard GUI is displayed. The first wizard phase is the selection of the type of application to be generated. The developer can choose between two options: (1) a mobile Web application or (2) a native mobile application. If the development of a native mobile application is required, then the target mobile operating systems must also be selected in this wizard phase as is depicted in Fig. 6. This is because the native code generation depends on the target technologies. In addition, the developer can indicate that the development is conducted starting from legacy source code, i.e., that an existing MobiCloUP!-compliant application will be migrated to the Cloud. Otherwise, the development is conducted starting from scratch. (d) The next phase is the selection of the cloud services to be included which provide functionalities to the applications to be generated. Cloud services supported by MobiCloUP! are classified into four categories: (1) Web 2.0, (2) I/O, (3) communication and (4) computing services as are depicted in Fig. 7. Developers can select one or more cloud services, even from different categories. In the case of Web 2.0 category, each one of the selected services is implemented by a GUI component which is displayed as an application view. It is important to notice that applications to be generated use a view-based navigation model which allows designing mobile applications composed of a set of full-screen views. In fact, we have developed both a MXML/ActionScript-based GUI component and an HTML5/JavaScriptbased GUI component for each Web 2.0 service supported by MobiCloUP! (see Sect. 4 of this paper). These components are the application building blocks, and they are reused during source code generation irrespective of the required type of application. In the case of I/O cloud services, each one of the selected services is implemented by means of a set of PHP-based data access scripts which are aimed 123 Autom Softw Eng Fig. 6 Selecting the type of application to be generated by using MobiCloUP! Fig. 7 Selecting the cloud services to be included at managing data from Web 2.0 cloud services. Furthermore, the necessary database schema script is automatically generated and executed in the Cloud. In this sense, at GUI design level, the GUI controls intended to trigger SQL data manipulation operations (INSERT, SELECT, UPDATE and DELETE) are automatically added to each of the application’s views, i.e., to each Cloud-based component. Additionally, a set of PHP-based data access scripts aimed at managing data about intended users and the corresponding database schema script are generated by the Source Code Generator component by default. It is important to remark that, at 123 Autom Softw Eng this point in the development, the design phase of the MobiCloUP!’s migration process outlined in Sect. 4 of this paper is initiated. Thus, legacy functionalities likely to be replaced by means of one or more cloud services offered by MobiCloUP! can be determined in this phase. Similarly, new functionalities to be integrated to the legacy application by means of other Cloud-based components can be optionally determined in this phase. In this sense, according to the scenario stated at the beginning of this section, the Google® Maps Cloud service of Web 2.0 category is selected only as a means to compare a legacy function to a corresponding MobiCloUP!-based function, the Yahoo!® Weather cloud service of the same category is selected as a new requirement towards the redesign of the legacy application. In addition, the GoogleTM Cloud Storage service of I/O category is selected as a means to migrate the legacy database. Figure 7 depicts both the set of cloud services of Web 2.0 category supported by MobiCloUP! and the set of cloud services of the same category selected in this case study. (e) Once the required cloud services are selected, the initial application configuration settings are settled according to the type of application to be generated. These configuration settings are provisional in the sense that they can be modified during the post-production phase of the MobiCloUP!’s migration process by using the Maintenance Tool. On the one hand, they are parameters applicable to both types of application offered by MobiCloUP!, i.e., multiplatform parameters, such as: (1) application name, (2) application title, (3) application DPI which allows automatically scaling application for different screen densities, where density is the number of dots or pixels per square inch, (4) application navigation model which can be a view-based model or a tabbed application model and (5) application style which comprises details of the application’s look and feel such as the background and font colors for the intended application template. On the other hand, they are parameters only applicable to native mobile applications. In detail, they are: (1) parameters applicable to all mobile operating systems, i.e., multi-device parameters such as the full-screen mode and the screen auto-orienting feature and (2) platform-specific properties such as the iPhone® /iPad® support and the style for the Apple® iOS status bar in the case of applications for Apple® iOS-based devices or the transparent background property and the splash screen feature in the case of applications for BlackBerry® Tablet OS-based devices. It is important to notice that application templates use a typical header/center/footer structure as is proposed by the HTML5 standard. In addition, the aforementioned GUI design decisions can be made in the context of a redesign project as is proposed in this case study. Thus, the look and feel of the application to be migrated to the Cloud must be taken into account at this point in the development. In fact, the design phase of the MobiCloUP!’s migration process is partially automated by this phase of the wizard tool. In this sense, the look and feel of the MobiCloUP!-based mobile Web applications is defined by means of CSS files whereas the look and feel of the MobiCloUP!-based native mobile applications is defined by means of Spark skins. Here, a Spark skin is a MXML class controlling all visual elements of a component of the Adobe® Flex Spark architecture including layout. The initial configuration settings settled in this case study for the development of a MobiCloUP!-compliant mobile Web application are depicted in Fig. 8. Finally, it is important to notice 123 Autom Softw Eng Fig. 8 Setting the development configuration of the application to be generated that, at the end of this wizard phase a MobiCloUP! application descriptor file is automatically generated by the Source Code Generator component. In fact, as it is explained in Sect. 4 of this paper, this file is generated starting from the parameters settled by the developer throughout all the previous wizard phases. (f) Once the application configuration is finished, the source code files composing the legacy application are uploaded to MobiCloUP! by means of a ZIP file as is depicted in Fig. 9. In this sense, a migration ZIP file must contains: (1) one or more HTML5/JavaScript-based or MXML/ActionScript-based files, (2) one or more PHP-based files, (3) one or more CSS files or Spark skin files and (4) a set of multimedia resources such as images and videos. It is important to remark that, at this point in the development, the core phase, i.e., the migration phase of the MobiCloUP!’s migration process outlined in Sect. 4 of this paper is initiated. In detail, the imported ZIP file is immediately unpacked in order to determine whether or not the application is a MobiCloUP!-compliant application, i.e., an MVC three-tier architecture. For this purpose, a series of lexical analysis of both presentation and business logic/data access files are performed according to the type of application to be migrated to the Cloud. Moreover, a dump file (SQL file) containing the SQL statements necessary to recreate a legacy database in the Cloud can also be uploaded to MobiCloUP! by means of this wizard phase. In this sense, the Source Code Generator component is able to determine whether or not the provided dump file contains MySQL-compliant statements. Besides providing the legacy source code files, the developer must conduct the activities explained below. In the case of mobile Web applications, the developer must indicate which of the presentation files, i.e., which of the HTML/JavaScript-based files or PHPbased files containing or generating HTML tags is the initial file, i.e., the file that must be accessed via a mobile Web browser when the application is invoked by a user. In the case of native mobile applications, the MXML/ActionScript-based file 123 Autom Softw Eng Fig. 9 Uploading the legacy application files implementing the top-most component container for Adobe® Flex-based mobile applications is automatically identified by the Source Code Generator component. According to the above, the PHP-based files imported as part of the aforementioned ZIP file are internally classified into one or the following two categories: (1) presentation files or (2) business logic/data access files, irrespective of the type of application to be migrated to the Cloud. In detail, the PHP-based files defining classes are automatically classified as business logic/data access files whereas the PHP-based files containing or generating HTML tags are automatically classified as presentation files. Once the legacy source code files have been validated by the Source Code Generator component, a source code generation process can be triggered in this wizard phase by using the “generate a MobiCloUP!-based app” option. In fact, in the context of migrating a legacy application, this code generation process is intended to generate a MobiCloUP!-compliant application that reuses the previously provided legacy source code files. In detail, a set of MobiCloUP!-compatible source code files are generated by using an application front-end template, an application back-end template and one or more predefined Cloud-based components (see Sect. 4 of this paper). On the one hand, each one of the required new functions is provided by means of a Cloud-based component which is added to the application front-end template as a view. On the other hand, all the legacy functions are added to the application front-end template into another view by wrapping the main presentation file (default HTML-based file). As can be inferred, MobiCloUP! is no able to recompose or refactor legacy GUIs in order to introduce the new functionalities (Cloud-based components) into the legacy Web applications. It is important to notice that, the wizard tool displays information messages in a console while the source code is being generated. (g) The next phase of the wizard is either the deployment of the mobile Web application to the MobiCloUP!’s production infrastructure or the native code generation, 123 Autom Softw Eng i.e., the generation of the installation files required to locally deploy the native mobile application on all target devices. In fact, this wizard phase automates the launch phase of the MobiCloUP!’s migration process. In the case of mobile Web applications deployment, there are few settings to be configured in this wizard phase before the application is launched: (1) the name of the sub-domain to be set up in order to release the application to potential users, (2) the name to be used by users to access the application. By default, the latter parameter is taken from application configuration settings settled in the third wizard phase. However, it can be changed if necessary. These both settings are used by the Web-based Applications Deployer component to build the URIs of the applications to be launched. In detail, an application URI is built by concatenating the following three elements: (1) the MobiCloUP!’s domain which is shared by all the applications in the MobiCloUP! ecosystem, (2) the developer sub-domain which can be used by more than one application at the same time and (3) the application name. Figure 10 depicts the configuration settings settled in this case study for the deployment of the MobiCloUP!-compliant mobile Web application. It is important to remark that the Web-based Applications Deployer component generates one sub-directory within the MobiCloUP!’s deployment directory for each mobile Web application developed. Thereby, the source code files composing a mobile Web application are copied to the corresponding application’s sub-directory. Finally, the application’s sub-directory is pointed to the sub-domain set up by the developer in this wizard phase. In the case of native code generation, the wizard asks for the digital certificate files and corresponding passwords needed to sign an installation file for each target platform initially required. In the specific case of signing applications for Apple® iOS-based devices, provisioning profiles must also be provided. A provisioning profile is a file which associates an Apple® iOS-based device with a digital certificate and with a previously registered Apple® iOS application. These Fig. 10 Deploying the application to MobiCloUP! 123 Autom Softw Eng files can be created in the Apple® iOS provisioning portal. Irrespective of the type of application to be launched, the developer can also activate the “incremental deployment” option. Otherwise, new versions of the application are fully redeployed which means stopping the already deployed instance of the application instead of just enabling or disabling back-end Cloud services on the already deployed version of the application at runtime. (h) The last phase of the wizard is either the access to the previously generated mobile Web application in a preview mode or the automatic generation of a ZIP file packaging the source and native code of the previously generated native mobile application. In the first case, the preview mode is intended to ensure the adequate functioning of an application before releasing it to its potential users. Additionally, at this point in the development, the application can be tested on different mobile devices like in a testing environment. For this purpose, the “pre-release application” option must be used. This option allows developers to release applications on randomly built URIs which are alternatives to the URIs provided by MobiCloUP! in the previous wizard phase. This feature prevents developers from releasing “beta” applications on their production sub-domains and, at the same time, prevents undesired users to access applications are being tested. Furthermore, a “release application” option is displayed from the beginning. The developer can finally release the mobile Web application by clicking this option. In the second case, once the ZIP file is generated, a “download ZIP file” option is displayed. The developer downloads the ZIP file by clicking this option. In both cases, the wizard tool finishes here. Once the MobiCloUP!’s migration process has been finished; there may be coexistence of legacy and new functionalities. In this sense, the application can be accessed in an edit mode by using the Maintenance Tool in order to solve possibly redundant functionalities, i.e., the “legacy functionalitynew functionality” pairs that are redundant. For instance, according to the scenario stated for this case study, a set of session management functions are provided by the legacy application. However, a set of standard session management functions are automatically obtained as a result of any MobiCloUP!’s migration project involving a legacy database and any MobiCloUP!’s development project requiring a new database. The decisions of whether the legacy functions must be preserved are made at this point in the MobiCloUP!’s migration process, i.e., as part of the post-production phase. In this case study, the legacy functionality is retired. The execution in preview mode of the previously deployed application is depicted in Figs. 11 and 12. In order to determine the correct functioning of MobiCloUP!, we have implemented a set of complementary case studies for developing mobile Web applications and native mobile applications based on other third-party Web 2.0 cloud services such as eBay® Finding and GoogleTM Custom Search services as well as on other third-party I/O Cloud services such as the Amazon® Simple Storage Service (S3). Furthermore, additional case studies for developing applications based on cloud services of other categories supported by MobiCloUP! such as Amazon® Simple Notification Service (SNS) from Communication category can be easily implemented. A screenshot of the 123 Autom Softw Eng Fig. 11 Executing the application in preview mode (legacy application’s view) Fig. 12 Executing the application in preview mode (Yahoo! Weather’s view) resultant mobile Web application running on a Motorola® XOOMTM tablet computer is depicted in Fig. 13. 6 Evaluation and discussion Although Cloud computing literature has produced several works related to software architectures addressing common challenges of developing and provisioning 123 Autom Softw Eng Fig. 13 Screenshot of the previously generated mobile Web application (Yahoo! Weather’s view) running on the Firefox 22.0 Web browser on a Motorola XOOMTM tablet computer cloud-based applications by using PaaS models, the absence of a standardized way to validate these proposals is still an issue. In fact, there are three general approaches: quantitative (objective), qualitative (subjective) and hybrid (quantitative–qualitative) evaluations. According to Kitchenham (1996) quantitative evaluations consists on identifying in measurable terms the effects of using Software Engineering methods/tools; in contrast, qualitative evaluations (feature analysis) consists on establishing the methods/tools appropriateness in terms of the features provided by the methods/tools themselves. Furthermore, due to the existence of several alternative ways of performing the same Software Engineering task or activity, evaluations must be addressed as comparison analysis between diverse methods/tools in specific circumstances. In this sense, we have proposed a new hybrid evaluation method focused on assessing PaaS proposals from both the technical standpoint and the user’s perspective. Cloud computing literature has produced several evaluation studies (Buyya et al. 2010; Liu and Wee 2009; Yang et al. 2012) aimed at assessing cloud platforms facing common challenges such as elasticity, availability and privacy from technical standpoints. In (Buyya et al. 2010) a performance evaluation study using CloudSim was proposed. CloudSim is a toolkit for modeling and simulation of cloud computing infrastructures and services. The authors evaluate a simulation environment that models federation of three cloud providers and a user with the aim of proving that federated infrastructure of clouds can deliver better performance and Quality of Service (QoS) as compared to existing not federated approaches. Liu and Wee (2009) presented a performance evaluation study of several cloud components: Amazon EC2 instances (virtual machines), Google App Engine, Amazon Elastic Load Balancing web services 123 Autom Softw Eng and Amazon S3. This evaluation uses SPECWeb2005, a web server benchmark, with the aim of understanding the capabilities and limitations of the aforementioned cloud components. In (Yang et al. 2012) a performance evaluation study of the Sonora system was presented. A service implemented on top of Sonora called Personal Environmental Impact Report (PEIR) is used with the aim of evaluating Sonora’s design decisions and proving that it is efficient (in terms of load balancing), scalable and that it provides responsive fault tolerance. PEIR is a participatory sensing service that delivers context-sensitive information to mobile devices. Finally, the Cloud Service Measurement Initiative Consortium (CSMIC)6 launched by Carnegie Mellon University proposed a framework called Service Measurement Index (SMI) which is a hierarchy of critical business and critical characteristics, associated attributes and measures for enabling comparisons of cloud services available from multiple providers. It is targeting organizations and it is intended to be used as a method to measure any kind of cloud service model (IaaS, PaaS or SaaS) starting from business and technology requirements. The above analyzed proposals are related to performance, QoS, security and privacy evaluations which typically imply quantitative measurements derived from software metrics. In this sense, the absence of a widely recognized and standardized framework providing a common language on software metrics for Cloud computing is an issue on validating in measurable terms the Cloud computing proposals either academic or commercial. Moreover, with the aim of going beyond the technical evaluation studies we have analyzed several proposals (Högberg and Georgsson 2012; Kitanov and Davcev 2012; Saripalli and Walters 2010) intended to be used as frameworks for selecting a PaaS solution. Saripalli and Walters (2010) presented a quantitative risk assessment method for cloud platforms. It defines a risk as a combination of the probability of a security treat event and its severity, measured at its impact. The authors propose six key security objectives for mapping security risks: confidentially, integrity, availability, multipart trust, auditability and usability. Finally, the Delphi method, technique that assigns numerical values to the probability of an attack and its severity, is used in order to collect the information necessary for assessing the security risks. In (Kitanov and Davcev 2012) a Quality of Experience (QoE) evaluation of a mobile distance learning system in a MCC environment was provided. QoE refers to the perception of the user about the quality of a particular service, application or network. In general, the QoE is evaluated through answering a 7-item survey. This approach is very interesting because it is meanly based in overall acceptability of applications as subjectively perceived by end-users, and it avoids technical aspects. Högberg and Georgsson (2012) proposed five criteria to consider when migrating an application to a cloud platform: cost, promised availability, security, support and documentation and complexity of migration. A comparative and qualitative evaluation method based on the aforementioned criteria was proposed. This method consists in assigning ratings to each of the criteria and weighing them in order to obtain total scores for each compared cloud platform. Finally, Haddad (2011) proposed an evaluation framework 6 http://csmic.org/understanding-smi/ 123 Autom Softw Eng for evaluating and comparing PaaS offerings across a set of criteria composed of: (1) measured characteristics that distinguish cloud solutions from traditional application solutions, namely on-demand self-service, resource pooling, rapid elasticity and measured service, (2) PaaS maturity, (3) the support of DevOps activities across software development life-cycle phases, (4) architectural issues that impact PaaS practices aimed at supporting cloud characteristics, (5) the programming model, i.e., the variety of programming languages and frameworks supported, (6) PaaS suitability for developing complex applications, i.e., the broadness of the services spectrum and (7) other factors. In general, the last three works use subjective measures for assessing predefined sets of criteria related to desirable features of cloud platforms. Here, the features are derived from the requirements that users have for particular tasks or activities. In detail, the third work uses a discussion approach to establish the user perception for aspects related to complexity of migration to cloud platforms. In fact, discussions can be used to justify subjective measures derived from evaluation studies. The latter work provides a classification of criteria for evaluating PaaS offerings, which covers not only non-functional requirements but also overall cloud characteristics and PaaS attributes aimed at supporting these characteristics. In this sense, it is important to notice that considering what distinguishes MobiCloUP! from other proposals, criteria related to overall cloud characteristics are out of the scope of our evaluation method. Because it is quite difficult to evaluate in a fully-quantifiable way how legitimate the solution provided is respect to the aspects previously discussed, we have decided to use a two-part comparative evaluation: (1) a qualitative method to measure diverse features of MobiCloUP!, not only focusing on its usability but also on the ease of both creating new applications and migrating legacy applications as well as on the coverage of the mobile development life-cycle and (2) a quantitative method to measure the quality of MobiCloUP!-based applications in terms of performance, assurance and usability. Moreover, in order to provide a comparison with diverse PaaS for MCC, we have selected the Salesforce Force.com and Antenna AMPchroma proposals which were described in Sect. 2. For the qualitative assessment method, on the one hand, four non-functional requirements were identified. Each of these requirements was mapped to about three features that a PaaS for MCC should possess to fulfill it, resulting in a total of thirteen features. The presence of each of these features in all compared PaaS was assessed in order to determine the legitimacy of MobiCloUp! and, at the same time, identify which of the alternatives is best in specific circumstances. Due to the subjective nature of this analysis, a discussion is presented with the aim of justifying the results. It is important to notice that the evaluation was conducted by a team composed of three senior software developers external to this research group. For the quantitative evaluation, on the other hand, a set of seven software metrics based on both the Service Management Index (SMI) framework and the ISO/IEC 9126 standard were proposed. In addition, a basic evaluation scenario consisting on developing a simple mobile Web application from scratch was implemented using each of the selected PaaS, so that the proposed metrics were employed under the same specific circumstances. 123 Autom Softw Eng 6.1 Qualitative evaluation 6.1.1 Evaluation design In this section, the four aspects that constitute the identified user needs are described. The features that a PaaS for MCC must possess for satisfying these needs are also outlined. Need (N) 1: Support for diverse architectures of mobile application The type of mobile application supported is a crucial aspect in choosing among different PaaS. It must be evaluated not only starting from technology and domain independence factors but also considering architectural aspects. In this sense, there are three types of mobile application architectures: (a) native applications which run entirely in mobile devices, (b) hybrid applications which are built using Web technologies, and they are wrapped in a device-specific native application container and (c) Web-based applications which have small device-specific clients with execution occurring on remote servers (Wasserman 2010). Furthermore, it is important to notice that domain of cloud-based applications can be determined by the broadness of the services spectrum offered by their cloud platform. Feature (F) 1: Domain-independent applications Feature (F) 2: Platform-independent applications Feature (F) 3: Mobile Web-based, hybrid and native applications Need (N) 2: Full coverage of the mobile development life-cycle Cover the end-to-end mobile development life-cycle by using a single cloud platform can save the time, effort and budget required to setting up hardware and software infrastructure; at the same time, it enables developers to spend more time innovating applications. Mobile development life-cycle commonly include: planning, design, development, testing, publishing (or deployment) and maintenance (About the Application Development Process 2012; Application Platform Overview for Windows Phone 2012). Planning and design are usually not addressed by cloud platforms because they are focused on life-cycle low-level stages, i.e. development, testing, publish and maintenance. Furthermore, in addition to the life-cycle coverage, the life-cycle speeding up is another factor to consider when development time is a constraint. This aspect is indirectly addressed in the need described below. Feature (F) 1: Planning and design activities Feature (F) 2: Application distribution support Feature (F) 3: Full control over applications Need (N) 3: Time and effort-saving development The major use cases of PaaS solutions are the development of new applications and the migration of legacy applications. In fact, according to Högberg and Georgsson (2012) the ease of migrating a legacy application to a cloud platform is a critical aspect in evaluating cloud platforms. In this sense, migrating existing applications can require much work in adapting the application to the provider’s offerings or even can require completely re-implement the application. Here, the compatibility with diverse 123 Autom Softw Eng programing languages and frameworks as well as the facilities aimed at avoiding hand coding as far as possible become relevant. Thus, we have proposed to evaluate this aspect not only considering the ease of implementing new applications from scratch but also considering the ease of migrating legacy applications. As can be inferred, this interpretation is directly influenced by the development approach driven by the provider. In this sense, we distinguish between code-based and automatic code generation programming models. Feature (F) 1: Use of wizards for performing complex tasks Feature (F) 2: Automatic source and native code generation Feature (F) 3: Support for diverse programming languages and frameworks Need (N) 4: Usability-compliant development tools ISO 9241-11 (1998) defined usability as the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use. According to the above, usability must be assessed respect to “effectiveness”, “efficiency” and “satisfaction” factors. However, effectiveness and efficiency are out of the scope of this evaluation method due to their quantitative nature. In this sense, Brooke (1996) proposed a 5-point Likert scale called Simple Usability Scale (SUS) which gives a global view of subjective assessments of usability. It allows assessing usability of websites respect to the satisfaction of their users. Thus, in order to evaluate the usability of cloud platform’s development tools, we have proposed to use the following aspects covered by the SUS usability scale: ease of use, ease of learning and required level of knowledge and skills. Feature (F) 1: Easy to use Feature (F) 2: Easy to learn Feature (F) 3: Current knowledge and skills of developers The scale used for the measurement of the identified aspects is a 3-point Likert scale (Likert 1932) in which “1” represents the best score and “3” represents the worst score as follows: • 2 points: strongly addressed (SA) • 1 points: partially addressed (PA) • 0 point: not addressed (NA) Finally, the overall evaluation for each software tool will be the sum of the scores in the five aspects. 6.1.2 Results Table 2 and Fig. 14 show to each aspect the score obtained from the evaluation. Finally, the argumentation of the results for each aspect is discussed. Regarding the N1–F1 aspect, all proposals allow building domain-independent mobile applications because they offer integration with a wide range of services including database storage, enterprise systems integration, content management, among others i.e., they are not intended a particular kind of functionality. It is important to mention that force.com is not a general-purpose computing platform because it 123 Autom Softw Eng Table 2 Evaluation results Fig. 14 Evaluation results 123 Aspect Salesforce Force.com Score Antenna AMPchroma Score MobiCloUP! Score N1 F1 2 2 F2 2 1 1 F3 2 2 2 N2 F1 1 2 1 F2 2 2 0 F3 2 2 2 N3 F1 1 1 1 F2 1 2 2 F3 2 2 2 N4 F1 1 1 2 F2 1 1 2 F3 0 0 2 Sum 17 18 19 2 Autom Softw Eng provides its own business logic programming language called Apex. Concerning the N1–F2 aspect, all proposals enable developers to use Web standards such as HTML5, JavaScript and CSS3 for building mobile Web applications and even hybrid mobile applications. In this sense, resulting Web applications do not require any additional web browser plugin or runtime environment to be executed. However, in the case of hybrid and native mobile applications it is not truth. Antenna AMPchroma-based hybrid and native mobile applications require extra client runtimes respectively called AMP Hybrid Client and AMP Native Client. These runtime environments expose multiple native capabilities, and they include a control library aimed at ensure deviceawareness. In the case of MobiCloUP!-based native applications, the Adobe® AIR runtime environment is required because these applications are built using the Adobe® Flex framework. Force.com-based native mobile applications, on the other hand, are entirely built using native code; thus, they do not require any additional client runtime. Moreover, regarding the N1–F3 aspect, force.com and Antenna AMPchroma support the previously outlined three types of mobile application whereas MobiCloUP! supports only Web-based and native mobile applications. In the case of force.com, hybrid applications are built on top of Apache Cordova framework targeting only Android and Apple iOS mobile operating systems. In the case of Antena AMPchroma, hybrid application development supports BlackBerry OS and Windows Phone besides the aforementioned operating systems. Finally, MobiCloUP!-based native mobile applications are targeting Android, Apple iOS and BlackBerry Tablet OS operating systems. About the N2–F1 aspect, only Antenna AMPchroma covers planning, design and testing stages of mobile development life-cycle. However, both Force.com and MobiCloUP! consider presentation design decisions. Force.com allows developers to inplace edit the application’s GUI by using either HTML5 elements or Visualforce components. Visualforce is the component-based GUI framework for the Force.com platform. In the case of MobiCloUP!, look and feel aspects can be configured using the wizard tool. Regarding the N2–F2 aspect, all proposals provide mechanisms for native application distribution. Furthermore, in Force.com a Web-based application or a piece of functionality can be packaged into either a one-time distribution package or a release package using an online environment. It also offers the AppExchange service which allows uploading and publishing packages that other can install in their environments. Antenna AMPchroma, on the other hand, is part of a major platform called Antenna Mobility Platform (AMP). This platform includes both the AMP Enterprise Storefront solution for creating and managing enterprise application stores for employees and the AMP Consumer Storefront solution for uploading, managing and delivering not only applications but also other digital content to consumers. It is important to notice that, in the case of MobiCloUP!, application market development is still in progress. Therefore, for now, native applications can only be downloaded for local installation in target mobile devices. About the N2–F3 aspect, all platforms integrate management tools providing functions like user administration giving the developer control over deployed applications. Furthermore, force.com also enables developers to manage mobile devices used for accessing native mobile applications; Because Antenna AMPchroma covers the entire mobile development life-cycle, it allows managers to set permissions for assigning workers to their corresponding functions, i.e., it allows managing workers besides users, devices and applications. 123 Autom Softw Eng Regarding the N3–F1 aspect, all proposals integrate wizard tools as a means to automate complex user tasks or as an alternative and quicker way of performing complex user tasks. For instance, in the case of force.com a one-step wizard for generating application templates with basic functionality is provided. In the case of MobiCloUP!, design, development, deployment (or publishing) and maintenance stages of the mobile development life-cycle are abstracted in a unique wizard tool. Concerning the N3–F2 aspect, all proposals have source code generation functions; however, only Antenna AMPchroma and MobiCloUP! support native code generation, i.e., they allow packaging and digitally signing native application installers. In this sense, it is important to notice that, the Antenna’s Enterprise Storefront enable employees to access certified enterprise-branded Web-based and native mobile applications. Regarding the N3–F3 aspect, all proposals support more than one programming language. Therefore, the three platforms are technology-independent. Force.com provides SDKs for both Android (using Java) and iOS (using Objective C) native development. It also offers a set of integration APIs which provide access to Force.com application data and logic from external languages such as Ruby, PHP and ASP.NET. Besides these native programming languages, the Antenna AMPchroma platform is open to third-party JavaScript libraries and frameworks such as jQuery Mobile, Sencha Touch and Dojo Mobile. MobiCloUP! uses pre-built HTML5/JavaScript-based and MXML/ActionScript-based GUI components for generating mobile Web-based and native mobile applications, respectively. About the N4–F1 aspect, thanks to the automatic code generation approach used by MobiCloUP!’s development and deployment tools, this platform can be easier to use than others; however, this drawback is offset by an extensive technical documentation in the specific case of force.com. Regarding the N4–F2 aspect, the learning curve of force.com is larger than the MobiCloUP! and Antenna AMPchroma’s learning curves. In detail, Antenna AMPchroma offers a no-code WYSIWYG editor integrated in its AMP Builder IDE as an alternative to the code-based development using the Eclipse-based AMP Studio IDE whereas MobiCloUP! integrates all the typical platform services in a unique GUI based on the wizard screen design pattern. Nevertheless, according to the SUS scale, the integration of functionalities in a system is a key issue in evaluating usability. In this sense, the evaluation results reflect that functions in MobiCloUP! should be better integrated. Finally, about the N4–F3 aspect, considering that self-service is a characteristic of cloud, PaaS solutions must demand minimal technical knowledge and skills from developers in order to promote business agility. For instance, previous experience on Objective-C or Java is required for coming up to speed on development with force.com and AMPchroma. In addition, knowledge and skills on CSS for customizing pre-built GUI components are required in order to develop Antenna AMPchroma-based or force.com-based Web and hybrid applications; MobiCloUP!, on the other hand, automates almost the entire mobile development life-cycle starting from a set of preferences that must be established by users through a wizard. In this sense, it does not require any previous experience on native or Web development. As can be inferred from the evaluation results, MobiCloUP! completely addresses almost 70 % of features that a PaaS for MCC must possess in order to satisfy the user needs related to technology and domain independence, mobile development lifecycle 123 Autom Softw Eng coverage, complexity of migration, support and documentation and usability aspects. It rated 21 out of 26 in the evaluation method we have proposed. According to the results, unlike force.com and AMPChroma, MobiCloUP! does not require any knowledge and skill on native or Web development. In addition, MobiCloUP!’s integrated tool is easier to use and easier to learn than force.com and AMPChroma’s development, deployment and maintenance tools. 6.2 Quantitative evaluation 6.2.1 Evaluation design This evaluation method is intended to measure the quality of the applications developed by using the selected PaaS, namely, Salesforce Force.com, Antenna AMPChroma and MobiCloUP!. For this purpose, we have selected the SMI framework because it is designed to become a standard method to measure Cloud services. Furthermore, we have also selected a model for software quality from Software Engineering literature, namely, ISO/IEC 9126 because the SMI framework is still an initiative and there is an absence of a widely recognized and standardized framework for validating in measurable terms the Cloud computing proposals. In detail, ISO/IEC 9126 is an international standard for the evaluation of software quality; it defines a model composed of general characteristics of software which are further decomposed into general subcharacteristics and specific attributes. In addition, ISO/IEC 9126 defines three sets of software metrics for assessing attributes from three different perspectives: (1) external quality, (2) internal quality and (3) quality in use. It is important to notice that thanks to the generic nature of the ISO/IEC 9126’s quality model, it can be refined according to the type of software to be evaluated; therefore, it can be applied to the evaluation of Cloud-based applications. According to the above, we have mapped SMI attributes with ISO/IEC 9126 subcharacteristics (two-level components) as far as possible. In this sense, we have selected one component common to both frameworks: “accuracy”. In addition, we have selected the “response time” and “availability” attributes from the SMI framework; similarly, we have selected the “resources utilization” sub-characteristic from the ISO/IEC 9126 standard. The quality factors to be assessed and the corresponding software metrics are described below. Service response time: According to the SMI framework it is an attribute of performance which is considered a critical characteristic of Cloud services. Here, “performance” is interpreted as the set of features and functionalities of a service whereas “service response time” is interpreted as the time between when a service is requested and when the response is available. In this sense, because it is considered that PaaS solutions allow delivering applications as SaaS, this attribute can be measured not only at an application development level but also at an application delivering level. In addition, in the case of measuring at an application delivering level, the service response time can be measured not only considering a particular functionality but also considering all the application as a whole. 123 Autom Softw Eng Hardware resources utilization: According to the quality model outlined by the ISO/IEC 9126 standard, the “resources utilization” is a software quality factor. Formally, it is a component of the “efficiency” quality characteristic which is interpreted as the ability of software to execute the required tasks with the least amount of resources. In this sense, taking into account that mobile applications can take advantage of cloud computing to face the challenges related to limited hardware resources availability, this factor can be measured not only at PaaS level but also at mobile device level. In addition, because MobiCloUP! is targeting rich mobile applications which can distribute business logic between client and server sides, the efficient usage of the available resources is a determining quality factor in any case (at any level). Service availability: According to the SMI framework it is an attribute of the “assurance” critical characteristic of Cloud services which is interpreted as the likelihood that a service will be available as specified. Here, service availability is interpreted as the amount of time that a client can use a service. In this sense, as in the case of “service response time”, “service availability” can be measured not only at an application development level but also at an application delivering level. Service accuracy: It is a component of both the SMI framework and the ISO/IEC 9126 standard. In detail, the SMI framework defines “accuracy” as a critical characteristic of Cloud services affecting its performance whereas the ISO/IEC 9126 standard defines “accuracy” as a software quality factor affecting the “functionality” characteristic. Here, functionality is interpreted as the set of functions and properties of software that satisfy stated needs. In both cases, “accuracy” is defined as the correctness of the software respect to the implied needs or requirements. In this sense, taking into account that MobiCloUP!’s development tool implements an automatic code generation approach based on a software development process for rich mobile applications, this metric is used to measure the accurateness of the functions automatically generated respect to the requirements of users being a determining factor of the quality of MobiCloUP!-based applications. Due to the quantifiable nature of this evaluation method, a set of software metrics to measure the above quality factors need to be employed. The metrics we have proposed to this aim are outlined in Table 3; they are based on both SMI measures and ISO/IEC 9126 metrics for internal quality, i.e., internal metrics. In addition, in order to assess in measurable terms the effects of using the selected PaaS respect to the features defined as part of the qualitative evaluation method, we have proposed a set of complementary software metrics. Specifically, these metrics address the features derived from N3 (“time and effort-saving development”) and they are intended to measure both the ease of developing new applications and the ease of migrating legacy applications. As can be inferred these metrics are not targeted at evaluating the quality of the applications developed by using the selected PaaS but at evaluating the quality of the PaaS themselves. Due to some specific features of MobiCloUP!’s development tool such as the ability to automatically generate source code for managing data from Web 2.0 Cloud services, the case study presented in the previous section of this paper is not adequate to be used as an evaluation scenario using neither Salesforce Force.com nor Antenna AMPChroma. Therefore, in order to measure the quality of the applications developed by using the selected PaaS under the same circumstances, we have proposed a 123 Autom Softw Eng Table 3 Quality metrics to be considered for the quantitative evaluation Quality factor Metric Description Service response time Expected service response time Hardware resources utilization RAM usage The amount of time spent by the service as a whole to respond The average memory size used by the service The average CPU percentage used by the service The average bandwidth percentage occupied by the service The ratio between the number of defects discovered and the number of features developed The amount of time spent and steps conducted by the developer to develop an application from scratch The amount of time spent and steps conducted by the developer to migrate an existing application CPU usage Bandwidth usage Service accuracy Defect–feature ratio Time and effort-saving development Time and effort to develop a new application Time and effort to migrate a legacy application basic scenario as the “hello world” program of Cloud services-based applications. In detail the application to be developed is a simpler version of the application developed in the case study because it manages a Cloud-based users’ SQL database to allow users to sign up and log in using their e-mail addresses. In this sense, once a user has logged in, a Web page with a “Hello World!” message is then displayed by the application. Notwithstanding its simplicity and due to the automatic code generation model implemented by MobiCloUP!, this scenario involves hand coding functionality in the case of Salesforce Force.com and Antenna AMPChroma PaaS. Going beyond this issue, Antenna AMPChroma is not available for free by means of trial versions; it is only available for free by means of 30-min live demos. Taking this into account, we have decided to exclude Antenna AMPChroma from this evaluation with the aim of preserve the accurateness of the results. Moreover, it is important to notice that this scenario does not involve the measurement of the time and effort required to migrate a legacy application because this metric suppose the existence of a legacy application meeting the requirements stated above. 6.2.2 Results In the context of implementing the evaluation scenario using the Cloud-based Force.com’s development tools, a custom Visualforce page was created by means of 123 Autom Softw Eng the developer console tool in the Force.com’s Developer Edition (DE) environment. This tool is launched as a new Web browser window by selecting the “Developer Console” option in the Visualforce pages administration page. In detail, the “New” option of the “File” menu was selected so that a name for the Visualforce page to be created was required. For this evaluation scenario, the “HelloWorld” name was entered. Finally, the source code aimed at displaying the “Hello World!” message was manually added. In this sense, the Visualforce “outputPanel” control was used. This control is a simple container which is rendered as an HTML div element. Because the Force.com-based applications are initially not optimized for mobile devices they need to be mobilized, i.e., they need to be redesigned by using JavaScript-based frameworks such as jQuery Mobile, BackboneJS and AngularJS. In fact, Force.com has built-in support only for the aforementioned frameworks; nevertheless, they need to be enabled in the Force.com’s DE environment by installing the so-called mobile packs. For this evaluation scenario, the jQuery Mobile framework was selected so that the mobile pack for jQuery Mobile was installed by entering the corresponding install URL into the Web browser address bar. Once the required mobile pack was installed, the developer console was accessed again in order to edit the source code. In detail, the jQuery Mobile framework was linked to the Visualforce page by using the Visualforce “includeScript” control; similarly, the minified CSS default theme of jQuery Mobile was linked to the Visualforce page by using the Visualforce “stylesheet” control. In addition, a single external HTML div element acting as a jQuery Mobile page (view) was defined by using the HTML5 data-role attribute; two nested div elements acting as its header and content areas, respectively, were also defined inside the external div element. The HTML5 data-theme attribute was used to apply the “b” jQuery Mobile theme swatch to the page. Finally, the previously defined Visualforce “outputPanel” control was moved to the content area and an HTML h2 element was defined inside the div element acting as the header area with the aim of displaying a title. Regarding the requirement related to the implementation of standard session control functions it is important to notice that Force.com provides facilities for controlling access to applications. These facilities include users, profiles and permission sets management and they suppose the automatic creation of user databases in the Cloud. As can be inferred, unlike in the case of MobiCloUP!, control access to applications is in charge of the platform instead of in charge of the applications themselves. According to the above, the target users of a Force.com-based application need to be pre-registered by a master user directly in its corresponding Force.com’s DE environment. For this evaluation scenario, a target user with the “Force.com App Subscription User” default profile was created by selecting the “New User” option in the user administration page. As a result, some information including personal data, user account-related data and locale settings was required. Once the target user was created, a new permission set was created by selecting the “New” option in the permission set administration page. As a result a name and an ID were required. For this evaluation scenario, the “ViewHelloWorld” name was entered. Finally, the permission to execute the Visualforce “HelloWorld” page was granted to the target user by assigning both the page and the user to the “ViewHelloWorld” permission set. For this purpose, the edit page of the “ViewHelloWorld” permission set was accessed and then the “Visualforce Page Access” option and the “Assigned Users” option were used. Once the aforementioned 123 Autom Softw Eng settings were settled, the “HelloWorld” page was deployed on Force.com (Force.com’s production environment). It is important to notice that the Visualforce custom pages are automatically deployed when they are accessed via Web browsers for the first time. The URIs of the Visualforce pages are obtained by appending the name of the applications to the https://login.salesforce.com/apex/ static URI. For this evaluation scenario, the following URI was obtained: https://login.salesforce.com/apex/HelloWorld. In the context of implementing the evaluation scenario using the MobiCloUP!’s wizard tool, a new mobile Web application was generated by conducting a development project in a similar way to how is explained in the case study (migration project). In detail, the functionality intended to display a “Hello World!” message once the user is logged in was achieved by simply selecting the “Hello World!” sample application as part of the initial application configuration (development configuration) which is settled in the third phase of the wizard. Regarding the requirement related to the implementation of standard session control functions, it is important to remark that MobiCloUP!-based applications incorporate control access facilities by default; similarly, a user database per each application developed is automatically created. Therefore, it is only necessary to create user accounts for the target users of a MobiCloUP!-based application. In this sense, unlike Force.com, MobiCloUP! defines only two different user roles: end user and developer so that user roles need not be configured during user account creation. For this evaluation scenario one end user account was created. This was done by means of the “Create Users” popup dialog box which is displayed by selecting the “Create Users” option in the third phase of the wizard, i.e., during the design phase of the MobiCloUP’s development project. As a result, the amount of end user accounts to be created was required and then the list of e-mail addresses of the target users was accordingly required. It is important to notice that the required user accounts are automatically set up by generating random credentials, i.e., usernames and passwords. According to the above, user registration is partially in charge of end users; hence, the randomly generated credentials need to be distributed to end users by means of e-mail messages in order to complete user registrations. These e-mail messages are automatically sent by when applications are released. Finally, the application was accessed via a Web browser by using the URI configured during the fifth phase of the wizard, i.e., during the deployment phase. In order to estimate the effort required to develop the applications resulting from the implementation of the evaluation scenario using Force.com and MobiCloUP!, only the main steps manually conducted in both development processes was considered. On the one hand, in the case of the Force.com-based development process the following steps were considered: (1) Set up the Force.com’s DE environment for mobile Web application development, (2) Create a Visualforce page, (3) Edit the source code to add the required functionality (“Hello World!” message), (4) Optimize the resultant page for mobile devices, (5) Create the user account to be able to access the page and (6) Create a permission set to grant access to the page. On the other hand, the following steps were considered in the case of the MobiCloUP!-based development process: (1) Select the mobile Web application type, (2) Set the development configuration settings, (3) Select the sample application providing the required functionality (“Hello World!” message), (4) Set the deployment configuration settings and (5) Create the target user account. Table 4 summarizes the results obtained. 123 Autom Softw Eng Table 4 Results from service accuracy assessment Table 5 Results on estimating the time and effort required to develop a new application PaaS Number of steps Time spent Force.com 5 ∼10 min MobiCloUP! 6 ∼6 min PaaS Number of functionalities developed Number of functionalities required Ratio Force.com 4 3 3/4 MobiCloUP! 4 4 4/4 According to the results summarized above, it can be determined that the Force.com-based application development process consists of 6 main steps whereas the MobiCloUP!-based application development process comprises 5 main steps covering design, development (implementation) and deployment phases of the mobile development life-cycle. Going beyond, the amount of time it takes to complete the development process is about 10 and 6 min in the case of Force.com and MobiCloUP!, respectively. It is important to notice that the maintenance phase is not considered here due to the nature of the evaluation scenario. The accuracy of the applications resulting from the implementation of the evaluation scenario was measured from a consumer’s standpoint so that the applications were addressed as SaaS. In this sense, according to the requirements stated as part of the evaluation scenario, the following four functionalities were considered: (1) “Hello World!” message displaying, (2) user signup, (3) user login and (4) user logout. Table 5 summarizes the results obtained. As can be inferred from the results summarized above, the user signup functionality is not obtained as a result of conducting the development using Force.com, which can be interpreted as an error in the development process. The same is not true in the case of automating the development using MobiCloUP!. Thus, considering that MobiCloUP! actually automates a software development process for rich mobile applications and Force.com only promotes an ad-hoc framework-based development these results may be used to prove that the approach taken by MobiCloUP! can help developers to generate less error-prone applications. In order to estimate the response time of the applications resulting from the implementation of the evaluation scenario, a complementary load test scenario was implemented using the BlazeMeter load testing PaaS which in turn automates the usage of the Apache JMeterTM performance testing tool. In detail, a test with up to 50 concurrent users sending HTTP requests was conducted during 30 min where the first 15 min corresponded to the ramp up time whereas the last 15 min corresponded to the continuous load time. It is important to notice that this scenario involved the emulation of a network of mobile devices (users) with a 2,048 kbps Wi-Fi Internet connection. In fact, the traffic data was collected using JMeterTM and it was generated from a 512 MB RAM, 1 GHz dual-core CPU Motorola® XOOMTM tablet computer (Android mobile 123 Autom Softw Eng Fig. 15 Evaluation results from service response time estimation 123 Autom Softw Eng Table 6 Results on estimating hardware resources utilization Hardware resource Force.com MobiCloUP! CPU 1,121 ms 917 ms RAM 19.65 MB 9.7 MB Bandwidth 123 KB 331 KB operating system) and the Mozilla Firefox 22.0 mobile Web browser and then it was used as a starting point in the conduction of the aforementioned load test scenario using BlazaMeter. Because the metric aimed at measuring the response time requires addressing all the functionalities provided by the applications as a whole, the traffic data collected basically comprised all the traffic between the request of the application via the mobile Web browser and the rendering of the page displaying the “Hello World!” message (final HTTP response), including the redirection to the login page. Figure 15 depicts the results obtained. As can be inferred from the results depicted in Fig. 15 the average response time of the Force.com-based application goes from 680.73 ms (maximum) to 544.15 ms (minimun) under a load of up to 50 concurrent users. In fact, the average response time remains stable (below 600 ms) during the ramp up time and even during the continuous load time (when the user load is 50 concurrent users). Taking into account that the Force.com and MobiCloUP!-based mobile Web applications has HTML/JavaScript-based GUIs, they can be profiled by employing any monitoring tool for JavaScript code. In this sense, with the aim of estimating the client-side hardware resources utilization of the applications resulting from the implementation of the evaluation scenario, the built-in Google Chrome’s developer tools were employed to this aim. In detail, the applications were tested on a desktop computer by setting up a mobile user agent emulating a Nexus S (Android 2.3) smartphone on the Google Chrome Web browser. As in the case of the load test outlined above, this performance test comprised the execution of the applications as a whole so that the obtained results represent the average amount of hardware resources used by the applications from the time they are requested via the mobile Web browser to the time the page displaying the “Hello World!” message (final HTTP response) is rendered. Table 6 summarizes the results obtained. According to the results summarized above, the MobiCloUP!-based application uses less RAM and CPU (execution time) than the Force.com-based application. The results related to CPU utilization only cover the time spent in executing JavaScript functions (loading and scripting tasks). The results related to RAM utilization show the amount of RAM consumed in loading, scripting, rendering and painting tasks. Finally, the results related to bandwidth utilization show the total size of the files transferred over the network, including CSS, HTML and JS files as well as images. 7 Conclusions and future work In mobile computing, the execution of services like data storage and data computation outside the mobile devices, i.e., in the Cloud, allows accessing computation- 123 Autom Softw Eng intensive applications and data-intensive applications anywhere at anytime by using low resource mobile devices. Recently, the problems of mobile computing inherent to mobile devices have been addressed by exploiting the capabilities of cloud resources. This has given rise to a new paradigm known as MCC. In recent years, several frameworks for executing cloud-based mobile applications have been arisen with the aim of supporting MCC. In this sense, we have proposed a PaaS for developing, executing and hosting mobile applications. Unlike other solutions, our proposal called MobiCloUP! abstracts almost the entire mobile development life-cycle in a unique visual tool avoiding the code-based development approach. Furthermore, this wizard tool implements a software development process for rich mobile applications, which is based on the PPMRD process; therefore, it can help developers to develop less error-prone mobile applications. In addition, because the code generation engine implements a technology-independent software development process, the native code generation mechanism can be easily adapted to other technologies like Microsoft® SilverlightTM . Thus, the code generation engine is intended to coverage a wide range of mobile operating systems. We are currently working on implementing the MobiCloUP!’s maintenance tool as well as a set of user management functionalities aimed at ensuring the security of the private data over Internet. MobiCloUP!-based applications can be generated as native applications, and then they can be downloaded for ad-hoc distribution. Therefore, application distribution is in charge of application developers. In this sense, we are currently working on the design of an application market that can be integrated to the MobiCloUP! architecture in order to automatize the application distribution regardless of the target platform. Acknowledgments This work was supported by the General Council of Superior Technological Education of Mexico (DGEST). Additionally, this work was sponsored by the National Council of Science and Technology (CONACYT) and the Public Education Secretary (SEP) through PROMEP. Additionally, this work was supported by the Isaac Peral Programme of Polytechnic University of Madrid being the work developed on Centre for Plant Biotechnology and Genomics UPM-INIA. Finally, this work has been supported by the Ministry of Industry, Energy and Tourism through project OPEN-IDEA (TSI-0206032012-219) and by the Spanish Ministry of Economy and Competitiveness and the European Commission (FEDER/ERDF) through project SeCloud (TIN2010-18650). References About MXML Components: Adobe® Website (n.d.). Retrieved 1 Oct 2012, from http://help.adobe.com/ en_US/flex/using/WS2db454920e96a9e51e63e3d11c0bf68cf9-7ffb.html About the Application Development Process: Mac Developer Library (2012, July 17 ). Retrieved 10 Oct 2012, from https://developer.apple.com/library/mac/#documentation/General/Conceptual/ ApplicationDevelopmentOverview Antenna Inc.: Harnessing the Power of the Mobile Cloud [White paper] (2010, January 11). Retrieved from http://www.antennasoftware.com/pdf/whitepaper_Antenna_Mobile_Cloud.pdf Application Platform Overview for Windows Phone: Microsoft Developer Network (2012, September 25). Retrieved 10 Oct 2012, from http://msdn.microsoft.com/en-us/library/ff402531(v=vs.92).aspx Binary Tree: Migrating to the Cloud: Which Approach is Right for You? Gestión de empresas (2011, June 21). Retrieved from http://es.slideshare.net/danalsip/migrating-to-the-cloud Brooke, J.: SUS: a quick and dirty usability scale. In: Jordan, P., Thomas, B., Weerdmeester, B., McClelland, I. (eds.) Usability Evaluation in Industry. Taylor & Francis, London (1996). Retrieved from http://www. usabilitynet.org/trump/documents/Suschapt 123 Autom Softw Eng Buyya, R., Ranjan, R., Calheiros, R.N.: 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, vol. part I, pp. 13–31. Springer, Berlin (2010). doi:10.1007/978-3-642-13119-6_2 Colombo-Mendoza, L.O., Alor-Hernandez, G., Rodriguez-Gonzalez, A.: A novel approach for generating multi-device Rich Internet Applications. In: 22nd International Conference on Electrical Communications and Computers (CONIELECOMP), pp. 361–367 (2012). doi:10.1109/CONIELECOMP.2012. 6189939 Cox, P.A.: Mobile cloud computing (2011, March 11). Retrieved 22 Oct 2012, from http://www.ibm.com/ developerworks/cloud/library/cl-mobilecloudcomputing/ Fernando, N., Loke, S.W., Rahayu, W.: Mobile cloud computing: a survey. Futur. Gener. Comput. Syst. 29(1), 84–106 (2013). doi:10.1016/j.future.2012.05.023 Forman, G.H., Zahorjan, J.: The challenges of mobile computing. IEEE Comput. 27, 38–47 (1994) Grønli, T.-M., Hansen, J., Ghinea, G.: Integrated context-aware and cloud-based adaptive home screens for android phones. In: Proceedings of the 14th International Conference on Human–Computer Interaction: Interaction Techniques and Environments, vol. part II, pp. 427–435. Springer, Berlin (2011). Retrieved from http://dl.acm.org/citation.cfm?id=2022466.2022517 Haddad, C.: Selecting a Cloud Platform: A Platform as a Service Scorecard. WSO2 (2011, December 12) Högberg, D., Georgsson, E.F.: An Applied Evaluation and Assessment of Cloud http://130.203.133.150/viewdoc/similar; Computing Platforms (2012). Retrieved from jsessionid=376F1FF26208AAB66BEB82871C02AECE?doi=10.1.1.221.2020&type=sc Hung, S.-H., Shih, C.-S., Shieh, J.-P., Lee, C.-P., Huang, Y.-H.: Executing mobile applications on the cloud: framework and issues. Comput. Math. Appl. 63(2), 573–587 (2012). doi:10.1016/j.camwa.2011.10.044 International Standard Organization: ISO 9241-11:1998—Ergonomic Requirements for Office Work with Visual Display Terminals (VDTs)—Part 11: Guidance on Usability. ISO, Geneva (1998) Introduction to Web Components: W3C Website (2012, October 1). Retrieved 1 Oct 2012, from http://dvcs. w3.org/hg/webcomponents/raw-file/tip/explainer/index.html Kao, Y.-W., Lin, C., Yang, K.-A., Yuan, S.-M.: A Web-based, Offline-able, and Personalized Runtime Environment for executing applications on mobile devices. Comput. Stand. Interfaces 34(1), 212–224 (2012). doi:10.1016/j.csi.2011.08.006 Kitanov, S., Davcev, D.: Mobile cloud computing environment as a support for mobile learning (pp. 99– 105). Presented at the the third international conference on cloud computing, GRIDs, and virtualization, 2012. Retrieved from http://www.thinkmind.org/index.php?view=article&articleid=cloud_computing_ 2012_4_40_20097 Kitchenham, B.: DESMET: A Method for Evaluating Software Engineering Methods and Tools (No. Tech. Rep. No. TR96-09). Department of Computer Science, University of Keele, Staffordshire (1996) Laszewski, T., Nauduri, P.: Methodology and design, chapter 3. In: Migrating to the cloud, pp. 45–68. Syngress, Boston (2012). Retrieved from http://www.sciencedirect.com/science/article/pii/ B978159749647600003X Li, X., Zhang, H., Zhang, Y.: Deploying mobile computation in cloud service. In: Proceedings of the 1st International Conference on Cloud Computing (pp. 301–311). Springer, Berlin (2009). doi:10.1007/ 978-3-642-10665-1_27 Likert, R.: A technique for the measurement of attitudes. Arch. Psychol. 22(140), 55 (1932) Liu, H., Wee, S.: Web server farm in the cloud: performance evaluation and dynamic architecture. In: Proceedings of the 1st International Conference on Cloud Computing (pp. 369–380). Springer, Berlin (2009). doi:10.1007/978-3-642-10665-1_34 Mao, H., Xiao, N., Shi, W., Lu, Y.: Wukong: a cloud-oriented file service for mobile Internet devices. J. Parallel Distrib. Comput. 72(2), 171–184 (n.d.). doi:10.1016/j.jpdc.2011.10.017 March, V., Gu, Y., Leonardi, E., Goh, G., Kirchberg, M., Lee, B.S.: µCloud: towards a new paradigm of Rich Mobile Applications. Proc. Comput. Sci. 5, 618–624 (2011). doi:10.1016/j.procs.2011.07.080 Marin-Perianu, R., Hartel, P., Scholten, H.: A Classification of Service Discovery Protocols (No. Tech. Rep. TR-CTIT-05-25). Centre for Telematics and Information Technology, University of Twente, Enschede (2005) Mishra, J., Dash, S. K., Dash, S.: Mobile-cloud: a framework of cloud computing for mobile application. In: Meghanathan, N., Chaki, N., Nagamalai, D. (eds.) Advances in Computer Science and Information Technology, vol. 86, pp. 347–356. Springer, Berlin (2012). Retrieved from http://rd.springer.com/ chapter/10.1007/978-3-642-27317-9_36 123 Autom Softw Eng Neil, T.: Designing Rich Applications. Slideshare® Website (2009). Retrieved 28 May 2012, from http:// www.slideshare.net/theresaneil/designing-rich-applications Petcu, D., Macariu, G., Panica, S., Crăciun, C.: Portable Cloud applications—From Theory to Practice. Future Gener. Comput. Syst. (2012). doi:10.1016/j.future.2012.01.009 REST Application Programming: CT316 (2010, September 21). Retrieved 30 Nov 2012, from http://www. ibm.com/developerworks/aix/library/au-aem_rest/ Saripalli, P., Walters, B.: QUIRC: a quantitative impact and risk assessment framework for cloud security. In: 2010 IEEE 3rd International Conference on Cloud Computing (CLOUD) (pp. 280–288). Presented at the 2010 IEEE 3rd international conference on cloud computing (CLOUD) (2010). doi:10.1109/ CLOUD.2010.22 Srirama, S.N., Paniagua, C., Flores, H.: CroudSTag: social group formation with facial recognition and mobile cloud services. Proc. Comput. Sci. 5, 633–640 (2011). doi:10.1016/j.procs.2011.07.082 Tang, W., Lee, J., Song, B., Islam, M., Na, S., Huh, E.-N.: Multi-platform mobile thin client architecture in cloud environment. Proc. Environ. Sci. 11, Part A(0), 499–504 (2011). doi:10.1016/j.proenv.2011.12. 079 Vodafone Group: Connecting to the Cloud [White paper] (2010). Retrieved from http://www.vodafone. com/content/dam/vodafone/about/what/white_papers/connecting_tothecloud.pdf Wasserman, A.I.: Software engineering issues for mobile application development. In: Proceedings of the FSE/SDP Workshop on Future of Software Engineering Research, pp. 397–400. ACM, New York (2010). doi:10.1145/1882362.1882443 Weissman, C.D., Bobrowski, S.: The design of the force.com multitenant internet application development platform. In: Proceedings of the 2009 ACM SIGMOD International Conference on Management of Data, pp. 889–896. ACM, New York (2009). doi:10.1145/1559845.1559942 Yang, F., Qian, Z., Chen, X., Beschastnikh, I., Zhuang, L., Zhou, L., Shen, G.: Sonora: A Platform for Continuous Mobile-Cloud Computing (No. Tech. Rep. MSR-TR-2012-34). Microsoft Research Asia, Beijing (2012) Zhang, X., Jeon, W., Gibbs, S., Kunjithapatham, A.: Elastic HTML5: workload offloading using cloudbased web workers and storages for mobile devices. In Gris, M., Yang, G. (eds.) Mobile Computing, Applications, and Services (pp. 373–381). Springer, Berlin (2012). Retrieved from http://link.springer. com/chapter/10.1007/978-3-642-29336-8_26 123

RELATED PAPERS

RELATED TOPICS

Log In

MobiCloUP!: a PaaS for cloud services-based mobile applications

MobiCloUP!: a PaaS for cloud services-based mobile applications

Related Papers

RELATED PAPERS

RELATED TOPICS