SlideShare une entreprise Scribd logo
1  sur  62
LES APPELS DE
PROCÉDURE
DISTANTS
heithem.abbes@gmail.com
Rappel du schéma client-
serveur2
 Appel synchrone Requête-Réponse
 Mise en œuvre
 Bas niveau : utilisation directe du transport : sockets
(construit sur TCP ou UDP)
 Exemple : utilisation des sockets en C
 Haut niveau : intégration dans un langage de programmation
: RPC (construit sur sockets)
 Exemple : RPC en C
Définition
3
 Appel de procédure à distance (Remote Procedure Call, ou
RPC) : un outil pour construire des applications client-serveur
dans un langage de haut niveau
 L’appel et le retour ont lieu sur un site , l’exécution se déroule
sur un site distinct
 L’effet de l’appel doit être identique dans les deux situations
(local et distant)
Avantages attendus
4
 Facilité de programmation
 La complexité des protocoles de communication est
cachée
 Ne pas avoir à programmer des échanges au niveau
réseau
 Facilité de mise au point : une application peut
être mise au point sur un site unique, puis
déployée sur plusieurs sites
 Portabilité : résulte de l’usage d’un langage de
haut niveau
 Indépendance par rapport au système de
communication
Problèmes de réalisation
5
 Transmission des paramètres
 conversion entre la forme interne, propre à un
langage, et une forme adaptée à la transmission
 Gestion des processus
 Séquentielle et parallèle
 Réaction aux défaillances
 Trois modes de défaillance indépendants : client,
serveur, réseau
Mise en œuvre
6
 Par migration
 Par mémoire partagée
 Par messages
 Par appel léger (LRPC)
1
2
3
4
Réalisation par migration
7
 Stratégie de migration
 Le code et les données de la procédure distante sont
amenés sur le site appelant pour y être exécutés par un
appel local habituel.
 Analogie
 Stratégie de pré-chargement en mémoire.
 Avantages
 Très efficace pour de nombreux appels
 Inconvénients
 Univers d’exécutions homogènes (ex machine
virtuelle).
 Performances selon le volume de codes et de données.
 Problèmes de partage des objets.
1
Réalisation en mémoire partagée
répartie
8
 L’appel distant est réalisé en utilisant une
mémoire virtuelle partagée répartie
 La procédure est installée pour le client comme pour
le serveur dans la mémoire virtuelle partagée répartie.
 Mais, réellement, elle est dans l’espace mémoire du
serveur.
 L’appel du client se fait comme si la procédure
était locale, provoquant un premier défaut de
page sur le début du code de la procédure.
 Le code et les données de la procédure distante
sont amenés page par page sur le site appelant
selon le parcours du code et des données.
 Analogie avec une stratégie page à la demande.
2
9
 Avantages
 Efficace en cas de nombreux appels
 Efficace si tout le code et les données ne sont pas
visités
 Résout le problème de l’utilisation des pointeurs
(références d’adresses en mémoire)
 Inconvénients
 Univers de systèmes homogènes
 Volume de codes et de données à échanger pages
par pages
 Problèmes de partage selon la cohérence de la
mémoire répartie
Réalisation en mémoire partagée
répartie
2
Réalisation par messages
10
 Deux messages (au moins) échangés : requête et
réponse
 Le premier message correspondant à la requête est
celui de l'appel de procédure, porteur des paramètres
d'appel.
 Le second message correspondant à la réponse est
celui du retour de procédure porteur des paramètres
résultats.
3
Notion des souches (1/2)
11
 Un mode de réalisation par interception
 Une procédure intercepteur intercepte l’appel d’un
client vers un serveur et modifie le traitement serveur
à sa guise
 Décomposition en traitements avant et après le
traitement serveur
 Décomposition en intercepteur coté client,
souche client, et intercepteur coté serveur,
souche serveur
 Souches (ou Stubs) =Talons = Squelettes (ou
Skeletons)…
 Objectif: transformer l’appel local en un appel
3
Notion des souches (2/2)
12
 La souche client ("client stub")
 Intercepteur (procédure) coté client qui reçoit l’appel en
mode local,
 Le transforme en appel distant,
 Envoie message d’appel de procédure,
 Reçoit le message contenant les résultats après
l’exécution,
 Retourne les résultats comme dans un retour local de
procédure.
 La souche serveur ("server stub")
 Intercepteur (procédure) coté serveur qui reçoit le
message d’appel,
 Fait réaliser l’exécution sur le site serveur par la procédure
serveur,
 Récupère les résultats et retransmet les résultats par
message.
3
Etapes de RPC par messages
(1/2)14
 Étape 1 : Le client réalise un appel procédural vers la procédure
souche client, la souche client collecte les paramètres , les emballe
dans le message d’appel
 Étape 2 : La souche client demande à une entité de transport locale la
transmission du message d'appel
 Étape 3 : Le message d’appel est transmis sur un réseau au site
serveur
3
 Étape 4 : Le message d’appel est
délivré à la souche qui déballe les
paramètres
 Étape 5 : La souche serveur
réalise l’appel effectif de la
procédure serveur
Etapes de RPC par messages
(2/2)15
 Étape 6 La procédure serveur ayant terminé son exécution
transmet à la souche serveur dans son retour de procédure les
paramètres résultats. La souche serveur collecte les paramètres
retour, les emballe dans un message.
 Étape 7 La procédure souche serveur demande à l ’entité de
transport serveur la transmission du message de réponse.
3
 Étape 8 : Le message de
réponse est transmis sur un
réseau au site client.
 Étape 9 : Le message de
réponse est délivré à la souche
client. La souche client déballe
les paramètres résultats.
 Étape 10 : La procédure
souche client transmet les
résultats au client en effectuant
un retour habituel de
procédure en mode local.
Diagramme de RPC par
messages16
Talon
(stub)
client
Talon
(stub)
serveur
Les talons (ou souches) client et serveur sont créés
(générés automatiquement) à partir d’une description
d’interface
3
Description d’interface
17
 Interface = “contrat” entre client et serveur
 Définition commune abstraite
 Indépendante d’un langage particulier (adaptée à des
langages multiples)
 Indépendante de la représentation des types
 Indépendante de la machine (hétérogénéité)
 Contenu minimal
 Identification des procédures (nom, version)
 Définition des types des paramètres, résultats
 Définition du mode de passage (IN, OUT, IN-OUT)
 Extensions possibles
 Procédures de conversion pour types complexes
3
RPC par message
18
 Avantages
 Applicable en univers hétérogènes moyennant
des conversions
 Partage d’accès sur le site serveur
 Inconvénients
 Pas d’usage des pointeurs dans les paramètres
 Échange de données complexes/de grande taille
délicat
 Peu efficace pour de très nombreux appels
3
Lightweight RPC (LRPC)
19
 Quand on appelle un serveur qui se trouve sur la
même machine, la traversée des couches réseaux
est inutile et coûteuse  Optimisation de la
communication
 Problème: Client et Serveur (2 processus) qui se
trouvent dans deux domaines de protection différents !
 Solution: la communication réseau est réalisée par
un segment de mémoire partagée entre le client et
le serveur qui contient une pile pour les paramètres
d’appel et de réponse.
 LRPC: principe de RPC mais entre processus
locaux s'exécutant sur la même machine
4
Lightweight RPC (LRPC)
20
4
 Avantages
 Transmission d’appel très performant comme mode de RPC
local
 Limites
 Uniquement applicable dans une même machine.
Synthèse sur les modes de
réalisation21
 RPC par messages :
 Le premier modèle implémenté
 Supporte l’hétérogénéité
 Le plus simple à réaliser
 RPC, RMI, DCE, CORBA, DCOM, SOAP
 Des optimisations peuvent être obtenues par
l’usage des autres solutions
 Exemple :
 Chorus a développé les quatre solutions.
 DCOM a développé RPC par messages + LRPC
Transmission des
arguments
22
Transmission par valeur
23
 Le seul mode de transmission des données dans les
messages en réseau
 Si le client et le serveur utilisent des formats de de données
différents  Conversion
 Définition du couple syntaxe abstraite/syntaxe de transfert
des données échangées:
 Syntaxe abstraite
 analogue à celles des langages évolués,
 facile à générer pour un développeur d’application
 À partir de la syntaxe abstraite : codage/décodage de la syntaxe
de transfert
 Syntaxe de transfert : une représentation lexicale des
données simples et une convention d’alignement
(emballage/déballage) des données commune au client et au
serveur
Transmission par valeur
dans l’appel de procédure distante
24
 En appel de procédure distante :
 génération automatique du code des souches à
partir de la syntaxe abstraite
 les souches fabriquent la syntaxe de transfert en
