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é

A moins de s’être limité à dessiner des ronds et des carrés avec Silverlight, vous avez sans doute déjà tenté d’utiliser un des templates de projets du Silverlight Toolkit permettant de faire des tests unitaires pour vos applications RIA! Plein de bonne volonté, vous vous êtes heurtés aux multiples inconvénients de cette solution :

• Framework de tests spécifique à Silverlight
• Obligation de lancer une application « conteneur » pour lancer vos tests
• Usabilité plus que discutable de cette même application
• Impossibilité d’utiliser une métrique comme la couverture de code
• et j’en passe…

N’abandonnez pas encore ! Je vous proposer ici une solution pour venir à bout de ces limitations… plus d’ excuses, vous pourrez tout tester …

la suite par ici en anglais…

Suggestion d'articles :

1. Flex vs Silverlight
2. Formation Silverlight Tour à Paris les 19,20 et 21 janvier
3. Formation Silverlight Tour à Paris – 28, 29, 30 Avril

Le framework Flex permet d’écrire très rapidement des IHM fonctionnelles, notamment grâce au langage MXML. Celui-ci permet effectivement de décrire l’interface avec peu de lignes de code.

Seulement, voilà, une fois l’étape du POC passée, les fichiers MXML s’accumulent, le code ActionScript s’insinue petit à petit dans le code MXML pour implémenter les handlers d’événements, les appels de services, la logique métier. Après quelques temps, il devient de plus en plus difficile de savoir d’où viennent les données affichées (ie. quel code a mis à jour la donnée ?), d’où provient un appel de service (surtout d’où proviennent les valeurs des arguments de cet appel).

Dans cet article, nous verrons quelques bonnes pratiques permettant d’assurer la maintenabilité d’une application Flex.

Séparation des responsabilités

La première étape consiste à séparer les responsabilités du code de l’application. En effet, lorsqu’une même méthode doit collecter les données (ex : dans un formulaire), les préparer pour l’appel d’un service distant, appeler le service et mettre à jour la vue, il devient difficile de la tester ou de retrouver l’origine d’un bug.

Commençons par le modèle de données qui gagnera à se retrouver dans des classes séparées. En effet, il sera alors plus facile d’identifier les données à mettre à jour. Par exemple, lorsque le résultat d’un appel de service arrive, les données reçues seront placée dans ce modèle. Plus besoin de se poser la question de savoir si toutes les données ont été mises à jour, elles sont uniques et regroupées dans ces classes de modèle. On créera, par exemple, un modèle par vue (au sens fonctionnel de l’application).

Ensuite, les appels de services méritent eux aussi d’être encapsulés dans des classes dédiées afin de ne pas écrire 3 fois le même code technique et de les écrire de 3 façons différentes. Il deviendra alors simple d’ajouter des fonctionnalités communes aux appels de services (ex : authentification, gestion des exceptions, …) et de les remplacer par des mocks dans les tests.

On retrouve ainsi quelques-unes des recommandations du pattern MVC et de ses cousins (MVVM, MVP, …), c’est toujours bon de se les remémorer de temps à autre.
En Flex, il existe un certain nombre de frameworks comme Cairngorm, PureMVC ou encore Mate (et bien d’autres) qui vous permettront de mettre en place cette séparation des responsabilités et ainsi d’améliorer la maintenabilité (en même temps que la testabilité) de votre application. Il ne faut cependant pas obligatoirement sélectionner l’un de ces frameworks tant que quelques règles d’organisation du code ont été définies et partagées par tous les développeurs du projet. Ces frameworks ne sont qu’un moyen d’appliquer ces règles.

Circulation des données

La seconde étape consiste à définir « un sens de circulation » des données dans l’application afin de faciliter le debuggage de celle-ci (ie. mieux comprendre d’où viennent les données et où vont les données) et de favoriser la réutilisation et testabilité des composants Flex écrits.

La partie « vue » d’une application Flex se définie par un arbre de composants (MXML et ActionScript) :

Les nœuds de l’arbre étant des composants conteneurs (*Box, Canvas, List, …) contenant d’autres composants plus primitifs (Label, Button, …) ou d’autres conteneurs.
Avec une séparation entre le modèle et les appels de services et la vue, il reste que n’importe quel composant peut se binder sur le modèle de données et peut effectuer un appel de service. Ce composant n’est alors plus réutilisable dans un autre contexte : il dépend des données sur lesquelles il est bindé et ne peut plus être utilisé pour en afficher d’autres. Pour lever cette limite, il faut que les données sur lesquelles il se binde lui soit injectées.
De même pour les appels de services, pour que le composant puisse être utilisé dans un autre contexte (qui nécessite l’appel d’un autre service ou qui ne nécessiterait pas d’appel du tout), il faut supprimer la dépendance vers cet appel de service (ie. le composant ne devrait même pas « savoir » qu’un appel est effectué lorsqu’un événement intervient).

La solution à ces 2 problèmes de dépendance est de repousser le problème au composant parent :). Ce composant parent pourra alors, soit déporter à nouveau le problème à son parent (en ajoutant des informations au passage si besoin), soit être lui-même dépendant du modèle et du service. En fait, à partir d’un certain seuil dans la hiérarchie de composants (en la remontant), il n’est plus vraiment envisageable de parler réutilisation (cela peut être le composant racine) et avoir des dépendances n’est plus vraiment problématique.

On obtient alors une circulation des données qui ressemble à ceci :

Les données redescendent la hiérarchie via le binding (ie. un composant binde ses attributs aux attributs des composants qu’il contient) :

Dans View1.mxml :

<Componentx title="{modelView1.viewTitle}" />

Dans ComponentX.mxml :

<mx:Label text="{title}" />

Et elles remontent par l’intermédiaire d’événements envoyés par les composants les plus bas dans la hiérarchie. Ces événements sont retransmis (avec du code ou avec la fonctionnalité de bubbling qui leur permet de remonter automatiquement la hiérarchie de composants) ou transformés en événement de plus haut niveau par le composant parent.

Dans ComponentX.mxml :

<mx:Button click="dispatchEvent(new AddItemEvent(this.item))" />

Dans View1.mxml :

<Componentx addItem="serviceProxy.addItem(event.item)" />

Ce mode de fonctionnement revient en fait à définir une API claire des composants développés :

• Les attributs exposés reçoivent les données en entrée
• Les données ressortent via les événements envoyés par le composant

Au passage cela facilite ainsi la testabilité du composant.

Conclusion

Une fois ces 2 principes appliqués sur une application Flex, celle-ci devrait mieux résister à l’augmentation de la quantité de code et rester maintenable plus longtemps. Il faut cependant garder à l’esprit que ces principes ne seront probablement pas suffisant et de nouveaux devront être imaginés s’adaptant au contexte de chaque projet afin de favoriser la lecture du code de l’application dans sa globalité.

Suggestion d'articles :

1. Flex vs Silverlight
2. Quand Spring s’invite dans une application Flex …
3. Référencer les applications RIA Flex et Silverlight

L’arrivée des terminaux mobiles en entreprise et la popularité de l’iPhone avec son modèle économique basé sur l’AppStore ont engendré le retour massif du développement d’applications natives, permettant de profiter de l’ergonomie, de la puissance et des nouvelles fonctionnalités des smartphones.

HTML5, la nouvelle version du standard du web, a été conçu pour remédier à ces lacunes. Quel est donc l’impact de HTML5 sur le choix entre application native ou application web?

Les nouvelles fonctionnalités de HTML5

Nous allons ici étudier les nouvelles fonctionnalités de HTML5 et voir s’il rattrape partiellement ou totalement les applications natives.

Des cas d’usages qui manquent encore

Nous pouvons d’ores et déjà distinguer ces besoins justifiant le choix de développer en client lourd plutôt qu’en HTML5:

