Un précédent article a exposé les grands principes de la sérialisation avec Thrift et Procotol Buffers. Ces deux frameworks promettent notamment une représentation des messages optimisée en termes de taille, ce qui est avéré dans le benchmark JVM Serializers : Thrift et Protocol Buffers y obtiennent une réduction de taille du message de 73% par rapport à la sérialisation native Java. Ce benchmark regroupe par ailleurs de nombreux autres frameworks de sérialisation du monde Java, mais se limite toutefois à l’utilisation d’un unique message de test.

Le présent article analyse l’influence de la structure (nombre et taille des objets, complexité de la grappe) sur la compacité du message sérialisé pour Thrift et Protocol Buffers. La comparaison est réalisée en Java, son protocole de sérialisation standard servant de référence.

Conditions du test

Afin d’évaluer diverses structures de messages, le prototype utilise une structure arborescente. Traditionnellement, ce type de structure est récursif. Cependant, il n’est pas compatible avec la limitation de Thrift sur la déclaration avancée abordée dans le précédent article.
La profondeur a donc été arbitrairement limitée au niveau 6, soit 127 nœuds au maximum pour un arbre binaire complet. Il y a un type différent par profondeur, de Node0 pour la racine à Node6 pour les feuilles les plus basses. Les arbres générés le sont selon trois paramètres :

• le nombre total de nœuds, qui permet de faire varier le nombre d’objets du message,
• la cardinalité des fratries , qui joue sur la complexité : plus cette cardinalité est faible pour un nombre de nœuds donné, plus les fratries sont petites et nombreuses, donc plus le message est complexe,
• et la taille des nœuds, qui est fonction du champ « description ». Son contenu est une chaîne de caractères différente pour chacun d’eux et générée par décalage des valeurs Unicode des caractères.

La construction des arbres se fait récursivement et équitablement entre les fils d’un nœud. Ci-dessous trois exemples d’arbre à 5 nœuds avec, de gauche à droite, des tailles de fratries de 1, 2 et 3. Les numéros sont présents à titre indicatif et indiquent l’ordre de création des nœuds par l’algorithme de construction.

Les déclarations dans les IDLs Thrift IDL et Protocol Buffers language sont disponibles en fin d’article. Les versions utilisées sont 0.8.0 pour Thrift, 2.4.1 pour Protocol Buffers et HotSpot 1.6.0_29 pour la JVM.

Impact du nombre d’objets du message

Dans un premier temps, la complexité est fixée au minimum :

• La longueur des descriptions de chaque nœud est constante (32 caractères),
• le nombre de nœuds est variable,
• la structure choisie est le 1024-tree qui équivaut à un arbre à deux niveaux dans cette étude.

En effet, si la cardinalité des fratries est supérieure au nombre de nœuds n, on obtient un arbre à deux niveaux, une racine Node0 et n-1 enfants Node1. Les 1024-trees de cet article ont tous cette structure car n est toujours inférieur à 1024.

Tracer la taille du message sérialisé en fonction du nombre de nœuds donne le graphe suivant :

Aussi bien sur cet histogramme que sur les suivants, une barre plus basse correspond systématiquement à un meilleur résultat et l’ordre des barres (de gauche à droite) correspond à celui de la légende (de haut en bas).
Sur ce premier graphique, on retrouve un constat du benchmark Java Serializers, mais dans un contexte de message plus complexe : Thrift et protobuf ont des performances très proches.

Le graphique ci-dessous rapporte leurs résultats à ceux de la sérialisation Java. On constate que leur avantage en termes de taille de message s’amenuise à mesure que l’arbre grossit.

Sur le graphique suivant, on observe que la taille moyenne d’un nœud décroît rapidement pour la sérialisation Java. En effet, le protocole de sérialisation Java ajoute aux informations du message lui-même la description des classes sérialisées. Ce surcoût, important pour un petit message, devient négligeable pour des messages constitués de nombreux objets du même type.

Les protocoles de protobuf et Thrift, quant à eux, contiennent très peu d’information de structure : uniquement un identifiant de champ et un type. Ainsi ils voient la taille moyenne d’un nœud croître légèrement, car les listes d’enfants augmentent en nombre et taille quand l’arbre grossit.

Impact de la taille des objets

Pour ce second test, on fige la structure du message pour mesurer l’influence de la quantité d’information contenue dans chaque nœud :

• Un 1024-tree est considéré comme dans le test précédent,
• sa taille est fixée à 31 nœuds,
• la taille du champ « description » est utilisé comme variable.

Les résultats concernant la taille du message sont similaires au test précédent, Thrift et protobuf sont très proches et font mieux que la sérialisation Java surtout pour de petits objets.

Figer la structure du message montre que la différence de taille par rapport au protocole de sérialisation Java est quasi-constante. Ceci est dû au fait que protobuf et Thrift n’apportent aucun gain notable lorsqu’on fait varier la taille de la chaîne de caractères.
En effet, les trois protocoles en jeu la sérialisent sous forme de chaîne en UTF8 précédée de sa longueur. La différence est que le protocole Java utilise 2 octets pour la longueur des chaînes de moins de 2^16 caractères, tandis que les deux frameworks ont recours à un varint. Le saut entre 64 et 128 caractères est dû au fait que le format varint n’utilise qu’un octet pour coder les entiers entre 0 et 127, puis deux de 128 à 2^14.

Impact de la structure du message

Pour évaluer l’influence de la structure du message :

• la description de chaque nœud est fixée à 32 caractères,
• le nombre de nœuds est variable,
• la cardinalité des fratries prend trois valeurs : 2, 4 et 1024.

Par exemple, voici les trois variations considérées de l’arbre à 7 nœuds :

Le graphique qui suit recense les tailles des messages sérialisés.

Pour tous les protocoles de sérialisation, le comportement est similaire : plus de complexité conduit à un message sérialisé moins compact.
Cela est dû au fait que plus de complexité se traduit par un plus grand nombre de listes de noeuds-enfants. Cependant, la variation reste négligeable (environ 1%) pour Thrift et protobuf.

Le protocole de sérialisation Java est lui plus fortement influencé (jusqu’à 13%). En effet la quantité d’information utilisée par les descripteurs de classes est liée au nombre de types de classes mises en jeu. Plus les fratries sont grandes, moins on utilise de classes différentes. Par exemple, pour 63 nœuds, le 2-tree utilise toutes les classes de Node0 à Node5, le 4-tree s’arrête à Node3, et le 1024-tree à Node1.
Le résultat particulièrement bon du 2-tree de taille 127 est lié au fait que Node6 n’a pas de liste d’enfants et est donc plus compact que les autres types de Nodes. Dans cet arbre, la majorité des nœuds (64) est de type Node6.

Les tailles moyennes par nœud sont représentées dans l’histogramme ci-dessous :

L’évolution est conforme aux observations du premier test : l’écart entre Java et les deux frameworks s’amenuise lorsqu’on augmente la taille du graphe sans pour autant être négligeable.

En traçant le gain apporté par les deux frameworks par rapport à la sérialisation Java on obtient :

Par exemple, en considérant le message du 4-tree à 63 nœuds et un système devant soutenir une charge de 10000 requêtes/s, le remplacement de la sérialisation Java par Thrift permet de diminuer le besoin de bande passante de 75.45 Mo/s à 40.68Mo/s, soit un gain de 46%.

Conclusion

Cet article a présenté une comparaison portant sur la taille de sérialisation avec des messages complexes. Par rapport au benchmark JVM-serializers, l’avantage de Thrift et protobuf sur la sérialisation native Java est moins décisif en termes de compacité, même s’il reste intéressant.

La taille du message sérialisé par Thrift ou Protocol Buffers n’est pas influencée par la structure même du message. C’est surtout son volume qui a un impact : les deux frameworks offrent une sérialisation bien plus compacte que celle de Java surtout sur de petits messages. Cette observation rejoint le fait que Protocol Buffers n’est pas particulièrement adapté aux volumes de données importants.

Il faut rappeler qu’employer la sérialisation native Java comme référence n’est légitime que parce que cet article se limite aux protocoles de sérialisation. Thrift et Protocol Buffers offrent d’autres avantages tels l’interopérabilité avec plusieurs langages et la compatibilité ascendante et descendante des messages. Ils sont abordés dans l’article précédent.

Pour aller plus loin, on pourrait analyser les temps de sérialisation, l’empreinte mémoire, l’intégration aux processus de build…

Annexes

Voici la déclaration des objets en Thrift IDL : tree.thrift

namespace java com.octo.example.serialization.model.thrift

enum RoomType {
        SINGLE =0,
        DOUBLE =1,
        SUITE =2
}
struct Node6 {
    1: optional i32 number,
    2: optional bool even,
    3: optional double rate,
    4: optional RoomType type,
    5: optional string description,
}
struct Node5 {
    1: optional i32 number,
    2: optional bool even,
    3: optional double rate,
    4: optional RoomType type,
    5: optional string description,
    6: list children,
}
[...]

et ainsi de suite jusqu’au Node0, qui correspond la racine de l’arbre. L’ordre employé évite le recours à la déclaration avancée.

Ci-dessous, l’équivalent en Protocol Buffers language : tree.proto

package serialization;

option java_package = "com.octo.example.serialization.model";
option java_outer_classname = "LimitedTreeProto";

enum RoomType {
    SINGLE =0;
    DOUBLE =1;
    SUITE =2;
}
message Node0 {
    optional int32 number =1;
    optional bool even =2;
    optional double rate =3;
    optional RoomType type =4;
    optional string description = 5;
    repeated Node1 children = 6;
}
[...]
message Node6 {
    optional int32 number =1;
    optional bool even =2;
    optional double rate =3;
    optional RoomType type =4;
    optional string description = 5;
}

L’ordre des nœuds plus naturel est supporté par le compilateur Protobuf.

Suggestion d'articles :

1. Sérialisation : Thrift et Protocol Buffers, principes et aperçu
2. Socle technique des applications Java EE : dans le WAR ou dans le serveur ?
3. Les nouveautés du langage dans Java 7

Préambule

Les applications Web enrichies, utilisant JavaScript pour mettre à jour tout ou partie d’une page web, sont officiellement nées en 2005 avec l’apparition du terme Ajax, et sont aujourd’hui communes. De ce concept sont ensuite nées les applications JavaScript « Single Page Interface », modèle dans lequel rentre l’application typique GWT. Le framework propose aujourd’hui un modèle de programmation au juste milieu entre les paradigmes du développement RDA (pour Rich Desktop Application) et du développement Web. Après compilation, une application GWT devient une application JavaScript tout à fait standard du point du vue du browser.

Les applications Ajax n’introduisent pas de nouvelles failles de sécurité. Techniquement, les risques et les techniques d’exploitation sont les mêmes. Si certaines failles sont affaiblies par le modèle, d’autres ont vu leur terrain de jeu évoluer.

Le but de cet article et d’un autre à venir est de rappeler les failles de sécurité qui concernent tout particulièrement la portion JavaScript – et donc GWT – de nos applications Web, puis de présenter les réponses qu’il convient de mettre en œuvre dans une application GWT pour contrecarrer les éventuelles attaques.

En point de départ, nous nous appuierons sur l’OWASP & son top ten 2010 des failles de sécurité des applications Web :

1. Injection
2. Cross-Site Scripting (XSS)
3. Broken Authentication and Session Management
4. Insecure Direct Object References
5. Cross-Site Request Forgery (CSRF)
6. Security Misconfiguration
7. Insecure Cryptographic Storage
8. Failure to Restrict URL Access
9. Insufficient Transport Layer Protection
10. Unvalidated Redirects and Forwards

