XMPP is a popular XML-based open-source protocol for streaming XML elements in order to exchange information in nearly real time, especially for IM and presence information (Jabber). Although XMPP is not bound to a specific architecture, it is usually implemented as client-server over TCP, HTTP or other.
Recently, XMPP has been featured on two presentations of OSCON 2008 as an alternative to SOAP or HTTP/REST style architectures [1], [2]. I will try to recap some of the main points.
XMPP Buliding Blocks
XMPP is about exchanging messages (“Hello Dave!”), sending and receiving presence data (“I am bored…”), and performing queries (“What is the weather like in Albaquerky?”).
Why do we need XMPP?
Today, most Cloud Computing services (that I know) are based on Web Services à la WSDL/SOAP or REST. SOAP was intended as a simple XML-based protocol for machine-to-machine communication in distributed middleware. However, some people argue that in many situations WSDL/SOAP/WS-* is overly complicated due to too much standardization (which leads to awkward programming). This is a driver for the adoption of REST-style architectures, where the application is a bag of stateful resources identified by URIs and accessed with stateless HTTP Crud methods.
Although HTTP is great for certain applications and tunneling firewalls, the protocol has its limitations. How would you implement something like GTalk, facebook chat, Twitter-like services, and so on? Polling is a bad idea, since most client requests are for nothing and waste server resources: Polling doesn’t scale. Moreover, polling induces a time lag that has a negative impact on usability.
XMPP seems to be great for this kind of task because it introduces persistent, stateful connections, it is designed for event-based data streaming and so on. So, if you deal with monitoring a Cloud Computing environment, why not use XMPP to check on your running instances?
More infos:
