Modèle de communication par message Réalisé par : Amina GUENFOUD Nour el houda YAHI M2 STIC-recherche 2012/2013

Plan Introduction Définitions Modes de synchronisation Modes de communication Les principes de communication par message: Des points en plus Les MOMs JMS JORAM

Introduction Le modèle de communication par message est un mode de communication très ancien. C’est le mode classique de programmation des réseaux. Il est par exemple utilisé pour le courrier électronique.

Définitions communication : l'ensemble des moyens et techniques permettant la diffusion d'un message auprès d'une audience plus ou moins vaste et hétérogène  message : Les systèmes de messagerie manipulent les messages comme des entités comportant : Un en-tête Des propriétés Un corps message : Les systèmes de messagerie manipulent les messages comme des entités comportant : Un en-tête : qui contient l'ensemble des données utilisées à la fois par le client et le système pour l'identification et l'acheminement du message. Des propriétés : en plus des champs standard de l'en-tête, les messages permettent d'ajouter des champs optionnels sous forme de propriétés normalisées, ou de propriétés spécifiques à l'application ou au système de messagerie. Un corps : le corps de message est définit sous différents types afin de répondre à l'hétérogénéité des systèmes de messagerie.

Modes de synchronisation Messages synchrones Messages asynchrones

Message synchrone (rendez-vous simple) • l'émetteur attend que le récepteur ait lu le message • le récepteur qui attend un message est bloqué jusqu'à son arrivée avantages • émetteur et récepteur sont dans un état connu • on peut implanter des styles de calcul concurrents par flot de données ou par calcul systolique inconvénients • fort couplage entre les correspondants : communication 1 - 1

Message asynchrone (sans attente) • l'émetteur n'est pas bloqué en attente de la réception • le récepteur a un rythme autonome de réception, avec deux modes : - API de réception bloquante si pas de message - API de réception non bloquante, avec un témoin de réception Avantages : • indépendance temporelle des correspondants:communication N - 1 Inconvénients: • pas d'acquittement implicite • pas de relation entre les états de l'émetteur et du récepteur => difficultés en cas d'erreur

Modes de communication Directe Indirecte Le gestionnaire de message ne conserve pas les messages émis un ou plusieurs fils d’exécution traitent les messages reçus si la machine est saturée ou en cas de panne, le message est perdu si le message est perdu, l’émetteur ne le sait pas l’ordre de réception des msgs ne respecte pas l’ordre d’émission La file mémorise les messages émis et les restitue au récepteur quand il le désire ou quand il est prêt l’ajout d’une file de messages à un protocole réseau permet délimiter la perte de messages Le modèle de communication par message peut être direct entre les processus. Le gestionnaire de message ne conserve pas les messages émis. C’est-à-dire que, si le processus récepteur n’est pas joignable à la réception du message, il est perdu. Ce modèle est typiquement celui fourni par les protocoles réseaux, comme par exemple IP ou UDP. Ici, un ou plusieurs fils d’exécution traitent les messages reçus. Mais, si la machine est saturée (plus de fil d’exécution libre) ou en cas de panne, le message est perdu. La communication par envoi de message ne présente pas que des avantages, si le message est perdu, l’émetteur ne le sait pas nécessairement. De plus, l’ordre de réception des messages ne respecte pas nécessairement l’ordre d’émission. Bien évidemment il est possible de réaliser des échanges synchrones par un acquittement de la réception. La communication par message peut aussi être indirecte et passer par une file de messages. La file mémorise les messages émis et les restitue au récepteur quand il le désire ou quand il est prêt. l’ajout d’une file de messages à un protocole réseau permet delimiter la perte de messages, c’est par exemple ce qui est fait dans les sockets Unix qui mémorisent les messages jusqu’à ce que le récepteur les récupère.

Les principes de communication par message: Message Passing (communication par messages) Message Queuing (communication par file de message) Publish/Subscribe (communication par abonnements)

1/Message passing : Principes directeurs communication asynchrone communication directe ou indirecte (via des “portes”) problème de désignation, localisation des entités coopérantes messages éventuellement typés

2/Message Queuing : Queue de messages persistantes => asynchronisme et fiabilité Indépendance de l'émetteur et du destinataire Le destinataire n’est pas forcément actif Les files d'attente de message fournissent des liaisons asynchrones normalisées. Elles ont pour but que l'expéditeur et le récepteur du message ne soient pas contraints de s'attendre l'un l'autre. Des messages placés dans la file d'attente sont stockés, jusqu'à ce que le destinataire les recherche. L'expéditeur n'a pas à attendre que le récepteur commence à traiter son message, il poste son information et peut passer à autre chose.

