La revue de presse hebdomadaire des écosystèmes Java/JEE proposée par Xebia.

Actualité éditeurs / SSII

• Sortie de la première version stable de Restfuse 1.0

Le coin de la technique

• Humour de développeur

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

• Scala et les EJB2
• Retour sur l’atelier Apache Mahout des Duchess France

Actualité éditeurs / SSII

Sortie de la première version stable de Restfuse 1.0

Restfuse 1.0.0 est la première version stable de cette API créée par EclipseSource. Il s’agit d’une extension open source de JUnit qui permet de tester des implémentations différentes REST (Jersey, RESTLET, RESTeasy…). Ses créateurs s’appuient sur le besoin d’avoir des tests d’intégration sur les services REST au-delà des tests unitaires, et des mocks des services afin de vérifier que le système entier fonctionne correctement.

Les objectifs de ce framework sont :

• Trouver une solution propre pour tester les services REST asynchrones. Pour tester les services asynchrones, les deux solutions les plus communes sont : callbacks ou polling. Les annotations @Callback et @Poll sont fournies afin d’éviter de boucler sur la requête ou de démarrer le serveur avant ou dans le test.

• Faciliter la configuration des requêtes avec des annotations. L’annotation @HttpTest permet de configurer la requête HTTP et de l’envoyer avant que le test ne soit exécuté. Cette méthode essaie d’améliorer d’autres APIs de tests, comme rest-assured où la requête doit être configurée en code Java dans la méthode de test.

Vous pouvez trouver des exemples d’utilisation sur la page de Restfuse et aussi dans cet article InfoQ qui contient plusieurs exemples assez pratiques.

Le projet est hébergé sur Github. La version 1.0 est disponible sur le dépôt central de Maven et aussi sur p2 pour le systèmes OSGi.

Le coin de la technique

Humour de développeur

Nous vous avertissons tout de suite, si vous êtes allergiques à l’humour geek ou aux anglicismes, vous pouvez zapper ce passage qui risque de vous faire bondir. Toujours là ? Allons-y alors !
Depuis peu tournent sur la toile des liens vers cet article. Celui-ci est en fait un « best-of » d’une vieille page de StackOverflow ayant généré des commentaires sur 12 (!) pages. Nous vous laissons la lire, en plusieurs fois tout de même pour éviter l’overdose, mais voici une petite sélection:

• les Yoda conditions: elles consistent à inverser la variable avec la valeur testée dans une condition. Ainsi on écrira if (CONST_VALUE == variable) au lieu de if (variable == CONST_VALUE). Ceci car Yoda lui-même parle en inversant les mots: « si grande est la variable, Jedi tu deviendra ».
• Pokémon Exception Handling: consiste à faire un catch (Throwable t) histoire de catcher toutes exceptions. Provient du slogan des Pokemons « catch’em all« .
• Les accolades égyptiennes: elles représentent le formatage par défaut en Java (voir les préconisations de Sun), c’est-à-dire que la position des accolades fait penser à un Égyptien. Le mieux est de voir cela en image.
• Refuctoring: décrit l’action prenant un beau morceau de code bien pensé pour le transformer, à travers une série d’étapes (ir-)réversibles, en un immonde plat de spaghettis non maintenable.
• Stringly Typed: par opposition à « Strongly typed », indique l’absence de typage et l’utilisation à outrance des chaînes de caractères, entraînant des problèmes visibles seulement au runtime. Se rencontre souvent dans les fichiers XML ou chez les novices en Javascript.
• Le Baklava code: désigne du code où trop de couches s’empilent. On fera l’analogie avec la « Théorie des pâtes » qui assimile des problèmes d’architecture du code à des plats de pâtes. On y retrouve le code spaghetti, le code ravioli, le code lasagne et… le code Spaghetti avec boulettes. Délectez-vous avec les recettes !
• Hydra Code: désigne du code impossible à corriger, où une correction entraîne inévitablement de nouveaux bugs.
• Protoduction code: lorsque du code non prévu qui n’était pas destiné à se retrouver en production finit par y atterrir. Le « Protoduction Driven Development » se rapproche ainsi souvent du « Marketing Feature Driven Devlopment ».
• Megamoth: la MEGA MOnolitique méTHode se retrouve souvent dans les projets où des codeurs bien intentionnés ont regroupé en une seule méthode différents traitements et logiques compliqués histoire de garder le reste du code simple et clair. Généralement, cette méthode fait plusieurs écrans de haut, quelques centaines de lignes et les commentaires sont bien sûr sans rapport avec le traitement effectif.

C’étaient quelques-unes des perles de la première page du thread sur Stackoverflow. La lecture du reste des 12 page est bien sûr fortement conseillée pour se détendre les zygomatiques.

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

Scala et les EJB2

Stephen Colebourne, le bouillant project lead de Joda Time présentait à Devoxx le 17 novembre dernier une conférence sur le langage Fantom. De cette présentation on n’en a malheureusement retenu qu’une petite phrase sibylline lourde de sous-entendus: « Scala ressemble aux EJB2″.

La pique n’a pas manqué de créer le buzz, à tel point que Colebourne s’est senti obligé d’y apporter une explication, puis une autre.

Colebourne voit du mérite dans bien des langages: Groovy, Kotlin, Ceylon, Gosu, Xtend, Clojure et bien entendu, Fantom. Mais sur Scala il reste plutôt sévère: selon lui il y aurait « beaucoup à dire sur Scala, mais peu de bien », car ce langage « prend une direction totalement erronée pour l’avenir ».

Mais que reproche-t-il au juste à ce langage?

• Modularité. Scala n’a pas de système de modules et reprend ainsi une erreur fondamentale du langage Java, difficile à corriger (cf. le projet Jigsaw). Colebourne est d’avis qu’un outil externe tel que Maven, Ivy ou OSGi n’est pas une solution durable à un problème qui doit être résolu au coeur même du langage.

• Concurrence: pourtant si vantée, la programmation concurrente sous Scala ne serait pour Colebourne qu’un « écran de fumée ». Scala s’appuie davantage sur le design de ses librairies et sur une certaine discipline de codage que sur une contrainte forte et inhérente au langage, et permet en effet qu’un objet mutable soit partagé — contrairement à Fantom, qui lui traque ces objets et les signale par des erreurs de compilation.

• Communauté: la communauté Scala serait certes large et active, mais faite de sophistes davantage mus par la beauté du langage et l’émulation intellectuelle que par l’efficacité pragmatique des algorithmes. Colebourne la considère comme un cercle élitiste tendant à prendre de haut le Javaïste « de base ».

• Système de typage: pour Colebourne, ils serait tout simplement trop complexe, « au-delà du raisonnable ». Cette complexité serait un faux atout: « si j’ajoute un String à une liste d’entiers, je devrais obtenir une erreur de compilation, non une liste de Any« .

• Syntaxe: même verdict. Si la flexibilité permet l’écriture fluide de DSLs (et encore, Colebourne y préfère l’approche à la Fantom), les paramètres implicites ou encore les nombreux sucres syntaxiques du langage donneraient au code un côté obscur et hermétique. Utilisés à large échelle sur de grands projets par de vastes équipes, leur effet serait plutôt négatif sur la maintenabilité du code.

• Qualité: Colebourne rend ici la parole à Paul Phillips, un commiteur Scala, et cite des extraits d’un podcast datant de Juin 2011. Philips y évoque l’extraordinaire complexité du code et surtout avoue platement que Scala manque d’une « suite de tests extensive » couvrant l’ensemble du code. Pour Colebourne, c’est la preuve même que Scala n’aurait pas encore atteint les niveaux de maturité, maintenabilité et évolutivité que l’on est en mesure d’attendre d’un langage d’entreprise. (A quoi nous pourrions également rajouter que, comme le note Ceki Gülcü, Scala a à de nombreuses reprises brisé la compatibilité binaire entre releases: 2.7, 2.8, 2.9…)

En somme on pourrait résumer la pensée de Colebourne par « trop de flexibilité tue la flexibilité ». Il va de soi que ses opinions agacent bon nombre d’adeptes de Scala et n’ont pas manqué de déclencher de nombreux commentaires enflammés sur son billet, au milieu, il est vrai, de quelques réponses plus posées (et plus ou moins convaincantes). D’autres enfin ont préféré répondre point par point sous forme de billet.

Retour sur l’atelier Apache Mahout des Duchess France

La semaine dernière s’est tenu un atelier Apache Mahout organisé par les Duchess France et présenté par Michaël Figuière (Xebia) et Jean-Baptiste Lemée (Lateral Thoughts). Le but de cet évènement était de mettre en valeur les fonctionnalités qui peuvent être développées grâce à Mahout et qui sont encore très peu répandues dans les applications d’entreprise.

Apache Mahout est un framework d’apprentissage artificiel (_machine learning_). Il permet, entre autres, de réaliser des moteurs de recommandations, de la classification automatique de documents, ou encore du regroupement d’entités (_clustering_). Ce type d’algorithmique était principalement réservé au monde de la recherche il y a encore une décennie, avant de se répandre parmi les sites Web les plus populaires durant les années 2000, bien que restant une affaire de spécialistes. L’émergence de Mahout, projet initié en 2009, permet enfin la banalisation de ces fonctionnalités tant appréciées par les utilisateurs, grâce à son API Java simple. En cela Mahout devient à l’apprentissage artificiel ce que Lucene est devenu aux moteurs de recherche.

L’atelier Mahout a démarré avec une présentation générale et rapide du framework, suivie par un exercice pratique avec la mise en oeuvre de Mahout pour créer un moteur de recherche de recettes de cuisines, en seulement quelques lignes de code…

Si vous avez manqué cet évènement, vous pouvez retrouver les slides de la présentation ici.

Le client JavaScript que nous allons déployer repose sur jQuery — un framework de haute productivité —, nous lui adjoindrons BackboneJS, un framework MVC REST, et RequireJS, un chargeur de modules à la demande.

Ressources et représentations

Le serveur auquel se connecte notre client est une boutique en ligne type Amazon. Elle propose une liste de produits, disponibles en quantité limitée, qu’il est possible de réserver dans un panier client. Deux ressources implémentent ces fonctionnalités :

Ces ressources produisent et consomment les représentations suivantes :

Les produits disponibles dans le stock disposeront, via leur attribut links, d’une relation afin de les ajouter au panier :

Se reporter à l’article connexe pour plus de détails sur les notions de ressource, représentation et relation.

Structure du site

Notre client web est composé d’une simple page html, d’une css et de modules JavaScript. Outre ses headers, la page index.html se résume aux lignes suivantes.

<body>
  <div id="cart"></div>
  <div id="products">
    <div id="product-creation"></div>
    <div id="product-list"></div>
  </div>
</body>

Trois emplacements sont prévus dans cette page sous la forme de div ; un pour le panier client, un autre pour ajouter un produit en magasin, un dernier pour lister les produits existants. Vides lors de l’affichage de la page, ces trois emplacements vont être renseignés par les données serveur via jQuery. Ce dernier permet de manipuler dynamiquement le DOM – le contenu de la page – afin d’offrir une expérience d’utilisation sans rafraîchissement.

La mise en page est simpliste : les produits occupent la majorité de la page, le panier, lui, est confiné dans une « colonne » sur la droite.

#products {margin-right:250px;}
#cart {float:right; width:250px }

Modules externes

Si jQuery fournit d’excellents outils pour manipuler le DOM, il est agnostique quant à la structuration du code ; BackboneJS permet de le structurer en MVC et RequireJS de le découper en modules. Commençons par confier la gestion des dépendances à RequireJS dans le head de la page index.html.

<script
  data-main="js/main"
  src="//ajax.cdnjs.com/ajax/libs/require.js/0.24.0/require.min.js">
</script>

RequireJS, situé sur un CDN (un repository de librairies), est chargé du code JavaScript de notre page. Pour se faire, il a besoin du point d’entrée de l’application, que l’on nommera main.js. Dans ce fichier, on récupère la main via une méthode require. Les bibliothèques externes sont importées – le préfixe order! indique qu’elles seront chargées dans l’ordre de déclaration – puis notre code exécuté.

require({ baseUrl:'/js' },
  ["order!//ajax.googleapis.com/ajax/libs/jquery/1.6.1/jquery.min.js",
   "order!//ajax.googleapis.com/ajax/libs/jqueryui/1.8.13/jquery-ui.min.js",
   "order!//ajax.cdnjs.com/ajax/libs/underscore.js/1.1.6/underscore-min.js",
   "order!//ajax.cdnjs.com/ajax/libs/backbone.js/0.3.3/backbone-min.js",
   "order!/lib/jquery.pubsub.min.js"],
  function()
  {
      // application
  }
);

Une fois les librairies externes importées, les classes de l’application doivent l’être également. RequireJS permet de moduler une application à loisir, nous retiendrons un découpage « une classe par fichier », de nombreux autres sont imaginables. Il est important de noter que ce découpage est un artifice destiné à faciliter le développement, lors de la mise en production les sources RequireJS seront minifiées (compressées et rassemblées au sein d’un même fichier).

require(...,
  function () {
    require(["product/ProductView",
             "product/ProductCollection"],
    function (ProductView,
              ProductCollection) {
      // application
    });
  }
);

Les classes de l’application sont déclarées avec leur chemin et manipulées grâce à un alias. Elles doivent être déclarées dans un fichier distinct comme module RequireJS via une méthode define comme nous allons le voir.

Créer un produit avec POST

Maintenant que la structure du projet est définie, il est temps de connecter le code aux ressources serveur : BackboneJS entre en jeu. Le formulaire de création de produit est le premier élément à ajouter à la page ; en voici le contenu.

<form method="post" onsubmit="return false" class="product">
  <fieldset>
    <ul>
      <li><label>Name: <input type="text" id="name" size="3" /></label></li>
      <li><label>Price: <input type="text" id="price" size="3" /></label></li>
      <li><label>Stock: <input type="text" id="quantity" size="3" /></label></li>
    </ul>
    <input type="submit" value="new product" />
  </fieldset>
</form>

Dans un premier temps, la classe ProductCreationView doit écraser l’emplacement product-creation de index.html avec la template précédente.

La fichier ProductCreationView est déclaré comme module RequireJS par la méthode define qui le nomme et indique sa dépendance à la template (le préfixe text! permet l’accès à un fichier plat). Ce module retourne une classe View héritée de BackboneJS qui sera instanciée par l’appelant.

Une vue BackboneJS définit :

• l’élément du DOM qu’elle manipule (avec jQuery) via la propriété el
• son constructeur via la propriété initialize
• les évènements capturés sur l’élément manipulé via la propriété events

define("ProductCreationView",
  ['text!/template/ProductCreationTemplate.html'],
  function(tmpl){
  return Backbone.View.extend({
    el: $('#product-creation'),
    initialize: function(){
      this.el.html(tmpl);
    }
  });
});

Le $ est un alias jQuery. Il donne accès à toutes les méthodes du framework ; avec une chaîne en argument, il joue le rôle de sélecteur. Il identifie un élément du DOM et permet de remplacer son contenu avec el.html(value). Le #, issu du monde css, représente l’attribut id d’une balise html (l’attribut class est représenté par un point, « . »).

Lorsqu’une instance de cette vue est créée, son constructeur écrase l’élément DOM à l’id product-creation et le remplace par le contenu de la template.

define("ProductCreationView",
  function(...){
    events: {
      "click input:submit": "create"
    },
    create: function() {
      var name = $('#name');
      var price = $('#price');
      var quantity = $('#quantity');
 
      this.collection.create({
        name: name.val(),
        price: price.val()
      });
    }
  });
});
 
define("ProductCollection", [], function(){
  return Backbone.Collection.extend({
     url: '/resource/product'
  });
});

Ensuite, lors du clic de l’utilisateur sur l’input submit de la template, la méthode create capture la valeur des inputs text Name, Price et Stock et délègue la création du produit à une collection (héritée de la Collection BackeboneJS). Cette dernière déclenche un POST sur la ressource /product avec la représentation qui lui est transmise.

Le fichier main.js déclare les deux classes ProductCollection et ProductCreationView, les instancie, et communique la collection à la vue afin qu’elle puisse créer un nouvel élément dans celle-ci (BackboneJS ne dispose pas de contrôleur à hériter). La méthode start est le bootstrap de l’application RequireJS.

