ARCHITECTURES ORIENTEES SERVICES

SOMMAIRES
SOMMAIRES ...................................................................................................................................1
GLOSSAIRES...................................................................................................................................2
SIGLES ET ABREVIATIONS.........................................................................................................3
LISTES DES FIGURES ...................................................................................................................4
INTRODUCTION ............................................................................................................................5
CHAPITRE 1 : CONTEXTE ET PROBLEMATIQUE ..................................................................6
I. CONTEXTE ..............................................................................................................................7
CHAPITRE 2 : ETAT DE L’ART ................................................................................................. 10
I. QU’EST-CE QUE L’ARCHITECTURE ORIENTEE SERVICE ? ............................................ 11
II. FONCTIONNEMENT DE l’ARCHITECTURE ORIENTEE SERVICE ................................... 12
III. PROTOCOLES ET NORMES .............................................................................................. 17
IV. LES APPORTS DE L’ARCHITECTURE ORIENTEE SERVICE ......................................... 18
V. EXEMPLE D’ARCHITECTURE ORIENTEE SERVICE ......................................................... 20
CONCLUSION ................................................................................................................................ 22

1
 ARCHITECTURES ORIENTEES SERVICES

GLOSSAIRES

Service web : Composant applicatif présentant une interface standardisée (au format WSDL),
accessible au travers d’Internet grâce au protocole SOAP.

Web Service Oriented Architecture, SOA mise en œuvre grâce à l’utilisation de

services Web et de leur annuaire de référencement UDDI.

Entreprise Resource Planning, ou PGI pour Progiciel de gestion intégré en français.

Logiciel permettant de gérer l’ensemble des processus d’une entreprise. Les données sont
standardisées sur une seule base de données commune à toutes les applications de
l’entreprise.

Workflow c’est la modélisation et la gestion informatique de l’ensemble des tâches à accomplir

et les communications entre les différents acteurs impliqués pour la réalisation d’un processus
métier.

Hypertext Transfert Protocol est le standard sur Internet pour les liaisons entre les
différentes ressources à partager.

2
 ARCHITECTURES ORIENTEES SERVICES
SIGLES ET ABREVIATIONS

SOA : Service Oriented Achitecture

ERP : Entreprise Resource Planning

WSOA : Web Service Oriented Architecture

WSDL : Web Services Description Language

WOA : Web-oriented architecture.

UDDI : Universal Description Discovery and Integration

3
 ARCHITECTURES ORIENTEES SERVICES

LISTES DES FIGURES

