« ServiceMix 3.2.x – Introduction à JBI
WebLogic Persistent Store »
4 août 2008
Imprimer ce billet

Revue de Presse Xebia

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

Evènements de notre communauté en France et à l’étranger

Actualité éditeurs / SSII

Pourquoi payer pour de l’open source ?

Alexis MP, Sun, explique dans Why should I buy a subscription when community support is good enough? les avantages à payer un éditeur (ou une société de support) lorsqu’on utilise un produit open source dont la communauté est très active :

  • Correction des bugs : plutôt que d’avoir une correction en mode best effort avec une communauté, la souscription garantit l’utilisateur, avec un délai de réponse assuré, des mécanismes d’escalade et des correctifs allant du contournement au bugfix directement ré-intégré dans les versions suivantes du projet open source selon le type de souscription.
  • Accès à des patchs : une fois le bug corrigé, le packaging du correctif peut être complexe. Cette difficulté sera particulièrement sensible sur les systèmes d’exploitation (e.g. Linux) et les middlewares (e.g. Glassfish, JBoss App Server, MySQL, Tomcat) qui sont souvent complexes à builder. Les souscriptions protègent les clients de ces complexités en assurant la livraison de versions adaptées du produit open source avec l’ensemble des patchs qui ont été nécessaires au client.
  • Indemnisation : problème beaucoup moins médiatisé en France qu’aux États-Unis, l’utilisation de produits open-sources expose les utilisateurs à des infractions aux lois sur les brevets et la propriété intellectuelle. Pour mémoire, la société SCO, avant d’être déboutée par la justice, avait demandé à des grandes entreprises américaine utilisatrices de Linux des dommages et intérêts au motif que Linux aurait violé des brevets appartenant à SCO. Certains verront dans cet argument une nouvelle rengaine de la tactique de Fear, Uncertainty and Doubt (FUD)mais ce risque de procès existe théoriquement.

Alors, faut-il payer pour de l’open source ? S’il s’agit de librairies / frameworks utilisées par des équipes de développement (e.g. Struts 2, Spring, Hibernate, etc), les avantages sont discutables. En revanche, pour un middleware compliqué qui a un rôle critique en production (base de données MySQL/PostgreSQL, middleware de message ActiveMQ, etc), du support commercial avec un engagement de temps de correction prend toute sa signification.

Le coin de la technique

JavaFX en pre-release

JavaFX est enfin disponible en pre-release. Un an après son annonce et quelques bugs corrigés, la technologie permettant le développement d’interfaces riches à la sauce Sun pointe le bout de son nez.

Concurrent sérieux à Adobe Flex et Microsoft Silverlight ? Sun semble mettre beaucoup d’énergie dans cette initiative mais nous remarquerons qu’Adobe a une très grande longueur d’avance avec un produit mature et une communauté très active aussi bien du côté des web designers que des développeurs. Microsoft est certes en retard face à Adobe mais est tout de même sur le point de lancer la version 2 de Silverlight et a entamé la difficile tâche de séduction du pré-carré d’Adobe : les graphistes et les web designers.

La technologie JavaFX se compose d’un langage de développement (JavaFX Script), d’un compilateur, d’un environnement d’exécution et de différents plugins destinés aux développeurs(plugins NetBeans) et aux web designers (Adobe Illustrator et Photoshop). De plus, elle compte séduire les développeurs en proposant une interaction aisée avec les APIs Java existantes.

La version 1.0 de JavaFX est prévue pour cet automne.

Annonce de la sortie :

Démos et tutoriaux :

Grilles de calcul versus grilles de données

GridGain joue des coudes pour essayer de différencier sa solution de grilles de calcul Open Source de ses concurrents. Dans cette optique, ils ont publié cette semaine un article sur Dzone présentant les différences entre les grilles de calcul et les grilles de données.

Le principe de base du calcul distribué s’appuie sur le célèbre adage « diviser pour régner ». Pour accélérer la résolution d’un gros problème, il est parfois possible de découper celui-ci en tâches indépendantes pour répartir les calculs sur plusieurs machines. Ce paradigme est appelé map reduce.

Le principe des grilles de données (plus communément appelées caches distribués) est différent. Ici aucun calcul n’est effectué. Les grilles de données se veulent maximiser la récupération d’objets à partir de la mémoire tout en assurant une cohérence des données dans un contexte multi-machines.

Vous l’avez compris, ces deux types de produits n’adressent pas les mêmes problématiques. Ils peuvent d’ailleurs être complémentaires dans certains cas, c’est pourquoi un certain nombre de produits se positionnent sur ces deux types de problème simultanément (Websphere eXtreme Scale / Oracle Coherence).

