Applications REST sur le Google App Engine

Bien que très complet, l’App Engine de Google n’intègre pas la gestion des ressources REST. Voici comment la lui ajouter :

  1. Télécharger la dernière version de jersey ou l’intégrer à maven ;
  2. Ajouter les JAR suivants dans le répertoire /war/WEB-INF/lib :
  3. asm-xxx.jar
    jackson-core-asl-xxx.jar
    jersey-client-xxx-ea-SNAPSHOT.jar
    jersey-core-xxx-ea-SNAPSHOT.jar
    jersey-json-xxx-ea-SNAPSHOT.jar
    jersey-server-xxx-ea-SNAPSHOT.jar
    jettison-xxx.jar
    jsr311-api-xxx.jar
    
  4. Modifier le web.xml comme suit :
  5. <servlet>
    	<servlet-name>Objet Direct Web Application</servlet-name>
    	<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
    	<init-param>
    		<param-name>com.sun.jersey.config.property.packages</param-name>
    		<param-value>com.objetdirect</param-value>
    	</init-param>
    	<load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
    	<servlet-name>Jersey Web Application</servlet-name>
    	<url-pattern>/resources/*</url-pattern>
    </servlet-mapping>
    
  6. Générer l’objet xml réponse (à partir d’un xsd à l’aide de xjc par exemple) :
  7. <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    	<xsd:element name="weather">
    		<xsd:complexType>
    			<xsd:attribute name="type" type="xsd:string"/>
    		</xsd:complexType>
    	</xsd:element>
    </xsd:schema>
    
  8. Annoter les classes ressources :
  9. package com.objetdirect;
    
    @Path("/weather")
    public class ObjetDirectResource {
    
    	@GET
    	@Path("/{city: [A-Z][a-z]+}")
    	@Produces(MediaType.APPLICATION_XML)
    	public Response getCityWeather(@PathParam("city") String cityName) {
    		Weather weather = new Weather();
    		weather.setType("Very clever on " + cityName);
    
    		ResponseBuilder responseBuilder;
    		responseBuilder = Response.status(Status.OK);
    		responseBuilder = responseBuilder.type(MediaType.APPLICATION_XML);
    		responseBuilder = responseBuilder.entity(weather);
    		Response response =  responseBuilder.build();
    		return response;
    	}
    }
    
  10. Démarrer le serveur et accéder à la resource localhost:8888/resources/weather/Paris

ParisJug Google – App Engine (part2)

Et la soirée Google continue … voici donc la suite de cette histoire.

APP Engine

Cette présentation fut menée par Guillaume Laforge, créateur de Groovy. On pouvait donc se douter de la coloration que pourrait prendre cette présentation GAE, qui tourna rapidement en présentation GAELyk, sucre Groovy pour exploiter sereinement les APIs GAE. Un bref résumé de ce qu’est le cloud computing, ou XaaS, soit :

  • SaaS : Software as a Service
  • PaaS : Platform as a Service <– positionnement Google avec GAE
  • IaaS : Infrastructure as a Service

L’intérêt soudain de la communauté Java pour GAE s’est produit lors de l’annonce du support Java (JVM Sandbox, serveur Jetty) par GAE l’an dernier. L’intérêt est de faire héberger sur les plateformes Google une application web, donc un war, ce qui permet d’utiliser nos frameworks web préférés (GWT, Dojo, et même Flex !), et de ne pas se soucier des problématiques d’installation, de scaling …En plus de cela, il y a des services offerts par les APIs GAE très intéressants : gestion de la mémoire CPU ou de la persistance DB, l’url fetching (liens vers sites externes), mails, librairies de manipulation d’images, support XMPP (Gtalk), support de login Google, et pour finir, gestion des CRON et Task Queues.

Que du bonheur, sauf que voilà, rien n’est gratuit en ce bas monde, il y a des limitations :

  • quotas : assez hauts, il faut générer beaucoup de traffic, mais il y a des quotas sur tous les services GAE : CPU, la mémoire , l’espace disque, les mails, les url fetch, xmpp … bref sur tout !
  • pas une ‘vraie’ DB relationnelle : il s’agit de BigTable, sorte de Map (key/value), qu’on peut attaquer via JDO ou JPA (ouf !), mais il ne s’agit pas vraiment de SQL
  • requêtes > 30sec interdites
  • nombre de fichiers, ainsi que leur taille, limité

Voilà donc pour la présentation GAE, en ce qui concerne l’intégration Groovy avec Gaelyk, cela semble très sympathique, je vous invite à regarder la présentation de Guillaume et ses compères ici.

Google Wave, révolution ?

Logo Google Wave Je me suis avalé l’intégralité de la vidéo de présentation de Google Waves (1h20 !) mais ça valait le coup. Depuis l’annonce faite en mai à la conférence Google I/O à quelques (600) happy few, le buzz a considérablement enflé. Jusqu’il y a quelques jours où Google a annoncé qu’il élargissait le nombre d’invitations à 100 000 et où le sport à la mode est devenu d’avoir SON accès (voire, encore plus fort, l’accès à la sandbox développeur). Il parait même que certains les achètent aux enchères sur e-bay !

Mais qu’est-ce donc que cet OVNI. L’ambition de Google est tout simplement de succéder à l’e-mail (et donc à SMTP) en terme d’usage et de popularité !

La solution ? Fournir un client unique pour toutes les usages collaboratifs d’Internet : le courriel donc, mais aussi le chat, le twitt, le blogging, la publication dans un Wiki, dans Facebook ou tout autre réseau social, jusqu’à l’écriture de compte-rendus de réunion, la planification d’un voyage ou même le jeu, ou toute autre activité qui induit un échange, une collaboration, une publication. Rien que ça !

Comment Google présente-t-il son nouveau bébé ? Qu’est ce qu’une Vague ?

  • Une Vague, c’est moitié conversation, moitié document
  • Une Vague c’est partagé
  • Une Vague c’est vivant

Mais encore? Quoi de neuf par rapport à un courriel traditionnel ?

  • On est plus proche d’une conversation que d’un courrier : tous les participants peuvent intervenir à tout moment (voire se couper la parole !). En ce sens ça ressemble plus à du chat.
  • Les échanges se font instantanément. Toute modification (frappe d’un caractère, mais aussi ajout de pièce jointe, ou d’image) est propagée instantanément à tous les participants ce qui rend effectivement l’échange extrêmement vivant (fini le temps d’attente pendant lequel apparaît le message “votre correspondant rédige un message”) mais aussi très intrusif (quand on chat on peut faire autre chose en même temps, c’est beaucoup plus difficile quand on est sur une Vague).
  • Une nouvelle dimension intervient, le temps : l’historique des échanges qui ont amené la Vague dans l’état courant est conservé et peut être restitué.
  • On peut intervenir à tout endroit de la conversation sans la dupliquer : on rassemble en un seul document un thread complet (i.e. le mail initial et toutes ses réponses ou mises à jour)
  • C’est réellement et nativement multi-media (même si le support initial est aujourd’hui majoritairement le texte).
  • On peut gérer des habilitations : l’accès à une Vague ou à certaines de ses parties peut être finement contrôlé.

L’équipe de Lars Rasmussen et Stephanie Hannon (les créateurs de Google Maps) est partie de la question suivante : à quoi ressemblerait l’e-mail s’il était inventé aujourd’hui ? La présentation du résultat est bluffante et, sans faire du “Googlisme” primaire, le concept me semble effectivement révolutionnaire.

Google Wave, c’est trois composants :

  • Un produit : un client écrit en GWT accédant à un serveur hébergé sur Google AppEngine
  • Une plateforme : des APIs pour développer
  • Un protocole : basé sur XMPP

Le tout est intégralement open source, l’objectif étant de développer des APIs et des usages nouveaux (j’ai admiré l’initiative de la R&D SAP pour proposer un outil collaboratif de modélisation de Business Process s’appuyant sur Google Wave).

J’attends avec impatience mon accès pour vous donner un retour concret (incluant aussi les points négatifs 😉

EDA in the Cloud

Je viens de lire un article qui vaut le détour si vous êtes intéressés par les architectures orientées évènements (EDA) et le Cloud Computing.

Simon Davies a réalisé un POC permettant l’intégration et la communication entre :
– une application s’exécutant dans l’App Engine de Google
– une application s’exécutant dans Windows Azure
– une application de type console s’exécutant derrière un firewall

Le middleware a été réalisé avec le composant « Service Bus » de la plateforme .NET Services.

L’article en question.

Cloud computing : le Google App Engine intègre Java

Le cloud computing en Java : c’est parti ! Google App Engine, c’est à dire la mise à disposition de l’infrastructure Google pour supporter les applications d’entreprise, peut désormais héberger des applications écrites en Java.

Les API gérées en standard sont : GWT, Servlet, JDO et JPA. Le mécanisme d’identification/authentification de Google (basé sur les adresses mail Google) s’intègre aussi très facilement. Tout cela utilise le JDK 1.6 de SUN.

Déclarer une nouvelle application à partir du site de Google est un jeu d’enfant. Il faut ensuite télécharger un plug-in  et l’installer sur Eclipse. Vous pouvez ensuite définir vos propres applications App Engine (qui sont en fait des applications GWT un peu customisées), les tester sur votre machine. Quand tout fonctionne, vous pouvez la déployer chez Google en 2 clics et un mot de passe. Encore plus simple que de déployer une application sur un Tomcat ou un JBoss local.

Évidemment, Google ne vous affecte qu’un ensemble limité de ressources (1Go de disque cependant). On peut ensuite « louer » de nouvelles ressources (CPU, mémoire, bande passante, disque) directement à partir du site d’administration de votre application. Et ajuster cette dépense au jour le jour. C’est le principe : vous payez ce que vous utilisez.

Tout n’est pas tout rose cependant : GWT demande du savoir faire. La base de données est DataStore, c’est à dire la BDD Google qui n’est pas précisément relationnelle. Ce qui signifie que les interfaces JDO/JPA proposées par Google imposent un certains nombre de contraintes, dont certaines ne sont pas précisément mineures …

Ne nous y trompons pas : cette offre est un événement majeur dans le monde de l’informatique,  si ce n’est pour le monde tout court. La facilité sidérante de déploiement d’une application sur App Engine, le coût très raisonnable et adaptatif, l’immense scalabilité garantie par Google, risquent de secouer très largement notre métier. On peut déjà imaginer que la livraison d’une application « clé en main »  sous la forme d’un déploiement Google App engine,  sera une prestation que nous aurons prochainement à faire. Il faut nous y préparer.

Je ne saurais trop vous conseiller de vous intéresser très très vite à cette technologie/proposition. C’est une opportunité majeure qui s’ouvre devant nous. Le cloud computing, c’est aujourd’hui. Demain il sera déjà trop tard pour se distinguer.