You are here: TUTWiki>Wille>Introduction



Wille Visualisation System was originally developed as part of OPAALS during 2006-2010, at Tampere University of Technology, Hypermedia Laboratory (

OPAALS (IST-034824) was a EU funded international Network of Excellent project, coordinated by London School of Economics (LSE). During the project, several versions of Wille were implemented: in 2006-2007, first version of Wille was developed as a proof-of-concept. The current, refactored version 2 of the system was developed during 2007-2010.

The objective of Wille2 is to function as a component-based data pre-processing and visualisation system for distributed and peer-to-peer (P2P) environments. Wille provides a light-weight core that can be extended by creating and integrating components. By scripting pipelines of component execution, interactive views to data can be created.

Wille2 is primarily created to aid visualisation application design and development. Creating new visualisations requires integration and application development work. For end-users, a catalogue of Wille-based visualisations is provided as well.

User Role Concepts

In order to understand usage of Wille as part of the process of developing and using visualisations, we have identified four key rules for users: (Content) Author, (Visualisation Component) Developer, (Visualisation Application) Designer, and (Visualisation Application) End-User:

  • Authors produce, adapt, or deploy accessible content. For instance, an author might write a wiki page, add calendar event to a public collaboration space, or publish a document in a Peer-to-peer file service.
  • Developers implement, wrap, or deploy services suitable for composing visualisations. For instance, a developer might provide a new service or component (e.g. a service outputting calendar data from a content management system) available to others, or simply implement a suitable software wrapper to an already existing software component (e.g. a linguistic analysis tool).
  • Designers implement, compose, or configure visualisation applications. For instance, a designer might configure a visualisation application service to suit a particular application purpose, or, exploiting some existing services, write a Python script outputting a graphical End-User interface.
  • End-Users utilise visualisation applications in their activities. For instance, a researcher might use a social graph view in order to review the work and contact other researchers of a particular domain.
In practice, the roles of Developer and Designer may significantly overlap. In order to simplify our terminology about roles, we mainly speak about developers, understanding that developers are in general capable of acting as designers, but not necessarily vice versa (due to the required technical skills). Also, several roles may apply to organisations or individuals simultaneously. In particular, End-Users might also appear as Authors, and vice versa.


Figure 1. Basic iterative collaboration cycle of creating visualisations with Wille

Figure 1 (above) depicts the basic iterative cycle of creating visualisations. The basic idea is that the process provides a natural feedback loop between different user roles. In particular, visualisations may include references to authoring practices. This allows integrating view activities with authoring, even if visualisation application per se might not include authoring tools.

Architecture and Key Concepts

The objective of Wille2 is to function as a component-based data pre-processing and visualisation system for distributed and P2P environments. Wille provides a light-weight core that can be extended by creating and integrating components. By scripting pipelines of component execution, interactive views to data can be created.

In a layered architecture, Wille2 can be modelled as follows (see Figure 2):
  • Instances of Wille including Wille Framework itself are executed with Python (either CPython or Jython) on top of a local run-time platform. Each instance of Wille include containers for Wille Services and Wille Apps.
  • Wille Services can be deployed to and executed from Wille Service Container. Similarly Wille Apps can be deployed to and executed from Wille Applications Container. Wille Apps can access services from local and remote Service Containers, as well as with external web APIs and other end-user (GUI) applications.
  • Wille has been designed to run both on Internet/Web and P2P? runtime environments.

Figure 2.
Overview of Wille 2 Architecture

Several key concepts and components from Wille can be identified:
  • Wille Services are stateless services that can be used for specific data (pre-)processing tasks. When executed, services transform given input parameters into a single output result. A service itself may invoke other services and APIs to perform the required data processing.
  • Wille Client is part of Wille Framework that allows search and execution of Wille Services. It can also carry user- and session-specific information including user's authentication and authorisation credentials in a keyring.
  • By composing several service executions with Wille Client, dynamic data processing pipelines are created
  • Wille Apps are web-based (visualisation) applications that can use Wille Client for various tasks
  • Wille Widget is a reusable Wille App that can be integrated with other Widgets to create a dashboard of visualisations
  • Wille Server is an application that allows deployment and sharing of Wille Services and Apps, and therefore Widgets as well
  • Wille Scripts are scripts that use parts of Wille, especially Client, but have not been integrated either as Apps or as Services.
In a basic usage pattern, visualisation development would start by creating simple Wille Scripts. Later on, when the visualisation matures, individual Wille Services and Apps could be created based on the initial script. Eventually, a visualisation would consist of several Wille Apps and Services.

Different data transformations could be implemented as Wille Services. A pipelined services execution could be then orchestrated either from an aggregating Wille Service or from a Wille App. In order to integrate existing visualisation components and to provide a graphical user interface, Wille Apps could be created. At the point in which several Apps need to share same visualisation component, Wille Widgets could be then created and reused between multiple Apps.
Print version |  PDF  | History: r15 < r14 < r13 < r12 | 
Topic revision: r15 - 03 Mar 2011 - 14:36:08 - JaakkoSalonen


Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TUTWiki? Send feedback