Pour comparer 2 choses, il faut un référentiel comparable. JBoss Seam propose sur cette page plusieurs versions d’une application de réservation de chambres d’hôtels. La version originale basée sur JSF 1.2 n’est plus toute jeune mais fonctionne très bien. J’en avais parlé sur le Touilleur Express il y a 3 ans et demie… Quand je me dis que cela fait plus de 3 ans que j’ai vu cela, et qu’à l’époque je vous avais convaincu de regarder JSF par rapport à Struts, je me dis qu’il faut que je réussisse dans cet article à vous montrer la nouvelle approche, celle de 2010.

Nous allons prendre Spring Faces et Spring Webflow, une approche que je trouve très intéressante et qui permet de réaliser des applications Webs avec les technologies de Spring.

I. Le match : télécharger, installer et lancer la démo

Voyons tout d’abord comment télécharger, compiler et lancer la démonstration avec chacun des environnements. Je souhaite évaluer la rapidité de prise en main. Je souhaite que le projet soit configuré dans IDEA IntelliJ ou Eclipse pour travailler, et je vais évaluer la facilité à monter chacun des environnements. Je regarderai aussi le temps de démarrage des serveurs Webs testés.

I.1) Préparation de l’espace de démo pour Spring

SpringSource propose « Spring Travel« , une version basée sur Spring Faces, Spring WebFlow 2.0.9 et une librairie JSF avancée pour le rendu. J’ai regardé précisément le code « booking-faces » dans le répertoire projects/spring-webflow-samples pour écrire cet article. Si vous souhaitez tester par vous même :
- téléchargez la version Spring WebFlow 2.0.9 sur le site de SpringSource
- décompressez l’archive
- ouvrez le répertoire projects/spring-webflow-samples/booking-faces
- tapez mvn eclipse:eclipse pour créer un nouveau projet
- ou sinon tapez mvn idea:idea pour créer un projet IDEA IntelliJ
- ou enfin, si vous avez IDEA IntelliJ, celui-ci importe sans problème le pom.xml et vous prépare un projet configuré… Pas besoins de plugins.

Faire tourner la démo en local
Pour faire fonctionner la version Spring en local, éditez le pom.xml et ajoutez Jetty dans la balise build/plugins comme ici:

   ...
   <build>
        <finalName>swf-booking-faces</finalName>
        <plugins>
        	...

            <plugin>
                <groupId>org.mortbay.jetty</groupId>
                <artifactId>maven-jetty-plugin</artifactId>
            </plugin>

        </plugins>
    </build>
    <properties>
        <spring.version>2.5.6.SEC01</spring.version>
        <jsf.version>1.2.0.09</jsf.version>
    </properties>
</project>

Vous pourrez alors lancer la démo avec mvn jetty:run dans le répertoire de la démo de Spring.

I.2) Configuration de la version Play! Framework

Play! Framework se télécharge sur le site de Play!. Voici comment suivre mes explications pour la deuxième partie :
- décompressez le zip dans un répertoire C:\Soft\play par exemple
- ajoutez C:\Soft\play à votre PATH

Pour lancer l’application :
- allez dans le répertoire C:\Soft\play\samples-and-tests\booking
- tapez « play run » et connectez-vous sur http://localhost:9000/

Pour travailler avec Eclipse ou IDEA IntelliJ
- allez dans le répertoire C:\Soft\play\samples-and-tests\booking
- tapez play eclipsify pour créer un projet Eclipse
- OU tapez play idealize pour créer un module IDEA IntelliJ
c’est tout !

I.3) Résultat du match :

Facilité d’installation : match nul
Qualité de la doc sur le site : match nul
Création du projet dans IDEA IntelliJ : match nul
Serveur : la démo Spring n’embarque pas de serveur, il a fallut ajouter Jetty pour tester alors que Play! Framework dispose de son propre serveur
Temps de démarrage : avantage Play! qui démarre très rapidement en 2 secondes.

Vainqueur : Play! Framework d’une courte longueur

II. Le modèle

II.1) Spécification fonctionnelle

L’objectif de l’application est de réaliser un site de réservation d’hôtel. Pour cela, l’utilisateur peut chercher un hôtel, puis ensuite créer une réservation (Booking en Anglais).

L’utilisateur doit s’authentifier avant de pouvoir terminer sa réservation. Une entité User permet donc de gérer la sécurité facilement avec un moteur de persistence.

Nous utiliserons JPA et une base en mémoire pour les 2 versions. L’essentiel est que Play! Framework comme la version Spring, utilisent JPA. Donc les entités sont presque identiques.

II.2) Une entité simple : l’Hotel

Prenons tout d’abord l’entité Hotel qui représente un hôtel. Voici la version de la démo Spring Webflow/JSF :

package org.springframework.webflow.samples.booking;

import java.io.Serializable;
import java.math.BigDecimal;

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;

/**
 * Version Spring Web Flow. La sérialisation est nécessaire pour JSF.
 */
@Entity
public class Hotel implements Serializable {
    private static final long serialVersionUID = 4011346719502656269L;
    private Long id;
    private String name;
    private String address;
    private String city;
    private String state;
    private String zip;
    private String country;
    private BigDecimal price;

    @Id
    @GeneratedValue
    public Long getId() {
	return id;
    }

    public void setId(Long id) {
	this.id = id;
    }

    public String getName() {
	return name;
    }

    public void setName(String name) {
	this.name = name;
    }

    public String getAddress() {
	return address;
    }

    public void setAddress(String address) {
	this.address = address;
    }

    public String getCity() {
	return city;
    }

    public void setCity(String city) {
	this.city = city;
    }

    public String getZip() {
	return zip;
    }

    public void setZip(String zip) {
	this.zip = zip;
    }

    public String getState() {
	return state;
    }

    public void setState(String state) {
	this.state = state;
    }

    public String getCountry() {
	return country;
    }

    public void setCountry(String country) {
	this.country = country;
    }

    @Column(precision = 6, scale = 2)
    public BigDecimal getPrice() {
	return price;
    }

    public void setPrice(BigDecimal price) {
	this.price = price;
    }

    public Booking createBooking(User user) {
	return new Booking(this, user);
    }

    @Override
    public String toString() {
	return "Hotel(" + name + "," + address + "," + city + "," + zip + ")";
    }
}

Voici la version Play! Framework :

package models;

import play.db.jpa.*;
import play.data.validation.*;
import javax.persistence.*;
import java.math.*;

/**
 * Version Play! Framework
 */
@Entity
public class Hotel extends play.db.jpa.Model {

    @Required
    @MaxSize(50)
    public String name;

    @MaxSize(100)
    public String address;

    @Required
    @MaxSize(40)
    public String city;

    @Required
    @MaxSize(6)
    @MinSize(2)
    public String state;

    @Required
    @MaxSize(6)
    @MinSize(5)
    public String zip;

    @Required
    @MaxSize(40)
    @MinSize(2)
    public String country;

    @Column(precision=6, scale=2)
    public BigDecimal price;

    public String toString() {
        return "Hotel(" + name + "," + address + "," + city + "," + zip + ")";
    }

}

Les différences entre les 2 versions :
- Play! Framework étend la classe « play.db.jpa.Model » qui fournit le support JPA.
- Les attributs sont publics dans la version Play!, ce qui logiquement évite des getters/setters comme dans la version Spring classique. Moi depuis que l’encapsulation n’est plus à la mode en soirée, j’ai arrêté.
- La syntaxe JPA est un peu plus poussée dans la version Play! Nous verrons si cela permet d’améliorer l’expérience utilisateur dans l’interface graphique ou non.

Le bean de Spring n’étend pas une classe de base contrairement à Play!, ce qui permet d’étendre éventuellement Hotel. Mais est-ce que c’est quelque chose que nous faisons pour des Entities ? Je me pose la question. Perso je décourage l’héritage avec JPA. FBI = Fausse bonne idée.

[Update] Avec Play! Framework vous pouvez étendre la classe Model afin de simplifier la gestion JPA de l’entité. Cela fait partie des bonnes pratiques comme expliqué par Nicolas Leroux dans les commentaires. Pour en savoir plus, regardez la doc de la partie JPA de Play!

Play! gère l’identité dans la class Model avec un attribut Id de type Long par défaut. Si vous souhaitez gérer votre propre id, vous devez pouvez par exemple étendre la class JPASupport de Play!, puis simplement définir un attribut @Id comme d’habitude avec JPA. C’est tout à fait possible.

On voit que dans la version Spring, il y a une méthode « createBooking » qui permet de créer au niveau de l’Hotel une réservation.

Il n’y a donc pas de vainqueur dans cette partie pour moi. Les 2 approches se valent je pense. Je préfère la simplicité de Play! Framework qui remet en question quelques habitudes du monde Java, comme l’encapsulation systématique.

Par contre je n’aime pas trop l’approche de placer les annotations JPA sur les getters/setters plutôt que sur les attributs de la classe dans la version Spring. On perd beaucoup en lisibilité.

II.3) Une entité plus compliquée : Booking

Une réservation est l’association d’un User, d’un Hotel, d’une date d’arrivée et de départ et de différents autres attributs. Je vais faire exprès de vous donner la version complète des 2 frameworks, afin de vous montrer les différences flagrantes entre les 2 approches.

La version de la démo Spring WebFlow telle qu’elle est livrée, sans trucages, sans effets spéciaux :

package org.springframework.webflow.samples.booking;

import java.io.Serializable;
import java.math.BigDecimal;
import java.text.DateFormat;
import java.util.Calendar;
import java.util.Date;

import javax.persistence.Basic;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.ManyToOne;
import javax.persistence.Temporal;
import javax.persistence.TemporalType;
import javax.persistence.Transient;

import org.springframework.binding.message.MessageBuilder;
import org.springframework.binding.message.MessageContext;
import org.springframework.binding.validation.ValidationContext;

/**
 * A Hotel Booking made by a User.
 */
@Entity
public class Booking implements Serializable {

    private static final long serialVersionUID = 1171567558348174963L;

