Architecture

Client/Serveur
Plan


Principe du Client/Serveur
●
Architecture Pair à Pair

Communication Client/Serveur

Exemple de protocole Client/Serveur

Client/Serveur avec RMI

TP.
Principe du Client/Serveur


Un client :
 Les caractéristiques d’un client sont les suivantes :
 il est d’abord actif (ou maître),
 il envoie des requêtes au serveur,
 il attend et reçoit les réponses du serveur.

Un serveur :
 Un serveur est initialement passif,
 il attend, il est à l’écoute, prêt à répondre aux requêtes envoyées
par des clients.
 Dés qu’une requête lui parvient, il la traite et envoie une réponse.
 Le rôle d'un serveur est de centraliser l'information
Principe du Client/Serveur


Le dialogue :
 Le client et le serveur doivent bien sûr utiliser le même
protocole de communication.
 Un serveur est généralement capable de servir
plusieurs clients simultanément.
 Une fois une requête cliente traitée, le serveur peut en
traiter une autre.
 Il existe des serveurs multi-clients comme les serveurs
Web/http qui sont capables de traiter plusieurs
requêtes clientes en même temps.

Le serveur est l’esclave et le client est le maitre.
Principe du Client/Serveur


Le client et le serveur doivent
utiliser le même protocole de
communication

Le client et le serveur sont le
plus souvent liés par la même
couche spécialisée de
communication

Le client et le serveur sont le
plus souvent liés par la même
couche spécialisée de
communication
Principe du Client/Serveur


Une architecture client/serveur est une
architecture 2-tiers :
 1 pour le client, 1 pour le serveur

Tier = couche (logiciel ou applicatif)


Pour communiquer un client et un serveur
utilise un "middleware"
Architecture Pair à Pair


Un autre type d’architecture est le pair à pair (peer to peer en
anglais ou P2P), dans lequel chaque nœud est à la fois client et
serveur.

Les systèmes pair-à-pair permettent à plusieurs ordinateurs de
communiquer via un réseau,
 de partager simplement des fichiers le plus souvent, mais
également des flux multimédia ou encore un service
(comme la téléphonie avec Skype par exemple), … sur
internet.

L'utilisation d'un système pair-à-pair nécessite pour chaque
noeud l'utilisation d'un logiciel particulier.
 Ce logiciel, qui remplit alors à la fois les fonctions de client
et de serveur, est parfois appelé servent (de la contraction
de « serveur » et de « client »)
Architecture Pair à Pair


Une des applications la plus
connue est le partage de fichiers
par le biais de logiciel à la fois
client et serveur comme
 eDonkey, eMule, FastTrack
(utilisé par KaZaA) ou
BitTorrent...

Les serveurs pair-à-pair
fonctionnent dans la quasi-totalité
des cas en mode synchrone :
 le transfert d'information est limité
aux éléments connectés
Architecture Pair à Pair


Ils peuvent utiliser le protocole TCP (Transmission Control
Protocol ou protocole de contrôle de transmissions)
 comme couche de transport des données (il fonctionne
en duplex, la réception des données est donc
confirmée et leur intégrité est assurée).

En revanche, certaines utilisations comme le continu
(streaming) nécessitent l'emploi d'un protocole plus léger
et plus rapide, comme UDP (User Datagram Protocol ou
protocole de datagramme utilisateur),
 bien que moins fiable, l’UDP est aussi le protocole le
plus utilisé pour transmettre des messages entre
serveurs dans les systèmes en partie centralisés.
Communication
client/serveur

Le mode client/serveur n’est pas le modèle
de communication parfait.

Ce mode présente plusieurs avantages et des
inconvénients :

Avantages :
 Toutes les données sont centralisées sur un seul
serveur, on a donc « un contrôle de sécurité simplifié »
 Les technologies supportant l’architecture
client/serveur sont plus matures que les autres (et plus
anciennes).
Communication
client/serveur

Avantages :
 Toutes les données sont centralisées sur un seul serveur, on
a donc « un contrôle de sécurité simplifié »
 Les technologies supportant l’architecture client/serveur
sont plus matures que les autres (et plus anciennes).
 L’administration se porte au niveau serveur. Toute la
complexité/puissance peut être déportée sur le(s)
serveur(s), les utilisateurs utilisant simplement un client
léger.
 Les serveurs étant centralisés, cette architecture est
particulièrement adaptée et véloce pour
 retrouver et comparer de vastes quantités d’information
(moteur de recherche sur le web).
Communication
client/serveur

