Publié par

Il y a 10 années -

Temps de lecture 7 minutes

Revue de Presse Xebia

Revue de Presse Xebia
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

RIA

Le coin de la technique

Evènements de notre communauté en France et à l’étranger

RIA

Ajax, le RIA du futur ?

Le SD Times Blog revient sur 2 expériences réussies de développement d’applications riches en Ajax.
Pour le développement d’un portail destiné aux soldats américains, la firme Roundarch a choisit Ajax. Dave Meeker, leader de la stratégie ‘orientée utilisateur’, revient sur les raisons de ce choix.
La première raison de ce choix est la valorisation des compétences CSS, HTML et Javascript des équipes de développements. La plupart des développeurs trouvent Ajax facile d’utilisation, lorsqu’il s’agit de développer des applications HTML dynamiques simples.
Un autre argument en faveur de ce choix est qu’au contraire de RIA tels Flex ou Silverlight, Ajax ne demande pas de téléchargement complémentaire, ce qui est un argument de poids quand le déploiement du portail se veut mondial, en particulier dans des pays où le débit et/ou le matériel peuvent poser problème (Afrique, Asie, …).
Autre entreprise, même son de cloche : Peter Mezzina, leader technique de Powerlink, explique le choix de partir sur Ajax, plutôt que sur un des 12 autres produits benchmarqués par son entreprise. Là aussi, la montée en compétence de ses équipes, facilitée par le choix du framework Dojo Toolkit (un wrapper Java pour Ajax), a été un élément de choix déterminant. Les équipes ont l’habitude de travailler dans un environnement Java, et grâce au wrapper, restent dans leur ‘zone de confort’ (gain de temps et de productivité).
De plus, selon Mezzina, Ajax est plus stable que les autres RIA testés. Cette stabilité se manifeste plus par un comportement ‘prédictible’ obtenu par les clients (ou au moins ‘débuggable’), que par une diminution sensible des crashs serveur par exemple.

Cependant, Dave Meeker estime que Flex possède de sérieux atouts dans le développement d’applications RIA complexes, en particulier grâce à la volonté de Adobe de rendre son moteur performant même sur des patterns complexes (Meeker cite le « célèbre » exemple du DataGrid, si facile à mettre en place), et/ou sur des volumes de données à manipuler importants (tentez de manipuler 5000 lignes en Javascript sous IE, vous comprendrez).
De plus, alors qu’Ajax est présent sur le marché depuis plus longtemps que les produits de Adobe et Microsoft, aucune implémentation ne sort clairement du lot. Il est donc difficile de ‘vendre’ Ajax à une DSI, ne sachant pas si la librairie choisie (Meeker prend l’exemple de script.aculo.us) passera l’hiver.

Peut-être qu’un cap sera franchit grâce à l’utilisation de Google Chrome, qui permet, même si le moteur Javascript crashe, de ne fermer que l’application incriminée. De plus, l’attention que Google a portée sur la stabilité et la performance du moteur Javascript, si elle est suivie d’effet chez les navigateurs concurrents, peut se révéler un avantage décisif pour ce langage.

Alors, Ajax va t’il gagner la bataille des RIA ? Comme d’habitude, une seule réponse valable : ça dépend

JavaFx cherche le soutient de la communauté Java

Jeet Kaul, vice président du groupe ‘Applications clients’ chez Sun, annonce sur son blog le passage prochain de JavaFx en full open source. Sun travaille actuellement à casser les dépendances entre Fx et certaines portions de code propriétaires.
Les spécifications pour FXD, FXZ, FXM et JavaFX Script devraient être publiées prochainement.
Dans la série des annonces, Kaul confirme l’arrivée de la version mobile pour mars 2009, et l’arrivée d’un outil de design pour mi 2009. Les bugs seront eux fixés au fil de l’eau. A ce sujet, le Jira de FX est maintenant accessible au grand public.
Sun cherche donc à s’appuyer sur un large nombre de développeurs pour combler son retard sur ses concurrents. Ce passage à l’open source est une très bonne nouvelle, et devrait permettre l’émergence rapide de composants de haut niveau sous licence GPL.

Le coin de la technique

Comment plomber une application grâce à de mauvaises pratiques base de données

