Blog Xebia France » SOA

Revue de Presse Xebia

Xebia France — Mon, 15 Nov 2010 23:40:11 +0000

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

Actualité éditeurs / SSII

SOA

La SOA renait de ses cendres

Le coin de la technique

Actualité éditeurs / SSII

Apple va collaborer au projet OpenJDK

Presque un mois après son annonce retentissante d’arrêter l’édition de la JVM pour Mac, Apple dans un récent communiqué de presse, a annoncé sa future collaboration avec Oracle pour contribuer au projet OpenJDK. Il rassure ainsi sur le futur des JVM pour OS X. Avec dernièrement le soutien d’IBM et maintenant d’Apple, le projet OpenJDK a de beaux jours devant lui. On espère que la qualité de l’intégration sera au rendez-vous pour les nombreux développeurs Java sous Mac.

Apple a confirmé que le JDK6 restera disponible de chez eux, pour OS X Snow Leopard et le prochain OS X Lion. Mais à partir du JDK 7, les versions pour Mac seront distribuées directement par Oracle. Chez Apple, on se félicite de ce partenariat qui devrait assurer aux Java-istes Mac d’obtenir dans le futur des releases au même rythme que tous les autres, au lieu d’avoir toujours un cran de retard. Espérons que tout se passe pour le mieux.

Oracle et Apache: de l’eau dans le gaz

Le début de la semaine passée a vu la Fondation Apache émettre un billet qui a fait beaucoup de bruit. Dans celui-ci, elle reproche à Oracle de ne pas respecter les termes du JSPA (pour Java Specification Participation Agreement) et qui, d’après la Fondation, l’autorisent à obtenir un TCK (Test Compatibility Kit) lui permettant de redistribuer Harmony, son JDK, sous la licence Apache. Le problème, qui reste un problème de brevet et de propriété intellectuelle, est ouvert depuis un moment: en 2007 déjà, Apache avait écrit une lettre ouverte à Sun. Les choses n’ont que peu changé depuis. Sauf qu’aujourd’hui, la Fondation menace carrément de quitter le processus du JCP ! Comme l’analyse InfoQ, c’est peut-être la seule arme qui reste à la Fondation Apache. Mais serait-ce vraiment une bonne chose ?
Pour mieux comprendre les termes et enjeux de l’imbroglio dans lequel se sont empêtrées les parties, un excellent document reste la FAQ publiée à l’époque par Apache pour expliciter sa lettre ouverte à Sun. Oracle vient d’ailleurs de publier sa réponse et… le moins que l’on puisse dire, c’est que la situation semble dans une impasse, chacun restant campé sur ses positions.

Par ailleurs, il faut aussi replacer les choses dans leur contexte actuel:

IBM, le plus gros contributeur à Harmony, le JDK d’Apache, a récemment indiqué se rapprocher d’Oracle à travers OpenJDK. Ainsi, il se détache d’Apache qui se retrouve donc isolé.
Oracle a par ailleurs attaqué Google sur son implémentation d’Android, basée en grande partie sur ce même Harmony.
enfin, le récent regain d’intérêt envers Java SE for embedded devices n’est peut-être pas étranger à tous ces problèmes. Même si le produit « date d’avant Android », Oracle semble vouloir le renforcer. Et la première étape, comme annoncé lors de l’ARM Conference consiste à faire correspondre les numéros de versions et implémentations des versions Java SE classic et embedded. Cette version est-elle appelée à se retrouver rapidement dans les téléphones portables à grande échelle maintenant que Java ME semble dépassé ? Oracle pourrait le souhaiter, car elle n’est pas gratuite !

SOA

La SOA renait de ses cendres

C’est ce qu’affirme le Burton group après avoir fais le buzz il y a deux ans avec son acticle SOA is Dead.
En effet, le rapport du cabinet note une remontée d’intérêt concernant les projets SOA, boostée par l’émergence du cloud computing.
Il place d’ailleurs la SOA comme prérequis pour réussir ses projets dans le cloud.
Il est aussi précisé que l’échec de la SOA il y a deux ans, a été largement provoqué d’une part, par la crise économique, et d’autre part, par les différentes solutions et technologies poussées par les éditeurs.
Ainsi, il faudrait se focaliser plus sur les principes fondamentaux de la SOA pour garantir la réussite de son architecture du SI ou de ses projets de migration vers le cloud. Pour en savoir plus, les articles de ZDNet ou de EbizQ sont de bons points de départ.

Le coin de la technique

Sortie d’Hyperic 4.5

Hyperic, la solution de monitoring et de management de SpringSource/VmWare est récement sortie en version 4.5. On peut voir l’annonce sur le blog de SpringSource ou celui d’Hyperic.

Cette nouvelle version apporte quelques nouveautés telles que le support des produits GemFire (un système de cache distribué), RabbitMQ (un système de messaging) et tc Server (un serveur Tomcat modifié). On peut voir que les efforts ont été portés vers les produits de SpringSource vFabric dont Hyperic fait partie.

La grosse nouveauté de cette version 4.5 réside dans ses fondations, avec des changements importants :

l’utilisation du Framework Spring 3 à la place des EJB,
le déploiement d’Hyperic se fait maintenant sur un serveur Tomcat et non plus sur JBoss,
l’utilisation de Maven à la place de Ant,
le changement du SCM qui passe de Subversion à Git.

Ces changements ont quelques conséquences plutôt bénéfiques pour le projet. En effet, le passage au framework Spring a permis de réduire la taille du code ainsi que sa complexité. De plus le passage de JBoss à Tomcat permet un gain sensible sur le temps de déploiement, faisant par la même gagner un temps précieux aux développeurs d’Hyperic.

Ces différentes améliorations devraient permettre de faciliter l’apparition de nouveautés dans les futures versions ainsi qu’une plus grande stabilité.

S4, le nouveau jouet de Yahoo!

Cette semaine, on risque de beaucoup parler de Hadoop, en particulier grâce à Devoxx. Yahoo!, qui a fortement contribué à ce framework de Map/Reduce via la fondation Apache, prépare déjà sa succession : S4. Là où Hadoop est plutôt orienté batch, S4 a pour but d’amener au Map/Reduce une dimension temps réel, en travaillant directement sur des flux continus de données.
Yahoo! utilise d’ores et déjà S4 en production pour analyser et cibler les informations publicitaires affichées aux internautes.
Le projet vient d’être cédé à la communauté openSource, sous licence Apache 2.0.
C’est le début d’une aventure qui s’annonce longue et semée d’embuche (comme le savent déjà ceux qui, comme nous, ont essayé de faire du pseudo temps-réel avec la stack Hadoop), mais d’ores et déjà palpitante.
S4 est écrit en Java, actuellement disponible en version alpha, et cherche des contributeurs !

Créer un composant Apache Camel de connexion à l’APNS – 3 sur 3

Alexis Kinsella — Wed, 13 Oct 2010 21:07:31 +0000

Nous avons vu dans un premier article comment initier le développement d’un composant Apache Camel, puis dans un second comment implémenter ses différentes classes.

A ce stade de notre développement nous sommes déjà en mesure d’utiliser pleinement notre composant, mais nous ne pouvons pas encore en assurer sa qualité. Pour cela, il est nécessaire d’ajouter à notre composant différentes classes de test. Bien que la testabilité de frameworks d’intégration puisse parfois paraître difficile, le projet Apache Camel fournit tous les outils nécessaires permettant de répondre à ce besoin. Nous verrons donc dans cet article comment tester le composant que nous avons développé.

Pour finir, nous verrons comment intégrer notre développement à un projet Camel, ainsi que les limites de notre composant et les solutions pour résoudre ces limitations.

Tester la classe ApnsConsumer

Bien que le projet Apache Camel permette de travailler naturellement avec Spring, nous nous attarderons dans un premier temps sur les méthodes permettant de tester notre composant sur un mode standalone. Pour cela, nous étendrons la classe CamelTestSupport. Cette dernière fournit les méthodes nécessaires pour effectuer différentes assertions sur les valeurs attendues en fin de traitement, en particulier sur des endpoints de type MockEndpoint.

Nous devons tout d’abord implémenter les 2 méthodes suivantes:

Méthode	Description
createCamelContext()	Permet de créer le contexte Camel qui sera utilisé par le test
createRouteBuilder()	Permet de construire la route qui sera appelée par le test. Idéalement, la route doit se terminer par l’appel d’un MockEpoint

Avant l’exécution de nos tests, un serveur APNS bouchonné doit être lancé. Il enverra sur le flux feedback des données factices.

L’objectif de ce test est de valider que le endpoint apns:consumer est capable de consommer les informations de test renvoyées par le flux feedback du serveur bouchonné. Le endpoint Camel mock:result nous permet de valider les assertions nécessaires sur les messages reçus par ce endpoint.

Le endpoint apns:consumer est configuré pour poller le flux feedback de l’APNS toutes les 500ms. Le test ne doit donc pas durer raisonnablement plus de 5 secondes en tenant compte du temps d’attente d’une seconde avant les assertions et du temps de démarrage du serveur bouchon APNS. Un timeout de 5 secondes est donc placé sur le test pour s’assurer que ce dernier tombe en erreur si un événement bloquant inattendu empêche le test de se terminer.

public class ApnsConsumerTest extends CamelTestSupport {
    ApnsServerStub server;
    public ApnsConsumerTest() {
    	super();
    }
    /**
     * Démarrage du serveur bouchonné simulant l'APNS
     */
    @Before
    public void startup() throws InterruptedException {
        server = ApnsServerStub.prepareAndStartServer(FixedCertificates.TEST_GATEWAY_PORT, FixedCertificates.TEST_FEEDBACK_PORT);
    }
    /**
     * Arrêt du serveur bouchonné simulant l'APNS
     */
    @After
    public void stop() {
        server.stop();
    }
    /**
     * Test de l'ApnsConsumer. L'objectif est de vérifier que le flux feedback est
     * bien consommé par la route Camel. Pour cela on vérifie après consommation
     * que le endpoint MockEndpoint a bien reçu les messages.
     */
    @Test(timeout=5000)
    public void testConsumer() throws Exception {
    	byte[] deviceTokenBytes = ApnsUtils.createRandomDeviceTokenBytes();
        String deviceToken = ApnsUtils.encodeHexToken(deviceTokenBytes);
        MockEndpoint mock = getMockEndpoint("mock:result");
        mock.expectedMessageCount(1);
        mock.message(0).body().isInstanceOf(InactiveDevice.class);
        byte[] feedBackBytes = ApnsUtils.generateFeedbackBytes(deviceTokenBytes);
        server.toSend.write(feedBackBytes);
        Thread.sleep(1000);
        assertMockEndpointsSatisfied();
        InactiveDevice inactiveDevice = (InactiveDevice)mock.getExchanges().get(0).getIn().getBody();
        assertNotNull(inactiveDevice);
        assertNotNull(inactiveDevice.getDate());
        assertNotNull(inactiveDevice.getDeviceToken());
        assertEquals(deviceToken, inactiveDevice.getDeviceToken());
    }
    /**
     * Création et configuration du contexte Camel avec une configuration de test.
     * Enregistrement du composant APNS, et configuration de l'ApnsService
     */
    protected CamelContext createCamelContext() throws Exception {
        CamelContext camelContext = super.createCamelContext();
        ApnsServiceFactory apnsServiceFactory = ApnsUtils.createDefaultTestConfiguration();
        ApnsService apnsService = apnsServiceFactory.getApnsService();
        ApnsComponent apnsComponent = new ApnsComponent(apnsService);
        camelContext.addComponent("apns", apnsComponent);
        return camelContext;
    }
    /**
     * Création de la route Camel permettant de simuler la consommation du flux
     * feedback de l'APNS
     */
    protected RouteBuilder createRouteBuilder() throws Exception {
        return new RouteBuilder() {
            public void configure() throws Exception {
                from("apns:consumer?initialDelay=500&delay=500&timeUnit=MILLISECONDS")
                	.to("log:com.apache.camel.component.apns?showAll=true&multiline=true")
                	.to("mock:result");
            }
        };
    }
}

Tester la classe ApnsProducer

De la même façon que nous nous y sommes pris pour la classe de test ApnsConsumerTest, nous allons étendre la classe CamelTestSupport pour tester notre classe ApnsProducer. L’objectif est de vérifier que le serveur bouchonné reçoit bien les messages produits.

public class ApnsProducerTest extends CamelTestSupport {
    private ApnsServerStub server;
    private String FAKE_TOKEN = "19308314834701ACD8313AEBD92AEFDE192120371FE13982392831701318B943";
    public ApnsProducerTest() {
    	super();
    }
    /**
     * Démarrage du serveur bouchonné simulant l'APNS
     */
    @Before
    public void startup() {
        server = ApnsServerStub.prepareAndStartServer(FixedCertificates.TEST_GATEWAY_PORT, FixedCertificates.TEST_FEEDBACK_PORT);
    }
    /**
     * Arrêt du serveur bouchonné simulant l'APNS
     */
    @After
    public void stop() {
        server.stop();
    }
    /**
     * Test de l'ApnsProducer. L'objectif est de vérifier que le serveur APNS a
     * bien reçu les notifications envoyées.
     * Pour cela on vérifie après production des notifications que le serveur bouchonné
     * a bien reçu les messages: On s'assure que les tableaux de bytes de la notification
     * produite et du contenu reçu par le serveur sont bien égaux.
     */
    @Test(timeout=2000)
    public void testProducer() throws Exception {
    	String message = "Hello World";
    	String messagePayload = APNS.newPayload().alertBody(message).build();
        ApnsNotification apnsNotification = new ApnsNotification(FAKE_TOKEN, messagePayload);
        server.stopAt(apnsNotification.length());
        template.sendBody("direct:test", message);
        server.messages.acquire();
        assertArrayEquals(apnsNotification.marshall(), server.received.toByteArray());
    }
    /**
     * Création et configuration du contexte Camel avec une configuration de test.
     * Enregistrement du composant APNS, et configuration de l'ApnsService
     */
    protected CamelContext createCamelContext() throws Exception {
        CamelContext camelContext = super.createCamelContext();
        ApnsServiceFactory apnsServiceFactory = ApnsUtils.createDefaultTestConfiguration();
        ApnsService apnsService = apnsServiceFactory.getApnsService();
        ApnsComponent apnsComponent = new ApnsComponent(apnsService);
        camelContext.addComponent("apns", apnsComponent);
        return camelContext;
    }
    /**
     * Création de la route Camel permettant de simuler la production de messages
     * à destination des serveurs APNS.
     */
    protected RouteBuilder createRouteBuilder() throws Exception {
        return new RouteBuilder() {
            public void configure() throws Exception {
                from("direct:test").
                setHeader(ApnsConstants.HEADER_TOKENS, constant(FAKE_TOKEN)).
                to("apns:notify");
            }
        };
    }
}

Tester l’intégration d’un composant Camel avec Spring

Les configurations Camel sont souvent déclarées par des fichiers de configuration Spring. C’est pourquoi il est nécessaire de tester l’intégration du composant dans une configuration Spring. Un bon moyen d’automatiser ce type de test est d’utiliser les classes de support JUnit fournies par Spring ( _AbstractJUnit4SpringContextTests_ ).

L’ensemble de la configuration est déclarée dans le fichier SpringApnsConsumerTest-context.xml associé au test unitaire. Les différents beans utilisés par la classe de test sont injectés via les annotations @Autowired et @EndpointInject(uri = « mock:result »).

Une fois la déclaration du composant Camel effectuée via le fichier de configuration Spring, il ne reste plus qu’à injecter les différents beans configurés dans les propriétés de la classe de test. Le contenu du test en lui-même reste identique, cependant la partie configuration a disparu ce qui rend le test plus lisible. Afin de faire disparaître du test ce qui peut encore en parasiter sa lisibilité, une classe de test parent peut être créée pour contenir les méthodes d’initialisation et d’arrêt du serveur APNS de test.

@ContextConfiguration
public class SpringApnsConsumerTest extends AbstractJUnit4SpringContextTests {
    ApnsServerStub server;
    /**
     * Injection du context Camel déclaré via Spring
     */
    @Autowired
    protected CamelContext camelContext;
    /**
     * Injection du endpoint Camel "mock:result" déclaré via Spring
     */
    @EndpointInject(uri = "mock:result")
    protected MockEndpoint mock;
    public SpringApnsConsumerTest() {
    	super();
    }
    /**
     * Démarrage du serveur bouchonné simulant l'APNS
     */
    @Before
    public void startup() throws InterruptedException {
        server = ApnsServerStub.prepareAndStartServer(FixedCertificates.TEST_GATEWAY_PORT, FixedCertificates.TEST_FEEDBACK_PORT);
    }
    /**
     * Arrêt du serveur bouchonné simulant l'APNS
     */
    @After
    public void stop() {
        server.stop();
    }
    /**
     * Test du consommateur
     */
    @Test(timeout=5000)
    public void testConsumer() throws Exception {
    	byte[] deviceTokenBytes = ApnsUtils.createRandomDeviceTokenBytes();
        String deviceToken = ApnsUtils.encodeHexToken(deviceTokenBytes);
        mock.expectedMessageCount(1);
        mock.message(0).body().isInstanceOf(InactiveDevice.class);
        byte[] feedBackBytes = ApnsUtils.generateFeedbackBytes(deviceTokenBytes);
        server.toSend.write(feedBackBytes);
        Thread.sleep(1000);
        mock.assertIsSatisfied();
        InactiveDevice inactiveDevice = (InactiveDevice)mock.getExchanges().get(0).getIn().getBody();
        Assert.assertNotNull(inactiveDevice);
        Assert.assertNotNull(inactiveDevice.getDate());
        Assert.assertNotNull(inactiveDevice.getDeviceToken());
        Assert.assertEquals(deviceToken, inactiveDevice.getDeviceToken());
    }
}

Limitations du composant actuel

Dans un soucis de simplicité, le composant présenté est limité fonctionnellement et ne propose qu’un ensemble réduit de fonctionnalités. L’implémentation proposée dans ce billet nous oblige à déclarer les tokens à notifier directement au niveau de la route. Cependant une implémentation plus complète pourrait permettre d’exploiter des en-têtes par exemple pour rendre la sélection de token à notifier plus dynamique.

Heureusement, la richesse du framework Apache Camel nous permet de passer outre cette restriction et d’obtenir l’aspect dynamique souhaité en utilisant le pattern Recipient List, qui permet par exemple l’extraction des URIs de destination depuis un en-tête de message produit au préalable.

RouteBuilder builder = new RouteBuilder() {
    public void configure() {
        from("direct:a").recipientList(
        header("recipientListHeader").tokenize(","));
    }
};

Dans cet exemple, l’en-tête recipientListHeader contiendrait les différentes URIs séparées par des virgules.

Utilisation du composant dans un projet

Pour utiliser le composant développé dans cette série d’articles, il suffit de l’importer en tant que dépendance Maven dans votre projet Camel et de déclarer le repository qui permettra de le charger à défaut de l’avoir déjà dans son répository local.

Ce qui donne les lignes suivantes à ajouter dans le pom de votre projet:

La dépendance Maven:


    org.apache.camel
    camel-apns
    2.4.0

Le repository Maven qui met à disposition le composant:


    
        camel-apns.repo-release
        http://camel-apns.googlecode.com/svn/maven/public/repository/release/

Exemples d’utilisation

Afin de donner une vision synthétique de l’usage de notre composant, voici un condensé de quelques exemples d’utilisation:

Consommation du flux feedback avec une configuration Java

      from("apns:consumer")
            .to("log:com.apache.camel.component.apns?showAll=true&multiline=true")
            .to("mock:result");

Envoi de notifications avec une configuration Java

      from("direct:test")
            .setHeader(ApnsConstants.HEADER_TOKENS, constant(FAKE_TOKEN))
            to("apns:notify");

Envoi d’une notification avec une configuration Spring

Conclusion

Nous avons vu dans cet article comment créer et tester un composant Camel qui communique avec les serveurs de notifications d’Apple. Les API du framework ont été pensées pour faciliter le développement de nouveaux composants, et vous permettront d’implémenter et de tester facilement les composants dont vous avez besoin. Vous pouvez consulter le code source du composant camel-apns présenté dans cette série d’article sur sa page Google Code.

Liens utiles:

Le site google code du composant ‘camel-apns’ présenté dans le billet:

http://code.google.com/p/camel-apns

D’autres liens utiles sur le développement de composants Camel:

Précédentes parties de l’article:

Créer un composant Apache Camel de connexion à l’APNS – 2 sur 3

Alexis Kinsella — Wed, 06 Oct 2010 20:44:21 +0000

Nous avons vu dans un premier article comment initier le développement d’un composant Apache Camel. Cependant, nous n’avons pas encore abordé son développement à proprement parler et notre composant ne permet pas encore de communiquer avec les serveurs Apple. Nous allons donc voir dans cet article comment implémenter les différentes classes nécessaires au bon fonctionnement de notre composant.
Pour rappel l’objectif est de développer un composant capable de communiquer avec l’Apple Push Notification Service, qui permet d’envoyer des notifications aux appareils mobiles d’Apple (iPad, iPhone, iPod Touch).

Implémentation du composant

Les quatre interfaces suivantes doivent être implémentées pour développer un composant Camel permettant à la fois de consommer et produire des messages :

Interfaces à implémenter	Description
Component	Elle permet de créer les endpoints relatifs au composant.
Endpoint	Elle permet la création des Consumers et Producers relatifs à un endpoint défini par son URI.
Consumer	Elle correspond à l’implémentation des Consumers relatifs au endpoint d’un composant.
Producer	Elle correspond à l’implémentation des Producers relatifs au endpoint d’un composant.

La classe ApnsService

Pour communiquer avec les serveurs Apple, nous devons instancier un objet ApnsService. Le framework java-apns fournit pour cela la classe ApnsServiceBuilder. Celle-ci permet de construire facilement un objet ApnsService en spécifiant au builder la configuration souhaitée.

Le builder est obtenu grâce à la classe utilitaire Apns :

        ApnsServiceBuilder builder = APNS.newService();

Ensuite, il suffit d’appeler les différentes méthodes de configuration du builder. Dans le cadre d’une configuration simple, le code source suivant est suffisant :

// Instanciation du builder
ApnsServiceBuilder builder = APNS.newService();
InputStream certificateInputStream = null;
try {
    // Ouverture de l'inputStream correspondant au certificat
	certificateInputStream = ResourceUtils.getInputStream("certificate_classpath");
	// Configuration du certificat utilisé pour communiquer avec l'APNS
	builder.withCert(certificateInputStream, "certificate_password")
}
finally {
	// Fermeture de l'inputStream correspondant au certificat
	ResourceUtils.close(certificateInputStream);
}
// Configuration des URLs par défaut de production vers les serveurs APNS
builder.withProductionDestination();
// Configuration d'un pool de 5 connexions vers les serveurs APNS
builder.asPool(5);
// Configuration d'une politique de reconnexion uniquement lorsqu'une connexion vers les serveurs APNS est fermée
builder.withReconnectPolicy(ReconnectPolicy.Provided.NEVER);
// Obtention de l'instance configurée
ApnsService apnsService = builder.build();

Note : Un exemple de configuration plus complet de l’objet ApnsService peut être trouvé dans le code source du composant camel-apns.

Afin d’intégrer de façon efficace notre composant avec Spring, la classe ApnsServiceBuilder se révèle être un bon point de départ pour écrire une factory permettant de construire un objet ApnsService via Spring.

La classe ApnsComponent

L’interface Component correspond à l’unité de base définissant un composant Camel. Ce dernier est associé au scheme d’une URI lorsqu’il est ajouté à un contexte d’exécution.

Une implémentation par défaut de cette interface est fournie (en l’occurrence la classe DefaultComponent), ce qui permet de se focaliser sur les fonctionnalités de notre composant. Un composant Camel a pour rôle de créer les endpoints relatifs aux URI définies dans le contexte Camel. Cette tâche est réalisée par la méthode createEndpoint.

Chaque endpoint créé à partir d’un même ApnsComponent utilisera une unique configuration pour échanger avec l’APNS. C’est pourquoi le service d’accès à l’APNS sera injecté au niveau de l’objet ApnsComponent.

Le bean apnsService peut être setté par le constructeur ou bien par un setter pour faciliter l’intégration avec Spring.

public class ApnsComponent extends DefaultComponent {
	private ApnsService apnsService;
	public ApnsComponent() {
		super();
	}
	public ApnsComponent(ApnsService apnsService) {
		super();
		AssertUtils.notNull(apnsService, "apnsService is mandatory");
		this.apnsService = apnsService;
	}
	public ApnsComponent(CamelContext context) {
		super(context);
	}
	public ApnsService getApnsService() {
		return apnsService;
	}
	@SuppressWarnings("unchecked")
	protected Endpoint createEndpoint(String uri, String remaining, Map parameters) throws Exception {
		ApnsEndpoint endpoint = new ApnsEndpoint(uri, this);
		setProperties(endpoint, parameters);
		return endpoint;
	}
    /**
     * L'objet ApnsService peut être setté s'il le constructeur vide a été appelé pour instancier un objet ApnsComponent
     */
	public void setApnsService(ApnsService apnsService) {
		if (this.apnsService != null) {
			throw new IllegalArgumentException("apnsService already setted");
		}
		this.apnsService = apnsService;
	}
}

