Netapsys Blog

Le cache de Guava- Partie 2

Abderrazek CHINE — Fri, 31 May 2013 18:05:00 +0200

Nous poursuivons ici ce billet. La démo 2 est présentée avec détails.

Dans cesdémos, nous donnons deux façons pratiques afin de mieux gérer le cache de Guava.

La première s'appuie les interfaces LoadingCache et CacheLoader

La seconde fait appel à l'interface Callable.

Nous partons du projet de la première partie de ce billet.

Nous allons le compléter et l'adapter au fur et à mesure pour construire les démos.

Passons à la mise en pratique.

DEMO2. Utilisation des interfaces LoadingCache et CacheLoader

1.A) Modification de l'interface DestinationCacheManager

Désormais la seule méthode utile est la méthode get.

public interface DestinationCacheManager {
	 Destination get(String key) throws ExecutionException ;
}

Notez que la méthode get lève une exception.

Aussi que la méthode put n'est plus utile.

1.B) L'implémentation de cette interface est nommée DestinationCacheManagerImpl:

package fr.netapsys.gestioncacheguava.services;
import java.util.concurrent.*;
import javax.annotation.PostConstruct;
import org.springframework.stereotype.Component;
import com.google.common.cache.*;
import fr.netapsys.gestioncacheguava.model.Destination;
@Component
public class DestinationCacheManagerImpl 
      implements DestinationCacheManager{
 private LoadingCache<String,Destination> cache;
 @PostConstruct
 public void init(){
	cache = CacheBuilder.newBuilder().
 	  maximumSize(10).
	  expireAfterWrite(1, TimeUnit.MINUTES).  
	  build( 
      	    new CacheLoader<String, Destination>() {
	    @Override
	     public Destination load(String key) throws Exception {
	      return getFavoriteDestination(key);//simule appel service 
	     }
	   }
	 );
	}
	public Destination get(String key) throws ExecutionException {
	  return cache.get(key);
	}
   //Simule l'appel an service qui genere la destination favorite 
    private Destination getFavoriteDestination(String key) {
	Destination destDispo=new Destination();
	destDispo.setLibelle("destFavorite");
	destDispo.setVille("PARIS");
	destDispo.setPays("FRANCE");
	destDispo.setCritere("C"+key);
	return destDispo;
   }
}

Explications:

Quelques modifications majeures sont à observer:

Le cache est de type LoadingCache. Et on utilise la méthode V get(K,V) throws ExecutionException,
Nous passons à la méthode build du CacheBuilder un objet anonyme de type CacheLoader.

Ceci permet donc d'appeler un service pour initialiser les éléments du cache.

1.C) Test unitaire

Voici le code du test unitaire :

package fr.netapsys.testscache;
import java.util.concurrent.ExecutionException;
import org.junit.*;
import org.springframework.beans.factory.annotation.Autowired;
import fr.netapsys.gestioncacheguava.model.Destination;
import fr.netapsys.gestioncacheguava.services.DestinationCacheManager;
public class TestDestinationCache extends TestParent {
  @Autowired DestinationCacheManager dcm;
  @Test
  public void testCacheLoader() throws ExecutionException  {
	// get from cache
 	Destination d=dcm.get("destFavorite");
 	Assert.assertNotNull(d);
	Assert.assertEquals(d.getLibelle(),"destFavorite"  );	
  }

@Test
	public void test2() throws ExecutionException  {
		// get from cache
		Destination d1=dcm.get("destSuper");
		Assert.assertNotNull(d1);
		Assert.assertEquals(d1.getCritere(),"CdestSuper"  );
	}
}

C'est simple non? Le (Laoding)Cache est initialisé via la méthode init annotée avec @PostConstruct qui appelle la méthode statique build en lui passant comme argument une instance de CacheLoader. Le test unitaire définit une instance DestinationCacheManager nommée dcm et injectée par Spring. Les deux méthode du test montrent que cette instance permet, via la méthode get, de récupérer du cache la destination ayant la bonne clé.

DEMO3. Utilisation de l'interface Callable

La prochaine partie détaille la démo3 basée sur les Callable.

Le cache de Guava

Abderrazek CHINE — Mon, 27 May 2013 19:45:00 +0200

L'objet ici est de présenter avec trois démos détaillées la prise en main d'un gestionnaire de cache de l'API utilitaire Guava fournie par google.

Cet article peut être rapproché de mon billet qui traitait Ehcache.

Chacune des démos est illustrée par un test unitaire.

Les sources de la démo1 sont fournies.

Passons à la mise en pratique.

DEMO 1.

Dans cette première démo, nous présentons un exemple simple permettant de prendre en main le gestionnaire de cache de Guava.

Etape1: Dépendances maven nécessaires

Dans le pom du projet, en plus des dépendances spring deux autres sont nécessaires.

La dépendance JSR-250 pour l'annotation @PostConstruct et celle de Guava.

Donc, le pom.xml doit avoir ces lignes :

      <!-- jsr 250 -->
      <dependency>
	<groupId>javax.annotation</groupId>
	<artifactId>jsr250-api</artifactId>
	<version>1.0</version>
     </dependency>
     <!-- guava -->
    <dependency>
	<groupId>com.google.guava</groupId>
	<artifactId>guava</artifactId>
	<version>12.0</version>
  </dependency>

Etape2: Les classes java de la démo

Il y a essentiellement deux classes java dans cette première démo:

La première est un objet POJO de la couche model.
La seconde est l'implémentation du service du cache.

La première classe est nommée Destination :

public class Destination {
 private String libelle;
 private String ville;
 private String pays;
 private String critere;
    //..getters setters omis

}

La seconde classe nommée DestinationCacheManager est celle qui nous intéresse ici.

Elle permet de définir les opérations liées à la gestion du cache.
Ces opérations sont résumées dans l'interface suivant:

public interface DestinationCacheManager {
 void remove(String key) ;
 void put(String key,Destination d);
 Destination get(String key) ;
}

Voici une implémentation de cette interface :

package fr.netapsys.gestioncacheguava.services;
import java.util.concurrent.*;
import javax.annotation.PostConstruct;
import org.springframework.stereotype.Component;
import com.google.common.cache.*;
import fr.netapsys.gestioncacheguava.model.Destination;
@Component
public class DestinationCacheManagerImpl 
                  implements DestinationCacheManager{

	private Cache<String,Destination> cache;
	
	@PostConstruct
	public void init(){
	  cache = CacheBuilder.newBuilder().
			maximumSize(10).
			expireAfterWrite(1, TimeUnit.MINUTES).  
			/* expire 1 min apres ecriture (ttl)*/
			build();
	}
	
	public Destination get(String key) {
		return cache.getIfPresent(key);
	}
	public void remove(String key) {
		cache.invalidate(key);
	}
	public void put(String key,Destination d){
		cache.put(key, d);
	}
}

L'annotation @Component permet à Spring de gérer ce bean.

L'annotation @PostConstruct de la jsr-250 permet d'initialiser, post création, le bean via la méthode annotée.

Notez que l'implémentation de la méthode get s'appuie sur getIfPresent du CacheBuilder.

Celle-ci retourne null si l'objet n'est pas dans le cache sans lever d'exception.

Etape3: Configuration Spring

Notre démo s'appuie sur le framework Spring, voici son fichier de configuration qui contient une seule ligne.

Le fichier est nommé spring-context.xml et localisé dans src/main/resources/META-INF.

?xml version="1.0" encoding="UTF-8"?>
<beans 
    xmlns="http://www.springframework.org/schema/beans" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:context="http://www.springframework.org/schema/context" 
    xmlns:p="http://www.springframework.org/schema/p"
    xsi:schemaLocation="
  http://www.springframework.org/schema/beans 
  http://www.springframework.org/schema/beans/spring-beans.xsd
  http://www.springframework.org/schema/context 
  http://www.springframework.org/schema/context/spring-context.xsd">
 <context:component-scan base-package="fr.netapsys"/>
</beans>

La seule chose à remarquer est la ligne context:component qui indique le package de base dans lequel Spring doit chercher les beans utiles.

Etape4: Test unitaire

Nous générons une classe JUnit pour tester notre cache.

Voici le code de cette classe:

import org.junit.Assert;
import org.junit.Test;
import org.springframework.beans.factory.annotation.Autowired;

import fr.netapsys.gestioncacheguava.model.Destination;
import fr.netapsys.gestioncacheguava.services.DestinationCacheManager;
import org.junit.runner.RunWith;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations=
     {"classpath*:META-INF/spring-context.xml"})
public class TestDestinationCache {
	@Autowired DestinationCacheManager dcm;
	@Test
	public void testSimple()  {
		Destination destFav=getDestDispo();
               ///mis en cache 
		dcm.put( "destFavorite", destFav);
		
		//first get from cache
		Destination d1=dcm.get("destFavorite");
		Assert.assertSame(d1, destFav);
				
		//another get from cache
		Destination d2=dcm.get("destFavorite");
		Assert.assertSame(d2, destFav);	
	}
	private Destination getDestDispo() {
	 Destination destDispo=new Destination();
	 destDispo.setLibelle("destinFavorite");
	 destDispo.setVille("Paris");
	 destDispo.setPays("France");
	 destDispo.setCritere("C1");
	 return destDispo;
     }
}

Quelques explications sont utiles:

l'annotation @RunWith permet de lancer le test JUnit via le lanceur de Spring.
l'annotation @ContextConfiguration précise le fichier de configuration de Spring mentionné à l'étape précédente.
l'annotation @Autowired permet d'injecter le bean implémentant l'interface DestinationCacheManager.

La méthode testSimple() construit une instance du POJO Destination et le met en cache.

Les appels successifs à la méthode get permettent de voir que, comme le prouve les assertions, l'objet est récupéré correctement du cache.

Pour conclure, la façon de créer et gérer le cache dans la démo1 n'est pas idéale.

Nous verrons dans la seconde démo comment mieux le gérer.

Enfin, le projet démo1 peut-être téléchargé ici.

DEMO 2.

Dans cette partie nous indiquons une autre façon (avancée) d'en tirer profit du gestionnaire de cache de Guava.

Partie 1. Utilisation du CacheLoader/LoadingCache

Partie 2. Utilisation du Callable

Nous nous basons sur les sources du projet de la démo1 que nous allons enrichir au fur et à mesure.

C'est ce que nous ferons dans la seconde partie de ce billet.

Améliorez les performances avec Spring-Ehcache: Cache & @Cacheable

Abderrazek CHINE — Thu, 28 Feb 2013 18:32:00 +0100

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.

Ehcache est une solution de cache Open Source.

La solution Ehcache peut être utilisée en JEE comme en JSE.