• le push de données : même si comme on l’a vu, HTML5 apporte de nouvelles fonctionnalités concernant le push de données, cela n’atteint pas les possibilités des clients natifs. En effet, vous ne pourrez pas contrôler que l’utilisateur ne ferme pas son navigateur;
• le multi-touch : les applications web gèrent très difficilement le multi-touch, même si des initiatives sont déjà lancées (cf. http://vimeo.com/6214945). Il est par exemple très difficile de manipuler une carte dans Google Maps avec ses deux doigts sur un mobile tactile, l’action se mélangeant avec la navigation sur la page;
• le besoin d’accès aux ressources système : pour des raisons de sécurité, les applications web ne peuvent pas accéder directement aux ressources systèmes et aux fichiers stockés sur disque. Typiquement un système à la Dropbox ou un lecteur de musique stockée en local (et non en streaming) n’est pas réalisable aujourd’hui en web.

Les navigateurs mobiles sont-ils prêts pour HTML5 ?

HTML5 apporte de nouvelles fonctionnalités mais où en sont les navigateurs des mobiles sur le support ce standard ? Peut-on déjà en bénéficier sur les différents smartphones du marché ?

Google et Apple participent énormément au standard HTML5, cette participation est un réel bénéfice pour les utilisateurs de smartphones Android et iPhone qui bénéficient ainsi des avancées de Chrome et Safari dans leurs mobiles. Cependant il faut prendre en compte que la majorité des téléphones Android est encore en version 1.5 ou 1.6 dont le navigateur ne bénéficie pas des fonctionnalités d’HTML5 ^[1]. Ce n’est pas le cas des iPhones, dont la majorité utilisent la dernière version majeure de l’OS ^[2].

Les autres OS mobiles tels que RIM OS (BlackBerry), Symbian ou Windows mobile n’ont pas de navigateurs intégrés prenant en compte HTML5. Leur seule alternative est le navigateur d’Opera mais Opera mobile commence seulement à intégrer quelques fonctionnalités d’HTML5 et accuse du retard par rapport aux navigateurs d’Android et de l’iPhone.

Si nous prenons les dernières versions d’OS d’Android et iPhone, leur navigateur est capable de gérer la plupart des fonctionnalités d’HTML5 à part le drag&drop et le multimédia qui ne sont pas du tout implémentées. Concernant le drag&drop, on imagine mal avoir cette fonctionnalité dans nos mobiles étant donné que nous utilisons cette technique pour se déplacer dans la page de notre navigateur.

Il également intéressant de voir le trafic Internet des différents navigateurs mobiles ^[3]. Ces chiffres sont variables entre les différentes zones géographiques mais l’iPhone est le téléphone le plus utilisé pour naviguer sur Internet même si Opera est beaucoup utilisé en Europe. En Amérique du Nord où le marché des smartphones est plus développé, les navigateurs supportant HTML5 (iPhone et Android) représentent 77% du traffic Internet mobile.

Conclusion sur l’impact de HTML5

En conclusion, si l’intérêt de choisir une application web concerne en général plutôt la réduction des coûts de développement (une seule application à développer pour tous les terminaux), HTML5 permet d’augmenter la valeur des applications web en offrant de nouvelles fonctionnalités et donc d’augmenter la compétitivité des applications web par-rapport aux applications natives. Le canal de diffusion restera cependant le même, une application web et une application native ne s’acquerra pas de la même façon. La volonté d’être présent dans un Application Store peut être l’élément déterminant de ce choix.

_{[1] Android Platform Versions, 3 mai 2010
[2] Updated iPhone OS Stats, 22 décembre 2009
[3] 2009 Mobile Web Trends Report, 5 janvier 2010}

Suggestion d'articles :

1. Applications mobiles multi-plateformes: les approches PhoneGap et Titanium Mobile
2. OCTO à Paris Web 2010 pour un atelier HTML5
3. Ce que jQuery Mobile nous apprend sur le Web Mobile

Je travaille sur un projet GWT depuis un peu plus d’un an (26K lignes de Java, à peu près autant de code en test, GWT 1.7.1). GWT 2 est sorti récemment, avec son lot de nouveautés. Plusieurs questions se posent donc :

• Dois je migrer vers GWT 2 ? (ou « Qu’est ce que GWT 2 va apporter à mon projet ? »)
• A-t-on vraiment le choix ?
• Combien cela va t il me coûter ?
• Comment vendre ce coût à ma MOA ?

Afin de répondre à ces questions ô combien importantes, j’ai donc fait quelques essais avec GWT 2. Voici le résultat.

Les nouveautés

Cette liste n’est pas exhaustive, elle contient juste celles qui me semblent importantes. La liste complète est ici.

Le nouveau Dev Mode

Cette nouveauté permet au développeur d’utiliser son navigateur habituel au lieu de celui qui était embarqué dans le Hosted Mode. Qu’est ce que cela change ? Sous windows, au lieu d’être obligé d’utiliser Internet Explorer 6, les développeurs vont pouvoir utiliser Firefox. Outre le moteur Javascript beaucoup plus performant, il est désormais possible d’utiliser Firebug !

Les développeurs sous Windows vont donc pouvoir avoir le même confort de développement que sous Mac (ou le Hosted Mode utilise Safari depuis toujours :-)). Pour la petite histoire, j’ai un jour calculé la différence de vitesse de l’application dans le Hosted Mode entre un Mac et un PC : cela va 6 fois plus vite avec Mac…

Cette nouveauté va donc améliorer grandement le confort de travail des développeurs. Toutefois, le navigateur cible du projet est Internet Explorer 6 : on est quand même obligé de l’utiliser pour mettre au point les CSS…

Le code splitting

Cette nouvelle fonctionnalité permet de séparer une application GWT en plusieurs fichiers Javascript, ce qui permet d’améliorer les performances au chargement. Pour plus d’informations, voir ici et là.

J’ai essayé rapidement cette fonctionnalité sur mon projet, pour lequel le Javascript fait 970K (ce qui commence à être critique). Au bout de quelques essais, je n’ai pas réussi à splitté mieux qu’en deux blocs de 969K / 1K.
Soit je ne peux pas splitter mon projet facilement parce qu’il n’a pas été prévu pour, soit il faut que je passe plus de temps dessus. Mais la fonctionnalité est là.

La gestion des ressources

Cette nouvelle version du système de gestion des ressources va nous permettre d’améliorer un des plus gros problème de maintenance que nous avons avec notre application GWT : la maintenance des CSS. Avec GWT 1.7.1, nous avons

• Des CSS externes à l’application Javascript
• Ces CSS contiennent des liens vers des images, qui sont elles aussi externes à l’application Javascript
• Les classes CSS sont en dur dans le code (c’est à dire sous forme de chaînes de caractères)

Avec GWT 2 :

• Les CSS seront internes à l’application Javascript (packagées par GWT dans cette application, de manière optimisées)
• Les images seront elles aussi internes à l’application Javascript, même quand elles sont seulement référencées par CSS (non utilisées sous forme d’objet Image dans le code). Voir ici pour plus d’informations. Ce que cela améliore :
  • GWT package l’image sous la forme la plus adaptée (image inlinée dans la CSS, image packagée avec d’autres dans une grande image, image indépendante)
  • GWT se charge de remplir pour nous certaines propriétés de l’image : background-image, width, height, clip. Le nom du fichier de l’image n’est plus dans la CSS, mais dans une interface Java. Cela s’applique également à quelques autres déclarations (repeat notamment)
  • GWT gère pour nous les problématiques de cache sur les ressources (plus de mise en production problématiques à cause des reverse proxy qui cachent des vieilles ressources)
• Dans le code Java, les classes CSS ne seront plus écrites en dur, mais seront des appels Java sur une interface. Cela permet de faciliter la maintenance et le refactor. De plus, GWT vérifie que toutes les classes déclarées dans la CSS sont bien déclarées dans l’interface Java correspondante, ce qui permet de voir quel bout de code utilise une classe CSS donnée !

Hélas, la migration de nos CSS actuelles vers ce système ne va pas être gratuite. Avant GWT 2.0, nous avions déjà des douleurs avec les CSS, et avions prévu de les traiter. Nous allons donc pouvoir profiter des nouveautés pour ce chantier.

Les layouts

En GWT 1.7, nous avons fait tout le positionnement graphique avec des VerticalPanel, HorizontalPanel, et beaucoup de CSS. Cela pose 2 problèmes :

• Le code HTML généré par des VerticalPanel et HorizontalPanel n’utilise que des tables HTML. Le code de la page est donc très lourd et très peu lisible
• L’effet de style CSS sur des éléments contenus dans des tables est assez variable selon les navigateurs, le type de composant. Par exemple, dans un HorizontalPanel, on peut dimensionner un composant par sa taille en pixel, mais pas par sa taille relative.

Les développeurs de GWT ont donc ajouté dans GWT 2 un nouveau mécanisme, les layout panels, qui sont basés sur des div, plutôt que des tables. Cela est beaucoup mieux, car

• Le code HTML est moins lourd (plus de <table><tbody><tr><td>, mais juste un <div>)
• L’application des styles est beaucoup plus complète et surtout, est prédictive.

Dans les exemples fournis avec GWT, le positionnement est fait de deux manières :

• Soit avec les nouveaux composants LayoutPanel pour les mises en pages compliquées (SplitBar, Layout North East West South, Stack Panel…)
• Soit avec des HtmlPanel, dans les lesquels ont mets des <div>, et qu’on positionne via CSS.

J’avoue être convaincu par cette approche qui permet de positionner simplement et efficacement les composants. Dans notre projet, nous allons migrer vers ce nouveau système en même temps que le refactor des CSS.

Le UI binder

GWT 2 permet de décrire les interfaces en XML au lieu d’écrire plein de code Java. Concrètement, au lieu de faire plusieurs lignes new VerticalPanel, new HorizontalPanel, add, add, add… on écrit un fichier XML qui décrit cet agencement. Or notre application contient déjà beaucoup d’interfaces, décrite en Java… Donc ?

