Revue de Presse Xebia
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
- Spring Source : les VC prennent le contrôle
- JBoss certifié Java EE 5 : un anachronisme corrigé ...
- ... tandis que Websphere 7 sera le dernier grand sur la ligne d'arrivée
Agilité
RIA
Le coin de la technique
- Les spécifications REST se terminent
- JVM Wish List vue par Terracotta
- Principes pour le design d'une API
- David Syer communique sur Spring Batch
Actualité éditeurs / SSII
Spring Source : les VC prennent le contrôle
Les semaines se suivent et ne se ressemblent pas chez Spring Source. Après le tumultueux revirement de stratégie Open Source il y a dix jours (cf. Nouvelle politique de maintenance de Spring : La très périlleuse route de monétisation de l'open source), Benchmark Capital, le principal fond d'investissement de Spring Source, prend le contrôle opérationnel de la société en nommant Rob Bearden President and Chief Operations Officer (COO). Rod Johnson conserve le titre de CEO.
C'est un véritable tournant dans la vie de Spring Source qui était jusqu'à présent gouvernée par son fondateur Rod Johnson et est aujourd'hui confrontée aux défis de la rentabilité et de la croissance.
Nous noterons au passage un clin d'oeil de l'histoire : Rob Bearden, avant de rejoindre Benchmark Capital, a été COO de JBoss. Le monde de l'Open source est petit, espérons que les relations conflictuelles entre les camps JBoss et Spring Source s'adoucissent 
Les interrogations sont nombreuses : quelle place trouvera Rod Johnson dans cette nouvelle organisation ? Quelle stratégie Open source va adopter Rob Bearden ? Entérinera-t-il la nouvelle politique de commercialisation des releases post trois mois qui suscite encore une polémique très vive ?
Quelques liens :
- The Server Side : What will be next with SpringSource?
- Communiqué officiel : SpringSource Names President and Chief Operating Officer
- The Register : SpringSource VC investor takes COO role
JBoss certifié Java EE 5 : un anachronisme corrigé ...
L'anachronisme que personne ne comprenait est enfin corrigé. JBoss Application Server, précurseur de Java EE 5 avec le support de JPA dans Hibernate et la Web Application qui jouait le rôle d'un conteneur d'EJB 3 est enfin certifié Java EE 5. Sacha Labourey, JBoss, annonce dans JBoss AS is now EE5 certified! que la version release sera disponible dans les semaines à venir. Il n'en reste pas moins que JBoss AS 5 est une refonte sur le fond du serveur d'application (nouveau messaging, clustering, etc) qui a duré plus de trois ans (cf InfoQ : Releasing JBoss AS 5: Q&A with Project Lead Dimitris Andreadis) et qu'on peut s'attendre à une phase de stabilisation de la nouvelle stack JBoss.
... tandis que Websphere 7 sera le dernier grand sur la ligne d'arrivée
IBM nous rappelle avec Websphere que les parts de marché sont parfois décorrélées de l'implémentation des dernières spécifications. Websphere 7 sera le dernier grand serveur Java EE a être certifié Java EE 5.
La version d'évaluation est déjà disponible sur DeveloperWorks ; des blogs (Websphere Community et Websphere and Messagin) relaient la communication institutionnelle.
Agilité
Le Scrum meeting, story par story ?
Les daily standup meetings se déroulent habituellement personne par personne, c'est-à-dire que chaque membre de l'équipe répond aux 3 questions l'un après l'autre. Le défaut de cette méthode selon Mike Cohn est qu'elle ne permet pas toujours de voir les problèmes sur les stories dont personne ne s'occupe puisque personne n'en parle.
Il suggère la possibilité d'attaquer le standup story par story, mais on perd alors en visibilité sur ce que fait chaque personne. Face à ce dilemme, plusieurs solutions sont possibles :
- L'équipe s'engage t-elle sur trop d'items par sprint ? Mike préconise une moyenne de 1 à 1,5 story / personne / sprint. Attention, cela ne veut absolument pas dire qu'une story doit être gérée par une seule personne !
- Faire le standup devant le tableau des tâches, afin que chaque personne puisse pointer les items sur lesquels elle travaille.
- Désigner des "story owners" : pour chaque story, une personne de l'équipe est responsable de son avancement. Cette personne n'est pas forcément le développeur principal de la story.
- Regarder la taille de l'équipe : selon ses observations la taille idéale d'une équipe se situe entre 5-7 personnes.
La plupart des équipes font leur standup par personne, mais certaines équipes peuvent se heurter à un manque de visibilité sur certaines stories. Cette vision "story par story" peut répondre à leurs attentes.
RIA
Microsoft et Nokia adoptent jQuery
À part GWT avec Google, un des reproches que l'on peut faire aux librairies JavaScript/AJAX est leur absence de support par un grand éditeur. Cet état de fait pourrait bien changer pour la librairie jQuery, une de nos librairies favorites, que l'on conseille et rencontre de plus en plus fréquemment chez nos clients. jQuery annonce sur son blog l'adoption par Microsoft et Nokia du framework, et son intégration dans leur plateforme de développement officielle respective.
jQuery sera donc distribué avec Visual Studio, et sera présent dans tous les nouveaux téléphones de Nokia qui utiliseront le moteur de rendu maison Web Runtime.
Les bénéfices pour jQuery et ses utilisateurs sont multiples : la reconnaissance de la librairie comme parmi les plus populaires, et son amélioration via la soumission de patchs et de tests. Excellente nouvelle donc !
Le coin de la technique
Les spécifications REST se terminent
Vous en entendrez certainement parler prochainement à l'occasion de Spring 3.0, les spécifications de la JSR-311 : Java API for RESTful Web Service (JAX-RS) ont été approuvées quasi unanimement (15 pour, 0 contre, 1 non votant) par l'executive comitee.
JAX-RS est une API permettant l'implémentation de Web Services REST, son fonctionnement est simple :
- on rajoute des annotations sur des classes et des méthodes pour décrire les services à exposer et la manière de les exposer
- le choix du service s'effectue en fonction des URL / Content type / Headers et type de requête HTTP
REST étant à la mode, plusieurs framework existent déjà dont :
- Jersey, l'implémentation de référence pour JAX-RS développée par Sun
- Restlet, le framework du moment le plus utilisé pour les applications REST
- CXF RESTful Services, l'implémentation JAX-RS du projet Apache CXF
- RESTeasy, la version JBoss
Une interview des specs leads Marc Hadley et Paul Sandoz est disponible sur InfoQ. Une des questions intéressantes porte sur l'influence de la JSR311 sur les spécifications de Servlet. Cela nous rappelle que, même si les API REST et les Servlets ont des approches complètement différentes, ces deux technologies doivent pouvoir cohabiter et travailler ensemble.
JVM Wish List vue par Terracotta
Cet article présente une liste d'améliorations JVM espérées vues par un spécialiste Terracotta. S'il est vrai que cet outil aborde des problématiques peu communes (clustering de JVM), certaines de ces idées pourraient être utiles pour tout autre framework utilisant l'instrumentalisation de code.
Voici les idées proposées par Steeve Haris dans son article regroupées par domaines, elles permettent de :
- Simplifier grandement le code de ce genre de framework en évitant d'avoir à développer des surcouches logicielles simulant certaines de ces fonctionnalités
- Permettre de créer des
proxyd'objets niveau JVM : cela faciliterait le maintien de la heap virtuelle de Terracotta - Pouvoir associer des métadatas à un objet : cela permettrait d'affiner les choix du memory manager de Terracotta
- Faciliter le développement de tricks en améliorant le _Hot swapping_
- Optimiser le nombre d'objets à instrumentaliser
- Permette d'instrumenter des tableaux sans avoir besoin de passer par les classes les utilisant
- Permettre le remplacement de méthodes natives : actuellement si l'on veut modifier le comportement d'une méthode native, nous somme obligé d'instrumenter tous les objets appelant celle-ci.
- Adapter la JVM aux architectures d'aujourd'hui
- La taille des listes et des collections est définie par un
int. Les architectures 64 bits nous permettant d'ajouter de plus en plus de mémoire, il se peut que cette taille devienne insuffisante dans certaines utilisations.
Principes pour le design d'une API
Joshua Bloch (Google), auteur de Effective Java, énumère un ensemble de principes clés afin de réussir la conception et la réalisation d'une API : Bumper-Sticker API Design.
Une API n'est pas seulement mise en place dans les frameworks mais aussi dans des applications à différents niveaux :
- la couche d'accès aux données
- la couche service
La volonté d'une API est de réaliser un module cadré au fonctionnement clair. Le fonctionnement interne du module est caché derrière un contrat d'utilisation (qui ne repose pas nécessairement uniquement sur des interfaces Java). Le terme d'utilisabilité de l'API peut être employé.
L'utilisabilité d'une API peut être décrite avec les spécificités suivantes :
- contrat d'utilisation simple et explicité, cela passe par le nommage des éléments (classe, méthode, argument, ...).
- l'intégration aux cas d'utilisation doit être naturelle. Pour que ce soit le plus naturel possible, on peut même envisager de d'abord coder les cas d'utilisation avec l'appel à l'API et ensuite coder l'implémentation de l'API.
- l'implémentation de l'API doit être indépendante du contexte d'appel
Le développement d'API pose le problème de la gestion des versions. A partir du moment où elle est exposée, une API doit répondre de la même façon à tous les appels, quel que soit le client sollicitant le service. Il est vital de respecter les principes de l'IoC Inversion of Control, et ne pas enrichir chaque version d'un ou plusieurs comportements spécifiques :
// Traitement spécifique client 1
} else if (isClient2) {
// Traitement spécifique client 2
} else {
...
}
Des principes qui font généralement débats sont aussi présentés :
- Faire peu de documentation, les noms des classes/méthodes doivent être explicites
- Ne pas remonter de
CheckExceptionque desRuntimeException
Il est vrai que la principale difficulté d'une API est de bien faire dès la première version. La moindre modification du contrat d'utilisation de l'API entraînera des régressions chez les clients de l'API.
C'est pour cette raison qu'il faut tenter de faire un premier jet aussi bref et concis que possible, et de ne traiter la multiplicité des cas qu'au fur et à mesure de leur apparition, dans des versions ultérieures.
Pour conclure, on reprendra la phrase de Joshua Bloch : le design d'API est un art, pas une science exacte.
N'hésitez pas à visionner le vidcast associé à cet article.
David Syer communique sur Spring Batch
Nous vous l'annoncions avant l'été, David Syer, le leader technique de Spring Batch, a entamé sa "tournée promotionnelle".
À travers ce vidcast, capté au QCon de Londres et relayé par InfoQ (ou bien via le support de présentation), il revient sur :
- les patterns de batch et leur utilisation
- un survol des concepts de SpringBatch
- une étude de cas
- l'avenir de ce produit
D'autre part, dans une autre vidéo publiée sur TV4it, Olivier Rachon, Senior Manager chez Accenture, nous en dit plus quant à l'utilisation de ce récent framework : 5 projets en production, des 10aines en cours de développement.
Pour information, la version 1.1.2 est disponible et les premiers tests que nous avons effectués, dans le cadre d'un XKE, nous ont paru très convaincants. Nous devrions publier prochainement notre retour d'expérience sur ce framework.
Billets sur le même thème :
1. Concernant le "revirement de stratégie Open Source", ça serait sympa de vous renseigner, surtout quand j'ai déjà fait un blog pour vous expliquer la fois précédente (voir sur http://www.springsource.com/fr/blog ). Il y a zéro changement de licence, et zéro changement de stratégie. Si cela vous choque que nous donnions des versions spécifiques à nos clients (et partenaires, dont vous faites partie), renseignez vous : nous faisons cela depuis des années (c'est l'une des raisons pour lesquelles on nous achète notre support), et en plus nous ne sommes pas les seuls à le faire. Rien qu'en France, je connais 4 autres boîtes qui font des "patchs" à Spring, et qui de plus ne les redonnent pas à la communauté (ce que nous faisons systématiquement, je le répète). Le seul changement concerne la politique de maintenance.
2. Concernant la nomination de Rob Bearden : là encore, renseignez-vous. Rod Johnson reste le PDG, que cela soit bien clair. Rob remplace Neelan Choksi, qui avait auparavant le même poste (il ne s'agit pas d'une création de poste). Neelan provenant de BEA, et Rob de JBoss : annoncer que l'arriver de Rob c'est la fin de l'Open Source, cela montre bien le peu d'estime que vous avez pour JBoss!! D'autre part Rob provient en effet de Benchmark Capital, suite à notre premier tour de table (c'était il y a un moment, il y en a eu un deuxième depuis), et Neelan, de son côté, reste au board (en plus il part bosser avec des copains). Bref, rien de bien extravagant. Et Rob est bien entendu OK avec la nouvelle politique de maintenance, ce n'est pas le genre de chose qu'on a fait derrière son dos.
3. C'est "SpringSource", pas "Spring Source".
4. Je précise que la politique de maintenance concerne l'ensemble des projets Spring, dont Spring Batch. Et que c'est grâce à nos ventes de support que nous pouvons sponsoriser le développement de tels outils, faire des vidéos pour expliquer leur bon fonctionnement, etc... Des choses dont Xebia est bien heureuse de bénéficier par la suite.
Tant qu'à rectifier les infos, il serait bien aussi de modifier la page http://www.springsource.com/fr :
"Via sa division Covalent, SpringSource est également leader dans le développement des produits Apache, en particulier Apache httpd (le serveur Web le plus utilisé au monde), Apache Tomcat et Apache ActiveMQ."
SpringSource (ou covalent) ne sont en rien "leader dans le développement de produits Apache". Il se trouve que Jim Jagielski et William Rowe sont deux commiters sur Httpd ou Tomcat, parmi beaucoup d'autres. Et ce ne sont pas des produits, mais des projets.
Une phrase plus 'correcte' serait :
"Via sa division Covalent, SpringSource participe activement aux projets Apache, en particulier Apache httpd (le serveur Web le plus utilisé au monde), Apache Tomcat et Apache ActiveMQ."
merci.
- Il n'y a pas que Jim et Bill. Par exemple, sur Tomcat, il y a Mark Thomas et Filip Hanik, qui sont deux des trois principaux contributeurs. Et il y en a encore d'autres...
- Concernant le terme "produits", c'est moi qui ait mal traduit "Apache-related products" - je vais changer pour mettre "des projets Apache", mais nous proposons bien des produits à partir de ces projets : ERS en particulier. Par contre ce ne sont pas des produits Apache, effectivement.
- J'en profite pour ajouter que proposer de produits commerciaux à partir de projets Open Source, ce n'est vraiment pas quelque chose de nouveau : comme on peut le voir dans le cas d'ERS, cela fait des années que Covalent le fait. Bref, ce n'est pas vraiment une stratégie très nouvelle.
@Emmanuel : finalement j'ai quasiment copié/collé ta phrase, je n'ai pas trouvé mieux! Merci!
J'ai également corrigé la même erreur sur la page http://www.springsource.com/fr/support
Notre site comporte actuellement un grand nombre de pages en Français, que je tiens à jour moi-même : j'y fais très attention mais une erreur est vite survenue.
Rapide la modification sur le site de SpringSource
merci !
Il n'y a aucun problème à vendre des produits à partir des projets apache (c'est même pour cela que la license a été conçue), mais effectivement il ne s'agit pas de produits apache. vous êtes en bonne compagnie (Iona, IBM, Sun ...).
Bonjour Julien,
Concernant le "revirement de stratégie", ne plus packager en version open source les "releases post trois mois" et ne plus publier sur le CVS public les tags associés est un changement important pour les utilisateurs et est assez inhabituel sur les projets open source.
Cette annonce a d'ailleurs suscité une vive réaction de la part de la communauté. Certaines prises de position relèvent j'en conviens d'overreaction pour citer Rod Johnson ; d'autres, notamment provenant de contributeurs bénévoles très présent sur les forums officiels, sont mesurées et témoignent d'un étonnement voire d'une déception.
J'y vois donc un changement important de stratégie.
Par ailleurs, le concept de versions spécifiques pour les clients commerciaux est habituel dans le monde open source et ne me choque pas ; ce qui l'est moins est de ne plus publier en open source les "versions post trois mois". L'approche communément retenue jusqu'à présent était la consolidation d'une version commerciale aux versions moins fréquentes mais plus testées, mieux packagées et souvent complétées d'outils de supervision. C'est ce que je comprends de Covalent/SpringSource Enterprise Ready Server (Apache Httpd, Tomcat, etc) et que l'on retrouve notamment avec Redhat Enterprise Linux, JBoss Enterprise Application Platform, Sun GlassFish Enterprise Server, MySQL Enterprise Server, IBM Websphere Community Edition (Geronimo), Iona Fuse (ActiveMQ, CXF et ServiceMix) [1]. Aucune de ces initiatives commerciales ne s'est accompagnée de la disparition des releases open source "post trois mois" ; ce choix est d'ailleurs indépendant du mode de gouvernance exclusif (Redhat/JBoss, Sun) ou communautaire (Apache).
Concernant la nomination de Rob Bearden, tout d'abord, Neelan Choksi était certes COO de SpringSource mais Rob Bearden a aussi et surtout le titre de Président(cf SpringSource : management). La différence peut être importante dans la distribution des rôles entre Rob Bearden et Rod Johnson chez Spring Source.
Ensuite, loin de nous l'idée que Rob Bearden va enterrer la culture Open Source de SpringSource. Rob Bearden a contribué à la mise en place du modèle économique de JBoss qui est aujourd'hui rentable. RedHat est d'ailleurs une des success story Open Source les plus proches du modèle de SpringSource : une startup Open Source qui ne s'est pas faîte racheter par un grand éditeur commercial. La présence d'une personne aussi expérimentée nous semble être une opportunité pour SpringSource dont le portfolio de frameworks est de très grande qualité.
Enfin, concernant l'adhésion de Rob Bearden à cette nouvelle politique de maintenance peu commune dans l'univers Open Source et la place qu'il compte tenir chez SpringSource, nous attendrons sa prise de parole en public qui ne tardera sûrement pas.
Cyrille (Xebia)
[1] Je note toutefois que le projet Liferay a annoncé une direction similaire à celle de SpringSource et que ce modèle va peut être s'étendre.
Ah non, plus Iona
C'est d'ailleurs bien dommage, c'était une bonne boîte. J'espère que leurs acquéreurs continueront dans la bonne direction.
J'ai utilisé le nom commercial Iona Fuse qui est toujours en vigueur mais vous avez raison de le rappeler, Iona a été racheté par Progress Software qui était jusqu'alors peu présente dans l'univers Open Source.
Nous noterons de cet événement que si Progress Software décidait de stopper son investissement, la gouvernance partagée de la Fondation Apache permettrait à d'autres acteurs de reprendre le flambeau. C'est déjà en partie le cas avec SpringSource qui renforce sa contribution au projet ActiveMQ.
C'est la Fondation qui gouverne les projets et aucun acteur, aussi méritant soit-il, ne pourrait changer la nature Open Source ou le rythme des correctifs d'un projet.
Cyrille (Xebia)
@Cyrille : je suis tout à fait ok sur tes deux points.
Pour le coup des tags : on est à l'étude pour trouver une solution, mais si on met les tags alors autant donner directement les jars packagés. C'est donc là un vrai problème, mais nous allons essayer de trouver une solution qui convienne à tout le monde.
Pour Rob : je ne sais pas s'il va beaucoup s'exprimer, parce que ce n'est pas vraiment son rôle (cela reste toujours le domaine privilégié de Rod). Mais je pense effectivement qu'il va beaucoup nous apporter, et que son expérience chez JBoss est un vrai plus.
@Julien,
Je comprends bien la difficulté de l'équation et j'espère que la polémique actuelle trouvera une issue sereine dans laquelle chacun se rappellera les qualités des frameworks Spring indépendamment de cet épisode qui concerne seulement les aspects économiques.
Monétiser l'Open Source est un sujet nouveau et encore très difficile.
SpringSource est un cas à part par l'intensité de son investissement sur les frameworks Open Source : des briques pour lesquelles le modèle économique Open Source reste à trouver.
On le voit d'ailleurs avec JBoss qui est profitable grâce à la vente de support aux exploitants pour le serveur d'application alors que le très réputé framework Hibernate fait figure de danseuse avec ses revenus marginaux.
Cyrille qui a passé sa journée sur spring-core, spring-security et spring-web-flow pour le Single Sign On CAS de son client.
[...] son annonce. Après les vif remous engendrés par la nouvelle politique de maintenance et l’arrivée de Rob Bearden à SpringSource de la semaine dernière, au programme cette semaine, une nouvelle un peu plus [...]
[...] que font certains frameworks concurrents (dont Grails). Comme nous l’avons annoncé dans une récente revue de presse, nous espérons que Spring 3.0 supporte l’intégralité de la JSR-311 : Java API for RESTful [...]