Blog Xebia France » OSGi

Revue de Presse Xebia

Xebia France — Tue, 22 Nov 2011 09:09:31 +0000

La revue de presse hebdomadaire des écosystèmes Java/JEE proposée par Xebia.

Actualité éditeurs / SSII

RIA

Sortie de JQuery Mobile 1.0

Le coin de la technique

Persistance Polyglotte

Actualité éditeurs / SSII

Adobe met Flex en Open source

Adobe a annoncé que Flex allait être donné à une fondation open source. Les réactions à l’annonce ont été plus que mitigées, certains parlant d’abandon. Adobe a alors apporté des précisions:

d’une part, la fondation envisagée est la Apache Software Foundation.
les développements en cours, dont le nouveau compilateur et plusieurs widgets, seront inclus dans le transfert.
enfin, Adobe va continuer à s’investir dans le développement de Flex, promettant une équipe de développement qui contribuera au projet open source à temps plein.

Geronimo 3 se prépare: certifié full Profile et utilise OSGI

Géronimo, le serveur EE Open-source d’Apache prépare sa nouvelle version. Comme nous le rapporte The H, la béta 1 vient de sortir. Certes, la release finale est sans doutes loin, mais le serveur a tout de même passé avec succès les certifications Full et Web-Profile de Java EE 6.
A noter que 2 versions du serveur existent. La première, avec Tomcat 7 et Axis 2, est celle qui a été validée. La seconde repose sur Jetty 8 et CXF. Par ailleurs, cette version est basée sur OSGI 4.3 et promet donc, en plus des applications EE, des facilités pour le déploiement d’applications OSGI.
L’annonce officielle est disponible sur le site du projet et la release note est ici.

Google Eclipse Plugin est maintenant open source

La semaine dernière, Google a annoncé que son célèbre Google Plugin for Eclipse (GPE) est maintenant open source. Pour rappel, GPE regroupe un ensemble d’outils de développement qui facilitent la conception, la construction et le déploiement d’applications qui utilisent GWT, SpeedTracer, App Engine et d’autres services du cloud de Google.

La communauté a réagit de manière positive suite à l’annonce. Max Andersen de Red Hat a souligné : “[...] suite à la mise à disposition du code source du plugin, nous envisageons de travailler plus étroitement avec Google et la communauté pour rendre l’expérience des développeurs plus productive et plus intégrée à la plate-forme Eclipse. Nous sommes particulièrement intéressés par les possibilités de déploiement sur des serveurs multiples, telles que la plateforme JBoss Enterprise Application et Google App Engine de façon uniforme [...]”

Le projet GWT Designer, qui s’appuie sur le projet de WindowBuilder, est également disponible sur Google Code sous la licence Eclipse Public License. De cette manière, Google espère que les contributions apportées par la communauté permettront l’amélioration et l’évolution du GPE.

RIA

Sortie de JQuery Mobile 1.0

Après un an de développement, JQuery Mobile sort enfin en version 1.0 finale. Basé sur les frameworks javascript JQuery et JQuery UI, cet outil va permettre de concevoir des interfaces graphiques en HTML5, Ajax et CSS 3 compatible sur un nombre impressionnant de mobiles et tablettes (iOS, Android, Blackberry, Bada, Windows Phone, webOS, Symbian, Meego, etc.)

Au menu, l’équipe met en avant les spécificités suivantes de JQuery Mobile:

Une compatibilité avec de nombreux périphériques,
Une dégradation progressive des composants en fonction des capacités de chaque périphérique,
Des layouts et composants graphiques optimisés pour le tactile, avec auto-adaptation au périphérique,
De grand efforts au niveau des performances (transition, scrolling) et du toucher sur les différentes plateformes mobiles,
L’apparition d’un outil pour customiser ses propres thèmes graphiques avec ThemeRoller for Mobile,
La possibilité d’intégrer JQuery Mobile avec PhoneGap, un outil très puissant pour déployer ses applications web sur de nombreuses plateformes,
Une communauté très active, avec ses nombreux blogs, ressources et plugins.

JQuery Mobile utilise la version 1.6.4 de JQuery, et n’est donc pas compatible avec la récente 1.7, qui a introduit des évolutions non rétro-compatibles avec les précédentes version. Ainsi, il faudra attendre la prochaine version 1.1 de JQuery Mobile.

L’accueil de JQuery Mobile a été quelque peu mitigé. Les performances et la réactivité du toucher semblent très inégales selon le périphérique utilisé.
Malgré la compatibilité avec une large gamme de périphériques, de nombreux développeurs semblent privilégier pour le moment le framework Sencha Touch.

Le coin de la technique

Persistance Polyglotte

Vous avez sans doute déjà entendu parler de la programmation polyglotte: il peut être intéressant d’introduire plusieurs langages dans un projet de façon à disposer d’outils bien adaptés à chaque problématique.

Dans la lignée de la programmation polyglotte, Martin Fowler formalise la notion de persistance polyglotte avec une approche identique. Aujourd’hui tout le monde utilise la base de donnée relationnelle pour la persistance mais tous les problèmes de persistance ne sont pas adaptés au modèle relationnel. L’article en anglais offre une réflexion approfondie et quelques exemples sur le sujet.

Revue de Presse Xebia

Xebia France — Wed, 27 Apr 2011 08:31:25 +0000

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

Actualité éditeurs / SSII

Le coin de la technique

Actualité éditeurs / SSII

Indisponibilité d’Amazon EC2

Jeudi dernier, Amazon a connu un gros problème de disponibilité de ses serveurs situés dans certaines régions des Etats-unis, perturbant très fortement des sites connus comme Quora, FoursQuare ou Reddit. Cette annonce a déjà été beaucoup commentée, les sceptiques du modèle de cloud computing y voyant la preuve de la méfiance qu’il faut accorder à ces nouveaux services. Il est évident que ces perturbations laisseront des traces pendant longtemps. Que dire par exemple de l’histoire de ce fournisseur d’accès qui, après avoir beaucoup hésité, a mis 6 mois pour migrer et qui a justement fini la migration la semaine dernière ?

On peut néanmoins affirmer qu’Amazon joue assez bien la transparence comme l’attestent les nombreux blogs sur le sujet ainsi que leur page très bien faite sur les statuts de leurs services dans le monde entier. Par ailleurs un autre site permet de voir le statut actualisé des sites impactés.

De plus, comme le souligne ce blog, les torts sont partagés avec les clients d’Amazon qui n’ont pas toujours tenu compte des avertissements de la compagnie, comme le souligne un des responsables d’EveryBlock:

While the acute problem originated with AWS, EveryBlock is not without blame for this downtime. Frankly, we screwed up. AWS explicitly advises that developers should design a site’s architecture so that it is resilient to occasional failures and outages such as what occurred yesterday, and we did not follow that advice.

Sans surprise ce sont les projets ayant le plus tenu compte des avertissements d’Amazon qui s’en sont le mieux sortis. Netflix en est un bel exemple et les 5 leçons qu’ils ont tirées de leurs précédentes expériences sont à méditer. La 3ème leçon, entre autre, est savoureuse: The best way to avoid failure is to fail constantly. Pour cela ils ont mis en place un ensemble de scripts qu’ils ont nommé Chaos Monkey et qui consiste à tuer des instances au hasard afin d’éprouver leur système en permanence.

Coherence 3.7 – Plus de problèmes de large heap

Coherence, la In Memory Data Grid d’Oracle, était comme beaucoup de ses consoeurs minée par le problème de la taille des JVMs.
Alors que les serveurs d’entrée de gamme embarquent 32 Go de RAM pour un prix dérisoire, nos grilles mémoires nous recommandaient laborieusement des heap de 1.5 Go à cause des problèmes de temps de pause du garbage collector. Coherence a pris le taureau par les cornes et suivi le même chemin que Terracotta Big Memory pour ne citer qu’eux : implémenter un memory manager à l’intérieur de la heap. Schématiquement, Coherence alloue au démarrage de la JVM un gigantesque tableau de _byte_ et gère lui même cet espace de stockage. Coherence annonce que nous pourrons désormais utiliser des JVM de 30 Go au lieu des limitations à 2.5 – 2 Go actuelles. Les simplifications seront très nombreuses (nombre de processus et de fichiers de logs à monitorer, sizing des data source / connections JMS utilisées en « write-behind », etc).

Autre innovation plus avant-gardiste qui ne concernera aujourd’hui que peu d’utilisateurs : le support de disques SSD, principalement pour porter les replicas. Enfin une rencontre avec Cameron Purdy, directeur technique de Coherence, pour un projet pour une grande banque parisienne, nous a appris qu’il travaille au support d’Infiniband pour connecter les noeuds d’une grille. Un Coherence 4 à 100 Gbit/s réels ?

Revenons à des cas d’utilisation de la vraie vie, le support de large heap est une grande simplification de mise en oeuvre (plus visible du côté Ops que du côté Devs) et nous avons encore plein d’attentes :

Des API plus simples et de plus haut niveau (similaires à « JPA ») pour les équipes informatiques « normales » qui ne sont pas composées que de « geeks passionnés » ; même si ces API seraient plus contraignantes que l’API Map & POF actuelle,
réplication inter-grille avec API de reconciliation (au hasard Londres, New York ou Tokyo pour les banques ),
outillage de déploiement avec un modèle de packaging (similaire à nos .war) et un système de gestion centralisé de grille (déploiement, monitoring, etc).

Tous les détails sur InfoQ – Oracle Coherence 3.7′s Elastic Data Offers Transparent Overflow from Memory to Solid State Storage.

Le coin de la technique

Sortie de Hudson 2.0

Une nouvelle version majeure du serveur d’integration continu Hudson vient de sortir. Cette nouvelle version 2.0.0 introduit un changement dans la numérotation, en suivant le schémas majeur.mineur.patch, notamment préconisé par le versioning dans OSGi. Il se démarque désormais de la notation en 1.x ({{x}} étant le numéro de build), toujours utilisée par Jenkins.

Plusieurs nouveautés importantes accompagnent cette nouvelle version avec notamment une modification du système de plugin qui repose maintenant sur le conteneur OSGi Sisu, utilisé dans Nexus et Maven3. Ce framework reposant sur Google Guice, il permet l’utilisation des annotations de la JSR330 comme @Inject permettant l’injection de dépendances ou encore @Singleton assurant l’unicité d’une instance d’un bean. Sisu permet aussi l’injection de services OSGi sans avoir à écrire du code spécifique à OSGi.

Hudson reposant principalement sur des plugins, l’utilisation d’OSGi pour les déployer paraît particulièrement pertinente.
Ce nouveau système de plugin reste rétro-compatible avec les plugins Hudson actuels, mais la migration des plugins vers le nouveau système est cependant encouragé.

Jenkins devrait lui aussi supporter le JSR330 dans un avenir proche, permettant ainsi de supporter les plugins migrés. Certaines parties de l’implémentation proviendront directement des développements d’Hudson.

Outre cette importante nouveauté, cette nouvelle mouture apporte quelques fonctionnalités supplémentaires :

des boîtes de dialogue modales de confirmation,
la possibilité de nettoyer le workspace avant chaque build,
l’amélioration du support de maven,
la possibilité de publier les plugins Hudson dans un dépôt maven.

Il semble donc que la communauté Hudson soit particulièrement active et qu’une saine concurrence soit installée entre Jenkins et Hudson.

CXF 2.4.0 est dans les bacs

La version 2.4.0 de CXF vient de sortir.

Cette nouvelle version apporte de nouvelles fonctionnalités dont :

des améliorations au niveau de WS-Security avec le support des tokens SAML2, de meilleures performances et un meilleur support de la partie sécurité du profile WS-I Basic,
databinding JiBX,
des améliorations pour la transformation des messages XML pour JAX-RS,
l’ajout d’une console permettant l’accès aux logs CXF,
l’amélioration du support OSGi, permettant le déploiement de CXF dans un conteneur OSGi comme Apache Karaf,
une amélioration du temps de démarrage et de l’empreinte mémoire.

Utiliser Guice et Peaberry pour développer un plugin Eclipse

Nicolas Demengel — Wed, 29 Dec 2010 09:43:40 +0000

Sans travailler spécifiquement sur la plateforme Eclipse et sans être committeur sur un des projets liés, il n’est pas rare de devoir écrire un plugin pour l’IDE Eclipse. Les raisons peuvent être variées : intégrer le gestionnaire de tâches de votre entreprise, supporter le DSL que vous venez de créer, templater des parties récurrentes de votre développement, etc…

Quand on découvre la plateforme, on peut être surpris par deux différences majeures par rapport au développement d’un projet Java « entreprise » :

La manière de builder le projet : Eclipse propose ses propres conventions de structure de projet et fournit ses outils pour le builder. Certains points sont paramétrables mais on ne retrouve pas la richesse offerte par Ant, Maven ou encore Gradle. Cela fera éventuellement l’objet d’un autre article ;
Dans le code lui même : le passage des dépendances entre classes ou entre bundles est particulier, et c’est ce dernier point qui nous intéresse dans cet article. En effet le code d’un plugin Eclipse ressemble souvent à ça : SomePlugin.getDefault().getSomeComponent().getSomeChild().doSomething().

Les singletons sont omniprésents, principalement pour fournir un point d’accès aux différents bundles. Par ailleurs beaucoup d’actions ne sont accessibles que via des méthodes statiques.

Évidemment, le principal problème qui se pose est celui des tests unitaires. Eclipse propose de lancer votre plugin et d’exécuter des tests JUnit dessus, mais il s’agit là de tests d’intégration qui s’exécutent lentement et ne permettront pas de faire du TDD. Il est toujours possible de faire de l’injection de dépendances (DI) « à la main », mais on aurait tort de se priver de l’utilisation d’un framework dédié à cela, d’autant plus qu’on pourrait y gagner d’autres fonctionnalités : binding interface/implémentation, gestion de scopes (singleton, session…), AOP, etc…

En attendant Eclipse 4 – qui proposera nativement des fonctionnalités de DI - je vous propose donc de mettre en place Guice et son extension Peaberry sur un projet-type de plugin pour Eclipse.

Note : pour ce qui est de l’appel de méthodes statiques, aucun framework de DI ne pourra changer la donne puisqu’on est alors dépendant d’une méthode, et non d’une classe. Il faudra donc déléguer ces appels à des classes « tampons » ou mocker ces appels lors des tests avec un framework spécifique tel que JMockit.

Créer le projet de démonstration

Tout le code nécessaire à la démonstration est dans cet article, mais il est parfois abrégé pour des questions de lisibilité. Si vous ne désirez pas créer le projet de démonstration mais que vous voulez malgré tout avoir accès au code dans son intégralité, vous pouvez le trouver sur GitHub.

Nul besoin de quelque chose de compliqué pour cet article, on se contentera du HelloWorld d’Eclipse :

Créer un nouveau projet : « New » > « Project » > « Plug-in Development » > « Plug-in Project » ;
Lui donner un nom, pour notre exemple : fr.xebia.eclipse.guiceexample ;
Changer le nom par défaut de l’Activator afin qu’il représente mieux le fait que ce sera un point d’entrée au plugin, par exemple : GuiceExamplePlugin ;
Choisir le template « Hello, World » ;
Valider.

A ce stade, vous pouvez lancer le plugin (« Run As » > « Eclipse Application ») et constater qu’il vous dit bonjour lorsque vous cliquez sur « Sample Menu » > « Sample Action ».

Afin d’avoir un peu de matière pour la suite, je vous propose deux ajouts :

dans le message, afficher le thème graphique utilisé par la plateforme ;
dans la console, afficher, lors du démarrage, des statistiques sur les points d’extension utilisés ou fournis par le plugin.

Le premier ajout se situe donc dans SampleAction.run() :

public void run(IAction action) {
	String currentTheme = PlatformUI.getWorkbench().getThemeManager().getCurrentTheme().getLabel();
	String message = "Hello, Xebia world. " + NL + "The current theme is: " + currentTheme;
	MessageDialog.openInformation(window.getShell(), "Guice Example", message);
}

Pour le deuxième point, ajoutons le code suivant dans GuiceExamplePlugin.start() :

public void start(BundleContext context) throws Exception {
	super.start(context);
	plugin = this;
	ExtensionStatistics stats = new ExtensionStatistics();
	String message = "This plugin declares " + stats.countDeclaredExtensions() + " extensions and provides "
			+ stats.countDeclaredExtensionPoints() + " extension points";
	getLog().log(new Status(IStatus.INFO, PLUGIN_ID, message));
}

Le code de la classe ExtensionStatistics étant le suivant :

public class ExtensionStatistics {
	public int countDeclaredExtensions() {
		return Platform.getExtensionRegistry().getExtensions(GuiceExamplePlugin.PLUGIN_ID).length;
	}
	public int countDeclaredExtensionPoints() {
		return Platform.getExtensionRegistry().getExtensionPoints(GuiceExamplePlugin.PLUGIN_ID).length;
	}
}

Enfin, afin que le plugin démarre en même temps qu’Eclipse, ajoutons cette ligne dans le fichier plugin.xml :

A présent, lors du lancement de l’application, on peut lire dans la console de l’instance Eclipse de développement :

!ENTRY fr.xebia.eclipse.guiceexample 1 0 2010-12-18 16:47:33.848
!MESSAGE This plugin declares 2 extensions and provides 0 extension points

ou encore dans la vue « Error Log » de la nouvelle instance d’Eclipse :

Et en cliquant sur « Sample Action » on obtient :

Voilà, la suite de cet article va consister à réécrire ces deux bouts de code pour qu’ils utilisent Guice, afin de s’affranchir des couplages forts entre nos classes et leurs dépendances. Mais commençons tout d’abord par l’importation de Guice dans la plateforme.

Importer Guice

Vous trouverez la dernière version de Guice ici. Deux JARs seulement nous intéressent dans l’archive ZIP : guice-2.0.jar et aopalliance.jar.

Eclipse propose deux manières d’importer des JARs dans la plateforme pour les utiliser avec votre plugin :

inclure les JARs dans votre plugin ;
exposer les JARs en question comme des plugins, desquels dépendra votre plugin.

Dans le premier cas, il vous faut :

Placer les JARs dans votre projet (disons dans un répertoire « lib ») ;
Puis, au sein de l’éditeur du manifest de votre plugin, les ajouter dans la section « Classpath » de l’onglet « Runtime » ;
Créer aussi la library « . » pour que le plugin voit encore ses propres classes ;
Enfin, sauvegarder.

La deuxième solution est à préférer si vous comptez utiliser vos dépendances au sein de plusieurs plugins. Les étapes sont les suivantes :

Créer un nouveau projet : « New » > « Project » > « Plug-in Development » > « Plug-in from Existing JAR Archives » ;
Donner l’accès aux JARs à importer ;
Donner un nom au plugin : pour éviter toute collision, une bonne méthode consiste à utiliser le nom de votre organisation ou de votre plugin (selon la portée de votre dépendance), suivi du nom de la dépendance (ou de l’ensemble de dépendances) – dans notre exemple : fr.xebia.eclipse.guiceexample.guice ;
Décocher « Unzip the JAR archives into the project » (ça ne sert à rien) ;
Enfin, déclarer ce nouveau plugin comme dépendance de celui qui nous intéresse : là encore, utiliser l’éditeur du manifest – onglet « Dependencies » – et ajouter fr.xebia.eclipse.guiceexample.guice.

On notera que ce nouveau plugin expose les JARs de la même manière qu’avec la première solution, mais au moins on n’a pas à le faire à la main.

Créer un module Guice et un injecteur

En bref, Guice requiert un ou plusieurs modules définissant les bindings entre des types Java et leur(s) implémentation(s), ainsi qu’un ou plusieurs injecteurs permettant de construire le graphe d’objets à partir de ces définitions. Pour démarrer nous créerons donc un module principal pour notre plugin :

package fr.xebia.eclipse.guiceexample;
import com.google.inject.AbstractModule;
public class CoreModule extends AbstractModule {
	@Override
	protected void configure() {
	}
}

ainsi qu’un injecteur, dans GuiceExamplePlugin :

private Injector injector;
public void start(BundleContext context) throws Exception {
	super.start(context);
	plugin = this;
	injector = Guice.createInjector(new CoreModule());
	ExtensionStatistics stats = injector.getInstance(ExtensionStatistics.class);
	// ...
}
// méthode d'accès qui nous servira plus tard
public Injector getInjector() {
	return injector;
}

Dans le cas qui nous intéresse, nous voudrions nous passer de l’appel à Platform.getExtensionRegistry(). Il suffit de déclarer une méthode @Provides dans CoreModule pour que Guice sache comment nous le fournir :

public class CoreModule extends AbstractModule {
	// configure(){} ...
	@Provides
	protected IExtensionRegistry provideExtensionRegistry() {
		return Platform.getExtensionRegistry();
	}
}
public class ExtensionStatistics {
	private final IExtensionRegistry extensionRegistry;
	@Inject
	public ExtensionStatistics(IExtensionRegistry extensionRegistry) {
		this.extensionRegistry = extensionRegistry;
	}
	public int countDeclaredExtensions() {
		return extensionRegistry.getExtensions(GuiceExamplePlugin.PLUGIN_ID).length;
	}
	// ...
}

Cela nous évite ainsi de créer notre propre factory. Vous l’aurez compris la suite ne relève que l’utilisation basique de Guice, déjà discutée sur ce blog ici et là.

Seulement voilà : lors d’un développement pour Eclipse IDE, la plupart de nos classes est déclarée comme étant une extension à la plateforme (au sein du fichier plugin.xml) et est instanciée par Eclipse, comme c’est le cas pour SampleAction. Dans ce cas-là, comment faire pour s’éviter de devoir à nouveau récupérer par nous-même nos dépendances ?

Injecter des dépendances dans une extension Eclipse

Peaberry’s GuiceExtensionFactory

Une première solution à notre problème est apportée par Peaberry. Il s’agit d’une extension pour Guice qui a été développée alors qu’il ne fonctionnait pas encore en milieu OSGi. Cela est réparé depuis la version 2 de Guice, mais Peaberry n’en fournit pas moins un support beaucoup plus avancé d’OSGi en général, et d’Eclipse en particulier.

Avant toute chose, il faut importer Peaberry et Peaberry-Eclipse. La dernière version se récupère ici, il s’agit alors de procéder comme précédemment pour inclure : aopalliance-1.0.jar, guice-customloader-yyyymmdd.jar, peaberry-1.1.1.jar et peaberry.eclipse-1.1.1.jar. C’est ce dernier JAR qui va nous apporter le support spécifique pour les extensions Eclipse.

Note : il semblerait que l’équipe de Peaberry ait eu un problème de packaging sur la version 1.1.1, perdant ainsi la déclaration du point d’extension décrit ci-après. La procédure pour corriger cela est fournie en fin d’article.

Dans notre plugin (fichier plugin.xml), il est à présent possible de demander à Peaberry d’instancier nos extensions via sa factory :


   
            class="org.ops4j.peaberry.eclipse.GuiceExtensionFactory:fr.xebia.eclipse.guiceexample.actions.SampleAction"

Il faut alors lui préciser le module Guice à utiliser pour injecter les dépendances :

Une autre syntaxe est possible, plus lisible, où le nom de la classe à instancier est en fait l’ID de l’extension (ce qui était déjà le cas dans notre exemple) :


         class="org.ops4j.peaberry.eclipse.GuiceExtensionFactory"
         id="fr.xebia.eclipse.guiceexample.actions.SampleAction"

