Web Services Plan

1. Introduction
Pr. Abderrahim EL QADI
2. Technologies réparties
Département Informatique
3. Caractéristiques et Architectures des Services Web
EST de Salé- Université Mohammed V de Rabat
4. Protocole de communication SOAP
5. Langage de description WSDL
6. L'annuaire des services UDDI
LP : IAM
7. Mise en œuvre de l’architecture
A.U. : 2017/2018

Web Services -1- A. El Qadi

1. Introduction − Ils implémentent la logique métier rendue consommable par

l'utilisation de standards ( TCP/IP, URI//URL, HTTP/SMTP/,
− Les services web sont des programmes :
SOAP..., pour le transport, puis XML pour le contenu), ce qui permet
• décrits en XML
à n'importe quelle technologie utilisant ces standards de pouvoir
• identifiés par un URI (Uniform Resource Identifier)
l'exploiter, facilitant ainsi l'interopérabilité des applications.
− Ils sont des «librairies» fournissant des données et des services à
− Ils utilisent le port 80, qui est toujours ouvert (employé par le
d’autres applications.
protocole HTTP utilisé par les navigateurs Web). Avec cet avantage,
− Ils permettent la distribution de l'information entre clients,
les services web représentent une sorte de tunneling
fournisseurs, partenaires commerciaux et leurs différentes plates-
(encapsulation de données d'un protocole réseau dans un autre).
formes.

Web Services -2- A. El Qadi Web Services -3- A. El Qadi

Exemples :
– Services Web de Google :
Web Services -4-
– Services de tracking "Smart Car" du Maroc Telecom, qui rend la
voiture connectée et intelligente (Smart):
• Géolocalisation: permet de localiser
en temps réel les déplacements de voiture
• Reporting: donne un historique des différents
trajets effectués par la voiture.
• Comportement de conduite: permet de suivre le comportement
de conduite du conducteur, en affichant chaque semaine un score
de conduite et son évolution dans le temps.
Web Services -6-
• Google Docs : Solution en ligne directement concurrente
de Microsoft Office mais gratuite et permettant en plus de créer
des fichiers au format pdf.
• Google Agenda : Calendrier et agenda en ligne interconnecté
avec Gmail.
• Google Earth : programme de recherche géographique lancé en
2005.
• Google Chrome : Navigateur web en partie Open source.
• ...
A. El Qadi Web Services -5- A. El Qadi
2. Technologies réparties
− RMI (Remote Method invocation): - Pour manipuler un objet distant, un client
récupère sur sa machine une représentation
de l'objet appelé talon/souche (stub): ce
talon implante l'interface de l'objet distant
et c'est via ce talon que le client pourra
invoquer des méthodes sur l'objet distant.
Une telle invocation sera transmise au
serveur (le protocole TCP est utilisé) afin
d'en réaliser l'exécution.
- Du côté du serveur un skeleton/squelette
• Stub (Souche) : Fait la transition entre l’appel
a en charge la réception des invocations
du client et le réseau
distantes, de leur réalisation et de l'envoi
• Skeleton (Squelette) : Fait la transition entre
des résultats.
le réseau et l’appel vers l’Objet Serveur.
A. El Qadi Web Services -7- A. El Qadi
 − CORBA (Common Object Request Broker Architecture) − Ces technologies ont généralement échoué en raison de la diversité
des plates-formes utilisées dans les organisations et aussi parce que
est une plate forme :
- issu de l’OMG (Object Management Group) leur usage n'était pas adapté à Internet (problème de passage à
- Objectif : créer une infrastructure à objets ouverte. travers des FireWalls, etc.) d'où la lenteur, voire l'absence de
- architecture définit la forme des composants et leur réponses sur ce réseau.
mode d’interopérabilité (IDL) (Interface Definition
Language − Les applications réparties fondées sur ces technologies offrent des
- les clients connaissent l’interface de l’objet.
solutions caractérisées par un couplage fort entre les objets.
- son mode de fabrication est transparent pour ses clients
potentiels
- la machine et son système d’exploitation ne sont pas
connues des clients.

Web Services -8- A. El Qadi Web Services -9- A. El Qadi

− Web services: permettent néanmoins un couplage moins fort. • le couplage faible des applications (évolution indépendante) et leur
• L'utilisation des technologies standards du Web coopération via des interfaces de haut niveau d’abstraction (services

telles HTTP et XML par les services Web facilite le globaux).

