Discussion :

[randriano]

Bonjour,

La première fois que j'ai vu le terme "web services", je croyais que c'est juste une appelation du développement de sites web de vente en ligne, réservation.
Alors qu'il se cache derrière une nouvelle architecture qui s'inspire de CORBA et de RMI mais utilisant le Web et possédant ses propres protocoles normalisés (SOAP, UDDI)
En feuilletant quelques discussions ici, je ne comprends pas encore son principe général:
- Avec quel langage peut-on développer un service web car on ne parle que du J2EE et DOTNET ??
- Puisque le service web se base sur HTTP et XML, les protocoles SOAP-WSDL sont-ils donc des surprotocoles c'est à dire au dessus de HTTP ? Ils sont même des XML dédiés comme HTML non ?

Les services web facilitent non seulement les échanges entre les applications de l'entreprise mais surtout permettent une ouverture vers les autres entreprises. Les premiers fournisseurs de services web sont ainsi les fournisseurs de services en ligne (météo, bourse, planification d'itinéraire, pages jaunes, etc.), mettant à disposition des développeurs des API (Application Programmable Interface) payantes ou non, permettant d'intégrer leur service au sein d'applications tierces.

En quel langage seront ces API?

Il existe des bibliothèques SOAP pour de très nombreux langages, dont Perl, C, C++, C#, Python, Java, Visual Basic/.NET, PHP, Ruby, etc.

Pour qui? Pour le client? Ce dernier n'aura-t-il pas que son navigateur comme logiciel?

[mathieugut]

Salut,

Bien NuSOAP par exemple pour le PHP permet de créer et d'exploiter des webs services

Après il existe une multitude de combinaisons, on peut très bien utiliser un WebService PHP à partir d'AJAX...

[randriano]

NuSOAP, ok !!

On dit quelquefois dans les tutos du web

Les services web, c'est quoi?
C'est la possibilité d'invoquer une fonction distante. En l'occurence, sur un serveur web distant puisque le protocole de base est HTTP

Pourquoi on parle d'invoquer pour les services web, les forums, les chats n'invoquent-ils pas tous des fonctions distantes. Ce terme convient plutôt pour CORBA et RMI car avec les webservices, le client ne recevra que du HTML et n'enverra que des requêtes GET ou POST

Et pour,

En quel langage seront ces API?

[samkiller]

Je crois que tu confonds un peu quelques notions.
Les web services, comme tu le dis c'est du CORBA ou RMI adapté au web et utilisant http comme couche de communication. En gros c'est le même principe que suit corba et RMI, à savoir RPC En gros t'as une description des interfaces ou services (en java pour RMI, IDL pour CORBA ou .x pour RPC). Pour les web services on utilise le langage favori du web car il est complètement interopérable : XML. Et le langage de description des services c'est le WSDL qui est du XML qui suit des schemas xml bien définit. EN plus comme en RPC, les messages sont encodé en XDR pour les échanger entre des plate formes, en web service on utilise encore un format précis qui basé sur du xml, mais qu'on appelle SOAP.
Je pense jusque là c'est pas loin de ce que tu disais. Mais les web services n'échangent pas du HTML. C'est pas parce que ça transite par http et que c'est du web que c'est forcément du html. Mais n'importe quel type de donnée peut être serialisé en xml, d'où l'avantage par rapport aux autres technos pour systèmes répartis.
Ainsi tu peux utiliser en programme .net quiinvoque des services sur une plate forme j2ee, sans mettre en place des bridges, mais uniquement en passant par le web car il est par définition interopérable.
Aussi les web services n'ont qu'un langage : xml. Donc tu peux les implémenter suiant n'importe quel autre langage de programmation du moment qu'ils offrent des API qui suivent.
Et en java par exemple les API n'ont de cesse d'évoluer, si bien que tu n'as à écrire une seule ligne de xl, mais rien que de définir tes services sous forme d'objets ou méthodes java, et les APIs s'occupent de créer l'infrastructure de déploiement et d'exposition pour toi. (Coire tuto JAX-WS ou web services for Java EE 5, et autres y en a tellement).
J'aime bien cette technos, mais à force de courir vers la simplification en allant de plus en plus vers une programmation haut niveau, je m'y perd souvent. Etant habitué à mon CORBa et RPC préférés pour la programmation d'applications ditribuées.

[samkiller]

Pourquoi on parle d'invoquer pour les services web, les forums, les chats n'invoquent-ils pas tous des fonctions distantes. Ce terme convient plutôt pour CORBA et RMI car avec les webservices, le client ne recevra que du HTML et n'enverra que des requêtes GET ou POST

