MUBaaS: mobile ubiquitous brokerage as a service

Richard K. Lomotey & Ralph Deters

Received: 1 March 2014 /Revised: 17 October 2014 /Accepted: 6 January 2015 /Published online: 15 February 2015# Springer Science+Business Media New York 2015

Abstract The use of multiple personalized mobile devices (e.g., smartphones and tablets) ison the increase. As such, users expect to access several network-based services across their n-devices. Previous studies proposed Ubiquitous Cloud Computing (UCC) where a single useror service consumer is facilitated to access multiple services from n-devices. However,seamless synchronization of data between the multiple devices can be hindered by intermittentloss of connectivity in mobile wireless networks due to user mobility. Another source oflatency is non-scalable architectures that tend to be overburdened during peak loads. This workproposes a cloud-based application middleware, called Mobile Ubiquitous Brokerage as aService (MUBaaS), which enables n-devices of a user to access multiple cloud services end-points in soft-real time. This is achieved by proposing distributed brokers that coordinates thetransactions of the user while taking load balancing into account. Pilot evaluations of theproposed architecture prove real-time application synchronization with reasonable scalability.

Keywords Ubiquitous cloud computing .Mobile cloud computing . Broker . Cloud computing

1 Introduction

In today’s services economy, cloud computing has become the de facto technology thatfacilitates the consumerization of Internet and network-based services from providers [16].Cloud computing technology and deployment has long been classified into three majortaxonomies which are Infrastructure as a Service (IaaS) — provision of servers, storage, andnetwork through virtualization, Software as a Service (SaaS) — applications to be consumedas hosted services, and Platform as a Service (PaaS)— platforms provided by cloud suppliersto offer hosted services [16, 27]. Enterprises (i.e., services providers) are also exposingmultiple cloud services to their employees and other companies who act as services con-sumers. As cloud computing is receiving much attention, researchers want to know how tocompliment the anytime-access possibilities of the cloud with anywhere-access capabilities.

World Wide Web (2016) 19:5–19DOI 10.1007/s11280-015-0323-7

R. K. Lomotey (*) : R. DetersDepartment of Computer Science, University of Saskatchewan, 110 Science Place, Saskatoon, SK S7N 5C9,Canadae-mail: richard.lomotey@usask.ca

R. Deterse-mail: deters@cs.usask.ca

This has led to the proposal of Mobile Cloud Computing (MCC). There are several workson mobile cloud computing and some sources are [8, 3, 15, 23, 19, 26, 21, 2, 7, 10, 11, 20, 25].But, what is more prevalent today is ownership of multiple mobile devices (e.g., tablets,smartphones, and notebook) by a single user. And users (consumers) expect to have applica-tion, data, and services consistency across these personalized devices. The era of supporting n-devices of a single user is dubbed Ubiquitous Cloud Computing (UCC) since consumers areno longer tied to a single client node but the options are wide for client data access.Furthermore, the cloud services can be offered from multiple providers in a single workflowto support the multiple consumer devices of a single user. For instance, there is an increasingamount of standalone mobile apps that integrate email services, file storage services, andcalendar and notification services; and these services can be offered by different providers butthey are presented to the consumer as a single service on the consumer’s multiple devices [5].

Currently, the deployment of the UCC systems consists of the following architecture.

& Multiple Consumer Devices to a Single IaaS Cloud Source (e.g. Dropbox).& Multiple Consumer Devices to Multiple SaaS, IaaS, and PaaS Sources (e.g., Rackspace

[24] and Locker Project [17]).& Multiple Consumer Devices to a Single IaaS Cloud Integrated with Multiple SaaS [13, 28].

In our previous work which is published in [18], we discuss the Cloud Services Brokeragefor Ubiquitous Cloud Computing - CSB-UCC. This is a framework that aggregates n-devicesto access m-cloud services where the services are delivered to the mobile through servicescomposition. Also, the framework ensures user, application, and data consistency across the n-devices. The challenge however is high-latency during the data synchronization process. Thisis because the brokerage platform is centralized and during peak-loads, the processing time canbe high.

As advancement on the initial work, we have proposed the Mobile Ubiquitous Brokerage asa Service (MUBaaS), which is an application middleware that enables mobile devices toconnect and consume multiple cloud services. MUBaaS adopts the decentralized proxyapproach for load balancing so the system transaction window is minimal. For instance, whenadopted to support multiple on-line gamers, MUBaaS load-balancing approach can ensure thatthe game states of users from several back-end locations are delivered quickly more than thecentralized technique. The main contributions of MUBaaS over the centralized approach are:1) higher scalability, 2) secure but flexible authentication approaches, and 3) soft-real timeapplication and data synchronization.

