La version 1.0 a été annoncé en décembre dernier, Mark Fisher propose de vous montrer en 10 minutes comment écrire un service simple et faire fonctionner Spring Integration : http://blog.springsource.com/2009/02/13/982/.

Dans son post dont j’ai repris le code ci-dessous, nous déclarons un bean Spring et nous allons montrer comment envoyer un message via Spring Integration.

La configuration Spring importe le namespace de Spring Integration et permet de déclarer le bean Shouter :
 

<?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:si="http://www.springframework.org/schema/integration"
xsi:schemaLocation="

http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans.xsd

http://www.springframework.org/schema/integration

http://www.springframework.org/schema/integration/spring-integration-1.0.xsd">

<si:channel id="input"/>

<si:channel id="output">
<si:queue capacity="10"/>
</si:channel>

<si:service-activator input-channel="input" output-channel="output" ref="shouter" method="shout"/>

<bean id="shouter" class="blog.Shouter"/>

</beans>

Voyons le bean Java qui va recevoir notre message et y ajouter des points d’exclamation:

public class Shouter {
    public String shout(String s) {
        return s.toUpperCase().concat("!!!");
    }
}

Le code Java pour tester le tout est simple :

public static void main(String[] args) {
    ApplicationContext context = new ClassPathXmlApplicationContext("blog/config.xml");
    MessageChannel input = (MessageChannel) context.getBean("input");
    PollableChannel output = (PollableChannel) context.getBean("output");

    input.send(new StringMessage("Le Touilleur Express"));
    Message< ?> reply = output.receive();

    System.out.println("received: " + reply);
}

A quoi sert Spring Integration ?
Spring Integration permet de réduire le code technique de votre application. Vous lisez un message sur une queue JMS, vous voulez envoyer un email, vous souhaitez lire un fichier et le convertir vers un autre format, faire un traitement par batch, télécharger via FTP un fichier ou SSH, alors Spring Integration pourra vous intéresser.

Peut-on comparer Spring Integration à Mule ?
Pour qui connaît un peu Mule 2, la ressemblance est frappante. Ross Mason, l’auteur de Mule, a tenté un moment de se rapprocher de la communauté Spring, mais celle-ci a préféré offrir une solution basée exclusivement sur Spring. Il n’y a pas de comparaison possible au sens « l’un est mieux que l’autre ». Mule a cependant un peu plus de recul, dispose de beaucoup plus de connecteurs que Spring Integration pour l’instant. Sa communauté est assez active. Si vous souhaitez utiliser par exemple Tibco Rendezvous ou faire du SSH, il faudra utiliser Mule.
Je pense qu’il est intéressant de connaître les deux projets et de ne pas s’aventurer à faire un choix, s’il faut en faire un.

Est-ce que Spring Integration est un ESB ?
Non, je dirai que c’est un framework léger d’intégration comme Apache Camel, mais pas un ESB. Le produit OpenESB basé sur le serveur d’application Glassfish est un ESB, car il est composé d’une API d’une part et d’un moteur d’autre part. Mule est un ESB léger, il propose son propre moteur ou il peut fonctionner dans une application Web. Spring Integration est par contre une brique peut-être plus facile à mettre en oeuvre si vos besoins sont avant tout techniques.

Pour aller plus loin
Le site de la communauté muleForge : http://www.muleforge.org/
Le site de Mule 2 : http://www.mulesource.org
Article de Cyrille Le Clerc sur le blog de Xebia en 2007
Article de Sébastien Letélié d’Improve sur les ESB : Java Camp II DB and ESB

1. ESB in Financial Application

2. Objectif de la présentation

En quinze minutes, l’idée de cette présentation est d’expliquer les besoins rencontrés dans le monde de la finance en terme d’architecture. Où en sommes-nous aujourd’hui et quels outils pouvons-nous utiliser afin de réduire les coûts et améliorer nos architectures ?

3. Speaker’s Qualifications

Après 5 ans 1/2 chez Reuters, j’ai débuté une nouvelle activité en tant qu’indépendant. Je travaille actuellement chez BNP-Paribas sur une mission d’architecture. Je suis membre du Paris Java User Group.

4. ESB

ESB. Ce mot est à la mode. A Devoxx j’ai compté 4 conférences cette année. Mule est traité 3 fois par Antoine Borg avec qui j’ai eu le plaisir de discuter la veille, bref il se passe quelque chose. A noter qu’aucune conférence ne nous parle de téléphone portable, les thèmes cette année tournent autour de l’intégration, de la sécurité ou de SOA. Voyons un peu « dans la vraie vie » où nous en sommes aujourd’hui, car moi, plutôt que de parler de SOA ou d’ESB, j’aime bien parler du terrain avant tout.

5. A legacy application

Ce que l’on constate c’est que les applications vieillissantes dans le monde Java des applications de gestion et de la finance, se présentent avec un socle d’architecture bien connu. Autour d’une architecture trois-tiers, nous retrouvons souvent du Struts pour la partie Web, un serveur d’application avec encore beaucoup d’EJB 2.1, et les innovations des dernières années que sont Hibernate, Spring et JMS. Et il est clair que ce type d’architecture aujourd’hui en production est encore amené à perdurer pour quelques années.
Votre travail sera donc de faire vivre, d’améliorer ou de transformer ce type d’architecture.

6. A legacy application (cont.)

Dans la finance, une application web communique et échange des ressources avec le monde extérieur en utilisant un certain nombre de connecteurs techniques (boîtes vertes). Ce code est bien souvent du code développé au fur et à mesure des besoins. Il peut s’agir de lire un fichier, d’échanger via JMS avec une autre application, de faire appel à un web service, ou d’envoyer un email. Bref, du code massivement technique. Ce code est le socle de communication de chaque application de gestion.

