Interopérabilité des Services Web dans le cadre d’une Architecture SOA

Année académique 2012 – 2013 (de Mars à Aout 2013)
Interopérabilité des Services Web
dans le cadre d’une Architecture SOA
Réalisé par : Jean Paul DONGMO MIAFFO

ii
Résumé
L’évolution rapide des technologies de l’informatique et la multiplicité de ceux-ci, a
profondément modifié le paysage du monde de l’informatique des entreprises, rendant ainsi
leur système d’information hétérogène et parfois fonctionnant en silo, empêchant les
différents composants du système d’information d’échanger des messages. Afin d’améliorer
la cohérence et la performance de leur système d’information, et de répondre de façon
efficace aux problématiques d’échanges de données entre les composants du système, les
entreprises se sont résolument tournées vers de nouveaux concepts et technologies afin de
permettre l’interopérabilité entre les éléments de leur système d’information.
L’interopérabilité se définit comme étant la capacité pour des applications fonctionnant dans
un système hétérogène de pouvoir échanger des messages. Les services web sont des
technologies qui permettent naturellement l’interopérabilité entre les applications. Elle repose
sur l’utilisation des normes ou de standard de communication et de format d’échange de
données ouvert (TCP/IP, HTTP, XML, JSON, …). L’architecture orientée services (SOA)
quant à elle est un paradigme qui permet de construire le système d’information de
l’entreprise autour d’une architecture modulaire en se basant sur des socles interopérable et
réutilisable. Sa complémentarité avec les technologies des services web permet d’augmenter
de façon significative les performances du système d’information en terme de :
• Flexibilité,
• Réutilisabilité,
• Interopérabilité.
Derrière le concept d’interopérabilité se cache de gros enjeux économique, ces enjeux peuvent
être appréhendés différemment par les entreprises en fonction de leurs besoins :
• Pour certains, l’interopérabilité permet d’éviter la duplication des composants ou
encore des ressources informatique par la réutilisation des composants existant. Cela
permet par la même occasion de réduire le coût lié au développement des nouveaux
composants. Car de nos jours les logiciels sont rarement construits à partir de zéros,
mais plutôt par assemblage des briques de base des composants existantes.
• Pour d’autres, l’interopérabilité permet de combiner ou de composer avec plusieurs
systèmes d’information afin d’offrir aux utilisateurs finaux un service à valeur ajoutée
fort. Par exemple l'achat d'un séjour touristique peut s’effectuer au près d’un seul
vendeur offrant ainsi des services unifiés en provenance d’institution différentes :
✓ Achat d’un billet d'avion,
✓ Réservation d’une chambre d’hôtel,
✓ Location de voiture.

iii
Abstract
The fast evolution of the computing technologies and the multiplicity of these, have
profoundly modified the landscape of the IT of companies, making their IT system
heterogeneous and sometimes working in silo, Preventing the various components of the
information system to exchange messages. To improve the coherence and the performance of
their information system, and answer with efficacy the problems of exchanges of data
between the components of the system, companies resolutely turned to new concepts and
technologies to allow the interoperability between the elements of their information system.
We define interoperability as the capacity for applications working in a heterogeneous system
to be able to exchange messages. The Web service is technologies which allow naturally the
interoperability between the applications. It is based on the use of standards communication
and exchange open data format (TCP / IP, HTTP, XML, JSON,). Service-oriented
architecture (SOA) is a paradigm for building the enterprise information system around a
modular architecture, based on interoperable and reusable bases. Its complementarity with the
technologies of web services increases significantly the performance of the information
system in terms of:
• Flexibility,
• Reusability,
• Interoperability.
Behind the concept of interoperability is a hiding big economic issue, these issues can be
understood differently by the companies according to their needs:
• For some, the interoperability allows to avoid the duplication of components or still
resources computing by the re-use of the existing components. It allows at the same
time to reduce the cost to the development of new components. Because nowadays
software are rarely built from zero, but by assembling the building blocks of existing
components.
• For others, the interoperability allows to combine or to compose with several
information systems to offer to the end users a strong value-added service. For
example, the purchase of a holiday may occur in nearly one vendor offering unified
services from different institution:
✓ Purchase of a plane ticket,
✓ Reservation of a hotel room,
✓ Car rental.

iv
Table des matières
Remerciement...........................................................................................Error! Bookmark not defined.
Résumé.....................................................................................................................................................ii
Abstract ...................................................................................................................................................iii
Liste des figures........................................................................................................................................v
Liste des tableaux....................................................................................................................................vi
Introduction Générale............................................................................................................................. 1
I. Introduction................................................................................................................................. 2
II. Présentation de l’entreprise d’accueil ........................................................................................ 4
III. Enjeux du Stage. ...................................................................................................................... 5
CHAP 1 : Architecture Orientée Service (SOA)........................................................................................ 6
I. Introduction................................................................................................................................. 7
II. Caractéristiques d’une SOA......................................................................................................... 9
III. Bénéfices d’une SOA ............................................................................................................. 12
CHAP 2 : Les Services Web .................................................................................................................... 13
I. Introduction............................................................................................................................... 14
II. Les services web basés sur le protocole SOAP.......................................................................... 16
III. Les Services Web basés sur le protocole REST...................................................................... 19
IV. Les différences entre REST ET SOAP...................................................................................... 20
CHAP 3 : Interopérabilité....................................................................................................................... 21
I. Introduction............................................................................................................................... 22
II. Mise en œuvre de l’interopérabilité ......................................................................................... 23
Conclusion ............................................................................................................................................. 27
I. Synthèse .................................................................................................................................... 28
II. Conclusion ................................................................................................................................. 29
Bibliographies / Neto-graphies.............................................................................................................. 30