Deux de ces failles potentielles nous concernent tout particulièrement dans une couche Ajax : les failles XSS [2] et CSRF [5]. Elles auront dans ce contexte la particularité sympathique de rendre l’application vulnérable quelles que soient les protections mises en place uniquement côté serveur. Leur compréhension et la connaissance des mécanismes de protection par le développeur sont donc essentielles. Dans ce premier article, nous nous focaliserons sur les attaques de type CSRF.

A l’écriture de ces lignes, la version courante de GWT est la 2.4.

CSRF : Cross Site Request Forgery

Traduire avec élégance par « falsification de requête inter-site ».

Une attaque CSRF consiste à utiliser les autorisations qu’a un utilisateur sur un site donné contre son gré. Il s’agit de construire sur un domaine sous le contrôle de l’attaquant une requête vers le site attaqué ; la requête sera soumise par le browser de l’utilisateur victime, et exécutée avec les droits de ce dernier. Si le cookie permet de s’assurer que la requête provient du browser du bon utilisateur, il ne permet pas de vérifier que l’appel provient du bon site…

La same origin policy

Petit rappel des règles du jeu. Tout browser se doit de restreindre les capacités de JavaScript à la same origin policy. Cette règle rend impossible un appel asynchrone via XMLHttpRequest sur un autre domaine. Toute manipulation du DOM est aussi restreinte : une iframe ayant pour source une page sur un autre domaine ne sera ni lisible ni pilotable par un script de la page parente.

Il s’agit bien d’empêcher la lecture d’une requête provenant d’un autre domaine : initier la requête est possible (et heureusement), pas traiter son résultat. C’est sur cet état de fait que s’appuient les attaques CSRF.

Une attaque CSRF typique : c’est l’histoire d’un steak

Plantons le décor. Ghislain est boucher, sur son site myboucher.com, il vend des bavettes. Georges, qui possède une brasserie, est son premier client. Richard est boucher lui aussi, mais jalouse Ghislain. A ses heures perdues, il lit des articles underground de l’internet mondial. Et agit secrètement sur iamthevilain.com.

Voici l’histoire de son attaque contre le site de Ghislain. Georges est sa première victime.

1. Georges se connecte sur myboucher.com. Il s’authentifie : login/mot de passe, qui ne seront pas divulgués dans cet article. Son browser reçoit alors un cookie de session ; ce dernier sera systématiquement envoyé par toute requête sur myboucher.com
2. Ce qu’il a fait sur myboucher.com précisément ne nous regarde pas, mais il ne s’est pas déconnecté. Plus tard, du fait d’un mail d’origine inconnue, il atterri sur la page http://iamthevilain.com/hack-myboucher.action . Sur cette page se trouve un formulaire qui correspond très précisément à celui qui est existe sur myboucher.com pour supprimer l’intégralité des informations du compte de l’utilisateur courant. Les champs sont identiques, et l’attribut HTML action du formulaire pointe sur la page correspondant à la suppression sur myboucher.com. Le formulaire est placé dans une frame invisible.
3. Un code JavaScript soumet automatiquement le formulaire, en JavaScript, sans que Georges ne fasse quoi que ce soit. Une requête POST parfaitement valide, ordonnant une suppression de compte est alors soumise à myboucher.com, avec le cookie qui authentifie Georges. Notre brasseur n’a plus de compte, et du fait de la frame, il ne s’est aperçu de rien.
   Ghislain perd bon nombre de ses comptes utilisateurs, sans pouvoir fournir à ces derniers la moindre explication.

Il est à noter que l’attaque CSRF n’a de sens que sur des utilisateurs connectés avec des droits spécifiques (dans 99,72% des cas). D’ailleurs, elle est d’autant plus dévastatrice que la victime a de droits sur le site. L’ensemble des protections est basé sur le fait que la victime potentielle dispose d’une session sur le serveur.

CSRF & HTTP

Dans le scenario ci-dessus, j’ai volontairement pris l’exemple d’une action nécessitant une requête POST. L’attaque CSRF la plus basique se base sur une requête GET. En effet, pour faire une requête GET sur un autre domaine sans que l’utilisateur ne puisse s’en apercevoir, il suffit d’utiliser une frame, une image… C’est possible dans un simple mail !

Sauf qu’une telle attaque CSRF ne devrait pas avoir de sens : une action d’écriture ne devrait jamais être faite via une requête GET. Une requête GET doit toujours pouvoir être exécutée sans mettre en question l’intégrité de vos données. C’est un des principes de HTTP (cf. la RFC), sur lequel est basée la conception des moteurs de recherche, des browsers, etc… Par exemple, un browser aura le droit de précharger les ressources trouvées en lien sur une page : imaginez les dégâts d’un simple lien « supprimer mon compte ». Derrière ce lien devrait en fait se cacher un formulaire HTML et une requête POST. Pour cette raison, ce sont uniquement les requêtes POST que nous voudrons protéger.

Utiliser le referer ? Non

Dans la définition d’HTTP se trouve un champ de header destiné à contenir l’URL de la page qui a initié la requête pour le browser, il s’agit du referer. C’est ce champ qui permet par exemple aux outils de statistiques de dire d’où vient un visiteur. On pourrait dès lors vouloir s’appuyer sur ce champ pour se prémunir des CSRF. Lors d’une soumission de formulaire depuis un site étranger, le referer devrait normalement contenir l’url de la page dans laquelle se trouvait le formulaire initial. C’est ce « normalement » qui nous arrêtera là. Dans la pratique, le referer ne sera pas toujours alimenté, de plus, certaines versions d’Internet Explorer et du player Flash contiennent des failles permettant la construction d’attaque CSRF avec manipulation des headers.

Les techniques de protection.

Dans une application WEB standard, les requêtes POST sont soumises par les formulaires, et la protection aux CSRF passe par l’utilisation d’un jeton. Ce dernier est généré de façon non prédictive côté serveur, et conservé dans la session utilisateur (ou directement construit à partir de l’identifiant de session, typiquement un hash). Il est donc associé à une session donnée. Lors de la construction d’un formulaire dans une page HTML, toujours côté serveur, il est injecté dans un champ caché (<input type= »hidden » … />). Sa présence est vérifiée à la soumission du formulaire. Du fait de la same origin policy, il est impossible à l’attaquant potentiel de récupérer un jeton. Il ne peut dès lors plus construire un formulaire contenant un jeton valide pour une quelconque session existante.

Les applications Ajax utilisent l’objet XMLHttpRequest pour faire des appels HTTP sans recharger la page web, et traiter le résultat de façon asynchrone. Si elles ne sont pas faites de la même façon, il s’agit des mêmes requêtes POST que celles des formulaires. La technique de protection sera la même, et il faudra utiliser un jeton conservé en session. XMLHttpRequest permettant la manipulation des headers HTTP, cette capacité sera souvent utilisée pour glisser le jeton dans un header dédié et ne pas polluer le corps de requête.

La plupart des frameworks web classique récents (Rails, Django, Symfony, ASP.NET MVC, ou encore Seam dans le monde Java, dont les frameworks sont plus globalement de mauvais élèves) proposent une solution de jeton intégrée aux formulaires, plus ou moins transparente pour le développeur. A contrario, les frameworks JavaScript, s’ils simplifient généralement les opérations de requêtes asynchrones, n’apportent pas de solution prémâchée. « Normal », puisque cette intégration passe aussi par l’implémentation côté serveur. A noter le cas de Rails, qui intègre nativement une protection pour la partie Javascript : le token est fourni via une balise dans le HTML, et l’objet JavaScript XMLHttpRequest est enrichi par le framework pour que le token soit systématiquement glissé dans les headers HTTP. Comme pour un formulaire standard, l’ensemble est totalement transparent pour le développeur !

GWT dans cet environnement a un côté vicieux. Le développeur GWT écrit bien souvent des requêtes RPC, et « ignore » le fait que ces requêtes sont techniquement des requêtes POST tout à fait standards, utilisant l’objet XMLHttpRequest. On pourra d’ailleurs faire un rapide aparté sur les applications basée sur Flash, et donc Flex, qui utilisent les mêmes requêtes, sans que les frameworks communément utilisés ne poussent de solution intégrée.

Que faire avec GWT ?

GWT-RPC

Il convient tout d’abord de souligner que GWT propose nativement une première ligne de défense en RPC. Le nom d’un des fichiers chargés par le bootstrap interne GWT (pour être plus précis, le nom de la permutation correspondante dans le mécanisme de Deferred Binding du compilateur) est systématiquement envoyé dans un header HTTP dédié lors de toute requête RPC (qui est encore une fois une requête faite via XMLHttpRequest). En son absence ou cas de valeur inattendue, la servlet lance une SecurityException ; le traitement s’arrête là. Ce simple ajout du header complique la tâche au potentiel attaquant. En effet, l’attaque CSRF par requête POST passe par la soumission d’un formulaire, le XMLHttpRequest cross-domain est interdit. Or l’ajout d’un header HTTP n’est pas possible dans un formulaire HTML.

Cependant, comme nous l’avons vu lors de l’élimination du referer dans notre stratégie de sécurisation, des configurations permettront cet ajout. Il ne suffit donc pas pour une protection exhaustive.

Depuis sa version 2.3, le framework propose un mécanisme plus complet. C’est un hash MD5 de l’identifiant de session qui est envoyé avec les requêtes RPC, sa présence est automatiquement contrôlée par le service GWT. L’interface d’un service protégé et son implémentation hériteront respectivement d’une interface et d’une classe spécifique. Enfin, une servlet sera dédiée à la récupération du jeton. La mise en place exacte d’un service RPC jouissant de ce mécanisme passe par les opérations suivantes :

Définition de l’interface du service

// à noter que les développeurs GWT ont préféré l'appellation XSRF - plus rare - à CSRF
public interface SecuredService extends XsrfProtectedService {
	void doSomethingReallyImportant();
}

Implémentation du service

public class SecuredServiceImpl extends XsrfProtectedServiceServlet implements SecuredService{

    @Override
    public void doSomethingReallyImportant() {
        yeahNowWeAreReallyGonnaDoIt();
    }

    // [...]

}

Déclaration de la servlet délivrant le jeton (token)

Dans le web.xml :

<context-param>
	<param-name>gwt.xsrf.session_cookie_name</param-name>
	<param-value>JSESSIONID</param-value>
</context-param><servlet>
	<servlet-name>XsrfTokenServiceServlet</servlet-name>
	<servlet-class>com.google.gwt.user.server.rpc.XsrfTokenServiceServlet</servlet-class>
</servlet>
<servlet-mapping>
	<servlet-name>XsrfTokenServiceServlet</servlet-name>
	<url-pattern>/xsrfTokenService</url-pattern>
</servlet-mapping>

Définition du nom du cookie à utiliser

Le nom du cookie à utiliser est aussi déclaré dans le web.xml. Au besoin il serait possible de créer un cookie dédié à cela, indépendamment de la session.

<context-param>
	<param-name>gwt.xsrf.session_cookie_name</param-name>
	<param-value>session-id</param-value>
</context-param>

Utilisation du service sécurisé

L’utilisation du mécanisme se fait en deux phases dans le code GWT. Il faut d’abord récupérer et stocker quelque part le jeton.

private XsrfToken xsrfToken;

public void fetchXsrfToken() {
	XsrfTokenServiceAsync xsrfTokenService = GWT.create(XsrfTokenService.class);
		// ces interfaces sont fournies par le SDK avec la servlet

	((ServiceDefTarget) xsrfTokenService).setServiceEntryPoint("xsrfTokenService"); // défini
	xsrfTokenService.getNewXsrfToken(new AsyncCallback() {
		public void onSuccess(XsrfToken result) {
			xsrfToken = result;
		}

		public void onFailure(Throwable caught) {
			// une RpcTokenException peut notamment être levée si le cookie
			// est inexistant ou vide

			// [...]
		}
	});
}