• Pour moi, on ne gagne rien en terme de modularité / expressivité par rapport à du Java. C’est tout aussi verbeux (ou quasiment), plus difficile à maintenir (le Java est beaucoup plus outillé que le XML, notamment pour le refactoring)
• Un des avantages de GWT est que tout est en Java & CSS : pas de HTML, pas de Javascript. Le UI Binder impose de ré -introduire du XML : cela fait un troisième language, cela n’est pas forcément une bonne idée pour la maintenance.
• Dès que l’interface devient complexe et dynamique, on ne pourra plus utiliser ce système, il faudra écrire l’IHM en Java. Comme en Flex, on peut donc décrire l’interface soit en XML (déclaratif), soit en ActionScript (programmatif). Le language du UI Binder est cependant loin d’avoir l’expressivité du XML de Flex : il n’y a notamment pas de mécanisme de binding automatique de propriétés de composant graphique sur des variables du code.
• L’apport du UI Binder est de séparer explicitement la description de l’interface du code associé. Cela est effectivement plus propre au niveau architecture applicative. Cependant, dans notre projet, nous avions déjà fait cette séparation au niveau du code Java. Cela n’est certes pas aussi joli, mais c’est déjà satisfaisant.

Migrer vers le UI Binder pour du code existant ne me paraît donc pas pertinent. Si l’on démarre un nouveau projet ou que l’on ait à développer de toutes nouvelles IHM, UI Binder permettra effectivement une meilleure productivité. Espérons que GWT 2.1 contiendra [enfin] un mécanisme de binding, comme en Flex.

Les tests

Hélas, GWT 2 n’apporte pas grand chose au niveau des tests. La seule différence est que GWTTestCase n’est plus plateforme-dépendant. HtmlUnit est utilisé par GWTTestCase, au lieu du navigateur embarqué dans l’ancien Hosted Mode. D’après ce que j’ai pu essayer (je n’y ai pas consacré beaucoup de temps), les tests sont plus lents qu’avant (en local sur Mac du moins). La solution que nous avons mis en place (ce framework, décrit ici), est donc toujours, à mon avis, pertinente. Nous allons donc porter notre framework de test vers GWT 2, ce qui devrait ne pas être trop compliqué.

Les autres nouveautès

Il y a d’autres nouveautés : optimisation du compilateur (on gagne 30K sur 970K de Javascript), outil pour détecter les problèmes de performances, compilation « draft » pour accélérer l’intégration continue …

A-t-on vraiment le choix ?

