La construction dynamique des pages web par assemblage de composants est devenue un standard de fait dans les applications de commerce électronique. Il suffit de parcourir les sites de grandes compagnies comme Ebay ou BestBuy pour constater que les pages sont de plus en plus façonnées à partir d’une collection de blocs qui puisent leurs données de plusieurs sources locales et/ou distantes statiques et/ou dynamiques (par exemple : un bloc qui récupère dynamiquement les cours des actions via un service web, un autre qui importe des données syndiquées (RSS feeds) à partir d’un fichier xml placé sur un site tiers ou encore un bloc qui contient le logo et les informations de copyright…).

Cette manière de construire les pages web facilite l’administration des sites et la reutilisabilité des blocs mais elle consomme beaucoup de ressources comme le montre le diagramme de séquence suivant.

Figure 32: Génération dynamique des pages web par assemblage de composants (pattern du composite view) (156)



Dans les applications Java les pages sont typiquement composées selon une ou plusieurs des techniques infra :

• Utilisation du mécanisme d’inclusion intégré aux JSP : un peu comme le font les frames d’HTML, cette technique permet d’incorporer à la volée une page à l’intérieur d’une autre. Nous verrons dans la partie 5 que son efficacité est subordonnée au type d’inclusion utilisée (include directive versus include action) et à la nature du contenu inclus (statique ou dynamique). En règle générale il faut éviter de l’utiliser lorsque le contenu incorporé ne peut pas être mis en cache.

• Utilisation des Java Bean : les Java Beans sont des composants sérialisables qui font massivement appel aux unités d’entrée/sortie (I/O) pour assurer la persistance de leurs propriétés. Vu que ces appels sont coûteux en mémoire, en processeur et en temps de réponse, il faut réduire leur utilisation au strict minimum. Il faut aussi raccourcir leur durée de vie et réduire leur portée (scope) pour éviter une occupation inutile de la mémoire lorsque la vue n’en a plus besoin. Enfin il faut essayer dans toute la mesure du possible de stocker les propriétés des Java Bean dans des bases de données parce qu’elles gèrent les mises à jour multiples (update) plus efficacement que le système de fichiers (unités d’entrées sorties I/O).

• Utilisation des librairies de tags personnalisés (custom tags) : lorsque le conteneur trouve un tag personnalisé dans le code d’une JSP, il procède au parsing du Tag Library Descriptor (fichier .tld) pour déterminer le chemin d’accès à la classe à laquelle le tag est adossé. Au passage il charge aussi le Tag Handler et appelle des méthodes qui permettent de gérer son cycle de vie. Ces opérations sont pénalisantes aussi bien pour la mémoire que pour le processeur. Si elles sont effectuées à une grande échelle elles peuvent dégrader brutalement la performance de l’application. Comme les Java Bean, il faut limiter l’utilisation des tags personnalisés au strict minimum. Il faut aussi créer un nombre restreint de Tag Handler dans le resource pool pour éviter au conteneur d’instancier le Tag Handler à chaque fois qu’il croise un tag personnalisé dans le code de la JSP.

Cela dit l’utilisation de la mémoire cache du browser pour conserver des données peu ou pas volatiles est souvent d’un grand apport dans l’amélioration des performances des vues composites.

Par exemple, au lieu de télécharger à maintes reprises une applet ou le logo, il est possible de les stocker dans la mémoire cache du browser de façon à soulager le trafic sur le réseau et à réduire le temps de réponse perçu par le client. La principale difficulté avec cette technique a trait à la fréquence de mise à jour du cache. Normalement c’est au serveur d’avertir le client lorsque les données changent mais malheureusement les browsers ne supportent pas ce mode de communication. Le modèle pull du web veut que la communication soit initiée par les browsers. C’est donc à eux d’aller vérifier à la source que les données n’ont pas changé. Cette vérification doit être occasionnelle sinon l’utilisation de cette technique doit être remise en question.

NB : des librairies de tags spécialisés comme OSCache offrent une solution complète et simple pour cacher ou mettre sur disque les différents composants d’une JSP. Ces libraires seront étudiées avec plus de détails dans cet article.

(156) Sun Microsystems, Core J2EE Pattern Catalog, http://java.sun.com/blueprints/corej2eepatterns/Patterns/CompositeView.html