XMPP has been getting a fair share of attention for solving issues related to applications designed around services. Here we'll take a look at XMPP's origins, its primary technical concepts and how its initial area of influence has expanded toward more general purpose 'cloud' computing scenarios related to scaling.
Originally conceived under the name Jabber and targeted at instant messaging applications, the approach set forth by Jabber has led to the creation of XMPP which is now an IETF standard -- RFC-3920 -- supported by various other XMPP extensions .
At its core, XMPP is defined as a streaming protocol that makes it possible to exchange XML fragments between any two network endpoints. Now, exchanging XML fragments between two network end points is not a novel idea, in fact it is what Web services designed around SOAP and REST principles already do. So why is XMPP different ? It's all in the XML fragment payload.
Whereas XML fragments used in SOAP-type services are provisioned with many WS-*/SOAP specific payloads to guarantee the many features required in enterprise services -- such as security and reliability -- and REST type services can be considered open-ended since they don't require any specific XML provision, XMPP uses specific payloads a'la SOAP to guarantee its primary feature as a real-time communication transport is achieved. Listing 1.1 shows a very basic XML fragment used in an XMPP exchange.
Listing 1.1 XMPP XML payload
<?xml version='1.0'?>
<stream:stream
from='example.com'
id='someid'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
version='1.0'>
<!-- Encryption, Authentication, and Resource binding ommited -->
<message from='juliet@example.com'
to='romeo@example.net'
xml:lang='en'>
<body>Art thou not Romeo, and a Montague?</body>
</message>
<message from='romeo@example.net'
to='juliet@example.com'
xml:lang='en'>
<body>Neither, fair saint, if either thee dislike.</body>
</message>
</stream:stream>
</stream:stream>
Reference http://www.xmpp.org/rfcs/rfc3920.html#streams
(End Listing 1.1)
This last XML fragment contains an XML Stream and XML Stanza, which are the primary building blocks behind XMPP. An XML stream is simply a container or envelope for the exchange of XML elements between any two entities over a network, whereas an XML stanza refers to the bulk of the message being exchanged. The elements presented here are just a sample of XMPP's elements, for the standard sets forth elements to deal with things like Transport Layer Security (TLS) and error management, not to mention XMPP's extensions cover over 100 supplemental areas related to messaging.
If you're familiar with services based on SOAP, XMPP's principles are strikingly similar. Both use their own addressing scheme, they both use envelopes to indicate communication behavior, and they both rely on standardized XML elements to further specify the purpose of an exchange. Similarly though, XMPP also requires that both a server and client be capable of processing and implementing the behavior expressed in such payloads.
In this area, you can find a wealth of clients and servers that support XMPP, including libraries for as much as 15 languages to integrate XMPP directly into your applications.
Still one important question remains, why has XMPP started getting more attention with presentations like Beyond REST: XMPP PubSub? And why is it being tested in applications that have nothing do with instant messaging? To answer this, its necessary to take a brief detour into other trends that have become more popular in 'cloud' computing.
In a stateless medium, like the Web that operates on HTTP, and in which client and server need to constantly re-identify themselves via cookies or some other mechanism, the appearance of techniques like Ajax and publication formats like RSS data feeds have only put increasing pressure on scalability issues.
Approaches like Ajax and RSS data feeds based on REST principles tend to be 'update hungry', placing an increasing strain on servers if a certain user base is attained or if update intervals are too short. These constant update requests from client to server -- which are often resolved through polling -- have given way to more instant messaging like approaches, in which information is pushed to a client without the need for it to constantly and often unnecessarily make update requests -- see Comet for more information on this trend.
In XMPP's case, since its many XML elements support precisely real-time communication, such behaviour is often far superior in the face of 'update hungry' designs than using the simpler yet 'dumber' REST approach. Though the introduction of XMPP into an application can make it more elaborate, doing so can also make it more robust, making it capable of taking advantage of techniques like publish/subscribe mechanism and other instant messaging like features that are missing in the more predominant REST and SOAP approaches used to build services.
And just how far has XMPP been adopted? Well, occurrences like Google Talk using XMPP as its backing protocol and Cisco's agreement to acquire Jabber Inc which was one of the first XMPP providers, should all be indicative of how the bigger players in the IT sector have given their vote of confidence to XMPP's approach.
So whether you design all your services using REST or SOAP, keep a close eye on XMPP's real-time XML based approach, its already on the map of the larger IT companies, who is not say it can help you deliver more elegant and robust solutions for you applications deployed in the 'cloud'.
About the author
Daniel Rubio is an independent technology consultant with over 10 years of experience in enterprise and web-based software, he blogs regularly on these and other software areas at http://www.webforefront.com/