7. Connect

Connecter.
Le besoin de Connecter différents systèmes. Ce besoin entraine un travail de médiation, de transformation et d’interconnexion entre systèmes. Je veux montrer ici qu’il y a forcément un besoin de connexion, au minimum avec une base de données relationnelles, mais bien souvent avec d’autres systèmes informatiques ou techniques. C’est une composante fondamentale de nos solutions, de ce que nous sommes appelés à développer.

8. Ecosystem

J’ai représenté sur ce slide une application financière typique de création de rapports, utilisé sur une plateforme de Prime Brokerage. Ce que nous voyons tout d’abord, c’est que cette application a besoin d’un environnement pour fonctionner, un écosystème. Cet écosystème est composé d’un grand nombre d’applications, maintenu par d’autres équipes que la mienne.
Mon application est représentée au milieu avec ses 3 services internes.

9. Ecosystem 2

Cette application utilise les données du marché ainsi qu’un service de tenue de Position. Aujourd’hui les échanges entre les systèmes s’effectuent avec des fichiers plats via des répertoires partagés ou via JMS. Dans le livre Enterprise Integration Pattern, une excellente présentation explique les avantages et les inconvénients de ces 2 types d’échange.

10. Ecosystem 3

Au delà des échanges de mon application, ce qui est encore plus intéressant c’est de constater que les autres applications échangent elles-aussi des informations entre elles. Il faut donc bien voir que nous sommes là face à un vrai réseau de communication, de médiation et d’échanges. C’est le coeur d’une architecture financière.

11. Ecosystem 4

Au final je dois prendre en compte que mon application cohabite, échange et transfert ses données avec un nombre assez important d’applications. Je ne rentre pas dans les détails de la partie métier, car l’idée ici n’est pas de vous donner un cours de finance des marchés, simplement d’expliquer que les systèmes sont massivement connectés en un réseau.

12. Ecosystem 5

… En forçant un peu le trait, je peux faire une analogie avec un réseau social comme FaceBook : mon application fait partie d’un réseau, d’autres applications m’envoient des messages, observent même les données que je produis sans que je ne le sache, il y a donc clairement un besoin important à résoudre : ce besoin de communication et d’échanges avec mes « amis ».

13. Collaborate

Collaborate en anglais, difficile à traduire avec le même sens en français.
Collaborer c’est apprendre à se connaître : lorsque mon application échange avec d’autres systèmes financiers, au delà du problème technique à résoudre il y aura une interaction humaine. Et donc, ESB ou non, SOA ou non, ce projet d’inter-communication doit s’accompagner de la définition d’une langue pour se comprendre, d’un média pour discuter et d’un contenu pour s’entendre.
Revenons un peu à notre application financière type pour parler d’un facteur très important : le temps.

14. Timebox and Adaptive

J’ai sélectionné ces deux photos du métro afin d’illustrer un facteur important dans les applications financières : l’importance de l’heure de la journée. Prenons le métro de Paris : le matin entre 07h00 et 09h00 il y a un métro chaque minute. A 14h il y a un métro toutes les 6 minutes. A 23h00 il y a une rame toutes les 15 minutes.
Le nombre de rame de métro par heure s’adapte selon les heures d’affluence.
Qu’en est-il de mon application financière ?
Chaque matin celle-ci a besoin de 10 fois plus de puissance qu’en pleine journée, car la génération des rapports doit s’effectuer à la fermeture du marché boursier, dans un intervalle de temps limité. Il n’est pas possible de lancer la génération tant que le marché est ouvert. D’autre part celle-ci doit s’effectuer avant l’ouverture du marché suivant, en Asie. De fait, nous nous retrouvons avec une architecture qui doit répondre à des demandes fluctuantes selon l’heure de la journée.
Mais le plus important est que notre application n’a pas le droit à une deuxième chance. Lorsqu’un bug survient, il faut que l’erreur soit corrigée avant l’ouverture du marché, et ce phénomène n’est pas contrôlable.
Enfin on constate que passé les quelques heures d’activité, la plateforme est ensuite peu sollicité en cours de journée.
Or le souci, c’est qu’aujourd’hui mon architecture n’est pas écologique : 16 serveurs de calcul de risk tournent en permanence, 4 serveurs d’applications sont sollicités pendant la journée mais l’utilisation des ressources est assez inégale durant la journée.
Il faut donc retenir que dans la finance, l’utilisation des ressources et la quantité des échanges avec les autres systèmes varient au cours de la journée. Cependant nous savons à l’avance nos besoins, et donc idéalement notre système devrait pouvoir s’adapter et se programmer comme le réseau de transport parisien.
Un site internet qui vend des ordinateurs pourrait être surpris de l’affluence de visiteur. Pas une application financière : il est possible de connaître à l’avance les besoins en énergie. Mais pourtant, il est difficile aujourd’hui de régler et d’adapter cette énergie.

15. Crisis

2008 marque le début d’une crise financière, qui aura un impact dès demain sur les budgets des projets dans le monde de la banque et de la finance. Nos besoins de connexions avec les autres applications financières demeurent. Je pense même qu’il y aura de nouvelles réglementations pour éviter certains dérapages de 2008. Vu la nervosité des marchés financiers, les calculs de VaR, de risque, d’appel de marge, de collatéral sur notre application de Prime Brokerage vont aussi certainement être plus intensif… Bref il va y avoir du sport en 2009.

16. Predictions for 2009

