Web of Things 2010 Workshop

we were just informed that our Web of Things 2010 proposal at the Eighth Annual IEEE International Conference on Pervasive Computing and Communications has been accepted, which means that there will be a WoT2010 workshop at PerCom 2010 in march 2010. this is great news for us, and i am looking forward to organizing this workshop with dominique guinard and vlad trifa from ETH zurich's distributed systems group.

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.

Comments

[Grant Robertson]

Erik, I read your paper "Putting Things to REST" with quite a bit of interest. On the one hand the concept is deliriously simple: Design physical objects such that they can respond directly to text commands over a communications medium. In fact, as I'm sure you know, many objects already do exactly that. As you mentioned, RFID tags respond to a query, although that query is usually in the form of a simple radio wave with enough power to drive the circuitry within the chip. Most sensors and actuators used in factories also respond to text commands of some sort, or they have controllers that do. Heck, I remember my first 300 baud modem and the AT commands I had to type in order to get that thing fired up. Later, as a network manager, there were many pieces of equipment that had to be configured via a so-called "terminal interface." These days many devices, especially network equipment, have their own web-based interface, in that the user can simply connect to them over the network with a simple web browser. The device acts as a mini-web-server and responds to the browser's HTTP requests.

Of course the problem with all of these devices is that they all communicate through different media using radically different protocols or standards. This situation has been endemic in the electronics industry ever since I can remember - and I have been dinking around with these things since about 1976. This is the reason for the oft-quoted retort: "The 'nice' thing about standards is that there are so darned many of them." I even wrote a little rant about standards design (http://www.ideationizing.com/2009/06/why-standards-fail-open-letter-to-oag.html) back in '93, not that it did any good.

However, it seems as if what you are proposing is nothing short of "One Standard to Rule Them All," with apologies to JRR Tolkien. Quite an undertaking, I must say. I certainly understand your apprehension at receiving dozens of entries that are not much more than one more proprietary method of a device communicating over the internet. This has been the pattern since the invention of electronic communication. Even Samuel Morse had his competitors. And everyone wants their one proprietary finger to be the only one in the pie.

Which brings me to that other hand: Creating a standard means by which to communicate with all these devices will be quite an arduous task. It seems that you are on the right track, though. HTTP and it's simple set of "verbs" is commonly accepted and well known by developers. Even embedded systems developers are familiar with it. Most existing systems using it implement a full web interface rather than respond with simple pieces of data but all they would have to do is add a set of responses to a set of queries. Other devices - such as sensors and actuators - commonly communicate over much more robust serial mediums such as RS422. They communicate with a central computer or networked device that then can be accessed over a network. But the actual sensors and actuators are very simple with only a minimum of communications electronics contained within them. This is because of the harsh environments in which they must be depended upon to function day-in and day-out for years at a time without fail. I don't know if an attempt to convince the industry to make their actuators less reliable (real or perceived) will be met with much success. Besides, existing factories would have to be completely rewired to communicate with your new, smarter devices. Therefore, it would be more efficient to concentrate on the one, central device that all these actuators and sensors already connect to anyway.

I think your best bet will be to simply start developing your standard - according to the principles I laid down in my linked-to rant above, of course. Naturally you must study all the industries that use the types of devices you intend to communicate with. Manufacturing, Inventory Control, Network Management, Scientific Data Gathering, Major Appliances. There are even systems sold to Law offices that track each document with a tiny RFID tag. It will take a lot of digging to find all the different industries that you wish to eventually influence. Then develop open source libraries for many languages that can communicate using your standard. Be sure to including the scripting languages used in the manufacturing industry to control their machines. Use licensing terms that allow commercial use. Finally, find a market where two or more existing categories of devices need to be controlled from one system. Offer to solve their problem for free. Once the other industries see that first success - which I presume you will have - then the doors will be wide open.

Unfortunately, I am not an electrical engineer or I would certainly jump right up on your band-wagon. I am currently working on a very belated Bachelor's degree while trying to develop my own standard (www.deml.org) so I will not be able to attend your conference. However, I am sure it will be interesting and I wish you the best of luck.

[dret]

@grant: thanks a lot for your comment and encouragement. you sound a little bit skeptical about the idea and approach, and maybe it's because of a misunderstanding: our vision of the "web of things" (and others are of course entitled to see it differently) does not necessarily mean that all "things" must be fully enabled to directly respond to HTTP requests. that's the beauty of web architecture and REST: you can always have intermediaries that transparently step in and process requests (in web speak, those would be "reverse proxies"). what this means is that infrastructures are free to use the communication protocols and interaction methods that work best for them, as long as they expose (at least a part of) their services as RESTful services on the web. what this means is that even very demanding real-time scenarios can nicely integrate into the web: they might not retain some of the hard real-time properties which can only be guaranteed in a more tightly coupled environment, but they could still provide a useful subset of their services in a more loosely coupled way. think of it this way: you want your accelerometer in your car to talk to the airbag in a tightly coupled and highly optimized way, so there's no need to drop the well-established methods for doing this as part of the on-board communications. however, your car could also provide web-based services to the outside world for diagnostic and other purposes, which probably would be most useful if they were provided via non-proprietary technologies such as HTTP and XML.

[Grant Robertson]

Erik,

Ah-ha! My mistake was not in thinking that you wanted to connect ALL things but in thinking that you wanted your protocol to REPLACE all existing protocols. Now I see that it is an addition to existing systems that can be added as needed. I see that the main function is not to be the new, be-all-end-all communication protocol for all control systems. Rather, you intend it to be a means of communicating remotely, over a network, about the status of a thing (or entire system) and making external adjustments to that thing or system.

There is certainly a great need for your concept in industry. There is a remote monitoring protocol for network equipment but it is very complicated and proprietary. (It has been so long since I was a network manager that I can't even remember what it is called.) However, for most manufacturing or HVAC control systems one must be at the control computer to see the status and make adjustments. This control computer is, as you say, tightly coupled and very, very proprietary. Usually, the only way to access this type of system remotely is to install some type of remote access software (such as Symantec PCAnywhere) on that computer and then work through the same user interface but on a remote computer. It is certainly not the kind of thing that can be automated and it leaves no possibility for the development of additional open-source software to monitor multiple systems and report on trends or set off alarms.

When direct access to data is available in these types of systems it is almost always via a proprietary API or protocol, as you have mentioned. When multiple disparate systems need to be centrally monitored it is only possible if one can get all the different vendors to cooperate on an expensive custom solution. This is why most companies simply resort to setting up multiple computers on a desk and sitting a person down in front of them to carefully watch them all separately.

My son recently got a job in the gas pipeline industry. He has told me that it takes about 20 people with about 20 years of experience each to sit and watch computer screens all day long to keep track of and ensure the safety of a gigantic network of gas pipelines. When they spot something going wrong they then have to call or send e-mails to each other to work out the solution. If someone doesn't spot a problem in time, or if they manually enter an adjustment incorrectly in the vast array of similar - but not identical - control fields then millions of dollars can be lost to waste or damage. Your WoT protocol could save millions of dollars in the gas pipeline industry and dramatically reduce or eliminate the possibility for human error.

Perhaps that could be your showcase solution. With T. Boone Pickens pushing natural gas as the solution to our energy needs, I am sure there will be a lot of new development in this area. I don't think he will be too very inclined to repeat mistakes of the past and install yet more human-error prone monitoring systems. So, a secure system using an open standard built upon other open standards may be just the thing for him. He has definitely got the money to invest in the research. (hint, hint)

I tell you what, I sure wish I could attend this conference. It sounds like incredible fun and I am buzzing with ideas just thinking about it. Unfortunately, Germany is a little far for me to ride my scooter and I will be busy finishing up a beta version of my own standard for my senior project. (Of all the things to misspell in my previous comment, I misspelled my URL. It is www.demml.org.) Anyway, again, best of luck. Hopefully, one day we can sit around over a beer and a large stack of napkins and toss around a few ideas.