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

Vaadin 6

Au revoir IT Mill Toolkit et bienvenue à Vaadin (vu sur leur blog) !

Pour ceux qui ne le connaissent pas encore, Vaadin (anciennement IT Mill Toolkit) est un framework de développement d’applications RIA qui s’appuie sur GWT. Sa particularité est d’être runtime donc aucune compilation spécifique n’est demandée avant de packager la webapp (à l’inverse de GWT).

Simple changement de nom ? En tout cas très peu de changement côté API selon les auteurs du framework. Il faut plutôt se tourner vers l’outillage pour voir quelques nouveautés : un plugin eclipse (création de projets, de composants UI, de thèmes…) et, inclus dans le plugin, un éditeur WYSIWYG.

Côté liens utiles, l’habituel showcase, le livre et la comparaison maison avec les autres frameworks du marché (et la concurrence est rude dans le monde du RIA).

A noter que Vaadin sera présent à Jazoon pour une conférence sur RIA Security le mardi 23 juin à 15h (slides, projet et autres sur cette page).

Adaptateur Gilead pour GAE

Vous connaissez GWT, Gilead, et Google App Engine ? Et bien il ne reste plus qu’à mélanger tout ça et on obtient le Gilead GWT adapter for Google AppEngine (vu sur le GWT Blog).

Tout démarre d’un thread google groups avec comme point de départ la serialization exception lancée par les entités persistantes transférées vers GWT. Évidemment, la solution qui ressort très rapidement, outre l’utilisation de DTOs, est de passer par Gilead pour transformer nos entités persistantes en POJOs. Il suffit d’ajouter le jar adapter4appengine et de remplacer la classe PersistentRemoteService par EngineRemoteService dans vos remotes services. Dès lors, il sera possible d’envoyer ses entités persistantes vers le client GWT sans exceptions de sérialisation sur GAE.

1.0 M2 téléchargeable à cette url, documentation par ici. Attention toutefois, cette version n’est pas production ready.

Une série d’annonces chez Adobe

Après l’annonce de la sortie de la plateforme Flash il y a quelques semaines, voici une nouvelle série d’annonce de la part d’Adobe.

Pour commencer, deux news relayées par Andrew Twice dans InsideRIA.
La première concerne la sortie d’Adobe Table en version bêta. Cet outil permet de créer des feuilles de calcul, des plannings ou encore des listes de tâches en ligne:

  • Les utilisateurs peuvent ajouter des données en même temps: les données sont mises à jour en temps réel pour tout le monde.
  • Possibilité de savoir qui travaille sur Adobe Table.
  • Création d’écrans communs et privés : les utilisateurs peuvent travailler de manière coopérative, et/ou créer des espaces privés pour ne garder que les informations importantes.
  • Filtrage : les utilisateurs peuvent filtrer leurs données en temps réel.
  • Tri.

Similaire à Google Document, cet outil a été développé sur la plateforme Flash et va continuer à évoluer. La démo se passe ici, la seule contrainte : avoir un compte Adobe.

La deuxième annonce concerne l’ouverture de la spécification de Real-Time Messaging Protocol (RTMP). Comme nous en avions parlé ici, la spécification a été publiée lundi dernier.

Enfin, Michael Chaize parle de la sortie de LiveCycle Data Services 3 en bêta. Disponible sur le labs d’Abobe, cette nouvelle version propose une meilleure qualité de service pour des applications dont la fiabilité est primordiale telles que les applications bancaires par exemple. Venant compléter la plateforme Flash (avec Flex 4 et Flash Builder 4), Adobe incite la communauté à faire ses retours sur le forum.

Le coin de la technique

Scalabilité avec Hibernate et Shards

Une session de QCon 2008, traitant de la scalabilité d’Hibernate, vient d’être mise en ligne. Présentée par Emmanuel Bernard, project lead d’Hibernate Search, et Max Ross, project lead d’Hibernate Shards, cette présentation offre une approche peu courante sur un problème pourtant récurrent.

Outre les classiques solutions permettant d’éviter certaines pertes de performance avec l’augmentation du volume traité, telles que la bonne gestion du cache, et les optimisations SQL, il a été question d’utiliser Hibernate Search et Hibernate Shards.

