We know the social web needs real-time event notifications, and that polling sucks. Some are wondering whether we can implement it using asynchronous messaging, ala Pub/Sub. The Publish/Subscribe is an architectural paradigm allowing asynchronous messaging from one sender (publisher) to many receivers (subscribers). PubSub is a common architecture in financial services, since it’s associated with persistence and ensured message delivery. But such qualities don’t come for free: there are complexity trade-offs.
Anyway, the conversation started in February, with Mickaël Rémond talking in his blog at ProcessOne (the maintainers of the top-notch Erlang ejbabberd XMPP server) about XMPP the application server, where he turned the PubSub XMPP extension into a public event firehose for twitter. And because Mickaël puts his money where his mouth is, he opened a public service doing just that, an XMPP gateway to twitter, or what twitter should have done to begin with.
Then came Internet veteran Jud, from upcoming Gnip, blogging about sockets, HTTP and XMPP, and how the in the original non-reliable Internet topology the stateless HTTP worked because it brought reliability, but that today's reliable Internet topology could allow HTTP to be replaced by the stateful XMPP protocol.
It hit us again, at OSCON 2008 in July, with fellow Yahoo's hackers Rabble and Kellan talking about data services streaming using XMPP PubSub. We know that having to do frequent HTTP polling sucks, and unfortunately that's the best we can do many times, so they proposed to use a cut-down XMPP server (no roster, etc.) to build a public Publish/Subscribe messaging infrastructure. They worked it out for FireEagle and Flickr building external XMPP components, and connected a web stack through queues. XSF has gone further, proposing a new standard for chaining components, and why not, even a pubsub data stream for Atom.
Honestly, there is plenty of buzz. Brian Dainton also talked about XMPP for event broadcasting instead of REST. The folks at ChessPark, with Jack Moffitt, are doing just that with component bots.
It might be that XMPP eventually replaces HTTP for event notification, avoiding the need to poll. But today, HTTP and REST are patterns known to work. Let me examine why I think a REST approach still works better today:
- The Internet, the firewalls, the monitoring, are not built today for persistent connections. XMPP real-time events are possible since a TCP socket is kept open. BOSH and XMPP over BOSH make it possible to run XMPP over HTTP, and provide almost real-time notification. I like BOSH, a lot, but it is still an emerging technology that needs plenty of love. XMPP metadata is still not implemented in BOSH, and the client-side implementations are weak.
- Running an Apache server and setting a up a REST service is almost straight forward. We know how it works, how it scales, and how it fails. Running a XMPP server, even the excellent ejabberd, is not as easy as running Apache, and most folks are likely not to run their own XMPP server and rely on third parties like jabber.org or gtalk. The good folks at gnip cut down on XMPP because of lack of reliability of the XMPP third parties. XMPP, still, is too complex to operate.
- Supporting binary data is XMPP's achilles heel.
- There are simpler HTTP only alternatives. Brad Fitzpatrick implemented a never-ending Atom feed for the LiveJournal update stream years ago. A partial solution to reduce polling, although not real-time, is Roy's better resource mapping. And let's not forget the straight forward callback. Oh yes, running an Apache server on your mobile phone is possible.
Will XMPP become the messaging middleware for the web? Eventually, perhaps, but in today's environment, neither the infrastructure or the software are ready to support such a model. As importantly, there are simpler alternatives to achieve real-time event notification without requiring the publish/subscribe architecture.
blog comments powered by Disqus