Architecture SOA

et Services Web
Auditoire :
3ème année Licence Génie Logiciel et Système d’information

Enseignante :
Dr. Ghada Feki
Maitre Assistante à la Faculté des Sciences de Monastir
Email : [Link]@[Link]
Plan
• Chapitre 1 : Introduction
• Chapitre 2 : Les Services
• Chapitre 3 : Web Services SOAP
• Chapitre 4 : Web Services REST

2
Chapitre 1 : Introduction

3
Problématique
Besoin de communication,
d’échange entre ces
applications et d’intégration
Un système d'information de nouvelles applications
d'entreprise est un généralement hétérogènes.
assemblage d'applications
indépendantes.

4
Problématique
Parmi les solutions existantes pour faire communiquer ces applications
indépendantes, et intégrer de nouvelles applications, on trouve:
• L’approche spaghetti: une communication point à point

5
Problématique
• L’EAI (Enterprise Application Integration) : Réunir les différents
programmes d'une organisation au sein d'un même espace. Elle
vient remplacer l’approche spaghetti et alléger l’architecture
d’interconnexion en mettant à la disposition des applications un
nœud centrale de communication.

6
Problématique
Limites de ces solutions :
• Développement coûteux
• Interconnexions redondantes
• Grande complexité
• Réutilisation et maintenance difficile

7
Solution
Naissance de la notion des services Web qui:
• Garantit L’interopérabilité
• Fait interagir des composants hétérogènes, distants, et
indépendants
• Simplifie la communication entre ces composants
• Se base sur des technologies qui existent déjà (XML, HTTP)

8
Définitions
• Service: « Un service est un comportement défini par contrat, qui
peut être réalisé et fourni par tout composant pour être utilisé par
tout composant sur la base unique du contrat. »

9
Définitions
• Service Web : entité logicielle mise à disposition sur l’internet ou sur
un réseau privé, publiable et accessible en utilisant le langage XML et
les protocoles standards du web. Elle est indépendante du système
d’exploitation et du langage de programmation.

• Architecture SOA (Service-Oriented Architecture) : modèle de

conception qui rend des composants logiciels réutilisables, grâce à
des interfaces de services qui utilisent un langage commun pour
communiquer via un réseau.

10
Avantages
• Mise sur le marché accélérée et plus grande flexibilité : le caractère
réutilisable des services facilite et accélère le regroupement des
applications. Les développeurs ne doivent plus repartir de zéro à
chaque fois, comme c'est le cas pour les applications monolithiques.
• Utilisation de l'infrastructure existante sur les nouveaux marchés :
grâce à l'architecture SOA, les développeurs peuvent plus facilement
étendre et mettre à l'échelle les fonctionnalités d'une plateforme ou
d'un environnement.
• Coûts réduits grâce à une meilleure agilité et à un développement
plus efficace.

11
Avantages
• Maintenance facilitée : les services étant autonomes et indépendants,
ils peuvent être modifiés et mis à jour autant que nécessaire, sans
affecter les autres services.
• Évolutivité : comme l'architecture SOA s'adapte à plusieurs services,
plateformes et langages de programmation, l'évolutivité est
considérablement accrue.
• Fiabilité améliorée : il est plus facile de déboguer des petits services
plutôt qu'un long code, ce qui permet de créer des applications plus
fiables.
• Grande disponibilité : les fonctions de l'architecture SOA sont à la
portée de tous.
12
Inconvénients
• Assez coûteuse en termes de main-d'œuvre : Plusieurs équipes
d'unités informatiques et de développeurs sont nécessaires pour
configurer et gérer chaque code de service. Bien que ce coût soit
principalement supporté par les prestataires de services tiers, il peut
en fin de compte se traduire par des coûts financiers pour l'entreprise
et ses clients.

13
Inconvénients
• Surcharge du trafic de données : Dans le cadre des protocoles de
sécurité, les commandes et les entrées doivent être vérifiées avant
d'être transférées au tiers. À mesure que le nombre de services sur
une architecture SOA augmente, le nombre d'entrées et de codes de
vérification pour ces entrées augmente également. La quantité
supplémentaire de trafic de données chargera votre système.
• Besoin en ressources plus élevé : L'élément d'une charge de données
plus élevée nécessite une bande passante plus importante pour
garantir que la vitesse du réseau est suffisante pour assurer la
satisfaction du client.

14
Top Business utilisant SOA
• Hôtels qui externalisent les services de blanchisserie et de restauration
• Entreprises géantes utilisant des fournisseurs de services tiers
• Tout site Web utilisant PayPal ou d'autres services de paiement
• Site de vente utilisant un service de livraison en ligne
• Un magasin de médias / livres utilisant iTunes, Amazon ou d'autres
systèmes de vente
• Le système de réservation de la SNCF (recherche d'horaire, demande de
tarif, réservation…) prend en charge à la fois les terminaux des guichets des
agences et gares, et les sollicitations de son site web de commande en
ligne
15
Exemple

16
Concepts d’une architecture SOA
• Un service web est une composante web qui possède une interface
lui permettant la communication.

• Une interface est un ensemble de fonctions qu’on peut les invoquer

suivant une spécification bien définie.

• Un service est conçu/développé par un fournisseur et consommé par

un consommateur.

17
Acteurs d’une architecture SOA
• Le fournisseur de service (Service Provider) : Application s'exécutant
sur un serveur et comportant un module logiciel accessible par
Internet en XML.

• Le client (Service Requester) : Application cliente se liant à un service

et invoquant ses fonctions par des messages XML (SOAP).

• L’annuaire de services (Service Registery) : Annuaire des services

publiés par les providers (UDDI).

18
Acteurs d’une architecture SOA
• 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.
• Le fournisseur publie son service dans un registre de services.
• Le consommateur cherche la disponibilité d’un service particulier
dans ce registre.
• Pour invoquer un service, le consommateur doit respecter la
spécification du service (ou aussi dit son contrat).

19
Fonctionnement
Le fournisseur de service (Service Provider ) est chargé de :

1) Définir le service: implémentation,

description, contrat d'utilisation.

2) Publier sa description dans

l’annuaire

3) Réaliser les opérations

20
 Fonctionnement
L’annuaire (Entrepôt) (Discovery Agency) est chargé de :

