1 web service said najah. 2 deuxième partie : technologies des services web

1

Web service

Said najah

2

Deuxième partie : Technologies des services Web

3

Les services web

Définition du W3C Selon la définition du W3C (World Wide Web Consortium), un Web service (ou service Web) est une application appelable via Internet - par une autre application d’un autre site Internet - permettant l’échange de données (de manière textuelle) afin que l’application appelante puisse intégrer le résultat de l’échange à ses propres analyses. Les requêtes et les réponses sont soumises à des standards et normalisées à chacun de leurs échanges.

4

Quelques définitions Les services web permettent l’invocation de fonctions distantes, présentes sur des systèmes distribués et hétérogènes, grâce au protocole HTTP et à XML.

« les services web sont des applications auto-descriptives, modulaires et faiblement couplées qui fournissent un modèle de programmation et de déploiement d’applications, basé sur des normes, et s’exécutant au travers de l’infrastructure web » Les Web Services, H.Kadima, Dunod 2003

Un service web est une application conçue pour assurer une interopérabilité entre machines au travers d’un réseau.

Les services web

5

Un service web est une interface qui décrit un ensemble d’opérations accessibles via un réseau par des messages XML standards.

« Un service web est un composant applicatif mis à la disposition sur un réseau et disposant de méthodes que l’on peut invoquer à distance via l’emploi de protocoles standards. Les services Web présentent l’avantage d’être faiblement couplés, indépendants des plateformes et réutilisables » Livre Blanc : Les Services Web, S.Bardet, 2003

Les services web permettent l'appel d'une méthode d'un objet distant en utilisant un protocole web pour le transport (http en général) et XML pour formater les échanges.

Les services web

6

Les services web fonctionnent sur le principe du client prestataire : un client appelle les prestataires web le prestataire traite la demande et renvoie le résultat au client le client utilise le résultat

Les services web sont des composants distribués qui offrent des fonctionnalités aux applications au travers du réseau en utilisant des standards ouverts.

Ils peuvent donc être utilisés par des applications écrites dans différents langages et exécutées dans différentes plateformes sur différents systèmes.

Les services web

7

Les services Web utilisent une architecture distribuée composée de plusieurs ordinateurs et/ou systèmes différents qui communiquent sur le réseau.

Ils mettent en œuvre un ensemble de normes et standards ouverts qui permettent

aux développeurs d'implémenter des applications distribuées internes ou externes en utilisant des outils différents fournis par différents fournisseurs.

Il existe plusieurs technologies derrière le terme services web : Les services web de type Representational state transfer (REST) Les services web de type SOAP

Les services web

8

Les Web services sont nés de l’effort de plusieurs organisations qui ont partagé un intérêt commun en développant et en maintenant "un marché électronique".

Les organisations souhaitaient pouvoir communiquer plus simplement et sans avoir à se concerter sur chacune de leur transaction pour pouvoir interpréter leurs différentes données. Elles souhaitaient supprimer l’isolement de leur système informatique avec les autres.

Pour répondre à cette nouvelle situation, de nouvelles technologies apparurent telles que CORBA (Common Object Request Broker Architecture) ou la

version qu’en fit Microsoft, le Component Object Model (COM).

Les services web

9

CORBA, est une architecture logicielle, pour le développement de composants. Ces composants, qui sont assemblés pour la construction d’applications complètes, ont la possibilité d’être écrits dans des langages de programmation différents, d’être exécutés dans des processus dissociés, voire d’être déployés sur des machines distinctes.

Les composants CORBA utilisent une approche essentiellement orientée objet (du point de vue d’un langage de programmation, toutes les méthodes sont virtuelles, il n’y a pas de polymorphisme paramétrique, ni méthodes protégées ou privées, ni surcharge d’opérateurs).

Les services web

10

Pour améliorer l’interopérabilité entre les réalisations de service Web, l’organisation WS-I a développé une série de profils pour faire évoluer les futures normes impliquées. L’aspect le plus important des Web Services est qu’ils reposent sur plusieurs standards qui permettent la structuration des architectures. Cette collection de normes et de protocoles est appelée Web Services Protocol Stack .

La collection de normes et de protocoles qui contient : XML et SOAP pour le formatage des données, WSDL pour la description des services Web UDDI pour la recherche des services Web nécessaire au bon fonctionnement des applications.

Les services web

11

Architecture

Les services web

12

1- Le client envoie une requête à l’annuaire de Service pour trouver le service Web dont il a besoin.

2- L’annuaire cherche pour le client, trouve le service Web approprié et renvoie une réponse au client en lui indiquant quel serveur détient ce qu’il recherche.

3- Le client envoie une deuxième requête au serveur pour obtenir le contrat de normalisation de ses données.

