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.

Signes distinctifs

Java 5

La première information qui saute aux yeux c'est que Spring 3 est complétement écrit en Java 5, ce qui d'emblée signifie qu'un projet utilisant Spring 3 est nécessairement compatible Java 5. ça peut paraitre brutal mais il faut savoir que depuis le 30 Octobre dernier, Java 5 n'est plus supporté par sun lire ceci.
pour illustrer ce changement voici un exemple qui met l'accent sur l'utilisation massive de Java 5 :

T getBean(String name, Class<T> requiredType)
la BeanFactory, et qui représente de loin une brique assez importante dans Spring, est elle même -Généric complient-

plus besoin d'XML, ou presque

l'autre nouveauté apportée par Spring 3, c'est la possibilité de configurer la bean factory sans le moindre XML ! cependant, Spring 3 reste totalement rétro compatible avec les version précédentes.

Utilisation de l'annotation @Configuration :

Configuration

public class ApplicationConfig {

}

la classe ApplicationConfig sera donc responsable de l'instanciation des Beans, pour déclarer un Bean, rien de plus simple :

@Configuration

public class AppConfig {

@Bean

public TransferService transferService() {

return new TransferServiceImpl();

}

}

Cette approche permet d'une part de donner au développeur le moyen de contrôler du code spécifique avant de rendre le Bean, d'autre part ça permet au code de l'application d rester totalement indépendant de la plateforme. L'autre façon est par l'utilisation des Meta Annotation

Restructuration du repository du code

l'organisation des modules de Spring 3 a été complétement revue, désormais le code source de chaque module est maintenu séparément.
Plus d'information sur le site de Spring. <<LINK>>

Spring Expression Language

Spring EL et qui s'apparente à Unified EL, propose des possibilités de simplification très puissantes et notamment lors de la définition des Beans dans une XML ou par annotations.
voici un exemple illustrant les possibilités qu'offre Spring EL :
<bean class="mycompany.RewardsTestDatabase">
    <property name="databaseName" value="#{systemProperties.databaseName}"/>
    <property name="keyGenerator" value="#{strategyBean.databaseKeyGenerator}"/>
</bean>

dans cet exemple, l'attribut databaseName et keyGenerator font référence à deux Beans précédemment initialisés dans le contexte.
le même comportement est facilement reproductible par l'utilisation des annotations selon l'exemple suivant :

@Repository

public class RewardsTestDatabase {

@Value("#{systemProperties.databaseName}")

public void setDatabaseName(String dbName) {

}

@Value("#{strategyBean.databaseKeyGenerator}")

public voidsetKeyGenerator(KeyGenerator kg) {

}

}

La résolution des @Value se fait automatiquement et dynamiquement par Spring au Runtime, ce qui offre une nouvelle possibilité pour les développeurs qui la prise en compte à chaud par Spring 3 d'un changement effectué dans les fichiers de configurations .properties.

Web

Spring MVC

Pas de nouveauté concernant le volé Spring MVC depuis la version 2.5 de Spring, qui a introduit l'utilisation des Annotations pour construire des Contrôleurs MVC dans une applicaiton, ce que Spring 3 ajoute -ou supprime- c'est la déprécation de "SimpleFormController" dans le but de faire orienté les nouveaux développements vers l'utilisation "systématique" des annotations pour les contrôleurs Spring.

Amélioration du support REST

Le support de REST a été amélioré dans cette version de Spring 3. REST est devenu en quelques années le standard de facto pour quiconque souhaite mettre en place une architecture orientée service par l'utilisation de Web Service, cependant REST est beacoup plus que ça. Le modèle de développement REST est assez simple et passe par l'utilisation intensive des Annotations. Un aspect non négligeable que REST permet d'atteindre est la normalisation des URI, je m'explique, pour faire passer des valeurs à travers une URL standard en GET le moyen le plus simple est de faire comme ci-dessous :
http://www.application.com?VARIABLE=VALUE,....
le problème qui se pose est qu'un certain nombre de proxy refuserons ce genre d'URL. le format des URI REST sont de pure URL qui respecte le standard HTTP.
pour pouvoir utiliser REST avec Spring 3, rien de plus simple :

URI Templates

@RequestMapping("/hotels/{hotelId}")

public String getHotel(@PathVariable String hotelId, Model model)

List hotels = hotelService.getHotels();

model.addAttribute("hotels", hotels);

return "hotels";

}

Quand une requête arrive à "/hotels/1", le serveur repondera par le renvoi de la chaine "hotels", noté cependant que {hotelId} dans "@RequestMapping" au début de la classe est repris dans la déclaration de la méthode "getHotel" par l'utilisation de l'annotation "@PathVariable".

D'autres possibilités sont offertes et notamment avoir plusieurs variables sur le même path ce qui permet de faire des filtres assez affinés :

@RequestMapping(value="/hotels/{hotel}/bookings/{booking}", method=RequestMethod.GET)

public String getBooking(@PathVariable("hotel") long hotelId, @PathVariable("booking") long bookingId, Model model) {

Hotel hotel = hotelService.getHotel(hotelId);

Booking booking = hotel.getBooking(bookingId);

model.addAttribute("booking", booking);

return "booking";

}

Je vous conseil vivement d'aller sur le blog de Arjen Poutsma qui vous donnera de plus amples informations.

View