1) Recevoir et enregistrer les

descriptions de services
publiées par les fournisseurs

2) Recevoir et répondre
aux recherches de services
lancées par les clients
21
Fonctionnement
Le client (Service Requestor) est chargé de :

1) Lancer la recherche sur un

service approprié.

2) Obtenir la description du
service grâce à l’annuaire.

3) Utiliser le service
22
SOA vs Programmation distribuée et POO
Caractéristiques de la programmation orientée objets
• La programmation orientée objets est basée sur le principe
d’encapsulation d’un ensemble d’informations dans un objet doté
d’un ensemble de méthodes permettant la manipulation de ses
informations.

• Ce style de programmation à un grand avantage surtout du côté

séparation du code ce qui facilite largement les taches suivantes du
développement du logiciel.

23
SOA vs Programmation distribuée et POO
Caractéristiques de la programmation orientée objets
Limites de cette architecture :
1. Structure et architecture de l’application peu visible.
2. Interactions entre objets enfouies dans le code.
3. Évolution / modification difficile.
4. Gestion de la consistance d’un changement délicate
5. Granularité encore trop fine: ce qui la rend mal adaptée à la
programmation à grande échelle.
6. Couplage fort: ce qui rend difficile la réutilisation et accroît la
complexité des Systèmes Orientés Objet.
24
SOA vs Programmation distribuée et POO
Caractéristiques des applications distribuées (orientées composants)
Une application distribuée est formée d’un ensemble de composants
logiciels qui :
1) Collaborent pour l’exécution de tâches communes
2) Distants géographiquement
3) Interconnectés via un réseau de communication
4) Hétérogènes
5) Solutions qui ont fait leur preuve: DCOM, CORBA, EJB, RMI, .Net, …

25
SOA vs Programmation distribuée et POO
Caractéristiques des applications distribuées (orientées composants)
Les faiblesses de ces solutions peuvent être résumées dans :
1) Format de représentation de données spécifiques
2) Interopérabilité uniquement si les composants utilisent la même
solution
3) Parfois elle utilise des protocoles de transport spécifiques ce qui
nécessite une configuration spécifique du réseau.
4) Couplage fort : phénomène du plat de spaghetti

26
SOA vs Programmation distribuée et POO
Architecture orientée service
1) Elle partage l’aspect modulaire (ensemble de fonctionnalités qui font
sens) avec la programmation orientée objets.
2) Elle partage les caractéristiques suivantes d’un composant
(application distribuée) :
• Boite noire (séparation interface/implémentation)
• Indépendant de la localisation
• Neutralité vis-à-vis des protocoles de transport

27
SOA vs Programmation distribuée et POO
Architecture orientée service
3) Correspond à un périmètre fonctionnel que l’on souhaite exposer à
des consommateurs.
4) Services faiblement couplés (indépendant des autres services).
5) Expose un petit nombre d’opérations offrant un traitement de bout
en bout.
6) Utilisation de standards.
7) Pas de remise en cause de l’existant lors d’évolutions technologiques
8) Découplage entre fournisseur et consommateur de services.

28
 Niveau d’abstraction grandissant

Programmation Orientée Services

Programmation Orientée Composants

Programmation Orientée Objets

Programmation Procédurale

29
Approches de SOA
Deux approches sont définies pour implémenter l’architecture SOA :
• Bottom-Up : Son principe est de commencer par un petit groupe et
ajouter 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.

30
Approches de SOA

31
Bilan SOA - Avantages
1. Accès à distance via un navigateur Web.
2. Pas de logiciel sur le poste client.
3. Possibilité d'interagir par n'importe quel appareil connecté à Internet.
4. Compatibilité avec différents systèmes d'exploitation et différentes plates-
formes (utilisation des standards).
5. Système d'information flexible (anticiper les évolutions technologiques). Il
suffit de faire évoluer un service ou d'ajouter un nouveau service sans avoir
de perturbations pour les autres services.
6. Réutilisation de code.
7. Une plus grande tolérance aux pannes (maintenance facile).

32
Bilan SOA - Inconvénients
1. Recentralisation des systèmes (charge très importante sur le serveur).
2. Coûts de conception et de développement initiaux importants à la fois
financier et humain (formation d’une équipe d’experts pour la conception et
des équipes pour l’implémentation et l’administration).
3. Lenteur d'exécution (services asynchrones).
4. Manque de maturité de standards (course à la spécification entre W3C et
OASIS).

33
Chapitre 2 : Les Services

34
Définitions
• Un service est un comportement défini par contrat, qui peut être
réalisé et fourni par tout composant pour être utilisé par tout
composant sur la base unique du contrat.
• Un Service est un composant logiciel distribué, exposant les
fonctionnalités à forte valeur ajoutée d’un domaine métier.
• Les aspects d’un service sont : le contrat standardisé, le couplage
lâche, l’abstraction, la réutilisabilité, l’autonomie, sans état,
découvrabilité, et composabilité.

35
Les aspects d’un service
Un service est un composant logiciel distribué satisfaisant les huit
aspects (caractéristiques) suivants :
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).
36
Les aspects d’un service
Contrat Standardisé
L’ensemble des services d’un même Système Technique sont exposés
au travers de contrats respectant les mêmes règles de standardisation.

Qu’est-ce qu’un contrat de service ?

37
Les aspects d’un service
Contrat Standardisé
Le contrat de service définit un accord entre le fournisseur et le
consommateur. Il est composé :
• D’un contrat syntaxique qui propose une représentation technique
du service : Il constitue le contrat d’utilisation du service (son
interface). Il présente le nom du traitement, ses paramètres d’entrée
et de sortie et les contraintes structurelles (format et contrainte sur
les données) qui s’y appliquent.

38
Les aspects d’un service
Contrat Standardisé
• D’un contrat sémantique qui fournit une description informelle du
traitement : Il précise les règles et contraintes d’utilisation du service :
La valorisation des messages de réponse; Les exceptions; les pré-
conditions et post-conditions techniques ou métiers.
• D’un contrat de niveau de service (QoS et SLA) qui précise les
engagements du service : Il spécifie par exemple le temps de réponse
maximum attendu, les plages horaires d’accessibilité, le temps de
reprise après interruption, les procédures mises en œuvre en cas de
panne, les procédures de prise en charge du support, …