développement d'applications réparties sur Internet, et permet − La plus importante innovation des Services Web est l'utilisation de

d'avoir des applications très faiblement couplées. XML (eXtensible Markup Language) comme EDI.

− Les Web services assurent: <?xml version="1.0" encoding="ISO-8859-1"?>

<adresse>
• Interopérabilité: <lieu>
<rue> rue de badr</rue>
− Différentes Applications (Client et/ou Serveur)
<numero>8</numero>
− Différents Systèmes d‘Exploitation </lieu>
<ville>Rabat></ville>
− Différents Hardwares
<code>10000</code>
</adresse>

Web Services -10- A. El Qadi Web Services -11- A. El Qadi

 • il communique en utilisant des messages XML, ces messages
3. Caractéristiques et architectures des
sont transportés par des protocoles Internet (généralement HTTP,
Services Web mais rien n'empêche d'utiliser d'autres protocoles de transfert tels:
3.1. Caractéristique d'un Web Service SMTP, FTP, ... ) ;

− Un service Web possède les caractéristiques suivantes : • l'intégration d'application en implémentant des services Web

• il est accessible via le réseau ; produit des systèmes faiblement couplés, le demandeur du

• il dispose d'une interface publique (ensemble d'opérations) service ne connaît pas forcément le fournisseur.

décrite en XML ; Ce dernier peut disparaître sans perturber l'application cliente qui

• ses descriptions (fonctionnalités, comment l'invoquer et où le trouvera un autre fournisseur en cherchant dans l'annuaire.

trouver ?) sont stockées dans un annuaire ;

Web Services -12- A. El Qadi Web Services -13- A. El Qadi

3.2. Architecture d'un service Web

Trois acteurs :
- le fournisseur de service (Service
Provider ) :
• définit le service
• publie sa description dans l’annuaire
• réalise les opérations
- l’annuaire (discovery agency) :
• • reçoit et enregistre les descriptions
de services publiées par les
• fournisseurs
• reçoit et répond aux recherches de
• services lancées par les clients.
- le client (Service Requestor ) :
• • obtient la description du service
grâce à l’annuaire
• utilise le service.

Web Services -14- A. El Qadi Web Services -15- A. El Qadi

 − Les technologies utilisées par les services Web sont HTTP, WSDL,
REST, XML-RPC, SOAP et UDDI :
− REST : (Representational State Transfer) est une architecture
permet de construire une application pour les systèmes distribués
comme le World Wide Web.
− XML-RPC : est un protocole simple utilisant XML pour
effectuer des messages RPC. Les requêtes sont écrites en XML et
envoyées via HTTP POST. Les requêtes sont intégrées dans le
corps de la réponse HTTP.
RPC (Remote procedure call): protocole d'appel de procédures à distance).
Web Services -16- A. El Qadi
− UDDI: (Universal Description, Discovery and Integration) est
un annuaire de services. Il fournit l'infrastructure de base pour la
publication et la découverte des services Web. Les informations
qu'il contient peuvent être séparées en trois types :
• les pages blanches qui incluent l'adresse, le contact et les
identifiants relatifs au service Web ;
• les pages jaunes qui identifient les secteurs d'affaires relatifs au
service Web ;
• les pages vertes qui donnent les informations techniques.
Web Services -18- A. El Qadi
− SOAP : (Simple Object Access Protocol) est un protocole
standard de communication.
• C'est l'épine dorsale du système d'interopérabilité.
• Il circule sur le protocole HTTP et permet d'effectuer des appels de
méthodes à distance.
− WSDL : (Web Services Description Language) est un langage de
description standard.
• C'est l'interface présentée aux utilisateurs.
• il est basé sur XML et permet de décrire de façon précise les détails
concernant le service Web tels que les protocoles, les ports utilisés,
les opérations pouvant être effectuées, les formats des messages
d'entrée et de sortie et les exceptions pouvant être envoyées.
Web Services -17- A. El Qadi
4. Protocole de communication SOAP
− SOAP (Simple Object Access Protocol) a pour principal objectif d'assurer la
communication entre machines.
− est basé sur XML
− est un protocole permet d'appeler une méthode RPC et d'envoyer des messages
aux machines distantes via HTTP. Ce protocole permet de fournir au client une
grande quantité d'informations récupérées sur un réseau de serveurs tiers.
Web Services -19- A. El Qadi
 4.1. Structure d'un message SOAP Exemple :
