Les problématiques de push de messages vers des clients connectés (encore appelé "web messaging") sont courantes dans les secteurs où l’information varie sur des temps très court, comme la finance, la sureté, la supervision ou encore les réseaux sociaux. Les données doivent être diffusées le plus rapidement possible à de nombreux clients, car ces données n'ont de valeur (ou d'intérêt) que pendant un temps limité.

Pour faire du web messaging, il existe aujourd’hui différentes techniques (polling, « comet » long polling et streaming) qui s’appuient sur des technologies variées (XmlHttpRequest, WebSocket, Flash socket, Silverlight socket, iFrame, RTMP). Le marché évolue d’ailleurs clairement dans ce sens : des solutions, jusqu’à présent concentrées sur la problématique Message-Oriented Middleware (RabbitMQ, HornetQ) offrent désormais une API HTTP, avec pour certaines d’entre elles, une API cliente basée sur WebSocket (même si cette technologie n’est pas encore compatible avec tous les navigateurs).

Nous allons ici parler d’une de ces solutions, permettant à la fois d’assurer une grande compatibilité et de hautes performances : Diffusion. Cet article a pour objet de présenter cette solution. Il se découpera en deux parties :

• Une présentation des concepts et du framework Diffusion
• Une présentation plus technique via la mise en œuvre d'un POC

1. Qu’est ce que Diffusion ?

Diffusion est une solution standalone de diffusion de message éditée par la société PushTechnology, société fondée en 2006 et basée à Londres, spécialisée dans les problématiques de middleware orientés messages et de push web.

PushTechnology propose :

• Un serveur, appelé Diffusion Message Broker, basé sur le protocole TCP
• Une surcouche orientée push web, appelée Diffusion Internet Message Broker, basé sur les protocoles HTTP et WebSocket
• Une API, disponible dans différents langages

1.1. Diffusion Message Broker

Le serveur Message Broker est un serveur orienté message développé en Java, multi-threadé et utilisant le framework NIO (gestion d’I/O non bloquantes) afin de garantir le service auprès d’un grand nombre de clients concurrents.

Citons quelques-unes des key features mises en avant par l’éditeur :

• Hautes performances : jusqu’à 300k messages (de l’ordre de quelques octets) par seconde pour un unique broker déployé sur un serveur de configuration standard et dans un contexte intranet. L’éditeur n’indique pas d’informations supplémentaires sur les conditions de test. Il est à noter que ces messages sont au format binaire, permettant ainsi d’adapter leur structure au plus proche des besoins et de transmettre tout type de contenu.
• Très faible latence (de l’ordre de quelques millisecondes) et synchronisation entre les différents brokers au sein d’une architecture distribuée, permettant d’assurer l’intégrité des messages et leur localisation à tout instant.
• Canaux bidirectionnels de transmission des messages : un client peut donc répondre à un message qui lui serait soumis.

1.2. Diffusion Internet Message Broker

L’une des spécificités de la solution Diffusion, celle qui nous intéresse aujourd’hui, est qu’elle offre une surcouche orientée web (et donc sur protocole HTTP). Appelée internet message broker, cette surcouche permet de diffuser des messages via Internet à destination de navigateurs, clients mobiles ou clients lourds connectés. Des tests de performance réalisés par l’éditeur ont montré qu’il était possible de diffuser jusqu’à 90k messages par secondes auprès de tels clients via Internet (conditions de test non précisées).

Plusieurs API sont ainsi mises à disposition afin de connecter ces différents types de clients à un broker Diffusion, parmi lesquelles :

• Navigateur : JavaScript, Flash, Silverlight,
• Client mobile : Android, iOS, Windows Phone, J2ME
• Client lourd : Java, .Net

Les protocoles disponibles sont les suivants :

• Web Socket
• Flash socket
• Silverlight socket
• XmlHttpRequest (HTTP Callback ou IFrame + long polling)
• RTMP (streaming de médias)

L’API JavaScript se différencie des autres API disponibles car elle possède un mécanisme de « fallback » : elle est capable de permuter parmi les 5 protocoles disponibles en fonction de la nature du client et de la connectivité disponible. Ce choix est donc transparent à la fois pour l’utilisateur et pour le développeur.

2. Focus sur Internet Message Broker

Comment fonctionne Diffusion et comment utiliser les différentes API mises à disposition afin d’implémenter rapidement une solution basée sur du web messaging ? Ouvrons un peu plus le capot…

2.1. Architecture

Le schéma ci-après présente le schéma général d’une architecture Diffusion :

On distingue trois couches :

• Les sources de message ou d’événement (en haut du schéma)
• La centralisation, le traitement et la distribution de ces messages (la couche Diffusion Message Broker)
• Les consommateurs de message (la couche Diffusion Clients)

Nous allons détailler ces différentes couches dans ce qui suit.

2.2. Concepts

Dans son implémentation la plus simple, une architecture Diffusion est constituée de Topics, de Publishers et de Clients. Transitent entre ces acteurs des TopicMessages, qui peuvent être routés de manière avancée grâce à différents mécanismes.