QoS : Quality of service

SLA : Service Level Agreement

39
Les aspects d’un service
Contrat Standardisé
Exemple :
Pour un service web (service implémenté sous forme de web service),
son contrat peut être formé comme suit :
• Un document WSDL décrivant l’interface du service (les modalités
d’accès), ceci fait partie du contrat syntaxique.
• Un ensemble de « policies » qui définissent les règles d’utilisation du
service :
o Les policies font parties du contrat sémantique. Les règles et
contraintes qu’elles expriment adressent des domaines variés :
Sécurité, encodage, langue, versioning, métiers, …
40
Les aspects d’un service
Contrat Standardisé
• Un ensemble de schémas XML (XSD) qui définissent les types de
données échangées par le service :
o Les XSD font partie du contrat syntaxique. Elles définissent les
formats de données et les contraintes structurelles.
o Les XSD font également partie du contrat sémantique. En effet, la
richesse des types et restrictions XSD permet d’auto-documenter
les valeurs possibles et permet souvent d’éviter des confusions.

XML : Extensible Markup Language

XSD : XML Schema Definition

41
Les aspects d’un service
Contrat Standardisé
• Documentations complémentaires.
o Ces documentations complètent le contrat sémantique. C’est par
exemple dans les spécifications que l’on décrira les prés et post
condition d’utilisation du service.
o Ces documentations constituent le contrat de niveau de service
(QoS & SLA). Notons que l’on parle bien d’un contrat qui définit
un ensemble d’indicateurs et de valeurs seuils.

42
Les aspects d’un service
Contrat Standardisé
Standardisation du contrat :
Le contrat de service est donc une notion complexe qui ne se limite pas
à la (simple) définition d’interfaces. Un contrat de service est constitué
de nombreux éléments (techniques ou non) qui forment un fond
documentaire pour lequel il est préférable (voire indispensable) de
respecter un formalisme commun. L’utilisation de ce formalisme
commun est le meilleur moyen de construire un modèle cohérent et
donc facile à comprendre et à partager.

43
Les aspects d’un service
Contrat Standardisé
En plus de cadrer la définition des contrats (et donc de faciliter la
communication), l’utilisation d’un formalisme commun et de règles de
standardisation facilite la centralisation des éléments constituant les
contrats. Cette centralisation encourage la réutilisation.
Parmi les constituants d’un contrat de service, les règles d’utilisation
(policies) et les formats des données (XSD) sont des bons candidats à la
réutilisation vu qu’on général les mêmes règles d’utilisations et les
mêmes structures de données sont partagées entre les services dans
un seul système.
Il est indispensable ainsi de séparer les différents éléments du contrat
de service afin de permettre leur réutilisation.

44
Les aspects d’un service
Couplage lâche
• L’objectif de la SOA est de permettre aux entreprises de s’adapter en
permanence et être de plus en plus réactives aux variations des
marchés et aux avancements technologiques.
• Il est primordial d’éviter les chausse-trappes des grands projets
d’architectures distribuées ou intégrées, et en particulier le couplage
technique et fonctionnel entre consommateurs et fournisseurs de
services.

45
Les aspects d’un service
Couplage lâche
• Le couplage technique : impose au consommateur de connaître le
protocole d’échange du fournisseur. À grande échelle, un tel couplage
complique, voire interdit l’évolution du socle technique, et risque de
figer le SI dans une inertie sclérosante.
• Le couplage fonctionnel : impose au client de connaître le format
d’échange du fournisseur. Ainsi toute évolution du fournisseur a un
impact potentiel sur chacun de ses consommateurs. Mal gérée, cette
dépendance peut conduire à de véritables verrous fonctionnels dans
le Système d’Informations – interdisant toute évolution ou, plus
sûrement, augmentant de façon exponentielle le coût de ces
évolutions.

46
Les aspects d’un service
Couplage lâche
La question qui se pose :
Comment garantir Sachant que :
l’indépendance entre le
consommateur (Interface client) La logique d’un service est
et le Fournisseur (Service) ? fortement liée à son
environnement d’implémentation

Examinons tout d’abord la nature

de dépendances qui existent :

47
Les aspects d’un service
Couplage lâche
• La logique d’un service est directement dépendante de son
implémentation (1). Cette implémentation s’appuie sur un ensemble
de ressources qui constituent l’environnement d’implémentation du
service. La logique d’un service est donc couplée à ces ressources.
• De la même façon, la logique d’un service est fortement liée aux
technologies sur lesquelles son implémentation s’appuie (2).
• D’autre part, dans le cadre de services composites, la logique d’un
service est également dépendante des services qui le composent (3).
• Enfin, le contrat de service ainsi que sa logique peuvent être couplés
aux processus qui les utilisent (4).
48
 Les aspects d’un service
Couplage lâche
Ces couplages sont inévitables.

Du côté consommateur, celui-ci est lié

directement avec le service à travers son contrat.

C’est le quatrième type de couplage (Couplage

Service/Contrat) qu’il faut réduire afin de permettre
un découplage entre le consommateur et le service.

1. Couplage du contrat de service

Le contrat d’un service et sa logique peuvent être
vers la logique d’implémentation
du service.
couplés de deux façons différentes.
2. Couplage de la logique du service
au contrat. 49
Les aspects d’un service
Couplage lâche
• Couplage du contrat de service vers la logique d’implémentation du
service :
Un tel couplage résulte d’une approche Contract last lors du design du
service (le contrat dérive de l’implémentation). Cette approche est à
exclure car elle induit un couplage du contrat avec l’environnement du
service.
• Couplage de la logique du service au contrat :
Ce couplage dénote une approche Contract first dans la conception du
service (le contrat est écrit préalablement à l’implémentation du
service). Cette approche est toujours préférable et le couplage du
service vers son contrat est considéré comme un couplage positif.
50
Les aspects d’un service
Couplage lâche
Ainsi il faut établir la dépendance dans le bon sens :
• 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.
• Or, si le contrat est couplé avec la logique du service, le
consommateur va hériter par transitivité de l’ensemble des
dépendances de la logique du service avec son environnement. Nous
nous retrouvons donc avec un consommateur qui est fortement
couplé au service (Couplage Fort).

