Revue de Presse Xebia

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

Actualité éditeurs / SSII

Le coin de la technique

Actualité éditeurs / SSII

Sortie d’Activiti 5.0, un nouveau venu dans le monde des moteurs BPM

Le projet Activiti vient de sortir en version finale (l’annonce ici et relayée chez infoQ).

Ce projet, distribué sous licence Apache, est une alternative aux moteurs BPM (Business Process Model) OpenSource jBPM et Bonita. Il est développé par plusieurs sociétés dont les plus connues sont Alftresco, SpringSource, Atos Origin, MuleSoft ou encore FuseSource et est dirigé par Tom Baeyens, qui n’est autre que le créateur de jBPM.

Pour rappel, les moteurs BPM permettent l’exécution de process décrits par des notations (ici Business Process Model Notation v2.0). Ces process peuvent être écris directement en XML ou à l’aide d’un modeleur (celui fourni par Signavio par exemple) ou du designer du projet Activiti, directement intégré dans Eclipse. L’intérêt du BPM est de pouvoir modéliser visuellement un process complexe ou métier critique, et de pouvoir partager une représentation, voir même collaborer à son élaboration avec par exemple, des experts métier. Dans ce cas de figure, la solution Activiti Cycle permettant un travail collaboratif entre les développeurs et les experts métiers, prend tout son sens.

Ce nouveau moteur BPM est l’aboutissement d’environ neuf mois de travail (l’annonce de la création du projet ici) et le fruit de l’expérience acquise sur jBPM. Le numéro de version choisi, 5.0, permet d’insister sur le fait que malgré sa jeunesse, ce produit repose sur la grande maturité de ses développeurs (notamment Tom Baeyens et Joram Barrez) sur ce type de produit.

Activiti supporte la notation BPMN 2.0 (qui standardise ce qui était disponible dans la notation jPDL spécifique à jBPM) et est facilement embarquable dans une application Spring. Le moteur d’exécution permet l’appel à des services Java (injectés par Spring) ou encore à des scripts Groovy.

La documentation du projet est relativement complète et la communauté est très active sur les forums ou l’irc pour répondre à vos questions.

Activiti est un projet réellement intéressant et simple à mettre en œuvre. Il corrige un certain nombre de problèmes rencontrés chez son grand frère jBPM (notamment dans la version 4.x) comme l’utilisation de services Spring par le process ou la gestion des transactions.

Hudson quitte le giron d’Oracle

La migration du code source de Hudson de java.net vers Kenai était programmée bien avant le rachat de Sun par Oracle. La réorganisation ne devait que la retarder. Mais ces dernières semaines, le projet phare des serveurs d’intégration continue a connu un grand chambardement.
Tout commence par le placement de Winston Prakash, un ingénieur Oracle, comme co-propriétaire du projet sur java.net. Ensuite, les mailings listes ont été migrées de java.net vers Google Groups. La migration du code de Hudson est planifiée, comme celle de Glassfish, vers Kenai. Et là commencent les ennuis : les accès SVN sont coupés pendant presque une semaine, ce qui, pour un projet qui connait une demi douzaine de commits par jour (uniquement sur le core) est un réel handicap. Un groupe de core-commiters accélère la migration vers Google Groups, en espérant faire suivre rapidement l’ensemble de la communauté. Kohsuke Kawaguchi, le fondateur du projet, exaspéré par le blocage de fait du projet, décide d’initier une migration sur GitHub, pour pouvoir continuer à travailler. Ce projet donne lieu à une vive réaction d’Oracle, via Ted Farrell, un senior VP, qui s’inquiète de ces changements. C’est ce mail qui semble-t-il a échauffé les esprits : les développeurs Hudson et Oracle veulent continuer à faire avancer Hudson. Mais ce sont les façons de faire qui divergent : les uns poussent pour un ‘tout communautaire’, les autres pour une communauté « pilotée » par des instances comme Oracle, Sonatype et Cloudbees. Il semblerait que la réaction maladroite d’Oracle ait déclenché une avalanche qui pourrait amener au fork complet du projet, et à l’abandon de Hudson, marque détenue par Oracle. Mais que les centaines de milliers d’utilisateurs de la plateforme se rassurent : même si le projet change de nom, la farouche volonté de ses core développeurs, illustrée dans cette « affaire », offre de belles perspectives d’avenir au serveur d’intégration continue inventé par Kohsuke Kawaguchi.

De façon à être un maximum impartial, voici les différents points de vue:

Le coin de la technique

Le nouveau SDK de Google App Engine

Ceux qui travaillent sous Google App Engine ont déjà reçu leur cadeau de Noël avant l’heure!

En effet, l’article très controversé de Carlos Ble (Voir notre revue de presse de la semaine dernière) laisse place à un nouveau SDK qui apporte des fonctionnalités très attendues de la communauté App Engine :

Channel API

L’API Channel est enfin disponible pour les applications Java. Elle permet de créer des applications en temps réel (sans utiliser les traditionnelles méthodes de Polling / Long Polling), grâce à un canal de communication bidirectionnel avec le client.

Always On

Une application déployée sous App Engine qui devenait inactive était rapidement stoppée avec pour conséquence un redémarrage lent pour l’utilisateur (selon le temps de déploiement de votre application). Bien que certains contournaient cette limitation en utilisant le service de cron de Google pour créer de l’activité sur l’application, la solution était peu élégante et ne fonctionnait que pour une seule instance de l’application. Désormais, moyennant finance (9$ / mois), vous pouvez réserver 3 instances qui seront toujours disponibles.

Retrait de la limitation des 30 secondes.