The remaining sections of the paper are structured as follows. Section 2 briefly discussessome existing works on cloud brokerage. Section 3 details the architectural design of theMUBaaS and Section 4 discusses the evaluations of the framework. The paper concludes inSection 5 with lessons learned, conclusion, and future outlook.

2 Brokerage services

Brokers offer uniform interface for users to access cross-domain cloud services,provide monitoring services for both private and public clouds, enable failure andfault detection, and facilitate migration of resources between cloud infrastructures Jainet al. [14]. In distributed systems, brokerage services can be employed to achievesystem integration tasks. Previous studies by Blum et al. [4] focus on the adoption ofbrokerage services to propagate user generated content between services providers and

6 World Wide Web (2016) 19:5–19

consumers. The broker facilitates the service workflow in the entire distributedsystem. Furthermore, Nair et al. [22] proposed a broker model that aggregatesmultiple cloud providers to offer a SLA-based tiered pricing. The model, whichfollows the enterprise requirement, offers SLA-based services such as the IdentityBrokerage Entitlement Management, Policy Enforcement, Usage MonitoringReporting, and Network Security. Further, the functional overview of the brokermodel is given in terms of cost, security, and performance management. Moreover,Houidi et al. [12] assert that cloud brokerage services are required for inter-cloudnetworking. In the view of the authors, cloud requests from the user can be split andprovisioned on multiple cloud platforms. Also, the same user requests can be provi-sioned over inter-cloud networks that are connected to a network operating system(NOX).

Some ongoing enterprise-oriented projects that adopt brokerage style architectures are:Locker Project [17], Rackspace [24], Google Project Glass [9], Amazon Data Pipeline, andIBM Integration Bus (formerly called IBMWebSphere Message Broker) and SAP NetWeaverProcess Orchestration.

When the CSB-UCC [18] architecture was designed, the focus is to facilitate theusers to access multiple cloud services (i.e., data and application) on their n-devices;where the devices are mobile devices such as smartphones, tablets, notebooks, and soon. The framework is not aggregating the data on the broker; rather, the aim is toensure services consistency across the multiple devices by integrating the devices tothe multi-cloud sources. While the CSB-UCC is the first to be deployed in thisdirection, there is the need to enhance the architecture for enterprise adoption. Thus,this paper has proposed the Mobile Ubiquitous Brokerage as a Service (MUBaaS),which is the advancement of the CSB-UCC. The specific research questions that areaddressed by MUBaaS are:

& How do we enhance scalability (in terms of throughput support)?& How do we ensure soft-real time services propagation through distributed broker

architecture?& How do we ensure authentication of the users and n-devices from the multi-cloud services?

The questions here are going to be explored in the subsequent sections.

3 The MUBaaS architectural design

The architectural design of the Mobile Ubiquitous Brokerage as a Service (MUBaaS)framework is graphically illustrated in Fig. 1. The framework is aimed at aiding userswho have already selected several diversified cloud services to have a convergentview of the services when consuming them. MUBaaS is a cloud-hosted applicationmiddleware layer that acts as a broker that integrates the n-devices of consumers tothe m-cloud sources; thereby forming the ubiquitous cloud computing ecosystem. Theentire architecture comprises of four (4) major layers namely: the mobile nodes, theMUBaaS layer (having three components; controller, sub-proxies, and gateway), 3rdParty Authentication layer, and the m-cloud sources. The mobile devices can commu-nicate with the MUBaaS through wireless technologies such as Wi-Fi or 3.5/4G. TheMUBaaS framework is a typical Software-as-a Service (SaaS) so enterprises can adoptit and host it on their internal/private or public virtualized environments.

World Wide Web (2016) 19:5–19 7

3.1 N-consumer device space

This is the representation of the user’s mobile devices such as smartphones and tablet devices.The MUBaaS framework is built to support any mobile architectural design. Thus, the mobileapplication design can follow the mobile Web design approach or the native design. This is leftto the application scope, need, and focus.

When the mobile Web is adopted, the client-end of the application can establish connectionto the MUBaaS framework through AJAX, XMLHttpRequest (in JavaScript), and /orWebSocket. The MUBaaS framework has an HTTP interface that is exposed to the clientnodes so that they can communicate over the wireless network. In the native environment, anyof the available HTTP connections can be adopted. It is important to state that the HTTPrequest can take the form of read/write operations. This includes HTTP GET (to retrieve aresource), HTTP POST (to create a resource), and HTTP PUT (to update a resource).

3.2 Third (3rd) authentication

The purpose of the social media cloud is to enable security authorization from a user’s socialmedia subscriptions. Using third party social networking Application Programming Interface(API) in personalized and enterprise oriented applications is becoming very popular fordifferent reasons. In this work, the motivation for the integration with the social networkingservices is to facilitate business-to-business (B2B) as well as business-to-consumer (B2C)support for the MUBaaS framework. The B2B model facilitates enterprise adoption of the

