Message Oriented Middleware Plan Pourquoi un nouveau type

Message Oriented Middleware

Plan • • Pourquoi un nouveau type de middleware? Quelle lignée logicielle ? Historique JMS : Java Message Server L’implémentation Joram L’avenir pour ce type de middleware

Pourquoi un nouveau type de middleware?

Intention Quelles sont les contraintes RPC derrière RMI ? communication synchrone Client-Serveur le serveur est prédominant dans la communication On souhaite ne pas être bloqué pendant une communication (asynchrone) ne pas connaître toujours au préalable ceux avec qui on communique

Exemple l’administration de réseaux • Gestion à distance de machines, serveurs, hubs, etc • Notification des événements en cas de panne

Objectifs principaux – Intégration de modules hétérogènes distribués – Indépendance (asynchronisme) – Fiabilité

Quelle lignée logicielle ? Historique Ce que vous connaissez déjà

Quelle lignée logicielle ? Historique • Communication par message au niveau socket : communication udp et multicast • Connexions faibles entre objets : le design Pattern Observer Observable • Programmation Java : interface graphique et gestion d’événements (listeners) • Et en Corba : le service d’événements

Communication par message : Envoi de datagrammes Serveur Client req 1 rep 1 application reqn repn opération

Communication par diffusion : Multicast Serveur Client 1 application Client 2 application Clientn application Gr

Observer Observable

Motivation • Un effet de bord fréquent de la partition d’un système en une collection de classes coopérantes est la nécessité de maintenir la consistance entre les objets reliés entre eux. • On ne veut pas obtenir la consistance en liant étroitement les classes, parce que cela aurait comme effet de réduire leur réutilisabilité.

Moyen Définir une dépendance de “ 1” à “n” entre des objets telle que lorsque l’état d’un objet change, tous ses dépendants sont informés et mis à jour automatiquement

Quand l’appliquer • Lorsqu’une abstraction possède deux aspects dont l’un dépend de l’autre. – L’encapsulation de ces aspects dans des objets séparés permet de les varier et de les réutiliser indépendemment. – Exemple : Modèle-Vue-Contrôleur • Lorsqu’une modification à un objet exige la modification des autres, et que l’on ne sait pas a priori combien d’objets devront être modifiés. • Lorsqu’un objet devrait être capable d’informer les autres objets sans faire d’hypothèses sur ce que sont ces objets,

Besoin d’événements • Le pattern “Observer” décrit – comment établir les relations entre les objets dépendants. • Les objets-clés sont – la source • Peut avoir n’importe quel nombre d’observateurs dépendants • Tous les observateurs sont informés lorsque l’état de la source change – l’observateur. • Chaque observateur demande à la source son état afin de se synchroniser

Structure

Collaborations

Bénéfices • Utilisation indépendante des sources et des observateurs. – On peut réutiliser les sources sans réutiliser les observateurs et vice-versa. – On peut ajouter des observateurs sans modifier la source et les autres observateurs. • Support pour la communication “broadcast” – La source ne se préoccupe pas du nombre d’observateurs.

Implémentations Java du pattern Une classe et une interface : class Observable {. . . } et interface Observer Un objet Observable doit être une instance de la classe qui dérive de la classe Observable Un objet observer doit être instance d’une classe qui implémente l’interface Observer void update(Observable o, Object arg); Des listeners

Le service d’événement Corba

Récepteur Emetteur message Destination Emetteur et récepteur connaissent seulement la destination Plusieurs émetteurs et récepteurs sur la Même destination Persistance du message (reçu ou non reçu) Format du message libre Acheminement par un bus de message

Le service de notification d'événements Corba La plupart des requêtes CORBA se traduisent par l’exécution synchrone d’une opération (le client connaît la référence de l’objet auquel la requête s’adresse et le client ainsi que l’objet doivent être tous deux actifs) et sinon? Le service d'Evénements ou Event service permet de découpler la communication entre objets. Mode de communication découplé : ü lorsque le client et l’objet ne se connaissent pas; ü lorsque le client et l’objet ne sont pas actifs simultanément.

