La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Message Oriented Middleware. Plan Pourquoi un nouveau type de middleware? Quelle lignée logicielle ? Historique JMS : Java Message Server Limplémentation.

Copies: 1
Message Oriented Middleware. Plan Pourquoi un nouveau type de middleware? Quelle lignée logicielle ? Historique JMS : Java Message Server Limplémentation.

Présentations similaires


Présentation au sujet: "Message Oriented Middleware. Plan Pourquoi un nouveau type de middleware? Quelle lignée logicielle ? Historique JMS : Java Message Server Limplémentation."— 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 Limplémentation Joram Lavenir 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 ladministration 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 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.

11 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

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

13 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);

14 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);

15 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()

16 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()

17 Principe des MOM

18 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

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

21 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

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 lidentification et lacheminement 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

24 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

25 Java Message Service

26 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

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

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

29 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

30 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

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

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

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

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

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

36 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

37 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

38 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

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

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

41 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

42 Joram: une implémentation de JMS

43 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

44 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

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

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

47 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

48 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

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


Télécharger ppt "Message Oriented Middleware. Plan Pourquoi un nouveau type de middleware? Quelle lignée logicielle ? Historique JMS : Java Message Server Limplémentation."

Présentations similaires


Annonces Google