Figure 1 The architectural design of MUBaaS

8 World Wide Web (2016) 19:5–19

framework to provide an authentication layer for sharing documents with other enterpriseswhile the B2C model supports direct end-user (i.e. employees or external customers) access tothe enterprise document.

Further, the social networking feature makes MUBaaS usable for different enterpriseswhich may have varying business process flows. For instance, an enterprise which wants tosupport only their internal staff (employees) to access the cloud services hosted data canemploy the simple login approach. This approach requires that the user provides a usernameand a password from the mobile device to the gateway; and the gateway checks from itsrepository of users to determine whether the supplied credentials are valid and matching.Provided the user’s credentials match, the gateway then fetches the user’s cloud servicescredentials and forwards the request to the appropriate end-point. But, another point of call iswhat happens when the enterprise is an advertising or marketing company and will like totarget multiple customers outside their facility?

The social networking authentication component allows users to login throughFacebook, and Google+. The authentication through the social networking sites isbased on OAuth 2.0 technology. Thus, when a user opts to login through a socialmedia say Facebook, the middleware forwards the request to the Facebook authentica-tion system where the user will be presented with the option to provide Facebook IDand password. If the user is a valid Facebook account holder, the gateway fetches theuser’s credentials including the Facebook security access token. But, in an enterprisewhere security is paramount and only employees are required to access the data on thecloud services, the system administrators are strongly advised to prepopulate the user’saccounts including the access tokens from the social media as well. In that case, if auser logs into the system and the credentials are not already stored in the middleware’srepository, the user will be denied access to the data.

A third way that the MUBaaS framework is useful in the context of social media isthe facilitation of an authentication approach which is dubbed as hybrid authenticationmechanism (i.e. either by social networking or proprietary personal login). Sinceenterprises have different needs, it is likely to find some that may require the hybridauthentication approach in order to meet their business execution workflow. Theproposed framework can deal with such a situation since all the features are availablefor combinatorial usage.

But, there is a security risk that is worth noting. Since, we employed the OAuth2.0 technique for logging through social media, the mobile embedded browser keeps asession of the login details. Hence, when a user logs into the system on the firstoccasion through social media say Facebook and the “keep me logged in” option ischecked, the subsequent login (within some time frame) takes the user straight to theapplication interface without the option to provide user credentials. Hence, end usersare cautioned to logout of the application all the time rather than just closing the app.Also, this caution should be a guiding principle for the high security enterprises thatwill be adopting the framework.

3.3 The MUBaaS

As already posited, the mobile devices can communicate with the MUBaaS framework usingany HTTP communication protocol. Currently, the MUBaaS supports:

& IaaS: Dropbox, MEGA, and Amazon Web Services (e.g., Amazon S3, AmazonSimpleDB, Amazon DynamoDB, Amazon EC2, and Amazon RDS)

World Wide Web (2016) 19:5–19 9

& SaaS: Salesforce, Social media (e.g., Facebook, Google+, Twitter, Flickr)& PaaS: Maqetta, Microsoft Azure

One of our goals is to make the framework highly agile so more cloud providerscan be supported. This can be achieved by modifying the model to accommodate theAPI of the new cloud source. The only limitation is that, the modification requiresexpertise in Erlang programming so novice users cannot accomplish this task. Thesource code of the framework will be well documented to make it easily understand-able by the open source developer community. For brevity, the implementation detailsand coding details are not discussed here.

3.3.1 The controller

Since MUBaaS is a distributed broker architecture, the controller component coordi-nates the activities of the sub-proxy. The issue of scalability is cardinal to this workso we adopt the distributed broker architecture to ensure load distribution when thesystem reaches peak demand. The components of the controller are discussed asillustrated in Fig. 2.

Network interfaces The controller has two network interfaces; one is exposed to the mobiledevices and the other is exposed to the multi-cloud sources. The mobile end-point allows themobile requesters to communicate with the controller. The second network interface is theproxy-endpoint. The communication with the cloud sources depends on the nature of theservices API of the provider.

Sub-proxy ID Each sub-proxy is a process that has a unique identifier. This is to aid efficientcommunication between the controller and the sub-proxies. This is beneficial to access specificprocesses as laid-down in the REST design principle.

Figure 2 The composition of the controller

10 World Wide Web (2016) 19:5–19

Sub-proxy state The requests which are sent by the mobile participants are not processed bythe controller. Rather, they are processed by the Sub-Proxies. So, when the requests arrive, thecontroller determines which sub-proxies are in a state that can process a request. There are fivestates for every sub-proxy which are:

i. Dead State: This means the sub-proxy (or, the process) is dead and is no longer reachable.This can be due to fatal errors, failures, or crashes. In Erlang, dead processes can bemonitored. Sub-proxies in this state are not issued requests by the controller.

