Documentation SDX-2 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 | # 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 : Un système de stockage (un SGBD relationnel, tel que MySQL, InterBase, Oracle, Hypersonic SQL) ; Un serveur HTTP (celui de Tomcat, Apache ou autre) ; Un moteur de servlets Java (Tomcat ou autre) ; Un processeur XSLT pour transformer l'XML généré en HTML (Saxon) ; Un moteur de recherche (Lucene) ; 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

| Home |
Copyright © 2000, 2001, 2002, 2003, 2004 Ministère de la culture et de la communication, AJLSM.