Faculté des sciences de Monastir

Résumé SOA

CHAPITRES 1-2-3
 Chapitre 1 : Introduction

§ Concepts d’une architecture SOA :

- Un service web :
• une composante web
• possède une interface lui permettant la communication.
- Une interface
• ensemble de fonctions
• invoquer suivant une spécification bien définie
- Un service
• conçu/développé par un fournisseur
• consommé par un consommateur.

§ Acteurs d’une architecture SOA

- Le fournisseur de service
• Application s'exécutant sur un serveur
• comportant un module logiciel accessible par Internet en XML.
- Le client
• Application cliente se liant à un service
• invoquant ses fonctions par des messages XML (par le protocole SOAP)
- L’annuaire de services :
• publiés par les providers (par UDDI)
- Le consommateur
• a accès à l’interface du service pour invoquer une fonctionnalité particulière.
- Le fournisseur
• a accès au code source du service dans le but de faire une mise à jour ou une maintenance du service.

§ Technologies

- Contrat / description WSDL (Web Service Description Language) :

• description du service et de son utilisation
• échangée entre le fournisseur de service et le client.
- SOAP (Simple Object Access Protocol) :
• Protocole de communication au sein de la SOA

- Annuaire UDDI (Universal Description Discovery and Integration) :

• liste dans laquelle les fournisseurs de services publient leurs descriptions.
- Bus ESB (Enterprise Service Bus) :
• moyen de communication entre le client et le fournisseur du service
• permettre la communication des applications qui à la base ne sont pas pensées pour fonctionner
ensemble

§ Fonctionnement :

§ Caractéristique de l’Architecture orientée service :

• l’aspect modulaire (ensemble de fonctionnalités qui font sens)
• Boite noire (séparation interface/implémentation)
• Indépendant de la localisation
• Neutralité vis-à-vis des protocoles de transport
• Services faiblement couplés

§ Approches de SOA
• Bottom-Up : Son principe est de commencer par un petit groupe et on ajoute jusqu’à on obtient une grande
entreprise.
• Top-down : c’est l’adverse de Bottom-Up. Top-down est la décomposition d’un système ou problème jusqu’à
l’obtient d’un petit service de base.
 Chapitre 2 : Les Services
Un service :
- comportement défini par contrat
- réalisé et fourni par tout composant
- utilisé par tout composant sur la base unique du contrat.

8 Aspects d’un service :

1) Il est exposé à travers un contrat standardisé.
2) Il permet un couplage lâche entre le consommateur et le fournisseur.
3) Il est abstrait (vu comme une boîte noire).
4) Il est réutilisable.
5) Il est autonome.
6) Il est sans état.
7) Il est découvrable (Possibilité de découverte de service).
8) Il est composable (Capacité de composition en modules de services).

§ Contrat Standardisé :
définit un accord entre le fournisseur et le consommateur :
• contrat syntaxique :
o propose une représentation technique du service
o constitue le contrat d’utilisation du service
o présente le nom du traitement, ses paramètres d’entrée et de sortie et les contraintes structurelles
qui s’y appliquent.
o Ensemble de schéma XML (XSD)

• contrat sémantique :
o une description informelle du traitement
o précise les règles et contraintes d’utilisation du service (Les exceptions; les pré- conditions et post-
conditions techniques ou métiers, policies : sécurité/encodage/langue…)
o Ensemble de schéma XML (XSD)
• contrat de niveau de service (QoS et SLA)
o spécifie par exemple le temps de réponse maximum attendu QoS : Quality of service
o les plages horaires d’accessibilité SLA : Service Level Agreement
o le temps de reprise après interruption
XML : Extensible Markup Language
Standardisation du contrat :
utilisation d’un formalisme commun :
XSD : XML Schema Definition
o moyen de construire un modèle cohérent et donc facile à comprendre et à partager
o faciliter la communication
o facilite la centralisation des éléments constituant les contrats
èRéutilisabilité
§ Couplage lâche
• Le couplage technique : impose au consommateur de connaître le protocole d’échange
du fournisseur
• Le couplage fonctionnel : impose au client de connaître le format d’échange du
fournisseur
Couplages inévitables :
1. La logique d’un service est directement dépendante de son implémentation
2. la logique d’un service est fortement liée aux technologies sur lesquelles son implémentation s’appuie
3. la logique d’un service est également dépendante des services qui le composent
4. le contrat de service ainsi que sa logique peuvent être couplés aux processus qui les utilisent

