Configuration d'un entrepôt de documents

Avant de voir en détails les différents types d'entrepôts, il est important de bien les catégoriser. En effet, SDX 2 prévoit des entrepôts où il s'approprie un document en faisant une copie et en le gérant lui-même ; ces entrepôts sont de type interne à SDX. Par ailleurs, SDX 2 prévoit également des entrepôts où il ne s'approprie pas le document, il ne fait que stocker son adresse URL ; ces entrepôts sont de type externe à SDX.

Les entrepôts de type externe sont intéressants lorsque les documents sont accessibles depuis le serveur et qu'ils sont déjà gérés correctement par un système (simple ou complexe), extérieur à SDX. Par exemple, ces documents pourraient être sur un site Web distant, où ils pourraient déjà être proprement stockés dans un système de fichiers accessible depuis le serveur et il n'y a aucune raison de copier ces documents.

Les entrepôts de type interne lorsqu'on veut que SDX prenne en charge le stockage des documents. Cela peut s'avérer nécessaire si, par exemple, les documents ne sont pas stockés sur un système de fichiers accessible depuis le serveur (c'est le cas s'ils sont chargés par l'utilisateur à l'aide d'une interface Web) ou s'ils sont construits dynamiquement, en mémoire, suite à la saisie d'informations dans un formulaire HTML. Dans ce telles situations, le document n'est pas déjà accessible à SDX, alors il faut lui passer et lui demander de le prendre en charge.

Avant même de choisir une implantation spécifique d'entrepôt pour une application SDX, il est bien important de déterminer si on cherche un entrepôt interne à SDX ou un entrepôt externe.

L'entrepôt de type URL est le seul entrepôt externe à SDX actuellement implanté. Son principe est simple : au lieu de prendre une copie des documents, il conserve seulement leur URL. Lorsque SDX a besoin des documents (par exemple pour la consultation du document), il le retrouve grâce à son URL.

Pour que ce type d'entrepôt fonctionne, les documents doivent nécessairement avoir une URL valide, c'est-à-dire une URL qui peut être utilisée par Java. Cela exclut donc les documents résidant en mémoire (un DOM par exemple), les documents accessibles via des URL qui utilisent des protocoles non standards, etc. Par contre, cela inclut les URL de type file://usr/home/doc.xml, ce qui signifie qu'un entrepôt URL peut être utilisé pour des documents disponibles sur le système de fichiers du serveur.

Ce dernier point est important : il montre que les documents gérés dans un entrepôt de type URL n'ont pas besoin d'être sur un serveur distant. L'utilisation de ce type d'entrepôt sur des fichiers locaux permet de ne pas copier ces derniers, s'ils sont déjà gérés convenablement sur le serveur.

Par ailleurs, lorsqu'un document est référencé par une URL qui pointe sur un serveur distant, chaque consultation de ce document se fera en allant le chercher à cette URL. Cela implique trois choses importantes :

L'utilisation d'un cach local (voir plus loin) modifie quelque peu les deux premiers énoncés.

Pour utiliser un entrepôt URL, la façon la plus simple est de le définir ainsi :

<sdx:repository id="r1" type="URL"/>
  

Avec un tel entrepôt, tous les documents seront référencés par leur URL absolue et récupérés à chaque fois via cette URL. On peut modifier ce comportement avec un cache ou une URL de base.

<sdx:repository id="r1" type="URL" base="http://foo/bar/"/>

<sdx:repository id="r1" type="URL">
  <sdx:cache check="onIndex">
    <sdx:repository type="FS" id="r1cache"/>
  </sdx:cache>
</sdx:repository>

Les documents XML peuvent facilement être stockés dans des fichiers, et c'est pourquoi il est naturel dans SDX d'offrir un type entrepôt qui exploite cette possibilité ; c'est le rôle de l'entrepôt de type système de fichiers. Cet entrepôt est fort simple : il prend une copie des documents indexés et les stocke dans une hiérarchie de répertoires sur un disque qui lui est accessible. Toutes les opérations subséquentes sur les documents s'effectuent à partir de ces copies gérées par SDX. Notamment, lors d'une suppression, le fichier est effectivement supprimé.

Ce type d'entrepôt est utile surtout pour sa simplicité. Nul besoin d'installer des outils externes ou de gérer les documents XML de l'extérieur, SDX se charge de tout. Par ailleurs, même si les fichiers sont facilement accessibles avec d'autres outils, il ne faut pas les déplacer ou les supprimer sans l'aide de SDX, sinon l'intégrité de la base de documents ne peut plus être assurée.

Une déclaration complète d'un tel entrepôt se fait de cette façon :

<sdx:repository type="FS" baseDirectory="documents" depth="2" extent="100"/>

L'attribut type indique bien qu'il s'agit d'un entrepôt de type système de fichiers (FileSystem). Ensuite, l'attribut baseDirectory, obligatoire, permet de spécifier le répertoire de base où SDX stockera les documents gérés. Sa valeur doit être une URL absolue ou relative, si elle est relative elle est interprétée par rapport au fichier application.xconf. Ainsi, dans cet exemple, le répertoire de base serait le répertoire documents dans le répertoire conf de l'application, car le fichier application.xconf se situe dans ce répertoire.

SDX va stocker les documents XML dans des fichiers, mais pas tous dans un même répertoire. Il créera une hiérarchie de répertoires pour contenir ces fichiers, de manière à éviter de créer un trop grand nombre de fichiers dans un même répertoire. Cette organisation dépend de deux paramètres : la profondeur de la structure et le nombre moyen de fichiers à mettre par répertoire ; ce sont les attributs depth et extent qui fournissent ces indications. Ainsi, dans l'exemple précédent, SDX va créer deux niveaux de sous-répertoires sous le répertoire de base, et il va créer 100 répertoires par sous-répertoire. Il va utiliser cette structure et y déposer les documents au hasard. Selon cet exemple, au second niveau, il y aura 100 * 100 = 10 000 répertoires, s'il y a 1 000 000 documents il y en aura donc 100 en moyenne. En spécificant des paramètres appropriés pour le nombre de documents envisagés pour une base, il est possible d'obtenir une structure facilement gérable. Ces deux attributs sont optionnels ; s'ils ne sont pas présents, les valeurs 3 et 100 sont utilisées par défaut.

Ce type d'entrepôt est facile à configurer, mais il est conseillé seulement pour les applications ayant un faible nombre de documents, car le système de fichiers montre des limites pratiques lorsque le nombre de fichiers dépasse un certain seuil.

Les entrepôts de type JDBC sont des entrepôts où le stockage des documents s'effectue à l'aide d'une base de données relationnelles. Il s'agit en fait du type d'entrepôts qui était offert par SDX-1. SDX utilise donc le gestionnaire de bases de données pour y stocker les documents et leur identifiant, permettant ainsi de les retrouver ou de les supprimer si nécessaire. La connexion avec la base de données et la création de la structure nécessaire sont des opérations prises en charges par SDX-2 et son architecture Cocoon sous-jacente ; par contre, l'installation du SGBD est la responsabilité du développeur de l'application SDX qui désire utiliser un tel type d'entrepôt.

Les entrepôts de type JDBC peuvent utiliser toute base de données pour laquelle il existe un pilote JDBC. Toutefois, même si la structure utilisée par SDX est fort simple, il peut y avoir des différences d'un SGBD à l'autre, différences en général dues à des implantations différentes des BLOB dans les SGBD. C'est pourquoi SDX distingue différents types d'entrepôts JDBC, chaque type faisant référence à un SGBD particulier, ou à un groupe de SGBD ayant des caractéristiques similaires. C'est pourquoi il est possible d'utiliser ces différentes valeurs pour l'attribut type :

Cocoon-2 prévoit tout ce qui est nécessaire pour définir des sources de données gérées par des SGBD. SDX utilise ces définitions plutôt que d'avoir ses propres sources de données. Ainsi, pour utiliser un entrepôt de type JDBC avec SDX, il est nécessaire de configurer une source de données appropriées dans Cocoon. La documentation de Cocoon indique comment procéder ; essentiellement, il s'agit d'une part d'ajouter une entrée dans le fichier WEB-INF/web.xml pour indiquer quelle classe Java utiliser comme pilote JDBC et d'autre part de définir une source de données utilisant ce pilote dans le fichier WEB-INF/cocoon.xconf, cette définition incluant notamment le nom de la base de données, le code d'utilisateur et le mot de passe à utiliser, et certaines autres pramètres. Cette étape de configuration Cocoon est nécessaire pour utiliser un entrepôt de type JDBC dans SDX.

La définition d'un entrepôt de type JDBC dans SDX est très simple, car un seul attribut est nécessaire :

<sdx:repository id="r1" dsi="my-db"/>

L'attribut dsi contient le nom de la source de données définies dans le fichier application.xconf.

SDX va stocker les documents dans une table de la base de données. Cette table aura pour nom la concaténation du chemin de l'application, du caractère _ et de l'identifiant de l'entrepôt. Par exemple, si l'entrepôt défini ci-dessus appartient à une application située dans sdx/myapp, la table où SDX stockera les documents est myapp_r1.

La structure utilisée par SDX variei légèrement d'un SGBD à l'autre, mais seulement sur les types de données précis. Cette définition générale donne une bonne idée de cette structure :

CREATE TABLE nom_de_la_table ( id VARCHAR(255) NOT NULL,
     data BINARY, PRIMARY KEY (id));

Il y a donc un champ id, clé primaire, qui contient l'identifiant du document dans SDX, et un champ data qui contient le document tel quel, sans aucune modification.

L'architecture SDX-2 permet d'utiliser d'autres types d'entrepôts sans toucher au code de SDX. En effet, l'attribut type de l'élément <sdx:repository/> est utilisé afin d'identifier une classe Java qui implémente l'interface fr.gouv.culture.sdx.repository.Repository. Cette identification s'effectue de cette façon :

Ce mécanisme est très souple, car il permettra d'ajouter facilement d'autres types d'entrepôts dans SDX, mais surtout il permet à tout développeur d'application de mettre en place son propre type d'entrepôts sans avoir à toucher au code de SDX.