    private Long id;
    private User user;
    private Hotel hotel;
    private Date checkinDate;
    private Date checkoutDate;
    private String creditCard;
    private String creditCardName;
    private int creditCardExpiryMonth;
    private int creditCardExpiryYear;
    private boolean smoking;
    private int beds;
    private Amenity amenities;   // Absent de la version Play!

    public Booking() {
    }

    public Booking(Hotel hotel, User user) {
        this.hotel = hotel;
        this.user = user;
        Calendar calendar = Calendar.getInstance();
        setCheckinDate(calendar.getTime());
        calendar.add(Calendar.DAY_OF_MONTH, 1);
        setCheckoutDate(calendar.getTime());
    }

    @Transient
    public BigDecimal getTotal() {
        return hotel.getPrice().multiply(new BigDecimal(getNights()));
    }

    @Transient
    public int getNights() {
        if (checkinDate == null || checkoutDate == null) {
            return 0;
        } else {
            return (int) (checkoutDate.getTime() - checkinDate.getTime()) / 1000 / 60 / 60 / 24;
        }
    }

    @Id
    @GeneratedValue(strategy = GenerationType.TABLE)
    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    @Basic
    @Temporal(TemporalType.DATE)
    public Date getCheckinDate() {
        return checkinDate;
    }

    public void setCheckinDate(Date datetime) {
        this.checkinDate = datetime;
    }

    @ManyToOne
    public Hotel getHotel() {
        return hotel;
    }

    public void setHotel(Hotel hotel) {
        this.hotel = hotel;
    }

    @ManyToOne
    public User getUser() {
        return user;
    }

    public void setUser(User user) {
        this.user = user;
    }

    @Basic
    @Temporal(TemporalType.DATE)
    public Date getCheckoutDate() {
        return checkoutDate;
    }

    public void setCheckoutDate(Date checkoutDate) {
        this.checkoutDate = checkoutDate;
    }

    public String getCreditCard() {
        return creditCard;
    }

    public void setCreditCard(String creditCard) {
        this.creditCard = creditCard;
    }

    @Transient
    public String getDescription() {
        DateFormat df = DateFormat.getDateInstance(DateFormat.MEDIUM);
        return hotel == null ? null : hotel.getName() + ", " + df.format(getCheckinDate()) + " to "
                + df.format(getCheckoutDate());
    }

    public boolean isSmoking() {
        return smoking;
    }

    public void setSmoking(boolean smoking) {
        this.smoking = smoking;
    }

    public int getBeds() {
        return beds;
    }

    public void setBeds(int beds) {
        this.beds = beds;
    }

    public String getCreditCardName() {
        return creditCardName;
    }

    public void setCreditCardName(String creditCardName) {
        this.creditCardName = creditCardName;
    }

    public int getCreditCardExpiryMonth() {
        return creditCardExpiryMonth;
    }

    public void setCreditCardExpiryMonth(int creditCardExpiryMonth) {
        this.creditCardExpiryMonth = creditCardExpiryMonth;
    }

    public int getCreditCardExpiryYear() {
        return creditCardExpiryYear;
    }

    public void setCreditCardExpiryYear(int creditCardExpiryYear) {
        this.creditCardExpiryYear = creditCardExpiryYear;
    }

    @Transient
    public Amenity getAmenities() {
        return amenities;
    }

    public void setAmenities(Amenity amenities) {
        this.amenities = amenities;
    }

    public void validateEnterBookingDetails(ValidationContext context) {
        MessageContext messages = context.getMessageContext();
        if (checkinDate.before(today())) {
            messages.addMessage(new MessageBuilder().error().source("checkinDate").code(
                    "booking.checkinDate.beforeToday").build());
        } else if (checkoutDate.before(checkinDate)) {
            messages.addMessage(new MessageBuilder().error().source("checkoutDate").code(
                    "booking.checkoutDate.beforeCheckinDate").build());
        }
    }

    private Date today() {
        Calendar calendar = Calendar.getInstance();
        calendar.add(Calendar.DAY_OF_MONTH, -1);
        return calendar.getTime();
    }

    @Override
    public String toString() {
        return "Booking(" + user + "," + hotel + ")";
    }

}

Voyons la version Play! Framework de l’entité Booking maintenant :

package models;

import play.db.jpa.*;
import play.data.validation.*;
import javax.persistence.*;
import java.util.*;
import java.text.*;
import java.math.*;

@Entity
public class Booking extends Model {

    @Required
    @ManyToOne
    public User user;

    @Required
    @ManyToOne
    public Hotel hotel;

    @Required
    @Temporal(TemporalType.DATE)
    public Date checkinDate;

    @Required
    @Temporal(TemporalType.DATE)
    public Date checkoutDate;

    @Required(message="Credit card number is required")
    @Match(value="^\\d{16}$", message="Credit card number must be numeric and 16 digits long")
    public String creditCard;

    @Required(message="Credit card name is required")
    @MinSize(value=3, message="Credit card name is required")
    @MaxSize(value=70, message="Credit card name is required")
    public String creditCardName;
    public int creditCardExpiryMonth;
    public int creditCardExpiryYear;
    public boolean smoking;
    public int beds;

    public Booking(Hotel hotel, User user) {
        this.hotel = hotel;
        this.user = user;
    }

    public BigDecimal getTotal() {
        return hotel.price.multiply( new BigDecimal( getNights() ) );
    }

    public int getNights() {
        return (int) ( checkoutDate.getTime() - checkinDate.getTime() ) / 1000 / 60 / 60 / 24;
    }

    public String getDescription() {
        DateFormat df = DateFormat.getDateInstance(DateFormat.MEDIUM);
        return hotel==null ? null : hotel.name +
            ", " + df.format( checkinDate ) +
            " to " + df.format( checkoutDate );
    }

    public String toString() {
        return "Booking(" + user + ","+ hotel + ")";
    }

}

Tout d’abord il manque des choses dans la version Play! Framework, et on ne compare donc plus exactement la même chose. Notez l’absence de l’entité Amenity. Ensuite, la version Spring utilise une approche différente pour l’attribut @Id et spécifie le générateur alors que la version Play! hérite de ce que la super-classe Model propose.

Ce qui me dérange dans la version Spring c’est la présence de la méthode validateEnterBookingDetails. Celle-ci est intéressante fonctionnellement, mais dépose une dépendance vers MessageContext un peu trop forte à mon goût.

Regardez aussi la différence sur la validation du numéro de carte de paiement. La version Play! utilise un moteur simple similaire à Hibernate Validation, mais propriétaire à Play! Au contraire la version Spring ne précise rien, et on imagine donc que la validation des 16 digits se fera dans la vue… et pas dans le modèle.

Conclusion : j’ai de plus en plus de mal avec la sauce des getters/setters, surtout lorsque les entités dépasse les « HelloWorld » et que l’on commence à sortir des cas d’usages compliqués. Souvenez-vous de ce que je vous disais : pour résoudre des problèmes compliqués il faut des solutions simples…

III. Le contrôleur

Après avoir regardé 2 entités différentes pour le modèle, voyons maintenant la différence d’approche entre Spring WebFlow et Play! Framework. Je vais étudier le cas de l’affichage de la liste des Hôtels, lorsque l’utilisateur clique sur le bouton Search par exemple.

III.1) Spring WebFlow

L’approche de Spring WebFlow est la suivante : afin d’éviter d’écrire un controller classique, Spring propose de définir les chemins logiques de navigation en XML, et d’associer directement des méthodes sur des services pour récupérer la partie Model. Cette approche a l’avantage de simplifier le développement de workflow webs complexes. Je vais vous présenter le concept.

Pour commencer, nous définissions un flow en XML pour l’action qui affiche la liste des Hotel correspondant à un critère de recherche. Je ne vous montre que la view-state « reviewHotels » afin de ne se concentrer que sur l’exemple :

« main-flow.xml »

<?xml version="1.0" encoding="UTF-8"?>
<flow xmlns="http://www.springframework.org/schema/webflow"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://www.springframework.org/schema/webflow http://www.springframework.org/schema/webflow/spring-webflow-2.0.xsd">

	<var name="searchCriteria" class="org.springframework.webflow.samples.booking.SearchCriteria" />

	<view-state id="enterSearchCriteria">
		// Effacé pour simplifier l'exemple...
	</view-state>

	<view-state id="reviewHotels">
		<on-render>
			<evaluate expression="bookingService.findHotels(searchCriteria)" result="viewScope.hotels" result-type="dataModel" />
		</on-render>
        <transition on="sort">
            <set name="searchCriteria.sortBy" value="requestParameters.sortBy" />
            <render fragments="hotels:searchResultsFragment" />
        </transition>
		<transition on="previous">
			<evaluate expression="searchCriteria.previousPage()" />
			<render fragments="hotels:searchResultsFragment" />
		</transition>
		<transition on="next">
			<evaluate expression="searchCriteria.nextPage()" />
			<render fragments="hotels:searchResultsFragment" />
		</transition>
		<transition on="select" to="reviewHotel">
			<set name="flowScope.hotel" value="hotels.selectedRow" />
		</transition>
		<transition on="changeSearch" to="changeSearchCriteria" />
	</view-state>

Le point fort de Spring WebFlow/JSF ici : il sera possible de ne redessiner qu’une partie de l’interface. En effet, vous avez noté le tag <render fragments= »"/> ? Grâce à ce système très pratique avec Spring WebFlow et JSF, si vous avez une partie cliente en Ajax il devient alors possible de ne redéfinir qu’une partie de l’interface.

Dans la démo Play! Booking, ce mécanisme est implémenté « à la main » dans la page index.html. Tout est fait avec du jQuery et le tag jsAction de Play!, qui appelle des actions du controller Play. Celui-ci retourne alors des fragments de HTML, ce qui fait que la version Play! est aussi ajaxisé. Je reconnais que c’est moins évident et facile, mais les 2 se discutent.

Il y a donc un BookingService avec une méthode findHotels pour rechercher la liste des hôtels, d’après le Flow XML. Il s’agit d’une interface, ce qui permet de changer l’implémentation. Dans notre cas nous n’aurons que la version JPA. Si vous avez une forte envie de faire une version PasJPA notez que c’est super utile…