On peut à présent modifier CoreModule et SampleAction comme suit :

public class CoreModule extends AbstractModule {
	// ...
	@Provides
	protected IThemeManager provideThemeManager() {
		return PlatformUI.getWorkbench().getThemeManager();
	}
}
public class SampleAction implements IWorkbenchWindowActionDelegate {
	// ...
	private final IThemeManager themeManager;
	@Inject
	public SampleAction(IThemeManager themeManager) {
		this.themeManager = themeManager;
	}
	public void run(IAction action) {
		String currentTheme = themeManager.getCurrentTheme().getLabel();
		String message = "Hello, Xebia world. " + NL + "The current theme is: " + currentTheme;
		MessageDialog.openInformation(window.getShell(), "Guice Example", message);
	}
}

On le voit, une fois le problème de l’import de Peaberry-Eclipse réglé, c’est assez simple à utiliser. Il reste malheureusement un problème potentiel : il est impossible de demander à la GuiceExtensionFactory d’utiliser un injecteur existant, elle va donc en créer un pour notre plugin. Si le contenu de plugin.xml est notre seul point d’entrée, tout va bien ; mais si on désire également mettre de la logique dans GuiceExamplePlugin.start() sur la base du même module Guice, une classe déclarée @Singleton pourra alors être instanciée deux fois…

Heureusement la solution est assez simple : écrire notre propre extension factory.

Ecrire sa propre extension factory

GuiceExtensionFactory implémente l’interface IExecutableExtensionFactory, permettant de contrôler l’instantiation des extensions. L’idée est de créer une factory abstraite faisant le même travail à l’exception près que l’injecteur sera fourni par une sous-classe concrète. Voici le code de la factory abstraite (voir le code complet ici) :

public abstract class AbstractGuiceInjectorExtensionFactory implements IExecutableExtension, IExecutableExtensionFactory {
	// définition des champs ...
	public void setInitializationData(final IConfigurationElement config, final String name, final Object data) {
		configuration = config;
		contributor = config.getContributor();
		// si la classe n'est pas fournie dans le même attribut que la factory (i.e: class="factory:classe"), on la récupère dans l'attribut "id"
		className = data instanceof String ? (String) data : config.getAttribute("id");
	}
	public Object create() throws CoreException {
		if (null == className) {
			throw newCoreException("Configuration is missing class information");
		}
		final Class clazz;
		try {
			clazz = resolve(contributor).loadClass(className);
		} catch (final InvalidRegistryObjectException e) {
			throw newCoreException(e);
		} catch (final ClassNotFoundException e) {
			throw newCoreException(e);
		}
		final Object o = getInjector().getInstance(clazz);
		if (o instanceof IExecutableExtension) {
			((IExecutableExtension) o).setInitializationData(configuration, null, null);
		}
		return o;
	}
	abstract protected Injector getInjector();
	// newCoreException(){}...
}

On peut à présent créer une factory différente pour chaque besoin que l’on pourrait avoir. Dans le cas de cet exemple, le but était de partager l’injecteur défini dans GuiceExamplePlugin :

public class GuiceExampleExtensionFactory extends AbstractGuiceInjectorExtensionFactory {
	@Override
	protected Injector getInjector() {
		return GuiceExamplePlugin.getDefault().getInjector();
	}
}

et voici le contenu de plugin.xml associé :



   
            class="fr.xebia.eclipse.guiceexample.GuiceExampleExtensionFactory"
            id="fr.xebia.eclipse.guiceexample.actions.SampleAction"

Note : on pourrait tout à fait utiliser cette factory pour créer des contextes d’injection enfants, dédiés par exemple à un certain type d’extensions définies dans plugin.xml :

public class ActionHandlerFactory extends AbstractGuiceInjectorExtensionFactory {
    private static Injector injector;
    @Override
    protected synchronized Injector getInjector() {
        if (injector == null) {
            injector = GuiceExamplePlugin.getDefault().getInjector().createChildInjector(new ActionHandlingModule());
        }
        return injector;
    }
    public static void cleanup() {
        injector = null;
    }
}

A ce stade, la plupart des besoins en injection de dépendances apparaissant lors du développement d’un plugin basique pour Eclipse sont couverts. On pourra même fournir notre contexte d’injection à des plugins autorisés en exposant une méthode createChildInjector() au niveau de notre plugin. Pourtant, quand le besoin arrive d’aller plus loin dans les intéractions entre bundles, il convient de s’intéresser aux services OSGi et aux points d’extension Eclipse.

Aller plus loin avec Peaberry

Eclipse est avant tout une plateforme OSGi, il est donc possible de publier et consommer des services. Là encore il serait intéressant de pouvoir les injecter automatiquement, voici donc deux grandes fonctionnalités proposées par Peaberry et Peaberry-Eclipse.

Injecter des services OSGi

Voici un exemple montrant l’injection du service EnvironmentInfo d’Eclipse, afin d’afficher l’OS sur lequel tourne la plate-forme :

public class CoreModule extends AbstractModule {
	@Override
	protected void configure() {
		// lors d'une injection, toute instance de EnvironmentInfo sera créée par un service déclarant cette interface
		bind(EnvironmentInfo.class).toProvider(Peaberry.service(EnvironmentInfo.class).single());
	}
}
public class GuiceExamplePlugin extends AbstractUIPlugin {
	// ...
	public void start(BundleContext context) throws Exception {
		// ...
		// ajout du support des services OSGi avec Peaberry.osgiModule()
		injector = Guice.createInjector(Peaberry.osgiModule(context), new CoreModule());
		// récupération du service
		EnvironmentInfo info = injector.getInstance(EnvironmentInfo.class);
		getLog().log(new Status(IStatus.INFO, PLUGIN_ID, "This platform runs on " + info.getOS()));
	}
	// ...
}

Note : il existe une solution plus simple pour récupérer cette information, mais là encore avec une méthode statique : org.eclipse.core.runtime.Platform.getOS().

Injecter des extensions clientes

Le système d’extensions d’Eclipse repose en fait aussi sur des services OSGi, Peaberry-Eclipse va donc nous permettre d’injecter de telles extensions.

Voici un dernier exemple dans lequel notre plugin propose un point d’extension à d’autres plugins pour qu’ils puissent aussi nous dire bonjour :

Créer l’interface définissant le contrat à remplir par l’extension :

package fr.xebia.eclipse.guiceexample.extensionpoint;
public interface HelloWorldParticipant {
	String sayHello();
}

Déclarer le point d’extension dans plugin.xml :

Le définir dans schema/helloWorldParticipant.exsd de la manière suivante :

Enfin, pour les besoins de l’exemple, déclarons une extension sur ce point d’extension (dans le même plugin pour faire simple) :

Créer l’extension :

package fr.xebia.eclipse.guiceexample.extension;
import fr.xebia.eclipse.guiceexample.extensionpoint.HelloWorldParticipant;
public class SampleHelloWorldParticipant implements HelloWorldParticipant {
	@Override
	public String sayHello() {
		return "Sample Hello";
	}
}

La déclarer dans plugin.xml :

Voici alors la manière « standard » de récupérer de telles extensions :

public class SampleAction implements IWorkbenchWindowActionDelegate {
	// ...
	public void run(IAction action) {
		String currentTheme = themeManager.getCurrentTheme().getLabel();
		String message = "Hello, Xebia world. " + NL + "The current theme is: " + currentTheme;
		message += NL + getHellosFromParticipants();
		MessageDialog.openInformation(window.getShell(), "Guice Example", message);
	}
	private String getHellosFromParticipants() {
		String extensionPoint = "fr.xebia.eclipse.guiceexample.helloWorldParticipant";
		IConfigurationElement[] elements = Platform.getExtensionRegistry().getConfigurationElementsFor(extensionPoint);
		final StringBuilder buffer = new StringBuilder();
		for (IConfigurationElement element : elements) {
			try {
				final Object extension = element.createExecutableExtension("class");
				if (!(extension instanceof HelloWorldParticipant))
					continue;
				appendParticipantHello(buffer, (HelloWorldParticipant) extension);
			} catch (CoreException e) {
				// ...
			}
		}
		return buffer.toString();
	}
	private void appendParticipantHello(final StringBuilder buffer, final HelloWorldParticipant participant) {
		SafeRunner.run(new ISafeRunnable() {
			public void run() throws Exception {
				if (buffer.length() == 0)
					buffer.append(NL).append("Other hellos:");
				buffer.append(NL).append(participant.sayHello());
			}
			public void handleException(Throwable throwable) {
				// ...
			}
		});
	}
}

On le voit, c’est plutôt indigeste. Peaberry-Eclipse nous permet de d’injecter ces extensions de la manière suivante :

// annotation de l'interface de l'extension pour fournir l'ID du point d'extension
@ExtensionBean("fr.xebia.eclipse.guiceexample.helloWorldParticipant")
public interface HelloWorldParticipant {
	// ...
}
public class CoreModule extends AbstractModule {
	@Override
	protected void configure() {
		// toute instance de HelloWorldParticipant déclarée par un service (une extension) sera injectée
		// si un Iterable est demandé
		bind(TypeLiterals.iterable(HelloWorldParticipant.class)).toProvider(Peaberry.service(HelloWorldParticipant.class).multiple());
	}
}
public class GuiceExamplePlugin extends AbstractUIPlugin {
	// ...
	public void start(BundleContext context) throws Exception {
		// ...
		// ajout du support du registre des services-extensions d'Eclipse avec EclipseRegistry.eclipseRegistry()
		injector = Guice.createInjector(Peaberry.osgiModule(context, EclipseRegistry.eclipseRegistry()), new CoreModule());
	}
}
public class SampleAction implements IWorkbenchWindowActionDelegate {
	// ...
	private final Iterable participants;
	@Inject
	public SampleAction(IThemeManager themeManager, Iterable participants) {
		this.themeManager = themeManager;
		this.participants = participants;
	}
	// run(){}...
	private String getHellosFromParticipants() {
		final StringBuilder buffer = new StringBuilder();
		for (final HelloWorldParticipant participant : participants) {
			appendParticipantHello(buffer, participant);
		}
		return buffer.toString();
	}
}

Et voilà le résultat :

Dans le cas d’une extension « non-exécutable » (ne fournissant pas une classe à instancier mais des propriétés à récupérer) il est également possible de demander à Peaberry de mapper les propriétés exposées à des méthodes de l’interface annotée avec @ExtensionBean.

Note : n’oubliez pas que les services OSGi sont par nature dynamiques et ne sont donc jamais une ressource acquise. Peaberry est assez sympathique dans le sens où il injecte des proxies dynamiques pour gérer cela automatiquement, mais pour toute utilisation avancée, je vous invite à vous renseigner en détail sur les autres fonctionnalités de Peaberry en rapport avec OSGi.

Conclusion :

Cet article nous a permis de voir qu’il est tout à fait possible d’utiliser un framework d’injection de dépendances lors d’un développement pour Eclipse. Pour les cas les plus basiques Guice seul suffira, de même que d’autres frameworks s’ils supportent le mécanisme de class-loading de OSGi (par exemple Spring). Mais il est possible d’aller plus loin dans le support d’OSGi grâce à Peaberry qui permet d’injecter des services (Spring Dynamic Modules fournit un support équivalent) mais surtout dans le support de la plate-forme Eclipse avec Peaberry-Eclipse qui simplifie grandement la récupération d’extensions clientes.

Les techniques décrites dans cet article me permettent actuellement d’améliorer grandement la lisibilité et la testabilité d’un plugin Eclipse au développement duquel je participe (MoreUnit). En attendant Eclipse 4, je ne peux donc que vous encourager à utiliser ces solutions.

Ressources

La documentation de Peaberry.
Martin Lippert’s SpringExtensionFactory : l’article et le code.
Le code de l’exemple sur GitHub.

Annexe : Procédure pour utiliser le point d’extension org.ops4j.peaberry.eclipse.modules

Récupérer le fichier modules.exsd, il s’agit de la description d’un point d’extension ;
Le placer dans le plugin qui expose Peaberry, dans un dossier « schema » ;
Ajouter un fichier « plugin.xml » à la racine de ce même plugin (s’il n’existe pas déjà) ;
Dans l’éditeur de manifest, cocher « This plug-in is a singleton » (onglet « Overview ») ;
Dans ce même éditeur, ajouter une dépendance à « org.eclipse.core.runtime » (onglet « Dependencies », section « Required plug-ins ») ;
Toujours dans l’éditeur, inclure « plugin.xml » au binard built (onglet « Build », section « Binary Build ») ;
Enfin, à l’intérieur de plugin.xml, déclarer le point d’extension :

Revue de Presse Xebia

Xebia France — Mon, 04 Jan 2010 19:12:31 +0000

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

SOA

Spring Integration et Apache Camel : 2 ESB lightweight en action

Le coin de la technique

SOA

Spring Integration et Apache Camel : 2 ESB lightweight en action

La mouvance SOA a amené un certain nombre de produits classifiés comme ESB (Enterprise Service Bus) dont le but est de répondre aux problématiques d’intégration courantes en entreprise. Dans un premier temps, ces produits prenaient la forme de middlewares très lourds dont la mise en œuvre devait être justifiée par des besoins importants. Il y a deux ans, nous assistions à l’avènement d’ESB qualifiés de lightweight car ils prenaient la forme de frameworks moins gourmands en ressources et plus simples à utiliser. Spring Integration et Apache Camel sont les deux principales options à envisager en matière d’ESB léger.

C’est justement de l’utilisation de chacun de ces deux frameworks que discute l’article que vient de publier Biju Kunjummen. Il y propose une problématique d’intégration qui consiste en l’exposition d’un service qui, lorsqu’il est invoqué, entraîne l’invocation multiple d’un même service de bas niveau via l’utilisation d’un pattern splitter sur la requête et d’un pattern aggregator sur la réponse. Les deux frameworks offrent nativement ce type d’EIP (Enterprise Intergration Pattern).

Aucun favori ne se démarque clairement dans la comparaison entre ces deux implémentations : Spring Integration vient s’intégrer naturellement à l’Application Context de Spring en reprenant le même type de structure de définition XML, tandis qu’Apache Camel, bien qu’offrant également la possibilité d’une configuration XML, sera surtout apprécié pour son DSL Java permettant la définition des routes d’intégration.

Le lecteur intéressé par ces deux frameworks pourra se tourner, au-delà des documentations respectives, vers les deux livres en préparation chez l’éditeur Manning, Spring Integration in Action et Camel in Action, prévus pour l’été prochain.

Le coin de la technique

Impala, la modularité pour Spring sans OSGi

La modularité est un sujet porteur en ce moment, tant du côté du JDK avec Jigsaw, que du côté Java Entreprise avec OSGi dont le principal acteur actuellement est sans conteste SpringSource avec Spring Dynamic Modules et son serveur d’application associé Spring dm Server.

Phil Zoio a été interviewé il y a peu pour présenter le projet Open Source qu’il a fondé : Impala. Il s’agit d’une vision différente de la modularité pour applications d’entreprise. Ainsi, Impala repose sur Spring, tout comme Spring Dynamic Modules, mais contrairement à ce dernier, il n’utilise pas OSGi et adopte une stratégie radicalement différente : il constitue lui-même des modules encapsulant chacun un application context qui déclare un certain nombre de beans. La solution de modularité ainsi produite offre tout comme OSGi un fonctionnement dynamique permettant le chargement à chaud de nouveaux modules.

Dans un climat où beaucoup s’interrogent sur la potentielle lourdeur d’OSGi, ce type d’initiative proposant une solution alternative plus simple face au standard prend tout son sens et n’est pas sans rappeler l’offensive de Spring Framework lui-même, il y a quelques années, face au contesté standard EJB.

La définition de DataSources dans Java EE 6

Matt Corey poste cette semaine un article mettant en avant une facilité rarement (jamais ?) évoquée de Java EE 6 : la configuration des sources de données par annotation. En effet, si la nouvelle spécification de Sun est largement couverte depuis des mois, y compris sur notre blog, il est en général question des nouveautés qui retiennent le plus l’attention telles que les beans singletons d’EJB 3.1, l’API query builder de JPA 2.0 ou encore ses nouveaux modèles de composants.

En fait il s’agit d’une standardisation de la technique de configuration des sources de données dans les serveurs d’application Java EE. Cette définition était en effet jusqu’alors un détail d’implémentation des serveurs et n’était donc pas portable. Cette configuration peut donc maintenant se faire par l’annotation @DataSourceDefinition ce qui évite ainsi l’utilisation de XML et va donc dans le sens de la logique initiée depuis Java EE 5. L’exemple suivant permet de mieux se rendre compte de son utilisation :

@DataSourceDefinition (
className="org.apache.derby.jdbc.ClientDataSource",
name="java:global/jdbc/AppDB",
serverName="localhost",
portNumber=1527,
user="user",
password="password",
databaseName="dev-db"
)
public class Config {
...
}

Si tout le monde n’appréciera pas forcément d’avoir recours à une annotation pour ce type de configuration, les projets souhaitant distribuer des war ou ear portables qui se connectent à une base de données embarquée ou locale devraient en revanche y trouver leur compte.

Les google-collections sont finales !

Annoncée sur la users list du projet, l’API google-collections passe en version finale 1.0.
Pour ceux qui ne connaissent pas encore cette API de collections type-safe, rendez-vous sur cette page pour une introduction à la librairie.

La finalisation de Google Collections constitue un changement majeur dans l’environnement des développeurs Java. En effet Apache Commons Collections constituait jusqu’alors le principal complément à l’API de base du JDK. Or, la librairie de la fondation Apache est vieillissante et ne propose toujours pas les generics de Java 5. Google Collection se positionne donc ni plus ni moins que comme un remplaçant.

La FAQ répondra à bon nombre de questions que l’on peut se poser sur cette API notamment sur les raisons qui ont poussé Google à créer sa propre API plutôt que de contribuer à Commons Collections.

Enfin on notera que Google Collections sera intégré à Guava sous peu pour constituer la librairie d’extension du JDK de Google.

De par la nature de ces APIs, Google Collections et Guava peuvent également constituer un premier pas vers la programmation un peu plus orientée fonctionnelle. A ce sujet, il est aussi possible de regarder du côté de lambdaj, une API de parcours de collections sans boucle explicite. Et pour ceux qui souhaitent aller encore plus loin, rendez-vous sur functional.java ou tournez vous vers la préparation des closures dans Java.

Spring Roo en 1.0.0 pour terminer l’année

Encore une release pour Spring pour clôturer en beauté l’année 2009. Bravo!
Spring Roo, 8 mois après sa première version alpha, vient de sortir en 1.0.0. Roo, en quelques mots, permet de développer des applications plus rapidement en générant et maintenant, tout au long des développements, une partie importante du code source (du POJO à la JSP).
Un effort a été mis sur la documentation qui a intégré un tutoriel et les commandes. La seule partie encore en travaux est le chapitre 3, celle qui concerne le fonctionnement interne de ROO. Cette partie permet entre autres d’avoir les bases pour développer des extensions.
En standard, Roo propose déjà des extensions, comme par exemple les fonctionnalités de sécurité, basées sur Spring Security et des flows avec Spring Webflow.

Spring Roo présente un formidable intérêt pédagogique, car il s’appuie systématiquement sur les toutes dernières versions des jars de Spring et d’Hibernate.
On peut par contre trouver peu commode son mécanisme interne qui se base sur la technologie AspectJ. Son principe est de générer les méthodes de classe en se basant sur des fichiers d’aspects. Jusqu’à présent, notre expérience avec Spring Roo a montré que cela ne fonctionnait pas de manière complètement transparente pour le développeur, même avec l’Eclipse de SpringSource (STS). Cette limitation pourra donc dissuader certaines équipes de partir sur un projet avec ROO tout au long des développements.

Voici sur Slideshare, les deux présentations mises en ligne par le leader du projet, Ben Alex:

Revue de Presse Xebia

Xebia France — Mon, 30 Nov 2009 17:30:44 +0000

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

Actualité éditeurs / SSII

SpringSource et Oracle ensemble pour l’OSGi d’entreprise

Le coin de la technique

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

Devoxx 2009 : le bilan

Actualité éditeurs / SSII

SpringSource et Oracle ensemble pour l’OSGi d’entreprise

Adrian Colyer, SpringSource, a annoncé la création d’un nouveau projet au sein de la fondation Eclipse : Gemini. Il s’agit d’un sous-projet d’Eclipse Runtime qui a pour but de réunir l’ensemble des implémentations de référence des spécifications OSGi liées au monde de l’entreprise. Il s’agit d’un effort commun de SpringSource et d’Oracle.

Deux composants fondamentaux sont apportés par SpringSource :

Gemini Web Container : il permet le fonctionnement d’un conteneur de Servlets dans un environnement OSGi. Cette implémentation est actuellement utilisée dans SpringSource dm Server et est donc prévue pour fonctionner sur Tomcat. Mike Keith, Oracle, assure que l’adaptation pour Jetty arrivera par la suite grâce à une collaboration avec l’équipe de ce projet.
Gemini Blueprint Service : il s’agit de Spring Dynamic Modules. Ce projet, qui a fortement inspiré la spécification du Blueprint Service intégré à OSGi 4.2, devient logiquement son implémentation de référence.

Il est important de noter qu’Adryan Colyer explique que SpringSource continuera désormais le développement de ces deux projets directement au sein de la fondation Eclipse et non plus en interne.

Oracle, pour sa part, apporte plusieurs implémentations de référence pour des RFC supplémentaires non intégrées à la spécification OSGi 4.2 : RFC 98 (transactions), RFC 122 (database access), RFC 139 (JMX integration), RFC 142 (JNDI integration), RFC 143 (JPA integration), RFC 146 (JCA integration).
Mike Keith indique qu’EclipseLink est à même de fonctionner correctement avec OSGi depuis longtemps, mais qu’il n’implémentait pas JPA lorsque cette intégration a été mise en œuvre au sein du projet. Par conséquent, une adaptation est nécessaire pour passer à la RFC 143, afin d’assurer une intégration JPA standard.

Alors que la spécification 4.2 a été finalisée il y a 2 mois, les implémentations de référence étaient toujours attendues. Cette réunification des implémentations liées a l’OSGi d’entreprise au sein d’un même projet Eclipse est une excellente nouvelle : elle met en avant la standardisation dont on pourra désormais bénéficier pour les développements intégrant OSGi dans les applications JEE. Mais cela suffira-t-il à démocratiser OSGi en entreprise ?!

Le coin de la technique

Lucene passe à Java 5

L’équipe du projet Lucene annonce la sortie de Lucene 3.0. Comme nous l’expliquions précedemment, cette version marque une évolution majeure puisqu’elle est la première a nécessiter Java 5.0 au minimum.

L’API bénéficie donc désormais de l’ensemble des améliorations du langage de Java 5.0 dont les generics, le varargs, les enums et l’autoboxing.

Tempérons cette annonce : l’API Lucene n’a pas été refondue, il ne s’agit que de quelques améliorations visant à la rendre type-safe. Citons par exemple :

Apparition d’enums BooleanClause.Occur, Field.Index, Field.Store et Field.TermVector ; ces concepts étaient jusqu’alors représentées sous forme de constantes type-safe.
La méthode getFields() de la classe Document retourne désormais une List alors qu’elle retournait une simple List jusqu’alors.
La classe Term implémente désormais Comparable et non plus simplement Comparable.

