RÉPUBLIQUE DU CAMEROUN FACULTÉ DES SCIENCES

REPUBLIC OF CAMEROON
Peace – Work – Fatherland Département de Mathématiques et Informatique
Department of Mathematics and Computer Science
UNIVERSITÉ DE DSCHANG BP 67, Dschang (Cameroun)
UNIVERSITY OF DSCHANG Tél. : (237) 243 69 15 09
Scholae Thesaurus Dschangensis Ibi Cordum E-mail : faculte.sciences@univ-dschang.org

BP 96, Dschang (Cameroun)

Tél./Fax : (237) 233 45 13 81
Website : http://www.univ-dschang.org
E-mail : udsrectorat@univ-dschang.org

ARCHITECTURE DES APPLICATIONS WEB ET INTÉGRATION

AVEC LES COMPOSANTS SOAP

MEGNE TCHINDA VALENTINE CM-UDS-14SCI2030

NGOUAJIO ZEBAZE NADINE CM-UDS-14SCI0236
NGUIMFACK SONGMO LEJUSTE CM-UDS-13SCI1367

Des notes de cours de

Intergiciel
échangées sous la supervision de
Dr. Fokou

IN4, 2018-2019

RSD57
Table des matières
Introduction ......................................................................................................................... 6
I. Applications web. ........................................................................................................ 7
I.1. Définition .................................................................................................................. 7
I.2. Architecture des applications web ............................................................................ 7
a. Architecture en couche ou 3-tiers......................................................................... 7
b. Architecture 2-tiers............................................................................................... 9
II. Les web services ...................................................................................................... 10
II.1. Définition .............................................................................................................. 10
II.2. Intérêt d’un web service .........................................................................................11
II.3. Caractéristiques d’un web service ..........................................................................11
II.4. Architecture d’un web service ............................................................................... 12
II.5. Fonctionnement des services Web ........................................................................ 13
II.6. Description en couche des services Web ............................................................... 14
III. Le protocole SOAP ................................................................................................... 16
III.1. Historique et définition ....................................................................................... 16
a. Historique ........................................................................................................... 16
b. Définition ........................................................................................................... 16
III.2. Principe de SOAP ................................................................................................ 17
III.3. Modèle d’échange de message SOAP ................................................................. 17
III.4. Rélation avec XML .............................................................................................. 18
III.5. Format d’un message SOAP ................................................................................ 18
a. L’enveloppe SOAP ............................................................................................. 19
b. L’en-tête SOAP .................................................................................................. 20
c. Le corps du message SOAP (Body) ................................................................... 20
d. Message ‘Fault’ .................................................................................................. 22
IV. Avantages et inconvénients du SOAP.................................................................... 23
a. Avantages ........................................................................................................... 24
b. Inconvénients ..................................................................................................... 24
V. Mise en œuvre. .......................................................................................................... 24
Conclusion ........................................................................................................................ 43
Référence .......................................................................................................................... 44

SEMESTRE II 2018 /2019 2

 Table de figure

Figure 1: architecture en couche ou 3 tiers ..................................................... 8

Figure 2: architecture d'un logiciel ................................................................. 9
Figure 3: Schéma de l’architecture 2-tiers .................................................... 10
Figure 4: schéma de fonctionnement d'un web service ................................ 13
Figure 5: Structure d'un web service ............................................................ 14
Figure 6: Utilisation de SOAP dans une architecture client serveur ............ 17
Figure 7: Format d'un message SOAP .......................................................... 19
Figure 8: type simple .................................................................................... 21
Figure 9: création d’un projet web dynamique ............................................. 25
Figure 10: création d’un projet web dynamique 2 ........................................ 26
Figure 11: création de la class personne ....................................................... 28
Figure 12: création de l’interface Person service ......................................... 29
Figure 13: création de la classe Person_serviceImpl .................................... 30
Figure 14: création du web service ............................................................... 31
Figure 15: implémentation du service .......................................................... 32
Figure 16: implémentation du service 2 ....................................................... 33
Figure 17: génération du web service WSDL............................................... 34
Figure 18: exploration du web service.......................................................... 35
Figure 19: test du web service ...................................................................... 35
Figure 20: création d’application client ........................................................ 36
Figure 21: génération des proxys .................................................................. 36
Figure 22: test des méthodes ......................................................................... 37
Figure 23: contenu du web service WSDL ................................................... 38
Figure 24: interface de SOAPui .................................................................... 39
Figure 25: création d’un nouveau projet SOAP ........................................... 40
Figure 26: envoie de la requête Soap ............................................................ 40
Figure 27: envoie de la requête Soap 2......................................................... 41
Figure 28: Réponse Soap .............................................................................. 42

SEMESTRE II 2018 /2019 3

SEMESTRE II 2018 /2019 4
 Liste des abréviations

NOMS CYCLES

SOAP Simple Object Access Protocol

UDDI Universal Description Discovery and Integration

WSDL Web Service Description Language
REST Representational State Transfer
XML eXtended Markup Language

AOS Architecture Orientée Service

SEMESTRE II 2018 /2019 5

 Introduction