Il doit ensuite être injecté aux instances de services d’appel asynchrone.

SecuredServiceAsync securedService = GWT.create(SecuredService.class);
((HasRpcToken) securedService).setRpcToken(xsrfToken);
securedService.doSomethingReallyImportant(new AsyncCallback() {
	@Override
	public void onFailure(Throwable caught) {
		// [...]
	}

	@Override
	public void onSuccess(Void result) {
		// [...]
	}
});

Tous les détails sont documentés dans la Javadoc de la servlet XsrfTokenServiceServlet.

L’utiliser, ou pas ?

Cette même Javadoc commence par l’avertissement suivant :

EXPERIMENTAL and subject to change. Do not use this in production code

Il est fort probable que les développeurs de GWT souhaitent l’intégrer de façon plus transparente, plus élégante et plus propre au framework. On pourrait entre autres générer le hash MD5 du cookie côté GWT.

Que faire en attendant ? Notre préconisation est de préférer l’utilisation de ces classes « expérimentales » si vous souhaitez vous défendre contre ce type d’attaque. Une implémentation de votre cru fera le job, mais vous n’y gagnerez rien. Si une version future de GWT propose une solution mieux intégrée, nul doute que le refactoring sera mineur…

Si jamais, pour une raison ou une autre (je pense notamment au refactoring d’une application existante), la récupération asynchrone du jeton vous pose problème, l’objet Dictionary permet de récupérer une variable définie dans la page HTML hôte de l’application GWT. Il suffit alors de délivrer cette page via une servlet (ou autre si vous avez déjà…) et d’y injecter le jeton.

RequestBuilder et RequestFactory

Un petit avantage des applications Ajax pour lutter contre les CSRF est, encore une fois, que l’objet XMLHttpRequest permet la manipulation des headers HTTP. Utiliser le header pour y glisser un champ dédié à notre jeton sera plus pratique qu’une variable dans le corps de la requête – qui restera dédié à la donnée.

RequestBuilder est le pendant de XMLHttpRequest du monde JavaScript, c’est la classe qui permet de faire des requête GET ou POST « à la main ». Par rapport au XMLHttpRequest initial, RequestBuilder n’est qu’une façade qui reprend une syntaxe plus proche de ce que l’on trouvera dans le monde Java, mais uniquement côté client. De ce fait, elle permet l’utilisation de GWT avec des stacks autres que Java côté serveur.

RequestFactory est l’API proposée avec la version 2.1 de GWT en alternative à RPC. Son principal atout aujourd’hui : elle manipule des DTO outillés, de telle façon qu’une opération save(myDto) ne fera transiter dans la requête HTTP que les champs effectivement modifiés de l’objet.

Contrairement à RPC le framework ne gère seul le jeton ni pour RequestBuilder ni pour RequestFactory. L’opération préconisée sera d’utiliser un champ de header pour RequestBuilder, afin de ne pas polluer le corps de la requête. Dans le cas de RequestFactory, la séparation headers/corps de requête est en fait moins substantielle, du fait de la forme déjà spécifique du corps de requête. L’exemple donné passe cependant par un header.

Notre préconisation sera d’utiliser au maximum l’outillage existant pour RPC, il tient la route et cela semble une bonne stratégie en cas de positionnement futur du framework pour la sécurisation des RequestBuilder et RequestFactory (bien sûr, si vous utilisez RequestBuilder avec autre chose que Java côté serveur, cette remarque n’est pas à prendre en compte).

Pour RequestBuilder

Côté client

Comme en RPC, il conviendra tout d’abord de récupérer le token (pour cela, voir le code fourni pour le mécanisme RPC), puis d’injecter le header :

RequestBuilder requestBuilder = new RequestBuilder(RequestBuilder.POST, "");
requestBuilder.setHeader("X-XSRF-Cookie", xsrfToken.getToken());
requestBuilder.sendRequest(null, new RequestCallback() {
	@Override
	public void onResponseReceived(Request request, Response response) {
		// [...]
	}

	@Override
	public void onError(Request request, Throwable exception) {
		// [...]
	}
});

Dans le cas d’un serveur non-Java, deux solutions : générer le MD5 en utilisant un script JS trouvé sur le net (les principaux frameworks n’en proposent pas, mais voir par exemple ici), ou procéder au hashage côté serveur et le redescendre côté client (comme avec RPC, en asynchrone ou via l’objet Dictionary et la page HTML hôte).

Côté serveur

Voici un exemple avec une simple servlet Java. La validation est grandement reprise du code utilisé pour RPC, et exploite les même classes utilitaires fournies par GWT :

public class SecuredServlet extends HttpServlet {

	@Override
	protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
		validateXsrfToken(request);
		super.service(request, response);
	}

	protected void validateXsrfToken(HttpServletRequest request) throws RpcTokenException {
		// RpcTokenException est propre à GWT

		String xsrfToken = request.getHeader("XSRF-Token");
			// le header que nous avons injecté
		if (xsrfToken == null) {
			throw new RpcTokenException("XSRF token missing");
		}

		Cookie sessionCookie = Util.getCookie(request, "session-id", false);
			// com.google.gwt.user.server.Util est une classe utilitaire interne GWT
		if (sessionCookie == null || sessionCookie.getValue() == null || sessionCookie.getValue().length() == 0) {
			throw new RpcTokenException("Session cookie is missing or empty! " + "Unable to verify XSRF cookie");
		}
		String expectedToken = Utility.toHexString(Utility.getMd5Digest(sessionCookie.getValue().getBytes()));
			// de com.google.gwt.util.tools.Utility ...

		if (!expectedToken.equals(xsrfToken)) {
			throw new RpcTokenException("Invalid XSRF token");
		}
	}

	// [...]

}

Pour RequestFactory

Côté client

Etendre DefaultRequestTransport pour injecter le header :

public class SecuredRequestTransport extends DefaultRequestTransport {

	protected XsrfToken xsrfToken;

	public SecuredRequestTransport(XsrfToken xsrfToken) {
		this.xsrfToken = xsrfToken;
	}

	@Override
	protected void configureRequestBuilder(RequestBuilder builder) {
		super.configureRequestBuilder(builder);
		builder.setHeader("XSRF-Token", xsrfToken.getToken());
	}
}

A noter qu’on aurait pu aussi enrichir le corps de requête, comme dit plus haut.

Utiliser ensuite une instance de notre SecuredRequestTransport au lieu de DefaultRequestTransport avec nos RequestFactory :

EventBus eventBus = new SimpleEventBus();
SecuredRequestTransport securedRequestTransport = new SecuredRequestTransport(xsrfToken);
MyRequestFactory myRequestFactory = GWT.create(MyRequestFactory.class);
myRequestFactory.initialize(eventBus, securedRequestTransport);

Côté serveur

Côté serveur, il sera nécessaire de créer une classe héritant de RequestFactoryServlet. Le code est strictement le même que l’exemple donné pour RequestBuilder, le validateXsrfToken() peut être appelé dans un doPost() enrichi (au lieu de service()).

public class SecuredRequestFactoryServlet extends RequestFactoryServlet {

	@Override
	protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
		validateXsrfToken(request);
		super.doPost(request, response);
	}

	// ce code est strictement le même que pour la SecuredServlet plus haut
	protected void validateXsrfToken(HttpServletRequest request) throws RpcTokenException {
		// RpcTokenException est propre à GWT

		String xsrfToken = request.getHeader("XSRF-Token");
			// le header que nous avons injecté
		if (xsrfToken == null) {
			throw new RpcTokenException("XSRF token missing");
		}

		Cookie sessionCookie = Util.getCookie(request, "session-id", false);
			// com.google.gwt.user.server.Util est une classe utilitaire interne GWT
		if (sessionCookie == null || sessionCookie.getValue() == null || sessionCookie.getValue().length() == 0) {
			throw new RpcTokenException("Session cookie is missing or empty! " + "Unable to verify XSRF cookie");
		}
		String expectedToken = Utility.toHexString(Utility.getMd5Digest(sessionCookie.getValue().getBytes()));
			// de com.google.gwt.util.tools.Utility ...

		if (!expectedToken.equals(xsrfToken)) {
			throw new RpcTokenException("Invalid XSRF token");
		}
	}

	// [...]

}

Dans le web.xml, déclarer cette servlet au lieu de RequestFactoryServlet.

Conclusion

Les CSRF rentrent dans la catégorie des failles qui doivent être connues du développeur qui manipule un framework de présentation quel qu’il soit. Étonnamment, nombre de frameworks font preuve de peu de maturité dans l’intégration de solutions pour s’en prémunir.

GWT permet de mettre en place des solutions relativement facile à maintenir et à surveiller. Les failles sont peut-être plus complexes à appréhender, mais sont aussi plus faciles à isoler avec une application riche qu’avec une application web standard. De même, une application GWT existante à sécuriser devrait aisément se refactorer.

Certains frameworks, notamment Rails, résilient la session en cas de jeton attendu non détecté, ce qui peut constituer une sécurité supplémentaire. La RpcTokenException de GWT pourrait par ailleurs nous permettre de prévenir l’utilisateur d’une probable tentative d’attaque, via une alerte JavaScript Window.alert(), afin de sortir d’une éventuelle frame cachée.

En cas de besoin, dans une démarche de qualité, on pourra chercher à l’aide d’un outil comme Sonar des traces de non respects de la marche à suivre. Par exemple en vérifiant que nos interfaces de service RPC héritent de XsrfProtectedService et non plus de RemoteService. Ou encore en créant une classe SecuredRequestBuilder dont le constructeur exige le jeton, et vérifier que la RequestBuilder standard n’est plus utilisée.

Un prochain article abordera les failles XSS, les solutions proposées par le framework pour s’en prémunir, et traitera rapidement des autres points top 10 OWASP dans le contexte d’une application GWT.

Suggestion d'articles :

1. Initiation à la sécurité des Web Services
2. Sécurité des services web – 1ère partie
3. HTML5, offline et sécurité

La plus grand conférence de la communauté Java avec JavaOne a eu lieu à Anvers en Belgique au mois de Novembre. Cette année, les thèmes principaux de Devoxx étaient (sans ordre particulier):

• Le futur de Java
• Les langages alternatifs sur la JVM
• HTML5
• JavaFX
• Android
• Un peu de Cloud, de NoSQL et d’architecture haute performance

Nous avons aussi eu droit à une grande annonce pour une nouvelle conférence qui démarre en 2012 : Devoxx France!

Bien sûr, OCTO était sur place. Dans cet article, nous ne couvrirons pas toute la conférence en détail, de nombreux blogs l’ont déjà très bien fait. Nous allons néanmoins vous résumer les grandes tendances de cette édition et vous donner nos impressions à froid.

La suite de cet article en anglais, international oblige! Lire la suite…

Suggestion d'articles :

1. Paris Web 2010: les grandes tendances
2. One day @ Devoxx
3. Last day @Devoxx