à Couplage du contrat de service vers la logique d’implémentation du service :

résulte d’une approche Contract last lors du design du serviceè à exclure car elle induit un couplage
du contrat avec l’environnement du service.
à Couplage de la logique du service au contrat :
 dénote une approche Contract first dans la conception du service è préférable et le couplage du service
vers son contrat est considéré comme un couplage positif.
Þ Le consommateur d’un service est lié au contrat de ce dernier, et ne doit être lié qu’à celui-ci (Pas au
service lui-même). C’est ce que l’on appelle le couplage lâche.

§ Abstraction :
- fournir les services du SI sur un modèle boîte noire
- seules les informations fournies au consommateur sont celles contenues dans son contrat
- cette restriction d’accès aux informations du service ne doit pas violer le principe de la prédictibilité du
service
• Prédictibilité du service : le comportement du service et la réponse qu’il donne suite à une
requête ne doivent pas varier è le respect du contrat du service
§ Réutilisabilité :
-la capacité du service à répondre aux besoins de plusieurs types de consommateurs
les principaux freins qui peuvent influencer mal sur le degré de réutilisation de service sont :
1. La centralisation et la standardisation des ressources :
Centraliser les contrats de service assure un accès exclusif aux services via le contrat,
simplifiant ainsi l'inventaire des services pour une réutilisation maximale au sein de
l'entreprise.
2. La démarche suivie dans la conception de service :
•Le processus de conception « Bottom-up » :
Un service peut émerger soit par une approche « Push » du fournisseur, soit par une
approche « Pull » du consommateur. Selon l'initiateur (fournisseur ou client), le
résultat peut être un service générique (Push) visant à satisfaire tous les partenaires
(risque de manquer de valeur métier) ou un service répondant spécifiquement aux
besoins d'un client sans considération de réutilisation, souvent dicté par des
impératifs de délai imposés par le client.
• Un processus de conception « Top-down » :
Le service découle d'une analyse approfondie et systémique du système
d'information ou d'un bloc spécifique. Bien qu'assurant une cohérence globale des
services, cette approche représente un défi complexe dont les avantages ne sont pas
garantis.
Þ Le choix de la démarche dépond du contexte et l’offre de services existants.
3. La granularité de service :
- le nombre de fonctions recouvertes par celui-ci
- une mauvaise granularité du service va limiter son réutilisation (mauvaise granularité :
trop ou trop peu de fonctionnalités)
§ Autonomie
- le service n’a pas besoin à d’autres services pour accomplir sa tâche
- Réduire l’accès partagé aux ressources d’un service et augmenter le niveau d’isolation physique des
services sont deux leviers permettant d’augmenter cette capacité.
• Autonomie de niveau de service
• Autonomie pure
§ Sans état (Stateless)
la gestion d’états (d’informations de contexte) au sein d’un service pose des problèmes :
• De compréhension et de maintenabilité : augmenter la complexité de l’implémentation(rendre
difficile sa lecture, sa documentation, sa testabilité )
• De réutilisation : suite à la complexité de lisibilité
• De performances :la gestion d’état est consommatrice de ressources systèmes (stockage)
Þ donc conception et implémentation de services sans état. La responsabilité de la gestion d’états sera
alors déléguée aux utilisateurs (consommateurs) des services
§ Découvrabilité :
Un service, accompagné de métadonnées de communication, nécessite une découverte humaine en
l'absence de découvrabilité en temps réel. Un référentiel de services centralisé stocke les
métadonnées essentielles pour la recherche et la récupération des éléments associés aux services par
la mise en œuvre d’un repository de services.
 § Composabilité :
