insideIT.fr : le blog des architectes IT de SFEIR

Android

Cette soirée Google commence tout d'abord avec une présentation d'Android proposée par deux consultants d'Oxiane, Gabriel Kastenbaum et Stéphane Liétard. Les deux conférenciers ont d'abord évoqué les approches historiques et marketing autour des smartphones et d'Android avec quelques rappels :

• le début des smartphones avec les technologies BlackBerry et ses fonctionnalités pushmail dès 2001-2002, iPhone en 2007,
• les premiers modèles de smartphones s'appuyant sur Android en 2008,
• les chiffres publiés par Gartner prévoyant que la plateforme Android prendra la deuxième place en 2012 derrière Symbian de Nokia et légèrement devant iPhone,

Et ont continué avec les aspects plus techniques en rappelant qu'Android est un système d'exploitation pour Smartphones, PDAs et autres terminaux mobiles. Il est basé sur un noyau linux allégé de son gestionnaire de données.Android vient avec sa machine virtuelle, DALVIK VM, spécialement conçue pour les systèmes embarqués ayant peu de ressources.

DALVIK offre la possibilité d'écrire des applications pour Android en Java. Les classes compilées sont transformées en .DEX et non en .CLASS (bytecode pour JVM classique). Ce format est spécialisé pour la DALVIK VM et est optimisé pour un terminal mobile. Aussi, l'ensemble des classes du JRE classique n'est pas supporté, mais l'essentiel y est.

Développer avec Android peut se faire simplement en récupérant le SDK Android et le plugin Eclipse associé. Toute application Android est définie dans un fichiers (android manifest) au format XML.

Une application sur Android est composée d'un ou plusieurs composants qui sont de 4 types:

• Activity : Un écran de l'application,
• Service : Un service qui tourne en tâche de fond,
• Content Provider : Un fournisseur de contenus (souvent une base de données SQLite),
• Broadcast Receiver : Réception d'un événement envoyé à toutes les applications (niveau de la batterie, réseaux, appel, sms, etc.).

Une application peut appeler un composant d'une autre application (exemple : ouvrir une page du navigateur ou la configuration du système), lancer un service d'une autre application, ou accéder aux données d'une autre application (exemple : accéder aux contacts).

Pour relier les composants entre eux, on passe par la notion d' "intent" qui encapsule les actions et données échangées. C'est ensuite Android qui s'occupe de trouver l'application à lancer pour l'Intent donné, il utilise pour cela le fichier android manifest où tous les composants de l'application sont enregistrés.

Et enfin, on a eu droit à une petite démonstration avec une application Android présentant une page et un bouton qui, en l'actionnant, affiche une autre application.

Pour plus d'infos : http://developer.android.com/index.html

Google App Engine, Groovy and Gaeylik

La soirée continue avec la conférence Google App Engine proposée par Marc-Antoine Garrigue et Gaël Lazzari d'OCTO et Guillaume Laforge de Spring Source

Guillaume Laforge a commencé par la présentation de AppEngine en rappelant que c'est la Plateform as a Service (PaaS) de Google où on peut héberger ses application et y accéder via URLs. Google propose à l'application "hébergée" des APIs et fonctionnalités qui permettent de gérer le cache, email, XMPP, Cron, etc.

Les principales limitations de la plateforme sont :

• pas de base relationnelle,
• la durée d'une requête est limitée à 30 secondes,
• le système de fichier est en lecture seule,
• impossibilité d'utiliser des Threads,
• pas de sockets natif,
• certaines classes de l'API Java ne sont pas autorisées,
• taille de fichier est limitée.

Les services de la plateforme App Engine sont gratuits jusqu'à un certain seuil. Les quotas au-delà desquels les services deviennent payants sont assez larges. Ils concernent le volume de données échangées, le nombre de requêtes, etc. Une interface d'administration permet de gérer les applications déployées, et via un tableau de bord de visualiser les statistiques et le graphe d'activités. Pas de base de données relationnelle classique pour la persistance de données mais une sorte de Hashtable/Bigtable. Par contre sur cette structure, Google propose des abstractions permettant d'utiliser JPA/JDO pour la persistance de données. Avec ce gestionnaire de données, le nombre d'occurrences retournées par une requête est limité à 1000. Il n'y a pas de support de transaction ni de possibilité de lancer des requêtes de type JOIN ou CONSTRAINT. En revanche on peut bénéficier des "facilités" permettant de gérer des entités hétérogènes de l'application dans une même structure de données.

