oreilly.comSafari Books Online.Conferences.
Articles Radar Books  

XML Messaging with Jabber

by Peter Saint-Andre

Discussions of XML can often seem dry, abstract, and even hopelessly arcane. (Have you read the XML Schema spec lately?) So it can be refreshing to look at a powerful (even fun) application that's built on XML. One such application is Jabber, an open source instant messaging and presence system that is beginning to garner a lot of attention from the open source community and large corporations alike.

Eric S. Raymond's first lesson of open source software development declares that "Every good work of software starts by scratching a developer's personal itch." That was certainly the case with Jabber. Jeremie Miller, the founder of the Jabber.org project, got sick of using four or five applications to keep in touch with friends on different instant messaging (IM) systems and to monitor various IRC channels. So he started to think about building a cross-platform, open source IM system that would speak to all the other messaging systems.

From the beginning of the project in early 1998, Jeremie resolved that Jabber would stand apart from existing IM systems by being based on a foundation of XML. Indeed, XML is not an afterthought or a cool buzzword in the Jabber world, but, as we shall see, simply the way things are done.

The basic architecture of Jabber is extremely similar to that of e-mail: there is a network of distributed servers, with a user connecting to their host server and servers transferring messages through one or more hops to a destination server for delivery to the intended recipient. From the perspective of the user, Jabber IDs are identical in form to e-mail addresses (in my case stpeter@jabber.com), and one registers with a Jabber server in much the same way that one creates an account with an ISP.

Related Articles:

Jabber Works: Here's How

Peer-to-Peer Makes the Internet Interesting Again

News -- view a week's worth of Jabber news via Meerkat.

More from the P2P DevCenter Previous Features

The server perspective is somewhat more complicated -- and in fact, this is intentional, because the relative complexity of the server offloads responsibility from the clients, thus making it easy to write Jabber clients for a wide variety of platforms. In essence, however, the server is made of two basic components: the core Jabber libraries and optional "transports."

The core libraries handle communications within the Jabber system. An example is when I send a message from my Jabber account to a friend who is also using Jabber. In this case, all the messaging occurs in the format of the Jabber's open XML protocol, so the communications are "native" to Jabber. Although there is a lot of code that makes this happen, in a way it is relatively simple.

The transports translate Jabber XML into and out of what we might think of as "foreign" protocols. An example is when I chat with a friend who's using another instant messaging system (such as AIM, ICQ, or MSN). Another example would be when I use Jabber's groupchat facilities to join an IRC channel, as shown below:

IRC over Jabber

Jabber screen shot.

IRC over Jabber.

It's in the world of transports that some of the "black magic" of Jabber comes into play, especially when the foreign protocol is not well-documented. When you use Jabber to connect to non-Jabber systems, it is as if the relevant transport is "masquerading" as you on the foreign system. When you register with the transport, you tell it about your user information on the foreign system, and in the future it acts on your behalf with that system, sending and receiving messages and presence information in that foreign protocol. The result is that your friends on (let's say) ICQ think they're communicating with you on ICQ when in fact you are using Jabber, and specifically Jabber's ICQ transport, to speak the language of ICQ. In this way Jabber is somewhat like a universal translator, although at present Jabber is not "universal," since transports do not yet exist for all messaging systems. (And no, we won't get into the politics of interoperability in this article!)

Pages: 1, 2, 3

Next Pagearrow

P2P Weblogs

Richard Koman Richard Koman's Weblog
Supreme Court Decides Unanimously Against Grokster
Updating as we go. Supremes have ruled 9-0 in favor of the studios in MGM v Grokster. But does the decision have wider import? Is it a death knell for tech? It's starting to look like the answer is no. (Jun 27, 2005)

> More from O'Reilly Developer Weblogs

More Weblogs
FolderShare remote computer search: better privacy than Google Desktop? [Sid Steward]

Data Condoms: Solutions for Private, Remote Search Indexes [Sid Steward]

Behold! Google the darknet/p2p search engine! [Sid Steward]

Open Source & The Fallacy Of Composition [Spencer Critchley]