Web service Said najah.

Web service Said najah

Deuxième partie : Technologies des services Web

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.

Les services web 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 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 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 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 Il existe plusieurs technologies derrière le terme services web : Les services web de type Representational state transfer (REST) exposent entièrement ces fonctionnalités comme un ensemble de ressources Uniform Resource Identifier (URI) identifiables et accessibles par la syntaxe et la sémantique du protocole HTTP. Les Services Web de type REST sont donc basés sur l'architecture du web et ses standards de base : HTTP et URI. Les Services Web WS-* exposent ces mêmes fonctionnalités sous la forme de services exécutables à distance. Leurs spécifications reposent sur les standards SOAP et WSDL pour transformer les problématiques d'intégration héritées du monde Middleware en objectif d'interopérabilité.

Les services web 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 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). Le nom de polymorphisme vient du grec et signifie qui peut prendre plusieurs formes. Cette caractéristique est un des concepts essentiels de la programmation orientée objet. Alors que l'héritage concerne les classes (et leur hiérarchie), le polymorphisme est relatif aux méthodes des objets. On distingue généralement trois types de polymorphisme : Le polymorphisme ad hoc (également surcharge ou en anglais overloading) Le polymorphisme paramétrique (également généricité ou en anglais template) Le polymorphisme d'héritage (également redéfinition, spécialisation ou en anglais overriding) Le polymorphisme paramétrique, appelé généricité, représente la possibilité de définir plusieurs fonctions de même nom mais possédant des paramètres différents (en nombre et/ou en type). Le polymorphisme paramétrique rend ainsi possible le choix automatique de la bonne méthode à adopter en fonction du type de donnée passée en paramètre. Ainsi, on peut par exemple définir plusieurs méthodes homonymes addition() effectuant une somme de valeurs. La méthode int addition(int, int) pourra retourner la somme de deux entiers La méthode float addition(float, float) pourra retourner la somme de deux flottants La méthode char addition(char, char) pourra définir au gré de l'auteur la somme de deux caractères etc. On appelle signature le nombre et le type (statique) des arguments d'une fonction. C'est donc la signature d'une méthode qui détermine laquelle sera appelée. En C++, une fonction virtuelle est une fonction qui peut être surchargé. Il faut alors utilisé le mot-clef virtual. Avec Java, les méthodes sont virtuelles sauf si le mot-clef final est utilisé...

Les services web 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 Architecture

Les services web 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 Architecture de base 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

Les services web

Les services web 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 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 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. Le projet ebXML a pour but de définir une architecture standard pour gérer les transactions b-to-b, de la définition des documents commerciaux aux processus.

Les services web 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 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 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 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 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 é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 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 Distributed Component Object Model : est une technique propriétaire de Microsoft qui permet la communication entre des composants logiciels distribués au sein d'un réseau informatique RPC : En informatique et en télécommunication, RPC (Remote Procedure Call) est un protocole réseau permettant de faire des appels de procédures sur un ordinateur distant à l'aide d'un serveur d'applications. Ce protocole est utilisé dans le modèle client-serveur pour assurer la communication entre le client, le serveur et des éventuels intermédiaires. RMI : Remote method invocation, plus connu sous l'acronyme RMI est une interface de programmation (API) pour le langage Java qui permet d'appeler des méthodes distantes, sur le principe des ORB. L'utilisation de cette API nécessite l'emploi d'un registre RMI sur la machine distante hébergeant ces objets que l'on désire appeler au niveau duquel ils ont été enregistrés. Cette interface de programmation est très souvent utilisée en parallèle avec l'API d'annuaire JNDI ou encore avec la spécification de composants distribués transactionnels EJB du langage Java. CORBA : CORBA, acronyme de Common Object Request Broker Architecture, est une architecture logicielle, pour le développement de composants et d’Object Request Broker ou ORB. Ces composants, qui sont assemblés afin de construire des applications complètes, peuvent être écrits dans des langages de programmation distincts, être exécutés dans des processus séparés, voire être déployés sur des machines distinctes.

Les services web

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

