Architectures client-serveur et

Services applicatives

1
Plan

 Introduction
 Architectures client-serveur
 Middleware
 Services applicatives

2
Introduction
 Applications réparties (distribuées)
 Pour fonctionner ces applications doivent interagir avec
plus d'un module situés sur des ordinateurs distincts, en
communiquant à travers un réseau (local ou distant).

 Applications parallèles
 On parle de parallélisme quand deux modules (ou plus)
d'une même application peuvent effectuer des tâches
simultanés et jusqu'à un certain point, indépendantes.

3
Introduction
 Paradigme client-serveur
structurer un système distribué en termes d’entités clientes et
d’entités serveurs qui communiquent par l’intermédiaire d’un
protocole

4
Introduction
 Paradigme client-serveur
 Service : regroupement de fonctions liées à la gestion d’une
ressource applicative, physique ou logique : des programmes,
des données, des processeurs et des périphériques de stockage
 Serveur : entité exécutable qui réalise, seule ou en coopérant
avec d’autres entités serveurs, les fonctionnalités du service.
• un serveur Web fournit des pages Web
• un serveur de fichiers sert fichiers informatiques.
• pour un SGBD (DBMS), le serveur est un serveur de DB
 Client : entité exécutable qui qui émet une requête auprès
d’un serveur pour utiliser les fonctionnalités d’un service.
 Communication par message: locale ou via le réseau
informatique 5
Introduction
 Applications client-serveur
Les systèmes client-serveur désignent aujourd'hui plusieurs
types d'applications:
– les applications WEB comme le courrier, les achats en ligne
– les liens avec les services (locaux ou distants) comme
l'impression
– les applications tirant profit des multiprocesseurs
– les applications de base de données (au sens très large du
terme)

6
 Architectures client-serveur
 Schéma applicative
Development Tools

Presentation Business Logic Data Access

Distributed
HTML Objects Data Access
HTML
Objects
Transactions
Enterprise Data
Java
Content Connectors
Data
Management

Java
Application Enterprise Deployment Services
Scalability Reliability Security Manageability
7
Architectures client-serveur
 Schéma applicative
 Présentation : les tâches liées à la présentation requièrent
 L'interaction avec l'utilisateur
 Interface classique : boutons, listes, menus, ... (ex :
traitement de texte)
 Interface Web : formulaires, liens vers des URLs
 La logique de présentation
 Le traitement des données retournées par les services
métiers et leur présentation à destination de l'utilisateur
 Réalisée par un client lourd qui généralement fait
directement l'appel des services métiers sur le serveur
 Logique de présentation peut être exécutée coté client ou
8
coté serveur mais se fait généralement dans un tiers à part
Architectures client-serveur
 Schéma applicative
 Présentation : Technologies et frameworks
 HTML, CSS, HTML5, Javascript
 Bootstrap, AngularJS
 JSF (Java Server Page) avec les composants Primefaces,
ICEfaces, RichFaces,
 JSP, Struts, GWT, WebWork, Tapestry, Apache Wicke

9
Architectures client-serveur
 Schéma applicative
 Logique applicative (logic tier, business logic): intègre la logique
métier, les services offerts aux utilisateurs
 toutes les règles de gestion, et toute l’intelligence de la
démarche
 Spring, Web service
 A terminer

10
Architectures client-serveur
 Schéma applicative
 Persistance (Data Access) : Enregistrement sur support physique
des données de l'application
 Fichiers binaires, textes « de base »
 Fichiers XML, LDAP
 Une base de données ou un ensemble de bases de données
 Dans le cas d’une BD
 Nécessité d'envoyer à distance des requêtes (types SQL) et
d'en récupérer les résultats. Pour réaliser cela
Soit c'est natif dans le langage utilisé (ex : PHP)
Soit on passe par des frameworks ou des API dédiés

11
Architectures client-serveur
 Schéma applicative
 Persistance (Data Access) : Quelques standards / outils d'accès à
distance à des BD
 RDA (Remote Data Access) de l'ISO
 ODBC (Open Data Base Connectivity) de Microsoft
 JDBC (Java Data Base Connectivity) d’Oracle
 Fonctionnement général :
 Gestion de requêtes SQL mais avec indépendance du
SGBDR utilisé (mySQL, PostgreSQL, Oracle ...).
 En général, seule la phase de connexion au SGBDR est
spécifique
12
Architectures client-serveur
 Schéma applicative
 Persistance (Data Access) : Frameworks de plus haut niveau
 Object-relational mapping (ORM) : Définition de manière
abstraite (via XML) la structure des données à manipuler
 L'outil génère un ensemble d'opérations de manipulation
