Architectures des Systèmes

d’ Information

chapitre 2&3 –
Architectures client serveur
Laetitia MOUAFO
PhD - Computer Science
 Architecture du SI

•Trois niveaux d'architecture : fonctionnelle, applicative,

technique

•Architecture fonctionnelle : recense les grandes fonctions

du SI; Correspond à la perception détaillée des
composants de la vue du SI

•Architecture applicative: décrit le fonctionnement des

applications réparti en trois composantes : la présentation,
le métier et la persistance

• Architecture technique : décrit le mode de

fonctionnement de l'infrastructure matérielle
 Tryptique d'une application
❖ Architecture applicative : décrit le fonctionnement des
applications, programmes et logiciels (logiciels de
comptabilité, ERP)

❖ Tryptique d'une application

 Tryptique d'une application
❖ Présentation : interface utilisateur pour interagir avec
l'application
❖ Interface classique type GUI (ex : traitement de

texte)
❖ Interface Web, plus légère

❖ Persistance : enregistrement sur support physique des

données de l'application
❖ Fichiers (binaires, XML, …)

❖ Base de données

❖ Simple

❖ Avec redondance pour fiabilité

❖ Multiples : fédération de bases de données

 Tryptique d'une application
❖ Service métier: intègre la logique métier + service offert à
l'utilisateur + partie applicative
❖ Logique métier : un document est composé de sections , elles
mêmes composées de sous-sections
❖ Service utilisateur : créer un document, le modifier, …

❖ Logique métier + persistance + service métier

❖ Intégrées pour le bon fonctionnement de l'application
❖ Appelés « tiers » en anglais
lEx : Application « 3-tiers » quand les trois composantes sont

distinctes
❖ Différents contextes techniques
❖ Contexte distribué : tiers exécutés sur différentes
machines
❖ Contexte centralisé : tout est sur la même machine
 Architecture 2-tiers
❖ Client/serveur de base avec 2 éléments:
❖ Client : présentation, interface utilisateur

❖ Serveur : partie persistance, gestion physique des données

❖ Mode « Client lourd » : service métier/ partie applicative entièrement coté

client, intégrés avec la présentation . La partie serveur ne gère que les données
❖ Ex : traitement de texte avec serveur de fichiers distants; application accédant à
une BDD distante

❖ Mode « Client léger » : service métier/ partie applicative entièrement côté

serveur. La partie client ne gère que l'interface utilisateur
❖ L'interface utilisateur peut même être exécutée sur le serveur:
fonctionnement mode terminal/mainframe où l'utilisateur a simplement
devant lui écran/clavier/souris pour interagir à distance avec l'application
s'exécutant entièrement sur le serveur

❖ Mode « Applicatif » : service métier/partie applicative découpés entre la partie

serveur et la partie client
 Architecture 2-tiers
❖ Mode Client lourd

❖ Mode Client léger

❖ Mode applicatif
 Architecture 3-tiers

❖ Les principaux tiers s'exécutent chacun sur un

composant logiciel différents :

❖ Présentation : machine cliente (navigateur)

❖ Applicatif/métier : serveur d'applications
❖ Persistance : serveur de base de données
 Architecture 3-tiers web
❖ Architecture 3 – tiers : Très développée sur le web

❖ Couche présentation : navigateur web sur machine

cliente
❖ Client léger : affichage de contenu HTML
❖ Couche applicative / métier
❖ Serveur d'applications : serveur HTTP exécutant
des composants/éléments logiciels qui génèrent
dynamiquement du contenu HTML Via des
requêtes à des bases de données distantes

❖ Couche persistance
❖ Serveur(s) de base de données
 Architecture N-tiers

❖ Architecture N–tiers : rajoute des étages en plus

❖ La couche applicative n'est pas monolithique

❖ Peut s'appuyer et interagir avec d'autres services

❖ Composition horizontale : un service métier

utilise d'autres services métiers
❖ Composition verticale : un service métier peut
aussi s'appuyer sur des services techniques :
sécurité, transaction
❖ Chaque service correspond à une couche : d'où le

terme de « N-tiers »
 Bénéfices du n-tiers

❖ Réutilisation de services existants

❖ Meilleure modularité : découplage des aspects

métiers et technique et des services entre eux

❖ Facilité d'évolution : nouvelle version de service

❖ Facilité de passage à l'échelle : évolution de certains

services

❖ Couplage faible entre les services : permet de faire

évoluer les services un par un sans modification du
reste de l'application
 Limites du N-tiers