ll est donc facile d’imaginer ce qui nous attend : avec moins de budget, moins de liberté et plus de pressions, il va falloir trouver des solutions rapides, économiques et capables de faire réaliser des économies. Pour ma part, un calcul de risque c’est un appel de marge pour un client. Si la plate-forme sur laquelle je travaille peut traiter 50 000 calculs au lieu de 10 000 car mon architecture évolue, alors je ferai gagner de l’argent à mon client.
D’autre part, vu la morosité et la crise du secteur de la finance, je pense que les solutions pragmatiques seront les gagnantes de 2009. J’ai peur que de gros projets basés sur les ESB des constructeurs souffrent du même phénomène que les constructeurs automobiles. Les gens veulent une voiture ? ils achètent une Logan et pas le dernier 4×4 à la mode.
Votre application a besoin d’un ESB ? Peut-être que Spring Integration, Mule ou Apache ServiceMix seront suffisants pour vos besoins, que les gros projets sur 6 mois auront plus de mal en 2009 à être validé par les DSI. Il est temps d’être pragmatique et d’arrêter de rêver sur des besoins que les grands éditeurs d’ESB nous ont peut-être inventé, comme les éditeurs de serveur d’app en 2000… Etre pragmatique, économe, écologique, réaliste.

17. Toolbox

En 2009 je pense que vous lirez des articles, que vous testerez, que vous entendrez parler de ces produits : Mule, Apache Service Mix, Apache Camel, Spring Integration, OpenESB project Fuji, Apache Synapse, Apache CXF, Jboss ESB… car ce sont des solutions qui répondent à un besoin : l’intégration légère en entreprise.
Après la guerre des serveurs d’application il y a quelques années, je pense que la prochaine grande bataille sera sur ce front. Les éditeurs du monde open-source savent que la demande va exploser, car lorsque la crise est là comme en 2001, le monde open-source tire son épingle du jeu. En 2002 personne ne se souvient mais c’était la grande époque des articles sur Linux dans 01 informatique, le Monde informatique ect. L’administration français a alors fait un grand pas en sélectionnant des solutions comme JBoss Application Server pour traiter… nos déclarations de revenus.
Economies, pragmatismes, simplifications, réductions des coûts…

18. A New Approach

Alors si nous repensons à notre application de gestion du début, voici comment je la vois en 2009. Tout d’abord le Web tiers a été déporté de mon architecture. Je ne fais pas une application Web, je fais d’abord l’architecture d’une application de gestion. Le web ne me coûte pas cher, j’utilise des frameworks légers sur une recopie en lecture seule de ma base de données. Seule une petite partie du code métier est partagée avec mon espace de données principal.
Ensuite on voit que j’ai cassé ce gros rectangle : je pense que des services sans états et légers sont suffisants pour effectuer les traitements de mon application. Là où auparavant j’utilisais la base de données pour stocker des données de travail, j’utilise désormais un espace mémoire en cluster afin de répliquer les données nécessaires à mes traitements de calculs. Cela demande plus de mémoire physique mais quintuple les performances de traitements. La base de données relationnelle n’intervient que via un service d’historisation qui effectue des captures de données afin de sauvegarder les données les plus sensibles, essentiellement pour un problème légal. Notez que la base est un petit carré bleu, car finalement elle ne me sert plus à grand chose.
Ces services reprennent la boîte à outil dont nous avons parlé tout à l’heure. Plutôt que de chercher à faire une grosse boite qui fait tout (un ESB au sens de certains) je crée un ensemble de services qui discutent et s’échangent des données. Et plutôt que de tenter de résoudre les problèmes de communication avec les applications extérieurs, de tenter de mettre en place un gros chantier afin de mettre tout le monde sur la même plateforme, je conserve et respecte les systèmes extérieurs, je m’adapte à eux, eux ne s’adaptent pas à moi. Et là je sais que mon application pour 2009 pourra continuer à exister sans couter une fortune.
Il faut donc oublier ce rêve qui serait de migrer toutes les applications de mon réseau vers un seul et même système. Ce serait un risque si l’éditeur disparaît (ce qui n’est pas exclu en ce moment). Ce serait la plus belle décision pour dégrader massivement les performances : pourquoi un système extérieure serait plus rapide que ce que mes équipes ont développé ? Ce serait un risque technique, un risque en terme de sécurité, et finalement, il faudrait attendre 6 mois avant de voir ce type de projet de gouvernance sur les rails.

Pour revenir à l’image du métro parisien, je rêve aussi de louer de la puissance machine plutôt que de l’acheter en utilisant par exemple Amazon EC2 et une solution comme Elastic Grid pour piloter mon parc informatique. Pour cette raison mon nouveau système est découpé en services sans état afin de faciliter une migration partielle et rapide de certains services vers ces nouvelles plate-formes de calculs et d’hébergement. La première banque qui aura déployé une plateforme de calcul de risque hostée comme un service sur internet gagnera certainement beaucoup d’argent.
Economies, pragmatismes, simples, réduire les coûts, arrêter de croire au père noël, pensez sur 6 mois…

Code code code
Ensuite j’ai un slide technique pour montrer un exemple d’utilisation d’Apache Camel. Lors de la conférence je n’ai pas eu assez de temps pour les présenter. Je vous ferrai un article complet sur Camel prochainement, donc revenez en janvier pour voir la suite.

Keep it simple

Pour connecter plusieurs systèmes il est tentant de faire n’importe quoi, de faire au plus vite ou de chercher une solution chère et trop complexe pour un problème. Soyez simple et vous réussirez à développer une architecture qui fonctionne.

Ne pas faire de l’intégration pour en faire…
Comme ces messieurs dans la piscine : ne cherchez pas à faire de l’ESB pour en faire, et faites attention à votre environnement. Un ESB ne remplace pas une réunion de pilotage avec l’autre équipe en face qui fait « l’autre » produit.

Don’t buy a solution

