Est-il possible de construire une architecture web agile simplement (Partie 2) ?

Ce post présente la suite de mon article où j'avais proposé une méthode simple pour implémenter une architecture agile sur un projet web.

Je m'étais attardé sur la façon de découper un projet en modules (horizontalement et verticalement), et j'avais introduit la notion de couplage fort et faible. J'avais notamment insisté sur cette notion de couplage car elle est à mes yeux importante : elle détermine le niveau d'adhérence entre les différents modules de votre application. Je préconisais ainsi l'utilisation de couplage faible entre les couches métiers dans le cas d'une architecture agile.

Pour l'utilisation du couplage faible, je vais introduire la notion de superviseur et d'hyperviseur, ce sera donc le sujet de cet article.
Ces deux notions sont les éléments clés de l'agilité de notre architecture.
L'hyperviseur en est le centre : il tient le rôle de manager des superviseurs.

Qu'est-ce qu'un superviseur ?

Il est le relais entre votre module et l'hyperviseur. Un superviseur est installé sur chaque module de votre application. Il ne sait pas communiquer directement avec les autres superviseurs de votre application mais doit interroger l'hyperviseur pour en connaître les coordonnées. Il faut comprendre que lorsque vous livrez votre application, vous fournissez des fichiers de configuration sans adresse physique mais avec des adresses logiques. C'est l'hyperviseur qui fera la transformation de l'adresse logique en une adresse physique.

Ainsi, l'hyperviseur joue le rôle d'annuaire entre les superviseurs de votre application. Mais son rôle ne s'arrête pas là, n'oublions pas que nous souhaitons une architecture qui soit souple, évolutive, et agile !

Évolutive ? Oui, nous voulons être capables d'installer une partie fonctionnelle de notre application sans impacter les autres.

Souple et agile ? Oui, car nous souhaitons mettre à jour un module , corriger un bogue sans impacter les internautes !

Pour cela, nous allons définir un protocole très simple de communication entre nos superviseurs et notre hyperviseur. Ce protocole repose sur des échanges de messages.

Je m'inspire notamment des protocoles réseaux tel que H323 ou SIP mais appliqués aux architectures web ...

Le premier message que nous allons implémenter est : REGISTER (URI,VERSION,PARAMETERS). Ce message permet à un superviseur de s'enregistrer auprès d'un hyperviseur. Il contient les informations suivantes :

  • URI : l'identifiant du superviseur s'enregistrant (on peut faire l'analogie avec le téléphone fixe : vous vous enregistrez auprès de France Télécom avec votre nom et prénom).
  • VERSION : la version applicative de l'instance de notre superviseur
  • PARAMETERS : Le superviseur fournit ses coordonnées pour être joignable. Ces paramètres peuvent se présenter sous la forme d'une URL d'un webservice, d'une adresse IP, etc. Si nous reprenons l'analogie précédente avec France Télécom : vous êtes en train d'associer votre nom et prénom à votre adresse postale, l'adresse postale représentant l'adresse à laquelle on peut vous joindre.

L'hyperviseur va répondre par un ACK pour accepter l'enregistrement ou un REFUSE (le refuse peut arriver si deux superviseurs avec la même URI et même version tentent de s'enregistrer par exemple). Je ne détaille pas plus ces messages mais sachez qu'ils existent.

blog2-register.png

A partir de maintenant, nous sommes capables d'enregistrer tous nos superviseurs dans un point d'entrée unique. Il ne reste plus qu'à les mettre en relation !

Le message CALL (URI,VERSION) offre cette fonctionnalité : un superviseur peut appeler un autre superviseur d'après l'URI, ainsi que la version.

Le champ Version peut être soit une version précise ou un ensemble de versions :

VERSION = 2.1 (version exacte 2.1)
VERSION = >2.1 (version 2.1 ou plus récente)
VERSION = 1.0-2.1 (entre les versions 1.0 et 2.1)
VERSION = (toujours la plus récente)

A la réception d’un message, l’hyperviseur va vérifier dans sa table des superviseurs ceux qui correspondent à la requête : même URI et il recherche le module dont la version est la plus récente et/ou correspond à l'ensemble de versions souhaitées.

Dès qu'il a trouvé la bonne correspondance, il répond à l'invitation par un RENDEZVOUS (PARAMETERS) qui contient les informations de connexion vers le superviseur cible.

blog2-call.png

L'hyperviseur peut ainsi mettre en relation tous les modules de votre application en fonction des URI et également des versions de vos modules !

C'est à partir de là que le rôle de notre hyperviseur prend de l'importance : dès l'arrivée d'un nouveau module, il va informer les autres modules concernés de ce changement !

Pour informer les superviseurs, l'hyperviseur utilise le message SIGNAL (WHAT,URI) : il notifie qu'une nouvelle version existe (WHAT = update). En retour, les superviseurs utilisent le message CALL pour obtenir les nouvelles coordonnées.

blog2-signal.png

Bien sûr, il faut que les superviseurs soient capables d'arrêter une connexion vers un superviseur pour en ouvrir une autre !

C'est la partie la plus difficile à mettre en place et elle fera l'objet d'un autre post sur ce blog.

Concrètement, avec ce protocole, vous pouvez mettre à jour un module en production très simplement. Si par exemple, vous avez l'application base-donnees-1.0.war installée en production, vous pouvez installer sur le même serveur votre nouveau WAR base-donnees-1.1.war. Au lancement du WAR, le superviseur se chargera de contacter l'hyperviseur pour informer tous les autres superviseurs de cette mise à jour ! L'échange des messages est rapide, ainsi, vos utilisateurs ne verront même pas qu'il y a eu une mise à jour !

Quelques problèmes subsistent, le premier qui me vient à l'esprit (et au votre...) est la notion de transaction. En se basant sur une couche 100% REST, on devrait s'affranchir de ce problème, ou alors, on peut prévoir un mode où les transactions se terminent toujours sur l'ancienne version du module et les nouvelles commencent sur la nouvelle version.

La mise en place d'un tel système nous emmène également vers la problématique de la sécurité. Ce protocole n'en propose pas. On peut imaginer que la communication entre l'hyperviseur et les superviseurs soient sur une couche HTTPS, on peut ainsi mettre en place une gestion des certificats pour autoriser ou pas les connexions entre les modules. Ce protocole peut s'utiliser à travers Internet : par exemple dans le cadre d'une architecture basée sur le Cloud Computing.

Ensuite, on peut imaginer de mettre en place des services plus avancés pour les développeurs, comme par exemple la mise à disposition de boîtes à outils :

<hyper-agile:for-each="netapsys-web-*">
	<!--Affiche un onglet par application en ligne-->
</ hyper-agile:for-each>

Ces balises afficheraient en temps réel, lors de la génération de la page HTML, les applications en ligne. On pourrait ajouter des nouveaux modules et les rendre visibles sans avoir à modifier quoique ce soit dans le code de votre page !

J'espère que la lecture de ce post vous a plu et vous a donné quelques idées pour construire votre prochaine architecture ! Rendez-vous sur le prochain post où j'aborderai le sujet des connexions entre les superviseurs (ouverture et fermeture des échanges).
D'ailleurs, n'hésitez pas à proposer des idées dans les commentaires !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.