51
Les aspects d’un service
Abstraction
• Le principe d’abstraction consiste à fournir les services du SI sur un
modèle boîte noire, or les seules informations fournies au
consommateur sont celles contenues dans son contrat, ainsi il est
quasiment indispensable de n’y mettre que les informations
essentielles à son invocation.
• Il est souvent inutile de fournir les informations complètes sur les
détails d’implémentation du service, le fournisseur du service peut
permettre un accès contrôlé à ce genre de détails à des concepteurs
particuliers de consommateurs.
• Cependant cette restriction d’accès aux informations du service ne
doit pas violer le principe de la prédictibilité du service.

52
Les aspects d’un service
Abstraction
Prédictibilité du service :
• La prédictibilité d’un service signifie que son comportement et la
réponse qu’il donne suite à une requête ne doivent pas varier (suite à
une concurrence d’accès par exemple).
• Ce principe est induit par le respect du contrat du service.
• Ainsi le principe de l’abstraction de service signifie qu’il faut mettre
dans le contrat du service toutes et uniquement les informations
nécessaires et suffisantes à son invocation.

53
Les aspects d’un service
Réutilisabilité
• La réutilisabilité des services (et plus largement des ressources du SI)
constitue une des pierres angulaires de la mise en œuvre d’une
architecture orientée service. En effet, la mise en œuvre d’une
architecture SOA vise, entre autres, à éviter le gaspillage des
ressources en éliminant les redondances. D’autre part, la réutilisation
est une condition première de l’agilisation du SI indispensable à la
réduction du time-to-market.

54
Les aspects d’un service
Réutilisabilité
• La réutilisabilité d’un service désigne la capacité du service à
répondre aux besoins de plusieurs types de consommateurs (est-ce
que plusieurs consommateurs vont utiliser ce service ?).
• Les services identifiés comme réutilisables sont ainsi mis à la
disposition d’un large spectre de services composites, de processus,
d’applications, … Au fil du temps, de tels services ont donc vocation à
prendre part à un nombre croissant de compositions,
d’orchestrations, de workflow, …

55
Les aspects d’un service
Réutilisabilité
En effet les principaux freins qui peuvent influencer mal sur le degré de
réutilisation de service sont :
1. La centralisation et la standardisation des ressources :
La centralisation des contrats de service garantit qu’un consommateur
n’a accès au service que par son contrat, et la centralisation de la
logique métier permet d’obtenir un inventaire de services hautement
normalisé. La standardisation de cet inventaire est essentielle pour
maximiser la réutilisabilité des services disponibles au sein de
l’entreprise.

56
Les aspects d’un service
Réutilisabilité
2. La démarche suivie dans la conception de service :
• Le processus de conception « Bottom-up » : un service émerge
d’une démarche « Push » initiée par un fournisseur ou « Pull »
initiée par un consommateur. Selon l’initiateur de cette démarche
(fournisseur ou client), le résultat de ce processus est un service plus
générique (Push) qui essaye de répondre aux besoins de tous les
partenaires (risque d’être sans valeur ajoutée métier), ou bien un
service qui répond au besoin d’un client particulier sans forcément
prendre en compte des perspectives de réutilisation du service. Cela
s’explique par le fait que ce genre de demande se conjugue
généralement avec des impératifs « Time To market » imposés par le
client du service. 57
Les aspects d’un service
Réutilisabilité
• Un processus de conception « Top-down » : le service est le résultat
d’une étude plus globale et systémique du SI ou d’un bloc du SI. Cette
démarche garantit une cohérence globale de l’ensemble des services,
néanmoins, sa mise en place s’avère un challenge difficile dont les
bénéfices sont loin d’être acquis.
Push

Bottom-up

Pull
Quelle démarche
favoriser donc ?
Top-down

58
 Les aspects d’un service
Réutilisabilité
• Il n’y a pas de démarche à favoriser en particulier.
• Les 3 peuvent coexister selon le contexte et l’offre de services existants.
Néanmoins, en phase de conception et de mise en œuvre du service, il est
primordial de prendre en considération les points suivants:
• Favoriser une démarche itérative et collaborative entre clients et
fournisseurs de services.
• Penser un service donné en tant qu’offre de services, plutôt qu’un
mono-service qui essaie de répondre à tous les besoins.
• Ne pas considérer l’étude d’urbanisation, s’il y en avait une, comme une
cible en elle-même, mais plutôt comme un fil conducteur pour la cible.
59
 Les aspects d’un service
Réutilisabilité
3. La granularité de service :
• La granularité d’un service est définie par le nombre de fonctions
recouvertes par celui-ci. En effet ce facteur est très critique, et une
mauvaise granularité du service va surement limiter son réutilisation.
• On parle de mauvaise granularité de service lorsque celui-ci couvre trop ou
trop peu de fonctionnalités :
• Un service qui fait trop de choses causera des mauvaises performances
et risquerait d’être moins réutilisable à cause des fonctionnalités non
utiles pour le consommateur.
• Un service qui fait trop peu de choses sera sans valeurs ajoutée métier
et risque d’être non réutilisable de son besoin à collaborer avec
d’autres services pour répondre aux besoins du consommateur. 60
Les aspects d’un service
Autonomie
• L’autonomie de service signifie que le service n’a pas besoin à d’autres
services pour accomplir sa tâche (il est indépendant des autres), et
par conséquent ça implique que le comportement d’un service ne
dépend pas du contexte dans lequel il est invoqué (contexte
fonctionnel ou contexte technique).
• Afin qu’un service s’acquitte au mieux de ses engagements
(comportement, fiabilité, performances, …), il doit exercer un contrôle
fort sur son environnement d’exécution sous-jacent. Plus ce contrôle
est fort, plus l’exécution d’un service est prédictible.

61
Les aspects d’un service
Autonomie
• Ainsi c’est au moment de la décomposition des fonctions du SI en
inventaire de services, qu’il faut définir les membres de ce registre
comme des blocs indépendants. C’est donc un haut niveau
d’autonomie individuelle des services qui est visé. 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é des services à fonctionner de façon
autonome.

