[IEEE 2011 IEEE International Conference on Pervasive Computing and Communications Workshops (PerCom Workshops) - Seattle, WA, USA (2011.03.21-2011.03.25)] 2011 IEEE International Conference on Pervasive Computing and Communications Workshops (PERCOM Workshops) - Ubiquitous cloud: Managing service resources for adaptive ubiquitous computing

Download [IEEE 2011 IEEE International Conference on Pervasive Computing and Communications Workshops (PerCom Workshops) - Seattle, WA, USA (2011.03.21-2011.03.25)] 2011 IEEE International Conference on Pervasive Computing and Communications Workshops (PERCOM Workshops) - Ubiquitous cloud: Managing service resources for adaptive ubiquitous computing

Post on 19-Mar-2017

213 views

Category:

Documents

1 download

TRANSCRIPT

<ul><li><p>Ubiquitous Cloud: Managing Service Resources for Adaptive Ubiquitous Computing</p><p>Koichi Egami, Shinsuke Matsumoto and Masahide NakamuraGraduate School of System Informatics, Kobe University</p><p>1-1 Rokkodai-cho, Nada-ku, Kobe, Hyogo 657-8501, JapanEmail: egami@ws.cs.kobe-u.ac.jp, {shinsuke, masa-n}@cs.kobe-u.ac.jp</p><p>AbstractThe adaptive ubiquitous services, which dynami-cally adapt behaviors to requirements and contexts, are one ofthe major challenges in the ubiquitous computing. To facilitatethe management of ubiquitous service resources, this paperpresents a novel platform called ubiquitous cloud, borrowingthe concept of the cloud computing. The ubiquitous cloudsupports various stakeholders to use appropriate ubiquitousobjects in infrastructure, platform and application levels. Wepresent an architecture consisting of four key components:the service resource registry, the adaptive resource finder, thecontext manager and the service concierge. To demonstrate theeffectiveness, we develop a practical adaptive service roomenvironment relocation service in an actual home networksystem, with and without the proposed ubiquitous cloud.</p><p>Keywords-adaptive ubiquitous services, cloud computing,service-oriented architecture, service resource discovery</p><p>I. INTRODUCTION</p><p>Along with the diversification of social needs, ubiquitousservices and applications are required to be more adaptiveto users and surrounding environments. In the ubiquitousand pervasive communities, many different techniques havebeen proposed to achieve the adaptive services including,changing the composition, re-assembling workflows, opti-mizing behaviors, performing AI planning (e.g., [2] [3] [5]).In reality, however, it was quite difficult to implement thesetheories in practical applications, since there was no standardplatform to guarantee the interoperability among ubiquitousresources (devices, sensors, interfaces, etc).</p><p>The Service-Oriented Architecture (SOA) [9][10] has at-tracted great attention firstly in the enterprise system inte-gration. The concept of the SOA is well applied to ubiqui-tous/pervasive environment to achieve the programmatic in-teroperability among heterogeneous and distributed devices.Wrapping proprietary operations and protocols by Webservices provides loose-coupling and platform-independentaccess methods for external software that uses the devices.The adaptive services can be implemented by statically ordynamically composing the existing services based on givenrequirements [4]. Several studies have been reported on theservice orientation of ubiquitous applications (e.g., homenetworks [6][7] and sensor networks [8]).</p><p>As more and more ubiquitous devices become availableas SOA services, the next challenge is how to managesuch service resources efficiently and effectively. Our key</p><p>idea is to borrow the idea of the cloud computing [11][12],regarding everything as a service (XaaS).</p><p>For the various ubiquitous resources deployed in theWeb, different requirements will be expected from differentclients. Expert programmers (or hackers) developing smallcustom applications may just want to use sensors and devicesas they are. Developers and providers of large-scale adaptiveapplications may require more sophisticated environmentor tools, which can dynamically discover necessary serviceresources based on contextual information. End users maywant to use the adaptive applications as tailor-made ser-vices without concerning whatever resources are used. Theabove hierarchy of requirements fits well the structure ofIaaS, PaaS and SaaS in the cloud computing [12].</p><p>Borrowing the concept of the cloud, this paper proposesan architecture of ubiquitous cloud, to manage serviceresources for adaptive ubiquitous applications and services.The key components of the proposed cloud are:</p><p>1) Service Resource Registry: Situated in the IaaSlayer, it provides an infrastructure making ubiquitousresources available as atomic Web services.</p><p>2) Adaptive Resource Finder: Situated in the PaaSlayer, it tries to find optimal service operations forusers and environments, based on given requirementsas well as the current user/environmental contexts.</p><p>3) Context Manager: Situated in the PaaS layer, it gath-ers various contextual information from real world,using the underlying sensor services.</p><p>4) Service Concierge: Situated in the SaaS layer, itrecommends and executes published adaptive appli-cations as tailor-made services for end users.</p><p>The development of the ubiquitous cloud is currentlyunder way. In this paper, we especially discuss the details ofthe service resource registry and the adaptive resource finder.To show the effectiveness, we also conduct an experimentof developing a practical adaptive service with and withoutthe ubiquitous cloud. As a result, it is shown that thedevelopment effort is significantly reduced.</p><p>II. PRELIMINARIES</p><p>A. Service-Oriented Ubiquitous Network</p><p>In this paper, we assume a future ubiquitous network,where every object is deployed as an (atomic) SOA service</p><p>1st IEEE PerCom Workshop on Pervasive Communities and Service Clouds</p><p>978-1-61284-937-9/11/$26.00 2011 IEEE 123</p></li><li><p>(e.g., [6][7][8]). Various types of ubiquitous devices are uni-formly abstracted as platform-independent service resources,defined by standard interface description (e.g., WSDL) andaccess protocols (e.g., REST, SOAP). Typical service re-sources include house-hold appliances (TVs, DVDs, air-conditioners, lights), sensors, cars, user-interfaces (displays,microphones), telephones, PDAs, etc.</p><p>A service resource provides a set of service operationseach of which implements a functional behavior of theresource. Integrating service operations from various re-sources achieves value-added composite services. For in-stance, orchestrating a TV, a DVD, a curtain, lights andspeakers implements a DVD theater service, where a usercan watch movies in a theater-like atmosphere at home. Thecomposition of the service resources can be done staticallyin design time, or dynamically during run-time, dependingon the target applications.</p><p>B. Adaptive Ubiquitous Services</p><p>Within the service-oriented ubiquitous network, we definean adaptive ubiquitous service as a composite service thatcan adapt its behaviors dynamically to users requirementsand varied contexts. A simple example is an adaptive mes-sage delivery service. For a given message and a recipientaddress, the service chooses an appropriate transport of themessage (e.g., chat, e-mail, phone, voice from speakers, TVsubtitles, etc.), according to the status of the recipient. An-other example is a room environment relocation service,which saves an environment status of a room and restoresthe status in another room as a user moves.</p><p>One of the most challenging issues in developing adap-tive services is how to find and use the service resourcesappropriate to the requirements and the contexts. This is aquite different point from the conventional services whereall the service resources are determined statically at designtime. Hence, we aim to support service developers as wellas end users in this respect.</p><p>The goal of this paper is to provide a powerful mecha-nism of service resource management at different levels ofabstractions.</p><p>III. UBIQUITOUS CLOUD</p><p>To achieve the goal, we present the ubiquitous cloud toprovide useful services that manage service resources in theservice-oriented ubiquitous network.</p><p>A. Stakeholders</p><p>We suppose in the future that the service-oriented ubiqui-tous network will be used by various kinds of stakeholders.Therefore, the cloud must be designed so as to correspondto service resource managements at different levels of ab-stractions. For the moment, we assume the following clients:</p><p> Ubiquitous Resource Providers (URP): Peoplewho want to provide own ubiquitous resources in theservice-oriented ubiquitous network.</p><p> Custom Applications Developers (CAD): Peoplewho want to develop their own applications by usingavailable ubiquitous service resources as they are.</p><p> Adaptive Services Developers (ASD): People whowant to develop large-scale adaptive services that dy-namically use service resources based on given require-ments and contexts.</p><p> Adaptive Service Providers (ASP): People who wantto provide adaptive applications as commercial or non-commercial services for the end users.</p><p> End Users (EU): People who want to use the pub-lished adaptive services as tailor-made services.</p><p>B. Architecture</p><p>To satisfy the stakeholders, the proposed ubiquitous cloudadopts a three-layered architecture, where each layer re-spectively corresponds to the IaaS, PaaS and SaaS of theconventional cloud. Figure 1 shows the architecture of theubiquitous cloud.</p><p> Infrastructure Layer: Provides fundamental featuresto make various ubiquitous objects available as serviceresources in the network. The infrastructure layer issupposed to be used by URP and CAD.</p><p> Platform Layer: Provides development platforms tofacilitate development of adaptive ubiquitous services.The platform layer is supposed to be used by CAD aswell as ASD.</p><p> Application/Service Layer: Provides showcaseswhere adaptive services are deployed and provided. TheApplication/Service layer is supposed to be used byASP and EU.</p><p>Within the three-layered architecture, we are currentlydeveloping the following four key components:</p><p>1) Service Resource Registry: Situated in the infrastruc-ture layer, the service resource registry stores meta-data explaining service resources that are registeredby the URPs. It also supports the CADs (as well theASDs) to identify service resources and operationsby various attributes: device class, operation type,physical location, purpose, users, etc.</p><p>2) Adaptive Resource Finder: Situated in the platformlayer, the adaptive resource finder recommends mostappropriate service operations based on given require-ments as well as the current contexts. It understandsthe requirements, and transforms the requirements intoconcrete queries for the service resource registry. Theresults of the queries are filtered by the contextsgathered by the context manager (explained below).Thus, the adaptive resource finder works as a powerfultool for the ASDs and the CADs to implement theadaptive services.</p><p>3) Context Manager: Situated in the platform platformlayer, it gathers various contextual information from</p><p>124</p></li><li><p>SOA</p><p>Service</p><p>SOA</p><p>Service</p><p>SOA</p><p>Service</p><p>SOA</p><p>Service</p><p>SOA</p><p>Service</p><p>1. Search Atomic Service Resources</p><p>2. Register Service Resources</p><p>3. Inquiry Service Resources</p><p>1. Understand Requirements</p><p>2. Recommend Best Resources</p><p>3. Manage History</p><p>1. Gather Resource Information</p><p>2. Interpret Information to Contexts</p><p>3. Provide Context</p><p>1. Receive Users Request</p><p>2. Recommend Adaptive Application</p><p>3. Execute Selected Application</p><p>IaaS</p><p>PaaS</p><p>SaaS</p><p>Application / Service</p><p>Platform</p><p>Infrastructure</p><p>ASP</p><p>EU</p><p>CAD</p><p>ASD</p><p>URP</p><p>CAD</p><p>Ubiquitous Cloud</p><p>Ubiquitous</p><p>Service</p><p>Resources</p><p>SOA</p><p>Service</p><p>SOA</p><p>Service</p><p>SOA</p><p>Service</p><p>SOA</p><p>Service</p><p>SOA</p><p>Service</p><p>1. Search Atomic Service Resources</p><p>2. Register Service Resources</p><p>3. Inquiry Service Resources</p><p>1. Understand Requirements</p><p>2. Recommend Best Resources</p><p>3. Manage History</p><p>1. Gather Resource Information</p><p>2. Interpret Information to Contexts</p><p>3. Provide Context</p><p>1. Receive Users Request</p><p>2. Recommend Adaptive Application</p><p>3. Execute Selected Application</p><p>IaaS</p><p>PaaS</p><p>SaaS</p><p>Application / Service</p><p>Platform</p><p>Infrastructure</p><p>ASP</p><p>EU</p><p>CAD</p><p>ASD</p><p>URP</p><p>CAD</p><p>Ubiquitous Cloud</p><p>Ubiquitous</p><p>Service</p><p>Resources</p><p>Figure 1. Ubiquitous Cloud for Adaptive Ubiquitous Services</p><p>real world, using the underlying sensor services. Thegathered information is interpreted as explicit contextscharacterizing users status, requirements, tastes, envi-ronmental situation. The contexts are extensively usedby the adaptive service applications as well as theadaptive resource finder. Thus, the context managersupports the ASDs and the CADs to obtain contextualinformation easily.</p><p>4) Service Concierge: Situated in the application/servicelayer, the service concierge provides a showcase forthe developed applications and services, which aredeployed by the ASP. It also recommends and executespublished adaptive applications as tailor-made servicesof the EUs. Thus, the EU can use the services withoutconcerning whatever service resources are used. Basedon users request, the behaviors of the services aredynamically determined.</p><p>We should note that the above four are just key com-ponents for the adaptive ubiquitous services, but not thecomplete set for the ubiquitous cloud. The cloud shouldevolve to contain more components, according to applica-tions and purposes. The development of the four componentsis currently under way. Due to limited space, we especiallyfocus on the details of the Service Resource Registry andthe Adaptive Resource Finder in the following sub-sections.</p><p>C. Service Resource Registry</p><p>The Service Resource Registry stores meta-data of serviceresources in the service-oriented ubiquitous network. The</p><p>registry is intended to be used for developers and applica-tions to discover desired service resources and operationsefficiently. As for a similar technology, UDDI (UniversalDescription, Discovery and Integration)) [15] is a well-known service registry for Web services.</p><p>However, we consider it difficult to use UDDI directly toimplement our registry. The reason is that the UDDI mainlyfocuses on business and Web services in the IT world only,whereas our targets are physical ubiquitous objects in thereal world interfacing the IT world.</p><p>In our context, an object is associated with a physicallocation and an explicit owner. An object could be aninterface between the IT and real worlds. An operation of theobject may work as information source from the real worldto the IT world (e.g., sensors), or work as information sink(e.g., appliances, actuators) from the IT to the real.</p><p>Taking these issues into consideration, we have designedand implemented a service registry, called UBI-REGI, forubiquitous service resources. The UBI-REGI is currentlydeployed in an actual home network system, CS27-HNS[7], developed by our research group. Figure 2 depicts anER diagram of the UBI-REGI. A box represents an entity(i.e., table), consisting of an entity name, a primary keyand attributes. We enumerate instances below each entityto support understanding. A line represents a relationshipbetween entities, where + denotes a parent-childrenrelationship, and + denotes a reference relationship.</p><p>In our UBI-REGI, a service resource (i.e., a ubiquitousobject) is explained by a name, a device class, an end-point</p><p>125</p></li><li><p>L001 null homelaboratory, office</p><p>L002 L001 living room, western-style room</p><p>L003 L001 bed roomsleeping roomL004 L002 front of a TV</p><p>LOCATION ParentLocation, LocationWordsLocationID</p><p>SERVICE_RESOURCE ResourceID Class, Endpoint, Location, User, Description</p><p>tv TV http://cs27-hns/tv.wsdl L002 Egami TV in living room</p><p>tempS01 tempSensor http://cs27-hns/tempS01.wsdl L002 Seto temperature sensor in living room</p><p>tempS02 tempSensor http://cs27-hns/tempS02.wsdl L003 Seto temperature sensor in bed room</p><p>ejtrans translation ht...</p></li></ul>

Recommended

View more >