Polycopié de Cours Architectures Orientées Services (SOA) · Chapitre 1 : Introduction aux architectures orientées services 1. Introduction Les architectures à base de services

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


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


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


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


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


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


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


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


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.


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


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.


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é.


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 :


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


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).


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.


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


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.


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


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,


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


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.


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


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 :


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.


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.


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


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) :


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.


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.


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.


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)


28

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 :

<?xml version="1.0"?>

<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"


29

Figure 5 : Structure d’un message http.

Exemple :

La requête http :

La réponse http :

Enveloppe

SOAP

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>

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>

http://localhost:8080/NotebookWebService/notebook%20HTTP/1.1


30

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.


31

- 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.

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/">

Définition

d’implémentation d’un

service Port

Service

Définition d’interface d’un

service

Binding

PortType

Message

Type

http://www.yothuyindi.fr:8080/exemple/fournisseur.wsdl


32

- 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.


33

<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,


34

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.


35

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>

<businessEntity>

nom, contacts, description, identités, catégories

Service Web (1..n) <businessService>

<bindingTemplate>

Information Technique

<tModel>

nom, description,

pointeurs URL vers les

specifications WSDL


36

- 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).


37

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 :

<import>

<types>

<messages>

<portType>

<Binding>

Interface

<port>

<port>

<service>

Implémentation

BusinessTemplate

BusinessService

BusinessEntity

BusinessTemplate

tModel

UDDI


38

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).

Transaction

SOAP-RP (SOAP-Routing Protocol), WS-Transaction (XML Web Services Transaction

Language)

BTP (Business Transaction Protocol)

Sécurité SAML (Security Assertion Markup Language), XACML (XML Access Control Markup

Language), WS- Security (Web Services Security)

Gestion des

processus

ebXML, XLang, XPDL (XML Pipeline Definition Language), WSFL (Web Services Flow

Language), WSCL (Web Services Conversation Language) , tpaML (Trading Partner

Agreement Markup Language), BPWS (Business Process Execution Language)

Orchestration

des processus

BPML (Business Process Management Language), BPEL4WS (Business Process Execution

Language for Web Services)WSBPEL,

Gestion de

l’interfaçage

client

WSUI (Web Services User Interface), WSXL (Web Services eXperience Language), WSRP

(Web Services for Remote Portals), WSCL (Web Services Component Model)

Pilotage des

échanges B2B

BTP, Biztalk, ebXML, RosettaNet

Documents

commerciaux

xCBL (XML Common Business Library), UBL (Universel Business Language)

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 :


39

Nouveau Web

service

+

Interface du

service n’existe pas

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

du service (actuellement la plupart des plateformes de développement fournissent une

génération automatique du code WSDL qui décrit le service Web).

Déploiement :

Publication de l’interface du service : La définition d'interface de service doit être

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.

Nouveau Web

service

+

Interface de

service existe déjà

Scénario Top-Down

Cette méthode est utilisée lorsqu’un nouveau service Web peut être développé en se conformant

à 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

services. Dans ce scénario, le processus de développement est comme suit :

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).


40

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.

Application/service

existe déjà

+

Interface du

service n’existe pas

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

l’implémentation de l’application qui représente le service Web.

Déploiement :

Déploiement de service Web.


Publication de l’interface du service.


Exécution :


Application/service

existe déjà

+

Interface de

service existe déjà

Scenario Meet-in-the-Middle

Cette méthode est utilisée lorsque la description de l’interface du service existe déjà et

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

exactement à la description de l’interface du service Web désiré.


41

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.

https://fr.wikipedia.org/wiki/Architecture_informatique

https://fr.wikipedia.org/wiki/Internet

https://fr.wikipedia.org/wiki/Protocole_sans_%C3%A9tat


42

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.


43

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

protocole.

REST peut utiliser les services Web SOAP car il s’agit d’un

concept et peut utiliser n’importe quel protocole comme

HTTP, SOAP.

