Architecture N-Tiers

Chapitre 1: Conception architecturale Dr. Ghada Besbes

Systèmes d’information

• Un système d’information est constitué d’un ensemble

d’outils destinés à gérer, stocker et traiter des flux d’information.

• Un « Post-it » laissé par une secrétaire sur le bureau de son directeur pour lui transmettre un message est considéré comme un système d’information.

• L’informatique n’est qu’un outil mis à disposition des

organisations afin de compléter d’améliorer le système d’information déjà en place.

Systèmes d’information

• L’informatique tend au fur et à mesure des années à devenir le principal outil incontournable d’un système d’information.

• Les applications et programmes informatiques évoluent

désormais dans plusieurs domaines d’activité : comptabilité, administration, chaine de montage, etc...

• Progressivement, les applications mises en place se

regroupent au sein d’applications de plus en plus importantes.

• L’objectif étant à terme d’obtenir une seule et même

application qui gère l’ensemble du système d’informations dans l’ensemble des secteurs d’activité d’une entreprise ou organisation.

Systèmes d’information

• Avec l’évolution des technologies, les applications ont

progressivement évolué, les attentes des utilisateurs et des clients également.

• Autrefois, les entreprises privilégiaient le fonctionnel à l’esthétique, la popularité du système monolithique (Mainframe) AS/400 en est un très bel exemple. • Cet outil à la fois simple et extrêmement complet d’un point de

vue fonctionnel ne doit pas sa renommée à son interface graphique (texte blanc sur fond noir avec des menus uniquement textuels).

• Il serait aujourd’hui impensable de mettre en place un outil semblable à l’AS/400 au coeur d’un système d’information.

Définition Architecture

• … la structure des composants d’un programme/système, leurs

interrelations et les principes et lignes directrices gouvernant leur conception et leur évolution au fil du temps.” [Garlan, 1995]

La définition de l’architecture logicielle consiste à: • Décrire l’organisation générale d’un système et sa décomposition en

sous-systèmes ou composants

• Déterminer les interfaces entre les sous-systèmes • Décrire les interactions et le contrôle entre les sous systèmes • Décrire les composants utilisés pour implanter les fonctionnalités

des sous-systèmes • Les propriétés de ces composants • Leur contenu (e.g., classes, autres composants) • Les machines ou dispositifs matériels sur lesquels ces modules seront

déployés

Définition Architecture

• Pourquoi développer une architecture logicielle ?

• Pour permettre à tous de mieux comprendre le système • Pour permettre aux développeurs de travailler sur des parties

individuelles du système en isolation • Pour préparer les extensions du système • Pour faciliter la réutilisation

Niveaux d’abstraction

• Traditionnellement une application informatique est un

programme exécutable sur une machine qui représente la logique de traitement des données manipulées par l’application.

• Ces données peuvent être saisies interactivement via

l’interface ou lues depuis un disque.

• L’application émet un résultat sous forme de données qui

sont, soit affichées, soit enregistrées sur un disque.

• Dans ce schéma, les traitements, les données d’entrées, les

données de sortie sont sur une seule machine.

Niveaux d’abstraction

• Une application informatique peut être découpée en trois

niveaux d'abstraction distincts :

• Présentation

• Logique applicative

• Données

Niveaux d’abstraction

La couche interface homme machine (IHM) ou présentation: permet l'interaction de l'application avec l'utilisateur. Cette couche gère les saisies au clavier, à la souris et la présentation des informations à l'écran. Dans la mesure du possible, elle doit être conviviale et ergonomique. La couche de traitement ou la logique applicative: décrit les travaux à réaliser par l'application. Ils peuvent être découpés en deux familles:

• Les traitements locaux, qui sont les contrôles effectués au niveau du dialogue avec l'IHM. Ils assurent la cohérence des informations entre la couche présentation et les traitements globaux.

• les traitements globaux, constituant l'application elle-même . Cette

couche, appelée Business Logic ou couche métier, contient les règles internes qui régissent une application donnée.

Niveaux d’abstraction

La couche de gestion des données ou plus exactement l'accès aux données, regroupant l'ensemble des mécanismes permettant la gestion des informations stockées par l'application.

• Fonctions classiques d’un SGBD :

• Définition de données • Manipulation de données • Sécurité de données • Gestion de transactions • etc. ..

• Et toute application possède ces trois parties ou niveaux

d'abstraction distincts

• Le découpage et la répartition d'une application en différentes parties permettent de distinguer les architectures applicatives différentes.

