Nous allons voir que Java EE 6 n’a maintenant rien à envier à Spring. Cette plateforme est devenue légère et simple à prendre en main. Toutes les spécifications ne seront pas abordées en détails.  Nous parlerons plutôt de conteneurs légers et testables, de managed beans, d’EJB Lite, ainsi que des nombreux services et patterns offert par la plateforme.  Nous terminerons par la spécification CDI et ses extensions portables, qui offrent de belles perspectives à la plateforme Java EE 6.

Spring, c’est quand même bien chouette!

Spring, Spring, Spring… Oui, Spring est un outil qui a révolutionné nos vies de développeurs et qui s’est très rapidement installé chez nos clients. Il a apporté avec lui des paradigmes de programmation comme l’IOC (Inversion Of Control), la DI (dependency injection), l’utilisation de simple POJOs, mais aussi de la simplicité avec ses xTemplate bien utiles. Arrivé en 2003, Spring s’est imposé rapidement dans les entreprises face au standard J2EE 1.4. Ce dernier était un peu Goliath J2EE. Souvenez vous de cette grosse usine à gaz avec ses EJB 2, son conteneur lourd packagé en ear, qui mettait des minutes à démarrer sur un serveur WAS.  Face à lui, un David nommé Spring doté de simples beans POJO, d’un conteneur léger et d’un packaging war déployable sur un simple serveur web, comme Tomcat. Grâce à eux,  Spring s’est imposé dans les entreprises en quelques années .

Java EE 5: début de la cure d’amaigrissement

Mais tout cela, c’était il y a neuf ans et depuis un sacré chemin a été parcouru par la spécification Java EE. En 2006, Java EE 5 est arrivé enrichi de nouvelles transformations. Tout d’abord, son utilisation a été rendue plus simple grâce à l’utilisation massive des annotations. Les EJB 3.0 en ont bénéficié et sont devenus ainsi injectables et plus faciles à implémenter. Il y a eu aussi l’arrivée de JPA, une nouvelle API de persistance, fortement inspirée d’Hibernate qui a fait disparaître les anciens Entity EJB CMP/BMP.

Java EE 6, ça rocks !

Sortie en 2009, Java EE 6 a progressé sur la voie de la simplicité avec l’utilisation massive des annotations et des POJO. A tel point qu’on peut se demander maintenant qui est David et qui est Goliath.
Des API existantes ont encore prospéré de manière significative, comme les EJB 3.1 (dont les EJB Lite), JPA 2.0, JSF 2.0, ou encore Servlet 3.0. De nouvelles API ont fait leur apparition comme CDI 1.0, @Inject 1.0, Interceptors 1.1, JAX-RS 1.1, ou encore Bean Validation 1.0. Et, toujours dans un esprit de “light is right”, de vieilles spécifications comme JAX-RPC, JAX-R, ou JSR88 ont été déclarées “pruned” et devraient disparaître pour la prochaine version de Java EE 7.
Par ailleurs, cette version introduit enfin des noms JNDI standard et donc portables entre les différents serveurs d’application. Cette version embrasse aussi les paradigmes de convention-over-configuration et de configuration-by-exception, qui permettent de ne presque plus rien avoir à configurer, le conteneur appliquant des paramètres par défaut tant qu’il n’ y a pas d’exception. Ainsi, on obtient des applications avec très peu de fichiers de configuration xml.
Avec Servlet 3.0, le bon vieux web.xml est devenu optionnel. Ainsi, ne soyez pas étonné de ne voir qu’en tout et pour tout seulement deux fichiers de configuration dans un projet Java EE: un fichier persistence.xml pour gérer la persistance avec JPA et un fichier beans.xml (qui peut rester vide) pour les managed beans.

Un packaging war grâce au Web Profile 1.0 et aux EJB Lite

L’arrivée des Profiles est une autre nouveauté majeure, ouvrant de nouvelles perspectives. En particulier, le Web Profile qui reprend un sous-ensemble de Java EE et qui permet de packager son application dans un simple war. Le Web Profile embarque les spécifications essentielles communément requises pour développer une application web d’aujourd’hui : JSF, JSP, Servlet, EL, JSTL, EJB Lite, CDI, etc. Cependant, il a été nécessaire de créer des EJB “Lite”, qui n’implémentent pas toute la spécification EJB. Ils conservent néanmoins le principal, à savoir : les Session Beans, l’injection, les interceptors, la transaction et sécurité. Ces sont donc de simples classes POJO, qui n’implémentent pas d’interfaces (appelée ‘no-interface view’). Les EJB Lite sont ainsi déployables dans un simple war.

//Exemple d'un EJB Lite avec une no-interface view
  @Stateless
   public class HelloBean {
       public String sayHello() {
           String message = propertiesBean.getProperty("hello.message");
           return message;
       }
   }

Des conteneurs légers et embarqués

Vous vous souvenez sans doute des serveurs d’application « usine à gaz », qui prenaient parfois quelques minutes à démarrer et à déployer votre application Java EE, . Il était aussi très difficile de tester ces EJB et de réaliser des tests d’intégration automatisés. Ces temps là sont maintenant révolus! Aujourd’hui, nous écrivons de plus en plus des tests unitaires et d’intégration. Nous avons besoin de déployer nos applications le plus rapidement possible pour ne pas être trop pénalisé durant notre cycle de développement. Pour répondre à ces besoins, les EJB 3.1 ont introduit l’idée de conteneurs JEE embarqués. Ces conteneurs EJB implémentent l’API javax.ejb.embeddable et sont packagés dans un jar exécutable n’importe où : du code Java SE, des tests Junit, ou encore un conteneur web. Ce conteneur s’exécute donc au sein de la même JVM que votre programme. Vous pouvez ainsi débugger facilement vos applications avec votre IDE préféré.

…et testables!

Voici un exemple de code Junit, où l’on peut voir comme il est simple de créer un conteneur EJB embarqué à l’aide de API javax.ejb.embeddable.EJBContainer. Des propriétés sont passées à l’ EJBContainer pour préciser où sont les ressources et classes Java. Ensuite, pour récupérer l’EJB, il suffit de faire un lookup dans le contexte en utilisant le nom JNDI portable de l’EJB.

private static EJBContainer ec;
private static Context ctx;
@BeforeClass
public static void createEmbeddedTestContainer() throws Exception {
       Map properties = new HashMap();
       properties.put(EJBContainer.MODULES, new File[]{new File("target/classes"), new File("target/test-classes")});
       ec = EJBContainer.createEJBContainer(properties);
       ctx = ec.getContext();
}
//Pour récuperer un EJB:
ctx.lookup("java:global/classes/MyEJB")

Par ailleurs, il existe une manière plus évoluée pour tester son conteneur EJB à l’aide de JBoss Arquillian et ShrinkWrap. Arquillian se pluggue sous forme de runner Junit et s’occupe de créer le conteneur pour vous. Il permet ainsi d’injecter directement avec @Inject vos beans. ShrinkWrap est un petit utilitaire qui permet quant à lui de créer une archive jar contenant les classes et fichiers ressources du projet. Arquillian à l’aide de l’annotation @Deployment va récupérer cette archive au moment de démarrer le conteneur. 