v
Liste des figures
Figure 1: effet du concept SOA sur un système d’information. ------------------------------------------------------------------ 7
Figure 2 : évolution d’un système d’information. ----------------------------------------------------------------------------------- 8
Figure 3: présentation des fonctionnalités offertes par un service. ------------------------------------------------------------ 9
Figure 4: présentation de la notion de réutilisabilité d'un service.-------------------------------------------------------------10
Figure 5: composition de service.-------------------------------------------------------------------------------------------------------11
Figure 6: interopérabilité entre composant d'un système hétérogène. ------------------------------------------------------11
Figure 7 : architecture client/serveur--------------------------------------------------------------------------------------------------14
Figure 8 : mise en œuvre de soap-------------------------------------------------------------------------------------------------------16
Figure 9 : structure d'un message soap -----------------------------------------------------------------------------------------------17
Figure 10 : structure d'un fichier wsdl -------------------------------------------------------------------------------------------------18
Figure 11 : style architecturale REST.--------------------------------------------------------------------------------------------------19
Figure 12 : interopérabilité mode point à point.------------------------------------------------------------------------------------23
Figure 14 : EAI de type message bus---------------------------------------------------------------------------------------------------24
Figure 13: EAI de type hup and spoke -------------------------------------------------------------------------------------------------24
Figure 15 : ESB entreprise service bus -------------------------------------------------------------------------------------------------25

vi
Liste des tableaux.
Tableau 1 : bénéfice d'une SOA ---------------------------------------------------------------------------------------------------------12
Tableau 4 : différences entre SAOP & REST. -----------------------------------------------------------------------------------------20
Tableau 3 : comparaison entre EAI & ESB--------------------------------------------------------------------------------------------26

[Introduction Générale]
1
Introduction Générale