Systèmes répartis

• Dans un système reparti, l'application est divisée en plusieurs

morceaux où chacun effectue un traitement donnée.

• Possibilité de dupliquer un morceau pour offrir une meilleure

robustesse (fiabilité) du système

• Chaque morceau de l'application repartie peut être développé dans un langage de programmation différent et être exécuté depuis un système d'exploitation différent.

Evolution des systèmes d’information

• Les applications composées d’un exécutable à lancer ont

progressivement laissé la place à des applications accessibles à partir d’un réseau par l’intermédiaire d’un navigateur Web.

• Cette évolution est due en partie aux évolutions

technologiques mais aussi grâce à la simplicité de de mise à jour de l’application : • Il est plus simple de mettre à jour un serveur unique avec une

interface Web que de compiler un programme et de le déployer sur l’ensemble des postes du réseau.

• Chaque utilisateur peut accéder à l’application à partir de

n’importe quel PC connecté au réseau doté d’un navigateur Web alors qu’il aurait été nécessaire autrefois d’avoir un poste de travail configuré avec l’application préalablement installée.

Vision : historique des architectures • Architecture 1 tiers • Architectures Client-Serveur

• 2- tiers • 3- tiers • N-tiers

• Architectures à Base de Composants • Architectures Orientées Services

ARCHITECTURE 1-TIERS

Architecture 1 tiers

• Jusqu’au années 90, ces trois couches étaient la plupart du

temps sur la même machine.

• Dans une application un tiers, les trois couches applicatives

sont intimement liées et s'exécutent sur le même ordinateur.

• L’application utilisait les disques de la machine pour lire les données a traiter et stocker les données résultantes du traitement .

Architecture 1 tiers

• Dans un contexte multi-utilisateurs, on peut rencontrer deux types

d'architecture mettant en œuvre des applications un tiers : • des applications sur site central, • des applications réparties sur des machines indépendantes

communiquant par partage de fichiers.

Les solutions sur site central (mainframe)

1. • Historiquement, les applications sur site central sont les premières à

proposer un accès multiutilisateurs.

• Dans ce contexte, les utilisateurs se connectent aux applications

exécutées par le serveur central (le mainframe) à l'aide de terminaux passifs se comportant en esclaves et n’effectuent la moindre tâche.

• 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.

Architecture 1 tiers

Les applications un tiers réparties

2. • Avec l'arrivée dans l'entreprise des premiers PC en réseau, il est devenu possible de déployer une application un tiers sur plusieurs ordinateurs indépendants.

• Ce type d'application peut être très satisfaisant pour répondre aux besoins d'un utilisateur isolé et sa mise en oeuvre dans un environnement multi-utilisateur est envisageable: • 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.

• La gestion des conflits d'accès aux données doit être prise en charge par chaque programme de façon indépendante, ce qui n'est pas toujours évident.

Architecture 1 tiers

Les applications un tiers réparties

2. • Dans ce contexte, 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.

• Lors de l'exécution d'une requête, l'intégralité des données

nécessaires doit transiter sur le réseau  saturation du réseau.

• La cohabitation de plusieurs moteurs de base de données

indépendants manipulant les mêmes données peut devenir instable: • Possibilité d’avoir des conflits lors de la consultation ou de la

modification simultanée d'un même enregistrement par plusieurs utilisateurs.

• Les conflits peuvent altérer l'intégrité des données. • Il est difficile d'assurer la confidentialité des données.

Architecture 1 tiers

Architecture d'une application sur site central

Architecture 1 tiers

• Avantages:

• Grande facilité d'administration • Haute disponibilité. • La centralisation de la puissance sur une seule et même machine

permet une utilisation optimale des ressources

Architecture 1 tiers

• Inconvénients

• L’augmentation du nombre d’utilisateurs pose des problèmes de

gestion des conflits d'accès aux données ou la modification simultanée d'un même enregistrement par plusieurs utilisateurs. Ces conflits peuvent altérer l'intégrité des données

• L’explosion de la volumétrie des données rend leur gestion

difficile

• il est difficile d'assurer la confidentialité des données • En regroupant tous les traitements on groupe également toutes

les sources d'erreur

• Ce type de solution est donc à réserver à des applications non

critiques exploitées par de petits groupes de travail (une dizaine de personnes au maximum).

Architecture 1 tiers

• Solution • Trouver une solution regroupant :

• La fiabilité de l’application sur site central, qui gèrent les données

de façon centralisée,

• L'interface utilisateur moderne des applications sur différents

