RE: Petite question d'architecture

> > Bon alors moi les ESB je trouve ça génial.
> > J'ai utilisé Fuse ESB pendant 6 mois avec Apache Camel pour le
> routage/transformation de données,
> > CFX pour la connectivité SOAP,
> 
> CXF plutôt, non ? :-)
> 
Evidemment :-)

 
> Bon, il ya quand même une question qui me tarabusque.
> Si je comprend bien (mais je suis encore assez loin de cet idéal),
> dans un ESB, tu définis une route pour un flux d'entrée et, long de
> cette route, un certain nombre de transformations vont être appliquées
> à ton flux.
> Mais cette route, est-ce que tu peux la définir dynamiquement dans une
> interface web, par exemple ? Ou est-ce qu'elle est gravée dans le
> marbre ?

Ca dépend :-)
Camel évolue très vite mais pour la version que j'ai utilisée il y a quelques mois 
Les routes sont initialisées au démarrage uniquement.
On peut arrêter/démarrer des routes dynamiquement mais je ne suis pas sûr qu'on puisse en créer.
En tout cas il n'y avait pas d'IHM pour cela (mais j'ai vu passer des messages sur la liste de diff qui semblent indiquer qu'il y a des travaux en cours sur le sujet).

On a développé une sorte de moteur de règles basé sur Camel qui permet dans les faits d'ajouter de nouveaux traitements par une modif d'un fichier xml de configuration et un redémarrage du bundle OSGi.

Certains préfèrent implémenter chaque route dans un bundle séparé et activer les routes à la demande.

Une autre équipe a développé une webapp d'administration des routes, mais ça reste du dév spécifique pour le projet.


> Et comment ça se passe si un des éléments de cette route a une assez
> forte latence (dans mon cas, typiquement, je pense à la mise en page
> InDesign qui est réputée lente et susceptible de planter) ?
> >

Là aussi ça dépend si on a décidé de l'appeler en mode synchrone ou asynchrone.
Dans mon cas tout est asynchrone, soit via JMS, soit via des services web SOAP avec callback.
Les services appelés sont aussi susceptibles d'être lents et instables.
Peu importe le temps pris par le processus appelé on attend la notification de fin de traitement (dans la file JMS ou le service de callback) et on agit ensuite en conséquence (code d'erreur reçu ou pas).

> > D'autres collègues se contentent d'un simple Camel intégré à une
> appli JavaEE classique.
> > C'est suffisant dans certains cas mais on perd la modularité d'un ESB
> comme Fuse (et surtout on perd le déploiement à chaud des modules, qui
> dans mon cas du moins est un critère important).
> 
> Et au niveau montée en charge, ça tient bien le choc, ou dès que tu as
> 5 fichiers à traiter ton Xeon hexaprocesseur commence à pleurer ?

Je n'interviens hélas pas trop sur ce point.
Mais j'ai des échos plutôt favorables des gens qui s'en occupent.

> D'ailleurs, au niveau monitoring, ça se surveille facilement un engin
> pareil ?
> 
Ben dans le cas de Fuse, avec la distribution commerciale, y'a un outil de monitoring qui a l'air bien. Mais bon, on n'a pas cette distribution...
Alors on fait via JMX et les quelques outils livrés par défaut, c'est mieux que rien.

Ca reste un aspect à creuser pour moi.

Voilà voilà.
Patrice



*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************