Le framework CXF est aujourd’hui probablement le meilleur framework pour implémenter des web services selon la spécification JAX-WS en Java. Ayant réalisé un projet d’envergure autour de CXF, cet article n’a pas pour but d’être une initiation à ce framework car les tutoriaux de base de la documentation sont très bien faits ( http://cxf.apache.org/docs/index.html). Nous allons plutôt, dans une série d’articles, tenter de vous présenter quelques « tips avancés » sur CXF.

Une grande qualité de CXF est d’être un framework très modulaire de par sa conception autour d’un bus et d’une chaîne d’intercepteurs.

Lorsqu’on met en place un ensemble de WebServices, on peut être amené à effectuer un traitement commun à tous ces web services. Par exemple, rattraper les exceptions et maîtriser la soap:foault qui sera renvoyée au client. Ce type de traitement peut être réalisé de diverses façons, mais une bonne pratique est d’utiliser des intercepteurs.

La documentation officielle explique très bien les bases de la mise en place d’intercepteurs.
CXF découpe en phases le cycle de vie d’un message depuis son arrivée en passant par son traitement jusqu’à la réponse à celui-ci. C’est sur ces phases que l’on « branche » les intercepteurs afin qu’ils puissent traiter un message en fonction de son étape de cycle de vie.
On peut aussi spécifier explicitement que l’on branche un intercepteur avant ou après un autre intercepteur sur la même phase.

Le schéma ci-dessous donne un exemple d’architecture projet simplifié pour CXF avec une étape de sécurité, une étape de logging, une étape de validation des données et une étape de traitement des erreurs – cliquer pour zoommer :

Nous allons maintenant vous présenter deux intercepteurs en exemple.
L’ensemble du code présenté ci dessous est disponible sur github dans un projet maven. Ce code a été testé et déployé sous JBoss AS 7.

Mise en place d’un WebService simple

Pour nos exemples, nous avons besoin d’un WebService à appeler.

Celui-ci aura deux WebMethod :

• une simple qui répond « hello »
• une autre générant des exceptions, pour illustrer l’interception de celles-ci.

Le code de notre WebService d’exemple :

1
2
3
4
5
6
7
8
9
10
11
12
13
14

@WebService
public class HelloWorldService {
 
    @WebMethod
    public String sayHello() {
        return "Hello world";
    }
 
    @WebMethod
    public void makeBusinessException() throws BusinessException {
    	throw new BusinessException();
    }
 
}

Nous utiliserons dans ce cas la configuration en mode Spring 3, par annotation dans le code Java :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

@Configuration
public class ApplicationConfig {
 
	@Bean
	public HelloWorldService helloWorldService() {
		return new HelloWorldService();
	}
 
	@Bean
	public XmlInInterceptor xmlInInterceptor() {
		return new XmlInInterceptor();
	}
 
	@Bean
	public ExceptionInterceptor exceptionInterceptor() {
		return new ExceptionInterceptor();
	}
 
}

Récupération du message SOAP avant marshalling

Pour diverses raisons, il peut être intéressant de récupérer le messages XML (SOAP donc) que les WebServices vont être amenés à recevoir. Le problème est que lorsqu’on arrive dans la WebMethod d’un WebService, celui-ci est déjà démarshallé et n’est plus accessible facilement.
D’autre part, ce type de traitement uniquement technique n’a pas à apparaître dans la WebMethod qui ne devrait porter que le code répondant au métier du Web Service. Il faut donc récupérer ce message avant l’arrivée dans le WebService. Excellent cas d’usage des intercepteurs.
Cet exemple a été choisi car il ne figure pas dans la documentation. Il a été codé en fouillant le code source de CXF.

A noter qu’on ne fait que logger le message, cela pourrait être remplacé par la feature de logging de CXF activable dans la configuration Spring :

1
2
3
4
5

<cxf:bus >
	<cxf:features>
		<cxf:logging />
	</cxf:features>
</cxf:bus>

Néanmoins il peut être utile de logger de façon plus formelle, pour des raisons d’audit par exemple.

Interception du message reçu

Le code suivant est celui de l’intercepteur qui récupère le XML du message reçu par le WebService.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

@NoJSR250Annotations
public class XmlInInterceptor extends AbstractSoapInterceptor { 
 
	private Logger logger = LoggerFactory.getLogger(XmlInInterceptor.class);
 
	public XmlInInterceptor() {
		super(Phase.PRE_PROTOCOL);
		getAfter().add(SAAJInInterceptor.class.getName());
	}
 
	public void handleMessage(SoapMessage msg) throws Fault {
		Exchange exchange = msg.getExchange();
		Endpoint ep = exchange.get(Endpoint.class);
 
		ServiceInfo si = ep.getEndpointInfo().getService();
		String serviceName = si.getName().getLocalPart();
		logger.info("Service name : {}", serviceName);
 
		XMLStreamReader xr = msg.getContent(XMLStreamReader.class);
		if (xr != null) { // If we are not even able to parse the message in the SAAJInInterceptor (CXF internal interceptor) this can be null
			QName name = xr.getName();
			String operationName = name.getLocalPart();
			logger.info("Operation name : {}", operationName);
		}
 
		// Set the calling ip
		ServletRequest request = (ServletRequest) msg.get(ServletDestination.HTTP_REQUEST);
		if (request != null) { // and if the ServletDestination isn't even processed, the request could be null
			String remoteHost = request.getRemoteHost();
			logger.info("Calling IP : {}", remoteHost);
		}
 
		try {
			SOAPMessage msgSOAP = msg.getContent(SOAPMessage.class);
			if (msgSOAP != null) {
				ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();
				msgSOAP.writeTo(byteArrayOutputStream);
				String encoding = (String) msg.get(Message.ENCODING);
				String xmlRequest = new String(byteArrayOutputStream.toByteArray(), encoding);
				logger.info("Xml Request was : {}", xmlRequest);
			}
		} catch (IOException e) {
			// process io exception
		} catch (SOAPException e) {
			// process soap exception
		}
 
	}
}

Cet intercepteur est donc branché en Phase Pre-Protocol. Cela nous permet de récupérer le XML avant qu’il ne soit unmarshallé par les intercepteurs JAXB de CXF.

Comme vous pouvez le voir, on extrait d’autres informations utiles du SoapMessages, tel que le nom du service appelée, l’opération appelée et l’hôte appelant. Ce code est un peu opaque. De façon générale, la programmation d’intercepteur est mal documentée. Le conseil que l’on pourrait donner est de s’inspirer d’un intercepteur similaire et déjà existant. Il faut fouiller car il y en a beaucoup… eux aussi non documenté.

Dans le cas présent, le fonctionnement est le suivant. Un SoapMessage CXF est une grosse HashMap contenant toute sorte de choses. Il faut donc faire un getContent vers d’un SOAPMessage version java pour récupérer l’objet en question. Ensuite, on l’extrait via un ByteArrayOutputStream que l’on insère dans une String en prenant bien soin d’utiliser l’encoding du message.

L’annotation @NoJSR250Annotations est utilisée pour indiquer à CXF que cette classe ne contient pas d’annotation provenant de la JSR 250 et qu’il n’est donc pas nécessaire d’en charger. Cela accélère le démarrage de l’application.

Interception de la réponse émise

Voici maintenant l’intercepteur utilisé en sortie qui récupère dans ce cas le XML émis par CXF pour répondre à l’appel de WebService.
Celui-ci est branché en phase PRE_STREAM, juste avant l’envoi du message au client donc.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

@NoJSR250Annotations
public class XmlOutInterceptor extends AbstractSoapInterceptor {
 
	private Logger logger = LoggerFactory.getLogger(XmlOutInterceptor.class);
 
	public XmlOutInterceptor() {
		super(Phase.PRE_STREAM);
	}
 
	public void handleMessage(SoapMessage message) throws Fault {
 
		final OutputStream os = message.getContent(OutputStream.class);
		if (os == null) {
			return;
		}
		final CacheAndWriteOutputStream newOut = new CacheAndWriteOutputStream(os);
		message.setContent(OutputStream.class, newOut);
 
		newOut.registerCallback(new LoggingCallback(message, os));
	}
 
	private class LoggingCallback implements CachedOutputStreamCallback {
 
		private final Message message;
		private final OutputStream origStream;
 
		public LoggingCallback(final Message msg, final OutputStream os) {
			this.message = msg;
			this.origStream = os;
		}
 
		public void onFlush(CachedOutputStream cos) {
 
		}
 
		public void onClose(CachedOutputStream cos) {
			String encoding = (String) message.get(Message.ENCODING);
			String ct = (String) message.get(Message.CONTENT_TYPE);
			StringBuilder builder = new StringBuilder();
			try {
				writePayload(builder, cos, encoding, ct);
			} catch (IOException ex) {
				throw new RuntimeException("Cannot generate audit log for soap response", ex);
			}
 
			String msg = builder.toString();
			logger.info("OUT MESSAGE {}", msg);
			message.setContent(OutputStream.class, origStream);
 
		}
 
		protected void writePayload(StringBuilder builder, CachedOutputStream cos, String encoding, String contentType)
				throws IOException {
			if (StringUtils.isEmpty(encoding)) {
				cos.writeCacheTo(builder);
			} else {
				cos.writeCacheTo(builder, encoding);
			}
		}
	}
 
}

Ce code semble encore plus complexe que le précédent pour simplement aller chercher un fragment de XML dans le framework.
En fait nous l’avons en partie repris de la LoggingFeature de CXF ainsi que de quelques astuces glanées dans le code du framework.
L’idée globale est d’intercepter le stream de sortie à l’aide d’un callback (LoggingCallback). Le callback en question récupère l’encoding du flux, lis le flux, le transforme en chaine de caractères, puis le replace dans le flux afin que la réponse soit tout de même émise au client… c’est mieux.

Configuration Spring

Et pour finir voici la configuration Spring de notre WebService et de ses intercepteurs :

Configuration Spring :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

<import resource="classpath:META-INF/cxf/cxf.xml" />
<context:annotation-config />
 
<bean class="com.octo.cxf.config.ApplicationConfig"/>
 
<bean id="saajInInterceptor" class="org.apache.cxf.binding.soap.saaj.SAAJInInterceptor" />
 
<cxf:bus >
	<cxf:features>
		<!-- <cxf:logging /> -->
	</cxf:features>
	<cxf:inInterceptors>
		<ref bean="saajInInterceptor" />
	</cxf:inInterceptors>
</cxf:bus>
 
 
<jaxws:endpoint address="/helloworld" implementor="#helloWorldService" serviceName="helloWorldService">
	<jaxws:inInterceptors>
		<ref bean="xmlInInterceptor" />
	</jaxws:inInterceptors>
	<jaxws:outInterceptors>
		<ref bean="xmlOutInterceptor" />		
	</jaxws:outInterceptors>
	<jaxws:outFaultInterceptors>
		<ref bean="exceptionInterceptor" />
	</jaxws:outFaultInterceptors>
</jaxws:endpoint>

Bien entendu, si on a plusieurs WebServices, il devient tout de suite intéressant de remonter les intercepteurs au niveau du bus et non d’un web service :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<cxf:bus >
		<cxf:features>
			<!-- <cxf:logging /> -->
		</cxf:features>
		<cxf:inInterceptors>
			<ref bean="saajInInterceptor" />
			<ref bean="xmlInInterceptor" />
		</cxf:inInterceptors>
		<cxf:outInterceptors>
			<ref bean="xmlOutInterceptor" />	
		</cxf:outInterceptors>
		<cxf:outFaultInterceptors>
			<ref bean="exceptionInterceptor" />
		</cxf:outFaultInterceptors>
	</cxf:bus>

Vous qui êtes perspicaces remarquerez sûrement l’apparition de l’intercepteur SAAJ. C’est celui qui va ajouter le SOAPMessage dans le SoapMessage. Il est donc nécessaire de l’ajouter avant notre intercepteur en entrée. Par défaut, CXF l’exécute en mode lazy au sein d’un autre intercepteur plus loin dans la chaine.

Interception des exceptions et personnalisation des soap:fault

Nous allons maintenant voir comment rattraper les erreurs générées par les WebServices et leur code sous jacent pour en faire des soap:fault personnalisées.

Le code suivant récupère l’exception incluse dans le SoapMessage, teste son type et va générer une soap:fault en conséquence. Ici, pour simplifier le code, on ne fait qu’ajouter un code d’erreur 8 (définit arbitrairement), mais dans une application plus évoluée cela peut être utile d’y placer ses propres codes d’erreur.

L’intercepteur :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

@NoJSR250Annotations
public class ExceptionInterceptor extends AbstractSoapInterceptor {
 
	public ExceptionInterceptor() {
		super(Phase.PRE_LOGICAL);
	}
 
	public void handleMessage(SoapMessage message) throws Fault {
		Fault fault = (Fault) message.getContent(Exception.class);
		Throwable ex = fault.getCause();
		if (ex instanceof BusinessException) {
			BusinessException e = (BusinessException) ex;
			generateSoapFault(fault, e);
		} else {
			generateSoapFault(fault, null);
		}
	}
 
	private void generateSoapFault(Fault fault, Exception e) {
			fault.setFaultCode(createQName(8));
	}
 
	private static QName createQName(int errorCode) {
		return new QName("octo.com", String.valueOf(errorCode));
	}
}

Cet intercepteur doit logiquement être branché en sortie, car la soap:fault sera la réponse au message envoyé.

Configuration Spring :

1
2
3
4
5
6
7
8

<jaxws:endpoint address="/helloworld" implementor="#helloWorldService" serviceName="helloWorldService">
	<jaxws:inInterceptors>
		<ref bean="xmlInInterceptor" />
	</jaxws:inInterceptors>
	<jaxws:outFaultInterceptors>
		<ref bean="exceptionInterceptor" />
	</jaxws:outFaultInterceptors>
</jaxws:endpoint>

Ainsi si on appelle la WebMethod makeBusinessException, on obtient la réponse suivante :

1
2
3
4
5
6
7
8
9
10
11

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
      <soap:Fault>
         <faultcode xmlns:ns1="octo.com">ns1:8</faultcode>
         <faultstring>Fault occurred while processing.</faultstring>
         <detail>
            <ns1:BusinessException xmlns:ns1="http://services.cxf.octo.com/"/>
         </detail>
      </soap:Fault>
   </soap:Body>
</soap:Envelope>

Pour plus de détails je vous invite à vous référer au code sur github : https://github.com/mikrob/cxf-poc

J’espère que cette petite immersion dans le monde des intercepteurs CXF vous sera utile. Dans le prochain article, nous verrons des notions de sécurité avancées liées à CXF (nous sortirons un peu du use case authentification avec WS Security déjà souvent présenté).

La JSR 303 (Java Specification Request) a été lancée en 2006. Elle a pour objet d’éviter la duplication de la validation des données dans les diverses couches de l’application en la localisant dans la définition des Beans Java. Ceci, dans le but de gagner en productivité et d’éviter les bugs liés à la redondance de la validation. 5 ans après son lancement, nous sommes tentés d’en savoir plus sur le chemin parcouru par cette JSR et surtout de savoir si oui ou non elle a atteint ses objectifs !

Avant toute chose cependant, il est primordial de se poser quelques questions basiques qui nous permettront de comprendre cette JSR. En effet, quels sont les principes de cette JSR ? Quelles sont les différentes implémentations qui en ont été faites ? Sont-elles au même degré de maturité ? Cette JSR s’intègre-t-elle avec les frameworks existants ? Ou se situe-t-elle par rapport aux autres outils de validation ?

La JSR 303 par l’exemple

Dans cette partie, après une courte introduction décrivant succinctement la JSR, je présenterai deux exemples : le premier utilise les annotations définies dans la JSR et le deuxième montre comment créer nos propres annotations pour valider une classe Utilisateur. Mais avant toute chose, je vous propose une brève présentation de la JSR.

Présentation de la JSR

La JSR 303 définit un modèle de meta-données et une API pour valider les Beans Java. Cette validation s’effectue en utilisant les annotations mais il est possible d’utiliser des fichiers XML. Actuellement, cette JSR a passé toutes les étapes (stages) puisqu’elle en est à la dernière, i.e. celle de Final Release depuis le 16 novembre 2009. Elle était sous la direction d’Emmanuel Bernard, lead développeur chez JBoss, une division de Red Hat.

1^er exemple : utilisation des annotations

Tout d’abord voici la classe Utilisateur que je vais utiliser pour illustrer mes exemples :

public class Utilisateur {

    private String login;
    private String mdp;
    private Date dateDeNaissance;

    //Constructeurs, getters et setters
}

Pour notre classe Utilisateur, nous avons plusieurs contraintes :

• Le login ne doit pas être vide
• Le mot de passe doit contenir entre 8 et 16 caractères
• La date de naissance doit se situer dans le passé

Nous allons donc annoter les attributs de notre classe pour prendre en compte ces contraintes :

public class Utilisateur {

    @NotNull
    private String login;

    @Size(min = 8, max = 16)
    private String mdp;

    @Past
    private Date dateDeNaissance;

    //Constructeurs, getters et setters
}

Pour illuster cet exemple, on définit une classe Main dans laquelle on instancie un nouvel utilisateur ayant des attributs qui ne respectent pas les contraintes :

public class Main {

	public static void main(String[] args) throws ParseException {

		Utilisateur user = new Utilisateur();

		long dayInMillis = 24*60*60*1000;

		user.setLogin(null);
		user.setMdp("mdp");
		user.setDateDeNaissance(new Date(System.currentTimeMillis() + dayInMillis ));

		Validator validator = Validation
				.buildDefaultValidatorFactory().getValidator();

		Set<ConstraintViolation<Utilisateur>> violations = validator
				.validate(user);

		System.out.println("Nombre de violations : " + violations.size());

		for (ConstraintViolation
				constraintViolation : violations) {

			System.out.println("Valeur '"+
					constraintViolation.getInvalidValue() +
					"' incorrecte pour '"+
					constraintViolation.getPropertyPath() +
					"' : " +
					constraintViolation.getMessage());
		}
	}
}

En exécutant le code précédent nous obtenons les sorties suivantes dans la console :

Nombre de violations : 3
Valeur 'Thu Aug 18 12:13:56 CEST 2011' incorrecte pour 'dateDeNaissance' : doit être dans le passé
Valeur 'mdp' incorrecte pour 'mdp' : la taille doit être entre 8 et 16
Valeur 'null' incorrecte pour 'login' : ne peut pas être nul

On voit donc qu’on ne respecte pas les trois contraintes et qu’on a à chaque fois un message explicatif.

Notons qu’on aurait tout aussi bien pu définir les contraintes dans un fichier XML constraint-utilisateur.xml :

    com.octo.jsr303
    
        
            
        
        
            
                8
                16
            
        
        
        	
        
    

Il aurait ensuite été nécessaire de déclarer ce fichier dans un fichier validation.xml pour qu’il soit pris en compte. La documentation détaillée de l’utilisation de la validation XML est disponible ici.

2^ème exemple : Création d’une annotation

Il est parfois nécessaire de créer ses propres annotations lorsque celles définies par défaut ne répondent pas aux besoins. Imaginons par exemple qu’on veuille ajouter aux utilisateurs l’attribut article qui représente un lien vers l’article favori de l’utilisateur parmi les articles du blog Octo.

public class Utilisateur {

	@NotNull
	private String login;

	@Size(min = 8, max = 16)
	private String mdp;

	@Past
	private Date dateDeNaissance;

	@OctoBlog
	private String article;

	// Constructeurs, getters et setters
}

On commence donc par définir une nouvelle annotation @OctoBlog :

@Constraint(validatedBy = OctoBlogValidator.class)
@Target(value = ElementType.FIELD)
@Retention(RetentionPolicy.RUNTIME)
public @interface OctoBlog {

	String message() default "L'article n'appartient pas au blog octo";

	Class<?>[] groups() default {};

	Class<? extends Payload>[] payload() default { };
}

Pour cette interface il est obligatoire de de redéfinir messages(), groups() et payload. Il est aussi nécessaire de définir l’annotation @Retention au RUNTIME pour que la validation s’effectue. L’annotation @Target sert à dire quel type d’élément sera validé et @Constraint la classe qui validera cet élément.

Ci-dessous la classe de validation :

public class OctoBlogValidator implements
		ConstraintValidator<OctoBlog, String> {

	@Override
	public void initialize(OctoBlog constraintAnnotation) {

	}

	@Override
	public boolean isValid(String value,
			ConstraintValidatorContext context) {
		return value.startsWith("http://blog.octo.com/");
	}
}

Pour illustrer ce deuxième exemple, on exécute le main suivant :

public class Main {

	public static void main(String[] args) throws ParseException {

		Utilisateur user = new Utilisateur();
		Validator validator = Validation
				.buildDefaultValidatorFactory().getValidator();

		user.setLogin("ams");
		user.setMdp("motDePasse");
		user.setDateDeNaissance(new Date(System.currentTimeMillis()));
		user.setArticle("http://www.blog.com/mon-article");

		System.out.println("Première validation : ");
		validateUser(user, validator);

		user.setArticle("http://blog.octo.com/jsr-303-bean-validation-etat-des-lieux");

		System.out.println("Deuxième validation : ");
		validateUser(user, validator);

	}

	private static void validateUser(Utilisateur utilisateur,
			Validator validator) {
		Set<ConstraintViolation<Utilisateur>> violations;
		violations = validator.validate(utilisateur);

		System.out.println("Nombre de violations : " + violations.size());

		for (ConstraintViolation constraintViolation : violations) {

			System.out.println("Valeur '"
					+ constraintViolation.getInvalidValue()
					+ "' incorrecte pour '"
					+ constraintViolation.getPropertyPath() + "' : "
					+ constraintViolation.getMessage());
		}
	}
}

Ce qui nous donne la sortie suivante dans la console :

Première validation :
Nombre de violations : 1
Valeur 'http://www.blog.com/mon-article' incorrecte pour 'article' : L'article n'appartient pas au blog octo
Deuxième validation :
Nombre de violations : 0

Notons qu’il nous était possible d’utiliser l’annotation @Pattern de la manière suivante :

	@Pattern(regexp = "http://blog\\.octo\\.com/.*",
			message = "L'article n'appartient pas au blog octo")
	private String article;

Une troisième façon de faire aurait été d’ajouter @Pattern en annotation de @OctoBlog :

@Constraint(validatedBy = OctoBlogValidator.class)
@Target(value = ElementType.FIELD)
@Retention(RetentionPolicy.RUNTIME)
@Pattern(regexp = "http://blog\\.octo\\.com/.*")
@ReportAsSingleViolation
public @interface OctoBlog {

	String message() default "L'article n'appartient pas au blog octo";

	Class<?>[] groups() default {};

	Class<? extends Payload>[] payload() default {};
}

L’annotation @ReportAsSingleViolation indique qu’il faut ignorer les messages d’erreur des annotations et qu’il faut utiliser le message défini dans @OctoBlog.
 

Implémentation de référence : Hibernate Validator

Pour exécuter les exemples précédents j’ai utilisé la version 4.2.0.Final (disponible depuis juin 2011) d’Hibernate Validator, implémentation de référence de la JSR-303. En plus d’implémenter les annotations définies par la JSR, Hibernate Validator en ajoute des nouvelles comme @Email, @NotEmpty et @CreditCardNumber.

Autre implémentation : Apache Bean Validation

Anciennement appelé agimatec-validation, ce projet est depuis mars 2010 en incubation chez apache : https://cwiki.apache.org/BeanValidation/ et la dernière version publiée est la 0.3-incubating.

Pour tester cette implémentation, j’ai modifié les imports dans les exemples de la partie précédente. Le comportement obtenu était semblable à l’exception des messages d’erreur qui étaient en anglais. Bon point donc pour Hibernate qui a internationalisé les messages.

D’une manière générale, si vous voulez utiliser la JSR-303 pour valider les Beans dans vos projets, la préconisation est d’utiliser Hibernate Validator. En effet, cette implémentation est stable et les nouvelles releases sont assez régulières. Pour ceux qui veulent utiliser Apache Bean Validation, il est conseillé d’attendre que ce projet passe l’étape d’incubation.

Certains projets sont plutôt hésitants quant à l’utilisation de la validation au niveau des Beans Java craignant une baisse des performances générales. Pour avoir une idée du temps que prend la validation des objets, je vous conseille de regarder le benchmark publié ici qui compare les temps nécessaires pour valider les Beans en utilisant les deux implémentations. Ce qui ressort de cette étude est que Apache Bean Validation 0.1-incubating est plus performant que Hibernate Validator 4.1.0.CR1. Cependant ce benchmark a été réalisé en 2010 et depuis la version 4.2.0.Final de Hiberante Validator est sortie, il serait donc intéressant de refaire les tests car cette dernière version est sensée améliorer les performances en diminuant les temps de validation.

GWT et la JSR-303

Le framework gwt-validation implémente  la JSR 303 et propose de valider les Beans aussi bien côté client que côté serveur. D’après le wiki du projet l’implémentation de la JSR est finie à 80%. Mais il ne sera bientôt plus obligatoire de passer par ce framework pour utiliser la JSR-303. En effet, depuis peu, Google a commencé à intégrer cette JSR dans GWT : http://code.google.com/p/google-web-toolkit/wiki/BeanValidation. Cette intégration se base sur l’implémentation de référence Hibernate Validator et propose aussi une validation côtés serveur et client. Cette intégration n’est pas disponible dans GWT 2.3 mais l’est dans le trunk. Pour ceux qui veulent tester, un exemple d’utilisation est disponible ici. Il faut cependant faire attention car, comme annoncé sur la page du wiki du projet, la validation n’est pas encore mature et l’API peut encore beaucoup évoluer.

Conclusion : JSR-303 Vs le reste du monde

Le besoin de valider les Beans Java est bien plus antérieur à la parution de JSR-303. En effet, d’autres frameworks se proposaient déjà de valider les objets comme Apache Commons Validator dont la première release date de 2002. D’autres  frameworks Java embarquent leur propre mécanisme de validation comme Spring avec son Validator. Pour utiliser ce dernier afin de valider notre classe Utilisateur, il aurait fallu créer une deuxième classe UtilisateurValidator qui implémente l’interface Validator de Spring.

Ces frameworks ayant été pensés à l’ère pré-JDK5, la JSR-303 simplifie la validation des Beans grâce à l’utilisation des annotations et rend le code plus lisible quant aux contraintes qu’il doit respecter. Elle apporte aussi un standard à cette partie très importante des projets informatiques que représente la validation des données.

Suggestion d'articles :

1. Tests unitaires et tests d’interface sur iPhone : État des lieux

NullPointerException : l’erreur la plus courante dans un programme Java. On est tous à un moment ou à un autre tombé sur cette exception. Malheureusement, ce n’est qu’en production à 4h du matin qu’elle arrive. On corrige donc le bug suivant :

MonObjet monObjet = null;
…
monObjet.maMethode(); // => NullPointerException

Par un rapide :

if(monObjet != null) {
  monObjet.maMethode();
}

Ce correctif est tout à fait honorable, mais pourquoi ne pas essayer de ne plus avoir aucune exception de ce type ?

Il existe plusieurs méthodes validées par le compilateur pour l’éviter, et donc avant la mise en production. Aucune n’est nouvelle, certaines controversés, mais elles sont toutes étudiées dans la suite de cet article.

Tu n’utiliseras pas null

La première règle est simple : ne jamais utiliser le mot clé null.

Globalement, il est utilisé dans deux cas :

• initialisation d’objets
• valeur vide

Par exemple, au lieu d’écrire :

String maVariable = null;

if(test == 0) {
  maVariable = "toto";
} else if(test > 0) {
  maVariable = "titi";
} else {
  maVariable = "tata";
}

maVariable.subString(….)

On peut tout simplement ne pas initialiser la variable maVariable. De cette façon, si on oublie un cas dans notre if, le compilateur va nous générer une erreur du type :

variable maVariable might not have been initialized

Pour les valeurs vides, le problème est plus complexe. Nous verrons donc par la suite comme remplacer un null qui fait office de valeur vide.

Tu utiliseras @NotNull, @Nullable

La JSR 308 nous apporte deux annotations @NotNull et @Nullable qui permettent une vérification statique par le compilateur des valeurs des paramètres et de retour des méthodes. Par exemple :

int maMethode(@NotNull String maChaine) {
  return maChaine.length();
}

maMethode(null);

Dans ce cas on aurait eu une NullPointerException au lancement, alors qu’avec cette annotation on aura un warning directement à la compilation.

Bien évidement, mon exemple est simpliste mais cela fonctionne aussi sur des cas plus complexes.

Cette JSR peut être intégrée à plusieurs outils (Maven, Eclipse, etc.), pour plus de détails c’est ici. Il faut noter qu’IntelliJ l’intègre nativement.

Tu utiliseras des objets vides

Une autre façon d’éviter le null est d’utiliser le Null Object Pattern. Le principe est très simple : créer des objets spécifiques qui représente le vide. Par exemple :

class Personne {
  public String getNom() { … }
  public void setNom(String nom) { … }
  public List<Personne> getEnfants() { … }
}

public final PersonneVide extends Personne {
  public String getNom() {
    return "";
  }
  public void setNom(String nom) {}
  public List<Personne> getEnfants() {
    return Collections.emptyList();
  }
}

Il suffit d’employer PersonneVide plutôt que d’utiliser null. Il y a plusieurs implémentations de cette solution. On peut aussi créer une interface Personne et l’implémenter en deux classe : PersonnePhysique (la vraie implémentation) et PersonneVide.

On peut aussi facilement étendre ce principe pour avoir d’autres objets plus spécifiques, comme le montre Martin Fowler.

Cette méthode a des nombreuses limitations. Il faut se contraindre à créer et surtout à utiliser ses objets vides. Ce qui rajoute du code et donc peut rajouter des bugs. À ma connaissance il n’existe pas de méthode automatique qui nous force à utiliser cette méthode.

Tu lanceras des exceptions

Une autre solution est d’utiliser des exceptions. Plutôt que de renvoyer une valeur null, on lance une exception. Cela à l’avantage d’avoir une validation statique faite par le compilateur. Pour plus de détail sur les bonnes pratiques sur la gestion des exceptions, c’est ici. Par exemple :

class ImpossibleDeGenererIDException extends Exception { … }

public class Personne {
  public Email genereID() throws ImpossibleDeGenererIDException {
    //On lance l'exception si on n'a pas pu générer d'ID
    //plutôt que de renvoyer null
  }
}

Il faut noter que lancer une exception est très coûteux en terme de calcul. Et comme le dis très bien l’article citer ci-dessus, utiliser une exception pour un contrôle de flux est un anti-pattern. À mon avis, cette solution n’est pas à utiliser.

Tu utiliseras le pattern Option/Maybe

Ce pattern nous vient des langages fonctionnels. Il consiste en un objet particulier Option qui encapsule un résultat. Cet objet peut avoir 2 valeurs possibles : une valeur non nulle (Some) ou None. Prenons un exemple de l’API de Java. La méthode get de MyMap renvoie null si l’objet demandé n’est pas présent dans celle-ci. Avec ce pattern, la méthode renverrait une instance d’Option. C’est donc l’utilisateur de la méthode est forcé par le compilateur de gérer le cas None. Une implémentation naïve serait donc :

interface Option<T> {
  public Boolean isNone();
}

class Some<T> implements Option<T> {
  public T get() { … }
  public Boolean isNone() { return false; }
}

class None<T> implements Option<T> {
  public Boolean isNone() { return true; }
}

class MyMap<K, V> {
  public Option<V> get(K key) { … }
}

MyMap<Integer, String> map = new MyMap<Integer, String>();
map.put(1, "un");

Option<String> result = map.get(2);
if(result.isNone()) {
  // Gestion du cas None
} else {
  String val = ((Some) result).get();
}

Cette méthode a le gros avantage d’avoir une validation statique par le compilateur. En effet, il est impossible d’utiliser directement la valeur de retour de la méthode get. Elle est du type Option<String> et donc complètement différent que celui attendu « classiquement » : String. On est donc forcé de faire le test du None. De plus, cela nous donne tout de suite l’information que la méthode peut renvoyer une valeur vide.

Cette implémentation est clairement bancale, la bibliothèque Functional Java en fournit une plus complète.

C’est à mon avis la méthode la plus sûre. Mais elle a été pensée pour les langages gérant le pattern matching comme Scala ou Haskell, où elle est intégrée nativement dans l’API.

Elle est donc un peu lourde à utiliser en Java. Et surtout, elle n’est pas intégrée à l’API. Il faut donc soit utiliser une autre API, ou faire des wrapper autour de l’API standard.

Conclusion

Ces méthodes sont adaptables à tous les langages orientés objets. Certains offrent d’autres méthodes. Par exemple en Groovy il y a l’Elvis Operator, en Ruby (avec Rails) le try.

Le problème reste lors de l’utilisation de bibliothèques externes. Même si un projet utilise ces solutions, il faudra toujours faire attention lors de l’utilisation de l’API Java ou autre (Hibernate pour ne citer que lui).

Il n’y a donc pas de méthode magique pour ne plus avoir de NullPointerException dans votre code Java (à part changer de langage ;)).

