XMPP versus HTTP 
September 6th, 2008
Its funny how we in the software industry seem to be re-inventing the same solutions to the same problems over and over again. When I started my career, server-centric mainframe systems were on their way out and smart desktop client-server systems were the new hawtness. At the bank where I started all those years ago we still had a number of these old systems in place. For anyone who hasn’t experienced using these systems they can basically be described as a monochrome text version of a typical Web 1.0 system. A page containing the UI was displayed that held some data and a few options (links) for navigation. The user would select an option, the screen would clear and the server would stream up a new UI. Other than the absence of color and any sort of graphics, it was just like using a typical present-day web system … ie. the server does all the work, the UI and data is discarded and re-generated with each user interaction, its slow and unresponsive, visually poor, unintuitive.
Client-server systems were a significant improvement on the older mainframe systems. They had most or all system logic on the desktop. This facilitated the creation of very interactive UI’s and is where a lot of the powerful UI components that we use today were born. Components like grids and combo-boxes had instant access to cached versions of data pulled from servers. Users could dive into data quickly and examine it from a number different perspectives. That’s not to say these systems didn’t come with their own problems (ie. distribution of software updates) but in many ways Web 1.0 systems were actually a step backward in usability and performance relative to their desktop client-server counterparts.
Along the way browser technologies have matured and some of the richness of the old client-server systems have started to slowly creep their way back into enterprise applications once again. The arrival of technologies like Flex and AJAX have been helped in particular. With these technologies we’ve seen some of the old patterns make a comeback like client-side business logic, smart UI updates and thrifty use of network bandwidth. Now, XMPP allows developers to take these patterns to the next level.
With all the sophistication that current Flex and AJAX applications afford, they are fundamentally still built on top of a technology that was designed for serving static web pages. The user perceives a seamless experience but are often unaware that communication between the UI and the back-end server is even occurring. In order to pull off a seamless experience, a lot of questionable code trickery is executed that exploits or contorts various browser features for the purpose of communicating with the server behind the scenes and then updating the UI. This practice has evolved into a somewhat standard practice. This is mainly due to the number of people who have adopted this approach as opposed to the features being well thought-out purpose-built browser features. It also only solves half the communication problem. Communication over HTTP can only be initiated from the browser. The server cannot initiate communication and transmit data to the browser on its own. Overall, a typical Rich Internet Application (RIA) ends up as a very intricately woven collection of some standard HTML, a few hacks, and a ton of browser-specific edge cases. They are very difficult to develop and test and have a high probability of breaking in the next browser release.
Using XMPP in place of HTTP won’t solve all the problems associated with developing enterprise applications for the web but it can make things a lot cleaner. In order to accomplish many of the things you need to do in a typical information system using traditional HTTP postback or AJAX techniques you inevitably find yourself making a lot of compromises. You may, for example, need to notify a user that another user has modified the data that he/she is working with. You need the server to send a message to the browser, which is not straight-forward using HTTP. The server, however, cannot speak unless spoken to. One of the compromises you wind up making then, is either polling the server at timed intervals to check for messages or having the server leave the HTTP connection open for long periods of time using keepAlives. Neither solution is particularly elegant and both are rather resource-intensive for both browser and server. You begin to feel your application is being held together with duct tape and chewing gum.
Applying XMPP to solve the same sort of problem provides a much cleaner solution. When events occur within one user’s application, such as modifying data, the event is propagated over an open XMPP connection back to a server where it can then be instantly propagated out to all clients with open XMPP connections. Because of subtle differences in how you would architect an XMPP application versus an HTTP application, this behavior is almost automatic.
XMPP requires very low overhead, it’s highly reliable and it has much lower latency and startup cost than HTTP because it is connection oriented. In fact, what you begin to see is that your entire application starts to mesh together in a much more cohesive manner. Whereas with an HTTP application you have a more pronounced distinction between code executing on the server and code executing in the browser, an XMPP application appears to run as a single cohesive piece of software. Even with AJAX applications the HTTP request-response pattern is still prominently visible to the user and you will typically see the application performing interactions with the server one at a time. With XMPP the software appears to update everything everywhere simultaneously. Execution threads hop seamlessly back and forth from browser to server and even from browser to server to multiple browsers and back again. The net result is the XMPP solution is more real-time experience versus the batch-processing feel of an HTTP solution.
In the HTTP world REST is all the rage. The basic philosophy of REST (Representational State Transfer) is that its a stateless system where all the types of information dealt with by your system (ie. customers, sales, etc.) are exposed as “resources” (unique URI’s ) with standard HTTP methods (POST, GET, PUT, DELETE). Ironically these methods are not implemented consistently in browsers and servers (or at all) necessitating further hackery … but anyway … moving on. The goal in building a well-architected HTTP system is to ensure that all your communication is RESTful. This can be most easily summed up as “don’t modify data with GET (read) operations”. The belief is that by following this pattern your software will be more simpler, cleaner and more scalable and maintainable than alternative approaches. Without arguing the validity of this belief, what REST does achieve is to impose a certain structure. This structure requires the software to organize requests and updates of data into small batches that are queued-up and transmitted from browser to server. Although there are no restrictions on how much data is sent or how often, messaging is generally held to minimum and is usually treated as a major event. For example, all the interactions with the user filling out a form and all the code that facilitates it may culminate with just a single message being posted to the server. As a developer you’re likely to spend a lot of time hand-crafting the construction of the message payload as well as parsing and handling the response.
Contrasting this with an XMPP implementation, once you get the basic communication infrastructure in place you don’t really spend much time worrying about browser to server communication. Thats because you’ll typically treat an XMPP event with more or less the same level of importance as any other event within your application. At a very granular level you define event delegates for your XMPP events in much the same way you’d define event handlers for mouse-over events. XMPP messages are so lightweight and quick that you could even relay mouse movements to users at other locations in real-time. In essence the network communication becomes transparent. Events triggered in the user interface can be listened for on the server and events on the server can be instantly responded to and reflected in the user interface. Of course, the particulars of how you design your application architecture are still up to you. There’s nothing stopping you from designing your application to send data in batches like an HTTP application would. Also, if you want to put in the effort it is possible to mimic the real-time behaviour of an XMPP application using HTTP. In the end, XMPP will be faster and less resource intensive so the overall application performance and user experience will be better with the XMPP application.
It seems we’re at a stage now with the technology where we can have our cake and eat it too. We’ve solved problems of connectivity and distribution of software updates thanks to the Internet. We’ve got rich UI’s thanks to AJAX, Flex and AIR. And now we have real-time communication that can be initiated from either direction using XMPP. With any luck, the clunky, stuttering, click and wait, web applications will soon be a thing of the past. It will be interesting to see how developers are able to take advantage of this technology and raise the bar for software applications.
Entries (RSS)
and