In this article I propose that we have a look on a very simple usage of the lightweight integration framework Apache Camel with one of the most popular Java Web framework : Apache Wicket. The article’s source code is available at the end of this article, ready to be compiled, so that you can test freely from home. If you’d like to reuse this article or its source code, please contact me before since it is not free for distribution. My email is displayed on the upper left logo.

What is Apache Wicket ?
Wicket is an open-source java framework that unlike a framework such as Struts 1, is component oriented. It lets you define your pages using plain Java, and then integrate them in static HTML source code with light tags, so that everything is displayed with a light application server such as Apache Tomcat for instance.
When I was a projet leader at Reuters last year, my job was to be the person in charge for a proprietary framework, Karma, which is very close to Wicket. Thus it wasn’t very hard to jump into the Wicket world. Component oriented frameworkd such as Wicket eases the development and is more close to what we’ve been doing for decade with Swing.

In this article we will see how to create your first Wicket page, a custom component, and integrate Spring with Apache Camel to load our configuration. The most interesting concept about Wicket is that the event model is very close to Swing. You basically implement listeners and based on the Observer-Observable pattern, the Wicket engine notifies your logic depending on the user action on the web page. With the support of Ajax, it’s a very interesting solution to learn.

What is Apache Camel ?
Apache Camel is an open-source framework based on Spring Core framework. It’s an implementation of the populars EIP (Enterprise Integration Patterns) that offers either XML for configuration (like Mule) or a nice DSL based on Java, which I personaly prefer. We will use the Java DSL in this article.
Apache Camel is a good add-on for Mule. For me, Mule is a lightweight integration framework, not only an ESB. Camel is a toolbox that you can also integrate with Mule. In this architecture, Mule will be in charge for I/O and the Threading model. Camel would be in charge of routing, transform and mediation tasks. Here we will use only Camel, since my solution is pretty simple.

Content of the demonstration
I started to work on this article in november, with the aim to present this work at Devoxx during my quickie on ESB at Devoxx 2008. I quickly realized that it wouldn’t fit in the amount of time allocated for a quickie. I posted the french version in january and now you’re reading the english translation.

… and why didn’t you take Mule/Spring Integration/Apache ServiceMix/OpenESB/AnyOtherIntegrationFramework ?
I really appreciate the hard work behind the other Integration framework but for the purpose of this article, Camel is enough. It would be very interesting to publish the same article based on Spring Integration for instance. Let me know if you plan to write such article so that we can reference it here !

The sample application
Let’s start with what you will see once completed. Remember : the source code is available at the end of this article.
Unzip, open a xterm and simply type « mvn jetty:run ». Open a web browser and here is what you’ll see:

As a customer I put my name in a form, and a litle message to ask why my great PS3 wasn’t delivered for christmans.
I click the submit button and a nice « Thanks » message is displayed. So far, so good.

What’s happening in the background ?
When I click the Send button, Wicket generates a message for Apache Camel. It transforms this message and store-it to a file, to demonstrate how to save a message on the local filesystem. I don’t say this is what you should do. I just want to demonstrate some of Camel’s features. So please don’t blame me for what the application is doing, we’re more interested by HOW it is doing it.
We have another async process in Camel that polls this folder. For any incoming file, it reads it, transforms it using Velocity and then generate an email. We will use an outgoing silo so that Apache Camel send to an SMTP server the email.
For my article I use MockMail, it’s a fake SMTP server that’s really easy to use, especially for JUnit test.

The administrator view
The admin page is a wicket page that reads the inbox with POP3 and display a list of customer’s requests to the web site administrator. We will see how it is simple to implement our own Wicket component to iterate a collection of Messages.

First steps with Wicket, « Bonjour le monde »/ »Hello world »
Download the source code and open InnoteriaWicketApplication java class with your favorite IDE (mine is IDEA IntelliJ). This class is our Wicket main application entry point. I use Mock JavaMail to declare a MailBox.
The class ReportIncidentEndpoint is one of my Apache Camel component. It’s the gate to the Camel world here for Wicket.

public class InnoteriaWicketApplication extends WebApplication {
    private ApplicationContext ctx;
    private ReportIncidentEndpoint endpoint;
    private Mailbox mailbox;   // mock javamail