public interface BookingService {
   // j'ai effacé les autres méthodes ici pour ne garder que l'essentiel

    public List<hotel> findHotels(SearchCriteria criteria);

}

Le service implémente l’interface, j’ai supprimé une bonne partie du code afin de ne vous laissez que ce qui nous intéresse. Mais croyez-moi, la version complète est assez verbeuse. Ce qui nous intéresse ici c’est uniquement la méthode findHotels

@Service("bookingService")
@Repository
public class JpaBookingService implements BookingService {

    private EntityManager em;

    @PersistenceContext
    public void setEntityManager(EntityManager em) {
        this.em = em;
    }

   // Note : j'ai effacé du code ici pour ne garder que quelques méthodes

    @Transactional(readOnly = true)
    @SuppressWarnings("unchecked")
    public List findHotels(SearchCriteria criteria) {
        String pattern = getSearchPattern(criteria);
        return em.createQuery(
                "select h from Hotel h where lower(h.name) like " + pattern + " or lower(h.city) like " + pattern
                        + " or lower(h.zip) like " + pattern + " or lower(h.address) like " + pattern + " order by h."
                        + criteria.getSortBy()).setMaxResults(criteria.getPageSize()).setFirstResult(
                criteria.getPage() * criteria.getPageSize()).getResultList();
    }

   // Note 2 : j'ai effacé du code ici pour ne garder que quelques méthodes

   // helpers
   private String getSearchPattern(SearchCriteria criteria) {
        if (StringUtils.hasText(criteria.getSearchString())) {
            return "'%" + criteria.getSearchString().toLowerCase().replace('*', '%') + "%'";
        } else {
            return "'%'";
        }
    }

}

Le plus intéressant est donc la méthode findHotels. Elle permet d’effectuer la recherche, de retourner une List d’Hotel à la vue, que nous verrons tout à l’heure si vous êtes toujours motivé.

III.2) Le contrôleur version Play! Framework

L’approche de Play! est un peu plus simple mais demande un peu plus de code Java.
Je précise tout de suite : j’ai modifié l’exemple afin de retirer la partie Authentification et pour ne me concentrer que sur le Use-Case de récupérer la liste des Hotel correspondant à un critère entré dans l’interface utilisateur.

public class Hotels extends Controller {

    public static void list(String search, Integer size, Integer page) {
        List hotels = null;
        page = page != null ? page : 1;
        if(search.trim().length() == 0) {
            hotels = Hotel.all().fetch(page, size);
        } else {
            search = search.toLowerCase();
            hotels = Hotel.find("lower(name) like ? OR lower(city) like ?", "%"+search+"%", "%"+search+"%").fetch(page, size);
        }
        render(hotels, search, size, page);
    }
   ...
    // Note : code effacé pour ne conserver que la méthode list
   ...
}

L’approche de Play! Framework est donc la suivante :
- écrire une classe dans le répertoire « controllers » qui étend la class Controller de Play!
- écrire une méthode public static avec en argument les paramètres de la vue. Play! se charge de vous récupérer ce que l’utilisateur a entré. Notez ensuite l’appel pour récupérer la liste des Hotels :

            search = search.toLowerCase();
            hotels = Hotel.find("lower(name) like ? OR lower(city) like ?", "%"+search+"%", "%"+search+"%").fetch(page, size);

La méthode find est une méthode statique définie dans la classe JPASupport. Elle permet d’exécuter des requêtes JPA. Vous pouvez aussi écrire une méthode dans l’entité Hotel pour éviter de placer ici du code technique par exemple. Les 2 approches se valent.

III.3) Différence d’approche

La version Spring WebFlow demande plus de XML, ce qui personnellement me dérange. Je trouve que la définition des flows n’est pas simple. C’est même une fausse bonne idée. Je préfère une approche fortement typée en Java, où par contre pour que la magie opère, je dois étendre des classes spécialisées de Play! Framework.

Côté test, il est assez simple de tester Spring WebFlow, mais je n’ai pas testé personnellement.

Je vais être méchant avec Spring WebFlow : je trouve cela bien compliqué pour résoudre un problème simple. Ici quel est l’apport du XML ? Des annotations ? Est-ce que notre vie est plus simple grâce à ce système ? Permettez-moi d’en douter.

C’est peut-être une révolution par rapport à l’approche Struts, mais tant qu’à faire la révolution, il ne faut pas s’arrêter à un concept basé sur un fichier XML pour définir la navigation d’une application Web.

III. 4) Synthèse

Avantages de Spring Web Flow

- possibilité de déclarer en quelques lignes un bout de code pour que la vue récupère le Model sans devoir définir un controller.
- gestion de la navigation de l’utilisateur fine dans le site
- se repose sur des Services facile à tester pour s’assurer que le Model est correct
- bien meilleur que l’approche classique où les DAO dans les Services ne servent à rien
- Spring MVC récupère les paramètres de la vue et les dénormalise, ce qui est très pratique.
- bonne intégration de la sécurité

Inconvénients de Spring Web Flow

- clairement plus compliqué que Play! sur ce point
- XML tu aimes ou tu n’aimes pas, mais c’est ton environnement de développement Web
- gestion pas facile pour les débutants entre les view-states, les action-states, les transitions etc.
- l’EntityManager à la main dans le service : pas top. Mais c’est quelque chose qui est souvent factorisé dans des classes de GenericService par exemple, avec un DAO… Bref encore 3 ou 4 classes Java en plus.

Avantages de Play! Framework :

- le controlleur déclare des méthodes static et public qui deviennent autant d’URL dans la vue
- le framework se charge de récupérer et dénormaliser les paramètres de la vue
- approche full java
- les entités ont un moteur comme GORM en Grails mais plus simple. Cela permet d’avoir des finders comme méthode statique sur l’entité Hotel. C’est cependant statique et plus limité que Grails/GORM.

Inconvénients de Play! Framework :

- le controller de base étend une class de Play! (si la spécialisation vous dérange plutôt que la composition)
- la gestion des workflows compliqué demande un effort de développement par rapport à Spring WebFlow, qui sera capable de retomber sur ses pieds.

IV. La Vue

Je vais maintenant évaluer plusieurs critères :
- la création d’une page pour chacune des technos
- la qualité de l’expérience utilisateur avec l’utilisation d’Ajax
- la taille des pages webs et les temps de chargement

IV.1) Créer une page avec Spring Faces

Basé sur JSF, cette partie sera donc essentiellement une discussion sur JSF plutôt que sur Spring. Je parlerai un peu de la taglibs de Spring pour la partie validation du côté client, que je trouve très bien fait. Mais l’essentiel du débat porte plus sur JSF ici.

Dans le projet Spring Webflow, les pages sont construites à partir d’un template, avec la technologie Facelets. Très pratique, cela vous permet de construire le canevas de votre site, puis de spécialiser vos vues en écrivant peu de code.

Le template standard.xhtml :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<f:view xmlns="http://www.w3.org/1999/xhtml"
      xmlns:ui="http://java.sun.com/jsf/facelets"
      xmlns:f="http://java.sun.com/jsf/core"
	  xmlns:c="http://java.sun.com/jstl/core"
	  xmlns:sf="http://www.springframework.org/tags/faces"
	  contentType="text/html" encoding="UTF-8">
<html>
<head>
	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
	<title>Spring Faces: Hotel Booking Sample Application</title>

	<sf:includeStyles/>
	<sf:resourceGroup>
		<sf:resource path="/css-framework/css/tools.css"/>
		<sf:resource path="/css-framework/css/typo.css"/>
		<sf:resource path="/css-framework/css/forms.css"/>
		<sf:resource path="/css-framework/css/layout-navtop-localleft.css"/>
		<sf:resource path="/css-framework/css/layout.css"/>
	</sf:resourceGroup>
	<sf:resource path="/styles/booking.css"/>
	<ui:insert name="headIncludes"/>
</head>
<body class="tundra spring">
<div id="page">
	<div id="header" class="clearfix spring">
		<div id="welcome">
			<div class="left">Spring Travel: A Spring Faces Reference Application</div>
			<div class="right">
				<c:if test="${not empty currentUser.name}">
	            	Welcome, ${currentUser.name} | <a href="${request.contextPath}/spring/logout">Logout</a>
				</c:if>
				<c:if test="${empty currentUser.name}">
	            	<a href="${request.contextPath}/spring/login">Login</a>
				</c:if>
			</div>
		</div>
		<div id="branding" class="spring">
			<a href="#{request.contextPath}"><img src="${request.contextPath}/resources/images/header.jpg" alt="Spring Travel"/></a>
		</div>
	</div>
	<div id="content" class="clearfix spring">
		<div id="local" class="spring">
			<a href="http://www.thespringexperience.com">
				<img src="${request.contextPath}/resources/images/diplomat.jpg" alt="generic hotel" />
			</a>
			<a href="http://www.thespringexperience.com">
				<img src="${request.contextPath}/resources/images/tse.gif" alt="The Spring Experience" />
			</a>
			<p>
			</p>
		</div>
		<div id="main">
			<ui:insert name="content"/>
		</div>
	</div>
	<div id="footer" class="clearfix spring">
		<a href="http://www.springframework.org"><img src="${request.contextPath}/resources/images/powered-by-spring.png" alt="Powered by Spring" /></a>
	</div>
</div>

</body>
</html>
</f:view>

La page « reviewHotels.xhtml » avec 52 balises HTML+JSF permet d’afficher la liste des Hôtels :

<!DOCTYPE composition PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<ui:composition xmlns="http://www.w3.org/1999/xhtml"
	    		xmlns:ui="http://java.sun.com/jsf/facelets"
	  			xmlns:h="http://java.sun.com/jsf/html"
	  			xmlns:f="http://java.sun.com/jsf/core"
	  			xmlns:sf="http://www.springframework.org/tags/faces"
				template="/WEB-INF/layouts/standard.xhtml">

<ui:define name="content">