Suggestion d'articles :

1. Parallélisation, distribution partie 3 : comment tirer parti des processeurs multi-coeurs à travers l’API de concurrence de Java 7 ?
2. Les nouveautés du langage dans Java 7
3. Un DSL SQL pour Java

Suggestion d'articles :

1. Platform as a Service avec Ruby on Rails
2. Intégration continue performante (Part #2)
3. 5 minutes pour : Comment faire de l’intégration continue en PHP ?

Le sujet du packaging des applications Java EE a suscité récemment des échanges riches sur notre mailing-list interne. C’est pourquoi nous avons trouvé intéressant d’en publier une synthèse. Nous remercions Dominique Jocal pour avoir réalisé cette synthèse, ainsi que les participants à ce débat : Benoît Lafontaine, Mikael Robert, Bertrand Paquet, Marc Bojoly – et nous vous souhaitons une bonne lecture !

Un projet de montée en version ou de changement de serveur d’application Java et de JVM est l’occasion pour une direction technique de se pencher à nouveau sur la stratégie d’empaquetage des applications : doivent-elles embarquer leur socle technique, ou s’appuyer sur celui présent dans le serveur d’application ?

La quasi-totalité des frameworks techniques utilisés par les applications sont présents dans les serveurs récents. 2 stratégies sont alors possibles pour empaqueter les “webapps” (application web Java) :

• “full webapp” : l’application embarque ses versions de frameworks techniques comme SLF4J et LOG4J, Hibernate, CXF, iText…. Elle n’utilise du serveur d’application – par ex. JBoss – que quelques services de connexions HTTP, SQL, MOM, annuaire d’objet…
• “full server” : la webapp n’embarque que les frameworks absents du serveur, par exemple iText. Elle utilise tous les autres frameworks techniques déjà présents dans le serveur dans leurs versions présentes.

Mettons-nous dans un cas de portefeuille applicatif, au demeurant très courant: un SI Java de plusieurs dizaines d’applications construites sur une décennie, bâties sur 2 ou 3 générations de socles techniques – les frameworks techniques d’injection, de logging, de persistance, d’IHM, de génération PDF, etc – exécutées sur une seule machine virtuelle Java et une seule version de serveur d’application sous licence/support éditeur, sauf rares exceptions.
Dans ce contexte également, citons les besoins et contraintes exprimés par les équipes techniques:

• Rester en phase avec l’évolution des serveurs d’applications qui embarquent toujours plus de services techniques.
• Diminuer globalement l’effort d’intégration et de dépannage sur les frameworks techniques.
• Continuer à bénéficier au maximum des outils d’administration et de supervision des ressources techniques, sans avoir à compenser en écrivant soi-même ces outils.

On peut être alors tenté pour ce cas d’adopter la stratégie “full server”:

• on pourra toujours suivre l’évolution du serveur, pas de conflit avec les frameworks techniques embarqués en webapp;
• la diminution voire la disparition de la diversité de frameworks rationalise de facto l’effort d’intégration et de dépannage;
• la possibilité d’utiliser les outils fournis avec le serveur est par définition garantie.

En revanche une contrainte apparaît: monter en version sur un framework technique pour résoudre un problème ou gagner une fonctionnalité sur la moindre application implique de mettre à niveau le serveur, la webapp n’est pas seule impactée.

Or les retours d’expérience montrent que cette contrainte a non seulement de grandes chances d’arriver, mais peut s’avérer bloquante. Benoit, architecte Octo explique que “migrer ensemble toutes les applications sur une version donnée est une mission quasi-imposssible”. “L’application X subit le bug spécial de la version x.y.z qui n’est pas compatible avec telle version de telle librairie, et à côté l’application Y qui ne doit plus évoluer ne sera jamais compatible avec cette fameuse version de librairie”. Fondamentalement, explique Marc, “les cycles de vie des applis sont trop différents entre eux et encore différents de celui d’une production”.

Enfin, il est possible de “rester en phase avec les évolutions des serveurs” en stratégie “full webapp” grâce à la notion de profil. “Un profil très léger, avec uniquement un conteneur web et quelques services d’administration” permet en même temps de disposer d’outillage prêt à l’emploi pour l’Exploitation en laissant les webapps embarquer des socles techniques plus importants. Un profil léger peut être obtenu par exemple en utilisant un JBoss allégé, ou en se contentant d’un simple conteneur de servlet comme Tomcat.

En conclusion, pour ce cas de SI, on préconise plutôt la stratégie “full webapp” sur serveur à profil léger. La webapp ne délègue alors au serveur un service technique que lorsque :

• il vient avec un outillage prêt à l’emploi, différenciateur et accélérateur pour la Production comme une configuration centralisée, une reconfiguration à chaud…

• l’API est mature et stable.

L’accès aux SGBDR, aux messageries applicatives, ou encore aux logs, sont des exemples de tels services, si votre serveur d’applications dispose des outils précités.
Le cas ou la strategie full-serveur pourrait être préconisée serait alors sur un ensemble d’applications ayant le même cycle de vie et maintenues par la même équipe.

Suggestion d'articles :

1. Les nouveautés du langage dans Java 7
2. Les nouvelles librairies dans Java 7
3. Thrift et Protocol Buffers : compacité du message sérialisé dans le monde Java

A l’heure où les nouvelles technologies de stockage de données regroupées sous les termes NoSQL et Distributed Data Grid deviennent populaires, il est intéressant de suivre l’évolution de cet écosystème et notamment des librairies d’intégration avec ces outils.
Des librairies apportant un certain niveau d’abstraction émergent, avec l’espoir de voir apparaître des solutions de haut niveau comparables aux ORM que nous utilisons pour les bases relationnelles. Nous allons nous intéresser aujourd’hui au projet Spring Data, qui propose une certaine unification pour les accès aux bases de données dites NoSQL.

Spring Data

Spring Data est un projet en développement et lancé en 2010, visant à simplifier l’utilisation des bases NoSQL, des frameworks Map-Reduce, ou d’apporter des extensions pour le support des bases relationnelles. Le projet intègre aussi progressivement le framework Hades qui apporte la notion de repository pour une approche Domain Driven Developpment.

Spring Data regroupe déjà plusieurs sous-projets dédiés à des implémentations particulières :

• JPA, qui apporte de nouvelles fonctionnalités pour une approche DDD avec des bases relationnelles,
• Graph, avec une implémentation pour Neo4j,
• Document, avec une implémentation pour MongoDB,
• Key – Value, des implémentations pour Redis et Riak,
• Extensions JDBC.

Dans l’ensemble, les projets existants consistent à apporter une couche d’abstraction facilitant la manipulation de données avec les différents systèmes de stockage. L’apport principal de ce projet est bien sûr de faciliter l’intégration de ces technologies à un applicatif Spring, et de profiter des facilités de configuration du framework : injection de beans, configuration xml et programmation orientée aspect.

Nous allons voir ce que peuvent apporter ces librairies par rapport à une utilisation directe des connecteurs existants. L’équipe prévoit également le support d’autres produits tels qu’Amazon S3, Cassandra ou Hadoop.

En parallèle, le projet Spring Data Mapping, actuellement hébergé côté Groovy, aurait pour objectif d’apporter une solution générique de mapping Objet-Base pour plusieurs bases NoSQL.

Spring Data JPA et Domain-Driven-Developpment

Une des vocations du projet Spring Data est d’apporter le support pour une approche Domain Driven Developpment (DDD) et l’utilisation du pattern Repository. Spring Data JPA en est la première implémentation, dédiée aux bases relationnelles. Le projet est directement repris depuis le framework Hades, dont les fonctionnalités sont progressivement intégrées au socle commun de Spring Data, et doit permettre à terme une approche DDD pour les différents types de stockage supportés.

Génération de Repository

Le développement d’un Repository est facilité en générant automatiquement les fonctions de CRUD les plus communes d’un service d’accès aux données :

• save
• findById
• findAll (avec gestion de résultats paginés)
• count
• delete
• exists

L’utilisation de l’API est plutôt simple, il suffit de définir son repository via une interface étendant l’interface JpaRepository de base, et le framework se chargera du reste.

public interface PersonRepository extends JpaRepository<Person, Long> { … }

De plus, l’API permet, comme cela se fait en Groovy et Rails, de générer les méthodes de requêtes à partir du nom de la méthode ou en utilisant une requête nommée (@NamedQuery). Par exemple, si on souhaite ajouter une méthode de recherche par nom à notre PersonRepository :

public interface PersonRepository extends JpaRepository<Person, Long> {
 List<Person> findByLastname(String lastname);
}

Le bean injecté par Spring comportera alors une méthode générée avec l’exécution de la requête correspondante : « SELECT * FROM User WHERE lastname = ? ».

La librairie permet principalement de réduire le volume de code à écrire lorsque l’on code un Repository, mais Spring Data JPA apporte d’autres fonctionnalités intéressantes:

• L’approche DDD est facilitée grâce aux supports des Specifications, qui utilisent des closures pour définir des prédicats, tout en utilisant l’API Criteria de JPA2.

public static Specification isPersonMinor() {
	return new Specification() {
		Predicate toPredicate(Root root, CriteriaQuery query,
			CriteriaBuilder builder) {
			LocalDate date = new LocalDate().minusYears(18);
			return builder.lessThan(root.get(Person_.birthDate), date);
		}
	};
}

• Ajout de fonctions pour la gestion des transactions au niveau Repository
• Entités auditables (suivi des dates et utilisateurs de création et modification). Il s’agit d’un sujet classique en entreprise lorsque le suivi des modifications de données est stratégique. Il sera intéressant de comparer cette fonctionnalité à son équivalent Hibernate Envers.
• Support de la librairie Querydsl.

Spring Data Graph

Ce projet est dédié aux bases proposant une implémentation de type graphe et fournit une implémentation pour Neo4j.
Neo4j est une base de données graphe, qui répond également aux enjeux traditionnels d’une base de données (ACIDité des transactions, gestion des accès concurrents,rollback de transaction, haute disponibilité). Pour avoir un rapide tour d’horizon de ce qu’apporte une base de données graphe et plus particulièrement Neo4j, voir ici.

Spring Data Graph propose une véritable couche d’abstraction permettant un mapping entre un modèle objet utilisé dans l’application Java et les entités stockées physiquement dans la base graphe. Spring Data Graph définit donc les notions suivantes pour la modélisation au niveau des objets (les exemples proviennent de la documentation officielle, qui propose par ailleurs un exemple complet d’une application web utilisant les différents composants de Spring) :

• Annotations pour définir noeuds (@NodeEntity) et relations (@RelationshipEntity)
• Gestion des index (@Indexed)

@NodeEntity
class Movie {
 @Indexed
 int id;

 String title;
 int year;    

 @RelatedTo(elementClass = Actor.class, type = "ACTS_IN", direction = Direction.INCOMING)
 Set<Actor> cast;

 @RelatedToVia(elementClass = Role.class, type = "ACTS_IN", direction = Direction.INCOMING)
 Iterable<Role> roles;
}

@NodeEntity
class Actor {    

 @Indexed
 int id;
 String name;

 @RelatedTo(elementClass = Movie.class, type = "ACTS_IN")
 Set<Movie> cast; 

 public Role playedIn(Movie movie, String roleName) {
 Role role = relateTo(movie, Role.class, "ACTS_IN");
 role.setRole(roleName);       
 return role;
 }
}

@RelationshipEntity
class Role {
 @EndNode
 Movie movie;

 @StartNode
 Actor actor;

 String role;
}

• Utilisation du pattern Repository, avec des implémentations pour gérer des opérations de CRUD, index et recherches; ainsi que les algorithmes de parcours de graphes.

GraphRepository<Person> graphRepository = graphRepositoryFactory.createGraphRepository(Person.class);

Spring Graph apporte également une couche d’abstraction sur des aspects plus techniques, entre autres:

• Gérer des recherches:
  • en utilisant des algorithmes spécifiques de parcours de graphe (Traversal)
  • en utilisant le système de recherche indexée avec un moteur d’indexation séparé (Apache Lucene est inclus par défaut).

Pour cela, il suffit d’annoter le champ à indexer: @Indexed(fulltext = true, indexName = « search »), puis d’appeler la méthode findAllByQuery(indexedField, query))