Qui t'a dit que dans les requêtes GET ou PST il y a que du html?? TU peux y mettre ce que tu veux. A ton avis comment tu télécharge des fichiers depuis le web avec du get??? c'est pourtant pas du html.
On inque des services, parce que ces services sont distants. Alors comme en corba ou rmi ou encore rpc, on peut parler d'invocation de de services. qui en générale sont des méthodes d'interfaces d'une applications distantes.

[oca]

Le terme "web services" n'est pas normalisé.
Il y a cependant deux grosses tendances :

1) Les web services "REST" qui se basent essentiellement sur les méthodes HTTP (POST, GET, PUT et DELETE)
Il y a un truc sympa qui pointe le bout de son nez : la WADL, proposé par un gas de chez Sun. Elle est encore peu controversée car les gens ne veulent pas trop tomber dans la complexité de ...

2) Les web services "WS-*", qui se basent principalement sur le protocole SOAP (et donc xml).

L'idée principale du web service est de pouvoir faire interopéré des systèmes qui n'ont pas obligatoirement le même OS, qui ne sont pas écrit dans le même langage, et qui peuvent être localisé sur des machine différentes.

A mon avis, le truc sympa des web services dit "WS-*", c'est la WSDL, un document "xml "qui décrit les services fournit et les structures de données nécessaires.

La plus part du temps, le message SOAP transit par le transport HTTP.

SOAP en lui-même est "relativement simple"... j'ai bien dit relativement... la ou cela se complique, c'est dans le '*' de WS-*... Il existe des tonnes d'extensions et d'autres normes qui décrivent des fonctions spécifiques, comme la sécurité.

Evidemment, toutes ces normes ne sont pas fournient par le même organisme, ce serait trop simple... Les plus importantes sont chez le W3C et chez OASIS.

Si on prend la sécurité par exemple...

WS-Security (OASIS) décrit un ensemble de tags pour transmettre des info dans le message SOAP (W3C).

WS-Security se base sur XML-Encyption et XML-Signature (les deux du W3C)
XML-Signature est lui-même très copain avec XML Canonicalization.