de données (en java par exemple) utilisable dans un
programme. Il fait en interne le lien avec le support
physique (SGBDR ...) considéré
TopLink, Doctrine, Hibernate, iBATIS and Apache


OpenJPA.
 Entreprise Data connectors : Using a Data Connector is very
convenient when your database lives behind an enterprise
firewall and you don't want mobile applications to connect
13
to
it directly. Examples : corticon, Telerik
Architectures client-serveur
 Schéma applicative : exemples

14
Architectures client-serveur
 Classification des architectures
Ou placer l’application?

Application

Client Server

Dans un contexte distribué, les couches de l’application sont /

peuvent être exécutées sur des machines différentes. Certaines
couches peuvent être sous découpées
 Classification en couches
 Classification en niveaux
 Peer-to-Peer 15
Architectures client-serveur
 Classification en couches

 Vison en couches des différentes composantes d’une

architecture client-serveur (comme le modèle ISO en 7
couches).
 Intéressante si les éléments mis en jeu dans les différentes
couches sont hétérogènes.
 Il fait intervenir deux entités : clients et serveurs (2 tiers)
 Le Gartner Group (société de consulting) a établi un
découpage en six vues distinctes montrant les différentes
possibilités de répartition entre clients et serveurs des trois
principales couches logicielles
16
Architectures client-serveur
 Classification en couches

Présentation Présentation Gestion Traitements Données et Bases de

distribuée distante distante des distribués traitements données
données distribués Distribuées

17
Architectures client-serveur
 Classification en couches

Terminal ou X Window client/server RPC Accès Bases de

émulation de System, SGBD (DB2, Web Services Mobile données
terminal sur Application Oracle, , RMI distribuées
site, Terminal Web avec un etc.)
Server sous navigateur
18
Windows Web
Architectures client-serveur
 Client Léger, Lourd et enrichie

3 Data Access Types de clients

2 Business Logic
Fat
Thin
1 Presentation Client
Client

19
Architectures client-serveur
 Client Léger, Lourd et enrichie

Client lourd (Fat Client): possède une interface graphique riche

ainsi que des capacités de traitements élevées (logique métier).
 MSN, Thunderbird, Outlook, Antivirus

Client léger (Thin client) : une interface graphique limitée

accessible via une interface web et consultable via un navigateur
(absence de logique métier).
 WebMessenger, Hotmail

20
Architectures client-serveur
 Client Léger, Lourd et enrichie

Client lourd

21
Architectures client-serveur
 Client Léger, Lourd et enrichie

Client léger

SGBD sur le
serveur
22
Architectures client-serveur
 Client Léger, Lourd et enrichie

23
Architectures client-serveur
 Client Léger, Lourd et enrichie
Client enrichie : combler les limites des clients lourd et léger
 Lourdeur de la maintenance pour le client lourd
 Lenteur et pauvreté pour le client léger
Deux approches :
 Rich Desktop Application (RDA) : On améliore le client lourd
 Sun JavaWebStart
 Microsoft : No Touch Deployment (.NET)
 Rich Internet Application (RIA) : On améliore le client léger
 Ajax, Flash, …
24
Architectures client-serveur
 Classification en niveaux (n-tiers)
Comparable à une architecture par couches… dont les couches
seraient distribuées !
Par abus de langage, la notion de tier a pris le sens de couche
distribuée
Chaque niveau est représenté par un composant qui joue le rôle
de client et/ou de serveur
Connecteurs : relient un client à un serveur. Connexion
asymétrique. Doit supporter les communication distantes (e.g.,
requêtes RPC, HTTP, TCP/IP)
Exemples
 Client-serveur, Trois niveaux, Quatre niveaux
25
Architectures client-serveur
 Classification multi-niveaux (n-tiers)
 1-tier ou centralisée
Le Tout sur la même machine. Exemple : Mainframe
les réseaux informatiques sont configurés autour d'un
ordinateur central de grande puissance appelé "Mainframe" qui
gère toutes les sessions utilisateurs ouvertes par l'ensemble des
terminaux-utilisateurs qui lui sont reliés (terminaux passifs :
écran adjoint d’un clavier sans unité centrale).

Pour pallier le manque de graphisme, différentes

solutions existent dont l'intégration du 26

mainframe dans une architecture 2, 3 ou N niveaux

Architectures client-serveur
 Classification multi-niveaux (n-tiers)
 Les architectures 2-tiers
• Client-serveur de base, avec 2 éléments
• Client : présentation, interface utilisateur
• Serveur : partie persistance, gestion physique des données
Physical Architecture Technical Architecture
Windows Database
Client Server
GUI

