Brevet/SandBox/brevet.txt

GridFTP is an extension of the File Transfer Protocol (FTP) for grid computing.
There are multiple implementations of the protocol; the most widely used is that provided by the Globus Toolkit.

Infrastructure

trouver l'infrastructure de test --> elixir (ELIC), ELI ? SGSI ?
connexion en GB: CISM (DCIII) ou SGSI (Pythagore, Cyclotron)
configuration: environnement Linux, gateway, vrtualisation (docker, virtualBox ?), agrégation de liens, etc
using a GridFTP client
installing and configuring a GridFTP server
persistence et reproductibilité aisée de la configuration (via Ansible ?)
trouver l'infrastructure de production (stockage, contrôle, etc)
versionning du projet: git ou mercurial
synergie: CISM - SRI - ELI/ELIC

Application

architecture 3-tiers à client léger

couches présentation & middleware:
plusieurs langages possibles: PHP, R, python, Java, Nodejs
choix (ou pas) de frameworks associés: Zend ou Symfony, Shiny, Django, Spring, Express, etc.

couche middleware:
objectif de programmation fonctionnelle (scala ?)
Idéal: "Language Agnostic" pour les différentes tâches 

couche accès aux données: MongoDB, MySQL, PostgresSQL
1) simple (via MySQL)
2) puis via DB distribuée.
   - multi-sites UCL
   - puis multi-sites extérieurs ?

Données

- données locales, traitement "on the fly", DB(s) locales 130.104
- données externes 
  - à posteriori (DB & protocoles connus)
  - à priori (infos de structures à soumettre)
- données externes
  - indexées: traitement "on the fly" (batch process possible sur DB distante)
  - non-indexées: traitement différé (DB distante accessible en interactif uniquement)

Scénarios pour les données à posteriori et non-indexées:
- téléchargement tiers + demande d'intégration aux DB locales
- téléchargement à travers l'appli + intégration auto aux DB locales

Catégorie(s): Application scientifique, application web, application de gestion

Ce projet a pour but de créer une interface de gestion de données sous forme de web service. Le but étant de créer une application web conforme à l'architecture REpresentational State Transfer (REST), une architecture orientée services (SOA) avec le patron de conception modèle-vue-contrôleur (MVC). 

https://en.wikipedia.org/wiki/Minimum_viable_product

    Introduction
        Contexte : Décrire brièvement l’environnement dans lequel s’inscrit le projet (stratégie, enjeux, domaine, etc.)
        Historique : Donner un bref historique du contexte dans lequel s’inscrit le projet
    Description de la demande
        Les objectifs : Définir les résultats que le projet doit atteindre
        Produit du projet : Proposer une description générale de ce produit
        Les fonctions du produit : Lister et justifier les principales fonctionnalités du produit
    Contraintes
        Contraintes de délais : Spécifier la date de livraison du produit et les éventuelles échéances intermédiaires
        Contraintes matérielles : Spécifier le matériel nécessaire au bon fonctionnement du produit
        Autres contraintes : Spécifier les éventuelles contraintes à prendre en compte dans le cadre du projet (normes techniques, clauses juridiques, etc.)
    Déroulement du projet
        Planification : Représenter les grandes phases du projet et les étapes principales
        Ressources : Lister les ressources humaines et matérielles
        Organisation : Décrire l’ensemble des activités introduites dans l’organigramme des tâches de la gestion de projet (Décomposition en tâches, Structure des équipes)

https://www.appvizer.fr/magazine/services-informatiques/framework/django/developpement-web-serveur-ou-client

http://apprendre-python.com/page-django-introduction-python

Un framework est un cadre qui permet de structurer le travail des développeurs grâce à un ensemble d'outils, une structure et des modèles prêts-à-l'emploi.
Étant donné l'étendue des développements à effectuer pour concevoir une application Web moderne, un framework est indispensable.

