Revue de Presse Xebia

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

Architecture

• Gartner adopte le pragmatisme avec l’Architecture Émergente

Actualité éditeurs / SSII

• JBoss HornetQ

RIA

• BlazeMonster

Le coin de la technique

• Liste finale des évolutions du langage Java apportées par le JDK 7
• Fin d’Eclipse RCP, place à…
• TestSwarm

Architecture

Gartner adopte le pragmatisme avec l’Architecture Émergente

Gartner nous livre un plaidoyer pour la pragmatisme avec Emergent Architecture. La formulation est parfois compliquée mais on se réjouira de trouver la responsabilisation des équipes sur le terrain et des Architectes d’Entreprise évangélistes de lignes directrices. Pour reprendre une expression chère au Lean Manufacturing, « Empower the People » :-) :

1. Non déterminisme – Dans le passé, les architectes d’entreprise prenaient des décisions centralisées qui s’appliquaient à tous. Dans une architecture émergente, ces architectes d’entreprise doivent au contraire décentraliser la prise de décisions pour permettre l’innovation.
2. Acteurs autonomes – Les architectes d’entreprise ne peuvent plus contrôler tous les aspects de l’architecture comme ils le faisaient auparavant ; ils doivent désormais reconnaître l’étendue et la variété du SI ; ils doivent déléguer le contrôle aux équipes sur le terrain.
3. Limiter les contraintes aux lignes directrices – Jusqu’à présent, les architectes d’entreprise ont fourni des spécifications détaillées de tous les aspects de l’architecture ; ils doivent désormais limiter leurs prescriptions aux lignes directrices et de permettre le choix.
4. Acteurs orientés objectif – Auparavant, les seuls objectifs qui comptaient étaient les objectifs de l’entreprise mais cela s’est maintenant déplacé et chaque acteur agit dans ses propres intérêt. Il ne faut pas pour autant oublier les lignes directrices.
5. Influences locales: Les acteurs sont influencés par des interactions locales et des informations limitées. Les feedbacks au sein de leur sphère de communication modifie leur comportement. Aucun acteur individuel ne possède la vision globale d’un système émergent. Les architectes d’entreprise doivent intensifier leur travail coordonner et de transmission de l’information.
6. Systèmes dynamiques et adaptatifs: le système (les différents acteurs et leur environnement) changent avec le temps. Les architectes d’entreprise doivent définir les pourtours des systèmes émergents et ajuster en fonction des changements.
7. Environnement aux ressources limitées: L’abondance, les budgets illimités, ne permet pas de créer une architecture émergente ; c’est au contraire la rareté des moyens qui permet une architecture émergente.

Actualité éditeurs / SSII

JBoss HornetQ

Après 2 ans de développement, le projet JBoss Messaging 2.0 sort enfin dans les bacs sous le nom HornetQ. Ce Message Oriented Middleware n’est pas une évolution de son prédécesseur qui continue d’exister dans sa version 1.0, mais belle et bien une réécriture (presque) intégrale. Redhat nous le vend comme un MoM opensource, multi-protocol, embarquable, haute performance, réparti, et asynchrone.
HornetQ peut-être utilisé en standalone ou bien embarqué dans un serveur d’application JBoss AS par exemple. Chose appréciable, HornetQ est léger, il dépend uniquement du JDK (5 minimum) pour être complètement fonctionnel.
Dans sa présentation, Redhat nous annonce que le projet est facile d’utilisation avec une documentation déjà très complète et la bagatelle de 65 exemples de codes sources. Il est même possible de démarrer en moins de 5 minutes.
HornetQ bénéficie d’une conception orientée Pojo qui lui permet d’être utilisé directement dans Spring ou Guice. La performance a fait l’objet d’une attention importante, avec un journal haute performance et JBoss Netty pour la scalabilité.
JBoss nous livre une liste sans fin des fonctionnalités embarquées parmi lesquels on retiendra:

• JMS 1.1
• JTA
• Adaptateur JCA

Enfin, l’editeur annonce orienter ses développements vers le support d’API RestFull qu’il voit comme le futur du cloud computing. Redhat souhaite donc pousser la porte des clouds privé en tentant de s’imposer comme le provider de message incontournable dans le nuage.

• Site du projet
• Wiki

RIA

BlazeMonster

BlazeMonster vient de sortir dans sa deuxième version. Pour rappel cet outil, basée sur la technologie AIR, permet le support et l’aide à la génération de code pour consommer/exposer des services Java en tant que service Remote pour BlazeDS ou LCDS (LiveCycle Data Services).
Parmi les supports, nous avons entre autre :