Inconvénients
 Si trop de client veulent communiquer sur
le serveur en même temps,

ce dernier risque de ne pas supporter la
charge

alors que les réseaux pair à pair
fonctionnent mieux en ajoutant de
nouveaux participants.
Communication
client/serveur

Inconvénients
 Si le serveur n’est plus disponible, plus aucun des
clients ne fonctionne

le réseau pair à pair continue à fonctionner,
même si plusieurs participants quittent le
réseau.
 Les coûts de mise en place et de maintenance
sont élevés.
 En aucun cas les clients ne peuvent communiquer
entre eux, entraînant

une asymétrie de l’information au profit des
serveurs.
Exemple de Protocole
Client/Serveur

HTTP:
 La consultation des pages sur un site web a un
fonctionnement basé sur une architecture client/serveur.

Un internaute connecté au réseau via son ordinateur et
un navigateur web est le client, le serveur est constitué
par le ou les ordinateurs contenant les applications qui
délivrent les pages demandées.

Dans ce cas, c’est le protocole de communication HTTP
(HyperText Transfer Protocol) qui est utilisé.
 Les navigateurs sont les clients (Firefox, Internet Explorer,
…). Ces clients se connectent à des serveurs http tels
qu’Apache http Server ou IIS (Internet Information Services).
Exemple de Protocole
Client/Serveur

HTTP
 Dans le protocole http, une méthode est
une commande spécifiant un type de
requête, c’est-à-dire qu’elle demande au
serveur d’effectuer une action.
 En général, l’action concerne une
ressource identifiée par l’URL qui suit le
nom de la méthode.
Exemple de Protocole
Client/Serveur

HTTP
 Les méthodes les plus utilisées sont GET et POST.

GET : c’est la méthode la plus courante pour
demander une ressource. Une requête GET est sans
effet sur la ressource.

POST : cette méthode doit être utilisée pour ajouter
une nouvelle ressource, comme un message sur un
forum, un article dans un site ou encore un login et
un mot de passe.

Les autres méthodes sont : HEAD, OPTIONS,
CONNECT, TRACE, PUT, DELETE.
Exemple de Protocole
Client/Serveur

FTP
 Le protocole de transfert de fichiers, ou FTP (File
Transfer Protocol), est un protocole de
communication destiné à l’échange informatique
de fichiers sur un réseau TCP/IP.
 Il permet, depuis un ordinateur, de copier des
fichiers vers un autre ordinateur du réseau,
d’alimenter un site web, ou encore de supprimer
ou de modifier des fichiers sur cet ordinateur.
 FTP obéit à un modèle client/serveur, c’est-à-dire
qu’une des deux parties, le client, envoie des
requêtes et le serveur répond.
Exemple de Protocole
Client/Serveur

FTP
 En pratique, le serveur est un ordinateur sur
lequel fonctionne un logiciel lui-même appelé
serveur FTP. Pour accéder à un serveur FTP, on
utilise un logiciel client FTP (possédant une
interface graphique comme FileZilla par exemple
ou en ligne de commande).
 Deux ports sont standardisés pour les connexions
FTP : le port 21 pour les commandes et le port 20
pour les données.
Client/Serveur avec RMI


RMI signifie Remote Method Invocation.

Il s’agit d’un mécanisme qui permet à un
objet résidant dans un système (JVM)
d’invoquer un objet exécuté sur une autre
JVM.

RMI est utilisé pour créer des applications
distribuées,

il fournit une communication à distance
entre les programmes Java.

Il est fourni dans le package java.rmi
Client/Serveur avec RMI :
Architecture

Dans une application RMI, nous avons deux
programmes :

un programme serveur et

un programme client.

À l’intérieur du serveur, un objet distant est
créé et la référence de cet objet est mise à la
disposition du client (à l’aide du registre).

Le client demande les objets distants sur le
serveur et tente d’appeler ses méthodes.
Client/Serveur avec RMI :
Architecture

Stub : Un stub est une représentation
(proxy) de l’objet distant chez le client.

Il réside dans le système client; il agit
comme une passerelle pour le
programme client.

Skeleton : C’est l’objet qui réside du côté
serveur.

stub communique avec Skeleton pour

transmettre la demande à l’objet distant .


RRL (Remote Reference Layer) : C’est la
couche qui gère les références faites par le
client à l’objet distant.

Couche de transport : Cette couche connecte
le client et le serveur. Il gère la connexion
existante et établit également de nouvelles
connexions.
Client/Serveur avec RMI :
Fonctionnement

