Intgration des systmes Clients/Serveurs

..
..
..
..
..
David Eudeline
CNAM UE NFE 107
.
Urbanisation et
architecture des systèmes
. d’information
.
.
.
.
.
.
.
Middlewares à messages : MOM
.
CNAM NFE 107 – David Eudeline
Table des matières
PRESENTATION .................................................................................................................................... 5
CARACTERISTIQUES PRINCIPALES .................................................................................................. 5
FORMAT DU MESSAGE ........................................................................................................................ 6
ARCHITECTURE DES MOM .................................................................................................................. 7
MODELES DE MOM ............................................................................................................................... 8
Message Queue ............................................................................................................................... 8
Publication /abonnement................................................................................................................ 10
CAS D’UTILISATION D’UN MOM ........................................................................................................ 11
INTEGRATION DES MOM DANS J2EE : JMS (JAVA MESSAGING SERVICE)............................... 12
Architecture JMS ............................................................................................................................ 12
Fonctions non supportées .............................................................................................................. 14
Synthèse ........................................................................................................................................ 14
INTEGRATION DES MOM DANS .NET : MSMQ................................................................................. 14
COMPARAISON JMS/MSMQ............................................................................................................... 15
COMPARAISON RPC/MOM................................................................................................................. 15
3
CNAM NFE 107 – David Eudeline
Table des figures
Figure 1: principe de fonctionnement d’un MOM...................5
Figure 2: Architecture hub and spoke....................................7
Figure 4: Architecture snow flake ..........................................7
Figure 5: Bus à messages .....................................................8
Figure 2: principe d’une file de messages .............................9
Figure 3: Modèle de fonctionnement du message queuing.10
Figure 4: Modèle de communication évènementielle ..........10
Figure 5 : Synoptique JMS...................................................12
Figure 6: Logique d'enchaînement pour JMS......................14
Figure 7: architecture MSMQ...............................................15
4
CNAM NFE 107 – David Eudeline
Middlewares à messages
« Ordinateur : moyen conçu pour accélérer et
automatiser les erreurs »
Anonyme
Présentation
Le middleware orienté message (MOM) est basé sur le principe du routage interapplicatif
utilisant des communications asynchrones par messages. C’est le même principe que la
messagerie "classique", mais où des applications prennent la place des personnes.
Cette technologie permet ainsi un couplage dit « lâche et non intrusif », les applications
restant relativement indépendantes et ne dépendant pas trop des autres applications
(contrairement aux RPC par exemple). Ce mode se caractérise par l’utilisation de files
d’attente et par des possibilités de fonctionnement en mode déconnecté. On dit
également que les applications sont "faiblement couplées".
Historiquement, les MOM sont issus de l’évolution des outils ETL (Extract, Transform &
Load), procédures de type batch s’exécutant sur les mainframes et permettant les
transferts importants de données asynchrones en temps différé.
Figure 1: principe de fonctionnement d’un MOM
Caractéristiques principales
•
Mode déconnecté :
5
CNAM NFE 107 – David Eudeline
Les MOM sont avant tous caractérisés par le fait qu’ils fonctionnent en mode
déconnecté. Le mode déconnecté permet de désynchroniser l'exécution des
processus entre eux, d'effectuer des requêtes sans exiger la disponibilité du
processus serveur (utile sur les WAN), de paralléliser les traitements (le client
peut lancer plusieurs tâches simultanément), et enfin d'absorber les différences
de débits entre les processus. Ainsi si une application tolère un certain niveau
d’attente, le MOM est une des méthodes les plus faciles pour réguler les
échanges.
La propriété la plus importante ici est donc l'asynchronisme, qui est la faculté de
demander l’exécution d’une procédure sans attendre le retour d'exécution de ce
traitement. Le client n'est donc pas bloqué en cas de dysfonctionnement du
serveur.
•
Interopérabilité :
L'interopérabilité est également un apport important des MOM. Le MOM permet
en effet d'assurer la communication entre applications quels que soient le langage
de programmation des applications et la nature des systèmes d'exploitation, ceux
ci étant la plupart du temps disponibles sur une multitude de plateformes et pour
de nombreux langages divers et variés (à l’exception notable de MSMQ de
Microsoft bien évidemment limité à la plateforme Windows).
•
garantie de livraison :
Les MOM se caractérisent par une garantie de livraison. Le MOM garantit ainsi
que le message sera livré à l'application cible une et une seule fois (très
intéressant par rapport aux RPC ou l’on reste dans l’incertitude…).
Chaque application ne voit ainsi que des formats de message et un protocole simple (API
très simple). Il y a indépendance par rapport au réseau et aux systèmes d'exploitation.
Chaque application dépose et retire des messages dans une file d’attente, le middleware
masque tous les problèmes liés à la communication.
Un consortium MOMA a été créé en 1993 pour normaliser le middleware à messages.
Les principaux acteurs sont:
•
IBM avec MQSeries
•
BEA avec MessageQ
•
Peerlogic avec PIPES
Il faut cependant souligner un manque flagrant d’interopérabilité entre ces solutions.
Format du message
Les MOM s’échangent donc des messages. Un message contient:
•
Une entête, qui contient les
l’acheminement du message ;
•
Des attributs, qui contiennent les couples (nom, valeur) utilisables par le système
ou l’application pour sélectionner les messages ;
•
Des données, définies par l’application et qui peuvent représenter aussi bien des
données binaires que textuelles ou xml par exemple.
6
informations
permettant
l’identification
et
CNAM NFE 107 – David Eudeline
Architecture des MOM
Les architectures les plus courantes sont illustrées dans les schémas suivants :
Figure 2: Architecture hub and spoke
Le courtier centralise tous les évènements et fonctionne en point à point avec tous les
clients.
Figure 3: Architecture snow flake
Le courtier coopère avec des correspondants pour diffuser les messages => Service
réparti de gestion des messages.
7
CNAM NFE 107 – David Eudeline
Figure 4: Bus à messages
Dans ce cas de figure les brokers utilisent un protocole de diffusion sur IP pour coopérer
et diffuser l’information directement à tous les clients.
Ces architectures types n’offrent pas les mêmes possibilités en termes de déploiement,
de souplesse d’administration et de connectivité pour les applications. Les bus à
messages de par leur architecture centralisée sont plus simples à déployer et à
administrer. Ils offrent une meilleure évolutivité contrairement aux « hub and spoke » où le
nœud central peut constituer un goulet d’étranglement.
Modèles de MOM
Deux modèles de MOM existent principalement :
•
les files de message (Message Queuing) pour lesquelles un message est déposé
dans une file de messages en attendant que l'application destinatrice le récupère.
Ce modèle est proche d’un système de messagerie traditionnel.
•
les MOM à publication-abonnement (publish/subscribe),
pour
lesquels
un
message publié est diffusé aux applications qui se sont abonnées. Ce modèle est
plus proche d’un système de newsgroup.
Message Queue
Le MOM repose sur un moniteur spécialisé, qui gère les messages en garantissant en
offrant des fonctions évoluées telles que la contournement des segments réseaux en
panne, les essais multiples, l’atomicité transactionnelle, la gestion des croissance en
volume, etc.
8
CNAM NFE 107 – David Eudeline
Figure 5: principe d’une file de messages
C'est un moniteur spécialisé, qui gère les messages en garantissant la transparence par
rapport:
•
aux formats des données
•
aux systèmes d'exploitation
•
au réseau (topologie, protocole, marche/arrêt)
•
au nombre et à la répartition des applications clientes.
Les files d’attente peuvent être persistantes (sur disque) ou non persistantes (en
mémoire). Les files d’attente persistantes sont moins rapides mais plus fiables que les
files d’attente non persistantes.
Les produits MOM permettent de créer des clients nomades qui accumulent les
messages et les délivrent tous lors d’une connexion. Il n’y a pas de connexion logique
permanente nécessaire. De ce fait ces produits sont bien adaptés à des infrastructures
non maîtrisées avec un faible niveau de service ou bien au nomadisme qui réclame de
l’asynchronisme entre le client et le serveur.
Les clients et serveurs peuvent fonctionner à des moments différents. Ceci permet une
grande souplesse mais il faut que l’application tolère un certain niveau d’attente.
Les MOM proposent des fonctions supplémentaires telles que la gestion des priorités et
l’équilibrage de charge.
9
CNAM NFE 107 – David Eudeline
Figure 6: Modèle de fonctionnement du message queuing
Publication /abonnement
La communication événementielle fonctionne sur les principes suivants :
•
Concepts de base : événements, réactions (traitements associés à
l’occurrence d’un événement).
•
Principe d’attachement : association
d’événement et une réaction.
•
Communication anonyme : indépendance entre l’émetteur et les
“consommateurs” d’un événement.
•
Environnements : un plus dans les environnements objets répartis
(services d’événements CORBA, composants CORBA, JMS Java
Messaging Service).
dynamique
entre
un
nom
Figure 7: Modèle de communication évènementielle
Les mécanismes de publication / souscription permettent de créer un couplage faible
entre les acteurs du SI. Un acteur s’abonne à un événement et une réaction est associée
à cet évènement.
Ce type de solution offre les propriétés suivantes :
10
CNAM NFE 107 – David Eudeline
•
Asynchronisme
•
Indépendance
•
Critères d’abonnement sur le sujet ou le contenu sémantique
•
Organisation hiérarchique
•
Qualité de service
•
"best effort"
•
fiable
•
persistant
•
transactionnel
- Des sources produisent des événements : publish.
- Des consommateurs s’abonnent à des événements : subscribe.
On parle fréquemment de Push Pull :
•
Pull : Les clients viennent prendre périodiquement leurs messages sur le
serveur.
•
Push : Une méthode prédéfinie (réaction) est attachée à chaque type de
message (événement) ; la réception d'un événement entraîne l'exécution
de la réaction associée.
En mode pull (« tiré ») le client contrôle le flux des évènements et donc des réactions
associées. Par contre en mode Push (« poussé »), le client subit les évènements et le
déclenchement des réactions est automatique.
Les principaux produits sont:
•
TIBCO avec TIB/rendez vous (MOM)
•
BEA avec TUXEDO et M3 (CORBA)
•
OpenHorizon avec Ambrosia (JAVA)
Cas d’utilisation d’un MOM
Les MOM sont une excellente brique pour intégrer des sous-systèmes hétérogènes avec
de bonnes performances. Ils permettent de traiter les problèmes de couplage des
applications et sont particulièrement adaptés aux applications nécessitant une intégration
par les flux.
Ils permettent également de mettre en place le principe de délégation (Front Office - Back
Office), pour répondre par exemple à un besoin de saisie massive.
Enfin, ils peuvent permettre de réaliser des opérations de synchronisation de base de
données, permettant la remontée d'informations, la consolidation d'informations
(datawarehouse) ou la synchronisation asynchrone de base de données réparties (Postes
nomades).
11
CNAM NFE 107 – David Eudeline
Au final, les MOM (comme les RPC) ne s'occupent cependant principalement que du
transport. "Ce n'est que de la plomberie". Ils s'intègrent désormais dans les serveurs
d'application (J2EE avec JMS ou .NET avec MSMQ).
Intégration des MOM dans J2EE : JMS (Java Messaging Service)
La spécification JMS se propose de définir une API permettant d’accéder à des produits
de messagerie divers. Ceci afin d’offrir un niveau d’interopérabilité entre les produits de
communication par messages. De ce fait JMS propose plusieurs modes de
fonctionnement et notamment le point à point (PTP, Message Queue) et le mode
publication/ souscription (pub/sub). A chacun de ces modes de fonctionnement est
associé un JMS domain.
JMS domain : Le format des messages échangés, PTP ou pub/sub détermine le JMS
domain et de ce fait les classes de fonctions utilisées. La dernière évolution de JMS 1.1
propose une classe « common » parente des deux classes avec une sémantique
identique. Il est fortement recommandé d’utiliser cette super classe qui permet de
s’affranchir du type de message utilisé.
En mode point à point (Message Queue) les utilisateurs du support JMS sont désignés
comme clients. Les applications externes souhaitant s’interfacer avec JMS afin d’offrir ce
service de connectivité le font en fournissant un provider supportant les interfaces JMS.
Figure 8 : Synoptique JMS
Architecture JMS
Une application JMS est composée des éléments suivants :
•
JMS clients : les programmes écrits en JAVA qui reçoivent et envoie les
messages,
•
Non-jms clients : les programmes utilisant les API natives fournies par le
système de messagerie inter-applicative.
•
Message : Chaque application définie les formats de messages qui
seront utilisés dans le système par les différents clients.
•
JMS provider : Produit de messagerie inter-applicative proposant une
interface JMS.
•
Administered Objects : Objets pré configuré par l’administrateur pour
les clients.
12
CNAM NFE 107 – David Eudeline
Les produits de MOM ont des fonctionnements qui peuvent s’avérer relativement
différents, ceci a donc un impact sur les JMS provider. Les clients JMS sont censés être
portable et donc indépendant du produit MOM sous jacent.
Cet objectif est atteint grâce à la définition et à l’utilisation des « objets administrés ». Ces
objets sont créés par l’administrateur grâce au JMS provider de l’application support et
utilisés par les clients JMS au travers des interfaces standards.
On trouve deux types d’objets administrés :
•
ConnectionFactory : Utilisé pour ouvrir une connexion avec le client.
•
Destination : Utilisé pour spécifier la destination ou la source d’un
message.
Ces objets sont placés dans le namespace JNDI (service de localisation) afin de
permettre aux différents clients JMS de résoudre les problèmes de localisation des
ressources.
Les objets utilisés lors de l’initialisation d’un dialogue via JMS sont les suivants :
JMS parent
ConnectionFactory
Modèle PTP
QueueConnectionFactory
Modèle
Pub/Sub
TopicConnectionFactory
un objet administré par le provider pour créer une Connection
Connection
QueueConnection
TopicConnection
une connexion active vers un JMS provider
Destination
Queue
Topic
Encapsule l’identité d ’une destination
Session
QueueSession
TopicSession
Contexte pour l’émission et la réception de messages
MessageProducer
QueueSender
TopicPublisher
objet pour la production (l’envoi) de messages vers une Destination (créé par la
Session)
MessageConsumer
QueueReceiver,QueueBrowser TopicSubscriber
objet pour la consommation (la reception) de messages d’une destination (créé par la
session)
Support transactionnel : JMS supporte les API JTA et JTS pour le support des
transactions distribuées.
13
CNAM NFE 107 – David Eudeline
Figure 9: Logique d'enchaînement pour JMS
Fonctions non supportées
JMS en tant qu’API de haut niveau pour la communication inter applicatives, JMS ne
supporte pas certains services de manière native :
•
Administration du produit MOM.
•
Equilibrage de charge et tolérance aux pannes.
•
Dépôt des types de message : JMS ne fournit pas un dépôt des formats
(types) de message ni un langage de définition.
•
Notification d’erreur : chaque produit peut envoyer aux clients des
messages systèmes ; JMS ne normalise pas ces messages.
•
Sécurité : JMS ne contrôle pas la confidentialité et l’intégrité des
messages.
•
Protocole de transport.
Synthèse
Plus
d’informations
pourront
http://java.sun.com/products/jms
être
trouvées
sur
le
site
de
SUN :
JMS est au final utilisé en conjonction avec les autres produits de la plate forme JEE tels
que JNDI, JTA et le mécanisme d’EJB.
Intégration des MOM dans .NET : MSMQ
Le MOM intégré dans .NET est une implémentation basée sur MSMQ 2.0 (fourni avec
Windows 2000). Les files d’attente sont publiques et accessibles à n'importe quel type de
client. Elles sont gérées par les serveurs MSMQ et enregistrées dans Active Directory.
Elles fonctionnent sur le principe de store and forward
14
CNAM NFE 107 – David Eudeline
L’architecture propose plusieurs types de clients:
•
Des clients « dépendant » ne fonctionnant qu'en mode connecté ;
•
Des clients « indépendants » pouvant travailler en mode déconnecté.
Il est également possible de définir des files privées, définies entre clients indépendants,
ne passant pas par un serveur MSMQ et fonctionnant donc par le biais de
communications directes.
Figure 10: architecture MSMQ
Les limitations sont que cela reste une technologie propriétaire (utilisation de MSMQ), et
que MSMQ ne gère que depuis peu de temps le mode publication-abonnement (A partir
de MSMQ 3.0, Windows Server 2003 & Windows XP)
Comparaison JMS/MSMQ
Les deux produits proposent donc une approche différente. Si .NET est une solution
dédiée Windows avec une approche propriétaire (MSMQ), JMS est une solution portable
qui fait abstraction vis à vis du fournisseur. Sinon fonctionnalités équivalentes, au bémol
près de la disponibilité très récente du mode pub/sub sous .NET
Comparaison RPC/MOM
Un critère important lors de l’analyse ou de la définition d’une architecture demeure le
degré de liberté ou de couplage des applications. Les critères à prendre en compte
sont les suivants:
•
Les applications doivent-elles s’exécuter en même temps?
•
Peut-on ajouter une application sans impacter les autres?
•
Peut-on modifier l’implémentation d’une application sans impacter les autres?
Ainsi la technologie RPC propose un couplage fort, les applications devant s’exécuter en
même temps, avec des difficultés dans la gestion des modifications des applications
(toute modification de l’interface serveur implique une modification de l’interface du client).
15
CNAM NFE 107 – David Eudeline
Les MOM pour leur part proposent un couplage faible avec un mode de communication
plus souple, les applications ne communiquant plus directement mais par l’intermédiaire
d’un médiateur.
Si l’on peut faire une métaphore, les RPC seraient plus proche du téléphone alors que les
MOM seraient plus proches du courrier postal. Les deux ont ainsi leur utilité, suivant les
circonstances :
•
Les MOM sont plus souples et moins dépendantes du temps, les applications
doivent cependant pouvoir gérer un tel degré de liberté ;
•
Les RPC proposent un traitement immédiat pour le client, les actions étant
traitées à mesure qu'elles arrivent au serveur. L'exécution est également plus
rapide.
16