Partie II

Architecture Orientée Services

Introduction

La diversité des applications d’un même système d’informations, et la nécessité de

manipuler des quantités de plus en plus importantes de données, posent un grand
problème d’intégration d’applications. En effet, la communication entre les applications
et les différents systèmes d’informations devient de plus en plus difficile à cause des
technologies hétérogènes utilisées qui amènent les utilisateurs à travailler dans un
environnement incohérent, mal adapté et incompatible. Le manque d’interopérabilité
est alors relevé comme principal problème de ces systèmes.
L'architecture orientée services offre la possibilité de coupler des composants dans
plusieurs configurations dans la structure d'une plateforme et de les réutiliser pour
différentes constructions ce qui augmente considérablement la flexibilité du système
d’informations; se sont les principaux avantages du SOA. L'interopérabilité et la
cohérence sont obtenues lorsque vous obtenez un système qui répond aux besoins
d'évolution des systèmes d'informations.
L'architecture orientée services permet aux entreprises de réutiliser les applications et
les technologies actuelles tout en agrégeant l'interopérabilité, la flexibilité et l'agilité. La
flexibilité et l'agilité sont facilitées car les processus métier automatisés et leurs services
peuvent être modifiés sans recodage des applications ou déploiement d'une nouvelle
infrastructure pour prendre en charge ces changements technologiques rapides; ce qui
permet de réduire sensiblement les coûts de maintenance et d’adaptation au
changement. L'interopérabilité transformera un processus métier en une méthode
automatisée, adaptative et rapide. Dans SOA, les données et la logique métier sont
automatisées dans les composants métier modulaires avec des interfaces documentées.
Cette architecture est construite sous la forme de services réutilisables qu’il est possible
de découvrir et composer dynamiquement, avec un couplage faible. Pour répondre aux
enjeux de la SOA, les Services Web représentent l'implémentation la plus utilisée pour
mettre en place l’architecture orientée services. Les Services Web, qui sont basés sur des
technologies Web dérivées du standard XML, présentent un grand avantage pour la
communication des systèmes caractérisés par une hétérogénéité croissante.

28
II-1. Définition de l’Architecture SOA
Dans la littérature, le concept SOA a été proposé la première fois par Yefim V. Natis en
1994 analyste du Gartner Group.
Le paradigme SOA a vu le jour dans le but de résoudre les problématiques
d’interopérabilité entre les différentes technologies informatiques distribuées utilisées
en entreprise.

Définition 1
L’architecture orientée service est définie comme un paradigme permettant d’organiser
et d’utiliser des savoir-faire distribués pouvant être de domaines variés. Cela fournit un
moyen uniforme d’offrir, de découvrir, d’interagir et d’utiliser des savoir-faire pour
produire le résultat désiré avec des pré-conditions et des buts mesurables.

Définition 2
SOA est une architecture de logiciel qui débute avec une définition d'interface et la
construction entière d'application de topologie comme topologie des interfaces, des
réalisations d'interface, et des appels d'interface… ».

Définition 3
SOA est une architecture métier conceptuel où les fonctionnalités métiers, ou la logique
de l’application, est mise à disposition aux utilisateurs SOA ou aux utilisateurs, en tant
que services réutilisables et partagés dans un environnement informatique.

Définition 4
SOA est définie comme un style architectural qui permet de construire des solutions
d’entreprises basées sur les services. Ces derniers rassemblent les grandes applications
de l'entreprise (dites applications composites) en services interopérables et
réutilisables. La SOA a introduit une nouvelle philosophie pour le développement des
applications distribuées, où les services peuvent être publiés, découverts, composés,
réutilisés, et invoqués en utilisant l’interface, indépendamment de la technologie utilisée
pour implémenter chaque service. Pour cela, il a été affirmé que l'objectif d’une SOA est
de décomposer les fonctionnalités d’un système ou d’une application en un ensemble de
services. L’avantage le plus important de la SOA est qu’elle permet de séparer
l’implémentation du service de son interface. C’est cette caractéristique qui assure le
haut degré d’interopérabilité visé par cette architecture.
En conclusion, ces définitions se placent selon différents points de vue qui vont plus ou
moins dans le même sens. Nous pouvons affirmer d'une manière générale que
l'architecture orientée services est un style architectural pour la conception, le
développement, le déploiement et la gestion de systèmes logiciels distribués qui délivre
des fonctionnalités d'application sous forme de services interopérables, soit à
l'utilisateur final ou à d'autres services.

29
 FIGURE II.1 – Exemple de réutilisation et d’interopérabilité.