Hibernate utilise Ehcache.

Passons à la mise en place de notre démo qui est un projet maven simple.

Commençons par créer un projet maven à partir d'une template quickstart.

Ensuite suivre les étapes suivantes.

ETAPE 1. Ajouter les dépendances du pom

Pour la mise en place de ehcache, ajouter ces lignes dans le fichier pom.xml:

<dependency>
  <groupId>org.hibernate</groupId>
  <artifactId>hibernate-ehcache</artifactId>
  <version>4.1.7</version>
  <scope>compile</scope>					
</dependency>

ETAPE 2. Configurer Spring

Le fichier de configuration de spring doit être configuré en ajoutant ces lignes où les noms sont explicités.

<!-- ehcache -->
 <!-- ehcache -->
   <cache:annotation-driven cache-manager="ehcacheManager"/>
   <bean id="ehcacheManager"
     class="o.s.cache.ehcache.EhCacheCacheManager"
     p:cacheManager-ref="ehcacheMFB"/>

     <bean id="ehcacheMFB" 
      class="o.s.cache.ehcache.EhCacheManagerFactoryBean"
     p:configLocation="ehcache.xml"
     p:cacheManagerName="ehcacheManager"
     p:shared="true"/>

NOTES.

Ici nous avons mis de côté le principe convention over configuration pour mieux détailler la configuration.

L'abréviation o.s désigne org.springframework.

Dans le bean ehcacheMFB nous faisons référence à ehcache.xml qui sera détaillé ci-après.

ETAPE 3. Configurer Ehcache

La configuration de ehcache est centrée dans le fichier ehcache.xml déjà mentionné dans la configuration de spring.

<?xml version="1.0" encoding="UTF-8"?>
<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
 xsi:noNamespaceSchemaLocation="http://ehcache.org/ehcache.xsd">
 <defaultCache eternal="false" maxElementsInMemory="100" 
    overflowToDisk="false" />
 <cache name="cacheLivs"
  maxElementsInMemory="10000" eternal="false" 
  timeToIdleSeconds="300"
  timeToLiveSeconds="600"
  overflowToDisk="false" />
</ehcache>

ETAPE 4. Ecrire la classe du model (entité)

La classe Livraison est l'unique classe entité du model.

package fr.netapsys.springehcache.model.common;

import java.util.Date;
import javax.persistence.*;

@Entity
public class Livraison  {
	@Id @GeneratedValue(strategy = GenerationType.AUTO)
	private Long id;
	private String libelle;
	private String quadriRegion;
	
	@Temporal(TemporalType.DATE)
	private Date dateLivraison;
	@Temporal(TemporalType.DATE)
	private Date dateDernInteg;
	@Temporal(TemporalType.DATE)
	
      /*omis ge(se)tters et toString*/

Vous remarquez l'absence d'annotations @Cache sur l'entité car nous ne souhaitons pas utiliser le cache de second niveau d'Hibernate.

ETAPE 5. Ecrire l'interface du service

Voici l'interface de la classe nommée ILivraisonService qui comporte des méthodes de recherche (finder).

Ces méthodes sont annotées avec l'annotation de spring @Cacheable en indiquant comme attribut le nom du cache fourni à l'étape 3.

public interface ILivraisonService {
	
	@Cacheable(value="livraisons")
	Livraison findOne(long id);
	
	@Cacheable(value="livraisons")
	List<Livraison> findAll();
	
	Livraison save(Livraison liv);
}

Seules les deux méthodes findOne et findAll sont annotées avec @Cacheable en indiquant le nom du cache configuré dans ehcache.xml.

ETAPE 6. Ecrire l'implémentation du service

Ici aucun détail d'implémentation n'est abordée pour la couche DAO.

La classe de service s’appuiera sur l'interface DAO.

Le code de la classe LivraisonService est simple:

package fr.netapsys.springehcache.service;

import java.util.List;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;
import fr.netapsys.springehcache.model.common.Livraison;
import fr.netapsys.springehcache.repository.ILivraisonRepository;

@Service
public class LivraisonService implements ILivraisonService {

 @Autowired private ILivraisonRepository livRepo;

 /**** Methodes Finder *****/
 @Override
 public List<Livraison> findAll() {
 	return livRepo.findAll();
 }
 @Override
 public Livraison findOne(long id) {
	return livRepo.findOne(id);
 }
/**** Methodes de MAJ *****/

 @Override
 public Livraison save(Livraison liv) {
 	return livRepo.save(liv);
 }	
 @Override
 public void delete(Livraison liv) {
	livRepo.delete(liv);
 }	
}

Notez que l'interface ILivraisonRepository n'apporte rien à notre démo.

Pour les curieux, mon billet sur Spring-Data donne les détails sur cette implémentation utilisant Spring-DATA (voir Partie1 et partie2).

ETAPE 7. Désactiver le cache de second niveau Hibernate (Optionnelle)

Si vous utilisez l'implémentation Hibernate pour votre couche DAO, il serait utile lors la définition du bean entityManagerFactory de mettre la propriété suivante à false:

<prop key="hibernate.cache.use_second_level_cache">false</prop>

ETAPE 8. Tester

Voici le code du test JUnit :

package fr.netapsys.springehcache.tests;
import static junit.framework.Assert.assertSame;
import static junit.framework.Assert.assertTrue;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
import fr.netapsys.springehcache.model.common.Livraison;
import fr.netapsys.springehcache.service.ILivraisonService;

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations=
     {"classpath*:config/applicationContext.xml" })
public class CacheableLivraisonTest
{
    @Autowired ILivraisonService livService;
    
  @Test public void testFindOne(){
	/*** fixer la valeur de l'id en fonction de la BD**/
	final int id=89;
	Livraison liv1=livService.findOne(id);
	/** assret suivante depend du contenu de la BD***/
	assertTrue(liv1.getLibelle().contains("pdl"));
	
	Livraison liv2=livService.findOne(id);
	
	assertSame(liv1,liv2);
	
	liv2=livService.findOne(id);
	
	assertSame(liv1,liv2);
 }
}

Il ne reste qu'à lancer la commande mvn test.

Vous constatez alors que le second appel à findOne ne génère pas un appel à la base de données.

L'assertion assertSame met en évidence que c'est la même instance récupérée du cache.

Avec mon implémentation de la couche DAO basée sur spring-data (JPA), j'obtiens les traces suivantes en ayant au préalable configuré log4j:

DEBUG (AbstractFallbackCacheOperationSource.java:105) 
   Adding cacheable method 'findOne' with attribute:
 [CacheableOperation[public abstract 
   fr.netapsys.springehcache.model.common.Livraison 
  fr.netapsys.springehcache.service.ILivraisonService.findOne(long)]
  caches=[cacheLivs] | condition='' | key='']
INFO  (EhCacheManagerFactoryBean.java:100) 
  Initializing EHCache CacheManager
Hibernate: 
  /* load fr.netapsys.springehcache.model.common.Livraison */ 
 select
      livraison0_.id as id0_0_,
        livraison0_.dateData as dateData0_0_,
        livraison0_.dateDernInteg as dateDern3_0_0_,
        livraison0_.dateFichierEns as dateFich4_0_0_,
        livraison0_.dateFichierInt as dateFich5_0_0_,
        livraison0_.dateLivraison as dateLivr6_0_0_,
        livraison0_.dateLivraisonSoc as dateLivr7_0_0_,
        livraison0_.libelle as libelle0_0_,
        livraison0_.quadriRegion as quadriRe9_0_0_ 
    from
        public.Livraison livraison0_ 
    where
        livraison0_.id=?
TRACE (BasicBinder.java:83) binding parameter [1] as [BIGINT] - 89

TRACE (BasicExtractor.java:72) 
   Found [2013-02-22] as column [dateData0_0_]
....
TRACE (BasicExtractor.java:72) 
     Found [PDL] as column [quadriRe9_0_0_]
..
TRACE (CacheAspectSupport.java:294) Computed cache key 89 
  for operation CacheableOperation
 [public abstract fr.netapsys.springehcache.model.common.Livraison 
  fr.netapsys.springehcache.service.ILivraisonService.findOne(long)] 
  caches=[cacheLivs] | condition='' | key=''
TRACE (CacheAspectSupport.java:294) Computed cache key 89 for 
 operation CacheableOperation
 [public abstract fr.netapsys.springehcache.model.common.Livraison 
 fr.netapsys.springehcache.service.ILivraisonService.findOne(long)] 
  caches=[cacheLivs] | condition='' | key=''
INFO  (EhCacheManagerFactoryBean.java:133) 
     Shutting down EHCache CacheManager

Les traces sont bien parlantes surtout à la fin.

Vous pouvez voir que le premier appel de findOne a généré une requête select * from Livraison where id=?

Mais le second appel à findOne se contente de chercher le résultat depuis le cache cacheLivs.

Concluons:

Il suffit d'ajouter les dépendances maven, d'annoter les méthodes concernées, de configurer le cacheManager(Factory) d'Ehcache et de laisser l'AOP Spring opérer.

Le réglage du cacheManager(Factory) est d'important pour garantir la cohésion des données mais ceci est un autre sujet.

@Enjoy

Camel SQL composant: Composant Camel-SQL

Abderrazek CHINE — Thu, 14 Feb 2013 18:53:00 +0100

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.

Voici les étapes de la démo qui utilise java 7, spring 3, camel 2.10:

ETAPE 1. CONFIGURER LE POM

Pour utiliser le composant camel-sql on a besoin uniquement de cette déclaration:

<dependency>
 <groupId>org.apache.camel</groupId>
 <artifactId>camel-sql</artifactId>
 <version>2.10.2</version>
</dependency>

Voici le pom.xml en entier:

<properties>
	<!-- Versions Dependances -->
	<commons-beanutils-version>1.8.3</commons-beanutils-version>
	<commons-codec-version>1.6</commons-codec-version>
	<commons-collections-version>3.2.1</commons-collections-version>
	<commons-lang-version>2.6</commons-lang-version>
	<commons-digester-version>2.1</commons-digester-version>
	<javassist-version>3.12.1.GA</javassist-version>
	<cglib-version>2.2.2</cglib-version>

	<!-- Log -->
	<log4j-version>1.2.17</log4j-version>
	<slf4j-version>1.6.6</slf4j-version>

	<!-- Spring -->
	<spring-version>3.1.2.RELEASE</spring-version>
	<!-- camel-version -->
	<camel-version>2.10.2</camel-version>
	<!-- Versions Dependances de test -->
	<junit-version>4.10</junit-version>

	<!-- PostgresSql -->
	<postgresql-version>9.1-901-1.jdbc4</postgresql-version>