<h:form id="hotels">
	<div class="section">
		<h2>Hotel Results</h2>
		<p>
			<sf:commandLink value="Change Search" action="changeSearch"/>
		</p>
		<ui:fragment id="searchResultsFragment">
			<div id="searchResults">
				<h:outputText id="noHotelsText" value="No Hotels Found" rendered="#{hotels.rowCount == 0}"/>
				<h:dataTable id="hotels" styleClass="summary" value="#{hotels}" var="h" rendered="#{hotels.rowCount > 0}">
					<h:column>
						<f:facet name="header">
							<sf:commandLink id="sortByNameLink" action="sort" value="Name" processIds="*">
								<f:param name="sortBy" value="name" />
							</sf:commandLink>
						</f:facet>
						#{h.name}
					</h:column>
					<h:column>
						<f:facet name="header">Address</f:facet>
						#{h.address}
					</h:column>
					<h:column>
						<f:facet name="header">
							<sf:commandLink id="sortByCity" action="sort" value="City, State" processIds="*" >
								<f:param name="sortBy" value="city" />
							</sf:commandLink>
						</f:facet>
						#{h.city}, #{h.state}, #{h.country}
					</h:column>
					<h:column>
						<f:facet name="header">Zip</f:facet>
						#{h.zip}
					</h:column>
					<h:column>
						<f:facet name="header">Action</f:facet>
						<sf:commandLink id="viewHotelLink" value="View Hotel" action="select"/>
					</h:column>
				</h:dataTable>
				<div class="buttonGroup">
					<sf:commandLink id="previousPageLink" value="Previous results" action="previous" rendered="#{searchCriteria.page > 0}"/>
					<sf:commandLink id="nextPageLink" value="More Results" action="next" rendered="#{not empty hotels and hotels.rowCount == searchCriteria.pageSize}"/>
				</div>
			</div>
		</ui:fragment>
	</div>
</h:form>
</ui:define>
</ui:composition>

Ce que j’apprécie à titre personnel avec JSF :
- possibilité d’écrire du code de mise en forme sans avoir besoin de faire trop de CSS
- moteur de construction de page assez proche d’une vue client lourd
- possibilité d’écrire avec la syntaxe JSF et d’avoir un rendu riche sans se prendre la tête avec du Javascript ou des feuilles de style.
<HUMOUR>De toutes les façons, je suis pas développeur Web. Donc mort aux CSS…</HUMOUR>

Ce qui me fait un peu tiquer, c’est que l’on dit au développeur Java : tu n’auras pas besoin d’apprendre à faire une mise en page compliquée en HTML et CSS…

Mais bon, vous vous foutez pas un peu de nous là ?

La page demande 52 balises. Et ce dataTable pourrait très bien être un simple TABLE en HTML avec une CSS non ? Ce qui d’ailleurs est le cas au final non ?

IV.2) Créer une page avec Play! Framework

Attention cela pique les yeux. Comme JSF ou Wicket, vous pouvez utiliser un éditeur HTML pour construire votre page. En effet, le format des pages de Play! Framework est très original puisque c’est du HTML ni plus, ni moins. Il y a cependant l’utilisation de Groovy qui risque de faire peur à quelques uns. Je note cela comme un inconvénient par rapport à JSF.

La version livrée avec Play! utilise jQuery et Ajax à fond. Il y a en fait une page principale, puis un ensemble de fonction Javascript pour ne charger rapidement que ce qui change dans un DIV au format HTML. C’est radicalement différent, et peut-être moins facile d’abord pour des gens n’ayant jamais fait de Web. Je vous montre donc plutôt ici ma version « gars qui a fait du Java et du Web et qui découvre Play »

Play! Framework dispose aussi d’un moteur de template. Je vais donc vous montrer 2 fichiers. Le fichier main.html est un template de base que j’utilise pour le site :

<!DOCTYPE html>

<html>
    <head>
        <title>#{get 'title' /}</title>
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
        <link rel="stylesheet" type="text/css" media="screen" href="@{'/public/stylesheets/main.css'}">
        #{get 'moreStyles' /}
        <link rel="shortcut icon" type="image/png" href="@{'/public/images/favicon.png'}">
        <script src="@{'/public/javascripts/jquery-1.3.2.min.js'}" type="text/javascript" charset="utf-8"></script>
        <script src="@{'/public/javascripts/sessvars.js'}" type="text/javascript" charset="utf-8"></script>
        #{get 'moreScripts' /}
    </head>
    <body>

        <div id="header">
            <h1>play framework booking demo</h1>
            #{if user?.id}
                <div id="options">
                    Connected as ${user.username}
                    |
                    <a href="@{Hotels.index()}">Search</a>
                    |
                    <a href="@{Hotels.settings()}">Settings</a>
                    |
                    <a href="@{Application.logout()}">Logout</a>
                </div>
            #{/if}
        </div>

        <div id="content">
            #{if flash.error}
                <p class="fError">
                    <strong>${flash.error}</strong>
                </p>
            #{/if}
            #{if flash.success}
                <p class="fSuccess">
                    <strong>${flash.success}</strong>
                </p>
            #{/if}

            #{doLayout /}

        </div>

        <div id="footer">
            Created with <a href="http://www.playframework.org">play framework</a> and really inspirated from the booking sample application provided by <a href="http://seamframework.org/">seam framework</a>
        </div>

    </body>
</html>

Voici la page qui affiche la liste des Hotels. Le fichier s’appelle « list.html » comme le nom de la méthode list du Controller Hotels que nous avons vu plus haut. Il est bien entendu possible de déclarer un nom différent et de configurer une autre route avec Play! Framework.

Le fichier est assez simple : il reçoit un objet List<Hotel>, il itère en Groovy avec un tag spécifique à Play et il affiche le résultat dans un tableau HTML :

#{extends 'main.html' /}
#{set title:'Search result'/}

#{if hotels}
<table>
    <thead>
    <tr>
        <th>Name</th>
        <th>Address</th>
        <th>City, State</th>
        <th width="8%">Zip</th>
        <th width="13%">Action</th>
    </tr>
    </thead>
    <tbody>
    #{list hotels, as:'hotel'}
    <tr>
        <td>${hotel.name}</td>
        <td>${hotel.address}</td>
        <td>${hotel.city}, ${hotel.state}, ${hotel.country}</td>
        <td>${hotel.zip}</td>
        <td>
            <a href="@{show(hotel.id)}">View Hotel</a>
        </td>
    </tr>
    #{/list}
    </tbody>
</table>
<p>
    <a id="nextPage" href="${page+1}">More results</a>
</p>
#{/if}

#{else}
<p>
    No more results
</p>
#{/else}

La version Play! est très dépouillée. L’inconvénient : il sera nécessaire dans les 2 cas (JSF comme Play!) d’apprendre la technologie de rendu et les tags pour travailler efficacement. Mais Play! n’est pas orienté composant comme JSF. Il n’y a pas d’utilisation de l’Expression Language, ici c’est Groovy. Ce moteur Groovy est un poil plus lent que Japid, un autre moteur Java qui est disponible pour Play!

Regardez aussi la liste des modules de Play! Framework. Il y a du lourd comme le support de Scala, le moteur NoSQL MongoDB, Guice, GWT ou le module Search avec Lucene (comme Hibernate Search en plus simple).

Un inconvénient de Play! pour les personnes qui n’ont jamais fait de Web : la mise en page et la partie CSS. Lorsque je monte un projet avec Play! Framework, j’utilise par exemple CSS 960 grid system. Je connais ces systèmes car j’ai un gros background Web. Pour le CSS, pour sélectionner des couleurs qui ne font pas vomir l’utilisateur, j’ai pleins d’outils comme Kuler d’Adobe pour préparer des styles… Donc pour moi qui suit très Web : je peux faire un truc joli avec Play! Framework. Je pourrai styliser mes tableaux sans soucis. Je pense que ce qui est bien avec JSF, c’est que cela vous aide à monter vos pages facilement, à construire vos formulaires ou vos tableaux sans devoir devenir une bête en HTML/CSS. Mais c’est un peu dommage, lorsque l’on voit le potentiel d’HTML 5 pour les années qui viennent.

IV.3) Expérience utilisateur

J’ai lancé les 2 applications et j’ai effectué une comparaison en tant qu’utilisateur. Je donne l’avantage à la version Spring Faces. Je trouve que la librairie de Spring de validation du côté client est très sympa.

En terme de rapidité, la version Play! Framework est vraiment plus réactive. Si je clique comme un dingue avec un script Selenium, la version Spring WebFlow est à la peine alors que la version Play! se tourne les pouces sans s’essoufler.

IV.5) Taille des pages Webs

La page d’affichage de la liste des Hôtels sur Spring WebFlow (cliquez sur l’image pour l’afficher en grand) :

La version Play! Framework :

Mes tests avec YSlow en effectuant 10 chargements de la page puis en prenant la moyenne :

Moyenne des temps de chargement de la page liste des Hotels pour 10 hotels:
- Play! Framework en mode Dev ou Prod : 0,234 secondes
- Spring WebFlow avec Jetty : 1.286 secondes
- Spring WebFlow avec Tomcat 6.0.20 : 1.092 secondes

Le mode Prod de Play! ne prend qu’un peu plus de temps à démarrer, mais je n’ai pas constaté de différence une fois le serveur lancé.

Volume de la partie HTML sans CSS/Images et temps de chargement :
Si je ne regarde que la partie HTML sans prendre en compte le temps de chargement des images, je teste réellement que la partie serveur.

Play! Framework : chargement de 3.1 kb en un temps moyen de 14ms
Tomcat+Spring : chargement de 14kb en un temps moyen de 52 ms

Donc pour un affichage similaire, vous voyez le souci ? la version Spring Faces de cette démonstration est 5 fois plus lourde et demande 4 à 5 fois plus de temps. Je ne dis pas qu’en général c’est le cas, mais pour notre exemple oui c’est le cas. Et nous sommes sur le même cahier des charges : afficher dans un tableau une liste d’Hôtel.

V. Conclusion

Si vous avez pris le temps de lire cet énorme article jusqu’au bout, merci. Revenez voir le code des deux version en détail. Téléchargez chacune des versions et donnez vos propres arguments techniques en faveur de l’un ou de l’autre.

