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!

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.

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]

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?

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.

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.

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.

Mag+ from Bonnier on Vimeo.

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!

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]…

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.

Thanks to you all for coming. Thanks for your feedbacks Let’s continue the discussion here and on Twitter #webofthings.

You’ll find the slides below and the doggy bag here.

You can find a full recording (about 1.5 hours) of the lecture here, but you’ll need to install the plug-in to watch it (sorry about that!).

Alternatively you can find the slides below:

The foreword is written by Vint Cerf. The book will be available in June 2010, but is already available for preorder from amazon. This is great news and very likely a solid reference for future research direction for the Web of Things, and more generally to extending the internet to smart devices (& written by – could I say – the inventor of IP-enabled sensor nets). In my wish list (& my birthday is soon, so you know what to offer me).

What is COAP I hear you saying? From the draft:

The use of web services on the Internet has become ubiquitous in most applications, and depends on the basic REST architecture of the web. The proposed Constrained RESTful Environments (CoRE) working group aims at extending the REST architecture to a suitable form for the most constrained nodes (e.g. 8-bit microcontrollers with limited RAM and ROM) and networks (e.g. 6LoWPAN). One of the main goals of CoRE is to design a generic RESTful protocol for the special requirements of this constrained environment, especially considering energy and building automation applications. The result of this work should be a Constrained Application Protocol (CoAP) which easily traslates to HTTP for integration with the web while meeting specialized requirements such as multicast support, very low overhead and simplicity.

I can’t wait to read it, as it’s definitely what we’ve been pushing since we started WoT: show that REST is indeed a viable protocol for constrained devices. We’re glad to see this great milestone rolling out, and we’re glad we’re here to make WoT a reality.Next step: turn it into a RFC! Maybe now, our papers will finally be better understood and not rejected on the basis “REST is not good for sensor networks”. Yay!
Oh, our WoT team wishes you all a Merry Christmas and a fantastic 2010! Thanks folks for all your support, encouragements, comments and emails, and we’re confident in saying that 2010 will be the WoT year! Keep up the good work, and looking forward for even more fruitful collaborations with you!!!

Looking forward to see how this will develop in the future, and feel free to share in the comments related projects you know about!

As a recap, Google Trends only shows trends for search terms (or combinations of terms) when the volume of single queries becomes interesting enough (i.e. big enough).

Note that, of course, the trend for the “Web of Things” is not as big yet as the one from his mother “Internet of Thing”, but it is growing (IoT is in blue, WoT in red)

This means that the popularity around WoT is growing and so is the hype. Let’s just makes sure it’s not only a hype and that it also roots on some solid ground that will, one day, make the world of “real things” truly part of the beautiful World Wide Web.

For that we need to do that thing Dilbert calls: “work” (thanks to Vlad for that one):

We created a page to host the application, you’ll find the latest version and additional info there.

Note that it currently only works with the Bluetooth Ploggs and on Windows (XP or later).

The bundle you download there basically contains two applications. First is contains a Web of Things Gateway for the Ploggs (written in C++) which is discovering the Ploggs and making them available through a RESTful interface. Then, it contains a Web UI and datastore based on the great Google Web Toolkit and on the wonderful RESTlet.

The bundle contains the binaries but not the source code. If you are interested in getting the source code please contact us.

We hope you’ll enjoy the software! Note that it is provided “as is” without support. However, you are very welcome to use this blog entry to post your comments, bugs reports or feature requests.

Java Card refers to a technology that allows small Java-based applications (applets) to be run securely on smart cards and similar small memory footprint devices. Java Card is the tiniest of Java targeted for embedded devices. Java Card gives the user ability to program the device and make them application specific. It is widely used in SIM cards (used in GSM mobile phones) and ATM cards. The first Java Card was introduced in 1996 by Schlumberger‘s card division which later merged with Gemplus to form Gemalto. Java Card products are based on the Java Card Platform specifications developed by Sun Microsystems. Many Java card products also rely on the GlobalPlatform specifications for the secure management of applications on the card (download, installation, personalization, deletion).

Here are some features of it (text stolen from here):

