Contents

Getting Started with Jabber

Introducing Jabber

This book is about Jabber: the technology, protocols, ideas, and the philosophy. Jabber is about connecting things (users, applications, and so on) in an all-pervasive message plasma that flows between clients and servers, carrying content, structure, and conversations.

The spirit of Jabber lies in its openness, its extensibility, and its lean but generic nature. That it finds itself in the midst of all that technology that will provide the backdrop to the dawn of the next-generation Internet is no accident. Web services, peer-to-peer, XML encapsulation, presence, identity, distributed computing — these are all phrases that describe key intiatives and developments that lie at the core of the coming transition, and Jabber can and does play a central role.

This book will show you how Jabber works, what makes it tick, and how to bend and shape it into solutions that join applications and users together. This first part is a guide to Jabber's technology and server. Part II is an examination of Jabber's building blocks and a series of scenarios and scripts we call "recipes," to show you how to deploy Jabber in a variety of situations.

Imaginary Jabber Conversation

To help you better understand what transpires during
a Jabber-based conversation, this section presents a conversation
between two friends, Jim and John, and two "assistant" applications at
their respective places of work.

Jim and John work at two different companies. Both of them invest in the
stock market, and they use a Jabber-based service to check and monitor
prices, to buy and sell shares, and to manage their portfolios. John's
company also has a workflow assistant that monitors incoming email and
coordinates work items between colleagues.

John decides to leave the mail until later and join the rest of his
colleagues in the meeting room.

There's a great deal we see in this imaginary, but not unlikely,
conversation:

There are human and application participants involved in this conversation; Jabber makes no distinction nor holds any prejudice

against either participant type.

XML is used effectively to segregate the conversational chunks (Jim's opening gambit, John's response, the price alert, and so on) and to structure and identify data within those chunks (the URL for the earnings story, the portfolio information, the conference room invitation).

Conversational strands are kept in context by use of a <thread/> tag, so that Jim and John's clients have a chance to present what's said in an appropriate way.

Each conversational chunk is a <presence/>, <message/>, or <iq/> tag—the three Jabber building blocks on which everything is based.

The conversation takes place across two Jabber servers; one server is located at company-a.com and the other at company-b.com.

The conversation flow is asynchronous, in the sense that out of nowhere, a message alerting John to a stock price fall below threshold appears seemingly in the middle of John's conversation with Jim, as does the message from the workassist agent.

All Jabber entities, human or otherwise, are identified by Jabber IDs such as John's (john@company-a.com) or the stock alert mechanism (alert@stocks.company-b.com).

company-b.com's stock system is multifaceted. As well as being able to send (and receive settings for) threshold alerts through the alert@stocks.company-b.com address, it can also interact using different identities to reflect the context of the stock being discussed. For example, MEGC@stocks.company-b.com represents the Megacorp (MEGC) stock.

In fact, this stock system is a Jabber component, a single entity that takes on each of the stock guises in the

conversation.
The most common misconception about Jabber is that it's solely for instant messaging—Jabber is more than a bridge to other IM systems or a set of protocols. Instant messaging is just one of countless ways that an XML-based messaging technology such as Jabber's can be applied. Jabber is an extensible client/server architecture that routes XML data between clients and services, which plug into Jabber servers as components. The original and core set of components provide the IM features (and supporting services) that were briefly described in the Preface.

The XML structures that make up the Jabber protocol fall into three
categories, each represented by a uniquely named top-level tag (also
referred to as an element). These tags don't necessarily carry
human-generated IM message content; as long as the resulting XML is
well-formed, anything goes. Furthermore, the Jabber protocol design
makes use of an XML feature that allows total flexibility of extension:
namespaces.

Note:

To prevent flooding of the server with large amounts of data,

there are mechanisms in place to "throttle" heavy connections. These
mechanisms can be configured in the server configuration, described in
Section 4.13.

Bearing this in mind, it's clear that Jabber can be deployed to

}} provide solutions far beyond the IM space as well as within it.

A Simple Script

Before moving on, let's have a look at how
simple it is to interact with Jabber. Example 1-1 shows a simple Perl
script that connects to a Jabber server, authenticates, checks who's
online, and sends those people a reminder message. It uses the
Net::Jabber library, which provides a high-level API to many
Jabber-related functions such as handling the connection to the server
(this is via another library that Net::Jabber
uses—XML::Stream), authentication, events, and all the
mechanisms to parse and create Jabber traffic.

} }} The script is fairly self-explanatory. For now, we'll leave the
} }} script's description to the comments embedded within it; by the end
} }} of the book, you should have a good understanding of how to put
} }} together complete applications and utilities using Jabber libraries
} }} in Perl, Python, and Java.