• Gérer les transactions avec la configuration Spring standard et SpringTransactionManager
• Gestion de la persistance des entités avec la méthode persist()
• Validation de beans (JSR 303) via les annotations de définition de contraintes (@Min, @Max, @Size, @Email, …)

Définition d’entités cross-store

Un autre aspect très intéressant dans cette API est le support multi-base en définissant des entités partielles, qui permet d’utiliser plusieurs systèmes de stockage pour une même entité. Actuellement, il est possible de définir une entité dont une partie des champs sera géré via JPA dans une base relationnelle classique, tandis que l’autre partie est gérée dans une base de données graphe.

L’exemple suivant est une modélisation simpliste d’un système de vente dans lequel les articles et les ventes sont stockés dans une base relationnelle classique, hormis les liens entre les objets vendus (« Les acheteurs qui ont acheté ce produit ont également acheté…), ainsi que le total des ventes pour chaque article.

@Entity
@Table(name = "product")
@NodeEntity(partial = true)
class Product {
	@Id
	@GeneratedValue(strategy = GenerationType.AUTO)
	@Column(name = "id")
	private Long id;

	private String name;
	private String description
	private Double price;

	@GraphProperty
	Double totalSales;

	@RelatedTo(elementClass = Product.class, type = "SAME_SALE", direction = Direction.INCOMING)
	private Set<Product> linkedSales;

