Comprends pas pkoi tout le monde fait une pendule à 14 coups à propos des web services et de soap...
On peut pas transporter de types ni que dalle, c'est d'un pratique... (autant faire du TCP directement à la limite...)
 
Pour ceux que ça intéresse, voici comment charger une image depuis un web service... (ici le web service dessine une chaine de caractères dans un PNG, puis l'envoie comme résultat)
 
Service :

 
Client :

 
Je vous raconte pas comment ça doit être commode quand on joue avec des types complexes, genre un graph...

Très franchement, mise à part l'absence de listner et d'emmerdement de recyclage des ressources, je ne vois pas en quoi ça diffère de la bonne vieille architecture TCP... Transport réseau ? Et qu'est-ce qui m'empêche de passer par le port 80 si les admins savent pas paramétrer un routeur ?

avec un WS, tu encapsules ta logique métier dans des objets que tu peux partager
un peu plus haut niveau que TCP, tu trouves pas ?

ze only matter, c'est que je ne peux transmettre mes types que via des strcutures de types simples.
super pratique quand je dois transmettre un graph ou autre objets structurés.
 
je pensais que les WS offraient une interface capable de transporter un type complexe plutôt
 
pour le reste, mise à part s'affranchir du protocole de communication, je ne vois aucune différence avec un simple client/serveur TCP. POP ou IMAP par exemple, permettent de transporter des données bien plus complexes que 3 strings encapsulées dans 20 Mo de XML...
 
berf, franchement pas convaincu par la chose. quand on regarde bien, c'est encore un super consortium qui nous veut que du bien qui a homologué la roue en bois à l'heure des chambres à air... ça doit être pareil que pour le XML, qui n'est ni plus ni moins que la même chose. tout un tas d'autre système de stockage/transfert de données existaient, dont la plupart notamment plus performants ou aisément lisibles, mais le marketing a eu raison de la logique.
 
je dis pas que c'est mal. je dis juste que je suis franchement déçu, je m'attendais à mieux.

t'as regardé du coté de DIME ? (pour les attachements)
Sinon, je suis assez d'accord par rapport au coté 'hype' des WS, ça n'a rien d'une révolution

renseigne toi mieux alors .  
 
Jamais tu n'arriveras a avoir la facilité qu'offre les WebServices avec une connexion TCP.
 
N'oublie pas que TCP c'est du mode connecté ce qui amene vachement beaucoup de contrainte. Je vois mal utiliser une connexion TCP entre deux clients sur internet.  
 
De plus les problèmes de firewall ne sont pas résolu en TCP. Or avec les Web Service, comme ça passe avec HTTP ça va tout seul. Moi je ne vois que des avantages par rapport à des connexions TCP classiques.
 
De plus, les Web Services sont multi plateforme et multilanguage, ce n'est pas le cas des applications réseaux.

moi23372 > euh... renseigne-toi toi-même donc...
 
là, je bosse sur un ERP.
dans la même version, je peux me connecter depuisun client lourd sous Windows, une console telnet depuis n'importe quel OS, ou même une URL intranet. C'est le même exe qui gère tout ça, et y'a pas l'ombre d'un web service dedans.
Les temps de réponse sont de 1 pour 1000 par rapport à un web service (sauf pour la version intranet evidement), l'appli est 100% multilangue, multiplateforme et surtout, massivement multiutilisateur.
 
T'ira faire du VNC en WS aussi toi...
 
Bref, tu t'emmerdes plus à écrire le truc, mais très franchement, les WS n'apporte aucune fonctionnalité. Le coup des firewall, ça me fait rigoler, parceque la pupart des sociétés passent par des proxy (source de merdes dans les consultations via WS) qui bloquent tout et ouvrent au cas par cas. Et pour les autres sociétés, en majorité on laisse tout passer c'est plus simple. Donc le support HTTP arrange les 5% des plus emerdeurs de la planète, trop paranos pour laisser les utilisateurs le soin de bosser, mais trop fénéant pour filtrer ce qu'ils font.
 
Bref
 
Je ne vois les WS que comme une surcouche "de moindre effort" genre "ben c'est déjà tout fait, donc je me contente de ses limitations", mais sorti de ça, y'a vraiment pas de révolution... Moi je m'attendais à un truc genre "l'invention de l'objet".
 
Sinon, y'a le RPC aussi qui existe... Ca marche plutôt pas mal, et étrangement, les services d'un réseau discutent plus souvent en RPC qu'en WS... Certainement une histoire de performance et de sécurité des transfert

il faut voir les webservices tels qu'ils sont. Ca te permet d'obtenir un flux qui peut être attaqué depuis n'importe quelle technologie, et en mode déconnecté.
Je travaille souvent avec un réferentiel commune (au sens les communes d'un departement). Et je ne suis pas le seul a l'utiliser, et les personnes qui developpent avec moi n'utilisent pas forcement les memes techno. Donc au lieu de faire une implementation en tcp & Cie sur n languages différents, j'ai un service qui peut etre attaqué. idem pour les problématiques de recherche sur un annuaire ldap et ainsi de suite.
 
l'autre avantage qu'il faut voir, c que la logique metier n'est pas dans ton webservice. Si tu as a faire une appli qui contient une couche de service, qui est appellé depuis une UI web ou client lourd, et que tu veux rendre disponible et accessible depuis d'autres projets , tu mets une "facade" webservice et ca roule.
 
Apres, le problème du tcp est le meme qu'en remoting. On peut dire oui, ce n'est qu'un problème de config de firewall et ainsi de suite....en attendant, dans la philosophie générale, ce n'est pas au développeur d'imposer les contraintes de sécurité à l'admin réseau en disant ouvre moi les ports x x x... mais au développeur de s'adapter
enfin, une opinion qui n'engage que moi

sinon en Java, y'a corba et rmi (mais jamais utilisé jusqu'à présent)...

Corba c'est relativement multi-languages, mais la mise en place ... argh

Remoting est l'equivalent de rmi (en gros , sinon les puristes vont me tomber dessus )  
et corba...jms vu de projet qui l'utilisaient reellement (sauf des thesards, mais ils sont à part [smileypastaper])

alien_man > je suis d'accord avec ton analyse du webservice. je ne remet pas en cause son utilité. le seul truc, c'est que je m'attendais à ce qu'il gère des flux un peu plus complexes que du simple xml "basique". je m'attendais notamment à pouvoir transporter des objets complexes de façon automatisée, sans devoir m'amuser à les décortiquer à la main. hors ce n'est pas le cas.
en fait, tu fous une page PHP, ASP ou autre sur un site web, qui accepte en POST des paramètres (ou un flux XML) et qui renvoie un flux XML en résultat, et t'as fait l'équivalent d'un webservice. je trouve la révolution plutôt limitée. notamment, pour un projet sur lequel j'étais à la bourre, c'est ce que j'ai fait : un post sur une page .NET avec un fichier XML, et la page qui va traîter les données reçues, puis renvoyer un résultat formatté en XML aussi. j'ai regardé les webservices pour voir si j'y gagnais quelquechose, et force est de constater que... mise à part une standardisation de mon implémentation, je n'y gagne rien au niveau fonctionnel...

 
Les données que je remonte sont souvent des datasets, car derriere, ca reste une structure "xml-like". Par contre, c vrai que je n'avais pas d'objets complexes dans mes datasets. Pour en mettre, il me semble (de memoire) qu'il faut qu'ils soient serializable. car si tu mets des objets super complexe, il faut que tu sois garant de la possibilité de les reconstruire depuis n'importe quel autre techno
 
Sinon c vrai que ds le cas que tu evoques, ca n'apporte pas grand chose.
 

en tt cas l'interopérabilité entre JAVA et .NET au niveau des WebServices, ça laisse à désirer. On voit que .NET ne respecte pas toujours les standards. :s

En tout cas je te conseille le corba : j'avais fais un gros projet avec et c'est vraiment très sympa a utiliser.

oui mais CORBA est en mode connecté. Et au niveau déploiement, c'est plus chiant à faire. De plus il faut faire un IDL afin de généré les classes vers les langages choisis.

Je rejoins un peu les propos d'alien_man sur les WS.
 
L'idée était quand même de faire un standard de communication "web" multilangage.
Imagine que tu puisses envoyer un type complexe. Comment est-il codé ? Comment PHP peut le récupérer ? Peut-il le faire d'ailleurs ? Et en JSP, le résultat obtenu imposera-t-il une légère adaptation qui n'existe pas si j'utilise PERL ?
 
J'ai fait un petit prog qui implémente le protocole XML6RPC ainsi qu'une recopie sous un WebService.
 
C'est des types simples, ok, mais je peux te dire que c'était bien plus efficace et rentable de faire le WS que de refaire la partie envoi/réception d'un flux XML et son encodage/décodage. Surtout sous .NET ou Visaul Studio te mache pas mal de boulot...
 
Après faut savoir éclater les informations traitées pour simplifier le résultat. Par exemple, envoyer un graph... C'est une image... Donc du byte.
 
Moi le WS m'a pas encore frustré...

C'est relou les web services !
=> je plussoie sans même lire la suite, juste pour le troll.