Message Oriented Middleware

Présentation au sujet: "Message Oriented Middleware"— Transcription de la présentation:

1 Message Oriented Middleware

2 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

3 Pourquoi un nouveau type de middleware?

4 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

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

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

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

8 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

9 Le service d’événement Corba

10 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. Je saurais le compléter.par un dessin.. Il permet aux objets de produire des événements asynchrone à destination d’objets consommateurs. Producteurs et consommateurs dialoguent à travers un intermédiaire appelé canal d’événements. Les producteurs n’ont pas besoins de connaître tous les consommateurs intéressés. Etendu avec le Notification service ou les consommateurs sont notifiés uniquement des évènements les interessant ce qui permet de réduire le trafic. Voir l ’exemple de Douglas si je pouvais recuperer le transparent…. dans le mode push le producteur a l ’initiative de la production le consommateur est notifié. Dans le mode pull, le consommateur demande explicitement les événements, le producteur est alors sollicité. ..

11 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

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

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

14 Un canal d’évènements : demande
Consommateur Producteur Pull() Consommateur Producteur Canal Pull() Consommateur PullSupplier { //demande de production d’un événement any pull() raises(Disconnected); // présence d’un événement any try_pull(out boolean has_event) raises(Disconnected); demande Consommateur Like consumers, suppliers can also use push or pull behavior. Push suppliers are the more common type, in which the supplier directly forwards data to the event channel and thus plays the client role in the link to the channel. Pull suppliers, on the other hand, are polled by the event channel and supply an event in response, if a new event is available. Polling is done by the try_pull() operation if it is to be non-blocking or by the blocking pull() call: // IDL interface PullSupplier { any pull() raises(Disconnected); any try_pull(out boolean has_event) void disconnect_pull_supplier(); }; Producteur réactif / Consommateur actif Le canal procure les évènements

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

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

17 Principe des MOM JORAM a été construit sur la base d’une technologie à agents développée dans le cadre du GIE Dyade (Bull + INRIA). JORAM fait partie de l’offre Objectweb depuis un peu plus d’un an.

18 Récepteur Emetteur 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 message Destination

19 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

20 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 Les MOM sont basés sur des systèmes de queues de messages persistantes qui permettent de transmettre de manière asynchrone des messages entre des composants qui peuvent ne pas fonctionner aux mêmes instants. Les queues de messages stockent les messages si le composant destinataire n’est pas accessible. Le mécanisme de reprise après panne permet d’envoyer les messages à la reprise sans intervention du client.

21 2 modes Mode push Mode pull 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 chercher l’information Consultation méteo

22 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

23 Caractéristiques des MOM
Modes de communication Point à point (PTP): émetteur, récepteur et queue Publication/Souscription (Pub/Sub): émetteur, abonné et nœud Différentes relations possibles entre émetteurs et récepteurs: PTP (~mail), PubSub (~listes)… Différents modèles de programmation: réception explicite/implicite. Messages dotés de propriétés: durée de vie, priorité, filtrage en fonction des propriétés et d’attributs. Ordonnancement.

24 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 Différentes relations possibles entre émetteurs et récepteurs: PTP (~mail), PubSub (~listes)… Différents modèles de programmation: réception explicite/implicite. Messages dotés de propriétés: durée de vie, priorité, filtrage en fonction des propriétés et d’attributs. Ordonnancement.

25 Java Message Service

26 L’interface Java Message Service (JMS)
API Java d’accès uniforme aux systèmes de messagerie Provider X JVM Client MQ X JMS JMS fournit une API commune aux programmes Java pour utiliser les MOMs, en minimisant les concepts tout en en s’efforçant de préserver leur diversité: PTP (queues), Pub/Sub (topics), réception implicite/explicite, … L’intérêt de JMS est de fournir une façon unifiée d’utiliser les services des MOM. Un code client JMS peut donc utiliser n’importe quel MOM du moment que celui-ci propose l’interface JMS.

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

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

29 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

30 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

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

32 Le mode Point-à-Point (PTP)
receive send Emetteur Récepteur Systèmes PTP construits autour du concept de queue de message. Les messages sont adressés sur une queue spécifique au destinataire. Le destinataire extrait ses messages de la queue. queue

33 Le mode Point-à-Point (PTP)
Queue QueueConnectionFactory QueueSession QueueConnection QueueSession QueueConnection + QueueSender + QueueReceiver send receive Systèmes PTP construits autour du concept de queue de message. Les messages sont adressés sur une queue spécifique au destinataire. Le destinataire extrait ses messages de la queue. Emetteur Récepteur

34 Etapes du mode Point-à-Point
Emetteur Destinataire Trouver la queue Créer une connexion et une session Systèmes PTP construits autour du concept de queue de message. Les messages sont adressés sur une queue spécifique au destinataire. Le destinataire extrait ses messages de la queue.

35 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 Systèmes PTP construits autour du concept de queue de message. Les messages sont adressés sur une queue spécifique au destinataire. Le destinataire extrait ses messages de la queue.

36 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 Systèmes PTP construits autour du concept de queue de message. Les messages sont adressés sur une queue spécifique au destinataire. Le destinataire extrait ses messages de la queue. Spécialiser une communication de Réception sur la queue

37 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 Systèmes PTP construits autour du concept de queue de message. Les messages sont adressés sur une queue spécifique au destinataire. Le destinataire extrait ses messages de la queue. Spécialiser une communication de Réception sur la queue Envoyer un message sur la queue

38 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 Systèmes PTP construits autour du concept de queue de message. Les messages sont adressés sur une queue spécifique au destinataire. Le destinataire extrait ses messages de 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

39 Mode Publication / Souscription (Pub/Sub)
Emetteur Destinataire Topic A B TopicSubscriber + Listener x y + TopicPublisher publish Les messages sont adressés à un nœud particulier. Émetteurs et abonnés sont anonymes. Le système distribue les messages arrivés aux différents abonnés. onMessage

40 Mode Publication / Souscription (Pub/Sub)
Emetteur Destinataire TopicConnectionFactory TopicSession TopicConnection TopicSession TopicConnection Topic A B TopicSubscriber + Listener x y + TopicPublisher publish Les messages sont adressés à un nœud particulier. Émetteurs et abonnés sont anonymes. Le système distribue les messages arrivés aux différents abonnés. onMessage

41 Mode Publication / Souscription (Pub/Sub)
Emetteur Destinataire Trouver la queue Créer une connexion et une session Créer un sujet Préparer un message à écouter Publier un message Les messages sont adressés à un nœud particulier. Émetteurs et abonnés sont anonymes. Le système distribue les messages arrivés aux différents abonnés. Se mettre à l’écoute d’un sujet

42 Joram: une implémentation de JMS

43 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 Agent SendTo Agent React Agents composés d’un état et d’un ensemble de règles décrivant leur comportement. Un événement est représenté par une notification. Les notifications sont envoyées via un bus logiciel. Channel

44 L’architecture distribuée SCALAGENT
Infrastructure basée sur un bus à messages Acheminement des notifications Exécution de la réaction du destinataire Distribution: forte interconnexion des bus locaux Agent Agent Agent Agent SendTo React Server A Channel Engine Channel Engine Serveur d’agents: JVM hôte, embarque un bus local et une fabrique à agents. Mise en œuvre distribuée: sur chaque site, le bus local représente le bus à messages. Bus local: gère les communications locales, est fortement interconnecté avec les autres bus locaux, est composé d’un Channel (loc et transport des notifs) et d’un Engine (moteur d’exécution). La délivrance des notifications se fait par la méthode react() des destinataires. Server B mq mq

45 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 Propriétés d’atomicité et de fiabilité assurées par le bus local.

46 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é

47 JMS via le MOM Scalagent
Message JMS QueueSender MOM Scalagent Client 1 QueueSession Agent Proxy QueueConnection Connexion TCP Notification Agent Queue Clients JMS queue Notification Agent Proxy QueueConnection Connexion TCP QueueSession Client 2 Les messages échangés par les clients JMS transitent via le MOM: L’objet JMS Connection encapsule une connexion TCP entre le client et le MOM. Les clients JMS se connectent à des agents « proxy ». Les messages sont encapsulés dans des notifications. QueueReceiver Message JMS

48 QueueConnectionFactory
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 Récepteur

49 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 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 »