Cours SOA Dehimi

République Algérienne Démocratique et Populaire
Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

Université Larbi Ben M’hidi – Oum El Bouaghi
Faculté des Sciences Exactes et des Sciences de la Nature et de la Vie
Département de Mathématiques et de l'Informatique
Polycopié de Cours
Architectures Orientées Services

(SOA)
Niveau : 2ème année master en Informatique

Spécialité : Architecture Distribuée
Proposé par
Dr. DEHIMI Nour El Houda
Edition 1.0
2019-2020
Préambule
Le présent document consiste en un support de cours concernant la matière intitulée

Architectures Orientées Services (SOA), enseignée au Département de Mathématiques et
d'Informatique à l'université Larbi Ben M’hidi d’Oum El Bouaghi. Il est destiné aux étudiants
de 2ème année master en informatique.
L’objectif de ce cours vise à permettre aux étudiants de comprendre :
- Les architectures orientées services
- Les web service
- La modélisation et l’exécution des processus d’affaires
- Les accords de niveau de service
- L'architecture orientée événements
- La conception des architectures orientées services
Pour la réalisation de ce document, et afin d’atteindre l'objectif tracé, nous avons déployé tous
les efforts nécessaires pour consulter plusieurs sources traitant du sujet (ouvrages, notes de
cours, publications et les sites internet). Nous avons par la suite effectué des comparaisons et
des recoupements entre les différentes informations rencontrées. Enfin, dans un souci
d’accessibilité aux utilisateurs, toutes les informations pertinentes ont été sélectionnées,
synthétisées et regroupées dans une forme pédagogique tout en respectant le canevas officiel
défini par le ministère de l’enseignement supérieur et de la recherche scientifique.
Néanmoins, compte tenu des avancées fulgurantes de l’informatique, nous avons conscience
que ce document restera partiel et non exhaustif et qu’il fera appel à notre vigilance pour son
enrichissement par le biais d’une actualisation permanente.
Nous souhaitons aux utilisateurs qui consultent ce document d’y trouver, les enseignements
qu’ils recherchent, et nous les invitons à nous proposer toute suggestion qu’ils jugent utile et de
nous signaler toute éventuelle erreur ou coquille qui aurait échappée à notre vigilance.
De plus, nous avons le plaisir, d’informer nos utilisateurs que, nous profitons des dernières
technologies mises en œuvre dans les enseignements pour soumettre le cours dans un format
interactif. Pour cela, nous utilisons la plateforme MOODLE (Modular Object Oriented
Dynamic Learning Environment). Cette dernière permet aux étudiants d'avoir des comptes
qu'ils utilisent pour accéder aux cours en ligne. Ils y trouveront pour chaque partie du cours
enseignée en classe :
- Un enrichissement par des vidéos, des livres, des références bibliographiques etc. jugées
complémentaires par l’enseignant dans le but de leur offrir une meilleure
compréhension du cours et d’améliorer leurs connaissances
- Des forums et des espaces de chat, d’échanges mutuels et de collaboration, entre eux
et/ou avec l'enseignant, qui leur permettent de rattraper et d’enrichir les parties du cours
qui auraient été mal assimilées en classe
- Des tests auxquels ils répondront en ligne avec correction automatique et instantanée et
ce, pendant une période fixée par l'enseignant
- Des travaux ou des exposés à faire par groupe en utilisant les forums et les chats
spécifiés par l’enseignant pour chaque groupe. Ces travaux, une fois réalisés, seront
déposés dans un espace spécifique de la plateforme avec notification automatique à
l’enseignant
Grâce à cette méthode, nous pensons que les étudiants se retrouveront au centre de leur
apprentissage entrain de progresser ensemble de manière collaborative.
Oum El Bouaghi, Janvier 2020
Dr. DEHIMI Nour El Houda

Table des matières
Chapitre 1 : Introduction aux architectures orientées services

1. Introduction 1
2. Notion de service 2
2.1.Définition 2
2.2.Les composants d’un service 3
3. L’architecture orienté services 3
3.1.Définition 3
3.2.Les composants de la SOA 4
3.3.Le fonctionnement de la SOA 5
3.4.Les principes de conception dans SOA 6
3.5.Cycle de vie des services dans la SOA 8
3.6. Avantages et inconvénients de SOA 9
3.6.1. Avantages 9
3.6.2. Inconvénients 10
Chapitre 2 : Modélisation des processus d’affaires

1. Introduction 11
2. Processus d’affaires 12
2.1.Définition 12
2.2.Catégorisation des processus 12
3. Modélisation des processus d’affaires 13
4. Langages de modélisation des processus d’affaires 14
4.1.Langages traditionnels 14
4.2.Langages dynamiques 16
4.3.Langages d'intégration de processus 17
4.4.Langages de modélisation orientée objet 18
4.5.Les ontologies d'affaires 18
4.6. Comparaison des langages de modélisation des processus d'affaires 20
Chapitre 3 : Les Web services
1. Introduction 22
2. Définition d’un service Web 22
3. Architecture des services Web 22
3.1.Architecture de référence 23
3.2.Architecture étendue ou en pile 25
4. Les technologies des services web 25
4.1.Le langage XML 26
4.2.SOAP (le protocole de communication des Services Web) 26
4.3.WSDL : le service de description 30
4.4.UDDI : le service d’enregistrement 33
5. Autres standards pour les services Web 37
6. Développement des services Web 38
7. Les web services RESTful 41
Chapitre 4 : Exécution de processus d’affaires

1. Introduction 44
2. Orchestration et Chorégraphie 44
2.1.Orchestration 44
2.2.Chorégraphie 45
3. Moteur de Workflow 46
4. BPEL (business process execution language) 47
Chapitre 5 : Formalismes pour les accords de niveau de service

1. Introduction 51
2. Définition d’accords de niveau 52
3. Cycle de vie d’un accord de niveau 53
3.1.Définition d'un accord de niveau de service 53
3.2.La négociation 54
3.3.Renégociation 55
3.4.Fin de l’accord 55
4. La supervision du niveau de service SLM 55
5. Langages de description d'accords de niveau 56
5.1.WSLA 56
5.2.Rule-based service level agreements (RBSLA) 58
5.3.WS-agreement 59
6. Comparaison entre WSLA, RBSLA et WS-Agreement 61
Chapitre 6 : Event driven architecture (EDA)

1. Introduction 62
2. Définition de l’EDA 63
3. Les composants de l’architecture EDA 64
3.1.Évènement 64
3.2.Les agents 65
3.3.Le diffuseur de messages 65
3.4.Processeur d'évènements 66
4. Avantages de l’EDA 67
5. Exemple 69
Chapitre 7 : Conception des SOA

1. Méthode SOMA 72
2. Méthode de Papazoglou et Heuvel 74
3. Méthode de Erl 76
Série des exercices 79

Références 84
Table des figures

Figure 1 : la couche de services de SOA. 1
Figure 2 : Classification des services SOA. 2
Figure 3 : Composants de service. 3
Figure 4 : Les composants de la SOA. 4
Figure 5 : Le fonctionnement de la SOA 4

Figure 1 : Les différentes normes en relation avec le cycle de vie d'un processus 12
d'affaires dans le cadre de BPM.
Figure 2 : Catégorisation des processus. 13

Figure 1 : Architecture de référence des services Web. 23
Figure 2 : Etapes d’exécution des Services Web dans une architecture de référence. 24
Figure 3 : Architecture étendue ou en pile des services Web. 25
Figure 4 : La structure des messages SOAP. 27
Figure 5 : Structure d’un message http. 29
Figure 6 : Description WSDL d’un service. 31
Figure 7 : Structure de données de l’annuaire UDDI. 34
Figure 8 : Les quatre principaux éléments d’un annuaire UDDI. 35
Figure 9 : Enregistrement du document WSDL dans un annuaire UDDI. 37
Figure 10 : REST vis-à-vis SOAP 42

Figure 1 : La composition des Web services en utilisant l’Orchestration. 45
Figure 2 : La composition des Web services en utilisant la chorégraphie. 34
Figure 3 : Différents interfaces adoptés dans les WfMC. 37
Figure 1 : Les quatre niveaux de contrat 52
Figure 2 : Cycle de vie d’un accord de niveau de service 53
Figure 3 : Les principaux concepts de WSLA. 57
Figure 4 : Patron d'interactions du canevas WSLA. 58
Figure 5 : Architecture en couches de l'approche Rule Based SLA. 59
Figure6 : Contenu d’un accord WS-Agreement. 60

Figure 1 : EDA en réseau décentralisé. 63
Figure 2 : EDA en flux d’évènements. 63
Figure 3 : Les composants de l’architecture EDA. 64
Figure 4 : Graphique présentant l'évolution des moteurs CEP. 67
Figure 5 : Avantage de l'EDA : du choix technique à l'avantage métier. 68
Figure 6 : Exemple d’architecture SOA – usine de voitures. 69
Figure 7 : Exemple d’architecture SOA – usine de voitures après l’ajout de l’ordinateur 70
de patron.
Figure 8 : Exemple d’architecture EDA – usine de voitures. 71
Figure 9 : Exemple d’architecture EDA – usine de voitures après l’ajout de l’ordinateur 71
de patron.

Figure 1 : les phases de la méthode SOMA 73
Figure 2 : La phase de réalisation de la méthode SOMA. 74
Figure 3 : les six phases de la méthode de Papazoglou et Heuvel. 75
Figure 4 : Les phases de la méthode Erl. 78
1. Introduction
Les architectures à base de services (SOA) consistent à concevoir des applications distribuées
à l'aide de composants réutilisables et interopérables dont les interactions s'effectuent sur la
base d'échanges de messages. Ces architectures offrent un avantage évident qui est
l'interopérabilité. Cet avantage implique que les applications peuvent s'invoquer et interagir
mutuellement, indépendamment de leurs plates-formes sous-jacentes, de leurs localisations
géographiques et aussi des langages dans lesquels ces applications ont été développées. Ceci
est assuré par le fait que les architectures à base de services se basent sur : (i) l’émergence d’une
couche de services (figure 1) dans laquelle, chaque service permet d’offrir une vue logique des
traitements et données existants déjà ou à développer, et où chaque service encapsule ces
traitements et données et masque ainsi l’hétérogénéité, (ii) l’utilisation des mécanismes
standards pour la publication, la recherche, l’invocation et la composition de ces services.
Figure 1 : la couche de services de SOA.
1
Chapitre 1 Introduction aux architectures orientées services
Grace au concept service, l’architecture orientée service a remporté un grand succès ce qui a
permis d’orienter cette dernière vers des aspects très variés qui dépassent largement le domaine
initial qu’est l’architecture logicielle. Aujourd’hui la SOA est considérée comme un style
architectural pour le système d’information de l’entreprise.
Dans ce chapitre, nous présentons, la notion de service à savoir : sa définition et ses composants.
Ensuite, nous présentons l’architecture orientée service à savoir : sa définition, ses composants,
son fonctionnement, les principes de conception dans SOA, le cycle de vie des services dans la
SOA enfin les avantages et les inconvénients de la SOA.
2. Notion de service
2.1.Définition
Dans une SOA, un service représente une brique logicielle dont les fonctionnalités, les
propriétés non fonctionnelles ainsi que les conditions d'utilisation sont définies de manière
déclarative par un descripteur de service. Ces services peuvent être publiés, découverts et
invoqués pour être utilisables par d’autres services. Ainsi les services peuvent être composés
pour donner d'autres services appelés services composés dont l'exécution fait intervenir d'autres
services appelés services composants. Ceci dans le but d’exécuter des fonctionnalités de plus
haut niveau. Suite à cette composition, on distingue des services (fonctionnel ou métier)
spécifiés au niveau du cahier des charges et des services (entité ou utilitaire) issu d’un travail
d’architecture applicative qui prépare l’implémentation des services métiers (Figure 2).
La liaison entre les services se fait de façon dynamique par envoi de messages. Elle n'est
effectuée qu'au moment de l'exécution, juste avant que le service requis ne soit utilisé. Grâce
aux mécanismes d'encapsulation et de liaison retardée, un service peut-être décrit et utilisé
indépendamment de sa réalisation. De ce fait un couplage extrêmement faible entre services
est assuré et l'interopérabilité de systèmes en environnements hétérogènes est facilitée.
Figure 2 : Classification des services SOA.
2
2.2.Les composants d’un service
Un service est composé de (figure 3) :

1 L’interface : L’interface de service permet de définir les modalités
d’accès au service (nom, les données d’entrée et de sortie des opérations
publiques). Ceci pour encapsuler l'implémentation et l’exécution physique
de service. La fonctionnalité du service est exposée par l'interface aux
clients.
2 Le contrat : Le contrat de service joue un rôle majeur : il détaille les
conditions d’utilisation du service sous forme de pré et post conditions,
protocoles, et contraintes.
Un contrat de service est un document organisé en plusieurs parties qui
sont :
- L’identification des parties
- La description des fonctions du service.
- La description de l’interface du service.
- La description de la qualité du service.
- La description du cycle de vie du service et du contrat.
- La description des termes de l’échange (s’il y’en a).
3 La logique d’affaire : se compose des règles de service, les exécutions et
les résultats d’un service dans la réalité. Cette partie est présentée Figure 3 : Composants de service.
particulièrement dans les services métiers.

4 Les données : Un service peut également inclure des données.
5 L’implémentation : L’implémentation de service fournit physiquement
la logique d'affaire exigée et les données appropriées. C'est la réalisation
technique qui accomplit le contrat de service.
3. L’architecture orienté services

3.1.Définition
Il n’y a pas une définition exacte de l’architecture orienté service. En effet plusieurs définitions
ont été proposées, mais toutes les définitions sont d’accord que SOA est un paradigme destiné
à résoudre les problèmes d’hétérogénéité et d’interopérabilité des logiciels qui constituent le
système d’information.
- 1ère définition : SOA est un paradigme pour l’organisation et l’utilisation de services
distribués. Elle permet d’offrir des services, découvrables, invocables et composables.
Selon cette définition, la SOA est une méthode d’architecturer un système d’information
3
en se basant non pas sur la représentation des ressources (software, applications…etc.)

ni sur les objets (Commandes, Moyen de transport, Client…etc.) mais sur les
fonctionnalités requises par l’exécution des processus métier. Tous les éléments de
l’architecture des systèmes d’information tourneraient autour de la notion de service.
- 2éme définition : SOA est un ensemble de composants qui peuvent être invoqués, et dont
les descriptions d’interface peuvent être publiées et découvertes.
- 3éme définition : SOA est un style d’architecture qui permet la réorganisation et

l’encapsulation des fonctionnalités d’un système d’information en un ensemble de
services faiblement couplés appartenant à la fois au niveau métier et au niveau technique
de l’entreprise. Les services, munis d’un contrat d’utilisation et d’une interface de
description, seront publiés dans des registres de services afin qu’ils puissent être
invoqués par des clients distants.
3.2.Les composants de la SOA

Une architecture orienté services (SOA) est constituée des trois composants suivants (figure
4) :
- Le fournisseur de service : correspond au propriétaire du service qui décrit, publie et
garanti la disponibilité du service.
- Le client : correspond au demandeur de service. D’un point de vue technique, il
recherche et invoque les services. il peut être lui-même un service.
- 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.
Les interactions de base entre ces trois composants incluent les opérations suivantes :
- Publication : opération réalisée par le fournisseur de service, qui consiste à enregistrer

le service dans l’annuaire pour le rendre accessible aux clients.
- Recherche : opération réalisée par le client, elle consiste à rechercher un service dans
l’annuaire.
- liens (binding) d’opérations : réponse de l’annuaire à une requête de recherche émise
par un client, elle consiste à trouver le service répondant à la requête du client.
4
Figure 4 : Les composants de la SOA.

3.3.Le fonctionnement de la SOA
Le fonctionnement de l’architecture orienté service se déroule comme suit (figure 5) :
1 Le fournisseur de services définit la description de son service
et la publie dans l’annuaire de service.
Le client utilise les facilités de recherche disponibles au niveau

2 de l’annuaire pour retrouver et sélectionner un service donné.
Le client examine ensuite la description du service sélectionné

3 pour récupérer les informations nécessaires lui permettant de
se connecter au fournisseur du service.
Le client commence à interagir avec l’implémentation du
4 service considéré par l’envoi des requêtes conformes à la
description du service.
5 Le service répond à la requête reçue par l’envoi d’une réponse
conforme à sa description. Figure 5 : Le fonctionnement de la SOA
Pour être fonctionnelle, l’architecture orientée service doit fournir des mécanismes de
publication (X), de recherche (Y) et d’invocation de service (Z) à savoir :
- (X) pour assurer la communication, par le moyen d'échanges de message, entre les
composants de la SOA.
- (Y) pour la description des services. Elle doit contenir la façon dont on peut accéder au
service ainsi que ce qu’il est capable de faire, sans donner le détail sur la façon dont il
est implémenté.
5
- (Z) pour la recherche des services demandés par les clients. Il sert à faciliter la
découverte des services qu’il répertorie en fournissant les détails concernant la façon
dont ils communiquent.
La concrétisation des SOA, dans un cadre technologique, revient alors à définir X, Y et Z
3.4.Les principes de conception dans SOA