Figure 1 : (concepts du SOA) ............................................................................................................. 13
Figure 2: (cycle de vie de service du SOA) .......................................................................................... 16
Figure 3 : (illustration de l'architecture 3 tiers) .................................................................................. 19
Figure 4 : (exemples d'application REST) ........................................................................................... 21

4
 ARCHITECTURES ORIENTEES SERVICES

INTRODUCTION
Les SOA (Service Oriented Architecture - ou Architecture Orientée Services) sont
souvent assimilés à des technologies mais ce sont en réalité des principes d’architectures. En
effet, la notion de SOA renvoie à une nouvelle manière d'intégrer et de manipuler les
différentes briques et composants applicatifs d'un système informatique (comptabilité,
gestion de la relation client, production, etc.) et de gérer les liens qu'ils entretiennent. Cette
approche repose sur la réorganisation des applications en ensembles fonctionnels appelés
services. Avant l’arrivée des SOA, les services d’une entreprise étaient développés au sein
d’une application monolithique c'est-à-dire déployé sur un serveur central. Petit à petit, le
modèle distribué s’est mis en place, permettant plus de souplesse dans la gestion du
système d’information. En effet, les systèmes d’informations des entreprises sont constitués
d’applications et de données constituants leurs héritages. Avec la fusion des groupes et
l’évolution des technologies ces héritages deviennent hétérogènes et ont tendance à se
spécialiser par métier au travers des services. On peut alors avoir une vision globale du
système d’information d’une entreprise. Ainsi, une nouvelle conception est apparue utilisant
les modèles distribués. Celle-ci, conceptualisée par le Gartner Group, le SOA tente de
s’imposer en rendant les applications plus souple et réutilisable. Les SOA s’appuient sur des
standards et peuvent fonctionner dans des environnements hétérogènes. Le principal but
des SOA est d’améliorer l’interopérabilité entre les systèmes sans créer de contraintes
fortes. En effet, les différents services n’ont pas besoin de répondre aux mêmes contraintes
structurelles tant qu’ils respectent un contrat. Il existe une faible interdépendance entre les
services. Les SOA sont utilisés pour le développement des applications à long termes. Ils
induisent une bonne conception et donc une maintenance du code facilité ainsi que l’ajout
de nouveaux services sans endommager l’application existante.

Dans ce document, nous allons essayer de voir les avantages d’utiliser ce modèle de
conception. Tout d’abord, il faut donc étudier les différentes définitions relatives à un SOA.
Dans une deuxième partie, nous allons nous intéresser aux performances ainsi qu’aux
inconvénients de mettre en place ce type de conception. Et enfin, nous allons observer un
exemple d’architecture SOA.

5
 ARCHITECTURES ORIENTEES SERVICES

CHAPITRE 1 : CONTEXTE ET
PROBLEMATIQUE

Aperçu :

I. CONTEXTE

6
 ARCHITECTURES ORIENTEES SERVICES

I. CONTEXTE
1. HISTORIQUE
Au cours de la décennie 1980-1990, la problématique de l'interopérabilité des systèmes
d'information, particulièrement complexe lors de la fusion ou de l'acquisition d'entreprises, a
donné naissance au domaine de recherche de l'interopérabilité des données ; c'est à cette époque
que l'on distingua l'interopérabilité syntaxique de l'interopérabilité sémantique des données. Ces
recherches aboutirent aux systèmes multibases, aux développements des bases de données
réparties et à l'architecture fédérée. En raison de nombreux problèmes insolubles, l'architecture
fédérée fut pratiquement abandonnée.

Les deux principales exigences fonctionnelles qui se sont dégagées au cours de cette période
sont :

• Les différents producteurs d'information doivent pouvoir continuer à utiliser leur

système de façon transparente. Par exemple, un trust réalisant une acquisition ne doit pas
handicaper son nouveau membre en imposant un changement brutal de système
informatique ;
• L'organisation doit pouvoir obtenir une synthèse de l'information produite par ses
différents membres. Il s'agit ici d'information en lecture seule, la synthèse s'effectuant
toujours du bas vers le haut.

Ces exigences fonctionnelles se cristallisèrent avec l'invention par Gio Wiederhold de

l'architecture de médiation en 1990-1992 :

• Les usagers finaux sont séparés des sources de données par une couche de médiation
(couche de services) permettant une synthèse dynamique de l'information ;
• Les différents médiateurs (services) peuvent communiquer entre eux pour transformer
et combiner l'information provenant de différentes sources ;
• Les différents médiateurs (services) communiquent en utilisant un langage offrant une
grande capacité d'expression sémantique et de transformation.

La recherche sur la médiation de données porta alors sur la création d'architecture générique
comme le ARPA I3 où apparurent les cinq grandes familles de services (Adaptation,

7
 ARCHITECTURES ORIENTEES SERVICES
Transformation, Extension, Management et Coordination), le développement de langages à
haute expressivité sémantique comme KQML et les outils de transformation sémantique de
l'information comme les ontologies. Parallèlement, le développement de la technologie Web
rendit progressivement les autres technologies d'informatique distribuée de moins en moins
attrayantes. L'arrivée en 1996 d'XML provoqua un engouement pour ce langage dans le milieu
de la recherche et les langages ad-hoc ou plus complexes comme KQML furent pratiquement
abandonnés, du moins pour ce type d'architecture. L'industrie développa de nombreux produits
sous l'impulsion de la recherche fondamentale, par exemple, on compte plus de 150 Ph.D. en
ligne directe de Wiederhold5, la plupart ayant participé activement au développement de cette
technologie chez IBM, Oracle, Sun, Microsoft, Cisco, Samsung, LG, Bell Laboratories,Silicon
Graphics, Kodak, Google, Napster et autres ; comme James Duncan Davidson qui fut le
créateur de Tomcat (Java Servlet et JavaServer Pages) ainsi que de Ant. À la fin de la décennie
1990-2000, on trouvait un nombre considérable de ce type de technologies dont
l'interopérabilité était parfois extrêmement problématique, du moins sans recette logicielle pour
la réaliser.

2. PROBLEMATIQUE

Dans la vie de tous les jours, un fournisseur offre un service à un client le consommant dans
une relation de confiance établie entre les deux parties. En général, le client s’intéresse
uniquement au résultat produit du service sans avoir le besoin ni le souci de savoir comment ce
dernier est obtenu. Le SOA suit ce même principe. Le service est une action exécutée par un
« fournisseur » (ou « producteur ») à l'intention d'un « client » (ou « consommateur »),
cependant l'interaction entre consommateur et producteur est faite par le biais d'un médiateur
(qui peut être un bus) responsable de la mise en relation des composants. Le service étant à
grandes mailles, il englobe et propose les fonctionnalités des composants du système. Ces
systèmes peuvent aussi être définis comme des couches applicatives. L'architecture orientée
services est une réponse très efficace aux problématiques que rencontrent les entreprises en
termes de réutilisabilité, d'interopérabilité et de réduction de couplage entre les différents
systèmes qui implémentent leurs systèmes d'information. Les SOA ont été popularisées avec
l'apparition de standards comme les Services Web dans l'e-commerce (commerce électronique)
(B2B, inter-entreprise, ou B2C, d'entreprise à consommateur), fondés sur des plates-formes

8
 ARCHITECTURES ORIENTEES SERVICES
comme Java EE ou .NET. Elles mettent en application une partie des principes d'urbanisation.
Au sein de l'architecture orientée services, on distingue les notions d'annuaire, de bus, de contrat
et de service, ce dernier étant le noyau et le point central d'une architecture orientée services.
La déclinaison ou plus précisément la mise en œuvre de la SOA qui repose entièrement sur
Internet est appelée la WOA (Web-oriented architecture).

9
 ARCHITECTURES ORIENTEES SERVICES

CHAPITRE 2 : ETAT DE L’ART

Aperçu :
I. QU’EST CE QUE L’ARCHITECTURE ORIENTEE SERVICE ?

II. FONCTIONNEMENT DE L’ARCHITECTURE ORIENTEE SERVICE

III. PROTOCOLES ET NORMES

IV. LES APPORTS DE L’ARCHITECTURE ORIENTEE SERVICE

V. EXEMPLES D’ARCHITESTURE ORIENTEE SERVICE

10
 ARCHITECTURES ORIENTEES SERVICES

I. QU’EST-CE QUE L’ARCHITECTURE

ORIENTEE SERVICE ?

Une architecture orienté service est une architecture logicielle s’appuyant sur un
ensemble de services simples. Ils sont développés en s'inspirant des processus métier de
l'entreprise. Un service est un composant fonctionnant de manière autonome et offrant des
fonctionnalités métiers à d’autres applications ou d’autres services. Ces services
représentent les fonctions basiques des fonctionnalités des entreprises. Ils dialoguent entre
eux au travers de bus ou par Internet, on parle alors de WebService (WSOA). Les échanges
peuvent se faire de manière synchrone ou asynchrone. L’entreprise s’enrichit de services
mutualisables permettant de répondre rapidement et avec souplesse aux demandes du
marché. En effet, ils correspondent à un processus métier mutualisable au niveau de
l’entreprise. Cela permet les changements au niveau informatique des décisions stratégiques
et tactiques de l’entreprise.

Il n'existe pas spécifications officielles pour l’architecture d’une SOA. Il peut être décrit
par la notion, la description, la publication et l’invocation de services. La notion de service est
une fonction encapsulée dans un composant que l'on peut interroger à l'aide d'une requête
composée d'un ou plusieurs paramètres et fournissant une ou plusieurs
réponses. Idéalement chaque service doit être indépendant des autres afin de garantir sa
réutilisabilité et son interopérabilité. La description de service est la manière de décrire les
paramètres d'entrée du service, le format et le type des données retournées. Le principal
format de description de services est WSDL (Web Services Description Language), normalisé
par le W3C. Ensuite la publication consiste à publier dans un registre (en anglais registry ou
repository) les services disponibles aux utilisateurs, tandis que la notion de découverte
recouvre la possibilité de rechercher un service parmi ceux qui ont été publiés. Le principal
standard utilisé est UDDI (Universal Description Discovery and Integration), normalisé par
l'OASIS. Enfin l'invocation représente la connexion et l'interaction du client avec le service.
Le principal protocole utilisé pour l'invocation de services est SOAP (Simple Object Access
Protocol)

11
 ARCHITECTURES ORIENTEES SERVICES
II. FONCTIONNEMENT DE l’ARCHITECTURE
ORIENTEE SERVICE

1. Concepts
Une architecture orientée service se conforme à divers principes de gestion des services
influençant directement le comportement intrinsèque d’une solution logicielle et le style de sa
conception :

• L’encapsulation des services.

• Le faible couplage des services avec la maintenance d’une relation réduisant les
dépendances.
• Le contrat de service adhère à un accord de communication, collectivement défini avec
un ou plusieurs documents de description.
• L’abstraction des services dissimulant la logique du service à l’extérieur.
• La réutilisation des services partageant la logique entre plusieurs services avec
l’intention de promouvoir la réutilisation.
• La composition des services.
• L’autonomie des services.
• L’optimisation des services.
• La découverte des services depuis leur description extérieure.

L’architecture orientée service représente un moyen technique d’intégration des divers

systèmes d’information de l’entreprise considérant chaque ressource informatique comme un
service. Elle permet de construire les buildings blocks qui composeront l'urbanisme du système
d'information.

La notion d’interface est importante dans l’approche orientée service. En effet, elle représente
le point d’entrée unique vers les fonctionnalités de la solution logicielle et assure la
communication grâce à l’échange de messages. Chaque message est porteur de la sémantique
particulière à la solution logicielle. De plus ce message est rédigé dans un langage
compréhensible aux deux parties en présence. Les services proposés d’une architecture agile
décrivent la structure des messages qu’ils attendent du client.

L’architecture orientée service est une solution logicielle distribuée. Elle propose un mécanisme
d’échange de messages sécurisé entre les systèmes d’informations sous-jacents en employant
12
 ARCHITECTURES ORIENTEES SERVICES
des protocoles de communication standardisés. Cette approche offre à l’architecture une
opportunité d’ouverture sur un large éventail de solutions logicielles existantes.

Figure 1 : (concepts du SOA)

Comme dit précédemment, les SOA sont des concepts créés par le Gartner Group.
Sur la page suivante, un schéma montrant le fonctionnement des concepts de SOA.
Les services au centre de ce schéma sont les unités atomiques d’une architecture
orientée services. Ces services communiquent entre eux par le biais de messages. Ces
communications peuvent être synchrones ou asynchrones. Le langage de programmation du
service n’a aucune importante, ainsi que la plateforme d’exécution, matérielle et logicielle.
Ces services sont limités par un ensemble de contrats, c'est-à-dire qu’un service doit
respecter un ensemble de règle de fonctionnement. Enfin dans les WSOA (WebService Oriented
Architecture), les WebServices sont desservices disponibles via Internet par le biais d'URL.
Pour les WSOA, les données sont stockées sur le serveur. On peut se connecter aux WebServices
à l'aide de terminaux mobiles. L'utilisateur dispose donc à partir d'un client léger la puissance
de calcul du serveur. La connexion à distance est réalisée par protocole http, on a donc une
indépendance de tout langage de programmation et plateformes. La communication entre les
différents acteurs du système est réalisée par la technologie XML. Le schéma suivant montre
le fonctionnement d’un WSOA entre différents terminaux et les WebServices.

13
 ARCHITECTURES ORIENTEES SERVICES

2. Cycle de vie des services

Le service est un composant clef de l'architecture orientée services. Il consiste en une
fonction ou fonctionnalité bien définie. C'est aussi un composant autonome qui ne dépend
d’aucun contexte ou service externe. Il est divisé en opérations qui constituent autant d'actions
spécifiques que le service peut réaliser. On peut faire un parallèle entre opérations et services
d'une part, et méthodes et classes dans le mode orienté objet d'autre part.

Une architecture orientée services consiste essentiellement en une collection de services qui
interagissent et communiquent entre eux. Cette communication peut consister en un simple
retour de données ou en une activité (coordination de plusieurs services).

Un service est une entité de traitement qui respecte les caractéristiques suivantes :

14
 ARCHITECTURES ORIENTEES SERVICES
• Large granularité (coarse-grained) : les opérations proposées par un service encapsulent
plusieurs fonctions et opèrent sur un périmètre de données large au contraire de la notion
de composant technique.
• Interface : un service peut implémenter plusieurs interfaces, et aussi plusieurs services
peuvent implémenter une interface commune.
• Localisable : avant d’appeler (bind, invoke) un service, il faudra le trouver (find).
• Instance unique : à la différence des composants qui sont instanciés à la demande et
peuvent avoir plusieurs instances en même temps, un service est unique. Il correspond au
design pattern Singleton.
• Couplage faible (loosely-coupled) : les services sont connectés aux clients et aux autres
services via des standards. Ces standards assurent le découplage, c'est-à-dire la réduction
des dépendances. Ces standards sont des documents XML comme dans les web services.
• Synchrone ou asynchrone.

Une déclinaison du service est par exemple le service Web qui utilise WSDL (un métalangage
XML) comme langage de description, un annuaire UDDI pour en permettre la localisation et
un protocole de transport comme HTTP dans l'architecture REST et SOAP pour l'architecture
SOA.

Il existe une hiérarchie des services correspondant aux différentes couches techniques de
l'architecture d'une solution :

• Les services de présentations ou de référencement vers les informations affichées et les

formulaires de saisies de données.
• Les processus métiers composés de tâches décrites et faisant appel éventuellement à
d’autres services.
• Les services de gestion et d’accès aux bases de données.
• Les services d’intégration chargés de la messagerie ou de l'échange de données tant à
l’intérieur que vers l’extérieur comme la gestion des courriers électroniques.

Une des plus grandes fonctionnalités des SOA est la réutilisation des services pour
plusieurs entreprises. En effet, en étudiant l’évolution des différentes architectures, on peut
observer une réutilisation croissante. Ceci était impossible dans le modèle des composants.

15
 ARCHITECTURES ORIENTEES SERVICES

Figure 2: (cycle de vie de service du SOA)

En passant du procédural à l’orienté objet, on a la notion de réutilisation de classes

d’objet. Celle-ci n’a cessé d’augmenter avec la vision orienté composant puis enfin service.

3. Déploiement de l’architecture orientée services

Le déploiement des SOA peut-être effectué sur des serveurs d’intégrations, EAI
(Enterprise Application Integration). Ces serveurs organisent la circulation de l’information
entre les applications et les rendent interopérables en développant des connecteurs,
middleware, permettant d’interfacer ces applications utilisant des protocoles de
communications différentes généralement propriétaire. L’EAI permet donc la connexion aux
applications, les conversions des informations dans un langage commun et le transport des
informations d’une application vers une autre.

Le fonctionnement de l’EAI repose sur les composants suivants. Tour d’abord, un référentiel
des objets métier de l’entreprises ou de l’ensemble des processus. Ensuite, un moteur de gestion
de règles, des connecteurs applicatifs permettant l’interface avec les applications et les données
de l’entreprise, et enfin un système de transport des informations. Il y a plusieurs possibilités
pour le transport des informations. On peut utiliser un hub, un middleware (une couche
logicielle qui s’intercale entre les applications et un système, un MOM (middleware orienté
messages). Dans le dernier cas, les communications sont asynchrones.

L’EAI permet un accès universel et un partage de toutes les données et composants d'un système
d'information, qu'ils soient normalisés, propriétaires ou incompatibles. Il nécessite peu ou pas
de modifications des applications ou structures de données qu'il intègre. Une architecture EAI
n'est pas figée. Elle constitue un socle évolutif, réutilisable et dynamique suivant l'évolution des
besoins métier spécifiques comme les évolutions structurelles de l'entreprise. Cependant, les
16
 ARCHITECTURES ORIENTEES SERVICES
plateformes J2EE et .Net répondent aussi aux besoins des systèmes informatiques distribuées
et services Web

III. PROTOCOLES ET NORMES

Les architectures SOA se reposent principalement sur l’utilisation d’interface d’invocation
(SOAP, ancien acronyme de Simple Object Access Protocol) et de vocabulaire de description
de données (WSDL, Web Services Description Language et XML, Extensible Markup
Language) qui doivent être communs à l’ensemble des agents (fournisseurs de services et
utilisateurs de services).

Ce dispositif permet de réutiliser les applicatifs métiers, le but étant de permettre à l’entreprise
de s’adapter rapidement à un nouveau contexte de marché.

En termes d'intéropérabilité, les architectures SOA reposent en partie sur les normes décrites à
travers le WS-I.

Parmi les différentes couches de normes et protocoles qui permettent de bâtir de telles
architectures, on relève :

• la gestion d'un annuaire de services (quels sont les services mis à disposition et par qui)
avec : UDDI (Universal Description Discovery and Integration) normalisé par l'OASIS ;
• la description des interfaces des services (quelles sont les données nécessaires à
l'exécution du service, que fournit-il en retour...) avec : WSDL recommandé par le W3C ;
• l'invocation (ou l'appel) du service (la requête transmise au service)
avec : SOAP recommandé par le W3C ;
• le format des données échangées avec : XML recommandé par le W3C ;
• et enfin, le transport des données avec les protocoles internet : HTTP et TCP/IP qui sont
des recommandations RFC.

Une architecture SOA pourra être complétée par :

• la gestion de la sécurité avec : SSL (Secure Sockets Layer), XML Signature, XML
Encryption, SAML (Security Assertion Markup Language) ou encore XKMS (XML Key
Management Specification, qui gère les infrastructures à clé publique ou PKI) ;
• l'orchestration (on parle également de chorégraphie) des services pour constituer
des processus métier avec : BPEL4WS (Business Process Execution Language For Web
Services) devenu WS-BPEL et qui est un dérivé à la fois de WSFL (Web Services Flow

17
 ARCHITECTURES ORIENTEES SERVICES
Language) d'IBM et de XLang de Microsoft qu'il a remplacés, devenant de fait le standard
de l'orchestration des services web. On peut aussi citer WSCI (Web Services Choregraphy
Interface). L'orchestration suppose l'existence d'un chef d'orchestre (WS-BPEL est un
langage d'orchestration), tandis que la chorégraphie implique des interactions pair-à-
pair. WS-CDL (Web Services Choregraphy Description Language) est un exemple, le plus
récent, d'un tel langage ;
• la gestion transactionnelle (gestion du protocole de validation à deux phases, two-phase
commit, pour la mise à jour contrôlée de plusieurs bases de données réparties entre plusieurs
fournisseurs de services : la transaction « attend » de recevoir l'acquittement (le commit)
des différents serveurs sollicités et en cas de problème avec l'un d'eux, est en mesure de
demander aux autres serveurs de « défaire » les mises à jour partielles effectuées afin de
maintenir l'intégrité des données) : WS-Transaction d'IBM, XAML (Transaction Authority
Markup Language) ou encore BTP (Business Transaction Protocol).

IV. LES APPORTS DE L’ARCHITECTURE

ORIENTEE SERVICE
1. Avantages
Tout d’abord, les SOA disposent de tous les avantages d’une architecture client/serveur. C'est
à dire une plus grande modularité, on peut facilement remplacer un composant (service) par un
autre. Ils offrent également la réutilisation des composants, des meilleures possibilités
d’évolutions, une plus grande tolérance aux pannes ainsi qu'une maintenance plus facile. Il est
très facile dans les SOA d'ajouter des nouveaux services sans venir perturber les existants ainsi
que de les faire évaluer. Ces services sont réutilisables, il est donc possible de bâtir de nouvelles
applications faisant appel à des services tiers. Par exemple, un ERP d'entreprise peut être créée
en faisant appel aux services SAP. Les services sont utilisés selon les besoins des entreprises et
la mise à jour de ces services est réalisée de manière totalement transparente pour les
consommateurs.
Les SOA ont une architecture n-tiers, c'est-à-dire la séparation de la présentation des
données du traitement et de la base de données. Pour une architecture client/serveur, la
présentation des données ainsi que le traitement sont réalisés par le client et le serveur

18
 ARCHITECTURES ORIENTEES SERVICES
utilisé pour la base de données. Par contre, en n-tiers, chaque serveur peut avoir une
fonction unique. Par exemple, si on prend une architecture 3-tiers, on a les terminaux pour
les requêtes http qui gèrent la partie présentation de l’interface homme-machine. On a un
serveur d’application pour gérer les traitements et un dernier serveur de données qui gère
les accès aux données. Une architecture n-tiers présente la première infrastructure
informatique pour un travail coopératif. Les avantages sont une centralisation des
traitements au niveau des serveurs. En effet les services sont stockés sur des serveurs,
comme montré sur le schéma ci-dessus. Elle permet également une gestion plus simple de la
cohérence et de l’intégrité des données. Sur la page d’après, un schéma illustrant une
architecture 3-tiers.

Figure 3 : (illustration de l'architecture 3 tiers)

Les applications clientes et les services correspondent entre eux à l’aide de

middleware, des couches logicielles permettant la communication inter-application.

19
 ARCHITECTURES ORIENTEES SERVICES
2. Inconvénients
La mise en place d’un SOA a un coût élevé à la fois financier et humain. Il faut former
une équipe d'experts en conceptions ainsi que plusieurs équipes pour développer et
administrer les différents services. Dans le cas idéal, l’activité de l’entreprise doit être
pensée autour des services. La conception du système d’information est donc une étape
initiale critique. Si le fonctionnement de l’entreprise n’est pas organisé autour des services
alors il est difficile d’utilisé un SOA et donc le coût de fonctionnement sera élevé. En effet,
les SOA ont un intérêt limité si l’entreprise ne base pas ses processus sur l’exploitation des
services, il faut donc concevoir des workflows adaptés. De plus, il est difficile de migrer d’une
architecture monolithique vers une architecture SOA sans étude préalable efficace.

V. EXEMPLE D’ARCHITECTURE ORIENTEE

SERVICE
Pour montrer les performances des SOA, intéressons-nous plus particulièrement à un
exemple concret. REST est l'acronyme de "Representational State Transfer" inventé par Roy
T. Fielding et dont la définition a été donnée dans sa thèse de doctorat sur les architectures
Web en 2000. REST est un style architectural inspiré des SOA, mais basé sur le Web, il ne
définit pas une spécification, mais explique un principe de développement à suivre. Il
s’appuie sur l’utilisation des standards fondamentaux d’Internet. L’adressage des ressources
est réalisé par les URI, Uniform Ressource Identifier, une chaine de caractères permettant
d’identifier une ressource sur un réseau. Ceci permet donc d’identifier les différents services
disponibles sur le réseau ainsi que des images, vidéos... Ensuite la communication avec le
service est réalisée par protocole HTTP et la représentation des données est de type MIME
(Multipurpose Internet Mail Extensions). Par exemple, si les données sont de type html, on
aura « text/html ». Il existe différents type : text/css, text/html, video/mpeg, image/png …

L’utilisation du protocole HTTP définit également l’interface du service grâce aux

principaux verbes définit par celui-ci. Cette interface est standard et implémenté par tous les
serveurs Web. Les services proposent des méthodes qui répondent aux requêtes http. On a
« GET » qui permet de récupérer des données, « POST » qui envoie une commande, « PUT »
pour mettre à jour une donnée et « DELETE » pour la suppression. Cependant, REST ne gère

20
 ARCHITECTURES ORIENTEES SERVICES
pas l’état du client (session), les données client doivent être stockées ailleurs, par exemple
dans des bases de données, les cookies ...

REST propose donc une architecture légère donnant de bonnes performances et tirant parti
des fonctionnalités du protocole HTTP implémentées dans les serveurs (caching, etc.).
La conception de l’architecture d’une application en REST commence par l’identification des
ressources disponibles. Ensuite, chaque ressource est définit par une URI permettant son
accès de manière unique et sûre. Les scénarios de navigations sont définis grâce à des
hyperliens auxquels on accède en « GET ». Et les clients récupèrent les informations des
ressources consommées directement, il n’y a pas de sessions. Enfin, le filtrage du site est
facilité par le biais des URI.

Figure 4 : (exemples d'application REST)

Sur ce schéma, on peut observer un exemple de représentation d’une application en

REST. La ressource « La météo de Paris » est identifiée et accessible avec une URI. Les
données renvoyées par cette ressource sont représentées sous forme d’une page HTML.

21
 ARCHITECTURES ORIENTEES SERVICES

CONCLUSION
L’utilisation des SOA a donc pour but d’avoir une vision globale du système
d’information d’une entreprise. Il représente la capitalisation des ressources métier d’une
entreprise avec la réutilisation des services et le stockage des données sur une base de
données uniques. L’utilisation d’une telle architecture facilite l’évolution des applications
mais demande beaucoup d’efforts au niveau conception. Cependant, des architectures types
existent et se développent de plus en plus. Elles sont également validées par des experts.
Mais les entreprises possédant des applications centralisées développées de manière
monolithique n’ont pas de bénéfices à adopter ce type d’architecture. En effet, l’application
doit être pensée orientée services dès le début, afin d’orienter les workflows vers cette
notion de service.

De plus, la plupart des applications dans les entreprises sont abandonnées. L’apparition de ce
type d’architecture permet donc diminuer ce point de vue et chaque service peut être réutilisé
pour une autre application. Ainsi, cette architecture doit être mise en place au plus tôt au risque
de voir son coût et ses avantages diminués.

Pour conclure, voici quelques chiffres. En 2004, un budget de 950 millions de dollars
est consacré pour le marché mondial des Web Services. Selon Radicati Group, il devrait
atteindre 6,2 milliards de dollars en 2008. Enfin, d’après le groupe Gartner, 60% des
entreprises opéreront leurs applications métiers par le biais d’une architecture SOA d’ici
2008.

22
 ARCHITECTURES ORIENTEES SERVICES
TABLES DE MATIERES
SOMMAIRES ...................................................................................................................................1
GLOSSAIRES...................................................................................................................................2
SIGLES ET ABREVIATIONS.........................................................................................................3
LISTES DES FIGURES ...................................................................................................................4
INTRODUCTION ............................................................................................................................5
CHAPITRE 1 : CONTEXTE ET PROBLEMATIQUE ..................................................................6
I. CONTEXTE ..............................................................................................................................7
1. HISTORIQUE .......................................................................................................................7
2. PROBLEMATIQUE .............................................................................................................8
CHAPITRE 2 : ETAT DE L’ART ................................................................................................. 10
I. QU’EST-CE QUE L’ARCHITECTURE ORIENTEE SERVICE ? ............................................ 11
II. FONCTIONNEMENT DE l’ARCHITECTURE ORIENTEE SERVICE ................................... 12
1. Concepts ............................................................................................................................... 12
2. Cycle de vie des services ....................................................................................................... 14
3. Déploiement de l’architecture orientée services ..................................................................... 16
III. PROTOCOLES ET NORMES .............................................................................................. 17
IV. LES APPORTS DE L’ARCHITECTURE ORIENTEE SERVICE ......................................... 18
1. Avantages ............................................................................................................................. 18
2. Inconvénients ........................................................................................................................ 20
V. EXEMPLE D’ARCHITECTURE ORIENTEE SERVICE ......................................................... 20
CONCLUSION ................................................................................................................................ 22
TABLES DE MATIERES ................................................................................................................ 23

23