web services vs. leurs implémentations

Cela fait un bout de temps que je voulais m'intéresser de plus près aux web services et l'occasion m'en a été donnée lors de mon stage de cet été. L'objectif été de créer une plateforme SOA et nous avons commencé à investiguer pour trouver la solution idéale. Sur le papier, les web services apparaissent comme quelque chose de fantastique. Et ça l'est si l'on regarde les différentes spécifications. Une parfaite utilisation d'XML et des namespaces permettent un nombre inconsidérable de possibilités. Seulement voilà, et vous ne pourrez pas me contre-dire, les spécifications et les implémentations sont rarement les meilleurs amis du monde! Lors de notre enquête, nous avons testé les principaux acteurs open source pour la mise en place d'un serveur sous linux: AXIS pour Java, gSoap pour C/C++, SOAP4R pour ruby, python et PHP. Je ne discuterai pas de python, 1) parce que je ne connais pas le langage et 2) parce que je ne l'ai pas testé, mais on ne m'a pas dit du bien de son implémentation des web services. Nos besoins étaient pourtant simples (!): un maximum d'interropérabilité (WS-I) dans une solution qui s'intègrerait bien à l'existentiel et facile à maintenir!

Le premier que j'ai testé fut AXIS pour Java (http://ws.apache.org/axis). Probablement l'implémentation la plus fidèle, pratiquement rien à redire même. Un bundle d'outils bien pratique (comme le proxy pour intercepter les requêtes), un excellent respect des recommandations. L'outil de conversion d'un WSDL vers son implémentation produit un code très bien structuré, propre et clair. Beaucoup de points forts donc. Malheureusement, java demande des serveurs puissants pour tenir la charge (qui risque d'être assez conséquente) et aucun développeur java ne travaille pour la boîte. Il n'en reste que j'ai était séduit par cette solution. gSoap maintenant (http://www.cs.fsu.edu/~engelen/soap.html). Là aussi une implémentation fidèle. Le package comprend aussi deux outils pour transformer un .h (formaté de façon particulière) vers un WSDL et son implémentation en C/C++, ou un WSDL vers cette même implémentation. gSoap dispose même de fonctionnalités intéressantes, comme la possibilité d'étendre les normes supportés, les typemaps...La description du service sous forme de .h rend celle-ci plus lisible que le WSDL et la conversion vers ce dernier est plus que correcte. L'implémentation DOM intégrée est un super plus. Côté mise en place, gSoap construit le code pour faire un serveur indépendant. Ce dernier tient très bien la charge (on s'en doute, c'est du C ;) ). En revanche, côté maintenance, c'est aussi du C, donc plus chiant! Coder un grand nombre de services rapidement n'est pas l'idéal. Arrive Ruby. Je reviendrai sur ce langage plus tard, mais je peux tout de suite vous dire que je suis loin d'être fan. SOAP4R (http://dev.ctor.org/soap4r) est une implémentation Ruby des web services et je dirais: qu'elle horreur! Cela ne me surprend plus de la part des rubiiste (??!), une documentation légère et seulement les parties des recommandations et des spécifications qui leur plaisent sont conservées! J'exagère peut-être mais je n'en reste pas moins très déçu. Tous les tests ont été réalisés en utilisant un unique WSDL (un tantinet complexe je l'avoue). Et bien Ruby est le seul qui ne l'a pas compris. Impossible de le charger. Les tests ont vite aboutis! Pourtant, la mise en place est rapide et la maintenance facile. Dommage, puisque beaucoup de développement été déjà réalisés en Ruby. PHP enfin. Leur implémentation, SoapServer (http://fr2.php.net/manual/fr/ref.soap.php), est plutôt bonne malgré quelques points négatifs. La mise en place est la plus rapide, pas de génération, il suffit de créer une nouvelle instance avec le WSDL en paramètre (langage de script quoi). Seulement, il manque quelques fonctionnalités présentent dans les deux premiers et qui en aurait fait une "excellente" implémentation: la validation des réponses n'en est pas vraiment une (élimine seulement les morceaux qui ne sont pas compatibles avec le WSDL), pas de gestion des SOAP headers (le client les gèrent par contre), pas de génération de WSDL, pas de mappage automatique des types XSD...à côté de cela il tient bien la charge et le tout est très facile à maintenir. Du coup je me suis dit pourquoi ne pas étendre la classe SoapServer pour lui retirer ces quelques défauts? Aussitôt dit aussitôt fait! Je publierai bientôt cette classe mais elle gère la validation, les headers et les web services peuvent être écrit sous forme de classe (comme un contrôleur, avec une méthode before et after...). Finalement, c'est donc la solution PHP qui a été retenue pour tous les web services sauf un qui sera géré par gSoap. La solution PHP tient très bien la charge, ne demande pas un serveur monstrueux et est facilement extensible et maintenable. Du côté de gSoap, il tient encore mieux la charge (nécessaire pour ce service particulier) et permet de faire des choses plus complexes (c'est du C!). gSoap a aussi été retenu pour la partie client, les développements se faisant en C. D'autres solutions existent probablement et ce billet est loin (loin) d'être exhaustif. PHP à une autre implémentation montante (par dessus SoapServer en fait): SCA (http://fr2.php.net/manual/fr/ref.SCA.php). Toujours expérimentale mais à suivre. Il existe aussi une implémentation AXIS pour php, encore trop jeune aussi. Finalement, c'est probablement le monde Java qui dispose de la meilleure implémentation à mes yeux. Je reviendrai rapidement sur les WSDL en particulier. Un monde à eux tout seul !

comments powered by Disqus

08/10/2007