Friday August 25, 2006
Friday August 25, 2006 In this post , I briefly try to push how XMPP can be used as a infrastructure - and not just as 'yet another chat protocol'.
It is not as descriptive or authoritative as I would like it to be ... but here goes nothing.
The abstract from RFC 3920 says :
"This memo defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a protocol for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779."
For the purpose of this discussion , let us take a small subset of what XMPP provides which allows us this :
We have an authenticated and secure stream between two entities - so this asserts the client identity.
This explictly identifies an entity within , not only its server - but if federated , across the XMPP universe of federated servers ! This guarantees that any stanza orginating anywhere in this grand federation of XMPP servers will be unambigously routed to this specific client endpoint
Defines an xml stream ... most data transfer protocols have already moved , or are moving towards standardizing on usage of xml : so XMPP provides a native transport mechanism for these.
The MEP's supported allows us both synchronous communication and asynchronous notification - in either direction: hence both push and pull models are natively supported.
The protocol itself allows for presence notifications through a publish subscribe model.
Now , the XMPP community has come up with a variety of protocol extensions which have been standardized as JEP's.
A few notable ones which are relevent for this discussion are :
We could use xmpp as a middleware for realtime communication and use it for both synchronous and asynchronous notifications. Some examples :
Httpbind essentially can be considered as way to tunnel a xml stream based protocol on top of http : no , not the old CONNECT hack that most implementations use , nor a dumb frequest poll mechanism.
As an analogy , you can consider it to be similar to how you would simulate a persistent stream on top of UDP - only it is HTTP here instead of UDP.
The extension takes care of retransmissions , packet loss , request/response id , etc and makes allowances for HTTP characteristics .
Hence , all the power of XMPP is now available over HTTP.
So be it a rich client application or a rich internet application - both can talk XMPP and harness its power !
And with it , allows all usecases of using XMPP as a realtime messaging middleware available to all developers/users on most platforms - be it a RIA or a thick client.
XMPP - coming to a browser near you
It is not as descriptive or authoritative as I would like it to be ... but here goes nothing.
The abstract from RFC 3920 says :
"This memo defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a protocol for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779."
For the purpose of this discussion , let us take a small subset of what XMPP provides which allows us this :
- As specified in section 4 of 3920 , an xml stream between two entities which allows for exchange of structured xml stanza's at realtime.
- A binding to tcp and defines how to secure and authenticate the stream.
- Defines the top level stanzas allowed in this xml stream. These model request-response , broadcast and one way meps.
- Server federation , routing rules , multiple resources per node built into the protocol.
We have an authenticated and secure stream between two entities - so this asserts the client identity.
This explictly identifies an entity within , not only its server - but if federated , across the XMPP universe of federated servers ! This guarantees that any stanza orginating anywhere in this grand federation of XMPP servers will be unambigously routed to this specific client endpoint
Defines an xml stream ... most data transfer protocols have already moved , or are moving towards standardizing on usage of xml : so XMPP provides a native transport mechanism for these.
The MEP's supported allows us both synchronous communication and asynchronous notification - in either direction: hence both push and pull models are natively supported.
The protocol itself allows for presence notifications through a publish subscribe model.
Now , the XMPP community has come up with a variety of protocol extensions which have been standardized as JEP's.
A few notable ones which are relevent for this discussion are :
- A flexible discovery mechanism : allowing various clients/servers to interoperate. It helps either side to discover the supported subset and allows protocol extension without breaking compatibility.
- Multi User Chat - though it defines how to set up a 'chat room' : it can be used or modeled to multicast message's to a subset of interested entities.
- A powerful publish subscribe extension for XMPP.
- Advanced message processing allows specifying additional delivery semantics for messages.
- HTTP Binding - allowing XMPP to be bound to HTTP. (More on this later)
We could use xmpp as a middleware for realtime communication and use it for both synchronous and asynchronous notifications. Some examples :
- Pushing information to interested entities - like stock quotes to customers or brokers , etc.
- A whole bunch of publish subscribe usecases can be solved.
- Multicast stanza's as messages to interested entities.
- Allows us to write presence aware applications - the entity in question need not really be another 'person' ! Also , use of CAPS and PeP will definitely make this world of applications much more interesting !
Httpbind essentially can be considered as way to tunnel a xml stream based protocol on top of http : no , not the old CONNECT hack that most implementations use , nor a dumb frequest poll mechanism.
As an analogy , you can consider it to be similar to how you would simulate a persistent stream on top of UDP - only it is HTTP here instead of UDP.
The extension takes care of retransmissions , packet loss , request/response id , etc and makes allowances for HTTP characteristics .
Hence , all the power of XMPP is now available over HTTP.
So be it a rich client application or a rich internet application - both can talk XMPP and harness its power !
And with it , allows all usecases of using XMPP as a realtime messaging middleware available to all developers/users on most platforms - be it a RIA or a thick client.
XMPP - coming to a browser near you