Upload
desiree-poirot
View
109
Download
0
Embed Size (px)
Citation preview
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
Le service d’événement Corba
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
Producteur
Producteur
Consommateur
Consommateur
Consommateur
Consommateur
Canal
Flot des évènements
Un canal d’évènements : notification
Producteur
Producteur
Consommateur
Consommateur
Consommateur
Consommateur
Canal
Producteur actif / Consommateur réactifLe canal diffuse les évènements
Push
Push
PushSupplierPushConsumer
void push(in any data) raises(Disconnected);
Un canal d’évènements : demande
Producteur
Producteur
Consommateur
Consommateur
Consommateur
Consommateur
Canal
Producteur réactif / Consommateur actifLe canal procure les évènements
Pull()
Pull()
demandePullSupplier {
//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);
Un canal d’évènements : file d’évènements
Producteur
Producteur
Consommateur
Consommateur
Consommateur
Consommateur
Canal
Producteur actif / Consommateur actifLe canal gère des files d’évènements
Push()
Pull()
Un canal d’évènements : collecte d’évènements
Producteur
Producteur
Consommateur
Consommateur
Consommateur
Consommateur
Canal
Producteur réactif / Consommateur réactifLe canal est une entité active voire intelligente
Pull()
Push()
Principe des MOM
Emetteur Récepteur
Destination
message
Emetteur et récepteur connaissent seulement la destinationPlusieurs émetteurs et récepteurs sur lamême destinationPersistance du message (reçu ou non reçu)Format du message libreAcheminement 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 chercher 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
Provider X
JVM
Client
Client
Client
MQ X MQ XMQ X MQ X
JMS
ClientProvider X
JVM
Client
JMS
Client JMSEmetteur Récepteur
Destination
message
Serveur de messages
Architecture JMS
Client JMS Client JMS
Consumer
Destination
message
Serveur de messages
Architecture JMS
Client JMS
Connection
Session
Producer
Client JMS
Connection
Session
Architecture JMSUne 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
Client1 Client2
queue
send
consumes
acknowledges
Client2publishes
Client1
subscribesdelivers
Client3subscribesdelivers
Le consommateur envoie un reçuLe message est détruit à réception dureçuIl peut y avoir plusieurs consommateursen attente
Un client doit s’abonnerau préalableTous 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
sendreceive
Emetteur Récepteur
Etapes du mode Point-à-Point
Emetteur Destinataire
Trouver la queueCréer une connexion et une session
Etapes du mode Point-à-Point
Emetteur Destinataire
Trouver la queueCréer une connexion et une session
Spécialiser une communicationd’envoi sur la queue
Etapes du mode Point-à-Point
Emetteur Destinataire
Trouver la queueCréer une connexion et une session
Spécialiser une communicationD’envoi sur la queue
Spécialiser une communication deRéception sur la queue
Etapes du mode Point-à-Point
Emetteur Destinataire
Trouver la queueCréer une connexion et une session
Spécialiser une communicationD’envoi sur la queue
Spécialiser une communication deRéception sur la queue
Envoyer un message sur la queue
Etapes du mode Point-à-Point
Emetteur Destinataire
Trouver la queueCréer une connexion et une session
Spécialiser une communicationD’envoi sur la queue
Spécialiser une communication deRéception sur la queue
Envoyer un message sur la queue
Demander la réception d’un message
Mode Publication / Souscription (Pub/Sub)
Emetteur Destinataire
Topic
A B
x y
+
TopicPublisher
publish
TopicSubscriber
+
Listener
onMessage
Mode Publication / Souscription (Pub/Sub)
Emetteur Destinataire
Topic
TopicConnectionFactory
A B
x yTopicSession
TopicConnection
TopicSession
TopicConnection
+
TopicPublisher
publish
TopicSubscriber
+
Listener
onMessage
Mode Publication / Souscription (Pub/Sub)
Emetteur Destinataire
Trouver la queueCréer une connexion et une session
Créer un sujet
Se mettre à l’écoute d’un sujet
Préparer un message à écouterPublier un message
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
Agent
React
SendTo
Channel
Agent
L’architecture distribuée SCALAGENT
Channel Engine
mq
Channel Engine
mq
AgentAgent
AgentAgent
SendTo React
Ser
ver
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
CA
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 ScalagentC
lient
s JM
S
QueueSender
QueueSession
QueueConnection
queue
Clie
nt
1
QueueReceiver
QueueSession
Clie
nt
2
QueueConnection
Connexion TCP
MOM ScalagentMessage JMS
Message JMS
Connexion TCP
Notification
Notification
Agent Proxy
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
EmetteurServeur 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 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 »