Hibernate Search est connu pour sa capacité à simplifier les recherches dans un ensemble d’entités grâce à l’utilisation de Lucene conjointement à la base de données. Emmanuel Bernard proposait ici de déléguer à Search certaines recherches qui s’avèrent très coûteuses à effectuer en base. Lucene étant placé sur une machine séparée, et pouvant même fonctionner en maître / esclave, il est ainsi possible d’obtenir une intéressante répartition de la charge.

Hibernate Shards, bien que plus ancien, est moins répandu du fait qu’aucune version finale n’a encore été produite. Il s’agit d’un module additionnel pour Hibernate permettant à une application de manipuler des données partitionnées sur plusieurs BDD. Le but étant d’encapsuler la conscience du partitionnement des données au sein de la couche Hibernate afin que l’application n’ait pas à gérer cette problématique. Les possibilités du framework sont intéressantes :

  • La gestion correcte des Criterias sur des données partitionnées grâce à ShardedCriteria.
  • Virtual Shards permettant de faire la distinction entre shard logique et shard physique et ainsi d’augmenter le nombre d’instances de base de données au fur et à mesure de l’augmentation des besoins.
  • Generation d’IDs compatibles avec l’utilisation sous-jacente de plusieurs BDDs grâce à l’utilisation d’UUIDs.
  • Gestion correcte de BDDs hétérogènes.

Ce sont finalement les fonctionnalités manquantes qui permettent de comprendre pourquoi Shards est toujours en version bêta. Max Ross s’est expliqué il y a plusieurs mois sur les problématiques rencontrées, de manière succincte sur un forum et plus longuement dans une interview. De nombreux défis restent ainsi à relever concernant la gestion correcte des agrégations dans les ShardedQuery et la fourniture d’outils d’aide au partitionnement et repartitionnement des données.
Max Ross est employé par Google et non par JBoss, tout comme les deux autres committers du projet (le code ayant été donné à JBoss par Google), et affirme ne disposer que de 20 % de son temps pour Shards. Ceci n’explique que partiellement le peu de commits sur le projet et ne nous rassure guère quant à sa finalisation prochaine.

Jigsaw vs OSGi

Sept mois après le démarrage du projet Jigsaw, sa légitimité n’est toujours pas reconnue face à OSGi qu’il est venu défier sur son propre terrain.

La semaine dernière JavaPosse diffusait une interview de Mark Reinhold et Alex Buckley, où ils ont pu présenter plus en détail leur vision de Jigsaw :

  • Il a été conçu pour modulariser le JDK et est intégré au langage.
  • Il ne repose pas sur une spécification car cela n’était pas possible compte tenu du calendrier de JDK 7. Il est donc à considérer comme un « détail d’implémentation » tout comme la gestion du classpath l’était dans les JVMs précédentes.
  • Il n’est pas supposé entrer en concurrence avec OSGi, des outils permettant l’intégration entre modules Jigsaw et bundles OSGi étant prévus, mais non prioritaires.

Dans le même temps, Eric Newcomer (Co-Chair, Enterprise Expert Group de l’OSGi Alliance), postait une série de billets très virulents à l’égard du projet Jigsaw, reprochant principalement que Sun n’ait pas voulu se tourner vers OSGi, ne cherchant pas à combler les manques qu’il y trouvait, se tournant immédiatement vers une nouvelle technologie et ignorant donc les 10 années d’expérience acquises par OSGi.

En fait, il semble n’y avoir aucune justification technique permettant d’expliquer l’orientation de Sun vers Jigsaw plutôt que vers OSGi ou vers une évolution d’OSGi intégrée au langage. La véritable raison serait alors à chercher sur le plan politique : la modularisation est un concept important qui manque à Java actuellement et Sun ne pouvait probablement pas se permettre, pour l’ajout d’un tel concept, de s’appuyer sur une spécification émise en dehors du JCP sur lequel il a la gouvernance.

Pourquoi utiliser un portail ?

Le dernier podcast des Cast Codeurs était l’occasion d’une interview de Thomas Heute et Julien Viet sur les portails d’entreprise et sur le partenariat entre eXo et JBoss dont nous vous parlions la semaine dernière.

