Présentation
EnglishAuteur(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.
DOI (Digital Object Identifier)
Cet article fait partie de l’offre
Technologies logicielles Architectures des systèmes
(240 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
4. Éléments
SOAP est constitué de différentes « couches » construites au-dessus de XML (figure 8). Chaque couche a un rôle bien particulier afin de rendre SOAP indépendant des langages de programmation et de la plate-forme d’exécution.
Le cœur est constitué du langage XML et des différents espaces de noms qui ont été définis.
Une partie optionnelle permet de définir des modèles pour représenter des services sur l’Internet. Nous avons mentionné 3 WSDL qui est l’un des modèles possibles. L’objectif de cette partie est, pour un serveur, de pouvoir publier sur l’internet les services qu’il fournit en décrivant la manière d’y accéder et, pour les clients, de pouvoir construire les messages attendus par les serveurs.
HTTP/1.1 500 Internal Server Error.
Server: Microsoft-IIS/5.0
Date: Thu, 01 Mar 2001 20:06:31 GMT
Cache-Control: private
Content-Type: text/xml
Content-Length: 720
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<soap:Fault>
<soap:faultcode>Client</soap:faultcode>
<soap:faultstring>
System.Web.Services.Protocols.SoapException: Server found
request content type to be ’text/xml; charset=utf-8’, but expected ’text/xml’.
at System.Web.Services.Protocols.SoapServerProtocol.ReadParameters()
at System.Web.Services.Protocols.WebServiceHandler.Invoke()
at System.Web.Services.Protocols.WebServiceHandler.CoreProcessRequest()
</soap:faultstring>
<soap:faultactor>http://localhost/services/Math.asmx</soap:faultactor>
<soap:detail/>
</soap:Fault>
</soap:Body>
</soap:Envelope>
Les...
Cet article fait partie de l’offre
Technologies logicielles Architectures des systèmes
(240 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
Éléments
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.
-
...
Cet article fait partie de l’offre
Technologies logicielles Architectures des systèmes
(240 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