Content Hotkeys
Distributed and Self-organizing Systems
Distributed and Self-organizing Systems

Implicit Inter-Widget Communication: Loops Detection Facilities


The mashups utilizing PubSub-based inter-widget communication approach do not require users to establish connections between widgets explicitly. Communication, i. e. data and control flows emerge as soon as widgets are put together in a workspace (so called choreographed user interface mashups, cf. [1]). Technically, this is achieved by employing the event-driven approach via publish-subscribe messaging pattern (pub/sub): widgets autonomously subscribe and publish messages on different communication channels, so-called topics. A message bus running within a browser takes care of delivering messages to all interested parties, i. e., widgets subscribed to the corresponding topics.

In some situations, however, such messaging approach may lead to malfunctioning compositions, for example the ones producing infinite message transfer or self-reinforcing loops. This in turn can cause unexpected and undesirable effects or even a crash of the run-time environment. Such a loop-producing mashup could be, for example, a workspace containing the following 3 widgets:

  • An emergency map widget M showing locations of emergency incidents in some city. The widget enables one to point a map to certain location and publishes details of all emergency incidents in the area (e.g. street name, incident description etc., topic “”). The map is simultaneously subscribed to messages containing GPS coordinates which should act as a center position of the map (topic “”).
  • A widget D showing a table overview of the emergency incidents (received over the topic “”) and publishes immediately addresses of the nearest hospitals (“”).
  • A widget H shows a table overview of hospitals (received over the topic “”) and publishes immediately GPS coordinates of the calculated center position of all hospitals (topic “”).
Such a composition causes a self-reinforcing loop as soon as the map focus is moved. The Incidents-message produced by M is delivered to D, which immediately responses with a Hospitals-message to H. The H-widget produces a GPS-message which is delivered to M causing it to move the focus and therefore to repeat emission of an Incident-message. Being executed in a browser, the loop can block the UI or cause a complete crash. To increase the end-user and developer awareness of such undesirable situations and to enable them to prevent/recover from such situations, following artifacts/software artifacts have been developed:
  1. IWC implementation guidelines (support developers in developing loop-preventing widgets)
  2. Static analysis of workspaces (support users in detection of potential loops before the communication starts)
  3. Runtime analysis of IWC traffic (support users in detection and recovery of loops as soon as they emerge)
The details of the approach are described in the D2.3 - Final specification of Mashup description language and Telco mashup architecture, a public deliverable of the OMELETTE project.

Online Demo

To try out the demo, click on the "Start cycle communication" in the first widget. The runtime analysis algorithm immediately detects a loop in the messages published to the global message bus. You can either block the complete IWC communication to avoid further loops or remove the blockade if the loop was expected/desired. To access the static analysis module, click on the arrow icon in the page title () and select "Analyze page for cycles". The pop-up window will provide a path in the communication which may cause a loop and will suggest to turn on the IWC visualization facilities.


Further Readings

[1] Scott Wilson, Florian Daniel, Uwe Jugel and Stefano Soi. Orchestrated User Interface Mashups Using W3C Widgets. ICWE 2011 Workshops, June 2011, Springer, Pages 49–61.

[2] The OMELETTE Project (FP7/2010-2013 GA n 257635). D2.3 - Final specification of Mashup description language and Telco mashup architecture. Public deliverable, 2013.

Press Articles