16 Juil 2007, 11:07
Défaut:
by

2 comments

« S » comme « Simple »

Deux personnes dans le dialogue suivant : un développeur (DEV) et un promoteur de SOAP.

  • DEV: Mon boss a joué au Golf cette semaine, et maintenant je dois rendre l’entreprise « SOAP-enable », mais je ne sais pas ce qu’est SOAP. Peux tu m’aider ?
  • SOAP: Bien sûr. Tout d’abord SOAP signifie « Simple Object Access Protocol ».
  • DEV:Alors c’est simple ?
  • SOAP: Simple comme un bonjour, mon ami.
  • DEV:Ok, vas-y.
  • SOAP: Bien, comme son nom l’indique, SOAP sert à accéder à des objets distants.
  • DEV:Comme CORBA ?
  • SOAP: Comme CORBA, mais en plus simple. Au lieu de protocoles de transports complexes que personne ne laisserait franchir un firewall, nous utilisons HTTP. Et à la place de messages binaires nous utilisons XML.
  • DEV:Je suis intrigué. Montre moi comment çà marche.
  • SOAP: Bien sûr. D’abord il y a l’enveloppe SOAP. C’est très simple. C’est juste un document XML avec une entête et un corps. Et dans le corps tu fais ton appel aux procédures distantes (RPC).
  • DEV:Tout est un histoire de RPC alors ?
  • SOAP: Absolument. Comme je le disais, tu fais ton appel RPC en mettant le nom de la méthode et ses arguments dans le corps d’un document XML. Le nom de la méthode est le chapeau, et chaque sous-élément est un paramètre. Et tous les paramètres peuvent être typés en suivant les spécifications ici, dans la Section 5 de la spécification.
  • DEV🙁lit la Section 5). Ok, c’est pas si mal.
  • SOAP: Puis, quand ton service est déployé, tu précise les destinations (endpoint).
  • DEV:Destinations ?
  • SOAP: Les destinations, les adresses du service. Tu POST ton enveloppe SOAP vers des URIs de destinations.
  • DEV:Et si je fais un GET sur une URL de destination, il se passe quoi ?
  • SOAP: Je ne sais pas. GET a un comportement non défini.
  • DEV:Hmm. Et que se passe-t-il si je déplace un service vers une nouvelle URL ? Est-ce que j’ai un 301 en retour ?
  • SOAP: Non. SOAP n’utilise pas vraiment les codes réponse de HTTP.
  • DEV:Donc quand tu dis que SOAP utilise HTTP, tu veux en fait dire que SOAP passe par HTTP, comme on passe dans un tunnel.
  • SOAP: Tunnel est un mot si vulgaire. Nous préférons dire que SOAP n’a pas de religion en matière de transport.
  • DEV:Mais HTTP n’est pas un protocole de transport (ndt : contrairement à ce que dit le sigle) mais un protocole d’application. Peu importe, quels autres « transports » SOAP supporte-t-il ?
  • SOAP: Et bien, officiellement aucun. Mais tu peux potentiellement les supprter tous. Et il y a beaucoup de plate formes qui supportent JMS, FPT, SMTP.
  • DEV:Mais qui utilise ces autres transports ?
  • SOAP: Euhh, personne. Mais le fait est que c’est possible.
  • DEV:Bien. Et àlors, cet entête (header) HTTP « SOAPAction » çà sert à quoi ?
  • SOAP: Pour être honnête, personne n’est vraiment sûr.
  • DEV:Et cet attribut « actor », ou encore ce « mustUnderstand », est-ce que quelqu’un les utilise .
  • SOAP: Non pas vraiment. Oublie-les.
  • DEV:Très bien, laisse moi essayer un coup pour voir.