La classe ApnsEndpoint

La classe ApnsEndpoint permet de gérer la création des objets Consumer et Producer définis dans les routes Camel. Dans notre cas, nous étendrons la classe ScheduledPollEndpoint. Elle permet d’implémenter un endpoint qui saura créer des objets Consumer dont le déclenchement s’effectuera à intervalle régulier.

C’est la classe ApnsEndpoint qui a la charge de gérer les paramètres passés dans l’URI. Ainsi, les tokens passés en paramètres de l’URI d’un objet ApnsEndpoint seront injectés automatiquement via les setters correspondant aux paramètres renseignés. Si un paramètre ne correspond pas à un setter déclaré, une exception sera alors lancée.

Afin de faciliter le travail de configuration des paramètres spécifiques au travail de polling, c’est la classe ScheduledPollEndpoint qui lira automatiquement les paramètres de déclenchement renseignés sur l’URI. L’ApnsEndpoint aura donc toutes les informations nécessaires pour configurer les paramètres de déclenchement de l’objet ApnsConsumer.

Dans le cas de l’exécution de tests, les paramètres de déclenchement de la consommation de messages en provenance de l’APNS peuvent être configurés de la façon suivante :

from("apns:consumer?initialDelay=500&delay=500&timeUnit=MILLISECONDS")
	.to("log:com.apache.camel.component.apns?showAll=true&multiline=true")
	.to("mock:result");

L’implémentation de la classe ApnsEndpoint donnera le code source suivant :

public class ApnsEndpoint extends ScheduledPollEndpoint {
	@SuppressWarnings("unused")
	private static final Log LOG = LogFactory.getLog(ApnsEndpoint.class);
	private CopyOnWriteArraySet consumers = new CopyOnWriteArraySet();
	private String tokens;
	public ApnsEndpoint(String uri, ApnsComponent component) {
		super(uri, component);
	}
	public String getTokens() {
		return tokens;
	}
	public void setTokens(String tokens) {
		this.tokens = tokens;
	}
	private ApnsComponent getApnsComponent() {
		return (ApnsComponent)getComponent();
	}
    /**
     * On obtient une instance de la clase ApnsService depuis l'object ApnsComponant
     */
	public ApnsService getApnsService() {
		return getApnsComponent().getApnsService();
	}
    /**
      * Indique que le endpoint n'est instancié qu'une seule fois par le contexte Camel
      */
	public boolean isSingleton() {
		return true;
	}
    /**
     * Permet d'obtenir la liste des consumers
     */
	protected Set getConsumers() {
		return consumers;
	}
    /**
     * Permet de créer un consumer
     */
	public Consumer createConsumer(Processor processor) throws Exception {
		ApnsConsumer apnsConsumer = new ApnsConsumer(this, processor);
		configureConsumer(apnsConsumer);
		return apnsConsumer;
	}
	/**
	 * Permet de créer un producer
	 */
	public Producer createProducer() throws Exception {
		return new ApnsProducer(this);
	}
}

La classe ApnsProducer

La classe ApnsProducer correspond à la classe qui permet d’envoyer des notifications aux terminaux mobiles Apple via les serveurs APNS. La classe abstraite DefaultProducer sera étendue pour fournir un support de base à notre implémentation.

Seule la méthode process reste ainsi à renseigner. Il suffira d’y implémenter l’envoi de la notification à l’APNS comme suit :

public class ApnsProducer extends DefaultProducer {
	private static final transient Log LOG = LogFactory.getLog(ApnsProducer.class);
	private ApnsEndpoint endpoint;
	private List tokenList;
	public ApnsProducer(ApnsEndpoint endpoint) {
		super(endpoint);
		this.endpoint = endpoint;
		configureTokens(apnsEndpoint);
	}
    /**
     * La méthode configureTokens permet d'extraire la liste de tokens destinataires
     * des notifications envoyées au endpoint.
     */
	private void configureTokens(ApnsEndpoint apnsEndpoint) {
		if (StringUtils.isNotEmpty(apnsEndpoint.getTokens())) {
			try {
				this.tokenList = extractTokensFromString(apnsEndpoint.getTokens());
			} catch (CamelException e) {
				throw new IllegalArgumentException(e);
			}
		}
	}
	/**
	 * Méthode appelée par le producer pour traiter les échanges Camel
	 */
	public void process(Exchange exchange) throws Exception {
		notify(exchange);
	}
	/**
	 * La méthode notify  est appelée pour envoyer une notification aux serveurs APNS.
	 */
	private void notify(Exchange exchange) throws ApnsException, CamelException {
		String payload = exchange.getIn().getBody(String.class);
                // Une copie de la liste des tokens à notifier est passée en paramètre,
                // ainsi que le payload du message
		endpoint.getApnsService().push(new ArrayList(tokenList), payload);
	}
	/**
	 * On extrait une liste de tokens à partir d'une chaîne de caractères contenant
	 * des tokens séparés par un point virgule.
	 */
	private List extractTokensFromString(String tokensStr) throws CamelException {
		tokensStr = StringUtils.trim(tokensStr);
		if (tokensStr.isEmpty()) {
			throw new CamelException("No token specified");
		}
		String[] tokenArray = tokensStr.split(";");
		int tokenArrayLength = tokenArray.length;
		for (String token : tokenArray) {
			token = token.trim();
			int tokenLength = token.length();
			// La taille d'un token est limitée à 64 caractères
			if (tokenLength != 64) {
				throw new CamelException("Token has wrong size['" + tokenLength + "']: " + token);
			}
		}
		List tokens = Arrays.asList(tokenArray);
		return tokens;
	}
}

Une fois la notification envoyée aux serveurs APNS, le terminal Apple recevra la notification et l’affichera comme suit dans le cas d’une notification texte:

La classe ApnsConsumer

La classe ApnsConsumer a pour objectif de nous permettre de consommer le flux feedback renvoyé par les serveurs APNS, permettant de connaître les terminaux mobiles Apple pour lesquels il n’est plus nécessaire d’envoyer de notifications (Par exemple, lorsque l’application a été désintallée).

Comme vu précédemment, la stratégie de consommation peut suivre un pattern de type Event Driven Consumer ou bien de Polling Consumer. Ici, nous choisirons le pattern Event Driven Consumer, et nous étendrons la classe ScheduledPollConsumer qui prend en charge toute la complexité de la gestion de consommation des messages et nous laisse nous concentrer sur le principal, c’est à dire, fournir les messages à consommer par nos routes de traitement.

Pour cela, il suffit d’implémenter la méthode poll qui permet d’interroger le service feedback d’Apple selon le timing d’interrogation configuré par l’URI.

C’est la classe ApnsEndpoint, qui au moment de la création de l’objet ApnsConsumer, configurera les paramétrages de polling à partir des paramètres récupérés via l’URI.

La méthode doStart aura pour rôle de vérifier qu’un seul objet ApnsConsumer est créé afin de ne pas consommer en double les messages d’une même configuration de l’ApnsService.

La méthode poll est implémentée ici de façon à récupérer les informations sur les appareils pour lesquels il ne faut plus envoyer de notifications. Pour cela, nous récupérons dans un premier temps une liste d’objets InactiveDevice renvoyés par le flux feedback de l’APNS, puis nous itérons sur cette liste pour les faire traiter par le processor Camel, qui n’est autre que la route de traitement Camel.

public class ApnsConsumer extends ScheduledPollConsumer {
	private static final int DEFAULT_CONSUME_INITIAL_DELAY = 10;
	private static final int DEFAULT_CONSUME_DELAY = 3600;
	private static final TimeUnit DEFAULT_CONSUME_TIME_UNIT = TimeUnit.SECONDS;
	private static final boolean DEFAULT_APNS_FIXED_DELAY = true;
	/**
	 * La configuration par défaut des paramètres de polling est fait lors de la
	 * construction de l'objet. Ces valeurs pourront être écrasées par des valeurs
	 * configurées via l'URI.
	 */
	public ApnsConsumer(ApnsEndpoint apnsEndpoint, Processor processor) {
		super(apnsEndpoint, processor);
		setInitialDelay(DEFAULT_CONSUME_INITIAL_DELAY);
		setDelay(DEFAULT_CONSUME_DELAY);
		setTimeUnit(DEFAULT_CONSUME_TIME_UNIT);
		setUseFixedDelay(DEFAULT_APNS_FIXED_DELAY);
	}
	/**
	 * Chaque élément de cette liste obtenue par l'appel de la méthode  getInactiveDevices()
	 * sera passé à la route Camel via l'appel de la méthode getProcessor().process(e)
	 */
	protected void poll() throws Exception {
		List inactiveDeviceList = getInactiveDevices();
		Iterator it = inactiveDeviceList.iterator();
		while(it.hasNext()) {
			InactiveDevice inactiveDevice = it.next();
			Exchange e = getEndpoint().createExchange();
			e.getIn().setBody(inactiveDevice);
			// On donne chaque élément de la liste de terminaux inactifs
			// reçu sur le flux feedback pour qu'il soit traité par la route associée
			getProcessor().process(e);
		}
	}
	/**
	 * La méthode getInactiveDevices() permet d'obtenir depuis le flux feedback une
	 * liste d'objects InactiveDevice.
	 */
	private List getInactiveDevices() {
		ApnsEndpoint ae = (ApnsEndpoint)getEndpoint();
		Map inactiveDeviceMap = ae.getApnsService().getInactiveDevices();
		List inactiveDeviceList = new ArrayList();
		for (Entry inactiveDeviceEntry : inactiveDeviceMap.entrySet()) {
			String deviceToken = inactiveDeviceEntry.getKey();
			Date date = inactiveDeviceEntry.getValue();
			InactiveDevice inactiveDevice = new InactiveDevice(deviceToken, date);
			inactiveDeviceList.add(inactiveDevice);
		}
		return inactiveDeviceList;
	}
    @Override
	public ApnsEndpoint getEndpoint() {
		return (ApnsEndpoint)super.getEndpoint();
	}
	/**
	 * La consommation du flux feedback doit être faite par un unique consumer.
	 * La méthode doStart permet de s'enassurer lors du démarrage.
	 * Si un autre consumer est déjà déclaré, alors une exception sera lancée.
	 */
    @Override
    protected void doStart() throws Exception {
        // only add as consumer if not already registered
        if (!getEndpoint().getConsumers().contains(this)) {
            if (!getEndpoint().getConsumers().isEmpty()) {
                throw new IllegalStateException("Endpoint " + getEndpoint().getEndpointUri() + " only allows 1 active consumer but you attempted to start a 2nd consumer.");
            }
            getEndpoint().getConsumers().add(this);
        }
        super.doStart();
    }
    @Override
    protected void doStop() throws Exception {
        super.doStop();
        getEndpoint().getConsumers().remove(this);
    }
}

Conclusion

Nous avons vu dans cette seconde partie comment implémenter les classes nécessaires au développement d’un composant Apache Camel. Nous verrons dans une dernière partie comment mettre en place différentes stratégies de test pour valider notre composant.

Liens utiles

Le site google code du composant ‘camel-apns’ présenté dans l’article :

http://code.google.com/p/camel-apns

Parties suivantes et précédentes de l’article :

Créer un composant Apache Camel de connexion à l’APNS – 1 sur 3

Alexis Kinsella — Thu, 30 Sep 2010 07:12:01 +0000

Le projet Apache Camel est un framework d’intégration basé sur l’implémentation de patterns d’intégration d’entreprise connus. Il permet d’implémenter des règles de routage et de médiation à partir d’un DSL Java ou bien via des configurations Spring au format Xml.

Apache Camel utilise la notion d’URIs, ce qui permet de travailler facilement avec différents types de transport ou modèles d’échange de messages, tels que HTTP ou JMS. De la même manière, Apache Camel est capable de travailler avec différents formats de données (Csv, Xml, Json, …).

L’utilisation des composants fournis out of the box permet de travailler avec de nombreux protocoles et formats de données. Mais qu’en est-il lorsqu’un connecteur vient à manquer?

Pour répondre à cette question, le projet Apache Camel propose une API complète permettant d’implémenter soi-même des composants adaptés à son besoin.

Objectif

L’objectif de cet article est de présenter comment initier le développement d’un composant Apache Camel.

Pour cela, nous mettrons en place un composant qui permettra de dialoguer avec l’Apple Push Notification Service, dans le but d’envoyer des notifications aux différents terminaux Apple (iPad, iPhone, iPod Touch).

Le composant proposera à la fois des endpoints de type producer et de type consumer qui permettrons respectivement d’envoyer des notifications et de lire un flux feedback d’informations en provenance de l’APNS.

En pré-requis, un ensemble de endpoints devra utiliser une même instance de la classe ApnsService proposée par la librairie java-apns, qui permet de dialoguer avec les serveurs d’Apple. La firme à la pomme préconise en effet de créer un nombre limité de connexions, et de réutiliser celles-ci pour communiquer avec ses serveurs. Nous utiliserons également le scheme apns pour déclarer les URIs qui représenteront les endpoints gérés par nos composants.

Présentation de l’APNS

L’Apple Push Notification Service est disponible pour les applications destinées aux iPhones, iPads et iPods touch. Il permet d’envoyer des notifications de 3 types : texte, image ou badge.

Pour envoyer une notification, un provider (une application serveur en général) doit en premier lieu envoyer la notification à l’Apple Push Notification Service qui se chargera à son tour de diffuser la notification aux terminaux concernés.

La notification est composée d’un token (identifiant unique d’un terminal) et d’un payload (contenu de la notification).

L’APNS propose en complément de l’envoi de notifications, un flux feedback d’informations permettant de connaître la liste des terminaux pour lesquels les notifications n’ont pu être délivrées de façon répétée (généralement, lorsque l’application a été désinstallée).

Pour qu’une application iOS soit en mesure de recevoir des notifications, elle doit en premier lieu fournir à l’application serveur (celle qui va envoyer les notifications aux serveurs Apple) toutes les informations nécessaires notamment son token d’identification. Cette opération peut-être réalisée, par exemple, via un simple appel HTTP.

API Java de connexion à l’APNS

De nombreux projets permettent de dialoguer avec l’APNS via différents langages de programmation. Actuellement deux implémentations existent pour le langage Java :

java-apns sur GitHub, et
javapns sur Google Code.

Historiquement, l’implémentation javapns est apparue avant java-apns. Cependant nous choisirons d’utiliser la librairie java-apns qui a pour avantage de proposer des fonctionnalités complètes (gestion de pool de connections, capacité de reconnexion, …), ainsi qu’une API élégante et différentes facilités d’écriture de tests unitaires.

Les endpoints Camel

Le développement d’un endpoint Apache Camel implique d’implémenter une ou plusieurs des méthodes suivantes selon les besoins :

Méthode	Description
createProducer()	Crée un producer permettant d’envoyer des messages à un endpoint
createConsumer()	Crée un consumer implémentant le pattern Event Driven Consumer pour consommer des messages depuis un endpoint
createPollingConsumer()	Crée un consumer implémentant le Polling Consumer pour consommer des messages depuis un endpoint

L’Event Driven Consumer

Ce modèle événementiel de consommation des messages correspond au modèle de consommation par défaut des messages par les composants Camel.

Le Polling Consumer

Le polling consumer propose 3 types de méthodes:

Méthode	Description
receive()	Attend qu’un échange soit disponible et le retourne (potentiellement indéfiniment)
receive(long)	Attend un échange jusqu’à un timeout défini. Renvoie null si aucun échange n’a été reçu dans le temps imparti
receiveNoWait()	Tente de recevoir un message sans attendre de timeout et retourne null si aucun échange n’est disponible

Le composant camel-jms implémente cette notion de polling-consumer pour s’intégrer à Apache Camel.

Générer un squelette de composant

Partir de zéro pourrait s’avérer compliqué. Heureusement le projet Apache Camel met à disposition l’archétype Maven: camel-artefact-component.

mvn archetype:create
-DarchetypeGroupId=org.apache.camel.archetypes
-DarchetypeArtifactId=camel-archetype-component
-DarchetypeVersion=2.3.0
-DgroupId=org.apache.camel
-DartifactId=camel-apns

L’exécution de la ligne de commande précédente va créer un squelette de composant sur lequel s’appuyer pour développer notre composant:

L’archétype va générer la structure nécessaire au développement du composant Camel. Cependant il sera nécessaire de personnaliser le composant nouvellement créé pour qu’il corresponde au nommage souhaité :

‘META-INF/services//direct’ devra être renommé selon le scheme de l’URI de votre composant (Dans notre cas: ‘apns’).
Les différentes classes générées seront préfixées par ‘Apns’ plutôt que ‘Direct’.

Il est possible de supprimer les classes qui ne seraient pas utilisées dans le cas où le composant serait uniquement destiné à consommer des messages ou à bien en produire.

Après renommage, le résultat obtenu doit être le suivant :

Importer son composant dans Eclipse

Pour cela, il est possible d’utiliser la commande suivante:

mvn eclipse:eclipse

Le fichier pom.xml

Il est conseillé d’hériter du projet parent camel-parent:


	org.apache.camel
	camel-parent
	2.4.0

Le composant camel-parent déclare en effet un certain nombre de dépendances nécessaires, ainsi que le type bundle qui permet d’OSGifier son composant. Ceci permettra aux utilisateurs/développeurs de le déployer dans un conteneur OSGi, tel qu’Apache ServiceMix.

Nous allons donc déclarer le packaging du composant, ainsi que différentes propriétés nécessaires à l’OSGificiation comme suit:

bundle
...

	...
	
	
	!
	${camel.osgi.export.pkg}*;version=${camel.osgi.export.version}
	${project.version}
	${camel.osgi.import.pkg}
	${groupId}.${artifactId}

Il est également nécessaire de déclarer les dépendances Camel dont nous aurons besoin, ainsi que les dépendances nécessaires à l’implémentation du composant:


	...
	
	
		org.apache.camel
		camel-core
		${camel.version}
	
	
		org.apache.camel
		camel-spring
		${camel.version}
	
	
		org.apache.camel
		camel-test
		${camel.version}
		test
	
	...
	
	
		com.notnoop.apns
		apns
		${apns.version}
		
			
				ch.qos.logback
				logback-classic
			
		
	
	...

Le projet Apache Camel propose le plugin camel-maven-plugin que nous allons déclarer dans notre fichier pom. Celui-ci permet de lancer en ligne de commande une instance standalone d’Apache Camel et de démarrer les routes qui sont déclarées dans le classpath via le fichier Spring suivant: ‘META-INF/spring/camel-context.xml’.



	org.apache.camel
	camel-maven-plugin
	${camel.version}

Plusieurs entrées repository et pluginReposity doivent également être déclarées dans le pom afin que Maven puisse importer différentes dépendances et plugins nécessaires à notre projet:


	
		open.iona.m2
		IONA Open Source Community Release Repository
		http://repo.open.iona.com/maven2
		
			false
		
		
			true
		
	
	
		open.iona.m2-snapshot
		IONA Open Source Community Snapshot Repository
		http://repo.open.iona.com/maven2-snapshot
		
			true
		
		
			false
		
	
	
	
		notnoop-repos
		http://notnoop.github.com/m2-repo
	
	...
	
		apache.incubating.releases
		Apache Incubating Release Distribution Repository
		http://people.apache.org/repo/m2-incubating-repository
	


	
		open.iona.m2
		IONA Open Source Community Release Repository
		http://repo.open.iona.com/maven2
		
			false
		
		
			true
		
	
	
		open.iona.m2-snapshot
		IONA Open Source Community Snapshot Repository
		http://repo.open.iona.com/maven2-snapshot
		
			true
		
		
			false
		
	
	
		maven-repository.dev.java.net
		Java.net Maven 2 Repository
		http://download.java.net/maven/2

Conclusion

Nous avons vu dans cette première partie comment initier le développement d’un composant Camel à l’aide de l’archétype Maven camel-archetype-component.

Dans un prochain billet, nous verrons comment implémenter les différentes classes d’un composant Camel. Puis nous conclurons dans une troisième et dernière partie, par la présentation des méthodes permettant de tester notre composant afin de fournir un livrable de qualité.

Liens utiles:

Le site google code du composant camel-apns présenté dans cet article:

http://code.google.com/p/camel-apns

Parties suivantes de l’article :

Revue de Presse Xebia

Xebia France — Tue, 06 Jul 2010 05:14:27 +0000

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

Actualité éditeurs / SSII

Une étude américaine prédit une pénurie d’informaticiens pour bientôt.

SOA

La future version 1.4 de Smooks supportera les messages UN/EDIFACT

Serveurs d’applications / Cloud Computing

Le coin de la technique

Hibernate Validator 4.1.0

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

Le ParisJUG et l’AvantJUG

Actualité éditeurs / SSII

Une étude américaine prédit une pénurie d’informaticiens pour bientôt.

C’est à la fois une bonne et une mauvaise nouvelle qui est sortie d’un étude américaine sur le marché de l’informatique, rapportée par infoQ : la bonne nouvelle, elle est pour les techniciens que nous sommes, car nous devrions avoir du travail pendant un long moment. La mauvaise nouvelle est pour nos employeurs, qui vont avoir de plus en plus de mal à recruter.
Les prévisions qui ressortent de cette étude sont les suivantes :

la croissance du secteur informatique devrait être quatre fois supérieure à celle des autres métiers de l’ingénierie dans les années à venir.
aux Etats Unis, il y a deux fois plus d’offres que de diplômés chaque année. C’est le seul métier scientifique pour laquelle l’offre est supérieure à la demande.

En parallèle de l’augmentation des besoins, il semble que les étudiants percoivent les métiers de l’informatique de manière erronée :

Tous les postes motivant sont exportés en Inde. Le mouvement global (aussi bien aux Etats Unis qu’en Europe) est plutôt à un retour des activités intéressantes en local, et une exportation des taches à faible valeurs ajoutées.
C’est un métier d’homme. Ce fait avéré est en train de changer, en partie grâce à certaines initiatives locales (voir ci-dessous). Même si la balance est loin d’être équilibrée, il semblerait que de plus en plus de demoiselles choisissent les carrières techniques. C’est à nos communautés de les convaincre de les poursuivre !
L’informatique, c’est programmer, et programmer c’est rester toute la journée devant un écran. Tous les consultants vous le diront, même si ils ne pratiquent pas l’XP, l’informatique est une activité sociale
C’est trop difficile. S’il est sûr que comprendre les algorithmes de GC en détail relève parfois de la mission impossible, tous les chefs de projets ou scrum master vous le diront : travailler dans l’informatique, c’est avant tout gérer son stress, gérer ses connaissances (et les augmenter au fur à et mesure) et se montrer inventif.

Il existe ainsi un certain nombre de mythes, que certains professeurs américains tentent de démonter.

Les défis à venir sont énormes, puisqu’il va falloir réconcilier le désamour des étudiants pour les carrières informatiques, et les besoins des entreprises qui s’annoncent énormes. Bien heureusement, un certain nombre d’acteurs français essayent de proposer une vision du marché de l’informatique plus humaine que d’autres.

A ce propos, vous savez que Xebia recrute ?

SOA

La future version 1.4 de Smooks supportera les messages UN/EDIFACT

L’équipe de développement de Smooks vient d’annoncer le support du traitement des messages EDI (Échange de Données Informatisées) au format UN/EDIFACT Interchange, dans la future version du projet.

Pour rappel Smooks est un framework Java offrant un moteur de traitement des données XML et non XML (CSV, EDI, Java, etc.). Il est capable d’effectuer des transformations de données en s’appuyant sur des transformations existantes, ou en utilisant des technologies de templating telles que XSLT, Freemarker, StringTemplate, etc. Smooks permet également d’analyser un flux de données afin de remplir un modèle d’objets Java (Java Bean Binding).

Le framework Smooks peut prendre en charge les modèles de traitement DOM et SAX, ce qui signifie qu’il est capable de traiter aussi bien un fichier qu’un flux de données.

Ainsi, les messages EDI pourront être traités grâce à deux nouvelles fonctionnalités :

Un module de lecture dédié au format UN/EDIFACT Interchange (), qui permettra de transformer un message EDI de manière automatique dans un format XML compréhensible par le moteur de traitement de Smooks.

Un outil pour Maven et ANT, appellé EDI Conversion Tool (ECT), embarquant directement les référentiels UN/EDIFACT, et offrant la possibilité de générer un Jar contenant les fichiers de mapping Smooks correspondant au message EDI traité.

Avec ces nouvelles fonctionnalités, Smooks propose une véritable alternative Open Source et performante aux solutions propriétaires pour le traitement des messages EDI au format UN/EDIFACT. Déjà intégré au sein de Mule ESB et de JBoss ESB, Smooks devient de plus en plus incontournable au sein des architectures SOA s’appuyant sur des solutions Open Source.

Ces nouveautés sont déjà disponibles dans la version 1.4-SNAPSHOT, téléchargeable directement depuis le repository Maven du projet.