Remarques
• La SOA est avant tout une démarche de conception contribuant au besoin
d'urbanisation du SI, sans pour autant être l'apanage d'une technologie;
• Pour les équipes métier, la SOA permet d’être plus réactif et rapide dans l’innovation
de modèles et des processus pour créer des produits à moindre coût en se dotant d’un
avantage concurrentiel et en optimisant la collaboration interne et externe à
l’entreprise.
• Pour les équipes IT, la SOA a pour but de créer une réelle interopérabilité entre les
différents silos applicatifs du SI et de facilité l’ouverture du SI aux partenaires de
l’entreprise.

Analyse de la démarche de l'architecture orientée services

• L'architecture SOA est définie comme un style architectural qui permet de construire
des solutions d’entreprises basées sur les services.
• SOA a introduit une nouvelle philosophie pour le développement des applications
distribuées, où les services peuvent être publiés, découverts, composés, réutilisés, et
invoqués en utilisant l’interface, indépendamment de la technologie utilisée pour
implémenter chaque service.
• SOA permet de décomposer les fonctionnalités d’un système ou d’une application en
un ensemble de services.
• Rassembler les services pour créer les applications de l'entreprise (dites applications
composites).

30
II-2. Bénéfices attendus de la SOA
Le principal objectif est de maîtriser et optimiser les coûts d’intégration
Deux types de bénéfices :
• Des bénéfices intrinsèques à la mise en œuvre d’une SOA
• Des bénéfices indirects de la mise en œuvre d’une SOA à grande échelle. Il s’agit des
opportunités exploitables dans le cadre de la mise en œuvre de la SOA

Des bénéfices intrinsèques

• Favoriser la mutualisation des fonctions du SI
 Réutilisation des composants métier existants
 Création de services métier réutilisables
• Contribuer à maitriser les coûts d’intégration et de maintenance applicative
 Réutilisation des services → mutualisation des coûts de maintenance
 De plus, les facilités offertes par les plateformes d’intégration SOA (ESB) doivent
permettre de réduire les délais d’intégration
• Améliorer la réactivité et la qualité des développements
 Accélérer le processus de développement de nouvelles applications
 Fiabiliser les applications offertes aux différents métiers (la réutilisation
permettant de mieux éprouver les systèmes existants)
• Favoriser le recentrage de la conception des applications autour des processus
métiers

Des bénéfices indirects

• Favoriser une plus grande standardisation du SI;
 Permet une meilleure capacité d’ouverture du SI, capacité d’intégration
d’environnements hétérogènes
 Et par là favoriser la productivité des filières de développement
• Favoriser la mise en place de mesure de qualité de service rendu par le SI;
 La SOA s’accompagne de la définition de « contrats de service » que sont capables
de supporter les nouvelles infrastructures (ESB, Annuaire de service, etc.)
• Permettre au SI de s’ouvrir vers ses principaux partenaires (filiale & SI externes);
 En proposant une infrastructure et des services spécifiques exposes à l’extérieur
• Améliorer la disponibilité des informations;

31
  En amenant le SI depuis une architecture Batch avec de traitements nocturnes
lourds vers une architecture en mode de traitement au fil de l’eau / asynchrone
plus souple.

Les risques liés à la mise en œuvre d’une SOA

Des préoccupations liées aux modèles organisationnelle et méthodologique actuels des
DSI :
• La gestion d’un lourd changement au niveau des collaborateurs ou des processus (en
particulier de développement)
• Un manque de support/compréhension de la part des métiers
 Mutualiser de manière efficace exige de moduler un certain nombre de
