Introduction Client/seveur

CSAOD
Conception et Sécurisation
d'Applications à Objets Distribués
Clémentine Nebut – Franck Fleurey – Yves Le Traon
{cnebut
cnebut,, ffleurey , yletraon
yletraon}@
}@irisa
irisa.. fr
Objectifs
Ø Introduction aux techniques de
déploiement de systèmes logiciels
l % au modèle UML « idéal »
Ø Mise en pratique
CSAOD Introduction aux AOD 2
Plan
Ø Introduction
Ø Architectures classiques des AOD
l Architecture client/serveur
client/serveur
l Architecture N-
N-tiers
l Architecture 3-
3-tiers
Ø Les principaux volets d’une AOD
l Gestion de la distribution
l Persistance
l Interface utilisateur
l Sécurisation
Ø Conclusion et plan du cours
1
Introduction
Ø Applications distribuées (ou réparties)
réparties )
l Définition : une application distribuée est :
• un ensemble de programmes,
• distribués sur un réseau de communication,
• qui collaborent pour assurer un service.
l Exemples :
• Une grappe de calculateurs
• Une application de commerce en ligne
• Un calendrier partagé
• ...
Introduction
Ø Pourquoi des applications distribuées ?
l Besoin intrinsèque de l'application
• Les utilisateurs sont répartis(ex
répartis (ex : site web)
• Les données sont réparties (ex : stations météos
météos))
• Partage de données
données//informations (ex :P2P – Kazaa
pour échange des fichiers
fichiers))
l Mais aussi
• Besoin de performances (ex : grappe de calcul
calcul))
• Besoin de « disponibilité » (ex : redondance
redondance))
l Et bien sûr
• Toutes les combinaisons possibles
Architectures classiques des

applications distribuées
Ø Deux grands types d'architectures
l Couplage fort
• Ex : Architecture « peer
peer--to
to--peer »
(tous les processus ont le même rôle)
rôle )
• Grappes de calculateurs (serveur d’exec.
d’exec. Linux de
l’Ifsic))
l’Ifsic
l Couplage faible
• Architecture client/serveur
client/serveur
• Architecture N
N--tiers
• Architecture 3-
3-tiers
2
Couplage fort
Ø Inter-dépendance entre les composants de
Inter-
l’application
P1
Px Processus x Il existe au moins un cycle dans le

P2 P3 Utilise les graphe de dépendances entre les
services de... composants de l’application
P4
Ø Ce type d’architecture pose problème tant pour

le développement que pour la maintenance.
A éviter tant que possible
Couplage faible
Ø Pas d’inter
d’inter--dépendance entre les composants
de l’application
P1
Px Processus x Pas de cycle dans le graphe de

P2 P3 Utilise les dépendances entre les composants
services de... de l’application
P4
Ø Permet de maîtriser la complexité de l’AOD :

l Pour le développement
l Pour le test
l Pour la maintenance
Architecture Client/Serveur
Réponse
Client
Requête
Requête Serveur
Client Réponse
Ø Deux types de noeuds

l Un serveur
l Des clients
3
Architecture client-
client- serveur
Ø Un client fait une requête
Ø Et reçoit une réponse du serveur
Ø Notion de session
l ensemble des requêtes et réponses pour un
même client
l nécessite l’identification du client
l ex: session yahoo
yahoo,, session telnet
telnet,, session
ftp…
ftp …
Ø Exemples :
l Client FTP/Serveur FTP
l Terminal X/Serveur d’exécution
l Navigateur Web
Web/Serveur
/Serveur de noms
l Navigateur Web
Web/Serveur
/Serveur Web
l …
Ø La majorité des AOD sont construites