2
I. Introduction
Le système d’information des entreprises est généralement constitué d’applications
construites avec des technologies différentes (JAVA, PHP, C#, …) et parfois fonctionnant sur
des plates formes différentes (Windows, Linux, Mac OS, …) formant ainsi un système
hétérogène empêchant les applications du système de communiquer ou d’échanger les
données. Face à ces problématiques, l’interopérabilité entre les applications du système se
présente comme étant une démarche qui vise à améliorer la cohérence et l’intégration des
applications du système d’information. Pour palier à ces problèmes d’échanges de données
récurrent en informatique, de grand constructeur et grand groupe du secteur informatique
(SUN, ORACLE, IBM, …) se sont regroupé au sein de l’OMG (Object Management Group),
pour définir des standards permettant l’interopérabilité et l’intégration des composants d’un
système hétérogène. C’est donc ainsi qu’on a assisté au début des années 1992 à la création de
la norme CORBA (Common Object Request Broker Architecture). La technologie CORBA
adopte une approche essentiellement orientée objet, et repose sur une architecture
Client/serveur. Avec CORBA il est possible de faire communiquer les objets écrits avec des
langages de programmation différents.
A cause de la complexité de la mise en œuvre de la technologie CORBA, d’autres grands
constructeurs tels que SUN, MICROSOFT, ont proposés de nouvelles spécifications à savoir :
✓ RMI de SUN,
✓ DCOM de MICROSOFT,
Malgré les avantages certains de ces différentes spécifications, et au delà du fait qu’elles
permettent l’interopérabilité entre les applications d’un système hétérogène, elles ont encore
beaucoup d’inconvénients :
• Les composants EJB de la spécification RMI ne peuvent être qu’assemblés entre eux.
• Les composants DCOM ne fonctionnent que dans un environnement Windows.
• Le développement d'un logiciel par un ensemble de composants nécessite un
important travail d'analyse et de spécification.
Face à ces problématiques, les Services Web accompagnés de nouveaux paradigmes
architecturaux telle que SOA, ont émergés au début des années 1995 pour satisfaire le besoin
croissant d’agilité du système d’information des entreprises.
Les services web est une technologie qui permet l’échange de données entre les composants
d’un système hétérogène. L’intérêt de l’échange de données entre les applications est entre
autre de permettre la réutilisation des briques de base des composants applicatifs existant, et
ceux grâce à la mise œuvre du concept SOA. Le concept SOA est un modèle architectural qui
vise à construire les applications de l’entreprise autour d’une architecture modulaire basé sur
des socles Interopérable et Réutilisable par le biais des « SERVICES », de telle sorte que
l’architecture du système résultant soit plus flexible qu’une architecture monolithique. Dès

3
lors il sera facile de construire de nouvelles applications par assemblage, ou par couplage des
briques de base de composants existants.
Dans ce mémoire nous avons orientée notre étude de la manière suivante :
• Au chapitre un, nous présentons le concept SOA. Nous avons accordé une attention à
certains de ses caractéristiques les plus intéressantes, en particulier la notion de
réutilisabilité. Car s’est grâce à cette caractéristique que l’on va réduire le coût et les
délais de développement de nouvelles applications au travers de l’interopérabilité.
• Au chapitre deux, nous présentons le concept d’interopérabilité et ses enjeux. Nous
présenterons aussi les différentes techniques informatiques permettant l’échange de
données entre les applications d’un système d’information.
• En fin au chapitre trois, nous présenterons la technologie des web services, plus
particulièrement les différents modes d’implémentations.

4
II. Présentation de l’entreprise d’accueil
L’obtention du diplôme de Master 2 informatique et système option MOPS (Modèle
Optimisation Programmation et Service) à l’université d’Evry Val d’Essonne est sanctionné
par la réalisation d’un stage d’une durée de six mois soit dans un laboratoire de recherche, soit
en entreprise. Ce stage permettra à l’étudiant à sa sortie d’école d’être apte et opérationnel
pour affronter la vie professionnelle.

5
III. Enjeux du Stage.

[Architecture Orientée Service]
6
CHAP 1 : Architecture Orientée Service (SOA)

7
I. Introduction
Une Architecture Orientée Services (en anglais SOA : Software Oriented Architecture) est
un concept qui repose sur des standards ouverts, elles visent à construire les applications de
l’entreprise en tant qu'un ensemble de services et composants métier faiblement couplés de
façon à ce qu'ils soient interopérable et fortement réutilisable. Se faisant elle permettra
l’évolution progressive du système d’information.
Une SOA est donc une réponse très efficace aux problématiques que rencontrent les
entreprises. Son but est avant tout d’augmenter :
• La flexibilité,
• La réutilisabilité,
• Et l’interopérabilité des composants d’un SI.
Elle permet aussi aux entreprises d’avoir une meilleure vision de leur système d’information
et de faire face de façon optimal au changement qu’elles rencontreront :
✓ Fusion,
✓ Acquisition,
✓ Cession d’activité.
Figure 1: effet du concept SOA sur un système d’information.
Ce concept peut être vu comme une approche utilisée pour normaliser l’architecture logicielle
à travers l’entreprise. L’idée sous-jacente est de construire la vie de l’entreprise autour d’une
architecture logicielle globale décomposée en services correspondant aux processus métiers
de l’entreprise, tout en permettant une évolution progressive du système d’informations.

8
Figure 2 : évolution d’un système d’information.
L’une des idées centrales d’une SOA consiste à s’éloigner de toutes solutions orientées
technologie et de privilégier l’implantation du système en se basant sur des standards ouvert.
Ce qui permettra à l’entreprise d’utiliser les meilleures applications sur le marché, et ne les
enfermera pas dans une solution fournisseur unique.
Mettre en place une Architecture Orientée Services consiste à concevoir et construire un
système d’information et les applications qui la composent à partir d’un ensemble de service
logiciels indépendants, mais capables de communiquer les un avec les autres.
Les architectures orientées services représentent la convergence de plusieurs approches
existantes à fin d’apporter de la souplesse et une meilleure agilité au système d’information
des entreprises. Elles contribuent grandement à la normalisation ou standardisation d’un
système d’information qui est en effet une condition importante pour permettre une meilleure
interopérabilité entre les composants d’un système hétérogène.

9
II. Caractéristiques d’une SOA
Les caractéristiques d’une SOA sont multiples, bien que chacun ait son utilité, il n’est
pas nécessaire de toutes les mettre en œuvre pour respecter le concept SOA. Nous présentons
ici quelques une de ces caractéristiques les plus pertinentes.
Service
Un service au sens SOA du terme est un ensemble d’opération (définies dans une description
contenant les aspects fonctionnels et les aspects non fonctionnels de traitement de données)
mises à disposition par un fournisseur à l’attention d’un consommateur. Ce fournisseur
exécute les traitements invoqués par le client consommateur.
Figure 3: présentation des fonctionnalités offertes par un service.
Un service est la brique de base d’une architecture orientée service. Son but est de réduire les
dépendances entre les différentes briques logiciels du SI.
Une architecture reposant sur des services permet l'ouverture du système d'information et
apporte nombreux avantages :
• Une rationalisation des processus: la SOA supposant une cartographie complète du SI.
• L'interopérabilité entre les composants du système: ce type d'architecture assure une
communication complète entre les processus métiers de l'entreprise grâce aux
protocoles d'échanges standards.
• Une utilisation externe des services: un SI interne basé sur les services permet la
communication avec des partenaires ou clients externes à l'entreprise.
Les services web représentent l’implémentation la plus utilisée pour appliquer l’architecture
SOA. Le concept de service web regroupe un ensemble de technologies basées sur XML,
permettant de créer des composants logiciels distribués, de décrire leurs interfaces et de les
utiliser en mettant en œuvre des standards tels que SOAP ou REST.

10
Dans le cadre d’une SOA, un service à généralement les caractéristiques suivantes :
• Standardisation : les services exposés doivent respecter les mêmes règles de
standardisation.
• Le contrat de service : il détaille les conditions d’utilisation du service sous forme de
pré et post conditions, protocoles, et contraintes (QoS, SLA).
• Autonomie : le service est autonome car il ne fait pas appel à aucun autre système
tiers. Il n’en n’est pas dépendant. Ce qui par ailleurs le rend prédictible.
• Sans état : le service ne doit pas conserver d’état (résultats d’exécution ou autres).
Réutilisabilité
La réutilisabilité de service est la capacité d’un service d’être partagé entre plusieurs services
ou applications. Elle est une caractéristique fondamentale de l’architecture SOA, c’est grâce à
elle que l’on va rendre le système d’information flexible et réactif en permettant d’accélérer le
développement de nouvelles application qui vont utiliser ces services.
Figure 4: présentation de la notion de réutilisabilité d'un service.
La notion réutilisabilité est fondamentale pour les entreprises qui désirent réduire le coût de
développement de nouvelles applications. Car de nos jours les logiciels sont rarement
construits à partir de zéros, mais par assemblage des briques de base des composants existant.
Elle permet aussi de préserver la flexibilité du système d’information. Un système
d’information mal organisée peut potentiellement créer des situations anarchiques, et apporter
une certaine complexité à l’évolution du système. Il est donc nécessaire de se doter des
meilleures pratiques et outils techniques qui permettront de se prémunir contre ces situations.
Une telle réalisation permettra, d’avoir un système d’information plus simple à lire, et à
maîtriser, et le système d’information en sera d’autant plus gouvernable. Toute volonté
d’évolution sera plus facile et plus rapide à concrétiser.
Composition de services

11
La composition de service permet de composer des services entre eux pour ensuite exposer ce
« méta-service » sous forme d’un nouveau service à valeur ajouté fort, et ainsi de suite
récursivement. On peut ainsi voir émerger une hiérarchie de services arbitrairement complexe.
Figure 5: composition de service.
Interopérabilité
L’hétérogénéité des systèmes et en particulier la multiplication des applications, accompagnée
d’exigences de plus en plus fortes en termes de qualité de service représentent des défis
permanents pour les directions de systèmes d’information. L’une des conséquences directes
de cette évolution est la nécessité pour l’entreprise de maîtriser les échanges d’information et
les services au sein de la société et avec ses partenaires ou clients. L’interopérabilité est donc
la capacité pour les systèmes d’information hétérogènes de pouvoir échanger les informations
c'est-à-dire de pouvoir communiquer.
Figure 6: interopérabilité entre composant d'un système hétérogène.

12
III. Bénéfices d’une SOA
Outre les avantages du développement rapide des logiciels, une SOA permet de faire
évoluer rapidement le système d’information de l’entreprise pour l'aligner sur les conditions
du marché, grâce au fait que les logiciels sont maintenant flexibles, réutilisables et
interopérables.
Par la nature faiblement couplée de SOA; On peut résumer dans un tableau ses qualités
évidentes :
Caractéristiques d’une SOA Bénéfices
Maintenance et remplacement de
composants facile
Facilité de remplacement des composants existants.
Facilement adaptable aux changements de processus d’affaires.
Rapidité de mise en œuvre de nouvelles fonctionnalités.
Basé sur la notion de service et
contrat de service
Nécessite peu d’effort pour connecter un nouveau système.
Intégration ou fusion facile avec des partenaires.
Permet l’automatisation des processus d’affaires.
Autonomie des services Temps d’arrêts et coût opérationnel réduit
Flexibilité Maitrise de la qualité de service.
Intégration facile de système.
Tableau 1 : bénéfice d'une SOA
Malgré les avantages du concept SOA, son adoption peut poser de nouveaux défis, à relever :
✓ Un manque de Maturité (Les outils de développement utilisés pour la mise en œuvre
d’une SOA n’ont pas encore atteins un bon niveau de maturité).
✓ Un « Time to market » parfois trop important (car nécessite des efforts supplémentaire
pendant la phase de conception et dans bien de cas les équipes reste immature.
✓ L’aspect sécurité reste immature (le concept SOA n’aborde pas suffisamment l’aspect
sécurité).
Comme toute technologie, SOA a ses avantages et ses limites. L’important est de bien profiter
de ses apports et savoir pallier ses limites, pour cela il faut adopter une stratégie bien
déterminée et savoir choisir la manière avec laquelle on va mettre en place cette architecture.

Interopérabilité
13
CHAP 2 : Les Services Web

[Les Services Web]
14
I. Introduction
Au delà de l’effet de mode, les services web peuvent être perçus comme étant la pierre
angulaire des Architectures orientées services (SOA). Un web service est une application
logicielle reposant sur une architecture client-serveur.
Les services web est une technologie qui permet l’échange de messages entre les composants
d’un système d’information. Sa particularité est d’utiliser le protocole HTTP comme support
d’échange de messages entre les parties communicantes.
L’avantage de l’utilisation du protocole HTTP est qu’il utilise les ports standard 80, 8080, …
qui sont généralement ouvert et ne nécessite aucune configuration pour être autorisés sur le
réseau, que ce soit en interne ou en externe.
Les services web sont basés sur le style d’architecture client/serveur. Une application
fonctionnant selon le principe de l’architecture client-serveur présente les avantages suivants :
1. Les fonctionnalités métier de l’entreprise sont présentes sur des serveurs distants, et
peuvent être utilisées simultanément par un grand nombre d’utilisateurs.
2. Les serveurs distants peuvent disposer d’une puissance de calcul ou de stockage que
ne possèdent pas les machines locales.
3. Sa mise à jour ou sa maintenance n’intervient qu’à un seul endroit.
Figure 7 : architecture client/serveur

[Les Services Web]
15
Plusieurs technologies ont ouvert la voie aux technologies web, parmi elle on peut citer :
• CORBA (Common Object Request Broker Architecture de l’OMG),
• DCOM (Distributed Component Object Model de MICROSOFT),
• RMI (Java To Enterprise Edition de SUN),
CORBA est une technologie orientée objet permettant l’invocation de méthodes sur des objets
distants fonctionnant sur des systèmes hétérogènes. L'organisme responsable est l'OMG.
DCOM est une technologie orientée objet permettant l’invocation de méthodes sur des objets
distants fonctionnant sur des systèmes Windows.
RMI est une technologie orientée objet permettant l’invocation de méthodes sur des objets
distants fonctionnant sur des machines virtuelles JAVA.
L'intégration d'applications qui ne respectent pas les spécifications DCOM et RMI se fait au
moyen de connecteurs spécifiques.
Les services web permettent l’échange de données entre les applications d’un système
hétérogène. Ils ont l’avantage d’être simple à mettre en œuvre, l'OASIS et le World Wide
Web Consortium (W3C) contribuent à la standardisation de son architecture afin de faciliter
l’interopérabilité entre les composants d’un système d’information hétérogène.
L’idée fondamentale derrière les services web est de construire les applications et
processus métiers en brique réutilisables appelés « service » de sorte que chaque service
offert effectue une tâche distincte. Les services web offrent donc aux entreprises une certaines
flexibilité pour leur système d’information, ce qui leur permet de répondre, voir même
d’anticiper avec efficacité au besoin changeant de leurs clients.
Il existe deux grands modes d’implémentation des services web:
• Les web services basés sur le protocole SOAP (Simple Object Access Protocol).
• Les web services basés sur le protocole REST (Representational State Transfer).

[Les Services Web]
16
II. Les services web basés sur le protocole SOAP
SOAP (Simple Object Access Protocol ou Service Oriented Architecture Protocol),
SOAP est un protocole d'invocation de méthodes sur des services distants. Basé sur XML
pour l’échange des messages. De par sa maturité, il est couramment utilisé pour le
développement de web service. L’un de ses avantages est qu’il peut être utilisé par plusieurs
protocoles de communication (http, SMTP, FTP, JMS, …).
SOAP est une recommandation du W3C dont les initiateurs sont Microsoft, IBM, Lotus,
DevelopMentor et Userland. SOAP a été construit de manière à ce qu’il puisse être
extensible et facilement intégrable aux technologies déjà existantes.
Il existe actuellement deux versions de spécification de SOAP :
• SOAP v1.1
• SOAP v1.2
C’est deux version sont retro-compatible, ce qui veut dire que la version 1.2 de SOAP peut
réaliser tous les fonctions remplis par la version 1.1 et même plus.
Figure 8 : mise en œuvre de soap
➢ Le serveur (service provider) publie une liste de ses services web sur l’annuaire
UDDI (service broker) dans un document au format WSDL.
➢ Le client (service requester) désire invoquer une méthode située sur une machine
distante ; il effectue une requête vers l’annuaire UDDI, afin d’obtenir un ou plusieurs
services web correspondant à la méthode demandée.
➢ L’annuaire UDDI transmet au client un document WSDL avec la méthode, ces
paramètres ainsi que l’adresse du serveur sur lequel effectuer l’appel.
➢ Le client envoie alors sa requête au serveur sous forme de message SOAP; le serveur
répond en suite à la requête en renvoyant un message SOAP au serveur.

[Les Services Web]
17
Les standards UDDI & WSDL représentent les éléments de base pour la création de service
web de type SOAP.
Structure d’un Message SOAP
Le standard SOAP définit trois éléments composant un message :
✓ L’enveloppe : L’enveloppe définit le cadre pour décrire ce qui est dans le message et
comment le traiter.
✓ L’entête du message : Les règles d’encodages sont placées dans l’en-tête et servent à
exprimer et définir le mécanisme de représentation des données.
✓ Le corps du message : Le corps du message permet de transmettre les requêtes et les
réponses entre les systèmes.
Figure 9 : structure d'un message soap
UDDI (Universal Description, Discovery, and Integration)
Est une plate forme pour la localisation et la publication du Service Web. Elle permet
d'enregistrer de l'information concernant les types de services disponibles. Elle fournit un
mécanisme de publication et de recherche de services. Elle est basée sur des standards tels que
HTTP, SOAP et WSDL. L’organisme chargé de sa normalisation est l’OASIS.
Il existe des registres publics, suivant le standard UDDI, où, à la fois, des fournisseurs de
services peuvent publier leurs services et des demandeurs de services peuvent trouver ces
services. Un registre UDDI est décomposé en pages :
• Blanches (incluent des informations telles que le nom et l'adresse d'une entreprise),
• Jaunes (catégorisent les entreprises en fonction du type d'affaires qu'elles effectuent),
• Vertes (décrivent le genre de services offerts ainsi que les techniques de
communication à employer pour joindre ces services).

[Les Services Web]
18
WSDL (Web Services Description Language)
Est un fichier basé sur XML, qui permet de décrire les différentes opérations offertes par un
service. Cette description peut être interprétée, sans la moindre intervention humaine, par une
entité distribuée désireuse de trouver et ensuite d'invoquer un service particulier. A l’heure
actuelle il existe deux versions de la norme : la 1.1, et la 2.0.
Un fichier WSDL est généralement divisé en deux grandes parties :
Figure 10 : structure d'un fichier wsdl
• La partie abstraite est constituée d’éléments qui permettent de décrire les services
indépendamment de la plate forme. Cela facilite la compréhension, des services
pouvant être implémenté.
• La partie concrète est constituée d’éléments représentant les données transmises lors
d’une communication entre le client et le serveur.

[Les Services Web]
19
III. Les Services Web basés sur le protocole REST.
REST (Representational State Transfer), a été décrit en l’an 2000 par Roy Thomas
Fielding dans sa thèse « Architectural Styles and the Design of Network-based Software
Architectures ». Où il la présente comme étant un style d’architecture logicielle permettant de
construire une application devant fonctionner sur des Architectures client-serveur, supportant
le protocole HTTP/HTTPS.
REST n’est pas un protocole, il n’existe pas de norme en tant que telle (il n'existe pas de
spécification du W3C pour la décrire), mais plutôt des conventions de codage respectant
certain principe. Un service web utilisant HTTP et ces principes est généralement qualifié de
RESTful. Les contraintes généralement posées par le style d’architecture REST sont :
• Sans état (stateless) : ce qui veut dire qu’au niveau serveur, on ne traite pas une
requête en référençant des éléments d’une requête précédente. Au niveau http, cela
veut dire que l’on ne crée pas de session utilisateur dans laquelle on stock des
informations.
• Possibilité d’utiliser un mécanisme de cache, cela consiste essentiellement à
l’utilisation de serveur proxy.
• Interface uniforme : c’est le point principal de la différence avec soap, car tout élément
offert à la manipulation par l’application est nommé ressource et est identifier de
manière unique. HTTP définit les Identifiants de Ressource Uniforme (URI ci-après)
suivant le schéma : http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]].
• Les différentes actions possibles sur les ressources sont : GET, POST, PUT, DELETE.
Figure 11 : style architecturale REST.