Une piqûre de rappel ne faisant jamais de mal, Alois Reitbauer revient pour InfoQ, sur quelques mauvaises pratiques dans les interactions applications / bases de données relationnelles.
Profitons donc de la nouvelle année pour rappeler ces mauvaises pratiques à éviter :

  • Mauvais usage des outils de mapping Objet / Relationnel : même si ces frameworks sont là pour rendre l’accès à la couche de persistance le plus transparent possible, il est bon de connaitre leurs grands mécanismes, pour optimiser la stratégie d’accès aux données (itérations, lazy-loading…)
  • Chargement excessif de données : la couche DAO doit évoluer avec l’application, et chaque changement de la base doit être l’occasion de se repencher sur celle-ci (dans le cas de l’ajout d’une colonne par exemple). Mais si les interfaces de service nous poussent à tendre vers un maximum de généricité, il est impératif de garder à l’esprit les impacts éventuels de chaque modification de base sur l’ensemble des use cases, quitte à devoir réécrire un service spécifique pour un use case donné.
  • Gestion des accès à la base : souvent, pour des questions de facilité de développement (lazy loading encore…), les connexions à la DB sont ‘tenues’ plus longtemps qu’il ne le faudrait. Il est donc impératif de libérer les accès à la base dès que possible (le lazy loading ne devant pas être un frein à cette libération).
  • Traiter indifféremment toutes ses données : il est impératif de mettre en place des traitements spécifiques pour des types de données à catégoriser (fréquence de changement, fréquence d’accès, use case d’accès). La catégorisation des données (et des requêtes) permet d’adapter les outils techniques (cache, pool de connexion différenciés…) pour optimiser les échanges.
  • Pas ou de mauvais tests : les tests unitaires de la couche DAO doivent se faire sur des données réelles et dans des conditions réelles d’utilisation (accès concurrents en lecture, lecture / écriture, pics d’accès). Ces tests de charge avant l’heure permettent d’identifier très tôt d’éventuelles erreurs de conception.

Peut-être avez-vous l’impression que nous enfonçons des portes ouvertes en reprenant ici cette interview, mais nous croisons encore ces mauvaises pratiques sur de trop nombreux projets…

Evènements de notre communauté en France et à l’étranger

InfoQ fait une rétrospective du contenu le plus lu en 2008

La semaine dernière nous avons eu l’occasion de présenter la rétrospective des articles de JavaLobby : JavaLobby fait une rétrospective des articles les plus lus en 2008.
Dans le même style, InfoQ nous propose une rétrospective par thèmes : .Net, Agile, Architecture, Java, Ruby, SOA dans Top InfoQ News and Exclusive Content for 2008.

Ainsi au vu des articles les plus consultés dans la communauté Java, les deux acteurs innovateurs ont été :

  • Adobe avec Flex
  • SpringSource, avec la nouvelle version de Spring (2.5 et la préparation de la version 3) mais aussi avec son SpringSource dm Server et son SpringSource tc Server.

On peut quand même s’étonner de ne voir aucun article à propos des nouvelles versions du JDK 7 et du JEE 6, en cours d’élaboration.

Cette année 2008 a été aussi marqué par l’évangélisation de l’architecture REST. De nombreuses questions et réponses ont été apportées sur ce sujet. De nombreux travaux sont en cours de réalisation dans ce domaine :

Donc si vous avez raté un article important en 2008 sur InfoQ c’est le dernier moment pour vous rattraper !

Les vidéos et les présentations des « rencontres Spring » disponibles en ligne

SpringSource référence sur son blog l’ensemble des vidéos et des présentations des rencontres Spring qui se sont tenues à Paris le 13 novembre 2008.
On notera en particulier la vidéo de Mark Thomas concernant l’amélioration des performances de Tomcat (dont nous nous étions déjà fait l’echo).

Publié par

Publié par Xebia France

Xebia est un cabinet de conseil international spécialisé dans les technologies Big Data, Web, les architectures Java et la mobilité dans des environnements agiles. Depuis plus de 15 ans, nous avons la volonté de partager notre expertise et nos actualités à travers notre blog technique.

Commentaire