fonctionnalités spécifiques. Les responsables des projets (Maîtres d'ouvrage)
doivent le comprendre et l’accepter.
 Une sensibilisation des métiers aux enjeux de la SOA est nécessaire
• L’adoption d’une démarche « services » a un impact certain sur la gestion des projets
 Les nouveaux projets applicatifs éligibles à une approche « services » doivent être
identifiés au plus tôt dans le cycle de vie des projets.
Des préoccupations liées aux modes de financement :
• Des investissements lourds sont nécessaires pour la mise en place de nouveaux
composants logiciels (annuaires de services, bus de services, etc.)
• Les modèles de financement actuels des DSI (en mode projet) peuvent être un frein
au déploiement de la SOA

Les craintes récurrentes

Des craintes liées aux impacts sur les architectures applicatives et techniques
• La mutualisation des ressources peut entraîner des difficultés pour identifier les
applicatifs impactés par la panne d’un composant.
• Le modèle d’architecture distribué de la SOA rend plus difficile le suivi d’un
traitement de bout en bout.
• Une dégradation possible des performances par l’ajout d’une couche logique de
services supplémentaire.
• Des risques de sécurité notamment dans le contrôle d’accès aux services.

II-3. Les services

Le service est le composant clef d’une architecture SOA. C’est une entité de traitement
qui représente une fonction ou fonctionnalité bien définie qui est divisée en opérations.
Un service peut implémenter plusieurs interfaces, et aussi plusieurs services peuvent

32
implémenter une même interface. Les services interagissent et communiquent entre
eux. Idéalement chaque service doit être indépendant des autres afin de garantir sa
réutilisabilité et son interopérabilité.
Après quoi nous donnons les principales caractéristiques d’un service citées par :
• Large Granularité : Les opérations d’un service peuvent encapsuler plusieurs fonctions
et donc opérer sur un périmètre de données large au contraire de la notion de
composant technique. En effet, il est possible de composer des services et de combiner
ainsi les différentes fonctionnalités offertes par les fournisseurs de services ce qui
permet d’offrir des services à forte valeur ajoutée aux clients.
• Couplage faible : Les services sont connectés aux clients et autres services via des
standards (Documents XML) qui assurent le découplage, c'est à dire, la réduction des
dépendances. En d’autres termes, les échanges entre les services ne dépendent pas de
l’implémentation sur laquelle les applications offertes par ces derniers reposent.

En résumé
• Le service est le composant clef d’une architecture SOA;
• C’est une entité de traitement qui représente une fonction ou fonctionnalité bien
définie qui est divisée en opérations;
• Les services interagissent et communiquent entre eux;
• Idéalement chaque service doit être indépendant des autres afin de garantir sa
réutilisabilité et son interopérabilité;
• A chaque service doit correspondre un contrat d’utilisation (contrat de service) qui
permet à ses utilisateurs de comprendre son usage fonctionnel et technique;
• De plus, les données échangées en entrée/sorties des services doivent être décrite par
un langage commun;
• Le service se doit d’avoir un propriétaire dûment identifié;
• La pertinence de création d’un service doit être évaluée au cas par cas.

33
Service vu du système d'information

FIGURE II.2 – Le service vu du SI.

Un Service :
• Effectue un ensemble de traitements qui répondent à un besoin donné
• Est exposé via une interface qui décrit un message en entrée et un autre en sortie
• Correspond à un niveau logique de traitement et pas à un niveau physique
d’implémentation
• Garanti la stabilité de l’action qu’il effectue (contrat de service)

Dans la SOA, la notion de service est associée à :

• Un découplage tant logique que physique entre le consommateur et le fournisseur;
• Une hiérarchisation des services;
• L’existence d’un engagement entre le fournisseur et le consommateur (le contrat de
service).

Une relation consommateur/fournisseur

Découplage entre le fournisseur et le consommateur :
• Pas d’adressage direct

34
• Découplage technologique

La gestion du cycle de vie des services

La gouvernance du cycle de vie des services est un élément clé d’une démarche
SOA

II-4. Les Services Web

Les Services Web fournissent les bases technologiques nécessaires à la réalisation de
l’interopérabilité entre les applications en utilisant différentes plateformes, différents
systèmes d’exploitation et différents langages de programmation.

II-4.1. Définition
Un Service Web est un composant logiciel identifié par une URI (Uniform Resource
Identifier), qui possède une interface publiable. Cette dernière peut être découverte par
d’autres systèmes, qu’ils peuvent interagir avec le Service Web selon les règles
prescrites par sa description, en utilisant des messages basés sur XML et portés par des
protocoles standards d’internet.
Les Services Web fournissent une couche d'abstraction entre le client et le fournisseur
d'un service. Cette couche est indépendante de la plateforme et du langage
d'implémentation, grâce à un ensemble de protocoles standardisés comme WSDL (Web
Service Description Language); document introduisant une grammaire communepour

35
décrire le Service Web, précisant les méthodes pouvant être invoquées, leur signature, et
les points d’accès du service (URL - Uniform Resource Locator, port, etc.), SOAP (Simple
Object Access Protocol) protocole de transmission de messages basé sur XML via
desquels ces méthodes sont accessibles, et UDDI (Universal Description, Discovery and
Integration) qui fournit l’infrastructure de base pour la publication et la découverte des
services.

II-4.2. Objectifs des Services Web