[Les Services Web]
20
IV. Les différences entre REST ET SOAP.
SOAP REST
met l’accent sur la notion de service propose une vision du Web concentrée sur le
concept d'une ressource
Ajoute une couche supplémentaire au
protocole HTTP. Ce qui le rend au final
assez lourd à manipuler à cause de
l’utilisation de XML imposé par SOAP.
utilise essentiellement le protocole HTTP et son
plein potentiel. Les données peuvent être
formatées en JSON ou XML.
Possibilité de choix entre différent type de
transport : HTTP, SJMS, FTP, SMTP…
HTTP/HTTPS uniquement.
Tableau 2 : différences entre SAOP & REST.
REST connaît un grand succès en ce moment, confirmé par l'intérêt d'acteurs tels que
Google, Yahoo ou encore Amazon. Afin de comparer SOAP et REST, Amazon a décidé de
fournir les même fonctionnalités de services sous forme de services Web SOAP et REST.
Le résultat des accès était REST = 80 %, SOAP = 20%
Les utilisateurs de ces services Web ont massivement opté pour l'architecture REST puisque
80% des accès sont effectués par le canal des Services Web REST.
Malgré la maturité et les multiples avantages offerts par le protocole SOAP, le nombre de ses
spécifications et sa complexité de mise en œuvre à complètement remis en cause les
avantages de son utilisation. De plus l’utilisation de XML imposé par SOAP est souvent mal
perçue par les développeurs. Car XML à la particularité d’être assez verbeux, et le temps
qu'il faut pour son analyse syntaxique est souvent long.
REST rencontre un fort succès parce qu'il est simple à utiliser et à implémenter, et qu'il
correspond parfaitement à ce dont les entreprises ont besoin dans le web, pour créer des web
services.
Malgré les avantages de REST liés à sa simplicité, il présente néanmoins des inconvénients :
• REST ne supporte aucun mécanisme standardisé de sécurité.
• Absence de dispositif d'orchestration de processus métier.