Pour en savoir plus :

Serveurs d’applications / Cloud Computing

Tomcat 7 sort en BETA

Après 18 mois de travail, Apache nous livre la première version officielle de Tomcat 7. Cette nouvelle release est désormais disponible dans les pages de téléchargements du site http://tomcat.apache.org qui intègre pour l’occasion la documentation du précieux. Comme promis de longue date, Tomcat 7 implémente les Servlet 3.0, ainsi que JSP et EL 2.2.

A ces mises à niveau s’ajoutent de nouvelles fonctionnalités:

Détection et prévention des fuites de mémoire, pour en finir avec les OutOfMemory au rechargement des applications web liés à l’utilisation du PermGen. Ce développement avait été porté sur Tomcat 6, début avril, le voilà disponible tout naturellement sur Tomcat 7.
La sécurité est aussi largement améliorée avec notamment un filtre permettant de bloquer les attaques de type Cross Site Request Forgery. C’est aussi une nouvelle gestion des rôles pour Tomcat Manager et Host Manager.
La gestion d’alias de répertoire à la mode apache.
Enfin, la possibilité d’embarquer et de lancer Tomcat simplement, ce qui ne manque pas de faire penser à Jetty.

Outre toutes ces nouveautés, le code a subi une vaste cure de nettoyage et l’équipe affirme avoir porté toutes les corrections de bugs des versions précédentes dans Tomcat 7. Nous en reparlerons sûrement sur le blog, en attendant, n’hésitez pas, faites le tour du propriétaire et sachez apprécier la nouvelle décoration.

Pour en savoir plus:

Google App Engine 1.3.5 et toolkit Paypal

La sortie de Google App Engine en version 1.3.5 apporte comme à son habitude son lot de nouveautés et de corrections pour les développeurs Java et Python:

Une amélioration de la Task Queue API permettant de traiter 50 reqs/sec par queue au lieu de 50 reqs/sec par application. Google promet d’ailleurs de futures améliorations de scalabilité relatives à cette API.
Le support pour la précompilation de fichiers sources Python
Une amélioration de l’API BlobStore permettant la lecture d’un blob tel un fichier avec une classe BlobstoreInputStream.

La réelle nouveauté vient cependant de PayPal annonçant le support de sa plateforme de paiement PayPal X pour GAE.

A travers sa plateforme PayPal X, le leader du micro-paiement sécurisé propose une API clé en main, permettant aux développements d’embarquer différentes solutions de paiement dans leurs applications via différents modèles de monétisation: Le freemium, les abonnements, le pay-per-use, les micro transactions. PayPal souhaite ainsi fournir une solution de paiement adaptée à tous les besoins.

Grâce à ce nouveau service orienté e-commerce et entreprise, le géant de Moutain View espère bien profiter de la demande croissante des entreprises envers l’hébergement d’applications sur une architecture cloud, et continuer de développer son offre destinée aux entreprises.

Pour en savoir plus:

Le coin de la technique

Hibernate Validator 4.1.0

Outre quelques corrections de bugs et améliorations de performance au niveau de certains parsings, cette version d’Hibernate Validator fournit de nouvelles fonctionnalités intéressantes, assez bien détaillées sur le blog de Gunar Morling, un des développeurs du projet.

Pour commencer, quelques types de contraintes ont été ajoutés:

@CreditCardNumber : permet de valider un numéro de carte de crédit selon l’algorithme de Luhn
@NotBlank : Le champ ne doit être ni null, ni vide, ni contenir que des espaces
@URL : valide une URL, on peut préciser le protocole, http par exemple
@ScriptAssert : cette contrainte permet de déléguer à un langage script tiers la validation du champ, ceci étant rendu possible grâce à la JSR-223 permettant l’intégration de languages de script dans Java (à partir de la version 1.6). Plus de détail ici

De plus il est possible maintenant de choisir sa propre stratégie pour récupérer les ResourceBundle, pour par exemple associer un message d’erreur à un champ. Il suffit pour cela de fournir une implémentation de l’interface ResourceBundleLocator qui contient une méthode retournant un ResourceBundle. On peut donc par exemple stocker ces messages dans une base de données.

Enfin cette version introduit la possibilité de créer des contraintes programmatiquement. Voici un exemple qui vient de la documentation:

ConstraintMapping mapping = new ConstraintMapping();
mapping.type( Car.class ).property( "manufacturer", FIELD ).constraint( NotNullDef.class )
   .property( "licensePlate", FIELD ).constraint( NotNullDef.class )
   .constraint( SizeDef.class ).min( 2 ).max( 14 )
   .property( "seatCount", FIELD ).constraint( MinDef.class ).value ( 2 )
   .type( RentalCar.class ).property( "rentalStation", METHOD).constraint( NotNullDef.class );

On utilise le principe des méthodes chainées, ça rappelle de loin les Criteria d’Hibernate. Entre cette possibilité et celle des @ScriptAssert, l’utilisateur a désormais deux nouveaux outils pour exprimer des contraintes relativement complexes.

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

Le ParisJUG et l’AvantJUG

Ce mardi aura lieu la soirée du ParisJUG comme tous les deuxièmes mardis du mois. Au programme de cette soirée, les EJB 3 présenté par Adam Bien. Vous voulez avoir une idée du contenu de la soirée ? Alors lisez le billet publié par le blog des JDuchess France qui résume les concepts que présentera Adam Bien ce soir là.
Comme depuis quelques mois déjà, le ParisJUG sera précédé de l’AvantJUG. C’est un évènement organisé par les JDuchess France pour faire connaissance avant de débuter la soirée du Paris JUG. A l’origine pour inciter les femmes à venir au Paris JUG, cette rencontre est ouvert à tous ceux qui veulent discuter et partager. Si vous voulez avoir une bonne excuse pour motiver une collègue à venir au ParisJUG ou tout simplement échanger autour d’un verre, venez donc à l’AvantJUG ! Toutes les modalités pour l’inscription se trouvent ici.

Revue de Presse Xebia

Xebia France — Mon, 19 Apr 2010 16:49:05 +0000

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

Agilité

SOA

RabbitMQ racheté par SpringSource

Le coin de la technique

Agilité

Comment faire des tests d’IHM sans se tirer une balle dans le pied ?

L’automatisation des tests d’IHM est souvent une mauvaise idée. Le constat est très souvent le même : bien que simple à mettre en place en général, leur apport est souvent mineur par rapport à leur coût (je vous dirige vers l’excellent article de Robert Martin pour creuser le sujet). Comment faire si l’on veut cependant s’engager dans cette voie?
Dans cet article, Gojko Adzic (commiter fitnesse et auteur du livre passionnant « Bridging the communication gap« ), nous livre des pistes pour maximiser le retour sur investissement sur ceux-ci. Tout d’abord, ne surtout pas partir sur de l’enregistrement brut des cas de tests les uns après les autres (avec Selenium IDE par exemple). C’est dans ce cas-là que l’on se tire une balle dans le pied. Les coûts de maintenance explosent et l’intérêt des tests est remis en question au fil du temps.
La clé est de représenter les tests d’IHM sur plusieurs niveaux :

Règles métiers
Worfklows
Technique

Les niveaux supérieurs sont plus stables dans le temps et sont plus compréhensibles que ceux du dessous. Les niveaux supérieurs s’appuient bien évidemment sur les niveaux du dessous pour fonctionner.
Le but de cette approche est de faire en sorte que les tests restent compréhensibles (bon courage pour aller comprendre la règle métier cachée derrière une centaine d’instructions Selenium) et surtout de promouvoir la réutilisabilité afin de garder la main sur la maintenance des tests.

La gestion des risques dans un projet agile

Mike Cohn, scrum master certifié et auteur de nombreux ouvrages de référence, nous suggère une manière de mettre en place la gestion des risques sur un projet agile.
Le management des risques est un sujet central dans de nombreux projets et est souvent considéré comme un enjeu déterminant pour leur réussite.
Il existe un ensemble de méthodes dédiées, ainsi que des normes et pratiques pour limiter les risques.
Au premier abord, on peut constater que Scrum n’implémente pas vraiment une gestion spécifique des risques. Cependant, les différentes pratiques et outils mis en place comme: les itérations courtes, l’intégration continue, les tests automatisés, etc. permettent de limiter drastiquement l’apparition des risques.
Ainsi, la mise en place d’une gestion des risques sur des projets agiles ayant des facteurs de risque faibles n’est pas nécessaire. Pour les autres projets, Mike nous propose une solution introduite par John Brothers dans The Agile Times avec le risk burndown chart.

Pour obtenir ce graphique, il convient au préalable de faire un recensement des risques (durant un sprint planning par exemple). On évalue la probabilité d’apparition, l’impact en jours sur la livraison si celui-ci se réalise, et enfin le nombre de jours exposés à ce risque potentiel. Pour calculer ce dernier, Mike multiplie la probabilité du risque par l’impact en nombre de jours. Ces informations sont renseignées dans un tableau de recensement.
Pour générer le risk burndown chart, il suffit ensuite de positionner la colonne du nombre de jours exposés en ordonnée et le nombre de jours (ou de sprints) en abscisse. On constate alors que plus on avance dans les sprints, moins le projet est exposé à des risques.

Sans tomber dans le sur-outillage, la mise en place d’un risk burndown chart permet d’introduire de manière légère la gestion des risques. Le tableau de recensement des risques peut suffire.

SOA

RabbitMQ racheté par SpringSource

Deux nouvelles importantes ces derniers jours autour d’AMQP, une bonne et une mauvaise.

La bonne nouvelle pour AMQP, c’est le rachat (ici, ici et là) par VMWare de RabbitMQ, rejoignant ainsi la gamme de produit SpringSource. Ceci donne l’occasion à Rod Johnson de donner son point de vue. Les efforts de RabbitMQ pour s’intégrer à des solutions cloud semblent avoir été déterminants pour VMWare. L’aspect standardisation par contre apparait moins dans les différentes annonces et il est sûrement encore trop tôt pour savoir quel sera l’investissement de SpringSource dans le groupe de travail d’AMQP. Néanmoins AMQP profitera sûrement de l’aura de Spring dans la communauté Java et ça ne peut être qu’une bonne nouvelle pour ce standard. Par contre OpenCredo, qui tente de faciliter les solutions AMQP en Java et propose entre autres un template Spring pour RabbitMQ, risque d’être une victime collatérale de cette nouvelle association.

Ensuite la mauvaise nouvelle. IMatix, qui a créé OpenAMQ, la première implémentation de ce standard, a l’intention d’arrêter son support en 2011. 0MQ, acheté il y a quelques mois, remplacera ce produit. Par la même occasion, ils cesseront de participer au groupe de travail AMQP. Outre le fait que 0MQ parait avoir des performances très supérieures à OpenAMQ, il semble que l’inertie autour de la nouvelle version de la norme AMQP/1.0 ait fini par éteindre l’enthousiasme des dirigeants d’iMatix. D’ailleurs, on peut trouver sur leur site un article intéressant sur les arcanes du groupe de travail. Il apparait qu’à vouloir spécifier trop de choses le standard deviendrait beaucoup trop complexe et que le retard pris sur la livraison de la nouvelle version serait dû à des considérations plus humaines que techniques, laissant entendre que l’ambiance n’y est peut-être pas toujours très détendue.

Le coin de la technique

Billy Newport et la programmation parallèle

Billy Newport, un des acteurs majeurs de la programmation distribuée, a donné une interview à InfoQ dans le cadre de Qcon.
Il y parle de programmation parallèle en Java, selon lui l’avenir de notre langage.
La tendance actuelle dans le hardware est à la multiplication des cœurs, mais au ralentissement de leur fréquence. Et contrairement à ce que semblent penser certaines équipes d’exploitation (nous avons des noms), la multiplication des cœurs ne permettra pas aux applications Web de traiter plus d’utilisateurs, plus vite (bien au contraire, puisque unitairement, les cœurs sont moins puissants).

Le problème que Billy Newport voit dans l’écosystème actuel est l’absence complète d’un framework de haut niveau pour faciliter la programmation parallèle (qui reste une arcane secrète réservée aux grand maîtres). Il existe bien un certain nombre d’outils pour gérer le comment implémenter des traitements parallèles :

les grilles de calculs en mémoire, comme eXtrem Scale.
les traitements massifs de fichiers, comme Hadoop.

Malheureusement, aucune de ces solutions ne propose d’API de haut niveau qui permettrait de décrire les traitements à appliquer aux données quelle que soit l’implémentation « physique » mise en place. De plus, il semblerait que bien peu de personnes travaillent dans la recherche sur ce sujet. Billy Newport y voit là une superbe opportunité pour créer la prochaine entreprise à la mode dans l’open source.
Proposer une API de haut niveau qui proposerait de décrire les traitements et la façon de les appliquer aux données, en permettant de s’abstraire de la tuyauterie classique de la programmation parallèle :

Gérer les structures de données et la concurrence autour de ces données.
Gérer la distribution optimisée des traitements (afin que le gain de temps réalisé en utilisant un cœur distant ne soit pas perdu en temps d’IO par exemple).

Selon lui, les mécanismes existant en Java posant les prémices du calcul massivement parallèle (les Actors en Scala par exemple) sont de trop bas niveau.
Afin de pouvoir faire de la programmation parallèle sans avoir à connaitre toutes les implémentations sur le bout des doigts, il faudrait que Java adopte une réflexion comme celle que les auteurs de Haskell et Erlang ont mené (et non pas des recherche sur des mécanismes de primitives comme Scala)

D’autres problématiques vont apparaitre, notamment à cause des mécanismes d’auto découverte des nœuds d’une architecture distribuée (il existe plusieurs parades, comme changer les ports standard ou bien utiliser un mécanisme déclaratif).

Bref une entrevue passionnante, dont vous trouverez l’intégralité en video, mais également en transcript, peut être plus accessible pour les anglophobes.

Performance jQuery avec $.delegate()

Voilà une petite astuce jQuery plutôt intéressante pour gagner en performance sur votre site web si vous êtes déjà, tout comme moi , un accro de la fonction live (via ce site).

Pour la gestion des évènements, nous avons la méthode bind qui permet d’associer à un élément de notre page un évènement de type click, change, focus… Mais bind ne s’appliquera que sur les éléments explicitement retournés par le sélecteur. Ainsi, même si nous spécifions un sélecteur du type $('a') (tous les éléments a de la page), les éventuels éléments a qui seraient créés plus tard dans la page ne seront pas pris en compte.

Pour cela, jQuery 1.4 introduit la méthode live qui est un bind présent et futur. En effet, il s’applique sur tous les éléments retournés par le sélecteur mais aussi sur tous les éléments futurs de la page qui matcheront avec ce sélecteur ! Une fonctionnalité très intéressante donc mais aussi très consommatrice si l’on a un DOM important. En effet, le sélecteur parcourt à chaque fois le document pour matcher les nouveaux éléments et leurs associer l’évènement.

Mais c’est sans compter sur delegate qui est un live voisin. Ainsi, plutôt que de matcher tous les éléments a de ma page, delegate va s’appliquer sur un élément parent (et donc restreint) et, de cet élément parent, rechercher un certain élément sur lequel binder l’évènement. Imaginons que notre a soit inclus dans un élément ayant l’id container, on pourra alors écrire :

$('#container').delegate('a', 'click', function() {...})

Une écriture quelque peu différente donc mais un véritable gain sur un DOM conséquent. A essayer d’urgence !

Faille de sécurité dans Oracle Java

Oracle Java a sorti une nouvelle mise à jour du JDK et du JRE 6 suite à une alerte de sécurité sur le Java Deployment Toolkit utilisé pour Java Web Start. Tavis Ormandy et Ruben Santamarta ont découvert simultanément la possibilité d’exécuter du code arbitraire à travers cette faille et ont alerté la communauté le 9 avril dernier. Ce problème existe depuis la version 1.6.0_10 et est dû à un certain laxisme sur la vérification du paramètre « codebase » dans le JNLP qui devient maintenant obligatoire. Bien que ce problème impacte potentiellement les environnements Linux, Windows semble plus vulnérable, donnant par exemple la possibilité de charger une DLL. Par contre il ne concerne pas les Mac. Oracle a commencé par minimiser la gravité du problème avant finalement de sortir cette mise à jour une semaine après sa découverte. Il est donc fortement conseillé de se mettre à jour.

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, 21 Dec 2009 20:25:00 +0000

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

Actualité éditeurs / SSII

Agilité

SOA

Gouvernance implicite et explicite dans une SOA

Le coin de la technique

Les optimisations se succèdent sur OpenJDK 7

Actualité éditeurs / SSII

Thoughtworks murmure la sortie de Mingle 3.0

Thoughtworks Studios, la partie éditeur de logiciels de Thoughtworks, annonce la sortie d’une nouvelle version majeure de son outil de gestion de projet agile : Mingle.

« Les nouvelles fonctionnalités de Mingle 3.0 permettent de transformer des échanges non structurés en mine d’informations à utiliser pour le développement… » annonce Chad Wathington (vice président de Thoughtworks Studios) :

Amélioration de la collaboration à l’intérieur de l’équipe : Mingle intègre une nouvelle plate-forme de communication appelée Murmurs.

Les échanges informels (du type messages instantanés ou emails) autour du développement d’une fonctionnalité sont associés en temps réel à une card Mingle. Ainsi tous les échanges sont conservés et aucune information n’est perdue dans les différents canaux de communication. L’intégration avec Jabber Chat est fournie.

Une fonctionnalité autour de la collaboration fait effet d’annonce. Thougtworks Studios propose une intégration avec le tout dernier moyen d’échanger des informations : Google Wave. Il sera alors possible de manipuler des cards (créer, changer de statuts…) directement depuis une Wave et de référencer du contenu de Wave pour le retrouver directement dans Mingle. Attention cependant, cette fonctionnalité sera seulement disponible courant 2010 (les bas de page sont, dans ce cas, à lire attentivement).

Les autres évolutions apportent de la flexibilité et des outils pour les grosses structures :

Pour le reporting et l’extraction de données, cette version fournit au manager une vision agrégée et multi-projets pour faciliter par exemple l’affectation des ressources ou encore la copie de Cards entre différents projets.
Dans la même voie, Mingle améliore sa boite à outils de développement de macro afin de proposer la recherche de données multi-projets ainsi qu’une macro d’exemple.
Mingle 3.0 supporte dorénavant le clustering pour les organisations de grosse taille.
Amélioration de l’intégration avec des applications extérieures en fournissant des API plus complètes pour manipuler les données de Mingle et une mise à jour du connecteur Subversion pour supporter la version 1.6.5

Mingle est déjà mature en version 2.3.1, et il se présente comme un des meilleurs outils de gestion de projet agile (gestion façon Kanban des user stories, customisation du workflow de développement, extraction de données simple, reporting…).
En tant qu’utilisateurs de Mingle, l’agrégation des échanges informels nous semble cependant une avancée intéressante : ils deviennent un canal privilégié d’échange (surtout dans dans le cadre d’équipes distribuées) et sont souvent à l’origine de bonnes idées. En assurer le suivi et l’indexation au sein de l’outil principal de gestion du projet apporte indubitablement de la valeur ajoutée.

Spring 3.0 enfin finalisé !

Deux mois après un communiqué de presse qui avait semé la confusion lors de la conférence SpringOne G2X, SpringSource a finalement livré la version finale du framework Spring 3.0. Cette version se rapproche des standards Java, ou les standards se rapprochent de Spring comme vous préférez !

Plus sérieusement, c’est un pas important pour cette version de Spring qui est maintenant compatible Java EE 6.

De plus, Spring supporte plusieurs standards :

JSR-250 @ManagedBean, annotation permettant de scanner les composants annotés et ainsi injecter des ressources, gérer les intercepteurs et callbacks attachés
JSR-303 pour la validation du modèle par annotation
JSR-330 @Inject standardisation de l’injection de dépendances par annotation

Il y a de nombreuses nouveautés, en voici un panel :

Spring Expression Language (SpEL) (inspiré de Seam) est un langage EL (Expression Language) étendu comme on peut le trouver dans nos chères JSP.
Enrichissement des annotations, ce qui devrait calmer les détracteurs de Spring qui reprochaient la surconfiguration XML
Support REST (client et serveur) dans Spring MVC
etc …

Voici un exemple intéressant des capacités de SpEL, dans le fichier de configuration XML de Spring :

ou en java :

@Repository
public class RewardsTestDatabase {
@Value("#{systemProperties.databaseName}")
public void setDatabaseName(String dbName) { ... }
@Value("#{strategyBean.databaseKeyGenerator}")
public void setKeyGenerator(KeyGenerator kg) { ... }
}

Autre élément important, Spring ne supporte plus Java 1.4. En effet Spring couvre les environnements Java 1.5 et 1.6 et Servlet 2.4 et plus, soit Tomcat 5.x et 6.x, ainsi que WebSphere 6.1 et WebLogic 9.2 (qui sont officiellement toujours basés sur J2EE 1.4).

Donc en résumé rien de révolutionnaire, mais il y a quand même beaucoup de nouveautés qui méritent un coup d’oeil. N’hésitez pas à lire la documentation officielle de Spring pour toutes les découvrir .

Agilité

Quand le ScrumMaster est un obsctacle

Cette semaine, Vikas Hazrati, un de nos collègues indiens, nous gratifie (sur InfoQ) d’un article délicieusement subversif : et si le Scrum Master était un obstacle – un impediment pour utiliser un anglicisme barbare – majeur.
Reprenant plusieurs fils de discussions, InfoQ distingue trois types de ScrumMaster problématiques :

Le ScrumMaster développeur : il agit comme un membre de l’équipe de développement, s’implique fortement dans la réalisation du backlog. L’équipe devient alors spectatrice de l’avancée du projet.
Le ScrumMaster chef de projet : il dirige les travaux de l’équipe, qui devient totalement dépendante de ses consignes.
Le ScrumMaster tampon : il gère toutes les communications entre les développeurs et les products owners et / ou clients. Il devient rapidement un goulot d’étranglement. C’est un cas fréquent dans les projets Scrum distribués.

D’autres mauvaises habitudes se dégagent de ces discussions :

le manque d’anticipation : le ScrumMaster tient le journal des difficultés rencontrées, et même si il les lève, il ne fait rien pour les anticiper.
l’expertise à tout prix : le ScrumMaster s’implique dans toutes les tâches délicates et l’équipe devient dépendante de son aide. Rapidement, il est contraint par un manque de temps et devient un obstacle à la réalisation du sprint.
toucher à tout, et oublier son rôle : le ScrumMaster est majoritairement là pour aider l’équipe à avancer dans la réalisation des sprints. Toute tâche annexe à celle ci est consommatrice de temps et empêche l’accomplissement de sa mission principale.

Malgré toutes ces analyses pertinentes, si nous ne devions en conserver qu’une, ce serait celle de Tobias Mayer : donner à quelqu’un le titre de ScrumMaster ne suffit pas à ce qu’il en devienne un.

Kanban ou Scrum ? Kanban et Scrum !

InfoQ nous propose en téléchargement gratuit le livre Kanban et Scrum – making the most of both par Henrik Kinberg et Mattias Skarin.
L’objectif du livre est que vous puissiez comprendre (si ce n’est pas déjà fait) comment Kanban et Scrum pourraient être utiles dans votre environnement.
La première partie se consacre à une brève description de Kanban et Scrum (rôles, itérations…). Ils sont ensuite comparer directement mais aussi comparer à d’autres méthodes agiles. La deuxième partie est une étude de cas avec des questions, des réponses et beaucoup d’exemples : pourquoi changer ? Par où commencer ? Démarrage des équipes ? Comment estimer ? etc…
Pour la version papier, cela se passe par ici.

SOA

Gouvernance implicite et explicite dans une SOA

Andrej Koelewijn ouvre cette semaine une discussion intéressante sur la gouvernance dans une SOA. Il commence par expliquer le rôle incontournable qu’à la gouvernance dans le cadre de l’évolution correcte des services. Puis il explique qu’il y a, selon lui, deux manières d’aborder cette gouvernance, toutes deux étant idéalement appliquées conjointement :

La gouvernance explicite est celle dont il est en général question, il s’agit d’une personne ou d’un groupe de personnes en charge de s’assurer de la cohérence des services exposés dans la SOA au fil du temps. Ils ont alors le pouvoir de contraindre les équipes projets à se conformer aux règles définies en cas d’écart.
La gouvernance implicite ne passe pas par le contrôle effectué par une équipe ou une personne tierce mais par des choix architecturaux contraignant ou tendant à diriger naturellement vers les choix idéaux.

A titre d’exemple il cite ainsi l’affectation d’une base de données propre à chaque service de bas niveau, afin d’assurer un partitionnement fonctionnel strict ; des services de plus haut niveau peuvent alors couvrir plusieurs domaines fonctionnels en procédant par agrégation. Toujours dans le but d’assurer ce découpage propre, il suggère la mise en place d’équipes en charge de fonctionnalités, qui seront amenées à développer des services de haut niveau, collaborant avec des équipes en charge de services de bas niveau, qui, elles, font évoluer les services dont elles ont la charge aux fur et à mesure que les besoins sont exprimés.

