Revue de Presse Xebia

La revue de presse hebdomadaire des écosystèmes Java/JEE proposée par Xebia.

• REST ou pas REST

Le coin de la technique

• SpringSource: Spring Social et Spring AMQP en 1.0
• Memory Image

REST ou pas REST

Un article a fait le buzz la semaine dernière sur les architectures REST. Kelly Sommers nous propose de revoir, de façon claire et détaillée, la définition d’une API REST.
En effet, avec l’émergence des frameworks Javascript, des traitements de présentation faits hier côté serveur sont maintenant revenus à leur juste place, au sein des navigateurs clients.
Pour couvrir un maximum de sites, les grands d’Internet se doivent d’avoir une API externe. C’est pour cela que des sites comme Twitter, Flickr, Google Search proposent d’utiliser leurs services via ces APIs dites « RESTful »: grâce à elles, il est possible d’intégrer de tels services dans un site tiers, et ce sans bibliothèque particulière.
Mais l’étude menée par Kelly Sommers nous démontre que certaines de ces APIs n’ont de RESTFul que le nom.
Rappelons au passage que REST signifie Representational State Transfer: il s’agit donc de gérer les états des ressources exposées par ces APIs.

Les règles les plus élémentaires d’une API REST sont en général bien respectées:

• Utiliser le transport HTTP
• Chaque service possède une URL définie
• L’application doit gérer un format de sortie simple (text/html, application/xml, application/json…)
• Gestion explicite des opérations avec les verbes HTTP: GET, POST, PUT, DELETE…

D’autres règles, plus contraignantes, sont cependant assez fréquemment bafouées :

• Pas de gestion d’état côté serveur (pas d’utilisation de la session HTTP, le client fournit l’intégralité des données au serveur à chaque appel)
• Si, dans une réponse, la ressource en cours de consultation contient une référence vers une autre ressource, la première doit contenir un lien vers un autre service qui permet de détailler aussi la seconde. On parle d’utilisation de liens hypertextes dans la réponse HTTP.
• La réponse doit pouvoir prévenir le client si elle peut être mise en cache dans le navigateur.

Nombre d’applications web utilisent des fermes de serveurs pour absorber la charge. On utilise ensuite des mécanismes complexes de transfert de session en cas de pannes de l’un d’eux, pour éviter la perte de données. REST propose une autre solution: comme il n’y a pas de données en session, on peut facilement changer de serveur entre chaque appel sans problème: la contrainte d’une architecture sans état devient alors un atout.

En ce qui concerne l’usage des liens hypertextes, l’exemple choisi, extrait de l’API Twitter, est très parlant. Si la réponse contient la description d’un client, on s’attend naturellement à recevoir le lien vers un autre service REST pour en avoir la description complète. Cela permet de maintenir la logique de suite des services au sein de l’application, et non pas dans le client.

Il est souvent intéressant de revenir aux sources des choses pour mieux les comprendre. Le service REST vous permet d’avoir une application indépendante du client qui l’appelle. Mais comme toute solution, attention à toujours suivre tous les principes fondamentaux! Il ne faut ne pas confondre Remote Programming Control et service REST. A vos claviers pour des API REST dignes de ce nom!

Un exemple d’API que nous trouvons réussie, et qui respecte ces patterns, est celle de Spring Batch Admin. La page d’accueil vous présente la liste des services qu’on peut invoquer, et chaque réponse contient un lien vers un service de description lié. Il reste juste une petite astuce pour gérer les opérations DELETE et PUT.

Le coin de la technique

SpringSource: Spring Social et Spring AMQP en 1.0

Les réseaux sociaux forment un nouveau médium de communication qui désormais ne peut plus être négligé. Avec Spring Social 1.0, SpringSource fournit une approche commune pour authentifier un utilisateur et permettre d’utiliser les APIs propriétaires des grands réseaux sociaux; le but de cette initiative est de simplifier et homogénéiser l’accès à ces APIs hétérogènes.