L’approche de Services Web vise essentiellement quatre objectifs fondamentaux
expliquant son grand succès :
• L’interopérabilité : Elle permet à des applications écrites dans des langages de
programmation différents et s'exécutant sur des plateformes différentes de
communiquer entre elles. En manipulant différents standards que ce soit XML ou les
protocoles d'Internet, les Services Web garantissent un haut niveau d'interopérabilité
des applications et ceci indépendamment des plateformes sur lesquelles elles sont
déployées et des langages de programmation dans lesquels elles sont écrites. Ainsi, en
s'appuyant sur un format d'échange de messages standard et sur l'ubiquité de
l'infrastructure d'Internet, l'interopérabilité est donc une caractéristique intrinsèque
aux services.
• Le couplage faible : Le couplage est une métrique indiquant le niveau d’interaction
entre deux ou plusieurs composants logiciels. Nous parlons de couplage fort si les
composants échangent beaucoup d'information et de couplage faible dans le cas
contraire. Vu que la communication avec les Services Web est réalisée via des messages
décrits par le standard XML caractérisé par sa généricité et son haut niveau
d'abstraction, les Services Web permettent la coopération d'applications tout en
garantissant un faible taux de couplage. Par conséquent, il est possible de modifier un
service sans briser sa compatibilité avec les autres services composant l'application
Web.
• La réutilisation : L'avantage de la réutilisation est qu'elle permet de réduire les coûts
de développement en réutilisant des composants déjà existants. Dans le cas de
l'approche Services Web, l'objectif de la séparation des opérations en services
autonomes est en effet pour promouvoir leur réutilisation. Ainsi, lorsqu'un client définit
ses exigences, il est généralement possible de réutiliser des services déjà existants pour
satisfaire une partie des exigences. Ceci facilite la maintenance de l'application et permet
un gain de temps considérable.
• La découverte et la composition automatique : La découverte et la composition sont
des étapes importantes qui permettent la réutilisation des services. En effet, il faudra
être en mesure de trouver et de composer un service afin de pouvoir en faire usage. En
exploitant les technologies offertes par Internet et en utilisant un ensemble de standards
pour la publication, la recherche et la composition, l'approche Services Web tend à
diminuer autant que possible l'intervention humaine en vue de permettre une

36
découverte et une composition automatiques des services les plus complexes. En effet,
pour réaliser son application, un développeur peut simplement interroger un moteur de
recherche de services afin de trouver le service adéquat et à l'aide de langages de
coordination appropriés il peut l'intégrer avec le reste des services de son application.

II-4.3. Architecture de référence

Les efforts de recherche et de développement récents autour des Services Web ont
conduit à un certain nombre de spécifications qui définissent aujourd’hui l’architecture
de référence des Services Web. Cette architecture vise trois objectifs importants : (i)
identification des composants fonctionnels, (ii) définition des relations entre ces
composants et (iii) établissement d’un ensemble de contraintes sur chaque composant
de manière à garantir les propriétés globales de l’architecture.
L’architecture de référence des Services Web s’articule autour des trois rôles suivants :
• Le fournisseur de service : correspond au propriétaire du service. D’un point de vue
technique, il est constitué par la plateforme d’accueil du service.
• Le client : correspond au demandeur de service. D’un point de vue technique, il est
constitué par l’application qui va rechercher et invoquer un service. L’application cliente
peut être elle-même un Service Web.
• L’annuaire des services : correspond à un registre de descriptions de services offrant
des facilités de publication de services à l’intention des fournisseurs ainsi que des
facilités de recherche de services à l’intention des clients.

Annuaire
de services
1-Publier
(UDDI)
(WSDL)
2-Rechercher
WSDL Fournisseur
3-Lier
Client - Implémentation
- Recherche - Déploiement
- Lier/connecter 4-Invoquer - Description et
- Invocation publication
SOAP
FIGURE II-3 – Architecture des Services Web.

Les interactions de base entre ces trois rôles incluent les opérations de publication, de
recherche et de liens d’opérations. Nous décrivons un scénario type d’utilisation de cette
architecture : Le fournisseur de services définit la description de son service dans un
document WSDL et la publie dans un annuaire de service UDDI. Le client utilise les
facilités de recherche disponibles au niveau de l’annuaire UDDI pour retrouver et
sélectionner un service donné via un message SOAP. Il récupère le document WSDL du
service choisi. Ensuite, il examine ensuite la description du service sélectionné pour
récupérer les informations nécessaires, via un message SOAP également, lui permettant

37
de se connecter au fournisseur du service et d’interagir avec l’implémentation du service
considéré. Enfin, il invoque l'opération désirée par le biais d'une requête SOAP
renfermant les paramètres d'entrée de l'opération. Le service, du coté du fournisseur,
reçoit la requête, la traite, formule la réponse SOAP et l'envoie au client.

II-4.4. Langages et protocoles utilisés par les Services Web