− Un message SOAP est composé de deux parties obligatoires: <?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
l'enveloppe SOAP et le corps SOAP ; et une partie optionnelle: soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding">
<soap:Header>
l'en-tête SOAP.
<!-- en-tête -->
</soap:Header>
<soap:Body>
<!-- corps -->
</soap:Body>
</soap:Envelope>

Web Services -20- A. El Qadi Web Services -21- A. El Qadi

a. SOAP envelope (enveloppe) est l'élément de base du message − Deux autres espaces de noms fortement utilisés dans SOAP sont
SOAP. Il contient la spécification des espaces de désignation « xsd » et « xsi » :
(namespace) et du codage de données. • xsd namespace précise que les balises proviennent de la définition

− La spécification SOAP définit deux namespaces fréquemment de schéma XML.

• xsi namespace indique que les balises viennent d'une instance d'un
utilisés :
schéma XML.
• soap-env ou soap associé à l'URI
«[..]schemas.xmlsoap.org/soap/envelope» pour définir le
namespace de l'enveloppe dans la version 1.1.
• soap-enc:encodingStyle associé à l'URI
«[..]schemas.xmlsoap.org/soap/encoding» pour la définition des
formats de types de données dans la version 1.1.

Web Services -22- A. El Qadi Web Services -23- A. El Qadi

 b. SOAP header (entête) est un élément facultatif dans un • soap:role : sert à indiquer le destinataire SOAP auquel un
message SOAP. bloc d'en-tête SOAP particulier est destiné.
− L'en-tête d'un message SOAP commence avec la balise • soap:relay : est utilisé pour indiquer si un bloc d'en-tête
<soap:Header> et se termine avec la balise </soap:Header>, ou SOAP ciblé sur un récepteur SOAP doit être réacheminé
<sopa-env:Header> </sopa-env:Header>. (relayé) s'il n'est pas traité.
− Trois attributs associés à l'en-tête peuvent être utilisés:
• soap:mustUnderstand : cet attribut prend la valeur 1 ou 0.
La valeur 1 signale que le récepteur doit reconnaître
l'information présente dans l'en-tête et que son traitement est
obligatoire. La valeur 0 indique que l'en-tête peut être ignoré
par le récepteur.

Web Services -24- A. El Qadi Web Services -25- A. El Qadi

c. SOAP body (corps) est un élément obligatoire dans le message Exemple de Bloc Header et Body:
SOAP. SOAP Request : SOAP Response :
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-
− Il contient l'information destinée au receveur. <S:Envelope 8"?><S:Envelope
− Le corps (body) doit fournir le nom de la méthode invoquée par xmlns:S="http://schemas.xmlsoap.org/soap/envel xmlns:S="http://schemas.xmlsoap.org/soap/envelop
ope/"> e/">
une requête ainsi que les paramètres associés a celle-ci. <S:Header/> <S:Body>
<S:Body> <ns2:sommerResponse
<ns2:sommer xmlns:ns2="http://TP/"> xmlns:ns2="http://TP/">
<a>3</a> <return>8</return>
<b>5</b> </ns2:sommerResponse>
</ns2:sommer> </S:Body>
</S:Body> </S:Envelope>
</S:Envelope>

Web Services -26- A. El Qadi Web Services -27- A. El Qadi

 d. SOAP fault (erreur) est un élément facultatif défini dans le • soap:Server : indique qu'une erreur s'est produite sur le serveur.
corps SOAP et qui est utilisé pour reporter les erreurs. • soap:Client : signifie que le message reçu contient une erreur.