Pour simplifier les choses, on peut décrire la sécurité sous forme de policies... Il faut alors WS-Policy (amusante celle-la d'ailleurs... on se croirait en plein cours de math), WS-PolicyAttachement, WS-PolicyAssertion, puis WS-SecurityPolicy... bref... il faut aimer lire...

On peut bien sûr utiliser des outils qui font tout tout seul, mais au premier problème... aie aie aie...

A noter encore que WS-I est une association dont le but est de garantir l'interoperabilité de tout cela (principalement entre .NET et JAVA)...

Bref, je ne critique pas, mais tout les besoins ne necessitent sûrement pas de mettre en place de tels solutions...

Un truc bien pour terminé Cette complexité n'intervient que si on en a besoin... c'est une des choses que j'aime avec SOAP.

A+

[samkiller]

Tout à fait d'accord avec le message précédent. Je préfère les web services SOAP/WSDL aux ws REST. Je suis pas expert en RESTful web services, mais je trouve que le système SOAP/WSDL reste plus extensible. Et on peut toujours ajouterdes couches si on en a besoin et utiliser n'importe quel mode de transit réseau.
D'autant que ça reste du XML /XSchema, et qu'avec les outils d'ajourd'hui on génère tout ça allegrement.

[randriano]

Mais les web services n'échangent pas du HTML

Ils s'échangent du XML entre eux (SOAP, WSDL) pour cause d'interopérabilité mais entre le client et le serveur de service web, c'est toujours du HTML c'est à dire juste affichage ! C'est loin du principe de Corba ou RMI où le client invoque directement des objets

En gros, cette technologie n'a rien d'innovant seulement appliquer les technologies des objets/services répartis sur le web (HTTP et XML)

Merci beaucoup les amis pour ces belles dissertations !!!

[djsnipe]

entre le client et le serveur de service web, c'est toujours du HTML c'est à dire juste affichage ! C'est loin du principe de Corba ou RMI où le client invoque directement des objets

Ben non justement, un web service n'a AUCUNE corrélation avec une notion de page web en HTML. Il s'agit bien d'invoquer des objets à distance de manière interopérable, comme en CORBA.
Les 2 posts de samkiller sont à relire.

[samkiller]

Ils s'échangent du XML entre eux (SOAP, WSDL) pour cause d'interopérabilité mais entre le client et le serveur de service web, c'est toujours du HTML c'est à dire juste affichage ! C'est loin du principe de Corba ou RMI où le client invoque directement des objets

En gros, cette technologie n'a rien d'innovant seulement appliquer les technologies des objets/services répartis sur le web (HTTP et XML)

Merci beaucoup les amis pour ces belles dissertations !!!

Mais il y a pas mal d'erreurs dans ton explication là.
D'abord en RMI ou Corba, on invoque pas des objets. Mais des méhodes ou des services. Chauqe service te fournit un résultat. C'est ce qu'on fait avec les web services, on invoque à distance des services qui te fournissent un résultat.
Et comme dit dans le post précédent, ça n'a rien à avoir avec du html ou des serveurs web. Un client qui invoque un service web , ne fait une requête à un serveur web pour obtenir une page web. Pour cela il suffit d'utiliser l'url.
Les web services, rmi ou corba étendent le principe de RPC. Qui est étendu aux objets pour java aavec rmi, de même pour corba avec des services en plus. Et c'est pareil avec les wev services, sauf que s'il y a échange d'objets ces derniers sont sérialisés en XML avec un schema xml.
ça n'a rien de spécialement novateur peut être, mais l'interopérabilité est plus importante qu'avec les autres middlewares, car le web par définition est interopérable.

[djsnipe]

mais l'interopérabilité est plus importante qu'avec les autres middlewares, car le web par définition est interopérable.

Attention à cette phrase, tu refais un léger amalgame. Le seul lien entre web service et le web, c'est le protocole de transport utilisé à savoir HTTP. Et c'est en tant que protocole utilisé sur internet qu'il est devenu support "standard" des échanges dans un système hétérogène.

[Tommy31]

Je crois que tu confonds un peu quelques notions.
Les web services, comme tu le dis c'est du CORBA ou RMI adapté au web et utilisant http comme couche de communication. En gros c'est le même principe que suit corba et RMI, à savoir RPC

Mmm, je tique sur l'aspect réducteur des choses. RMI et corba permettent d'édifier des architecture à objets distribués. Les WS permettent simplement d'édifier des architectures de services. Certes avec un architecture à objets distribués tu peux aussi faire du SOA, mais c'est limitateur.

Après le protocole sous-jacent, ce n'est pas à mes yeux l'élément distinctif (on peut faire du rmi http tunnelling).

[djsnipe]

Intéressant.
Quelle est pour toi la distinction entre architecture distribuée et architecture de services (j'ose le terme SOA, c'est à la mode ) ?

[samkiller]

ouais moi aussi je me pose la question?? Quelle est la différence entre une architecture à base de service donc SOA et une architecture répartie à base d'objets type CORBA?
A mon avis la différence c'est l'effet de mode. vu que l'on utilise de plus en plus http, et que c'est un protocole qui marche sur tout type de plateforme, on chois plus les ws, que corba, qui est bien plus complexe à mettre en oeuvre.
Quant aux SOA, c'est bien joli de construire une architecture en réutilisant des services, mais en y réflechissant bien ça reste faisable avec corba ou rmi. du moment qu'on gère l'interopérabilité (voir IIOP). Mais, l'avantage des web services c'est encore une fois le xml et la tendance à tout bâtir autour du web des dernières années.
Aussi je trouve très réducteur aussi, le fait de penser que les web services ne servent qu'au SOA. Leur premier but est de faire communiquer des applications distantes, comme RPC. Et les objets, comme les videos la voix et tout le reste peut y passer aussi. Grace à l'optimisation des messages, qui permet d'encoder des sequences bytes sous forme de type XML en utilisant des librairies de binding appropriés.

[oca]

Moi je vois la distribution comme un des piliers d'une architecture en service.
en plus de la distribution, on peut aussi avoir besoin de répertoires de services (UDDI), de la descriptions des services (WSDL), de leurs Policies (encryption, signature, MTOM etc...)
A+

[Tommy31]

ouais moi aussi je me pose la question?? Quelle est la différence entre une architecture à base de service donc SOA et une architecture répartie à base d'objets type CORBA?

La différence est que dans l'un tu distribue des objets vivants, dans l'autre des objets stateless (des value-object). En corba ou rmi, lorsque tu t'adresse à une interface elle peut te retourner une autre interface tout aussi invoquable. En d'autre terme tu peux accéder à ta hiérarchie d'objets et invoquer des méthodes dessus comme si tu le faisais en local.

En WS, niet, tu as une interface qui te retourne un résultat dématérialisé, une coquille vide.