[toulouse-pm] TPC (4)

Michel Rodriguez mrodrigu at ieee.org
Wed Jul 24 11:00:35 CDT 2002


SOAP

Et oui! C'est l'apres-midi buzzword!

Ca commence comme d'habitude avec une photo de bebe, MJD soit maudit!
Par Ian Kallen, qui bosse pour Covalent si j'ai bieng suivi. Il a bosse
pour salon.com avant, excellent site web au passage.

Puis pub pour Teach Yourself Apache 2 in 24 hours, il y aura un tirage
au sort pour en gagner un exemplaire a la fin de la session. Un conseil
quand meme: ne pas lire le livre en 24 heures consecutives. Pratique!

Apparement le tutorial utilise Java et Perl. Damn! Java! Horreur malheur!

SOAP: Simple Object Access Protocol. C'est un des protocoles pour faire
des Web Services. Le protocole de transport peut etre HTTP (en general)
mais aussi SMTP, Jabber... (SOAP::Lite en Perl a probablement le plus
de protocoles differents)

WSDL est le protocole qui decrit les services offerts et UDDI "publie"
le service (Ian le decrit comme le DNS des Web Services).

Il decrit RSS comme un proto-protocole dans le genre (je suis assez
content
du mot proto-protocole).

Mythes (faux) a propos de SOAP:

- c'est simple (il faut se taper XML, les W3C Schemas plus SOAP pour
implementer SOAP),
- c'est a propos d'objets (nope, 'est juste des donnees),
- il y a un web dans web service (ca utilise souvent HTTP, mais
ca n'a pas de lien direct avec le web),
- ca s'integre facilement avec .NET (pas vraiment le cas d'apres lui),
- il faut connaitre XML pour l'utiliser (nope, le bas niveau est du XML,
mais l'utilisateur ne le voit pas),
- le standard est mature (non, il y a beaucoup d'outils, souvent
cher, mais rien de vraiment solide et qui communique sans probleme avec
d'autres outils),
- ca fait tout et le cafe ("don't believe the hype!", faire un proto
d'abord)

Mais ce qui est vrai:

- c'est ouvert, on peut implementer son truc dans le langage qu'on veut,
- ca peut utiliser different protocoles de transport
- c'est independant des vendeurs (ca veut pas dire que les outils marchent
bien ensemble, juste que personne ne domine completement le standard)
- chaque langage a sa propre maniere d'implementer les objets
- il peut faire cooperer des systemes "loosely coupled"
- les applications n'ont pas forcement besoin de connaitre SOAP
- c'est un standard au lieu de protocoles proprietaires (ca sonne bien
aussi)
- ca peut traverser les firewall (NdM (Note de Mirod): pas bon a mon
humble
avis , mais bon, j'ai iptable actif sur la moitie de mes machines a
l'interieur de mon firewall...)

Le format d'une requete (non, je vais pas le taper, google devrait avoir
ca!)

WSDL definit les types de donnees et generalement les interfaces d'un
service.
En generalement c'est des gros paves!

Si on utilise directement les messages SOAP on doit se taper le processing
du XML qui contient les donnees. Si on utilise SOAP-RPC le message est un
appel de procedure. Les outils se debrouillent d'apres ce que je comprends
(Ndm: OK, d'apres ce que je _sais_ SOAP::Lite est completement Magique
(tm)).

A la base les types de donnees sont les memes que dans XML W3C Schema (on
cree des types complexes avec W3C Schema (NdM: bonjour le mal a la tete,
mais bon, je suis pas trop impartial, je deteste tous les standards XML a
part XML lui meme , XPath et des bouts de SAX).

En cas d'erreur le message contient uniquement une erreur

Bon, apres tout ca on rentre dans le domaine des outils qui masquent tout
ca: JWS pour Java: cote server c'est simple, on doit juste renommer le
.java en .jws (NdM: ah les joies des extensions!) et on le met dans le
repertoire qui va bieng. C'est un peu plus complique cote client. Diable!
Il faut ecrire du code! Les classes ne peuvent as etre compilees, le
serveur doit avoir acces au source.

Cote Perl le client est juste un liste d'appels de methode chaine'es. Le
serveur change pas. Regarder la doc de SOAP::Lite, c'est beau! Sans rire,
si on vous demande de faire du SOAP precipitez vous sur SOAP::Lite
(recent, il y avait un gigantesque pb de securite il y a pas longtemps).
Vous ridiculiserez vos collegues Java (surtout que l'outil Java genere des
messages qui plantent avec les ouils Microsoft).

Pour installer un serveur SOAP avecmod_perl il suffit d'ajouter un
directive Location dans la config Apache. Le code du server ne change pas
par  rapport a du code local (les return des fonctions dans le package
sont SOAP-es).

Le gars a son serveur web en ligne pour la demo depuis 30mn et il a deja
des tentatives d'intrusion de virus IIS!

Un truc pas joli avec SOAP::Lite c'est que le XML transmis (il nous le
montre avec un sniffeur) est tout sur une ligne. Mais bon, c'est legal.

SOAP::Lite se debrouille generalement bien avec les conversions de types.
Juste des fois si une chaine de carateres ressemble a un nombre il envoie
un nombre. C'est pas grave si en face c'est aussi du Perl, qui convertira
gentiment en string si il faut, mais ca posera desproblemes a des langages
plus fortement typees comme Java.

Il donne quelques moyens de simplifier l'installation avec Java, je
l'ignore.

Pour publier un web service en Perl: ajouter un ligne a la liste d'appels
de methodes.

Fais chier, je crois que je suis malade, ma femme a ca aussi, j'ai froid
et je suis creve. Ceci dit j'ai pas dormi beaucoup la nuit derniere, alors
ca ira peut etre mieux demain. Demain c'est loin ceci dit, alors vous
etonnez pas si je finis pas le cours :--(

Pause, cafe, il fait chaud dehors (la clim doit etre regleea -15 ici!), ca
va mieux.

Un vrai example, genre e-business.

D'abord avec Java, c'est l'heure de lire /. sur Mandrake 9.0 beta (NdM:
cette phrase etait dediee aux trolls du CULTe). Il patauge un peu avec la
demo, l'ecran est trop petit... ah bon, c'est fini, ouf!

Il montre un client Perl pour le serveur qu'il a ecrit en Java. Il faut
ajouter une ligne plutot coton pour deserialiser proprement les donnees
emises par le serveur. Ah maintenant il montre la vrai facon de faire,
avec WSDL. Ca marche sans verrue horrible. Et maintenant il utilise la
magie de SOAP::Lite pour autogenerer des accesseurs.

Il liste des implementations dans d'autres langages.

On arrive a la fin, il complimente SOAP::Lite (moi aussi), il repete que
le standard n'est pas mature et qu'il a des trous qui conduisent a des pd
de compatibilite. L'en-tete HTTP Host est souvent mal traite, ce qui cause
des problemes avec les outils MS qui sont tres strict sur ca.

UDDI progresse lentement, mais pour l'instant pas vraiment
d'implementation interessante.

La securite n'est pas traitee a ce niveau (HTTPS bonjour, mais a mon avis
ca va creer des problemes ou les niveaux vont se melanger). Comme il dit
c'est Microsoft qui pousse ces standards, donc faut pas s'attendre a un
truc trop sur a la base.