@RunWith(Arquillian.class)
public class MyEJBTest {
   @Deployment
   public static JavaArchive createDeployment() {
      return ShrinkWrap.create(JavaArchive.class, "test.jar")
         .addClasses(MyEJB.class, AnotherClass.class);
   }
   @Inject
   private MyEJB myEJB;

Les serveurs d’applications ont mis le turbo

Il existe quelques serveurs qui implémentent le Full Profile Java EE 6 et certifiés par Oracle, comme Oracle GlassFish Server 3.x, IBM WebSphere Application Server 8.0, ou encore Apache Geronimo 3.x. Mais grâce au Web Profile, on voit apparaitre de nombreux serveurs Java EE 6 Web Profile, comme: Jboss 7, Apache TomEE, ou encore Caucho Resin.

Prenons par exemple, Apache TomEE, qui n’est autre qu’un serveur Tomcat, auquel on a ajouté quelques jars, comme OpenWebBeans, OpenEJB, OpenJPA et MyFaces pour qu’il soit compatible Java EE 6 Web Profile. Comme le souligne Antonio Goncalves, Java EE expert member, ces serveurs démarrent très rapidement:  La plupart en moins de 4 secondes à comparer avec un simple Tomcat qui démarre en 0,7s. On oubliera WebSphere qui reste encore d’une lenteur accablante avec un démarrage en 48s. La version Full Profile de GlassFish nous rassure avec un démarrage en à peine 3s. On voit bien que Java EE devient de plus en plus rapide, simple à utiliser et s’oriente vers une architecture de plus en plus modulaire. 

Avec CDI, on injecte tout dans tout!

En parallèle de la notion de conteneur léger, l’API Managed Beans 1.0 décrit que toute classe POJO est potentiellement un bean managé par le conteneur. Ce dernier doit lui fournir un certain nombre de services simples, comme la gestion du cycle de vie du bean avec @PostConstruct et @PreDestroy, des interceptors “à la AOP” avec le @Interceptor, et le @AroundInvoke, ou encore de l’injection de dépendances avec @Inject, et @Resource.

CDI 1.0 est une API majeure dans Java EE 6 qui permet entre autre de réaliser l’injection de dépendance et bien plus comme nous le verrons par la suite. L’implémentation de référence est JBoss Weld. Ici, le mot d’ordre est loose coupling, strong typing. Contrairement aux beans Spring, qui sont identifiés par des String, et donc sources d’erreurs au runtime, CDI a choisi la voix du typage fort en utilisant des annotations. Tout managed bean est injectable dans un autre. Bref, maintenant on peut vraiment injecter tout dans tout ! A son chargement le conteneur CDI va scanner tous les jars de son classpath à la recherche d’un fichier beans.xml. Si un fichier est trouvé, il va créer des managed beans pour toutes les classes concernées. Ce type de chargement permet de réduire le temps de création du conteneur CDI et d’exclure facilement les jars que l’on ne veut pas manager. Par défaut, le fichier beans.xml peut rester vide, ce sont alors les annotations, qui seront utilisées. Si vous configurez le fichier, vous pourrez définir ou surcharger les propriétés d’un bean : les informations du fichier xml ayant prédominance par rapport aux annotations.

Les scopes

Tout bean dispose d’un scope. Par défaut, le scope est implicitement annoté @Dependent, ce qui revient à créer une instance du bean pour chaque objet dépendant de lui. D’autres scopes sont proposés: @RequestScoped, @SessionScoped, @ApplicationScoped, ou encore @ConversationScoped. Il est possible de créer ses propres scopes métiers. Il existe également une annotation @New pour forcer l’injection d’une nouvelle instance d’un bean, même si celui-ci a un scope Application par exemple.

@Inject @New Calculator calculator;
@ApplicationScoped
public class Calculator {...}

L’injection avec @Inject

Ainsi, pour injecter un bean, il suffit d’annoter une classe, une propriété, ou un paramètre avec l’annotation @Inject. Les beans sont identifiés de plusieurs manières possibles. La première méthode utilise un @Qualifier. Par défaut, si l’on ne précise rien, c’est le qualifier @Default qui est appliqué.

@Inject
private CustomerDao customerDao;
//Equivalent à:
@Inject @Default
private CustomerDao customerDao;

Identifier un bean avec @Qualifier

Si votre bean a plusieurs implémentations et afin de prévenir des ambiguïtés au niveau d’un point d’injection, vous devrez créer votre propre qualifier. Pour cela, il suffit de créer votre propre annotation avec @Qualifier et d’annoter votre bean avec celle-ci.

@Qualifier
@Retention(RUNTIME)
@Target({FIELD, TYPE, METHOD, PARAMETER})
public @interface JdbcDao {
}
@Qualifier
@Retention(RUNTIME)
@Target({FIELD, TYPE, METHOD, PARAMETER})
public @interface JPADao {
}
@JdbcDao
public class JdbcCustomerDao implements CustomerDao {...}
@JPADao
public class JPACustomerDao implements CustomerDao {...}
//Exemple d'injection avec @Qualifier:
@Inject @JdbcDao
private CustomerDao customerDao;

Identifier un bean via son nom EL avec @Named

Une autre manière d’identifier un bean est d’indiquer son nom EL (Expression Language) via l’annotation @Named. Ce bean sera ainsi accessible depuis vos pages JSF en utilisant une EL. Il est possible de spécifier un nom ou par défaut c’est le nom de classe dont la première lettre passe en minuscule qui est considéré.

@Named
public class Calculator {...}
//Equivalent à :
@Named("calculator")
public class Calculator {...}
//Page JSF:
<h:outputLabel value="#{calculator.someMethod}" />

Définir une implémentation alternative avec @Alternative

Une autre fonctionnalité intéressante proposée dans CDI est de définir une implémentation alternative à un bean. Cette alternative doit être déclarée dans le fichier beans.xml et permet de modifier l’implémentation d’un bean au déploiement. Elle surcharge donc le bean qui aurait dû être injecté initialement.

//MockCustomerDao est une implémentation alternative aux implémentations Jdbc et JPA
@Alternative
@JdbcDao
@JPADao
public class MockCustomerDao implements CustomerDao {...}
//L'implémentation alternative MockCustomerDao sera injectée à la place de JPADao:
@Inject @JPADao
private CustomerDao customerDao;
//Déclaration de l'alternative dans le beans.xml:
<alternatives>
   <class>fr.xebia.cdi.MockCustomerDao</class>
</alternatives>

Personnaliser le rôle d’un bean avec @Stereotype

Les stéréotypes permettent de regrouper au sein d’une même annotation des modèles et des rôles communs que l’on veut implanter sur des beans. CDI fournit quelques stéréotypes de base. Ci-dessous, le stéréotype @Model représente la partie Model du pattern MVC et peut être utilisée pour les beans JSF. On voit par exemple que les beans utilisant ce stéréotype auront tous en commun un nom EL, et un scope request.

@Named
@RequestScoped
@Stereotype
@Target({TYPE, METHOD, FIELD})
@Retention(RUNTIME)
public @interface Model {}

On constate la richesse qu’offre CDI en plus de la simple injection de dépendances. Les qualifiers et stéréotypes permettent notamment de donner du sens métier et fonctionnel aux beans.

CDI offre de nombreux patterns clé en main

Outre l’injection de dépendance, CDI va plus loin en implémentant un certain nombre de patterns de programmation. Là encore, c’est à l’aide d’annotations que la magie opère.

Le pattern Singleton avec @Singleton

Tout d’abord le mythique pattern Singleton, où il suffit d’annoter un bean avec @Singleton. Ainsi, une seule instance du bean est partagée et les accès concurrents sont gérés. Il faut savoir que cette annotation est en fait un pseudo-scope, mais contrairement aux autres scopes, le conteneur injecte une référence directe au bean, et non un proxy.

Le pattern Factory avec @Produces

Cette technique appelée producer method est une méthode permettant de créer des objets injectables. On peut produire des types primitifs, des beans ou encore des ressources telles qu’un entityManager, une connection JMS, etc. Dans l’exemple ci-dessous, notre producer method produit un logger. Pour créer ce logger, il est nécessaire d’indiquer le nom de la classe qui sera loggué. Pour cela, il suffit de passer en paramètre de notre méthode un objet InjectionPoint qui sera injecté par CDI. Cet objet permet de récupérer des informations de contexte, comme la classe où est injecté l’objet Logger.

class LogFactory {
   @Produces Logger createLogger(InjectionPoint injectionPoint) {
       return Logger.getLogger(injectionPoint.getMember().getDeclaringClass().getName());
   }
}
//Injection du logger:
@Inject
private Logger logger;

Les interceptors avec CDI

CDI enrichit l’API Interceptors 1.1 présente dans Java EE 6. Initialement, Interceptors permet de faire de l’interception à la « AOP » sur les managed beans ou les EJB beans. L’intercepteur déclenche alors un traitement avant et après l’invocation d’une méthode. L’annotation @AroundInvoke permet d’exécuter du code au moment de l’interception et @Interceptors indique les méthodes à intercepter. Ainsi, CDI introduit une nouvelle annotation @InterceptorBinding, qui simplifie et offre un couplage lâche avec la classe de l’interceptor.

@InterceptorBinding
@Inherited
@Target( { TYPE, METHOD })
@Retention(RUNTIME)
public @interface Transactional {}
//Intercepteur qui déclare l'annotation précédente, ainsi que @Interceptor
public @Transactional @Interceptor
class TransactionInterceptor { ... }
//On applique l'intercepteur sur le bean via l'annotation.
public @SessionScoped @Transactional
class ShoppingCart implements Serializable { ... }

Le pattern Decorator avec @Decorator

Les décorateurs ressemblent aux intercepteurs. Ils interceptent aussi des appels de méthodes, mais ont en plus accès à la sémantique du bean intercepté. Un décorateur est une classe abstraite (ou non) qui implémente le type du bean qu’il décore et est annoté avec @Decorator.
Le bean du décorateur s’injecte l’objet qu’il décore via les annotations @Inject @Delegate @Any. L’annotation @Delegate indique que ce point d’injection correspond au bean que l’on veut décorer. L’annotation @Any permet d’intercepter tous les beans implémentant l’interface du type décoré. Enfin, le décorateur implémente au choix les méthodes qu’il veut intercepter.

public interface Customer {
   String getName();
   ...
}
@Decorator
public abstract class CustomerDecorator
implements Customer {
   @Inject @Delegate @Any
   Customer customer;
   public String getName() {
      return "decorate"+ customer.getName();
   }
}

Le pattern Observer (ou Event) avec @Observable

CDI offre la possibilité aux beans de produire et de consommer des events. Ce mécanisme permet notamment aux beans d’interagir entre eux via un couplage lâche et asynchrone sans utiliser JMS. Par ailleurs, ce pattern permet de synchroniser et capter les changements d’état de beans stateful. 
Un event est matérialisé par un objet java (event object ou payload) et est marqué d’un ou plusieurs qualifiers (event qualifiers). Les qualifiers permettent de distinguer les events que l’on veut produire ou observer pour un type de bean donné. Techniquement, une méthode observatrice (observer method) aura le rôle de consommer l’event object, correspondant à un ensemble de qualifiers donnés.

//Permet de qualifier l'event
@Qualifier
@Target({FIELD, PARAMETER})
@Retention(RUNTIME)
public @interface Updated {}
//Observer method pour tout type de Customer
public void onAnyCustomerEvent(@Observes Customer customer) { ... }
//Observer method pour les Customer qualifié par @Updated
public void afterCustomerUpdate(@Observes @Updated Customer customer) { ... }
//Producteur d'un event de type Customer qualifié par @Updated
@Inject @Updated Event<Customer> customerEvent;
public void someMethod(Event<Customer> customerEvent) {
   ...
   customerEvent.fire(customer);
}

Les extensions CDI, l’avenir de Java EE ?

De base, les patterns et les fonctionnalités qu’offre CDI sont riches et nombreux. Mais, cela va encore plus loin. Le cœur de CDI a été conçu tel un bus d’événements. Au moment du chargement du conteneur, celui-ci envoie ses informations de contexte (détection d’annotations, de beans, etc.) dans un bus. Il est alors possible de capter ces événements via une SPI, contenu dans le package javax.enterprise.inject.spi. En implémentant cette SPI, il est ainsi possible de capter ces informations et d’effectuer des traitements propres. Cette architecture rend CDI modulaire et permet le développement d’extensions CDI portables.

Les développeurs de Seam 3 ont bien compris l’intérêt des extensions CDI et ont conçu leur framework comme un ensemble d’extensions à CDI. Si vous avez besoin d’une certaine fonctionnalité, il suffit d’ajouter le module concerné. Cela ouvre la voix à l’intégration d’api third-party et permet d’enrichir considérablement la plateforme Java EE,  de la même manière que Spring le fait avec ses modules et ses templates.

Par ailleurs, un projet très ambitieux encore en incubation chez Apache, nommé DeltaSpike a pour but de standardiser un ensemble d’extensions CDI, développé et maintenu par la communauté Java. Et éventuellement, ces extensions pourront être intégrées aux spécifications Java SE et EE. Les premiers contributeurs ont offert les « code base » de JBoss Seam3, Apache MyFaces CODI et CDISource. A terme, JBoss Seam 3 et consorts disparaitront pour laisser DeltaSpike la seule source d’extensions CDI portables et standards. L’avenir de Java EE passera donc aussi par le développement des extensions CDI.

Conclusion

Cet article avait pour vocation de démontrer que la plateforme Java EE 6 est aboutie et apporte des nouveautés majeures. Il n’a pas abordé toutes les spécifications, telles que JPA 2, Bean Validation 1.1 ou encore JSF 2.0.  Comme nous avons pu le voir, cette plateforme a rattrapé son retard par rapport au géant Spring. L’arrivée du Web Profile et des EJB Lite ouvre la voie à des conteneurs légers et testables.

Néanmoins, il y a quelques petites déceptions: par exemple, la gestion de la configuration et celle des profiles sont inexistantes contrairement à spring. On peut aussi regretter que le profile web n’inclue pas JMS, JAX-RS et JAX-WS. Enfin, la réussite de Java EE 6 est sans doute l’API CDI, qui apporte enfin l’injection de dépendances, de la modularité, et même plus avec ses extensions. Le projet Delta Spike qui consiste à devenir le catalogue de référence des extensions CDI est à surveiller de près.

Car oui : JSF 2.0 annonce la couleur et souhaite faire participer la communauté. Dans cet esprit, les speakers nous présentent le topic twitter #jsf2next pour partager autour des évolutions futures de JSF, souhaitées ou non. Ils enchaînent ensuite avec un trombinoscope de toutes les personnes qui se trouvent derrière JSF 2.0 (on reconnaîtra quelques visages au passage) :

L’aspect communautaire sera rappelé tout au long de la session et on sent vraiment que JSF met le paquet pour être apprécié des développeurs. Les speakers insisteront beaucoup sur le tag JSF2.next avec des slides spécifiques pour donner quelques idées internes ou remontées par la communauté pour (déjà) améliorer JSF 2.0.

La présentation fût découpée en 3 parties : Vue, Contrôleur et Modèle (approximativement 1h pour chaque partie), ce qui nous donne ainsi un bon aperçu de tous les changements de chaque couche du MVC. Une session de BOF spéciale JSF 2.0, qui a eu lieu le soir même, apportera quelques précisions sur certaines fonctionnalités non évoquées lors de la conférence.

Vue

Premier rappel côté Vue et déjà quelques tacles à la gorge : JSP avec ses points faibles (dont certains sont assez discutables…) :

• la complexité de développer une librairie,
• l’état stateful des tags qui impose de faire des appels à release sur les objets tags pour les réinitialiser,
• l’obligation d’une phase de compilation lors du premier affichage,
• le mélange de la présentation avec la couche métier
• le fait que JSP soit orienté contenu (et non composant).

Facelets arrive ainsi avec ses XHTML tags, stateless par défaut, des librairies plus simples à développer, du templating et plus de compilation Java. Et, première bonne nouvelle pour les fans de Facelets, la librairie est incluse dans la spécification avec les mêmes fonctionnalités et quelques améliorations. Elle inclura aussi Gracelets (Groovy pour JSF / Facelets).
La présentation se focalise ensuite sur un des points noirs de JSF : la création de composant… Vous savez, les composants pour lesquels il faut coder un UIComponent, un Renderer, tag/tld, le (ugly) faces-config.xml…

La création de composants est simplifiée dans JSF 2.0 : soit en utilisant les annotations et le fichier taglibs.xml (configuration ainsi simplifiée) soit les Composite Components, une des grosses nouveautés de cette version. Nous avons ainsi les tags composite:interface et composite:implementation pour définir le composite et l’implémentation.

Ces composites sont accessibles directement dans la webapp ou dans un JAR, avec la possibilité d’ajouter des listeners et converters, de plugger un resource bundle…

L’Ajax n’est pas en reste avec un composant embarqué dans JSF 2.0 : jsf.ajax.request(), utilisable par le tag <f:ajax> qui peut-être soit nested soit wrapping.

Contrôleur

Comme la plupart des frameworks web du moment (Wicket pour ne citer que lui), JSF 2.0 pourra enfin se targuer de supporter… GET (pas de sarcasme svp ) ! La conséquence directe est que nous allons enfin pouvoir bookmarker nos URLs. Un exemple avant/après :

<h:link outcome="product" value="View">
    <f:param name="id" value="#{product.id}" />
</h:link>
// qui donnera :
<a href="/product.jsf ?id=3">View</a>

Côté événement, le nouveau SystemEvent fonctionne en mode publish/subscribe avec des événements de type PostAddToViewEvent (après la création du composant) et PreRenderViewEvent (avant le rendering du composant).

Une autre partie intéressante est la gestion des ressources dans l’application avec 2 possibilités de récupération selon que la ressource soit présente dans un dossier de la webapp ou dans un JAR :

// Web root
<h:graphicImage name="hello.png" />
// Classpath of myimages.jar
<h:graphicImage name="hello.png" library="myimages" />
<h:graphicImage value="#{resources['myimages:hello.png']}" />

Modèle

Pour la partie modèle, ce sera surtout une présentation des différentes technologies JEE 6 avec leur intégration dans JSF 2.0 : Managed Beans (partie de JSR-316), Contexts and Dependency Injection (JSR-299), Bean-Validation (JSR-303) et JAX-RS (JSR-311).

Outre les fameuses annotations @Inject (CDI) et @Named (EL), la présentation fera la part belle à Bean-Validation avec l’ajout d’une annotation au niveau de notre POJO qui validera côté Data, Business mais surtout, ce qui nous intéresse, Client.

On se retrouve donc avec les exemples suivants qui sont nativement gérés par JSF 2.0 dans nos pages JSF :

public class User {
   ...
   @NotNull @Size(min=3, max=25)
   public String getUsername() {return username;}
   @NotNull @Email
   public String getEmail() {return email;}
}

Il sera toutefois possible, côté JSF, de désactiver certaines validations, soit par paquet soit au cas par cas.

A noter une bonne gestion du null dans un champ (null ou String vide) avec la possibilité de valider ou non le champ si une annotation Bean-Validation est présente ou si le context-param suivant est présent :

<context-param>
   <param-name>javax.faces.VALIDATE_EMPTY_FIELDS</param-name>
   <param-value>true</param- value >
</context-param>

Mais, il est aussi possible de forcer le champ vide à null avec le paramètre assez explicite suivant :

<context-param>
   <param-name>javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL</param-name>
   <param-value>true</param- value >
</context-param>

Dernier point abordé, la validation multiple avec plusieurs approches :

• Avant la construction du modèle avec un test de tous les champs sur un événement PostValidateEvent ;
• Après la construction du modèle avec Bean-Validation (mais un objet a déjà été construit… à vous de vous faire votre idée).

BOF

Au niveau des sujets esquivés en conférence, quid d’un projet comme Spring Web Flow pour la gestion d’un flow de page qui est supporté par Seam mais pas par JSF ? Une des réponses est que le projet est plutôt complexe et mériterait peut-être une spécification plus globale pour définir ce qu’est un flow de page, les événements autour de ce flow… Il n’en reste pas moins que JSF 2.0 supporte parfaitement le mode Stateless mais pour l’instant le Stateful ne l’est pas…

Au niveau des tags ajax embarqués, il devrait être assez simple de brancher un jQuery ou un Script.aculo.us sur JSF 2.0 et profiter d’une expérience Ajax complète. Reste à voir l’intégration avec des Composite Components.

Conclusion

Une présentation très rythmée avec beaucoup de slides (peut-être trop) qui ne laissent donc que très peu de temps pour la prise de note. Dommage car certains sujets, non évoqués dans cet article, auraient aussi mérité leur place. Mais ce n’est que partie remise pour un prochain article !

En tout cas, force est de constater que JSF 2.0 tend vraiment à une simplification d’utilisation, orienté annotation et zero-XML. Des Composite Component simples à écrire, une intégration gracieuse avec Bean-Validation… en bref, beaucoup de bons points !

Dans ce billet, nous allons essayer d’évaluer ce framework en menant une étude comparative entre deux prototypes basés sur le même socle fonctionnel. Un premier prototype en JSF/EJB3/JPA et un deuxième se basant sur le même socle technique mais intégrant Seam. L’étude va porter sur plusieurs critères tel que la maturité de la solution, la pérennité, la complexité de mise en œuvre, le coût de développement etc.

Au programme :

• Présentation de Seam
• Le prototype ContactBook
• La solution JSF/EJB3/JPA
• La solution Seam
• Comparatif des deux solutions
  • Architecture applicative
  • Code technique
  • Délai et facilité de mise en œuvre
  • Solution
• Conclusion

Présentation de Seam

Seam est un framework JEE 5 dont la première version est sortie en décembre 2005. Il se base essentiellement sur les standards EJB3 et JSF pour construire des applications web. L’objectif principal de Seam consiste à éliminer la complexité tant au niveau de l’architecture que de l’interface de programmation (API). Il se base sur les annotations JDK 1.5 et sur l’utilisation des POJO conformément à l’évolution de JAVA EE 5.

Il offre de nombreuses avantages :

• Meilleure Intégration (JSF/EJB3/JPA).
• Nouveaux contextes : conversation, business process et page.
• Gestion automatique des composants de l’application.
• Intégration simple des flux de pages.
• Intégration simple de JBoss JBPM.
• Accès distant simplifié.

Ce framework offre de nombreuses facilités au niveau de la mise en œuvre des applications web, et se présente de plus en plus comme un futur standard. Pour les utilisateurs qui ne sont pas encore prêts à utiliser les EJB, Seam supporte également des classes POJO et des classes Hibernate comme composants.

Nous allons essayer de vérifier la pertinence des éléments avancées par les créateurs de Seam en menant une étude comparative entre deux prototypes, un se basant sur les EJB3 et JSF et un se basant sur le même socle technique mais utilisant Seam comme framework d’intégration des deux technologies.
Pour ceux qui veulent se documenter plus n’hésitez pas à consulter le billet suivant.

Le prototype ContactBook

Le prototype ContactBook est une application web de gestion des contacts. Son périmètre fonctionnel couvre les fonctionnalités essentielles d’une application de gestion. Ces fonctionnalités sont réparties en deux domaines :

• Gestion des utilisateurs.
• Gestion des contacts.

ContactBook est une application web relativement simple. Elle permet à un utilisateur de gérer ses contacts. Chaque utilisateur répond à un profil (nom, prénom, adresse mail et numéro de téléphone). Chaque utilisateur doit s’identifier auprès du système pour utiliser l’application ContactBook.

ContactBook est une application internationale. Un utilisateur doit pouvoir choisir sa langue « de travail ». Un mécanisme de changement de gestion multilingue est donc proposé à l’utilisateur. Deux langues sont proposées : l’anglais et le français. La langue par défaut est le français.

La solution JSF/EJB3/JPA

cette solution se base sur une architecture 3 tiers avec jsf pour la couche présentation, ejb3 pour la couche métier et jpa pour la couche des données.

La couche présentation est constituée d’un ensemble de composants JSF. Les JSF Backing Beans ou les Managed Beans sont utilisés pour faire le lien entre la couche présentation et la couche métier, ils permettent ainsi de récupérer les données saisies par les utilisateurs, les valider et les véhiculer à la couche métier. La couche métier est un ensemble de composants EJB session qui encapsulent le logique métier de l’application. Les EJB entités représentent le modèle des données. Ceux-ci seront directement persistés dans la base de données grâce à l’api de persistance utilisée.

La solution Seam

Cette solution se base sur les mêmes composants que l’architecture précédente mais utilise Seam comme framework d’intégration des différentes frameworks et technologies utilisés dans le projet.

La couche présentation est constituée d’un ensemble de composants JSF. Les EJB session jouent un double rôle puisqu’ils permettent l’échange des données entre la couche présentation et la couche métier, la validation des données, et la gestion des transactions et des sessions des utilisateurs. Les EJB entités représentent le modèle des données. Ceux-ci seront directement persistés dans la base de données grâce à l’api de persistance utilisée.

Comparatif des deux solutions

Architecture applicative

Pour commencer, nous allons mener une comparaison au niveau de l’architecture applicative des deux solutions proposées :

Notation : Faible(1), Moyen(2), Élevé(3), Excellent(4)

Les dépendances introduites dans le code technique par Seam, ainsi que le modèle d’architecture imposé par ce framework rend la réutilisation de ses composants très faible par rapport aux composants sans Seam qui sont réutilisables dans l’état.

Seam couvre la plupart des besoins techniques liés au développement d’une application web, ce qui permet de simplifier le développement avec JEE5. Seam fournit aussi des outils pour faciliter la vie des développeurs. Sans Seam les développeurs doivent prendre en charge tout les problèmes liés à l’intégration des différentes briques JEE5.

Il est plus difficile d’intégrer des composants réutilisables dans une application Seam, car il faut les convertir en composants Seam. Sans Seam nous avons moins de contraintes pour intégrer des composants réutilisables dans l’application.

Seam est un framework complexe qui nécessite un grand cout d’entrée, mais qui permet de résoudre beaucoup de problèmes liés à l’intégration des différents frameworks du marché. Seam nous facilite la tâche en s’intégrant parfaitement avec plusieurs frameworks et implémentations des spécifications JEE5 (EJB3, JSF, Spring, GWT, IceFaces …).

L’architecture de la solution Seam est moins souple que l’architecture de la solution JSF/EJB3/JPA, c’est à la fois un avantage et un inconvénient. Un avantage car il y a moins de problèmes à résoudre lors de l’implémentation de la solution. Un inconvénient car le choix de Seam peut être impactant par la suite. Par exemple il serait difficile de passer de JSF à un autre framework web qui n’est pas pris en charge par Seam, Ce qui freine l’évolutivité à long terme.

Code technique

Pour voir l’apport de l’intégration de Seam sur le code technique, nous avons utilisés le plugin Metrics pour calculer quelques
métriques :

Nous avons constaté que l’intégration de Seam a permis de réduire considérablement la quantité du code technique. Comme il n’y a pas de distinction entre un composant backing bean et un composant Seam. Une page JSF peut donc invoquer directement un composant Seam sans passer par un backing bean ce qui permet de supprimer le code technique des backing beans.

Seam fournit aussi des annotations pour JSF, le cycle de vie des composants, les exceptions, l’asynchronicité, le databinding, l’intégration avec plusieurs apis du monde JEE etc. Ces annotations permettent de produire un code élégant et très compact. Beaucoup prétendent que l’utilisation de Seam ne nécessite pas de configuration XML ce qui est faux, l’intégration des briques et des apis tierces avec Seam nécessitent leurs propres configurations.

Seam est un framework très productif qui permet de réduire considérablement la quantité du code technique nécessaire pour développer une application web mais les dépendances introduites par Seam rend le code technique difficile à maintenir et difficilement réutilisable sans Seam.

Délai et facilité de mise en œuvre

Cette comparaison va nous permettre de comparer les deux prototypes au niveau de la mise en œuvre :

Notation : Très Facile (1), Facile (2), Moyen (3), Difficile (4), Très difficile(5)

La préparation du projet Seam est très simple car nous avons utilisés l’outil seam-gen pour générer la structure du projet avec des exemples de code fonctionnel. Avec Seam, la configuration est fournie dans le projet générée avec seam-gen ce qui n’est pas le cas dans le projet EJB3-JSF. La cohabitation des différentes briques JEE est prise en charge par Seam. Les backing beans n’existent plus, les pages JSF invoquent directement les composants Seam. Sans Seam, il faut coder tout les backing beans et les mapper avec les pages JSF. C’est un cout de développement de plus pour les développeurs. Néanmoins, il ne faut pas oublier que Seam introduit ses propres dépendances dans votre code ce qui le rend moins évolutif et difficilement réutilisable dans d’autres projets qui n’utilisent pas Seam.

Solution

Pour comparer les deux solutions développées, nous allons nous baser sur des critères spécifiques aux frameworks de présentation et des critères généraux :

La solution JSF/EJB3/JPA

La solution Seam

Conclusion

Seam permet d’effondrer les couches artificielles entre la couche présentation et la couche métier. Il permet ainsi de rapprocher les composants métiers de la couche web.

Dans la solution JSF/EJB3/JPA, il est nécessaire d’utiliser des backing beans JSF pour lier la couche présentation à la couche métier. En Seam il n’y a plus de couches d’intégration, mais il faut voir les choses autrement car Seam s’appuie sur une architecture 2 tiers. Lorsque l’on a plusieurs niveaux, il est préférable de les séparer en plusieurs couches pour avoir une meilleure visibilité du code et une séparation des responsabilités. Un autre problème réside dans le fait que Seam introduit une forte dépendance entre les différentes couches de l’application.

Seam a apporté une vraie valeur ajoutée à notre projet JSF/EJB3/JPA et nous a permis de gagner en productivité. Toutefois, le modèle d’architecture imposé par Seam et les dépendances techniques introduites dans nos briques nous laissent à réfléchir, mais il reste une solution très envisageable pour développer des applications entreprises.

Agilité

• Brûlez des Stories, pas des Tâches

RIA

• GraniteDS en version 1.2.0 GA
• Sortie du framework JavaScript JQuery 1.3
• Solution ORM en Javascript : Active Record JS
• Servlet 3.0 : une API innovante et convergente ?

Le coin de la technique

• Sortie de FEST-Swing 1.0
• Intégration Continue avec Maven
• Nouvelle version de RichFaces: la 3.3.0 est sortie
• LiquiBase 1.9 : Des améliorations bien utiles
• Comparatif de performance entre JSF/Seam à Wicket

Agilité

Brûlez des Stories, pas des Tâches

Beaucoup d’équipes Scrum sont habituées à décomposer les User Stories en tâches pour faciliter la répartition du travail dans l’équipe. Mais les problèmes arrivent dès lors qu’elles essaient d’estimer ces tâches (souvent en heures) et de les suivre.
Ron Jeffries suggère de ne pas utiliser de tâches. Il recommande d’utiliser les stories comme unité. Cela suppose que les stories soient suffisamment petites.

Chris Sims rappelle sur InfoQ quelques critères pour définir une bonne user story, que l’on retrouve dans le modèle INVEST (Independant Negotiable Valuable Estimable Small Testable).
Une story peut donc être réalisée par un seul développeur à condition qu’il ait les compétences pour la réaliser de bout en bout. Si votre équipe est spécialisée, vous pouvez y remédier à coup de pair programming.

Kelly Waters souligne que le sprint planning est allégé puisqu’il n’y a plus l’étape de décomposition en tâches.

Ron recommande également de suivre uniquement les stories sur le Burndown chart. Brûler les tâches donne l’impression d’avancer mais potentiellement aucune fonctionnalité ne sera livrable à la fin du sprint. Restez concentrés sur des fonctionnalités livrables, en vous aidant d’une bonne définition de terminé.

RIA

GraniteDS en version 1.2.0 GA

Une nouvelle version de Granite Data Services ou GraniteDS (solution serveur JEE pour le développement et le déploiement des applications Adobe Flex) est sortie avec de nouveaux supports pour :

• TopLink (Intégré dans GlassFish V2, Sun AS et Oracle AS).
• EclipseLink (Implémentation de référence pour JPA 2.0, intégré dans GlassFish V3).
• GlassFish (Un service de sécurité spécifique basé le service de sécurité de Tomcat).

La prochaine version de GraniteDS fournira un support d’OpenJPA et de JPOX/DataNucleus. Elle fournira également un service de sécurité spécifique pour les serveurs d’applications WebLogic. Toutefois avec la prochaine version vous aurez la possibilité de déployer la totalité de vos applications Flex/GraniteDS sur les serveurs d’applications WebLogic.

Pour voir la liste complète des nouveautés, rendez-vous sur le post suivant.

Pour se procurer gratuitement GraniteDs 1.2.0 GA, cela se passe ici.

Sortie du framework JavaScript JQuery 1.3

L’équipe de jQuery, un des frameworks JavaScript le plus en vogue aujourd’hui, annonce la sortie d’une nouvelle version : jQuery 1.3 and the jQuery Foundation.

JQuery est un framework JavaScript extensible. Il permet de manipuler plus simplement et de manière plus portable (d’un navigateur à un autre) le JavaScript. Il apporte une syntaxe élégante et légère pour la manipulation d’un document HTML d’un navigateur (arbre DOM et évènements).

Il apporte de base :

• un modèle d’événement (pression d’une touche du clavier, clic de souris, etc)
• un sélectionneur de noeud dans l’arbre DOM
• des routines pour le développement Ajax
• des routines d’animation graphique

La communauté jQuery est très active et elle développe de nombreux plugins JQuery, de la fonction JavaScript utilitaire au composant graphique riche, comme par exemple :

• routine pour la manipulation de formulaire : Form Plugin
• composant graphique pour la réalisation de graphe : jQuery Google Charting

La version 1.3 met à disposition différentes mises à jours:

• Performances améliorées avec un nouveau moteur de sélection CSS, une nouvelle méthode de ré-injection HTML (cf ci dessous le deuxième exemple), etc.
• Nouveau modèle d’événement : objet JQuery.Event
• Objet jQuery.support pour la détection de fonctionnalités spécifiques (ou de bugs) d’un navigateur.

Voici quelques exemples qui illustrent les capacités de JQuery :

// A la fin de chargement de l'arbre DOM par le navigateur
$(document).ready(function() {
// Attachement d'une fonction lors d'un clique à toutes les ancres
// (balise <a>) qui ont une classe CSS nommée "external"
$("a.external").click(function() {
alert("clic sur une ancre de style external");
});
});

Ainsi avec cet exemple tous les liens avec le style « external » dès qu’ils seront cliqués afficheront un message d’alerte.

Voici un exemple d’appel Ajax :

$.ajax({
type: "GET",
url: 'http://host.com/page.html',
success: function(content) {
// content est un parametre qui contient le code HTML de la page à l'url http://host.com/page.html
$("#content").html(content);
},
error: function() {
logInPage('Erreur de chargement Ajax de la page : http://host.com/page.html');
}
});

Le code $("#content") signifie que l’on sélectionne la balise avec l’identifiant content. La fonction html(« <a href...« ) signifie que l’on met dans la balise le code html en paramètre.

Ainsi si vous avez initialement dans votre page <div id="content">en cours de chargement ...</div>, après l’appel Ajax, le contenu de la page sera <div id="content"><h1>Titre1<h1>...</div> (où <h1>Titre1<h1>... est le contenu de la page à l’url http://host.com/page.html).

JQuery est un excellent framework, notamment grâce à une syntaxe bien pensée, mais qui exige quand même un certain coût d’entrée. Cependant, les exemples à disposition sont nombreux. De quoi réconcilier un certain nombre de développeurs Java avec le développement Web/Javascript.

Solution ORM en Javascript : Active Record JS

La société Aptana annonce la première version de Active Record qui permet d’utiliser une solution de mapping objet/relationnel (ORM) en Javascript en utilisant différents connecteurs :

• En mémoire, pour ne pas utiliser de base de données
• Google Gears (solution de persistance côté client)
• Adobe Air
• SQLite ou MySQL
• Des environnements compatibles HTML 5. Cette nouvelle version de HTML propose une spécification d’API de stockage côté client

Ce framework met en œuvre le pattern du même nom. Le pattern Active Record est un pattern souvent utilisé dans les frameworks Rails comme RubyOnRails, Django (Python) ou Grails (Groovy). C’est une approche pour lire les données d’une DB. Les attributs d’une table ou d’une vue sont encapsulés dans une classe.

Voici quelques opérations élémentaires qui peuvent être réalisées avec ActiveRecord JS :

// Connection en memoire (sans base de donnees)
ActiveRecord.connect(ActiveRecord.Adapters.InMemory);
// Creation du schema
ActiveRecord.execute('CREATE TABLE IF NOT EXISTS users (id INTEGER PRIMARY KEY, ...
// Creation d'une entite
var jessica = User.create({
username: 'Jessica',
password: 'rabbit'
});
// Sauvegarde
jessica.save(); // ou jessica.synchronize()
// Recherche
User.findByUsername('Jessica');

Cependant ce n’est qu’une version béta, quelques problèmes d’implémentation subsistant, en particulier pour Internet Explorer.

Avec un tel framework, le client (navigateur) pourra fonctionner de manière plus détachée du serveur. D’une part, le client gèrera ses données propres indépendamment du serveur. D’autre part le client pourra sauvegarder et restaurer des informations dans le but de se re-synchroniser avec le serveur. Le client pourra gérer plus de traitement sans être lié au serveur, en quelque sorte en mode hors ligne (« offline »).

Pour plus d’informations vous pouvez consulter la page d’Active Record JS

Servlet 3.0 : une API innovante et convergente ?

L’API Servlet 3.0 vient de franchir le Public Review Ballot et nous pouvons aujourd’hui voir l’ampleur des innovations qu’apporte cette version. Les promesses de cette JSR concernaient principalement les applications RIA (introduction d’un mode asynchrone/comet) et l’intégration des frameworks web (accès programmatique à l’enregistrement des servlets et des filtres ou encore à la gestion des login et logout).
Si le manque de maturité des modes asynchrone et Comet pouvait rendre délicat leur standardisation, l’intégration des frameworks web semblait plus aisée étant donnée la longue expérience du monde Java sur ce sujet.

Hélas, on peut douter que Servlet 3.0 améliore réellement l’intégration de frameworks populaires comme SpringMVC, Struts2 ou encore Wicket. Cette pluggability passe d’abord par la possibilité de brancher un conteneur externe (comme Spring Framework ou Google Guice) pour instancier les composants de l’application (y compris les Servlet, les Filter et les ServletContextListener). Servlet 3.0 aurait pu mettre fin au monopole des conteneurs de servlets pour gérer le cycle de vie de ces composants, en introduisant une API de Service Provider Interface, qui permettrait d’utiliser un conteneur externe. Ces SPI sont fréquentes dans les API Java (cf JSF FactoryFinder, JAX-WS Provider, etc) et ont fait leurs preuves dans les frameworks web (Struts2 ObjectFactory, Wicket IWebApplicationFactory, etc).

A la place, Servlet 3.0 introduit un nouveau conteneur d’objets qui, s’il reprend les annotations standard @EJB, @Resource, @PersistenceContext, etc , n’en reste pas moins différent des déjà standards conteneur EJB, conteneur EJB Lite 3.1, conteneur de Managed Bean JSF ou encore du très probable conteneur de Web Beans.

L’enregistrement programmatique des Servlet et Filter (ServletContext#addServlet(...) et ServletContext#addFilter(...)) n’assouplit pas le monopole du conteneur de servlet sur le cycle de vie des Servlet et Filter : on enregistre les composants par leur nom de classe et le conteneur de servlet se charge de les instancier.

Par ailleurs, les annotations Servlet 3.0 (@WebServlet, @ServletFilter, @GET, etc), en plus de ne mutualiser ni le code, ni les concepts équivalents du très récent JAX-RS ( @Path , GET, etc), ont été beaucoup moins ambitieuses puisqu’on ne retrouve pas les QueryParam, PathParam, etc. de JAX-RS, qui existent pourtant depuis bien longtemps dans nos framework Web MVC (cf. Spring MVC @WebParam).

Ces limitations de la pluggability des frameworks web de Servlet 3.0 restreignent les perspectives de standardisation des frameworks web autres que JSF, pourtant si controversé .

En revanche, petit rayon de soleil, le support des modes asynchrone/Comet dans Servlet 3.0 semble satisfaire les projets innovants en la matière même s’ils vont sensiblement plus loin que la nouvelle API startAsync() (cf Grizzly and the New Atmosphere Comet Framework: Q&A with Project Lead Jean-Francois Arcand]).

Le coin de la technique

Sortie de FEST-Swing 1.0

Alex Ruiz nous informe sur son blog de la sortie de FEST-Swing en version 1.0.

Pour rappel FEST-Swing, tout comme UISpec4J, est un outil de test d’interface utilisateur pour une application Swing.

Ses principales caractéristiques sont :

• Support de tous les composants Swing standard (JDK),
• API de création et de maintenance des tests,
• Simulation de toutes les interactions utilisateur (souris, clavier…),
• Supporte les Applets,
• Ajout des captures d’écran des erreurs dans le rapport HTML,
• Utilisable avec JUnit et TestNG.

Une interface utilisateur devient alors aussi simple à tester que :

dialog.comboBox("domain").select("Xebia");
dialog.textBox("username").enterText("rmaton");
dialog.button("login").click();
dialog.optionPane().requireErrorMessage().requireMessage("Please enter your password");

Chaque classe de tests a la possibilité de définir les fonctions setUp et tearDown :

• setUp et tearDown en JUnit 3.8.x
• Toutes méthodes avec @After et @Before pour JUnit 4.x
• Toutes méthodes avec @AfterMethod et @BeforeMethod pour TestNG

On se retrouve avec des tests du type :

import org.testng.annotations.*;
import org.fest.swing.fixture.FrameFixture;
public class FirstGUITest {
private FrameFixure window;
@BeforeMethod
public void setUp() {
window = new FrameFixture(new MyFrame());
window.show(); // shows the frame to test
}
@AfterMethod
public void tearDown() {
window.cleanUp();
}
@Test
public void shouldCopyTextInLabelWhenClickingButton() {
// Your unit tests
}
}

La librairie se télécharge ici ou, pour notre pom adoré, dans ce repository.

Intégration Continue avec Maven

Brian Fox de Sonatype nous livre ses Maven Continuous Integration Best Practices pour faciliter l’Intégration Continue (IC) avec Maven :

• Laisser le server d’IC déployer automatiquement les snapshots pour s’assurer que le repository est synchro avec le système de gestion des sources. Nexus aide en purgeant automatiquement les snaphosts.
• Isoler les repository locaux des différents projets avec -Dmaven.repo.local=xxx pour éviter qu’un artifact buildé par un projet ne soit visible par les autres builds
• Purger régulièrement (tous les soirs) les repository locaux permet de garder l’espace disque sous contrôle
• Activer le mode Batch pour raccourcir les logs (skip les traces de téléchargement des dépendances) avec -B ou dans settings.xml :

false

• Activer les traces complètes -e pour débugger plus facilement
• Rediriger les erreurs des tests sur la sortie standard avec -Dsurefire.useFile=false ou dans settings.xml :

 true 

• Toujours chercher les snapshots avec -U ou dans settings.xml :

always

Nouvelle version de RichFaces: la 3.3.0 est sortie

4 mois après la dernière version (3.2.2), JBoss sort la version 3.3.0 de RichFaces.
Celle-ci a corrigé pas mal de bugs, la liste est disponible sur Jira. Ella a amélioré certains composants ou en a simplifié d’autres. Enfin, le support du navigateur Chrome a été revu et amélioré.

Deux nouveaux composants viennent s’ajouter aux nombreux déjà existants :

• l’éditeur WYSIWYG adapté de TinyMCE accessible par la balise <rich:editor>,
• l’amélioration du traffic Ajax grâce à une file d’attente, en utilisant la balise <a4j:queue>.

L’éditeur ne nécessite pas de code javascript supplémentaire, tout est paramétrable par les propriétés du composant. Et surtout, il est extensible, on peut ajouter ses propres plug-ins.

La file d’attente Ajax est la petite révolution de cette version. Ce qu’on reproche souvent à JSF, c’est de rendre difficile l’utilisation d’Ajax dans le cycle de vie JSF. Ce composant va mettre de l’ordre dans tout ça et ne laisser passer qu’une requête à la fois, les autres sont mises en attente. Il va aussi réduire la charge du serveur en combinant plusieurs requêtes si celles-ci sont similaires. Enfin, plusieurs files d’attente peuvent être définies pour une gestion plus fine des requêtes (Global default queue, View scoped default queue, View scoped named queue, Form-based default queue).

D’autre part, quelques nouvelles fonctionnalités sont venues enrichir plusieurs composants:

• le slider de nombre qui permet de changer une valeur en faisant glisser un curseur sur une ligne (<rich:inputNumberSlider>) peut être positionné verticalement,
• l’évènement « clic droit » (onRowContextMenu) a été ajouté sur les lignes d’un tableau et permet de faire apparaître des informations (<rich:dataTable>),
• l’élément d’un menu (<rich:menuItem>) peut être utilisé seul et ajouté directement dans la toolbar.

Comme toujours avec RichFaces, il est possible de voir à l’oeuvre les composants sur la page de démonstration.

Enfin, le souhait des utilisateurs va se réaliser, la prochaine version de RichFaces a pour objectif d’enrichir les possibilités de positionnement des composants dans une page.

LiquiBase 1.9 : Des améliorations bien utiles

Le mois dernier, un billet sur la refactorisation de base de données avait présenté LiquiBase dans sa version 1.8.1. Nous tenions donc à vous informer de la sortie d’une nouvelle version qui confirme la forte activité autour de cet outil.

Sans surprise, cette version 1.9.0 corrige son lot de bugs et améliore la validation dans le schéma XSD.

La fonctionnalité majeure de cette nouvelle release se trouve dans la balise <modifySQL>. Elle offre un mécanisme de modification du code SQL après génération par les balises standards. Cela permet d’ajouter des informations spécifiques à la base de données utilisée, comme « engine innodb » pour une base MySQL.
Là où, avant, on devait passer par du code SQL custom (<sql>), on va pouvoir rester sur les balises existantes et les modifier à notre guise.

D’autre part, une nouvelle balise (<stop>) permet, en développement, d’arrêter le traitement du fichier et d’aller regarder dans la base de données pour voir si tout se passe comme il faut.

Enfin, dans les versions précédentes, pour inclure d’autres fichiers, il fallait les énumérer un par un, à présent, il suffit d’indiquer un répertoire avec la balise <includeAll>. Il faut toutefois être prudent car l’ordre des fichiers est important et cette balise parcours la liste dans l’ordre alphabétique, une politique précise de nommage s’impose.

Pour rassurer certains qui penseraient qu’il vaut mieux attendre la version 2.0 qui sort généralement après la version 1.9, le responsable du projet LiquiBase précise que la version majeure n’est pas prévue dans l’immédiat et que les prochaines versions seraient 1.10, 1.11, etc.

Donc n’ayez crainte et allez-y.

Comparatif de performance entre JSF/Seam à Wicket

Peter Thomas nous propose dans son article Seam / JSF vs Wicket: performance comparison, un comparatif de performance entre une solution Seam/JSF et Wicket.

Il y a deux éléments intéressants dans cet article :

• Le resultat de l’étude : Wicket semble plus performant que Seam/JSF

En effet, Wicket a une empreinte moins grande que Seam/JSF :

• Wicket consomme moins de mémoire JVM
• Wicket charge moins de classes
• Wicket démarre plus rapidement. Le temps de démarrage n’est pas un critère primordial mais il est représentatif des performances globales et impacte le développement
• Wicket a de meilleurs temps de réponse sur les différents scénarii

• La méthode de test de performance.

Ce n’est pas une méthode formelle qui garantit le résultat de manière scientifique mais cela donne une tendance.
Les outils utilisés sont :

• Ant pour le scripting du benchmark
• JMeter pour réaliser les mesures de temps de réponses en injectant une charge
• Eclipse Memory Analyzer pour réaliser les mesures d’empreinte mémoire de la JVM

Le travail effectué peut être facilement étendu à d’autres frameworks. Il est en outre possible de réutiliser une partie des scripts du projet Google Code PerfBench.

La revue de presse de l’actualité Java/J2EE hebdomadaire proposé par Xebia.

Le coin de la technique

• Sonar en version 1.5
• Version finale de Tapestry 5
• Première implémentation de la JSR 299 : Web Beans RI 1.0.0.ALPHA1

Evènements de notre communauté en France et à l’étranger

• JavaLobby fait une restrospective des articles les plus lus en 2008

Le coin de la technique

Sonar en version 1.5

SonarSource (spin off de la société Hortis dédiée au développement et au support de Sonar) a annoncé la sortie de la nouvelle version de Sonar.
Comme déjà présenté plus en détail sur ce blog, Sonar est un outil open source qui collecte, consolide et présente les données Qualité d’un projet.
Dans les nouvelles fonctionnalités, il est à noter une volonté d’ouverture de l’API :

• Récupération des mesures à partir de services REST.
• Possibilité d’écrire ses propres extensions via des plugins de collecte (voir le tutorial ici).

Des présentations graphiques des métriques et de l’évolution dans le temps ont été ajoutés :

• Suivi des règles sous forme de radar.
• Couverture de code présenté en nuages de classe.
• Amélioration de l’affichage des graphiques d’évolution du respects des règles (Time machine).

L’intégration avec les outils open source utilisés lors des collectes est aussi améliorée :

• Ajout des règles Findbugs portant à 600 le nombre de règles de codes contrôlables (de la simple règle de nommage à l’anti-pattern).
• Mise à jour des versions des plugins PMD et Clover.

La release s’accompagne aussi de son lot de corrections de bugs.
Pour plus de détails, voir la release note complète.

Sonar, avec cette nouvelle version, se positionne encore plus comme un incontournable dans la présentation de données liées à la qualité, loin devant le dashboard Maven.
De plus, la roadmap présentée sur le site de Sonar propose des fonctionnalités intéressantes comme le regroupement de projets, le positionnement d’alerte sur indicateurs ou encore l’association de règles différentes selon les projets …

Version finale de Tapestry 5

Comme nous l’a fait remarquer un de nos lecteurs, François Armand, Tapestry 5.0 est actuellement disponible en version finale.

Tapestry 5 a nécessité près de 3 ans de développement afin d’avoir les améliorations suivantes (par rapport à la version 4) :

• Amélioration du modèle de programmation de Tapestry afin de pouvoir développer des composants « Tapestry » sous forme de classe POJO
• Moins de configuration par XML, et plus de conventions de nommage (principe de CoC, Convention over Configuration), utilisation des nouveautés du langage Java 5 (annotation)
• Amélioration de la productivité des développements avec la recharge à chaud des classes Java en cours de développement.

Le rechargement à chaud de classe permet de ne plus avoir un cycle de développement suivant :

• Modification.
• Compilation de l’application.
• Packaging de l’application.
• Déploiement de l’application.
• Démarrage de l’application.
• Test de l’application.

Le cycle de développement suivant permet d’être plus productif car beaucoup plus court que le précédent :

• Modification d’une classe.
• Compilation de la classe.
• Rechargement de la classe dans le Classloader de l’application sans le redemarrage de l’application.
• Test de l’application.

Pour plus d’informations sur l’intérêt d’un cycle de développement allégé, je vous invite à découvrir ou redécouvrir l’article à propos de JavaRebel.

Je vous propose aussi à lire le commentaire de François sur notre blog, qui fait un tour d’horizon et un retour d’expérience sur Tapestry. Encore une fois, merci François.

Matt Raible (Raible Design) avec l’aide de Serge Eby, ont mis à jour AppFuse afin d’intégrer Tapestry 5. Ils notent d’ailleurs ce qu’ils apprécient dans Tapestry 5 : la configuration, qui est minimale, ainsi que les URLs claires. Pour plus d’informations sur AppFuse, voici une présentation du plugin : AppFuse par l’exemple.

Première implémentation de la JSR 299 : Web Beans RI 1.0.0.ALPHA1

A plusieurs reprises dans cette revue de presse, nous avons parlé de la spécification JSR 299, baptisée WebBeans :

• JSR-299 : Web Beans disponible en Public Review Draft.
• Seam 3 : les futures orientations de Seam.

Sur la page consacrée à WebBeans sur le site de Seam Framework, une release de WebBeans est maintenant disponible : Web Beans 1.0.0.ALPHA1 released!.

Pour être plus précis sur l’avenir conjoint de Seam et WebBeans : Seam ne va pas devenir WebBeans. Il y aura un noyau WebBeans, et Seam utilisera ce noyau.

Le noyau WebBeans prend en charge le contexte de gestion de composants « WebBeans » ainsi que les mécanismes d’injection de dépendance.

Ainsi Seam embarquera ces propres fonctionnalités :

• Seam Security.
• Rendu PDF / mail.
• Intégration de moteur de workflow (JBPM).
• etc …

Cette release est une première étape importante afin d’achever cette spécification JSR 299 avec une implémentation et sa documentation.
Cette première release vous permettra peut être d’avoir les idées plus claires sur cette spécification.

Evènements de notre communauté en France et à l’étranger

JavaLobby fait une restrospective des articles les plus lus en 2008

JavaLobby fait le bilan de l’année 2008 en nous montrant les 10 articles les plus lus ces 12 derniers mois. En tête, l’interview de John de Goes président de N-BRAIN qui avoue que les produits open source deviennent de redoutables concurrents et annonce le passage en open source de leur plateforme UNA.
Rick Hightower dont l’un des articles fait partie du top 10 nous fait remarquer dans un commentaire la répartition des résultats en fonction des frameworks.
Voici le résultat :

• deux articles sur JSF dans le top 5 montrent que JSF a toujours le vent en poupe. L’un de ces articles parle d’ailleurs de l’interfaçage JSF/Flex.
• deux articles sur JPA/Hibernate
• un article sur Spring.

Rick Hightower nous précise aussi que les résultats ne prennent pas en compte l’âge des articles. En effet la majorité de ces articles a été publiée avant le mois de Mai.
Globalement, il est intéressant de voir que les frameworks tels JSF et JPA sont toujours aussi populaires et qu’ils intéressent toujours autant les lecteurs.

Le scaffolding fait le bonheur des rubyistes en leur permettant, au prix de l’exécution de quelques lignes de commandes, de disposer d’une application web opérationnelle, autorisant la manipulation élémentaire des données de leur modèle au travers d’écrans de saisie et de listes – charge au développeur d’enrichir ensuite le code généré pour implémenter un comportement plus sophistiqué.

Le projet AppFuse, aujourd’hui dans sa version 2.0, s’appuie sur les archétypes Maven 2 pour offrir aux développeurs Java des fonctionnalités équivalentes. Dans cet article, nous vous proposons une introduction par l’exemple à AppFuse.

Maven : rappels

Pour ceux qui ne sont pas encore familiers avec Maven, voici quelques rappels de base pour pouvoir suivre cet article.

Maven est un outil open-source de build pour les projets Java. Il a été conçu pour simplifier les tâches difficiles du processus de build. Maven offre la possibilité de démarrer un projet en utilisant des squelettes d’application. Ces squelettes, dans la terminologie Maven, sont appelés « archétypes ». Grâce à eux, une ligne de commande permet de démarrer avec une hiérarchie de répertoire standardisée (sources, resources, builds).

Tous les archétypes Maven comportent un fichier « pom.xml » contenant toutes les directives de construction du projet, ses dépendances et différents plugins accessibles. Les plugins Maven couvrent, entre autres, des outils d’analyse de code, de formatage et de génération de rapport.

Pour plus d’informations sur ces notions, je vous conseille de jeter un oeil sur les sites suivants :

• Maven : http://maven.apache.org/
• Plugin d’intégration Maven/Eclipse : http://m2eclipse.codehaus.org/
• Mojo Project (plugins Maven) : http://mojo.codehaus.org/

AppFuse

Concept

Initialement créé par Matt Raible, AppFuse est un projet open source pour développer des applications web J2EE. Il permet aux développeurs de démarrer rapidement et facilement en utilisant des technologies open-source telles que Spring, Hibernate et différents frameworks web (Struts2, Spring MVC, Tapestry, …).

AppFuse est un ensemble de scripts de génération de code permettant de faire le travail le plus pénible très rapidement, typiquement les écrans CRUD (Create, Read, Update, Delete) de votre modèle de données.

Utilisation

Initialement conçu avec Ant, Appfuse s’appuie, depuis sa version 2, sur Maven via des archétypes et des plugins de génération de code.

Archétypes Maven

Les différents archétypes fournis par le projet AppFuse couvrent différents frameworks Web, couplés avec Hibernate et Spring :

• JSF
• Struts2
• Spring MVC
• Tapestry

AppFuse propose pour tous ces outils de généré un projet d’application simple ou un projet multi-modules contenant un projet noyau et des projets modulaires. Il est également possible de générer uniquement le backend d’application. Vous pourrez brancher dessus votre framework préféré.

Chaque archétype AppFuse crée une application complète comprenant :

• la gestion de la sécurité
• une interface d’administration des utilisateurs et des rôles.
• plusieurs thèmes CSS
• la création automatique de la base de données
• la population automatique de la base avec un jeu de données de test.

Plugins de génération de code

Une fois votre projet démarré avec l’archétype de votre choix, vous pourrez ajouter vos beans de données et les mapping Hibernate associés selon la méthode que vous préférez (annotations ou fichiers hbm.xml).

Une fois votre modèle posé, le plugin Maven « appfuse:gen » s’occupera pour vous de créer les classes de DAO, Managers et vues correspondantes pour obtenir les écrans de gestion élémentaires (CRUD).
Chaque lancement du plugin se fait sur une classe du modèle de données et fournit :

• une vue avec un tableau triable contenant l’ensemble des instances persistées en base
• un formulaire de saisie/suppression
• un jeu de données pour les tests
• les DAO et Managers associés

Conformément aux principes du scaffolding, la génération de code et de configuration possède ses limites et il est souvent nécessaire d’effectuer quelques corrections manuelles lorsque le modèle de données est un peu évolué.

Par exemple, dans le cas de relations ManyToOne, le formulaire de saisie d’un bean doit comporter une liste permettant de sélectionner avec quel objets faire le lien. Ce cas nécessite de faire des modifications dans l’Action Struts pour que la liste s’affiche effectivement dans le formulaire web. Nous allons voir ce genre de manipulation dans la partie pratique.

Hands-on : Hibernate, Spring, Struts2

Un bon exemple valant souvent mieux qu’un long discours, nous vous proposons de créer pas à pas une application web simple, permettant de saisir des constructeurs automobiles et des voitures liées à ces constructeurs.

L’environnement technique est le suivant :

• Struts 2
• Java 5
• Maven (>= 2.0.6 mais 2.0.9 est plus sûr pour les corrections sur les classpaths )
• accès au web depuis le poste de développement

Démarrage du projet

Création de notre squelette de projet avec l’archétype appfuse-basic-struts :

mvn archetype:create -DarchetypeGroupId=org.appfuse.archetypes
-DarchetypeArtifactId=appfuse-basic-struts
-DremoteRepositories=http://static.appfuse.org/releases
-DarchetypeVersion=2.0.1
-DgroupId=fr.xebia.blog.voiture -DartifactId=voiture-app

Un répertoire « voiture-app » contenant notre squelette applicatif vient d’apparaître. Les amateurs d’Eclipse pourront ajouter :

cd voiture-app
mvn eclipse:eclipse

… pour que Maven créé les fichiers indispensables à Eclipse pour importer le projet.

Les archétype AppFuse placent la majeure partie du code de l’application en dépendances dans le pom.xml.
Pour pouvoir modifier le comportement de l’application et avoir tout sous les yeux, nous devons couper ces dépendances avec AppFuse et rapatrier le code.

Cela se fait très simplement en lançant :

mvn appfuse:full-source

Écriture du modèle

Ajoutons maintenant notre modèle de données. Pour plus de simplicité, nous allons y intégrer directement les annotations utiles à la persistance. Les classes que l’on souhaite passer au générateur de code doivent se trouver directement dans le package « model » du projet. Dans notre cas il s’agit de « fr.xebia.blog.voiture.model ».

Classe : ConstructeurAutomobile

src/main/java/fr/xebia/blog/voiture/model/ConstructeurAutomobile.java

package fr.xebia.blog.voiture.model;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
@Entity
public class ConstructeurAutomobile {
  private Long id;
  private String nom;
  @Id
  @GeneratedValue(strategy=GenerationType.IDENTITY)
  public Long getId() {
    return id;
  }
  public void setId(Long id) {
    this.id = id;
  }
  @Column(length=50)
  public String getNom() {
    return nom;
  }
  public void setNom(String nom) {
    this.nom = nom;
  }
}

Classe : Voiture

src/main/java/fr/xebia/blog/voiture/model/Voiture.java

package fr.xebia.blog.voiture.model;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.JoinColumn;
import javax.persistence.ManyToOne;
@Entity
public class Voiture {
  private Long id;
  private String nom;
  private ConstructeurAutomobile constructeur;
  @Id
  @GeneratedValue(strategy=GenerationType.IDENTITY)
  public Long getId() {
    return id;
  }
  public void setId(Long id) {
    this.id = id;
  }
  @Column(length=50)
  public String getNom() {
    return nom;
  }
  public void setNom(String nom) {
    this.nom = nom;
  }
  @ManyToOne
  @JoinColumn(name="constructeur_id")
  public ConstructeurAutomobile getConstructeur() {
    return constructeur;
  }
  public void setConstructeur(ConstructeurAutomobile constructeur) {
    this.constructeur = constructeur;
  }
}

Génération des CRUD

Maintenant que nous disposons des classes, nous pouvons lancer la génération des écrans CRUD :

mvn appfuse:gen -Dentity=ConstructeurAutomobile
mvn appfuse:gen -Dentity=Voiture

N.B. : Si vous omettez l’option -Dentity le nom de la classe ciblée est demandé en prompt.

Le générateur de code comporte cependant une lacune. Les classes sont bien ajoutées aux mappings Hibernate, mais pas pour les tests unitaires. Par conséquent, un mvn test tombera en erreur.

Le palliatif à cela est de copier les lignes de mapping dans :

src/main/resources/hibernate.cfg.xml

<hibernate-configuration>
    <session-factory>
        <mapping class="fr.xebia.blog.model.User"/>
        <mapping class="fr.xebia.blog.model.Role"/>
<!-- Les deux lignes suivantes nous intéressent -->
        <mapping class="fr.xebia.blog.voiture.model.ConstructeurAutomobile"/>
        <mapping class="fr.xebia.blog.voiture.model.Voiture"/>
<!-- Stop, pas plus loin, deux lignes seulement -->
    </session-factory>
</hibernate-configuration>

et de les coller dans le fichier src/test/resources/hibernate.cfg.xml pour garder ces deux fichiers en phase.

Vous pouvez le vérifier par vous même en lançant :

mvn clean test -P hsqldb

{quote}
Plusieurs profils de base de données sont disponibles dans le pom.xml fourni par AppFuse (MySQL, PostgreSQL, Oracle, etc). Par souci de simplicité nous utilisons ici HSQLDB.
{quote}

Support du lien ManyToOne

Le générateur AppFuse, bien que pratique, n’est pas omnipotent. Nous avons donc quelques manipulations à réaliser manuellement pour que le formulaire de saisie d’une Voiture soit complet.

Dans le fichier src/main/webapp/WEB-INF/pages/voitureForm.jsp vous pouvez voir cette ligne :

<s:select name="voiture.constructeur.id" list="constructeurList" listKey="id" listValue="id"></s:select>

Il s’agit du tag Struts qui affiche la liste de sélection des constructeurs. Cependant, la classe VoitureAction, générée, ne fournit pas cette liste à la JSP, qui restera en conséquence désespérément vide à l’exécution. Notons également que par défaut, AppFuse affiche l’identifiant de l’entité dans la liste – ce qui ne correspond qu’exceptionnellement au besoin. Remplaçons la valeur de l’attribut listValue du tag select par « nom ». Ainsi, le nom du constructeur sera présenté dans la liste de sélection, plutôt que son identifiant.

Attaquons-nous au support de cette fameuse liste. Nous allons rajouter ceci au fichier :

src/main/java/fr/xebia/blog/voiture/webapp/action/VoitureAction.java

[...]
import fr.xebia.blog.voiture.model.ConstructeurAutomobile;
[...]
  private GenericManager constructeurAutomobileManager;
  public void setConstructeurAutomobileManager(GenericManager constructeurAutomobileManager) {
    this.constructeurAutomobileManager = constructeurAutomobileManager;
  }
  public List getConstructeurList () {
    return (List) constructeurAutomobileManager.getAll();
  }
[...]

Comme l’attribut que nous rajoutons respecte les conventions de nommage et que la configuration Spring générée par AppFuse est correcte, l’injection de dépendances se fait automatiquement pour le constructeur AutomobileManager.

La méthode getConstructeurList, quant à elle, sera appelée par la JSP pour obtenir le contenu de la liste de sélection.

Démarrage

Nous pouvons maintenant effectuer un premier lancement de notre application grâce au plugin Jetty de Maven. :

mvn jetty:run-war -P hsqldb

Je vous laisse faire le tour du propriétaire en allant avec votre navigateur web sur localhost:8080 pour vous mettre l’eau à la bouche, voici une liste non exhaustive de tout ce que nous avons obtenu en une demi-heure de travail :

• filtres de sécurité
• gestion des utilisateurs en base
• envois de mail en cas d’oubli d’un mot de passe ou de création de compte
• écrans CRUD pour les constructeurs automobiles
• écrans CRUD pour les voitures
• un jeu de données inséré à chaque lancement des tests
• export des listes de constructeurs et de voitures en CSV, XLS, PDF ou XML (Merci à DisplayTag)
• une CSS propre (ça fait toujours plaisir)
• une foule de plugins très utiles placés dans le pom.xml : Cobertura, PMD, DBunit et d’autres
• le support de l’internationalisation

Et j’en oublie.

Conclusions

AppFuse est, à mon avis, un excellent plugin Maven pour démarrer un projet d’application Web classique. Il n’est pas très polyvalent mais permet de se libérer d’une part assez fastidieuse du développement web : l’écriture des CRUD.

Le squelette d’application standardisé permet de s’y retrouver rapidement quand on gère plusieurs applications et de respecter un bon découpage des fichiers de configuration.

En fait ce plugin en fournit presque trop : trois semaines après je trouvais encore des morceaux de code inutilisés provenant du squelette, et qui m’ont facilité la vie, notamment pour l’exposition de WebServices grâce à XFire.

À mon avis un très bon outil, bien ciblé, à essayer.

Quelques ressources complémentaires :

• Seven simple reasons to use AppFuse par Matt Raible
• AppFuse QuickStart

Agilité

• Agile 2008 : La sagesse des foules

RIA

• FXStruts
• Interopérabilité Java – Silverlight
• HTML immobilisé par les tergiversations … pendant que les RIA progressent

Le coin de la technique

• Les nouveautés de Seam 2.1

Evènements de notre communauté en France et à l’étranger

• JSF One – Septembre 2008

Agilité

Agile 2008 : La sagesse des foules

La conférence Agile 2008 qui se déroulait à Toronto s’est terminée vendredi dernier. Avec près de 1600 participants et 400 présentations c’était la plus grande (trop grande ?) conférence Agile jamais organisée. Les retours sur le niveau des présentations semblent plutôt positifs bien que la qualité des sessions était inégale, certaines déceptions venant parfois des stars.

La conférence a débuté avec un très bon discours de James Surowiecki, auteur du livre The Wisdom of Crowds (La sagesse des foules). InfoQ revient sur la thèse de ce livre : « une décision prise par un groupe de personnes est souvent meilleure que la meilleure décision de n’importe quelle personne du groupe« . Cette affirmation est toutefois soumise à quelques contraintes : un groupe sage est un groupe diversifié, où chaque membre prend une décision de façon indépendante, et qui sait agréger l’ensemble des décisions individuelles pour obtenir une décision collective.

Robert C. Martin – surnommé l’oncle Bob – a donné un discours intitulé Quintessence dans lequel il propose d’ajouter un cinquième élément au Manifeste Agile : il appelle les développeurs à se laver les mains, c’est-à-dire à écrire du code propre, à ne pas faire de compromis sur la qualité.
Il tire aussi une caricature des 2 méthodes Scrum et XP en les comparant à Obama et Mc Cain : Scrum à cause de son idéalisme et de ses certifications, et XP car la méthode est trop stricte. Il rappelle que la conférence Agile 2008 est une fusion de deux anciennes conférences respectivement sur Scrum et XP, ce qui confirme le fait que les 2 méthodes ont fusionné en un seul ensemble de pratiques agiles.

Alan Cooper a clôturé la conférence avec sa présentation The Wisdom of experience. Il en a profité pour rappeler que sa conviction pour l’interêt de la conception détaillée par écrit ne fait pas de lui un adhérent à la méthode Waterfall.

Voici quelques blogs parlant d’Agile 2008, dont certains sont cités précédemment. En français :

• Alexandre Boutin
• Valtech

En anglais :

• Gojko Adzic
• Kent McDonald
• Mishkin Berteig
• Klinton Keith
• Lisa Crispin
• Tom Perry

Rendez-vous l’année prochaine à Chicago.

RIA

FXStruts

Cet article nous présente un nouvelle librairie open source: FXStruts. Cette dernière, développée, par Anirudh Sasikumar permet d’intégrer Flex dans la partie Vue de Struts. Le principe est assez simple: cette librairie fonctionne sur le même principe du tag bean:write dont l’output sera de l’AMF ou du XML. Pour cela, deux tags sont disponibles :

• fx:write équivalent au tag bean:message.
• fx:message équivalent au tag bean:write.

Le code source est accessible sur le repository de google et des aides à la migration d’applications Struts en Flex sont données.
Pour le moment, l’inconvénient majeur de cette libraire est qu’elle n’a été testée que pour la version 1.3.8 de Struts.
Ce projet témoigne encore de l’engouement pour les technologies RIA et plus particulièrement de Flex. A quand un FXStruts pour Struts 2 ?

Interopérabilité Java – Silverlight

Derrière le leader des RIA Flex, Microsoft s’accroche et tente d’imposer son RIA Silverlight.
En attendant la sortie de la version 2 et un billet plus complet sur ce blog, InfoQ présente un tutoriel pour interfacer Silverlight avec des Webservices Java (SOAP, REST et RSS).

Nous retiendrons les conclusions de cet exercice :

• Les technologies de communication de prédilection de Silverlight pour accéder à des backends Java sont SOAP, REST (aka XML sur HTTP) et RSS
• SOAP pose les classiques problèmes d’interopérabilité entre les mondes .Net et Java. Silverlight n’offre pour le moment que le support de WS-I Basic Profile (WS-I Basic Security Profile, n’est pas encore disponible).
• Le support de REST manque de maturité. La documentation est obsolète voire erronée. Les implémentations RESTful qui utilisent simplement HTTP POST ou GET (plutôt que PUT et DELETE) sont celles qui fonctionnent le mieux avec Silverlight.
• Si SOAP est un bon choix pour les accès en écriture, REST est en revanche plus simple à utiliser pour les accès en lecture.
• L’accès à des flux RSS est facile à mettre en place.
• Un des concepts fondamentaux à retenir est que Silverlight s’exécute dans un browser. C’est pourquoi il possède tous les problèmes inhérents aux composants ‘embarqués’ dans le navigateur : les problèmes de cross domaines, les limitations sur le nombre de connexions au navigateur, le support des différents types MIME, etc. Ces problématiques doivent être abordées durant le développement.

A noter, les références vers des objets JAXB devraient être supportées dans Silverlight 2 RTM de la même manière qu’elles le sont dans .NET Framework 3.5 SP1 (DataContractSerializer).

HTML immobilisé par les tergiversations … pendant que les RIA progressent

InfoQ revient sur les tergiversations autour des évolutions de HTML dans XHTML 2 and HTML 5 continue to diverge.
Pour mémoire,

• XHTML V2 est issu du W3C. Dans la veine du toujours confidentiel Web Sémantique soutenu par le W3C, l’objectif principal de XHTML V2 est de renforcer la séparation entre le contenu et la présentation.
• HTML V5 est une proposition du Web Hypertext Application Technology Working Group (principalement Google, Apple, Mozilla et Microsoft) suite à un désaccord avec la direction prise par XHTML V2. HTML V5 se veut plus pragmatique et met l’emphase sur la dimension Rich Internet Application (interactions browser-serveur, édition de documents, drag&drop, etc).

Pendant ces hésitations, les éditeurs de RIA continuent à ajouter des fonctionnalités à leurs environnements graphiques et Adobe va même jusqu’à évoquer des applications web widget-centric qui ne passeraient même plus par des browsers mais directemment des liens sur le bureau du système d’exploitation.

Plus de détails dans XHTML 2 vs. HTML 5 par Vinny Carpenter.

Le coin de la technique

Les nouveautés de Seam 2.1

Peter Muir, JBoss, présente dans DZone : What’s New in Seam 2.1 – An interview with Peter Muir les nouveautés de Seam 2.1.

Pour rappel, Seam est un framework permettant le développement d’applications web d’entreprise. Seam intègre des technologies Java EE 5 comme JSF, EJB 3, JPA. Il fournit également un ensemble d’API et d’annotations afin de faciliter le développement avec ces technologies. Seam tente de prendre les meilleures idées de chacune des technologies pour que le développeur ait à faire le moins de couture¹ possible, c’est à dire du développement purement technique pour intégrer les différentes couches de l’application.

Seam pose les bases des GWT et Wicket dans Seam 2.1. Le support GWT permettra à Seam de déléguer son rendu à celui-ci alors que le support de Wicket est plus complet. Wicket pourra directement utiliser des composants et des conversations Seam. Côté RIA, l’intégration de Flex est également à l’étude.

Les principaux changements que l’on peut attendre de Seam 2.1 sont :

• Les performances
• La sécurité : gestion de l’identité, gestion des habilitations sur les écrans, les workflows, …
• Amélioration du support REST : intégration de JAX-RS, JSR 311 et de RESTeasy, implémenté par un autre JBoss-ien : Bill Burke.

Web Beans est une spécification Java EE. Cette spécification se base sur Seam mais aussi Guice, le framework d’injection de dépendance de Google.

Voici quelques problématiques couvertes par Web Beans :

• Gestion des conversations
• Injection des dépendances
• Création de composants et la gestion de leurs cycles de vie
• Intégration de transactions
• Intégration de JPA
• Mécanismes de validation (Formulaire, métier, donnée, …)

La version 3 de Seam est actuellement en bêta. On peut espérer une sortie courant 2009. Cette version proposera un nouveau modèle de composant, à suivre …

¹ Seam signifie en français couture

Evènements de notre communauté en France et à l’étranger

JSF One – Septembre 2008

Du 4 au 6 septembre 2008 se tiendra une série de conférences autour de JSF : JSF One.

Les principaux sujets abordés seront :

• JSF 2.0 (JSR 314) (sera embarqué dans Java EE 6)
• Facelets
• Spring Integration
• Seam
• Développement Portlet
• Test
• Sripting JSF
• Développement de composant
• Suite de composant comme RichFaces (JBoss), ICEfaces, …
• Intégration des API Google

Les principaux acteurs du marché seront représentés : Sun, Spring, JBoss, etc. Voici le détail du programme et des intervenants.

Actualité éditeurs / SSII

• Aqualogic Service Bus 3.0 (BEA)
• Spring Source arrive en France

Agilité

• Les bons programmeurs en ont (de bons tests unitaires)
• Progression des méthodes Agiles ?

SOA

• 2008, annus horribilis de la SOA ?

Le coin de la technique

• Java EE 6 : les profiles se dévoilent
• Load balancing avec Tomcat et Apache
• Tests unitaires : Mockito
• JSF, répétition de la mésaventure des EJB 2 ?

Actualité éditeurs / SSII

Aqualogic Service Bus 3.0 (BEA)

Aqualogic Service Bus 3.0 (ALSB 3.0 pour les intimes) est maintenant disponible en téléchargement. La liste des fonctionnalités majeures de cette nouvelle version a déjà été abordée lors d’une précédente revue de presse. On peut y ajouter une meilleure intégration avec la gamme Aqualogic (ALRR, le repository,ALBMP, le moteur de processus et ALSM, le moniteur SOA) et une fonctionnalité de _Throttling, un service qui permet d’éviter d’entrainer une surcharge vers les services métiers accédés.

La distribution comprend WebLogic Server 10, la surcouche ESB et BEA Workshop 10.2 l’IDE basé sur Eclipse pour le développement (Eclipse 3.2.2, Eclipse WTP 1.5.4,…)

• La documentation
• La Release Note

Spring Source arrive en France

Nous apprenons via cet article que SpringSource (anciennement Interface21) allait ouvrir une filiale en France. Un des premiers avantages est la prochaine disponibilité de formations Spring en français.

Il est déjà possible de s’inscrire sur le site de SpringSource, à cette adresse.

Agilité

Les bons programmeurs en ont (de bons tests unitaires)

Dans Real programmers avec GUTs, Vikas Hazrati et Deborah Hartmann commentent le débat qui a eu lieu sur InfoQ mi-février entre Jim Coplien et Bob Martin sur le sujet TDD (Test Driven Development), CDD (Contract Driven Development) et professionnalisme des développeurs.
Vikas et Deborah nous rappelle, qu’étrangement, l’idée d’avoir obligatoirement à utiliser la méthode TDD pour avoir de bons tests unitaires semble répandue. Or, l’important, c’est d’avoir de bons tests unitaires, et ce qu’ils soient développés avant ou après le code.

Pour rappel, TDD n’est pas une méthode de test, c’est bien une méthode de développement. L’effet produit est d’avoir de bons tests unitaires, mais ce n’est pas la seule méthode pour y parvenir !
La blogosphère agile semble éprouver le besoin irrépressible de trouver un acronyme pour “je code de bons tests unitaires après avoir développé mon code”. On n’y voit pas grand intérêt, mais si ceci a pour effet d’éviter la confusion ambiante sur TDD, pourquoi pas…
S’il n’utilise pas la méthode TDD, recommandons au lecteur de ne pas développer les tests unitaires “plus tard”, mais “le plus tôt possible”.

Progression des méthodes Agiles ?

Le site Methods And Tools a publié le résultat d’une étude qu’il a réalisé sur l’adoption des méthodes agiles. En voici les résultats (comparés à ceux d’une étude similaire réalisée en 2005) :

C’est encourageant : les méthodes agiles sont définitivement sorties de la confidentialité, et leur déploiement progresse assez rapidement. Reste à savoir ce qu’entendent précisément les sondés par méthodes agiles… On sait que dans le domaine, le wannabisme fait rage, et que l’adoption se résume souvent à quelques mesures cosmétiques, autrement appelées cowboy coding (rappelez-vous le test Nokia).
Scott Ambler apporte un commentaire (Scott Ambler’s 2007 Agile survey analyzed for Dr. Dobb’s : Is Agile really that successful?) intéressant sur le sujet.

Et pour s’encourager, on peut toujours regarder la belle courbe de Indeed.com

SOA

2008, annus horribilis de la SOA ?

S’il ne faut pas tomber dans le sensationnalisme, on notera tout de même la crise de doute que traversent les SOAistes en ce début d’année.
Tout d’abord le chantre de la SOA, le Burton Group lui-même, qui se lance à la recherche de projets SOA qui ont vraiment marché (InfoQ : Burton On Real World SOA Experiences) ; hélas, le “Rapport Burton” restera réservé aux clients payants.
Ensuite, la très officielle presse SOAiste searchSOA.com part à la recherche de bonnes utilisations de SOAP, si cela a existé, avec Looking for a few good WSDLs . A quand “Looking for a few good WS-* uses” ?

Enfin, Steve Vinoski, héros de l’époque Corba, a profité de son changement d’employeur pour retourner sa veste et prôner l’approche RESTful dans InfoQ : CORBA Guru Steve Vinoski on REST, Web Services, and Erlang.
Rassurons-nous, rien de cela n’ébranlera les diseurs de bonne aventure SOA qui, après nous avoir gratifié des merveilleuses prédictions du Yahoo SOA Group pour 2008, débattent férocement de UDDI v2, v3 and replication.
Ne jetons tout de même pas bébé avec l’eau du bain. L’approche SOA apporte beaucoup de valeur lorsqu’elle est abordée avec pragmatisme à l’instar du site Enterprise Integration Patterns qui propose des documents de grande valeur comme Developing in a Service-oriented World de Gregor Hohpe (Google).

Le coin de la technique

Java EE 6 : les profiles se dévoilent

Nous avions évoqué le Java EE Web Profile en Janvier. Roberto Chinnici nous dévoile aujourd’hui dans Profiles in the Java EE 6 Platform les différentes pistes pour le Web Profile si cher à Rod Jonhson.
C’est l’occasion pour chacun de donner son opinion éclairée sur le sujet. Les plus extrémistes demandent un Web Profile qui ne porterait que la Servlet API, d’autres demandent à corps et à cri leurs JSFs voire leurs Portlets pour les plus téméraires.
Nous seront moins péremptoires et nous nous limiterons pour le moment à quelques observations :

• Les équipes d’exploitation sont les grands oubliés, JSR-77 : J2EE Management n’est pas au rendez-vous, la standardisation des API de monitoring et de supervision ne semblent intéresser personne. Nous ne sommes pas prêts d’avoir le monitoring des datasources inclu dans Tomcat
• Pourquoi regrouper dans JSR 77 les statistiques de monitoring (JDBCStats, JMSStats, JCAStats, etc) plutôt que de les réintroduire dans chacune des JSR concernées ?
• JMS n’a jamais été aussi aussi utilisé qu’aujourd’hui (merci à Spring-JMS et à ActiveMQ), quel dommage de le voir absent du Web Profile
• L’utilisation de JMS sous tend le pooling des ressources (JCA) et les transactions distribuées (JTA). Cela tire beaucoup d’APIs pour les esprits minimalistes mais le scénario Message Driven Pojo + accès SGBD est chaque jour plus fréquent.
• JTA embarqué dans le Web Profile demanderait un travail substantiel aux équipes de SpringSource qui veulent leur stack Tomcat+Spring certifiée Web Profile. Pour mémoire, JBoss n’a été vraiment satisfait de son Java Transaction Service qu’en version 4.
• JAXB et JAXWS ne rentrent pas dans le débat car ils sont inclus dans le JDK 6.
• On peut voir un pruning en douceur avec les Web Profiles (A) et (B) qui ne sont pas encombrés par les APIs désuètes.

Scénarios pour le Web Profile

Ressources complémentaires

• InfoQ : Java EE 6 Spec Lead Requests Community Feedback on Web Profile Options
• Webtide (ie Jetty) blog: Java EE 6 Web Profile Should JSPs really be included? Do we even need a profile?
• TSS : Roberto Chinnici: Profiles in the Java EE 6 Platform

Load balancing avec Tomcat et Apache

Avneet Mangat nous explique dans TSS : Load-balancing Tomcat with Apache comment mettre en place un cluster Tomcat avec le serveur web Apache. Si la fiabilité de la solution n’a rien rien à envier aux serveurs d’applications sophistiqués pour les cas, très fréquents, qui ne nécessitent pas de réplication de session, on remarquera cependant que la mise en place du load-balancing avec Tomcat et Apache demande sensiblement plus de configuration par édition de fichier qu’avec un serveur commercial. De plus, on regrettera le manque de documentation sur le sujet.

Le load balancing Tomcat avec Apache, une solution prête pour la production ? Oui, mais surtout pour les équipes d’exploitation qui ont la culture du scripting et des technologies open source à la documentation parfois légère. Les équipes qui attendent des procédures packagées seront plus à l’aise avec un serveur d’applications plus complexe.

Tests unitaires : Mockito

Szczepan Faber nous présente dans expect-run-verify… Goodbye! les raisons qui l’ont poussé à créer un nouveau framework de mocks – Mockito – en partant d’un fork d’EasyMock.
Il reproche aux autres frameworks de mocks d’utiliser le pattern expect-run-verify (description des attentes – exécution – vérification) :

• les attentes sont décrites avant l’exécution, ce qui n’est pas intuitif
• les mocks nécessitent d’enregistrer des interactions pour fonctionner même si on n’a pas besoin de les tester
• les tests sont fragiles, sont souvent cassés par l’ajout d’une fonctionnalité
• les attentes (expect) et le bouchonnage (stub) sont mélangés, ce qui nuit à la lisibilité du code
• si les attentes étaient remplacées par des assertions, il n’y aurait plus besoin de déchiffrer la pile d’exécution en cas d’erreur pour retrouver la ligne de code correspondante

Mockito se veut plus souple et plus simple, comme le veut le principe KISS de la culture XP.
Cette comparaison avec EasyMock donne une idée du gain de lisibilité.

Côté limitations Mockito ne permet pas faire de mock sur :

• les classes ou méthodes final (Mockito s’appuie cglib)
• les méthodes equals(), hashCode(), toString()

On regrette toutefois que Mockito ne soit pas sur le repository maven (encore la faute de cglib) !

JSF, répétition de la mésaventure des EJB 2 ?

Les EJB ont inauguré la série “Le pire du mal” avec J2EE AntiPatterns et autres Bitter EJB. TheServerSide a trouvé un successeur avec JSF Anti-Patterns and Pitfalls. On y découvre qu’on peut avoir mal au PhaseListener, qu’il y de nombreux faux-amis du thread-safe, que l’overdose de XML guette et qu’il ne faut pas oublier la “View State Encryption”.

Nous décernons le “JSF trick d’or” au “View State Encryption” pour My Faces Wiki : Secure your application qui nous recommande un merveilleux secret d’encryption qu’on choisit “au hasard”, puis que l’on passe à la moulinette base64, et que l’on stocke enfin en dur dans faces-config.xml. Mais attention ! la taille du secret doit être de huit caractères pour un chiffrement DES ou de seize pour Blowfish; pas un de moins, pas un de plus…
JSF condamné ? Il ne faut pas préjuger de l’avenir. Malgré les critiques innombrables, certains ténors voient toujours en JSF l’avenir des pages web en java. En revanche, si JSF venait à péricliter, personne ne pourra dire qu’il ne savait pas … et JSF 2 est prédit très incompatible avec JSF 1.

Le coin de la technique

• JSF Testing Tools
• Wicket 1.3 released
• WebSphere MQ en environnent J2EE/JEE : JMS vs. ‘MQ Java Interfaces’
• IBM ObjectGrid 6.1 fix 3 : une grille résolument ‘developer friendly’

Le coin de la technique

JSF Testing Tools

Cet article présente trois principaux frameworks permettant d’effectuer des tests unitaires JSF. Pour rappel, la principale difficulté est de pouvoir effectuer des tests en dehors du container, et grâce à ces outils il est possible de tester les composants côtés client mais aussi côté serveur.

• JSFUnit est basé sur HttpUnit et Apache Cactus. Son API permet notamment de tester le transfert de données dans un formulaire et de savoir si le managed bean correspondant à bien été mis à jour… Cet outil inclue aussi un JSF Static Analysis permettant notamment d’analyser les fichiers de configuration.
• Shale Test est un projet Apache fournissant des implémentations d’objet Mock pour les Servlets et les composants JSF.
• JSF Extensions est basé sur JUnit, HTMLUnit, et Cactus. Cet outil est composé d’un module Test-Time fournissant des objets Mock pour les composants JSF 1.2, ainsi qu’un module Design-Time pour effectuer des déploiements plus rapide (hot deploy). Cette fonctionnalité a pour but de mettre en place des tests de manière itératif durant le développement d’application JSF.

Enfin l’article termine par deux outils d’aide au développement et au monitoring d’applications JSF :

• JXInsight, se basant sur l’interface PhaseListener, permet de collecter différentes informations sur l’exécution du code (les stacks…)
• JSF Tools, sous projet de Eclipse WTP, fournit un support pour le développement et le déploiement d’application JSF.

Pour terminer, cet article présente assez bien les différents outils, mais il aurait peut être été bien de proposer des critiques sur ceux-ci, qui feront peut être l’objet d’un nouvel article.

Wicket 1.3 released

Nous annoncions lors de la revue de presse du 12 novembre dernier son passage en RC, et bien c’est maintenant officiel : Apache Wicket 1.3 fait maintenant partit de la volumineuse liste des java web framework disponibles sur le marché. Malgré cette farouche concurrence, le buzz continue : Wicket est l’un des web framework faisant le plus de bruit sur la toile, ses promesses sont simples : simplicité d’utilisation, POJO-centric, pas de configuration XML … donnez votre sur le billet du Xebia Web Framework Contest.

Nous vous invitons à consulter la liste complète des nouveautés à partir du site d’Apache.

• Apache Wicket
• Discovering Apache Wicket 1.3 by Pachod Joseph
• Guide de migration à Wicket 1.3

WebSphere MQ en environnent J2EE/JEE : JMS vs. ‘MQ Java Interfaces’

David Currie nous rappelle dans WebSphere MQ Java in J2EE que JMS est l’API privilégiée pour accéder à Websphere MQ dans un environnement J2EE/JEE et que les historiques API « MQ Java Interfaces » devraient progressivement être remplacées [1].

Au delà d’un simple choix technique d’API (la fiabilité de JMS est aujourd’hui avérée), il s’agit d’un réel changement de culture depuis l’historique approche en langage C (user exits MQ, style de programmation des « MQ Java Interfaces », etc) vers le monde orienté objet Java / .Net [2]. Cette évolution demande un travail d’explication et de formation des équipes qu’il ne faut pas négliger.

La roadmap MQ JMS pourra aller jusqu’au remplacement de Queue Managers MQ par le Websphere Embedded Messaging Engine pour les utilisateurs du serveur J2EE d’IBM …

[1] IBM Technote : Using WebSphere MQ Java Interfaces in J2EE/JEE Environments : « This technote explains why ‘WebSphere MQ classes for Java Message Service’ is the API best suited for use in J2EE/JEE environments … »
[2] IBM DeveloperWorks : Introducing XMS : The IBM Messages API

IBM ObjectGrid 6.1 fix 3 : une grille résolument ‘developer friendly’

Le fix 3 d’IBM ObjectGrid apporte de nouvelles fonctionnalités résolument à l’écoute des développeurs avec notamment :

• Support de Spring Framework
  - Intégration aux transactions Spring et à leurs annotation @Transactional
  - Gestion par le container Spring des beans d’extension d’ObjectGrid (ObjectTransformer, Loader, TransactionCallback, etc)
• Entity Listeners similaires aux listeners JPA/Hibernate autour des événements persist, load, update et remove

On remarquera à l’occasion la poursuite de la nuit de noces entre IBM et Spring Framework dont les précédents épisodes marquant furent le support officiel de Websphere par Spring Framework (11/2007) et la présentation de Billy Newport sur l’eXtreme Transaction Processing à The Spring Experience (12/2007).

Le mois dernier, nous avons décidé de faire du XKE le Xebia Web Framework Contest, un concours de développement autour des framework de présentation.

4 équipes ont développé la même application web, chacune avec un framework (très) différent. Les frameworks retenus étaient :

• Strut2,
• Google Web ToolKit,
• Wicket,
• My Faces (JSF).

8h30 certains, les plus scolaires, sont déjà arrivés et aiguisent leurs environnements, se concertent sur les rôles de chacun.
9h00 tout le monde est là, certains prennent leur café en discutant de tout sauf du concours qui les attend alors que d’autres sont fin prêts …
9h30 les spécifications, tenues secrètes jusqu’au jour J sont enfin distribuées aux équipes et là : grande surprise et grande rigolade ….

Wanda Zeller, directrice d’un réseau de call girls international, a décidé d’augmenter son volume d’affaire en mettant en ligne un site de réservation interactif de ses protégées. Mme Zeller, que son activité contraint à la discrétion, a délégué son chargé d’affaires, M. Moussaud, de relayer ses exigences et de piloter les développements. Mme Zeller, qui vit avec son temps, dispose d’ores et déjà d’un système de réservation qu’utilisent les opérateurs de son call-center marocain. Afin de limiter les efforts de développement, il a été décidé de réutiliser les services métier mis au point pour ce système de réservation, et de limiter les développements à la couche de présentation.

Les spécifications de nouveaux lots seront ensuite distribuées à un rythme assez soutenu, à raison d’une toutes les heures trente. Chacune ayant pour but d’adresser un pan particulier.

• Le premier lot mettait en place les mécanismes de recherche simple et un système de panier avec commande.
• Le lot 2 apportait la couche « sécurité » sur les commandes.
• Le lot 3 ajoutait la mise en place d’un workflow de validation des commandes.
• Enfin le dernier lot mettait l’accent sur l’aspect validation.

Après une journée intense de développement, chaque équipe est venue présenter son œuvre et donner son avis sur les avantages et inconvénients de la solution étudiée.

Google Web Toolkit

L’équipe a bataillé un moment pour trouver quels fichiers étaient à synchroniser entre les membres de l’équipe et ceux qui ne l’étaient pas. Pour ne pas perdre de temps (c’était quand même un concours !), la synchronisation s’est faite finallement par clé USB !

Ce qui avait séduit l’équipe avec ce framework nouvelle génération est le concept du ‘Tout-Java’: le client et le serveur sont codés en java, GWT se charge de la génération des pages web et du javascript. Mais ce modèle à des contraintes:

• Implémentation d’une interface IsSerialisable pour tout objet qui transite entre le client et le serveur (réglé depuis la version 1.4).
• Support de Java 1.4 (seulement), donc il faut oublier les génériques et les annotations pour la partie client (fonctionnalité programmé pour la future version 1.5 ).
• Le concept client-serveur reste quand même assez déroutant quand depuis des années on manipule chaque jours des objets de type Request/Response, des pages JSP/Html ou des actions ‘Struts’.

La conclusion de l’équipe est qu’il faut vraiment aborder GWT comme un framework Client Riche avec un concept de client/serveur; les outils se chargeant entièrement de l’exposition en mode Web (JSP/CSS/AJax). Le coût d’entrée semble assez important et les composants graphiques limités (il n’est pas évident d’intégrer des composants d’une maquette HTML existante). Donc GWT est un outil à suivre en attendant la maturité.

Synthèse de l’équipe :

Les bons points :

• Gestion transparente des différents browsers.
• Possibilité d’utiliser un debugger Java (celui de l’environnement de développement choisi, Eclipse par exemple).
• Beaucoup de buzz autour du projet. Notamment concernant les extensions graphiques (portage de plusieurs librairies AJAX), début d’intégration avec Spring.
• Un retour à la programmation graphique par composant.
• Facile de mettre en place une IHM simple.

Les mauvais points :

• Seule une partie du JRE est supportée côté client et pour les DTO utilisés par les RCPs (ex: pas toutes les collections).
• Besoin d’un mapping objet métier/DTO utilisés par GWT (Serializable et un constructeur public par défaut).
• Manque guide de bonnes pratiques et de la documentation en général.
• Les API ne sont pas toutes détaillées.
• Il n’y a que des composants graphiques « simples ». Si l’on veut utiliser des composants plus évolués, il faut soit les coder ou bien se tourner vers des librairies de widgets GWT Open Source « non Google ».

Les points non abordés :

• Possibilité de faire des tests unitaires.
• Internationalisation.
• JavaScript Native Interface (JSNI).
• Exposition de services via Web Services/JSON/XML.
• Facilité/difficulté du respect d’une charte graphique.
• Authentification.
• Respect des standards, facilité de référencement.
• Intégration à l’IDE Idea (semble assez poussée, gestion des CSS et modules à partir du code Java).

Struts 2

L’équipe avait préparé un template de projet Struts2 avant le XKE, projet Eclipse/Maven 2, web.xml déjà configuré, librairies installées, et différents tests « Hello World » de plugins (zero conf, etc…).
Résultat : c’est l’équipe gagnante.

L’équipe n’a pas rencontré de difficultés particulières, et a décidé de développer l’application avec ses tests unitaires, ce qui n’était peut être pas nécessaire dans le cadre du concours, mais qui a permis de démontrer la facilité avec laquelle les actions Struts2 peuvent être testées unitairement (le gros défaut de Struts 1).

Synthèse de l’équipe :

Les bons points :

• Testabilité : écrire des tests unitaires pour les actions, qui sont de simples POJOs, est très simple.
• Modularité des filtres sur les actions : les piles d’Interceptors sont très pratiques pour appliquer des filtres différents aux actions (authentification etc.). Mais est-ce réellement si utile ? A part le classique interceptor d’authentification qui ne s’applique pas aux actions de type « login » et « forgotten password », a-t-on vraiment besoin de tant de modularité sur les filtres ?
• Simplicité : Struts 2 est simple à utiliser par une équipe projet. Sa modularité et sa testabilité le rendent parfaitement adapté au travail en équipe.
• Prédictibilité par son efficacité et son classicisme : Struts2 est un framework éprouvé aux concepts très répandus (« Action based », Orienté Objet simple) qui ne causera pas de mauvaise surprise. Struts 2 sera prédictible sur un projet.
• Elégance des interactions HTTP : URL claires et un modèle post-and-redirect fiable (double submit) et efficace (bookmarkable) malgré WW-1714 qui est en cours de résolution.
• Souplesse de l’interface graphique : le mécanisme de template est très pratique mettre en œuvre la charte graphique d’un site ou d’une application. SiteMesh est un complément naturel très efficace.
• Débuggabilité : des tags de debug (facilement désactivables pour la production) et un browser de configuration simplifient le troubleshooting (voir également les mauvais points sur la débuggabilité de Struts2).
• Coût d’entrée réduit : le framework est plus simple à appréhender que Struts 1.
• Form beans : aucun fichier de configuration, on peut passer de simples POJO à la vue Tests unitaires : les actions sont testables facilement avec JUnit, les actions sont des POJO.
• Templates : intégration avec Sitemesh aisée pour les templates, les templates Sitemesh ont accès aux tags Struts grâce au plugin struts2-sitemesh.
• Ajax : tags Ajax (support Ajax basé sur le toolkit Dojo) simplifient, voir masquent, l’utilisation de dojoSpring: support de Spring, on choisit le framework d’injection à utiliser dans la configuration.
• Expression Language : les taglibs utilisent OGNL, plus puissant que JSTL, Communauté: framework MVC le plus téléchargé du moment (http://www.jroller.com/TedHusted/entry/struts_skyrockets ) , les mailing lists sont très actives.

Les mauvais points :

• Hétérogénéité / dispersion : Struts 2 se disperse en proposant souvent plusieurs solutions pour un sujet sans qu’aucune ne soit pleinement satisfaisante.
  • Trois technos pour le HTML : JSP, Freemarker et Velocity.
  • Plusieurs projets de configuration par annotations : Zero config etc.
• Configuration propriétaire (struts.xml).
  • Spring est le standard de-facto pour configurer l’assemblage des composants d’une application. Il serait très pratique de pouvoir configurer Struts2 dans les fichiers Spring grâce au mécanisme d’extension de configuration introduit dans Spring 2 à l’instar de la configuration d’Apache CXF (e.g. , etc.).
• Productivité modérée : c’est probablement un écueil du classicisme et de la testabilité (découplage actions-pojo de la présentation) mais la productivité n’est pas stupéfiante.
• Debuggabilité : Struts2 n’affiche aucun message d’erreur en cas de coquille sur les variables de scripting (i.e. manipulées par OGNL) aussi bien dans les page web (jsp, ftl ou velocity) que dans la config (paramètres dans les redirections …). Le problème est en cours de résolution.
• Performances : l’application doit être configurée d’une certaine manière pour obtenir des performances acceptables (http://struts.apache.org/2.x/docs/performance-tuning.html). OGNL est plus lent que JSTL dans certains cas (mais est aussi plus riche).
• Développement : l’équipe de commiteurs est réduite, les trous de sécurité prennent du temps à être corrigés.
• Ajax : Le support Ajax est intégré dans le cœur de Struts2, pas sous forme de plugin, une mise à jour de dojo toolkit demande de sortir une nouvelle version de Struts2 (va changer dans Struts 2.1).
• Documentation : il est parfois difficile de se repérer dans la documentation, certaines pages font parfois référence à webwork, elle n’est pas tout le temps à jour (c’est bien évidemment lié au faible nombre de commiteurs sur le projet).

Conclusion :

Struts2 est basé sur l’excellent WebWork 2.2, les bases sont saines. En revanche, les nouveaux développements Struts 2.0 ont pris du temps, et certains ont été remis en cause dans le futur Struts 2.1. Struts 2.1 est plein de promesses, les performances devraient être meilleures (mise à jour vers OGNL 2.7, vers Dojo 0.9,…), et le plugin SmartURLs devrait permettre de se passer de la configuration explicite, pour se rapprocher encore du paradigme « Convention over Configuration ». Le projet tend vers une consolidation des différents plugins, et a appris de ses erreurs depuis la première release de Struts2. Aujourd’hui nous pouvons conseiller d’attendre la première release stable et éprouvée de Struts 2.1 (Struts 2.1.0 devrait sortir à la fin Octobre 2007) pour démarrer un nouveau projet. La branche 2.0 ne va plus évoluer, et le saut 2.0 vers 2.1 ne sera pas forcément transparent!

JSF/My Faces

Ce groupe de Travail a véritablement bataillé durant toute la journée et le bilan affiché en fin de journée est un peu mitigé.

Les bons points :

• Concepts proches des frameworks Struts 2 et Spring MVC
• Utilisation de POJO simple
• La tentative de standardisation
• Le support des éditeurs

Les mauvais points :

• Complexité de mise en oeuvre
• Manque de documentation
• Manque de transparence sur le fonctionnement du framework
• Impossibilité de mixer JSF avec d’autres composants (Tag JSP 2.0, Taglibs tierces, etc.)

Synthèse de l’équipe :

• Dès le début JSF présente la spécificité d’utiliser un buffer spécifique pour écrire la response.
• Il n’est pas possible d’utiliser directement du code HTML à l’intérieur de tags JSF ! Vous devez baliser tout vos blocs html par <f:verbatim> (bye bye xhtml) ou utiliser la tablig htmLib pour remplacer tous vos tags html par le tag équivalent (perfs ?).
• Autre impact, plus gênant : l’intégration du code JSF avec les autres taglib. JSF ne dispose pas de certains tags intégrés de base dans d’autres frameworks. Par exemple, en JSF les conditions et les boucles n’existent pas. Et comme on atteint vite les limites des fonctionnalités offertes par les taglib JSF, on aimerait bien pouvoir retourner sur du JSTL ; mais là encore vous vous heurterez à des problèmes de compatibilité à cause du « buffer JSF » mentionné plus haut.
• La gestion des templates n’existant pas non plus dans JSF, il faut utiliser struts-tiles.
• Côté gestion des erreurs justement, on peut dire que JSF n’est pas bavard. Pour certains problèmes de navigation la page appelante est simplement réaffichée, sans aucun message d’erreur ! Autant dire que certains bugs deviennent très difficiles à analyser.
• Autre détail, le nom des tags dans les taglib ou même pour les fichiers de conf ne sont pas très intuitifs, mais si vous avez besoin, des plugins permettent de vous imprégner du vocabulaire JSF assez rapidement.

Conclusion :

JSF n’est clairement pas le framework le plus productif, en tous cas pas sur une journée car le coût d’entrée est lourd. Et même une fois habitué au framework, on peut se demander comment être productif sans remontée d’erreur et quelles limites posera cette gestion de buffer spécifique dans le cadre d’un vrai projet ?

Wicket

On peut considérer Wicket comme la bonne surprise de cette journée. Replaçons le contexte. Au moment des choix de chaque consultant, certains ont préféré partir sur la nouveauté (Wicket) par rapport à l’ancien solide et fiable (ex : Struts 2). Les différents contraintes de leur vie professionnelle n’ont pas permis aux membres de cette équipe d’affiner le sujet avant le jour J. Seul un rapide coup d’œil sur le « HelloWorld » de Wicket le soir précédant la compétition. C’est donc sans grandes connaissances qu’ils ont abordés ce concours. A la fin de la journée, ils avaient implémentés globalement l’ensemble du Lot 1 (Rappel: My Faces et GWT n’y sont pas arrivés !). C’est là que le framework choisit intervient.

Les bons points :

• Prise en main rapide
• Véritable séparation entre la partie cliente et la partie serveur (utilisation de plain HTML)
• Retour à la programmation graphique des composants
• Mécanismes de templating par héritage Java
• Pas de fichier de configuration : une classe définie dans le web.xml sert de point d’entrée
• Navigation entre les pages définies en Java (ex: new Link(PageSuivante.class))
• Démarrage rapide (notamment grâce à l’archetype Maven2)

Les mauvais points :

• Documentation très très succinte malgré l’existence d’exemples
  • Pas d’explication des concepts de base (navigation, gestion de la session, templating, etc)

Les points non abordés :

• Possibilité de faire des tests unitaires
• Validation de formulaire
• Internationalisation
• Intégration de composant Ajax

Synthèse de l’équipe :

Les concepts de wicket sont les suivants :

• Séparation très claire entre la présentation (.html) et les actions métiers (.java).
• Pas de longue configuration xml, le seul fichier xml est le web.xml.
• Une création automatique d’un squelette d’application avec un seul artefact maven. (est-ce maven la réelle clé de la productivité ?)
• Haute réutilisation des maquettes html (fournie avec les spécifications) : le positionnement des éléments dynamiques utilisent principalement des balises HTML de type <span> avec un attribut « wicket.id ».

Conclusion :

En un mot, un framework web simple, facile et pragmatique. Ces 3 qualificatifs ont permis à l’équipe d’aller très vite une fois les concepts acquis. Ils ont cependant beaucoup « ralé » sur le manque de documentation. Seuls les exemples fournis leur ont permis de déjouer et de comprendre les subtilités du framework. Il faut cependant relativiser cet enthousiasme :

• Que vaut wicket sur des fonctions avancées comme la validation de formulaire ou un workflow d’écran avec suivant et précédent ?
• Est-il seulement un buzzword du moment ou va-t-il perdurer ?

Alors qui est le gagnant ?

• Catégorie « Couverture », l’équipe Struts2 a implémenté le plus de fonctionnalités, c’est indéniable. En revanche déception vis à vis du rendement !
• Catégorie « Découverte », Wicket a été une révélation pour beaucoup d’entre nous ! Une fois passée la barrière de la découverte, le développement est rapide et efficace.

Pour des raisons évidentes de bonne moralité, nous ne pouvons mettre en ligne les différentes applications développées …