Les nouvelles architectures front Web et leur impact sur la DSI – partie 2

Dans la partie 1 de cet article, nous avons traité des nouvelles architectures front-end basées sur des applications Web massivement Javascript appelant des API offertes par un serveur back-end : les nouvelles architectures front Web et leur impact sur les DSI – Partie 1.

Nous avons vu qu’elles sont apparues ces dernières années grâce à l’augmentation des performances des navigateurs et à l’amélioration des outils d’industrialisation des développements Javascript.

Dans cette seconde partie, nous nous intéresserons aux raisons pour lesquelles on devrait choisir ces nouvelles architectures, aux opportunités qu’elles offrent, et aux conséquences sur les organisations des directions informatiques.

Lire la suite

Les nouvelles architectures front Web et leur impact sur les DSI – Partie 1

Les applications Web évoluent. Depuis les premiers sites en HTML statique jusqu’aux applications AJAX de ces dernières années, en passant par les multiples technologies de sites Web dynamiques (PHP, ASP, Java, Rails…), les architectures applicatives et les outils pour les mettre en place connaissent régulièrement des avancées majeures et des points de ruptures.

Depuis deux ans, nous voyons venir une nouvelle vague technologique qui submerge le paysage des applications Web. Celle-ci n’a pas encore de nom bien défini comme ont pu l’avoir les RIA ou AJAX. Nous les appellerons les « architectures MV* côté client ».

Elles se constituent principalement de ce principe d’architecture : le serveur ne doit plus gérer l’affichage mais seulement envoyer des données brutes à afficher, et toute la génération des écrans et la gestion des interactions avec l’utilisateur doivent être géré côté client, c’est-à-dire dans le navigateur.

Dans ce billet, nous préciserons cette architecture et expliquer les raisons de son émergence. Dans un second billet, nous verrons pourquoi il est pertinent de les mettre en place dès aujourd’hui, les opportunités qu’elles offrent, et quels sont les impacts à prévoir pour les DSI.

Lire la suite

GWT et sécurité, se prémunir des CSRF

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.

Lire la suite

JSR 303 (Bean Validation) : état des lieux

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

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

Lire la suite

Retour du front : dois je migrer vers GWT 2 ?

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.

Lire la suite

HTML5, tueur de Flash ?

Internet n’est plus seulement peuplé de sites d’informations statiques mais de véritables applications dont les fonctionnalités étaient jusqu’à présent seulement disponibles sur nos postes de travail. Aujourd’hui, on trouve des applications Web capables de proposer de la retouche de photos, la visualisation de bande-annonces de film, la gestion et l’écoute de musique, la lecture de livres, etc. Les standards actuels du W3C n’ayant pas été conçus pour la création d’applications Web, des plugins tels que Flash ont comblé ce manque. Le W3C préparait XHTML2 depuis des années mais cette spécification était orientée document et non application. Des employés d’Apple, de Mozilla Foundation et d’Opera Software ont formé la communauté WHATWG. Point de départ d’HTML5, leurs travaux ont été orientés vers un standard capable de créer des applications : ajout de la vidéo, mode hors-ligne, etc. HTML5 est-il une réelle alternative aux plugins comme Flash ? Voire un Flash-killer ?

Lire la suite

Optimiser le temps de chargement d’une application GWT (2/2)

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. Lire la suite

GWT & les tests, épisode 3

A la fin du précédent article, nous en étions restés à une application GWT testée unitairement :

  • tous les comportements des contrôleurs sont testés
  • les points difficiles des vues sont testés

Ces tests sont exécutés avec JUnit ou Maven, comme n’importe quel autre test. Nous sommes donc capables de lancer l’application GWT dans une JVM standard. Rien ne s’affiche, mais toutes les classes sont instanciées, et les comportements sont implémentés. Par contre la partie serveur (qui reçoit les appels GWT-RPC) est mockée.

La faiblesse de ces tests est qu’ils sont unitaires : on teste le comportement d’un écran. Or les problèmes commencent lors que l’on enchaine les écrans…
Lire la suite

GWT & les tests, épisode 2

Dans le précédent article, nous avons démontré qu’il n’était pas si facile de faire des tests avec GWT car :

  • La classe de test de base, GWTTestCase est trop restrictive (impossible d’utiliser des outils de tests), et est source de lenteurs
  • Le mock de composants GWT requiert l’utilisation d’interfaces intermédiaires plutôt que des classes de composants, ce qui induit un gros travail de refactoring sur les projets existants

Nous avons donc mis en place une solution alternative…
Lire la suite