Some of you might remember/have attended our SXSW 2010 workshop. Well we enjoyed giving it so much that we decided to come up with two brand new proposals for this year’s SXSW!
The Real-World as a Web API is our first proposal:
The world of “physical devices” such as home appliances/electronics, real-time city data, RFID-tagged objects, mobile phones, etc. has long been longing for a seamless and universal integration platform. Out of a great number of heavy-and-not-so-great middleware a surprising one is emerging: the Web! In this presentation we would like to show how Web developers might well be the next generation of real-world hackers. We’ll demonstrate how the current developments in Web standards make it one step closer to the real-world. We’ll show how REST and the light IPv6 (lowpan) protocols fit really well to control most physical devices. We’ll illustrate how the real-time Web (Web sockets, Pubsubhubbub, Twitter, etc.) makes it easy to sense the world and get physical devices to trigger events. We’ll show how HTML 5, Microformats/data, rich snippets and social networks can help us to search and share the real-world. We will finally show how this Web integration and Javascript toolkits (e.g. JQuery, Sencha touch, etc.) enable us to mashup the world on the Web layer as we wish: from configuring our connected homes to building on top of our real-time cities with our mobile phones. The success of books such as “The Next Internet” or blogs such as Web of Things and theinternetofthings.eu emphasize it: the Internet of Things is coming and Web developers are its most powerful actors!
Next, we have a closer look at the city use-case in:
The public infrastructure of our cities are obscure structures whose workings are not accessible to most citizens. What if every sensor in our cities would have a Web API anyone could access in real-time and mashup? Open and easy to use Web platforms that enable efficient integration, processing, storage, and access to the enormous amount of data digital cities generate are increasingly needed, and we’ll explore the various technologies that are making such solutions possible. Furthermore, we’ll go much more beyond the technical aspects of such a platform to address the more controversial implications of such an Orwellian scenario. Hopefully, this session will provide a forum for the different disciplines involved in the design of future cities to establish a common ground for better interdisciplinary cooperation and understanding in this area.
The idea is to concentrate the first workshop on the technology side and the second a little more on the conceptual side, if you want to be able to attend any of those at SXSW 2011 then please vote here: The Real-World as a Web API or here Web Mashup Platforms for Future Programmable Cities. Or better vote for both 
Votes are closing Friday 27th of August!
We are organizing the First International Workshop on the Urban Internet of Things at the IOT 2010 conference, at the end of this month, and we would love to invite you all to submitting a demo or a paper.
Unlike the WoT2010 which brought together WoT researchers, we emphasize here concrete applications practical solutions that can be built on top of WoT. We particularly welcome real-world deployments that can highlight the plus/minuses of using WoT as infrastructure for a scalable urban-scale data collection and processing.
We would like to bring closer practitioners in the area of smart cities (industries that build the various components of smart cities such as infrastructure, sensor, software, middleware, hardware, etc), along with researchers in various fields related to networked objects (that’s why we do this workshop in the context of IOT conference), and with architects/designers/urban planners that are in charge of designing the points of contact between citizens and this invisible (& growing) digital infrastructure.
The outcome would be for participants to get to know the latest trends in research/technology (& each other) and at the same time get practical insights about the challenges in building such scalable (city-wide+) infrastructures to collect, process, share and store huge quantities of real-time data from various urban sources. Pretty much like a combination between twitter and data.gov, but for sensor data which emphasizes open access to real-time data streams from cities (public APIs that anyone can access and code with).
As we wanted to avoid a “classic” mini-conf like workshop to enable active participation, we have been preparing a few surprises that will allow you to get your hands dirty and join the conversations and hands-on sessions with world-class experts in this area. More to follow soon.
Also, we are still looking for sponsors that could cover the travel costs of our keynote speaker, so if you know someone or are interested to sponsor us in exchange of some promotion/visibility, please get in touch with us (info@{guesswhat}.com would do).
Read more on the official call for papers/demos.
The OpenPicus community released a wi-fi module called FlyPort. It is a small device that uses the Microchip PIC24F (256K Flash+16K Ram, 16Mips@32Mhz) and MRF24WB0MA/RM WI-FI certified module. FlyPort runs a wireless Stack (TCP/IP version 5.25 from Microchip) and has a 26 Pin connector for easy prototyping. Applications and libraries are open source and can be freely downloaded from the openpicus website. Programmers have full control of the wi-fi module, thus the Flyport can act as tiny Web server and client that can directly interact with other Web resources directly, without requiring a gateway. Besides, this project has a social aim too, they give away free development kits for students and universities that want to develop their applications on this platform, as long as they want to share the code and results with the community (mail us if you are interested by such a kit, or just write in the comments and we’ll get back to you). According to the project’s founder, Claudio Carnevali, the Flyport will be available soon to a wider public for less than 30 Euros each.
We have seen more and more projects around embedded wi-fi modules, and we believe this direction will have a strong impact in making the Web of Things happen. For a few bucks more, every electric appliance out there could host one such wifi module on-board, and coupled with a Web server on it this. For example, companies such as RedPine, GainSpan, ZeroG Wireless (that has been recently acquired by microchip), or G2 Microsystems are among the key players to watch in this area, and I’m sure that we’ll see a proliferation of Web-enabled appliances in the next years [ thou, smart fridge, will u finally become real?? 
]
Now that wi-fi chips are virtually easy to integrate in appliances, the next important step to make WoT happen is to also offer a free, easy to use high-level programming environment that would allow people to fast prototype Web of Things applications on top of the wi-fi substrate – just like the Arduino did, but on a even higher level. Instead of learning how to read and write signal to digital & analog pins, developers could interact with these devices simply through a RESTful Web API. After a great discussion I had last october with Massimo Banzi (co-inventor of the arduino), the next stage is clearly a wifi version of the Arduino (nothing disclosed about that yet), which would make it straightforward to also run a Web server on it. I can’t wait for the day this will happen.
[Thanks to Claudio Carnevali for providing us this information and we're looking forward to the evolution of the OpenPicus project]
A few days ago I had the chance to participate to the “touch the Web 2010” workshop.
The goals of the workshop were rather similar to the ones of WoT 2010 however, rather than being hosted at a Ubicomp/Pervasive venue, Touch the Web was collocated with ICWE2010, a pure Web engineering conference.
The most surprising fact was probably how close the two communities are getting. Web people are increasingly interested in embedded/physical/sensor computing, and on the other hand, pervasive people are getting more and more convinced that the Web protocols as not so bad after all (take this paper for instance), at least good enough for a good range of applications. Quite a change of mindset compared to a year ago.
One of the good outcomes of the workshop was the fruitful final discussion. Three big challenges seem to emerge: the discovery of things, the real-time things and understanding the needs for Web-enabled things. Three challenges that were also identified as keys at WOT 2010.
Discovery
We need to look at describing things so that they can be both discovered by machines (i.e. network discovery) and their “services” understood by humans (i.e. service discovery). REST is good, REST is great but it’s raw expressiveness is not enough to understand things. By crawling a RESTful API you can find the resources it exposes, by reading the URIs you can get rough “tags” (e.g. /temperature) describing their nature. But this is not enough for users, neither for machines. As an examples, attendees mentioned the need to generate sense-making UIs on the fly or to customize page rendering depending on the thing one discovers. A simple example of this is Google rich snippets where the search engine renders the page results differently if they embed some semantics. What if Google could render search results for things in a way that helps users interacting with them.
Thus, researchers are exploring ways of better describing things directly inspired from the semantic Web. In “A Triple Space-Based Semantic Distributed. Middleware for Internet of Things” the authors suggest using RDF. In the mashup framework we presented an RDFa based solution to be able to integrated newly discovered devices as mashup actors directly. Those solutions however have the drawbacks of being based on well-know syntax but “proprietary semantics”, i.e. they cannot be understood by One alternative we (and others) currently explore is the use of Microformats which enables to use “agreed-upon” lightweight semantics. Their recent fast-pace expansion makes them even more interesting (I should post about our early experiments with things and microformats here soon!).
Real-time Things
Next in line of the important aspects for a WoT was the need for real-time communication patterns. Not ground-breaking, since this topic has been around WoT architectural discussions since the beginning but the workshop made it clear: client server architectures are great for controlling things, but for monitoring we also need things to be able to push data. Of course, we would also like this push pattern to be as Web oriented as possible. On the REST-side People talked about Atom and especially the latest push based mechanism using it, aka PuSH (or pubsubhubbub). On the more WS-* side, speakers talked about using WS-eventing. We also talked about our experiences with WS-eventing in DPWS (a device tailored WS-* stack) and concluded that it was getting better but still quite heavy for many devices and rather hard to get hands on.
Overall it seemed that this space for still open for further exploration. Speaking of which we also presented a paper at the main conference about a light messaging service for things called RMS (Vlad will tell you more about it here soon!)
Understanding the Needs for Web-enabled Things
Last but not least one really tricky question emerged: “why do we do this?” We propose a re-programmable world where everything is created not as a single purpose object but rather as an API ready for opportunistic applications, but do people want that and why?
Most of the people there believed they do and for various reasons ranging from sustainability (objects have a second life thanks to involving them in new use cases), to customization (things are often not quite the way we want them to be) and satisfaction of DIY (Do It Yourself).
However, raising this question is key and depicted the strong need for better understanding the “mashup space” from an end-user point of view. What would people like to mash in their homes, cities and offices?
As in our project we needed a (quickly setup, reliable, and flexible) backend system to store sensor data, I played around with CouchDB as I wanted to explore a RESTful data store. As a matter of fact, the version 1.0 was released just a few minutes before I installed it. First impression, wow. Sleek, pretty fast, damn easy to use, flexible as any software should be (not the conventional click and run install, but damn well documented installation). I have to admit I’m impressed by the quality of this release, just as much as by the documentation.
I think this is the best option out there to store relatively low-frequency changing data, such as device metadata, information about locations, etc, but I really wonder how it performs for high-frequency data, such as sensor samples. Considering that it is a document store (for JSON data for example), I wondering how it handles the storage of thousands of incoming “documents” per second. This question is certainly worth exploring and I will hopefully be able to share some insights on this question soon.
In the meanwhile, we are looking forward to hear about your experiences with Web-oriented datastores.
After the last draft released in december, the COAP folks just released a few days ago a more refined version of the COAP draft, with additional thoughts on coap-http mapping, RESTful verbs for constrained environments, and pub/sub notifications, and more.
Abstract
This document specifies the Constrained Application Protocol (CoAP), a specialized RESTful transfer protocol for use with constrained networks and nodes for machine-to-machine applications such as smart energy and building automation. These constrained nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while networks such as 6LoWPAN often have high packet error rates and a typical throughput of 10s of kbit/s. CoAP provides the REST Method/ Response interaction model between application end-points, supports built-in resource discovery, and includes key web concepts such as URIs and content-types. CoAP easily translates to HTTP for integration with the web while meeting specialized requirements such as multicast support, very low overhead and simplicity for constrained environments.
Definitely worth looking at it and try to reuse as much as possible from there in your designs. I’ll be analyzing it soon and give my thoughts on it later.
I gave a few thoughts recently about what the iPad (& iPhone) represent for the WoT.
NIWEA
As our friend Hannes Gassert awesomely summarized it recently, NIWEA (Native Interoperable Web Applications) is the sweetest method to build interactive applications for all things mobile, plus NIWEA feels like it was made for the Web of Things. In a nutshell, NIWEA are simple Web applications (developed only with HMTL/CSS/Javascript) designed to look & feel like a “real” (native) mobile application. This not only provides a great environment to develop easily apps for the iPhone/Pad, Android, Blackberry & co, but in particular it is the perfect platform to fast prototype various interactive applications for the WoT.
What it means for developers is that one doesn’t need to learn cocoa & co. and similar weird & proprietary languages for each target platform anymore. It takes time & money to develop an iPhone app (thus the designers’ nightmare when the client says “me too want iPhone app”). As our colleague Erik Wilde mentioned, many apps in the Apple Store could be implemented as Web apps directly (games are a different story and might need to be native for performance reasons). Besides, HTML5 seems to be a pretty versatile, lightweight, and powerful alternative to Flash, and full HTML5 support on future mobile browsers would be the perfect trick against the lack of support for flash in the iPhone (not everyone seemed to agree with the end of flash though, maybe now things have changed 2 years later…).
There’s been a significant move towards more and more simple Web apps directly for mobiles (especially as mobile internet has pretty much become a commodity), and what we see is only the beginning. Simply look at the tremendous progress in Javascript recently: more and more server-side javascript engines, tons of libraries for animations, pretty plotting & vector graphics, etc. Additionally, with all the noise around Real-time Web, highly responsive event-driven Web applications can be developed, especially with the Web Sockets in HTML5, which is much cleaner than Comet, therefore paving the way for a new generation of versatile and mashable-by-design Web content distribution platforms.
Beautiful Interfaces
There is a lot going especially around sleek framework for building interactive and visually appealing UI for mobile devices, among which jQtouch, iui, or Sencha (pretty much everything about this was said by Jonathan Stark at our favourite sxsw’s presentation).
Sencha Touch Introduction. “Sencha Touch allows your web apps to look and feel like native apps. Beautiful user interface components and rich data management, all powered by the latest HTML5 and CSS3 web standards and ready for Android and Apple iOS devices. Keep them web-based or wrap them for distribution on mobile app stores.“
Caching & the N of NIWEA (native)
Using Web apps for mobile device might give the impression that the mobile *must* have Web connectivity at all times, which obviously wouldn’t be that practical. The simplest solution to have stand-alone (offline) Web apps is to use PhoneGap (PG) or Titanium which are the first steps towards NIWEA.
PhoneGap is described on the original site as:
An open source development framework for building cross-platform mobile apps. Build apps in HTML and JavaScript and still take advantage of core features in iPhone/iTouch, iPad, Google Android, Palm, Symbian and Blackberry SDKs.
An interesting alternative is to leverage the caching features of HTML/HTTP, so you can explicitly specify what data can be cached locally on a devices and for how long. But there’s a long road ahead towards a common definition (& rigorous/uniform implementation on all browsers). This is definitely an area that deserves through exploration, in particular for how to optimize Web apps rendering and sensor integration for various classes of devices.
iPad is more than just a big iPod
An essential virtue of the iPad was to open our eyes towards what it means beyond just an iPhone with a bigger screen, especially in terms of HCI. As explained by Matt Jones, the novel types of multi-users/-touch interactions enabled by such a larger display offers a fresh perspective for devices, an interactive surface you can share and use with others. Another excellent example is the great iPad radios (sorry, in german), an intriguing Web radio that augments the listening experience with pictures of the singer, and has been developed by our friends at liip (check this awesome “behind-the-curtains” overview of radios).
If you think of the Chumby as a great platform for interactive information display, then NIWEA is Chumby on steroids. Not only because it runs on many more platforms, but especially because the development life-cycle of NIWEA apps is so much shorter. And trust me, there are many Web developers out there waiting eagerly [for NIWEA frameworks] to put their talent and build great Web apps for pervasive screens.
Looking at the Mag+ concept video above offers a great glimpse into the future of media. In this gorgeous example, a digital surface such as the iPad offers countless new ways to distribute and interact with information, while gaining back the clean and aesthetically pleasing features of print media – the tangible experience. In our world overloaded with information, subtle, appealing, and efficient interfaces are required to interact with all types of media, and a flexible solution accessible to most is needed to maximize its utility.
An iPhone is useful only when you use it, else it’s just there, doing nothing. Because of its form factor, an iPad can be useful even when not used: while you leave it on a desk to charge, it can show stuff to you. The idea of ambient information display is certainly not new, but the iPad just reminds us how we (as designers) barely scratched the surface of all the interaction possibilities hidden behind such a simple (& falsely considered non-disruptive) gadget. What is needed now, is an elaborate, ease-to-use, and efficient framework for building flexible UI with support for smooth tangible interactions of all sorts (multi-touch, sensors, GPS, etc) that can run on a various classes of devices. Such a framework would offer a uniform, high-level, and transparent API that can be used directly from Javascript by people without deep technical expertise, thus enable them to explore the realm of possibilities offered by such displays. This would allow to easily (& cross-platform”ily”) leverage a common set of interactions seamlessly in various NIWEA apps, yet could be still optimized and suited for the hardware platform under consideration.
More to follow soon!
Coming back from Jazoon, a conference that some people see as the European version of Java One. Since this conference is for me a nice concentrate of what’s coming in the Java/OO/Business software world, I wanted to report a little on what I’ve seen there and what this implies/offers in a Web of Things context.
Let’s be modular
As last year, modularity was a BIG keyword. The Java community has acknowledged the success of OSGi and is looking for a somewhat closer integration of these concepts. The Language Support for Modular Programming (JSR 294) will be part of Java 7 and will pave the way towards truly re-usable software components. In the WoT community and in our personal projects here at ETH and SAP research, we started using OSGi a little while ago. The physical world is definitely not homogeneous in terms of protocols, thus the need to create device adapters or drivers, understanding a particular device and providing its functionality as a Web API. OSGi helps there as it enables us to package these drivers and inject them, at run-time, on different platforms such as “smart gateways”.
But using OSGi also complexifies the whole developement cyle and thus a seamless integration to Java of the modularity concepts might help simplifying it! Wait and see…
REST rules
REST ohhhh REST core of the Web of Things! REST was already pretty strongly represented at Jazoon last year but it now seems to have gone beyond the hype and is in the process of being “tool-supported” in lots of ways in the serious world of Java Enterprise. The most prevalent example of this is the number of Java frameworks offering to help you implementing your RESTful API both on the server and client sides.
When we began our exploration of REST we basically had the choice between RESTlet and …. RESTlet (in the Java world). To me RESTlet has always been a great tool with a great community however, as a developer with Java Enterprise background I always felt not totally at ease with the level of abstraction used by RESTlet (which are really close toFielding’s thesis) and with the relative lack of tight integration with the enterprise tool-box such as JAXB.
The JAX-RS standard changed the deal. It offers abstraction levels which are more familiary to the Java developer and its implementations a tight integration with the Java enterprise tools (JAXB) and techniques (annotations, etc.).
Two implementations of JAX-RS were dominating at Jazoon, Jersey and RESTeasy. Jersey is the reference implementation from Sun (ohhhh sorry Oracle). We’ve been using it in two of our latest projects (that I shall present here soon) and I must say and really really like it. It was presented in several talks but I especially liked this one.
I can only advise you to have a look at Jersey and especially it’s integration to Grizzly, a embedded Web server to follow being only because of its very fast integration of bleeding edge technologies (e.g. Comet) and scalability!
The second framework I had the chance to discover was RESTeasy, a full implementation of JAX-RS as well. I did not have the chance to test RESTeasy yet but I was impressed by the presentation. I especially liked its out of the box support for lots of representations (e.g. RSS, XML, ATOM, JSON, YAML, etc.) and its out of the box support for caching, which is extremely valuable in a WoT.
One of the big problems Java WoT developers will now face is choosing the right framework because these are just three amongst the many poping up every month, the graph below is a hype-meter of the four major REST frameworks for Java:
It was created by a colleague at SAP who also made a great benchmarking of these frameworks (and others). I should soon be able to publish it here…
[to be continued]…
Dear readers,
A few days ago we missed being listed here because our feed was ill (a weird, non ASCII char appeared in one of the posts)!
I gave it some steroids and while at it moved it to an Atom feed. For a RESTifarian community as such as ours, it was somewhat weird to actually support RSS and not Atom and its great, RESTful, AtomPub protocol.
Now, since I moved the default Atom, subscribed members might have some problems, many (only?) in the case they use a bad feed client.
Thus if you suddenly are not able to see the webofthings.com feed anymore (then you probably won’t read this message, hem) you might want to register to this, old-fashioned, RSS 2 feed, or get a proper reader.
Plus, you shall also comment this post to tell us how unhappy you are with this move to Atom as a default.
Yes, let’s make it political
We’re happy to announce that our friends at Oberon Microsystems have released the first open version of yaler (reverse of relay). The have made an excellent impression at our WoT2010 workshop by showing a demo of an essential building block for building an infrastructure for the Web of Things. In two words it’s a server to which embedded devices can initiate an HTTP connection, which will be kept open. Using the reversehttp protocol, notifications can be send anytime from the server to any device connected to yaler, even when behind a firewall or NAT.
From to the official website:
A few lines of code make your embedded or mobile device accessible, no matter if it’s behind a firewall, a NAT or a mobile network gateway. Publishing your web service through the Yaler REST API requires just a TCP Socket and some basic HTTP. On the client side a standard Web browser is all it takes to remotely monitor and control your device.
Download yaler with hg clone http://hg.yaler.org/yaler or download it as a ZIP file. Definitely worth a try! We’re looking forward to what they’ll come up with next.
