Blog Xebia France

Revue de Presse Xebia

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

Actualité éditeurs / SSII

• Fusion BEA / Oracle : présentation de la stratégie par Oracle

Agilité

• Techniques d'estimation des user stories
• Les déboires de Google avec Scrum

RIA

• Le contenu Flash / Flex indexable

SOA

• REST anti patterns

Le coin de la technique

• Bonne utilisation des generics
• Websphere MQ v7 : un bouleversement discret appelé message properties

Actualité éditeurs / SSII

Fusion BEA / Oracle : présentation de la stratégie par Oracle

Le 1er juillet 2008 a été annoncée la stratégie d'intégration des offres BEA par Oracle. Thomas Kurian, patron du middleware chez Oracle, a notamment annoncé que les produits Weblogic et Tuxedo seront intégrés tel que à l'offre Oracle. Quant aux ESB et aux outils de développement d'Oracle et BEA, ils fusionnent.

Plus de détails sur la nouvelle offre Oracle :

• Détails de cette information par InformationWeek
• Présentation de cette information par InfoQ

Agilité

Techniques d'estimation des user stories

Jay Fields, consultant chez ThoughtWorks, présente différentes astuces pour estimer les user stories. Nous retiendrons :

• Utilisez 4 valeurs, des puissances de 2 : 1, 2, 4, 8. De manière générale, un nombre de choix réduit simplifie le vote et les valeurs qui s'éloignent de plus en plus évitent une fausse précision. La suite de Fibonacci fonctionne très bien aussi.
• Votez indépendamment les uns des autres. Des techniques simples comme le jeu pierre-feuille-ciseaux ou le planning poker permettent de voter simultanément sans être influencé par les autres.
• Les réunions d'estimation sont rarement un plaisir, motivez l'équipe avec des croissants par exemple !

Les déboires de Google avec Scrum

Jeff Sutherland revient dans cette présentation sur la première implémentation de Scrum chez Google.
En 2001, Google avait de gros problèmes pour tenir ses deadlines. Ils ont commencé à introduire Scrum en utilisant les backlogs et les burndown charts, puis les daily scrums. Pourtant les livraisons continuaient de prendre du retard. Après investigations, ils se sont aperçus que beaucoup de tâches étaient "en cours" en même temps. La principale leçon à retenir est de ne pas se disperser sur trop de tâches, l'équipe doit se focaliser sur le minimum de tâches possible jusqu'à ce qu'elles soient complètement terminées.

RIA

Le contenu Flash / Flex indexable

InfoQ rapporte une avancée majeure pour Adobe : le contenu des applications Flash (et donc Flex) est dorénavant indexable par les principaux moteurs de recherche que sont Google et Yahoo.
Avec un avantage non négligeable sur Ajax, à savoir que le contenu dynamique, récupéré du serveur est lui aussi indexé.
Le principe de fonctionnement est original : Adobe fournit à Yahoo et Google un lecteur Flash spécial, optimisé, qui parcourt tout le fichier SWF à la manière d'un utilisateur : instanciation des différents états de l'application, récupération des données dynamiques...
Aucune intervention des développeurs n'est nécessaire, aussi bien sur les nouvelles applications que sur les anciennes.
Certaines fonctionnalités de Flex 3, comme le "deep linking" (historique au sein du fichier SWF, bookmark intra-Flash) ne sont pas encore implémentées.

Un frein (le principal ?) au développement des RIA Flash vient d'être levé.

SOA

REST anti patterns

Stefan Tilkov, éditeur de la communauté InfoQ SOA, présente ses REST Anti Patterns :

• Utiliser uniquement des requêtes GET ou uniquement des requêtes POST : REST utilise la sémantique HTTP avec GET pour les lectures, PUT & DELETE pour les écritures indempotente avec ID et enfin POST pour le reste mais qui est à éviter.
• Ignorer les mécanismes de cache : le code retour HTTP 304 Not Modified et ses headers associés ETag, Expires permettent une grande souplesse de mise en cache par les clients et les proxies pour offrir une très grande tenue à la charge.
• Ignorer les codes retour HTTP : les codes retour HTTP sont très expressifs (201 Created, 406 Not Acceptable, 412 Precondition Failed, etc) ; se limiter aux inexpressifs 200 OK et 500 Internal Server Error nuit à l'auto-documentation.
• Mal utiliser les cookies : REST est par essence sans état ; si les cookies peuvent maintenir des informations stateless comme l'authentification, ils ne doivent en revanche pas porter d'information stateful ou métier (id, etc).
• Oublier l'hypermedia : les hyperliens sont à REST ce que sont les clefs étrangères aux base de données relationnelles. On notera toutefois que l'utilisation d'hyperliens est aujourd'hui très délicate ; xlink reste confidentiel pour XML et les équivalents en JSON ou YAML restent à trouver.
• Ignorer les types MIME : chaque utilisateur a son format de prédilection et se limiter à un seul format limiterait les opportunités de ré-utilisation. On retiendra XML pour java / .Net, JSON pour javascript, YAML pour Ruby et HTML pour les humains.
• Casser l'auto-description : idéalement, tout message devrait contenir suffisamment d'information (headers, format, etc) pour qu'un client générique puisse le traiter. Toute invention de header, protocole ou format nuit très fortement à l'utilisabilité de la ressource.