L’objectif est ici de déterminer la « bonne » granularité de services afin de décomposer la solution à
un problème métier de haut niveau en un ensemble de « plus petites unités réutilisables » de
traitement : les services
de vue technique (runtime), un service ne sera composable que s’il est autonome et stateless (c’est-à-
dire réutilisable).
Les applications des services Web :
• B2C (Business to Consumer) : Qualifie une application, un site Internet destiné au grand public.
• B2B (Business to Business) : Qualifie une application, un site Internet destiné au commerce de professionnel
à professionnel.
Exemples :
Google+ : B2B et B2C // Twitter , Viadeo et LinkedIn ,WordPress : B2B //. Facebook et Myspace : B2C

Fonctionnement des services web :

 Chapitre 3 : Principales technologies de développement de service web

La pile protocolaire simplifiée des services Web

La couche de Transport HTTP (Hypertext Transfer Protocol)

o Cette couche s’intéresse aux protocoles de transport
o transporter les requêtes et les réponses échangées entre services
o peut être remplacé par FTP (File Transfer Protocol), JMS (java messagerie services), SMTP (Simple
Mail Transfer Protocol), POP
Structure Du HTTP :
Notion d’entité :
o transporter des entités document
o messages-requêtes (du client au serveur) et de messages-réponse (du serveur au client)
o L'entité est toujours définie par :
• Une entête d'entité (méta informations sur le contenu et la transmission).
• Un corps d'entité (le contenu).
Construction De La Requête :
1. Le libellé de requête : la requête http est une demande au serveur à exécuter un ordre :
• HEAD : "donne-moi les métas informations concernant un document" ;
• GET : "donne-moi le contenu du document (et ses méta informations par la même occasion)" ;
• POST : "fais ce que tu veux (ou tu peux avec les données que je t'envoie)" ;
• PUT : "mets le document que je t'envoie où je te le dis".

2. La Cible :
o représentée par une URL absolue ou relative
o Le serveur est chargé de traduire en une réalité physique exploitable (un fichier physique, un
exécutable, un répertoire).
o Des préférences convenues entre le serveur et le client pour améliorer le service rendu, sont :
• Le choix de la langue la plus appropriée.
• Le choix d'un encodage acceptable du côté du client.
• Le choix d'une version
3. Un corps de requête :
• Le client pousse un document local vers le serveur.
4. Détermination de la longueur du corps d'entité :
o Toute requête portant un contenu d'une certaine longueur doit informer le
serveur de cette longueur. On utilise le champ : Content-Length

Construction De La Réponse :
Le schéma de réponse est symétrique à celui de la requête, à la différence près que le corps d'entité est le plus
souvent non vide.
• Une requête mono-entité, dans le cas général se construit ainsi :

Le langage XML (eXtensible Markup Language)

• XML est un standard qui permet de décrire des documents structurés transportables sur les
protocoles d’Internet.
• La technologie des services web, conçue pour des environnements hétérogènes, nécessite une
interopérabilité entre les systèmes. Les schémas de type de données XML jouent un rôle
essentiel,d'où la prédominance de XML dans cette technologie.
• Quelques spécifications de XML :
• XSD (XML Schema) : c’est un langage qui sert à décrire formellement un vocabulaire
• XSLT (Extensible Stylesheet Language Transformations) : est utilisé pour transformer un document
XML basé sur un certain schéma en un autre document XML
• XPath (XML Path Language) : fournit une syntaxe d’expressions utilisées pour créer des chemins de
localisation.
• Espaces de noms :
o Mécanismes permettant de partitionner les balises XML (permet d’avoir deux fois le même
nom de balise)
o est défini dans n’importe quelle balise par l’attribut xmlns et par une URI.
• Deux façons de définir une grammaire X :
• DTD (Document Type Description) :
o Langage de définition de grammaire XML
o Expression faible (type, structure)
• XML Schéma :
o Langage XML de définition de grammaire XML
o Expression puissante (type, structure, héritage)
Þ Un document XML est dit valide lorsqu’il est conforme à une grammaire.

Avantages du langage XML :

• Standard W3C
• peu de mot clef: Simplicité
• indépendant des plates-formes: Portabilité
• possibilité de créer ses propres balises: Extensibilité
• Outils disponibles (et gratuits)
• Largement utilisé pour les échanges inter-applications

