<<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='[EMAIL PROTECTED]'
to='[EMAIL PROTECTED]'
xml:lang='en'>
<body>Art thou not Romeo, and a Montague?</body>
</message>
<message from='[EMAIL PROTECTED]'
to='[EMAIL PROTECTED]'
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'.>>
You can read this at:
http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1332820,00.html?track=NL-449&ad=663264&asrc=EM_NLT_4621932&uid=5532089
Gervas
