7.3 Génération de code . . . 125 7.4 Interface graphique d’aide au développement . . . 128 7.5 Cohérence des composants atomiques . . . 129 7.6 Conclusion . . . 131
Dans les chapitres précédents, nous avons défini une approche conceptuelle pour construire des services web, basée sur l’IDM. Nous avons spécifié notre méta-modèle dans le Chapitre 4, précisé des règles de cohérence structuelle des modèles dans leChapitre 5et fusionné l’approche avec OpenAPI, un méta- modèle utilisé dans l’industrie, dans leChapitre 6. Pour permettre l’utilisation de cette approche dans des cas réels, nous avons développé un outil.
LaSection 7.1présente cet outil et le processus de développement dans lequel il s’inscrit. LesSections 7.2et7.3détaillent la manière dont il vérifie et génère les services web. Enfin, lesSections 7.4et7.5montrent deux aspects qui peuvent être travaillés pour améliorer l’expérience développeur de l’approche.
7.1
SWSG : un outil au cœur de l’approche
Pour supporter notre approche de construction automatique de services web à partir d’un modèle OpenAPI 3.0 étendu (voirChapitre 6), nous proposons un outil nommé Safe Web Services Generator (SWSG) [46].
SWSG est un outil en ligne de commande qui a besoin de deux entrées pour fonctionner :
— un fichier de modèle ;
— le chemin d’un dossier contenant les implémentations des composants atomiques de ce modèle.
Processus de fonctionnement. La Figure 7.1 montre le fonctionnement de SWSG, qui se base sur quatre étapes séquentielles :
1. Analyse du modèle. Le modèle d’entrée est analysé pour déterminer s’il s’agit de la syntaxe concrète présentée dans laSection 4.3ou d’un modèle OpenAPI 3.0 étendu (voirChapitre 6). Dans le premier cas, la syntaxe concrète est transformée en une représentation interne proche de celle montrée dans laSection 4.2et l’étape 2 est ignorée. Dans le second cas, le modèle OpenAPI 3.0 est transformé en une représentation interne d’un modèle OpenAPI étendu ;
2. Transformation du modèle. Si le modèle est un modèle OpenAPI 3.0 étendu, il est transformé en une représentation interne proche de celle montrée dans laSection 4.2;
3. Vérification de cohérence. La cohérence structurelle (voirChapitre 5) du modèle est vérifiée ;
4. Génération de code. Le modèle et les implémentations des composants atomiques sont utilisés pour générer une implémentation des services web.
Transformation de modèle. Transformer des modèles OpenAPI 3.0 étendus en modèles compatibles avec notre méta-modèle est plutôt simple, sauf pour les parties liées aux schémas et types. OpenAPI définit des types de données primitifs et repose sur une version modifiée deJSON Schema Specification [27] pour les types de données complexes. Deux difficultés se posent :
OpenAPI
model Model parsing
Syntax OK? Failure
Start Transforming to SWSG model
Consistent? Consistency checking Generation AC implementations Web services Transformation OK? Stop Failure Failure yes yes yes no no no 1 2 3 4
Figure7.1 – Fonctionnement de l’outil SWSG
1. JSON Schema Specification est plus expressif que le système de types
de notre approche. Par exemple, il permet de définir des types raffinés, comme lorsqu’on spécifie la longueur minimum d’une chaîne de carac- tères ;
2. JSON Schema Specification supporte à la fois la définition littérale et par
référence des types des attributs de types complexes. En comparaison notre approche impose des types littéraux pour les types primitifs et des références vers d’autres entités pour les types complexes.
La deuxième difficulté est plutôt un problème technique qui peut être résolu en améliorant l’algorithme de transformation. Le premier problème est plus com- plexe car il nécessiterait une profonde modification de notre système de types pour que celui-ci supporte l’ensemble des types qu’il est possible d’exprimer dans OpenAPI.
Cependant, pour conserver la simplicité de notre méta-modèle et de SWSG, nous avons choisi de ne pas résoudre ces problèmes. En effet, ils ne nous empêchent pas de tester notre approche à ce stade. En l’état, SWSG peut donc renvoyer des erreurs lorsqu’on lui fournit des modèles OpenAPI contenant de tels types ou références dans les schémas, pourtant valides.
Technologies. SWSG est écrit en Scala1. Ce langage a été choisi pour le com- promis qu’il offre entre vérification (système de types moderne), flexibilité pour le prototypage et écosystème debibliothèques. Parmi lesbibliothèquesutilisées, on retrouve :
Cats. Des structures de données algébriques et autres mécanismes de la programmation fonctionnelle2;
Circe. Analyse, validation et sérialisation de données au format JSON3; Parboiled. Bibliothèquedeparser combinators qui simplifient l’écriture de
programme d’analyse syntaxique ; utilisé ici pour analyser la syntaxe concrète des modèles d’entrée4;
Twirl. Moteur de template ; utilisé ici pour la génération de code5;
Better Files. API plus simple et sûre que celle de Java pour la lecture et l’écriture de fichiers ; utilisé ici pour la lecture des fichiers d’entrée et l’écriture du code généré6;
Scopt. Analyse des arguments de l’interface en ligne de commande7; Scala.js. Compilation de code Scala vers du code JavaScript [16].
Une fois compilé, SWSG est facile à distribuer sous la forme d’un fichierJARet peut être exécuté dans de nombreux environnements. Par ailleurs, SWSG peut être compilé via Scala.js [16] pour obtenir un artefact exécutable par un inter- préteur JavaScript ; certains avantages associés à cette possiblité sont développés dans laSection 7.4.
Interface en ligne de commande. LeJARde SWSG peut être manipulé à tra- vers une interface en ligne de commande. LeListing 7.1montre l’aide intégrée à cette interface.
La commandejava -jar swsg.jarpermet d’exécuter leJARde SWSG. Direc- tement à la suite de cette commande, il est possible de spécifier des arguments séparés par une espace. Le premier argument doit avoir la valeurcheck, pour uniquement vérifier le modèle d’entrée, ougen, pour le vérifier et générer du code. Les paramètres suivants sont des options qui peuvent être placées dans un ordre quelconque et permettent de spécifier les chemins du modèle d’entrée, des implémentations d’entrée et du code généré, ainsi que le nom dubackend à
utiliser pour réaliser ladite génération8.
2. https://typelevel.org/cats/ 3. https://circe.github.io/circe/ 4. https://github.com/sirthias/parboiled2 5. https://github.com/playframework/twirl 6. https://github.com/pathikrit/better-files 7. https://github.com/scopt/scopt
8. Actuellement il n’y a qu’un seulbackend d’implémenté :laravel. Cette option est donc facultative tant qu’un secondbackend n’est pas présent.
1 $ java -jar swsg.jar --help
2 Usage: java -jar swsg.jar [check|gen] [options] 3
4 --help prints this usage text
5 -m, --model <file> path to the model 6 -i, --implementation <path>
7 path to implementation
8 -b, --backend <name> backend name
9 -o, --output <path> path to the output directory 10 Command: check
11 Check a web app model 12 Command: gen
13 Generate from a web app model
Listing 7.1 –Documentation de l’interface en ligne de commande de SWSG