Interview : Christophe Deneux, Architecte chez Cap Gemini

Mathieu Le Breton, Petals Link : Bonjour Christophe. Tu es architecte chez Cap Gemini Sud, où tu travailles depuis 1997. Tu as démarré le premier projet SOA basé sur des logiciels open source en France, à l’ACOSS, la caisse centrale des organismes de sécurité sociale.

Christophe Deneux, Cap Gemini : Effectivement. Il y avait également la mairie de Toulouse à cette époque, mais l’échelle était très différente.  La mairie de Toulouse, c’était pour un musée. L’ACOSS était réparti dans toute la France, avec des volumétries bien plus importantes. On parle d’une cible de 10 000 endpoints et plus de 30 serveurs répartis sur toute la France en WAN.
Mathieu Le Breton : Vous avez démarré en 2005 ?
Christophe Deneux : Le projet a démarré en été 2006, et mis en production en avril 2008.

ML : En deux mots, le projet ESB à l’ACOSS, c’est ?

CD : Le projet s’inscrit dans un cadre réglementaire, par décision ministérielle : l’interconnexion du RSI (Régime social des indépendants) avec l’ACOSS, pour le recouvrement des travailleurs indépendants. Avant ce projet, le RSI s’occupait de tout son recouvrement, désormais la partie supérieure à 90 jours est déléguée aux URSSAF.

L’ACOSS a profité de ce projet fonctionnel pour commencer à mettre en place une infrastructure SOA. Ce qui a amené à la mise en œuvre de Petals ESB. On a choisi le logiciel, on a fait des tests,  on a validé, et on est parti en développement. Et ça tourne. (Présentation vidéo du projet ACOSS)

ML : Tu voulais parler d’un truc qui te tenait à cœur : quels sont les critères de choix d’un ESB ?

CD : Avant tout : pourquoi un ESB ? Ce n’est pas simple, c’est un peu comme répondre à : pourquoi un EAI ? Avant, j’avais des liens point à point partout, et maintenant toutes les applications se branchent sur un même truc, qui gère la communication. C’est l’EAI.  Et qu’est-ce qu’un ESB rajoute à un EAI ? L’aspect services, simple et standardisé.

Ensuite, comment choisir un ESB, une fois que tu sais que tu en as besoin ? Le but n’est pas de choisir un produit, comme Petals ou autres, mais de se mettre à la place d’un DSI ou d’un architecte, et de se dire : « Je veux un ESB. Quels sont mes critères de choix ?  ». La plupart du temps, je lis dans les appels d’offres « Est-ce qu’il sait faire des transformations ? » « Est-ce qu’il sait faire un Web-service ? » « Est-ce qu’il a tel ou tel connecteur ? ». Que des critères techniques !

Je pense que ce n’est pas la bonne façon de faire. Pour moi, l’ESB va être amené à vivre, et ce sera le backbone de toute l’infrastructure applicative de l’entreprise. Tu vas y développer tout son métier. Toutes les applications, tous les processus métiers, vont être dessus. Pas forcément tout de suite. Peut-être dans 1 an, 5 ans ou 10 ans. C’est un projet de longue haleine. Ca c’était la première remarque : ton ESB c’est un backbone.

Backbone, ça veut dire qu’il y a beaucoup de choses dessus, et que ça va vivre longtemps. Donc, il faut que l’ESB retenu te permette d’être pérenne sur les développements effectués. Tu dois pouvoir réutiliser le maximum de choses qui a été mis en place dessus, si tu veux le changer, pour une raison X ou Y.

ML : Changer l’ESB, tu veux dire ?

CD : Oui. Par exemple, je ne m’entends plus avec l’éditeur. Ou l’éditeur va fermer et il n’y a plus rien. Ou il a été racheté, et ne fait plus de support. Et moi, je n’ai plus que mes yeux pour pleurer, j’ai une production sans support.

Généralement, en production, on ne peut pas se permettre d’être sans support, au cas où. C’est quand même tout ton applicatif qui est dessus. C’est un peu la vie de ton entreprise qui est en jeu. Mine de rien, sans informatique, tu ne fais plus rien. Dans ce cas, il faut changer l’ESB.

Et pour le changer… Ca fait 5 ans ou 10 ans qu’on a développé dessus. Combien ça coûte de tout réécrire ? Si j’ai fait un bon choix au départ, je vais pouvoir en prendre un autre qui est plus ou moins compatible, et récupérer un maximum des développements que j’ai déjà fait.