Ces changements légers décevront peut-être certains utilisateurs lassés par l’API vieillissante de Lucene, mais on appréciera toutefois la facilité de migration, puisqu’il s’agira la plupart du temps de supprimer quelques casts (l’équipe Lucene cite quelques cas à surveiller lors de la migration).

Cette nouvelle version, qui apporte par ailleurs quelques modifications mineures, conclut donc un cycle d’évolutions importantes sur le projet Lucene.

Mark Reinhold justifie l’introduction des closures

C’était l’Annonce de cette édition de Devoxx, l’apparition des closures en Java 7. Mark Reinhold revient, sur son blog, sur les raisons à l’origine de cette petite bombe.
Il justifie cette évolution majeure du langage par la nécessité pour Java de tirer partie des nouvelles générations de processeurs, multi-cœurs.
Jusqu’ici, pour exploiter cette puissance, il fallait utiliser des Parallel Array et tout le code inutile nécessaire à leur fonctionnement. Les closures permettent de supprimer ce code, et il est temps de les introduire en Java.
Java doit se concentrer sur deux fonctionnalités clés : la syntaxe littérale, et les fonctions typées. L’arrivée des closures requiert deux autres évolutions de Java : les conversions, et l’extensibilité des méthodes.
Il est temps pour Mark Reinhold d’oublier les querelles. Sun spécifiera et implémentera un premier jet des closures pour le JDK 7. Cela permettra une expérimentation à grande échelle, et si tout se passe bien, cela conduira à une JSR de modification du langage, qui pourra être incluse dans Java SE 7.
La tâche est immense et Mark Reinhold appelle bien évidement toutes les bonnes volontés à contribuer.

Bien au-delà de la manipulation du multi-threading, les closures pourraient permettre une simplification des APIs courantes. Cette perspective semble essentielle à Mark Reinhold qui ne pouvait attendre le JDK 8 pour une nouvelle tentative, dans 3 à 4 ans…

Patterns NoSQL

Nous vous parlions récemment dans une revue de presse et un article du mouvement NoSQL, qui se caractérise par « une absence de requête et par un relâchement des caractéristiques ACID propres aux RDBMS ». Ricky Ho, architecte chez Adobe, revient sur son blog sur les caractéristiques communes de plusieurs technologies permettant de « faire du NoSQL », et extrait quelques patterns récurrents. Ne vous arrêtez pas à la mise en page étriquée de l’article, car la description est très complète. Ricky Ho y explore successivement:

Les types de noeud possibles (physiques et virtuels) ainsi que leur fonctionnement.
Le partitionnement des données.
La réplication de ces données, ainsi que le maintien de leur consistance.
La gestion des pannes.

On notera quand même que l’une des solutions retenue pour le stockage des données reste… une base de donnée relationnelle ! Humour mis à part, une telle formalisation de patterns est vraiment bienvenue dans un environnement aussi émergeant.

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

Devoxx 2009 : le bilan

Nous concluons aujourd’hui notre série de billets sur Devoxx 2009. Ces 5 jours passés à Anvers furent riches en informations et en rencontres et nous souhaitions vous les faire partager.

A l’heure du bilan, voici ce que nous retiendrons de cette édition :

Les annonces concernant JDK 7, JEE 6 et Maven 3.0.
Le succès de JEE 6 : toutes les sessions sur le sujet ont fait salle comble.
La place réservée à la nouvelle plateforme Flash d’Adobe, présente au keynote et dans de nombreuses sessions ; il est intéressant de noter que cette place correspond exactement à celle occupée par JavaFX lors de la précédente édition.
L’omniprésence de Scala ; au-delà des sessions qui lui étaient consacrées, il était cité dans beaucoup d’autres présentations lorsqu’il était question de DSL par exemple.
L’intérêt persistant de la communauté pour le Cloud Computing. Ce nouveau concept a rencontré un large succès à Devoxx.

Pour rentrer plus en détails dans les enseignements de cette conférence, vous pouvez désormais retrouver l’intégralité de nos billets Devoxx :

Revue de presse

Xebia France — Mon, 21 Sep 2009 17:35:00 +0000

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

Actualité éditeurs / SSII

Agilité

Pair programming à distance sous Eclipse avec Saros

SOA

L’initiative REST-* fait débat

Le coin de la technique

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

Soirée Tontons Flexeurs le 24 Septembre

Actualité éditeurs / SSII

Google lance son langage pour la JVM

Lors du JVM Language Summit de la semaine dernière, Google a présenté son nouveau langage pour la JVM appelé Noop. Le Wiki du projet et sa présentation permettent de faire le tour des spécificités de ce langage :

Syntaxe prévue pour être facilement compréhensible par un développeur Java ou C++
Pas de types primitifs, pas de classes ou méthodes statiques, variables non mutables par défaut, pas de syntaxe optionnelle, exceptions uniquement de type unchecked
Librairie standard s’appuyant sur JodaTime, util.concurrent et Google Collections
Support natif du concept d’injection de dépendances offert par Guice ou PicoContainer, un type est alors soit newable soit injectable
Support natif des tests unitaires qui ont leur structure dédiée sans classes ni méthodes

Les réactions qui ont suivies cette annonce montrent en général un intérêt couplé à une réserve légitime due à l’état embryonnaire du projet. Ainsi l’analyse de Dominique de Vito s’inscrit dans ce schéma, tandis qu’Alexis Moussine-Pouchkine, Sun, explique à 01net qu’il trouve enrichissant la profusion de nouvelles idées mais que, selon lui, le langage Java restera malgré tout omniprésent pendant encore des années.

Reste que là où de nombreux nouveaux langages justifient leur existence par une syntaxe plus compacte, une nature dynamique ou encore des concepts élaborés, Noop semble adopter une approche plus pragmatique et plus proche des besoins quotidiens rencontrés en informatique de gestion. L’avenir nous dira si les apports de ce langage sont suffisants pour convaincre des équipes de le préférer à Java pour leurs développements.

iBeans : la solution d’intégration pour applications Web de MuleSoft

MuleSource, récemment renommé en MuleSoft lors du lancement de leur offre Tcat Server a récemment diffusé une première beta public d’un nouveau produit : Mule iBeans. Il s’agit d’une nouvelle solution d’intégration s’attaquant à un marché différent des ESB traditionnels. MuleSoft part en effet du constat que de nombreuses applications Web doivent s’intégrer avec diverses ressources distantes, mais ne peuvent s’appuyer sur un ESB qui constituerait une solution trop lourde. iBeans se positionne ainsi en tant que solution d’intégration pour applications Web. La nuance est légère par rapport aux ESB mais on constate clairement cette orientation dans la pratique : annotations, composants iBeans, injection de services type IoC avec un contexte request, …

La particularité principale du projet est son modèle de composant iBeans. Il s’agit de composants similaires aux Beans Spring ou aux Session Beans EJB mais spécialisés dans l’accès à un service à distance. Ces composants utilisent certaines annotations de la récente JSR-330 (Dependency injection for Java) et peuvent s’intégrer facilement avec Spring, Struts et JSF.

MuleSoft propose parallèlement un projet nommé Community iBeans Proposals visant à regrouper les iBeans de la communauté pour intégrer les ressources les plus fréquentes.

iBeans répond à un besoin courant des applications Web. La réponse proposée par MuleSoft est élégante mais on pourra regretter l’apparition d’un modèle de composant supplémentaire disposant de son propre cycle de vie. Actuellement l’éditeur n’a pas communiqué sur son projet naissant en dehors de la page Wiki dédiée. Une recherche Google montre rapidement que la communication autour de ce projet est quasi inexistante. Toutefois, une session dédiée au sujet prévue pour Devoxx 2009 tend à nous faire penser que la célèbre conférence européenne pourrait bien servir de rampe de lancement au nouveau projet de MuleSoft.

Agilité

Pair programming à distance sous Eclipse avec Saros

L’université de Berlin propose depuis quelques temps un plugin Eclipse nommé Saros, offrant des fonctionnalités permettant le pair programming à distance grâce au protocole XMPP. Concrètement les possibilités sont :

Reproduction ou synchronisation d’un projet Eclipse à distance via une connexion XMPP.
Visualisation dans l’environnement de l’observer des classes ouvertes et de la classe en cours d’édition par le driver.
Affichage en temps réel des modifications du code, et de la position du curseur et du texte sélectionné.
Gestion expérimentale d’un mode multi-driver permettant de modifier le code à deux simultanément.
Chat via une vue dédiée dans Eclipse

Un screencast est proposé sur le site du projet, celui-ci permet de se rendre compte des capacités du plugin.

Idéalement complété d’une conversation Skype, ce plugin trouvera sa place dans de nombreux scenarii allant du distributed pair programming à l’assistance d’un collègue situé à un autre étage.

SOA

L’initiative REST-* fait débat

JBoss vient de lancer le site REST-*.org hébergeant son initiative de standardisation de plusieurs services middleware traditionnels sur le modèle REST.

Actuellement deux drafts sont en cours de rédaction, l’un porte sur RESTful Messaging, l’autre sur RESTful Transactions. Ces deux spécifications visent à définir un ensemble d’URIs standards sur le modèle REST permettant d’exposer une ressource transactionnelle ou un broker de messages.

Très rapidement, de vives réactions sont apparues au sein de la communauté, principalement pour faire part de leur scepticisme quant à cette initiative, régulièrement comparée à la très lourde collections de spécifications WS-*, qui pourrait mettre à mal la simplicité unanimement reconnue du modèle REST. C’est ainsi le cas d’Anne Thomas Manes qui revient également sur les critiques de Bill Burke à l’égart de l’initiative RestMS qui existait déjà et qui pariait plutôt sur Atom et AMQP.

Bill Burke de son coté publie sur son blog un billet par jour depuis la publication sur le site REST-*.org, pour justifier ses choix et la légitimité du projet qu’il porte. Ses arguments portent principalement sur le fait qu’il existe une demande très forte de la communauté pour gérer les services de messaging et les transactions avec REST.

Le débat est compréhensible : la volonté d’exposer certaines ressources transactionnelles ou services de messaging s’inscrit dans les besoins courants des entreprises, tout comme les craintes de voir se reproduire les erreurs du passé sont légitimes. L’apport de cette initiative est donc probablement de porter sur le devant de la scène une réflexion sur un problème pourtant courant et déjà exposé par Leonard Richardson et Sam Ruby, il y a deux ans, dans leur livre majeur RESTful Web Services.

Le coin de la technique

OSGi 4.2

OSGi est sur le devant de la scène, d’InfoQ à OSGi Thoughts en passant par The Programming Delusion (BJ Hargrave, CTO de l’OSGi Alliance), depuis une petite semaine et pour cause : l’OSGi Alliance a sorti et mis à disposition le 16 septembre dernier les spécifications finales de la version 4.2 (téléchargeables ici).

Alex Blewitt nous résume la situation sur InfoQ. On retiendra qu’Equinox et Félix ont déjà commencé leur travail de compatibilité avec OSGi 4.2. Les spécifications étant désormais released, ce n’est qu’une question de temps avant que les projets affichent fièrement leur label OSGi 4.2 compliant.
On notera aussi une nouvelle méthode de lancement du runtime OSGi, le nouveau nom des Distributed OSGi qui deviennent les Remote Services (connexion de VMs OSGi), les Blueprint Services qui seront des services wired à la Spring, le concept de Bundle Tracker ou bien encore le mécanisme de permission sur une opération dans un bundle.

Pour la petite piqure de rappel, on pourra se tourner vers JavaLobby qui nous propose depuis quelques jours 2 tutoriaux HelloWorld sur OSGi, le premier avec Swing et le second avec Spring RC.
Et pour les plus nostalgiques, le Paris JUG sur OSGi, c’était (déjà) il y a 1 an…

Scala OSGi-fié

On reste dans les news OSGi avec un projet qui propose Scala 2.7.6 en version OSGi-fiée (vu ici).

Comme expliqué sur le GitHub du projet, Scala n’est pas (encore) packagé en bundle OSGi. Certes, le plugin Eclipse Scala IDE utilise un bundle OSGi qui embarque Scala mais celui-ci ne peut pas être utilisé de manière générale (manifest spécifique et toutes les librairies dans un seul jar).

scala-lang-osgi répond à ce besoin et fournit un bundle OSGi pour chaque librairie Scala. Le tout est disponible sur le repository maven scala-tools.org.

Astuces de performance pour MySQL

Même si nos ORMs préférés génèrent des requêtes optimisées à notre place, il arrive parfois que, pour des raisons de performances ou autres, l’on doive écrire certaines requêtes directement en SQL.
Le site Debian Admin (par Code Purity) référence à cette fin 84 astuces d’optimisations de performances pour MySQL.
Certes, la plupart des astuces de configuration de MySQL sont peut-être/certainement déjà mises en place par nos chers DBA. Mais on trouvera aussi une pléiade d’astuces concernant la requête elle-même : cela passe de la non utilisation du gourmand SELECT *, d’éviter au possible l’utilisation de DISTINCT (très consommateur), d’utiliser pour l’insertion des BATCH INSERT et REPLACE ou bien encore l’utilisation INET_ATON et INET_NTOA au lieu de CHAR et VARCHAR pour les adresses IP.
Pour le détail complet, rendez-vous directement sur le site de Debian Admin.

Enquête sur les temps de redémarrage des serveurs JEE

ZeroTurnAround, l’éditeur de JRebel, a mené (et continue même à collecter des données) une étude sur les temps de redémarrage / redéploiement des serveurs d’applications auprès des lecteurs de son blog (environ 700 personnes ont répondu).
Tout d’abord, passons sur la conclusion évidente de l’étude, vous avez besoin de JRebel, pour tenter de voir au delà de cette évidence marketing. On évitera aussi la polémique sur le rapprochement Conteneurs de Servlets / Serveurs d’applications.
On constate tout d’abord que la population fréquentant le blog de ZeroTurnAround (on a donc dès le début une information en partie biaisée) a une forte tendance à confier ses applications à une plate-forme basée sur Tomcat (JBoss + Tomcat), plutôt qu’aux historiques IBM et ~~BEA~~ Oracle. Là encore, étant donné la notoriété naissante de JRebel, au sein d’une communauté plutôt tournée vers l’open source, rien d’étonnant.

En revanche, il est intéressant de constater que les temps de redéploiement deviennent assez rapidement délirants, avec des serveurs qui en moyenne mettent entre 2 et 5 minutes à redémarrer, la palme de la lenteur revenant, on le savait déjà par expérience, aux gros serveurs monolithiques commerciaux. Alors, au-delà du constat qu’un développeur passe aujourd’hui une grande partie de son temps à attendre que son application se mette à jour sur son serveur d’applications, au-delà du fait que JRebel est une des manières d’adresser ce problème, nous nous posons la question suivante : est-il normal, pour un serveur d’applications, de mettre cinq minutes à redémarrer ?

L’actualité de cette revue de presse met en avant OSGI, qui sera certainement une des réponses apportées à cette explosion des temps de démarrage. Ce sont d’ailleurs les absents de cette étude qui porteront la première estocade : GlassFish 3.x et dmServer.

Premiers pas avec memcached

Dans le but de proposer une implémentation d’un système de cache pour Grails, James Goodwill, sur DeveloperWorks, propose, dans un premier temps, une découverte du système de cache distribué memcached.
Une mise en bouche qui permet de découvrir les bases de ce produit, avant de combiner ce cache avec Grails dans une seconde partie, qui, on l’espère, permettra d’optimiser les performances du plus célèbre des frameworks haute productivité.

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

Soirée Tontons Flexeurs le 24 Septembre

Suite des Tontons Flexeurs, après la très bonne soirée Flex et Java en entreprise, avec une nouvelle session ce jeudi 24 septembre. 2 invités de marque : Mike Chambers et Lee Brimelow qui nous feront une présentation d’Adobe AIR (techniques avancées de synchronisation de données, de manipulation de fichiers, possibilités d’intégration à la plateforme hôte…) et des nouvelles fonctionnalités des prochaines versions de AIR.

A l’heure où nous écrivons ces lignes, il reste encore quelques places disponibles donc rendez-vous sur le formulaire d’inscription de l’évènement.

Revue de Presse Xebia

Xebia France — Mon, 22 Jun 2009 16:19:03 +0000

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

RIA

Le coin de la technique

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

Xebia @ Jazoon 09

RIA

Vaadin 6

Au revoir IT Mill Toolkit et bienvenue à Vaadin (vu sur leur blog) !

Pour ceux qui ne le connaissent pas encore, Vaadin (anciennement IT Mill Toolkit) est un framework de développement d’applications RIA qui s’appuie sur GWT. Sa particularité est d’être runtime donc aucune compilation spécifique n’est demandée avant de packager la webapp (à l’inverse de GWT).

Simple changement de nom ? En tout cas très peu de changement côté API selon les auteurs du framework. Il faut plutôt se tourner vers l’outillage pour voir quelques nouveautés : un plugin eclipse (création de projets, de composants UI, de thèmes…) et, inclus dans le plugin, un éditeur WYSIWYG.

Côté liens utiles, l’habituel showcase, le livre et la comparaison maison avec les autres frameworks du marché (et la concurrence est rude dans le monde du RIA).

A noter que Vaadin sera présent à Jazoon pour une conférence sur RIA Security le mardi 23 juin à 15h (slides, projet et autres sur cette page).

Adaptateur Gilead pour GAE

Vous connaissez GWT, Gilead, et Google App Engine ? Et bien il ne reste plus qu’à mélanger tout ça et on obtient le Gilead GWT adapter for Google AppEngine (vu sur le GWT Blog).

Tout démarre d’un thread google groups avec comme point de départ la serialization exception lancée par les entités persistantes transférées vers GWT. Évidemment, la solution qui ressort très rapidement, outre l’utilisation de DTOs, est de passer par Gilead pour transformer nos entités persistantes en POJOs. Il suffit d’ajouter le jar adapter4appengine et de remplacer la classe PersistentRemoteService par EngineRemoteService dans vos remotes services. Dès lors, il sera possible d’envoyer ses entités persistantes vers le client GWT sans exceptions de sérialisation sur GAE.

1.0 M2 téléchargeable à cette url, documentation par ici. Attention toutefois, cette version n’est pas production ready.

Une série d’annonces chez Adobe

Après l’annonce de la sortie de la plateforme Flash il y a quelques semaines, voici une nouvelle série d’annonce de la part d’Adobe.

Pour commencer, deux news relayées par Andrew Twice dans InsideRIA.
La première concerne la sortie d’Adobe Table en version bêta. Cet outil permet de créer des feuilles de calcul, des plannings ou encore des listes de tâches en ligne:

Les utilisateurs peuvent ajouter des données en même temps: les données sont mises à jour en temps réel pour tout le monde.
Possibilité de savoir qui travaille sur Adobe Table.
Création d’écrans communs et privés : les utilisateurs peuvent travailler de manière coopérative, et/ou créer des espaces privés pour ne garder que les informations importantes.
Filtrage : les utilisateurs peuvent filtrer leurs données en temps réel.
Tri.

Similaire à Google Document, cet outil a été développé sur la plateforme Flash et va continuer à évoluer. La démo se passe ici, la seule contrainte : avoir un compte Adobe.

La deuxième annonce concerne l’ouverture de la spécification de Real-Time Messaging Protocol (RTMP). Comme nous en avions parlé ici, la spécification a été publiée lundi dernier.

Enfin, Michael Chaize parle de la sortie de LiveCycle Data Services 3 en bêta. Disponible sur le labs d’Abobe, cette nouvelle version propose une meilleure qualité de service pour des applications dont la fiabilité est primordiale telles que les applications bancaires par exemple. Venant compléter la plateforme Flash (avec Flex 4 et Flash Builder 4), Adobe incite la communauté à faire ses retours sur le forum.

Le coin de la technique

Scalabilité avec Hibernate et Shards

Une session de QCon 2008, traitant de la scalabilité d’Hibernate, vient d’être mise en ligne. Présentée par Emmanuel Bernard, project lead d’Hibernate Search, et Max Ross, project lead d’Hibernate Shards, cette présentation offre une approche peu courante sur un problème pourtant récurrent.

Outre les classiques solutions permettant d’éviter certaines pertes de performance avec l’augmentation du volume traité, telles que la bonne gestion du cache, et les optimisations SQL, il a été question d’utiliser Hibernate Search et Hibernate Shards.

Hibernate Search est connu pour sa capacité à simplifier les recherches dans un ensemble d’entités grâce à l’utilisation de Lucene conjointement à la base de données. Emmanuel Bernard proposait ici de déléguer à Search certaines recherches qui s’avèrent très coûteuses à effectuer en base. Lucene étant placé sur une machine séparée, et pouvant même fonctionner en maître / esclave, il est ainsi possible d’obtenir une intéressante répartition de la charge.

Hibernate Shards, bien que plus ancien, est moins répandu du fait qu’aucune version finale n’a encore été produite. Il s’agit d’un module additionnel pour Hibernate permettant à une application de manipuler des données partitionnées sur plusieurs BDD. Le but étant d’encapsuler la conscience du partitionnement des données au sein de la couche Hibernate afin que l’application n’ait pas à gérer cette problématique. Les possibilités du framework sont intéressantes :

La gestion correcte des Criterias sur des données partitionnées grâce à ShardedCriteria.
Virtual Shards permettant de faire la distinction entre shard logique et shard physique et ainsi d’augmenter le nombre d’instances de base de données au fur et à mesure de l’augmentation des besoins.
Generation d’IDs compatibles avec l’utilisation sous-jacente de plusieurs BDDs grâce à l’utilisation d’UUIDs.
Gestion correcte de BDDs hétérogènes.

Ce sont finalement les fonctionnalités manquantes qui permettent de comprendre pourquoi Shards est toujours en version bêta. Max Ross s’est expliqué il y a plusieurs mois sur les problématiques rencontrées, de manière succincte sur un forum et plus longuement dans une interview. De nombreux défis restent ainsi à relever concernant la gestion correcte des agrégations dans les ShardedQuery et la fourniture d’outils d’aide au partitionnement et repartitionnement des données.
Max Ross est employé par Google et non par JBoss, tout comme les deux autres committers du projet (le code ayant été donné à JBoss par Google), et affirme ne disposer que de 20 % de son temps pour Shards. Ceci n’explique que partiellement le peu de commits sur le projet et ne nous rassure guère quant à sa finalisation prochaine.

Jigsaw vs OSGi

Sept mois après le démarrage du projet Jigsaw, sa légitimité n’est toujours pas reconnue face à OSGi qu’il est venu défier sur son propre terrain.

La semaine dernière JavaPosse diffusait une interview de Mark Reinhold et Alex Buckley, où ils ont pu présenter plus en détail leur vision de Jigsaw :

Il a été conçu pour modulariser le JDK et est intégré au langage.
Il ne repose pas sur une spécification car cela n’était pas possible compte tenu du calendrier de JDK 7. Il est donc à considérer comme un « détail d’implémentation » tout comme la gestion du classpath l’était dans les JVMs précédentes.
Il n’est pas supposé entrer en concurrence avec OSGi, des outils permettant l’intégration entre modules Jigsaw et bundles OSGi étant prévus, mais non prioritaires.

