Message Oriented Middleware

Plan Pourquoi un nouveau type de middleware? Quelle lignée logicielle ? Historique JMS : Java Message Server Limplémentation Joram Lavenir 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 ladministration 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 application opération Client Serveur req1 rep1 reqn repn

Communication par diffusion : Multicast application Clientn Serveur application Client1 application Client2 Gr

Observer Observable

Motivation Un effet de bord fréquent de la partition dun 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 dun objet change, tous ses dépendants sont informés et mis à jour automatiquement

Quand lappliquer Lorsquune abstraction possède deux aspects dont lun dépend de lautre. –Lencapsulation 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 Lorsquune modification à un objet exige la modification des autres, et que lon ne sait pas a priori combien dobjets devront être modifiés. Lorsquun objet devrait être capable dinformer les autres objets sans faire dhypothè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 nimporte quel nombre dobservateurs dépendants Tous les observateurs sont informés lorsque létat de la source change – lobservateur. 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 dobservateurs.

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 dune classe qui implémente linterface Observer void update(Observable o, Object arg); Des listeners

Le service dévénement Corba

Emetteur Récepteur Destination message 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 lexécution synchrone dune opération (le client connaît la référence de lobjet auquel la requête sadresse et le client ainsi que lobjet 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 lobjet ne se connaissent pas; lorsque le client et lobjet ne sont pas actifs simultanément.

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

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

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

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

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

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

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

Emetteur Récepteur Destination message 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 dinté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 linformation Publicité, spam Mode pull –Le serveur livre une information –Le récepteur va chercher linformation 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 lidentification et lacheminement 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 dattributs et de propriétés –Priorités, garantie de délivrance

Java Message Service

Linterface Java Message Service (JMS) API Java daccès uniforme aux systèmes de messagerie Provider X JVM Client MQ X JMS Client Provider X JVM Client JMS

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

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

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

2 types de destinations Queue pour le point à point –Chaque message na quun 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 Client1 Client2 queue send consumes acknowledges Client2 publishes Client1 subscribes delivers Client3 subscribes delivers Le consommateur envoie un reçu Le message est détruit à réception du reçu Il peut y avoir plusieurs consommateurs en attente Un client doit sabonner au préalable Tous les abonnés reçoivent Le message publié

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

Le mode Point-à-Point (PTP) Queue QueueConnectionFactory QueueSession QueueConnection QueueSession QueueConnection + QueueSender + QueueReceiver send receive Emetteur Récepteur

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

Etapes du mode Point-à-Point EmetteurDestinataire Trouver la queue Créer une connexion et une session Spécialiser une communication denvoi sur la queue

Etapes du mode Point-à-Point EmetteurDestinataire Trouver la queue Créer une connexion et une session Spécialiser une communication Denvoi sur la queue Spécialiser une communication de Réception sur la queue

Etapes du mode Point-à-Point EmetteurDestinataire Trouver la queue Créer une connexion et une session Spécialiser une communication Denvoi sur la queue Spécialiser une communication de Réception sur la queue Envoyer un message sur la queue

Etapes du mode Point-à-Point EmetteurDestinataire Trouver la queue Créer une connexion et une session Spécialiser une communication Denvoi sur la queue Spécialiser une communication de Réception sur la queue Envoyer un message sur la queue Demander la réception dun message

Etapes du mode Point-à-Point QueueConnectionFactory connectionFactory = (QueueConnectionFactory) messaging.lookup("…"); Queue queue = (Queue) messaging.lookup("…"); QueueConnection connection = connectionFactory.createQueueConnection(); QueueSession session = connection.createQueueSession(…);

Etapes du mode Point-à-Point QueueConnectionFactory connectionFactory = (QueueConnectionFactory) messaging.lookup("…"); Queue queue = (Queue) messaging.lookup("…"); QueueConnection connection = connectionFactory.createQueueConnection(); QueueSession session = connection.createQueueSession(…); QueueSender sender = session.createSender(queue); String selector = new String("(name = 'Bull') or (name = 'IBM'))"); QueueReceiver receiver = session.createReceiver(queue, selector);

Etapes du mode Point-à-Point QueueConnectionFactory connectionFactory = (QueueConnectionFactory) messaging.lookup("…"); Queue queue = (Queue) messaging.lookup("…"); QueueConnection connection = connectionFactory.createQueueConnection(); QueueSession session = connection.createQueueSession(…); QueueSender sender = session.createSender(queue); String selector = new String("(name = 'Bull') or (name = 'IBM'))"); QueueReceiver receiver = session.createReceiver(queue, selector); TextMessage msg = session.createTextMessage(); msg.setText("…"); sender.send(msg); TextMessage msg = (TextMessage) receiver.receive();

Etapes du mode Point-à-Point QueueConnectionFactory connectionFactory = (QueueConnectionFactory) messaging.lookup("…"); Queue queue = (Queue) messaging.lookup("…"); QueueConnection connection = connectionFactory.createQueueConnection(); QueueSession session = connection.createQueueSession(…); QueueSender sender = session.createSender(queue); String selector = new String("(name = 'Bull') or (name = 'IBM'))"); QueueReceiver receiver = session.createReceiver(queue, selector); TextMessage msg = session.createTextMessage(); msg.setText("…"); sender.send(msg); TextMessage msg = (TextMessage) receiver.receive();

Mode Publication / Souscription (Pub/Sub) EmetteurDestinataire Topic AB x y + TopicPublisher publish TopicSubscriber + Listener onMessage

Mode Publication / Souscription (Pub/Sub) EmetteurDestinataire Topic TopicConnectionFactory AB x y TopicSession TopicConnection TopicSession TopicConnection + TopicPublisher publish TopicSubscriber + Listener onMessage

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

Mode Publication / Souscription (Pub/Sub) EmetteurDestinataire TopicConnectionFactory connectionFactory = (TopicConnectionFactory) messaging.lookup("…"); Topic topic = (Topic) messaging.lookup("/A/x"); TopicConnection connection = connectionFactory.createTopicConnection(); TopicSession session = connection.createTopicSession(false, Session.CLIENT_ACKNOWLEDGE);

Mode Publication / Souscription (Pub/Sub) EmetteurDestinataire TopicConnectionFactory connectionFactory = (TopicConnectionFactory) messaging.lookup("…"); Topic topic = (Topic) messaging.lookup("/A/x"); TopicConnection connection = connectionFactory.createTopicConnection(); TopicSession session = connection.createTopicSession(false, Session.CLIENT_ACKNOWLEDGE); TopicPublisher publisher = session.createPublisher(topic); publisher.publish(msg);

Mode Publication / Souscription (Pub/Sub) EmetteurDestinataire TopicConnectionFactory connectionFactory = (TopicConnectionFactory) messaging.lookup("…"); Topic topic = (Topic) messaging.lookup("/A/x"); TopicConnection connection = connectionFactory.createTopicConnection(); TopicSession session = connection.createTopicSession(false, Session.CLIENT_ACKNOWLEDGE); TopicPublisher publisher = session.createPublisher(topic); TopicSubscriber subscriber = session.createSubscriber(topic); Subscriber.setMessageListener(listener); void onMessage(Message msg) throws JMSException { // unpack and handle the message … } publisher.publish(msg);

Joram: une implémentation de JMS

La plate-forme S CALAGENT Bus logiciel à base dagents communicants Agents = objets réactifs –Persistants –Légers : infrastructure dexécution partagée au sein dun serveur dagents 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 React SendTo Channel Agent

Larchitecture distribuée S CALAGENT ChannelEngine mq ChannelEngine mq Agent SendTo React Server A Server B Infrastructure basée sur un bus à messages –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 Ordonnancement causal –Les notification sont délivrées selon un ordre causal B C A

JORAM JORAM est linterface 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 linfrastructure à agents –Architecture totalement distribuée –Scalabilité

JMS via le MOM Scalagent Clients JMS QueueSenderQueueSessionQueueConnection queue Client 1 QueueReceiverQueueSession Client 2 QueueConnection Connexion TCP MOM Scalagent Message JMS Connexion TCP Notification Agent Proxy Agent Queue

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

Intégration dans JOnAS 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 quun 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