Universal Messaging est un middleware orienté message qui garantit la livraison de messages sur les infrastructures publiques, privées et sans fil.
Universal Messaging a été construit à partir de zéro pour surmonter les défis de la livraison des données sur différents réseaux.
Il fournit sa fonctionnalité de messagerie garantie sans l’utilisation d’un serveur Web ou des modifications à la politique de pare-feu.
La conception de messagerie universelle prend en charge les communications basées sur les courtiers et umTransport, et comprend ainsi des composants client et serveur.
Communication basée sur les courtiers
Le composant client standard basé sur un courtier de messagerie unifiée peut être subdivisé en messagerie clients, clients comètes et clients de gestion. Le composant serveur a une conception spécifique avec des fonctionnalités pour prendre en charge chacune de ces classifications de client ainsi que la planification : Déclencheurs, plugins, fédération, clustering et faible latence IO.
Composants du serveur
Le serveur de domaine de messagerie universelle est un processus Java fortement optimisé capable de fournir un débit élevé de données à un grand nombre de clients tout en garantissant des latences réduites au minimum.
En plus de prendre en charge les types de clients décrits ci-dessous, le serveur de domaine Universal Messaging possède un certain nombre de fonctionnalités intégrées pour assurer la flexibilité et les performances au plus haut niveau.
Composants clients
Universal Messaging prend en charge 3 types de clients :
- Clients de messagerie
- Clients comètes
- Clients de gestion
Chaque type de client a été développé à l’aide de protocoles ouverts avec une attention particulière sur les performances et le déploiement externe.
Chaque type de client a été spécialement conçu pour passer en toute transparence à travers les pare-feux et autres infrastructures de sécurité tout en fournissant ses propres fonctions de sécurité inhérentes.
Clients de messagerie
Les clients de messagerie Universal Messaging prennent en charge les modèles synchrones et asynchrones de middleware. Les fonctionnalités de publication d’abonnement et de files d’attente sont toutes prises en charge et peuvent être utilisées indépendamment ou en combinaison les unes avec les autres.
Les clients de messagerie Universal Messaging peuvent être développés dans un large éventail de langues sur un large éventail de plateformes. Java, C # et C ++ fonctionnant sous Windows, Solaris et Linux sont tous pris en charge. Les appareils mobiles et les technologies Web existent en tant que clients de messagerie natifs.
WebSocket, Comet et LongPolling pour les clients JavaScript
En plus de notre protocole de fil binaire natif, Universal Messaging prend également en charge la livraison de texte basée sur les langues qui ne prennent pas en charge les données binaires. Utilisé conjointement avec la technologie de plug-in de serveur de messagerie universelle, les clients Comet et Long Polling utilisent des connexions HTTP et persistantes pour fournir une fonctionnalité de publication asynchrone aux clients. Les clients JavaScript peuvent également utiliser WebSocket comme approche de livraison bien que cela ne soit pas encore suffisamment pris en charge dans les navigateurs des utilisateurs pour justifier sur Comet / Long Polling.
Clients de gestion
Universal Messaging fournit une API de gestion très étendue et sophistiquée écrite en Java. Les clients de gestion peuvent créer des ressources (canaux, listes de contrôle d’accès, files d’attente, etc.) et les données de gestion des requêtes (débit, état du cluster, nombre de connexions, etc.) directement à partir des serveurs de domaine de messagerie universelle.
umTransport Communication
Universal Messaging propose, en plus de son API client-serveur standard complète, une API de communication client-client extrêmement légère appelée umTransport API (actuellement disponible pour Java et C ++).
umTransport API
Universal Messaging propose, en plus de son API client-serveur standard complète, une API de communication client-client extrêmement légère appelée API umTransport. Modèle basé sur les courtiers. Historiquement, l’architecture de messagerie a été principalement basée sur un «courtier» dans le approche moyenne. C’est ce qu’on appelle souvent le «hub and speak». Le courtier agit comme hub de communication, routage des messages entre pairs découplés logiquement :
Le modèle pub-sub est un paradigme courant pour l’architecture basée sur les courtiers, où un ou davantage d’éditeurs envoient des messages au courtier, qui les distribue ensuite aux consommateurs intéressés.
Modèle umTransport
Le modèle umTransport est un modèle d’égal à égal qui permet aux pairs de savoir comment de communiquer directement entre eux plutôt que par l’intermédiaire d’un courtier. En effet, chaque éditeur pair agit comme un serveur, et chaque consommateur peut communiquer directement avec les éditeurs :
Bien que ce modèle contourne les fonctionnalités de messagerie du courtier telles que la persistance ou la sémantique transactionnelle, elle se traduit par une latence de livraison des informations considérablement plus faible d’un éditeur à un consommateur.
En réduisant de moitié le nombre de «sauts» entre le client et éditeur, la latence est également réduite de moitié.