N’achetez pas les yeux fermés une solution. Au contraire, il faut que vos équipes retroussent leurs manches, repensez à des solutions simples. Dans le monde des applications de gestion, et de la Finance, le temps est certes à l’économie, mais aussi à un pragmatisme souvent contraire à nos envies d’architectes et de consultants.

The End

En conclusion : nous avons discuté des besoins en architecture dans le monde de la finance : connecter, échanger et collaborer, inter-agir avec d’autres systèmes. Les solutions d’intégrations légères seront en 2009 un moyen de réduire les coûts en évitant d’écrire à la main du code technique sans valeur ajoutée. Je souhaite dépiler un message JMS et envoyer un email, Mule m’aide à le faire en quelques heures au lieu de perdre mon temps avec du code sans valeur. Face aux réductions de budgets, il est logique de penser que les solutions d’intégration dans la finance auront le vent en poupe en 2009. Et face à cette crise, il y aura encore plus de travail pour nous, avec encore moins de budgets, d’où la nécessité de s’outiller enfin correctement.

Fin de la présentation
————————————————

La version Entreprise de Mule propose un exemple complet d’utilisation du connecteur JDBC. Le code source de cet exemple n’étant pas distribuable ni libre de droits, je vous propose dans cet article un exemple simple dans lequel je vais lire un fichier texte de type CSV, le transformer puis ensuite l’importer dans une base HSQLDB.

Cet exemple vous montre comment écrire un transformer, déclarer le connecteur JDBC de Mule puis enfin mette en oeuvre le tout.

Installation de Mule

Téléchargez la version de Mule 2.1.2 via le site de Mule
Décompressez dans un répertoire l’archive
Déclarer une variable d’environnement MULE_HOME
Mettez à jour le script startMule.sh donné avec l’archive à la fin de cette article pour pointer vers le bon répertoire de Mule.

Mise en place de la base de données

Dans un premier temps, si vous souhaitez tester par vous même, téléchargez l’archive suivante « mule-poc.tar.gz ». Je vous ai préparé une arborescence avec l’ensemble du code source. Le répertoire database contient de quoi créer une base HSQLDB en mémoire mais autonome, car déclarée sous la forme serveur.
HSQLDB nécessite un fichier « sqltools.rc » pour que le mode serveur autorise des connexions sur le serveur. Pour cela, copiez le fichier sqltools.rc vers votre répertoire $HOME (ou C:\Document and Settings\)
Le script startDBServer.sh assume que Java 5 ou 6 se trouve dans le Path, et démarre le serveur HSQLDB. N’étant pas un expert HSQLDB, j’ai fait au plus simple.
Le script createDatabase.sql sera exécuté via le script shell « createDatabase.sh » afin d’importer le contenu du fichier sample.dsv.

Structure simple de la base

L’unique table de la base est vraiment ce qu’il y a de plus simple, il n’y a pas d’index ni de clé primaire. Simplement des types Date, boolean, int et Varchar afin de montrer les capacités de transtypage de Mule.

CREATE TABLE sampletable(id INT, lastUpdate DATE NOT NULL, msg VARCHAR, isValid BOOLEAN);


Le fichier de configuration de Mule

Le fichier de configuration de Mule est le coeur du système. Basé sur Spring, Mule partage des concepts de Spring 2.5 qui en font un système très facile à apprendre. Contrairement à une solution basée sur Spring Integration, vous verrez qu’ici je ne vais écrire qu’une seule classe Java. J’aimerai refaire le même exemple avec Spring Integration plus tard afin de comparer.

L’entête du fichier déclare les namespaces des connecteurs file, stdio, vm et jdbc ainsi que les entêtes pour Spring.

<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns="http://www.mulesource.org/schema/mule/core/2.1"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:spring="http://www.springframework.org/schema/beans"
      xmlns:context="http://www.springframework.org/schema/context"
      xmlns:file="http://www.mulesource.org/schema/mule/file/2.1"
      xmlns:stdio="http://www.mulesource.org/schema/mule/stdio/2.1"
      xmlns:vm="http://www.mulesource.org/schema/mule/vm/2.1"
      xmlns:jdbc="http://www.mulesource.org/schema/mule/jdbc/2.1"
      xsi:schemaLocation="
       http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
       http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd
       http://www.mulesource.org/schema/mule/core/2.1 http://www.mulesource.org/schema/mule/core/2.1/mule.xsd
       http://www.mulesource.org/schema/mule/file/2.1 http://www.mulesource.org/schema/mule/file/2.1/mule-file.xsd
       http://www.mulesource.org/schema/mule/vm/2.1 http://www.mulesource.org/schema/mule/vm/2.1/mule-vm.xsd
       http://www.mulesource.org/schema/mule/stdio/2.1 http://www.mulesource.org/schema/mule/stdio/2.1/mule-stdio.xsd
       http://www.mulesource.org/schema/mule/file/2.1 http://www.mulesource.org/schema/mule/file/2.1/mule-file.xsd
       http://www.mulesource.org/schema/mule/jdbc/2.1 http://www.mulesource.org/schema/mule/jdbc/2.1/mule-jdbc.xsd">

Ensuite je déclare simplement un DriverManagerDataSource en utilisant la base HSQLDB démarrée sur mon serveur. Le login par défaut est ‘sa’ et il n’y a pas de mot de passe.

    <spring:bean id="touilleurDB"
                 class="org.springframework.jdbc.datasource.DriverManagerDataSource">
        <spring:property name="driverClassName"
                         value="org.hsqldb.jdbcDriver"/>
        <spring:property name="url"
                         value="jdbc:hsqldb:hsql://localhost"/>
        <spring:property name="username" value="sa"/>
        <spring:property name="password" value=""/>
    </spring:bean>

