L’une des annonces majeures pour Windows Azure à mon sens est la possibilité, en plus de .NET et PHP, de déployer désormais également des applications Java. Le retour d’expérience de Domino’s Pizza durant la keynote est éloquent: ils ont pu bénéficier des apports de la plateforme Azure avec un faible impact sur leur application Java existante.

Steve Marx va nous détailler dans cette session les nouvelles fonctionnalités de Windows Azure pour Java.

Steve a beaucoup de démos que je ne pourrai pas vous montrer tout de suite, mais sûrement très bientôt! Vous pourrez également consulter la session complète en Webcast sur le site de la PDC (en anglais).

Windows Azure a pour ambition d’être la meilleure plateforme Cloud pour tout le monde, il n’y a donc aucune raison d’exclure une technologie en particulier. Steve nous confie qu’il préfère .NET, mais que le week-end il code en Python, en Perl et même en Eiffel :-)

L’audience est principalement expérimentée en Java, mais beaucoup moins en Windows Azure! Steve commence donc par “résumer” la plateforme.

Steve montre l’application de démo, un simple compteur. Plus intéressant, l’architecture:

L'architecture de l'application

  • Plusieurs Tomcat en load-balancing (Apache Tomcat 6)
  • Un JRE (Java Runtime Environment)
    • L’on détaillera les raisons de la séparation Tomcat/JRE
  • Le Storage

Java fonctionne dans Azure car:

  • L’on autorise le code natif (java.exe)
  • L’on a accès au filesystem (e.g. pour les logs de Tomcat)
  • L’on a des worker roles avec des endpoints: possibilité d’écouter sur des ports arbitraires, par exemple le port 80
  • L’on peut exécuter du code à l’initialisation d’une instance

Par ailleurs, l’on offre en plus:

  • Une librairie client Java pour accéder au storage (merci à Soyatec, société française qui a participé à ce projet)
  • Un “solution accelerator” pour Apache Tomcat, c.à.d. une base de code permettant d’initialiser et d’exécuter Tomcat
  • Des outils pour Eclipse (encore un travail de Soyatec!)

Pour illustrer le modèle d’exécution de Windows Azure, Steve propose cette analogie:

  • On va tourner sous Windows
  • Sous un compte non-administrateur
  • Avec une clef USB sur laquelle on a l’application

Si une application tourne de cette façon, elle pourra tourner dans Windows Azure.

Dans le cas de Tomcat, on est proche de cette configuration, mais il y a quelques points à régler que l’on verra plus tard.

Au niveau stockage, l’on va utiliser Windows Azure Storage (pas SQL Azure dans cet exemple, mais cela serait bien sûr possible).

Steve va illustrer l’utilisation du SDK Windows Azure pour Java, dans Eclipse, pour développer la petite application.

On a référencé org.soyatec.windows.azure.java_xxx.jar dans Eclipse, ainsi que les imports qui vont avec.

L’appli est une simple Servlet avec une méthode doGet() qui affiche un “hello world”. L’appli tourne dans Tomcat en local avec un environnement Java classique.

On utilise simplement l’API fournie par Soyatec pour accéder au Windows Storage, en passant les paramètres habituels comparables à ce que l’on trouve dans l’API .NET. Steve utilise un Blob “count.txt” pour stocker le compteur.

Le code Java

A ce niveau, l’on a déjà illustré la possibilité d’accéder facilement au Windows Azure Storage depuis un client Java!

Comment exécuter Tomcat dans Windows Azure? L’accélérateur a été créé par Infosys.

  • Copier Tomcat dans le système de fichiers local
  • Configurer Tomcat pour écouter sur le bon port: il faut reconfigurer Tomcat pour écouter sur le port alloué à l’instance
  • Il faut démarrer Tomcat
  • Surveillance et remontée d’incidents

Steve va montrer comment utiliser les commandes fournies par l’accélérateur:

  • buildme.cmd pour copier les bits et assembler le touit
  • runme.cmd pour ecxécuter en local
  • packme.cmd pour packager et préparer le déploiement proprement dit

buildme.cmd demande où se trouve les binaires de Tomcat et copie l’ensemble des fichiers. Il demande ensuite où se trouve le JRE. L’on peut choisir librement la version de Tomcat ou du JRE.

runme.cmd package alors l’ensemble puis le lance dans l’environnement de développement Azure. L’on peut alors exécuter l’application sous Tomcat localement, mais dans l’environnement Windows Azure.

packme.cmd crée le .cspkg qui pourra être déployé directement dans Windows Azure.

On utilise alors la console Web Windows Azure de façon classique pour envoyer les fichiers .cspkg et .cscfg et l’on déploie l’application.

Steve décrit alors les problèmes de concurrence qui peuvent se produire quand plusieurs instances essaie d’accéder au même Blob en même temps.

Une possibilité: utiliser un système asynchrone afin de traiter les écritures de façon contrôlée et éviter les problèmes de concurrence.

On va utiliser une file d’attente (Queue) pour traiter les incrémentations, qui seront effectuées par une instance dédiée exécutée par un Worker. C’est un modèle classique pour le traitement de travaux dans le cadre d’applications Web, e.g. du type sites de partage de photos qui calculent des vignettes, etc.

Un Worker Role est basiquement une machine virtuelle qui exécute une DLL .NET avec les points d’entrée OnStart(), Run(), OnStop(). Un Worker s’exécute pour toujours (on ne revient pas de l’appel à Run()).

Steve montre son Worker qui est une classe Java classique avec un point d’entrée de type main(). C’est cette application qui va tourner en tâche de fond, lire la file d’attente et exécuter les incrémentations dans le Blob. L’on utilise là aussi l’API Java créée par Soyatec. Les message sont vides, c’est juste une notification que l’on doit faire +1.

Le Worker va utiliser un bout de code .NET qui va faire un Process.Start() pour exécuter le JRE et exécuter la classe Java. On copie directement le JRE complet dans le projet avant de packager et déployer la solution.

Le package complet est très volumineux, une solution serait de copier les dépendances (JRE, Tomcat) dans des Blobs. C’est comme ça que fait également WordPress.

Steve revient sur le témoignage de Domino’s Pizza qui a migré son application Web Java dans Windows Azure.

L’on pourrait aussi bien accéder à SQL Azure depuis l’environnement Java, mais ce n’est pas illustré dans la session de Steve. Une bonne idée de démonstration que je garde en tête!

Où trouver les éléments? Ici: http://windowsazure.com/interoperability/