J’ai eu mercredi dernier l’occasion d’animer un cours du soir sur Apache CouchDB.
CouchDB est une base de donnée “NoSQL“, orientée document et dont la particularité est d’être très orienté vers le web (données au format JSON, accès REST donc via HTTP, écriture des vues en JavaScript). Ces différents points ont été abordés lors de cette soirée.

Si ce sujet vous intéresse, je vous invite à parcourir la présentation en ligne.
Utilisez les flèches de votre clavier pour naviguer dans cette présentation HTML (construite sous S5 d’Eric Meyer).

Les erreurs passent, il n’y a que le vrai qui reste.

Discutons les préjugés qui éclosent autour de REST (REpresentational State Transfer).
REST est un style d’architecture fondé sur ce qui définit le WEB.

1. REST n’a rien inventé, le premier des serveurs WEB faisait déjà du REST…

C’est vrai et REST propose une vision d’un WEB étendu aux échanges de machine à machine (M2M) là où le WEB est aujourd’hui un système dont les consommateurs sont des humains.

2. J’ai implémenté un programme sur mon serveur WEB qui renvoie des Représentations différentes en fonction de l’attribut Accept de l’entête HTTP et de la méthode (GET, PUT, DELETE) envoyée par le client, je fais donc du REST.

Partiellement vrai. On ne peut pas vraiment décréter que l’on fait du REST sans savoir à quelles contraintes on doit se plier. Au départ, on trouve la thèse de Roy Fiedling. Il a analysé les caractéristiques du système WEB en interaction avec les utilisateurs humains. Par extension, il a construit le style REST pour le dialogue de machine à machine, dont chacune des propriétés suivantes offrent des qualités au système:

1. Données structurées au dessus d’HTTP: accessibilité
2. Universal Ressource Identifier (URI): adressabilité, diffusabilité de l’information
3. Sans état: montée en charge (scalability)
4. Contrat uniforme (verbes HTTP): inter-médiation (cache, sécurité, etc.), contrôle
5. Sûreté (répétabilité du GET) & idem potence (une modification produit toujours le même résultat, par exemple, la fonction incrément n’est pas idempotente): robustesse à la perte de communication serveur
6. Hyperliens (les liens inclus dans la représentation de la ressource permettent de naviger vers ses services associés – pensons aux pages WEB des humains !) : couplage lâche (pas besoin d’extraire l’identification de la ressource pour la passer aux autres services)
7. HATEOAS (Hypermedia As The Engine Of Application State): montée en charge
8. Ressource auto-porteuse de l’information (pas besoin de notice pour consommer la ressource: utiliser le type de la ressource – est-il connu ?, lire son contenu pour trouver comment s’en servir – contient-il des hyperliens ?): couplage lâche

La vision puriste de REST, celle de son créateur, détermine que toutes ces contraintes doivent être respectées pour arriver à un système REST. Dans les faits, seules les premières étapes son outillées. Soyez indulgent avec le prochain puriste qui vous dira que votre système n’est pas REST et demandez lui s’il a bientôt terminé son implémentation pour le support des deux derniers niveaux…
Notons qu’aujourd’hui, le WEB “humain” (celui qui nous fait surfer d’une page à l’autre) satisfait ces contraintes, même la dernière: les liens et formulaires des pages sont interprétables par nos cerveaux évolués.

3. Si je dois assurer l’idem potence, je ne peux pas implémenter la fonction incrément, par exemple ?

Il faut préciser en disant qu’on ne peut pas la réaliser côté serveur. D’ume manière générale, il y a un surcoût lorsque l’on architecture un système sur REST. Nous sommes peut-être trop habitués à penser RPC et pas assez Ressource. Dès que l’on est bloqué en REST, il faut inventer une nouvelle ressource qui réalisera la fonction souhaitée.
Par exemple, pour la gestion des transactions, on peut créer une ressource transaction qui possède un état et dont la représentation permettrait de confirmer la transaction ou l’annuler annuler. Vous pouvez lire le thread suivant : [xml-dev] A question about REST and transaction isolation (en anglais) qui date de février 2004, et oui, il y a cinq ans !
A la différence des services web RPC classiques, REST ne propose donc pas de solution native pour répondre à la problématique des transactions applicatives. Si on en a besoin, il faut analyser son besoin transactionnel et l’implémenter grâce à une ressource.