Dans le même temps, Eric Newcomer (Co-Chair, Enterprise Expert Group de l’OSGi Alliance), postait une série de billets très virulents à l’égard du projet Jigsaw, reprochant principalement que Sun n’ait pas voulu se tourner vers OSGi, ne cherchant pas à combler les manques qu’il y trouvait, se tournant immédiatement vers une nouvelle technologie et ignorant donc les 10 années d’expérience acquises par OSGi.

En fait, il semble n’y avoir aucune justification technique permettant d’expliquer l’orientation de Sun vers Jigsaw plutôt que vers OSGi ou vers une évolution d’OSGi intégrée au langage. La véritable raison serait alors à chercher sur le plan politique : la modularisation est un concept important qui manque à Java actuellement et Sun ne pouvait probablement pas se permettre, pour l’ajout d’un tel concept, de s’appuyer sur une spécification émise en dehors du JCP sur lequel il a la gouvernance.

Pourquoi utiliser un portail ?

Le dernier podcast des Cast Codeurs était l’occasion d’une interview de Thomas Heute et Julien Viet sur les portails d’entreprise et sur le partenariat entre eXo et JBoss dont nous vous parlions la semaine dernière.

Les détails liés au partenariat ont déjà été largement couverts par la blogosphère, et c’est surtout le tour d’horizon du concept même de portail que l’on retiendra. Celui-ci reste en effet souvent un élément ambigu au sein de l’écosystème JEE.

Le rôle du portail est d’agréger plusieurs applications au sein d’une unique application Web. Ce besoin technique peut être atteint à plusieurs niveaux de l’architecture de l’application :

Au niveau back-end, par agrégation de Web Service, se conformant ainsi à l’un des préceptes des SOAs.
Au niveau applicatif, par l’utilisation d’un portail, ou d’une solution spécifique.
Au niveau du navigateur Web, par l’utilisation de gadgets, en suivant le principe des Mashups.

En outre, il a également été question des problématiques d’intégration des frameworks Web aux portlets, de complexité éventuelle, et d’adaptation des technologies Web aux portlets. Déterminer si un portail doit être utilisé dans une architecture dépend alors du niveau de tolérance à ces problématiques.

Embarquer le Web dans Java avec JWebPane

Depuis plusieurs années, lorsque l’on veut afficher une page Web au sein d’une application Swing, il faut se tourner vers le composant Browser de la librairie Jdic. Ce composant utilise Embeddable Mozilla, et se présente sous la forme de code natif décliné pour chaque OS et d’un wrapper Java. Outre la nécessité de fournir une version spécifique à chaque OS, ce composant présente également l’inconvénient de mal s’intégrer aux applications Swing du fait de sa nature heavyweight. Pour rappel, un composant est dit heavyweight lorsqu’il est dessiné par l’environnement graphique du système d’exploitation ; à l’opposé il devient lightweight s’il est dessiné par l’application, ce qui est le cas de l’ensemble des composants Swing. Or, faire cohabiter les deux types de composants est délicat car n’étant pas dessinés au même moment, leur superposition est confuse et des chevauchements non contrôlables apparaissent.

Lors de JavaOne, Alexey Ushakov a fait la démonstration du composant JWebPane sur lequel il travaille actuellement et vient de poster des captures d’écrans. Contrairement à Jdic Browser, JWebPane se base sur le moteur WebKit pour effectuer le rendu HTML. Or celui-ci se caractérise par sa nature lightweight s’intégrant agréablement à Swing. La présentation d’Alex Ushakov permet également de constater que son composant est particulièrement riche en possibilité d’interactions et apporte un support pour d’éventuels plugins tels que Flash.

On ne peut qu’apprécier le choix de Sun de créer un composant pour Swing, réutilisable dans JavaFX, plutôt que de privilégier uniquement JavaFX comme cela est souvent le cas depuis son arrivée. L’intégration de JWebPane au JDK 7 est maintenant indispensable pour rendre ce composant réellement exploitable : se basant sur WebKit, il repose donc sur des librairies natives qu’il sera nécessaire de livrer avec les applications Java et seul l’intégration au JDK permettrait de l’éviter. Or, malgré les appels de la communauté, JWebPane reste pour le moment absent de la liste des features du JDK 7 et il est uniquement question d’une mise à disposition sur Java.net.

Revue de Presse Xebia

Xebia France — Tue, 14 Apr 2009 17:07:06 +0000

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

Actualité éditeurs / SSII

Google App Engine pour Java et Groovy

SOA

Le statut de JBI 2 en question

Mobilité

Preview d’Android 1.5

Le coin de la technique

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

Les Cast Codeurs, le podcast Java en Français

Actualité éditeurs / SSII

Google App Engine pour Java et Groovy

Google App Engine, solution de Cloud Computing proposée par Google supporte depuis la semaine dernière (en plus du langage Python disponible depuis un an) le langage Java. Cette solution permet dorénavant de déployer son application web à base de servlets (sous forme de war) sur un serveur virtuel hébergé sur l’infrastucture de production de Google (Google a donné la semaine dernière un compte Google App Engine Java aux 10 000 premiers inscrits).

Google met en avant les avantages suivants :

La facilité d’utilisation via un SDK très documenté et des plugins Eclipse.
La scalabilité gérée de manière transparente et automatique
La fiabilité et la performance fournies par les infrastructures de Google
Enfin, App Engine est gratuit si votre serveur n’excède les 500 Mo de stockage et 5 millions de page visualisées par mois

Google fait une entrée de manière fracassante dans le marché du cloud computing « Java » (Amazon EC2, etc.. ) et propose une offre séduisante où chacun peut créer, tester et déployer son application facilement. La création d’un projet App Engine sous Eclipse via le plugin est simple et le déploiement sur App Engine s’effectue en un seul clic.

Quelques liens utiles :

vous pouvez trouver une description très complète de la solution (en Français) sur le blog de Frank Arnulfo
David Gageot a mis en ligne une feuille Google Spreadsheet qui liste les librairies et frameworks Java supportés par Google App Engine
Groovy est également supporté, retrouvez l’annonce sur le blog de Guillaume Laforge

SOA

Le statut de JBI 2 en question

La JSR-312 : Java Business Integration 2.0 (JBI) a été initiée début 2007 pour pallier les défauts de la première version de ce standard (JSR-208 : JBI). Cette dernière souffrait en effet de nombreuses critiques, portant principalement sur sa lourdeur excessive et son indépendance vis-à-vis des autres standards existants (SCA, EJB3, JAX-WS, …).

Le projet était alors ambitieux mais la perspective d’un tel standard ne manquait pas d’intérêt. Toutefois, deux ans après sa création, le statut de cette JSR, tel qu’affiché sur sa page du JCP, reste toujours inchangé et la JSR est maintenant classée « inactive ».
Ron Ten-Hove (co-spec lead de la JSR), vient toutefois d’apporter une information discrète quant à l’activité de l’Expert Group associé sur la mailing list du projet OpenESB. Il indique que le développement de la JSR n’est pas interrompu et que la classification d’inactivité est uniquement due à une nouvelle règle du JCP qui étiquette ainsi les JSRs dont le statut n’a pas évolué depuis 18 mois. Ceci ne refléterait donc pas le niveau d’activité au sein de l’Expert Group. Aucune date ni évolution de planning ne sont par contre indiquées.

Le standard JBI 1.0 est boudé par un grand nombre de produits commerciaux et Open Source qui préfèrent épouser la vague des « lightweight ESB » dont nous vous parlions déjà il y a un an. Toutefois l’arrivée tardive d’un standard faisant consensus n’est pas forcément un frein à son adoption comme l’a montré EJB 3 remplaçant avec succès ses très lourds prédécesseurs ; la voie reste donc ouverte pour JBI 2.0 et l’avenir nous dira si la tâche n’était pas trop lourde.

Mobilité

Preview d’Android 1.5

En attendant la sortie finale d’Android 1.5 (Cupcake) à la fin du mois, Android Developers Blog annonce la sortie d’une pré-version du SDK 1.5 pour les développeurs d’applications Android.
Parmi la liste complète des nouveautés d’Android 1.5, cette pré-version du SDK propose notamment:

le clavier virtuel
le développement de widgets pour l’écran d’accueil (à l’image de l’horloge ou du widget de recherche qui existent déjà dans Android)
la fonctionnalité live folders
la reconnaissance vocale

Ce nouveau SDK propose également une avancée intéressante : la possibilité de gérer plusieurs versions du SDK en parallèle, par exemple ici les versions 1.1 et 1.5. Les développeurs pourront donc tester leur application sur plusieurs environnements sans manipulations fastidieuses.
Afin de commencer à tester vos applications sur cette nouvelle version d’Android, vous pouvez télécharger ce SDK 1.5 en cliquant ici.

Le coin de la technique

Lucene continue d’innover

Le projet Apache Lucene reste une source d’innovation importante au fil des années. Il compte en effet huit sous-projets, chacun apportant son lot d’outils et d’APIs additionnelles permettant de mettre en œuvre un moteur de recherche toujours plus élaboré.Ces sous-projets vont parfois au-delà du simple environnement de Lucene, comme cela a été le cas avec Hadoop, qui gagne actuellement en popularité et dont le moteur MapReduce est réutilisé par de nombreux autres projets.

Dernière preuve en date de cette activité, le sous-projet Mahout, créé en Janvier 2009 et qui vient d’être annoncé en version 0.1, a pour but de fournir des implémentations d’algorithmes de machine learning, la plupart pouvant être distribués grâce à Hadoop. Ces algorithmes couvrent principalement :

La classification et le clustering : permettent de catégoriser, tagger et séparer des données en groupes. Ainsi enrichies, ces données pourraient par exemple être plus facilement exploitables et accessibles par un moteur de recherche qui saurait exploiter ces informations lors de son processus d’indexation.
Le collaborative filtering : permet de créer des systèmes d’associations d’objets par apprentissage, du type « les utilisateurs ayant acheté cet article ont également acheté … ». Cette fonctionnalité est offerte par le moteur Taste de Mahout.

Ces technologies sont actuellement plus proches du monde de la recherche que de celui de l’informatique de gestion en entreprise. Et c’est bien là que va résider tout le défit pour Mahout : parvenir à proposer une API simple et robuste pour offrir ces fonctionnalités à moindre coût aux applications d’entreprise. Actuellement peu courants, les cas d’utilisation pourraient se multiplier avec la mouvance globale vers les technologies Web 2.0 et autre concepts liés à l’intelligence collective.

ServiceMix 4 et son kernel OSGi

L’équipe de ServiceMix a profité de la conférence ApacheCon Europe 2009 pour annoncer la sortie de la version 4.0 finale de leur ESB.
Rod Biresch présentait en septembre dernier les principaux apports de cette nouvelle version, ce qui permettait alors de constater qu’il s’agissait avant tout d’une refonte de l’architecture du projet. Ainsi, alors que ServiceMix 3 gravitait principalement autour de son conteneur JBI, son successeur utilise désormais un kernel basé sur OSGi et secondé par un module Normalized Message Router (NMR). Il donne naissance à deux sous-projets distincts : ServiceMix Kernel et ServiceMix NMR.

Cette nouvelle architecture permet à ServiceMix de gagner en évolutivité et n’a qu’un impact limité pour les développeurs utilisant cet ESB. Ainsi, les composants développés pour ServiceMix 3.x restent compatibles avec cette nouvelle version, tel que l’on pouvait s’y attendre du fait de la conservation du standard JBI.

En outre, Guillaume Nodet (project lead de ServiceMix) nous apprend que le kernel de ServiceMix 4 attire d’autres projets de la fondation Apache (ActiveMQ, Directory et James) ce qui devrait conduire ServiceMix Kernel à devenir un sous-projet d’Apache Felix et à être, à priori, renommé pour l’occasion en Apache Karaf. OSGi continue ainsi de s’imposer massivement pour apporter la modularité dans les implémentations de conteneurs et middlewares Java, après avoir conquit le cœur de nombreux serveurs d’applications.

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

Les Cast Codeurs, le podcast Java en Français

A l’image du Java Posse anglo-saxon, Emmanuel Bernard (JBoss, Hibernate), Guillaume Laforge (SpringSource, Groovy), Antonio Goncalves (freelance, auteur, Paris JUG) et Vincent Massol (XWiki, Maven) lancent Les Cast Codeurs, podcast dédié aux nouvelles fraîches du monde Java, en Français !
Parmi les sujets discutés pendant cette première édition : Google App Engine, le rachat hypothétique de Sun par IBM ou Java EE 6 proposé en final draft.
On y entend beaucoup Emmanuel Bernard, beaucoup moins Vincent Massol, mais les propos et le format sont intéressants, longue vie aux Cast Codeurs !

Revue de Presse Xebia

Xebia France — Mon, 30 Mar 2009 17:03:17 +0000

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

Actualité éditeurs / SSII

SOA

Red Hat JBoss choisit d’investir dans CXF

Le coin de la technique

Actualité éditeurs / SSII

Sun, Java et le JCP

Depuis quelques jours, une agitation se crée au sein de la communauté Java autour des agissements de Sun vis-à-vis de son projet OpenJDK 7. Plusieurs observations permettent en effet de penser que le JDK 7 pourrait bien ne pas être basé sur un standard du JCP comme c’est habituellement le cas :

Neil Bartlett remarque que le projet Jigsaw, poussé par Sun pour être le système de modules utilisé par le JDK, n’est pas défini par une JSR. Ceci en fait donc une technologie propriétaire dont il doute de la légitimité face à OSGi, un standard bénéficiant de 10 années d’expérience.
Stephen Colebourne constate que Sun ne fait plus mention de « Java 7″ depuis quelques temps, mais seulement de « JDK 7″ qui n’est qu’une implémentation, là où « Java 7″ qualifierait un standard.
Anne Thomas Manes faisant des observations similaires, compare l’OpenJDK à la position de framework Open Source « rebelle », non standard, que tient Spring.
Stephen Colebourne encore, visiblement très impliqué par ce débat, revient dans une série de billets sur les différents qui opposent Sun à la fondation Apache, rappelant l’historique, ainsi que sur la problématique de propriété intellectuelle au sein du JCP de manière générale.

Si le JDK 7 devait être finalisé sans qu’aucun standard ne le soutienne, cela constituerait un évènement majeur, puisque l’avenir deviendrait incertain pour les JVMs fournies par d’autres éditeurs tels qu’Oracle ou IBM.

RIA, SOA, Tim Bray tire dans le tas

C’est dans une interview pour InfoQ que Tim Bray co-auteur du XML nous donne son avis sur les technologies RIA. Selon lui, les RIA type Flex, Silverlight et JavaFx n’ont pour but que de fournir des applications toujours plus immersives et de moins en moins utiles. Il modère tout de même ses propos en s’appuyant sur des exemples de réussite comme Google et Yahoo! qui utilisent de manière élégante Ajax et consort. En bref, pour lui les avantages des interfaces web sont la simplicité et la rapidité, Tim ne croit donc pas en la longévité du RIA. Rien de mieux pour faire de l’applicatif lourd que de l’applicatif lourd.
Dans son interview, il explique rapidement que l’émergence des Web Services et des architectures de type SOA s’est faite en dépit du bon sens. Au début chacun y allait de son format XML privé et ça fonctionnait, mais on a voulu généraliser le problème et fournir une solution pour tous. Cette volonté de créer une pierre philosophale pour exposer ses services n’a apporté que des difficultés d’implémentation, d’intégration et surtout d’interopérabilité. Bref, Tim est assez pessimiste en ce qui concerne les ‘WS-*’, il soutient en revanche REST qui selon ses termes, n’est qu’une reformulation des bonnes pratiques des Web Oriented Architectures.
Enfin, il reste très discret sur Sun et sur le cloud computing en indiquant tout de même que pour le moment le département se cherche un peu. Faut-il fournir des solutions et des outils pour implémenter des nuages ou bien héberger directement des nuages et devenir fournisseur?

L’interview complète sur InfoQ
La réponse de Yakov Fain

SOA

Red Hat JBoss choisit d’investir dans CXF

Red Hat a annoncé la semaine dernière qu’elle devient un « key contributor » du projet Apache CXF.
A terme, comme l’explique Sacha Labourey sur son blog, cela signifie que JBossWS qui laisse aujourd’hui le choix de l’implémentation Web Service (ne fournissant qu’une couche d’abstraction) ne fournira plus que l’implémentation Apache CXF. C’est dommage, d’autant plus que les dernières releases de CXF ont été plutôt douloureuses et riches en bugs.
D’un autre côté, la participation active des équipes JBoss au projet ne peut qu’aider à rectifier le tir. Gageons donc que les futures releases d’Apache CXF seront de bien meilleures factures que celles de 2008.

Le coin de la technique

Enfin une roadmap détaillée pour le JDK7

Lors de la conférence Devoxx de décembre dernier, un keynote avait particulièrement retenu l’attention : Mark Reinhold présentait alors la liste des fonctionnalités qui seraient intégrées au futur JDK 7, ainsi qu’une date pour la version finale.

Mark Reinhold annonce maintenant la mise en ligne d’un calendrier détaillé des milestones prévus et des fonctionnalités associées.

L’analyse de ces informations aboutit à quelques remarques :

La période annoncée en décembre dernier pour l’arrivée d’une version finale, à savoir « début 2010″, est légèrement décalée puisqu’un final milestone est prévu pour le 18/02/2010 suivi d’une phase de release candidate d’un à deux mois. Ceci porterait donc l’arrivée d’une version finale à avril ou mai 2010.
La liste des nouveautés reste globalement inchangée à une exception près : il n’est plus question de MVM (Multiple Virtual Machines) qui devait permettre d’exécuter plusieurs applications au sein d’une même VM. Cette fonctionnalité, particulièrement intéressante dans le contexte du regain d’intérêt pour les Applets Java et autres applications JavaFX embarquées dans le browser, était annotée d’un « maybe » il y a deux mois et était visiblement trop ambitieuse pour résister à la pression du calendrier.
La JSR-310 (Date and Time API) n’avait pas été citée en décembre et ne l’est toujours pas. L’appel à l’aide du spec lead Stephen Colebourne aura donc été vain. En effet, comme il le faisait alors remarquer, dans le cas d’une inclusion au JDK, JDBC et NIO2 seraient impactés afin de prendre en compte la nouvelle API. Compte-tenu de cet impact, il était essentiel que cette JSR puisse être finalisée rapidement. Or son statut, toujours annoncé comme « inactive » par le site du JCP, tend à nous faire penser que la classe java.util.Date a encore de « beaux » jours devant elle.

La création de bundles OSGi selon SpringSource

SpringSource annonce l’arrivée de Bundlor, son outil de création de bundles OSGi, actuellement en version 1.0M2.

Dans un projet OSGi il est en effet nécessaire que l’ensemble des modules de l’application et des librairies tierces soient fournis sous forme de bundles. La création de bundles pour les modules dont on a le contrôle n’est pas un problème en soit, pour les librairies tierces, il en est tout autrement.

Deux possibilités s’offrent alors au développeur : obtenir la librairie qu’il recherche packagée sous forme d’un bundle OSGi sur un repository dédié (celui de SpringSource par exemple) ou créer ce bundle par lui-même. Dans ce dernier cas, il faudra analyser l’ensemble des dépendances de la librairie pour créer un manifest adapté. C’est là que les outils de création automatisée de bundles interviennent. Bnd était le seul disponible jusqu’alors, crée par Peter Kriens, Technical Director d’OSGi. SpringSource amène donc désormais son propre outil.

Bundlor est justifié par SpringSource par quelques fonctionnalités non présentes dans Bnd telles que la création incrémentale de manifests et l’intégration à Eclipse via un plugin dédié.

Malgré l’apparente efficacité de ce type d’outil, il est indispensable de ne l’appliquer qu’à des librairies tierces. En effet un des intérêts d’OSGi réside dans sa capacité à n’exposer qu’une partie soigneusement sélectionnée des interfaces d’un module, ce que seule une intervention humaine sera à même d’effectuer correctement.

Utiliser le nuage pour réduire les coûts d’intégration continue.

Il est de notoriété publique que plus la fin d’un sprint approche, plus les ressources du serveur d’intégration sont sollicitées. En outre, c’est dans ces périodes que les développeurs ont besoin des feedbacks les plus rapides. Alors, que faire ? S’offrir une machine surpuissante, dédiée à l’intégration continue, mais qui ne sera que rarement utilisée à pleine capacité ?
Atlassian, l’éditeur du serveur d’intégration continue Bamboo, propose de résoudre ce problème dans la version 2.2 de son produit, en offrant la possibilité d’utiliser « Elastic Bamboo », un agent distant s’exécutant sur le nuage Amazon EC2. Ainsi, la disponibilité et la puissance sont maximales lorsque l’équipe en a besoin, tout en limitant les coûts.
Et comme Atlassian utilise Bamboo en interne, certains plâtres sont déjà essuyés :

Les builds doivent réellement être indépendants de l’environnement (à vous de construire vos builds en étant conscients de ce problème).
Dans le cas standard, les dépendances doivent être téléchargées à chaque build (l’instance de build disparaissant du nuage lorsqu’elle se termine). Une solution peut être d’utiliser une image disque sauvegardée sur le nuage.

Toutes les astuces de Edwin Wong pour paramétrer votre serveur d’intégration continue sur le nuage se trouvent sur le blog d’Atlassian.

Outils Glassfish pour Eclipse

Sun vient de sortir la version 0.9 (la version 1.0 arrive bientôt) de son bundle.
Celui-ci intègre:

Eclipse 3.4.1
Serveurs Glassfish v 2.1 et v3 Prélude
JDK 1.6 Update 12 (optionnel)
Une série de plugins permettant de configurer votre serveur J2EE, ainsi que vos WebServices (Soap ou Rest) depuis l’IDE. (Plus de détails sur les plugins, ici).

Ce bundle offre l’avantage de fournir un paquet tout-en-un. Il est destiné aux développeurs et aux organisations qui n’utilisent pas NetBeans, mais Eclipse. Celui-ci étant l’IDE le plus répandu. Sun élargit ainsi son public et se rapproche de la grande communauté d’Eclipse.

Revue de Presse Xebia

Xebia France — Mon, 24 Nov 2008 17:58:29 +0000

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

Actualité éditeurs / SSII

OSGi : Spring dm Server standardisé pour l’été 2009 ?

Agilité

La fin de l’Agilité ?

SOA

SOA : de la crise de doute à la désillusion ?

Le coin de la technique

Actualité éditeurs / SSII

OSGi : Spring dm Server standardisé pour l’été 2009 ?

Eric Newcommer, OSGi Enterprise Expert Group (EEG) co-chair, présente dans « OSGi for the Enterprise Gets a Bit Closer & LinkedIn Too » l’avancement de l’EEG qui a pour ambition de faire coïncider la fin de ses travaux avec la sortie d’OSGi R4.2 annoncée pour Juin 2009.

On y apprend que la « RFC 124 / Blueprint Component Model » est quasiment finalisée, son implémentation de référence (RI) est SpringSource dm Server dont elle a repris les principes ; le Test Compatibility Kit (TCK) est développé par le projet Apache Geronimo. Souhaitons que cette standardisation de dm Server permette à SpringSource de reverser le contenu de son Enterprise Bundle Repository dans l’officiel OSGi Bundle Repository de l’OSGi Alliance et que la prolifération de bundles customisés par les grands acteurs de l’OSGi prenne fin.