Ces suggestions, imprégnées par l’expérience pratique, sont dans l’alignement des présentations actuelles sur SOA telles que celle de Nicolai Josuttis à Devoxx 09, dans lesquelles SOA y apparaît comme ayant dépassé le hype pour atteindre la maturité.

Le coin de la technique

Les optimisations se succèdent sur OpenJDK 7

Rémi Forax discute sur son blog de l’arrivée d’une nouvelle optimisation majeure au sein d’OpenJDK 7 : l’optimisation des l’ajout récent de l’escape analysis et de la compression de pointeurs.

Un tail call est une invocation positionnée en fin de bytecode d’une méthode, juste avant un return. En pratique, pour le développeur Java, il s’agit d’une ligne du type return m(data), où la valeur retournée est fonction d’une méthode tierce.

Lors de l’invocation d’une méthode, outre le saut de code nécessaire, la JVM doit également recréer un stackframe pour la nouvelle méthode en y copiant ses arguments. L’optimisation des tail calls consiste alors à supprimer cette opération sur la stack en réduisant l’invocation à un simple saut dans le code. Dans la mesure où cette simplification nécessite tout de même certaines précautions, une instruction de bytecode doit marquer l’invocation optimisée en tant que tail call auprès de la JVM.

Dans certaines applications présentant un grand nombre d’invocations de ce type, un gain de performance pourra apparaître lorsque cette optimisation sera activée. Celle-ci s’inscrit ainsi dans la continuité d’une présentation que Brian Goetz avait donnée lors de Devoxx 09 où il expliquait qu’un très grand nombre d’optimisations élaborées étaient effectuées par la JVM afin de réduire, ou de supprimer, le surcoût lié aux constructions courantes des langages objets.

Devoxx – Jour 2 – SOA en pratique

Michaël Figuière — Mon, 23 Nov 2009 14:09:15 +0000

Les sessions dédiées à SOA étaient présentes cette année encore à Devoxx. Nicolai Josuttis a animé une présentation intitulée « SOA in practice » à l’image du titre du livre dont il est l’auteur, publié chez O’Reilly.

Passage obligé de toute présentation sur SOA, Nicolai Josuttis commence par introduire l’ensemble des concepts gravitant autour de l’architecture orientée services. Nous passerons sur ces rappels ici, car malgré quelques divergences dans les définitions, on retrouve les idées décrites dans les différents articles portant sur SOA que nous avons pu publier jusqu’alors.

Après cette introduction, Nicolai Josuttis s’est arrêté sur les débats ayant agité le petit monde des SOAistes en ce début d’année : ce modèle d’architecture est-il mort ? N’était-ce qu’une mode de passage ? Non, le concept de service garde toute sa valeur pour l’entreprise et la suite de sa présentation, sans rien cacher des défauts de SOA, montrera tout son intérêt.

La suite de la présentation s’oriente rapidement autour de la mise en pratique de ces concepts.

SOA en pratique dans l’entreprise

Entre frontends et backends

Une architecture orientée services repose en général sur un ensemble de frontends et une série de backends idéalement organisés en respectant les frontières des départements ou des business units de l’entreprise. La figure suivante représente ce type de système :

Le frontend peut prendre plusieurs formes. Il peut s’agir d’une simple interface de visualisation qui se contente alors de présenter les données formées par les services d’agrégation sous-jacents. A l’inverse, il peut permettre la modification des données, ce qui en fait une application plus intelligente. Il est alors également nécessaire de faire un choix quant à la validation des données entrantes : celle-ci peut se faire dans le frontend, dans le frontend et le backend, ou via un service dédié. Cette dernière solution simplifie l’architecture en assurant la cohérence de la validation mais entraîne une grande quantité d’invocations de services.

Versionning

Les services exposés dans une SOA subissent en général des modifications au cours de leur vie car ils mettent en œuvre des besoins en perpétuelle évolution. Les consommateurs ne pouvant alors être tous mis à jour lorsque le service évolue, plusieurs versions vont coexister.

Nicolai Josuttis préconise alors de limiter à 3 le nombre de versions d’un même service en production. Pour cela :

Il est nécessaire que les consommateurs d’une version obsolète d’un service fassent évoluer leur application afin d’exploiter la version la plus récente.
Le point précédent implique qu’une collaboration est nécessaire entre producteur et consommateur.
Il implique également qu’il est vital d’être en mesure d’énumérer l’ensemble des consommateurs d’un service.

Interrogé sur le positionnement de nouveaux framework tels que Apache Thrift gérant nativement la problématique de versionning, Nicolai Josuttis explique qu’il s’agit là d’un détail d’implémentation qui ne doit pas être une justification pour contourner le nombre maximum de versions simultanément en production.

Ré-utilisabilité

La ré-utilisabilité est une des propriétés fondamentales des services dans une SOA.

Pourtant, Nicolai Josuttis a pu observer qu’en pratique cette propriété est rarement possible. En effet, il explique que ses observations ont montré que la majorité des services d’un système d’information ont au plus deux consommateurs. Certains ne sont même pas consommés.

Dans la mesure où la ré-utilisabilité va souvent à l’encontre des performances puisqu’il est alors souvent nécessaire d’invoquer plusieurs services, il est conseillé de se fixer des objectifs raisonnables quant à cette propriété.

Annuaires

Les annuaires de services permettent de recenser l’ensemble des services disponibles dans une SOA.

Nicolai Josuttis préconise de ne pas mettre en œuvre d’annuaire dès la création de l’architecture orientée services, mais d’attendre que le besoin s’en fasse naturellement ressentir.

Gouvernance

La SOA faisant interagir l’ensemble des départements de l’entreprise, des aspects humains et des problématiques de gouvernance surviennent inévitablement.

Il est suggéré de recourir à une équipe SOA dédiée, assurant le respect d’une stratégie d’architecture globale.

Lors de l’émergence de SOA dans l’entreprise, il est indispensable de procéder progressivement, en lançant des projets pilotes permettant de détecter les problématiques et d’adapter les équipes à cette nouvelle architecture. Ainsi le processus de transition peut prendre 5 ans.

SOA à l’heure du bilan

Après avoir énuméré l’ensemble de ces problématiques propres à SOA, Nicolai Josuttis pose une question simple : compte-tenu de tous ces défauts, pourquoi passer à SOA ? Il répond simplement en montrant que dans de nombreuses situations, ce modèle d’architecture n’est pas contournable pour satisfaire les besoins de communications entre les composantes de l’entreprise.

Enfin, il reconnait et dénonce le hype qui a entouré SOA, mais n’en minimise pas l’intérêt pour autant.

Conclusion

L’architecture orientée services aurait-elle atteint la maturité ? C’est en tout cas l’impression qui transparaît face à la multiplication de présentations telles que celle de Nicolai Jusuttis, imprégnées de pragmatisme et de réalisme, tout en montrant son rôle incontournable dans le remplacement des systèmes monolithiques ou organisés en silos isolés.

L’apparition d’outils et de frameworks légers tranchant avec les solutions très lourdes que SOA a connu dans ses débuts, ainsi que la percée des méthodes agiles pour leur mise en œuvre, s’ajoutent à ces nouveaux discours pour constituer le renouveau des architectures orientées services.

Revue de Presse Xebia

Xebia France — Mon, 16 Nov 2009 17:47:49 +0000

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

Actualité éditeurs / SSII

SOA

10 mythes au sujet des SOA

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

Soirée Google au LyonJUG

Actualité éditeurs / SSII

Innovation permanente chez Google

Google est encore une fois au cœur de l’actualité cette semaine avec la mise à disposition d’un nouveau langage de programmation et d’un protocole destiné à remplacer HTTP.

Le langage Go est à la croisée de C, Java et Pascal et est annoncé comme ayant des performances proches du C. Go se distingue par le fait que son compilateur produise directement du code natif, et qu’il ne requiert donc pas de machine virtuelle. Il apporte toutefois un ramasse-miette et un ensemble d’abstractions permettant de simplifier la programmation parallèle.

Très rapidement, plusieurs opinions et résultats d’expérimentations sont apparus. Ainsi, Tim Yang montre les performances obtenues par une application serveur développée en Java (en utilisant Mina), C (avec Nginx) et Go. Les résultats qu’il obtient montre que Go est en retrait par rapport aux deux autres solutions. Ces résultats doivent toutefois être relativisés par la maturité acquise par le système d’entrée / sortie de la JVM, le design très performant offert par Mina, la réputation de performance de Nginx et enfin, bien sûr, par le stade embryonnaire de Go.

Google a également diffusé les spécifications de SPDY (prononcer Speedy), un protocole visant à remplacer HTTP. On le sait, HTTP n’est pas adapté au Web moderne. En particulier il n’est pas optimisé pour obtenir une latence minimale. SPDY ne redéfinit pas tout, il se base sur HTTP et y ajoute un ensemble de possibilités supplémentaires telles que la compression d’en-têtes, le multiplexage de flux ou encore la priorisation de requêtes.

Des tests sur le transport du contenu des sites Web les plus populaires, permettent à Google d’annoncer un gain moyen de 55%.

L’entreprise américaine continue donc d’impressionner par son innovation permanente, n’hésitant pas à remettre en cause régulièrement des technologies considérées comme incontournables.

Java SE 5 en fin de vie, JDK 7 en approche

Sur la page dédiée à J2SE 5.0, Sun notifie depuis début novembre les utilisateurs de l’arrivée en fin de vie (End of Service Life) de cette version de Java.

Arrivé il y a 5 ans, Java 5 avait constitué la mise à jour la plus importante de la plate-forme et de son langage depuis sa création. Son adoption en entreprise fut longue, mais s’est concrétisée au fil du temps. Ainsi aujourd’hui, on ne compte plus qu’une minorité de projets fonctionnant encore exclusivement avec la version 1.4 ou inférieure de Java.

Il en est tout autrement pour Java 6.0. En effet, contrairement à la version 5.0 dont l’adoption était indispensable pour profiter des technologies d’entreprise les plus récentes, les principales motivations pour passer à la version 6.0 concernent la JVM elle-même et les améliorations qu’elle a connue.

L’arrivée en EOSL pourrait accélérer les choses dans certaines entreprises, tandis que d’autres préfèreront se tourner vers l’offre Java for Business de Sun qui permet de continuer de bénéficier du support de l’éditeur.

Une autre possibilité pourrait se trouver dans l’arrivée de JDK 7. En effet, la roadmap du projet promet un début de phase Release Candidate débutant à la fin du premier trimestre 2010 pour une durée d’un à deux mois, ce qui permettrait donc l’arrivée d’une version finale dans 6 mois. Si la confiance dans les dates de finalisation annoncées de JDK 7 s’est évaporée au fil des reports successifs, la situation semble maintenant se stabiliser : Mark Reinhold vient d’annoncer la disponibilité de la M5 de JDK 7, en accord avec le calendrier prévisionnel de la roadmap. Quatre des fameuses évolutions du langage apportées par le projet Coin y sont implémentées et peuvent donc être d’ores et déjà testées.

SOA

10 mythes au sujet des SOA

Yefim Natis, de Gartner, a exposé durant l’évènement SOA in Action, dix mythes communs (et la réponse qu’il faut leur apporter) sur la mise en place d’une SOA.
Là où l’article porte à sourire, c’est que, pour une fois, la faute est partagée : cinq de ces mythes sont propagés par les fanatiques de la SOA, et sont mis en regard de cinq autres portés par les allergiques.

Pour les fanatiques, nous avons :

Les services sont portés par l’IT et propagés vers les acteurs fonctionnels.
Pour Yefim Natis, une SOA est un moyen pour l’IT de mieux comprendre et appréhender les problématiques métier.
Les plate formes orientées services reposent sur des briques pré-fabriquées.
Les SOA ne reposent pas uniquement sur des applications ‘services’, mais aussi sur des batchs et des applications héritées.
Partager et réutiliser sont les principaux apports d’une SOA.
C’est en effet un des bénéfices attendus, mais c’est loin d’être le seul. On peut citer : meilleure exploitation, meilleure montée en charge …
Mettre en place une SOA permet de s’abstenir de réaliser une phase d’intégration.
Même si la SOA permet d’introduire une stabilité dans les interactions entre services, elle ne dispense pas de réaliser de vrais tests d’intégration, bien au contraire.
Une SOA réduit les coûts du SI.
Sur le long terme, peut être … Mais dans un premier temps, une SOA peut s’avérer couteuse : nouvelle façon de penser, nouveaux outils, formations à prévoir…

Pour les allergiques, la liste est la suivante :

Une SOA introduit une grande complexité et de nouveaux problèmes.
La plupart des problèmes liés à la mise en place d’une SOA sont des problèmes existants partout ailleurs dans le monde de l’informatique distribuée. La mise en œuvre d’une SOA ne fait souvent que mettre en exergue des problèmes existants.
SOA n’est pas nouveau, c’est juste un effet de mode.
Il faut voir au delà de l’aspect technique : certes SOA repose sur les principes de l’informatique distribué, mais c’est l’ensemble de la démarche qui est nouvelle et qui a au moins l’avantage de crystaliser certaines bonnes pratiques.
Une SOA est vouée à l’échec, parce que les Web Services sont un standard trop instable.
SOA et SOAP sont deux choses complètement différentes. Les Web Services sont ‘juste’ un moyen d’exposer des services.
Il est difficile de vendre une SOA, car les acteurs fonctionnels n’en voient pas les bénéfices.
Certains bénéfices sont apparents de manières quasi instantanée (on pense aux indicateurs BAM), et les acteurs fonctionnels gagnent rapidement une nouvelle compréhension de leur environnement IT.
SOA est déjà dépassé, il faut passer à la suite.
Le challenge d’une SOA basique est en effet dépassé. Mais il reste de nombreux enjeux à adresser, notamment dans les architectures les plus complexes.

via InfoQ

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

Soirée Google au LyonJUG

Lundi 23 Novembre, le LyonJUG organise une soirée dédiée aux technologies Google. L’occasion de découvrir, démonstration à l’appui, Google Web Toolkit, Google App Engine, Android et le dernier né Google Wave. L’objectif est aussi de présenter l’architecture globale de ces produits pour mieux en saisir le fonctionnement et le but.
Pour faciliter l’organisation de la soirée dans les locaux d’EPITECH, vous devez vous inscrire ici.

Le référentiel de services dans une architecture SOA

Christophe Heubès — Fri, 30 Oct 2009 14:17:52 +0000

Dans une architecture orientée service, le référentiel ou catalogue de services appartient à une famille de composants destinés à ce que l’on appelle généralement la gouvernance. La gouvernance est une notion évanescente, dont la définition fait l’objet d’âpres débats, mais qui, quelle que soit celle que l’on retient, renvoie au besoin de se doter d’outils et de procédures susceptibles d’assurer le contrôle de la complexité de l’architecture et d’en mesurer la consistance.

Le référentiel de service est un incontournable pour maîtriser les services.

Traditionnellement, et de façon macroscopique, un référentiel de services dans une architecture distribuée comprend deux grandes catégories de fonctionnalités :

Les fonctions de registre qui visent à faciliter le fonctionnement de l’infrastructure de services :

Contrôle d’accès.
Correspondance entre les différents noms que peut porter chaque service dans les différents sous-systèmes.
Localisation et routage.
Transcodification et uniformisation des codes (y compris les codes erreurs).
…

Les fonctions d’annuaire qui visent à consolider la connaissance métier :

Etre la référence unique portant la connaissance des services de l’entreprise.
Porter la connaissance des formats d’échanges.
Distinguer les services qui nécessitent une réponse de ceux qui n’en attendent pas.
Identifier l’appartenance fonctionnelle de chaque flux.
Gérer les versions.
…

Les fonctions de registre sont destinées à l’exécution des services. Elles permettent aux consommateurs de services de localiser les fournisseurs (dans la version adéquate), d’identifier les modalités techniques de l’interaction, de valider les formats d’échange et de vérifier les politiques d’accès. Elles adressent aussi la dimension routage à savoir qu’à partir des informations de contexte, elles offrent la possibilité de déterminer le service cible, le mode d’accès (M.O.M., Web Services, …), les ressources associées (nom de la file MQ, URL d’accès, etc.).
Ces fonctions de registre s’appuient le plus souvent sur le standard UDDI v3, et un ensemble de standards complémentaires pour les différentes métadonnées et stratégies (WSDL 1.1, SOAP w/wo Attachement 1.1, OASIS Web Service Security, XACML 1.0, SAML 2.0).

Les fonctions d’annuaire, quant à elles, offrent une large palette de fonctionnalités destinées aux personnels impliqués dans la mise en œuvre de la SOA : modélisation et structuration du référentiel, accès à la documentation des services, recherche, gestion du cycle de vie (éventuellement avec des processus d’approbation), analyse d’impact, reporting, etc. Ces fonctionnalités sont proposées au travers d’interfaces graphiques plus ou moins sophistiquées et ergonomiques.
Ces fonctions ne font pas l’objet de standards, et sont en conséquence un facteur de différenciation fort entre les offres logicielles.

Le référentiel assure donc la cohérence entre les différentes nomenclatures des applications.
Dans son acception classique, le référentiel doit être et rester l’unique point de référencement des services. Il constitue un composant central de l’architecture, et nécessite à ce titre des procédures de gestion et d’administration adaptées.

Revue de Presse Xebia

Xebia France — Mon, 26 Oct 2009 18:32:17 +0000

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

SOA

Le coin de la technique

SOA

SOA Manifesto : pragmatisme utopique ?

La communauté SOA vient de publier son SOA Manifesto. Les valeurs sont très consensuelles, on pourrait même les trouver trop lisses quand on a vécu un naufrage SOA (avec l’oubli des objectifs métier, sa perfection naïve initiale, ses services faussement partagés qui finalement ne satisfont même pas le premier consommateur et autres ESB passe-plats).

Saluons tout de même cette initiative. SOA est une réalité. Les projets utopistes sont aujourd’hui minoritaires face à tous les projets qui intègrent des web services pour interconnecter les applications.
Le Manifeste SOA en français :
Valeur métier plutôt que stratégie technique,
Objectifs stratégiques plutôt que bénéfices spécifiques à un projet,
Interopérabilité intrinsèque plutôt qu’intégration propriétaire,
Services partagés plutôt qu’implémentation spécifique à un besoin particulier,
Flexibilité plutôt qu’optimisation,
Amélioration incrémentale plutôt que recherche de la perfection initiale.

Et rassurons-nous, ce n’est pas un manifesto qui empêchera les zélotes SOA de se déchirer. La guerre SOAP versus REST bat (toujours) son plein .

Ils parlent du SOA Manifesto : InfoQ SOA Manifesto, Stefan Tilkov’s Weblog : Comments on SOA Manifesto.

Allez, je retourne à mes web services Contract First avec CXF .

WADL devient une Submission W3C

Marc Hadley, auteur de la spécification WADL et spec-lead de la JSR-311 (JAX-RS), a annoncé que WADL venait d’être accepté en tant que Submission W3C.

Cette spécification portée par Sun a pour but de définir un format XML de description de services REST. Il s’agit donc d’un équivalent à WSDL pour REST. Alors que REST-*, porté par JBoss, a récemment relancé le débat sur la tendance récurrente à vouloir intégrer dans REST les fonctionnalités des très controversés WS-*, la soumission de WADL au W3C fait réapparaître la question de l’intérêt de définir des contrats pour des services REST.

Joe Gregorio s’opposait vivement à l’initiative WADL il y a deux ans déjà. Il reprochait principalement :

l’insuffisance de WADL pour définir élégamment tous les types de services REST
la fragilité du client qui ne fonctionne plus lorsque le contrat change comme c’est déjà le cas avec WSDL
le manque de réalisme de l’approche WADL2Java qui ne permettrait pas la pleine exploitation de REST. Il préférait donc une approche d’écriture du client REST manuelle, en se basant sur un socle commun.

Toutefois, l’approche « REST avec un contrat » est séduisante pour les applications d’entreprise dont les services sont souvent aussi nombreux que les consommateurs variés.
C’est dans cette logique que de nombreux projets lèvent les ambiguïtés de leurs services REST en préférant XSD à JSON. Les URL et paramètres d’appel restant alors décrits uniquement dans une documentation annexe.

Par ailleurs, on peut regretter que WADL n’ait pas mieux adressé que WSDL des problèmes aussi important que le versioning des services alors qu’un projet comme Apache Thrift a su être innovant sur le sujet.

La soumission de WADL au W3C n’implique donc pas forcément son succès à venir. La disponibilité en masse d’outils et de frameworks permettant de gérer ce format pourrait en revanche attirer une partie des adeptes de SOAP.

Le coin de la technique

Play! Framework 1.0

The Server Side nous annonce la sortie de Play! Framework en version 1.0.

Play! est un framework web de haute productivité (tout comme Grails ou Spring Roo) qui simplifie la création et le développement d’applications Web en langage Java. Ce framework full stack inclut tout une batterie de composants tels que Groovy (pour le templating), Apache Mina mais aussi Hibernate. Quant à l’architecture de vos projets Play!, elle sera de type RESTful.

Cette vidéo nous donne un bon aperçu du produit, surtout en ce qui concerne le fameux Fix the bug and hit reload ! c’est à dire pas de compilation, de déploiement ou de redémarrage serveur suite à la modification de vos classes Java, juste un rafraîchissement de votre navigateur pour voir vos modifications.

A noter que l’équipe travaille déjà sur la version 1.1 et, entre autres, sur le support de Scala

Pour les liens utiles, la documentation complète du produit se trouve sur cette page. Le téléchargement se passe par ici. Et, comme le rappelle TSS, n’oubliez pas la présentation Play! framework in practice à Devoxx, en tous cas nous y serons !

Mise à jour de VisualVM en 1.2

8 mois après la sortie de la version 1.1, l’équipe nous gratifie d’une nouvelle version de son outil de monitoring de JVM. Avec un passage de 1.1.1 à 1.2, il ne faut pas s’attendre à de grandes révolutions. Une liste de 31 bugs corrigés, suivie de quelques nouvelles fonctionnalités notables:

Un sampling profiler CPU et mémoire
Support de plusieurs instances de JStatd
Amélioration de l’API de génération de graphes
Sauvegarde d’un snapshot de l’application dans un fichier nps pouvant-être utilisé plus tard pour analyse

Nous vous passons les améliorations de GUI et le support des proxys qui peut toujours s’avérer utile pour les analyses à distance. La vraie grande nouveauté c’est le plugin permettant de profiler l’application par sampling. Il ne faut pas s’attendre à la précision des outils instrumentant l’application comme JXInsight. Cependant, cela permettra une analyse assez poussée sans impact sur les performances.

Comment concevoir un datacenter, … par Google

Lors de la conférence Ladis 2009 (Large Scale Distributed Systems and Middleware), Jeff Dean, du groupe infrastructure chez Google, a présenté les manières de concevoir un système distribué.

Il passe en revue différentes problématiques :

Infrastructure
Stockage
Clustering
Échange de données sur le réseau
Communication entre applications
Construction d’application sur de telles infrastructures

Il est intéressant de voir les problématiques posées et les solutions proposées, sur des problématiques que nous avons trop tendance à oublier en tant que développeurs. Citons entre autres :

Latence réseau : un critère important, car difficile à optimiser
Bande passante du réseau
Capacité de stockage (mémoire et disque)

Il est donc très important même pour un développeur d’avoir ces chiffres en tête.

Par retour d’expérience, Jeff Dean montre les joies d’interagir avec du matériel physique. Les applications ne doivent pas supposer que le matériel est infaillible, il y a différentes erreurs que nos applications doivent gérer. Quand on voit les nombres d’occurrences de ce type de problème et leur nature, leur gestion par l’application n’est pas aussi triviale qu’il y parait :

Problème DNS
Plantage de serveur
Perte de connections
…

Cette présentation est très riche, et elle permet de voir les tenants et aboutissants d’une bonne infrastructure mais aussi les impacts que cela peut avoir dans nos développements de tous les jours.

Les contraintes que s’est imposé Google en terme de disponibilité, dimensionnement, … ont amené plusieurs innovations technologiques en terme d’infrastructure qui ont des impacts sur le développement applicatif :

Protocol Buffer
MapReduce
Google File System
Big Table

Les lecteurs intéressés par les innovations mises en place par Google sur ses infrastructures noteront que Gregor Hohpe (auteur de Enterprise Integration Patterns) présentera à Devoxx une session Distributed Programming the Google Way.

Ca bouge dans la communauté Groovy/Grails

Pour commencer, on peut noter la longue présentation de Grails faite par Graeme Rocher sur InfoQ. Le « papa » de Grails revient sur de nombreux points relatifs à ce très bon framework permettant de créer des applications web rapidement en bénéficiant de la puissance de Java, Groovy, Hibernate, Spring…