ii. Alive State: This means that the sub-proxy is reachable.iii. Responsive State: This means the sub-proxy is responding to the communication of the

controller. There are cases where the sub-proxies are alive but non-responsive. This canbe due to intensive transaction processing.

iv. Busy State: This is when a sub-proxy notifies the controller and other sub-proxies that itdoes not want to receive any further requests.

v. Available State: This means the sub-proxy is ready to receive new tasks from themiddleware-layer.

Request queue This is a channel where the controller stores the incoming requests as queuebased on a First-Come-First-Serve bases. The queue increases when most of the sub-proxiesare dead, busy, and non-responsive.

Response queue The responses are also queued when being delivered to the various mobilenodes. This queue is specifically for situations where a sub-proxy is not able to deliver aresponse to the mobile because of communication failure.

Storage This is disk storage where the requested transactions are stored for later usage.

3.3.2 The sub-proxies

While the CSB-UCC [18] is designed as a centralized architecture, the MUBaaS framework isa distributed architecture. This is to ensure scalability through load distribution. In this case,the sub-proxies are built with the capacity of the CSB-UCC. This means, every sub-proxy canact as a broker to aggregate the user’s services from the m-cloud sources. The sub-proxies cancommunicate with the gateway to issue requests. The major components of the sub-proxies areillustrated in Fig. 3.

REST request Currently, the mobile devices can only interact with the system following theREST standard. This is because the HTTP interface that is exposed to the mobile devicesunderstands only the HTTP semantic.

Router The router component is responsible for the request routing, request splitting,and event monitoring. Routing— The sub-proxy ensures that responses are sent backto the mobile devices for every request. The updates are also pushed to the appro-priate devices as needed. Splitting— The sub-proxy splits the incoming requests to theappropriate service provider. Since the user can subscribe to multiple cloud sources,splitting is required to issue the request to the specific service provider. Also, updatesfrom the cloud providers are split to the specific devices of the user. Events— The

World Wide Web (2016) 19:5–19 11

event component interfaces the notification layer and the queue layer to determine theavailability of updates or the state of devices respectively.

Services The services component is responsible for macro activities such as services selection,API type detection, REST composition and issuance of appropriate notification. ServicesSelector— This component aids the selection of the specific service that the user wants tocommunicate with. The services can be IaaS, SaaS, and PaaS. This component also commu-nicates with the gateway. API Type— This component is responsible for the choice betweenthe REST and SOAP API. REST Composition— Though the MUBaaS framework supportsSOAP API with the cloud sources, the mobile end supports only REST. When a service isselected which uses the SOAP protocol, the sub-proxy transforms the SOAP to REST usingthe REST Composition layer. This is done by re-assignig an ID to the SOAP request andreconstructing the HTTP header information. State Notification— When services are updated,this layer pushes the update to the intended user. The notification follows three events whichare: the creation of new service states, updated services states, and a deleted state.

Queue The users and their devices are queued to receive updates. We define channels whichstores the list of users. Each channel contains one user details and a channel has sub-channels.Each sub-channel contains the queue for the registered devices. The client devices are assignedstates which are defined simply as: Connected and Disconnected. The client devices thatconnect are in the Connected state and are ready to receive data from the cloud providers orpush data to the cloud source. The client devices that loss connectivity are in the Disconnectedstate and data is not sent to them by the data router. Rather, the disconnect state is recorded andwhen the device reconnects, the updates are pushed.

3.3.3 Gateway

This is the component that does the actual requesting to the cloud sources. The security of thesystem is also handled by this component. But first, we describe the security workflow of the

Figure 3 The composition of the sub-proxy

12 World Wide Web (2016) 19:5–19

cloud sources to the reader by considering the amazon S3 security workflow. Every userlocated within a group needs to have an Access Key Id and a Secret Access Key which areassigned by the Amazon IAM service when the users of the resources are created. Then, aHash Message Authentication Code (HMAC) signature has to be generated with thesecredentials; which has to be added to the HTTP request headers for Amazon S3 to authenticatethe requester. Based on the signature, Amazon S3 is also able to determine the access levelprivileges of the requester.

Notably, the other cloud services providers follow similar security workflow. Examples areDropbox, MEGA and so on. Hence, one of the primary responsibilities of the gateway is to usethese credentials to calculate the HMAC signature which is SHA-1 Base 64 encoded that issent as part of the HTTP headers over the Internet to the IaaS. This enforces the integrity of therequest.

But, it is important to state that each IaaS layer has only one account credential (i.e., oneemail account as username and a corresponding password) for every customer’s account.Therefore, though we have offered mobile services consumers the flexibility of using multipleaccounts, the middleware can only issue a request to the IaaS facilities with the registered andauthorized user account. It is based on this authorized account that the IaaS providers willassign the Access Key Id and the Secret Access Key. In this case, we proposed a graph-oriented mapping between the user credentials. For clarity, Fig. 4 illustrates the overview ofhow the gateway graphs the user’s accounts.