Les services web Exemples de services existants
Google ( : 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( accès gratuit mais limité (une requête par seconde après enregistrement) propose recherche et gestion d’un panier d’achats

Fondations des services Web 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.

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.

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: 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.

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 « - »). Les séquences d'échappement sont utilisées pour définir certains caractères spéciaux dans les chaînes de caractères littérales.

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 L’enregistrement de nouveaux modèles ou scheme est soumis à une procédure décrite par le RFC2717. La liste des modèles enregistrés est, quant à elle, gérée par l’IANA ( On y trouve notamment : • ftp (RFC1738) ; • http (RFC2616) ; • mailto (RFC2368) ; • file (RFC1738

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.

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.

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).

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é.

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 ( ) 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.

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° ), même si elle n’a jamais demandé de contrepartie financière. La version 2.0 de SSL date de 1994 ( 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 à qui est par ailleurs la version la plus récente de ce protocole.

Fondations des services Web Les technologies XML
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.

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. Les balises génériques sont des balises qui n’ont pas de sens sémantique. En effet, toutes les autres balises XHTML ont un sens : <p> signifie "Paragraphe", <h2> signifie "Sous-titre" etc. Parfois, on a besoin d’utiliser des balises génériques (aussi appelées balises universelles) car aucune des autres balises ne convient. On utilise le plus souvent des balises génériques pour construire son design.

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>

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>

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.

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).

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=" est équivalent à : <Envelope xmlns=" et déclare l’espace de noms Dans le premier exemple, xmlns: non seulement déclare un espace de noms, mais aussi définit un préfixe. Tout élément ou attribut dont le nom appartient à l’espace de noms doit être précédé de ce préfixe. Par exemple : <soap-env:Envelope xmlns:soap-env=" soap-env:encodingStyle=" <soap-env:Body> </soap-env:Body> </soap-env:Envelope>

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 En général, le préfixe utilisé est xlink. Par exemple : <monlien xmlns:xlink=" "> … </monlien>

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") ;

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= xlink:type="locator" xlink:href=" xlink:role=" xlink:title="Michel Dupond" xlink:label="MDupond"/>

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. L'élément <BASE> prend en compte l'URL (Uniform Resource Locator) du document lui-même comme adresse de base fixe pour palier aux situations dans lesquelles le document pourrait être lu hors de son contexte. Les URL dans le document peuvent s'écrire relativement à cette adresse de base dans un format "réduit".

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 .

Par exemple, pour le document XML suivant : <? XML version="1.0" encoding="ISO " ?> <carnet_adresses> <adresse id="1"> <nom>Dupont</nom> <prenom>Bernard</prenom> <cp>75014</cp> </adresse>

<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> </carnet_adresses> l’expression XPath suivante sélectionne tous les noms du carnet d’adresses : /carnet_adresses/adresse/nom

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.

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 : : cet espace de noms définit la plus grande partie du vocabulaire d’XML Schema. : 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.

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.

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 : SOAP 1.2 : Pour comparaison, SOAP est similaire aux protocoles « RPC »

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 ( 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

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 ( 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é

shrdlu winograd maclisp teletype
Exemple d’une struct key q shrdlu winograd maclisp teletype start 10 true "" false maxResults filter restrict oe lr ie "" latin1 latin1

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 (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

Exemple de traduction googleSearch-part.xml <ns1:doGoogleSearch
2 xmlns:ns1="urn:GoogleSearch" 3 xmlns:env=" 4 xmlns:xsi=" 5 xmlns:xsd=" 6 env:encodingStyle=" 7 <key xsi:type="xsd:string"> </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>

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 ( noté xsi) dont la valeur correspond à un type fondamental des schémas (dans le NS 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

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

Exemple nom Rossi Fabrice prénom personne-part.xml
<?xml version="1.0" encoding="ISO "?> 2 <pers:personne 3 xmlns:pers=" 4 xmlns:env=" 5 xmlns:xsi=" 6 xmlns:xsd=" 7 env:encodingStyle=" 8 <nom xsi:type="xsd:string">Rossi</nom> 9 <pr´enom xsi:type="xsd:string">Fabrice</pr´enom> 10 </pers:personne> Services

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

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

Exemple Ordre 1 2 3 4 tableau-part1.xml <enc:Array
2 xmlns:env=" 3 xmlns:xsi=" 4 xmlns:xsd=" 5 env:encodingStyle=" 6 xmlns:enc=" 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>

Exemple 15.23 −34 1 Ordre 15.23 −34 1 Ordre Bla bla bla Bla bla bla
tableau-part2.xml <enc:Array 2 xmlns:env=" 3 xmlns:xsi=" 4 xmlns:xsd=" 5 env:encodingStyle=" 6 xmlns:enc=" 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

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

Exemple reference-part.xml
<?xml version="1.0" encoding="ISO "?> 2 <c:cours xmlns:c=" 3 xmlns:env=" 4 xmlns:xsi=" 5 xmlns:xsd=" 6 env:encodingStyle=" 7 xmlns:enc=" 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>

Exemple Services Web sujet Introduction titre nom Rossi auteur titre
prénom SOAP Fabrice auteur

Web service Said najah.

Présentations similaires

Présentation au sujet: "Web service Said najah."— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

Web service Said najah.

Présentations similaires

Présentation au sujet: "Web service Said najah."— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back