Ensuite, et c’est la rançon du succès, il y a beaucoup de discussions et d’interrogations autour des besoins auxquels répondent Groovy et Grails. Sur son blog, Peter Delahunty précise par exemple que, pour lui, Grails n’est l’arme absolue que si on a une bonne connaissance des technologies sous-jacentes (Spring, Hibernate…). Il ne faut pas débuter par Grails sans s’attendre à bloquer sur des problèmes relatifs à ces technologies.

Cet article va dans le même sens et rappelle qu’à partir du moment où l’on parle de « la magie Groovy » il faut être conscient que des choses qui n’ont rien de magique (cela reste du code !) se passent. Les « dynamic finders », le MOP (Meta Object Protocol) et la magie des closures font rêver mais s’expliquent bel et bien ! Ensuite, il y est noté que la proximité de Groovy et Java fait que de nombreuses personnes pensent que l’on peut passer de Java à Groovy sans formation particulière. Si l’on ne comprend pas les principes de ces choses magiques et que l’on se contente de les accepter comme tels, on s’expose tôt ou tard à des retours de flamme sévères qui se matérialisent généralement sous la forme de StackTraces incompréhensibles. Enfin, le manque de support professionnel pour Groovy/Grails est évoqué. Sur ce point, je pense que l’auteur se trompe. On note en effet que Springsource semble fournir un support commercial pour ces technologies. Mais, il y a peu, Groovy et Grails n’étaient pas encore dans le giron de Springsource et l’on devait « se contenter » du support de la communauté. Néanmoins, celui-ci a toujours été assez réactif et de bon niveau.

Toujours concernant Groovy, on peut noter la version Community Edition de l’IDE IntelliJ, tout récemment publiée, semble bien lotie au niveau du support de ce langage. Malheureusement, le support de Grails, lui, n’est pas présent dans cette version.

Votre application web est elle vulnérable ?

Le Web Application Security Consortium (WASC) estime que 87% des applications de la toile sont vulnérables. Tout le monde ne peut pas s’offrir les services d’un expert en sécurité, et un développeur ne peut pas écrire du code sécurisé s’il ne connaît ou ne comprends pas les risques auxquels il s’expose. C’est pour cette raison que DeveloperWorks revient sur les principales failles de sécurité qui nous guettent, et quelques outils simples pour analyser notre code.
Les points de faiblesse les plus connus sont :

le cross site scripting : le pirate injecte, via un autre site (de type forum par exemple), un script (de type javascript) vers le site visé. Ce script lui permet de récupérer des informations de connexion, des cookies…
l’injection de SQL : le pirate saisit du code SQL dans un formulaire web. Celui-ci est poussé jusqu’à la base, exécuté et donne (le plus souvent) accès à la base ‘en direct’ au pirate (l’un des exemples le plus connus est l’injection de OR 1=1- dans un formulaire d’authentification, qui retourne alors toujours TRUE).

Et l’on reparle de l’OWASP, qui propose un outil open source pour détecter ces erreurs de conception : WebScarab. WebScarab s’utilise comme un proxy HTTP (qui se place entre votre browser et votre serveur d’applications, par simple redirection des ports). Ensuite, un simple fichier .txt permet d’injecter votre site avec quelques-uns des plus célèbres cas de cross site scripting ou d’injection SQL. Un autre outil open source est présenté, d’un fonctionnement similaire, Paros Proxy.
Reste ensuite à détecter les faux positifs, opération généralement manuelle.

On notera que la section Ressources de l’article original est richement fournie, et permet de réellement comprendre les risques auxquels sont exposées les applications accessibles sur internet.

Saurez-vous trouver les failles du site de test Webgoat ?

Artifactory : évolutions et mode SaaS

Artifactory est un repository Maven dont la principale particularité est de s’appuyer sur Java Content Repository (JCR) pour assurer le stockage des artefacts. Le choix de JCR plutôt qu’un simple système de fichiers n’avait pas fait l’unanimité car il rend les tâches courantes d’administration plus délicates. En effet, lorsque l’on veut supprimer, remplacer ou déplacer un ensemble d’artefacts, l’action est triviale lorsque le système de fichier est utilisé alors qu’elle devient plus complexe avec JCR, qui n’est pas aussi directement manipulable.

Conscient de ce problème JFrog, l’éditeur derrière Artifactory, a peu à peu intégré un certain nombre de fonctionnalités permettant d’effectuer ces tâches courantes d’administration des artefacts directement depuis l’interface Web. Ainsi, la dernière version du projet permet même le déplacement d’artefacts entre plusieurs repository.

Début septembre, JFrog a également lancé ArtifactoryOnline, un service d’hébergement de repository Maven Artifactory en mode SaaS (Software as a Service). Ce type d’offre répond clairement à un besoin puisque la présence d’un repository Maven est souhaitable pour de nombreux cas d’utilisation et que cette infrastructure nécessite du temps et du matériel dont ne disposent pas toujours les équipes de taille réduite.

Par ces innovations, le repository Maven de JFrog saura sûrement séduire les utilisateurs déçus par les solutions concurrentes que sont Nexus et Archiva.

Article mis à jour le 26/10/2009 à 21h25

Revue de Presse Xebia

Xebia France — Mon, 24 Aug 2009 16:35:23 +0000

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

Actualité éditeurs / SSII

SpringSource lance CloudFoundry

SOA

David Chappell et Ted Neward : SOA est un échec … mais aussi un progrès

Le coin de la technique

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

Actualité éditeurs / SSII

SpringSource lance CloudFoundry

Rod Johnson l’annonçait jeudi dernier sur son blog, l’éditeur fait ses premiers pas dans le monde du cloud computing. Il s’agit en effet d’une interface web qui ne manque pas de rappeller Google App Engine permettant d’installer des applications Java sur le nuage. Dans cette première version, on nous propose de déployer des applications hébergées sur le fameux Spring Tc Server, avec out of the box, la supervision Hyperic, la possibilité d’utiliser une base de données MySQL, et évidemment le support de Grail, si cher à Rod.

Au menu, bien évidemment le support et la répartition automatique de la montée en charge. Pour le moment, le tout est déployé sur Amazon EC2, mais Rod espère bien le voir déployé prochainement sur vSphere (la solution de cloud computing de VMWare). Nous souhaitons longue vie à ce nouveau produit de SpringSource qui confirme une fois encore sa montée en puissance. Notez, tout de même pour information que c’est Chris Richardson et son équipe qui s’est chargé de la réalisation de CloudFoundry.

L’article de Cyrille Le Clerc sur SpringSource et Java Platform As A Service vous permettra d’y voir un peu plus clair sur la stratégie poursuivie par SpringSource.

SOA

David Chappell et Ted Neward : SOA est un échec … mais aussi un progrès

David Chappell a retrouvé une discussion qu’il a eu avec Ted Neward en 2008 sur SOA.

Au-delà de l’évocation des liens entre Service Oriented Architecture (SOA), Software as a Service (SaaS) et Cloud computing, nous retiendrons de cet échange : SOA a échoué à tenir sa double promesse « Réutilisation et agilité ».
L’agilité est une forme de réutilisation puisqu’elle permet de créer de nouveaux services en assemblant facilement des services existant. La réutilisation des services métiers a échoué, et par effet de bord, l’agilité n’a pas été obtenue. La réutilisation des services métiers est analogue à la réutilisation des objets métiers à la fin des années 90.
La cause de cet échec, pour SOA comme pour les objets métier, n’est pas technique mais principalement humaine. Les organisations n’ont pas créé les conditions pour inciter les équipes à partager leur travail ni à réutiliser le travail des autres (Cf. « Le syndrome Not Invented Here » et « Propriété des composants et Financement au projet« ).

En revanche, la réutilisation des objets techniques a réussi, les frameworks .Net et Java EE en sont des exemples. De plus, l’orienté objet a convaincu comme paradigme de programmation. Pour SOA, la réutilisation de services techniques comme la gestion de l’identité ou la couche d’accès aux données basiques fonctionne.

Il s’agit donc d’un échec du SOA tel qu’on nous l’a promis mais en revanche d’un succès de l’approche par service.

Pour ce qui est des ESB, il s’agit principalement d’un coup marketing des éditeurs de solutions d’intégrations mais aussi d’une évolution des paradigmes d’intégration : l’intégration par services à succédé à l’intégration par base de données.

Alors SOA est un échec ? Oui si l’on regarde les promesses initiales qui n’ont pas été tenues ; non si l’on voit les transformations orientées service qu’elle apporte.

Le coin de la technique

Acquisition d’Ehcache par Terracotta, nécessaire et suffisant ?

Le teaser largement propagé via Twitter et les différents blogs des acteurs de Terracotta est tombé. Terracotta a fait l’acquisition d’un des frameworks open-source les plus populaires du marché : Ehcache. Drôle de teasing, sous la forme d’un hash md5, pour une drôle d’annonce. Ce mariage ressemble plus à un arrangement entre amis qu’a un véritable rachat :

Ehcache et Terracotta fonctionnent conjointement depuis bien longtemps.
Ehcache est porté par une seule personne : Greg Luck.
La vente de support Ehcache ne fonctionne pas vraiment, dixit Greg Luck.
Le code source de Ehcache est très léger, et sa partie la plus complexe, le cache distribué, concurrence avec une grande simplicité Terracotta.

Alors, pourquoi avoir racheté Ehcache ?

Selon certains analystes, après le rachat de SpringSource, VMWare a la volonté d’élargir son portefeuille d’outils et de middleware Java, et Terracotta serait pressenti. C’est en tout cas l’hypothèse mise en avant par quelques gaillards de Terracotta (encore une fois, merci Twitter). Notre sentiment, trop de bruit pour que cela soit d’actualité. Par contre, il nous semble clair que Terracotta désire se faire racheter. Et pour cela, plusieurs problèmes doivent être réglés :

Malgré les différentes versions, Terracotta suscite des résistances, en cause son approche bas niveau (JVM / Bytecode) qui freine bon nombre d’utilisateurs. D’ailleurs, Terracotta ne fonctionne pas avec toutes les JVM.
L’utilisation de ce framework n’est pas transparente, quoi qu’en disent les documentations. Il est facile de se tromper sur le choix des objets à partager et les poses de lock. Tout cela fait qu’à l’utilisation, la mise en place de celui-ci est tout sauf triviale.

Et c’est là qu’Ehcache intervient !

Mis en lumière par le cache L2 d’hibernate, Ehcache fonctionne également avec d’autres produits star comme Spring, Alfresco et Liferay. Il est devenu l’une des apis de cache les plus utilisées par les développeurs. On parle de plusieurs centaines de milliers de projets utilisant celui-ci. Avec ce rachat, Terracotta espère se rapprocher davantage de cette communauté en s’appuyant sur la bonne image d’Ehcache pour rassurer les développeurs.
D’autre part, Terracotta gonfle sa stack logiciel et propose dans son portefeuille un mécanisme de cache distribué alternatif plus haut niveau.

Au final, petite annonce ? Pas si sûr ! Terracotta signe ici un joli coup de communication et se met dans les meilleures conditions en vue d’un éventuel prochain rachat.

ChromeDevTools

Pour ceux qui ne sont pas à l’aise avec le débogage Javascript par l’interface de Firebug ou tout simplement ceux qui souhaitent débugger intégralement leur application dans Eclipse, y compris le Javascript client, voici un petit outil (développé par Google) qui vous le permettra : le Google Chrome Dev Tools (par l’Eclipse Zone).

Le projet se compose du Chrome Dev Tools SDK, API Java permettant à une application en mode debug de communiquer avec le navigateur Google Chrome (localhost en TCP/IP) , et de l’Eclipse Debugger, le plugin Eclipse qui vous permettra de débugger votre application.

Ce dernier propose entre autres :

Breackpoints
Watches
Step in / over / into
Évaluation d’une sélection de texte
Évaluation sur mouse hover
Exceptions reportées dans la vue Error Log

Côté mise en place, il vous faudra au minimum, comme vous pouvez vous en doutez, un navigateur Google Chrome en version 3.0.189.0 (actuellement en beta) et un Eclipse 3.4.2. L’installation du plugin se fera par l’Update Site avec cette URL.
Il vous faudra ensuite lancer votre Chrome avec le paramètre --remote-shell-port=9222 (ou le port de votre choix) et définir, dans le menu Debug Configurations d’Eclipse, une nouvelle Chromium Javascript configuration avec le port spécifié pour Chrome. Et à partir de là, à vous les breakpoints et le debug de votre application dans Eclipse !

Pas de Swing Application Framework dans le JDK 7

Il y a quelques mois nous vous parlions de la disponibilité d’une roadmap détaillée pour le JDK 7. Elle incluait entre autre la JSR-296 (Swing Application Framework), une spécification destinée à simplifier le développement d’applications Swing grâce à :

Des annotations @Action pour déclarer les actions Swing plus facilement qu’en sous-classant AbstractAction puis en redéfinissant la méthode actionPerformed()
Gestion de l’enregistrement de l’état des fenêtres à la fermeture de l’application
Simplification de la gestion des ressources
Gestion du cycle de vie de l’application

Les apports sont intéressants car répondent bien aux réalités des projets Swing courants, mais n’y répondent que partiellement. En effet il aurait été interessant de voir se créer une synergie avec la JSR-330 (Dependency Injection for Java) afin d’apporter l’injection de dépendance aux applications client lourds. De plus, ce framework ne simplifie pas la définition des interfaces en Swing, opération se révélant souvent assez laborieuse en raison d’APIs vieillissantes et probablement trop bas niveau.

Alexander Potochkin nous apprend maintenant que cette JSR ne sera pas prête dans les temps pour la roadmap prévue et qu’en conséquence son intégration au JDK 7 est annulée. Dans ces conditions, les apports du JDK 7 à Swing seront quasi nuls, ce qui constituera une réponse bien peu satisfaisante aux débats ayant animé cette communauté il y a quelques mois.

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

Hadoop World 2009

La société Cloudera, spécialisée dans le support aux utilisateurs de Hadoop, a annoncé la première conférence mondiale consacré à Hadoop : Hadoop World. Cette conférence se tiendra à New-York City en octobre de cette année. Elle est soutenue par des sponsors de taille comme IBM, Intel et Yahoo.

Le nombre de candidat à la prise de parole est tellement important que l’agenda n’est pas encore fixé. Le thème sera « Hadoop is everywhere », on aura donc droit à des sujets aussi bien sur des applications utilisant déjà Hadoop, que sur les implications coté administration de parc.

Les inscriptions sont ouvertes …

Sortie le 30 septembre de Google Wave Preview

Présenté il y a quelques mois comme une évolution majeure de notre façon de communiquer en ligne, Google Wave sera bientôt disponible au public. 100 000 utilisateurs sont attendus une fois le service ouvert.

A l’heure actuelle, les développeurs qui ont pu testés ont eu de gros problèmes de disponibilité de la plateforme. Sur InfoQ, on apprend que pour le 30 septembre, l’objectif du responsable technique de Wave API, Douwe Osinga, est bien sûr d’améliorer la stabilité du système mais aussi d’ajouter des fonctionnalités à l’API. Par conséquent, il ne leur restait que peu de temps pour stabiliser le bac à sable.

Dans les nouvelles fonctionnalités, l’accent a été mis sur l’API liée aux robots qui est à présent ouverte. Grâce aux robots, on peut répondre de manière applicative à des évènement sur la wave, ce qui permet d’interagir avec les autres participants, ou d’échanger des informations avec des systèmes extérieurs.

Si vous souhaitez être averti de l’ouverture du service, inscrivez-vous. Vous pouvez même écrire un message d’encouragement à l’équipe de Google Wave. Ils en auront certainement besoin pendant le moins prochain…

SOA : Du composant au service : La composabilité

Christophe Heubès — Tue, 11 Aug 2009 07:50:46 +0000

Comme son nom le suggère, l’élément clé de SOA (Service Oriented Architecture) est le Service. Il est pourtant difficile de faire le consensus autour de la notion de service et il est souvent difficile de répondre à cette simple question « Qu’est-ce qu’un service ? ». Ce sujet débouche invariablement sur, au choix : Un blanc ; Une réponse alambiquée et incertaine ; Une discussion enflammée (ou un débat stérile).

On pourrait proposer la définition suivante : « Un Service est un composant logiciel distribué, exposant les fonctionnalités à forte valeur ajoutée d’un domaine métier ». Malheureusement, les définitions aussi courtes (bien qu’exactes) sont nécessairement incomplètes et amènent un florilège de questions.

Pour répondre plus précisément à la question, nous vous proposons de passer en revue les huit aspects qui caractérisent un service :

Contrat standardisé : L’ensemble des services d’un même Système Technique sont exposés au travers de contrats respectant les mêmes règles de standardisation.
Couplage lâche : Le contrat d’un service doit imposer un couplage lâche de ses clients.
Abstraction : Le contrat d’un service ne doit contenir que les informations essentielles à son invocation. Seules ces informations doivent être publiées.
Réutilisabilité : Un service exprime une logique agnostique et peut ainsi être positionné comme une ressource réutilisable.
Autonomie : Un service doit exercer un contrôle fort sur son environnement d’exécution sous-jacent. Plus ce contrôle est fort, plus l’exécution d’un service est prédictible.
Stateless (sans état) : Un service doit minimiser la consommation de ressources en déléguant la gestion des informations d’état quand cela est nécessaire.
Découvrabilité : Un service est complété par un ensemble de métas données de communication au travers desquelles il peut être découvert et interprété de façon effective.
Composabilité : Un service doit être conçu de façon à participer à des compositions de services.

Ces 8 aspects sont issus du livre « SOA Principles of Service Design » de Thomas Erl, également auteur du site SOA Principles.

Dans ce billet, nous nous attarderons sur la notion de composabilité.

Un service doit être composable, c’est-à-dire être conçu de façon à participer à des compositions de services.

Ce huitième et dernier aspect constitue en quelque sorte l’aboutissement des sept précédents. En effet, l’ensemble des principes présentés dans cette série vise in fine à la réutilisation des services. Or, cette réutilisabilité n’a de sens que si les services sont effectivement réutilisés en prenant part à des compositions de services.

C’est grâce à la composabilité que sera mis en œuvre le principe de « separation of concerns » au sein d’une architecture orientée services. L’objectif est ici de déterminer la « bonne » granularité de services afin de décomposer la solution à un problème métier de haut niveau en un ensemble de « plus petites unités réutilisables » de traitement : les services.
L’idée est de pouvoir recomposer notre logique métier à l’infini au sein de processus ou de services composites de haut niveau.

La mise en œuvre de cet aspect dans une architecture de services pose donc le problème du bon niveau de granularité pour un service :

Un service trop large ne pourra pas être réutilisé, car il implémente un enchainement de traitements qui n’ont, a priori, de sens que dans le contexte où le service a été écrit. Un service trop large n’est utilisable que par une seule (ou quelques) application(s).
A l’opposé, un service trop fin ne sera pas réutilisé, car il implémente un traitement atomique qui n’apporte pas de valeur ajoutée. Un service trop fin propose un niveau de détail qui n’est pas pertinent d’un point de vue métier.

D’autre part, il faut garder à l’esprit que, d’un point de vue technique (runtime), un service ne sera composable que s’il est autonome et stateless (c’est-à-dire réutilisable).

Déterminer le niveau de granularité adéquat pour les services d’un écosystème est un exercice délicat, qui exige des connaissances (en grande partie métier), de l’expertise et l’expérimentation de différentes options.
La réussite de cet exercice permettra de maximiser la composabilité du portfolio de services, pré-requis indispensable à l’atteinte d’un des objectifs phares de la mise en œuvre d’une architecture à base de services : la réutilisation des services en vue de l’agilisation du SI, indispensable à la réduction du time-to-market, principal élément de ROI des SOA.

Revue de Presse Xebia

Xebia France — Mon, 20 Jul 2009 16:20:01 +0000

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

Actualité éditeurs / SSII

RIA

SOA

Le coin de la technique

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

Soirée Tontons Flexeurs

Actualité éditeurs / SSII

Les standards du Cloud Computing en préparation

Comme pour tout marché émergeant, le Cloud Computing s’est développé autour de technologies propriétaires mises au point par différents éditeurs et fournisseurs. Une session dédiée aux problématiques d’intégration lors du CloudCamp Paris avait conclu qu’aucun standard adapté n’était disponible pour permettre le transfert d’informations entre les différents fournisseurs et technologies du Cloud Computing.

Le monde du Cloud Computing montant en puissance mois après mois, la problématique de standardisation se fait de plus en plus pressante. C’est donc sans surprise qu’on a assisté à la constitution d’organismes de standardisation et de groupes de travail afin d’établir les standards à venir. Afin de donner une visibilité à l’ensemble de ces efforts, l’Open Grid Forum (OGF) annonce la création d’un site commun ou chaque organisme est invité à présenter ses travaux en cours : http://cloud-standards.org. On notera particulièrement deux spécifications prometteuses :

Open Virtualization Format (OVF) : Format de packaging d’application permettant la distribution et le déploiement simplifié sur environnement virtualisé.
Open Cloud Computing Interface (OCCI) : API standardisée permettant la définition, le provisioning et le monitoring d’infrastructures exposées en tant que services sur un Cloud (IaaS).

Par ailleurs, l’Open Cloud Consortium (OCC) explique travailler sur des frameworks d’interopérabilité entre Clouds et l’OASIS expose quant à elle sa vision selon laquelle le Cloud Computing est une extension naturelle des concepts SOA, et que, par conséquent, de nombreux standards qu’elle développe actuellement intègrent cette problématique.

Fin de JavaRebel, place à …

Zeroturnaround, l’éditeur de JavaRebel, doit faire face à un joli défi : pour avoir fait une entorse à la marque déposée Java, il doit modifier le nom de son produit, sans pour autant perdre la notoriété d’ores et déjà acquise. Pour faire d’une pierre deux coups (modifier effectivement ce nom mais aussi s’offrir un joli coup de pub), l’éditeur soumet ce renommage à un concours. En jeu, une licence ~~JavaRebel~~ à vie…

RIA

GWT 1.7 pour les nouveaux navigateurs !

Les dernières releases de GWT étaient plutôt espacées dans le temps (1 an entre 1.4/1.5 et 8 mois entre 1.5/1.6) mais il n’aura fallu attendre que 3 mois pour voir débarquer la version ~~1.6.5~~ 1.7 de GWT.

Cette dernière version (définie comme mise à jour mineure / bugfix release) apporte un meilleur support des derniers navigateurs à savoir Internet Explorer 8, FireFox 3.5 et Safari 4 (meilleur support d’IE8 = disparition d’IE6 ? ).

L’ajout du user.agent ie8, qui peut potentiellement impacter certains projets, a fait pencher la balance vers un numéro de version de type majeure (1.7) pour forcer les développeurs à être attentif sur ce point important (une version de type 1.6.5 n’aurait pas eu le même impact).

Une simple recompilation suffit pour être compatible avec ces navigateurs, aucune modification de code n’est requise. Disponible comme toujours dans la section téléchargement du Google Code.

Flex Monkey 1.0

Plus de 7 mois après la sortie de la version 0.5 (précédente revue de presse), FlexMonkey, le framework de tests automatisés pour applications Flex et Air, se met à jour et passe ainsi en version 1.0 (par InfoQ).

Au menu : réorganisation de l’interface utilisateur, support direct d’applications Air (la console FlexMonkey devenant d’ailleurs une application Air) et tests générés pour Fluint (qui pourront aussi être lancés par FlexUnit 4).

Plusieurs tutoriels/exemples sont déjà disponibles sur la toile, on retiendra plus particulièrement le Getting Started d’Eric Owens (Gorilla Logic) et l’article très complet de Stuart Stern (CEO de Gorilla Logic et créateur de FlexMonkey) sur InfoQ.

SOA

La base de données dans une Event Driven Architecture

Sur son blog dédié aux traitements des évènements dans les systèmes d’informations, Tibco a publié un billet portant sur le positionnement d’une base de données dans une Event Driven Architecture (EDA).

Se trouvant à la base de nombreuses applications et services, elle constitue en effet une potentielle source d’évènements très intéressante. L’auteur met alors en avant la technologie Continuous Query Notification (CQN) intégrée à Oracle 11g, et qui permet aux clients d’une base de données de s’enregistrer pour recevoir des notifications lorsque les données d’une table ou le résultat d’une requête prédéfinie changent. On peut assimiler cette technologie à un mécanisme de trigger qui rappellerait des systèmes externes.

Cette possibilité permet ainsi d’enrichir les sources d’évènements disponibles au sein du système d’information : de par son positionnement, la base de données est capable d’offrir simplement des évènements qui seraient parfois complexes à générer au niveau applicatif. Dans une telle configuration, le Complex Event Processing (CEP) permettra alors de manipuler le volume important d’évènements ainsi créés afin d’en extraire des informations métiers utiles.

REST et les abus de langage

Ryan McDonough, contributeur au projet RESTEasy, a publié un billet dans lequel il fait un parallèle entre les abus de langages liés à REST et les mauvaises pratiques qui en découlent.

Parmi les erreurs de compréhension qu’il met en avant, on retrouve l’assimilation de REST à un protocole, la définition de REST en tant que synonyme de HTTP, ou encore l’utilisation abusive du qualificatif RESTful.