From the illustration, a user can have an authorized account with which the cloud layer canidentify the user. However, the user may own other accounts such as emails and social mediaservices (e.g., Facebook, Yahoo ID, Google+ etc.). We label the other accounts as registeredaccounts since these accounts can be known by the gateway. So, what the gateway does isanytime the user logs in with any account, the gateway uses the linked data (graph) to map theregistered account to the authorized account and issues the request with the authorized account.Considering a simple use case: assuming User A has a Dropbox account that is bounded to theaccount name a1.example@usecase.com, then this email is the authorized account. Now, UserA may have other accounts such as a2.example@testcase.ca which when the user tells themiddleware about it becomes a registered account. Moreover, the second account can be asocial media id. So in case User A later logs into the system with the second account, the

Figure 4 The Gateway on the users credential mapping

World Wide Web (2016) 19:5–19 13

middleware can map the second account to the authorized account and issue the request to theIaaS cloud with the authorized account.

Further, it is possible for the registered account to be the authorized account for anotherIaaS layer say MEGA and in that case, the authorized account of Dropbox becomes aregistered account. This scenario arises when a user employs multiple accounts for multiplecloud services registration. The graph relationship then becomes advantageous because theuser is facilitated to provide any account and the gateway will handle the routing of the requestwith the appropriate authorized account. But first, the user has to specify during the initialconfigurations which accounts are the authorized ones for which services.

4 System evaluation

We evaluate the proposed system with devices with the following specifications: Processor:Intel Core i-5, CPU 2400@ 3.10 GHz, RAM: 16 GB, System 64-bit operating system. Themobile devices connect to the middleware through 802.11 gWi-Fi 54Mbps connection. All thedevices have approx. 5 % of utilized resources since they have pre-installed factoryapplications.

4.1 Scalability testing

In order to determine the performance of the MUBaaS framework during peak loads(i.e., increasing work demand), the scalability test is conducted. Scalability is a majorissue we want to address in the research. In this work, the workload represents theincreasing number of mobile users’ requests in the system. This experiment requiresheavy users, therefore, a load generating tool, which is built in Erlang [6] and identicalto the Apache Bench [1] software, is used as the client to send concurrent HTTPrequests to the MUBaaS framework to access resources at a controlled rate. The loadgenerating tool is installed on the windows 7 enterprise edition server. The total numberof concurrent HTTP requests that the users can send ranges from 10,000 to 1,000,000.A load generator is configured to emulate the users by issuing the HTTP requests. Themean throughput (i.e. request per second) is recorded every 10 s. In the experiment, weobserved the throughput for six different setups where the system is centralized (i.e.,only 1 broker and identical to the CSB-UCC in [18]) and distributed where the brokersare increased from 2 brokers to 6 brokers. Each of the broker (which is the same assub-proxy) is deployed on an Amazon EC2 instance in North Carolina. The resultsfrom the scalability test are graphed in Fig. 5 and the summary of values is presentedin Table 1.

In the first experiment, we focused on the centralized broker which is shown in thegraph as 1 Broker. This is identical to the CSB-UCC in our previous work in [18].Starting from 10,000 requests, the minimum throughput processed by the centralizedbroker is 2991.45 requests/second and the maximum throughput is approximately32651.56 requests/second. The average (i.e., the cumulative moving average or mean)throughput is approximately 24631.95 requests/second. As shown in the graph, weobserved that the throughput value increases until the system almost stabilizes from160,000 requests. This range shows throughput value of around 32,600 until a maximumcapacity is reached at 250,000 requests. The centralized broker then becomes non-responsive or crashes at this point. This shows that a centralize broker can handle upto about 30,000 mobile users if those users are issuing approximately 8.3 requests/second.

14 World Wide Web (2016) 19:5–19

In the real world use case however, there can be more than this number of users or theirrequest can be more than 8.3 requests/second.

So, the second setup considers the performance of the system with two sub-proxies (i.e., 2Brokers). For brevity, the reader is referred to Table 1 and Fig. 5 to check the maximum,minimum, mean capacity, and maximum request capacity of each setup in order to avoidrepetition of text. With 2 sub-proxies (2 Brokers), we observed that the throughput valueincreases until the system almost stabilizes from 410,000 requests. This range shows through-put value of about 60,300 request/second until a maximum request capacity is reached at520,000 requests. The system then becomes non-responsive or crashes at this point. Thisperformance is approximately double that of the centralized broker assuming we maintain thesame mobile request rate at 8.3 requests/second.