De nos jours, plus l’informatique avance et plus le choix d’une architecture
web se complexifie. Un peu en arrière vers les débuts d’internet, il était très
facile de choisir une architecture parmi les technologies web existantes. Il
suffisait en somme de choisir sa technologie serveur, soit in fine PHP ou
java. On a ensuite vu arriver de nombreux Framework côtés serveur :
Symphonie ou zend pour le PHP, Java EE ou Spring pour le Java. Le but
était de rendre le développement plus facile pour les développeurs en
organisant le code sur différents couches applicatives et en proposant des
fonctionnalités built-in avec un niveau d’abstraction élevé. Il suffisait ainsi
d’apprendre le langage de programmation, les différentes couches imposées
par le Framework et les principales fonctionnalités fournies. L’intégralité du
traitement s’effectuait côté serveur, la page HTML était générée puis
transmise au navigateur. L’architecture restait donc simple. Il est petit à petit
devenu évident qu’il n’était pas utile de changer de page à chaque clic (et
ainsi tout recalculer côté serveur), alors qu’on pouvait ne mettre à jour que
des morceaux de la page HTML. Avec Ajax, Javascript a pris tout son sens
et de nombreux développeurs, souvent réticents, ont dû se rendre à
l’évidence : le traitement côté client ne doit plus être négligé. Suite à cette
évolution de raisonnement majeure, Les web services et les protocoles tels
que soap ont vu le jour pour répondre au besoin toujours croissant de
structurer le développement côté client.
L’objectif visé par notre travail est de présenter comment sont réalisés les
architectures logiciels et distribués avec la technologie SOAP, ensuite, de
répondre aux questions à tels que : C’est quoi SOAP ?, Pourquoi SOAP ?,
comment est son fonctionnement ?, Quels sont les outils associés à SOAP
pour la réalisation d’application distribuées ?, Comment est réaliser cette
association ?, et enfin, de montrer par un exemple très précis comment on
exploite le SOAP.

SEMESTRE II 2018 /2019 6

 I. Applications web.
I.1. Définition
une application web (aussi appelée web application, en anglais) est
une application manipulable directement en ligne grâce à un navigateur
web et qui ne nécessite donc pas d'installation sur les machines clientes,
contrairement aux applications mobiles. Une application Web permet au
développeur de ne pas avoir à développer un client pour chaque type
d’ordinateur ou chaque système d’exploitation. À partir du moment où le
client fonctionne dans un navigateur Internet, peu importe que l’utilisateur
utilise un Mac ou un PC, fonctionnant sous Windows XP ou Windows Vista.
Il peut naviguer de la même manière en utilisant Internet Explorer ou
Firefox. Cependant certaines applications nécessitent un navigateur Internet
en particulier. Les applications Web sont généralement développées en
utilisant des scripts côté serveur (ASP, PHP, etc.) et côté client (HTML,
Javascript, etc.). Le script côté client s’occupe de la présentation des
informations. Le script côté serveur s’occupe des tâches compliquées, par
exemple le stockage et la récupération d’informations. La plupart des
applications Web sont basées sur une architecture client-serveur dans
laquelle le client saisit des informations que le serveur récupère et stocke.
Les logiciels de messagerie sur Internet sont un exemple parlant, des
sociétés comme Yahoo et Microsoft proposent des clients de messageries en
ligne.

I.2. Architecture des applications web

a. Architecture en couche ou 3-tiers
L’architecture en couche consiste à diviser une application en diffèrent
module, qui constituent autant de couche. L’objectif est de proposer une
meilleure répartition des rôles (chaque module à un rôle clairement défini),
la séparation des traitements, ainsi qu’une réduction des dépendances entre
les services. Chaque module se doit d’être indépendant des autres pour
permettre une meilleure maintenabilité.
Une application peut aisément se diviser en trois niveaux distincts : Les
données, le traitement de ces données, et leur affichage.

SEMESTRE II 2018 /2019 7

 Figure 1: architecture en couche ou 3 tiers

 La couche de données regroupe le stockage et les mécanismes

d’accès des données de façon à ce qu’elles soient utilisables par
l’application au niveau traitement.
 La couche de traitement concerne à la fois les tâches à réaliser par
l’application sur les données et les traitements nécessaires suite à une
action venant de l’utilisateur : vérification d’authentification, calculs
divers….
 Enfin, la couche de présentation gère l’affichage des données et les
interactions de l’application avec l’utilisateur. La séparation de cette
couche permet notamment de proposer plusieurs présentations pour
une même application : la même couche peut alors servir pour une
application lourde et pour une application légère.
Les bonnes pratiques de développement logiciel recommandent de
développer ces trois niveaux d’une manière la plus indépendante possible.
Ainsi, la décision de changer de modèle de données ne devra impacter que la
couche donnée ; aucune modification ne devrait être nécessaire dans les
deux autres couches.
Mais le découpage en couche va plus loin. Imaginons que, lors du
développement d’un logiciel, il soit décidé de changer le système de gestion
de base de données, sans pour autant que le modèle de données ne soit
modifié. Si la couche de données est elle-même découpée en module
indépendant les uns des autres, cette décision sera plus rapide à mettre en
œuvre et les modifications nécessaires moins fastidieuses.
Pour cette raison, l’architecture d’un logiciel est le plus souvent
présentée plus finement que précédemment.

SEMESTRE II 2018 /2019 8

 Figure 2: architecture d'un logiciel

Dans cette architecture, nous distinguons :

 le système de gestion de base de données (SGBD), qui stocke les

données utilisées par l’application
 La couche de persistance, qui gère le mécanisme de sauvegarde et
de restauration des données
 La couche d’accès aux données, en charge d’accès aux données et
de leur manipulation, indépendamment du SGBD choisi.
 La couche service, ou couche métier, qui gère la logique de
l’application et les traitements à effectuer sur les données,
indépendamment de la provenance des données de la façon dont
elles seront affichées une fois les traitements effectués
 La couche interface utilisateur, qui s’occupe à la fois d’afficher
les données reçues par la couche de services et d’envoyer à la
couche de services les informations relatives aux actions de
l’utilisateur.

b. Architecture 2-tiers
L’architecture 2-tiers (aussi appelé architecture 2-tier, le mot tiers
signifiant rangée en anglais) caractérise les systèmes clients / serveurs pour