Des dangers de la virtualisation appliquée à la haute disponibilité

Billy Newport, Websphere eXtreme Scale, explique dans The dangers of virtualization and datagrids comme la grille de données d’IBM concilie haute disponibilité et virtualisation.

Le fond du problème est que les grilles et les clusters offrent de la haute disponibilité auto-configurée en dupliquant les informations critiques sur plusieurs noeuds dont la probabilité de panne simultanée est infime. Avant la virtualisation, il suffisait de différencier les noeuds par leur adresse IP. Aujourd’hui, la virtualisation permet de démarrer deux serveurs virtuels aux adresses IP différentes sur le même serveur physique ; l’assomption de beaucoup de solutions de haute disponibilité auto-configurées devient alors caduque.

En attendant l’arrivée d’API qui permettrons de détecter que deux serveurs virtuels s’exécutent sur le même serveur physique, une étape de configuration manuelle s’impose pour garantir que des données critiques ne se retrouvent pas dupliquées sur le même serveur physique qui héberge d’autres serveurs virtuels.

Actualité OSGI

OSGI est certainement l’un des sujets les plus fidèles de nos revues de presse. Après le prototype de Java Module / OSGI de la semaine dernière, deux actualités OSGI cette semaine :

Convention de nommage pour langage Java

John O’Hanley, auteur du framework Web4J et de javapractices.com, propose différentes conventions de nommage pour le langage de programmation Java, Four harmful Java idioms, and how to fix them.

Voici les 4 conventions que propose John O’Hanley :

  • 1 - Préfixer les attributs de classes privées par « f« , les arguments de méthode par « a« ,
  • 2 - Organiser les packages Java par critères fonctionnels plutôt que par couche,
  • 3 - Ne pas utiliser la convention JavaBeans pour les objets immuables,
  • 4 - Ne pas mettre les attributs privés en début de classe.

Les règles n°1 et n°4 sont contestables, dans la mesure où un IDE moderne, comme Eclipse, disposent de fonctionnalités pour assurer la lisibilité du code, et surtout assurer la distinction entre les différents types de variables (paramètre de méthode, attributs de classe). Eclipse fournit une colorisation du code source et un panneau outline permettant de trier et d’assurer la distinction des différents types de variables (comme le montre l’image ci-dessous) :

La règle n°2 est pertinente. Il est plus intéressant d’avoir un premier découpage en composant fonctionnel. Rien n’empêche, à l’intérieur d’un composant fonctionnel d’avoir un découpage en couche, ou de manière générale un découpage technique. Le concept important est de cerner au mieux la responsabilité fonctionnelle d’une classe en l’exprimant clairement dans le nom de la classe. Le package est un premier filtrage des responsabilités fonctionnelles. Steve McConnell fait l’éloge de ce concept dans le livre Code Complet

Enfin, la règle n°3 pose différents problèmes techniques avec des frameworks existants tel que Hibernate. Hibernate se repose rigoureusement sur la convention JavaBean. Hibernate commence par appeler le constructeur par défaut pour construire l’objet avant d’injecter l’état de l’objet via les différents setters d’attributs de classe.

Evènements de notre communauté en France et à l’étranger

Agile 2008

Cette semaine se déroule LA conférence annuelle sur l’agilité du 4 au 8 août à Toronto. Agile 2008 a un programme chargé avec ses 400 sessions !
Pour ceux qui ont la chance d’y aller, vous serez probablement intéressés par cette sélection des présentations les plus attendues.

Deep lean

Crisp organise un séminaire Deep lean animé par des grands noms du lean et de l’agilité : Mary et Tom Poppendieck, Jeff Sutherland, et Henrik Kniberg.
Ce séminaire de 2 jours aura lieu à Stockholm les 25 et 26 Septembre. Pour plus de détails, regardez l’agenda.

Mots-clefs :, , , ,

Billets sur le même thème :

Vous pouvez suivre les réponses reçues par cet article grâce au fil des commentaires.