ordinateurs.

• Il est nécessaire de scinder l’application en plusieurs

parties distinctes et coopérantes : • Gestion centralisée des données • Gestion locale de l'interface utilisateur

Naissance du concept du client/serveur.

ARCHITECTURES CLIENT-SERVEUR

Architecture client-serveur

• Dans le cas d'un système reparti, l'application est divisée en plusieurs morceaux où chaque morceau joue un rôle différent pour les traitements du SI.

• L'environnement client-serveur désigne un mode de

communication à travers un réseau entre plusieurs programmes ou logiciels : l'un, qualifié de client, envoie des requêtes ; l'autre ou les autres, qualifiés de serveurs, attendent les requêtes des clients et y répondent.

Architecture client-serveur

• Le modèle client-serveur met en oeuvre une conversation entre deux programmes que l'on peut opposer à l'échange figé « maître-esclave » qu'entretiennent les applications sur site central avec leurs terminaux passifs.

• Dans une conversation client-serveur, on distingue donc les

deux parties suivantes : • Le client, c'est le programme qui provoque le dialogue, • Le serveur, c'est le programme qui se contente de répondre au

client.

Types de clients

• Client lourd (fat client): désigne une application cliente graphique exécutée sur le système d'exploitation de l'utilisateur. Un client lourd possède généralement des capacités de traitement évoluées et peut posséder une interface graphique sophistiquée. Néanmoins, ceci demande un effort de développement et tend à mêler la logique de présentation (l'interface graphique) avec la logique applicative (les traitements).

• Client leger (thin client): ne prend en charge que la

présentation de l'application avec, éventuellement, une partie de logique applicative permettant une vérification immédiate de la saisie et la mise en forme des données. Il est souvent constitué d'un simple navigateur web.

Types de clients

• Les clients lourds sont des logiciels destinés à être installés

localement sur une machine en opposition aux clients légers qui s'exécutent par exemple dans un navigateur internet, mais nécessitent un serveur.

• À titre indicatif, Google Maps constitue un client léger

puisque tout s’exécute sur un serveur et est affiché dans votre navigateur internet.

• Google Earth est pour sa part un client lourd puisqu’une

version doit être installée manuellement sur votre ordinateur.

Couplage

• Le couplage est une métrique indiquant le niveau d'interaction

et de dépendance entre deux ou plusieurs composants logiciels (fonctions, modules, objets ou applications). • Deux composants sont dits couplés s'ils échangent de

l'information et sont dépendants l’un de l’autre.

• Couplage fort: si les composants échangent beaucoup

d'information. • On ne peut pas déterminer le qui, le quoi et le comment d’une modification de données donc ça pose des problèmes lors du développement et la maintenance. A éviter autant que possible • Exemple: Architecture « peer-to-peer » (tous les processus ont le

même rôle)

Couplage

• Couplage faible: si les composants échangent peu

d'information. • Pas d’inter-dépendance entre les composants de l’application • Permet de maîtriser la complexité de l’architecture pour le

développement, le test et la maintenance

• Exemples: Architectures 3-tiers, n-tiers

• Couplage très faible: Les composants sont remplaçables, conçus en indépendance, avec des technologies diverses • Un composant est facilement remplaçable par un autre rendant

les mêmes services

• La construction par assemblage permet de faciliter la

maintenance

• Exemple: architecture orientée services

Architecture client-serveur

• Le modèle client-serveur mono-serveur

• les clients demandent des services en mode « message » • le serveur connecté offre le service demandé. Si le service

demandé n’est pas local, le serveur demande à son tour le service en question en mode « message ». Dans ce cas, le serveur devient un client.

Architecture client-serveur

• Le modèle client-serveur multi-serveur • les clients demandent un service en mode « message » • un service est assuré par un serveur ou par multi-serveurs

Architecture client-serveur

• Le client est le programme qui demande l’utilisation des

ressources d’un serveur

• Par extension, le client désigne également l'ordinateur sur

lequel est exécuté le logiciel client, et le serveur, l'ordinateur sur lequel est exécuté le logiciel serveur.

• En général:

• Les serveurs sont des ordinateurs dédiés au logiciel serveur qu'ils

abritent, et dotés de capacités supérieures à celles des ordinateurs personnels en ce qui concerne la puissance de calcul, les entrées- sorties et les connexions réseau.

• Les clients sont souvent des ordinateurs personnels ou des appareils individuels (téléphone, tablette), mais pas systématiquement. Un serveur peut répondre aux requêtes d'un grand nombre de clients.

