insideIT.fr : le blog des architectes IT de SFEIR

Aller au contenu | Aller au menu | Aller à la recherche

vendredi 15 avril 2011

1er anniversaire des Duchess France

C'est ce 14 avril que s'est tenu le 1er anniversaire des Duchess France.
Pour ceux qui n'ont pas suivi, non la noblesse n'a pas été rétablie en France. Il s'agit d'un groupe principalement composé de filles et qui oeuvre pour donner plus de visibilité aux femmes dans le milieu informatique; et bien sûr pas en gestion de projet, mais dans la technique.

A l'arrivée, nous recevons notre badge ainsi qu'un classique petit questionnaire : comment avez vous connu les Duchesses ? Quelle thèmes souhaiteriez voir traité .... A remettre dans une urne, car il pourra faire gagner l'un des lots offerts par les Sponsors. Tout les badges sont marqués d'une petite forme colorée. Quelle est sa signification ? C'est en rentrant dans l'amphithéâtre que la question trouve sa réponse : Nous sommes placés d'après la couleur de gommette. Et c'est ainsi que sont faites les équipes du Trivial Java, ainsi pas de jaloux dans la formation de ces dernières.
La soirée commence par une traditionnelle présentation, ce sont elles/qui elles ne sont pas, quel est le but ?, .... On connaissait déjà les avant-JUG, les groupes de préparation à la certification et bientôt s'annonce un nouvel événement : la marmite ! Mais qu'est ce donc ? Il s'agira d'une rencontre type coding dojo "main dans le code" (ou plutôt dans la marmite).
Après quelques remaniement de certaines couleurs en sous effectif, le jeu peu vraiment commencer. Les règles sont assez simples, chaque équipe envoi un représentant répondre à une série de question sur un thème comme le code java, la veille techno, les frameworks et même l'histoire geeko-javaïste. Des questions bien tordue, notamment sur le code java.
C'est après quelques séries de questions qu'a lieu la pause buffet bien méritée après ces efforts. Celle-çi est l'occasion de discuter avec les diverses connaissances présentes.
Au retour ce celui ci a lieu le tant attendu tirage au sort permettant de gagner les cadeaux offerts par les sponsors (dont Sfeir fait bien sûr parti). Parmi ces lots : un ipad2 (d'ailleurs remporté par une Sferienne : Yasmine Aite), des formations, des pass parleys, .... ainsi qu'un "cadeau surprise" qui se révélât être la fameuse Barbie informaticienne qui avait fait le buzz l'année dernière, remportée par Brice Argenson

BriceEtBarbie.jpg

La seconde parti reprend sur la lancée de la 1ère partie. Pour ce terminer, sur une égalité entre les verts foncés et les ciels. Pour les départager, c'est un duel entre Julien Dubois et Cédric Beurtheret sur une question de rapidité qui tranchera. C'est Spock (le framework de test) qui emmènera les verts foncés à la victoire par la réponse de Cédric. Leur équipe s'est vue remettre un mug aux couleurs des Duchess.

vainqueur.jpg

Pour les plus chevronnés, la soirée se termine par une traditionnelle 3ème mi-temps autour d'une pizza.

Félicitations aux duchesses pour cette belle soirée avec une très bonne animation. En attendant le prochain anniversaire, nous espérons de bonnes marmites pleines de bonnes technos auxquelles nous voulons tous gouter.

mercredi 15 décembre 2010

gwt-table-to-excel

Présentation d’un nouveau projet Open Source.

Lire la suite...

jeudi 11 novembre 2010

Google Refine - Les dessous de l'outil pour manipuler des données

Google avait fait l'acquisition en juillet dernier de Metaweb, la société derrière le projet Freebase. Pour ceux qui ne connaissent pas Freebase, c'est un peu le wikipedia de la base de données : Des données tabulaires libres sur des sujets variés (Artistes, Films, Livres, etc.) enrichis et maintenus par la communauté. Metaweb avait également un outil opensource nommé "Freebase Gridworks" permettant de manipuler, corriger, transformer des données. Aujourd'hui Google annonce que Gridworks et renommé en Google Refine et passe en version 2.

3 vidéos de présentations sont proposés pour mieux comprendre comment fonctionne Refine. Elles sont visible ici. On y découvre les fonctionnalités principales de Refine qui sont : corriger les données (fusionner certains types, corriger les valeurs abérantes), transformer (par exemple : découper des chaines de caractères pour créer des nouvelles colonnes), enrichir (en appellant des webservices comme googlemap pour geolocaliser, freebase, ...)

Les sources du projet sont sur google code.

Le produit peut être exécuté sur sa machine. Un simple exécutable qui, une fois lancé, démarre un serveur web. Refine s'utilise donc ensuite depuis un simple navigateur web.

Un coup d'oeil rapide au code nous permet de voir quelques unes des technologies utilisées :

  • LessCss et Lessen : Un préprocesseur CSS très à la mode qui lui rajoute quelques élements très utiles comme les variables, l'imbrication, etc.
  • Jetty 6, qu'on ne présente plus
  • Smilie Butterfly Un framework web écrit en Java. Il a été créé par Stefano Mazzocchi, créateur de Apache Cocoon. Ce monsieur a aussi contribué à quelques JSR (JSR 53 - Servlet, 63 - JAXP, et 170 - Java Content Repository). Il travaillait chez Metaweb au moment du rachat et est donc maintenant chez google (oui encore un :-D ) et travaille sur Refine. Les particularités du framework sont : pensé pour créer des applis web modulaires ; bien qu'écrit en java, fait usage de javascript à la fois sur le client et sur le serveur via Rhino.

Sur le navigateur :

  • jquery avec les plugins jquery ui et event stack

Coté build et outils :

  • Ant
  • Des fichiers .projet, .gitignore qui trainent qui indique l'utilisation d'Eclipse et de Git
  • PMD
  • Launch4j en tant que task Ant pour la génération de l'exécutable

Je trouve Butterfly intéressant, on parle beaucoup du javascript coté serveur avec node.js depuis quelques temps. La frontière entre le client et le serveur est toujours difficile à franchir surtout lorsqu'on vient du monde java, malgré les progrès effectués ces dernières années (GWT, Wicket, ...) Node.js sera justement le sujet de mon prochain billet ! J'investiguerai peut être un peu plus Butterfly pour vous en reparler. A suivre donc...

Alexandre. Twitter : @alexandre_t

lundi 23 novembre 2009

Atmosphere, atmosphere


Au devoxx de cette année nous avons pu assister à la présentation du framework Atmosphere par Jean-François Arcand, créateur du framework et Paul Sandoz, contributeur sur le projet Jersey utilisé par Atmosphere en ce qui concerne les aspects REST.

Après une rapide présentation des concepts liés aux architectures PUSH pour les applications WEB. Les deux speakers sont rentrés dans le vif du sujet en développant en direct une petite application permettant de démontrer les possibilités offertes par Atmosphere.



Le PUSH ?

Dans les applications WEB, le PUSH correspond à l'utilisation des protocoles WEB pour permettre aux différents clients (navigateurs généralement) de se voir notifier des informations de la part du serveur sans avoir à faire des requêtes périodiques sur ce dernier. Comme son nom l'indique, les informations sont poussées du serveur vers le(s) client(s) et non plus tirées par chaque client désireux d'y avoir accès. L'intérêt d'une telle technique réside dans la possibilité de voir se propager rapidement une modification de l'état du serveur et atteindre ainsi un pseudo temps-réel tout en économisant des échanges réseaux inutiles. Avec le PUSH on peut par exemple dans le cas d'un tchat, propager les nouveaux messages d'une discussion du serveur vers les clients connectés de manière quasi instantanée.
Lors de cette conférence Jean-François nous a décrit les trois types de communications existantes dans les applications WEB à savoir :
  • Polling (technique traditionnelle)
  • Ajax PUSH  ou Long Polling : ce que propose Atmosphere
  • Http Streaming : Une technique idéale théoriquement mais qui souffre de problème d'intégration avec les proxys notamment.
Atmosphere est un framework (le premier) à base de POJO proposant aux développeurs d'applications PUSH une couche de programmation masquant la complexité des serveurs Java dans ce domaine.
Pour développer la partie serveur d'une application, le framework est utilisable sur de nombreux serveurs : des conteneurs legers (Tomcat, Jetty), certains serveurs d'applications comme Glassfish et Weblogic, il est même disponible pour le Google App Engine. Concernant ce dernier, on est en droit de se demander comment peut fonctionner le Long Polling avec des requêtes censées durer moins de 30s ? Jean-François nous a donné la solution en expliquant qu'Atmosphere implémente sont propre système de continuation permettant de passer outre cette contrainte. Il faut aussi noter la compatibilité d'Atmosphere avec les Servlets 3.0.

En ce qui concerne la partie cliente des applications, de nombreux frameworks sont supportés dont GWT et Wicket. 
Lors de la présentation, les speakers se sont focalisés sur une sous-partie du framework à savoir les annotations disponibles pour les POJOs et les aspects REST intégrés via Jersey.

Lors de la démo, les deux conférenciers ont pu nous démontrer la simplicité avec laquelle il est possible de créer une application WEB asynchrone utilisant le PUSH. Ils ont insisté sur le fait d'utiliser de simples POJO et de les rendre manipulables via REST. On obtient par exemple des classes ressemblant à ceci :

@Path("/{topic}")
@Produces("text/plain;charset=ISO-8859-1")
public class PubSub {
    private @PathParam("topic") Broadcaster topic;
    @GET
    @Suspend
    public Broadcastable subscribe() {
        return new Broadcastable("OK",topic);
    }
    @POST
    @Consumes(MediaType.APPLICATION_FORM_URLENCODED)
    @Broadcast
    public Broadcastable publish(@FormParam("message") String message){
        return new Broadcastable(message,topic);
    }
}
L'idée principale de cette démo était d'utiliser Atmosphere pour suspendre la connection client lorsqu'il s'incrit à un topic "test" en appelant http://mon_serveur/test. Un autre client peut alors publier des messages qui seront diffusés à tous les clients connectés sur ce topic en soumettant un simple formulaire HTML contenant un paramètre "message" sous forme textuelle.

Ce que nous aurons retenu

Atmosphere simplifie effectivement le travail des développeurs en ce qui concerne la gestion du PUSH dans une application Java. Il n'est pas nécessaire de refondre entièrement une application existante pour y intégrer Atmosphere, la plupart des problèmes d'intégration sont adressés par le framework (gestion des proxys pour les connections HTTP, les limitations de chacun des navigateurs).

Resources:
Le site du projet : http://atmosphere.dev.java.net
Blogs :
Twitter : 
    @atmosphere_java 
    @jfarcand 

Ludovic Meurillon et Vincent Bostoen

mercredi 18 novembre 2009

DEVOXX 2009 - Conference Day 1 - Keynote

Premier jour à DEVOXX 2009 pour SFEIR, et premier jour de la partie "Conference" de DEVOXX.

Ca commence fort : Stephan JANSSEN (principal organisateur de DEVOXX) demande s'il y a des gens de SFEIR dans la salle, en précisant qu'on est venu à 24 au total ! Nous sommes surpris de notre popularité !







Stephan JANSSEN enchaine alors par quelques chiffres clés afin de se rendre compte de l'importance de l'événement :
- 8e édition
- plus de 2500 inscrits
- 737 entreprises
- 212 étudiants
- 132 sessions
- 120 speakers
- 56 JUGs
- 36 pays
- 19 partenaires

Il poursuit sur la présentation de Parleys.com V3, la plate-forme de e-learning dont il est le principal contributeur, et qui fête aujourd'hui ses 3 ans. Cette version est actuellement disponible sur : http://beta.parleys.com
Au programme des nouveautés de cette V3 :
- la possibilité de créer des espaces
- la possibilité de personnaliser son espace (par CSS)
- la possibilité d'avoir sa propre URL (monnom.parleys.com) pour son espace

Au programme de la version suivante (V4) :
- un client iphone (Stephan souligne que c'est à cause du système de validation de l'Apple Store que cette évolution n'est pas présente dans la V3)
- un système de pay-per-view, qui permet au visionneur de rémunérer le speaker de la session.

Il a également annoncé que comme l'an dernier, toutes les vidéos de DEVOXX 2009 seront publiées sur parleys.com tout au long de l'année (à hauteur de deux sessions par semaine) et disponibles gratuitement.
Pour ceux qui seraient pressés d'avoir accès à toutes les vidéos, une formule payante (49 euros pour 6 mois d'accès illimité) sera possible et permettra seulement une semaine après DEVOXX 2009 d'avoir un accès complet et illimité à toutes les vidéos des conférences.
Courage au passage à l'équipe DEVOXX, car à mon avis, la semaine après DEVOXX, ils auront du pain sur la planche...

Après Parleys, un speaker Oracle a expliqué sa vision du futur de la plate-forme java.
Une démonstration a été faite de Weblogic DM (pour Dynamic Modules), qui permet la modularisation en utilisant OSGI.
Je ne m'étendrai pas sur sa présentation qui, à mon sens, a peu apporté.



Puis Robert Chinicci (spec lead de Java EE 6) a présenté les grandes lignes de Java EE 6.
Il a annoncé que la date de version finale de Java EE 6 sera le 10 décembre 2009.
Il s'est attardé sur les principales nouveautés de Java EE 6 :
- JAX-RS : l'API pour développer des web services RESTfull, en utilisant uniquement des simples classes java (POJO) et des annotations.
- Bean Validation (JSR 303) : l'API pour définir des contraintes par annotation directement sur les entités métier.
Il sera intégré avec JSF et JPA pour que la validation soit automatique dans les frameworks associés. Par ailleurs, on pourra étendre les contraintes en créant ses propres annotations de contraintes.


- Web Profile : le premier sous-profil Java EE. Ce profil est en fait une sous-partie de Java EE 6, qui inclut les principales APIs utilisées pour développer des sites web. En plus de Servlet/JSP/JSTL/JSF, on pourra y retrouver des APIs plus poussées comme Managed Beans, EJB 3.1 lite, JPA et JTA. Ainsi, avec un serveur d'applications implémentant ce profil, on pourra réaliser des applications relativement complètes. Par contre, je vois mal Tomcat implémenter EJB 3.1 lite, JPA et JTA... On verra l'adoption de ce web profile par les serveurs d'applications.
- Servlet 3.0 :
Ont été ici cités : les web fragments, le fichier web.xml désormais optionnel, la configuration de servlets par annotation, la possibilité d'initialisation de librairies partagées, la registration de servlets par programmation (au démarrage), et la possibilité d'intégrer des ressources statiques dans les JARs des frameworks web.
Pour plus de détails sur cette API, vous pouvez lire notre compte-rendu de la soirée Servlet 3 & JSF 2 au Paris JUG.
- Dependency Injection : API permettant de standardiser l'injection de dépendance (JSR 299 et JSR 330).
En plus de l'annotation @Resource (existante dans Java EE 5), a été rajoutée l'annotation @Inject.
Les beans sont découverts au démarrage de l'application.
Possibilité de parcourir le métamodel d'injection, par l'API BeanManager
- EJB 3.1 :
ajout de l'annotation @Singleton (pour un EJB ayant une unique instance)
ajout de l'annotation @Startup (pour l'initialisation d'un EJB au démarrage de l'application)
ajout de l'annotation @Asynchronous (pour déclarer l'invocation d'un EJB comme asynchrone)
possibilité de définir un EJB directement dans un WAR
API EJBContainer pour pouvoir démarrer/exécuter un conteneur EJB dans une application Java SE ou pour les tests unitaires
- JSF 2.0 :
standardisation des facelets
définition de managed beans par annotation
intégration d'AJAX
et même une API JavaScript fournie
Tout comme Servlet 3.0, pour plus de détails sur cette API, vous pouvez lire notre compte-rendu de la soirée Servlet 3 & JSF 2 au Paris JUG.

