Aperçu technique

Ce document fournit un aperçu technique haut-niveau des technologies Jabber/XMPP.

Introduction

Le terme « XMPP » (anciennement Jabber) est largement utilisé pour désigner un ensemble de protocoles ouverts permettant l'échange de données XML entre deux points quelconques d'un réseau. Mais aussi, pour désigner les technologies utilisant ces protocoles. Bien que Jabber soit principalement connu comme étant une plate-forme de messagerie instantanée et de présence (similaire aux anciens systèmes de MI comme AIM, ICQ, MSN/WLM, et Yahoo!) basé sur XML, le cœur du protocole procure une infrastructure de streaming XML qui est utilisé pour une large variété de systèmes de communication en temps réel.

Ce document propose un petit aperçu technique de l'architecture des technologies Jabber pour la messagerie instantanée et l'échange de présence, bien que beaucoup des principes abordés ici peuvent s'appliquer de manière plus générale. Pour plus d'informations concernant le protocole de Jabber, allez faire un tour sur le site http://xmpp.org/.

Un rapide exemple

L'architecture du système Jabber est très similaire à celle du système de messagerie le plus éprouvé de la planète : l'e-mail. Bien qu'il y ait des différences fondamentales, si vous voyez Jabber comme un « e-mail instantané », vous n'aurez pas vraiment tord. Alors comment est-ce que ça marche vraiment ? Pour comprendre comment, regardons d'abord un rapide exemple : Roméo et Juliette et la fameuse scène du balcon de Shakespeare.

Juliette n'envoie pas de message directement (« pair à pair ») à Roméo, du moins pas dans le monde de Jabber. Juliette à un compte sur un serveur Jabber, et son identifiant Jabber (ou « JID ») ressemble beaucoup à une adresse e-mail. Comme Juliette est une Capulet, elle enregistre son nom d'utilisateur « juliette » avec le serveur Jabber tournant sur capulet.com, comme ça son JID est juliette@capulet.com. De la même manière, Roméo a un compte sur le serveur de sa famille et son JID est romeo@montague.net.

Une fois que Juliette est connectée sur le serveur capulet.com, elle peut envoyer des messages à son ami. Pour être précis, voila ce qu'il se passe lorsque Juliette lance son client windows de son ordinateur portable, sur le balcon :

Juliette envoie un message adressé à romeo@montague.net
Le message est géré par le serveur Jabber de capulet.com
Le serveur capulet.com établie une connexion avec montague.net, s'il n'en existe pas déjà une
En supposant que les parents n'aient pas désactivé les communication serveur-à-serveur entre capulet.com et montague.net, le message de Juliette est envoyé vers le serveur Jabber de montague.net
Le serveur montague.net voit qu'un message est adressé à un utilisateur nommé « romeo » et le fait parvenir au client Jabber tournant sur le PDA de Roméo dans le verger des Capulets.

Il y a beaucoup de choses ici : des clients tournant sur différents systèmes d'exploitation, plusieurs serveurs, un canal de communication entre les serveurs, et deux amoureux. Jabber gère tout sauf la dernière partie. Pour mémoriser le processus, visualisons le avec une image :

Fondation architecturale

Ce schéma vous semble sans doute familier, car il décrit aussi l'architecture de l'e-mail. Les communications pour les e-mails et Jabber sont rendues possibles par un réseau distribué de serveurs parlant un protocole commun. Des clients spécialisés se connectent sur les serveurs afin de recevoir les messages des autres utilisateurs ou d'en envoyer, aussi bien sur le même serveur que sur n'importe quel autre serveur connecté sur le réseau.

Néanmoins, tandis que l'e-mail est un système de stockage et de renvoi, les serveurs Jabber délivrent vos messages pratiquement en temps réel. La livraison immédiate est rendue possible par le fait que le serveur Jabber sait quand vous êtes connecté. Vos contacts le savent aussi, si vous leur donnez la permission de le savoir. La connaissance de votre disponibilité est appelée présence, et c'est la clé de voute qui permet à la messagerie d'être instantanée.

Jabber combine ces caractéristiques standards de la messagerie instantanée avec trois fonctionnalités additionnelles qui rendent la technologie unique. La première est un ensemble de protocoles ouverts, bien documentés, et faciles à comprendre. La deuxième est le fait que les protocoles sont basés à 100% sur XML, ce qui permet une messagerie structurée aussi bien entre des utilisateurs que des applications logiciels. La troisième est que Jabber utilise des adresses qui sont basées sur le DNS et des schémas d'URI reconnus, ce qui permet d'avoir des adresses du même genre que l'e-mail (utilisateur@machine).

Chacun de ces points clés est détaillé plus bas.

Client/Serveur

