Web of Things Application Architecture
Upcoming SlideShare
Loading in...5
×
 

Web of Things Application Architecture

on

  • 29,187 views

PhD defense at ETH Zurich discussing the required layers in order for the Web of Things to become a reality.

PhD defense at ETH Zurich discussing the required layers in order for the Web of Things to become a reality.

Statistics

Views

Total Views
29,187
Views on SlideShare
6,956
Embed Views
22,231

Actions

Likes
19
Downloads
558
Comments
0

29 Embeds 22,231

http://www.webofthings.org 13204
http://dom.guinard.org 3642
http://www.webofthings.com 3417
http://lainternetdelascosas.com 1016
http://feeds.feedburner.com 373
http://flavors.me 185
http://internetdelascosas.wordpress.com 120
http://postscapes.com 103
http://webofthings.org 54
http://translate.googleusercontent.com 27
http://abtasty.com 20
http://paper.li 18
http://www.newsblur.com 11
http://www.informyzer.com 9
http://webcache.googleusercontent.com 9
http://domguinard.flavors.me 4
http://elcobre.es 3
http://www.webofthings.com HTTP 2
http://webofthings.com 2
http://131.253.14.66 2
http://207.46.192.232 2
http://131.253.14.98 1
http://shrix.tumblr.com 1
https://www.google.co.uk 1
http://twbiserver.got.volvo.net 1
https://twimg0-a.akamaihd.net 1
http://honyaku.yahoofs.jp 1
http://beta.cur8r.com 1
http://www.inoreader.com 1
More...

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Currentdevelopments in embeddedsystems in domainssuch as home appliances, sensor net, or simple everydayobjectbeingtaggedwith RFID:Show thatthey are gettingincreasinglysmarter and connectedwhichlead to a very large ecosystem of smart thingsLet us think of an electronic article surveillance system in a store thatwouldleveragethiseco-system: tag objectswith RFID trigger the RFID readerswith a proximitysensor trigger the security camera if somethingwasstolenbroadcast the information to the staff on their mobile phones
  • This leads to a problemresearched by many, showing:ToomuchprotocolsheterogeneityExpensive and time-consumingexpertknowledgeRequirements for application layer for the IoT
  • Web:Set of relatively simple and open standards (e.g., HTTP, HTML, etc.).Broad-pool of developers.Well understood by users.Best-effort (efficiency, scalability, etc.).From Web sites to Web APIs.Ubiquitous availability (desktop, mobile, etc.).Contribution: We propose a Web of Things Application Architecture:Enablesparticipatory application development:Easier for specialistsCloser to Web developers, end-users
  • Four layers but: Not OSI:layers are flexible, eacheases a little more building applications: from Embedded Syst. Dev to End-UsersContribution: LayersBuilding blocks: each block is a Web APIApplications testingthese blocks
  • Resource Tree:functionality of the sun spot identified by resolvableURIsNot bound to one representation. We use HTML for browsability, JSON for mashups, HTTP has a content-negotiationmechanism for selecting the right representation.GET on temperature => retrieves the representation of the tempsensorPUT on LED => changes the state of the LED (on/off)
  • One of ourcore contributionsFor smart thingsthat do not speak Internet or Web protocolswe propose a lightweight software frameworkthatcanbedeployed on computers at the edge of the network (e.g., NAS, wifi routers, etc.):Device Drivers: encapsulate the proprietary or low-levelprotocolsCore Services: are used by drivers to maptheirfunctionality to a Web APIPluggable Services: services implementing cross-cuttingconcerns (seenextlayers)Maybeaddstuff about Web Sockets
  • Withthis layer wewant to achievetwothings:MakethingsfindableusingsearchenginesAllow the semi-automaticintegrationintomashuptoolsGuinard, D., Trifa, V., Mattern, F., & Wilde, E. (2011). From the Internet of Things to the Web of Things: Resource-oriented Architecture and Best Practices. In D. Uckelmann, M. Harrison, & F. Michahelles (Eds.), Architecting the Internet of Things (pp. 97-129). Berlin, Heidelberg: Springer Berlin Heidelberg. Retrieved from http://www.springerlink.com/content/p314x13322qnw276
  • SAC: Manages Access to Smart ThingsThrough Social NetworksAnd offers an API for clients or client applicationsRequirements (details):Security: prevent attackers from gaining accessEase of use: significantly influences adoption [Ion2010]Reflecting existing trust modelsInteroperable: Web protocols, prevent user lock-inIntegrated Advertisement
  • Smart things are securedbased on HTTP Basic AccessAuthentication or HTTP DigestAuthenticationAuthenticationthroughOauthUsing the social network API (OpenSocial if supported, otherwise social network proprietary API)
  • List of resources (i.e., services) thatcanbesharedisautomaticallygenerated by crawling (see sharing layer)
  • Manualmashupdev:Wetake a device on whichappscanbedeveloped by domainspecialists and, using the otherlayers, bringit to Web developers
  • We provide a Web page that loads the real-world data into global variables, developers then just have to create widgets by combining this data with services on the Web.
  • Bringingdevelopment as close as possible to endusersWecreated a frameworkthatallows the creation of dedicatedmashup editorsi.e., Web toolthat let usersbuildmashupssimply by visuallycomposingwidgetsThanks to the otherlayerseachwidgetisreduced to an HTTP call and canevenbeautomaticallygenerated.This is the EAS mashup.
  • Criticism of the Web for embedded devices: too heavy.Weevaluatedbothapproaches (embedded HTTP & Smart Gateway mediated):Ok for sub-second use-cases
  • RTTcanbeimproved by caching the authentication of users (not theirtokens) however, thisis a tradeoffbetweensecurity and efficiency.http://vswot.inf.ethz.ch:8091/gateways/vswot.inf.ethz.ch:8081/resources/sunspots/Spot1/sensors/light
  • We wanted to asses whether the Web approach was making development easier
  • Web of Things architecture:Blueprints to bring IoT application development closer to non-specialists thanks to the Web:Performances are acceptable for sub-second use-casesUnveils integration possibilities (browser integration, social networks, Web scripting languages, mashups, etc.)Fosters open, participatory innovation to physicalmashupsEvaluated and prototyped in two domains:Wireless Sensor Networks & RFIDDeliverables: ~20 co-authored publications, 5 frameworks (3 open-source), 10 applications (1 open-source)
  • Real-time <10ms response rangeIf Internet standards are adaptedwecouldalso serve more use-cases throughsuch an architectureFirst sensethrough the open-sourcing of ourframeworks, more isneeded
  • Four layers but: Not OSI:layers are flexible, eacheases a little more building applications: from Embedded Syst. Dev to End-UsersContribution: LayersBuilding blocks: each block is a Web APIApplications testingthese blocks
  • Criticism of the Web for embedded devices: too heavy.Weevaluatedbothapproaches (embedded HTTP & Smart Gateway mediated): Ok for most types of apps (<1 second)Sync-based Smart Gateway: muchbetter:
  • If theyimplement the Accessibility layer smart thingscanbediscovered by crawling.
  • Pseudo code for the crawling:crawl(Link currentLink) { new Resource() r;r.setUri = currentLink.getURI();r.setShortDescription = currentLink.text();r.setLongDescription = currentLink.invokeVerb(GET).extractDescriptionFromResults();r.setOperations = currentLink.invokeVerb(OPTIONS).getVerbs();foreach (Format formats: currentFormat) {r.setAcceptedFormats = currentLink.invokeVerb(GET).setAcceptHeader(currentFormat); } if (currentLink.hasNext()) crawl(currentLink.getNext());}
  • Requirements:Security: prevent attackers from gaining accessEase of use: significantly influences adoption [Ion2010]Reflecting existing trust modelsInteroperable: Web protocols, prevent user lock-inIntegrated Advertisement
  • Sharing RFID data through the EPCIS Webadapter
  • ClickScript [Naef2009]: Language created to teach programming to children.Client-side Web technologies (JavaScript + CSS + HTML).Smart Things building-block within a few lines of JavaScript.Added push support (tPusher).
  • Lets end-users create simple rules to optimize their energy consumption:Turn the heating on only when I am driving home and temp < 18 deg.Turn off the lights when sun light is strong enough.
  • REST appears to be more adapted to foster a participatory Web of Thingswere application developmentisbrought to non-specialists