Une architecture orientée services doit respecter les principes suivants :
- La réutilisation : Les services sont conçus de façon à pouvoir être réutilisés
ultérieurement. La réutilisation des services indique la possibilité de les réutiliser pour
des tâches différentes et des utilisateurs différents. Le but est de minimiser la
redondance et de permettre des modifications rapides, sans passer par une
programmation entière du système. Ceci est assuré par : (i) la dissociation des
fonctionnalités des services de tout type d’application ou de processus. (ii) le
développement de services avec plusieurs contrats d’utilisation, ce qui permet, par
conséquent, de couvrir plusieurs scénarios d’utilisation.
- L’autonomie : L’autonomie des services indique la capacité des services à utiliser leurs
ressources pour exécuter la logique métier qu’ils déploient sans l’appui de participants
externes. Grâce à leur caractéristique d’autonomie, les services entretiennent un
contrôle très significatif sur l’environnement qu’ils déploient et ses limites techniques
sont définies de manière significative, pour éviter des redondances de services.
- Le couplage faible : Le but du principe de couplage faible entre les services est de
garder une faible liaison entre les services, pour atteindre un haut degré de flexibilité
dans l’architecture. Grâce à la réduction des dépendances entre les services, il sera facile
de remplacer les services ou de les relier entre eux sons altérer le reste des services
existants. Il sera facile en outre, en cas de dysfonctionnement, de remplacer le service
dysfonctionnant sans arrêter tout le système
- L’abstraction de services : L’abstraction d’un service détermine combien
d’informations sont disponibles sur ce dernier. Cette abstraction vise à cacher le détail
des informations inutiles du contrat de service. D’une part, pour permettre au
propriétaire de service de faire évoluer le service facilement, d’autre part, pour éviter
d’influencer l’implémentation du contrat de service par son utilisateur. Ainsi, plus il y
a de détails dans le contrat de service plus le couplage entre l’utilisateur et le contrat de
service est fort. L’abstraction concerne quatre types d’information :
6
 Technologique : concerne le contrat de service et son implémentation. Il faut

éviter d’avoir une description détaillée de l’implémentation technique.
 Fonctionnelle : cette abstraction est limitée uniquement au contrat de service
qui publie certaines capacités du service. Les capacités publiées dans le contrat
de services délimitent le périmètre fonctionnel du service connu par le client.
 Programmatique : concerne les détails de conception liés à la logique du
programme utilisé pour implémenter les services (journalisation, exceptions,
authentification, etc.).
 Qualité de service : concerne la logique et le contrat du service. Ce terme
englobe des méta-informations qui permettent de déterminer le comportement
du service à l’aide d’un ensemble de règles et de contraintes.
- La cohésion forte : La cohésion dans les services adresse le degré de relation
fonctionnelle et sémantique qui existe entre les opérations accomplies par un service.
Une forte cohésion d’un service implique que les opérations de ce dernier sont fortement
reliées entre elles. Le principe de cohésion est important pour garantir la clarté et la
qualité de la conception des services, ce principe simplifie les efforts de maintenance et
d’améliorations futures.
- Découverte de services : Le principe de découverte de service permet de répondre à la
question suivante : « Est-ce que le service dont on a besoin existe déjà ou faut-il créer
un nouveau service ? » dans le but d’éviter la redondance et de favoriser la réutilisation
des services disponibles. La découverte de services se focalise essentiellement sur la
bonne définition du contrat de services. Cette dernière doit communiquer clairement les
objectifs et les capacités des services. En plus elle doit être implémentée en utilisant des
standards afin de rendre le service découvrable.
- La granularité des services : Cette propriété se rapporte à la taille du service et
l’ensemble des opérations qu’il expose. La granularité des services est déterminée par
le nombre d’opérations incluses dans le service où il faut trouver le bon compromis
entre des services qui englobent trop d’opérations (de grosse granularité) et des services
avec trop peu d’opérations (de fine granularité).
- Services sans état : Le terme sans état est utilisé pour qualifier une condition
d’exécution du service. Un service sans état ne traite pas l’état des données associées à
une activité. Autrement dit, il ne garde pas la mémoire de son exécution précédente.
Aucun état n’est préservé entre deux invocations du service. Par conséquent, toutes les
7
invocations du même service sont indépendantes. En revanche, si le service traite et

conserve l’état des données alors c’est un service avec état.
- La composition de services : Les services peuvent invoquer ou utiliser d’autres
services dont l’objectif est de créer de nouvelles fonctionnalités en combinant des
fonctionnalités offertes par des services existants. Pour cela, chaque service joue le rôle
soit d’un composable soit d’un composé soit des deux en même temps. Ainsi, il est
considéré comme un composant lorsque sa logique applicative invoque les capacités des
autres services et comme un composable lorsqu’il est appelé par d’autres services. En
réalité, un service peut être temporairement composable ou composé, car cela dépend
de sa capacité.
- Interopérabilité : Elle est considérée comme propriété fondamentale, dans le sens où
l’appel au service fonctionne quel que soit le langage de programmation et le système
d’exploitation.
3.5.Cycle de vie des services dans la SOA
Le cycle de vie des services est défini en quatre phases (détaillé au chapitre 3) :
- Construction : la phase de construction inclut le développement et le test de

l’implémentation du service, la définition de la description de l’interface et la définition
de la description d’implémentation. Il y a trois possibilités pour fournir une
implémentation d’un service par : (i) la création de nouveaux services, (ii) la
transformation des applications existantes en services, (iii) la composition de nouveaux
services et applications existantes à savoir :
 Le développement d’un nouveau service implique l’utilisation des langages de
programmations et les modèles appropriés pour l’environnement de
développement du fournisseur du service.
 La transformation des applications existantes implique la génération de la
définition de l’interface du service et l’enveloppement (Wrapping) de
l’application existante pour permettre l’interaction entre l’application existante
et le monde extérieur. L’enveloppe (Wrapper) est un logiciel qui communique
avec l’application existante telle qu’elle a été conçue et offre à l’extérieur une
nouvelle API (Application Programming Interface) où une interface graphique
peut être développée pour cette API. Il est intéressant de rappeler que ce travail
est réalisé pour les anciennes applications (Legacy systems).
8
 la composition de nouveaux services à partir des services existants implique

l’ordonnancement et l’orchestration de flux des messages entre les programmes
directement ou bien avec la technique de Workflow (cf : chapitre 4).
- Déploiement : la phase de déploiement inclut la publication de la description du service
dans un service d’enregistrement, le déploiement du code exécutable du service dans
l’environnement d’exécution et l’intégration avec les legacy systems. Pour les services
qui représentent des applications existantes, le déploiement peut inclure seulement le
service Wrapper parce que l'application peut être déjà déployée.
- Exécution : dans cette phase le consommateur du service peut trouver la description du
service et invoquer toutes les opérations définies dans le service.
- Gestion : cette phase couvre la gestion et l’administration de l’application du service :
sécurité, disponibilité,…etc.
3.6. Avantages et inconvénients de SOA

3.6.1. Avantages
- Assurer une interopérabilité intrinsèque : SOA permet aux différentes applications
d’échanger des données et des fonctionnalités entre elles, même si elles sont
développées en différents langages.
- Assurer un alignement entre le métier et la représentation physique : SOA permet
d’introduire la couche service qui encapsule les fonctionnalités techniques ce qui permet
de faciliter la traduction des représentations logiques du métier en représentation
physique sous forme de service.
- Minimiser l’investissement initial et permettre la réutilisation des services : SOA
permet d’utiliser des composants déjà existants, quel que soit le langage de
développement utilisé et quelques soit la plateforme sur laquelle ils tournent. Ceci
assure une meilleure possibilité d’évolutions, une plus grande tolérance aux pannes, une
maintenance plus facile ainsi qu’un développement rapide de nouveaux services et par
conséquent un gain en termes de temps et d’argent.
- Accroître l’agilité : dans une SOA la modification, la panne, l’amélioration,
l’élimination d’un service n’affecte pas les autres services en relation avec ce dernier.
- Minimiser les risques de défaillance : La réutilisation des services existants réduit le
risque d’introduction de nouveaux échecs dans le processus d’amélioration ou de
création de nouveaux services.
9
3.6.2. Inconvénients
- La mise en place d’une SOA a un coût élevé à la fois financier et humain :
 Former une équipe d'experts en conception 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.
 Si le fonctionnement de l’entreprise n’est pas organisé autour des services alors
il est difficile d’utilisé une SOA et donc le coût de fonctionnement sera élevé.
- Les SOA ont un intérêt limité si l’entreprise ne base pas ses processus sur l’exploitation
des services.
- Difficulté de migrer d’une architecture monolithique vers une architecture SOA sans
étude préalable efficace.
10
1. Introduction
Un service métier représente le résultat d’une opération dans une organisation. Il peut être
représenté à différents niveaux et au même titre que les opérations d’une organisation du fait
que ces dernières peuvent, aussi, être représentées à différents niveaux de granularité. Pour
obtenir un service métier, il est nécessaire que les services puissent être composés en des
services plus complexes. Cette composition se poursuit jusqu’à ce que le service résultant
fournisse un support entier pour les processus métiers. Les processus métiers sont ainsi définis
dans le contexte de la composition des services, comme étant une collection d’activités à travers
lesquelles les services sont invoqués.
Le traitement offert par un service métier, obtenus suite à la composition, est un service de type
particulier. En effet, le rôle du service métier est d’offrir un ensemble cohérent de traitements
métiers d’où le terme de processus métier (processus d’affaires) qui représente l’enchainement
d’activités à exécuter pour réaliser l’objectif du service métier. Cet enchainement forme ce
qu’il est convenu d’appeler le flux de contrôle du processus, c’est à dire sa logique d’exécution.
Ceci nécessite une bonne gestion qui permet au client de ne pas ressentir qu’il utilise un service
composé. Pour cela, la gestion des processus métiers est assurée par la méthodologie de gestion
de processus d'affaires BPM (Business Process Managenement). Cette méthodologie inclut les
concepts, les méthodes et les techniques nécessaires pour la modélisation, la conception,
l’administration, la configuration, l’exécution et l’analyse des processus métiers. Par la suite,
BPMS (Business Process Managenement Software) a proposé un ensemble d'outil destiné à
supporter la démarche BPM. Cet ensemble comprend un catalogue de processus d'affaires, des
outils de modélisation graphique (exemple : BPMN), des outils d'aide à l'implémentation, des
moteurs d'exécution à base de flux (exemple : BPEL), des moteurs de règle d'affaires pour
l'adaptation, et des outils de pilotage et de création de rapports. La Figure 1 illustre les
différentes normes en relation avec le cycle de vie d'un processus d'affaires dans le cadre de
11
Chapitre 2 Modélisation des processus d’affaires (Business Process Modeling -BPM)
BPM. Dans ce chapitre, nous présentons la modélisation des processus métiers, quant à leur
exécution ; elle sera abordée dans le chapitre 4.
Figure 1 : Les différentes normes en relation avec le cycle de vie d'un processus d'affaires
dans le cadre de BPM.
2. Processus d’affaires
2.1.Définition
Le terme processus d’affaires est une traduction française de la notion de Business Process ;
plusieurs synonymes de ce mot existent tels que : processus, processus métiers, processus
opérationnel et processus d’entreprise. Un processus d’affaires est un ensemble d'activités
structurées et mesurables conçues pour produire un résultat de valeur pour un client ou un
marché particulier. Le processus d'affaires met l'accent sur la façon dont le travail est fait au
sein d'une organisation. Les activités sont spécifiques et ordonnées dans le temps et 1’espace.
2.2.Catégorisation des processus
Les processus métiers peuvent être classés dans un espace à deux dimensions (figure 2)
suivant le temps nécessaire à l’exécution complète du processus et suivant la complexité de de
ce dernier (de simple et directe à hautement complexe). A partir de ce classement, il ressort
trois catégories bien distinctes de processus métiers : processus à processus, personne à
processus et enfin personne à personne.
12
Durée du processus
Figure 2 : Catégorisation des processus.
a- Processus à processus
Dans la majorité des cas, les processus appartenant à cette catégorie sont peu complexes
et ne durent que très peu de temps. Il s’agit de processus discrets qui se concentrent sur des
transformations de données. Leur but est de transférer un objet métier d’une application vers
une autre. Il suffit, pour cela, de définir la logique métier de transformation de ses objets.
b- Personne à processus
Les interactions personne à processus découlent le plus souvent d’un processus de type
transactionnel comme une demande de validation ou la résolution d’une exception dans une
tâche automatisée. Pour cette raison, ce type de processus est très répétitif avec peu de
différences entre les différentes instances du processus. Ces processus sont souvent basés sur
des états et impliquent des interactions personnes à processus à des étapes spécifiques alors que
les autres étapes sont automatisées. Un exemple serait l’acceptation d’accorder un crédit lors
d’une vente.
c- Personne à personne
Les processus de type personne à personne relient les employés d’une entreprise dans
un but collaboratif comme par exemple le processus de développement de nouveaux produits.
La planification des ressources est centrée sur des processus et des connaissances explicites
alors que la gestion des projets est plus guidée par des connaissances tacites.
13
3. Modélisation des processus d’affaires

Un modèle est une vue simplifiée d'une réalité complexe. Cette vue consiste à créer des
abstractions qui permettent d'éliminer les détails non pertinents et de mettre l'accent sur les
aspects les plus impo1iants. La modélisation de processus d’affaires permet de les décrire, de
les analyser et de les mettre en œuvre. La modélisation des processus d'affaires a suscité 1'intérêt
de plusieurs chercheurs et comités de normalisation. Ceci a été à l’origine de l’apparition d’une
grande variété de langages de modélisation de processus d'affaires. La majorité des techniques
de modélisation ont été développées pour répondre à des besoins spécifiques et sont issues de
différentes traditions. Donc, le choix de langage a toujours été imposé par le besoin.
La modélisation de processus d'affaires doit faire ressortir les quatre différentes vues suivantes :
- La vue fonctionnelle : représente la dépendance fonctionnelle entre les activités du
processus. Elle met 1'accent sur les activités à accomplir et les ressources produites et
consommées par ces activités.
- La vue dynamique (comportementale) : montre la séquence des étapes du processus.
Les étapes sont des activités ou des éléments de contrôle. Ces derniers décrivent
comment les activités sont connectées. La vue dynamique s'intéresse principalement à
quand et comment ces étapes sont connectées.
- La vue informationnelle: représente la description structurelle des entités manipulées
par les activités du processus d'affaires.
- La vue organisationnelle: explicite la structure organisationnelle, les rôles et les
mécanismes de communication au sein des entreprises.
4. Langages de modélisation des processus d’affaires
Les langages de modélisation des processus d’affaires peuvent être classifiés en quatre grandes
familles : les langages traditionnels, les langages dynamiques, les langages d'intégration de
processus et les langages orientés objet.
4.1.Langages traditionnels
Ces langages sont nés à partir des différents courants de modélisation en ingénierie de
l'information et des processus. Parmi ces langages on trouve :
4.1.1. IDEF
IDEF (Integration DEFinition) est une famille de langages de modélisation dans le domaine
d'ingénierie logicielle. Elle inclue les langages suivants :
- IDEF0 : Créé principalement pour la modélisation fonctionnelle. Il consiste en une
hiérarchie de diagrammes dont chacun décrit la fonctionnalité d'un système, ses entrées,
14
ses sorties et ses services. Un diagramme est un graphe de nœuds où chaque nœud peut
être une fonction simple ou un autre diagramme. Les arcs orientés représentent des flux
de données ou de contrôle. Une fonction ne peut débuter que lorsque toutes ses entrées
sont disponibles.
- IDEF1 : Modélise la vue informationnelle qui expose les entités du système ainsi que
les relations entre elles. Il est basé principalement sur le modèle relationnel de données
avec l'approche entité/relation. IDEF1 utilise la technique de conception ENALIM
(Evolving Natural Language information Model) connue maintenant sous le nom ORM
(Object Rote Modeling).
- IDEF3 : Modélise la vue dynamique en décrivant la séquence des étapes du processus
ainsi que les contraintes qui les sous-tendent et les événements du système avec une
prise en compte de l'aspect temporel. Il utilise la terminologie de scénario qui décrit une
occurrence d'un processus d'affaires. Un scénario est décrit par deux modèles selon deux
stratégies de modélisation. La première stratégie centrée sur le processus qui décrit les
séquences et la deuxième stratégie centrée sur 1'objet, qui expose la transition des objets
au sein du scénario.
4.1.2. RAD
RAD (Role Activity Diagram) est une méthode visuelle pour modéliser et analyser les processus
d’affaires. Dans le cadre de RAD, un processus d'affaires est un ensemble de rôles exécutés par
des acteurs. L'interaction entre ces rôles définit la chorégraphie. Chaque rôle expose l'ensemble
des activités ordonnées par leurs états. Une ressource (entité) peut être reliée à une activité ou
à une interaction lors d'un échange entre les rôles. RAD expose l'entité sous ses différents états
pendant le déroulement du processus en utilisant le concept d'ELH (Entity Lifetime Histories).
Un diagramme RAD supporte les concepts de base de modélisation de processus d'affaires. Il
met l'emphase sur la vue dynamique et la structure des rôles au niveau organisationnel.
4.1.3. EPC
EPC (Event-driven Process Chains) est un langage qui offre une notation graphique à base de
connecteurs logiques. Ses concepts de base sont les fonctions, les événements et les connecteurs
logiques. Un processus EPC est représenté par un graphe d'événements et de fonctions.
L'événement décrit la situation avant ou après l'exécution d'une fonction (une étape du
processus). EPC permet de modéliser les processus parallèles. Il est principalement centré sur
15
l'aspect comportemental et fonctionnel d'un processus d'affaires. Dans une version étendue,
EPC permet de représenter la vue informationnelle et la vue organisationnelle.
4.2.Langages dynamiques
Ces langages partagent les caractéristiques suivantes : (i) ils mettent l'accent sur la vue
dynamique, (ii) ils offrent une description complète permettant de mettre en œuvre et exécuter
le processus d'affaires, (iii) ils mettent l'accent sur un format de sérialisation pour les échanges,
(iv) ils sont normalisés par le WfMC (Workflow Management Coalition) (cf : chapitre 4). Parmi
ces langages en trouve :
4.2.1. BPMN
BPMN (Business Process Mode! and Notation) est un langage graphique récent de plus en plus
accepté comme une norme. Il vise à combler le vide entre la technologie de l'information et les
analystes d'affaires en présentant une notation graphique simple et facile à assimiler par des
utilisateurs ayant moins de connaissance techniques. Avec une base fondée sur les réseaux de
Pétri et centrée sur l'aspect comportemental d'un processus d'affaires, BPMN supporte tous les
concepts de base d'un processus d'affaires avec une sémantique de flux de contrôle bien définie.
4.2.2. XPDL
XPDL (XML Process Definition Language) : c’est un langage de définition de processus basé
sur XML. Il est défini dans l’objectif d’offrir un format standard de sérialisation pour BPMN.
Plusieurs entreprises utilisent XPDL pour la définition et l'échange de processus d'affaires, dont
IBM et BEA Systems.
4.2.3. BPML
BPML (Business Process Modeling Language) offre un langage formel à base de XML pour
représenter des processus exécutables qui traitent tous les aspects des processus d'affaires des
entreprises, y compris les activités complexes, les transactions et leur compensation, la gestion
des exceptions et la sémantique opérationnelle. Dans BPML, un processus est un ensemble
d'activités qui s'exécutent dans un contexte caractérisé par des propriétés spécifiques telles que
les variables et les exceptions.
4.2.4. BPDM
BPDM (Business Process Definition Metamodef) : l'objectif de ce langage est de fournir un
modèle standard pour unifier l'ensemble des normes de modélisation de processus d'affaires.
Le langage BPDM est indépendant de toute notation graphique et de toute méthodologie de
gestion de processus d'affaires ce qui a permis aux entreprises de continuer à utiliser les mêmes
outils de modélisation de processus en leur possession.
16
4.3.Langages d'intégration de processus