L’architecture de référence des Services Web présentée dans la section précédente
montre l’utilisation de nombreux langages et protocoles durant la publication;
recherche, lien et l’invocation des Services Web afin de garantir l’interopérabilité des ces
opérations. L'atout principal des protocoles SOAP et UDDI ainsi que du langage WSDL
est de se reposer sur le langage XML. Cette architecture montre aussi que les Services
Web se basent sur l’utilisation des normes actuelles d'Internet comme le protocole
HTTP.
L'architecture des Services Web peut être définie sous forme couches décrivant la pile
de langages et de protocoles utilisés.

Découverte / Publication
(UDDI)
Description
(WSDL)
Communication
(SOAP)
Transport
(HTTP, SMTP…)

FIGURE II.4 – Pile protocolaire des Services Web.

Nous citons les propositions de standards ont été élaborées pour chaque type
d’interactions, notamment les standards suivants :

II-4.4.1. XML
XML c’est la technologie de base des architectures Services Web, XML est un standard;
promulgué par le World Wide Web Consortium (W3C); qui permet de décrire des
documents structurés transportables sur les protocoles d’Internet.
XML apporte à l’architecture des Services Web l’extensibilité et la neutralité.
L’interopérabilité entre les systèmes hétérogènes demande des mécanismes puissants
de correspondance et de gestion des types de données des messages entre les différents
participants (clients et fournisseurs). C’est une tâche où les schémas de type de données
XML s’avèrent bien adaptés. Donc les Services Web sont totalement basés sur XML.

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

II-4.4.3. SOAP – La communication

SOAP définit un protocole de transmission de messages basé sur XML lors de
l’invocation d’un service, et ce, en se basant sur des protocoles de transport réseau
TCP/IP (HTTP, SMTP ou encore FTP). Des messages de type document XML peuvent
ainsi être transmis de façon unidirectionnelle ou avec des dialogues requête-réponse. Le
protocole SOAP définit un ensemble de règles pour définir le contenu (les données
véhiculées) et la structure du message (l’enveloppe). L’enveloppe qui est l’élément
racine du document XML à transmettre est composée de deux parties : un en-tête «
SOAP header » et un corps « SOAP body ». L’en-tête SOAP est optionnel et est
typiquement utilisé pour transmettre des données d’authentification ou de gestion de
session. Le corps SOAP fournit un mécanisme de transmission d’information structurée.

Protocole de Transport
(Exemple: HTTP)

Enveloppe SOAP

SOAP Header

SOAP Body

FIGURE II.5 – Structure d'un message SOAP.

II-4.4.4. WSDL – La description

Officiellement recommandé par le W3C, le langage WSDL permet de décrire l’interface
d’un Service Web de façon universelle à l’aide d’une grammaire XML. Il définit les
paramètres nécessaires pour invoquer un service, le format et le type des données
retournées. Concrètement, un fichier WSDL est un document qui utilise XML dans lequel
on trouve le nom du service, son emplacement et comment y accéder (l’adresse du
Service Web sous la forme d’une URI et les protocoles permettant son invocation) ainsi
que la liste de ses opérations avec tous les paramètres d’entrée et de réponse.

39
WSDL permet de décrire un Service Web et la manière d’y accéder, en incluant des
détails tels que le protocole à utiliser, l’URI, les opérations pouvant être effectuées, les
formats des messages SOAP entrants ou sortants qui sont requis pour dialoguer avec le
service ainsi que les exceptions pouvant être renvoyées.

<definitions> : Racine du WSDL

<types> !--abstract data types

<message> !--message structure

<portType> !--Web Service Interface

<binding> !--how the service is accessed

<service> !--who provides the service

FIGURE II.6 – Structure d’un document WSDL.

Une description WSDL d’un Service Web est un document XML dont l’élément racine
<definitions> contient cinq éléments :
• <types> : contient les définitions des types de données utilisées dans les messages
envoyés et reçus par le Service Web et ceci en utilisant le modèle XML Schema.
• <message> : décrit le nom et le type d’un champ à transmettre et qui correspond à un
paramètre d’entrée ou de sortie d’une opération du service.
• <portType> : définit de manière abstraite le Service Web comme un ensemble
d’opérations où chaque opération est composée d’un message d’entrée, d’un message de
sortie et d’un éventuel message d’erreur. Suivant les messages qui composent une
opération, WSDL permet de définir quatre types d’opérations : Request-Response
(reçoit un message et retourne un message), Solicit-Response (émet un message et
reçoit un message), One-Way (reçoit un message) et Notification (émet un message).
• <binding> : permet de faire une liaison précise entre les descriptions, effectuées dans
les éléments <message> et <portType>, et le type de protocole utilisé pour véhiculer les
données.
• <service> : permet de préciser les informations complémentaires nécessaires pour
invoquer le service, en particulier l’URI qui permet d’y accéder.
Ainsi la description WSDL permet de spécifier le protocole à utiliser ainsi que les
opérations à invoquer. Ceci n’est pas suffisant pour découvrir un Service Web qui
possède une fonctionnalité dont une application a besoin. Pour savoir où trouver les
Services Web, les documents WSDL peuvent être référencés dans des annuaires
permettant la recherche et la découverte des services disponibles.