Par la suite Marc-Antoine Garrigue et Gaël Lazzari ont présenté Groovy et Gaelyk. Groovy, langage dynamique basé sur Java, à présent peut fonctionner avec App Engine. Pour arriver à cette compatibilité, Groovy a modifié quelques lignes de codes après un travail en commun avec Google. Avec Groovy on peut faire des composants qui ressemblent à des servlets, les Groovlets ainsi que des pages Groovy Template Servlet.

Gaelyk, le Framework/boite à outils facilite le développement avec Groovy et aide le développeur à interagir plus facilement avec App Engine. L'application de démonstration FetchFeeds est plus qu'une simple application. Proposée en open source sous licence Apache, elle utilise bien sûr les technologies App Engine, Groovy et Gaelyk. Elle montre de plus comment implémenter les mécanismes subtils permettant de réduire l'utilisation de ressources et donc comment ne pas dépasser trop vite les quotas imposés par App Engine.

http://groovy.codehaus.org

http://gaelyk.appspot.com

Google Wave pour les développeurs

Après le buffet sympathique et classique des conférences Paris JUG, nous remontons de nouveau les quelques escaliers I.S.E.P qui nous mènent à la salle de conférence pour suivre la dernière conférence de la soirée.

Didier Girard le Directeur des Opérations et de l'innovation de SFEIR, et Salvador Diaz, consultant spécialisé dans les technologies Google, nous présentent le tout dernier outil collaboratif de Google, Google Wave.

À en croire les sondages à mains levées, la grande majorité des participants présents dans la salle développe en Java, a déjà développé en GWT et pour certains sur Android et beaucoup possèdent déjà un compte Wave !

La présentation débute par une revue des principales fonctionnalités de Wave suivi d'une série de démonstrations.

Google Wave est généralement présenté comme une plateforme de communication faisant la synthèse de messagerie instantanée, d'email et de wiki avec donc la possibilité de partager un même espace entre plusieurs intervenants, drag & droper des photos ou partager des données pendant une conversation, etc. Cet outil collaboratif est développé en GWT et apporte deux principales innovations qui sont la possibilité de créer et de déposer des gadgets dans une Wave et la possibilité de développer des Robots (Goldorak pour les intimes !), une sorte de servlet qui collabore à sa façon aux conversations.

En effet, un Robot est un automate que l'on fait participer à une Wave. Il peut se comporter comme n'importe quel autre participant et dès lors il peut modifier le contenu de la Wave, ajouter des participants, etc. Les Robots supportés par Wave sont déployés sur Google App Engine et communiquent en HTTP et peuvent être indifféremment écrits en Python ou en Java. En déployant un Robot sur AppEngine, Google crée implicitement une url de type http://application.appspot.com que wave va appeler pour le robot qui aura alors comme adresse mail : application@appspot.com. Pour illustrer les possibilités que Wave offre aux développeurs, Salvador et Didier ont proposé de nous faire trois démonstrations.

La première démonstration nous montre comment créer un gadget, le déployer sur App Engine et l'ajouter à une Wave. Il suffit de récupérer un wrapper, étendre un gadget et lui donner un titre. Le gadget créé dans la démonstration, n'est autre que le logo de Paris JUG qui se déplace dans tous les sens sur l'écran. Un simple copier/coller de l'url suffira pour l'ajouter à une Wave. Les autres invités de la Wave pourront dès lors le voir et interagir avec.

La deuxième démonstration consiste à créer un Robot qui va participer à une chaine de transmission et de traitement de SMS qui utilise les technologies Android, AppEngine, GWT et enfin Wave. Le jeu consiste à faire un sondage via SMS avec la salle sur la présence des participants à un prochain événement Paris JUG. Les participants envoient un SMS à un téléphone Android, le téléphone possède une application qui réceptionne tous les SMS du téléphone pour les envoyer sur un serveur AppEngine. Enfin, un gadget écrit en GWT et ajouté sur une wave va interroger régulièrement AppEngine pour afficher les SMS. Le Robot développé pour la démonstration est déployé sur App Engine. Pour recevoir le messge, il est abonné aux événements de la wave (modification d'un message, ajout d'un participant, etc.), s'il détecte une commande particulière (SEND(message;téléphone)), il va former le message que l'application Android vient scruter et envoyer en SMS. La salle participe activement en envoyant des SMS que l'on voit défiler avec les chiffres consolidés dans la "boite" Wave de nos deux conférenciers.

La troisième et dernière démonstration nous montre un exemple d'utilisation de Wave en entreprise. Il s'agit d'un outil collaboratif léger à base de gadgets de prise de congés. Le demandeur de congés rajoute les gadgets dans sa Wave et renseigne les jours demandés. Il invite ensuite son responsable et dès lors un mini workflow de prise de congés s'engage via le Wave entre le demandeur et le responsable qui doit valider la demande.