62
Les aspects d’un service
Autonomie
Cependant il est quasiment impossible de satisfaire cette
caractéristique pour l’ensemble des services, c’est pour cela qu’on a fait
introduire deux niveaux basiques d’autonomie :
• Autonomie de niveau de service : Les frontières des services entrants
dans cette catégorie sont clairement définies et les services sont
indépendants les uns des autres, mais il se peut que ces services
partagent encore certaines ressources sur lesquelles ils s’appuient.

63
Les aspects d’un service
Autonomie
• Autonomie pure : La logique sous-jacente au service et les ressources
qu’il utilise sont la propriété du service et sous son contrôle exclusif.
C’est le niveau d’autonomie que l’on pourra atteindre lors de la
création de « nouveaux » services quand la logique sous-jacente est
construite spécifiquement pour supporter le service. Cependant ceci
reste un objectif difficilement atteignable au sein d’un système déjà
existant et avec lequel il faut vivre pendant longtemps.

64
Les aspects d’un service
Sans état (Stateless)
Un service doit minimiser la consommation de ressources en déléguant
la gestion des informations d’état quand cela est nécessaire. D’une
manière plus générale, la gestion d’états (d’informations de contexte)
au sein d’un service pose des problèmes :
• De compréhension et de maintenabilité
• De réutilisation
• De performances

65
Les aspects d’un service
Sans état (Stateless)
• De compréhension et de maintenabilité : La gestion d’états va
sensiblement augmenter la complexité de l’implémentation et donc
rendre difficile sa lecture, sa documentation, sa testabilité, … Dans le
cadre d’une composition de services, la complexité du composé étant
directement liée à celle de ses composants, la complexité des services
de plus haut niveau peut donc rapidement devenir ingérable.

66
Les aspects d’un service
Sans état (Stateless)
• De réutilisation : La gestion d’états au sein du service brouille la
lisibilité de son contrat puisque l’adaptation de son comportement en
fonction de son état ne transparaît pas dans son contrat. Or la
lisibilité et la transparence des contrats de service sont des facteurs
clés de la réutilisation des services. D’autre part, l’utilisation d’états au
sein d’un service présuppose souvent l’utilisation de ce service au
sein d’un enchaînement d’invocations défini à l’avance. Il sera donc
difficile de réutiliser le service au sein d’une autre orchestration ou
composition.

67
Les aspects d’un service
Sans état (Stateless)
• De performances : car la gestion des états est consommatrice de
ressources systèmes, notamment en terme de stockage de ces états
(en mémoire ou sur disque).
On préférera donc la conception et l’implémentation de services sans
état. La responsabilité de la gestion d’états sera alors déléguée aux
utilisateurs (consommateurs) des services : compositions,
orchestrations, processus, …

68
Les aspects d’un service
Découvrabilité
Un service est complété par un ensemble de métas-données de communication au
travers desquelles il peut être découvert et interprété de façon effective.
Cette découvrabilité des services existants passe par la mise en œuvre d’un
repository de services qui vient outiller l’inventaire des services disponibles. Ce
repository stocke l’ensemble des métadonnées nécessaires à :
• La recherche des services de l’inventaire.
• La récupération de l’ensemble des artefacts relatifs aux services de l’inventaire
(Spécifications, SLAs, Policies, Schémas XML, WSDL, Interfaces, …).

69
Les aspects d’un service
Découvrabilité
Le concepteur d’un consommateur de service (Service composé,
application composite, orchestration, processus, …) pourra s’appuyer
sur ce repository de la façon suivante :
• Le concepteur recherche dans le repository un service possédant les
fonctionnalités dont il a besoin (1).
• En se basant sur les métadonnées contenues dans le repository, le
concepteur est capable de découvrir et d’identifier un service
potentiellement capable de répondre à ces besoins (2).
• Le concepteur peut alors accéder au contrat du service : syntaxique,
sémantique et de niveau de service (3).
70
Les aspects d’un service
Composabilité
Un service doit être conçu de façon à participer à des compositions de
services.
Ce dernier aspect constitue en quelque sorte l’aboutissement des sept
précédents. En effet, l’ensemble des principes présentés dans cette
série vise à la réutilisation des services. Or, cette réutilisabilité n’a de
sens que si les services sont effectivement réutilisés en prenant part à
des compositions de services.

71
Les aspects d’un service
Composabilité
C’est grâce à la composabilité que sera mis en œuvre le principe de «
separation of concerns » au sein d’une architecture orientée services.
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.
L’idée est de pouvoir recomposer notre logique métier à l’infini au sein
de processus ou de services composites de haut niveau.

72
Les aspects d’un service
Composabilité
La mise en œuvre de cet aspect dans une architecture de services pose
donc le problème du bon niveau de granularité pour un service :
• Un service trop large ne pourra pas être réutilisé, car il implémente
un enchainement de traitements qui n’ont, a priori, de sens que dans
le contexte où le service a été écrit. Un service trop large n’est
utilisable que par une seule (ou quelques) application(s).
• A l’opposé, un service trop fin ne sera pas réutilisé, car il implémente
un traitement atomique qui n’apporte pas de valeur ajoutée. Un
service trop fin propose un niveau de détail qui n’est pas pertinent
d’un point de vue métier.

73
Les aspects d’un service
Un service est un composant logiciel distribué satisfaisant les huit
aspects (caractéristiques) suivants :
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).
74
Les applications des services Web
Les technologies des services Web peuvent être appliquées à toutes
sortes d’applications auxquelles elles offrent des avantages
considérables en comparaison aux anciennes API propriétaires, aux
implémentations spécifiques à une plate-forme et à quelques autres
restrictions classiques que l’on peut rencontrer (multiplateforme, multi-
langage, disponible sur Internet avec une information actualisée
disponible en temps réel, ...).

75
Les applications des services Web
L’application des services Web est multiple, autant dans les domaines
du B2C, B2B que pour des domaines de gestion, par exemple gestion
de stock, gestion commerciale, etc...
• 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.

76
Applications des Services Web en B2B
(Business-to-Business)
• les services web sont principalement utilisés pour automatiser et
fluidifier les processus métier entre entreprises partenaires.
• L'accent est mis sur l'intégration, l'automatisation et l'efficacité.