    private static ISpringContextLocator CTX_LOCATOR = new ISpringContextLocator() {
        public ApplicationContext getSpringContext() {
            return InnoteriaWicketApplication.get().ctx;
        }
    };

    public InnoteriaWicketApplication() {
    }

    public Class getHomePage() {
        return HomePage.class;
    }

    public static InnoteriaWicketApplication get() {
        return (InnoteriaWicketApplication) Application.get();
    }

    @Override
    protected void init() {
        ctx = new ClassPathXmlApplicationContext("applicationContext.xml");
        Address address= null;
        try {
            address = new InternetAddress("incident@innoteria.fr");
        } catch (AddressException e) {
            e.printStackTrace();
        }
        mailbox = new Mailbox(address);
    }

    /**
     * This trick is used to decorate a specified template class with a SpringBeanLocator
     * so that I can use Spring to load my Apache Camel configuration.
     * @param clazz will be the endpoint to decorate
     * @param <T> template
     * @return a decorated class.
     */
    private <T> T createProxy(Class<T> clazz){
        return (T) LazyInitProxyFactory.createProxy(clazz, new SpringBeanLocator(clazz, CTX_LOCATOR));

    }

    public ReportIncidentEndpoint getReportIncidentEndpoint(){
        if(endpoint==null){
            endpoint=createProxy(ReportIncidentEndpoint.class);
        }
        return endpoint;
    }

}

It is now time to write your first page, the HomePage class. It extends the WebPage class. We see that a FeedbackPanel component has been declared with 2 text fields. We also added a Form. The onSubmit method will be trigger when the user submits the form from the web page. We will see later how an instance of MyReportIncident is used to hold details later.
In a few lines, as you can see it’s pretty simple to implement a Form and to trigger an action when the user clicks a button.

public class HomePage extends WebPage {

    private static final long serialVersionUID = 1L;

    public HomePage(final PageParameters parameters) {
        // un de mes composants
        FeedbackPanel feedbackPanel = new FeedbackPanel("feedback");
        add(feedbackPanel);

        final TextField yourName = new TextField("yourname", new Model());
        final TextField yourMessage = new TextField("yourmessage", new Model());
        yourMessage.setRequired(true) ;
        yourName.setRequired(true);

        Form form = new Form("formtest") {
            protected void onSubmit() {
                ReportIncidentEndpoint service = InnoteriaWicketApplication.get().getReportIncidentEndpoint();
                service.reportIncident(
                        new MyReportIncident(
                                yourName.getModelObject().toString(),
                                yourMessage.getModelObject().toString()
                        ));
                info("Thanks!");
            }
        };

        form.add(yourName);
        form.add(yourMessage);

        // Add a form with an onSubmit implementation that sets a message
        add(form);

        /* java code */
        add(new BookmarkablePageLink("link", CheckMailbox.class));

    }
}

Let’s see on the HTML side how does it work. If you open HomePage.html we see:

...


                Your name

                Your message:


            


...

Wicket relies on the ID declared in the HTML to create a proxy between the HTML view and the Java side. Wicket really lets you play and design the HTML without the need to use complex components syntax. The HTML code is clean and you can even preview it with IDEA IntelliJ to validate that the layout is correct.
Enough for my short introduction to Wicket, I let you have a look at the code while I prepare the next step.
Browse the source code, try to compile and deploy with maven 2 (mvn jetty:run) and when you’re ok to continue, come back here.

The Apache Camel side
Our entry point in Camel is ReportIncidentEndpoint. The reportIncident method is notified by Wicket when the user clicks the send button in the user interface. It publishes to an in-memory Queue handled by Apache Camel. ReportIncidentEndpoint is a Spring Bean which gets injected into InnoteriaWicketApplication.

/**
 * @author Nicolas Martignole http://touilleur-express.fr
 */
public class ReportIncidentEndpoint implements Serializable {
    private CamelContext context;
    private static final long serialVersionUID=2233L;

    public ReportIncidentEndpoint() throws Exception {
        // create the context
        context = new DefaultCamelContext();

        // append the routes to the context
        context.addRoutes(new ReportIncidentRoutes());

        // at the end start the camel context
        context.start();
    }