Je déclare ensuite un connecteur mule de type JDBC avec pour datasource-ref, mon bean « touilleurDB ».
Dans ce connecteur vous pouvez déclarer 3 types de requêtes, je ne déclare ici qu’une requête d’insertion appelée « writeTest ». Cette requête va recevoir une List de Map. Chaque élément de la List correspond à une ligne de fichier. Chaque élément de la ligne séparé par des virgules, sera enregistré dans une Map. J’y reviens plus loin.
La lecture des arguments utilise ici map-payload, l’une des techniques de Mule pour récupérer des couples clés-valeurs facilement.

Une fois cette requête « writeTest » déclarée, elle est alors disponible pour mon service Mule

    <jdbc:connector name="myJdbcConnector"
                    dataSource-ref="touilleurDB"
                    pollingFrequency="1000">
        <jdbc:query key="writeTest"
                    value="INSERT INTO SAMPLETABLE (ID, lastUpdate, msg, isValid) VALUES (#[map-payload:id], #[map-payload:lastUpdated], #[map-payload:msg], #[map-payload:isValid])"/>
    </jdbc:connector>

Je déclare ensuite 1 transformer :

    <custom-transformer name="StringToListOfMap" class="com.innoteria.mule.simple.StringToListOfMap"/>

Le code de la classe StringToListOfMap n’est pas très élégant mais l’intérêt ici est de vous expliquer le principe, pas de vous donner un cours de Java. Mule lit un fichier texte simple et par défaut transforme son contenu en une String. A noter que ce comportement est bien entendu désactivable mais ici il me rend service car mon transformer reçoit directement une String contenant tout le fichier. Je vais ensuite iterer et créer une Map clé-valeur correspondant aux paramètres de ma requête « writeTest » précédemment déclarée.
Enfin je mets chacune de mes Map dans une List pour ensuite utiliser l’encoding transformer map-payload

public class StringToListOfMap extends AbstractTransformer {

    @Override
    protected Object doTransform(Object src, String encoding) throws TransformerException {
        String payload = (String) src;

        if (payload == null) return null;
        StringTokenizer stLine = new StringTokenizer(payload, "\n");

        String line;
        Map m;
        List resultList=new ArrayList();
        StringTokenizer st;
        while (stLine.hasMoreTokens()) {
            line=stLine.nextToken();
            st=new StringTokenizer(line,",");
            m = new HashMap();
            m.put("id", st.nextToken());
            m.put("lastUpdated", st.nextToken());
            m.put("msg", st.nextToken());
            m.put("valid", st.nextToken());
            resultList.add(m);

        }
        return resultList;

    }
}

Pour terminer la configuration de mon service Mule, je déclare ensuite un connecteur de type file. L’instance de Mule va scruter le répertoire out/source. Dès qu’un fichier y sera déposé, il sera lu et transformé ensuite via notre transformer « StringToListOfMap » dont nous venons de voir le code.

<model name="fromFileToDatabase">
  <service name="myImportService">
    <inbound>
       <file:inbound-endpoint path="/Users/nicolas/Dev/mule-poc/out/source"
                  pollingFrequency="3000" fileAge="5000"
                  moveToDirectory="/Users/nicolas/Dev/mule-poc/out/destination"
                  transformer-refs="StringToListOfMap">
       </file:inbound-endpoint>
   </inbound>
   ...
   ...

Je n’utilise aucuns composants particuliers. Il est temps de déclarer maintenant un outbound endpoint de type JDBC, utilisant notre query « writeTest ». La seule chose un peu spéciale est que j’utilise ici un list-message-splitter-router. Celui-ci prend en entrée une List d’élément et va automatiquement itérer cette List pour passer ensuite chacun des éléments au « jdbc:outbound-endpoint » en l’occurence une Map.

En cas d’exceptions je route les messages vers la sortie standard. Je pourrai aussi sauver vers un fichier les entrées invalides de mon fichier CSV.

 <echo-component/>
   <outbound>
        <list-message-splitter-router>
            <jdbc:outbound-endpoint queryKey="writeTest">
                <payload-type-filter expectedType="java.util.Map"/>
            </jdbc:outbound-endpoint>

            <payload-type-filter expectedType="java.util.List"/>
          </list-message-splitter-router>
        </outbound>

        <default-connector-exception-strategy>
                <outbound-endpoint address="stdio://OUT"/>
        </default-connector-exception-strategy>

     </service>
  </model>
</mule>

Une fois le tout compilé, je démarre mon instance de Mule via le script « startMuleServer.sh » en l’exécutant dans le répertoire bin.
A l’execution, si je dépose le fichier « testDatabase.txt » dans le répertoire out/source, Mule le charge et le message suivant s’affiche dans la console :

INFO 2008-12-23 15:24:48,927 [myImportService.2] org.mule.component.simple.LogComponent:
********************************************************************************
* Message received in service: myImportService. Content is: '0,2008-12-12,[Un *
* exemple de message tr?s simple],true *
* 1,2008-11-12,[Un autre exemple pour tester],fa...[100 of 141]' *
********************************************************************************


Un select dans la table retourne les 3 lignes du fichier testDatabase.txt comme attendu

Conclusion
Dans cet exemple nous avons vu comment lire un fichier texte simple, comment transformer son contenu pour ensuite insérer directement des entrées dans une base de données. Mule Enterprise Edition propose des connecteurs avancés pour les traitements par Batch, plus efficace que l’import utilisé ici. Par ailleurs il est aussi possible de configurer les pools de connections en se basant sur les méthodes Spring standards.
Mule est une solution qui évite l’écriture de code d’infrastructure, par essence du code souvent sans valeur ajouté. Cependant comme on peut le remarquer ici, il y a rapidement un besoin d’ajouter un peu de logique, ne serait-ce que pour la validation. Et cette logique s’écrit avec du code Java. J’ai aussi en stock un exemple avec Apache Camel, préparé pour Devoxx, que je vous proposerai prochainement dans un article sur le Touilleur.

