On parle beaucoup aujourd’hui des architectures MSA (Micro-Services Architecture), censées réussir là où les SOA ont échoué. Cela ne sera cependant pas facile, car outre la modélisation des traitements à enchaîner sous forme de micro-services, il va falloir résoudre celui de l’activation des micro-services, que l’on va embarquer le plus souvent dans des containers.

C’est dans cet esprit qu’il faut replacer l’initiative de LunchBadger, qui propose une API de gateway Open Source, l’Express Gateway, construite sur Express.js, une boîte à outils très populaire pour construire des applications Web, puisque selon son éditeur, elle donnerait lieu à 11 millions de téléchargements chaque mois. A qui il manquait cependant une dimension de services, ce que Express Gateway va lui donner.

Il faut bien comprendre quel est le problème à résoudre.

D’un côté, vous avez une bibliothèque de micro-services élémentaires, encapsulés généralement dans des containers, Docker ou autres et de l’autre une application Express qui veut solliciter au « run time » ces exécutables, voire même les diffuser avant de les exploiter.

On peut évidemment modéliser l’enchaînement de ces traitements, mais ce n’est pas la modélisation qui va vous dire comment l’applicatif maître va appeler les micro-services et comment ceux-ci vont s’appeler entre eux.

C’est ce rôle que suggère de prendre en charge la nouvelle passerelle de LunchBadger, dite « Express Gateway », qui va router les requêtes applicatives vers la plate-forme de micro-services.

Cette passerelle se présente comme un module NPM, une sorte de package à la mode Node.js, de plus en plus populaire, qui comporte une CLI (architecture d’exécution Microsoft .NET) avec entre autre, un « run time », une API de sollicitation REST (utilisation des verbes HTTP) et une base de données distribuées.

La manière d’utiliser la gateway, ce qui n’exclut pas la modélisation, est décrite par un certain nombre d’informations stockées dans un fichier JSON ou dans un YAML (Yet Another Markup Language), qui est une forme de représentation des données par sérialisation Unicode.

C’est lui qui va regrouper les éléments qui permettront à l’application de s’exécuter normalement et de recenser les consommateurs de l’API.

ExpressGateway est un cœur JavaScript qui s’exécute sur un serveur, d’où le recours judicieux à Node.js, qui lui garantit des performances qui seraient difficiles à obtenir autrement.

ExpressGateway n’est sans doute rien d’autre qu’un intermédiaire de plus, mais il mérite à ce titre d’être regardé de plus près, par ceux, tous langages confondus, qui ont à mettre en place une architecture distribuée urbanisée.

C’est là que commencent les vrais problèmes d’implémentation des micro-services.