Ces trois démonstrations et l'explication de code qui a suivi, ont montré aux participants comment Wave peut se placer au sein des technologies Google et comment on peut assez simplement et sans besoin d'infrastructure complexes, mettre en oeuvre via ces technologies des applications techniquement complexes.

https://services.google.com/fb/forms/wavesignup/

http://code.google.com/intl/fr/apis/wave/

À la fin de la conférence, les Juggers qui le souhaitent peuvent demander leur nouveau compte Wave juste avant de se diriger vers la troisième mi-temps qui promet d'être riche en discussion.

Troisième et dernier jour du symposium…je n’ai pas gagné l’iPod qui était en jeu, dommage, j’aurais pu tester GWT dessus ;)

On commence par une conférence de Geert Bevin: Boldly go where the Java language has never gone before. On le sait, Java ce n’est pas qu’un langage, c’est un langage, une JVM et une plateforme, qui ont chacun leurs points forts mais aussi leurs limites. Dès lors, l’idée, qui est à la mode ces derniers temps, c’est que l’on peut remplacer ou modifier un de ces composants pour “pousser l’enveloppe” lorsque les limites se font sentir.

Geert cite 4 exemples pour illustrer cette approche.

1. Terracotta: il s’agit d’une extension de la JVM qui facilite la scalabilité des applications, en permettant de mettre des JVM en cluster. Déclarativement, certains objets (“shared objects”) sont répliqués entre toutes les JVM, et accédés indifféremment (avec du lazy loading) par toutes les instances. On a ainsi étendu le comportement natif de la JVM.
2. RIFE continuations: déjà évoqué hier au sujet de Comet, il s’agit pour prendre une image de prendre une photo de l’état d’un thread, comme un “save game” (c’est l’image donnée par Geert). On peut à tout moment appeler pause(), ce qui crée une sauvegarde et rend la main immédiatement, puis reprendre à partir de n’importe quel état avec resume(). Les continuations sont organisées en arbre (parent = continuation à partir de laquelle on a restauré). Encore une fois, on change la sémantique habituelle de la JVM dans sa gestion des threads.
3. GWT: on ne présente plus GWT, Geert fait un rappel des principes de fonctionnement (translation Java->Javascript, mode hosted vs. compilé, debugging, etc.). Ici on a remplacé l’ensemble du stack Java par une plateforme web pure, et seul le développement utilise le stack Java standard. Un participant pose la question du JavaScript généré, et Geert dit que pour lui c’est un problème, car le JavaScript généré est illisible et impossible à débugger… je bondis intérieurement, et j’irai voir Geert à la fin pour lui expliquer que pour GWT, le browser est la plateforme, la lisibilité du JavaScript généré est aussi peu importante que la lisibilité du bytecode généré par le compilateur Java! Je ne pouvais pas laisser passer ça…
4. Android: la plateforme mobile de Google. Comme pour GWT, le développement et debugging se font en Java, avec les IDEs habituels, et un émulateur de la plateforme mobile (équivalent au mode hosted de GWT). En revanche pour le déploiement, le bytecode Java est converti en bytecode (.dex) pour la machine virtuelle Dalvik, qui est l’équivalent de la JVM.

On aurait pu multiplier les exemples, notamment les langages dynamiques qui fleurissent sur la JVM, mais le point est fait. A mon sens, ces multiples extensions et détournements sont plus des preuves de la puissance de Java que de sa faiblesse, car Java reste toujours au centre d’un écosystème qui est plus bouillonnant que jamais.

Deuxième conf: JCR: TheServerSide as a Content Application. David Neuscheler (days.com) introduit JCR, version 1.0 (JSR 170) et 2.0 (JSR 283), les diférentes fonctionnalités d’un système de CM, etc. Puis il fait une démo en prenant une page du site TheServerSide.com, et en la transformant en appli client JCR. Pour tout dire c’est un peu fastidieux, et d’où je suis on n'arrive pas à lire le code ! J'aurais peut-être dû choisir la conf sur MapReduce dans l'autre salle...

Dernière conf du matin, Michael Keith présente What's new in JPA 2.0. Les objectifs étaient multiples:

• standardiser les propriétés
• remplir les manques de l'ORM
• rendre la modélisation objet plus flexible
• fournir une abstraction du contrôle du cache
• contrôle du verrouillage (locking)
• fournir des "hooks" pour des frameworks propriétaires
• améliorations JPQL
• etc.

Je ne vais pas détailler les nouveautés, mais globalement il semble que le groupe de travail JPA a bien écouté les utilisateurs, et lorsque JPA 2.0 sera sorti, il sera difficile de justifier l'utilisation directe d'une API de persistence propriétaire.Au passage, la présentation a été agrémentée d'une page culturelle sur les oies du Canada...

