Systèmes Distribués

Ali BEDDIAF
Département d’informatique
Université Hadj Lakhdar de Batna
http://sites.google.com/site/Abeddiaf
 Communication dans les SDs
– Sites évoluent au cours du temps ( ajout de
sites/applications)
– On doit assurer la communication entre les
anciennes applications et celle qu’on veut ajouter.

2
 Communication dans les SDs
• Solution banale: ajout d’un lien/interface de
communication à chaque fois.
– Système de spaghetti :(((((
– N liens et 2*N interface !!

3
 Communication dans les SDs
• Solution : middleware
– Factoriser les parties communes des applications
dans un seul module ou bus de communication
– Les nouvelles applications vont se connecter à ce
bus plutôt que à toutes les autres applications

4
 Communication dans les SDs
• Les applications qui se connectent au
middleware peuvent être de natures
différentes:
– Ensemble d’applications
– Ensemble de procédures (paradigme procédural)
– Ensemble de objets(paradigme objet)

5
 Communication dans les SDs
• Sortes de middleware
– Par échange de messages (entre applications)
– Par appel de procédures distantes (entre
procédures)
– Par appel de méthodes distantes (entre objets)

6
 Communication dans les SDs
• Middleware orienté message
– Unité de distribution est l’application
– Émission/réception de messages entre application
– Simplicité, grâce à l’évitement de la
programmation des protocoles réseau et systèmes
(Sockets)

7
 Communication dans les SDs
• Middleware orienté message
– Garantie de livraison des messages par la
sauvegarde sur le disque
– Existence des produits fiaable et très matures:
• BEAMessageQ
• MQSeries d’IBM

8
 Communication dans les SDs
• Middleware orienté message
– Applications émettrice/réceptrice doivent prendre
en charge la construction des messages
– Pas de standard ( deux produits différents ne sont
pas interopérables)

9
 Communication dans les SDs
• Middleware par appel de procédures distantes
(RPC : Remote Procedure Call)
– Unité de distribution est la procédure
– Programme principal représente le client (sur un
site)
– Les procédures représente le serveur (sur un autre)

10
 Communication dans les SDs
• Middleware par appel de procédures distantes
(RPC : Remote Procedure Call)
– Transparence d’appel aux procédures (identiques
pour les procédures locales ou distantes)
– Un appel à une procédure se traduit par l’envoi d’un
message
– Aucune construction de message n’est obligatoire
(elle se fait automatique par le middleware)

11
 Communication dans les SDs
• Middleware par appel de méthodes distantes
(RMI : Remote Method Invocation)
– Unité de distribution est l’objet
– Système est un ensemble d’objets en interaction
– Un objet peut invoquer la méthode d’un autre qui
se situe sur un site distant d’une manière
transparente

12
 Communication dans les SDs
• Middleware par appel de méthodes distantes
(RMI : Remote Method Invocation)
– Le bus du middleware RMI est constitué par l’ensemble
des interfaces des objets qui y sont connectés
– Un middleware RMI tire les même avantages d’un
système O.O.
• Évolutif via le mécanisme d’héritage

13
 Communication dans les SDs
• Middleware par appel de méthodes distantes
(RMI : Remote Method Invocation)
– Mode de communication:
• Statique: comme le cas des RPC (décrite ci-dessous)
• Dynamique: le client au moment de l'exécution interroge
le middleware objet afin de connaître les interfaces
disponibles sur le réseau

14
 Communication dans les SDs
• Middleware par appel de méthodes distantes
(RMI : Remote Method Invocation)
– Existence des standards:
• CORBA (1990) par l'OMG sur toutes les plates-formes.
• DCOM (1996) par Microsoft sur Windows et UNIX,
domine le monde PC Windows.
• Java RMI (1998) par Sun Microsystems ; une abstraction
pour toute sorte de protocole basé objets distribués.

15
 Communication dans les SDs
• Principe de fonctionnement RPC/RMI

16
 Communication dans les SDs
• Principe de fonctionnement RPC/RMI
– Souche client (stub) : elle se charge de préparer les
paramètres de la procédure/méthode distante, puis elle
les envoie au middleware, et enfin elle se met en
attente jusqu’à la fin de l’exécution de la
procédure/méthode distante en retournant
probablement un résultat attendu.
– Souche serveur (skeleton) : elle se charge d’invoquer la
procédure/méthode demandée en lui passant les
paramètres reçus, puis à la fin de son exécution, elle
renvoie le résultat au middleware.

17
 Communication dans les SDs
• Evolution des applications distribuées
– Modèle centralisé (1-tier)
• Un seul site
• Rapidité des tâches
Interface utilisateur (graphique…)
• Bonne Sécurité
• Pb de partage/comm.
• Pb de cohérence Traitements

• Mono-utilisateur
• Surcharge Données
• …
18
 Communication dans les SDs
• Evolution des applications distribuées
– Modèle Client/Serveur (2-tiers)
• Plusieurs sites
• Partage de données
• Cohérence de données
• Client allégé des manipulation liées aux données
• Pb sécurité du serveur de données
• Client encore alourdi par les traitements

Interface utilisateur TCP/IP

(graphique…)
Données
Traitements
Serveur
19
Client
 Communication dans les SDs
• Evolution des applications distribuées
– Modèle Client/Serveur à trois étages (3-tiers)
• Indépendances interface utilisateur/traitement/donnée
• Chaque étage peut s’exécuter sur un site différent
• Mise au point d’un étage ne met pas en cause les autres.
• Le middleware assure la communication du tout

Interface (textuelle,
Traitements Données
graphique…)

Serveur / Client Serveur20

Client
 Communication dans les SDs
• Evolution des applications distribuées
– Modèle d’applications multi-étages (n-tiers)
• Plusieurs clients (léger, lourd)
• Plusieurs serveur (web, de traitement, de base de
données)
• Introduction de la notion de serveur d’applications

21
 Communication dans les SDs
• Evolution des Serveurs d’application
– S.A. à base d’objets distribués
• La logique métier est implémentée à base d’objets
distribués, dont le middleware est un middleware objet
standardisé tel que CORBA, RMI ou DCOM (avantage :
logique métiers réutilisable et évolutive)
• On a toujours besoin de la gestion des aspects complexes
tels que: la concurrence, la sécurité, les transactions, etc.

22
 Communication dans les SDs
• Evolution des Serveurs d’application
– S.A. à base de moniteur TP
• Les moniteurs TP (Transaction Processing) sont des
serveurs d’application qui prennent en charge les
transactions, la gestion des ressources

• Dans les moniteurs TP, la logique métier n’est ni

évolutive ni réutilisable parce qu’elle n’est pas orientée
objets.

23
 Communication dans les SDs
• Evolution des Serveurs d’application
– S.A. à base de CTM (Component Transaction
monitors)
• Ce sont les serveurs d’applications hybrides à base
d’objets distribués et les moniteurs TP.

• Ils implémentent des modèles de composants cotés

serveurs robustes qui facilitent la création et l’utilisation
des systèmes d’entreprise

24
 Communication dans les SDs
• Evolution des Serveurs d’application
– S.A. à base de CTM (Component Transaction
monitors)
Chaque CTM est propre à une spécification bien définie :
• Le CTM Microsoft : MTS (Microsoft Transaction Server)
basé sur le middleware objet DCOM
• Les CTM non Microsoft : tel que les serveurs EJB basé sur
le middleware objet CORBA.

25
 Communication dans les SDs
• Evolution des Serveurs d’application
– S.A. à base de CTM (Component Transaction
monitors)

26