autour du modèle client serveur
Ø Points forts
l Couplage faible (le serveur n’a pas besoin des clients)
• La maintenance et l’administration du serveur sont simplifiées
• Souplesse : il est possible d’ajouter/suprimer
d’ajouter/suprimer dynamiquement
des clients sans perturber le fonctionnement de l’application
l Les ressources sont centralisées sur le serveur
• Sécurisation simple des données : 1 seul point d’entrée
• Pas de problème d’integrité
d’ integrité/cohérence
/cohérence des données
Ø Points faibles
l Un maillon faible : le serveur
l Coût élevé : le serveur doit être très performant pour
honorer tous les clients
4
Ø Les AOD construites sont de plus en plus complexes :
• Application de commerce en ligne
• Radio/télévision numérique interactive
• Moteur de recherche…
Ø Dans le modèle client/serveur toute la complexité est
concentrée dans le serveur
• Problème de performance/disponibilité
l Répartition de charge ( load balancing
balancing))
• Problème pour maîtriser la complexité
l Architectures multicouches (N-
(N- Tiers)
Répartition de charge
(load balancing )
Ø Un serveur traite simultanément les requêtes de
plusieurs clients
Ø Les requêtes de deux clients sont indépendantes
Ø L’idée du « load balancing » est de paralléliser sur

plusieurs serveurs identiques s’exécutant sur des
machines différentes le traitement des requêtes
concurrentes
Les requêtes des clients passent par un répartisseur de
charge qui les répartit sur N serveursidentiques.
serveurs identiques.
« ferme de serveurs »
Réponse Serveur 1
Client
Requête
Répartisseur
Requête de Serveur 2
charge …
Client Réponse
… Serveur N
5
Le répartisseur de charge
Ø Rôle principal
l Diriger les requêtes des clients en fonction de la charge de
chacun des serveurs
Ø Rôle annexe
l Gérer les sessions des clients (2 solutions)
l Toutes les requêtes d’un client sont dirigées vers un seul serve ur
l Les données de session sont transmises avec la requête
l Ex: gestion des données concernant un client
l Gérer les défaillances :
l Ne plus diriger de requêtes sur un serveur « crashé »
l Assurer le passage à l’échelle (scalabilité
(scalabilité))
l Permettre l’ajout et le retrait de serveurs sans interruption de service
Ø Points forts
l Transparent pour les clients
l Scalable : le nombre de serveurs peut être adapté à la
demande
l Tolérant aux défaillances : la défaillance d’un serveur
n’interrompt pas le service
l Plus besoin de machines très chères : il suffit d’en mettre
plus
Ø Point faible
l Les données ne sont plus centralisées mais dupliquées
l Le répartiteur de charge devient le « maillon faible »
Répartition de charge : Exemple

Le site web de yahoo est hébergé simultanément
sur plusieurs serveurs web d’adresse différentes
$ host www.yahoo.com
www.yahoo.com is an alias for www.yahoo.akadns
www.yahoo.akadns .net.
www.yahoo. akadns
akadns.net
.net has address 216.109.118.70
www.yahoo. akadns
akadns.net
www.yahoo. akadns
akadns.net
www.yahoo. akadns
akadns.net
www.yahoo. akadns
akadns.net
www.yahoo. akadns
akadns.net
www.yahoo. akadns
akadns.net
www.yahoo. akadns
akadns.net
Le serveur de noms (DNS) joue le rôle de répartisseur

de charge en traduisant « www
www..yahoo
yahoo..com » par l’adresse
de chacun des serveur web à tour de rôle
6
Maîtriser la complexité :
les architectures multicouches
(N-- tiers)
(N
Ø L’application devient complexe :
l Difficile à développer
l Difficile à tester
l Difficile à maintenir
l Difficile à faire évoluer
Ø Solution : les architectures multicouches

l Inspiré par le développement en couches des protocoles
réseaux et des architectures à base de composants
Les architectures multicouches

Ø Principe
l Découper l’application en un ensemble de
composants (ou couches) fonctionnels
distincts et faiblement couplés.
• Chaque composant est ainsi plus simple et
l’application distribuée reste faiblement couplée
l Les composants communiquent entre eux sur
le modèle client/serveur
• Les composants de l’application peuvent être
facilement répartis sur plusieurs machines

Ø Chaque couche d’une application multicouches est
cliente de ses couches inférieures et serveur pour les
couches supérieures.
Couche 1 (Client)
Sens des
« Serveur »
requêtes
Couche 2
Couche 3 Faiblement couplé :

pas de cycles
Couche 4
7
Ø La plupart des applications développées se ressemblent
et se composent :
l De données
l De traitements (sur ces données)
l De présentation (des données et des résultats des traitements)
On distingue
généralement 3
grandes couches
dans une application
Les architectures à 3 couches

(3--tiers)
(3
Ø Le cœur de l’application ( modèle métier)
métier) :
l modèle objet et traitements propre au domaine de
l’application (Analyse et conception OO habituelle).
Ø Les données persistantes (couche
(couche d’accès au
données)) :
données
l Couche basse faisant le lien entre le modèle métier et
stockage physique des données (système de fichier,
SGBD…)
Ø L’interface utilisateur (couche
(couche de présentation)
présentation)
l Interface permettant a l’utilisateur d’agir sur le modèle
métier (interface graphique, interface web
web…)…)

principales: Exemples de technos
Présentation Logique métier Sauvegarde
3 ans 10 ans 20 ans et +
ØClients ØServeurs applicatifs ØSources de donnés
l Navigateurs web l BDR/BDO
ØPlateformes OO
lApplets l JAVA l Annuaires (LDAP)
lClients Corba l .NET l …
l…
l …
Database
Serveur Web
XML
8
Ø Points forts
l Découplage logique applicative
applicative/interface
/interface
• Ce ne sont généralement pas les même équipes de
développement.
• Possibilité de changer ou d’avoir plusieurs UI sans toucher à
l’application elle-
elle- même.
l Découplage données/logique applicative
• Possibilité d’utiliser des données existantes sans
complexifier le modèle métier.
• Possibilité de changer le mode de stockage des données
sans modifier la logique métier.
l Favorise la réutilisation puisque toute la logique
propre à l’application est concentrée dans le modèle
métier

Ø Problèmes génériques
l Comment échanger des objets entre différentes machines :

gestion de la distribution
l Comment stocker des objets :

la persistance
l Comment présenter des données :

interface utilisateur
l Comment sécuriser les données et les échanges :

cryptage et authentification
Gestion de la distribution
Ø Communication entre les couches basses
l Appel de méthode à distance (RPC)
• Ex : RMI, CORBA, .NET Remoting , Service Web

l Communication par messages asynchrones
• Ex : JMS (Java Message System)
Ø Communication avec le client
l Appel de méthode à distance (RPC)
• Ex : Applet JAVA via RMI, Service Web via Soap

l Par l’intermédiaire d’un serveur web
• Utilisent toujours http
• Ex : IIS (Internet Information Services - MS.net), Apache (PHP),
Tomcat (Java), …
9
Appel de méthodes distantes
Ø Dans le paradigme objet, les communications
sont déjà sur le modèle client serveur :
• Requête : Appel de méthode
• Réponse : Valeur de retour
Objet client Objet serveur

MaMethode(mes,
MaMethode(mes, paramètres)
Requête
UnObjet
Réponse

Ø Communication entre les différentes couches d’une AOD :
Appel de méthode sur des objets distants.
Couche cliente Couche serveur

Objet client Objet serveur
MaMethode(mes,
MaMethode(mes, paramètres) Requête
Réseau
UnObjet
Réponse

Ø Avantages :
l Les communications entre couches restent à un bon
niveau d’abstraction
• on manipule toujours des objets
l Le mode de communication entre les couches est le
même qu’à l’intérieur d’une couche
• Transparence de la distribution : on ne s’en préoccupe pas à
la conception…mais au niveau du déploiement.
l Il existe des technologies permettant l’appel de
méthodes distantes très simplement
• RMI (JAVA) : Remote Method Invocation
• Corba
• .NET remoting
• …
10
Ø Comment transférer des instances d’une
couche à l’autre (ex: callback avec en
retour un objet)
l La couche qui reçoit un objet doit avoir
connaissance de sa classe (2 solutions) :
• La classe est transmise avec l’objet
l Charge réseau importante : il faut transmettre tout l’arbre
d’héritage
• Toutes les couches ont une copie des classes
qu’elles sont amenées à manipuler
l Moins souple, mais plus économique pour le réseau

Ø Comment transférer des instances d’une
couche à l’autre
l Les paramètres (2 solutions)
• Par valeur : on transmet une copie des objets
(sérialisation en binaire)
• Par référence : on transmet un pointeur sur l’objet.
l C’est le mode classique des langages OO
l Utilisation de proxy et stubs pour rendre le passage par
référence transparent
a:=d.toto( obj
obj)) - > a est une instance du proxy accédant à
l’objet distant. Le proxy spécifie l’interface
a.coucou - > le code de coucou est exécuté à distance
Communication par messages
Ø Communication par messages asynchrones

l Il peut être utile de transmettre une information à
une couche inférieure sans pour autant avoir
besoin d’une réponse : asynchronisme
l Exemple : notification d’évènement,
déclenchement d’un traitement batch (ex: à minuit
envoyer les emails
emails)…
)…
l On utilise alors la communication par message.
l Technologie : JMS (Java Message System), …
11
Communications par Serveur Web
l Utilisation du protocole HTTP
• passe partout : Permet de transmettre les données sur de longues
distances : le protocole HTTP est toléré par tous les firewalls
firewalls..
• compris partout: Tous le monde a un client HTTP : le navigateur
web..
web
• La gestion de session « web » est prise en charge par le serveur
web
l Permet de créer des interfaces utilisateur (HTML)
• compris partout: Un navigateur web suffit pour utiliser l’application
: pas de problème d’administration, de mise à jour des clients !
l Permet à des applications de communiquer
(Services Web
Web))
• Permet de définir et utiliser des API tout en étant
indépendant du langage utilisé.



