Sablés fourrés

SOAP, vous connaissez ? Je ne parle pas de détergent ni de série télévisée, mais bien d'un protocole informatique. SOAP, c'est la couche applicative/réseau de Talath, un jeu massivement multijoueur avec un client lourd en Java que nous avions développé pour notre projet de fin de DUT. Et nous avions décidé d'utiliser SOAP pour la couche communication du jeu.

Au début, ça paraissait bien : les sockets et leur prise de tête inhérentes aux entrées sorties : oubliées ; les méthodes de sérialisation à deux balles : envolées ! les problèmes de synchronisation avec le serveur : disparus ! Et en plus, c'est la classe, on utilise une techno mainstream, shinny, et je ne le savais pas encore à l'époque mais décideur-compliant. Avec SOAP tout est beau tout est joli tout est automatisé et automatique.

Oui, mais non. J'avais déjà du mal à l'époque à comprendre pourquoi Tomcat était aussi compliqué (je reste sur ma position, c'est une usine à gaz beaucoup trop polyvalente pour ce qu'on voulait faire au final), alors, rajouter de la complexité avec SOAP, on était pas au bout de nos peines...

L'idée, au départ, était d'utiliser un protocole récent et facile à mettre en place : SOAP. L'implémentation choisie, libre, était celle d'Apache. Ah oui, mais laquelle ? Apache SOAP, ou Apache Axis : et oui, les ennuis commencent : deux implémentations pour la même chose. Mais ce n'est pas fini. Officiellement, les deux sont compatible, dans le monde merveilleux de l'interoperabilité. Dans les faits, Apache SOAP est peu/pas documenté et pas bien finalisé, voir encore en developpement. Et ça semble être le bordel. De l'autre coté, Axis, bah c'est pareil, mais c'est mieux parce que c'est plus récent. Et rigolez pas, parce que les deux versions sont toujours en ligne.

Dans les deux cas, les docs sont succintes, et surtout les exemples sont toujours triviaux. En gros, avec SOAP, envoyer un mot, c'est simple, mais dès qu'on passe des paramètres plus complexes, il n'y a plus personne. Dans ce cas, une bon protocole binaire sur une socket, et c'était réglé. Bon, evidemment, Axis n'était absolument pas capable de gerer les structures de données géantes qu'on s'envoyait entre client et serveur. Pour ça, il nous fallait un sérialiseur XML.

Alors, on s'est dit qu'on allait utiliser Castor. Le truc qui génère du XML plus vite que son ombre. Castor, à l'époque, c'était bien mais pas non plus très fini. Et ça gerait pas non plus les grosses structures de données de façon très automatique... À pis pour l'intégration avec Axis, ça n'a pas été joli joli... Bref, pour moi, SOAP était une impasse, mais je n'avais pas le recul nécessaire pour dire "stop, on utiliser un truc trop complexe et pas assez finalisé".

Depuis, je n'ai plus jamais retouché à SOAP. J'ai refais un peu de XML au travers de xerces en C++ et de l'objet minidom de python. Depuis, j'ai aussi compris ce qui se cachait derrière le DOM et SAX. Bref, j'ai compris qu'on avait pas commencé par le bon bout, d'une part, et que d'autre part, SOAP était un paquet de noeuds sans nom.

Et aujourd'hui, je suis tombé^[1] sur cette page où l'on peut lire un dialogue fictif entre un developpeur et un ayatola du SOAP. Et je me suis finalement reconnu dans ce dialogue... http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-stands-for-simple/

C'est la saga tirée d'une histoire d'Agatha Christie qui passe sur France 2 en ce moment. C'est très sympa :-)

En ce moment, j'ai de moins en moins le temps pour glander ou développer mes pensées le soir sur ce blog. Et au bureau, j'ai pas non plus trop le temps, du fait du boulot.

C'est pas que j'ai rien à dire, mais en général, quand une idée sympa me passe par la tête, je suis soit dans la rue, soit dans le RER, ce qui n'aide pas à la redaction dudit message... Et après, bah j'oublie ce que je voulais dire. Ou alors parfois, ce sont des choses qui n'ont pas à figurer ici.

Bref, tout ça pour dire que ce n'est pas évident.