Soa Chapiv

CH4.
Les Standards des

services Web
  HTTP
  SOAP
  WSDL
  UDDI
  BPEL
  WS-Security
Fatima-Zahra BELOUADHA. SOA. 3ème année. Options IQL et TI. Filière Génie Informatique. 57
Pile des standards des services
Web étendus
HTTP (HyperText Transfer Protocol)
  Protocole de communication sur Internet
  Disponible sur toutes les plateformes
  Simple (a besoin de peu de support pour fonctionner)
  Sans connexion (peu de paquets sont nécessaires
pour l’échange d’informations)
  Niveau de sécurité simple et effectif
  Le seul protocole utilisable à travers des pare-feu
SOAP (Simple Object Access Protocol)
  Protocole d’échange d’informations XML entre client et
serveur HTTP (standard de W3C, initié par Microsoft et IBM)
-  De rôle similaire à RPC
  Protocole minimal pour l’appel des méthodes sur des
serveurs, services, composants, objets, et qui n’impose pas
l’utilisation de :
-  API ou Runtime (API)
-  ORB (CORBA,DCOM…) ou serveur Web particulier (Apache, IIS…)
-  Modèle de programmation
  Porté sur toutes les plateformes et technologies
  Extensions : SOAP sur SMTP/FTP, MOM …
Requête et réponse SOAP
  Peuvent servir à échanger par exemple :
-  Des Messages : appel sérialisé d’une méthode sur un

objet (Rq) / retour sérialisé d’un appel de méthode sur
un objet (Rp)
-  Appel (obligatoire), Réponse (optionnel), Erreur/fault
(optionnel)
-  Des Documents : Document XML (Rq) et sa version

transformée (Rp)
-  Paramètres In, InOUT (Req)/Inout, OUT (Rép) comme

dans le cas d’objets RPC
Exemple : requête SOAP (1/2)
  Appel du service hel (opération : HelloWorld)
Message SOAP pour appeler
l’opération makeHelloWorld
avec un paramètre value
Exemple : requête SOAP (2/2)
  Appel du service hel (opération : HelloWorld)
Message SOAP pour appeler
l’opération simpleHelloWorld,
sans de paramètre

Exemple : Réponse SOAP
  Messages de Réponses aux appels du service HelloWorld
Les réponses sont

sensiblement iden-ques

Structure d’un message SOAP
transporté par HTTP
Structure de l’enveloppe SOAP
  Elément racine du message identifié par la balise
<soapenv:Enveloppe>
  Il spécifie les espaces de désignation et de
codage de données (namespaces)
Ou contenu
de la réponse
Entête SOAP (Header)
  Elément facultatif du message identifié par la
balise <SOAP-ENV:Header>
-  Utilisé surtout quand le message est traité par plusieurs
intermédiaires avant le récepteur final
  Rajoute des info. non applicatives (supplémentaires)
-  Indique à l’application réceptrice que le Message est
optionnel/obligatoire (attribut mustUnderstand=0 ou 1)
-  Indique des Transactions, sessions, l’émetteur (cas de
FTP)…
Exemple : Entête SOAP dans un
transfert successif de message
Corps SOAP (Body)
  Elément facultatif du message identifié par la
balise <SOAP-ENV:Body>
  Il comprend des informations applicatives :
