Implicit Inter-Widget Communication: Loops Detection Facilities

Authors: Alexey Tschudnowsky, Michael Hertel, Martin Gaedke

Introduction

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 “http://example.org/incidents”). The map is simultaneously subscribed to messages containing GPS coordinates which should act as a center position of the map (topic “http://example.org/gps”).
• A widget D showing a table overview of the emergency incidents (received over the topic “http://example.org/incidents”) and publishes immediately addresses of the nearest hospitals (“http://example.org/hospitals”).
• A widget H shows a table overview of hospitals (received over the topic “http://example.org/hospitals”) and publishes immediately GPS coordinates of the calculated center position of all hospitals (topic “http://example.org/gps”).

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.

Screencast

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.