4- Le serveur envoie sa réponse sous la forme établie par WSDL en langage XML.

5- Le client peut maintenant rédiger sa requête pour traiter les données dont il besoin.

6- Le serveur fait les calculs nécessaires suite à la requête du client, et renvoie sa réponse sous la même forme normalisée.

Les services web

13

Architecture de baseTrois 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

Les services web

14

Les services web

15

La normalisation actuelle autour des Web Services est cependant une organisation complexe qui va bien au-delà de la simple invocation d’une méthode d’un objet distant.

Différents travaux ont ainsi démarré pour permettre d’établir une véritable infrastructure distribuée, capable de satisfaire l’ensemble des besoins d’une application distribuée, aussi bien en terme de normalisation des échanges qu’en terme de services transverses.

Cette normalisation des services transverses se fait sur trois axes horizontaux

Les services web

16

Couche de transport :

Définition de la structure des messages utilisés par les applications pour se découvrir et dialoguer entre elles.

Cette couche est à l’heure actuelle la seule réellement normalisée et qui ne souffre d’aucune contestation.

Elle s’appuie sur le protocole SOAP pour l’échange des messages et sur le langage WSDL pour la définition du contrat de l’interface.

Les services web

17

Couche de sémantique :

Normalisation des données participant aux échanges selon des critères métier.

Les initiatives de définition de la couche de sémantiques des messages sont nombreuses et n’ont pour le moment pas conduit à une quelconque normalisation.

Deux types d’organisation sont actuellement ouverts, l’une établie selon les différents corps de métier, l’autre suivant une approche plus globale autour de consortium tel que OASIS (initiateur de ebXML) ou RosettaNet.

Les services web

18

Couche de gestion des processus

Standardisation de la gestion des processus métier qui s’étendent sur plusieurs

applications disponibles sur Internet.

L’orchestration de transactions B2B (Business to Business) complexes, fondée sur une architecture normalisée des messages est aussi une tentative qui n’avance pas assez rapidement et sur des standards non murs.

Les services web

19

Cette normalisation des services transverses de fait aussi sur trois axes verticaux :

Service d’annuaire : Standardisation des moyens d’accès à un service à partir d’une requête portant sur le contenu d’un service ou sur un fournisseur.

La première proposition d’annuaire UDDI aurait du apporter une solution définitive. Le constat est qu’il n’en est rien et que la trame, trop globale, du projet ne suffit pas à régler cette problématique d’échanges entre

applications .

Une deuxième proposition d’annuaire, WSInspection, vient concurrencer celle-ci.

Les services web

20

Service de sécurité Normalisation des moyens permettant de couvrir les problématiques d’authentification et de gestion des droits d’accès.

La gestion de la sécurité est actuellement le frein le plus important à la mise en place d’architectures distribuées à base de Web Services.

Il semblerait que la norme XACML (eXtensible Access Control Markup Language) puisse supplanter SAML (Security Assertion Markup Language) et s’imposer à terme comme standard de sécurité.

Les services web

21

Service de transaction

Normalisation des moyens permettant de garantir l’intégrité des transactions longues impliquant plusieurs Web Services.

Le problème reste le même que pour la sécurité.

Les standards ne sont pas tout à fait établis.

La lutte pour l’obtention d’une norme est beaucoup plus ouverte que pour celle de la sécurité, même si BTP (Business Transaction Protocol ) semble plus soutenu actuellement.

Les services web

22

Evolution des middlewares Quelle est la nouveauté dans les web services ? Pourquoi ne pas utiliser les technologies existantes?

Remote Procedure Call Message Oriented Middleware Objets Distribués Database Oriented Middleware

Les services web

23

évolution des middlewares - RPC Remote Procedure Call (RPC) Principe d’appel de procédure type client/serveur s’exécutant sur une

machine distante dans un environnement d’applications distribuées. Un des plus vieux middlewares Fonctionne de manière synchrone Facile à comprendre et à coder Nécessite beaucoup de ressources Complexe à administrer Pas de standards/Implémentation spécifique à un vendeur Ne supporte pas la POO

Les services web

24

Architectures pour les systèmes répartis (RPC, DCOM, RMI et CORBA) :

problèmes d’inter-opérabilité : DCOM spécifique Microsoft RMI spécifique Java

problèmes techniques : RPC technologie vieillissante CORBA technologie extrêmement complexe

Les services web

25

Les services web

26

Les services web

27

Les services web

Troisième vague du e-Business Exemple de Scénario de M2M

28