réalisant l’alignement (emballage/déballage) des
paramètres dans les messages.
Définition des nouveaux langages de syntaxe
abstraite adaptés aux appels de procédure
distante :
Interface Definition Language (IDL)
Pourquoi les langages IDL ?
25
 Être indépendant des langages évolués
utilisant le RPC
 Permettre l’appel distant avec tout langage
évolué
 Définition d’un langage pivot (intermédiaire) de
description de données ayant des fonctionnalités
assez riches pour les langages les plus récents.
 Notion de correspondance entre les types d’IDL
et les types des langages existants
Génération des souches
26
Source code
client
Source code
serveur
Définition de l’interface
en IDL
Compilateur IDL
Souche client Entête Souche serveur
Compilateur
(C, java, ..)
Compilateur
(C, java,..)
Binaire
client
Binaire
serveur
Compilateur
(C, java, ..)
Compilateur
(C, java,..)
Binaire souche
client
Binaire souche
serveur
Exemples d’IDL
et de format de présentation en RPC
27
 SUN RPC
 RPCL - XDR eXternal Data Representation
 OSF DCE
 IDL DCE - Format NDR Network Data Representation
 OMG CORBA
 IDL Corba - Format CDR Common Data Representation,
Protocole IIOP
 SUN Java RMI
 Java - Protocole JRMP Java Remote Method Protocol
 Microsoft DCOM
 MIDL Microsoft IDL - DCOM Protocole ORPC Object RPC
Format NDR
 Services Web
 Web Services Definition Language (WSDL) – SOAP
Autres modes de transmission :
passage par adresse
28
 Le passage par adresse utilise une adresse
mémoire centrale du site de l’appelant qui n’a
aucun sens sur l’appelé (sauf cas particulier)
 3 solutions :
 Interdiction totale des pointeurs
 La solution la plus répandu
 Passage par adresse en mémoire virtuelle
partagée répartie
 Simulation du passage par adresse en utilisant
une copie restauration
Simulation par copie restauration
29
 A l’appel: copie des valeurs des paramètres de
l’appelant vers l’appelé
 Au retour: copie de nouvelles valeurs pour les
paramètres de l’appelé vers l’appelant
 Marche bien dans beaucoup de cas mais violation
dans certains cas de la sémantique du passage
Simulation par copie restauration
30
 Exemple du problème de violation
procédure double_incr ( x , y ) ;
x , y : entier ;
début
x := x + 1 ;
y := y + 1 ;
fin ;
Séquence d’appel : passage par
adresse
a := 0 ;
double_incr ( a , a ) ;
Résultat attendu : a = 2
Utilisation d’une copie restauration
Résultat obtenu : a = 1
Désignation et liaison31
Désignation
32
 La structuration des noms et références permet de désigner les
services distants :
 Nom symbolique : une chaîne de caractères désignant la
procédure dans un annuaire ou serveur de nom
 Référence : une structure de données permettant de réaliser l’appel
 Référence : selon l’implantation considérée:
 Désignation du protocole permettant l’accès distant (TCP ou UDP)
 Désignation de l’hôte où se trouve le serveur (adresse IP)
 Désignation du point d’accès de service transport (numéro de port)
 Désignation de la procédure
 Serveur de nom : une table qui assure la correspondance
entre nom symbolique et référence
Liaison
33
 Moment de liaison : précoce (statique) ou tardive
(dynamique)
 Statique :
 localisation du serveur connue à la compilation
 pas d’appel à un serveur de noms (ou appel à la compilation)
 Dynamique : localisation au moment de l’exécution,
non connue à la compilation
 Désignation symbolique des services (non liée à un site
d’exécution)
 Liaison au premier appel : consultation du serveur de noms au
premier appel seulement
 Liaison à chaque appel : consultation du serveur de noms à
chaque appel
Désignation & liaison
34
Désignation & liaison
35
 1, 2 : le serveur s’enregistre auprès de l’annuaire avec nom,
@serveur, #port
 3, 4, 5 : le client consulte l’annuaire pour trouver @serveur,
#port à partir du nom symbolique
 L’appel peut alors avoir lieu
Gestion du contrôle36
Contrôle client : RPC en mode synchrone
37
 L’exécution du client est suspendue tant que la
réponse du serveur n’est pas revenue ou qu’une
condition d’exception n’a pas entraîné un traitement
spécifique
 Avantage : le flot de contrôle est le même que dans
l’appel en mode centralisé.
 Inconvénient : le client reste inactif.
Contrôle client : RPC en mode synchrone
38
 Solution au problème de l’inactivité du client :
création des activités concurrentes
 Création de (au moins) deux activités
(« processus léger » ou « threads ») sur le site
client:
 L’une occupe le site appelant par un travail à faire.
 L’autre gère l’appel en mode synchrone en restant
bloquée :
 Le fonctionnement est exactement celui d’un appel
habituel.
Contrôle client : RPC en mode asynchrone
39
 Le client poursuit son exécution immédiatement
après l’émission du message porteur de l’appel
 La procédure distante s’exécute en parallèle avec
la poursuite du client
 Le client doit récupérer les résultats quand il en a
besoin
Contrôle serveur : exécution séquentielle des
appels
40
 Les requêtes d’exécution sont traitées l’une après
l’autre par le serveur  exclusion mutuelle entre
les traitements.
 Si la couche transport assure la livraison en
séquence et que l’on gère une file d’attente
« FIFO : premier arrivé premier servi », on a un
traitement ordonné des suites d’appels.
Contrôle serveur: exécution parallèle des
appels
41
 le serveur créé un processus ou une activité
(« processus léger » ou « thread ») pour chaque
appel
 Gestion possible de pool de processus ou d’activités
 Les appels sont exécutés en parallèle.
 Si les procédures manipulent des données globales
persistantes sur le site serveur, le contrôle de
concurrence doit être géré.
Gestion des données42
Gestion des données applicatives
sans données partagées persistantes
43
 L’appel de procédure s’exécute en fonction des
paramètres d’entrée en produisant des
paramètres résultats
 Données locales à la procédure
 Pas de modification de données persistantes sur le
serveur
 Situation très favorable, on n’a pas à gérer:
 la tolérance aux pannes
 le contrôle de concurrence
Gestion des données applicatives
partagées persistantes
44
 Les exécutions successives manipulent des
données persistantes sur le serveur:
 Une exécution modifie le contexte sur le serveur
 Exemple: un serveur de fichier, de bases de données.
 Problème de contrôle de concurrence
 Problème des pannes en cours
d’exécution
Gestion des données protocolaires
mode avec ou sans état
45
 La terminologie avec ou sans état porte sur
l’existence ou non d’un descriptif pour chaque
relation client serveur au niveau du serveur.
 Notion d’état : un ensemble de données
persistantes au niveau du protocole pour
chaque relation client serveur :
 Permettrait de traiter les requêtes dans l’ordre
d’émission.
 Permettrait de traiter une requête en fonction des
caractéristiques de la relation client serveur
(qualité de service).
Mode sans état
46
 Les appels successifs d’une même procédure
s’exécutent sans liens entre eux
 Chaque opération du point de vue du
protocole s’effectue sans référence au passé
 Exemples
 NFS "Network File System" de SUN
 système de fichier réparti basé sur RPC sans état
 HTTP "HyperText Transfer Protocol"
 protocole d’exécution de méthodes distantes sans état
Mode avec état
47
 Les appels successifs s’exécutent en fonction
d’un état de la relation client serveur laissé par
les appels antérieurs
 La gestion de l'ordre des requêtes est
indispensable
 Exemple :
 Opérations d’achat des produits sur Internet
(payement électronique)
Tolérance aux pannes48
Appel local vs Appel distant
49
En appel local
 L’appelant et l’appelé s’exécutent sur la même machine : même
exécutant => mêmes performances et modes de pannes.
 L’appel et le retour de procédure sont des mécanismes internes
considérés comme fiables.
 Problème des erreurs abordé => exceptions chez l’appelant.
En appel distant
 Appelant et appelé peuvent tomber en panne indépendamment
 Le message d’appel ou celui de retour peuvent être perdus
 Le temps de réponse peut-être très long en raison de surcharges
diverses (réseau, site appelé)
 La prise en compte des défaillances nécessite de formuler des
hypothèses de défaillances, de détecter les défaillances, et
enfin de réagir à cette détection.
Hypothèses de défaillances
50
 Système de communication
 Congestion du réseau, messages retardés
 Perte de messages
 Altération de messages
 Serveur
 Défaillance avant l’exécution de la procédure
 Défaillance pendant l’exécution de la procédure
 Défaillance après l’exécution de la procédure
 Défaillance définitive ou reprise possible
 Client
 Défaillance pendant le traitement de la requête