Twitter et Facebook sont pleinement supportés; le support de LinkedIn, TripIt, GitHub et Gowalla est en cours. Bien sûr, un SPI vous permet également d’intégrer votre réseau social favori. Par exemple, des projets externes se consacrent actuellement à l’intégration de Foursquare et Dropbox. Il ne faut cependant pas négliger l’effort d’adaptation requis : marshalling, unmarshalling, gestion des erreurs… sans oublier les différences d’implémentation du protocole d’authentification Oauth, utilisé par la plupart des réseaux sociaux.

Avec la sortie de Spring AMQP 1.0, ce nouveau protocole de message n’a plus rien à envier à JMS en terme de facilité d’utilisation. Pour les utilisateurs de CloudFoundry, c’est une nouvelle API pour utiliser RabbitMQ, le système de message de la plateforme.

Memory Image

Martin Fowler nous propose un article sur la notion de Memory Image. Il fait suite à une publication cet été sur une application de passage d’ordres pour les marchés financiers, le projet LMAX. Cette application Java permet de traiter pas moins de 6 millions d’opérations par seconde… sur un seul Thread!

Pour arriver à ce niveau de performance, l’application met en place le mécanisme d’Event Sourcing.

L’application est divisée en trois parties:

• Input Disruptors
• Business Logic
• Output Disruptors

Les éléments Input et Output Disruptors sont chargés de recevoir, archiver et transmettre les données hors du système, avec des entrées-sorties fréquentes et une conception multi-threadée faisant appel à des buffers circulaires FIFO permettant de diminuer les temps de latence élevés dus aux entrées-sorties.

Le composant Business Logic quant à lui représente le cœur du traitement. De façon surprenante, cet élément de l’architecture n’est pas conçu pour l’exécution concurrente, et repose entièrement sur un seul thread.

Le concept est plutôt simple, toutes les données sont en mémoire dans le centre du Business Logic. Martin Fowler rappelle gentiment que pour faire fonctionner les mécanismes de cache du code de la JVM, on doit avoir des méthodes courtes et bien découplées (ces patterns de conception ne sont pas du pur hasard !). La seule contrainte est de pouvoir recomposer l’état du système à travers une journalisation des événements passés faite au fil du temps. Ainsi, il suffit de rejouer le journal des événements et votre application reprend son traitement où elle en était.

Martin Fowler revient également sur le concept de « sympathie mécanique » (mechanical sympathy) qu’il emprunte à Martin Thompson: il s’agit de soigner l’interaction entre le programme et le hardware qui l’exécute afin d’optimiser les performances. Par exemple, Fowler explique que son équipe a pris soin d’écrire des implémentations « cache-friendly » et « garbage-collector-friendly » de l’interface Map plutôt que d’utiliser les implémentations classiques; mais surtout il explique que le choix même des paradigmes de programmation est crucial: un modèle concurrentiel fondé sur les files de messages serait d’après lui moins « CPU-friendly » qu’un modèle à producteur unique, comme les Disruptors et leurs buffers circulaires. D’après Fowler, ce choix a permis d’optimiser les caches CPU de façon non négligeable.

Avec l’avènement du concept de NoSQL, nous apprenons déjà à revoir nos choix d’architecture pour la persistance de données. Avec le concept de Memory Image, Martin Fowler nous propose d’aller encore plus loin en se demandant même si un stockage persistant des données, de quelque type que ce soit, est réellement utile dans toutes les situations.

Se dissocier de la persistance permet d’avoir un modèle clair et d’éviter les acrobaties de mapping requises par les frameworks d’ORM (le fameux problème de l’impedance mismatch). Pas besoin non plus de personnaliser jusqu’à la dernière goutte les requêtes SQL pour arriver au niveau de performance voulu. Par contre, l’un des problèmes de l’approche in-memory est l’absence de notion de transaction. Il est en effet très difficile d’appliquer un rollback à des objets en mémoire, contrairement à ceux d’une base de données. Il faut donc valider un maximum les données avant même de faire le traitement.

Alors, êtes-vous prêts à faire 6 millions de transactions par seconde sur 1 thread ?