Spring-MVC permet au @Controller de décider quelle vue rendre pour une requête donnée, via ViewResolver. Dans un scénario RESTful, c'est le client qui décide du rôle de la représentation acceptable (XML, HTML, JSON), en passant par l'en-tête HTTP-Accept. Le serveur répond avec la représentation livrés via l'entête Content-Type. Ce processus est connu comme la négociation de contenu.

Spring Integration

Spring Integration est un framework léger d'intégration à l'image de Apache Camel ou Mule, il permet par exemple l'échange de données entre applications Spring se trouvant dans plusieurs instances JVM à travers un canal de communication. Pas de bouleversement concernant Spring Integration pour la version 3 de Spring à part le fait d'une meilleure prise charge ,un modèle simplifié d'utilisation et un découplage Framework-application amélioré.

Support de JEE 6

Une prise en compte du support de la très prochaine version JEE 6 annoncée pour la mi Décembre 2009 existe déjà dans Spring 3 et notamment le support de la JSR 330. La version Spring 3.1 aura pour mission la prise en compte totale de JEE 6.

Depricated & Pruned

Plusieurs packages et Classes font désormais partie du grand nettoyage du printemps engagé par les équipes de Spring et cela dans le but d'avoir du code encore plus facilement "maintenable", évolutif et moins complexe. Je vous invite vivement de jeté un coup d'œil dans la documentation de Spring pour prendre en compte les changements dans vos projets respectifs.

Téléchargements

Voici comment vous devez faire si vous voulez utiliser Spring 3 RC1. Je pars de l'hypothèse que vous utilisez maven pour le build de vos projets.
Pour commencer ajouter les URL des différents repository des Bundles dans votre settings.xml :

  <repository>

 <id>com.springsource.repository.bundles.snapshot</id>

 <name>  SpringSource Enterprise Bundle Repository – SpringSource Bundle Snapshots  </name>

    <url>http://repository.springsource.com/maven/bundles/snapshot  </url>

</repository> 

 <repository>       

      <id>com.springsource.repository.bundles.milestone  </id> 

     <name>  SpringSource Enterprise Bundle Repository – SpringSource Bundle Milestones  </name> 

  <url>  http://repository.springsource.com/maven/bundles/milestone  </url> 

</repository> 

 <repository>       

  <id>com.springsource.repository.bundles.release  </id> 

       <name>  SpringSource Enterprise Bundle Repository – SpringSource Bundle Releases  </name> 

    <url>  http://repository.springsource.com/maven/bundles/release  </url> 

</repository> 

 <repository>       

    <id>com.springsource.repository.bundles.external  </id> 

      <name>  SpringSource Enterprise Bundle Repository – External Bundle Releases  </name> 

        <url>  http://repository.springsource.com/maven/bundles/external  </url> 

</repository> 

et puis ajouter les dépendances des modules que vous voulez utilisé, il faudra prendre en compte le changement des noms des différents ArtifacId qui désormais suivent tous le format suivant :

<dependency>   <groupId>org.springframework</groupId>   <artifactId>org.springframework.core</artifactId>   <version>3.0.0.BUILD-SNAPSHOT</version></dependency>

la version actuelle est 3.0.0.BUILD-SNAPSHOT.

Veuillez noté que l'artifact spring tout court n'existe plus.

Ressources

Arjen poutsma REST in Spring 3 post
Arjen Poutsma Blog
Juregen Hoeller Annotated Web MVC in Spring 2.5 post
Juergen Hoeller Blog
Spring Integration
Slim Tebourbi sur insideit.fr autour de Spring Expression Language
Spring JavaConfig Reference Guide
Rod Johnson lors de la SpringOne/2GX 2009
Les rencontres Spring 2009, ROO par Bruno Guedes
Les rencontres Spring 2009, Keynote par Adrian Colyer

La semaine prochaine je vais démarrer un petit JUGing durant lequel je vais présenter les technologies Google : AppEngine, Wave, GWT, Android et GoogleApps. Cette présentation sera assez pratique et a pour objectif que chacun puisse repartir chez lui avec une meilleure vision des différents technologies de Google et comment elles s’architecturent dans une vision globale.

Je travaille sur quelques démonstrations sympa : sondage SMS, demande de congés via Wave,…

Les dates déjà fixées sont les suivantes : Lille (09/11/2009), Paris (10/11/2009), Rennes (12/11/2009), Nantes (13/11/2009), Lyon (23/11/2009) et Nancy (07/12/2009).

D’autres JUG suivront, il faut simplement que je fixe les dates.

J'ai assisté à l'IBM Forum Paris aujourd'hui, le sujet c'était le "Cloud Computing".

Pour commencer, quelles étaient mes motivations ? et bien, mon objectif premier était de pouvoir découvrir l'offre IBM cloud et notamment celle-ci http://www.ibm.com/cloud/developer, Cependant, il n'est toujours pas possible de créer un compte du fait que France ne figure pas encore dans la liste des pays sur le formulaire d'inscription et ça ne devrait plus tarder selon une confirmation que j'ai obtenu de la part d'IBM après les avoir contacté.

L'autre objectif était de comprendre l'offre de IBM et ce que cela allait changer pour les entreprises et notamment pour celles qui sont partenaires avec IBM.

Et le dernier et pas le moindre, la vision qu'IBM a du "Cloud Computing".

Un petit Historique