Mêmes concepts : le code est bien séparé entre la partie infra et la partie métier. Je n’ai aucune adhérence particulière à des codes de l’ESB. Je n’utilise que des standards. Si ton ESB respecte ça, tu auras bien sûr des coûts de migration, mais la plupart des choses, ce sera du repackaging –et pas de la réécriture-.

Ecrire une transformation, par exemple, avec le produit d’un éditeur. Tu as un éditeur wysiwyg dans lequel tu tires des traits pour écrire ta transformation. L’éditeur te génèrera du XSL, standardisé. Mais dedans, il y a des références ou adhérences à l’éditeur de l’ESB,  donc tu ne pourras pas l’éxecuter sur un autre moteur. OK, tu as un standard XSL, mais tout ce qu’il utilise a une adhérence. Donc tu ne peux pas t’en servir.

Donc plus loin que les standards, il faut des standards qui n’ont aucune adhérence au moteur, au produit lui-même. Il faut un produit qui va respecter les standards à 100%, sans adhérence. Si tu as ça, en gros tu peux dire : le boulot à faire, c’est du repackaging : on reprend ma feuille XSL, pour la remettre dans un truc nécessaire pour l’installer dans le nouvel ESB. Et après, c’est du test de non-régression. Il n’y a pas de développement. Donc tu gagnes une part. Si en plus tu as eu la chance d’avoir été super intelligent au départ, et que tu as fait des tests fonctionnels automatiques et ce genre de chose, il te reste en gros le packaging.
Ca, pour moi, ce sont des critères de choix incontournables.

ML : Ca, c’est dû au fait que tu le gardes longtemps, c’est ça ?

CD : Oui, tu ne peux pas t’amuser à le changer comme ça. C’est un truc qui va vivre.

ML : Autant, tu peux changer une application métier à un endroit, ou quelque chose comme ça, autant là c’est quelque chose d’assez central.

CD : Oui. Il faut prévoir dès le départ que les versions de l’ESB vont évoluer et qu’à un moment donné l’éditeur ne voudra plus supporter les veilles versions et se gavera sur la fourniture d’un support « custom », et que toi, tu es tout petit, tu ne peux rien faire à part payer fort cher un support de ta vieille version, ou payer fort cher une migration vers un nouvel ESB ou une nouvelle version

Ce genre de choses, on n’y pense pas forcément lors des choix, mais c’est non négligeable pour un ESB, parce qu’un ESB va vraiment devenir le backbone du système d’information. Après, si c’est pour faire un petit ESB dans un coin avec trois services, ce n’est pas la peine de se casser la tête. Si tu dois redévelopper trois services dans le futur, ce n’est pas énorme.

ML : Tu dis qu’il faut prendre un ESB qui se base au maximum sur des standards, sans adhérence ?

CD : Ca, ce sont les grands concepts pour choisir ton ESB. Le but c’est de se dire « Qu’est-ce qu’il est capable de faire ? » et « Je veux avoir un développement pérenne ».

Après, en réfléchissant à ça, tu te dis : en fait c’est quoi un ESB ? A l’intérieur, tu as des moteurs, des gens qui travaillent, et là-dessus tu leur donnes un paramétrage pour dire ce qu’ils doivent exécuter réellement. Tu retrouves l’architecture JBI en fait : composants et SU.

L’ESB s’occupe des échanges : tout l’aspect garantie de délivrance, réseaux, la partie  purement infrastructure.

Au-dessus, tu rajoutes des agents, des petits moteurs, qui savent faire un traitement technique : exécuter une feuille XSL, exécuter un worflow Talend… Et par-dessus de chacun des petits moteurs, tu vas leur donner un petit truc qui est purement fonctionnel, métier. Qui est vraiment la partie applicative : « Exécutes-moi telle feuille XSL », typiquement.

Ca c’est en gros un pattern de l’architecture d’un ESB tel qu’il devrait être selon moi. Si tu as ce genre de pattern, tu vois bien que tu sépares facilement la partie applicative de la partie moteur et réseau/infra. Donc, à ce moment là, l’ESB que tu vas acheter, qu’est-ce qu’il va comporter ? Il va comporter la partie réseau/infra,  les petits moteurs et les petits composants autours. Toi, tu n’auras plus qu’à faire la partie applicative : les service-units de JBI.

Si tu as en tête ce pattern là, on peut imaginer qu’on enlève l’ESB, qu’on le remplace par un autre pattern. Sous réserve des aspects d’installation/packaging, on peut récupérer la partie applicative et la réinstaller.