With 3 Brokers, we observed that the throughput value increases until the system almoststabilizes from 700,000 requests. This range shows throughput value of about 90,127 requests/second until a maximum request capacity is reached at 790,000 requests. The system thenbecomes non-responsive or crashes at this point. This performance is approximately triple that

Figure 5 The scalability test of MUBaaS

Table 1 The scalability testing

1 Broker 2 Brokers 3 Brokers 4 Brokers 5 Brokers 6 Brokers

Minimum throughput(request/second)

2991.45 3022.45 3122.45 3002.45 3504.62 3504.62

Maximum throughput(request/second)

32651.56 60501.99 93765.00 135,001 166766.87 198901.51

Mean capacity(request/second)

24631.95 44873.67 64539.31 80373.06 93082.67 112692.24

Maximum request capacity(request/second)

250,000 520,000 790,000 1000,000 1000,000 1000,000

Broker is the same as Sub-Proxy as used throughout the work

World Wide Web (2016) 19:5–19 15

of the centralized broker (CSB-UCC) assuming we maintain the same mobile request rate at8.3 requests/second.

When there are four sub-proxies (i.e., 4 Brokers), we observed an increase in the throughputuntil the value stabilizes from 930,000 requests. This range shows throughput value of about130,000 requests/second until a maximum request capacity is reached at 1,000,000 requests.The system then becomes non-responsive or crashes at this point.

In the setup for 5 and 6 Brokers, the load generator could not issue more than a millionrequests. So, both experiments are limited to 1,000,000 requests capacity. We cannot concludethis is the maximum number of users that 5 to 6 brokers can serve since the limitation is notfrom the MUBaaS system but from the experimental setup. However, even though themaximum value is pegged at 1 million requests, we observed that the throughput values haveimproved compared to the initial setups. With 5 Brokers, the throughput increases until itstabilizes from 960,000 requests. This range shows throughput value of about 166,600requests/second. At the million request mark, the approximate throughput is 166766.87requests/second. When the 6 Broker setup is employed, a million requests shows approximatemaximum request rate of 198901.51 requests/second.

From the entire scalability test, we observed that for a single broker, approximately 30,000users who own on average 8 mobile devices and can make 1 request/second from each device,to access services can be supported. There is an increase in the number of users by approx-imately 30,000 for each additional sub-proxy that is added to the system. Another importantobservation from the graph is that, all the six brokers seem to have equal throughput at thebeginning of the requests. The reason for this is that, the controller keeps sending the requeststo one broker until that broker reaches saturation (where the broker starts sending busymessage back to the controller). It is from this point that the controller will start sending therequests to another node. Hence, we realized that if the total request is say 170,000, thethroughput will be approximately the same for all the 6 brokers since at this number, regardlessof the number of active brokers, only one broker will be working.

4.2 File propagation by MUBaaS from Amazon S3

The MUBaaS framework is tested by hosting the sub-proxies on six (6) Amazon EC2instances. All the amazon EC2 instances are located in North Carolina region. The controlleris hosted on the Windows server in Saskatoon so that it can distribute the load across thevarious distributed nodes.

The aim is to evaluate the performance of MUBaaS in the scenarios where it is used toaggregate the files from Amazon S3. The files are directly placed on the Amazon S3 facility(using the PC) and the MUBaaS is expected to determine the update and push that update tothe mobile devices that subscribe to the system. The identified update is assigned to aparticular node of the broker to handle. Thus, as the requests are increasing, the broker willbe distributing the tasks to several of the nodes.

Table 2 Summary of the Amazon S3 result (With approx. 20,098 users)

Playbook iPad3 Transformer NOKIA

Average window (s) 374.68 444.75 558.34 757.66

Maximum window (s) 663.30 804.12 991.63 1338.55

Minimum window (s) 58.55 71.80 113.48 182.90

16 World Wide Web (2016) 19:5–19

The broker is flooded with several requests to keep the system busy. The load generatorsends requests to simulate the activities of about 20,098 users (representing about 180,882requests). The result is reported in Table 2 and graphed in Fig. 6. The experiment is conductedwith file sizes ranging from 100 MB to 2.4GB. The maximum number of users before thesystem starts exhibiting signs of high latency is 20,114.

The overall result is encouraging in comparison with the Amazon S3 SDK which thecompany released for their mobile devices. From our experiments, we realized that theAmazon S3 application transfers files on the Playbook at an approximate average time of291.93 s. This means the MUBaaS framework is just about 82.75 s slower. However when thenumber of users decrease from 20,000, the MUBaaS framework shows minimal time incomparison to the amazon version. Considering the iPad3, the Amazon mobile app synchro-nizes the files in an approximate 370.38 s duration. On the Transformer Prime and NOKIAdevices, the Amazon mobile app takes approximately 480.63 s and 612.27 s respectively topropagate files.