Interopérabilité
21
CHAP 3 : Interopérabilité

[Interopérabilité]
22
I. Introduction
L’interopérabilité entre les composants d’un Système d’Information est la capacité de
ces composants de pouvoir échanger des messages. Elle s’appuie sur des normes et des
standards de préférence ouvert (protocole de communication, format d’échange de données)
adoptées entre les parties communicantes facilitant ainsi l’échange de données entre les
composants du système.
On distingue trois niveaux différents d’interopérabilité :
• Interopérabilité technique,
• Interopérabilité sémantique,
• Interopérabilité syntaxique.
L’interopérabilité technique fait appel à l’infrastructure et aux protocoles pour permettre entre
autre le transfert de données entre machines distantes. On peut citer à titre d’exemple, les
protocoles HTTP, TCP/IP, … ce niveau d’interopérabilité appartient au domaine des réseaux
informatique.
L’interopérabilité sémantique se base sur la signification des messages échangés, elle permet
de s’assurer que les données échangées conservent bien leurs sens. C'est-à-dire que les
machines communicantes on une même interprétation des données qu’elles échangent.
L’interopérabilité syntaxique vise à garantir une certaine cohérence des informations
échangées, elle porte essentiellement sur la structure, ou la représentation des messages
échangés. XML et JSON sont deux formats de données régulièrement utilisé pour le
développement du Web. Si le premier est le plus connu, parce que utilisé massivement et
depuis longtemps, le second fait ces derniers temps une percée fulgurante.
Les avantages de l’interopérabilité sont multiples :
• Interconnecter des applications écrit sur différent langage (c, java, PHP, etc.),
• Interconnecter des applications fonctionnant sur des plates formes différentes
(Windows, Linux, Mac OS, …).
• Faciliter l’intégration des applications existante.
• Fournir des services métiers à forte valeur ajouté.
D’un point de vue technique, l’interopérabilité entre les composants du système d’information
est invisible aux utilisateurs finaux.