2.2.1. Le socle Topic, Publisher, Client

Les Topics sont des fils de messages sur lesquelles il est possible de publier. Ils peuvent être hiérarchisés en sous Topics. Ainsi, un message publié à la racine d’un arbre sera diffusé dans toutes ses branches, autrement dit dans chacun des sous Topics.

Les Topics peuvent être déclarés :

• Par configuration, lors du déploiement d’un serveur Diffusion
• Programmatiquement (dans le code des « Publisher », voir ci-après)

Les Publisher sont garants d’un ou plusieurs Topics mais également des Clients y souscrivant. Ils ont pour rôle de traiter les nouveaux messages et leur diffusion auprès d’un, plusieurs ou la totalité des clients ayant souscrit au Topic. Un Publisher peut être de deux types :

• internal : ils sont alors déployés au sein du serveur Diffusion. C’est la forme de Publisher recommandée.
• external : ils sont alors déployés à l’extérieur d’une instance Diffusion et s’enregistrent auprès des serveurs Diffusion disponibles. Leur utilisation peut être justifiée par des besoins fonctionnelles ou techniques.

Ils ont donc à leur charge la transmission des nouveaux messages vers tout ou partie des clients ayant souscrit au Topic.

Les Clients se connectent sur un serveur Diffusion et s’inscrivent à un ou plusieurs Topics. Ils reçoivent ainsi tous les messages dès lors qu’ils sont publiés sur ces derniers, mais ils peuvent également en publier de nouveaux : la chaine de transmission des messages est bidirectionnelle.

Chaque Client possède sa propre pile de messages au sein d’une instance Diffusion. Cette pile est de type FIFO. Elle est alimentée par les Publishers et continuellement déchargée à destination du Client.

2.2.2. Les TopicMessages

Un TopicMessage est l’implémentation des messages échangés entre les différents acteurs. Il se compose de fixed headers (utilisés par Diffusion pour sa mécanique interne), de user headers et d’un bloc user data (zone libre du message pour l’utilisateur).

Le contenu d’un message est binaire. Diffusion propose une hiérarchisation des données en deux niveaux grâce à des records, des fields et des delimiters. Ces delimiters sont en réalité de simples caractères ASCII, permettant de sérialiser simplement les données.

Il est possible d’utiliser des métadonnées afin de décrire les différents champs composants un message. Ces métadonnées permettent également de faire de la validation et de la transformation des données. Elles ne sont pas transmises avec le message et devront donc être connues à l’avance par les différents lecteurs du message.

Un TopicMessage existe sous deux formes :

• Load message : reçu par le client lors de la souscription à un Topic. Il permet généralement d’initialiser un contexte
• Delta message : utilisé après le LoadMessage, il permet de transmettre toutes les mises à jour du contexte

Il peut également avoir trois états :

• Normal : le message est ajouté sur la pile de chacun des Clients
• Expedited : c’est un message prioritaire, il est ajouté au début de chaque pile (de chaque client) ayant souscrits au Topic. Il est donc le suivant à partir.
• R__equiring acknowledegement : ce message requiert un acquittement de la part de son destinataire. Si le message n’a pas été acquitté, il est placé dans une file dédiée et le publisher est alors notifié.

Aux différents acteurs étant en mesure de publier sur un Topic, nous pouvons ajouter l’EventPublisher. Il permet d’implémenter facilement des sources externes d’événements, directement connectées à un ou plusieurs Topics via un Publisher. Il peut s’intégrer à n’importe quel applicatif Java ou .Net grâce aux deux API mises à disposition.

2.2.3. Mécanismes avancés de traitement de files

Diffusion propose une gestion avancée des files de messages, avec entre autre les mécanismes suivants :

• La conflation : correspond aux messages dupliqués ou similaires au sein d’une file. Il ainsi possible de définir des règles de comparaison de message permettant d’éviter ce genre de situation. En plus d’offrir une information plus pertinente aux clients, cette technique permet de réduire le trafic sur le réseau, en évitant l'envoie de messages inutiles car déjà obsolète.
• Le throttling : correspond à la capacité de temporiser (bufferiser) les messages avant leur envoi vers le Client. Cette technique permet de contrôler la bande passante. Il est possible de régler le throttling pour chaque client selon 3 critères :
  • le nombre de message par seconde
  • le nombre d’octet par seconde
  • l’intervalle de temps entre chaque message.

3. Conclusion

L’architecture et les mécanismes de Diffusion ne divergent pas tellement de celle d’un autre Message-Oriented Middleware, et les habitués retrouveront rapidement leurs marques. L’intérêt est ici de pouvoir connecter facilement un grand nombre de clients web, quel qu’en soit leur nature, à des files de messages.

Dans la seconde partie, nous aborderons, autour d’un use-case simple, les bases permettant de mettre en œuvre un navigateur connecté recevant des informations en temps réel depuis un serveur Diffusion.