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.
Since we came back from WoT 2010 about a month ago, I’ve been wanting to post a small wrap up about it. So let’s really do it before WoT 2011 takes place
Before WoT
The idea of launching the WoT workshop came from discussion with our Professor Friedemann Mattern and Erik Wilde from UC Berkeley. The main goal of the event was to bring together researchers interested in the Web of Things concepts and bootstrap a scientific community on the topic.
We got a total of 28 papers and 5 demo papers, not bad for a first edition! Our very supportive Program Committee helped us to select 12 papers (about 40% acceptance rate).
We wanted the workshop to be international and thus were glad that the submitted papers came from 15 countries as shown below.
During WoT 2010
The workshop was held at Percom 2010 and attracted about 40 totally motivated people. An number of people also came from the world of industrial research (such as the Sun Lab guys, presenting their great Sensor.Network.
Most of the participants where coming from the Ubicomp/Pervasive world and just two came from the “Web” world.
As one of our goals was to bring the two communities together we definitely see that there is room for improvement on that point (any suggestion? please comment!).
The topics where quite diverse but all discussions really focused on a “Web of Things” being either built using WS-* Webservice (the DPWS folk was well represented) or using REST. The discussions between the two communities were quite constructive and very far from those REST vs WS-* wars.
The workshop definitely did not only focus on those topics but rather started from there and discussed what was missing in those architectures and principles to fully apply them to things. The word cloud below tries to encapsulate the keywords of the presentations and discussions.
As you can see, lot’s of discussions were rotating around missing key features of the current architectures for things. In particular people talked about semantics and discovery of things. Several approaches where proposed. On the one hand-side the WS-* folks presented how DPWS had service discovery mechanisms directly at hand. The REST people explained how microformats (btw, we currently run a little study of Microformats for things to see how Google will register them!) and more generally the semantic Web could push discovery beyond the “discovery by browsing” paradigm of REST for more complex use cases. Sharing through social networks, concentrators such as Pachube or Sensor.Network or the use of a location infrastructure reflected in URLs were also mentioned as a means to better discover relevant smart objects.
The real-time Web was also a hot topic. Thinking about how event-driven protocols could be built and reused (e.g. Twitter, Pubsubhubbub) on the Web to better fit the needs of sensor networks applications.
More network related topics where discussed such as how to solve the mobility of smart objects and the fact that they often connect behind firewalls. Solutions like using reverse HTTP and Yaler where presented. Still in these topics, a number of paper dealt with evaluations of the proposed protocols and architectures (e.g. DPWS, REST, ontologies, etc.) for things. IPv6lowpan also gained momentum during the workshop as a (soon) viable solution to get rid of the Web of Things software gateways bridging non-IP networks with IP networks.
Finally, novel architectures and integration patterns (based on REST or on custom middleware such as SWE) were proposed to create an organized and composable Web of Things.
You’ll find all the papers and most of the presentations on the workshop official Webpage have a look at them, it is definitely part of the material that will influence the future Web of Things!
After WoT
Overall, WoT 2010 was a success, thanks to all the people who participated and made it valuable! Obviously I’m not the most objective person to say that but according to the feedback we got, people definitely enjoyed it and look forward to the next edition. Perhaps the only downside of this first edition was the lack of Web people… we can certainly improve that!
Speaking of which I wanted to get your feedback:
Where (@ what conference?) should WoT 2011 take place? (should it take place?)
Who should drive it?
When should we plan it for?
How do we get more Web people on board?
A few weeks ago I posted about a project we currently work on for sharing web-enabled things using social networks. During WoT 2010 (which I’ll wrap up here soon!) I had the chance to present it and got quite a good feedback.
People where mainly wondering about the scalability of such a system. If an access controller such as SAC was to be implemented for every “thing” how would that scale? We discussed its deployment on platforms such as Google Appengine which are highly scalable. We also talked about distributed versions of SAC.
People also had concerns about the “user-friendliness” of the approach. While using social networks instead of classical Access Control Lists seemed one step towards the right direction people mentioned the importance of being able to share with clusters of people rather than single persons. A feature which is probably going to be supported by most social network APIs sooner or later.
Last but not least we talked about the Social Network Standards. Researchers in the audience all agreed in one voice that OpenSocial was the way forward. Let’s just hope Facebook and Twitter will eventually join…
Anyway, thanks for the good feedback WoT 2010 crowd!
You’ll find the slides below and some more WoT 2010 slides by searching for WoT 2010 on Slideshare.
