Il y a 13 ans -
Temps de lecture 9 minutes
Revue de Presse Xebia
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
- La diffusion des produits d’Instantiations par Google
- Avec BigMemory Terracotta se dote d’une mémoire d’éléphant
- PostgreSQL: version 9.0 finale
Agilité
SOA
Actualité éditeurs / SSII
La diffusion des produits d’Instantiations par Google
Dans les semaines qui ont suivi le rachat de la société Instantiations par Google début août, les produits phares de la start-up, comme GWT Designer, n’étaient plus accessibles. Comme on s’en doutait, Google vient de remettre à disposition ces outils, au détail prêt qu’ils sont désormais gratuits. On retrouve les plugins Eclipse suivant :
Ce plugin est un ensemble de fonctionnalités autour du framework Google Web Toolkit. Parmi ses avantages, on retrouve principalement le designer visuel permettant de concevoir rapidement des interfaces ou d’effectuer du reverse engineering sur un code existant et la génération automatique des services RPC.
L’acquisition de ce plugin marque un renforcement de l’offre RIA de Google, qui annonce travailler sur la fusion de GWT Designer avec GPE (Google Plugin Eclipse) et sur la prise en charge de l’UIBinding.
Ce plugin est un outil collaboratif autour de la qualité du code Java contenant pas moins de 700 métriques. Il propose des fonctions comme l’audit de code, la couverture de code, l’analyse des dépendances.
Ce plugin est un designer visuel permettant de concevoir rapidement des interfaces graphiques dans diverses technologies comme Swing, SWT, RCP, XWT et GWT. Au même titre que GWT Designer, l’outil permet également d’effectuer du Reverse Engineering sur du code existant (écrit à la main ou généré par des outils comme JBuilder, NetBeans, etc.)
Ce plugin permet de réaliser des tests d’interfaces pour les frameworks SWT et Swing.
Avec BigMemory Terracotta se dote d’une mémoire d’éléphant
La semaine dernière Terracotta a annoncé la sortie de BigMemory en version bêta. Cette nouvelle solution, qui se présente sous la forme d’un plugin d’Ehcache, permet d’utiliser un cache pouvant atteindre plusieurs centaines de Go d’espace (la compagnie annonce 350Go) sans souffrir des pauses dues au garbage collector.
Ce tour de force est possible en soustrayant cet espace à la heap de la jvm, Ehcache désigne cet espace off-heap store. Il s’agit d’une énorme HashMap qui n’est limitée que par la RAM du serveur. De plus la configuration semble assez facile, juste quelques lignes à ajouter dans la configuration de Ehcache. Bien sûr pour dépasser les 2 ou 4 Go il faudra un OS 64bits. Il est à noter par ailleurs que cette solution est 100% java. Parmi les points forts mis en avant:
- d’un point de vue logistique, concentrer la gestion du cache sur une seule machine peut être plus simple à gérer qu’avec un cache distribué.
- les projets confrontés à la taille maximum de leur JVM dépensent parfois beaucoup d’énergie afin de trouver les bonnes options pour limiter le garbage collector ou à trouver des dérivatifs, ici la question ne se pose plus.
- les temps de réponse sont quasi constants, en partie parce que le garbage collector n’est pas concerné, ce qui permet d’avoir un SLA prédictible. Le benchmark d’Ehcache est assez évocateur à ce sujet.
Parmi les bémols qui se sont exprimés, le billet sur ServerSide de Joseph Ottinger, employé de Gigaspaces (donc pas 100% objectif) et la discussion qu’il a engendré sont très instructifs. De façon abrégée, les points relevés:
- BigMemory n’est qu’une HashMap, lorsqu’on manipule autant de données il peut être nécessaire d’avoir un mécanisme de requête sur les clés.
- Le garbage collector a ses vertus, lorsqu’il y a un fort ratio d’écritures et que les tailles des objets varient beaucoup on peut se trouver dans une situation où l’espace est très fragmenté ce qui ralentira les écritures.
- Le monitoring de ce cache nécessitera d’autres outils que ceux utilisés habituellement pour surveiller l’efficacité du cache, rendant plus complexe leur utilisation.
PostgreSQL: version 9.0 finale
En version bêta depuis avril, PostgreSQL débarque dans sa version finale 9.0. Souvent considérée comme « l’autre base de donnée open source », PostgreSQL dispose pourtant de nombreuses qualités, que vient renforcer cette nouvelle version. Pendant la phase bêta, PostgreSQLFR nous avait décrit en détails les 2 principales nouveautés, orientées réplication et répartition de la charge en lecture.
- Le hot Standby: des bases secondaires sont disponibles en lecture seule. La charge peut donc être répartie entre les bases.
- La streaming replication: les bases secondaires sont maintenues à jour en temps réel, grâce aux logs de la base principale.
Ces 2 fonctionnalités justifient à elles seules le passage à la version supérieure. Il y en a bien sûr de nombreuses autres parmi lesquelles:
- des améliorations dans la gestion des droits qui peuvent être appliqués:
- sur les blobs
- en groupe sur les schémas
- le support de Python 3 en plus de nombreuses modifications dans la gestion des langages des procédures stockées
La liste complète des ajouts de cette version ainsi que des incompatibilités et informations de migration est disponible dans les release notes. Elle était déjà Open Source friendly, surtout après l’acquisition de MySQL par Oracle, voila que PostgreSQL va à n’en pas douter, avec cette nouvelle version, renforcer sa position dans les entreprises.
Agilité
Les problèmes d’estimation de la valeur métier
Mike Cohn, personnalité éminente dans la sphère agiliste et fondateur de l’Agile Alliance, nous fait part des difficultés à estimer la valeur métier des fonctionnalités développées dans un projet. En général, on estime la valeur métier pour deux raisons:
– Estimer la valeur ajoutée pour la société au cours des sprints (sous forme de graphique)
– Prioriser les user stories de manière plus efficace en comparant la valeur métier au coût de chaque story.
Vu que les user stories sont censés être des petits morceaux de fonctionnalités, il est très difficile de les estimer une à une puisqu’elles sont étroitement liées. Leur estimation s’apparente à la méthode des prix hédoniques (il va falloir ressortir les livres d’économie). Cette méthode est notamment utilisée pour évaluer les biens environnementaux et se base sur le principe que le prix d’un bien dépend de ses caractéristiques et des services qu’il rend.
En faisant des calculs de retour sur investissement, on peut être amené à comparer la valeur métier avec le coût de la story. Or, le coût d’une petite story est souvent dur à déterminer sans prendre en compte les autres stories (ex: une fonctionnalité d’architecture). Cela révèle tout le problème des coûts partagés.
Un autre constat que l’on peut faire est que la valeur de certaines stories peut être considérée comme la valeur totale de la fonctionnalité regroupant des stories. Mike reprend l’exemple de la valeur d’une roue alors que l’on veut fabriquer une voiture: Si on considère que l’on ne veut pas cette voiture sans cette roue, alors la valeur métier de la roue vaut la totalité de la voiture.
Mike nous a exposé tout le problème de l’estimation de la valeur métier sans toutefois nous proposer de méthode miracle. Celui-ci conclut en proposant d’estimer par groupe de user stories afin d’obtenir des valeurs plus réalistes et de permettre d’effectuer des analyses plus significatives.
SOA
Sortie de Mule ESB 3 GA
Le 15 septembre dernier, Ross Masson, CTO de MuleSoft, a officiellement annoncé la sortie de Mule ESB 3 en version GA. Cette 3ème version de l’ESB star, dont la première Milestone remonte à plus d’un an, était très attendue par la communauté Open Source, ainsi que par les utilisateurs, en raison des nombreuses nouveautés qui l’accompagnent.
Parmi les principales fonctionnalités se trouve le tout nouveau module Cloud Connect, qui regroupe un ensemble de connecteurs dédiés à l’intégration avec les applications Cloud, SaaS, ainsi qu’avec les Médias sociaux :
- Connecteurs Cloud clef-en-main dédiés aux fournisseurs de service Cloud populaires tels que Amazon Web Services et Facebook.
- Support natif de REST, facilitant le data-binding et la consomation de services RESTful s’appuyant notamment sur JAX-RS.
- Intégration avec les framework AJAX / JavaScript, offrant la possibilité d’interagir avec les services de l’ESB directement depuis son navigateur à l’aide de connecteurs dédiés à chaque librairie JavaScript (MooTools, ExtJS, JQuery, Dojo).
- Utilisation simplifiée d’ATOM et de RSS, pour la consommation et la création de flux. Il est notamment possible de déclencher des évènements en réaction à un flux.
- Support de JSON, à travers l’utilisation de nouveaux transformateurs.
Cette nouvelle version de Mule ESB introduit également une nouvelle gestion de la configuration basée sur les patterns, simplifiant l’exécution des tâches courantes telles que la publication de service REST, la création de passerelles transactionnelles ou la configuration de proxy de Services Web.
Par ailleurs, Mule ESB 3 supporte maintenant les annotations, simplifiant encore un peu la configuration de ces services. Parmi ces annotations, @Schedule offre la possibilité de planifier simplement l’exécution d’une méthode, et @Transformer, permet d’appliquer des transformations directement sur les messages reçus.
Du côté du déploiement, Mule ESB 3 est maintenant capable de déployer les nouveaux services à chaud, sans avoir à redémarrer son application. Basé sur une architecture OSGI, Mule 3 offre une meilleure isolation, permettant aux services d’être modifiés lors de l’exécution sans impact sur les autres services.
A noter parmi les autres changements :
- Une intégration avec jBPM améliorée permettant d’envoyer ou recevoir des messages vers et à partir d’un processus en cours.
- La possibilité de définir des endpoints dynamiques à l’aide d’expressions (Expression Language).
- Un mécanisme de transformations automatiques, s’appuyant sur les types Mime des messages.
Cette nouvelle version de Mule ESB apporte un très grand nombre de nouveautés, qui ont toutes vocation à en simplifier l’utilisation. La simplicité semble donc être le maître mot de cette 3ème mouture de l’ESB, qui va certainement conserver sa qualification de « couteau suisse » dans le domaine de l’intégration et des architectures SOA. En outre, Mule 3 sait également faire la part belle aux nouvelles exigences des entreprises, en s’ouvrant aux applications Cloud et aux Médias sociaux.
Pour plus d’informations sur Mule ESB 3 :
Commentaire
3 réponses pour " Revue de Presse Xebia "
Published by Bruno Leroux , Il y a 13 ans
Bonjour,
Je n’ai pas étudié Mule ESB 3, mais d’après ce que j’ai lu le choix a été fait de ne pas s’appuyer sur OSGi (soit disant trop complexe alors que les autres ESB le font…). Plus d’infos sur cet article : http://architects.dzone.com/articles/mule-3-embraces-simplicity-and (cf paragraphe au-dessus de la vidéo).
Published by Dominique De Vito , Il y a 13 ans
BigMemory illustre/montre le fait que la JVM manque d’un mécanisme de passivation des données en dehors de la Java heap (mais tjrs en mémoire).
BigMemory prouve que cela est possible, pourrait éventuellement être inclus en standard au sein d’une JVM.
Coté Java RT, il existe différents types de mémoire. Et justement, BigMemory ressemble au développement d’un « nouveau » type de mémoire pour les objets Java.
Perso, j’ai tendance à penser qu’à cause du fait que Java est soumis à la pression de manipuler un volume de plus en plus important de données (et soumis aussi à la pression des limitations du GC), les développeurs font faire face à plus de contraintes et vont avoir besoin de plus en plus de « contrôle » sur leur environnement, i.e. la JVM (car la JVM ne va pas pouvoir tout le temps deviner les meilleurs optimisations à faire). Et justement, les développeurs ont bcq plus de contrôle sur leur environnement avec Java RT.
De ce fait, je pense qu’une possibilité (intéressante) pour développer/faire évoluer Java SE serait de regarder dans la direction de Java RT…
Published by Tom , Il y a 13 ans
Par rapport à la valeur métier, pourquoi s’embêter à « estimer » cette valeur ? Scrum n’en parle pas, il faut juste prioriser les US par valeur métier mais cela n’implique pas d’estimer une valeur pour chaque. Il faut juste comparer/trier. J’avais d’ailleurs compris le post de Mike Cohn de cette manière (« je vois occasionnellement des équipes qui essaient de mettre une estimation de valeur métier sur chaque US »).
Ca me fait penser à ceux qui estiment en heures, ils se posent des tas de questions métaphysiques alors qu’un suivi au niveau des US (done/not done) est suffisant, pas besoin de faire du micro-management. KISS.