Communication événementielle principes de fonctionnement • concepts de base : événements, réactions (traitements associés à l’occurrence d’un événement) • principe d’attachement : association dynamique entre un nom d’événement et une réaction • communication anonyme : indépendance entre l’émetteur et les “consommateurs” d’un événement

Un canal d’évènements Flot des évènements Consommateur Producteur Canal Consommateur

Un canal d’évènements : notification Push. Consumer Push. Supplier Consommateur Push Producteur void push(in any data) raises(Disconnected); Consommateur Producteur Push Canal Consommateur Producteur actif / Consommateur réactif Le canal diffuse les évènements

Un canal d’évènements : demande Consommateur Pull() Producteur Consommateur Producteur Pull() Canal Consommateur Pull. Supplier { //demande de production d’un événement demande any pull() raises(Disconnected); Consommateur // présence d’un événement any try_pull(out boolean has_event) raises(Disconnected); Producteur réactif / Consommateur actif Le canal procure les évènements

Un canal d’évènements : file d’évènements Consommateur Pull() Producteur Consommateur Producteur Push() Canal Consommateur Producteur actif / Consommateur actif Le canal gère des files d’évènements

Un canal d’évènements : collecte d’évènements Consommateur Push() Producteur Consommateur Producteur Pull() Canal Consommateur Producteur réactif / Consommateur réactif Le canal est une entité active voire intelligente

Principe des MOM

Introduction • Modèle de communication entre logiciels –Intégration de modules hétérogènes distribués –Indépendance (asynchronisme) –Fiabilité

Message Oriented Middleware (MOM) NT

Récepteur Emetteur message Destination Emetteur et récepteur connaissent seulement la destination Plusieurs émetteurs et récepteurs sur la même destination Persistance du message (reçu ou non reçu) Format du message libre Acheminement par un bus de message

Systèmes de messages • 2 mode de communication – Modèle point à point • Couplage lâche • Asynchronisme • Communication par message – Modèle par diffusion • • Notification Diffusion à une liste, un groupe d’intérêt Surveillance du réseau Communication par événement

Principe de base des MOM • Message Queueing –Queues de messages persistantes –Transmission des messages asynchrone (stockage des messages si nécessaire) –Reprise après panne –Un émetteur remet son message au système et peut continuer son exécution sans se soucier de l’état du destinataire

2 modes • Mode push – Le serveur diffuse une information – Le récepteur reçoit l’information • Publicité, spam • Mode pull – Le serveur livre une information – Le récepteur va cher l’information • Consultation méteo

Le message • Non formatté • Mais on peut utiliser XML – Et ajouter au contenu : une entête, des propriétés – Entête peut contenir des informations permettant l’identification et l’acheminement du message – Propriétés couples utilisables pour sélectionner messages et/ou destinataires

Caractéristiques des MOM • Modes de communication –Point-à-point (PTP): émetteur, récepteur et queue –Publication/Souscription (Pub/Sub): émetteur, abonné et nœud

Caractéristiques des MOM • Modèle de programmation –Réception explicite / implicite • Messages –Messages dotés d’attributs et de propriétés –Priorités, garantie de délivrance

Java Message Service

L’interface Java Message Service (JMS) • API Java d’accès uniforme aux systèmes de messagerie Client JMS Provider X JMS Client JVM MQ X Provider X JVM MQ X

Architecture JMS Client JMS Emetteur Récepteur message Destination Serveur de messages

Architecture JMS Client JMS Connection Session Producer Consumer message Destination Serveur de messages

Architecture JMS Une connexion est liée à un serveur de message Une session existe à l’intérieur d’une connexion Il peut y avoir plusieurs session par connexion La session gère le processus global de transmission Le consommateur/producteur existe seulement à l’intérieur d’une session Le consommateur/producteur connaît la destination Le message n’existe qu’à l’intérieur d’une session

2 types de destinations • Queue pour le point à point – Chaque message n’a qu’un consommateur – Pas de couplage temporel fort • Topic pour le publish/subscribe – Similaire à un modèle d’événements – Un message peut avoir plusieurs consommateurs par abonnement – Abonnement et activité du consommateur requise

Point à Point et Publish/ Subscribe Client 1 send Client 2 Le consommateur envoie un reçu Le message est détruit à réception du reçu acknowledges Il peut y avoir plusieurs consommateurs en attente consumes queue Un client doit s’abonner au préalable Tous les abonnés reçoivent Le message publié Client 1 publishes subscribes delivers Client 2 subscribes delivers Client 3

Le mode Point-à-Point (PTP) receive send Emetteur Récepteur queue

Le mode Point-à-Point (PTP) Queue. Connection. Factory Queue. Connection Queue. Session + send + receive Queue. Sender Emetteur Queue. Receiver Récepteur

Etapes du mode Point-à-Point Emetteur Destinataire Trouver la queue Créer une connexion et une session

Etapes du mode Point-à-Point Emetteur Destinataire Trouver la queue Créer une connexion et une session Spécialiser une communication d’envoi sur la queue

Etapes du mode Point-à-Point Emetteur Destinataire Trouver la queue Créer une connexion et une session Spécialiser une communication D’envoi sur la queue Spécialiser une communication de Réception sur la queue

Etapes du mode Point-à-Point Emetteur Destinataire Trouver la queue Créer une connexion et une session Spécialiser une communication D’envoi sur la queue Spécialiser une communication de Réception sur la queue Envoyer un message sur la queue

Etapes du mode Point-à-Point Emetteur Destinataire Trouver la queue Créer une connexion et une session Spécialiser une communication D’envoi sur la queue Spécialiser une communication de Réception sur la queue Envoyer un message sur la queue Demander la réception d’un message

Etapes du mode Point-à-Point Queue. Connection. Factory connection. Factory = (Queue. Connection. Factory) messaging. lookup("…"); Queue queue = (Queue) messaging. lookup("…"); Queue. Connection connection = connection. Factory. create. Queue. Connection(); Queue. Session session = connection. create. Queue. Session(…);

Etapes du mode Point-à-Point Queue. Connection. Factory connection. Factory = (Queue. Connection. Factory) messaging. lookup("…"); Queue queue = (Queue) messaging. lookup("…"); Queue. Connection connection = connection. Factory. create. Queue. Connection(); Queue. Session session = connection. create. Queue. Session(…); Queue. Sender sender = session. create. Sender(queue); String selector = new String("(name = 'Bull') or (name = 'IBM'))"); Queue. Receiver receiver = session. create. Receiver(queue, selector);

Etapes du mode Point-à-Point Queue. Connection. Factory connection. Factory = (Queue. Connection. Factory) messaging. lookup("…"); Queue queue = (Queue) messaging. lookup("…"); Queue. Connection connection = connection. Factory. create. Queue. Connection(); Queue. Session session = connection. create. Queue. Session(…); Queue. Sender sender = session. create. Sender(queue); String selector = new String("(name = 'Bull') or (name = 'IBM'))"); Queue. Receiver receiver = session. create. Receiver(queue, selector); Text. Message msg = session. create. Text. Message(); msg. set. Text("…"); sender. send(msg); Text. Message msg = (Text. Message) receiver. receive();

Etapes du mode Point-à-Point Queue. Connection. Factory connection. Factory = (Queue. Connection. Factory) messaging. lookup("…"); Queue queue = (Queue) messaging. lookup("…"); Queue. Connection connection = connection. Factory. create. Queue. Connection(); Queue. Session session = connection. create. Queue. Session(…); Queue. Sender sender = session. create. Sender(queue); String selector = new String("(name = 'Bull') or (name = 'IBM'))"); Queue. Receiver receiver = session. create. Receiver(queue, selector); Text. Message msg = session. create. Text. Message(); msg. set. Text("…"); sender. send(msg); Text. Message msg = (Text. Message) receiver. receive();

Mode Publication / Souscription (Pub/Sub) Emetteur Destinataire Topic A x publish Topic. Publisher + B y + Topic. Subscriber Listener on. Message

Mode Publication / Souscription (Pub/Sub) Emetteur Destinataire Topic. Connection. Factory Topic. Connection A Topic. Session publish Topic. Publisher x + Topic. Connection B Topic. Session y + Topic. Subscriber Listener on. Message

Mode Publication / Souscription (Pub/Sub) Emetteur Destinataire Trouver la queue Créer une connexion et une session Créer un sujet Publier un message Préparer un message à écouter Se mettre à l’écoute d’un sujet

Mode Publication / Souscription (Pub/Sub) Emetteur Destinataire Topic. Connection. Factory connection. Factory = (Topic. Connection. Factory) messaging. lookup("…"); Topic topic = (Topic) messaging. lookup("/A/x"); Topic. Connection connection = connection. Factory. create. Topic. Connection(); Topic. Session session = connection. create. Topic. Session(false, Session. CLIENT_ACKNOWLEDGE);

Mode Publication / Souscription (Pub/Sub) Emetteur Destinataire Topic. Connection. Factory connection. Factory = (Topic. Connection. Factory) messaging. lookup("…"); Topic topic = (Topic) messaging. lookup("/A/x"); Topic. Connection connection = connection. Factory. create. Topic. Connection(); Topic. Session session = connection. create. Topic. Session(false, Session. CLIENT_ACKNOWLEDGE); Topic. Publisher publisher = session. create. Publisher(topic); publisher. publish(msg);

Mode Publication / Souscription (Pub/Sub) Emetteur Destinataire Topic. Connection. Factory connection. Factory = (Topic. Connection. Factory) messaging. lookup("…"); Topic topic = (Topic) messaging. lookup("/A/x"); Topic. Connection connection = connection. Factory. create. Topic. Connection(); Topic. Session session = connection. create. Topic. Session(false, Session. CLIENT_ACKNOWLEDGE); Topic. Publisher publisher = session. create. Publisher(topic); publisher. publish(msg); void on. Message(Message msg) throws JMSException { // unpack and handle the message … } Topic. Subscriber subscriber = session. create. Subscriber(topic); Subscriber. set. Message. Listener(listener);

Joram: une implémentation de JMS

La plate-forme SCALAGENT • Bus logiciel à base d’agents communicants • Agents = objets réactifs – Persistants – Légers : infrastructure d’exécution partagée au sein d’un serveur d’agents • Modèle événement / réaction asynchrone – Événement : changement d’état significatif du système auquel un ou plusieurs agents réagissent – Événement Notification – Réaction fonction dans la classe Agent Send. To Agent React Channel

L’architecture distribuée SCALAGENT • Infrastructure basée sur un bus à messages Agent Send. To Channel Engine mq Agent React Channel Engine mq Server B Server A – Acheminement des notifications – Exécution de la réaction du destinataire – Distribution: forte interconnexion des bus locaux

Les propriétés de la plate-forme • Persistance – Sauvegarde des agents et notifications • Atomicité – Cohérence garantie par un moniteur transactionnel • Persistance + Atomicité = Fiabilité – Une notification est délivrée une et une seule fois A • Ordonnancement causal – Les notification sont délivrées selon un ordre causal C B

JORAM • JORAM est l’interface JMS du MOM SCALAGENT – Les queues et topics sont des agents – Les messages sont encapsulés dans des notifications • Délivrance asynchrone • Garantie de délivrance • Reprise après panne • Apports de l’infrastructure à agents – Architecture totalement distribuée – Scalabilité

JMS via le MOM Scalagent Queue. Sender Queue. Session Queue. Connection Connexion TCP Agent Proxy Notif icatio n Agent Queue queue Queue. Connection Client 2 Clients JMS Client 1 Message JMS Queue. Session Queue. Receiver Message JMS Agent Proxy Connexion TCP ion t ifica t o N

Points forts de JORAM Récepteur • Architecture distribuée –Facilité de mise en oeuvre –Passage à l’échelle Serveur 1 Queue Serveur 0 Emetteur Queue. Connection. Factory Serveur 2 • Implémentation complète des « Application Server Facilities » –Intégration au serveur EJB JOn. AS

Intégration dans JOn. AS • JORAM implémente la partie ASF (Application Server Facilities) de la spéc. JMS – Intégration de JORAM en tant que ressource dans un environnement transactionnel distribué tel qu’un serveur EJB – Envoi et réception de messages dans des transactions gérées par le serveur EJB – Réception asynchrone via les « Message-driven Beans »

Avenir