With amazon having a massive infrastructure, we are proud with the performance ofMUBaaS within the test range. In most cases that we have requesters/users within a regionof less than 20,000, the propagation time of MUBaaS is lower in comparison to the Amazonmobile app. However, the result we report in Table 2 is for 20,098 users. Even at this number,the MUBaaS framework shows only a propagation delay of some tolerable seconds.

5 Conclusions and further outlook

Today, mobile computing has become a huge area of interest to both academicians andenterprise players. This is because mobile devices such as smartphones and tablet deviceshave become the de facto nodes to consume enterprise resources which are deployed as cloudservices. The consistent crave for data, application, and services consumption is driving usersto acquire multiple devices. Similarly, there is growing diversity in cloud product offerings

Figure 6 Data propagation time on Amazon S3 using MUBaaS

World Wide Web (2016) 19:5–19 17

which consumers may be interested in accessing. This creates the need to support consumers touse their n-devices to access m-cloud services, known as the ubiquitous cloud computing.

Frameworks that can integrate multiple services for n-mobile device consumption aregenerally lacking. In this work, we propose the Mobile Ubiquitous Brokerage as a Service(MUBaaS) which is an application broker that can be hosted in any cloud virtualizedenvironment. The framework is an extension on the CSB-UCC [18] platform which isproposed to enable data sharing in mobile and cloud environments. The MUBaaS frameworkis designed as a distributed architecture with the sole purpose of ensuring load balancing; anattempt that is geared towards increasing scalability in comparison to the centralized architec-ture. The work has also proposed three levels of authentication which includes the username/password pair, 3rd party security using tokenization and OAuth 2.0 from social medianetworks, and hybrid authentication (which combines the other two).

The experimental results show that the proposed MUBaaS framework transfers files in soft-real time with minimal delay. Currently, services that have been integrated are Amazon WebServices (e.g., Amazon S3, Amazon SimpleDB, Amazon DynamoDB, Amazon EC2, andAmazon RDS), Dropbox, MEGA, Maqetta, Facebook, Google+, Twitter, and Flickr.

In the future, the work will consider the deployment of a distributed controller that cancoordinate the transactions between the brokers. Also, the work can be advanced to includedistributed gateways rather than a centralized version as seen in the current MUBaaSarchitecture.

Acknowledgments We are grateful to our MITACS partners for funding and the Multi-Agent and DistributedMobile Ubiquitous Computing (MADMUC) Lab.

Further thanks to the Editorial Team of theWorld Wide Web Journal, and the Reviewers of this work for theirinvaluable critique.

Final Thanks to Prof. Richard Chbeir and the organizers of the International Conference on Management ofEmergent Digital EcoSystems (MEDES) 2013.

References

1. ab - Apache HTTP server benchmarking tool, http://httpd.apache.org/docs/2.2/programs/ab.html2. Barnes, S.J.: The mobile commerce value chain: analysis and future developments. Int. J. Inf. Manag. 22(2),

91–108 (2002). doi:10.1016/S0268-4012(01)00047-03. Beccue, M.: Mobile trends: the impact of mobile cloud computing on mobile money. ABI Research, http://

www.abiresearch.com/research/1004455-Mobile+Trends%3A++The+Impact+of+Mobile+Cloud+Computing+on+Mobile+Money (2009)

4. Blum, N., Magedanz, T., Stein, H., Wolf, I. An open carrier controlled service environment for usergenerated mobile multimedia services. In Proceedings of the 7th International Conference on Advances inMobile Computing and Multimedia (MoMM ‘09). ACM, New York, NY, USA, 137–145. doi: 10.1145/1821748.1821779 (2009)

5. Cantara, M. Hype cycle for cloud services brokerage, 2012. Gartner Report, ID:G00234256. http://www.gartner.com/technology/reprints.do?id=1-1BJMEZ4&ct=120731&st=sb#h-d2e3337 (2012)

6. Erlang Programming Language, http://www.erlang.org/7. Gad, S.H.: Cloud computing and mapreduce for reliability and scalability of ubiquitous learning systems. In

Proceedings of the compilation of the co-located workshops on DSM’11, TMC’11, AGERE’11,AOOPES’11, NEAT’11, & VMIL’11 (SPLASH ‘11 Workshops). ACM, New York, NY, USA, 273–278.doi:10.1145/2095050.2095096

8. Gibbs, C.: The rise of tablets in the enterprise. GigaOM Pro (2011)9. Google Project Glass, http://www.youtube.com/watch?v=GrfXtAHYoVA

18 World Wide Web (2016) 19:5–19

10. Greer, M.B. Jr., Ngo, J.W.: Personal Emergency Preparedness Plan (PEPP) Facebook App: Using CloudComputing, Mobile Technology, and Social Networking Services to Decompress Traditional Channels ofCommunication during Emergencies and Disasters. In Proceedings of the 2012 I.E. Ninth InternationalConference on Services Computing (SCC ‘12). IEEE Computer Society, Washington, DC, USA, 494–498.doi:10.1109/SCC.2012.106

