The exchange and distribution of information in real world scenarios requires more than a synchronous (sequenced) request/response framework. In IM, people originate chat messages in a spontaneous and unpredictable manner (especially if there's alcohol involved). In a loose network of independent applications, messages originate on a similar 'random' event basis. This asynchronous activity requires a design equally asynchronous in nature—and that is what Jabber has.
To allow for the generation—and more importantly the receipt—of messages in an asynchronous fashion, Jabber's programming model for client and server alike is an event-based one. An event-based programming model is nothing to be afraid of. In simple terms it's just a loop that iterates either doing nothing in particular or doing something regularly (like checking for user input and acting upon it if required) while waiting for something—an event—to happen. In Jabber's case, it will be the receipt of an XML fragment. Depending on what type of fragment it is, a handler will be called to deal with that fragment. We saw a simple example of this in the Perl script in Chapter 1.
In all but the simplest deployment examples of Jabber, the event model pervades. We will see the model in action in Part II. And while we've reduced the receipt of chat messages to a rather dry and generic event idea, let's also look at some concepts that often go hand in hand with event-based messaging systems.
Depending on circumstances, if you send a message to someone who's not currently connected, that message will be held and passed to the recipient when he does connect.
Likewise, in the wider context of application to application (A2A) or application to person (A2P) messaging, this store and forward concept is often useful in non-time-critical situations, such as a centralized logging mechanism where the log-writing component might be temporarily unavailable, or a workflow scenario where an application passes a message to a supervisor for approval (in this case, the message would be similar to an email).
Indeed, in the case of the recipient being offline and messages being handled by a store and forward mechanism, or simply where the recipient cannot handle the messages as fast as they arrive, the nature of the XML stream in which these message fragments are transmitted (see Chapter 5 for details) means that the messages are naturally queued, to be handled in the order that they arrive.
In many cases, it's not much use sending a message to an application, and have it queued or stored offline, without having an idea of whether the recipient actually did (eventually) receive and handle it. Jabber supports the concept of message receipt, whereby the sender can request an acknowledgment of receipt from the recipient. This request is sent along with the message itself. We'll see message receipt in action in the recipes in Part II.