Les détails liés au partenariat ont déjà été largement couverts par la blogosphère, et c’est surtout le tour d’horizon du concept même de portail que l’on retiendra. Celui-ci reste en effet souvent un élément ambigu au sein de l’écosystème JEE.

Le rôle du portail est d’agréger plusieurs applications au sein d’une unique application Web. Ce besoin technique peut être atteint à plusieurs niveaux de l’architecture de l’application :

  • Au niveau back-end, par agrégation de Web Service, se conformant ainsi à l’un des préceptes des SOAs.
  • Au niveau applicatif, par l’utilisation d’un portail, ou d’une solution spécifique.
  • Au niveau du navigateur Web, par l’utilisation de gadgets, en suivant le principe des Mashups.

En outre, il a également été question des problématiques d’intégration des frameworks Web aux portlets, de complexité éventuelle, et d’adaptation des technologies Web aux portlets. Déterminer si un portail doit être utilisé dans une architecture dépend alors du niveau de tolérance à ces problématiques.

Embarquer le Web dans Java avec JWebPane

Depuis plusieurs années, lorsque l’on veut afficher une page Web au sein d’une application Swing, il faut se tourner vers le composant Browser de la librairie Jdic. Ce composant utilise Embeddable Mozilla, et se présente sous la forme de code natif décliné pour chaque OS et d’un wrapper Java. Outre la nécessité de fournir une version spécifique à chaque OS, ce composant présente également l’inconvénient de mal s’intégrer aux applications Swing du fait de sa nature heavyweight. Pour rappel, un composant est dit heavyweight lorsqu’il est dessiné par l’environnement graphique du système d’exploitation ; à l’opposé il devient lightweight s’il est dessiné par l’application, ce qui est le cas de l’ensemble des composants Swing. Or, faire cohabiter les deux types de composants est délicat car n’étant pas dessinés au même moment, leur superposition est confuse et des chevauchements non contrôlables apparaissent.

Lors de JavaOne, Alexey Ushakov a fait la démonstration du composant JWebPane sur lequel il travaille actuellement et vient de poster des captures d’écrans. Contrairement à Jdic Browser, JWebPane se base sur le moteur WebKit pour effectuer le rendu HTML. Or celui-ci se caractérise par sa nature lightweight s’intégrant agréablement à Swing. La présentation d’Alex Ushakov permet également de constater que son composant est particulièrement riche en possibilité d’interactions et apporte un support pour d’éventuels plugins tels que Flash.

On ne peut qu’apprécier le choix de Sun de créer un composant pour Swing, réutilisable dans JavaFX, plutôt que de privilégier uniquement JavaFX comme cela est souvent le cas depuis son arrivée. L’intégration de JWebPane au JDK 7 est maintenant indispensable pour rendre ce composant réellement exploitable : se basant sur WebKit, il repose donc sur des librairies natives qu’il sera nécessaire de livrer avec les applications Java et seul l’intégration au JDK permettrait de l’éviter. Or, malgré les appels de la communauté, JWebPane reste pour le moment absent de la liste des features du JDK 7 et il est uniquement question d’une mise à disposition sur Java.net.

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

1 réponses pour " Revue de Presse Xebia "

  1. Publié par , Il y a 10 ans

    SUN a loupé une énorme opportunité en trainant des pieds à livrer JWebPane (pas de béta, pas de RC) et/ou en ne mettant pas suffisamment de ressources pour développer JWebPane rapidement. Sauf erreur de ma part, JWebPane était déjà présenté à JavaOne’08. Et cette année encore, une session lui était consacrée.

    JWebPane présente un énorme potentiel et aurait pu, livré bcq plus tôt, largement revivifier Java coté client. Mais non, pour des raisons très dommageables, sans doute à cause d’une mauvaise appréciation des priorités, SUN a trainé la patte à livrer JWebPane qui est seulement annoncé pour fin 2009 (encore 6 mois à attendre…). Soit près de 1,5 an, voire même 2 ans entre l’annonce, le début des dev et la livraison, une éternité.

    SUN a failli à délivrer ses promesses. Et là, cela lui a été dommageable ici.

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.