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
88
Embed
Polycopié de Cours Architectures Orientées Services (SOA) · Chapitre 1 : Introduction aux architectures orientées services 1. Introduction Les architectures à base de services
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
2. Notion de service
2.1.Définition
2.2.Les composants d’un service
3. L’architecture orienté services
3.1.Définition
3.2.Les composants de la SOA
3.3.Le fonctionnement de la SOA
3.4.Les principes de conception dans SOA
3.5.Cycle de vie des services dans la SOA
3.6. Avantages et inconvénients de SOA
3.6.1. Avantages
3.6.2. Inconvénients
1
2
2
3
3
3
4
5
6
8
9
9
10
Chapitre 2 : Modélisation des processus d’affaires
1. Introduction
2. Processus d’affaires
2.1.Définition
2.2.Catégorisation des processus
3. Modélisation des processus d’affaires
4. Langages de modélisation des processus d’affaires
4.1.Langages traditionnels
4.2.Langages dynamiques
4.3.Langages d'intégration de processus
4.4.Langages de modélisation orientée objet
4.5.Les ontologies d'affaires
4.6. Comparaison des langages de modélisation des processus d'affaires
11
12
12
12
13
14
14
16
17
18
18
20
Chapitre 3 : Les Web services
1. Introduction
2. Définition d’un service Web
3. Architecture des services Web
3.1.Architecture de référence
3.2.Architecture étendue ou en pile
4. Les technologies des services web
4.1.Le langage XML
4.2.SOAP (le protocole de communication des Services Web)
4.3.WSDL : le service de description
4.4.UDDI : le service d’enregistrement
5. Autres standards pour les services Web
6. Développement des services Web
7. Les web services RESTful
22
22
22
23
25
25
26
26
30
33
37
38
41
Chapitre 4 : Exécution de processus d’affaires
1. Introduction
2. Orchestration et Chorégraphie
2.1.Orchestration
2.2.Chorégraphie
3. Moteur de Workflow
4. BPEL (business process execution language)
44
44
44
45
46
47
Chapitre 5 : Formalismes pour les accords de niveau de service
1. Introduction
2. Définition d’accords de niveau
3. Cycle de vie d’un accord de niveau
3.1.Définition d'un accord de niveau de service
3.2.La négociation
3.3.Renégociation
3.4.Fin de l’accord
4. La supervision du niveau de service SLM
51
52
53
53
54
55
55
55
5. Langages de description d'accords de niveau
5.1.WSLA
5.2.Rule-based service level agreements (RBSLA)
5.3.WS-agreement
6. Comparaison entre WSLA, RBSLA et WS-Agreement
56
56
58
59
61
Chapitre 6 : Event driven architecture (EDA)
1. Introduction
2. Définition de l’EDA
3. Les composants de l’architecture EDA
3.1.Évènement
3.2.Les agents
3.3.Le diffuseur de messages
3.4.Processeur d'évènements
4. Avantages de l’EDA
5. Exemple
62
63
64
64
65
65
66
67
69
Chapitre 7 : Conception des SOA
1. Méthode SOMA
2. Méthode de Papazoglou et Heuvel
3. Méthode de Erl
72
74
76
Série des exercices
Références
79
84
Table des figures
Chapitre 1 : Introduction aux architectures orientées services
Figure 1 : la couche de services de SOA.
Figure 2 : Classification des services SOA.
Figure 3 : Composants de service.
Figure 4 : Les composants de la SOA.
Figure 5 : Le fonctionnement de la SOA
1
2
3
4
4
Chapitre 2 : Modélisation des processus d’affaires
Figure 1 : Les différentes normes en relation avec le cycle de vie d'un processus
d'affaires dans le cadre de BPM.
Figure 2 : Catégorisation des processus.
12
13
Chapitre 3 : Les Web services
Figure 1 : Architecture de référence des services Web.
Figure 2 : Etapes d’exécution des Services Web dans une architecture de référence.
Figure 3 : Architecture étendue ou en pile des services Web.
Figure 4 : La structure des messages SOAP.
Figure 5 : Structure d’un message http.
Figure 6 : Description WSDL d’un service.
Figure 7 : Structure de données de l’annuaire UDDI.
Figure 8 : Les quatre principaux éléments d’un annuaire UDDI.
Figure 9 : Enregistrement du document WSDL dans un annuaire UDDI.
Figure 10 : REST vis-à-vis SOAP
23
24
25
27
29
31
34
35
37
42
Chapitre 4 : Exécution de processus d’affaires
Figure 1 : La composition des Web services en utilisant l’Orchestration.
Figure 2 : La composition des Web services en utilisant la chorégraphie.
Figure 3 : Différents interfaces adoptés dans les WfMC.
45
34
37
Chapitre 5 : Formalismes pour les accords de niveau de service
Figure 1 : Les quatre niveaux de contrat
Figure 2 : Cycle de vie d’un accord de niveau de service
Figure 3 : Les principaux concepts de WSLA.
Figure 4 : Patron d'interactions du canevas WSLA.
Figure 5 : Architecture en couches de l'approche Rule Based SLA.
Figure6 : Contenu d’un accord WS-Agreement.
52
53
57
58
59
60
Chapitre 6 : Event driven architecture (EDA)
Figure 1 : EDA en réseau décentralisé.
Figure 2 : EDA en flux d’évènements.
Figure 3 : Les composants de l’architecture EDA.
Figure 4 : Graphique présentant l'évolution des moteurs CEP.
Figure 5 : Avantage de l'EDA : du choix technique à l'avantage métier.
Figure 6 : Exemple d’architecture SOA – usine de voitures.
Figure 7 : Exemple d’architecture SOA – usine de voitures après l’ajout de l’ordinateur
de patron.
Figure 8 : Exemple d’architecture EDA – usine de voitures.
Figure 9 : Exemple d’architecture EDA – usine de voitures après l’ajout de l’ordinateur
de patron.
63
63
64
67
68
69
70
71
71
Chapitre 7 : Conception des SOA
Figure 1 : les phases de la méthode SOMA
Figure 2 : La phase de réalisation de la méthode SOMA.
Figure 3 : les six phases de la méthode de Papazoglou et Heuvel.
Figure 4 : Les phases de la méthode Erl.
73
74
75
78
1
Chapitre 1 : Introduction aux architectures orientées services
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.
Chapitre 1 Introduction aux architectures orientées services
2
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.
Chapitre 1 Introduction aux architectures orientées services
3
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
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.
Figure 3 : Composants 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
Chapitre 1 Introduction aux architectures orientées services
4
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.
Chapitre 1 Introduction aux architectures orientées services
5
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.
2
Le client utilise les facilités de recherche disponibles au niveau
de l’annuaire pour retrouver et sélectionner un service donné.
3
Le client examine ensuite la description du service sélectionné
pour récupérer les informations nécessaires lui permettant de
se connecter au fournisseur du service.
4
Le client commence à interagir avec l’implémentation du
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é.
Chapitre 1 Introduction aux architectures orientées services
6
- (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 :
Chapitre 1 Introduction aux architectures orientées services
7
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
Chapitre 1 Introduction aux architectures orientées services
8
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).
Chapitre 1 Introduction aux architectures orientées services
9
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.
Chapitre 1 Introduction aux architectures orientées services
10
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.
11
Chapitre 2 : Modélisation des processus d’affaires
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
Chapitre 2 Modélisation des processus d’affaires (Business Process Modeling -BPM)
12
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.
Chapitre 2 Modélisation des processus d’affaires (Business Process Modeling -BPM)
13
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.
Du
rée
du
pro
cess
us
Chapitre 2 Modélisation des processus d’affaires (Business Process Modeling -BPM)
14
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,
Chapitre 2 Modélisation des processus d’affaires (Business Process Modeling -BPM)
15
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
Chapitre 2 Modélisation des processus d’affaires (Business Process Modeling -BPM)
16
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.
Chapitre 2 Modélisation des processus d’affaires (Business Process Modeling -BPM)
17
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
Chapitre 2 Modélisation des processus d’affaires (Business Process Modeling -BPM)
18
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 :
Chapitre 2 Modélisation des processus d’affaires (Business Process Modeling -BPM)
19
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.
Chapitre 2 Modélisation des processus d’affaires (Business Process Modeling -BPM)
20
- 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.
Chapitre 2 Modélisation des processus d’affaires (Business Process Modeling -BPM)
21
Langage Vue
Informationnelle
Vue
Fonctionnelle
Vue
Dynamique
Vue
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.
22
Chapitre 3 : Les Web services
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.
Chapitre 3 Les Web services
23
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) :
Chapitre 3 Les Web services
24
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.
Chapitre 3 Les Web services
25
- 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.
Chapitre 3 Les Web services
26
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.
Chapitre 3 Les Web services
27
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.
Enveloppe SOAP
En- tête SOAP
(Header facultatif)
Corps du message SOAP
(Body)
Chapitre 3 Les Web services
28
4.2.2. Exemple d’un message SOAP
- Exemple de requête : Quel est le prix des pommes ? <?xml version="1.0"?>