• JDK6 Compatible VM: Except for floats, it support class file version 50.
• Full Java Language support: Java Card 2 has restrictions on the language itself. But JC3 has no limits. You can use all language features like annotations, enhanced for-loops etc… (except floating point)
• Rich API: This is mixture of CLDC, GCF, Servlet, JavaCard2 API, Sockets, Threads, Transactions …
• Three application models and two library models, which makes it possible to have virtually any kind of secure application on JC3: o Servlets, extended-Applets, Classic-Applets o Extension-Library and Classic-Library
• Servlet Container with Servlet 2.5 support.
• HTTP and HTTPS interface: No need for special client programming. Use any web client to reach JC3.
• Still tiny(!!):24K RAM, 128K EEPROM, 512K ROM with a 32 bit processor
• It is not just “Card” any more: With the newly added USB interface this technology can go beyond Smart Cards into devices like secure USB tokens, Secure Personal Databases, Embedded Servers, WebDAV compliant thumb drives and more.

The hot part is that smart cards support directly HTTP/HTTPS. This means it can be part of WoT and support natively Web-based communication (HTML/SOAP/REST), so it could be very nice to see new applications that could be built with it. Any experience on your side with that?

However it seems like the REST-* initiative is also generating a lot of unhappy people amongst the RESTians. One of the reason is that they fear the REST-* initiative being a generated WS-* initiative (which is pretty much the case, JBOSS is an Enterprise Server after all, not a Web Server…) will end up with lessons like: “look guys, we did great stuff in the WS-* world now let’s apply what we know to the REST world”.
Fundamentally this would of course be wrong. If the initiative really takes off (which I quite doubt looking at the virulent feedbacks) then it is a great opportunity to rethink the WS-* integration patterns and not re-do what was done for WS-* in REST.

Essentially the first goal of such an organization should be (and is probably going to be, let’s hope) to educate people on the RESTful philosophy. Because it is definitely not trivial to entirely master (while trivial to use) and takes a while to fully understand. It probably took me over a year to go from “REST is just about URLs and Verbs (PUT, POST, etc.)” to “REST is really an architecture with constraints and great great benefits when you are interested in making you application PART of the Web”
REST is simple to use for the RESTful “API” (as word that RESTians don’t always love…) user but hard to grasp in a correct way for the RESTful “API” architect or developer.

So please REST-* guys and gals, do not do standards for the sake of it. The WS-* galaxy has so many standards that no one on earth can tell me how many (watch you eyes if you click on that). REST-* is a great idea which could turn so wrong, don’t waste it!

Indeed, there is a need to clarify what RESTful Web Services (which go beyond REST only) are about and this organization may help towards this particular goal. As a starting point what really helped ME towards this goal already exists. It is a book (a thing with a lot of pages that you can read without Internet connectivity) by people who understood most points of a RESTful architecture. A book that I read over and over again, understanding each time a little more while putting it in practice.

Btw, we are currently writing a more techie and scientific article for a conference which we will publish as a more detailed white paper once it is ready. It should also give its share of advices on building RESTful architectures for… things!

from my point of view, this workshop nicely complements the Location and the Web (LocWeb) workshops organized in 2008 and 2009. however, i guess we will face the exact same challenges: my vision for the LocWeb workshops was to not focus on location-enabled application that happen to have a web interface, but to really focus on the larger, systemic issues of location on the web; to look at what it takes to location-enable the web, and thus to look beyond single applications. this did not work as well as i hoped, we still had a lot of submissions about location-enabled applications on the web, but that was also good, because it provided a nice forum for presenting various approaches of how to use and expose location on the web.

for WoT, the challenge will be the same: the goal is to mainly attract submissions that look beyond the single application, and that look at systemic issues of making the web a better place for things. my guess is that we again will get the majority of submissions about projects that deal with real-world things, and somehow expose these on the web. and again, it will not be a problem, because that will allow us to provide a nice overview of the current landscape of these applications.

