Is XMPP the Future of Cloud Services?

Posted by Gavin Terrill on Jan 28, 2008

Sections

Architecture & Design,

Enterprise Architecture,

Operations & Infrastructure

Topics

Performance & Scalability ,

Architecture ,

Cloud Computing ,

SaaS ,

EAI ,

Web Services

Tags

Atom ,

XMPP ,

Comet

The debate around Push versus Pull architecture has been resurrected, sparked by a posting from Jive Software's CTO Matt Tucker declaring that the push based approach of XMPP is the future for cloud services:

There's a new firestorm brewing in web services architectures. Cloud services are being talked up as a fundamental shift in web architecture that promises to move us from interconnected silos to a collaborative network of services whose sum is greater than its parts. The problem is that the protocols powering current cloud services; SOAP and a few other assorted HTTP-based protocols are all one way information exchanges. Therefore cloud services aren't real-time, won't scale, and often can't clear the firewall. So, it's time we blow up those barriers and come to Jesus about the protocol that will fuel the SaaS models of tomorrow--that solution is XMPP (also called Jabber) . Never heard of it? In just a couple of years Google, Apple, AOL, IBM, Livejournal and Jive have all jumped on board.

Matt states that the common approach of clients polling servers for updates over HTTP is inefficient, citing examples such as Tivo, Twitter and SalesForce, where polling has not been able to sufficiently scale:

Since the beginning of the Internet, if you wanted to sync services between two servers the most common solution was to have the client ping the host at regular intervals, which his known as polling. Polling is how most of us check our email. We ping our email server every few minutes to see if we got new mail. It's also how nearly all web services APIs work.

XMPP's profile has been steadily gaining since its inception as the protocol behind the open source IM server jabberd in 1998. XMPP's advantages include:

• it is decentralized, meaning anyone may set up an XMPP server
• it is based on open standards
• maturity - multiple implementations of clients and servers exist
• robust security is supported via SASL and TLS
• flexibility - it is designed to be extended

While initially targeted at IM, XMPP is now being used for a wide variety of applications. For example, this Internet-Draft proposal for sending notifications about syndicated resources using the Atom feed format opens up interesting possibilities for application integration. Matt says that the biggest hold up preventing further adoption is that it does not run over HTTP:

XMPP's largest hurdle is that its not HTTP, and common wisdom states everything new that's built must be web-based. That means we won't see a widespread application of XMPP in cloud services until a few more brave pioneers clear the path for the rest of us.

So what makes XMPP a good fit for cloud computing? Matt listed several items:

• 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.

XMPP is not the only publish subscribe enabler getting a lot of interest from web application developers - Comet is seeing an uptake in interest, with Webtide CTO Greg Wilkins recently reporting supporting 20,000 users on an amazon EC2 backed server running Jetty and Cometd from Dojo. Unlike XMPP, Comet is based on HTTP, and in conjunction with The Bayeux Protocol, uses JSON to exchange data.

One question that is tempting to ask is how much scalability is needed, as Sean McGrath did when he pondered how far can you get with Pull versus Push in building Mashups:

The web - with all its concomitant bits'n'bobs from XML to RSS/Atom to AJAX - is an extremely good platform for pull-centric design. On the Web, if you try to pull some piece of information and something goes wrong, well you just pull again and again until you get it or give up. Nothing fancy. Just brutish repetition. Something machines are extremely good at. If you want to look at information from yesterday, you just go to the URL that contains yesterday's information. Nothing fancy. Just a simple naming convention that includes dates in URLs.

It will remain to be seen if XMPP is the future of cloud services, but one thing is for certain now: if you are a web application architect, you need to know about XMPP.

1. Back to top

   Interesting

   by Billy Newport

   I've been eyeing Lotus Sametime for 3 or 4 years now trying to come up with a reason to use it in middleware etc. Most companies have an IM infrastructure just sitting there to be abused for something useful besides sending links to funny stories to one and other and links to infoq OF COURSE!

   Reply

• Older >