11. Hollingsworth, J., Powell, D.J.: Requiring web-based cloud and mobile computing in a computer scienceundergraduate curriculum. In Proceedings of the 49th Annual Southeast Regional Conference (ACM-SE ‘11).ACM, New York, NY, USA, 19–24. doi:10.1145/2016039.2016054

12. Houidi, I., Mechtri, M., Louati, W., Zeghlache, D.: Cloud service delivery across multiple cloud platforms. InProceedings of the 2011 I.E. International Conference on Services Computing (SCC ‘11). IEEE ComputerSociety, Washington, DC, USA, 741–742. doi:10.1109/SCC.2011.107

13. Intel White Paper. A unified mobile architecture for the modern data center. Intel Expressway ServiceGateway (2012)

14. Jain, P., Rane, D., Patidar, S.: A novel Cloud Bursting Brokerage and Aggregation (CBBA) algorithm formulti cloud environment. 2012 Second International Conference on Advanced Computing &Communication Technologies (ACCT), pp. 383–387, 7–8 Jan. 2012, doi:10.1109/ACCT.2012.7

15. Kumar, K., Yung-Hsiang, L.: Cloud computing for mobile users: can offloading computation save energy?Computer 43(4), 51–56 (2010). doi:10.1109/MC.2010.98

16. Li, H., Sedayao, J., Hahn-Steichen, J., Jimison, E., Spence, C., Chahal, S.: Developing an enterprise cloudcomputing strategy. White Paper, Intel Information Technology (2009)

17. Locker Project, http://lockerproject.org/18. Lomotey, R.K., Deters, R.: CSB-UCC: cloud services brokerage for ubiquitous cloud computing.

In Proceedings of the Fifth International Conference on Management of Emergent DigitalEcoSystems (MEDES ‘13). ACM, New York, NY, USA, 100–107 (2013). doi:10.1145/2536146.2536173

19. Lomotey, R.K., Jamal, S., Deters, R.: SOPHRA: A Mobile Web Services Hosting Infrastructure in mHealth.2012 I.E. First International Conference on Mobile Services, pp. 88–95, 24–29 June 2012, Honolulu Hawaii,USA.

20. Meads, A., Roughton, A., Warren, I., Weerasinghe, T.: Mobile service provisioning middleware formultihomed devices. Proceeding WIMOB ‘09, Networking and Communications IEEE Computer SocietyWashington, DC, USA (2009)

21. Mohiuddin, K., Islam, A., Alam, A., Ali, A.: 24X7X365: mobile cloud access. In Proceedings of the CUBEInternational Information Technology Conference (CUBE ‘12). ACM, New York, NY, USA, 544–551. doi:10.1145/2381716.2381820

22. Nair, S.K., Porwal, S., Dimitrakos, T., Ferrer, A.J., Tordsson, J., Sharif, T., Sheridan, C., Rajarajan, M., Khan,A.U.: Towards secure cloud bursting, brokerage and aggregation. 2010 I.E. 8th European Conference onWeb Services (ECOWS), pp. 189–196, 1–3 Dec. 2010, doi:10.1109/ECOWS.2010.33

23. Papageorgiou, A., Lampe, U., Schuller, D., Steinmetz, R., Bamis, A.: Invoking web services based on energyconsumption models. 2012 I.E. First International Conference on Mobile Services (MS), pp. 40–47, 24–29June 2012

24. Rackspace, http://www.rackspace.com/25. Ranck, J.: The rise of mobile health apps. GigaOM Pro (2010)26. Satyanarayanan, M., Bahl, P., Caceres, R., Davies, N.: The case for VM-based cloudlets in mobile

computing. IEEE Pervasive Comput. 8(4), 14–23 (2009). doi:10.1109/MPRV.2009.8227. Schaffer, H.E.: X as a service, cloud computing, and the need for good judgment. IT Prof. 11(5), 4–5 (2009).

doi:10.1109/MITP.2009.11228. Solution Brief. Secure big data analytics - the marriage of REST APIs, Security and Big Data. Intel

Expressway Service Gateway (2012)

World Wide Web (2016) 19:5–19 19

本文献由“学霸图书馆-文献云下载”收集自网络，仅供学习交流使用。

学霸图书馆（www.xuebalib.com）是一个“整合众多图书馆数据库资源，

提供一站式文献检索和下载服务”的24 小时在线不限IP

图书馆。

图书馆致力于便利、促进学习与科研，提供最强文献下载服务。

图书馆导航：

图书馆首页 文献云下载 图书馆入口 外文数据库大全 疑难文献辅助工具