L’utilisation des files d’attente un administrateur système installerait et configurerait l'intergiciel orienté message puis définirait l'identifiant pour chaque file d'attente de messages. Une application => « écouter » les messages placés sur cette file d'attente. Une autre application se connecterait à cette file d'attente et enverrait un message. Le gestionnaire stockerait le message L'application en réception traite ce message . Dans une implémentation typique de file de messages, un administrateur système installerait et configurerait l'intergiciel orienté message (gestionnaire de files d'attente), puis définirait l'identifiant pour chaque file d'attente de messages. Une application pourrait alors s'enregistrer pour « écouter » des messages placés sur cette file d'attente. Une autre application se connecterait à cette file d'attente et enverrait un message. Le gestionnaire de files d'attente stockerait le message jusqu'à ce que l'application de réception soit connectée, et demande le message en attente. L'application en réception pourrait alors traiter ce message de façon appropriée.

L’utilisation des files d’attente (suite) De nombreux choix impactent la façon précise de passer les messages comme : persistance sécurité  obsolesence Filtrage de messages Stratégie de livraison Persistance : les données envoyées peuvent être simplement gardées en mémoire ou si elles ne doivent pas être perdues même en cas d'échec système seront stockées dans un fichier voire une base de données. Sécurité : les messages et l'accès aux files de messages peuvent être protégés. Obsolescence : les messages et les files peuvent imposer des durées limites de validité. Filtrage de messages : certains systèmes permettent à une application de fournir des critères pour ne recevoir que certains messages. Stratégie de livraison : faut-il garantir que chaque message envoyé est reçu au moins une fois ou plutôt jamais plus qu'une fois ?

3/Publish/Subscribe : Désignation anonyme Communication 1-N L’émetteur envoie un message Basé sur un sujet (subject-based) Basé sur un contenu (content-based) Le récepteur s’abonne (à un sujet ou un contenu) Communication 1-N Plusieurs récepteurs peuvent s’abonner les applications consommatrices des messages s'abonnent à un topic (sujet, catégorie de messages). Les messages envoyés à ce topic restent dans la file d'attente jusqu'à ce que toutes les applications abonnées aient lu le message.

Les Middleware Orientés Messages Les MOMs sont des outils permettant aux applications d'interopérer en échangeant des messages, de manière asynchrone et fiable. Asynchrone : les application ne sont pas à l’attente de l’arriver d’une reponse à ces messages Fiable:garantir l’acheminement des message quelles que soient les circonstances et les aléas:(la connectivité réseu est interrompue , le serveur distant est arrêté…,)

Les Middleware Orientés Messages Les systèmes de communication asynchrones, fondés sur l'envoi de messages : connaissent aujourd'hui un regain d'intérêt dans le contexte des applications réparties sur Internet. Les modèles de communication asynchrones : prennent en compte l'indépendance entre entités communicantes et sont donc mieux armés pour traiter des problèmes Ces problemes sont : l'éloignement géographique des entités communicantes la possibilité de déconnexion temporaire d'un partenaire en raison d'une panne ou d'une interruption de la communication Les systèmes de communication asynchrones, fondés sur l'envoi de messages, connaissent aujourd'hui un regain d'intérêt dans le contexte des applications réparties sur Internet. Les modèles de communication asynchrones prennent en compte l'indépendance entre entités communicantes et sont donc mieux armés pour traiter les problèmes : l'éloignement géographique des entités communicantes la possibilité de déconnexion temporaire d'un partenaire en raison d'une panne ou d'une interruption de la communication

Les couches des MOMs Le modèle de passage de messages (ou modèle de Message Passing) réalise l’envoi de messages simples. Il constitue la couche de base des middlewares orientés messages. Au dessus de cette couche, on trouve d'autres couches de middlewares de plus en plus perfectionnées et qui sont : Le Message Queuing qui ajoute la notion de persistance Le modèle par abonnement (ou modèle Publish/Subscribe), qui utilise les fonctions du Message Passing ou du Message Queuing et qui ajoute la notion d’anonymat et d’abonnement.