Lorsque le client fait un appel à l’objet distant,

il est reçu par le stub qui transmet finalement cette
demande au RRL.

Lorsque le RRL côté client reçoit la demande,

il invoque une méthode appelée invoke() de l’objet
remoteRef. Il transmet la demande au RRL côté
serveur.

Le RRL côté serveur transmet la demande au
Skeleton (proxy sur le serveur) qui appelle
finalement l’objet requis sur le serveur.

Le résultat est transmis au client.
 Client/Serveur avec RMI :
Registre RMI

Le registre RMI est un espace de noms sur
lequel tous les objets serveur sont placés.

Chaque fois que le serveur crée un objet, il
enregistre cet objet avec RMIregistry (en
utilisant les méthodes bind() ou reBind()).

Ceux-ci sont enregistrés en utilisant un
nom unique appelé ‘bind name’.

Pour appeler un objet distant, le client a
besoin d’une référence de cet objet.

À ce moment, le client récupère l’objet à
partir du Registre à l’aide de son nom
‘bind name’ (à l’aide de la méthode
lookup()).
Client/Serveur avec RMI :
Exemple d’une application JAVA RMI


Pour écrire une application Java RMI, vous devez suivre les étapes ci-
dessous:

Étape 1: Définir l’interface de l’objet distant

Étape 2: Développer la classe qui implémente l’interface de l’objet
distant

Étape 3: Développer le programme serveur

Étape 4: Développer le programme client

Étape 5: Compiler l’application

Étape 6: Exécutez l’application
Client/Serveur avec RMI :
Etape 1 : Définir l’interface de l’objet
distant

L’interface de l’objet distant fournit la description de toutes les méthodes d’un
objet distant particulier.

Le client communique avec cette interface distante.

Pour créer l’interface de l’objet distant :

Créez une interface qui hérite de l’interface prédéfinie Remote.

Déclarez toutes les méthodes métier pouvant être invoquées par le client
dans cette interface.

Puisqu’il existe un risque de problèmes de réseau pendant les appels distants,
une exception nommée RemoteException peut se produire.
Client/Serveur avec RMI :
Etape 2 : Développer la classe qui
implémente l’interface de l’objet
distant


Pour créer la classe qui implémente l’interface de l’objet distant:

Implémentez l’interface créée à l’étape 1.

Fournit l’implémentation de toutes les méthodes abstraites de l’interface
distante.
Client/Serveur avec RMI :
Etape 3 : Développer le programme
Serveur


Le programme Serveur doit hériter la classe qui implémente l’interface de l’objet
distant. Ici, nous devons créer un objet distant et le lier à RMIregistry

Pour développer le programme Serveur:

Créez un objet distant en instanciant la classe qui implémente l’interface de
l’objet distant.

Exportez l’objet distant à l’aide de la méthode exportObject() de la classe
nommée UnicastRemoteObject qui appartient au package java.rmi.server.

Récupérez le registre RMI à l’aide de la méthode getRegistry() de la classe
LocateRegistry qui appartient au package java.rmi.registry.

Liez l’objet distant créé au registre à l’aide de la méthode bind() de la classe
nommée Registry. À cette méthode, passez une chaîne représentant le nom
associé à cet objet(bind name) et l’objet exporté, en tant que paramètres.
Client/Serveur avec RMI :
Etape 3 : Développer le programme
Serveur
Client/Serveur avec RMI :
Etape 4 : Développer le programme
Client


Le programme client, récupère l’objet distant et appelle la méthode requise à
l’aide de cet objet.

Pour développer un programme client:

Récupérez le registre RMI à l’aide de la méthode getRegistry() de la classe
LocateRegistry qui appartient au package java.rmi.registry.

Récupérez l’objet dans le registre en utilisant la méthode lookup() de la classe
Registry qui appartient au package java.rmi.registry. Pour cette méthode, vous
devez passer une chaîne représentant le nom associé à cet objet(bind name)
en tant que paramètre. Cela vous rendra l’objet distant.

lookup() renvoie un objet de type Remote, le transtypage vers le type Hello.

Enfin, appelez la méthode requise en utilisant l’objet distant obtenu.

Client/Serveur avec RMI :
Etape 4 : Développer le programme
Client
Client/Serveur avec RMI :
Etape 5 : Compiler l’application
Etape 6 : Exécuter l’application


Compiler & Exécuter l’application
TP :


En Java, appuyez-vous sur RMI pour
implémenter une calculatrice.