by

Introduction

I have a working prototype for the following scenarii:

  • an HTML widget A discovering another HTML widget B on another machine (with different OS): B exposes itself on the network, A discovers B, A calls an action declared by B (changing the color of an HTML element in B).
  • an HTML widget discovering and communicating with a Intel Tools test UPnP service: discovering the Network Light and turning it on and off
  • an HTML widget discovering and communicating with an MPEG-U Widget (in GPAC), the HTML widget acting as a switch for a virtual light in the MPEG-U Widget
  • an MPEG-U Widget (in GPAC) discovering and communicating with an HTML widget , the MPEG-U widget acting as a switch for a virtual light in the HTML Widget

This is an extension of our work on communicating widgets [1][2][3][4] which should work in any recent web browser. The only requirements are: the platform must allow Java applications (hence no iOS), and the web browser needs to implement Web Sockets.

This work started with my work within the W3C Home Network Task Force. We worked on requirements for a platform allowing the convergence of the TV world with the Internet world, opening the TV to the Internet, and making multi-screen scenarii possible. After creating a set of requirements [5] in the task force, we “passed the buck” to the W3C Device API WG. The Device API group is working on two technologies that may answer our requirements: Web Intents [6] and Discovery API [7].

Actually, neither of these technologies is really solving my problem. I need more than just web applications/widgets and these technologies. I need:

  •  a way to package web applications and exchange them on the net: W3C Widgets (check)
  • a way to discover devices, services, and possibly other web applications: Discovery API (check), but Web Intents does not fullfil this (needs a discovery proxy of some sort)
  • a way to exchange messages between web applications and services: it is possible to implement the full UPnP messaging protocol (SOAP and all) in JS and use Web Sockets to communicate with the UPnP services; however, since the UPnP proxy is already required for discovery, and already implement UPnP messaging, it seems a better idea to use the UPnP proxy for messaging.
  • a way for web applications to expose themselves as services, in order to be discovered by other web applications or services: not provided.
What is in the system presented below and is not in the above set of technologies is: (1) an abstraction of the messaging to allow a web application to send or receive actions without worrying about the details of the underlying messaging syntax, and (2) an API to expose a service implemented by this web application.
This work is done within the collaboration project Coltram, funded by PICF 2012 (ANR/BMBF), with Fraunhofer FOKUS.

Principle

The principle is:

  • there is a UPnP proxy running beside the web browser. The proxy is implemented as an external Java application. It handles the UPnP discovery, communication with UPnP services, and service advertising. The Java application also handles Web Sockets connections to/from the HTML page.
  • there is a JS library handling the communication from the HTML page to the external UPnP proxy through Web Sockets.

API

The HTML widget calls a very simple API:
  • connect: to connect to the Web Sockets server (the proxy), providing a callBack called when the connection is operational;
  • addServiceDiscoveredCallback: to be called when a service is discovered;
  • addServiceRemovedCallback: to be called when a service has disappeared;
  • functions to remove the callbacks;
  • Action.call: calling an action from one of the discovered services;
  • exposeService: passing a Service object and a serviceFunction function. The service object describes the characteristics of the service (the elements of the SCPD), and the serviceFunction is the callback to handle actions from outside to this service.
There is also a set of classes: Service, Action and ActionArgument, used for the representation of the exposed service and to call actions.

Communication

The communication to the UPnP proxy consists in JSON messages sent over Web Sockets.

Architecture of the solution

Code

Source code and test files and jars are there.

The proxy uses the Cling UPnP library from teleal (LGPL), and the Web Sockets Library from http://java-websocket.org/ (MIT license), as well as a JSON Java library from json.org.

Tests

I have tested the following configurations:

  • HTML widget to HTML widget on the same machine (sharing the same proxy) : to test that, run the console proxy and load testWidgets/coltram1.html and testWidgets/coltram2.html on Chrome on the same machine.
  • an HTML widget A discovering another HTML widget B on another machine (with different OS): B exposes itself on the network, A discovers B, A calls an action declared by B (changing the color of an HTML element in B). To test that, run a console proxy and load testWidgets/coltram1.html on one machine, run console proxy and load testWidgets/coltram2.html on another machine.
  • an HTML widget discovering and communicating with a Intel Tools test UPnP service: discovering the Network Light and turning it on and off: to test that, run a console proxy and testWidgets/coltram3.html on a machine, and an Intel network light on this or another machine.
  • an HTML widget discovering and communicating with an MPEG-U Widget (in GPAC), the HTML widget acting as a switch for a virtual light in the MPEG-U Widget
  • an MPEG-U Widget (in GPAC) discovering and communicating with an HTML widget , the MPEG-U widget acting as a switch for a virtual light in the HTML Widget

Complete tests were done with the Chrome navigator. A partial test was successful in Firefox.

References:

[1] J. C. Dufourd, C. Concolato and J. Le Feuvre, SVG Communicating Widgets, SVG Open, Mountain View, CA, USA, October 2009 [PDF]

[2] C. Concolato, J. Le Feuvre and J. C. Dufourd, Declarative Interfaces for Dynamic Widgets Communications, Document Engineering, Munich, Germany, September 2009, pp. 241-244 [PDF] [DOI 10.1145/1600193.1600245]

[3] J. Le Feuvre, C. Concolato and J. C. Dufourd, Widgets Mobility, International Conference on Mobile Technology, Applications and Systems, Nice, France, September 2009 [PDF] [DOI 10.1145/1710035.1710060]

[4] C. Concolato, J. C. Dufourd, J. Le Feuvre, K. Park and J. Song, Communicating and migratable interactive multimedia documents, Multimedia Tools and Applications, May 2011 [PDF] [DOI 10.1007/s11042-011-0805-2]

[5] Requirements for Home Networking Scenarios, W3C Interest Group Note 01 December 2011, http://www.w3.org/TR/hnreq/

[6] Web Intents, W3C Working Draft 26 June 2012, http://www.w3.org/TR/web-intents/

[7] Networked Service Discovery and Messaging, W3C Working Draft 07 August 2012,  http://www.w3.org/TR/discovery-api/

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.