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).

A l’heure où je vous parle, je suis devant un banal ordinateur.
Rien de plus commun que cet engin doté encore d’un disque dur, d’une mémoire et même d’un lecteur de disquette (je sais, je suis vieux). Mais est-ce moi, ou ma machine qui est vielle.
Il y a presque 20 ans j’ai démarré avec un « 3270 », quel engin barbare (merci IBM) pour faire de l’informatique. Terminal passif, juste un écran et un cable réseau connecté à Big Blue.
Mais en finalement, pas si désuet que ça.
Pour gérer ces mails, il y a Google (Gmail)
Pour faire ces spécifications et autres plans chers à nos Ingénieurs Qualité, il y a Google (Google Docs)
Pour faire nos suivis de projets, statistiques en tout genre, il y a Google (Google Docs)
Pour voir nos photos de vacances, il y a Google (Picassa)
Pour suivre la presse, il y a Google (Google Reader)
Pour voir les films, il y a Google (bon là, c’est YouTube, pas encore racheté par Google?)
Et maintenant, même pour développer nos applications, il y a Google (Google App Engine)
Et pour ranger tout ça sur mon bureau, il y a encore Google (IGoogle)

Donc, pourquoi s’embarrasser d’un vieil ordinateur, avec disque dur de 180Go et mémoire de 2Mo, pour finalement accéder à Internet.
Même Windows, à quoi sert-il, si ce n’est lancer le navigateur.
Même le système d’exploitation est remplacé par le navigateur, YouOS (www.YouOS.com)
Reste à avoir un bon fournisseur d’accès, et voilà !

PS : Google = Google, Yahoo, et Cies

Auto contrôle ou auto flagellation

8aweek donne des leçons à la communauté Agile. (sur InfoQ)

8aweek veut nous faire croire qu’on n’est pas capable de se responsabiliser soi même.
8aweek propose un outil de type toolbar qui nous aiderait à « contrôler notre distraction» sur internet. L’utilisateur spécifie sur quel site il estime « perdre du temps », et la toolbar s’occupe de contrôler son accès.

Ne sommes-nous pas plus responsable que ça que nous ayons besoins de nous auto-flageller ?
De toute façon, si la toolbar s’occupe du contrôle, il y a toujours moyen de la désactiver. Peut être vont-ils inventer un outil qui vérifiera que la toolbar est bien active, et finalement même pour les sites non « distractifs » ne seront plus accessibles.

Le meilleur, c’est qu’ils ont utilisé l’Agilité pour faire cet outil.

Le risque, que nos managers nous imposent sont utilisation

Surfer libre !

Ça y est, j’ai enfin réussi à faire fonctionner le nuage de tag Technorati.

Le “Cloud” comm’y dise!

En fait, il faut modifier les paramètres par défaut de recherche de post dans Technorati pour son propre blog :

Par défaut, il ne cherche que sur les blogs avec autorité et j’avais mis en langue Française.
Reste plus qu’à faire fonctionner le ping automatique (soit disant) de Blogspot vers Technorati, et le « Cloud » devrait se mettre à jour

Google vient de lancer la version beta de sa solution d’hébergement d’application.
Application développée en Pyhton.

What is the Google App Engine?

“Google App Engine lets you run your web applications on Google’s infrastructure. App Engine applications are easy to build, easy to maintain, and easy to scale as your traffic and data storage needs grow. With App Engine, there are no servers to maintain: You just upload your application, and it’s ready to serve your users.”

Google App Engine

A quand notre Trac sur Google ??

J’ai cherché sur le net une traduction en Français du manifeste Agile.

• Les individus et les interactions priment sur les processus et les outils
• Un logiciel qui marche prime sur une documentation exhaustive
• La collaboration avec le client prime sur la négociation contractuelle
• L’ouverture au changement prime sur le suivi d’un plan rigide

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…)

Article paru dans la newsletter #20 – Ete 2007

Plus qu’une évolution

La concurrence entre les frameworks J2EE est grande et seule l’adoption par un plus grand nombre assure la pérennité de ces derniers. Struts 2 arrive avec l’ambition de remplacer Struts 1 qui est aujourd’hui le framework de référence pour la majorité des développements.

(more…)

UPDATE !!!
The author of the Last.fm wordpress plugin has updated it to make it work !!!

Well, it was…until I found out what was actually going wrong !
“last.fm recent tracks” WordPress plugin by Tijs Teulingsdoesn’t work anymore due to Last.fm new XML syntax.
In the file lastfm.php which comes with the plugin, and which may be located at the /wp-content/plugins directory (relatively to your wordpress installation directory), you have to change, line 92 :
$findme = '<track>'; by
$findme = '<track';
to make it work !
Yeah it’s as simple as that, the XML output of Last.fm has changed and the tag <track> has now an attribute, and often becomes <track streamable=”true”> (which doesn’t match <track> but always matches <track).