J’ai envie de taper du poing sur la table : il est temps de revoir le développement Web en Java.
Le développement Web demande des compétences. Si vous ne les avez pas, ne prenez pas une techno pour couvrir vos lacunes. Apprenez à faire du Web. Désolé, le XML ne m’excite pas. Play! est plus facile à apprendre que toute la stack Spring que je vous ai présenté. Car elle est plus simple et tout aussi puissante.

Pour construire une application Web compliquée ou d’entreprise, est-ce que dans 5 ans nous ferrons toujours du JSF ? ou est-ce que nous ferrons du HTML+CSS+jQuery ? Je pose la question. Evidemment, Play! Framework doit encore faire ses preuves et on peut me retourner l’argument. Mais c’est plus simple, plus réaliste et plus facile à maintenir.

Le point faible de Play! par rapport à un framework comme Spring Faces+Spring WebFlow+JSF c’est qu’il faut plus d’efforts pour construire ses composants dans la partie vue. D’un autre côté, lorsque vous avez un framework aussi puissant que JSF, vous avez envie de prendre des tableaux avancés, des richTables, ou des composants plus puissants. Cela entraîne parfois le risque de prendre des composants qui font trop par rapport à un tableau simple. D’ailleurs, si vous ne preniez pas ces composants, quel intérêt à utiliser une librairie JSF ? Je pose la question.

Un risque est donc d’utiliser des composants riches trop facilement dans une application Web avec JSF. Vous vous retrouvez avec un tableau avec des colonnes triables, alors que vous n’en n’avez pas besoin. Et votre page pèse 15-20kb au lieu de peser 2-5kb, et demande de la mémoire et du CPU du côté serveur.

Le site « eXpress-Board » tourne sur la même machine que le blog « Le Touilleur Express » avec 3 parts chez Gandi, soit 768Mo. Le process Java tourne avec 128 Mo de mémoire, et prend entre 5 et 16% de l’utilisation de la machine, bien loin de MySQL qui est très sollicité par WordPress pour le Blog.

Je vais me faire taper par les maîtres Javas qui ne vont pas être d’accord. Mais c’est la première fois où j’en ai rien à faire, car je suis sûr de mes arguments.

Allez SuperTroll, sort du bois, je t’attends.

On va bien s’amuser…

Voir : http://www.rencontres-spring.com/

SpringSource lance une matinée de présentation le 4 novembre à la Défense (adresse plus bas).

En espérant vous compter parmi nous!

J’ai rencontré Adrian Colyer en Suisse, c’est une personne vraiment intéressante et riche. Si vous voulez vous plonger dans sa présentation de Jazoon 2009, vous pouvez relire cet article que j’ai écrit en juin dernier. Si vous êtes plutôt intéressé par Spring 3.0, j’ai aussi suivi la présentation de Jürgen Hoeller toujours à Jazoon.

Jurgen Hoeler SpringSource Jazoon 2009

Voici le plan de sa présentation:
- Java 5 Themes
- REST
- EL expression language
- Annotated web controllers
- RoadMap

Dans un premier temps, Jurgen Hoeler, que j’avais interviewé en novembre dernier, nous donne la vision de Spring. La version 3.0 sera tout d’abord le support de Java 5, avec l’utilisation massif des annotations. Il explique par exemple que dans Spring MVC, l’objectif est d’apporter les améliorations via les Annotations. Pour cette raison il nous encourage à utiliser celles-ci plutôt que le code classique pour les Controllers par exemple.
Le support de l’expression language (EL) permet d’offrir des fichiers XML et des classes encore plus configurable. L’exemple qu’il a prit nous montre ainsi une DataSource dont le nom exact de la base n’est connu qu’à l’exécution. Si vos fichiers de configuration XML de Spring sont déjà configurables à l’aide de propriétés externes, cela vous semblera familier.
Viens ensuite la présentation de REST. Dans l’architecture de Spring 3.0, le support de REST sera là, et vu le temps passé pour nous en parler, on pense à Java EE 6 et au profile Lite qui n’a justement pas… JAX-RS en standard.
Le support de la JSR-303 (Bean Validation) aussi présent dans Java EE 6, sera offert par Spring. Comprendre par là, que les annotations seront reconnues et que la validation des beans sera effectuée par le framework Spring. Intéressant à noter.
Les Portlets 2.0 retiennent mon attention, c’est l’un des sujets en ce moment chez mon client. Tout d’abord il explique que la spécification Portlet 1.0 étant assez incomplète, le support des Portlets 2.0 par Spring devrait permettre d’offrir un socle simple pour écrire des Portlets. Il cite JBoss Portal et eXo Portal.
Concernant le support de Java EE 6, Spring 3.0 attend la sortie de la version finale de Java EE 6. Tout ce qui est JSF2.0 et JPA2.0 ne sont donc pas encore prévu dans la version qui sortira… courant juillet. Tout du moins pas officiellement, mais en early preview.

Un retour sur Java 5 pour nous montrer ce qu’il y a de nouveau. Tout d’abord grâce aux génériques, le framework offrira un typage plus fort comme dans cet exemple:

BeanFactory returns typed bean instances as far as possible
T getBean(String name, Class requiredType)
Map getBeansOfType(Class type)

Concernant l’exécution de tâches asynchrones, Spring 3.0 proposera un TaskExecutor (ce n’est pas déjà le cas ?). La gestion des tâches asynchrones sera plus facile. Pas de mentions des Annotations.

A propos de Spring WebFlow : la nouvelle version propose une version révisée de la gestion du binding et de la conversion de type.
A propos ensuite (vous suivez ?) de la gestion des Annotations standards de Java, Spring offre le support des annotations du projet Java Config, la gestion de l’instanciation tardive des Beans avec le mot clé @Lazy.

A propos de l’Expression Language j’ai pris un exemple de l’un de ses slides pour vous montrer comment il serait possible d’injecter une proprieté à l’exécution :

@Repository
public class R {
	@Value("#{systemProps.dbname}")
	public void setDatabaseName(String dbName){
	...
	}

}

N’importe quel de vos Beans Spring est accessible avec l’EL, ce qui permet aussi de récupérer la valeur d’une propriété d’un autre Bean pour l’injecter en paramètre… Je ne vous parle pas des problèmes d’instanciations tardives, car il est tard.

Concernant le support de REST avec Spring 3.0 : Spring MVC offre un support de REST accessible facilement et qui permet d’ajouter à une application Spring MVC le support de REST. Par contre si vous souhaitez utiliser JAX-RS… ce n’est pas possible. C’est l’un ou l’autre… « On attendra de voir ce que les clients veulent »

@RequestMapping(value = "/rewards/{id}",nethod = GET)
public Reward reward (@PathVariable("id") long id){
	return this.rewardsService.findReward(id);
}

Du côté du code, on note aussi l’apparition d’annotations supplémentaires (youpi déjà qu’on avait terminé tout l’autre stock, sympa d’en remettre encore) pour par exemple lire les paramètres des entêtes HTTP ou des Cookies, ce qui peut être utile pour la gestion de la localisation par exemple. Les 2 annotations sont @RequestHeader et @CookieValue.

Conclusion
Voilà pour la présentation de Spring. Jürgen est un bon speaker qui présente son sujet de manière synthétique. On sent la pression pour sortir en juillet la version, avant la sortie en septembre de son copain Java EE 6. L’un n’ayant d’ailleurs rien à voir avec l’autre.

Next please !

PS: j’ai rectifé l’orthographe de Jürgen, il suffisait de regarder le premier slide au début de cet article.

Il y a plus de 10 ans, SUN Microsystems a eu l’excellente initiative de libérer le processus de définition du langage Java. L’objectif à l’époque était de prendre en compte les demandes grandissantes d’évolution des différents éditeurs du tout jeune langage Java. Rappelons que chaque JSR propose une implémentation de référence de la spécification, avec un code source accessible. Il faut aussi mettre au point un lot de tests afin de proposer un TCK (Technology Compatibility Kit).

Un match de boxe
Gavin King est spec leader de la JSR-299, spécification apparue début 2006 et qui est en phase finale, afin d’être livrée d’ici septembre 2009 dans la future version JEE6. Au début de cet année, la spécification initialement présentée comme WebBeans a été renommée « Java Context and Dependency Injection« . Derrière tout cela, les acteurs de la communauté avait noté que la spécification avait en effet évolué vers l’injection de service, le terme WebBeans était alors trop réducteur par rapport à la portée de la spécification. Pourtant en relisant ne serait-ce que les premières lignes de la JSR, on voit que le scope initial, intimement lié à JBoss Seam, était la gestion du cycle de vie dans une application Web…

La spécification a aujourd’hui bien évolué, et propose un standard d’injection de dépendances à Java EE 6. Preuve que le processus communautaire a du bon, il est claire que la future version entreprise de Java sera plus mature et plus flexible que les versions antérieures. L’effort du JCP, et je pense que les standards ont du bon, est que la spec JSR-299 offre un moyen standard donc portable d’apporter de l’injection de dépendance à une application d’entreprise. Je n’ai rien contre Spring, je pense qu’il est plutôt bon et raisonnable de conserver le système libre et d’offrir (tardivement) une spécification d’injection pour les services et les dépendances.

Un petit pavé
Crazy Bob jette un pavé dans la marre en annonçant le 5 mai dernier une proposition de JSR sponsorisée par Google, SpringSource,PicoContainer, Plexus, Tapestry IoC, et Simject en portant l’effort sur un scope plus réduit. Il souhaite proposer une spécification afin que l’injection de dépendance soit un standard dans Java SE 7 par exemple. Il pense même qu’il sera possible en 5 mois de finaliser cette JSR afin de l’inclure dans la future version de Java EE6. C’est tout simplement impossible, voir irréaliste. Cela entraine bien entendu une réaction un peu épidermique des personnes de la spécification JSR-299. Vous suivez toujours ?

