No breaking news in this post, but we were just informed about the fact that one of our articles was in the special selection of Service Oriented Computing of IEEE Computing now as well as Featured on ZDNet.
We never really talked about this work because it largely discusses WS-* services (DPWS in particular) which are also known as “evil-services” by the RESTifarians 😀
We actually began our IoT journey with DPWS, were quite frustrated with it, but it evolved a lot since then, became an official OASIS standard, and thanks to the crew of WS4D became a lot less buggy and a little less heavy.
While we still stick to a more pure Web-approach because of its simplicity and ease of integration with the existing and fast growing world of the mashable Web, in this paper we were trying to federate them both and to explain how they could be leveraged to create an composable Intranet of physical services in an company.
The paper discusses the differences between REST and DPWS, points at several features of DPWS that are addressed in limited ways by REST (and vice-versa) such as service discovery: you can discover REST resources by getting their URI (HATEOAS but how do you get that URI in the first place, how do you resolve it?) and proposes the use of small local units, called LDUs (Local Discovery Units) to enable the discovery of both DPWS and REST services.
It also discusses how to improve the “searchability” of services for developers so that they can find the service they look for in the real-world context they want. For this it uses the LDUs (e.g., services inherit from the location of LDUs) as well external services such as Wikipedia, Google, or domain-specific portals, to extend the available semantics with extracted keywords, without overloading the devices (e.g., sensors) themselves with heavy semantics (btw, sorry but we actually were forced to patent the process :-D)
Finally, I’d like to point out that DPWS papers are welcomed to WoT 2011, we actually had some at WoT 2010! We are especially interested in report of experiences on how can DPWS and REST coahbit, because after all, nothing prevents you from using DPWS-enabled devices if you need some of its features but design nicely interoperable RESTful APIs on top.
