JabChapter 1
From WikiContent
(→Imaginary Jabber Conversation) |
|||
| Line 1: | Line 1: | ||
<br> | <br> | ||
| - | =Getting Started with Jabber= | + | =Getting Started with Jabber= |
| - | <br> | + | <br> |
| + | ==Introducing Jabber== | ||
| + | <br>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. <br> | ||
| - | + | 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. | ||
| + | <br> ==Imaginary Jabber Conversation== | ||
| + | <br>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. | |
| - | 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. | + | |
Jim is notified that John is available: | Jim is notified that John is available: | ||
| - | <Code>|<presence from='john@company-b.com/Desk' to='jim@company-a.com/home'> <status>Online</status> <priority>2</priority> </presence> </code> | + | <Code>|<presence from='john@company-b.com/Desk' |
| + | to='jim@company-a.com/home'> <status>Online</status> | ||
| + | <priority>2</priority> </presence> </code> | ||
| Line 25: | Line 46: | ||
| - | + | <code>|<message type='chat' from='jim@company-a.com/home' | |
| + | to='john@company-b.com'> <thread>01</thread> | ||
| + | <body><tt>Hey John, have you seen the latest story on Megacorp | ||
| + | earnings?</tt></body> </message></code> | ||
| Line 31: | Line 55: | ||
| - | + | <code>|<message type='chat' to='jim@company-a.com/home' | |
| + | from='john@company-b.com/Desk'> <thread>01</thread> | ||
| + | <body><tt>No, where is it?</tt></body> | ||
| + | </message></code> | ||
| Line 37: | Line 64: | ||
| - | + | <code>|<message type='chat' from='jim@company-a.com/home' | |
| + | to='john@company-b.com/Desk'> <thread>01</thread> | ||
| + | <body><tt>Here's the link</tt></body> <x | ||
| + | xmlns='jabber:x:oob'> | ||
| + | <url><tt>http://www.megacorp.co.uk/earnings3q.html</tt></url> | ||
| + | ; <desc><tt>Third Quarter Earnings for Megacorp</tt></desc> | ||
| + | </x> </message></code> | ||
| - | John receives an alert about the price of ACME Holdings (ACMH) falling below a threshold he previously set: | + | John receives an alert about the price of ACME Holdings (ACMH) falling |
| + | below a threshold he previously set: | ||
| - | + | <code>|<message to='john@company-b.com' | |
| + | from='alert@stocks.company-b.com'> <subject><tt>ACMH Fallen | ||
| + | below 250p</tt></subject> <body><tt>ACME Holdings price 248p | ||
| + | as at 10:20am today</tt></body> </message> </code> | ||
| - | He checks the price of Megacorp stock (MEGC) by sending an empty message to the shares assistant application: | + | He checks the price of Megacorp stock (MEGC) by sending an empty message |
| + | to the shares assistant application: | ||
| - | + | <code>|<message type='chat' to='MEGC@stocks.company-b.com' | |
| + | from='john@company-b.com/Desk'> <thread>T20</thread> | ||
| + | </message> </code> | ||
| - | In reply, the shares assistant application sends the required information: | + | In reply, the shares assistant application sends the required |
| + | information: | ||
| - | + | <code>|<message type='chat' from='MEGC@stocks.company-b.com' | |
| + | to='john@company-b.com/Desk'> <thread>T20</thread> | ||
| + | <subject><tt>MEGC Current Price</tt></subject> <body> | ||
| + | <tt>Megacorp price 1287p at 10:25am today</tt> </body> | ||
| + | </message> </code> | ||
| Line 61: | Line 106: | ||
| - | + | <code>|<message type='chat' to='MEGC@stocks.company-b.com' | |
| + | from='john@company-b.com/Desk'> <thread>T20</thread> | ||
| + | <body><tt>Buy 100 at 1287 now</tt></body> </message> | ||
| + | </code> | ||
| - | He sends a message to Jim telling him of his new investment. Jim checks his own portfolio: | + | He sends a message to Jim telling him of his new investment. Jim checks |
| + | his own portfolio: | ||
| - | + | <code>|<iq type='get' to='portfolio.company-a.com' id='port_01' | |
| + | from='jim@company-a.com/home'> <query | ||
| + | xmlns='jabber:iq:browse'/> </iq> </code> | ||
| - | He sees that he already holds 1200 Megacorp shares and decides against buying any more: | + | He sees that he already holds 1200 Megacorp shares and decides against |
| + | buying any more: | ||
| - | + | <code>|<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> </code> | ||
| - | The workflow assistant application, ''workassist'', sends John a notice that he's received an important email: | + | The workflow assistant application, ''workassist'', sends John a notice |
| + | that he's received an important email: | ||
| - | + | <code>|<message from='workassist@company-b.com' | |
| + | to='john@company-b.com/Desk'> <subject><tt>New mail from: | ||
| + | Alastair B</tt></subject> <body> <tt>You have a new mail | ||
| + | waiting; details are as follows: Subject: Incident last week From: | ||
| + | Alastair B </tt></body> </message> </code> | ||
| Line 85: | Line 148: | ||
| - | + | <code>|<message from='joanne@company-b.com/laptop' | |
| + | to='john@company-b.com/Desk'> <body> <tt>Hey John, you're | ||
| + | supposed to be helping us decide where to hold this year's Christmas | ||
| + | party! </tt></body> <x xmlns='jabber:x:conference' | ||
| + | jid='room2@meeting.company-b.com'/> </message> </code> | ||
| - | John decides to leave the mail until later and join the rest of his colleagues in the meeting room. | + | 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'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. <br> | + | * There are human and application participants involved in this |
| - | * 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 <tt><thread/></tt> tag, so that Jim and John's clients have a chance to present what's said in an appropriate way. <br> | + | conversation; Jabber makes no distinction nor holds any prejudice |
| - | * Each conversational chunk is a <tt><presence/></tt>, <tt><message/></tt>, or <tt><iq/></tt> tag—the three Jabber building blocks on which everything is based. <br> | + | against either participant type. <br> |
| - | * The conversation takes place across two Jabber servers; one server is located at <tt>company-a.com</tt> and the other at <tt>company-b.com</tt>. * 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. <br> | + | * XML is used effectively to |
| - | * All Jabber entities, human or otherwise, are identified by Jabber IDs such as John's (<tt>john@company-a.com</tt>) or the stock alert mechanism (<tt>alert@stocks.company-b.com</tt>). * <tt>company-b.com</tt>'s stock system is multifaceted. As well as being able to send (and receive settings for) threshold alerts through the <tt>alert@stocks.company-b.com</tt> address, it can also interact using different identities to reflect the context of the stock being discussed. For example, <tt>MEGC@stocks.company-b.com</tt> represents the Megacorp (MEGC) stock.<br> | + | segregate the conversational chunks (Jim's opening gambit, John's |
| - | * 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.<br> | + | 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). <br> | ||
| + | * Conversational strands | ||
| + | are kept in context by use of a <tt><thread/></tt> tag, so that | ||
| + | Jim and John's clients have a chance to present what's said in an | ||
| + | appropriate way. <br> | ||
| + | * Each conversational chunk is a | ||
| + | <tt><presence/></tt>, <tt><message/></tt>, or | ||
| + | <tt><iq/></tt> tag—the three Jabber building blocks on which | ||
| + | everything is based. <br> | ||
| + | * The conversation takes place across two | ||
| + | Jabber servers; one server is located at <tt>company-a.com</tt> and the | ||
| + | other at <tt>company-b.com</tt>. | ||
| + | * 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. <br> | ||
| + | * All Jabber entities, human or otherwise, | ||
| + | are identified by Jabber IDs such as John's | ||
| + | (<tt>john@company-a.com</tt>) or the stock alert mechanism | ||
| + | (<tt>alert@stocks.company-b.com</tt>). | ||
| + | * <tt>company-b.com</tt>'s stock | ||
| + | system is multifaceted. As well as being able to send (and receive | ||
| + | settings for) threshold alerts through the | ||
| + | <tt>alert@stocks.company-b.com</tt> address, it can also interact using | ||
| + | different identities to reflect the context of the stock being | ||
| + | discussed. For example, <tt>MEGC@stocks.company-b.com</tt> represents | ||
| + | the Megacorp (MEGC) stock.<br> | ||
| + | * 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.<br> | ||
| - | 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.'' | + | 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. | + | {{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. | + | }} 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 == | == A Simple Script == | ||
| - | <br>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 <tt>Net::Jabber</tt> 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 <tt>Net::Jabber</tt> uses—<tt>XML::Stream</tt>), authentication, events, and all the mechanisms to parse and create Jabber traffic. | + | <br>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 | ||
| + | <tt>Net::Jabber</tt> 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 <tt>Net::Jabber</tt> | ||
| + | uses—<tt>XML::Stream</tt>), authentication, events, and all the | ||
| + | mechanisms to parse and create Jabber traffic. | ||
''A simple Jabber script'' | ''A simple Jabber script'' | ||
| - | + | <code>|#!/usr/bin/perl | |
use Net::Jabber qw(Client); use strict; | use Net::Jabber qw(Client); use strict; | ||
| - | # List of addressees for our reminder our @addressees; | + | # List of addressees for our reminder our @addressees; # What we want to |
| - | # What we want to send my $reminder = $ARGV[0] or die "No reminder!"; | + | # send my $reminder = $ARGV[0] or die "No reminder!"; # Connect to our |
| - | # Connect to our Jabber server my $c= Net::Jabber::Client->new(); $c->Connect('hostname' => 'yak', 'port' => 5222); | + | # Jabber server my $c= Net::Jabber::Client->new(); |
| - | # Authenticate $c->AuthSend('username' => 'reminder', 'password' => 'secret', 'resource' => 'reminder'); | + | # $c->Connect('hostname' => 'yak', 'port' => 5222); # |
| - | # Set handler to deal with presence packets that might (will) be pushed # to us (we're not interested in any other type of packet) $c->SetCallBacks('presence' => \&handle_presence); | + | # Authenticate $c->AuthSend('username' => 'reminder', 'password' |
| - | # Send out our own presence, and run an event loop for up to 5 seconds # to catch any packets pushed to us $c->PresenceSend(); $c->Process(5); | + | # => 'secret', 'resource' => 'reminder'); # Set handler to deal |
| - | # Create a new message with our reminder text my $m = Net::Jabber::Message->new(); $m->SetBody($reminder); | + | # with presence packets that might (will) be pushed # to us (we're not |
| - | # Send the message to each of the addressees collected in the # handle_presence() subroutine foreach my $jid (@addressees) { | + | # interested in any other type of packet) $c->SetCallBacks('presence' |
| + | # => \&handle_presence); # Send out our own presence, and run an | ||
| + | # event loop for up to 5 seconds # to catch any packets pushed to us | ||
| + | # $c->PresenceSend(); $c->Process(5); # Create a new message with | ||
| + | # our reminder text my $m = Net::Jabber::Message->new(); | ||
| + | # $m->SetBody($reminder); # Send the message to each of the | ||
| + | # addressees collected in the # handle_presence() subroutine foreach my | ||
| + | # $jid (@addressees) { | ||
$m->SetTo($jid); $c->Send($m); | $m->SetTo($jid); $c->Send($m); | ||
| Line 130: | Line 264: | ||
# Disconnect from the Jabber server and exit $c->Disconnect; exit(0); | # Disconnect from the Jabber server and exit $c->Disconnect; exit(0); | ||
| - | # Deal with presence packets sub handle_presence { | + | # # Deal with presence packets sub handle_presence { |
my ($sid, $presence) = @_; | my ($sid, $presence) = @_; | ||
| - | # Get the presence my $show = $presence->GetShow() || 'online'; | + | # Get the presence my $show = $presence->GetShow() || 'online'; # If |
| - | # If the user is around, add to addressee list push @addressees, $presence->GetFrom() if $show eq 'online' or $show eq 'chat'; | + | # the user is around, add to addressee list push @addressees, |
| + | # $presence->GetFrom() if $show eq 'online' or $show eq 'chat';</code> | ||
| - | } }} 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. | + | } }} 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. | ||
Revision as of 17:05, 13 September 2006
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.
Jim is notified that John is available:
|<presence from='john@company-b.com/Desk'
to='jim@company-a.com/home'> <status>Online</status>
<priority>2</priority> </presence>
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, have 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 price 248p
as at 10:20am today</body> </message>
He checks the price of Megacorp stock (MEGC) by sending an empty message
to the 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 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 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>
The workflow assistant application, workassist, sends John a notice
that he's received an important email:
|<message from='workassist@company-b.com'
to='john@company-b.com/Desk'> <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'
to='john@company-b.com/Desk'> <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 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.
there are mechanisms in place to "throttle" heavy connections. These mechanisms can be configured in the server configuration, described in Section 4.13.
}} 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.
A simple Jabber script
|#!/usr/bin/perl
use Net::Jabber qw(Client); use strict;
- List of addressees for our reminder our @addressees; # What we want to
- send my $reminder = $ARGV[0] or die "No reminder!"; # Connect to our
- Jabber server my $c= Net::Jabber::Client->new();
- $c->Connect('hostname' => 'yak', 'port' => 5222); #
- Authenticate $c->AuthSend('username' => 'reminder', 'password'
- => 'secret', 'resource' => 'reminder'); # Set handler to deal
- with presence packets that might (will) be pushed # to us (we're not
- interested in any other type of packet) $c->SetCallBacks('presence'
- => \&handle_presence); # Send out our own presence, and run an
- event loop for up to 5 seconds # to catch any packets pushed to us
- $c->PresenceSend(); $c->Process(5); # Create a new message with
- our reminder text my $m = Net::Jabber::Message->new();
- $m->SetBody($reminder); # Send the message to each of the
- addressees collected in the # handle_presence() subroutine foreach my
- $jid (@addressees) {
$m->SetTo($jid); $c->Send($m);
}
- Disconnect from the Jabber server and exit $c->Disconnect; exit(0);
- # Deal with presence packets sub handle_presence {
my ($sid, $presence) = @_;
- Get the presence my $show = $presence->GetShow() || 'online'; # If
- the user is around, add to addressee list push @addressees,
- $presence->GetFrom() if $show eq 'online' or $show eq 'chat';
} }} 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.
