Service Web : SOAP
Corinne Amel ZAYANI
Table des matières
I - Objectifs 3
II - Mise en œuvre d'un middleware 4
1. Exemple d'une architecture SOA...............................................................................4
2. Le Service (WSDL) ......................................................................................................5
3. Le Serveur ..................................................................................................................8
4. Test (SOAP) .................................................................................................................9
5. Fonctionnement du premier projet WS SOAP ........................................................12
6. Le client (SOAP)........................................................................................................12
III - Les concepts de bases 16
1. Simple Object Access Protocol (SOAP) ...................................................................16
2. Web Services Description Language (WSDL) ..........................................................16
3. Universal Description, Discovery and Integration (UDDI) ......................................18
2
Objectifs
Initiation au protocole et les Web services SOAP
Comprendre les enveloppes SOAP
Créer et tester des services SOAP
3
Mise en œuvre d'un middleware I
Objectifs
Comprendre la mise en oeuvre d'un middleware SOAP via un exemple
1. Exemple d'une architecture SOA
Il y a trois acteurs : registre de service (Annuaire), producteur de service (le serveur), consommateur de
service (le client)
1. le serveur permet la publication des services via des contrats (*.WSDL)
2. le client interroge l'annuaire en cherchant les SW disponibles
3. le UDDI retourne le document descriptif du SW choisi (le contrat WSDL)
4. le client interroge le serveur conformément au WSDL
5. le serveur répond aux requêtes du client par des messages SOAP conforme au WSDL
4
Mise en œuvre d'un middleware
2. Le Service (WSDL)
Exemple
Une classe CalculWS désignée pour le service qui permet de réaliser l'opération de sommation
Dans cette classe CalculWS, une méthode nommée somme prend en paramètre deux valeurs
envoyées par le client et lui retourner leur somme
1 public class CalculWS{
2 public int somme (int val1, int val2){
3 return val1 + val2;
4 }
5}
Pour rendre cette classe un WS, il faut ajouter les annotations JAX-WS pour auto-générer le document
WSDL par le serveur d'application au moment du déploiement.
@webService
annotation relative à la classe en attribuant un nom au service : @webService(name="CalculWS")
1 @webService(name="CalculWS")
2 public class CalculServiceSOAP{
3 ....
4 }
5}
@WebMethod
annotation relative à la méthode en attribuant un nom à l'opération :
@WebMethod(operationName="Somme")
1 @webService(name="CalculWS")
2 public class CalculServiceSOAP{
3 @WebMethod(operationName="Somme")
4 public int somme (int val1, int val2){
5 return val1 + val2;
6 }
7}
@WebParam
annotation relative au(x) paramètre(s) de la méthode pour associer un nom à chaque paramètre :
@WebParam(name="val1")
1 public int somme (@WebParam(name="val1") int val1, @WebParam(name="val2") int val2)
{
2 return val1 + val2;
3 }
Exemple complet
1 @webService(name="CalculWS")
2 public class CalculServiceSOAP{
3 @WebMethod(operationName="Somme")
4 public int somme (@WebParam(name="val1") int val1, @WebParam(name="val2") int
val2){
5 return val1 + val2;
6 }
7}
5
Mise en œuvre d'un middleware
WSDL
1 <definitions xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-utility-1.0.xsd" xmlns:wsp="http://www.w3.org/ns/ws-policy"
xmlns:wsp1_2="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://Service/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://schemas.xmlsoap.org/wsdl/" targetNamespace="http://Service/"
name="CalculWSService">
2 <types>
3 <xsd:schema>
4 <xsd:import namespace="http://Service/"
5 schemaLocation="http://localhost:8686/?xsd=1"/>
6 </xsd:schema>
7 </types>
8 <message name="Somme">
9 <part name="parameters" element="tns:Somme"/>
10 </message>
11 <message name="SommeResponse">
12 <part name="parameters" element="tns:SommeResponse"/>
13 </message>
14 <portType name="CalculServiceSOAP">
15 <operation name="Somme">
16 <input wsam:Action="http://Service/CalculServiceSOAP/SommeRequest"
17 message="tns:Somme"/>
18 <output wsam:Action="http://Service/CalculServiceSOAP/SommeResponse"
19 message="tns:SommeResponse"/>
20 </operation>
21 </portType>
22 <binding name="CalculServiceSOAPPortBinding" type="tns:CalculServiceSOAP">
6
Mise en œuvre d'un middleware
23 <soap:binding transport="http://schemas.xmlsoap.org/soap/http"
24 style="document"/>
25 <operation name="Somme">
26 <soap:operation soapAction=""/>
27 <input>
28 <soap:body use="literal"/>
29 </input>
30 <output>
31 <soap:body use="literal"/>
32 </output>
33 </operation>
34 </binding>
35 <service name="CalculWSService">
36 <port name="CalculServiceSOAPPort" binding="tns:CalculServiceSOAPPortBinding">
37 <soap:address location="http://localhost:8686/"/>
38 </port>
39 </service>
40 </definitions>
JAX-WS
est la nouvelle appellation de JAX-RPC (Java API for XML Based RPC) qui permet de développer
très simplement des services web en Java.
fournit un ensemble d'annotations pour mapper la correspondance JavaWSDL. Il suffit pour cela
d'annoter directement les classes Java qui vont représenter le service web.
Remarque
Dans cette exemple, si les valeurs sont des objets, il faut utiliser le JAXB aussi
JAX-B ou JAX-Binding pour fair le mapping Objet XML (OXM) fait parie dans les version java 6 et 8
à partir de la version 9, JAX-B n’est plus intégré dans le JDK
JAX-WS utilise automatiquement JAX-B
Exemple
Quand JAX-WS fait appel à une méthode qui retourne un objet Compte sous format XML.
JAX-WS utilise automatiquement JAX-B pour convertir l'objet Compte sous format XML
7
Mise en œuvre d'un middleware
Complément
Exemple
@XmlRootElement(name="compte")
public class Compte
JAX-WS Vs JAXB
JAX-WS s'appuie sur l'API JAXB 2.0 pour tout ce qui concerne la correspondance entre document XML
et objets Java.
JAXB 2.0 permet de mapper des objets Java dans un document XML et vice versa.
Il permet aussi de générer des classes Java à partir un schéma XML et vice et versa.
3. Le Serveur
Le serveur utilise un librairie (midelware exemple JAXWS une des spécificité de l'architecture J2EE) qui
s'en charge de récupérer la requête HTTP et qui analyse le message SOAP
Exemple
La classe ServeurJWS réservée au lancement du serveur qui permet de déployer le service
Le Serveur développé par l'utilisateur
1 package Serveur;
2
3 import javax.xml.ws.Endpoint;
4 import Service.CalculWS;
5
6 public class ServeurJWS {
7
8 public static void main(String[] args) {
9 //Spécifier l'@ d'accès
8
Mise en œuvre d'un middleware
10 String url="http://localhost:8686/";
11 //Publier le WS, on fait appel à la méthode appartement à JAX-WS
12 //on publie le SW dans l'url et le SW est une instance de CalculWS
13
14 Endpoint.publish(url, new CalculWS());
15
16 //pour le test
17 System.out.println(url);
18 }
19
20 }
4. Test (SOAP)
Lancer via le navigateur la requête http suivante :
http://localhost:8686/CalculWS?wsdl
L'application envoie le wsdl suite à la requête précédente
Ce WSDL est la description du service.
Comment tester les méthodes de WS ?
Soit via un éditeur tel que Oxygen ou un outil comme SOAPUI
SoapUI : Visualiser la structure des requêtes SOAP Exemple
L'intérêt d'utiliser l'outil SoapUI pour comprendre mieux ce qui circule entre les applications
Création d'un projet
9
Mise en œuvre d'un middleware
tester le WS qui se trouve à cette adresse : http://localhost:8585/CalculWS?wsdl
Le SoapUI se connecte au serveur pour récupérer le WSDL du SW comme on a fait avec le navigateur
10
Mise en œuvre d'un middleware
Suite à l'exemple, on voit la méthode somme
L'utilisateur tape la requête et clique sur l’envoi (submit)
Le résultat s'affiche dans la fenêtre à droite
Remarque
L'envoi de la requête SOAP n'est pas évidant pour un utilisateur non informaticien
En effet le proxy côté client (STUB) répond à cette difficulté qui sera généré à partir du WSDL
11
Mise en œuvre d'un middleware
L'idée pour qu'un client appel la méthode somme du côté serveur (SKELETON), il utilise le proxy qui
s'occupe d'envoyer la requête http au serveur
5. Fonctionnement du premier projet WS SOAP
Lors de l'implémentation, on repose sur la création du projet java
Le client demande au stub de faire appel à la méthode somme
Le Stub se connecte au Skeleton et lui envoie une requête SOAP
Le Skeleton fait appel à la méthode du web service
le web service retourne le résultat au Skeleton
Le Skeleton envoie le réponse SOAP au Stub
Le stub fournie le résultat au client
Les deux cas repose sur l'échange de message SOAP
6. Le client (SOAP)
Le client consomme le web service, le client n'a aucune info sur le langage du developpement du SW il
ne sait que l'@ http
Il faut créer un simple projet java pour le client nommé clientCalculWS
Dans ce client, il faut généré un proxy qui est l'équivalent d'un Stub (voir l'architecture présentée dans
le principe de cette partie)
qui a pour but de faciliter la communication avec le SW
à partir du WSDL, il aura une génération de proxy : un ensemble de classe et de classes
Il existe plusieurs moyens pour générer de proxy en utilisant SOAPUI, eclipse
12
Mise en œuvre d'un middleware
Création de proxy via eclipse
Pour réaliser ceci, créer un web service client qui offre une interface en demandant où se trouve le WS.
13
Mise en œuvre d'un middleware
La figure ci-dessous montre que le proxy SOAP est généré
14
Mise en œuvre d'un middleware
Création de l'application client
1 import Service.CalculServiceSOAPProxy;
2
3 public class Client {
4
5 public static void main(String[] args) throws Exception {
6 //CalculServiceSOAPProxy est généré dans clientCalculWS/bin/service
7
8 CalculServiceSOAPProxy proxy= new CalculServiceSOAPProxy();
9 //appel de la méthode somme
10 int som = proxy.somme(23, 25);
11 System.out.println("somme = " + som);
12
13 }
14
15 }
On exécute l'application client on aura le résultat affiché dans le console
15
Les concepts de bases II
Objectifs
Comprendre le principe de SOAP via un exemple simple
SOAP est un message XML peut être porté par un protocole HTTP ou autre protocole
1. Simple Object Access Protocol (SOAP)
est un protocole d'échange inter-applications indépendant de toute plate-forme, basé sur le langage
XML.
Un appel de service SOAP est un flux ASCII encadré dans des balises XML et transporté dans le
protocole HTTP.
2. Web Services Description Language (WSDL)
WSDL est un document XML qui contient l'interface du Web Service en précisant les méthodes pouvant
être invoquées, leurs signatures et le point d'accès (URL, port, etc..).
C'est, l'équivalent du langage IDL (Interface Development Langage) pour la programmation distribuée
CORBA.
WSDL est une recommandation du W3C (the world wide web consortium) du 26 juin 2007.
WSDL 1.1 a été proposé en 2001 au W3C pour standardisation mais n'est pas approuvée. Cette version
est relative au couplage fort (cf. voir partie Rappel principes de conception)
16
Les concepts de bases
La version 2.0 a été approuvée le 26 juin 2007 et désormais une recommandation officielle du W3C.
Cette version est relative au couplage faible
Le contenu du WSDL est dédié au machine ( c.à.d l'application qui fait appel au WS) . Mais on peut
accéder au WSDL (voir la partie mise en oeuvre du middelware Jax-WS)
WSDL est principalement composé de 6 éléments, avec d'autres éléments optionnels :
définitions : élément racine du document, il donne le nom du service, déclare les espaces de
noms utilisés, et contient les éléments du service (obligatoire).
types : la partie la plus importante. Elle décrit tous les types de données utilisés entre le client et
le serveur , utilise par défaut la spécification XML schéma (définition abstraite).
message : décrit un message unique, que ce soit un message de requête seul ou un message de
réponse seul. L'élément définit le nom du message et peut contenir (ou pas) des éléments ” part
“, qui font référence aux paramètres du message ou aux valeurs retournées par le message
(définition abstraite).
port Type : est l'interface de WS, la partie la plus importante. Elle est constituée d'un ensemble
d'opérations. Chaque opération présente le nom de la méthode, en spécifiant les paramètres
d'entré et de sortie. L'input qui se réfère à un message en entrée et l'output qui se réfère à
message en sortie. Pour chaque méthode, il y a deux messages. Un message qui décrit l'input de
la méthode (nomMethode) et un autre qui décrit l'output (nomMethodeResponse). Chaque
paramètre est déclaré dans le Schema XML
binding : Elle décrit les spécifications concrètes concernant la manière dont le service sera
implémenté : protocole de communication et format des données pour les opérations et
messages définis par un type de port particulier.
WSDL possède des extensions internes pour définir des services SOAP (Simple Objet Architecture
Protocole); de ce fait, les informations spécifiques à SOAP se retrouvent dans cet élément
(définition concrète) ;
17
Les concepts de bases
service : Définit les adresses permettant d'invoquer le service données, ce qui sert à regrouper
un ensemble de ports reliés. La plupart du temps, c'est une URL invoquant un service SOAP
(définition concrète).
3. Universal Description, Discovery and Integration (UDDI)
normalise une solution d'annuaire distribué de Web Services, permettant à la fois la publication et
l'exploration (recherche) de Web Services. UDDI se comporte lui-même comme un Web service dont les
méthodes sont appelées via le protocole SOAP.
C'est l'équivalent d'un moteur de recherche (idem annuaire) qui facilite la recherche des pages web
(idem SW)
Consultation de l'annuaire
L'annuaire UDDI se concentre sur le processus de découverte de l'architecture orientée services (SOA),
et utilise des technologies standards telles que XML, SOAP et WSDL qui permettent de simplifier la
collaboration entre partenaires dans le cadre des échanges commerciaux.
L'accès au référentiel s'effectue de différentes manières.
Les pages blanches comprennent la liste des entreprises ainsi que des informations associées à
ces dernières (coordonnées, description de l'entreprise, identifiants...).
Les pages jaunes recensent les services Web de chacune des entreprises sous le standard WSDL.
Les pages vertes fournissent des informations techniques précises sur les services fournis.
Architecture
Les entreprises publient les descriptions de leurs services Web en UDDI, sous la forme de fichiers WSDL.
Les clients peuvent plus facilement rechercher les services Web dont ils ont besoin en
interrogeant le registre UDDI.
Lorsqu'un client trouve une description de service Web qui lui convient, il télécharge son fichier
WSDL depuis le registre UDDI. Ensuite, à partir des informations inscrites dans le fichier WSDL,
notamment la référence vers le service Web, le client peut invoquer le service Web et lui
demande d'exécuter certaines de ses fonctionnalités.
Le scénario classique d'utilisation de UDDI est illustré ci-dessous. L'entreprise A a publié un
service Web, et l'entreprise B est client de ce service :
Structures de données UDDI
Un registre UDDI se compose de quatre types de structures de données,
Informations métier (businessEntity),
Informations sur le service (businessService),
Informations de liaison (bindingTemplate), et
Informations décrivant les spécifications les services (tModel)
18
Les concepts de bases
Informations métier (businessEntity). La structure businessEntity regroupe des informations
sur l'entreprise ayant publié le service, tel que le nom, la description, les contacts et les
identificateurs de cette entreprise.
Informations sur le service (businessService). Informations décrivant un groupe de services
Web. Cette structure contient des informations sur les familles de services techniques. Elle
regroupe un ensemble de services Web associés à un processus métier ou à un groupe de
services
Informations de liaison (bindingTemplate). Cette structure détient des informations techniques
servant à déterminer le point d'entrée et les spécifications de construction pour l'appel d'un
service Web. La structure bindingTemplate fournit les descriptions de service Web utiles aux
développeurs d'applications souhaitant rechercher et appeler un service Web. La structure
bindingTemplate pointe vers des descriptions d'implémentation d'un service, par le biais d'une
adresse URL, par exemple.
Informations décrivant les spécifications les services (tModel). Cette structure représente les
métadonnées afférentes aux différentes spécifications implémentées par un service Web donné.
tModel fournit un système de références (index) facilitant la reconnaissance des services Web.
L'interface UDDI
L'interface UDDI est définie sous forme de documents UDDI et implémentée sous forme de service Web
SOAP.
Elle est composée des modules suivants :
Interrogation inquiry : Cette interface permet de rechercher des informations dans un
répertoire UDDI.
Publication : Cette interface permet de publier des informations dans un répertoire UDDI.
Sécurité : cette interface est utilisée pour obtenir et révoquer les jetons d'authentification
nécessaires pour accéder aux enregistrements protégés dans un annuaire UDDI.
19
Les concepts de bases
Contrôle d'accès et propriété custody and ownership transfer : Cette interface permet de
transférer la propriété d'informations (qui est à l'origine attribuée à l'utilisateur ayant publié ces
informations) et de gérer les droits d'accès associés.
Abonnement Subscription : Cette interface permet à un client de s'abonner à un ensemble
d'informations et d'être averti lors des modifications de ces informations.
20
