Merci pour votre attention et votre reponse rapide. Je me permet de poursuivre la discussion..

Etant un nouveau dans la monde du SOAP et faisant mes premiers pas avec Apache CXF je navigue a vue.

C’est un article qui teste la reponse SOAP qui m’a fait me poser la question si il etait interessant de faire un tel test. J’etait assez dubitatif. Votre reponse sur l’inutilite d’un tel test me conforte dans ma premiere vague impression.
Voila l’article en question: http://stackoverflow.com/questions/8066474/how-to-transform-soapfault-to-soapmessage-via-interceptor-in-cxf

J’ai d’autre part fais un test d’integration visant a evaluer une exception mais mon intercepteur ne semble pas entrer en action. L’exception est bien lancee et est bien recu par le test client, mais sans etre modifiee comme il se doit par l’intercepteur.
J’ai poste un fil dans le forum a la page:
http://cxf.547215.n5.nabble.com/Why-is-my-exception-interceptor-not-being-called-td5464238.html

Encore merci pour votre article qui m’a permis de decouvrir les intercepteurs et de les deployer dans un projet.

Qu’entendez vous par plus d’informations sur les faults et exceptions? L’exemple donné illustre ceci, non?

Pour les deux autres questions :
- On peut écrire un test d’intégration qui va utiliser un client CXF, qui, pour vous va demarshaller l’exception ce qui vous permettra de la catcher et de regarder ce qu’elle contient
- la 2e méthode est possible aussi c’est à vous de voir ce que vous préférez ou votre besoin. Néanmoins ça reviens à tester le framework qui est déjà fort bien testé par ses developpeurs :) Toutefois j’ai déjà écrit ce genre de tests pour analyser des comportements « anormaux » de web services, c’est à dire en l’appelant avec des données incohérentes (tests de sécurité entre autres) .. bref à vous de voir!

Il serait tres interessant d’avoir plus d’information sur la facon dont les exceptions et/ou faults sont retournees.

Peut on ecrire un test unitaire que va inspecter une exception contenant certaines informations ajoutees par l’intercepteur ?

Ou doit on avoir un test unitaire qui va inspecter la reponse xml elle meme ?

Bonjour,
Pour moi, les fonctionnalités d’administration que vous citez sont possibles avec Rabbit du fait de l’architecture à base de broker. Je suppose qu’avec ZeroMQ, qui est décentralisé, la topologie est « inscrite » dans le comportement des acteurs, plutôt que configurée dans un broker.

Pour avoir rapidement évalué les 2 d’un point de vue fonctionnalités, il y a quelques avantages vraiment intéressants à RabbitMQ :
– possibilité de persister les messages sur le disque
– gestion de l’acknowledge (automatique, manuel ou multiple, « nack »)
– interface de gestion : le fait d’avoir un broker central permet d’avoir une interface de gestion centralisée (plugin management de RabbitMQ) pour voir ce qui se passe sur le broker, purger des files, changer les bindings,… Très utile en dev et peut également bien dépanner par la suite.

Sauf erreur de ma part, tout ça n’est pas dans ZeroMQ. Après, c’est aussi une question de goût et on doit surement pouvoir ré-implémenter ça avec ZeroMQ, mais j’avoue qu’avoir tout ça « out-of-the-box » m’avait particulièrement séduit.