I. Présentation de PHPBoost

Architecture technique de PHPBoost

Dernière mise à jour : 24/04/2023 à 12h14

Introduction


Comme toute application Web, PHPBoost est naturellement structuré en deux principales couches, le Web étant basé sur le modèle client-serveur. En effet sur une telle application intervient un traitement côté serveur (générateur de page) et un traitement côté client (navigateur web). On distingue donc aisément deux niveaux. En allant plus loin, ce que nous ferons dans la suite, nous verrons qu'en réalité le traitement côté serveur se décompose lui-même en plusieurs couches. Nous aboutirons à une architecture n tiers (en anglais), à comprendre au sens de n étages ou n couches.

Dans ce dossier nous allons voir dans un premier temps les notions nécessaires pour comprendre le découpage en couches et ensuite détailler les couches les unes après les autres en partant de celle qu'on voit, c'est-à-dire l'interface graphique (donc les pages sur lesquelles on navigue) jusqu'à la couche la plus basse qui est le stockage des données (et donc le Système de Gestion de Base de Données ou SGBD).

Architecture générale


Définition d'une couche


Concrètement, qu'est-ce qu'une couche ?

Une couche est une interface d'abstraction d'un niveau plus bas. Par exemple, le navigateur envoie une requête HTTP au serveur sans se préoccuper de la façon dont le serveur va la traiter. Le serveur peut-être considéré comme une boîte noire, dans la mesure où si on lui donne les bonnes entrées (en l'occurrence une requête HTTP), ils nous fournira la sortie (la page) sans qu'on ait besoin de savoir comment il procède pour ce faire.


Le schéma suivant explique ce qu'est une couche et comment elle peut communiquer avec les autres.

schema_explication_couches



Les couches sont "empilées" les unes sur les autres. Pour garder une hiérarchie et une totale indépendance, chaque couche doit faire appel seulement à ses couches inférieures. En effet si elle dépend de ses couches supérieures on perd tout l'intérêt de découper l'application en couches.

Les différentes couches présentes dans PHPBoost


En découpant grossièrement on dégage simplement 3 principales couches, qui elles-mêmes sont éventuellement composées de plusieurs sous couches.

Ces trois principales couches sont les suivantes :

  • La couche présentation : l'interface homme utilisateur
  • La couche application : le coeur de PHPBoost
  • La couche stockage des données : la base de données


Couche client


La couche client (ou présentation) est la seule que l'utilisateur voit vraiment. En effet, il s'agit de l'interface, appelée en informatique Interface Homme Machine (IHM), grâce à laquelle l'utilisateur peut manipuler l'application.

Elle est exécutée par le client (navigateur web de l'utilisateur).

Comment l'utilisateur obtient-il la page qu'il souhaite ?


Nous allons voir ici rapidement quel est le principe de fonctionnement du Web.

Tout d'abord, le client doit être connecté à un réseau (souvent Internet qui pour rappel est le réseau des réseaux mais ça peut-être un réseau domestique ou un Intranet d'entreprise) tout comme le serveur Web qui correspond au site que l'utilisateur demande (ils doivent cependant être sur le même réseau pour pouvoir communiquer).

Les deux ordinateurs ont besoin de parler la même langue pour pouvoir se comprendre. En informatique, on appelle cela un protocole de communication ou de transfert de données. Celui utilisé sur le Web est le célèbre HTTP (d'où la présence de http devant chaque url) qui signifie HyperText Transfer Protocol, ou, plus rare, HTTPS, sa version sécurisée qui garantit la confidentialité des données transitant sur le réseau.

L'utilisateur demande un site, par exemple mondomaine.com. Le navigateur va lancer une requête HTTP à cette adresse. L'identifiant d'un ordinateur sur un réseau étant son adresse IP, chaque nom de domaine renvoie vers une adresse IP (par des annuaires de Domain Name Server). Tout ce traitement est réalisé par le système d'exploitation du client qui se charge d'acheminer la requête vers le serveur distant, à travers le réseau, dans lequel elle sera routée pour arriver à sa destination qui est le serveur. Un réseau informatique est comme un réseau routier, il y a plusieurs itinéraires pour arriver à destination, le chemin le meilleur étant le plus court. Ici c'est pareil, chaque carrefour est en réalité un routeur qui relie plusieurs sous réseaux entre eux. Une fois à destination la requête est traitée par le serveur. Cette requête HTTP contient diverses informations, comme l'adresse IP de l'ordinateur qui l'envoie (donc celle du client), l'adresse de la page demandée, diverses informations sur le client (son navigateur, son système d'exploitation...) ainsi que des paramètres qui sont très utiles (sous forme de cookies, de paramètres de type GET (des valeurs intégrées à l'url comme [font= Courier new]page.php?parametre1=valeur1[/font]) ou POST (par exemple des informations renseignées dans un formulaire)).

Le serveur a maintenant toutes les clés en main pour pouvoir répondre à cette requête. Il va envoyer au client (dont il connait l'adresse IP) une réponse HTTP. Cette réponse contient principalement le code HTML de la page qu'il a générée, mais aussi des entêtes contenant entre autres le type de réponse (la fameuse erreur 404 qui signifie que la page n'existe pas en est une). Le serveur achemine sa réponse exactement comme le client a acheminé sa requête, à travers le réseau.

Le client (qui attend la réponse) la reçoit et l'interprète : si les entêtes indiquent que la réponse est positive il interprète le code HTML qu'il a reçu et l'affiche, sinon il affiche un message d'erreur indiquant la cause du problème.

Voici pour résumer un schéma représentant le fonctionnement du protocole HTTP qui permet à deux ordinateurs de communiquer.

architecture_application_web



L'interchangeabilité de l'interface


PHPBoost est un logiciel qui ne peut fonctionner qu'avec une interface de type Web. Cependant l'apparence de cette application Web est complètement indépendante du reste de PHPBoost grâce à l'utilisation des templates. Ce mot anglais désigne patron (au sens géométrique) ou encore squelette. En réalité un fichier template permet de définir la forme des pages. Grâce à un système de balisage, on marque les emplacements de chaque contenu qui sera généré par la couche application (que nous verrons plus tard).

Les fichiers templates sont indépendants. En effet il n'est pas nécessaire de connaître le fonctionnement de la couche application (et donc de tout le code PHP) pour pouvoir modifier ces fichiers. La couche application apparaît comme une simple boîte noire dont le rôle est d'écrire les contenus des variables balisées là où on lui a demandé. Nul besoin de savoir comment elle fonctionne pour pouvoir s'en servir.

Grâce à l'utilisation de ces fichiers on peut dégage deux fonctionnalités très intéressantes :

  • La modification de la forme d'une page est simple. Il suffit de modifier le fichier template qui permet de la générer.
  • Un site peut avoir différentes apparences, selon le choix de l'utilisateur, puisque la couche application permet de choisir quel fichier elle appellera lors de la génération d'une page.


Résumé de la couche présentation


Cette couche est sur deux niveaux :

  • L'ordinateur du client qui envoie la requête au serveur
  • Les fichiers templates qui permettent de construite l'interface indépendamment des couches inférieures. Cette interface sera interprétée par le navigateur dans deux langages différents :
    • Le code HTML apportant la touche statique de l'application (typiquement la mise en forme)
    • Le javascript qui permet de modifier dynamiquement la page et donc son code HTML (par exemple du glisser déposer d'une image, d'un bloc, l'affichage de l'heure en temps réel)... C'est cette partie qui est vraiment révolutionnée depuis l'apparition du "Web 2.0".



En savoir plus


Voici quelques liens permettant d'approfondir les différentes notions abordées dans cette page :



Couche application


Maintenant que nous avons vu comment le client envoie les requêtes au client, nous allons voir comment celui-ci les réceptionne, les traite et renvoie leur résultat.

Cette partie est assurée par un serveur Web (nous conseillons Apache) et l'interpréteur de code PHP.

Réception de la requête


Le serveur Web scrute le réseau et plus particulièrement certains ports, comme le port 80 qui est celui utilisé par défaut. Dès qu'il détecte une requête HTTP entrante, il prend la main et s'occupe de son traitement. Il est configuré pour appeler l'interpréteur PHP lorsqu'on lui demande une page de ce type. L'interpréteur PHP entre maintenant en jeu et lit le code et l'interprète à mesure, après avoir globalement vérifié qu'il n'y avait pas d'erreur de syntaxe. Celui-ci exécute le code de la page et renvoie son résultat.

Le code de la page demandée est en fait celui de PHPBoost.

Traitement de la requête


C'est là que PHPBoost joue vraiment son rôle. En fonction des paramètres qu'il reçoit il va exécuter différentes actions de façon à satisfaire le besoin du client.

Comme on l'a vu précédemment, PHPBoost utilise des templates pour l'interface, c'est cette couche qui va dire quelle valeur il faut mettre à chaque balise qui marque les emplacements des différentes variables.

Nous allons maintenant décomposer PHPBoost en différentes parties.

Le noyau


Le noyau est l'organe central du site. Ses principales fonctions sont :

  • Gérer la configuration du site (nom, adresse, configuration du serveur et de la base de données)
  • Gérer l'environnement global (langues, thèmes, organisation des menus, modules)
  • Gérer l'espace membres. Il s'occupe de l'authentification des autorisations des utilisateurs, il procure un système de messagerie privée entre les utilisateurs. Il gère aussi les fichiers de chaque utilisateur, ainsi que les contributions de chaque utilisateur dans les différents modules, avec une interface d'approbation de chaque contribution.


Plus généralement, tout le panneau d'administration à l'exception des panneaux d'administration des modules est géré par le noyau.

Le framework


Le noyau contient le framework de PHPBoost, qu'il utilise d'ailleurs lui-même, notamment dans les interfaces de configuration. Le framework est aussi et surtout destiné aux développeurs de modules.

Un framework (espace de travail en anglais) est un ensemble de fonctions que l'on peut utiliser et qui gère les traitements qui sont assez courants de façon à éviter de multiplier les lignes de code et comme on dit de ne pas réinventer la roue à chaque fois. On a donc juste à appeler certaines fonctions du framework et celui-ci les traite sans qu'on sache forcément quand on l'utilise comment il fonctionne. On peut donc voir le framework comme une sous couche de cette couche application.

Il assiste et centralise les traitements courants dont voici quelques exemples :

  • Système de gestion de commentaires, de notation
  • Editeurs et interpréteurs de mise en page du contenu
  • Système de gestion de catégories infinies
  • Gestionnaire de flux (RSS par exemple), de plan du site
  • Interfaces de communication avec le noyau et les autres modules (exemple : recherche dans tous les modules)
  • Gestion des fichiers (lecture, écriture)
  • Moteur de templates pour permettre de faire la liaison entre fond et forme (voir couche présentation)
  • Différents outils pratiques au développement


Les modules


PHPBoost peut tourner sans aucun module. Certes cela serait d'un intérêt très limité, mais cela découle d'un principe qui est fondamental : le noyau est indépendant des modules et les modules sont indépendants entre eux.

Ainsi, chaque utilisateur pourra installer seulement les modules dont il aura besoin. Un site communautaire utilisera des modules sujets à la contribution des utilisateurs (forum, wiki, discussion...) alors qu'un site de publication se concentrera beaucoup plus sur les modules de gestion de contenu (pages, galerie...).

Les modules étant indépendants, il est possible d'ajouter ou de supprimer des modules. D'ailleurs les programmeurs apprécieront certainement le fait de pouvoir développer leur propre module et l'intégrer assez simplement au noyau, en utilisant notamment le framework.

Bien que les modules soient indépendants, une des nouveautés de la version 2.1 est qu'il est tout de même possible de les faire communiquer entre eux. Prenons par exemple la recherche. Le nouveau module de recherche permet d'effectuer une recherche dans tous les modules qui proposent cette fonctionnalité. Il suffit que le module signale qu'il sait donner suite à une telle demande. Cette communication permet de supprimer tous les défauts de l'indépendance des modules et donc d'apporter une totale liberté dans le développement et l'intégration de modules au sein de PHPBoost.

En savoir plus




Couche base de données


Cette couche est la seule complètement indépendante du projet PHPBoost.

PHPBoost utilise le SDBG MySQL qui est d'ailleurs très utilisé pour les applications Web et installée sur les serveurs Web.

Un SGBD c'est quoi ?


Un SGBD (ou DBMS:wink est un système qui permet de gérer les données. Ces données peuvent être des nombres, du texte, des caractères, des dates, ou des types plus évolués comme des fichiers (rarement utilisé sous cette forme cependant). Il existe d'autres SGBD que MySQL, comme notamment SQLite, PostGreSQL mais aussi Oracle ou SQL Serveur qui sont plus performants mais utilisés que par des professionnels.

Un SGBD est une vraie machine de guerre pour stocker des données. Très souvent programmés en langage C (programmation bas niveau mais performante), ils sont capables d'absorber des données et de les restituer en temps record et ce quelque soit la taille des données qu'ils contiennent.

Un des gros problèmes techniques actuels est que les ordinateurs stockent leurs données dans des disques durs, c'est donc aussi le cas pour les fichiers de base de données. Le problème est qu'un disque dur est un composant mécanique, et que même en optimisant toute la conception mécanique des têtes de lecture et des plateaux de disque on ne peut plus améliorer les performances car les limites ne sont pas électroniques mais bel et bien mécaniques : on ne peut pas repousser les lois de la physique notamment en ce qui concerne le déplacement de la tête de lecture. Il faut savoir qu'aujourd'hui une lecture d'une donnée élémentaire sur le disque dur prend de l'ordre de quelques millisecondes (millièmes de seconde), alors qu'une lecture dans la mémoire vive (RAM) de l'ordinateur prend environ quelques nanosecondes (milliardièmes de seconde). Il y a donc un rapport d'un million ! Mais alors pourquoi ne pas tout stocker en mémoire vive ? Actuellement la mémoire vive coûte bien plus cher que de la mémoire sur un disque dur. Il est vrai que maintenant nous arrivons assez facilement à 4 Go de mémoire vive, mais au moment où ont été inventés les SGBD ce n'était pas le cas, il était donc hors de question de stocker la base de données en mémoire vive. Il a fallu donc trouver une solution avec les disques durs. C'est pour cela que les SGBD sont de véritables machines de guerre, leurs concepteurs ont dû trouver une solution pour contourner ce problème d'accès disque et donc diminuer au maximum les lectures en créant par exemple des index (comme un index d'un livre qui classe les notions par ordre alphabétique et qui met le numéro de la page à laquelle on peut trouver l'information). Ils sont capables de sélectionner des données en imposant des contraintes (par exemple seulement les messages de tel utilisateur) en quelques millisecondes.

Comment communique-t-on avec lui ?



La plupart des SGBD sont en réalité des serveurs logiciels qui attendent des requêtes, les traitent et renvoient leurs résultats.

Le programme qui souhaite effectuer une opération sur le SGBD s'y connecte (par exemple l'interpréteur PHP avec PHPBoost) en connaissant bien entendu le nom du serveur et les identifiants pour pouvoir y accéder. Ensuite il communique en s'envoyant des informations. Une demande d'opération au serveur contient une requête en langage SQL (le principal langage de requêtes vers les bases de données). Le SGBD interprète cette requête, la traite et renvoie les informations. Le programme (PHPBoost ici) peut ensuite traiter les données comme il le souhaite.

Le SGBD SQLite a un fonctionnement un peu particulier. Conçu pour être très léger il n'est pas utilisé dans les mêmes conditions que les SGBD traditionnels (il convient par exemple en informatique embarquée comme dans un robot, un avion, par exemple ou dans des logiciels qui ont une fréquence d'accès à la base de données assez faible ou des petites quantités de données à gérer comme Firefox 3 avec sa "barre intelligente"). Ce dernier ne constitue pas un serveur mais est directement embarqué dans le logiciel (sous forme de librairies). Le gros avantage est qu'il n'y a aucune communication entre deux programmes donc aucune perte de temps à ce niveau là. Cependant ce SGBD est moins rapide que d'autres car sommaire mais très léger. Il se trouve que PHP 5 embarque SQLite et il peut donc aussi être utilisé pour une application Web, c'est un cas d'utilisation assez rare.

PHPBoost est-il compatible avec d'autres SGBD que MySQL ?


Le SGBD constitue une véritable couche et même une parfaite "boîte noire" car à moins d'avoir étudié leur fonctionnement on ne sait pas comment il travaille, en revanche on sait ce qu'il fait et on l'utilise. Il semble donc possible d'utiliser n'importe lequel de ces SGBD, puisqu'ils jouent le même rôle.

En effet, sur PHPBoost le support de différents SGBD est prévu depuis longtemps. Cependant nous rencontrons des difficultés techniques assez importantes qui font que cela n'avance pas vite. Même si tous les SGBD utilisent le langage SQL, ils n'utilisent pas exactement le même dialecte et ils ne comprendront pas forcément les requêtes. Chaque système a les spécificités de son langage et nous n'arrivons pas actuellement à faire des requêtes qui soient compatibles avec tous les SGBD. Il s'agit de construire une interface d'abstraction totale du SGBD.

Il est cependant prévu pour la suite de trouver une solution, pour l'instant PHPBoost fonctionne très bien avec MySQL, et ce dernier étant le plus répandu dans le monde des particuliers et des semi-professionnels, peu de gens devraient être gênés par ce problème. MySQL est en revanche très peu utilisé dans le monde des professionnels car il ne respecte pas certaines contraintes sur l'intégrité des données par exemple et ne résiste pas longtemps quand la charge de travail monte. Il suffit cependant dans une très large majorité des cas pour une application Web, à moins d'avoir plusieurs centaines de visiteurs connectés en permanence.

Comment éviter de multiplier les accès au SGBD ?


Les SGBD sont très rapides si on se base sur la quantité de données qu'ils sont capables de traiter. Cependant dans la mesure du possible il est préférable d'éviter de le solliciter, surtout pour éviter les temps de latence entre les appels et les réponses qu'il fournit.

Pour cela PHPBoost met certaines données en cache. Ces informations sont celles qui sont très souvent utilisées et rarement renouvelées, typiquement une configuration. Ces informations sont stockées dans des fichiers sur le serveur et sont très rapidement accessibles, bien plus rapidement que si il les demandait au SGBD car le serveur Web n'a qu'à ouvrir un petit fichier. Le framework PHPBoost permet de gérer la mise en cache assez simplement pour chaque module.

couche_donnees_cache_svg



En savoir plus


Quelques liens qui permettent d'approfondir certaines notions abordées ici :



Conclusion


Récapitulatif


Le découpage en différentes couches ayant maintenant été effectué, nous pouvons le matérialiser simplement par un schéma.

schema_racitulatif_couches



Pourquoi un tel découpage ?


Dans ce dossier nous avons vu grossièrement quelle était la structure de PHPBoost. L'utilisation de différentes couches permet, comme on l'a vu, de rendre indépendantes les différentes parties de l'application, ce qui laisse la possibilité par la suite d'apporter des optimisations ou de changer totalement les méthodes de traitement, dans la mesure où les appels à ces fonctions ne changent pas de forme.

Le découpage en couches semble a priori complexe à mettre en place et peu utile. Cependant il permet de faciliter nettement la maintenance et l'intégration (personnalisation) d'un logiciel. En effet lorsqu'on se trouve face à un bug, on peut très rapidement identifier la couche dans laquelle il se trouve et le corriger plus simplement. Une telle architecture ne permet pas de gagner en performances, en revanche elle vise à simplifier l'organisation d'un projet et donc le développement ainsi que sa maintenance. C'est pour cela qu'aujourd'hui les systèmes d'information sont souvent découpés en de nombreuses couches de façon très précise.

En savoir plus


Ce dossier contient beaucoup de notions qui sont assez complexes techniquement. Si quelque chose n'est pas clair, n'hésitez pas à en discuter dans les commentaires de l'article par exemple.
Cette page a été vue 14710 fois