− La balise <soap:fault> peut contenir quatre autres balises • soap:VersionMismatch : se produit lorsque les versions des
protocoles SOAP utilisés par le client et le serveur sont différentes.
facultatives :
• soap:MustUnderstand : est générée lorsqu'un élément dans l'en-
• faultcode : contient un code indiquant la nature du problème.
tête ne peut pas traiter alors qu'il est marqué comme obligatoire.
• faultstring : une explication en langage naturel.
• faultactor : indique le service qui a généré l'erreur.
• detail : définition précise de l’erreur; Il contient souvent des valeurs
de variables au moment de l'échec.

− Quatre types de codes d'erreur sont définis par la spécification:

Web Services -28- A. El Qadi Web Services -29- A. El Qadi

Exemple : Bloc Fault 5. Langage de description WSDL

<soap:Body>
<soap:Fault> − Décrit les aspects techniques d’implantation d’un service web
<!-- Identifiant de l'erreur ? défini par SOAP -->
<faultcode>soap:Server</faultcode> (quel est le protocole utilisé,
<!-- Description brève du message -->
<faultstring> msage.</faultstring> quel est l’adresse du service)
<!-- Composant qui a généré l'erreur (URL). -->
<faultactor> ..... </faultactor> Une description WSDL est un document
<!-- Message spécifique à l'application -->
<detail>
XML qui commence par la balise
<m:error xmlns:m="http://www.monsite.com/errors"> /m:error> Definition et contient les balises suivantes :
</detail>
</soap:Fault>
</soap:Body>

<message name="IOException">
<part name="fault" element="tns:IOException"/>
</message>

Web Services -30- A. El Qadi Web Services -31- A. El Qadi

 – Types : cette balise décrit les types utilisés. – Messages : représente une définition abstraire (noms et types) des
<wsdl:types> données en cours de transmission.
<xs:schema
targetNameSpace="http://www.exemple.fr/personne.xsd" • Un message est composé de plusieurs part :
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="personne"> • Part de type simple
<xs:complexType> <wsdl:message name="personneMsg">
<xs:sequence> <wsdl:part name="nom" type="xsd:string" />
<xs:element name="nom" type="xs:string" />
<wsdl:part name="prenom" type="xsd:string" />
<xs:element name="prenom" type="xs:string" />
</xs:sequence> </wsdl:message>
</xs:complexType>
</xs:element> • Part qui utilise un XML Schema
</xs:schema> <wsdl:message name="personneMsg">
</wsdl:types
<wsdl:part name="personne" element="exemple:personne" />
</wsdl:message>

Web Services -32- A. El Qadi Web Services -33- A. El Qadi

– PortTypes : décrit un ensemble d'opérations. Chaque opération a – Opération : c'est la description d'une action exposée dans le port.
zéro ou un message en entrée, zéro ou plusieurs messages de sortie • L'élément <operation> est analogue à un appel de méthode en Java.
ou d'erreurs. La différence est que seulement trois messages sont autorisés dans

• la définition abstraite d'un port est appelée <portType> une opération :

<wsdl:portType name="descriptionPersonnes" > - Input Message : définit les données que le service Web s'attend à
<wsdl:operation name="getPersonne" > recevoir.
…
- OutPut Message : définit les données que le service Web prévoit
</wsdl:operation>
<wsdl:operation name=“setPersonne" > d'envoyer en réponse.
… - Fault Message : définit les messages d'erreurs qui peuvent être retournés
</wsdl:operation>
</wsdl:portType> par le service Web.

Web Services -34- A. El Qadi Web Services -35- A. El Qadi

 • Plusieurs types d'opération peuvent être déclarés dans un document – Binding : spécifie une liaison entre un <portType> et un protocole
WSDL : concret (SOAP, HTTP...).
- Request/Response : le client envoie la demande, et le service répond. • Un Binding :
- Solicit/Response : un service Web envoie un message au client, et le - peut être identifié par un nom : name
client répond. - identifie le portType : type
- One-way : un client envoie un message au service Web, mais ne s'attend à
<wsdl:binding name="Personne_WSSoapBinding"
aucune réponse.
type="impl:Personne_WS">
- Notification : un service Web envoie un message au client, mais n'attend
…
pas de réponse.
</wsdl:binding>
<wsdl:operation name="getPersonne">
<wsdl:input message="impl:getPersonneRequest" name="getPersonneRequest">
</wsdl:input>
<wsdl:output message="impl:getPersonneResponse" name="getPersonneResponse">
</wsdl:output> </wsdl:operation>