Suite à la nécessité de collaboration entre les entreprises ; plusieurs langages d'interaction inter-
entreprises (B2B) ont vu le jour. Ces nouveaux langages de modélisation mettent l'emphase sur
les mécanismes d'intégration en termes d'indépendance technologique, d'interfaces de
programmation et de formats d'échange de données entre les entreprises. Ces langages de
modélisation ont une sémantique opérationnelle qui suppose l'existence d'un moteur pour
l'exécution des processus. Parmi ces langages en trouve :
4.3.1. RosettaNet
RosettaNet présente plusieurs normes pour définir un langage de processus d'affaires facilitant
le commerce inter-entreprises. Il considère que les entreprises doivent assurer la compatibilité
à différents niveaux de l'infrastructure informatique pour que l'échange d'affaires puisse avoir
lieu. La structure de la norme RosettaNet est formée de plusieurs couches. Elle permet aux
entreprises d'être compatibles à différents niveaux. Dans chaque couche, RosettaNet définit une
norme. Parmi ces normes, on retrouve le PIP (Partn er Inteljace Processes), les dictionnaires
et le cadre de mise en œuvre RNIF (RosettaNet Implementation Framework) à savoir :
- Les dictionnaires définissent le vocabulaire des transactions électroniques. Il existe deux
types de dictionnaires : un pour les termes d'affaires (RosettaNet Business Dictionary)
et 1’autre pour les termes techniques (RosettaNet Technical Dictionwy).
- Les PIPs sont des modèles de processus génériques impliquant deux ou plusieurs
partenaires. La spécification PIP contient trois vues du processus : (i) la vue
opérationnelle d'affaires pour représenter la sémantique d'affaires, (ii) la vue du service
fonctionnel qui décrit les composants de l'interaction, leurs protocoles et établit une
correspondance entre les actions de PIP et les documents, et (iii) la vue de mise en œuvre
du cadre RNIF qui spécifie les formats des messages.
- Le RNIF est une spécification des protocoles d'échanges pour PIP. Elle couvre : (i) les
formats et les directives d'utilisation des messages d'affaires, (ii) les services de sécurité,
(iii) les procédures et les règles d'assemblage et de désassemblage des messages, (iv)
les protocoles de transfert des messages et la sémantique de leur flux.
4.3.2. ebXML
ebXML (Electronic Business using eXtensible Markup Language) est proposé afin de permettre
aux entreprises de toutes tailles, opérant dans n'importe quel domaine, de collaborer avec toute
autre entreprise dans le monde. ebXML propose de nouvelles normes d'échanges pour le
17
commerce électronique B2B. L'échange entre les partenaires se fait par le biais de documents
XML sur Internet. Contrairement à RosettaNet, ebXML est une collection de normes
génériques qui ne dépendent d'aucun domaine d'affaires. Parmi les normes d'ebXML, nous
citons BPSS (Business Process Specification Schema) et CPP (Collaboration Protocol Profile).
La famille des normes ebXML aborde les domaines suivants :
- La norme BPSS pour décrire des processus d'affaires. Cette dernière sert à définir la
collaboration entre des partenaires (B2B) dans un processus d'affaires à travers les
transactions et les échanges de documents.
- La norme CPP permet aux entreprises de représenter les processus d'affaires qu'elles
supportent et comment elles les supportent.
- Un mécanisme pour enregistrer et rechercher des CPP à travers un registre public
(ebXML Registry Services).
- Un mécanisme pour établir la correspondance entre deux CPPs pour produire un accord
de collaboration (Collaboration Protocol Agreement, CPA).
- Une librairie de processus d'affaires de base (Core business processes) et les documents
qui couvrent les scénarios d'affaires les plus fréquents.
4.4. Langages de modélisation orientée objet

Dans cette catégorie de langage, UML2 a introduit de nouveaux concepts d'EDOC4 pour la
représentation des aspects comportementaux et architecturaux. Cette version est enrichie avec
des notations de composition, d'agrégation comportementale et structurelle ainsi que plusieurs
autres concepts de bas niveau. UML2 englobe largement la vue dynamique, la vue fonctionnelle
et la vue informationnelle. Le diagramme d'activité dans UML 2.0 utilise la sémantique des
réseaux de Pétri. Il représente un bon langage de modélisation comportementale avec un support
pour la détection des exceptions, la gestion d'erreurs et aussi la présentation des activités
composées avec la possibilité de modélisation des partitions.
4.5. Les ontologies d'affaires
En plus de la grande famille de langages de modélisation des processus d’affaire, il existe une
famille d’ontologie d’affaire. Une ontologie d'affaires est une ontologie qui décrit le concept de
création, de transformation et d'échange de valeurs économiques. Parmi les ontologies d'affaires
on trouve :
18
4.5.1. L'ontologie REA

REA perçoit un processus d'affaires en termes de transfert ou de transformation de ressources
économiques. Par la suite, REA est devenu une ontologie de modélisation de processus
d'affaires. Les modèles REA offrent une meilleure sémantique pour la compréhension des
processus d'affaires. Les composantes principales de l'ontologie REA sont :
- Les ressources économiques : sont des objets rares et utiles qui sont sous le contrôle de
l'entreprise
- Les évènements économiques : sont des phénomènes qui changent la valeur des
ressources économiques.
- Les ressources sont incrémentées et décrémentées dans le contexte d'un événement
économique. La relation de dualité représente le lien entre les événements économiques
lors d'un processus d'échange ou de transformation de ressources.
- L'agent économique est un individu ou une organisation qui peut avoir un contrôle sur
les ressources économiques.
4.5.2. L'ontologie e3-Value

L'ontologie e3-Value a été conçue dans le but d'aider à définir comment la valeur économique
est créé et échangée au sein d'un réseau d'acteurs. L'objectif principal de l'ontologie est d'offrir
une notation graphique formelle pour la modélisation et permettre d’évaluer le profit
économique à partir du modèle. Particulièrement, elle permet de définir et analyser les relations
multi-organisationnelles, les scénarios d'affaires et les exigences opérationnelles d'une manière
à la fois qualitative et quantitative. L'ontologie e3-Value distingue trois vues pour décrire les
modèles d'affaires : (i) la vue acteur globale, (ii) la vue acteur détaillée, et (iii) la vue des
activités de valeur.
- La vue acteur global montre une vue globale des acteurs impliqués et quels objets de
valeur ils échangent.
- La vue acteur détaillée montre des aspects de décomposition de la vue acteur globale à
l’exemple des alliances entre les acteurs.
- La vue des activités de valeur souligne les activités clés et les acteurs qui les performent.
Les concepts les plus importants de l'ontologie e3-Value sont :
- L’acteur : Toute entité économique indépendante.
- L'objet de valeur (Value abject) : C'est une ressource de valeur que les acteurs
échangent. Par exemple, les produits et les services.
19
- L'échange de valeur (Value exchange) : Il permet de relier deux acteurs. Plus

exactement, deux ports de valeur.
- Le port de valeur (Value port) : C'est un concept utilisé par un acteur pour montrer qu'il
veut fournir ou acquérir des objets de valeur.
- L'interface de valeur (Value interface) : C'est un groupe de ports de valeur. Un acteur
peut avoir plusieurs interfaces de valeur.
4.5.3. L'ontologie e-BMO
L'ontologie e-BMO (e-Business Madel Ontology) définit un modèle d'affaires comme
l'architecture conceptuelle de l'entreprise et son réseau de partenaires pour la création et le
transfert de valeurs et de capital relationnel dans le but de générer du revenu profitable et
durable.
Les composants de base de l'ontologie e-BMO sont :
- les produits et services offerts par une firme qui forment une valeur essentielle pour
laquelle un client est disposé à payer,
- 1 'infrastructure et le réseau de partenaires pour la création de valeur et le maintien
d'une bonne relation client,
- le capital relationnel qui permet à l'organisation de satisfaire les demandes de ses clients
et générer des revenus profitables et durables,
- les aspects financiers tels que les coûts et les structures de revenu.
4.6. Comparaison des langages de modélisation des processus d'affaires
Le tableau suivant montre, pour chaque langage de modélisation, le niveau de support de
chacune des vues de processus d'affaires. « Oui » indique que le langage supporte la vue en
question. « Référence » indique que le langage ne supporte pas la vue, mais que les concepteurs
du langage ont lié les modèles de cette vue à des modèles dans un autre langage. « En partie »
est utilisé si le langage présente un ensemble incomplet de structures/concepts pour représenter
la vue, et « Ingrédients » est utilisé si le langage contient les ingrédients mais pas encore la
portée pour supporter la vue.
20
Langage Vue Vue Vue Vue

Informationnelle Fonctionnelle Dynamique Organisationnelle
IDEF Oui Oui Oui
RAD En partie Oui En partie
EPC Référence Oui Référence
BPML Référence Oui En partie
XPDL Référence Oui
BPMN Oui Oui En partie
BPDM Oui Oui Référence
EbXML Oui Oui En partie
UML 2 Oui Oui Oui Ingrédients
REA Ingrédients Oui En partie
RosettaNet Oui Oui
Tableau 1 : Comparaison des langages de modélisation des processus d'affaires.

Le langage BPMN couvre la vue dynamique et fonctionnelle. De plus, il est largement accepté
par la communauté. UML 2 englobe les vues dynamique, fonctionnelle et informationnelle.
Cependant, pour la vue organisationnelle, UML 2 contient les ingrédients mais pas encore la
portée. Notons aussi que le diagramme d'activité (vue dynamique) dans UML 2 demeure
complexe, notamment pour les analystes d'affaires. BPDM couvre largement la vue dynamique
et la vue fonctionnelle. De plus, c'est une norme récente qui spécifie les mécanismes d'échange
et qui offre une sémantique bien définie des concepts d'orchestration et de chorégraphie.
21
1. Introduction
Lorsque les interactions d’une SOA s'appuient sur Internet et sur les standards Web, on parle
de services Web. La conception des spécifications Web services a été menée dans l’objectif de
répondre au mieux aux enjeux de l’architecture SOA. Les Web services fournissent les bases
technologiques nécessaires pour réaliser l’interopérabilité entre les applications en utilisant
différentes plateformes, différents systèmes d’exploitation et différents langages de
programmation.
2. Définition d’un service Web

Un service Web désigne une application mise à disposition sur internet par un fournisseur de
service, et accessible via son interface par les clients à travers des protocoles Internet standard.
Les services Web peuvent être publiés, découverts, invoqués et composés pour fournir une
solution ou une réponse à un problème ou à une requête d’un utilisateur qui y accède via
l’ubiquité des protocoles Web. Les services Web reposent sur une collection de normes et de
protocoles appelée Web Services Protocol Stack contenant, entre autre : (i) SOAP pour assurer
la communication, par le moyen d'échanges de message, entre le client et le fournisseur de
service, (ii) WSDL pour la description des services Web. Cette description contient la façon
dont on peut accéder au service ainsi que, ce qu’il est capable de faire, sans donner le détail sur
la façon dont il est implémenté. (iii) UDDI pour la recherche des services Web demandés par
les clients. Il sert à faciliter la découverte des services qu’il répertorie en fournissant les détails
concernant leur façon de communiquer. SOAP, WSDL et UDDI se basent sur le langage XML.
3. Architecture des services Web

L’architecture des services Web est une architecture qui définit les éléments globaux qui
assurent l’interopérabilité des services Web. Dans ce qui suit, seront présentés :
- l’architecture de référence : utilisée pour les services Web isolés
- l’architecture étendue ou en pile : utilisée lors de la composition des services Web.
22
Chapitre 3 Les Web services
3.1.Architecture de référence
3.1.1. Les composants de l’architecture de référence
L’architecture de référence comporte trois composants de base qui sont (Figure 1) :
- Le fournisseur de service : c’est le propriétaire du service Web. Il représente
l’environnement d'hébergement et d'exécution du service. Il peut être considéré comme
«serveur» dans une architecture client/serveur. Il est constitué de trois couches de bases:
 La couche de données : contient une ou plusieurs bases de données
 La couche applicative : c'est la plateforme de développement qui assure
l'exécution du service Web
 La couche de description : elle expose les fonctionnalités du service via un
fichier WSDL
- Le client : Le client est défini comme le consommateur du service. Il peut accéder à ce
dernier en échangeant avec le fournisseur des messages SOAP. Techniquement, le client
peut être une simple application Windows ou Web, comme il peut être un autre service
Web.
- L’annuaire des services : L’annuaire des services est un registre de description qui
offre aux fournisseurs le moyen de publier et d'indexer leurs services Web sur le réseau,
il permet, en outre, aux clients de rechercher les services publiés.
Figure 1 : Architecture de référence des services Web.
3.1.2. Etapes d’exécution des Services Web dans une architecture de référence
Les principales étapes d’exécution des services Web dans l’architecture de référence sont
(Figure 2) :
23
Figure 2 : Etapes d’exécution des Services Web dans une architecture de référence.
- Etape 1 : définition et description du service Web
Cette étape consiste à décrire ce que fait le service Web ainsi que la solution qu’il
propose. La définition est faite en WSDL au sein du fournisseur de services Web.
- Etape 2 : publication du service Web
Cette étape consiste à publier le service Web dans un annuaire dédié UDDI afin de le
rendre accessible aux clients.
- Etape 3 : recherche du service Web
Dans cette étape le client se connecte, sur un annuaire UDDI pour effectuer une
recherche de service Web correspondant à ses besoins.
- Etape 4: récupération des informations de description du service et enregistrement
du client
Dans cette étape, le service Web trouvé par le client, récupère de l’annuaire UDDI la
description du service au format WSDL puis s’enregistre auprès du fournisseur associé
au service Web. Cet enregistrement indique au fournisseur l’intention du client
d’utiliser le service Web suivant les conditions décrites dans la publication.
- Etape 5 : connexion au service Web
Cette étape permet d’assurer la communication entre le composant demandeur du
service et le fournisseur de service à travers des Wrappers (listener et proxy). Pour cela,
le proxy du composant demandeur émet une requête SOAP au composant fournisseur
du service. Le protocole HTTP véhicule le message SOAP jusqu’au listener du
fournisseur du service.
24
- Etape 6 : réponse du service Web

Dans cette étape le service Web du fournisseur renvoie sa réponse au demandeur sous
la forme d’un document XML via SOAP et HTTP.
3.2. Architecture étendue ou en pile
Une architecture étendue est constituée de plusieurs couches se superposant les unes sur les
autres, d’où le nom de pile des services Web où les fonctions de couches supérieures reposent
sur celles de couches inférieures (figure 3).
Figure 3 : Architecture étendue ou en pile des services Web.

