Serveur - Ecircle

LEILA
MODÈLES DE COMMUNICATION
DANS LES SYSTÈMES RÉPARTIS
BACCOUCHE
1
Quelques modèles
•
•
•
•
Les protocoles de communication
La communication de groupe
Le modèle client/serveur
L’invocation de procédures et de méthodes à
distance
• Le modèle peer-to-peer
LEILA
BACCOUCHE
2
Fonctionnement du modèle
client/serveur
LEILA
BACCOUCHE
• Exemples de serveurs
• Serveur de fichiers (AFS, NFS), Serveur d’impression (lpd)
• Serveur de calcul, Serveur de bases de données, Serveur web
• Serveur de noms (annuaire des services)
3
Conception d’une application
client/serveur
• Une application informatique est représentée selon un modèle
en trois couches
– la couche présentation (interface Homme/Machine):
• logique de l’affichage, partie de l’application qui transmet à la
gestion de l’affichage, les éléments de présentation.
• gestion de l’affichage (exemple Windows, X-windows, etc.),
LEILA
BACCOUCHE
– la couche traitements :
• la logique des traitements : les algorithmes de l’application,
• la gestion des traitements qui manipulent les données de
l’application (ex: procédures SQL).
– la couche données :
• la logique des données constituant les règles régissant les
objets de la base de données,
• la gestion des données (consultation et mise à jour des
enregistrements). Un système de type SGBDR,
habituellement, est responsable de cette tâche.
4
Les niveaux du modèle
client/serveur
• Le terme « niveau» décrit le découpage logique
d’une application entre des clients et des
serveurs.
• Comment répartir cette charge ?
• Les niveaux permettent de préciser les choix
architecturaux de base :
LEILA
BACCOUCHE
– Modèle à 2 niveaux (2 tiers)
– Modèle à 3 niveaux (3 tiers)
– Modèle à N niveaux (N tiers)
5
Le modèle à 2 niveaux
• Le serveur ne fait pas appel à une autre application afin
de fournir le service.
• Il découpe en deux la charge de l’application (charge
répartie entre le client et le serveur).
• 2 archi :la logique applicative s’exécute sur le client
(architecture orientée client) ou sur le serveur
Niveau 2
(architecture orientée serveur)
LEILA
BACCOUCHE
Req. SQL select
Traitement
Envoi de la requête
Réception des données SERVEUR
CLIENT
Niveau 1
6
Le modèle à 2 niveaux (2)
• Intérêt du C/S à 2 niveaux :
– Réduction des transferts réseaux
– Simplification des outils de développement
LEILA
BACCOUCHE
• Limites du 2-Tiers client lourd
– nécessité de monter les données dans le client
pour les modifier
– Nécessité de puissance de traitement sur le
poste client
– évolution difficile
– développement sur le poste de travail
7
Le modèle à 3 niveaux
• le client exécute l’interface graphique utilisateur
(architecture client léger)
• le serveur d’application exécute la logique applicative
(architecture orientée serveur)
• Le serveur de données maintient la base de données.
LEILA
BACCOUCHE
Niveau 2
Req. ftp
Req. http
Req. SQL
Req. web
Envoi de la
requête
Niveau 3
Interrogation de la
source de données
Réception des
résultats
Client
Serveur
Niveau 1 d’application
Serveur de
données
8
Le modèle à 3 niveaux
• Le modèle à 3 niveaux répond aux besoins des
vastes applications client/serveur de l’Internet et
des intranets en particulier avec des
technologies ne laissant aucune trace comme
les applets Java.
LEILA
BACCOUCHE
9
Comparaison des
deux architectures
• Dans l'architecture à deux niveaux, le serveur est
polyvalent, c'est-à-dire qu'il est capable de fournir
directement l'ensemble des ressources demandées par le
client.
• Le modèle à 3 niveaux remplace de nombreuses
requêtes et mises à jour SQL par un petit nombre
d’appels au serveur.
• Les applications au niveau serveur sont délocalisées,
chaque serveur est spécialisé dans une tâche (serveur
Web/serveur de base de données par exemple). Ainsi,
l'architecture à trois niveaux permet:
LEILA
BACCOUCHE
– une plus grande flexibilité/souplesse
– une plus grande sécurité (la sécurité peut être définie pour
chaque service)
– Le client n’accède pas directement à la base de données.
– de meilleures performances (les tâches sont partagées)
10
De 3 niveaux à N niveaux
• Les applications exécutent souvent un ensemble
de composants utilisés lors de diverses
transactions initiées par les clients
• Chaque composant automatise une fonction
relativement limitée.
• Un composant peut appeler d’autres
composants pour implémenter une requête.
• Certains composants peuvent se comporter
comme des passerelles encapsulant des
applications sur des sites centraux.
• La plupart du temps, les 3 niveaux sont donc en
réalité N niveaux.
LEILA
BACCOUCHE
11
Un rappel sur les sockets
• Introduites avec la version 4.3 BSD de Unix
• Les sockets implémentent une interface d’accès au
réseau au dessus de la couche transport.
• Une socket = file d’attente de messages à destination
d’un processus
LEILA
BACCOUCHE
– Rattachée @ IP + port
– Fonctionne par paire : 1 socket client et 1 serveur
• Lors de la création de la socket, le protocole de
communication TCP ou UDP est précisé.
– Socket(domaine, type, protocole)
• Domaine : AF_Unix communications locales, AF_INET
communications utilisant IP, AF_X25, AF_APPLE TALK
• Type : SOCK_STREAM comm. bidirectionnelle sûre utilisant TCP.
• SOCK_DGRAM comm. datagrammes utilisant le protocole UDP.
• SOCK_RAW personnaliser
12
Eléments De Communication
• Protocoles de communication : PPP,IP,
TCP,UDP
Protocoles d’application
Protocoles d’application
: Telnet, ftp, Irc, Smtp
Serveur
Client
LEILA
BACCOUCHE
Sockets
Transport
Réseau
Liaison
Physique
Sockets
Transport :
TCP, UDP, SPX
Réseau : IP,
IPX, Appletalk
Liaison : Ethernet,
FDDI, PPP
Physique :cablage
13
L’API Socket
• Création de la socket : Socket
• Ouverture de dialogue :
– client : connect(...)
– serveur : bind(..), listen(...), accept(...)
• Bind : rattacher la socket à une adresse
• Listen : se mettre à l’écoute de requêtes simultanées sur
une socket (req. mises en file)
LEILA
BACCOUCHE
• Transfert de données :
– mode connecté : read(...), write(...), send(...), recv(...
– mode non connecté : sendto(...), recvfrom(...),
sendmsg(...), recvmsg(...)
• Clôture du dialogue : close(...)
14
Mode connecté
– le client initie une connexion avec le serveur par l’appel de
connect et décide d’y mettre terme en appelant close.
– Une fois la connexion établie, aucun des deux sites n’a besoin
d’inclure des informations d’adressage dans son message
Programme Client
Socket
Demande de connexion
Serveur
LEILA
BACCOUCHE
connect
Émission de requêtes
Réception de résultats
Read, write
Demande de déconnexion
close
Socket, bind
prise en compte de la connexion
Listen, accept
Réception de requêtes
Émission de résultats
Read, write
prise en compte de
la déconnexion
close
15
Mode Connecté
–
–
–
–
–
Adapté aux grands transferts
Problèmes de communications gérés automatiquement,
Primitives simples d’émission et de réception,
Gestion de la connexion coûteuse,
Pas de délimitation des messages dans le tampon.
LEILA
BACCOUCHE
16
Mode Non Connecté
• Mode non connecté (UDP) :
– le client ne transmet qu’une requête et reste bloqué
jusqu’à la réception de la réponse du serveur.
LEILA
BACCOUCHE
Programme Client
Requête
Socket
Serveur
Socket, bind
prise en compte de la requête
Emission d’une requête
sendto
Etat bloqué jusqu’à réception du résultat
Réveil du serveur
Recvfrom,
Réponse
recvfrom
poursuite du traitement
Exécution de la requête
sendto
17
Mode Non Connecté
– Adapté aux petits transferts
– Consomme moins de ressources systèmes,
– Ne garantit pas intégrité, l’ordonnancement, la non
duplication des données.
– Gestion de toutes les erreurs à la main !!
LEILA
BACCOUCHE
18
Client/Serveur en mode connecté
Serveur
socket()
Client
socket()
Création de la socket
bind()
LEILA
BACCOUCHE
listen()
accept()
connect()
write()
établissement de la connexion
envoi requête
read()
bloqué jusqu'à la réception de la requête
read()
bloqué jusqu'à la réception
de la réponse
close()
traitement de la requête
envoi réponse
write()
Fermeture de la socket
close()
19
Client/Serveur en mode non connecté
Client
socket()
Serveur
socket()
Création de la socket
LEILA
BACCOUCHE
bind()
Assignation n°port - @ IP bind()
sendto()
recvfrom()
envoi requête
recvfrom()
bloqué jusqu'à la réception de la réponse
bloqué jusqu'à la réception de la
requête
traitement de la requête
envoi réponse
sendto()
traitement de la réponse
close()
Fermeture de la socket
close()
20
Exemple : Un serveur concurrent
sous Unix
sd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
bind(sd, (struct sockaddr *)&serveur, sizeof(serveur));
listen(sd, 5); // accepter 5 requêtes
while (!fin)
{
nsd = accept(sd, ...); // nouvelle socket
if (fork() == 0)
{
close(sd); // On n’a plus besoin de la socket du
père
// traitement
close(nsd); // le fils ferme sa socket
exit(0); // Mort du fils
}
close(nsd); // le père ferme sa socket }
LEILA
BACCOUCHE
21
Exemple : Un serveur itératif
sous Unix
sd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
...
bind(sd, (struct sockaddr *)&serveur, sizeof(serveur));
listen(sd, 5); // accepter 5 connexions
while (!fin)
{
nsd = accept(sd, ...); // nouvelle socket
// traitement
close(nsd); // Fin de la connexion avec le client
LEILA
BACCOUCHE
}
22
Du modèle client/serveur à
l’appel de procédures à distance
• conception orientée communication:
– définition du protocole d’application (format et syntaxe des
messages) inter-opérant entre le client et le serveur,
– conception des composants serveur et client, en spécifiant
comment ils réagissent aux messages entrants et génèrent
les messages sortants.
LEILA
BACCOUCHE
• opérations send et receive explicites, non-transparence des
programmes.
• conception orientée application :
– subdivision de l’application en plusieurs modules qui
s’exécutent sur différentes machines.
• conserver la sémantique associée à un appel de procédure local
• Dégager le programmeur de la gestion de l’exécution à distance
• L'informatique répartie est construite autour d'appels de
procédures à distance (Remote Procedure Calls, introduit
par Birrel et Nelson 84) pour pallier les inc. du C/S.
23
L’invocation de méthodes et
procédures à distance
• Les RPC ≈ les appels classiques, mais sont exécutés à
distance
– Appel de procédure côté client avec paramètres d’e/s,
procédure côté serveur avec paramètres d’e/s
• L’implémentation de l’appel et les opérations d'e/s sont
invisibles au programmeur.
LEILA
BACCOUCHE
– Elles sont gérées par des procédures d'interfaces : les
talons (souche, stub) : 1 talon client et 1 serveur
• L'information est transportée à travers le réseau.
• RPC protocole de la couche session
• +ieurs services répartis sont bâtis sur RPC : services de
fichiers, web
• RPC en mono-machine : protection des espaces
d’adressages
24
Le RPC en dix étapes
Client
Serveur
Exécution de la procédure
Appel 1
10
Retour
Retour
6
Emballage des
résultats
Emballage des
paramètres
5
Appel
LEILA
BACCOUCHE
Talon client
Déballage des
résultats
2
9
7
Noyau
Talon serveur
Déballage des
paramètres
4
Noyau
8
3
• Encodage des arguments dans un message
réseau
25
L’invocation de méthodes et procédures
à distance : les problèmes
Appel de procédure local
Remote PC
Même espace de travail
Espaces de travail différents :
pour l’appelant et l’appelé mémoires distinctes
machines hétérogènes,
Mêmes types de pannes Pannes du client ou serveur
indépendants
Retour de procédure
Aucune garantie
assuré
immédiat
délai non négligeable
LEILA
BACCOUCHE
Passage de paramètres par adresse n’a pas de sens
Hétérogénéité : codage des arguments
Pannes et sémantique d’exécution
26
L’invocation de méthodes et procédures à
distance : l’envoi des paramètres
• Passage par valeur
• Passage par référence remplacé par copie/restauration :
– la valeur de la var. recopiée dans un buffer transmis à la
procédure. Au retour sa valeur est recopiée à l’adresse de
la variable.
LEILA
BACCOUCHE
• Hétérogénéité
– Ordre de stockage des octets différent entre les machines
little endian (intel) versus big endian (sparc)
– Représentation interne des types (exple des réels :
exposant en C1 ou C2, normalisé
• Codage similaire entre le client et le serveur : format
universel
• Norme de représentation des données
• Envoi données + leur représentation : client inchangé,
conversion côté serveur
27
L’invocation de méthodes et
procédures à distance : les pannes
• Plusieurs types de pannes peuvent survenir :
– Panne du client, du serveur, panne/congestion du réseau,
Serveur
Serveur
Req
Panne
Req
Panne
Serveur
Serveur
Req
Reçoit
Reçoit
Exécute
Panne
LEILA
BACCOUCHE
Répond
Req
Reçoit
Exécute
Panne
• Le client tombe en panne avant ou après l'émission de la
requête :
– Avant : pas de réponse
– Après : réponses du serveur sont orphelines
• Le serveur tombe en panne avant ou après l'exécution :
– La réponse du serveur au client est perdue : réémission
– Le requête n'a pas été exécutée : réexécution
– Comment distinguer entre les pannes ?
28
Pannes du serveur ou du réseau
: Sémantique des RPC (1)
• Sémantique variable selon la nature du mécanisme de
reprise mis en œuvre et la nature du serveur : avec ou
sans état
– Serveur avec état. Le serveur conserve des informations
sur les requêtes des clients.
– Serveur sans état : gestion des pannes à la charge du
client
LEILA
BACCOUCHE
• Quatre solutions possibles: 1, +1, -1, 0 à N
– Au moins une fois :
• Ne convient pas aux actions 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
• Client : Au bout d’un nombre de tentatives, le serveur est
déclaré indisponible
29
Pannes du serveur ou du réseau
: Sémantique des RPC (2)
– Au plus une fois
• Soit l'opération est faite une fois soit pas du tout.
• Client : Pas de réémission
• Serveur : pas d’informations conservées
– Exactement une fois
LEILA
BACCOUCHE
• Réémettre requêtes/réponses
• Difficile a implanter à cause des doublons
• 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
• Client : Au bout d’un nombre de tentatives, le serveur est
déclaré indisponible
• Serveur : garde en mémoire id_req, résultat (pour la perte d’une
réponse)
• Serveur : pour chaque requête recherche 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
30
Pannes du client
• Le client tombe en panne après l’émission d’une
requête. Après reprise, que faire à la réception
d’une réponse ?
– le client élimine les requêtes orphelines.
LEILA
BACCOUCHE
• Nécessaire de distinguer les requêtes orphelines des
autres
31
L’invocation de méthodes et procédures à
distance : mise en place
• Programmation
– Élaboration des programmes client et serveurs :
la procédure et son appel
– Description de l’interface du service RPC à offrir
LEILA
BACCOUCHE
• Compilation
– des prog. et interfaces avec un outil RPC
– Génération des talons client et serveur
• Configuration de la localisation du serveur :
statique ou dynamique
• Lancement
– Du client et du serveur
32
L’invocation de méthodes et procédures à
distance : localisation du serveur
• Localisation statique : adresse du serveur
connue à la génération des talons
• Localisation dynamique : le talon s’adresse à un
serveur de noms lors du premier appel de la
procédure
LEILA
BACCOUCHE
33
L’invocation de méthodes et procédures à
distance : quelques outils
• Sun RPC : plateforme Unix/ Lge C
– XDR (External Data Representation):
• Java RMI : Remote Method Invocation
– RPC orienté objet
LEILA
BACCOUCHE
• Corba : Common Object Request
– toute plateforme et langage
• EJB : Entreprise Java Beans
• DCOM : Distributed Component Object Model
– alternative microsoft pour corba
• DCE-RPC : Distributed Computing Environment
– RPC de OSF
• XML RPC : RPC léger pour XML et HTTP
• SOAP : RPC étendu pour XML et HTTP
34
SUNRPC
LEILA
BACCOUCHE
35
SUNRPC
• Initialement implémenté au-dessus d’UDP
–Sémantique au plus une fois : pas de retransmission
–Nouvelles version supporte TCP
• Norme XDR : external Data representation
–Définit des types de données XDR, Primitives de codage,
décodage
LEILA
BACCOUCHE
• Exemple
XDR
*xdrs;
/* pointeur vers un buffer XDR */
char
buf[BUFSIZE]; /* buffer pour recevoir les données encodées
xdr_mem_create (xdr, buf, BUFSIZE, XDR_ENCODE);
/* buffer créé, chaque appel à une fonction d’encodage va placer le
résultat à la fin du buffer */
i=260;
xdr_int(xdrs, &i); /* encode l’entier i et le place en fin de buffer*/
/* Le programme receveur décodera les données :*/
xdr_mem_create ( ... , XDR_DECODE)
36
SUNRPC : fonctions de conversion XDR
Fonction
xdr_bool
xdr_bytes
xdr_char
xdr_double
xdr_enum
xdr_float
xdr_int
xdr_long
xdr_opaque
xdr_bool
xdr_bytes
xdr_float
xdr_int
xdr_long
xdr_opaque
xdr_pointer
xdr_short
xdr_string
xdr_u_char
xdr_u_int
arguments
xdrs, ptrbool
xdrs, ptrstr, strsize, maxsize
xdrs, ptrchar
xdrs, ptrdouble
xdrs, ptrint
xdrs, ptrfloat
xdrs, ip
xdrs, ptrlong
xdrs, ptrchar, count,
xdrs, ptrbool
xdrs, ptrstr, strsize, maxsize
xdrs, ptrfloat
xdrs, ip
xdrs, ptrlong
xdrs, ptrchar, count,
xdrs, ptrobj
xdrs, ptrshort
xdrs, ptrstr, maxsize
xdrs, ptruchar
xdrs, ptrint
type de donnée converti
booléen
chaîne de caractères
caractère
virgule flot., double précision
type énuméré
virgule flot. simple précision
entier 32 bits
entier 64 bits
données non converties
booléen
chaîne de caractères
virgule flot. simple précision
entier 32 bits
entier 64 bits
données non converties
pointeur
entier 16 bits
chaîne de caractères
entier 8 bits non signé
entier 32 bits non signé
LEILA
BACCOUCHE
37
•
•
SUNRPC : la localisation du
serveur
Chaque machine offrant des programmes RPC dispose d’un service
d’association de port dynamique: le port mapper, processus daemon
qui tourne sur le port 111.
Lorsqu’un serveur RPC démarre, il alloue dynamiquement un
numéro de port local, puis contacte le port mapper de la machine
sur laquelle il s’exécute et s’enregistre.
Chaque serveur enregistre le nom de sa procédure, sa version, son
@IP, son numéro de port avec svc_register.
Le portmapper utilise une table de liaisons.
Le client s’adresse au port 111 et transmet au portmapper le nom de
la procédure (ou du service) et sa version.
Le portmapper consulte sa table de liaisons et retourne le numéro
du port.
LEILA
BACCOUCHE
•
•
•
•
38
Liaison dynamique via le
portmapper
LEILA
BACCOUCHE
Source Jürgen Ehrensberger, EIDV, 9_RPC.pdf
39
SUNRPC : La génération des
talons
• Une bibliothèque : rpclib et un utilitaire de
génération de talons : rpcgen
• Un contrat Q.x (fichier de spécification) est écrit
avec le langage RPCL.
• A la compilation, Rpcgen produit quatre fichiers
source dont les noms sont dérivés du nom de
spécification en entrée. Si le fichier en entrée est
Q.x, les fichiers générés sont:
LEILA
BACCOUCHE
– Q.h : déclarations des constantes et types utilisés
dans le code généré pour le client et le serveur,
– Q_xdr.c : procédures XDR utilisés par le client et le
serveur pour encoder/décoder les arguments,
– Q_clnt.c : procédure « stub » côté client,
– Q svc.c : procédure « stub » côté serveur.
40
SUNRPC : Rpcgen
Procédure du client.c
Compilateur
fich.x
fich_clnt.c
Rpclib
Talon client
LEILA
BACCOUCHE
fich.h
Déclaration de const et types
rpcgen
Programme client
Programme serveur
fich.xdr.c
Procédures XDR
d’encodage/décodage des param
compilateur
Fich_svc.c
Talon serveur
Procédure du serveur.c
41
•
JAVA RMI : Le RPC orienté
objet
Permet l’invocation de méthodes sur des objets
distants sans en connaître la localisation
LEILA
BACCOUCHE
OD.methode
OL.methode(OD)
OD.methode(OOD)
OOD = OD.methode
OD ? Celui là !
Source : Pascal MOLLI, MC U. Henri Poincarré, Nancy1
42
RMI : Présentation
• RMI est une API gratuite intégrée au JDK 1.1 réservée aux
objets java. RMI est une extension distribué du langage Java.
• RMI utilise JRMP pour l’échange des données (basé sur les
sockets)
• RMI peut utiliser IIOP (Internet Inter ORB Protocol) pour
l’intéropérabilité avec CORBA
• Le package java.rmi et ses sous-packages (java.rmi.server,
java.rmi,server et java.rmi.dgc) contiennent la définition de
classes et d'outils permettant l'implantation et l'utilisation d'objets
distants.
• JOE (Java Environment Object) permet l’intéraction d’objets java
et autres (éditeur ≠)
• RMIC compilateur qui génère les talons : stub client et skeleton
serveur
• RMISecurityManager : vérifie les classes chargées
• Distributed Garbage collector
LEILA
BACCOUCHE
43
RMI : Les préliminaires
• Le package java.rmi et ses sous-packages
(java.rmi.server, java.rmi,server et java.rmi.dgc)
contiennent la définition de classes et d'outils
permettant l'implantation et l'utilisation d'objets
distants
• Déclarer les objets distants
• Déclarer les méthodes distantes :
• Passage de paramètres par valeur pour les
types simples
• Passage de paramètres par copie de la
référence s’il s’agit d’un objet distant,
• Pas de limite sur le type des paramètres
LEILA
BACCOUCHE
44
RMI : stub et skeleton
• Pour chaque objet distant, il est nécessaire de
disposer de deux objets : l ’objet stub et l ’objet
skeleton.
– Le stub est le représentant local de l ’objet distant
LEILA
BACCOUCHE
• Il gère ses méthodes exportées
• Lorsqu’une méthode fait une référence à un OD, elle
reçoit une référence au stub
– Le skeleton réceptionne les appels de méthodes
distants du client et les propage à
l ’implémentation de l ’objet distant sur le serveur.
45
Déploiement d’une application RMI
• Définir une interface java pour l’OD
• Créer et compiler une classe implémentant cette
interface
• Créer et compiler l’application serveur (javac)
• Créer un programme client accédant à des OD
du serveur
• Créer avec RMIC le talon et le skeleton
• Démarrer RmiRegister et enregistrer le serveur
LEILA
BACCOUCHE
– Naming.bind(« apllication », OD)
• Lancer l’application serveur : java serveur
• Compiler et lancer le programme client
46
RMI : Déploiement
• Rmiregistry : processus chargé de maintenir la table de
liaison ( nommage dynamique)
• Les clients interrogent le rmiRegistry qui est à l’écoute
sur un port connu : le port 1099 par défaut.
• Les objets distants enregistrés sont repérés par une
URL (//machine:port/nomobjet) ex :
//serv.unice.fr:2585/compte
LEILA
BACCOUCHE
47
Modèles d’exécution
• Modèles de communication
– Les protocoles de communication
– La communication de groupe (diffusion)
• Modèles d’exécution orientés communication
LEILA
BACCOUCHE
– Le modèle client/serveur (traditionnel)
• Modèles d’exécution orientés application
– Le modèle client/serveur (procédural) : appel de
procédures à distance
– Le modèle client/serveur (objet) : l’invocation de méthodes
à distance
– Le modèle client/serveur (données) : requêtes SQL,
ODBC, ODMG
– Le modèle client/serveur (composants) : composants,
COM/DCOM
– Le modèle client/serveur (services)
48
Modèles de communication
• Modèles d’exécution orientés communication
– Le modèle client/serveur (traditionnel)
• Modèles d’exécution orientés application
LEILA
BACCOUCHE
– Le modèle client/serveur (procédural) : appel de
procédures à distance
– Le modèle client/serveur (objet) : l’invocation de méthodes
à distance
– Le modèle client/serveur (données) : requêtes SQL,
ODBC, ODMG
– Le modèle client/serveur (composants) : composants,
COM/DCOM
– Le modèle client/serveur (services)
49