Une démonstration a ensuite été faite de GlassFish V3, qui est l'implémentation de référence de Java EE 6.
On a alors appris qu'un plugin pour Eclipse existait et la démo en a attesté.
De la démo, on retiendra :
- un démarrage de Glassfish V3 en 3 secondes chrono (merci OSGi)
- une application web sans fichier web.xml (servlet définie par annotation uniquement)
- rechargement à chaud : on enregistre la modification dans Eclipse, on fait F5 dans son navigateur et ça marche ! Le tout en conservant la session utilisateur...
- démonstration de l'ajout simple d'un EJB directement dans l'application web : un EJB simple POJO avec l'annotation @Stateless, une servlet l'intégrant en variable d'instance (@EJB MonEJB monEJB), un appel à l'EJB dans la méthode doGet() de la servlet, hop, on rafraichit le navigateur et ça marche ! Bluffant de simplicité... au point que la salle applaudit
- démonstration de l'intégration d'un module OSGI dans la même servlet, toujours avec aussi peu d'étapes, et une intégration simple par annotation, on recharge le navigateur, et ça marche... Toujours pas de redémarrage du serveur d'applications, vraiment bluffant...


Enfin, Chet Haase (de Adobe) a montré l'ensemble de la gamme des produits d'Adobe, démo à l'appui.
On retiendra :
- Flash 10.1 optimisé pour être compatible avec des smartphones
- l'empreinte mémoire de la VM Flash 10.1 est globalement 2 fois inférieure à celle de la VM Flash 10.0
- une démo a par ailleurs été faite sur un smartphone de l'application parleys.com (qui fait du streaming vidéo), qui était particulièrement fluide.
- BlackBerry/RIM et Google Android sont en train d'intégrer Flash dans leur système
- Pour Apple/iPhone, ils ont indiqué qu'un outil permettait de convertir une application Flash en application iPhone SDK (démo à l'appui...)
- AIR 2.0 apporte plus de rapidité, et ouverture directe des fichiers dans le système d'exploitation
- une démo assez bluffante de Flash Catalyst : transformation de fichiers PhotoShop en une application Flash/Flex en quelques étapes (pour autant, il s'agissait grossomodo de la même démonstration que l'an dernier)