La couche de Communication SOAP (Simple Object Access Protocol)

Définition:
• SOAP est un protocole standardisé par W3C, et qui assure le transfert des messages et les appels de
procédures RPC (Appels de procédures distants) indépendamment du transport.
• l’échange de données structurées en XML.
Objectif : permettre la normalisation des échanges de données.
- définit un moyen uniforme d'échange de données encodées XML sous forme d'appels de procédures à
distance RPC
- assure l'interopérabilité entre composants tout en restant indépendant des plates-formes et des langages de
programmation
- Il repose sur deux standards :
• XML : structuration des messages.
• http : transport.
- Les paquets de données circulent sous format XML
- tous types de données peuvent être transportés
- Les données binaire sont transportées sous forme de pièces jointes avec le message SOAP principal
- Les messages SOAP peuvent traverser les Proxy et les pares-feux
- l'échange de données :
o synchrone (requête/réponse)
o asynchrone (accompagnement des processus).

1. Framework de messagerie :
la manière avec laquelle les messages sont manipulés
a. Nœud SOAP(Nodes)
o l'infrastructure technique qui alimente les différents scénarios de communication entre
services
o le processeur logique permettant de recevoir, transmettre, et exécuter un ensemble
d'opérations sur les messages SOAP
o identifié par un URI
o peut être classifié en SOAP server, SOAP listener ou bien SOAP router selon son rôle dans
la communication.
b. Différents rôles joués par un nœud
o Expéditeur initial (Demandeur de service),(Initial Sender) ou (Service Requestor).
o Récepteur Final (Fournisseur de service),(Ultimate Receiver) ou (Service Provider).
o Nœud intermédiaire (Intermediary)
2. Encodage et sérialisation standard pour les objets:
• SOAP impose une spécification d'encodage/sérialisation standard
• doit être appliquée sur les données du message
• Cette tâche est assurée par le runtime SOAP implanté des deux côtés (client, fournisseur) avec le RPC
3. Invocation de Service d'objets distants via SOAP RPC :
- SOAP permet d'invoquer un objet distant en communiquant les informations nécessaires à l'appel: nom de la
méthode, et sa signature numérique (ses arguments) dans un message au format XML.
- La réponse à la requête est aussi renvoyée encapsulée dans un message au format XML.
- Les différentes étapes d'invocation des objets distants sont:
1. Le programme client SOAP crée le document XML contenant les informations nécessaires à
l'invocation d'un objet distant, et le transmet au protocole HTTP (requête POST).
2. Le message est transmis au serveur via une connexion HTTP.
3. Le serveur reçoit le message et fait appel à l'objet concerné.
4. L'objet effectue le traitement demandé et renvoie les résultats au serveur SOAP.
 5. Le serveur SOAP encapsule les résultats et les envoie dans un document XML au client via le protocole
HTTP.
6. Le client SOAP décode le message et envoie les résultats au demandeur initial.
4. Messages SOAP :
• Le framework de messagerie SOAP requiert que les messages SOAP soient composés d'une
enveloppe (Envelope) contenant :
• Un entête (Header) :véhiculer les métadonnées du message : Optionnelle
• un corps (Body) : contient les données applicatives destinées au récepteur final : partie
principale
• tous les fichiers attachés en pièces jointes doivent être référencés par des URL dans le message
principal.
5. Acheminement des messages :
A l'arrivée d'un message chez un nœud SOAP :
1. Vérifier la structure du message: enveloppe, entête, et corps du message.
2. Déterminer les entrées d'entêtes destinées à lui-même, et l'ensemble des rôles à en exécuter.
3. Sélectionner parmi ces entrées celles qui sont mandataires.
4. Si une de ces entrées n'est pas comprise ou bien qu'il n'a pas la capacité d'en traiter, il envoie un message
d'erreur à l'expéditeur initial.
5. Traiter toutes les entrées mandataires, ainsi que celles qui sont optionnelles et dont il a la capacité d'en
traiter.
6. Traiter le corps du message s'il s'agit du récepteur final.
7. Retransmettre le message au nœud suivant s'il s'agit d'un nœud intermédiaire.