- La couche transport : assure la connectivité physique. Dans cette couche, plusieurs
protocoles peuvent supporter le transfert des services Web : HTTP, SMTP, FTP.
- L’infrastructure de base (Discovery, Description, Exchange) : ce sont les
fondements techniques établis par l’architecture de référence. Nous distinguons les
échanges des messages établis par SOAP, la description de services par WSDL et la
recherche de services Web via le registre UDDI.
- Les couches transversales (Security, Transactions, Administration, QoS) : ces
couches rendent viable l’utilisation effective des services Web dans le monde industriel.
- La couche processus métier (BusinessProcess) : cette couche supérieure permet
l’intégration de services Web, elle établit la représentation d’un « BusinessProcess »
comme un ensemble de services Web. De plus, la description de l’utilisation de
différents services composant ce service est disponible par l’intermédiaire de cette
couche.
4. Les technologies des services Web
Pour mieux comprendre l’architecture des services Web, il faut présenter avec plus de détails
les standards de base qui sont utilisés dans cette architecture (XML, SOAP, WSDL, et UDDI),
ainsi que les relations entre ces standards.
25
4.1.Le langage XML
XML est un sous ensemble du SGML (Standard Generalized Markup Language), c’est un
langage balisé, issu d’une recommandation W3C, ayant pour but d’encoder tout type de
données, indépendamment du code machine de celle-ci. Il a été développé dans le but de
partager facilement des données entres différents systèmes et en particulier à travers un réseau
type internet en séparant le contenu (données) du contenant (présentation des données).
XML est devenu une famille très large de standards variés, il est utilisé dans tous les standards
des services Web, soit WSDL, UDDI, SOAP. Parmi les spécifications XML on trouve :
- XSD (XML Schema) : c’est un langage qui sert à décrire formellement un vocabulaire.
- XSLT (Extensible Stylesheet Language Transformation) : utilisé pour transformer un
document XML basé sur un schéma en un autre document XML qui peut être un
document lui-même basé sur un autre schéma.
- XPath (XML Path Language) : fournit une syntaxe d’expression utilisée pour créer des
chemins de localisation.
4.2. SOAP (le protocole de communication des Services Web)
SOAP (Simple Object Access Protocol) ou (Service Oriented Architecture Protocol) est un
protocole pour l’échange d’informations dans un environnement reparti, basé sur le standard
XML. Il permet la communication entre composants, logiciels et applications en s’appuyant sur
des protocoles standards de type http, smtp,…etc.
SOAP définit un ensemble de règles pour structurer des messages qui peuvent être utilisés dans
de simples transmissions unidirectionnelles, mais il est particulièrement utile pour exécuter des
dialogues requête-réponse RPC (Remote Procedure Call). Il n’est lié à aucun système
d’exploitation ni à aucun langage de programmation. Ce qui permet donc, aux dialogues entre
clients et serveurs de pouvoir tourner sur n'importe quelle plate-forme et de pouvoir s’écrire
dans n'importe quel langage du moment qu'ils puissent formuler et comprendre des messages
SOAP.
4.2.1. Structure d’un message SOAP
Un message SOAP est constitué d’une enveloppe qui contient deux sous-éléments spécifiques
à SOAP à l'intérieur : un env:Header (en-tête) et un env:Body (corps) (Figure 4). Les contenus
de ces éléments sont définis par l'application et ne font pas partie de la spécification de SOAP.
26
Enveloppe SOAP
En- tête SOAP

(Header facultatif)
Corps du message SOAP

(Body)
Figure 4 : La structure des messages SOAP.
- L’enveloppe SOAP : est la racine du document XML contenant le message SOAP. Il

définit l’espace de nom (namespace : URI permettant de connaître la provenance de
chaque balise) précisant la version supportée de SOAP.
Cet espace de nom est standard et permet de différencier les éléments du schéma
(exemple : http://www.w3.org/2001/06/soap-envelope/). L’enveloppe SOAP est
constituée d’un en-tête facultatif (SOAP header) et d’un corps obligatoire (SOAP body).
- L'en-tête SOAP : c’est un élément optionnel. Il peut avoir plusieurs fils (SOAP blocks).
Ces fils sont utilisés pour ajouter les fonctionnalités au message comme
l’authentification et la gestion des transactions. Ceci permet d'étendre un message
SOAP de manière spécifique à l'application.
- Le corps SOAP : c’est un élément obligatoire. Le corps SOAP contient l’information
destinée au receveur. Il doit fournir le nom de la méthode invoquée par une requête, ou
le nom de la méthode pour générer la réponse. Il doit aussi, fournir l’espace de nom
correspondant au nom du service. Le corps SOAP peut contenir un SOAP fault. Ce bloc
est utilisé pour transmettre l’information des erreurs durant le traitement du message.
27
4.2.2. Exemple d’un message SOAP

- Exemple de requête : Quel est le prix des pommes ?
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body>
<m:GetPrice xmlns:m="http://www.w3schools.com/prices">
<m:Item>Apples</m:Item>
</m:GetPrice>
</soap:Body>
</soap:Envelope>
On remarque que les éléments m: GetPrice et Item sont des éléments spécifiques à l’application
- Exemple de réponse :
Le prix des pommes est 1,90. Une réponse SOAP est la suivante :
<soap:Envelope
<soap:Body>
<m:GetPriceResponse
xmlns:m="http://www.w3schools.com/prices">
<m:Price>1.90</m:Price>
</m:GetPriceResponse>
</soap:Body>
</soap:Envelope>
4.2.3. Le transfert des enveloppes SOAP avec HTTP

HTTP (Hypertext Transfer Protocol) est un protocole de niveau application pour les systèmes
d’information multimédia distribués et collaboratifs. Le but est de fournir au Web un protocole
de transfert simple capable d’accéder aux fichiers situés sur le réseau Internet. Le protocole
HTTP fonctionne selon un principe de requête/réponse où le client transmet une requête
comportant des informations sur le document demandé et le serveur renvoie le document si ce
dernier est disponible, dans le cas échéant, un message d’erreur est renvoyé. HTTP offre un
ensemble ouvert de méthodes et d’en-têtes qui indiquent l’objet d’une requête.
Les enveloppes SOAP peuvent etre transportés sur le protocole HTTP. Pour ce faire
l’enveloppe SOAP sera placée dans le corps HTTP (Figure 5) et le type de contenu d’entête
"Content-type" doit être "application/soap+xml"
28
Enveloppe
SOAP
Figure 5 : Structure d’un message http.
Exemple :
La requête http :
POST http://localhost:8080/NotebookWebService/notebook HTTP/1.1
Content-Type: text/xml; charset=UTF-8
SOAPAction: ""
User-Agent: Jakarta Commons-HttpClient/3.1
Host: localhost: 8080
Content-Length: 459
<soap:Envelope
<soap:Body>
<m:GetPrice xmlns:m="http://www.w3schools.com/prices">
<m:Item>Apples</m:Item>
</m:GetPrice>
</soap:Body>
</soap:Envelope>
La réponse http :
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/xml; charset=utf-8
Transfer-Encoding: chunked
Date: Sun, 13 Dec 2009 12:00:33 GMT
<soap:Envelope
<soap:Body>
<m:GetPriceResponse
xmlns:m="http://www.w3schools.com/prices">
<m:Price>1.90</m:Price>
</m:GetPriceResponse>
</soap:Body>
</soap:Envelope>
29
4.3.WSDL : le service de description

Le langage WSDL (Web Service Description Language) est un format de description des
services Web fondé sur XML. Il est utilisé pour définir l'interface générale des services Web.
Cette définition inclue des détails tels que les protocoles, les serveurs, les ports utilisés, les
opérations pouvant être effectuées, les formats des messages d'entrée et de sortie et les
exceptions pouvant être renvoyées. Les définitions WSDL permettent aux services Web de
décrire, de manière abstraite et indépendante du langage de programmation, ce qu'ils font,
comment ils le font et comment les clients peuvent les exploiter.
4.3.1. Structure d’un document WSDL
Un document WSDL contient des informations opérationnelles concernant le service. La

définition du service marquée par la balise <definitions> est la racine de tout document
WSDL. Elle peut contenir les attributs précisant le nom du service et les espaces de noms. Un
document WSDL contient un ensemble d’entités divisés en deux parties comme suit (Figure 6):
- l’interface du service : c’est la partie réutilisable de la définition du service, elle peut

être référencée par de multiples implémentations du service. Cette partie contient les
éléments suivants :
 Port types : Cet élément définit de manière abstraite une collection d’opérations
ou d’actions, chaque opération est déclenchée par une requête, puis génère une
réponse.
 Opérations : Cet élément définit de manière abstraire une action supportée par
le service Web.
 Binding (liaison) : Cet élément spécifie de manier concrète le protocole de
communication (exemple : SOAP1.1, HTTP, MIME (Multipurpose Internet
Mail Extension), …) et le format des donnés pour les opérations et messages
définis par un type de port particulier. WSDL possède des extensions internes
pour définir des services SOAP ; de fait, les informations spécifiques à SOAP
se retrouvent dans cet élément.
 Message : Cet élément est utilisé pour définir les données échangées entre
services Web.
 Types : Cet élément décrit de manière abstraite tous les types de données
échangées. Cette description n’est pas liée à un système spécifique de typage,
mais utilise par défaut la spécification XML schéma.
30
- L’implémentation de service : est la partie qui décrit comment une interface

particulière d’un service est implémentée par un fournisseur donné. Cette partie contient
les éléments suivants :
 Services : Cet élément définit une collection d’adresses permettant d’invoquer
un service. Il sert à regrouper un ensemble de points de communication. En
général ; il correspond à une URL invoquant un service SOAP.
 Ports : Cet élément définit un point de communication unique avec l’adresse
réseaux à laquelle elle est liée.
Service
Définition
d’implémentation d’un
Port
service
Binding
PortType
Définition d’interface d’un
service
Message
Type
Figure 6 : Description WSDL d’un service.
4.3.2. Exemple d’un document WSDL :

- L'élément définitions
L'élément définitions constitue la racine du document et fournit les espaces de noms.

<definitions name="RecevoirBdC"
targetNamespace=http://www.yothuyindi.fr:8080/exemple/fournisseur.wsdl
xmlns:xsd="http://www.w3.org/2001/XMLSchema/"
xmlns:wns="http://www.yothuyindi.fr:8080/exemple/fournisseur.wsdl"
xmlns:xsdl="http://www.yothuyindi.fr:8080/exemple/fournisseur.xsd"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
31
- Les Types
Ici le type de donnée ‘commande’ est décrit ci-dessous comme une date et une liste non vide de
produits à commander, chacun dans une quantité non nulle donnée.
<types>
<schema targetNamespace="http://www.yothuyindi.fr:8080/exemple/fournisseur.xsd">
<xsd:complexType name="Commande"><xsd:sequence>
<xsd:element name="dateCommande" type="xsd:date">
<xsd:element name="LigneDeCommande" minOccurs="1" maxOccurs="unbounded">
<xsd:complexType><xsd:sequence>
<xsd:element name="RéférenceProduit" type="xsd:string"/>
<xsd:element name="Quantité" type="xsd:positiveInteger"/>
</xsd:sequence></xsd:complexType> </xsd:element>
</xsd:sequence></xsd:complexType>
</schema>
</types>
- Les Messages
Ici, le document décrit deux messages pour l'interaction : le premier message est la requête
reçue par le service, l'autre est l'accusé de réception renvoyé. Les valeurs fournies pour les
attributs élément sont des noms de types XML Schema ou définis dans la partie types ci-dessus.
<message name="SoumissionBdC">
<part name="body" element="xsdl:Commande"/>
</message>
<message name="RecepisseBdC">
<part name="body" element="xsd:string"/>
</message>
- Le Type Port
Ici les opérations offertes par le service sont exposées par le biais de points d'entrée. Un point
d'entrée (élément portType) fournit la signature de chaque opération et doit par la suite être
associé à une implantation particulière (voir plus loin la description de la partie binding). WSDL
permet l'existence de plusieurs points d'entrée dans un même document. Ainsi, la même
opération peut être rendue disponible au travers d'implantations différentes. Les valeurs des
attributs message font référence à un message défini plus haut (élément message du document
WSDL). La définition de la signature d'une opération s'appuie sur trois sous éléments possibles
: input pour le message en entrée, output pour celui en sortie et fault pour un message d'erreur
émis par le service.
32
<portType name=pt_RecevoirBdC>
<operation name="op_Commande">
<input message="wsn:SoumissionBdC">
<ouput message"=wsn:RécépisséBdC">
</operation>
<operation name=...
..............
</operation>
</portType>
- La liaison (Binding)
La dernière partie du document WSDL fixe la mise en correspondance entre chaque point
d'entrée (un ensemble d'opérations) et son implantation, et permet de définir quels services sont
associés à quelle mise en correspondance. Dans le fragment donné ci-dessous, l'implantation
des points d'entrée s'appuie sur SOAP.
<binding name="bd_opCommande" type=pt_RecevoirBdC>

<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="op_Commande">
<soap:operation soapAction="http://www.yothuyindi.fr/exemple/op_Commande"/>
<input>
<soap: body
use="literal"
namespace="http://www.yothuyindi.fr/exemple/fournisseur.xsd"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding"/>
</input>
<output>
<soap:body
use="literal"
namespace="http://www.yothuyindi.fr/exemple/fournisseur.xsd"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding"/>
</output>
</operation>
</binding>
<service name=ServiceFournisseur>
<documentation> Service de réception des commandes </documentation>
<port name="PortSoumissionCommande" binding="bd_opCommande">
<soap:address location="//www.yothuyindi.fr/exemple/fournisseur"/>
</port>
</service>

</wsdl:definitions>
4.4.UDDI : le service d’enregistrement

UDDI (Universal Description, Discovery and Integration) est une spécification pour la
description et la découverte de Services Web. UDDI est une technologie qui s’articule autour
des protocoles HTTP et SOAP, et du langage XML. Les spécifications UDDI définissent les
types d’annuaires de services Web distribués : pages blanches (nom de l’entreprises, adresse,
33
contacts), pages jaunes (services classés par catégories industrielles) et pages vertes
(information d’implémentation des services Web proposés) (figure 7). Ainsi, UDDI se présente
comme un ensemble de bases de données utilisées par les entreprises pour enregistrer leurs
services Web ou pour localiser d’autres services Web.
Figure 7 : Structure de données de l’annuaire UDDI.
4.4.1. Structure d’un document UDDI
Un document UDDI dispose de la structure suivante (Figure 8) :
- Pages blanches : elles référencient les noms, adresses, contacts, identifiants, etc., des
entreprises enregistrées. Ces informations sont décrites dans des entités de type
Business Entity. Cette description inclut des informations de catégorisation permettant
de faire des recherches spécifiques dépendant du métier de l’entreprise.
- Pages jaunes : elles contiennent des détails sur le métier de l’entreprise et les services
qu’elle propose. Ces informations sont décrites dans des entités de type Business
Service.
- Pages vertes : elles comportent des informations techniques sur les services proposés.
Elles incluent des références vers les spécifications des services Web et les détails
nécessaires à l’utilisation de ces services. Ces informations sont décrites dans deux
documents : un Binding Template et un Technology Model (tModel).
- Les tModels : Représentés par un schéma XML, Ils contiennent des informations
permettant de connaître les normes que respectent le service Web, le format des
messages, le protocole de transport utilisé et d’identifier la catégorie à laquelle
appartient le service.
34
<businessEntity>
nom, contacts, description, identités, catégories
Service Web (1..n) <businessService>
<tModel>
<bindingTemplate> nom, description,

pointeurs URL vers les
Information Technique specifications WSDL
Figure 8 : Les quatre principaux éléments d’un annuaire UDDI.
Un annuaire UDDI offre plusieurs point d’entrées (API), mais les deux grandes
bibliothèques d’appels sont : l’API de requête utilisée par les utilisateurs des services Web pour
chercher et exploiter les services et l’API de publication pour publier les services Web par les
fournisseurs.
4.4.2. Exemple d’un document UDDI

- Pages blanches
<element name="businessEntity" type="uddi:businessEntity" />

<complexType name="businessEntity">
<sequence>
<element ref="uddi:discoveryURLs" minOccurs="0" />
<element ref="uddi:name" maxOccurs="unbounded" />
<element ref="uddi:description" minOccurs="0" maxOccurs="unbounded" />
<element ref="uddi:contacts" minOccurs="0" />
<element ref="uddi:businessServices" minOccurs="0" />
<element ref="uddi:identifierBag" minOccurs="0" />
<element ref="uddi:categoryBag" minOccurs="0" />
</sequence>
<attribute name="businessKey" type="uddi:businessKey" use="required" />
<attribute name="operator" type="string" use="optional" />
<attribute name="authorizedName" type="string" use="optional" />
</complexType>
35
- Pages jaunes :
<element name="businessService" type="uddi:businessService" />

<complexType name="businessService">
<sequence>
<element ref="uddi:name" minOccurs="0" maxOccurs="unbounded" />
<element ref="uddi:bindingTemplates" minOccurs="0" />
</sequence>
<attribute name="serviceKey" type="uddi:serviceKey" use="required" />
<attribute name="businessKey" type="uddi:businessKey" use="optional" />
</complexType>
- Pages vertes :
<element name="bindingTemplate" type="uddi:bindingTemplate" />

<complexType name="bindingTemplate">
<sequence>
<choice>
<element ref="uddi:accessPoint" />
<element ref="uddi:hostingRedirector" />
</choice>
<element ref="uddi:tModelInstanceDetails" />
</sequence>
<attribute name="serviceKey" type="uddi:serviceKey" use="optional" />
<attribute name="bindingKey" type="uddi:bindingKey" use="required" />
</complexType>
- tModels :
<element name="tModel" type="uddi:tModel" />

