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”
- 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 !