</properties>

<dependencies>

	<dependency>
		<groupId>commons-dbcp</groupId>
		<artifactId>commons-dbcp</artifactId>
		<version>1.2.2</version>
	</dependency>
	<dependency>
		<groupId>commons-pool</groupId>
		<artifactId>commons-pool</artifactId>
		<version>1.2</version>
	</dependency>

	<!-- dep transitive de JavConfig see @Configuration -->
	<dependency>
		<groupId>javassist</groupId>
		<artifactId>javassist</artifactId>
		<version>${javassist-version}</version>
		<scope>compile</scope>
	</dependency>
	<dependency>
		<groupId>cglib</groupId>
		<artifactId>cglib</artifactId>
		<version>${cglib-version}</version>
		<scope>compile</scope>
	</dependency>

	<!-- spring-core -->
	<dependency>
		<groupId>org.springframework</groupId>
		<artifactId>spring-core</artifactId>
		<version>${spring-version}</version>
		<scope>compile</scope>
	</dependency>
	
	<!-- spring-expression -->
	<dependency>
		<groupId>org.springframework</groupId>
		<artifactId>spring-expression</artifactId>
		<version>${spring-version}</version>
		<scope>compile</scope>
	</dependency>
	<!-- spring-asm -->
	<dependency>
		<groupId>org.springframework</groupId>
		<artifactId>spring-asm</artifactId>
		<version>${spring-version}</version>
		<scope>compile</scope>
	</dependency>
	<!-- spring-beans -->
	<dependency>
		<groupId>org.springframework</groupId>
		<artifactId>spring-beans</artifactId>
		<version>${spring-version}</version>
		<scope>compile</scope>
	</dependency>
	<!-- spring-context -->
	<dependency>
		<groupId>org.springframework</groupId>
		<artifactId>spring-context</artifactId>
		<version>${spring-version}</version>
		<scope>compile</scope>
	</dependency>
	<!-- spring-context-support -->
	<dependency>
		<groupId>org.springframework</groupId>
		<artifactId>spring-context-support</artifactId>
		<version>${spring-version}</version>
		<scope>compile</scope>
	</dependency>
	<!-- postgres -->
	<dependency>
		<groupId>postgresql</groupId>
		<artifactId>postgresql</artifactId>
		<version>${postgresql-version}</version>
		<scope>compile</scope>
	</dependency>
	<!-- CAMel -->
	<dependency>
		<groupId>org.apache.camel</groupId>
		<artifactId>camel-core</artifactId>
		<version>${camel-version}</version>
	</dependency>
	<!--    camel-sql -->		
	<dependency>
		<groupId>org.apache.camel</groupId>
		<artifactId>camel-sql</artifactId>
		<version>${camel-version}</version>
	</dependency>
	<dependency>
		<groupId>org.apache.camel</groupId>
		<artifactId>camel-spring</artifactId>
		<version>${camel-version}</version>
	</dependency>
	<!-- camel-spring-config -->
	<dependency>
		<groupId>org.apache.camel</groupId>
		<artifactId>camel-spring-javaconfig</artifactId>
		<version>${camel-version}</version>
	</dependency>
	<!-- logging -->
	<dependency>
		<groupId>org.slf4j</groupId>
		<artifactId>slf4j-api</artifactId>
		<version>1.6.6</version>
	</dependency>
	<dependency>
		<groupId>org.slf4j</groupId>
		<artifactId>slf4j-log4j12</artifactId>
		<version>1.6.6</version>
	</dependency>
	<dependency>
		<groupId>log4j</groupId>
		<artifactId>log4j</artifactId>
		<version>1.2.17</version>
	</dependency>
	<!-- logging -->
	<dependency>
		<groupId>commons-logging</groupId>
		<artifactId>commons-logging</artifactId>
		<version>1.1</version>
		<scope>runtime</scope>
	</dependency>
	<!-- CAMEL -test-spring  -->
	<dependency>
		<groupId>org.apache.camel</groupId>
		<artifactId>camel-test-spring</artifactId>
		<version>${camel-version}</version>
		<scope>test</scope>
	</dependency>
	<!-- spring-test -->
	<dependency>
		<groupId>org.springframework</groupId>
		<artifactId>spring-test</artifactId>
		<version>3.1.2.RELEASE</version>
		<scope>test</scope>
	</dependency>
	<!-- DEPENDANCES DE TESTS junit -->
	<dependency>
		<groupId>junit</groupId>
		<artifactId>junit</artifactId>
		<version>${junit-version}</version>
		<scope>test</scope>
	</dependency>
 <!-- commons beanutils -->
 <dependency>
	<groupId>commons-beanutils</groupId>
	<artifactId>commons-beanutils</artifactId>
	<version>${commons-beanutils-version}</version>
 </dependency>
	<!-- commons codec -->
	<dependency>
		<groupId>commons-codec</groupId>
		<artifactId>commons-codec</artifactId>
		<version>${commons-codec-version}</version>
		<scope>compile</scope>
	</dependency>
	<!-- -->
	<dependency>
		<groupId>commons-collections</groupId>
		<artifactId>commons-collections</artifactId>
		<version>${commons-collections-version}</version>
		<scope>compile</scope>
	</dependency>
	<dependency>
		<groupId>commons-lang</groupId>
		<artifactId>commons-lang</artifactId>
		<version>${commons-lang-version}</version>
		<scope>compile</scope>
	</dependency>
	<!-- common DIGESTER -->
	<dependency>
	 <groupId>commons-digester</groupId>
	 <artifactId>commons-digester</artifactId>
	 <version>${commons-digester-version}</version>
	</dependency>
</dependencies>
<build>
 <defaultGoal>install</defaultGoal>
 <plugins>
  <plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-compiler-plugin</artifactId>
  <version>2.5.1</version>
  <configuration>
 	<source>1.7</source>
	<target>1.7</target>
  </configuration>
</plugin>
<!-- allows the route to be ran via 'mvn camel:run' -->
<plugin>
	<groupId>org.apache.camel</groupId>
	<artifactId>camel-maven-plugin</artifactId>
	<version>${camel-version}</version>
</plugin>
</plugins>
</build>
</project>

ETAPE 2. CONFIGURER SPRING

La configuration de spring est centrée dans le fichier xml suivant:


<context:property-placeholder location="db.properties"/>
<context:component-scan base-package="fr.netapsys.camel"/>
<camel:camelContext id="camel1"
	xmlns="http://camel.apache.org/schema/spring">
	<camel:package>fr.netapsys.camel.routes</camel:package> 
</camel:camelContext>

<bean id="myDataSource" class="org.apache.commons.dbcp.BasicDataSource" 
     destroy-method="close">
    <property name="driverClassName" value="${bd.driverClassName}"/>
    <property name="url" value="${bd.url}"/>
    <property name="username" value="${bd.username}"/>
    <property name="password" value="${bd.password}"/>
    <property name="defaultAutoCommit" value="true" />
</bean>

Explications:

Un fichier (placeholder pour spring) contient les paramètres (propriétés) de définition de la datasource nommée myDataSource.

Les routes camel sont auto-injectées en les scannant dans le répertoire de <camel:package>.

Les autres composants à injecter par spring sont scannés depuis le <context:component-scan base-package.

Le fichier db.properties est donné à l'étape 4.

ETAPE 3. DESSINER LA ROURE CAMEL-SQL