<complexType name="tModel">
<sequence>
<element ref="uddi:name" />
<element ref="uddi:overviewDoc" minOccurs="0" />
<element ref="uddi:identifierBag" minOccurs="0" />
</sequence>
<attribute name="tModelKey" type="uddi:tModelKey" use="required" />
<attribute name="operator" type="string" use="optional" />
<attribute name="authorizedName" type="string" use="optional" />
</complexType>
4.4.3. Publication d’un document WSDL dans un annuaire UDDI

Pour enregistrer un service dans un annuaire UDDI, il faut publier ses deux documents WSDL :
le document interface qui contient la définition du service (<Types>, <Message>, <Portype>,
<binding>) et le document implémentation qui contient la description du service lui-même
(<Service>, <Port>) où ce dernier importe le document interface (Figure 9).
36
Implémentation UDDI
<import>
BusinessEntity
<service> BusinessService
BusinessTemplate
<port>
BusinessTemplate
<port>
tModel
Interface
<types>
<messages>
<portType>
<Binding>
Figure 9 : Enregistrement du document WSDL dans un annuaire UDDI.
5. Autres standards pour les services Web

En plus des standards de base qui constituent l’architecture des services Web, plusieurs
initiatives sont lancées par des éditeurs spécialisés dans ce domaine. Ces standards sont destinés
à accomplir différents objectifs (échange, découverte, description, sécurité, gestion
d’interfaçage client, orchestration des processus,…etc.). Mais, tous ces standards ont un point
commun qui est XML. Le tableau ci-dessous fait le point sur quelques technologies établies
dans la sphère des Web Services :
37
Fonctions Standards
Découverte UDDI, WSIL, ADS (Advertisement and Discovery of Services Protocol), ebXML.
Description WSDL, Daml-S, OWL-S, SAWSDL,
Echange SOAP, DIME (Direct Internet Message Encapsulation), SWAT (SOAP With Attachment).
SOAP-RP (SOAP-Routing Protocol), WS-Transaction (XML Web Services Transaction
Transaction Language)
BTP (Business Transaction Protocol)
SAML (Security Assertion Markup Language), XACML (XML Access Control Markup
Sécurité
Language), WS- Security (Web Services Security)
ebXML, XLang, XPDL (XML Pipeline Definition Language), WSFL (Web Services Flow
Gestion des
Language), WSCL (Web Services Conversation Language) , tpaML (Trading Partner
processus
Agreement Markup Language), BPWS (Business Process Execution Language)
Orchestration BPML (Business Process Management Language), BPEL4WS (Business Process Execution
des processus Language for Web Services)WSBPEL,
Gestion de WSUI (Web Services User Interface), WSXL (Web Services eXperience Language), WSRP
l’interfaçage (Web Services for Remote Portals), WSCL (Web Services Component Model)
client
Pilotage des BTP, Biztalk, ebXML, RosettaNet
échanges B2B
Documents xCBL (XML Common Business Library), UBL (Universel Business Language)
commerciaux
Tableau 1 : Autres standards pour les services Web.
6. Développement des services Web

Il existe quatre méthodes de développement d’un service Web pour un fournisseur de services,
l’utilisation de ces méthodes dépend de l’existence de l’application/service et de l’interface du
service. Ces méthodes sont représentées dans le tableau suivant :
38
Scénario Green-Field
Cette méthode décrit comment une nouvelle description de l’interface du service sera créée
pour un nouveau service Web. Dans ce scénario le processus de développement est comme
suit :
Construction :
 Création d’un nouveau service Web : cette étape inclut la conception, le
développement et le test du service.
 Génération de l’interface WSDL, qui décrit le service et la manière de son invocation.
La description de l’interface du service peut être générée à partir de l’implémentation
Nouveau Web du service (actuellement la plupart des plateformes de développement fournissent une
service génération automatique du code WSDL qui décrit le service Web).
+ Déploiement :
Interface du  Publication de l’interface du service : La définition d'interface de service doit être
service n’existe pas publiée avant que le service ne soit déployé. L’interface du service est utilisée par un
demandeur du service pour déterminer comment accéder à un service. Un service
d’enregistrement (UDDI par exemple) est utilisé pour la fonction de publication, ce
dernier peut être publique ou privé tout dépend du contexte d’utilisation.
 Déploiement du service Web : le code exécutable pour le service doit être fourni dans
l’environnement d’exécution.
 Création de la définition de l’implémentation du service.
 Publication de la définition de l’implémentation du service dans un service
d’enregistrement.
Exécution :
 Exécution du service Web : le service Web est maintenant opérationnel, déployé dans
l’environnement d’exécution et publié dans un service d’enregistrement. Il peut donc,
être invoqué par les consommateurs.
Scénario Top-Down
Nouveau Web Cette méthode est utilisée lorsqu’un nouveau service Web peut être développé en se conformant
service à une interface existante. Ce type d'interface de service est habituellement une partie d'une
+ norme d'industrie qui peut être implémentée par n’importe quel nombre de fournisseurs de
Interface de services. Dans ce scénario, le processus de développement est comme suit :
service existe déjà Construction :
 Trouver l’interface du service : cette dernière est supposée existante et publiée dans
un service d’enregistrement. Donc, la fonction de recherche est faite au niveau d’un
service d’enregistrement (annuaire UDDI, par exemple).
39
 Création d’un gabarit (template) de l’implémentation du service : en utilisant la

définition de l’interface du service trouvé, un gabarit d’implémentation du service peut
être généré. Ce dernier doit contenir toutes les méthodes et les paramètres qui doivent
être implémentés par le service Web correspondant à l’interface.
 Développement d’un nouveau service : Le gabarit créé dans l’étape précédente est
utilisé pour concevoir et développer l’application qui représente le service Web. Cette
étape inclut le développement et le test du service Web.
Déploiement :
 La phase de déploiement de cette méthode (Top-Down) est presque semblable à la
phase de déploiement dans la méthode Green-Field. La seule différence c’est que la
description de l’interface est déjà publiée.
 Déploiement du service Web.
 Publication de la définition de l’implémentation du service.
Exécution :
 Exécution du service Web.
Scénario Bottom-Up
Cette méthode est utilisée lorsque les fonctionnalités existantes d’une application sont exposées
comme un service Web.
Construction :
 Génération de l’interface du service : l’interface est générée à partir de
Application/service l’implémentation de l’application qui représente le service Web.
existe déjà Déploiement :
+  Déploiement de service Web.
Interface du  Création de la définition de l’implémentation du service.
service n’existe pas  Publication de l’interface du service.
Exécution :
Scenario Meet-in-the-Middle
Application/service Cette méthode est utilisée lorsque la description de l’interface du service existe déjà et
existe déjà l’application qui représente le service existe aussi. Le problème qui peut être posé dans cette
+ situation est que les fonctionnalités de l’application existante ne peuvent pas correspondre
Interface de exactement à la description de l’interface du service Web désiré.
service existe déjà
40
Pour régler ce problème, un enveloppe (Wrapper) peut être crée pour l’application existante qui
utilise la définition de l’interface du service. Dans ce scénario le processus de développement
est comme suit :
Construction :
 Trouver l’interface du service qui sera utilisée pour implémenter le service Web
 Création d’un gabarit (template) de l’implémentation du service en utilisant la
définition de l’interface du service trouvé
 Développement du service d’enveloppement (service Warpper).
Déploiement :
 Déploiement de services Web.
Exécution :
Tableau 2 : Les méthodes de développement des services Web.
7. Les Web services RESTful

REST (representational state transfer) est un style d'architecture logicielle définissant un
ensemble de contraintes à utiliser pour créer des services Web. Les services Web conformes
au style d'architecture REST, aussi appelés services Web RESTful, établissent une
interopérabilité entre les ordinateurs sur Internet. Les services Web REST permettent aux
systèmes effectuant des requêtes de manipuler des ressources Web via leurs représentations
textuelles à travers un ensemble d'opérations uniformes et prédéfinies sans état.
REST vise à résoudre les problèmes rencontrés avec SOAP suite à l’utilisation de XML pour
envoyer des requêtes et recevoir des réponses. En effet de nombreux développeurs ont trouvé
SOAP encombrant et difficile à utiliser. Par exemple, travailler avec SOAP en JavaScript
signifie écrire une tonne de code pour effectuer des tâches extrêmement simples parce qu’on
doit créer à chaque fois la structure XML requise. Donc, la difficulté d'utiliser SOAP dépend
dans une large mesure du langage utilisé.
Contrairement à SOAP, REST offre une alternative plus simple. Au lieu d'utiliser XML pour
faire une demande, REST repose sur une simple URL pour exposer les ressources et utilise les
primitives du protocole HTTP (GET, POST, PUT et DELETE) pour effectuer des tâches.
41
De plus, contrairement à SOAP, les requêtes ne sont pas encapsulées dans une enveloppe, ce
qui réduit le cout de traitement, et elles ne sont pas limitées au XML. Elles peuvent contenir
des réponses au format CSV (Command Separated Value), JSON JavaScript Object Notation
ou encore RSS (Really Simple Syndication). Il est possible donc, d’obtenir la sortie dont on a
besoin sous une forme facile à analyser avec le langage dont on a besoin pour l’application.
La description d'une application Web RESTful est décrite par le langage WADL (Web
Application Description Language). Cette description contient le modèle des ressources
déployées, leur structure, types de supports, les méthodes HTTP, etc. Dans un sens, WADL est
un analogue de la WSDL (Web Service Description Language) qui décrit les services Web
SOAP. WADL est cependant spécifiquement conçu pour décrire les ressources Web RESTful.
Dans ce qui suit la figure 10 ainsi que le tableau 3 montrent la différence entre REST et SOAP.
Figure 10 : REST vs SOAP.
42
SOAP REST
SOAP est un protocole. REST est un style d’architecture.
SOAP signifie Simple Object Access Protocol. REST signifie REPresentational State Transfer.
SOAP ne peut pas utiliser REST car c’est un REST peut utiliser les services Web SOAP car il s’agit d’un
protocole. concept et peut utiliser n’importe quel protocole comme
HTTP, SOAP.
SOAP utilise des interfaces de services pour exposer REST utilise l’URI pour exposer la logique métier.
la logique métier.
JAX-WS est l’API java pour les services Web SOAP. JAX-RS est l’API java pour les services Web RESTful.
SOAP définit les normes à suivre strictement. REST ne définit pas trop de normes comme SOAP.
SOAP nécessite plus de bande passante et de REST nécessite moins de bande passante et de ressources que
ressources que REST. SOAP.
SOAP définit sa propre sécurité. Les services Web RESTful héritent des mesures de sécurité du
transport sous-jacent.
SOAP autorise uniquement le format de données REST autorise différents formats de données tels que le texte
XML. brut, HTML, XML, JSON, etc.
SOAP est moins préféré que REST. REST plus préféré que SOAP.
Tableau 3 : REST vs SOAP.
43
1. Introduction
L’exécution d’un processus d’affaire revient à exécuter l’ensemble des activités (les services
qui le composent) de ce dernier dans un enchainement bien déterminé. Cette exécution possède
deux vues fondamentales et complémentaires à savoir : l’orchestration et la chorégraphie.
L'orchestration décrit la séquence des activités, leurs branchements et leurs synchronisations.
La chorégraphie permet de décrire les interactions, dans le cadre de la collaboration, entre les
activités.
Les processus d’affaire permettent de réduire considérablement les coûts des transactions.
Toutefois, plusieurs problèmes de coordination peuvent être posés lors de l’exécution de ces
processus. Pour dépasser ces problèmes, la technologie Workflow s’est imposée. Cette
technologie permet de rationnaliser, coordonner et contrôler un processus d’affaire. Ceci dans
le but d’assurer une bonne gestion de l'ensemble des tâches à accomplir et des différents acteurs
impliqués dans la réalisation de ce processus. Cette technologie est supportée par un ensemble
de langages entre autre le langage BPEL (Business Process Execution Langage) adopté pour
l’exécution des processus d’affaire.
Dans ce chapitre nous présentons les méthodes de l’orchestration et de la chorégraphie, le
moteur de Workflow ainsi que le langage BPEL.
2. Orchestration et Chorégraphie
2.1.Orchestration
L’orchestration décrit comment les services Web peuvent interagir entre eux selon une
perspective opérationnelle, avec des structures de contrôle, incluant l’ordre d’exécution des
interactions (la logique métier).
Les services Web ne savent pas (et non pas besoin de savoir) qu’ils sont invoqués dans une
composition et qu’ils sont une partie d’un processus métier complexe, seul le coordinateur
central de l’orchestration le sait et prend le contrôle de tous les services Web impliqués et
coordonne l’exécution des différentes opérations des services Web qui participent dans le
processus tel que schématisé dans la figure 1.
44
Chapitre 4 Exécution de processus d’affaires
Figure1 : La composition des Web services en utilisant l’Orchestration.
2.2.Chorégraphie
La chorégraphie est, par nature, collaborative. Elle décrit les différents messages qui transitent
entre les différents acteurs d’un processus (les services), l’identité de ceux-ci n’étant pas
forcément encore connue. La chorégraphie permet la collaboration point-à-point entre plusieurs
services Web et donne ainsi une vision abstraite des échanges au sein d’un processus. Elle ne
permet en aucun cas une exécution, mais sert cependant de première spécification au processus
concret (orchestration) à réaliser. Elle permet la modélisation d’un point de vue global afin de
prendre en compte des situations de concurrences dans les environnements distribués et ainsi
donner une vue plus flexible. Contrairement à l’orchestration, la chorégraphie n’a pas de
coordinateur central. Chaque service Web impliqué dans la chorégraphie sait exactement à quel
moment ses opérations doivent être exécutées et avec qui l’interaction doit avoir lieu. La
collaboration dans la chorégraphie des services Web peut être représentée de la manière
suivante (figure 2).
Figure 2 : La composition des Web services en utilisant la chorégraphie.
45
En résumé, l’orchestration diffère de la chorégraphie, car, elle décrit un ensemble de services

Web contrôlé par un seul service Web, alors que la chorégraphie décrit un modèle plus
collaboratif, engendrant un échange de messages entre plusieurs services Web, sans qu’aucun
de ces services Web ne contrôle cet échange. Pour exécuter des processus métiers,
l’orchestration a des avantages sur la chorégraphie, parmi ces derniers :
- On connaît de façon exacte le responsable de l’exécution du processus métier en
entier
- On peut incorporer les Web services, même ceux qui ne savent pas qu’ils sont
impliqués dans des processus métiers
- On peut aussi fournir un scénario alternatif quand il y a des erreurs.
3. Moteur de Workflow
L’approche Workflow est une technologie clé pour l’automatisation des processus métiers.
Cette technologie supporte les processus métiers qui intègrent des applications ainsi que ceux
qui impliquent des tâches humaines. Elle décrit le circuit de validation, les tâches à accomplir
entre les différents acteurs d’un processus, les délais, les modes de validation, et fournit à
chacun des acteurs les informations nécessaires pour la réalisation de sa tâche.
L’effort majeur pour standardiser le Workflow a été fait par la WfMC (Workflow Management
Coalition). La WfMC définit un Workflow comme étant la vision automatisée de la totalité ou
d’une partie d’un processus durant laquelle des documents, des informations, ou des tâches sont
transmises d’un participant à un autre en suivant des règles procédurales.
La WfMC est un consortium international d’éditeurs de Workflow, d’utilisateurs, d’analystes
et de groupes de recherches, dont les objectifs sont la promotion des technologies de Workflow
et la définition de standards. La WfMC présente le méta-modèle de base pour représenter les
systèmes de Workflow. Ce méta-modèle souligne les éléments de base et les liens qui doivent
exister pour supporter l’automatisation d'un processus. Ce méta-modèle vise à établir un format
d'échange entre les différents modèles et outils de Workflow. Pour cela WfMC propose cinq
interfaces supportées par un ensemble de langages (Figure 3).
46
Figure 3 : Différents interfaces adoptés dans les WfMC.