Architecture client-serveur

• Il existe une grande variété de logiciels serveurs et de logiciels

clients en fonction des besoins à servir : • un serveur web publie des pages web demandées par

des navigateurs web

• un serveur de messagerie électronique envoie des mails à des clients

de messagerie

• un serveur de fichiers permet de stocker et consulter des fichiers sur

le réseau

• Le client et le serveur doivent bien sûr utiliser le même protocole de communication au niveau de la couche transport du modèle OSI. Un serveur est généralement capable de servir plusieurs clients simultanément.

Middleware

• Définition • Le dialogue entre le client et le serveur s’effectue à l’aide d’un

ensemble de mécanismes assurant la communication

• On appelle intergiciel ou middleware, littéralement « élément

du milieu», un logiciel servant d'intermédiaire de communication entre plusieurs applications, généralement complexes ou distribuées sur un réseau informatique.

• Les composants logiciels du middleware assurent la

communication entre les applications quels que soient les ordinateurs impliqués et quelles que soient les caractéristiques matérielles et logicielles des réseaux informatiques, des protocoles réseau, des systèmes d'exploitation impliqués.

Middleware

• Pour former une application à part entière les tiers doivent être reliés entre eux. Les différents serveurs sont regroupés par un réseau. Afin d'effectuer la liaison entre les différentes parties du logiciel tout en rendant le réseau et les systèmes d’exploitation des différents machines transparents aux utilisateurs, on utilise un middleware.

• Le terme middleware est utilisé pour décrire des logiciels qui

servent de colle entre les deux applications.

• Il peut être ressemblé à la plomberie parce qu'il relie deux

côtés d'une application et transmet les données entre elles.

Middleware

• Objectif:

• 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 transparente

• Offre des API (Application Programming Interface) de haut niveau

• Permettant de masquer la complexité des échanges inter-

applications

• Facilite le développement d'une application client-serveur

Middleware

Services • Un middleware rend les services suivants:

• Conversion : Service utilisé pour la communication entre machines

mettant en oeuvre des formats de données différents

• Adressage : Permet d'identifier la machine serveur sur laquelle est localisé le service demandé afin d'en déduire le chemin d'accès. • Sécurité : Permet de garantir la confidentialité et la sécurité des

données à l'aide de mécanismes d'authentification et de cryptage des informations.

• Communication : Permet la transmission des messages entre les

deux systèmes sans altération. Ce service doit gérer la connexion au serveur, la préparation de l'exécution des requêtes, la récupération des résultats et la déconnexion de l'utilisateur.

• Le middleware masque la complexité des échanges inter-

applications. Sans ce mécanisme, la programmation d'une application client-serveur serait extrêmement complexe et rigide.

Middleware

Exemples de middleware • Les middleware qui lient un système de base de données à un

serveur Web. Cela permet aux utilisateurs de demander les données de la base de données en utilisant des formulaires affichées sur un navigateur Web.

• Le middleware permet au serveur Web de retourner des pages Web dynamiques basées sur les demandes et le profil de l'utilisateur: • SQL*Net : Interface propriétaire permettant de faire dialoguer une application cliente avec une base de données Oracle. Ce dialogue peut aussi bien être le passage de requêtes SQL que l'appel de procédures stockées.

• ODBC (Open DataBase Connectivity): Indépendant d ’un SGBD.

Interface standardisée isolant l’application informatique du serveur de données. Il est mis en œuvre par Microsoft pour les systèmes d'exploitation Windows, Unix et la plateforme Java.

• API JDBC: de Java avec des drivers écrits en Java

Middleware

Exemples de middleware • Le middleware joue un grand rôle dans la structuration du

système d'information.

• Les middleware proposés par les fournisseurs de SGBD sont très performants et permettent de tirer profit de l'ensemble des fonctionnalités du serveur de données pour lequel ils ont été conçus. Par contre, ils ne permettent pas, le plus souvent, l'accès à d'autres sources de données.

Middleware

Types de middleware • On distingue en général trois types de middleware différents:

• Les middlewares orientés message ou MOM • Les middlewares orienté transaction ou MOT • Les middlewares orientés objet ou MOO

Middleware

• Le MOM • Il permet d'échanger des messages entre un client et un serveur au moyen d’une file d'attente de messages. Les applications communiquent sur le réseau en disposant et en retirant des messages dans des files d'attentes.

• C'est un middleware qui fait abstraction de la couche