Il est souvent question lorsque l’on parle de REST de définition d’URLs, de représentations multiples d’une ressource, ou, plus couramment encore, d’opposition à SOAP. Loin de ces problématiques, Ryan McDonough met ici en avant le fait que REST est dans la réalité trop souvent utilisé pour justifier à tort tout type d’utilisation douteuse de JSON ou XML sur HTTP…

A ce titre, le livre RESTful WebServices de Leonard Richardson et Sam Ruby permet de comprendre en détail toutes les nuances de ce modèle d’architecture qui sont parfois délicates à appréhender.

Le coin de la technique

OpenDS passe en version 2.0

La version 2.0 du projet OpenDS est disponible. Il s’agit d’un serveur LDAP implémenté entièrement en Java et soutenu par Sun ; ces caractéristiques le positionne donc directement face à Apache Directory Server, son équivalent développé par la fondation Apache.

Ludovic Poitou présente les principales nouveautés de cette version :

Ajout d’un control panel graphique, en remplacement du status-panel de la version précédente, permettant d’administrer le serveur et ses données
Amélioration de la réplication multi-master
Support de connections sécurisées SASL
Affinement du système de contrôle d’accès
Amélioration des performances. On notera sur ce point la collaboration avec l’équipe du garbage collector G1 qui avait été exposée il y a 2 mois

Au delà de l’ajout de fonctionnalités, la question du positionnement reste entière pour OpenDS tout comme pour son rival ApacheDS. En effet, l’annuaire est en général une ressource critique du système d’information pour laquelle on préfèrera généralement une implémentation native plus mature. Dès lors, OpenDS se destinera principalement au poste de développement, aux tests, et aux applications embarquant directement leur propre annuaire comme mécanisme de persistance.

10 bonnes raisons de chercher le successeur de Java

Dans la droite ligne d’un certain nombre de keynotes récentes, Mario Fusco expose, sur TheServerSide, 10 bonnes raisons de chercher un héritier à Java. Ces ‘manques’ de Java sont souvent évoqués, parfois partiellement comblés par les futures spécifications. Il nous a semblé malgré tout intéressant de les reprendre ici, ne serait ce pour que ces limitation soient bien comprises de tous.

Absence de Closures, et son corollaire, l’absence de pointeur sur les fonctions (first-class function).
L’existence de types primitifs (le langage n’est pas 100 % objet), et un autoboxing pas toujours performant (sur la gestion des null par exemple).
La faiblesse des Génériques : impossible de découvrir leur type au Runtime.
L’impossibilité de supprimer certains warnings concernant les génériques.
Impossible de passer un paramètre void à une méthode.
Le pattern proxy n’est pas implémenté de manière native sur les classes concrètes.
Le switch…case est très faible
La présence des exceptions Checked qui obligent à de douloureux try...catch ou à d’illisibles throws

Mario Fusco a l’honnêteté de reconnaitre que nombre de ces défauts font partie des péchés originels de Java et qu’il est quasiment impossible de les remettre en cause sans gravement compromettre la compatibilité ascendante du language, qui en est une des pierres angulaires. C’est pour cette raison qu’il se met en quête du next gen language

Vous ne manquerez pas de remarquer que, comme tout article qui parle de succéder à Java, ce billet est richement (parfois de manière assez virulente) commenté.

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

Soirée Tontons Flexeurs

Demain (mardi 21 Juillet) de 18h à 20h se déroulera une nouvelle soirée des Tontons Flexeurs dont le sujet est un retour d’expériences sur la mise en place d’applications Flex en entreprise dans le monde Java (tests unitaires/fonctionnels, intégration continue…).
L’événement étant déjà complet, il ne vous reste plus qu’à bookmarker leur calendrier pour être informé des prochaines réunions

Revue de Presse Xebia

Xebia France — Mon, 13 Jul 2009 15:53:20 +0000

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

RIA

GChart 2.5 pour GWT

SOA

Le coin de la technique

Making Good Software, bonnes pratiques du développement logiciel

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

Sun fait évoluer sa certification programmer

RIA

GChart 2.5 pour GWT

Afficher des résultats sous forme d’histogramme ou de camembert se résume pour bon nombre de projets Java à l’import de JFreeChart, la librairie de référence pour faire des diagrammes en Java (démo).

Pour les projets GWT, une autre API fait beaucoup parler d’elle en ce moment (entre autres sur Ajaxian et onGWT) et cette API est GChart 2.5. Son objectif est simple : réaliser rapidement de beaux graphiques.

Une démo nous montre les capacités de l’outil en termes de rapidité d’affichage. Le code source de chaque exemple est aussi disponible (source du graphique Estimated Future Oil Prices).

Pour la release note technique (plus de compatibilité GWT 1.4, navigateurs testés, objets et méthodes dépréciés, bugfix…), tout se trouve sur cette page. Il ne reste plus qu’à tester ! Les retours d’expériences sont bienvenus dans les commentaires.

SOA

jBPM 4.0 est disponible

Tom Baeyens annonce sur son blog la disponibilité de la version finale de jBPM 4.0 respectant ainsi le calendrier prévu.

jBPM n’avait pas connu d’évolution majeure depuis 2005, cette nouvelle version constitue donc un évènement majeur pour les utilisateurs de jBPM. Les nouveautés apportées sont importantes :

Nouvelle version du plugin Eclipse (GPD) permettant la définition graphique de processus suivant la notation BPMN
Introduction de JBoss PVM (Process Virtual Machine), un moteur de workflow générique utilisé par jBPM pour l’implémentation des différents langages de définition de processus qu’il propose (jPDL, BPEL et Pageflow)
Refonte des schémas de base de données utilisés pour les rendre plus évolutifs
Intégration native à Spring
Amélioration des performances
Simplification de l’installation

Cette nouvelle version est d’ores et déjà disponible sur le repository Maven de JBoss. Par ailleurs, l’ensemble des apports de jBPM 4 seront passés en revue lors du JBoss World 2009 en septembre prochain, ainsi qu’à Devoxx 09 en novembre.

Avez-vous besoin d’un ESB ?

Ross Mason, fondateur de MuleSource a publié sur son blog une liste de points à vérifier avant de mettre en place un ESB. L’article, au titre plutôt racoleur (To ESB or not to ESB), à fait du bruit sur Twitter. D’ailleurs, en aparté, pour avoir nous-mêmes fait circuler ce lien, nous avons été surpris d’avoir été répondu par un certain @shakesp.

Pour en revenir au cœur du sujet, les points qui nous semblent intéressants sont simples à retenir :

Commencez à penser à un ESB pour intégrer 3 applications, à plusieurs ESB si vous en avez plus que 10
Avez-vous absolument besoin de plusieurs protocoles de communications ?
Avez-vous de réels besoins d’intégration ? Découpage, routing, agrégation de messages …

Le coin de la technique

Making Good Software, bonnes pratiques du développement logiciel

Une fois n’est pas coutume, nous vous proposons cette semaine la découverte d’un blog tout récemment ajouté dans nos RSS : Making Good Software. Ce blog établit des listes de bonnes (et mauvaises) pratiques du développement logiciel. Non pas que son contenu soit extraordinaire, puisque vous en connaissez probablement déjà les plus gros points, mais il a le mérite de les rappeler : toute ressemblance avec personnes existantes ou ayant existé ne suivant pas ces règles ne saurait être que fortuite

Dans un premier article, une liste des 5 erreurs non techniques les plus répandues chez les développeurs, dont nos 2 préférés qui vous feront probablement penser à quelqu’un de votre open-space:

Ego surdimensionné : » je suis le meilleur développeur au monde, et ça me permet d’avoir toujours raison » (ou la fameuse conversation à sens unique)
Manque de discipline : » j’essaye de tout faire en même temps, mais je ne termine jamais rien » (définition de done plus que douteuse)

Un autre article vous donne une liste de 10 points à suivre pour écrire du bon code :

Factorisez votre code, pour simplifier la correction d’anomalies et le refactoring
Ecrivez des méthodes les plus courtes possibles
Travaillez le nom des vos objets, variables et méthodes, il s’agit de la meilleure des documentations
Une seule responsabilité par classe,
Travaillez l’organisation de votre code, par groupes physiques de fichiers et groupes logiques de fonctions
Faites des tests unitaires, quand vous aurez fini, faites-en encore plus
Refactorez le plus tôt et le plus souvent possible
Auto-documentez votre code
Privilégiez le code par interface
Faites des revues de code régulières

Dans un autre article l’auteur décrit une matrice permettant de noter votre code en fonction de sa simplicité et de son extensibilité.

Et pour finir, histoire de ne pas commenter l’ensemble des billets du blog, les 7 étapes pour corriger un bug : de la recherche de l’erreur, à l’analyse des dommages collatéraux.

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

Sun fait évoluer sa certification programmer

Sun teste une nouvelle version de sa certification SCJP (Sun Certified Java Programmer). La grosse nouveauté de cette révision : l’examen contiendra dorénavant une partie programmation. Cette certification, que certains appellent ‘pensez comme un compilateur Java’ évolue donc pour adopter une approche plus pragmatique.

Les demandes d’ New Sun Java Programmer Plus Certification, SCJP vs SJPPC

Revue de Presse Xebia

Xebia France — Mon, 29 Jun 2009 16:32:10 +0000

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

Actualité éditeurs / SSII

Le coin de la technique

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

Retour sur la conférence Jazoon

Actualité éditeurs / SSII

StreamBase lie le Complex Event Processing à Twitter

StreamBase est un éditeur qui fournit une solution de Complex Event Processing (CEP) très populaire dans le monde de la finance. Il s’agit d’un middleware capable d’analyser un flux de messages en temps réel pour y reconnaître des évènements complexes.

Dans un communiqué de presse, l’entreprise annonce proposer un connecteur Twitter pour sa solution de CEP. Il devient ainsi possible pour les systèmes d’information du monde de la finance d’analyser les messages Twitter pour en extraire un sentiment global en temps réel pouvant être utilisé dans un système de trading ou d’analyse marketing.

John Davies, directeur technique d’une société américaine spécialisée dans ce type de traitements financiers, analyse cette annonce et avoue qu’après avoir été sceptique quant à cette idée au premier abord, il y voit désormais une opportunité d’améliorer la réactivité des systèmes par rapport à l’utilisation de simples flux Reuteurs apportant l’information plus tardivement.

Ce type d’annonce permet surtout de réaliser le potentiel de la technologie CEP appliquée à l’exploitation de sources diverses provenant de l’intérieur comme de l’extérieur du système d’information de l’entreprise.

Atlassian Summit : le présent et l’avenir des outils Atlassian

Au début du mois de juin s’est déroulé l’Atlassian Summit à San Fransico. Il s’agissait de la première conférence du genre pour l’éditeur et a pu profiter de l’occasion pour présenter toutes ses nouveautés à venir et revenir sur les dernières évolutions de ses produits. L’ensemble des sessions de cette conférence sont maintenant accessibles librement en ligne.

Nous nous attarderons principalement sur le keynote de Mike Cannon-Brookes, CEO et co-fondateur d’Atlassian, qui résume la majorité des éléments à retenir.

Confluence

La version 3.0 de Confluence a été finalisée il y a peu. Elle apporte principalement :

Ajout d’un macro browser permettant de naviguer facilement parmi les macros disponibles
Apport de nombreuses extensions de nature « sociale » avec une gestion de réseaux, un microblogging de type Twitter, un espace personnel repensé
Gain significatif de performance lors de la navigation et de l’édition

Jira et GreenHopper

Jira 4.0 n’est pas encore finalisé, mais est dors et déjà disponible en version beta. Il apporte quelques nouveautés intéressantes :

Refonte du dashboard de Jira. Il devient largement personnalisable grâce à l’ajout de gadgets à l’image d’iGoogle
Introduction du Jira Query Language (JQL) permettant de faire des recherches avancées simplement grâce à un système de complétion. Les résultats des requêtes peuvent alors être ajoutés au dashboard
Le plugin GreenHopper, permettant d’exploiter le moteur de tâches de Jira pour gérer un projet agile (gestion d’itérations, production de burndown charts, …), devient un produit Atlassian. L’éditeur en ayant annoncé l’acquisition lors du Summit.

Open Social

La généralisation de l’utilisation de l’API Open Social au sein des produits Atlassian est probablement ce qui restera le plus marquant. Ainsi la plupart des produits Atlassian proposeront des gadgets Open Social pouvant être intégrés à n’importe quel conteneur Web s’appuyant sur cette technologie.

Concrètement, il est alors possible d’intégrer un gadget Jira au sein de l’interface de Gmail afin de simplifier la saisie d’une nouvelle anomalie suite à la réception d’un mail décrivant un problème. De même, le dashboard de Jira 4.0 devenant un conteneur Open Social, il est possible d’intégrer un gadget indiquant l’état des derniers builds de Bamboo conjointement aux gadgets indiquant l’état des anomalies et tâches Jira actives. Open Social devient ainsi le vecteur d’intégration des produits Atlassian.

Fisheye, Crucible et Eclipse Connector

Fisheye 2.0 et Crucible 2.0 ne sont également pas encore finalisés mais accessibles en beta. Ils apporteront tous deux une meilleure intégration à Jira, une interface utilisateur refondue et une vue permettant de visualiser l’activité des développeurs sur les différents projets.

Atlassian a également publié fin mai la version finale de l’Eclipse Connector, un plugin permettant d’intégrer certaines fonctionnalités des produits Atlassian au sein d’Eclipse :

Jira est un task repository pour Mylyn, la gestion de tâches s’intègre donc à tous les niveaux dans l’IDE. Il est par exemple possible avec un clic d’ajouter, en pièce jointe de l’anomalie Jira, le context Mylyn et, dans un autre environnement, de le restituer d’un autre clic.
Une vue est dédiée à Bamboo et permet d’observer et d’interagir avec les builds du serveur d’intégration continue de l’éditeur
Il devient possible d’effectuer les code reviews Crucible directement depuis Eclipse
Il est possible de lancer l’affichage de la page Fisheye correspondant à un fichier spécifique par simple clic droit

Ces fonctionnalités étaient déjà disponibles pour IntelliJ, elles le sont maintenant également pour l’IDE Java le plus populaire.

Atlassian continue de se montrer très innovant en apportant un lot intéressant de nouvelles fonctionnalités sur ses produits déjà très populaires. L’acquisition de GreenHopper lui permet quant à elle de se positionner sur le créneau des applications de gestion de projets agiles que Thoughtworks Studios commençait à investir avec Mingle.

Le coin de la technique

Sortie d’Eclipse Galileo

Comme chaque année depuis 2004, fin juin sera marquée par la sortie d’une nouvelle version d’Eclipse IDE.

Après Callisto, Europa et Ganymède, voici venu Galileo (ou Eclipse 3.5).

Difficile de faire un résumé des 24 millions de lignes de codes ni même de la trentaine de projets qui le compose, cependant plusieurs nouvelles fonctionnalités ressortent. A signaler qu’un top 10 de ces nouveautés a d’ailleurs été publié par Ian Bull sur le site d’Eclipse Source (série de 10 billets).

On notera ainsi :

Compatibilité avec Mac OS X (portage SWT vers Cocoa).
Memory Analyzer Tool (MAT), un outil d’analyse de heap (consommation, fuite mémoire …).
Mylyn (gestion de tâches, synchronisation…) qui n’est pas nouveau mais qui devient de plus en plus populaire avec le support entre autre de Jira.
XText qui permet la création de DSL (auto-complétion, coloration syntaxique …).
Rich Ajax Platform (RAP) qui permet de déployer son application en tant que WebApp.
SWT Browser qui gère le pont entre Java et Javascript dans les 2 sens.
Mylyn WikiText, un éditeur de fichier wiki.
Plateforme (p2 avec update manager revu, target platform, deploy into self pour tester ses plugins …).

Le téléchargement se passe par ici avec comme d’habitude plusieurs packages disponibles qui vont de la version classique à la version Java, JEE ou RCP sans oublier, pour les non javaistes, les versions C++ et PHP. D’autres packages ciblant le reporting ou la modélisation sont aussi disponibles.

Et bien sûr, rendez-vous est pris l’année prochaine même date (par Chris Aniszczyk) pour la release d’Eclipse 3.6 qui se nommera Helios !

Des applications Web modulaires avec SpringSource Slices

Rob Harrop a présenté une ébauche d’un nouveau projet SpringSource appelé Slices.

Il s’agit d’un framework basé sur dm Server 2.0 et permettant le développement d’applications Web modulaires. Cette modularité est bien sûr offerte par OSGi, ce qui lui en apporte les caractéristiques particulières : gestion de dépendance versionnées et chargement et arrêt des modules à chaud.

Concrètement une application utilisant Slices offrira un module Web host et un ensemble de modules fils appelés slices. Chaque module apporte du code applicatif et un ensemble de ressources Web (CSS, JavaScript, JSP, images). Le framework offre alors une couche d’abstraction aux slices leur permettant de posséder leur propre session et servlet mappings. Il offre également l’infrastructure nécessaire pour rendre les ressources du module host visibles par tous les autres et pour permettre aux modules de se détecter les uns les autres et ainsi d’opérer des altérations visuelles et comportementales en conséquence.

Dans son état actuel, Slices n’offre qu’une infrastructure de base, la version finale devrait apporter en supplément :

Un framework de composition d’UI. On imagine que celui-ci apportera des tags permettant l’affichage conditionnel en fonction de la présence ou non de certains modules. Cette fonctionnalité est actuellement gérée manuellement par des EL dans l’application d’exemple
Le support des servlet filters
Une intégration à Tiles 2
L’intégration à SpringSource Tool Suite

Slices apportera donc de nouvelles possibilités en apportant la modularité jusqu’à la couche Web. Ainsi, parallèlement à son offre tc Server, résolument orienté vers le marché actuel, SpringSource continue d’innover en apportant des fonctionnalités supplémentaires à son offre modulaire centrée autour de dm Server.

Que devient JMX 2 ?

JMX est une API standard Java permettant le monitoring et le management d’applications, elle est définie par la JSR-3 et étendue par la JSR-160 (Remote JMX). Depuis sa création en 1998, l’API a évoluée au fil des maintenance releases de sa JSR, incrémentant au passage sa version depuis 1.0 jusqu’à 1.4. Au départ disponible sous forme de librairie externe, JMX a finalement été intégré au JDK 5.0 puis mis à jour dans le JDK 6.0, fin 2006, pour s’aligner avec sa dernière version.

La prochaine évolution majeure de JMX est la version 2.0, cette fois-ci définie dans une nouvelle JSR, la JSR-255 (JMX 2.0). Actuellement en statut early draft review, il est dors et déjà possible de se rendre compte des chantiers prévus :

Des namespaces permettant de préfixer les noms des MBeans afin d’offrir une meilleure scalabilité lors que de très nombreux MBeans sont manipulés.
Le cascading permettant de fédérer un ensemble de MBeans situés sur des serveurs différents.
Définition de MBeans standards par annotations (@MBean, @ManagedAttribute et @ManagedOperation) et de leur injecter des ressources telles qu’un MBeanServer ou un ObjectName. Ce principe de définition de MBeans par annotations est calqué sur ce que Spring permet actuellement.
Un nouveau langage de requête permettant d’accéder facilement à tous les MBeans dont les propriétés se conforment à certains prédicats.

JMX 2.0 était initialement prévue pour être intégrée au prochain JDK, l’API avait fait son apparition au sein de la Javadoc des previews du JDK 7 mais restait absent de sa liste de features. Eamonn McManus a clarifié cette situation en annonçant sur son blog que JMX 2.0 ne serait pas intégré au JDK 7 tel qu’initialement prévu, qu’il n’était pas pour autant annulé mais reporté … au JDK 8. L’officialisation de ce report est une mauvaise nouvelle, car cette nouvelle mouture de JMX serait arrivée à temps pour apporter un renouveau à cette API, qui bien que très puissante, souffre parfois de lourdeurs à l’usage.

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

Retour sur la conférence Jazoon

La semaine dernière se tenait à Zürich la conférence où les Javaistes se rencontrent. Xebia était présent à cette conférence et en a publié des résumés quotidiens :

Jour 1 : JEE6 et Glassfish v3
Jour 1 : Groovy
Jour 1 : Développement mobile
Jour 1 : Prospective
Jour 2 : JDK 7
Jour 2 : DDD et Value Objects
Jour 2 : Java FX
Jour 3 : Un arbre est tombé
Jour 3 : Les secrets des programmeurs Rockstars
Jour 3 : Hibernate Search

SOA : Du composant au service : La découvrabilité

Christophe Heubès — Fri, 12 Jun 2009 07:00:45 +0000

Pour répondre plus précisément à la question, nous vous proposons de passer en revue les huit aspects qui caractérisent un service :

Contrat standardisé : L’ensemble des services d’un même Système Technique sont exposés au travers de contrats respectant les mêmes règles de standardisation.
Couplage lâche : Le contrat d’un service doit imposer un couplage lâche de ses clients.
Abstraction : Le contrat d’un service ne doit contenir que les informations essentielles à son invocation. Seules ces informations doivent être publiées.
Réutilisabilité : Un service exprime une logique agnostique et peut ainsi être positionné comme une ressource réutilisable.
Autonomie : Un service doit exercer un contrôle fort sur son environnement d’exécution sous-jacent. Plus ce contrôle est fort, plus l’exécution d’un service est prédictible.
Stateless (sans état) : Un service doit minimiser la consommation de ressources en déléguant la gestion des informations d’état quand cela est nécessaire.
Découvrabilité : Un service est complété par un ensemble de métas données de communication au travers desquelles il peut être découvert et interprété de façon effective.
Composabilité : Un service doit être conçu de façon à participer à des compositions de services.

Ces 8 aspects sont issus du livre « SOA Principles of Service Design » de Thomas Erl, également auteur du site SOA Principles.

Dans ce billet, nous nous attarderons sur la notion de « découvrabilité« .

Nous l’avons dit et répété tout au long cette série, la réutilisabilité des services constitue une des pierres angulaires de la mise en œuvre d’une architecture orientée service. En effet, la mise en œuvre d’une SOA vise, entre autres, à éviter le gaspillage des ressources en éliminant les redondances inhérentes au modèle en silo. D’autre part, la réutilisation est une condition première de l’agilisation du SI indispensable à la réduction du time-to-market, principal élément de ROI des SOA.

Le positionnement des services comme ressources réutilisables au sein de l’entreprise passe par :

La prédictibilité des services proposés (ce qui implique que les services soient autonomes et sans état).
La découvrabilité des services existants.

Écartons tout de suite le mythe de la découvrabilité au runtime qui reste un espoir inabouti (ou une promesse non tenue) : Un service répondant aux besoins et contraintes d’un consommateur potentiel ne peut être identifié que par un acteur humain. Nous parlons donc bien ici de découverte des services en phase de conception.

Cette découvrabilité des services existants passe par la mise en œuvre d’un repository de services qui vient outiller l’inventaire des services disponibles. Ce repository stocke l’ensemble des métadonnées nécessaires à :

La recherche des services de l’inventaire.
La récupération de l’ensemble des artefacts relatifs aux services de l’inventaire (Spécifications, SLAs, Policies, Schémas XML, WSDL, Interfaces, …).

Remarque : Attention à ne pas confondre le repository de services avec un registre de services qui a lui la responsabilité de référencer pour le runtime les endpoints (points d’accès physiques) des services déployés.

Ainsi, le concepteur d’un consommateur de service (Service composé, application composite, orchestration, processus, …) pourra s’appuyer sur ce repository de la façon suivante :

Le concepteur recherche dans le repository un service possédant les fonctionnalités dont il a besoin (1).
En se basant sur les métadonnées contenues dans le repository, le concepteur est capable de découvrir et d’identifier un service potentiellement capable de répondre à ces besoins (2).
le concepteur peut alors accéder au contrat du service : syntaxique, sémantique et de niveau de service (3). il est alors capable, en se basant sur les différents artefacts constituant le contrat du service (spécifications, SLAs, policies, syntaxe, …), de déterminer si le service découvert correspond bien à ces attentes.

Afin qu’il remplisse au mieux son rôle, les fonctionnalités attendues d’un repository de service sont :

Le catalogage des services, de leurs métadonnées et des artéfacts relatifs à ces services.
La validation des services et artéfacts catalogués vis-à-vis des standards de l’entreprise.
La gestion des dépendances entre les services et les artéfacts.
Le versioning des services et de leurs différents artéfacts.
La gouvernance de la publication au sein du repository.
Le support d’un large panel de type d’artéfacts.

Le repository de services constitue donc un outillage indispensable à la découvrabilité de l’inventaire des services. Il permet une gestion centralisée de l’ensemble des données relatives aux services, devenant ainsi un des éléments centraux autour desquels s’articulera la gouvernance SOA.

Revue de Presse Xebia

Xebia France — Mon, 08 Jun 2009 17:00:29 +0000

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

Actualité éditeurs / SSII

RIA

Sortie beta de Flash Builder 4 et de Flash Catalyst

Le coin de la technique

Actualité éditeurs / SSII

Tibco dans les nuages avec Silver

