Google Wave’s Federation Protocol Under the Hood, Part 1

Posted Feb 09, 2010 by Anthony in Architecture, Blogs, Google Wave

Purpose [Updated 4/3/2010]

This post is the first in a series intended to cover the basics of how the FedOne project as released by Google is designed and implemented in code.  I could not find a guide that covered the internal architecture and namespaces, which left me sifting through approximately 200 files in 30 packages to gain an understanding that allowed me to modify and contribute code.  In addition, I was not familiar with some of the Google technologies employed (e.g. - Guice and ProtoBuf).  Since we are exploring the use of Wave at my company, I thought it would be helpful to our engineers to write up an overview.  Hopefully, as you read this you will find it useful as well.

I do not intend to write an exposition on every package or file.  There will be many topics left uncovered or as I like to think of it many opportunities for others to expand upon this post :).    I plan to highlight the topics that will give those new to the project/code a push in the right direction.  My current intention in this series is to cover prerequisites to examining the code, the startup process, dependencies as captured by Guice, the XMPP to WaveServer communication, and Persistence.  Other topics such as the Client-Server protocol or the OT algorithm itself will not be addressed (at least at this time).


This post is targeted specifically to developers and technical managers.  No effort has been made to abstract the technical implementations or figures into high-level concepts.  Furthermore, I assume the reader has an understanding of Google Wave in general and more specifically the Google Wave FedOne project.  

For an introduction to Google Wave, I recommend:

About Wave []
Google Wave Wikipedia Entry []

For an introduction to the FedOne Project see:

Wave Federation Home []


An understanding of a couple of Google technologies used will make it much easier to follow the FedOne code base.  These are Guice and Protocol Buffers.


You will quickly get lost in the code without an understanding of Guice and how it is used.  Guice is a lightweight dependency injection technology used and open sourced by Google.  It allows for the decoupling of dependencies in code that are created when direct calls are made to constructors of external Classes.  The Guice technology has many benefits and applications, but we’ll focus on the ease of switching out implementations of an algorithm that are present in different subclasses (think Template pattern as defined by the Gang of Four).  What you need to know at a base level (and I posit you need more) is that when you see an @Inject annotation, the parameters that follow will be looked up and supplied by Guice at or prior to runtime.  Guice does this by defining bindings in a separate Module from an Abstract class to a subclass.  A Guice injector is then created from that Module and the specified dependency (Subclass) is injected when an Instance of the Base Class is requested.  Clear as mud?  Yes, you really need to read about Guice separately from this discussion.

The reason I even broached the topic of Guice is because while dependency injection is an incredibly useful technique it does have the downside that it can often be difficult to track the class/values that are actually being applied at runtime.  Using an example from the Guice site, a constructor may have a BillingService class that is implemented by RealCreditCardBillingService and FakeCreditCardBillingService.  Since the binding to one of the subclasses is specified in a separate file and is constructed by Guice, you may have difficulty when you’re testing to realize that RealCreditCardBilling is still being used.  If you set up your Guice bindings in your own project, you’ll probably be familiar with where these settings are located, but if you’re looking at another Project for the first time that has 200 files over 30 packages it can be difficult.  For instance, the within org.waveprotocol.wave.federation.xmpp package contains @Named annnotations for parameters that are supplied by in org.waveprotocol.wave.examples.fedone.  There is a Graph extension that allows you to view the dependency linkings, however, that is not released within FedOne. I will show an output of this tool on FedOne in a later post to this series.

To read more on Guice, I recommend you watch the video and read the user guide.  There are other uses within FedOne (e.g. - scoping) that I did not cover above.

Protocol Buffers (often referred to as protobufs)

Protobufs are used by Google to serialize structured data for storage and transmission.  The data structure you wish to emulate in Java (or C++ and Python) is specified in a .proto file, which the Proto compiler then uses to generate code allowing an object with that structure to be constructed in Java.  The Proto compiler also adds a number of other methods such as getter, setter, and exist methods.  The benefit of the ProtoBufer is the simplicity, size and speed of the resulting code.  To use an example from the Protobuf site, accessing data from XML may require the developer to write person.getElementsByTagName(“name”)->item(0)->innerText() while ProtoBuf would access the same data with  As a result of the amount of code generated by the Proto Complier it is much easier to understand the structure of an object by locating the .proto file.  The methods generated by the compiler can be found by researching the ProtoBuf documentation.  ProtoBufs are used early and often in FedOne, so an understanding of them will be of great assistance.

Next in Series

The next post will cover the startup process within the FedOne code.  It will list the primary packages/classes invoked and layout the process by which they interact (will illustrate this in an Activity Diagram).

Related posts:

  1. Google Wave’s Federation Protocol Under the Hood, Part 3 Purpose [Updated 4/3/2010] This is the third post in...
  2. MongoWave: Persistence on Google FedOne Wave Server with mongoDB Purpose My company, SESI, has been working on applying...
  3. Google Wave’s Federation Protocol Under the Hood, Part 2 Purpose [Updated 4/3/2010] This post is the second in a...
  4. Google Wave’s Federation Protocol Under the Hood, Part 5 Purpose [Updated 4/3/2010] This is the fifth and final post...
  5. Google Wave’s Federation Protocol Under the Hood, Part 4 Purpose [Updated 4/3/2010] This is the fourth post in...

Related posts brought to you by Yet Another Related Posts Plugin.

Tags: , , , , ,

4 Responses to “Google Wave’s Federation Protocol Under the Hood, Part 1”

  1. [...] Google Wave’s Federation Protocol Under the Hood, Part 1 Posted Feb 09, 2010 [...]

    Reply to this comment
  2. [...] Google Wave’s Federation Protocol Under the Hood, Part 1 [...]

    Reply to this comment
  3. [...] Google Wave’s Federation Protocol Under the Hood, Part 1 [...]

    Reply to this comment
  4. [...] Part 1 – Audience and Prerequisites [...]

    Reply to this comment

Leave a Reply

Subscribe without commenting