SEMESTRE II 2018 /2019 9

lesquels le client demande une ressource et le serveur la lui fournit
directement, en utilisant ses propres ressources. Cela signifie que le serveur
ne fait pas appel à une autre application afin de fournir une partie du service.

Figure 3: Schéma de l’architecture 2-tiers

Inconvénients
 Charge importante du poste client qui réalise l’ensemble des
traitements applicatifs
 Maintenance et mises à jour difficiles à gérer
 Conversation entre client et serveur est assez bruyante
 Ces limites proviennent de type du client : client lourd

I. Les web services

II.1. Définition
La technologie des services Web est un moyen rapide de distribution de
l'information entre clients, fournisseurs, partenaires commerciaux et leurs
différentes plates-formes. Les services Web sont basés sur le modèle SOA
(Architecture Orientée Service).
D'autres technologies telles que RMI, DCOM et CORBA ont
précédemment adopté ce style architectural mais ont généralement échoué
en raison de la diversité des plates-formes utilisées dans les organisations et
aussi parce que leur usage n'était pas adapté à Internet (problème de passage
à travers des FireWalls, etc.) d'où la lenteur, voire l'absence de réponses sur
ce réseau. Les applications réparties fondées sur ces technologies offrent des
solutions caractérisées par un couplage fort entre les objets. Les solutions
proposées par les services Web, permettent néanmoins un couplage moins
fort. De plus, l'utilisation des technologies standards du Web telles HTTP et
XML par les services Web facilite le développement d'applications réparties

SEMESTRE II 2018 /2019 10

sur Internet, et permet d'avoir des applications très faiblement couplées.
L'intégration est sans doute le facteur essentiel qui favorise l'utilisation des
services Web.
Alors, un Web Service est un composant logiciel identifié par une URI,
dont Les interfaces publiques sont définies et appelées en XML. Sa
définition peut être découverte par d'autres systèmes logiciels. Les services
Web peuvent interagir entre eux d'une manière prescrite par leurs définitions,
en utilisant des messages XML portés par les protocoles Internet.

II.2. Intérêt d’un web service

Les services Web fournissent un lien entre applications. Ainsi, des
applications utilisant des technologies différentes peuvent envoyer et
recevoir des données au travers de protocoles compréhensibles par tout le
monde.
Les services Web sont normalisés car ils utilisent les standards XML et
HTTP pour transférer des données et ils sont compatibles avec de nombreux
autres environnements de développement. Ils sont donc indépendants des
plates-formes. C'est dans ce contexte qu'un intérêt très particulier a été
attribué à la conception des services Web puisqu'ils permettent aux
entreprises d'offrir des applications accessibles à distance par d'autres
entreprises. Cela s'explique par le fait que les services Web n'imposent pas
de modèles de programmation spécifiques. En d'autres termes, les services
Web ne sont pas concernés par la façon dont les messages sont produits ou
consommés par des programmes. Cela permet aux vendeurs d'outils de
développement d'offrir différentes méthodes et interfaces de programmation
au-dessus de n'importe quel langage de programmation, sans être contraints
par des standards comme c'est le cas de la plate-forme C O R B A qui définit
des ponts spécifiques entre le langage de définition IDl et différents langages
de programmation. Ainsi, les fournisseurs d'outils de développement peuvent
facilement différencier leurs produits avec ceux de leurs concurrents en
offrant différents niveaux de sophistication. Les services Web représentent
donc la façon la plus efficace de partager des méthodes et des
fonctionnalités. De plus, ils réduisent le temps de réalisation en permettant
de tirer directement parti de services existants.

II.3. Caractéristiques d’un web service

La technologie des services Web repose essentiellement sur une
représentation standard des données (interfaces, messageries) au moyen du
langage XML. Cette technologie est devenue la base de l'informatique

SEMESTRE II 2018 /2019 11

distribuée sur Internet et offre beaucoup d'opportunités au développeur Web.
Un service Web possède les caractéristiques suivantes :
 il est accessible via le réseau ;
 il dispose d'une interface publique (ensemble d'opérations) décrite en
XML ;
 ses descriptions (fonctionnalités, comment l'invoquer et où le trouver
?) sont stockées dans un annuaire ;
 il communique en utilisant des messages XML, ces messages sont
transportés par des protocoles Internet (généralement HTTP, mais rien
n'empêche d'utiliser d'autres protocoles de transfert tels : SMTP, FTP,
BEEP...) ;
 l'intégration d'application en implémentant des services Web produit
des systèmes faiblement couplés, le demandeur du service ne connaît
pas forcément le fournisseur. Ce dernier peut disparaître sans
perturber l'application cliente qui trouvera un autre fournisseur en
cherchant dans l'annuaire.

II.4. Architecture d’un web service

Les services Web reprennent la plupart des idées et des principes du
Web (HTTP, XML), et les appliquent à des interactions entre machines.
Comme pour le World Wide Web, les services Web communiquent via un
ensemble de technologies fondamentales qui partagent une architecture
commune. Ils ont été conçus pour être réalisés sur de nombreux systèmes
développés et déployés de façon indépendante. Les technologies utilisées par
les services Web sont HTTP, WSDL, REST, XML-RPC, SOAP et UDDI.
 REST : REST (Représentational State Transfer) est une architecture
de services Web. Élaborée en l'an 2000 par Roy Fieding, l'un des
créateurs du protocole HTTP, du serveur Apache HTTPd et d'autres
travaux fondamentaux, REST est une manière de construire une
application pour les systèmes distribués comme le World Wide Web.
 XML-RPC : XML-RPC est un protocole simple utilisant XML pour