    /**
     * Callback method executed from the HomePage when the user
     * clicks on submit.
     * @param message is a message created by Wicket
     * @return a status message that is shown on HomePage.
     */
    public String reportIncident(MyReportIncident message) {
        // create the producer template to use for sending messages
        ProducerTemplate producer = context.createProducerTemplate();

        // Send the message to an in-memory queue and return
        // See GenerateEmailStoreToFilePollFolderAndSendFile
        // it will read the message from direct:start in-memory queue
        Object mailBody = producer.sendBody("direct:start", message);
        System.out.println("Body:" + mailBody);

        return "OK";
    }

}

Let’s see now how we integrate our application with Apache Camel. I stated explicitly 2 roads to show you one of Camel’s principle. Open ReportIncidentRoutes in your editor. This class extends RouteBuider, a Camel super class that lets you define the logical path within your application. Please note that XML is also an option.
Note that it is also possible to use XML to define your route, but here I find elegant the java definition of your path, especially when your architecture will not change any further.

The first road:
- reads the in-memory queue « direct:start »
- calls a Velocity template to generate a message
- saves set the file on the file system.

Please note that it would be very simple to replace the « save file on disk » operation with a « generate and send JMS Message » to a Queue. For the purpose of this article it’s simplier to use an in-memory queue or the file system.

