Evolution des architectures applicatives 2010/2011
I. Niveau d abstraction d une application Application La couche de présentation La logique applicative Les données
II. Architecture 1 tiers Les trois couches applicatives sont intimement liées et s'exécutent sur le même ordinateur On parle d informatique centralisé Contexte multi utilisateurs : application sur site central (Mainframe) application répartie sur des machines indépendantes communiquant par partage de fichiers.
Application sur Mainframe Les utilisateurs se connectent aux applications exécutées par le serveur central (le mainframe) à l'aide de terminaux passifs C'est le serveur central qui prend en charge l'intégralité des traitements, y compris l'affichage qui est simplement déporté sur des terminaux passifs.
Les applications un tiers déployées Application un tiers sur plusieurs ordinateurs indépendants Plusieurs utilisateurs se partagent des fichiers de données stockés sur un serveur commun Le moteur de base de données est exécuté indépendamment sur chaque poste client Ce type de solution est donc à réserver à des applications non critiques exploitées par de petits groupes de travail
II. Architecture 1 tiers Avantages Mainframe : la fiabilité des solutions sur site central qui gèrent les données de façon centralisée Un tiers déployé : l interface utilisateur moderne des applications. Limites Mainframe : interface utilisateur en mode caractères Un tiers déployé : cohabitation d'applications exploitant des données communes peu fiable au delà d'un certain nombre d'utilisateurs. Conclusion Il a donc fallu trouver une solution conciliant les avantages de cette architecture. Pour se faire, il a fallu scinder les applications en plusieurs parties distinctes et coopérantes : gestion centralisée des données, gestion locale de l'interface utilisateur. Ainsi i est né le concept du client serveur.
III. Architecture 2 tiers Le poste client se contente de déléguer la gestion des données à un service spécialisé L ensemble des traitements applicatifs par le poste client : client lourd La gestion des données est prise en charge par un SGBD centralisé, s'exécutant le plus souvent sur un serveur dédié Ce dernier est interrogé en utilisant un langage de requête qui, le plus souvent, est SQL
III. Architecture 2 tiers Le Middleware Ensemble des couches réseau et services logiciel qui permettent le dialogue entre les différents composants d'une application répartie. L'objectif principal du middleware est d'unifier, pour les applications, l'accès et la manipulation de l'ensemble des services disponibles sur le réseau, afin de rendre l'utilisation de ces derniers presque transparente.
III. Architecture 2 tiers Avantages Interface utilisateur riche Appropriation des applications par l'utilisateur Limitesit Importante charge du poste client, qui supporte la grande majorité des traitements applicatifs Maintenance et mises à jour difficiles à gérer Difficulté de modifier l'architecture initiale
IV. Architecture 3 tiers Les données sont toujours gérées de façon centralisée La présentation ti est toujours prise en charge par le poste client La logique applicative est prise en charge par un serveur intermédiaire Tier 1 Tier 2 Tier 3 Client Serveur applicati f BDD Présentation Logique métier Données
IV. Architecture 3 tiers Tous ces niveaux étant indépendants, ils peuvent être implantés sur des machines différentes, de ce fait : Le poste client ne supporte plus l'ensemble des traitements (client léger) Facilité de déploiement Sécurité : pas d exposition du schéma de la base de données La manipulation des données est indépendante du support physique de stockage Il est relativement simple de faire face à une forte montée en charge, en renforçant le service applicatif.
V. Architecture n tiers
V I. Architecture n tiers web
Couche DAO
Couche Service
Couche de présentation
Séparation des couches: modèle MVC Le modèle MVC (Modèle-Vue-Contrôleur) cherche à séparer nettement les couches présentation, et service. Le traitement d'une demande d'un client se déroule selon les étapes suivantes : 1.Le client fait une demande au contrôleur. Ce contrôleur voit passer toutes les demandes des clients. C'est la porte d'entrée de l'application. C'est le C de MVC. 2.Le contrôleur traite cette demande. Pour ce faire, il peut avoir besoin de l'aide de la couche métier, ce qu'on appelle le modèle M dans la structure MVC. 3.Le contrôleur reçoit une réponse de la couche métier. La demande du client a été traitée. 4.Le contrôleur choisit la réponse (= vue) à envoyer au client. Celle-ci est le plus souvent une page contenant des éléments dynamiques. Le contrôleur fournit ceux-ci à la vue. 5.La vue est envoyée au client. C'est le V de MVC.
NFE 107 : Urbanisation et architecture des systèmes d'information Questions? 2008/2009