effectuer des messages RPC. Les requêtes sont écrites en XML et
envoyées via HTTP POST. Les requêtes sont intégrées dans le corps
de la réponse HTTP. XML-RPC est indépendant de la plate-forme, ce
qui lui permet de communiquer avec diverses applications. Par
exemple, un client Java peut parler de XML-RPC à un PerlServer !
 SOAP : SOAP (Simple Object Access Protocol) est un protocole
standard de communication. C'est l'épine dorsale du système

SEMESTRE II 2018 /2019 12

 d'interopérabilité. SOAP est un protocole décrit en XML et
standardisé par le W3C. Il se présente comme une enveloppe pouvant
être signée et pouvant contenir des données ou des pièces jointes. Il
circule sur le protocole HTTP et permet d'effectuer des appels de
méthodes à distance.
 WSDL : WSDL (Web Service Description Language) est un langage
de description standard. C'est l'interface présentée aux utilisateurs. Il
indique comment utiliser le service Web et comment interagir avec
lui. WSDL est basé sur XML et permet de décrire de façon précise les
détails concernant le service Web tels que les protocoles, les ports
utilisés, les opérations pouvant être effectuées, les formats des
messages d'entrée et de sortie et les exceptions pouvant être envoyées.
 UDDI : UDDI ( Universal Description Discorvery and Integration )
est un annuaire de services. Il fournit l'infrastructure de base pour la
publication et la découverte des services Web. UDDI permet aux
fournisseurs de présenter leurs services Web aux clients.
Les informations qu'il contient peuvent être séparées en trois types :
 les pages blanches qui incluent l'adresse, le contact et les identifiants
relatifs au service Web ;
 les pages jaunes qui identifient les secteurs d'affaires relatifs au
service Web ;
 les pages vertes qui donnent les informations techniques.

II.5. Fonctionnement des services Web

Le fonctionnement des services Web s'articule autour de trois acteurs
principaux illustrés par le schéma suivant :

Figure 4: schéma de fonctionnement d'un web service

SEMESTRE II 2018 /2019 13

Décortiquons ce schéma.
 Service provider service : Le fournisseur de service met en
application le service Web et le rend disponible sur Internet.
 Service requester programme client : C'est n'importe quel
consommateur du service Web. Le demandeur utilise un service Web
existant en ouvrant une connexion réseau et en envoyant une demande
en XML (REST, XML-RPC, SOAP).
 Annuaire service registry : Le registre de service est un annuaire de
services. Le registre fournit un endroit central où les programmeurs
peuvent publier de nouveaux services ou en trouver. Les interactions
entre ces trois acteurs suivent plusieurs étapes :
 La publication du service : le fournisseur diffuse les descriptions de
ses services Web dans l'annuaire.
 La recherche du service : le client cherche un service particulier, il
s'adresse à un annuaire qui va lui fournir les descriptions et les URL
des services demandés afin de lui permettre de les invoquer.
 L'invocation du service : une fois que le client récupère l'URL et la
description du service, il les utilise pour l'invoquer auprès du
fournisseur de services.

II.6. Description en couche des services Web

Les services Web emploient un ensemble de technologies qui ont été
conçues afin de respecter une structure en couches sans être dépendante de
façon excessive de la pile des protocoles. Cette structure est formée de
quatre couches majeures :

Figure 5: Structure d'un web service

SEMESTRE II 2018 /2019 14

  Le transport de messages XML-RPC ou SOAP est assuré par le
standard HTTP.
 SOAP ou XML-RPC prévoit la couche de communication basée sur
XML pour accéder à des services Web.
 La description d'un service Web se fait en utilisant le langage WSDL.
WSDL expose l'interface du service.
 La publication et la découverte des services Web sont assurées par le
biais du référentiel UDDI. Un référentiel UDDI est un catalogue de
services Web.
Couche transport : Cette couche est responsable du transport des messages
XML échangés entre les applications. Actuellement, cette couche inclut
HTTP, SMTP, FTP, et de nouveaux protocoles tels que BEEP.
Couche communication : Cette couche est responsable du formatage des
données échangées de sorte que les messages peuvent être compris à chaque
extrémité. Actuellement, deux styles architecturaux totalement différents
sont utilisés pour ces échanges de données. Nous avons d'un côté
l'architecture orientée opérations distribuées (protocoles RPC) basée sur
XML et qui comprend XML-RPC et SOAP et de l'autre côté une architecture
orientée ressources Web, REST (Representational State Transfer) qui se base
uniquement sur le bon usage des principes du Web (en particulier, le
protocole HTTP).
Couche description de service : Cette couche est responsable de la
description de l’interface publique du service Web. Le langage utilisé pour
décrire un service Web est WSDL qui est la notation standard basée sur
XML pour construire la description de l’interface d’un service. Cette
spécification définit une grammaire XML pour décrire les services Web
comme des ensembles de points finaux de communication (ports) à travers
lesquels on effectue l’échange de messages.
Couche découverte de service : Cette couche est chargée de centraliser les
services dans un registre commun, et de simplifier les fonctionnalités de
recherche et de publication des services Web. Actuellement, la découverte
des services est assurée par un annuaire UDDI (Universal Description,
Discovery, and Integration).

SEMESTRE II 2018 /2019 15

 II. Le protocole SOAP