Pourtant cette initiative n’est pas inutile car :
- elle offrirait une gestion de l’injection native dans Java
- elle ne nous forcerait pas à utiliser tout Java EE6
- elle reste pragmatique et ne se focalise que sur les points précis de l’IoC que tout le monde utilise (Guice, Spring…)
- elle nous permettrait de rendre portable notre code d’injection (Spring vers Guice, Guice vers Spring, Spring vers Spring…)

JSR-299 une marieuse
Nous avons d’un côté la JSR-299 qui est pour moi une marieuse : faire se rencontrer les différents composants de votre application d’entreprise, vous aider à faire collaborer votre application avec la gestion des sources externes. A ce titre je pense qu’il est indispensable d’avoir cela sous la forme d’une spécification. Cela en fait certainement l’une des JSR les plus complexes.

Le petit nouveau
D’autre part, nous avons des développeurs utilisateurs de Spring et de Guice qui souhaitent rendre standard l’injection de dépendance dans une spécification. Cela revient aussi à dire que tout le monde recevrait le support de l’IoC… même ceux qui s’en passent très bien.

Tout ceci ne vous intéressera que si vous faîtes appel à l’injection de dépendance, que vous le faîtes car vous souhaitez changer de framework d’IoC, que vous vous fichez du reste des excellents fonctionnalités dans Spring comme la gestion des abstractions (JDBC,JMS,Securité…), la programmation orientée Aspect, la gestion des Transactions, bref que vous ne vous intéressez QUE à l’injection de dépendance… Est-ce bien réaliste ?

N’oublions pas aussi les « mauvais » effet de la surinjection de dépendance. Nous avons tous vu une fois une application avec des fichiers de mapping obèses, où le framework d’injection de dépendance est sur-utilisé. Rien ne remplace une architecture propre et une bonne utilisation des patterns. Je ne suis pas un fan du « tout-Spring » comme je n’étais pas fan du « tout EJB ».

Alors à quoi servent les JSR ?

Le principe des spécifications ouvertes a apporté à Java une bouffée d’oxygène. Dès 98 cela a été le moyen de sécuriser les investissements des clients finaux. Grâce à la normalisation et aux standards, un code écrit en Java sur Windows et compilé avec la JVM de SUN fonctionne sur votre serveur Solaris, avec votre serveur d’application Oracle Weblogic et JRockit. Standard est donc synonyme de sécurité, d’indépendance et de pérennité dans le temps. Les JSR sont donc un ensemble de règles appuyées par une implémentation de référence, avec accès libre au code source, ce qui nous sécurise et évite de devenir dépendant d’un éditeur de logiciel.

La dure vérité
Deuxième effet notoire : il y a toujours quelqu’un de plus intelligent que vous. Il y a toujours un petit gars quelque part dans le monde qui a déjà eu cette idée géniale. Il y aura toujours un étudiant prêt à faire 60 heures par semaine pour coder une API. Il y aura toujours un Doug Lea ou un Gavin King avec un oeil d’artiste sur le code.
Java et donc les JSR vous apprennent une chose : vous êtes une m… et il va falloir faire avec. Non vous n’êtes pas génial à avoir pensé vous aussi à un framework d’inversion de contrôle. Le principe a été décrit en 1988 à ma connaissance. Non arrêtez d’écrire des classes comme « SynchronizedHashMap » et reprenez la lecture de la spécification Java.

Les spécifications sont donc un moyen de s’assurer que les meilleurs principes se diffusent et que la plateforme Java évolue. C’est un canal de diffusion de la connaissance, qui permet aux éditeurs et aux acteurs de la communauté Open-Source de travailler main dans la main (ou poing dans figure aussi) mais de travailler ensemble. Quelque part, je vois cela comme les tests indépendants EuroNCAP de crash-test des voitures. Mine de rien, en 10 ans nous avons tous un ABS et bientôt l’ESP sur nos voitures, car un organisme indépendant a décidé de noter les constructeurs sur la sécurité de nos voitures.

Conclusion
Les standards ont du bon, merci à CrazyBob de penser qu’une JSR pour une version light de l’IoC est une bonne idée. Par contre j’ai franchement du mal à me projeter dans 2 ans, et à imaginer un standard de facto pour l’IoC. L’approbation de cette JSR par l’Expert Group, dont fait partie RedHat (Gavin King) pour sortir d’ici 5 mois me semble tout simplement impossible. Mais comme je vous le disais : nous sommes bêtes et nous devons donc attendre patiemment que les gourous du JCP s’organisent afin de s’accorder sur cette JSR.

Messieurs de RedHat, de SpringSource et de SUN-Oracle : respirez un grand coup et revenez vous assoir afin de travailler ensemble, car le plus gros risque que court Java serait que ce processus soit remis en cause. Il faut que la communauté reste prudente et fasse la distinction entre ce qui est important pour faire évoluer Java, de ce qui est purement manoeuvre de noyautage. Il n’y a pas de guerre froide entre les grands acteurs (Oracle/SUN, RedHat/JBoss, Google, IBM et SpringSource) et il serait dommage de commencer à casser ce système.

Pour terminer allez lire les échanges entre Gavin King et Bob Lee :

http://in.relation.to/Bloggers/CommentsOnAnnotationsForDependencyInjection

La page sur la proposition de JSR Light sans sucre d’injection de dépendance :
http://google-code-updates.blogspot.com/2009/05/javaxinjectinject.html

Dans notre application cet après-midi j’ai vu un problème de déclaration de propriétés Spring au moment du chargement de mon application. Un fichier de Properties chargé par Spring lors du démarrage par un PropertyPlaceholderConfiguration n’était pas à jour, il me manquait 3 propriétés… soit.
Quelque part, je me demande si le fait de retarder finalement tardivement cette vérification est une si bonne idée. J’ai dû attendre le démarrage de mon application sur Weblogic et ensuite l’exécution de mon premier batch pour le voir…
C’est la vie.
Je n’ai plus qu’à aller m’immoler pour ne pas avoir pensé à mettre à jour mon fichier primeweb.properties…. ou pas.

Que se passerait-il avec un simple EJB ? Que se passerait-il avec du code classique old-school qui serait capable de me dire poliment que 3 propriétés ne sont pas renseignées ? Là pour tout vous dire, j’ai pris une grande exception en pleine face. Je regarderai demain comment au moins mettre un peu de vérification afin de rendre plus polie mon application.

Alors j’ai regardé le fichier application.xml… et il y en a du monde.
Un peu comme un car de supporter de l’OM/du PSG/de l’OL de retour d’un match, c’était un sacré foutoir pour comprendre comment dans ce sac de nœud personne n’avait été blessé jusqu’à maintenant. Il y avait au début du fichier une organisation assez simple avec un DAO, deux Beans déclarés normalement.
Et plus je suis entré dans ce fichier de configuration, plus j’ai eu du mal à comprendre les relations entre Beans… Un peu comme les acteurs d’un sitecom, on ne sait plus très bien qui couche avec qui… Il faut alors configurer votre IDEA (IntelliJ supporte très bien Spring) et il est ensuite tout à fait possible de comprendre les déclarations. Ce n’est pas la faute de Spring, c’est notre faute à nous. On est généreux, nous avons mis un peu tout et n’importe quoi sous la forme de Bean comme un groupe de junkie très excité à l’idée de s’injecter des dépendances…

L’inversion de contrôle est un concept franchement sympa tant qu’on garde le contrôle.
Inversion of Control is a nice concept if you keep some sort of control, copyright nicolas martignole pour la version pour l’export…
A vouloir trop retourner la responsabilité du code, est-ce que finalement nous n’avons pas mis dans un fichier XML un peu trop de choses ? Le prix à payer pour cette flexibilité très pratique lors des tests, est qu’une partie de la vérification qui était effectuée à la compilation, voir au démarrage de l’application, est maintenant pris en charge par Spring. Et ça, ça me dérange. Ce n’est pas la faute de Spring, c’est encore une fois notre faute à nous.
Pour peu que quelqu’un propose un outil, nous sommes tentés de nous en servir et un peu comme un enfant avec un pistolet ou un bouledogue avec un bébé : aie cela fait mal.

Les EJB3 ont un mérite : ils arrivent après la version actuelle de Spring 2.5. Et à ce titre, je commence vraiment à croire que c’est une option très sérieuse qui dans le cadre d’une application de gestion, est tout à fait convenable. J’ai hâte d’acheter et de lire le livre d’Antonio Goncalves du Paris JUG car je pense qu’il y aura du bons sens.

Spring reste un très bon framework qui ne fait pas que de l’IoC (Inversion of Control) mais aussi beaucoup d’autres tâches barbantes. La gestion de la partie JDBC, des templates JMS ou des Transactions : merci ! cela nous évite de devoir gérer une soupe technique peu intéressante.
Cependant pour certains cas (que je devrai préciser si j’étais un gars bien) je continuerai à faire du BoViCoJa (Bon Vieux Code Java) au lieu d’utiliser Spring.
Que l’on ne m’accuse pas de cracher dans la soupe, mais qu’en même temps les gens prennent conscience qu’il ne faut pas tout faire faire par Spring. Il sera parfois plus intéressant de faire du code classique et d’éviter de déclarer une Interface, puis une seule implémentation, pour ensuite l’injecter dans votre code.

Je vous parlerai la prochaine fois de notre copain NoClassDefFoundError et d’AspectJ, le tout mijoté avec du Maven2 et des problèmes de dépendance.

La version 1.0 a été annoncé en décembre dernier, Mark Fisher propose de vous montrer en 10 minutes comment écrire un service simple et faire fonctionner Spring Integration : http://blog.springsource.com/2009/02/13/982/.

Dans son post dont j’ai repris le code ci-dessous, nous déclarons un bean Spring et nous allons montrer comment envoyer un message via Spring Integration.

La configuration Spring importe le namespace de Spring Integration et permet de déclarer le bean Shouter :
 

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:si="http://www.springframework.org/schema/integration"
xsi:schemaLocation="

http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans.xsd

http://www.springframework.org/schema/integration

http://www.springframework.org/schema/integration/spring-integration-1.0.xsd">

<si:channel id="input"/>

<si:channel id="output">
<si:queue capacity="10"/>
</si:channel>

