| | | | | | --- | --- | --- | --- | | **Institut Supérieur des Etudes Technologiques de Bizerte** **Département Technologies de l’informatique** | | | | | **Parcours :** | Développement des Système d’Informations | | | | **Unité d’Enseignement :** | 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 d’architectures : Architectures à 1, 2, 3, n niveaux**
**Objectif :**
* Présenter les principaux types d’architectures logicielles et les critères permettant de choisir un type spécifique d’architecture lors de la conception d’un système d’informations
**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.
🡺Ces 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**
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 l’application 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é |
🡪 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**
****
Publicité
Le modèle client/serveur met en œuvre 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, l’utilisation 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**.**
****
La plate-forme répartie, le middleware, est l’interface 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 :
Publicité
* 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 œuvre d'architecture trois tiers propose l'introduction d'un serveur d'application centralisé exploité par les postes clients.
****
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 d’architecture 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 œuvre 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 d’accè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 d’assurer 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 l’analogie avec le bus matériel.
Ce bus s'appuie sur le paradigme de l’orienté objet, qui offre une approche conceptuelle très claire des applications. Ainsi le middleware **O**bject **R**equest **B**roker (**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.
S’appuyant 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.