❖ Technologies variées : en général, les divers services

s'appuient sur des technologies très variées
❖ Nécessité de prendre en compte l'hétérogénéité
et l'interopérabilité : Utilisation de framework et
outils supplémentaires

❖ Distribution : les services étant plus découpés et

distribués, pose plus de problèmes liés à la
distribution
 Logique de présentation
❖ La couche présentation requiert :
❖ L'interaction avec l'utilisateur : GUI ou navigateur
❖ La logique de présentation
❖ Le traitement des données retournées par les services
métiers pour affichage à l'utilisateur
❖ Réalisée par un client lourd qui généralement fait
directement l'appel des services métiers sur le serveur

❖ Cas d'un client web

❖ Le navigateur se contente d'afficher du code HTML:
Exécute le code qui récupère les données retournées par
les services métiers et génère dynamiquement du code
HTML
❖ Logique de présentation: peut être exécutée coté client
ou coté serveur mais se fait généralement dans un tiers à
part coté serveur
 Persistance
❖ Stockage et manipulation des données de
l'application

❖ Plusieurs supports physique

❖ Fichiers binaires, textes «de base»
❖ Fichiers XML

❖ Une base de données ou un ensemble de bases de

données
❖ Nécessité d'envoyer à distance des requêtes
(types SQL) et d'en récupérer les résultats
❖ Soit l'envoi est natif dans le langage utilisé
(ex : PHP)
❖ Soit on passe par des frameworks ou des API
dédiés
 Persistance – quelques outils

❖ Outils d'accès à distance aux BD

❖ RDA (Remote Data Access) de l’ISO
❖ ODBC (Open Data Base Connectivity) de Microsoft
❖ JDBC (Java Data Base Connectivity) de Sun
❖ Principe général :Gestion de requêtes SQL mais avec
indépendance du SGBDR utilisé (mySQL, PostgreSQL,
Oracle …)

❖ Frameworks de plus haut niveau

❖ Hibernate (Sun, J2EE), NHibernate (libre, pour .Net)
❖ Principe général : On définit de manière abstraite (via XML
par ex) la structure des données à manipuler.
❖ L'outil génère un ensemble d'opérations de manipulation
de données (en java par ex) utilisable dans un programme
❖ L'outil fait en interne le lien avec le support physique
(SGBDR ...) considéré
 Persistance – Frameworks
❖ Un grand nombre de technologies
❖ Présentation : HTML, GUI …
❖ Applicatif : objets, composants, scripts
exécutables, services, ..
❖ BD : fichiers XML, SGBDR, …
❖ Protocoles de communication : RPC / RMI,
HTTP

❖ Frameworks
❖ J2EE / Java EE chez Sun
❖ .Net chez Microsoft
❖ Serveur d'application : Serveur permettant
d'exécuter les parties applicatives dans le
contexte de ces frameworks
 Persistance – Framework J2EE
❖ J2EE/Java EE - Java Entreprise Edition : standard défini par Sun
pour le langage Java

❖ Technologies :
❖ Composants logiciels : EJB
❖ Applications orientées Web : JSP, servlet
❖ Communication à distance : Java RMI, IIOP, JMS (Java Message
Service : communication par message), Web Services
❖ Gestion données distantes : JDBC, JPA (Java Persistance API)
❖ Gestion d'annuaires (type LDAP) : JNDI
❖ Transactions : JTA

❖ Serveurs d'applications J2EE

❖ Versions libres : GlassFish, JBoss, Apache Geronimo, Jonas …
❖ Versions d'éditeurs : Sun Java System Application Server (basé
sur GlassFish), IBM WebSphere, BEA WebLogic, Oracle
Container for Java EE,
 Persistance – Framework .Net
❖ Solution Microsoft similaire à J2EE
❖ Particularité : multi-langage
❖ Permet interopérabilité d'éléments écrits en C, Java, C#, J#,
Eiffel,
❖ Traduction en code intermédiaire (MSIL) qui sera exécuté par
la couche CLR (Common Language Runtime)
❖ Côté Java, c'est le code Java qui était converti en byte code
exécuté par la machine virtuelle Java (JVM)

❖ Technologies intégrées
❖ Composants logiciels : COM+
❖ Applications orientées Web : ASP .Net,
❖ Communication à distance : .Net remoting, MSMQ, Web
services
❖ Accès données : ADO .Net, ODB,
❖ ...
Architecture 4-tiers
 Architecture 4-tier
