User-controlled resource management in federated clouds

Mosch et al. Journal of Cloud Computing: Advances, Systems and Applications 2014, 3:10http://www.journalofcloudcomputing.com/content/3/1/10

RESEARCH Open Access

User-controlled resource management infederated cloudsMarc Mosch1,2*, Stephan Gro1 and Alexander Schill1

Abstract

Virtualization and broadband Internet connections enabled what is known today under the term cloud. Benefits likescalability and cost reduction by pay per use agreements are accompanied by potential harm to the users data. Sinceexisting cloud solutions can be considered synonymous with unknown locations and potentially hostile environmentssecurity protection objectives can not be guaranteed. Motivated by clouds potential we propose a way to get rid ofthis drawback. We present -Cloud, a personal secure cloud, that enables users to benefit from cloud computing andretain data sovereignty by federating the users own resources. More precisely we present a cloud resource managerthat is able to keep control on the devices forming the users -Cloud as well as the services running on them.

Keywords: Cloud computing; Federated clouds; Cloud resource management; User-control

IntroductionCatchwords like scalability, on demand self service, payper use, availability everywhere and any time describe aneven bigger catchword: cloud computing. Cloud comput-ing has evolved from technologies like utility and gridcomputing or the Internet of services. The progress inthe area of virtualization and the availability of broadbandInternet connections even for average consumers enabledcloud computing. It allows the outsourcing of comput-ing and storage and involves the renting of virtualizedhardware as well as of software running on it.The cloud computing paradigm focuses on offering ser-

vices and differentiates between three service levels [1]: Asa foundation, the Infrastructure as a Service (IaaS) layeroffers pure virtualized hardware like computing, networkand storage. On top of this, the Platform as a Servicelayer (PaaS) provides a development platform for softwarewhich can then be utilised as Software as a Service (SaaS).Orthogonally to these service layers, four types of cloudsare defined based on their consumer groups. The typemostly referred to when talking about clouds is the pub-lic cloud. Users of public clouds share the same resourcesunder control of a cloud provider. In contrast, the users of

*Correspondence: [email protected] Universitt Dresden, Department of Computer Science, Chair ofComputer Networks, D-01062 Dresden, Germany2Technische Universitt Dresden, Faculty of Civil Engineering, Institute ofConstruction Informatics, Dresden, Germany

private clouds are provided with resources that are main-tained by themselves or at least for them alone. Hybridclouds are a combination of public and private cloudswhile community clouds are a combination of several pri-vate clouds. Furthermore, we define federated clouds incontrast to other work such as [2] not only as synonymousto hybrid clouds but as a special mixture of hybrid andcommunity clouds. To be more precise, a federated cloudis formed by an individual combination of public and pri-vate cloud resources as defined by an arbitrary participantof a community cloud.With the outsourcing comes the cost reduction as it is

no longer necessary to run data centres that are dimen-sioned for maximum peak loads and that run most of thetime underutilized. However, these benefits are accompa-nied by a severe drawback that unsettles companies andprevents them from using cloud solutions: the decreaseof data control. Data once outsourced is exposed to loss,abuse andmanipulation. Cloud users are not able to deter-mine where their data is located and who has access toit. The three security protection objectives availability,integrity and confidentiality are endangered in cloud envi-ronments. This is where our approach of a personal securecloud sets.

The -Cloud approachThe FlexCloud research group [3] aims to enable users tooutsource their data and benefit from cloud computing