Détection de pannes – Délai de
garde51
 Les mécanismes de détection de pannes reposent sur des
délais de garde.
 À l'envoi d'un message,
 une horloge de garde est armée, avec une valeur estimée de la
borne supérieure du délai de réception de la réponse.
 Le dépassement du délai de garde déclenche une action de
reprise
 Les horloges de garde sont placées côté client, à l'envoi du
message d'appel, et côté serveur, à l'envoi du message
de réponse.
 Dans les deux cas, l'action de reprise consiste à renvoyer le
message.
 Ilest difficile d'estimer les délais de garde : un message
d'appel peut être renvoyé alors que l'appel a déjà eu lieu, et
la procédure peut ainsi être exécutée plusieurs fois!
RPC : sémantique en cas de
panne52
 Détection de panne = expiration de délai de garde.
 On tente de ré-exécuter l’appel. Combien de fois la
procédure a-t-elle été exécutée!?
 Sémantique : nombre d’exécution de la
procédure
 dépend des hypothèses de pannes et du mécanisme de
reprise
 Indéfini (pas d’hypothèses)
 Au moins une fois (appel répété, plusieurs exécutions
possibles, au moins une réussit)
 acceptable si opération idempotente (2 appels successifs ont le
même effet que 1 appel)
 Au plus une fois (0 ou 1 fois)
 on évite les exécutions répétées, mais on ne garantit pas le
succès
Traitement des défaillances
53
Congestion du réseau ou du serveur
 Panne transitoire (ne nécessite pas d’action de reprise)
 Détection : expiration du délai de garde coté client ou coté
serveur
 Reprise (délai de garde du client)
 La souche client réémet l’appel (avec le même identificateur)
sans intervention de l’application
 Le service d’exécution détecte que c’est une réémission
 Exécution de l’appel en cours : le nouvel appel du client n’a aucun
effet
 Retour déjà effectué : réémission du résultat
 Reprise (délai de garde du serveur) : réémission du
résultat
 Sémantique
 Si défaillance transitoire : exactement une fois
 Si défaillance permanente : détection, exception vers application
Traitement des défaillances
54
Panne du serveur après émission de l’appel
 3 cas possibles sur l’exécution de l’appel
 Traitement : pas fait, partiel, total
 Détection : expiration du délai de garde du client
 Reprise
 Le client réémet l’appel dès que le serveur redémarre
 Sémantique : au moins une fois
 Le client ne connaît pas l’endroit de la panne
 Solution : le serveur mémorise l’identificateur de
requête et état avant exécution
Traitement des défaillances
55
Panne du client après émission de l’appel
 L’appel est correctement traité par le serveur
 Le processus exécutant courant est déclaré orphelin
 Détection : expiration du délai de garde du serveur,
après n réémissions infructueuses
 Action du serveur : élimination des orphelins pour libérer
ses ressources
 Reprise (après redémarrage du client)
 L’application cliente réémet l’appel (avec identifiant
différent)
 Sémantique : au moins une fois
 Le serveur ne peut pas détecter qu’il s’agit d’une répétition
 Pas d ’incidence si idempotent
 Sinon, le client doit informer le serveur pour qu’il revient à l’état
cohérent avant exécution de son nouvel appel
Conclusion56
Avantages des RPC
57
 De plus haut niveau
 Les détails de communication sont cachés.
 Une structure de contrôle bien connue, l’appel
de procédure
 Support naturel de l’approche client-serveur
 Qui s’intègre à l’univers réparti des concepts
modernes de génie logiciel: approche objets,
approches composants
 Modularité, encapsulation, réutilisation par délégation.
67
68
Sémantique des pannes
69
 La sémantique d’appel caractérise combien de fois
la procédure appelée à distance est exécutée suite
à un appel en l’absence ou en présence de
défaillances.
 La sémantique est variable selon la nature du
mécanisme mis en œuvre et la nature du serveur:
 Serveur avec état: le serveur conserve des informations
sur les appels des clients
 Serveur sans état: gestion des pannes à la charge du
client
 Remarque [Idempotence]: une procédure est
idempotente si quel que soit le nombre d’exécutions,
elle délivre le même résultat
 Lecture de fichiers et une opération idempotente
 L’incrémentation d’une variable est non idempotente
Sémantique exactement une fois
70
 Une seule exécution est effectuée et celle-ci réussit
toujours.
 Réémettre requêtes/réponses
 Client:
 Arme un délai. Après expiration du délai, le client réémet
sa requête jusqu’à réception d’une réponse
 Au bout d’un nombre de tentatives, le serveur est
considéré indisponible
 Serveur:
 Garde en mémoire id_req, résultat (pour la perte d’une
réponse)
 Pour chaque requête id_req, réémettre résultat
 Reprise du serveur: la requête ne doit pas être
réexécutée: conserver un journal des requêtes traitées.
 Difficile à implémenter en pratique!
Sémantique au plus une fois
71
 Cas d'une fonction non idempotente: on ne doit pas
l'exécuter deux fois.
 Solution très répandue: Identification des requêtes +
exécution effectuée une seule fois.
 Exécution effectuée une seule fois:
 Si tout va bien le résultat est retourné à l’utilisateur
 Si un problème est détecté il est signalé à l’utilisateur.
Laisser à la charge du client.
 Aucune tentative de reprise n’est effectuée. Elle est
laissée entièrement à la charge du client.
Sémantique au moins une fois
72
 Ne convient pas aux procédures non
idempotentes
 Client:
 Arme un délai. Après expiration du délai, le client
réémet sa requête jusqu’à réception d’une
réponse
 Au bout d’un nombre de tentatives, le serveur est
déclaré indisponible.

Contenu connexe

Tendances

Chp3 - Diagramme de Classes
Chp3 - Diagramme de ClassesChp3 - Diagramme de Classes
Chp3 - Diagramme de ClassesLilia Sfaxi
 
Pfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEEPfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEEOussama Djerba
 
Administration réseaux sous linux cours 1
Administration réseaux sous linux   cours 1Administration réseaux sous linux   cours 1
Administration réseaux sous linux cours 1Stephen Salama
 
Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...Ilyas CHAOUA
 
Mohamed youssfi support architectures logicielles distribuées basées sue les ...
Mohamed youssfi support architectures logicielles distribuées basées sue les ...Mohamed youssfi support architectures logicielles distribuées basées sue les ...
Mohamed youssfi support architectures logicielles distribuées basées sue les ...ENSET, Université Hassan II Casablanca
 
diagramme de séquence UML
diagramme de séquence UMLdiagramme de séquence UML
diagramme de séquence UMLAmir Souissi
 
Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...Addi Ait-Mlouk
 
Présentation de RMI Java
Présentation de RMI JavaPrésentation de RMI Java
Présentation de RMI JavaZakaria Bouazza
 
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
Rapport pfe Conceptionet Developpement d'une Application web et  Mobile Rapport pfe Conceptionet Developpement d'une Application web et  Mobile
Rapport pfe Conceptionet Developpement d'une Application web et Mobile Raoua Bennasr
 
TP2-UML-Correction
TP2-UML-CorrectionTP2-UML-Correction
TP2-UML-CorrectionLilia Sfaxi
 
Notes de cours et tp - Administation Systèmes
Notes de cours et tp  - Administation Systèmes Notes de cours et tp  - Administation Systèmes
Notes de cours et tp - Administation Systèmes Ikram Benabdelouahab
 
Tp3 - Application SOA avec BPEL
Tp3 - Application SOA avec BPELTp3 - Application SOA avec BPEL
Tp3 - Application SOA avec BPELLilia Sfaxi
 
Systèmes d'Exploitation - chp6-synchronisation
Systèmes d'Exploitation - chp6-synchronisationSystèmes d'Exploitation - chp6-synchronisation
Systèmes d'Exploitation - chp6-synchronisationLilia Sfaxi
 
Introduction aux architectures des SI
Introduction aux architectures des SI Introduction aux architectures des SI
Introduction aux architectures des SI Heithem Abbes
 
Les architectures client serveur
Les architectures client serveurLes architectures client serveur
Les architectures client serveurAmeni Ouertani
 
Architectures orientés services (SOA)
Architectures orientés services (SOA)Architectures orientés services (SOA)
Architectures orientés services (SOA)Heithem Abbes
 
Fascicule de tp atelier développement web
Fascicule de tp atelier développement webFascicule de tp atelier développement web
Fascicule de tp atelier développement webHouda TOUKABRI
 

Tendances (20)

Chp3 - Diagramme de Classes
Chp3 - Diagramme de ClassesChp3 - Diagramme de Classes
Chp3 - Diagramme de Classes
 
Cours architecture
Cours architectureCours architecture
Cours architecture
 
Pfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEEPfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEE
 
Administration réseaux sous linux cours 1
Administration réseaux sous linux   cours 1Administration réseaux sous linux   cours 1
Administration réseaux sous linux cours 1
 
Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...
 
Mohamed youssfi support architectures logicielles distribuées basées sue les ...
Mohamed youssfi support architectures logicielles distribuées basées sue les ...Mohamed youssfi support architectures logicielles distribuées basées sue les ...
Mohamed youssfi support architectures logicielles distribuées basées sue les ...
 
diagramme de séquence UML
diagramme de séquence UMLdiagramme de séquence UML
diagramme de séquence UML
 
Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...
 
Sécurité des Applications Web avec Json Web Token (JWT)
Sécurité des Applications Web avec Json Web Token (JWT)Sécurité des Applications Web avec Json Web Token (JWT)
Sécurité des Applications Web avec Json Web Token (JWT)
 
Présentation de RMI Java
Présentation de RMI JavaPrésentation de RMI Java
Présentation de RMI Java
 
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
Rapport pfe Conceptionet Developpement d'une Application web et  Mobile Rapport pfe Conceptionet Developpement d'une Application web et  Mobile
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
 
TP2-UML-Correction
TP2-UML-CorrectionTP2-UML-Correction
TP2-UML-Correction
 
Notes de cours et tp - Administation Systèmes
Notes de cours et tp  - Administation Systèmes Notes de cours et tp  - Administation Systèmes
Notes de cours et tp - Administation Systèmes
 
Tp3 - Application SOA avec BPEL
Tp3 - Application SOA avec BPELTp3 - Application SOA avec BPEL
Tp3 - Application SOA avec BPEL
 
Support JEE Servlet Jsp MVC M.Youssfi
Support JEE Servlet Jsp MVC M.YoussfiSupport JEE Servlet Jsp MVC M.Youssfi
Support JEE Servlet Jsp MVC M.Youssfi
 
Systèmes d'Exploitation - chp6-synchronisation
Systèmes d'Exploitation - chp6-synchronisationSystèmes d'Exploitation - chp6-synchronisation
Systèmes d'Exploitation - chp6-synchronisation
 
Introduction aux architectures des SI
Introduction aux architectures des SI Introduction aux architectures des SI
Introduction aux architectures des SI
 
Les architectures client serveur
Les architectures client serveurLes architectures client serveur
Les architectures client serveur
 
Architectures orientés services (SOA)
Architectures orientés services (SOA)Architectures orientés services (SOA)
Architectures orientés services (SOA)
 
Fascicule de tp atelier développement web
Fascicule de tp atelier développement webFascicule de tp atelier développement web
Fascicule de tp atelier développement web
 

En vedette

En vedette (7)

Sockets
SocketsSockets
Sockets
 
Servlets et JSP
Servlets et JSPServlets et JSP
Servlets et JSP
 
Cloud computing
Cloud computingCloud computing
Cloud computing
 
Java Server Faces (JSF)
Java Server Faces (JSF)Java Server Faces (JSF)
Java Server Faces (JSF)
 
Génie Logiciels : Introduction aux architectures
Génie Logiciels : Introduction aux architecturesGénie Logiciels : Introduction aux architectures
Génie Logiciels : Introduction aux architectures
 
Le Manifeste Agile
Le Manifeste AgileLe Manifeste Agile
Le Manifeste Agile
 
Entreprise Java Beans (EJB)
Entreprise Java Beans (EJB)Entreprise Java Beans (EJB)
Entreprise Java Beans (EJB)
 

Similaire à Appels de procédures distants (RPC)

Les socket ing1_issat
Les socket ing1_issatLes socket ing1_issat
Les socket ing1_issatsloumaallagui
 
Cours 2 les architectures reparties
Cours 2 les architectures repartiesCours 2 les architectures reparties
Cours 2 les architectures repartiesMariem ZAOUALI
 
Les Web Services en 60 diapos chrono !
Les Web Services en 60 diapos chrono !Les Web Services en 60 diapos chrono !
Les Web Services en 60 diapos chrono !Olivier Le Goaër
 
Cours 1 les principes de base
Cours 1 les principes de baseCours 1 les principes de base
Cours 1 les principes de baseMariem ZAOUALI
 
Ch3_Couche application.pptx
Ch3_Couche application.pptxCh3_Couche application.pptx
Ch3_Couche application.pptxOthmaneMansouri1
 
Socket tcp ip client server on langace c
Socket tcp ip client server on langace c Socket tcp ip client server on langace c
Socket tcp ip client server on langace c mouad Lousimi
 
Cisco discovery-module-final-v4
Cisco discovery-module-final-v4Cisco discovery-module-final-v4
Cisco discovery-module-final-v4r2ch
 
Presentation
PresentationPresentation
Presentationbois
 
Chapitre-4-Programmation-réseau-avec-les-sockets.pdf
Chapitre-4-Programmation-réseau-avec-les-sockets.pdfChapitre-4-Programmation-réseau-avec-les-sockets.pdf
Chapitre-4-Programmation-réseau-avec-les-sockets.pdfYoussefJamma
 
QoS of WLAN (WiFi) - French
QoS of WLAN (WiFi) - FrenchQoS of WLAN (WiFi) - French
QoS of WLAN (WiFi) - FrenchAssia Mounir
 
resume-theorique-m107-2203-6246f60d6b994.pdf
resume-theorique-m107-2203-6246f60d6b994.pdfresume-theorique-m107-2203-6246f60d6b994.pdf
resume-theorique-m107-2203-6246f60d6b994.pdfFootballLovers9
 

Similaire à Appels de procédures distants (RPC) (20)

Cours apd
Cours apdCours apd
Cours apd
 
Les socket ing1_issat
Les socket ing1_issatLes socket ing1_issat
Les socket ing1_issat
 
Cours 2 les architectures reparties
Cours 2 les architectures repartiesCours 2 les architectures reparties
Cours 2 les architectures reparties
 
Les Web Services en 60 diapos chrono !
Les Web Services en 60 diapos chrono !Les Web Services en 60 diapos chrono !
Les Web Services en 60 diapos chrono !
 
Cours 1 les principes de base
Cours 1 les principes de baseCours 1 les principes de base
Cours 1 les principes de base
 
Les sockets.pptx
Les sockets.pptxLes sockets.pptx
Les sockets.pptx
 
Web Services
Web ServicesWeb Services
Web Services
 
Rpc 4bypage
Rpc 4bypageRpc 4bypage
Rpc 4bypage
 
Chap 2 b ds client-serveur
Chap 2   b ds client-serveurChap 2   b ds client-serveur
Chap 2 b ds client-serveur
 
Etude de la WIFI sur NS2
Etude de la WIFI sur NS2Etude de la WIFI sur NS2
Etude de la WIFI sur NS2
 
Ch3_Couche application.pptx
Ch3_Couche application.pptxCh3_Couche application.pptx
Ch3_Couche application.pptx
 
8-socket.pdf
8-socket.pdf8-socket.pdf
8-socket.pdf
 
Socket tcp ip client server on langace c
Socket tcp ip client server on langace c Socket tcp ip client server on langace c
Socket tcp ip client server on langace c
 
Cisco discovery-module-final-v4
Cisco discovery-module-final-v4Cisco discovery-module-final-v4
Cisco discovery-module-final-v4
 
Presentation
PresentationPresentation
Presentation
 
Chapitre-4-Programmation-réseau-avec-les-sockets.pdf
Chapitre-4-Programmation-réseau-avec-les-sockets.pdfChapitre-4-Programmation-réseau-avec-les-sockets.pdf
Chapitre-4-Programmation-réseau-avec-les-sockets.pdf
 
Vpn
VpnVpn
Vpn
 
Applications_Slide.pdf
Applications_Slide.pdfApplications_Slide.pdf
Applications_Slide.pdf
 
QoS of WLAN (WiFi) - French
QoS of WLAN (WiFi) - FrenchQoS of WLAN (WiFi) - French
QoS of WLAN (WiFi) - French
 
resume-theorique-m107-2203-6246f60d6b994.pdf
resume-theorique-m107-2203-6246f60d6b994.pdfresume-theorique-m107-2203-6246f60d6b994.pdf
resume-theorique-m107-2203-6246f60d6b994.pdf
 

Dernier

Calendrier de la semaine du 8 au 12 avril
Calendrier de la semaine du 8 au 12 avrilCalendrier de la semaine du 8 au 12 avril
Calendrier de la semaine du 8 au 12 avrilfrizzole
 
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptx
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptxPrésentation - Initiatives - CECOSDA - OIF - Fact Checking.pptx
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptxJCAC
 
Bibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdf
Bibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdfBibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdf
Bibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdfBibdoc 37
 