(le temps passe)

  • DEV:Bien, j’ai pratiquement réussit à faire marche le tout, mais uniquement si je reste avec une seule pile SOAP. En fait, je ne peux pas vraiment dire que j’aime cette idée d’appel de procédure à distance avec ces objets sérialisés.
  • SOAP: Appel de procédure à distance ! Objets sérialisés ! Mais où as-tu vu que SOAP faisait des RPCs ? SOAP ne fait que faire passer des messages sous forme de documents, mon ami.
  • DEV:Mais tu as dit que …
  • SOAP: Oublie ce que j’ai dit. A partir de maintenant nous passons à une large granularité des messages – tu aimes cette expression « large granularité des messages ». Des messages qui se conforment à des Schéma XML. Nous appelons Document/Littéral le nouveau style et RPC/Encodé le vieux style.
  • DEV:Schéma XML ?
  • SOAP: Oh, çà fait fureur, c’est l’avenir. Jette un oeil.
  • DEV:(lit les spécification XML Shema). Sainte mère de dieu : préservez nous de ce casse tête !
  • SOAP: Ne t’inquiète pas. Tes outils vont créer le schéma pour toi. Vraiment, tout est dans les outils.
  • DEV:Et comment les outils vont faire cela ?
  • SOAP: Ils vont analyser ton code (si c’est faisable) et générer automatiquement un schéma compatible.
  • DEV:Analyser mon code ? Mais je croyais que tout était dans le document et non dans des objets sérialisés et encodés.
  • SOAP: Tu m’a bien écouté ? Tout est dans les outils. De toute manière on ne peut pas raisonnablement écrire des Schémas XML ou des WSDL à la main. Et après tout, c’est just ede la plomberie. Tu n’as pas à t’en occuper.
  • DEV:Oulà attends. C’était quoi ce mot ? Wizzdle ?
  • SOAP: Oh, je n’ai pas mentionné WSDL ? Webs Services Description Language. Ça décrit la manière dont tu spécifies les types de données, les listes de paramètres, le nome des opérations, les contraintes de transports, les URIs, afin que des tierces parties puissent accéder à ton service. Jette-y un oeil.
  • DEV:(lit les spécifications WSDL) Je crois que celui qui a écrit çà était drogué. Cà n’a aucun sens. Et puis c’est quoi toutes ces contraintes sur les GET de HTTP ? Je croyais que que GET était avait un comportement non défini ?
  • SOAP: Ne t’inquiète pas, personne n’utilise çà. et puis les outils vont générer le WSDL, et le WSDL sera le schéma.
  • DEV:Mais cela ne devrait-il pas être l’inverse ? Les règles qui génèrent le code ?
  • SOAP: Oui, c’est vrai cela devrait se passer ainsi. Mais en pratique ce n’est pas facile car peu de piles (stacks) supportent le développement à partir du WSDL. Laisse faire les outils.
  • DEV:Une autre question. Si maintenant on fait passer des messages compatibles avec un XML Schema, où spécifie-t-on le nom de l’opération.
  • SOAP: Et bien, tu te souviens de l’entête HTTP SOAPAction ? La plupart des gens le mettent là.
  • DEV:La plupart ?
  • SOAP: En fait, ce nouveau style n’est écrit nulle part.
  • DEV:J’ai également remarqué que votre activité est construite autour de spécifications qui sont ambiguës, parfois erronées et certainement non standardisées. En fait, les spécifications SOAP et WSDL ne sont que des notes du W3C, mêmes pas des documents de travail (working draft).
  • SOAP: On y travaille.
  • DEV:Tout cela va me donner l’interopérabilité promise ?
  • SOAP: Tout à fait.
  • DEV:J’essayerai

(le temps passe)

  • DEV:C’est une horreur. Le WSDL généré par mes outils est inexploitable par les outils de mes partenaires. Plus que çà même : les schémas générés sont impénétrables et ne peuvent être réutilisés. Et aucun outil n’est d’accord dans la façon de prendre en compte le SOAPAction de mon entête HTTP.
  • SOAP: Je suis désolé pour toi. En fait plus personne n’utilise le style Document/Littéral. Afin de retrouver l’indépendance vis-à-vis de la couche de transport, nous utilisons tous le style « wrapper-doc/Lit » maintenant. C’est pas cool ?
  • DEV:C’est quoi ?
  • SOAP: C’est comme Doc/Lit, mais tu prends tout le message et tu le mets dans un élément qui a le même nom que l’opération. Ainsi le nom de l’opération revient dans le message auquel elle appartient.
  • DEV:Ok, elle est où la spec ?
  • SOAP: Euh, il n’y en a pas. C’est juste ce que Microsoft semble faire. On dirait une bonne idée, alors tout le monde le fait. En plus, il y a une nouvelle chose. Tu vas aimer. Cà s’appelle le Web Services Interopérability Group, ou WS-I. Ils essayent d’éliminer un maximum d’ambiguités des spécification SOAP et WSDL. Je sais que tu aimes les specs.
  • DEV:En d’autre mots, les spécifications était si mauvaise que vous avez eu besoin d’une démarche de standardisation des standards. Mon Dieu, est-ce cela qui va résoudre mes problèmes d’interopérabilité ?
  • SOAP: Oh oui. Tant que tu utilise une pile compatible WS-I, évite d’utiliser 8/10 schéma XML, n’utilise pas des types de données inhabituels, et n’essaye pas d’utiliser WebSphere et Apche Axis.
  • DEV:Et est-ce-que l’explication à wrapped-doc/Lit est donné alors ?
  • SOAP: Euuh non. Mais c’est pas grave car tes outils le comprendront. La plupart en tout cas.
  • DEV:Résumons-nous. La définition de SOAP est en pertétuel mouvement, SOAP est tout sauf simple, et il ne sert plus à adresser des objets distant même si c’est ce que les outils continuent à faire.
  • SOAP: C’est presque çà, mais on a quand même une longueur d’avance sur çà. Nous avons changé la définition de l’acronyme SOAP.
  • DEV:Vraiment! Et qu’est ce que çà veut dire maintenant ?
  • SOAP: Rien

(héberlué)

  • SOAP: Je t’ai parlé de UDDI ?

Ce dialogue est une traduction rapide de celui produit par Pete Lacey.

vraiment excellent, on ne s’en lasse pas 🙂

Merci pour la traduction… J’espère que le buzz va s’emplifier autour de REST…

[Reply]

 

Répondre à genium Annuler la réponse

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

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.