Par ailleurs, « RFC 119 / Distributed OSGi » serait elle aussi prête. Apache CXF est en charge de la Reference Implementation (Cf. First Ever Demo of Distributed OSGi) et Tibco s’occupe du Test Compatibility Kit. Nous remarquerons que Distributed OSGi reprend certains principes de Service Component Architecture (SCA) et que le positionnement des deux technologies manque encore de clarté. De plus, à la différence de « Blueprint Component Model » avec Spring dm Server, Distributed OSGi ne connaît pas encore de « vraie » implémentation.

Agilité

La fin de l’Agilité ?

Le prix du buzz de la semaine revient incontestablement à James Shore pour son article The Decline and Fall of Agile. « Jim » raconte qu’il a noté un changement dans son métier : avant on l’appelait pour introduire les méthodes agiles sur les projets, aujourd’hui on l’appelle pour secourir des projets soi-disant « agiles ».
Et par « agile » la plupart des clients entendent Scrum, la méthode la plus répandue. Il reproche à Scrum son silence sur les pratiques d’ingénierie logicielle à mettre en place (contrairement à XP), pourtant indispensables à la viabilité d’un projet. Il critique également la Scrum Alliance et son système de certification ScrumMaster qui donnent l’impression que l’agilité est facile. La nature humaine nous incite à ne choisir que les côtés agréables (les sprints et les daily scrums) mais nous ignorons les côtés plus difficiles, qui sont aussi les plus importants : équipe co-localisée, auto-organisée, produit livrable à chaque fin d’itération, élimination des obstacles.

Cet article a déclenché de vives réactions dans la communauté agile, certaines un peu puériles, d’autres plus constructives. Sur InfoQ par exemple, le Gartner Hype Cycle est évoqué pour expliquer ce déclin. Après un pic d’attentes irréalistes concernant une technologie, celle-ci traverse un creux de désillusion avant de remonter pour atteindre son plateau de productivité. Les méthodes agiles traverseraient-elles actuellement ce creux ?

Le Touilleur cite Rob Bowley qui fait le rapprochement entre la déception de Scrum et l’engouement récent pour le Lean Software Development. Il prédit pourtant que le Lean subira le même sort que Scrum, pour les mêmes raisons. Selon lui peu importe la méthode, il y a toujours des personnes qui se concentrent sur les outils plutôt que sur les vrais problèmes. Ces personnes, qui échouent avec Scrum aujourd’hui, échoueront avec le Lean demain.

SOA

SOA : de la crise de doute à la désillusion ?

Nous évoquions en Mars dernier dans « 2008, annus horribilis de la la SOA ?« la crise de doute qui s’emparait du Burton Group, grand chantre de la SOA. La crise s’accentue aujourd’hui avec l’autre évangéliste de SOA, le Gartner Group, qui nous gratifie de Ahh Shucks, SOA Is A Failure (Frank Kenney). À croire que le Gartner Group s’applique son célèbre Hype cycle et, après avoir loué SOA, tombe en pleine phase de désillusion.

Est-ce pour autant la fin de SOA ? Certainement pas, des ouvrages comme Enterprise Integration Patterns ou Developing in a Service-oriented World (Gregor Hohpe, Google) ont beaucoup apporté à l’intégration des Systèmes d’Information.

Quant aux cabinets de conseils qui ont parfois manqué de pragmatisme, ils ont trouvé des nouvelles marottes avec les architectures du moment : Representational State Transfer (REST) et Web Oriented Architecture (WOA) (Cf. Gartner – WOA: Putting the Web Back in Web Services ou Burton Group : The Tao Of REST), sans oublier les promesses mirobolantes du Software As A Service (SaaS) et du Cloud Computing !

Le coin de la technique

Seam 3 : les futures orientations de Seam

Gavin King, créateur d’Hibernate et Seam, présente les futures orientations de Seam3.

Il indique que Seam 2 était une première couche. Cette couche a pour responsabilité de gérer des composants à état, configurables et injectables pour le développement d’applications Web riches. Il permet de s’abstraire du code « glue » que l’on doit faire pour intégrer différentes technologies (JSF, JPA, …). Cette première couche est focalisée sur l’intégration de services à état côté serveur et sur la réalisation d’interface graphique (par défaut avec JSF).

Seam 3 ajoutera une seconde couche, qui aura pour responsabilité de faire de WebBeans le coeur de Seam, d’améliorer l’intégration de la sécurité, de Drools et jBPM. L’idée est de faire de Seam 3 un framework d’infrastructure basé sur Web Beans. Seam 3 permettra donc l’intégration de moteur de workflow et de moteur de règles qui devrait apporter de nouveaux outils pour la conception et la réalisation d’applications.

Seam 3 pourrait conduire à une réécriture de Seam 2 afin d’intégrer Web Beans.

A noter que le 2 décembre 2008 se tiendra une soirée JBoss au Paris JUG, dont la deuxième partie sera entièrement consacrée au framework Seam.

Sortie de Netbeans 6.5

Netbeans.org annonce la sortie de son IDE NetBeans 6.5 : NetBeans.org is proud to announce the availability of NetBeans IDE 6.5!.

Cette nouvelle version met à disposition des développeurs :

le debug Javascript dans Internet Explorer et Firefox,
le développement JavaFX (compilation, déploiement, prévisualisation, édition, …),
l’intégration de Glassfish V3 Prelude (possibilité de scripter en JRuby),
un plugin pour le développement en python : NetBeans IDE for Python EA Download,
l’amélioration et l’intégration de nouvelles technologies de développement : PHP, Groovy / GRails, Ruby (RoR – Ruby On Rails, rake),
et bien d’autres : NetBeans IDE 6.5 Release Information, NewAndNoteWorthyNB65.

Netbeans s’avère une alternative de plus en plus crédible à Eclipse. Il possède des avantages non négligeables par rapport à ce dernier : meilleur support Javascript (et du développement Web avec PHP), support de Python, JavaFx, etc.

Pour plus d’informations, voici quelques screencasts qui montrent le fonctionnement de Netbeans : NetBeans IDE 6.5 Released; Introductory Screencast Released.

Sortie de SOAP UI 2.5

SoapUI est un outil graphique pour tester les services web. Il permet d’inspecter, invoquer, développer, créer des tests de charges et des tests fonctionnels sur des services web. Il apporte aussi des plugins pour Eclipse, IntelliJ IDEA et NetBeans.

SoapUI 2.5 apporte un grand nombre de fonctionnalités :

Inspection et invocation :
- Importation et analyse de fichiers WSDL.
- Appel des différentes opérations d’un service web.
- SSL / authentification / sécurité WS.
Développement et validation :
- Génération de stubs client et serveur pour les frameworks les plus populaires : Axis 1.x/2.x, XFire / CXF, JWSDP, Oracle, .NET, GSoap, JBossWS.
- Génération de XML bindings pour JAXB et XMLB.
Tests fonctionnels :
- Génération de séries de tests et de testcases sur la base du WSDL.
- Utilisation de scripts « Groovy » pour l’exécution de tests.
Tests de charge :
- Établissement de tests de charge à partir de testcases fonctionnels.
- Établissement d’assertions, tant au niveau de la performance que de la fonctionnalité.
- Analyse de performance pour des scénarios variés..

Pour voir la liste complète des fonctionnalités, rendez-vous sur le site du projet.

Très facile d’utilisation, SoapUI devient de plus en plus un leader incontournable dans le test des services web en open source. Il existe en version gratuite et open source et en version payante appelée « SoapUI Pro ».

Vous pouvez télécharger l’outil, ou l’utiliser directement avec le déploiement Java Web Start. Java 1.5 est indispensable à son utilisation.

Survol de l’architecture MySpace

InfoQ poursuit sa série sur les architectures des grands du Web 2.0, avec l’interview de Dan Farino, architecte principal du site communautaire MySpace.

Nous entrerons probablement moins dans les détails de cette architecture pour la bonne et simple raison que MySpace est l’un des seuls site internet de cette taille à tourner sous .Net. Cependant, les grands principes de performances qui permettent au site communautaire de gérer plusieurs millions de visiteurs par jour, et un contenu en constante augmentation, s’appliquent à n’importe quelle technologie.

Mettre l’accent sur l’automatisation : avec des fermes comportant plusieurs centaines de serveurs (300 serveurs web IIS frontaux par exemple), il est vital que toutes les opérations d’administration des serveurs soient automatisées à une large échelle.
La détection des anomalies est la première étape nécessaire à l’amélioration des performances : à cette fin, Dan Farino a dû écrire un outil de supervision sur mesure permettant de ‘tracer’ chaque requête à travers les centaines de serveurs de l’architecture. Cette problématique est relativement courante.
Pour chaque problème de performance ou de scalling détecté, l’équipe d’architectes de MySpace a favorisé la solution sur mesure aux nombreux outils ‘génériques’ proposés par Microsoft. On notera en particulier :
- Le développement d’un système de cache spécifique, afin de s’affranchir des problèmes (connus) de GarbageCollection en .Net, et afin d’alléger la charge pesant sur les serveurs de DB.
- Le développement d’un serveur de fichiers, en Linux, permettant d’adresser les fichiers aux utilisateurs finaux directement en HTTP, et gérant la redondance des fichiers audio, video (qui sont la vraie valeur ajoutée de MySpace).
- Le développement d’un système d’introspection du code .Net en temps réel (mesure des temps d’appels, des allocations mémoire, levée d’exception, …) écrit en C++ (afin de monitorer le code .Net de la manière la plus indépendante possible).
- La création d’un système de ‘load balancing’ spécifique, permettant de rapidement isoler un serveur défaillant et de n’impacter qu’un minimum d’utilisateurs.

Et bien sûr, MySpace respecte un principe que nous avons maintenant rencontré dans tous les sites gérant un trafic ou un contenu important, le partitionnement horizontal et vertical des bases de données, en fixant une limite d’un million d’utilisateurs par DB.

Les autres épisodes de la série disponibles sur notre blog :

Oracle sort son Incubateur Coherence

Oracle tente d’élargir la communauté ‘Coherence’ après l’ouverture du mois dernier de son nouveau site web Coherence Incubator. Veillez à ne pas comparer celui-ci à l’incubateur Apache, son fonctionnement est tout autre. ‘Coherence Incubator’ a été créé dans le but de regrouper un ensemble de projets d’exemples, chacun d’entre eux proposant une implémentation de référence pour un cas d’utilisation standard de l’outil. Il s’agit donc d’un ensemble de bonnes pratiques validées par Oracle. Oracle espère par ce biais faciliter l’accès à son outil.

Pour mémoire, Oracle Coherence se positionne comme l’une des solutions les plus complètes de grilles de données distribuées. Il permet de clusteriser vos applications sur un environnement hardware évolutif. Par exemple, l’ajout et la suppression de machine s’effectuent sans contrarier la réplication, la distribution et le cache de données au sein du cluster.

Un mois après sa sortie, l’incubateur Coherence contient les projets suivants :

coherence common : un regroupement de classes utilitaires et bonnes pratiques. Utilisés par les autres projets de l’incubateur.
Implémentation distribuée du command pattern.
Implémentation du functor pattern. Il s’agit d’une extension au ‘command pattern’ qui permet de renvoyer à l’appelant des valeurs de retour et des exceptions.
Implémentation partielle du pattern messaging. Messages non persistés, managés en mémoire par Coherence.
Implémentation du pattern Push Replication. Propagation des modifications des données, réplication.

Si le contenu de cet incubateur n’est pas encore très impressionnant, il aura le mérite de servir de bon point de départ aux futurs nouveaux utilisateurs de Coherence. Le nombre de cas d’utilisation est encore très faible ; reste à savoir à quelle vitesse Oracle enrichira-t-il celui-ci. Après un mois d’utilisation, seul un nouveau projet a été créé.

OSGi au Paris JUG – Slides de la présentation

Xebia France — Thu, 16 Oct 2008 18:59:11 +0000

Cyrille Le Clerc et Nicolas Griso, Xebia, ont présenté OSGi, prêt pour Java EE ? au Paris JUG d’Octobre.

Nous tenons à remercier les participants d’avoir fait le déplacement, les organisateurs Antonio Goncalves, David Dewalle et Zouheir Cadi pour leur accueil toujours aussi chaleureux et tous les bloggers qui ont relayé cette soirée.

Nous souhaitons à Didier Girard et Jérôme Louvel une assistance aussi nombreuse pour la soirée GWT du Paris JUG de Novembre .

La blogosphère en parle

Le Touilleur Express : Présentation d’OSGI au Paris JUG : naphtaline et peinture fraîche
Eric Le Merdy (Valtech Blog) : Back from OSGi at ParisJUG
Tom’s quest : OSGi : oui mais non
Ruchika Goyal (Xebia Hollande) qui relate lui aussi son expérience OSGi dans Experimenting with OSGi on Server Side

La présentation

Télécharger en PDF

Le plan

Pourquoi la modularité ?
La modularité en Java
- L’existant
  - Les jars
  - Les classloaders hiérarchiques
  - Maven 2
- Le futur
  - Java Module System
  - OSGi / JSR 291 : Dynamic Component Support for Java SE
OSGi Alliance
- L’histoire
- Le fonctionnement
- OSGi Alliance et le JCP
La plateforme OSGI
- Les bundles
- Le réseau de classloader
- Le conteneur
- Le cycle de vie des bundles
- Le Service Registry
- L’assemblage des services
  - BundleActivator et ServiceTracker
  - Declarative Service
  - RFC 124 – A Component Model for OSGi (aka Spring DM)
- Les services standards
Demo
- Import d’un service
- Exposition d’une servlet : le HttpService
- Upgrade à chaud d’un bundle
- Log4j !
OSGi dans le monde Java EE
- Client side
- Server Side
Bonnes pratiques OSGi
Les enjeux d’OSGi pour Java EE
Conclusion : OSGi, prêt pour Java EE ?

Rendez-vous le mois prochain au Paris JUG !

Revue de Presse Xebia

Xebia France — Mon, 13 Oct 2008 17:14:30 +0000

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

Actualité éditeurs / SSII

Agilité

RIA

Le coin de la technique

JSR-277 : OSGi m’a tuer (Stanley Ho)

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

Paris JUG : soirée OSGi

Actualité éditeurs / SSII

SpringSource : sortie par le haut

Comme nous l’annoncions succinctement mercredi, SpringSource a revu sa copie concernant sa nouvelle politique de maintenance abandonnant de ce fait les points les plus polémiques de celle-ci, dont sa fameuse règle des trois mois à l’origine des levées de boucliers de la communauté.

Dans son post de mardi dernier, Rod Johnson dévoile donc le nouveau fonctionnement de celle-ci : les releases seront disponibles pour la communauté jusqu’à la sortie d’une nouvelle version majeure. Ainsi, les binaires des versions 2.5.x du cœur du framework continueront d’être publiés tant que Spring 3.0 RC1 n’est pas disponible. SpringSource compte, par ce biais, inciter la communauté open-source à toujours coller aux dernières versions de son framework.

Websphere: les derniers seront les premiers ?

Dernier serveur certifié Java EE 5, Websphere ressort grand vainqueur d’une étude comparative des principaux serveurs d’application du marché, menée par Evans Data Corporation (rapport gratuit, mais enregistrement nécessaire).

Cette étude soulève déjà de nombreuses questions chez les concurrents (comme Rick Sharples, de JBoss), le marketing d’IBM n’allant pas se plaindre d’une si belle vitrine.
Rick émet 3 interrogations majeures :

Comment comparer des serveurs d’application dont les communautés peuvent varier d’un noyau de type ‘niche’ (SAP) à des super-communautés mondiales (IBM, BEA, RedHat ou Microsoft) ?
Pourquoi n’arrive t’on pas à corréler les résultats de cette étude avec ceux d’autres études publiques, voire internes, sur JBoss ?
Pourquoi évalue t’on un serveur aussi confidentiel que Geronimo (lui aussi chez IBM) ?

Pour notre part, nous émettons un certain nombre de réserves :

L’étude ayant été menée durant l’été 2008, elle ne peut nécessairement pas porter sur WAS 7.0, sorti officiellement en septembre (d’autant plus qu’un des points de l’étude porte sur le support, qui n’est pas assuré pour les versions beta). Cette étude porte donc plus globalement sur ‘les marques’, plutôt que sur les dernières versions des serveurs d’application cités.
Les consultants Xebia ont l’habitude de travailler avec bon nombre de ces serveurs d’application, et au petit jeu des comparaisons directes (ce qui n’est pas le cas de cette étude), les avis sont loin d’être aussi tranchés.
La rédaction du rapport est très orientée ‘marketing’, ce qui est étonnant au vu de la population consultée. Il est étonnant de lire des phrases telles que « WebSphere’s users obviously love this product. » venant de développeurs qui n’ont souvent pas le choix de leur serveur d’application (souvent dicté par les achats groupe ou l’exploitant) et qui ont tendance à ne faire que « subir » ses désavantages.

Alors, étude téléguidée par un éditeur ? Enième conflit d’intérêt pour un cabinet d’analyse dont les clients sont les premiers sujets de comparatifs ? La réponse est sûrement plus complexe et on peut tout au plus tirer quelques enseignements de ce travail :

JBoss joue définitivement dans la cour des grands, et est un concurrent sérieux pour les « grands » serveurs d’application, même sur des applications à grande échelle.
la communauté s’inquiète du rachat de BEA par Oracle (peut-être est-ce même la raison principale de cette 7ème place).
Le « petit jeune », Glassfish, qui remporte l’adhésion des développeurs pour sa facilité de mise en oeuvre, n’est pas en reste sur les fonctions principales (performances, scalabilité) et vient titiller les vieux mastodontes.
La comparaison objective de serveurs d’application, dans un environnement aussi hétéroclite que celui des SI du XXIeme siècle, avec des problématiques variées et complexes, est un exercice dangereux, qui porte rapidement à critique.

Agilité

Prioriser le Product Backlog

En Scrum, il faut ordonner les éléments du Product Backlog pour que l’équipe sache quelles sont les fonctionnalités à implémenter en priorité.
Peter Stevens propose différentes stratégies pour prioriser le Product Backlog, à composer selon le contexte du projet :

Ensemble minimum de fonctions : faire une liste minimum des fonctions à implémenter pour que le produit soit utilisable et accepté par les utilisateurs
Valeur métier en premier : se concentrer sur les fonctions à haute valeur ajoutée métier. La valeur métier (typiquement avec un coefficient entre 1 et 100) est fixée par le Product Owner.
En avoir pour son argent : semblable à la précédente approche, elle se concentre sur les éléments qui ont le meilleur rapport valeur métier/coût.
Risques techniques en premier : préconisée par RUP, cette approche s’attaque aux points techniques difficiles en premier. Cela peut cependant conduire à un système trop complexe par rapport aux besoins.
Reporter le risque : s’attaquer aux difficultés en dernier (ou jamais). Préférer les stories bien comprises, tout en investigant les stories plus risquées/coûteuses pour les décomposer.
Votes des utilisateurs : demandez aux utilisateurs de voter parmi une liste de fonctionnalités potentielles.

Ce dernier point peut être accompli par une analyse de Kano comme le propose Mike Cohn dans sa présentation Prioritizing Your Product Backlog mise en ligne sur InfoQ. Le pdf est également disponible.
Mike Cohn y présente plusieurs techniques de priorisation, plus concrètes mais nécessitant plus de calculs :

Analyse de Kano : distinguer les thèmes selon 3 types : fonctions obligatoires, linéaires, et attractives. Implémenter toutes les fonctions obligatoires, le plus de linéaires possible et quelques excitateurs pour la satisfaction utilisateur.
Theme screening : noter les thèmes selon certains critères de sélection, par rapport à un thème de référence.
Theme scoring : semblable au Theme screening en pondérant les critères de sélection
Relative weighting : pour chaque thème, calculer le rapport entre sa valeur relative (aux autres thèmes du product backlog) et son coût relatif. Ce rapport donne la priorité du thème.

Ces techniques s’appliquent toutes au niveau thème, car descendre au niveau user story demanderait trop de travail sur un product backlog complet.

Leçons de management par la NASA

Jerry Madden, un ancien employé du Goddard Space Flight Center de la NASA, a collecté « 100 leçons » apprises auprès des managers qu’il a cotoyés.
Marios Alexandrou en a extrait les leçons qui collent le plus avec son expérience des projets web. Parmi les plus marquantes :

Une réunion de travail devrait durer 5 minutes minimum (moins elle est inutile) et 1 heure maximum (plus c’est un marathon). Au-delà de 6 personnes, elle devrait être réservée au transfert d’information.
Ne demandez jamais à vos chefs de prendre une décision que vous pouvez prendre vous-même, sauf si un document vous l’interdit.
Ne supposez jamais que quelqu’un a fait quelque chose, demandez lui. Même le plus évident peut être oublié, surtout en période de stress.
La documentation ne remplace pas la connaissance. Les documents restent des images statiques dans le temps et sont rapidement dépassés.
Les projets nécessitent un travail d’équipe pour réussir. Rappelez-vous que la plupart des équipes ont un coach et non un boss, mais le coach doit parfois arbitrer certaines parties.
Si un chef de projet est l’homme le plus intelligent de l’équipe, c’est qu’il a fait un mauvais travail de recrutement.
Les principes de gestion sont toujours les mêmes. Seuls les outils changent. Vous devez toujours trouver les bonnes personnes pour faire le travail et rester à l’écart pour qu’ils puissent le faire.

Il est amusant de constater certaines similitudes avec les méthodes agiles. Les individus et leurs connaissances sont plus importants que la documentation. Le coach doit s’appuyer sur une équipe de personnes motivées, intelligentes, et responsables qui n’attendent pas d’ordre d’un patron. Leur collaboration est essentielle à la réussite du projet. Ces ressemblances sont logiques finalement, il s’agit simplement de bon sens.

RIA

10 choses à savoir sur Flex

Les articles recommandant Flex se succèdent. Après l’annonce d’Atos sur son blog Entreprise 2.0 du choix de Flex sur plusieurs projets pour de grands comptes et la « victoire » de Flex lors de notre RIA Contest, c’est au tour de Alaric Cole, l’auteur de « Learning Flex 3″ de lister 10 avantages à l’utilisation de Flex.

Alaric Cole est partie prenante, et on a déjà pu lire sur d’autres blogs les différents points cités, mais l’article a l’avantage de les regrouper :

Flex s’apparente aux standards d’une application Web : MXML est un langage de balises comparable à l’HTML, l’ActionScript est l’équivalent du JavaScript. Le tout customisable avec du CSS.
Flex = Flash : tout ce qui était possible en Flash l’est en Flex. Flex apporte cependant une couche de structuration/méthodologie par rapport à Flash
Une application Flex fonctionne sur tous les navigateurs et tous les OS (Linux 64bit ?). La seule contrainte est d’avoir déployé le plug-in d’exécution.
Le framework RIA d’Adobe accepte l’échange de données et propose des interfaces de communication avec plusieurs formats d’échange (SOAP, HTTP, AMF…)
Une application Web Flex aura un « Look And Feel » identique quelque soit l’OS client
Flex est léger et rapide grâce notamment aux améliorations du futur plug-in Flash 10. Par exemple, la fonctionnalité de « Framework Caching » permet de réduire à 100Ko la taille de l’application à télécharger
Les composants de Flex sont nativement construits pour être accessibles (loupe, internationalisation, raccourcis clavier…)
Le contenu d’une application Flex peut maintenant être indexé par un moteur de recherche
Le SDK Flex est maintenant OpenSource et gratuit mais attention l’IDE Flex Builder est payant.
Enfin, il rappelle la facilité d’apprentissage du langage. Pour un habitué de la Javadoc, l’accès au format ASDocs d’Adobe est cependant déroutant les premiers temps.

