Téléchargé parHeithem Abbes
Architectures 3-tiers (Web)
Le document décrit l'évolution des architectures informatiques de 2-tiers à 3-tiers, mettant en lumière les limitations des systèmes 2-tiers comme la lourdeur du client et la complexité de la maintenance. L'architecture 3-tiers sépare l'application en trois niveaux pour améliorer la légèreté du client et faciliter la communication via un navigateur web. Les technologies web, tant côté client que côté serveur, sont également explorées, soulignant les avantages et les inconvénients de cette architecture.
Contenu connexe
Similaire à Architectures 3-tiers (Web)
Architectures 3-tiers (Web)
- 1.
- 2. De l’arch. 2-tiersaux 3-tiers 2 Limites des arch. 2-tiers Charge importante du poste client qui réalise l'ensemble des traitements applicatifs Maintenance et mises à jour difficiles à gérer Conversation entre client et serveur est assez bruyante Ces limites proviennent de type du client : client lourd Frontal complexe et non standard (Windows, Linux, Mac,…) Middleware entre client et serveur n'est pas standard Solution : utilisation d'un poste client simple communicant avec le serveur par le biais d'un protocole standard
- 3. Présentation de l’arch.3-tiers 3 L'arch. 3-tiers, ou C/S de 2ème génération, sépare l'application en 3 niveaux Niveau 1 : l'affichage et les traitements locaux (contrôles de saisie, mise en forme de données... ) sont pris en charge par le poste client Niveau 2 : les traitements applicatifs globaux sont pris en charge par le service applicatif : serveur d’application Niveau 3 : les services de base de données sont pris en charge le serveur de données Traitements globaux Présentati on Traitemen ts locaux Données Niveau 1 Niveau 2 Niveau 3
- 4.
- 5.
- 6. Client léger 6 Dansl’arch 3-tiers le client est léger, prend en charge présentation de l'application traitements locaux permettant une vérification immédiate de la saisie et la mise en forme des données Les évolutions de l'application ne nécessitent pas la modification de la partie cliente Éviter l'installation des applications sur le poste utilisateur Utiliser un navigateur web Communiquer avec le serveur d’application via une façade web
- 7. Niveau web dansl’arch. 3-tiers 11 Le poste client prend la forme d'un navigateur Web Le serveur d’application nécessite une couche web, appelé serveur web, pour communiquer avec le navigateur Fonctionnement Le serveur web transmet au client, lui ayant fait une demande HTTP via URL , les fichiers statiques présents sur son disque dur (pages HTML , images, fichiers CSS,...) Lorsque le client demande un traitement, page dynamique, le serveur web aiguille cette demande vers la couche applicative dans le serveur d'application Une fois le traitement effectué, le serveur d'application renvoie la page HTML au serveur web qui se charge de la router vers le client Remarque : Le marché des serveurs web est dominé par Apache
- 8. Niveau web dansl’arch. 3-tiers 12
- 9.
- 10. Les technologies web: coté client14 Javascript Langage Interprété, orienté objet Code s’insère dans le code HTML Gère les évènements principaux de la souris et la saisie au clavier Code envoyé au client, puis interprété Applets Langage java Ensemble de fichiers .class Le code est exécuté dans une JVM ActiveX Composants Microsoft Fichiers stockés sur disque dur (.VBX, .OCX, .DLL, .EXE) Créés avec Visual basic, Delphi ou C++
- 11. CGI (CommonGateway Interface) Technologie la plus ancienne Tout langage possible Langage Perl le plus utilisé C, C++, Fortran, etc... Servlets Classes Java Exécutés par un moteur de servlet (Tomcat ou Jetty) La classe doit générer tout le code html Les technologies web : coté serveur
- 12. JSP (JavaServer Pages) Technologie Java Langage de scripts Fichier .jsp remplaçant les fichiers .html Combine l’utilisation d’html et de java ASP (Active Server Pages) Technologie Microsoft Même principe que JSP PHP Langage de scripts Orienté Objet S’intègre au code HTML Les technologies web : coté serveur
- 13. Synthèse 17 Avantages Déploiementimmédiat Evolutions transparentes pour l'utilisateur Caractéristiques du poste client libres Limites Le serveur d’application réalise la majorité des traitements Problème de gestion de la montée en charge
Notes de l'éditeur
- #3 Il est coûteux et contraignant de réaliser l'ensemble des traitements applicatifs et de les maintenir par le poste client. Il n’est pas possible de soulager la charge du poste client, qui supporte la grande majorité des traitements applicatifs Le poste client doit installer une application assez complexe La conversation entre client et serveur est assez bruyante et s'adapte mal à des bandes passantes étroites. Ce type d’architecture est souvent réservé au réseau local de l'entreprise
- #4 ou C/S distribué
- #7 Aucune connaissance des traitements applicatifs globaux ou de la structure des données exploitées Client léger ou Thin client
- #8 Prend en charge l'ensemble des fonctionnalités de l’application Gestion des connexions des utilisateurs Gestion des montées en charge et reprise sur incident Connexion à la base de données
- #9 À modifier !!! Voir d’autres fonctionnalités La plupart des serveurs d'application génèrent un identifiant unique pour chaque nouveau client et transmettent cet identifiant lors de chaque échange HTTP par URL longs, variables cachées ou cookies. (même si dans la grande majorité des cas, on se contente d'une gestion des montées en charge au niveau réseau - boîtier de répartition, DNS round-robin, reverse proxy...). On s'attend également à ce qu'il fournisse des mécanismes performants tels que le pooling de connexion base de données.
- #10 Architecture standardisée, facile à comprendre pour l’extérieur portabilité : peut passer d’un serveur d’applications J2EE à un autre sans problèmes Inconvénients : le code doit être écrit en Java la portabilité entre serveurs d’application J2EE n’est pas totale
- #11 Avantage: unité, cohérence plusieurs langages possibles : C#, Visual Basic, F#, J#, etc. compilés dans un langage commun : “Common Language Infrastructure” qui est ensuite compilé en langage machine ASP.NET permet de créer des pages Web dynamiques
- #12 Le marché des serveurs Web est largement dominé par Apache Une fois, le traitement effectué, le serveur d'application renvoie la page HTML (ou autre format) au serveur Web qui se charge de la router vers le client.
- #13 Animer cette figure
- #14 Modifier cette figure !!!
- #15 Dans JavaScript, j’ai remplacé Page par Code (1 fichier .class par classe définie) Appel de l’applet dans le code HTML <APPLET CODE= … > </APPLET>
- #16 Jetty est utilisé dans Google App Engine Lien entre serveur et machine virtuelle Exécuté par un moteur de servlet (Tomcat) CGI : Programme sur le serveur (précompilé) Placé dans un répertoire particulier étendre les classes javax.servlet.GenericServlet javax.servlet.http.HttpServlet
- #17 Avantage Accès bases de données Composants Java (servlets, JavaBeans) Réutilisabilité PHP Langage de scripts Orienté Objet S’intègre au code HTML Permet un accès facile aux bases de données
- #18 Les contraintes semblent inversées par rapport à celles rencontrées avec les architectures deux tiers : le client est soulagé, mais le serveur est fortement sollicité. Le phénoméne fait penser à un retour de balancier. et il est difficile de répartir la charge entre client et serveur