En fait, non :-( La branche 1.7 n’est plus maintenue. Le fait de choisir GWT comme framework de développement implique que l’on choisisse également de suivre les versions, puisque les anciennes branches ne sont pas maintenues. On ne peut donc pas bénéficier ni des corrections de bugs, ni du support des nouveaux navigateurs, ni évidemment des nouvelles fonctionnalités… La seule chose que l’on contrôle, c’est le moment où l’on fait la migration. Cela n’enlève cependant rien au fait que la migration doit être évaluée en terme d’apport et de coût. A terme, il faut la faire.

Combien cela va t’il me coûter

Après cette brève présentation des nouveautés, revenons à nos questions. Combien cela va t il me coûter ? Et bien cela dépend de quoi on parle :

• Utiliser GWT 2.0 au lieu de 1.7.1 : le coût est quasiment nul. J’ai changé la version de GWT dans le pom, l’application se lance dans l’environnement de développement sans aucune modification, elle compile, est déployable et fonctionne normalement. Il y a quelques coûts indirects :
  • Quelques modifications mineures sont à apporter à l’environnement de développement (installation des nouveaux plugins, modifications de quelques classes utilisées pour le développement (nous n’utilisons pas le plugins Eclipse pour GWT))
  • Même si l’application fonctionne, quelques warnings apparaissent dans l’application dus à des API dépréciées. Il faudra donc les corriger.
  • Nous ne pouvons pas migrer vers GWT 2 le temps que le framework de test n’a pas été porté. Etant Open Source, je n’inclus pas le coût de ce portage dans le coût de migration
  • Attention, si votre application utilise GWT 1.5.x ou antérieur, des APIs ont été modifiées. Je vous conseille donc de passer sous GWT 1.7, de corriger tous les warnings, puis de migrer vers GWT 2.
• Coût pour utiliser proprement le nouveau système de CSS : 2 semaines de travail pour un développeur. C’était un chantier déjà identifié, la venue de GWT 2 ne fait qu’apporter une solution plus propre pour le faire. Ayant déjà des douleurs avec les CSS et GWT 1.7, ce coût là ne fait donc pour moi pas partie du coût de migration. Par contre, la migration vers GWT 2 permet d’améliorer le ROI du refactor des CSS, en utilisant les nouvelles fonctionnalités.
• Coût pour utiliser le code splitting, c’est pour moi un chantier indépendant de la migration GWT 2. Mais nous allons devoir le faire, notre Javascript devient trop gros. Cela ne devrait prendre que quelques jours.

Si l’on part du principe que le framework de test est compatible GWT 2, le coût de migration est donc marginal. On peut donc bénéficier facilement des améliorations au niveau du développement (nouveau DevMode), et ensuite progressivement refactorer le code pour utiliser les nouvelles fonctionnalitées (notamment CSS)

Comment vendre ce coût à ma MOA ?

Vu de la MOA (ou du client final), GWT 2 n’apporte … rien. Cependant, comme le coût de migration est faible et étant donné que cela apporte pas mal de choses aux développeurs, cela ne devrait pas être trop difficile à négocier. Surtout vu le bénéficie prévisible en terme de maintenance CSS.

D’après l’équipe de GWT 2, cette version était effectivement consacrée au développeurs. Les versions suivantes devraient elles être consacrée aux utilisateurs. A suivre …

Suggestion d'articles :

1. Mutation Testing, un pas de plus vers la perfection
2. Retour des DevOpsDays 2010 à Hambourg
3. Vers des API haut niveau pour Java et NoSQL avec Spring Data

La première partie de cet article a permis d’introduire la problématique de chargement des RIA, en commençant par expliquer comment optimiser le temps de téléchargement d’une application web basée sur GWT, notamment à travers la modularisation. Cette deuxième partie aborde l’optimisation du temps d’initialisation d’une application sur le browser, toujours illustré à travers la technologie GWT.

Optimiser le temps d’initialisation d’une application GWT

Optimiser les communications client/serveur

Une des premières étapes de l’initialisation d’une RIA consiste à charger des données à travers une ou plusieurs requêtes au serveur. Ces données sont requises à l’initialisation, soit parce qu’elle sont affichées sur la vue initiale, soit parce qu’elles participent aux traitements déportés côté client. Les données qui transitent entre le client et le serveur doivent donc correspondre, ni plus ni moins, à ces besoins. En effet, l’objectif est de n’envoyer au client que les données réellement utilisées pour optimiser aussi bien le volume de données téléchargées que le temps de sérialisation/désérialisation des objets, quelque soit le protocole utilisé. Pour cela, un des pièges à éviter selon moi est d’exposer, côté serveur, des services qui renvoient directement le modèle d’entités persistantes. Même si, techniquement, cette solution est aujourd’hui rendue possible par l’utilisation du framework Gilead, elle impose un modèle souvent inadapté aux besoins du client (en dehors des applications de type CRUD) d’un point de vue fonctionnel et limité en terme d’optimisation. En effet, le mécanisme de chargement des collections à la demande (lazy/eager) peut être exposé au niveau de l’API serveur mais s’avère souvent insuffisant lorsqu’il est question de réduire le nombre de requêtes et d’optimiser les temps de réponse.

L’utilisation d’un modèle DTO (Data Transfer Object) devient alors souvent incontournable, même si cette méthode est moins productive que Gilead puisqu’elle impose l’implémentation du mapping entre les deux modèles (DTO <=> persistant). Un moyen simple d’obtenir une visibilité sur les requêtes serveur avec leur temps de réponses ainsi que les temps de sérialisation/déserialisation est d’utiliser le DebugPanel. Ce composant graphique s’utilise durant les phases de développement en s’insérant dans la même page web que l’application GWT et offre un certain nombre d’indicateurs indispensables pour contrôler précisément ce qui passe entre le client et le serveur.

Profiter pleinement du caractère asynchrone de la technologie GWT

Les moteurs Javascript sont aujourd’hui mono-thread, autrement dit les browsers ne peuvent pas exécuter plusieurs traitements en parallèle. Ajax permet de simuler un comportement multi-thread en offrant la possibilité de paralléliser les  traitements entre le client et le serveur à travers des requêtes asynchrones. Comme on l’a évoqué précédemment, le chargement d’une page nécessite souvent une sollicitation du serveur pour récupérer les données à afficher. Le client doit également instancier un certain nombre de composants. Un axe d’optimisation est donc de paralléliser recherche des données sur le serveur et instanciation des composants de la vue sur le client. Concrètement, voici une comparaison entre deux séquences de chargement, l’une ne profitant pas de la parallélisation apportée par l’asynchronisme, l’autre oui :

Une autre bonne pratique consiste à afficher les informations de manière progressive sur la vue initiale, suivant un découpage fonctionnel. En effet, certaines RIA affichent la vue d’accueil une fois qu’elle est entièrement initialisée, à la manière des sites web classiques… Le temps d’attente peut devenir assez frustrant pour l’utilisateur, surtout si finalement l’information qui intéresse le plus l’utilisateur aurait pu être affichée très rapidement! L’idée est donc d’afficher le plus tôt possible les fonctionnalités pour lesquels l’utilisateur ouvre l’application. L’exemple le plus parlant qui me vient en tête est l’affichage des mails dans la vue initiale de GMail, même si le panneau « Chat » n’est pas encore chargé.

Pour aller plus loin, un bloc fonctionnel peut lui-même être très lourd à charger entièrement. Ce cas de figure arrive fréquemment lorsqu’on souhaite faire apparaître une liste ou un tableau volumineux. Pour rester sur l’exemple Google, mais cette fois-ci avec l’application Wave, on peut remarquer que les Waves ne sont pas toutes affichées dès l’apparition de la page d’accueil. Elles apparaissent de manière progressive, ce qui permet à l’utilisateur de pouvoir très rapidement consulter les Waves qui se trouvent en haut de la liste (les plus récentes) sans devoir attendre que la liste soit entièrement remplie. En GWT, l’API DefferedCommand facilite l’implémentation de ce chargement progressif. En fait, Javascript étant mono-thread, GWT traite l’asynchronisme à travers une pile de commandes. Le fait d’implémenter une DefferedCommand permet d’ajouter une commande à cette pile. Cette commande est alors traitée lorsque toutes les commandes préalablement ajoutées à la pile ont été exécutées. Voici un exemple d’utilisation de l’API permettant de charger un tableau volumineux de manière progressive :

1
2
3
4
5
6
7
8
9
10

//on charge les 5 premières lignes du tableau tout de suite
loadTableLines(0, 4);
//on charge le reste du tableau en différé par lots de 5 lignes
for(int i = 5 ; i < list.length() ; i+5){
    DeferredCommand.add(new Command() {
        public void execute() {
            loadTableLines(i, i+4);
        }
    });
}

Du chargement à la demande (ou « lazy loading »)…

Il existe différentes approches permettant de dessiner l’architecture d’une GUI, les principales étant MVC, HMVC et MVP. Ces architectures permettent de découper l’application en composants (MVC ou MVP) améliorant la modularité de l’application, et donc sa maintenabilité et sa réutilisabilité. Concrètement, prenons l’exemple d’une application ressemblant à ce schéma classique :

Pour ce type d’application, et sans rentrer dans le détail des widgets composants les vues ni dans le détail des classes du modèle, on peut imaginer un découpage MVP ressemblant à celui-ci :

Pour afficher la vue d’accueil, il est donc nécessaire d’instancier 3 composants : le menu, l’en-tête et le contenu initial, c’est à dire la liste des comptes dans le cas présent. Dans une démarche d’optimisation du temps d’initialisation d’une application GWT, il est important de toujours bien penser à instancier les composants seulement au moment où l’utilisateur souhaite les afficher. En Flex, cela se fait automatiquement pour beaucoup de composant avec une policy par défaut qui est d’initialiser les composants uniquement lorsqu’ils deviennent visibles pour la première fois (voir la doc sur la propriété creationPolicy pour plus d’informations). Ce n’est pas le cas pour GWT où le chargement à la demande doit être implémenté par du code spécifique ou à l’aide du composant LazyPanel ou par le framework MVC/MVP utilisé. Dans cet exemple, les classes View et Presenter des composants ShowAccount et EditAccount ne doivent donc pas être instanciés à l’initialisation de l’application, mais uniquement lorsque l’utilisateur souhaitera naviguer sur une de ces sections via le menu. Cette pratique peut paraître logique et triviale, mais tous les frameworks MVC/MVP ne le gèrent pas. On peut par exemple citer le framework mvp4g qui instancie tous les composants dès l’initialisation, contrairement à la version MultiCore de PureMVC. Attention donc à bien prendre en compte ce critère pour le choix d’un framework d’architecture de client GWT.

… au téléchargement à la demande!

Une fois ce type d’architecture mis en place, les triades deviennent un support idéal au CodeSplitting décrit dans l’article précédent. Il suffit alors d’instancier les différents composants à travers l’API GWT.runAsync(RunAsyncCallback callback) pour mettre en œuvre non plus un chargement à la demande mais un véritable « téléchargement à la demande », permettant de modulariser l’application de manière optimale. En effet, la granularité apportée par ce découpage en triades MVC/MVP permet de minimiser le nombre de téléchargements de modules avec un seul  téléchargement maximum par vue affichée. Pour reprendre l’exemple précédent, on obtiendrait le découpage en modules suivant :

Dans l’idéal, il serait même encore plus intéressant de regrouper plusieurs composants dans un même module en fonction de la fréquence d’utilisation des fonctionnalités par les utilisateurs. Pour reprendre l’exemple d’un client mail, on peut regrouper l’affichage des mails et la vue permettant de rédiger un mail dans le même module, et exclure la vue « Settings » dans un module dédié, car utilisé beaucoup plus occasionnellement. On combine alors téléchargement à la demande des modules et chargement à la demande des composants du module.

Enfin, tout dépend du type de client visé et surtout du type de réseau ciblé (ethernet 10/100Mbps/1Gbps, Wifi, 3G, etc.) mais en général, il est conseillé d’éviter que la taille des ressources téléchargées soit inférieure à 5Ko et supérieure à 500Ko. Ces bornes doivent permettre de cadrer le degré de modularité à adopter. Pour cela, l’utilisation de l’outil SOYC (Story Of Your Compile, inclus dans GWT 2.0) permettra de répartir équitablement le poids de l’application entre les différents modules durant les phases de développement. En effet, l’outil génère des rapports mettant en relief le poids de chaque module, ce qui permet d’identifier les modules dont le poids ne rentre pas dans les bornes qu’on se fixe (ex : 500Ko > poids > 5Ko).

Conclusion

En respectant les bonnes pratiques web, en architecturant et en modularisant les applications GWT avec un mécanisme de chargement/téléchargement à la demande des modules, on répond à la problématique de temps de chargement. Au final, peu importe le nombre de vues implémentées dans l’application, celle-ci est capable d’en accueillir autant qu’on le souhaite sans impacter son temps de démarrage. Si on reprend le graphique des temps de téléchargement et d’initialisation, on voit qu’on tend vers un lissage du temps de chargement entre la vue initiale et les vues suivantes :

Cet article présente des concepts illustrés par des exemples d’utilisation de la technologie GWT. Ces concepts (et notamment le téléchargement à la demande) existent également en Flex.

Suggestion d'articles :

1. Optimiser le temps de chargement d’une application GWT (1/2)
2. Optimiser les performances de vos applications web sur mobile
3. Quand Spring s’invite dans une application Flex …

Alors que Macromedia (racheté en 2005 par Adobe) était parti seul devant, début 2004, dans le développement d’applications RIA en sortant la première version de Flex, voilà que fin 2006 (plus de 2 ans après donc), Microsoft dévoile une première version de sa réponse à Flex nommée Silverlight. Seulement, cette première version n’était là que pour « occuper le terrain » car elle restait encore très loin derrière Flex qui passait à peu près au même moment en version 2. D’ailleurs, à peine cette première version de Silverlight sortie, Microsoft annonçait déjà les premières versions Alpha de la v2 qui viendrait avec une machine virtuelle plus performante, une version allégée de la CLR .Net, en lieu et place du moteur Javascript de la v1. Alors que la v2 est sortie en fin d’année dernière, la v3 sort seulement un peu plus de 6 mois après. Il semble donc que malgré son retard, Microsoft produit à un rythme impressionnant de nouvelles versions de Silverlight en apportant à chaque fois un nombre non négligeable de nouvelles fonctionnalités. Même si Adobe continue de faire évoluer sa plateforme et s’apprête à sortir la version 4 d’ici la fin de l’année, les deux technologies sont aujourd’hui au coude à coude.
Dans cet article, nous ferons un tour panoramique de ces deux technologies afin de pointer leurs similitudes et différences.

Le principe de fonctionnement

Les deux technologies, que ce soit Flex ou Silverlight, fonctionnent exactement selon le même principe :
Il s’agit d’une application embarquée dans une page HTML (donc téléchargée depuis un serveur web) dont l’exécution s’effectue sur le poste client et est totalement déléguée à un plugin tiers du navigateur web, le Player Flash pour Flex et un nouveau plugin fourni par Microsoft pour Silverlight.
Flex profite bien évidemment de la popularité de déploiement du Player Flash installé sur une grande majorité des machines connectées à Internet. Pour le plugin Silverlight, tout reste à faire mais Microsoft rattrape vite son retard, notamment en profitant d’autres canaux de distribution que le navigateur web tel que Windows Update.

Une fois démarrées, ces applications fonctionnent en mode client-serveur, c’est à dire en gardant l’état de l’application (ie. la session utilisateur) sur le poste client et en effectuant des appels de services avec le serveur.

Le modèle de programmation

Concernant le modèle de développement, on retrouve là encore de grandes similitudes entre Flex et Silverlight qui utilisent toutes les deux un format de fichier XML pour décrire l’IHM : MXML pour Flex et XAML pour Silverlight (emprunté à WPF). Ces fichiers XML permettent de décrire l’agencement des composants graphiques et de paramétrer les propriétés de ces composants.

Exemple MXML :

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
    <mx:Text text="Hello World !" />
</mx>

Exemple XAML :

<UserControl x:Class="SilverlightApplication2.Page"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Width="400" Height="300">
    <Grid x:Name="LayoutRoot" Background="White">
        <TextBox Text="Hello World !" />
    </Grid>
</UserControl<

Associés à ces fichiers XML, un langage de programmation objet est utilisé afin de traiter la dynamique de l’application : les événements utilisateur et la logique de l’IHM. Alors que Flex utilise l’ActionScript 3 qui est le langage de prédilection du Player Flash, Silverlight s’appuit sur C# (et même d’autres languages tels que IronPython ou IronRuby). C’est un gros avantage pour Silverlight qui profite de la maturité de C#, beaucoup plus avancé qu’ActionScript tant en terme de langage que d’outillage. En effet, C# a été pensé dès le départ pour le développement d’application alors qu’ActionScript a commencé en tant que langage de scripting pour les applets Flash pour ensuite évoluer vers un langage objet typé fortement.

Ce n’est pas seulement le langage en lui-même dont profite Silverlight mais aussi de tout l’écosystème .Net. En effet, une application développée avec Silverlight pourra profiter de la plupart des bibliothèques .Net (après recompilation), mais aussi du grand nombre d’outils disponibles pour le développement .Net.
L’écosystème Flex, qui est en pleine ébullition, rattrape son retard avec des bibliothèques et des outils de développement en tout genre qui sortent régulièrement, notamment grâce à une communauté très active de projets opensource. Ils restent cependant jeunes face à .Net.

Enfin, même si la machine virtuelle de Silverlight est récente, elle a hérité des capacités de la CLR .Net et profite donc de la maturité de celle-ci comme par exemple des systèmes de compilation Just In Time ou de Garbage Collecting. La machine virtuelle du Player Flash, malgré ses évolutions récentes pour inclure ces mécanismes, reste moins avancée. Cette dernière profite cependant de la maturité de son moteur de rendu graphique, le Player Flash ayant toujours été adapté à l’animation graphique.

Les composants et le développement

Stratégies de chargement d’une application

En ce qui concerne les composants disponibles avec chacune des solutions, on retrouve à peu près les même composants en allant piocher dans des bibliothèques tierces. Silverlight vient cependant avec une bibliothèque de base moins complète que celle de Flex qui s’explique notamment par le choix du mode de compilation d’une application qui diffère d’une solution à l’autre.

En effet, le plugin Silverlight installé sur le poste de l’utilisateur ne contient pas seulement la machine virtuelle mais aussi la bibliothèque de composants de base alors que le Player Flash n’installe que la machine virtuelle (qui implémente seulement l’API bas-niveau de Flash). Cela se traduit par un plugin Flash de 1.8Mo et un plugin Silverlight de 4.7Mo. Le choix d’inclure la bibliothèque de composants de base dans le plugin Silverlight peut s’expliquer par le fait que la plupart des applications utiliseront ces composants et il n’est ainsi pas nécessaire de les retélécharger en même temps que chaque application.
De son côté, la solution n’incluant pas la bibliothèque de base dans le plugin a pour avantage de décorréler le cycle de vie du Player Flash et du SDK Flex mais ce n’est pas la seule raison. En effet, la stratégie de compilation Flex, et notamment la phase de link avec les bibliothèques, diffère de celle de Silverlight. Par défaut, lors de la compilation d’une application Flex, les composants disponibles dans les bibliothèques utilisées (dont le SDK et donc les composants de base) ne sont inclus dans le fichier SWF final que s’ils sont effectivement utilisés par l’application. Ainsi, toute la bibliothèque de composants de base Flex n’est pas inclue dans toutes les applications Flex contrairement à la stratégie de compilation d’une application Silverlight qui embarquera la totalité des bibliothèques utilisées. Flex implémente d’autres stratégies de compilation dont une similaire à la stratégie Silverlight (ie. le téléchargement des bibliothèques dans leur globalité) ou encore la possiblité de télécharger le SDK complet, de le mettre en cache et de le partager pour toutes les applications Flex tout en gardant une « inclusion sélective » des composants des autres bibliothèques utilisées.
Dans l’absolu, aucune solution n’est meilleure qu’une autre, tout dépendra du contexte de déploiement. Flex offre cependant une plus grande souplesse en permettant de maitriser plus finement la taille de l’application.

Création de composants

Une autre différence entre Silverlight et Flex se situe lors de la création de composants personnalisés.
En effet, Silverlight permet de créer deux types de composants, les composants utilisateurs qui sont écris en XAML et les composants personnalisés qui sont complètement écris en C# pour avoir la main sur le rendu du composants. Le premier type est simple à écrire (XAML + code behind en C# comme le reste de l’application Silverlight) mais ne permet pas d’hériter d’autres composants. Le second, par contre, permet l’héritage de composants mais doit être écrit totalement en C# et est donc beaucoup plus complexe à écrire.

En Flex, la création de composants reste plus simple. Pour créer un composant, il suffit de déplacer le morceau de MXML voulu dans un nouveau fichier. La balise racine de ce morceau de MXML devient le composant parent (en terme d’héritage objet). Pour avoir la main sur le rendu du composant, il suffit de surcharger la méthode adéquate de ce même composant (en mélangeant le MXML et l’AS). Flex favorise donc la création de composants réutilisables en ne proposant qu’une solution fexible plutôt que de multiples pour chaque cas d’usage.

Description de l’IHM

Le XAML permet d’aller plus loin en terme de description de l’IHM par rapport à MXML en offrant la possibilité de pouvoir dessiner avec le langage de balisage. Cette fonctionnalité est surtout utile pour des outils WYSIWYG (le résultat en XML étant peu Human Friendly) tel que Expression Blend pour Silverlight. Flex n’offrira cette fonctionnalité qu’avec la version 4 et son format FXG (http://opensource.adobe.com/wiki/display/flexsdk/FXG+1.0+Specification) manipulable avec les outils de la Creative Suite d’Adobe (et son future outil FlashCatalyst pour faire le pont entre designers et développeurs).

Styliser une application

Pour styliser une application, Flex et Silverlight utilisent là aussi des stratégies différentes :
Tout d’abord en ce qui concerne le style simple, c’est à dire les éléments stylisables prévus par le développeur d’un composant, Silverlight utilise des balises XAML pour déclarer des styles qui seront utilisés lors de l’instanciation d’un composant (via l’attribut Style).

Par exemple :

<Grid>
  <Grid.Resources>
    <Style TargetType="Button" x:Key="MyStyle">
      <Setter Property="Stroke" Value="Red"/>
    </Style>
  </Grid.Resources>

  <Button Style="{StaticResource MyStyle}" />
</Grid>

Flex, de son côté, utilise CSS (adaptés au système de composants Flex bien sûr). Celà permet d’utiliser une syntaxe connue des développeurs web et moins verbeuse que du XML.

Dans un fichier CSS :

Button {
  color: #FF0000;
}

Dans un fichier MXML :

<mx:Style source="style.css" />
<mx:Button />

Pour aller plus loin dans le style d’une application, il est utile de pouvoir complètement redessiner les composants. Silverlight utilise la notion de template qui permet de redéfinir en XAML le rendu d’un composant :

<Style TargetType="Button" x:Key="MyButton">
  <Setter Property="Template">
    <Setter.Value>
      <ControlTemplate TargetType="Button">
        <Border Background="Red">
          <TextBlock Text="Fixed text: " />
          <ContentPresenter Content="{TemplateBinding Content}“ />
        </Border>
      </ControlTemplate>
    </Setter.Value>
  </Setter>
</Style>

En Flex par contre, du moins jusqu’a la version 3, il est possible d’utiliser des skins Flash réalisées avec le studio Flash ou directement écrites en ActionScript. La solution de Silverlight est dans ce cas plus abordable et plus flexible puisque le template peut être aussi complexe que nécessaire, ce n’est pas juste une skin. Flex supportera de modifier le rendu d’un composant avec la version 4 en séparant la définition de la vue du reste du composant.

Système d’animation

Les systèmes d’animation de Silverlight et Flex offrent des possiblités équivalentes tout en ayant des approches différentes.
En Silverlight, une animation cible une propriété d’un composant dont elle lissera la transition d’une valeur à une autre.

<Storyboard x:Name="myStory">
  <DoubleAnimation From="0" To="42" Duration="0:0:2"
                   x:Name="moveAnimationX"
                   Storyboard.TargetName="myButton"
                   Storyboard.TargetProperty="x" />
  <DoubleAnimation From="0" To="42" Duration="0:0:2"
                   x:Name="moveAnimationY"
                   Storyboard.TargetName="myButton"
                   Storyboard.TargetProperty="y" />
</Storyboard>

<Button x:Name="myButton" />

Puis en C# :

1
2

...
myStory.Begin();

Alors qu’en Flex, une animation est de plus haut niveau et s’appliquera sur un composant. Son type déterminera le ou les attributs ciblés et se déclenchera lorsque l’attribut sera modifié (il est cependant possible de fonctionner de la même manière qu’en Silverlight : en déclanchant l’animation qui modifiera l’attribut d’un composant).

<mx:Move id="moveEffect" />

<mx:Button id="myButton" moveEffect="{moveEffect}" />

Puis en ActionScript :

1
2
3

...
myButton.x = 42;
myButton.y = 42;

La solution Flex est moins verbeuse, le MXML s’écrit plus facilement par un développeur alors que le XAML est encore une fois, plus destiné aux outils WYSIWYG.

Communication Client / Serveur

Un dernier point de comparaison qui diffère entre Flex et Silverlight est le système de communication client-serveur. Les deux technologies permettent toutes les deux d’effectuer des appels XML / HTTP et SOAP / HTTP selon un modèle de sécurité très proche (ie. appel de service sur le serveur d’où est téléchargé l’application et appel entre différents domaines géré avec un fichier de configuration : crossdomain.xml pour Flex et accesspolicy.xml pour Silverlight).

Pour simplifier le parsing du XML, Silverlight permet d’utiliser Linq alors que Flex utilise E4X (EcmaScript For XML : une syntaxe proche de l’objet pour parser du XML). Ceci permet donc aux 2 technologies de se connecter sur n’importe quel type de serveur qui sait exposer des WebServices SOAP ou REST.

Cependant, elles viennent chacune avec leur technologie d’appel de services qui permet de grandement simplifier la communication entre le client et le serveur. En effet, en utilisant des appels de service WCF en Silverlight ou AMF/HTTP en Flex (disponible en Java, PHP, Python ou Ruby), cela permet de bénéficier d’une (dé)sérialisation automatique que ce soit sur le client ou le serveur et simplifie grandement le développement de ce type d’applications.

Conclusion

Beaucoup de caractéristiques de chacune des technologies Flex et Silverlight n’ont pas été abordées dans cet article pour se concentrer sur ce qui peut servir à les différencier ou qui permet de mieux faire ressortir les avantages de l’une ou l’autre.

Silverlight, malgré le retard avec lequel la première version est sortie, a sû le rattraper en réutilisant la CLR, plus avancée que le Player Flash, mais aussi en s’appuyant sur tout l’ecosystème .Net tant en terme de langage avec C#, qu’en terme d’outillage.
Ainsi, aujourd’hui, les deux technologies ont des capacités équivalentes et quand une fonctionnalité n’existe pas dans l’une, la version suivante prévoit de combler le vide.

En terme de développement, Flex semble plus abordable lorsque l’on s’attarde sur le code écrit, tant en XML (MXML est globalement moins verbeux que XAML mais ce n’est pas un problème si l’on fait confiance aux outils WYSIWYG de Microsoft), qu’en AS et C# (pour l’appel de services par exemple ou la création/le parsing de XML en C# qui utilise une API plus complexe qu’en AS).

Enfin, l’écosystème dans lequel ces applications seront déployées a aussi son importance puisque, même si Flex et Silverlight s’intègrent parfaitement partout où il est possible de faire au moins du XML / HTTP, leur technologie de communication respective avec le serveur facilite grandement le développement mais lie du coup la technologie cliente avec la technologie serveur.
La cible des utilisateurs est aussi un critère déterminant sachant que pour une cible grand public, le Player Flash reste le plus déployé à l’heure actuelle alors que pour des applications internes, la disponibilité du plugin Silverlight ou Flash est maitrisable.

Pour aller plus loin sur la comparaison de Flex et Silverlight, allez voir la vidéo de la session Du RIA pour mon SI Microsoft Silverlight vs Adobe Flex présenté à l’Université du SI 2009.

Suggestion d'articles :

1. Référencer les applications RIA Flex et Silverlight
2. Du TDD pour Silverlight aussi !
3. Quand Spring s’invite dans une application Flex …

La JSR 314 spécifiant la version 2 de Java Server Faces (JSF), le framework de développement d’IHM web fourni par JEE, a été livrée en version finale le 12 mai dernier (cf. http://jcp.org/en/jsr/detail?id=314).

Cette version 2 de JSF cherche à améliorer la productivité des développements, l’intégration d’AJAX et la ré-utilisation. Nous allons parcourir ici les principales nouveautés.

Les principales nouveautés

L’intégration native de fonctionnalités AJAX

Avec JSF 1, il fallait utiliser une autre librairie (RichFaces, IceFaces…) pour faire de l’AJAX, conduisant à une complexification de la configuration (ajout d’un filtre, de dépendances) et obligeant le développeur à maîtriser plusieurs frameworks. JSF2 dispose désormais d’un tag nommé « f:ajax » offrant la possibilité de mettre à jour une partie de la page lors d’évènements. Pour fonctionner, on doit inclure dans la page une librairie JavaScript fournie par JSF2. Par exemple, on veut ici mettre à jour la div panierDiv lors d’un clic sur le lien  addPronostic :


<h:outputScript name="jsf.js" library="javax.faces" target="body"></h>
<h:form>
<h:commandLink id="addPronostic" value="#{match.cote1}" action="#{mesPronosBean.addPronoCote1}">
<f :ajax render=":panierDiv" />
</h:commandLink>
</h:form>
<div id="panierDiv">...</div>

De plus, JSF2 va traiter côté serveur uniquement la partie de la page nécessaire. C’est la notion de partial processing. Cela améliore grandement les performances car auparavant, toute la page était traitée.

Le remplacement de configuration XML par des annotations

JSF 1 centralisait la déclaration des managed bean, de la navigation et bien d’autres choses dans le fichier faces-config.xml. On peut désormais déclarer des managed beans avec des annotations (des frameworks comme Spring le permettaient déjà), économisant des dizaines de lignes de configuration dans le fichier faces-config.xml :

@ManagedBean()
@SessionScoped
public class UserBean {...}

JSF 2 fournit également l’injection de dépendances de managed beans.

De même, les pages de destination peuvent être déclarées directement dans la réponse d’une méthode d’action :

<h:commandButton id="loginButton" action="#{monBean.doAction}"/>

Si la méthode « doAction » renvoie « hello », alors JSF interprétera  l’action « hello » comme la page hello.xhtml , et la cherchera dans les répertoires disponibles. S’il existe plusieurs pages du même nom, on pourra évidemment déclarer la navigation dans le fichier faces-config.xml.
Cependant, JSF laisse la possibilité d’utiliser la déclaration XMLdans tous les cas. Cela peut être parfois plus pratique, par exemple pour centraliser les informations dans un projet assez complexe.

La simplification de la création de composant :

L’utilisation de composants est le grand avantage de JSF. Il doit permettre la ré-utilisation de composants développés en entreprise, ainsi que de composants offerts par des librairies du marché (open-sources ou non).
Malheureusement, développer des composants avec JSF 1 était complexe et nécessitait l’écriture de nombreuses classes Java implémentant différentes interfaces, et de fichiers de configuration (cf. http://blogs.steeplesoft.com/jsf-component-writing-check-list/). Plusieurs initiatives ont vu le jour pour simplifier ce développement, comme le Component Development Kit de RichFaces. Le framework Facelets permettait également de simplifier un peu ce développement. JSF 2 a intégré Facelets et permet de créer des composants de manière déclarative dans un seul fichier XHTML, ne nécessitant plus ni l’écriture d’une classe Java (sauf si besoin est), ni de XML de description. De plus, on peut désormais créer des composants composites, qui peuvent être réutilisés dans d’autres composants.

Par exemple, on va définir un composant affichant le nom et le prénom d’une personne :


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:composite="http://java.sun.com/jsf/composite">
<!-- interface -->
<composite:interface>
<composite:attribute name="user"/>
</composite:interface>
<!-- implémentation -->
<composite:implementation>
<h:form>
<h:outputText value="Prénom : #{cc.attrs.user.forname} Nom : #{cc.attrs.user.name}"/>
</h:form>
</composite:implementation>
</html>


Points-clés :

• composite:interface, composite:attribute et composite:implementation structurent la déclaration du composant.
• #{cc.attrs.user} est la formulation JSF 2 pour récupérer le paramètre «monimage» déclaré par la vue ou le composant qui utilisera ce composant. Cc.attrs sont des mots réservés en JSF 2.
• Le nom du composant est directement déduit du nom du fichier XHTML, et son namespace est construit avec http://java.sun.com/jsf/composite suivi du chemin où se trouve le composant, depuis la racine du site. Il est possible de modifier le préfixe « java.sun.com/jsf/composite », mais on complexifiera le code.

Pour l’utiliser dans une page, si le fichier précédent se nomme par exemple « usercomp.xhtml » et se trouve dans le répertoire « components/util », on l’utilisera comme suit :

<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:util="http://java.sun.com/jsf/composite/components/util">
<util:usercomp user="#{sessionBean.user}"/>
</html>

Ce composant est bien évidemment simpliste, et dès que l’on a du code plus complexe, on devra utliser une classe Java, etc.

Standardiser et simplifier le développement de composants est un point crucial pour l’avenir de JSF. Ces nouveautés vont donc dans la bonne direction. Il faudra encore que les outils de développements suivent pour que cela soit le plus efficace possible : intégration aux IDE, plug-ins et archetypes Maven…

Une gestion des ressources plus puissante

On peut désormais placer les ressources (images, CSS, JavaScript) dans un répertoire nommé « resources » en dehors du répertoire WEB-INF, ou même les inclure dans un JAR à déposer dans ce même répertoire. Cela permet un meilleur versioning des ressources. On accédera par exemple à une image appelée « monimage.jpg » et à la racine du répertoire resources de la façon suivante :

#{resource['images:monimage.jpg']}

Templating

En intégrant Facelets à la la spécification , JSF 2 intègre désormais nativement des fonctions de templating de vue dans JSF. Cela évite encore d’avoir à inclure un framework tiers.

Bilan

JSF2 n’apporte pas de nouveauté révolutionnaire, et pourrait ressembler plus à une amélioration de JSF 1.2 qu’à une nouvelle version majeure. Il améliore tout de même la productivité et la ré-utilisation en simplifiant les développements, et ce de façon non négligeable.
Désormais, les limitations de JSF viendront sans doute de ses principes fondamentaux :

• la nécessité pour JSF de gérer une représentation de la vue entière côté serveur, qui induit une charge de travail importante côté serveur, des temps de réponses plus longs et empêche de réaliser des vraies architectures stateless
• son orientation navigation web classique, entre différentes pages, alors que les applications RIA tendent plutôt vers des applications à une seule page, manipulant des petits fragments du DOM via JavaScript et n’ayant pas besoin d’une vue globale de la page côté serveur
• le principe de génération de HTML avec des tags, qui nécessite à la fois de savoir développer en HTML + CSS et de connaître les composants JSF. Sur ce point JSF peut souffrir à la fois de la concurrence de frameworks comme Wicket ou JavaScript classiques, qui sont non intrusifs dans le HTML et peuvent être mieux adaptés pour un bon développeur web, et de celle de GWT, qui permet de ne développer qu’en Java et être mieux adapté pour un développeur Java (cf. « faut-il-maitriser-son-code-html »).

L’amélioration de la productivité du développement, grâce à l’utilisation de composants et aux outils, notamment le support par les IDE, sera la clef pour la réussite de JSF, si les fondamentaux du framework ne changent pas.

P.S: on remarquera l’absence des tests dans cet article. L’absence de nouveautés dans JSF 2 concernant ce point ne signifie pas pour autant qu’il est impossible de tester. Cela pourra faire l’objet d’un autre article.

Pour aller plus loin

Commencer à utiliser JSF

L’API et l’implémentation de référence de JSF 2 sont déjà disponibles ici : http://download.java.net/maven/2/com/sun/faces/ et presque finalisées. Bien que JSF 2 ne fera partie que de la version 6 de JEE, il tourne sur la plupart des serveurs JEE 5 du marché (Tomcat, JBoss, Glassfish…). Pensez- simplement à mettre à jour les librairies JSF fournies par le serveur sur JBoss et Glassfish…

JSF 2 au Paris JUG

Mon collègue Damien Gouyette et moi-même présenterons une session du Paris Java User Group consacrée à JSF 2 le 15 octobre prochain.

Pensez à réserver vos places!

Liens externes

• Le site officiel de la spécification : http://jcp.org/en/jsr/detail?id=314
• Un article très complet sur JSF 2 : http://andyschwartz.wordpress.com/2009/07/31/whats-new-in-jsf-2/
• Un tutorial de David Geary utilisant les principales nouveautés : http://www.ibm.com/developerworks/web/library/j-jsf2fu1/

Suggestion d'articles :

1. Les nouveautés du langage dans Java 7

Le temps de chargement d’une application informatique est un point essentiel en terme d’usabilité. Il a un impact important sur l’expérience utilisateur, tellement important qu’il peut être le facteur décisif d’adhésion ou de rejet de l’application par les utilisateurs qui se font un avis en 2-3 secondes. On a tous des exemples douloureux en tête… ou pas d’ailleurs… et c’est bien ça le drame : ces applications passent aux oubliettes!

Les site web sont évidemment très concernés par cette problématique, la concurrence est rude sur la toile… et les plus performants marquent des points face à leurs concurrents, des points qui valent très cher! Les grands du web (Google, Yahoo, etc.) l’ont bien compris et en ont fait leur priorité n°1.

Le problème : le temps de chargement d’une page web dépend de la richesse du contenu et des fonctionnalités qu’elle offre… autant de choses qui sont de plus en plus attendues par les utilisateurs.

Pour résumer, quand on construit une application internet riche (RIA), on est de plus en plus confronté à la question suivante :

Comment concilier performance et richesse fonctionnelle ?

Le temps de chargement d’une RIA est la somme de deux phases :

• le téléchargement des composants web : la page hôte, l’application (JS, SWF ou autre) et autres fichiers CSS, images, vidéos, etc.
• l’initialisation/instanciation de la vue dans le browser

Si on compare ces deux phases entre une application web classique (j’utilise ce terme pour désigner les applications web dont le contenu HTML est généré côté serveur) et une application RIA (utilisant les nouveaux paradigmes consistant à générer les vues côté client), on obtient (grosso-modo… c’est l’ordre de grandeur qui nous intéresse ici) les graphiques suivants :

J’ai volontairement séparé le chargement de la vue initiale et les vues suivantes pour faire apparaître les spécificités des RIA en terme de chargement. En effet, le chargement initial d’une RIA est souvent douloureux comparé aux application web classique, par contre le chargement des vues suivantes est globalement plus réactifs pour une RIA.
Cet article est donc découpé en deux, correspondant à ces deux grandes phases de chargement, avec comme objectif de :

• rassembler les bonnes pratiques permettant d’optimiser les temps de téléchargement et de les illustrer au travers d’une application Google Web Toolkit (GWT)
• aborder les différentes approches d’architectures permettant d’optimiser les temps d’initialisation d’une application GWT sur le navigateur

Optimiser le temps de téléchargement des composants web

Respecter les pratiques standards : compresser, mettre en cache, déclarer proprement

Les « bibles » des bonnes pratiques de développement web de Google et Yahoo sont disponibles en ligne :

• Google : Web Performance Best Practices
• Yahoo : Best Practices for Speeding Up Your Web Site

Les règles les plus classiques liées à l’optimisation du téléchargement des composants web sont essentiellement :

• optimiser la taille des composants téléchargés : compression des fichiers multimédia (images, vidéos), optimisation des fichiers css (ne laisser que les styles qui surchargent les styles par défaut ou les styles hérités), compression des composants (exemple : mod_gzip sur Apache HTTP Server)
• paramétrer la bonne politique de cache : mettre en cache browser l’application afin d’éviter de retélécharger l’application à chaque visite (attention toutefois à ne pas garder en cache le fichier « *nocache.js » généré par GWT)
• déclarer les CSS dans la section HEAD du fichier HTML et déclarer les fichiers Javascript en bas de page HTML

Une fois que tout ça est respecté, reste à optimiser l’application elle-même…

Optimiser la taille d’une application GWT (i.e. des fichiers Javascript générés)

La taille d’une application GWT est dépendante de la quantité de code « Java client » produit et du nombre de composants utilisés (DatePicker, Panels, etc.). Même si GWT optimise le code Javascript généré (suppression du code mort, génération d’un fichier Javascript par type et version de navigateur et par langue pour éviter un gros fichier Javacript prenant en compte toutes les spécificités de chaque navigateur et langue, etc.), un premier niveau d’optimisation sera de :

• factoriser au maximum le code « Java client » à l’aide de widgets réutilisables, idéalement en héritant de la classe Composite, les bonnes pratiques sont disponibles sur le blog officiel GWT
• obfuscer le code de l’application en définissant l’argument de la commande de compilation GWT « -style OBF » (activé par défaut). L’intérêt est de réduire au maximum la taille du fichier Javascript généré en utilisant des noms de classes/méthodes/variables les plus courts possibles.
• éviter dès que possible l’utilisation de bibliothèque de composant tierces type Wrapper Javascript (ex : GWT-Ext, Tatami, etc.) qui nécessiteront le téléchargement de nouveaux fichiers Javascript, non optimisés par la compilation GWT. Une autre bonne raison de ne pas les utiliser est de ne pas provoquer de fuite mémoire en court-circuitant les mécanismes de GWT qui garantissent la libération des objets non utilisés. De manière générale, j’ai tendance à préférer implémenter moi-même mes widgets plutôt que d’utiliser les librairies tierces dont on peut avoir quelques doutes sur la stabilité et la pérennité. Un autre intérêt est de garder la maîtrise du comportement des composants qui doivent souvent être customisés pour répondre aux besoins métier.

A ce titre, GWT 2.0 viendra avec son lot de nouveautés et notamment la possibilité de générer des rapports Story Of Your Compile (SOYC) permettant de mieux cibler les portions de code à optimiser. Ca fera l’objet d’un autre article en préparation…

Diminuer le nombre de composants à télécharger

Pour palier à la contrainte HTTP1.1 des 2 connexions HTTP simultanées sur le même domaine, il est indispensable de diminuer au maximum le nombre de composants qui seront téléchargés :

• regrouper dès que possible les styles dans un seul fichier CSS générique
• ajouter au maximim 1 fichier CSS spécifique à la vue pour éviter un trop gros fichier CSS générique
• pour les mêmes raisons que précédement, utiliser des librairies tierces necessitera de télécharger des ressources (CSS, images, etc.) trés riches, donc lourds, et pas toujours découpés par composants graphiques. De plus ces ressources ne seront pas mis dans un fichier Sprites (mécanisme décrit ci-dessous)
• utiliser la technique CSS Sprites permettant de télécharger plusieurs icônes en une seule requête. Le fonctionnement est auto-magique, les icônes sont fusionnés dans un seul fichier image, puis positionné sur le navigateur de sorte à ne faire apparaître que l’icône concernée. L’utilisation de cette technique en GWT est « transparente » à travers ImageBundle. Pour donner un exemple concret :

1
2
3
4
5
6
7

public interface Icons extends ImageBundle {
    public static final Icons INSTANCE =  GWT.create(Icons.class);
    @Resource("com/octo/sample/public/images/logo.gif")
    public AbstractImagePrototype getLogo();
    @Resource("com/octo/sample/public/images/info.png")
    public AbstractImagePrototype getInfo();
}

Dans l’exemple ci-dessus, les deux icônes logo et info sont automatiquement fusionnés à la compilation GWT dans le même fichier image. Il suffit d’ajouter ces images dans l’interface graphique de la manière suivante par exemple :

1

panel.add(Icons.INSTANCE.getInfo())

GWT va générer le code permettant de positionner l’image en CSS de sorte à faire apparaître uniquement l’icône info.

En GWT 2.0, le concept de ImageBundle va être étendu aux autres ressources envoyées côté client (CSS, XML, properties, etc.) via le ClientBundle. Les fichiers ressources seront donc fusionnés au moment de la compilation, voire intégrées au fichier Javascript et mis en cache côté client (il y a d’autres intérêts mais qui concernent moins le sujet de cet article).

Modulariser l’application

Une autre grosse nouveauté GWT 2.0, appelée CodeSplitting, permettra de découper l’application en plusieurs modules, c’est à dire plusieurs fichiers Javascript. Cela permettra d’éviter un seul gros fichier Javascript, long à télécharger au démarrage de  l’application sur le client.

L’objectif de cette fonctionnalité est donc clairement de diminuer le temps de téléchargement au chargement de l’application sur le client et tendre vers les proportions suivantes :

L’utilisation de cette fonctionnalité est très simple, il suffit d’utiliser l’API GWT.runAsync comme suit :

1
2
3
4
5
6
7

GWT.runAsync(new RunAsyncCallback() {
    public void onFailure(Throwable reason) {
    }
    public void onSuccess() {
        SearchView searchView = new SearchView ();
    }
});

Dans l’exemple ci-dessus, la déclaration et l’instanciation d’un composant (ici une vue de type SearchView) sont encapsulées dans la méthode onSuccess d’une classe anonyme de type RunAsyncCallback, en paramètre de la méthode static runAsync de la classe GWT. Dans cet exemple, le code Javascript correspondant à la classe SearchView, et tous les composants qu’il utilise de manière exclusive (à l’exception des composants issus de librairies tierces type Wrapper JS) sera stocké dans un fichier Javascript séparé du fichier Javascript général. Ce fichier sera automatiquement téléchargé sur le client à l’exécution, l’idéal étant de déclarer ce code sur traitement d’un évènement non déclenché à l’initialisation de la RIA (lors du traitement de l’évènement clic sur le menu « Search » pour reprendre l’exemple).

Pour être plus précis, GWT détecte à la compilation que le composant SearchView est candidat à un SplitPoint puisqu’il n’est utilisé qu’à travers un seul runAsync. Par contre, les composants utilisés dans plusieurs SplitPoints sont stockés dans un autre fichier Javascript partagé mais différent du fichier Javascript du chargement initial, en gros ça donne le découpage suivant :

• 1 fichier Javascript pour le code de la vue initial
• n fichiers Javascript correspondants aux SplitPoints
• 1 fichier Javascript contenant le code qui n’est ni spécifique au chargement initial, ni spécifique à un unique SplitPoint

Vous l’aurez compris, ce mécanisme n’est pas forcément simple à utiliser et j’imagine que vous vous posez déjà quelques questions comme :

• comment découper au mieux mon application ? Je tenterai d’apporter une réponse dans l’article suivant.
• comment savoir quel code se retrouve dans quel fichier Javascript ? J’ai un article en préparation sur l’outil SOYC qui semble répondre au besoin.

On a donc vu dans cet article comment optimiser les temps de téléchargement d’une application GWT et des composants web sur le client, l’article suivant concernera l’optimisation du temps d’initialisation d’une application GWT sur le browser… stay tuned! ;)

Suggestion d'articles :

1. Optimiser le temps de chargement d’une application GWT (2/2)
2. Quand Spring s’invite dans une application Flex …
3. Optimiser les performances de vos applications web sur mobile

De base le toolkit GWT vient avec son framework d’échange : GWT-RPC. Aucun problème particulier dans son fonctionnement mais quelques limitations à la fois dans la configuration que l’on pourra qualifier d’un « peu lourde », ainsi que dans l’intégration avec un existant (typiquement un existant Spring).

Le framework gwtrpc-spring répond à ces limitations, il faut bien l’avouer, de façon trés élégante.

Configuration de la partie Serveur : une simple exposition de beans Spring
Exposer un service GWT-RPC nécessite deux choses :

• L’implémentation du service doit hériter de RemoteServiceServlet
• La servlet associée à chaque service doit être configurée dans le web.xml

Peu de choses a priori mais autant de défauts potentiels qui ne seront détectés qu’au déploiement et qui, au final, freinent la productivité.

gwtrpc-spring propose un fonctionnement un peu plus générique (une documentation plus complète est disponible sur le site) :

• une servlet de type « Dispatcher » unique à configurer dans le fichier web.xml.

  1 2 3 4 5

  ... <servlet -mapping> </servlet><servlet -name>dispatcher</servlet> <url -pattern>*.rpc</url> ...

• tout bean Spring peut être alors exposé via l’annotation @Service. Vous noterez que l’implémentation du service n’hérite pas de RemoteServiceServlet. Il est possible d’avoir les mêmes API via la classe statique RemoteServiceUtil.

  1 2	@Service public class GreetingServiceImpl implements GreetingService {

• la configuration Spring associée peut être générique

  1 2 3 4

  ... <context :annotation-config /> <context :component-scan base-package="org.octo.myapp.server" /> ...

Ainsi configurés, toutes les appels sur des urls se terminant par *.rpc seront « dispatchés » vers le « bon » bean Spring ie. l’implémentation du contrat de service.

Configuration de la partie Cliente : du GWT, simplement
L’élégance de ce framework tient en partie dans son intégration transparente dans la partie cliente. En effet:

• l’interface de service utilise toujours et uniquement les annotations GWT.

  1 2	@RemoteServiceRelativePath("greet.rpc") public interface GreetingService extends RemoteService {

• la création du service via l’API GWT.create() est identique

  1	greetingService = GWT.create(GreetingService.class);

En bref, un framework simple et élégant…

Suggestion d'articles :

1. Quand Spring s’invite dans une application Flex …
2. Comparaison Google Guice et Spring
3. Soirée Spring au Paris JUG