Jim and John work at two different companies, and are both interested in stocks and shares, using Jabber-based services to check and monitor prices, buy stock and manage their portfolios. There's a workflow assistant at John's company that can do things like monitor incoming email and coordinate work items between colleagues.
Jim sends a quick chat message to John:
<message type='chat' from='jim@company-a.com/home'
to='john@company-b.com'>
<thread>01</thread>
<body>Hey John, you seen the latest story on Megacorp earnings?</body>
</message>John responds:
<message type='chat' to='jim@company-a.com/home'
from='john@company-b.com/Desk'>
<thread>01</thread>
<body>No, where is it?</body>
</message>Jim sends John the URL:
<message type='chat' from='jim@company-a.com/home'
to='john@company-b.com/Desk'>
<thread>01</thread>
<body>Here's the link</body>
<x xmlns='jabber:x:oob'>
<url>http://www.megacorp.co.uk/earnings3q.html</url>
<desc>Third Quarter Earnings for Megacorp</desc>
</x>
</message>John receives an alert about the price of ACME Holdings (ACMH) falling below a threshold he previously set:
<message to='john@company-b.com' from='alert@stocks.company-b.com'> <subject>ACMH Fallen below 250p</subject> <body>ACME Holdings stock price 248p as at 10:20am today</body> </message>
He checks the price of Megacorp stock (MEGC) by sending an empty message to the stock and shares assistant application:
<message type='chat' to='MEGC@stocks.company-b.com'
from='john@company-b.com/Desk>
<thread>T20</thread>
</message>In reply, the stocks and shares assistant application sends the required information:
<message type='chat' from='MEGC@stocks.company-b.com'
to='john@company-b.com/Desk'>
<thread>T20</thread>
<subject>MEGC Current Price</subject>
<body>
Megacorp stock price 1287p at 10:25am today
</body>
</message>John likes the price and decides to buy 100 more shares:
<message type='chat' to='MEGC@stocks.company-b.com'
from='john@company-b.com/Desk'>
<thread>T20</thread>
<body>buy 100 at 1287 now</body>
</message>He sends a message to Jim telling him of his new investment. Jim checks his own portfolio:
<iq type='get' to='portfolio.company-a.com'
id='port_01'
from='jim@company-a.com/home'>
<query xmlns='jabber:iq:browse'/>
</iq>He sees that he already holds 1200 Megacorp shares, and decides against buying any more:
<iq type='result' from='portfolio.company-a.com'
id='port_01'
to='jim@company-a.com/home'>
<portfolio xmlns='jabber:iq:browse' type='personal'
jid='jim@portfolio.company-a.com'>
<stock type='standard' name='Megacorp'
jid='MEGC@portfolio.company-a.com' holding='1200'/>
<stock type='standard' name='ACME Holdings'
jid='ACMH@portfolio.company-a.com' holding='500'/>
</portfolio>
</iq>Workassist, the workflow assistant application, sends John a notification of an important email:
<message from='workassist@company-b.com'>
<subject>New mail from: Alastair B</subject>
<body>
You have a new mail waiting; details are as follows:
Subject: Incident last week
From: Alastair B
</body>
</message>He also receives an invite to a meeting:
<message from='joanne@company-b.com/laptop'>
<body>
Hey John, you're supposed to be helping us decide where to hold
this year's Christmas party!
</body>
<x xmlns='jabber:x:conference' jid='room2@meeting.company-b.com'/>
</message>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 stock 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's and John's clients have a chance to present what's said in an appropriate way.
Each conversational chunk is either a <message/> or a <iq/> tag - two of the three Jabber building blocks (<message/>, <iq/> and <presence/>) on which everything is based.
The conversation takes place across two Jabber servers - the one 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 multi-faceted. 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.
This stock system is in fact a Jabber component, a single element which takes on each of the stock guises in the conversation.
Jabber is a set of protocols, a technology, a system that is extremely capable of providing IM facilities, including bridging services to other IM systems.
But it is capable of much more than that. Paring down what Jabber is to its bare essentials, what do we have? An extensible client-server architecture in which XML can be exchanged, be routed, between clients and services that plug in as components to the Jabber server. The original and core set of components provide the IM features (and supporting services) that were briefly described in the Preface; the current 'off-the-shelf' Jabber clients are generally orientated towards IM.
But of course, IM is just one of countless domains to which XML-based messaging technology such as Jabber's can be applied.
As we'll learn, 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). But these tags mustn't necessarily carry human-generated IM message content—as long as the resulting XML is well-formed, anything goes. [1] Furthermore, the Jabber protocol design makes use of an XML feature that allows total flexibility of extention: Namespaces.
Bearing this in mind, it's clear that Jabber can be deployed to provide solutions outside the IM space as well as within it.
| [1] | 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 the section called io Section in Chapter 4. |