…
PowerBuilder Oracle
Visual Basic Sybase Ethernet
Visual C++ SQLServer TCP/IP
JEE
27
Architectures client-serveur
 Classification multi-niveaux (n-tiers)
 Les architectures 2-tiers
Les services métier / la partie applicative peuvent être
– Soit entièrement coté client, intégrés avec la présentation
• Ex : traitement de texte avec serveur de fichiers distants
• Ex : application accédant à une BDD distante
– Soit entièrement coté serveur
• L'interface utilisateur peut même être exécutée sur le
serveur
– Soit découpés entre la partie serveur et la partie client

28
Architectures client-serveur
 Classification multi-niveaux (n-tiers)
 Les architectures 2-tiers

29
Architectures client-serveur
 Classification multi-niveaux (n-tiers)
 Les architectures 2-tiers

 Applications internes
 Des environnements avec peu de clients
 Des environnements homogènes
 Des environnements fermés (e.g SGBD)

 Heavy load on database

 Limited option for scaling
 Costly software distribution
 Poor separation of software components
 “Fat Client”
Architectures client-serveur
 Classification multi-niveaux (n-tiers)
 Les architectures 3-tiers
Les 3 principaux tiers s'exécutent chacun sur des machines
différentes

Physical Architecture Technical Architecture

Business Data
GUI
Logic Base
Application Server

DataBase Server 31
Architectures client-serveur
 Classification multi-niveaux (n-tiers)
 Les architectures 3-tiers
In the web development field, 3-tier is often used to refer to websites,
which are built using three tiers:
– A front-end web server serving static content, and potentially
some cached dynamic content. In web based application,
Front End is the content rendered by the browser. The content
may be static or generated dynamically.
– A middle dynamic content processing and generation level
application server, for example Ruby on Rails, Java EE,
ASP.NET, PHP, ColdFusion, Perl, Python platform.
– A back-end database or data store, comprising both data sets
and the database management system software that manages
and provides access to the data.
Architectures client-serveur
 Classification multi-niveaux (n-tiers)
 Les architectures 3-tiers
Physical Architecture

HTTP Applicati
Web Web on Data
Browser Server base
Server

HTML
Pages

Technical Architecture

Any Computer Server

Any Network
Architectures client-serveur
 Classification multi-niveaux (n-tiers)
 Les architectures 3-tiers

 Le mise à l’échelle des milliers de clients

 Accès à des sources de données hétérogènes
 Maintenance (update software on few app. servers
instead of thousands of clients)
 Séparation entre la presentation et la logique métier

 Costly software distribution

 Poor cross-platform support
 “Fat Client”
Architectures client-serveur
 Classification multi-niveaux (n-tiers)
 Architecture n-tiers
Rajoute des étages / couches en plus
La couche applicative n'est pas monolithique
– Peut s'appuyer et interagir avec d'autres services
– Composition horizontale
• Service métier utilise d'autres services métiers
– Composition verticale
• Les services métiers peuvent aussi s'appuyer sur des
services techniques : Sécurité, Transactions, ...
Chaque service correspond à une couche : d'où le terme de N-tiers
35
Architectures client-serveur
 Classification multi-niveaux (n-tiers)
 Architecture n-tiers

36
Architectures client-serveur
 Peer-to-Peer
 égal à égal" ou "point à point".
 Chaque ordinateur connecté au réseau est susceptible de jouer
tour à tour le rôle de client et celui de serveur
 Intérêt : optimiser l’utilisation des ressources (CPU, stockage
et bande passante) de l’ensemble du réseau.
 Défit : comment obtenir la localisation d’une donnée
particulière ?
 Terminologie :
 Nœud : entité logicielle intervenant dans le système
 Lien : canal de communication entre nœuds
 Réseau : noeud+lien 37

 Echange d’objets entre les noeuds

Architectures client-serveur
 Architectures Peer-to-Peer
 Client- Serveur
Le serveur est un intermédiaire de stockage pour les
échanges de données entre clients.
 Le serveur est un intermédiaire de communication.
 Les seules ressources publiées sont celles localisées
sur le serveur.
 Exemple : Messagerie Mail

38
Architectures client-serveur
 Architectures Peer-to-Peer
 P2P centralisé
Le serveur est un intermédiaire de coordination
et/out de communication pour les échanges de
données entre clients.
 Napster
 Pour partager un fichier, il suffit de se déclarer chez
le serveur qui possède l’annuaire général
 Pour obtenir le fichier, il est nécessaire d’intéroger le