Code source de l’exemple :
mule-poc-touilleur.tar.gz

Ross Mason a débuté le projet Mule en 2003. Avec un background en Finance et en Telco, Ross a débuté le projet Mule dans l’idée de créer un ESB open-source. Un ESB (Entreprise Service Bus) est un bus d’information, d’échange et de transformation de message. Mule remporte un succès car plus d’un million de téléchargement ont été effectués depuis la première version. 7 des 50 plus grosses entreprises dans le monde utilisent Mule. Il y a plus de 2500 développeurs sur les listes de diffusions, la communauté est donc active. 2000 applications sont en production avec Mule aujourd’hui.

La définition de Ross de Mule est « de permettre l’intégration de systèmes hétérogènes dans un même environnement ». Il s’agit de connecter différentes applications dont l’architecture est complétement différente. Un portail Web avec des sources de données. Des Services Adapters avec un bus de messagerie, etc.

Mule est composé d’un diffuseur de messages (Message Broker), d’un repository pour la configuration, d’un système de routage et de diffusions de messages, d’un moteur transactionnel, d’un moteur de transformation et enfin d’un moteur de gestion de workflow.

Mule peut donc recevoir un fichier, le transformer, diffuser via le routage des messages ou une partie de ce fichier à plusieurs applications, s’entourer d’une transaction pour réaliser le tout. La gestion de la sécurité est souple mais permet de gérer l’authentification et l’autorisation.

Pourquoi choisir Mule ?
Mule tout d’abord ne force pas un type de message. Que votre architecture se base sur l’échange de fichiers XML, CSV, d’objets sérialisés ou de flux binaires, le moteur de transformation de Mule permet d’ajouter ces différents formats.
Au niveau du code, Mule n’est pas intrusif et n’impose pas d’API externes. Les objets sont complètement portables, ce qui facilite les tests.
Le fait que Mule ne force pas le format des messages en fait un outil non compatible avec la spécification JBI de Java. Cependant je pense que c’est un avantage qui permet d’avoir un système plus ouvert. Renseignez-vous sur ce sujet, je n’ai pas plus creusé.

Mule a été comparé à un couteau suisse. Il offre un grand nombre d’architectures de services. ESB est l’une des topologies, mais Mule peut très bien faire du Client-Serveur par exemple, en se basant sur des échanges synchrones, asynchrones de type message ou de type commande (rpc). Pour cette raison c’est une solution souple.

Un service web de type requete-réponse synchrone peut ensuite faire suivre un message asynchrone à une Queue JMS par exemple. C’est le principe de Mule.

L’intégration avec l’architecture J2EE est optionnelle. Le support de JBI, JMS, EJB, des connecteurs JCA, de JTA et des Servlets permet à Mule de s’intégrer dans une architecture J2EE existante sans problèmes.

La partie routage des messages a été écrite en se basant sur le livre « Enterprise Integration Pattern » de Gregor Hohpe, , Bobby Woolf et Kyle Brown. C’est un livre de 2004 qui a encore beaucoup d’idées d’architecture simple.

La distribution transparente est une fonctionnalité de Mule qui permet de définir les règles d’échanges de messages dans la configuration. Ceci permet de faire des tests unitaires avec échanges de messages entre virtual machine, puis une fois en production d’utiliser un autre fichier de configuration avec des règles de distribution différentes. Très pratique dans le cadre des tests unitaires ou pour simuler (mock pattern) des interfaces clientes lorsque celles-ci ne sont pas disponibles. Pour la partie sécurité, Mule supporte JAAS ou Acegi pour l’authorisation.
Mule est capable de gérer des objets existants, des POJOs ou des EJBs. Enfin Mule est réputé pour faciliter les tests et un framework complémentaire à JUnit facilite l’écriture des tests.

L’architecture composant de Mule
Une instance de Mule est composée d’un Routeur entrant (Inbound Router), d’un composant unitaire (UMO Service Component) et enfin d’un Routeur sortant (Outbound Router).
Les routeurs sont connectés à différentes applications via des Channels. Un Channel peut être un client web service ou un fichier plat sur un répertoire par exemple.

Les nouveautés de Mule 2.0
La première nouveauté est un nouveau format de configuration XML basé sur des schémas, en lieu et place des anciennes DTD. Cela apporte pas mal de nouveautés pour la complétion de code dans IDEA IntelliJ par exemple. La configuration est plus simple et il n’est plus nécessaire de décrire toutes les classes. Un ensemble de XSD permet de simplifier la configuration des points d’entrées (endpoint).
Il est possible d’associer un Endpoint avec une méthode Java, via un Proxy Java. Il y a une Registry de configuration et donc il n’y a plus de Mule Manager. La gestion des messages a été améliorée. Un nouveau type de transformation peut être appliqué automatiquement lorsqu’un type de message est appelé. Mule peut prendre en charge certaines transformations simples.
Le Streaming est maintenant implicite pour les endpoints. Mule est gérable via JMX, ce qui facilite la gestion.

Mule est basé sur Spring pour sa partie configuration, cela se voit dès la lecture des fichiers de configuration. On retrouve l’idée de Spring 2.5. Son architecture est composée d’un Runtime Mule qui s’assure de la diffusion, de la gestion des Threads et des Transactions. La partie Transport supporte plus de 60 types différents. Cela inclus JMS, SOAP, Fichier plat, HTTP, FTP, SSH, JDBC, etc. La partie de routage permet l’échange de message. La partie transformation est capable d’effectuer un sacré nombre de tâches : XSLTC, CSV, Fix, ISO20022, Swift, objets Java… Il est possible d’appliquer un grand nombre de transformation.
Mule peut enfin démarrer un petit conteneur web pour simplifier la configuration.