Ainsi se termine ce premier keynote, qui ma foi, fut assez intéressant !
 

lundi 16 novembre 2009

SFEIR en force à DEVOXX 2009 !

Cette semaine, a lieu un événement important pour la communauté java : DEVOXX 2009.
Il s'agit de la deuxième plus grosse conférence mondiale (et la première européenne) autour des technologies java.

Pour la quatrième année consécutive, SFEIR sera présent à l'événement, et pas qu'un peu : pas moins de 20 collaborateurs SFEIR feront le déplacement pour participer à DEVOXX 2009 les mercredi 18 et jeudi 19 novembre !

Pendant ces deux jours, nous essaierons de vous faire partager au mieux l'événement, en publiant des billets sur insideIT relativement aux sessions présentées.

Donc, si vous n'avez pas eu la chance d'avoir votre billet pour DEVOXX 2009, suivez le blog insideIT !

En attendant, voici le programme prévu pour ces deux jours :
- mercredi 18 novembre : http://www.devoxx.com/display/DV09/Conf+Day+1
- jeudi 19 novembre : http://www.devoxx.com/display/DV09/Conf+Day+2

dimanche 18 octobre 2009

Compte-rendu de la soirée JSF 2.0 / Servlet 3.0 au Paris JUG

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

jeudi 11 juin 2009

Eric Evans au Paris JUG lundi 15 juin

Ce cours post pour vous signaler la venue d'Eric Evans au Paris JUG lundi 15 juin (ce lundi) à 19h30 pour une soirée exceptionnelle dans les locaux de l'EPITA (KB).

Eric viendra parler du Domain Driven Design dont il est le fondateur.

C'est une présentation du niveau des grandes conférences telles que Devoxx ou Jazoon, sauf que vous ne payez ni le transport ni la conférence :-)

Inscriptions ici : http://parisjug.org/xwiki/bin/view/Meeting/20090615

mercredi 8 avril 2009

Développez en Java vos applications Google App Engine :