77
B2B Applications Concrètes
Intégration de la Chaîne Logistique (Supply Chain)
• Exemple : Un fabricant (ex: Renault) connecte son système de gestion
des stocks (ERP) à ceux de ses fournisseurs de pièces détachées via
des services web. Quand le stock d'un composant est bas, le système
de Renault commande automatiquement auprès du fournisseur, qui
reçoit la commande directement dans son propre système.
• Avantage : Réduction des stocks, livraison juste-à-temps, moins
d'erreurs humaines.

78
Paiements et Facturation Électronique (E-invoicing)
• Exemple : Une entreprise utilise un service web comme PayPal for
Business pour intégrer la facturation dans son logiciel de
comptabilité. Les factures sont générées, envoyées et les paiements
sont enregistrés automatiquement.
• Avantage : Automatisation de la trésorerie, réduction des retards de
paiement.

79
Services Financiers et Bancaires
• Exemple : Une application de gestion financière (comme QuickBooks)
se connecte via des API (services web) aux comptes bancaires de
l'entreprise pour récupérer automatiquement les transactions et les
catégoriser.
• Avantage : Vue financière en temps réel, comptabilité simplifiée.

80
Logiciel en tant que Service (SaaS) et Interopérabilité
• Exemple : Une entreprise utilise Salesforce (CRM) qui est connectée
via des API à son outil de marketing Mailchimp et à son ERP SAP.
Quand un nouveau lead est qualifié dans Salesforce, il est
automatiquement ajouté à une campagne Mailchimp et créé comme
client potentiel dans SAP.
• Avantage : Écosystème logiciel cohérent et données synchronisées.

81
Réservation et Logistique
• Exemple : Un site de voyage d'affaires se connecte via des services
web aux systèmes de réservation (GDS) des compagnies aériennes et
des chaînes hôtelières pour afficher la disponibilité et les prix en
temps réel.
• Avantage : Accès à un inventaire global, processus de réservation
simplifié.

82
Applications des Services Web en B2C
(Business-to-Consumer)
• les services web sont la colonne vertébrale de l'expérience utilisateur
directe.
• Ils sont utilisés pour fournir des services rapides, personnalisés et
engageants aux consommateurs finaux.

83
B2C Applications Concrètes
E-commerce et Retail
• Exemple : L'application Amazon fait appel à des dizaines de services
web en arrière-plan : pour afficher les recommandations de produits,
vérifier la disponibilité en stock, calculer les frais de port, et traiter le
paiement via son service Amazon Pay.
• Avantage : Expérience d'achat fluide, personnalisée et sécurisée.

84
Réseaux Sociaux et Partage de Contenu
• Exemple : Quand vous voyez un tweet de Twitter intégré dans un
article de presse, c'est un service web de l'API Twitter qui fournit ce
contenu. De même, se connecter à un site via son compte
Facebook/Google utilise des services web d'authentification (OAuth).
• Avantage : Intégration et partage de contenu sans friction.

85
Services de Cartographie et de Géolocalisation
• Exemple : Uber utilise les API de Google Maps pour afficher la carte,
calculer l'itinéraire optimal et estimer le temps de trajet. L'application
de météo sur votre smartphone utilise un service web pour obtenir
les données météorologiques en temps réel.
• Avantage : Fonctionnalités complexes externalisées, développement
plus rapide.

86
Streaming de Médias
• Exemple : Netflix et Spotify utilisent des services web pour vous
recommander des films ou de la musique basés sur votre historique
de visionnage/écoute, gérer votre playlist, et streamer le contenu
depuis le cloud.
• Avantage : Expérience hautement personnalisée et adaptive.

87
Services Bancaires aux Particuliers (Fintech)
• Exemple : Les applications de banque en ligne (ex: Revolut, N26)
utilisent des services web pour toutes leurs opérations : consulter son
solde, effectuer un virement, ou analyser ses dépenses.
• Avantage : Accès 24/7, interface utilisateur moderne et réactive.

88
Google+
B2B et B2C
• C’est le futur carrefour d’influence pour les marques et les entreprises
adeptes du marketing sur les réseaux sociaux. Google Plus offre des
perspectives intéressantes aux professionnels. Par exemple
développer votre marque, travailler en mode collaboratif, organiser
une veille d’informations.
• Tout cela vous permettra de gagner en présence et communication,
présenter votre activité ou entreprise, créer des réseaux internes et
externes à l’entreprise, partage d’information, veille concurrentielle…
• Actions pour l’entreprise : Créer un portfolio, créer des cercles à
vocation professionnels, chat, vidéo conférences, veille
d’informations, réseautage sur mobile lors des déplacements…

89
Twitter
B2B
• Twitter permet d’obtenir des informations brutes, rapides et se tenir au
courant de l’actualité des industries. Twitter va essentiellement regrouper
les personnes qui travaillent dans la publication d’information,
l’évènementiel, la publicité, la veille concurrentielle.
• Twitter est un mégaphone qui permet via quelques mots d’accroître la
popularité et solliciter les foules en temps réel. Idéal pour créer
du trafic autour de l’entreprise.
• Créer une plateforme d’expert : Twitter est un outil d’échanges
d’information. L’entreprise est entourée d’experts afin de bénéficier de leur
savoir-faire.
• Un tweet c’est viral, puisqu’il se transmet ou renvoie “retweet” en un clic.
Donc pour gagner en visibilité, interpeler, les internautes sont motivés de
relayer les messages. Puis créer des liens pour gagner en audience…

90
WordPress
B2B
• WordPress communique des informations sérieuses et fiables sur un
sujet, et permet de donner son avis.
• Ce site (il s’agit de créer des blogs) s’adresse à des clients qui
cherchent à recevoir des informations ou à consulter les services de
l’entreprise qu’ils suivent.
• WordPress est réputé pour ses nombreuses fonctionnalités
permettant à des utilisateurs, avancés ou non, de créer un site
Internet et de le personnaliser. Ses fonctionnalités sont conçues afin
de faciliter au maximum l'activité de publication et de la rendre
accessible à tous.

91
Viadeo et LinkedIn
B2B
• Viadeo et LinkedIn permettent de construire un réseau solide de
votre activité. Les deux réseaux permettent de cibler, respectivement
à l’échelle française et internationale.
• Ces réseaux du B2B sont des portails très intéressants qui
communiquent entre le monde de l’emploi des formations et de
l’entreprise. Ils sont des plateformes d’échange entre candidats,
étudiants, entreprises, recruteurs.

