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. [1]

Components, also known as modules or 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 method of which 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.

The former "library load" method and the STDIO method both 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 more components, in much the same way as an SAP R/3 system can exist as multiple instances, each instance running on a separate host and providing different services (dialog, update, enqueue, message, background, gateway, spool) according to configuration.

Would it surprise you to learn that the binding fluid that flows between the Jabber server and components (and ultimately of course between Jabber clients and components) is XML? Of course not. In fact, it's the same XML that flows between Jabber clients and servers. [2] The <message/>, <iq/> and <presence/> elements can all flow to and from components—how a component handles or generates these elements reflects the purpose of that component. As we saw in the imaginary conversation in Chapter 1, components can also be addressed in the same way that other Jabber entities can be addressed:

• As a whole, the JID is simply the name of the component, for example stocks.company-a.com;

• Using individual "users" as if they existed as separate entities within that component, for example MEGC@stocks.company-a.com;

A version of this imaginary conversation will become reality in Part II as we learn how to build our own components and attach them to the Jabber server.

Although components are addressed in the same way that clients are addressed, and the interaction is similar, there is one significant difference between writing or using a client (which could just as well be a stub connector for a service), and writing or using a component.

This difference is rooted in the Jabber server architecture and becomes clear when we consider the nature of how the components provide their services. Messages sent to a client entity that is not connected will be stored and forwarded to that entity the next time it connects and becomes available. This is beause the client's connection is inherently hosted, or managed, by the standard component that provides IM services such as availability handling and message queueing. This is the Jabber Session Manager (JSM) component. All clients are handled this way and automatically partake of these features. All entities that connect over a stream with the jabber:client namespace are considered clients, and their XML-based interaction is handled by the JSM.

Because other components connected to the Jabber server are themselves peer components to the JSM component, no availability or message queueing is available, as the JSM is only designed to handle client-connected entities. [3] To put it another way:

• Send a message to a client that's not connected and it will get stored until that client connects and becomes available again.

• Send a message to a component that's not connected, and an error will occur.

From a philosophical standpoint, this is fair enough, as you're trying to address a (temporarily) nonexistent feature of the server. From a practical standpoint, this is not usually a problem unless you're in the habit of bouncing your Jabber server to randomly connect or disconnect components.