Comparatif Pleinpot Saada Sitools
Ce document présente et compare trois logiciels pour le management, l'analyse et la publication des données (en particulier leur intégration dans l'Observatoire Virtuel).
-
Pleinpot est une collection d'applications et une library appelable en C, Fortran,
Python, PHP ou Java, pour organiser, traiter et distribuer les données. Il permet de
gérer une base de données astronomiques (catalogues de sources, collections de
spectres...) ou de créer un service compatible avec les normes de l'Observatoire
Virtuel (protocoles, formats) sans que l'utilisateur ou le développeur n'ait à
connaitre ces normes en détail.
-
Saada est un générateur de bases de données astronomiques destinées à héberger des données hétérogènes
de différentes catégories (images, spectres, sources). L'objectif de Saada est de permettre à de petites
équipes où à des individus de ranger leurs données dans des bases locales dotées de fonctionnalités de haut niveau.
La construction d'une base avec Saada se fait sans
écrire de code et ne necessite pas d'infrastructure particulière. Les données hébergées sont accessibles par
une interface Web, un API ou les protocoles VO.
-
SITools est un outil générique destiné à la mise en place de centres de données
scientifiques au sein de laboratoires. Il s'adapte aux catalogues de données existant
et permet de mettre à disposition des utilisateurs les données scientifiques, au moyen
de critères sur les métadonnées, ainsi que les services de traitement associés. SITools
est un outil interopérable qui s'adapte aux architectures distribuées et permet d'intégrer
des catalogues de données répartis de manière transparente.
Architecture, technologie, langages, bases
- Bases supportées?
-
Postgres.
L'adaptation pour Oracle exigerait des modifications de Pleinpot (2 jours de travail). Pour MySQL celà demanderait environ 10-15 jours.
-
Actuellement Postgres, Sybase (MySQL prochainement)
- Postgres, MySQL, Oracle
- Peut-on faire une même requête sur plusieurs bases en même temps?
-
On ne peut pas faire de join entre des tables de bases de donnees differentes, mais une
meme requete peut acceder simultanement a diverses bases de donnees ou services locaux
ou distants. Nous n'avons pas d'implémentation de VOQL. Avec Pleinpot, on peut évidemment avoir un interface commune pour acceder à plusieurs bases de données, mais on ne peut pas faire quelquechose comme:
SELECT base1:table1.field1,base2:table2.field2 FROM base1:table1,base2:table2 where base1:table1.id=base2:table2.id
où les deux tables 'table1' et 'table2' sont sur deux bases différentes.
-
On ne peut faire des requêtes que sur une seule base (une SaadaDB).
Toutefois, une SaadaDB contient des produits hétérogènes repartis dans plusieurs tables et on peut faire des requêtes sur plusieurs tables dans une même base.
-
Oui une instance de sitools peut interroger simultanément plusieurs catalogues, eux mêmes composés de plusieurs bases (pouvant être des SGBD différents).
- Si oui, l'outil gère-t-il un dictionnaire de synonyme pour permettre d'établir l'équivalence entre des champs qui ont des labels différents dans des tables différentes?
-
Oui.
A chaque table est associée une table de meta-data, dont en particulier l'UCD (facultatif).
Les UCD ne sont pas utilisés (pour l'instant) dans les requêtes pre-implémentées
dans le système.
-
Les UCDs associés au traitement des unités sont en cours d'implémentation au niveau du langage de requêtes
(IVOA Mai 2006)
- Oui. Le mécanisme de synonyme est aussi doublé d'un mécanisme de convertisseur permettant d'appliquer des conversion à la volée entre attributs similaire (ex. envisageable Température en °Celsius d'un côté en Kelvin d'un autre, ou bien radian/degré).
- Accès à des bases distantes possible? (si oui, type d'accès à ces bases : direct via login/passwd, ou indirect, via web-services fournis par les serveurs distants)
-
Oui.
Pour les bases gérées par Pleinpot, utilise les modes de connections de Postgres (IP).
Pour les autres services, implémentations ad hoc via les outils fournis par les services distants
(ftp client, http).
-
Une base Saada peut être accédée directement par le Web et les sources peuvent être sélectionnées par Web-Services (ADQL).
L'API permet d'accéder aux données par le biais de JDBC.
- Les deux sont possibles. Pour interfacer la base de données, le module 'catalogue' de SITools utilise JDBC (pour ce faire il utilise une connexion à la base de données via login password). Donc si on place le service catalogue sur la même machine que la ou les bases de données, il suffit de n'ouvrir à l'extérieur que l'accès webservice au module catalogue et on peut restreindre l'accès à la base de données en local. Du coup le module catalogue peut servir de proxy à la base de données.
- OS possibles pour le serveur? (si linux, distribution linux imposée?)
-
Linux et MacOS (environnements de développements)
Solaris et OSF en principes testes au moment des releases.
Des installations ont été réalisées sur AIX et HP-UX dans le passe.
Le script de configuration doit detecter les problemes.
-
Saada fonctionne sous Linux et Solaris. Une beta version fonctionne sous Windows (et sera bientôt disponible)
- Windows / Linux (a priori tous les OS où Tomcat et java peuvent tourner)
- Serveur HTTP possible (Apache, autre?). Version imposée? Modules à installer (mod_jk, mod_ldap, etc)
-
Pas de contrainte spéciale pour l'exécution de cgi.
Module php4 si l'interface est faite en php, et python si l'interface est en python
-
Tomcat est conseillé (l'utilisation de tout serveur d'application supportant les servlets est à priori possible)
- Apache 2 avec mod_jk pour tomcat (on utilise le module en version 1.2.13. Il est possible que cela fonctionne avec des versions différentes mais les tests n'ont pas été réalisés.)
- Si java est utilisé, version de java imposée?
-
Une API Java est offerte (construite avec swig, en version alpha). Pas de contrainte de version connue.
- Java 1.5
- SITools tourne désormais avec Java 1.5 et Tomcat 5.5.
- Langage de conception de l'outil (java, fortran, C, etc)
-
Library: C et Fortran.
Certains éléments sont en sh, perl... et il y a des programmes de tests dans les langages pour lesquels
des API sont fournies.
- Java 1.5
- développé en java (j2ee)
- Technologie utilisée pour la création dynamique des pages (cgi, jsp+TOMCAT)
-
cgi programmes en C ou en Fortran (les deux existent en production)
ou bien Python, PHP, Java (à ma connaissance pas encore utilises en production).
-
Java servlets incluant des pages fixes, des feuilles de styles et du code Javascript.
- Tomcat + JSP
- Que faut-il modifier pour modifier la forme des pages-réponses (fichiers de configuration XML, HTML, jsp, C, fortran, java, etc)
-
Le contenu et le formatage de la réponse sont contrôlés par des paramètres de la requête.
Une customization des pages peut être faite de différentes manières:
- écrire un cgi utilisant la library à différentes profondeurs possibles (demande de se familiariser avec la library).
- écrire des fonctions dynamiquement chargeables, en C, Fortran, Pyton, PHP (ou Java) qui appelle
ou non la library
- utiliser des feuilles de styles pour agrementer la presentation.
- Fichiers HTML et/ou Code Java
- modification au niveau des fichiers de conf XML et .properties, CSS, JSP (pas de modif à faire dans le code java, ni les servlets).
- Bases de donnée avec plusieurs tables supportées / une seule table par base?
-
Pas de limitation (connue) sur le nombre ni la taille des tables. Les tables sont sémantiquement groupées en "catalogues", eg. une table de mesures, une table décrivant les méthodes de mesures et une table de bibliographie. Pas de limitation connue sur le nombre de catalogues.
-
Saada propose un modèle de données basé sur le concept de collections. La collection est une entité pouvant contenir plusieurs tables et la SaadaDB peut contenir plusieurs collections.
-
Pas de limitation sur les tables. SITools s'adapte à l'existant, il est sulement nécessaire de rajouter quelques table supplémentaire pour décrire les tables existantes. Les tables de description sont propres à SIToosl et ont une structure précise. Par contre il n'y a aucune restriction sur la structure des tables de données existantes.
Fonctionnalités
- Type possible de récupération de données (en ligne, récupérable par ftp avec mail qui prévient quand c'est disponible, etc)
-
réponse http avec une variété de formats possibles (txt, html, VOTable...), éventuellements customizables.
-
Les fichiers FITS chargés dans la base peuvent être téléchargés. Les sélections SIAP et ADQL peuvent être récupérées sous forme de VOTables.
- Si les données sont accessibles en ligne, il est possible de les récupérer via un lien dans l'interface de SITools. Il est aussi possible de les commander et de les récupérer sur espace utilisateur, via un lien ou bien dans un zip directement téléchargeable. Enfin il existe un plugin FTP pour déposer les données sur un site FTP (il faudra le modifier très légèrement pour l'envoi d'un mail).
- Possibilité de créer des traitements (i.e. des fonctions élémentaires ou Service à Valeur Ajoutés, SVA) applicables ensuite par les utilisateurs sur les données (par exemple : compression des données (zip), ou création d'un image jpg qui contient le plot d'une courbe y=f(x))
-
Oui.
Les briques de pipeline peuvent être définies par des fonctions dynamiquement chargeables.
Il est possible d'exécuter un pipeline entre plusieurs machines.
-
Saada dispose d'une API Java permettant de faire des traitements sur les données de la base. Cette API est read-only.
Le résultat des traitements ne peut être stocké dans la base sans passer par le loader.
- sitools a été développé dans ce sens, il existe donc des SVA déjà écrits dans le noyau de base de sitools ainsi que des exemples et un environnement de développement pour écrire ses propres servlets.
- Possibilité pour l'utilisateur de définir à la volée une séquence de traitements sur les données (i.e. un pipeline, créé à partir de fonctions élémentaires)?
- Oui
-
Saada est un outil de stockage. La création ou la mise à jour d'une base (SaadaDB) peut être incluse dans un pipeline pour effectuer des
validations par exemple, mais cette base n'a pas vocation à contrôler un pipeline.
- Cela serait possible via un SVA permettant d'en lancer plusieurs.
- L'outil permet-il de donner des droits d'accès différents à différents utilisateurs?
-
Non.
On ne définit que trois utilisateurs différents avec des droits spécifiques.
(superuser, owner of the db, consultation).
- Seul l'opérateur, celui que créé la base, a un droit d'écriture.
Tous les utilsateurs ont un accès en lecture à toutes les données.
- Oui, gestion des utilisateurs par groupes
- Mise à disposition d'un espace utilisateur pour stocker des données?
-
Non.
Certains services utilisant Pleinpot en production gèrent eux même des fichiers temporaires
(mais à ma connaissance sans aucun mécanisme d'anthentication).
On peut utiliser Pleinpot pour gerer ses propores donnees, dans ce cas, l'utilisateur peut faire ce qu'il veut.
-
L'objectif de Saada est de permettre à quiconque de créer une base sur sa propre machine, indépendemment de toute infrastructure tiers.
- oui.
- Création automatique de la base à partir de fichier FITS de données?
-
Oui.
Ou à partir d'autres formats.
- Oui à partir de règles de configuration.
- non.
Web-services et VO
- Existe-t-il une interface web permettant de faire des requêtes complexes avec une syntaxe du type SQL, ADQL ou VOQL?
-
Oui.
Langage de requête incluant SQL et des requêtes astronomiques standards avec spécification de traitement et de formatage du document de sortie. Protocoles standards IVOA (SSA...)
-
Sont actuellement implémentés:
- Traitement de requêtes SaadaQL (langage de Saada)
- Traitement de requêtes ADQL par WS
- Traitement de requêtes ConeSearch
- Traitement de requêtes SIAP (SSAP dans un avenir proche)
- non
- Possibilité de faire des recherches dans un cône (cone search) en « natif », i.e. de faire des recherches sur le ciel du type « position et rayon autour de la position » pour rechercher dans une base des objets dont on connaît la position sur le ciel (i.e. ascension droite et déclinaison) en faisant un « cone search ».
-
Oui.
-
Oui
-
non, pas actuellement
- L'outil est-il capable de répondre à des requêtes en renvoyant la liste des réponses dans un fichier au format VOTable? (fait // pas fait actuellement mais possible // pas possible)
-
Oui
-
Oui pour SIAP/CS/ADQL. Non encore implémenté pour les requêtes SaadaQL
-
pas fait mais possible via un SVA
- Les requêtes peuvent-elles être exprimées directement dans une URL (par ex, pour demander les images centrées sur (180.5,-30.4) et dans une région de taille 0.012°, quelque chose du style http://myimages.org/cgi-bin/VOimq?POS=180.5,-30.4&SIZE=0.012) (fait // pas fait actuellement mais possible // pas possible)?
- L'outil met-il en place les services compatibles avec SIAP (protocole d'accès aux images) et SSAP (protocole d'accès aux spectres)? (oui / envisagé / pas prévu)
-
Oui (au standard SIA 1.0 et SSA 0.93)
-
SIAP(SSAP en cours)
-
envisagé
- Les requêtes peuvent-elles être faites en faisant appel à un web-service plutôt qu'une interface web (fait // pas fait actuellement mais possible // pas possible)?
-
Non.
Mais c'est prévu.
-
Seulement pour ADQL
- Pas fait actuellement mais possible. L'ensemble des modules de SITools dialoguent entre eux via webServices (SOAP), il est donc possible de réaliser une requête en webservices mais ce n'est pas encore très "userFriendly". IL faudrait développer un petit proxy Client offrant une interface webservices claires et simple d'utilisation.
Divers
- Installation de l'outil sans support du concepteur (simple, difficile, impossible)
-
Simple pour quelqu'un ayant l'expérience d'installation de logiciel à partir de source.
Difficile pour une personne qui découvrira qu'il a installé sa machine sans les packages de développement
contenant les headers et les static libraries.
- L'installation est assez simple et ne requiert pas de faire appel à un tiers.
La simplification du déploiement est un axe majeur de développement.
- Documenté, installation simple avec support CNES, plus compliquée pour une personne seule (mais pas impossible !!).
- Sites web existants et utilisant l'outil
- HyperLeda (une douzaine de miroirs)
- Giraffe Archive
- Elodie
- Sophie (accès public le 1er Juillet)
- ASPID
- Klun+
- Fabry Perot database
-
Il y a une démo en ligne.
Deux bases sont en cours de développement: l'interface du second catalogue XMM et le Galactic Plane Survey du SSC de XMM
- Base de données Cassini : http://kronos.cesr.fr/cassini login : cassiniUser / mdp : cassiT11ls (ce sont des 'un' pas des 'L')
- Temps estimé pour l'installation de l'outil (à partir d'un poste n'ayant qu'un serveur HTTP installé) avant de mettre en place le lien avec une quelconque base de donnée?
-
La plateforme imposée est d'avoir les compilers C et Fortran ainsi que Perl (pas toujours nécessaire).
La plupart des libs nécessaires sont embarquées ou peuvent être évitées, mais il est hautement
préférable de les installer avant (mais normalement elle sont disponibles sur tout système propre
à faire du développement et installer des packages GNU depuis les sources).
Le temps minimum d'installation est de l'ordre de deux heures pour une personne experimentée
avec du logiciel GNU.
Pour une personne raisonnablement habile, ayant quelques notions sur Unix et suivant le mode
d'emploi pas à pas cela doit prendre une petite journée.
Pour une personne ne lisant pas la documentation, ça peut se faire en 1 heure s'il a
de la chance...
ou bien il ira bricoler à tord et à travers et devra finalement tout recommencer au début.
Il a toujours été facile d'aider les utilisateurs à faire l'installation.
- De une heure à .... selon la complexité des données à ingérer.
- Une journée (avec support CNES) à une semaine seul.
- Disponibilité du code source et type de licence? (code disponible en ligne? donné au cas par cas? licence GPL? autre licence?)
-
GPL
-
Source disponible sous licence GPL
- Code source disponible sur demande
- Estimation du nombre de (personne x an) pour le développement de l'outil jusqu'à aujourd'hui?
-
13 personnes.an, développement commencé en 1985.
- 3 personnes.an, développement commencé fin 2002
- 3 personnes.an (soit 1.5 personnes * 2 ans), développement commencé en 2004.
- Le développement de l'outil est-il fini? Si non, nombre de (personne x an) financé pour ses évolutions.
-
Le code est utilisable est utilisé en production.
Les développements envisages se répartissent en trois catégories sensiblement équivalentes:
- développement de nouveaux outils, suivant les besoins du GEPI
- l'amélioration de la qualité et le debuggage
- l'utilisations des nouvelles technologies et standards (en particulier VO).
-
Le développement continue avec un CDD IE pour 6 mois, des travaux de stages et une partie de mon temps.
- Développement quasiment achevé (recette finale fin du mois à priori)
- Organisme(s) et personne(s) responsable(s) de l'outil ?
-
Observatoire de Paris-GEPI, sous la responsabilité de Philippe Prugniel.
-
L'outil est développé à l'Observatoire de Strasbourg avec un soutien du CNES et de la région Alsace
-
CNES (thierry.levoir@cnes.fr à l'origine puis romain.conseil@cnes.fr)
- Visibilité sur le financement pour le développement + les corrections/évolutions + le support utilisateur de l'outil (à court, moyen, long terme)? (ou autre manière de poser la question : dans les 2 ans qui viennent, est-on sûr que l'outil est maintenu? Dans les 5 ans qui viennent? Après?)
-
Le soutien pour le developpement est conditionne aux besoins des projets scientifiques du GEPI, mais la communaute de developpeurs est ouverte.
-
La maintenance assurée pour les deux ans qui viennent et très certainement au delà du fait que Saada est utilisé par la mission XMM-Newton.
-
L'outil entre en garantie d'un an à partir de fin mai. Le budget pour les évolutions fonctionnelles à venir est en discussion.
- Type de support aux utilisateurs et nombre de personnes capable de faire ce support (pas de financement pour du support / hotline téléphonique => num. de tel et nom de la personne / support par mail ? )
-
Il y a huit développeurs sur sourceforge. Tous ne peuvent pas intervenir sur tous les aspects
(le code est assez gros, 300 klignes). Support par mail/telephone
-
Support par mail.
La création d'un communauté d'utilisateur est souhaitée
-
support CNES (cf. responsables outil). Il existe un forum utilisateur : http://sitools.forumpro.fr/index.forum et un site mis à jour au fur et à mesure : http://vds.cnes.fr/sitools