LES APPELS DE PROCÉDURE

DISTANTS
[email protected]
2 Middleware
 Motivations
3

¨ L’interface fournie par les systèmes d’exploitation et

de communication est encore trop complexe pour
être utilisée directement par les applications:
¤ Hétérogénéité (matérielle et logicielle)
¤ Complexité des mécanismes (bas niveau)
¤ Nécessité de gérer la répartition

¨ Solution
¤ Introduire une couche logicielle intermédiaire (répartie)
entre les niveaux bas (systèmes et communication) et le
niveau haut (applications) : c’est l’intergiciel ou
Middleware
 Middleware
5

¨ Un middleware (ou intergiciel) permet le dialogue entre

les différentes entités d'une application répartie
¤ Représente l’élément le plus important de tout système réparti

Site 1 Site 2
 Middleware - Fonctions
6

¨ Masquer l’hétérogénéité (machines, systèmes,

protocoles de communication)
¨ Fournir une API (Application Programming Interface)
de haut niveau
¤ Permet de masquer la complexité des échanges
¤ Facilite le développement d'une application répartie

¨ Rendre la répartition aussi invisible (transparente)

que possible
¨ Fournir des services répartis d’usage courant
 Services du middleware
7

¨ Communication
¤ permet la communication entre machines mettant en
œuvre des formats différents de données
¤ prise en charge par la FAP (Format And Protocol)

¤ FAP : pilote les échanges à travers le réseau :

n synchronisation des échanges selon un protocole de
communication
n mise en forme des données échangées selon un format connu
de part et d'autre
 Middleware
8

¨ Nommage
¤ permet d'identifier la machine serveur sur laquelle est
localisé le service demandé afin d'en déduire le chemin
d'accès.
¤ fait, souvent, appel aux services d'un annuaire.

¨ Sécurité
¤ permet de garantir la confidentialité et la sécurité des
données à l'aide de mécanismes d'authentification et
de cryptage des informations
 Types de middleware
9

¨ Middleware RPC (Remote Proceedure Call)

¤ RPC de SUN
¨ Middlewares orientés objets distribués
¤ Java RMI, Corba
¨ Middlewares orientés composants distribués
¤ EJB, Corba, DCOM
¨ Middlewares orientés messages
¤ Kafka, MQTT, RabbitMQ
¨ Middlewares orientés sevices
¤ Web Services (XML-RPC, SOAP)
¨ Middlewares orientés SGBD
¤ ODBC (Open DataBase Connectivity), JDBC de Sun
¨ Middlewares transactionnels
¤ JTS de Sun, MTS de Microsoft
 Rappel du schéma client-serveur
10

¨ Appel synchrone Requête-Réponse

¨ Mise en œuvre
¤ Bas niveau : utilisation directe du transport : sockets (construit sur
TCP ou UDP)
n Exemple : utilisation des sockets en C
¤ Haut niveau : intégration dans un langage de programmation : RPC
(construit sur sockets)
n Exemple : RPC en C
 RPC
11

¨ 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
 Mise en œuvre
14

¨ Par messages
¨ Par migration
¨ Par mémoire partagée
¨ Par appel léger (LRPC)
 Réalisation par messages
18

¨ 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.
 Souches (Stubs)
19

¨ 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 distant
 Souches (Stubs)
20

¨ 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.
 Etapes de RPC par messages
22

¨ É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

¨ É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
23

¨ É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.
¨ É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.
24
Diagramme de RPC par messages

Talon Talon
(stub) (stub)
client serveur

Les talons (ou souches) client et serveur sont créés (générés

automatiquement) à partir d’une description d’interface
 Description d’interface
25

¨ 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
30 Transmission des arguments
 Transmission par valeur
31

¨ Le seul mode de transmission des données dans les

messages en réseau
¨ Si le client et le serveur utilisent des formats 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 et une
convention d’alignement (emballage/déballage) des
données communes au client et au serveur
 Transmission par valeur
dans l’appel de procédure distante
32

¨ 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 ?
33

¨ Ê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
34

Source code client Définition de l’interface Source code

en IDL serveur

Compilateur IDL

Souche client Entête Souche serveur

Compilateur Compilateur Compilateur Compilateur

(C, java, ..) (C, java, ..) (C, java,..) (C, java,..)

Binaire Binaire souche Binaire souche Binaire

client client serveur serveur
 Exemples d’IDL
et de format de présentation en RPC
35

¨ 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 (Simple Object
Access Protocol)
 Autres modes de transmission :
passage par adresse
36

¨ 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
n 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
37

¨ 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
38

¨ Exemple du problème de violation Séquence d’appel : passage par adresse

procédure double_incr ( x , y ) ; a := 0 ;
x , y : entier ; double_incr ( a , a ) ;
début Résultat attendu : a = 2
x := x + 1 ;
y := y + 1 ; Utilisation d’une copie restauration
fin ; Résultat obtenu : a = 1
39 Désignation et liaison
 Désignation
40

¨ 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
41

¨ Moment de liaison : précoce (statique) ou tardive

(dynamique)
¤ Statique :
n localisation du serveur connue à la compilation
n pas d’appel à un serveur de noms (ou appel à la compilation)
¤ Dynamique : localisation au moment de l’exécution, non
connue à la compilation
n Désignation symbolique des services (non liée à un site d’exécution)
n Liaison au premier appel : consultation du serveur de noms au premier
appel seulement
n Liaison à chaque appel : consultation du serveur de noms à chaque
appel
 Désignation & liaison
42
 Désignation & liaison
43

¨ 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
44 Gestion du contrôle
 Contrôle client : RPC en mode synchrone
45

¨ 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
46

¨ 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 :
n Le fonctionnement est exactement celui d’un appel habituel.
 Contrôle client : RPC en mode asynchrone
47

¨ 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
48

¨ 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
49

¨ 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é.
50 Gestion des données
 Gestion des données applicatives
sans données partagées persistantes
51

¨ 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
52

¨ Les exécutions successives manipulent des données

persistantes sur le serveur:
¤ Une exécution modifie le contexte sur le serveur
n 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
53

¨ 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
54

¨ 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
n système de fichier réparti basé sur RPC sans état
¤ HTTP "HyperText Transfer Protocol"
n protocole d’exécution de méthodes distantes sans état
 Mode avec état
55

¨ 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)
56 Tolérance aux pannes
 Appel local vs Appel distant
57

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
58

¨ 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 garde
59

¨ 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 panne
60

¨ 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
n Indéfini (pas d’hypothèses)
n Au moins une fois (appel répété, plusieurs exécutions possibles, au
moins une réussit)
n acceptable si opération idempotente (2 appels successifs ont le même
effet que 1 appel)
n Au plus une fois (0 ou 1 fois)
n on évite les exécutions répétées, mais on ne garantit pas le succès
n Exactement une fois (c’est l’idéal, difficile à atteindre)
 Traitement des défaillances
61

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
n Exécution de l’appel en cours : le nouvel appel du client n’a aucun effet
n 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
62

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
n 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
63

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)
n Sémantique : au moins une fois
n Le serveur ne peut pas détecter qu’il s’agit d’une répétition
n Pas d ’incidence si idempotent
n Sinon, le client doit informer le serveur pour qu’il revient à l’état cohérent
avant exécution de son nouvel appel
64 Conclusion
 Avantages des RPC
65

¨ 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.