Mule 2 configuration
Mule 2 se base sur le système de gestion d’espace de nomage de Spring 2. Chaque module a son propre espace de nom. Spring Bean peut être aussi ajouté dans la configuration de Mule 2. Le support de Seasar (sorte de Spring japonais) est aussi possible tout comme Hivemind ou Picocontainer.
La différence que j’ai vu entre Mule 1 et Mule 2 est que dans la première version de Mule, il fallait connaitre le nom des classes Mule pour déclarer les connecteurs. Mule 2 se basant sur des espaces de noms XML comme Spring, vous pouvez déclarer directement un attribut xml correspondant au connecteur qui vous intéresse. De plus les propriétés de chaque connecteur sont différentes selon le nom du module et la validation est possible dès l’écriture de votre configuration Mule.

Ensuite Ross présente un exemple simple de service Mule, qui permet de lire un message sur l’entrée standard pour créer un objet Order, puis ensuite d’appeler un service de gestion de la commande pour créer un objet ProcessedOrder.
Je retiens que Mule apporte toute la colle qui permet de créer le chemin suivant : lecture sur la console d’un message, transformation du message en objet Order, appel de la méthode process d’un service, récupération de l’objet ProcessedOrder et transformation de cette objet vers une String pour afficher un message de résultat. Le rôle de Mule via la configuration est donc de créer tous ces liens et d’orchestrer les appels des objets entre eux. Zéro ligne de code pour vous.

Ensuite un des intérêts ici est de montrer comment il est possible d’ajouter un nouveau point d’entrée sous la forme d’un service Web. Pour cela il déclare tout simplement une petite ligne dans le fichier de configuration, et via CXF un nouveau service web est automatiquement créé pour vous. Au lieu d’utiliser la console et l’entrée standard, vous pouvez maintenant appeler une méthode d’un service web pour refaire le même parcours.
Si je résume : Mule permet d’ajouter via une ligne de configuration un nouveau point d’entrée à votre application.

Il montre ensuite comment appeler un service de vérification de crédit durant la transaction. Lorsque la commande est créé, on souhaite effectuer un appel à un service HTTP distant capable de nous dire si la carte de crédit est créditrice ou non pour valider le paiement. Le service est modifié pour recevoir par injection un objet CreditChecker. Le code est vraiment simple et on ne voit aucunes informations de transport, il est impossible de voir qu’il s’agira d’un appel HTTP ou via un Web Service. Mule crée du code agnostique et la partie transport/communication est masquée de son côté. Cela facilite en effet les tests unitaires.

Il montre ensuite un nouveau système d’extraction et de création des propriétés à l’execution. L’exemple qu’il montre est l’envoi d’un email à un destinataire, l’email est extrait avec une expression XPath à l’exécution.

Autres nouveautés
Mule 2 a été réécrit pour faciliter la gestion des clusters. Mule 2 est prêt aussi à fonctionner avec OSGi car cela permettra d’apporter la gestion de version d’OSGi à Mule, ainsi que le déploiement à chaud. La gestion de version permettrait de ne redéployer qu’une partie de votre application et de ne mettre à jour que ce qui est nécessaire.

La gestion du Streaming
Mule 2 est capable de gérer de gros volumes de données sans essayer de tout charger en mémoire. C’est indispensable par exemple lors de la génération de rapports financiers. Les données étant énormes, lorsque nous avons travaillé avec Kocktail chez Reuters je me souviens que cette partie était délicate. Si c’était à refaire aujourd’hui, je serai tenté de regarder si Mule ne peut pas aider et faciliter l’architecture de ce composant. Hasan si tu me lis… tu sais quoi faire.

La gestion des erreurs
La gestion des exceptions est importante car pour la gestion des connecteurs c’est ce qui apporte des règles de tolérance de pannes. Pour les exceptions des connecteurs (un service web distant est tombé…) il est possible de configurer dans Mule des règles de routage différente pour gérer les problèmes réseaux par exemple. JMX permet de surveiller un composant Mule afin de détecter des pannes, chose importante pour l’exploitation et les équipes de production (spéciale dédicace à Gik de l’INA).

Les transactions
A mon avis c’est la partie la plus délicate de Mule. Tout se configure via les fichiers de configuration. Mule supporte les transactions de type Local ou XA. Plusieurs serveurs d’applications sont supportés comme Weblogic ou JBoss. Le support d’Arjuna ou Atomika est aussi possible. Mule peut utiliser les gestionnaires de transaction des serveurs d’application comme Weblogic par exemple, en passant via JNDI pour retrouver le gestionnaire de transaction.

La montée en charge
Dans ce slide, Ross explique pourquoi Mule est scalable. Mule est basé sur le modèle SEDA (Straged Event Driven Architecture).
Je fais une aparté pour parler de SEDA, ou de ce que j’en ai retenu en lisant le PDF.
Le problème : comment gérer un grand nombre de requêtes dans un serveur ? Quelle est la meilleur architecture pour traiter 1000 requêtes à la fois ?