III.1. Historique et définition
a. Historique
Microsoft a initialement développé SOAP pour remplacer des
technologies plus anciennes qui ne fonctionnent pas parfaitement sur le
web tels que le Distributed Component Object Model (DCOM) et le
Common Object Request Broker Architecture (CORBA). Ces
technologies échouent parce qu'elles comptent sur la messagerie
binaire; la messagerie XML employée par SOAP fonctionne mieux sur
le web.
Après une première version, Microsoft a présenté SOAP à
l'Internet Engineering Task Force (IETF) où il a été normalisé. SOAP
est conçu pour soutenir l'expansion, il a donc toutes sortes d'autres
sigles et abréviations qui y sont associés, tels que WS-Addressing, WS-
Policy, WS-Security, WS-Federation, WS-ReliableMessaging, WS-
Coordination, WS-AtomicTransaction et WS-RemotePortlets.
Le fait est que SOAP est fortement extensible, mais vous pouvez
utiliser uniquement les parties dont vous avez besoin pour une tâche
particulière. Par exemple, lorsque vous utilisez un service Web public
qui est librement accessible à tout le monde, vous n'avez plus vraiment
besoin de WS-Security.

b. Définition
SOAP (simple Object Access Protocol) est un protocole de
communication basé sur XML, pour permettre aux applications de
s’échanger des informations via http. Il permet ainsi l’accès aux services
web et l’interopérabilité des applications à travers le web. SOAP repose
exclusivement sur XML pour fournir des services de messagerie.
Les applications communiquent grâce au RPC (remote procedure call)
entre les objets. Mais http n’a pas été conçu pour ça. Or RPC ne résout pas
les problèmes de sécurité et de compatibilité car certain firewall et proxy
bloque ce genre de trafic. L’utilisation de la communication via http reste
incontournable car il est supporté par tous les navigateurs et serveurs. Ainsi
donc SOAP a été créé pour :
 pallier à ce manque de sécurité et compatibilité

SEMESTRE II 2018 /2019 16

  permettre la communication entre application qui tourne sur
différents OS, différentes technologies, et différents langages de
programmation

III.2. Principe de SOAP

SOAP codifie simplement une pratique existante, à savoir l’utilisation
conjointe de XML et http. SOAP est un protocole minimal pour appeler des
méthodes sur des serveurs, services, composants, objets.
Il a pour avantages de ne pas imposer une API ou un runtime, ni l’utilisation
d’un ORB (CORBA, DCOM, …) ou d’un serveur web particulier (Apache,
IIS, …) et non plus de ne pas imposer un modèle de programmation.
Une des volontés du W3C vis à vis de SOAP est de “ne pas réinventer une
nouvelle technologie”. SOAP a été construit pour pouvoir être aisément
porté sur toutes les plates-formes et les technologies
SOAP peut être vu selon deux aspects :
 SOAP peut être vu comme un protocole d’échange de “message” : La
requête contient un seul message (appel sérialisé d’une méthode sur
un objet) ; La réponse contient un seul message (retour sérialisé d’un
appel de méthode sur un objet) ;
 SOAP peut être vu comme un format d’échange de documents : La
requête contient un document XML. Le serveur retourne une version
transformée L’architecture client/serveur peut être représentée de la
manière suivante :

Figure 6: Utilisation de SOAP dans une architecture client serveur

III.3. Modèle d’échange de message SOAP

En dehors du protocole auquel SOAP est attaché, les messages sont

SEMESTRE II 2018 /2019 17

routés sur un chemin appelé un ‘message path’, qui permet de transmettre un
message à un destinataire en passant par un ou plusieurs noeuds
intermédiaires.
Une application SOAP recevant un message SOAP doit traiter ce
message en faisant les actions suivantes :
 Identifier toutes les parties du message SOAP ;
 Vérifier que toutes les parties mandataires sont supportées par
l’application pour ce message et les traiter en conséquence.
 Si ce n’est pas le cas le message est supprimé ; - Si l’application
SOAP n’est pas la destination finale du message alors le message est
forwardé.

III.4. Relation avec XML

Tous les messages SOAP sont encodés en XML. Une application SOAP
doit inclure le namespace SOAP adéquat pour tous les éléments et les
attributs définis par SOAP. Elle doit pouvoir supprimer les messages qui ont
un namespace incorrect.
SOAP définit deux namespaces :
 L’enveloppe SOAP qui a l’identifiant suivant
http://schemas.xmlsoap.org/soap/envelope/
 Les règles d’encodage qui a l’identifiant suivant :
"http://schemas.xmlsoap.org/soap/encoding/"
Un message SOAP ne doit pas contenir de DTD.

III.5. Format d’un message SOAP

Un message SOAP est formé de trois éléments :
 L’enveloppe SOAP (SOAP envelope) définit une cadre d’ensemble
pour décrire ce qui est dans le message, qui gère ce message et si ce
message est optionnel ou mandataire
 Les règles d’encodage définissent un mécanisme de sérialisation qui
peut être utilisé pour échanger des types de données d’une application
précise ;
 Le SOAP RPC qui définit une convention qui peut être utilisé pour
représenter des appels et réponses de procédures distantes. Bien que
ces trois parties soient décrites ensemble en tant que des parties de
SOAP, elles sont fonctionnellement différentes. En particulier,

SEMESTRE II 2018 /2019 18

 l’enveloppe et les règles d’encodage sont définies dans des espaces de
nommage (namespaces) différents pour faciliter la modularité.

Figure 7: Format d'un message SOAP

a. L’enveloppe SOAP
Un message SOAP est un document XML qui consiste en une
enveloppe mandataire SOAP, un header optionnel et un body. Un message
SOAP contient :
 L’enveloppe est l’élément de base du document XML, qui représente
le message ;
 Le header est un mécanisme générique qui permet d’ajouter des
fonctionnalités à un message SOAP de manière décentralisé sans
agrément entre les parties qui communiquent. C’est ici qu’il est
indiqué si le message est mandataire ou optionnel ;
 Le body est un container pour les informations mandataires à
l’intention du récepteur du message. SOAP définit un élément pour
le body, qui est l’élément ‘Fault’ utilisé pour reporter les erreurs.
Les règles de grammaires sont les suivantes :
 Enveloppe :
 Le nom de l’élément est ‘envelope’ ;
 L’élément doit être présent dans un message SOAP ;

