Google Wave Protocols: Clearing the Confusion

Today is the long-awaited day when 100,000 lucky individuals receive access to an early, but working, version of Google Wave. I hope I am in those ranks! Like many people, I have been reading about Wave, but have not been able to experience it hands-on.

Wave has been a hot topic since it was first shown outside of Google last May. Yet it continues to be quite misunderstood, most likely because it is such an early stage effort and most interested people have not been able to lay hands on the technology.

The confusion surrounding Wave was highlighted for me yesterday in a Twitter exchange on the topic. It all started innocently enough, when Andy McAfee asked:

To which I replied:

That statement elicited the following comment from Jevon MacDonald of the Dachis Group:

I am not a technologist. I seek to understand technology well enough that I can explain it in layman’s terms to business people, so they understand how technology can help them achieve their business goals. So I generally avoid getting into deep technical discussions. This time, however, I was pretty sure that I was on solid ground, so the conversation between me and Jevon continued:

Now, here we are, at the promised blog post. But, how can Jevon and I both be correct? Simple. Google Wave encompasses not one, but several protocols for communication between system components, as illustrated in the figure below.

Figure 1: Google Wave Protocols (Source: J. Aaron Farr, http://www.cubiclemuses.com/cm/articles/2009/08/09/waves-web-of-protocols/)

The most discussed of these is the Google Wave Federation protocol, which is an extension of the Extensible Messaging and Presence Protocol (XMPP). However, Wave also requires protocols for client-server and robot server- (Web service) Wave server communication. It is also possible, but probably not desirable, for Wave to utilize a client-client protocol.

Jevon was absolutely correct about the XMPP protocol enabling server-server communication in the Google Wave Federation Protocol. The Draft Protocol Specification for the Google Wave Federation Protocol lays out the technical details, which I will not explore here. XMPP provides a reliable mechanism for server-server communication and is a logical choice for that function in Google Wave, because XMPP was originally designed to transmit instant message and presence data.

It turns out that the Google Wave team has not defined a specific protocol to be used in client-server communication. A Google whitepaper entitled Google Wave Data Model and Client-Server Protocol does not mention a specific protocol. The absence of a required or recommended protocol is also confirmed by this blog post. While the Google implementation of Wave does employ HTTP as the client-server protocol, as Jevon stated, it is possible to use XMPP as the basis for client-server communication, as I maintained. ProcessOne demonstrates this use of XMPP in this blog post and demo.

Finally, there is no technical reason that XMPP could not be used to route communications directly from one client to another. However, it would not be desirable to communicate between more than two clients via XMPP. Without a server somewhere in the implementation, Wave would be unable to coordinate message state between multiple clients. In plain English, the Wave clients most likely would not be synchronized, so each would display a different point in the conversation encapsulated in the Wave.

To summarize, Google Wave employs the following protocols:

• XMPP for server-server communication
• HTTP for client-server communication in the current Google implementation; XMPP is possible, as demonstrated by ProcessOne
• HTTP (JSON RPC) for robot server-Wave server communication in the current Google implementation
• Client-client protocol is not defined, as this mode of communication is most likely not usable in a Wave

I hope this post clarifies the protocols used in the current architecture of Google Wave for you. More importantly, I hope that it highlights just how much additional architectural definition needs to take place before Wave is ready for use by the masses. If I had a second chance to address Andy McAfee’s question, I would unequivocally state that Google Wave is a “concept car” at this point in time.

Postscript: The heretofore mentioned possibilities around XMPP as a client-client protocol are truly revolutionary. The use of XMPP as the primary communication protocol for the Internet, instead of the currently used HTTP protocol, would create a next generation Internet in which centralized servers would no longer serve as intermediaries between users. Web application architectures, even business models, would be changed. See this post for a more detailed explanation of this vision, which requires each user to run a personal server on their computing device.

Thought of the Day: September 17, 2009

Social functionality is best deployed when embedded in other applications and systems, not as social suites or platforms. Most organizations don’t realize that yet, but they will, once they experience the disconnect they’ve created between collaboration, content, and process applications.

Enterprise 2.0 is Neither a Crock Nor the Entire Solution

Dennis Howlett has once again started a useful and important debate, this time with his Irregular Enterprise blog post entitled Enterprise 2.0: what a crock. While I am sympathetic to some of the thinking he expressed, I felt the need to address one point Dennis raised and a question he asked.

I very much agree with this statement by Dennis:

“Like it or not, large enterprises – the big name brands – have to work in structures and hierarchies…”

However, I strongly disagree with his related contention (“the Big Lie” as he terms it) that:

“Enterprise 2.0 pre-supposes that you can upend hierarchies for the benefit of all.“

Dennis also posed a question that probably echoes what many business leaders are asking:

“In the meantime, can someone explain to me the problem Enterprise 2.0 is trying to solve?“

Below is the comment that I left on Dennis’ blog. It begins to answer the final question he asked and address my disagreement with his contention that Enterprise 2.0 advocates seek to create anarchy. Is my vision for the co-existence of structured and recombinant organizational and work models clear and understandable? Reasonable and viable? If not, I will expand my thoughts in a future post. Please let me know what you think.

Enterprise 2.0 is trying to solve a couple levels of problems.

From a technology standpoint, E2.0 is addressing the failure of existing enterprise systems to provide users with a way to work through exceptions in defined business processes during their execution. E2.0 technology does this by helping the user identify and communicate with those who can help deal with the issue; it also creates a discoverable record of the solution for someone facing a similar issue in the future.

From a organizational and cultural perspective, E2.0 is defining a way of operating for companies that reflects the way work is actually accomplished — by peer-to-peer interaction, not through command and control hierarchy. Contrary to your view, E2.0 does not pre-suppose the destruction of hierarchy. Correctly implemented (philosophy and technology), E2.0 provides management a view of the company that is complementary to the organization chart.

Addendum: See this previous post for more of my perspective on the relationship of structured and ad hoc methods of working.