CXF ou Axis ? Quelques chiffres

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…


15 commentaires sur “CXF ou Axis ? Quelques chiffres”

  • 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.
  • 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 :
    • le code généré est identique en taille à celui généré par CXF (normal, c'est aussi Jaxb qui assure le binding)
    • le code de test est identique à celui utilisé pour CXF (modulo la création du bouchon)
    • au niveau performance, Metro est a peu près 2 fois plus rapide que CXF, autant à l'initialisation que lors de l'exécution.
    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 :
    • Metro et CXF génèrent un code de la même taille et quasiment identique pour le développeur qui l'utilise
    • Metro est environ 2 fois plus rapide que CXF pour les tests que j'ai pu faire
    • Par rapport à Metro, CXF est beaucoup plus facile à rapide à mettre en place (dans un environnement de développement ou de production)
    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.
  • Merci pour le partage de ton expérience. Je pense que pour pouvoir être le plus proche possible de la réalité, il aurait fallu comparer CXF et Axis 2 dans la même techno de mapping (disons JAXB). Car si les comparaisons ne se font pas dans des conditions identiques (techno de mapping XML, OS, complexité, volumétrie, réseau,... ) les résultats ne seront pas totalement fiable ;p Pour ma part, il y a quelques années, j'avais un projet en CXF 1.1 avec du XmlBeans de mémoire et bien c'était bien plus chiant que le projet sur lequel je suis en Axis 2 JAXB 2.2 (mais c'est un peu comme comparer une 4L avec une RCZ pour comparer Renaud et Peugeot... ). Je testerai bien le passage en CXF 2.3 si j'ai le temps un jour :)
    1. Laisser un commentaire

      Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *


      Ce formulaire est protégé par Google Recaptcha