2014 Mosch et al.; licensee Springer. This is an Open Access article distributed under the terms of the Creative CommonsAttribution License (http://creativecommons.org/licenses/by/2.0), which permits unrestricted use, distribution, and reproductionin any medium, provided the original work is properly credited.

mailto: [email protected]://creativecommons.org/licenses/by/2.0

Mosch et al. Journal of Cloud Computing: Advances, Systems and Applications 2014, 3:10 Page 2 of 18http://www.journalofcloudcomputing.com/content/3/1/10

without losing data control. This is achieved by dividingthe used resources within a federated cloud into trust-worthy and non-trustworthy ones. The devices undercomplete control of the user are per definition trust-worthy whereas foreign resources are assumed to benon-trustworthy until further classification. This personalsecure cloud, or -Cloud is controlled by the so called-Box, a security gateway that manages the separation ofsensitive from public data. The former is stored prefer-ably on trustworthy resources although it might be out-sourced if necessary. An automatic encryption beforehandensures data protection. Public data can be outsourcedunencrypted. While this approach ensures integrity andconfidentiality of important data the usage of informationdispersal mechanisms ensures availability as well. See [4]for further details regarding the implementation of thisfeature. Similar mechanisms apply for the distribution ofservices. So services processing critical data should bebound to trusted resources only.Thus, the -Clouds major objective is to put the user

in a position to externalize his IT-infrastructure withoutlosing the control over his data [5]. Therefore we formthe -Cloud consisting of all resources, services and dataunder the complete control of the user. The user is able toadjust his -Cloud to his actual demands by secure inclu-sion of foreign resources. In doing so, data flow as well asservice execution has to be controlled. Cloud setup andcontrol, data flow as well as service distribution are regu-lated by the -Box. The -Box is composed of four maincomponents, as depicted in Figure 1: (1) the Cockpit, (2)the Service Controller, (3) the Data Controller and (4) theResource Manager.The Cockpit provides the user interface. Although we

are aiming to include as much intelligence in our -Box aspossible, to disburden the user from cumbersome admin-istration tasks, it would be exaggerated to claim that the

-Cloud is able to maintain itself. In order to preventthe user from becoming the weakest link in the secu-rity chain, the cockpit has to put him into a position tosupervise and manage his -Cloud even if he is not anexpert [6,7].The Service Controller is responsible for secure ser-

vice execution. As complete homomorphic encryptionis not yet real-time capable, we realize secure serviceexecution by decomposing services into critical and non-critical sub-services. Critical sub-services process high-confidential data and are executed strictly on trustworthyresources, whereas non-critical sub-services are allowedto compute on arbitrary resources.The Service Controllers counterpart, the Data Con-

troller, takes care of secure cloud storage. We split eachfile into several slices and place each slice encrypted andattached by an authentication code on a different resource.Since only a subset of these slices is required to restore theoriginal information, a high availability is realized [4].Last but not least, the -Box Resource Manager is

responsible for managing the set of all available resourcesand services.

Contributions and outlineIn this work we focus on the development of this ResourceManager. The remainder of this paper is structured as fol-lows. Before actually analysing necessary requirements forthe design of the ResourceManager, we first discuss draw-backs of existing cloud resource management approaches.Going on, we present our three-fold design concept thatcovers service description as well as device and servicecoordination. We then present an overview of our proto-type implementation and discuss first evaluation results.We conclude with a final discussion of our achievementsas well as future work.Our main contributions are:

-CLOUD

DATA

CONTROLLER

SERVICE

CONTROLLER

COCKPIT

RESOURCE MANAGER

-CLOUD ARCHITECTURE

MONITORING

COMPONENT

Figure 1 The -Box. Architectural layout of the -Cloud with a subdivision of the -Box into Service and Data Controller, Cockpit, MonitoringComponent and Resource Manager.


The conceptional and technical development offundamental system components for the setup ofuser-controlled federated clouds.

This includes the development of CRDL, a CloudResource Description Language, that leverages theexisting Open Cloud Computing Interface (OCCI)standard for the PaaS and SaaS layer.

A preliminary version of this work has already been pre-sented at the Utility and Cloud Computing Conferencein 2012 [8]. This revised version provides more detailsand insight in all aspects of our work. Furthermore, wehave added two sections to discuss drawbacks of cur-rent cloud resource management solutions and to presentfirst evaluation results of our ResourceManager prototyperespectively.

Drawbacks of existing cloud resourcemanagementsolutionsTo gain an understanding, which functionality theResource Manager has to provide, we start with an analy-sis of already existing solutions. In order to compare themwith each other, we first of all define following reasonableevaluation criteria.

Availability as open source In order to preventlock-in effects and to enhancesecurity/trustworthiness, only Open Source solutionsor such based on open standards are consideredsuitable.Ability to integrate services from a users devicesFurthermore according to the -Cloud ideapresented in the previous section it is mandatory thatthe sought solution is able to integrate services froma users own devices.Ability to integrate arbitrary cloud providers Thesame applies for the integration of services anddevices from different cloud providers. This includescommunity clouds.Ad hoc migration of the managing componentAdditionally, we aim at enabling the ad hocmigration of the managing component itself betweendifferent parts of the -Cloud due to stability,performance or trustworthiness reasons.Support for IaaS, PaaS and SaaS Last but not least,our solution should support the whole bandwidth ofcloud platforms, i. e. IaaS as well as PaaS and SaaSplatforms.

For our investigation we concentrated on open sourcesolutions and those proposed by academia. Industrysolutions like Akitio MyCloud [9], mydlink Cloud [10],Synology Cloud Station [11] and LenovoEMC PersonalCloud [12] as well as Samsung HomeSync [13] and myQ-NAPCloud [14] have not been considered as they are

proprietary, focussed solely on storage service and arebound to the respective companies storage devices.OwnCloud [15] is a promising open source solution

which unfortunately does not support computing or plat-form services either and nearly no software services yet.Most scientific approaches like the Anzere project [16],

PCP [17] and Cloud@Home [18] are mainly storage cen-tred, offer sometimes groupware functionality but notmore and are therefore not suitable. Some scientificapproaches like the Clouds@Home [19] project seempromising but are still work in progress.Table 1 summarizes how the mentioned cloud resource

management solutions match our evaluation criteria.Obviously, none of them fully meets our requirementswhich motivates the development of our own solution.

Requirements analysisWe start our requirements analysis by detailing the gen-eral tasks a cloud Resource Manager has to perform.Basically, these can be divided in three parts. On the onhand, the users devices must be coordinated in order tocombine them into a -Cloud. On the other hand, thereare the requirements from the other -Box components.Specifically, the description of services to be run withinthe -Cloud as well as their storage and management.Thus, we come to a high-level architectural overview ofthe Resource Manager presented in Figure 2.The connector is more or less a straight forward com-

ponent that encapsulates all necessary functionality forconnecting the Resource Manager with the remainingparts of the -Box as well as with the users own devices orwith external cloud resources. As it only contains techni-cally state of the art mechanisms we skip a more detaileddescription here. Instead, we concentrate on the deviceand service coordination respectively.

Device coordination requirementsFor coordinating the access to all relevant user devicesin the -Cloud the Resource Manager first has to recog-nize the (re)appearance of devices whose status has thento be maintained by a specific device directory. For thispurpose, we distinguish between three general communi-cation scenarios as depicted in Figure 3.

Intra--cloud scenario In this first scenario aresource wants to establish a connection to the-box and both are inside a local area network. Insuch a situation as low operational effort as possibleshould be necessary. In ideal case the resourcedetection and interconnection between resource and-box should work automatically. Furthermore the-box should be safely identifiable and thecommunication should take place in a secure mannerin order to prevent unauthorized access to the userscommunication and data.


Table 1 Comparison of existing cloud resourcemanagement solutions

Approach Open Integration of Integration of Ad hoc IaaS, SaaSsource services from arbitrary migration of and PaaS

users devices clouds the managing component

Industry Solutions No No No No No

OwnCloud Yes No Yes No No

Sparkle Share Yes No No No No

Aero FS Yes No No No No

Anzere [16] Yes Yes Yes No No

PCP [17] Yes ? ? ? No

[20] Yes Yes No ? ?

[21] Yes Yes No No Yes

Cloud CDI [22] Yes Yes ? No No

Social Cloud [23] Yes Yes No No No

Cloud@Home [18] Yes Yes Yes No ?

Clouds@Home [19] Yes ? Yes ? ?

Cloud4Home [24] Yes Yes Yes No No

The solutions are evaluated by means of the criteria defined above. If a matching is not certain due to no or imprecise information, a question mark is entered in thecorresponding field.

Remote Intra--cloud scenario In this secondscenario a resource tries to establish the connectionto the -box from the outside of the local network.Here it is necessary for that resource to know how toestablish the connection to its own -box. Therequirements regarding identifiability and securecommunication are just the same as in theIntra--cloud scenario.Inter--cloud scenario If all the users resources areregistered and with them the services the user

might want to use a service. In order to find anappropriate one he will send a query to the own-Box. If the desired service is not available in theown repository the user can try to use the service ofsomebody else. Every -Box runs its own repository.In order to use foreign services the -Box has toconnect to at least one other -Box. This thirdscenario is the Inter--Cloud scenario where one ormore -Boxes interconnect to share information andresources.

Resource Manager

RESOURCE MANAGER ARCHITECTURE | BASIC OVERVIEW

DATA

CONTROLLER

SERVICE

CONTROLLER

COCKPIT

MO

NIT

OR

ING

CO

MP

ON

EN

T

Service DirectoryConnectorDevice Directory

Devices

Figure 2 The Resource Manager. Basic overview of the Resource Managers architecture.


CLOUD SCENARIOS

Intra- -Cloud Remote Intra- -Cloud Inter- -Cloud

Figure 3 -Cloud communication scenarios.

For each scenario the device directory has to be able tostore all necessary information about available resources.It must be possible to search a device based on theseinformation. Thus, the following two basic requirementsare retrieved from the striven functionalities of the devicedirectory.

Storing The information about devices might eitherbe stored as a file directly into the file system or theymight be stored in a storage system of any kind likefor example in a relational database.Searching Either a device initiates a search forexample to find the current -Box or othercomponents of the -Box incorporate the searchfunction as a subroutine for other tasks. The result ofa request is a set of attributes of the node.

Besides these functional requirements our systemshould also satisfy several non-functional requirements asfollows.

Platform independence According to the -Cloudidea every device might get the -Box status whichbasically means that the same -Box software has torun on all of them independent of their software andhardware platform.Resource conservation To enable all devices to gain-Box status, the Device Directory as well as theother -Box components have to be lightweightenough to run at least in small scenarios with a lowdouble-digit number of devices even on a smartphone if necessary without affecting its mainfunctionalities. This means that a resourceconserving architecture has to be chosen.Security The device coordinator must support theusers wish for confidentiality, integrity andavailability of his data when migrating it to the cloud.Therefore, strong security mechanisms must beintegrated to protect the data traffic carried out bythe device coordinator.

Scalability The number of the devices within thecorresponding -Cloud could vary from half a dozenin a home office to several hundred thousands in abig company. The device directory has to show ahigh scalability to manage such a large number ofdevices with satisfying performance.Responsiveness Besides scalability anotherimportant aspect for the acceptance of such a systemis its responsiveness. It is important to keep waitingtimes for search results as low as possible.

Service coordination requirementsService description format requirementsDuring the handshake between device and -Box thedevice has to publish its services. To describe them aservice interface description format has to be found thatis extensible, widely distributed, easy usable and thatsupports the description of non-functional properties.These requirements have to be meet for the followingreasons:

1. Extensibility: For the description of cloud servicesthey have to be differentiated based on the beforementioned service levels IaaS, PaaS and SaaS. SincePaaS and SaaS show a broad range of properties thatdiffer from provider to provider and from service toservice a fixed basic set of properties is not powerfulenough to describe the services. For example thedescription of functional properties of a routingplanner differ fundamentally from that of an officeproduct. Even IaaS providers need the flexibility toextend the basic feature set. Although it might beassumed that a basic set of computing, storage andnetwork properties is sufficient for them and thatonly units may change from time to time (themeasure for computing power may for examplechange from GigaFlops to TerraFlops) a closerinspection shows that essential infrastructuralchanges occur. It just takes longer time periods for


changes that are fundamental enough to require thedescriptiveness of new properties.General-purpose computing on graphics processingunits (GPGPU) is such a fundamental change.Powered by computing engines and interfaces likeCUDA (Compute Unified Device Architecture) [25]and OpenCL (Open Computing Language) [26] userswere provided with a huge performance boost thatcame with the utilization of GPUs (graphicprocessing units) for former CPU tasks. Amazon forexample offers GPU computing instances since 2011[27]. With this change came the need to extend thegiven set of property descriptions.

2. Non-functional properties: Given a set of serviceswith similar functional properties the non-functionalproperties become important for the selection of themost appropriate service. That is why the descriptionlanguage has to be able to describe them as well.Non-functional properties include the functionaldescription, costs, quality and safety.

3. Distribution: The distribution of the service interfacedescription language plays another important role. Inorder to be able to integrate as much existing servicesas possible a widespread language has to be used.

4. Ease of use: Last but not least the ease of use is amajor feature that should allow service providers toeasily extend the basic set of property descriptionswithout being discouraged by to complex handling.Therefore the service interface description languagehas to be of as low complexity as possible while beingas complex as necessary.

Service directory requirementsTo manage all available services within the -Cloud wefurther introduce a service directory. It has to be able tostore service descriptions and extract information fromthem to build search indexes. It furthermore has to be ableto deliver whole service descriptions or specific informa-tion about them if users request so. Hence, the followingrequirements are retrieved from the striven functionalitiesof the service directory:

Storing The service descriptions might either bestored directly into the file system or they might bestored as a string in a storage system of any kind likefor example in a relational database. Furthermore thestorage subsystem has to be able to store extractedelements and attributes in a way that futureextensions of the service description format can behandled. For management reasons meta data like IDshave to be stored in the same place as theinformation extracted from the service descriptions.Parsing After storing a new service description, thesystem has to extract relevant data from it. Due to

the fact that it can not be foreseen which data mightbe requested by users and which not, all the elementsand attributes have to be considered relevant. Thewhole content of the service description is thereforeextracted and in the following referred to as relevantdata. Since the service description format might beextended, the parser should be able to deal with newelements.Searching It is not only the user that should beenabled to initiate a search. Other components of the-Box might incorporate the search function as asubroutine for other tasks. The data controller mightfor example run a background task that searches forsuitable storage services to disperse the data to. For abroad access to the stored information the ability tocope with syntax variety is important. The use of alexical analyser that can for example handle fuzzyqueries and replace synonyms can make the searchfor users more intuitive and flexible. -Boxcomponents that have to access the service directoryare better suited with a machine readable querylanguage. To face this demand the service directoryhas to be provided with an interface that allows tocouple a variety of query modules to it. The result ofa request is however a list of suitable services. Thesemight be ordered according to a rating either basedon information from a monitoring system or on userdecisions. Although the rating system necessary forthis task is out of focus of this work, the servicedirectory has to be designed open enough to be easilyextended with such a system.Retrieval If the user chooses one of the offeredservices from the list, additional detailed informationand the whole service description might have to beretrieved. Authorisation and authentication ruleshave to be part of an other subsystem of the -Box orshould be encapsulated in a library that all -Boxcomponents can use.

In addition, the same non-functional requirementsalready stated for the device directory apply here, too.Concerning the scalability a maximum amount of 500,000devices for big companies was estimated. Assumed thatnot all devices provide services, an average of two ser-vices per device is likely which sums up a total amount of1,000,000 service descriptions. With the amount of man-aged service descriptions the response time increases andit becomes increasingly complicated to keep users patientif the search is executed directly on the descriptions. Sothe responsiveness of the system has to be high enough toreact within 3 to 4 seconds or faster [28]. For the addingof service descriptions this can be achieved with cachingmechanisms if necessary. In contrast the retrieval of infor-mation has to rely on an efficient indexing technology, e. g.


with binary search trees. Since service descriptions candescribe different resources, they contain various, some-times unrelated data. That implies the need for multi treeindexes. A search combining different parameters resultsin the utilisation of the same amount of search trees.There is the need for a manager for different binary treesand for the trees themselves. But instead of creating themfrom scratch it seems to be more economically to consideronly such existing storage systems that are able to generatethe trees and manage them. The storage system thereforehas to analyse the service descriptions and generate binarysearch trees based on extracted elements and attributes.Furthermore it has to have mechanisms to organise thesearch over multiple trees.

Designing the resourcemanagerIn the following we discuss the conceptual design of theResourceManager based on the requirements determinedin the previous section.

Device coordinationThe design of the device coordinator architecture is pre-sented according to the three scenarios introduced in thelast section.

Intra--Cloud In the previous section lowoperational effort was defined as a requirement whena resource wants to establish a connection to the -Box in a local network. During this initial handshakephase resource and -Box meet each other for thefirst time. The resource shares information about itsavailable services and gets an ID. For the automaticresource discovery Zero Configuration Networking(Zeroconf) [29] seems promising since it is aconfiguration-free network approach that proposestechniques to build up an Internet Protocol withoutintervention from human operators. Participatingresources can automatically connect to the networkand get network addresses assigned. The two mostcommon implementations are Bonjour [30] fromApple and Avahi [31]. Bonjour is an implementationnot limited to Apple OS X and iOS. It also works onLinux and Microsoft Windows. UnfortunatelyBonjour is only partially open source under Apache2.0 license and partially closed source under anApple license. We aim to offer the -Box as opensource. That is why we prefer Avahi which is an opensource implementation developed under GNU LesserGeneral Public License. The needed identifiabilitycould for example be ensured with a PIN code that isshown at a diplay at the -Box. Other ways to safelyidentify the -Box involve for example certificatesand a Public Key Infrastructure (PKI) to check thesecertificates or recommendation or reputation

systems might be utilized. A hybrid encryption willensure a secure communication that is more efficientthan a asymmetric one. Therefore the -Box firstsends its public key to the resource. In case of ansuccessful identity check the resource generates asymmetric key, encrypts it with the -Boxs publickey and hands it over to the -Box. Which for itspart decrypts the symmetric key with the private keyonly known to the -Box. After this the wholecommunication (which includes the remote Intra--Cloud communication) can take place encrypted in alightweight manner with the symmetric key that isnow only known to the resource and the -Box.Since we are in an early state regarding thecommunication protocol we can not offer deeperconceptional insight or implementations. Theessence is that Zeroconf would enable automaticinterconnection between resource and -Box asdesired and that the identifiability might be ensuredvia PIN code, PKI or recommendation or reputationsystems while the secure communication should berealized with a hybrid encryption approach.Remote Intra--Cloud In general it can be assumedthat a remote connection to the -Cloud follows aninitial resource registration like discussed in theIntra--Cloud scenario. If so the necessaryinformation like a constant IP and a port to contactthe -Box from the outside were already handedover to resource by the -Box. If not for examplebecause the user got in possession of a new deviceand is eager to test it before he enters his homenetwork he has to know these information frommemory. The solutions for identifiability and securecommunication can be based on the solutions for theIntra--Cloud scenario.Inter--Cloud The Inter--Cloud scenario isconceivable in two forms. Either all -Boxes are partof a friend of a friend (FOAF) network. In this case itcan be assumed that the users -Box is in possessionof the connection information to all the users friends-Boxes. Then a directed multicast might be the bestway to query for a desired service. Then again if it isassumed that the user does not have such a FOAF atleast one other -Box has to be known. In this case astructured peer-to-peer network can be the solution.If a user enters such a network where he only knowsone other -Box the communication is not limited tothe known instance. In fact directly addressed-Boxes should be able to forward failed servicequeries or to introduce other instances to the new-Box. To cope with -Boxes that are leaving thenetwork unattended because of faulty internetconnections or hardware failures the network has tobe robust. That is the network should be able to heal


itself and replace information that are missing due tothe unannounced absence of the peer. Furthermore itshould be fault-tolerant and highly effective to ensuresuccessful routing of messages.

Given these scenarios, we have identified severaloptions for the general architecture of the device directoryas depicted in Figure 4.Going on, we analysed the use cases for the Intra--

Cloud scenario (see Figure 5).

Join -cloud The first use case captures the contactinitiation between a device and the -Box. Asuccessful attempt results in the -Box revealingitself and sending information to the device how toconnect from the outside of the personal network.Furthermore a certificate has to be generated andhanded over to the device to enable it to identifyitself as an authorised member of the -Cloud.Create connection This use case deals with thecreation of a secure connection between a device andthe -Box. It is required that the -Box is clearlyidentifiable and that the communication takes placein a secure manner in order to prevent unauthorisedaccess to the users data. The device sendsinformation about itself to the -Box. After aauthorisation check the -Box generates a sessionkey for the ongoing communication. Afterwards theDevice Directory marks the device is as connectedand stores the session key.

Delete device record If a device has to be finallydismissed from the network for example because itis broken it has to be deleted from the list ofmanaged devices in order to keep the data baseup-to-date and slim.Set disconnected For management tasks it issometimes necessary to know if a device is availableor not. Therefore it must be possible to set an entryin the data base that marks a device as disconnected.Set -box info The -Box software shouldpotentially run on all -Cloud devices. The -Boxstatus can change from one to another. This meansthat the Resource Manager has to provide a way toassign -Box status to a specific device.Get -box info If a member of the -Cloud wants tocontact its -Box it has to be provided with amethod to get to know which other member of the-Cloud is the current -Box.Revoke certificate It has to be ensured thatcertificates once handed out by the -Box can berevoked to exclude devices from the -Cloud if theyare responsible for access violations or other harmfulbehaviour. The revoking has to be initiated by acomponent of the -Box which sends the ID of thedevice that has to be excluded from the -Cloud.After the Device Directory added the certificate ofthe corresponding device to the revoke certificationlist, a list of the connected devices is requested whichleads the Device Directory to return a list of them. Arequest should then be send to all devices of the list

Dir1.1.1_t1Dir1.1.1_t2

Dir1.1.1_t3

DIR1

DIR1.1

DIR1.2

Dir1.2.1_t1Dir1.2.1_t2

Dir1.2.1_t3

Dir1.2.2_t1Dir1.2.2_t2

Dir1.2.2_t3

DirA DirB

DirC

DirA_t1DirA_t2

DirA_t3

DirB_t1DirB_t2

DirB_t3

DirC_t1DirC_t2

DirC_t3

OVERALL DIRECTORY ARCHITECTURE OPTIONS

inte

rnal

cen

tral

inte

rnal

dec

entr

al

external peer-to-peer external hierarchically

DIR1

DIR1.1

DIR1.2

DIR1.1.1

DIR1.2.1

DIR1.2.2

Figure 4 Architectural options of internal and external -Cloud device directories.


USE CASE DIAGRAM FOR THE DEVICE COORDINATION

Join -Cloud

Create Connection

Device

-Box

DeviceDirectory

Delete Device Record

Set Disconnected

Set -Box Info

Get -Box Info

Revoke Certificate

Figure 5 Use cases regarding the device coordination.

in order to cause each of them to add the undesireddevice to the own revoke certification list.

Service coordinationService descriptionAs the analysis shows there are four main features theservice interface description language has to provide. Ithas to be easily extensible and support the description ofnon-functional properties while being widely distributedand of low complexity in order to achieve a good easeof use. Existing service interface description languagesare either easily extensible and support the descriptionof non-functional properties (like USDL and OWL-S) orthey are widely distributed and show a good ease of use(like WSDL, WADL) as to be seen in Table 2.To the best of our knowledge there is no approach that

is fulfilling all four requirements in one solution. Here iswhere a meta model comes in hand that was designed todescribe cloud resources. It is the so called Open CloudComputing Initiative (OCCI) [32] powered by the OpenGrid Forum [33]. At the moment it consists of a coremodel [34] and an infrastructure extension [35]. A com-bined diagram of both models is depicted in Figure 6.The graphic except the grey parts represents the OCCIcore model with an infrastructure extension according tothe specifications v1.1. Among other things this modu-larisation makes the model easily extensible. Well knownopen source cloud attempts like OpenNebula, Openstackand Eucalyptus already implement OCCI [36]. Given this

high distribution and the simple but easily extensiblemodel OCCI seems to be an appropriate base for an ownimplementation to describe services.

Service directoryThe design of our service directory is based on the usecases depicted in Figure 7.

Add service description To be able to describe cloudresources, CRDL, a Cloud Resource Description Lan-guage, was developed. It leverages the existing OpenCloud Computing Interface (OCCI) standard for the PaaSand SaaS layer. To publish the services of a device anappropriate CRDL file has to be added to the ServiceDirectory. Therefore the file is sent to the to the ResourceManager. The Resource Manager checks the files valid-ity and adds some meta data like the users id. The fileis then translated in a format that can be understood bythe Resource Managers Service Directory where it is sentnext. In the Service Directory a file id is generated andadded as meta data. Furthermore the CRDL file has to beparsed to extract relevant data. All information will thenbe stored in the Service Directorys own storage. Finally anacknowledgement and the newly generated id will be sentback to the device.Search service To search a service a device sends arespective search request to the -Box. The request ishandled by Service Directorys Storagemodule. As a resultthe Service Directory returns a list of CRDL files match-ing the search criteria. The Resource Manager as well as

Table 2 Comparison of service description formats

USDL WSDL WADL OWL-S WSMO OCCI

NFP Support Very good Existing Existing Existing Existing Existing

FP extensibility Existing No/bad No/bad Good Good Very good

NFP extensibility Very good No/bad No/bad Very good Very good Very good

Distribution No/bad Very good Existing No/bad Existing Existing

Ease of use Existing Very good Very good No/bad No/bad Good


Entity

+source

target

0..1

MixinAction

Category

Kind

Link

IPNetworkExtension

+id : URI+title : String [0..1]+public_service_description : ServiceDescription+private_service_description : ServiceDescription+occi.entity.ipnetwork : IPNetworkextension

+requirements

links

Resource+summary : String [0..1]

Service Description

-entity_type : Entity +mixin_address : URI

ApplicationPlatform Functionality Compute Storage Network

StorageLink WebbrowserInterface ServiceInterface ApplicationInterfaceNetworkInterface

platform_extensions

OCCI XAAS EXTENSION

Figure 6 OCCI extensions. A simplified representation of the OCCI Core Model with infrastructure extension for the IaaS domain according to thespecifications v1.1. The grey parts mark an additional extension for the integration of existing service description formats as well as additionalextensions for non-functional properties, platform and software extension for the XaaS domain and required interface extensions.

USE CASE DIAGRAM FOR THE SERVICE COORDINATION

Add Service Description

Search Service

Retrieve Service Description

Device

-Box

Update Metadata

Service Directory

Delete Service Description

Update Service Description

Figure 7 Use Cases for the service coordination.


other components of the -Box can filter and reorder theresults, for example according to the knowledge of a ratingmodule, before they are resend to the inquiring system.Retrieve service description Retrieve a CRDL file basedon the ID assigned during the addition of the servicedescription.Delete service description Delete a CRDL file based onthe ID assigned during the addition of the service descrip-tion.Update service description Update a CRDL file basedon the ID assigned during the addition of the servicedescription.Update metadata Update a CRDL files metadata basedon the ID assigned during the addition of the servicedescription.

Overall architectureA schema of the Resouce Managers architecture is shownin Figure 8. It consists of three main modules, one foreach directory and one the Connector as an inter-face. This Connector itself again contains three modules.The Internal Call Manager is responsible for the com-munication with other -Box components while Listenerand External Call Manager cover the communication withexternal resources. The Device Directory consists of twomodules. The Core module encapsulates management

functionalities and the Storage module offers storagefunctionalities. In addition to two similar modules, theService Directory contains a parser module, which isresponsible for the parsing of the CRDL files.

Prototype implementationDevice directoryAccording to the -Cloud idea, the -Box software isintended to run on a variety of hardware platforms. That iswhy the prototype is based on the platform-independentprogramming language Java. With future migration inmind, devices and -Box should run different instances ofthe same program. Migrating the -Box from one deviceto another then just involves a change of the status ofboth devices and a transfer of administrative tasks, infor-mation and rights. It seems appropriate to use RMI theRemote Method Invocation protocol for the communi-cation. It is Javas version of an RPC (Remote ProcedureCall). An RPC enables one program to execute proce-dures in the foreign address space of another program ona different machine. The Java RMI API allows to invokeJava methods remotely from another (JVM) (Java Vir-tual Machine). The machine which is in possession ofthe remote object registers it at the RMI-registry with aunique name. The machine that strives for remote accessuses the objects name to retrieve an object reference from

Resource Manager

RESOURCE MANAGER ARCHITECTURE | COMPLETE OVERVIEW

DATA

CONTROLLER

SERVICE

CONTROLLER

COCKPIT

MO

NIT

OR

ING

CO

MP

ON

EN

T

Service DirectoryConnectorDevice Directory

Devices

Storage Core ParserCore

Storage

Internal Call Manager

External Call Manager

Listener

Figure 8 Complete overview of the Resource Managers architecture.


the RMI-registry. The object reference has to correspondwith its remote interface. If the machine that strives forremote access invokes a method from the object refer-ence of the machine which is in possession of the remoteobject, the method on the remote object is executed. Inthis process external code might be loaded dynamicallyfor usage. As a result of the invocation return values or anerror message are sent back. This response is useful in thecommunication process between client and -Box sincein most cases it is initiated by the client which relies on aresponse. In seldom cases the communication is initiatedby the -Box and is then sent to all connected clients inthe network. But this is a rare event. It is so rare, that RMIoverhead compared with publish subscribe mechanisms isacceptable.The most obvious storage solution for data sets is stor-

ing them in the file system. But if the data to be storedare well structured, data bases can be a faster solution.Data bases that are able to store the data completely inmain memory have to be preferred. They utilise highthroughput and low response times of main memory andachieve a much better performance than common databases, which work mostly on comparatively slow harddisks. With HSQLDB (HyperSQL DataBase) [37] one ofthe most popular Java-based open source databases isused which is able to run completely in-memory.

Service descriptionThe base of the -Box service description is the OCCIcore specification with some extensions implemented asXML Schema. The class resource is complemented by acomplex data type converter specifications that consist of: a classification of the service description of the service

provider as Enum (e.g. WSDL,WADL and OWL-S) the corresponding service description address in

form of an URI the address of the converter for the extraction of the

needed data from the service providers servicedescription in form of an URI

an execution instruction for the converter (e.g. XSLTfor WSDL/WADL/OWL-S converter in XSL)

This converter specifications are stored in a separatelocal file and can therefore be easily extended by the

user for other forms of service descriptions. The coreclass Link is extended by inheritance for diverse interfacetypes of the services in addition to existing specificationsof the OCCI infrastructure model. The resulting inter-face class structure is integrated into the resource classas an abstract element. Its ascertainment of goods can begenerated at runtime together with other resource ele-ments from the providers service description by meansof the converter specification. The class resource usesthe extensions for infrastructure services of the OCCIinfrastructure model. With Software and Platform ownextensions for software and platform services are addedin form of ascertainments of goods of the resource class.The class Platform is composed of one or more instan-tiations of each of the following: Compute, Storage andsoftware. Non-functional extensions (e.g. for quality andsafety features) as well as individual extensions of theservice description by the -Box users are integratedvia Mixins. Mixins allow to extend Ressource with addi-tional arbitrary attributes. For reasons of manageabilityand clarity of the service description the class Mixinis extended by the address of the Mixin in form ofthe URI of the XML source file which is integrated atruntime.

Service directoryFor the implementation of the service directory we haveexisting basic technologies that are open source andtherefore compatible with the -Cloud idea. Table 3summarizes the results of our analysis. We have cho-sen Lucene as our founding implementation componentsince it fulfils all our functional requirements. The fulfil-ment of non-functional requirements is only of interestfor the complete Service Directory. For a basic technologylike Lucene it is only important to be platform inde-pendent, resource conserving, scalable, responsive andable to cope with CRDLs inherent complexity. Accord-ing to the Apache project [38] all these requirements arefulfilled.

Evaluation and discussionIn this section we describe our evaluation of the ResourceManagers efficiency. After introducing the evaluationmethodology, our results are presented and discussed.

Table 3 Comparison of basic technologies for the service directory

LDAP RDBMS File system XML Query Digester LuceneLanguages

Parsing Impossible Impossible Impossible Intended Intended Intended

Storing files Possible Intended Intended Impossible Possible Possible

Storing data Intended Intended Possible Impossible Possible Intended

Searching Intended Possible Possible Impossible Impossible Intended

File retrieving Intended Intended Impossible Impossible Impossible Intended


MethodologyIn order to validate sufficient performance in real-worldscenarios, several test scenarios are applied. As alreadydiscussed the -Box and thereby also the Resource Man-ager have to be scalable to manage even big usage scenar-ios with up to 500,000 devices and 1 million CRDL files.At the same time the response of the system should notexceed 4 seconds to provide a good user experience [28].The tests cover this big scenario with 1 million CRDL filesand a middle size scenario with 100,000 CRDL files. Evensmaller scenarios are indirectly included in themiddle sizescenario.Service Directory and Device Directory are accessed by

only one Connector and therefore have to handle requestsonly sequentially. The Connector can be accessed by sev-eral devices at the same time. Therefore in theory it has tomanage parallel requests and is responsible for the execu-tion order. However, the prototype takes no care of this.Since for the tests only one client sends requests they enterthe connector one by one and are executed sequentially.So the scalability can just be assumed.Four test parameters can be used to judge the

performance of the developed Resource Manager. Theparameter which represents the efficiency of the ResourceManager the most is the response time (tresp). It is definedas the period between the moment when the device sendsthe request and themoment when it receives the response.The period starting with the point when the Listenermodule receives the query and ending when it sends theresponse is the period which defines the execution time.Thus, the response time equals the execution time (texe)plus twice the network delay (tnd):

tresp = texe + 2tndAnother important parameter is the CPU load. As

already mentioned the -Box may run on a device whichhas another original purpose. If a smart phone acts as a -Box, it should for example still be able to make and acceptcalls. That is why the CPU should be used economical at least in smaller -Clouds. In case of bigger -Clouds,it seems plausible that the -Box is hosted by a dedicatedserver, rendering CPU load less relevant, as long as it isnot excessive.The memory consumption is a further parameter which

may also interfere with using the host system in smallerscenarios for its original purpose. It is hard to find anobjective requirement regarding the acceptable amount ofutilised memory. That is why it is only possible to rely onsubjective estimation.Last but not least the size of the Device Directorys

database and the Service Directorys index are importantparameters. They have to be within reasonable limits.Our test cases have been designed with all processes in

mind which involve a waiting user. These are:

join -Cloud create connections add new CRDL files search services retrieve CRDL files delete CRDL files update CRDL filesFurthermore these processes have to be evaluated under

different sizes of -Clouds according to the before men-tioned usage scenarios. The evaluation covers a middlesize -Cloud with 0 to 100,000 CRDL files and 50,000devices and a big -Cloud with 10,000 to 1,000,000 filesand 500,000 devices.To reflect conditions of real world personal clouds, the

client server communication takes place inside a localnetwork. Apart from that, the systems differ for the two-Cloud sizes. The middle size scenario involves a laptopcomputer with the following characteristics hosting the-Box: Model: Lenovo G550 CPU: 2.1 GHz Intel Core 2 Duo Memory: 3072 MB RAM Architecure: 32 bit HDD: WesternDigital 500 GB 5400 rpm (ATAWDC

WD5000BEVT-22ZAT0) OS: Debian 6.7 Squeeze Runtime Environment: Oracle JDK 7The laptop computer itself was the server and a QEMU-

KVM 0.12.5 based virtual machine with 1 CPU core and128 MB of RAM was used as client. The server for the bigscenario is a virtual machine with the following specifica-tions:

CPU: 4 2.4 GHz (only one core used) Memory: 8192 MB RAM Architecure: 64 bit OS: Debian 6.7 SqueezeThe client virtual machine shows the following charac-

teristics:

CPU: 1 2.0 GHz Memory: 500 MB RAM Architecure: 64 bit OS: Debian 6.7 SqueezeBoth virtual machines run on a host system with the

following characteristics:

Model: Fujitsu Primergy RX300S6 CPU: 2 Xeon E5620 2,4 GHz 4C/8T 12 MB RAM: 4 12 GB HDD: Fujitsu ETERNUS DX APAK 6x750 GB (Raid5) Virtualisation Environment: VMWare vSphere 4.1


The measurements presented in the following shouldprovide a coarse comparison of the performance of thetwo systems. They were taken with the GNU/Linux filecopy and conversion command dd.The CRDL files for the test were generated based on

four main structure types one for storage, one for com-pute, one for platform and one for software descriptions.To achieve good diversity which means a huge set ofunique CRDL files, parameters were changed randomlywithin each of the four groups always within predefinedlimits.The queries were generated at runtime. There are

four query types: the fastest possible without parameterswhich retrieves all services; the normal one, a query forstorage, with different sizes and status online; the slow-est, a query for compute services with close restrictionsfor all five possible parameters; a query which searches forstorage with unsatisfiable demands.

ResultsResponse time

Join -cloud In the middle size scenario run on thelaptop computer the fulfilment of join requests onserver side (execution time) took 2.25 milliseconds inaverage with a maximum of 202 milliseconds. 98.9percent of the request where processed within 2 to 8milliseconds. And 99.9 percent took not longer then64 milliseconds. The overall network delay with anaverage of 2.25 milliseconds leads to an averageresponse time of 4.89 milliseconds and a maximumresponse time of 206 milliseconds on client side. 98.2percent of the responses reached the inquiring clientwithin 2 to 8 milliseconds. And 99.9 percent took notlonger then 68 milliseconds. Since the overallnetwork delay is constant and negligible small theexecution time on server and the response time arealmost identical. We found that the response time isindependent from the amount of already joineddevices. This result was expected. It reflects the fact,that information about already registered nodes isnot retrieved during the join process.In the big scenario executed on the virtual machinethe fulfilment of join requests on server side took1.04 milliseconds in average with a maximum of 2179milliseconds. The second longest join was executedwithin around 1 second. 99.994 percent of therequest where processed within less then 10milliseconds. And only 10 of 500,000 joins tooklonger then 100ms. The overall network delay withan average of 1.04 milliseconds added to a totalaverage execution time of 1.73 milliseconds. 99.988percent of the responds reached the inquiring clientwithin less then 10 milliseconds. As in the mid-sizescenario, we found that the response time for join

requests is independent from the amount of alreadyjoined devices.Create connections In the middle size scenario theresponse time grows almost at a linear rate with theamount of registered devices. After each 10,000 joinoperations the time for connecting the accordingclients was measured. After joining the last 10,000clients to the -Cloud each of the subsequentconnections took around 38.5 milliseconds inaverage from sending the request to receiving theacknowledgement. The drop at the beginning is theresult of initial just-in-time compilation of the JVM.In the big scenario the response time also growsalmost at a linear rate with the amount of registereddevices. After each 100,000 join operations the timefor connecting the according clients was measured.After joining the first 100,000 clients to the -Cloudeach of the subsequent connections took around 34milliseconds in average while the last 100,000connections took around 264 milliseconds fromsending the request to receiving theacknowledgement.Add new CRDL files In the middle size scenario runon the laptop computer the fulfilment of an addrequest on server side took 262 milliseconds inaverage with the four slowest responses between 6and 11 seconds. 88 percent of the requests wereanswered in less than 0.3 seconds and 99.8 percenttook less than 2 seconds. Since the overall networkdelay is similar to the delay in the join case theexecution time can be considered almost equal to theresponse time.In the big scenario, run on the virtual machine thefulfilment of an add request on server side took 29milliseconds in average which is almost ten timesfaster than on the laptop computer. The four worstresults reached from 20 to 45 seconds. Nevertheless,99.83 percent of the requests were answered withinless than 300 milliseconds and 99.99 percent withinless then 1 second. Since the overall network delay issimilar to the delay in the join case the execution timecan be considered almost equal to the response time.Search services As it can be seen in Figure 9 theresponse time for search requests depends on thesize of the index and grows with a linear rate.Retrieve CRDL files After each 1,000 added CRDLfiles the retrieval of 100 files was measured. Theretrieval took an average of 6.7 milliseconds. Theslowest request took 71 milliseconds. 99 percent ofthe requests took not more than 14 milliseconds. 99.9percent of the retrieve requests took less than 39milliseconds and 99.99 percent less than 45milliseconds. We found that the response time growsonly negligibly for the mid-size scenario.


Figure 9 Response time for the search a service request. The abscissae show respectively the amount of already added CRDL files and aretherefore like time-lines. The ordinates both show the response time in milliseconds. For the response times for every 10,000 requests maximum,75%, median, 25% and minimum are shown. The circles mark faulty measured values not considered for the determination of these quantiles.

After each 10,000 added CRDL files the retrieval of1,000 files was measured. The retrieval took anaverage of 9.3 milliseconds. The slowest request took40 milliseconds. 99 percent of the requests took notmore than 14 milliseconds. 99.9 percent of theretrieve requests took less than 28 milliseconds and99.99 percent less than 37 milliseconds. Just as in themid-size scenario the response time for the bigscenario grows negligibly.Delete CRDL files After each 1,000 added files 10 ofthem were deleted for this test. The response timefor the deleting requests took 121.9 milliseconds inaverage. 90 percent of the requests took not longerthan 146 milliseconds. The longest request took 302milliseconds. Up to 100,000 added files the responsetime grows with the size of the index but notconsiderably.After each 10,000 added files 10 of them were deletedfor the big scenario test. The response time for thedeleting requests took 20.5 milliseconds in average.The longest request took 331 milliseconds. 90percent of the requests did not take longer than 25milliseconds. Up to 1,000,000 added files the responsetime grows with the size of the index. Neverthelessthe response time is superior considering that theaverage value is in the range of black-white-blackresponse times of LCD displays. And even the worstresult with 331 milliseconds corresponds with theduration of a blink of the human eye.Update CRDL files For this test 10 files wereupdated every 1,000 added files. The response timefor the updating took 371,6 milliseconds in average.The longest update took 2,773 milliseconds. 90 percentof the requests were answered within a maximum of438 milliseconds. The growing of the request time withthe amount of files in the index is negligible.

The same applies for the big scenario where 10 fileswere updated every 10,000 added files. The responsetime for the updating took 55.2 milliseconds inaverage. This is almost 7 times faster compared withthe middle size scenario the result of the morepowerful host system. The longest update took 780milliseconds. 90 percent of the requests wereanswered within a maximum of 79 milliseconds.Scalability assumptions It can be assumed that theresponse time will increase with the number ofparallel requests. Given the almost consistent lowresponse times for the different processes thisincrease can be assumed marginal. Except for thesearch process, it is most likely that the responsetime will not exceed the critical 4 seconds mentionedbefore. However, referring to this 4 second threshold,the search process only performed well for up to300,000 stored service descriptions. The number ofmanageable descriptions will decrease with thegrowing number of parallel requests, since theregular expressions used for the search are veryresource intensive. However, it is likely thatcompanies big enough to depend on hundreds ofthousands of service descriptions will have powerfuldedicated -Box servers to speed up the responsetimes to a bearable extent. Furthermore it has to bepointed out that the developed architecture onlycovers service brokering. Regarding performance theservice brokering is far less important then the actualservice usage. The usage is responsible for the maintraffic and takes place between the clients only. Noserver is involved.

Index and database sizeThe generated CRDL files have a size between 2 KB and9 KB with an average of 6 KB. Figure 10 shows that the


SIZE OF HSQLDB

0 100K 200K 300K 400K 500K

050

100

150

200

> # of devices (thousands)

> s

ize

in M

B

0 200K 400K 600K 800K 1M

> # of service descriptions 0

3.0

2.5

2.0

1.5

1.0

0.5

SIZE OF LUCENE INDEX

> s

ize

in G

B

Figure 10 Lucene index and HSQLDB data base size in relation to the number of service descriptions and devices.

size of the index grows at a linear rate with the amountof files. The index including CRDL files plus extracteddata and meta data is 1.6 to 1.9 times smaller than thestorage space needed by the original CRDL files. 590 MBfor 100,000 CRDL files mean a Lucene index of 361 MB.In the big scenario the compression is even more effi-cient most likely due to a higher rate of reusable patternsfor Lucenes compression algorithms. With growing indexthe compression induced perennial index size reductionshows as a spiky graph. The storage space of 5,896 MB for1,000,000 CRDL files is reduced to 3,019 MB if the filesare stored and described in the index. Extensions of thedescription viameta data will increase the size of the indexbut the growing will be negligible. The size of the databasealso grows at a linear rate. 50,000 joined devices occupy22.6 MB if they are all connected. 500,000 devices use

219 MB. The size of the data base depends on the num-ber of joined and connected nodes and on the amount ofrevoked certificates.

CPU load andmemory consumptionTable 4 shows CPU load as well as memory and hard diskconsumption for the different use cases. The adding pro-cess depends more on the hard disk than on the CPUor the memory. On the laptop computer there were forexample only 10 to 20 percent CPU usage. The com-parison of the adding process for laptop computer andvirtual machine shows that a fast hard disk can shift thebottleneck. Since the virtual machines host was a serverwith 6 fast SAS disks in RAID5 mode the CPU becamefully utilised. In contrast searching requests demandedfull processing power on both, server and laptop

Table 4 Utilisation of processor, memory and hard disk for the specific use cases

Use case CPU RAM HDD

Laptop computer

Join and connect 60%70% 78 MB84 MB Low load

Add 1020 Grows linear High load

Search 100% 330 MB360 MB Low load

Retrieve 100% ca. 300 MB Low load

Delete 20%30% ca. 200 MB High load

Update 30%50% ca. 350 MB High load

VMWare

Join and connect 73%75% 140 MB190 MB Low load

Add 100% Grows linear High load

Search 100% up to 2 GB per request Low load

Retrieve 100% up to 2 GB per request Low load

Delete up to 100% up to 1.5 GB Medium load

Update 50%60% ca. 400 MB Medium load

The values for processor and memory are based on observations during the evaluation while the content of the last column is based on theoretical assumptions.


computer. The memory consumption did not exceed 360MB on the laptop computer while the virtual machine hadto provide the -Boxwith up to 2GB per request when theindex held 1million service descriptions. After the requestthe size of the program in memory fell below 200 MB.

SummaryThe developed prototype works well for networks witha file amount of up to around 300,000 CRDLs with thegiven virtual test server and with a sequential order ofrequests. Larger amounts of service descriptions lead toresponse times for search requests of 4 seconds and more,at least with the given virtual test server. Anyhow, is likelythat such large -Clouds are managed by powerful dedi-cated -Box servers, which would be capable of handlingmore service descriptions. Then again, the tested pro-gram was only a prototype. Not all designed features wereincluded. The communication channel was for examplenot encrypted and was furthermore based on a localarea network. Additional encryption will add overheadand increase the response time. Communication over theInternet can be substantially slower then our LAN-basedtests, depending on the quality of the users connection.But there are also possibilities to enhance the prototypewith regard to its performance. The Lucene based Storagemodule of the prototype is single threaded and there-fore only utilises one core. But since the design of theResourceManager is modular, Lucene could be exchangedfor example with ElasticSearch [39] an extension ofLucene which enables distributed indexes. This wouldallowmulti threading and therefore decrease the responsetime with the growing number of distributed indexes.The response time for the search requests could also bereduced if regular expression queries would be replacedby less resource intense query types. During the parsingprocess frequently searched properties could be extractedand added as meta data to the service records. Since thiswould prevent browsing indexes for whole CRDL files atrun time, it will speed up the search process.

ConclusionCloud computing attracts, inter alia, with scalability andcost reduction. However, clouds benefits are accompa-nied by potential harm to the users data. Existing cloudsolutions can be considered synonymous with unknownlocations and potentially hostile environments. Thereforesecurity protection objectives can not be guaranteed inthe cloud. Motivated by cloudAZs potential we proposeda way to get rid of this drawback. We presented -Cloud,a personal secure cloud, that enables users to benefit fromcloud computing and retain data sovereignty by federat-ing the users own resources. More precisely we presentedthe prototypic implementation of a Resource Manager forpersonal secure clouds. This includes the coordination of

devices which form this cloud as well as the descriptionof the services they provide and the description of exter-nal services. For this description an intermediary format,the Cloud Resource Description Language (CRDL) wasdeveloped as an extension of the Open Cloud ComputingInfrastructure (OCCI). Since OCCI is currently limited toinfrastructure services the approach has been extendedto support PaaS and SaaS services as well. Furthermore,an architecture for the coordination and management ofCRDL service descriptions and the respective services wasdeveloped. As a foundation for the -Box the ResourceManager enables users to (re)gain their data sovereigntywhen going to the cloud. Scalability and usability of ourprototype have been empirically demonstrated by exten-sive lab tests.

Future workUntil now we have neglected the need for a trust manage-ment system although it represents an inevitable require-ment for real life scenarios. However, the estimation oftrust in services, resources and provider implies manifoldresearch challenges from different scientific disciplines.Thus, we have postponed this issue for future work.More technical aspects for further development include

distribution support, temporary fragmentation or inter-connecting several -Clouds in order to form a com-munity cloud. As each component of the -Box can beconsidered to be a service, it should be possible to dis-tribute them throughout the -Cloud. This implies mech-anisms to handle abrupt disconnections of devices whichhost services, intelligent replication of services, serviceredundancy and so on. The scientific area of peer-to-peer protocols offers a variety of potentially suitable basictechnologies for this challenge.For scenarios like business trips it seems plausible that

a user would benefit from a mobile -Box. Building upon already implemented basic -Box status functionali-ties, intelligent hand over mechanisms can be developed.Depending on the amount of data necessary for a businesstrip, it might be wise to migrate the -Box and relevantdata in advance. Particularly interesting is the questionwhich criteria can be used to predict such user behaviourand how this data can be aggregated, utilised and secured.Finally, in community cloud scenarios every participat-

ing -Box would provide at least partial access to itsresources for friendly -Boxes in addition to its owndevices. This entails authentication checks during search,update, delete and retrieval processes.

Competing interestsThe authors declare that they have no competing interests.

Authors contributionsAll the listed authors made substantive intellectual contributions to theresearch and manuscript. Specific details are as follows: MM: Led the work onrequirements gathering and analysis, design, development and evaluation of


the Resource Manager. Carried out the analysis of related work. Wrote themain part of the paper based on his PhD thesis. Contributed to the editing andpreparation of the paper as well as the overall architecture of the -Box. SG:FlexCloud project lead. Responsible for the overall technical approach andarchitecture, editing and preparation of the paper. Contributed torequirements gathering for the Resource Manager. AS: Principal investigator ofthe FlexCloud project. All authors read and approved the final manuscript.

AcknowledgementsThis work has received funding under project number 080949277 by means ofthe European Regional Development Fund (ERDF), the European Social Fund(ESF) and the German Free State of Saxony. The information in this documentis provided as is, and no guarantee or warranty is given that the information isfor any particular purpose. The authors would like to acknowledge thecontributions of Hartmut Schweizer in the initial version of this paper [8] andhis support in the design and development of CRDL. Furthermore, weappreciate the assistance of Ievgenii Maksymiuk in the development andevaluation of the Resource Manager prototype.

Received: 2 December 2013 Accepted: 4 June 2014

References1. Mell P, Grance T (2011) The NIST definition of cloud computing. Technical

Report 800-145. National Institute of Standards and Technology (NIST),Gaithersburg, MD, http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf

2. Rochwerger B, Breitgand D, Eliezer L, Galis A Nagin K, Llorente IM,Montero R, Wolfsthal Y, Elmroth E, Cceres J, Emmerich W, Galn F (2009)The reservoir model and architecture for open federated cloudcomputing. IBM J Res Dev 53(4):4:14:11

3. Flexible Service Architectures for Cloud Computing, FlexCloud projectweb site. http://flexcloud.eu/. Accessed 2014-06-12

4. Strunk A, Mosch M, Gro S, Tho Y, Schill A (2012) Building a flexibleservice architecture for user controlled hybrid clouds In: 7th InternationalConference on Availability, Reliability and Security, AReS 2012. IEEE,Prague, CZ

5. Gro S, Schill A (2012) Towards user centric data governance and controlin the cloud. In: Camenisch J, Kesdogan D (eds) Open Problems inNetwork Security. Lecture Notes in Computer Science, vol 7039. Springer,Berlin/Heidelberg, pp 132144

6. Moltkau B, Tho Y, Schill A (2013) Managing the cloud service lifecyclefrom the users view. In: Proceedings of the 3rd International Conferenceon Cloud Computing and Services Science (CLOSER). SCITEPRESS DigitalLibrary, Aachen

7. Spillner J, Schad J, Zepezauer S (2013) Personal and federated cloudmanagement cockpit. PIK Praxis der Informationsverarbeitung undKommunikation 36(1):44

8. Mosch M, Schweizer H, Gro S, Schill A (2012) Automated federation ofdistributed resources into user-controlled cloud environments. In: 5thIEEE/ACM International Conference on Utility and Cloud Computing (UCC2012), 2nd International Workshop on Intelligent Techniques andArchitectures for Autonomic Clouds (ITAAC 2012). IEEE, Chicago, Il, USA,pp 321326

9. Akitio My Personal Cloud Server Product web site. http://www.akitio.com/information-center/personal-cloud-server. Accessed 2014-06-12

10. mydlinkTM . Product web site. http://www.dlink.com/de/de/home-solutions/mydlink/what-is-mydlink. Accessed 2014-06-12

11. Synology Cloud Services. Product web site. http://www.synology.com/dsm/home_file_sharing_cloud_station.php. Accessed 2014-06-12

12. LenovoEMC Personal Cloud. Product web site. http://www.iomegacloud.com/landing_page.php. Accessed 2014-06-12

13. Samsung Tomorrow. Samsung Electronics Official Global Blog. SamsungHomeSync creates connected media experience for the whole family.http://global.samsungtomorrow.com/?p=22348. Accessed 2014-06-12

14. myQNAPcloud Product web site. https://www.myqnapcloud.com/.Accessed 2014-06-12

15. ownCloud. Project web site. http://owncloud.org/. Accessed 2014-06-12

16. Riva O, Yin Q, Juric D, Ucan E, Roscoe T (2011) Policy expressivity in theanzere personal cloud. In: Proceedings of the 2nd ACM Symposium onCloud Computing (SOCC 11). ACM, New York, pp 114

17. Ardissono L, Goy A, Petrone G, Segnan M (2009) From service clouds touser-centric personal clouds. In: Cloud Computing (CLOUD-II), 2009 IEEEInternational Conference On. IEEE, Bangalore, India, pp 18

18. Cunsolo VD, Distefano S, Puliafito A, Scarpa M (2009) Volunteercomputing and desktop cloud: The cloud@home paradigm. In: NetworkComputing and Applications, 2009. NCA 2009. Eighth IEEE InternationalSymposium On. IEEE, Cambridge, MA, USA, pp 134139

19. Andrzejak A, Kondo D, Anderson DP (2010) Exploiting non-dedicatedresources for cloud computing. In: Network Operations and ManagementSymposium (NOMS), 2010 IEEE. IEEE, Osaka, Japan, pp 341348

20. Marinos A, Briscoe G (2009) Community cloud computing. In:Proceedings of the 1st International Conference on Cloud Computing(CloudCom09). Springer, Berlin, Heidelberg, pp 472484

21. Barraca JP, Matos A, Aguiar RL (2011) User centric community clouds.Wireless Personal Commun 58(1):3148

22. Ning W, De X, Baomin X (2010) Collaborative integration andmanagement of community information in the cloud. In: E-Business andE-Government (ICEE), 2010 International Conference On. IEEE,Guangzhou, China, pp 14061409

23. Chard K, Caton S, Rana O, Bubendorfer K (2010) Social cloud: Cloudcomputing in social networks. In: Cloud Computing (CLOUD), 2010 IEEE3rd International Conference On. IEEE, Miami, Florida, USA, pp 99106

24. Kannan S, Gavrilovska A, Schwan K (2011) Cloud4home enhancing dataservices with @home clouds. In: Distributed Computing Systems (ICDCS),2011 31st International Conference On. IEEE, Minneapolis, Minnesota,USA, pp 539548

25. NVIDIA CUDA Parallel Programming and Computing Platform.http://www.nvidia.com/object/cuda_home_new.html. Accessed2014-06-12

26. Khronos Group. OpenCL - The open standard for parallel programming ofheterogeneous systems. http://www.khronos.org/opencl/. Accessed2014-06-12

27. Amazon Web Services Homepage. Announcing Cluster GPU Instances forAmazon EC2. http://aws.amazon.com/about-aws/whats-new/2010/11/15/announcing-cluster-gpu-instances-for-amazon-ec2/. Accessed2014-06-12

28. Brutlag JD, Hutchinson H, Stone M (2008) User preference and searchengine latency. In: JSM Proceedings, Qualitiy and Productivity ResearchSection. IEEE, Alexandria, VA, USA

29. IETF Zeroconf Working Group homepage. http://www.zeroconf.org/.Accessed 2014-06-12

30. Apple Bonjour support homepage. http://www.apple.com/support/bonjour/. Accessed 2014-06-12

31. Avahi project web site. http://www.avahi.org/. Accessed 2014-05-1032. Open Cloud Computing Interface. Project web site. http://www.occi-wg.

org/. Accessed 2014-06-1233. Open Grid Forum. Project web site. http://www.ogf.org/. Accessed

2014-06-1234. Metsch T, Edmonds A, Nyrn R (2010) Open cloud computing

Interface-Core. In: Open Grid Forum, OCCI-WG, Specification Document.http://forge.gridforum.org/sf/go/doc16161, Online publication

35. Metsch T, Edmonds A (2010) Open cloud computing InterfaceInfrastructure. http://ogfweb.pti.iu.edu/Public_Comment_Docs/Documents/2010-12/ogf_draft_occi_infrastructure.pdf, Onlinepublication, Accessed 2012-11-08

36. Open Cloud Computing Interface. OCCI implementations. http://www.occi-wg.org/community/implementations/. Accessed 2014-06-12

37. HyperSQL database. Project web site. http://hsqldb.org. Accessed2014-06-12

38. Apache Lucene. Project web site. http://lucene.apache.org/core/.Accessed 2014-06-12

39. elasticsearch. Project web site. http://www.elasticsearch.org/. Accessed2014-06-12

doi:10.1186/s13677-014-0010-8Cite this article as:Mosch et al.: User-controlled resource management infederated clouds. Journal of Cloud Computing: Advances, Systems andApplications 2014 3:10.

http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdfhttp://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdfhttp://flexcloud.eu/http://www.akitio.com/information-center/personal-cloud-serverhttp://www.akitio.com/information-center/personal-cloud-serverhttp://www.dlink.com/de/de/home-solutions/mydlink/what-is-mydlinkhttp://www.dlink.com/de/de/home-solutions/mydlink/what-is-mydlinkhttp://www.synology.com/dsm/home_file_sharing_cloud_station.phphttp://www.synology.com/dsm/home_file_sharing_cloud_station.phphttp://www.iomegacloud.com/landing_page.phphttp://www.iomegacloud.com/landing_page.phphttp://global.samsungtomorrow.com/?p=22348https://www.myqnapcloud.com/http://owncloud.org/http://www.nvidia.com/object/cuda_home_new.htmlhttp://www.khronos.org/opencl/http://aws.amazon.com/about-aws/whats-new/2010/11/15/announcing-cluster-gpu-instances-for-amazon-ec2/http://aws.amazon.com/about-aws/whats-new/2010/11/15/announcing-cluster-gpu-instances-for-amazon-ec2/http://www.zeroconf.org/http://www.apple.com/support/bonjour/http://www.apple.com/support/bonjour/http://www.avahi.org/http://www.occi-wg.org/http://www.occi-wg.org/http://www.ogf.org/http://forge.gridforum.org/sf/go/doc16161http://ogfweb.pti.iu.edu/Public_Comment_Docs/Documents/2010-12/ogf_draft_occi_infrastructure.pdfhttp://ogfweb.pti.iu.edu/Public_Comment_Docs/Documents/2010-12/ogf_draft_occi_infrastructure.pdfhttp://www.occi-wg.org/community/implementations/http://www.occi-wg.org/community/implementations/http://hsqldb.orghttp://lucene.apache.org/core/http://www.elasticsearch.org/

AbstractKeywords

IntroductionThe -Cloud approachContributions and outline

Drawbacks of existing cloud resource management solutionsRequirements analysisDevice coordination requirementsService coordination requirementsService description format requirementsService directory requirements

Designing the resource managerDevice coordinationService coordinationService descriptionService directory

Overall architecture

Prototype implementationDevice directoryService descriptionService directory

Evaluation and discussionMethodologyResultsResponse timeIndex and database sizeCPU load and memory consumption

Summary

ConclusionFuture workCompeting interestsAuthor's contributionsAcknowledgementsReferences

/ColorImageDict > /JPEG2000ColorACSImageDict > /JPEG2000ColorImageDict > /AntiAliasGrayImages false /CropGrayImages true /GrayImageMinResolution 300 /GrayImageMinResolutionPolicy /OK /DownsampleGrayImages true /GrayImageDownsampleType /Bicubic /GrayImageResolution 300 /GrayImageDepth -1 /GrayImageMinDownsampleDepth 2 /GrayImageDownsampleThreshold 1.50000 /EncodeGrayImages true /GrayImageFilter /DCTEncode /AutoFilterGrayImages true /GrayImageAutoFilterStrategy /JPEG /GrayACSImageDict > /GrayImageDict > /JPEG2000GrayACSImageDict > /JPEG2000GrayImageDict > /AntiAliasMonoImages false /CropMonoImages true /MonoImageMinResolution 1200 /MonoImageMinResolutionPolicy /OK /DownsampleMonoImages true /MonoImageDownsampleType /Bicubic /MonoImageResolution 1200 /MonoImageDepth -1 /MonoImageDownsampleThreshold 1.50000 /EncodeMonoImages true /MonoImageFilter /CCITTFaxEncode /MonoImageDict > /AllowPSXObjects false /CheckCompliance [ /None ] /PDFX1aCheck false /PDFX3Check false /PDFXCompliantPDFOnly false /PDFXNoTrimBoxError true /PDFXTrimBoxToMediaBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXSetBleedBoxToMediaBox true /PDFXBleedBoxToTrimBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXOutputIntentProfile (None) /PDFXOutputConditionIdentifier () /PDFXOutputCondition () /PDFXRegistryName () /PDFXTrapped /False

/CreateJDFFile false /Description > /Namespace [ (Adobe) (Common) (1.0) ] /OtherNamespaces [ > /FormElements false /GenerateStructure true /IncludeBookmarks false /IncludeHyperlinks false /IncludeInteractive false /IncludeLayers false /IncludeProfiles true /MultimediaHandling /UseObjectSettings /Namespace [ (Adobe) (CreativeSuite) (2.0) ] /PDFXOutputIntentProfileSelector /NA /PreserveEditing true /UntaggedCMYKHandling /LeaveUntagged /UntaggedRGBHandling /LeaveUntagged /UseDocumentBleed false >> ]>> setdistillerparams> setpagedevice