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.