Semaine 1
Exemple de projet :
Hiver 2025
https://php.dinf.ca/projet/h2025/2338442/
https://php.dinf.ca/projet/h2025/Mers/
(Architecture, vocabulaire, modèles client/serveur, n-tier et conception MVC)
Ref.: http://www.commentcamarche.net
1. Architecture:
Introduction
Nous allons présenter les architectures 3-tier.
On écrit bien tier et non tiers. En effet "n tier"
est un terme anglais qui ne doit pas être confondu
avec le mot français "tiers".
Dans toute la présentation suivante tier signifie
niveau logique et non 3.
La multiplication et le développement des réseaux nationaux et planétaires ont profondément modifié les méthodes de programmation. Les architectures trois tier ( et n-tier ) sont la solution pour développer des applications permettant une grande flexibilité dans les relations entre l'entreprise, ses clients et ses fournisseurs.
Ce site internet a pour objectif de faire un état des lieux des technologies et des méthodes utilisées pour créer ce type d'application. Nous étudions tout d'abord les l'évolution historique des applications clients serveurs pour arriver aux architectures n-tier. Puis nous étudions les différents outils mis en oeuvre dans ce type d'application. Nous utilisons, de plus, tout au long de notre démonstration l'exemple d'un moteur de recherche pour préciser les différents points.
Les débuts du client serveur
Durant les années 80 de nombreuses applications de gestion sont proposés aux entreprises. Ces applications sont exclusivement propriétaire et les infrastructure les supportants sont celles des constructeurs informatiques qui dominent le marché( IBM, Bull ... ). Souvent une station n'est de travail n'est uilisé que pour une application ce qui entraine une multiplication des stations pour les utilisateurs. Les protocoles de réseaux reliant les postes de travail aux calculateurs sont ceux des différents constructeurs ( comme SNA pour IBM ).
Cette multiplication d'application entraine une donc une mutliplication des terminaux pour les utilisateurs. L'apparition des PCs a permit de résoudre en partie ce problème. Des emulateurs sont installés sur ces PCs grace à eux le nombre de station de travail est considérablement réduit. Au fur et à mesure le protocole IP s'impose pour remplacer les différents protocoles constructeurs.
L'architecture à deux niveaux
Les différentes applications dont nous avons parlé précedement étaient basée sur une architecture à deux niveaux. Une partie des traitements était effectués sur le poste client et la seconde sur le calculateur.
On peut séparer ce type d'application en deux types:
- orienté clients
- orienté serveur.
Dans les applications orienté clients, la plupart des traitements sont effectués sur le poste du client qui possède une Interface Homme Machine dite "lourde". Dans celles orientés serveurs c'est le serveur qui effectue tous les traitements. Le client lui possède une IHM légère.
Qu'elle soit légère ou lourde l'IHM est propriétaire est nécéssite donc une instalation sur le poste client. Ceci rend l'installation d'une telle application trés lourde si le nombre de client est important. De plus ont peu trés difficilement réutiliser ce type d'application car l'IHM est dédié et composée d'un seul bloc. Enfin les performances réseaux ne sont pas trés elevés car de nombreuses requêtes doivent transiter par le réseau.
On peut représenter cette architecture par le schéma ci-dessous.
Pour pallier aux différents inconvénient que nous avon étudié, on a décidé de séparer le traitement applicatif à la fois des données et de l'interface, c'est ce qui a amené l'architecture 3-tier.
L'architecture à n-niveaux
Dans une telle architecture, on a séparé la partie applicative ou traitement de l'IHM et des données. On obtient donc les trois couches suivantes:
- la couche présentation.
- la couche application
- la couche donnée ou métier.
La représentation d'une architecture 3-tier est la suivante.
On parle d'architecture 3 tier mais aussi d'architecture n tier. En effet dans la plupart des applications le niveau intermediaire est une collection de composant qui sont utilisés dans de nombreux traitements transactionnels. Ces composants peuvent être situé sur un ou plusieurs serveurs physique. De plus chacun de ces composants effectue une petite tache et c'est pourquoi on peut séparer cette partie intermediare en n partie d'où le terme architecture n-tier.
2. Quelques définitions:
|
Client/Serveur |
|
|
|
|
|
client-serveur |
|
|
|
|
|
architecture multi tiers |
|
|
|
|
|
3-tier (Programmation) |
|
|
|
|
La norme J2EE s'impose actuellement comme une référence mondiale de rigueur, d'ouverture et d'évolutivité.
Le sigle J2EE signifie " Java 2 Enterprise Edition " et repose donc sur Java, langage objet conçu pour être "portable", c'est-à-dire exécutable sur n'importe quel type de serveur ou de système d'exploitation. D'ou le slogan lancé par la firme SUN : "Write Once, Run Anywhere" ("développé une fois, exécutable partout").
Le standard Java 2 Entreprise Edition (J2EE)
La norme J2EE recommande les différentes couches qui doivent constituer un serveur d'application (respectant les standards) et définie l'environnement standard sur lequel ce serveur peut tourner. Les éléments constitutifs d'une architecture basée sur la norme J2EE sont décrit ci-dessous :
Premier changement : le client/serveur " n-tier "
Le monde informatique s’aperçoit rapidement qu’une architecture à 2 niveaux ne tient pas la route lorsqu’il s’agit de déployer des applications critiques sur des centaines ou des milliers de postes client.
Le client/serveur, en bute à de graves limitations de déploiement à grande échelle, réinvente le transactionnel. On se met alors à parler de client/serveur " 3-tier " ou " n-tier ". Le poste client représente le premier niveau, le serveur le dernier niveau et le (ou les) services du système transactionnel le (ou les) niveaux intermédiaires.
Deuxième changement : l’objet
La programmation objet fait beaucoup parler d’elle depuis quelques années. Son développement aura été freiné par le haut niveau d’abstraction requis par la programmation objet, un certain manque d’outils et de violents conflits autour de la définition de standards. Malgré tous ces handicaps, l’objet progresse régulièrement. Une application découpée en composants logiciels résidant sur plusieurs systèmes différents et hétérogènes et devant interagir entre eux a besoin, pour fonctionner correctement, d’une couche intermédiaire gérant ce dialogue. Ce middleware sera appelé ORB (Object Request Broker).
Troisième changement : Internet
Les technologies Internet sont en train de bouleverser les architectures des systèmes d’information. Un serveur Internet/Intranet/Extranet doit être en mesure d’encaisser la charge que représente des milliers de clients qui y effectuent des requêtes. La première solution consiste à mettre directement en ligne des serveurs Web. Réponse insatisfaisante parce que le serveur se trouve vite saturé, que la technologie sous-jacente des liens entre serveurs Web et bases de données est pour le moins primitive et aussi parce que, dans le monde Internet, il est judicieux de distribuer les requêtes sur différents serveurs répartis en différents points du réseau.
3. Réflexion sur l'histoire :
Le client-serveur "effacé" par le Web
A peine le temps de dire " ouf ! ", et voici le client-serveur remis en question par l'arrivée d'un nouvel arrivant : le Web. Sans apport d'un point de vue fonctionnel, c'est surtout grâce à sa standardisation qu'Internet a réussi à aller au-delà de sa vocation originelle et a pu percer dans un domaine où on ne l'attendait pas : la gestion informatique.
Lundi 1 octobre 2001
Débat (Suite) : Faut-il tourner définitivement la page du client-serveur ?
"Je suis Responsable Informatique d'une PMI, et je dois dire que, bien souvent, les arguments avancés par les uns et les autres dans ce débat ne tiennent pas compte des contraintes et de l'environnement que nous avons dans les PME-PMI.
La première des réflexions qui me vient à l'esprit est: "pourquoi vouloir absolument tendre vers des clients légers ?" Quand nous achetons de nouveaux PC, ceux-ci, sont bien plus puissants que nos " vieux " serveurs âgés de seulement 2 ans. La plupart de nos utilisateurs font usage d'une suite bureautique qui ne fonctionne qu'avec un PC puissant et un OS lourd. Pourquoi alors ne pas utiliser cette puissance pour des applications clientes lourdes ? Changer, certes, mais pour quelle architecture ?
Dans nos petites entreprises, où le personnel informatique est souvent réduit à sa plus simple expression, pourquoi en effet changer une architecture qui fonctionne et que nous avons mis du temps à installer et à optimiser ? La grande question est : "Architecture distribuée pour faire quoi ?".
Le client-serveur a-t-il un avenir ? Bien sûr que oui. Les nouvelles architectures que l'on nous propose sont des architectures client-serveur. Quelle différence entre une architecture client-serveur n-tier et une architecture " distribuée " ? Les nouvelles technologies proposées ne sont pas à mettre en opposition avec les anciennes, elles ne représentent qu'une évolution naturelle. La différence vient essentiellement du client utilisé, client lourd versus client léger, et là, les arguments en faveur de l'un ou de l'autre ne manquent pas. L'outil de développement que nous utilisons dans mon entreprise nous permet de placer les objets dans le client ou dans le serveur, voire les deux, et de les utiliser au cas par cas, soit sur le client, soit sur le serveur.
La migration vers un client léger nous serait assez facile, et nous l'avons déjà fait, mais il y a peu d'intérêt pour nous à surcharger nos serveurs alors que la plupart des tâches peuvent être traitées sur des postes client puissants..."
Parlons 2026
Serveur d'application ?
Ce système permet à chaque membre du réseau d’exécuter des programmes directement sur le serveur plutôt que sur son propre poste, baptisé à l’occasion client léger
Application mobile ?
Une application mobile est un logiciel applicatif développé pour être installé sur un appareil électronique mobile, tel qu'un assistant personnel, un téléphone portable ou une tablette numérique.
4. Conception MVC :
Ref. : https://fr.wikipedia.org/wiki/Mod%C3%A8le-vue-contr%C3%B4leur
Modèle-vue-contrôleur ou MVC est un motif d'architecture logicielle destiné aux interfaces graphiques lancé en 1978 et très populaire pour les applications web. Le motif est composé de trois types de modules ayant trois responsabilités différentes : les modèles, les vues et les contrôleurs.
- Modèle : cette partie gère les données de votre site. Son rôle est d'aller récupérer les informations « brutes » dans la base de données, de les organiser et de les assembler pour qu'elles puissent ensuite être traitées par le contrôleur. On y trouve donc entre autres les requêtes SQL.
- Vue : cette partie se concentre sur l'affichage. Elle ne fait presque aucun calcul et se contente de récupérer des variables pour savoir ce qu'elle doit afficher. On y trouve essentiellement du code HTML mais aussi quelques boucles et conditions PHP très simples, pour afficher par exemple une liste de messages.
- Contrôleur : cette partie gère la logique du code qui prend des décisions. C'est en quelque sorte l'intermédiaire entre le modèle et la vue : le contrôleur va demander au modèle les données, les analyser, prendre des décisions et renvoyer le texte à afficher à la vue. Le contrôleur contient exclusivement du PHP. C'est notamment lui qui détermine si le visiteur a le droit de voir la page ou non (gestion des droits d'accès).
Ce motif est utilisé par de nombreux frameworks pour applications web tels que Ruby on Rails, Grails, ASP.NET MVC, Spring, Struts, Symfony, Apache Tapestry, Laravel, ou AngularJS.
La requête du client arrive au contrôleur et celui-ci lui retourne la vue
Représentation des interactions entre le modèle, la vue et le contrôleur dans le cas d'une application web.
Dans notre cours :
Back end => Serveur Web apache utilisant PHP
Front end => Framework Angular utilisant JavaScript