4. Je dois donc juste faire un choix de framework pour commencer à développer avec REST.

Oui, c’est un bon point d’entrée. Et il ne faut pas non plus négliger le choix du framework de marshalling qui a un impact direct sur la quantité de code applicatif à développer. Un client disait qu’il était tenté de se passer de framework puisqu’on était sur les bases du web, et c’est vrai, on pourrait se contenter de l’API Servlet dans le monde java par exemple. Cependant, dès que l’on va commencer à écrire ses servlet REST, il va y avoir du code en commun: la gestion des header, la représentation des ressources en flux Json ou XML par exemple. Il y a donc bel et bien la place pour un framework REST ici. Nous avons déjà des expériences sur le choix à faire et nous pouvons vous aider.

5. Avec REST, on doit exposer ses objets métiers de trop de formats différent: XML ad-hoc, XML générique RSS ou Atom, Json…

La multi-représentabilité est aussi une force. Si vous choississez Atom par exemple, vous bénéficiez de tous les clients Atom déjà développés : clients lourds, intégration dans les portails, etc. Vos données disposent alors d’une diffusabilité maximale.
De même, si vos utilisateurs sont déjà des consommateurs de pages WEB, de flux RSS, ils retrouveront des applications familières. Si on va jusqu’au bout, les outils de Mashups qui cherchent a laisser l’utilisateur libre de construire lui-même les services dont il a besoin, seront friands des ressources REST à consommer.

6. REST est l’architecture utilisée par le WEB actuel. Mais dans mon S.I., je n’ai pas besoin que ma donnée fasse trois fois le tour de la Terre avant d’être consommé par un employé…

Le fait que le WEB soit un réseau mondial n’est pas ce qui nous intéresse pour les application métier. Le vrai critère ici, c’est plutôt la propriété de montée en charge qui a son importance pour les S.I. A l’heure du Cloud Computing (que les vendeurs de solutions hébergées ont bien du mal à évangéliser), un S.I. bâtit sur REST à l’opportunité de bénéficier de la robustesse de tous les équipements et stratégies qui rendent le WEB performant:

• proxy
• cache (Cache-Control, ETag)
• compression des requêtes (Accept-Encoding / Content-Encoding)

REST est une approche rafraichissante dans le monde très server-side de Java aujourd’hui. Ce style architectural résonne d’une tonalité très actuelle en 2009 sur les architectures où la performance, la montée en charge et la robustesse à la perte de connexion en situation de mobilité sont des critères de plus en plus porteurs de valeur pour les applications que nous concevons. Les RIAs seront tout particulièrement intéressées par la consommation des services possédants de telles qualités.

Pour en savoir plus, vous pouvez venir au prochain Valtech AfterWork qui abordera le sujet SOA (précisions sur ce précédent billet).

The Aquarium Paris s’est déroulé Vendredi 12 Décembre, cette conférence était consacrée aux solutions Open Source de Sun, du middleware au client riche en passant par les ESB.

Tout d’abord, Sun a présenté sa stratégie commerciale autour de ses solutions Open Source, avec un périmètre élargi depuis le rachat de MySql début 2008.
Ensuite une dizaine de présentations se sont succédées, dont celle de Romain Linsolas de Valtech sur Hudson l’outil d’intégration continue.

JEE6
La présentation JEE6 par Roberto Chinicci (Spec Leader J2EE) est certainement celle qui était la plus attendue.

