Des trois petits cochons à SOAP

October 12th, 2004 par Freddy Mallet

Petite histoire (à ne pas trop prendre au sérieux) suite à la lecture de cet article intéressant sur les dérives de la normalisation autour du concept des web services:

Il était une fois CORBA, RMI et DCOM. Ces trois petits cochons faisaient rougir de jalousie toute la basse-cour au vue de leur capacités:

  • Transparence quasi totale de la distribution des objets
  • Gestion des transactions distribuées
  • Load balancing
  • Fail over
  • Découverte dynamique des interfaces
  • Interopérabilité avec des cochons grecques, anglais, etc… (au moins pour CORBA)
  • Sécurité à la fois au sens cryptage, authentification et droit d’accès
  • etc.

Bref des cochons dignes de participer à Top Gun. Pour tester ses cochons, l’agriculteur commença par leur soumettre un problème relativement simple (tout est subjectif): Faire un système de base de gestion de blogs en java. Force était de constater que cette mission aurait pu être donnée à n’importe quel cochon à très bas prix (php + mysql) alors par excès d’orgueil les trois cochons mirent tout de même un point d’honneur à utiliser l’ensemble de leur palette et par conséquent l’agriculteur se retrouva avec un wiki state-of-art qui lui coûta la peau du cul et que seuls ces cochons extraterrestres étaient capables de maintenir à prix d’or.

L’agriculteur fut un poil refroidi mais leur laissa tout de même le bénéfice du doute. Le deuxième test consista à faire un site web style www.ldlc.com avec capacité de montée en charge illimitée sur un beau bouquet de serveurs linux. Les petits cochons fous de joie accouchèrent d’un beau porcelet plein de composants potentiellement distribuables. L’agriculteur intégra donc le produit, distribua les composants sur plusieurs machines et… patatra les perfs furent lamentables. L’agriculteur alla consulter ses druides Martin Fowler et Marc Fleury qui lui dirent un truc du genre:

“Mon bon ami, la distribution transparente des objets est semblable à la quête du graal. En effet, par définition, une bonne conception objet implique une granularité relativement fine des interfaces. En gros ça veut dire que sur l’objet Address vous allez trouvez des méthodes getCity(), getStreet(), getCountry(), etc. Dès que vous allez vouloir utiliser cet objet à distance, les cochons qui vous ont dit que le réseau était transparent vont commencer à vous expliquer que le coût en temps d’appel d’une méthode in-process ou sur un serveur distribué n’est pas tout a fait le même. Ils vont donc vous conseiller soit de faire tourner vos objets sur la même machine et si possible dans le même process et/ou de revoir les interfaces des objets distribués. Ils vont par exemple transformer l’objet Adress en tableau pour transférer en une seule fois l’ensemble des infos de l’objet Adress et ainsi réduire le coût de l’appel distant -> bravo la conception objet! Dans un monde idéal nous vous conseillons de ne pas faire d’entorse à la conception objet et de faire tourner tous les composants dans le même process. Si vous avez besoin de monter en charge vous faites alors des clusters (réplication de l’ensemble des composants sur une autre machine mais sans interaction entre les machines). Pour finir chaque cluster offre une interface d’accès conçue dès le départ pour un fonctionnement distribué (Pattern: Layer Service)”

L’agriculteur compris alors que la distribution et par conséquent la gestion des transactions distribuées n’avait que peu d’utilité pour son utilisation personnelle.

Pour son troisième test, l’agriculteur fit venir un cochon grecque pour tester l’interopérabilité. Quand les trois cochons demandèrent au cochon grecque sa version IIOP, ce dernier leur mit son point dans la gueule et la rencontre prit fin.

Entre le troisième et quatrième test, l’agriculteur se demanda dans quel cadre il pourrait bien utiliser le service de découverte dynamique des interfaces des composants distribués. Aux dernières nouvelles l’agriculteur se pose toujours la question. Cette fonctionnalité est en effet seulement utilisée par les agriculteurs australiens.

Pour son quatrième test, l’agriculteur plaça de manière intentiné perverse un firewall entre les objets distribués. Ca a légèrement énervé les cochons (style les cochons du film ‘Hannibal’). C’est vrai quoi après tout c’est pas très fair-play.

Pour son cinquième test, l’agriculteur demanda aux cochons de lui montrer le système de load-balancing sur le bus CORBA de Borland (visibroker). Autant vous dire que les cochons étaient dans leur petits sabots quand ils durent avouer à l’agriculteur qu’en guise de load-balancing on trouvait du round-robin.

L’agriculteur compris qu’il était inutile de pousser trop loin l’investigation et qu’en fait les trois petits cochons étaient certainement très biens mais de loin et de préférence chez le voisin histoire de foutre le bordel chez le concurrent.

############
pub milka
############

L’agriculteur vira donc ces trois petits cochons et recycla un de ces vieux cochons qu’on trouve le soir à traîner sur les URL des sites des produits open-source. Le vieux cochon fit une première version rapide en utilisant un conteneur léger du style hivemind, hybernate pour l’accès à la base, Tomcat pour le conteneur de servlet/jsp, et struts. De plus, en guise de Layer Service pour accéder aux objets métiers s’exécutant au sein d’hivemind, il utilisa simplement du XML/HTTP. Pour ce qui est de la montée en charge et du load balancing, le vieux cochon conseilla de clusteriser tomcat et hivemind et d’utiliser un soft de load balancing HTTP du style resonate entre les deux et que sans miracle cela fonctionnerait. L’agriculteur compris aussi que dans ce cas le test de l’ajout d’un firewall entre tomcat et hivemind risquait de laisser totalement indifférent notre vieux cochon.

Et à partir de ce succès le vieux cochon commença à déraper et c’est justement l’objet de l’article auquel je fais référence au début de cette histoire. En effet le vieux cochon suivit le raisonnement décadent suivant:

  • c’est que ce service n’est pas auto-descriptif donc je vais ajouter un langage de description d’interface: WSDL (A titre personnel, un bon document XML ça me semble doter d’un pouvoir auto-descriptif presque surnaturel puisque j’arrive à comprendre ce que je vois)
  • le problème c’est que je ne peux pas découvrir dynamiquement les services disponibles par exemple sur Internet donc j’ajoute UDDI (ce doit être un de ces agriculteurs australiens qui lui a mis cette idée en tête)
  • le problème c’est que lorsque je fais du XML/HTTP ce n’est pas transparent pour mon programme donc je fais du SOAP
  • le problème c’est que http c’est synchrone donc je porte SOAP sur SMTP puis sur JMS
  • le problème c’est qu’en SOAP je n’arrive pas à accéder à mes vieux composants CORBA donc je fais une passerelle SOAP/CORBA
  • etc.

Bref le vieux cochons rejoignit finalement les trois petits cochons chez le voisin car il avait lui aussi succombé aux sirènes de la théorisation.

moral de l’histoire: c’est pas facile de miser sur un bon cochon de nos jours!

2 Responses to “Des trois petits cochons à SOAP”

  1. Eric Says:

    Conclusion: et voilà pourquoi le prix du porc a augmenté…

  2. Franck Says:

    Vraiment excellent ;-)
    Bon pour chipoter, je poserais des questions sur la partie clustering tomcat qui est un peu trop automagically !

Leave a Reply

You must be logged in to post a comment.