Tibco a annoncé la semaine dernière la sortie prochaine de Silver, une plate-forme de Cloud Computing en mode PaaS (Platform as a Service). Cette offre entrera en phase de beta privée d’ici la fin du mois de juin et ne sera disponible qu’en 2010.

Dans un premier temps, Tibco a fait le choix d’adosser Silver sur Amazon EC2 (Elastic Compute Cloud) pour la partie infrastructure. L’objectif à terme est d’offrir une intégration avec un large panel des fournisseurs de plates-formes de Cloud Computing (y compris des plates-formes maisons) et ainsi de positionner Silver comme une plate-forme d’exécution universelle agnostique vis-à-vis de l’infrastructure qui la supporte.
Dans ses premières versions, Silver proposera des conteneurs pour l’exécution de composants Java, Spring, POJO, et Ruby et d’ici peu, Silver supportera également Python, Perl, C, C++, et .Net. Tibco adressera ainsi un panel très large de technologies de développement.

La plate-forme Silver vise à outiller cette infrastructure de Cloud Computing. Pour ce faire, Tibco capitalise sur son offre SOA ActiveMatrix afin de proposer :

Un modèle de composition et d’orchestration de services basé sur SCA (Service Component Architecture) : Tibco ActiveMatrix BusinessWorks.
Un backbone d’intégration, tiers d’inter-médiation supportant la communication et l’échange entre services au travers d’un large choix de protocoles de transport : Tibco ActiveMatrix Service Bus.
La supervision et la gestion des performances et des SLAs des services déployés : Tibco ActiveMatrix Service Performance Manager.
Un système de gouvernance pour la gestion du cycle de vie des services et de leurs règles d’utilisation (policies) : Tibco ActiveMatrix Lifecycle Governance Framework.

D’autre part, Silver tire largement partie du savoir faire de Tibco dans le domaine du CEP (Complex Event Processing) : Tibco BusinessEvents.
La combinaison des capacités de supervision des SLAs (et plus largement des performances) et des capacités de CEP de la plate-forme permet d’automatiser le provisionnement de l’infrastructure de Cloud Computing.
C’est là la grande promesse de Silver : proposer une plate-forme capable d’allouer (ou de désallouer) automatiquement des ressources à des services ou à des applications au sein de l’infrastructure de Cloud Computing en fonction de l’utilisation qui en est faite dans le temps. Ainsi, là où sur les autres plates-formes une intervention humaine est nécessaire pour faire jouer l’élasticité de la plate-forme, Silver adapte l’utilisation qui est faite de l’infrastructure en se basant sur ses capacités de monitoring dont les résultats sont traités au travers d’un modèle Evènement / Décision / Action s’appuyant sur les règles de gestion des SLAs.

Oracle s’investit dans JavaFx

Du moins, Larry Ellison, qui suggère de ré-écrire l’UI de OpenOffice en utilisant JavaFx.
En attendant cette hypothétique révolution, le framework de Sun a dévoilé quelques nouveautés durant JavaOne, en ajout à la sortie de la version 1.2 dont nous nous faisions l’écho la semaine dernière.

Démonstration d’un outil collaboratif de développement : en plus des annonces de renforcement du développement du plugin JavaFx-Eclipse, Sun a donné une démonstration publique d’un outil de création graphique assez impressionnant : gestion de la Scene, drag and drop de composants, d’effets… Reste à savoir quand celui ci sera disponible…
Autre démonstration, plus attendue, celle de JavaFx for TV, avec une application réalisant des prévisualisations et des téléchargements de films à partir d’un téléviseur LG.

G1 payant : une simple incompréhension

La semaine dernière, une simple petite phrase a suffit à déclencher un tollé :
Although G1 is available for use in this release, note that production use of G1 is only permitted where a Java support contract has been purchased. G1 is supported thru Sun’s Java Platform Standard Edition for Business program.
[...]l’utilisation en production de G1 n’est autorisée que pour les utilisateurs ayant acheté un contrat de support Java[...]
Oracle avait il sonné le glas des JVM gratuites ?

Visiblement, tout cela ne serait qu’un choix de mots malheureux, qui ont d’ailleurs été remplacés par la phrase suivante :
G1 is available as early access in this release, please try it and give us feedback. Usage in production settings without a Java SE for Business support contract is not recommended.
[...]l’utilisation en production [de G1] … est déconseillé en l’absence de support Java SE Business[...]

Par ailleurs, Alexis MP (Sun), en réaction à la publication de la news la semaine dernière, apporte quelques précisions dans son commentaire sur notre blog :

G1 peut être assimilée à une option (donc non essentielle) payante, comme cela se pratique chez MySql.
La monétisation du support Java SE Business n’est pas une nouveauté.
Sun est toujours indépendant, et ses choix et annonces ne sont pas influencés par Oracle

Réel quiproquo donc, sans conséquences? Quoi qu’il en soit, la communication de Sun a été bien maladroite, en ces temps où de gros doutes planent sur l’avenir de Java.

RIA

Sortie beta de Flash Builder 4 et de Flash Catalyst

Adobe a annoncé les sorties de ses nouveaux produits en version beta. Flash Builder 4, successeur du Flex Builder, supporte le Flex SDK 4 et propose de nouvelles fonctionnalités. Parmi elles nous noterons le support de Flex Unit, la possibilité de lier les données aux composants (ex : services Java). Une liste des nouveautés et améliorations est disponible ici.
Flex SDK 4 (Gumbo) nous arrive avec une nouvelle architecture : Spark Component. Cette dernière permet de séparer la gestion de la customisation, mise en page et de la logique des composants. Cette séparation a été effectuée afin que les futures versions du SDK puissent évoluer, tout en gardant la rétro compatibilité avec les SDK antérieurs. De plus, cela permet également d’avoir une gestion plus fine de la customisation des composants. Néanmoins, cela a entrainé l’arrivé d’une syntaxe MXML plus enrichie (= namespace supplémentaires) :

xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/halo"

De plus, Flex 4 introduit le support de FXG : cette librairie permet de simplifier la création d’objets graphiques (rectangle, ellipse, …) ainsi que d’effets (transformations) pour la plateforme Flash. Les performances concernant la compilation ont été améliorées. Vous trouverez une liste des autres nouveautés ici.

Enfin, Flash Catalyst est arrivé : ce dernier nous donne la possibilité de « transformer » des artworks Photoshop et/ou Illustrator en interface utilisateur avec la collaboration de Flash Builder 4. Voici une vidéo assez impressionnante sur l’utilisation de ce nouveau produit. Le but est de pouvoir dérouler un meilleur workflow entre les designers et les développeurs. En effet, avec Flash Catalyst un designer peut faire une maquette sous Photoshop, ajouter les effets de transitions et de succession de pages. Ce dernier sauvegarde le projet Flash Catalyst qui pourra être utilisé par un développeur sous Flash Builder 4.

Cependant, nous noterons des interrogations : le coup des licences : actuellement les licences Photoshop et Flex Builder 3 représentent un investissement qui n’est pas forcément négligeable. Peut être qu’Adobe proposera un package avec toute la suite ? De plus, la relation entre designer/développeur peut apporter un certain danger : toutes les sociétés n’ont pas le luxe d’avoir des ressources dédiées au design … les développeurs devront donc se mettre au design, ou alors les designers devront avoir de meilleurs connaissances au niveau développement (utilisation du Flash Builder 4).
Pour conclure, avec toutes ces nouveautés nous voyons qu’Adobe a décidé de passer à la vitesse supérieure, et veut continuer d’être un des acteurs principaux dans la guerre des technologies RIA.

Le coin de la technique

Project Coin

Voici quelques nouvelles de Project Coin (dont nous vous parlions il y a quelques mois) par l’intermédiaire de Joseph Darcy et de sa présentation faite à JavaOne suite à la seconde sélection de features retenus le 27 mai dernier.

Pour rappel, le but du projet est de proposer de petites évolutions pour le langage Java, la communauté pouvant participer en passant par la mailing-list (avec du beau monde comme Bob Lee, Joshua Bloch, Neal Gafter…). Plusieurs comptes rendus de cette session sont déjà disponibles (chez Alex Miller ou Cay Horstmann). On retiendra ainsi :

Le switch avec String (switch(str) {case "foo": return 1; case "bar": return 2; })
Le multi catch (try { ... } catch (Extype1 | Extype2 ex) { logger.log(ex); })
L’exception handling avec les opérateurs ?:, ?. et ?[] (proposition)
La collection literals ou création de liste avec valeur par défaut comme pour les tableaux (List list = ["a", "b"];)
L’opérateur diamond permettant d’avoir un constructeur light qui ne contient pas les generics (Map();)
Nombres avec underscores (long creditCardNumber = 1234_5678_9012_3456L;)

De bien belles propositions donc qui allégeront nos classes Java, surtout ces ignobles if(myObject != null) {return myObject.aMethod()} qui deviendrait ainsi myObject?.aMethod();. En espérant que tout ce petit monde arrivera vite…

(Com)prendre la vague Google Wave

Définitivement la star de Google I/O 2009, Google Wave se dévoile peu à peu et nous laisse admirer la mécanique qui se cache derrière la future (?) référence de plate forme collaborative.
Le coeur du système repose sur le protocole créé pour l’occasion.
InfoQ propose un zoom sur 2 sous domaines de ce protocole, extraits du site officiel que Google consacre à son invention :

Operational Transform : c’est le coeur du système, le framework de gestion de la concurrence. Toute modification est sauvée en local et envoyée en temps réel au serveur, qui se charge de traiter toutes les fusions, conservant la version référence, qui est ensuite poussée vers tous les clients graphiques consultant ce document. Dans l’attente de l’accusé de réception du serveur (le serveur a reçu la modification, l’a incorporé, et l’a propagé à tous les clients), chaque client cache toutes les modifications effectuées en local, qui seront envoyées en paquet ultérieurement.
le modèle de données : une Wave contient plusieurs Wavelets, qui contiennent des participants et des documents. La concurrence d’accès est gérée au niveau Wavelet. L’état d’un Wavelet est déterminé par une séquence ordonnée de modifications appliquées / en cours d’application sur un document.

A noter en outre que Google réutilise pour l’interface graphique deux de ses technologies open source, à savoir GWT (dont c’est le grand retour chez Google) et Google Gears (pour le drag & drop).

SOA : Du composant au service : Sans état (Stateless)

Christophe Heubès — Thu, 04 Jun 2009 04:32:16 +0000

Pour répondre plus précisément à la question, nous vous proposons de passer en revue les huit aspects qui caractérisent un service :

Contrat standardisé : L’ensemble des services d’un même Système Technique sont exposés au travers de contrats respectant les mêmes règles de standardisation.
Couplage lâche : Le contrat d’un service doit imposer un couplage lâche de ses clients.
Abstraction : Le contrat d’un service ne doit contenir que les informations essentielles à son invocation. Seules ces informations doivent être publiées.
Réutilisabilité : Un service exprime une logique agnostique et peut ainsi être positionné comme une ressource réutilisable.
Autonomie : Un service doit exercer un contrôle fort sur son environnement d’exécution sous-jacent. Plus ce contrôle est fort, plus l’exécution d’un service est prédictible.
Stateless (sans état) : Un service doit minimiser la consommation de ressources en déléguant la gestion des informations d’état quand cela est nécessaire.
Découvrabilité : Un service est complété par un ensemble de métas données de communication au travers desquelles il peut être découvert et interprété de façon effective.
Composabilité : Un service doit être conçu de façon à participer à des compositions de services.

Ces 8 aspects sont issus du livre « SOA Principles of Service Design » de Thomas Erl, également auteur du site SOA Principles.

Dans ce billet, nous nous attarderons sur la notion de « statelessness« .

Comme nous l’avons expliqué dans le précédent billet de cette série : Mettre l’emphase sur la réutilisabilité des services commence par la fourniture de services proposant une logique réutilisable, mais implique également que l’implémentation de cette logique soit effectivement réutilisable une fois déployée.
Dans une optique de sollicitation massive, il est important de concevoir l’implémentation des services en prêtant tout particulièrement attention à la concurrence d’accès. Les accès concurrents à un service ne doivent en aucun cas modifier son comportement, sa fiabilité ou ses performances. En d’autres termes, un service doit respecter son contrat (et ses SLAs), quel que soit le volume de sollicitations auquel il est soumis : Un service doit être prédictible.
Afin de garantir cette prédictibilité dans le cadre d’accès concurrents, deux principes doivent être appliqués lors de l’élaboration des services :

Un service doit (au maximum) être autonome.
Un service doit être sans état.

Ces deux aspects sont fortement liés : Le principe d’autonomie des services implique que le comportement d’un service ne dépende pas du contexte dans lequel il est invoqué (contexte fonctionnel ou contexte technique). Dans cette optique, intégrer de la gestion d’états au sein de nos services est un non sens.

D’une manière plus générale, la gestion d’états (d’informations de contexte) au sein d’un service pose des problèmes :

De compréhension et de maintenabilité :
La gestion d’états va sensiblement augmenter la complexité cyclomatique de l’implémentation et donc rendre difficile sa lecture, sa documentation, sa testabilité (plus cette complexité cyclomatique est élevée, plus il est difficile d’obtenir une couverture de code acceptable), … Dans le cadre d’une composition de services, la complexité du composé étant directement liée à celle de ses composants, la complexité des services de plus haut niveau peut donc rapidement devenir ingérable.
De réutilisation :
La gestion d’états au sein du service brouille la lisibilité de son contrat puisque l’adaptation de son comportement en fonction de son état ne transparaît pas dans son contrat. Or la lisibilité et la transparence des contrats de service sont des facteurs clés de la réutilisation des services.
D’autre part, l’utilisation d’états au sein d’un service présuppose souvent l’utilisation de ce service au sein d’un enchaînement d’invocations défini à l’avance. Il sera donc difficile de réutiliser le service au sein d’une autre orchestration ou composition.
De performances : car la gestion des état est consommatrice de ressources systèmes, notamment en terme de stockage de ces états (en mémoire ou sur disque).

On préférera donc la conception et l’implémentation de services stateless. La responsabilité de la gestion d’états sera alors déléguée aux utilisateurs (consommateurs) des services : compositions, orchestrations, processus, … Ce transfert de responsabilité (déléguer la gestion d’états au client) rejoint les principes d’une approche REST des services.

Le retour sur investissement des infrastructures informatiques

Xebia France — Tue, 19 May 2009 07:02:38 +0000

Ce jeudi 14 mai, Guillaume Bodet (Directeur Technique de Xebia) était l’invité de l’émission 01 Business sur BFM Radio en compagnie d’Yves Caseau (Directeur général adjoint en charge de la prospective, de la qualité, des services et de l’innovation chez Bouygues Télécom, dont il est ancien DSI) et de Michel Mariet (Responsable marketing middleware d’Oracle France).

Le sujet de l’émission était « Le retour sur investissement des infrastructures informatiques« :

Comment calculer le retour sur investissement (ROI) des infrastructures informatiques ?
Comment aligner ces infrastructures sur la stratégie de l’entreprise ?
Quel ROI apporte la mise en œuvre des SOA (Architectures Orientées Services) ?

Bonne écoute.

Revue de Presse Xebia

Xebia France — Mon, 18 May 2009 16:48:34 +0000

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

Actualité éditeurs / SSII

Grails 1.1.1 supporté par Google App Engine

Agilité

SCRUM en vidéo en 5 minutes

SOA

REST : Le bon et surtout le moins bon …

Le coin de la technique

Actualité éditeurs / SSII

Grails 1.1.1 supporté par Google App Engine

Dans une précédente nouvelle, nous avions annoncé la sortie de Google App Engine pour Java et Groovy. Après Struts2, Spring MVC, le support de nombreux frameworks web continue.
Le framework web Grails, basé sur le langage Groovy et développé par l’équipe de Spring est maintenant supporté par App Engine. Des ajustements ont été apportés pour le rendre compatible, d’où la sortie de cette version 1.1.1.. Celle ci apporte aussi des corrections de bugs, dont la liste est disponible ici.
Par ailleurs, un plugin a été développé pour faciliter l’intégration de Grails avec le SDK de App Engine, notamment au niveau du déploiement du serveur web.

L’objectif fixé par SpringSource est que Grails devienne le framework web le plus utilisé avec Google App Engine, d’où les nombreux efforts fournis. Les prochains axes de travail porteront sur l’abstraction de JPA/JDO pour faciliter l’utilisation du data store (base de données) d’App Engine.

Agilité

SCRUM en vidéo en 5 minutes

Tout simplement géniale, cette vidéo fait le tour de la blogosphère SCRUM / Agile : Le retour de 6 mois d’expérience d’une équipe SCRUM.

Tout y est :

L’équipe.
Les cérémonies.
Les artefacts.
Le fun.

La réalisation très soignée et la BO ne gâchent rien.

A regarder !

SOA

REST : Le bon et surtout le moins bon …

Dans l’article « REST – The Good, The Bad and The Ugly« , publié sur DZone, Arnon Rotem-Gal-Oz propose un éclairage intéressant de ce qu’il y a de bon et surtout de ce qu’il peut y avoir de moins bon lors de la mise en place d’une architecture REST.
On retiendra de cette déclinaison deux travers récurrents dans la mise en œuvre de REST :

Limiter REST à REST over HTTP : Ce raccourci appauvrit en effet dramatiquement les possibilités que nous offre la mise en place d’une architecture REST
Limiter REST à l’utilisation du GET et du POST : Ici encore, n’utiliser qu’une sémantique à 2 verbes nous prive de la richesse dont nous pourrions profiter.

Comme pour beaucoup d’autres sujets (les méthodes agiles, les SOA, …), la mise en place d’architectures REST nécessite un changement d’approche et de façon de penser : REST implique une approche orientée ressources qui ne nous est pas naturelle. Il est donc primordial de ne pas bruler les étapes et de faire l’effort du changement avant de pouvoir bénéficier des promesses de REST.

Le coin de la technique

Utiliser Selenium Grid avec Hudson

Depuis 2006, Hudson offre un plugin Hadoop permettant d’utiliser son cluster Hudson pour effectuer des traitements lourds de type MapReduce.

Selenium Grid, d’autre part, est une solution permettant de distribuer un ensemble de tests Selenium sur plusieurs machines, permettant ainsi de ramener leur temps d’exécution à un ordre de grandeur plus propice à l’intégration continue.

Kohsuke Kawaguchi, créateur du projet Hudson, vient d’annoncer la disponibilité d’un plugin Selenium Grid. Outre l’intégration à Hudson, facilitant le démarrage automatisé des tests, ce plugin présente l’intérêt de simplifier la configuration, puisqu’il s’appuie sur l’infrastructure cluster d’Hudson.

Il s’agit là d’une avancée qui devrait permettre de rendre plus accessible et moins coûteuse l’exploitation quotidienne de larges quantités de tests d’intégration. Parmi les perspectives d’avenir pour la pleine utilisation d’un cluster Hudson, on notera également une très intéressante proposition sur le Jira du projet Hadoop visant à créer un distributed JUnit TestRunner.

Une API Criteria pour JCR

Magnolia est un CMS en Java qui repose sur la technologie JCR (Java Content Repository, JSR-170) pour assurer la persistance versionnée des informations qu’il présente.

JCR, dans sa version 1.0, propose deux possibilités pour exécuter des requêtes sur son repository de contenu : XPath, supporté en standard, et SQL, dont le support est défini comme optionnel par la spécification JCR.

Dans ces deux cas, les requêtes se font en mode texte. Dans certains cas d’utilisation, tels que les recherches multi-critères, cela peut amener le développeur à créer une logique de construction de requêtes par concaténation. Avec Hibernate, ce genre de problématique est adressée par l’API Criteria qui rend le développement de ce type de besoin trivial.

Partant de ce constat, les développeurs de Magnolia proposent une librairie utilitaire permettant la construction de requêtes JCR par programmation. Cette librairie repose sur Magnolia mais pourrait être adaptée pour devenir standalone.

Ceci préfigure de ce que JCR 2.0 (JSR-283), actuellement en statut proposed final draft, s’apprête à offrir : les requêtes pourront être définies de manière objet grâce à l’API JCR-JQOM (JCR Java Query Object Model). Apache Jackrabbit, l’implémentation de référence, supporte déjà partiellement JQOM.

Intégration simple de GWT et Spring

Et même super simple selon l’article de Dev Bright qui dans son exemple s’appuie sur le projet gwtrpc-spring (qui nous permet par la même occasion de tester une autre librairie que GWT-SL, la librairie référence des projets GWT actuels). L’article est d’autant plus intéressant qu’il utilise les annotations pour déclarer les services auprès de Spring.

Les services seront accessibles par une URL qui possèdera une extension spécifique qui sera mappée dans le web.xml. Cela évite ainsi une multitude de servlets dans le web.xml. Ici il n’y aura qu’une seule servlet mais qui mappera toutes les extensions de type .rpc.

Le service :

@RemoteServiceRelativePath("myservice.rpc")
public interface MyService extends RemoteService {
   String myMethod(String arg);
}

Le web.xml :


   
      dispatcher
      org.gwtrpcspring.RemoteServiceDispatcher
   
   
      dispatcher
      *.rpc
   
   
      org.springframework.web.context.ContextLoaderListener

Pour le fichier de configuration Spring, il suffit d’activer la configuration par annotation et de donner le package à scanner :

Du coup, plus aucune configuration XML, l’annotation @Service finit le travail :

@Service
public class MyServiceImpl implements MyService {
   public String myMethod(String arg) {
      // You impl...
   }
}

En quelques lignes et très peu de configuration, l’auteur a créé une application GWT, Spring, avec annotation et avec un web.xml bindant tous les appels RPC. L’avantage dans cette configuration est que les fichiers XML de configuration n’évolueront pas (sauf ajout de nouveaux packages).

Le projet est récupérable à cette url.

8 bonnes pratiques pour améliorer scalabilité et performances

Wille Faler donne 8 conseils pour optimiser la scalabilité de vos applications.

Déchargez la base de données : la base de données relationnelles est le plus courant des goulets d’étranglements sur nos applications.
Utilisez des caches : cacher est un moyen simple d’appliquer le point précédent.
Cachez des objets complexes : même si des objets ‘à maille fine’ sont stockées, cacher des entités plus complexes permettra de moins solliciter les ressources lors d’une recherche dans le cache, et de ramener plus rapidement une grappe d’objets complète.
Ne sauvez pas d’état en base : ne doivent persister que les données business (pas d’informations de login, de session…)
Réfléchissez à la spacialisation : placer les données au plus près de là où elles doivent être utilisées (en utilisant un CDN par exemple)
Restreignez les accès concurrents aux ressources sensibles : il est plus performant d’adopter une attitude ‘un seul thread à la fois’
Abusez de l’asynchrone pour fractionner vos process : séparez vos traitements en petites unités, traitées par des workers distincts; afin d’éviter un phénomène d’engorgement généralisé.
Ne surchargez pas le réseau : sortir de votre runtime applicatif est couteux en temps, limitez donc les échanges avec les systèmes tiers.

Certains diront ‘encore un article de bonnes pratiques performance’… Pour notre part, sorti des grands classiques (base de données, réseaux…), nous avons apprécié deux conseils plutôt originaux : le caching d’entités complexes, et la spacialisation.

Revue de Presse Xebia

Xebia France — Mon, 11 May 2009 16:48:58 +0000

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

SOA

Fuji, le futur d’OpenESB

Le coin de la technique

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

Soirée Datagrid au Paris Jug

SOA

Fuji, le futur d’OpenESB

La prochaine version d’OpenESB, qui sera estampillée ‘v3′, est en cours de développement sous le nom de code ‘Project Fuji’. Ce projet a été récemment mis en avant par Andi Egloff, dans un webcast qui fait le tour des nombreuses nouveautés. Les principales d’entre elles sont :

Integration Flow Language (IFL) : il s’agit d’un DSL externe permettant de définir des flux d’intégrations. Le rôle de ce langage est donc le même que le DSL interne offert par Apache Camel.
Distributed JBI : La spécification JBI (JSR-208) ne couvre pas la problématique de distribution des composants JBI sur plusieurs noeuds. Fuji apporte une extension propriétaire pour permettre cette distribution.
Utilisation de composants OpenJBI : ces composants seront utilisables directement dans OpenESB v3. Le projet prévoit de mettre les composants dont la compatibilité aura été validée dans le repository Maven du projet.
Enterprise Integration Patterns : un certain nombre d’EIP sera supporté en standard et configurable via le langage IFL.

La version finale d’OpenESB v3 est prévue pour le second semestre 2009, l’équipe du projet annonce une probable preview pour JavaOne en juin.

Le coin de la technique

Concevoir des APIs efficaces

John De Goes vient de publier une série de deux articles (première partie et deuxième partie) portant sur les bonnes pratiques de conception d’APIs. Il s’appuie sur un exemple d’API de configuration pour illustrer son propos. Les points qu’il met particulièrement en avant sont :