communication. Il autorise des exécutions désynchronisées des applications et n'impose pas de connexions instantanée entre elles. Une file d'attente reçoit le message de l'application émettrice et le stocke jusqu'à ce que l'application réceptrice vienne lire le message.

• Ce type de middleware est particulièrement adaptés aux

situations où une connexion entre client et serveur n'est pas souhaitable pour des raisons de sécurités ou d'efficacité.

Middleware

• Le MOM • Ils offrent deux modes de communications:

Le modèle point à point: une application produit des messages et une application les consomme. Les messages ne sont lus que par un seul consommateur. Une fois qu'un message est lu, il est retiré de la file d'attente. Le modèle Publish & Subscribe: un sujet est associé à chaque message. L’emetteur transmet le message à un agent intermédiaire. Les serveurs sont abonnées auprès de cet agent en fonction des sujets qui les intéresse. L'agent transmet le message à tous les serveurs "intéressés" par le sujet.

• Avec ce type de middleware les applications transmettent les

messages à des destinations, qui sont des files d'attente. Elles n'ont pas connaissance de la localisation physique de ces destinations ni des noms des applications. Un message peut être transmis à plusieurs destinataires.

• Plusieurs MOM existent sur le marché comme MQSeries d'IBM ou

MessageQ de BEA.

Middleware

• Le MOT • On appelle transaction ou unité de travail une suite d'actions qui changent l'état d’un système d’une manière contrôlée. Il n'y a pas de demi-mesure, soit le travail a été effectué soit non. Si pour une raison quelconque la transaction n'a pu se terminer, on replace le système dans son état de départ. Une transaction a un début et une fin que l'on doit obligatoirement atteindre pour que les modifications soient validées.

• Un MOT prend en charge l’exécution d'une application et la vérification de son bon fonctionnement en intégrant des mécanismes transactionnels.

Middleware

• Le MOT • Les MOT permettent au programmeur de ne pas s'occuper des

problèmes de simultanéités d'accès, de défaillance du système, de ruptures de connexions. Ils fournissent le moteur pour faire tourner les applications au dessus des systèmes d’exploitation et du matériel. Ils assurent une cohérence transactionnelles et facilitent le découpage des applications en services.

• Il existe différents moniteurs transactionnels comme Tuxedo

de BEA ou CIS d'IBM

Middleware

• Le MOO • Pour permettre à différentes applications de communiquer

entre elles, il faut des règles et des formats communs d'appels de services: ils sont assurés par les MOO.

• Les MOO permettent aux différents objets de communiquer

entre eux car les composants peuvent être de nature différentes, sur des machines différentes, ayant des systèmes d’exploitation différents. Ils peuvent aussi avoir été conçu dans des langages différents.

• Ils existe trois modèles de composants objets qui sont

complémentaires et interopérable. Il s'agit du modèle CORBA, des composant Java EJB et enfin de DCOM de Microsoft.

Le modèle de Gartner Group

Fig. Les différents types de client-serveur selon la classification du Gartner Group

* Le trait horizontal représente le réseau

Le modèle de Gartner Group

• Présentation distribuée : Partie présentation est partagée par le client et le serveur. Tout le reste est attribué au serveur.

• La classification « client-serveur » de ce type

est souvent jugée abusive, du fait que l'intégralité des traitements originaux est conservée et que le poste client conserve une position d'esclave par rapport au serveur.

Le modèle de Gartner Group

• Présentation distante : Encore appelée

client-serveur de présentation. L'ensemble des traitements est exécuté par le serveur, le client ne prend en charge que l'affichage.

• Ce type d'application présentait jusqu'à présent l'inconvénient de ne permettre aucune répartition de la charge entre client et serveur.

Le modèle de Gartner Group

• Gestion distante des données : Correspond au client-serveur de données, sans doute le type de client-serveur le plus répandu.

• L'application fonctionne dans sa totalité sur le client, la gestion des données et le contrôle de leur intégrité sont assurés par un SGBD centralisé.

• Cette architecture, de part sa souplesse,

s'adapte très bien aux applications interrogeant souvent la base de données. Il ne soulage pas énormément le poste client, qui réalise encore la grande majorité des traitements.

Le modèle de Gartner Group

• Traitement distribué : Correspond au client- serveur de traitements. Les traitements sont distribués entre le client et le serveur. • Il s'appuie sur un mécanisme d'appel de

procédure distante, et la notion de procédure stockée proposée par les principaux SGBD du marché.

• Cette architecture permet d'optimiser la