Django est un framework Backend Open Source développé en Python. Il a été spécialement créé pour réaliser des sites Web puissants et de haut niveau.
Python est un avantage car c'est le langage le plus utilisé par les chercheurs en ELIC. En outre, les services IT de l'UCL utilisent également ce framework pour les nouveaux développements web.
Une alternative solide est Ruby on Rails (RoR). Il est le framework MVC libre le plus populaire. Ce framework a été conçu pour développer des applications Web plus rapidement. Il permet aux développeurs de créer des fonctionnalités avec moins de code que d'autres frameworks. 
Mais si RoR nécessite peu de configuration, il exige aussi plus de conventions. En outre, Le niveau d'expertise pour se lancer est une barrière à l'entrée pour les débutants. Enfin Ruby nécessite des ressources serveur plus importantes que Django et des frameworks PHP, et sa technologie comme son utilisation sont en déclin.

Framework Full-Stack (il est très facile de combiner Django et Angular) et tout clé en main : modèles, côté serveur, panneau d'administration pour configurer un site sans coder, etc.
Il utilise le patron de conception modèle-vue-contrôleur (MVC), c'est à dire que la structure du framework sépare les données (models) qui sont séparées des traitements (controller) qui sont eux-mêmes séparés de la vue (view/template).
C'est également un outil idéal pour un projet collaboratif.

Enfin, Django étant très populaire auprès des développeurs web, de nombreux projets sont apparus autour du framework. Par exemple dans notre cas, Ncdjango est un ensemble d'outils de gestion de données et de géotraitement écrits en Python qui fonctionnent sur des données NetCDF.

Application web serveur Python/Django (raison: choix en interne UCL) + Docker

https://blog.imirhil.fr/2016/10/09/docker-container-hell.html

Environnement de développement avec Vagrant

Docker est un logiciel libre qui automatise le déploiement d'applications dans des conteneurs logiciels. "Docker est un outil qui peut empaqueter une application et ses dépendances dans un conteneur isolé, qui pourra être exécuté sur n'importe quel serveur Linux". Ceci permet d'étendre la flexibilité et la portabilité d’exécution d'une application.

Django est un cadre applicatif open-source de développement web en Python (Framework), et il a pour objectif de rendre le développement web simple et rapide. Il embarque tous les composants utiles, que ce soit la gestion de vues, authentification, le mapping objet-relationnel, une documentation détaillée, etc.

PyCharm est un environnement de développement intégré utilisé pour développer en Python ainsi qu'avec Django. Il propose la possibilité de débuger en direct dans un conteneur Docker.

Vagrant est un logiciel libre et open-source pour la création et la configuration des environnements de développement virtuel. Il peut être considéré comme un wrapper autour de logiciels de virtualisation comme VirtualBox.

https://www.supinfo.com/articles/single/5779-bien-debuter-avec-django-docker

Scaling Django: https://djangobook.com/scaling-django/

Django est généralement considéré par de nombreux développeurs comme un framework Web MVC, mais il peut également être utilisé pour créer un back-end (développement orienté serveur), qui dans ce cas est une API.

Comme nous souhaitons mettre à disposition des données pour quelles soient utilisées sur d’autres plateformes ou que nos données intéragissent avec d’autres, une architecture REST ("REpresentational State Transfer") semble appropriée ici.
L'architecture REST est plus axée sur un modèle orienté ressources (les données, dans notre cas) que sur un modèle orienté fonctions. Elle imite la façon dont le web lui-même fonctionne dans les échanges entre un client et un serveur.
REST constitue donc une méthode d'intégration efficace puisque le service à développer ici concerne surtout la récupération de données. Aussi, plutôt que de définir toute une API (interfaces de programmation d'application) personnalisée mieux vaut utiliser un standard de manipulation des données CRUD (Create, Read, Update, Delete : créer, lire, mettre à jour, supprimer), qui "correspond" aux opérations HTTP (HyperText Transfert Protocol) GET, PUT, POST et DELETE. Ce fonctionnement ne repose pas sur la seule utilisation de ces opérateurs, mais sur une combinaison avec des URI.

Le "Django REST framework" va nous permettre de créer plus facilement une API REST sur notre application Django.

Un interfacage avec Amazon S3 serait un atout supplémentaire

https://medium.com/backticks-tildes/lets-build-an-api-with-django-rest-framework-32fcf40231e5

https://medium.com/python-pandemonium/building-and-deploying-an-enterprise-django-web-app-in-16-hours-79e018f7b94c

