Chez un client, j’ai du récemment vérifier que l’on pouvait facilement utiliser l’API SOAP de Crowd en Java. J’ai donc pour cela utiliser les 2 principaux framework de web service du monde Java Open source : CXF et Axis2. L’idée de cet article n’est pas de comparer fonctionnellement ces 2 frameworks, mais juste vous livrer les résultats numériques de ces essais.
Le web service à appeler est le service SecurityServer de Crowd. C’est un gros service : le WSDL fait 120K, comporte 2793 lignes et 94 opérations. Pour chaque framework, j’ai :
- généré le bouchon client correspondant au WSDL
- écrit un test qui utilise ce bouchon et appelle quelques services sur le serveur Crowd. Le test est identique pour chaque framework (au niveau fonctionnel et au niveau des assertions). Il est juste adapté à l’API du framework
J’ai donc essayé avec CXF, puis avec Axis 2 avec le mapping ADB, et, comme j’ai eu quelques problèmes, avec Axis 2 et le mapping XmlBeans. Dans les 3 cas, j’ai réussi à faire passer mes tests fonctionnels.
| CXF | Axis2 ADB | Axis2 XmlBeans | Commentaire | |
|---|---|---|---|---|
| Version | 2.1.6 | 1.5.1 | 1.5.1 | |
| Outil de mapping XML | JAXB | ADB | XmlBeans | Pour CXF, j’ai utilisé l’option de JAXB generateElementProperty=’false’ pour simplifier le code généré par CXF. Je ne sais pas si l’équivalent existe avec Axis. |
| Classes modifiées après génération ? | Oui | Non | Oui | Il faut modifier le code produit, car des classes sont générées dans le package java.lang (Exception, Throwable) |
| Nombres de classes générées | 155 | 15 | 498 | Peu de classes pour Axis2 ADB, mais tout est dans la même classe. |
| Nombre de lignes Java générées (LOC) | 4 748 | 54 814 | 17 798 | Il y a 10 fois plus de code pour Axis2 ADB que pour CXF. Cela est du au fait que CXF utilise des annotations au lieu de générer du code. |
| Taille de la classe principale (LOC) | 483 | 54 233 | 17 239 | Avec Axis2 ADB, Eclipse plante toutes les 3 minutes à cause de la classe de 54K lignes. Le projet est donc quasiment inutilisable |
| Nombres de resources générées | 0 | 0 | 1 269 | Contrairement aux autres, Axis 2 XmlBeans génère des fichiers de resources dont il a besoin au runtime. |
| Taille du projet (code source) | 840 K | 4,6 M | 11 M | 11 M de code source pour un bouchon SOAP… |
| Taille de la classe de test (LOC) | 134 | 175 | 233 | Le code le plus court et le plus joli est avec CXF. Avec Axis 2, il faut instancier plein d’objets supplémentaires liés au mapping XML. |
| Temps d’initialisation du bouchon | 2 613 ms | 0 ms | 503 ms | CXF est long à s’initialiser (normal, il n’y a que peu de code, tout est dans les annotations) |
| Temps d’exécution des tests | 847 ms | 1400 ms | 1357 ms | CXF va plus vite à l’exécution que les autres |
Bilan :
- le code généré est beaucoup, beaucoup plus petit avec CXF qu’avec les autres …
- le code à écrire pour utiliser le bouchon est beaucoup plus simple et joli avec CXF
- CXF est plus long à s’initialiser, mais va plus vite après
J’utilisais déjà CXF, il me faudra des raisons très convaincantes pour passer à Axis…
Suggestion d'articles :
Bonjour,
Oui je suis plutôt d’accord avec ton étude. Je suis en train de faire des études de perf entre les 2 technos. L’étude consiste a lancer 20 threads qui invoquent 500 fois des méthodes simples. Le résultat est que CXF est beaucoup plus performant et qu’ Axis2 fournit un stub non threadsafe et plus lent…C’était bien galère!
En tout cas, merci pour ces résultats, ca m’aide beaucoup
Très intéressante.
Il semblerait que coté serveur, Axis2 éprouve éganelent quelques difficultés :
http://jsevellec.blogspot.com/2010/02/bench-de-framework-web-service-java.html
Pas de quoi donner envie d’utiliser Axis
Pour éviter de générer toutes les classes dans un seul fichier, il y a un paramètre du wsdl2code : unpackClasses=false.
Intéressant! C’est marrant cette article… Les problématiques de performances des frameworks ws sont à l’honneur en ce moment. Je confirme que coté serveur, Axis2 est aussi beaucoup moins performant. En revanche, il ne faut pas oublié Spring ws qui coté serveur est presque aussi performant que CXF, c’est peut être la même chose coté client.
[...] doesn’t have a feature you need, it doesn’t matter how bug free it is). Performance is important. Documentation is important. Ease of use is important. A friendly and responsive community is [...]
metro n’est pas dans les principaux framework ? un peu de mal a comprendre.
Il manque Metro, c’est exact. J’ai essayé la même manipulation avec, voilà ce que cela donne :
Metro a donc un net avantage sur CXF grâce à ses performances.
Par contre, faire fonctionner Metro [sous MacOsX] est un vrai défi. Il faut utiliser des librairies endorsed pour avoir Jaxb 2.2 (j’ai du aller les chercher à la main dans glassfish V3, un vrai bonheur…). Pour lancer les tests, c’est aussi le même problème, il faut ajouter des -Djava.endorsed.dirs pour que cela démarre.
Finalement :
A vous de choisir !
En prod sur GlassFish v3 c’est du « finger in the noze »
Y’a plus qu’à renommer l’article…
Certes, metro sur GLassfish V3 ca marche, mais CXF c’est « finger in the noze » sur n’importe quel environnement / n’importe quel serveur d’app
mouais, faut juste trimbaler le(s) bon(s) JAR(s) et s’assurer qu’il n’y a pas de conflit avec d’autres bibliothèques. Quid d’un serveur qui utilise/bundle CXF?
Personnellement, je préfère l’approche d’un serveur le plus léger possible (jetty, tomcat) et un bon outil qui me gère le pakaging et les dépendances (maven).
Mais on s’écarte un peu du sujet initial là …
Super intéressant comme petite comparaison ! mais tu sembles plus comparer la partie marshalling/databinding (jaxb vs abd vs xmlbeans.) que les implémentations de soap.
Perso je préfère aussi le couple jaxb2+CXF > 2.2
J’ai déjà fait joujou avec JOnAS 5.1 qui embarque un CXF 2.0. Bilan : ça marche tout seul, mais il faut bien un CXF 2.0 à proximité si on veut générer des classes Java à partir du WSDL (en mode contract-first).
Le problème avec Metro, c’est qu’on peut se retrouver avec des conflits par rapport aux implem comprises dans Java 6…
Franchement je ne vois pas pourquoi avoir JAX-WS dans le JDK pose problème. L’utilisation des endorsed classes est clairement documentée et pas bien compliquée à mettre en oeuvre.