Desole de taper sur Java et MS autant, mais bon,deja je les aime pas trop
c'est vrai et en plus l'instructeur tape sur MS et me montre du code Java
10x plus long que la meme chose en Perl.

Avec SOAP::Lite et mod_perl Apache::Session peut aider a gerer une session
raisonablement sure (me demandez pas comment, c'est un exercice pour le
lecteur).

C'est fini,au bout du compte c'etait plutot ennuyeux, mais bon, j'aurais
du m'y attendre, SOAP c'est pas vraiment un domaine ou on rigole tous les
jours!

Apres ca je me sens vraiment pas en forme et je vais me coucher!

Autres

Lecon apres seulement 2 jours de conference: n'emmenez pas votre epoux(se)
ou "significant other" comme y disent ici a une conference si elle n'est
pas _extremement_ tolerante et qu'elle ne peut pas supporter 4 heures de
descendage de biere en causant de Perl, XML et de gens qu'elle ne connait
pas. Le taux de crises conjugales est deja impressionant!

Leon Brocard a l'air de bosser sur un nouveau film, genre le film de YAPC
mais sans les jurons (bouh!). Ingy recolte des photos rigolotes pour son
Lightning talk (j'en ai une ou Elaine lui met des raisins dans la bouche,
a la romaine, je la posterai demain, je peut charger la photo sur mon
portable dans ma chambre mais ya pas de connection rapide a cet etage
!@##$%%^&*).

Michel Rodriguez
Perl & XML
http://www.xmltwig.com





More information about the Toulouse-pm mailing list