a) Traitement de l'entête:
Une entrée entête SOAP peut contenir un attribut d'information appelé "role", qui sert à déterminer quel
nœud doit exécuter ce rôle.
b) Compréhension des entrées d'entête:
o L'utilisation de l'attribut mustUnderstand = "true" permet de rendre la compréhension et le
traitement d'une entrée par un nœud SOAP spécifique obligatoire
o si le nœud concerné n'a pas compris ou bien n'est pas capable de traiter cette entrée,
l'acheminement du message est arrêté et un message d'erreur est envoyé à l'expéditeur initial.
c) Réacheminement des messages par les nœuds intermédiaires:
o Un nœud SOAP intermédiaire doit obligatoirement retransmettre le message reçu au nœud suivant ,
il doit:
o Supprimer toutes les entrées entête déjà traitées ainsi que celles ignorées et dont elles ne
contiennent pas l'attribut "relay = true ".
o Garder toutes les entrées non traitées qui contiennent l'attribut "relay = true", ainsi que toute entrée
destinée aux autres nœuds.
o Ne prendre un attribut relay en considération que dans le cas où mustUnderstand est absent ou bien
égal à "false".
6. Nœud intermédiaire actif :
- En plus du traitement effectué par des intermédiaires de réacheminement, les intermédiaires actifs
entreprennent du traitement supplémentaire : des services de sécurité, des services d'annotation et des
services de manipulation de contenu.
7. Règles d'encodage:
Les règles d'encodage SOAP expriment les types de données définis pour l'application en XML :
a) Les types de données simples :
tous les types simples définis comme Built-in data-type dans XML Schema : string, integer, float, date, etc .
b) Les types composés
- Struct (enregistrement)
- Array : marqué par leur attribut xsi:type qui est SOAP-ENC:Array , Le type des membres du tableau est
déclaré au moyen d'un autre attribut SOAP-ENC: arrayType
8. Liaison du SOAP avec les protocoles du transport:
a) Modes de transport de message SOAP:
• Le mécanisme RPC SOAP est utilisé pour les communications au sein de l'entreprise
• La communication par messages est utilisée entre deux entités métiers différentes
b) Utilisation de SOAP avec RPC:
- Pour effectuer une invocation de méthode distante les informations suivantes sont nécessaires:
• URI de l'objet cible.
• Nom de la méthode.
• Signature de la méthode (facultative)
• Paramètres de la méthode
• Données de l'entête (facultatives)
- Les appels et réponses de méthodes RPC sont transmis encapsulés dans l'élément Body du message

c) Utilisation du SOAP avec http en mode messagerie:

d) Liaison sur des protocoles applicatifs spécifiques:
Des protocoles sous-jacents pourraient être conçus pour un but particulier ou un profil d'application .
9. Sécurité du SOAP:
Le concepteur et l'implémenteur du protocole SOAP doivent prendre en considération différents types de
risques qui peuvent être produits :
a) Risque dû au contenu du message (nœud SOAP) :
Les considérations de sécurité ne se limitent pas uniquement à la partie XML du message, mais aussi les
fichiers attachés, et les données passées comme paramètres (par exemple des chaînes de requêtes sous forme
d'URI).
b) Risque dû au transport(nœuds intermédiaires) :
Un intermédiaire SOAP atteint ou un intermédiaire implémenté ou configuré sans attention aux considérations
de sécurité et de confidentialité pourrait être utilisé pour une large étendue d'attaques potentielles.

c) Risque dû aux spécifications (protocole de transport)

Les auteurs de spécification de liaison doivent décrire en détails les implications de sécurité dans le cas où des
recommandations ou obligations ne seraient pas suivies
Les auteurs de spécification de liaison doivent identifier tout risque qui pourrait subsister et indiquer où des
contre-mesures supplémentaires seraient nécessaires au- delà de celles fournies dans la spécification de la
liaison.

