Programming Jabber

Along Came Jabber

So Jeremie resolved to create a solution that had the following characteristics:

• It would have its own internal protocol, based upon XML.

• This protocol should be:

  • Simple to understand and implement

  • Easy to extend

  • Open

• The complexity of bridging the disparate proprietary IM protocols would remain at the server, each bridge being a plug-in module.

• All the clients would have to implement only the single, simple open protocol; everything else would be implemented at the server.

He called this solution “Jabber.”

The main architectural feature for Jabber that Jeremie strived for was that it should be simple enough for anyone to implement a Jabber server of his own. Unlike a centralized server environment, with all of the traffic routed through a central point, Jeremie envisioned that Jabber would be decentralized, allowing individuals, companies, and public organizations to run their own servers. This is particularly relevant for internal-only, IM-style corporate communications. Just as email servers are used to exchange mail using the Simple Mail Transport Protocol (SMTP), the Jabber servers are able to connect and exchange IM traffic whenever necessary. Figure P-1 illustrates Jabber’s distributed architecture, with two separate Jabber servers serving separate users.

Figure P-1. The distributed architecture of Jabber

Being open meant that Jabber could benefit from the help of anyone who wished to lend a hand, and administrators were empowered to be able to find and fix problems themselves if they so wished.

Being XML-based, as opposed to another binary format, for example, meant that the protocol streams were easy for humans to read, extensible, and readily integrated (a great range of XML parsing and construction tools is already available).

Being distributed meant that the Jabber system would belong to the people and that some of the scalability problems would be avoided. There remain some scalability issues, of course. Client-server communication that is TCP socket-based suffers from limitations of this technology. There are, however, initiatives to overcome these limitations with multiplexing techniques such as jpolld and dpsm (see http://download.jabber.org).

All of these features made for a good IM system design. But why stop at IM? Consider the client as an implementation of a simple protocol to exchange messages and presence information in XML structures and use plug-in services at the server, and what do you have? A language- and platform-agnostic XML routing framework.

Good grief, what a mouthful! This is why my response to “What is Jabber?” is usually just:

A really great technology!