SEMESTRE II 2018 /2019 19

  L’élément peut contenir une déclaration de namespace et des
attributs additionnels.
 En-tête (header) :
 Le nom de l’élément est ‘Header’ ;
 L’élément peut être présent dans un message SOAP. S’il est
présent, il doit être le premier enfant d’un élément SOAP
enveloppe ;
 L’élément peut contenir une collection d’en-têtes qui doivent
être ses enfants immédiats.
 Corps (body) :
 Le nom de l’élément est ‘Body’ ;
 L’élément doit être présent dans un message SOAP et doit être
un enfant immédiat d’une enveloppe SOAP. Il doit suivre le
header s’il est présent. Sinon il doit être le fils immédiat de
l’enveloppe ;
 L’élément peut contenir une collection de body qui sont tous les
fils immédiats d’un body.

b. L’en-tête SOAP
SOAP fournit un mécanisme permettant d ‘étendre un message d’une
manière modulaire et décentralisée sans mécanisme d’apprentissage entre les
deux parties communicantes. Des exemples d’extension qui peuvent être
implémentées comme des en-têtes sont des authentifications, des
transactions, des paiements…
L’élément Header est encodé en tant que premier enfant de l’enveloppe
SOAP. Tous les enfants immédiats du header sont appelés des entrés du
header.
Les règles d’encodage pour les entrées du header sont les suivantes :
 Une entrée d’header est identifiée par son nom d’élément, qui
consiste en le namespace URI et le nom local ;
 L’attribut SOAP : ‘encodingStyle’ peut être utilisé pour indiquer le
style de codage de l’entrée ;
 L’attribut SOAP : ‘mustUnderstand’ peut être utilize pour indiquer
comment traiter l’entrée.
c. Le corps du message SOAP (Body)
Le corps d’un message SOAP fournit un mécanisme pour échanger les

SEMESTRE II 2018 /2019 20

informations mandataires à l’attention du récepteur final du message.
L’utilisation typique de l’élément body inclut les appels RPC et les rapports
d’erreurs.
L’élément body est encodé en tant que fils direct de l’élément SOAP
envelope. Si un header est présent alors le body doit être le fils immédiat de
celui-ci.
Tous les enfants immédiats de l’élément body sont appelés des entrées
du corps et chaque entrée est encodée comme un élément indépendant dans
l’élément body.
Les règles d’encodage des entrées du body sont les suivantes :
 Une entrée body est identifiée par son nom d’élément, qui
correspond au namespace URI et au nom local ;
 L’attribut SOAP ‘encodingStyle’ peut être utilisé pour indiquer le
style d’encodage pour l’entrée. SOAP définit une entrée body, qui est
l’entrée ‘Fault’ utilisée pour le rapport d’erreurs.

Les éléments ainsi véhiculés peuvent contenir deux types de donnée :

 les types simples

Figure 8: type simple

La déclaration d’un type simple s’effectue en deux temps :

 Il est nécessaire de fixer le type ainsi que le nom de la variable que
l’on souhaite manipulée.
 Comme pour tout langage, nous pouvons ensuite affecter la variable
à une valeur.
Exemple :

SEMESTRE II 2018 /2019 21

  Les énumérations
Contrairement aux éléments simples, il faut trois étapes pour utiliser une
énumération :
 Il faut déclarer un nouvel élément qui possède le type que l’on
s’apprête à créer
 Ensuite, on définit les valeurs de l’énumération
 On utilise l’énumération en affectant la valeur souhaitée.

Exemple :

Alors que le header et le body sont définis comme des éléments

indépendants, ils sont en fait liés. La relation entre une en-tête et un corps est
la suivante : un body est sémantiquement équivalent à un header sans
destinataire et avec un message SOAP ‘mustUnderstand’ avec une valeur de
‘1’.
d. Message ‘Fault’
L’élément Fault de SOAP est utilisé pour acheminer des erreurs ou des

SEMESTRE II 2018 /2019 22

informations sur le statut à travers un message SOAP. S’il est présent,
l’élément Fault de SOAP doit impérativement apparaître comme une entrée
du ‘body’ et ne doit en aucun cas apparaître plus d’une fois à l’intérieur de
l’élément ‘body’.
L’élément Fault de SOAP est défini par les quatre sous éléments suivants :
 Faultcode : L’élément faultcode est prévu pour être interprété par
des logiciels possédant un algorithme d’identification des erreurs
SOAP. Le faultcode doit absolument être présent dans l’élément fault
de SOAP. La valeur du faultcode est définie par la norme W3C.
 faultstring : L’élément faultstring offre une explication lisible pour
l’homme d’erreur. Cet élément n’est donc pas interprété par un
processus de gestion d’erreur SOAP. Cet élément peut être assimilé
au “Reason Phrase” définie par HTTP. Il doit absolument être
présent dans l’élément fault de SOAP.
 Faultactor : L’élément faultactor est prévu pour informer le
processus responsable de l’erreur. La valeur de cet élément SOAP est
une URI afin d’identifier la source. Toutes les applications qui ne
connaissent pas la destination finale d’un message SOAP doivent
inclure cet élément.
 détail : L’élément détail est prévu pour indiquer le champ d’action
d’une erreur qui porte sur les données présentes dans l’élément body.
L’absence d’élément détail dans un message fault signifie que l’erreur
n’influe pas sur le traitement des informations contenues dans l’élément
Body.
Tous les fils de l’élément detail (au sens xml du terme) sont appelés
“detail entries”. Chaque “detail entries” apporte une information sur
l’élément detail.
Les règles de codage des “detail entries” s’effectuent comme suit:
 Un “detail entries” est défini par son nom.
 Un attribut “encodingStyle” qui doit être utilisé pour indiquer la
