W

E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
1
FABRICE CLARI- FABRICE.CLARI@ZALTANA.FR
FABRICE CLARI- FABRICE.CLARI@ZALTANA.FR
WEBSERVICES
XML
SOAP, WSDL
RPC avec SOAP
AXIS
SOA

WEBSERVICES
XML
SOAP, WSDL
RPC avec SOAP
AXIS
SOA

W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
2
Pr-requis
o XML
o Espaces de noms (namespaces)
o XML Schema
Services Web : dfinition
SOAP
Les protocoles de communication
RPC avec SOAP
WSDL
UDDI
Un scnario
Les diteurs
La scurit des services web
AXIS
SOA
Sommaire
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
3
Introduction XML (1/4)
Afin de bien comprendre le fonctionnement des services web, il est important
davoir quelques connaissances sur le langage XML et XML Schema.
XML est un langage balis qui est rapidement devenu le standard pour
lchange de donnes ;
Les donnes sont identifies grce des tags (tout tag ouvert doit
imprativement tre ferm) ;
A la diffrence de HTML, les tags XML identifient des donnes et non un
affichage.
Exemple :
<?xml version="1.0" encoding="ISO-8859-1" ?>
<album>
<artiste>Jean-Jacques Goldman</artiste>
<titre>Chansons pour les pieds</titre>
<date_de_parution>2001</date_de_parution>
<chansons>
<titre piste='1'>Ensemble</titre>
<titre piste='2'>Et l'on y peut rien</titre>
<titre piste='3'>Une poussire</titre>
</chansons>
<prix euros='20' />
</album>
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
4
Introduction XML (2/4)
Entre deux tags XML ouvert/ferm, se trouve un lment ;
Un tag XML peut contenir dautres tags, ce qui permet une reprsentation
hirarchique des donnes ;
Un tag peut contenir un (voire plusieurs) attribut(s) (piste dans le tag titre
de lexemple prcdent) ;
Tous les tags ouverts doivent tre ferms ;
Un tag vide est valide (<prix euros='20' /> par exemple) ;
Exemple de commentaires en XML : <!-- commentaire --> ;
Un document XML commence par un prologue :
<?xml version="1.0" encoding="ISO-8859-1" ?>
Diffrents types de parseur XML existent : DOM (Document Object Model),
qui construit un arbre en mmoire du document, et SAX (Simple API to XML) qui
associe un vnement chaque balise lue.
Astuce : pour vrifier la validit dun document XML, vous pouvez louvrir avec
Internet Explorer (version suprieure ou gale la 5.5) qui dispose dun parseur
XML. Il affichera une erreur si le document est syntaxiquement faux.
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
5
<?xml version="1.0" encoding="ISO-8859-1" ?>
<albums>
<album>
<artiste>Jean-Jacques Goldman</artiste>
<titre>Chansons pour les pieds</titre>
<date_de_parution>2001</date_de_parution>
<chansons>
<piste n='1'>Ensemble</piste>
<piste n='2'>Et l'on y peut rien</piste>
<piste n='3'>Une poussire</piste>
</chansons>
<prix euros='20' />
</album>
</albums>
Introduction XML (3/4)
La notion despace de noms (namespace) est trs utilise dans les services web.
Les namespaces permettent :
de qualifier de manire unique des lments et des attributs ;
la dfinition de balises modulaires.
Exemple
Un magasin de disques et de livres peut caractriser son stock par deux
documents XML :
Un dcrivant ses disques Un dcrivant ses livres
<?xml version="1.0" encoding="ISO-8859-1" ?>
<livres>
<livre>
<auteur>Jean-Marie Chauvet</auteur>
<titre>Services Web avec SOAP, WSDL, </titre>
<date_de_parution>2002</date_de_parution>
<editeur>eyrolles</editeur>
<prix euros=39' />
</livre>
</livres>
Problme : la balise <titre> contient deux types dinformations.
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
6
<?xml version="1.0" encoding="ISO-8859-1" ?>
<magasin
xmlns:magasin="http://magasin.org"
xmlns:album="http://album.org"
xmlns:livre="http://livre.org">
<magasin:albums>
<magasin:album>
<album:artiste>Jean-Jacques Goldman</album:artiste>
<album:titre>Chansons pour les pieds</album:titre>
<album:date_de_parution>2001</album:date_de_parution>
<album:chansons>
<album:piste piste='1'>Ensemble</album:piste>
<album:piste piste='2'>Et l'on y peut rien</album:piste>
<album:piste piste='3'>Une poussire</album:piste>
</album:chansons>
<album:prix euros='20' />
</magasin:album>
</magasin:albums>
<magasin:livres>
<magasin:livre>
<livre:auteur>Jean-Marie Chauvet</livre:auteur>
<livre:titre>Services Web avec SOAP, WSDL, </livre:titre>
<livre:date_de_parution>2002</livre:date_de_parution>
<livre:editeur>eyrolles</livre:editeur>
<livre:prix euros='39' />
</magasin:livre>
</magasin:livres>
</magasin>
Introduction XML (4/4)
Lespace de nom (xmlns) permet de crer un nom unique pour chacune des
balises <titre>, en associant un identifiant unique (URI, Uniform Ressource
Indentifier) un nom.
Ces URI ne sont pas vrifies. En
gnral, elles pointent sur la
grammaire de lespace de noms.
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
7
Introduction XML Schema
XML Schema prcise comment reprsenter en XML une structure de donnes. A
la diffrence des DTD, qui ne dfinissent que les imbrications des lments entre
eux, XML Schema dfinit les imbrications ainsi que les types des donnes
(lments et attributs).
Ainsi, le XML Schema dfinissant lexemple <livre> (simplifi) est :
<xsd:schema xmlns:xsd="http://www.w3.org/2000/10/XMLSchema">
<xsd:element name="livre">
<xsd:complexType>
<xsd:sequence>
<xsd:element name=" auteur" type="xsd:string"
minoccurs="1" maxoccurs="1"/>
<xsd:element name="titre" type="xsd:string"/>
<xsd:element name="date_de_parution" type="xsd:string"/>
<xsd:element name="editeur" type="xsd:string"/>
<xsd:element name="prix">
<xsd:complexType>
<xsd:attribute name="euros"
type="xsd:int"
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
8
De multiples dfinitions de la notion de Web Services existent, mais sont
gnralement trop vagues ou trop prcises.
Un groupe de travail du W3C (Web Services Architecture group, compos de
multiples membres de lindustrie) en donne une dfinition exacte :
A web service is a software application identified by a
URI, whose interfaces and binding are capable of being
defined, described, and discovered by XML artifacts, and
supports direct interactions with other software
applications using XML-based messages via Internet-based
protocols .
(source : http://www.w3c.org/2002/ws/arch/2/08/wd-wsa-arch-20020821.html#webservice)
Cette dfinition met laccent sur lutilisation du langage XML, utilis pour dcrire
la structure des messages changs entre clients et serveurs de Services Web ;
Elle ne prcise pas quel protocole de transport doit tre utilis. Cependant, il doit
sagir dun protocole utilis sur Internet.
Web Services : une dfinition
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
9
Les composants dun service web
Afin de mettre en uvre un service web, trois composants sont ncessaires :
un protocole pour dcrire le service : il permet entre autres- dnumrer
les mthodes disponibles, ainsi que leurs signatures (nous tudierons plus
tard WSDL) ;
un protocole pour crire les messages ;
un protocole de transport, afin de faire circuler les informations sur Internet.
http://www-106.ibm.com/developerworks/webservices/library/ws-best1/?dwzone=webservices#figure1
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
10
Le protocole SOAP (1/5)
Le protocole SOAP (Simple Object Access Protocol) est devenu le standard
pour dcrire les messages en XML entre services web. Ce dernier peut tre utilis
sur diffrents protocoles de transports. Les deux principaux protocoles utiliss
tant HTTP et SMTP.
De par sa nature, SOAP permet linter-oprabilit entre diffrents systmes
dexploitation et diffrentes plate-formes (J2EE, .NET, ).
SOAP permet de crer des applications de type distribues, en suivant le modle
RPC (Remote Procedure Call).
La grande majorit des services web utilise
le protocole SOAP.
Un message SOAP est un document XML
compos dune enveloppe qui contient
une entte et le corps du message.
Enveloppe SOAP
En-tte SOAP
(header)
Corps du message SOAP
(body)
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
11
<Envelope>
<Header>
<Transaction>3<Transaction>
</Header>
<Body>
<echoString>
<arg0>Hello!</arg0>
</echoString>
</Body>
</Envelope>
Lenveloppe contient tout le message
Le protocole SOAP (2/5)
Prenons lexemple dun message SOAP appelant une mthode echoString(string), qui prend
en paramtre une chane de caractres.
Le corps (body) du message
contient toutes les informations
destines au rcepteur (les
paramtres par exemple) ou
llment fault si une erreur sest
produite.
Lentte (header) contient des
informations non-lies la
mthode, comme par exemple lID
de la transaction ou des
informations pour la scurit (infos
du header = gestion du contexte).
Lentte est facultative et les
lments quelle contient peuvent
avoir lattribut mustUnderstand,
qui prcise si le serveur est oblig
de connatre et traiter llment.
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
12
<Envelope>
<Header>
<Transaction>3<Transaction>
</Header>
<Body>
<echoStringResponse>
<return>Hello!</return>
</echoStringResponse>
</Body>
</Envelope>
Le protocole SOAP (3/5)
Lorsque le serveur rpond la mthode echoString(string), il ajoute Response la suite du
tag <echoString> (dune manire gnrale, il rajoute Response la suite du tag contenant
le nom de la requte.
Si une erreur se produit, la rponse contient llment Fault (dans le corps du message).
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
13
Le protocole SOAP (4/5)
Une des forces de SOAP est de permettre linter-oprabilit entre diffrentes
plate-formes. Il est donc important davoir des rgles de codage des types de
donnes, afin que ces dernires puissent tre encodes/dcodes sans
difficults.
On distingue deux types de donnes :
Les donnes de types simples (une chane de caractre par exemple) ;
Les types composs : structures ou tableaux.
Dans le cas o des donnes binaires devraient transiter (comme une image par
exemple), il est galement possible denvoyer un message SOAP avec
attachement et ce grce un message MIME (Multimedia Internet Mail
Extension).
Pour pouvoir rfrencer une pice jointe depuis le corps du message SOAP, une
URI est utilise, faisant rfrence la pice jointe.
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
14
Le protocole SOAP (5/5)
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<ns1:echoStringResponse
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:ns1="http://soapinterop.org/">
<return xsi:type="xsd:string">Hello!</return>
</ns1:echoStringResponse>
</soapenv:Body>
</soapenv:Envelope>
Les messages prcdents prsentaient SOAP sans lutilisation des espaces de
noms, obligatoires daprs les spcifications du protocole.
xsi correspond au namespace des types de donnes connus ;
xsd correspond au namespace du schema du document ;
soapenv correspond au namespace de lenveloppe (utilis pour la gestion de la
version SOAP).
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
15
La couche de transport (1/6)
Comme nous lavons vu prcdemment, la dfinition ne dfinit pas une couche
de transport particulire. Le protocole SOAP quant lui nest pas dpendant
dun transport particulier (dans sa version 1.0 il ne pouvait circuler que sur HTTP ;
cela a t corrig dans la version 1.1).
Actuellement, deux couches de transport sont frquemment utilises (HTTP tant
le plus courant) :
HTTP, lors dappels synchrones ;
SMTP, lors dappels asynchrones.
Les spcifications de SOAP ne prcisant pas de protocole particulier, on peut trs
bien imaginer invoquer des services web grce au protocole FTP par exemple
Le protocole HTTP (HyperText Transfert Protocol) est lun des protocoles les
plus utiliss sur Internet. La plupart des clients web (IE, ) lutilisent pour
communiquer avec un serveur.
Ce protocole dfinit le format des requtes quun client peut envoyer ainsi que les
rsultats quil peut attendre.
Chaque requte contient une URL qui contient lidentifiant dun objet demand par
le client (ex.: pages HTML, images, ).
Ce protocole est dfini par le W3C et est prsent dans une RFC (Request for
Comment) : ftp://ftp.isi.edu/in-notes/rfc2616.txt.
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
16
La couche de transport (2/6) : HTTP
Exemple : un navigateur web souhaite obtenir la page par dfaut du site
www.google.fr
Client HTTP
(Internet Explorer)
Serveur Web
(Apache)
Ouverture dune socket sur le port 80 (port par dfaut)
GET / HTTP/1.0
HTTP/1.0 200 OK
Content-Length: 3403
Server: GWS/2.0
Date: Mon, 14 Oct 2002 06:31:35 GMT
Content-Type: text/html
<html><head><meta http-equiv="content-type" content="text/html; charset=ISO-8859-
1"><title>Google</title><style>
Dans le cas o toutes les requtes HTTP doivent transiter par un serveur de cache (proxy HTTP),
il faut ouvrir les connexions sur ce proxy (et non sur le serveur cibl) puis demander lURL
entire.
Ex. : si un client, souhaite obtenir la page www.google.fr en passant par proxy.monintranet
1. Ouverture de la socket (en TCP) sur le port 3128 (port par dfaut) de proxy.monintranet ;
2. Envoi de la requte : GET http://www.google.fr HTTP/1.0
3. Le proxy se connecte son tour google.fr ;
4. Une fois que le proxy a obtenu le rsultat, il rpond au client.
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
17
Quand un client envoie une requte, il lenvoie grce une mthode (GET, POST ou HEAD), suivie dune
URI (Uniform Ressource Identifier) qui identifie la ressource demande. Aprs cette URI se trouve la version
du protocole HTTP (1.0 ou 1.1) ;
Dans les lignes suivantes se trouvent les enttes qui prcisent par exemple quels sont les documents
accepts par client, de quel type de client il sagit,
Aprs les enttes se trouve le corps de la requte, rempli seulement lorsque la mthode POST est utilise.
Permet de supprimer une ressource. DELETE
Permet dajouter une ressource. PUT
Permet au client denvoyer des donnes dans le corps de la requte.
Utile pour envoyer des formulaires, des documents, poster des messages dans les
newsgroups Cette mthode est celle qui convient le mieux SOAP
POST
Comme GET, mais aucune information ne se trouve dans le corps du rsultat.
Notamment utilis pour voir si un document a t mis jour.
HEAD
Utilis pour demander un document : GET index.html
Le corps dune telle requte est toujours vide.
Permet galement de passer des paramtres au serveur, en les collant lURL :
GET index.jsp?userLogin=toto&userPasswd=kkju
Comme rsultat, GET renvoie dabord les enttes, puis le contenu du document
GET
Les mthodes
Dautre mthodes existent : LINK, UNLINK, OPTIONS, TRACE mais sont rarement utilises ;
La rponse du serveur contient le statut de la rponse, les enttes puis le corps de la rponse (par exemple
le contenu dun document HTML ;
Diffrents statuts existent. Les principaux sont : 200 (ok), 400 (mauvaise requte), 403 (client non
autoris), 404 (document inexistant), 500 (erreur dexcution sur le serveur).
La couche de transport (3/6) : HTTP
Utilises dans les architectures REST
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
18
Rsum:
Format dune requte HTTP:
Commande
En-ttes
[Ligne vide ]
Corps
La couche de transport (4/6) : HTTP
http://fr.wikipedia.org/wiki/HTTP
Codes de retour: http://fr.wikipedia.org/wiki/Liste_des_codes_HTTP
Version actuelle: 1.1
Format dune rponse HTTP:
Status
En-ttes de rponse
[Ligne vide ]
Corps de rponse
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
19
La couche de transport (5/6) : SMTP
SMTP (Simple Mail Transfer Protocol) est le principal protocole utilis sur
Internet pour faire transiter les emails entre deux htes (une passerelle peut
galement tre utilise).
SMTP utilise TCP comme couche de transport et le port 25 par dfaut.
Exemple de lutilisation du protocole SMTP pour lenvoi dun mail sur
wanadoo.fr :
- La premire tape est louverture dune connexion (socket) sur le port 25 de
smtp.wanadoo.fr.
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
20
Exemple denvoi dun message SOAP au dessus de HTTP
Le message ne contient aucune information le liant la couche de transport.
Concernant le protocole HTTP, lajout dun attribut SOAPAction:uneURI permet au
destinataire (le serveur HTTP) de savoir quil reoit une requte SOAP. La valeur
est une uri qui nest pas vrifie.
Pour un envoi via HTTP:
ouverture dune socket sur le port du serveur (80 par dfaut) ;
puis :
POST /axis/services/echo HTTP/1.0
Content-Type: text/xml; charset=utf-8
User-Agent: Axis/1.0
Host: 192.168.0.1:8080
Cache-Control: no-cache
Pragma: no-cache
SOAPAction: http://tempuri.org/echo
Content-Length: 453
puis est envoye la requte.
La couche de transport (6/6)
Obligatoire pour requte
SOAP sur HTTP
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
21
RPC (1/2)
Un RPC (Remote Procedure Call), est un mcanisme permettant lappel local
dune mthode distante : un client possde une copie (un stub) dun objet
distant sur lequel il appelle des mthodes. Ct serveur, le skeleton est un
objet sinterfaant avec le vrai objet appel.
Un stub est un proxy cot client.
Diffrents langages de RPC existent, dont :
Corba ;
DCOM ;
RMI ;
SunRPC;
DCE (Distributed Computing Environment).
Un systme distribu permet de rpartir des sous-ensembles dune architecture
dans diffrents serveurs.
Lavantage dun RPC est quil ny a (presque!) pas de diffrence entre un appel
local et un appel distant. Il ny a donc plus se soucier de la couche rseau, qui
est gre par le RPC.
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
22
Code de
lappelant STUB
Rseau
Rseau
Protocole
rseau
Client
Serveur
Protocole
rseau SKELETON
Code du
serveur
Service RPC Service RPC
RPC (2/2)
Une architecture distribue
Chaque RPC a son protocole de communication:
IIOP pour Corba ;
ORPC pour DCOM ;
JRMP pour RMI ;
et HTTP, SMTP, pour SOAP !
On constate des diffrences entre SOAP et les autres protocoles :
SOAP est le seul protocole qui ne fait pas circuler de donnes binaires. En
plus dtre lisible, cela permet le dbugage ;
SOAP peut circuler sur HTTP, ce qui lui permet de passer les
firewalls dans leurs configurations standards. Cest l un de ses
grands avantages.
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
23
A ses dbuts, SOAP tait destin tre un protocole fournissant un mcanisme
de RPC, inter-oprable, car utilisant XML & HTTP (il est maintenant entre autre
un protocole de communication entre services web par changes de messages
XML).
Lors dun appel RPC, un message SOAP doit contenir :
ladresse du destinataire du message ;
le nom de la mthode excuter ;
les paramtres passer la mthode.
En devenant un RPC, les services web en SOAP peuvent tre vus comme un point
dentre dans les applications lourdes : par exemple, un service web peut
permettre une connexion entre un client sur Internet et une application base
dEJB.
De nombreuses API (Application Programmer Interface) permettent de crer des
stubs de mthodes exposes dans des services web.
Nous tudierons en TP lAPI Axis dApache ( un SOAP engine ).
RPC avec SOAP
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
24
WSDL (1/3)
WSDL (Web Service Description Langage), est un langage de description de
services web en XML.
Il dcrit :
Les informations sur les fonctions publiques du service web ;
Les types de donnes utiliss durant lchange de messages ;
Les diffrents protocoles aux travers desquels le service est accessible ; et
comment y accder ;
Une adresse permettant de localiser le service web.
A noter : WSDL pourrait dcrire nimporte quel protocole de messagerie bas sur
XML.
A noter (2) : les documents WSDL ne sont jamais gnrs par des dveloppeurs,
mais le sont grce des outils qui automatisent la tche (par exemple, il existe
des outils qui prennent une classe Java et qui crent le WSDL correspondant).
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
25
WSDL (2/3)
Ci-dessous le document WSDL dcrivant un WS proposant une mthode daddition.
Dcrit les messages
qui circulent
Dfinit comment est disponible
(SOAP) la mthode et quelle adresse
Abstraction dcrivant une opration
Protocole daccs et format des
messages
<wsdl:definitions targetNamespace="http://192.168.0.12:8080/axis/SimpleWS.jws"/>
<wsdl:message name="addRequest">
<wsdl:part name="i1" type="xsd:int"/>
<wsdl:part name="i2" type="xsd:int"/>
</wsdl:message>
<wsdl:message name="addResponse">
<wsdl:part name="addReturn" type="xsd:int"/>
</wsdl:message>
<wsdl:portType name="SimpleWS">
<wsdl:operation name="add" parameterOrder="i1 i2">
<wsdl:input message="impl:addRequest" name="addRequest"/>
<wsdl:output message="impl:addResponse" name="addResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="SimpleWSSoapBinding" type="impl:SimpleWS">
<wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="add">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="addRequest">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://192.168.0.12:8080/axis/SimpleWS.jws" use="encoded"/>
</wsdl:input>
<wsdl:output name="addResponse">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://192.168.0.12:8080/axis/SimpleWS.jws" use="encoded"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="SimpleWSService">
<wsdl:port binding="impl:SimpleWSSoapBinding" name="SimpleWS">
<wsdlsoap:address location="http://192.168.0.12:8080/axis/SimpleWS.jws"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
26
WSDL (3/4)
Sur le slide prcdent, quelques lments nont pas t prsents. Reprenons llment
<port> : il dfinit un point de terminaison (adresse internet plus liaison).
<wsdl:service name="SimpleWSService">
<wsdl:port binding="impl:SimpleWSSoapBinding" name="SimpleWS">
<wsdlsoap:address location="http://192.168.0.12:8080/axis/SimpleWS.jws"/>
</wsdl:port>
</wsdl:service>
Il est noter que llment <portType> peut contenir plusieurs oprations.
A lexemple prcdent manque llment <type> qui permet de dfinir des types
complexes (dans lexemple ci-dessous, la valeur renvoye est une chane de caractres).
Remarque : dans la dfinition des messages, nous navons aucune information sur le
protocole de transport. Cela reste dans la logique des web services.
Le logiciel XMLSpy donne une bonne vue (graphique) dun document WSDL (ici celui du
slide prcdent).
Une version complte dvaluation (30 jours) est disponible sur http://www.altova.com.
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
27
WSDL (4/4)
WSDL : rsum des lments dun document
Operation : une action particulire supporte par le service web dcrit. En
faisant lanalogie avec Java, on peut comparer une Operation une
(mthode dune) Interface ;
Message : dfinition des types de donnes utilises lors de linvocation (et
de la rponse) dune opration ;
PortType : un ensemble (1..n) doprations ;
Binding : lien entre un PortType et un protocole daccs ;
Port : dfinit un point daccs (cad une URL par exemple) pour un binding ;
Service : contient une collection de ports.
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
28
UDDI (1/2)
UDDI (Universal Description, Discovery and Integration) est un standard
ayant pour but la cration dun annuaire distribu de services web.
Cet annuaire contient :
les pages blanches : informations gnrales sur une socit (nom,
description, adresse) ;
les pages jaunes : classement des types de services ;
les pages vertes ou roses : informations sur les modes dexploitation du
service.
LUDDI Business Registry est une implmentation complte des spcifications
UDDI. Lance en mai 2001 par Microsoft et IBM, elle permet maintenant
quiconque dy chercher des informations et aux socits de senregistrer.
UDDI repose sur une architecture distribue comparable celle des
serveurs DNS.
En guise dexemple :
http://uddi.microsoft.com ;
http://www.ibm.com/services/uddi.
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
29
UDDI (2/2)
LAPI UDDI propose deux fonctionnalits principales :
la recherche de services (envoi de requtes).
la publication de services dans un annuaire UDDI ;
Les clients UDDI interrogent les serveurs (les sites oprateurs) UDDI en
envoyant des requtes formates en SOAP (sur HTTP avec la mthode
POST).
______________
Le slide suivant prsente un scnario complet. Les tapes sont :
1. Publication dun service web par une socit ;
2. Recherche dun service web ;
3. Dcouverte dun service web ;
4. Consommation dun service web.
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
30
UDDI + WSDL + SOAP : vue densemble
Serveur
UDDI
Entreprise
A
WS
Lentreprise A
dveloppe et dploie
un service web (WS)
1
Lentreprise A
publie WS
2
Le serveur UDDI renvoie ladresse
de WS (plus dautres info comme la
description du service. cf plus loin)
4
Entreprise
B
Lentreprise B, la recherche dun service
du type WS, envoie une demande de
recherche au serveur UDDI
3
Lentreprise B
invoque WS
5
Lentreprise A
rpond B
6
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
31
Conclusions de la premire partie
Trop souvent on lit web services = SOAP . Cest faux !
Web service = XML + (HTTP|SMTP|FTP|)
Les services web permettent de mettre en place des services faiblement
coupls (loosely coupled), rendant la communication entre deux plate-
formes incompatibles possible.
SOAP est indpendant de la couche de transport ;
Cependant, SOAP est devenu de facto le standard des services web ;
SOAP peut faire des RPC, mais pas que des RPC ;
WSDL sert dcrire des services web ;
UDDI est un annuaire qui rpertorie les socits et les services web
quelles proposent ; UDDI est bas sur une architecture distribue.
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
32
Les offres du march
Le march des services web est trs fourni : la plupart des diteurs
proposent des kits de dveloppement.
Le premier proposer les services web au cur de son architecture a t
Microsoft, avec la plate-forme .NET.
Le monde Java a bien ragi bien que les spcifications J2EE de lpoque
(version 1.3) ne parlaient aucunement de services web. Ils y ont t introduits
dans la version 1.4.
Tous les diteurs du monde Java proposent leur kit pour les services web :
Oracle pour 10gAS ;
BEA pour WebLogic ;
IBM pour WebSphere;
Sun pour Sun Java System Application Server ;

De nombreux projets Open Source existent galement, comme par exemple
lAPI Axis utilise en TP. Les IDE open source intgrent eux aussi ces
technologies : Eclipse, NetBeans...
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
33
La scurit des services web (1/4)
A la vue du contenu des messages issus des services web, il est
important de disposer de mcanisme de scurit assurant
lauthentification, lintgrit et lauthenticit des donnes.
La scurit dun service web peut se faire deux niveaux :
applicatif : sur la couche SOAP par exemple ;
au niveau rseau.
Lavantage de pouvoir passer les firewalls donnent aux hackers de nouveaux
points dentre dans le systme dinformation de lentreprise ; ce qui
peut leur permettre par exemple de lancer une attaque de dni de service sur le
serveur.
De plus, les messages tant cods en XML, les mthodes et procdures
proposes par une entreprise transitent en clair sur le rseau, ce qui
constitue une indication pour les pirates.
A la vue de larchitecture des services web, il apparat que la problmatique de
scurisation est la mme que celle dun site web car les donnes transitent
(dans la plupart des cas) sur HTTP.
On peut donc dans un premier temps mettre les mmes solutions de scurit
que celles utilises pour les sites web, savoir le protocole SSL.
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
34
Seuls le client
et
le serveur
peuvent
dchiffrer ces
messages
La scurit des services web (2/4)
Le protocole SSL a t dvelopp par Netscape. Permettant le cryptage des
donnes, il est trs utilis sur Internet pour faire transiter des informations
sensibles (par exemple un numro de carte de crdit).
Il est noter que lorganisme de normalisation IETF la renomm TLS.
Le protocole HTTP sutilisant avec le protocole SSL devient HTTPS. Le port par
dfaut nest plus 80 mais 443.
SSL est bas sur la cryptographie. Il fonctionne grce un systme de cls
publiques et de cls prives.
1 - Le client initialise une connexion (non crypte, port 443 par dfaut)
2- Le serveur renvoie une cl de cryptage (sa cl publique).
Cette requte nest pas crypte.
3 Le client gnre une chane de 46 octets et la crypte avec la cl
publique du serveur. Seul le serveur (possdant la cl prive) peut
dcrypter ce message.
4 - Le serveur dcrypte la chane de 46 octets qui est utilise pour crer
des cls de cryptage utilises pour le reste de la session
5 - Les donnes transitant sont cryptes
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
35
La scurit des services web (3/4)
SSL permet grce aux cls publiques et prives dencoder les messages, mais ne
permet pas didentifier le serveur.
En effet, au moment de linitialisation du protocole SSL (tape 2) sur le slide
prcdent, nimporte quelle serveur pirate peut se faire passer pour le serveur
interrog par le client et renvoyer une cl publique.
Pour palier ce problme, les certificats ont t mis en place.
Un certificat est un objet verrouill qui contient lidentit dun serveur ainsi que
sa cl publique. Il est encrypt avec la cl prive de lorganisme qui le dlivre
(comme Verisign par exemple).
Quand un client se connecte un site, il demande lorganisme des certificats de
vrifier lidentit du serveur (grce au certificat envoy par le serveur).
Cela permet davoir avec HTTPS lauthentification ainsi que le cryptage
des donnes.
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
36
La scurit des services web (4/4)
La scurit des services web peut galement se faire sur des couches plus
basses (couches rseaux). Grce des rgles dfinies sur des firewalls, on peut
par exemple autoriser laccs un service web seulement des clients ayant des
adresses IP connues.
Certains constructeurs/diteurs de firewalls ajoutent des rgles de filtrage de
messages SOAP, qui peuvent grce des enttes SOAP vrifier quun
consommateur dun service est autoris y accder.
Des protocoles spcifiques sont en cours dlaboration. Microsoft a propos au
W3C le protocole WS-Security qui permet lidentification des utilisateurs,
lintgrit des messages SOAP ainsi que le chiffrement des donnes.
WS-Security est bas sur XML Signature (authenticit de lutilisateur) et de
XML Encryption (encodage des donnes).
Un exemple avec le protocole WS-Security
(source : http://msdn.microsoft.com)
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
37
AXIS
Axis est une API Java (Open Source) servant crer et consommer des
services web;
AXIS = Apache eXtensible Interaction System
Site web : http://ws.apache.org/axis ;
Supporte SOAP 1.1 et 1.2 partiellement ;
Pas de support dUDDI ;
Sutilise avec nimporte quel serveur dapplication J2EE (propose mme un
serveur HTTP pour fonctionner en mode stand-alone) ;
Propose deux outils WSDL2Java et Java2WSDL permettant le mapping entre
des services web et des classes Java, et vice-versa ;
Dispose dun outil de monitoring de requtes ;
Propose un mchanisme ultra-simple de cration de services web ;
AXIS est lAPI que nous allons utiliser pendant les TPs.
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
38
AXIS : invocation dynamique dun service web
AXIS implmente la spcification JAX-RPC
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
39
AXIS : utilisation de WSDL2Java
WSDL2Java permet de reprsenter un service ct client. A la diffrence de
linvocation dynamique, cela permet de :
passer les arguments la place de tableaux dobjets (cf exemple prcdent) ;
avoir en retour lobjet attendu et non un objet Object caster
WSDL2Java gnre :
port-nameService.java <service>
nom-portBindingStub.java <binding>
nom-port.java <porttype>
nom-type.java <type>
Classe gnre Nom de la balise XML dans le
document WSDL
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
40
AXIS : utilisation de WSDL2Java
Relations entre les fichiers gnrs par WSDL2Java et squence dutilisation :
source : http://www.ociweb.com/javasig/knowledgebase/2002Sep/Axis.pdf
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
41
Un peu de scurit dans la pratique (1/2)
Quelles sont les attaques auxquelles un service web est expos :
Dni de service ;
Interception et manipulation des messages ;
Requte du client falsifie ;
Rponse du serveur falsifie ;
Tentative de lectures/critures sur le systme de fichiers du serveur.
-> Ces attaques ne sont pas spcifiques aux services web mais aux serveurs web !
A ces attaques, se rajoutent les attaques propres aux donnes XML :
Envois de trs gros documents XML (assimile un dni de service) ;
Dclarations dentits rcursives dans les headers XML ;
Dclarations dentits pointant sur un fichier local.
source : documentation dAxis
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
42
Un peu de scurit dans la pratique (2/2)
Quelques options pour scuriser un service web :
Authentifier les clients (avec HTTPS par exemple) ;
Ecrire du code sr ;
Recompiler Axis avec le strict ncessaire lexcution du service ;
Renommer les outils exposs afin que personne ne sache que vous utilisez
Axis (ou une autre API) ;
Dsactiver la gnration automatique des fichiers WSDL ;
Filtrer les accs via les adresses IP ;
Logger les accs ;
Lancer le serveur web et Axis avec des droits rduits ;
...
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
43
La mobilit et les services web (1/2)
De nombreuses solutions permettent dinvoquer des services web depuis des
clients mobiles (PDA PocketPC/Linux, tlphones J2ME).
Avec un OS Microsoft :
.NET CF : la version pour terminaux mobiles de lenvironnement dexcution
(runtime) de .NET intgre les API pour invoquer des services web ;
PocketSOAP : client open source SOAP, disponible sous la forme dun objet
COM (galement disponible pour win32) ;
En faisant du Java :
J2ME Web Service API (JSR 172) :
http://developers.sun.com/techtopics/mobility/apis/articles/wsa ;
Oracle J2ME Web Service : cf slide suivant.
PS : ce nest pas une liste exhaustive !
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
44
La mobilit et les services web (2/2)
Service web Service web Proxy Proxy
Lapproche dOracle pour la consommation de
services web depuis des applications J2ME :
exemple dappel dun service web Addition
SOAP/HTTP
add 3 4
7
Un proxy se charge de la communication avec le service web afin den cacher
la complexit au client J2ME. Ce proxy doit tre gnr pendant le
dveloppement de lapplication (depuis JDeveloper, IDE dOracle) ;
Le terminal mobile nenvoie donc que la chane de caractres add 3 4 , ce
qui lui vite de faire du traitement XML (coteux).
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
45
Architectures Orientes Services (1/4)
SOA = Services Oriented Architecture
Source : http://fr.wikipedia.org/wiki/Service_Oriented_Architecture
Larchitecture oriente service est un modle dinteraction applicative qui met en
uvre des services (composants logiciels) :
avec une forte cohrence interne (par l'utilisation d'un format d'change pivot, le plus
souvent XML)
et des couplages externes lches (par l'utilisation de couche d'interface
introprable, le plus souvent un Web services).
SOA est un concept, les services web en sont une utilisation.
Description dune architecture SOA :
Annuaire de services : rfrence lensemble des services disponibles au sein du
systme dinformation ;
Bus de services : le bus a un rle de mdiateur (middleware) entre le consommateur
et le producteur du service, il permet ainsi de raliser le couplage lche ;
Service : cf. slide suivant.
-> SOA dfinit comment allier dveloppement orient objet et programmation distribue.
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
46
Architectures Orientes Services (2/4)
SOA, dfinitions :
Fournisseur de services (service provider) : entit qui fournit et excute
le service (cad le serveur) ;
Consommateur de services (service consumer) : entit qui consomme le
service (cad le client) ;
Message (message): entres et sorties du service (dans les services web:
SOAP) ;
Contrat de service (service contract) : document qui dfinit comment le
fournisseur et le consommateur inter-agissent (dans les services web:
WSDL) ;
Annuaire (service registry) : un annuaire dans lequel se trouvent les
services (dans les services web: UDDI).
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
47
Architectures Orientes Services (3/4)
Source : http://fr.wikipedia.org/wiki/Service_Oriented_Architecture
Le service est un composant clef de lArchitecture Oriente Services. Il consiste en une
fonction ou fonctionnalit bien dfinie.
Une architecture oriente services consiste essentiellement en une collection de services
qui interagissent et communiquent entre eux. Cette communication peut consister en un
simple retour de donnes ou en une activit (coordination de plusieurs services).
Un service est une entit de traitements qui respecte les caractristiques suivantes :
Grande maille (coarse grained) : les oprations proposes par un service encapsulent
plusieurs fonctions et oprent sur un primtre de donnes large au contraire de la notion
de composant technique ;
Interface : un service peut implmenter plusieurs interfaces et aussi plusieurs services
peuvent implmenter une interface commune ;
Localisable : avant dappeler (bind, invoke) un service, il faudra le rechercher (find).
Instance unique : la diffrence des composants qui sont instancis la demande et
peuvent avoir plusieurs instances en mme temps ; un service est unique. Il correspond
au design pattern Singleton ;
Faible couplage (loosely-coupled) : les services sont connects aux clients et autres
services via des standards. Ces standards assurent la rduction de dpendance et du
dcouplage . Ces standards sont des documents XML comme dans les web services ;
Synchrone ou Asynchrone.
W
E
B
S
E
R
V
I
C
E
S
W
E
B
S
E
R
V
I
C
E
S
48
Architectures Orientes Services (4/4)
Source : http://fr.wikipedia.org/wiki/Service_Oriented_Architecture
Parmi les diffrentes couches de normes et protocoles qui permettent de btir des
architectures orientes services, on relve :
la gestion d'un annuaire de services (quels sont les services mis disposition et par qui)
avec : UDDI (Universal Description Discovery and Integration) normalis par l'OASIS ;
la description des interfaces des services (quelles sont les donnes ncessaires
l'excution du service, que fournit-il en retour, ...) avec : WSDL (Web Services Description
Language) recommand par le W3C ;
l'invocation (ou l'appel) du service (la requte transmise au service) avec : SOAP (Simple
Object Access Protocol) recommand par le W3C ;
le format des donnes changes avec : XML (eXtensible Markup Language) recommand
par le W3C ;
le transport des donnes avec les protocoles internet : HTTP et TCP/IP qui sont des
normes RFC ;
la gestion de la scurit avec : SSL (Secure Sockets Layer), XML Signature, XML
Encryption, SAML (Security Assertion Markup Language) ou encore XKMS (XML Key
Management Specification, qui gre les infrastructures cl publique ou PKI) ;
l'orchestration (on parle galement de chorgraphie) des services pour constituer des
processus mtier avec : BPEL4WS (Business Process Execution Language For Web Services) qui
regroupe WSFL (Web Services Flow Language) d'IBM et XLang de Microsoft, ou encore WSCI
(Web Services Choregraphy Interface) ;
la gestion transactionnelle : WS-Transaction d'IBM, XAML (Transaction Authority Markup
Language) ou encore BTP (Business Transaction Protocol).