- Interface 1 (Serveur-concepteur) : Elle définit un format commun pour l’échange
des spécifications des processus statiques entre l’outil de définition des processus et
le serveur Workflow.
- Interface 2 (Client-Serveur) : Elle supporte les interactions entre l’application client
du Workflow et le moteur de Workflow. Ces interactions incluent les Workflows,
la demande d’informations et de contrôle des processus Workflow et de leurs
activités et enfin, les fonctions administratives. Cette interface permet, également, à
une application client d’un vendeur d’interagir avec le serveur Workflow d’un autre
vendeur (interopérabilité Workflow/Application Usager).
- Interface 3 (Invocation d’applications) : Elle permet de décrire comment des
ressources externes sont invoquées par le serveur Workflow.
- Interface 4 (Serveur-Serveur interopérabilité Workflow/Workflow) : Elle décrit les
interactions entre les serveurs Workflows. Ces interactions incluent l’initiation, la
demande d’information et de contrôle des processus Workflows et de leurs activités
et les fonctions administratives.
- Interface 5 (Surveillant-Serveur) : Elle définit les fonctions d’administration et de
surveillance du serveur Workflow.
4. BPEL (business process execution language)
BPEL (Business Process Executable Language) est un langage d’exécution des processus
d'affaires basé sur XML. Il utilise WSDL (Web Services Description Language) pour spécifier
les actions du processus opérationnel et pour décrire les services Web offerts par le processus.
47
La définition d'un processus avec BPEL est constituée d’une partie déclarative des différents
éléments du processus suivie par une partie de description du processus (l’algorithme)
a. La partie déclarative
Elle permet de décrire :
- les messages échangés entre les services,
- les services appelés,
- les interactions entre les partenaires,
- les partenaires,
- les variables utilisées durant la collaboration d’affaires,
- le gestionnaire d'erreurs.
b. La partie de description
Pour cette partie BPEL offre des constructions comme des boucles, des branchements, des
variables, des assignements, etc. permettant de définir des processus métiers de manière
algorithmique. Dans cette partie les fonctionnalités les plus importantes offertes par BPEL
sont :
- Décrire la logique du processus métier à travers la composition de services.
- Composer des processus métiers complexes à partir de processus et de services plus
simples.
- Manipuler des invocations synchrones et asynchrones des opérations des services,
et gérer les callbacks qui viendront après.
- Supporter les activités séquentielles et les activités concurrentes
- Invoquer les opérations des services en séquence ou en parallèle.
- Maintenir des activités longues qui sont interruptibles.
- Reprendre des activités interrompues ou qui ont échoué pour minimiser le travail à
refaire.
- Router les messages entrants à l’activité ou au processus destinataire.
- Organiser les activités en se basant sur leur temps d’exécution et définir leur ordre
d’exécution.
- Exécuter les activités en parallèle.
- Intègrer des mécanismes de contrôle pour la gestion des flux des activités
4.1.Les principales instructions de BPEL
Un processus BPEL est composé d'étapes appelées activités. Il supporte les activités basiques
et les activités structurées
48
a. Les activités basiques :

Les activités basiques sont généralement utilisées pour réaliser des tâches courantes
- L'élément racine de tout programme BPEL c'est <process>
- Invoquer d'autres Web services en utilisant l'activité <invoke>
- Attendre à ce que le client invoque le processus métier à travers l'envoi de message
en utilisant l'activité <receive> (recevoir une requête)
- Générer une réponse pour les opérations synchrones en utilisant l'activité <reply>
- Définir les variables en utilisant <variable>
- Manipuler les données en utilisant <assign> et <copy> qui permettent d'assigner
une valeur à une variable.
- L'activité vide en utilisant <empty>
b. Les activités structurées :
Les activités basiques peuvent être combinées pour définir des algorithmes complexes
qui spécifient exactement les étapes du processus métier. Pour combiner les activités
basiques, BPEL propose différentes activités structurées dont les plus importantes sont :
- Définir un ensemble d'activités qui seront invoquées dans une séquence ordonnée
en utilisant <sequence>
- Définir un ensemble d'activités qui seront invoquées en parallèle en utilisant <flow>
- Définir les structures conditionnelles en utilisant l'activité <if> <else>
4.2.Les processus exécutables et les processus abstraits
Avec BPEL, les processus métiers peuvent être décrits de deux manières différentes : (i) par la
spécification des détails exacts des processus métiers. De tels processus sont dits des processus
métiers exécutables et suivent le paradigme d’orchestration (orchestration engine). (ii) par la
spécification de l’échange de messages publics entre les services. De tels processus sont appelés
des processus métiers abstraits. Ils n’incluent pas les détails internes des flux des processus
et ne sont pas exécutables. Ils suivent le paradigme de la chorégraphie.
a. Les processus métiers exécutables : sont des processus qui composent un ensemble
de services existants et spécifient l’algorithme exact des activités, les messages
d’entrées et les messages de sorties. De tels processus sont exécutables par des
moteurs BPEL (BPEL engines). Les processus exécutables sont importants car ils
constituent la réponse directe au problème de l’automatisation du processus métier.
La définition d’un processus métier exécutable en BPEL, revient à définir un
nouveau Web service qui est la composition des services existants. L’interface du
49
nouveau Web service utilise un ensemble d’entrées (port type) à travers lesquelles
il fournit des opérations comme n’importe quel autre Web service. Pour invoquer
un processus métier exécutable, on doit invoquer le Web service résultant. Dans la
majorité des cas BPEL est utilisé pour spécifier des processus exécutables.
b. Les processus métiers abstraits : Ils sont définis principalement pour deux
scénarios :
- Décrire le comportement du service sans savoir exactement dans quel
processus métier il va prendre place.
- Définir des protocoles de collaboration parmi plusieurs parties et préciser le
comportement externe de chaque partie.
50
1. Introduction
Dans le contexte des architectures orientées service, l'usager d'un service doit, au moins,
connaître la syntaxe des opérations qu'il souhaite utiliser. Pour cela, il utilise un contrat de
service dont la version la plus simple décrit la syntaxe de ce dernier. Le contrat peut être enrichi
par des informations non fonctionnelles telles que des informations sur le comportement et/ou
sur la qualité garantie de service. Ces données supplémentaires rendent le contrat négociable et
permettent, dans un environnement concurrentiel, à des services similaires provenant de
plusieurs fournisseurs de se distinguer.
On distingue quatre niveaux de contrat à savoir (figure 1) :
- Le niveau syntaxique : spécifie les opérations disponibles, les paramètres d'entrées et
de sorties requis et éventuellement les exceptions qui pourraient être levées durant ces
opérations.
- Le niveau comportemental : spécifie le comportement de chaque opération en utilisant
des assertions booléennes appelées pré-conditions ou post-conditions et invariants.
- Le niveau synchronisation : spécifie le comportement global d'objets en termes de
synchronisations entre appels de méthodes.
- Le niveau qualité de service (QoS) : a pour but de qualifier et quantifier la livraison
d'un service du point de vue de critères spécifiques à un domaine. Un service composé
d’un ensemble de fonctionnalités (propriétés fonctionnelles), peut-être décliné en
plusieurs services aux propriétés extra-fonctionnelles différentes, et donc de qualité
différente.
51
Chapitre 5 Formalismes pour les accords de niveau de service
Figure 1 : Les quatre niveaux de contrat
La définition de la qualité de service, dans un contrat, implique la définition des accords de

niveau SLA (Service Level Agreements) entre le fournisseur de ce service et l’utilisateur de ce
dernier. Ces accords portent généralement sur la garantie de la qualité du service fourni, sur
son tarif et sur les pénalités en cas de non-respect de l'accord. Le but est de prévenir les conflits,
en clarifiant les attentes mutuelles des parties qui y sont engagées. Ainsi, l'accord est établi dès
le départ pour éviter tout malentendu ultérieur pouvant aboutir à un conflit.
L’accord de niveau de service fournit un cadre général de compréhension des parties. Il permet
au client de disposer de garanties sur la qualité du service perçu, et au fournisseur, bien qu’il
soit tenu à des obligations de résultat, d’éviter de faire face à des attentes parfois irréalistes de
la part de ses clients.
On trouve dans la littérature par analogie avec le terme SLA, le terme SLM (Service Level
Management) qui correspond à la gestion du niveau de service, c'est-à-dire qu'il englobe tout
ce qui est surveillance, facturation et gestion des pénalités en cas de non-respect de l'accord.
Dans ce chapitre nous présentons les accords de niveau ainsi que les langages de description de
ces accords.
2. Définition d’accords de niveau
SLA (Service Level Agreements) est un contrat souscrit entre le fournisseur d'un service et un
usager de ce service dans lequel sont définis les engagements de ces deux parties.
Ces engagements déterminent le niveau de service fourni ainsi que les pénalités encourues en
cas de manquement de part et d'autre, ils sont définis par des critères objectifs de qualité de
service pouvant être évalués par les deux parties. Bien que les accords de niveaux de services
52
ressemblent à une simple contractualisation de la qualité de service, il en existe un grand

nombre de natures différentes : du basique contenant des standards de disponibilité et de
performance s'appliquant à une large gamme d'applications, aux accords plus précis, focalisés,
personnalisés qui varient d'un client à l'autre.
3. Cycle de vie d’un accord de niveau
Le cycle de vie d’un accord de niveau de service se découpe en quatre phases (figure 2) : une
première phase qui conduit à la définition des grandes lignes de l’accord et fournit une base à
la négociation. Une fois négocié, l’accord peut optionnellement être revu et renégocié au cours
de sa vie. Enfin l’accord peut se prendre fin pour diverses raisons.
Figure 2 : Cycle de vie d’un accord de niveau de service

3.1.Définition d'un accord de niveau de service
Cette phase consiste à définir les grandes lignes de l’accord pour préparer les négociations. Elle
comporte les étapes suivantes :
- Définir les parties engagées par l'accord.
- Décrire le service fourni.
- Spécifier le volume de demande pour le service.
- Définir le temps d'utilisation du service.
- Spécifier la disponibilité du service.
- Définir la fiabilité du service fourni. En pratique il s'agit du temps où le service est
effectivement disponible sur le temps de disponibilité annoncé.
- Quantifier la compensation pour le service fourni. Souvent la compensation correspond
au prix du service, mais en plus elle peut augmenter ou diminuer si l'utilisateur ou le
fournisseur ne respecte pas les accords. Elle englobe donc le principe de pénalité. Une
53
telle mesure est indispensable mais elle implique la mise en place d'un système de
facturation.
- Décrire les procédures de mesure à utiliser. Les mesures peuvent être stockées pour
être réutilisées comme preuves en cas de litige entre les parties, ou bien servir à des
outils statistiques ou prévisionnels.
- Fixer une date pour la renégociation de l'accord. Cette date est en fait une date de
validité de l'accord. Comme les politiques des différents acteurs peuvent changer (prix
du service, volume autorisé, etc.) il est nécessaire d'avoir dans ces cas-là une phase de
renégociation.
3.2.La négociation
La négociation repose sur la recherche du compromis optimal entre les besoins et les capacités
de chaque partie dans les limites de ce que ces dernières peuvent offrir.
Au terme de la négociation les parties échangent leurs consentements pour exprimer l'accord
des volontés, qui se matérialisent à travers l’acceptation de l'offre. L’acceptation, qui peut être
tacite ou explicite, est l’adhésion au contenu précis de l’offre.
Il existe trois niveaux de négociation possibles, de la plus simple à la plus sophistiquée, à
savoir :
- Niveau sélection : la première forme de négociation tient plus de la simple sélection. Le
prestataire propose un SLA, et le consommateur a uniquement le choix de l’accepter ou
le refuser. S’il accepte, l’accord est valide tel quel, dans le cas contraire le
consommateur doit trouver un autre fournisseur.
- Niveau personnalisation : dans ce cas, le fournisseur laisse plus de choix aux
consommateurs. Il peut proposer différentes offres prédéfinies et fixes parmi lesquelles
le consommateur choisit celle qui lui convient. Il peut, en outre, proposer un contrat
dont certaines clauses sont négociables parmi lesquelles, le consommateur peut choisir
la qualité de service qu'il désire tout en restant dans des intervalles prédéfinis. Le choix
du consommateur peut, dans ce cas, avoir des répercussions sur le prix du service ou la
durée d'engagement par exemple.
- Niveau conversationnel : le dernier niveau, beaucoup moins courant, correspond à une
véritable négociation stricto sensu : l'accord est construit et élaboré par les différentes
parties qui en fixent les clauses au terme d’une discussion. Ce niveau peut être atteint
par la mise en place de stratégies et de politiques de négociation. Toutefois le gain dans
54
la liberté de choix se fait au détriment du processus qui est plus complexe et implique
plus d’échanges que les deux premiers niveaux.
3.3.Renégociation
Au cours de sa vie, un accord de niveau de service peut être renégocié. Un nouveau besoin ou
de nouvelles offres de la part d'une des parties peuvent être à l’origine de cette renégociation.
La renégociation d'un accord peut aboutir à un simple prolongement de la durée, mais il est
aussi possible que les clauses du contrat soient renégociées partiellement ou même dans leur
totalité. La renégociation peut alors affecter la valeur d’un paramètre de qualité de service ou
toute autre modification de clause (politiques, tarifs, etc.). Par exemple, si un fournisseur
d'applications hébergées change son infrastructure, il peut proposer à ses clients une nouvelle
grille tarifaire, de meilleures performances (niveau de service plus haut), et les clients peuvent
soit accepter la renégociation, soit garder l’ancien contrat.
3.4.Fin de l’accord
Un accord de niveau de service peut se terminer pour trois raisons différentes :
- L'accord peut tout simplement ne plus être valide une fois que sa date d'expiration est
atteinte : il arrive à son terme.
- La violation d'une clause peut entrainer la rupture de l'accord et donc sa fin si une telle
mesure est stipulée dans les politiques.
- Si l'une des parties décide de mettre fin à l'accord, ce dernier n'est plus valide et la partie
ayant rompu le contrat peut être amenée à subir des pénalités.
4. La supervision du niveau de service SLM

La supervision du niveau de service SLM (Service Level Management), consiste à mesurer la
qualité du service rendu en regard de l'accord négocié par les parties. Le SLM fait plus
largement référence à l'ensemble des procédures et outils d'audits chargés de surveiller le
respect des objectifs de niveau de service et de faire appliquer l’accord. Il couvre un spectre
assez large de problèmes, de la prise de mesures et de leurs traitements, jusqu’à l’application
de politiques définies dans l’accord. Il a donc non seulement pour but d’évaluer et assurer le
respect du contrat, mais aussi parfois de réagir en cas de son non-respect.
55
La surveillance des accords de niveau, assurée par le SLM, doit être déléguée à une partie tierce
de confiance choisie par les parties signataires de l'accord, pour un arbitrage impartial. Cette
tierce partie peut être constituée d'un seul ou de plusieurs auditeurs. Chaque auditeur est chargé
de prendre des mesures pour vérifier le respect des accords dont la surveillance lui a été confiée.
En cas de non-respect il doit appliquer les mesures décrites par les politiques de pénalité. Les
auditeurs jouent un rôle primordial dans le SLM et deviennent des acteurs à part entière qui
pourrait être nommés certifieurs de service.
5. Langages de description d'accords de niveau

5.1.WSLA
Le langage WSLA est un langage de description d'accords de niveau de service basé sur WSDL.
La spécification WSLA intègre les différents concepts liés aux accords de niveau de service
(figure 3). Un accord de type WSLA est divisé en trois parties :
- les parties concernées par l'accord, c'est-à-dire les parties contractantes ainsi que les
parties tierces
- la description du service. Elle contient les opérations fournies par le service, le protocole
de transmission des messages, les paramètres d'accord de niveau de service, les critères
de qualité de service ainsi que les métriques associées à ces critères (les métriques
intègrent les fonctions et les algorithmes nécessaires aux mesures)
- les obligations qui concernent les garanties données par le fournisseur et les contraintes
qui lui sont imposées. De plus cette partie spécifie une date de validité de l'accord, des
formules permettant de détecter une violation de contrat et les actions à entreprendre en
cas de violation, ce qui correspond au principe de pénalité.
56
Figure 3 : Les principaux concepts de WSLA.

Les accords de niveau de service WSLA sont rédigés par le fournisseur de service avec l'accord
de l'usager, avant la phase de déploiement. Ces accords sont par la suite utilisés lors de
l'exécution par un système chargé de surveiller leur respect, le SLA Compliance Monitor.
IBM a proposé un canevas WSLA pour la prise en charge des accords de niveau de service dans
le contexte des services Web avec comme objectif de pouvoir répondre aux besoins suivants :
- Pouvoir s'adapter à une large gamme d'accords de niveau de service,
- Fournir des mécanismes automatiques de négociation,
- Chaque partie impliquée ne doit recevoir parmi les accords de niveau de service que le
fragment qui la concerne,
- Déléguer la surveillance et l'instrumentation à des parties tierces.
La figure 4 illustre le fonctionnement de ce canevas et le rôle du SLA Compliance Monitor qui

en est la partie orientée SLM. Une fois que les accords de niveau de service ont été conclus et
mis sous la forme WSLA, ils sont déployés, c'est-à-dire distribués entièrement ou partiellement
aux différentes parties par le SLA Compliance Monitor. Ce composant est ensuite responsable
des mesures et de la surveillance du respect des accords de service. Si le service d'évaluation
de condition détermine qu'une obligation n'a pas été respectée, des actions prévues dans les
accords doivent être entreprises. L'entité métier (Business Entity) contient des informations
privées propres au fournisseur de service telles que des objectifs et des politiques, et n'est là que
pour valider ou invalider les actions si elles sont ou non en accord avec les objectifs actuels du
fournisseur.
57
Figure 4 : Patron d'interactions du canevas WSLA.
5.2.Rule-based service level agreements (RBSLA)

RBSLA propose une représentation des accords de niveau de service à partir de règles en
utilisant des concepts de représentation de connaissances sophistiqués, à base de logique. Il
représente une alternative aux contrats écrits en langage naturel, ou dans des langages tels que
Java ou C++ et dont les implémentations sont disséminées dans le code applicatif. En
combinant des formalismes logiques dans le canevas ContractLog, il est possible de décrire des
spécifications de contrat à base de règles formelles qui peuvent être surveillées et exécutées de
manière automatique par des moteurs de règles.
La figure 5 illustre l'implémentation à trois niveaux qui a été réalisée : le canevas ContractLog,
le langage déclaratif RBSLA et un outil de gestion de niveau de service basé sur des règles,
RBSLM. ContractLog est implémenté sur le moteur de règles open-source Mandarax construit
au-dessus de Java, et RBSLA est un langage basé sur XML. Les règles RBSLA sont une
extension à RuleML et s’expriment donc dans un langage XML conçu pour satisfaire les
besoins du domaine des SLAs. Ces règles sont ensuite transformées pour être traitées par
ContractLog et pouvoir tirer parti de ses composants logiques de dérivation, d’event calculus,
de logique déontique, de logique défaisable, et de logique de description.
58
Figure 5 : Architecture en couches de l'approche Rule Based SLA.