	@RelatedToVia(elementClass = SaleConnection.class, type = "SAME_SALE", direction = Direction.INCOMING)
	private Iterable<SaleConnection> salesConnections;

	@OneToMany
	private Set<SoldItem> sales;

	@Transactional
	public SaleConnection soldTogether(Product item) {
		SaleConnection connection = relateTo(item, SaleConnection.class, "SAME_SALE");
		connection.incrementLinkWidth();
		return connection;
	}
}

@RelationshipEntity
class SaleConnection {
	@EndNode
	Product item1;

	@StartNode
	Product item2;

	int linkWidth = 0;

	public void incrementLinkWidth(){
		linkWidth++;
	}
}

@Entity
@Table(name = "sales")
class SoldItem {
	@ManyToOne
	Product productReference;

	Double soldPrice;
}

Spring Data Document

Ce projet est dédié aux bases proposant une implémentation de type document, et fournit pour l’instant une implémentation pour MongoDB.

L’implémentation apporte une surcouche au client Java fourni par Mongo et en reproduit l’essentiel des fonctionnalités en s’intégrant au framework Spring, entre autres :

• Configuration Spring via XML ou classes @Configuration pour les instances Mongo et la gestion des replica set
• MongoTemplate qui offre des mécanismes d’abstraction pour interagir avec MongoDB et pour gérer la persistance des objets Java avec MongoDB de manière transparente, la gestion des collections, exécuter des commandes shell internes.
• Fonctions de recherche avec notamment :
  • possibilité d’utiliser des Criteria
  • support des requêtes géographiques
  • gestion d’index