Même si l’ancienneté de Flex sur le marché, la couverture de déploiement de son plugin d’exécution et la solidité de son distributeur Adobe semblent placer Flex en tête du tournoi RIA, il est bon de rappeler que la compétition ne fait que commencer : 2 outsiders sérieux (Silverlight et JavaFx) vont bientôt s’élancer dans la course ! L’avance prise par Flex pourra t-elle être comblée ?

GraniteDs en version 1.1.0

GraniteDS est un framework opensource équivalent à BlazeDS, simplifiant le développement des communications entre un RIA Flex et un serveur J2EE. Cet article d’InfoQ nous présente les nouvelles fonctionnalités disponibles sur GraniteDS 1.1.0:

Granite Eclipse Builder : un plugin Eclipse basé sur AS3 Generator permettant de générer le code ActionScript 3 associé aux JavaBeans. Ce plugin génère automatiquement du code lorsqu’un JavaBean est modifié.
Tide : ce framework fournit des fonctionnalités telles que la mémorisation d’objets dans un contexte qui transite entre la partie cliente et la partie serveur, la pagination des données. Il permet également de gérer le lazy loading des collection en wrappant les collections et en les récupérant dés que c’est nécessaire.
MXML Web Compiler : une compilation à la volée du code source MXML et ActionScript 3 sur le serveur d’application.

Avec cette nouvelle version, GraniteDS se positionne comme un concurrent sérieux de BlazeDS. La génération des JavaBeans, la gestion du lazy loading et la compilation à la volée sont des points forts qui séduiront très vite les développeurs. Cette nouvelle approche ne peut que faciliter et améliorer le développement d’applications Flex.

Le coin de la technique

JSR-277 : OSGi m’a tuer (Stanley Ho)

Stanley Ho a annoncé son départ de Sun Microsystems. Par la même occasion, il laisse les clés de la JSR-277 dont il était à la tête. C’est donc Alex Buckley qui reprend le flambeau, il était déjà responsable de la petite sœur, la JSR-294 : les superpackages.

Nous sommes en droit de nous demander si la création du prototype permettant l’interopérabilité entre Java Module System et OSGi qu’a amorcé Sun ces derniers mois a quelque chose à voir avec ce départ. Quoi qu’il en soit, le tournant est définitivement engagé pour le futur de Java Module System.

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

Paris JUG : soirée OSGi

Dernière piqûre de rappel pour la soirée OSGi de ce mardi 14 octobre au Paris JUG.

Le programme est disponible ici : première partie ‘introduction à OSGi’, seconde partie : ‘OSGi appliqué’
Les inscriptions sont gratuites et ouvertes à tous, enregistrez-vous ici
La soirée aura lieu à l’ISEP, dont voici le plan d’accès

Nous vous y attendons nombreux.

Paris JUG : Soirée OSGi le 14 octobre

Xebia France — Tue, 07 Oct 2008 09:53:18 +0000

La prochaine soirée du Paris JUG aura lieu le mardi 14 octobre 2008 dans les locaux de l’ISEP.

Cette soirée sera consacrée à OSGi et sera animée par Cyrille Le Clerc et Nicolas Griso de Xebia.

Au programme :

19h15 à 19h30 : Accueil

19h30 à 20h30 : Introduction à OSGI

La naissance de ce standard extérieur au JCP
La gouvernance de l’OSGI Alliance et les relations avec le JCP
Les champs d’applications d’hier, d’aujourd’hui et demain (Enterprise Expert Group)

20h30 à 21h : Buffet

21h à 22h : OSGI appliqué
Côté client graphique, côté serveur. Quelles promesses, quelle valeur ajoutée, quels défis ?
Côté client, les applications RCP imposent OSGI, est-ce vraiment une plus value pour les développements ?
Côté serveur :

OSGI en socle des middlewares : Websphere, Weblogic, Glassfish et ServiceMix 4
OSGI pour l’informatique de gestion :
- pour les ESB/EAI : OSGI comme technologie d’assemblage là où JavaEE n’a pas légiféré
- pour les applications Web en alternative au standard .war de Java EE

22h à … : 3ème mi-temps des juggers

Pour participer à la soirée OSGi, inscrivez-vous ici.

Revue de Presse Xebia

Xebia France — Mon, 06 Oct 2008 17:45:39 +0000

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

Actualité éditeurs / SSII

Sortie officielle de SpringSource dmServer

Agilité

RIA

Framework RIA : où en est-on?

Le coin de la technique

Actualité éditeurs / SSII

Sortie officielle de SpringSource dmServer

L’actualité SpringSource ne faiblit pas, à chaque semaine 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 technique : l’arrivée en GA (General Availibility) de son serveur d’applications OSGI ‘dmServer’.

Il s’agit en fait de la sortie officielle de son produit anciennement appelé S2AP (SpringSource Application Platform) annoncé depuis mai dernier dont les versions bêta se sont succédées cet été. Le produit a été renommé en dmServer lors de l’arrivée de la RC2 en Septembre dernier, S2AP existe toujours comme terme plus générique. Il désigne ce serveur d’applications dmServer ET son ensemble d’outils, de services et de supports : SpringSource Enterprise

Pour revenir à la sortie de dmServer, celui-ci se présente comme un serveur d’applications modulaire basé sur OSGI dont voici les principaux bénéfices :

pour le développeur, l’approche modulaire permet d’améliorer la réutilisation du code et de faciliter le développement itératif sans trop dépendre d’un serveur d’applications particulier
pour la production, dmServer propose des fonctionnalités de mises à jour applicatives et serveur automatisées, une compatibilité avec des environnements grid et virtualisés et une meilleure utilisation des ressources. Embarquant Tomcat, il reste également compatible avec les anciennes applications Web.

Pour terminer les nouveautés SpringSource, notons également la sortie de Spring Security 2.0.4 disponible en téléchargement, il s’agit de la première release post 3 mois Open Source de SpringSource depuis qu’ils ont annoncé qu’ils arrêtaient d’en faire

Agilité

Sprint zéro

Dans ces articles de Claude Aubry et de Mark Levison, ceux-ci nous expliquent en quoi consiste ce sprint. Il contient entre autres en la définition backlog initial, la définition des users stories, la priorisation des items… Mais ce sprint est aussi consacré à la mise en place des environnements de travail, à la définition d’architectures (si celles-ci ne sont pas définies), à la mise en place d’un prototype…
La difficulté est que ce sprint n’a pas vraiment de durée, mais il est judicieux de la maintenir la plus courte possible, car rien n’est produit au final (pas de produit utilisable à la fin, pas de mesure de la vélocité…).
Alors peut-on parler effectivement de Sprint zéro (et donc intégré à Scrum) ou bien de phase préparatoire ? Le débat est ouvert.

Méthodes agiles et développement de Google Chrome

Darin Fisher, membre de l’équipe de développement de Chrome, expose sur SearchSoftwareQuality.com les grands principes qui ont prévalus pour le développement du navigateur de Google.
Même si le décor est planté dès la première phrase (« Nous n’avons pas spécifiquement utilisé la méthodologie Agile, nous avons juste fait appel à notre bon sens »), il est intéressant de voir que la méthodologie Agile et le bon sens selon l’équipe de développement de Google Chrome ont de nombreux points communs:

Les équipes étaient auto organisées, chacun décidant des taches qu’il accomplirait.
Le développement était organisé en sprints (longs) d’un trimestre, mais une version stable était mise à disposition des utilisateurs toutes les semaines.
Le pilotage était réalisé via une liste de fonctionnalités (précises et minimalistes) ordonnée (incontournable, secondaire…), enrichie par les retours des utilisateurs (via une mailing list interne).
Une grande partie du test a été automatisée.
Dans une certaine limite, le développement a pu être distribué.

Google n’a visiblement pas systématisé son usage, mais utilise déjà Scrum sur certains projets, en particulier pour le développement de sa « cash machine », Adsense…
Jeff Sutherland a récemment donné une conférence sur Scrum dans les locaux de Google NYC

RIA

Framework RIA : où en est-on?

Il y a quelques jours, nous vous proposions un point sur les frameworks RIA à la suite d’un contest : Xebia RIA Contest.

Glen Lipka, designer Web, propose aussi un point sur l’état des frameworks RIA : RIA frameworks. Il est intéressant de comparer les deux points de vue, si nous sommes spécialistes Java (Xebia), Glen Lipka est designer Web.

Il existe d’autres comparatifs : par exemple JSF matrix qui compare différentes technologies Ajax qui peuvent être utiliser avec JSF.

Etant donné le profil technique de Glen Lipka, il a une préférence pour le framework JQuery. Il est vrai que JQuery apporte une solution simple et élégante au développement JavaScript :

Syntaxe élégante et fonction utilitaire (appel ajax, effet ergonomique, …)
Simplification de la manipulation de l’arbre DOM et de la gestion des événements DOM
Système de plugin pour étendre le comportement de JQuery : manipulation en Ajax de formulaire, composants graphiques (Carrousel, animation, …)

JQuery est un bon compromis entre simplicité et puissance. Au prix d’une complexité supérieure, Ext-JS s’annonce comme une solution plus complète. Il existe d’ailleurs une version Ext-JS pour GWT : Ext-GWT. Il faut néanmoins une licence commerciale pour les applications propriétaires.

Il y a d’autres concurrents de qualité :

Yahoo UI Library
Dojo toolkit mais reste assez complexe
OpenLazlo mais il est architecturalement compliqué et sa syntaxe freine aussi bien les Java-istes que les développeurs Web
Technologies Rails : Ruby On Rails (ROR), Grails (Groovy) ou encore Django (Python) se base sur des concepts très pragrammatiques (« convention over configuration« , « don’t repeat yourself« )

Il y en a de toutes les couleurs dans les frameworks RIA :

Avec/sans développement JavaScript
Pour designer ou autre
Dans des langages interprétés ou compilés (voir même intermédiaires comme GWT)
Dans des technologies inexplorées (Ruby, Groovy, Python)

Le choix est difficile mais les solutions s’orientent vers :

Un modèle de programmation simple et productif (selon les compétences des utilisateurs, c’est un point difficile car on est à cheval sur deux domaines (vastes) de compétences, le développement Web et le développement d’applications de gestion)
Richesse des composants graphiques (qui est par exemple le point fort de Flex)
L’intégration avec l’existant qui est souvent négligé dans les solutions comme le montre Ruby On Rails ou Grails même si elles ont un modèle de programmation très intéressant, ou à moindre mesure GWT.

Liens connexes :

Discussions de cet article sur TSS : The Server Side

Le coin de la technique

EJB 3.1 se dévoile

Un peu plus d’un an après le lancement de la réflexion sur l’évolution des EJB 3.0, de nouvelles spécifications viennent d’être rendues publiques.
Toujours dans la droite ligne d’une simplification de l’utilisation des EJB, voici un aperçu des nouveautés les plus attrayantes :

Les EJB locaux ne nécessitent plus l’utilisation d’une interface, une simple classe concrète suffit.
Un sous ensemble allégé, les « EJB Lite » directement déployables dans un war (sont notamment exclus les Message Driven Beans, l’exposition Web Services et le remoting RMI/IIOP).
Un nouveau type d’EJB Session vient de naître: le type Singleton, qui rappelle beaucoup les singletons Spring.
Un mécanisme d’événement pour lancer des traitements au démarrage et à l’arrêt du conteneur EJB.
Pour simplifier les tests unitaires, on peut désormais exécuter un conteneur d’EJB dans une simple JVM sans nécessiter de serveur d’application.
Un accès JNDI global permet d’accéder aux EJB sans besoin de spécifier un descripteur de déploiement.
Un EJB peut être invoqué de manière asynchrone.

Dans les spécifications de Java EE 6, il est souhaité que la réduction des « lourdeurs » de l’API EJB soit faite de la manière la plus douce pour les développeurs. Cette publication va dans ce sens, dans le sens d’une facilité d’utilisation qui s’approche du framework Spring.
Pour tout savoir sur cette publication, il faut consulter la JSR-318 et pour mieux comprendre, par l’exemple, la présentation de Kenneth Saks avère très utile.

Pour l’amélioration de la qualité, gérez vos dépendances

Kevlin Henney présente dans l’article Manage component dependencies for improved system quality un autre aspect de la QoS en développement logiciel qui est : la gestion des dépendances.

La gestion des dépendances permet de réaliser une application plus modulaire, donc moins monolithique. Quelques bonnes pratiques à suivre :

Structurer le logiciel sous forme de module cohérent, défini, suffisant et distinct (Separation of Concern (Dijkstra))
Identifier les impacts lorsqu’un module est modifié, et donc de mieux analyser les coûts et risques d’une modification sur l’ensemble du logiciel
Mettre en place de bonnes pratiques de conception :

Open Closed Principle (OCP) : Un module doit être ouvert aux extensions mais fermé aux modifications.
Inversion Of Control (IOC) : Permettre l’isolation des modules. Les modules de haut niveau ne doivent pas dépendre de modules de bas niveau.
Acyclic Dependencies Principle (ADP) : Le graphe des dépendances doit former un graphe acyclique.
Stable Dependencies Principle (SDP), Stable abstractions Principe (SAP) : Un module doit dépendre de modules plus stables que lui, les modules les plus stables sont les plus abstraits.

Actuellement, il existe des outils pour gérer les dépendances au niveau librairie (Maven2, Ivy), pour réaliser une application modulaire, on applique une solution packaging.

Il existe d’autres types de solution : OSGi et Java Module (JSR 277). Dans ce cas, c’est une infrastructure de modules qui est utilisée pour exécuter les différents modules et former une application.

Pour le développement d’applications modulaires, il n’ y a pas encore de solution technique miracle, elle se repose fortement sur la bonne conception fonctionnelle et technique : la mise en oeuvre des principes avancés de conception objet.

Liens connexes :

Design-up : Principes avancés de conception objet (PDF) : explication des principes OCP, IOC, ADP, SDP, SAP, …

Les dessous d’InfoQ

Alexandru Popescu, architecte en chef du site InfoQ, dévoile l’architecture du célèbre site d’information, qui culmine à plus de 300 000 visiteurs uniques par mois. De ce vidcast, nous retiendrons :

InfoQ est une entreprise virtuelle, et elle utilise les méthodologies Agile pour son développement (dont un backlog long de sept pages, ce qui nous promet de très nombreuses évolutions)
InfoQ est un CMS complet et fait maison. Le site est découpé comme une application trois tiers classique. Les API ‘utilisateur’ et ‘auteur’ sont quasi identiques et sont séparées durant la phase de build.
L’application repose sur WebWork et DWR pour la navigation. Une API spécifique redirige la requête vers le framework ad-hoc (WebWork pour les requêtes classiques, DWR pour les requêtes Ajax). Cette API a été reversée dans le repository de DWR, et peut être utilisée avec Struts 2 par exemple.
Au niveau Service, on a majoritairement du Spring ‘classique’
Au niveau persistance, un mécanisme original, puisqu’InfoQ s’appuie à la fois sur Hibernate et JCR. C’est d’ailleurs le seul regret d’Alexandru Popescu, ne pas avoir une API de haut niveau qui permet à ses développeurs de s’affranchir du mode de stockage.
Toute cette architecture repose sur une base MySql distribuée (une instance en lecture écriture, plusieurs autres instances en lecture seule). Les problèmes et temps de réplication sont insignifiants, et les performances d’un Hibernate ‘de base’ (requêtes non optimisées) suffisent à servir du contenu à tous les visiteurs.
Dernier point, plus technique, le caching : un cache à 2 niveaux a été élaboré. Le premier, basique, utilise le cache d’Hibernate (ainsi que l’ensemble des mécanismes du framework, comme le lazy loading). Le second est un cache spécifique d’objets agrégés depuis les différentes sources de données (on n’en saura pas plus…)

En outre, dans l’interview, Alexandru Popescu aborde les problématiques de streaming. Nous vous invitons à consulter l’intégralité de ce vidcast, servie par InfoQ lui-même.

Paris Jug – Résumé de la soirée Groovy et Grails

Erwan Alliaume — Wed, 10 Sep 2008 10:58:48 +0000

Les tongs et les shorts de bain sont définitivement rangés pour tout le monde, le Paris Jug a fait sa rentrée hier soir. Rappelez-vous, la dernière édition nous avait particulièrement conquis. C’est donc avec une certaine impatience que nous attendions cette soirée, au menu ce jour : Groovy et Grails.

Groovy, scriptez vos applications sur une plateforme Java

Groovy est un langage de programmation dynamique pour la JVM. Il reprend certaines fonctionnalités d’autres langages comme Python ou Ruby tout en gardant une syntaxe proche du langage Java. Les scripts peuvent, soit être interprétés à la volée par la JVM, soit compilés comme tout autre programme Java. Étant donné que le bytecode généré est le même, il est tout à fait possible d’utiliser des bibliothèques Java au sein d’un programme Groovy et vice-versa. Vous pouvez par exemple écrire une interface en Java, l’implémenter par une classe Groovy et utiliser cette classe dans du Java. Groovy fait l’objet de la spécification JSR-241 du JCP. Qui de mieux que son leader, Guillaume Laforge, pouvait animer cette première partie de soirée ?

Après la présentation générale du framework, Guillaume nous a fait faire le tour les principaux sucs syntaxiques offerts par Groovy « sans devoir attendre les versions 7, 8 ou 9 de Java ». Pour nous démontrer cela, nous avons commencé par transformer un programme du type « hello world » écrit en Java en utilisant certaines fonctionnalités spécifiques Groovy :

Utilisation de la portée par défaut (en Groovy tout est public par défaut) ;
Sortie du code de la méthode main ;
Suppression des ';' ;
Gestion des propriétés ;
Utilisation de paramètres nommés
…

Au final, la taille du code a été divisée par 3.

Nous sommes ensuite entrés dans les détails de certaines fonctionnalités clés de Groovy dont :

Les closures ;
La lecture / écriture de fichiers XML ;
La décoration de classes final ;
…

Le tout en nous appuyant sur des cas d’utilisation concrets : création d’interfaces en Swing, utilisation simplifiée d’API, requêtes SQL.

L’intégration de code Groovy dans une application Java peut se faire de plusieurs manières :

Via un ScriptEngine proposé par le Jdk 6 (JSR-223) ;
Via Spring avec un namespace lang permettant de définir des beans Groovy ;
Ou encore, via d’autres mécanismes spécifiques à Groovy.

Groovy permet également la création de DSL (Domain Specific Language), une sorte de mini-langage proche de l’utilisateur, sujet sur lequel nous avons publié un article en mai dernier.

La prochaine version Groovy 1.6 (actuellement en beta) est annoncée pour la fin de l’année, apportant de grandes améliorations sur les performances.

Grails, le trifouilleur de CRUD

En seconde partie de soirée, Fabrice Robini, architecte chez notre confrère Octo Technology, nous a présenté Grails.
Grails est un framework, basé sur Groovy, permettant le développement Agile d’applications Web MVC. Sorti en février dernier en version 1.0, Grails se veut être la réponse Java au framework Ruby On Rails dont il est fortement inspiré.
Ce type de framework privilégie les conventions à la configuration : fan de lourds fichiers XML, passez votre chemin ! L’idée maîtresse est de minimiser le code et les configurations techniques afin d’être rapidement opérationnel et de pouvoir se concentrer sur le code métier.

Pour fonctionner, Grails se repose sur certains frameworks stars du monde Java dont Spring et Hibernate. Ce n’est pas pour autant que votre code reste complètement figé par ces choix préétablis. Si il vous prend l’idée de remplacer votre couche présentation , pas de problème. Pour peu que votre choix se trouve dans le catalogue de plugins, vous pourrez remplacer Spring MVC par GWT ou Flex. Dans la plupart des cas, le code est débranchable et configurable. Notons cependant qu’il est, pour le moment, impossible de se passer d’Hibernate. Ce problème devrait être corrigé avec la prochaine version de Grails qui prévoit une compatibilité Jpa.

Grails ne se contente pas de fournir une stack d’API de développement, il intègre également un environnement complet d’exécution :

Base de données (Hsqldb) ;
Serveur web (Jetty)
Scripts de déploiement (Ant, Maven)
…

La création de projets s’en trouve fortement simplifiée.
Nous avons donc créé, le temps de la session, un petit projet CRUD permettant l’ajout / la modification / la suppression et la recherche d’albums audio. La première étape consiste à générer un projet vide par l’intermédiaire d’une première ligne de commande Grails. Projet que l’on peut directement importer dans Eclipse pour développer, en Groovy, nos entités métiers : ‘Album’. Ensuite, avec une seconde commande Grails, l’intégralité de l’application CRUD est automatiquement générée. A partir de là, il vous est tout à fait possible de modifier le code généré pour y apporter les améliorations que vous désirez. C’est là que Groovy devient intéressant, Grails s’appuyant sur les forces de ce langage pour faciliter la création de votre code spécifique. Au final, une dernière commande Grails vous permettra de générer un WAR déployable sur votre serveur d’applications préféré et monitoré par vos outils d’administration habituels.

Conclusion

Bien plus qu’une simple présentation de framework, les soirées Paris Jug sont toujours l’occasion de partager un retour d’expérience au sein d’un cercle de passionnés. La soirée d’hier n’a pas dérogé à la règle, l’assemblée contenait une proportion importante de personnes qui connaissaient déjà (de près ou de loin) ces technologies. Au final, si la soirée n’a évidemment pas mis tout le monde d’accord, elle aura eu le mérite de faire avancer un peu le point de vue de chacun.

À chaque événement, c’est également l’occasion d’ouvrir le débat, ce mois-ci par exemple, les questions nous ont permis d’avoir le point de vue de Guillaume Laforge sur un des sujets d’actualités du moment : l’arrivée probable des closures Java.

Terminons ce résumé avec le programme du mois prochain consacré à OSGI présenté … par des Xebians (Cyrille Le Clerc et Nicolas Griso)

Première partie : « introduction à OSGI »

La naissance de ce standard extérieur au JCP
La gouvernance de l’OSGI Alliance et les relations avec le JCP
Les champs d’applications d’hier, d’aujourd’hui et demain (Enterprise Expert Group)

Seconde partie : « OSGI appliqué »

Côté client, les applications RCP imposent OSGI, est-ce vraiment une plus value pour les développements ?
Côté serveur : OSGI en socle des middlewares (Websphere, Weblogic, Glassfish et ServiceMix 4) et OSGI pour l’informatique de gestion

Nous vous y attendons nombreux !

Revue de Presse Xebia

Xebia France — Mon, 04 Aug 2008 17:02:10 +0000

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

Actualité éditeurs / SSII

Pourquoi payer pour de l’open source ?

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 :

Cela fait quelques temps que GlassFish s’intéresse à OSGI. La prochaine version du serveur d’application de Sun sera d’ailleurs modularisée. Dans ce sens, Sun un vient d’embaucher Richard S. Hall, actif participant au conteneur OSGI open-source Apache Felix. Il devrait rejoindre l’équipe GlassFish.
Solstice est (sera ?) le premier framework alliant Flex et OSGI. Il permet le développement d’application riche modularisée en intégrant les technologies Adobe Flex et Adobe BlazeDS, Eclipse Equinox et Apache Felix .

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.

