27 January 2009
I don't know if they're using an ESB, but they should be.
Meebo.com's a very novel little Ajax-oriented IM client. It's acheived some stunning success, all very well deserved. Recently (a few weeks ago), I noticed Meebo.com has added support for talking to Facebook as well as MySpace users via their presence-aware messaging feature ("Instant Messaging"). This means that they're exposing connectivity with services provided by the platform. They built their previou lot of IM connectivity/functionality using a concurrency-friendly version of libpurple (This article on Meebo on WikiPedia metnions that, and so does these two from Meebo's Blog).
libpurple is the library behind the ubiquitous F/OSS Pidgin (formerly, GAIM). Essentially, it knows how to speak/receive messages from all sorts of IM protocols/platforms.
I want to take this opportunity to imagine their architecture a little bit, and explore it as an ideal candidate for an ESB-based solution. Architecting an application like that requires some of the features that an ESB best provides: messaging, routing, transformation.
The messaging quality I attribute to their natural requirement to send and receive messages. Their application has endpoints that know how to "receive" messages and endpoints that know how to "send" messages. That these endpoints are written on top of
libpurple or on top of the Facebook Chat and MySpace IM API's is irrelevant.
Naturally, Meebo needs to provide routing. It wouldn't be kosher if you sent a message to Fred, and a complete stranger Wilma got it!
Finally, Meebo must provide support for transformation - I can only imagine - if for no other reason than that's a requirement in the Canonical Data Model Pattern, which describes integration across many disparate endpoints made possible by reducing the permuations of connective channels. This is feasible by having all endpoints "adapted" into a normalized message format. All channels to and from those endpoints undertand this format. This makes adding a new endpoint as simple as adding an adapter from its format to the normalized system format. Thus, for Meebo, it is imperative that for any messages being passed from point to point, the message model itself is normalized and then pased on to a channel bound for an adapter. This avoids "architectural spaghetti!"
Finally, their architecture must make use of certain design patterns, for example a correlation ID would be invaluable in a cloud application where anybody can send messages at any time but they must consistantly show up in a normalized sequence for all clients of the discussion involved.
I don't know what Meebo's made of, though I am happy to speculate. Plenty of people have tried to build solutions, like SOAShable, for example, which has since stopped functioning. But, it's a good start at the project, and is worth a look. There are other explanations of some of the hard core nitty gritty behind Meebo. One such article, How Comet Brings Instant Messaging To Meebo, is a good read. Finally, to see how some of this might be implemented it's worth noting that there's already support for some of this functionality in a few different ESBs. Here's an example using XMPP and JBoss ESB. This example provides XMPP support for the popular Mule ESB. Who knows, perhaps with a little work and some C I'm sure you could get a server-ready, concurrency friendly version of
libpurple running yourself!
Just food for thought..