AMSI Chapitre 4 Complément sur l architecture des applications - Page 1 / 8 Objectifs et points du référentiel : S15 Architecture des réseaux o Décrire la structure et le fonctionnement d'une configuration réseau. o Identifier et décrire les liaisons entre les différents composants d'un réseau. Type de contenu : Cours Matière : AMSI Niveau : BTS IG DA Création : 01/09/2008 Sommaire I) Niveaux fonctionnels d une application... 2 II) L architecture des applications... 2 1. Architecture à 1-tier (premier niveau ou premier étage)... 2 a) Application 1 : Schema Gartner group... 3 2. Architecture client/serveur 2-tier... 4 3. Architecture à 3-tier... 4 a) Application n 2 (extrait Net-Car BTS IG DA 2003)... 5 b) Application 3... 8
AMSI Chapitre 4 Complément sur l architecture des applications - Page 2 / 8 Une application réalise des fonctions répondant aux besoins des utilisateurs d un système d information. L organisation de ces fonctions et les composants auxquels elles recourent correspondent à l architecture de l application. En fait l architecture d une application correspond à : - une architecture matérielle (type de réseau, poste ) - une architecture logique (organisation de la circulation des données, répartition des traitements.) Dans ce chapitre on ne parlera que de l architecture logique (ou applicative) I) Niveaux fonctionnels d une application On peut séparer les fonctions d une application en trois couches II) L architecture des applications 1. Architecture à 1-tier (premier niveau ou premier étage) Dans une application à 1-tier les trois couches (Présentation- Traitement Données) s exécutent sur une même machine. Deux solutions sont possibles : - architecture 1-tier centralisée : un serveur central gère les trois couches qui sont ensuite exportée vers des terminaux passifs - architecture 1-tier déployée : partage des données via le réseau est envisageable uniquement dans des petits réseaux où le moteur de base de données est exécuté sur chaque poste. L architecture client/serveur est née de la volonté de tirer profit des avantages de chacune des solutions précédentes c est-à-dire la centralisation de la gestion des données sur un serveur (cohérence, sécurité, administration plus facile) et la capacité des postes à mettre en œuvre une interface conviviale et ergonomique
AMSI Chapitre 4 Complément sur l architecture des applications - Page 3 / 8 Le cabinet de consulting Gartner Group a établi une classification des architectures client/serveur a) Application 1 : Schema Gartner group Votre plate-forme technique client-serveur étant opérationnelle, vous avez mis cinq applications à la disposition des utilisateurs. Pour chaque application, donnez le (ou les) numéro(s) correspondant(s) dans le schéma du Gartner Croup. DESCRIPTION DE L'APPLICATION L'application "gestion des élèves" a été développée avec VB.Net. La couche présentation et les traitements sont gérés par un poste de travail sous VISTA. Les données sont stockées dans la base de données Oracle 7. L'application "taxe d'apprentissage" a été développé avec PowerBuilder. La couche présentation et les traitements sont gérés par un poste de travail sous VISTA. Les données et certains traitements sont stockés dans la base de données Oracle 7. L'application "gestion des absences" a été développée avec PowerBuilder. La couche présentation et les traitements sont gérés par un poste de travail sous VISTA. Les données et certains traitements sont stockés dans la base de données Oracle 7. D'autre part, sur chaque poste en local vous disposez du SGBDR SQL Anywhere qui gère également une partie des données. L'application "gestion du budget" a été développée en cobol et est interfacée avec la base de données relationnelle Oracle. Elle dispose d'une interface en mode caractères. La couche présentation, traitement et données sont gérés par le serveur Unix. Certains postes de travail sont équipés avec DOS et l'outil de rhabillage Affinity qui permet de bénéficier d'une interface graphique N DU TYPE C/S 3 4 6 1
AMSI Chapitre 4 Complément sur l architecture des applications - Page 4 / 8 2. Architecture client/serveur 2-tier Dans cette architecture il y a un dialogue à l initiative de machines clientes 1. un utilisateur demande par l intermédiaire de l interface l exécution d une fonctionnalité devant répondre à son besoin 2. les traitements liés à cette fonctionnalité peuvent nécessiter des données qui sont demandées auprès du serveur 3. et 4. le SGBDR obtient les données auprès de la base de données 5. Les données brutes font l objet d un traitement sur le poste client 6. les informations issues du traitement sont affichées Avantages : - la cohérence des données, gérées de façon centralisée - permet de ne pas surcharger le serveur - profite de la puissance des machines clientes Inconvénient : - maintenance lourde sur les postes clients (changement de version de logiciel ) 3. Architecture à 3-tier L architecture 3-tier est une évolution du 2-tier. Par contre les trois couches sont prises en charge par des machines différentes : - le client, qui est chargé de l interface - un serveur d application chargé des traitements et de fournir le service au client - un serveur secondaire qui gère les données Avantages : - les couches sont administrées de façon indépendantes - les postes clients peuvent être plus «léger» (utilisation du navigateur par exemple) - sécurité accrue car indépendance des couches
AMSI Chapitre 4 Complément sur l architecture des applications - Page 5 / 8 a) Application n 2 (extrait Net-Car BTS IG DA 2003) Le système d information de Net-car s appuie sur une base de données installée sur un serveur à Richmond aux États-Unis. Cette base de données rassemble toutes les informations nécessaires à la gestion des agences et des véhicules de l entreprise, quel que soit le pays où se situe l agence. Dans chaque pays, un serveur national héberge une base de données comportant des paramètres nationaux tels que la monnaie, les différentes taxes, les tarifs ce qui permet l établissement de devis chiffrés personnalisés. Lors d une demande de réservation d un véhicule, le demandeur accède au serveur web installé à Richmond qui lui retourne un formulaire. Le demandeur saisit son identité, l agence où le véhicule sera enlevé, l agence où le véhicule sera remis, les dates de location et la catégorie de véhicule souhaitée. À réception des données saisies dans le formulaire, le serveur web : interroge le serveur de base de données de Richmond pour vérifier si la catégorie de véhicule souhaitée existe bien dans l agence de départ (par exemple, les utilitaires de 30 m 3 ne se trouvent que dans certaines agences) ; envoie une requête vers le serveur de la base de données nationale concernée, pour obtenir le coût de la location. Les réponses obtenues permettent alors au serveur web de Richmond de retourner au client la confirmation de sa réservation (annexe 1). Travail à faire - Proposer un schéma simplifié du processus de réservation en représentant les sites, les composants logiques (serveurs et client) et les différents flux (complétez annexe 2) - La base de données de Richmond est hébergée par un serveur disposant d un disque de grande capacité. Proposer une solution pour assurer la sécurité des données en prévention d une éventuelle panne du disque - Le serveur web de Richmond interroge le serveur de bases de données local. Citer les composants logiciels dont il faut disposer sur le serveur de Richmond pour réaliser et transmettre la page présentée en annexe 1 Annexe 1 Confirmation par Net-car de la réservation du client occasionnel
AMSI Chapitre 4 Complément sur l architecture des applications - Page 6 / 8 Corrigé TRAVAIL À FAIRE 2.1 Proposer un schéma simplifié du processus de réservation en représentant les sites, les composants logiques (serveurs et client) et les différents flux. France Richmond BD nationale BD SGBDR SGBDR Requête tarif Données clients Données agences, catégorie véhicules, clients Tarif Autre pays Serveur Web - serveur internet - php/ asp BD nationale SGBDR Internet FAI Pages HTML Données formulaires Client en France
AMSI Chapitre 4 Complément sur l architecture des applications - Page 7 / 8 TRAVAIL À FAIRE 2.2 La base de données de Richmond est hébergée par un serveur disposant d un disque de grande capacité. Proposer une solution pour assurer la sécurité des données en prévention d une éventuelle panne du disque. Pour assurer la tolérance aux pannes et la disponibilité 24h sur 24, on proposera l utilisation de disques durs à technologie RAID. Pour information : Attribué à l université de Berkeley, le principe du RAID (Redundant Array of Inexpensive Disks ou ensemble de disques bon marché) a aujourd hui une quinzaine d années. A l époque où un volume de quelques centaines de mégaoctets valait le prix d une voiture, cette astuce trouvait tout son sens. Aujourd hui le principe reste d actualité pour la vitesse comme pour la sécurité. Cette technologie repose en effet sur deux grands principes : la redondance, qui consiste à dupliquer les données pour en avoir un double en cas de panne, et le découpage, un mode d enregistrement qui répartit les segments de données sur plusieurs disques pour accélérer les chargements. Quand des périphériques RAID répondent à un besoin d accessibilité permanente des données, ils sont conçus pour autoriser leur remplacement en cas d avarie sans mise hors tension de l unité centrale qui les accueille. Il existe diverses combinaisons appelées «niveau de RAID», numérotées de 0 à 5. TRAVAIL À FAIRE 2.3 Le serveur web de Richmond interroge le serveur de bases de données local. Citer les composants logiciels dont il faut disposer sur le serveur de Richmond pour réaliser et transmettre la page présentée en annexe 1. Pour que le serveur web exécute des requêtes et construise des pages web dynamiques, plusieurs solutions sont envisageables : 1) Solution de type CGI, utilisation d un langage de programmation (C, Perl, ). 2) Solution de type script (ASP, PHP); présence d un moteur d interprétation des scripts. 3) Solution utilisant des architectures intégrées : J2EE,.NET, présence d un serveur d applications.
AMSI Chapitre 4 Complément sur l architecture des applications - Page 8 / 8 b) Application 3 Système non centralisé, peu de sécurité, difficile à administrer) Présentation-traitementdonnées) Technicité, coût élevé, le point faible le serveur Poste client léger, portabilité, serveurs spécialisés, sécurisation sur chacune des couches, maintenance facilitée par l indépendance des couches