Architecture logicielle

Schéma général 

Dans le cas général de la publication Web de données gérées par Ametys, une installation type d'Ametys comporte deux applications Web : l'application Front-office à laquelle accèdent les visiteurs, et l'application Back-office, qui est l'application de contribution.

La plupart du paramétrage (droits, workflows, types de contenus, charte graphique, ...) s'effectue côté Back-office. Sauf mention contraire, la documentation de ce manuel se réfère donc à cette application.

Les seuls paramétrages à effectuer côté Front-office concernent l'accès aux espaces visiteurs le cas échéant (authentification des utilisateurs, comptes clients, ...).

Dans le cas d'une application qui ne nécessite pas de publication Web, comme par exemple une application de gestion de fiches structurées, la partie Front-office n'est pas utilisée et il n'y a que l'application Back-office.

Architecture du back-office 

Ametys est une plateforme logicielle modulaire, basée sur une architecture en plugins.

Bien qu'il soit tout à fait possible de se servir du Runtime en tant que socle bas niveau pour construire n'importe quel type d'application Web, nous allons ici nous intéresser à une application CMS type, représentée par le schéma d'architecture ci-dessous.

• Le Runtime est un socle bas-niveau d'applications Web au sens large, basé sur le moteur de pipeline de Cocoon et sur plusieurs librairies Open Source standard, principalement des projets de la fondation Apache.
  Il apporte :
  • un gestionnaire de plugins, utilisé pour construire tous les modules applicatifs (voir ci-dessous pour une présentation de la notion de plugin) ;
  • un gestionnaire de workspaces, qui sont des sous-ensembles applicatifs (voir ci-dessous pour une présentation de la notion de workspace) ;
  • la définition de concepts standard à toute application Web (authentification, gestion des utilisateurs et des groupes, gestion des droits, pages d'erreurs, pages de configuration, monitoring système, ...) ;
  • les implémentations par défaut de ces concepts standard (gestion des utilisateurs SGBD et LDAP, authentification SGBD, LDAP, CAS et NTLM, ...).
• Le plugin Repository apporte une couche de stockage générique basée sur un repository JCR. La surcouche proposée par ce plugin permet la gestion d'objets virtuels (vue par l'application comme des objets réels, mais qui ne sont en réalité pas présents physiquement dans le repository JCR) et une gestion fine du mapping entre noeud JCR et objet Java associé.
• Le plugin Workflow est une mise en oeuvre de la librairie Open Source OSWorkflow, basée sur JCR.
• Le noyau CMS implémente toute l'ergonomie de contribution (ruban,onglets, ...) et les aspects métiers liés à la gestion de contenus (édition en ligne, pièces jointes, indexation, recherche, ...) et à la gestion de sites Web (plan du site, étiquettes, charte graphique, zones, services).

L'ensemble ci-dessus sera appelé "noyau Ametys" dans ce manuel d'intégration, par opposition à tous les plugins "métiers" qui peuvent être ajoutés par la suite.

La plupart des éléments du noyau Ametys sont paramétrables, que ce soit fonctionnellement ou graphiquement, c'est l'objet de ce manuel.

Plugin

Dans le vocabulaire Ametys, un plugin représente un module logiciel autonome qui peut être ajouté à une application sans toucher au noyau.

Il se présente soit sous la forme d'une librairie (ex. : ametys-plugin-repository-2.0.0.jar) présente dans le répertoire WEB-INF/lib de l'application, soit sous la forme d'un sous-répertoire au répertoire plugins de l'application.

Exemple de l'arborescence d'un plugin

Il contient obligatoirement un fichier plugin.xml qui contient la définition du plugin. Ce fichier est lu au démarrage de l'application.

Un fichier plugin.xml est organisé en features (ensembles cohérents de composants unitaires). Chaque feature peut déclarer des composants Java, des paramètres de configuration, des points d'extension et des extensions.

Les points d'extensions sont la base de la modularité d'Ametys. Ils représentent un concept, qui est ensuite implémenté par des extensions.

Par exemple, le Runtime définit le point d'extension "authentification" qui possède quatre extensions : "Anonyme", "SGBD", "LDAP", "CAS".

Lors de la phase de paramétrage, on choisit donc l'implémentation (=extension) utilisée, sans besoin de retoucher au noyau, qui lui se contente d'utiliser le concept "authentification" sans savoir quelle extension sera réellement choisie.

Les points d'extension et les extensions associées peuvent être déclarés dans des plugins différents.

Workspace

Une application Ametys est décomposée en workspaces, qui peuvent être vus comme des sous-applications.

Chaque workspace gère ainsi son mécanisme d'authentication et son espace d'URL. Chaque workspace peut utiliser tous les plugins définis dans l'application.

Une application Ametys standard utilise 3 workspaces :

• L'application elle-même (accessible à http://<serveur>)
• L'application d'administration (accessible à http://<serveur>/_admin)
• L'application de gestion du repository JCR  (accessible à http://<serveur>/_repository)