la persistance


La persistance
Ø Stocker de façon permanente les données

manipulées par l’application
l Permettre d’arrêter et redémarrer l’application
sans perdre d’informations
l Partager des données entre plusieurs
applications indépendantes
Besoin de stocker des instances du modèle métier :

Comment rendre persistant des objets ?
12
La persistance
Ø Par exemple :
l Stockage sur disque des objets
l Bases de données relationnelles
l Système de fichiers
l Bases de données objets
l …
Ø La couche d’accès aux données doit
rendre transparente la technologie utilisée
pour la couche métier et assure l’intégrité
des données
l’intégrité des données

Ø Assurer que les données stockées sont cohérentes
l Exemple : Une AOD gère des comptes bancaires
• Les objets persistants « compte bancaire » comportent entre autres
autres les
méthodes « débiter(montant) » et « créditer (montant)».
• La couche d’accès aux données permet de charger et enregistrer d es
objets « compte bancaire »
• On souhaite implanter un service de virement bancaire :
l Charger les deux comptes bancaires
l Débiter le montant du compte source du virement
l Créditer le compte destination
l Enregistrer les comptes avec leur nouveau montant
• Chacune des étapes peut échouer et conduire à un problème d’intégrité
d’intégrité :
Compte destination pas crédité, compte source pas débité, …
La persistance doit s’accompagné d’un mécanisme de