Avec JEE6 pas de révolution mais quelques nouveautés :
• RestWS : support des Services Web en mode REST
• EJBLite : déploiement d’un EJB en mode embarqué avec packaging dans un War
• WebBeans : unification du modèle de développement JSF et EJB (standardisation du modèle de développement Seam)
• ValidationBean : API permettant la validation des beans utilisable dans un contexte JPA et/ou JSF (devrait ressembler à l’API Hibernate Validator)
et la poursuite des simplifications opérées par JEE5 :
• Allègement de l’API, certaines librairies ne seront plus embarquées par défaut mais seront optionnelles (Entity Beans EJB 2, JAX-PRC…)
• Simplification de la configuration des applications web : configuration dynamique du fichier web.xml à partir d’annotations Java 5
• Plus de flexibilité : il sera enfin possible d’utiliser des threads dans JEE6.
• Les profils : un profil regroupera un sous ensemble de l’API JEE, actuellement un seul profil est prévu (Web Profile). Un serveur d’application pourra ainsi limiter son support uniquement à un profil et non plus à toute la plateforme entière. Cela devrait simplifier l’émergence de nouveaux acteurs  JEE (Spring Application Server par exemple).

Dans le détail JEE6 devrait être constitué des APIS suivantes :
• EJB 3.1
∘ Plus besoin de déclarer les interfaces locales
∘ @Singleton pour déclarer un EJB Session du type singleton
∘ @Asynchronous pour déclarer une méthode asynchrone sur un EJB Session
∘ Convention de nommage JNDI par défaut : java:global/(app)/(module)/(bean)#interface
• Servlet 3.0
∘ Configuration dynamique des Servlets à partir d’annotations Java 5
∘ La configuration et l’intégration des frameworks web Open Source sera simplifiée à partir de point d’extension (web-fragment.xml)
∘ API asynchrone : standardisation des principes du projet Comet (Reverse Ajax) qui permet du faire du push d’information depuis le serveur vers un client
• JPA 2.0
• JSF 2.0
∘ Mécanisme de template ressemblant à Facelet
∘ Cycle de vie compatible Ajax (?)
• JAX-RS 1.1
• JAXB 2.2

La version finale de JEE6 est prévue pour début 2009 et l’implémentation de référence devrait suivre avec GlassFishV3 courant 2009.

GlassFish V3
A propos de GlassFish V3, Alexis Moussine Pouchkine au cours de sa présentation a surtout insisté sur la rapidité de démarrage (grâce à OSGI seuls les modules nécessaires sont chargés en mémoire), la légèreté du serveur d’application (26 mégas) et la possibilité d’utiliser GlassFish en mode embarqué (à la mode en ce moment).

Grizzly Comet

J’ai également assisté à la présentation de Grizzly Comet par Jean François Arcand. Grizzly (le moteur HTTP de GlassFish) simplifie l’intégration avec l’API Comet (permet de faire du Reverse Ajax). Grizzly est prévu pour traiter des requêtes HTTP en mode asynchrone : le dialogue entre le client et le serveur n’est plus en mode requête/réponse. Le serveur est capable de pousser des informations vers le client. La requête HTTP n’est donc plus attachée à un seul thread, l’envoi de la réponse a lieu plus tard dans un autre thread, l’API Comet se chargeant de gérer le contexte.

Une application de démonstration du type Twitter a permis de se rendre compte de la simplicité et de l’efficacité de Grizzly Comet, mais ce genre de technologie semble à proscrire lors d’une utilisation derrière des proxys.
A noter que l’API Comet peut également fonctionner sur Tomcat et bientôt Jetty et que les concepts sont repris dans l’API JSF IceFaces.

JavaFX
Java FX était à l’honneur, la solution RIA de Sun. Les deux présentations ont permis à l’auditoire de se faire une idée sur le produit : globalement un concurrent de Flash à partir d’un langage de Script basé sur Java. Une application JavaFX peut se déployer dans un navigateur, en mode standalone ou bien sur un téléphone portable. Visuellement c’était très beau mais je ne pense pas que cette API soit utilisable actuellement pour le développement d’applications de gestion. Wait and See…
En ce qui concerne l’outillage un plugin JavaFX existe pour NetBeans 6.5. (un plugin eclipse existe également).

Cet article a pour objectif de présenter les architectures REST : REpresentational State Transfer. Il s’agit là d’une introduction dont le but est de présenter ses concepts de base, le sujet pouvant aisément faire l’objet d’un livre de 600 pages !

(more…)