| | | | |
| --- | --- | --- | --- |
| Institut Sup rieur des Etudes Technologiques de Bizerte D partement Technologies de linformatique | | | |
| Parcours : | D veloppement des Syst me dInformations | | |
| Unit dEnseignement : | Environnement de D veloppement | | |
| Mati re : Architecture Logicielle | | | |
| Enseignants Responsables : Khaoula Jridi &Hatem Hamdi | | Ann e Universitaire : 2015-2016 | Semestre : 5 |
Chapitre 1 : Principaux types darchitectures : Architectures 1, 2, 3, n niveaux
Objectif :
- Pr senter les principaux types darchitectures logicielles et les crit res permettant de choisir un type sp cifique darchitecture lors de la conception dun syst me dinformations
Introduction
La premi re notion importante des architectures Client Serveur est la r partition d'une application en trois niveaux d'abstraction.
| | |
| --- | --- |
|  |  |
La premi re couche est la couche de pr sentation, encore appel e IHM pour Interaction Homme Machine. Cette couche permet l'interaction de l'application avec l'utilisateur : elle g re les saisies au clavier, les actions avec la souris et la pr sentation des informations l' cran.
La deuxi me couche est la couche applicative. Elle regroupe 2 types de traitements.
- 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: repr sentent la couche m tier de l'application. On parle parfois de logique m tier (ou Business Logic) qui recouvre les traitements des r gles internes qui r gissent une entreprise donn e.
La derni re couche est celle des donn es, ou plus exactement, celle de l'acc s aux donn es. Elle regroupe l'ensemble des m canismes qui permettent la gestion des donn es stock es par l'application.
>zCes trois niveaux peuvent tre imbriqu s ou r partis de diff rentes mani res entre plusieurs machines physiques.
Le d coupage et la r partition d'une application permettent de distinguer les architectures applicatives suivantes : l'architecture 1-tiers, l'architecture 2-tiers, l'architecture 3-tiers et les architectures n-tiers.
1. Les architectures 1 tiers
Publicité
Dans une application un tiers, les trois couches applicatives sont intimement li es et s'ex cutent sur le m me ordinateur. On ne parle pas ici d'architecture client-serveur, mais d'informatique centralis e.
Dans un contexte multi-utilisateurs, on peut rencontrer deux types d'architecture mettant en oeuvre des applications un tiers :
- Des applications sur site central
- Des applications r parties sur des machines ind pendantes communiquant par partage de fichiers.
| | |
| --- | --- |
| Architecture 1 tiers centralis e  Serveur Central (mainframe) Terminaux passifs | Architecture 1 tiers r partie  |
| Les utilisateurs se connectent aux applications ex cut es par le serveur central (le mainframe) l'aide de terminaux incapables de r aliser 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. + conception programmation administration puissance centralis e - IHM pas de bureautique | D ploiement de lapplication 1 tiers sur des 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. + ergonomie IHM saturation du r seau acc s aux donn es confidentialit |
>j Il a donc fallu trouver une solution conciliant les avantages des deux premi res :
la fiabilit des solutions sur site central, qui g rent les donn es de fa on centralis e et l'interface utilisateur des applications sur les ordinateurs modernes.
Pour obtenir cette synth se, les applications ont t scind es en deux parties distinctes et coop rantes : gestion centralis e des donn es et gestion locale de l'interface utilisateur.
Ce type d'application est un client-serveur de donn es aussi appel client-serveur de premi re g n ration.Elle met en oeuvre une architecture deux-tiers.
1. Les architectures 2 tiers
Le mod le client/serveur met en Suvre une conversation entre deux programmes.
- Le client est un programme qui permet de soumettre des requ tes un ou plusieurs serveurs.
- Le serveur est galement un programme qui tourne sur un ordinateur dans le seul but de r pondre des requ tes de logiciels tournant sur d'autres ordinateurs.Par extension on parle de machine serveur.
Entre le client et le serveur circule un flux de donn es. Ces donn es sont chang es en utilisant des canaux de communication, le plus souvent ce sont des "sockets".
Les sockets sont des canaux de communication virtuels fiabilis s permettant la communication point point entre processus afin de permettre des processus de communiquer au dessus du protocole IP.
Remarque
Au niveau du d veloppement de l'application, lutilisation de sockets permet de faire abstraction du transport des donn es.
L'ensemble des couches r seau et des couches services qui permettent le dialogue entre les diff rentes applications r parties est appel plate-forme r partie ou plus commun ment Middleware litt ralement `` l ment du milieu''.Ce dialogue se base sur un protocole applicatif commun, d fini par l'API du middleware.
Publicité
La plate-forme r partie, le middleware, est linterface de communication haut niveau entre les processus. Elle repr sente v ritablement la clef de vo te de toute application client-serveur.
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.
Dans une architecture deux tiers, encore appel e client-serveur de donn es, le poste client se contente de d l guer la gestion des donn es un service sp cialis .
Ce type d'architecture offre :
+ Une interface utilisateur riche, des donn es centralis es et est efficace pour un
nombre r duit de clients.
Mais aussi il y on a les limitations suivantes :
-le probl me du client dit ob se (ou fat client). En effet, on ne peut pas soulager la charge du poste client, qui supporte la grande majorit des traitements applicatifs.
- chaque intervention engendre un co t important en particulier pour la mise jour des applications clientes.
- la relation troite qui existe entre le programme client(le traitement applicatif) et l'organisation de la partie serveur de donn es complique les volutions de cette derni re.
- la conversation entre client et serveur est assez bruyante et s'adapte mal des bandes passantes troites. La croissance du nombre de clients est limit e car les performances se d gradent et la base de donn es est en surcharge.
Pour r soudre les limitations du client-serveur deux tiers tout en conservant ses avantages, on a cherch une architecture plus volu e, facilitant les forts d ploiements moindre co t. La r ponse est apport e par les architectures 3 tiers.
Consid rant les faits suivants :
- Les 3 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, il est moins sollicit et peut tre moins volu , donc moins co teux.On parle alors de client l ger (ou thin client).
- Les ressources pr sentes sur le r seau sont mieux exploit es puisque les traitements applicatifs peuvent selon les besoins tre partag s ou regroup s par exemple le serveur d'application peut s'ex cuter sur la m me machine que le SGBD. La r partition de charge est alors possible (on parle de loadbalancing).
- La fiabilit et les performances de certains traitements se trouvent am lior es par leur centralisation, il est relativement simple de faire face une forte mont e en charge, en renfor ant le service applicatif.
- La modification des sch mas de la base de donn es ne n cessite aucune mise jour de l'application client, la structure du syst me est plus souple.
Dans une architecture 3 tiers, les donn es sont toujours g r es de fa on centralis e, la pr sentation est toujours prise en charge par le poste client, la logique applicative est prise en charge par un serveur interm diaire.
1. Les architectures 3 tiers
La mise en Suvre d'architecture trois tiers propose l'introduction d'un serveur d'application centralis exploit par les postes clients.
Publicité
Les architectures trois tiers sont complexes et demandent des comp tences tr s pointues en particulier du fait de manque de standards. Malgr ses avantages techniques vidents, ce type d'application fut donc souvent jug trop co teux mettre en place.
Alors que les solutions pour la mise en place d'architectures 3 tiers existaient depuis longtemps, leur g n ralisation explosa avec l'arriv e d'un ph nom ne mondial qui a r volutionn l'informatique : le World Wide Web.
Remarque
La v ritable r volution du W3 r side dans son caract re universel fruit de l'utilisation de standards reconnus.
- HTML pour la description des pages disponibles sur le Web
- HTTP pour la communication entre navigateur et serveur Web
- TCP/IP, le protocole r seau largement utilis
- CGI, l'interface qui permet de d clencher distance des traitements sur les serveurs Web.
La notion d'Intranet est n e de l'int gration des principes d'Internet et des technologies d ploy es dans l'entreprise. On utilise alors le r seau local de l'entreprise, les donn es sont toujours g r es par un SGBD, les m canismes utilis s pour interroger le SGBD sont toujours les m mes.
Les limitations des architectures 3 tiers
- Des limitations dues la mont e en charge : le serveur W3 constitue la pierre angulaire de ce type darchitecture et les probl mes de mont e en charge du syst me se posent son niveau.
- 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.
| | |
| --- | --- |
|  La mont e en charge |  |
Le juste quilibrage de la charge entre client et serveur semble atteint avec la g n ration suivante : les architectures n-tiers.
L'architecture n-tiers a t pens e pour pallier aux limitations des architectures trois tiers et concevoir des applications puissantes et simples maintenir.
1. Les architectures n tiers
L'appellation ``n-tiers'' pourrait faire penser que cette architecture met en Suvre un nombre ind termin de niveaux d'application, alors que ces derniers sont au maximum trois (pour rappel : la couche IHM la couche applicative la couche dacc s aux donn es).
En fait, l'architecture n-tiers qualifie la distribution de la couche applicative entre de multiples services et non la multiplication des couches.
Les composants ''m tier'' de la couche applicative sont sp cialis s et ind pendants. Ils communiquent entre eux et peuvent donc coop rer en tant implant s sur des machines distinctes.
Publicité
Ce type d'architecture permet de distribuer librement la logique applicative, ce qui facilite la r partition de la charge entre tous les niveaux.
- Un besoin appara t alors : cela n cessite des solutions pour faire communiquer les composants logiciels entre eux.
Les RPCs (Remote Procedure Call) offrent une solution transparente au d veloppeur pour faire communiquer les proc dures d'une application distribu e entre elles. Mais les RPCs ont leurs limites. Il est en effet tr s difficile par exemple d'assurer la communication avec un composant logiciel h t rog ne.
Ou encore dassurer la communication entre deux SI utilisant des technologies diff rentes.
Pour r pondre ses contraintes, il a t d fini des normes afin de cr er un bus logiciel standardis . La terminologie de bus logiciel vient de lanalogie avec le bus mat riel.
Ce bus s'appuie sur le paradigme de lorient objet, qui offre une approche conceptuelle tr s claire des applications. Ainsi le middleware Object Request Broker (ORB), bus logiciel servant d'interm diaire entre les objets distribu s est apparu.
- ORB assure la communication entre les diff rents composants logiciels. Ce bus logiciel permet de manipuler un objet distant comme s'il tait local.
- ORB est un nouveau type de middleware qui permet la construction d'architectures distribu es grande chelle.
Sappuyant sur le bus logiciel ORB une norme a t mise en place par le consortium OMG (Object Management Group) pour l'int gration et l'interop rabilit entre des applications distribu es et h t rog nes l'aide des technologies orient es objet ; CORBA est apparue. L'architecture CORBA pour Common Object Request Broker Architecture EST fruit d'un long travail de consensus effectu par le consortium OMG.
CORBA permet, au travers du protocole IIOP (au dessus de IP), l'utilisation d'objets structur s dans un environnement h t rog ne. Cette communication, orchestr e par l'ORB, est totalement ind pendante des contraintes syst mes des diff rentes plates-formes mat rielles.
Une application acc de un objet distant en utilisant le langage IDL (Interface Definition Language)
Ainsi est n la derni re g n ration de concept li aux architecture client serveur : le concept des architectures Objets Distribu s.