manière dont il est codé.
Chaque « detail entries » contient des sous éléments. Ces sous éléments sont
différents suivant le type de « detail entry ».

III. Avantages et inconvénients du SOAP

De nombreux commentateurs et spécialistes ont discuté des avantages

SEMESTRE II 2018 /2019 23

et inconvénients de SOAP relatifs aux autres technologies, et relatifs aux
contextes de son utilisation.
a. Avantages

 Utiliser SOAP via HTTP facilite la communication et évite les

problèmes de proxys et pare-feu par rapport à des technologies plus
anciennes.
 SOAP est :
 assez ouvert pour s'adapter à différents protocoles de
transport ;
 indépendant de la plate-forme ;
 indépendant du langage ;
 extensible.

b. Inconvénients

 En raison du nombre d'informations qu'impose le format XML,

SOAP peut alourdir considérablement les échanges par rapport à
des middlewares comme CORBA ou ICE, ce qui n'est pas
forcément un handicap quand les volumes de données transités par
SOAP sont faibles par rapport au volume total de données
échangées.
 SOAP décrit la manière dont les applications doivent
communiquer entre elles, certains considèrent que le couplage
reste fort entre le serveur et ses clients. Une modification de l'API
implique ainsi une évolution côté client, contrairement à une
architecture orientée ressources telle que REST.

IV. Mise en œuvre.

Pour la suite, nous allons voir comment implémenter un web service basé
sur JAXWS. Pour cela, nous allons suivre les étapes suivantes :

 Créer le web service

 Développer le web service

SEMESTRE II 2018 /2019 24

  Déployer le web service en utilisant un serveur http et un conteneur
WS
 Tester le web service avec un analyseur SOAP .dans notre cas, nous
utiliserons l’outil SOAPui
 Enfin nous allons créer un client java.

Le web service que nous allons créer consiste à créer un service qui permet
d’exposer un certain nombre de méthodes via le protocole SOAP.
 addPerson : pour ajouter une personne
 deletePerson : pour supprimer une personne
 getPerson : pour rechercher une personne
 getAllPerson : pour avoir la liste de toutes les personnes enregistrées
Commençons par notre service web SOAP dans Eclipse. Tout d'abord,
nous allons créer un projet Dynamic Web simple dans Eclipse qui
contiendra la logique métier de notre application.

Figure 9: création d’un projet web dynamique

Cliquez sur le bouton Suivant ci-dessus et vous obtiendrez la page suivante

SEMESTRE II 2018 /2019 25

pour fournir le nom de votre projet Web et le Runtime cible.

Figure 10: création d’un projet web dynamique 2

Cliquez sur Suivant et on vous demandera de fournir l'emplacement "Racine

contextuelle" et l'emplacement du répertoire de contenu. Vous pouvez les
laisser par défaut.

SEMESTRE II 2018 /2019 26

Cliquez sur Terminer et Eclipse créera le squelette du projet pour vous.
Commençons par notre logique d'affaires. Ainsi, pour notre exemple, nous
aimerions publier un service web qui peut être utilisé pour
ajouter/supprimer/obtenir un objet. La première étape consiste donc à créer
un modèle Bean.

SEMESTRE II 2018 /2019 27

 Figure 11: création de la class personne

Notez que ci-dessus est un simple java Bean, nous sommes en train
d'implémenter une interface serializable car nous allons le transporter sur le
réseau. Nous avons également fourni l'implémentation de la méthode
toString qui sera utilisée lorsque nous imprimerons cet objet côté client.

La prochaine étape est de créer des classes de service, donc nous aurons une
interface comme Person_service et sa classe d'implémentation simple
Person_serviceImpl .

SEMESTRE II 2018 /2019 28

 Figure 12: création de l’interface Person service

Ci-dessous se trouve la classe de service d'implémentation, nous utilisons

Map pour stocker les objets Person comme source de données. Dans le
monde réel de la programmation, nous aimerions les sauvegarder dans des
tables de base de données.

SEMESTRE II 2018 /2019 29

 Figure 13: création de la classe Person_serviceImpl

C'est tout pour notre logique, puisque nous les utiliserons dans un service
web, il n'y a aucun intérêt à créer des pages web ici. Notez que nous n'avons
aucune référence à tout type de classes de services web dans le code ci-
dessus.

Services Web SOAP en Java avec Eclipse

Une fois que notre logique métier est prêt, l'étape suivante consiste à utiliser
Eclipse pour créer une application de service web à partir de celle-ci. Créez
un nouveau projet et sélectionnez l'assistant Web Service.

SEMESTRE II 2018 /2019 30

 Figure 14: création du web service

Cliquez sur le bouton Suivant et vous obtiendrez une page où le service web
et ses détails client doivent être fournis. C'est la page la plus importante dans
la création d'un service web. Assurez-vous que vous sélectionnez Web
Service type comme Bottom up Java bean Web Service parce que nous
mettons en œuvre avec une approche ascendante. Il y a deux façons de créer
un service web :

 Dernier contrat ou approche ascendante : Dans cette approche, nous

créons d'abord l'implémentation, puis nous générons le fichier WSDL
à partir de celle-ci. Notre implémentation s'inscrit dans cette catégorie.
 Le contrat d'abord ou l'approche descendante : Dans cette approche,
nous créons d'abord le contrat de service web, c'est-à-dire le fichier
WSDL, puis nous créons l'implémentation pour lui.

SEMESTRE II 2018 /2019 31

 Figure 15: implémentation du service

Dans l'implémentation du service, fournissez la classe d'implémentation