40
II-4.4.5. UDDI – La découverte/publication
UDDI décrit un registre dans lequel les Services Web peuvent être publié. Il fournit
l’infrastructure de base pour la publication et la découverte des services. UDDI est
sponsorisée par OASIS et il est le résultat d’un accord interindustriel entre Microsoft,
Ariba, IBM, Sun Microsystems, Oracle, HP, SAP, etc. Il offre un mécanisme de registre
distribué de services permettant leur publication par les fournisseurs et leur découverte
par les clients. Les données stockés dans l’UDDI sont structurées en XML et organisées
en trois parties nommées, pages blanches, jaunes et vertes. Les pages blanches : noms,
adresses, contacts, identifiants, etc… des fournisseurs de services. Les pages jaunes :
détails sur le métier du fournisseur et les services qu’il propose de façon à classer les
entreprises et les services par secteurs d’activités. Les pages vertes incluent des
références vers les spécifications des Services Web et les informations nécessaires à
l’utilisation de ces services. Ces informations incluent la description du service, du
processus de son utilisation et des protocoles utilisés pour son invocation.

II-4.5. Composition des Services Web

Le principal avantage sinon le plus important de l’approche par composants est la
réutilisation des composants. Par définition, les Services Web, répondent aux principes
de cette approche. Ils sont des composants conceptuellement limités à des
fonctionnalités relativement simples qui sont modélisées par une collection
d’opérations. De ce fait, les Services Web doivent pouvoir être composés en services que
l’on compose jusqu’à ce que le service résultant fournisse un support entier pour les
processus métiers.

II-4.5.1. Définitions
La composition peut est définie comme étant une technique permettant d’assembler des
Services Web afin d’atteindre un objectif particulier, par l’intermédiaire de primitives de
contrôle (boucle, test, traitement d’exception, etc.) et d’échange (envoi et réception de
messages). Les services composants existent au préalable et peuvent ne pas être fournis
par la même organisation.
La composition est aussi définie comme l’infrastructure de base des Services Web suffit
pour la mise en œuvre d’interactions simples entre un client et un Service Web. Si la
mise en œuvre d’une application métier implique l’invocation d’autres Services Web, il
est nécessaire donc de combiner les fonctionnalités de plusieurs Services Web. Dans ce
cas, nous parlons d’une composition de Services Web.
L’objectif de la composition de services est de créer de nouvelles fonctionnalités en
combinant des fonctionnalités offertes par d’autres services déjà existants, en vue
d’apporter une nouvelle valeur ajoutée. La composition de service, étant donnée une
spécification de haut niveau, implique la capacité de sélectionner, de composer et de
faire inter-opérer des services existants. De plus, la forte compétition engendrée par la
multitude de fournisseurs de services oblige les entreprises à adapter leurs services

41
pour mieux répondre aux besoins des clients et ce à moindre coût. L’utilisation d’un
protocole de coordination permet de gérer de façon appropriée l’ordre et le type des
messages échangés.

II-4.5.2. Orchestration et Chorégraphie

La composition des Services Web peut être faite en utilisant l’une des deux méthodes :
orchestration ou chorégraphie. Ces dernières représentent deux points de vue
complémentaires decrivent le concept de la composition de Services Web :
(i) la chorégraphie; qui représente le point de vue global dans lequel l’ensemble des
partenaires participant à la composition est,
(ii) l' orchestration qui est le point de vue local ou privé dans lequel seul le processus
interne d’un participant est modélisé.
Nous rappelons qu’une composition de services peut aussi être décrite en termes d’un
processus abstrait ou exécutable.