8 réponses pour " Revue de Presse Xebia "

  1. Publié par , Il y a 10 années

    Bonjour,

    J’aurais une observation à faire au sujet de Dojo Toolkit, à mon avis improprement qualifié de wrapper Java pour Ajax. Dojo est en effet un toolkit Javascript, par nature totalement agnostique par rapport à la technologie serveur. Le framework DWR [http://directwebremoting.org/] mériterait plus ce qualificatif.
    Encore merci pour vos revues de presse technique dont la lecture est toujours aussi enrichissante.

  2. Publié par , Il y a 10 années

    « Pas ou de mauvais tests : les tests unitaires de la couche DAO doivent se faire sur des données réelles et dans des conditions réelles d’utilisation (accès concurrents en lecture, lecture / écriture, pics d’accès). Ces tests de charge avant l’heure permettent d’identifier très tôt d’éventuelles erreurs de conception. »

    Je vois pas comment on peut tester la couche en condition réelle quand la plateforme de dev (integration) n’est pas identique à la plateforme de prod (par les même performance de serveur, etc…)

    Qu’est ce que ca apporte de tester la couche DAO ?

  3. Publié par , Il y a 10 années

    Bonjour,

    > Kad
    Merci pour vos remarques pertinentes et vos encouragements.

    > Sylvain
    On ne parle pas ici de tester les performances de l’accès à la base en tant que telles, mais plutôt de mettre au point des tests ‘en conditions réelles’, en particulier dans la façon dont on accède aux données, pour détecter d’éventuels problèmes ‘structurels’ (locking, accès excessif au cache, concurrence d’accès élevée).
    Ces tests seront certes réalisés lors de la phase de tests de performance, mais d’expérience, nous savons que ces tests arrivent souvent tardivement (quand la plate forme physique de production sera arrivée ;o) et que les couts de refactoring de la couche DAO risquent alors d’être insurmontables.
    On se situe donc à la limite entre le test unitaire et le test d’intégration.

    Pablo (Xebia)

  4. Publié par , Il y a 10 années

    Merci pour ces articles très intéressants.
    Je voulais juste signaler qu’il y a une petite coquille avec le lien: « Top InfoQ News and Exclusive Content for 2008. » qui ne fonctionne pas.
    En effet, le caractère | à la fin du lien est en trop.

  5. Publié par , Il y a 10 années

    C’est corrigé, merci Romain.

  6. Publié par , Il y a 10 années

    Bonjour Pablo,

    Je suis désolé mais je suis pas du tout convaincu qu’il vaille se préoccuper à ce type de problème lors de la création de la couche dao.
    La couche dao est là pour fournir une implémentation simple de requêtes de bas niveau.

    Il convient de se préoccuper des performances (problèmes de concurrence) à la fin de la partie de développement, on parle alors de bench. La plateforme de bench correspond à la plateforme de prod (« condition réelle »), on peut alors faire des tests en ajoutant des améliorations (placer des index, ajouter du cache, etc…). On peut également faire des simulations avec des outils adéquats.
    J’ai du mal à concevoir de lancer des tests sur une machine de dev ou d’intégration durant le développement sachant qu’un pc n’est pas un serveur, que passer du temps à se mettre dans les conditions réelles est couteux de plus si on effectue régulièrement des modifications d’architecture (fréquent dans le cadre du développement agile) on va passer trop de temps en refactoring de tests.

    Je préconise de travailler sur les tests unitaires, sur la création d’un produit « sans bugs bloquant » et de travailler sur les performances si ça en vaut vraiment le coup, et ne pas commencer son développement en passant au cache, au lock etc… il faut donc cibler ce qui mérite d’être amélioré ou ce qui peut apporter de gros problèmes de perf.

  7. Publié par , Il y a 10 années

    Bonjour Sylvain.
    Nous sommes sur la même longueur d’onde.
    Il est inutile de tester les performances des DAO durant la phase de développement s’il n’y a évidement aucun risque. En revanche, sur certains points délicats, ces ‘pré’ tests de performance trouvent tout leur intérêt. L’expérience de chacun permettra de déterminer les zones triviales et les zones à risque, pour maximiser la productivité de ces tests et leur apport concret.

    Pablo (Xebia)

  8. Publié par , Il y a 10 années

    D’expérience aussi, quand un problème de performance existe, il n’y a pas besoin d’une machine puissante pour le mettre en évidence :)
    Les problèmes d’accès concurrent peuvent appraitre aussi dès 2 ou trois utilisateurs. Donc faire quelques tests de performance rapide et sans sortir la grosse artillerie peuvent permettre d’identifier au plus tôt un problème.
    La campagne de tests de performance arrivant après le développement est bien sûr toujours indispensable et doit être beaucoup plus pertinente que les quelques tests de perf fait en dev.

    Mes 2 cents
    Manuel

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.