since i am currently at ICWE 2009, i couldn’t help but notice the similarity to what’s going on here: even though it’s called Web Engineering, the majority of the conference is actually about Web Application Engineering, or more specifically Model-Driven Web Application Engineering. but even though this is more about engineering for the web (or even software engineering for the web) and not as much about engineering the web as i would lke it to be, it still is a great forum to see the ongoing developments in how apps for the web can be created. and regardless of personal preferences, the thing that matters most is that there are forums where people can meet and discuss the future of the web, and not only that of web apps.

I just heard about web hooks yesterday and thought it’s just something totally cool. I think it’s an excellent approach to a much more programmable web and world, especially if we think in terms of small scale, personal mashups. The idea has been around for a while and maybe hasn’t been formalized with an official terminology yet, but it’s a totally cool way to have some publish/subscribe mechanism on the Web, or better said trigger-based notifications.

It’s funny that I was thinking of doing something like that, but Jeff did it a little ago already. I loved the slides he made, it’s not only totally cool to sell the concept and idea, but also full of cool examples and ideas, so you definitely want to check them out. No seriously, his slides kick ass! And I can’t help fantasizing about the endless possibilities of a hookable web of things.

Something similar for devices is a very neat way to obtain a more flexible notification mechanism for devices, and certainly cleaner and more RESTful than using comet, which is nice, but feels to much of a dirty hack.

Do you have some experience using hooks or other notification mechanism for devices? Fire up, comments are here for that!!

This is a project to develop and build a free and open source energy monitor. Energy monitoring is a key technology in building a bright and smart sustainable future. An Energy monitor is a device that enables you to look at your energy use in detail, which appliances use the most energy and when they use it. This makes using energy more efficiently easier.

Definitely a cool initiative and I would love seeing more projects like this one.

To be clear: we don’t claim to have invented WoT; it’s been here since the Web itself, and tons of projects have already connected objects to the Web. This is cool, but doesn’t reflect our WoT. The core concept of WoT is in the W (remember, Web), and it’s about reusing what’s on the Web not only for documents, but with also to interact with things in the real world. In particular, use as much as possible of the HTTP standard to build applications for devices, instead of relying on middlewares or other proprietary protocols. This is completely different from the pre-WoT projects, where the Web was used only to access Web pages with data from devices. What we propose is use as many functionalities of HTTP as possible to make everything in the world both a Web server and a Web client (some of these functionalities might not even be supported by firefox – although they are part of the HTTP specification).

Spot the difference? It’s very subtle, yet fundamental (okay almost philosophical).

The actual debate of what the WoT really is, stems directly the debate between REST and SOAP based Web Services. The point is not which one is the best, but which one is better to fills your requirements. And in the context of WoT more about end-users, rather than big companies, REST might be a better candidate, and that’s what we’re talking about on this site.