Le coin de la technique

Bonne utilisation des generics

Introduits lors du jdk 5, les génériques sont maintenant utilisés dans la plupart des applications Java. Les développeurs, aussi bien débutants qu'expérimentés, ont dans l'ensemble bien compris leurs avantages. Ces 'marqueurs' permettant de détecter les problèmes de cast dès la compilation ce qui facilitent indéniablement la lecture et l'auto-documentation du code.

Si l'utilisation des génériques est relativement simple à comprendre, cela se complique lorsque vous vous essayez à créer votre propre API. En particulier, l'utilisation des wildcard n'est pas triviale. Qui ne s'est jamais tiré les cheveux pour se demander quand mettre un wildcard. 3 ans après la sortie du jdk 5, êtes-vous familiers avec les formes suivantes ? MyBox<?>, MyBox<? extends T>, MyBox<? super T>

Brian Goetz, l'auteur du bien connu Java Concurrency In Practice revient sur ces notions peu évidentes (cf. le lien en fin d'article). Pour illustrer cette difficulté, il prend l'exemple de la classe AbstractExecutorService introduite lors du jdk 5 dont la signature a été modifiée au jdk 6 : personne n'est à l'abri d'une erreur.

Bonnes pratiques à respecter pour l'utilisation d'une API utilisant les génériques

• Préférez l'utilisation des génériques (List<String>) aux types raw traditionnels (List)
• Proscrire les types raw dans du nouveau code
• Eliminez et documentez les warnings 'unchecked' en utilisant l'annotation suivante @SuppressWarnings("unchecked") en essayant de minimiser sa portée.
• Privilégiez l'utilisation des listes (List<String>) aux tableaux (String[]), lorsque le contexte le permet. En effet, les tableaux sont covariants : contrairement aux génériques. (Si une classe A étend B, B[] peut être casté en A[], alors que List<B> ne peut pas être casté en List<A>).

L'exemple ci-dessous, tiré du livre Effective Java, montre en quoi la covariance peut-être dangereuse.

Bonnes pratiques à respecter pour la création d'une API utilisant les génériques

• Utilisez les types paramétrés simples T lorsque c'est possible
• Utilisez les wildcards pour rendre vos API plus flexibles
• Utilisez les wildcards lorsque que vous désirez passer un type paramétré en entrée d'une méthode (remplacer MyBox<T> par MyBox< ? extends T> ou par MyBox<? super T>)
• N'utilisez pas de wildcard dans les types de retours

Comment choisir le bon wildcard ? Le get-put principe.

• Méthodes de type GET : utilisez le 'upper bounded wildcard' (MyBox< ? extends T>) sur les méthodes qui permettent de sortir des données de la structure courante.
• Méthodes de type PUT : utilisez le 'lower bounded wildcard' (MyBox< ? super T>) sur les méthodes qui font rentrer des données de la structure courante.

D'une manière générale, si l'utilisateur d'une API se pose la question d'utiliser un wildcard, c'est probablement que l'API a été mal pensée.
Au final, notons que si l'utilisation du wildcard extends est relativement répandu, force est de constater que le wildcard super ne se déniche pas encore à tous les coins de rue.

Consultez l'article de Brian Goetz : Going wild with generics

Websphere MQ v7 : un bouleversement discret appelé message properties

Nous avions déjà évoqué les nouveautés de Websphere MQ V7 lors du lancement du programme de beta testing.
Notre attention s'était portée sur l'intégration du moteur de publish/subscribe et l'amélioration des performances et nous n'avions pas vu passer une évolution sur la structure même des messages. MQ v7 intègre le principe JMS de propriétés de message sous une forme beaucoup plus simple à utiliser que les anciens "RFH2 Folders" qui rebutaient certaines équipes non Java lorsqu'on leur proposait d'abandonner le format MQSTR pour bénéficier des propriétés JMS.
Ces nouveaux Message Properties, toujours transparents pour les développeurs JMS, se manipulent facilement pour les développeurs MQI grâce à l'introduction des verbes MQSETMP et MQINQMP. Un mode de compatibilité ascendante transforme ces nouveaux Message Properties en header MQRFH2 lorsqu'ils sont envoyés à d'anciens Queue Managers.
On notera par ailleurs que l'intégration native du mode publish/suscribe dans MQ simplifie l'utilisation de ce mode pour les développeurs MQI avec la création de nouveaux verbes (MQSUB, ...) qui remplacent les fastidieux headers RFH2.
Avec ces deux simplifications majeures, l'utilisation de la richesse de JMS ne devrait plus susciter de réticences dans les équipes MQI.

Tous les détails dans Websphere Technical Exchange : What is new in WebSphere MQ Version 7 et Redbook (Draft) : WebSphere MQ V7.0 Features and Enhancements