L'URI constitue la clé unique d'une ressource spécifique. Si cette ressource affiche des relations avec d'autres ressources – par exemple, une Commande associée à une Personne – les URI jouent le rôle des clés étrangères qui permettent de parcourir ces relations. Sachant que l'architecture REST tire parti de la technologie d'hypermédia en tant que moteur de l'état des applications HATEOAS (Hypermedia As The Engine Of Application State), il ne reste plus à l'utilisateur qu'à extraire l'URI de la représentation de la ressource et d'exécuter une opération HTTP GET pour accéder aux informations.

La seule élimination de WSDL et SOAP ne donne pas une architecture REST.

Parallèlement, la technologie HATEOAS est essentielle à la flexibilité. Que se passe-t-il lorsque la structure doit changer ? Si le parcours vers ces relations est spécifié dynamiquement via des liens intégrés à la réponse, vos utilisateurs n'ont pas forcément besoin de changer. De plus, ne pas être contraint à une définition et une validation d'interface rigides permet d'ajouter des éléments en fonction des besoins. Si c'est important pour l'utilisateur, il modifiera son code ; mais ce serait le cas avec n'importe quelle autre technologie.

L'approche HATEOAS est très importante mais malheureusement souvent oubliée. Beaucoup pensent que l'architecture REST consiste simplement à se débarrasser de l'enveloppe SOAP et du langage WSDL (Web Services Description Language), mais ce n'est pas le cas. L'architecture REST ne nécessite aucun langage de description d'interface, comme WSDL, et fonctionne parfaitement non seulement avec le langage XML (eXtensible Markup Language), mais aussi avec JSON (JavaScript Object Notation) et tout autre type de support que vous souhaitez prendre en charge.

C'est là sa grande force ; elle favorise la compatibilité au niveau de la couche de présentation, qu'il s'agisse d'une application bureautique, Web ou mobile. La seule élimination de WSDL et SOAP ne donne pas une architecture REST. Dans l'exemple Personne/Commande ci-dessus, le retour d'un code XML pour une Commande comportant un élément appelé <ID_Personne> ne rend pas le fonctionnement compatible REST, ou « RESTful », si l'utilisateur n'est pas en mesure d'effectuer une simple opération HTTP GET sur la valeur de cet identifiant. Un simple code XML/HTTP ne donne pas une architecture REST.

Autre défi de l'architecture REST, elle peut conduire à un modèle plus fin. Quand fournissez-vous un lien dans vos réponses, plutôt que les données réelles issues d'une relation ? Argument à décharge, il s'agit d'un choix conceptuel qui reste possible. Ainsi, rien ne vous empêche de renvoyer un lien à suivre, en même temps qu'une partie des données elles-mêmes. Considérez l'opération comme une jointure à laquelle s'ajouterait le renvoi d'une clé étrangère permettant d'obtenir davantage de données.
Enfin, si la simplicité de REST s'avère plutôt attrayante, elle rend parallèlement plus difficile la création d'outils adaptés. Si vous envisagez des services SOAP ou XML pour ces outils, WSDL ou XSD (ou les deux) sont essentiels à leur mise en oeuvre.

Avec REST, l'affaire est toute autre... Certains outils accepteront les POJO (Plain Old Java Object) ou un schéma relationnel, qu'ils exposeront via REST. De même, rien ne vous empêche de définir un schéma XML pour une représentation XML renvoyée par un service RESTful, et d'utiliser un genre d'API JAXB pour la conversion en Java. Ne perdez cependant pas de vue que s'appuyer sur ces fichiers – notamment si le schéma est repris au moment de l'exécution – génère des contraintes supplémentaires susceptibles de rendre plus coûteuse la prise en charge des modifications.

Globalement, je suis content que la question se soit posée de cette manière, et non du point de vue du classique débat SOAP ou REST. Dans des décisions de ce type, rien n'est absolu ; il y a des avantages et des inconvénients. Quiconque a travaillé dans un service informatique connaît les passions que déchaîne chaque approche et les nombreux exemples de réussites et d'échecs. Il est bien plus important de comparer les forces et les faiblesses de chaque approche à celles de votre organisation.

Pour résumer, si vous publiez une API complexe vers l’extérieur, SOAP vous sera plus utile. Mais pour quelque chose avec une courbe d’apprentissage rapide, des transactions simples et des résultats rapides, ma préférence va à REST.