SOAP utilise des interfaces de services pour exposer

la logique métier.

REST utilise l’URI pour exposer 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

ressources que REST.

REST nécessite moins de bande passante et de ressources que

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

XML.

REST autorise différents formats de données tels que le texte

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.

44


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.

Chapitre 4 Exécution de processus d’affaires

45

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.


46

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).


47

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.


48

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


49

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


50

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.

51


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.

Chapitre 5 Formalismes pour les accords de niveau de service

52

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


53

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


54

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


55

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.


56

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é.


57

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.


58

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.


59

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


60

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).


61

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

ciblés

Services web Service web et autre Non spécifié

Formalisme

Langage

XML Extensible XML Extensible Règles au format

XML

Etablissement

et

Négociation

Non spécifié

Interfaces de création à partir

d’offres Rôles d’initiateur et

répondeur

Aucun protocole spécifié

N /A

Outils de

supervision

SLM Compliance moniteur Cremona (canevas et librairie

extensibles)

RBSLM

Evaluation

de la

Conformité

Les parties tierces doivent

implémenter des services de

mesure et d’évaluation

spécifiés dans l’accord.

Un Compliance Monitor

évalue la conformité à partir

d’une instance de SLA

Evaluation de

Règles T,E,C,A

Politique de

recours

WSLA définit des garanties

d’action : des notifications ou

des opérations de gestion en

cas de violation de clause

Définies par des valeurs

métier. Actions entreprises

par un Compliance Manager

spécifique au système

Basées sur des

Règles logiques

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.

62


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.

Chapitre 6 Event Driven Architecture (EDA)

63

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.


64

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.


65

- 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.


66

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.


67

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-


68

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


69

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.


70

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.


71

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.

72


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,

Chapitre 7 Conception des AOS et gouvernance

73

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.


74

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.


75

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.


76

- 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,


77

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.


78

- 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.

84

Références

1. Mohamed Gharzouli. (2004). Proposition d’un processus de développement des portails d’entreprises

basé sur les services web. Thèse de magister. Université Larbi Tebessi, Tebess.

2. 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.

3. Aymen Baouab. (2013). Gouvernance et supervision décentralisée des chorégraphies inter-

organisationnelles. THESE de doctorat. l'Université de Lorraine.

4. Bell Marks. (2006). Service-Oriented Architecture : A planning and implementation guide for business

and technology.

5. Erl Thomas. (2008). SOA principles of Service Design, Indiana, Prentice Hall.

6. Erl Thomas. (2006). Service-Oriented Architecture, Concept, Technology, and Design, Indiana, Prentice

Hall.

7. Fournier-Morel, Pascal Grojean Dunod (2017). SOA microservices API management. Le guide de

l'architecte d'un SI agile de Xavier 4ème éd.

8. 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.

9. Lionel Touseau. (2005). Accords de niveau de service dans les plateformes dynamiques à services.

Mémoire de master. Université Joseph Fourier (Grenoble 1).

10. 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.

11. Lionel Touseau. (2010). Politique de Liaison aux Services Intermittents dirigée par les Accords de Niveau

de Service. THESE de doctorat. Universite de Grenoble.

12. 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.

13. 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.

14. 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.

15. Zoran Stojanovic, Ajantha Dahanayake. (2005). Service-Oriented Software System Engineering :

Challenges and Practices. IDEA Group, ISBN 1-59140-426-6.

16. https://www.plb.fr/formation/developpement/formation-soa,13-143.php.

17. https://www.nobleprog.be/formations-soa.

18. https://fr.coursera.org/learn/service-oriented-architecture.

https://www.plb.fr/formation/developpement/formation-soa,13-143.php

https://www.nobleprog.be/formations-soa

https://fr.coursera.org/learn/service-oriented-architecture

85

19. https://fr.scribd.com/presentation/163299819/Cours-SOA-Service-Oriented-Architecture.

https://fr.scribd.com/presentation/163299819/Cours-SOA-Service-Oriented-Architecture