News Geek on the Block

Brainstorming session: XMPP integration into real time web application

We, at @linagora, are currently developing a new open source project: OpenPaaS (@awesomepaas). One of the component of this platform is an Enterprise Social Network (ESN), ie the Facebook++ for the enterprise. When it comes to social stuff, we first think about sharing statuses, connecting to people and messaging. And since we are open, XMPP seems natural for the messaging part.

This article is a summary of the brainstorming session we had internally, gives some XMPP basis and how we plan to use it in OpenPaaS ESN.
XMPP stands for eXtensible Message and Presence Protocol. This well known protocol is completely awesome, but let’s look at the basis. XMPP is a collection of open standards for real time messaging based on a completely decentralized architecture which allows to create collaborating systems and multimedia exchanges (VoIP and video conferences are good examples).
The initial idea is pretty simple, it allows to exchange XML messages between client/server and server/server and allows to create a platform based on a mix of public and private networks. The XMPP is defined to be extensible at its basis:
 — The base protocol is defined in some RFCs (Request For Comments). Nothing will work without them.
 — Anyone can create extensions aka XEP: XMPP Extensions Protocols. These are some proposals of addons to the base protocol. 
The XMPP protocol has been created almost 20 years ago in 1998 (yes you are quite old now…), the first server implementation was out in 2000. What a success! It is today used by millions (billions) of people since it is used by most of the major Internet actors for instant messaging: Google, Facebook, Apple, Skype, MSN… It can be (and is) also used for monitoring, data transfer, white boards, games…
It reminds me that I created some transport layer for Petals Enterprise Service Bus which allowed us to exchange messages between instances distributed across the Internet using Google XMPP infrastructure platform as transport layer.
As introduced before, the overall architecture is pretty simple, when a user A wants to send a message to user B, the message goes from ‘user A’ client to ‘user A server’, if ‘user B’ is connected to the same server, the message is sent from the server to the client. If ‘user B’ is connected to another server, the ‘user A’ server sends the message to ‘user B’ server which will be in charge of delivering the message to ‘user B’.
This is quite simple to understand, as the addressing schema:
Where ‘user’ is the user name, ‘server’ is the server name and ‘resource’ is an optional resource name. ‘resource’ is optional but quite useful: it allows to distinguish clients since you can be connected at the same time with many of them. As an example, one can choose to send a message on my mobile phone instead of my laptop by just sending the message to Did you get it?
As an additional feature, there are some priorities which can be defined on clients, based on when the connection occurred, some user data, etc. This is quite complex and the RFC will describes it better than me.
Let’s move to the presence part of XMPP. The process is simple again. When a user connects to its server, the server notifies the user’s contacts with a specific message. This is the same when the user defines a ‘status’. This is quite simple to achieve since the user’s contacts are stored on the server.
There are many more features which are available in the XMPP specification like groups (N to N discussions), transports (Gateways between protocols ie how to send a message to an IRC buddy), file transfer, etc…

The most interesting ones are new extensions which provides communication protocols on top of web compliant technologies such as BOSH (Bidirectional-streams Over Synchronous HTTP) and websockets. In some words, these extensions allows to create XMPP-based communication between your web browser and the XMPP server: The browser can now open a XMPP connection to the server over HTTP where it was not possible before. This is a completely Awesome part which open new horizons!

With all of this popular stuff, we should be able to create a real time web application using XMPP and some of its extensions. In our current use case, the the goal is not just only to create a chat but all the messaging and presence system in the platform. To achieve this we defined some ‘simple’ requirements:

  1. Big Data: All the messages exchanged will to be stored, as well as presence, status, … Additionally, we plan to create some really ambitious integration with other sources feeding the platform like Twitter, Facebook, … 
  2. Real time web: Because we want to create a completely dynamic platform. 
  3. Open: We do not want to force users to connect to the web application to chat, we are open to other channels like standard XMPP clients, mobile applications, bots, …
    This is where the fun part comes. We are currently building an architecture which leverages these three points:
  4. We are using Mongodb, Elasticsearch, Redis and some other fun storage stuff (not only because it is fun and fashion but because it is completely aligned with our needs).
  5. Node.js and frontend stuff like AngularJS coupled with SocketIO are really good candidates to leverage the real time part. What is exchanged between parts are events, and javascript does the job. Just have a look to this gist to see how simple it is to play with XMPP events in the backend (node) or in the frontend (angular in our case):

So, now using XMPP over Websocket or Bosh and with very little effort, we are able to provide a real time messaging in the browser. Easy as usual, thanks to XMPP and the JS community. Stay tuned for some real code to be released soon!


, ,

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>