<si:service-activator input-channel="input" output-channel="output" ref="shouter" method="shout"/>

<bean id="shouter" class="blog.Shouter"/>

</beans>

Voyons le bean Java qui va recevoir notre message et y ajouter des points d’exclamation:

public class Shouter {
    public String shout(String s) {
        return s.toUpperCase().concat("!!!");
    }
}

Le code Java pour tester le tout est simple :

public static void main(String[] args) {
    ApplicationContext context = new ClassPathXmlApplicationContext("blog/config.xml");
    MessageChannel input = (MessageChannel) context.getBean("input");
    PollableChannel output = (PollableChannel) context.getBean("output");

    input.send(new StringMessage("Le Touilleur Express"));
    Message< ?> reply = output.receive();

    System.out.println("received: " + reply);
}

A quoi sert Spring Integration ?
Spring Integration permet de réduire le code technique de votre application. Vous lisez un message sur une queue JMS, vous voulez envoyer un email, vous souhaitez lire un fichier et le convertir vers un autre format, faire un traitement par batch, télécharger via FTP un fichier ou SSH, alors Spring Integration pourra vous intéresser.

Peut-on comparer Spring Integration à Mule ?
Pour qui connaît un peu Mule 2, la ressemblance est frappante. Ross Mason, l’auteur de Mule, a tenté un moment de se rapprocher de la communauté Spring, mais celle-ci a préféré offrir une solution basée exclusivement sur Spring. Il n’y a pas de comparaison possible au sens « l’un est mieux que l’autre ». Mule a cependant un peu plus de recul, dispose de beaucoup plus de connecteurs que Spring Integration pour l’instant. Sa communauté est assez active. Si vous souhaitez utiliser par exemple Tibco Rendezvous ou faire du SSH, il faudra utiliser Mule.
Je pense qu’il est intéressant de connaître les deux projets et de ne pas s’aventurer à faire un choix, s’il faut en faire un.

Est-ce que Spring Integration est un ESB ?
Non, je dirai que c’est un framework léger d’intégration comme Apache Camel, mais pas un ESB. Le produit OpenESB basé sur le serveur d’application Glassfish est un ESB, car il est composé d’une API d’une part et d’un moteur d’autre part. Mule est un ESB léger, il propose son propre moteur ou il peut fonctionner dans une application Web. Spring Integration est par contre une brique peut-être plus facile à mettre en oeuvre si vos besoins sont avant tout techniques.

Pour aller plus loin
Le site de la communauté muleForge : http://www.muleforge.org/
Le site de Mule 2 : http://www.mulesource.org
Article de Cyrille Le Clerc sur le blog de Xebia en 2007
Article de Sébastien Letélié d’Improve sur les ESB : Java Camp II DB and ESB

Pour les vieux lecteurs du Touilleur (pas ceux qui n’ont plus de cheveux, ceux qui me lisent depuis un an) vous savez sans doute que je connais bien Florent Ramière et Nicolas Romanetti de Jaxio dont je vous ai déjà parlé sur le Touilleur. C’est donc en toute subjectivité (et pas objectivité) que j’ai testé l’outil.

Je vous donne mon avis : pensez au temps gagné en utilisant un outil qui génère en 1 minute ce que vous pouvez écrire en une bonne semaine de travail…
Testez-le, faîtes-vous votre avis, pensez-y pour faire du refactoring de votre logiciel. Vous avez une base de données ? vous êtes curieux et prêt à vous remettre en question ? Alors rendez-vous sur http://www.springfuse.com

1. ESB in Financial Application

2. Objectif de la présentation

En quinze minutes, l’idée de cette présentation est d’expliquer les besoins rencontrés dans le monde de la finance en terme d’architecture. Où en sommes-nous aujourd’hui et quels outils pouvons-nous utiliser afin de réduire les coûts et améliorer nos architectures ?

3. Speaker’s Qualifications

Après 5 ans 1/2 chez Reuters, j’ai débuté une nouvelle activité en tant qu’indépendant. Je travaille actuellement chez BNP-Paribas sur une mission d’architecture. Je suis membre du Paris Java User Group.

4. ESB

ESB. Ce mot est à la mode. A Devoxx j’ai compté 4 conférences cette année. Mule est traité 3 fois par Antoine Borg avec qui j’ai eu le plaisir de discuter la veille, bref il se passe quelque chose. A noter qu’aucune conférence ne nous parle de téléphone portable, les thèmes cette année tournent autour de l’intégration, de la sécurité ou de SOA. Voyons un peu « dans la vraie vie » où nous en sommes aujourd’hui, car moi, plutôt que de parler de SOA ou d’ESB, j’aime bien parler du terrain avant tout.

5. A legacy application

Ce que l’on constate c’est que les applications vieillissantes dans le monde Java des applications de gestion et de la finance, se présentent avec un socle d’architecture bien connu. Autour d’une architecture trois-tiers, nous retrouvons souvent du Struts pour la partie Web, un serveur d’application avec encore beaucoup d’EJB 2.1, et les innovations des dernières années que sont Hibernate, Spring et JMS. Et il est clair que ce type d’architecture aujourd’hui en production est encore amené à perdurer pour quelques années.
Votre travail sera donc de faire vivre, d’améliorer ou de transformer ce type d’architecture.

6. A legacy application (cont.)

Dans la finance, une application web communique et échange des ressources avec le monde extérieur en utilisant un certain nombre de connecteurs techniques (boîtes vertes). Ce code est bien souvent du code développé au fur et à mesure des besoins. Il peut s’agir de lire un fichier, d’échanger via JMS avec une autre application, de faire appel à un web service, ou d’envoyer un email. Bref, du code massivement technique. Ce code est le socle de communication de chaque application de gestion.

7. Connect

Connecter.
Le besoin de Connecter différents systèmes. Ce besoin entraine un travail de médiation, de transformation et d’interconnexion entre systèmes. Je veux montrer ici qu’il y a forcément un besoin de connexion, au minimum avec une base de données relationnelles, mais bien souvent avec d’autres systèmes informatiques ou techniques. C’est une composante fondamentale de nos solutions, de ce que nous sommes appelés à développer.

8. Ecosystem

J’ai représenté sur ce slide une application financière typique de création de rapports, utilisé sur une plateforme de Prime Brokerage. Ce que nous voyons tout d’abord, c’est que cette application a besoin d’un environnement pour fonctionner, un écosystème. Cet écosystème est composé d’un grand nombre d’applications, maintenu par d’autres équipes que la mienne.
Mon application est représentée au milieu avec ses 3 services internes.

9. Ecosystem 2

Cette application utilise les données du marché ainsi qu’un service de tenue de Position. Aujourd’hui les échanges entre les systèmes s’effectuent avec des fichiers plats via des répertoires partagés ou via JMS. Dans le livre Enterprise Integration Pattern, une excellente présentation explique les avantages et les inconvénients de ces 2 types d’échange.

10. Ecosystem 3

Au delà des échanges de mon application, ce qui est encore plus intéressant c’est de constater que les autres applications échangent elles-aussi des informations entre elles. Il faut donc bien voir que nous sommes là face à un vrai réseau de communication, de médiation et d’échanges. C’est le coeur d’une architecture financière.

11. Ecosystem 4

Au final je dois prendre en compte que mon application cohabite, échange et transfert ses données avec un nombre assez important d’applications. Je ne rentre pas dans les détails de la partie métier, car l’idée ici n’est pas de vous donner un cours de finance des marchés, simplement d’expliquer que les systèmes sont massivement connectés en un réseau.

12. Ecosystem 5

… En forçant un peu le trait, je peux faire une analogie avec un réseau social comme FaceBook : mon application fait partie d’un réseau, d’autres applications m’envoient des messages, observent même les données que je produis sans que je ne le sache, il y a donc clairement un besoin important à résoudre : ce besoin de communication et d’échanges avec mes « amis ».

13. Collaborate

Collaborate en anglais, difficile à traduire avec le même sens en français.
Collaborer c’est apprendre à se connaître : lorsque mon application échange avec d’autres systèmes financiers, au delà du problème technique à résoudre il y aura une interaction humaine. Et donc, ESB ou non, SOA ou non, ce projet d’inter-communication doit s’accompagner de la définition d’une langue pour se comprendre, d’un média pour discuter et d’un contenu pour s’entendre.
Revenons un peu à notre application financière type pour parler d’un facteur très important : le temps.

14. Timebox and Adaptive

J’ai sélectionné ces deux photos du métro afin d’illustrer un facteur important dans les applications financières : l’importance de l’heure de la journée. Prenons le métro de Paris : le matin entre 07h00 et 09h00 il y a un métro chaque minute. A 14h il y a un métro toutes les 6 minutes. A 23h00 il y a une rame toutes les 15 minutes.
Le nombre de rame de métro par heure s’adapte selon les heures d’affluence.
Qu’en est-il de mon application financière ?
Chaque matin celle-ci a besoin de 10 fois plus de puissance qu’en pleine journée, car la génération des rapports doit s’effectuer à la fermeture du marché boursier, dans un intervalle de temps limité. Il n’est pas possible de lancer la génération tant que le marché est ouvert. D’autre part celle-ci doit s’effectuer avant l’ouverture du marché suivant, en Asie. De fait, nous nous retrouvons avec une architecture qui doit répondre à des demandes fluctuantes selon l’heure de la journée.
Mais le plus important est que notre application n’a pas le droit à une deuxième chance. Lorsqu’un bug survient, il faut que l’erreur soit corrigée avant l’ouverture du marché, et ce phénomène n’est pas contrôlable.
Enfin on constate que passé les quelques heures d’activité, la plateforme est ensuite peu sollicité en cours de journée.
Or le souci, c’est qu’aujourd’hui mon architecture n’est pas écologique : 16 serveurs de calcul de risk tournent en permanence, 4 serveurs d’applications sont sollicités pendant la journée mais l’utilisation des ressources est assez inégale durant la journée.
Il faut donc retenir que dans la finance, l’utilisation des ressources et la quantité des échanges avec les autres systèmes varient au cours de la journée. Cependant nous savons à l’avance nos besoins, et donc idéalement notre système devrait pouvoir s’adapter et se programmer comme le réseau de transport parisien.
Un site internet qui vend des ordinateurs pourrait être surpris de l’affluence de visiteur. Pas une application financière : il est possible de connaître à l’avance les besoins en énergie. Mais pourtant, il est difficile aujourd’hui de régler et d’adapter cette énergie.