-  Structure Opération (Nom d’opération (suivi de Response) et
ses paramètres sous forme de structures s’ils sont de type
complexe (valeurs d’entrées ou de retour), fault (<SOAP-
ENV:Fault>)…
-  Ces informations respectent un encodage déterminé dans le

binding au niveau du fichier WSDL
u  Attribut style (Document et RPC)
u  Attribut use (encoded et litteral)
u  Les namespaces utilisés pour l’encodage sont :

- SOAP-ENC http://schemas.xmlsoap.org/soap/encoding/
- xsd : XML Schema Description
Exemple de Corps SOAP appelant une
opération d’un service Web (1/2)
Service Web Notebook

Appel de l’opéra-on

addPersonWithSimpleType

3 paramètres
Exemple de Corps SOAP appelant une
opération d’un service Web (2/2)
Service Web Notebook

Appel de l’opéra-on

addPersonWithComplexType

Parameètre de type

complexe défini sous
forme de structure
newPerson
Exemple de Corps SOAP contenant une réponse
d’une opération d’un service Web (2/2)
Exemple de réponse SOAP
transportée par http
  Codes de retour : 2xx (message reçu), 500 (message fault).
Exemple de requête SOAP
transportée par http
  Méthode POST avec Attribut SOAPAction (intention de la Rq)
Règles d’encodage de données (1/3)
  Types primitif
  Structure
  Enumération
  Référence
  Tableau
  Tableau creux
  Tableau d’octets
Encodage des faults
  Faultcode (obligatoire) : utilisé par un logiciel
pour identifier des faults (ex : switch (faultcode) …
-  4 groupes de code : Client, Serveur,
MustUnderstand, VersionMismatch
-  Ex : Client.authentification
  Faultstring (obligatoire) : description du fault

  Faultactor (optionnel) : firewall, proxy, MOM
(en cours de cheminement du msg)
  Detail : non lié au corps du message
  Autres : peuvent être ajoutés mais doivent être
associés à des namespaces
Exemple : Erreur SOAP (Fault)
Echanges SOAP via HTTP
Faut-il connaître SOAP ?
  Non : Utiliser des APIs fournissant une abstraction des
messages SOAP
  Oui (mais il faut connaître XML et XML Schema) pour :
-  Débugger une application
-  Réaliser des tests via l’outil graphique SOAP UI
-  Intercepter les messages bas niveau SOAP (via les
handlers)
  SOAP UI (www.soapui.org)
-  Disponible en Standalone ou intégré (Eclipse, Intellij,
Netbeans, Maven...) et indépendant de la plateforme
de développement
-  Supporte les Services Web étendus ou REST
-  Permet d’inspecter, invoquer, développer et simuler
des Services Web via des bouchons (mocks), et
d’effectuer des tests QoS (temps de réponse...)
SOAP et concurrents
RMI RPC DCOM CORBA SOAP
Organisme Sun SUN/ Microsoft OMG W3C
OSF
Plateforme Multi Multi Win32 Multi Multi
Langage de java C, C++ C++, VB, VJ, Multi Multi
développement … Opascal…
Langage de Java RPCGE ODL IDL WSDL
description N
Transport TCP, TCP, IP/IPX GIOP, HTTP,
HTTP, UDP IIOP HTTPR,
IIOP SMTP
transaction Non Oui Oui Oui
Sécurité SSL, - - SSL SSL
JAAS
SOAP Vs RMI, DCOM et CORBA
(Avantages et inconvénients)
RMI DCOM CORBA SOAP
-‐  Monolang. -‐  Mul;langage -‐  Mul;langage -‐  Mul;langage
-‐  Mul;-‐plate. -‐  Monoplateforme -‐  Mul;plat. -‐  Mul;plaforme
-‐  Problème de -‐  Protocole orienté -‐  Installa;on -‐  Spécifica;on non
performance connexion (+eurs coûteuse (si propriétaire (W3C)
et sécurité paquets doivent un ORB est à -‐  Requêtes/réponses
être échangés acheter) en XML
pour créer ou -‐  Implémenta;on
maintenir une facile sur différents
session) protocoles de
-‐  Faible diffusion transport
(Non disponible -‐  Capable de franchir
sur Mac OS, NT les farewalls (mais
3.51, Win95, le contrôle d’accès
WinCE2, coûteux à faible granularité
sur Unix, MVS, sera perdu)
VMS ou NT)
WSDL (Web Service Description
Language)
  Standard W3C basé sur XML pour la

description d’interfaces des services Web
-  Opérations du service
-  Paramètres d’entrée et sortie des opérations
-  Types de données des paramètres
-  Points d’entrée (URL) des opérations
-  Manière d’invoquer le service (Comment?)
Eléments WSDL
  <definitions> : racine du document
  <types> : Types de données sous format schéma XML
  <Part>
  <Message> : paramètre, valeur de retour, exception

  <Operation>
  <portType> : ensemble d’opérations

  <binding> : détail technique (protocoles…)
  <port> : point d’accès
  <service> : ensemble de port at leur binding associés
Exemple 1 : service Carnet d’adresses
  3 opérations
-  addPerson : Entrée (Person) + Sortie (booléen pour
indiquer l’état de création)
-  addPerson : Entrées (3 string : name, address et
birthyear)
-  getPersonByName : Entrée (string) + Sortie (Person)
-  getPersons : Sortie (tableau d’objets Person)
  Protocole SOAP : pour décrire les messages

  Protocole HTTP : pour l’échange de messages
WSDL : l’élément types
  2 variantes :
-  Contient la définition des types de données
(Schéma XSD, schéma XML…)
•  Facultatif si les types sont simples (Integer,
Boolean... )
-  Importe un fichier Schéma XML contenant la
définition des types
•  Avantage : réutiliser des types et d’alléger
le fichier WSDL
Exemple WSDL : définition des types
Exemple WSDL : Import d’un fichier
de types
WSDL : l’élément message
  Décrit un message échangé par le service et est

défini par les attributs :
-  Name : nom du message
-  1 ou plusieurs éléments <part> : inputs/outputs ou
exception d’une opération
  Chaque élément <part> est défini par les attributs :

-  name : nom du paramètre
-  type : type de données du paramètre
Exemple WSDL : l’élément message
WSDL: les éléments portType et opération
  Interface contenant les prototypes
d’opérations fournies par le service et définie
par les attributs :
-  Name : nom du portType
-  <opération> : 1 ou +eurs décrivant chacun le
prototype d’une méthode fournie par le service
  Chaque élément <opération> est défini par les
attributs :
-  name : nom de l’opération
-  <input message>/<output message>/ <fault> :
référence à 1 message décrivant les paramètres d’E/
S et le message d’erreur de l’opération
Exemple WSDL : l’élément portType
Types d’échanges assurés par une
opération
  One-way : Message input sans réponse
  Notification : Seul un message <output> est utilisé
  Request/Response : <input>, <output> et <fault>
Ø  Le service reçoit un message du client et répond à sa

requête
  Solicit - response : <input>, <output> et <fault>
Ø  Le client reçoit un message du service et répond au

service
Exemples des différents Types d’échanges
  One-way :
  Notification :
  Request/Response :
  Solicit - response :
WSDL : l’élément binding
  Décrit un portType du point de vue technique
-  Protocole (SOAP 1.1 ou 1.2, HTTP GET & Post : ex,
transfert d’images) utilisé pour manipuler un <portType>
  Est défini par les attributs :
-  name : nom du binding
-  type : portType concerné
  Sa structure (éléments qu’ils contient) dépend du
protocole utilisé
  Plusieurs <binding> peuvent être définis pour
appeler un portType de différentes manières
WSDL: Structure de l’élément binding
WSDL : Binding SOAP
  A généralement la forme <soap:binding> et est

défini par l’espace de noms :
-  http://schemas.xmlsoap.org/wsdl/soap/
  Utilise les principales balises suivantes :

-  <soap:binding>
-  <soap:operation>
-  <soap:body>, <soap:header>, <soap:headerfault>
-  <soap:fault>
WSDL : les éléments service et port
  Un élément <service> définit les ports (points

d’accès) du service
-  Chaque <port> spécifie 1 adresse pour 1 binding donné
  Un élément <port> est défini par les attributs :

-  name : nom du port
-  binding : nom du binding (défini précédemment)
  La structure de l’élément <port> est spécifique au

protocole utilisé dans le binding
-  <soap:address> : URI du port dans le cas d’un binding
SOAP
WSDL : les éléments service et port
Le portType Notebook est accessible

en SOAP/HTTP via cette URL
Exemple 2 : service HelloWorld
  2 opérations
-  makeHello : Entrée (string) + Sortie (string)
-  simpleHello : Sortie (string)
  Protocole SOAP : pour décrire les messages
  Protocole HTTP : pour l’échange de messages
Exemple 2 : service HelloWorld en WSDL
Exemple 2 : service HelloWorld en WSDL
Organisation d’un document WSDL
  Partie abstraite (types+Messages+portTypes) : réutilisable
  Partie concrète (binding+services)
Outils pour manipuler des documents
WSDL
  Edition
-  Notepad++ (texte : XML)
-  Eclipse JavaEE
-  Netbeans
-  Visual Studio
-  Environnements de développement de SW
  Validation
-  www.validwsdl.com
  Test
-  SOAPUI
UDDI (Universal Description,
Discovery and Integration)
  Annuaire mondial de services d’entreprises décrits en
WSDL et accessibles via des requêtes SOAP
-  Proposé en 2000 (Microsoft, Ariba et IBM, puis SUN, Oracle,
HP…), V2 (2002), V3 (2003) adoptée en 2005
  Contient 3 types d’infos :

-  Pages Blanches : fournisseurs de services (nom de l'entreprise,
ses coordonnées, sa description…)
-  Pages Jaunes : catégories de services fournis par les entreprises
-  Pages Vertes : description technique des WS (contrats WSDL,
informations de liaison…)
Modèle UDDI
Nom, desc., contact, Nom, desc. text, Desc., point d’accès,
catég., adresse, iden-f… catégorie… paramètres…
Schéma UDDI
  Le modèle UDDI est défini sous forme de schéma W3C XML
Pages blanches:
Providers (clé)
Pages jaunes:
info sur le service
+binding Templates
Coordonnées du
service :
Pt d’accès+tModels
Desc. Technique des

services
(format : XHTML,
WSDL…)
Exemple de Binding template
Exemple de TModel
Interface UDDI
  Implémentée sous forme de service Web SOAP, elle
permet :
-  Interrogation : rechercher des informations dans l’UDDI

-  Publication : publier des informations dans l’UDDI
-  Sécurité : assurer l’authentification pour l’accès
aux enregistrements protégés dans l’UDDI
-  Contrôle d'accès et propriété : transférer la propriété d’info
(attribuée à l’origine à l'utilisateur l’ayant publié) et de gérer les
droits d'accès associés
-  Abonnement : Assurer l’abonnement à des informations (ce qui
permet d'être averti lors de leur modification)
-  Réplication interne : synchroniser les noeuds d'un même UDDI
-  Réplication externe : dupliquer les informations entre différents
UDDI (par interrogation + publication + abonnement pour
propager les modifications)

Soa Chapiv

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Soa Chapiv

Transféré par

Droits d'auteur :

Formats disponibles

CH4.

Les Standards des

- Des Messages : appel sérialisé d’une méthode sur un

- Des Documents : Document XML (Rq) et sa version

- Paramètres In, InOUT (Req)/Inout, OUT (Rép) comme

Les réponses sont

- Ces informations respectent un encodage déterminé dans le

u Attribut use (encoded et litteral)

u Les namespaces utilisés pour l’encodage sont :

Service Web Notebook

Appel de l’opéra-on

Service Web Notebook

Appel de l’opéra-on

Parameètre de type

 Faultstring (obligatoire) : description du fault

 Standard W3C basé sur XML pour la

 <Message> : paramètre, valeur de retour, exception

 <portType> : ensemble d’opérations

 Protocole SOAP : pour décrire les messages

 Décrit un message échangé par le service et est

 Chaque élément <part> est défini par les attributs :

 Notification : Seul un message <output> est utilisé

 Request/Response : <input>, <output> et <fault>

Ø Le service reçoit un message du client et répond à sa

 Solicit - response : <input>, <output> et <fault>

Ø Le client reçoit un message du service et répond au

 A généralement la forme <soap:binding> et est

 Utilise les principales balises suivantes :

 Un élément <service> définit les ports (points

 Un élément <port> est défini par les attributs :

 La structure de l’élément <port> est spécifique au

Le portType Notebook est accessible

 Protocole SOAP : pour décrire les messages

 Protocole HTTP : pour l’échange de messages

 Contient 3 types d’infos :

Desc. Technique des

- Interrogation : rechercher des informations dans l’UDDI

Vous aimerez peut-être aussi

-  Des Messages : appel sérialisé d’une méthode sur un

-  Des Documents : Document XML (Rq) et sa version

-  Paramètres In, InOUT (Req)/Inout, OUT (Rép) comme

-  Ces informations respectent un encodage déterminé dans le

u  Attribut use (encoded et litteral)

u  Les namespaces utilisés pour l’encodage sont :

  Faultstring (obligatoire) : description du fault

  Standard W3C basé sur XML pour la

  <Message> : paramètre, valeur de retour, exception

  <portType> : ensemble d’opérations

  Protocole SOAP : pour décrire les messages

  Décrit un message échangé par le service et est

  Chaque élément <part> est défini par les attributs :

  Notification : Seul un message <output> est utilisé

  Request/Response : <input>, <output> et <fault>

Ø  Le service reçoit un message du client et répond à sa

  Solicit - response : <input>, <output> et <fault>

Ø  Le client reçoit un message du service et répond au

  A généralement la forme <soap:binding> et est

  Utilise les principales balises suivantes :

  Un élément <service> définit les ports (points

  Un élément <port> est défini par les attributs :

  La structure de l’élément <port> est spécifique au

  Protocole SOAP : pour décrire les messages

  Protocole HTTP : pour l’échange de messages

  Contient 3 types d’infos :

-  Interrogation : rechercher des informations dans l’UDDI