Le document traite des web services, une architecture basée sur des standards internet permettant la communication entre applications indépendamment de leurs technologies. Il explique les technologies clés comme SOAP, WSDL et UDDI, ainsi que leur rôle dans l'interopérabilité et la description des services. Il aborde également l'importance de la sécurité dans les communications entre clients et serveurs via des normes comme WS-Security.

1. Présentation générale
des Web Services

2. Vue Globale
Type d'architecture reposant sur les standards de l'Internet
Alternative aux architectures classiques :
Client/serveur
n/tiers
Orientée services permettant à des applications de
communiquer sans préoccupation des technologies
d'implantations utilisées de part et d'autre
Priorité : Interopérabilité
Née fin 90 (Microsoft, IBM, SAP)
Basée sur les technologies XML

3. Architecture web-services
Web-services : logiciel qui interagit avec d'autres au moyen
de protocoles & langages universels (http, xml …)
Deux formes de services-web : SOAP & XML-RPC
Présentent 2 caractéristiques :
Enregistrement (facultatif) auprès d'un service de
recherche (UDDI)
Interface publique avec laquelle le client invoque le service
Web (WSDL)

4. Architecture web-services
UDDI : Universal Desciption, Discovery and Integration peut
être vu comme les pages blanches (ou jaunes) des services-
web.
C'est un annuaire permettant à des fournisseurs de présenter
leurs services à des 'clients'.
WSDL : Web Service Description Language est un langage
reposant sur XML dont on se sert pour décrire les services-
web.
Il est indispensable à UDDI pour permettre aux clients de trouver
les méthodes leur permettant d'invoquer les services web.
SOAP : Simple Object Access Protocol est un protocole basé
sur XML et qui définit les mécanismes d'échanges
d'information entre les clients et les fournisseurs de service-
web.
Les messages SOAP sont susceptibles d'être transportés en HTTP,
SMTP, FTP...
XML-RPC : protocole RPC (Remote Procedure Call) basé sur
XML. Permet donc l'invocation de procédure distante sur
internet.

5. Interopérabilité
Capacité des services Web à faire converser des applications &
des composants hétérogènes
Exemple :
Réalisation d'un service Web permettant de donner le
cours d'une action en bourse, fonctionnant sous Linux en
Java
Et l'interroger depuis une page Web Asp.net en même
temps que depuis une application PERL ou PHP

6. Fonctionnement - SOAP
Un protocole standard de communication : SOAP (Simple
Object Access Protocol)
Ecrit en XML
Standardisé par le W3C
Présentation :
Enveloppe pouvant contenir des données ou des pièces
jointes
Circule sur le protocole HTTP
Permet d'effectuer des appels à des méthodes distantes

7. Fonctionnement - XSD
Un format standard de représentation des données : XSD
(schéma XML)
Standardisé par le W3C
Assure la compatibilité des données, même sur des plates-
formes différentes

8. Fonctionnement - WSDL
Un langage de description standard : WSDL (Web Service
Description Language)
Interface présentée aux utilisateurs
Décrit comment utiliser le service et interagir avec lui
Description XML, standardisée W3C
Accessible depuis une URL distante

9. Fonctionnement - WSDL
WSDL définit :
Les Types : un système de types applicable à des
données. Utilisation de XML Schema pour définir les types
de données.
Le Message : décrit les données échangées entre services
web. Peut-être comparé aux paramètres d'un appel de
procédure.
Le Type de Port (portType): définit les opérations du
service web et les messages impliqués (de type input,
output ou fault). Peut être comparé à une interface Java.

10. Fonctionnement - WSDL
WSDL définit :
La Liaison (binding) : définit le format des messages (par
exemple soap:body spécifie que le le message considéré
sera transmis dans la partie body du message soap) et le
protocole utilisé par chaque type de port. C'est
l'implémentation de l'interface.
Le Port : un point de terminaison identifié de manière
unique par la combinaison d'une adresse internet et d'une
liaison
Un Service Web (service) : associe des liaisons à des
process concrets de mise en oeuvre des opérations qu'elles
décrivent (typiquement une URL dans le cas d'une liaison
mettant en oeuvre SOAP sur HTTP)