Les principaux avantages de cette approche logique, par contraste avec les approches
traditionnelles par programmation, sont sa flexibilité élevée, son extensibilité dynamique et un
fort potentiel pour ce qui concerne l'automatisation de tâches telles que la détection de violation
de contrat, le contrôle d'autorisation (par la logique déontique), la détection de conflit, la
facturation de service et la création de rapport.
5.3.WS-agreement
WS-agreement se positionne comme un standard émergent succédant à WSLA. La
spécification WS-Agreement définit un protocole pour l’établissement des accords entre
fournisseur et consommateur d’un service Web en utilisant un langage XML extensible, ainsi
que des modèles d’accords (templates) pour faciliter la découverte de parties compatibles.
WS-Agreement offre un langage formel riche pour l’expression des garanties et des besoins des
services Web, ce qui permet de capturer et représenter la nature complexe des accords de niveau
de service du monde réel. Les éléments constitutifs d’un accord sont (figure 6) :
- le nom : représente le nom de l’accord. Il est optionnel.
- le contexte : sert principalement à identifier les parties engagées dans l’accord et à
préciser sa durée de vie. Cette section peut aussi contenir des informations sur le modèle
ayant servi à la création de l’accord.
- les termes : cette section est composée de deux parties :
 Les termes de service : décrivent les services concernés par l’accord, donnent
une référence vers ces services, et précisent les propriétés attachées à un service.
Ces propriétés désignent les critères de qualité de service qui seront réutilises
59
dans les objectifs de niveau de service. Chaque propriété définit un ensemble de

variables qui la qualifient.
 Les termes de garantie : un accord WS-Agreement peut contenir zéro ou
plusieurs termes de garantie ou chaque terme est composé des éléments suivants:
o La partie obligée à laquelle s’applique ce terme
o La portée de la clause : une liste de services auxquels s’applique cette
garantie.
o L’objectif de niveau de service (SLO) : exprimé en fonction des
descriptions de service.
o Une condition qualifiante : optionnelle qui doit être satisfaite pour que
la garantie soit valable.
o Une liste de valeurs métier associées à chaque SLO. Cette liste
représente la valeur qu’attachent les parties à un objectif. Une valeur
métier peut être exprimée à travers les notions d’importance, de pénalité
si l’objectif n’est pas atteint et récompense pour la partie obligée si
l’objectif est atteint, ou bien de préférence.
Figure 6 : Contenu d’un accord WS-Agreement.
Les mécanismes de mise en œuvre de la spécification WS-Agreement se découpe en trois

parties pouvant être utilisées ensemble ou indépendamment :
- un protocole d’établissement des accords,
- un protocole de création des modèles d’accords,
- un ensemble de types de ports et d’opérations pour gérer le cycle de vie de l’accord :
création, expiration, et supervision des états de l’accord. Ces opérations sont basées sur
un ensemble de standards issus du Web Services Resource Framework (WSRF).
60
6. Comparaison entre WSLA, RBSLA et WS-Agreement

Le tableau suivant récapitule les principales caractéristiques des technologies étudiées. Six
critères ont été retenus pour comparer leurs capacités : le formalisme proposé, l’attachement à
une technologie particulière, le support et le niveau de négociation, et du point de vue de la
gestion des accords, les outils de supervision et les politiques de recours.
Critères WSLA WS-Agreement RBSLA

Services Services web Service web et autre Non spécifié
ciblés
Formalisme XML Extensible XML Extensible Règles au format
Langage XML
Etablissement Interfaces de création à partir N /A
et Non spécifié d’offres Rôles d’initiateur et
Négociation répondeur
Aucun protocole spécifié
Outils de
supervision
SLM Compliance moniteur Cremona (canevas et librairie RBSLM
extensibles)
Evaluation Les parties tierces doivent Un Compliance Monitor
de la implémenter des services de évalue la conformité à partir Evaluation de
Règles T,E,C,A
Conformité mesure et d’évaluation d’une instance de SLA
spécifiés dans l’accord.
Politique de WSLA définit des garanties Définies par des valeurs Basées sur des
recours d’action : des notifications ou métier. Actions entreprises Règles logiques
des opérations de gestion en par un Compliance Manager
cas de violation de clause spécifique au système
Tableau 1 : Comparaison entre WSLA, RBSLA et WS-Agreement.

Ce tableau montre que WS-Agreement est le langage de représentation des SLAs le plus abouti
à ce jour. Ceci est dû au fait qu’il propose un mécanisme de négociation et d’obligations qui
place le consommateur et le fournisseur de service au même niveau, chaque partie pouvant
avoir des obligations.
61
1. Introduction
L'EDA (Event driven architecture) est la suite logique de SOA, poussant le concept plus loin
et corrigeant ses défauts. Elle propose de repenser les interactions entre les différents éléments
qui composent un SOA. En effet, pour un SOA classique, un service bien identifié s'adresse à
un autre service bien identifié pour lui demander une information ou d'effectuer une action. En
réponse, son correspondant lui renvoie l'information. Ainsi, l’objectif de SOA était d'avoir un
couplage faible entre les services. Malheureusement, le fonctionnement par requête-réponse
impose une forte dépendance entre les services en termes de préconception. En effet, il nécessite
pour chaque service de savoir à qui il s'adresse. En plus il impose à chaque service de définir
de manière rigide les requêtes auxquelles il sait répondre et quelles réponses il enverra.
Pour outrepasser ces inconvénients, l’architecture EDA a été proposée. L'EDA est une
architecture logicielle reposant sur le principe d'un découpage de l'application en plusieurs
parties, interagissant entre elles uniquement par la diffusion d'évènements (asynchrones et sans
destinataires) en temps réel. En EDA, les seuls messages envoyés sont des évènements et ils
sont diffusés, c'est à dire qu'ils sont envoyés sans destinataire précis, donc sans qu'il y ait de
nécessité pour la source de savoir à qui ils s'adressent. Cela signifie que les différents
composants ne conserveront plus d'informations sur leur état ni sur celui du système. Toutes les
informations d'état doivent alors être contenues dans les évènements diffusés. Le fait que
l’architecture EDA permette de détecter ces évènements et d'y réagir intelligemment constitue
l'élément clé la caractérisant.
Dans ce chapitre nous présentons l’EDA à savoir : sa définition, ses composants, ses avantages
qui seront illustrés par un exemple.
62
Chapitre 6 Event Driven Architecture (EDA)
2. Définition de l’EDA
Une architecture orientée évènements est une architecture ayant la capacité de détecter ces
derniers et d’y réagir intelligemment. Elle peut être représentée sous forme de réseau ou sous
forme de flux.
- Un réseau décentralisé : On peut voir cette architecture comme un réseau décentralisé
(figure 1). Un ensemble d'agents, connectés à un système de transmission de messages,
reçoivent et diffusent des évènements. Les agents ont tous des rôles différents, certains
pouvant même assumer plusieurs rôles. Au-delà des agents qui sont à la frontière du
système, on trouvera alors l'ensemble des sources d'évènements, physiques ou
virtuelles, internes ou externes.
Figure 1 : EDA en réseau décentralisé.

- Des flux d'évènements : Cependant, il est aussi possible de voir l'EDA en terme de flux
(figure 2). On suit alors un évènement particulier, depuis sa création jusqu'aux
conséquences possibles qu'il peut avoir : l'évènement est d'abord créé par un producteur
d'événements, qui le transmet à un diffuseur de messages. Ce dernier est chargé de
transmettre l'évènement à le processeur d'événement, qui à son tour s'occupe de le traiter
afin d'en déduire une action adéquate.
Figure 2 : EDA en flux d’évènements.
63
3. Les composants de l’architecture EDA
Une architecture EDA est composée d’un ensemble d’évènements, un ensemble d’agents, un
diffuseur de messages et un processeur d'évènements (Figure 3).
Figure 3 : Les composants de l’architecture EDA.
3.1.Évènement
Un évènement est défini comme un changement d'état, c'est à dire une variation suffisamment
significative des paramètres définissant l'état système. N'importe quelle donnée apportant une
information inédite peut donc être considérée comme un évènement. Cette définition permet
d'inclure n'importe quelle occurrence ou non-occurrence d'une action, n'importe quelle variation
d'une valeur. Cela peut être :
- une action effectuée par un utilisateur du système

- une donnée envoyée par un capteur, à fréquence fixe
- un e-mail envoyé sur une mailing-list
- une dépêche d'une agence de presse
- l'enregistrement d'une nouvelle commande d'un client
Formellement, un évènement peut être défini à plusieurs niveaux, plus ou moins précis,
apportant chacun une information propre au système :
- Notification : à ce niveau, ce qui nous intéresse est simplement de savoir si l'évènement

a eu lieu ou pas, ce qui constitue un fait en soi.
- Définition : au deuxième niveau, on analyse le type d'évènement : quel est son genre, sa
classe. Par exemple, un type évènement pourrait être « problème technique ». On parle
de type, de classe, de définition ou encore de schéma d'évènement.
64
- Détail : enfin, au troisième niveau, on s'intéresse aux détails de l'évènement, à l'instance

de la classe définie au niveau au-dessus. Si c'est un problème technique par exemple, où
et quand il a eu lieu. On parle alors d'objet, de message ou encore de type d'évènement.
Les données de l'évènement sont appelés attributs ou encore propriétés.
3.2.Les agents
Les agents sont les éléments qui vont réellement effectuer le travail dans l'architecture. On
considère trois types d'agents : ceux qui produisent, ceux qui consomment et ceux qui
transforment les évènements. En pratique, un agent sera souvent une combinaison de ces
éléments, tour à tour consommateur et producteur d'évènements. Ils correspondent aux services
d'une architecture SOA. L’utilisation des agents permet, à l’EDA, de remplacer N connexions
directes par une connexion avec intermédiaires. Alors qu’en utilisant la SOA, il faut rendre les
éléments connectés compatibles entre eux de sorte qu’ils puissent parler le même langage et
ainsi communiquer. L’EDA n’impose qu’une chose : chaque élément doit être rendu compatible
avec le diffuseur de messages. Le but reste le même : rendre la communication possible. C’est
là qu’interviennent les agents. Ils vont faire office d’éléments de liaison, de traducteurs entre le
diffuseur et le reste de l’architecture.
3.3.Le diffuseur de messages
La communication inter-éléments de l’EDA est assurée par les agents d’une part, et par le
diffuseur de messages d’autre part. Cet élément crucial et essentiel de l'architecture EDA doit
être conçu avec soin.
- Il doit pouvoir efficacement transmettre un flux important d'informations (on

veut pouvoir gérer de nombreux évènements, et chaque évènement doit contenir
l'ensemble de l'état du processus associé) depuis et vers les différents services.
- Il doit être omniprésent, afin de recueillir le plus d'informations possibles : plus
le système reçoit d'évènements, mieux il pourra agir.
- Il est recommandé d'éviter l'écueil d'un diffuseur de messages trop centralisé.
Une structure en réseau décentralisé est à préférer.
- Enfin, il est recommandé aussi de minimiser les services offerts par le
gestionnaire de messages. Tout ce qui n'est pas essentiel peut être isolé dans un
service séparé, qui sera alors plus facilement activable, désactivable ou
remplaçable.
65
3.4.Processeur d'évènements
Le processeur d'évènements, permet l’application d’une série de règles prédéfinies dans le but
d’apporter à l’EDA une certaine réactivité voire même, une certaine intelligence lors du
traitement des évènements. Une distinction est fréquemment faite entre trois types de
traitements :
- le simple event processing : reçoit un seul évènement notable et réagit à un changement

de condition précis.
- l'Event Stream Processing (ESP) : réagit à plusieurs évènements, mais travaille sur un
(et un seul) flux de données.
- Le Complex Event Processing (CEP) : consiste à corréler les évènements entre eux (de
manière causale, temporelle ou spatiale) dans le but de tenter d'inférer l'occurrence d'un
évènement complexe.
On remarque que les deux premiers peuvent être vus comme des cas particuliers du troisième.
La distinction entre ESP et CEP est d'ailleurs remise en cause. De manière générale, les moteurs
de traitement d'évènements que l'on trouvera sur le marché seront qualifiés de moteurs CEP,
dont la définition permet d'inclure les trois types de processeurs. Bien que n'étant pas
exhaustive, la figure suivante permet de se faire une idée de la richesse et de la variété du
domaine des moteurs CEP.
66
Figure 4 : Graphique présentant l'évolution des moteurs CEP.
4. Avantages de l’EDA
- Analyse systémique : La caractéristique des composants d'un système EDA est d'être
sans état, c'est-à-dire dénués d'informations sur l'état global du système. Ceci permet
donc d'adopter une approche systémique : au lieu de devoir définir un ensemble de
processus métiers il est possible de s'intéresser simplement à l'état global tel que défini
à un instant donné par l'ensemble des évènements apparus. Cette approche est
particulièrement utile lorsque le système, trop complexe, ne peut être modélisé
simplement comme un ensemble de processus où chacun de ces processus est constitué
d'une séquence d'actions. L'approche systémique permet de prendre en compte
l'ensemble des variables du système plutôt qu'un sous-ensemble restreint de celles-ci :
en effet, chaque évènement est diffusé sans apriori sur l'usage qui va en être fait.
- Agilité : l'EDA permet un couplage extrêmement faible entre les différents composants.
Ce découplage est rendu obligatoire par la communication par évènement, ce qui incite
à un découpage en de nombreux sous-systèmes plutôt qu'un système monolithique.
Comme le montre la figure 5, il s'agit du niveau de détail le plus bas. À un niveau au-
67
dessus, on se rend compte que cette architecture permet de mieux faire évoluer le
système, notamment par une réutilisabilité accrue des composants, et de mieux le
maintenir : on peut toucher à un composant du système sans que cela n'ait d'impact
majeur sur les autres. À un niveau encore au-dessus, on quitte les aspects techniques et
on constate que la facilité d'évolution et de maintenance rend le système agile, c'est à
dire capable d'être adapté rapidement et efficacement aux conditions changeantes du
métier qu'il sert. Ce sont déjà, évidemment, des avantages promus (et promis) par les
partisans de l'approche SOA. Il ne faut pas s'en étonner, puisque l'EDA est
l'aboutissement d'une réflexion sur les améliorations possibles à celle-ci. Dès lors,
l'EDA va plus loin dans la promotion de ces avantages et permet de les exploiter plus
facilement et plus efficacement.
Figure 5 : Avantage de l'EDA : du choix technique à l'avantage métier.
- Le couplage faible : plus un composant connait, ou a besoin de connaitre,

d'informations sur un autre composant avec lequel il interagit, plus il lui est
techniquement lié : un couplage fort existe entre les deux. Aussi, plus la préconception
est faible, plus le système sera découplé. La maintenabilité/ changeabilité se définit
comme capacité à maintenir le système fonctionnel au cours du temps et à le faire
évoluer en fonction de l'évolution de son environnement (nouveaux besoins,
accroissement de la charge, nouvelles règles métier, etc). Plus le système est
changeable/maintenable, plus il sera découplé.
- La réutilisabilité : L'EDA facilite la réutilisabilité en incitant les développeurs à

concevoir ses composants de manière isolée les uns des autres, encore plus qu'avec une
architecture SOA. En effet, tout ce qu'un agent doit savoir est ce qu'il veut recevoir
68
comme évènement et quelle information il désire diffuser. En quelque sorte, les

composants n'ayant pas d'interface de programmation publique, n'ont pas à rendre des
comptes aux autres composants et n'ont pas besoin de savoir comment s'interfacer avec
ces derniers.
5. Exemple
Pour mieux visualiser les avantages de l’EDA vis-à-vis la SOA nous allons appliquer les deux
architectures sur le même exemple ‘une usine de fabrication de voitures’ qui possède :
1- Un serveur hébergeant une base de données pour recueillir et stocker toutes les
données de leur système informatique
2- Une pointeuse pour le personnel
3- Un ordinateur pour la gestion du personnel
Dans cet exemple, on s’intéresse uniquement aux interconnexions résultants entre les éléments
1, 2 et 3 suite à l’utilisation des services qu’ils proposent entre eux, sans s’intéresser aux détails
des services.
Version SOA :
Selon SOA, pour les trois éléments de l’usine on peut envisager trois interconnexions (figure
6) :
- Serveur  pointeuse : oui, car la pointeuse enregistre ses données sur le serveur
- Serveur  ordinateur : oui, car l’ordinateur ajoute et puise des informations sur le
serveur
- Pointeuse  ordinateur : non
Figure 6 : Exemple d’architecture SOA – usine de voitures.

Cette architecture semble très simple, mais elle risque de devenir plus complexe si le patron de
l’usine décide d’installer un autre ordinateur pour suivre tous les autres éléments de l’usine. En
effet, dans ce cas, le patron doit être connecté au serveur de l’usine, à l’ordinateur de gestion
du personnel ainsi qu’à la pointeuse. Nous obtenons donc le résultat suivant, explicité par la
figure 7.
69
Figure 7 : Exemple d’architecture SOA – usine de voitures après l’ajout de l’ordinateur du