15. Crisis

2008 marque le début d’une crise financière, qui aura un impact dès demain sur les budgets des projets dans le monde de la banque et de la finance. Nos besoins de connexions avec les autres applications financières demeurent. Je pense même qu’il y aura de nouvelles réglementations pour éviter certains dérapages de 2008. Vu la nervosité des marchés financiers, les calculs de VaR, de risque, d’appel de marge, de collatéral sur notre application de Prime Brokerage vont aussi certainement être plus intensif… Bref il va y avoir du sport en 2009.

16. Predictions for 2009

ll est donc facile d’imaginer ce qui nous attend : avec moins de budget, moins de liberté et plus de pressions, il va falloir trouver des solutions rapides, économiques et capables de faire réaliser des économies. Pour ma part, un calcul de risque c’est un appel de marge pour un client. Si la plate-forme sur laquelle je travaille peut traiter 50 000 calculs au lieu de 10 000 car mon architecture évolue, alors je ferai gagner de l’argent à mon client.
D’autre part, vu la morosité et la crise du secteur de la finance, je pense que les solutions pragmatiques seront les gagnantes de 2009. J’ai peur que de gros projets basés sur les ESB des constructeurs souffrent du même phénomène que les constructeurs automobiles. Les gens veulent une voiture ? ils achètent une Logan et pas le dernier 4×4 à la mode.
Votre application a besoin d’un ESB ? Peut-être que Spring Integration, Mule ou Apache ServiceMix seront suffisants pour vos besoins, que les gros projets sur 6 mois auront plus de mal en 2009 à être validé par les DSI. Il est temps d’être pragmatique et d’arrêter de rêver sur des besoins que les grands éditeurs d’ESB nous ont peut-être inventé, comme les éditeurs de serveur d’app en 2000… Etre pragmatique, économe, écologique, réaliste.

17. Toolbox

En 2009 je pense que vous lirez des articles, que vous testerez, que vous entendrez parler de ces produits : Mule, Apache Service Mix, Apache Camel, Spring Integration, OpenESB project Fuji, Apache Synapse, Apache CXF, Jboss ESB… car ce sont des solutions qui répondent à un besoin : l’intégration légère en entreprise.
Après la guerre des serveurs d’application il y a quelques années, je pense que la prochaine grande bataille sera sur ce front. Les éditeurs du monde open-source savent que la demande va exploser, car lorsque la crise est là comme en 2001, le monde open-source tire son épingle du jeu. En 2002 personne ne se souvient mais c’était la grande époque des articles sur Linux dans 01 informatique, le Monde informatique ect. L’administration français a alors fait un grand pas en sélectionnant des solutions comme JBoss Application Server pour traiter… nos déclarations de revenus.
Economies, pragmatismes, simplifications, réductions des coûts…

18. A New Approach

Alors si nous repensons à notre application de gestion du début, voici comment je la vois en 2009. Tout d’abord le Web tiers a été déporté de mon architecture. Je ne fais pas une application Web, je fais d’abord l’architecture d’une application de gestion. Le web ne me coûte pas cher, j’utilise des frameworks légers sur une recopie en lecture seule de ma base de données. Seule une petite partie du code métier est partagée avec mon espace de données principal.
Ensuite on voit que j’ai cassé ce gros rectangle : je pense que des services sans états et légers sont suffisants pour effectuer les traitements de mon application. Là où auparavant j’utilisais la base de données pour stocker des données de travail, j’utilise désormais un espace mémoire en cluster afin de répliquer les données nécessaires à mes traitements de calculs. Cela demande plus de mémoire physique mais quintuple les performances de traitements. La base de données relationnelle n’intervient que via un service d’historisation qui effectue des captures de données afin de sauvegarder les données les plus sensibles, essentiellement pour un problème légal. Notez que la base est un petit carré bleu, car finalement elle ne me sert plus à grand chose.
Ces services reprennent la boîte à outil dont nous avons parlé tout à l’heure. Plutôt que de chercher à faire une grosse boite qui fait tout (un ESB au sens de certains) je crée un ensemble de services qui discutent et s’échangent des données. Et plutôt que de tenter de résoudre les problèmes de communication avec les applications extérieurs, de tenter de mettre en place un gros chantier afin de mettre tout le monde sur la même plateforme, je conserve et respecte les systèmes extérieurs, je m’adapte à eux, eux ne s’adaptent pas à moi. Et là je sais que mon application pour 2009 pourra continuer à exister sans couter une fortune.
Il faut donc oublier ce rêve qui serait de migrer toutes les applications de mon réseau vers un seul et même système. Ce serait un risque si l’éditeur disparaît (ce qui n’est pas exclu en ce moment). Ce serait la plus belle décision pour dégrader massivement les performances : pourquoi un système extérieure serait plus rapide que ce que mes équipes ont développé ? Ce serait un risque technique, un risque en terme de sécurité, et finalement, il faudrait attendre 6 mois avant de voir ce type de projet de gouvernance sur les rails.

Pour revenir à l’image du métro parisien, je rêve aussi de louer de la puissance machine plutôt que de l’acheter en utilisant par exemple Amazon EC2 et une solution comme Elastic Grid pour piloter mon parc informatique. Pour cette raison mon nouveau système est découpé en services sans état afin de faciliter une migration partielle et rapide de certains services vers ces nouvelles plate-formes de calculs et d’hébergement. La première banque qui aura déployé une plateforme de calcul de risque hostée comme un service sur internet gagnera certainement beaucoup d’argent.
Economies, pragmatismes, simples, réduire les coûts, arrêter de croire au père noël, pensez sur 6 mois…

Code code code
Ensuite j’ai un slide technique pour montrer un exemple d’utilisation d’Apache Camel. Lors de la conférence je n’ai pas eu assez de temps pour les présenter. Je vous ferrai un article complet sur Camel prochainement, donc revenez en janvier pour voir la suite.

Keep it simple

Pour connecter plusieurs systèmes il est tentant de faire n’importe quoi, de faire au plus vite ou de chercher une solution chère et trop complexe pour un problème. Soyez simple et vous réussirez à développer une architecture qui fonctionne.

Ne pas faire de l’intégration pour en faire…
Comme ces messieurs dans la piscine : ne cherchez pas à faire de l’ESB pour en faire, et faites attention à votre environnement. Un ESB ne remplace pas une réunion de pilotage avec l’autre équipe en face qui fait « l’autre » produit.

Don’t buy a solution

N’achetez pas les yeux fermés une solution. Au contraire, il faut que vos équipes retroussent leurs manches, repensez à des solutions simples. Dans le monde des applications de gestion, et de la Finance, le temps est certes à l’économie, mais aussi à un pragmatisme souvent contraire à nos envies d’architectes et de consultants.

The End

En conclusion : nous avons discuté des besoins en architecture dans le monde de la finance : connecter, échanger et collaborer, inter-agir avec d’autres systèmes. Les solutions d’intégrations légères seront en 2009 un moyen de réduire les coûts en évitant d’écrire à la main du code technique sans valeur ajoutée. Je souhaite dépiler un message JMS et envoyer un email, Mule m’aide à le faire en quelques heures au lieu de perdre mon temps avec du code sans valeur. Face aux réductions de budgets, il est logique de penser que les solutions d’intégration dans la finance auront le vent en poupe en 2009. Et face à cette crise, il y aura encore plus de travail pour nous, avec encore moins de budgets, d’où la nécessité de s’outiller enfin correctement.

Fin de la présentation
————————————————

Which application server you use?

Petit sondage sur l’un des tableaux blancs installés au premier étage. Avec l’appareil photo de l’iphone mes photos étaient toutes plutôt ratées. J’ai trouvé sur flickr une image d’un des tableaux qui m’a valu une bonne discussion là-bas lorsque j’étais devant avec d’autres développeurs.

Voici le nombre de résultat par serveur d’application:

• - JBoss Application Server : 136 voix
• - Oracle WLS + BEA Weblogic : 75 voix
• - GlassFish : 78 voix
• - IBM WebSphere : 46 voix (j’adore « web fear »)
• - Plain Tomcat, Jetty, Resin : 148 voix
• - Geronimo : 5 voix
• - Spring App Server : 7 voix
• - SAP Application Server : 2 voix
• - JONAS : 3 voix

Bref avec Spring dm Server qui arrive sur ce marché, je pense que nous allons voir l’an prochain des batailles de discussions sur « mon mien il est meilleur que ton tiens » comme il y a quelques années…

Cela promet des heures de discussions sur les blogs.

N.Martignole et G.Laforge

C’est fait, le premier podcast du Touilleur Express est en ligne sur sa page dédiée. Le premier épisode vous propose d’écouter Guillaume Laforge, le chef de projet du langage Groovy. SpringSource a annoncé le 11 novembre dernier le rachat de sa société, G2One.inc. A l’occasion de la journée « Les Rencontres Spring » nous avons été invité par SFEIR à rencontrer plusieurs personnes de SpringSource. J’ai enregistré une petite interview de guillaume avec Olivier Croisier, auteur du blog « The Coder’s Breakfast« .

Voici des pointeurs vers des sujets abordés dans le podcast :

• article sur InfoQ
• Le Blog de Guillaume
• The eXo Platform
• Benjamin Mestrallet, fondateur d’eXo, gagne le prix du jeune dirigeant de la Technologie

A venir prochainement : interview avec Peter Cooper-Ellis. La qualité n’étant pas assez bonne, je vous proposerai une transcription de notre rencontre avec Peter prochainement.

En attendant voici une photo prise chez SFEIR, avec donc de gauche à droite : Peter Cooper-Ellis, moi-même et enfin Olivier Croisier.

Interview Peter Cooper-Ellis avec Nicolas Martignole et Olivier Croisier