IBM est une entreprise novatrice dans le domaine du service depuis plusieurs années, c'est aussi une société avec une approche "globaliste" des problèmes de l'entreprise, citons par exemple les Main Frame,.. IBM est aussi un acteur historique dans le monde de l'informatique, son omniprésence et sa notoriété ne sont plus discutables. C'est avec cette logique, que cette dernière est indirectement, puis explicitement précurseur dans le domaine du Cloud Computing : "j'ai entendu parler du Grid Computing depuis déjà plusieurs années", IBM possède aussi toute l'infrastructure matérielle et logicielle nécessaire pour parfaire l'offre.

L'offre Cloud Computing IBM

David Parker (plus d'information), durant la plénière matinale, a fait le tour de l'offre qui selon ma compréhension s'articule autour de trois axes :

Le Cloud Privé (Cloudburst (R))

Selon la présentation qui a duré environ 1H, je suis ressorti avec ce qui suit : le nom de la solution : Cloudburst, une solution qui agrège toute l'expérience de IBM tant sur le coté hardware (BladeCenter (R) ) que sur le côté logiciel "une solution complète qui permet une montée en charge 'maîtrisée' voici une présentation vidéo de l'offre cloud testing"

Ce que j'en pense, et bien pour faire un rapprochement j'ai tendance à penser que c'est une nouvelle forme de mainframe, la différence réside dans le fait que l'infrastructure est mutualisée entre plusieurs entreprises ou filiales de la même entreprise avec une gestion plus souple des ressources, mais la vérité est ailleurs. Il y a bien une phrase qui a été reprise par tous les présentateurs et qui est la suivante : "...et dans tous les cas, IBM est en mesure de prendre en charge la gestion et l'administration de l'infrastructure", ce qui m'indique que IBM veut à terme pousser les entreprises à déléguer leurs infrastructures chez elles et donc proposer des contacts de maintenance. Je ne vais pas rentrer dans la critique parce que ce n'est pas le coeur du billet et que je ne maîtrise pas le modèle économique d'IBM.

IBM apps

iNotes [plus d'informations ici]est l'offre d'IBM en terme de Web Desktop, le coût est de 3$ (Google apps coûterait selon l'orateur 4$) donc moins 1$, je n'ai pas eu le temps de tester l'application mais selon les écrans que j'ai pu apercevoir ça ressemble à la version web de Notes.

Je pense qu'à terme, les solutions Web Desktop seront de la même qualité, la différence sera donc la disponibilité ainsi que la mobilité.

Le Stockage et la Virtualisation C'est un monde qui m'est un peu inconnu, mais ce que j'ai compris c'est que c'est une partie très importante de l'offre globale "Cloud Computing".

En résumé

La majeure partie de l'offre "Cloud Computing" de IBM est essentiellement destinée aux entreprises. Parmi leurs objectifs, la prise en charge de l'infrastructure des entreprises dans l'optique de réduction des coûts, la montée en charge et la disponibilité 24/24 7/7. Ca s'appelle "Cloud Privé", il y a bien un intermédiaire qui est "Cloud Hybride".

Je ferai un retour complet sur l'utilisation de la plateforme dès que mon compte IBM cloud sera activé.

Ressources :

Web

Le site de l'événement : http://www-03.ibm.com/systems/fr/jt/cloud.html
Un petit historique IBM : http://en.wikipedia.org/wiki/IBM
iNotes : http://www-01.ibm.com/software/lotus/products/inotes/
l'offre cloud publique (pas encore disponible pour la France) : http://www.ibm.com/cloud/developer

Blogs

Le blog IBM cloud : http://www.ibm.com/developerworks/downloads/cloud.html

Livres

Cloud computing & Saas : lien ici chez amazon

Mardi dernier, a eu lieu la soirée JSF 2.0 / Servlet 3.0 au Paris JUG. Comme à l'accoutumée désormais, la salle était comble, Antonio nous a même annoncé que toutes les places étaient prises 24h après l'annonce officielle ! Un conseil donc, si vous souhaitez participer à la prochaine soirée Paris JUG (soirée Google le 10 novembre), ne tardez pas une fois les inscriptions ouvertes !

JSF 2.0

La première partie de la soirée était consacrée à JSF 2.0. En réalité, derrière le titre JSF 2.0, cette présentation montrait les concepts généraux JSF d'une part, et les nouveautés JSF 2.0 d'autre part. On pourra regretter dans ce choix d'intégrer une présentation plus générale de JSF, le fait de voir les nouveautés JSF 2.0 noyées dans la masse et certaines nouveautés peu ou pas expliquées, faute de temps.
Voici les principales nouveautés de JSF 2.0 que j'ai retenu de cette présentation :

• Possibilité de faire de la validation en utilisant la JSR 303 (Bean Validation) :
  Désormais, en positionnant le tag <f:validateBean> dans vos vues, JSF exécute la validation d'un bean donné en utilisant les annotations JSR 303 positionnées sur chaque attribut du bean. Par ailleurs, Emmanuel Bernard (spec lead de la JSR 303) est intervenu à la fin de cette présentation pour nous expliquer plus en détail l'intérêt de cette spécification : les contraintes de validation sont définies à un seul endroit, l'entité métier, et sont réutilisées par toutes les couches de l'application - présentation, métier, persistance - notamment de manière automatique par les frameworks comme JSF 2.0 ou encore Hibernate. Il nous a également indiqué que la JSR devrait très prochainement être finalisée.
   
• Nouveau scope 'view' pour les managed beans :
  En plus des scopes classiques application, session et request, un nouveau scope fait son apparition : le scope view. Un bean de scope view sera maintenu par le conteneur tant que l'utilisateur ne change pas de page. Ce scope est donc pratique lorsque l'on souhaite faire plusieurs allers-retours client/serveur avec la même page, et que l'on souhaite conserver l'état de cette page entre chaque aller-retour.
   
• Possibilité de déclarer des managed beans par annotation :
  Avant, la déclaration de managed-beans devait obligatoirement être faite dans le fichier faces-config.xml. Désormais, il sera possible de déclarer un managed bean par annotation en positionnant @ManagedBean sur le bean en question. Le scope du managed bean devra également être précisé (ex: @RequestScope pour un managed bean de scope request)
   
• Développement de composants facilité avec EZComp :
  JSF 2.0 apporte la simplification du développement de composants avec EZComp. Avec EZComp, on déclare l'interface d'un composant, puis son implémentation pour un type de rendu donné, et on n'a plus qu'à importer le composant dans nos vues JSF.
  Interface :
  <composite:interface>
<composite:attribute name="qui" required="true"/>
</composite:interface>
  Implémentation :
  <composite:implementation>
<span>Hello #{cc.attrs.qui}</span>
</composite:implementation>
  Utilisation :
  <html xmlns:ez="http://java.sun.com/jsf/composite/hello">
…
<ez:hello qui="world" />
   
• Gestion native d'AJAX :
  Avant JSF 2.0, pour faire de l'AJAX, il fallait passer par des librairies tierces comme RichFaces. JSF 2.0 fournit désormais le nécessaire out-of-the-box. Ainsi, avec la balise <f:ajax>, on peut facilement intégrer des comportements AJAX dans ses vues, comme la validation en temps réel d'un champ, et sans rechargement de page.
   
• Templating : intégration de facelets dans JSF 2.0 :
  En JSF 1, il fallait faire appel à la librairie tierce facelets pour faire du templating, JSF 2.0 l'intègre désormais directement. Ainsi, pour faire du templating, il faut d'une part définir un template XHTML définissant le cadre commun de la page et la zone où est insérée le contenu spécifique de chaque vue. Puis dans chaque vue, il faut référencer le template utilisé, puis définir le contenu spécifique de la page.
   
• Gestion avancée des ressources statiques :
  Il est désormais possible de positionner les ressources statiques soit dans /resources, soit dans /META-INF/resources au niveau des classes de l'application web, ou encore dans les JARs de l'application (de WEB-INF/lib). Cette nouveauté n'est pas sans rappeler celle de Servlet 3.0, comme on le verra plus loin. Au delà de ce mécanisme, il est également possible de versioner les ressources statiques, mais également de les internationaliser. Ainsi, pour une même image, on pourra avoir une version fr_monimage.gif et une autre en_monimage.gif. Ces ressources pourront alors être référencées dans les vues soit par tag, soit par EL.
   
• Gestion de profils :
  Une nouveauté intéressante, car peu commune, la gestion de plusieurs profils d'utilisation : development, production et unitTest. Avec ces profils, on peut mettre du code ou du contenu conditionné par un profil d'utilisation. Ainsi, par exemple, on pourra en cas d'erreur, afficher la stacktrace dans la page en profil development, et afficher un joli message  d'erreur en profil production.
   
• Accès aux vues par la méthode GET :
  Enfin, dernière nouveauté qui était fortement demandée par la communauté, les vues seront désormais accessibles par la méthode GET, et plus seulement par la méthode POST. Cela permettra notamment aux utilisateurs de pouvoir créer un favori sur une page donnée.

 

Servlet 3.0

La deuxième partie de soirée était consacrée aux nouveautés apportées par Servlet 3.0. Aux commandes de cette présentation, Rémy Maucherat, responsable de l'implémentation des APIs Servlet & JSP chez JBoss, et membre de l'expert group de la JSR 315 alias Servlet 3.0. Autant dire qu'il maitrisait son sujet !
Au milieu de toutes les nouveautés annoncées, nous avons appris que pas mal de modifications avaient été apportées à cette JSR la semaine dernière même, ce qui est assez surprenant étant donné que la finalisation de cette JSR est très proche.
Voici la liste des nouveautés que j'ai retenu :

• Possibilité de définir les servlets, filters, listeners par annotation :
  On peut désormais définir une servlet uniquement en positionnant une annotation @WebServlet sur la servlet en question (avec les paramètres associés, notamment les urlPatterns auxquels elle répond). Il en est de même pour les filters et listeners. Ainsi, le fichier web.xml devient optionnel.
  Enfin, il est également possible au niveau d'une servlet, de définir les contraintes de sécurité associées par annotation.
   
• Possibilité de définir les servlets, filters, listeners par web-fragments :
  Chaque JAR d'un framework donné présent dans WEB-INF/lib peut définir sa configuration XML spécifique dans un fichier META-INF/web-fragment.xml. Ainsi, il sera désormais possible d'ajouter un framework web donné par simple drag&drop du JAR dans WEB-INF/lib, plus besoin d'ajouter de la configuration dans web.xml. Par ailleurs, cette configuration par défaut d'un framework web donné est surchargeable dans le fichier web.xml. On pourra ainsi redéfinir uniquement un init-parameter du controller du framework, le conteneur web se chargera de faire la fusion des configurations.
  Enfin, il est possible de définir l'ordre de chargement des web-fragments, soit dans le fichier web-fragment.xml même (ordre relatif de chargement de ce fragment par rapport aux autres), soit dans le fichier web.xml (ordre absolu des web-fragments chargés).
   
• Possibilité de définir les servlets, filters, listeners par programmation :
  Au moment du chargement de l'application, il est possible désormais d'ajouter par programmation des servlets, filters et listeners à partir du ServletContext, ce qui permettra des configurations dynamiques (par opposition à la configuration statique) et contextuelles (en fonction de paramétrage d'environnement par exemple). Un exemple d'utilisation qui me vient à l'esprit : les tests unitaires. On pourra ainsi imaginer l'ajout à chaud de la servlet de Cactus lorsqu'une system property est détectée au démarrage de l'application.
   
• Possibilité de définir des ressources statiques dans un JAR :
  Dans certains cas, on souhaite ajouter dans notre application, un framework ou un outil de monitoring/administration qui a ses propres ressources statiques associées. Aujourd'hui, il faut manuellement ajouter ces ressources à nos ressources applicatives, ce qui est dommage. Pour répondre à cette problématique, il est désormais possible dans Servlet 3.0, d'inclure dans un JAR (de WEB-INF/lib) les ressources statiques associées dans le répertoire META-INF/resources. Ces ressources statiques seront accessibles depuis le web comme si elles étaient positionnées à la racine du WAR.
   
• Possibilité d'initialiser les bibliothèques partagées :
  Au jour d'aujourd'hui, il y a un certain flou autour de l'initialisation des bibliothèques partagées par plusieurs applications au sein d'une instance de serveur d'applications. Désormais, il sera possible au niveau de la bibliothèque partagée d'avoir un initializer implémentant l'interface ServletContainerInitializer, ayant une méthode onStartup() appelée à l'initialisation de chaque application présente dans le serveur d'applications. Le servletContext de l'application en question sera passé en paramètre. Un usage intéressant que je vois pour cette fonctionnalité est pour les portails (au sens moteur de portlets). Un portail a souvent besoin de rajouter des servlets, des listeners ou des filtres spécifiques au sein des portlets qu'il manage, ce qui est dommage lorsque l'on souhaite avoir des portlets standard Portlet 1.0 ou 2.0. Grâce à ce mécanisme, plus celui permettant de définir des servlets/filters/listeners programmatiquement, le portail pourra rajouter à chaud au démarrage du serveur,ses composants spécifiques au niveau de chaque portlet. Ainsi le web.xml de chaque portlet restera standard Portlet 1.0 ou 2.0.
   
• Possibilité d'exécution asynchrone des servlets :
  Probablement la plus grosse fonctionnalité : la gestion d'exécution asynchrone des servlets. Cette fonction permet de répondre à deux problématiques :
  
  • le mécanisme de push dans les applications de chat ou les jeux en ligne
  • dans les applications très haute charge, la possibilité de libérer un thread du pool de threads du serveur d'applications pendant le temps où on attend des retours asynchrones du BackOffice du SI, pour les agréger ensuite dans la réponse web.
  Ce mécanisme est très puissant, mais apporte également son lot de complexité. A utiliser donc uniquement si on en a vraiment besoin.
   
• Gestion des formulaires multi-parties (upload de fichiers) :
  Récupérer côté serveur (simplement) les fichiers envoyés par un client via un formulaire était un manque important, qui avait jusqu'alors été comblé par la librairie Apache Commons FileUpload, largement utilisée. Servlet 3.0 reprend quasiment à l'identique les fonctionnalités permises par cette librairie.
   
• Possibilité de contrôler le processus d'authentication par le conteneur :
  Un constat est le fait que les mécanismes d'authentification par le conteneur sont peu utilisés car peu flexibles, peu contrôlables. Partant de ce constat, de nouvelles méthodes ont été ajoutées dans l'interface ServletRequest afin de permettre aux développeurs de contrôler le mécanisme d'authentification du conteneur :
  
  • authenticate(response) : lance le mécanisme d'authentification défini du conteneur 
  • login (username, password) : lance le mécanisme d'authentification du conteneur à partir des identifiants passés en paramètre (nouveau type d'authentification : LOGIN)
  • logout() : permet de forcer la déconnexion de l'utilisateur en supprimant le principal de la session
     
• Possibilité de personnalisation de la gestion des sessions :
  Désormais, dans la balise <session-config> du fichier web.xml, il est possible de personnaliser la gestion des sessions :
  
  • possibilité de modifier le nom du cookie de session (par défaut JSESSIONID)
  • possibilité de choisir le mécanisme de récupération de l'id de session : URL, COOKIE, SSL
  • possibilité de redéfinir la portée du cookie de session (par défaut : locale au contexte web de l'application). Cela permet notamment d'activer le partage de sessions entre plusieurs applications au sein d'un même serveur d'applications. Cela sera particulièrement utile pour les portails (encore une fois), pour permettre d'avoir une session commune entre toutes les portlets.
   

Conclusion

En conclusion, beaucoup de nouveautés pour ces deux versions majeures d'APIs, intégrant la spécification Java EE 6. Côté JSF 2.0, on appréciera le fait que Sun ait écouté la communauté (support natif d'AJAX, support de la méthode GET), et le fait d'avoir intégré certains frameworks existants et ayant fait leurs preuves comme Facelets. Mais pour moi, le plus impressionnant est côté Servlet 3.0 : on avait pas vu pareils changements depuis au moins Servlet 2.3 (avec l'arrivée des listeners et filters), et cela fait plaisir à voir. Pour moi, les maîtres mots sont flexibilité (avec quatre moyens de définir des servlets, filters et listeners) et puissance (notamment avec la nouvelle fonctionnalité d'exécution asynchrone des servlets).
Bien sûr, tout le monde ne tirera pas forcément partie de ces nouveautés et continuera à utiliser l'API Servlet comme au bon vieux temps. Mais, je pense que tout cela apportera de nouveaux frameworks, de nouveaux outils qui tireront profit au maximum des nouveautés de Servlet 3.0, et pourquoi pas, apporteront de nouveaux usages...

Références

Slides JSF 2.0
Slides Servlet 3.0

Pourquoi donc un titre en anglais ? C'est la phrase de David Chappell concluant sa magnifique présentation de la plateforme Azure et du cloud computing en général, qui a eu lieu hier au palais des sport d'Issy les Moulineaux pour les Microsoft Days.
David Chappell est un orateur et un visionnaire hors pair, jusque-là rien de nouveau. Le cloud computing est un sujet brûlant, jusque-là rien d'étonnant. Microsoft mise beaucoup sur Azure, sa plateforme Cloud et ce n'est pas un scoop. Mais le mélange des ingrédients tient de l'alchimie parfois et peut offrir un plat rafraichissant et pimenté à la fois. Je me permets cette image, lui même ayant démarré sur une apologie de la cuisine française. Car en bon orateur il est arrivé en courant et a commencé par une plaisanterie (deux en fait). La présentation s'est déroulé ensuite comme un combat de boxe, ne laissant pas un instant de répit aux auditeurs, suivant un plan simple et efficace : description; scénarii, comparaisons. Je n'ai vu personne bailler. Franchement, si le sujet n'avait pas été captivant en soi, il fallait venir juste pour le jeu d'acteur. Une vraie leçon de communication qui n'avait rien à envier de celle de l'avant veille par un orateur hors norme lui aussi, Steve Balmer. Mais passons: assez parlé du flacon, attaquons tout de suite l'ivresse, enfin je veux dire le contenu.

A new world is unfolding!

(ça devient une habitude!) Quel est donc ce monde nouveau en train d'émerger ? Le Cloud. La 6ème révolution informatique: après le Mainframe dans les années 60, le PC dans les années 70, les PC en masse dans les années 80, les serveurs dans les années 90 et la technologie mobile dans les années 2000, voici l'ère du nuage.

Alors qu'il y a quelques mois encore tout le monde était plus ou moins dubitatif sur la rapidité d'adoption, chacun attendant que l'autre se lance et se casse les dents éventuellement, aujourd'hui il n'est plus possible de douter de l'ampleur du phénomène et la courbe d'adoption parle d'elle même (selon Gartner qui est plutôt fiable en général). En clair: la course est lancée et ceux qui sont assis seront en retard. Je parle ici des éditeurs, car pour eux les places seront chères. Et ce n'est rien de le dire, un data-center pour le cloud, c'est au bas mot un demi milliard de dollars, mais surtout c'est un pari qui ne peut reposer que sur une vrai capitalisation technologique et d'image qui ne s'improvise pas. Ne pourra pas ouvrir un "cloud" qui veut. Amazon a pu se lancer parce qu'il était le premier. Et c'est d'ailleurs une première dans l'histoire des technologies de l'information et sans doute une anomalie sympathique. Mais il y a peu de chance que le phénomène se reproduise à présent.

It's here !

Pour les entreprises, l'urgence est moindre. Mais les opportunités sont énormes et les manquer serait une erreur stratégique. Le cloud computing est une réponse à beaucoup de blocages insurmontables jusque là. Les exemples sont innombrables. De la start-up qui n'a pas les moyens de se payer un service IT, à l'équipe d'une grande entreprise qui préfère éviter d'y faire appel, à son service IT. Des pics de charge journaliers d'une entreprise moyenne ouverte le jour mais finalement pas la nuit (comme beaucoup d'entreprises on en conviendra), à l'envolée brutale à la Twitter, en passant par les montées en charges saisonnières au fil des campagnes marketing, des rencontres sportives, des élections. De ceux voulant des espaces de stockage à des prix défiant toute concurrence, à ceux qui souhaitent exporter des calculs très gourmands mais limités dans le temps. Les raisons sont toutes bonnes pour tâter du nuage. Et quant au pricing, la difficulté qu'il y a à comparer les services entre eux et avec les solutions on-premise (chez soi en somme) démontre une chose, c'est qu'il n'y a pas d'écart délirant et que le choix ne portera vraisemblablement pas sur ce critère.

De nouvelles menottes ?

Certains y voient un nouvel emprisonnement. Une fois dans le cloud, qui pourra assurer que l'on peut en revenir. C'est une question pertinente mais qui a déjà ses réponses. Tout d'abord, si SalesForce a clairement fait le choix de l'enfermement, par un système très propriétaire, Amazon, Google et Microsoft jouent plutôt la carte de l'ouverture et de l'interopérabilité. Les uns sont en Java ou en python, les autres en .NET, PHP ou autres, sur des plateformes connues. Il est facile de porter une application sur ces plateformes, il sera facile de les en retirer. Ensuite, du fait de cette compatibilité "raisonnable", les prix sont assurés de ne pas s'envoler une fois la courbe d'adoption jugée suffisante par les éditeurs.

Certains y voient la mort des fournisseurs. Mais ceux-ci restent la source de revenus principale d'éditeurs comme Microsoft, qui n'aurait aucun intérêt à tuer cette manne. Il y a donc plus probablement à prévoir une cohabitation serrée mais possible.

Et revenons aux start-ups. Comme l'a joliment fait remarquer David Chappell, qu'est-ce qui caractérise le plus souvent une start-up ? L'échec. "Je plaisante bien sûr" a dit M.Chappell (il a dit "je plaisante" au moins une douzaine de fois, à chaque fois en glissant des vérités plus sensibles les unes que les autres). Mais le fait est: la très grande majorité des Start-up échoue avant de rapporter la queue d'une cerise. Le rapport avec le Cloud ? Allez, encore une phrase dans le texte : "with the cloud, if it fails, it fails fast". Quitte à sombrer, autant que ce soit rapide et sans frais supplémentaire. Ca donne plus envie de prendre des risques non ? Alors que la crise financière a plombé indubitablement les velléités des business angels, le cloud va donner un coup de fouet aux créations d'entreprise, c'est un pari que je suis prêt à prendre.

Facile et pas cher !

Pour les aspects techniques, je vous laisse consulter le livre blanc sur Azure du même David Chappell, qui est déjà disponible en anglais et en français et qui a servi de fil conducteur pour la partie technique de la présentation. Je ne m'amuserai pas à parodier ici un plan assuré et efficace. Mais un bref résumé laconique et simpliste : à moins que votre application ai besoin de droits administrateurs pour tourner (auquel cas passez votre chemin et orientez-vous vers Amazon ou SalesForce), le portage se fera en un clin d'oeil.

Pourquoi hésiter, alors ? Oui, pourquoi. La question n'est plus tant de savoir si l'on prend le train que de savoir à quelle heure. Et admettons, ce qu'on apporte avec soi pour le premier voyage. N'allons pas tout déménager en une fois. Laissons la confiance venir avec le temps. Mais ne manquons pas un beau voyage. Il faut faire partie de l'aventure. Be a part of it !

Alors une petite dernière pour la route :

It's up to you

Quelques livres blancs (dont celui cité) : http://www.microsoft.com/azure/whitepaper.mspx

Le blog du maître : http://www.davidchappell.com/blog/

Il y a un peu plus d'une semaine, Google annonçait la sortie de Google Chrome Frame.
Vous en avez surement déjà  beaucoup entendu parler.

Pour rappel, il s'agit d'un plugin s'intégrant à Internet Explorer et permettant de bénéficier
du moteur de rendu de Google Chrome, lui même basé sur WebKit.

Chrome Frame ne vient pas complètement remplacer le moteur de rendu d'Internet Explorer, il ne prend la main que si l'utilisateur ou la page qu'il visite le demandent explicitement.

Si vous souhaitez spécifier que votre page doit être chargée par Chrome Frame, il vous suffit de rajouter la balise suivante :

<meta http-equiv="X-UA-Compatible" content="chrome=1">

Sur le plateau de développement où je suis actuellement en mission, nous développons des applications GWT. Il s'agit d'applications de gestion dont les traitements côté client peuvent parfois être assez importants. La fluidité sous Internet Explorer n'est donc souvent pas optimale quand on la compare à celle sous Firefox ou Chrome.

Malheureusement, comme dans de nombreuses entreprises, le navigateur installé sur les postes de nos utilisateurs est Internet Explorer et faire installer un second navigateur pour optimiser la consultation de nos applications n'est pas vraiment une possibilité.

A l'annonce de la mise à disposition de ce plugin, nous avons décidé de le tester sur nos applications et les résultats se sont montrés vraiment impressionnants. Les gains en termes de rapidité d'exécution et de fluidité sont tels que l'adoption a été quasiment immédiate par le client.
Certes, tout n'est pas rose, nous avons eu quelques petites surprises d'affichage et le plugin est encore très jeune mais globalement pour un effort vraiment minime, les gains en termes de performance sont au-delà de ce que n’importe quelle optimisation de notre application aurait pu donner.

Le site officiel de Google Chrome Frame
L'annonce sur le site de GWT
Chrome Frame et Google Wave

Un jour ou l’autre, il est nécessaire de franchir le pas. C’est fait depuis hier. J’ai basculé un premier blog sur un système que mes équipes ont développé en interne : le WolfEngine.

Lorsque SFEIR a eu la possibilité de beta tester AppEngine, en python puis en java, j’ai lancé mes équipes internes sur un développement dont l’objectif était d’apprendre à maîtriser la nouvelle vague technologique qui se profilait. Le projet s’est étalé sur 18 mois et il vient de franchir une étape hier, la première mise en production. Voici un petit bilan.

Les étapes du projet

1. Début 2008 choix d’une technologie pour monter en compétence sur les technologies cloud : AppEngine. Le fait d’avoir accès au produit en version béta a fortement influencé la sélection de AppEngine par rapport à d’autres technologies types EC2.
2. Printemps 2008, première expérimentation autour du moteur : développement d’appliquettes, tests de  charge, analyse des techniques d’optimisation à mettre en oeuvre, confrontations aux contraintes de BigTable. L’objectif était de développer le feeling avec ce type de technologie,
3. Ete 2008, décision de développer un système de blog. Le projet en soit n’est pas très original mais il a la particularité d’apporter suffisamment de complexité tout en posant de vrais problèmes liés à un fonctionnel connu de tous ce qui évite d’interminables discussions sur les spécifications.
4. Automne 2008, première version java. Cette version n’a jamais été déployé et pour cause, seul le SDK nous était accessible, via le contrat de beta test,…
5. Hivers 2008, deuxième version, avec un premier déployement (enfin nous avions accès au déploiement java). Techniquement peu abouti, un fonctionnel non finalisé et un manque de disponibilité, cet ensemble nous a contraints à mettre le projet en veille durant le printemps 2009, …
6. Eté 2009, redémarrage du projet avec pour objectif de passer tous les blogs de SFEIR sur cette infrastructure. Toute la couche de persistances et de services a été refaite  pour utiliser les dernières API (JDO) afin d’apporter plus de cohérence dans l'application. Les objectifs à atteindre étaient : tenir la charge ( !), arriver à un système peu gourmand pour rester en dessous des quotas payants, apporter de la convivialité en supportant l’API Metaweblog qui permet de blogger en utilisant Windows Live Writer, peaufiner le système de gestion des droits utilisateurs (administrateur, éditeur, contributeur), mettre un système de gestion des commentaires, mettre en place un système de comptage de clicks,… WolfEngine propulse enfin un premier blog depuis hier. L’infographie n’est pas parfaite, il reste quelques bugs, mais il faut bien se lancer...

Ce que nous avons appris :

• développer sur le cloud nécessite un vrai apprentissage. C’est un point à ne surtout pas négliger en d’autres termes : le cloud est pratique, mais pas simple à mettre en œuvre,
• débugué sur le cloud n’est pas facile, pas de remote debug
• l’infrastructure Google est efficace, la première page du blog, bien optimisée, s’affiche de manière quasi immédiate
• il est peu probable qu’il y ait une compatibilité entre les différents cloud
• il faut optimiser les I/O
• ne jamais optimiser en local, le comportement local n’est pas le même que le comportement en ligne
• la mise en oeuvre de JDO par AppEngine n’est pas la même que pour une base de données relationnelle

Ce que nous avons aimé :

• ne plus se soucier de l’infrastructure
• pouvoir coder en java et déployer sur internet à des prix compétitifs
• la console d’administration
• la simplicité de mise en oeuvre des batchs
• le démarrage immédiat : installer Eclipse, le plugin, coder, tester, déployer – c’est en ligne

Ce que nous n’avons pas aimé :

• un bon fonctionnement local n’est pas forcément signe d’un bon fonctionnement en ligne
• nous avons essuyé pas mal de plâtre, beaucoup de frameworks ne sont pas encore opérationnels sur AppEngine
• l’absence de lisibilité sur les quotas
• la difficulté à mettre en place des tests en situation réel

Automne 2009, nous attaquons une nouvelle étape, nous allons solidifier le système, améliorer le code et commencer à nous écarter des fonctionnalités de base d’un blog. Je pense en effet que le blog tel que je le manipule depuis que j’ai créé a19s (2000) va muter. La première chose que je souhaite mettre en oeuvre est la suppression de la page d’accueil chronologique. En effet de deux choses l’une, soit le lecteur est un lecteur régulier, auquel cas il lit les brèves à travers un blog reader (via les feeds RSS), soit le lecteur est de passage sur le site et dans ce cas le contenu chronologique ne met pas assez en valeur le blog. Cette nouvelle version du WolfEngine sera testée avec le site de SFEIR, si tout va bien…

La suite logique du rachat de SpringSource par VMWare arrive plus vite que je ne l'imaginais, il s'agit de Cloud Foundry.

Une offre qui permet le déploiement d'application java sur internet. Dans un premier temps SpringSource va s'appuyer logiquement sur l'offre Amazon EC2. D'après l'annonce il n'y aurait tout de fois pas d'adhérence entre Cloud Foundry et EC2 qui devrait permettre à terme de déployer sur d'autres infrastructure. La configuration de base est composé de Apache, Tomcat, MySQL et Hyperic.

Les premiers retours devraient pas tarder de fleurir sur le web.

http://www.cloudfoundry.com/

SpringSource Launches Enterprise Java Cloud

Pour revenir sur un billet précédent, dans lequel un widget basique était conçu avec UiBuilder, nous avions pu constater la puissance de la technologie, mais le résultat n'était pas visuellement appétissant.

Voilà qui est maintenant réparé avec l'utilisation des CSS avec UiBinder pour donner une meilleure apparence aux widgets. Ce fut aussi l'occasion d'utiliser une autre fonctionalité à venir de GWT, le ClientBundle, qui permet à l'instar de l'ImageBundle de transmettre toutes ses ressources au client à travers une seule requête HTTP.

Feuille CSS et UiBinder