Web Services -36- A. El Qadi Web Services -37- A. El Qadi

• Soap Binding : − Pour chaque opération du portType :

− Pour préciser que le binding est de type SOAP, il faut inclure la • il faut préciser l’URI de l’opération : soapAction
balise suivante : • Il est aussi possible de repréciser la façon dont sont créés les
<wsdlsoap:binding style="document" messages SOAP : style
transport="http://schemas.xmlsoap.org/soap/http"/> − Pour chaque message de chaque opération, il faut définir comment
sera créé le message SOAP
• Transport définit le type de transport.
• Style définit la façon dont sont créer les messages SOAP de
toutes les opérations :
- rpc : Encodage RPC défini par SOAP RPC
- document : Encodage sous forme d’élément XML.

Web Services -38- A. El Qadi Web Services -39- A. El Qadi

 Exemple: – Service : indique les adresses de port de chaque liaison.
<wsdl:binding type="descriptionPersonnes" > • IL définit les ports soutenus par le service Web.
<soap:binding
• Il contient aussi un élément <documentation> qui fournit la documentation
transport="http://schemas.xmlsoap.org/soap/http" style="rpc" />
<wsdl:operation name="getPersonne"> lisible par l'homme.
<soap:operation soapAction="http://www.exemple.fr/getPersonne" />
<wsdl:input> – Port : représente un point d'accès de services défini par une
<soap:body use="encoded"
encodingStyle="schemas.xmlsoap.org/soap/encoding"/>
adresse réseau et une liaison.
</wsdl:input> • Le port contient un élément <soap:address> qui spécifie à l'aide de
<wsdl:output>
<soap:body use="encoded" l'attribut location une URL représentant l'adresse du port.
encodingStyle="schemas.xmlsoap.org/soap/encoding"/> <wsdl:service name="Personne_WSService">
</wsdl:output> <wsdl:port binding="impl:Personne_WSSoapBinding" name="Personne_WS">
</wsdl:operation> <wsdlsoap:address
</wsdl:binding> location="http://localhost:8082/WebServiceProject/services/Personne_WS"/>
</wsdl:port>
</wsdl:service>

Web Services -40- A. El Qadi Web Services -41- A. El Qadi

1. Définition du service (fournisseur): Description WSDL

6. L'annuaire des services UDDI
des entrées/sorties, des caractéristiques du service.
• Utilisation de UDDI: L'entreprise B a publié le service Web S, et 2. Publication du service (fournisseur): Publication de la
l'entreprise A est client de ce service : description WSDL dans un annuaire (UDDI).
3. Recherche de service (client): Recherche d’un service dans un annuaire
4. Enregistrement du service web (client): Enregistrement auprès du
fournisseur pour accéder au service trouvé.
5. Exécution du service avec les paramètres fournis par le client.
6. Composition (client, fournisseur):Utilisation du résultat pour l’appel à
d’autres services (client)
• Appel d’un autre service lors de l’exécution du service appelé (fournisseur).

Web Services -42- A. El Qadi Web Services -43- A. El Qadi

 – Principaux fournisseurs − Structures de données UDDI :