Pas de vagues. pptx Film français
Pas de vagues.  pptx   Film     françaisPas de vagues.  pptx   Film     français
Pas de vagues. pptx Film françaisTxaruka
 
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdf
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdfVulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdf
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdfSylvianeBachy
 
Faut-il avoir peur de la technique ? (G. Gay-Para)
Faut-il avoir peur de la technique ? (G. Gay-Para)Faut-il avoir peur de la technique ? (G. Gay-Para)
Faut-il avoir peur de la technique ? (G. Gay-Para)Gabriel Gay-Para
 
Newsletter SPW Agriculture en province du Luxembourg du 10-04-24
Newsletter SPW Agriculture en province du Luxembourg du 10-04-24Newsletter SPW Agriculture en province du Luxembourg du 10-04-24
Newsletter SPW Agriculture en province du Luxembourg du 10-04-24BenotGeorges3
 
Chana Orloff.pptx Sculptrice franco-ukranienne
Chana Orloff.pptx Sculptrice franco-ukranienneChana Orloff.pptx Sculptrice franco-ukranienne
Chana Orloff.pptx Sculptrice franco-ukranienneTxaruka
 
DIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptx
DIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptxDIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptx
DIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptxMartin M Flynn
 
Apprendre avec des top et nano influenceurs
Apprendre avec des top et nano influenceursApprendre avec des top et nano influenceurs
Apprendre avec des top et nano influenceursStagiaireLearningmat
 
Bibdoc 2024 - Les intelligences artificielles en bibliotheque.pdf
Bibdoc 2024 - Les intelligences artificielles en bibliotheque.pdfBibdoc 2024 - Les intelligences artificielles en bibliotheque.pdf
Bibdoc 2024 - Les intelligences artificielles en bibliotheque.pdfBibdoc 37
 
La Base unique départementale - Quel bilan, au bout de 5 ans .pdf
La Base unique départementale - Quel bilan, au bout de 5 ans .pdfLa Base unique départementale - Quel bilan, au bout de 5 ans .pdf
La Base unique départementale - Quel bilan, au bout de 5 ans .pdfbdp12
 
Pas de vagues. pptx Film français
Pas de vagues.  pptx      Film   françaisPas de vagues.  pptx      Film   français
Pas de vagues. pptx Film françaisTxaruka
 
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...Bibdoc 37
 
Aux origines de la sociologie : du XIXème au début XX ème siècle
Aux origines de la sociologie : du XIXème au début XX ème siècleAux origines de la sociologie : du XIXème au début XX ème siècle
Aux origines de la sociologie : du XIXème au début XX ème siècleAmar LAKEL, PhD
 

Dernier (16)

Calendrier de la semaine du 8 au 12 avril
Calendrier de la semaine du 8 au 12 avrilCalendrier de la semaine du 8 au 12 avril
Calendrier de la semaine du 8 au 12 avril
 
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptx
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptxPrésentation - Initiatives - CECOSDA - OIF - Fact Checking.pptx
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptx
 
Bibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdf
Bibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdfBibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdf
Bibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdf
 
Pas de vagues. pptx Film français
Pas de vagues.  pptx   Film     françaisPas de vagues.  pptx   Film     français
Pas de vagues. pptx Film français
 
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdf
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdfVulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdf
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdf
 
Faut-il avoir peur de la technique ? (G. Gay-Para)
Faut-il avoir peur de la technique ? (G. Gay-Para)Faut-il avoir peur de la technique ? (G. Gay-Para)
Faut-il avoir peur de la technique ? (G. Gay-Para)
 
Newsletter SPW Agriculture en province du Luxembourg du 10-04-24
Newsletter SPW Agriculture en province du Luxembourg du 10-04-24Newsletter SPW Agriculture en province du Luxembourg du 10-04-24
Newsletter SPW Agriculture en province du Luxembourg du 10-04-24
 
Chana Orloff.pptx Sculptrice franco-ukranienne
Chana Orloff.pptx Sculptrice franco-ukranienneChana Orloff.pptx Sculptrice franco-ukranienne
Chana Orloff.pptx Sculptrice franco-ukranienne
 
DIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptx
DIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptxDIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptx
DIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptx
 
Apprendre avec des top et nano influenceurs
Apprendre avec des top et nano influenceursApprendre avec des top et nano influenceurs
Apprendre avec des top et nano influenceurs
 
Bibdoc 2024 - Les intelligences artificielles en bibliotheque.pdf
Bibdoc 2024 - Les intelligences artificielles en bibliotheque.pdfBibdoc 2024 - Les intelligences artificielles en bibliotheque.pdf
Bibdoc 2024 - Les intelligences artificielles en bibliotheque.pdf
 
La Base unique départementale - Quel bilan, au bout de 5 ans .pdf
La Base unique départementale - Quel bilan, au bout de 5 ans .pdfLa Base unique départementale - Quel bilan, au bout de 5 ans .pdf
La Base unique départementale - Quel bilan, au bout de 5 ans .pdf
 
Bulletin des bibliotheques Burkina Faso mars 2024
Bulletin des bibliotheques Burkina Faso mars 2024Bulletin des bibliotheques Burkina Faso mars 2024
Bulletin des bibliotheques Burkina Faso mars 2024
 
Pas de vagues. pptx Film français
Pas de vagues.  pptx      Film   françaisPas de vagues.  pptx      Film   français
Pas de vagues. pptx Film français
 
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...
 
Aux origines de la sociologie : du XIXème au début XX ème siècle
Aux origines de la sociologie : du XIXème au début XX ème siècleAux origines de la sociologie : du XIXème au début XX ème siècle
Aux origines de la sociologie : du XIXème au début XX ème siècle
 