transactions
Transaction
Ø Un mécanisme de transaction permet de rendre atomique un
ensemble d’actions
l Exemple :
• Début de transaction
l Charger les deux comptes bancaires
l Débiter le montant du compte source du virement
l Créditer le compte destination
l Enregistrer les comptes avec leur nouveau montant
• Si tout va bien : Valider la transaction (Commit)
• Si il se produit une erreur : Annuler la transaction (Rollback
(Rollback))
l Si il y a une erreur, toute les modifications réalisées dans le corps de
la transaction sont annulées.
l L’état du système reste ainsi cohérent même si une
erreur se produit.
13
Serveur d’application
Ø Objectifs
l Prendre en charge les problèmes récurrents rencontrés lors du
développement d’AOD (Persistance, Accès à distance,
transaction, session,…)
Ø Exemple :
l Plateforme J2EE
l Plateforme .NET
Ø Point fort
l Permet au dévelopeur de se concentrer sur la logique métier.
Ø Point faible
l Comme toute application qui propose de tout prendre en charge,
les serveur d’application sont assez difficile à maîtriser…



la persistance


Interface utilisateur
(couche présentation)
l Interface Web : pas de traitements locaux
• Client léger (= le même client pour se connecter à tous les
services-- il n’y a rien à installer chez les clients - (navigateur
services
web:: Internet explorer, netscape …)
web
• Communication via serveur Web
l Programme client dédié à l’application (traitements
locaux)
• Possibilité d’adapter le client à l’application (ex: calendar
interne à un réseau local, Objecteering : interface trop
complexe)
• Mode de communications au choix
l Serveur web (en utilisant des service web
web))
l RPC (RMI, CORBA,…)
• Déploiement et maintien plus difficile
La technologie doit être choisie en fonction du
CSAOD nombre et du statutaux
Introduction des
AODutilisateurs. 42
14