Implémentation SOAP :
Il existe actuellement diverses implémentations du protocole SOAP ainsi que des ensembles d'outils, adaptés à
une gamme variée d'environnements et de langages de programmation tels que Java, C++, C, Perl, PHP,
Python, entre autres. Ces solutions sont conçues pour satisfaire les divers besoins des utilisateurs en matière
de communication entre applications, offrant une flexibilité d'intégration dans des contextes technologiques
diversifiés.
Ces outils peuvent implémenter de différentes fonctionnalités :
• Processus fondamental de création, déploiement et utilisation des services web.
• Comprendre et réaliser tous les traitements concernant les styles d'encodage et la translation des
types natifs de données dans XML et vice versa.
• Encodage, décodage et routage des messages SOAP à travers le protocole de transport.
les fonctionnalités spécifiques sont diverses, elles concernent surtout :
• L'utilisation du protocole de transport
• Les fonctionnalités de sécurité
• Appel d'objet à distance avec différents niveaux d'automatisation.
• Utilisation et manipulation des données SQL.
STRUCTURE DES MESSAGES SOAP
La structure d’un message SOAP diffère selon les types d’informations transportées :
• informations sont tous textuelles èle format de message simple suffit
• s’il y a des informations nécessitant des formats de données binaires spécifique (image, vidéo, son,
pdf,..) èdoivent être encapsulées dans un format MIME
1. Message simple :
Un message SOAP simple est message contenant uniquement du texte (XML). Il est composé de :
a) L’enveloppe SOAP (Envelope) :
- conteneur englobant tous les autres éléments du message
- Sa déclaration est strictement obligatoire
- Le mot-clé Envelope est suivi d'un espace de nom = un URI qui pointe vers un schéma XML.
- La valeur de cet URI (schéma XML) varie selon la version du message SOAP(1.1 ou 1.2).
- A la suite de l’URI l’attribut encodingStyle peut être utilisé pour indiquer le format de sérialisation utilisée
pour coder un élément donné et ses descendants( tableau par exemple).
b) L’entête du message (Header) :
• optionnelle
• composée d’une ou plusieurs entrées (Header entry/ Header Block) qui peuvent être destinée { un ou
plusieurs nœuds SOAP (nœuds intermédiaires et/ou récepteur final du messag}.
• L’entrée peut contenir des attributs nécessaires pour le traitement du message (encodingStyle, role
(actor), mustUnderstand et relay )
à Attribut « role » (actor pour la version 1.1) : désigner le destinataire concerné (un émetteur, un
récepteur final ou bien aucun ou plusieurs intermédiaires) par le traitement de cette entrée.
S’il n’est pas spécifié alors seul le destinataire final est concerné de cette entrée

Cet attribut peut prendre 3 valeurs particulières:

à L'attribut « mustUnderstand » : utilisé pour déterminer si la compréhension de l'entrée par le nœud

concerné est obligatoire ou non.
à L'attribut « encodingStyle » : utilisé pour indiquer au destinataire le format de sérialisation a été
utilisé pour coder un élément donné et ses descendants.
à L'attribut « relay » : Il détermine si une entrée dans l'entête d'un message SOAP arrivé chez un
intermédiaire doit être réacheminée ou non lorsque le traitement de cette entrée est impossible par
le nœud actuel.
c) Le corps du message (Body) :

• doit absolument être présent de manière unique dans chaque message

• le corps d’un message d’erreur ne doit contenir que l’entrée « fault » qui sert à reporter et expliquer
la nature d’erreur rencontré est obligatoire.
2. Les messages d’erreur :
Le corps d’un message d’erreur est constitué d’une entrée unique appelée l’entrée "Fault"
Cette entrée sert à définir le type du message d’erreur, et à donner plus de détails sur cette erreur.
Selon le type d’erreur signalée, l’entête du message peut exister ou non
a) Structure de l'entrée Fault:
• L’élément Code : C’est un élément obligatoire qui a deux fils :
® Value : obligatoire
® Subcode :optionnel
Ses valeurs peut être une des valeurs prédéfinies de type xs:QName qui donne le code d’erreur comme défini
par SOAP
• L’élément Reason : C’est un élément obligatoire
qui contient une chaîne de caractères explication l'erreur destinée à être comprise par l'utilisateur.
• Elément texte:
• L’élément Node : Requis pour tous les nœuds SOAP, excepté l'ultime destinataire. Il contient un URI
décrivant le nœud ayant entraîné l'erreur.
• L’élément Role : Requis pour tous les nœuds SOAP, excepté pour l'ultime destinataire. C'est un URI décrivant
la source de l'erreur .
• L’élément Detail : Requis si le corps de l'erreur SOAP ne peut pas être traité (erreurs spécifiques aux
applications). Doit fournir des éléments sur le corps des éléments SOAP ayant échoué
b) Codes d'erreurs:
Il existe 5 groupes de code d'erreur (4 dans la version 1.1) :

