How does XMPP Work?
XMPP defines protocols for communicating between a client and a
server, and between two servers, as illustrated above. An XMPP
Client will talk to the server with which it is registered.
XMPP Clients are named in the same way as email addresses
(e.g., [email protected]) and XMPP Servers are named as domains
(e.g., capulet.com is [email protected]'s XMPP server).
XMPP Messages are extensible, and can be used to carry messages
of different types. For example, an XMPP Message can carry
Instant Messaging (IM) type traffic. To send a message, an XMPP
Client will simply send it to its local server. If the recipient
XMPP client uses the same XMPP server, the XMPP server will send
it directly to the recipient. If the recipient uses a different
XMPP server, the XMPP server will send the message to the
recipient's XMPP server. There are some key differences between
this scenario and traditional store and forward messaging
(email):
1. XMPP messages have a single recipient only.
2. Messages delivery is optimized for clients that are online
(i.e., to clients that are connected to their XMPP server).
3. Messages do not have to be stored reliably (e.g., on a
disk), so may be dropped if the XMPP server fails.
4. XMPP servers are generally optimized for short messages (1
kbyte or less).
This scenario is familiar to many IM users, although many of
the well known IM services are single server and do not
communicate with other servers in the way that XMPP does.
Although IM is an important and well known use of the messaging
part of XMPP, it is important to understand that the messaging
part of XMPP can be used to carry data other than IM. XMPP is
much more than just IM.
XMPP Clients can be interactive GUIs or applications. The
basic messaging part of XMPP can be used as a building block for
more complex applications, and in particular to transfer XML data
defined in support of other applications. Chat rooms are an
extension to the core XMPP service, providing a mechanism for
multiple users to exchange and share information.
In order for this messaging to work usefully, a mechanism is
needed to determine if and where a client is online. This is
handled by the Presence part of XMPP. When an XMPP Client
connects to its server, its basic presence is registered, which
can be qualified by additional information provided by the XMPP
user, such as "in a meeting" . Thus the XMPP server has presence
information for all local clients. Each XMPP Client maintains on
the XMPP server a list of users, called a Roster (described as
Buddy List and other informal terms in many clients).
The XMPP server determines presence status for each member of
the roster, and keeps this information up to date. This requires
XMPP servers to share presence status of their clients, to enable
information on each client's roster to be kept up to date. The
functionality to efficiently manage presence in a distributed
environment is the hard part of XMPP.
XMPP provides a mechanism for XMPP clients to exchange messages
through the XMPP servers. This message exchange can be used "as
is", for example to support IM traffic. This message exchange
can also be used to enable two applications using XMPP clients to
establish a direct connection. A good example of this is the
JINGLE mechanism based on XMPP that enables a direct connection
to be established for voice traffic (which has too high a data
volume to be sent indirectly through the XMPP servers). The
presence part of XMPP is critical, as in general the clients
would not have a fixed location. XMPP can play a key role in
establishing advanced communication directly between two clients.
XMPP has been widely adopted, including by Google as part of
Google Talk, and there are many XMPP clients and servers
available. Technical information on XMPP can be found on the
XMPP Standards Foundation (XSF) Web site.
Why Real Time Messaging?
IM, based on real time messaging, has become mainstream. Users
increasingly expect to have IM provided alongside email (store
and forward messaging). Real time messaging is an important
building block for distributed systems that can be used in
conjunction with store and forward messaging. Services that can
be provided include:
. Multi-User Chat.
. White Boarding.
. Publishing and sharing data between applications, using the
PubSub publish and subscribe mechanism.
. Setup of direct communication such as:
. File Transfer
. Voice
. Streaming Video
Why Presence?
Presence is not such an obvious service to the end user, but it
is critical both to enable services such as IM and to enable
direct client to client communication. It is a key building
block for advanced communication applications. Extended Presence
allows sharing of extended information, and provides support for
capabilities such as geo-location.
Why XMPP?
Isode believes that XMPP will become the single standard for Real
Time Messaging and Presence services.
Presence and IM are on their way to becoming universal services.
In support of this, users will want to have a single IM/Presence
address that can be used with everyone. For many users, it would
be convenient to have this address the same as the user's email
address. XMPP enables this.
Today, many users advertise multiple IM addresses associated with
different centralized IM service providers such AIM, MSN and
Yahoo!. This is reminiscent of messaging in the 1980s, when
users would list a set of email providers, such as AOL and
CompuServe. Isode believes that convergence will happen for IM,
in an analogous way to the way that email convergence happened.
Convergence requires an open standard supported by a recognized
standards body, that defines both client/server and server/server
operation. Instant Message and Presence Service (IMPS) from the
Open Mobile Alliance meets two of these criteria, but does not
define a server to server protocol, which is key for an
integrated global service.
SIMPLE (Session Initiation Protocol for Instant Messaging and
Presence Leveraging Extensions) is an Internet Standard, and the
only serious alternative to XMPP. Isode believes that XMPP has
already won out over SIMPLE for a number of reasons:
. XMPP has a much larger deployed base, and is actively
deployed in a distributed manner using server/server
communication.
. The core SIMPLE specification is significantly more complex
than XMPP.
. Scaling analysis shows that XMPP scales to large deployments
in a much better manner than SIMPLE.
. There are many more XMPP client and server products.
. XMPP has a very active community centred on the XMPP
Standards Foundation that is working on a wide family of
standards based around XMPP.
In summary, we believe that XMPP is the only credible open
standards choice.
XMPP and Isode
XMPP is important technology in its own right. The rest of this
paper looks at how XMPP fits with other Isode products and
technologies.
XMPP and Directory
Directory and XMPP presence deal with complementary information
on a user:
. Directory holds static information, such as email address and
telephone number.
. An XMPP server holds information that may not always be
available and may change rapidly, such as location and activity.
There is immediate benefit in providing integration of this
information in both directions:
1. The directory can be used to hold static information for the
XMPP server, including user information, and rosters. This
approach is consistent with Isode's general approach of using
directory to hold configuration information for Isode
applications.
2. Presence information stored in the XMPP server can be made
available to directory clients, so that when information is
looked up, this information is available to the directory use
along with other information. For a white pages application,
this would enable presence information such as "User in meeting
until 11:30" to be displayed along with email address and other
directory information. It would also enable an application
making information delivery decisions to make use of presence
information in the calculation.
XMPP and Store & Forward Messaging
Isode's store and forward messaging solutions are designed for
high reliability environment. A key goal of many such
environments is timely delivery, and an XMPP service can help
here.
Isode provides monitoring capabilities, so that an operator can
determine when messages have not been read by the intended
recipient. (see here for more details). An XMPP service will
help the operator in this situation, by providing information on
availability of the intended recipient, and a mechanism to
communicate with the intended recipient using IM to determine if
the message can be handled soon. In the event that the operator
determines that the message needs to be sent on to an alternate
recipient, the XMPP capabilities can be used to help select an
alternate recipient who is ready to handle the message
immediately.
It can also make sense to automate the previous operator assisted
scenario. Where a message may be processed by one of several
recipients, presence information can be used by the store and
forward messaging system to help automatically determine the best
place to deliver the message.
XMPP and Events
Isode has a model of events and faults described in the Isode
white paper Operational Monitoring and Control of Systems using
Isode Servers. When an event or fault occurs that (may) require
operator attention, it is important to provide a flexible
approach to get this information to an operator. XMPP alerting
of events can add value to this approach, either by sending
information to an individual user or to a chat room.
This approach can be particularly helpful where the number of
operator events is very low, and operators are handling many
non-operational tasks. Use of a chat room can also be helpful
where a number of people are providing cover. That chat room can
then also be used to work out who is dealing with a specific
event, and avoid duplication of effort.
XMPP Server and User Configuration
Click image for more detail
Isode provides Web based configuration of its Internet messaging
servers using Internet Messaging Administrator (IMA). This
includes integrated configurion of XMPP services, and can also be
used to configure XMPP only configurations.
When a user is added, XMPP support is selectable as an option,
leading to integrated support with email address and XMPP address
being the same. This integrated provisioning is provided using a
directory back end, and so can be easily be integrated with a
third party provisioning system to give the same result.
Configuration of the M-Link server is also be done using
directory and with GUI configuration provided by IMA.
Conclusions
This paper has set Isode's high level XMPP Strategy, and how this
fits with.other Isode products and technologies.
XMPP was invented for instant messaging and presence, and is
the dominant open protocol in that space. Instant messaging?
Yep, it turns out that all of the problems that had to be solved
for instant messaging make the protocol perfect for cloud
computing:
. It allows for easy two-way communication, so bye bye polling.
It even has rich pub-sub functionality built-in.
. It's XML-based and easily extensible, perfect for both new
instant messaging features and custom cloud services.
. It's efficient and proven to scale to millions of concurrent
users on a single service (such as Google's GTalk). It also has
a built-in worldwide federation model.
I'm not the only one to notice that XMPP is a great fit for
cloud computing. Tivo is switching to XMPP as a more efficient
alternative to their old architecture:
<div class="jive-quote">Today each TiVo polls TiVo's severs
roughly every 15 minutes to check for new scheduled recordings,
TiVoCast downloads, Unbox downloads, etc. That's highly
inefficient - nearly all of those polling calls are for nothing.
There is nothing waiting to be done. And it introduces a lag
when you want to start a download - up to 15 minutes. And it
doesn't scale well as TiVo's user base keeps growing.
So what's changed? The polling system is gone. TiVo is using
XMPP now instead. (...) Yep, TiVo is basically using instant
messaging for real- time communication. Now when the TiVo server
has a new recording to schedule, it will IM the TiVo to tell it.
Or if there is a download to pull, it will IM the TiVo to tell it
to do so. This is a much more efficient system and it eliminates
latency. It is really a clever idea.
</div
Fixing the polling and scaling problems with XMPP as Tivo has
done is compelling, but the built-in presence functionality also
offers tantalizing possibilities. Presence includes basic
availability information, but is extensible and can also include
things like geo-location. Imagine cloud services taking
different actions based on where the client is connecting from.
More people, us included, will make the shift to XMPP, which
will provide the missing evidence to create momentum toward a
tipping point. In fact, I'm happy to announce that Clearspace
2.0 will include a feature that's powered by an XMPP-based cloud
service. We'll be publishing a series of blog entries in the
near future to discuss how we built it.
Resources for XMPP cloud service developers
There are a few places you can turn for help building cloud
services around XMPP. Here is a list of a few:
. XMPP Standards Foundation -- where the standard gets defined
. Ignite Realtime -- Jive Software's Open Source XMPP projects
. Jabber Website -- lists XMPP servers, libraries and clients
Attachments:
. saas-communication-models.jpg (27.2 K
. xmpplogo.png (11.1 K
For all you technobuffs out there.
___
Replies to this message will go directly to the sender.
If your reply would be useful to the list, please send a
copy to the list as well.
To leave the BrailleNote list, send a blank message to
[email protected]
To view the list archives or change your preferences, visit
http://list.humanware.com/mailman/listinfo/braillenote