Exemples de services existants Google (http://www.google.com/apis/) :

accès gratuit mais limité (1000 requêtes par jour après enregistrement) propose trois opérations :

recherche obtention d’une page depuis le cache correction orthographique

Amazon(http://associates.amazon.com/exec/panama/associates/join/developer/resources.html)

accès gratuit mais limité (une requête par seconde après enregistrement) propose recherche et gestion d’un panier d’achats

Les services web

29

Fondations des services Web Les protocoles Internet

Les protocoles Internet

URI, URN, URL, trois sigles qui se rapportent au mécanisme utilisé par le Web pour identifier et/ou localiser une ressource ;

MIME, technologie permettant de véhiculer des objets de toute sorte sur Internet, très importante dans la mesure où de nombreux autres protocoles l’utilisent, et en particulier SMTP et HTTP ;

HTTP/1.1, protocole réseau fondamental en tant que tel, qui est en outre le moyen de transport des messages le plus utilisé pour les services Web ;

SMTP, alternative à HTTP en tant que moyen de transport des services Web.

30

URI, URL, URN

Le Web est une formidable mine d’informations, de documents, de programmes et de services, bref, de ressources en tout genre. Il était primordial de définir un mécanisme permettant aux utilisateurs et aux programmes de nommer et de localiser ces ressources.

C’est l’objectif des URI (Uniform Resource Identifier) définis par un standard Internet (Draft Standard) proposé par l’IETF sous la référence RFC2396 (août 1998).

Ce mécanisme d’identification et de localisation est utilisé non seulement par les protocoles de base du Web HTTP, FTP ou Telnet, mais aussi par la plupart des technologies récentes telles que les espaces de noms (namespaces) XML.


31

Les URI sont classés en trois groupes (figure ) : Ceux qui permettent de localiser des ressources sur un réseau, appelés URL (Uniform Resource Locator) ; Ceux qui permettent d’identifier et de nommer des ressources de manière unique et persistante, appelés URN (Uniform Resource Name) ; Par exemple, l'URN urn:isbn:0-395-36341-1 est un URI qui, étant un numéro de l'International Standard Book Number (ISBN), permet de faire référence à un livre, mais ne suggère ni où, ni comment en obtenir une copie réelle. Et ceux qui permettent à la fois de localiser et d’identifier une ressource.


32

Syntaxe d’un URI Un URI n’utilise qu’un jeu restreint de caractères (chiffres, lettres et quelques

symboles) car il doit pouvoir être utilisé tout aussi bien avec des moyens de communication informatisés que non informatisés (papier, etc.). Il est constitué :

de caractères réservés (« ; », « / », « ? », « : », « @ », « & », « = », « + », « $ », « , ») qui servent de délimiteurs ;

de chaînes de caractères codés en ASCII US ou à l’aide de séquences d’échappement commençant par le signe « % » (par exemple : « %2D » qui est le caractère « - »).


33

Composition d’un URI Un URI est toujours constitué de la manière suivante :

<modèle>:<chemin ou partie spécifique du modèle> Il existe néanmoins une syntaxe générique des URI, que voici :

<modèle>://<autorité><chemin> ?<requête>URN un URN a pour objectif de nommer une ressource indépendamment de sa localisation. Un modèle (scheme) spécifique a été défini par le RFC2141 et est utilisé en tant que standard pour identifier des ressources sur le Web. Sa syntaxe est la suivante :

urn:<espace de noms><identifiant au sein de l’espace de noms> Par exemple :

urn:MonEspace:MonIdentifiant


34

Le standard MIME MIME (Multipurpose Internet Mail Extensions) est un standard Internet («Draft Standard ») proposé par l’IETF sous les références RFC2045, RFC2046, RFC2047, RFC2048 et RFC2049 (dernières RFC datées de novembre 1996). Cette spécification a pour objectif :

de permettre l’échange sur Internet de messages dont le contenu textuel est codé avec un autre jeu de caractères que l’ASCII US sur 7 bits (utilisé historiquement sur le Web) ; de définir un ensemble extensible de formats binaires permettant de transporter dans ces messages tout type de contenu non textuel (audio, vidéo, HTML, etc.) ainsi que des contenus mixtes (« multipart ») ; de permettre le codage des informations d’en-têtes de ces messages avec un autre jeu de caractères que l’ASCII US.

En d’autres termes, c’est un standard qui permet d’échanger des messages multimédias sur Internet entre des systèmes informatiques hétérogènes.


35

Le protocole HTTP HTTP (HyperText Transfer Protocol) est un standard Internet (Draft Standard) proposé par l’IETF sous la référence RFC2616 (dernière RFC datée de juin 1999) et utilisé sur le Web depuis 1990.

HTTP est un protocole application générique (couche 7), qui permet de transférer des messages au format MIME entre un client et un serveur. Il est largement utilisé par de nombreux types de clients (PC, PDA, etc.), des moyens de transport variés (depuis les réseaux sans fil jusqu’aux liaisons optiques transocéaniques) et sur des architectures plus ou moins complexes. Le protocole HTTP utilise un jeu de requêtes/réponses entre un client, qui initie le dialogue, et un serveur.


36

La communication peut être directe entre les deux acteurs mais elle peut également faire intervenir trois types d’intermédiaires, que voici :

un proxy, c’est-à-dire un agent qui transfère les messages vers le serveur après en avoir réécrit tout ou partie du contenu ; une passerelle, c’est-à-dire un agent qui agit comme une surcouche pour un serveur sous-jacent utilisant un autre protocole ; cet agent se charge de traduire les messages pour permettre leur transfert vers ce serveur tiers ; un tunnel, c’est-à-dire un relais qui se charge de transmettre le message entre deux points de connexion sans modification du message (à travers un intermédiaire tel qu’un pare-feu).

En dehors des tunnels, tous les autres intermédiaires peuvent implémenter des fonctions de cache : il s’agit de garder localement une copie de la réponse tant que celle-ci est valide et de retourner cette réponse au client sans interroger à nouveau le serveur (ce qui amène un gain de performance et de trafic réseau).


37

Le protocole HTTP est à l’origine sans état, c’est-à-dire qu’il est incapable de traiter une succession de réponses/requêtes issues du même client comme un dialogue de session : le client envoie une requête, le serveur y répond, mais il n’y a pas de moyen pour communiquer entre client et serveur des informations sur le contexte du dialogue (l’état de la session).

Ce fonctionnement s’est vite avéré problématique pour les sites Internet qui ont souvent besoin de suivre les actions d’un utilisateur au sein d’une session (par exemple, pour une prise de commande).

C’est pour cette raison qu’un mécanisme de gestion d’état a été ajouté au protocole dans la RFC2965 (Proposed Standard), il introduit de nouveaux en-têtes (cookies) qui permettent d’échanger des données d’état tout au long des échanges entre un client et un serveur.

Enfin, HTTP utilise en général TCP/IP sur le port TCP 80 (par défaut), mais en théorie tout autre protocole peut être utilisé.


38

Le protocole SMTP

SMTP (Simple Mail Transfer Protocol) est un standard Internet (Proposed Standard) proposé par l’IETF sous la référence RFC2821 (dernière RFC de avril 1996).

Cette spécification a pour objectif de définir un protocole application de transfert de courrier électronique (e-mail) en utilisant un canal de distribution tel que TCP (mais non limité à ce canal).

Sa simplicité explique sans doute sa robustesse, il est par ailleurs très largement utilisé aujourd’hui pour la messagerie Internet, associé à POP ou IMAP4 :

SMTP se charge du transfert des messages alors que POP (Post Office Protocol) ou IMAP (Internet Mail Access Protocol) permettent à l’utilisateur de gérer sa boîte aux lettres et de récupérer ses messages.

Une fonction importante de SMTP est la possibilité de transférer un message en s’appuyant sur un réseau de serveurs relais et de garantir ainsi sa livraison à travers des environnements de transport différents : LAN, WAN, Internet, etc.


39

Les protocoles SSL et TLS

SSL (Secure Socket Layer) est un protocole qui a pour objectif d’assurer la sécurité des échanges entre un client et un serveur sur le Web (authentification et chiffrement). Il a été développé par la société Netscape qui a d’ailleurs déposé un brevet sur cette technologie en 1997 (n°5657390), même si elle n’a jamais demandé de contrepartie financière. La version 2.0 de SSL date de 1994 (http://wp.netscape.com/eng/security/SSL_2.html) cette version est obsolète, mais elle est pourtant toujours prise en charge par les principaux navigateurs. En 1996, un groupe de travail est créé par l’IETF afin de standardiser un protocole de sécurité pour remplacer SSL. Cette date coïncide avec la publication de la version 3.0 de SSL (Internet Draft disponible à http://wp.netscape.com/eng/ssl3), qui est par ailleurs la version la plus récente de ce protocole.


40

XML (eXtensible Markup Language) est un format universel qui permet de structurer et d’organiser des documents et des données sur le Web.

La version 1.0 de cette recommandation a été publiée par le W3C en février 1998 et ce format est devenu depuis incontournable.

Ce succès est bien sûr lié au développement d’internet mais il tient aussi en grande partie aux objectifs initiaux que le groupe de travail s’était fixé et qui tiennent en quelques mots :

simple (à construire, à lire, à traiter), précis (pas d’ambiguïté, règles syntaxiques strictes), universel (conforme à Unicode, indépendant de la plateforme logicielle), extensible.

Fondations des services Web Les technologies XML

41

XML est un sous-ensemble, une version simplifiée de SGML (Standard

Generalized Markup Language ).

C’est un langage à balises générique (markup language) : il établit les règles syntaxiques servant à marquer un document et à en dégager la structure mais il ne définit aucun jeu de balises (contrairement à HTML, par exemple).

La définition de ces balises et de leur sémantique appartient au concepteur qui construit le document.


42

Rappel des règles de base Les règles syntaxiques d’XML sont simples mais strictes, ainsi, un programme qui traite un document XML doit s’arrêter à la première erreur. On dit d’un document XML qu’il est bien formé s’il respecte les règles syntaxiques imposées et ainsi résumées :

Un document XML doit commencer par une ligne de déclaration ne serait-ce que pour préciser la version d’XML. Exemple :

<?xml version="1.0"?> Les éléments qui composent un document XML doivent être encadrés par une balise ouvrante et une balise fermante. Exemple :

<para> Ceci est un paragraphe </para> Les noms de balises sont sensibles à la casse des caractères. Exemple :

<Para> Ceci est correct </Para> <para> Ceci est incorrect </Para>

Tous les éléments doivent être correctement encadrés entre eux. Exemple : <para> <texte> Ceci est correct </texte> </para> <para> <texte> Ceci est incorrect </para> </texte>


43

Un document XML possède toujours une racine qui est définie par la première balise rencontrée dans le traitement.

Tous les éléments du document sont encadrés par cette racine. Exemple : <racine>

<element1> <souselement1> Sous élément du premier élément </souselement1>

</element1> <element2> Second élément </element2>

</racine>

Les éléments peuvent être dotés d’attributs. Exemple : <Para monattribut="mavaleur"> Élément avec comme attribut monattribut de valeur mavaleur</Para>


44

Les valeurs des attributs doivent toujours être encadrées par des quotes (simples

ou doubles). Exemple : <Para date=maintenant> Ceci est incorrect </Para> <Para date="maintenant"> Ceci est correct </Para>

Les commentaires sont définis par la balise .

On dit d’un document qu’il est valide s’il respecte une certaine description : ces descriptions sont établies par des DTD (Document Type Definition) ou des schémas (documents XML décrivant d’autres documents XML), internes ou

externes.

45

XML namespaces

Les espaces de noms XML ou namespaces sont une extension de la recommandation XML qui a été publiée en janvier 1999 par le W3C.

À l’origine de cette extension, il y a la volonté d’introduire la modularité dans les documents XML et de permettre la réutilisation de tout ou partie des documents existants.

Pour atteindre cet objectif, il est nécessaire de doter XML d’un mécanisme permettant d’éviter toute ambiguïté de nommage (problèmes de collisions de noms d’éléments ou d’attributs).


46

L’attribut xmlns: Un espace de noms XML identifie une collection de noms qui sont utilisés dans un document XML par les éléments et les attributs.

La déclaration d’un espace de noms XML est réalisée à l’aide de l’attribut réservé xmlns ou d’un attribut spécifique précédé du préfixe xmlns:

La valeur de cet attribut (une référence d’URI) est le nom de l’espace de noms. Par exemple :<soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">est équivalent à : <Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">et déclare l’espace de noms http://schemas.xmlsoap.org/soap/envelope/.


47

Xlink XML Linking Language(XLink) version 1.0 est une recommandation du W3C publiée en juin 2001. L’objectif de cette spécification est de fournir un mécanisme permettant de créer et de décrire, dans des documents XML, des liens entre des ressources. Ces liens peuvent être unidirectionnels ou des structures plus complexes. Cette recommandation est complémentaire à Xpointer, laquelle fournit un mécanisme de définition d’adresses. XPointer est une spécification du W3C dont l'objectif est de permettre de désigner un fragment de document XML en ligne, c'est-à-dire lui-même désigné par une URL.

La syntaxe Xlink L’usage d’Xlink nécessite dans un premier temps la définition de l’espace de noms http://www.w3.org/1999/xlink. En général, le préfixe utilisé est xlink. Par exemple : <monlien xmlns:xlink=" http://www.w3.org/1999/xlink "> … </monlien>


48

Cet espace de noms identifie un ensemble d’attributs qui permet de définir les liens Xlink. Le principal attribut est type, qui permet de définir le type de lien. Il y a, en effet :

des liens simples (type="simple") qui mettent en relation de façon unidirectionnelle une ressource locale et une ressource éloignée, ce sont typiquement les liens HTML A ou IMG ; des liens étendus (type="extended") qui utilisent pleinement les fonctionnalités de Xlink en permettant la création de liens multidirectionnels, de liens en ligne ou tiers.

Cet attribut permet également de qualifier d’autres éléments qui servent à la déclaration des liens étendus, comme :

des ressources locales (type="resource") ; des ressources éloignées (type="locator") ; des règles de traversée (type="arc") ;


49

La définition de ces attributs est la suivante : L’attribut de localisation href permet de définir l’URI de localisation d’une ressource éloignée. Les attributs sémantiques role, arcrole et title permettent de définir la signification d’un lien ou d’une ressource. Les attributs role et arcrole ont comme valeur des URI alors que l’attribut title attend une chaîne de caractères.

L’exemple suivant déclare une ressource éloignée en précisant un rôle (qui est un URI),

un titre, et en la nommant MDupond. <patron xmlns:xlink=http://www.w3.org/1999/xlink xlink:type="locator" xlink:href="http://wwww.masociete.com/salaries/mdupond.xml" xlink:role="http://www.masociete.com/direction" xlink:title="Michel Dupond" xlink:label="MDupond"/>


50

XML Base XML Base 1.0 est une recommandation du W3C publiée en juin 2001. Son objectif est de définir dans un document XML un chemin de base permettant d’interpréter de façon relative tous les URI contenus dans le document et implémentés en XLink. L’objectif de cette spécification est équivalent à celui d’HTML Base.

L’attribut xml:base Le principe de fonctionnement de XML Base est simple. Il consiste à ajouter un attribut xml:base à n’importe quel noeud d’un document XML. La valeur de cet attribut est un URI de base utilisé par tous les liens Xlink exprimés dans le noeud.


51


Les documents XML peuvent être représentés comme des arbres de noeuds appartenant à un des sept types suivants : le type racine, qui est utilisé pour la racine du document ; le type élément, qui est utilisé pour les éléments d’un document. Le nom d’un élément peut être exprimé en précisant un espace de noms ; le type texte, qui est utilisé pour les valeurs d’éléments données caractères (y compris <![CDATA[…]]>) ; le type attribut, qui est utilisé pour les attributs d’un élément ; le type espace de noms, qui est utilisé pour les attributs ou éléments affectés par la déclaration d’un espace de noms (attribut xmlns ou préfixé xmlns:) ; le type instruction, qui est utilisé pour les instructions XML <? … ?> (mis à part l’instruction de déclaration XML en en-tête qui ne possède pas de noeud) ; le type commentaire, qui est utilisé pour les commentaires .

52


Par exemple, pour le document XML suivant :

<? XML version="1.0" encoding="ISO-8859-1" ?>

<carnet_adresses>

<adresse id="1">

<nom>Dupont</nom>

<prenom>Bernard</prenom>

<cp>75014</cp>

</adresse>

53

<adresse id="2"><nom>Durand</nom><prenom>Paul</prenom><cp>06220</cp></adresse><adresse id="3"><nom>Vincent</nom><prenom>Pierre</prenom><cp>21017</cp></adresse></carnet_adresses> l’expression XPath suivante sélectionne tous les noms du carnet d’adresses : /carnet_adresses/adresse/nom


54

XML Schema XML Schema 1.0 est une recommandation du W3C qui a été publiée en mai 2001.

L’objectif de cette spécification est de fournir un mécanisme de description et de validation des documents XML, équivalent à la DTD mais plus expressif, extensible et surtout utilisant lui-même une syntaxe XML et les espaces de noms.

Globalement, XML Schema permet de créer un modèle de document (un schéma) qui définit :

les éléments et les attributs qui peuvent apparaître dans le document ; l’ordre et l’occurrence des éléments fils ; si un élément est vide ou s’il a un contenu ; les types de données des éléments et des attributs ; les valeurs par défaut des éléments et des attributs.


55

Description d’un schéma XML Un schéma XML est d’abord un document XML 1.0 bien formé et valide au regard de ses spécifications, c’est-à-dire soit en utilisant le schéma des schémas, soit la DTD des schémas (respectivement dans les annexes A et G de la recommandation du W3C).

Le vocabulaire (noms d’attributs et d’éléments) est défini dans deux espaces de noms : http://www.w3.org/2001/XMLSchema : cet espace de noms définit la plus grande partie du vocabulaire d’XML Schema. http://www.w3.org/2001/XMLSchema-instance : cet espace de noms définit des attributs qui peuvent être utilisés dans tout document XML (type, null schemaLocation et noNamespaceSchemaLocation).

Le schéma est un modèle qui peut être appliqué à des instances de documents XML.

En général, un modèle est fait pour être réutilisé et il est préférable de le confier à un document à part plutôt que de le voir défini dans le corps du document XML auquel il s’applique.


56

Le lien entre le document XML et le schéma est réalisé à partir des attributs xsi:schemaLocation ou xsi:noNamespaceSchemaLocation qui permettent de référencer l’URL du schéma. Ce lien implique qu’un travail de validation devra être effectué sur l’instance de document par un programme adéquat ( Les analyseurs syntaxiques XML). Un schéma XML peut être réparti dans plusieurs documents. Deux mécanismes d’inclusion sont fournis :

<xsd:include>, qui permet d’inclure un schéma et d’utiliser telles quelles les définitions et les déclarations de ce schéma ; <xsd:redefine>, qui permet non seulement d’inclure un schéma mais aussi de redéfinir les types de ce schéma par restriction ou extension.

Dans les deux cas, l’attribut schemaLocation permet de spécifier l’URL du document à inclure. De plus, ce schéma externe doit posséder le même espace de noms cible que le schéma dans lequel il est inclus.


57

Généralités SOAP

SOAP est un protocole de communication entre application basé sur le langage XML

Initialement SOAP désignait l’acronyme de Simple Object Access Protocol

Qui est derrière SOAP (Microsoft et IBM)

Objectifs visés Assurer la communication entre applications d’une même entreprise (intranet) Assurer les échanges inter-entreprises entre applications et services Web

Spécification du W3C SOAP 1.1 : http://www.w3.org/TR/2000/NOTE-SOAP-20000508/ SOAP 1.2 : http://www.w3.org/TR/soap12/

Pour comparaison, SOAP est similaire aux protocoles « RPC »

58

Maturité

XML-RPC est une technologie parfaitement mure, avec de très nombreuses implémentations (en particulier en terme de langages cibles)

SOAP 1.1 est relativement mur : bon support dans les serveurs d’applications implémentation open source complète : AXIS du projet apache (http://ws.apache.org/axis/)

SOAP 1.2 : le W3C considère que la spécification est terminée les implémentations sont en cours de réalisation certaines implémentations sont relativement complètes

59

Le modèle de données

modèle abstrait : graphe orienté étiqueté (formalisation introduite dans 1.2)

basé sur des types fondamentaux (les “feuilles” du graphe) et des constructeurs de type composé, struct et listes (les noeuds internes du graphe), associés à ces accesseurs (les arêtes du graphe)

types fondamentaux : ceux des schémas du W3C (http://www.w3.org/TR/xmlschema-2/) entiers, réels, chaînes de caractères, binaire codé en base64, etc. dates, durée, URI, etc.

types composés : énumération (une valeur parmi une liste) struct (compound) : accès nommé liste (array) : accès numéroté

60

Exemple d’une struct

0000000000000000000000000000000000

shrdlu winograd maclisp teletype

0 10 true "" false

""latin1latin1

maxResultsfilter restrict

q

start

key

oe ie lr

61

Traduction en XML

SOAP définit une représentation en XML de son modèle de données (un encoding) : pour l’utiliser, il faut définir l’attribut env:encodingStyle et lui donner la valeur http://schemas.xmlsoap.org/soap/encoding/ (noté enc)

le modèle est facultatif : on peut utiliser une autre représentation, mais il faut que l’émetteur et le récepteur la comprennent

la représentation est celle des schémas du W3C, avec des extensions pour la notion de type composé

elle utilise les notions d’ID XML et de uriReference pour implémenter des références internes, ce qui permet de réduire les volumes de données

62

Exemple de traduction

<ns1:doGoogleSearch2 xmlns:ns1="urn:GoogleSearch"3 xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"4 xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"5 xmlns:xsd="http://www.w3.org/1999/XMLSchema"6 env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">7 <key xsi:type="xsd:string">00000000000000000000000000000000</key>8 <q xsi:type="xsd:string">shrdlu winograd maclisp teletype</q>9 <start xsi:type="xsd:int">0</start>10 <maxResults xsi:type="xsd:int">10</maxResults>11 <filter xsi:type="xsd:boolean">true</filter>12 <restrict xsi:type="xsd:string"></restrict>13 <safeSearch xsi:type="xsd:boolean">false</safeSearch>14 <lr xsi:type="xsd:string"></lr>15 <ie xsi:type="xsd:string">latin1</ie>16 <oe xsi:type="xsd:string">latin1</oe>17 </ns1:doGoogleSearch>

googleSearch-part.xml

63

Traduction en XML

Principes de base : toute valeur est représentée comme le contenu d’un élément

quand la valeur correspond à un type de base, celui-ci est précisé directement ou indirectement par l’élément :

directement par un attribut type du NS des schémas (http://www.w3.org/1999/XMLSchema-instance, noté xsi) dont la valeur correspond à un type fondamental des schémas (dans le NS http://www.w3.org/1999/XMLSchema, noté xsd) directement par le nom de l’élément (choisit dans le NS enc) indirectement par le type du tableau (le cas échéant)

exemple : maxResults de type xsd:int dans le transparent précédent

64

Traduction des structs

Une struct est une valeur composée : un noeud du graphe sans étiquette dont partent des arcs étiquetés vers d’autres valeurs

les étiquettes des arcs correspondent aux champs de la structure

traduction XML : un élément (sans type associé) dont le contenu est constitué d’éléments nommés selon les champs de la structure

correspond à la représentation classique des données structurées en XML

dans SOAP 1.1, on peut avoir un type composé plus général que les structs dans lequel plusieurs champs peuvent porter le même nom : cette possibilité a été supprimée dans SOAP 1.2

65

Exemple

Fabrice

Rossinom

prénom

<?xml version="1.0" encoding="ISO-8859-1"?>2 <pers:personne3 xmlns:pers="http://apiacoa.org/teaching/xml/personnes"4 xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"5 xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"6 xmlns:xsd="http://www.w3.org/1999/XMLSchema"7 env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">8 <nom xsi:type="xsd:string">Rossi</nom>9 <pr´enom xsi:type="xsd:string">Fabrice</pr´enom>10 </pers:personne>Services

personne-part.xml

66

Traduction des listes

Les tableaux de SOAP (array) sont en fait des listes (le type n’a pas besoin d’être uniforme) :

correspond à un noeud du graphe sans étiquette dont partent des arcs numérotés vers d’autres valeurs

traduction XML : un élément de type dérivé de enc:Array (ou directement l’élément enc:Array) portant un attribut enc:arrayType qui précise le type des éléments et la taille du tableau (sous la forme [n]) le type xsd:ur-type peut servir de joker pour avoir des types différents pour chaque élément des sous-éléments dans l’ordre du tableau, avec si besoin le type pour chaque élément

67

Traduction des listes

on peut représenter des tableaux à plusieurs dimensions (modèle ligne par ligne)

on peut représenter des tableaux creux ou partiellement transmis

la traduction des tableaux a été modifiée dans SOAP 1.2 (surtout au niveau syntaxique) :

tableaux creux et partiels supprimés les attributs itemType et arraySize remplacent l’attribut arrayType

68

Exemple

2

3

4

1Ordre

<enc:Array2 xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"3 xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"4 xmlns:xsd="http://www.w3.org/1999/XMLSchema"5 env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">6 xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/"7 enc:arrayType="xsd:int[4]">8 <x>1</x>9 <y>2</y> 10 <x>3</x>11 <x>4</x>12 </enc:Array>

tableau-part1.xml

69

Exemple

Bla bla bla

15.23

−34

1Ordre

<enc:Array2 xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"3 xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"4 xmlns:xsd="http://www.w3.org/1999/XMLSchema"5 env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">6 xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/"7 enc:arrayType="xsd:ur-type[4]">8 <x xsi:type="xsd:int">1</x>9 <x xsi:type="xsd:decimal">15.23</x>10 <x xsi:type="xsd:int">-34</x>11 <x xsi:type="xsd:string">Bla bla bla</x>12 </enc:Array>Services

tableau-part2.xml Bla bla bla

15.23

−34

1Ordre

70

Références croisées

Afin de limiter le volume des messages, SOAP utilise le mécanisme de références croisées d’XML :

un élément peut être identifié par un attribut de type ID et de nom id

un élément peut être vide mais doit alors posséder un attribut href de type xsi:uri-reference

l’interprétation d’un élément vide est son simple remplacement par l’élément référencé par son href

en SOAP 1.2, href est remplacé par enc:ref de type IDREF

71

Exemple

<?xml version="1.0" encoding="ISO-8859-1"?>2 <c:cours xmlns:c="http://apiacoa.org/teaching/xml/cours"3 xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"4 xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"5 xmlns:xsd="http://www.w3.org/1999/XMLSchema"6 env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">7 xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/"8 <c:sujet xsi:type="xsd:string">Services Web</c:sujet>9 <enc:Array enc:arrayType="c:slides[2]">10 <c:slides><c:titre xsi:type="xsd:string">Introduction</c:titre>11 <c:auteur id="Rossi">12 <nom xsi:type="xsd:string">Rossi</nom>13 <pr´enom xsi:type="xsd:string">Fabrice</pr´enom>14 </c:auteur>15 </c:slides>16 <c:slides><c:titre xsi:type="xsd:string">SOAP</c:titre>17 <c:auteur href="#Rossi"/>18 </c:slides>19 </enc:Array>

reference-part.xml

72

Exemple

Services Web

Introduction

Rossi

FabriceSOAP

sujet

titre

titre

auteur

auteur

nom

prénom

1 web service said najah. 2 deuxième partie : technologies des services web

Documents