Télécharger
    Installer
    Présentation
      +Architecture <-
       Serveur
       Applications
       Bases de documents
       Entrepôt
       Multilinguisme
       Analyseurs
       Débuter
    Configuration
    Indexation
    Recherche
    OAI
    Javadoc
    Référence API-XSP
    Migration
    Schemas
    Performances


SDX

Architecture de SDX-2

Sous licence GPL, SDX n'agrége que des composants logiciels libres. Avant de développer une application SDX-2 (et même de faire migrer une application de la version 1 à la version 2), on gagne à s'interroger sur son architecture, pour ce qu'elle apporte à une application documentaire.

SDX-1

SDX-1 répondait à son premier objectif : la diffusion et la recherche d'une collection de documents XML. Pour cet objectif, plusieurs composants étaient installés :

  1. Un système de stockage (un SGBD relationnel, tel que MySQL, InterBase, Oracle, Hypersonic SQL) ;

  2. Un serveur HTTP (celui de Tomcat, Apache ou autre) ;

  3. Un moteur de servlets Java (Tomcat ou autre) ;

  4. Un processeur XSLT pour transformer l'XML généré en HTML (Saxon) ;

  5. Un moteur de recherche (Lucene) ;

  6. Et surtout, un générateur de pages XML (Cocoon-1).

Une application type se présentait en quatre volets : présentation des documents, navigation hiérarchique, recherche simple et avancée, et administration de la collection de documents. Le modèle restait celui d'une application Web conventionnelle : une interface adossée à un système d'informations.

SDX-2

A l'usage, Cocoon et le langage XSP se sont avérés fort commodes pour définir les pages serveur qui constituent une application. Entré dans sa version 2 (compatible avec une exploitation industrielle), des livres sortent, des grands comptes s'y intéressent. Comme d'autres, mais souvent avant eux, SDX-2 s'est construit comme une extension directe de la servlet Cocoon (le serveur SDX). Ainsi, développer pour SDX est l'assurance de perfectionner des compétences standards (XML, XSLT, XSP), vouées à se diffuser.

Le moteur de recherche Lucene est théoriquement remplaçable (à terme), mais peu de composants libres pourraient concrètement le remplacer. La définition d'une base de documents en tire tout le parti.

Un autre processeur XSLT peut être choisi sans risque d'incompatibilité, à la condition qu'il soit en Java (ex : Xalan). Comme Cocoon, SDX-2 peut être déployé sous tout autre serveur implantant l'architecture de servlets proposée par Sun. Un moteur de servlets est constitué pour être compatible avec la plupart des serveurs HTTP. Enfin, c'était un premier objectif de SDX-2, les sources de données peuvent être multiples, conduisant au concept générique d'entrepôt (sans imposer une base de données extérieures au serveur par exemple).

Cette souplesse apporte beaucoup à une application documentaire. Il n'est plus nécessaire de la penser comme l'exploitation d'une collection de documents (ou même une collection de collections). Au lieu d'habiller une interface, on peut désormais partir d'un projet éditorial et considérer un public, une maquette, une ligne. L'agrégation des documents nécessaires vient ensuite et SDX doit résoudre facilement les questions stériles de la pure technique.



Auteur : Frédéric Glorieux ( AJLSM ) - 2003-05-13