Le cœur d’eXoMiLe est à la fois une brique élémentaire garantissant l’extension du produit et une boite à outils regroupant un ensemble de mécanismes facilitant l’exploitation d’eXoMiLe. Dans cette section nous allons découvrir quelques-uns des outils et services offerts par ce composant.
Sans aller jusqu’à dire que c’est un framework, le cœur d’eXoMiLe insuffle une façon de concevoir les extensions. Il renferme la conception et les règles de développement (Figure 48).
Modèle de
données Mapping
Abstraction base de données
Base de données Processus Fabrique de service Service N Service configuration Service document
...
Moteur d’interrogation fonctionnel
Figure 48 - Coeur d'eXoMiLe
Nous débuterons par la présentation d’un mécanisme fondamental dans la gestion des traitements parallèles d’eXoMiLe : les processus et les tâches.
Nous verrons ensuite la représentation d’une configuration de document dans l’univers Java. Nous aborderons l’accès au paramétrage et l’exploitation des ressources.
Ensuite nous parlerons du gestionnaire de document si souvent cité. Nous verrons qu’il constitue un point important dans la logique d’eXoMiLe et dans le traitement des documents.
L’abstraction de la base de données sera ensuite traitée. Nous avons évoqué précédemment qu’eXoMiLe ne doit pas être couplé à un SGBD et doit pouvoir facilement être adapté à un nouveau candidat. Nous détaillerons les mécanismes permettant de répondre à ce besoin.
L’accès aux services métiers est obtenu grâce à une fabrique. Nous verrons sa définition, comment ajouter de nouveaux services et comment modifier le comportement des services existants.
Nous continuerons sur la présentation de deux services fondamentaux : le service de gestion des configurations et le service de gestion des documents.
3.4.1 Le modèle de données
Le modèle de données est la traduction objet de la configuration de document (Figure 49). Il offre un accès à l’ensemble des ressources et au paramétrage via un mapping objet / XML (JAXB).
Configuration Modèle de données (Java)
Paramétrage
Code
Ressources
Resourceloader
Classloader
L’accès aux ressources est détaché du support de cette dernière. C’est-à-dire qu’eXoMiLe masque volontairement le fait qu’une ressource soit un fichier local, une image hébergée sur un serveur, un document en base de données, etc.
Le code Java bénéficie d’un traitement particulier du fait qu’il est destiné à être injecté dans la JVM. Pour cela un chargeur de classe est associé au modèle de données.
3.4.2 La fabrique de services : exposer le métier au client
La fabrique de services est instanciée par l’application cliente. eXoMiLe propose une implémentation par défaut offrant l’ensemble des services de base.
La fabrique peut être enrichie par décoration permettant ainsi la modification des services existants ou l’ajout de nouveaux services (Figure 50).
Fabrique de base
Service 1 Service 2Fabrique extension 1
Fabrique extension 2
Décore Décore Service 3 Service 4 Décore Profil 3 Profil 2 Profil 1 Utilise Utilise UtiliseFigure 50 - Fabrique de services
Dans le cas de l’ajout d’un service, l’exposition de ce dernier nécessiterait un transtypage de la fabrique. En effet la nouvelle méthode de création correspondant au nouveau service ne serait pas visible par la partie cliente.
Pour pallier à ce problème, eXoMiLe implémente une chaîne de responsabilité déclenchée par une méthode générique. Un client demande un service par une interface et cette dernière sert de clé transmise à la chaîne formée par les décorateurs. Le premier capable de produire un tel service stoppera la propagation.
Une alternative à cette conception aurait été l’utilisation d’un registre. Cependant cette solution a été écartée du fait de l’unicité du registre. En effet, la décoration permet d’offrir à une application différente vision de notre fabrique. Nous pouvons par exemple répondre facilement à des problématiques de gestion de profils et de droits d’accès de manière totalement transparente en reposant uniquement sur des décorations successives.
Bien que cette conception viole des principes de la POO (responsabilité unique, ségrégation par interface), elle permet une approche moins contraignante pour l’application tierce et permet une plus grande abstraction vis-à-vis des implémentations. On peut donc dire que la fabrique de services eXoMiLe est une composition de trois design patterns : fabrique abstraite, décorateur et chaîne de responsabilité.
3.4.2.1 Le service de gestion des configurations
Le service de gestion des configurations est en charge de l’import, de la suppression et de la lecture des configurations de document. L’ensemble des traitements associés sont exécutés via des processus que nous présenterons au paragraphe 3.4.3.
Les opérations d’import et de suppression d’une configuration consistent respectivement à créer et supprimer les structures nécessaires à la persistance de l’information (document + indexation).
La lecture d’une configuration est un ensemble de deux opérations. Premièrement, la configuration est extraite de la base de données puis le modèle de données est généré. Dans un second temps, un mapping modèle de données / structures de données est généré. Il maintient les relations entre le modèle de données, donc les paramétrages de la configuration, et les tables et colonnes produites à partir de ce modèle.
Ce mapping est exploité lors de la traduction d’une requête fonctionnelle en une interrogation à la base de données qui sera présenté à la section 3.5. Il est organisé selon une représentation hiérarchique calquant le modèle de données (Figure 51).
Configuration
Modèle de données (Java)
Paramétrage Code Ressources Resourceloader Classloader Base de données
Mapping
Figure 51 - Mapping modèle de données / base de données
3.4.2.2 Le service de gestion des documents
Le service de gestion des documents gère l’ensemble des opérations applicables à un document, dans sa totalité, c’est-à-dire qu’il ne connait pas la notion d’élément ou d’état. Il offre les fonctionnalités d’import et de suppression, d’indexation, de vérification de l’existence et de récupération d’un document.
A l’instar des ressources d’une configuration, un document est représenté sous une forme générale permettant de s’affranchir de son emplacement physique. La notion de fichier ou d’URL est entièrement masquée. Par conséquent, le service de configuration de document exploite et fournit des sources de document. Ainsi, un
document importé en base de données ou bien un document à importer pourront être traités indifféremment.
Le service de gestion des documents nécessite de connaitre le type de la source. Il s’appuie alors sur le modèle de données et sur le mapping pour réaliser les différentes opérations. Par conséquent, il utilise la fabrique de service et nous voyons ici l’importance de la décoration de cette dernière. En effet, un accès limité aux types de document peut être implémenté de manière totalement transparente pour le service de gestion des documents.
3.4.3 La notion de processus et tâches
Le mécanisme de processus et de tâches offert par eXoMiLe permet de modéliser un traitement parallélisable. Le processus est exécutable dans un thread, et chaque processus peut exécuter un ensemble de tâches. Une tâche peut être considérée comme une étape au sein du processus, elle peut être synchrone ou asynchrone.
Un processus est capable de communiquer avec son environnement. Pour cela, il s’appuie sur le patron de conception observateur et différents évènements sont associés :
· démarrage, avancement et fin, · lancement de tâches,
· émission de messages, · demande d’information.
En règle générale, un message émis par un processus est représenté par une clé destinée à être interprétée par l’appelant. Une demande d’information pourra être traduite par une boite de dialogue ou une invitation à saisie en ligne de commande.
D’un point de vue technique, une tâche est semblable à un processus. Elle définit une notion de criticité qui permet de la rendre fatale, c’est-à-dire qu’en cas d’erreur, le processus parent ne pourra pas continuer. A l’instar du processus, une tâche est observable et possède des évènements semblables. Un point important est qu’elle ne peut pas réaliser de demande d’information, elle est obligée d’en référer au processus. Cette contrainte a pour but de ne pas saturer une éventuelle IHM avec des
demandes d’informations. Il n’y a donc qu’un seul canal de demande par processus (Figure 52).
Processus
Tâche 1 Tâche 2 Tâche 3 Tâche 4 Demande d’information MessageFigure 52 - Processus / Tâches
Un processus peut devenir une tâche d’un autre processus. Par exemple, l’indexation d’un document devient une tâche dans le processus d’import. Pour cela le patron de conception adaptateur a été employé. Il devient ainsi aisé de composer tâches et processus.
La notion de processus et de tâches est constamment utilisée dans eXoMiLe. Elle offre à l’application cliente la possibilité de suivre et de communiquer avec des opérations longues et asynchrones. Le diagramme de classes représentant cette mécanique est présenté en annexe C.
3.4.4 Le gestionnaire de document
Nous avons vu au fil de ce mémoire qu’eXoMiLe est conçu dans le but de traiter des documents XML. Cette affirmation est réductrice. En effet eXoMiLe est potentiellement capable de traiter tout format de document offrant une représentation hiérarchique de l’information. Par exemple, eXoMiLe est capable de traiter des documents composites, ce que nous verrons à la section 0.
Pour cela, eXoMiLe s’appuie sur la notion de gestionnaire de document qui implémente la logique d’import, de suppression et d’indexation. La définition du gestionnaire de document est réalisée dans le paramétrage de la configuration, il constitue un point d’extension. Par défaut, eXoMiLe propose un gestionnaire de document XML dont le processus d’indexation sera présenté à la section 3.7.
Le gestionnaire de document offre également la possibilité de tester un document, c’est-à-dire que le document fourni est bien supporté par la configuration. Nous voyons ici apparaitre une potentielle future fonctionnalité utilisateur : la détection automatique de document. Cette opération étant synchrone, il est nécessaire que le traitement effectué soit le plus performant possible en espace et en temps.
3.4.5 Faire abstraction de la base de données
L’abstraction de la base de données est assurée par un ensemble de composants permettant de gérer :
· les connexions et les transactions (TCL), · les opérations de structures (DDL), · la manipulation de données (DML).
Le premier point est laissé à la charge de l’application tierce et les deux autres sont implémentés par le module de support du SGBD (Figure 53). En effet, eXoMiLe ne peut imposer la gestion des sources de données tel un pool de connexion ou une ressource JNDI.
SUPPORT SGBD
CLIENT TCL
DML
DDL
Les opérations de structures ne concernent que les opérations s’appliquant au modèle dynamique de données. Le modèle statique est un prérequis à l’utilisation d’eXoMiLe et un script de création est fourni à la livraison. Nous retrouvons dans ce composant toutes les opérations de création de table, colonne, index, contrainte, etc.
La manipulation des données consiste en la conversion d’une requête fonctionnelle en une requête SQL adaptée à la base de données cible. Pour cela eXoMiLe offre un modèle d’interrogation s’appuyant sur les informations d’indexation et les données (Figure 54).
ET C1 C2 SELECTION TRI FILTRE > 3 C1 C2 < 0 C2 REQUETE COUNT (C3)
Figure 54 - Requête fonctionnelle
Les annexes D et E présentent respectivement les diagrammes de classes des champs et filtres utilisables dans une requête fonctionnelle. Nous pouvons constater la présence du patron de conception visiteur facilitant l’exploitation de telles structures.
Finalement, on peut dire que ce modèle calque les clauses d’une requête SQL. Il faut cependant noter que les agrégations sont calculées, c’est-à-dire la clause GROUP BY est exprimée en s’appuyant sur les fonctions appliquées aux champs sélectionnés. De plus, aucune information de table et de jointure n’est précisée. En effet, ces informations seront déduites par le moteur d’interrogation fonctionnelle présenté à la section 3.5.