Il y a à peu près un an, Google ouvrait l'App Engine aux développeurs, il n'était alors possible de déployer que des applications développées en Python.
Pour rappel, Google App Engine est une offre de Cloud Computing permettant aux développeurs d’héberger leurs applications Web sur les serveurs de Google. Les applications ainsi hébergées bénéficient de ce fait de la même capacité de montée en charge que les services Google tels que Gmail ou Google Finance.
Google n’est pas la seule entreprise positionnée sur ce secteur, bien que pas tout à fait similaires, Amazon et Microsoft ont eux aussi leurs offres avec respectivement AWS et Windows Azure.
Un des atouts de Google App Engine c’est que gratuitement un développeur peut déployer une application qui soit accédées à raison de 5 millions de pages vues par mois. Ce qui est somme toute une offre d’hébergement intéressante. Au-delà de ces quotas, il est possible d’acheter des ressources supplémentaires.
Depuis quelques mois, nous pouvions voir dans la roadmap de ce projet que le support d’autres langages était un des objectifs de Google. Aujourd'hui, c’est chose faite, Google ouvre son service à une nouvelle communauté et contrairement à leur poisson d’avril, ce n’est pas Fortran mais bien Java qui est désormais supporté.
Cette nouvelle devrait donc être accueillie avec un vif enthousiasme lorsque l’on sait que le support de Java a été l’une des premières évolutions suggérées par les développeurs lors de la sortie de la première version de l’App Engine.
La version Java ne déroge pas au qualificatif de « Simple d’utilisation » qui caractérisait la version Python. En effet, il n’y a pas de différence majeure dans l’approche qu’ont ses deux dernières. Un atout supplémentaire de la version Java et qui a son importance, c’est le fait qu’elle s’accompagne d’un plugin Eclipse. Il est ainsi possible de créer une application et de la déployer en quelques clics.
De plus, l’intégration avec GWT (Google Web Toolkit) est enfantine et proposée par défaut par le plugin.
L’environnement de développement App Engine Java supporte les versions Java 5 et Java 6, sachant que sur les serveurs distants c’est la 6 qui est supportée. Les pré-requis au développement et au déploiement d’applications sur la plate-forme sont relativement faibles : avoir installé Java et le SDK de l’App Engine. L’installation du plugin Eclipse est bien entendu un plus non négligeable.
L’administration des applications se fait via la même interface que pour les applications Python. Il est ainsi possible de voir la répartition de la charge dans le temps, les requêtes HTTP les plus récurrentes, le taux d’utilisation ramené aux quotas. Il est également possible de consulter les logs. Enfin, une page permet d’accéder aux données stockées dans le Datastore.
Etudions de plus près l’architecture d’un projet et l’utilisation des APIs

Passons à la pratique : 

Les applications Google App Engine doivent être structurées en respectant l’arborescence WAR, ainsi, si vous créez un projet via le plugin Eclipse, vous obtiendrez une structuration semblable à celle-ci :

Cette arborescence de projet ne présente pas de spécificité particulière, on notera la présence d’un fichier web.xml permettant d’assurer le mapping entre les URLs et les classes des Servlets.
Lorsque vous déployez une application sur Google App Engine, une association s’opère entre les fichiers que vous transférez sur les serveurs de Google et les applications que vous êtes en mesure d’administrer. Cette association est possible grâce à un identifiant que vous vous devez de retranscrire dans le fichier appengine-web.xml. Ce fichier est l’équivalent du fichier app.yaml de la version Python de l’App Engine.
Les Servlets sont tout à fait communes et ne différent pas de celles que l’on peut développer dans une application traditionnelle. La Servlet d’un HelloWorld pourrait donc se présenter ainsi :

package com.sfeir.demo;

import java.io.IOException;
import javax.servlet.http.*;

public class DemoServlet extends HttpServlet {
    public void doGet(HttpServletRequest req, HttpServletResponse resp)
            throws IOException {
        resp.setContentType("text/plain");
        resp.getWriter().println("Hello, world");
    }
}


Maintenant que nous savons qu’il n’est pas difficile de créer un projet, intéressons nous aux APIs spécifiques de Google App Engine.

Utiliser les APIs :

Authentification

Ajouter un système d’authentification des utilisateurs se fait tout aussi facilement qu’avec la version Python :

package com.sfeir.demo;

import java.io.IOException;
import javax.servlet.http.*;
import com.google.appengine.api.users.User;
import com.google.appengine.api.users.UserService;
import com.google.appengine.api.users.UserServiceFactory;

public class DemoServlet extends HttpServlet {
    public void doGet(HttpServletRequest req, HttpServletResponse resp)
              throws IOException {
        UserService userService = UserServiceFactory.getUserService();
        User user = userService.getCurrentUser();

        if (user != null) {
            resp.setContentType("text/plain");
            resp.getWriter().println("Hello, " + user.getNickname());
        } else {
            resp.sendRedirect(userService.createLoginURL(req.getRequestURI()));
        }
    }
}


Ici, on utilise le UserService pour récupérer l’utilisateur actuellement connecté à l’application. S’il y a bel et bien un utilisateur authentifié, nous lui affichons un message de bienvenue et si ce n’est pas le cas, l’API nous permet de le rediriger vers une page de login. Lorsque vous travaillez en « local », le système d’authentification est émulé, il n’y a pas de vérification à proprement parler de l’existence des utilisateurs. Lorsque vous déployez votre application, le UserService se base sur les Google Accounts pour vérifier l’existence des utilisateurs.

Il est également possible de savoir si l’utilisateur actuellement authentifié est un administrateur de l’application et ainsi de lui donner accès ou non à certaines fonctionnalités.

Persistance


Attention, comme pour la version Python de Google App Engine, le stockage des données ne s’effectue pas dans une base de données relationnelle. Google dispose de son propre formalisme de stockage des données qui s’apparente à une Map multidimensionnelle partagée.
Le développeur dispose de trois solutions distinctes pour persister ses données, en effet, Google App Engine Java implémente JDO (Java Data Object), JPA (Java Persitance API) et met également à disposition une API de plus bas niveau (Datastore API).
Dans cette version de Google App Engine, Google pousse un Framework de persistance : DataNucleus. Sa configuration se fait très simplement (voir doc pour plus de détails)
Voici un exemple utilisant JDO, la définition des données à persister se fait par annotation.
Ci-dessous, l’objet Comment est défini comme pouvant être persisté, en le sauvant, les éléments annotés comme @Persistent feront parti de la sauvegarde.

package com.sfeir.demo;

import java.util.Date;
import javax.jdo.annotations.IdGeneratorStrategy;
import javax.jdo.annotations.IdentityType;
import javax.jdo.annotations.PersistenceCapable;
import javax.jdo.annotations.Persistent;
import javax.jdo.annotations.PrimaryKey;
import com.google.appengine.api.users.User;

@PersistenceCapable(identityType = IdentityType.APPLICATION)
public class Comment {
    @PrimaryKey
    @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
    private Long id;

    @Persistent
    private User author;

    @Persistent
    private String content;

    @Persistent
    private Date date;

    public Comment(User author, String content, Date date) {
        this.author = author;
        this.content = content;
        this.date = date;
    }

}

Il est ensuite très simple de manipuler cet objet au travers de l’API. Ainsi, pour persister une instance de cet objet, on peut utiliser le PersistenceManager de la manière suivante :

Comment comment = new Comment(user.getNickName(), content, new Date()) ;
PersistenceManagerFactory pmfInstance =
        JDOHelper.getPersistenceManagerFactory("transactions-optional");
      PersistenceManager pm = pmfInstance.get().getPersistenceManager();
        try {
            pm.makePersistent(comment);
        } finally {
            pm.close();
        }



Avec ce PersistenceManager, il est tout aussi simple de récupérer un objet pm.getObjectById(…) ou encore de le supprimer pm.deletePersistent(…).
Au même titre qu’il était possible d’interroger la base au travers du GQL dans la version Python, il est ici possible d’utiliser un langage de requête proche de SQL pour récupérer des données, il s’agit de JDOQL.
On pourrait récupérer la liste de nos commentaires ainsi :

PersistenceManagerFactory pmfInstance =
        JDOHelper.getPersistenceManagerFactory("transactions-optional");

PersistenceManager pm = pmfInstance.get().getPersistenceManager();

String query = "select from " + Comment.class.getName();
List<Comment> comments = (List<Comment>) pm.newQuery(query).execute() ;