Web of Things Application Architecture Web of Things Application Architecture Presentation Transcript

  • A Web of Things Application Architecture -Integrating the Real-World into the WebDominique GuinardPh.D. Defense, ETH Zurich
  • MotivationWhy should we bring the Web and real-world devices together? [flickr.com/photos/moragcasey]
  • An Increasing Number of Connected Smart Things… A very large ecosystem of smart things, complex application development15.08.2011 Dominique Guinard 3
  • Need for a Common Internet of ThingsApplication Architecture Application development with  Hypothesis: The Web smart things: (application archi. of the Internet)  Requires expert knowledge: can be the application  Hardware/software heterogeneity architecture of smart things as  Lack of common application protocols well.  WSN [Mot2011]  Research Question: «How can RFID [Sch2008] the Web be leveraged to ease the development of Internet of Things applications and bring it closer to non-specialists?» [Sch2008] Schmitt, P. Adoption und [Mot2011] Mottola, L., & Picco, G. P. Diffusion neuer Technologien am Programming wireless sensor networks: Beispiel der Radiofrequenz-Identifikation Fundamental concepts and state of the (RFID). PhD Thesis, ETH Zurich. art. ACM Comput. Surv.15.08.2011 Dominique Guinard 4
  • Contributions A Web of Things Application Architecture:  Adapt and leverage protocols, services and tools of the Web ecosystem  Foster a participatory application development:  Easier for specialists  Closer to Web developers (Web languages), tech-savvies (mashups) and end- users (browsers)  Evaluated for WSN and RFID:  Simplifies the development and deployment of applications15.08.2011 Dominique Guinard 5
  • Web of Things Application ArchitectureSimplifying Application Development in the Internet of Things [flickr.com/photos/docman]
  • Web of Things Application Architecture15.08.2011 Dominique Guinard 7
  • Device Accessibility Layer How do we make smart things accessible on the Web? Generic design process[Gui2010] for smart things as Web resources:  REST[Fie2000] and Resource Oriented Architectures[Ric2007] [Fie2000] Fielding, R. (2000). [Ric2007] Richardson, L., & Ruby, S. [Gui2010] Guinard, D., Trifa, V., Wilde, E. Architectural styles and the design of RESTful web services, O’Reilly Media. A Resource Oriented Architecture for the network-based software architectures. Web of Things. IoT 2010 PhD Thesis15.08.2011 Dominique Guinard 8
  • Resource Representation Interface Implementation Design Design Design Strategy http://<DOMAIN>:<PORT>/genericNodes /node1/sensors/temperature GET, DELETE GET GET, PUT http://<DOMAIN>:<PORT>/genericNodes15.08.2011 Dominique Guinard 9
  • Resource Representations Interface Implementation Design Design Design Strategy15.08.2011 Dominique Guinard 10
  • Findability Layer Once smart things are accessible on the Web, how do we enable users to find the right service for their application? Enabling Smart Things to be indexed by search engines (lightweight metadata)[Gui2011] Local lookup and discovery infrastructure [Gui2010a,May2011] [Gui2011] Guinard, D., Trifa, V., Mattern, [Gui2010a] Guinard, D., et al. (2010). [May2011] Mayer, S., Guinard, D. An F., & Wilde, E. From the Internet of Interacting with the SOA-Based Internet Extensible Discovery Service for Smart Things to the Web of Things. Architecting of Things: Discovery, Query, Selection, Things. WoT2011 the Internet of Things (pp. 97-129) and On-Demand Provisioning of Web Services. IEEE Transactions on Services Computing15.08.2011 Dominique Guinard 11
  • Sharing Layer Once smart things are accessible and findable on the Web, how do we share them? Social Web of Things [Gui2010b] [Gui2010b] Guinard, D., Fischer, M., & Trifa, V. Sharing using social networks in a composable web of things. WoT 201015.08.2011 Dominique Guinard 12
  • Social Access Controller (SAC) Existing systems:  Require dedicated access control lists (e.g., HTTP Digest or Basic Authentication) Leverage social graphs of social networks:  Are walled-gardens [Ber2009]  Allow sharing data, not services Social Access Controller as proxy between clients and smart things [Ber2009] Tim Berners-Lee. Twenty years: Looking forward, looking back. WWW 200915.08.2011 Dominique Guinard 13
  • Social Access Controller (SAC)15.08.2011 Dominique Guinard 14
  • Sharing in Friends and Things http://vswot.inf.ethz.ch:8091 /gateways/vswot.inf.ethz.ch:8081 /resources/sunspots/spot1/sensors/temperature15.08.2011 Dominique Guinard 15
  • Composition Layer Once smart things are accessible, findable, shareable on the Web, how do we enable their easy composition by non- specialists, into new applications? Physical Mashups [Gui2010, Gui2010c] [Gui2010] Guinard, D., Trifa, V., Wilde, E. [Guinard2010c] Guinard, D. Mashing up A Resource Oriented Architecture for the your web-enabled home. ICWE 2010 Web of Things. IoT 201015.08.2011 Dominique Guinard 16
  • From Web 2.0 Mashups to Physical Mashups Web 2.0 Mashups:  “Web applications generated by combining […] disparate Web sources […] to create useful new services” [Yu2008]  Ad-hoc applications accessible to a larger public Physical Mashups:  Composite Web applications involving smart things and virtual Web services  Three development approaches[Yu2008] Yu, J., Benatallah, B., Casati,F., & Daniel, F. Understanding MashupDevelopment. IEEE Internet Computing15.08.2011 Dominique Guinard 17
  • Energie Visible: An Energy-Aware Mashup  Developers:  Smart Meters as an RESTful Web API:  Mashup with any language supporting HTTP  Users:  Used by several families around the world (Energie Visible)15.08.2011 Dominique Guinard 18
  • EPC Mashup Dashboard: RFID Business Intelligence  Developers:  RFID Readers & Data in a black-board approach  Wizard-based creation of Widgets  Merging Web data and real-world RFID data  Users:  Simple Web page providing real-time business intelligence  Deployed at the SAP future store15.08.2011 Dominique Guinard 19
  • Electronic Article Surveillance as a Physical Mashup [Gui2010d] Guinard, D., Floerkemeier, C., & Sarma, S. Cloud Computing, REST and Mashups to Simplify RFID Applications, WoT 2011 [Naef2009] Naef, L. ClickScript a visual programming language in the browser. Master Thesis, ETH Zurich15.08.2011 Dominique Guinard 20
  • Selected EvaluationsSmart Gateways, Social Access Control & Developers’ Experiences [flickr.com/photos/myfwc] [flickr.com/photos/docman]
  • Smart Gateway vs Direct Web Integration End-to-end HTTP  Smart Gateway:  7000 (sequential) requests:  7000 (sequential) requests:  Avg.: 205 ms, SD: 127.8 ms  Avg.: 4.2 ms, SD: 3.7 ms  Min.: 96 ms, Max.: 8.5 sec  Min.: 2 ms, Max.: 111 sec15.08.2011 Dominique Guinard 22
  • Using Social Access Control 1000 requests on a Sun SPOT  Through SAC (Facebook), RTT: (Smart Gateway):  Avg.: 218 ms, SD: 24 ms Direct Access:  Min: 204 ms, Max: 830 ms  Avg.: 9 ms, SD: 2 ms  Most of the RTT (140ms) due to  Max.: 40 ms, Min.: 6 ms social network login => caching15.08.2011 Dominique Guinard 23
  • Ease of Use? Assessing the Developers’ Experience  WS-* (WSDL, SOAP, etc.) as one of the most comprehensive alternatives (DPWS, DNLA, etc.)  Performances were compared[Yaz2009] , not ease of use  Study with 69 computer science students  2 applications: 1. Android phone accessing a Sun SPOT featuring a WS-* API 2. Android phone accessing a Sun SPOT featuring a RESTful Web API[Yaz2009] Yazar, D., & Dunkels, A.Efficient application integration in IP-based sensor networks. BuildSys200915.08.2011 Dominique Guinard 24
  • Ease of Learning  RESTful Web API:  70% easy to very easy to learn  63% fast to very fast to learn15.08.2011 Dominique Guinard 25
  • Suitability by Use-Case and Guidelines REST and Web more adapted to foster adoption by non- specialists WS-* more adapted for high QoS/security requirements15.08.2011 Dominique Guinard 26
  • Conclusions, Limitations and OutlookWhat did we contribute? What are the current limitations? [flickr.com/photos/brapke]
  • Contributions & Learnings WoT Application Architecture & evaluation in WSN + RFID  The Web can be leveraged and adapted as a smart thing application architecture  Eases the development & brings it closer to non-specialists  Unveils integration possibilities:  Browser, search engines, social networks, Web languages, mashups, etc.15.08.2011 Dominique Guinard 28
  • Limitations & Outlook Not the best approach for every use-case:  Real-time, high QoS requirements, battery-life Pushing Internet and Web standards forward:  Lower foot-print (6LoWPAN)  Web push (HTML5 WebSockets, etc.)  Metadata for smart things Real-world evaluations:  Larger deployments, industrial trials (IPSO alliance)  Comparisons with other alternatives  Evaluating the mashups with more end-users15.08.2011 Dominique Guinard 29
  • Thanks a lot for your attention  Dominique Guinard  Contact details: www.guinard.org  Blog: www.webofthings.com  Software: www.webofthings.com/projects  Publications www.webofthings.com/publications15.08.2011 Dominique Guinard 30
  • BackupWait! There is a little more…15.08.2011 Dominique Guinard 31
  • Complete Web of Things Application Architecture15.08.2011 Dominique Guinard 32
  • Case-Studies Wireless Sensor Networks:  Tagged Objects:  General Purpose Sensing Platform  RFID global network: (Sun SPOTs)  EPC Network  Smart Metering Platform (Ploggs)15.08.2011 Dominique Guinard 33
  • Web-Enabling Smart Things in 4 Steps Resource  Based on REST [Fiel2000] Design and Resource Oriented Architecture [Rich2007].  Applied it to smart things in Representation [Gui2010]. Design Interface GET, POST, PUT, DELETE, OPTIONS Design Content Negotiation, Status Codes [Fiel2000] Fielding, R. (2000). Architectural styles and the design of network-based software architectures. PhD Thesis Implementation [Gui2010] Guinard, D., Trifa, V., Wilde, E. Strategy A Resource Oriented Architecture for the [Rich2007] Richardson, L., & Ruby, S. Web of Things. IoT 2010 RESTful web services, OʼReillyMedia.15.08.2011 Dominique Guinard 34
  • Resource Representation Interface Implementation Design Design Design Strategy  Identify Resources:  Any component of an application that needs to be used and addressed.  Link resources together15.08.2011 Dominique Guinard 35
  • Resource Representation Interface Implementation Design Design Design Strategy  Smart things should offer different representations:  HTML for browsability  JSON for mashups  XML for interoperability {"resource": {"methods":["GET"], "name":"Temperature", "links":["/feed", "/rules"], "content": [{"description":"Current Temperature", "name":"Current Ambient Temperature", "value":"24.0", "unit": "celsius"}]} }15.08.2011 Dominique Guinard 36
  • Resource Representation Interface Implementation Design Design Design Strategy Leverage content negotiation:  Accept: application/json Use the HTTP Verbs extensively:  GET, PUT, POST, OPTIONS, DELETE  GET /genericNodes/2/sensors/temperature  PUT /genericNodes/2/actuators /led/1 Map status codes:  200 OK, 201 Created, 400 Bad Request, etc. The presented design process can be automated15.08.2011 Dominique Guinard 37
  • Automating the Design Process The design process can be semi- automated through an editor Auto-WoT [May2010a] project:  Generates the RESTful Web API  Wraps it in an OSGi module, loadable as a device driver in a Smart Gateway [May2010a] Simon Mayer, Dominique Guinard, Vlad Trifa Facilitating the Integration and Interaction of Real-World Services for the Web of Things. UrbanIOT 201015.08.2011 Dominique Guinard 38
  • Smart Gateway Mediated Interaction15.08.2011 Dominique Guinard 39
  • Pushing Data From Smart Things15.08.2011 Dominique Guinard 40
  • Pushing From Web Sockets: t-Pusher Service15.08.2011 Dominique Guinard 41
  • Performance Evaluation  7000 (sequential) requests: 1. End-to-end HTTP  Avg.: 205 ms, SD: 127.8 ms  Max.: 8.5 sec (single request)  Min.: 96 ms 2. Syn-based Smart Gateway:  Avg.: 4.2 ms, SD: 3.7 ms  Max.: 111 sec  Min.: 2 ms15.08.2011 Dominique Guinard 42
  • Scalability / Concurrency Evaluation Smart Gateway sync-based approach  Scales better:  Strongly depends on the Web server implementation  Provides more aged data.15.08.2011 Dominique Guinard 43
  • Discovery by Crawlingcrawl(Link currentLink) { new Resource() r;  Thanks to the Accessibility r.setUri = currentLink.getURI(); r.setShortDescription = currentLink.text(); Layer (REST), smart things r.setLongDescription = currentLink.invokeVerb(GET). extractDescriptionFromResults(); can be crawled r.setOperations = currentLink.invokeVerb(OPTIONS). getVerbs();  Shortcomings: foreach (Format formats: currentFormat) {  Rough descriptions (UIs) r.setAcceptedFormats = currentLink.invokeVerb(GET).  Does not enable automated setAcceptHeader(currentFormat); } mashup integration if (currentLink.hasNext()) crawl(currentLink.getNext());}15.08.2011 Dominique Guinard 44
  • Metadata Description: Smart Things Description Model  Description model for: hProduct  Findablility through existing search engines Crawling  Automatic integration into mashups geo hCard hReview  Crawling algorithm gathers the minimal information:  Read URLs  GET & OPTIONS on resource  Content-negociation  Compound of microformats: hProduct, hCard, geo, hReview15.08.2011 Dominique Guinard 45
  • Local Lookup and Discovery Units (LLDUs)15.08.2011 Dominique Guinard 46
  • LLDU Deployment15.08.2011 Dominique Guinard 47
  • Infrastructure Performance Evaluation  LLDU tree:  Depth of 6  11 virtual LLDUs  1 Physical LLDU (LLDU + Smart Gateway)  2 Sun SPOTs  61 virtual services  LLDU on a PC (2.4 GHz, 2 GB of RAM):  10000 keywords queries (“light”)  Avg: 619 ms  Min: 12 ms  Max: 373515.08.2011 Dominique Guinard 48
  • Query Extension Evaluation  17 neutral developers:  Each describes one device and at least two services (based on the STD model)  RFID readers, robots, smart meters, etc.  Search keywords provided by 7 IT people:  No augmentation: 70%  Wikipedia: ~90%  Yahoo Web Search: 95-100%  Optimum: Yahoo with 5-10 added keywords (95%).15.08.2011 Dominique Guinard 49
  • Social Access Controller (SAC) Architecture15.08.2011 Dominique Guinard 50
  • Friends and Things: User Interface15.08.2011 Dominique Guinard 51 / 50
  • Accessing Shared Smart Things: WSN http://vswot.inf.ethz.ch:8091/gateways/vswot.inf.ethz.ch:8081/ resources/sunspots/spot1/sensors/temperature15.08.2011 Dominique Guinard 52
  • Accessing Shared Smart Things: RFID http://vswot.inf.ethz.ch:8091/gateways/vswot.inf.ethz.ch:8080/resources/epcis- webadapter/rest/1/eventquery/result?epc=urn:epc:id:sgtin:181280.*15.08.2011 Dominique Guinard 53
  • From Web 2.0 Mashups to… Web 2.0 Mashups:  “Web applications generated by combining […] disparate Web sources […] to create useful new applications or services” [Yu2008] Composite applications with:  Lightweightness and simplicity  Acessibility to larger public [http://www.housingmaps.com]  Prototypical or opportunistic nature[Yu2008] Yu, J., Benatallah, B., Casati,F., & Daniel, F. Understanding MashupDevelopment. IEEE Internet Computing15.08.2011 Dominique Guinard 54
  • Manual Mashups with Energie Visible15.08.2011 Dominique Guinard 55
  • Adapting a Mashup Editor $.ajax({ url: "http://" + ip + "/sunspots/" + name + "/sensors/temperature", type: "GET", dataType: "json", success: function(result){ var temperature = result.resource.getters[0].value state.outputs.item(0).setValue(temp) component.finishAsync(); } […]}); [http://www.clickscript.ch] [Naef2009] Naef, L. ClickScript a visual programming language in the browser. Master Thesis, ETH Zurich15.08.2011 Dominique Guinard 56
  • Building Mashup Editors: Physical Mashups Framework  Requirements:  Support for event-based mashups  Support for dynamic building-blocks  Support for non-desktop platforms  Support for application specific editors15.08.2011 Dominique Guinard 57
  • Physical Mashup Lab Deployment & Mobile Apps15.08.2011 Dominique Guinard 58
  • Mobile Energy Mashup Editor  Android-based mashup editor for mashable homes  Uses the Physical Mashup Framework RESTful Web API  Findability Layer for automatic building-blocks generation [Guinard2010c] Guinard, D. Mashing up your web-enabled home. ICWE 201015.08.2011 Dominique Guinard 59
  • Mobile Energy Mashup Editor cont’d  Lets end-users create simple rules to optimize their energy consumption:  Turn the heating on only when I am driving home and temp < 18 deg.  Turn off the lights when sun light is strong enough.  Android-based mashup editor.  Uses the Physical Mashup Framework RESTful Web API.  Uses the Findability Layer for automatic building-blocks generation.15.08.2011 Dominique Guinard 60
  • Mobile Energy Mashup Editor cont’d  JSON reflection to generate adapted UIs.15.08.2011 Dominique Guinard 61
  • REST vs WS-*: Guidelines15.08.2011 Dominique Guinard 62