Il est important de sélectionner le niveau d’abstraction approprié et d’assurer l’uniformité de celui-ci sur l’ensemble de l’API, ainsi que de définir et respecter une responsabilité pour chaque classe. Ceci concerne la granularité des méthodes, le type d’objets manipulés en entrée et en sortie, ainsi que la présence et le type d’exception éventuellement renvoyée.
N’offrir qu’une seule possibilité pour chaque besoin, afin d’éviter la confusion chez l’utilisateur de cette API.
S’appuyer sur les possibilités offertes par le langage pour empêcher certaines mauvaises utilisations d’une API.
L’API doit être la plus intuitive possible afin de minimiser autant que possible le besoin pour l’utilisateur d’avoir à se plonger dans une documentation.

Certaines de ces idées sont déjà partagées par de nombreux développeurs, mais comme c’est souvent le cas dans l’énonciation de bonnes pratiques ou de patterns, tout l’intérêt réside ici dans la formalisation apportée par l’auteur.

Les lecteurs intéressés par cette problématique pourront se tourner vers le livre de Jaroslav Tulach, Practical API Design, qui apporte l’intéressant retour d’expérience d’un architecte de NetBeans, ou encore How to Design a Good API and Why it Matters par Joshua Bloch (auteur de Effective Java).

JavaFX : informations et controverses

Depuis plusieurs mois, nous vous rapportons les différentes informations et controverses à propos de JavaFX. Cette technologie RIA, développée par Sun, et introduite en décembre 2008 fait beaucoup parler d’elle car personne ne sait dire aujourd’hui ce qu’il adviendra de JavaFX dans les mois et années à venir.

Les propos particulièrement négatifs dont JavaFX a été victime à ses débuts se font moins nombreux, non pas parce que cette technologie a convaincu, mais parce qu’elle n’est plus au centre des débats. En fait, ceci est bénéfique puisque cela permet d’observer plus sereinement les différents exemples postés régulièrement par la communauté JavaFX naissante. Il ressort de ce tour d’horizon que les capacités actuelles de JavaFX ne prêtent pas à critique : les fonctionnalités de graphisme et d’animations qui sont offertes semblent satisfaire de nombreux développeurs. Le problème porte principalement sur les manques et les promesses non tenues à ce jour :

la portabilité de JavaFX sur plusieurs environnements (_desktop_, web, mobile, et TV, le fameux ‘All the screens of your life‘) n’est pas assuré puisque le déploiement est impossible sur mobile, faute de device compatible. Le fonctionnement sur téléviseur est lui toujours prévu dans une version ultérieure.
les composants graphiques de haut niveau sont absents. Il s’agit pourtant d’un élément indispensable pour le développement d’applications RIA.

Joshua Marinacci, un des meneurs de JavaFX chez Sun, a été interviewé par Scott Hanselman dans un podcast. Il annonce que la démonstration de JavaFX sur TV pourrait être faite lors de JavaOne 2009, en juin. Il reconnaît par ailleurs le marketing excessif entourant cette technologie.

Outre ces réflexions d’ordre technique, le rachat de Sun par Oracle constitue une autre source de débats. Personne ne sait quelle décision Oracle prendra quant à JavaFX : soutenir ce projet qui nécessite encore un investissement lourd pour prétendre réellement concurrencer les autres acteurs RIA ou abandonner ce marché. Les différentes opinions sur ce sujet sont présentées et argumentées dans le dernier podcast des Cast Codeurs.

Sortie de Wicket 1.3.6

Wicket, le framework orienté composant de la Fondation Apache, sort en version 1.3.6 (1.4 toujours en release candidate 2).

Malgré les 7 mois d’écart avec la version précédente, il ne faut pas s’attendre à une révolution pour cette nouvelle mouture. Il s’agit en effet d’une version de stabilisation et d’amélioration. On notera donc de nombreux correctifs de bugs et plusieurs améliorations.

Cette version est téléchargeable sur le site d’Apache ou en changeant votre version de pom.xml en 1.3.6.

A noter, toujours autour de Wicket, le retour critique de Tom’s Quest sur Wicket et ses limites après la présentation, chez Zenika, de Martin Dashorst, un des committers principaux de Wicket et coauteur du livre Wicket In Action.

@Inject standardisation de l’injection de dépendances

Pas mal de bruit la semaine dernière dans la blogosphère Java avec l’annonce par Google et SpringSource d’une nouvelle proposition de JSR dédiée à l’injection de dépendances : @Inject (« Annotations for Dependency Injection »).
Comme le souligne ‘Crazy’ Bob Lee, l’auteur principal de Google Guice, la sortie de Spring 1.0, il y a déjà 5 ans, a apporté l’injection de dépendances aux masses, via un fichier de configuration propriétaire. Il y a 3 ans, Google Guice a proposé la même chose via des annotations (et SpringSource propose la même chose depuis Spring 2.5).
Si le succès de Google Guice est assez limité face au raz de marée Spring, le constat est là : il manque un standard. Comme les deux librairies ne sont pas compatibles, si vous exposez à un autre projet/équipe une librairie contenant des dépendances injectées par Google Guice, et que l’autre équipe utilise Spring, elle devra redéfinir tous les beans et leurs dépendances dans un fichier de configuration Spring (ou des annotations Spring).
@Inject propose donc de standardiser les annotations, afin de rendre portables sur différents frameworks (Guice, Spring, Tapestry IOC, etc.) des classes injectables.

Lire notre article à ce sujet : @Inject standardisation de l’injection de dépendances.

Sortie de Tapestry 5.1

Tapestry, dont on parlait récemment dans l’article l’injection de dépendances avec Tapestry IoC, passe en version 5.1 en respectant à la lettre son nouveau planning d’une version tout les 4 à 6 mois.
Outre les améliorations de performance et les nombreux bugs corrigés, la mise à jour embarque des nouveautés sur le support JavaScript, à la traîne par rapport au prédécesseur Tapestry 4.
Le rafraîchissement de plusieurs zones d’une page en une seule requête Ajax est maintenant supporté. Tapestry embarque maintenant la console JavaScript Blackbird.
Du côté des améliorations sur les templates, le chargement et le rendu des pages ont été optimisés, ce qui rend T5 plus rapide que jamais.
Vous pourrez aussi apprécier l’amélioration substantielle de l’archetype quickstart qui offre désormais une jolie interface, avec un design css intégré.
L’intégration de Spring est maintenant à double sens : on peut injecter des services Tapestry dans un Bean Spring.
Pour la prochaine version, qui sortira sans doute à la rentrée 2009, l’accent sera mis sur l’intégration de Spring Web Flow, et la possibilité d’utiliser une application Tapestry en tant que Portlet.

Trucs et astuces Json – Restfull

Edwin Khodabakchian, fondateur de Collaxa (aujourd’hui au coeur de la stratégie SOA d’Oracle), nous donne quelques bonnes pratiques pour écrire des services web REST en utilisant Json (un couple qui a le vent en poupe). Actuellement lancé dans l’écriture de Feedly, une extension Firefox qui agrège des tweets et des entrés Google Reader, Edwin fera régulièrement profiter ses lecteurs de son expérience. Sans entrer dans les détails de ces bonnes pratiques, nous retiendrons l’astucieux découpage en 7 phases d’implémentation :

Definir un service ou une ressource simple : définir le modèle Json et les 4 opérations REST et le servlet qui les fournit.
Ecrire un client : utiliser le service avec un javascript simple. Cette possibilité est offerte par de nombreux frameworks, dont JQuery.
Ajouter une étape de validation : modifier le service pour valider les ressources Json et utiliser les codes retour HTTP.
Complexifier les ressources : modifier la hiérarchie d’Url pour servir des ressources plus riches. Tester la pérennité des ressources simples (phase 2).
Ajouter un cache : améliorer les performances et la scalabilité de votre système.
Implémenter la sécurité : utiliser une authentification web.
Publier des événements business : pour découpler les processus REST des processus back-end. Les ressources REST sont traitées, un évènement business est lancé, qui déclenche le ou les traitements back-end.
Gérer un cycle de vie pour les ressources : coupler un état de la ressource avec la phase de validation et la phase de publication des évènements.

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

Soirée Datagrid au Paris Jug

Le DataGrid au Paris Jug, c’est demain.
Pensez à réserver si ce n’est déjà fait.

SOA : Du composant au service : L’autonomie

Christophe Heubès — Wed, 29 Apr 2009 07:00:13 +0000

Pour répondre plus précisément à la question, nous vous proposons de passer en revue les huit aspects qui caractérisent un service :

Contrat standardisé : L’ensemble des services d’un même Système Technique sont exposés au travers de contrats respectant les mêmes règles de standardisation.
Couplage lâche : Le contrat d’un service doit imposer un couplage lâche de ses clients.
Abstraction : Le contrat d’un service ne doit contenir que les informations essentielles à son invocation. Seules ces informations doivent être publiées.
Réutilisabilité : Un service exprime une logique agnostique et peut ainsi être positionné comme une ressource réutilisable.
Autonomie : Un service doit exercer un contrôle fort sur son environnement d’exécution sous-jacent. Plus ce contrôle est fort, plus l’exécution d’un service est prédictible.
Stateless (sans état) : Un service doit minimiser la consommation de ressources en déléguant la gestion des informations d’état quand cela est nécessaire.
Découvrabilité : Un service est complété par un ensemble de métas données de communication au travers desquelles il peut être découvert et interprété de façon effective.
Composabilité : Un service doit être conçu de façon à participer à des compositions de services.

Ces 8 aspects sont issus du livre « SOA Principles of Service Design » de Thomas Erl, également auteur du site SOA Principles.

Dans ce billet, nous nous attarderons sur la notion d’autonomie.

Comme nous l’avons vu dans le précédent billet de cette série : La réutilisabilité des services constitue une des pierres angulaires de la mise en œuvre d’une architecture orientée service. En effet, la mise en œuvre d’une SOA vise, entre autres, à éviter le gaspillage des ressources en éliminant les redondances inhérentes au modèle en silo. D’autre part, la réutilisation est une condition première de l’agilisation du SI indispensable à la réduction du time-to-market, principal élément de ROI des SOA.
Mettre l’emphase sur la réutilisabilité des services commence bien sûr par la fourniture de services proposant une logique réutilisable, mais cela implique également que l’implémentation de cette logique soit effectivement réutilisable une fois déployée. La confrontation au monde réel est souvent douloureuse.
En effet, le modèle SOA pousse à maximiser les possibilités de réutilisation des services produits. Les services identifiés comme réutilisables sont ainsi mis à disposition d’un large spectre de services composites, de processus, d’applications, … Au fil du temps, de tels services ont donc vocation à prendre part à un nombre croissant de compositions, d’orchestrations, de workflow, …
Dans cette optique de sollicitation massive, il est donc important de concevoir l’implémentation des services en prêtant tout particulièrement attention à la concurrence d’accès. Les accès concurrents à un service ne doivent en aucun cas modifier son comportement, sa fiabilité ou ses performances. En d’autres termes, un service doit respecter son contrat (et ses SLAs), quelque soit le volume de sollicitations auquel il est soumis : Un service doit être prédictible.

Afin de garantir cette prédictibilité dans le cadre d’accès concurrents, deux principes doivent être appliqués lors de l’élaboration des services :

Un service doit (au maximum) être autonome.
Un service doit être sans état.

Ces deux aspects sont fortement liés. En attendant le billet consacré à la notion de « statelessness des services », je vous invite à relire l’article Service Stateful vs. Service Stateless.

Afin que les services s’acquittent au mieux de leurs engagements (comportement, fiabilité, performances, …), ils doivent exercer un contrôle fort sur leur environnement d’exécution et sur les ressources qui sous-tendent leur implémentation. L’autonomie d’un service traduit la mesure du degré de contrôle qu’un service exerce sur son environnement. Plus un service à de contrôle sur son environnement (plus il est autonome), plus son comportement au runtime sera prévisible.
Lors de la décomposition des fonctions du SI en inventaire de services, il est souhaitable de définir les membres de ce registre comme des blocs indépendants. C’est donc un haut niveau d’autonomie individuelle des services qui est visé. Réduire l’accès partagé aux ressources d’un service et augmenter le niveau d’isolation physique des services sont deux leviers permettant d’augmenter cette capacité des services à fonctionner de façon autonome.

Tous les services d’un inventaire ne pourront évidement pas offrir un contrôle complet sur leur environnement. C’est pourquoi Thomas Erl propose de distinguer deux niveaux basiques d’autonomie :

L’autonomie de niveau service : Les frontières des services entrant dans cette catégorie sont clairement définies et les services sont indépendants les uns des autres, mais il se peut que ces services partagent encore certaines ressources sur lesquelles ils s’appuient. Par exemple, un service d’encapsulation d’un système legacy, même s’il régit ce système partage cette ressource avec ses autres clients.
L’autonomie pure : La logique sous-jacente au service et les ressources qu’il utilise sont la propriété du service et sous son contrôle exclusif. C’est le niveau d’autonomie que l’on pourra atteindre lors de la création de « nouveaux » services quand la logique sous-jacente est construite spécifiquement pour supporter le service.

La mise en œuvre d’une SOA se faisant, dans la grande majorité des cas, au sein d’un existant avec lequel il faut vivre pendant longtemps (la refonte de tout ou partie du SI en mode big-bang est trop coûteuse et trop risquée), un inventaire de services offrant exclusivement des services d’ un niveau d’autonomie pure reste un objectif difficilement atteignable. C’est pourtant cet objectif qu’il faut viser car un tel inventaire de service permet d’adresser nos préoccupations de monté en charge et de concurrence d’accès.

La mise en œuvre du principe d’autonomie est donc extrêmement importante car elle détermine dans quel mesure les autres principes peuvent être mis en application dans le monde réel (nos environnements de production) en favorisant la fiabilité et la prédictibilité des services.

Revue de Presse Xebia

Xebia France — Mon, 27 Apr 2009 16:09:31 +0000

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

Actualité éditeurs / SSII

La fondation Apache et JAX-RS

RIA

SOA

Vers l’émergence de Rule-driven process engines ?

Le coin de la technique

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

Actualité éditeurs / SSII

La fondation Apache et JAX-RS

Une proposal pour l’intégration d’un nouveau projet dans l’Incubator de la fondation Apache vient d’être publiée. Le projet, dont le nom suggéré est Apache Wink, est une implémentation de JAX-RS (JSR-311) dont le but est de simplifier l’implémentation de Web Services Restful. L’équipe est composée de développeurs provenant de HP et d’IBM. Quatre d’entre eux sont contributeurs au projet Axis2. Le code du projet est issu d’un fork de l’implémentation de JAX-RS du projet CXF.

La fondation Apache possède déjà une implémentation de JAX-RS au sein du projet CXF. Le projet Axis2, quant à lui, supporte Rest mais pas JAX-RS. Dans ce contexte, une discussion s’est engagée autour de la légitimité du projet. On retiendra deux interventions notables :

Daniel Kulp, du projet CXF, intervient assez sèchement, en regrettant que l’équipe du projet Wink n’ait pas cherché à consulter l’équipe CXF sur le sujet. Il souligne par ailleurs le fait que puisque le projet est annoncé comme d’ores et déjà compliant avec le TCK de JAX-RS, il aura probablement du mal à trouver de nouveaux commiteurs.
Greg Truty, fondateur du projet Wink et affilié IBM, explique qu’IBM utilise Axis2 en tant qu’implémentation JAX-WS et ne peut se permettre de tirer CXF en tant que dépendance pour leur implémentation JAX-RS car il leur faut une librairie indépendante.

L’approbation du projet reste incertaine, mais quel que soit le résultat final, le projet Apache Wink naîtra avec un manque certain de légitimité. Il n’aurait en effet comme seule justification que l’indépendance à CXF et devrait alors se démarquer face aux nombreuses autres implémentations de la JSR qui sont rapidement apparues et dont Jersey et RestEasy sont déjà de dignes représentants.

RIA

Comparatif de framework Ajax

Matt Raible a publié sur son blog les résultats d’un comparatif de frameworks Ajax. La liste des frameworks est assez restreinte : Ext JS, Dojo, YUI et GWT. On peut entre autres regretter l’absence du framework Javascript JQuery. Les résultats de l’analyse peuvent être étendus à d’autres frameworks car la méthode de comparaison est explicitement définie. Cette évaluation repose sur 20 critères : richesse des composants, qualité de la documentation, productivité de développement, etc.

Ce qui est le plus intéressant dans cette étude est la méthode, et la grille d’évaluation avec ses critères. Cette méthode peut aussi être étendue à différents contextes de développement d’applications Web.

On remarque que tous les frameworks reçoivent une bonne note, à l’exception de Ext JS.

Des conseils d’optimisations pour Flex et ActionScript 3

Suite à son article présentant les bonnes pratiques Flex, Sean Moore présente ici quelques conseils d’optimisation pour Flex et ActionScript 3.
Voici quelques conseils intéressants à retenir :

Les optimisations pour ActionScript 3 :

Au niveau des tableaux (Array) :

Eviter les new et préférer [] à la place.

Au niveau du code :

Utilisation de const pour les constantes,
Privilégier dans la condition du if l’évènement qui se produit le plus,
Utiliser des entiers dans les boucles for,
Privilégier la multiplication plutôt que la division.

L’auteur nous donne également quelques conseils sur les performances du code ; nous apprenons ainsi que :

il n’y a pas de différence de performance entre le if et le switch
la longueur du nom d’une méthode n’a pas d’incidence sur les performances

Les optimisations pour MXML

Eviter les repeaters sur des données scrollables
Eviter l’utilisation excessive voire inutile de conteneurs (tels que VBox), cela impacte les performances de l’application
Lors de l’utilisation de repeaters, mettre la propriété recycleChildren à true pour que les éléments enfants ne soient pas créés à nouveau s’ils existent déjà
Mettre la propriété creationPolicy à « queued » pour différer la création de conteneur dans le cas de multiples vues.

Bien que certaines informations puissent être applicables à tous les langages, certains points sont spécifiques au langage AS3/MXML, et peuvent rendre une application bien plus performante. Des informations bien utiles et à mettre en pratique sur tous projets Flex.

SOA

Vers l’émergence de Rule-driven process engines ?

Winston Dhanraj vient de terminer une série de deux articles (partie 1 et partie 2) portant sur la convergence des technologies de BPM, en apportant une observation du marché actuel, principalement focalisée sur la séparation entre processus et règles. Il y oppose deux camps :

La vision traditionnelle, représentée par les poids lourds du marché que sont IBM, Oracle, Microsoft et Tibco, qui se base sur un faible couplage entre le moteur de processus et le moteur de règles (éventuellement apporté par un éditeur tierce).
Une vision émergente, représentée par Pegasystems et sa solution SmartBPM Suite, qui préconise un moteur unifié de processus et règles (rule-driven process engine), rendant ainsi ces deux composants conscients l’un de l’autre.

Bien que reconnaissant sa plus grande complexité, l’auteur expose clairement son intérêt pour la seconde solution en mettant en avant ses atouts par rapport aux BPMs traditionnels :

La logique conditionnelle n’a plus à être intégrée au sein du processus (évitant ainsi de produire des processus surchargés) ni déléguée à un moteur de règles externe, forcément non conscient du contexte d’invocation
Les possibilités du moteur de règles peuvent être pleinement exploitées du fait de l’information contextuelle dont il dispose, évitant ainsi de le transformer en simple tableau de décision
La transition vers une nouvelle version d’un processus est simplifiée
Il n’est plus nécessaire de maintenir synchronisés les modèles métiers manipulés par le moteur de processus et de règles

Ce concept de moteur unifié n’était présent jusqu’alors que dans le monde commercial, grâce à l’offre de Pegasystems. Un produit Open Source s’apprête toutefois à changer la donne : JBoss Drools 5 est attendu en version finale dans les semaines à venir (une CR1 étant d’ores et déjà disponible). En effet, alors que Drools se limitait jusqu’alors à un moteur de règles, il évolue pour offrir maintenant un BPM unifié. On notera que la gestion de processus est apportée par un sous-projet nommé Drools Flow et non par jBPM ; Mark Proctor, JBoss Drools Lead, explique ce choix par des points de vue divergents entre les équipes des deux projets, l’équipe jBPM préférant ne pas s’engager sur cette nouvelle vision qu’elle juge trop complexe.

L’arrivée d’un acteur majeur supplémentaire comme JBoss permettra sans nul doute de donner un crédit supplémentaire à cette nouvelle vision du BPM. Toutefois seule une adoption de cette évolution par les poids lourds du marché permettra de la démocratiser.

Le coin de la technique

Sortie de TeamCity 4.5

The Server Side nous informe de la sortie de TeamCity, le serveur d’intégration continue de JetBrains, dans sa version 4.5

Pas de révolution dans cette version mais de nouvelles fonctionnalités font leur apparition (la liste complète est plus que respectable). Parmi les plus intéressantes, on note:

Une meilleure interface utilisateur,
Gestion de groupes d’utilisateurs,
Intégration LDAP,
Une meilleure intégration avec nos IDEs (Eclipse, Visual Studio et bien sûr IDEA),
Utilisation des résultats (format XML) de frameworks tels que JUnit, NUnit, Surefire, PMD ou FindBugs,
Support du framework MONO,
Assignation d’une responsabilité à un utilisateur,
Détection de crash JVM…

À noter qu’il est possible que votre agent par défaut soit écrasé comme ça a été le cas chez Developpez.com mais pas de panique au niveau des données (qui ont toutes été récupérées).

Une application à essayer d’urgence, rendez-vous est pris dans la section téléchargement !

Des nouvelles du projet Nebula

Nebula est un projet Eclipse à destination des développeurs Eclipse RCP. Son but est de fournir des composants SWT évolués.

En effet, les composants SWT fournis en standard font le travail mais restent de très bas niveau. Qui n’a jamais essayé de mettre une checkbox éditable dans une cellule de son tableau ? Il est bien sûr tout à fait possible de l’implémenter soi-même, mais l’idéal serait d’avoir un composant tiers qui gère nativement ce genre de fonctionnalités avancées (très appréciables !).

Actuellement tous en incubation, on trouve en téléchargement :

la galerie (seul composant étiqueté stable),
le tableau (édition de cellule, colonnes groupées, entêtes multiples…),
le panel avancé,
l’accordéon,
des animations (non officielles).

On note toutefois une communication sur de nouveaux composants, pas encore en téléchargement mais récupérables sur le CVS du projet (Web browser) :

Et, petite surprise, même si pour l’instant aucune communication n’a été faite, le ~~jira~~ bugzilla du projet semble indiquer l’arrivée possible d’autres composants tels que :

un ruban type office,
un éditeur de texte riche.

Nebula propose toujours son plugin eclipse d’exemples qui permet de faire un rapide tour d’horizon des composants.
Pour des exemples de code, ça se passe dans la section snippets.

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

SpringOne : Annonces de la première journée

Aujourd’hui se déroulait la première journée de SpringOne Europe à Amsterdam. La conférence a débuté par une keynote théâtrale menée par Rod Johnson en personne. Partant d’un point de départ plutôt piquant : « l’acquisition de Sun par Oracle ! » et d’une phrase quelque peu cinglante « Ce n’est pas avec Oracle que nous pouvons espérer les nouveautés du monde Java » (nous lui laissons la paternité de ce propos peu amène), Rod a annoncé les nouvelles directions stratégiques prises par SpringSource :

Phase 1, s’enfuir de Java EE !
Phase 2, améliorer la productivité des développeurs Java.

Différentes annonces ont donc été faites dans ce sens durant cette keynote :

Sortie de tcServer en GA : SpringSource espère toucher différents publics avec ce serveur : les utilisateurs de serveurs Java EE désirant migrer vers une solution plus simple et moins onéreuse, mais aussi les utilisateurs de Tomcat en recherche de console d’administration.
Sortie du futur nouveau produit ‘Spring ROO’ (vous pouvez voter pour son nom) que nous avions déjà évoqué à plusieurs reprises. Ce projet, décrit comme le Grails pour code Java, vise à augmenter la productivité des développements en proposant différents mécanismes de génération de code, et une intégration aux outils de développements (Maven2, Eclipse …).
SpringSource Tool Suite (STS) : Brique indispensable pour tirer la meilleur partie de Spring ROO, STS sera dorénavant diffusé gratuitement. Il contiendra, outre les plugins Spring, Mylyn et autres tutoriaux que nous connaissions déjà, une intégration directe avec la console Spring ROO.

Continuez à suivre Spring One Europe via twitter.

Java EE 6 n’aura plus de secret pour vous …

Antonio Goncalves vient de terminer l’écriture de son livre : Beginning Java EE 6 Platform with GlassFish 3: From Novice to Professional. Celui-ci est en cours de publication et devrait être disponible à la vente fin mai. Antonio, que vous connaissez probablement comme l’un des leaders du ParisJug, est également un membre du JCP et intervient sur les JSR-316 (Java EE 6), JSR-317 (JPA 2.0) et JSR-318 (EJB 3.1).

Félicitions pour ce nouvel ouvrage, nous avons hâte de le lire. Tu vas pouvoir souffler un peu avant Java EE 7 .

Pouvons-nous espérer une reprise de ton ancien livre ?