11. Fonctionnement - UDDI
Un mécanisme de découverte : UDDI (Universal Description
Discovery and Integration)
Mécanisme permettant aux utilisateurs de découvrir quels
sont les services qui correspondent à leurs besoins
Ces descriptions de services sont centralisées sur un serveur
public ou privé
Semblable à un annuaire

12. Fonctionnement - Couches
Toutes ces technologies sont disposées en couches et
constitue l'architecture services Web

13. Exemple : Java & les web-services
Java dispose de nombreuses API utiles aux services-web :
API pour le traitement XML : JAXP
API pour RPC-XML : JAX-RPC
API pour l'échange de données XML : JAXM
API pour les annuaires XML : JAXR
Mais il existe surtout des librairies prêtes à l'emploi simplifiant
grandement la conception et la consommation de services
web :
AXIS : c'est une implémentation Java de SOAP offerte par
l'Apache Software Foundation qui couvre aussi bien la conception
que la consommation des services-web.
Apache propose aussi une implémentation de XML-RPC
Apache, propose un framework dédié à l'invocation des services-
web : WSIF (Web Service Invocation Framework).

14. Fonctionnement - Exemple
service StockQuoteService :
Il retourne le cours d'une action en bourse, à partir de son
code de cotation

15. Fonctionnement - Exemple
Un utilisateur désire consulter le cours de l'action IBM au moyen d'un
service Web.
1. Pour cela, il interroge un serveur UDDI dont
il connaît l'adresse , afin de savoir quels sont
les services disponibles correspondant à ses
besoins.
Le serveur lui retourne la liste des possibilités
parmi lesquelles il en sélectionne une.
À ce stade, l'utilisateur ne possède qu'une URL
pointant vers le service sélectionné.

16. Fonctionnement - Exemple
2. Il récupère ensuite une interface WSDL , accessible depuis l'URL, qui lui permet de
savoir comment utiliser le service.
À partir de cette interface, l'utilisateur va automatiquement générer les stubs du
service.
Stubs :objets locaux disposant des mêmes fonctions que le service distant et qui
permettront à l'utilisateur d'accéder au service distant en toute transparence.
Les stubs sont créés grâce à un outil et peuvent être générés dans un grand nombre
de langages de programmation différents

17. Fonctionnement - Exemple
3. À cet instant, le stub va représenter l'appel de méthode distante sous la forme
d'une requête SOAP dans laquelle seront inclus les paramètres fournis par l'utilisateur.
Ces paramètres seront empaquetés grâce à la méthode standard de représentation
des données, ce qui permet d'assurer la compatibilité inter machines (PC, Mac, etc.).
Cette requête est ensuite émise vers l'URL désignant le service Web.

18. Fonctionnement - Exemple
4. Sur la machine hébergeant le service, la requête est réceptionnée puis ouverte par
un Tie.
5. Le service Web, une fois la requête comprise, interroge sa base de données et
récupère le cours de l'action IBM .
6. Une réponse SOAP est construite puis est émise en direction de l'expéditeur initial.
Le stub réceptionne ensuite la réponse, l'ouvre et en extrait le cours de
l'action IBM qu'il retourne finalement à l'utilisateur

19. Sécurité
Les services Web disposent d'une norme standard de sécurité qui
permet d’assurer la confidentialité des opérations : WS-Security.
Confidentialité (la communication est privée) : assurée par
l’utilisation d’une connexion SSL pour le transfert des requêtes SOAP
entre le client, d’éventuels intermédiaires et le serveur final.
Intégrité (la requête n’est pas modifiée) : elle est assurée soit par
l’utilisation d’une connexion SSL ou par l’encodage de la requête à
l’aide d’un certificat X.509.
Authentification (le message provient bien de la personne qui le
prétend) : elle est assurée par l’ajout d’un mot de passe ou d’un
certificat X.509 dans l’entête de la requête.
Autorisation (la personne émettrice de la requête peut accéder aux
données) : cet aspect de la sécurité est délégué au serveur recevant
la requête.