• Génération des fichiers de configurations : déclarations des services, channels..
• Génération du code appelant le service Remote
• Génération des beans ActionScript (Value Object)
• Visualisation des réponses des services Remote

Dans cette deuxième version, BlazeMonster intègre le support de Spring BlazeDS, permettant la génération de services Remote en utilisant cette librairie. Je vous invite à jeter un coup d’œil sur les autres corrections et évolutions apportées à ce projet ici.
Facile d’utilisation, ce projet permet de copier/coller des morceaux de code dans votre application, facilitant le développement.
Enfin, à travers ce projet nous voyons, une fois de plus, l’engouement que les technologies Flex et BlazeDS remportent. Peut être pouvons nous espérer l’intégration de ce type d’outil dans le Flash Builder 4. Alors messieurs d’Adobe, qu’attendez vous ?

Le coin de la technique

Liste finale des évolutions du langage Java apportées par le JDK 7

En début d’année, Sun a initié le Project Coin, un sous-projet d’OpenJDK visant à recueillir les propositions d’évolutions du langage Java pour le JDK 7 prévu pour début 2010. Les soumissions ont été nombreuses et Joseph D. Darcy, leader du projet, informait régulièrement la communauté sur l’avancement du processus de sélection. C’est maintenant la liste finale des évolutions qu’il annonce. Sauf problème de planning, il s’agit donc là de ce que le langage Java sera dans JDK 7 :

• Clause switch utilisable sur les String.
• Gestion automatique des resources. Cette évolution vise à simplifier la gestion de la fermeture des flux ou autre ressources par l’utilisation d’une clause try spécifique pour les objets implémentant l’interface Disposable introduite dans le JDK pour l’occasion.
• Inférence de type améliorée pour la création d’objets génériques grâce à une syntaxe du type List<String> list = new ArrayList<>().
• Evolution de la gestion des warnings pour l’utilisation des generics dans des varargs.
• Autorisation de la notation binaire pour les entiers comme en C/C++ et possibilité de placer des underscores dans les nombres pour en simplifier la relecture tel que long creditCardNumber = 1234_5678_9012_3456L
• Accès en lecture et écriture aux valeurs des collections Java par la notation utilisé jusqu’alors uniquement pour les tableaux.

On est loin de la liste d’évolutions très audacieuses initialement prévue pour JDK 7, mais les évolutions finalement retenues ont l’avantage d’être réalistes en terme de temps d’implémentation, tout en apportant un confort supplémentaire au quotidien pour les développeurs Java.

Rémi Forax, très au fait des développements sur l’OpenJDK, propose d’ailleurs son analyse des tâches restant à accomplir et de leur complexité pour chacune des évolutions.

Fin d’Eclipse RCP, place à…

Après Java Rebel, c’est Eclipse RCP qui se trouve sur la voie du changement de nom.
Cette fois-ci, ce n’est pas pour une raison de marque déposée mais tout simplement, dixit l’auteur, parce que ce nom est horrible :-) .
Un vote est organisé avec tous les noms remontés par la communauté Eclipse depuis 3 mois.
Alors, Aurora, Montage ou Tangram, c’est à vous de voter ! Et ça se passe sur cette page.

TestSwarm

John Resig, créateur de jQuery, nous annonce que Test Swarm est maintenant ouvert au public (par ajaxian).

Test Swarm permet de tester le code Javascript sur différents navigateurs de différentes plateformes de manières continues. A l’origine utilisé pour jQuery, il est désormais possible de tester son propre code Javascript, moyennant 8 steps d’installation paragraphe Setting Up Your Own Swarm. Les tests (jobs) peuvent être lancés à chaque commits (SVN ou Git) ou bien en appelant une URL spécifique. Les résultats des tests sont résumés dans un tableau avec une colonne pour chaque navigateur/plateforme. Il est possible de rester au niveau projet mais on peut affiner l’affichage au niveau commit voir au niveau de chaque fichier js de tests. Côté couleur, les tests vert se sont bien passés, les rouges contiennent au moins une erreur, les noirs ont au moins une erreur critiques et les gris sous en cours/en attente. Des logs sont disponibles pour chaque run de tests et permettent de voir ceux qui ne seraient pas passés.

Les frameworks de tests unitaires Javascript gérés (bien d’autres suivront) sont pour l’instant :

• QUnit (jQuery)
• UnitTestJS (Prototype)
• JSSpec (MooTools)
• JSUnit
• Selenium
• Dojo Objective Harness

Une vidéo de type quick tour nous donne un bon aperçu du site. Plusieurs directions sont possible concernant la roadmap du produit dont l’intégration à l’IDE, tests sur encore plus de browser… Un produit à suivre.