la persistance


Cryptage et Authentification
Ø Les AOD sont généralement multi -utilisateurs et peuvent
manipuler des données sensibles
l Exemple : les numéros de carte de crédit pour les applications
de commerce en ligne.
Ø Il est donc nécessaire de prendre en compte très tôt la
sécurité des données et des échanges.
Ø Plusieurs problèmes
l La personne qui m’envoie une requête est-
est- elle bien la personne
qu ’elle prétend être ?
• Authentification
l Comment être sûr que personne ne va intercepter les messages
échangés ?
• Cryptage
Cryptage/Authentification -
exemple
Do-- this
Do
Who are you ?
John
Ø Zéro-- knowledge
Zéro
15
Cryptage – les fils d’Ali-
d’Ali - Baba
Ø Ali- Baba a eu au moins un fils
Ali-
Ø Il a un trésor accessible par des mots de passe
dans un grotte
Ø Ali
Ali-- Baba est mort
Ø Quelqu’un prétend être son fils et donc détenir
les mots de passe
Ø Comment convaincre la population sans livrer
les mots de passe ?
Cryptage – les fils d’Ali-

d’Ali - Baba
trésor
Cryptage - exemple
Ø Zéro--knowledge
Zéro
Do-- this
Do
Who are you (x=1 p=3) ?
1
Who are you (2, 3) ?
1
Who are you (3, 3) ?

? 0
16
Cryptage - exemple
Ø Zéro--knowledge
Zéro grotte
Fils Ali-
Ali- Baba Do-- this
Do
Who are you (x=1 p=3) ?
1
V=x^n mod p
n= secret (mdp
(mdp)) Who are you (2, 3) ?
Opt:: p aussi secret
Opt 1 V=x^n mod p
(CB) V = fct du protocole
Who are you (3, 3) ? n= secret (mdp
(mdp))
population
Concevoir une AOD

Ø Concevoir le modèle métier
l Conception OO classique
l Sans se soucier des aspects de persistance, transaction…
Ø Réaliser la couche d’accès aux données

l la persistance ne doit pas compliquer le modèle métier
l Interfaçage avec une BD existante ?
l Quelle technologie utiliser ?
…
Ø Réaliser la couche de présentation