92
Facebook et Myspace
B2C
• Facebook et Myspace sont des réseaux sociaux.
• Ces sites sont majoritairement utilisés pour rester en contact avec des
amis ou fans, pour communiquer, partager des photos, des liens ou
des vidéos ou encore échanger des informations sur divers centres
d’intérêt.

93
Types de Services Web
L’architecture fonctionnelle des services web utilise plusieurs langages et
protocoles durant le déploiement et l’invocation des services web. Les
services web se basent sur l’utilisation des normes actuelles d'Internet
comme le protocole HTTP.

Types de Services Web sont :

• SOAP

• REST

• gRPC

94
QCM
• 20 questions
• Lien :
[Link]
ESxZ1nviW2rBk3E4/prefill

95
Vidéo
• [Link]
• [Link]
• [Link]

96
Discussion

97
Chapitre 3 : Web Services SOAP

98
Technologies
Annuaire / Entrepôt
UDDI
1. Déploiement
Description
WSDL Service Web

Description
Description
WSDL
WSDL
2. Publication
3. Découverte
SOAP (publier)
(chercher)

4. Invocation Description
Client (consommer)
Fournisseur WSDL

Proxy
Application ESB Web Application
Description
WSDL Service

99
 Technologies
• Contrat / description WSDL (Web Service Description Language) : contient
la 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
dynamique de recherche de descriptions de services dans laquelle les
fournisseurs de services publient leurs descriptions.
• Bus ESB (Enterprise Service Bus) : le moyen par lequel s'effectue la
communication entre le client et le fournisseur du service. Son but est avant
tout de permettre la communication des applications qui à la base ne sont
pas pensées pour fonctionner ensemble.
100
La pile protocolaire simplifiée SOAP WS

Mécanismes fonctionnels Mécanismes non fonctionnels

Découverte / Publication (UDDI)

Description (WSDL)

Transaction
Sécurité

……….
Communication (SOAP)

Transport (HTTP)

101
La pile protocolaire simplifiée SOAP WS

Mécanismes fonctionnels Mécanismes non fonctionnels

Découverte / Publication (UDDI)

Description (WSDL)

Transaction
Sécurité

……….
Communication (SOAP)

Transport (HTTP)

102
La couche de Transport HTTP (Hypertext
Transfer Protocol)
• Cette couche s’intéresse aux protocoles de transport de bas niveau,
ces derniers vont transporter les requêtes et les réponses échangées
entre services. HTTPS est la variante sécurisée de ce protocole.
• Le protocole le plus utilisé et recommandé par le consortium WS-I
(Web Service Interoperability) est l’HTTP, mais d’autres
implémentations peuvent utiliser un autre ensemble de protocoles
tels que : FTP (File Transfer Protocol), JMS (java messagerie services),
SMTP (Simple Mail Transfer Protocol), etc.

103
La couche de Transport HTTP (Hypertext
Transfer Protocol)
Le protocole HTTP, à travers les Cookies, fournit un moyen pour
"marquer" l'agent client de façon suffisamment précise :
• L'application est marquée, puisque c'est dans le container de cette
application que l’information de marquage est stockée.
• L'utilisateur d'une machine multi-utilisateur est marqué, puisque les
informations de marquage sont stockées dans le profil particulier de
cet utilisateur.

104
La couche de Transport HTTP (Hypertext
Transfer Protocol)
Structure Du HTTP :
Notion d’entité : Le HTTP est un protocole destiné à transporter des
entités document. Il est constitué de messages-requêtes (du client au
serveur) et de messages-réponse (du serveur au client). Il implémente
donc parfaitement un paradigme client-serveur en ce sens que :
• Le client (agent utilisateur) est toujours l'initiateur de la requête
(PULL).
• Le serveur est toujours en attente d'un client.

105
La couche de Transport HTTP (Hypertext
Transfer Protocol)
Structure Du HTTP :
Les messages transportent des entités. Le cas le plus fréquent est celui
d'une entité unique. 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).

106
La couche de Transport HTTP (Hypertext
Transfer Protocol)
Structure Du HTTP :
Le protocole admet cependant que plusieurs entités puissent être
transportées par le même message.
C'est le cas du téléchargement de fichiers accompagnant des données
de formulaire, ou de téléchargements multiples.
Dans ce cas, le message doit permettre de séparer proprement les
différentes entités qu'il transporte.

107
 La couche de Transport HTTP (Hypertext
Transfer Protocol)
Construction De La Requête
1. Le libellé de requête : La requête HTTP, comme son nom l'indique est une
demande à un serveur pour qu'il exécute un ordre (principalement d'obtenir
un document). Ces ordres sont symbolisés par des verbes.
Les verbes les plus connus sont :
• 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".
108
La couche de Transport HTTP (Hypertext
Transfer Protocol)
2. La Cible : Elle est représentée par une URL absolue ou relative. Le
serveur est chargé de "consommer" cette cible, la traduire en une
réalité physique tangible (un fichier physique, un exécutable, un
répertoire).
La requête peut informer le serveur d'un certain nombre de
prédispositions de l'agent utilisateur.
Des mécanismes de gestion de préférences, convenues entre le client
et le serveur permettent d'améliorer le service rendu, sans faire appel à
des choix explicites de l'utilisateur.

109
La couche de Transport HTTP (Hypertext
Transfer Protocol)
Ces préférences sont, par exemple :
• 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 suffisamment récente, ou au contraire de
versions plus anciennes.
Les champs de requête sont placés à la suite de la "ligne VERBE" sous la
syntaxe :
NomChamp : [ValeurChamp] LF
L'en-tête doit se terminer par une ligne vide, pour indiquer que ce qui
suit est un corps d'entité (ou que le message est fini).
110
La couche de Transport HTTP (Hypertext
Transfer Protocol)
3. Un corps de requête
• Certains verbes (PUT, POST) supposent très fortement une
transmission de contenu du client vers le serveur.
• Ce contenu pouvant être a priori d'une taille quelconque, il s'agit bien
d'un corps d'entité.
• Dans ce cas, on doit considérer potentiellement une requête comme
étant une transmission d'un document à part entière.
• Le client pousse un document local vers le serveur.