Les technologies Jabber utilisent une architecture client-serveur, et non une architecture directe en pair à pair comme font d'autres systèmes de messagerie. Cela signifie que toutes les données Jabber envoyées d'un client à un autre doivent passer par au moins un serveur Jabber. (En fait, les clients Jabber sont libres de négocier des connexions directes, par exemple pour l'envoi de fichier, mais ces connexions « out-of-band » sont d'abord négociées en utilisant l'architecture client-serveur.)

Un client Jabber se connecte à un serveur Jabber avec une connexion TCP sur le port 5222 (les serveurs se connectent entre eux avec le port 5269). Cette connexion est toujours active pendant toute la durée de la session du client sur le serveur, le client n'aura donc pas à demander au serveur s'il a reçu des messages, contrairement à un client e-mail. Tous les messages vous étant destinés sont envoyés immédiatement à votre client, tant que vous êtes connecté. Le serveur regarde si vous êtes connecté ou non, et quand vous n'êtes plus connecté il mémorise tous les messages qui vous sont destinés, et vous les envoie lorsque vous vous reconnectez.

Protocoles ouverts

Les technologies Jabber ont débuté dans la communauté open-source avec le serveur jabberd et les clients pour Windows, Mac OS, et Linux. Le travail de l'équipe Jabber a consisté entre autres à définir un protocole ouvert pour du streaming XML sur un réseau. Ce protocole continue de s'approfondir et de s'élargir. L'approfondissement vient principalement du travail effectué par le groupe de travail Jabber de l'Internet Engineering Task Force (IETF); ce groupe à formalisé le cœur du protocole de streaming XML sous le nom « Extensible Messaging and Presence Protocol », et a été approuvé par l'IETF en tant que RFC 3920 et RFC 3921. L'élargissement vient principalement du travail de la XMPP Standards Foundation qui définit des extensions au protocole de base qui offrent des fonctionnalités variées, comme les discussions à plusieurs participants, le transfert de fichiers, la découverte de services, les avatars, et encore beaucoup d'autres.

Puisque toutes les technologies Jabber utilisent un protocole ouvert, n'importe qui peut implémenter ces protocoles, et ils peuvent utiliser n'importe quelle licence. Cela a permis l'explosion du nombre de logiciels Jabber, qui peuvent être aussi bien des serveurs que des clients et aussi bien libres que propriétaires.

Format de données XML

XML est une partie intégrale des technologies Jabber. Pourquoi ? Parce que ça leur permet d'être complètement extensibles et capables de contenir presque n'importe quelle donnée structurée. Quand un client se connecte au serveur, il ouvre un flux XML unidirectionnel du client vers le serveur, et le serveur répond avec un flux unidirectionnel du serveur au client. Ainsi chaque session implique deux flux XML. Toutes les communications entre le client et le serveur passent par ces deux flux, sous la forme de petits morceaux ou « stanzas » de XML, comme le message suivant de Juliette à Roméo :

Exemple 1. Un message simple

<message from='juliette@capulet.com' to='romeo@montague.net'>
  <body>Comment vas-tu, Roméo ?</body>
</message>

Bien que beaucoup de stanzas Jabber sont simples, le format XML de Jabber peut aussi être étendu avec des namespaces XML officiels (gérés par la XMPP Standards Foundation) et des namespaces personnalisés pour des applications spécialisés. Cela fait de Jabber une plate-forme puissante pour transférer des données structurées, incluant des choses comme des appels XML-RPC et SOAP, des flux RSS, et des images SVG.

Réseau distribué

Comme nous l'avons vu, l'architecture de Jabber est faite de la même manière que celle de l'e-mail. Chaque utilisateur se connecte à un serveur « maison », qui reçoit les informations à leur place, et ces serveurs communiquent entre eux à la place des utilisateurs. Ainsi n'importe quel domaine peut avoir son serveur Jabber. Chaque serveur fonctionne indépendamment des autres, et possède sa propre liste d'utilisateurs. De plus, chaque serveur Jabber peut communiquer avec n'importe quel autre serveur Jabber accessible par Internet (si les communications serveur-à-serveur sont activées). Chaque utilisateur est associé a un serveur spécifique (en s'enregistrant avec un fournisseur de service ou avec une configuration administrative dans une entreprise), et les adresses Jabber sont de la même forme que les adresses e-mail. Le résultat est un réseau de serveurs flexible, contrôlable, et qui peut monter en charge bien mieux que les services monolithiques et centralisés utilisés par des fournisseurs de MI comme AOL, Microsoft et Yahoo.

Serveurs modulaires

Un serveur Jabber joue principalement trois rôles :

Gérer les connexions et les communications directement avec les clients Jabber.
Communiquer avec les autres serveurs Jabber.
Coordonner les différents composants serveurs associés avec le serveur.

Les serveurs Jabber ont été conçus pour être modulaires, avec des morceaux de code spécifiques qui gèrent les fonctionnalités comme l'enregistrement, l'authentification, la présence, les listes de contacts, le stockage des messages hors-ligne, et d'autres. En plus, les serveurs Jabber peuvent être étendus avec des composants externes, qui permettent aux administrateurs des serveurs d'ajouter des services au serveur de base, comme des passerelles vers les autres systèmes de messagerie instantanée. De tels composants peuvent introduire d'avantage de complexité dans un déploiement Jabber sans sacrifier la simplicité du serveur et sans nécessiter que ces composants soient approuvés par l'équipe de développement du serveur. Une fois de plus, la flexibilité est une considération cruciale dans la communauté Jabber.

Des clients simples

Un des principes de base du système de messagerie instantanée Jabber était qu'il devait être facile d'écrire un client (e.g., même quelque chose d'aussi simple qu'une connexion telnet). En effet, l'architecture de Jabber n'impose que très peu de restrictions aux clients. Les seules choses qu'un client Jabber doit faire sont :

Communiquer avec le serveur Jabber en utilisant un connexion TCP.
Analyser et interpréter des « stanzas » XML bien formés dans un flux XML.
Comprendre les types de données de base de Jabber (message, presence, et iq).

Il est préférable avec Jabber de déplacer la complexité des clients vers les serveurs. Cela permet de faire des clients relativement facile à faire (comme le témoigne la grande diversité des clients Jabber disponible aujourd'hui) et facilite la mise à jour des fonctionnalités du système (i.e., sans obliger les utilisateurs à mettre à jour leur client). Dans la pratique, beaucoup de fonctions de bas niveau des clients (e.g., interpréter le XML et comprendre les type de base de Jabber) sont gérées par des bibliothèques pour clients Jabber, permettant aux développeurs de clients de se focaliser sur l'interface utilisateur.

Un adressage basé sur des Standards

Sur le réseau Jabber, il y a beaucoup d'entités différentes qui doivent communiquer entre elles. Ces entités peuvent représenter des serveurs, des passerelles, des salons de discussions, un utilisateur Jabber, etc. Des Jabber ID sont utilisés à la fois internement et externement pour définir l'appartenance ou pour router des informations. Les caractéristiques principales des Jabber ID incluent :

Ils identifient de manière unique des objets individuels ou des entités pour échanger des messages ou des informations de présence.
Ils sont faciles à retenir et à transmettre dans le monde réel pour les utilisateurs.
Ils sont suffisamment flexibles pour permettre l'inclusion d'autres MI ou de schémas de présence.

Chaque identifiant Jabber (ou « JID ») contient un ensemble de données ordonnées. Les JID sont formés d'un domaine, d'un nœud et d'une ressource dans le format suivant :

   [nœud@]domaine[/ressource]

Les éléments du JID sont définis comme suit :

L'identifiant du Domaine est l'identifiant primaire. Il représente le serveur Jabber auquel l'entité de connecte. Tout domaine Jabber utilisable devrait être un nom de domaine entièrement défini.
L'identifiant du Nœud est l'identifiant secondaire. Il représente « utilisateur ». Tout les nœuds sont rattachés a un domaine spécifique. Toutefois, l'identifiant du Nœud est optionnel, et un domaine spécifique (e.g. conference.jabber.org) est un Jabber ID valide.
L'identifiant de Ressource est l'identifiant tertiaire, il est optionnel. Toutes les ressources appartiennent à un Nœud. Dans Jabber l'identifiant de Ressource identifie un objet spécifique appartenant à l'utilisateur, comme un appareil ou un lieu. Les Ressources permettent a un utilisateur unique d'avoir plusieurs connexions simultanées avec le même serveur Jabber ; par exemple juliette@capulet.com/balcon et juliette@capulet.com/chambre.

Un utilisateur Jabber se connecte toujours à un serveur en utilisant une ressource particulière et a donc une adresse de la forme noeud@domaine/ressource lorsqu'il est connecté (e.g., juliette@capulet.com/balcon). Toutefois, comme une ressource est spécifique à une session, l'adresse de l'utilisateur peut être communiqué sous la forme noeud@domaine (e.g., juliette@capulet.com), ce qui est familier pour les gens car c'est la même forme qu'une adresse e-mail.

Conclusion

Les protocoles et technologies Jabber fournissent une véritable alternative ouverte aux services fermés et propriétaires offerts par les anciens fournisseurs de MI comme AIM et MSN. La standardisation IETF de Jabber et la base XML permettent aux développeurs de créer une solution robuste, presque temps réelle de messagerie et de présence pour la MI et encore plus. Rejoignez la conversation, visitez http://xmpp.org/.