Michael Adeyeye (Ph.D)

Below is an excerpt of my recent paper. I was asked about The Google Wave during an Industry seminar here at the UCT. I checked it out and found it related to my work [1, 2], so I decided to write a paper on it. I never knew that Google was also thinking in the same direction – improving the online experience through user-generated services or converged services.

The Excerpt:

Table 1 shows the comparison of our work with the Google Wave. Google Wave, which is currently under development, is a new tool for communication and collaboration on the web. It uses an open protocol [1, 2], so anyone can build their own wave system. The Google Wave API allows developers to use and enhance Google Wave through two primary types of development, namely Extensions and Embed.

Comparison of Google Wave and TransferHTTP

The extensions (also called the Robots API) can be developed using the Java Client Library, Python Client Library, or Gadgets API, while the embed, which is embedded into a Web application, is always written in JavaScript.
The Google Wave and TransferHTTP provide the same services, though over different architectures. While Google Wave API is used to develop applications that reside on a Web server, TransferHTTP APIs are used to develop applications that reside at the client end. For example, the Click-to-dial in Google wave [3] requires the server to set up a call session, while in TransferHTTP, the client sets up the call session. In Google Wave, the robot in the Web server is responsible for the signalling, while in TransferHTTP, the SIP stack in the Web browser does the signalling.
The Extensible Messaging and Presence Protocol (XMPP) stack [4] in the Google Wave resides at the server, and its APIs are written for third-parties to help them develop converged applications. The Google team has separated the signalling (HTTP and XMPP) in a bid to maintain the current Web architecture. Hence, it could be referred to as a server-based architectural framework for service creation. In our work, a SIP stack is integrated into a Web browser to provide similar services. It was found out that the integration of a SIP stack into a Web browser does not impede its performance [5], thereby making our work a viable approach to create converged services. We provide a hybrid-based architectural framework in which services could be rendered from the client using our API. In addition, a number of services could be rendered from the proxy. These services could be called control services based on what they do. While the proxy services could be developed using the Mobicents SIP Servlets and JAIN SLEE APIs, the client services could be developed using our TransferHTTP extension API.
In summary, irrespective of the technologies or programming languages used in the Google Wave and TransferHTTP, the difference between them is that the Google Wave only has a stack (an XMPP stack) in its server, thereby making it a server-based architectural framework for service creation, while TransferHTTP has a stack (a SIP stack) both in its client and proxy, thereby making it a hybrid-based architectural framework for service creation.

References:

1. The Wave Protocol, http://www.waveprotocol.org, July 5, 2009.
2. The Google Wave Project, http://wave.google.com, July 5, 2009.
3. The Google Wave Click-to-dial, http://googlewavedev.blogspot.com/2009/06/twiliobot-bringing-phone-conversations.html, July 31, 2009.
4. P. Saint-Andre, Ed., “Extensible Messaging and Presence Protocol (XMPP): Core,” IETF RFC 3920, October 2004.
5. Michael Adeyeye (2008), A SIP Integrated Web Browser for HTTP Session Mobility and Multimedia Services, Unpublished Master’s thesis, University of Cape Town, South Africa.