Gestion d'un cache mémoire


Afin de ne pas surcharger le Datastore avec des requêtes récurrentes, il peut être intéressant de stocker un certain nombre d’informations dans un cache mémoire. Cela peut se faire très simplement au travers de l’utilisation de la Memcache API.

cache = CacheManager.getInstance().getCacheFactory().createCache(Collections.emptyMap());
cache.put(‘‘cachedInteger’’, 25) ;
Integer cachedValue = (Integer) cache.get(‘‘cachedInteger’’);



Dans l’exemple ci-dessus, après avoir récupéré l’instance du cache mémoire, on y insère un entier à la clef « cachedInteger » au travers d’un put. Un simple get avec la clef nous permet de récupérer la donnée que nous avions mise en cache.
Le cache est utilisé pour cet exemple de manière très simpliste mais on pourrait imaginer l’utiliser pour retourner des informations ayant plus de valeur, comme le contenu RSS de l’application ou encore une page fréquemment requêtée.
Cette API de cache propose d’autres fonctionnalités intéressantes comme la possibilité de définir une période de validité pendant laquelle les données peuvent être considérées comme « fraiches ». Différentes politiques de gestion sont également applicables, ainsi il est possible de n’ajouter la donnée que si celle-ci est déjà présente ou réciproquement.

Envoi de mail


L'envoi de mail fait partie des fonctionnalités intégrées à Google App Engine et relativement simples à mettre en place au sein d'un projet.
Dans cette version Java, l'API implémente l'interface JavaMail, pour des raisons de sécurité, seules les adresses d’un administrateur de l’application ou celle de l’utilisateur couramment authentifié peuvent être spécifiées comme adresses de l’émetteur.
       

Properties props = new Properties();
        Session session = Session.getDefaultInstance(props, null);

        String msgBody = "Contenu du mail";

        ...
        Message msg = new MimeMessage(session);
        msg.setFrom(new InternetAddress("admin@mondomaine.com"));
        msg.addRecipient(Message.RecipientType.TO,new InternetAddress("destinataire@sondomaine.com", "Destinataire"));
        msg.setSubject("Email envoyé par Google App Engine");
        msg.setText(msgBody);
        Transport.send(msg);


L’exemple ci-dessus montre l’envoi d’un mail basic, sachez qu’il est également possible d’ajouter des pièces jointes (voir types MIME autorisés) avec la contrainte toutefois que l’e-mail ne dépasse pas les 1mb.

Comme pour la version Python, il est également mis à la disposition des développeurs une API permettant d’interroger des hôtes distants (via l’API URL FETCH) et une autre permettant de manipuler des images.

Cette version de Google App Engine étant toute récente, il va être intéressant de suivre l’adhésion des développeurs de la communauté Java à ce service. D’une part, elle offre une grande facilité de développement et de ce fait un gain de temps dans l’élaboration d’applications, ce qui devrait en attirer plus d’un. D’autre part, tout comme pour la version Python un certain nombre de quotas et de restrictions sont à prendre en compte lors de l’utilisation de ce service, ce qui exclu certain types d’applications de cette offre d’hébergement.

Cette nouvelle version est également un beau coup de pousse donné à GWT, en effet le plugin Eclipse permet de créer en quelques clics une application GWT pour Google App Engine et devrait donc  amener davantage de développeurs à adopter ce Framework Web.

Google Guice sera peut être un autre des bénéficiaires de cette version Java, bien qu’il ne soit pas poussé outre mesure par Google pour être associé à Google App Engine, sa légèreté et sa simplicité d’utilisation devrait lui permettre de s’intégrer facilement aux applications déployées sur la plate-forme.

Quoi qu’il en soit c’est une nouveauté que nous nous devons de suivre.

Références :

Pour s'inscrire
L'annonce officielle
Le Coud Computing
Tout sur Google App Engine
DataNucleus
Découvrir GWT
En savoir plus sur GUICE
Amazon Web Services
Windows Azure

jeudi 19 février 2009

How to : Spring Security (ex Acegi) and GWT

As you know, Spring Security (previously Acegi) provides an easy and robust solution to secure web applications. Thereby, web developers do not have to deal with all that stuff in their source code, but just have to configure Spring Security to enable authentication and authorization for their application.

As it works pretty good with 'conventional' application, things go less cool with applications like GWT ones. This is mainly due to the asynchronous calls.

Lire la suite...

mercredi 11 février 2009

Le Paris JUG a 1 an

Paris JUG

Ce soir le Paris JUG fêtait son premier anniversaire dans une ambiance chaleureuse.