serveur qui donne la liste des nœuds qui possède le
fichier
 Transfert s’effectue directement entre nœuds
 Problème : centralisation des indexes
39
Architectures client-serveur
 Architectures Peer-to-Peer
 P2P centralisé
• Napster • Groove
• Partage de fichiers • Service collaboratif d’édition
musicaux. de documents.
• Recherche effectuée sur • Service de relai pour
l’index du serveur. coordonner les pairs sur le
contenu des documents.

40
Architectures client-serveur
 Architectures Peer-to-Peer
 P2P décentralisé
– Pur P2P.
– Pas de serveur dédié.
– Les pairs publient et consomment des
ressources.
– Les pairs orientent les requêtes.

41
Architectures client-serveur
 Architectures Peer-to-Peer
 P2P décentralisé (Gnutella)
– Aucun serveur central. Chaque nœud indexe ses données
et se déclare auprès de ses voisions
• comment trouver des voisins? Liste de voisins sur le web
– Découvertes et requêtes transmises de proche en proche.
– Diffusion limitée par le TTL.
– Connaissance locale du réseau.
– Les nœuds lents ralentissent les requêtes

42
Architectures client-serveur
 Architectures Peer-to-Peer
 P2P décentralisé : Kaaza et Gnutella 0.6

43
Architectures client-serveur
 Architectures Peer-to-Peer
 P2P décentralisé : ADSL

44
Architectures client-serveur
 Architectures Peer-to-Peer
 P2P décentralisé : eDonkey et eMule

45
Architectures client-serveur
 Architectures Peer-to-Peer
 P2P décentralisé : Bittorent

46
Architectures client-serveur
 Architectures Peer-to-Peer
 P2P décentralisé : Bittorent

47
Architectures client-serveur
 Architectures Peer-to-Peer
 P2P vs client-serveur
• Rapidité d’exécution: • Coûts réduits:
– Plus de puissance processeur; – Maintenance;
– Plus de capacité mémoire; – Equipements.
– Temps de transit réduits. • Meilleure capacité d’extensibili
• Meilleur utilisation de la bande • Sécurité.
passante.
• Problèmes éthiques (droits
• Tolérance aux pannes: d’auteurs,...).
– Connexions plus instables;
– Redondance accrue des
informations.
48
Middleware
 Médiateur

• Software that connects two

otherwise separate applications Database Server:
• Example: Middleware product Manages Data
linking a database system to a
Web server Middleware Links
Applications

Web Server:
Presents Dynamic Pages
Client: Requests Data via Web 49
Middleware
 Médiateur
Middleware (Intergiciel)
– Logiciels s’exécutant à la fois côte client et côté serveur
– Offre le service de distribution et d’héterogénité [IBM
Mainframe (big-endian), Unix (Little-endian)].
L'échange de messages, l'appel de procédures et la
manipulation d'objets tiers sont trois techniques prises en
charge par le middleware, qui permettent à des applications
informatiques d'interagir, de coopérer et de se transmettre
des informations.

50
Middleware
 Médiateur
Un Middleware offre en plus les services de :
– Transactions : concept à la base de l’échange commercial
informatisé, exécution d’une ou plusieurs tâches accédant
à une ou plusieurs ressources sur différents serveur (dont
des BD) offrant un ensemble de garanties :
• Atomicité : une transaction est soit validée soir
entièrement annulée.
• Cohérence
• Isolation : Les données manipulées dans une
transaction ne sont pas accessibles à d’autres.
• Durabilité : Le nouvel état des données (après la
transaction) est enregistré dans la base. 51
Middleware
 Médiateur
Un Middleware offre en plus les services de :
– interopérabilité : communication entre objets écrits avec
différents langages (du C++ faisant appel ç un
programme distant en JAVA. (Exemple : CORBA).
– Sécurité, contrôles d’accès.
– Nommage (API JNDI : interface pour se connecter aux
services de noms ou d’annuaires).
– Gestion transparente de la communication bas-niveau
entre divers clients et EJB distants (JEE remote
connectivity).

52
Middleware
 Médiateur
Exemples Middleware
– Orientés transaction : IBM CICS, Tuxedo
– Appel à méthodes distantes middleware
• RPC Middleware, Java/RMI
– Object-Oriented Middleware :
• OMG/Corba, Microsoft/Com, Java/RMI,
• ORB : Object Request Broker. Intergiciel, dit bus d’objets ou bus
logiciel, assurant l’appel de service à distance.
CORBA (Common Object Request Broker Architecture) : Un
middleware pour les applications distribuées et l’interopérabilité,
incluant un bus logiciel et un ensemble de services.

53