• Erreur VersionMismatch : Quand un nœud génère une erreur avec value de code ="VersionMismatch" il
devrait fournir obligatoirement une entrée d'entête appelée "Upgrade" dans le message d'erreur généré qui
contient une liste ordonnée d'espaces de noms représentant les versions supportées.
• Erreur mustUnderstand : Lorsqu'un nœud SOAP génère une faute avec une valeur Value du Code fixée à
"env:MustUnderstand", il devrait fournir un bloc d'en-tête NotUnderstood dans le message de faute généré.

c) Transition de version de SOAP/1.1 à SOAP Version 1.2

• lorsqu'un nœud SOAP/1.1 reçoit un message SOAP Version 1.2, il crée une faute SOAP de décalage de
version.
• De même, un nœud SOAP Version 1.2 peut traiter un message SOAP/1.1 ou générer une faute avec
un en-tête Upgrade pour indiquer le support de SOAP en version 1.2, permettant à un nœud
SOAP/1.1 d'interpréter correctement la faute générée par le nœud SOAP 1.2.
3. Message avec pièce jointe :
Le support des données non XML nécessite un emballage MIME multipart pour les messages. L'enveloppe
MIME comporte deux parties : la première avec le message SOAP et un bloc Manifest Header, généré par le
Handler Message Manifest ; la deuxième avec les payloads, pouvant être des documents XML ou d'autres
formats. Cela offre une flexibilité dans le traitement des messages en prenant en charge divers types de
données.
Le Manifest Header peut contenir les éléments qui référencent les parties MIME séparées en utilisant leurs
identificateurs de contenu. Ceci peut être réalisé en utilisant les références XLink.
 § La couche de Description WSDL (Web Service Description Language) :

• WSDL est un langage de description des capacités de services web basé sur XML. Un document WSDL
décrit essentiellement le nom de la méthode utilisée, son nombre de paramètres, et leur type, ce
qu'un service web offre, où il réside et comment on peut l'invoquer.
• La description d’un service doit inclure la définition des composants nécessaire à :
- protocole de communication (SOAP pour les services web)
- l’interaction avec un client ou un autre service web

Les différents éléments décrits dans WSDL sont les suivants :

• Les opérations proposées par le service web.
• Les données et messages échangés lors de l’appel d’une opération.
• Le protocole de communication.
• Les ports d’accès au service.

Le WSDL divise les informations en deux niveaux : abstrait (réutilisable, non spécifique au service) et concret
(protocoles spécifiques au service). Le niveau abstrait est utilisé lors de la sélection, le niveau concret lors de
l'invocation des méthodes du service web.

1. Niveau abstrait:

Le niveau abstrait dans WSDL décrit les détails des méthodes d'un service, ainsi que les informations sur les
messages et les données échangés lors de son utilisation.
En cas de méthodes similaires entre deux services, la description WSDL au niveau abstrait peut être réutilisée.

composé des informations suivantes :

a) Les types de données (types)
b) Les messages (message)
c) Les opérations (portType)
2. Niveau concret:
Il décrit la manière dont le client accède à un service en particulier
non réutilisable (propre à un service unique)
Les informations décrites dans le niveau concret sont
a) Le protocole de communication (binding)
b) Les ports d’accès au service (service)
Ä Le client peut invoquer le service par le biais de sa description abstraite (méthodes disponibles,
paramètres d’entrée et sortie) et concrète (description des protocoles de communication et des
points d’accès du service).