23
II. Mise en œuvre de l’interopérabilité
A l’heure actuelle, il existe plusieurs techniques permettant l’interopérabilité entre les
composants d’un système d’information. Nous pouvons citer entre autre :
✓ Les Services Web en mode Point to Point,
✓ Les EAI,
✓ Les ESB.
Les Services Web en mode point to point
Les services web permettent l’échange de message de façon normalisé entre les composants
d’un système hétérogène. Cette technologie est essentiellement basée sur le protocole HTTP.
La mise en place d’une telle architecture peut s’avérer extrêmement coûteuse dans le cas ou le
nombre de composant à interconnecter est important. Car l’intégration d’une nouvelle
application dans ce contexte d’architecture, nécessite un effort supplémentaire de
configuration d’un nouveau connecteur pour chaque composant existant, de plus il est difficile
d’avoir une bonne visibilité en terme d’administration de l’ensemble d’un tel système.
Ainsi on estime à
(𝒏 𝟐− 𝒏)
𝟐
le nombre de pont d’interconnexion entre les composants du système
(avec n= nombre de composant à interconnecter).
Figure 12 : interopérabilité mode point à point.

24
EAI – Enterprise Application Intégration
Les EAI permettent de gérer les échanges entre les différentes applications dans un
système d’information hétérogène. Souvent appelé super-connecteur ou médiateur, ils
prennent en compte un ensemble de problématiques techniques tel que :
Mapping entre services,
• Traitement des Messages,
• Routage,
• Monitoring.
Les EAI proposent deux types d’architecture :
• Hub and Spoke dans laquelle un composant central assure la médiation physique
entre le client et sa cible.
• Message Bus utilise un système de messagerie basé sur les standards tel que MOM
(Middleware Orienté Message), pour la propagation des messages. Les messages sont
publiés à l'aide d'adaptateurs de bus.
Figure 13 : EAI de type message bus
Figure 14: EAI de type hup and spoke

