Instant Messaging with Jabber

Jun. 20, 2002 12:00 AM

Of all of the possible technologies to arise out of the first consumer Internet revolution, instant messaging (IM) is a bit of an enigma. Its incredible popularity challenges that of the Internet's first "killer app," e-mail, yet it does so mostly by offering the features of e-mail in a slightly different package.

At the core of any IM system lies the capacity to rapidly send a message from one client to another. The second most important feature in an IM system is the capacity to recognize when certain users of the system have become available. When these two features are put together, it becomes possible to send messages rapidly to a target and be reasonably certain that the target is available to receive them. In contrast, with e-mail there is no guarantee of when, if ever, the target will choose to receive a message. Providing many of the desirable features of wireless paging and e-mail, IM would seem a silver bullet in an enterprise's messaging infrastructure.

Three important hurdles have impeded the progress of enterprise IM: lack of standards, security, and the ability to readily integrate enterprise applications into an IM framework.

Knocking Down the Hurdles
As has often been the case with computing infrastructure over the last decade, the development community has come together to generate an open standard protocol for IM. The name of that protocol, appropriately enough, is Jabber. A nearly complete change from the proprietary IM protocols of companies like ICQ, AOL, and Yahoo, Jabber's unique design strategy is well designed for use in the enterprise world. Here are the reasons:

Jabber is an open standard: The DTDs defining the Jabber protocol are available to anyone wishing to read them, allowing anyone access to an understanding of the protocol. The Jabber Software Foundation has recently applied to the ITEF to have Jabber considered for an Informational RFC, which provides additional public access to the protocol.

Jabber is an XML protocol: Not only does this ensure that the Jabber protocol is platform independent, it also facilitates the rapid development of both client and server technology. An XML-based protocol has a leg up on other protocols in that there's no need to parse a data stream for unique tokens - all that's needed is an XML parser. This has caused a wide proliferation of Jabber API libraries in languages like Java, Perl, and .NET.

Much like SOAP, Jabber is agnostic about underlying protocols used to transport it: Jabber will function well via any transport that provides data in a stream. The current preferred way to do this is via plain TCP/IP sockets, but SSL sockets and other stream techniques are becoming popular.

Jabber has provisions for security available: Not only does Jabber allow for transport-level encryption, but the Jabber protocol also supports digital signatures and encryption using PGP (Pretty Good Privacy) and can protect passwords using SHA1 (Secure Hash Algorithm v. 1.0).

Of all of the features listed, possibly the most important of these is the fact that Jabber is an XML protocol. This carries with it the benefits so common to XML, though it's the extensibility available in Jabber that makes it so successful. The Jabber protocol is rich in features implemented in unique namespaces, but there's no requirement that these "extension namespaces" be implemented by a client. In fact, there are only three simple tag structures that must be handled by a client to have a basic session with the server, though an implementation of a few extension namespaces can give a client some important bells and whistles.

Even more important than Jabber's liberal approach to protocol conformance is the fact that a session with a Jabber server is essentially the exchange of two XML documents: one of the client's data sent to the server, and one of the server's data sent to the client. The transformability of XML gives developers an advantage in converting XML documents to Jabber as well as packets in the Jabber protocol into other IM protocols. Jabber "transports" can give clients the ability to freely communicate over multiple IM networks at the same time. The XML basis for Jabber also allows developers to start with the Jabber protocol as the basis for their own messaging solution and then extend it to accommodate their specific needs.