❖ La couche présentation contient les différents types de clients,
léger (ASP, JSP) ou lourd (Applet)

❖ La couche applicative contient les traitements représentant les

règles métier (créer un compte de facturation, calculer un
amortissement ... )

❖ La couche d'objets métier est représentée par les objets du

domaine, c'est à dire l'ensemble des entités persistantes de
l'application (Facture, Client ... )

❖ La couche d'accès aux données contient les usines d'objets métier,

c'est à dire les classes chargées de créer des objets métier de
manière totalement transparente, indépendamment de leur mode
de stockage (SGBDR, Objet, Fichiers, ...)
 Conteneur J2EE

❖ Application J2EE = 0..* composants Web + 0..*

composants EJB
❖ Plusieurs rôles :
❖ Développeur de composants Web,

❖ Développeur de composants EJB,

❖ Assembleur d’applications,

❖ Deployeur et gestionnaire d’applications

❖ 4 services fournis par le serveur au conteneur EJB

❖ cycle de vie,

❖ transaction JTS,

❖ nommage JNDI,

❖ Sécurité
Conteneur J2EE
Architecture web J2EE
Mécanisme d'une application web J2EE
3 - La servlet contrôle la
validité de la requête HTTP.
4 - instanciation des beans
de données pour accéder aux
données.
5- persistance des données
6 – invocation de la JSP pour
générer la page HTML qui
7-contient le résultat de la
requête.
Architecture d'une application
web J2EE
-3 couches : Les composants, les
modules regroupant les
composants, les applications
regroupant les modules
- Les modules et les applications
correspondent physiquement à des
fichiers d'archives :
-archive EJB JAR (.jar) pour un
module EJB,
- archive WAR pour un module
web,
- archive EAR pour une
application.
Architecture J2EE N-Tiers
 JSP et servlets

❖ Programme Java s’exécutant côté serveur Web

❖ Servlet : programme « autonome » stocké dans un fichier
.class sur le serveur
❖ JSP : programme source Java embarqué dans une page .html
exécutable avec tous les serveurs Web (Apache, IIS,...) ayant
un moteur de servlet/JSP (e.g. Tomcat)

Côté client Côté serveur

.class autonome applet servlet
Embarqué dans .html javascript JSP
 Servlets
❖ Classe java héritant de HttpServlet (ou compilation d’une JSP)
All Implemented Interfaces:
ljava.io.Serializable, Servlet, ServletConfig

❖ public abstract class HttpServlet

lextends GenericServlet

limplements java.io.Serializable

❖ La méthode service définit le code à exécuter.

❖ protected void service(HttpServletRequest req,

HttpServletResponse resp)
❖ void service(ServletRequest req, ServletResponse res)

❖ req représente la requête renseignée par le moteur resp

représente la réponse HTML construite dans la servlet
(”à coup de out.println”)
 JSP
❖ JSP = Java Server Pages

❖ Une JSP est un fichier contenant du code HTML et des

fragments de code Java exécutés sur le moteur de Servlets

❖ Comparable aux langages côté serveur de type PHP, ASP, …

❖ Les pages JSP sont converties en Servlet par le moteur de

Servlets lors du premier appel à la JSP
 Déploiement

❖ WEB-INF : pages Web

❖ descripteur web.xml

❖ lien pages web et code

❖ META-INF : applications, EJB...

❖ manifeste manifest.mf

❖ descripteur application.xml

❖ archives (EAR, JAR)…

❖ Bibliothèques

❖ autres
 Déploiement

lStructure J2EE Enterprise Archive

lLes cases grises représentent les archives ZIP, les cases blanches

représentent les répertoires et les cases rouges arrondies représentent les

descripteurs de déploiement
 MVC
❖ Pattern Modèle/Vue/Contrôleur = séparer les préoccupations du
code
❖ Modèle : cœur de l'application (données et accès, calculs)
❖ Vue : présentation des données
❖ Contrôleur : interaction de l'utilisateur

❖ MVC -J2EE
❖ Modèle : communément représenté par les entity beans, bien
qu'il puisse être crée par un framework de business object tel
Spring
❖ Vue : en J2EE peut être représentée par une JSP(Java Server
Page), implémentable en utilisant une JSF(JavaServer Faces
Technology). Le code de génération de la vue doit être une
partie de la servlet
❖ Contrôleur : dans une application J2EE doit être représenté
par une servlet implémentable en utilisant une JSF
(JavaServer Faces)