• IBM UDDI Registry (www-3.ibm.com/services/uddi/) • Un registre UDDI se compose de quatre types de structures de
• Microsoft UDDI Business Registry (UBR) données :
(uddi.microsoft.com/default.aspx) - BusinessEntity (entité d'affaires) : sont en quelque sorte les pages
• Oracle Application Server UDDI Regsitry blanches d'un annuaire UDDI.
(otn.oracle.com/tech/webservices/htdocs/uddi/). Elles décrivent les organisations ayant publié des services dans le répertoire.
- BusinessService (service d'affaires) : sont en quelque sorte les pages jaunes
d'un annuaire UDDI.
Elles décrivent de manière non technique les services proposés par les
différentes organisations.

Web Services -44- A. El Qadi Web Services -45- A. El Qadi

On y trouve essentiellement le nom et la description textuelle des
services ainsi qu'une référence à l'organisation proposant le
service et un ou plusieurs « bindingTemplate ».
- BindingTemplate (modèle de rattachement) : Ce sont les pages
vertes de l'annuaire UDDI.
Ils contiennent notamment une description, la définition du point
d'accès (une URL) et les éventuels « tModels » associés.
- tModel (index) : se sont les descriptions techniques des services.
− 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 et de lire les différents
enregistrements suivant le modèle de données UDDI.
• Publication : cette interface permet de publier des informations dans un
répertoire UDDI conformément à son modèle de données.
• 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.

Web Services -46- A. El Qadi Web Services -47- A. El Qadi

 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.
7. Mise en œuvre de l’architecture
Des services Web peuvent être déployés en employant un logiciel de serveur
d'applications :
− JAX-WS 2.x qui constitue l'implémentation de référence de Java EE est open
source et intégré dans GlassFish et utilisable dans d'autres environnements.
− Axis et le serveur de Jakarta Tomcat (deux projets open source d'Apache
Software Foundation)
− Serveurs HTTP IIS de Microsoft (avec le framework .NET)
− WebLogic d'Oracle Corporation
− WebSphere Application Server d'IBM (basé sur le serveur d'Apache et la plate-
forme de J2EE)

Web Services -48- A. El Qadi Web Services -49- A. El Qadi

Exemple 1 : Création d'un Service Web en utilisant le fournisseur de services L’environnement d’exécution et de déploiement des services web que nous utilisons est l’outil
« Axis ».
Web Axis
Vous noterez qu’il n’est pas nécessaire de compiler le source java.
Vous êtes désormais en mesure d’accéder à votre service à l’URL suivante :
a. Création du web service http://localhost:8082/axis/Sommer.jws

La première étape consiste à définir la classe du service web qui retournera au client la somme
de 2 entiers. There is a Web Service here
public class Sommer { Click to see the WSDL
public int getsomme(int a, int b) {
return a+b;
}
} Si vous cliquez sur ce dernier lien, vous verrez la définition « WSDL » (générée automatiquement
par « Axis ») de votre service web.
Attention, vous devez sauvegardez votre classe sous le fichier portant le même nom de la classe
http://localhost:8082/axis/Sommer.jws?wsdl
et suffixé par « jws » ! Ici, le fichier de sauvegarde sera donc : « Sommer.jws ». dans le dossier
C:\Program Files\Apache Software Foundation\Tomcat 6.0\webapps\axis
b- Déploiement du web service

La deuxième étape consiste à déployer le service au sein d’un fournisseur de services web.

Web Services -50- A. El Qadi Web Services -51- A. El Qadi

Web Services -52- A. El Qadi Web Services -53- A. El Qadi

c- Test du web service Exemple 2 : Création d'un Web Service en utilisant Outils NetBeans
Pour exécuter une méthode de votre service et obtenir la réponse « SOAP » correspondante,
vous tapez l’expression suivante dans votre navigateur :
http://localhost:8082/axis/Sommer.jws?method=getsomme&a=4&b=6
Par rapport à l’expression précédente, vous précisez ici le nom de la méthode à exécuter, sous la
forme de la valeur de l’attribut « method » et vous précisez les valeurs des paramètres a et b.
La réponse affichée est le contenu « SOAP », c’est-à-dire un fichier « XML » dont voici un extrait :

Web Services -54- A. El Qadi Web Services -55- A. El Qadi

 •

Web Services -56- A. El Qadi Web Services -57- A. El Qadi

Exemple 3: Interopérabilité : Appel le service web à partir de

DOT.NET

- Dans Eclipse, sélectionner le dossier racine du projet Web Service (Calculatrice.wsdl), et utiliser le
menu contextuel pour Exporter sous la forme d’une Web Archive. Choisir le dossier webapps de
tomcat pour enregistrer l’archive. Ajouter la clause using concernant la web référence générée.
- Démarrer serveur Tomcat, using AppelWS_Calcul.ServiceReference1;
- Sous Visual Studio.Net, créer un nouveau projet de type « Visual C# / Windows / Windows
Application » nommé AppelWSCalcul : Dans le corps de la méthode, saisir le code de l'appel du service web.
- Sélectionner l'option « Add new DataSource » du menu principal « Data » Exemple de code:
- Sélectionner « Web Service » et cliquez sur bouton « Next ». private void button1_Click(object sender, EventArgs e)
{
CalculatriceClient cs = new CalculatriceClient();
int a = int.Parse(textBox1.Text);
int b = int.Parse(textBox2.Text);
int resultat = cs.additionner(a, b);
label4.Text = "" + resultat;
}

- Dans la fenêtre du projet, ajouter 2 contrôles de type TextBox et 3 de type Button.

Web Services -58- A. El Qadi Web Services -59- A. El Qadi
 8. Sécurité des Web Services
− Les Services Web, par nature ouverts et interopérables, constituent des points d’entrée
privilégiés pour des attaques.
− Pour répondre à cette problématique, les différentes solutions existantes reposent sur
une sécurisation :
• Au niveau réseau : visant à assurer principalement le chiffrement, l’intégrité et
l’authentification des échanges réseau.
• Au niveau applicatif: apportant des fonctionnalités plus étendues telles que la
fédération d’identités.
− Afin de pallier à ces vulnérabilités potentielles, un certain nombre de bonnes pratiques
doivent être prises en compte. Elles s’articulent autour de 3 axes majeurs qui sont :
8.1. Sécurisation coté Client
8.1.1. Contrôle d’accès : Le Service Web doit implémenter un
mécanisme d’authentification pour contrôler la légitimité des accès :
HTTP Digest/Basic, Active Directory, Base de données, Certificats.
8.1.2. Gestion des sessions: Si le mécanisme d’authentification
utilisé n’implémente pas nativement une gestion des sessions, il est
nécessaire d’implémenter une gestion des sessions de manière
applicative.
8.1.3. Gestion des comptes: Les comptes utilisés par l’application
doivent respecter le principe du moindre privilège afin d’éviter une trop
grande exposition en cas de compromission de celui-ci.

Web Services -60- A. El Qadi Web Services -61- A. El Qadi

8.2. Sécurisation de l'application (TP n°5) • Contrôle de la sensibilité des informations remontées en cas d’erreur

8.2.1. WSDL: L’accès à la WSDL doit être sécurisé et n’être autorisé 8.2.4. Protection contre le rejeu: Les Services Web n’intègrent pas

qu’aux clients identifiés : Filtrage IP des clients. par défaut de mécanismes contre le rejeu. Le développeur doit intégrer
des mécanismes anti rejeu sur les fonctions sensibles du Service Web.
8.2.2. Contrôle des entrées: Chaque donnée en entrée doit faire
• Protection applicative contre le rejeu
l’objet d’un contrôle afin de s’assurer qu’elle correspond au type attendu
• Protection système contre le rejeu
et qu’elle respecte la syntaxe attendue :
• Valider la taille, le format, le type des données en entrée,
• Valider la taille, la longueur et la profondeur des messages XML parsés.
8.2.3. Gestion des exceptions: Les erreurs possibles du Service
Web doivent être interceptées et gérées afin de ne pas fournir
d’informations potentielles à un attaquant : Gestion des exceptions
(Try/Catch),
Web Services -62- A. El Qadi Web Services -63- A. El Qadi
 8.3. Sécurisation des échanges • Références
8.3.1. Confidentialité: Les échanges SOAP, par exemple, doivent − Services Web avec J2EE et .NET : Conception et implémentations;
être sécurisés et les messages chiffrés : Rampart, WS-Security, TLS, Libero M. , Christian B., Xavier L.; Edition Eyrolles.
IPSec − Book Web Data Management and Distribution,
8.3.2. Intégrité: Les parties critiques des messages SOAP doivent http://webdam.inria.fr/textbook
être signées afin d’en garantir leur exactitude : Rampart, WS-Security, − http://apiacoa.org/teaching/webservices/index.fr.html
TLS, IPSec − www.labri.fr/perso/xblanc/data/OldCourses/XB4-WebServices.ppt
8.3.3. Disponibilité: Les Services Web critiques en disponibilité − https://www.ibisc.univ-evry.fr/~tmelliti/cours/CPAR/cours6.pdf
doivent faire l’objet de mesures adaptées supportées par des composants
d’infrastructure et applicatifs : Redondance de l’infrastructure, WS-
Reliability.

Web Services -64- A. El Qadi Web Services -65- A. El Qadi