Eros Web Services

17 Janvier 2022

Présentation

Le projet d'un serveur web pour accéder aux données Eros est une idée ancienne qui n'a jamais abouti. Le transfert au CDS d'une partie des résultats de l'expérience remet le projet en lumière.

Diverses mises en oeuvre peuvent s'envisager. L'une d'elle, présentée dans cette note, s'appuie sur les développements réalisés pour la gestion des données Eros au Centre de calcul. La note étudie la mise en oeuvre de services répondant à des requêtes sur le modèle que l'application ReportImages [voir https://erosdb.in2p3.fr/ErosDb/outils-erosdb/#report-images], à savoir le passage des éléments de la requête à la base de données sous la forme de couples clé valeur.

Description

Les services étudiés doivent répondre à des requêtes du genre «trouver les images du LMC pour le champ 001, la caméra 0 et le CCD 5 de l'expérience Eros 2», ou encore «obtenir la liste des étoiles et leurs courbes de lumière pour une zone particulière».

Dans l'implémentation étudiée dans cette note, les paramètres de la requête sont transmis via l'URL du service web. Les résultats sont retournés soit sous la forme d'une simple liste soit comme une table HTML. D'autres formats peuvent être supportés : XML, CSV, ...

L'exemple suivant n'est qu'un exemple basé sur le mécanisme de requêtes mis en place dans l'application ReportImages, mais il donne une idée générale du service proposé :

http://erosdb.in2p3.fr/reportimages?eros=2&objet=lm&champ=001&camera=0&ccd=5&report=filename

L'URL est celle du serveur ErosDb à Lyon, le nom reportimages indique le service interrogé, l'expression eros=2 désigne l'expérience Eros 2, les attributs objet, champ, camera et ccd décrivent les caractéristiques des images cherchées, l'attribut report désigne les attributs à présenter – dans cet exemple le nom des fichiers correspondant aux images sélectionnées.

Dans l'exemple, le résultat est retourné comme une simple liste des chaînes de caractères. Il est aussi possible de définir le format de présentation par un critère format=html, format=xml ou format=csv.

Pour récupérer les fichiers correspondant aux images sélectionnées dans l'exemple précédant, un second service est nécessaire : 

http://erosdb.in2p3.fr/getfile?filename=/eros/data/eros2/fits/lm/lmc001.../sm001....fits

La connexion des deux services au sein d'une application web côté client est donc nécessaire pour effectuer une sélection et récupérer ensuite les fichiers. Des services plus élaborés sont envisageables, mais une première étape serait la mise en place une maquette de démonstration.

L'intérêt de l'approche proposée est que les services décrits sont utilisables indépendamment du contexte d'utilisation ou du langage de programmation. On peut même envisager une utilisation depuis un script Bash et wget.

Points à préciser

La mise en place de services Web implique nécessairement de définir la politique d'accès à ces services. En d'autres termes, qui est autorisé à émettre des requêtes de sélection et qui est autorisé à récupérer les fichiers ? Et en quel volume ? Avec pour corollaire : comment procéder aux vérifications... ?

Mise en oeuvre

La mise en oeuvre de ces services peut sans doute se faire de multiples manières, mais les plus réalistes sont l'utilisation d'un environnement existant, non payant de préférence, ou le développement des services en Java.

L'utilisation d'un environnement existant suppose 1) d'identifier les candidats et de les évaluer; mais surtout 2) d'obtenir de Lyon l'installation de l'environnement retenu...