If you’re too lazy (or if you don’t want to open a file editor..) you can download the fixed version of lastfm.php

Working version of the lastfm.php file from “last.fm recent tracks” WordPress plugin compatible with the new Last.fm XML syntax

Ce tutorial vous expliquera comment mettre en oeuvre derrière Apache 2 le script CGI Proxy qui peut vous servir aussi bien à surfer anonyme (désactivation de scripts pendant la navigation), à accéder aux serveurs web de machine situées dans un réseau local, à contrer la censure …

Installer simplement CGI Proxy (sans SSL)

Tout d’abord, vous devez avoir les logiciels suivants installés sur votre machine:
-un serveur sous Linux(çà devrait marcher sur tous les OS…)
-Apache2 (un autre serveur web devrait faire l’affaire mais je n’ai pas testé…)
-Perl
Des commandes comme :
#apt-get install perl apache2
devrait plus ou moins régler les choses sur Debian et les Debian-like…
Pour la suite de l’article, je suppose que vous utilisez une distribution Debian Sarge.

Dirigez vous vers /etc/apache2/sites-available
#cd /etc/apache2/sites-available

Créez un nouveau site web, disons que vous avez le nom de domaine test.fr, créez ainsi le sous domaine cgiproxy.test.fr :
#vim cgiproxy.test.fr

et insérez les lignes suivantes :

Pour que ce nouveau site soit fonctionne, n’oubliez de faire un lien symbolique de cette configuration dans /etc/apache2/sites-enabled :
#cd /etc/apache2/sites-enabled
#ln -s /etc/apache2/sites-available/cgiproxy.test.fr

et de bien sûr créer le répertoire désigné dans votre configuration:
#mkdir /var/www/cgiproxy.test.fr

On redémarre Apache2 pour que la configuration soit prise en compte :
#/etc/init.d/apache2 restart

Petite note pour ceux qui n’ont pas de nom de domaine ou ne sachant pas comment créer un site sous Apache 2 :
Vous avez sans doute dans /etc/apache2/sites-available un site (fichier de configuration) qui s’appelle 000-default, qui pointe vers des fichiers dans /var/www : vous pouvez aussi bien l’utiliser en adaptant cet article (chemins et sites)

Rendez vous dans /var/www/cgiproxy.test.fr et téléchargez le script CGI CGI Proxy :
#wget http://www.jmarshall.com/tools/cgiproxy/releases/cgiproxy.2.1beta15.tar.gz

Pour avoir la dernière version, veuillez consulter le site officiel CGI Proxy

On décompresse l’archive ainsi récupérée :
#tar xvzf cgiproxy.2.1beta15.tar.gz

Et si tout s’est bien passé, en dirigeant son navigateur vers http://cgiproxy.test.fr/nph-proxy.cgi on doit avoir le formulaire de saisie d’URL de CGI Proxy !
Si toutefois cela ne fonctionne pas, n’hésitez pas à laisser un commentaire à cet article, mais commencez par vérifier :
-que vos chemins sont bons
-que vous n’avez pas renommé nph-proxy.cgi en quelquechose.cgi (il faut impérativement que le nom du fichier commence par nph-)
-que le script est exécutable :
#chmod +x nph-proxy.cgi

Installer CGI Proxy en mod ssl :

Un peu plus difficile cette fois-ci, cette partie de l’article s’adresse aux personnes ayant déjà mis en place des sites Apache2 en mod_ssl.(un jour j’écrirai un article pour l’expliquer !).
Pour faire simple, et rapide, inspirez vous de mon fichier de configuration :

Un peu d’explication !
<VirtualHost *:443>
vous permet de déclarer un serveur virtuel écoutant sur le port 443 (https par défaut)
AddHandler cgi-script .cgi
permet à Apache 2 de lancer le moteur d’interpréteur de CGI lorsque les fichiers demandés terminent par .cgi
DirectoryIndex nph-protected.cgi
indique à apache que le fichier index par défaut est : nph-protected.cgi (situé dans /var/www/cgiproxy.test.fr) lorsque qu’aucun nom de fichier est spécifié.
AuthUserFile
permet de mettre en place une sécuristation HTTP Basic (login/mot de passe demandé pour accéder à la ressource)

Liens

Le site de documentation d’Apache2
Le site officiel de CGI Proxy