Architecture WOA et CQRS (Devoxx 3/4)
Alors que certains embourbés dans JSF sont allés voir comment réduire leurs souffrances, j’ai préféré m’intéresser à des sujets d’actualités afin de voir comment faire une application de demain avec les technologies de demain. C’est le choix que souhaite également faire Gérard notre startupeur. Comment ne pas se tromper ? La technologie évolue vite et il est impossible de choisir une technologie aujourd’hui en étant certain qu’elle ne sera pas obsolète demain. Ce que je retiens des présentations de Guillaume Bort, Sadek Drobi (Play!), Habib Guergachi (WOA), Alexandre Bertails (Linked Data) et Jérémie Chassaing (CQRS) c’est que les concepts qui vont servir de base à nos architectures sont plus importants que les technologies elles-mêmes.
Web Oriented Architecture
Avant d’être Startupeur, Gérard était architecte urbaniste respecté et vénéré. Mais trop souvent, il a essayé de plier le web pour faire des applications dites « Stateful » où l’état du client est conservé côté serveur via les sessions. Ce qui amène pas mal de problèmes, en terme de performance bien sûr, car il est du coup difficile d’avoir un cache efficace, mais aussi des problèmes de développement, qui n’a jamais galéré à gérer le bouton « back » et à devoir mettre un bouton « back » spécifique dans son application alors que le navigateur lui-même en possède déjà un ?
La présentation de Habib, qui s’approche de la keynote a hypnotisé le public (et Gérard) en cassant les architectures dites « stateful » et antiweb, celle de Sadek et Guillaume montre que Play! pousse le développeur à embrasser le Web plutôt qu’à lutter contre lui.
Mais au fait c’est quoi une architecture Web ?
- Ressource based : Utilisation des URI et des mediatypes pour identifier et exprimer les « ressources » fournies par l’application
- Stateless : L’état de la conversation est gérée côté client, dans le browser. Le client change l’état de l’application via des commandes au serveur (verbes http PUT, POST et DELETE)
- HTTP powered : Utilisation du protocole HTTP et de ses verbes à bon escient : PUT, POST, DELETE, GET. Une application qui embrasse le web est une application qui ne fait que du CRUD.
WAT ? Mais comment va faire Gérard pour ne faire que du CRUD ? Son application fait des vrais trucs de barbus.
En fait c’est super simple, lorsque vous avez de faire un truc « compliqué » (qui n’est pas CRUD), comme par exemple, déplacer une somme d’argent d’un compte A (ressource) à un compte B (autre ressource) vous n’allez, côté client ni demander de modifier le compte A, ni demander de modifier le compte B, mais ajouter une ressource à votre système (via un PUT) et ça, ben c’est du CRUD. Cette commande déclenchera l’exécution de notre traitement métier « complexe » de manière « Atomic » et « Asynchrone » (Toi qui es perspicace tu auras reconnu l’objet bancaire Transaction )
Ceci permet d’avoir entre autre une interface réactive, car l’envoie d’une commande dans une queue est d’une complexité constante.
Ha oui mais du coup, quand on va requêter pour savoir combien il y a sur le compte B il va falloir parcourir toutes les transactions ! (Gérard est fier de sa perspicacité)
Biensûr que non !! La solution est dans le chapitre en dessous avec CQRS, on va séparer le modèle métier d’écriture et le modèle métier de lecture et pré-calculer, dé-normaliser pour être efficace autant en écriture qu’en lecture.
Pour aller plus loin : Implementing REST
CQRS
Le lien fort entre CQRS et la WOA, c’est le CRUD, une architecture CQRS est une architecture à base de commande, comme en WOA, l’idée est de créer des commandes plutôt que de modifier plusieurs entités du modèle. Cela revient donc à faire du CRUD, comme en WOA.
Une architecture CQRS (Command Query Responsabilty Segragation) sépare le modèle d’écriture du modèle de lecture ce qui va permettre :
- De ne pas fetcher d’informations inutiles (On n’a pas besoin du nom du client B pour calculer le solde du client A …) Qui n’a jamais du fetcher des informations inutiles parce que le modèle est unique pour toute l’application ?
- De pré-calculer de manière asynchrone toutes les opérations fortement demandées pour s’approcher d’une complexité constante ( ou linéaire, mais sur un nombre réduit d’éléments).
Bien, se dit Gérard, mais si je suis asynchrone, je ne vais pas voir tout de suite le résultat de ma transaction sur mon compte ! C’est vrai. Mais ce n’est pas grave il faut être « relax », Habid appelle ça la « relaxation temporelle ».
Pour aller plus loin :
Le mot de la fin
Maintenant qu’on ne fait que du CRUD, du Stateless et de l’asynchrone, cela permet de découper facilement nos applications en plusieurs petites applications ou API qui ne traitent que d’une seule problématique, réduisant encore la complexité du système d’information. Les applications web « finales » agrègent ensuite ces API pour présenter quelque chose de « complet » à l’utilisateur final. Évidement ces APIs simples et « unitaires » sont réutilisables par autant d’applicatifs finaux que nécessaires, permettant ainsi une ré-utilisatibilité et une interopérabilité maximale.
Appelez ça comme vous voulez, WOA, REST, CQRS, HTTP, Web. L’avenir est dans la simplicité du CRUD, l’asynchrone et le Stateless. C’est aussi l’avis de Gérard. Est-ce le vôtre ?
Java, Web | Jean-Baptiste | 6 mai 2012
Pourquoi appeler WOA ce qui semble être le bien connu REST ? Marketing ou y a-t-il quelque chose de différent ?
@Sylvain C’est différent mais très lié : « REST drives WOA but WOA extends beyond REST. » http://www.theserverside.com/news/thread.tss?thread_id=48990
Ah oui, en résumé WOA c’est SOA où on a remplacé SOAP par REST. Une sage décision
Et pour le « oriented architecture », c’est parce que WOA s’intéresse à un système global résultant de l’assemblage de « services » REST (le « service » désignant les ressources d’un domaine fonctionnel particulier).
Merci pour l’article !
A la fin du slide de Jérémie Chassaing est indiqué : » Quand ne PAS utiliser CQRS ? » Réponse: Dans un environment purement CRUD.
Cela tranche avec vos affirmations …
Effectivement, cela peut paraître bizarre mais ça ne l’est pas. D’un côté si notre application se contente de faire du CRUD (ie PUR crud) il est inutile de séparer le modèle d’insertion du modèle de lecture.
D’un autre côté, l’idée est de modéliser un métier non-CRUD (avec des actions autre que create, update, delete) justement en créant des ressources de types « action » et en y accédant à la manière « CRUD » plutôt qu’en donnant une sémantique non-CRUD à des URLs (en web) ou en faisant gérer la consistance du modèle par l’appelant (qui effectuera plusieurs update du modèle pour une seule action cohérente).
Il faut comprendre, sauf erreur de ma part qu’à partir du moment où ton application « purement crud » souhaite afficher les 10 dernières saisies, elle n’est plus purement crud et CQRS deviens sensé, car on va « calculer » pour obtenir les 10 dernières saisies. Le « purement » dans « purement CRUD » est très fragile