Person_serviceImpl chemin entièrement classifié. Assurez-vous que vous
déplacez le curseur en service et le type de client vers la gauche pour qu'il
puisse générer le programme client et aussi l'interface utilisateur pour tester
notre service web. Vérifiez les configurations dans l'implémentation du
service Web, vous devez fournir des détails corrects pour l'exécution du
serveur, l'exécution du service Web et le projet de service. Habituellement,
ils sont remplis automatiquement et vous n'avez pas besoin de faire de
changements ici.
Pour les configurations client, vous pouvez fournir le nom du projet client
comme vous le souhaitez. Je l'ai laissé par défaut comme SoapJWSClient.
Si vous cliquez sur le lien pour l'exécution du service web, vous obtiendrez
différentes options comme le montre l'image ci-dessous. Cependant, je l'ai
laissé par défaut.

SEMESTRE II 2018 /2019 32

 Figure 16: implémentation du service 2

Cliquez sur le bouton Suivant et vous pourrez ensuite choisir les méthodes
que vous voulez exposer en tant que service web. Vous pourrez également
choisir le style du service web en tant que document ou littérale. Vous
pouvez changer le nom du document WSDL mais il est bon de l'avoir avec
le nom de la classe d'implémentation pour éviter toute confusion par la suite.

SEMESTRE II 2018 /2019 33

 Figure 17: génération du web service WSDL

Cliquez sur le bouton Suivant et vous obtiendrez la page de démarrage du

serveur, cliquez sur le bouton "Démarrer le serveur" et ensuite le bouton
suivant sera activé.

SEMESTRE II 2018 /2019 34

Cliquez sur le bouton Suivant et vous obtiendrez une page pour lancer le
"Web Services Explorer".

Figure 18: exploration du web service

Cliquez sur le bouton Lauch et il ouvrira une nouvelle fenêtre dans le

navigateur où vous pourrez tester votre service web avant de passer à la
partie application client. Il ressemble à l'image ci-dessous pour notre projet.

Figure 19: test du web service

Nous pouvons faire des tests ici, mais pour notre simple application, je suis
prêt à aller de l'avant avec la création d'applications client. Cliquez sur le
bouton Suivant dans la fenêtre contextuelle des services Web d'Eclipse et
vous obtiendrez une page pour le dossier source de l'application client.

SEMESTRE II 2018 /2019 35

 Figure 20: création d’application client

Cliquez sur le bouton Suivant et vous obtiendrez différentes options à choisir

comme installation de test. Je vais aller de l'avant avec JAX-RPC JSPs afin
que l'application client génère une page JSP que nous pouvons utiliser.

Figure 21: génération des proxys

SEMESTRE II 2018 /2019 36

Notez les méthodes getEndpoint et setEnpoint (String) ajoutées que nous
pouvons utilisé pour obtenir l'URL du point de terminaison du service web
et nous pouvons le définir à une autre URL au cas où nous déplacerions
notre serveur vers une autre URL.

Cliquez sur le bouton Terminer et Éclipse créera le projet client dans votre
espace de travail, il lancera également la page de test client JSP comme
indiqué ci-dessous.

Figure 22: test des méthodes

Vous pouvez copier l'URL et l'ouvrir dans le navigateur de votre choix. Vous
avez le choix de tester les autres méthodes.
Tout est fait vous pouvez maintenant accéder à votre web service WSDL
dans un navigateur

SEMESTRE II 2018 /2019 37

 Figure 23: contenu du web service WSDL

Testons maintenant notre web service avec notre outil SOAPui

SEMESTRE II 2018 /2019 38

 Figure 24: interface de SOAPui

Pour cela on crée un nouveau projet Soap. Nous référençons notre WDSL
comme présenté à l’image suivant :

SEMESTRE II 2018 /2019 39

 Figure 25: création d’un nouveau projet SOAP

Ensuite nous pouvons tester les méthodes .Faisons un test sur la méthode
addPerson :
Alors pour cela vous clicquez sur la methode addPerson  request1.vous
obtenez :

Figure 26: envoie de la requête Soap

Remplacer les « ? » par les valeurs souhaités comme l’indique la figure

suivante :

SEMESTRE II 2018 /2019 40

 Figure 27: envoie de la requête Soap 2

Apres avoir exécuté vous avez la réponse suivante :

SEMESTRE II 2018 /2019 41

 Figure 28: Réponse Soap

Le résultat retourné est true pour vous indiquer que la personne à bel et bien
été ajouté.
Je vous invite donc à tester les autres méthodes

SEMESTRE II 2018 /2019 42

 Conclusion
Nous avons présenté dans cet exposé les architectures des applications
web et leur répartition avec les composants logiciels SOAP, en répondant à
toutes les questions posées dans l’introduction. Nous avons proposé aussi un
petit exemple qui montre l’utilisation du protocole SOAP.

SEMESTRE II 2018 /2019 43

Référence
 Bibliographie
[1] : Chauvet j. ‘‘service web avec SOAP, WSDL, UDDI,
ebXML’’; jouve, Paris; Mars 2017.
[2]: Bussler C, ‘‘B2B integration: Concepts and Architecture’’;
Springer-Verlag Berlin, 2016.
[3]: Qi Yu- Athman Bouguettaya, Foundation for Efficient
Web Service Selection, 2010.
 Webographie
[4] : Web service et définition, www.laurenti.com/publis/STF
Laurenti 04032004.PDF
[5] : Site officiel d’UDDI : http://www.uddi.org/
[6]:siteofficiel : http://igm.univmlv.fr/~dr/XPOSE2005/rouvio_
WebServices/soap.html
[6]: W3S Recommandation,www.w3.org/2016/07/soap-
translation/soap12-part0.html

SEMESTRE II 2018 /2019 44