Appels de procédures distants (RPC)

  • 2. Rappel du schéma client- serveur2  Appel synchrone Requête-Réponse  Mise en œuvre  Bas niveau : utilisation directe du transport : sockets (construit sur TCP ou UDP)  Exemple : utilisation des sockets en C  Haut niveau : intégration dans un langage de programmation : RPC (construit sur sockets)  Exemple : RPC en C
  • 3. Définition 3  Appel de procédure à distance (Remote Procedure Call, ou RPC) : un outil pour construire des applications client-serveur dans un langage de haut niveau  L’appel et le retour ont lieu sur un site , l’exécution se déroule sur un site distinct  L’effet de l’appel doit être identique dans les deux situations (local et distant)
  • 4. Avantages attendus 4  Facilité de programmation  La complexité des protocoles de communication est cachée  Ne pas avoir à programmer des échanges au niveau réseau  Facilité de mise au point : une application peut être mise au point sur un site unique, puis déployée sur plusieurs sites  Portabilité : résulte de l’usage d’un langage de haut niveau  Indépendance par rapport au système de communication
  • 5. Problèmes de réalisation 5  Transmission des paramètres  conversion entre la forme interne, propre à un langage, et une forme adaptée à la transmission  Gestion des processus  Séquentielle et parallèle  Réaction aux défaillances  Trois modes de défaillance indépendants : client, serveur, réseau
  • 6. Mise en œuvre 6  Par migration  Par mémoire partagée  Par messages  Par appel léger (LRPC) 1 2 3 4
  • 7. Réalisation par migration 7  Stratégie de migration  Le code et les données de la procédure distante sont amenés sur le site appelant pour y être exécutés par un appel local habituel.  Analogie  Stratégie de pré-chargement en mémoire.  Avantages  Très efficace pour de nombreux appels  Inconvénients  Univers d’exécutions homogènes (ex machine virtuelle).  Performances selon le volume de codes et de données.  Problèmes de partage des objets. 1
  • 8. Réalisation en mémoire partagée répartie 8  L’appel distant est réalisé en utilisant une mémoire virtuelle partagée répartie  La procédure est installée pour le client comme pour le serveur dans la mémoire virtuelle partagée répartie.  Mais, réellement, elle est dans l’espace mémoire du serveur.  L’appel du client se fait comme si la procédure était locale, provoquant un premier défaut de page sur le début du code de la procédure.  Le code et les données de la procédure distante sont amenés page par page sur le site appelant selon le parcours du code et des données.  Analogie avec une stratégie page à la demande. 2
  • 9. 9  Avantages  Efficace en cas de nombreux appels  Efficace si tout le code et les données ne sont pas visités  Résout le problème de l’utilisation des pointeurs (références d’adresses en mémoire)  Inconvénients  Univers de systèmes homogènes  Volume de codes et de données à échanger pages par pages  Problèmes de partage selon la cohérence de la mémoire répartie Réalisation en mémoire partagée répartie 2
  • 10. Réalisation par messages 10  Deux messages (au moins) échangés : requête et réponse  Le premier message correspondant à la requête est celui de l'appel de procédure, porteur des paramètres d'appel.  Le second message correspondant à la réponse est celui du retour de procédure porteur des paramètres résultats. 3
  • 11. Notion des souches (1/2) 11  Un mode de réalisation par interception  Une procédure intercepteur intercepte l’appel d’un client vers un serveur et modifie le traitement serveur à sa guise  Décomposition en traitements avant et après le traitement serveur  Décomposition en intercepteur coté client, souche client, et intercepteur coté serveur, souche serveur  Souches (ou Stubs) =Talons = Squelettes (ou Skeletons)…  Objectif: transformer l’appel local en un appel 3
  • 12. Notion des souches (2/2) 12  La souche client ("client stub")  Intercepteur (procédure) coté client qui reçoit l’appel en mode local,  Le transforme en appel distant,  Envoie message d’appel de procédure,  Reçoit le message contenant les résultats après l’exécution,  Retourne les résultats comme dans un retour local de procédure.  La souche serveur ("server stub")  Intercepteur (procédure) coté serveur qui reçoit le message d’appel,  Fait réaliser l’exécution sur le site serveur par la procédure serveur,  Récupère les résultats et retransmet les résultats par message. 3
  • 13. Etapes de RPC par messages (1/2)14  Étape 1 : Le client réalise un appel procédural vers la procédure souche client, la souche client collecte les paramètres , les emballe dans le message d’appel  Étape 2 : La souche client demande à une entité de transport locale la transmission du message d'appel  Étape 3 : Le message d’appel est transmis sur un réseau au site serveur 3  Étape 4 : Le message d’appel est délivré à la souche qui déballe les paramètres  Étape 5 : La souche serveur réalise l’appel effectif de la procédure serveur
  • 14. Etapes de RPC par messages (2/2)15  Étape 6 La procédure serveur ayant terminé son exécution transmet à la souche serveur dans son retour de procédure les paramètres résultats. La souche serveur collecte les paramètres retour, les emballe dans un message.  Étape 7 La procédure souche serveur demande à l ’entité de transport serveur la transmission du message de réponse. 3  Étape 8 : Le message de réponse est transmis sur un réseau au site client.  Étape 9 : Le message de réponse est délivré à la souche client. La souche client déballe les paramètres résultats.  Étape 10 : La procédure souche client transmet les résultats au client en effectuant un retour habituel de procédure en mode local.
  • 15. Diagramme de RPC par messages16 Talon (stub) client Talon (stub) serveur Les talons (ou souches) client et serveur sont créés (générés automatiquement) à partir d’une description d’interface 3
  • 16. Description d’interface 17  Interface = “contrat” entre client et serveur  Définition commune abstraite  Indépendante d’un langage particulier (adaptée à des langages multiples)  Indépendante de la représentation des types  Indépendante de la machine (hétérogénéité)  Contenu minimal  Identification des procédures (nom, version)  Définition des types des paramètres, résultats  Définition du mode de passage (IN, OUT, IN-OUT)  Extensions possibles  Procédures de conversion pour types complexes 3
  • 17. RPC par message 18  Avantages  Applicable en univers hétérogènes moyennant des conversions  Partage d’accès sur le site serveur  Inconvénients  Pas d’usage des pointeurs dans les paramètres  Échange de données complexes/de grande taille délicat  Peu efficace pour de très nombreux appels 3
  • 18. Lightweight RPC (LRPC) 19  Quand on appelle un serveur qui se trouve sur la même machine, la traversée des couches réseaux est inutile et coûteuse  Optimisation de la communication  Problème: Client et Serveur (2 processus) qui se trouvent dans deux domaines de protection différents !  Solution: la communication réseau est réalisée par un segment de mémoire partagée entre le client et le serveur qui contient une pile pour les paramètres d’appel et de réponse.  LRPC: principe de RPC mais entre processus locaux s'exécutant sur la même machine 4
  • 19. Lightweight RPC (LRPC) 20 4  Avantages  Transmission d’appel très performant comme mode de RPC local  Limites  Uniquement applicable dans une même machine.
  • 20. Synthèse sur les modes de réalisation21  RPC par messages :  Le premier modèle implémenté  Supporte l’hétérogénéité  Le plus simple à réaliser  RPC, RMI, DCE, CORBA, DCOM, SOAP  Des optimisations peuvent être obtenues par l’usage des autres solutions  Exemple :  Chorus a développé les quatre solutions.  DCOM a développé RPC par messages + LRPC
  • 22. Transmission par valeur 23  Le seul mode de transmission des données dans les messages en réseau  Si le client et le serveur utilisent des formats de de données différents  Conversion  Définition du couple syntaxe abstraite/syntaxe de transfert des données échangées:  Syntaxe abstraite  analogue à celles des langages évolués,  facile à générer pour un développeur d’application  À partir de la syntaxe abstraite : codage/décodage de la syntaxe de transfert  Syntaxe de transfert : une représentation lexicale des données simples et une convention d’alignement (emballage/déballage) des données commune au client et au serveur
  • 23. Transmission par valeur dans l’appel de procédure distante 24  En appel de procédure distante :  génération automatique du code des souches à partir de la syntaxe abstraite  les souches fabriquent la syntaxe de transfert en réalisant l’alignement (emballage/déballage) des paramètres dans les messages. Définition des nouveaux langages de syntaxe abstraite adaptés aux appels de procédure distante : Interface Definition Language (IDL)
  • 24. Pourquoi les langages IDL ? 25  Être indépendant des langages évolués utilisant le RPC  Permettre l’appel distant avec tout langage évolué  Définition d’un langage pivot (intermédiaire) de description de données ayant des fonctionnalités assez riches pour les langages les plus récents.  Notion de correspondance entre les types d’IDL et les types des langages existants
  • 25. Génération des souches 26 Source code client Source code serveur Définition de l’interface en IDL Compilateur IDL Souche client Entête Souche serveur Compilateur (C, java, ..) Compilateur (C, java,..) Binaire client Binaire serveur Compilateur (C, java, ..) Compilateur (C, java,..) Binaire souche client Binaire souche serveur
  • 26. Exemples d’IDL et de format de présentation en RPC 27  SUN RPC  RPCL - XDR eXternal Data Representation  OSF DCE  IDL DCE - Format NDR Network Data Representation  OMG CORBA  IDL Corba - Format CDR Common Data Representation, Protocole IIOP  SUN Java RMI  Java - Protocole JRMP Java Remote Method Protocol  Microsoft DCOM  MIDL Microsoft IDL - DCOM Protocole ORPC Object RPC Format NDR  Services Web  Web Services Definition Language (WSDL) – SOAP
  • 27. Autres modes de transmission : passage par adresse 28  Le passage par adresse utilise une adresse mémoire centrale du site de l’appelant qui n’a aucun sens sur l’appelé (sauf cas particulier)  3 solutions :  Interdiction totale des pointeurs  La solution la plus répandu  Passage par adresse en mémoire virtuelle partagée répartie  Simulation du passage par adresse en utilisant une copie restauration
  • 28. Simulation par copie restauration 29  A l’appel: copie des valeurs des paramètres de l’appelant vers l’appelé  Au retour: copie de nouvelles valeurs pour les paramètres de l’appelé vers l’appelant  Marche bien dans beaucoup de cas mais violation dans certains cas de la sémantique du passage
  • 29. Simulation par copie restauration 30  Exemple du problème de violation procédure double_incr ( x , y ) ; x , y : entier ; début x := x + 1 ; y := y + 1 ; fin ; Séquence d’appel : passage par adresse a := 0 ; double_incr ( a , a ) ; Résultat attendu : a = 2 Utilisation d’une copie restauration Résultat obtenu : a = 1
  • 31. Désignation 32  La structuration des noms et références permet de désigner les services distants :  Nom symbolique : une chaîne de caractères désignant la procédure dans un annuaire ou serveur de nom  Référence : une structure de données permettant de réaliser l’appel  Référence : selon l’implantation considérée:  Désignation du protocole permettant l’accès distant (TCP ou UDP)  Désignation de l’hôte où se trouve le serveur (adresse IP)  Désignation du point d’accès de service transport (numéro de port)  Désignation de la procédure  Serveur de nom : une table qui assure la correspondance entre nom symbolique et référence
  • 32. Liaison 33  Moment de liaison : précoce (statique) ou tardive (dynamique)  Statique :  localisation du serveur connue à la compilation  pas d’appel à un serveur de noms (ou appel à la compilation)  Dynamique : localisation au moment de l’exécution, non connue à la compilation  Désignation symbolique des services (non liée à un site d’exécution)  Liaison au premier appel : consultation du serveur de noms au premier appel seulement  Liaison à chaque appel : consultation du serveur de noms à chaque appel
  • 34. Désignation & liaison 35  1, 2 : le serveur s’enregistre auprès de l’annuaire avec nom, @serveur, #port  3, 4, 5 : le client consulte l’annuaire pour trouver @serveur, #port à partir du nom symbolique  L’appel peut alors avoir lieu
  • 36. Contrôle client : RPC en mode synchrone 37  L’exécution du client est suspendue tant que la réponse du serveur n’est pas revenue ou qu’une condition d’exception n’a pas entraîné un traitement spécifique  Avantage : le flot de contrôle est le même que dans l’appel en mode centralisé.  Inconvénient : le client reste inactif.
  • 37. Contrôle client : RPC en mode synchrone 38  Solution au problème de l’inactivité du client : création des activités concurrentes  Création de (au moins) deux activités (« processus léger » ou « threads ») sur le site client:  L’une occupe le site appelant par un travail à faire.  L’autre gère l’appel en mode synchrone en restant bloquée :  Le fonctionnement est exactement celui d’un appel habituel.
  • 38. Contrôle client : RPC en mode asynchrone 39  Le client poursuit son exécution immédiatement après l’émission du message porteur de l’appel  La procédure distante s’exécute en parallèle avec la poursuite du client  Le client doit récupérer les résultats quand il en a besoin
  • 39. Contrôle serveur : exécution séquentielle des appels 40  Les requêtes d’exécution sont traitées l’une après l’autre par le serveur  exclusion mutuelle entre les traitements.  Si la couche transport assure la livraison en séquence et que l’on gère une file d’attente « FIFO : premier arrivé premier servi », on a un traitement ordonné des suites d’appels.
  • 40. Contrôle serveur: exécution parallèle des appels 41  le serveur créé un processus ou une activité (« processus léger » ou « thread ») pour chaque appel  Gestion possible de pool de processus ou d’activités  Les appels sont exécutés en parallèle.  Si les procédures manipulent des données globales persistantes sur le site serveur, le contrôle de concurrence doit être géré.
  • 42. Gestion des données applicatives sans données partagées persistantes 43  L’appel de procédure s’exécute en fonction des paramètres d’entrée en produisant des paramètres résultats  Données locales à la procédure  Pas de modification de données persistantes sur le serveur  Situation très favorable, on n’a pas à gérer:  la tolérance aux pannes  le contrôle de concurrence
  • 43. Gestion des données applicatives partagées persistantes 44  Les exécutions successives manipulent des données persistantes sur le serveur:  Une exécution modifie le contexte sur le serveur  Exemple: un serveur de fichier, de bases de données.  Problème de contrôle de concurrence  Problème des pannes en cours d’exécution
  • 44. Gestion des données protocolaires mode avec ou sans état 45  La terminologie avec ou sans état porte sur l’existence ou non d’un descriptif pour chaque relation client serveur au niveau du serveur.  Notion d’état : un ensemble de données persistantes au niveau du protocole pour chaque relation client serveur :  Permettrait de traiter les requêtes dans l’ordre d’émission.  Permettrait de traiter une requête en fonction des caractéristiques de la relation client serveur (qualité de service).
  • 45. Mode sans état 46  Les appels successifs d’une même procédure s’exécutent sans liens entre eux  Chaque opération du point de vue du protocole s’effectue sans référence au passé  Exemples  NFS "Network File System" de SUN  système de fichier réparti basé sur RPC sans état  HTTP "HyperText Transfer Protocol"  protocole d’exécution de méthodes distantes sans état
  • 46. Mode avec état 47  Les appels successifs s’exécutent en fonction d’un état de la relation client serveur laissé par les appels antérieurs  La gestion de l'ordre des requêtes est indispensable  Exemple :  Opérations d’achat des produits sur Internet (payement électronique)
  • 48. Appel local vs Appel distant 49 En appel local  L’appelant et l’appelé s’exécutent sur la même machine : même exécutant => mêmes performances et modes de pannes.  L’appel et le retour de procédure sont des mécanismes internes considérés comme fiables.  Problème des erreurs abordé => exceptions chez l’appelant. En appel distant  Appelant et appelé peuvent tomber en panne indépendamment  Le message d’appel ou celui de retour peuvent être perdus  Le temps de réponse peut-être très long en raison de surcharges diverses (réseau, site appelé)  La prise en compte des défaillances nécessite de formuler des hypothèses de défaillances, de détecter les défaillances, et enfin de réagir à cette détection.
  • 49. Hypothèses de défaillances 50  Système de communication  Congestion du réseau, messages retardés  Perte de messages  Altération de messages  Serveur  Défaillance avant l’exécution de la procédure  Défaillance pendant l’exécution de la procédure  Défaillance après l’exécution de la procédure  Défaillance définitive ou reprise possible  Client  Défaillance pendant le traitement de la requête
  • 50. Détection de pannes – Délai de garde51  Les mécanismes de détection de pannes reposent sur des délais de garde.  À l'envoi d'un message,  une horloge de garde est armée, avec une valeur estimée de la borne supérieure du délai de réception de la réponse.  Le dépassement du délai de garde déclenche une action de reprise  Les horloges de garde sont placées côté client, à l'envoi du message d'appel, et côté serveur, à l'envoi du message de réponse.  Dans les deux cas, l'action de reprise consiste à renvoyer le message.  Ilest difficile d'estimer les délais de garde : un message d'appel peut être renvoyé alors que l'appel a déjà eu lieu, et la procédure peut ainsi être exécutée plusieurs fois!
  • 51. RPC : sémantique en cas de panne52  Détection de panne = expiration de délai de garde.  On tente de ré-exécuter l’appel. Combien de fois la procédure a-t-elle été exécutée!?  Sémantique : nombre d’exécution de la procédure  dépend des hypothèses de pannes et du mécanisme de reprise  Indéfini (pas d’hypothèses)  Au moins une fois (appel répété, plusieurs exécutions possibles, au moins une réussit)  acceptable si opération idempotente (2 appels successifs ont le même effet que 1 appel)  Au plus une fois (0 ou 1 fois)  on évite les exécutions répétées, mais on ne garantit pas le succès
  • 52. Traitement des défaillances 53 Congestion du réseau ou du serveur  Panne transitoire (ne nécessite pas d’action de reprise)  Détection : expiration du délai de garde coté client ou coté serveur  Reprise (délai de garde du client)  La souche client réémet l’appel (avec le même identificateur) sans intervention de l’application  Le service d’exécution détecte que c’est une réémission  Exécution de l’appel en cours : le nouvel appel du client n’a aucun effet  Retour déjà effectué : réémission du résultat  Reprise (délai de garde du serveur) : réémission du résultat  Sémantique  Si défaillance transitoire : exactement une fois  Si défaillance permanente : détection, exception vers application
  • 53. Traitement des défaillances 54 Panne du serveur après émission de l’appel  3 cas possibles sur l’exécution de l’appel  Traitement : pas fait, partiel, total  Détection : expiration du délai de garde du client  Reprise  Le client réémet l’appel dès que le serveur redémarre  Sémantique : au moins une fois  Le client ne connaît pas l’endroit de la panne  Solution : le serveur mémorise l’identificateur de requête et état avant exécution
  • 54. Traitement des défaillances 55 Panne du client après émission de l’appel  L’appel est correctement traité par le serveur  Le processus exécutant courant est déclaré orphelin  Détection : expiration du délai de garde du serveur, après n réémissions infructueuses  Action du serveur : élimination des orphelins pour libérer ses ressources  Reprise (après redémarrage du client)  L’application cliente réémet l’appel (avec identifiant différent)  Sémantique : au moins une fois  Le serveur ne peut pas détecter qu’il s’agit d’une répétition  Pas d ’incidence si idempotent  Sinon, le client doit informer le serveur pour qu’il revient à l’état cohérent avant exécution de son nouvel appel
  • 56. Avantages des RPC 57  De plus haut niveau  Les détails de communication sont cachés.  Une structure de contrôle bien connue, l’appel de procédure  Support naturel de l’approche client-serveur  Qui s’intègre à l’univers réparti des concepts modernes de génie logiciel: approche objets, approches composants  Modularité, encapsulation, réutilisation par délégation.
  • 57. 67
  • 58. 68
  • 59. Sémantique des pannes 69  La sémantique d’appel caractérise combien de fois la procédure appelée à distance est exécutée suite à un appel en l’absence ou en présence de défaillances.  La sémantique est variable selon la nature du mécanisme mis en œuvre et la nature du serveur:  Serveur avec état: le serveur conserve des informations sur les appels des clients  Serveur sans état: gestion des pannes à la charge du client  Remarque [Idempotence]: une procédure est idempotente si quel que soit le nombre d’exécutions, elle délivre le même résultat  Lecture de fichiers et une opération idempotente  L’incrémentation d’une variable est non idempotente
  • 60. Sémantique exactement une fois 70  Une seule exécution est effectuée et celle-ci réussit toujours.  Réémettre requêtes/réponses  Client:  Arme un délai. Après expiration du délai, le client réémet sa requête jusqu’à réception d’une réponse  Au bout d’un nombre de tentatives, le serveur est considéré indisponible  Serveur:  Garde en mémoire id_req, résultat (pour la perte d’une réponse)  Pour chaque requête id_req, réémettre résultat  Reprise du serveur: la requête ne doit pas être réexécutée: conserver un journal des requêtes traitées.  Difficile à implémenter en pratique!
  • 61. Sémantique au plus une fois 71  Cas d'une fonction non idempotente: on ne doit pas l'exécuter deux fois.  Solution très répandue: Identification des requêtes + exécution effectuée une seule fois.  Exécution effectuée une seule fois:  Si tout va bien le résultat est retourné à l’utilisateur  Si un problème est détecté il est signalé à l’utilisateur. Laisser à la charge du client.  Aucune tentative de reprise n’est effectuée. Elle est laissée entièrement à la charge du client.
  • 62. Sémantique au moins une fois 72  Ne convient pas aux procédures non idempotentes  Client:  Arme un délai. Après expiration du délai, le client réémet sa requête jusqu’à réception d’une réponse  Au bout d’un nombre de tentatives, le serveur est déclaré indisponible.

