Dans cette partie je présenterai la keynote réalisée par Alexis Moussine-Pouchkine lors de l'ouverture des keynotes de la dernière journée du DEVOXX France 2013.

Voilà une semaine que les conférences DEVOXX France 2013 se sont déroulées, je vous propose de revenir sur les sessions auxquelles j'ai eu l'opportunité d'assister.

La première journée de conférences Devoxx 2013 à Paris s'est ouverte sur une présentation de Neo4j par Florent Biville, une base de donnée orientée Graphes. A l'issue de cette conférence il me semble intéressant de retranscrire les principales fonctionnalités de ce puissant outil.

JAVA 8 (version SE 8 en Sept 2013, EE 8 en 2015)  arrive avec son lots de nouvelles fonctionnalités et notamment les expressions Lambda susceptibles de révolutionner notre façon de coder mais aussi d'anticiper nos développements. Un bémol néanmoins: JAVA à la sauce Lambda devient un langage ouvert à l'orientation vers les fonctions et moins regardant quant au caractère "fortement typé" qui défini ce langage. Je vous propose de décrypter une partie des fonctionnalités des expressions Lambda afin de vous faire une première idée.

Le recours à l'emploi de caches dans nos projets permet d'améliorer significativement les performances.

Dans ce billet contrairement à celui-ci nous ne codons rien dans la partie métier pour éviter le couplage.

Spring sait rendre les choses simples plus simples et les choses complexes possibles.

Un cache sert à optimiser les accès aux données néanmoins ce n'est la solution miracle à tous les problèmes de performances.

Mais une fois mis en œuvre à bon escient, on se demande comment peut-on s'en passer.

Donc depuis Spring 3.1, implémenter une gestion de cache devient possible sans trop écrire du code.

La démo ci-après, sans aborder les détails d'implémentation de la couche DAO, présente un exemple concret de mise en (EH)cache.

Sachez néanmoins que les illustrations données reposent sur une implémentation basée sur spring-data.

Spring offre une implémentation light de mise en cache qui ne peut satisfaire les besoins de nos projets.

C'est pour cette raison qu'ici nous utilisons Ehcache.

L'annotation @Cacheable de Spring apposée sur les méthodes (finder par exemple) suffit.

L'AOP Spring rend la gestion du cache facile à l'instar des transactions déclaratives.

Ce billet illustre l'emploi du composant Camel-SQL.

Dans notre démo le composant camel-sql s'appuie sur une datasource déclarée dans spring.

La démo est réalisée en cinq étapes:

I. CONFIGURER LE POM DU PROJET

II. CONFIGURER SPRING

III. DESSINER LA ROUTE CAMEL

IV. CONFIGURER L'ENVIRONNEMENT

V. TESTER

Passons à la pratique.

MISE EN PLACE D'UN WEB-SERVICE DE TYPE RESTFUL AVEC RESTEASY

1- Resteasy: C'est une implémentation de la spécification JAX-RS. JAX-RS fournit une API Java pour développer des WebService RestFul par-dessus le protocole HTTP.

Ce billet s'inscrit dans la catégorie optimisation des performances.

Il se fixe comme objectif d'illustrer avec démo détaillée comment améliorer significativement les performances de nos projets.

Et cela sans se lancer dans l'aventure d'écrire des kilomètres de code lourd de gestion du 'parallel processing' car nous allons laisser la puissance du framework Camel opérer.

Sachez néanmoins que de nombreux problèmes de mauvaise performance peuvent être traités sans recours aux implémentations complexes de parallélisme.

Voici deux situations où il faudrait réfléchir sur l'apport du parallélisme :

- Si les tâches ou opérations ne prennent que très peu de temps (échelle quelque sec). La gestion/monitoring des threads devient coûteux.

- Si les ressources mémoire, CPU et IO sont déjà fortement utilisées; sachez que le parallélisme consomme davantage de ressources.

Le billet veut s'inspirer (librement) des deux étapes décrites dans la démo du chapitre 10 du livre "Camel in action".

L'essentiel du code source est fourni ici.

Sachez néanmoins que le code présenté ci-après a été largement adapté et pour certaines parties complètement réécrits.

En effet, comme j'utilise Spring, toutes les parties de code sont adaptées ou réécrites en fonction.

En particulier j'utilise l'implémentation spring ThreadPoolTaskExecutor de l'interface TaskExecutor à la place de la méthode statique de Executors de java.

Le billet est organisée en deux parties:

- La première partie permet d'exécuter en séquentiel notre démo,

- La seconde permet adapte la première partie pour une exécution parallèle.

Nous donnons quelques indications sur le temps d'exécution de chacune des parties.

Avec les bons paramètres nous pouvons diviser par quatre le temps d'exécution voire plus.

Le framework Camel offre avec son java DSL des fonctions permettant d'obtenir simplement de meilleurs performances en parallélisant les tâches.

Comme d'habitude nous le combinons avec le framework Spring v3+ car peut-on faire autrement?

Dans le domaine de performance, il est utile d'identifier les deux limites: CPU-bound et IO-bound.

Distinguer ces deux limites permet d'identifier le bon choix pour améliorer les performances.

En guise de conclusion, dans le domaine d'exécution parallèle, Camel simplifie grandement la vie des développeurs.

Néanmoins, il leur reste la responsabilité de la cohésion des données.

Passons à la mise en pratique.

Ce billet tente de démystifier l'utilisation en java5+ des exécutions en parallèle des tâches (parallel processing) en s'appuyant sur les classes de Spring qui masquent les difficultés du parallélisme en java.

Les machines de nos jours viennent avec plusieurs processeurs: des multi-core (quatre, huit ou plusieurs centaines cœurs).

Or la puissance de ces ressources n'est pas constamment utilisée.

L'exécution parallèle autorise des calculs parallèles qui consomment ces ressources pour améliorer les performances.

Mais c’est comme tout, le parallélisme ça se mérite. Même si c'est un petit chouia difficile!

En réalité, la difficulté n'est pas dans la mise en place technique mais réside dans la gestion de la cohésion des données.

Techniquement, c'est le développeur qui doit réaliser les calculs parallèles.

C'est sûr, demain apparaîtront côté JVM les méthodes de traitement du parallélisme comme c'était le cas de la gestion mémoire avec le garbage collector ou récemment la gestion des descripteurs de fichier avec try/catch en java7.

Java 8+ nous proposera (peut-être) de faire le calcul paralléle à notre place (nous développeurs).

Ce qui reste au développeur c'est de décrire les traitements atomiques (comme l'atomicité dans les transactions), et à partir de là c'est la JVM qui mène le traitement global parallélisé efficacement en fonction des ressources disponibles.

Bel enjeu de demain.

Signalons que nous n'utilisons pas directement la classe Executors de java qui offre des méthodes statiques pour instancier un Executor ou un ExecutorService.

A la place nous utiliserons les classes de Spring.

La démo ci-après est faite en java7 et spring 3.

Passons à la mise en pratique.

On s'intéresse ici au composant 'camel-bindy' qui permet de transformer des données non structurées (csv par exemple) en objets java et inversement.

La démo est réalisée en quatre actes: configurer le pom du projet, dessiner et déclarer la route, annoter le bean du model et enfin tester.

la v2.10.2 de camel-bindy est utilisée.

Voici les détails de la démo.