25
ESB – Entreprise Service Bus
Les ESB peuvent être perçues comme une nouvelle génération d'EAI construite sur
des standards ouverts facilitant l’interconnexion entre les applications d’un système
hétérogène. Ils prennent en compte un ensemble de problématiques techniques tel que :
• Mapping entre services,
• Traitement des Messages,
• Routage,
• Monitoring.
L'ESB propose un style architectural qui exploite les services web, les systèmes orientés
messages, le routage intelligent et la transformation. L'ESB agit comme une colonne
vertébrale légère et omniprésente de l'intégration à travers laquelle les services logiciels et les
composants applicatifs circulent. Peuvent venir se greffer à cette architecture:
• Le Business Activity Monitoring (BAM) qui permet de suivre l'activité d'un processus
métier.
• Le Business Process Management (BPM) qui a pour but de maîtriser l'orchestration
des processus métier, c'est-à-dire l'enchaînement des échanges entre applications.
Figure 15 : ESB entreprise service bus

26
Différence entre EAI & ESB
La différence majeure avec l'EAI réside dans le fait que l'ESB propose une intégration
complètement distribuée grâce à l'utilisation des conteneurs de services. Ces "mini-serveurs"
contiennent la logique d'intégration et peuvent être déposés n'importe où sur le réseau.
L’utilisation des middlewares telle que JMS permet de passer aisément d'une architecture en
mode point to point à un bus d'échanges fonctionnant en mode dynamique. De plus les ESB
sont généralement construis à partir des standards ouverts.
Le tableau ci-dessous présente les différences fondamentales entre une EAI et un ESB. Nous
avons omis expressément d’associer à ce tableau les services web en mode point to point, car
les EAI et les ESB sont construits autour de cette technologie.
Catégorie EAI ESB
Architecture Monolithique, et standard
propriétaire
Standard ouvert
Point centrale Structure centralisé Structure distribué
Administration Framework central simple et
facile à contrôler
Framework distribué et difficile de
contrôle.
Fiabilité Peu fiable car « single point
of failure »
Très fiable en « l’absence du « single
point of failure »
Coût Comparativement coûteux,
nécessite une formation type
propriétaire.
Moins coûteux due au facteur open
standard, et maintenance facile
Tableau 3 : comparaison entre EAI & ESB
Les solutions d'EAI souffrent de leur caractère très propriétaire :
La technologie interne aux EAI est propriétaire. Ainsi, l’accès aux applications se fait par
l’intermédiaire de connecteurs encore largement spécifiques à chaque éditeur (ces connecteurs
sont souvent très onéreux). Ainsi, un grand nombre de projets de mise en œuvre d'EAI ont
été complexe et beaucoup plus long que prévu, ne tenant au final pas leurs promesses en
terme de retour sur investissement(ROI).