Comme hier et avant-hier, déjeuner avec un lance-pierres... et en plus ils ont enlevé les machines à café !

L'après-midi commence avec Choosing a Web framework, par Shashank Tiwari. En fait de conseils pratiques, il s'agit d'une énumération de définitions, de généralités, de questions (quel problème résout un framework, quel problème crée-t-il?), tout ça pour finir par dire que toutes les raisons sont bonnes de choisir un framework, y compris parce qu'il est à la mode ou pour faire bien sur son CV !!! Au final si on est en recherche d'un framework, cette conférence ne fait qu'ajouter à la confusion et à l'incertitude. Ou comment gâcher un bon sujet.

Case Study: Better Software with the Spring portfolio, par Eberhard Wolff (SpringSource Allemagne). Pour info, SpringSource est la société qui emploie tous les committers de Spring, mais aussi certains de Tomcat et Apache. Spring, outre le framework bien connu, c'est aussi dynamic modules, batch, integration, webflow, etc.

On nous propose un cas de système de traitement de commande à architecturer autour de Spring. Le système peut recevoir des commandes par Web Services. La démarche classique est de définir une interface Java, implémentée par un POJO, et de générer le WSDL à partir de cette interface. Or cette démarche présente des inconvénients: le WSDL expose de facto l'interface d'une classe interne.. que se passe-t-il si le WSDL doit changer? D'autre part certains types communs en Java, comme Map, ne sont pas supportés en WSDL...Eberhard propose d'inverser la démarche: puisque le contrat avec les clients est le WSDL, on part du WSDL et on base le traitement d'une commande sur le schéma XML correspondant. Ansi on n'expose pas d'interface interne, on traite un objet Java généré à partir du message envoyé, via un système de mapping (JAXB/XStream). La logique est découplée de l'interface. La classe qui traite le message est un Endpoint qui est annoté via les annotations Spring. Eberhard en profite pour rappeler que Spring est trop souvent assimilé à XML, mais qu'on peut très bien faire du Spring sans XML (ou presque, soyons honnête..)

Pour rendre robuste le WebService, on peut aussi baser le traitement du message sur des expressions XPath. Ceci permet d'avoir un contrôle plus fin sur des messages qui seraient incomplets, et donc ne pourraient pas être mappés avec la solution précédente.

Eberhard introduit également les notions de pipes et filtres, qui sont des pipelines de traitement, supportés par Spring Integration, et configurables par XML (tiens donc).

Spring fournit également une approche à la notion de batch, mal résolue en Java; notamment le problème des redémarrages en cas d'interruption volontaire ou non. Un batch Spring c'est une série d'étapes, chaque étape lit quelque chose (un record dans une base probablement) et écrit quelque chose (résultat du traitement). Cette notion est supportée par Spring batch.

Dernière conf de la journée, et du symposium: Real GWT applications, par Jeff Dwyer. Une énième présentation rapide des principes de GWT, et une petite démo sur le site tocollege.net, dont une partie est réalisée en GWT. Jeff fait une petite séance rapide de live coding, et montre le débugging en mode hosted. Puis il insiste, un peu trop peut-être, sur les problèmes pour envoyer des objets métier au client provenant d'hibernate: les proxies dynamiques cassent le mécanisme de sérialisation GWT. Il existe des solutions: Hibernate4GWT et GWTHibernateFilter. Je lui ferai remarquer à la fin que ce n'est pas forcément la meilleure idée, et qu'avec Dozer il est facile de populer des objets spécialisés pour les transmette au client, car je n'ai pas forcément envie de voir mes objets métier transiter sur le fil, on ne sait jamais ce qui peut s'y trouver demain...

Jeff conseille judicieusement d'utiliser un pattern Command pour les communications du client. Il aborde la sécurité, notamment les attaques XSRF, et présente Goggle Gears pour les applis offline.

La présentation était un peu rapide, mais l'intérêt pour la techno est évident. J'espère que cette présentation (qui a été donnée deux fois lors du symposium suite à la forte demande !) y aura contribué.

Ouf, le marathon est fini ! Beaucoup de choses passionnantes ont été présentées, et on sent qu'on est à un tournant car pour ainsi dire "ça part dans tous les sens", l'écosystème Java, aux frontières autrefois bien nettes, commence à devenir une galaxie en expansion avec des projets qui poussent l'enveloppe et repoussent sans arrêt les limites, des polémiques (et encore, on n'a pas abordé les closures !). Le monde Java de demain sera certainement bien différent de celui d'aujourd'hui, mais Java en restera probablement le centre de gravité...

Il me reste à visiter Prague (superbe ville) et regarder les Turcs se qualifier sur l'écran géant au centre ville...