111
La couche de Transport HTTP (Hypertext
Transfer Protocol)
4. Détermination de la longueur du corps d'entité
• Il n'existe pas en HTTP de bloc de fin de message identifiable.
• D'autre part, virtuellement, le corps de l'entité peut contenir n'importe
quelle séquence binaire, y compris une séquence qui pourrait se confondre
avec un tel bloc.
• La question de prévoir la fin du corps d'entité doit être réglée dès l'entête.
• Toute requête portant un contenu d'une certaine longueur doit informer le
serveur de cette longueur. On utilise le champ : Content-Length

112
La couche de Transport HTTP (Hypertext
Transfer Protocol)
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.

113
La couche de Transport HTTP (Hypertext
Transfer Protocol)
• Une requête mono-entité, dans le cas général se construit ainsi :

114
La pile protocolaire simplifiée SOAP WS

Mécanismes fonctionnels Mécanismes non fonctionnels

Découverte / Publication (UDDI)

Description (WSDL)

Transaction
Sécurité

……….
Communication (SOAP)

Transport (HTTP)

115
La couche de Communication SOAP (Simple
Object Access Protocol)
Définition:
• SOAP (Simple Object Access Protocol) 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.
• SOAP définit le cadre général pour l’échange de données structurées en
XML.
• Il permet d’échanger des structures de données complexes en XML avec les
espaces de nom, et la spécification XML Schéma.
• L'atout principal des protocoles SOAP et UDDI ainsi que du langage WSDL
est de se reposer sur le langage XML (eXtensible Markup Language).

116
C’est quoi XML ?

117
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.
• Il apporte à l’architecture des services web l’extensibilité et la
neutralité vis-à-vis des plateformes et des langages de
développement.
• De plus, grâce à la structuration, XML permet la distinction entre les
données des applications et les données des protocoles.

118
Le langage XML (eXtensible Markup Language)
• La technologie des services web a été conçue pour fonctionner dans
des environnements totalement hétérogènes.
• Cependant, l’interopérabilité entre les systèmes hétérogènes
demande des mécanismes puissants de correspondance et de gestion
des types de données des messages entre les différents participants
(clients et fournisseurs).
• C’est une tâche où les schémas de type de données XML s’avèrent
bien adaptés. C’est pour cette raison que la technologie des services
web est essentiellement basée sur XML.

119
Le langage XML (eXtensible Markup Language)
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 qui peut être un document lui-même basé
sur un autre schéma.
• XPath (XML Path Language) : fournit une syntaxe d’expressions
utilisées pour créer des chemins de localisation.

120
Le langage XML (eXtensible Markup Language)
• Espaces de noms : Mécanismes permettant de partitionner les balises
XML (permet d’avoir deux fois le même nom de balise)
Un espace de nom est défini dans n’importe quelle balise par l’attribut
xmlns et par une URI.
Dans un document XML, un espace de noms est identifié par un nom
logique, les balises appartenant à cet espace doivent alors être préfixée
par ce nom logique.
Exemple :
<meta:body xmlns:meta="[Link]

121
Le langage XML (eXtensible Markup Language)
Exemple d’un fichier XML:
<livre>
<titre> le super livre </titre>
<chapitre>
<numero> 1 </numero>
<titre> titre du chapitre 1 </titre>
<contenu> xxxxxxxxx </contenu>
</chapitre>
<chapitre>
…
</chapitre>
</livre>

122
Le langage XML (eXtensible Markup Language)
Deux façons de définir une grammaire XML :
• DTD
• Langage de définition de grammaire XML
• Largement utilisé
• Expression faible (type, structure)
• XML Schéma
• Langage XML de définition de grammaire XML
• De plus en plus utilisé
• Expression puissante (type, structure, héritage)
Un document XML est dit valide lorsqu’il est conforme à une grammaire.
123
Le langage XML (eXtensible Markup Language)
Avantages du langage XML :
• Standard W3C
• La syntaxe XML ne contient que peu de mot clef: Simplicité
• XML est indépendant des plates-formes: Portabilité
• XML est un méta-langage, il est possible de créer ses propres balises:
Extensibilité
• Outils disponibles (et gratuits)
• Largement utilisé pour les échanges inter-applications

124
La couche de Communication SOAP (Simple
Object Access Protocol)
Définition:
• SOAP (Simple Object Access Protocol) 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.
• SOAP définit le cadre général pour l’échange de données structurées
en XML.
• Il permet d’échanger des structures de données complexes en XML
avec les espaces de nom, et la spécification XML Schéma.

125
La couche de Communication SOAP (Simple
Object Access Protocol)
Objectif : permettre la normalisation des échanges de données.
Il définit un moyen uniforme d'échange de données encodées XML
sous forme d'appels de procédures à distance RPC, en utilisant souvent
le HTTP comme protocole de transport ainsi les protocoles SMTP, POP,
et FTP dans certains cas.
Il assure l'interopérabilité entre composants tout en restant
indépendant des plates-formes et des langages de programmation.

126
La couche de Communication SOAP (Simple
Object Access Protocol)
Il repose sur deux standards :
• XML : pour la structuration des messages.
• http : pour le transport.
Il permet une interopérabilité avec divers environnements logiciels
(.NET, Java/RMI, CORBA, COM/DCOM …) quel que soit leur plate-forme
d'exécution.

127
La couche de Communication SOAP (Simple
Object Access Protocol)
• Les paquets de données circulent sous format XML, mais tous types
de données peuvent être transportés même si les données binaires
peuvent faire l'objet d'un encodage spécifique.
• Les données ayant un format binaire sont transportées sous forme de
pièces jointes avec le message SOAP principal.
• Les messages SOAP peuvent traverser les Proxy et les pare-feu.
• Il permet l'échange de données que ce soit en mode synchrone
(requête/réponse) ou asynchrone (accompagnement des processus).

128
La couche de Communication SOAP (Simple
Object Access Protocol)
PRINCIPES FONDAMENTAUX DU PROTOCOLE SOAP :
1. Framework de messagerie
2. Encodage et sérialisation standard pour les objets
3. Invocation de Service d'objets distants via SOAP RPC
4. Messages SOAP
5. Acheminement des messages
6. Nœud intermédiaire actif
7. Règles d'encodage
8. Liaison du SOAP avec les protocoles du transport
9. Sécurité du SOAP 129