Revue de Presse Xebia

Xebia France — Mon, 28 Jul 2008 17:13:58 +0000

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

Actualité éditeurs / SSII

Projet Cassandra : donation de Facebook à la communauté Open Source

Agilité

Les outils pour l’Agilité

RIA

OSCON 2008 : Web framework of the future

SOA

Succès des projets SOA : seulement 20% selon le Burton Group

Le coin de la technique

Actualité éditeurs / SSII

Projet Cassandra : donation de Facebook à la communauté Open Source

Cassandra est un système distribué de stockage de données. Cette solution sera Open Source.

Cassandra est une solution développée par Facebook (Facebook Data Team), le site de réseau social.

Cassandra s’inspire de l’architecture de Google Big Table et Amazon Dynamo. Ces systèmes sont conçus pour être des solutions fortement scalables et aussi gérer des entrepôts de données importants, de l’ordre du petabyte (représente 10 puissance 15 soit un un million de milliards). Son architecture est semblable à un réseau P2P contrairement ou base de données classique (Oracle, MySQL, …) qui ont une architecture centralisée (sous forme de Cluster). Cette architecture permet de répartir la charge et de contourner des goulets d’étranglement de trafic de données.

L’avantage d’une telle architecture est d’être très scalable, et d’éviter les goulets d’étranglement de performance, au détriment de la cohérence de données.

Autant dire que les problématiques adressées par ces outils sont fortement critiques, mais seulement pour des systèmes d’information très particuliers.

Agilité

Les outils pour l’Agilité

Kent Beck (l’un des fondateurs d’XP) partage ses réflexions sur la relation entre les outils et l’Agilité.

Il constate que beaucoup de personnes font une mauvaise interprétation d’un des principes du manifeste agile : Privilégiez les personnes et leurs interactions plutôt que les processus et les outils. Cela ne signifie pas qu’il n’y a pas besoin d’outil ! Les outils sont indispensables et les méthodes agiles font émerger de nouveaux besoins. Les tests unitaires, la conception incrémentale, et l’intégration continue sont des exemples de changements qui accompagnent le développement agile. Kent prédit d’autres changements à venir :

Des transitions plus aisées entre les activités
Un plus grand périmètre pour les tests automatiques
La transparence
Une collaboration en temps réel

Une synthèse du livre blanc est disponible sur InfoQ et sur le blog de Claude Audry.

RIA

OSCON 2008 : Web framework of the future

Lors de la convention de l’Open Source à Portland (EU), Matt Raible a présenté Web framework of the future où sont comparés les frameworks suivants : Flex, GWT, GRails et Rails

Il propose deux ‘nouveaux’ pattern pour la conception des couches de présentation pour les applications SOA :

Le SOFEA se fonde sur trois principes fondamentaux :

AD : Application Download, décrit la manière dont la couche client est téléchargée du serveur chez l’utilisateur. Suivant le paramétrage du client (logiciel, sécurité, …) une certaine application sera téléchargée par le client
PF : Presentation Flow, décrit la manière dont la couche de présentation enchaîne les écrans et dont les données sont transmises d’écran en écran. La réalisation de ce principe doit être dirigée par la partie client et non service
DI : Data Interchange, décrit la manière dont la couche de présentation et la couche service s’échangent les données. La couche de présentation doit supporter les mêmes structures de données que la couche modèle

La tableau suivant liste quelques solutions pour implémenter les trois principes précédents avec deux modèles de client thin client, rich client :

Principe	thin client	rich client
Application Download	Cette opération est assurée par le conteneur de la partie cliente (navigateur web)	C’est une opération explicite, le client télécharge une application suivant le paramétrage du client (Flash/Java Web Start)
Presentation Flow	Une partie de la navigation peut être assurée par du Javascript côté client. Cependant, la grosse partie de la navigation est assurée côté serveur avec un framework	La navigation est gérée localement (sur le poste client) par l’application téléchargée. Sur cette partie client, le pattern MVC est envisageable
Data Interchange	Il n’y a pas de communication directe, elle est assurée par le conteneur de l’application serveur (serveur Web). Un modèle HTML/HTTP est utilisé pour s’échanger les données, elle suit la sémantique requête/réponse.	Une certain nombre de protocoles et de format d’échange de données peuvent être utilisés, dans la plupart des cas c’est du XML. Généralement, la sémantique utilisée est la requête/réponse mais elle peut aussi être une semantique peer-to-peer.

A l’instar du SOFEA, le SOUI se base sur un découplage net entre la couche de présentation et la couche service métier. La conception de la couche présentation est pilotée par la couche de service métier et non l’inverse.

Ces principes sont mis en oeuvre au travers de 3 frameworks :

Flex : pour la réalisation d’interface en Flash.
GWT : pour la réalisation d’interface en DHTML/Ajax, développée en Java. Cette technologie peut amener à des difficultés lors que l’on travaille sur du code source existant.
GRails (Rails) : pour la réalisation d’interface Web en suivant le pattern MVC. Le scaffolding apporte une mise en place des écrans rapide, mais supporte mal le REST.

Ces technologies sont assez différentes dans leur architecture et dans leur prise en compte de l’existant. Flex supporte bien le REST. Les technologies Rails (GRails, Ruby On Rails, Django) apportent de la productivité grâce à un langage dynamique et expressif, au SOA

Succès des projets SOA : seulement 20% selon le Burton Group

Nous annoncions en Mars dernier le lancement du sondage du Burton Group sur le succès des projets SOA. Nous saluerons d’abord l’honnêteté de l’étude d’Anne Thomas Mannes qui reconnaît pas moins de 50% d’échecs complets.

Il ne faut pas pour autant condamner SOA dans son ensemble ; les piliers de cette démarche correspondent à des réalités des entreprises d’aujourd’hui. Certains principes comme le couplage lâche et la cohérence ne sont pas nouveaux et des idées comme la gouvernance des services et les Service Level Agreement qui vont avec, restent souvent des voeux pieux difficilement mis en oeuvre eu égard aux changements culturels qu’ils demandent.

Nous ne tirerons donc pas aujourd’hui sur l’ambulance. En plus des 10 pièges de la SOA dont nous avons déjà parlé ces dernières semaines, nous retiendrons que sur le fond, les échecs sont plus souvent dûs à un manque de vision métier et architecturale qu’un à problème d’implémentation technique.

Un point intéressant de l’étude du Burton Group : une culture purement projet, malgré ses vertus de mise en production à un prix et une date maitrisés, se marie mal à une démarche SOA. Le délai court et le périmètre étroit, clefs du succès d’un projet (ce que nous prônons), sont souvent incompatibles avec une architecture SOA qui demande une vision plus large des briques du SI et des retours sur investissements plus long.

Le coin de la technique

Interopérabilité OSGI et Java Module System

Plusieurs mois après l’annonce d’une éventuelle interopérabilité entre Java Module System et OSGI, le sujet est toujours en discussion au sein du groupe d’experts de la JSR-277. Sun semble un peu patauger dans la gadoue sur ces spécifications, il est vrai qu’il est difficile de contenter tout le monde sur un sujet ou chacun essaye d’imposer ses idées.

Et bien vous pouvez maintenant vous faire votre propre opinion, le sous-projet implémentant le draft de Java Module System inclus maintenant un repository OSGI. Le prototype est pour le moment uniquement compatible avec l’implémentation OSGI de la fondation Apache (Apache Felix). L’interopérabilité semble complètement transparente à l’utilisation, vous pouvez importer des modules OSGI de la même manière que vous importeriez des modules JAM (JAva Module). Si vous voulez essayer par vous-même un exemple complet est disponible sur le blog de Mandy Chung.

Nouvelle JSR : Post mortem JVM Diagnostics API

Les principaux outils de diagnostic (débuggeur, outils de trace, analyse de performance) permettent de surveiller le comportement de la JVM lorsqu’ils sont activés. Ce genre d’outils est très efficace quand les problèmes sont reproductibles et que le client est prêt à accepter le prix de cette reproduction. C’est pourtant en pratique pas toujours le cas : soit par ce que le bug est dû à un problème ponctuel, soit par ce que le coût de reproduction n’est pas acceptable. L’analyse rétrospective est compliquée et nous manquons d’outils permettant d’effectuer des analyses ‘post-mortem’.

La nouvelle JSR-326 : Post mortem JVM Diagnostics API voudrait pallier à ce manque en proposant un API permettant d’effectuer des analyses sur des artefacts générés à chaud par la JVM (HPROF ou autres… ).

Elle proposera :

un ensemble d’outils permettant de lire ces analyses
un moyen d’étendre ces outils
un moyen de standardiser la génération à la volée de ces artefacts

Alex Miller en a profité pour demander à Steve Poole (specifications leader de la JSR) si celle-ci à une chance d’arriver à temps pour le jdk7. La réponse évidement incertaine : toujours aucune date pour cette fameuse umbrella JSR devant officialiser le contenu de la prochaine version de Java…

Optimiser les performances de Java : rencontre avec Kirk Pepperdine

Dans cet article sur le Sun Developpper Network, Kirk Pepperdine revient sur ses expériences dans le domaine de la performance. Nous retiendrons les points suivants :

L’un des principaux écueils dans une analyse de performance est le manque de méthode avec un focus prématuré sur le code. La plupart des équipes plongent directement dans le code, au mépris d’informations plus globales sur le système. Pour améliorer ce point Kirk Pepperdine expose deux méthodes : la box et le mantra Ne devinez pas, mesurez
Plonger directement dans le code est d’ailleurs l’un des soucis majeurs que Kirk Pepperdine a rencontré au cours de sa carrière : aussi doué soit-il, un développeur ne parviendra pas à résoudre un problème de performance uniquement par la lecture du code ; la phase préliminaire de caractérisation du problème et d’identification du code en cause est primordiale.
L’un des facteurs de succès dans l’amélioration des performances est un code source simple et bien structuré. Un code simple (a.k.a. « dumb ») permet une meilleure analyse, aussi bien par des humains que par les optimiseurs de JVMs. De plus, un code complexe cache souvent des optimisations prématurées.
Un code bien structuré permet ajouts et remaniements qui sont souvent la clé de toute optimisation.
De manière générale, les grands principes agiles (couplage lâche, délégation, application des bons design patterns, bonne couverture de tests unitaires, builds automatisés) s’appliquent dans le cadre du tuning des performances.
Il faut se méfier des Performance Tips qui peuvent se révéler être des faux amis : une solution peut fonctionner dans un cas et s’avérer catastrophique dans une autre situation ou avec les versions suivantes d’une JVM.
La majorité des problèmes de performances se situent au niveau de la base de données et de la mémoire de la JVM.
Les principales mauvaises pratiques en ce qui concerne les liens entre programme Java et base de données sont :
     - Rendre son application résistante à l’introduction de caches (e.g. en mélangeant des accès jdbc au code métier)
     - Utiliser la base de données comme un mécanisme de lock distribué
     - Utiliser la base de données pour exécuter de la logique métier clef
     - Stocker des flux dénormalisés en base.
Le premier indice d’une sur-utilisation de la base est le nombre d’interactions entre celle-ci et l’application. La correction la plus triviale à cette erreur est d’ajouter un cache, ce qui sera beaucoup plus rapide et efficace que de tenter de réduire le nombre d’appels à la base.
Une autre astuce est de grouper au maximum les interactions application – base de données.
La gestion de la mémoire peut aujourd’hui reposer uniquement sur des outils efficaces :
     - Détection des fuites mémoire : Visual VM et Netbeans Generation
     - Objets ‘zombis’ : Netbeans Generation ou attendre le time out de ces objets
     - Un taux élévé de création d’objets. Cela entraîne généralement une Garbage Collection inefficace. Surveiller l’activité du GC permet donc de diagnostiquer ces problèmes (HPJMeter, Tagtraum, gchisto).
La majorité des problèmes de mémoire peuvent être réglés en jouant sur les Java Heap Size.
Une équipe stressée ne parviendra pas à traiter efficacement les problèmes. C’est pour cela qu’il est parfois bon d’envisager une correction ‘quick & dirty’ qui contente un maximum d’utilisateur, afin de faire baisser la pression sur les développeurs, pour pouvoir se poser et réfléchir à une solution à long terme.

M2Eclipse : Le nouvelle éditeur graphique de pom

Une nouvelle fonctionnalité vient de paraître dans la version 0.9.5 du plugin M2eclipse : l’éditeur graphique de fichier pom.xml. On peut remarquer que pour une première version, l’éditeur est déjà assez complet : la très grande majorité des paramètres configurables d’un pom sont présents et l’éditeur offre la complétion pour l’ajout de dépendances (déjà présent dans l’éditeur « source »).

Mais la fonctionnalité qui mérite le coup d’oeil est celle permettant d’afficher l’arbre de dépendance sous la forme d’un arbre. L’éditeur reprend le goal tree du maven-dependency-plugin en lui ajoutant la visualisation graphique qui le rend bien plus facile à utiliser que son rendu en ligne de commande. Pour vous en rendre compte, voyez plutôt les quelques captures d’écran disponibles. L’éditeur offre aussi une vue des dépendances sous la forme d’un graphe mais ce plugin relève encore du gadget, devant inutilisable sur des projets un peu conséquents.

M2Eclipse, en compétition avec Q4E pour devenir l’intégration officielle de Maven dans Eclipse (cf The Eclipse Integration for Apache Maven (IAM)), a fait de grands progrès depuis ses premières versions et si vous ne l’avez pas testé depuis longtemps, la dernière version mérite le coup d’œil …

Revue de Presse Xebia

Xebia France — Mon, 16 Jun 2008 16:15:50 +0000

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

Agilité

Le top 20 des livres sur l’Agilité

RIA

NASDAQ Market Replay : une success story pour Flex, AIR et Amazon S3

Le coin de la technique

Agilité

Le top 20 des livres sur l’Agilité

A partir de son top 100 des meilleurs livres d’ingénierie logicielle, Jurgen Appelo en a extrait le top 20 des livres sur l’Agilité.
Voici les 3 premiers pour les moins courageux :
1. Agile Software Development: Principles, Patterns and Practices de Robert C. Martin
2. Refactoring: Improving the Design of Existing Code de Martin Fowler
3. Agile Estimating and Planning de Mike Cohn

Une liste qui pourra vous guider dans vos prochains achats sur Amazon !

RIA

NASDAQ Market Replay : une success story pour Flex, AIR et Amazon S3

InfoQ explique dans InfoQ Case Study: NASDAQ Market Replay comment le NASDAQ offre un outil de rejeu des transactions effectuées (vérification de la validité d’une transaction, explication de l’écart entre le prix de vente espéré et le prix de vente réel, etc…) développé en FLEX avec un client standalone Abode AIR et connecté à un back end Amazon Simple Storage Service (S3).
La mise en place de cet outil est un véritable succès pour le RIA d’Abode, car il a été bâti en 6 mois par une équipe de 10 personnes, et répond complètement aux besoins fonctionnels, avec des performances supérieures à celles espérées.
De plus, un premier lot d’évolutions devrait voir le jour dans moins d’un mois, et son déploiement sera grandement facilité par l’utilisation de la technologie AIR (déploiement automatique par vérification de la dernière version en cours au lancement de l’outil).
Une démonstration de l’outil est disponible sur le site du NASDAQ.

Le coin de la technique

Spring Source Application Platform : l’heure de se faire une opinion ?

Julien Dubois, directeur de Spring Source France, a présenté Spring Source Application Platform (S2AP) lors de la soirée Spring du Paris JUG. Nous avions relaté en mai dernier la sortie du serveur hybride OSGI-Tomcat dans SpringSource Application Platform : la brèche dans Java EE. L’événement avait fait grand bruit, The Server Side avait lancé la polémique avec S2AP – totally rocks (220 messages enflammés). Si le buzz est retombé, Spring Source occupe le terrain médiatique pour nous faire patienter jusqu’à la première release avec des articles pédagogiques sur la valeur ajoutée des modules OSGI pour les applications web (Why should I care about OSGi anyway? par Adrian Colyer) autant que sur la nouvelle stratégie de Spring Source (Open Source, Open Strategy: The SpringSource Manifesto par Rod Johnson).

Au-delà des promesses un zest marketing du site officiel qui vont de l’amélioration de la réutilisabilité du code à la meilleure disponibilité des serveurs en passant par la reconfiguration à chaud, l’été peut-être l’occasion de regarder plus en détail la proposition de Spring Source.

Pour mémoire, S2AP est un serveur d’applications orienté modules basé sur OSGI Eclipse Equinox, dm-Kernel (Spring Source Dynamic Module Kernel), et Tomcat.

Le but de la présentation de jeudi dernier était autant de faire connaître le produit (après un rapide sondage avec l’assemblée, un peu plus la moitié du public connaissait s2ap) que de rassurer d’éventuels futurs utilisateurs sur la capacité de cette plateforme à aller rapidement en production. C’est d’ailleurs sur ce dernier point que Julien a insisté lors de la présentation au Jug : il ne faut pas oublier qu’il s’agit pour le moment que d’une béta.

L’administration de la plateforme s’effectue par l’intermédiaire : d’une web console ultra light (pour le moment). Celle-ci dispose d’un simple champ ‘Parcourir …’ vous permettant d’uploader vos bundles et de la liste des applications déployées disposant chacune d’un lien ‘undeploy’. (cf screenshot 2) ; et d’une console Osgi Equinox accessible via Telnet (cf screenshot 3). Si cela ne vous convient pas, rien ne vous empêche d’installer une console OSGI complémentaire plus conviviale du type knopflerfish .

Petit problème anecdotique à ce sujet noté sur la console Equinox : si vous voulez vous déconnecter, utilisez la commande ‘disconnect’, celle-ci vous demandera alors si vous êtes certain de vouloir quitter la console. Par contre si vous tapez la commande ‘exit’, le serveur est immédiatement arrêté sans aucun message de confirmation.

Après plus d’un mois de teasing en tout genre, vous n’avez peut-être pas encore eu le temps de vous faire une idée concrète du produit. C’est peut-être le moment de passer à l’action. Nous vous proposons ici une liste de liens permettant d’effectuer votre propre « Getting Started S2AP » rapidement :

Téléchargez la dernière bêta S2AP en vous inscrivant sur Spring Source, user guide, programmer guide
Téléchargez une application exemple
Consultez le Repository officiel de bundles compatibles S2AP
Tutoriel d’installation et d’utilisation rapide pour les développements

Screenshot 1 : S2AP startup	Screenshot 2 : Web Console	Screenshot 3 : Equinox Telnet Console

JPA 2.0, la nouvelle version d’une API bien portante

Il est loin le temps où le standard de persistance en Java, les EJB CMP, était conspué. JPA a refermé cette page tourmentée en créant un consensus autour du meilleur d’Hibernate, de TopLink et des autres.
Linda DeMichiel, Sun Microsystems, a présenté à JavaOne 2008 dans JavaTM Persistence API 2.0 les contours d’une nouvelle version largement inspirée d’Hibernate.

Nous retiendrons :

Améliorations des mappings : collections de types basics avec @ElementCollection, supports amélioré des types @Embeddable, des tris et des Map, etc.
Ajout d’une Criteria query API que regrettaient les adeptes d’Hibernate
Intégration du mécanisme de validation JSR 303: Bean Validation dont le specification leader n’est autre qu’Emmanuel Bernard, Red Hat, également project leader d’Hibernate Validator

Cette ébauche de JPA 2.0 est l’occasion de rappeler qu’il est maintenant raisonnable de migrer de l’historique API Session d’Hibernate à l’API EntityManager de JPA. Cette dernière répond à la majorité des besoins de nos projets et il suffit de récupérer la session Hibernate avec ((Session) entityManager.getDelegate()) si le besoin s’en fait sentir.

Language Java, que faut-il attendre ?

Alex Buckley (Sun), Neal Gafter (Google) et Michael D. Ernst (MIT) ont présenté à JavaOne 2008 dans Upcoming Java Programming Language Features les enjeux de l’évolution du langage Java et les nouvelles fonctionnalités actuellement à l’étude :

Multi-catch try {...} catch (E1, E2 e) {...}
Safe re-throw : simplification des blocs catch lorsque la méthode encapsulante rethrow les exceptions levées dans le bloc try
Modularité : Ajout d’un niveau de granularité entre les visibilités package et public
Extension des annotations pour ne plus limiter leur utilisation aux déclarations de class / method / field / variable et pour ajouter des informations dans le code telles que @NonNull, @Readonly ou @Immutable. Ces évolutions sont regroupées dans JSR 308: Annotations on Java Types.

A plus long terme, l’Expert Group réfléchit entre autres à un meilleur support du parallélisme et une évolution du modèle de composant (versioning, etc). Plus généralement, d’autres sucs syntaxiques et évolutions du langage sont à l’étude, nous en avions consacré une partie à ce sujet lors de la présentation ‘jdk 7 proposals‘ en février dernier.

Revue de Presse Xebia

Xebia France — Mon, 28 Apr 2008 17:04:41 +0000

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

Actualité éditeurs / SSII

Agilité

User stories « En tant que … je veux … »

Le coin de la technique

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

XKE, le programme de la session de mai

Actualité éditeurs / SSII

MySQL by Sun : Revirement de stratégie open source ? Choquant ?

Slashdot essaie de nous emmener sur une polémique « Sun gâche MySQL » avec Sun May Begin Close Sourcing MySQL Features à l’occasion de l’annonce par l’éditeur de fonctionnalités (online backup, etc) qui seront uniquement disponibles dans la version payante MySQL Enterprise. Au delà de l’insinuation peu crédible quand on se rappelle que l’essentiel du catalogue de Sun est disponible gratuitement, on retrouve le défi aujourd’hui classique de la monétisation de l’Open Source. Le rachat de MySQL par Sun change complétement le modèle économique de l’éditeur de base de données.

Hier, la startup MySQL, financée par des fonds de capital risque, se permettait d’être déficitaire car les candidats au rachat (Oracle puis finalement Sun) ne valorisaient pas MySQL Inc sur ses revenus mais sur les parts de marché de sa base de données. La stratégie a magnifiquement porté ses fruits puisque MySQL Inc s’est vendue un milliard de dollars à Sun, félicitations au management.

Aujourd’hui, MySQL est vraisemblablement devenue une division ‘classique’ de Sun et doit donc devenir rentable. L’équation de la rentabilité de l’open source est complexe, Red Hat et JBoss by Red Hat ont été des pionniers sur ce chemin, souhaitons à MySql by Sun de trouver lui aussi son modèle.

TSS : MySQL to get new features in Enterprise version

Modification du billet le 29 Avril 2008 : Jonathan Schwartz est finalement revenu en arrière et a annoncé que tous les produits que Sun distribue, sans exception, sont proposés gratuitement en licence Open source à la communauté. Pour plus de détails sur cette histoire, nous vous recommandons la série de The 451 Group : MySQL’s business model in a state of flux, Finding the right balance – MySQL’s changing development model et Jonathan Schwartz has the last word on MySQL

Superpackages (JSR-294) vs. OSGI : Episode n° 34291567….

La guerre continue entre les partisans de OSGI et ceux des JSR de SuperPackage et de JAM. Cependant, l’attaque vient cette fois-ci d’Alex Buckley de chez Sun.

Il explique dans son email les inconvénients qu’il voit dans l’implémentation actuelle des superpackages[1]. En substance, il propose d’introduire à la place un nouvel ‘access modifier’ (module).