require(...,
  function () {
    require(["product/ProductView",
             "product/ProductCollection"],
    function (ProductView,
              ProductCollection) {
      return {
      start: function() {
        var products = new ProductCollection();
        new ProductCreationView({ collection: products });
      }
    }
  }
);

Récapitulons :

1. la page index.html est chargée par le navigateur
2. la balise script initialise RequireJS qui donne la main à notre code
3. une collection est instanciée avec une référence à la ressource /product
4. une vue est instanciée avec cette collection
5. cette vue charge la template de création de produit dans index.html
6. lors d’une création de produit par l’utilisateur, la vue appelle create sur la collection de produits
7. la collection de produits POST le produit au serveur et récupère celui retourné pour mettre à jour id et links

L’échange HTTP obtenu est le suivant :

# Request
POST /resource/product HTTP/1.1
Host: localhost:8080
Content-Type: application/json;q=1.0
{
  "name":"pull",
  "price":25
}
 
# Response
HTTP/1.1 201 CREATED
Content-Type: application/json
{
  "id":0,
  "name":"pull",
  "price":25,
  "links":[{
    "href":"resource/product/0/stock/{quantity}/{username}",
    "rel":"RELS_BOOK"
  }]
}

Lister les produits avec GET

Maintenant qu’il est possible d’ajouter des produits via l’interface, voyons comment les afficher ; un emplacement est prévu à cet effet, celui à l’identifiant product-list.

<form method="post" onsubmit="return false">
  <fieldset>
    <ul>
      <li><strong><%= product.get('name') %></strong></li>
      <li>Price: $<%= product.get('price') %></li>
      <li>
        <label>
          Qty: <input type="text" data-id="<%= product.get('id') %>" value="1" size="3"/>
        </label>
      </li>
    </ul>
 
    <input type="submit" data-id="<%= product.get('id') %>" value="add to cart" />
  </fieldset>
</form>

La template précédente permet l’affichage d’un produit, elle utilise la syntaxe UnderscoreJS <%= value %> (utilisé également par BackboneJS ; il existe de nombreux moteurs de templates, MustacheJS, entre autres). Elle est intégrée à la page grâce au code de la classe ProductView qui lui transmet un produit en paramètre. Le produit étant issu d’une collection BackboneJS, accéder à une propriété passe par un getter.

define("ProductView",
  ['text!/template/ProductTemplate.html'],
  function(tmpl){
  return Backbone.View.extend({
    el: $("#product-list"),
    initialize: function(){
      _.bindAll(this, 'render');
      this.collection.bind('add', this.render);
    },
    render: function() {
      var template = '';
      this.collection.each(function(product) {
        template += _.template(tmpl, { product: product });
      });
      this.el.html(template);
    }
  });
});

Le constructeur de cette classe positionne un écouteur sur l’ajout d’élément à la collection de produits avec bind. L’occurrence de cet évènement déclenche la propriété render de la vue. Cette écoute étant effectuée par la collection, le this manipulé par la méthode render de la vue lui est relatif. L’utilisation d’une méthode utilitaire d’Underscore, bindAll, permet de modifier ce comportement en indiquant que le this manipulé par la méthode render est la vue elle-même.

L’ajout d’un produit à la collection manipulée par cette vue ajoute une template pour chaque produit à la page. Les collections BackboneJS offrent une méthode each pour faciliter l’itération sur leurs éléments. Lorsque plusieurs éléments sont ajoutés à une page, il est plus performant de les concaténer et de les afficher d’un coup.

L’identifiant du produit est positionné sur l’input submit afin de localiser le produit sélectionné par le client par la suite. L’input text recevant la quantité réservée le reçoit également à cette fin.

Réserver une quantité d’un produit

Afin de permettre la réservation d’une certaine quantité d’un article, il est nécessaire d’ajouter le code suivant à la classe ProductView :

define("ProductView",
  function(...){
  return Backbone.View.extend({
    events: {
      "click input:submit": "book"
    },
    book: function(event) {
      var product_id = $(event.target).data('id');
      var quantity = $('input[type=text][data-id="'+product_id+'"]').val();
 
      var links = this.collection.get(product_id).get('links');
 
      var map = new Object();
      _.each(links, function(link) {
        map[link.rel] = link.href;
      });
 
      $.ajax({
        type: 'POST',
        url: map['RELS_BOOK'].replace('{quantity}', quantity).replace('{username}', "xebia"),
        success: function() {$.publish('basket-event')},
        error: function(xhr) { alert(xhr.responseText) }
      });
    }
  });
});

Le clic sur l’input submit de la vue est capturé et son évènement déclencheur permet d’identifier quel produit, parmi la liste proposée, a été sélectionné : event.target permet d’accéder à l’input submit qui a reçu le clic. Il est alors possible de récupérer ses attributs, ici son data-id (cet identifiant est préférable à id car il est utilisé pour deux éléments, la quantité et le bouton submit). Les collections BackboneJS offrent une méthode get(id) permettant d’accéder à un élément par son identifiant. La quantité est récupérée à l’aide d’un sélecteur jQuery.

Les relations proposées par le produit sélectionné sont copiées dans une map, et la template de réservation d’un produit est complétée (quantity et username). Un POST est réalisé sur le lien obtenu.

Afficher le panier

Lors du succès d’une réservation, le panier doit être rafraîchi. La ressource /product ajoute un ou plusieurs produits dans le panier utilisateur, représenté par la ressource /basket. La ressource /basket ne remonte donc aucune notification au client, puisqu’elle est modifiée côté serveur. Il donc nécessaire, comme le fait le handler success de l’appel de réservation, de publier un évènement lors du succès d’un achat à destination du panier afin qu’il se rafraîchisse. Cette gestion d’évènements est ajoutée à jQuery par Tiny Pub/Sub.

define("BasketView",
  function(...) {
  return Backbone.View.extend({
    el: $('#cart'),
 
    var view = this;
    $.subscribe('basket-event', view.fetch);
  },
  fetch: function() {
    var view = this;
    this.model.clear();
    this.model.fetch({ success: view.render });
  },
  price:0,
  render: function() {
    var stocks = this.model.get('stock');
    var view = this;
    var tmpl = '';
    var total = 0;
 
    _.each(stocks, function(stock) {
        var product = view.collection.get(stock.id);
        var price = stock.quantity * product.get('price');
        total += price;
        tmpl += _.template(basketItemTemplate,
                          { quantity: stock.quantity,
                            name: product.get('name'),
                            price: price });
    });
    this.el.html(_.template(basketTemplate, { total: total }));
    $('tbody', this.el).html(tmpl);
    this.price = total;
  });
});

Deux templates sont nécessaires à l’affichage du panier : un tableau et un élément répété pour chaque produit. Le calcul du prix du panier est effectué côté client ; lors d’un clic utilisateur sur le bouton « checkout » le prix est comparé à celui retourné par le serveur et, s’il est correct, le payement est effectué et le panier vidé (la comparaison du prix et son calcul côté client sont, bien entendu, réalisés à des fins didactiques).

define("BasketView",
  function(...) {
  return Backbone.View.extend({
    events: {
      "click input:submit": "checkout"
    },
    checkout: function() {
      var links = this.model.get('links');
      var map = {};
 
      _.each(links, function(link) {
        map[link.rel] = link.href;
      });
 
      var total = this.price;
      $.getJSON(map['RELS_PRICE'], function(response) {
        if(response.value == total)
          $.post(map['RELS_PAYMENT'], function() { $.publish('basket-event') });
      });
    }
  });
});

Épilogue

L’interface unifiée de HTTP offerte par BackboneJS simplifie grandement l’interaction avec un serveur REST (en plus des exemples présentés ici, la modification d’un élément déclenche un PUT, sa suppression un DELETE). L’utilisation d’une liste de relations, plutôt que d’URI, entre client et serveur diminue encore leur couplage. Pour approfondir le sujet davantage, se référer à l’article de référence sur l’intégration des solutions jQuery dans l’entreprise.

Une fois déployée, la servlet Jersey mappe l’url /resource/* ; la partie cliente est disponible sur /index.html. Le web.xml définit deux filtres Jersey afin de loguer les trames HTTP des échanges client-serveur.

Par convention, GET /product liste tous les produits, GET /product/12 affiche le produit identifié, PUT /product/12 remplace le produit identifié par celui transmit, DELETE /product/12 supprime le produit identifié, POST /product crée le produit transmis et fourni son identifiant en réponse. Les verbes GET, PUT et DELETE sont sûrs et idempotents (sans effet de bord – effet identique à requête identique). POST est utilisé comme factory (ici pour créer de nouveaux produits) et pour toute opération non sûre ou non idempotente (par exemple, déplacer une quantité du stock vers un panier). Les navigateurs internet utilisent abondamment GET pour accéder au contenu d’une page web et POST lors de la soumission d’un formulaire.

Ressources

L’application que nous nous apprêtons à développer est une boutique en ligne type Amazon. Elle propose une liste de produits, disponibles en quantité limitée, qu’il est possible de réserver dans un panier client. Deux ressources implémentent ces fonctionnalités, ProductResource et BasketResource, dont voici les définitions :

Récupérer la liste des produits s’effectue avec un GET sur http://localhost:8080/resource/product.

À l’instar de la navigation sur internet, naviguer entre ressources s’effectue à l’aide de liens. Alors que sur le web c’est le nom du lien qui aiguille l’internaute, ici c’est la relation — l’attribut rel — qui permet de naviguer. HTTP définit des relations standards, pour couvrir les besoins de l’exercice, les suivantes lui sont ajoutées et communiquées au client :

Représentations

Les représentations sont les objets échangés entre client et serveur (en XML ou JSON, à la demande du client). Elles sont définies dans un XSD. Côté serveur, la grappe d’objets équivalente est générée par XJC. Un précédent article aborde les notions de JAXB en détails. Voici une définition compacte des représentations :

La servlet Jersey est initialisée avec le paramètre POJOMappingFeature afin d’utiliser Jackson pour le marshalling JSON plutôt que JAXB, dont la responsabilité est ici limitée au marshalling XML. Jackson produit un JSON plus standard — la dépendance jersey-json est ajoutée au pom.xml.

JAXB requiert l’annotation @XmlRootElement afin de produire/consommer les objets du modèle en XML. Jackson n’en nécessite aucune.

Les représentations et les ressources sont intimement liées. Leur nommage gagne à être cohérent : la ressource /product produit une List lors d’un GET et consomme un Product lors d’un POST ; la ressource /stock produit et consomme un Stock. Sans information (le déplacement d’un produit dans le panier et le paiement), aucune représentation n’est consommée ni produite, seuls l’URI, le statut de retour et les headers caractérisent l’échange.

Status de retour

Quelle que soit l’opération demandée, les ressource indiquent toujours un statut de retour. Ce code, composé de 3 chiffres dont le premier spécifie la catégorie (1. information, 2. succès, 3. redirection, 4. erreur client, 5. erreur serveur), est indiqué à chaque appel de ressource, quel que soit le verbe HTTP utilisé et la présence, ou non, de représentation. 200, 301 et 404 sont les plus connus, ils indiquent, dans l’ordre, un succès, une redirection et l’absence du document recherché. Se référer à la liste des statuts HTTP pour plus de détail.

Headers

Une trame HTTP est composée, en plus d’une représentation — le body — et d’un statut de retour, de headers — l’entête –. Les headers HTTP, une liste de propriétés clé/valeur, en plus de véhiculer la négociation de médiatype, communiquent des informations de cache, de concurrence et de sécurité notamment. Un précédent article aborde les notions d’authentification HTTP en détails.

Ressource produit

L’intégralité du code étant disponible sur GitHub, nous nous focaliserons sur les points clé de l’implémentation. Toute latitude est laissée au lecteur d’aller et venir entre les explications suivantes et le code lié. Afin de simplifier la compréhension, le rôle du référentiel de données est joué par des classes dotées de méthodes statiques, Products, Stocks et Purchases. Commençons avec la classe ProductResource.

import javax.ws.rs.GET;
import javax.ws.rs.POST;
import javax.ws.rs.Path;
import javax.ws.rs.core.Response;
 
@Path("/product")
public class ProductResource {
    @GET
    @Path("/{id}")
    public Response get(@PathParam("id") long id) {
        Product product = Products.get(id);
        return Response.ok(product).build();
    }
 
    @POST
    public Response post(Product product) {
        Products.put(product);
        return Response.ok(product).build();
    }
 
    @GET
    public Response get() {
        List<Product> products = Products.get();
        GenericEntity<List<Product>> entity = new GenericEntity<List<Product>>(products) {};
        return Response.ok(entity).build();
    }
}

L’annotation @Path permet de déclarer l’URI d’une ressource au niveau d’une classe puis de la compléter si nécessaire au niveau méthode (le scannage de Jersey peut être restreint à un package dans le web.xml). Les méthodes HTTP sont représentées quant à elles par des annotations du même nom @GET, @PUT, @DELETE et @POST appartenant au package javax.ws.rs de JAX-RS. Du même package, le builder Response permet notamment de positionner le code de retour (la méthode ok(...) le positionne à 200), la représentation retournée, les headers, etc.

GenericEntity est nécessaire lors de la production d’une List en guise de réponse. Les implémentations de List n’étant pas annotés avec JAXB, cette encapsulation permet de positionner une liste au premier nœud du graphe.

En cas d’absence du produit, une NotFoundException est levée par Products. Cette exception, de la famille des WebApplicationException est capturée par un mapper annoté @Provider. Cette classe d’exceptions introduite par Jersey remonte une réponse avec statut de retour approprié : ici, 404.

La classe Product (générée par XJC) est la représentation consommée et produite par cette ressource ; elle a été réduite ici à sa plus simple expression.

import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlRootElement;
 
@XmlRootElement
@XmlAccessorType(XmlAccessType.FIELD)
public class Product {
    protected long id;
    protected String name;
    protected int price;
    protected List<Link> links;
}

Lors d’un appel à cette ressource le header Accept permet d’indiquer les préférences du médiatype utilisé pour communiquer la représentation. Le navigateur Chrome, par exemple, indique les suivants Accept: text/html,application/xml;q=0.9,/;q=0.8. Ceux-ci sont pondérés, ainsi il préfère XML (0.9) à JSON (0.8, */* indiquant ceux non exprimés auparavant). Il obtient donc la représentation en XML :

<products>
  <product>
    <id>0</id>
    <name>pull</name>
    <price>25</price>
    <links>
      <href>resource/product/0/stock/{quantity}/{username}</href>
      <rel>rels/book</rel>
    </links>
  </product>
</products>

Appelé d’un client JavaScript la représentation sera bien plus compacte, grâce au JSON :

[{
  "id": 0,
  "name": "pull",
  "price": 25,
  "links": [{
    "href": "resource/product/0/stock/{quantity}/{username}",
    "rel": "RELS_BOOK"}]
}]

Ces représentations ont été indentées, sans quoi, elles seraient exprimées sur une simple ligne.

L’échange client serveur peut être simplifié ainsi :

# Request
GET /product HTTP/1.1
Host: localhost:8080
Accept: application/json;q=1.0
 
# Response
HTTP/1.1 200 OK
Content-Type: application/json
[{"id": 0...}]

Tests produit

Afin de s’assurer du fonctionnement de cette première ressource, un serveur Jetty-Embedded peut être déployé et une batterie de tests exécutée à l’aide du client Jersey. Voyons comment avec la classe ProductResourceTest et son référentiel de données Shipments.

import static com.sun.jersey.api.client.ClientResponse.Status.OK;
import static com.sun.jersey.api.client.ClientResponse.Status.NOT_FOUND;
 
import org.junit.Rule;
import javax.ws.rs.core.UriBuilder;
 
import com.sun.jersey.api.client.Client;
import com.sun.jersey.api.client.ClientResponse;
 
public class ProductResourceTest {
  @Rule
  public EmbeddedTestServer server = new EmbeddedTestServer();
 
  @Before
  public void before() {
    for (Product product : Shipments.products())
      productResource().post(product);
  }
 
  @Test
  public void shouldGetProduct() {
    Product product = productResource(2).get(Product.class);
    assertNotNull(product);
    assertEquals(product.getName(), "L'étranger");
  }
 
  @Test
  public void shouldNotGetUnexistingProduct() {
    ClientResponse response = productResource(12).get(ClientResponse.class);
    assertEquals(response.getStatus(), NOT_FOUND.getStatusCode());
  }
 
  @Test
  public void shouldListProducts() {
    ClientResponse clientResponse = productResource().get(ClientResponse.class);
    List<Product> products = clientResponse.getEntity(new GenericType<List<Product>>() {});
 
    assertEquals(OK.getStatusCode(), clientResponse.getStatus());
    assertEquals(Shipments.size(), products.size());
  }
 
  /* helpers */
 
  private WebResource productResource() {
    URI uri = UriBuilder.fromPath("resource/product").build();
    return Client.create().resource(server.uri()).path(uri.getPath());
  }
 
  private WebResource productResource(long productId) {
    URI uri = UriBuilder.fromPath("resource/product/{id}").build(productId);
    return Client.create().resource(server.uri()).path(uri.getPath());
  }
}

L’annotation @Rule permet d’externaliser le lancement du serveur (basé sur le web.xml). L’initialisation réalisée par l’annotation @Before utilise POST comme une factory pour créer, un à un, de nouveaux produits. Les tests utilisent GET pour vérifier la présence de ceux-ci (et leur numérotation côté serveur). Les listes nécessitent l’utilisation de GenericType afin de conserver leur typage.

Le client a généré, au préalable, les représentations avec XJC. Ainsi, il peut demander l’unmarshalling de la réponse à Jersey. On notera l’accès direct à la classe Product dans le premier test et le passage préalable par ClientResponse dans le second, donnant accès, en plus de la représentation de la réponse, à son statut et ses headers. On notera également la gestion de template proposée par UriBuilder dont la méthode build(...) remplace les différents tags.

Ressource stock

La notion de stock d’un produit lui est indépendante. Positionner le stock comme attribut de produit porte à confusion : déplacer un produit du stock vers le panier client ne doit pas concerner tout le stock, seulement la quantité réservée. Pour autant, définir une ressource indépendante /stock/{productid} est ambiguë. Une manière plus élégante est de l’exprimer comme noeud du produit /product/{id}/stock ; cela traduit bien l’appartenance de l’un à l’autre sans impliquer la présence d’un attribut dans la représentation. Les / d’une URL définissent toujours une hiérarchie.

L’implémentation suivante considère l’ajout au stock comme un arrivage et utilise donc POST. Si l’accès au stock avait été considéré comme le remplacement de la quantité existante, PUT aurait été retenu.

import javax.ws.rs.core.Response.Status;
import javax.ws.rs.core.EntityTag;
import com.google.common.base.Objects;
 
@Path("/product")
public class ProductResource {
  @POST
  @Path("/{id}/stock")
  public Response addToStock(@PathParam("id") long id, Stock stock) {
    Integer instock = Stocks.quantity(id);
    Stocks.put(id, instock + stock.getQuantity());
    return Response.status(Status.ACCEPTED).build();
  }
 
  @GET
  @Path("/{id}/stock")
  public Response stock(@PathParam("id") long id) {
    Stock stock = new Stock();
    stock.setQuantity(Stocks.quantity(id));
    return Response.ok(stock).tag(eTag(id, stock.getQuantity())).build();
  }
 
  private EntityTag eTag(long id, int quantity) {
    return new EntityTag(String.valueOf(Objects.hashCode(id, quantity)));
  }
}

L’ajout de stock vérifie au préalable l’existence du produit et renseigne le statut de la réponse en conséquence (Stocks s’en remet à Products qui lève une NotFoundException le cas échéant). La classe-représentation consommée et produite par cette ressource est la suivante.

@XmlRootElement
@XmlAccessorType(XmlAccessType.FIELD)
public class Stock {
  protected int quantity;
  protected long id;
  protected Link related;
}

Lors de l’accès à la ressource stock un tag d’accès concurrent est ajouté aux headers. Ce dernier est calculé à partir du hash de l’id produit et de la quantité disponible. Lorsqu’il veut réserver une certaine quantité du stock, le client fournit ce tag — qu’il estime être le dernier en date — afin que le serveur puisse lui indiquer si la ressource a changé depuis (ici, si la quantité a changé). Si c’est le cas, le client doit la récupérer à nouveau du serveur. Lorsque les deux tags correspondent, le serveur accepte la demande client.

Ce tag peut également permettre 1. de ne pas reconstruire une grappe d’objets côté serveur si le client a déjà sa dernière version 2. de gérer la concurrence de modification d’une ressource.

import javax.ws.rs.core.Request;
import javax.ws.rs.core.Context;
 
@Path("/product")
public class ProductResource {
  @POST
  @Path("/{id}/stock/{quantity}/{username}")
  public Response post(@PathParam("id") long id, @PathParam("quantity") int quantity,
      @PathParam("username") String username, @Context Request request) {
 
    String message;
    int productQuantity = Stocks.quantity(id);
 
    if (request.evaluatePreconditions(eTag(id, productQuantity)) == null) {
      if (Stocks.sell(id, quantity)) {
        Purchases.put(username, id, quantity);
        return Response.ok().build();
 
      } else message = "Product is out of stock";
    } else message = "eTag mismatch";
    return Response.status(Status.PRECONDITION_FAILED).entity(message).build();
  }
}

Lors de la réservation d’un produit, le tag transmis est comparé (par le biais d’une méthode utilitaire de Request) à sa valeur actuelle. Si ce calcul est couteux, la valeur du hash peut être sauvegardée avec l’objet afin d’économiser ce coût. Cette comparaison renvoie un statut 412 si un problème se produit. Ensuite, le stock est décrémenté s’il lui reste assez d’articles (la méthode sell renvoie un booléen acquittant l’opération).

Lorsqu’une erreur se produit, la réponse, en plus du code 412 — préconditions non respectées –, se voit dotée d’un message d’erreur approprié.

Afin de limiter le couplage, le lien de réservation ne sera pas connu par le client. Ce dernier sera averti de l’accès à la réservation par la présence d’une relation rels/book. Cette relation est ajoutée au produit lors de sa création via POST.

@Path("/product")
public class ProductResource {
  @POST
  public Response post(Product product) {
    Products.put(product);
    addBookLink(product);
    return Response.ok(product).build();
  }
 
  static UriBuilder uriBuilder = //
  UriBuilder.fromPath("resource/product").path("{id}/stock/{quantity}/{username}");
 
  private void addBookLink(Product product) {
    Link link = new Link();
    URI uri = uriBuilder.build(product.getId(), "{quantity}", "{username}");
    link.setHref(uri.getPath());
    link.setRel(Rels.RELS_BOOK);
    product.getLinks().add(link);
  }
}

Enfin, une fois une quantité du stock déplacée vers un panier client, une ressource va permettre l’accès au panier d’un client. N’ayant que peu de sens sans le nom du client, ce paramètre est rendu général à la classe.

@Path("/basket/{username}")
public class BasketResource {
  @PathParam("username") String username;
 
  @GET
  @Path("/{product}")
  public Response get(@PathParam("product") long productId) {
    Map<Long, Integer> quantityByProductId = Purchases.get(username);
    Stock stock = new Stock();
    stock.setId(productId);
    stock.setQuantity(quantityByProductId.get(productId));
    return Response.ok(stock).build();
  }
}

Tests stock

Pour incrémenter le stock d’un produit, son id est nécessaire ; mais, comme il est généré côté serveur, il est nécessaire de le récupérer lors de sa création. Par convention, POST retourne toujours l’objet qui lui est soumis décoré au minimum d’un identifiant. La création d’un produit, présentée en tête de cet article, s’appuie sur la classe utilitaire Products associant un id au produit avant de retourner le produit ainsi identifié au client. Voici le cas de test du stock.

public class ProductResourceTest {
  @Before
  public void before() {
    for (Product product : Shipments.products()) {
      product = productResource().entity(product).post(Product.class);
      Stock stock = new Stock();
      stock.setQuantity(2);
      stockResource(product.getId()).post(stock);
    }
  }
 
  private WebResource stockResource(long productId) {
    URI uri = UriBuilder.fromPath("resource/product/{id}/stock").build(productId);
    return Client.create().resource(server.uri()).path(uri.getPath());
  }
}

Ce code reprend l’initialisation précédente et ajoute, pour chaque produit, un stock de 2 unités. Les produits ayant désormais du stock il est possible de tester leur réservation dans le panier d’un client.

import com.google.common.collect.ImmutableMap;
import com.google.common.collect.Maps;
import com.xebia.representation.Rels;
 
public class ProductResourceTest {
  @Test
  public void shouldAccessStock() {
    for (Product product : getProducts())
      assertEquals(2, stockResource(product.getId()).get(Stock.class).getQuantity());
  }
 
  @Test
  public void shouldMoveProductToBasket() {
    String username = "xebia";
    int quantity = 2;
 
    Product product = getProducts().get(0);
    String uriBook = rels(product.getLinks()).get(Rels.RELS_BOOK);
    resource(uriBook, ImmutableMap.of("quantity", quantity, "username", username)).post();
 
    assertEquals(0, stockResource(product.getId()).get(Stock.class).getQuantity());
    assertEquals(quantity, basketResource(username, product.getId()).get(Stock.class).getQuantity());
  }
 
  /* helpers */
 
  private WebResource resource(String href, Map<String, ?> params) {
    URI uri = UriBuilder.fromPath(href).buildFromMap(params);
    return resource(uri.getPath());
  }
 
  private List<Product> getProducts() {
    ClientResponse clientResponse = productResource().get(ClientResponse.class);
    return clientResponse.getEntity(new GenericType<List<Product>>() {});
  }
 
  private Map<Rels, String> rels(List<Link> links) {
    Map<Rels, String> rels = Maps.newHashMap();
    for (Link link : links)
      rels.put(link.getRel(), link.getHref());
    return rels;
  }
 
  private WebResource basketResource(String username, long productId) {
    URI uri = UriBuilder.fromPath("resource/basket/{user}/{id}").build(username, productId);
    return createClient().resource(server.uri()).path(uri.getPath());
  }
}

On notera l’utilisation du lien de réservation, rels/book, proposé par la ressource stock limitant la connaissance du client à la template (quantity, username) qu’il doit poster. En l’absence d’un article par exemple, ce lien peut disparaitre, mettant le client — ignorant l’URI complète — dans l’impossibilité d’effectuer une réservation. Ainsi l’état de l’application et ses possibilités futures sont exprimées par ces relations hypermédia (HATEOAS). Client et serveur partagent la connaissance des transitions, celles-ci étant rendues disponibles par le serveur lors de l’accès aux ressources. Le couplage obtenu entre client et serveur en est ainsi affaibli.

Le panier propose des relations afin d’accéder à chaque article réservé (la relation related est souvent utilisé à des fins d’économie de ce genre) au prix total et au paiement. Un client, après avoir accédé à une ressource, navigue grâce aux relations communiquées par cette dernière aux ressources suivantes. Le code clé-en-main disponible sur GitHub couvre le paiement et la rupture du stock, afin de prolonger le sujet.

Épilogue

Implémenter REST avec Jersey résulte en un code compact, élégant, explicite et indépendant du médiatype. Le cache, la sécurité et la concurrence sont supportés dans le même esprit de simplicité. Quelques considérations sur le sujet ; comme le nom d’un auteur littéraire à succès, les URI publiques gagnent à ne pas changer. Divulger le minimum d’URI, en offrant un jeu de relations riches au client, masque la complexité du serveur ; les clients agissant en fonction de relations, modifier la logique du serveur est alors peu impactant et réduit le recours au versionning.

L’implémentation d’un client JavaScript communiquant avec le serveur développé ici, réalisée dans l’article connexe consacré au sujet, est l’occasion d’apprécier davantage les vertus de l’interface uniforme de HTTP. Le livre RESTful Web Services Cookbook est un excellent moyen de se plonger davantage encore sur la question.

• REST ou pas REST

Le coin de la technique

• SpringSource: Spring Social et Spring AMQP en 1.0
• Memory Image

REST ou pas REST

Un article a fait le buzz la semaine dernière sur les architectures REST. Kelly Sommers nous propose de revoir, de façon claire et détaillée, la définition d’une API REST.
En effet, avec l’émergence des frameworks Javascript, des traitements de présentation faits hier côté serveur sont maintenant revenus à leur juste place, au sein des navigateurs clients.
Pour couvrir un maximum de sites, les grands d’Internet se doivent d’avoir une API externe. C’est pour cela que des sites comme Twitter, Flickr, Google Search proposent d’utiliser leurs services via ces APIs dites « RESTful »: grâce à elles, il est possible d’intégrer de tels services dans un site tiers, et ce sans bibliothèque particulière.
Mais l’étude menée par Kelly Sommers nous démontre que certaines de ces APIs n’ont de RESTFul que le nom.
Rappelons au passage que REST signifie Representational State Transfer: il s’agit donc de gérer les états des ressources exposées par ces APIs.

Les règles les plus élémentaires d’une API REST sont en général bien respectées:

• Utiliser le transport HTTP
• Chaque service possède une URL définie
• L’application doit gérer un format de sortie simple (text/html, application/xml, application/json…)
• Gestion explicite des opérations avec les verbes HTTP: GET, POST, PUT, DELETE…

D’autres règles, plus contraignantes, sont cependant assez fréquemment bafouées :

• Pas de gestion d’état côté serveur (pas d’utilisation de la session HTTP, le client fournit l’intégralité des données au serveur à chaque appel)
• Si, dans une réponse, la ressource en cours de consultation contient une référence vers une autre ressource, la première doit contenir un lien vers un autre service qui permet de détailler aussi la seconde. On parle d’utilisation de liens hypertextes dans la réponse HTTP.
• La réponse doit pouvoir prévenir le client si elle peut être mise en cache dans le navigateur.

Nombre d’applications web utilisent des fermes de serveurs pour absorber la charge. On utilise ensuite des mécanismes complexes de transfert de session en cas de pannes de l’un d’eux, pour éviter la perte de données. REST propose une autre solution: comme il n’y a pas de données en session, on peut facilement changer de serveur entre chaque appel sans problème: la contrainte d’une architecture sans état devient alors un atout.

En ce qui concerne l’usage des liens hypertextes, l’exemple choisi, extrait de l’API Twitter, est très parlant. Si la réponse contient la description d’un client, on s’attend naturellement à recevoir le lien vers un autre service REST pour en avoir la description complète. Cela permet de maintenir la logique de suite des services au sein de l’application, et non pas dans le client.

Il est souvent intéressant de revenir aux sources des choses pour mieux les comprendre. Le service REST vous permet d’avoir une application indépendante du client qui l’appelle. Mais comme toute solution, attention à toujours suivre tous les principes fondamentaux! Il ne faut ne pas confondre Remote Programming Control et service REST. A vos claviers pour des API REST dignes de ce nom!

Un exemple d’API que nous trouvons réussie, et qui respecte ces patterns, est celle de Spring Batch Admin. La page d’accueil vous présente la liste des services qu’on peut invoquer, et chaque réponse contient un lien vers un service de description lié. Il reste juste une petite astuce pour gérer les opérations DELETE et PUT.

Le coin de la technique

SpringSource: Spring Social et Spring AMQP en 1.0

Les réseaux sociaux forment un nouveau médium de communication qui désormais ne peut plus être négligé. Avec Spring Social 1.0, SpringSource fournit une approche commune pour authentifier un utilisateur et permettre d’utiliser les APIs propriétaires des grands réseaux sociaux; le but de cette initiative est de simplifier et homogénéiser l’accès à ces APIs hétérogènes.

Twitter et Facebook sont pleinement supportés; le support de LinkedIn, TripIt, GitHub et Gowalla est en cours. Bien sûr, un SPI vous permet également d’intégrer votre réseau social favori. Par exemple, des projets externes se consacrent actuellement à l’intégration de Foursquare et Dropbox. Il ne faut cependant pas négliger l’effort d’adaptation requis : marshalling, unmarshalling, gestion des erreurs… sans oublier les différences d’implémentation du protocole d’authentification Oauth, utilisé par la plupart des réseaux sociaux.

Avec la sortie de Spring AMQP 1.0, ce nouveau protocole de message n’a plus rien à envier à JMS en terme de facilité d’utilisation. Pour les utilisateurs de CloudFoundry, c’est une nouvelle API pour utiliser RabbitMQ, le système de message de la plateforme.

Memory Image

Martin Fowler nous propose un article sur la notion de Memory Image. Il fait suite à une publication cet été sur une application de passage d’ordres pour les marchés financiers, le projet LMAX. Cette application Java permet de traiter pas moins de 6 millions d’opérations par seconde… sur un seul Thread!

Pour arriver à ce niveau de performance, l’application met en place le mécanisme d’Event Sourcing.

L’application est divisée en trois parties:

• Input Disruptors
• Business Logic
• Output Disruptors

Les éléments Input et Output Disruptors sont chargés de recevoir, archiver et transmettre les données hors du système, avec des entrées-sorties fréquentes et une conception multi-threadée faisant appel à des buffers circulaires FIFO permettant de diminuer les temps de latence élevés dus aux entrées-sorties.

Le composant Business Logic quant à lui représente le cœur du traitement. De façon surprenante, cet élément de l’architecture n’est pas conçu pour l’exécution concurrente, et repose entièrement sur un seul thread.

Le concept est plutôt simple, toutes les données sont en mémoire dans le centre du Business Logic. Martin Fowler rappelle gentiment que pour faire fonctionner les mécanismes de cache du code de la JVM, on doit avoir des méthodes courtes et bien découplées (ces patterns de conception ne sont pas du pur hasard !). La seule contrainte est de pouvoir recomposer l’état du système à travers une journalisation des événements passés faite au fil du temps. Ainsi, il suffit de rejouer le journal des événements et votre application reprend son traitement où elle en était.

Martin Fowler revient également sur le concept de « sympathie mécanique » (mechanical sympathy) qu’il emprunte à Martin Thompson: il s’agit de soigner l’interaction entre le programme et le hardware qui l’exécute afin d’optimiser les performances. Par exemple, Fowler explique que son équipe a pris soin d’écrire des implémentations « cache-friendly » et « garbage-collector-friendly » de l’interface Map plutôt que d’utiliser les implémentations classiques; mais surtout il explique que le choix même des paradigmes de programmation est crucial: un modèle concurrentiel fondé sur les files de messages serait d’après lui moins « CPU-friendly » qu’un modèle à producteur unique, comme les Disruptors et leurs buffers circulaires. D’après Fowler, ce choix a permis d’optimiser les caches CPU de façon non négligeable.

Avec l’avènement du concept de NoSQL, nous apprenons déjà à revoir nos choix d’architecture pour la persistance de données. Avec le concept de Memory Image, Martin Fowler nous propose d’aller encore plus loin en se demandant même si un stockage persistant des données, de quelque type que ce soit, est réellement utile dans toutes les situations.

Se dissocier de la persistance permet d’avoir un modèle clair et d’éviter les acrobaties de mapping requises par les frameworks d’ORM (le fameux problème de l’impedance mismatch). Pas besoin non plus de personnaliser jusqu’à la dernière goutte les requêtes SQL pour arriver au niveau de performance voulu. Par contre, l’un des problèmes de l’approche in-memory est l’absence de notion de transaction. Il est en effet très difficile d’appliquer un rollback à des objets en mémoire, contrairement à ceux d’une base de données. Il faut donc valider un maximum les données avant même de faire le traitement.

Alors, êtes-vous prêts à faire 6 millions de transactions par seconde sur 1 thread ?

Actualité éditeurs / SSII

• Mozilla Firefox 4 RC 1
• xCode 4 : l’âge de raison

Le coin de la technique

• Java EE 7

Actualité éditeurs / SSII

Mozilla Firefox 4 RC 1

La première release candidate de Mozilla Firefox 4 est sortie le 9 mars. Cette release fait suite à une (longue) liste de versions bêta. On peut citer au nombre des nouveautés : l’intégration d’un nouveau moteur d’exécution JavaScript plus performant nommé JägerMonkey, un support partiel des transitions CSS, un meilleur support du HTML 5 avec notamment le support de l’API HTML forms, le support de l’accélération matérielle. La note de version complète est accessible ici.

Un petit rappel sur HTML forms: cette API permet d’effectuer une validation des formulaires directement par le navigateur. Cet ajout majeur devrait standardiser et simplifier la gestion de la validation côté client en mettant fin aux validations bricolées en JavaScript : des attributs positionnés directement sur les contrôles du formulaire permettront de valider avec élégance les contraintes les plus courantes (longueur, non-nullité, conformité vis-à-vis d’une expression régulière, etc.). Des fonctions de rappel (callbacks) en JavaScript demeurent malgré tout accessibles pour les cas non triviaux.

On peut aussi noter l’inclusion de la fonctionnalité Do Not Track, censée mieux protéger la vie privée des utilisateurs. Son activation ajoute un élément dans l’entête HTTP enjoignant aux sites visités de ne pas procéder au suivi de l’utilisateur. Toutefois, cette fonctionnalité n’aura pas d’impact sur votre navigation avant que les sites et les annonceurs ne la prennent en compte.

xCode 4 : l’âge de raison

Après de longs mois en bêta développeur (conditionnée à l’achat d’une licence annuelle), la version 4 de xCode est enfin disponible. L’environnement de développement Mac/iPad/iPhone propose ici une refonte majeure avec, notamment, l’unification dans xCode des outils jusqu’alors isolés dans d’autres applications (construction de l’interface et gestion des performances). Deuxième modification majeure, le choix du compilateur LLVM par défaut et l’arrivée — enfin ! — du quick fix lors de l’écriture (et plus seulement lors de la compilation). Troisième apport, GIT et SVN sont désormais intégrés bien que quelques ajustements semblent encore nécessaires.

Si ces changements peuvent être perturbants, l’aide contextuelle — appuyée par des vidéos de démonstration — aide souvent à s’y retrouver. Attention, xCode devient payant pour les « candidats libres » (sans licence annuelle) : 4€ qui sont surtout un prétexte au plébiscite du nouvel App Store pour Mac.

Le coin de la technique

Java EE 7

Suite à la sortie de Java SE 7 en developper preview, c’est au tour de Java EE 7 de faire parler de lui. Il y a deux semaines, la spécification de la plateforme Java Entreprise Edition dans sa version 7 a été soumise au JCP sous la JSR 342. Bien entendu, cette spécification est une proposition qui devra être votée et implémentée par l’« expert group ». Selon plusieurs sources, JEE 7 devrait voir le jour courant 2012, au troisième ou quatrième trimestre.

Au programme de cette version 7 : du cloud, du cloud et encore du cloud. En effet, cette JSR « umbrella » — c’est-à-dire chapeautant à son tour d’autres JSR — se veut résolument « cloud-friendly ».

Mais JEE 7 couvrira aussi d’autres sujets : le support des derniers standards du Web, la modularité et la facilité de développement.

Focus sur le Cloud

Le spec lead de cette JSR voit le cloud comme un prolongement du modèle orienté conteneur (accès au système et aux ressources externes géré par le conteneur) de la plateforme Java Entreprise Edition, où une application peut être déployée sur une machine unique comme sur un cluster de manière distribuée, sans changements radicaux, grâce à la souplesse de la stack.

La plateforme JEE étant déjà bien parée pour des environnements cloud — grâce à son modèle orienté conteneur et à son abstraction d’accès aux ressources — l’objectif de la spécification est d’améliorer l’intégration de la plateforme dans des clouds privés ou publics, afin que les applications y soient exposées « as a service », avec le support de fonctionnalités telles que l’extensibilité horizontale (« horizontal scalability ») ou encore la « multitenancy » (principe d’architecture logicielle où une seule instance d’une application peut servir, de manière individualisée, différents clients avec potentiellement des configurations et des paramétrages personnalisés).

Il s’agit également de tenir compte des problématiques liées au cloud (sécurité, isolation, qualité de service), en définissant par exemple de nouveaux rôles, tel que celui de PaaS (Platform as a Service) administrator ou en mettant à jour le modèle de sécurité de la plateforme en ce sens. Aussi, les applications qui voudront tirer avantage des différentes fonctionnalités spécifiques au modèle PaaS devront-elles obéir à certaines contraintes et fournir un moyen d’être identifiées comme étant conçues pour évoluer dans un environnement cloud.

Bon nombre d’APIs vont être mises à jour pour tenir compte de ces problématiques. Celles notamment qui gèrent des accès aux ressources, comme JPA, JDBC ou encore JMS, devront se rendre compatibles avec les systèmes multitenants. Dès lors, des ressources externes telles qu’une source de données ou une file de messages pourront être marquées comme étant partagées entre plusieurs applications. Les « expert groups » qui gouvernent chaque API seront chargés d’identifier ces besoins et de prendre les mesures adéquates.

Les derniers standards du Web

Le Web est aussi à l’honneur pour cette version 7 de la plateforme. D’ailleurs, deux nouvelles APIs, venant étoffer le support des dernières technologies Web dans le vent, sont en discussion :

• Support du HTML5 et des Web Sockets via l’API Java Web Sockets.
• Support de JSON (JavaScript Object Notation) via l’API Java JSON.

JEE 7 inclura aussi la version 2.0 de l’API JAX-RS (Java API for RESTful Web Services) définie par la JSR 339. Cette dernière sera rajoutée au profil Web, en plus des mises à jour des APIs déjà présentes au sein de celui-ci.

Modularité

Cette JSR a aussi pour objectif de faciliter la modularité et la gestion de versions, en permettant par exemple à une application d’utiliser une version supérieure d’une API déjà incluse dans la plateforme. Ce travail devra être coordonné avec la JSR à venir sur la modularité dans Java SE afin de rendre les deux plateformes cohérentes.

Facilité de développement

Tirant les leçons de certaines API vilipendées pour leur lourdeur ou leur complexité — on pense aux EJB d’avant la version 3.0 — cette version 7 se veut simple, légère, efficace et efficiente. En ce sens, l’API JMS dans sa version 2.0 va être améliorée et l’API CDI (Context and Dependency Injection), introduite dans JEE 6, se verra doter d’une API pour configurer un injecteur : l’API DI 1.1 (la suite de la JSR 330).

A noter que la JSR 342 propose l’ajout de deux nouvelles JSRs, à savoir :

• Concurrency Utilities for Java EE (JSR-236) : construite sur l’API java.util.concurrent, cette API offre des facilités pour exécuter des tâches de manière asynchrone.
• JCache (JSR-107) : cette API a pour objectif de standardiser un système de cache accessible depuis tous les conteneurs en vue de rendre les applications plus « scalables » (extensibles).

En résumé, plusieurs APIs déjà présentes dans JEE seront mises à jour :

• Java Persistence API (JPA)
• Java API for RESTful Web Services (JAX-RS)
• JavaServer Faces (JSF)
• Servlets
• Enterprise JavaBeans (EJB)
• JavaServer Pages
• Expression Language
• Java Messaging Service (JMS)
• Java API for XML-based Web Services (JAX-WS)
• Contexts and Dependency Injection for Java EE (CDI)
• Bean Validation
• Dependency Injection for the Java Platform (JSR-330)
• Common Annotations (JSR-250)
• Java Connector Architecture

Ce modèle a été développé par Léonard Richardson. Léonard Richardson est, entre autres, co-auteur du livre « Restful Web Service » publié chez O’Reilly.
Martin Fowler a récemment publié un papier à propos du Modèle de Maturité de Richardson intitulé « Richardson Maturity Model: steps toward the glory of REST ». Dans ce papier, Martin Fowler déroule et commente le Richardson Maturity Model au travers d’un cas d’utilisation simple (réserver un rendez-vous chez le médecin).

Ce billet présente le Richardson Maturity Model en s’appuyant en grande partie sur le papier de Martin Fowler. Au programme :

• Le niveau 0 : Le RPC sur HTTP en POX (Plain Old XML).
• Le niveau 1 : L’utilisation de ressources différentiées.
• Le niveau 2 : L’utilisation des verbes et des codes retours HTTP.
• Le niveau 3 : L’utilisation des contrôles hypermédia.

Le niveau 0 : Le RPC sur HTTP en POX

A ce niveau, qui constitue le point de départ du modèle, on ne peut pas vraiment parler de REST : on se contente d’utiliser HTTP comme système de transport pour interagir à distance avec un « service ».
Toutes les requêtes sont envoyées vers le même endpoint (la même URI) : /appointmentService. Elles sont complètement décrites dans le flux XML envoyé. Dans l’exemple proposé par Martin Fowler, la réservation se fait de la façon suivante :

Une première requête est envoyée pour obtenir les créneaux disponibles à une date donnée :

POST /appointmentService HTTP/1.1
[various other headers]
<openSlotRequest date = "2010-01-04" doctor = "mjones"/>
Le serveur retourne une liste de créneaux :
HTTP/1.1 200 OK
[various headers]
<openSlotList>
  <slot start = "1400" end = "1450">
    <doctor id = "mjones"/>
  </slot>
  <slot start = "1600" end = "1650">
    <doctor id = "mjones"/>
  </slot>
</openSlotList>

Une deuxième requête est envoyée (sur le même endpoint) pour réserver un des créneaux de la liste :

POST /appointmentService HTTP/1.1
[various other headers]
<appointmentRequest>
  <slot doctor = "mjones" start = "1400" end = "1450"/>
  <patient id = "jsmith"/>
</appointmentRequest>

Si la demande aboutit, le serveur retourne un rendez-vous :

HTTP/1.1 200 OK
[various headers]
<appointment>
  <slot doctor = "mjones" start = "1400" end = "1450"/>
  <patient id = "jsmith"/>
</appointment>

Si la demande échoue, le serveur retourne un message d’erreur :

HTTP/1.1 200 OK
[various headers]
<appointmentRequestFailure>
  <slot doctor = "mjones" start = "1400" end = "1450"/>
  <patient id = "jsmith"/>
  <reason>Slot not available</reason>
</appointmentRequestFailure>

Vous noterez l’incongruité d’une réponse 200 OK en cas d’erreur (nous y reviendrons).

Cette approche revient à mettre en place un simple système RPC (Remote Procédure Call). Elle met en œuvre les mêmes mécanismes que SOAP ou XML-RPC, mais en s’affranchissant des enveloppes inhérentes à ces mécanismes. Les messages échangés sont du POX (Plain Old XML).

Le niveau 1 : l’utilisation de ressources différenciées

Dans le Richardson Maturity Model, le premier pas vers l’utilisation de REST consiste à introduire la notion de ressource. Ce qui est somme toute assez logique, puisque REST est un modèle d’architecture basé sur la manipulation de ressources (tout est ressource).
Ainsi, là où au niveau 0, toutes les requêtes étaient faites vers un unique endpoint (une unique URI), au niveau 1, les requêtes sont envoyées à des ressources individuelles : dans l’exemple de Martin Fowler, des médecins et des créneaux.

La première requête (pour demander les créneaux disponibles) se fait vers l’URI d’une ressource de type médecin :

POST /doctors/mjones HTTP/1.1
[various other headers]
<openSlotRequest date = "2010-01-04"/>

La requête étant faite sur un médecin (une ressource) particulier, le flux XML ne spécifie plus cette information.

La réponse du serveur est en substance la même, mais elle fournit maintenant pour chaque créneau un identifiant de ressource : chaque créneau est maintenant une ressource qui peut être requêtée individuellement :

HTTP/1.1 200 OK
[various headers]
<openSlotList>
  <slot id = "1234" doctor = "mjones" start = "1400" end = "1450"/>
  <slot id = "5678" doctor = "mjones" start = "1600" end = "1650"/>
</openSlotList>

La requête de réservation d’un créneau se fait maintenant sur la ressource idoine :

POST /slots/1234 HTTP/1.1
[various other headers]
<appointmentRequest>
  <patient id = "jsmith"/>
</appointmentRequest>

La réponse renvoyée par le serveur est la même qu’au niveau 0.

Au niveau 1, l’introduction des ressources nous permet de gérer la complexité de notre système (de notre API de réservation) par l’approche « divide & conquer » : nous avons éclaté un service en plusieurs ressources.

Le niveau 2 : L’utilisation des verbes et des codes retours HTTP

La deuxième étape de l’approche prônée par le Richardson Maturity Model est d’introduire l’utilisation des verbes et des codes retours HTTP. Dans REST, les ressources sont manipulées au travers d’un jeu de verbes simples. Le plus souvent les verbes HTTP pour la simple et bonne raison que la majeure partie des implémentations REST se fait sur HTTP.

L’idée est de tirer parti du protocole sur lequel nous nous appuyons. Ainsi, au niveau 2, Martin Fowler déroule son exemple de la façon suivante :

La première requête (pour demander les créneaux disponibles) se fait en utilisant une requête GET (et non plus POST) :

GET /doctors/mjones/slots?date=20100104&status=open HTTP/1.1
Host: royalhope.nhs.uk

La réponse à cette requête est la même qu’au niveau 1.

Pour rappel, HTTP définit GET comme une opération « sécurisée » qui n’induit aucun changement d’état côté serveur. Cette particularité présente deux avantages :

• Les requêtes GET peuvent être invoquées autant de fois qu’on le souhaite dans n’importe quel ordre : la réponse à une requête sera toujours la même (sauf bien sûr si l’état de la ressource a été modifié par ailleurs).
• Les résultats des requêtes GET peuvent être mis en cache par les différents équipements intervenant dans la chaîne de routage de la requête (dans un système comme celui de l’exemple déroulé par Martin Folwer, il conviendra évidement de régler correctement le « cache timeout »).

La requête de réservation d’un créneau est la même qu’au niveau 1 (en POST).

Les réponses retournées par le serveur sont les mêmes qu’au niveau 1 à l’exception du code retour utilisé :

• Si la demande aboutie, le serveur retourne un code 201 Created : ce code réponse indique clairement qu’une nouvelle ressource a été créée. L’URI de cette ressource est contenue dans la réponse : Location : slots/1234/appointment (la ressource elle-même, dans sa représentation XML, est également retournée afin d’éviter une requête supplémentaire au client). L’indication fournie par le code retour est plus riche qu’avec un simple 200 OK.

HTTP/1.1 201 Created
Location: slots/1234/appointment
[various headers]
<appointment>
  <slot id = "1234" doctor = "mjones" start = "1400" end = "1450"/>
  <patient id = "jsmith"/>
</appointment>

• Si la demande échoue, le serveur retourne un code 409 Conflict : ce code réponse indique clairement que la requête n’a pas aboutit en raison d’un conflit (le créneau est déjà réservé). L’utilisation d’un code en 4XX a ici beaucoup plus de sens que celle du 200 OK qui devient fallacieuse quand on retourne une erreur.

HTTP/1.1 409 Conflict
[various headers]
<openSlotList>
  <slot id = "5678" doctor = "mjones" start = "1600" end = "1650"/>
</openSlotList>

Au niveau 2, l’utilisation des verbes et codes retours standards de HTTP nous permet de tirer pleinement parti du protocole sur lequel nous nous appuyons (« By following the rules of HTTP we’re able to take advantage of that capability. »).
Cette approche nous permet également d’éliminer les variantes dans la façon de traiter les choses et ainsi, de gérer des cas similaires de façon semblable dans l’ensemble de notre API.

A propos de l’utilisation des standards HTTP, Martin Fowler soulève un point très intéressant. Comme il l’explique, les partisans de REST poussent à l’utilisation de l’ensemble des verbes HTTP (ce qui permet de disposer d’une sémantique CRUD). Or, un argument souvent avancé est que le modèle REST a fait ses preuves à très grande échelle : internet est construit sur une architecture REST. En effet, cet argument est inattaquable quand il s’agit d’utiliser POST et GET, mais il devient beaucoup plus discutable quand on parle de l’utilisation des verbes PUT et DELETE.

Le niveau 3 : L’utilisation des contrôles hypermédia

Le troisième et dernier niveau du Richardson Maturity Model introduit la notion de HATEOAS (Hypertext As The Engine Of Application State). Derrière cet acronyme barbare se cache un principe simple : les transitions possibles vers les états suivants sont fournies par des liens hypermédia.

Les requêtes sont les mêmes qu’au niveau 2, mais les réponses sont ici enrichies avec, pour chaque ressource, un élément link fournissant l’URI permettant de la manipuler.
Ainsi, dans l’exemple de Martin Fowler, la réponse à la requête de demande de créneaux libres est :

HTTP/1.1 200 OK
[various headers]
<openSlotList>
  <slot id = "1234" doctor = "mjones" start = "1400" end = "1450">
     <link rel = "royalhope.nhs.uk/linkrels/slot/book"
           uri = "slots/1234"/>
  </slot>
  <slot id = "5678" doctor = "mjones" start = "1600" end = "1650">
     <link rel = "royalhope.nhs.uk/linkrels/slot/book"
           uri = "slots/5678"/>
  </slot>
</openSlotList>

Et la réponse à la requête de réservation d’un créneau est :

HTTP/1.1 201 Created
Location: slots/1234/appointment
[various headers]
<appointment>
  <slot id = "1234" doctor = "mjones" start = "1400" end = "1450"/>
  <patient id = "jsmith"/>
  <link rel = "royalhope.nhs.uk/linkrels/appointment/cancel"
        uri = "slots/1234/appointment"/>
  <link rel = "royalhope.nhs.uk/linkrels/appointment/addTest"
        uri = "slots/1234/appointment/tests"/>
  <link rel = "self"
        uri = "slots/1234/appointment"/>
  <link rel = "royalhope.nhs.uk/linkrels/appointment/changeTime"
        uri = "doctors/mjones/slots?date=20100104@status=open"/>
  <link rel = "royalhope.nhs.uk/linkrels/appointment/updateContactInfo"
        uri = "patients/jsmith/contactInfo"/>
  <link rel = "royalhope.nhs.uk/linkrels/help"
        uri = "help/appointment"/>
</appointment>

Le premier avantage de l’utilisation des contrôles hypermédia est que les développeurs côté serveur peuvent refactorer les URI d’accès à l’API sans impacter les clients (pour autant que les clients utilisent les URI fournies par les éléments link).

D’autre part, l’utilisation des contrôles hypermédia permet d’auto-documenter l’API REST. Même si cette approche ne suffit pas à documenter complètement l’API, elle fournit un premier niveau d’information :

• Elle aide les utilisateurs de l’API REST (les développeurs de clients) à explorer ses capacités : chaque réponse indique ce qu’il est possible de faire après en indiquant les ressources manipulables (on notera que les éléments link ne fournissent pas d’indication sur les verbes utilisables).
• Elle permet aux développeurs de l’API de communiquer sur les nouvelles fonctionnalités en ajoutant de nouveaux éléments link dans les réponses.

Perspectives

Le Richardson Maturity Model propose un fil conducteur permettant d’appréhender pas à pas les concepts sous-jacents à une approche RESTFul :

• Niveau 1 : Gérer la complexité de notre système via l’approche « divide & conquer » en introduisant la notion de ressource.
• Niveau 2 : Eliminer les variantes dans la façon de traiter les choses et de gérer des cas similaires de façon semblable en introduisant un jeu de verbes standards pour manipuler les ressources.
• Niveau 3 : Auto-documenter le protocole et fournir un premier niveau de découvrabilité au travers de la notion de HATEOAS.

Le Richardson Maturity Model fournit aussi un biais intéressant pour évaluer la « RESTitude » d’une architecture.

Actualité éditeurs / SSII

• Google lance son langage pour la JVM
• iBeans : la solution d’intégration pour applications Web de MuleSoft

Agilité

• Pair programming à distance sous Eclipse avec Saros

SOA

• L’initiative REST-* fait débat

Le coin de la technique

• OSGi 4.2
• Scala OSGi-fié
• Astuces de performance pour MySQL
• Enquête sur les temps de redémarrage des serveurs JEE
• Premiers pas avec memcached

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

• Soirée Tontons Flexeurs le 24 Septembre

Actualité éditeurs / SSII

Google lance son langage pour la JVM

Lors du JVM Language Summit de la semaine dernière, Google a présenté son nouveau langage pour la JVM appelé Noop. Le Wiki du projet et sa présentation permettent de faire le tour des spécificités de ce langage :

• Syntaxe prévue pour être facilement compréhensible par un développeur Java ou C++
• Pas de types primitifs, pas de classes ou méthodes statiques, variables non mutables par défaut, pas de syntaxe optionnelle, exceptions uniquement de type unchecked
• Librairie standard s’appuyant sur JodaTime, util.concurrent et Google Collections
• Support natif du concept d’injection de dépendances offert par Guice ou PicoContainer, un type est alors soit newable soit injectable
• Support natif des tests unitaires qui ont leur structure dédiée sans classes ni méthodes

Les réactions qui ont suivies cette annonce montrent en général un intérêt couplé à une réserve légitime due à l’état embryonnaire du projet. Ainsi l’analyse de Dominique de Vito s’inscrit dans ce schéma, tandis qu’Alexis Moussine-Pouchkine, Sun, explique à 01net qu’il trouve enrichissant la profusion de nouvelles idées mais que, selon lui, le langage Java restera malgré tout omniprésent pendant encore des années.

Reste que là où de nombreux nouveaux langages justifient leur existence par une syntaxe plus compacte, une nature dynamique ou encore des concepts élaborés, Noop semble adopter une approche plus pragmatique et plus proche des besoins quotidiens rencontrés en informatique de gestion. L’avenir nous dira si les apports de ce langage sont suffisants pour convaincre des équipes de le préférer à Java pour leurs développements.

iBeans : la solution d’intégration pour applications Web de MuleSoft

MuleSource, récemment renommé en MuleSoft lors du lancement de leur offre Tcat Server a récemment diffusé une première beta public d’un nouveau produit : Mule iBeans. Il s’agit d’une nouvelle solution d’intégration s’attaquant à un marché différent des ESB traditionnels. MuleSoft part en effet du constat que de nombreuses applications Web doivent s’intégrer avec diverses ressources distantes, mais ne peuvent s’appuyer sur un ESB qui constituerait une solution trop lourde. iBeans se positionne ainsi en tant que solution d’intégration pour applications Web. La nuance est légère par rapport aux ESB mais on constate clairement cette orientation dans la pratique : annotations, composants iBeans, injection de services type IoC avec un contexte request, …

La particularité principale du projet est son modèle de composant iBeans. Il s’agit de composants similaires aux Beans Spring ou aux Session Beans EJB mais spécialisés dans l’accès à un service à distance. Ces composants utilisent certaines annotations de la récente JSR-330 (Dependency injection for Java) et peuvent s’intégrer facilement avec Spring, Struts et JSF.

MuleSoft propose parallèlement un projet nommé Community iBeans Proposals visant à regrouper les iBeans de la communauté pour intégrer les ressources les plus fréquentes.

iBeans répond à un besoin courant des applications Web. La réponse proposée par MuleSoft est élégante mais on pourra regretter l’apparition d’un modèle de composant supplémentaire disposant de son propre cycle de vie. Actuellement l’éditeur n’a pas communiqué sur son projet naissant en dehors de la page Wiki dédiée. Une recherche Google montre rapidement que la communication autour de ce projet est quasi inexistante. Toutefois, une session dédiée au sujet prévue pour Devoxx 2009 tend à nous faire penser que la célèbre conférence européenne pourrait bien servir de rampe de lancement au nouveau projet de MuleSoft.

Agilité

Pair programming à distance sous Eclipse avec Saros

L’université de Berlin propose depuis quelques temps un plugin Eclipse nommé Saros, offrant des fonctionnalités permettant le pair programming à distance grâce au protocole XMPP. Concrètement les possibilités sont :

• Reproduction ou synchronisation d’un projet Eclipse à distance via une connexion XMPP.
• Visualisation dans l’environnement de l’observer des classes ouvertes et de la classe en cours d’édition par le driver.
• Affichage en temps réel des modifications du code, et de la position du curseur et du texte sélectionné.
• Gestion expérimentale d’un mode multi-driver permettant de modifier le code à deux simultanément.
• Chat via une vue dédiée dans Eclipse

Un screencast est proposé sur le site du projet, celui-ci permet de se rendre compte des capacités du plugin.

Idéalement complété d’une conversation Skype, ce plugin trouvera sa place dans de nombreux scenarii allant du distributed pair programming à l’assistance d’un collègue situé à un autre étage.

SOA

L’initiative REST-* fait débat

JBoss vient de lancer le site REST-*.org hébergeant son initiative de standardisation de plusieurs services middleware traditionnels sur le modèle REST.

Actuellement deux drafts sont en cours de rédaction, l’un porte sur RESTful Messaging, l’autre sur RESTful Transactions. Ces deux spécifications visent à définir un ensemble d’URIs standards sur le modèle REST permettant d’exposer une ressource transactionnelle ou un broker de messages.

Très rapidement, de vives réactions sont apparues au sein de la communauté, principalement pour faire part de leur scepticisme quant à cette initiative, régulièrement comparée à la très lourde collections de spécifications WS-*, qui pourrait mettre à mal la simplicité unanimement reconnue du modèle REST. C’est ainsi le cas d’Anne Thomas Manes qui revient également sur les critiques de Bill Burke à l’égart de l’initiative RestMS qui existait déjà et qui pariait plutôt sur Atom et AMQP.

Bill Burke de son coté publie sur son blog un billet par jour depuis la publication sur le site REST-*.org, pour justifier ses choix et la légitimité du projet qu’il porte. Ses arguments portent principalement sur le fait qu’il existe une demande très forte de la communauté pour gérer les services de messaging et les transactions avec REST.

Le débat est compréhensible : la volonté d’exposer certaines ressources transactionnelles ou services de messaging s’inscrit dans les besoins courants des entreprises, tout comme les craintes de voir se reproduire les erreurs du passé sont légitimes. L’apport de cette initiative est donc probablement de porter sur le devant de la scène une réflexion sur un problème pourtant courant et déjà exposé par Leonard Richardson et Sam Ruby, il y a deux ans, dans leur livre majeur RESTful Web Services.

Le coin de la technique

OSGi 4.2

OSGi est sur le devant de la scène, d’InfoQ à OSGi Thoughts en passant par The Programming Delusion (BJ Hargrave, CTO de l’OSGi Alliance), depuis une petite semaine et pour cause : l’OSGi Alliance a sorti et mis à disposition le 16 septembre dernier les spécifications finales de la version 4.2 (téléchargeables ici).

Alex Blewitt nous résume la situation sur InfoQ. On retiendra qu’Equinox et Félix ont déjà commencé leur travail de compatibilité avec OSGi 4.2. Les spécifications étant désormais released, ce n’est qu’une question de temps avant que les projets affichent fièrement leur label OSGi 4.2 compliant.
On notera aussi une nouvelle méthode de lancement du runtime OSGi, le nouveau nom des Distributed OSGi qui deviennent les Remote Services (connexion de VMs OSGi), les Blueprint Services qui seront des services wired à la Spring, le concept de Bundle Tracker ou bien encore le mécanisme de permission sur une opération dans un bundle.

Pour la petite piqure de rappel, on pourra se tourner vers JavaLobby qui nous propose depuis quelques jours 2 tutoriaux HelloWorld sur OSGi, le premier avec Swing et le second avec Spring RC.
Et pour les plus nostalgiques, le Paris JUG sur OSGi, c’était (déjà) il y a 1 an…

Scala OSGi-fié

On reste dans les news OSGi avec un projet qui propose Scala 2.7.6 en version OSGi-fiée (vu ici).

Comme expliqué sur le GitHub du projet, Scala n’est pas (encore) packagé en bundle OSGi. Certes, le plugin Eclipse Scala IDE utilise un bundle OSGi qui embarque Scala mais celui-ci ne peut pas être utilisé de manière générale (manifest spécifique et toutes les librairies dans un seul jar).

scala-lang-osgi répond à ce besoin et fournit un bundle OSGi pour chaque librairie Scala. Le tout est disponible sur le repository maven scala-tools.org.

Astuces de performance pour MySQL

Même si nos ORMs préférés génèrent des requêtes optimisées à notre place, il arrive parfois que, pour des raisons de performances ou autres, l’on doive écrire certaines requêtes directement en SQL.
Le site Debian Admin (par Code Purity) référence à cette fin 84 astuces d’optimisations de performances pour MySQL.
Certes, la plupart des astuces de configuration de MySQL sont peut-être/certainement déjà mises en place par nos chers DBA. Mais on trouvera aussi une pléiade d’astuces concernant la requête elle-même : cela passe de la non utilisation du gourmand SELECT *, d’éviter au possible l’utilisation de DISTINCT (très consommateur), d’utiliser pour l’insertion des BATCH INSERT et REPLACE ou bien encore l’utilisation INET_ATON et INET_NTOA au lieu de CHAR et VARCHAR pour les adresses IP.
Pour le détail complet, rendez-vous directement sur le site de Debian Admin.

Enquête sur les temps de redémarrage des serveurs JEE

ZeroTurnAround, l’éditeur de JRebel, a mené (et continue même à collecter des données) une étude sur les temps de redémarrage / redéploiement des serveurs d’applications auprès des lecteurs de son blog (environ 700 personnes ont répondu).
Tout d’abord, passons sur la conclusion évidente de l’étude, vous avez besoin de JRebel, pour tenter de voir au delà de cette évidence marketing. On évitera aussi la polémique sur le rapprochement Conteneurs de Servlets / Serveurs d’applications.
On constate tout d’abord que la population fréquentant le blog de ZeroTurnAround (on a donc dès le début une information en partie biaisée) a une forte tendance à confier ses applications à une plate-forme basée sur Tomcat (JBoss + Tomcat), plutôt qu’aux historiques IBM et BEA Oracle. Là encore, étant donné la notoriété naissante de JRebel, au sein d’une communauté plutôt tournée vers l’open source, rien d’étonnant.

En revanche, il est intéressant de constater que les temps de redéploiement deviennent assez rapidement délirants, avec des serveurs qui en moyenne mettent entre 2 et 5 minutes à redémarrer, la palme de la lenteur revenant, on le savait déjà par expérience, aux gros serveurs monolithiques commerciaux. Alors, au-delà du constat qu’un développeur passe aujourd’hui une grande partie de son temps à attendre que son application se mette à jour sur son serveur d’applications, au-delà du fait que JRebel est une des manières d’adresser ce problème, nous nous posons la question suivante : est-il normal, pour un serveur d’applications, de mettre cinq minutes à redémarrer ?

L’actualité de cette revue de presse met en avant OSGI, qui sera certainement une des réponses apportées à cette explosion des temps de démarrage. Ce sont d’ailleurs les absents de cette étude qui porteront la première estocade : GlassFish 3.x et dmServer.

Premiers pas avec memcached

Dans le but de proposer une implémentation d’un système de cache pour Grails, James Goodwill, sur DeveloperWorks, propose, dans un premier temps, une découverte du système de cache distribué memcached.
Une mise en bouche qui permet de découvrir les bases de ce produit, avant de combiner ce cache avec Grails dans une seconde partie, qui, on l’espère, permettra d’optimiser les performances du plus célèbre des frameworks haute productivité.

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

Soirée Tontons Flexeurs le 24 Septembre

Suite des Tontons Flexeurs, après la très bonne soirée Flex et Java en entreprise, avec une nouvelle session ce jeudi 24 septembre. 2 invités de marque : Mike Chambers et Lee Brimelow qui nous feront une présentation d’Adobe AIR (techniques avancées de synchronisation de données, de manipulation de fichiers, possibilités d’intégration à la plateforme hôte…) et des nouvelles fonctionnalités des prochaines versions de AIR.

A l’heure où nous écrivons ces lignes, il reste encore quelques places disponibles donc rendez-vous sur le formulaire d’inscription de l’évènement.

Actualité éditeurs / SSII

• Les standards du Cloud Computing en préparation
• Fin de JavaRebel, place à …

RIA

• GWT 1.7 pour les nouveaux navigateurs !
• Flex Monkey 1.0

SOA

• La base de données dans une Event Driven Architecture
• REST et les abus de langage

Le coin de la technique

• OpenDS passe en version 2.0
• 10 bonnes raisons de chercher le successeur de Java

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

• Soirée Tontons Flexeurs

Actualité éditeurs / SSII

Les standards du Cloud Computing en préparation

Comme pour tout marché émergeant, le Cloud Computing s’est développé autour de technologies propriétaires mises au point par différents éditeurs et fournisseurs. Une session dédiée aux problématiques d’intégration lors du CloudCamp Paris avait conclu qu’aucun standard adapté n’était disponible pour permettre le transfert d’informations entre les différents fournisseurs et technologies du Cloud Computing.

Le monde du Cloud Computing montant en puissance mois après mois, la problématique de standardisation se fait de plus en plus pressante. C’est donc sans surprise qu’on a assisté à la constitution d’organismes de standardisation et de groupes de travail afin d’établir les standards à venir. Afin de donner une visibilité à l’ensemble de ces efforts, l’Open Grid Forum (OGF) annonce la création d’un site commun ou chaque organisme est invité à présenter ses travaux en cours : http://cloud-standards.org. On notera particulièrement deux spécifications prometteuses :

• Open Virtualization Format (OVF) : Format de packaging d’application permettant la distribution et le déploiement simplifié sur environnement virtualisé.
• Open Cloud Computing Interface (OCCI) : API standardisée permettant la définition, le provisioning et le monitoring d’infrastructures exposées en tant que services sur un Cloud (IaaS).

Par ailleurs, l’Open Cloud Consortium (OCC) explique travailler sur des frameworks d’interopérabilité entre Clouds et l’OASIS expose quant à elle sa vision selon laquelle le Cloud Computing est une extension naturelle des concepts SOA, et que, par conséquent, de nombreux standards qu’elle développe actuellement intègrent cette problématique.

Fin de JavaRebel, place à …

Zeroturnaround, l’éditeur de JavaRebel, doit faire face à un joli défi : pour avoir fait une entorse à la marque déposée Java, il doit modifier le nom de son produit, sans pour autant perdre la notoriété d’ores et déjà acquise. Pour faire d’une pierre deux coups (modifier effectivement ce nom mais aussi s’offrir un joli coup de pub), l’éditeur soumet ce renommage à un concours. En jeu, une licence JavaRebel à vie…

RIA

GWT 1.7 pour les nouveaux navigateurs !

Les dernières releases de GWT étaient plutôt espacées dans le temps (1 an entre 1.4/1.5 et 8 mois entre 1.5/1.6) mais il n’aura fallu attendre que 3 mois pour voir débarquer la version 1.6.5 1.7 de GWT.

Cette dernière version (définie comme mise à jour mineure / bugfix release) apporte un meilleur support des derniers navigateurs à savoir Internet Explorer 8, FireFox 3.5 et Safari 4 (meilleur support d’IE8 = disparition d’IE6 ? ).

L’ajout du user.agent ie8, qui peut potentiellement impacter certains projets, a fait pencher la balance vers un numéro de version de type majeure (1.7) pour forcer les développeurs à être attentif sur ce point important (une version de type 1.6.5 n’aurait pas eu le même impact).

Une simple recompilation suffit pour être compatible avec ces navigateurs, aucune modification de code n’est requise. Disponible comme toujours dans la section téléchargement du Google Code.

Flex Monkey 1.0

Plus de 7 mois après la sortie de la version 0.5 (précédente revue de presse), FlexMonkey, le framework de tests automatisés pour applications Flex et Air, se met à jour et passe ainsi en version 1.0 (par InfoQ).

Au menu : réorganisation de l’interface utilisateur, support direct d’applications Air (la console FlexMonkey devenant d’ailleurs une application Air) et tests générés pour Fluint (qui pourront aussi être lancés par FlexUnit 4).

Plusieurs tutoriels/exemples sont déjà disponibles sur la toile, on retiendra plus particulièrement le Getting Started d’Eric Owens (Gorilla Logic) et l’article très complet de Stuart Stern (CEO de Gorilla Logic et créateur de FlexMonkey) sur InfoQ.

SOA

La base de données dans une Event Driven Architecture

Sur son blog dédié aux traitements des évènements dans les systèmes d’informations, Tibco a publié un billet portant sur le positionnement d’une base de données dans une Event Driven Architecture (EDA).

Se trouvant à la base de nombreuses applications et services, elle constitue en effet une potentielle source d’évènements très intéressante. L’auteur met alors en avant la technologie Continuous Query Notification (CQN) intégrée à Oracle 11g, et qui permet aux clients d’une base de données de s’enregistrer pour recevoir des notifications lorsque les données d’une table ou le résultat d’une requête prédéfinie changent. On peut assimiler cette technologie à un mécanisme de trigger qui rappellerait des systèmes externes.

Cette possibilité permet ainsi d’enrichir les sources d’évènements disponibles au sein du système d’information : de par son positionnement, la base de données est capable d’offrir simplement des évènements qui seraient parfois complexes à générer au niveau applicatif. Dans une telle configuration, le Complex Event Processing (CEP) permettra alors de manipuler le volume important d’évènements ainsi créés afin d’en extraire des informations métiers utiles.

REST et les abus de langage

Ryan McDonough, contributeur au projet RESTEasy, a publié un billet dans lequel il fait un parallèle entre les abus de langages liés à REST et les mauvaises pratiques qui en découlent.

Parmi les erreurs de compréhension qu’il met en avant, on retrouve l’assimilation de REST à un protocole, la définition de REST en tant que synonyme de HTTP, ou encore l’utilisation abusive du qualificatif RESTful.

Il est souvent question lorsque l’on parle de REST de définition d’URLs, de représentations multiples d’une ressource, ou, plus couramment encore, d’opposition à SOAP. Loin de ces problématiques, Ryan McDonough met ici en avant le fait que REST est dans la réalité trop souvent utilisé pour justifier à tort tout type d’utilisation douteuse de JSON ou XML sur HTTP…

A ce titre, le livre RESTful WebServices de Leonard Richardson et Sam Ruby permet de comprendre en détail toutes les nuances de ce modèle d’architecture qui sont parfois délicates à appréhender.

Le coin de la technique

OpenDS passe en version 2.0

La version 2.0 du projet OpenDS est disponible. Il s’agit d’un serveur LDAP implémenté entièrement en Java et soutenu par Sun ; ces caractéristiques le positionne donc directement face à Apache Directory Server, son équivalent développé par la fondation Apache.

Ludovic Poitou présente les principales nouveautés de cette version :

• Ajout d’un control panel graphique, en remplacement du status-panel de la version précédente, permettant d’administrer le serveur et ses données
• Amélioration de la réplication multi-master
• Support de connections sécurisées SASL
• Affinement du système de contrôle d’accès
• Amélioration des performances. On notera sur ce point la collaboration avec l’équipe du garbage collector G1 qui avait été exposée il y a 2 mois

Au delà de l’ajout de fonctionnalités, la question du positionnement reste entière pour OpenDS tout comme pour son rival ApacheDS. En effet, l’annuaire est en général une ressource critique du système d’information pour laquelle on préfèrera généralement une implémentation native plus mature. Dès lors, OpenDS se destinera principalement au poste de développement, aux tests, et aux applications embarquant directement leur propre annuaire comme mécanisme de persistance.

10 bonnes raisons de chercher le successeur de Java

Dans la droite ligne d’un certain nombre de keynotes récentes, Mario Fusco expose, sur TheServerSide, 10 bonnes raisons de chercher un héritier à Java. Ces ‘manques’ de Java sont souvent évoqués, parfois partiellement comblés par les futures spécifications. Il nous a semblé malgré tout intéressant de les reprendre ici, ne serait ce pour que ces limitation soient bien comprises de tous.

• Absence de Closures, et son corollaire, l’absence de pointeur sur les fonctions (first-class function).
• L’existence de types primitifs (le langage n’est pas 100 % objet), et un autoboxing pas toujours performant (sur la gestion des null par exemple).
• La faiblesse des Génériques : impossible de découvrir leur type au Runtime.
• L’impossibilité de supprimer certains warnings concernant les génériques.
• Impossible de passer un paramètre void à une méthode.
• Le pattern proxy n’est pas implémenté de manière native sur les classes concrètes.
• Le switch…case est très faible
• La présence des exceptions Checked qui obligent à de douloureux try...catch ou à d’illisibles throws

Mario Fusco a l’honnêteté de reconnaitre que nombre de ces défauts font partie des péchés originels de Java et qu’il est quasiment impossible de les remettre en cause sans gravement compromettre la compatibilité ascendante du language, qui en est une des pierres angulaires. C’est pour cette raison qu’il se met en quête du next gen language

Vous ne manquerez pas de remarquer que, comme tout article qui parle de succéder à Java, ce billet est richement (parfois de manière assez virulente) commenté.

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

Soirée Tontons Flexeurs

Demain (mardi 21 Juillet) de 18h à 20h se déroulera une nouvelle soirée des Tontons Flexeurs dont le sujet est un retour d’expériences sur la mise en place d’applications Flex en entreprise dans le monde Java (tests unitaires/fonctionnels, intégration continue…).
L’événement étant déjà complet, il ne vous reste plus qu’à bookmarker leur calendrier pour être informé des prochaines réunions

Actualité éditeurs / SSII

• Grails 1.1.1 supporté par Google App Engine

Agilité

• SCRUM en vidéo en 5 minutes

SOA

• REST : Le bon et surtout le moins bon …

Le coin de la technique

• Utiliser Selenium Grid avec Hudson
• Une API Criteria pour JCR
• Intégration simple de GWT et Spring
• 8 bonnes pratiques pour améliorer scalabilité et performances

Actualité éditeurs / SSII

Grails 1.1.1 supporté par Google App Engine

Dans une précédente nouvelle, nous avions annoncé la sortie de Google App Engine pour Java et Groovy. Après Struts2, Spring MVC, le support de nombreux frameworks web continue.
Le framework web Grails, basé sur le langage Groovy et développé par l’équipe de Spring est maintenant supporté par App Engine. Des ajustements ont été apportés pour le rendre compatible, d’où la sortie de cette version 1.1.1.. Celle ci apporte aussi des corrections de bugs, dont la liste est disponible ici.
Par ailleurs, un plugin a été développé pour faciliter l’intégration de Grails avec le SDK de App Engine, notamment au niveau du déploiement du serveur web.

L’objectif fixé par SpringSource est que Grails devienne le framework web le plus utilisé avec Google App Engine, d’où les nombreux efforts fournis. Les prochains axes de travail porteront sur l’abstraction de JPA/JDO pour faciliter l’utilisation du data store (base de données) d’App Engine.

Agilité

SCRUM en vidéo en 5 minutes

Tout simplement géniale, cette vidéo fait le tour de la blogosphère SCRUM / Agile : Le retour de 6 mois d’expérience d’une équipe SCRUM.

Tout y est :

• L’équipe.
• Les cérémonies.
• Les artefacts.
• Le fun.

La réalisation très soignée et la BO ne gâchent rien.

A regarder !

SOA

REST : Le bon et surtout le moins bon …

Dans l’article « REST – The Good, The Bad and The Ugly« , publié sur DZone, Arnon Rotem-Gal-Oz propose un éclairage intéressant de ce qu’il y a de bon et surtout de ce qu’il peut y avoir de moins bon lors de la mise en place d’une architecture REST.
On retiendra de cette déclinaison deux travers récurrents dans la mise en œuvre de REST :

• Limiter REST à REST over HTTP : Ce raccourci appauvrit en effet dramatiquement les possibilités que nous offre la mise en place d’une architecture REST
• Limiter REST à l’utilisation du GET et du POST : Ici encore, n’utiliser qu’une sémantique à 2 verbes nous prive de la richesse dont nous pourrions profiter.

Comme pour beaucoup d’autres sujets (les méthodes agiles, les SOA, …), la mise en place d’architectures REST nécessite un changement d’approche et de façon de penser : REST implique une approche orientée ressources qui ne nous est pas naturelle. Il est donc primordial de ne pas bruler les étapes et de faire l’effort du changement avant de pouvoir bénéficier des promesses de REST.

Le coin de la technique

Utiliser Selenium Grid avec Hudson

Depuis 2006, Hudson offre un plugin Hadoop permettant d’utiliser son cluster Hudson pour effectuer des traitements lourds de type MapReduce.

Selenium Grid, d’autre part, est une solution permettant de distribuer un ensemble de tests Selenium sur plusieurs machines, permettant ainsi de ramener leur temps d’exécution à un ordre de grandeur plus propice à l’intégration continue.

Kohsuke Kawaguchi, créateur du projet Hudson, vient d’annoncer la disponibilité d’un plugin Selenium Grid. Outre l’intégration à Hudson, facilitant le démarrage automatisé des tests, ce plugin présente l’intérêt de simplifier la configuration, puisqu’il s’appuie sur l’infrastructure cluster d’Hudson.

Il s’agit là d’une avancée qui devrait permettre de rendre plus accessible et moins coûteuse l’exploitation quotidienne de larges quantités de tests d’intégration. Parmi les perspectives d’avenir pour la pleine utilisation d’un cluster Hudson, on notera également une très intéressante proposition sur le Jira du projet Hadoop visant à créer un distributed JUnit TestRunner.

Une API Criteria pour JCR

Magnolia est un CMS en Java qui repose sur la technologie JCR (Java Content Repository, JSR-170) pour assurer la persistance versionnée des informations qu’il présente.

JCR, dans sa version 1.0, propose deux possibilités pour exécuter des requêtes sur son repository de contenu : XPath, supporté en standard, et SQL, dont le support est défini comme optionnel par la spécification JCR.

Dans ces deux cas, les requêtes se font en mode texte. Dans certains cas d’utilisation, tels que les recherches multi-critères, cela peut amener le développeur à créer une logique de construction de requêtes par concaténation. Avec Hibernate, ce genre de problématique est adressée par l’API Criteria qui rend le développement de ce type de besoin trivial.

Partant de ce constat, les développeurs de Magnolia proposent une librairie utilitaire permettant la construction de requêtes JCR par programmation. Cette librairie repose sur Magnolia mais pourrait être adaptée pour devenir standalone.

Ceci préfigure de ce que JCR 2.0 (JSR-283), actuellement en statut proposed final draft, s’apprête à offrir : les requêtes pourront être définies de manière objet grâce à l’API JCR-JQOM (JCR Java Query Object Model). Apache Jackrabbit, l’implémentation de référence, supporte déjà partiellement JQOM.

Intégration simple de GWT et Spring

Et même super simple selon l’article de Dev Bright qui dans son exemple s’appuie sur le projet gwtrpc-spring (qui nous permet par la même occasion de tester une autre librairie que GWT-SL, la librairie référence des projets GWT actuels). L’article est d’autant plus intéressant qu’il utilise les annotations pour déclarer les services auprès de Spring.

Les services seront accessibles par une URL qui possèdera une extension spécifique qui sera mappée dans le web.xml. Cela évite ainsi une multitude de servlets dans le web.xml. Ici il n’y aura qu’une seule servlet mais qui mappera toutes les extensions de type .rpc.

Le service :

@RemoteServiceRelativePath("myservice.rpc")
public interface MyService extends RemoteService {
   String myMethod(String arg);
}

Le web.xml :

<web-app>
   <servlet>
      <servlet-name>dispatcher</servlet-name>
      <servlet-class>org.gwtrpcspring.RemoteServiceDispatcher</servlet-class>
   </servlet>
   <servlet-mapping>
      <servlet-name>dispatcher</servlet-name>
      <url-pattern>*.rpc</url-pattern>
   </servlet-mapping>
   <listener>
      <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
   </listener>
</web-app>

Pour le fichier de configuration Spring, il suffit d’activer la configuration par annotation et de donner le package à scanner :

<beans ...>
   <context:annotation-config>
      <context:component-scan base-package="org.gwtrpcspring.example.server" />
   </context:annotation-config>
</beans>

Du coup, plus aucune configuration XML, l’annotation @Service finit le travail :

@Service
public class MyServiceImpl implements MyService {
   public String myMethod(String arg) {
      // You impl...
   }
}

En quelques lignes et très peu de configuration, l’auteur a créé une application GWT, Spring, avec annotation et avec un web.xml bindant tous les appels RPC. L’avantage dans cette configuration est que les fichiers XML de configuration n’évolueront pas (sauf ajout de nouveaux packages).

Le projet est récupérable à cette url.

8 bonnes pratiques pour améliorer scalabilité et performances

Wille Faler donne 8 conseils pour optimiser la scalabilité de vos applications.

• Déchargez la base de données : la base de données relationnelles est le plus courant des goulets d’étranglements sur nos applications.
• Utilisez des caches : cacher est un moyen simple d’appliquer le point précédent.
• Cachez des objets complexes : même si des objets ‘à maille fine’ sont stockées, cacher des entités plus complexes permettra de moins solliciter les ressources lors d’une recherche dans le cache, et de ramener plus rapidement une grappe d’objets complète.
• Ne sauvez pas d’état en base : ne doivent persister que les données business (pas d’informations de login, de session…)
• Réfléchissez à la spacialisation : placer les données au plus près de là où elles doivent être utilisées (en utilisant un CDN par exemple)
• Restreignez les accès concurrents aux ressources sensibles : il est plus performant d’adopter une attitude ‘un seul thread à la fois’
• Abusez de l’asynchrone pour fractionner vos process : séparez vos traitements en petites unités, traitées par des workers distincts; afin d’éviter un phénomène d’engorgement généralisé.
• Ne surchargez pas le réseau : sortir de votre runtime applicatif est couteux en temps, limitez donc les échanges avec les systèmes tiers.

Certains diront ‘encore un article de bonnes pratiques performance’… Pour notre part, sorti des grands classiques (base de données, réseaux…), nous avons apprécié deux conseils plutôt originaux : le caching d’entités complexes, et la spacialisation.

Actualité éditeurs / SSII

• JBoss AS 5, ce fut long mais c’est parti
• SpringSource tc Server : un dm Server sans ses modules
• Quoi de neuf dans Spring 3.0 M1 ?
• Sortie de Spring Integration 1.0.0
• Sortie d’Hibernate Search 3.1

Agilité

• L’agilité chez IBM

RIA

• Au pied du sapin : JavaFX GA
• Silverlight sous Linux

Le coin de la technique

• Nouveau mode hosté pour GWT 2.0

Actualité éditeurs / SSII

JBoss AS 5, ce fut long mais c’est parti

Sacha Labourey, CTO de JBoss, nous avait parlé lors de sa venue au Paris JUG la semaine dernière de l’imminence de cette annonce que la communauté attendait depuis longtemps : JBoss AS 5 est enfin releasé !

Les principaux composants de JBoss AS 5

• JBoss Micro Container (MC) : remplaçant du JMX Kernel, MC est le conteneur du serveur d’applications. Il offre le cycle de vie des différents modules (installation, démarrage, arrêt, désinstallation).
• JBoss Messaging (JMS) : déjà utilisé dans JBoss AS 4, JBoss Messaging est le successeur de JBoss MQ. La version 2 de JBoss Messaging est en cours de développement; les synergies avec Red Hat Messaging sont prévues ; les efforts pour faire converger les deux middlewares de message seront vraisemblablement importants.
• JBoss Transaction : issu du rachat d’Arjuna Transaction Service en 2005, ce composant mature n’a pas connu d’évolution significative avec AS 5.
• JBoss WS : stack Web Service ; la multiplicité de ses implémentations SOAP (native, adapteur pour Glassfish Metro ou pour Apache CXF) rend compliquée la compréhension de ce composant.
• Clustering : la haute disponibilité et la réplication reposent sur le mature et dynamique JBoss Cache (aujourd’hui en version 3) qui repose lui-même sur la librairie de communication multicast JGroups.
• JBoss Web : fort de son long passé de commiter Tomcat, JBoss package sa version optimisée du moteur de servlet de la fondation Apache.

Pourquoi JBoss a-t-il mis autant de temps à sortir cette version ? Des difficultés pour implémenter Java EE 5 ?
JBoss n’a pas eu de difficultés particulières à implémenter les EJB 3 ou JPA qui étaient déjà disponibles dans JBoss AS 4.2. Java EE 5 est la partie émergée de l’iceberg AS 5. Ce qui a pris du temps à JBoss est la refonte complète de son serveur d’applications. Les fonctions structurelles du middleware (transactions, clustering, messaging, sécurité, administration, etc.) sont désormais séparées des applications déployées qui peuvent être packagées au format Java EE mais aussi OSGi, Spring, Ruby On Rails ou tout autre format dès lors qu’un deployer (i.e. adaptateur) est disponible.

JBoss Micro Container est-il une victime du syndrome Not Invented Here ?
La réponse est complexe et le choix de JBoss plein de mesure. Le projet MC a été lancé alors que la bataille (plus politique que technique) entre Java Module System et OSGi faisait rage. Sun misait sur le projet HK2 pour son serveur Glassfish et s’est finalement rabattu sur le conteneur OSGi Apache Felix. SpringSource a tellement amélioré OSGi que le résultat rendait OSGi méconnaissable (adieux les ServiceTracker et autres Declarative Services) ; le pari a réussi et Spring dm Server est en cours de standardisation par l’OSGi Alliance sous le nom de Blueprint Component Model. JBoss, pourtant habitué des contributions aux standards Java (cf. JPA, Web Beans, etc.) a cette fois ci préféré commencer cavalier seul avec un Micro Container qui supporte OSGi comme il aurait pu supporter Java Module System.

Si JBoss AS 5.0 est une refonte complète, il risque d’être buggué
Le risque n’est pas nul, mais nous remarquerons que la plupart des composants fondamentaux sont matures et n’ont pas été impactés par la refonte 5.0 (transactions, messaging, etc.).

Le chantier AS 5 a-t-il été trop ambitieux ?
Les autres serveurs d’applications ont déjà été refondus (Websphere 6.1) ou sont en cours de refonte (Glassfish 3). Cette remise à plat était importante. Cependant, JBoss a pris beaucoup plus de temps qu’il ne le prévoyait et a dû changer certaines méthodes de travail pour atteindre son objectif. Sacha Labourey a notamment expliqué que le mécanisme de build a été changé en cours de route et que le travail open source collaboratif à distance par forum/mailing-list interposés avait touché ses limites.

Les clients ont-ils perdu patience ? Ont-ils changé de serveur ?
Les clients ont sûrement été déçus par l’attente mais pas tellement plus que les clients Websphere et JBoss AS 4 proposait déjà les EJB 3 et JPA. Ensuite, Glassfish a surement pris des parts de marché à JBoss AS mais c’est plus probablement lié à l’essor de Glassfish qui se fait au détriment de ses concurrents JBoss, Websphere et Weblogic.

En conclusion, JBoss AS 5 est une bonne nouvelle pour l’Open Source Java et rappelle la vitalité du modèle économique du Professional Open Source que JBoss a contribué à inventer.

SpringSource tc Server : un dm Server sans ses modules

L’actualité Spring est particulièrement riche cette semaine : SpringSource a annoncé lors des conférences de SpringOne Americas l’arrivée prochaine d’un nouveau serveur d’applications : le tc Server. Non, il ne s’agit pas d’un second renommage de leur dm Server, mais bel et bien d’un nouveau produit. Comme son nom l’indique, tc Server n’est ni plus ni moins qu’un Tomcat gonflé en fonctionnalités et en support, permettant de répondre aux problématiques de production.

Selon SpringSource, ce nouveau serveur est destiné à trois types d’utilisateurs :

• Les utilisateurs de Tomcat, désireux d’acquérir du support en production et/ou des fonctionnalités supplémentaires d’aide à la configuration et de diagnostics.
• Les utilisateurs de serveurs d’applications JEE qui n’utilisent pas d’EJB, désireux de migrer vers une solution plus légère.
• Les futurs utilisateurs de dm Server, désirant modulariser leur application.

Par ailleurs, SpringSource a récemment annoncé dans sa roadmap une compatibilité Tomcat dans sa prochaine version de dm Server (Jersey) prévue pour Q2 2009. À terme, ces deux serveurs ne risquent-ils pas de se marcher dessus ? Vu de l’extérieur, cela donne l’impression que ce nouveau tc Server a été créé dans le but de rassurer les utilisateurs : pas besoin d’être modulaire pour tourner sur une plateforme SpringSource.

Ce chevauchement dans l’offre nous laisse entrevoir une stratégie intéressante de la part de SpringSource :

1. Attirer en douceur les utilisateurs via un simple support Tomcat avec tc Server.
2. Les aiguiller par la suite vers une solution plus complète basée sur dm Server.

Pour cela, Spring compte tout d’abord mettre en avant ses fonctions Java EE classiques (monitoring avancé, transactions distribuées), puis, dans un deuxième temps, ouvrir le développement sur un modèle de composants Spring Module. Tout l’enjeu de cette stratégie est de convaincre les exploitants. Une fois que dm Server sera suffisamment bien implanté, les développeurs devraient se mettre à déployer leurs propres modules OSGi.

Cette distinction, techniquement non nécessaire, nous montre encore à quel point la monétisation du libre et la vente de support restent difficiles. La tarification des services reste au centre de la stratégie (et c’est bien compréhensible) : avec ce nouveau serveur, SpringSource nous propose également une nouvelle grille de tarifications allégée.

Quoi de neuf dans Spring 3.0 M1 ?

Le premier milestone du Spring nouveau est arrivé, annoncé par Jurgen Holler ce vendredi sur son blog. Comme nous l’annoncions dans une précédente revue de presse, Spring 3.0 M1 sort avec un léger retard par rapport à la roadmap Spring prévue.

Utilisateurs de Spring 2.5, les nouveautés apportées par cette nouvelle version ne devraient pas vous dépayser : peu de nouveautés fonctionnelles, mais un gros travail de refactoring interne.

Modifications techniques internes :

• Migration de gestionnaire de source : CVS vers SVN, dont voici l’adresse.
• Refactoring du projet en modules, le trunk contient une vingtaine de sous projets : org.springframework.core, org.springframework.aop, org.springframework.expression …
• Chaque module est commité avec sa configuration Eclipse prête à l’emploi, vous trouverez donc les .project, .classpath et même les répertoires .settings directement sur le svn.
• Vous y trouverez également les fichiers de configuration de build Ivy et un début de configuration Maven. Cette dernière n’est probablement pas fonctionnelle : les derniers commits datent de fin d’octobre pour les fichiers Maven, alors que des modifications ont été effectuées plus récemment fin novembre sur la configuration Ivy. D’ailleurs, les .classpath ne vous y tromperont pas, ils contiennent tous la variable d’environnement IVY_CACHE.
• Refactoring des sources, chaque module utilise maintenant les fonctionnalités Java 5, le code interne en est simplifié.
• Montée de version des tiers frameworks : JRuby 1.1 et JUnit 4.5. La montée de version de JUnit simplifie l’utilisation de ses extensions.

Nouvelles fonctionnalités :

• Arrivée de Spring EL utilisable dans n’importe quel composant Spring (y compris ‘core’). Vous pouvez par exemple utiliser la syntaxe #{ … } lors de la définition de vos beans (XML et/ou annotations) pour permettre de définir au runtime la valeur de certaines propriétés de vos beans prototypes.
• Support de REST intégré dans Spring MVC.
• … le reste à venir dans les milestones M2 et M3 qui suivront, prévus pour Q1 2009.

Nous avions également publié un article en octobre présentant les principales nouveautés de Spring 3.0.

Sortie de Spring Integration 1.0.0

La version 1.0.0 GA de Spring Integration, le « light weight ESB«  de SpringSource a été annoncée cette semaine lors du dernier SpringOne Americas.

Comme nous l’expliquions dans notre Introduction à Spring Integration, cette implémentation légère des Enterprise Integration Patterns vise à simplifier le développement de solutions d’intégration d’entreprise et à faciliter l’adoption par les utilisateurs de Spring des principes EDA (Event Driven Architecture).

Sortie d’Hibernate Search 3.1

La version 3.1.0 d’Hibernate Search a été mise à disposition cette semaine. Comme l’explique Emmanuel Bernard dans l’article « Hibernate Search 3.1 is out: performance, robustness and new features on the menu« , cette nouvelle version met l’accent sur l’amélioration des performances, la robustesse du code et l’utilisabilité.

Comme nous l’expliquions dans notre Introduction à Hibernate Search, Hibernate Search est un moteur d’indexation et de recherche full-text reposant sur Apache Lucene. Il prend ainsi en charge la gestion d’un index Lucene et sa synchronisation avec une structure objet persistée en base de données.

Agilité

L’agilité chez IBM

Scott Ambler, responsable du développement agile chez IBM, a été interviewé par InfoQ sur l’état présent de l’agilité et son futur.
En se basant sur l’étude 2008 de Dr. Dobb’s, il rappelle que 69% des organisations font au moins un projet agile. L’agilité est une réalité. Le TDD fait aussi parler de lui mais ceux qui le pratiquent sont moins nombreux.

Une autre étude a montré que les équipes agiles font autant de documentation que les équipes traditionnelles, et même plus de modélisation upfront (88% des équipes agiles), que ce soit sur papier ou avec des outils plus sophistiqués.
Abordant les problèmes liés à l’introduction de l’Agilité dans les grandes équipes, Scott cite les 2 points les plus courants qui sont les équipes de grande taille (5000 ?) et les équipes distribuées. Il ajoute un 3e point : la gouvernance.
L’Agilité permet une gouvernance plus efficace que les projets traditionnels, en laissant le contrôle du périmètre, du budget et de l’agenda aux intervenants (stakeholders).
Concernant les équipes distribuées, l’étude du Dr Dobb’s rapporte le succès des projets mesuré par leurs clients :

• équipes colocalisées : 83%
• équipes proches (étages différents, bâtiments différents) : 72%
• équipes distribuées (qui nécessitent l’avion) : 60%

Scott conseille donc d’éviter les équipes distribuées. Si l’on ne peut vraiment pas, il conseille d’organiser les équipes en fonction de l’architecture afin de minimiser la communication entre les différents lieux. Cela nécessite notamment un « architecture owner », responsable de l’architecture, mais qui ne reste pas dans sa tour d’ivoire comme on peut en voir sur certains projets.

L’autre conseil pour les équipes distribuées est de s’équiper de bons outils. Il présente le nouveau produit Rational Team Concert, basé sur Eclipse et la plateforme Jazz, qui facilite la collaboration de l’équipe.

Pour finir avec le futur de l’agilité, Scott reprend son analogie avec l’astronomie :

• Avant on pensait que « tout tourne autour de la Terre ». C’est la communauté traditionnelle qui pense que « tout tourne autour de l’engineering et de la documentation ».
• Aujourd’hui la communauté agile pense que « tout tourne autour du soleil », c’est-à-dire « autour du développeur ».
• Demain nous verrons comme Newton que « tout tourne autour de tout ». Nous devons avoir une vision entreprise et non par silo.

Avoir une vue d’entreprise sur l’informatique est extrêmement difficile, mais nécessaire pour construire des applications de niveau entreprise et de haute qualité.

RIA

Au pied du sapin : JavaFX GA

Après presque 2 ans d’attente, JavaFX est enfin disponible en version finale. Enfin pas tout à fait : JavaFX Mobile, initialement dans le scope de cette première version, est repoussé à février 2009, et les OS Linux et Solaris ne sont pas (encore) supportés.
Cette version 1.0 tient elle malgré tout les promesses entrevues lors de la parution de la preview ?
Et bien, pas vraiment.
Les défauts rédhibitoires que nous y avions décelés sont toujours là : le seul IDE de développement disponible est Netbeans (sans même l’inclusion d’un éditeur graphique), les composants graphiques de haut niveau (hormis les portages Swing) manquent toujours à l’appel…
Qu’est ce qu’apporte vraiment cette version 1.0 ? A première vue, l’effort a été porté sur la documentation : la Javadoc a été mise à jour et est relativement complète. La galerie d’exemples et de tutoriaux ‘officielle’ a été copieusement alimentée. On regrettera cependant que cette galerie mette l’accent sur le spectaculaire, plus que sur le fonctionnel (aucun exemple d’intégration avec un back end Java ou une base de données).
Au rayon des nouveautés, on notera la présence de codecs audio et video, permettant d’intégrer facilement du contenu multimédia (par l’entremise d’un encodage en Flash).
Sur un niveau moins technique, on peut noter la présence de 2 plugins pour les produits Adobe, Photoshop et Illustrator, qui devraient faciliter les échanges entre web designers et développeurs J2EE.
A noter enfin, sur un plan plus marketing, la présence d’un émulateur mobile, qui préfigure ce que pourrait être JavaFx Mobile.
En conclusion, cette première version n’est pas vraiment au niveau des attentes qu’elle a suscitées. Cependant, nous restons une fois de plus sur l’agréable impression de pouvoir faire de jolies interfaces en Java.
A notre sens, la prochaine étape déterminante sera l’adhésion de la communauté à cette nouvelle technologie, qui devrait permettre l’émergence de composants de haut niveau (un travail auquel s’est déjà attelé James Weaver), en espérant que ceux ci seront incorporés dans les prochaines versions.
Reste que le produit de Sun est en retard par rapport à ses concurrents, et que la volonté de couvrir toutes les plateformes à la fois (desktop, mobile, télévision) pourrait se révéler à court terme un handicap pour cette technologie émergente.
Alors, Sun s’est il fourvoyé avec Fx, comme le pense Tim Bray ? Seules les futures versions nous le diront.

Silverlight sous Linux

La version 1.0 beta de Moonlight est disponible.
Moonlight est une implémentation open source de Silverlight pour Linux / Unix, portée par Novell et développée par le projet Mono. Cette béta est disponible pour un grand nombre d’environnements (Ubuntu, Suze, Fedora…) en 32 ou 64 bits.
Elle permet l’exécution de scripts Silverlight 1.0, la diffusion de contenu (MediaPack 1.0)…
Elle sera disponible en version finale le 20 janvier 2009.
Pour pouvoir profiter au maximum de Silverlight sous Linux, il faudra attendre la version 2 de Moonlight (support complet de Silverlight 2.0 et des dernières innovations Microsoft). Elle devrait être disponible en béta courant avril, puis en finale durant septembre 2009.
La roadmap complète est exposée sur le site du projet Mono.

Le coin de la technique

Nouveau mode hosté pour GWT 2.0

Les nouveautés des prochaines versions 1.6 et 2.0 de GWT continuent d’affluer.
Ainsi, après la possibilité de pouvoir fragmenter son application, c’est une fois de plus chez Sami Jaber que l’on apprend en vidéo l’une des grosses fonctionnalités à venir : le nouveau « Hosted Mode » de GWT 2.0.
Alors qu’aujourd’hui ce mode se lance dans une nouvelle fenêtre de votre IDE, demain vous pourrez le lancer directement dans votre navigateur (en tout cas ceux gérés pour l’instant).
Le mode reste toutefois celui que l’on connaît à savoir que GWT simule un site compilé (moteur de rendu) i.e. qu’aucun Javascript n’est généré. L’intégration avec des plugins comme Firebug sera donc limitée… Le mode Debug et le rafraichissement du navigateur suite à modification du code GWT sont bien sûr conservés.

L’actualité battant son plein, vous aurez certainement noté la nouvelle mise à jour de la politique de maintenance effectuée par SpringSource hier soir incitant la communauté open-source à migrer vers les nouvelles versions de son framework. Ainsi, à publication de Spring 3.0 RC1, plus aucun tag ne sera effectué sur la branche 2.5.x.

Restructuration de Spring Core

Exit le JDK 1.4

La première des nouveautés n’est pas fonctionnelle, mais purement technique. Spring a décidé de laisser tomber une fois pour toutes le JDK 1.4. La refonte de Spring Core dépendra donc dorénavant des fonctionnalités du JDK 5.

Cette décision va certainement en choquer certains, mais il ne faut pas oublier que le JDK 5 est sorti il y plus de 3 ans et qu’il est supporté par tous les serveurs d’applications du marché depuis bien longtemps. De plus, cette refonte coïncide avec l’annonce de Sun du passage du JDK 1.4 en End Of Service Life (EOSL) à la fin du mois.

En fait, rien de vraiment étonnant : Spring prépare le terrain depuis sa version 2.5, dont les principales nouveautés s’appuyaient sur les notions introduites par le JDK 5. Certains modules dépendaient déjà de celui-ci. Cette généralisation à Spring Core en est la suite logique. Quitte à faire une cure de jouvence, autant profiter des avancées techniques.

Nettoyage de printemps

Spring profite de cette refonte pour se débarrasser de tout ce qui était précédemment déclaré deprecated. Ce choix n’est pas facile pour tout le monde : n’oublions pas que Sun traîne dans son JDK certaines méthodes deprecated depuis plusieurs années qui ne sont pas prêtes d’être retirées. Rod Johnson a d’ailleurs lancé des appels dans ce sens pour nettoyer JavaSE et JavaEE.

La liste complète des interfaces, classes et méthodes deprecated est disponible sur la Javadoc de Spring 2.5, où les destinées de ces différents éléments sont renseignées. Seront par exemple supprimées dans Spring 3.0 :

• AbstractPathMapHandlerMapping, CommonsPathMapHandlerMapping, PathMap, remplacées par les annotations permettant de mapper les requests.
• ServerSessionMessageListenerContainer, SimpleServerSessionFactory, au profit des beans DefaultMessageListenerContainer et JmsMessageEndpointManager.
• …

D’autre part, ce coup de balai terminé, Spring profite également de cette refonte pour déprécier certains cas d’utilisation et technologies quelque peu archaïques.

Seront probablement rendus deprecated :

• L’intégration avec la hiérarchie de classe de JUnit 3.8
• La hiérarchie de classe des contrôleurs de Spring MVC, remplacée par les annotations @Controller
• Et probablement certaines classes liées à HibernateTemplate et JPATemplate

En plus de cela, un certain nombre de fonctionnalités seront extraites de Spring Core et placées dans des modules legacy.

Ces modules seront disponibles, au besoin, séparément :

• L’intégration avec l’API Apache Commons Attributes qui n’a plus beaucoup de sens dans un environnement Java 5.
• Les APIs spécifiques TopLink

Pour conclure sur cette première partie, par ce grand ménage, Spring compte donner un coup de jeune au cœur de son framework. Aussi nombreux et importants que soient ces changements, si tout se passe comme prévu, les utilisateurs ne se rendront probablement pas compte de cette restructuration. Spring nous annonce, comparé à Spring 2.5, un modèle de programmation identique et une rétrocompatibilité quasiment complète.

Ajout de fonctionnalités

Pour finir, voici quelques-unes des nouvelles fonctionnalités attendues pour Spring 3.0 :

• Spring EL à tous les niveaux : il vous sera possible d’utiliser les Expression Language dans n’importe quel module de Spring. Cela vous permettra par exemple de définir des propriétés dont les valeurs seront fixées au runtime lors de la création du bean. Les EL seront aussi bien utilisables à partir des fichiers de configuration que par les différentes annotations @Value(#{anotherBean.anotherProperty})
• Support de REST via Spring MVC : cette fonctionnalité devrait être disponible dès le premier milestone de Spring 3.0. Elle sera également accompagnée de nouveau type de vues JSON, XML ou ATOM, nous rappelant ce que font certains frameworks concurrents (dont Grails). Comme nous l’avons annoncé dans une récente revue de presse, nous espérons que Spring 3.0 supporte l’intégralité de la JSR-311 : Java API for RESTful Web Service nouvellement terminée.
• Support des Portlets 2.0 : les premiers tests et développements ont apparemment commencé en utilisant le conteneur Pluto. Le support de cette JSR-286 : Portlet Specification 2.0 permet d’espérer l’apparition de fonctionnalités très attendues dans le monde des portlets, telles que la demande de ressources et communication inter portlets via événements
• Validation du modèle via annotations : depuis Spring 2.5 l’ancien modèle de validation parait un peu dépassé. Pour sa version 3.0, Spring nous propose de revoir tout cela avec l’arrivée de nouvelles annotations. On peut espérer une compatibilité avec la JSR-303, sujet fortement influencé par JBoss. Une intégration forte avec Spring MVC et Spring JS est également attendue.
• Un nouveau scope : la conversation. Présent dans Spring WebFlow, ce nouveau scope sera rendu disponible dans Spring Core.Il se basera sur une API spécifique pour ouvrir et terminer programmatiquement les conversations. Une conversation peut se comparer à une sous-session spécifique à un process. Avec ce nouveau scope, l’utilisateur pourra associer des objets dont la durée de vie dépendra d’un ensemble défini d’actions. Lorsque ce processus se terminera, les objets liés à celui-ci seront supprimés.

Les développements n’étant pas encore terminés et les sources n’étant pas disponibles, cette liste n’est ni exhaustive, ni définitive … ni officielle. Nous ne manquerons pas de publier des articles complémentaires sur ces différents sujets lorsque nous en saurons plus.

Actualité éditeurs / SSII

• Spring Source : les VC prennent le contrôle
• JBoss certifié Java EE 5 : un anachronisme corrigé …
• … tandis que Websphere 7 sera le dernier grand sur la ligne d’arrivée

Agilité

• Le Scrum meeting, story par story ?

RIA

• Microsoft et Nokia adoptent jQuery

Le coin de la technique

• Les spécifications REST se terminent
• JVM Wish List vue par Terracotta
• Principes pour le design d’une API
• David Syer communique sur Spring Batch

Actualité éditeurs / SSII

Spring Source : les VC prennent le contrôle

Les semaines se suivent et ne se ressemblent pas chez Spring Source. Après le tumultueux revirement de stratégie Open Source il y a dix jours (cf. Nouvelle politique de maintenance de Spring : La très périlleuse route de monétisation de l’open source), Benchmark Capital, le principal fond d’investissement de Spring Source, prend le contrôle opérationnel de la société en nommant Rob Bearden President and Chief Operations Officer (COO). Rod Johnson conserve le titre de CEO.

C’est un véritable tournant dans la vie de Spring Source qui était jusqu’à présent gouvernée par son fondateur Rod Johnson et est aujourd’hui confrontée aux défis de la rentabilité et de la croissance.

Nous noterons au passage un clin d’oeil de l’histoire : Rob Bearden, avant de rejoindre Benchmark Capital, a été COO de JBoss. Le monde de l’Open source est petit, espérons que les relations conflictuelles entre les camps JBoss et Spring Source s’adoucissent

Les interrogations sont nombreuses : quelle place trouvera Rod Johnson dans cette nouvelle organisation ? Quelle stratégie Open source va adopter Rob Bearden ? Entérinera-t-il la nouvelle politique de commercialisation des releases post trois mois qui suscite encore une polémique très vive ?

Quelques liens :

• The Server Side : What will be next with SpringSource?
• Communiqué officiel : SpringSource Names President and Chief Operating Officer
• The Register : SpringSource VC investor takes COO role

JBoss certifié Java EE 5 : un anachronisme corrigé …

L’anachronisme que personne ne comprenait est enfin corrigé. JBoss Application Server, précurseur de Java EE 5 avec le support de JPA dans Hibernate et la Web Application qui jouait le rôle d’un conteneur d’EJB 3 est enfin certifié Java EE 5. Sacha Labourey, JBoss, annonce dans JBoss AS is now EE5 certified! que la version release sera disponible dans les semaines à venir. Il n’en reste pas moins que JBoss AS 5 est une refonte sur le fond du serveur d’application (nouveau messaging, clustering, etc) qui a duré plus de trois ans (cf InfoQ : Releasing JBoss AS 5: Q&A with Project Lead Dimitris Andreadis) et qu’on peut s’attendre à une phase de stabilisation de la nouvelle stack JBoss.

… tandis que Websphere 7 sera le dernier grand sur la ligne d’arrivée

IBM nous rappelle avec Websphere que les parts de marché sont parfois décorrélées de l’implémentation des dernières spécifications. Websphere 7 sera le dernier grand serveur Java EE a être certifié Java EE 5.

La version d’évaluation est déjà disponible sur DeveloperWorks ; des blogs (Websphere Community et Websphere and Messagin) relaient la communication institutionnelle.

Agilité

Le Scrum meeting, story par story ?

Les daily standup meetings se déroulent habituellement personne par personne, c’est-à-dire que chaque membre de l’équipe répond aux 3 questions l’un après l’autre. Le défaut de cette méthode selon Mike Cohn est qu’elle ne permet pas toujours de voir les problèmes sur les stories dont personne ne s’occupe puisque personne n’en parle.
Il suggère la possibilité d’attaquer le standup story par story, mais on perd alors en visibilité sur ce que fait chaque personne. Face à ce dilemme, plusieurs solutions sont possibles :

• L’équipe s’engage t-elle sur trop d’items par sprint ? Mike préconise une moyenne de 1 à 1,5 story / personne / sprint. Attention, cela ne veut absolument pas dire qu’une story doit être gérée par une seule personne !
• Faire le standup devant le tableau des tâches, afin que chaque personne puisse pointer les items sur lesquels elle travaille.
• Désigner des « story owners » : pour chaque story, une personne de l’équipe est responsable de son avancement. Cette personne n’est pas forcément le développeur principal de la story.
• Regarder la taille de l’équipe : selon ses observations la taille idéale d’une équipe se situe entre 5-7 personnes.

La plupart des équipes font leur standup par personne, mais certaines équipes peuvent se heurter à un manque de visibilité sur certaines stories. Cette vision « story par story » peut répondre à leurs attentes.

RIA

Microsoft et Nokia adoptent jQuery

À part GWT avec Google, un des reproches que l’on peut faire aux librairies JavaScript/AJAX est leur absence de support par un grand éditeur. Cet état de fait pourrait bien changer pour la librairie jQuery, une de nos librairies favorites, que l’on conseille et rencontre de plus en plus fréquemment chez nos clients. jQuery annonce sur son blog l’adoption par Microsoft et Nokia du framework, et son intégration dans leur plateforme de développement officielle respective.
jQuery sera donc distribué avec Visual Studio, et sera présent dans tous les nouveaux téléphones de Nokia qui utiliseront le moteur de rendu maison Web Runtime.
Les bénéfices pour jQuery et ses utilisateurs sont multiples : la reconnaissance de la librairie comme parmi les plus populaires, et son amélioration via la soumission de patchs et de tests. Excellente nouvelle donc !

Le coin de la technique

Les spécifications REST se terminent

Vous en entendrez certainement parler prochainement à l’occasion de Spring 3.0, les spécifications de la JSR-311 : Java API for RESTful Web Service (JAX-RS) ont été approuvées quasi unanimement (15 pour, 0 contre, 1 non votant) par l’executive comitee.

JAX-RS est une API permettant l’implémentation de Web Services REST, son fonctionnement est simple :

• on rajoute des annotations sur des classes et des méthodes pour décrire les services à exposer et la manière de les exposer
• le choix du service s’effectue en fonction des URL / Content type / Headers et type de requête HTTP

REST étant à la mode, plusieurs framework existent déjà dont :

• Jersey, l’implémentation de référence pour JAX-RS développée par Sun
• Restlet, le framework du moment le plus utilisé pour les applications REST
• CXF RESTful Services, l’implémentation JAX-RS du projet Apache CXF
• RESTeasy, la version JBoss

Une interview des specs leads Marc Hadley et Paul Sandoz est disponible sur InfoQ. Une des questions intéressantes porte sur l’influence de la JSR311 sur les spécifications de Servlet. Cela nous rappelle que, même si les API REST et les Servlets ont des approches complètement différentes, ces deux technologies doivent pouvoir cohabiter et travailler ensemble.

JVM Wish List vue par Terracotta

Cet article présente une liste d’améliorations JVM espérées vues par un spécialiste Terracotta. S’il est vrai que cet outil aborde des problématiques peu communes (clustering de JVM), certaines de ces idées pourraient être utiles pour tout autre framework utilisant l’instrumentalisation de code.

Voici les idées proposées par Steeve Haris dans son article regroupées par domaines, elles permettent de :

• Simplifier grandement le code de ce genre de framework en évitant d’avoir à développer des surcouches logicielles simulant certaines de ces fonctionnalités
• Permettre de créer des proxy d’objets niveau JVM : cela faciliterait le maintien de la heap virtuelle de Terracotta
• Pouvoir associer des métadatas à un objet : cela permettrait d’affiner les choix du memory manager de Terracotta
• Faciliter le développement de tricks en améliorant le _Hot swapping_
• Optimiser le nombre d’objets à instrumentaliser
• Permette d’instrumenter des tableaux sans avoir besoin de passer par les classes les utilisant
• Permettre le remplacement de méthodes natives : actuellement si l’on veut modifier le comportement d’une méthode native, nous somme obligé d’instrumenter tous les objets appelant celle-ci.
• Adapter la JVM aux architectures d’aujourd’hui
• La taille des listes et des collections est définie par un int. Les architectures 64 bits nous permettant d’ajouter de plus en plus de mémoire, il se peut que cette taille devienne insuffisante dans certaines utilisations.

Principes pour le design d’une API

Joshua Bloch (Google), auteur de Effective Java, énumère un ensemble de principes clés afin de réussir la conception et la réalisation d’une API : Bumper-Sticker API Design.

Une API n’est pas seulement mise en place dans les frameworks mais aussi dans des applications à différents niveaux :

• la couche d’accès aux données
• la couche service

La volonté d’une API est de réaliser un module cadré au fonctionnement clair. Le fonctionnement interne du module est caché derrière un contrat d’utilisation (qui ne repose pas nécessairement uniquement sur des interfaces Java). Le terme d’utilisabilité de l’API peut être employé.

L’utilisabilité d’une API peut être décrite avec les spécificités suivantes :

• contrat d’utilisation simple et explicité, cela passe par le nommage des éléments (classe, méthode, argument, …).
• l’intégration aux cas d’utilisation doit être naturelle. Pour que ce soit le plus naturel possible, on peut même envisager de d’abord coder les cas d’utilisation avec l’appel à l’API et ensuite coder l’implémentation de l’API.
• l’implémentation de l’API doit être indépendante du contexte d’appel

Le développement d’API pose le problème de la gestion des versions. A partir du moment où elle est exposée, une API doit répondre de la même façon à tous les appels, quel que soit le client sollicitant le service. Il est vital de respecter les principes de l’IoC Inversion of Control, et ne pas enrichir chaque version d’un ou plusieurs comportements spécifiques :

if (isClient1) {
  // Traitement spécifique client 1
} else if (isClient2) {
  // Traitement spécifique client 2
} else {
...
}

Des principes qui font généralement débats sont aussi présentés :

• Faire peu de documentation, les noms des classes/méthodes doivent être explicites
• Ne pas remonter de CheckException que des RuntimeException

Il est vrai que la principale difficulté d’une API est de bien faire dès la première version. La moindre modification du contrat d’utilisation de l’API entraînera des régressions chez les clients de l’API.

C’est pour cette raison qu’il faut tenter de faire un premier jet aussi bref et concis que possible, et de ne traiter la multiplicité des cas qu’au fur et à mesure de leur apparition, dans des versions ultérieures.

Pour conclure, on reprendra la phrase de Joshua Bloch : le design d’API est un art, pas une science exacte.

N’hésitez pas à visionner le vidcast associé à cet article.

David Syer communique sur Spring Batch

Nous vous l’annoncions avant l’été, David Syer, le leader technique de Spring Batch, a entamé sa « tournée promotionnelle ».

À travers ce vidcast, capté au QCon de Londres et relayé par InfoQ (ou bien via le support de présentation), il revient sur :

• les patterns de batch et leur utilisation
• un survol des concepts de SpringBatch
• une étude de cas
• l’avenir de ce produit

D’autre part, dans une autre vidéo publiée sur TV4it, Olivier Rachon, Senior Manager chez Accenture, nous en dit plus quant à l’utilisation de ce récent framework : 5 projets en production, des 10aines en cours de développement.

Pour information, la version 1.1.2 est disponible et les premiers tests que nous avons effectués, dans le cadre d’un XKE, nous ont paru très convaincants. Nous devrions publier prochainement notre retour d’expérience sur ce framework.

Actualité éditeurs / SSII

• Fusion BEA / Oracle : présentation de la stratégie par Oracle

Agilité

• Techniques d’estimation des user stories
• Les déboires de Google avec Scrum

RIA

• Le contenu Flash / Flex indexable

SOA

• REST anti patterns

Le coin de la technique

• Bonne utilisation des generics
• Websphere MQ v7 : un bouleversement discret appelé message properties

Actualité éditeurs / SSII

Fusion BEA / Oracle : présentation de la stratégie par Oracle

Le 1er juillet 2008 a été annoncée la stratégie d’intégration des offres BEA par Oracle. Thomas Kurian, patron du middleware chez Oracle, a notamment annoncé que les produits Weblogic et Tuxedo seront intégrés tel que à l’offre Oracle. Quant aux ESB et aux outils de développement d’Oracle et BEA, ils fusionnent.

Plus de détails sur la nouvelle offre Oracle :

• Détails de cette information par InformationWeek
• Présentation de cette information par InfoQ

Agilité

Techniques d’estimation des user stories

Jay Fields, consultant chez ThoughtWorks, présente différentes astuces pour estimer les user stories. Nous retiendrons :

• Utilisez 4 valeurs, des puissances de 2 : 1, 2, 4, 8. De manière générale, un nombre de choix réduit simplifie le vote et les valeurs qui s’éloignent de plus en plus évitent une fausse précision. La suite de Fibonacci fonctionne très bien aussi.
• Votez indépendamment les uns des autres. Des techniques simples comme le jeu pierre-feuille-ciseaux ou le planning poker permettent de voter simultanément sans être influencé par les autres.
• Les réunions d’estimation sont rarement un plaisir, motivez l’équipe avec des croissants par exemple !

Les déboires de Google avec Scrum

Jeff Sutherland revient dans cette présentation sur la première implémentation de Scrum chez Google.
En 2001, Google avait de gros problèmes pour tenir ses deadlines. Ils ont commencé à introduire Scrum en utilisant les backlogs et les burndown charts, puis les daily scrums. Pourtant les livraisons continuaient de prendre du retard. Après investigations, ils se sont aperçus que beaucoup de tâches étaient « en cours » en même temps. La principale leçon à retenir est de ne pas se disperser sur trop de tâches, l’équipe doit se focaliser sur le minimum de tâches possible jusqu’à ce qu’elles soient complètement terminées.

RIA

Le contenu Flash / Flex indexable

InfoQ rapporte une avancée majeure pour Adobe : le contenu des applications Flash (et donc Flex) est dorénavant indexable par les principaux moteurs de recherche que sont Google et Yahoo.
Avec un avantage non négligeable sur Ajax, à savoir que le contenu dynamique, récupéré du serveur est lui aussi indexé.
Le principe de fonctionnement est original : Adobe fournit à Yahoo et Google un lecteur Flash spécial, optimisé, qui parcourt tout le fichier SWF à la manière d’un utilisateur : instanciation des différents états de l’application, récupération des données dynamiques…
Aucune intervention des développeurs n’est nécessaire, aussi bien sur les nouvelles applications que sur les anciennes.
Certaines fonctionnalités de Flex 3, comme le « deep linking » (historique au sein du fichier SWF, bookmark intra-Flash) ne sont pas encore implémentées.

Un frein (le principal ?) au développement des RIA Flash vient d’être levé.

SOA

REST anti patterns

Stefan Tilkov, éditeur de la communauté InfoQ SOA, présente ses REST Anti Patterns :

• Utiliser uniquement des requêtes GET ou uniquement des requêtes POST : REST utilise la sémantique HTTP avec GET pour les lectures, PUT & DELETE pour les écritures indempotente avec ID et enfin POST pour le reste mais qui est à éviter.
• Ignorer les mécanismes de cache : le code retour HTTP 304 Not Modified et ses headers associés ETag, Expires permettent une grande souplesse de mise en cache par les clients et les proxies pour offrir une très grande tenue à la charge.
• Ignorer les codes retour HTTP : les codes retour HTTP sont très expressifs (201 Created, 406 Not Acceptable, 412 Precondition Failed, etc) ; se limiter aux inexpressifs 200 OK et 500 Internal Server Error nuit à l’auto-documentation.
• Mal utiliser les cookies : REST est par essence sans état ; si les cookies peuvent maintenir des informations stateless comme l’authentification, ils ne doivent en revanche pas porter d’information stateful ou métier (id, etc).
• Oublier l’hypermedia : les hyperliens sont à REST ce que sont les clefs étrangères aux base de données relationnelles. On notera toutefois que l’utilisation d’hyperliens est aujourd’hui très délicate ; xlink reste confidentiel pour XML et les équivalents en JSON ou YAML restent à trouver.
• Ignorer les types MIME : chaque utilisateur a son format de prédilection et se limiter à un seul format limiterait les opportunités de ré-utilisation. On retiendra XML pour java / .Net, JSON pour javascript, YAML pour Ruby et HTML pour les humains.
• Casser l’auto-description : idéalement, tout message devrait contenir suffisamment d’information (headers, format, etc) pour qu’un client générique puisse le traiter. Toute invention de header, protocole ou format nuit très fortement à l’utilisabilité de la ressource.

Le coin de la technique

Bonne utilisation des generics

Introduits lors du jdk 5, les génériques sont maintenant utilisés dans la plupart des applications Java. Les développeurs, aussi bien débutants qu’expérimentés, ont dans l’ensemble bien compris leurs avantages. Ces ‘marqueurs’ permettant de détecter les problèmes de cast dès la compilation ce qui facilitent indéniablement la lecture et l’auto-documentation du code.

Si l’utilisation des génériques est relativement simple à comprendre, cela se complique lorsque vous vous essayez à créer votre propre API. En particulier, l’utilisation des wildcard n’est pas triviale. Qui ne s’est jamais tiré les cheveux pour se demander quand mettre un wildcard. 3 ans après la sortie du jdk 5, êtes-vous familiers avec les formes suivantes ? MyBox<?>, MyBox<? extends T>, MyBox<? super T>

Brian Goetz, l’auteur du bien connu Java Concurrency In Practice revient sur ces notions peu évidentes (cf. le lien en fin d’article). Pour illustrer cette difficulté, il prend l’exemple de la classe AbstractExecutorService introduite lors du jdk 5 dont la signature a été modifiée au jdk 6 : personne n’est à l’abri d’une erreur.

Bonnes pratiques à respecter pour l’utilisation d’une API utilisant les génériques

• Préférez l’utilisation des génériques (List<String>) aux types raw traditionnels (List)
• Proscrire les types raw dans du nouveau code
• Eliminez et documentez les warnings ‘unchecked’ en utilisant l’annotation suivante @SuppressWarnings("unchecked") en essayant de minimiser sa portée.
• Privilégiez l’utilisation des listes (List<String>) aux tableaux (String[]), lorsque le contexte le permet. En effet, les tableaux sont covariants : contrairement aux génériques. (Si une classe A étend B, B[] peut être casté en A[], alors que List<B> ne peut pas être casté en List<A>).

L’exemple ci-dessous, tiré du livre Effective Java, montre en quoi la covariance peut-être dangereuse.

// Lance ArrayStoreException au runtime
Object[] testArray = new Long[1] ;
testArray[0] = "Incompatible value";
// Ne compile pas
List<Object> testList = new ArrayList<Long>();
testList.add("Incompatible value ");

Bonnes pratiques à respecter pour la création d’une API utilisant les génériques

• Utilisez les types paramétrés simples T lorsque c’est possible
• Utilisez les wildcards pour rendre vos API plus flexibles
• Utilisez les wildcards lorsque que vous désirez passer un type paramétré en entrée d’une méthode (remplacer MyBox<T> par MyBox< ? extends T> ou par MyBox<? super T>)
• N’utilisez pas de wildcard dans les types de retours

Comment choisir le bon wildcard ? Le get-put principe.

• Méthodes de type GET : utilisez le ‘upper bounded wildcard’ (MyBox< ? extends T>) sur les méthodes qui permettent de sortir des données de la structure courante.
• Méthodes de type PUT : utilisez le ‘lower bounded wildcard’ (MyBox< ? super T>) sur les méthodes qui font rentrer des données de la structure courante.

D’une manière générale, si l’utilisateur d’une API se pose la question d’utiliser un wildcard, c’est probablement que l’API a été mal pensée.
Au final, notons que si l’utilisation du wildcard extends est relativement répandu, force est de constater que le wildcard super ne se déniche pas encore à tous les coins de rue.

Consultez l’article de Brian Goetz : Websphere MQ v7 : un bouleversement discret appelé message properties

Nous avions déjà évoqué les nouveautés de Websphere MQ V7 lors du lancement du programme de beta testing.
Notre attention s’était portée sur l’intégration du moteur de publish/subscribe et l’amélioration des performances et nous n’avions pas vu passer une évolution sur la structure même des messages. MQ v7 intègre le principe JMS de propriétés de message sous une forme beaucoup plus simple à utiliser que les anciens « RFH2 Folders » qui rebutaient certaines équipes non Java lorsqu’on leur proposait d’abandonner le format MQSTR pour bénéficier des propriétés JMS.
Ces nouveaux Message Properties, toujours transparents pour les développeurs JMS, se manipulent facilement pour les développeurs MQI grâce à l’introduction des verbes MQSETMP et MQINQMP. Un mode de compatibilité ascendante transforme ces nouveaux Message Properties en header MQRFH2 lorsqu’ils sont envoyés à d’anciens Queue Managers.
On notera par ailleurs que l’intégration native du mode publish/suscribe dans MQ simplifie l’utilisation de ce mode pour les développeurs MQI avec la création de nouveaux verbes (MQSUB, …) qui remplacent les fastidieux headers RFH2.
Avec ces deux simplifications majeures, l’utilisation de la richesse de JMS ne devrait plus susciter de réticences dans les équipes MQI.

Tous les détails dans Websphere Technical Exchange : What is new in WebSphere MQ Version 7 et Redbook (Draft) : WebSphere MQ V7.0 Features and Enhancements

Actualité éditeurs / SSII

• Eclipse Ganymède

Le coin de la technique

• JAX-RS : Java standardise son API REST
• Sortie de la JSR286 – Version 2 de l’API Portlet Java
• Le top 10 des fonctionnalités de Hudson
• Dave Syer revient sur SpringBatch pour InfoQ
• Sécurité des applications web : les lignes de front bougent

Actualité éditeurs / SSII

Eclipse Ganymède

La nouvelle livraison de la fondation Eclipse sera disponible le 25 juin. Cet article d’ IBM DeveloperWorks passe en revue l’ensemble des sous projets qui constitue cette nouvelle mouture.

Le coin de la technique

JAX-RS : Java standardise son API REST

Marc Hadley et Paul Sandoz, les specs leaders de JAX-RS, ont présenté à JavaOne 2008 dans JAX-RS: The Java API for RESTful Web Services les enjeux de l’API REST en Java dont la version 1.0 est prévue pour Septembre 2008.

Nous retiendrons:

REST en cinq étapes :

1. Donner un ID sous forme d’URL à chaque donnée (ex. : <client id="http://example.com/client/my-company"><name>my company</name>...</client>).
2. Lier les données ensembles (ex. : <product-order><client ref="http://example.com/client/my-company"/>...</product-order>).
3. Utiliser les méthodes HTTP standard (GET pour la lecture, PUT pour l’écriture avec ID, POST pour l’écriture sans ID, DELETE).
4. Représenter les données sous plusieurs formats (XML, JSON, HTML souvent déterminé selon le champ Accept de la requête HTTP).
5. Communications ‘stateless’

Example de code JAX-RS :

@Path("orders/{order_id}")
public class OrderResource {
   @GET
   @ProduceMime({"application/xml","application/json"})
   Order getOrder(@PathParam("order_id") String id) {
   ...
   }
}

Les principales implémentations JAX-RS :
Restlet, JBoss RESTEasy, Apache CXF, Glassfish Jersey.

Sortie de la JSR286 – Version 2 de l’API Portlet Java

Cette nouvelle version apporte le support des événements (une portlet peut envoyer ou recevoir des évènements), une gestion des paramètres publics pouvant être partagée entre différentes portlets (Public parameter renderer), le « resource serving » pour qu’une portlet puisse donner accès à une ressource, et pour finir le « portlet filter » qui permettra de faire des transformations en entrée ou sortie de la portlet.
JSR-000286 Portlet Specification 2.0

Le top 10 des fonctionnalités de Hudson

On a déjà parlé de Hudson a plusieurs reprises, toujours en bien, et on en rajoute une couche, avec ce post d’Arun Gupta (Technology Evangelist chez Sun), qui nous donne son top 10 des meilleures fonctionnalités de Hudson:

1. Facilité d’installation et d’utilisation – Hudson est un simple WAR à déployer
2. Vaste écosystème de plugins – voir la liste des plugins les plus téléchargés depuis la mise en place du centre de téléchargements de plugins dans Hudson 1.222
3. Support du build distribué – la mise en place d’un build distribué est simple, un serveur maître gère les esclaves, et leur distribue les builds automatiquement. On se connecte à l’interface du maître et le mode distribué est transparent, l’interface est la même que si les builds sont effectués sur le serveur maître
4. Support du build inter-équipes – les dépendances entre projets compilés par Hudson sont correctement gérées, avec un système de « chaînage » des builds. On peut également aisément garder la trace des versions utilisées grâce au Finger printing
5. Open Source – Hudson est entièrement Open Source, sous licence MIT
6. Maturité – au 23 Juin 2008, Hudson en est à la 227ème release
7. Existence de nombreux outils pour Hudson en dehors de Hudson – l’API de contrôle d’Hudson a permis l’apparition d’outils tiers, comme par exemple un plugin pour Firefox ou une icône de notification dans la barre des tâches sous Windows ou MacOS.
8. Support des liens permalink – Hudson expose des URLs simples pour certaines pages, comme les pages « dernier build réussi » ou « historique des temps de build »
9. Internationalisation – Hudson est disponible en Anglais, Japonais, Allemand, Français (grâce au travail d’Eric Lefevre, Turque, Brésilien, Portugais et Russe. Un guide d’internationalisation est disponible.
10. API d’utilitaires développés pour Hudson – peuvent être utilisés sur d’autres projets

Nous utilisons Hudson chez nos clients sur de nombreux projets, l’outil est tellement simple et efficace qu’il nous est maintenant difficile de nous en passer!

Dave Syer revient sur SpringBatch pour InfoQ

Le leader du projet SpringBatch , David Syer , expose sur InfoQ les principales fonctionnalités offertes par le framework. Comme pour l’ensemble du projet Spring, le but avoué est d’aider le développeur à se consacrer à la logique métier de son application, en délégant au maximum les taches sans valeurs ajoutées au framework.
Les principaux cas d’utilisation de SpringBatch sont les suivants :

• Traitements business : reporting, traitement de commandes, réconciliation de comptes…
• Gestion d’import /export : traitement de formulaires, rapports d’inventaire…
• Emissions à grande échelle : campagne d’emailing, états financier…

Les principales fonctionnalités de SpringBatch

• Une infrastructure de bas niveau, réutilisable, offrant la gestion des répétitions et des ‘retry’, la synchronisation des transactions, la lecture / écriture en fichiers plats, en XML ou en base de données.
• Un noyau (Core) sous forme d’API légère qui permet le lancement et la gestion des batchs, et fourni tous les outils pour la gestion opérationnelle de ceux ci.
• Un environnement d’exécution (implémentation de l’API Core)
• Un ensemble d’applications d’exemple déclinant toutes les fonctionnalités offertes par SpringBatch

David Syer revient également sur la collaboration fructueuse entre la fondation Spring et Accenture sur ce projet, qui a permis d’augmenter la quantité et la qualité des contributions sur le code source.

A noter que David Syers donnera une télé-conférence sur l’utilisation de SpringBatch le 9 juillet .

L’intégralité de l’article sur InfoQ .

Sécurité des applications web : les lignes de front bougent

Jeremiah Grossman, Whitehat, et Joe Walker, Sitepen ont présenté à JavaOne 2008 dans Advanced Web Application Security les évolutions des menaces qui pèsent sur les applications web avec l’émergence des Cross Site Request Forgery* (CSRF) et JavaScript Hijacking qui s’ajoutent au bien connu Cross Site Scripting (XSS).

Cross Site Request Forgery (CSRF)

• Description : un attaquant insère dans une page web une URL (<img />, <iframe />, etc) vers un site applicatif auquel l’internaute a l’habitude de se connecter. Il n’est même pas nécessaire d’injecter ce code malicieux sur le site agressé ; il suffit que la page web ‘crackée’ soit affichée dans le browser.
• Exemple : insertion d’un tag image <img src="https://ma-banque.com/virement?montant=666&beneficiaire=un-mechant-attaquant" />
• Protection : OWASP CSRF Guard

JavaScript Hijacking

• Description : le langage JavaScript permet de redéfinir la plupart des comportements, notamment les constructeurs, les getters et les setters. Il suffit de redéfinir le comportement d’un accès Ajax pour intercepter et modifier les contenus entrants et sortants.
• Exemple : redéfinition du constructeur et d’un setter

function Object() {
  alert("Hello, World");
  this.__defineSetter__('foo', function(x) {  alert(x); } );
}

• Protections : utiliser un framework Ajax qui prévient cette faille (DWR 2.2 le fait déjà, les autres y travaillent), lire des documents de référence tels que JavaScript Hijacking par Brian Chess, Yekaterina Tsipenyuk O’Neil et Jacob West.

Cross Site Scripting (XSS)

• Description : Problème maintenant bien connu mais toujours aussi dangereux d’injection de javascript dans des pages web.
• Exemple : saisie d’une valeur malicieuse dans un champ de formulaire telle que Joe<script src="http://evil.com/danger.js" />
• Protections : Restreindre les données en entrée, escaper les données affichées et fixer l’encodage des pages.

Actualité éditeurs / SSII

• MySQL by Sun : Revirement de stratégie open source ? Choquant ?
• Superpackages (JSR-294) vs. OSGI : Episode n° 34291567….

Agilité

• User stories « En tant que … je veux … »

Le coin de la technique

• De la sérialisation au parallélisme, une évolution incarnée par java.util.concurrent
• Innovation autour de JPA : JBoss Hibernate confirme son domination avec Envers
• Cas d’utilisation des grilles Java avec WebSphere eXtreme Scale/ ObjectGrid
• JSR-311 JAX-RS REST une histoire de RESTaurant

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

• XKE, le programme de la session de mai

Actualité éditeurs / SSII

MySQL by Sun : Revirement de stratégie open source ? Choquant ?

Slashdot essaie de nous emmener sur une polémique « Sun gâche MySQL » avec Sun May Begin Close Sourcing MySQL Features à l’occasion de l’annonce par l’éditeur de fonctionnalités (online backup, etc) qui seront uniquement disponibles dans la version payante MySQL Enterprise. Au delà de l’insinuation peu crédible quand on se rappelle que l’essentiel du catalogue de Sun est disponible gratuitement, on retrouve le défi aujourd’hui classique de la monétisation de l’Open Source. Le rachat de MySQL par Sun change complétement le modèle économique de l’éditeur de base de données.

Hier, la startup MySQL, financée par des fonds de capital risque, se permettait d’être déficitaire car les candidats au rachat (Oracle puis finalement Sun) ne valorisaient pas MySQL Inc sur ses revenus mais sur les parts de marché de sa base de données. La stratégie a magnifiquement porté ses fruits puisque MySQL Inc s’est vendue un milliard de dollars à Sun, félicitations au management.

Aujourd’hui, MySQL est vraisemblablement devenue une division ‘classique’ de Sun et doit donc devenir rentable. L’équation de la rentabilité de l’open source est complexe, Red Hat et JBoss by Red Hat ont été des pionniers sur ce chemin, souhaitons à MySql by Sun de trouver lui aussi son modèle.

TSS : MySQL to get new features in Enterprise version

Modification du billet le 29 Avril 2008 : Jonathan Schwartz est finalement revenu en arrière et a annoncé que tous les produits que Sun distribue, sans exception, sont proposés gratuitement en licence Open source à la communauté. Pour plus de détails sur cette histoire, nous vous recommandons la série de The 451 Group : MySQL’s business model in a state of flux, Finding the right balance – MySQL’s changing development model et Jonathan Schwartz has the last word on MySQL

Superpackages (JSR-294) vs. OSGI : Episode n° 34291567….

La guerre continue entre les partisans de OSGI et ceux des JSR de SuperPackage et de JAM. Cependant, l’attaque vient cette fois-ci d’Alex Buckley de chez Sun.

Il explique dans son email les inconvénients qu’il voit dans l’implémentation actuelle des superpackages[1]. En substance, il propose d’introduire à la place un nouvel ‘access modifier’ (module).

Peter Kriens de l’OSGi Alliance semble plutôt emballé par cette proposition.

[1] Pour mémoire, nous avons publié en février dernier un article présentant les superpackages

Agilité

User stories « En tant que … je veux … »

Mike Cohn nous rappelle les 3 raisons pour lesquelles il préconise de décomposer les user stories sous forme de phrase « En tant que <role>, je veux <but>, pour que <raison> » (la raison est optionnelle) :

• L’emploi de la 1ère personne du singulier aide les développeurs à s’identifier à l’utilisateur
• La structure de la phrase – représentée par 3 colonnes dans le Product backlog – aide le Product Owner à comprendre et prioriser les user stories
• Pour ne pas rajouter de bruit dans la description des user stories, il suffit de nommer les colonnes du Product backlog « En tant que … », « je veux … », « pour que … » et le backlog devient intuitif à lire.

Le coin de la technique

De la sérialisation au parallélisme, une évolution incarnée par java.util.concurrent

La programmation multi-threadée en java a évoluée : anciennement on utilisait la sérialisation incarnée par synchronized, désormais on peut faire du parallélisme avec l’introduction des API java.util.concurrent en Java 5.

Sharadjava nous présente dans sa Java Concurrency Series les différents aspects de cette nouvelle librairie :

• Simple Executor example pour la parallélisation des tâches.
• Barrier pour l’attente entre tâches (on n’oubliera pas sur ce sujet le CountDownLatch).
• Meaning of volatile pour la visibilité inter-threads des valeurs des variables.

Innovation autour de JPA : JBoss Hibernate confirme son domination avec Envers

Après l’intégration de la recherche full text Lucene [1] et le support du Database Sharding, Hibernate confirme sa domination de l’innovation autour de JPA en ouvrant le chantier du versionnage des données. Cette problématique, bien que récurrente et accentuée par les nouvelles contraintes réglementaires (Sarbane & Oaxley, etc), restait largement ignorées par nos frameworks et nos très chers design patterns. Seul Martin Fowler nous éclairait sur ce sujet délicat avec Patterns for things that change with time.

JBoss comble aujourd’hui ce vide en lançant Envers, une extension d’Hibernate qui versionne les données persistantes selon un pattern similaire au Temporal Object de Martin Fowler. Envers n’est qu’en version preview mais le projet est très prometteur et déjà une source d’inspiration pour les projets qui n’ont pas le temps d’attendre la première version stable.

On notera au passage qu’Envers préfère l’API standard JPA EntityManager à l’historique Session Hibernate ; on peut y voir un signe que le temps est venu pour les équipes projets de privilégier les standards JPA aux API historiques Hibernate.

Exemple d’entité persistante versionnée avec JBoss Envers

@Entity
public class Person {
    @Id
    @GeneratedValue
    private Integer id;
    @Versioned
    private String name;
    @Versioned
    private String surname;
    @Versioned
    @ManyToOne
    private Address address;
   ...
}

[1] cf notre billet Introduction à Hibernate Search (Googling your Persistent Domain Model)

Cas d’utilisation des grilles Java avec WebSphere eXtreme Scale/ ObjectGrid

Billy Newport présente dans Video: Introduction to WebSphere eXtreme Scale/ObjectGrid with patterns and use cases les scénarios typiques d’utilisation de la grille Java d’IBM :

• Cache de proximité classique : la grille sert de Map distribuée ; l’application métier gère les données (chargement depuis les backends, mise en cache et sauvegarde des modifications dans les backends).
• Cache de proximité avec « Loader synchrone » dans la grille : l’application métier se limite à demander des données à la grille et à les modifier ; la grille, grâce à un Loader, s’occupe de charger les données depuis les backends et sauvegarde en synchrone les données modifiées dans les backends.
• Cache de proximité avec un « Loader à écriture différée » dans la grille : similaire au scénario précédent mais la sauvegarde des modifications dans les backends est asynchrone.
• Cache collocalisé : l’application et la grille s’éxécutent dans les même JVM, chaque JVM héberge un noeud du cluster de l’application et un noeud de la grille. Ce scénario est typique de la mise en cache des sessions HTTP.

On notera que les architectures de type Map/Reduce, qui nécessitent une conception radicalement différente, ne semblent pas encore très répandues.

JSR-311 JAX-RS REST une histoire de RESTaurant

Dans cet article, Nicolas Martignole nous présente l’architecture REST (Representational State Transfer) et JSR 311: JAX-RS: The Java API for RESTful Web Services. L’objectif de cette JSR est de faciliter la programmation d’applications REST en Java.
La première partie est consacrée à une introduction de REST (définition d’une ressource, lecture, création, mise à jour, suppression d’une ressource, Services Webs RESTfull).
La deuxième partie nous présente quelques détails sur l’implémentation JAX-RS avec Java.

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

XKE, le programme de la session de mai

Le prochain XKE (Xebia Knowledge Exchange) aura lieu le mardi 6 Mai 2008. Les sujets suivants seront abordés :

• Sessions Pratiques
  • Terracotta, the Network Attached Memory (NAM)
  • java.util.concurrent, concours de developpement

• Technique
  • Java et la Cryptographie

• Architecture
  • Retour sur l’architecture de l’un des plus grand site de ecommerce de France
  • Tests unitaires avec les librairies de Mock

• Xebia Hollande
  • Intervention du CTO de Xebia Hollande

Comme nous l’annoncions, les XKE sont ouverts à l’ensemble des personnes à l’écoute du marché de l’emploi autour des technologies Java/J2EE. Si vous êtes l’une d’entre elles , n’hésitez pas à contacter Mélanie Bacrot pour vous inscrire.