II-4.5.2.1 Orchestration
Dans la technique de l’orchestration de services, un processus central (qui peut être lui-
même un Service Web) prend le contrôle de tous les Services Web impliqués dans la
composition et coordonne l’exécution des différentes opérations sur ces Services Web.
Ces derniers ne savent pas (et n’ont pas à savoir) qu’ils sont invoqués dans une
composition et qu’ils font partie d’un processus métier complexe. Seul le coordinateur
central de l’orchestration le sait. L’orchestration est donc centralisée avec des
définitions explicites des opérations et l’ordre d’invocation des Services Web.
Une orchestration définit l’enchaînement des services (la logique et les séquences
d’invocation) selon un schéma prédéfini, et permet de les exécuter à travers des
processus métier ou des workflows inter/intra-entreprises. En d’autres termes,
l’orchestration de services permet la description d’un ensemble d’actions internes (dans
lesquelles un service donné peut ou doit s’engager afin de remplir ses fonctions) et
d’actions communicatives (d’envoi et de réception de messages) ainsi que les
dépendances entre ces actions.
Service
Web 1

Service Web
Moteur

Service
Web 2

FIGURE II.7 – Illustration d’une orchestration.

42
II-4.5.2.2 Chorégraphie
D’autre part, on peut ne pas compter sur un coordinateur central. Au lieu de cela, chaque
Service Web impliqué dans la chorégraphie sait exactement quand exécuter ses
opérations et avec qui interagir. La chorégraphie est un effort de collaboration focalisé
sur l’échange de messages dans des processus métiers publics. Tous les participants à la
chorégraphie doivent connaître leurs rôles dans le processus métier, les opérations à
exécuter, les messages à échanger, et le temps d’échange de ces messages.
La chorégraphie décrit donc, d’une part, un ensemble d’interactions qui peuvent ou
doivent avoir lieu entre un ensemble de services/participants qui sont généralement
représentés de façon abstraite par des rôles, et d’autre part, les dépendances entre ces
interactions. La chorégraphie définit la séquence de messages pouvant impliquer
plusieurs parties et plusieurs sources, incluant les clients, les fournisseurs, et les
partenaires.
Du point de vue de la composition des Services Web, pour exécuter des processus
métiers, l’orchestration est avantageuse par rapport à la chorégraphie.
• On connaît de façon exacte qui est le responsable de l’exécution du processus métier en
entier;
• On peut incorporer les Services Web, même ceux qui ne savent pas qui sont impliqués
dans des processus métiers;
• On peut aussi fournir un scénario alternatif en cas d’erreurs.

Service Service
Web 1 Web 2

Service
Web3

FIGURE II.8 – Illustration d’une chorégraphie.

II-4.5.3. Langages de composition des Services Web

La composition de Services Web est notamment un processus complexe qui doit
répondre à la question de savoir comment trouver les services appropriés, les
sélectionner et les combiner, fournir des informations d’ordre comportemental
renseignant sur leur orchestration et chorégraphie en vue de les rendre exécutables. Ces
deux derniers concepts d’orchestration et de chorégraphie, servent à décrire le
comportement interne et externe d’un Service Web composite. D’où, la composition de
services s'intéresse au support des processus métiers en leur fournissant des standards
et des outils permettant de générer les flux de composition.

43
Le concept de composition des Services Web est réduit aux concepts d’orchestration et
de chorégraphie. Dans ce contexte, l’aspect comportemental des Services Web
composites est décrit, permettant ainsi la description décrire des flux de composition
qui traduisent les comportements ou encore la manière dont les composants doivent
être agrégée. Ainsi, des langages de composition spécifiques tels que WS-BPEL (Web
Services Business Process Execution Language), WS-CDL (Web Services Choreography
Description Language) et OWL-S (Ontology Web Language for Service) ont été
développés.

II-4.5.3.1. WS-BPEL
Rappelons que l’orchestration permet de décrire l’enchaînement des services selon un
canevas prédéfini, et de les exécuter comme étant un ensemble d’actions à réaliser par
l’intermédiaire de Services Web. Un moteur d’exécution (lui-même un Service Web),
jouant le rôle de chef d’orchestre, est chargé d’appeler et de gérer l’enchaînement d’un
ensemble de Services Web selon un processus prédéfini. Ce moteur définit le processus
dans son ensemble et appelle les Services Web (tant internes qu’externes à
l’organisation) selon l’ordre des tâches d’exécution.
OASIS a conçu et standardisé le langage WS-BPEL pour la modélisation de
l’orchestration des services. Selon, WS-BPEL, fondé sur XML, offre la possibilité de
décrire le comportement externe des Services Web à un niveau syntaxique. Il spécifie
une grammaire XML et un vocabulaire riche pour décrire la logique de contrôle requise
pour orchestrer les Services Web participant à un processus. Et selon le même auteur, ce
langage peut être utilisé pour décrire deux types de processus d’orchestration : abstrait
et exécutable. Le processus abstrait permet de spécifier les messages échangés entre les
différents partenaires sans expliciter leurs comportements internes. Le processus
exécutable, lui, précise les différentes opérations de services partenaires, leur ordre
d’exécution et l’ensemble des exceptions et des compensations à prévoir.