Peter Kriens de l’OSGi Alliance semble plutôt emballé par cette proposition.

[1] Pour mémoire, nous avons publié en février dernier un article présentant les superpackages

Agilité

User stories « En tant que … je veux … »

Mike Cohn nous rappelle les 3 raisons pour lesquelles il préconise de décomposer les user stories sous forme de phrase , je veux , pour que "" >« En tant que , je veux , pour que » (la raison est optionnelle) :

L’emploi de la 1ère personne du singulier aide les développeurs à s’identifier à l’utilisateur
La structure de la phrase – représentée par 3 colonnes dans le Product backlog – aide le Product Owner à comprendre et prioriser les user stories
Pour ne pas rajouter de bruit dans la description des user stories, il suffit de nommer les colonnes du Product backlog « En tant que … », « je veux … », « pour que … » et le backlog devient intuitif à lire.

Le coin de la technique

De la sérialisation au parallélisme, une évolution incarnée par java.util.concurrent

La programmation multi-threadée en java a évoluée : anciennement on utilisait la sérialisation incarnée par synchronized, désormais on peut faire du parallélisme avec l’introduction des API java.util.concurrent en Java 5.

Sharadjava nous présente dans sa Java Concurrency Series les différents aspects de cette nouvelle librairie :

Simple Executor example pour la parallélisation des tâches.
Barrier pour l’attente entre tâches (on n’oubliera pas sur ce sujet le CountDownLatch).
Meaning of volatile pour la visibilité inter-threads des valeurs des variables.

Innovation autour de JPA : JBoss Hibernate confirme son domination avec Envers

Après l’intégration de la recherche full text Lucene [1] et le support du Database Sharding, Hibernate confirme sa domination de l’innovation autour de JPA en ouvrant le chantier du versionnage des données. Cette problématique, bien que récurrente et accentuée par les nouvelles contraintes réglementaires (Sarbane & Oaxley, etc), restait largement ignorées par nos frameworks et nos très chers design patterns. Seul Martin Fowler nous éclairait sur ce sujet délicat avec Patterns for things that change with time.

JBoss comble aujourd’hui ce vide en lançant Envers, une extension d’Hibernate qui versionne les données persistantes selon un pattern similaire au Temporal Object de Martin Fowler. Envers n’est qu’en version preview mais le projet est très prometteur et déjà une source d’inspiration pour les projets qui n’ont pas le temps d’attendre la première version stable.

On notera au passage qu’Envers préfère l’API standard JPA EntityManager à l’historique Session Hibernate ; on peut y voir un signe que le temps est venu pour les équipes projets de privilégier les standards JPA aux API historiques Hibernate.

Exemple d’entité persistante versionnée avec JBoss Envers

@Entity
public class Person {
    @Id
    @GeneratedValue
    private Integer id;
    @Versioned
    private String name;
    @Versioned
    private String surname;
    @Versioned
    @ManyToOne
    private Address address;
   ...
}

[1] cf notre billet Introduction à Hibernate Search (Googling your Persistent Domain Model)

Cas d’utilisation des grilles Java avec WebSphere eXtreme Scale/ ObjectGrid

Billy Newport présente dans Video: Introduction to WebSphere eXtreme Scale/ObjectGrid with patterns and use cases les scénarios typiques d’utilisation de la grille Java d’IBM :

Cache de proximité classique : la grille sert de Map distribuée ; l’application métier gère les données (chargement depuis les backends, mise en cache et sauvegarde des modifications dans les backends).
Cache de proximité avec « Loader synchrone » dans la grille : l’application métier se limite à demander des données à la grille et à les modifier ; la grille, grâce à un Loader, s’occupe de charger les données depuis les backends et sauvegarde en synchrone les données modifiées dans les backends.
Cache de proximité avec un « Loader à écriture différée » dans la grille : similaire au scénario précédent mais la sauvegarde des modifications dans les backends est asynchrone.
Cache collocalisé : l’application et la grille s’éxécutent dans les même JVM, chaque JVM héberge un noeud du cluster de l’application et un noeud de la grille. Ce scénario est typique de la mise en cache des sessions HTTP.

On notera que les architectures de type Map/Reduce, qui nécessitent une conception radicalement différente, ne semblent pas encore très répandues.

JSR-311 JAX-RS REST une histoire de RESTaurant

Dans cet article, Nicolas Martignole nous présente l’architecture REST (Representational State Transfer) et JSR 311: JAX-RS: The Java API for RESTful Web Services. L’objectif de cette JSR est de faciliter la programmation d’applications REST en Java.
La première partie est consacrée à une introduction de REST (définition d’une ressource, lecture, création, mise à jour, suppression d’une ressource, Services Webs RESTfull).
La deuxième partie nous présente quelques détails sur l’implémentation JAX-RS avec Java.

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

XKE, le programme de la session de mai

Le prochain XKE (Xebia Knowledge Exchange) aura lieu le mardi 6 Mai 2008. Les sujets suivants seront abordés :

Sessions Pratiques
- Terracotta, the Network Attached Memory (NAM)
- java.util.concurrent, concours de developpement

Technique
- Java et la Cryptographie

Architecture
- Retour sur l’architecture de l’un des plus grand site de ecommerce de France
- Tests unitaires avec les librairies de Mock

Xebia Hollande
- Intervention du CTO de Xebia Hollande

Comme nous l’annoncions, les XKE sont ouverts à l’ensemble des personnes à l’écoute du marché de l’emploi autour des technologies Java/J2EE. Si vous êtes l’une d’entre elles , n’hésitez pas à contacter Mélanie Bacrot pour vous inscrire.

Revue de Presse Xebia

Xebia France — Mon, 21 Apr 2008 16:24:29 +0000

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

Agilité

Succès et échecs avec Scrum en Chine

RIA

Top 10 des problèmes des applications Flex

Le coin de la technique

Agilité

Succès et échecs avec Scrum en Chine

Jacky Li d’InfoQ China a étudié l’adoption de Scrum dans les entreprises chinoises. Elles ont essayé Scrum pour différentes raisons : leurs besoins changeaient trop souvent, nécessité de livrer fréquemment, ou parce que leur ancienne approche ne leur permettait plus de s’améliorer.
Parmi les 5 cas retenus, 3 compagnies ont adopté Scrum avec succès, les 2 autres ont essuyé un échec. Comme on apprend beaucoup aussi d’un échec, voici les raisons évoquées par les 2 sociétés concernées :

certains dirigeants n’ont pas compris l’agilité, ils ont transformé les « daily scrum » en « daily report » (rapport journalier) avant de les abandonner
le 2e cas est une équipe offshore qui a abandonné les stand-up meetings et les plannings meetings, et où les développeurs priorisaient eux-mêmes les fonctionnalités du product backlog à implémenter

Même dans les cas de succès, l’un des principaux problèmes lors de l’adoption reste la mauvaise compréhension de Scrum et des principes agiles par les dirigeants et leurs collègues.
A noter qu’une des sociétés interrogées a mené une enquête au sein de ses équipes : 68% se trouvent plus productifs avec Scrum qu’avec leur ancienne approche…

RIA

Top 10 des problèmes des applications Flex

Dans cet article, l’équipe de James Ward nous présente les erreurs et/ou problèmes que peuvent engendrer la mise en place d’applications Flex.

Ainsi, nous apprenons que des problèmes de standard (bouton retour, bookmarking…) et de manière de concevoir les applications Web apparaissent. Au niveau des transferts de données, Flex en propose plusieurs types (XML, SOAP…) mais certains d’entre eux posent des problématiques de performances.

Néanmoins, des pistes de solutions sont citées comme entre autres l’utilisation de BlazeDS, pratique à utiliser avec du Java en backend.
Flex permet d’élaborer des IHM avec de nombreuses animations, mais trop d’animations tue l’animation. Il est donc conseillé de ne mettre de l’animation lorsque celle-ci est réellement nécessaire.

Etant donnée leur jeunesse, les projets Flex n’ont pas encore d’écosystème de développement et d’intégration (ie intégration continue, tests unitaires…). Cependant, de plus en plus d’outils et de plugins apparaissent (FlexUnit, FlexCover, plugin Maven…) et doivent être mis en place au même titre que des projets « classiques ».
Enfin trouver des développeurs Flex sur le marché est difficile, mais pour des personnes étant familières avec le monde Web et la programmation d’UI, l’apprentissage du langage Flex (ActionScript) ainsi que de ses API ne devrait pas être un grand frein à la percée de Flex sur le marché.

Le coin de la technique

Java Module System (JSR 277) vs. OSGI. La réconciliation ?

La grève des scénaristes à Hollywood n’aura finalement pas touché tout le monde. Si certaines de vos séries préférées ont été écourtées cette année, heureusement il n’en est pas de même partout. Plus haletant que 24, voici le pitch du nouvel épisode de la série : « Java Module System vs. OSGI ».

Résumé des épisodes précédents :

Sun a décidé de proposer une nouvelle solution d’assemblage de composants en ignorant les solutions (à peu près similaires) existantes. Au programme de cette solution : offrir le versionning, la gestion des dépendances, le stockage, packaging et distribution d’un nouveau type d’archive : le JAM. L’objectif étant d’inclure ces fonctionnalités dans la prochaine version du jdk dont voici l’overview.

La JSR 277 : Java Module System a donc été lancée. Pourtant, de par les (trop) nombreuses (houleuses) discussions, les spécifications ont commencé à prendre un certain retard. Ce retard devenant inquiétant, un nettoyage a été demandé au sein de l’expert group chargé de valider les spécifications. Concernant OSGI, aucune véritable prise de position n’a été communiquée par Sun.

Nouveautés de la semaine :

Bryan Atsatt, membre de l’expert group, essaye de calmer le jeu en exposant certains bénéfices qu’OSGI pourrait tirer d’une intégration fine de ces bundles avec Java Module System. De son coté, Sun fait une annonce, peut être la principale sur ce sujet de la semaine : la prochaine version de leur serveur d’application Glassfish sera modularisée … et un prototype existe : basé sur Felix (l’implémentation Apache d’OSGI R4).

Pour le moment, d’après le blog de Sahoo dont nous avons repris le schéma ci-dessus, cela ressemble plus à une cohabitation entre bundles HK2 et OSGI. Par la suite, l’idée est de transformer les bundles HK2 en une surcouche à OSGI, puis de la faire disparaître peu à peu.

L’annonce de Jérôme Dochez, tech lead Glassfish : GlassFish V3 runs on OSGi.
Sanjeeb Kumar Sahoo : GlassFish on OSGI – Part 1.
Téléchargez GlassFish V3 Preview 2 pour voir les instructions osgi (Export-Package et Require-Bundle) dans les manifests aux côtés de leurs équivalents HK2.

D’autre part, Mandy Chung, qui travaillait auparavant sur les APIs de management du Java SE, annonce sur son blog qu’un nouveau challenge se présente à elle : l’interopérabilité entre Java Module System et OSGI.

Affaire à suivre.

CXF devient un Top Level Project de la fondation Apache

Le framework SOAP CXF, successeur de XFire, quitte l’incubateur de la fondation Apache pour devenir un Top Level Project.

Quels impacts pour les utilisateurs ?

A court terme, le support de JAXB 2.1 et de JAXWS 2.1 avec la release CXF 2.1 qui attendait que le projet quitte l’incubateur et la disparition des messages d’erreur lors de l’édition des fichiers XML qui référencent des schémas XML de CXF (CXF-957).
A plus long terme, le renforcement de CXF face à ses concurrents JAXWS-RI et Axis 2. On notera sur ce point que le nouveau Mule 2 à choisi CXF pour remplacer XFire.

Cette promotion est l’occasion de regarder le fonctionnement de la Fondation Apache.

Nouvelles de la communauté Maven

Vous trouverez sur le blog d’Octo quelques nouvelles de la communauté Maven, avec en particulier la sortie de Maven 2.0.9 annoncée la semaine passée, et la liste des plugins principaux mis à jour ces deux derniers mois.

Mule 2, une refonte pour aller plus loin

Le célèbre ESB Open Source Mule annonce la sortie de sa version 2.0, une remise à plat de l’architecture interne de l’ESB préalable au développement de nouvelles technologies telles que SCA et OSGI.

On notera :

La refonte des API et de la configuration qui repose désormais sur la configuration XML par namespace introduite avec Spring 2.0.
Le framework d’évaluation d’expression (XPath, Groovy, etc) pour faciliter le traitement des messages.
La généralisation du modèle de streaming qui évite la représentation complète en mémoire des messages (HTTP, file, etc).
L’écartement du standard JBI comme le rappelle Ross Mason dans JBI misses mark.
L’annonce d’un probable support de SCA.

Nous aurions aimé :

L’OSGI-fication de l’ESB à l’instar de Websphere ESB, de BEA Aqualogic et du prochain ServiceMix 4. Ce chantier est annoncé pour la version 2.1 (cf MULE-981) mais nous pouvons craindre que son ampleur nécessite plus qu’un changement de release mineur et relève plus d’une version 3.
L’intégration limitée des Enterprise Integration Patterns alors qu’Apache Camel et Spring Integration en font leurs éléments principaux de routage [1].

Si cette refonte de Mule est pleine de promesses, l’absence de technologies phares comme OSGI, SCA et les Enterprise Integration Patterns font hélas de Mule un produit en retrait face aux ‘lightweight ESB’ que sont Apache Camel et Spring Integration.

Spring Security 2.0 : Acegi Security en plus simple

Le très réputé framework de sécurité Java Acegi profite de sa release 2.0 pour rejoindre le giron de SpringSource et devenir Spring Security 2.0.

On notera de cette release :

La grande simplification et une configuration beaucoup moins verbeuse grâce à :

Une configuration XML Spring à base de namespaces
Une configuration XML Spring à base de namespaces
Exemple de configuration :
```
   
   
   
   
   
   
```

Le support du standard émergent de Web SSO OpenID (notamment utilisé par Google, IBM, Sun et Yahoo) ainsi que de l’authentification Microsoft NTLM.
L’amélioration de la gestion des utilisateurs, des groupes et des rôles qui deviennent hiérarchiques.

L’intégration au portfolio Spring et la grande simplification de la configuration en font un framework incontournable de l’écosystème Java.

Revue de Presse Xebia

Xebia France — Mon, 07 Apr 2008 17:27:10 +0000

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

Actualité éditeurs / SSII

Agilité

Polémique : Scrum aliène-t-il XP ?

RIA

Adobe AIR pour Linux

Le coin de la technique

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

Poissons d’avril

Actualité éditeurs / SSII

Microsoft se rapproche de la fondation Eclipse

A l’occasion d’EclipseCon 08, Sam Ramji, leader de la communauté Open Source chez Microsoft, a annoncé le début d’une collaboration entre La fondation Eclipse et Microsoft.
Le principal but de ce rapprochement concerne une meilleure intégration du toolkit graphique d’Eclipse SWT avec Windows Presentation Foundation (WPF).

Eclispe 4, une refonte du socle ?

Voulant conquérir de nouveaux horizons, notamment côté serveur, la fondation Eclipse annonce la création d’un nouveau composant appelé e4. Le but principal de ce projet est de poser les bases du futur Eclipse 4.0. Partant de zéro, son rôle sera de simplifier la plateforme Eclipse et d’être résolument tourné vers le web.
Prévu au mieux pour fin 2009, Eclipse 4 sera développé en parallèle d’Eclipse 3.4 (Ganymede) et devrait assurer le compatibilité des plugins existants.

SpringSource Application Management Suite (AMS)

SpringSource vient de livrer une solution de monitoring des applications basée sur Spring. Voyons ici un système concurrent de Glassbox. Cependant, cet outil tire partie des nouvelles possibilités de configuration par annotation offertes par Spring 2.5. Il comprend automatiquement les annotations @Controller, @Repository, @Transactional, @Component et @Service. L’avantage donc par rapport à Glassbox finalement c’est la prise en compte automatique des beans gérés par Spring dans le monitoring.

SpringSource AMS est basé sur Hyperic’s HQ Enterprise Edition, fruit du récent partenariat entre les deux sociétés.

Un outil résolument à suivre ….

Agilité

Polémique : Scrum aliène-t-il XP ?

Notre collègue Vikas Hazrati a résumé sur InfoQ: Do Extreme Programming Folks Care about Scrum? une discussion très « animée » initiée par Michael James à propos de Scrum vue par les praticiens d’XP (eXtreme Programming). Ce dernier pense que Scrum et XP sont des alliés, mais ce n’est pas l’avis de tout le monde.

Comme Guillaume Bodet l’expliquait dans Scrum ou XP ? Scrum et XP !, nous pensons que Scrum et XP sont complémentaires, Scrum se positionne au niveau de la gestion/organisation de projet tandis que XP concerne les activités de développement.
Mais comme le dit Bruce Robinson, XP n’est pas la seule méthode de développement et elle n’est pas forcément la plus adaptée dans tous les cas, on peut par exemple préférer la revue de code au pair programming.

Alistair Cockburn répète que les pratiques préconisées par XP sont utiles mais pas nécessaires, des projets fonctionnent très bien sans XP.
Peu importe la méthode, mais tous sont d’accord qu’un projet nécessite des pratiques de développement pour réussir. Effectivement Scrum fournit un cadre méthodologique mais elle nécessite d’être complétée, « implémentée » par des pratiques de développement.

Wayne Mack propose l’approche du menu chinois : apprenez les 2 méthodes, choisissez ensuite les éléments qui vous semble intéressants parmi le menu.
Attention toutefois, Vikas Hazrati nous rappelle à travers le ShuHaRi que choisir les éléments du menu et créer sa propre méthode demande de la maturité, il conseille de commencer par expérimenter une méthode telle que préconisée, et seulement une fois à l’aise avec la méthode vous pouvez essayer de la personnaliser.

Pour en revenir aux valeurs de l’agilité, la méthode n’est pas le principal, les personnes et leurs interactions sont plus importantes. Car même si vous appliquez de bonnes pratiques, cela ne vous protège pas contre une « mauvaise » équipe (manque de compétences techniques, mauvais relationnel, esprit compliqué…). Quelle que soit la méthode il faut des gens talentueux et motivés pour mener à bien un projet selon J. B. Rainsberger, cependant un processus peut aider et XP semble le mieux adapté pour compléter Scrum.

Même si le groupe n’a pu se mettre d’accord au final, certains ont mentionné avoir utilisé Scrum et XP ensemble avec succès !

La discussion originale est sur Yahoo! Extreme Programming: How is Scrum alienating the eXtreme Programming folks?.

RIA

Adobe AIR pour Linux

Adobe AIR est enfin disponible pour la plateforme Linux. Seul bémol, celui-ci est une version alpha. Néanmoins, cette version contient le runtime, un exemple d’application et le AIR SDK. Par ailleurs, Flex Builder 3 a aussi été mis à jour afin de supporter la mise en place d’applications AIR sous Linux.
Adobe continue son ascension et remporte de plus en plus de succès et d’adhésion. Va t-on vers une ère Adobe ?

Le coin de la technique

SCA Java EE Integration specification : v0.9

Pendant que le Java Community Process tarde à statuer sur le modèle de composants de bas niveau OSGI, la communauté SCA continue à avancer les pions de son standard d’assemblage de composants de haut niveau avec la publication d’une première ébauche de la SCA Java EE Integration specification. Cette spécification a le mérite d’apaiser le monde Java EE après la tonitruante déclaration de Michael Rowley (BEA) : « EJB session beans, MDBs, JAX-WS and even JMS aren’t usually necessary in an SCA universe » dans Does SCA define a new programming model for Java?.

Quel impact pour le quotidien des développeurs Java ? Quasiment aucun pour le moment ; SCA est une spécification à l’utilisation encore confidentielle (SCA est principalement présent dans Websphere ESB et Process Server).

IBM annonce Websphere MQ V7 pour Juin

Le marché des middlewares de messages est lui aussi modifié par l’émergence d’offres open source matures (Apache ActiveMQ, etc ). Dans cette atmosphère dynamisée, IBM Websphere MQ, le leader du marché, tourne la page de trois ans de V6.0 avec l’annonce de WMQ V7.0 pour Juin 2008.
Les principales améliorations :

Amélioration des performances (particulièrement publish/subscribe, réception sur selector et messages non persistents).
Simplification de l’administration du mode publish/subscribe et des ressources JMS.
Bridge HTTP pour directement exposer les queues à des clients Web 2.0/Ajax.
Intégration native du mode publish/subscribe au Queue Manager [1].

Nous aurions espéré :

Un mécanisme de relivraison différé des messages équivalent à la redelivery policy d’ActiveMQ.
Une amélioration des performances des temporary queues similaire à celle apportée aux selectors. L’utilisation de files temporaires est un modèle encore plus simple que les selectors pour réaliser des invocations synchrones avec un middleware de messages (cf pattern request/reply).

Plus d’informations dans Redbook: WebSphere MQ V7.0 Features and Enhancements (Draft).

[1] En v6.0, un broker périphérique était utilisé.

Complexité cyclomatique optimale : 11 selon Enerjy !

Les outils d’analyse statique de code fleurissent avec l’essor des serveur d’intégration continue. L’éditeur Enerjy, après avoir étudié des projets open source réputés à la loupe de son analyseur, révise la valeur optimale de la complexité à 11. On notera que cette valeur est légèrement supérieure à celle retenue par CheckStyle, le leader de l’analyse statique, qui estime que 10 est déjà excessif.

Si la valeur exacte est sujette à débat, c’est l’occasion de se rappeler que la complexité cyclomatique est un indicateur pertinent de qualité du code et que les environnements de développement et serveurs d’intégration continue rendent aujourd’hui facile le suivi de ces indicateurs.

Java Module System (JSR-277) et OSGI, un silence pesant

Nouveau rebondissement dans le feuilleton « JSR-277 : Java Modules System versus OSGI ».

La JSR d’assemblage des composants menée par Sun prenait un retard inquiétant pour être intégrée à la version 7 de Java (Dolphin). Un petit répit s’annonce avec le décalage de la sortie de Dolphin désormais planifiée pour Janvier 2009.

Si cette prolongation donne une chance à la JSR-277 de figurer dans la prochaine version de Java, il reste néanmoins un problème de gouvernance de fond sur cette spécification. Peter Kriens (OSGI Alliance) expliquait en Septembre dernier qu’il a été refoulé de l’expert group sans raison convaincante. Dalibor Topic (kaffe.org) a demandé en Janvier l’éviction de 9 membres de ce même expert group sur une mailing list du projet Open JDK. Les déclarations fusent et l’expert group de la JSR 277 qui ne communique toujours rien de concret sur la position du très important OSGI, laissant la place à la rumeur et au mécontentement …

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

Poissons d’avril

Premier jour d’avril oblige, certains ont annoncé de fausses nouvelles, surprenantes ou amusantes. Voici une liste des poissons d’avril que nous avons recensés :

Microsoft rachète SpringSource
Microsoft rachète TheServerSide.com (décidément Microsoft est en forme)
Google et Richard Branson (Virgin) s’associent pour lancer la 1ère colonie sur Mars
De l’ASCII Art dans le bytecode Java
Le projet JavaRebel intègre une Intelligence Artificielle qui code à votre place pendant vos pauses-cafés
Cédric Beust lance le projet Toledo : un générateur de code multi-langage
Eclipse e4 déjà disponible
TSS devient multilingue