Intro
Annoncé lors du Google Campfire (littéralement feu de camp) du 7 avril dernier, le support du langage Java dans Google App Engine (GAE) est une grande nouvelle pour ceux qui développent dans ce langage.
Flashback
Un petit flashback s’impose en effet: GAE est un service qui permet de déployer des applications web sur l’infrastructure Google sorti il y a un an mais avec comme seul langage de développement Python.
Depuis la sortie de GAE, le support de Java comme langage figurait comme la première demande (même devant PHP). Demande exaucée donc depuis le 7 avril par Google.
GAE c’est quoi ?
Google App Engine est une une plateforme permettant de déployer des applications web Python et maintenant Java de type servlet/JSP en profitant gratuitement jusqu’à une certaine limite (quota) de l’infrastructure de Google.
C’est presque une révolution car dans le monde de l’hébergement, l’hébergement d’application web java n’est pas très répandu. Il y a bien quelques hébergeurs spécialisés dans ce domaine mais au vu des prix et des contraintes la solution la plus simple reste souvent de louer un serveur et d’installer soit même son JDK/Tomcat. On est très loin du niveau de support de PHP que presque tous les fournisseurs d’accès à internet offrent à leurs clients.
C’est là que Google App Engine Java change la donne.
On peut enfin déployer facilement une application web java comme on le ferait sur un serveur d’application en local mais surtout profiter de l’infrastructure de Google pour tenir une charge importante en répartissant la charge sur plusieurs serveurs si nécessaire.
C’est un des points fort de GAE par rapport à un serveur dédié: on déploit son application et c’est Google qui s’occupe de gérer la montée en charge de l’application selon les besoins.
Contraintes et persistence de données
Pour pouvoir assurer cela, GAE impose certaines contraintes à bien prendre en compte:
- il n’est pas possible d’écrire dans un fichier
- pas de possibilités de créer des threads
- pas de connexion de type socket directe à des serveurs externes (les requêtes HTTP sont par contre autorisées)
- une limite d’exécution de 30s par requête (depuis)
- support des apis java limité à une whitelist : http://code.google.com/appengine/docs/java/jrewhitelist.html
- pas d’accès à des bases de données relationnelles type MySQL (par contre JDO et JPA sont disponibles)
Il faut bien comprendre que ces limites permettent à Google d’assurer une montée en charge en déployant une même application sur plusieurs serveurs.
Dans ce cas on comprend pourquoi l’écriture de fichier est interdite : elle n’a aucun sens quand l’application est distribuée. Un fichier généré par une instance d’une application ne peut pas être utilisé par une autre instance de l’application sur un autre serveur tel quel.
Avant de vous révolter sur ces contraintes, relisez les restrictions à respecter dans le développement des EJB (http://java.sun.com/blueprints/qanda/ejb_tier/restrictions.html), on y retrouve presque les mêmes contraintes.
L’aspect absence de base de données est plus délicat: mettre à disposition une base de données relationnelles de type MySQL à l’ensemble des applications distribuées sur plusieurs serveurs est un problème qui n’est pas simple. Les Facebook, Google, LinkedIn, Flickr, Amazon et autres gros consommateurs de ressources n’ont apparemment pas trouver de solution simple et s’appuient sur des systèmes alternatifs plus simples en plus de bases de données relationnelles traditionnelles: Cassandra pour Facebook, BigTable pour Google, Dynamo pour Amazon, …
La persistence des données dans GAE s’appuit donc sur un système « Datastore » plus simple et plus « scalable » comme on dit, ce système dispose d’APIs mais pour nous faciliter la vie, les standards Java de persistence de données JDO et JPA sont disponibles via une implémentation basée sur le Datastore.
La gestion des sessions web est elle-même gérée via ce Datastore ce qui permet d’avoir des sessions distribuées sur plusieurs serveurs (besoin classique quand il s’agit de distribuer une application gérant des sessions utilisateurs sur plusieurs serveurs, la méthode la plus simple étant l’affinité de serveur, un client est « fixé » sur un serveur donné et toutes ses requêtes ultérieures sont dirigés sur ce même serveur).
Console d’Administration
GAE met à votre disposition une interface d’administration dont on aimerait bien avoir plus souvent l’équivalent dans le monde professionnel: statistiques de requêtes à la secondes, de temps par requêtes, de consommation CPU, nombre d’octets envoyés/reçus, …
Petite remarque: c’est une vue consolidée des différents serveurs sur lesquels peuvent tourner votre application (à prendre en compte avant de dire que le serveur d’application X ou Y fournit la même chose…).
Versioning
GAE gère les versions de vos applications: à chaque fois que vous déployer vous pouvez préciser la version de l’application que vous déployez, les différentes versions sont ainsi conservées sur GAE et même accessibles simultanément individuellement via une URL spécifique. Une fois déployée, vous pouvez choisir quelle version doit être celle par défaut. Point intéressant pour pouvoir tester une nouvelle version en réel sans l’activer pour tout le monde (hors problème de gestion de version de la structure des données …).
Développement/Déploiement & GWT:
En plus de l’App Engine SKD, un plugin pour Eclipse est disponible pour développer/tester votre application en local puis la déployer sur GAE. Le JDK utilisé est 1.6. Le plugin intégre aussi en option le plugin Google Web Toolkit (GWT) permettant de développer en java des applications Ajax.
Coûts ?
Et oui, GAE est gratuit jusqu’à un certain niveau (nb de requêtes, octets, …), mais au delà l’application est bloquée par un message d’erreur. Ces quotas sont extensibles en payant.
Voici ci-dessous une partie des quotas sur les ressources:
La liste complète: http://code.google.com/appengine/docs/quotas.html
Ouverture de GAE à d’autres langages
Le support de Java par Java permet à des langages qui ont été porté sur la JVM comme par exemple Ruby avec JRuby de pouvoir être exécuté sur GAE:
Groovy qui s’appuie directement sur la JVM est lui aussi disponible:
Cron , Secure Data connector
GAE dispose aussi d’un ordonnanceur (cron) permettant d’appeler une URL de votre application, bien utile pour mettre à jour des statistiques, remplir des caches, …
Secure Data Connector est un service permettant de pouvoir accèder depuis GAE à des données au sein de l’entreprise.
Conclusion : Révolution ?
Je ne sais pas encore si GAE Java est une révolution mais c’est clairement un gros changement dans le paysage Java car GAE abaisse fortement la barrière de déploiement d’application web Java sur Internet. Plus besoins de serveurs dédiés, plus de gestion de montée en charge sur différents serveurs.
On se demande (enfin surtout moi 
), pourquoi ce n’est pas Sun, père de Java qui a eu cette initiative ?
Pourquoi Sun n’a pas populariser davantage Java chez les hébergeurs webs ou en offrant lui-même un hébergement de ce type ?
Quel dilemme pour un pro Java d’être obligé d’utiliser PHP pour son blog perso car c’est le langage le plus répandu chez les hébergeurs mutualisés gratuits et payants. Quelle frustration de ne pas pouvoir déployer ses applications web java aussi facilement que d’autres lancent leur blog ou leur applis PHP !
C’est pourquoi GAE est à mon avis, une avancée importante pour le développement de Java dans le web.
Sources:
