Bibliographie & annexes
Présentation
En anglais
Auteur(s)
-
Michel RIVEILL : Professeur à l’université de Nice‐Sophia‐Antipolis
Lire cet article issu d'une ressource documentaire complète, actualisée et validée par des comités scientifiques.
Lire l’articleINTRODUCTION
Pour faire communiquer deux morceaux d’une même application ou deux applications distinctes, les programmeurs pouvaient jusqu'à présent utiliser trois propositions difficilement compatibles : COM+, la version distribuée du modèle objet de Microsoft limitée dans les faits au monde Windows ; CORBA, spécification normative d'un bus objet multi-plate-forme et multilangage et le modèle des Enterprise Java Beans (EJB), spécification d'architecture pour la construction et l'exécution de composants Java proposée par Sun. Indépendamment des apports des uns et des autres, qui sont en dehors de cette étude, peu de passerelles logicielles permettent de convertir aisément les requêtes issues d’un environnement afin qu'elles soient acceptées dans un autre environnement. Il est donc illusoire de vouloir faire cohabiter simplement au sein d’une même application plusieurs bus logiciels (« middleware ») d’interconnexion. Le besoin étant essentiel, plusieurs types de passerelles existent.
Microsoft, IBM et d’autres par la suite, observant que les incompatibilités et la lourdeur de ces propositions conduisaient au développement de solutions fondées sur des requêtes HTTP, ont introduit SOAP (Simple Object Access Protocol), un protocole de communication entre objets, très simple, reposant sur les acquis de l’Internet. En particulier, cette proposition utilise XML pour la description des requêtes et HTTP pour leur transport, ce qui permet d’éviter les problèmes liés au filtrage par des pare-feu (« firewall »). Ces deux standards, largement diffusés, sont utilisés en lieu et place de tout autre schéma propriétaire. Pour être plus précis, SOAP consolide et rend normative une proposition existante « XML-RPC ». SOAP, soumis à l’IETF et adopté par le W3C, comble une lacune du Web.
L’objectif de ce document est de présenter les principes de fonctionnement de SOAP ainsi que de donner quelques exemples d’utilisation.
L'expertise technique et scientifique de référence
DOI (Digital Object Identifier)
Cet article fait partie de l’offre
Technologies logicielles Architectures des systèmes
(239 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive
Présentation
Conclusion
En anglais
6. Autres aspects
6.1 Sécurité
SOAP définit peu de choses pour la sécurité et laisse au protocole de transport le soin de la garantir. Si celui-ci est HTTP, elle repose sur la version sécurisée du protocole (HTTPS) et sur la notion de certificat aujourd’hui couramment utilisée sur l’Internet. Comme les messages SOAP sont des messages HTTP (ou HTTPS), les pare-feu peuvent aisément les filtrer ou les laisser passer comme tous les autres messages acheminés par le même support.
SOAP a été défini pour mettre en place un mécanisme d’échange de données types codées en XML entre un client et un serveur. Le client peut uniquement appeler les services que le serveur a publiés et ne peut recevoir que les réponses que celui-ci envoie. D’une manière générale, SOAP n’a pas été défini pour permettre l’échange de code et l’activation à distance de celui-ci.
La sécurité du protocole repose, comme bien souvent, sur une utilisation correcte : si un site permet de recevoir du code et de l’activer, alors une brèche est ouverte ; si un site ne peut que recevoir des demandes de service clairement identifiées, il est nettement plus difficile d’en détourner l’usage.
HAUT DE PAGE6.2 Langage de description des services : WSDL
Un client qui désire utiliser un service doit pouvoir, comme dans toute plate-forme client-serveur, en acquérir la description. Cette description contient, comme pour tous les langages de description d’interface (IDL), le nom de la méthode ainsi que les paramètres d’appel. Dans le cas de SOAP, ce contrat est décrit dans un format XML appelé WSDL (Web Service Description Language) [14] qui est en cours de normalisation par le W3C en 2001. Ce document contient une description précise des différentes méthodes accessibles et de leurs paramètres (figure 11). Il contient en particulier des informations sur les méthodes de transport des messages (SOAP, http GET, http POST), le nom et les attributs des méthodes, donc tout ce qu'il faut pour construire et émettre une requête vers un service Web. Le service de calcul précédemment présenté 3...
L'expertise technique et scientifique de référence
Cet article fait partie de l’offre
Technologies logicielles Architectures des systèmes
(239 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive
Autres aspects
BIBLIOGRAPHIE
-
(1) - GUDGIN (M.), HADLEY (M.), MOREAU (J.J.), NIELSEN (H.-F.) - * - SOAP Version 1.2. W3C Working Draft, 9 juill. 2001 http://www.w3.org/TR/soap12/
-
(2) - SCRIBNER (K.), STIVER (M.C.), SCRIBNER (K.) - Understanding SOAP : The Authoritative Solution. - 1re éd., Ed. Sams, janv. 2000.
-
(3) - XML Cover Pages - http://www.oasis-open.org/cover/
-
(4) - McLAUGHLIN (Br.) - Java and XML. - 1re Éd., O’Reilly & associates, juin 2000.
-
(5) - BIRREL (A.D.), NELSON (B.J.) - Implementing Remote Procedure Call. - ACM Transactions on Computer Systems, 2 (1), 39-59 (1984).
-
(6) - FIELDING (R.), GETTYS (J.), MOGUL (J.C.), FRYSTYK (H.), BERNERS-LEE (T.) - Hypertext Transfer Protocol - HTTP/1.1. - RFC 2616, U.C. Irvine, W3C/MIT, janv. 1997.
-
...
L'expertise technique et scientifique de référence
Cet article fait partie de l’offre
Technologies logicielles Architectures des systèmes
(239 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive
