Updated Jun 22, 2009 by pi.two.kay
Labels:	Featured, Phase-Requirements, Phase-Design

ArchitecturalThoughts

Look before you leap or run into the thick of it?

Introduction

I decided to write a quick-and-dirty Google Wave Server which shall constantly evolve into full-featured production-ready software. This implies, that writing the server is an iterative process.

The tradeoff of trying to be as fast as possible is a certain tendency to, simply spoken, go the wrong way and maybe to reach dead ends in software engineering. So I sat down, took a breath and carefully thought up a plan.

The Server Architecture

After reading the API up and down and having taken a glimpse at the Federation Protocol specification I came to the following points (summed up pretty tight):

The Client Architecture

See PyGoWaveClientArchitecture.

How PyGoWave Server is implemented

My current approach, and why I went for it.

Focus on the API's protocol

As long as there are no other Wave Servers and I am not able to communicate with Google's, I'll stick with the Robots, Gadgets and a rudimentary Wave client.

Maintain the API's object model

This allows me to rapidly establish a working communication with Robots and Gadgets. For implementing the Federation Protocol it's quite a bit cumbersome.

Create a Google Gadgets / Google Wave environment

Without access to the Google Wave Client I am foreced to build my own client too. This is a heavy task and will take a huge amount of time. Nevertheless, I'll do it.

Gadgets are already running fine in my testing environment. The next step is their integration in a real Wave.

Note: I dropped the term "emulation" here. This won't be an emulator anymore, it is the real thing! :D

Choose Python

Platform independency, clearity, nice design of the language, the ease and speed of writing working programs and much more are my reasons for choosing Python. I could write a feature-length hymn for this language.

Choose Django (and MooTools)

With Django, a persistent object model can be created in a few hours (as you have probably seen). Because of the request-response scheme of the Robot API there shouldn't be a problem to shove those events and context into a robot.

I switched from jQuery to MooTools. Not only MooTools has everything that jQuery has, but it also provides a nice toolset for object oriented programming in JavaScript. The Gadget API wrapper is written in vanilla JavaScript so it won't interfere with any toolkit a Gadget may choose.

Another reason for choosing Django: After all, you want to administer your Wave Server through some sort of Web Interface - Ok, a Wave and/or Gadget would do the trick too. At least something must serve those IFrames and JavaScripts...

Choose Orbited and RabbitMQ

The current Gadget emulator and the upcoming Wave client doesn't use any (short-)polling. Instead, a Comet framework is in place for which I took Orbited (guessed right, it's written in Python). This reduces latency to about a quarter of a second which is sufficient for Waves.

Because every data traffic in a Wave is sent via messages, a message broker had to be installed. I chose RabbitMQ over ActiveMQ because the former is written in Erlang, a nice functional language with built-in parallelism, and the latter is written in Java, which I avoid because of personal reasons.

The main node of data exchange between client and server is represented in an AMQP RPC server (with AMQP being the main messaging protocol of RabbitMQ). This RPC server acts as a controller in terms of the MVC design pattern. Because of the architecture of the message broker, this server can be easily split into multiple threads which can handle Wave messages in parallel.