répartition de la charge de traitement entre machines et limite le trafic réseau.

• Par contre il n'offre pas la même souplesse que

le client/serveur de données puisque les traitements doivent être connus du serveur à l'avance.

Le modèle de Gartner Group

• Bases de données distribuées : Il s'agit d'une variante du client-serveur de données dans laquelle une partie de données est prise en charge par le client.

• Ce modèle est intéressant si l'application doit gérer de gros volumes de données, si l'on souhaite disposer de temps d'accès très rapides sur certaines données ou pour répondre à de fortes contraintes de confidentialité.

• Ce modèle est aussi puissant que complexe à

mettre en œuvre.

Le modèle de Gartner Group

• Données et traitements distribués: répartir la charge des données et des traitements entre le client et le serveur.

• Ce modèle est très puissant et tire partie de la notion de composants réutilisables et distribuables pour répartir au mieux la charge entre client et serveur.

• C'est, bien entendu, l'architecture la plus

complexe à mettre en œuvre.

Le modèle de Gartner Group

• Les solutions que nous venons de détailler sont

indépendantes les unes des autres

• Prises individuellement, on peut dire que les deux premières solutions proposées ne correspondent pas à des applications client-serveur. (Les traitements et la gestion des données sont réalisées par le serveur)

• En effet, la présentation distribuée ne considère pas le client en tant que tel et ce dernier reste dans une position d'esclave par rapport au serveur.

• La première solution à mettre en œuvre une relation client- serveur se retrouve au troisième niveau et correspond au client-serveur de données.

• Ce type d'application, encore appelé client-serveur de

première génération, met en œuvre une architecture 2-tiers.

Architecture 2 tiers

• Dans une architecture deux tiers, encore appelée client-

serveur de première génération ou client-serveur de données, le poste client se contente de déléguer la gestion des données à un service spécialisé.

• Le cas typique de cette architecture est l'application de

gestion fonctionnant sous Ms-Windows et exploitant un SGBD centralisé s'exécutant le plus souvent sur un serveur dédié pour la gestion des données

Architecture 2 tiers

• Ce dernier est interrogé en utilisant un langage de requête qui, le plus souvent, est SQL. Le dialogue entre client et serveur se résume donc à l'envoi de requêtes et au retour des données correspondant aux requêtes. Ce dialogue nécessite l'instauration d'une communication entre client et serveur. • Ce type d'application permet de tirer profit de la puissance

des ordinateurs déployés en réseau pour fournir à l'utilisateur une interface riche, tout en garantissant la cohérence des données, qui restent gérées de façon centralisée.

Architecture 2 tiers

• Le client provoque l'établissement d'une conversation afin de d'obtenir des données ou un résultat de la part du serveur.

• Cet échange de messages transite à travers le réseau reliant

les deux machines. Il met en œuvre des mécanismes relativement complexes qui sont, en général, pris en charge par un middleware.

Architecture 2 tiers

Avantages: • Maintenance et administration du serveur simplifiées • Souplesse : possibilité d’ajouter/suprimer dynamiquement des

clients sans perturber le fonctionnement de l’application

• Les ressources sont centralisées sur le serveur • Sécurisation simple des données : un seul point d’entrée • Pas de problème d’intégrité/cohérence des données Limitations: • On ne peut pas soulager la charge du poste client, qui

supporte la grande majorité des traitements applicatifs (client lourd)

• Coût élevé : le serveur doit être très performant pour honorer

tous les clients

Architecture 2 tiers

• Exemples d’ applications du système client-serveur • Opération transactionnelle par OLTP (On Line Transaction Processing): Elle permet d’effectuer une transaction, une transaction bancaire par exemple. Les principales composants sont des accès à la base de données, des traitements et des modifications et des affichages en mode graphique.

• Aide à la décision par DS (Decision Support), la gestion des lignes Air France, par exemple. Les principales composants sont des accès à BD, des traitements de synthèse et de décision et des affichages.

• ….

Architecture 2-tiers

• Les limites de l'architecture deux tiers proviennent en grande partie de la nature du client utilisé : le frontal est complexe et non standard (même s'il s'agit presque toujours d'un PC sous Windows),

• La solution résiderait donc dans l'utilisation d'un poste client

simple communicant avec le serveur par le biais d'un protocole standard.

• Dans ce but, l'architecture trois tiers applique les principes

suivants : • la présentation est toujours prise en charge par le poste client, • la logique applicative est prise en charge par un serveur

intermédiaire.

• les données sont toujours gérées de façon centralisée,