Par ailleurs, la librairie apporte le support du pattern Repository de manière similaire à Spring Data JPA  avec MongoRepository:

• Génération des fonctions de CRUD
• Gestion de requêtes prédéfinies au format JSON, par exemple:

public interface PersonRepository extends MongoRepository<Person, String>
  @Query("{ 'firstname' : ?0 }")
  List<Person> findByThePersonsFirstname(String firstname);
}

• Support de Querydsl

Enfin, la dernière version fraichement sortie de l’API propose d’une part un système de mapping à base d’annotations, avec notamment la possibilité de gérer les collections au sein d’un document par référence ou non:

@Document
public class Account {
  @Id
  private ObjectId id;
  private Float total;
}

@Document
public class Person {
  @Id
  private ObjectId id;
  @Indexed
  private Integer ssn;
  @DBRef
  private List<Account> accounts;
}

D’autre part, cette dernière release apporte comme l’API Graph un support cross-store persistence, permettant d’utiliser conjointement plusieurs systèmes de stockage de données.

Cette librairie semble plutôt aboutie et vient sans doute concurrencer sérieusement les librairies existantes comme Morphia, qui propose également des fonctions de mapping notamment.

Spring Data Key-Value

Le projet Key-Value (SDKV) est dédié aux bases proposant une implémentation clé-valeurs, et fournit des implémentations pour Redis et Riak.

Il s’agit pour l’instant essentiellement d’une couche d’abstraction au dessus des librairies de bas niveau existantes, qui permet principalement de tirer avantage d’une configuration Spring. Ces deux librairies semblent encore à un niveau de  maturité assez faible et n’apportent pour l’instant pas beaucoup par rapport à une utilisation directe des connecteurs.

Redis

L’implémentation SDKV pour Redis est une surcouche aux connecteurs Jedis, JRedis et RJC, qui apporte notamment:

• Configuration simple via XML, par exemple :

<bean id="jedisConnectionFactory" class="org.springframework.data.keyvalue.redis.connection.jedis.JedisConnectionFactory">
	<property name="hostName" value="localhost"/>
	<property name="port" value="6379"/>
	<property name="timeout" value="5000"/>
	<property name="pooling" value="true"/>
</bean>

<bean id="redisTemplate" class="org.springframework.data.keyvalue.redis.core.RedisTemplate"
	p:connection-factory-ref="jedisConnectionFactory"/>

• Utilisation d’objets plutôt que de dialoguer directement avec Redis grâce à la classe RedisTemplate
  • classes correspondant aux opérations de Redis (Value, List, Set, ZSet, Hash et Bound*)
  • fonctions de messaging (Send/Publish/Subscribe)
• Possibilité d’utiliser différents mécanismes de sérialisation pour stocker des objets

Plusieurs articles on déjà été publiés sur le sujet:

• SpringData – Redis tutorial
• Movie Recommendation App using Spring Data and Redis
• Creating an Application using Spring Data with Redis as Datastore — Part 1
• Exemples sur le github de SpringSource

Riak

Là aussi, SDKV propose une surcouche au client Java développé par Basho (la société derrière Riak). Une base de données Riak est nativement accédée via une API REST/HTTP, utilisant les drivers Apache Commons.

La librairie apporte notamment :

• Configuration simple par XML, par exemple:

<bean id="riakTemplate"
      p:defaultUri="http://localhost:8098/riak/{bucket}/{key}"
      p:mapReduceUri="http://localhost:8098/mapred"/>

• Utilisation d’objets plutôt que de dialoguer directement avec Riak grâce à la classe RiakTemplate
  • pour les fonctions d’accès et de stockage
  • l’utilisation de l’algorithme Map/Reduce
  • les fonction de liaison entre les entrées et de parcours des listes liées
• Gestion asynchrone des échanges avec la base de données avec des callbacks
• Utilisation de services personnalisés de conversion d’objets vers Riak ou de ClassLoader depuis Riak

Spring Data JDBC Extensions

Cette partie de Spring Data se situe un peu en marge du reste car il s’agit ici de fournir des extensions de configuration spécifiques à certaines implémentations de bases de données relationnelles.

La première version du projet comporte des extensions pour les bases de données Oracle, qui constituent un portage du code d’un module auparavant payant de Spring, le Advanced Pack for Oracle Database. Cette extension doit notamment permettre un support transparent pour les applications de fonctionnalités telles que le Fast Connection Failover d’Oracle RAC, Advanced Queuing, et des types de données complexes (XML, STRUCT, ARRAY).

Vers une abstraction de plus haut niveau?

Spring Data Mapping

Ce dernier projet plutôt ambitieux vise à fournir un framework mutualisé de mapping objet pour les différents implémentations de stockage de données. C’est finalement une surcouche aux projets précédents qui cherche, j’imagine, à décorréler la modélisation du stockage physique. A l’heure actuelle, le projet est simplement mentionné dans la page du projet Spring Data, il n’y a pas de version SNAPSHOT disponible. Le projet est pour l’instant en Groovy, mais devrait être migré en Java pour s’intégrer à Spring Data.

D’après ce qu’on peut voir des sources existantes, il serait bien possible de définir un mapping d’objets de manière relativement  indépendante de la base de données : on trouve un projet core, et des implémentations pour de nombreuses technologies: Gemfire, Hibernate, AppEngine, Redis, Mongo, Cassandra et d’autres…

Hibernate OGM

Hibernate OGM est un projet démarré en juillet 2010 et mené par Emmanuel Bernard chez JBoss. Le projet a été repris d’un essai d’une implémentation JPA-like pour Infinispan, le moteur de grille de données open source de JBoss. A l’heure actuelle, le projet semble être à un stade plutôt expérimental et bien moins avancé que Spring Data, mais il sera intéressant de suivre son évolution et l’orientation qui sera suivie, car les deux projets seront sans doute concurrents.

Concrètement, Hibernate OGM souhaite utiliser Hibernate Core pour stocker des données dans une grille de données distribuée, en l’occurrence Infinispan. L’objectif est de réutiliser l’implémentation existante de JPA plutôt que de repartir de zéro, pour mapper des entités et des relations.

Pour conclure

Pour l’instant, en dehors de l’API Graph, Spring Data est en cours de développement et il n’est donc pas encore question d’utiliser ces librairies en production. Néanmoins, l’avancement actuel des différentes librairies laisse déjà présager de plusieurs atouts à leur utilisation :

• intégration au framework Spring et apport de ses facilités de configuration.
• abstraction par rapport aux implémentations des différentes solutions de stockage NoSQL et apport de surcouches aux connecteurs, notamment grâce aux systèmes de mapping par annotations. Il y a encore du travail sur ce point pour offrir toutes les fonctionnalités de chaque base de données et y gagner réellement par rapport à l’utilisation d’une API de plus bas niveau.
• développement facilité dans une approche orientée Domain-Driven-Developpment.

Mais la perspective la plus intéressante est l’émergence de solutions unifiées de mapping objet/base permettant de limiter les spécificités à chaque base. Spring Data et Hibernate OGM ont un potentiel intéressant car ils ouvrent la voie vers une abstraction de plus haut niveau pour des implémentations et surtout des concepts de stockage de données très divers.

En s’attaquant à ces problématiques de mutualisation, ces projets attaquent la question complexe des frontières entre ces différents concepts :

• Peut-on espérer avoir une abstraction suffisante pour passer d’une manière transparente d’une implémentation relationnelle à certains modes de stockage NoSQL?

Spring Data tente d’adresser ce problème avec le socle commun du framework et le projet Spring Data Mapping, de même qu’Hibernate OGM en réutilisant Hibernate Core pour Infinispan. Mais il faudra être très prudent sur ce point et ne pas tomber dans le piège de vouloir faire du relationnel classique dans une base clé-valeur ou document par exemple, en risquant de perdre les avantages de ces représentations.

• Dans quelle mesure peut-on outiller les développements pour utiliser conjointement et de manière transparente plusieurs systèmes de représentation des données?

Dans ce sens, Spring Data adresse directement cette frontière, avec la notion d’entités partielles pour l’API Graph : une même application peut être amené à utiliser plusieurs techniques de stockage conjointement, et nous avons besoin d’outils pour faciliter ces développements.

Finalement, les deux projets étudiés ici adressent un point essentiel : le mouvement NoSQL ne propose pas simplement de nouvelles techniques de stockage, mais vise surtout à adresser les solutions adaptées à chaque problème, en arguant le fait qu’il n’existe pas de solution unique parfaite.

L’écosystème autour de NoSQL et du stockage distribué est bien vivant, et surtout il est bien parti pour gagner en maturité et en accessibilité pour les développements Java. On suivra donc avec attention la sortie des premières versions définitives!

Suggestion d'articles :

1. Data Grid or nosql? same, same but different…
2. REST en JAVA avec la JSR-311
3. Soirée Spring au Paris JUG

Lorsqu’on écrit une application avec des données persistantes, il est souvent nécessaire de pouvoir réaliser de l’audit sur les modifications. Aujourd’hui, l’état de l’art pour la persistance des données se base sur des outils de type ORM à travers l’interface JPA en Java. Etre capable d’ajouter à chaque table la date de création et de dernière mise à jour est souvent la première demande en terme d’audit. Borémi et moi avons du répondre à cette question en mission. Nous avons regroupé et étudié différentes implémentations, notamment mises en oeuvre par d’autres Octos. De façon à vous aider à choisir le meilleur outil dans ce genre de situation, je vais vous présenter dans cet article (en anglais) les différentes solutions que nous avons comparées.

Suggestion d'articles :

1. Tours JUG – Apache Maven, mise en œuvre en entreprise
2. Le jour où la documentation a disparu
3. Mon action lean du jour