Notes de l'éditeur

  1. L’effet de l’appel doit être identique dans les deux situations (local et distant) Mais cet objectif ne peut être atteint en toute rigueur en présence de défaillances
  2. Ne pas avoir à programmer des échanges au niveau réseau en mode message Ne pas utiliser pour construire une application répartie des schémas de contrôle trop simples (affectation, fork, join …)
  3. Problèmes de partage des objets (fermeture d’objets, ...).
  4. Réalisation de l’appel de procédure distante par messages asynchrones
  5. Objectif de génération automatique des souches connaissant le profil d’appel de la procédure distante. Un mode de réalisation par interception (wrapping) Une procédure intercepteur (wrapper) intercepte l’appel d’un client vers un serveur et modifie le traitement serveur à sa guise Stub = souche Skeleton: squellette
  6. J’ai remplacé procédure par intercepteur
  7. La souche client collecte les paramètres , les aligne dans le message d’appel (“parameter marshalling”). La souche détermine l’adresse du serveur. La souche client collecte les paramètres , les emballe dans le message d’appel. La souche détermine l’adresse du serveur.
  8. La souche serveur réalise l’appel effectif de la procédure serveur. On a ici réalisé un rendez-vous d'activation. La souche serveur collecte les paramètres retour, les assemble dans un message (“parameter marshalling”).
  9. Définition des types des paramètres, résultats, exceptions Propriétés non-fonctionnelles (qualité de service), non standard)
  10. Avantages: Volume de code ou de données du serveur quelconque ???
  11. Si le serveur se trouve dans le même processus (même domaine de protection) pas de problème (appel local). Si le serveur se trouve dans un autre processus (autre domaine de protection)
  12. Exemple : DCOM RPC par messages + RPC léger (aussi prévu en CORBA).
  13. Si le site client et le site serveur utilisent des formats de de données différents : problème syntaxique  Conversion est nécessaire Exemple : norme de représentation lexicale des données simples BER (‘Basic Encoding Rules’) dans le mode de communication par messages. Exp: ASN1 ‘Abstract Syntax Notation’1 pour le mode message codage/décodage de la syntaxe de transfert (technique de compilation, notion de compilateur de protocole).
  14. Insuffisance des normes de syntaxe abstraite et de syntaxe de transfert en mode message asynchrone : ASN1/BER. Définition de nouveaux langages de syntaxe abstraite adaptés aux appels de procédure distante : IDL ‘Interface Definition Language’ Pour chaque IDL en général redéfinition d’une syntaxe de transfert. N’est pas clair, le passage de ASN1/BER vers IDL ??? Pourquoi ne pas parler directement de IDL
  15. Motivation pour une classe de langages de syntaxes abstraites : IDL Définition d’un langage pivot qui permette de corriger les ambiguïtés et les insuffisances des langages anciens (comme par exemple C). Notion de correspondance entre les types retenus dans l’IDL et les types des différents langages existants ("mappings")
  16. Archivage Entete de la procédure pour permettre de faire certaines vérifications lors de la compilation et de la génération des souches. J’ai supprimé des parties de la figure  voire figure originale
  17. Indispensable de traiter ce problème
  18. Y-a-t il une syntaxe qui implémente la copie restauration ?
  19. Désignation locale de l’objet où se trouve la procédure. une structure de données permettant de réaliser l’invocation.
  20. Dynamique : localisation au moment de l’exécution, non connue à la compilation Désignation symbolique des services (non liée à un site d’exécution) Possibilité d’implémentation ou de sélection retardée
  21. Schémas plus élaborés : attributs (critères de choix)
  22. Condition d’exception: attente bornée Mode centralisé: sur la même machine
  23. Le client doit récupérer les résultats quand il en a besoin (primitive spéciale).
  24. Exclusion mutuelle : est une primitive de synchronisation utilisée en programmation informatique pour éviter que des ressources partagées d'un système ne soient utilisées en même temps. Exemple RPC SUN : traitement séquentiel des requêtes mais utilisation de UDP => requêtes non ordonnées (mais mode synchrone le client attend la fin du traitement). Autres exemples : les RPC ont un mode séquentiel (exemple : CORBA)
  25. Rémanantes= persistantes=durables Exemple : Corba Notion d’adaptateur d’objets.
  26. Exemple : fonction scientifique (EJB session stateless). Données applicatives partagées (variables d’instance, fichiers, bases de données) : problème de persistance. Sans données partagées persistantes
  27. Solution : le couplage d’une gestion transactionnelle avec une approche RPC. Opérations d’écriture de données persistantes, la structure de donnée manipulée par les méthodes d’un objet). Exemple : EJB Session stateful (un seul client),
  28. Autre aspect de la persistance des données sur le serveur En fait une notion identique à celle du descriptif de connexion chez le serveur dans une communication en mode connecté.
  29. Il peut y avoir modification de données globales persistantes sur le serveur mais chaque opération du point de vue du protocole s’effectue sans référence au passé (indépendamment de toutes celles qui ont précédé) Lecture/Écriture du nième article d’un fichier dont toutes les caractéristiques utiles (nom, droit d’accès) sont passées au moment de l’appel. Je pense que tout ça est déjà dit dans les sockets
  30. Changer les exemples !!! Exemple : un système de fichier en RPC : lecture d’article de fichier sur le pointeur courant.
  31. Le message d’appel ou celui de retour peuvent être perdus (sauf si l’on emploie un protocole de transport fiable).
  32. Système de communication Congestion du réseau, messages retardés Perte de messages Altération de messages
  33. Détection : expiration du délai de garde A ou D Panne transitoire (ne nécessite pas d’action de reprise)
  34. Plusieurs moments possibles Avant B, entre C et D, entre fin traitement et D Traitement : pas fait, partiel, total On peut faire mieux avec un service transactionnel Mémorise identificateur de requête et état avant exécution
  35. Panne du client après émission de l’appel L’appel est correctement traité Changement d’état du serveur Le processus exécutant courant est déclaré orphelin Le serveur ne peut pas détecter qu’il s’agit d’une répétition Pas d ’incidence si idempotent On peut faire mieux, si le client a un service de transactions
  36. De plus haut niveau que les communications en mode message. Une structure de contrôle bien connue, l’appel de procédure (mode de communication support naturel de l’approche client-serveur).
  37. Utilisation d’un délai de garde par le site appelant Signalement de l’absence de réponse au client qui décide de la stratégie de reprise. Reprise arrière automatique (si possible) : soit tentative d’exécution sur un autre site soit reprise sur le même site (si relance) Plusieurs exécutions successives de la même procédure pour une seule demande.
  38. Réalisation de travaux inutiles, utilisation de ressources qui ne sont plus accessibles pour des tâches utiles.
  39. Mécanisme de traitement des pertes de message à prévoir dans la conception du RPC :
  40. Notion d’ORB (‘Object request Broker’) temps réel en cours d’étude. Gestion de priorités au niveau réparti, gestion d’échéances intégrant les délais réseaux.
  41. Si l'exécution se termine avant l'échéance le serveur transmet sa réponse qui retrouve ou ne retrouve pas son client
  42. Client: Pas de réémission Serveur : pas d’informations sauvegardées