Team:Freiburg Software/Developer/Architecture

From 2010.igem.org

Architecture

SynBioWave turns Google Wave into a biosynthetic software suite. There are currently two available methods for extending Google Wave, and we are making use of both in SynBioWave:

  • Robots
  • Gadgets

Robot

A robot is an automated participant on a wave. It has a Wave ID in the form of bot@example.com, and you can add it to your Contacts list just as you would any Wave user. The only difference between a bot and a human Wave user is that the bot is programmed to automatically perform some function within a wave. A robot can read the contents of a wave in which it participates, modify the wave's contents, add or remove participants, create new blips and new waves, and insert content into waves. In short, a robot can perform many of the actions that any other participant can perform. Robots are created and manipulated using the Google Wave Robots API. You can use the Robots API to perform actions such as the following:

  • modify information in a wave
  • insert elements such as gadgets and images in a wave
  • interact with participants on a wave
  • communicate and synchronize information in a wave to the outside world or to other waves
  • access or modify state in a third-party system (such as a database)

Gadget

Gadgets are little web programs included in a wavelet and communicating with it via Google's Wave API. Typically they aren't full blown applications, but small add-ons that improve certain types of conversations. For example, a wave might include a gadget that lets wave participants vote on where to go to lunch. Wave gadgets can:

  • Access more granular state management
  • Find out the current viewer and all of the other participants on the wave
  • Work harmoniously with the Wave playback mechanism

Gadgets running in Wave belong to the wave they've been added to. They can set the state and also respond to change in it. State can be shared between all the participants of the wave or can be private to the particular participant.

SynBioWave Block Diagram

SynBioWaveRobot and other extension robots are installed and works on Google Wave Server. The communication between various parts of the application can be explained as follows:

User-Wave communication

The user interacts with the wave client in order to use the SynBioWave and other extension robots. He logs in to the wave client in order to use robots. This communication can be called User-Wave communication. The wave client also consists of various gadgets like Menu, input forms etc. The interaction by the user to supply the input parameters to the program also fall under this category.

Block diagram explaining communication in SynBioWave

Wave Internal communication

This communication relates to the interaction between various parts on the wave server. The input given by the user is forwarded to the server through HTTP/HTTPS requests and then various parts of the server communicate with each other in order to give an output to the user (Robot execution)

Qooxwave protocol

We invented the qooxWave protocol to realize an easy to use interface for creating graphical user interfaces (GUI) inside a wave from a robot. The protocol defines a server-to-client and client-to-server communication. This communication contains

  • A server-to-client communication for building client-side GUI elements from server side (so a server side robot can create a client side button for example)
  • A client-to-server communication for reporting events fired in the client side GUI and to transfer user input data to the robots (so the server knows when the user clicks a button for example)

The communication is realized via JSON-Strings that are stored inside a gadgets state object. Both, server (robot) and client (gadget) can access the state object and they can both react on changes of this state object (this is provided by the google wave API).

QooxWave Protocol

The client-side implementation of qooxWave is based on a qooxdoo application loaded into a gadget inside the Wave (have a look at the screenshot on the right). This qooxdoo application - written entirely in JavaScript - communicates with the SynBioWave Robot via JSON-Strings using a state object provided by the Wave API. The state object is actually designed for gadget-robot communication. But it only supports String-Data. This is why we use JSON to transmit more complex objects. The qooxdoo application receives a JSON-object from the robot containing a GUI-structure. It parses this object and dynamically adds the ui-elements. On the other hand, the application sends user input back to the robot, also in form of JSON-Strings. As an example, the robot could send a JSON-String containing information about a toolbar, its menu items - let's say just a button labeled upload - and information for an upload form that opens when clicking the button. The JSON-String is modeled into a certain JavaScript object (to be precise: qooxdoo objects) and then displayed by the qooxdoo application. When the user submits the upload form, its data is converted back to a model again, than to a JSON-representation and sent to the robot.