SoapUI : testeur de web service

Je travaille chez mon client à la mise en oeuvre d'architecture d'intégration, notamment SOA et EDA avec des ESBs.

Je viens de terminer une phase de test de montée en charge dans lequel nous avons mis à l'épreuve plusieurs ESBs Open Source du marché.

Plusieurs de nos scénarios concernées la mise en oeuvre d'échanges synchrones à base de web services avec un ESB comme "proxy" intermédiaire. Nous avons développé un injecteur maison permettant de simuler une charge synchrone (appel massif de web services) ou asynchrone (écriture massive de messages JMS).

J'ai néanmoins découvert un outil très sympa : SoapUI
L'outil permet à partir d'un WSDL d'appeler un web service. Ce que je trouve très intérressant dans l'outil c'est la génération d'un message SOAP par défaut qui permet d'appeler le web service. Pour ceux qui n'ont pas eu WSDL en seconde langue au lycée, c'est très appréciable! :-)

En creusant un peu sur les fonctionnalités de l'outil, j'ai découvert qu'en plus de faire des tests unitaires, il permet aussi de mettre en place des tests de charge (multi threading) avec la possibilité de mettre en place tout un ensemble d'assertions.

SOA et EDA

SOA est sur toutes les lèvres. A tel point que trop de SOA peut parfois tuer le SOA :-). Certains responsables informatiques ont maintenant peur de l'entendre ou de le prononcer.

Je travaille actuellement sur les architectures d'intégrations et notamment celles autour des ESBs. La plupart des présentations que j'ai pu voir sur les ESBs les définissent comme une infrastructure permettant de "faire du SOA". "Faire du SOA" implique de mettre en oeuvre des architectures où un applicatif appelle un service d'un autre applicatif de manière synchrone (pour simplifier...). Cette démarche implique alors une dépendance en terme de disponibilité entre les 2 systèmes. Elle implique aussi de déporter les exigences en terme de temps de réponse de l'application consommatrice vers l'application qui fournit le service.

C'est normalement à ce moment que le responsable des applicatifs en production vous dit :"heuuu et comment je fais si je veux que mes applicatifs soit indépendants en terme de disponibilité pour pouvoir continuer à travailler si un d'entre eux crash?..."

EDA permet ce genre de fonctionnement. EDA, pour Event Driven Architecture, propose des échanges asynchrones de messages unitaires (ayant seul un sens métier au sein du SI) au fil de l'eau. Ce type d'architecture permet de rendre indépendant les applicatifs en terme de disponibilités et de performance, tout en offrant la possibilité de diffuser les messages au fil de l'eau dans le SI. La plupart des ESBs permettent de faire de l'EDA même si en général le focus est mis sur les partie SOA qu'offre le bus.

Je pense, et je crois que je ne suis pas le seul (enfin j'espère...), que ces 2 types d'architectures font partis d'un SI moderne.

Vous en pensez quoi???

Voici d'ailleurs un blog intéressant :
http://soa-eda.blogspot.com/
Le nom du blog est assez porteur de sens...