patron.
Après l’ajout d’un élément, l’architecture simple au départ devient donc, plus complexe
puisque, l’ajout d’un seul élément engendre la création de trois liens nouveaux. Extrapolé, vers
une architecture SOA qui est composée d’une centaine d’éléments interconnectés, l’ajout d’un
élément devant échanger des services avec la majorité des éléments préexistants, entrainerait
des centaines de liens nouveaux et rendrait l’architecture trop complexe.
Version EDA
Maintenant, si nous appliquons les principes de l’EDA à notre exemple, il faut ajouter :
- Un diffuseur de messages
- Un processeur d'évènements
- Un agent par élément (diffuseur exclus)
En les interconnectant de la manière qui convient (chaque élément avec son agent, chaque agent
avec le diffuseur), nous obtenons l’architecture décrite par la figure 8.
En termes de nombre d’interactions, nous constatons que l’EDA a permis de minimiser ces
derniers par rapport à SOA. Dans l’architecture EDA, tous les éléments sont indirectement
interconnectés. En réalité, c’est au niveau software que les liens entre éléments seront gérés.
70
Figure 8 : Exemple d’architecture EDA – usine de voitures.
Si le patron de l’usine décide d’ajouter un ordinateur, interconnecté avec celui du personnel et

avec la pointeuse. Toujours en suivant les principes de l’EDA, nous obtenons le schéma de la
figure 9.
Figure 9 : Exemple d’architecture EDA – usine de voitures après l’ajout de l’ordinateur du

patron.
Contrairement à l’architecture SOA dans laquelle, il a fallu ajouter trois connexions ; une seule
connexion a été requise pour l’EDA : celle entre l’élément et le diffuseur de messages. En plus,
l’EDA n’a pas nécessité de connaître au préalable, les éléments devant être en liaison avec
l’ordinateur du patron. Ce qui évidemment n’était pas le cas lors de la réalisation de
l’architecture SOA équivalente.
71
Dans ce chapitre, nous présentons quelques méthodes de conception des SOA.

1. Méthode SOMA
SOMA est une méthode pour l’identification, la modélisation et la spécification des services.
Elle est constituée de trois phases (figure 1) :
- La phase d’identification des services : Cette phase se base sur trois démarches : une
démarche descendante (Top-Down) pour la décomposition des domaines en domaines
fonctionnels et sous système, une démarche ascendante (Bottom-Up) pour l’analyse du
patrimoine existant et une démarche hybride (Middle-out) pour une modélisation du
service selon le but et de découvrir d’autres services qui n’ont pas été découvert aux
démarches précédentes. La démarche descendante offre une cartographie des cas
d’utilisation. Tandis que la démarche ascendante analyse les systèmes existants afin
d’identifier les services de bas niveau. La démarche hybride consiste en une
modélisation de service basée sur les buts et vise à déterminer les services qui n’ont pas
été identifiés dans les deux autres démarches,
- La phase de spécification : une fois les services identifiés dans la phase précédente,
cette phase commence par filtrer l’ensemble des services candidats en se basant sur des
règles bien déterminées à savoir : l’alignement entre fonction et métier, l’élimination
des redondances, la réutilisation des services par les différents processus métiers, et la
facilité de l’implémentation. Dans cette phase, les services sont notés sur une échelle de
1 à 5. Les services qui auront les scores les plus élevés seront considérés comme des
candidats pour la réalisation,
72
Chapitre 7 Conception des AOS et gouvernance
Figure 1 : les phases de la méthode SOAM.

- La phase de réalisation : cette phase est chargée d’implémenter l’ensemble des
services. Ceci passe par une architecture comportant cinq (05) couches horizontales et
deux couches verticales comme support à la mise en place d’une SOA au sein de
l’entreprise (Figure 2).
 La première couche : inclut les systèmes legacy, les ERP et les applications
Web de l’entreprise.
 La deuxième couche : propose d’étudier les composants de l’entreprise qui sont
responsables de la réalisation de fonctionnalités et le maintien de la QoS des
services. Ces éléments sont responsables pour assurer la conformité aux SLA
grâce à l’application des meilleures pratiques architecturales.
 la troisième couche : c’est la couche de services métiers de l’entreprise, ces
services peuvent être découverts ou statiquement liés ou invoqués ou
éventuellement chorégraphiés en un service composite.
 La quatrième couche : assure la composition ou la chorégraphie des différents
services exposés dans la troisième couche, sous forme de Workflow applicatif
afin de réaliser les processus métiers.
 La cinquième couche : ou la couche présentation offre la possibilité d’invoquer
des services à partir des portails de l’entreprise.
Les couches verticales proposées sont :
 La première couche : est la couche d’intégration des services, qui offre les
moyens pour identifier et retrouver les services et les composants et proposer les
protocoles essentiels à leurs fonctionnements.
73
 La deuxième couche : est la couche de la qualité de service qui se charge de

superviser les différents attributs de la qualité de service (QoS).
Figure 2 : La phase de réalisation de la méthode SOMA.
L’approche SOMA est une approche à la fois descendante et ascendante qui tient compte des
besoins métier. Cependant SOMA ne propose pas de description ouverte de sa méthode ce qui
rend difficile l’analyse de ses capacités réelles.
2. Méthode de Papazoglou et Heuvel

C’est une méthode de développement des services Web qui est basée sur le Rational Unified
Process (RUP), le développement orienté composant et la modélisation des processus (BPM :
Buisness Process Modelling).
La Figure 3 montre les 6 phases de la méthode et qui constituent le cycle de vie de
développement des services. Dans cette section, nous allons exposer les phases de
développement précédentes.
74
Figure 3 : les six phases de la méthode de Papazoglou et Heuvel.

- La phase de planification : cette phase détermine la faisabilité, la nature et la portée
de la solution service dans le contexte de l’entreprise. Pour réussir cette phase il suffit
de comprendre l’environnement de l’entreprise, l’analyse des besoins métier, l’étude
des technologies actuelles et de leurs capacités. Cette phase comprend aussi une analyse
financière et une estimation des coûts et des bénéfices d’un projet de développement
d’une SOA.
- La phase d’analyse et de spécification : cette phase consiste à étudier les exigences
d’une nouvelle application, elle comporte deux étapes à savoir :
 1ère étape : Elle consiste à examiner, durant la phase d’analyse, l’ensemble des
services existants « as-is » dans le but de savoir quels sont les services qui sont
déjà en place et quels sont ceux qui doivent être développés « to-be ». Il s’agit
principalement de :
o l’identification des processus,
o l’identification de la portée des processus,
o l’analyse des services existants et des services à obtenir,
o l’analyse de la réalisation des processus.
 2ème étape : c’est l’étape de spécification de service, qui se préoccupe de
spécifier les services ainsi que les processus métiers (composition des services).
La spécification des services se focalise sur la présentation de la structure du
service, de son comportement et de ses politiques. En revanche, la spécification
des processus métiers comprend la description de la structure des processus ainsi
que l’identification des paramètres non fonctionnels de ces processus.
75
- La phase de construction et de test : cette phase se concentre sur l’implémentation

des services et la définition de leurs interfaces. Puis de vérifier la compatibilité des
services obtenus par rapport aux objectifs fixés durant la phase d’analyse.
- La phase de provisionning : cette phase s’intéresse à la gouvernance, la certification,
l’enregistrement et l’audit des services afin de contrôler le comportement d’un service
durant son utilisation.
- La phase de déploiement : il s’agit d’assurer dans cette phase la publication des
interfaces des services.
- La phase d’exécution et de supervision : durant cette phase un consommateur de
service peut découvrir la définition et invoquer toutes les opérations définies. Il s’agit
par la suite d’évaluer le service en considérant ses performances d’exécution.
La méthode de Papazoglou et Heuvel présente un cycle complet pour le développement des
services. En outre, les auteurs ne présentent pas une architecture support à leur méthode et la
relation entre services et processus métier n’est pas assez détaillé.
3. Méthode de Erl
Erl présente une méthode de définition des services qui couvre les deux premières étapes du
cycle de vie de la construction d’une SOA à savoir : l’identification et la conception des
services. Avant d’aborder l’approche d’identification des services, il est important de faire le
point sur la typologie des services proposée par Erl.
3.1.la typologie des services proposée par Erl
La méthode Erl propose trois types de topologie de service à savoir :
- Le service métier : encapsule la logique métier de l’entreprise et il est issu de l’analyse
de ses différents processus. Deux types de services métier ont été présentés :
 les services métier orientés tâches (Task-centric business service) :
encapsulent la logique métier spécifique à une tâche ou à une activité (ou
plusieurs activités).
 les services métier orientés entités (Entity-centric business service) :
encapsulent la logique de fonctionnement spécifique à une entité bien
particulière.
- Le service applicatif : expose des fonctionnalités de fines granularités, qui sont
sollicitées par les services métier. Les services applicatifs peuvent être :
 des services d’intégration (pour les besoins d’intégration),
 des services d’infrastructure,
76
 des services Wrapper exposant la logique qui réside dans les applications de
l’entreprise.
- Le service hybride : ce type de service encapsule à la fois la logique métier et la logique
applicative.
3.2.Les phases de la méthode Erl
Les phases de la méthode Erl sont (figure 4) :
- La 1ère phase : cette phase consiste à décomposer les processus métiers déjà
cartographiés en un ensemble d’étapes (steps).
- La 2ème phase : après avoir identifié les étapes des processus précédemment, il faut
éliminer les étapes inappropriées qui ne peuvent pas être encapsulées par des services
telles que les étapes réalisées manuellement.
- La 3ème phase : cette étape consiste à identifier les services potentiels en regroupant les
étapes qui semblent appartenir à un même contexte. Chaque étape pourra correspondre
à une opération au sein d’un service.
- La 4ème phase : il s’agit d’identifier les logiques métiers issues de l’étude des processus.
L’objectif d’une telle identification est de sélectionner les étapes éligibles au rang
d’opérations de services.
- La 5ème phase : consiste à appliquer la logique de la SOA aux services potentiels
préalablement définis. Il s’agit d’appliquer deux principes de base de la SOA aux
services métier à savoir : la réutilisation et l’autonomie.
- La 6ème phase : cette phase consiste à définir les services composites. Ceci se réalise à
travers la construction des différents processus métiers par composition des services.
Ainsi, il sera plus facile de détecter le besoin de développer un nouveau service ou
encore le besoin d’ajouter une opération à un service.
- la 7ème phase : se charge d’étudier les besoins fonctionnels de chaque opération d’un
service. Ces besoins seront pris en considération dans la phase suivante.
- la 8ème phase : cette phase permet d’identifier les opérations des services applicatifs à
partir des besoins d’implémentation exprimés dans la phase précédente.
- la 9ème phase : les opérations appartenant à un même contexte seront regroupées afin
d’identifier les services applicatifs.
- la 10ème phase : dans cette phase les services applicatifs vont être vérifiés dans la phase
suivante afin de s’assurer qu’ils sont réutilisables et autonomes.
77
- la 11ème et la 12ème phase : ces deux dernières phases du processus consistent à revoir
les services déjà identifiés ainsi que leurs opérations.
Figure 4 : Les phases de la méthode Erl.

Dans la méthode de Erl, la typologie de services n’est pas supportée par un méta-modèle qui
récapitule l’ensemble des concepts manipulés ainsi que les relations entre eux, ceci laisse un
certain flou concernant la signification de certains types de services tels que les services
hybrides. L’approche proposée est une approche descendante ce qui signifie une refonte de
tout ou partie du système d’information de l’entreprise ce qui implique qu’elle est trop coûteuse
et trop risquée.
78
Références
1. Abderrahmane Leshob. (2013). Classification, Représentation et Spécialisation des processus d'affaires

pour le développement de systèmes d'information. Thèse de Doctorat. Université Du Québec À Montréal.
2. Aymen Baouab. (2013). Gouvernance et supervision décentralisée des chorégraphies inter-

organisationnelles. THESE de doctorat. l'Université de Lorraine.
3. Bell Marks. (2006). Service-Oriented Architecture : A planning and implementation guide for business
and technology.
4. Erl Thomas. (2008). SOA principles of Service Design, Indiana, Prentice Hall.
5. Erl Thomas. (2006). Service-Oriented Architecture, Concept, Technology, and Design, Indiana, Prentice
Hall.
6. Fournier-Morel, Pascal Grojean Dunod (2017). SOA microservices API management. Le guide de
l'architecte d'un SI agile de Xavier 4ème éd.
7. Jehan Bruggeman. (2010). Prototypage d'une application basée sur les Architectures Orientées
évènements : Application à la gestion d'essais cliniques. Mémoire de fin d’études. Pôle Universitaire
Européen Bruxelles Wallonie.
8. Lionel Touseau. (2005). Accords de niveau de service dans les plateformes dynamiques à services.
Mémoire de master. Université Joseph Fourier (Grenoble 1).
9. Molay El Mehdi, Alaoui Selsouli. (2010). Test Unitaire de Processus BPEL : Génération Orientée
Chemins de cas de Test. Université Du Québec À Montréal.
10. Lionel Touseau. (2010). Politique de Liaison aux Services Intermittents dirigée par les Accords de Niveau
de Service. THESE de doctorat. Universite de Grenoble.
11. Renaud Marteleur. (2011). Implémentation d’une architecture EDA pour le suivi de patients d’unités de
soins intensifs. Mémoire de Fin d’études. Université Libre De Bruxelles.
12. Youness LEMRABET. (2012). Proposition d’une méthode de spécification d’une architecture orientée
services dirigée par le métier dans le cadre d’une collaboration inter-organisationnelle. THESE de
doctorat. L’école centrale de lille.
13. Zerabi Soumaya. (2010). Passage d’une architecture classique vers une architecture orientée services :
Application à l’entreprise ENMTP. Memoire de Magistère. Universite De M’sila, Algeria.
14. Zoran Stojanovic, Ajantha Dahanayake. (2005). Service-Oriented Software System Engineering :
Challenges and Practices. IDEA Group, ISBN 1-59140-426-6.
15. https://www.plb.fr/formation/developpement/formation-soa,13-143.php.
16. https://www.nobleprog.be/formations-soa.
17. https://fr.coursera.org/learn/service-oriented-architecture.
18. https://fr.scribd.com/presentation/163299819/Cours-SOA-Service-Oriented-Architecture.
84

Cours SOA Dehimi

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours SOA Dehimi

Transféré par

Droits d'auteur :

Formats disponibles

République Algérienne Démocratique et Populaire

Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

Architectures Orientées Services

Niveau : 2ème année master en Informatique

Le présent document consiste en un support de cours concernant la matière intitulée

Oum El Bouaghi, Janvier 2020

Dr. DEHIMI Nour El Houda

Chapitre 1 : Introduction aux architectures orientées services

Chapitre 2 : Modélisation des processus d’affaires

Chapitre 4 : Exécution de processus d’affaires

Chapitre 5 : Formalismes pour les accords de niveau de service

Chapitre 6 : Event driven architecture (EDA)

Chapitre 7 : Conception des SOA

Série des exercices 79

Chapitre 1 : Introduction aux architectures orientées services

Chapitre 2 : Modélisation des processus d’affaires

Chapitre 3 : Les Web services

Chapitre 4 : Exécution de processus d’affaires

Chapitre 6 : Event driven architecture (EDA)

Chapitre 7 : Conception des SOA

Figure 1 : la couche de services de SOA.

Figure 2 : Classification des services SOA.

2.2.Les composants d’un service

Un service est composé de (figure 3) :

particulièrement dans les services métiers.

3. L’architecture orienté services

en se basant non pas sur la représentation des ressources (software, applications…etc.)

- 3éme définition : SOA est un style d’architecture qui permet la réorganisation et

3.2.Les composants de la SOA

- Publication : opération réalisée par le fournisseur de service, qui consiste à enregistrer

Figure 4 : Les composants de la SOA.

Le client utilise les facilités de recherche disponibles au niveau

Le client examine ensuite la description du service sélectionné

La concrétisation des SOA, dans un cadre technologique, revient alors à définir X, Y et Z

3.4.Les principes de conception dans SOA

 Technologique : concerne le contrat de service et son implémentation. Il faut

invocations du même service sont indépendantes. En revanche, si le service traite et

3.5.Cycle de vie des services dans la SOA

- Construction : la phase de construction inclut le développement et le test de

 la composition de nouveaux services à partir des services existants implique

3.6. Avantages et inconvénients de SOA

Figure 2 : Catégorisation des processus.

3. Modélisation des processus d’affaires

4.3.Langages d'intégration de processus

4.4. Langages de modélisation orientée objet

4.5.1. L'ontologie REA

4.5.2. L'ontologie e3-Value

- L'échange de valeur (Value exchange) : Il permet de relier deux acteurs. Plus

Langage Vue Vue Vue Vue

Tableau 1 : Comparaison des langages de modélisation des processus d'affaires.

2. Définition d’un service Web

3. Architecture des services Web

Figure 1 : Architecture de référence des services Web.

- Etape 6 : réponse du service Web

Figure 3 : Architecture étendue ou en pile des services Web.

4.1.Le langage XML

4.2.1. Structure d’un message SOAP

En- tête SOAP

Corps du message SOAP

Figure 4 : La structure des messages SOAP.

- L’enveloppe SOAP : est la racine du document XML contenant le message SOAP. Il

4.2.2. Exemple d’un message SOAP

4.2.3. Le transfert des enveloppes SOAP avec HTTP

Figure 5 : Structure d’un message http.