.
I. Les applications d'hier, d'aujourd'hui et de demain▲
Au cours de sa présentation Habib Guergachi se propose de transmettre de bonnes pratiques de construction des systèmes d'information. Pour ce faire, David a décidé de découper sa présentation en différentes parties que j'essaierai de retranscrire le plus fidèlement possible.
Dès le départ, Habib Guergachi bouscule son auditoire en distinguant trois types de projets :
- [S-1] ceux se basant sur des applications d'entreprises vieillissantes aux technologies obsolètes (Java 1.4, EJB…) ;
- [S-0] ceux qui se bâtissent sur des technologies d'aujourd'hui (JEE, Spring...) mais qui, selon Habib, sont en fait des technologies d'hier arrivées à maturité ;
- [S+1] ceux qui vont bâtir le futur avec les technologies de demain, basées sur HTML (REST, HTML 5).
La conférence est lancée, les slides s'enchaînent et on comprend vite, qu'en effet, durant une longue période les applications étaient basées sur des modèles RPC (Remote Procedure Call), stateful et complètement synchrones.
S'apparentant à un fonctionnement en mode "maître-esclave", elles laissent souvent un goût amer à leurs utilisateurs ainsi qu'à leurs constructeurs.
Selon Habib, nous arrivons aujourd'hui à un point de rupture, cette fameuse "transmutation" évoquée dans le titre de la conférence.
Aujourd'hui, les nouvelles applications agréables à utiliser, adoptent principalement des modèles REST (REpresentational State Transfer), stateless et asynchrones. Les enfants de cette transmutation ne sont autres que les grands du Web : Google, Facebook, Twitter…
Toutes ces sociétés ont su bousculer les règles établies en refusant d'utiliser les concepts dits "Enterprise" (JEE, EJB, ESB…) en osant prendre des risques, afin de définir de nouveaux styles d'architecture pour leurs applications.
Le point commun de ces sociétés ? Le Web bien sûr !
II. Le Web comme élément central des applications▲
Qu'est-ce qui définit le Web :
- un protocole de transfert simple : HTTP (HyperText Transfer Protocol) ;
- un langage HTML (HyperText Markup Language), permettant de décrire les différentes ressources disponibles sur le Web ;
- un identifiant pour chacune de ces ressources, l'URI (Uniform Resource Identifier).
Habib Guergachi nous démontre alors que tout ce que nous développons dans nos applications est déjà présent dans le Web, et c'est en partant de là qu'a émergé le concept de WOA, par opposition à SOA (WebServices, Orchestrations, ESB) afin de remettre en avant le style REST.
En adoptant une architecture WOA, il est effectivement possible de faire les liens entre applications, sans difficultés et cela fonctionne déjà à grande échelle sur le Web.
L'exemple parfait de ce type de "Système d'Information", nous l'utilisons tous les jours, ce n'est autre que Wikipédia : on fait appel à un service de recherche qui nous renvoie une information sous forme d'URI qui nous permet ensuite d'accéder aux ressources demandées.
Un autre exemple, lorsque l'on recherche une personne sous Google, une des informations qui nous est retournée est son adresse qui va constituer un nouvel identifiant avec lequel nous pouvons interroger un autre service (La Poste par exemple) pour obtenir le code postal associé. Cette composition de services permet de ne choisir que les informations voulues par l'utilisateur.
Toujours pas convaincu de l'intérêt des architectures de style WOA ?
Habib Guergachi insiste désormais sur l'approche asynchrone prônée par WOA qui permet, selon ses termes, de favoriser la "relaxation temporelle".
Nouvel exemple concret avec le cas d'une application dont l'objectif est de réaliser des dépôts d'argent sur un compte bancaire. À partir de quel moment peut-on considérer que le dépôt est effectif ?
Dans le cadre d'une application classique de traitement de ces opérations, nous serions amenés à développer des transactions, à utiliser des frameworks techniques complexes pour gérer des workflows… afin de s'assurer que tout soit bien crédité / débité pour afficher le dépôt.
Dans une approche WOA, ce qui est fondamental c'est le fonctionnel : une fois que la requête de dépôt est effectuée, on affiche la mise à jour. Le débit n'est pas encore effectué ? Qu'importe, le service métier va s'occuper de tout, j'attends simplement un retour.
Par conséquent, c'est l'infrastructure qu'il est nécessaire d'adapter afin de limiter au mieux la fenêtre d'incertitude temporelle. Autre intérêt bien sûr, la possibilité de travailler en mode "déconnecté".
Pour résumer, en approche WOA, je fais une requête… ça part quand ça part… ça revient quand ça revient…
III. Des applications communicantes▲
Dernier concept abordé dans cette conférence, HATEOAS (Hypermedia as the Engine of Application State).
En effet, dans une architecture WOA, les applications se basent uniquement sur des liens (Hypermedia) pour interagir entre elles, plus besoin de définir des interfaces figées et complexes entre les clients et les serveurs comme cela est nécessaire avec SOA.
Ainsi dans une approche WOA, on bâtit les applications de manière à ce qu'elles soient totalement indépendantes les unes des autres, le tout à base de services métiers idempotents ( f(f(x)) = f(x) ).
Par exemple dans une application globale de gestion de comptes clients, on va définir différentes sous-applications : une application gérant exclusivement les clients, une autre gérant les contrats, une autre gérant des adresses… et toutes ces applications vont communiquer entre elles via le Web.
À noter que ces applications peuvent être réutilisées dans d'autres applications en tant que brique applicative.
Finalement, la seule question qui se pose est de savoir quel est le "bon" niveau de découpage. "C'est une question culturelle" répond tout simplement Habib Guergachi…
IV. Et les développeurs dans tout ça ?▲
En conclusion, Habib Guergachi insiste sur le fait que face à ce nouveau type d'architecture, les développeurs doivent "sortir de leur grotte" afin de comprendre l'idée qu'a l'utilisateur de l'application. Ils ne doivent pas s'enfermer dans des idées reçues, des couches techniques complexes leur masquant la réalité. Ils doivent se rapprocher au plus près de l'expérience utilisateur.
Ainsi, nous allons devoir dès aujourd'hui faire un choix entre deux métiers complémentaires :
- un métier s'apparentant à celui d'un agriculteur, d'un bâtisseur : celui qui construit des services métiers autonomes, idempotents, scalables ;
- un métier proche de celui de cuisinier, c'est-à-dire celui qui va consommer ces services en les sublimant.
La référence d'Habib Guergachi ? Marc Veyrat, un grand cuisinier français qui sait allier à merveille ces deux métiers.
V. Conclusion▲
Globalement, j'ai été très séduit par cette conférence, Habib Guergachi est vraiment un très bon orateur, un mélange de Steve Jobs et de Gad Elmaleh, qui maîtrise parfaitement son sujet. D'ailleurs la salle était pleine et vu les longs applaudissements à la fin de la présentation, je ne pense pas avoir été le seul séduit.
Si on va au-delà de l'orateur, le sujet en lui-même s'est avéré vraiment intéressant. N'ayant jamais entendu parler de WOA avant, j'ai trouvé que la présentation posait les bonnes questions, en montrant que WOA y apportait des solutions simples s'appuyant sur quelque chose qui a déjà fait ses preuves : le Web, tout simplement.
Bref, une présentation qui, à mon avis, aurait largement mérité d'être en keynote à Devoxx France 2012.
VI. Remerciements▲
Cette rétrospective de Devoxx France 2012 a été réalisée par Jérôme Valloire, consultant Soat et reporter Developpez.com pour Devoxx France 2012.
Cet article a été publié avec l'aimable autorisation de la société SoatSoat.
Nous tenons à remercier jacques_jean pour sa relecture attentive de cet article et Mickael Baron pour la mise au gabarit.