6 réponses à “Revue de Presse Xebia”

  • Le 4 août 2008 à 21:28 (), Alexis MP a dit :

    Merci pour tous ces liens ;)

    Pour la partie RIA/JavaFX, je constate que Flex a une avance certaine mais que Adobe mise surtout sur AIR qui est une autre paire de manches (en particulier nouveau runtime à déployer).

    Rich Hall comme nouveau collègue dans l’équipe GlassFish c’est une excellente nouvelle!

  • Le 5 août 2008 à 1:50 (), Olivier Le Merdy a dit :

    Intéressante revue de presse, tout particulièrement en ce qui concerne le feuilleton OSGI.

    Je me permets de réagir au point 3 des conventions de nommage pour langage Java. Initialement, je ne saisis pas trop de l’intérêt du postulat initial: si un objet suit la convention Javabean et propose des accesseurs en écriture, l’objet n’est par définition pas immuable.

    Concernant le contre-exemple Hibernate, je pense qu’il est tout à fait pertinent que les entités soient par défaut modifiables. Si le besoin se fait sentir de disposer directement d’objet immuable depuis une requête Hibernate, il est tout à fait envisageable d’exploiter l’opérateur NEW, par exemple:

    SELECT NEW samples.ProductImmutable(p.name, p.code, p.price) FROM samples.Product p

    De même, même si Spring pousse à l’utilisation de Beans, l’approche par constructeur et l’immuabilité restent possibles.

  • Le 5 août 2008 à 11:43 (), Cyrille Le Clerc a dit :

    Bonjour Alexis,

    Nous partageons votre intérêt pour les initiatives d’Adobe autour de AIR et nous sommes particulièrement frappés par la volonté d’Adobe de nous faire évoluer d’une approche browser centric dans laquelle les RIA [1] sont encapsulées dans des pages HTML vers une approche widget centric dans laquelle l’utilisateur ne lance plus un browser web mais un widget qui est présent sur son home screen (banal sur les téléphones mobiles, Gadget Windows Vista, Widget Mac OS X, etc).

    Nous avions été très amusés, lors du Paris JUG sur Flex, d’entendre James Ward, évangéliste Flex et représentant d’Adobe au JCP, dire que le HTML était une technologie legacy et montrer le widget AIR eBay Desktop qui se substitue à la version HTML du site d’enchères !

    Cyrille (Xebia)

    [1] Flash, Applet avec Java SE Update 10, etc

  • Le 7 août 2008 à 14:50 (), Cyrille Le Clerc a dit :

    Bonjour Olivier,

    Nous aimons l'idée d'avoir des classes immuables pour des entités accédées en lecture seule (données de référence, etc). Un objet avec des fields final, uniquement des getters et un constructeur avec arguments a l'avantage d'être auto-documenté et sans ambiguité.

    Cette approche est hélas délicate à mettre en oeuvre avec JPA (v1 comme v2):

    • L'annotation @Entity ne supporte pas l'attribut mutable, il faut utiliser l'extension Hibernate @org.hibernate.annotations.Entity(mutable = false).
    • JPA autorise le mapping de fields final (e.g. @Basic final String name;) mais exige un no-arg constructor ; on peut y voir un paradoxe.

    Nous avons donc trouvé l'arrangement suivant pour mapper des entités immuable :

    @Entity
    @org.hibernate.annotations.Entity(mutable = false)
    public class Gender implements Serializable {

       /**
        * JPA requires a public or protected no-arg constructor
        */
       protected Gender() {
         this(null, null);
       }

       public Gender(Long id, String name) {
          super();
          this.id = id;
          this.name = name;
       }

       private static final long serialVersionUID = 1L;
     
       @Id
       @GeneratedValue(strategy = GenerationType.AUTO)
       private final Long id;
     
       @Basic
       private final String name;
     
       public String getName() {
         return name;
       }
     
       @Override
       public String toString() {
         return new ToStringBuilder(this).append("id", this.id).
          append("name", this.name).toString();
       }
    }

    Nicolas Lecoz et Cyrille Le Clerc (Xebia)

  • Le 8 août 2008 à 13:44 (), Eric Siber a dit :

    Sur le thème "Grilles de calcul versus grilles de données" et les produits traitant les deux problèmes, merci de m'avoir fait connaître Websphere eXtreme Scale que je ne connaissais pas.
    A noter qu'un acteur majeur sur le datagrid+computing est GigaSpaces, société Israélienne http://www.gigaspaces.com/ qui anime également une communauté open source http://www.openspaces.org autour de son produit payant.

  • Le 3 octobre 2008 à 16:28 (), Blog Xebia France - RIA Contest : Flex / Silverlight / GWT / Echo3 / JavaFX a dit :

    [...] à l’édition 2008, JavaFX se fait attendre. Pour nous faire patienter, Sun a sorti une pre-release, incluse avec NetBeans [...]

Laisser un commentaire

« ServiceMix 3.2.x – Introduction à JBI
WebLogic Persistent Store »