Historically, the first time I saw WoT is in these two presentations of Dave Raggett. For me, these slides are the clearest and first conceptualization of the Web of Things. Around the same time, this tech report by Erik Wilde (who should use his account here to post from time to time is what I could say the seminal and most inspirational source and documentation about the WoT vision. That was straight to the point, and he laid the finger on exactly what the WoT is about. Our work here is merely a continuation and implementation of Erik’s initial vision. However, the term “Web of Things” itself is older and from what I know, the earliest occurrence can be found in Traversat’s paper.

On the other hand, when I see people publishing and marketing things about WoT without even mentioning that paper (or Dave’s slides), means that either they didn’t google “web of things”, or they just try to hide the fact that they didn’t actually come up with the idea. The same is true for people publishing papers today 2009 about WoT, without acknowledging our papers, or worse none of Erik’s or Dave’s – how about googling “web of things” before proclaiming inaccuracies?

The coolest thing yet for me is to see people popping out of nowhere (such as a totally different area), and being self-proclaimed WoT experts. Check this keynote for example (did anyone of you ever hear about this conference by the way?). I’d sincerely love to see WoT hackers and coders and [insert occupation here] popping out throughout the world and join us to make the WoT a reality, but I don’t think powerpoint is really the tool that would help us the most. We need coders, and people who really want to see what’s underneath the surface of HTTP.

For the sad part, is when I hear people talking about “web of things” without actually caring about the Web (as in HTTP) at all. These folks actually mean Web as in Web 2.0 (you know, facebook, twitter, wiki, bla bla blaaaah), but not a single word about the technology and architecture of the Web. It seems that what is important is to put toilets and things on twitter no matter how (this twitter trend is seriously driving me mad btw). Hmmm, okay, if you say so. This is only the tip of the iceberg which is “putting things on the Web”, and not the real problem which is “making things part of the Web”.

Again, a fundamental difference.

What you guys think? Are we just too religious (and almost fetishistic) about that, instead of focusing on more relevant higher level issues? Would love to hear what you think!

But the best of them is the WOT whitepaper, about the general vision. It’s short, a little geeky, but has the vision and motivation in it. In a few words we hope people can a little better understand what the WOT is all about.

We plan to do a few more of those guys, in particular the elevator pitch for business people, and another one like a tech report for total geeks (guess which one we prefer), but for now it’s an initial milestone that should at least help spread our vision.

Send us please your comments, and we’ll hopefully improve it much more in the future version (I feel like it’s still very geeky). Indeed, I think the hardest part of WoT is the communication and the positioning of WoT, i.e. what it is, what is it good for, and how to use it. Help us spread the word and ideas, send it all around the world.

Here the WOT white paper

Update: As Stefano proposed, here is the embeddable version, Thanks!
Web of Things whitepaper v1

If you want to know more, just come, and read our MEM paper. I’ll be posting soon what I present there. I can’t wait to be there, and meet all these cool people! Given what I read about the first one, it’s gonna be awesome!

Dom: Just for the records, I have to admit that this paper is clearly amongst my top five for 2009. It’s a paper we can use and cite quite a lot in frame of our web of things projects in order to justify our design choices.

Cesare begins by asking the audience whether WSDL is loosely-coupled? Most people said no which kind of crashed Cesare’s effect (Dom: I guess many people like me pre-read the paper ). Some aspects of WSDL go towards loose-coupling (like the fact that you get language independent) but then it is also not loosely-coupled because for instance there are a million ways to describe operations in a WSDL.

His point is that loose-coupling should be considered as a multifaceted decision where the goal is to find the best-effort solution for your case. Erik goes on talking about the facets they identified such as discovery, identification, binding, platform, interaction, etc. (see the paper for a full list).

Cesare goes on with the first facet: Discovery. Centralized registration is tightly coupled, de-centralized for instance by providing links (Dom: as it is the case for RESTful services) is loosely-coupled. For naming globally unique names are considered to be more loosely-coupled since they do not introduce micro-worlds where names are unique and prevent the need for translation. A platform is loosely coupled if you do not use some abstract and language independent means of describing your functionality. Cesare take the example of using Java only (tightly coupled) vs using WSDL on top of Java (loosely-coupled). Erik talks about models. He says that loose-coupling can be achieved when the model is focusing on what you exchange and on how do you act on it rather than entirely describing the exact semantics of the interchanged data and services.

After describing the facets, Erik and Cesare go on by explaining how they evaluated RESTful HTTP, RPC over HTTP and WS-* / ESB (Enterprise Service Bus). They provide graphs which can be used as a basis to take decision on where to use what technology depending on how important is one facet against another for your own use case. Overall REST wins if all the facets have the same weight for you (Dom: which is unlikely to happen, you should know what’s more important for you!). They explain however that this deeply depends on the particular case.

Erik and Cesare also ask the audience to provide some input on new facets we could think of. I propose considering the “time to first running prototype”, namely the time it takes you to have something running and not too unclean. I also suggest that this could be a nice facet for the world of research where applications need to be designed quickly but still re-usable to some extends. Erik replies that they indeed want to look into more, soft, development-time facets such as ease of development, ease of understanding the system, etc.

Dom:This paper, is a very nice attempt to end the RESTful vs. WS-* (which you could read as X vs. Y) war in terms of loose-coupling since it offers a nice and neutral (although I do know they both like REST very much ) framework to evaluate what technology is best depending on what really matters for you and how much you need your solution to be loosely-coupled. There is no ultimate answer, there are systems you should not use anymore (mainly because they are dead or not supported by any sufficient community, like plain RPC, Remote Procedure Calls) but choosing amongst the still-alive systems is a matter of really evaluating what you need, and this paper can help you towards that goal. In the case of the Web of Things we picked RESTful services but we did this after evaluating the WS-* approach and we also know that in some cases the WS-* approach still makes sense.

Update: the slides of the talk can be found here.

Dominique Guinard presents this paper. (You might wonder how I manage to both present it and blog about it, well this is thanks to Ghislain Fourny who wrote a summary of my talk).
After introducing a couple of smart objects and noticing that the audience is uncool as nobody has a Poken, Dominique asks how we are going to deal with the 1000+ smart objects each person is going to have within the next 5 to 10 years. Communicating with these objects could be made easier with Mash-ups.

The agenda will consist of a discussion of the Web of Things, the introduction of a Web-oriented architecture of the real world, the demonstration of two prototypes one of which is going to crash, and finally real-world Mash-ups.

Architecture:
1. Resource design: each resource is accessed through a URL, e.g., http://webofthings.com/spots/2/sensors/light
2. Representation design: XHTML would be the default, JSON would be better for parsing and XML would be ideal for integration
3. Uniform interface: the HTTP protocol does the job with GET, PUT, DELETE, POST. HTTP headers tell what data is being sent, and HTTP bodies contain the data.

The integration could be done through a smart gateway which discovers the devices, understands their API and exposes them as a RESTful API. Dominique mentions that Nokia is going to introduce a home control center, which will, so he says, fortunately for his work be proprietary. As opposed to the integration with the smart gateway, a direct integration would consist of smart objects having all a RESTful API.

Dominique attempts a demonstration. He turns on a sensor which gets an IP address. Two LEDs indicate that it is on the web. With an AJAX website developed with the Google Web Toolkit, Dominique selects the sensor URL and explores its services, described using JSON.

The goal of the next example is to integrate smart plugs (Ploggs) thanks to the smart gateway. Dominique plugs one of them to his smart phone, the other one to his computer and starts the gateway. Using three rounds of bluetooth, the gateway identifies all phones, well, plugs (as of course everybody in the room kindly turned off their phones upon Dominique’s request). Then Dominique navigates to the gateway URL and notices with surprise that his computer consumes 80W.

In order to compose real-world Mash-ups using these devices and this architecture, it is possible to use Yahoo pipes, Microsoft Popfly, etc. For the example, he uses his own program showing diagrams of the consumption of his devices. After 20 seconds, the data are plotted and Dominique notices that his smart phone only consumes a cool 4W.

Eventually, he introduces a physical Mash-up with an ambient energy meter, which is a Mash-up made of Ploggs, Sun Spots and gateways.

Dominique concludes by considering REST as a suitable approach for small embedded applications, although it would be nice to have asynchronous mechanisms so that they are investigating protocols like XMPP. Mash-up editors would also be nice to have.

The video of the prototype in this presentation is available on: http://www.youtube.com/watch?v=1H49H1pPSBI
The presentation is available below:

Bibtex:

@inproceedings{dguinard:wotMashups:2009,
author = {Dominique Guinard and Vlad Trifa},
title = {Towards the Web of Things: Web Mashups for Embedded Devices},
year = {2009},
month = apr,
booktitle = {Workshop on Mashups, Enterprise Mashups and Lightweight Composition on the Web (MEM 2009), in proceedings of WWW (International World Wide Web Conferences)},
address = {Madrid, Spain}
}

I’ve notice that all the people I talk to not really understand what WOT is about, and for this reason we’re working on the WOT manifesto with Dom. I want to position the WM (yes, for WOT manifesto) as a central starting point of our joint action, and I think there are a few important points to clarify to convey our message perfectly. This post is in the continuity of the previous one, but more aimed at WOT in particular.

WOT is not a technology. It is not a standard either. WOT is a vision and a community.

This is maybe the most important aspect of WOT. We tend to radically position our work on a higher level than the current Internet of Things and alike. For us, the Internet of Things is to connect devices together over the Internet. Great! Wow! So what? Why should we care?

Networked objects have never been (and should never be) about just connecting things together. It’s about why we need to connect things, and most people ask us “but why do you guys want to connect your fridge with your toaster, what’s the point? Why would you want to do that?“. I seriously don’t know, and I really don’t care! And if somebody asks me that again, I’ll slap him in the face, I promise! That’s as simple as that. I also have no idea of why would anybody connect a dildo with the RSS feed of the vibration sensor on a volcano in Vanuatu. But I’m sure there’s a lucky girl (or boy) out there who knows! And if she can’t hack it herself, then she’ll never have a volcano-linked dildo, and that’s no good. That’s exactly the kind of people we care about (not the sex freak, but the average Bob or Alice), people who want to connect something to something else! That’s what the Web of Things is all about! People who know just a little bit about of computers and would like to do much more with them to create new things that nobody thought of before without a PhD in computer science. Technology today just sucks because people who build things are too selfish to care about the users, and because of that, in the end most things out there are way to complex to do what they were supposed to. Technology is so not plug & play, and we can change that because the technology to do it is out there and works well enough for my parents (but maybe not for guys playing with the LHC).

I’ve been working with wireless sensor networks (WSN) for over five years 2004, and although I can see today better tools, algorithms, and protocols, these devices area still only made for geeks. Or for the new rich with tons of cash to show off. Seriously, after a decade of active research in this area I think that WSN are have become a product-ready technology sufficiently robust and performant for most non-industrial applications. However, as mentioned in my previous (mis-titled) post, I still want to see something that is made for the end-user. I mean, we have hundreds of different products that could potentially gather data and monitor places and things, but there’s nothing on the market that I can buy, unpack, plug, and use right away. I didn’t try commercial solutions such as Arch Rock‘s or Crossbow’s EKo nodes, but I’m certain that they’re almost impossible to change to build new applications on top of it. And devices made for research (tmote, sunspots, etc.) solutions are either too expensive or too hard to use. Or both.

A few of the toys we’re Web-enabling. TMote sky and Sun SPOTs.

From a technology point of view, I’m sure that the price of a WSN node could drop to less than 20-30$ each. But even so, who would want to learn TinyOS or Contiki to program them? Who wants to implement their own mesh routing algorithms or time synchronization? Nobody does! There are tons of solution for doing that, maybe not perfect but certainly sufficient for monitoring electricity and temperatures in my house. Imagine buy a couple of devices, configure them easily in a Web-based interface (yes visually, not with code), add new modules from the Web (or from apple store). But there aren’t any LEGO-like approach for WSN or embedded devices.

But why is that so?

Look at the Arduino. It’s a slick sexy wonder! Simple, cheap, easy to use and to program, and it just works. WSN people have a lot of lessons to learn from that slap in the face! How come an open-source piece of hardware that didn’t even come out from the higher circles of academic research in the area of embedded devices has become so successful? Simple: anyone can buy one for like 30$ and can code a hello world within minutes. And that is what matters the most today! While technology keeps improving all the time, devices become faster and more powerful, but we humans don’t. If a device today needs 10 minutes to do something today, it’ll take only one minute to do the same in 10 years. And if that something is programmed in 100 lines of code today, well in 10 years, it will require… still 100 lines of code. But if it takes 10 lines of code instead of 100, then we have something. That’s also what the Web of Things is about.

The Arduino. Such a slick and sexy toy!

For me, the field of Ubicomp has become mature enough so that people should stop digging their own graves, look around, climb up of their hole, look around again, and think. What do we see? Thousands of projects in all directions, with basically no overlapping or links between them. A common ground for connecting all these devices together is lacking, right? Does it ring a bell to you? Yes? Do you really think Internet would have worked if every server would have tried to push its own standard? Of course not! And what’s more important? Internet is only the lower part, how data gets transferred from point A to point B. It’s about sending data, be it Morse code over telegraph or smoke signals. But the Internet doesn’t say anything about data that gets transmitted and that’s how it should remain. But on top of TCP/IP comes the application. You’re free to design your own application of course, but why create a new one when you already have something that work just great, and that would get your job done?

No matter which devices I buy, they should understand each other right away, because they all use the same application – and that’s where the Web comes into play. We don’t think the HTTP is the best solution in the world for everything. We just think it’s out there, it’s used by 1.5 billion people, its simple, yet powerful, and its potentials are largely untapped! Most people use only 5-10% of what HTTP is about, and automatically assume “that’s it. we’ve seen the whole think and it sucks. it not good for embedded device”. It’s so wrong, because the people who say so never used HTTP, but only HTML to build their frame-based homepage, filled with animated gifs (you remember, like the very first home page you made in the mid 90′s?!).

Many people think we advocate religiously the Web (and HTTP, or worse HTML) as being the best solution for everything and that we want everything in the world to become a Web page. That’s so not true, especially because we have no links whatsoever with W3C or any other standardization comity. The fact is we are just lazy. We don’t want to reinvent something that already exists just for the sake of it. Our central goal is to reuse as much as we can, and to spend our time to tackle unsolved problems. Recap:

Our aim is to enable developers of applications for embedded devices to spend as few time as possible to program the device, so that people spend most of their time on developing their application and how to combine the data. Developers should never care about the underlying communication or implementation, and certainly not low level data routing and other weird aspects irrelevant to them.

This is another essential point of WOT! JDRTFW (just don’t reinvent the f***g wheel)! There’s so much code out there that we can take, reuse, tinker, and optimize, yet so many people come up with yet another lousy standard or protocol that serves only to connect fridges and TV sets! Guys, just stop that, it’s simply useless. Of course, once in a decade there’s a cool standard that gets invented and adopted and that’s OK. But unless you’re Vint Cerf or Tim Berners-Lee, then maybe you should focus on reuse and improve what’s out there for doing what you want. That’s exactly what we want at WOT! And we propose to use the Web because it’s the most wonderful example of a great, simple, and functional technology in the area of distributed computing. After 20 years of the Web, we now have access to the tools and expertise to build efficient websites that scale to millions of concurrent users. HTTP is a great technology, because it’s simple and was not made for something in particular other than connecting data. Not so much data about fridges or people, but about anything you want. The versatility, openness, and simplicity of HTTP was detrimental to its success, therefore our goal is to learn a lesson from the Web and reuse the same principles that made it success. Then reapply the same principles, and if possible technologies, to connecte not just virtual data but also things in the real world. Many people told us to forget it as that’s will not possible given that the Web was not done for that. Sorry Nostradamus wannabees to disappoint you, but you were wrong and we’re here to prove it. That’s another aspect of WOT, to show that the Web can be very well used to conenct things together. Just like house can twitters, we’re working on putting tons of objects on the Web, and you’ll be able to ping out fridge and subscribe to the RSS feed of my chair so that you know when I stand up and sit down? Why? To feed it your dildo, don’t you get it yet?

Finally, the most important thing maybe about WOT, is the notion of community. We would like thank you all so much for your mails, comments, koudos and support! It’s so great to see the impact we had in just a few months, and so many people responded positively so thank you! At the moment, we’re still thinking about the materialization of the WOT as something beyond a blog and a vision. How can we get you guys involved? How can we build the world of tomorrow all together? We don’t know yet, but we’re working hard on it. We don’t want to build an open source community around a single project, but an intersection where people from all fields interested in networked things can find each other (no dating service if you ask), share their creations, ideas, and feeds, and simply build cool and usable toys for a better world. Oh, if you’d like to join our bloggers team in particular if you want to blog about existing tools, products/projects, please send us a mail.

Maybe WOT could be summarized as follows: “Now we got technologies and protocols to connect things in a sufficiently reliable manner, so how about we stop focusing so much on technology only, and let’s have a look at the big picture. Let’s have a look about how anyone could use these devices simply without being frustrated by technology under the hood. What can people do when we can connect virtually anything together? And how to make it simpler for the average people to build their own mashups of physical objects? How to enable anyone to do anything they want with the electronic devices they buy? These are the important questions we should start considering. Let’s focus mainly on people and let’s see how they behave. Let’s stop thinking only about technology, because in the end it is not what matter. Technology is a tool, and if it’s cumbersome to use, then it sucks.”

We also still have a PhD to finish, so most of the things we’re working on are still lab prototypes and not so much user-oriented, and we don’t intend to create commercial products any time soon. At this moment, we mainly focus on the scientific value of our toys (no, we don’t ship web-enabled dildos), and are testing and analyzing them to prove that, yes, the Web for connecting things works a lot better than anything else out there. Maybe not in terms of performance, but certainly in terms of functionality and flexibility. We even dare to say that we got a bunch of awesome toys and ideas that will rock the world, but we’ll release them slowly (yeah if we give the whole pack to you, you’ll sell them, make money, and not even say thanks to us nor invite us for a champagne on your yacht you bought with our sweat!). Let’s call that marketing. One thing is sure: stay tuned! We’ll soon release little jewels you can take, play, and tune, but also more scientific and tech data so you can also take contribute to the Web of Things, not just toys and prototypes. For now, we just want to make our work more solid, reliable, and more scientifically valid to show to the world that we don’t just talk non-sense, but actually get awesome things done (and they’re freaking awesome, so you’ll for sure soon hear more about them).

In the next weeks, expect a finalized version of the WOT Manifesto both in an elevator pitch form (1-2 pages), and then later this year the “impress-your-girlfriend” version (in like 10 pages with much more tech meat). Pfeew, that was a long post, and congrats for reading it up to here. You deserve a beer! And I’m going to grab one on the that sunny terrace too. Pfewww.

Many Web-based data sources and services are available as feeds, a model that provides consumers with a loosely coupled way of interacting with providers. The current feed model is limited in its capabilities, however. Though it is simple to implement and scales well, it cannot be transferred to a wider range of application scenarios. This paper conceptualizes feeds as a way to serialize query results, describes the current hardcoded query semantics of such a perspective, and surveys the ways in which extensions of this hardcoded model have been proposed or implemented. Our generalized view of feeds as query result serializations has implications for the applicability of feeds as a generic Web service for any collection that is providing access to individual information items. As one interesting and compelling class of applications, we describe a simple way in which a query-based approach to feeds can be used to support location-based services.

Feeds as Query Result Serializations is a technical report published today. it describes what we think will be the next step in the evolution of lightweight web services. in the same way as containerization has revolutionized the global trade of physical goods, feeds are already essential as a lightweight and universal way of sharing machine-readable information, and this trend will continue.

one of the major missing pieces in the atom landscape today is the lack of well-defined query features, and we argue that such a capability would make atom feeds much more flexible in a wide variety of scenarios. this can be as simple as querying feeds by category (something already possible with GData), or as sophisticated as spatial queries when considering geo-referenced collections. more specifically, the step from the Internet of Things to the Web of Things, i.e. making the step from enabling connectivity to a web architecture for networked things, probably will be made possible by smart ways of extending and combining feed technologies. after all, many of the data streams produced by sensors or other pervasive technologies can be readily mapped to feeds, and exposing stream processing capabilities as queryable feeds would bridge the gap between web-based information streams, and information streams originating in the physical world.

In this paper we better explain the concepts behind the Web of Things, namely we talk about the way we implement RESTful APIs for embedded devices. Furthermore, we discuss the different integration methods to connect embedded devices and sensor networks to the Web. Showing how we can both integrate the future IPv6 devices and current non-IP devices to the Web through the use of Smart Gateways. We also show how these gateways can provide higher level functionality such as aggregating the services provided by embedded devices.

Finally, and that’s the focus of this paper, we introduce how a massive deployment of the Web of Things’ concepts reduces building real-world applications to the way we build Web 2.0 Mashups today.

Check it out for yourself, the full paper is available here!.

In order to better illustrate the application and for us not to have to carry a printer, a kettle and a… fridge around for each demo, we shot a video of the prototype.

The end of the video also contains some more technical insights on the structure of this project and of the web of things in general.

Enjoy! (PS: choose the HQ version, because it is rather hard to read the screen-casts on the other one, PS 2: Thanks to Iulia Ion for the great “fridge opening” acting!)