Modèles de référence de WordPress, Joomla et Drupal

Intérêt du « trois tiers »

Le modèle d'architecture « trois tiers » (voir infra) a été introduit pour simplifier l'administration et la personnalisation des applications — qui interviendront soit en tant qu'outils (ici, des CMS) soit en tant que produits générés par les outils (en l'occurrence, des sites Web) s'adressant à l'utilisateur final.

Administration des applications

En matière d'administration, le « trois tiers » facilite aussi bien la gestion des sauvegardes — que l'on appliquera aux données, au code, ou à l'ensemble code-plus-données (selon les besoins) — ; que la gestion des mises à jour — qui serviront ou bien à sécuriser les applications ou bien à améliorer leurs performances.

Personnalisation des applications

Sur les questions de personnalisation, on retiendra que le « trois tiers » facilite : d'un côté, l'intégration des moteurs de gabarits — dont la fonction est de traiter la façon de présenter les contenus ; de l'autre, l'intégration des extensions — qui, par définition, serviront à étendre les fonctionnalités de base des applications.

Notion d'interface

Le client-serveur fait appel à deux types d'interfaces : les interfaces graphiques (qui, dans le cadre des interactions Homme-Machine, ont depuis longtemps pris le pas sur les interfaces en ligne de commande), et les API.

Interfaces graphiques. Ce sont les interfaces qui nous permettent de dialoguer avec les applications (site Web, boutique, traitement de texte). Elles fournissent les composants dont on a besoin pour se situer (fenêtres), naviguer (menus), éditer (champs de saisie) et valider les tâches à réaliser (boutons).

Lien utile : Interface graphique

API (Application Programming Interfaces). Les API sont des interfaces qui s'adressent à des développeurs [codeurs, programmeurs]. Il faut les voir comme des portes d'entrées, celles de programmes auxquels les développeurs pourront accéder depuis d'autres programmes, leurs propres programmes.

Lien utile : Interface de programmation

Deux autres modèles d'architecture à considérer : les architectures distribuées et les architectures pair-à-pair

En plus du client-serveur, il y a deux autres modèles à considérer : tout d'abord, les architectures distribuées ; ensuite, les architectures pair-à-pair. Ces deux modèles, qui remontent aux années 90, se présentent comme des extensions du client-serveur ; et sont à la base du Web dit 2.0 des années 2000.

Liens utiles :

• Architectures distribuées
• Architectures pair-à-pair

Traits de caractère des deux modèles d'architecture

Les architectures distribuées reprennent le principe d'externalisation des ressources ; mais au lieu de les traiter comme un tout indivisible que l'on installera sur un seul serveur — pour une application donnée —, elles les répartissent sur plusieurs serveurs.

Ces architectures, déjà plus ouvertes que le client-serveur traditionnel, du fait de la distribution des ressources sur les serveurs, sont elles mêmes challengées par des architectures qui le sont encore plus : les architectures dites pair-à-pair.

Reprenant le principe de distribution des ressources, les architectures pair-à-pair se distinguent des architectures distribuées par le fait qu'elles interconnectent des ordinateurs qui interviendront aussi bien en tant que serveur qu'en tant que poste client.

Vocation des architectures distribuées

Les architectures distribuées ont été conçues pour favoriser l'accès à des services (Google Maps) que des entités tiers pourront utiliser librement — c'est-à-dire sans contrepartie financière — en fonction de leurs besoins.

Ces services serviront le plus souvent à enrichir des applications déjà existantes ; mais certains outils donne aussi la possibilité de les assembler pour créer des applications complètes, sans avoir, théoriquement ! à écrire une seule ligne de code.

Remarque. — Le plus souvent appliquées à des services, les architectures distribuées peuvent aussi servir à distribuer des contenus, stockés dans des bases de données notamment. On parle dans ce cas de bases de données distribuées.

Vocation des architectures pair-à-pair

Concernant les architectures pair-à-pair, il s'agira au contraire de distribuer des contenus — plutôt que des services — (des fichiers musicaux par exemple) que les utilisateurs échangeront les uns avec les autres en étant soit fournisseurs soit consommateurs.

Mais là encore, rien n'est figé ; car les architectures pair-à-pair donnent aussi la possibilité de partager les capacités de traitement des ordinateurs (projet de calcul distribué SETI@home initié en 1999), en plus de leurs capacités de stockage (contenus).

CMS et modèles d'architecture

CMS et client-serveur. Les CMS étudiés dans notre ouvrage ont plutôt été conçus pour regrouper l'ensemble des ressources (code-plus-base de données) sur un seul serveur, selon les principes du client-serveur.

CMS et architectures distribuées. On retiendra que les trois CMS étudiés (WordPress, Joomla et Drupal) donnent la possibilité d'intégrer des services, sans difficulté ; mais que Drupal est le seul à pouvoir en délivrer (c'est-à-dire exposer les contenus qu'il gère en tant que services, via des API).

CMS et architectures pair-à-pair. Les premiers travaux sur le sujet (G. Canfora, « ContentP2P: A peer-to-peer content management system », IEEE Xplore) sont relativement anciens (2002). Cependant, la gestion de contenu en mode pair-à-pair reste confidentielle.

Bases de données

Liens utiles :

• Bases de données
• Systèmes de gestion de base de données

Bases de données vs SGBD et serveur de base de données

Les bases de données sont des conteneurs de données. Enregistrées dans des fichiers, celles-ci sont gérées par des SGBD (Systèmes de Gestion de Base de Données) qui, utilisés comme serveurs, deviennent des serveurs de base de données.

Données et éléments de structure

Deux types de fichiers sont à considérer. D'abord, les fichiers dans lesquels seront enregistrés les données, en tant que telles. Ensuite, ceux qui serviront à définir les éléments de structure de ces mêmes données (tables et en-têtes de colonnes associés).

Tables et en-têtes de colonne

Les éléments de structure de premier niveau s'appellent des tables (typiquement, plusieurs dizaines), pour lesquelles on définira des en-têtes de colonne (jusqu'à plusieurs dizaines) qui interviendront en tant qu'éléments [de structure] de second niveau.

Enregistrement des données

C'est à partir de ces éléments de structure que les données seront enregistrées, ligne par ligne ; chacune représentant une entité qui, dans le cas des CMS, correspondra à une rubrique, un article, un lien de menu, etc.

Attention. — Le mot « champ » est souvent utilisé pour parler des en-têtes de colonne alors qu'en fait, il désigne les cellules qui, à l'intersection des lignes et des colonnes, serviront à enregistrer les données les plus élémentaires (le titre des articles).

[Bases de données] Cas de Joomla

Avec Joomla, les articles sont enregistrées dans la table « content ». Celle-ci met en jeu une trentaine d'en-têtes, parmi lesquels « title » (titre des articles), « fulltext » (leur contenu textuel) ou encore « publish_up » (leur date de publication).

Les rubriques sont quant à elles enregistrées dans la table « categories », avec un nombre d'en-têtes qui est à peu près le même. (Les titres des catégories sont rattachés à l'en-tête « title » [comme pour les articles], les contenus textuels à l'en-tête « description »).

L'assignation des articles aux rubriques se fera au travers de l'en-tête « catid » [de la table « content »] qui correspond à l'en-tête « id » de la table « categories ». Ces deux en-têtes sont des clés qui servent respectivement à référencer et à identifier les rubriques.