Quelques chiffres sur l'année passée :

  • Un public composé majoritairement de développeurs seniors et d'architectes ;
  • Le site Web compte 15000 visites pour les 7 derniers mois (majoritairement d'île de France).

A suivi un quicky d'un quart d'heure sur Wicket par Tarik Filali Ansary.
Wicket m'a semblé être un framework recherchant des objectifs similaires à GWT : simplifier la vie des développeurs Java pour la création d'application Web.
Rien n'est plus explicite que quelques exemples.
De plus Wicket semble jouir d'une communauté très active : Wicket Stuff, Wicket Library.

Par la suite, nous avons pu nous rendre compte combien les JUG florissent en France. En effet, cette session avait pour invités d'honneur des représentants de tous les JUG français : Christophe Jollivet (Tours JUG), Xavier Hanin (Bordeaux JUG), Nicolas Leroux et Stephane Epardaud (Riviera JUG), Nicolas de Loof (BreizhJug), Sebastien Roul (Nantes JUG), Christophe Meyer, JM Doudoux et Xavier Roy (Lorraine JUG), Gaël Blondelle (Toulouse JUG), Julien Ripault et Cédric Exbrayat (Lyon JUG).

Puis Christian Frei a présenté Jazoon09 de manière très dynamique.

Ce fut ensuite le tour de Stephan Janssen avec pour sujet Parleys.
J'avais déjà assisté à la présentation de la version Flex de Parleys durant JavaPolis07 mais je ne pense pas me tromper en disant que Stephan a eu beaucoup d'effet sur l'assemblée de Juggers en présentant les versions prototype JavaFX et surtout GWT !
Pour la partie moins fun, Parleys proposera bientôt des espaces professionnels pour poster des présentations. Ces espaces seront gratuits pour les JUGs.
Pour finir, Stephan a continué d'envoyer la purée en présentant l'outil de post-processing vidéo qu'il a développé (avec Adobe AIR) pour traiter les enregistrements des conférences Devoxx.

Pour la présentation de Java SE 7 Dolphin, ... et bien, j'étais en train de me faire masser donc je n'ai pas pu prendre de notes ! D'ailleurs merci aux masseurs et aux organisateurs du Paris JUG, c'était un très bonne idée, et toutes mes excuses à Thomas Chamas.
Par contre je me souviens en avoir entendu parler durant une keynote de Devoxx08

Le dernier quicky traitait de l'état de l'art et de l'utilisation de Java dans les jeux vidéo (avec Java Binding for Open GL) par Julien Gouesse.
J'avoue qu'il m'a bluffé. Je ne savais pas que des jeux développés en Java étaient commercialisés même s'ils se comptent sur les doigts.
Pour les personnes intéressées par ce genre de développement, le code source du doom-like TUER développé par Julien est dispo ici.
Par ailleurs, la fluidité de la démonstration du jeu TUER a également bluffé l'ensemble des spectateurs : voir un jeu 3D développé en java aussi fluide, j'avoue que je ne m'y attendais pas.

lundi 2 février 2009

JavaFX : Widgets pour applications professionnelles

Le petit dernier des candidats aux applications RIA, JavaFX, est sorti dépourvu des composants graphiques utiles et nécessaires au développement d'applications à destination des professionnels. Comme Sun semble occupé à mettre le paquet sur une prochaine release en début d'année, incorporant la partie "Mobile", il est peu probable d'en voir arriver tout de suite par le canal officiel.

Alors, quels sont les choix ? Et bien, on se retrouve un peu comme aux débuts de GWT : nous avons un socle technique, il ne reste qu'à retrousser ses manches. Oui mais voilà, tout le monde ne souhaite pas réinventer la roue.

Alors inspirons nous de ce qui a été largement fait pour GWT (par exemple) : le wrapping. Avec GWT il est relativement aisé de wrapper les librairies JavaScript (Ext, SmartClient...) pour pouvoir utiliser les composants existants et souvent de qualité. Avec JavaFX, il est permis de wrapper n'importe quel composant Swing étendant javax.swing.JComponent, autrement dit un nombre assez conséquent :-)

Certes la tâche peut paraitre conséquente - et elle l'est d'ailleurs - mais si une communauté prend autour de JavaFX, des librairies de ce type peuvent rapidement apparaître. Voici un tutorial illustrant comment wrapper la célèbre librairie JFreeChart, tant utilisée par ailleurs !

Lire la suite...

lundi 19 janvier 2009

Compte-rendu de la soirée Java EE 6 et GlassFish V3 au Paris JUG

La semaine dernière s'est tenu la première réunion du Paris JUG de l'année !

Au menu, présentation de la future spécification Java EE 6 par Antonio Goncalves (également co-organisateur du Paris JUG), et présentation du serveur d'applications de Sun - Glassfish - par Alexis Moussine Pouchkine.

La soirée commence avec quelques annonces :

  • La prochaine réunion sera spéciale, le Paris JUG fêtera sa première année (déjà !). Pour l'occasion, les organisateurs des JUG français ainsi que l'organisateur de Devoxx seront présents, et on aura le droit à une série de Quickies sur différents sujets. Tarik Filali Ansary, chef de projet technique chez Sfeir, viendra nous présenter Wicket.
  • Le Paris JUG, attirant de plus en plus de monde, commence à être victime de son succès. Trop de monde, pas assez de budget pour investir dans une autre salle -> inscription obligatoire pour les prochaines réunions.
  • Après XP France, un nouveau groupe d'agilistes est en cours de création, le French Scrum User Group. Lancement prévu le 19 mars, avec Jeff Sutherland himself, rédacteur du manifeste agile et fondateur de Scrum.

Ces annonces faites, Antonio a commencé à nous présenter Java EE 6. Pour info, Antonio est JCP Expert Member de Java EE 6, JPA 2.0, et EJB 3.1. 

Java EE 6

Java EE 6, c'est 28 JSRs, environ 500 pages par spec. Le travail est encore en cours, peu de JSRs ont atteint le statut de public draft, et la sortie est prévue pour mai 2009.
... et présenté par Antonio, c'est façon Daft Punk : richer, easier, lighter !

Richer et en même temps lighter ?

Oui, c'est possible grâce à l'apparition :

  • des EJB Lite. La spécification EJB-lite est un sous-ensemble de la spécification EJB qui supprime notamment le support de RMI, EJB 2.x, Message Driven Bean.
  • des profiles. Le profile "web" permet de supporter la base de "Java EE", et même plus puisque cela inclut les EJB-Lite. Cela permettra à des serveurs d'applications légers d'être certifié sur un sous-ensemble de Java EE 6.
  • du pruning. Plus fort que le deprecated, le pruning doit permettre de se séparer des vieux morceaux obligatoirement présents en raison de compatibilité ascendante. A noter que Entity CMP, JAX-RPC et JAX-R seront "prunées" dans Java EE 6. Cela signifie que ces APIs seront tout simplement supprimées dans la spécification Java EE 7 !

Antonio a ensuite zoomé sur certaines spécifications :

  • Servlet 3.0 : on peut se passer du web.xml en le remplaçant par des annotations. Pour plus de modularité, il sera également possible de casser le web.xml en fragments. La nouvelle version de la JSR permettra également le mode asynchrone. Une partie du mode asynchrone est déjà implementée dans glassfish et permet de faire du reverse Ajax.
  • JSF 2.0 : de nouvelles annotations vont permettre de simplifier le développement d'applications JSF, et comme pour l'API Servlet 3.0, de rendre optionnel le fichier faces-config.xml. JSF 2.0 intégrera facelet.
  • EJB 3.1 : oh ! des annotations. Entre autres, une annotation Singleton, et une autre facilitant la gestion des appels asynchrones (par simple annotation sur une méthode d'EJB). Cela permet de se passer de l'utilisation de JMS qui peut être plus fastidieuse. Nouveauté également, on peut créer facilement un container d'EJBs à la volée (très pratique pour les tests unitaires). La définition d'EJB devient extrêment simplifiée : il suffit de rajouter l'annotation @Stateless pour qu'un simple POJO devienne un EJB, plus besoin de configuration XML lourde. D'autre part, pour un EJB local, une interface de l'EJB n'est plus nécessaire. Enfin, on pourra dorénavant créer des EJBs directement dans un WAR (plus besoin d'un EAR, qui contient un JAR EJB). Ainsi le développement d'EJB devient beaucoup plus simple à mettre en oeuvre pour un développeur. C'est cette simplicité qui a jusqu'ici fait défaut aux EJB, au profit de Spring. Dernier point : les noms JNDI des EJB deviennent portables (plus de nom JNDI adhérent au serveur d'applications).
  • Timer services : une nouvelle syntaxe apparaît (avec des annotations !), s'inspirant de Cron et de Quartz. Séduisant par son apparente simplicité.
  • JPA 2.0 : La spécification JPA 2.0 est désormais complètement indépendante de la spécification EJB, elle n'est plus vue comme un sous-ensemble de EJB (comme c'était le cas dans JPA 1.0, source de confusion). On notera la possibilité d'utiliser JPA 2.0 dans Java SE, de mapper des collections de types simples, d'utiliser des locks pessimistes, et une API "Criteria" (proche d'easyMock dans l'esprit). Rien de nouveau, mais JPA couvrira désormais plus largement les fonctionnalités d'Hibernate.
  • JAX-RS 1.1 : API permettant d'implémenter des Web Services RESTfull. Encore une fois, tout est basé sur les annotations. Il suffit de rajouter l'annotation @Path("/helloWorld") devant une classe POJO et une annotation @GET devant la méthode qui sera appelée pour les appels en méthode GET, pour obtenir une ressource REST. L'API est donc simple à utiliser. A voir pour les cas plus complexes.

