Jeremie Miller started the Jabber project in early 1998 and it was announced to the public in January 1999. To understand why Jabber came about, and in the form it took, let's look briefly at what existed in the IM world before Jabber.
IM existed as a concept and a handful of systems from companies such as Mirabilis, AOL, Microsoft and Yahoo!. These systems (ICQ from Mirabilis, AIM from AOL, MSN from Microsoft, and Yahoo!IM from Yahoo!) allowed their users to chat to one another and avail themselves of IM-related services. However, an AIM user couldn't chat with an ICQ user, and MSN users couldn't interact with Yahoo!IM users. Each system was effectively closed to the outside world.
Furthermore, the protocols that these systems used were also closed —proprietary—which meant it was difficult to find clients for these IM systems other than the ones supplied by the IM system owner.
Finally, the systems themselves were monolithic: multiple clients but a single server (or server farm). Although the companies were able to invest time and money into the problem, the fact remained that a monolithic architecture presented a scaling problem. Perhaps more relevant than that, companies who wanted to use IM services internally had to accept the fact that the conversations would be carried through the systems of a third party—namely the owners of these public IM systems. This was no more desirable than for a company to run their internal email using a public email service such as Hotmail.
Of course, these systems did have their advantages. The clients were accomplished and easy to learn and use; and as long as your correspondents were using the same IM system, and you didn't mind your messages being carried by another organization (for private individuals these wouldn't be unique circumstances; again, we are led to the email services parallel) then you could leave the system management to someone else and get on with chatting.
Having all your contacts use the same IM system is all well and good in theory, but in practice is rarely the case. (If, like me, you have few friends, then this is not so much of a problem). Jeremie Miller had correspondents in different IM systems, and consequently had to have different IM clients running on his desktop to keep up with them all. Many great software projects stem from a personal "itch" that someone wanted to scratch. This was the primary itch that Jeremie had. A single client for all IM interaction: panacea.
Of course, one obvious solution would be to build a single client that supported all of the IM system protocols, but this approach had two drawbacks:
The proprietary nature of the protocols made it harder to implement the support required and would make the client overly complicated.
Every time the protocol, which wasn't under his control, changed, or a new one came along, the client would have to be modified—a task not practical for a large user base.
On top of that, GUI programming isn't everyone's cup of tea, and Jeremie preferred a solution that allowed him to concentrate on the underlying problems at hand and let others build the GUIs.
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 only have to implement the single, simple internal protocol; everything else would be implemented at the server.
He called this solution "Jabber."
At the same time, perhaps because he didn't consider himself a large organization with the resources to run a centralized server service, this architecture feature was fundamental:
Anyone could implement a server of their own.
In the same way that email is not a centralized service— each mail user has an address that corresponds to where their mailbox is held—the system that Jeremie envisioned was a decentralized one. This meant that individuals, companies and public organizations could run their own servers—especially relevant for internal-only, IM-style corporate communication. Just as email servers exchange mail using Simple Mail Transfer Protocol (SMTP), so the Jabber servers would connect and exchange IM traffic when necessary.
Figure 1-1. The Distributed Architecture of Jabber
+--------+
| Jabber |
| client | +--------+
+--------+ | Jabber |
| | server | +....................+
+------ | | : :
| | : Internet :
+--------+ : :
| : :
+--------: :-------+
: : |
: : +--------+
: : | Jabber |
+....................+ | server |
| | -----+
| | |
+--------+ +--------+
| Jabber |
| client |
+--------+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 some other binary format for example, meant that the protocol streams were easy for humans to read, extensible, and readily integrated (there is a great range of XML parsing and construction tools already available).
Being distributed meant that the Jabber system would belong to the people, and that some of the scalability problems would be avoided. [1]
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!
| [1] | 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. |