Tout d’abord voyons l’architecture multi-threadée classique :
Un serveur Web classique peut par exemple démarrer une thread par requête. Si cela semble une bonne idée au premier abord, charger une image du disque ou faire un appel dynamique à un EJB ne coûte pas la même énergie. Et ce modèle threadé est donc « bête » car il consomme des Threads pour des choses simples. Pour répondre à cela, est apparu les modèles orientés événement comme celui au coeur de Flash. A chaque événement système un ordonnanceur envoie des événements à un nombre limité de threads qui gérent une machine à état. Imaginez la distribution de cartes dans une partie de Poket. Il y a 5 joueurs et le donneur donne des cartes. Certains joueurs vont terminer le boulot avant les autres (se coucher…) et d’autres vont travailler plus longtemps. Le souci de cette 2ème architecture de distribution est que l’on assume que la lecture des événements n’est pas bloquant. En clair, cela veut dire que lorsque je distribue les cartes, mes joueurs ne me bloquent pas et je passe au joueur suivant. Or c’est parfois difficile en vrai. De plus, si l’une de mes Threads prend 90% du CPU pendant que je distribue mes tâches, je suis impacté et toute l’application se met à ramer.
Pour revenir à mon exemple avec le poker, la limitation de l’architecture orienté message est que lorsque l’ordonnanceur (le donneur) distribue les cartes il n’attend pas la réponse de chaque joueur et donc il va très vite, sans s’arrêter. Si ensuite il doit être bloqué par un joueur, comme lorsqu’il demande ce que veut faire le joueur, alors le modèle est bloqué. Donc ce type de distribution des tâches fonctionne tant que les machines à état ne bloquent pas le scheduler.
Pour cette raison, SEDA propose une 3ème architecture. Tout d’abord on ajoute la notion d’étape, pour que la gestion d’un événement soit effectué par petite étape très rapide. Ensuite on ajoute des queues pour effectuer la gestion des événements. Enfin SEDA fonctionne avec un système d’allocation dynamique des ressources afin d’ajuster à la charge le nombre de Threads. Tout ceci mis en place dans Mule promet donc une architecture mature et capable de monter en charge. La gestion des Threads est un cauchemar, je n’ai jamais vu une application parfaite en Java 1.4.
Je me souviens d’une discussion avec un ami, Flavien, qui m’expliquait que son équipe avait écrit un moteur d’envoi de MMS massivement parrallèle. L’implémentation initiale en Java se trainait à 100 MMS par seconde. Une nouvelle implémentation en C avec une architecture différente permet maintenant d’envoyer entre 2000 et 3000 MMS à la seconde…

Pour Mule, le modèle SEDA est appliqué à JMS dans Mule ainsi que la notion de Spaces emprunté à Java Spaces.

Load balancing et Failover
Ross présente dans ce slide les capacités de répartition de charge et de gestion des pannes de Mule 1 et Mule 2. Mule 2.1 aura un support natif du clustering.

MuleForge
MuleForge est une communauté destinée aux utilisateurs de Mule pour partager des projets basés sur Mule. Par exemple des Transformers spéciaux, des connecteurs pour SAP, Salesforces.com, SIP ou SMS par exemple. Il y a déjà 80 projets hébergés sur ce site.
Allez voir la page http://www.muleforge.org/activeprojects.php qui contient des connecteurs pour du Single Sign On, du LDAP, du SFTP, etc.

Mule HQ
Il s’agit d’une console de surveillance et d’administration qui permet via JMX de surveiller des instances Mule. C’est un peu le domaine sur lequel j’ai travaillé pour l’INA afin de surveiller et d’administrer des serveurs avec une application en Flex. Intéressant de voir ce que Mule propose, c’est une réelle demande des équipes d’exploitation et de production.

Ensuite Ross présentera MuleIDE, un plugin pour Eclipse qui facilite l’écriture de modules Mule.

Conclusion
Voilà c’est tout pour cette transcription, j’espère que cela vous aura donné envie de tester Mule et d’y penser pour vos prochaines architectures.
A bientôt.

Annexes

• Le site de Mule : http://www.mulesource.com/
• Blog Octo : http://blog.ippon.fr/tag/ross-mason
• Livre Enterprise Integration Pattern sur Amazon.fr

La prochaine soirée du Paris Java User Group aura lieu mardi soir prochain à Paris à l’ISEP à partir de 19h15 autour du langage Groovy présenté par Guillaume Laforge, chef de projet de Groovy et membre de l’OSSGTP. L’intérêt de Groovy est à mon avis de dépasser l’étape de langage de script pour vraiment apporter à la plateforme Java un langage dynamique. Guillaume est aussi spec-lead de la JSR-241 qui vise à standardiser Groovy au sein de la plateforme Java. Groovy permet de retirer pas mal de code d’assemblage et de s’approcher de la mouvance des langages de script amorcée avec Java 6.

On ne peut pas parler de Groovy sans parler de Grails, le framework MVC basé sur Groovy. La deuxième partie de la soirée sera donc consacrée à la présentation de Grails par Fabrice Robini, architecte chez Octo.
J’attends avec impatience de voir un peu une présentation en live de Grails. J’espère que Fabrice pourra refaire ce que Jean-François Hélie et Christian Blavier nous avaient proposé en juin dernier.

Le 18 septembre se déroulera aussi le Google Developer Day 2008 à l’ENSA. Les sessions sur GWT et sur AppEngine pourraient intéresser pas mal de monde. Je ne manquerai pas de vous en faire un petit compte-rendu.

Si vous voulez vous regarder quelques petites vidéos sympathiques, je vous conseille de regarder les vidéos de Jazoon 2008 une conférence dont je vous avais parlé il y a quelques mois déjà.

A propos de vidéo, si vous souhaitez regarder tranquillement un screencast de votre MacBook Pro préféré, le site Parleys.Com héberge un certain nombre de vidéo sur l’écosystème Java, Spring, Mule, JBoss et compagnie. Je vous recommande par exemple la présentation de Mule 2 de Ross Masson ou l’intervention de Rod Johnson sur Spring 2.
Au passage on note que le site a été réalisé avec Adobe Flex et qu’il existe même une version AIR. Pas mal non ?