Antonio nous a ensuite affiché un arbre représentant la stack technologique Java EE 6. Maintenant, avec la simplicité apportée par Java EE 6, on peut faire une application JSF / EJB / JTA / JPA dans un simple WAR.
Pour finir, on nous a présenté l'implémentation de référence de chaque JSR. GlassFish V3, présenté dans la 2e partie de soirée, sera l'implémentation de référence de EJB 3.1 et Servlet 3.0.

C'est tout pour la présentation de Java EE 6, qui sortira cette année. A noter que Java EE 5 a 3 ans et que la plupart des serveurs d'applications sont compliant Java EE 5 depuis peu, le dernier en date étant JBoss en décembre 2008...

La présentation s'est terminée par une session de questions-réponses, en voici quelques-unes :

  • D'un côté Java EE 6 présente 5 conteneurs différents, de l'autre Spring n'en présente qu'un, pourquoi, quel est l'intérêt ? Antonio répond que le sujet des Web Beans n'est pas tout à fait réglé, sans plus de détails. Nicolas Martignole semble avoir obtenu plus d'informations sur le sujet au cours de la 3ème mi-temps !
  • Pourquoi ne pas mettre plus le focus sur la JSR Servlet 3.0, ça semble pourtant être la principale avancée ? Réponse : Parce que cette spécification a été sujet à controverse, n'est pas finie, et n'est pas des plus faciles à appréhender.
  • JSF est un framework orienté composant, il n'y a rien sur les frameworks orientés actions ? Réponse : en effet !

GlassFish

Quelques retrouvailles / petits fours / t-shirts Glassfish plus tard, Alex Moussine-Pouchkine nous présente GlassFish. Plus précisément GlassFish V3 Prelude, qui est un "prelude to Java EE 6". GlassFish veut être early adopter de la spécification Java EE 6. La plupart des futures spécifications sont d'ailleurs déjà implémentées, en mode preview. On retrouve ainsi JSF 2.0 Preview et EJB3.1 Preview.

Glassfish est à l'origine basé sur Tomcat, mais se veut un serveur d'applications complet.
Alexis commence la session en essayant une comparaison Glassfish / JBoss pas vraiment équitable, puisque les téléchargements GlassFish prennent en compte le nombre de téléchargements du SDK Java EE 5 (Glassfish est inclus dans le SDK Java EE 5).
Glassfish se présente comme étant "au même niveau côté performances" que WebSphere et WebLogic. La mode étant au light (lightweight containers, lightweight ESBs, EJB lite ...), GlassFish se présente comme un "lightweight application server". Glassfish pourrait d'ailleurs être l'un des premiers à se positionner sur les serveurs d'applications "web profile compliant", mais c'est également bien plus, comme on a pu le voir par la suite.

GlassFish se veut avant tout modulaire et extensible. Modulaire car son noyau est basé sur OSGi (ce qui est transparent pour les développeurs). Extensible car basé sur HK2. GlassFish v3 a ainsi un socle ouvert, permettant à tout le monde de pouvoir créer et déployer ses extensions HK2.
Alexis nous fait ensuite une démonstration : GlassFish possède des fonctionnalités intéressantes pour les développeurs, en particulier la sérialisation de sessions HTTP et le “compile on change” (rechargement à chaud des modifications, très pratique en phase de développement). Le démarrage rapide (15 à 20 secondes sur un ordinateur portable), grâce à un système de mise en cache, est également mis en avant. Enfin GlassFish propose un AppStore façon serveur d'applications : l'Update Center. Semblable au apt-get de Debian, l'Update Center permet d'ajouter des briques logicielles à son serveur d'applications. On y trouve par exemple des composants permettant l'intégration de Grails ou Rails.

Côté versions, la 2UR2 (bientôt 2.1) est celle mise en avant commercialement, pour sa robustesse et son support SUN. La V3 définitive sortira vers juin 2009, pour être présentée à JavaOne 2009, et devrait être certifiée Java EE 6. Attention, certains composants Glassfish v2 ne sont pas portés sur Glassfish v3 pour le moment. Ainsi la V3.1, apportant le clustering, sera disponible fin 2009.


Bienvenue au Paris Java User Group !

GlassFish - Open Source Application Server

Résultats du Tableau Blanc lors du buffet


Article rédigé par les sfeiriens du Paris JUG : Fabien Baligand, Tanguy Bayard et Tarik Filali Ansary.

mercredi 17 décembre 2008

JavaCamp #2 - compte rendu

Ce soir c'était le deuxième BarCamp Java de Paris. C'est l'occasion de se retrouver entre technophiles dans un format ouvert où chacun peut échanger librement.

Ce que j'aime dans le format BarCamp, c'est que l'on vient avec ses idées, on les post-it-ise et si son sujet rassemble suffisamment de monde on en discute dans la foulée. Ce côté discussion autour du feu de camp est très enrichissant et complète parfaitement les présentations plus grosses du Paris JUG.

Côté organisation : 2 sessions de 45 minutes, et un buffet pour finir.

Session #1

Les sujets :

  • Retour d'expérience de Devoxx.
  • Génération de code
  • Bases de données orientés objets

J'ai participé à la session sur Devoxx, qui a accueilli le plus grand nombre de personnes il me semble. Ceux qui étaient à Devoxx - principalement Nicolas Martignole (le touilleur) et Fabrice Robini (Octo) - ont parlé de leur retour d'expérience, de l'ambiance dans un premier temps, puis des sujets techniques qui nous intéressaient, à savoir Java FX, REST et SpringSource dm Server. Didier est venu nous faire partager son point de vue en fin de session.

Session #2

Les sujets :

  • L'intégration continue et ses outils
  • Les ESBs légers Mule et Spring Intégration
  • Un autre sujet qui m'a échappé

J'ai participé à la session sur les ESBs. Julien Dubois (SpringSource) a présenté Spring Intégration et Spring Batch. On a ensuite parlé de Mule et des outils implémentant les patterns d'intégration de manière plus générale avec un retour d'expérience dans chaque cas.

Le buffet

Le buffet est le moment le plus intéressant, où tout le monde discute par petits groupes dans une joyeuse anarchie. J'ai pu discuter avec des personnes ayant participé à la session sur la génération de code ; elles ont visiblement apprécié ce format ouvert où chacun venait avec sa propre expérience. J'ai également eu une discussion intéressante au sujet d'IntelliJ vs Eclipse : avec des gens qui connaissent bien les deux IDEs on obtient des comparaisons constructives !

Et pour rester dans l'ambiance de Devoxx, on a eu le droit à quelques goodies Octo : boîte à meuh et white paper sur la productivité en Java version papier. Félicitations à Luc pour l'organisation !

mercredi 10 décembre 2008

Devoxx 2008 - From concurrent to parallel

Pour bien commencer Devoxx, j'ai choisi la presentation de Brian GOETZ nommée "From concurrent to parallel".

Pour rappel, Brian GOETZ est auteur du livre Java Concurrency in Practice, une référence sur le sujet.