Aujourd’hui, qu’est-ce qu’il existe ? Quels sont les ESBs qui sont de ce type là ? Pour moi il n’y a que JBI qui fait ça. Si tu prends les gros ESB propriétaires, tu as toujours tout qui est mélangé. Tu ne sépares pas trop les applicatifs du moteur, l’éditeur va coller des adhérences. Pour moi, il n’y a qu’un standard qui fait bien cette séparation entre l’aspect application et l’aspect exécution, c’est JBI.

ML : Il y a des gens qui comparaient, à une époque, JBI et SCA. Tu en penses quoi ?

CD : Pour moi, ce sont deux choses différentes, et complémentaires. SCA, tu fais de la composition. SCA ne va rien te dire sur le fait d’avoir une frontière indépendante entre le moteur et son paramétrage. SCA va te dire « Ce composant est composé du composant A et du composant B » C’est un peu comme une intégration : c’est une composition. Pour moi, ce sont deux choses complémentaires. D’ailleurs, vous avez fait un SE SCA.

ML : Oui, exactement.

CD : Ce sont vraiment deux choses. JBI te donne une faible dépendance à ton applicatif. SCA ne te donne pas du tout ça. Il te dit comment composer des éléments de mon système, mais je ne suis pas un expert de SCA.

Ensuite, concrètement, tu peux te dire : JBI, personne n’utilise, c’est mort. Un autre standard, qui pourrait faire jouer ce rôle : OSGI. Tu pourrais très bien avoir tes composants en OSGI, avec ta partie applicative qui se base sur ces composants OSGI. D’ailleurs, tu peux passer d’une implémentation Petals en JBI à une implémentation OSGI. Tu repackages tes SU/SA sous des bundle OSGI. Et hop, ça roule ! Tout est récupéré.

ML : Tu passes directement d’OSGI à JBI, par transformation

CD : Par repackaging de la partie applicative. Je n’ai rien à développer. Je fais du packaging. Au lieu d’avoir un .zip SA, avoir un truc OSGI.
Donc aujourd’hui, dans les standards, il n’y a que JBI. Et aujourd’hui, dans les ESB JBI qui existent, tu as quoi ? ServicMix de FUSE, Petals ESB de Petals Link, et Open ESB.

Si tu as des besoins de distribution, Petals est le seul à le faire, avec un Routeur de messages (NMR) nativement distribué. Attention, ce n’est pas « intégration d’instance », parce que ServiceMix parle de distribué. Mais ce n’est pas du distribué au même niveau. Ils intègrent deux ServiceMix, ce qui fait que de l’un tu peux appeler des services de l’autre, mais ce n’est pas le NMR qui est distribué.

Ensuite, la question de la haute disponibilité. Si tu ne peux pas travailler avec un seul NMR sur deux containers, je ne vois pas comment tu peux faire de la haute disponibilité. A part faire du clustering. Et Petals fait de la haute disponibilité sans clustering. Le clustering, ça coûte vachement cher, parce qu’il te faut tout ce qui est matériel, mode de réplication ou autres. Alors que Petals disponibilise sur un aspect distribution. Ce qui fait que tu ne dis plus « Je veux avoir mon système disponible à 99.9% » mais « Je veux avoir mon système disponible à 90% pour 90% de ma topologie ». Tu as un aspect surface.

C’est beaucoup moins coûteux à mettre en place avec une disponibilité distribuée, qu’une haute disponibilité à base de cluster. Ca se fait tout seul, c’est super simple. Ce qui donne une disponibilité bien meilleure à moindre coût.

ML : A l’ACOSS, vous avez des clusters ou du distribué ?

CD : Il n’y a pas de cluster, c’est tout distribué.

ML : Tu conseillais d’utiliser un standard, tel que JBI, qui sépare l’aspect métier et technique. Il me semble qu’il y a d’autres logiciels ESB qui font du JBI, non ? TIBCO, Mule, par exemple.

CD : Pas vraiment, eux font de l’intégration avec du JBI. Ce n’est pas un bus JBI à proprement parler.
L’idée, c’est de mettre un composant sur le bus JBI, et de pouvoir directement taper le cœur, plutôt que de passer par une couche service, ce qui rajoute une étape. Mais c’est normal que les éditeurs ne souhaitent pas faire de bus JBI : ça voudrait dire qu’ils peuvent se faire virer du jour au lendemain.

ML : Il faut se protéger un peu, c’est compréhensible.

CD : C’est pareil pour les éditeurs open source, ils peuvent se faire virer aussi. Ils implémentent pourtant ces standards. Mais derrière c’est une philosophie différente. Le business modèle est différent. L’open source est plus basé sur du service/support.

ML : Oui, la différence est importante. Merci Christophe pour cette interview !