Accueil Nos publications Blog FuseSource Community Day – Présentation client et retour d’expérience par Atos Worldline et CapGemini

FuseSource Community Day – Présentation client et retour d’expérience par Atos Worldline et CapGemini

Ces deux sessions ont présenté un retour d’expérience sur la mise en place des solutions de FuseSource.

Premier retour d’expérience

La première session a été présentée par Papa-Moussa Diagne et Christian Müller (qui est également commiteur sur le projet Apache Camel) dans le cadre de deux projets menés par Atos Worldline.
Le premier projet consistait à fournir un service à destination des utilisateurs finaux afin de leur permettre de modifier immédiatement le code PIN de leur carte de crédit.
Le deuxième avait pour objectif de sécuriser les transactions sur internet.
Bien sûr, il va sans dire que ce type de services avait à être robuste, sûr, scalable et disponible 24h/24 et 7j/7.
Pour ce faire, ce sont les solutions Fuse ESB, Fuse Message Broker, Fuse Services Framework et Fuse Mediation Router qui ont été mises en place afin de rendre interopérables des couches aussi diverses que le système de fichiers, du SOAP, du JMS, du JMX, du XML et des bases de données.

Suite à la présentation de leurs projets, Christian et Papa-Moussa nous ont fait part de leur retour d’expérience, à savoir :

  • qu’il pouvait être utile d’être accompagné par des personnes d’expérience sur ce type de solutions,
  • qu’il était fortement recommandé de faire un choix sur la façon de mettre en oeuvre l’écriture des routes (ie. utilisation de JavaDSL ou XML-DSL) dans le cas d’Apache Camel,
  • qu’il était important de bien prendre en compte la problématique de déploiement/packaging de l’application,
  • qu’il était fortement recommandé de ne pas utiliser JBI,
  • qu’il ne fallait pas sous-estimer le coût d’une solution basé sur OSGi.

Deuxième retour d’expérience

La deuxième session a été présentée par Benoît Hannebicq, Yannick Plourin de CapGemini et a fourni un retour d’expérience d’un projet effectué dans le cadre du projet SIRHEN. Ce dernier consistait en une refonte complète du SI RH pour le Ministère de l’Education Nationale.
Coté nombre de ressources, il a regroupé de manière permanente environ 150 personnes.
En fait, le projet SIRHEN a été construit comme une plateforme de services centralisée basée sur une architecture SOA en proposant une approche Bottom-up afin de permettre l’exposition des différentes applications/services implémentés sur des couches protocolaires de type SOAP et REST.
Ce projet a mis en oeuvre les différentes solutions de FuseSource afin d’implémenter les couches d’ESB, de médiation mais aussi pour la transmission des évènements.

A leur tour, les consultants de CapGemini nous ont fourni leurs retours :

  • En phase de construction de la solution :
    • le choix d’utilisation de ce type de solutions structure l’architecture,
    • l’utilisation des frameworks ActiveMQ, CXF, ServiceMix et Camel a permis un assemblage aisé des briques de bases,
    • l’utilisation des frameworks ActiveMQ, CXF, ServiceMix et Camel offre une solution élégante pour l’interfacage du système avec les autres systèmes externes,
    • il est important de bien réfléchir à la place que l’ESB aura dans l’architecture,
    • la mise en oeuvre d’une architecture SOA impacte fortement le déploiement mais la réciproque est également vrai.
  • En phase de développement
    • Camel permet de se concentrer sur l’esentiel sans avoir à se préoccuper de la tuyauterie,
    • pour utiliser convenablement Camel, il est nécessaire d’acquérir de nouveaux réflexes de développement,
    • les frameworks Camel et ServiceMix doivent être réservés à des personnes ayant un minimum d’expérience au risque d’avoir des surprises.
  • En phase d’intégration
    • ServiceMix et ActiveMQ ont fait preuve de stabilité,
    • il est nécessaire d’acquérir de nouveaux réflexes lors du déploiement de ce type de solution (nouveau conteneur, nouveau mode de déploiement, …),
    • les interfaces JMX offertes par Camel, ServiceMix et ActiveMQ permettent d’avoir de nombreuses informations sur l’état et sur l’activité des composants déployés dans le système,
    • il reste des points à améliorer pour le packaging dans un contexte de livraison client/fournisseur.

Conclusion

En conclusion de ces deux sessions, je dirais que cela était très instructif. En effet, ces retours d’expérience sur une réelle mise en oeuvre de ce type de solutions prouve que les architectures SOA sont possibles d’un point de vue bottom-up mais également que les solutions commencent à être vraiment matures.