Auparavant, chaque traitement ne devait pas excéder 30 secondes et il fallait utiliser le service de tâches d’App Engine (TaskQueue) pour effectuer des traitements plus longs. Même si cette limitation est cohérente avec les bonnes pratiques de développement, Google vient de passer cette limitation à 10 Minutes.

Augmentation de la taille des appels sur certaines API (auparavant la limite était d’1MB) :
- Passage à 32MB pour les réponses HTTP via l’api URLFetch
- Passage à 32MB pour le mode Batch (GET / PUT) sur le cache distribué MemCache
- Passage à 32MB pour les réponses provenant de l’API Image
- Passage à 10MB pour les pièces jointes des mails envoyés de la plate-forme.

Et pour ceux qui n’ont toujours pas expérimenté Google App Engine, un livre blanc vient d’être publié sous Google Code.

OpenXava, le CRUD facile

L’équipe OpenXava vient d’annoncer la sortie de la version 4.0 de ce framework web Java qui se veut résolument simple et « clé en main ».

Foncièrement centré sur le modèle de données, OpenXava met en effet l’accent sur la délivrance logicielle rapide et libère le développeur du fardeau que constitue bien souvent la conception d’une interface graphique. Celui-ci n’a plus qu’à se focaliser sur l’essentiel: son modèle de données. Grâce à OpenXava, ce modèle est automatiquement exposé sur une interface web orientée RIA certes sobre, mais néanmoins puissante. Jugez-en plutôt: navigation dans des listes paginées avec accès au détail de chaque élément; recherche multi-critères; formulaires de création et mise à jour d’entités du domaine, avec la possibilité de parcourir le graphe d’objets en se « promenant » dans les associations entre entités; validation instantanée de la saisie utilisateur; reporting PDF et Excel grâce à JasperReports; etc., etc. : OpenXava vous génère tout cela, et bien davantage, en à peine quelques minutes de développement! Côté persistance, tout est prévu: grâce à la prise en charge des annotations JPA, votre modèle de données est persisté de façon transparente. Côté déploiement enfin, les applications OpenXava se déploient facilement tant sur des serveurs d’application classiques que sous forme de portlets.

Les nouveautés d’OpenXava 4.0 sont résumées dans cet article, rédigé par l’initiateur du framework, Javier Paniza:

Une interface web repensée et plus riche en fonctionnalités;
La prise en charge des annotations JPA 2.0;
La prise en charge de l’injection de dépendances « façon » JSR-330 (@Inject);
Le support de Groovy sur l’ensemble des couches applicatives, y compris le modèle de données.

Populaire en Espagne d’où il est originaire, OpenXava commence à gagner en notoriété au-delà des frontières ibériques, grâce notamment à une communauté très impliquée: OpenXava dispose en effet d’une documentation bien ficelée et multilingue, d’un forum actif, et même d’un livre!

Il va de soi qu’OpenXava ne cible pas les applications grand public aux interfaces aguicheuses, mais davantage les applications d’entreprise. Utilisé à bon escient, et malgré un léger manque de maturité perceptible par exemple dans la gestion de l’internationalisation où le français, bien que pris en charge, souffre de quelques problèmes d’accents ce framework, conçu par des développeurs pour des développeurs, peut être un véritable levier pour la productivité de l’entreprise.

Kafka, le broker de messages distribué de LinkedIn

LinkedIn a open sourcé un nouveau projet issu de ses développements internes. A l’instar de nombreux autres grands sites Web, LinkedIn produit en effet lui-même des outils pour répondre à ses besoins, si exigeants en termes de tenue à la charge et de temps de réponse, que les solutions existantes ne conviennent pas. C’est ainsi que ces dernières années LinkedIn a diffusé Voldemort, sa base de données clé-valeur distribuée, ou encore Zoie, une extension Lucene pour traiter les indexations en temps réel.

Cette fois il s’agit de Kafka, un broker de messages distribué et conçu avant tout pour supporter une très forte charge. Il se distingue tout d’abord par le fait qu’il est écrit en Scala, langage qui semble populaire actuellement pour l’écriture rapide d’outils distribués de ce type (Twitter l’utilise également pour écrire FlockDB, sa base de données graphe, ou encore Gizzard, son outil de partitionnement de stockage).

Mais c’est surtout son architecture qui distingue Kafka des autres middlewares de messages :

La persistence des messages est assurée par une structure de données append-only similaire à celle que l’on trouve chez BigTable ou Cassandra.
Le choix à été fait de ne placer que très peu de données en cache au sein de la mémoire de la JVM, et de reposer principalement sur des lectures disques qui seront naturellement mises en cache par le système d’exploitation. Cette approche a été popularisé par Varnish, un serveur proxy très courant aujourd’hui.
Contrairement à de nombreux MOM tels qu’ActiveMQ avec KahaDB, Kafka n’utilise pas de B-Tree pour le stockage, il dispose donc d’une sémantique réduite pour accéder aux données de la file, mais il garantit ainsi l’exécution des lectures et écritures en temps constant, quelque soit la taille de la file d’attente.
Les transactions distribuées étant très couteuses, Kafka propose une approche différente, dans laquelle le client est lui-même en charge de maintenir un offset courant dans la file qu’il consomme. Ainsi il lui est alors simple de persister cet état au plus proche des données qu’il produit, afin de profiter d’une transaction non distribuée.
Avec Kafka, le producteur, le broker et le consommateur peuvent être distribués. La coordination des différents noeuds est assurée par Zookeeper, qui devient peu à peu une brique de base pour de nombreux outils distribués.

LinkedIn offre donc une fois de plus à la communauté Open Source un outil distribué simple et très efficace, à l’image de Voldemort. Cette vision rafraichissante des outils d’entreprise courants montre que de nombreux progrès sont encore possible au sein de l’éco-système JEE.