message oriented middleware. plan pourquoi un nouveau type de middleware? quelle lignée logicielle...

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 »