La route camel permettant de rechercher ( et d'insérer) des données depuis (dans) la table CLIENTS de la base s'écrit :

public class BatchSqlRoute extends RouteBuilder {
 public void configure() {
  //handled(false) tell camel propagate the exception to caller.
  onException(SQLException.class).handled(false).
  log(LoggingLevel.ERROR,">>>Error in:  ${body},\n ${exception}");
        	
  //using SqlEndpoint select from CLIENTS
 from("direct:simpleSelect")
 .to("sql:SELECT * FROM CLIENTS 
           WHERE id=# ?dataSourceRef=myDataSource")
 .end();

 //using SqlEndpoint to insert into CLIENTS
from("direct:insertSql") 
.to("sql:INSERT INTO CLIENTS
     (id, nom,prenom) values (#,#,#)?dataSourceRef=myDataSource")
.end();
 }
}

Noter que chacune des deux chaînes de .to doivent être sur la même ligne.

Vous pouvez constater que deux endpoints sont définis :

le premier permet d'effectuer un simple select en fonction de l'id du client.

le second effectue une insertion des trois champs de la table CLIENTS.

ETAPE 4. CONFIGURER L'ENVIRONNEMENT

A) Fichier db.properties

Ce fichier (placeholder de spring) contient les paramètres d'accès à la base postgres qu'il faudrait adapter.

#params db postgres
bd.driverClassName=org.postgresql.Driver
bd.url=jdbc:postgresql://localhost:5432/test
bd.username=XXXXXX
bd.password=XXXX

B) Script de création de la table CLIENTS

Voici le script pour créer la table clients

CREATE TABLE clients(
  id bigint PRIMARY KEY NOT NULL,
  nom varchar(255),
  prenom varchar(255)
);
CREATE UNIQUE INDEX clients_prim_key ON clients(id);

ETAPE 4. TESTER AVEC JUNIT

package fr.netapsys.camel.tests;

import static org.junit.Assert.assertNotNull;
import static org.junit.Assert.assertTrue;

import java.util.List;
import java.util.Map;

import org.apache.camel.Endpoint;
import org.apache.camel.Exchange;
import org.apache.camel.ProducerTemplate;
import org.junit.Test;
import org.springframework.dao.DuplicateKeyException;

public class TestBatchSqlRoute extends TestParent {
	final static int ID_2_CREATE=110;
	
@Test 
public void testInsertSql() throws Exception {
	ProducerTemplate template = camelCtx.createProducerTemplate();
	Endpoint endpoint = camelCtx.getEndpoint("direct:insertSql");
	Exchange exchange = endpoint.createExchange();
	final long id = ID_2_CREATE+1001;
	final String nom = "toto"+id;
	final String prenom = "prenom"+id;
	exchange.getIn().setBody(new Object[]{id,nom,prenom});
	Exchange exchangeOut = template.send(endpoint, exchange);
	assertNotNull(exchangeOut);
	assertNotNull(exchangeOut.getOut());
	assertTrue(exchangeOut.getException() ==null ||
         exchangeOut.getException() instanceof DuplicateKeyException);
	if(exchangeOut.getException() !=null)
	 assertTrue(
          exchangeOut.getException() instanceof DuplicateKeyException);
   }
}

Lancer la commande mvn test pour voir une ligne s'insérer dans la table CLIENTS.

Le test suivant vous permet de recherche un client par son id.

Vérifier que l'id passé existe en base.

@Test 
public void testSelectSql() throws Exception {

	final static int ID_4_SELECT=110;
	ProducerTemplate template = camelCtx.createProducerTemplate();
	
	Endpoint endpoint = camelCtx.getEndpoint("direct:simpleSelect");
	Exchange exchange = endpoint.createExchange();
	
	exchange.getIn().setBody(ID_4_SELECT);
	Exchange out = template.send(endpoint, exchange);
	assertTrue(out != null);
	assertTrue(out.getException() == null);
	assertTrue(out.getOut() != null);
	int nb=out.getOut().getHeader
                   ("CamelSqlRowCount",Integer.class);
	assertTrue(nb == 1);
	List<Map<String,Object>> l= (List<Map<String,Object>>) 
            out.getOut().getBody();
	assertTrue(l.size()>0);
	Map<String,Object> map=l.get(0);
	assertTrue(map.get("nom").contains("toto");
}

Pour conclure le composant camel-sql réduit la couche DAO (ici à base de jdbc) à presque quelques lignes de configuration.

Améliorez les performances: Parallel processing with Camel & Spring (Partie 1/2)

Abderrazek CHINE — Mon, 04 Feb 2013 17:57:00 +0100

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.

Nous allons partir d'un projet maven préconfiguré que nous devons compléter pas à pas.

La première partie de ce billet est de montrer le fonctionnement de la démo en séquentiel.

La seconde partie introduit le parallélisme.

USE-CASE / CAS D'ETUDE

Le cas d'étude consiste à construire un ensemble d'instances java (bean du model nommé Tache) depuis des lignes d'un fichier CSV.

Nous le réalisons en exécution sequentielle dans la première partie puis en parallèle dans la seconde en considérant le cas où le fichier csv est trop gros.

Le diagramme de classe suivant est utile pour les deux parties (vous pouvez aggrandir l'image):

PREMIERE PARTIE

ETAPE 1. CREATION DU PROJET MAVEN PRECONFIGURE POUR CAMEL

Dans le répertoire workspace, créer un projet maven en mode intéractif avec la commande suivante (en une seule ligne):

mvn archetype:generate -Dfilter=camel-archetype-java 
   -DarchetypeVersion=2.10.3

Répondre à la première question en acceptant la valeur par défaut.

Saisir le nom de votre package pour la seconde question. Noter que ce nom sera utilisé plus loin.

Entrer le nom de votre projet en réponse à la troisième question sur artifactId.

ETAPE 2. IMPORTER LE PROJET DANS ECLIPSE

Cette étape est optionnelle car si vous utilisez l'IDE STS de Spring, vous pourriez importer votre projet maven directement dans STS.

Pour contruire le projet pour eclipse, lancer cette commande:

mvn eclipse:eclipse

Ensuite, importer le projet dans eclipse.

ETAPE 3. AJOUTER DES DEPENDANCES DANS LE POM

Nous complétons le pom.xml avec cette dépendance:

<!-- Camel-spring Component -->
	<dependency>
		<groupId>org.apache.camel</groupId>
		<artifactId>camel-spring</artifactId>
		<version>2.10.3</version>
		<scope>compile</scope>
	</dependency>

NOTE. Le contenu complet du pom sera fourni en annexe.

ETAPE 4. CONFIGURER LE PLUGIN CAMEL

<!-- run the route via 'mvn camel:run' -->
	<plugin>
		<groupId>org.apache.camel</groupId>
		<artifactId>camel-maven-plugin</artifactId>
		<version>2.10.3</version>
	</plugin>

ETAPE 5. AJOUTER LE FICHIER DE CONFIGURATION DE SPRING

Ajouter le fichier camel-context.xml dans src/main/resources/META-INF/spring (si besoin créer/ajouter les répertoires manquants).

Il ne contient que la déclaration du contexte camel ainsi que l'unique route existante:

<?xml version="1.0" encoding="UTF-8"?>
<!-- Configures the Camel Context -->
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xmlns:camel="http://camel.apache.org/schema/spring"
    xsi:schemaLocation="
    http://www.springframework.org/schema/beans 
    http://www.springframework.org/schema/beans/spring-beans.xsd
    http://camel.apache.org/schema/spring 
    http://camel.apache.org/schema/spring/camel-spring.xsd">
     <!-- camel context -->
      <camel:camelContext 
		xmlns="http://camel.apache.org/schema/spring">
	<camel:routeBuilder ref="myRouteBuilder"/>
	</camel:camelContext>
</beans>

Vous devez adapter son contenu en fonction de votre contexte et le nom de package déclaré au moment de créer le projet maven.

Vous pouvez tester la construction de votre projet maven avec la commande sur la console:

mvn camel:run

Pour quitter le programme tapez CTRL-C.

Si vous jetez un oeil sur le dossier target vous verrez un sous-dossier nommé messages contenant le contenu filtré des fichiers xml du répertoire src/data.

Ok, or tout cela n'est pas notre sujet aujourd'hui mais nous avons maintenant un projet maven préconfiguré pour camel.

NOTE IMPORTANTE

Pour la suite, les deux classes java MainApp et MyRouteBuilder ne seront plus utiles.

Vous pouvez les supprimer mais n'oubliez de retirer toute référence sur MainApp dans les plugins du pom.xml.

Il est temps de revenir à notre sujet.

Commençons par écrire un bean model nommé Inventory annoté avec les annotations du composant camel-bindy

ETAPE 6. ECRIRE LE BEAN MODEL ANNOTE

Voici donc le code source du bean model, de l'interface et de sa classe d'implémentation:

Le bean model est Inventory annoté avec les annotations du composant camel-bindy:

package fr.netapsys.blogs.camel.beans;
import java.io.Serializable;
import org.apache.camel.dataformat.bindy.annotation.CsvRecord;
import org.apache.camel.dataformat.bindy.annotation.DataField;
@CsvRecord(separator = ",", skipFirstLine = true)
public class Inventory implements Serializable {
	private static final long serialVersionUID = 1L;
	@DataField(pos = 1)
	private String supplierId;
	@DataField(pos = 2)
	private String partId;
	@DataField(pos = 3)
	private String name;
	@DataField(pos = 4)
	private String amount;
	public Inventory(String supplierId, String partId,
                                  String name,String amount) {
		this.supplierId = supplierId;
		this.partId = partId;
		this.name = name;
		this.amount = amount;
	}
//... omis les getters/setters et toString
}

Ce bean utilise le composant camel-bindy qui sera ajouté dans dépendances plus loin.

Il est annoté pour être mappé avec les lignes du fichier inventory.csv.

ETAPE 8. FICHIER CSV

Voici un exemple du fichier csv:

supplierId,partId,name,amount
1,2,toto,123.90
2,2,titi,89000.45

ETAPE 9. DESSINER UNE (BELLE) ROUTE CAMEL

Comme promis, nous nous inspirons du cas d'étude du chapitre 10 du livre Camel in action.

Comme vous pouvez constater, nous l'avons complètement adapté pour écrire encore moins de code.

A titre d'exemple, la transformation des lignes CSV en un POJO est désormais géré par le composant camel-bindy.

A l'aide de camel java DSL, nous dessinons notre route dans la classe MyRoute comme suit:

package fr.netapsys.blogs.camel.routes;
import org.apache.camel.LoggingLevel;
import org.apache.camel.builder.RouteBuilder;
import org.apache.camel.dataformat.bindy.csv.BindyCsvDataFormat;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;
import fr.netapsys.blogs.camel.impl.InventoryServiceImpl;
import fr.netapsys.blogs.camel.processors.MyProcessor;
@Component
public class MyRoute extends RouteBuilder {
 @Autowired 
 private MyProcessor myProcessor;
 
 public void configure() throws Exception {
  from("file:src/data/?fileName=inventory.csv&noop=true")
   .log(LoggingLevel.INFO,"MyRoute",
    "Starting process inventory.csv at ${date:now:dd/MM/yy HH:mm:ss}")
   .unmarshal(new BindyCsvDataFormat("fr.netapsys.blogs.camel.beans"))
   .process(myProcessor)
   .split(body())
   .streaming()
   .bean(InventoryServiceImpl.class, "updateInventory")
  .end()
  .log(LoggingLevel.INFO,"MyRoute",
     "Done processing file at ${date:now:dd/MM/yy HH:mm:ss}.");	
  }	
}

Explications:

La route de camel commence par lire le fichier inventory.csv défini via l'argument fileName dans le répertoire src/data.

Le second argument noop=true indique à camel de ne pas déplacer le fichier après son traitement. Sinon, par défaut, camel déplace le fichier dans le répertoire caché .camel.

La fonction unmarshal transforme le contenu du fichier csv en une map d'instances Inventory.

Puis le processor récupère la liste des instances Inventory et définit le body de l'exchange.

Le code de la classe MyProcessor est donné ci-après.

Le split(body()) décompose à juste titre la liste d'objets en une instance Inventory.

Enfin, c'est la méthode updateInventory qui opère sur chaucne des instances de la liste.

Pour finir, une simple trace log termine la route camel.

Le service InventoryServiceImpl doit implémenter la seule méthode updateInventory.

L'étape suivante présente les détails d'implémentation.

Mais avant cela, voici le code du processor Myprocessor:

package fr.netapsys.blogs.camel.processors;
import java.util.ArrayList;
import java.util.List;
import java.util.Map;
import org.apache.camel.Exchange;
import org.apache.camel.Processor;
import org.springframework.stereotype.Component;
import fr.netapsys.blogs.camel.beans.Inventory;

@Component
public class MyProcessor implements Processor{
  @Override
  public void process(Exchange exchange) throws Exception {
   List<Map<String, Inventory>> listMapInv=
                 exchange.getIn().getBody(List.class);
   List<Inventory> listInv=new ArrayList<>();	
   for(Map<String,Inventory> map:listMapInv){ 
     listInv.add(
        (Inventory)map.get("fr.netapsys.blogs.camel.beans.Inventory"));
   }
   exchange.getIn().setBody(listInv);
 }
}

Cette classe implémente le contrat Processor de camel d'où la définition de la méthode process().

Dans process(), nous récupérons les instances Inventory à partir du fichier csv dans une liste, puis le body de l'exchange est défini avec cette liste.

ETAPE 10. ECRIRE LE SERVICE METIER

Contrairement à l'exemple du chapitre 10 du livre "Camel in action", notre interface est mono car il déclare une seule méthode.

package fr.netapsys.blogs.camel.interfaces;
import fr.netapsys.blogs.camel.beans.Inventory;
public interface InventoryService {
  void updateInventory(final Inventory inv) throws Exception;
}

Son implémentation est:

package fr.netapsys.blogs.camel.impl;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import fr.netapsys.blogs.camel.beans.Inventory;
import fr.netapsys.blogs.camel.interfaces.InventoryService;
public class InventoryServiceImpl implements InventoryService {
  @Override
  public void updateInventory(Inventory inventory) throws Exception {
     // simulate updating using some CPU processing
     Thread.sleep(100);
  }
}

ETAPE 11. AJOUTER LES DEPENDANCES DANS LE POM

Ajouter la dépendance sur le composant camel-bindy:

<dependency>
  <groupId>org.apache.camel</groupId>
  <artifactId>camel-bindy</artifactId>
  <version>2.10.3</version>
</dependency>

ETAPE 12.TESTER L'EXECUTION SEQUENTIELLE

Voici une première classe abstraite pour faciliter l'écriture des tests JUnit.

package fr.netapsys.blogs.camel.demo.tests;
import org.apache.camel.CamelContext;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.ApplicationContext;
import org.springframework.test.annotation.DirtiesContext;
import org.springframework.test.annotation.DirtiesContext.ClassMode;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration({"classpath:META-INF/spring/camel-context.xml"})
@DirtiesContext(classMode = ClassMode.AFTER_CLASS)
public abstract class TestParent  {
	@Autowired protected ApplicationContext sprinCtx;
	@Autowired protected CamelContext camelCtx;	
}

Nous écrivons un premier test JUnit comme suit:

package fr.netapsys.blogs.camel.demo.tests;
import org.junit.Test;
public class TestSequentielRouteTest extends TestParent {	
	@Test
	public void testSeqFile() throws InterruptedException{
		Thread.sleep(3000);
	}
}

Comme vous pouvez le constater nous avons là aussi simplifier l'écriture du test par rapport à celui du chapitre 10 du livre "Camel in action".

La classe test JUnit hérite de la classe abstraite TestParent qui se charge de démarrer le contexte de spring.

Ainsi, la route camel est automatiquement lancée par le contexte camel démarré par Spring.

SECONDE PARTIE: EXECUTION PARALLELE

Voici les étapes que nous développerons dans la deuxième partie de ce billet.

ETAPE 13. REDESSINER LA ROUTE DE CAMEL
ETAPE 14. DECLARER LA ROUTE DANS SPRING
ETAPE 15. CONFIGURER L'EXECUTOR DE SPRING
ETAPE 16. TESTER L'EXECUTION PARALLELE

A très bientôt.

Spring parallel processing. Exécution parallèle avec Spring

Abderrazek CHINE — Mon, 28 Jan 2013 17:56:00 +0100

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.

Voici les étapes pour concevoir notre démonstration simple.

ETAPE 1. ECRIRE UN BEAN MODEL

La classe Tache décrit le model de notre simple démo:

package fr.netapsys.executorservice.beans;

import java.io.Serializable;
import java.text.SimpleDateFormat;
import java.util.Date;

public class Tache implements Serializable {

	private final static transient SimpleDateFormat sdf=
                 new SimpleDateFormat("dd/MM/yy HH:mm:ss");
	private static final long serialVersionUID = 1L;

	private String libelle, strDate;
	
	public Tache(){
		super();
	}
	
	public Tache(final String libelle,final String strDate){
		setLibelle(libelle);
		setStrDate(strDate);
	}
	

	public Tache(final String libelle,final Date date){
		setLibelle(libelle);
		setStrDate(sdf.format(date));
	}
	//.... omis les getters/setters et toString
}

ETAPE 2. AJOUTER LES DEPENDANCES

Seules les dépendances de Spring sont ajoutés, le pom.xml est donné en annexe.

ETAPE 3. CONFIGURER SPRING

Nous retenons la configuration java-centric dans cette démo.

La classe chargée de configurer Spring est JavaConfigurator:

package fr.netapsys.executorservice.javacfg;
import java.util.concurrent.ExecutorService;
import org.springframework.context.annotation.*;
import org.springframework.core.task.TaskExecutor;
import org.springframework.core.task.support.ExecutorServiceAdapter;
import org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor;
@Configuration
public class JavaConfigurator {
    protected static int nbThreadPool=5;    
    /***
     * Use l'implementation spring 
       ThreadPoolTaskScheduler de l'interface TaskExecutor
    */
    @Bean
    public TaskExecutor taskExecutor() {
       ThreadPoolTaskExecutor tpte = new ThreadPoolTaskExecutor(); 
       tpte.setCorePoolSize(nbThreadPool);
       tpte.setMaxPoolSize(nbThreadPool*2);
       tpte.setQueueCapacity(nbThreadPool*10);
       return tpte;
    }
    /* Use l'adapter de spring ExecutorServiceAdapter pour 
         retourner une instance ExecutorService
         au lieu de Executors.newFixedThreadPool de java
    */
    @Bean
    public ExecutorService executorService() {
      return new ExecutorServiceAdapter(taskExecutor()); 
    }
}

Explications:

C'est ici que la configuration du contexte de spring est regroupée.

Une instance de TaskExecutor est définie: précisément c'est l'implémentation ThreadPoolTaskExecutor de spring retenue.

L'instance ThreadPoolTaskExecutor est configurée ainsi:

- corePoolSize initialisé à 5. Le nombre de thread lancés simultanément,

- maxPoolSize le nombre maximal de thread lancés en parallèle. Au dela il sera mis en pool,

- queueCapacity la taille max du pool. Au délà une exception de rejet est levée (à moins de configuration particulière).

Nous avons aussi défini une instance de ExecutorService qui autorise de lancer un objet Runnable ou Callable.

Nous y reviendrons une autre fois sur les Callable.

NOTES.

- Les commentaires dans le code complètent ces explications,

- C'est spring qui se charge d'appeler la méthode shutdown sur ExecutorService donc il n'est pas autorisé de l'appeler manuellement.

ETAPE 4. ECRIRE UNE CLASSE RUNNABLE (THREAD)

La classe MyThread implémente l'interface Runnable:

package fr.netapsys.executorservice;
import java.util.Date;
import java.util.concurrent.atomic.AtomicInteger;
import org.slf4j.*;
import fr.netapsys.executorservice.beans.Tache;

public class MyThread implements Runnable {
    private AtomicInteger num;
    private Logger logger=LoggerFactory.getLogger("MyThread");
    public MyThread(){super();    }
    public MyThread(AtomicInteger ai){
       this(); 
       this.num=ai;
    }
    @Override
    public void run() {
       logger.info(Thread.currentThread().getName()+" demarrage:"+num);
       process(); /*simulate long process*/
       logger.info(Thread.currentThread().getName()+" termine.");
    }
    private void process() {
        Tache tache=new Tache("libel"+num, new Date());	
    	logger.info("processing tache:"+tache);
    }
}

Dans la classe MyThread qui redéfinit la méthode run qui simule un long processus.

Dans notre cas, une tache est créée puis logguée. Je n'utilise pas de Thread.sleep afin de ne pas masquer les difficulltés liées à l'exécution parallèle.

Il serait utile de surcharger la méthode toString() du bean Tache pour un affichage clair.

ETAPE 5. Tester avec JUnit

Avec ce test nous mettons en pratique l'exécution parallèle en appelant la méthode execute de l'instance de TaskExecutor. Ce test hérite de la classe abstrainte TestParent donné ci-après.

package fr.netapsys.executorservice.tests;

import static org.junit.Assert.assertNotNull;
import java.util.concurrent.atomic.AtomicInteger;
import org.junit.Test;
import org.slf4j.*;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.core.task.TaskExecutor;
import fr.netapsys.executorservice.MyThread;

public class TestSpringTaskExecutor extends TestParent {
	private Logger logger=LoggerFactory.getLogger(this.getClass());
	@Autowired TaskExecutor threadPoolTaskExecutor;
	@Test
	public void testSpringTaskExecutor() 
                             throws InterruptedException  {
		assertNotNull(threadPoolTaskExecutor);
		for (int k = 0; k < 5; k++) {
			Runnable myThread = 
                            new MyThread(new AtomicInteger(k));
			threadPoolTaskExecutor.execute(myThread);
		}
		Thread.sleep(500);
		logger.info("Finished all threads");
	}	
}

La seule chose à noter est la boucle for qui crée cinq threads.

Ces threads sont lancés simultanément via la méthode execute de l'instance ThreadPoolTaskExecutor spring.

En effet, à chaque itération, un objet Runnable est passée à la méthode execute.

Ainsi, plusieurs tâches sont lancées simultanément dont chacune réalise le traitement dans la méthode run.

Dans notre cas, chaque thread initialise une instance du bean Tache puis le loggue.

La classe abstraite TestParent permet de charger le contexte spring à partir de JavaConfigurator:

package fr.netapsys.executorservice.tests;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.ApplicationContext;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
import fr.netapsys.executorservice.javacfg.JavaConfigurator;

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes={JavaConfigurator.class})
public abstract class TestParent{
	@Autowired ApplicationContext sprinCtx;
}

Il reste à lancer mvn test et observer les traces logs.

En fonction de votre environnement, les traces logs ne sont pas forcément ordonnés.

Dans un proche billet nous ferons tout cela avec le framework Camel ce qui rend la chose plus simple.

ANNEXE 1.

Voici le contenu du pom.xml:

<properties>
	<jdk-version>1.7</jdk-version>
	<!-- Log -->
	<log4j-version>1.2.17</log4j-version>
	<slf4j-version>1.6.6</slf4j-version>
	<!-- Spring -->
	<spring-version>3.1.2.RELEASE</spring-version>
	<!-- versions dependances de test -->
	<junit-version>4.10</junit-version>
	<javassist-version>3.12.1.GA</javassist-version>
	<cglib-version>2.2.2</cglib-version>
</properties>
	
<dependencies>
	<!-- 2 dep transitive de JavConfig see @Configuration -->
	<dependency>
		<groupId>javassist</groupId>
		<artifactId>javassist</artifactId>
		<version>${javassist-version}</version>
		<scope>compile</scope>
	</dependency>
	<dependency>
		<groupId>cglib</groupId>
		<artifactId>cglib</artifactId>
		<version>${cglib-version}</version>
		<scope>compile</scope>
	</dependency>
	<!-- spring-core -->
	<dependency>
		<groupId>org.springframework</groupId>
		<artifactId>spring-core</artifactId>
		<version>${spring-version}</version>
		<scope>compile</scope>
	</dependency>

	<!-- spring-expression -->
	<dependency>
		<groupId>org.springframework</groupId>
		<artifactId>spring-expression</artifactId>
		<version>${spring-version}</version>
		<scope>compile</scope>
	</dependency>
	<!-- spring-context -->
	<dependency>
		<groupId>org.springframework</groupId>
		<artifactId>spring-context</artifactId>
		<version>${spring-version}</version>
		<scope>compile</scope>
	</dependency>
<!-- spring-asm -->
	<dependency>
		<groupId>org.springframework</groupId>
		<artifactId>spring-asm</artifactId>
		<version>${spring-version}</version>
		<scope>compile</scope>
	</dependency>
<!-- spring-beans -->
	<dependency>
		<groupId>org.springframework</groupId>
		<artifactId>spring-beans</artifactId>
		<version>${spring-version}</version>
		<scope>compile</scope>
	</dependency>
	<!-- spring-context-support -->
	<dependency>
		<groupId>org.springframework</groupId>
		<artifactId>spring-context-support</artifactId>
		<version>${spring-version}</version>
		<scope>compile</scope>
	</dependency>
	<!-- logging -->
	<dependency>
		<groupId>org.slf4j</groupId>
		<artifactId>slf4j-api</artifactId>
		<version>1.6.6</version>
	</dependency>
	<dependency>
	 <groupId>org.slf4j</groupId>
	 <artifactId>slf4j-log4j12</artifactId>
	 <version>1.6.6</version>
	</dependency>
	<dependency>
	 <groupId>log4j</groupId>
	 <artifactId>log4j</artifactId>
	 <version>1.2.17</version>
	</dependency>
	<!-- logging -->
	<dependency>
	 <groupId>commons-logging</groupId>
	 <artifactId>commons-logging</artifactId>
	 <version>1.1</version>
	 <scope>runtime</scope>
	</dependency>
	<!-- spring-test -->
	<dependency>
	 <groupId>org.springframework</groupId>
	 <artifactId>spring-test</artifactId>
	 <version>${spring-version}</version>
	 <scope>test</scope>
	</dependency>
	<!-- DEPENDANCES DE TESTS junit -->
	<dependency>
	 <groupId>junit</groupId>
	 <artifactId>junit</artifactId>
	 <version>${junit-version}</version>
	 <scope>test</scope>
	</dependency>
</dependencies>
<build>
	<defaultGoal>install</defaultGoal>
	<plugins>
	 <plugin>
	  <groupId>org.apache.maven.plugins</groupId>
		<artifactId>maven-compiler-plugin</artifactId>
		<version>2.5.1</version>
		<configuration>
		 <source>1.7</source>
		 <target>1.7</target>
		</configuration>
		</plugin>
	</plugins>
</build>

Composant Camel-Bindy: Comment transformer les données non structurées

Abderrazek CHINE — Tue, 22 Jan 2013 18:39:00 +0100

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.

La démo du composant bindy est un projet maven réalisé en quatre actes:

ACTE1. Configurer le pom

<dependency>
  <groupId>org.apache.camel</groupId>
  <artifactId>camel-bindy</artifactId>
  <version>2.10.2</version>
</dependency>

ACTE2. Dessiner la route et la déclarer dans spring

package fr.netapsys.camel.routes;
import org.apache.camel.builder.RouteBuilder;
import org.apache.camel.dataformat.bindy.csv.BindyCsvDataFormat;

public class BindyRoute extends RouteBuilder {
	@Override
	public void configure() throws Exception {
     from("file://src/?noop=true&fileName=persons.csv")
	  .unmarshal(new BindyCsvDataFormat("fr.netapsys.camel.beans")) 
	  .to("mock:results.csv")
	 .end();
	}
}

La route pointe sur un fichier persons.csv localisé dans src.

La méthode unmarshall se charge de convertir les données en csv via l'argument BindyCsvDataFormat.

BindyCsvDataFormat prend en argument les noms des packages des classes annotées.

Elle prend aussi comme argument la classe annotée (voir la javadoc).

N'oublier pas d'ajouter dans le fichier camel-context.xml une référence sur BindyRoute comme suit:

<camel:camelContext 
	xmlns="http://camel.apache.org/schema/spring">
	<camel:routeBuilder ref="bindyRoute" />
</camel:camelContext>

Le principe de "Convention over configuration" attend que le fichier camel-context.xml dans src/META-INF/spring.

ACTE3. Annoter le bean du model pour camel-bindy

package fr.netapsys.camel.beans;
import java.io.Serializable;
import org.apache.camel.dataformat.bindy.annotation.CsvRecord;
import org.apache.camel.dataformat.bindy.annotation.DataField;

@CsvRecord(separator = ",", skipFirstLine=true)
public class Personne implements Serializable {
	@DataField(pos = 1)
	private String nom;
	@DataField(pos = 2)
	private String prenom;
	@DataField(pos = 3)
	private String age;	

        public Personne(){}

	public Personne(String nom,String prenom,String age){
		setNom(nom);
		setPrenom(prenom);
		setAge(age);
	}
//...  getters / setters toString omis...
}

Explications:

L'annotation @CsvRecord de org.apache.camel.dataformat.bindy précise que ce bean servira à la transformation csv.

Les deux attributs de cette annotation permettent de définir le séparateur et d'ignorer la première ligne.

Le reste des annotations de bindy servent à structurer les données.

Attention, pensez à écrire le constructeur par défaut si vous en créez un ou plusieurs avec arguments.

ACTE4. Tester

Vérifions que, dans le répertoire src/, l'existence d'un fichier persons.csv contenant les lignes à transformer en objets java.

Ces lignes doivent avoir trois colonnes nom, prénom et age comme suit:

[persons.csv]
nom,prenom,age
Toto,To,30
Titi,Ti,32
......

Voici le code du test:

package fr.netapsys.camel.tests;

import java.util.*;
import org.apache.camel.builder.RouteBuilder;
import org.apache.camel.component.mock.MockEndpoint;
import org.apache.camel.test.junit4.CamelTestSupport;
import org.junit.*;
import fr.netapsys.camel.beans.Personne;
import fr.netapsys.camel.routes.BindyRoute;

public class BindyRouteTest  extends CamelTestSupport {
final String clazzModel="fr.netapsys.camel.beans.Personne";
@Override
protected RouteBuilder createRouteBuilder() throws Exception {
	return new BindyRoute();
}

@Test
public void testBindyCamel() throws Exception {
  
      MockEndpoint mock = getMockEndpoint("mock:results.csv");
		
      mock.expectedMessageCount(1);
      assertMockEndpointsSatisfied();
		
       List<Map<String, Personne>> listMapPersons = 
               (List<Map<String, Personne>>) mock
		   .getReceivedExchanges().get(0).getIn().getBody();

	Assert.assertTrue(listMapPersons.size()==2);
	Assert.assertTrue(listMapPersons.get(0)
                  .get("fr.netapsys.camel.beans.Personne")!=null);
	
 }
}

Les lignes du fichier persons.csv sont transformées en liste d'instances Personne.

Voilà tout!

Camel, Spring et tests JUnit pour les nuls (partie 2/3)

Abderrazek CHINE — Mon, 14 Jan 2013 19:39:00 +0100

Ce billet est la suite de Camel, Spring et tests JUnit pour les nuls (partie 1/3).

Voici donc la troisième démo avancée.

TROISIEME DEMO: Exécuter script shell: Niveau avancé

L'objet de cette démo avancée est de pouvoir envoyer des commandes batch windows.

Le canal d'entrée attend un message (body) ayant le format suivant: RepertoireExec;commande;optionCmd

avec comme séparateur le point virgule.

En résumé la route est composée de cet enchainement:

"direct://a"-> Processor1 ->uriExecShell ->Processor2 -> uriFile.

Nous allons détailler les trois actes.

Acte1: Dessiner une route plus complexe

package fr.netapsys.camel.routes;
import org.apache.camel.Exchange;
import org.apache.camel.builder.RouteBuilder;

import fr.netapsys.camel.processors.MyExecProcessor;
import fr.netapsys.camel.processors.MyProcessor;

public class MyThirdRoute extends RouteBuilder {
 @Override
 public void configure() throws Exception {
/**
 * la route est configurée ainsi:
 * Le msg, arrivant à "direct://a" est traité par MyProcessor. 
 * MyProcessor prépare les arguments de la commande batch
 * Puis passe le msg au second endpoint "exec:cmd". 
 * Arrivé à ce dernier, le msg est traité par MyExecProcessor qui
 * analyse le résultat de l'execution. Deux cas possibles: 
 * - En cas d'echec du shell, une exception est levée.
 * - Sinon, un header est setté puis le msg est passé à uriFile
 */

 from("direct://a").process(new MyProcessor())
	.to("cmd:exec").process(new MyExecProcessor())
	.setHeader(Exchange.FILE_NAME, constant("camelResult.txt"))
	.to("file:/temp/?fileExist=Override")
	.end();
  }
}

Noter que les commentaires de cette classe détaille l'enchaînement.

Il reste à écrire les deux classes MyProcessor et MyExecProcessor qui doivent implémenter l'interface Processor.

Ce dernier possède une seule méthode process(Exchange ex).

La première classe MyProcessor:

package fr.netapsys.camel.processors;
import org.apache.camel.Exchange;
import org.apache.camel.Processor;
import org.apache.camel.component.exec.ExecBinding;
import fr.netapsys.camel.utiles.Utiles;
import org.springframework.stereotype.Component;

@Component
public class MyProcessor  implements Processor {	
/***Simple processor afin de traiter  la ligne de commande** */
   @Override
   public void process(final Exchange exchange) throws Exception {
     // Recup the body sent to uriEntree
     final String body = exchange.getIn().getBody(String.class);
     String[] bodySplit=body.split(";");	    
     if(bodySplit.length<3) {
	throw new IllegalArgumentException(
            "Erreur:body format not correct for the body :" +body);
     }
    final String currentDir=bodySplit[0];
    final String cmdBatch=bodySplit[1];
    final String option=bodySplit[2];
    exchange.getOut().setHeader(
           ExecBinding.EXEC_COMMAND_WORKING_DIR, currentDir);	 
    // Activation des canaux StdErr si StdOut n est pas open
    exchange.getOut().setHeader(
              ExecBinding.EXEC_USE_STDERR_ON_EMPTY_STDOUT, true);
    exchange.getOut().setHeader(ExecBinding.EXEC_COMMAND_ARGS,
                Utiles.getExecCommand(cmdBatch, option));
  }
}

L'extraction des éléments de la commande windows est effectuée en splittant le message à l'aide du séparateur ; .

Ces éléments sont explicitement nommés dans le code.

La méthode process du Processor prend en argument une instance exchange.

La ligne exchange.getIn().getBody() illustre que l'objet exchange contient, entre autres, le message In (en entrée).

La ligne exchange.getOut() permet d'accéder au message Out (de sortie).

Plus loin, nous verrons comment accéder à d'autres informations (ex. exception) durant l'acheminement du message.

Donc, la ligne :

exchange.getOut().setHeader(ExecBinding.EXEC_COMMAND_ARGS, 
                   Utiles.getExecCommand(cmdBatch, option));

établit la liste des arguments de la commande batch en utilisant la méthode statique getExecCommand de la classe Utiles.

Le code de la classe Utiles contient une seule méthode statique dont voici son code:

public static List<String> getExecCommand(
     final String commande, final String param) {
    return new ArrayList<String>() {
      private static final long serialVersionUID =1L;
     {
       	add("/C");
       	add(commande);
       	add(param);
      }	        
    };
}

Une seule option (param) de la commande cmd.exe a été gérée (sans soin) dans cette méthode.

Passons à la seconde classe nommée MyExecProcessor:

package fr.netapsys.camel.processors;
import org.apache.camel.Exchange;
import org.apache.camel.Processor;
import org.apache.camel.component.exec.ExecResult;
import org.springframework.stereotype.Component;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

@Component
public class MyExecProcessor implements Processor {
 private Logger  logger=
         LoggerFactory.getLogger(MyExecProcessor.class);
  @Override
  public void process(Exchange exchange) throws Exception {
    // On recupere l'exec de la ligne de commande
    final ExecResult execRes = exchange.getIn().
                         getBody(ExecResult.class);
    if (execRes.getExitValue() != 0) {
      logger.error("\n\t>>>>Exec cmd '" +execRes.getCommand()+
          "' echec avec  exit value:'"+execRes.getExitValue()+"'\n");
    }
 }
}

Dans la méthode process, on accède:

- Au résultat de l'exécution de la commande via l'instance ExecResult,

- Au contenu de l'exception levée dans l'objet exchange.

L'objetExecResult permet de récupérer le code retour de l'exécution d'une commande. En cas d'échec de l'exécution de la commande un code de retour différent de zéro est retournée.

Acte2: Configurer Spring

Pas grand chose si la route est déclarée dans le même package.

Acte3: Tester avec JUnit

Le test JUnit repose toujours sur Spring:

package fr.netapsys.camel.tests;
import org.apache.camel.ProducerTemplate;
import org.apache.camel.component.exec.ExecException;
import org.junit.Test;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class TestMyExecRoute  extends TestParent{	
 private Logger logger=LoggerFactory.getLogger(TestMyExecRoute.class);
 @Test
 public void testExecRoute() throws Exception {		
    ProducerTemplate template=camelCtx.createProducerTemplate();
    try{
 	template.sendBody("direct://a", "/temp/;dir;/W");
    }catch(ExecException e){
	logger.error("\n>>>Erreur produite:\n"+e,e);
    }
 }
}

Il suffit de lancer mvn test.

Pour voir la log s'afficher passer en argument commande non reconnue par l'OS.

La troisième partie nous fait découvrir les composants Camel-JDBC et Camel-SQL, une autre manière de de faire du jdbc ou de la peristance sans écrire du code (de plomberie!).

Bean validation avec camel: Composant camel-bean-validator

Abderrazek CHINE — Wed, 09 Jan 2013 19:00:00 +0100

L'objet de ce billet est de présenter la validation (jsr303) avec le composant camel-bean-validator.

Ce composant permet de valider des pojos ou beans annotés.

Deux démos sont fournies. La seconde un peu plus avancée.

Chaque démo est un projet maven réalisée en trois actes:

- Configurer la pom,

- Annoter le bean,

- Tester avec JUnit.

Voici dons les étapes.

PREMIERE PARTIE: Valider des beans

ACTE1. Dépendances du pom

<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-bean-validator</artifactId>
<version>2.10.2</version>
</dependency>

La version doit être celle de camel-core.

ACTE2. Ecrire un bean annoté pour validation

package fr.netapsys.camel.beans;
import javax.validation.constraints.NotNull;
import javax.validation.constraints.Pattern;
public class Utilisateur {
	@NotNull private String login;
	@Pattern(regexp="[a-zA-Z0-9]+")
	private String pwd;

        public Utilisateur(){}
	
	public Utilisateur(String login,String pwd){
	  setLogin(login);
	  setPwd(pwd);
	}

... omis setters/getters et toString
}

ACTE3. Tester et déclarer la route

package fr.netapsys.camel.tests;

import org.apache.camel.*;
import org.apache.camel.builder.RouteBuilder;
import org.apache.camel.component.bean.validator.*;
import org.apache.camel.test.junit4.CamelTestSupport;
import org.junit.Test;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import fr.netapsys.camel.beans.Utilisateur;

public class TestCamelUtilisateurValidator 
                        extends CamelTestSupport {

 private static final String ENTREE = "direct:in";	
  private static final Logger logger=
        LoggerFactory.getLogger(TestCamelUtilisateurValidator.class);
  //Route definie ici en surchargeant 
   //createRouteBuilder de CamelTestSupport.
  @Override
   protected RouteBuilder createRouteBuilder() 
                  throws Exception {
     return new RouteBuilder() {
	@Override
	public void configure() throws Exception
	{
 	   onException(BeanValidationException.class)
	    .handled(false)
            .log(LoggingLevel.ERROR,
                 ">>>Error in:  ${body},\nmsg=${exception.message}\n")
	    .end();
			 	
	  from(ENTREE)
		.to("bean-validator://v")
		.convertBodyTo(String.class)
		.setHeader(Exchange.FILE_NAME,constant("ok.log"))
		.to("file:/temp")
		.end();
		}
	 };
	}

  @Test
  public void testOk() throws Exception {
		
	ProducerTemplate producerTemplate =
                     context.createProducerTemplate();
	Utilisateur user = new Utilisateur("test","secret");
	logger.info("body ok :"+user);
		
	producerTemplate.sendBody(ENTREE, user);
         //assertion todo
         //dans /temp le fichier ok.log est créé
	}

  @Test
  public void testValidKo() throws Exception {
	ProducerTemplate producerTemplate = 
                context.createProducerTemplate();
	Utilisateur user = new Utilisateur();
	user.setLogin(null); //not correct
		
	Endpoint ep=context.getEndpoint(ENTREE);
	Exchange exch=ep.createExchange(ExchangePattern.InOnly);
	exch.getIn().setBody(user);
	Exchange out=producerTemplate.send(ep,exch);
	//pliz note this assert depends on errorHandler and handled.
	assertTrue(
            "Lorsque handled(false), BeanValidationException levée",
           out.getException() instanceof BeanValidationException);
      }
}

Explications:

La route camel est définie dans le test en surchargeant la méthode createRouteBuilder() de CamelTestSupport.

Cette route permet de stocker les messages valides dans un fichier et de logguer en erreur les messages non valides.

Deux méthodes de test :

- La première, testOk(), fait opérer la validation sur des données valides,

- La seconde testValidKo() permet de voir la propagation d'une BeanValidationException sur des données non valides.

Enfin, les commentaires dans le code du test détaille le fonctionnement du composant et l'interception de l'exception générée.

SECONDE PARTIE: Valider des listes de beans

ACTE1. Annoter le bean

Ici nous écrivons une classe, nommée Groupe, conteneur de beans Utilisateur.

La classe Groupe est annotée avec @Valid de javax.validation.

package fr.netapsys.camel.beans;
import java.util.*;
import javax.validation.Valid;
public class Groupe {
	@Valid
	private List<Utilisateur> users;
 	public Groupe(){
	 users=new ArrayList<>();
 	}
 	//methode pratique
	public void addUser(Utilisateur u){
		users.add(u);
	}
	...omis getters/setters
}

ACTE2. Tester

Ajouter à la classe de test la méthode testValidGroupeKo:

@Test
public void testValidGroupeKo()  {
 //preparer le body
  Groupe groupe=new Groupe();		
  Utilisateur user = new Utilisateur("anonym","anonym");
  groupe.addUser(user);
  
  user = new Utilisateur("anonym","--");
  groupe.addUser(user);

   //setter le body de l'exchange
   Endpoint ep=context.getEndpoint(ENTREE);
   Exchange exch=ep.createExchange();
   logger.info("Bad groupe utilisatuers :"+groupe);
   exch.getIn().setBody(groupe);
   //envoi de l exchange
   ProducerTemplate producerTemplate = 
            context.createProducerTemplate();
   Exchange out=producerTemplate.send(ep,exch);

   //assertion
   assertTrue(" BeanValidationException est levée", 
       out.getException() instanceof BeanValidationException);
}

Les commentaires du code explique la démarche de validation d'un conteneur d'objets.

En résumé, le conteneur doit comporter l'annotation @Valid et ses éléments doivent également être annotées avec javax.validation.constraints.

Nous avons réalisé la validation des beans et des conteneurs de beans avec une ou deux annotations et presque une ligne de code.

Voilà c'est tout!

Camel, Spring et tests JUnit pour les nuls (partie 1/3)

Abderrazek CHINE — Fri, 04 Jan 2013 17:28:00 +0100

L'objet de ce billet est d'expliquer l'essentiel de Apache Camel avec Spring et accompagné de tests JUnit.

Apache Camel est un framework puissant implémentant les patterns EIP (Enterprise Integration Patterns).

Apache Camel permet l'échange, le routage et la transformations des données avec une variété de protocoles et connecteurs.

L'architecture de Camel basée sur des composants pluggables. Il offre une panoplie de composants intégrables avec facilité à nos projets web ou non.

Apache Camel n'est pas réservée à des applications Client/Serveur, des Webservices ou des échanges JMS (Java Messaging Service).

En pratiquant Camel, on découvre que c'est un couteau suisse fort utile.

Les démos ci-après, projets java standards, aident à la prise en main rapide de Camel.

La dernière démo introduit néanmoins des notions avancées de Camel.

Chacune des démos de ce billet est organisé en trois actes :

- Acte 1: Dessiner une route Camel,

- Acte 2: Configurer Camel dans Spring,

- Acte3: Tester avec Junit

Camel v2.10, Spring v3.x et Java 7 sont utilisés bien que java 5 devrait suffire.

Les mots clés de ce billet sont : Camel, EIP, route, processor, exchange, body, header, spring, encodage, test JUnit.

Passons à la mise en pratique.

Contrairement à mes habitudes, je vous propose de démarrer par télécharger le zip du projet démo.

Ce projet nous servira de base et il sera complété à partir de la seconde partie.

Dézipper le projet dans le workspace de votre eclipse.

Puis lancer la commande:

mvn test

En principe les tests passent (au vert).

Sinon créer le répertoire /temp à la racine de votre disque (sous windows c:\temp) et relancer les tests.

Lancer la commande

mvn eclipse:eclipse

Puis importer le projet dans eclipse.

Vous pouvez par la suite reproduire, étape par étape, les démos ci-après ou exécuter directement le projet dans eclipse.

Seul le fichier pom.xml ne sera détaillé dans ce billet.

Compléter les dépendances nécessaires en s'inspirant du pom.xml fourni dans le zip.

NOTIONS ET TERMINOLOGIE

On va expliquer rapidement les notions importantes de Camel ainsi que les termes provenant de l'EIP.

Certains termes anglais ne seront pas traduits.

1- Camel contexte & Composant

Camel, au plus haut niveau, définit un contexte qui est une collection d'instances de composants.

Chaque composant est principalement une fabrique (factory) d'instances de endpoint. Voir après.

2- Endpoint

Ce terme est utilisé dans la communication inter-processus ou inter-composants.

Par exemple, en communication Client/Serveur, le client est un endpoint et le serveur en est un autre.

Selon l'utilisation, un endpoint peut référer à une adresse URL www.host:port,

Et derrière cette URL il se peut qu'il y a un logiciel ou (web)service interrogeable.

Donc, un endpoint agit comme une URI (voir ci-après) dans une application ou comme une destination JMS.

On communique avec un endpoint de deux façons:

- soit par l'envoi de message en créant un Producer attaché à cet endpoint,

- soit par consommer le message en créant un Consumer sur cet endpoint.

A noter que certains endpoints (ex. DirectEndpoint ) n'acceptent pas de consommateurs et d'autres (ex. JdbcEndpoint) n'acceptent pas de producteurs.

3- Route & RouteBuilder

Une route est l'enchainement des étapes qu'un message doit parcourir à partir de sa réception par le canal (endpoint) d'entrée.

Camel fournit deux manières d'écrire une route:

- soit par configuration XML,

- soit avec Camel java DSL (domain specific language).

Note. Dans la suite on utilise plutôt le java DSL

4- URI

Camel utilise beaucoup cette notion pour construire une route.

Quels sont les significations des URI, URN, URL?

Un URI permet d'identifier une ressource de manière permanente.

Un URI peut-être de type URL (locator) ou URN (name).

Voir le wiki pour plus de détails.

5- Message

Le Message est une interface abstraite (public abstract interface org.apache.camel.Message). Exemples: -la requête en entrée, la réponse ou un message d' exception.

Dans le jargon de Camel, la requête est nommée In, le retour Out et le message d'exception 'Fault message'.

Des classes Camel concrètes implémentent cette interface (ex.GenericFileMessage, MailMessage).

6- Exchange

Exchange est une interface abstraite pour l'échange de messages.

C'est un conteneur de messages qui tient à jour les informations durant l'acheminement du message reçu.

DefaultExchange est une classe concrète dans Camel implémentant l'interface Exchange.

7- CamelTemplate

La classe Camel nommée auparavant CamelClient a été renommée en CamelTemplate afin de se conformer au nommage et convention rendus célèbres par Spring.

La classe CamelTemplate est un wrapper qui permet l'envoi de message (exchange).

Avec ces notions, je crois que nous sommes bien armés pour débuter une première démo.

PREMIERE DEMO: Loguer avec Camel

Nous commençons par une démo rapide et facile pour illustrer la puissance de Camel.

Dans cette démo, on souhaite tracer des logs.

Et il ne faudrait qu'une seule ligne de code.

Mais on va détailler un peu et écrire les briques séparément en suivant les trois actes précitées.

Acte1: Dessiner une route

A l'aide du java DSL (Domain Specific Language), écrivons une première classe MyFirstRoute qui déclare une route Camel:

package fr.netapsys.camel.routes;
import org.apache.camel.Exchange;
import org.apache.camel.builder.RouteBuilder;

public class MyFirstRoute extends RouteBuilder {
  @Override
  public void configure() throws Exception {
    from("direct://aa").to("log:fr.netapsys.camel?level=DEBUG").end();
 }
}

Noter que MyFirstRoute hérite de RouteBuilder d'où la méthode configure() surchargée.

Le "from" précise le endpoint d'entrée qui est un composant Camel DirectComponent.

Le "direct://aa" veut dire simplement que la route démarre avec un DirectEndpoint nommé "aa".

DirectEndpoint assure une communication synchronisée.

Pour envoyer un message à "direct://aa", il faudrait instancier un ProducerTemplate puis appeler l'une des méthodes sendXXXX.

Le "to" indique que c'est vers le composant log que le message sera transmis.

L'URI du composant log d'Apache Camel a le format suivant:

log:loggingCategory[?options]

L'option, level=DEBUG, de notre cas indique le niveau DEBUG associé au logger (catégorie) "fr.netapsys.camel". Voir la documentation de log4j.

Nous venons de dessiner une route Camel qui a deux endpoints.

L'une d'entrée "direct://aa" et l'autre est le composant log.

Il ne reste qu'à envoyer un message à "direct:/:aa" et il sera loggué. C'est ce que nous ferons dans le test JUnit (acte3).

Il est temps de configurer le contexte Camel dans Spring.

Acte2: Configurer Spring

Le fichier spring doit par convention être localisé dans META-INF/spring et nommé camel-context.xml.

En respectant cette convention, Spring charge automatiquement le contexte Camel et le démarre.

Voici les quelques lignes xml valables pour toutes les démos:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xmlns:camel="http://camel.apache.org/schema/spring"
  xsi:schemaLocation="
  http://www.springframework.org/schema/beans 
  http://www.springframework.org/schema/beans/spring-beans.xsd
  http://camel.apache.org/schema/spring 
  http://camel.apache.org/schema/spring/camel-spring.xsd">	
  
<context:component-scan base-package="fr.netapsys.camel"/>
 <camel:camelContext
	xmlns="http://camel.apache.org/schema/spring">
     <camel:package>fr.netapsys.camel.routes</camel:package>	
</camel:camelContext>

Explications:

Nous avons déclaré dans camelContext le package où sont déclarées nos routes camel.

Et context:componet-scan permet à spring d'auto-injecter les beans (ex. les processors).

C'est tout!

Acte3: Écrire le test Junit

Le code du test JUnit est :

package fr.netapsys.camel.tests;
import org.apache.camel.ProducerTemplate;

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration({"classpath:META-INF/spring/camel-context.xml"})
public class TestMyFirstRoute {
 @Autowired CamelContext camelCtx;
 @Test
 public void testCamel() throws Exception {		
  ProducerTemplate template=camelCtx.createProducerTemplate();		
     //send msg to log
     template.sendBody("direct://aa", "\nloggue moi  \n");
  }
}

Explications:

Camel étant configuré dans Spring, le contexte Camel est démarré automatiquement, il suffit d'injecter (via @Autowired) une instance de CamelContext.

Avec l'instance camelContext, on peut créer un ProducerTemplate: une template à la sauce de spring facilitant l'envoi de message.

La méthode sendBody utilisée ici attend deux arguments: Un endpoint et un body de l'exchange (message).

Ici, on lui a passé les deux arguments "direct://aa" et le contenu du message qui est un String.

Un point de vigilance est de reprendre le endpoint direct://aa tel qu'il a été déclaré dans la route Camel.

Enfin, la commande mvn test affiche la sortie sur la console dos:

Running fr.netapsys.camel.tests.TestMyFirstRoute
xxxxxx camel [DEBUG] Exchange[ExchangePattern:InOnly, 
   BodyType:String, Body: loggue moi]

REMARQUE IMPORTANTE

Le même résultat aurait pu être obtenu avec la configuration suivante de notre route:

 from("direct://log")
  .log(LoggingLevel.DEBUG,"fr.netapsys.camel","${body}")
  .end();

Et le test JUnit devient:

template.sendBody("direct://log","loggue moi");

DEUXIEME DEMO: Transformer les données vers un fichier

Dans la classe MySecondRoute, la route trace l'enchainement suivant:

- Le direct endpoint "direct://a" est celui qui réceptionne le message,

- Une transformation simple est opérée sur le message,

- Une conversion du message selon un encodage prédéfini,

- Sauvegarde du message dans un fichier.

En résumé on a donc cet enchainement:

uriDirect -> Processor (transformation) -> Encodage ->uriFile.

Acte1: Dessiner une route

Voici la classe MySecondRoute qui hérite de RouteBuilder et définit la méthode configure():

package fr.netapsys.camel.routes;
import org.apache.camel.Exchange;
import org.apache.camel.builder.RouteBuilder;

public class MySecondRoute extends RouteBuilder {
  @Override
  public void configure() throws Exception {
    from("direct://starting")
     .transform().simple("Bonjour,\n ${in.body} \nSincères salutations")
     .convertBodyTo(String.class,"iso-8859-1")
     .setHeader(Exchange.FILE_NAME, constant("camelroute2.txt"))     
     .to("file:/temp/?fileExist=Override")
     .end();
  }
}

Les déclarations importantes ici sont:

- Un DirectEndpoint nommé "//starting",

- Une transformation simple du message est effectué à l'aide de la méthode transform,

- Une conversion du code en String avec l'encodage iso-8859-1,

- Un FileEndpoint avec son header qui fixe le nom du fichier où stocker le message. L'option fileExist permet d'écraser le fichier s'il existe.

Acte2: Configurer Spring

Rien à faire si la route est déclarée dans le package fr.netapsys.camel.routes.

Acte3: Tester avec JUnit

package fr.netapsys.camel.tests;
import org.apache.camel.ProducerTemplate;
import org.junit.Test;

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration({"classpath:META-INF/spring/camel-context.xml"})
public class TestMySecondeRoute{
@Autowired CamelContext camelCtx;
@Test
public void testCamel() throws Exception {		
 ProducerTemplate template=camelCtx.createProducerTemplate();
 template.sendBody("direct://starting",
  "\nMonsieur Néçàn\nNous avons bien reçu votre demande...\nblabla\n");
 }
}

La commande mvn test produira un fichier nommé camelroute2.txt dans le répertoire /temp.

TROISIEME DEMO: Exécuter script shell: Niveau avancé

L'objet de cette démo avancée est de pouvoir envoyer des commandes batch windows.

Le canal d'entrée attend un message (body) ayant le format suivant:

RepertoireExec;commande;optionCmd

Noter que le séparateur est un point virgule.

En résumé la route est composée de cet enchainement:

uriDirect -> Processor1 ->uriExecShell ->Processor2 -> uriFile.

La suite dans la prochaine partie.