Archive

Archives pour la catégorie ‘développement’

FlickrML : Flickr + Google App Engine/Java + Google Earth

Suite à l’annonce de Google App Engine pour Java, j’en ai enfin profité pour déployer une petite application java qui attendait patiemment dans un coin.

Cette application « FlickrML » permet d’afficher dynamiquement dans Google Earth les photos géotagguées de Flickr via un fichier KML à ouvrir dans Google Earth.

Ne pas oublier de cocher le dossier « FlickrML » puis baladez-vous dans des endroits susceptibles d’avoir beaucoup de photos comme Paris.

Ce fichier KML contient un Network Link qui pointe sur une servlet hébergée sur Google App Engine.

1s après un arrêt de mouvement, Google Earth va appeler la servlet en lui passant en paramètre les coordonnées de longitudes et de latitudes de l’endroit que vous observez (paramètres BBOX). La servlet utilise ces coordonnées pour récupérer auprès de Flickr toutes les photos correspondantes sous format XML.

Télécharger le fichier KML sur Application FlickrML

Une petite démonstration ci-dessous:


Google App Engine et Java: une révolution ?

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

gae-dashboard

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

gae-dashboard-version

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:

gae-quotas

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:

Categories: développement, google, java Tags: ,

Sauvegarder vos documents google

Vous avez un compte Gmail et vous utilisez les Google Docs qui permettent de gérer vos documents en ligne ?

Et bien Google met à disposition depuis quelque temps des apis qui permettent d’agir sur ces documents : les Google Data APIs.

Ces apis sont basées sur des échanges XML via HTTP et pour faciliter la vie des développeurs des bibliothèques encapsulant ces appels sont disponibles dans différents langages : Java, .NET, PHP, Python, Javascript et même Objective-C.

La nouveauté c’est que ces apis ont été mis à jour sur la partie Documents en ajoutant le téléchargement des documents [1].

Afin de mieux voir de quoi il retourne, j’ai développé une petite application « GDocsUI » en Java/Swing pour mettre en oeuvre ces apis.

Voici ci-dessous une copie d’écran de l’application:

gdocsui

Vous pouvez lancer cette application via Java Web Start via ce bouton :

jws-launch-button

Cette application a été développé avec l’IDE Netbeans et le Swing Application Framework plus riche que les apis Swing de base (gestion des Actions centralisées, gestion des traitements en tâche de fond toujours problèmatique en client lourd, …).

Bespin | Eclipse : Le retour du terminal X ?

Le « Tout en ligne » est une idée qui se généralise de plus en plus : les WebMail, les photos (Flickr), les documents (GoogleDocs), la sauvegarde (Amazon S3), etc…

Les avantages : aucune installation à faire et un accès à toutes vos données depuis n’importe quel accès internet.

En appliquant ce principe au développement, on a le concept d’un environnement de développement intégré tout en ligne. Développer sur n’importe quel ordinateur avec votre configuration personnelle, vos projets, le tout sans rien réinstaller, le rêve, non ?

Bespin est un nouveau projet des labs Mozilla qui va dans ce sens : un éditeur de code réalisé en javascript permettant d’intéragir avec un serveur pour par exemple enregistrer le texte édité dans une structure de projet grâce à des apis REST à implémenter côté serveur (des exemples en Python et Servlet Java sont fournis [1]).

L’éditeur est assez évolué et dispose d’une ligne de commande avec aide en ligne.

Allez à 2:13 pour voir l’éditeur en action: 


Introducing Bespin from Dion Almaer on Vimeo.

Mais ce n’est pas fini! Quelques jours après cette annonce Boris Bokowski, commiter sur Eclipse et son camarade Simon Kaegi ont implémenté ces apis [2] avec un Eclipse « headless » sans interface graphique [3].

L’intérêt ? Un des avantages du tout en ligne c’est la puissance de calcul qui peut être mis en oeuvre par une application web par rapport à votre ordinateur personnel si puissant soit-il.

Par exemple, utilisateur régulier de service de calcul d’itinéraire comme Google Maps, j’ai acheté il y a quelques temps un GPS portable et au premier test d’itinéraire ce qui m’a frappé c’est le temps de calcul de l’itinéraire : plusieurs secondes alors que sur internet c’est quasiment instantané…

Et oui, sur une application web, on ne sait pas combien d’ordinateurs sont utilisé pour vous fournir le service. Si l’application en question utilise des services distribués cela peut être un nombre important.  C’est ainsi que l’on a appris récemment qu’une simple recherche sur google utiliserait par exemple près de 1000 serveurs [4].

Appliquons maintenant ce principe de puissance à la demande à un éditeur de code : compilation instanée, exécution des tests en simultané, etc… Le tout à partir de votre ordinateur qui peut être beaucoup plus léger en puissance car son seul but est de faire tourner le navigateur Web: pas besoin d’avoir des tonnes de RAM ou des processeurs à 300 coeurs. On reporte cela sur le ou les serveurs.

C’est un peu un retour au principe des terminaux X mais avec une ouverture beaucoup large : votre éditeur pourrait utiliser un serveur pour la compilation, d’autres services web pour des analyses de code, etc…

Vous pouvez essayer Bespin sur le site suivant : https://bespin.mozilla.com/

Références:

  • L’annonce du projet Bespin
  • Remerciements des créateurs aux contributions d’Eclipse et de XWiki
  • Clicky Web Analytics