Le développement Java présente l'intérêt de s'appuyer sur la librairie ErosDb développée pour le support des données de l'expérience. Cette librairie intègre déjà les outils d'interrogation de la base de données et d'accès à Irods, ainsi qu'un modèle pour le traitement des requêtes – utilisé par exemple dans ReportImages ainsi que dans les autres outils de requêtes et de transferts [voir https://erosdb.in2p3.fr/ErosDb/outils-erosdb/]. La difficulté encore une fois est d'obtenir du Centre de calcul l'installation des outils nécessaire, à savoir une version de Java à jour et un serveur capable de supporter ces services.

A l'inverse, il parait exclu de développer de tels services à partir de langages plus exotiques, genre PHP, puisqu'il faudrait réécrire l'encodage des mots de passe, la gestion des accès à la base de données et perdre le support des accès directs à Irods. Cette question de l'accès à Irods se pose également pour des environnements préexistants.

Langage de requête

Dans les exemples présentés, les requêtes sont construites à partir de critères simples : identité entre un attribut des images cherchées et une valeur. Une extension à des opérateurs relationnels usuels, comme par exemple plus petit, plus grand, plus petit ou égal, plus grand ou égal, mais aussi nul ou non nul, ou l'appartenance à un intervalle ou à une liste – bref, les différents opérateurs SQL – pourrait être envisagée, en fonction des besoins exprimés.

Notes techniques

Le développement de Web Services Eros en Java s'appuie sur deux types d'éléments : des JSP et des servlets.

Une servlet est une application légère Java s'exécutant au sein même du serveur HTTP. Ceci permet de bénéficier du parallélisme naturel de Java grâce au multithreading, mais surtout évite d'avoir à lancer des processus extérieurs pour traiter les requêtes, avec un accroissement très certain des performances.

L'exécution d'une servlet nécessite un container de servlets. Tomcat, de la fondation Apache, est la référence dans ce domaine. Lorsqu'une requête est adressée au serveur sous la forme d'une URL, celui-ci consulte un fichier de description et s'il trouve une définition correspondant à l'URL, passe le contrôle à la servlet déclarée. Celle-ci reçoit les éléments de la requête ainsi que le canal de sortie pour transmettre la réponse. Si le serveur ne trouve aucune définition pour l'URL reçu, il tente de trouver un fichier correspondant et le renvoie. En cas d'échec, il retourne la fameuse page 404 (vestige du vieux VM/CMS et/ou du véhicule du concepteur ?) ou si celle-ci n'existe pas sa propre version du message d'erreur.

Un exemple d'utilisation de ce mécanisme est le suivi d'une production, par exemple le transfert des images calées astronomiquement (mais ça, c'est fait) ou la numérisation des plaques Eros 1. La servlet de consultation de la base de données construit un rapport sous la forme d'une table HTML et la renvoie. Une page du site Eros contient un lien du genre «si vous voulez savoir où on en est, cliquez ici». Lorsque l'utilisateur clique sur le lien, la servlet est invoquée et le navigateur présente la page reçue qui contient la table actualisée de la numérisation des plaques.

Mais ce mécanisme présente l'inconvénient de solliciter l'intervention de l'utilisateur. Une autre présentation consisterait à présenter directement la table actualisée dans la page, genre «voici l'état de la numérisation des plaques».

Une telle présentation n'est pas possible avec du HTML standard, c'est-à-dire statique. La solution usuelle est de faire intervenir un langage de scripting côté client, genre JavaScript. Mais une approche bien plus efficace mais surtout beaucoup plus gérable est de réaliser le traitement du côté du serveur : lorsque la page est consultée, un mécanisme de génération dynamique de page est activé et la base de données est interrogée. La page intégrant les éléments statiques ainsi que la table construite dynamiquement sont retournées. Usuellement, une telle page dynamique est écrite en PHP, mais dans le cadre du projet ErosDb, la solution est évidemment d'utiliser une JSP afin de récupérer les développements déjà réalisés.

Une JSP est une page HTML standard autorisant l'utilisation de balises spéciales. Ces balises permettent principalement d'exécuter du code Java ou de réaliser différentes opérations, comme par exemple construire un rapport à partir d'une requête à la base de données. Il convient de noter à ce sujet qu'il n'est pas nécessaire d'invoquer la servlet précédente : l'appel à une méthode de la bibliothèque est plus simple – cette méthode pouvant par ailleurs être utilisée par la servlet...

Tous les serveurs HTTP ne supportent pas les JSP. Encore une fois, Tomcat propose ce support. L'extension jsp à la place de htm ou html indique au serveur qu'il traite une JSP. Le serveur interprète la page et la convertie en une servlet exécutée au sein de la machine virtuelle du serveur.

Pour résumer, le support de web services Eros, c'est-à-dire la génération de pages dynamiques, s'articule autour de deux ensembles d'éléments Java : des servlets, pouvant être invoquées par des sites extérieurs, par exemple depuis le CDS; et des JSP, intégrées au site ErosDb.

Remarques

Le compilateur Java usuellement disponible dans la sphère de la physique est une version préhistorique truffée de bugs et de failles de sécurité. La mise en place d'une version un tantinet moderne est toujours une épreuve et depuis très longtemps, le projet ErosDb survie avec sa propre installation d'un Open JDK utilisable – la version 16 actuellement.

Mais pour pouvoir déployer des services Java pour Eros, il faut que le serveur propose une version de Java capable d'utiliser la librairie ErosDb, ce qui nécessite l'installation de Java 16 sur le serveur.

De même, il est nécessaire que le serveur supporte un container de servlets, typiquement Tomcat.

Ces deux conditions supposent des négociations, traditionnellement assez âpres, avec le Centre. Et donc une volonté plutôt forte de la part de l'expérience.


Pour permettre un accès transparent à la base de données et à Irods, la librairie ErosDb utilise des fichiers de configuration contenant les mots de passe encodés. Les fichiers utilisés par les services Web doivent donc être installés sur le serveur. Pour éviter tout risque, les comptes utilisés tant pour Irods que pour Oracle, sont des comptes basiques, sans privilèges, autorisés uniquement à lire les données.


Contrairement aux applications en ligne proposées dans le projet ErosDb, les services web envisagés n'autorisent pas l'usage de raccourcis dans l'expression des requêtes. Les requêtes incorrectes sont rejetées avec une description de l'erreur rencontrée et un lien vers la page de description des paramètres supportés. L'aide en ligne peut être fournie par exemple par la page correspondant à l'URL sans requête exprimée. Par exemple : http://erosdb.in2p3.fr/reportimages?objet=lm&... traitera la requête, alors que : http://erosdb.in2p3.fr/reportimages seul présentera la description du service.


La politique d'accès aux données n'est pas prise en compte dans cette étude, mais comme les contraintes induites par les choix de l'expérience pourraient avoir des conséquences en ce qui concerne les implémentations, il serait souhaitable que ces choix soient précisés assez rapidement.

Prochaines étapes

Les prochaines étapes devraient être :

  1. rechercher et évaluer un ou des environnements préexistants capables d'interroger la base de données Eros et de transférer les fichiers Irods;
  2. faire la démonstration de services Java, mais en dehors du Centre;
  3. définir la politique d'accès aux données Eros;
  4. préciser les conditions d'utilisation de l'outil afin d'affiner les services à mettre en place.

Planning

La partie ‟maquette Java”, pour avoir un sens, doit pouvoir être présentée en démonstration dans les 3 mois à venir. Comme la plupart des outils existent et que le cahier des charges est relativement modeste, ce délai semble réaliste.

Dans le même temps, rien n'interdit à d'autres intervenants d'explorer d'autres voies : environnements existants, services Web Irods, ...

Et il serait également souhaitable qu'un groupe de réflexion soit mis en place afin de préciser plus clairement les besoins, et en particulier les contraintes de l'expérience Eros et les attentes d'utilisateurs extérieurs, comme le CDS.