Retour : page principale > sommaire eFlore v2

Besoins et solutions techniques d'eFlore v2


Base de données

Besoins :

Une base de donnée :
  1. robuste
  2. utilisable sur différents système d'exploitation
  3. gérant la concurrence des accés aux données qu'elle contient
  4. permettant de créer deux bases une pour les données les plus récentes, l'autre pour l'archivage et le suivi historique des modifications des données de la première base.

Solution technique :

Aucune base de données ne convient vraiment, c'est au niveau du code que nous géreront la compatibilité à différentes bases. Pour cela :
  • utilisation d'une couche logiciel fournissant un système d'abstraction de base de données
  • être compatible SQL92 (ou dernière norme s'il y en a une plus récente)

Base de données envisageable sans choix:
  • Mysql
  • Oracle
  • Postgresql

Intégration des données dans la base


Besoins :

Un langage informatique permettant :
  1. d'accéder facilement à différents types de fichiers (txt, csv, html, ...)
  2. de se connecter à différentes bases de données (couche d'abstraction des bases de données)
  3. d'extraire facilement des morceaux de texte d'un document et de les retravailler (expressions régulières)

Solution technique :

Utilisation du langage PERL car:
  • possède un module d'abstraction de BD
  • est le langage le plus complet pour l'utilisation des expressions régulières
  • libre et disponible sur Linux comme sous Windows

Interfaces des outils


Besoins :

  1. services XML interrogeable mais avec accés limité
  2. interface de consultation générale (comme l'index des plantes actuel) proposant seulement l'affichage des projets considérés comme référence.
  3. interface de travail (administration et consultation) sur la base

Solution technique du besoin A :

  • langage : php (courbe d'apprentissage courte) / Java (courbe d'apprentissage longue)
  • Abstraction de base de données : PEAR / JDBC
  • moteur XSL : à définir (actuellement Sablotron) / Cocoon
  • Base de données centrale sur le serveur de Tela : Postgresql ou Mysql
Actuellement, les services XML sont fournis par des scripts php. Nous utiliserons leur trame pour le développement des nouveaux services XML et nous les compléterons avec l'utilisation de PEAR.
Dans tous les cas, l'utilisation des services XML dans un but de création d'interface de consultation via XSL sera disponible pour les organismes nous en faisant la demande moyennant contrepartie (due à la montée en charge du serveur).
L'accès aux services XML devra être sécurisé (mot de passe). Les interfaces d'administrations que nous développeront auront accés à ces services si nécessaire.

Solution technique du besoin B :

  • langages : php, html, javascript
  • Méthode d'obtention des données : requêtes SQL
  • Abstraction de base de données : PEAR
  • Base de données centrale sur le serveur de Tela : Postgresql ou Mysql

Nous pourrions utiliser les services XML, pour réaliser cette interface mais la proximité de la base de données sur le serveur de Tela incite à courcircuiter cette étape (qui ralentit la consultation ...) en attaquant la base directement en SQL.
En outre, si l'on développe les interfaces de travail (besoin C) nous pourrions réemployer le code (du moins en partie) ainsi réalisé.

Solution technique du besoin C :

Deux solutions développées en paralléle :

1.Solution PHP :

  • langages : php, html, javascript
  • Interface d'utilisation graphique : utilisation des navigateurs WEB
  • plateforme : toutes
  • Abstraction de base de données : PEAR
  • Méthode d'obtention des données : requêtes SQL
  • [Base de données en mode déconnecté : mysql]
  • [Serveur WEB en mode déconnecté : Apache]
  • Base de données centrale sur le serveur de Tela : Postgresql ou Mysql
  • Fonctionnalités de l'interface :
    • Etape 1 : gérer toute la base sauf création de classifications, de descriptions, de taxons et de clefs de déterminations.
    • Etape 2 : permettre la gestion de l'ensemble de la base en mode connecté.
    • Etape 3 : permettre la gestion de l'ensemble de la base en mode connecté ou déconnecté.

2-Solution Java :

  • langages : Java
  • Interface d'utilisation graphique : oui mais à réaliser !
  • plateforme : toutes
  • Abstraction de base de données : JDBC
  • Méthode d'obtention des données : services XML
  • [Base de données en mode déconnecté : mysql]
  • [Serveur WEB en mode déconnecté : pas nécessaire]
  • Base de données centrale sur le serveur de Tela : Postgresql ou Mysql
  • Fonctionnalités de l'interface :
    • Etape 1 : permettre la création de classifications, de descriptions, de taxons et de clefs de déterminations.
    • Etape 2 : permettre la gestion de l'ensemble de la base en mode connecté.
    • Etape 3 : permettre la gestion de l'ensemble de la base en mode connecté ou déconnecté.

3-Solution X-Internet :

  • langages : XUL
  • Interface d'utilisation graphique : utilisation du navigateur WEB Mozilla
    • Plateforme : toutes
    • Abstraction de base de données : Aucune
    • Méthode d'obtention des données : services XML
    • [Base de données en mode déconnecté : Aucune]
    • [Serveur WEB en mode déconnecté : pas nécessaire]
    • Base de données centrale sur le serveur de Tela : Postgresql ou Mysql
      • Fonctionnalités de l'interface:
        • En mode connecté:
          • Passage du mode consultation (pages HTML) au mode modification d'un simple click (comme dans ce wiki).
          • Possibilité de sauvegarder sur sa machine certaines données pour les modifier hors connexion.
          • Possibilité de charger des données modifiées hors connexion et de les envoyer au serveur de Tela-botanica.
        • En mode déconnecté:
          • Possibilité d'éditer les données préalablement sauvegardées.

Concernant le mode de travail connecté ou déconnecté

Pour ces deux solutions, il serait idéal de mettre en place un protocole de travail en mode connecté ou pas. Le principe devrait être équivalant à celui de CVS.
La gestion du mode de connection rendant le projet plus complexe, les développement géreront seulement le mode connecté dans un premier temps.

En mode de travail connecté :
  • tout se fait directement sur la base de données centrale du serveur de Tela Botanica.

En mode déconnecté :
  • c'est une base de données locale (Mysql) qui est utilisée où toutes les modifications sont enregistrées.
  • au démarage de l'application un protocole permet de savoir dans quel mode on travaille
  • l'utilisateur peut décider de mettre à jour sa base. Les données qu'il a modifié ne sont pas mises à jour.
  • l'utilisateur peut décider de mettre à jour la base sur le serveur de Tela Botanica. S'il les données ont été modifiées par une autre personne entre temps, l'utilisateur en est averti. Il doit pouvoir voir les différences, réaliser des modifications et enfin décider de mettre à jour les données sur le serveur.

Concernant les classifications, descriptions et clefs de déterminations

Nous utiliserons des documents au format XML pour les stocker

Pour les trois types de documents :

Besoin d'un service XML qui se contente uniquement de stocker le document tel quel dans la base de données d'eFlore
(c'est la nouveauté et très facile à faire en PHP: bref on analyse plus le XML).
On pourra dans l'application cliente récupérer également ces documents via un service XML qui n'aura qu'à renvoyer le XML puisque stocké sous sa forme brut dans la base (également très facile à faire en PHP puisqu'il ne fait pratiquement rien).

Pour les descriptions et les clefs de déterminations :

Besoin de réaliser en Java ou dans un autre langage un logiciel qui tournera périodiquement sur le serveur de Tela. Ce programme aura comme fonction de générer pour tous nouveau document XML inséré dans notre base de donnée, la représentation HTML de celui-ci, via XSL (pourquoi pas via cocoon ?).
Une fois cette représentation générée on la stocke dans la base de donnée, elle sera utilisée par les interfaces de consultation de la base de données.
Petite remarque complémentaire , en réalité il faudra également régénérer la représentation HTML, si certain éléments référencés dans le XML sont modifiés (un bon système de flag devrait permettre de gérer cela). De toutes façon cette régénération ne prendra pas beaucoup de temps car nous n'aurons pas des dizaines de clefs ou descriptions par jour.

Pour les classifications :

Besoin de réaliser en Java ou dans un autre langage un logiciel qui tournera périodiquement sur le serveur de Tela.
Ce programme aura comme fonction de remplir pour toute nouvelle classification en XML inséré dans notre base de donnée, les tables concernant les classifications, et également de modifier le statut des documents HTML devant être régénérés car impactés par la modification de la classification.