§ STRUCTURE D’UN DOCUMENT WSDL

Document WSDL 1.1 :

Composé d’une racine contenante 5 élément obligatoire :

elt racine : <definition> utilisé pour la déclaration des espaces de noms

<types>définit les structures de données (tableau, string) +nbre d’elt dans la balise </types>
Niveau abstrait <message>définit les types de messages et les données transmises </message>
<portType>définit l’ensemble des opérations proposées</portType>
<binding>définit les protocoles de communication et les spécifications assurées par SOAP
</binding>
Niveau Concret <service>décrit la collection de port d’accès du service(localisation par URI) </service>
</definition>
Obligation : Pour bien comprendre les détails par des exemples voir pages : 228 – 239
Document WSDL 2.0 :

L’élément interface: Cet élément décrit l’ensemble des fonctionnalités, appelées opérations(simple interaction
entre le client et le service), fournies par le service web .

les messages sont définis au niveau de l’opération et sont de deux types : soit des messages que le service
reçoit (sous- élément input), soit des messages que le service envoie au client (sous- élément output)

Obligation : Pour bien comprendre les détails par des exemples voir pages : 243 – 250

§ Comparaison entre la structure des documents wsdl 1.1 et la structure des documents wsdl 2.0 :

Points communes : types, binding, service

Points de différentiations:
o niveau structurel du langage ; la description des messages échangés entre le client et le service lors de
l’appel des opérations.
§ WSDL 1.1 : la description des messages : <message>…</message>
§ WSDL 2.0 : la description des messages :
<interface><operation>…</operation></interface>è+lisibilité
o niveau d’extensibilité du langage :
§ WSDL 1.1 : pas d’extensibilité
§ WSDL 2.0 :la possibilité d’ajouter des informations utiles
 § La couche de découverte et de publication UDDI (Universal Description Discovery and Integration
Registry)

o UDDI (Universal Description, Discovery and Integration) est une spécification d’annuaires de services
web.
o formalisées en XML
o elles proposent 3 types d’informations :
pages blanches : contenant noms, adresses, identifiants et contacts des entreprises enregistrées
décrits dans une entité : Business Entity
pages jaunes : détails sur le métier des entreprises et les services qu’elles proposent, décrites dans
une entité : Business Service
page verte : informations techniques sur les services ,processus métier, l’URL du WSDL de service

Deux types d’annuaires UDDI:

Annuaire UDDI publique :implémenté sous forme de nœuds UDDI, telles que SAP, IBM, Microsoft, La
publication d’un service chez une entreprise propage automatiquement ses informations (pages blanches,
jaunes et vertes) aux différents nœuds UDDI. L’accès à l’ensemble des informations des registres peut se faire
à n’importe quel nœud UDDI. Ce type d’annuaire est gratuit.

Annuaire UDDI privé : permet à une entreprise de choisir les partenaires pour lesquels elle autorise la
publication et l'invocation de ses services web.

La partie pages blanches : est constituée de deux éléments <businessEntity> et <Publisher Assertion>.
• <businessEntity> donne des informations de contact sur l’organisation fournissant les services
• <Publisher Assertion> spécifie les liens d’affiliation entre deux entreprises (mère et fille)
La partie pages jaunes : est constituée des éléments <business Service>.
• <business Service> décrit un ensemble de services fournis par une organisation (le nom du service, la
description textuelle, les informations de classification).
Un <business Service> est un sous élément de <businessEntity>.
La partie pages vertes : est constituée des éléments <bindingTemplate> et <tModel>.
• <bindingTemplate> spécifie des informations techniques, telles que l’URI du service. Un
<bindingTemplate> est un sous élément de <business Service>.
• <tModel> définit des structures d’informations techniques telles que l’interface WSDL, les taxonomies
industrielles, les ontologies, etc. Un élément <tModel> peut être réutilisé par plusieurs éléments
<bindingTemplate>.
Le protocole d'utilisation de l'UDDI offre trois fonctions de base :
• publish : permet de publier un nouveau service.
• find : permet d'interroger l'annuaire UDDI.
• bind : permet d'établir une connexion entre l'application cliente et le service.