public class ReportIncidentRoutes extends RouteBuilder {
    // Any message posted on direct:start will be
    // handled by velocity template, then persisted on the file system
    public void configure() throws Exception {
        from("direct:start")
            .to("velocity:MailBody.vm")
                .setHeader(FileComponent.HEADER_FILE_NAME, "errorEmail.txt")
                .to("file:///./target/demoCamel?append=false");
       ...

Let’s add another Camel path/road. The second road :
- polls the folder for any incoming file
- adds an email subject to the message
- connects to a real SMTP server and publish the message

Do you remember that we created a MockMail Mailbox in InnoteriaWicketApplication ? Once this application is deployed, MockMail starts to listen for incoming SMTP requests on port 25. Try a telnet localhost 25, you should see that someone is listening ! So our application will really send an email. You can adapt the source code and use the GMail SMTPs server if you want to complete this article.
Here, the user name is nicolas. We will use it later to retrieve the list of email with POP3.

 from("file:///./target/demoCamel")
            .setHeader("subject", constant("New incident reported"))
           .to("smtp://nicolas@localhost?password=secret&to=incident@innoteria.fr");

Apache Camel is a framework that can simplify your source code. I picked another sample to demonstrate one of its nice feature : a simple rules engine that would be enough in most use cases :


// sample 1 if the header key foo is equals to bar then forward to b queue
from("queue:a").filter(header("foo").isEqualTo("bar")).to("queue:b");

// sample 2
from("queue:c").choice()
.when(header("foo").isEqualTo("bar")).to("queue:d")
.when(header("foo").isEqualTo("cheese")).to("queue:e")
.otherwise().to("queue:errorQueue");


Apache Camel is an interesting solution. It aims to reduce the amount of technical code in your application, usually required to read a file, generate an email and send it to a SMTP server. The idea behind this framework is to ease integration with external systems such as JMS, SSH, FTP, File, SMTP or FTP. Don’t hesitate to go on Apache Camel web site and have a look at the documentation, there’s a lot of interesting use cases.

How can I read the mailbox content and display a list of emails ?
Let’s go back to Wicket. We will see in a minut how to create your own component. The next user story is : how can I read the list of incoming customer’s request from my administrator web page ?
If you click on the « Check Incident Mailbox… » on the home page you’ll see this screen :

CheckMailbox class is a Wicket web page that fetches the list of email sent to incident AT innoteria.fr. An Iterator of Message is used by our custom component to display each message. I had to add an Adapter for Message, cause javax.mail.Message is not Serializable. Wicket requires Serializable instance. This is an usage of Iterator and Adapter pattern by the way.

public class CheckMailbox extends WebPage {
    private static final long serialVersionUID = 1L;

    public CheckMailbox(final PageParameters parameters) {
        Address address = null;
        try {
            address = new InternetAddress("incident@innoteria.fr");
        } catch (AddressException e) {
            e.printStackTrace();
        }
        Mailbox mailbox = Mailbox.get(address);
        // javax.mail.message subclasses are not serializable
        // thus we need this little trick to adapt our collection.
        // I don't wan use collections-utils and folks, it's too simple.
        InnoteriaMessageIterator imi=new InnoteriaMessageIterator(mailbox.iterator());
        MessagePanel rv = new MessagePanel("repeatingPanel",imi);
        add(rv);
    }

}

My first component
The class MessagePanel is a Wicket component, attached with its own subset of HTML. DisplayMessagePanel is a Panel included in MessagePanel. When I wrote my code I thought it would be useful to add some more components, but I didn’t finnish. Anyway…

I really appreciate how Wicket describes components.

public class DisplayMessagePanel extends Panel {

    public DisplayMessagePanel(String id, final InnoteriaMessageIterator listOfMessages) {
        super(id);

        add(new RefreshingView("repeatingView") {

            @Override
            protected Iterator getItemModels() {
                return new ModelIteratorAdapter(listOfMessages.iterator()) {
                    @Override
                    protected IModel model(Object o) {
                        return new CompoundPropertyModel((InnoteriaMessage) o);
                    }
                };

            }

            @Override
            protected void populateItem(Item item) {
                // Those 3 properties are read directly on InnoteriaMessage POJO
                // See CompoundPropertyModel javadoc for more details
                item.add(new Label("subject"));
                item.add(new Label("from"));
                item.add(new Label("content"));
            }
        });
    }
}

Conclusion
I hope you appreciate, I spent a lot of time to write this article. The idea was to demonstrate Apache Wicket and Apache Camel with a real use case. It would be interesting to write the Spring Integraton or the Mule version. Not a lot of work but I have already some article to complete…

If you appreciate reading this article, please vote for it on DZone

Source code:
touilleur_wicket_camel_1.0.tar.gz

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

Les choix techniques pour l’architecture de la solution sont:

• User Interface: echo 2
• Application Server: JBoss Application Server 4
• Integration with Mortgage Providers: ServiceMix
• Persistence Mechanism: MySQL
• CMS System: Hippo
• Object Relational mapping: Hibernate 3
• Dependency Injection: Spring

Pour la couche UI, RDF Group utilise echo2 un framework open-source Ajax très sympa. L’intérêt de ce composant est de proposé un modèle orienté widgets/composants qui est à la fois simple à programmer et puissant. Allez voir les démos echo2 pour vous faire une idée de ce qu’il est possible de faire faire à votre navigateur… Je me sens un peu chez moi puisque le projet que j’encadre est similaire à echo2 ou encore ZK Ajax

Pour la couche Business Logic, RDF Group a fait le choix d’utiliser Apache ServiceMix 3.0, projet open-source de la communauté Apache. Ce framework propose un bus de données d’entreprise (ESB) pour s’intégrer dans une architecture SOA. Il est construit à la base sur la spécification JBI JSR208 qui est dit comme étant l’implémentation Java de référence pour l’orchestratio de services. J’ai parlé il y a un temps de SCA, la proposition des gros éditeurs (BEA, Sybase, Oracle…) et je ne sais plus si j’ai parlé de Microsoft Indigo, l’architecture proposée par Microsoft qui est aussi intéressante.
ServiceMix utilise Spring et intégre des API très intéressante comme le moteur de règles Drools. Ce moteur de règle devrait donc permettre de proposer des services d’évaluation de Business Object vraiment intéressant.
La couche de Binding propose les protocoles suivants:

• HTTP
• JMS
• JavaMail
• WSIF
• Jabber (instant messaging)

La couche Services package les couches métiers SOAP suivantes:

• WS-Notification
• WS-Reliable Messaging
• WS-Eventing
• WS-Resources Properties
• WS-Distributed Managment

Quant à la couche Components voici ce que l’on y trouve:

• ActiveMQ pour la fabrication de message
• ActiveSOAP
• Mule (Object Brooket)
• Groovy pr le scripting
• Drools (moteur de regles)
• PXE (BPEL)
• Agila (Workflow)

Concernant les serveurs J2EE, ServiceMix s’integre avec Apache Geronimo facilement. Il y a auss le support de JBoss et donc la possibilité de construire facilement un bus de données.
Pour vous faire une idée de ServiceMix je vous conseille la lecture du UserGuide sur leur Wiki.

Dès que j’ai un peu de temps je testerai ServiceMix et je ne manquerai pas de revenir ici autour d’un café en parler avec vous.