l Interface web ou interface dédiée ?
l Quel mode de communication avec l’application ?
l la présentation ne doit pas compliquer le modèle métier
…
Conclusion
Ø La construction d’une application à objets
distribués nécessite :
l D’en élaborer l’architecture
• Modèle métier
• Quel objet est distribué ? Persistant ?
• Comment les différentes composantes
communiquent--elles ?
communiquent
l De définir des stratégies de sécurité
l De choisir les technologies adéquates
17
Le cours de CSAOD
Ø Buts :
l Familiarisation avec les concepts des applications
distribuées
l Connaître les principales technologies sous-
sous-jacentes
• Java : RMI pour la communication, JDO pour la persistance,
Swing pour le graphique (client lourd), JSP (client léger).
• Web services avec communication basée sur Soap Soap..
Ø Moyens :
l Utilisation d’un exemple : une vidéothèque
l Application des grands principes vus en cours
l Assemblage progressif en TP de plusieurs briques
formant une AOD
Le travail à fournir
Ø A l’issue de chaque cours:
l Lire la documentation pour le TP suivant quand
demandé
Ø Pour les TPs:
l Ne pas prendre de retard
l Profiter des mercredi libres (c’est volontaire)
l Respecter les interfaces et les consignes données
l Validation des TPs par des jeux de test prédéfinis
l Livrables à rendre régulièrement
Plan du cours
Ø Élaboration du modèle métier de la vidéothèque,
et architecture de l’application
Ø XML : principes et outils
l Utilisé dans la plupart des technologies liées à la
communication entre applications
Ø La persistance d’objets
Ø Les objets distribués :
l RMI, Corba
Ø Les services web
l Et côté client ? L’exemple des JSP
18
Plan des TPs
Ø Implémentation du modèle métier
Ø Implémentation d’un module d’import/export
XML
Ø Rendre la vidéothèque persistante
Ø Elaboration d’une interface interne à la
vidéothèque de gestion des données
Ø Publication d’un service web pour la consultation
des ouvrages
Ø Utilisation du service web publié :
implémentation d’un client
19

Introduction Client/seveur

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Introduction Client/seveur

Enviado por

Direitos autorais:

Formatos disponíveis

CSAOD

CSAOD Introduction aux AOD 2

CSAOD Introduction aux AOD 3

CSAOD Introduction aux AOD 4

Architectures classiques des

CSAOD Introduction aux AOD 6

Px Processus x Il existe au moins un cycle dans le

Ø Ce type d’architecture pose problème tant pour

Px Processus x Pas de cycle dans le graphe de

Ø Permet de maîtriser la complexité de l’AOD :

Ø Deux types de noeuds

CSAOD Introduction aux AOD 9

CSAOD Introduction aux AOD 10

Ø La majorité des AOD sont construites

CSAOD Introduction aux AOD 11

CSAOD Introduction aux AOD 12

CSAOD Introduction aux AOD 13

Ø Les requêtes de deux clients sont indépendantes

Ø L’idée du « load balancing » est de paralléliser sur

CSAOD Introduction aux AOD 14

CSAOD Introduction aux AOD 15

CSAOD Introduction aux AOD 16

CSAOD Introduction aux AOD 17

Répartition de charge : Exemple

Le serveur de noms (DNS) joue le rôle de répartisseur

CSAOD Introduction aux AOD 18

Ø Solution : les architectures multicouches

CSAOD Introduction aux AOD 19

Les architectures multicouches

CSAOD Introduction aux AOD 20

Les architectures multicouches

Couche 3 Faiblement couplé :

CSAOD Introduction aux AOD 22

Les architectures à 3 couches

CSAOD Introduction aux AOD 23

Les architectures à 3 couches

CSAOD Introduction aux AOD 24

Les architectures multicouches

l Comment échanger des objets entre différentes machines :

l Comment stocker des objets :

l Comment présenter des données :

l Comment sécuriser les données et les échanges :

CSAOD Introduction aux AOD 26

• Ex : RMI, CORBA, .NET Remoting , Service Web

• Ex : Applet JAVA via RMI, Service Web via Soap

CSAOD Introduction aux AOD 27

Objet client Objet serveur

CSAOD Introduction aux AOD 28

Appel de méthodes distantes

Couche cliente Couche serveur

CSAOD Introduction aux AOD 29

Appel de méthodes distantes

CSAOD Introduction aux AOD 30

Appel de méthodes distantes

CSAOD Introduction aux AOD 32

Communication par messages

Ø Communication par messages asynchrones

CSAOD Introduction aux AOD 33

CSAOD Introduction aux AOD 34

Les architectures multicouches

l Comment échanger des objets entre différentes machines :

l Comment stocker des objets :

l Comment présenter des données :