Les Middleware Orientés Messages Caractéristiques Transport de messages Communication asynchrone Routage Transformation des données Persistance des messages Fiabilité Caractéristiques • Communication asynchrone. L'application émettrice d'un message et l'application réceptrice du message n'ont pas besoin d'être actives en même temps. La file d'attente reçoit le message de l'application émettrice et le stocke données qui peuvent être dans n'importe quel format. • Transport de messages. Les messages comportent deux parties: l'en-tête technique, utilisée par le MOM et les jusqu'à ce que l'application réceptrice vienne lire le message. • Transformation des données. La plupart des MOM permettent de changer le format des données contenues dans les messages pour les adapter à l'application réceptrice. Cette capacité est proche de celle des outils d'EAI distants disposant chacun d'un MOM installé localement. • Routage. Les messages peuvent être routés entre MOM. Par exemple, pour router un message entre deux sites • Fiabilité. Chaque message envoyé par une application fait l'objet d'un accusé de réception par le MOM. Chaque • Persistance des messages. Les messages présents dans les files d'attente peuvent être sauvegardés sur un support physique pour en assurer la conservation en cas de panne. (Enterprise Application Integration) dont ils constituent parfois le noyau. mécanisme permet de garantir qu'aucun message ne sera perdu dans son transfert entre les applications. application qui consomme un message envoie un accusé de réception au MOM. Couplé avec la persistance, ce

Inconvénients des MOMs Avantages des MOMs Gérer le problème d’éloignement géographique Gérer le problème d’hétérogèneité éviter l’implémentation des différents types de communication au niveau de chaque application La permanence de applications n’est pas obligatoire Inconvénients des MOMs Nécessité d’installation et configuration un composant logiciel supplémentaire pour faire communiquer les applications (qui est souvent difficile) Avantage des MOMS : éloignement géographique Applications destinataires ne fonctionnant pas obligatoirement en permanence éviter l’implémentation différents types de communication au niveau de chaque application puisque ils sont installés au niveau du MOM (API dans MOM) Possèdent des APIs dans plusieurs langages et tournent sur différents systèmes d’exploitation ce qui facilite la connectivité entre applications hétérogènes.   Inconvénients des MOMs : Nécessité d’installation et configuration un composant logiciel supplémentaire pour faire communiquer les applications (qui est souvent difficile) et qui peut être un avantage aussi qui est celui de s’affranchir de l’implémentation de la couche envoi/réception de message au niveau de chaque application.

JMS (Java Messaging Service) JMS est la spécification d'un service de messagerie en Java => elle est la norme pour accéder aux fonctionnalités des MOM dans le monde JAVA Pendant de nombreuses années l'essor des systèmes de communication asynchrones a été retardé par l'absence de normalisation. Les intergiciels à messages sont donc restés propriétaires à la fois du point de vue du modèle de programmation et de leur implémentation. A la fin des années 90, l'émergence de la spécification JMS (Java Messaging Service) dans le monde Java a partiellement comblé ce handicap,

JMS : Modèle de communication Point à Point Deux modes de communication (Messaging Domains) sont fournis par la spécification JMS :  La communication point à point est fondée sur des files de message (Queues) . Un message est adressé à une queue par un client producteur. Un message est consommé par un seul client. Le message est stocké dans la queue jusqu'à sa consommation ou jusqu'à l'expiration d'un délai d'existence. La consommation d'un message peut être synchrone (retrait explicite par le consommateur - flots 2 et 3) ou asynchrone (activation d'une procédure de veille préenregistrée chez le consommateur - non représenté dans la figure 2) par le gestionnaire de messages. La consommation du message est confirmée par un accusé de réception généré par le système ou le client.

JMS : Modèle de communication Publish/Subscribe La communication multipoints est fondée sur le modèle publication/abonnement (Publish/Subscribe) . Un client producteur émet un message concernant un sujet prédéterminé (Topic) (flot noté 2). Tous les clients préalablement abonnés à ce Topic (flots 1a et 1b) reçoivent le message correspondant (flots 3a et 3b). Le modèle de consommation (implicite/explicite) est identique à celui du mode point à point.

JORAM : une mise en œuvre d'un JMS JORAM (Java Open Reliable Asynchronous Messaging) : est une Implémentation 100% Java de la spécification JMS

JORAM : une mise en œuvre d'un JMS Comme toutes les autres réalisations de plates-formes JMS, JORAM est structuré en deux parties : une partie ««serveur JORAM»» qui gère les objets JMS (Queues,Topics , connexions, etc.) et une partie «« client JORAM »» qui est liée à l'application cliente JMS. le serveur JORAM peut être mis en œuvre de façon centralisée ou de façon distribuée. La communication entre un client JORAM et un serveur JORAM s'appuie sur le protocole TCP/IP. La communication entre deux serveurs JORAM peut utiliser différents types de protocoles selon les besoins (TCP/IP, HTTP, SOAP, communication sécurisée via SSL). Client et serveurs peuvent être sur des machines physiques différentes ; ils peuvent partager la même machine et s'exécuter dans des processus différents ou partager le même processus.

MERCI