Sa présentation portait sur le futur JDK 7, et en particulier le fruit de la jsr166y qui y sera integré. La présentation a couvert le spectre des possibilités offertes par cette API, à savoir la possibilité de paralléliser une opération sur un maximum d'unités de traitement (processeur, core, ...) en la subdivisant en sous tâches permettant une répartition de la charge plus efficace.

J'avais il y a quelques temps posté un article présentant justement cette jsr, que je vous invite à relire à l'occasion : Java 7 Fork/Join : Exploiter toute la puissance disponible

Ou si vous souhaitez entrer un peu plus dans le sujet, vous pouvez lire cet article : ForkJoin : Bienvenue dans les mondes parallèles

mercredi 3 décembre 2008

Release de SmartGWT

Sanjiv, le créateur de GWT-Ext vient de sortir la première release de SmartGWT. Sanjiv a réussi à sortir un wrapping de la librairie JavaScript SmartClient en à peine 4 mois !

SmartGWT reprend les principales fonctionnalités de GWT-Ext auxquelles s'ajoutent un databinding puissant, d'avantages de widgets (notamment le composant Calendar, un Google Agenda simplifié) et de meilleures performances d'affichage. Sanjiv a su prendre du recul par rapport à sa précédente expérience, et présente une librairie mieux adaptée au développement d'applications de gestion. Allez voir les sources, vous verrez que l'utilisation des composants graphiques et des datasources se fait de façon beaucoup plus simple qu'auparavant.

Utilisation d'une grille éditable à la volée

A cela s'ajoute une très grande réactivité de l'équipe : critiqués sur leurs styles un peu old school, ils sont déjà en train d'y remédier.

Quelques indicateurs :

  • GWT-Ext incite à passer sur SmartGWT : lien
  • Evolution du nombre de posts du google group GWT-Ext : lien

jeudi 13 novembre 2008

les Rencontres Spring 2008

Aujourd'hui, salle comble pour la première édition des Rencontres Spring. Cet événement co-organisé par SpringSource France et Sfeir marque le partenariat entre les deux entreprises. Pour rappel, Sfeir est un "System Integrator Partner" de SpringSource.

Durant cet événement, des acteurs majeurs de la communauté Spring :

  • Peter Cooper-Ellis, VP de SpringSource depuis juin 2008 après 10 ans chez BEA ;
  • Juergen Hoeller, co-fondateur du framework Spring (avec Rod Johnson) et aujourd'hui principal développeur du framework ;
  • Mark Thomas, principal contributeur au projet Apache Tomcat ;
  • Guillaume Laforge, co-fondateur du défunt G2One et désormais lead des développements Groovy et Grails chez SpringSource ;
  • Julien Dubois, directeur régional France de SpringSource ;
  • Didier Girard, directeur de l'innovation de Sfeir.

et des utilisateurs de la technologie :

  • Voyages SNCF Technologies ;
  • HSBC ;
  • SG CIB ;
  • Improve ;
  • Grails.

ont respectivement annoncé les nouveautés que nous réserve SpringSource pour l'année à venir et témoigné de la puissance de l'offre de SpringSource.

Des témoignages, je retiens que les technologies Spring respectent leurs engagements. Elles simplifient le développement, réduisent les coûts et assurent de bonnes performances :

  • le site www.voyages-sncf.com supporte très bien la charge avec une infrastructure minime ;
  • réduction de 60% du code écrit chez HSBC grâce à un framework "maison" reposant sur Spring ;
  • temps de réponse de l'ordre des millisecondes garantis chez la SG CIB.

Beaucoup de nouveautés nous attendent, entre-autres :

  • évolution de SpringSource dm Server ;
  • Spring 3.0 ;
  • intégration de Flex dans Spring Web ;
  • intégration de Groovy et Grails dans la stack Spring ?

Voici les nouveautés marquantes de la version 3.0 du framework Spring :

  • évolution du modèle de description par annotation ;
  • support de Spring Expression Language pour la configuration des beans ;
  • le support de REST dans Spring MVC ;
  • ajout d'un modèle de validation basé sur les annotations (respectant la JSR 303 et le modèle de validation d'Hibernate).

Concernant les aides au déploiement, SpringSource mise sur son dm Server. Ce serveur d'application Java est basé sur OSGi et a été pensé pour offrir une grande modularité. Cette modularité permet une meilleur gestion des ressources. Cela résulte en un serveur avec une trace légère donc au démarrage rapide, ce qui est très apprécié par les développeurs. Grâce à l'approche OSGi, SpringSource dm Server offre également la flexibilité pour la gestion des applications en permettant le chargement à chaud et le multi-versioning.
Peter Cooper-Ellis, fort d'une longue expérience dans le développement de BEA WebLogic, annonce une évolution sur le marché des serveurs d'applications. La demande est à l'agilité.

Photos de l'événement sur flickr.
Bientôt : Les slides et les vidéos de l'événement.

mardi 14 octobre 2008

PureMVC Multicore for Java (compatible with GWT)

The first version of the PureMVC Multicore framework for Java which is compatible with GWT has been relased here under Creative Commons Attribution 3.0 license. For those who do not know MVC, you should look at Wikipedia. Then, if you want to know more about PureMVC, you should continue with the conceptual diagram and best practices. These documents demonstrate the Singleton version, they are a good introduction to PureMVC concepts.

jeudi 11 septembre 2008

Qualité de code : quelques outils

Quality_is_your_responsabilityDévelopper ne relève pas de l'exploit, mais développer bien, un peu plus... Les nouvelles méthodes de développement imposent un rythme soutenu, une polyvalence permettant d'intervenir sur des portions de code appartenant à un autre membre de l'équipe, etc. Bref, plein de bonnes raisons qui encouragent de maintenir un code propre, suivant des règles communes entre membres de l'équipe, testé de la façon la plus exhaustive possible... On pourrait croire que seul un monde parfait peut permettre d'atteindre cet objectif, et bien pas forcément : il existe différents outils que vous connaissez sûrement, peut être que vous utilisez aussi, qui aident à atteindre cet objectif. Ces outils ne doivent pas être une mallette de secours quand tout commence à aller mal, mais le fil rouge au long du cycle de vie du projet qui sera le gage de la performance de l'équipe.

Voici donc présentés brièvement quelques ténors du secteur.

Lire la suite...

dimanche 29 juin 2008

débuter avec Restlet

restlet_logo Dans le cadre d'un projet sur lequel je suis intervenu, j'ai eu a refactorer le format des URIs d'un middleware RESTful. Ce fut également l'occasion d'introduire Restlet, le framework Java de référence pour faire du REST, à la place d'un framework "maison". La refacto fut courte et sans douleur, c'est pourquoi je recommande Restlet aux personnes qui souhaitent faire du REST en Java et leur donne quelques liens pour débuter.

Pour commencer, je me suis appuyé sur l'exemple "First Resource", qui permet de se familiariser avec les notions de Restlet grâce à un exemple simple.

Concernant la sécurité, tout ce qu'il y a à savoir se trouve sur la page "Securing a Restlet application"

Pour la gestion des exceptions, il suffit d'étendre la classe StatusService puis d'affecter la nouvelle classe à l'Application concernée.

Pour finir, il ne faut pas oublier de modifier le fichier "web.xml" comme indiqué ici.

- page 1 de 2