Developers Flout Tradition
Developers within the Jabber community are also offering an interesting twist on traditional IM concepts - developing automated information services that act like ordinary clients. Multiple methods exist for integrating applications into a Jabber IM network, including Jabber server-side components and the increasingly popular "bots." The applications available range from simple Perl scripts that rotate Web page graphics to Jogger (http://jogger.jabber.org), a Web journal that accepts entries via Jabber messages.

How It All Works
All communication in Jabber is broken down into discrete chunks called packets. Each packet is an XML element. The core protocol of Jabber is broken down into three packet types: Message, Presence, and a "utility type" known as Info/Query (IQ). The first two of these packet types are fairly intuitive as they're responsible for implementing the two fundamental features of IM. IQ packets provide the final piece of the puzzle by allowing client programs to communicate to the server and each other via a series of "get" and "set" operations. The structure of each query is left to extension namespaces, making IQ an effective wrapper for every action from a client's authentication to the management of the client's roster (also called a "buddy list") to negotiation of file transfers and the Jabber implementation of XML-RPC. The three packet types are defined as children of a single element called the Stream element, which also serves as the root element of the entire session. When the Stream element closes, the document has been completed and the session dies.

Putting it all together, Jabber provides everything needed for a wide array of possible IM activities. Here's how the three different packet types working together allow a client to interact with the world.

After connecting a socket to the Jabber server, the client begins the session by opening the stream:

<?xml version="1.0" encoding= "UTF-8" ?>
<stream:streamto="jabber.org"
xmlns="jabber:client"
xmlns:stream="http://etherx.jabber.org/streams">

The server, in recognition, sends back a similar response, allowing the server/client XML stream to begin. Now the client must authenticate itself with the server:

<iq type="set" id="1">
<query xmlns="jabber:iq:auth">
<username>foobar</username>
<password>murple</password>
<resource>Winjab</resource>
</query>
</iq>

Notice the ID attribute in this packet. This attribute is useful in synchronizing server responses to client packets, which may be (and often are) asynchronous. If the authentication credentials are valid, the server sends back a response confirming the authentication:

If the authorization failed, the server would send back an IQ of type "error" and additional information explaining the reason for the error. Errors are generally reported using an error code standard similar to that of HTTP.

The client is now ready to begin performing IM operations by announcing its presence to the server, which broadcasts the statement of availability to all interested parties:

At this point the client is visible as being "available" on the system, and it's free to do as it (or its user) wishes. The finer points of what a client can do on Jabber is a topic that's well beyond the scope of this article, but I'll briefly illustrate sending a message.

Let's say that this user (foobar@jabber.org) wanted to send a message to an old friend of his (duncan@jabber.org). His client would formulate the following packet:

<message id="3" to="duncan@jabber.org">
<subject>Dinner</subject>
<body>Don't forget we're
having the XML-Journal editors over
for dinner tonight!</body>
</message>

Once done with his Jabber session, the user of the client would opt to disconnect, and the client would gracefully bow out by ending its stream to the server:

</stream:stream>

Upon seeing the stream ended by the terminating tag, the server likewise ends the client's stream and notifies interested parties that the client has become unavailable. Both sides then close their sockets.

Getting a Feel for It
Probably the best way to get a feel for Jabber is to be a user. JabberCentral (www.jabbercentral.com) maintains an extensive list of Jabber clients. Just grab an appealing one, use it to register an account on a free server such as Jabber.org, and become acquainted with what's out there in the world of Jabber. Those considering becoming client developers should also explore what API libraries are at their disposal. The Jabber project's Web site (www.jabber.org), as well as JabberCentral, contains links to many API libraries.

Starting your own Jabber IM system at home or work is easy. JabberCentral lists several vendors that are offering Jabber servers for all major platforms. There is also an open source Jabber server available for download at the Jabber project's Web site. It comes with installation documentation, and is designed to be easily built on UNIX operating systems. While each Jabber server implementation has its own installation process, one thing is nearly universal: installation of any Jabber server is quite easy. The Jabber server available from the Jabber project homepage is by far the most hands-on, and after installing a build of the server, the only necessary configuration step is to specify some host name information in the jabber.xml configuration file.

The time is definitely here for Jabber to begin taking its place alongside other open standard XML protocols like SOAP. Next time you consider a messaging solution, consider what Jabber may hold in store for you.

SIDEBAR
Jabber on Its Way
Since its inception in 1998, Jabber has been making the slow push toward providing a complete open standard for IM. With the backing of IBM and Hitachi and with three books regarding Jabber development in print, the community is beginning to rally behind Jabber as a standard for IM in much the same fashion as the community has rallied behind HTTP, XML, and SOAP. Jabber is definitely here to stay, and its popularity is on the rise precisely because it effectively tackles the issue of standardization. Commercial Jabber servers, each offering unique features like wireless gateways, have emerged to serve enterprise messaging solutions markets.

About J. Rhett Aultman