[Conclusion]
28
I. Synthèse
Les bénéfices de l’interopérabilité entre les systèmes d’informations sont incontestables et
ses contours peuvent varier d’un interlocuteur à l’autre.
• Pour certains, l’interopérabilité permet d’éviter la duplication des composants ou
encore des ressources informatique par la réutilisation des composants existant. Cela
permet par la même occasion de réduire le coût lié au développement de ces nouveaux
composants. Car de nos jours les logiciels sont rarement construits à partir de zéros,
mais plutôt par assemblage des briques de base des applications existantes.
• Pour d’autres, l’interopérabilité permet de combiner ou de composer avec plusieurs
systèmes d’information afin d’offrir aux utilisateurs finaux un service à valeur ajoutée
forte. Par exemple l'achat d'un séjour touristique peut s’effectuer au près d’un seul
vendeur offrant ainsi des services unifiés en provenance d’institution différentes :
✓ Achat d’un billet d'avion,
✓ Réservation d’une chambre d’hôtel,
✓ Location de voiture.
Dans le chapitre un de ce mémoire, nous avons étudié les caractéristiques du concept SOA.
Nous avons prêtés une attention particulière à la notion de réutilisabilité car elle correspond
entre autre au besoin d’interopérabilité entre les composants logiciels de la plate forme
SIMEO d’OXAND.
Dans le chapitre deux nous avons étudié les Services Web, nous avons vu qu’il existe deux
grand mode d’implémentation. Nous avons présentés les points forts et les points faibles de
chaque mode d’implémentation des Services Web. Le but de cette étude était surtout de
choisir le mode d’implémentation qui correspond le mieux aux besoins d’implémentation des
Services Web à la plate forme SIMEO.
Dans le chapitre trois nous avons étudié les différentes techniques permettant
l’interopérabilité entre les composants d’un système hétérogène.
En entreprise, nous avons décidés de mettre en œuvre le style architectural REST. Ce style
d’architecture est basé sur la manipulation des ressources à distance, il est relativement simple
à mettre en œuvre, et présente de très bonne performance. De plus REST n’impose pas
l’utilisation de XML, qui est souvent assez lourd comparativement à JSON.
Malgré sa complexité, SOAP, présente néanmoins de très bonnes caractéristiques, et peut
parfois correspond aux besoins des entreprise. Nous avons vus par exemple qu’il était
possible d’utiliser d’autres protocoles de communication (SMTP, FTP, ...) autre que le HTTP.
Que l’on utilise SOAP ou REST, un problème se pose toujours : comment faire pour sécuriser
l’accès au système d’information, et garantir l’intégrité et la confidentialité des données. Cette
problématique importante n’a pas pu être abordé vu le temps assez court de la durée du stage.
Elle demeure néanmoins comme étant une perspective que l’on traitera au plutôt.

[Conclusion]
29
II. Conclusion
La démarche d’interopérabilité est porteuse de bénéfice, pour les entreprises ayant fait le
choix de la mettre en œuvre. Mais elle peut très vite devenir une caractéristique critique pour
les entreprises nécessitant de forts échanges de messages. La complémentarité des services
web et du paradigme SOA, permet d’améliorer considérablement les performances d’un
système d’information. On peut donc dire qu’une SOA n’est pas un produit que l’on peut
acheter, c’est un ensemble de concept à mettre en œuvre pour construire des systèmes
d’informations à architectures flexibles. Elle contribue grandement à apporter de la souplesse
à l’architecture du système d’information par la modularité de ses composants.
Les services web permettent naturellement l’interopérabilité entre les applications. L’un
de ses avantages est que les protocoles d’invocation des services (HTTP, TCP/IP) sont
universels et ne nécessitent apriori aucune configuration. Mais seulement cette technologie est
limitée à ces seuls protocoles d’invocation. Les entreprises nécessitant une interopérabilité à
grande échelle, voir même international ont généralement recours à l’utilisation des
médiateurs telle que les EAI ou les ESB qui ont cette capacité technique à prendre en charge
les différents niveaux d’interopérabilité. Avec ces médiateurs, il est possible d’interconnecter
par exemple une application fonctionnant avec le protocole HTTP et une autre fonctionnant
avec le protocole SMTP.
Afin de favoriser l’interopérabilité entre les composants d’un système d’information, il est
tout aussi important de se poser des questions sur le choix du style architectural à mettre en
œuvre c'est-à-dire :
• Une approche orientée appel de procédure à distance telle que SOAP,
• Ou une approche basée sur la manipulation de ressources telle que REST.
Les décisions que l’on aura à prendre auront un impact sur les performances du système
d’information en terme de :
• Complexité,
• Flexibilité,
• Obsolescence technique,
• Montée en charge.
En l’état actuel des choses, on utilise :
• REST pour sa simplicité,
• SOAP pour le support du W3C.
En matière de service web, on recherche généralement un compromis entre la perfection
théorique des protocoles, et leur simplicité de mise en œuvre. Les architectures du Web en
particulier privilégient la simplicité et la performance.

[Glossaire]
30
Bibliographies / Neto-graphies
SOA - 3ème édition - Le guide de l'architecte d'un SI agile. Xavier Fournier-Morel (Auteur),
Pascal Grojean (Auteur), Guillaume Plouin (Auteur), Cyril Rognon (Auteur).
Architecture logicielle - Pour une approche organisationnelle, fonctionnelle et
techniqueThomas BAILET (Auteur)
http://architectures-web.smile.fr/Urbanisme-et-soa/Trois-protocoles-pour-les-services-web
http://www.zdnet.fr/actualites/soa-comment-creer-des-applications-a-partir-de-services-de-
faible-granularite-39124586.htm
http://blog.xebia.fr/2009/04/16/soa-du-composant-au-service-la-reutilisabilite/
http://www.objis.com/formation-java/comprendre-web-services-architecture-wsdl-uddi-soap-
soa.html
http://searchsoa.techtarget.com/tip/REST-vs-SOAP-How-to-choose-the-best-Web-service
http://www.infoq.com/articles/rest-soap-when-to-use-each
http://blog.manishchhabra.com/2013/04/rest-and-soap-web-services-analogy/
http://www.jboss.org/jbossesb
http://ggatz.com/images/Enterprise_20Integration_20-_20SOA_20vs_20EAI_20vs_20ESB.pdf
http://manojpurohit.wordpress.com/2010/09/27/difference-between-soa-eai-and-esb/

Interopérabilité des Services Web dans le cadre d’une Architecture SOA

Contenu connexe

Similaire à Interopérabilité des Services Web dans le cadre d’une Architecture SOA (20)

Interopérabilité des Services Web dans le cadre d’une Architecture SOA