II-4.5.3.2. WS-CDL
La chorégraphie décrit le comportement interne du Service Web, en exposant les
différentes interactions (collaborations) que le client d’un Service Web doit respecter
afin de consommer les fonctionnalités de ce dernier.
WS-CDL est un langage issu des efforts de standardisation du groupe de travail du W3C
portant sur la chorégraphie de Services. L’objectif de ce langage est de décrire les
relations entre les Services Web lors d’une composition de type chorégraphie. C’est un
langage basé sur XML permettant à l’utilisateur de décrire des collaborations pair à pair
(P2P) entre services en définissant leur comportement commun et observable.
Un document de chorégraphie, en complétant de la description WSDL, décrit les
interactions entre participants (les autres Services Web) impliqués en décrivant leurs
comportements observables. L’accomplissement de leur but commun se fait alors par
des échanges ordonnés de messages suivant le plan déterminé dans ce document. En

44
effet, le WS-CDL apporte un modèle global qui assure la cohérence des interactions entre
des services qui coopèrent. Notamment, la chorégraphie, qu’il décrit, garantit un
comportement contractuel entre multiples services sans avoir recours à un outil
complexe d’interconnexion. Néanmoins, l’utilisation de ce langage par les industriels
reste très limitée, vu qu’il garde encore le statut recommandation et non pas standard de
W3C.

II-4.5.3.3. OWL-S
OWL-S est un langage de mise en œuvre de Services Web sémantiques qui permet la
composition de type chorégraphie des Services Web.
Les Services Web sémantiques sont définis comme étant des Services Web munis d’une
sémantique ayant pour but de les rendre interopérables et compréhensibles par des
moteurs ou des agents logiciels capables de raisonner.
OWL-S a pour objectif de décrire sémantiquement les propriétés d’un Service Web de
façon claire et interprétable par la machine. Outre la description des propriétés de base,
il fournit une spécification des pré-requis et des conséquences d’exécution du service
ainsi qu’un mécanisme de description des services composites et des flux de données. Ce
langage est fondé sur l’utilisation du langage d’ontologie du Web (OWL) connu comme
langage de référence dans le domaine des langages sémantiques utilisant la logique de
description. Et selon le même auteur, OWL-S est considéré comme une ontologie OWL
particulière qui fournit des dispositifs spécifiques pour la description, la publication, la
découverte, la composition et l’invocation des Services Web. Ces dispositifs visent à
automatiser le plus possible, la gestion des Services Web. Dans ce contexte, OWL-S
structure notamment la description d’un Service Web en trois sous-ontologies : le profil
du service (ServiceProfile), son modèle processus (ServiceModel) et ses liaisons
(ServiceGrounding).

Conclusion
Depuis quelques années, la notion d’Architecture Orientée Services (SOA) s’est
rapidement répandue et a été largement acceptée par l’industrie du logiciel.
Actuellement, le concept de SOA recouvre des aspects et des domaines très variés qui
dépassent d’une certaine manière largement le domaine initial qu’est l’architecture
logicielle. Ainsi, l’approche SOA propose, d'une part, une architecture guidée par les
besoins métiers (les services) de l’application et, d'autre part, une architecture qui
s’adapte aux besoins de l’application. En outre, la technologie des Services Web offre de
fortes potentialités pour surmonter les problèmes d’interopérabilité des systèmes. Elle
constitue un cadre prometteur pour l’intégration des applications, et pour la gestion des
interactions entre divers partenaires dans un environnement distribué, hétérogène,
ouvert et versatile qui est le Web.

45
Par ailleurs, la composition des services permet de former un nouveau service dit
composé ou composite, d'où l’exécution d’un service composé implique des interactions
avec des services partenaires en faisant appel à leurs fonctionnalités. La composition des
Services Web constitue, aussi, une évolution naturelle de cette technologie qui permet
de mettre en place des composants Services Web au profit de l’intégration d’applications
sur le Web afin d'atteindre de meilleures solutions. En conclusion, la composition de
Services Web spécifie quels services ont besoin d'être invoqués, dans quel ordre et
comment gérer les conditions d'exception.
Dans cette seconde partie du cours, nous avons présenté les notions et concepts
fondamentaux de l'architecture orientée services, les caractéristiques des services et les
principes des Services Web. De plus, nous avons abordé le sujet de la composition de
Services Web et un ensemble de différents langages de composition des Services Web.

46