Programming Jabber

Component/Service Architecture

The original problem for Jabber to solve was to provide bridges to different IM systems; the upshot of the solution was a server design that is ultimately as flexible as the imagination allows. Each of the IM bridges, or transports as they are often called, is a pluggable component; the Jabber server architecture, examined in detail in Chapter 4, is a component-based architecture. The standard Jabber server distribution comes with the components required to provide IM services, data storage, and server-to-server communication, for example. Each component is separately configurable and is made known to the server through the inclusion of that configuration into the main configuration structure.^[2]

Components, also known as services, can be, to a large extent, platform agnostic. There are different methods by which components can connect to and interact with the Jabber server. One of these methods uses low-level Jabber library functions (in C) to bind the component (built in the form of a shared library) to the server. The other methods use either standard I/O (STDIO) in a process-spawning mechanism or TCP sockets.

Both the former library load method and the STDIO method require that the component runs on the same host as the Jabber server itself; this isn’t in fact as restrictive as it sounds. As you’ll find out in Chapter 4, it is possible to run multiple “instances” of a Jabber server across different hosts, each instance containing one or ...