La gouvernance SOA Ses aspects théoriques et pratiques

Département d’Informatique

Université de Fribourg, Suisse

http://diuf.unifr.ch

La gouvernance SOA

Ses aspects théoriques et pratiques

Otto Poveda Hernández

Chemin de Bel-Air 6

CH-1752 Villars-sur-Glâne

Mobile: +41 79 7747677

[email protected]

Travail de master en Informatique de Gestion

Encadré par :

1er lecteur: Dr Stefan Hüsemann

2nd lecteur: Prof. Dr Jacques Pasquier-Rocha

Fribourg, 21 Juillet 2008

i

Table des matières

1 Introduction .............................................................................................. 9

1.1 Motivation .................................................................................................................... 9

1.2 Objectifs ..................................................................................................................... 10

1.3 Structure ..................................................................................................................... 10

2 Les services .............................................................................................12

2.1 La notion de service ................................................................................................... 12

2.2 Modèles de services ................................................................................................... 14

2.3 Caractéristiques des services ...................................................................................... 16

2.4 Les rôles ..................................................................................................................... 23

2.5 Spécifications et technologies .................................................................................... 24

3 Architecture orientée services.................................................................28

3.1 L’évolution de SOA ................................................................................................... 28

3.2 Les couches d’application, métier et de processus..................................................... 31

3.2.1 Les outils de registre et référentiel de services............................................................ 35

4 La gouvernance SOA ...............................................................................37

4.1 Introduction ................................................................................................................ 37

4.1.1 Les risques de SOA..................................................................................................... 38

4.1.2 L’origine de la gouvernance des TI............................................................................. 43

4.1.3 Le contenu de la gouvernance des TI......................................................................... 47

4.1.4 Relation entre la gouvernance TI et SOA ................................................................... 49

4.2 Le Roadmap ............................................................................................................... 58

4.3 Planification et exécution de SOA ............................................................................. 60

4.4 La gouvernance des services ...................................................................................... 64

4.4.1 La phase de « Design-Time »...................................................................................... 66

4.4.2 La phase de « Run-Time » .......................................................................................... 78

5 Etude de cas « e-dec » .............................................................................86

5.1 Motivations de la plateforme « e-dec »...................................................................... 87

5.2 Description de la solution « e-dec » ........................................................................... 89

5.2.1 Modèle métier import.................................................................................................. 89

5.2.2 Architecture et technologies........................................................................................ 90

6 Implémentation du prototype « e-dec Governance » ................................94

6.1 Objectifs du prototype « e-dec Governance »............................................................ 94

6.2 Exigences et besoins................................................................................................... 95

6.3 Architecture du prototype « e-dec Governance »....................................................... 97

6.4 SecureSpan Gateway Virtual Appliance .................................................................... 99

6.4.1 Le fonctionnement de SSG Manager ........................................................................ 102

6.4.2 Support et conformité aux standards ......................................................................... 103

6.4.3 Intégration avec des outils de la gouvernance Design-Time..................................... 104

6.5 Gouvernance Run-Time ........................................................................................... 104

6.5.1 Publication d’EdecImportService ............................................................................. 105

6.5.2 Les politiques d’accès pour EdecImportService ....................................................... 106

6.5.3 Les politiques de sécurité .......................................................................................... 107

6.5.4 L’implémentation du SLA ........................................................................................ 108

6.5.5 La logique de WS-Policy et les assertions ................................................................ 108

6.6 Présentation des résultats ......................................................................................... 110

6.6.1 Consolidation des connaissances théoriques de SOA ............................................... 110

6.6.2 Le prototype de gouvernance SOA pour EdecImportService ................................... 111

6.6.3 Evaluation de la passerelle virtuelle SecureSpan Gateway....................................... 113

7 Conclusions ...........................................................................................115

A Artefacts ................................................................................................117

B Installation et Configuration ...................................................................120

C CD-Rom..................................................................................................123

Bibliographie ..............................................................................................124

Liste des figures

Figure 1: Composants d’un service [Erl 2005, p. 296]. ........................................................... 13

Figure 2: A gauche, le client est couplé à la logique du service. A droite, il est couplé aux

ressources du service [Erl 2007, p. 188]. ................................................................................. 20

Figure 3: Client avec couplage fonctionnelle hérité d’une dépendance de même type entre le

service et une logique externe [Erl 2007, p. 188]..................................................................... 21

Figure 4: Spécifications des Services Web [Abou khaled and Mugellini 2007, p. 15]............ 24

Figure 5: Structures de données de la spécification UDDI ...................................................... 25

Figure 6: Messages SOAP et des contrats WSDL [Abou khaled and Mugellini 2007, p. 29 and

p. 45]......................................................................................................................................... 26

Figure 7: Vision par application et vision intégrée .................................................................. 29

Figure 8: Découplage entre les processus et les applications................................................... 30

Figure 9: Une vue d'ensemble sur l'architecture SOA ............................................................. 31

Figure 10: Les différentes couches de services ........................................................................ 32

Figure 11: Exemple d’un diagramme BPMN [Josuttis 2007, Chap. Business Process

Modeling]. ................................................................................................................................ 34

Figure 12: Le registre publie les contrats de services qui sont consultés par les clients

potentiels. ................................................................................................................................. 36

Figure 13: Exemple des nombreux documents produits dans chaque étape du cycle de vie de

services Cf. [Arch2Arch 2006c, p. 8]..................................................................................... 39

Figure 14: Conformité légale et stratégiques fait de la pression sur SOA ............................... 40

Figure 15: Faible couplage implémenté par les services web [Pulier and Taylor 2006, p. 78].

.................................................................................................................................................. 41

Figure 16: Le contenu de la gouvernance d'entreprise. ............................................................ 44

Figure 17: Le concept de l'IT business foundation. Image tirée de [Georgel 2005, p. 2]. ....... 46

Figure 18: Les principaux domaines de la gouvernance TI [IT Governance Institute 2003, p.

20]............................................................................................................................................. 50

Figure 19 Structure de gouvernance TI et SOA...................................................................... 52

Figure 20: Communication non sécurisée entre le fournisseur et le consommateur de service

[Cf. Ultes-Nitches 2006, p. 15-19]........................................................................................... 57

Figure 21: Le Roadmap doit inclure les principes de SOA ainsi que l'architecture de référence.

.................................................................................................................................................. 58

Figure 22: Une vue très simplifiée du cycle de vie SOA......................................................... 61

Figure 23: Architecture de référence pour SOA Cf. [High, Kinder et al. 2005, p. 25]............ 62

Figure 24: Modèle de maturité SOA en trois étapes [Josuttis 2007, Chap. Classification de

services].................................................................................................................................... 64

Figure 25: Les trois phases du cycle de vie des services SOA ................................................ 65

Figure 26: Processus top-down défini dans [Erl 2005, p. 364] ................................................ 68

Figure 27: Processus bottom-up défini dans[Erl 2005, p. 367]................................................ 68

Figure 28: Classification de services selon la logique encapsulée dans un service. ................ 72

Figure 29: Processus du portefeuille de services. .................................................................... 73

Figure 30: Différents types d'accords sur les niveaux de service............................................. 74

Figure 31: Processus de développement et management des SLAs [Cf. Maurer, Matlus et al.

2000 p. 18]................................................................................................................................ 76

Figure 32: Gouvernance Design-Time des SLA [Cf. webMethods 2005, p. 5]....................... 77

Figure 33: Gouvernance Run-Time basée sur les politiques [Cf. Ritu and Latha 2008, p. 31].80

Figure 34: Gouvernance Run-Time dans la gestion de la sécurité des services ....................... 82

Figure 35: Processus de gestion de la capacité [Cf. Macfarlane and Rudd 2006, p. 55] ......... 84

Figure 36: Nombre de déclarations (en millions) pendant la période 1995 au 2007. Graphique

publié dans [AFD 2007, p. 23]................................................................................................. 86

Figure 37: Recettes encaissées pour le compte de la Confédération [OFIT 2007, p. 6]. ......... 89

Figure 38: Délimitation en packages d’e-dec import ............................................................... 89

Figure 39: Architecture « e-dec ». Graphique tiré de [Innotvation Process Technology 2008,

p. 10]......................................................................................................................................... 91

Figure 40 : L'architecture d'e-dec Governance. ....................................................................... 97

Figure 41: Projet e-dec/IPV Web Services dans soapUI.......................................................... 98

Figure 42 : Les différentes catégories de politiques implémentées dans la passerelle SSG. . 100

Figure 43 : Policy Enforcement sur les requêtes envoyées à EdecImportService ................. 101

Figure 44 : L'interface du Dashboard contenu dans le gestionnaire de SSG......................... 103

Figure 45 : Les services web publiées dans la passerelle SSG. ............................................. 105

Figure 46: Vue globale de l'interface WSDL......................................................................... 118

Figure 47 : Vue globale du fichier EdecImportService Policy.xml ....................................... 119

Figure 48 : SSG_32bit_VirtualAppliance_v43 ...................................................................... 120

Figure 49 : Fichier hosts du serveur linux.............................................................................. 121

Figure 50 : Politiques d'EdecImportService........................................................................... 122

Figure 51: Structure du CD-Rom........................................................................................... 123

Liste des tableaux

Tableau 1 : Catégories de services ........................................................................................... 15

Tableau 2: Mécanismes de gouvernance d'entreprise .............................................................. 44

Tableau 3 : Relation entre les solutions métier et TI................................................................ 51

Tableau 4: Quelques paramètres utilisés pour mesurer la performance des services. ............. 53

Tableau 5 : Relation entre les solutions métier et l'infrastructure SOA tiré de [Arch2Arch

2006a, p. 11]............................................................................................................................. 59

Tableau 6: Principes d'architecture .......................................................................................... 70

Tableau 7 : SLA du service web EdecImportService ............................................................ 117

Tableau 8: Contenu du dossier EdecImportService ............................................................... 123

Tableau 9 : Contenu du dossier SoapUI................................................................................. 123

Tableau 10: Contenu du dossier Virtual SecureSpan Gateway 4.3........................................ 123

Résumé

L’architecture orientée services (SOA) est une approche architecturale de dernière générationqui permet de passer d’une vision « application » à une vision « services ». Elle réunit en unseul nom un grand nombre de concepts tels que, la composition, l’abstraction, l’autonomie, lecouplage faible, la modélisation et le monitoring des processus métier, etc. Du point de vuetechnique, elle s’appuie sur une infrastructure large et hautement distribuée contenant descomposants diverses comme les bus de services (ESB), les registres et référentiels de services,etc. Cette diversité représente au même temps la force et la faiblesse de SOA car si elle n’estpas suffisamment contrôlée peut mettre en danger la réalisation des bénéfices tant espérés(retour sur investissement élevés, minimisation des coûts des TIs et souplesseorganisationnelle). Par conséquent, il est nécessaire d’accompagner l’adoption de cetteapproche avec un modèle de gouvernance approprié que l’on connaît comme la gouvernanceSOA. Cette dernière est en effet une extension de la gouvernance des TIs qui consiste endéfinir et faire appliquer un ensemble de règles et principes (politiques) spécifiques à chaquephase du cycle de vie d’un service. La gouvernance en Design-Time désigne les mécanismeset procédures permettant de contrôler les aspects fonctionnels et techniques de l’architectureet des services. La gouvernance Run-Time se focalise principalement sur les mécanismes decontrôle que l’on devrait exercer sur les opérations de déploiement, monitoring etmanagement de la qualité des services (QoS). Enfin, sachant que la seule constante eninformatique s’appelle « le changement », SOA n’échappe pas à ce principe et doit reposersur la gouvernance en Change-Time qui désigne la manière de contrôler, surveiller etmaîtriser les effets des changements survenus au niveau métier et des TI.

Mots-clés

Architecture, services, gouvernance, gestion, management, risques, alignement, procédures,principes, politiques, règles, application, composition, couplage, autonomie, services web etcomposants.

Liste des acronymes

Acronyme Signification

SOA

BPM

MDB

SSZ

LDAP

ESB

TI

AFD

WS

e-dec

SOX

SAML

DMZ

SSG

PKI

UDDI

WSS

WSDL

SOAP

Service-Oriented Architecture

Business Process Management

Message-Driven Beans

Shared Service Zone

Lightweight Directory Access Protocol

Enterprise Service Bus

Technologie de l’information

Administration fédérale des douanes

Web Service

Electronic declaration

Sarbanes-Oxley

Security Assertions Markup Language

Demilitarized Zone

SecureSpan Gateway

Public Key Infrastructure

Universal Description Discovery and Integration

WS-Security

Web Service Definition Language

Simple Object Access Protocol

9

1Introduction

1.1 Motivation

L’architecture orientée service (SOA) se présente comme un concept innovant qui permet auxentreprises d’atteindre un niveau élevé de flexibilité et d’interopérabilité. On dit souventqu’elle est la technologie la mieux adaptée aux nouvelles exigences du marché où uneorganisation doit être capable de réagir rapidement aux changements produits dans sonenvironnement (intérieur comme à l’extérieur). Par exemple, lorsqu’une entreprise réalise unestratégie d’achat d’un concurrent, elle doit intégrer les différents systèmes et applications pourbénéficier de l’effet de synergie qu’une telle opération est sensé générer. Si l’architecture enplace est de type SOA, l’interopérabilité devient plus facile grâce à l’utilisation des standardsouverts supportés par l’ensemble de fournisseurs de logiciels.

Cette possibilité de faire interagir des services hétérogènes (services de comptabilité avecceux du département de finance) montre la portée transversale de l’architecture SOA et laisseimaginer tous les avantages que l’on peut tirer d’une telle approche. Malgré cela, le caractèredynamique et distribué de SOA représente aussi un risque pour l’entreprise si celle-ci neparvient pas à définir les règles et directives permettant de bien contrôler et évaluerl’architecture mise en place. Les risques de prolifération de services (services dupliqués,nombre élevé de services non utilisé, etc.), leur indisponibilité, l’absence d’accords au niveaude service (SLA) touchant les aspects de performance et sécurité, sont quelques exemples desproblèmes survenus lorsque l’implémentation SOA n’est pas suivie d’un cadre degouvernance adapté.

Sans la gouvernance, SOA est destinée à l’échec car elle manquerait du support nécessairepour gérer les différents éléments qui la composent. Ces éléments, possédant aussi bien decaractéristiques techniques que stratégiques, nécessitent une structure organisationnelle quipermette de refléter les rôles et responsabilités des parties prenantes (TI et métier). Par lagouvernance, chaque entreprise peut définir ses propres objectifs qu’elle aimerait atteindre enadoptant une SOA ainsi que les ressources de TI dont elle a besoin. Les entreprises peuventaussi prévoir les différents types de décisions à prendre lorsque certains scénarios se réalisentafin d’apporter une direction claire qui s’aligne sur les objectifs globaux.

Enfin, grâce aux processus et outils de la gouvernance SOA il est possible de conserver etd’optimiser le potentiel de SOA dans tous les scénarios possibles, comme par exemple laréutilisation des services partagés par les différents départements d’une organisation. Dans cecas la gouvernance permettrait de gérer les conflits éventuels pouvant survenir lors du partaged’un service par plusieurs clients, notamment lorsque l’on doit appliquer des mises à jourimportantes qui représentent toujours un danger pour les clients du service. D’autresprocessus et outils définis au niveau de la gouvernance permettraient d’accroître la visibilité

Introduction 10

sur l’infrastructure des TI et de mener une gestion en temps réel des services existants. Ainsitout changement effectué au niveau des processus métier peut être répliqué en configurant lesservices afin de les adapter aux nouvelles exigences, selon les politiques définies dans lesphases de développement et de maintenance.

1.2 Objectifs

L’objectif principal est de comprendre la vision qui sous-entend le paradigme SOA etd’approfondir dans les aspects théoriques et pratiques de la gouvernance. On aimerait aussiappliquer les connaissances acquises par l’étude de cas « e-dec ». Voici une description plusdétaillée des objectifs poursuivis dans ce travail :

1. Tout d’abord on aimerait aborder les fondements de l’architecture orientée services afinde comprendre ce que cela signifie du point de vue technologique et du marché d’affaires.Dans cette phase on présentera les différentes notions accompagnant SOA ainsi que lesavantages et désavantages qu’elle possède.

2. Une fois avoir posé les fondements de SOA, le second objectif est d’approfondir sur lesaspects théoriques et pratiques de la gouvernance SOA qui permet de répondre à laquestion « Comment les entreprises parviennent-elles à gérer l’architecture SOA avecefficacité ».

3. Le dernier objectif est d’implémenter la gouvernance SOA (Run-Time) dans le cadre del’étude de cas « e-dec ». Dans cette partie on aimerait proposer un prototype degouvernance pour le service web e-dec, notamment dans les domaines de la gestion depolitiques et des niveaux de services (SLA).

1.3 Structure

La manière dont ce travail est structuré obéit à l’idée de rendre son exposition facile et souple.Ce document est composé de trois parties :

1. la première partie, délimitée par le deuxième et troisième chapitres, est uneintroduction générale dans le domaine du développement orienté services et del’architecture SOA. Elle aborde les principes de la conception des services et lesbases conceptuels sur lesquelles repose SOA.

2. la deuxième partie, constituée du chapitre 4, traite les aspects théoriques de lagouvernance SOA qui doivent être maîtrisés pour mieux comprendre ce qui se cachederrière ce terme. Ce chapitre développe le sujet de la gouvernance SOA en suivantune approche séquentielle, c’est à dire, en s’intéressant tout d’abord à son origine,relation et place vis-à-vis des autres formes de gouvernance (entreprise, et TI).Ensuite, on présente la gouvernance SOA proprement dite, liée aux cycles de vie desservices.

Introduction 11

3. La troisième et dernière partie, composée des chapitres 5 et 6, est une section réservéeà l’étude de cas « e-dec » dont l’objectif est de faire le lien entre la théorie et lapratique. Elle décrit en premier en quoi consiste le projet et l’application « e-dec »,notamment la situation de départ qui a conduit l’AFD à changer d’approche pour sediriger vers une solution orientée service. Ensuite, on présente un survol desdifférents composants que constituent son architecture, en particulier les servicesjusqu’à maintenant déployés. Enfin, on aborde la proposition de gouvernance duservice web EdecImportService consistant, d’une part à implémenter à l’aide de deuxoutils SOA (passerelle applicative et un module de gestion) le SLA existant entre « e-dec » et ses clients. D’autre part, cette proposition définit certaines politiques deservices qui pourraient se révéler utiles dans la gestion du service EdecImportService.

12

2Les services

2.1 La notion de service

En général, le terme « service » est employé pour se référer à l’action de servir une personne,une idéologie ou une fonction spécifique dans le but de satisfaire une demande particulière.C’est un concept dont la signification varie en fonction du contexte dans lequel on l’utilise.Dans les relations humaines, il se réfère à une action qu’on accomplit pour le compte d’unetierce personne afin d’apporter un support ou une aide ponctuelle. Dans le contexteéconomique, les services représentent les différentes prestations qu’une entreprise met àdisposition de ses clients pour satisfaire leurs besoins. Les échanges opérés entre les deuxparties, entreprise et client, implique l’existence de certains accords et contrats traitant surcertains aspects importants comme la quantité et la qualité du service, la manière dont ildevrait être rendu ainsi que l’importance du service aux yeux d’un consommateur particulier.Par ailleurs, les services sont naturellement composés d’un ensemble d’activités reliées entreelles qui dans l’ensemble définissent son domaine de compétence. Par exemple, le service« clientèle » est souvent composé d’un système de gestion de la relation client, d’uneplateforme de support, d’un ou plusieurs canaux de distribution et d’un système de retour demarchandises.

Dans le contexte des solutions logicielles, le terme service a été utilisé pour désigner un typed’application qui s’exécute en arrière plan pour fournir un support système. C’est le cas desservices des systèmes d’exploitation de la famille Windows [Wikipedia-windows 2008,Windows services]. Cependant, les services sur lesquels SOA se base sont très différents desapplications traditionnelles car ils sont régis par des principes de base spécifiques auparadigme de développement orienté services. Avec SOA, le concept d’application, tel qu’onle connaît depuis longtemps, change radicalement pour laisser la place au concept decomposition de services ou aux applications composées [Erl 2007, p. 91]. En effet, il ne s’agitpas de construire une application spécifique pour chaque exigence métier qui vient d’êtreidentifiée mais plutôt de composer des nouvelles configurations de services permettant desatisfaire les besoins utilisateur. Donc, on peut dire qu’un service est un module logicielcontenant une interface publique affichant ses fonctionnalités, et une implémentation dont lesdétails ne sont pas connus des clients.

D’après le paradigme orienté service, on peut décomposer la logique d’un processus métier oud’une tâche en unités de traitement autonomes et réutilisables que l’on appelle services. Cesderniers contiennent un ensemble d’unités de travail ou de fonctionnalités bien définies,accompagnées d’un ensemble d’informations décrivant ce que le service est capable de faireainsi qu’un ensemble de règles pour gérer cette information [Brown 2007, p. 2]. A premièrevue cela ressemble à la définition d’un composant, tel qu’il est décrit dans l’orientation objet.

Les services 13

Mais en regardant de plus près on s’aperçoit qu’un service ne se limite pas à uneimplémentation et une interface uniquement sinon qu’il est constitué d’une structurebeaucoup plus complexe qui fait appel aux concepts de contrat [Erl 2007, p. 456] de service(plus large que celui d’interface), de messages et de collection de fonctionnalités. L’interfaced’un service expose la signature des fonctionnalités qu’il supporte au même temps que décritson emplacement et comportement global. Le contrat désigne aussi bien l’interface techniqueque la description métier concernant la qualité et le niveau de service exigé.

Dans le paradigme orienté objet on appelle message le flux de données que circule entre unobjet émetteur et un objet récepteur indépendamment de la manière dont ce message estréellement transmis. Cela veut dire que le terme message désigne un concept général plutôtqu’un format physique avec un en-tête, un corps de message et des attachements. Dans leparadigme orienté service, le terme messages désigne aussi bien un concept abstrait que leformat spécifique utilisé pour les échanges entre un service et son client. Il doit contenir, enplus des données elles-mêmes, des métadonnées décrivant le destinataire, des informationssur la sécurité et le protocole de communication.

Figure 1: Composants d’un service [Erl 2005, p. 296].

Lorsque l’on veut définir la notion de service on retrouve toujours la même idée de base quiest celle de collection de fonctionnalités ou de conteneur de comportement bien défini. Seréférer aux services comme une collection permet de dire qu’un service sert à exposer une ouplusieurs fonctionnalités reliées entre elles car appartiennent à un même domaine fonctionnel.L’image de containeur sert à illustrer le fort potentiel d’encapsulation de la logique sous-jacente ainsi que l’autonomie d’un service. Dans la Figure 1 on montre l’architecture d’unservice partitionnée en trois couches logiques, à savoir le service, les fonctionnalités et lesmessages. La couche du service représente le containeur de fonctionnalités et le contrat deservice. Les différentes fonctionnalités appartenant au même domaine fonctionnel utilisent lesmessages reçus en entrée et renvoient les messages résultants des traitements qu’elles sonteffectuées. Dans une implémentation spécifique, telle que celle des services web, on change le

Les services 14

terme de fonctionnalité par celui d’opération. Si l’implémentation du service est basée sur lemodèle de composants et d’objets, alors on appelle les fonctionnalités, des méthodes [Erl2007, p. 115].

2.2 Modèles de services

Le terme « service » est un concept général qui est utilisé pour se référer à toutes les formesde services existantes. En effet, il n’est pas rare de trouver dans une SOA une grande variétéde services placés à différents niveaux d’abstraction et ayant des caractéristiques particulièrespropres à une catégorie de service. Jusqu’à maintenant il n’y a pas de taxonomie de référencesur laquelle on s’appuie pour présenter les différents modèles de services, mais par contre, ontrouve dans la pratique un certain nombre de classifications permettant de connaître les typesde services, ainsi que les critères de choix qui les différencient. Dans [Erl 2007, p. 43] l’auteurprésente trois modèles de services, à savoir les services de support (utility services), lesservices métier centrés sur les entités (entity services) et les services métier centrés sur lestâches (task services). Par ailleurs, dans [Josuttis 2007, Chap. Service Classification] l’auteurclasse les services selon les trois catégories suivantes: services de base (basic services),services concertés ou composés (composed services) et services de processus (processservices).

Dans la plupart des cas, ces différents modèles sont équivalents et parfois identiques. Certainsservices métier, comme ceux centrés sur les entités, peuvent être assimilés aux services debase car ils encapsulent les fonctionnalités métier contenues dans les systèmes et applicationsexistantes (back-end). Les services métier centrés sur les tâches sont équivalents aux servicesconcertés qui se chargent de composer d’autres services dans l’exécution d’un sous-processusquelconque. Enfin, les services de processus sont ceux qu’implémentent la logique spécifiqueà un processus métier et servent aussi de contrôleurs.

Depuis une perspective plus globale, on peut dire qu’il existe trois catégories principales deservices qui se distinguent en fonction de trois critères principaux tels que, le potentiel deréutilisation du service, le modèle logique qu’il représente (métier, support, etc.) et ledomaine fonctionnel qui définit la portée de la logique sous-jacente. Dans le cadre de cetravail on a retenu les groupes suivants :

Les services de processus (process services),

Les services métier (business services),

Et les services d’application (application services).

Dans l’opinion personnelle de l’auteur de ce travail, l’utilisation de ces groupes permettraitd’identifier immédiatement la logique sous-jacente encapsulée dans chaque type de services.Les services de processus désigne les services utilisés pour implémenter les processus métieret faisant appel aux techniques d’orchestration. Les services métier pouvant exister à plusieursniveaux désignent aussi bien les sous-processus et les tâches que les entités métier. Lesservices d’application se réfèrent aux traitements de support technique et générique utilisés

Les services 15

par la plupart d’applications. Au même temps, ils désignent les fonctionnalités encapsuléesdans les services qui exposent les systèmes et applications légués.

Le Tableau 1 montre la combinaison des modèles de services trouvés dans la littératurementionnée ci-dessus. Il s’agit d’une liste des services que l’on assigne à chaque groupe envue de faciliter le transfert de connaissances, du domaine des applications traditionnelles audomaine des solutions orientées services où les termes métier et application sont déjà bienconnus.

La première colonne du tableau contient la liste des services considérés comme des servicesde processus car ils permettent de modéliser le flux de travail d’un processus en coordonnantl’interaction entre plusieurs services. Concrètement, il s’agit de modéliser un processusd’affaire en rassemblant plusieurs services en un seul flux de travail. Ce processus est connusous le nom de composition de services et concerne surtout les services de haut niveau tel queles services d’orchestration, contrôleurs, etc. Ces derniers interagissent avec des services ditsenfants (situés en-dessous d’eux) tels que, les services d’entité, afin exécuter le processusmétier qu’ils représentent. Dans ce contexte, les services de processus jouent le rôle de« Controller » car ils sont capables de gérer les différentes étapes nécessaires à l’exécutiond’un processus métier.

Tableau 1 : Catégories de services

Services de processus Services métier Services d’application

services composés services d’entité services wrapper

services d’orchestration services de tâches services de support

services contrôleurs service de traitement services d’infrastructure

services de données

Un service métier peut modéliser une tâche, une entité ou un traitement quelconque définitdans le cadre de certaines règles métier. Formellement on les appelle services de tâche (taskservices ou task-centric services) et services d’entité (entity services ou entity-centricservices) et services d’application. Comme son nom l’indique, les premiers contiennent lalogique métier permettant au consommateur du service d’exécuter une tâche correspondant àune étape déterminée d’un processus. Du fait qu’ils implémentent une tâche spécifique, leurpotentiel de réutilisation est réduit par rapport aux autres services. Une particularité de cesservices est qu’ils sont caractérisés par un contexte fonctionnel large concernant plusieursdomaines ou entités à la fois [Erl 2007, p. 45].

Les services d’entités représentent les entités métier d’une organisation ou d’une entreprise.Ils peuvent modéliser un client, un fournisseur ou n’importe quel autre concept qui fait partiedu modèle d’affaire. L’idée d’avoir un tel service est de concentrer le traitement métier àl’intérieur du contexte fonctionnel de l’entité qu’il représente. Si le service a besoin d’une

Les services 16

information supplémentaire, il l’obtient en échangeant des messages avec d’autres services.Cela permet de créer un service ayant un bon potentiel de réutilisation, plus élevé que celuitrouvé dans les services de tâches. Par contre, la portée fonctionnelle des services d’entités estlimitée au domaine de l’entité en question.

Les services d’application appartiennent à une catégorie de services de bas niveau quipermettent de développer des fonctionnalités centrées sur l’infrastructure et la technologiesous-jacente. On les appelle aussi des services d’infrastructure (infrastructure services) ouservices de technologie (technology services). En effet, ce modèle de service englobe unensemble de services dont la caractéristique principale est qu’ils sont indépendants de lalogique métier de haut niveau. Parmi ces services il y a les services d’accès aux données (dataservices), les services de support (utility services) et les services d’encapsulation de systèmesexistants ou systèmes légués (wrapper services). Bien qu’ils soient centrés sur la technologie,cela ne veut pas dire qu’ils ne sont pas réutilisables par les services de plus haut niveau. Eneffet, un service de support tel que le service de gestion de sécurité peut être utilisé parn’importe quel service métier afin d’effectuer l’identification et authentification desutilisateurs.

2.3 Caractéristiques des services

Indépendamment des différents types de services déjà mentionnés, un service possède unensemble de caractéristiques essentielles qui permettent de juger de son potentiel et intérêtconforme au paradigme « service-orientation ». Chaque caractéristique est associée à unprincipe de conception du développement orienté services.

Les services sont réutilisables

Le principe de réutilisation de service consiste à encourager le développement de servicesréutilisables en encapsulant la logique métier à un niveau assez générique pour qu’elle soitutilisée dans plusieurs contextes. Cependant, tous les services n’ont pas besoin d’avoir lemême degré de réutilisation. Il y a des services qui sont spécifiques à un processus d’affaireparticulier et dans ce cas ils ne sont pas réutilisables car les autres processus ne peuvent pasl’utiliser. Mais on trouve aussi des services que l’on appelle « agnostic services » qui ont unhaut degré de réutilisation car ils encapsulent une logique de traitement suffisammentgénérique pour être utilisés dans des contextes d’utilisation différents[Erl 2005, Chap.Common principles of service-orientation]. Leur contexte fonctionnel est adapté à plusieursconsommateurs de services qui peuvent s’en servir individuellement ou en accèsconcurrentiel.

Les services centrés sur les entités (entity-centric services) ont un fort potentiel deréutilisation. Par exemple, le service « produit » qui représente une entité d’affaire del’entreprise peut être utilisé dans les processus « Approvisionnement » et « livraison ». Lesservices de support (utility services) encapsulent les détails d’implémentation qui sont

Les services 17

communs à beaucoup de services et applications, et par conséquent, sont utilisés dansplusieurs scénarios différents.

Les services sans état

Les opérations ou les méthodes d’un service peuvent exécuter leurs traitements sans maintenirun état pendant une longue période [Erl 2007, p. 329]. Une fois que les opérations ont étéréalisées, le service ne retient pas les informations sur l’état des messages ou duconsommateur du service. Ce faisant, il peut rester disponible pour d’autres clients etsupporter la montée en charge (scalability) lorsqu’il y a plusieurs accès simultanés. Souventles données d’état sont stockées dans les messages qui peuvent contenir de la logique detraitement indépendante au service.

On doit distinguer entre l’état d’un service et l’information d’état que ce dernier pourraitcontenir. Dans le contexte de la composition de services, ces derniers peuvent passer entre lesétats, actif et passif, selon s’ils sont en exécution ou pas. Cela concerne plutôt l’état temporeldu service et n’est pas un principe de conception de l’orientation service.

Lorsque l’on dit que le service est sans état on se réfère plutôt au fait de manipuler, pendantl’exécution du service, les informations et les données spécifiques à la tâche concernée. Cessont des données contextuelles, des données de session, règles de validation, etc. Cependant,lorsqu’on considère les services de processus on s’aperçoit qu’ils représentent une exception àce principe car, contrairement aux autres modèles de services, ils doivent maintenir desinformations d’état pour gérer le déroulement du processus qu’ils implémentent. Un moteurd’orchestration leur permet de maintenir la trace des informations de session et de contexteainsi que de gérer le flux d’exécution (composition) pour que les services s’exécutent dansl’ordre définit.

Le contrat des services

Un contrat doit être décrit de manière appropriée pour permettre aux consommateurs de jugerde l’utilité du service et de connaître la manière dont il fonctionne. Pour ce faire, il estnécessaire de compter sur des descriptions normalisées des informations publiques du service.Donc, le contrat de service désigne un ensemble de documents permettant de décrire lesservices d’une manière détaillée et normalisée. C’est aussi un accord formel entre lefournisseur et le consommateur concernant l’utilisation du service. Dans [Erl 2007, p. 127] onle définit comment un ensemble de documents contenant:

- La description de chaque opération du service.

- Les types de messages tels que les messages en entrée, les messages générés commeréponse et les messages d’exception ou d’erreur.

- La description de chaque type de données contenue dans les messages.

- La localisation physique du service et les protocoles de communication.

- Les informations et règles sur l’exploitation du service. Par exemple, temps de réponse,temps pendant lequel le service doit être disponible, etc.

Les services 18

Dans le cas des services web, le contrat de service est représenté par plusieurs documents. Undocument de description appelé « WSDL document » qui contient une description centrée surles aspects techniques du service. Les documents XSD pour définir les structures de donnéesXML embarquées dans les messages. Les documents « policy description » utilisés pourdéfinir des règles de sécurité, des contraintes d’utilisation et les caractéristiques de qualité(QoS).

Autonomie des services

Pour qu’un service soit autonome il faut que la logique applicative contenue dans sesfonctionnalités soit délimitée par un contexte fonctionnel bien précis [Erl 2007, p. 72].Lorsque cela est possible, le service peut s’exécuter comme un module autonome qui contrôlele traitement métier qu’il expose ainsi que les ressources qu’il utilise.

L’autonomie des services peut être analysée depuis plusieurs perspectives. Pour lespropriétaires d’un service l’autonomie commence au moment de la conception de ce dernier.A ce niveau, l’autonomie veut dire que tant le service comme les consommateurs doiventpouvoir évoluer indépendamment l’un de l’autre [Brown 2007, p. 41]. C’est ce que l’auteurde [Erl 2007, p. 299] désigne comme étant l’autonomie de « Design-Time » qui consiste àgarantir une marge de liberté pour que tout au long de la durée de vie du service, lespropriétaires puissent réaliser les changements nécessaires. Ces changements concernent aussibien l’interface du service, les documents du contrat, le traitement métier encapsulé dans lesfonctionnalités, etc. En principe, ils doivent se faire sans affecter les consommateurs, cet àdire, sans besoin que les clients changent aussi sinon l’autonomie est mise en question.

L’autonomie au temps d’exécution (Runtime Autonomy) est une autre forme d’autonomie deservice [Erl 2007, p. 299]. Elle concerne le niveau de contrôle exercé par le service sur lalogique d’application, l’environnement d’exécution dans lequel il réside et les ressourcespartagées. Un service est complètement autonome lorsqu’il est déployé dans un containeurd’exécution qui lui dédié et dispose de toutes les ressources nécessaires comme s’il en était lepropriétaire. Cela ne veut pas dire que d’autres services ne peuvent pas accéder aux mêmesressources mais seulement lorsque celui-ci n’est pas actif.

Cependant, il y a d’autres niveaux d’autonomie qui sont tout aussi possibles. Par exemple,l’autonomie du traitement métier (Service Logic Autonomy) encapsulé dans le service qui seréfère à l’indépendance du service au niveau de son implémentation. Cette dernière est le seulélément du service qui n’est pas partagé tandis que les données, les connexions et d’autresressources sont accédées par d’autres services. Il existe aussi l’autonomie partagée (SharedAutonomy) qui a lieu lorsque l’implémentation du service est utilisée par des systèmes etapplications externes. Les services « wrappers » sont caractérisés par ce type d’autonomie carils encapsulent un traitement métier déjà existant que l’on invoque depuis d’autresapplications.

Enfin, la composition de service tend à rendre moins autonomes les contrôleurs et servicesintermédiaires car ils dépendent des membres de la composition pour réaliser leurs tâches [Erl2007, p. 298]. D’une certaine manière, une application composée crée des dépendances

Les services 19

d’utilisation qui transfèrent l’autonomie individuelle d’un service vers un niveau d’autonomiecollectif.

Composition de services

Beaucoup de systèmes et d’applications ont été développées selon le principe de composition.Dans le domaine des objets, on applique ce principe en créant des relations des types A-UN etCONTIENT-UN entre les classes. Concrètement, il s’agit d’un exercice d’assemblagependant lequel on cherche à créer une structure de classes constituée de plusieurs objets qui,dans un contexte d’utilisation particulier, se révèle être complémentaires. De cette façon, unobjet peut obtenir le comportement désiré sans forcement l’implémenter lui-même. A sontour, il peut être utilisé par d’autres clients en vue d’apporter ses propres fonctionnalités.

Dans le cas des services, la composition poursuit les mêmes objectifs que dans l’orientationobjet et se base sur la même idée d’assemblage ou agrégation mais en garantissant beaucoupplus de souplesse car les relations de propriété (A-UN et CONTIENT-UN) n’existent plus.Donc, les services ne jouent pas le rôle d’agrégat ou de composite mais plutôt de contrôleur.Ce dernier se charge de composer les services réutilisables qui vont devenir des membres oudes sous-contrôleurs de la composition. Il se trouve à la tête de la structure de composition àpartir de laquelle il invoque les autres services grâce à une relation d’utilisation des capacités(capability) où un service délègue à un autre la suite de la séquence d’exécution[Erl 2007, p.470].

A première vue on pourrait croire que la composition est réalisée à chaque fois que deuxservices interagissent. En effet, lorsqu’un consommateur utilise un ou plusieurs services qui àleur tour n’invoquent pas d’autres service, il n y a pas de composition. La même situation seproduit lorsqu’ il y a un seul niveau d’interaction entre les services (point-to-point). Enprincipe, on est en présence de la composition lorsqu’il y a au moins deux services, en plus ducontrôleur, engagés dans la séquence d’exécution concerné [Erl 2007, p. 406].

Faible couplage entre les services

Le développement orienté service met l’accent sur le couplage faible entre les services. Le butest d’avoir des pièces (les services) les plus indépendantes possibles pour faciliter l’évolutionfuture des applications. Pour ce faire, il est important que tant les consommateurs comme lesfournisseurs puissent évoluer indépendamment l’un de l’autre pour s’adapter auxchangements imposés par leur environnement respectifs, sans mettre en périll’interopérabilité.

Le contexte d’utilisation garantissant le plus faible niveau de couplage est celui où le serviceexpose ses fonctionnalités au travers d’un contrat ou d’une interface. Cependant, la simpleexistence d’un contrat ne garantit pas à lui seul l’indépendance entre les deux parties. Il fautque son contenu ne garde aucune relation avec les détails de fonctionnement, tels que latechnologie, l’implémentation des ressources (base de données, système de fichiers, systèmeslégués, etc.) et la logique sous-jacente. Si le contrat de service contient une dépendancequelconque envers un composant de son environnement il y aura un effet de transmission dedépendances qui couplera le consommateur au sous-système du service. Ce comportement

Les services 20

appelé « coupling inheritance » [Erl 2007, p. 186] décrit une relation étroite, définie en« Design-Time », entre le service et le consommateur malgré l’existence d’un contrat. Il s’agitde dépendances internes (contrat et implémentation du service) qui peuvent avoir lieu si l’onne fait pas attention à la manière dont on crée le contrat de service.

Une première variante susceptible d’aboutir au « coupling inheritance » est lié à la pratique degénérer certaines parties du service à partir d’un code ou d’un modèle physique existant. Eneffet, lorsqu’un contrat est construit automatiquement, à partir d’un code existant, au mêmetemps on court le risque de créer une dépendance depuis le contrat vers le code utilisé pourdériver ce contrat. Par exemple, en utilisant une interface et des classes Java pour générer lefichier de description WSDL on crée une relation étroite entre cette interface, le contrat et leschéma de données (spécifique au service en question). Le problème du couplage est iciévident car à chaque fois que l’implémentation change on devra aussi changer (régénérer) lefichier WSDL pour qu’il corresponde avec la version actuelle du service. Les types dedonnées définis dans les classes Java peuvent aussi poser des problèmes d’interopérabilité,surtout lorsqu’ils sont trop complexes ou spécifiques au langage (objets POJO, Entity Beanset Object)1.

Dans la Figure 2 on présente deux exemples de « coupling inheritance » dans lesquels on créele contrat à partir d’un code existant. Le premier (à gauche) correspond à l’exemple décrit ci-dessus où le contrat est généré à partir des classes et interfaces du service. Le deuxième (àdroite) montre un autre contrat généré automatiquement dont le code du service est aussi liéaux ressources qu’il utilise. Autrement dit, le code du service étant lié aux ressources(fichiers, base de données, etc.) lorsqu’on génère le contrat on risque d’y inclure certainescaractéristiques propriétaires. Un exemple typique est celui de schémas XML générés à partirde modèles de données physiques comme le modèle de tables relationnelles[Erl 2007, p. 178].Dans les deux cas, le consommateur hérite, via le contrat, les relations de dépendance avec lecode du service et avec les ressources externes.

Figure 2: A gauche, le client est couplé à la logique du service. A droite, il est couplé aux ressources du

service [Erl 2007, p. 188].

1 Il n’est pas toujours possible de faire un mapping entre les types spécifiques à un langage et les types dedonnés standards des schémas XML.

Les services 21

Une autre variante plus évidente menant à ce type de couplage est celle où l’on utilise unesolution propriétaire pour implémenter un service. Dans ce cas on peut espérer que le contratcontient quelques éléments propriétaires et non standards, comme par exemple un protocolede communication propriétaire qui imposera le même choix aux consommateurs du service.Ici aussi le consommateur hérite, via le contrat, les relations de couplage avec le service.

Figure 3: Client avec couplage fonctionnelle hérité d’une dépendance de même type entre le service et une

logique externe [Erl 2007, p. 188].

Enfin, une dernière variante où un contrat peut apparaître comme fortement couplé est cellemontrée dans la Figure 3. Il s’agit d’un service dont le code est étroitement lié à un processusmétier ou un autre service, comme c’est le cas des services implémentés pour supporter unservice spécifique, et que le contrat est à son tour lié au code de service. Comme on l’a déjàvu dans la première variante, le contrat peut être couplé au service soit parce qu’il estdéterminé en fonction du code, soit parce que ce code est déjà couplé aux ressources externeset il est utilisé pour générer le contrat. Donc, la dépendance fonctionnelle du contrat enversune logique externe est transférée au consommateur.

Découvrir et localiser les services

Le contrat de service est la pièce principale qui permet de découvrir et de localiser un service.Il contient les métadonnées techniques concernant la localisation physique et les capacitésfonctionnelles du service. Ce faisant, les propriétaires, tels que les architectes et lesdéveloppeurs, cherchent les services dont ils sont besoin avant de les développer eux-mêmes.S’ils existent, on peut évaluer leur niveau de conformité au nouveau besoin et les réutiliserpour ne pas redévelopper une ressource qui existe déjà, ainsi on évite d’ajouter un service ouun logique métier redondant. S’ils n’existent pas, les développeurs peuvent développer desnouveaux services selon les exigences identifiées. C’est pourquoi il est important que lors dela phase de conception (Design-Time), le service soit décrit d’une manière précise dans lesdocuments qui forment son contrat. A ce stade, on doit répondre aux questions telles que :

1. Les fonctionnalités dont on a besoin existent-elles ?

2. Doivent-elles être développées ?

Les services 22

La découverte de service n’a pas seulement des avantages sur l’administration des services.Les consommateurs utilisent les mécanismes de découverte pour localiser les services d’unemanière transparente, sans qu’il y ait besoin de connaître les détails physiques de salocalisation. Ils peuvent juger de l’utilité du service avant de s’en servir et même jouer laconcurrence en se basant sur des informations touchant à la qualité du service.

En résumé, la découverte de services se base sur la possibilité de définir d’une manière claireet précise, les informations descriptives (méta information) des services. Elles concernent leservice lui-même, l’infrastructure de communication, les politiques et règles d’utilisation, lescritères de recherche, etc.

L’abstraction des services

L’abstraction est étroitement liée à l’utilisation des services de la part des ses clientspotentiels. En effet, un service met à disposition des consommateurs un ensembled’informations publiques qui sont importantes pour son exploitation. Ces informationsprésentées sous forme de contrats sont l’interface entre le service et ses clients permettant demettre en place un mécanisme d’utilisation, simple et transparent, des différentesfonctionnalités. Pour les consommateurs et les propriétaires l’abstraction représente une vueexterne du service qui est facile à comprendre et à utiliser. Elle empêche aux applications etpersonnes d’accéder directement à l’implémentation des services.

La simplicité est l’un des objectifs poursuivit par le principe d’abstraction. Tandis quel’encapsulation cache les détails d’implémentation d’un service, l’abstraction montre lesinformations essentielles nécessaires pour bien comprendre le service, tout en excluant cellesqui ne sont pas pertinentes. Publier un service avec toutes les informations qui contient sesfonctionnalités rend complexe son exploitation et tend à coupler fortement sesconsommateurs. Par exemple, en publiant les détails de communication, comme l’adressephysique, les consommateurs seront obligés d’accéder directement aux fonctionnalités duservice, ce qui crée une dépendance entre eux. Par contre, si l’on fait correspondre cetteadresse à un nom quelconque (URI), les consommateurs auront toujours accès au serviceindépendamment de la situation physique de ce dernier. Donc, le service est libre de changerd’emplacement tout en restant disponible.

A l’instar de l’encapsulation, l’abstraction est aussi une manière de cacher les détailsd’implémentation mais en se focalisant sur les aspects publics d’un service. En principe,l’abstraction peut s’appliquer aux types d’informations suivantes :

Les informations techniques (protocoles de communication, format de messages, etc.)

Les informations fonctionnelles (fonctionnalités du service, format des fonctionnalités,types de données, etc.)

Les informations d’administration telles que les règles d’utilisation, aspects de qualité,etc.

Le fait de ne montrer aux clients que les informations essentielles implique que l’on cachecelles qui ne le sont pas. Les détails techniques sur le langage de programmation dans lequel

Les services 23

est écrit l’implémentation ainsi que l’infrastructure de communication sont des informationsqui devront être cachées à l’extérieur car elles ne concernent que le développement et lamaintenance du service. Autrement dit, le contrat de service doit être clair et précis mais sansaborder les détails superflus des informations qu’il contient car, comme déjà dit, le risque decoupler le client est élevé.

2.4 Les rôles

Les services peuvent être classés selon le rôle qu’ils jouent en relation avec d’autres sources etservices. Parfois la frontière de certains de ces rôles n’est pas définie clairement car toutdépend du contexte d’utilisation à partir duquel on décrit le service. Mais ce qui est certainc’est qu’un service peut jouer plusieurs rôles à la fois, montrant ainsi leur flexibilité. Ces rôlessont:

Fournisseur de service : En principe, un service est toujours un fournisseur car ilcontient des fonctionnalités qui peuvent être invoquées depuis une source quelconquecapable de communiquer via des messages. Généralement, un fournisseur se trouve endehors du système qui l’a invoqué. Pour satisfaire la requête qui lui a été envoyé, leservice traite le message entrant et exécute le traitement demandé.

Consommateur de service : Ce rôle peut être assumé par un service ou une applicationutilisant une plateforme de communication basée sur les messages. Généralement, unconsommateur se trouve en dehors du système du fournisseur de service. Donc, il doitêtre capable de le localiser pour pouvoir utiliser le service.

Intermédiaires : Entre un fournisseur et un consommateur on peut trouver un serviceintermédiaire chargé d’effecteur des traitements supplémentaires avant que le messagede requête ne parvienne au consommateur du service. Si le service intermédiaire selimite au routage du message, on parle d’intermédiaire passif [Erl 2005, p. 119].

Contrôleur de service : Lorsque les services implémentent un même processusd’affaires ou sont reliées dans une séquence d’exécution permettant d’accomplir unetâche déterminée, on est en présence d’une composition de services. Le service de plushaut niveau gérant la composition dans son ensemble joue le rôle de contrôleur. Lesautres services de niveaux intermédiaires jouent le rôle de sous-contrôleurs.

Pour éviter des confusions dans le rôle des services, il est important de savoir que cesdescriptions englobent une certaine flexibilité. Par exemple, dans le contexte de lacomposition de services un contrôleur peut être considéré comme étant un consommateur caril utilise d’autres services. Par contre, l’inverse n’est pas toujours vrai car le consommateurpeut être un programme externe qui n’est pas un service. Au même temps, un sous-contrôleurpeut être vu comme un fournisseur s’il est appelé par un membre de la composition dans laséquence d’exécution.

Dans le contexte de ce travail, on préfère utiliser l’analogie avec le modèle client-serveur [Erl2005, p. 119] pour dire que les rôles, fournisseur, consommateur et intermédiaire, sont

Les services 24

attribués aux services et applications qui existent dans des couches ou systèmes différents.Pendant que les contrôleurs et sous-contrôleurs sont uniquement réservés au contexte decomposition des services.

2.5 Spécifications et technologies

Tous les concepts jusqu’ici présentés font partie du cadre théorique des services. Cependant,ils ne disent rien sur les spécifications qui ont permis de concrétiser les différents principes dece nouveau paradigme. La spécification la plus utilisée pour implémenter les solutionsorientées services est celle des services web. Ces derniers représentent une nouvellegénération d’applications qui s’appuient sur un ensemble de standards et protocoles ouvertspour permettre une vraie interopérabilité entre les applications.

Lorsque l’on analyse la spécification des WS on se rend compte que cette technologie possèdetous les éléments nécessaires pour implémenter une solution orientée services. Lescaractéristiques des services, tels qu’elles sont définis par l’orientation service, sont pour laplupart supportées par les WS. C’est le cas par exemple pour la localisation et découverte desservices, les contrats, la composition, le faible couplage et l’autonomie.

Figure 4: Spécifications des Services Web [Abou khaled and Mugellini 2007, p. 15].

Comme on peut le constater dans la Figure 4, la pile de la spécification des WS est composéedes couches de protocoles : enregistrement et découverte, description de services et la couchede messages. La première couche de cette spécification supporte très bien le principe dedécouverte et localisation de services. En effet, une fois qu’on a développé un service il fautque celui-ci soit accessible, via le Web, aux applications qu’aimeraient l’utiliser. Pour cefaire, on l’enregistre dans un annuaire basé sur un ensemble de structures de données

Les services 25

standards et dont l’accès se fait par l’intermédiaire de protocoles universels, compréhensiblespar toutes les applications.

La deuxième couche, à savoir celle de la description de service offre tous les élémentsnécessaires pour que les WS puissent compter sur des interfaces publiques auto-descriptives.Les contrats des WS, qui représentent ces interfaces, permettent de décrire les fonctionnalitésmises à disposition par le WS. On doit y décrire toutes les opérations, les paramètres d’entréeet sortie de chaque opération, la localisation du service, le protocole de communication, lesaspects de sécurité, etc. Les contrats des WS représentent un moyen concret de supprimer lesdépendances entre les services, et par conséquence sont propice pour garantir le faiblecouplage.

La troisième couche fournit un mécanisme efficace pour que les services puissent échangerdes messages entre eux. Un WS supporte plusieurs patterns de messages, comme lesmessages à une seule direction (one-way) et les messages requête-réponse(Request/Response).

Pour la couche d’enregistrement et découverte des services ce sont les annuaires UDDI quipermettent de publier un service d’une façon standard pour que les clients potentiels puissentles découvrir et les utiliser. Pour ce faire, UDDI permet de stocker la description exacte dufournisseur associée aux informations d’un ou plusieurs partenaires consommateurs oufournisseurs de service. Chaque entreprise de l’annuaire contient un ou plusieurs servicesqu’elle a décidé de publier. Les informations concernant un service sont reparties en deuxstructures de données qui sont réservées pour contenir les détails techniques tels que, l’URLpour l’accès réseau, une référence vers l’implémentation du service, etc. Pour être plus précis,UDDI permet d’associer aux services des données d’identification ainsi que les documentsWSDL et SOAP, contenant la description de l’interface et le protocole de messagesrespectivement. De cette façon, UDDI garanti la possibilité de chercher un service selon desdiverses critères tels que, le type de fournisseur, sa zone géographique ou l’entreprisepropriétaire du service.

Figure 5: Structures de données de la spécification UDDI.

Les services 26

Comme on l’a déjà mentionné dans la section 2.3, le contrat de service est le documentqu’assure la description des services. Dans le contexte des WS, on s’appuie sur le langageWSDL (langage basé sur XML) pour implémenter cette description dans un formatinterprétable, aussi bien par les fournisseurs que par les consommateurs. Un document WSDLest constitué de quatre éléments répartis sur deux niveaux de description, un abstrait et l’autreconcret. Dans la description abstraite, il y a l’élément type qui contient la définition desdonnées simples et complexes qui sont utilisés dans les messages. L’élément message permetde définir les messages utilisés par le WS grâce aux informations sur le mode de messagesupporté, les données contenues dans le message ainsi que quelques informations sur leprotocole de message SOAP et les erreurs liés aux messages. Le troisième élément est celuiqui contient l’ensemble d’opérations supportées par le service, il porte le nom de portType. Cedernier défini l’interface abstraite du service web qui consiste en un ensemble d’opérations etdes paramètres respectifs d’entrée et sortie. Le niveau de description concret contient unélément nommé service qui est utilisé pour définir les ports par lesquels il est possibled’accéder au service. Chaque port, ici déclaré, doit contenir une URL pointant versl’emplacement physique du service.

Figure 6: Messages SOAP et des contrats WSDL [Abou khaled and Mugellini 2007, p. 29 and p. 45].

La technologie qui correspond à la couche de messages est représentée par le protocole demessage SOAP. Le format des messages définis par SOAP est très simple. Il y a d’abord unepremière partie appelée Envelope représentant l’enveloppe du message. Sa fonction premièreest de servir de containeur pour le corps du message mais il constitue aussi un moyend’indiquer le début et la fin d’un message. Il contient l’élément Header, définit commeoptionnel, où se trouvent les instructions de traitement, les informations de sécurité et lesdonnées de routage. L’élément Body est obligatoire et fait aussi partie de l’élémentEnveloppe. C’est ici où l’on trouve le contenu du message, comme par exemple, la valeur de

Les services 27

retour d’une opération ainsi qu’une description générale de cette opération. Si le service doitajouter un contenu quelconque, il peut le faire en se servant des éléments Attachment qui estdéfinis comme des parties optionnelles du message. Les messages SOAP sont transportablesde différentes manières. La plus connue est celle qu’utilise le protocole HTTP mais il est aussipossible d’envoyer un message via SMTP (Simple Mail Transfert Protocol) et FTP (FileTransfert Protocol). Les messages SOAP sont de documents XML validés ce qui permetd’éviter certaines erreurs de syntaxe.

28

3Architecture orientée services

3.1 L’évolution de SOA

L’architecture orientée services fait son apparition afin de résoudre certains inconvénientsposés par les approches architecturales qui l’ont précédé. Afin de décrire la manière dont SOAs’est installée, l’auteur présente d’une manière générale les deux visions qui ont guidé ledéveloppement d’applications précédant SOA.

Pendant longtemps les entreprises ont soutenu leurs activités en s’appuyant sur des systèmeset applications spécifiques à une fonction (achats, finances, etc.) particulière. Dans cetteconfiguration l’ensemble d’applications est développé, ou acheté, pour répondre aux besoinset exigences actuels tout en veillant à rendre facile leur évolution future. A chaque applicationcorrespond un projet de développement qu’en principe n’a pas de liens avec d’autres projetsde même type. En simplifiant on peut dire qu’à chaque spécification métier correspond unenouvelle application ou une extension de celle déjà existante. C’est ce que [Laudon andLaudon 2001, p. 737] appelle une vision par application du développement de systèmesd’entreprises.

Dans le court terme, cette approche s’est révélée très efficace car elle a permis d’identifier desbesoins urgents et de fournir une solution immédiate. Cependant, dans le long terme, au fur età mesure du développement de l’entreprise, certains inconvénients commencent à semanifester. L’entreprise peut se retrouver avec un nombre croissant de systèmes etapplications disparates qui sont difficiles à gérer et empêchent l’interopérabilité. D’ailleurs,pour un employé, le fait de disposer d’un nombre important d’applications, peut alourdir sacharge de travail au lieu de l’alléger. Au niveau des processus d’affaires, ceux-ci secaractérisent pour être rigides et difficiles à modifier car ils tendent à être fortement couplésaux solutions logicielles qui les implémentent.

L’illustration de gauche de la Figure 7 montre l’architecture globale d’une entreprise qui sebase sur cette vision. Le niveau « Fonctions » contient les différentes fonctions que l’ontrouve dans une entreprise, à savoir finance, comptabilité, production, etc. En dessous decelles-ci il y a les processus métier ainsi que les systèmes de gestion correspondants. Lesprocessus sont spécifiques à un domaine fonctionnel et chaque système supporte l’ensembledes processus d’affaires d’une fonction particulière. Comment on peut le constater, il n y apas d’environnement commun entre les différents systèmes de gestion car l’interopérabilitéest rarement possible. Si l’exécution d’un processus métier demande l’enchaînement deplusieurs applications, l’utilisateur n’a pas d’autres choix que de disposer d’une boîte à outilslogiciel complexe qui peut être difficile à gérer. Il doit maîtriser des informationssupplémentaires comme l’emplacement de chaque application et l’ordre logique dans lequel il

Architecture orientée services 29

peut les utiliser. Sur le plan du développement, il est sûr que l’on multiplie les fonctionnalitésredondantes, ce qui représente un gaspillage de ressources et un retour sur investissementfaible.

Figure 7: Vision par application et vision intégrée.

Bien que le sujet de l’intégration de systèmes soit un domaine à part entière, il représente unpas important dans l’évolution de SOA. En effet, pour remédier aux inconvénients soulignésauparavant, les entreprises ont réfléchit à la possibilité d’intégrer leurs systèmes. Cela apermis de passer d’une vision par application à une vision intégrée des ressources, ce qui veutdire que l’on a reconsidéré les processus d’affaires à échelle de l’entreprise et ne plus àl’échelle d’une seule fonction. Pour soutenir cette approche, les systèmes disparates ontimplémenté des interfaces pour favoriser le flux d’informations à différents niveaux etfonctions. Dans la Figure 7, l’illustration de droite montre une vue intégrée de l’entreprise. Leniveau des processus n’est plus vertical mais horizontale montrant leur transversalité. Chaqueprocessus est implémenté par une ou plusieurs applications qui communiquent entre elles viades interfaces ou de middleware spécifiques.

Malgré les améliorations apportées par l’approche d’intégration d’application, les solutionsainsi obtenues sont complexes et représentent une dépense financière importante. En plus, ladiversité des plateformes dans la couche de systèmes tend à créer de nombreuses contraintestechniques et de sécurité. Quant aux processus d’affaires, ils sont restés fortement couplés auxapplications, ce qui tend à ralentir l’entreprise face aux changements internes et externes.Heureusement, SOA va au-delà de la vision intégrée de l’entreprise et amène une nouvellevue sur l’ensemble des ressources d’une organisation. C’est une vision focalisée sur lesaffaires qui permet de découpler les processus de la couche de systèmes afin de doterl’entreprise d’une indépendance total vis-à-vis des applications. Ce faisant, il est possible dedévelopper les stratégies d’affaire en sachant que l’on dispose d’une architecture IT flexible,capable d’évoluer au rythme des changements et exigences nouvelles. SOA introduit aussiune couche de services entre le niveau de processus et celui des applications. Ces services


sont conçus et développés conforme aux principes de l’orientation service présentés dans lechapitre 2, à savoir autonomie, abstraction, contrats de service, etc.

Figure 8: Découplage entre les processus et les applications.

La Figure 8 et la Figure 9 montrent les prochaines étapes dans l’évolution de l’architectured’entreprise. La première figure illustre la nécessité de supprimer le couplage direct qui existeentre les processus et les systèmes afin de rendre l’architecture plus flexible. Chaque couplagefort est éliminé pour faire de la place à une couche de services SOA capable de garantir lefaible couplage et de diminuer les nombreuses connections (relations) créées avec l’approchepar application. Dans la deuxième figure on montre une représentation logique de cettecouche de service qui contient l’ensemble des modèles de services jusqu’ici décrits. En effet,ce sont les services de haut niveau qui supportent directement les différents processusd’affaire pendant que les services de bas niveau encapsulent le comportement d’uneapplication particulière. Il est intéressant de noter que tous les services résident dans unemême couche (représentation logique) car, à différence des applications, ils sontintrinsèquement interopérables grâce à l’utilisation des standards. Cette couche communemontre aussi la vision fédérée que SOA porte sur les ressources de l’entreprise afin de mieuxles coordonner.


Figure 9: Une vue d'ensemble sur l'architecture SOA.

SOA est une architecture orientée service parce qu’elle permet de substituer les applicationstraditionnelles par des modules logiciels appelés services. Une telle substitution ne se fait pasen supprimant les applications qui existent déjà sinon en encapsulant leurs fonctionnalitésdans une couche de service. Toutes les fonctionnalités conservant un certain lien fonctionnelsont collectées dans un même service. Par exemple, si les systèmes « gestion des achats » et« gestion de commandes » ont tous les deux une fonctionnalité « getProduit », celle-cin’existe qu’une seule fois dans la couche de service.

3.2 Les couches d’application, métier et de processus

La couche de services « glissée» entre les couches d’applications et de processus métier peutêtre conçue de différentes manières. Au début de l’adoption de SOA, cette couche peutcontenir un nombre limité de services, souvent dédié à exposer les fonctionnalités desapplications résidantes dans la couche de systèmes. Au fur et à mesure de la maturité de SOAon ajoute des nouveaux services, ce qui fait que la couche de service devient de plus en pluscomplexe. Pour mieux gérer cette complexité, les architectes et les développeurs partitionnentla couche de service en plusieurs couches qui reflètent les modèles de services présentés dansle chapitre Modèles de services, à savoir les services d’application, les services métier et lesservices de processus. Comme dans le cas des catégories des services, ces couches peuventêtre nommées et organisées autrement que comme elle sont illustrées dans la Figure 10 car enréalité tout dépend des exigences et stratégies spécifiques à chaque architecture.


Figure 10: Les différentes couches de services.

Dans ce modèle, SOA est constitué de trois couches de services (voir la section Modèles deservices) et d’un système d’annuaire contenant un référentiel de tous les services existants. Lacouche de services d’application est souvent implémentée en premier car elle permetd’exposer l’ensemble de fonctionnalités de la couche système que jusqu’ici a supportél’organisation. Ce faisant, il est possible de commencer avec SOA en emballant ce qui estdéjà disponible sans pour autant devoir développer des services (from scratch). Autrement dit,au lieu d’abandonner les applications existantes et de tout reprogrammer, on optimise lesapplications existantes en les exposants sous forme de services. En effet, cette couchereprésente un niveau d’abstraction de la couche de systèmes qu’encapsulent les détailspropres à chaque technologie et aux plateformes sous-jacentes. Par conséquence, chaqueservice entretient une relation simple (un-à-un) avec l’application qu’il représente car pardéfinition un service doit avoir un seul domaine fonctionnel bien défini. Le fait de cacher lesimplémentations propriétaires avec des technologies standards permet implicitementl’existence d’une couche d’intégration souple et évolutive. Dans ce cas, chaque systèmecompte sur un adaptateur ou wrapper servant d’interface vers les clients. Il sert aussid’intermédiaire entre les consommateurs et les fournisseurs de services, ce qui est un bonmoyen pour concrétiser le faible couplage.

La couche de services d’application peut contenir d’autres types de services à l’instar de ceuxproposés par la plupart de Framework d’applications. Principalement, cela concerne lesservices de support et d’infrastructure chargés de gérer des opérations communes à toutes lesapplications comme les services de logging qui permettent de tracer les sessions d’unutilisateur et les services de gestion d’exception offrant un mécanisme de contrôle des


exceptions [Arch2Arch 2006b, p. 23]. Il y a aussi les services de données qui servent à écrireet à lire les données résidant dans le tiers de persistance d’une application externe. Dans laFigure 10 on montre deux instances de ce type de service donnant accès aux données desclients et des produits dans le contexte d’opérations de mise à jour. Selon [Josuttis 2007,Chap. Services Classification] les services d’application ne sont pas responsables d’éliminerles fonctionnalités en doublons et par conséquent il est tout à fait envisageable d’avoir deuxservices qui font la même chose mais pour le compte de systèmes distincts. Par exemple, leservice « consumer data » peut exister sous deux versions, une spécifique aux clients d’unsystème CRM et l’autre encapsulant les données des clients d’un système de gestion defactures.

La couche intermédiaire contient les services métier qui sont chargés de représenter les entitéset les traitements métier d’une organisation comme les clients, les produits et les fournisseurs.Cette couche offre les fonctionnalités de type CRUD (create, read, update, delete) exécutéesdans le contexte d’un domaine métier spécifique. En plus, il est aussi possible de placer desservices à granularité plus importante comme les services de traitement qui renvoient desréponses dynamiques générées en fonction de la requête reçue.

Les services d’entités répondent à une stratégie de conception dont le but serait d’éliminer lesdoublons identifiés dans la couche d’application. Pour ce faire, il suffit de collectionner dansun service les différentes fonctionnalités en doublons pour les exposer dans un contextefonctionnel bien défini. Par exemple, si dans la couche d’application on a identifié deuxservices « consumer data », il est possible de disposer d’un seul service d’entité « consumer »contenant les opérations d’un client. De cette façon, le service est réutilisable aussi bien poureffectuer les opérations sur le CRM que sur le système de gestion de factures.

Les services de gestion de commandes, gestion des clients et gestion d’achats de la Figure 10contiennent la logique de traitement nécessaire à l’exécution automatique d’une tâche. Parexemple, le service de gestion de commandes permettrait à une application de passer lescommandes d’un client et d’enregistrer les données les plus importantes. Pour ce faire, ellecompose les services d’entités « produit » et « client » mais il doit aussi exposer desopérations, telle que « commander ». Par contre, le service de gestion de clients utilise lesservices d’entités « fournisseur » et « produit ». Dans le cas du premier, on voit (Figure 10)que les opérations sont dérivées d’un adaptateur J2EE qui permet d’accéder aux données desfournisseurs2.

En plus des deux niveaux déjà mentionnés, SOA permet la mis en place d’une couchesupplémentaire contenant les services de processus. Comme son l’indique, il s’agit d’unensemble de services encapsulant le flux de travail des processus métier pour que ces dernierspuissent s’exécuter d’une manière automatisée. Un service de ce type aura toujours unecontrepartie sous forme de processus métier géré au niveau des processus de l’organisation.En effet, les analystes fonctionnels construisent des modèles de processus à l’aide des outilsBPM (Business Process Modeling) qui permettent de capturer les différents processus métier.Une fois modélisés, ils peuvent être développés et testés selon des règles prédéfinies qui sont

2 Il peut s’agir d’un adaptateur vers le système de fournisseurs même.


spécifiques au métier concerné. Ensuite, les processus sont contrôlés via les fonctionnalitésd’analyse et de monitoring en temps réel permettant d’identifier les problèmes potentiels quipourraient survenir. La Figure 11 montre un processus modélisé à l’aide de la notation BPMN(Business Process Modeling Notation).

Figure 11: Exemple d’un diagramme BPMN [Josuttis 2007, Chap. Business Process Modeling].

Un concept important lié à la couche des services de processus est celui de l’orchestration.Généralement, les modèles de processus sont constitués d’une séquence d’opérationsexécutées par une ou plusieurs départements d’une organisation. Pour qu’un service puissentles implémenter correctement ils font appel à d’autres services plus spécialisés et réutilisablesqu’ils composent dans séquence de traitement logique. Ce faisant, les services de processusdoivent contrôler le flux de travail pour déterminer l’ordre des opérations que chaqueparticipant est tenu de respecter. Donc, un service de processus peut être vu comme un « chefd’orchestre » qui est chargé de diriger l’exécution d’une composition de services. Dans laFigure 10, on peut voir deux instances de services de processus qui implémentent lesprocessus métier « approvisionnement » et « ventes ». Afin d’accomplir ses tâches, le serviced’approvisionnement compose deux services de la couche métier, à savoir « gestion decommandes » et « gestion d’achats » qui permettent de tirer des informations centrales tellesque les produits à réapprovisionner et les fournisseurs respectifs. Pour le service de vente leprincipe est le même car il se sert de la couche métier pour exécuter la séquence d’opérationsdont il est constitué.


3.2.1 Les outils de registre et référentiel de services

La concrétisation des principes de conception de services ne doit pas uniquement se focalisersur le développement des services eux-mêmes. Elle doit passer aussi par la disponibilité demécanismes de support capables d’implémenter ces mêmes principes mais d’une manière plusglobale. Comme il a été dit auparavant, les principes, tels que la découverte et localisation deservices, le couplage faible et la réutilisation sont implémentés grâce au développement d’uncontrat qui décrit toutes les informations pertinentes d’un service. Cependant, cela nereprésente que la moitié de ce qui doit être fait pour qu’un service soit vraiment accessible,faiblement couplé et réutilisable. L’autre partie est complétée grâce aux systèmes de gestionde services qui sont le Registre et le Référentiel de services.

Le premier composant, à savoir le registre de services, a été déjà abordé lorsque l’on aprésenté la spécification UDDI dans la section concernant les services web. Cependant, lafrontière entre registre et référentiel n’est pas tout à fait claire ce qui parfois fait croire qu’ils’agit de deux termes équivalents. Mais en réalité, il s’agit de deux composants distinctsgérant le même type d’entité (les services) mais sous deux angles différents. Le registre gèreles services du point de vue technique tandis que le référentiel le fait du point de vue métier[Josuttis 2007, Chap. Repositories and Registries]. Dans le contexte de SOA, le registrereprésente le catalogue de services permettant aux fournisseurs de publier leurs services pourles rendre accessibles aux consommateurs. Cette accessibilité est aussi nécessaire pour lespropriétaires des services, comme les architectes, développeurs et analystes, qui doiventdisposer d’un système permettant de gérer les aspects techniques du cycle de vie des services.En général, un registre fournit une base de données respectant la spécification UDDI ainsiqu’un ensemble de fonctionnalités comme la classification, recherche et localisation deservice. Du point de vue des consommateurs et fournisseurs, le registre contribue à réduire ladépendance d’utilisation de sorte que tout changement dans l’implémentation d’un servicen’entraîne pas d’autres modifications au niveau des clients. Pour les propriétaires, le registreest un composant central qui permet de configurer les services au temps d’exécution, decontrôler les changements d’implémentation ainsi que d’en informer les parties concernées,de suivre l’évolution des services en mettant en place un mécanisme de gestion de version.Certains aspects concernant la qualité des services peuvent être gérés dans un registre, commepar exemple la sécurité et la disponibilité.

Parallèlement à l’utilisation des services, il y a toute la question concernant la gestion etgouvernance du cycle de vie des services. Un référentiel de service est le composant de SOApermettant aux gestionnaires et développeurs de gérer les services indépendamment de latechnologie. Pour ce faire, il permet de stocker la définition des services et processus métierainsi que leurs relations. Il offre aussi la possibilité de définir des règles et politiquesd’utilisation qui doivent être respectées par les consommateurs et fournisseurs. Le principe deréutilisabilité est largement implémenté par les référentiels car, grâce aux métadonnées qu’ilscontiennent, il est possible d’identifier des relations de dépendance entre les services, et dedéterminer si un service existe déjà et dans quelle mesure il satisfait le besoin que l’oncherche à supporter. De manière générale, on peut dire que le référentiel est la base dedonnées contenant tous les documents liés au cycle de vie, à savoir les définitions, les


modèles, les exigences métier, etc. Comme il est mentionné dans [Arch2Arch 2006b, p. 31]un référentiel de services doit fournir les fonctionnalités suivantes :

Publication et découverte de métadonnées.

Mécanisme sophistiqué de recherche par catégorie, description de services.

Synchronisation avec des données externes.

Gestion de droits d’utilisation des métadonnées.

Notification des changements appliqués aux métadonnées, etc.

Figure 12: Le registre publie les contrats de services qui sont consultés par les clients potentiels.

Un dernier point à souligner est que contrairement aux registres, les référentiels de services nesont pas obligatoires dans une architecture orientée services, d’au moins aux premières étapesde maturité de SOA. Cependant, lorsque le nombre de services augmente il devient de plus enplus nécessaire de mettre en place un référentiel pour soutenir le processus de gouvernance etle management de services [Arch2Arch 2006b, p. 32]. Cela veut dire que le référentiel estcomplètement indépendant de l’environnement d’exécution des services, ce qui n’est pas lecas pour le registre. Enfin, malgré les différences entre ces deux composants il n’est pas rarede trouver des solutions combinant plusieurs référentiels et registres dans un même produit.

37

4La gouvernance SOA

4.1 Introduction

Après avoir parcouru les concepts de base liés au développement orienté service et àl’architecture SOA en générale, on est mesure de développer le sujet central de ce travail quiest celui de la gouvernance SOA. En effet, les objectifs techniques et métier poursuivis parSOA ne peuvent pas être atteints sans avoir une structure de gouvernance propre à ce type deprojet. Le caractère hautement distribué de SOA, les promesses de faible couplage, lacomposition dynamique des services, ne sont que quelques exemples de la complexitéinhérente à SOA. Au niveau métier, les objectifs de souplesse et de flexibilité ne seront jamaisatteint si le cycle de vie des services n’est pas aligné avec sur les objectifs stratégiques del’entreprise.

En général, SOA est caractérisée par un ensemble de processus de conception, d’utilisation etde mise à jour de services qui sont difficile à concrétiser sans avoir une maitrise total desaspects de management et de gouvernance. En effet, la gouvernance SOA permet d’encadrerles différentes étapes de conception, d’utilisation et de mise à jour mentionnées ci-dessus, parla mise en place d’une structure de responsabilités visant à clarifier les rôles et les prises dedécisions de chaque partie prenante. Ensuite, chaque niveau de gouvernance (Design-Time,Run-Time and Change-Time) défini les politiques et les processus qui permettront de gérerl’ensemble des artefacts propres à chacune de ces étapes du cycle de vie des services. Lespolitiques, qui sont au cœur de la gouvernance SOA, vont capturer toutes les règles relatives àchaque événement déclenché par les utilisateurs, les services et tout autre artefact pour ensuitedicter les actions à prendre. On trouve plusieurs exemples concrets de gouvernance SOA dansdes domaines tels que la clarification de la stratégie SOA liée aux objectifs métiers del’entreprise. Les décisions relatives au Roadmap et à l’architecture de référence quipermettent de définir la vision future de SOA par rapport aux standards de données,d’infrastructure et métier qui guideront son développement. La création des principes de SOA(métier, application, données et technologies) qui est essentielle pour appuyer l’ensemble desdécisions sur des directives prédéfinies.

Comme on a pu le constater ci-dessus, le spectre de la gouvernance SOA est très large et peuttoucher presque chaque élément de SOA. C’est pourquoi on a décidé de traiter dans la suitede ce travail les étapes de gouvernance Design-Time et Run-Time qui sont celles qui sedifférencient les plus et peuvent apporter plus de compréhension à ce sujet. Bien que lagouvernance Change-Time ait ses propres particularités, comme la gestion des versions et lechoix des stratégies de mise à jour (big bang, évolutive, etc.), on peut considérer qu’elle esttoujours présente dans la gouvernance en Design-Time et Run-Time.

La gouvernance SOA 38

Pour ne rien laisser dans l’oublie on commencera cette partie par l’exposition des motivationsqui justifient l’existence d’un Framework de gouvernance dans le cadre de SOA, son origineet sa relation avec la gouvernance d’entreprise et TI. Il s’agit en effet d’un chapitre quiprésente la gouvernance SOA d’une manière très générale sans se focaliser sur aucun aspectparticulier. Ensuite, c'est-à-dire, dans les chapitres cinq et six on approfondira davantage surles questions de gouvernance Design-Time et Run-Time en essayant de présenter les différentssujets à l’aide des illustrations explicites pour montre en quoi consiste ces étapes. Enfin, lelecteur assistera à l’implémentation d’un prototype de gouvernance Run-Time qui seradéveloppé avec un outil professionnel utilisé dans le déploiement et de renforcement(enforcement) des politiques de gouvernance.

4.1.1 Les risques de SOA

Le premier défi imposé par SOA ne vient pas de l’approche elle-même mais de l’effet« changement » qui accompagne l’introduction des nouvelles technologies à l’échelle del’entreprise. Il est connu que les organisations possèdent des structures organisationnelles biendéfinies qui reflètent l’assignation des responsabilités auprès de son personnel. A chaqueniveau de cette structure on trouve des spécialistes qui ont leur propre agenda et qui ne sontpas forcement d’accord avec l’implantation d’une nouvelle architecture d’entreprise, surtouts’ils se voient affectés par de tels changements. Ce refus aux changements causé par lapolitique organisationnelle [Laudon and Laudon 2001, p. 98] d’une entreprise est unproblème connu qui surgit lorsqu’on veut modifier ou implanter un nouveau systèmed’information. Donc, SOA n’échappe pas à cette règle car elle introduit des nouveaux rôlesque, dans la plupart des cas, sont supportés par des nouvelles structures organisationnelles.Comme SOA est très liée à l’optimisation et automatisation des processus métier (SOAimplémente des processus métier) on peut espérer qu’elle impacte directement ouindirectement ces structures organisationnelles.

Un autre facteur de risque lié aux questions d’organisation est celui des méthodes dedéveloppement utilisé dans SOA. En effet, pour bien implémenter SOA et ses composantsindividuels on doit introduire une approche de développement différente de celle utiliséejusqu’à présent pour les applications orientées composants. Cette nouvelle approche devraitinclure les étapes de recherche et d’identification de services en vue de faciliter leurréutilisation et de raccourcir le temps de développement par rapport aux méthodestraditionnelles [Arch2Arch 2006c, p. 16]. Ces étapes sont essentielles pour optimiser lesinvestissements réalisés dans les TIs car elles permettent de s’assurer que l’on n’a pas desservices et fonctionnalités en doublons qui augmentent les coûts de production des services.

Au fur et à mesure que SOA se développe il peut s’avérer nécessaire d’ajouter des nouvellesressources à l’échelle de toute l’entreprise. Des ressources techniques telles que les moteursBPM, les ESB, les registres, et les référentiels qui sont nécessaires pour fournir un bonsupport aux nouveaux services mais aussi à ceux déjà déployés. Donc, ces composantstechniques doivent être intégrés dans l’infrastructure des TI suivant un plan d’exécution biendéfini. Dans ce cas, le risque est lié à l’éventuel couplage avec les solutions propriétaires desvendeurs comme Microsoft et Sun MicroSystems. Le plan d’exécution de la stratégie SOA


doit au moins mentionner l’obligation de disposer de produits basés sur les protocoles etstandards3 du marché afin de garantir l’interopérabilité avec les solutions existantes et futures.Un exemple concret est celui des APIs de type « wrapper ». Si ces derniers sont développés àl’aide de technologies propriétaires, c’est l’architecture globale qui se trouvera face à unecontrainte de compatibilité par rapport aux services qui viendront après. Même lorsqu’onprétend garantir l’interopérabilité en comptant sur les standards il peut arriver que les servicesne soient pas universellement accessibles. Cela veut dire que SOA devrait permettrel’existence de plusieurs canaux d’accès, tels que le courrier électronique et le web (HTTP,FTP, etc.) [Brown 2007, Chap. 4.2 Creating effective services]. Or, cela implique que l’ondoit prendre de décisions sur le nombre de standards de données que les services doiventsupporter tout en veillant à leur prolifération incontrôlée4.

Un autre risque lié aussi au cycle de vie de SOA (cycle de services inclus) est l’absence d’unmécanisme de partage des nombreux documents ou artefacts générés à la fin de chaque étapedu cycle de vie. Que ce soit sous la forme d’un système de registre ou d’un inventaire manuelde services, il est important de pouvoir publier les services ainsi que leurs documents. Cesderniers sont aussi importants que les services eux-mêmes car ils sont essentiels pour leurutilisation actuel et future [Brown 2007, p. 223]. Par conséquence, la négligence desdocuments affecte négativement la suite de l’ensemble du processus SOA.

Figure 13: Exemple des nombreux documents produits dans chaque étape du cycle de vie de services Cf.

[Arch2Arch 2006c, p. 8].

3 Service web (WS-Policy, WS-Security, etc.), UDDI, SOAP, HTTP, JMS, XML, POP3, SMTP.4 L’introduction d’un standard pourrait exiger des investissements en formation, acquisition de ressources

hardware, etc.


Aligner le TI avec les réglementations dictée par le haut management et l’environnement del’entreprise (lois, normes, etc.) est l’un de soucis de la gouvernance TI et SOA car à présentles technologies de l’information sont le moyen « par excellence » avec lequel les entrepriseréalisent la plupart de ses activités, inclus la gouvernance d’entreprise elle-même [Bloomberg2004]. Donc, il est important de disposer d’un cadre de procédures et de politiques qui dictentle comportement de SOA dans des scénarios comme l’intégration d’applications, l’échanged’information (interne et externe) et le commerce B2B. Comme pour le cas de la gouvernanced’entreprise, la gouvernance TI et SOA représentent un moyen de garantir la conformitélégale des actifs TI et de gérer ces derniers dans une perspective de rentabilité. La statistiquecitée dans l’article [Mitra 2005, The importance of IT and SOA governance] confirme cettetendance de la manière suivante :

« (…) firms with a well exercised IT governance have had 20 percent greater profitmargins than their counterparts who make very little or no investment in ITgovernance, (...)”

Figure 14: Conformité légale et stratégiques fait de la pression sur SOA.

La Figure 14 illustre un scénario de commerce B2B où chacun des partenaires utilisent uneSOA pour effectuer leurs transactions commerciales. Il s’agit d’une illustration basée sur laconformité légale et l’alignement stratégique qui permet de voir les nombreuses relations(flèches) présentant un certain intérêt pour la gouvernance. Aussi bien les plateformes SOAcomme les niveaux métier sont tous les deux soumis aux contraintes de conformité provenantde l’extérieur de l’entreprise. Cependant, SOA est encore exposée aux différentes exigencesinternes qui dictent (SOA guidée par le business) comment elle doit être implémentée poursupporter correctement les affaires d’une organisation. C’est pourquoi on a représenté lesdeux architectures avec des formes différentes, rectangulaires et ovales, car cela permet demontrer l’influence de certains aspects de conformité sur le comportement de SOA.


Mis à part les aspects de conformité, toute implémentation de SOA doit surmonter les défisconcernant la sécurité des systèmes d’information, à savoir l’authentification, l’autorisation,l’intégrité et la confidentialité dans un environnement flexible et hautement distribué. Eneffet, lorsqu’on entend dire que SOA permet d’implémenter une architecture agile et flexibleon ne mentionne jamais les contraintes de sécurité inhérentes à l’interaction entre deux ouplusieurs services. En principe pour qu’un service puisse être utilisé de manière sécurisée ilfaut qu’on puisse compter sur des mécanismes d’identification permettant d’authentifier unclient ou un consommateur. Il faut aussi que les droits d’accès aient été identifiés pourgarantir que le client utilise les ressources dont il a vraiment le droit de manipuler. Lesinformations échangées par les services doivent aussi être protégées contre la modification etl’interception de messages qui pourraient survenir d’une tierce partie.

Dans un environnement faiblement couplé, tel que celui promue par SOA, certains modèlesde sécurité traditionnels, notamment l’embarquement de la logique de sécurité dansl’implémentation du service, ne sont pas recommandés car il faut que les services restentautonomes (portables) et réutilisables partout ils seront déployés, sans recourir à deschangements couteux. A cela s’ajoutent les contraintes d’interopérabilité des services qui estbasé sur l’utilisation exhaustive des standards industriels à tous les niveaux de collaborationpossibles (EDI, EAI, B2B, etc.). Alors, on peut se poser la question suivante :

Comment faire pour que SOA reste flexible et agile lorsqu’on se trouve dans uncontexte d’intégration tel que celui du Supply Chain Management où les partenairesont des domaines de sécurité spécifiques ?

Figure 15: Faible couplage implémenté par les services web [Pulier and Taylor 2006, p. 78].

Comme on peut le constater dans la Figure 15 on a une architecture de service complètementflexible qui permet à plusieurs entreprises de location de voitures de rester informées sur leshoraires d’une compagnie aérienne. Pour ce faire, les différents systèmes communiquent à


l’aide de la technologie des services web (voir Spécifications et technologies) qui permet àchaque partie de collaborer d’une manière découplée. N’importe quelle entreprise de locationde voitures peut s’abonner au service de la compagnie aérienne et devenir client du serviceweb qu’elle expose. Il est aussi possible d’ajouter dans cette architecture d’autres partenairespour offrir des services supplémentaires, comme la réservation de chambre d’hôtel. Malgrétoutes ces possibilités, l’architecture en question présente un point faible qui se situe auniveau de la sécurité de l’information. En effet, les services web utilisés tels qu’ils sont étéspécifiés ne garantissent pas le moindre niveau de sécurité car les technologies sur lesquellesils se basent (XML, SOAP, WSDL, UDDI) ont été conçues dans l’hypothèse des échangesouverts5. Donc, on peut dire que n’importe quel client (abonné ou pas) peut accéder au serviceproposé par la compagnie aérienne sans qu’elle celle-ci puisse l’empêcher.

Pour se convaincre des enjeux de la sécurité dans SOA il suffit de savoir que dans un contexteréel, les différents partenaires (Figure 15) se trouvent dans des domaines de sécurité différentscaractérisés par leurs propres politiques de sécurité, des stratégies de gestion d’identitésparticulières, des dispositifs de détection d’intrusion, etc. Dans ce contexte, il faut permettreque les services collaborent entre eux, comme dans les cas de chorégraphie et composition deservice, de la manière la plus efficace possible, cet à dire, en garantissant une vraie flexibilitéinter-domaine malgré les obstacles imposés par les politiques de sécurité locales.

Le défi devient beaucoup plus important lorsqu’on sait que la sécurité en SOA vise davantageles applications, les services et les machines que les personnes elles-mêmes [Pulier and Taylor2006, p. 111]. En effet, lors de l’exécution d’un processus métier impliquant plusieurspartenaires, comme l’exemple de la Figure 15, la sécurité doit avoir lieu de manièreautomatisée et sans aucune intervention humaine. Les phases d’authentification et autorisationsont déléguées aux différentes plateformes SOA de sorte que chaque service reste, au mêmetemps, accessible et protégé. Dans les cas de l’implémentation SOA par les services web, ondoit considérer aussi la capacité des messages SOAP sur HTTP de passer les firewalls sanstrop de difficulté, ce qui ouvre une brèche importante dans la violation de politiques d’accès.Malgré tout, dans une SOA idéale, la portée de la sécurité doit dépasser les frontièrestraditionnelles (entreprise et ses départements) et couvrir l’ensemble de participants(fournisseurs, intermédiaires et consommateurs).

Comme dernier point concernant les risques de SOA on considère la qualité des services, leurdisponibilité et les accords au niveau de services. Le premier concerne la capacité des servicesà répondre aux requêtes des clients dans un temps acceptable. Dans le cas où le suivi de laqualité n’est pas supporté, SOA n’est pas capable de dire si ses services sont assez rapides oupas, et de garantir la reprise de panne dans le meilleur délai possible. Le deuxième point estcelui qui permet de mieux planifier l’infrastructure de services pour que ces derniers soientaccessibles comme prévu. Si l’on ne fait pas attention aux aspects de disponibilité, il y a unrisque de méconnaissance sur l’utilisation des services. En effet, la fréquence d’utilisation des

5 L’absence de la sécurité dans ces standards n’est pas un défaut en soi car les services sont des moduleslogiciels dont le domaine fonctionnel doit rester bien défini. En découplant les aspects fonctionnels duservice de ceux concernant la sécurité on évite l’introduction d’un domaine autre que celui défini parfrontière fonctionnel du service.


services peut varier dans le temps pour toucher les extrêmes de la sur-utilisation et la sous-utilisation. Dans ce cas, la surveillance de leur disponibilité permettrait de prendre de décisionsur une éventuelle réplication afin de maintenir la performance (respect du SLA) ouabandonner son exploitation [Pulier and Taylor 2006, p. 127]. Enfin, les accords au niveau deservice représentent le fondement sur lequel on peut vérifier la conformité des services vis-à-vis des contrats existants. Si ces accords n’existent pas, SOA ne peut pas disposer desindicateurs importants tels que le temps nécessaire pour traiter une requête, les nombre demessages reçus et envoyés toutes les heures, le nombre de transactions rejetées et acceptéespar jour, etc.

Donc, pour garantir le succès à long terme de SOA il est apparu un concept déjà connu dansle haut management d’entreprise qui est celui de la gouvernance. Cette dernière est unprocessus de régulation et de contrôle qui permet d’avoir une visibilité étendue sur différentsaspects clés d’une organisation. Dans le contexte des systèmes d’information on a vu enpremier la gouvernance TI qui concentre ses efforts sur les processus de décision affectantdirectement les systèmes d’information (personnes, logiciels, matériel, etc.). La gouvernanceSOA étend les principes et pratiques de la gouvernance TI et établi un cadre de gouvernancefocalisé sur les architectures orientées services. C’est dans ce contexte qu’il est possible deminimiser les risques énumérés ci-avant.

4.1.2 L’origine de la gouvernance des TI

De nos jours, les entreprises de type société anonyme sont équipées de mécanismes degouvernance permettant d’aligner les intérêts des dirigeants sur celui des actionnaires. Lespremiers, qui détiennent le contrôle opérationnel de l’entreprise, possèdent une grande margede manœuvre sur les milliers d’opérations quotidiennes qu’une société doit exécuter. Parfois,ils sont poussés, par des forces externes et internes à l’entreprise, à se détourner des objectifsstratégiques, ce qui est une source importante de conflit avec les propriétaires (problèmePrincipal-Agent cité dans le cours [Isakov and Ledentu 2005, Chap. 1]. Ces derniers, connuscomme des actionnaires, apportent le capital nécessaire à la marche des affaires mais nedisposent pas d’assez d’informations sur la gestion de l’entreprise.

Ce que l’on vient de décrire ci-dessus n’est ni plus ni moins que la problématique donnantnaissance à la gouvernance d’entreprise. Ces problèmes existent depuis longtemps à cause dela dissociation entre la propriété et la gestion qui caractérise la structure des sociétésanonymes. La conséquence fondamentale est la perte d’efficacité pour l’entreprise concernée,dû aux nombreux coûts générés pour corriger ces problèmes et gérer les risques latents. D’unepart, il y a des coûts tels que les dépenses de contrôle, des dépenses de dédouanement et despertes provenant du manque de cohérence entre la propriété et la gestion. D’autre part, il y ades coûts importants lorsque les cadres dirigeants engagent la société dans des projets inutilesayant un grand potentiel de risque. Par conséquence, si les coûts augmentent, les bénéficesannuels sont affectés directement entraînant une diminution des résultats financiers et mêmemettre en péril la pérennité de l’entreprise.


La gouvernance d’entreprise est un modèle de haut management composé d’un grand nombred’acteurs impliqués dans différents dispositifs de surveillance et mécanismes d’incitation etdes contraintes. Une définition formelle très citée dans les travaux de gouvernance est celleque l’on trouve dans [Wikipédia-gouvernance 2008, Gouvernance d'entreprise] :

« La gouvernance d’entreprise est l’ensemble des processus, réglementations, lois etinstitutions influant la manière dont l’entreprise est dirigée, administrée et contrôlée ».

Figure 16: Le contenu de la gouvernance d'entreprise.

Dans la Figure 16 on peut constater les divers éléments cités ci-dessus qui conforment lagouvernance d’entreprise. On y aperçoit les processus tels que l’audit, l’OPA, lesrémunérations et la surveillance. Les réglementations et lois sont représentées par les codes debonnes pratiques et les droits de votes des actionnaires. Quant aux institutions, elles peuventse présenter sous la forme de comités ou tout autre organe de contrôle comme le conseild’administration, les organes de révision et les marchés. Le tout décrivant de manière généralele contenu de la gouvernance d’entreprise [Gilardi 2006, Chap 2.1].

Tableau 2: Mécanismes de gouvernance d'entreprise

Mécanismes internes Mécanismes externes

Conseil d’administration Marché d’actions

Système de rémunération Réviseurs de la société

Organe de révision Agences de notation

Activisme des actionnaires Lois et réglementations

Structure de financement Marché d’obligations


Pour mieux comprendre la notion de gouvernance d’entreprise, il ne suffit pas de se contenteravec une définition formelle. En effet, au-delà des concepts de base présentés ci-dessus, legouvernement d’entreprise est un système de relations qui agissent comment des mécanismesde contrôle, d’incitation et de sanction pour le bon fonctionnement de l’entreprise.L’ensemble du contenu de la gouvernance d’entreprise est donc classé en deux catégoriesdistinctes de ces mécanismes comme le montre le Tableau 2. En principe, un système degouvernance d’entreprise se base sur un processus global constitué de quatre phases, à savoirl’exécution des mécanismes internes, la divulgation des informations, l’exécution desmécanismes externes et l’application des sanctions. Les mécanismes internes ont pour missiond’améliorer sensiblement la direction de l’entreprise en veillant, entre autres, à minimiser lescoûts engendrés par les conflits d’intérêts. Chaque tâche réalisée à ce niveau permet deproduire certaines informations qui sont communiquées à l’entreprise et à son environnement.C’est là où entrent en scène les mécanismes externes qui viennent corriger les défauts ou lesexcès provenant de la gouvernance interne. Les mécanismes externes sont une sorte depression « naturelle » (agences de notation, etc.) contre les procédés contraires aux intérêtsdes propriétaires. Comme moyen d’action, ils offrent la possibilité de sanctionner la directionde l’entreprise en lui appliquant diverses mesures qui vont dès les menaces d’achat (OPA)jusqu’à l’application des sanctions pénales.

La description de la gouvernance d’entreprise est un point de départ intéressant pourintroduire les questions concernant la gouvernance des technologies de l’information et de lacommunication (TI). En effet, les experts dans les questions de la gouvernance des TI tels que[Georgel 2005, p. 6] et [Mitra 2005], sont d’accord sur le fait que celle-ci s’inspireprofondément des principes de la gouvernance d’entreprise et maintient des liens dedépendances avec cette dernière. On pourrait même dire, selon mon opinion personnelle, quesi la gouvernance d’entreprise n’existerait pas, celle des TI n’existerait pas non plus.

Bien qu’en règle générale les experts soient d’accord sur le fait que la gouvernance des TItrouve son origine dans la gouvernance d’entreprise, il y a une certaine divergence quant auxprincipes régissant la gouvernance des TI. Depuis la perspective américaine on considère quela gouvernance des TI existe comme un résultat direct de la gouvernance d’entreprise, plusprécisément à partir de la loi SOX6 adoptée en 2002. Elle est surtout centrée sur la conformitéaux règles de gestion des systèmes d’information qui forment cette loi.

Une autre interprétation est celle qui estime la gouvernance des TI comme une approchemanagériale nécessaire, vu le rôle de plus en plus stratégique joué par les systèmesd’information. Elle est centrée sur les aspects de performance des TI et leur apport concretaux objectifs stratégiques de l’organisation. Plus concrètement, aucune entreprise ne peutfonctionner sans le support des infrastructures informatiques et plus généralement dessystèmes d’information. Que ce soit pour faire de transactions importantes ou pourcommuniquer des données simples, on utilise des personnes, des machines et des logicielspour atteindre l’objectif visé. Ce sont donc les systèmes d’information qui sont à la base

6 Loi sur la sécurité financière adoptée aux Etats- Unis. Elle oblige les cadres dirigeants à présenter les comptescertifiées et les rend ainsi pénalement responsables. Elle assure aussi l’indépendance des auditeurs.


(fondation) des affaires de n’importe quelle organisation. Ceci est connu comme le concept del’IT Business Foundation (voir la Figure 17).

Figure 17: Le concept de l'IT business foundation. Image tirée de [Georgel 2005, p. 2].

En forçant un peu l’analogie entre les gouvernances d’entreprise et des TI on peut direqu’ainsi comme la gouvernance d’entreprise résout certains conflits et améliore laperformance de l’entreprise, la gouvernance des TI optimise la performance del’infrastructure des TI et se révèle un moyen efficace d’aligner les intérêts des différentsresponsables. Les dirigeants des TI peuvent être vus comme (dans le rôle) la direction dans lemodèle de gouvernance d’entreprise et ils doivent opérer dans l’intérêt des propriétaires dessystèmes qu’ils administrent, à savoir les cadres dirigeants, et plus généralement, l’entreprisedans son ensemble. On dit que les cadres dirigeants (haut mangement) sont les propriétairesdes TI car les budgets globaux dont dispose le département informatique est approuvé par cescadres dirigeants.

Cependant, la gouvernance de la TI est un domaine à part entière qui s’est développé pourrépondre aux différents besoins apparus dernièrement avec l’importance stratégique dessystèmes d’information. Elle englobe aussi bien des questions financières comme des aspectsde gestion et organisation. Dans [Georgel 2005, p. 6] l’auteur identifie huit piliers sur lesquelsest basée la gouvernance des TI. Ce sont le management des ressources et des infrastructures,la maîtrise des risques sur le plan technologique, la maturité des infrastructures et desprocessus, la valeur économique des ressources informatiques, la gestion de la gouvernance etdes ressources humains, le contrôle et l’audit des processus et des systèmes, la gestion de laperformance des services délivrés et l’alignement sur la stratégie de l’entreprise et lesprocessus. Dans la suite ces différents éléments seront présentés plus en détails.


4.1.3 Le contenu de la gouvernance des TI

Jusqu’à maintenant on s’est limité à décrire de manière globale le concept de gouvernance desTI en présentant séparément les deux interprétations fondamentales utilisées par les expertsdes TI, à savoir la performance technologique et la conformité réglementaire. Mais à vrai dire,aucune des ces deux approches est fausse car au bout de tout débat elles se retrouvent aucentre d’une même et unique définition donnée par l’institut de gouvernance des TI (ITGI)7.Selon ce dernier « la gouvernance des TI contribue à garantir la mise en conformité del’organisation aux exigences légales et à optimiser la performance fonctionnelle des TI, le toutau profit de la gouvernance supérieure et globale de l’organisation » [Blanc 2007]. Il existecependant beaucoup d’autres définitions décrivant de manière plus formelle ce qui est lagouvernance des TI. Par exemple, selon [Weil and Ross 2004, p. 8] la gouvernance desTI désigne :

« La spécification d’un cadre de droits décisionnels et des responsabilités en vud’encourager des comportements souhaitables dans l’utilisation des TI » (NotreTraduction).

Dans la première définition mentionnée ci-dessus on remarque que la gouvernance se focalisesur la conformité des systèmes d’information aux règles internes et externes de l’entreprise.Souvent ce sont des règles dérivées de celles existantes déjà au niveau métier et qui font partiede l’ensemble des mécanismes de la gouvernance globale (d’entreprise) instaurées dansl’organisation. Dans ce contexte on peut faire référence aux objectifs stratégiques del’entreprise qui posent les fondations pour que la gouvernance des TI puisse à son tour définirsa vision et ses propres objectifs. Par exemple, si l’un des objectifs majeurs concerne lafourniture d’un service rapide et sûr à ses clients, ce même objectif devrait être traduit auniveau technologique en un ou plusieurs objectifs clés. Cela pourrait s’énoncer ainsi :

Optimisation du temps de réponse des systèmes (extranet, etc.).

Fournir un environnement technologique sûr tant aux clients comme aux employés.

Toujours dans le même contexte du « compliance ». Pour qu’il y ait des objectifs il fautd’abord qu’il y ait aussi des personnes qui puissent les définir. Donc, la gouvernance doitétablir la structure organisationnelle la mieux adaptée à ses besoins. Lors de la présentation dela gouvernance d’entreprise on a mentionné l’organe de révision, le conseil d’administrationet l’actionnariat en tant que mécanismes de gouvernance veillant sur les intérêts del’entreprise. Avec la gouvernance des TI il se passe la même chose, il faut qu’il y ait en placedes organismes portant des responsabilités bien spécifiques et bénéficiant de certains pouvoirsde contrôle sur les opérations exécutées au moyen des systèmes d’information. C’est à cemoment que la gouvernance distribue les rôles, responsabilités et les types de décisions que

7 L’ITGI a été créé en 1998 à Illinois (USA) pour assister les leaders des TI dans l’accomplissement de leursresponsabilités et objectifs.


chacun est invité à prendre. Par exemple, on défini les personnes autorisées (qui) à prendre dedécisions sur l’architecture des applications (type de décisions), le contexte et le lieuapproprié dans lequel ces décisions doivent être prises (où) et les procédures pour prendre detelles décisions (comment).

L’un des éléments les plus importants du « compliance » est la définition des politiques(policies) et processus que les parties prenantes (architectes, développeurs, groupes de travail,etc.) sont obligés de suivre. En effet, le mot « politique » englobe les différents types de règleset normes dictées par les corps de direction ainsi que les lois auxquels est soumisel’organisation. Dans ce cas, les responsables de la gouvernance des TI vont établir despolitiques de différente nature et à différents niveaux. Un exemple typique de ce qui peut êtreune politique de gouvernance est celle concernant la sécurité des systèmes d’information.Selon les objectifs propres à chaque entreprise, elles doivent être appliquées tant au niveaudes infrastructures des TI qu’au niveau de l’architecture globale afin de garantir l’existence detous les aspects de la sécurité informatique8. Ces politiques doivent répondre à des questionsde type :

1. Quels sont les objectifs de l’entreprise en termes de sécurité ?

2. Quelle est la composition des équipes de sécurité ?

3. Quels sont les actifs critiques de l’entreprise qui doivent être protégés ?

Mais les questions de conformité ne se limitent pas aux règles internes comme cellesmentionnées auparavant. La « compliance » est très centrée sur le respect des lois externesémanant des institutions légales traçant les grandes lignes des comportements des systèmesd’information. Cela est un aspect très important dans la gouvernance des TI car elle dicte, enquelque sorte, ce qui est permit ou pas dans chaque pays. Un exemple concret est celui quifait référence aux risques encourus par les entreprises américaines ou étrangères implantéesaux USA. En effet, les entreprises qui sont sur le sol américain sont assujetties à la loi surl’embargo imposée par le gouvernement à certain pays qu’il juge dangereux. Dans unscénario comme celui-ci, la gouvernance des TI devrait veiller à empêcher qu’aucun serviceinformatique de l’entreprise ne soit utilisé par des compagnies opérant sur ces pays car unetelle violation entrainerait des conséquences graves tant d’ordre financière comme d’ordrepénal.

Actuellement en Suisse il existe un projet de modernisation du droit des sociétés anonymes etdu droit comptable. Comme dans le cas de la SOX citée auparavant, elle cherche à renforcerla gouvernance d’entreprise, confère plus de souplesse à la structure du capital et promul’utilisation des TI dans l’assemblée générale. Dans ce dernier point il y a une référencedirecte aux TI comme moyen de support au déroulement des assemblées des actionnaires.Concrètement, il sera possible d’utiliser l’Internet comme plate-forme pour réunir les

8 Les principes de base de la sécurité des systèmes d’information sont : la confidentialité, l’authentification,

l’intégrité, la non-répudiation, le contrôle d’accès et la disponibilité.


actionnaires séparés par des longues distances, de les convoquer à l’aide des moyensélectronique tels que le courriel. Les actionnaires pourront utiliser des procurationsélectroniques pour se faire représenter auprès de l’assemblée, être présent dans cette dernièrepar visioconférence et mettre sur pied une assemblée générale virtuelle grâce à l’Internet ouIntranet.

Du point de vue des TI ces modifications posent un certain nombre de défis, notamment auniveau de la qualité des données à publier, des processus de publication de rapports etl’incorporation des nouvelles règles métier dans l’infrastructure des TI. Pour ce faire, lagouvernance des TI doit définir certains principes autour des applications, des données et desrègles métier utilisées dans les systèmes d’information. Par exemple, si l’entreprise comptesur des procédures semi-automatique dans la génération de rapports critiques (comptabilité,finance, etc.), elle pourrait se poser la question sur la nécessité d’implémenter ou acheter dessystèmes hautement automatisés et fiables permettant de se rapprocher du risque zéro lors dela génération des rapports et la saisie des données par les employés. En l’occurrence, on seréfère aux systèmes de la Business Intelligence (BI) offrant des fonctionnalités d’extraction etconsolidation de données ainsi que la génération automatique de rapports.

4.1.4 Relation entre la gouvernance TI et SOA

Aligner les stratégies métier et TI

La gouvernance des architectures orientée services est une extension de la gouvernance des TIqui se focalise sur la gestion efficace de chaque aspect lié aux services. La manière dont cesderniers doivent être gérés diffère des pratiques jusqu’à maintenant utilisées par rapport auxsystèmes traditionnels dû aux changements importants induits par SOA. Par contre, il nes’agit pas d’un projet de refonte de gouvernance mais plutôt d’une suite basée sur les piliersdéjà existants dans la gouvernance des TI. Dans la Figure 18 on peut voir ces différentspiliers, ou domaines d’intérêt, ainsi que leur relation dans un modèle de gouvernance TI. Cespiliers sont l’alignement des stratégies métier et TI, la valeur des livrables (Value delivery), lagestion de la performance, le management des ressources et des infrastructures et la maîtrisedes risques sur le plan technologique [Mitra 2005, Governance responsibilites].


Figure 18: Les principaux domaines de la gouvernance TI [IT Governance Institute 2003, p. 20].

D’une manière générale, la demande provenant des parties prenantes (stakeholders) pousse ledépartement TI à travailler en cohérence avec les objectifs stratégiques. Le degréd’alignement stratégique entre le métier et le TI est un paramètre fondamental pour que les TIcommencent à fournir de la valeur (actifs, etc.) à l’entreprise. La valeur dérivée des TIspermet de satisfaire les besoins stratégiques et opérationnels exprimés par le niveau métier. Ils’agit de lui fournir tous les services espérés (Just-in-Time) avec l’infrastructure correcte et lepersonnel adéquat. Afin de permettre la continuité de l’activité TI, il est important d’effectuerune gestion proactive et réactive des risques liés aux actifs. En effet, aujourd’hui les systèmesd’information sont exposés à plusieurs dangers qui peuvent mettre en péril l’entreprise la plussolide qu’il soit. La gestion des risques permet de prévoir et d’identifier les problèmes(pannes, piratage, vols, etc.) et d’apporter des solutions temporelles ou définitives. Enfin, pouravoir une meilleure visibilité sur les opérations et la stratégie adoptée on doit mettre en placeun système de mesure de la performance TI. Dans ce domaine on s’intéresse au monitoringdes résultats permettant d’établir un bilan actuel de l’état du TI dans l’entreprise et de fixerdes nouveaux objectifs. En principe, la mesure de la performance se réalise selon quatreperspectives différentes, à savoir les clients, les objectifs financiers, les processus métier et lecapital humain [IT Governance Institute 2003, p. 29].

Dans la gouvernance SOA, l’alignement stratégique s’étend au domaine des applicationsorientées services ou applications composées. Il n’est concerne ni les applications orientéescomposants ni les architectures client-serveur traditionnels car cela est déjà pris en charge auniveau de la gouvernance TI. Il se concentre plutôt sur les questions stratégiques qui peuventêtre résolues avec une approche orientée service. Par exemple, il défini et communique lesniveaux d’investissements en SOA (finance, personnel, infrastructure, etc.) qui correspondentle mieux avec les besoins métier. Garanti les niveaux de service SOA adéquats pour que lastratégie métier puisse être déployée avec flexibilité et rapidité et prend des décisions sur lesstratégies d’implémentation de SOA.


Tableau 3 : Relation entre les solutions métier et TI

Stratégies métier Solution métier Outils stratégiques Solutions TI

Domination par

les coûts

Différentiation

Concentration

Politique de prix

bas, cash-flow

abondant et

réinvestis

Innovation, qualité

élevée, marque,

etc.

Fusion, achats,

niche de marché,

etc.

Analyse de la chaîne

de valeur

Méthodes de

portefeuille

Modèles financiers

Systèmes Supply

Chain

Réseaux de

communication

étendue : web, centre

d’appel, etc.

Intégration de

systèmes,

interopérabilité, etc.

Le Tableau 3 contient une synthèse des éléments à considérer lors de la mise en œuvre del’alignement stratégique. En principe, il est important que la gouvernance des TI puisse établirune relation avec le niveau métier. Elle peut se faire au moyen des outils d’analysestratégique, par exemple avec l’application des méthodes de portefeuille et d’analyse de lachaîne de valeur qui sont employées tant pour les directions métier que pour les directions desTI. Comme on peut le constater dans ce tableau il n’y a pas de relation directe entre lesstratégies métier et l’infrastructure des TI. Cela s’explique en partie par le fait que lesstratégies comme celle de domination par les coûts, peuvent se décliner en plusieurs solutionsmétier distinctes (petits prix ou cash-flow réinvestis) et ne déclarent aucun concept se référantdirectement aux TI. C’est ensuite que grâce aux mécanismes de gouvernance (méthodes degestion de portefeuille, etc.) qu’il est possible de déterminer le potentiel des TI dans uncontexte précis et de fournir une direction claire aux unités de gestion des TI (gestion desrisques, gestion de configuration, etc.) pour l’implantation de ces solutions.


Figure 19 Structure de gouvernance TI et SOA.

Dans le contexte de SOA, la colonne « Solutions TI » du Tableau 3 est évidemmentimplémentée d’une autre manière. Ces solutions TI sont implémentées avec la technologie deservices et demandent quelques adaptations des structures de gouvernance existantes. Commeon peut le voir dans la Figure 19, une structure de gouvernance TI se compose principalementde trois niveaux, à savoir le niveau stratégique, le centre d’excellence en gouvernance et leniveau de gestion TI. SOA introduit en plus une nouvelle entité connue sous le nom dedomain ownership [Bloomberg 2004] qui permet de décomposer une entreprise en plusieursdomaines de services ayant en commun un contexte métier. A l’intérieur d’un domaine deservice, les cadres métier et TI doivent assurer la qualité des applications et des services SOAen prenant en charge toutes les phases de leur cycle de vie. Ils sont responsables par exemplede maintenir les interfaces avec les services d’autres domaines et de négocier leurs propresniveaux de services (SLA). Selon [Bloomberg 2004] dans chaque domaine on doit trouverune liste de rôles comme celle qui suit :

Développeurs de domaine : Dans cette catégorie on trouve les personnes impliquéesdans le développement de services conforme aux principes de l’orientation servicesévoqués dans la section 2.3.

Le propriétaire de domaine désigne la personne responsable de représenter ledomaine vis-à-vis des cadres métier. Il est chargé de gérer le domaine comme uneunité de service informatique fournissant des services aux unités métier et aux autresdomaines de services SOA.

Analyste fonctionnel orienté service : C’est le rôle assigné aux personnes chargéesde capturer les besoins métier et d’identifier les services SOA à implémenter. Ilsproduisent aussi les modèles de données et travaillent en collaboration avec lesdifférents architectes.

Line of business representative : Responsable de capturer les services métier quidevront être supportés par l’initiative SOA. Pour ce faire il communique les besoinsmétier aux responsables TI.


Service tester : C’est le rôle assigné aux développeurs ou autre personnel SOA pourdéfinir et implémenter des tests conforme aux besoins métier.

Comme on l’a mentionné au début de ce chapitre, la gestion de la performance dans lagouvernance TI se centre sur quatre axes principaux, à savoir les rendements financiers, lasatisfaction du client, les processus internes et l’acquisition des connaissances du personnel TI(innovation, formation, etc.). Chacun de ces quatre axes ont pour but de mesurer un aspectspécifique de l’efficacité des solutions TI et la valeur que celles-ci ajoutent aux affaires del’entreprise. Ils permettent de disposer des indicateurs de performance clés permettant desavoir par exemple le ratio investissement-bénéfice dans un projet TI donné.

Gestion de la performance

La gouvernance SOA tire avantage de ce que l’on sait faire déjà au niveau de la gouvernanceTI. En principe, on utilise les méthodes et les outils de mesure de la performance TI (ROI,BSC, portfolio management, etc.) pour évaluer les résultats espérés au niveau de l’architectureet des services individuels. L’élément central qui permet d’optimiser le rendement financier(performance financière) est sans doute la réutilisation des services. Pour ce faire, lagouvernance TI continue à utiliser les modèles économiques cités ci-dessus, tandis que lagouvernance SOA fourni les informations telles que les statistiques de fréquence d’utilisationdes services et de chacune de ses fonctionnalités, le nombre de consommateurs par service,etc. Pour qu’un service SOA devienne effectivement rentable il faut qu’il n’existe pas endoublons, si possible, qu’il appartient à plusieurs projets à la fois (réutilisable) et qu’il ne soitpas sous-utilisé.

La performance Run-Time est aussi un sujet très important dans l’approche orienté services.Comme on peut voir dans le Tableau 4, les données comme le temps qui prend un servicepour retourner une réponse au consommateur (important dans le mode synchrone) etl’indisponibilité sont des données liées à la performance. Dans le cas des services web, letemps de réponse est un paramètre à surveiller de près car l’un des inconvénients deXML/SOAP est qu’il est effectivement plus lent par rapport aux données en format binaire[Pulier and Taylor 2006, p. 46]. D’autres éléments sont aussi susceptibles de gêner laperformance SOA, notamment le niveau de granularité des fonctionnalités, des messages etdu service et les opérations de transformation effectués par les « nodes » de traitement demessages.

Tableau 4: Quelques paramètres utilisés pour mesurer la performance des services.Performance Run-Time Performance Design-Time Indicateurs clés de

performance (KPI) Temps de réponse Temps d’arrêt Temps de disponibilité Fiabilité

Granularité des services Granularité des fonctionnalités Granularité des messages Transformation des données

Disponibilité d’un service Fréquence des interruptions Niveau de réutilisation ROI


La gestion de la qualité du service (QoS) représente un autre aspect de la gestion de laperformance SOA. La qualité des services est une question qui touche aussi bien laperformance Run-Time que celle de Design-Time. Quoi qu’il en soit, la gestion des QoS estsouvent implémentée à l’aide d’outils d’administration de service qui permettent de définirdes paramètres de qualité et de les comparer avec ceux définis au niveau des SLAs. Audesign-time il existe des principes et des patterns orientés service qui permet de garantir laqualité en fonction du modèle de service que l’on veut développer. Les grandes lignes de laQoS sont fournies principalement par les contrats de services comme le SLA qui établit lesniveaux de services attendus par les consommateurs du service en question.

Comme SOA et la gestion de processus métier sont très liés l’une à l’autre, on peut citer lemanagement des processus métier comme une des facettes de la gestion de la performanceSOA. En effet, les services de processus supportent les processus métier qui eux à leurs tourssont gérés au niveau de la couche BPM. Lorsque les indicateurs clés de performances (KPI)d’un processus métier montrent que ce dernier ne correspond plus aux besoins métier, le BPMpermet de changer d’une manière dynamique le flux des opérations afin d’optimiser lesrésultats. Parallèlement au module de gestion de processus, les outils BPM fournissent unmodule d’orchestration [Arch2Arch 2006c, p. 23] pour répercuter rapidement leschangements effectués au niveau des processus sur les services. Donc, les mesures relevées auniveau des processus métier supportés par SOA permettent aussi de faire une analyse decorrélation entre les performances du processus et celle des services qui l’implémentent.

La gestion du risque

Aussi bien la gouvernance TI comme la gouvernance SOA s’intéressent toutes les deux audomaine de la gestion des risques. Dans le contexte général des technologies de l’information,la gouvernance s’est focalisée sur trois aspects principaux, à savoir les investissementsfinanciers en TI, la sécurité de l’information et les risques opérationnels. Pour mettre en placeun système de gestion, que ce soit au niveau SOA ou au niveau TI, le principe reste le même,c’est-à-dire, on doit commencer par définir le profil de risque (aversion, goût, etc.) auquell’entreprise correspond le plus. Cette étape d’analyse comportementale permet de comprendrejusqu’à quel point les systèmes d’information peuvent rester protégés des éléments internes etexternes à l’entreprise.

En principe, la gestion des risques comprend les activités suivantes :

L’analyse des risques qui permet d’identifier les événements représentant une menacepour un projet TI et SOA. A partir de cette analyse l’entreprise est en mesured’estimer en termes de probabilité la réalisation d’un risque et les conséquencespossibles.

L’analyse de l’impact qui est une méthode permettant de capturer les pertespotentielles (totales et partielles) suite à l’occurrence d’un risque. Elle fourni unedescription détaillée sur la nature de dommages, les ressources nécessaires pour lescontrôler et les délais toléré pour que les services soient rétablis.


La gestion de la continuité des services permet d’établir un plan de conduite desaffaires dans tous les cas de figure [Descloux 2004, Chap. Plan de sécurité]. Dans lecas du rétablissement de la continuité après un sinistre, il fait référence au plan dereprise graduelle, intermédiaire ou immédiate.

La gouvernance TI et SOA doit choisir parmi les stratégies de gestion de risque telles que lamitigation, le transfert et l’acceptation du risque [IT Governance Institute 2003, p. 27].

La mitigation est une stratégie consistant à minimiser les risques par la mise en placed’une infrastructure de protection caractérisée par des mécanismes de contrôlesinternes et des plateformes de sécurité informatique.

Le transfert du risque est stratégie permettant de partager les risques encourus ou deles transférer à une entreprise spécialisée comme les compagnies d’assurances.

Enfin, la stratégie d’acceptation consistant à accepter le risque parce qu’il ne peut pasêtre réduit, ou par d’autres raisons, et qu’il faut le surveiller de près pour éviter desproblèmes majeurs.

Dans le contexte de SOA, la gestion des risques vise le cycle de vie des services pour réduireet contrôler les risques associés à la conception, l’utilisation et l’administration des services.Voici quatre exemples des risques qui peuvent survenir dans le cycle de vie des services[Brown 2007, p. 215] :

Services ill-defined: Les services dont les fonctionnalités ne correspondent pas auxbesoins métier car elles ne peuvent pas supporter le flux de travail comment on auraitvoulu. Mais aussi, lorsque l’équipe de développement consomme des ressources(temps, argent, etc.) en ajoutant des artefacts qui ne sont pas nécessaires, comme c’estle cas de fonctionnalités et de la documentation en trop.

Services disposable: Les services développés dans le but de servir dans un seul etunique projet ne sont pas convenables pour SOA car toute possibilité de réutilisationest supprimée et il est très difficile de retirer de bénéfices concrets dans le long terme.Cela revient à implémenter des services jetables qui ne servent qu’à un projetseulement et dont les caractéristiques ne s’ajustent pas aux utilisations futures.

Conception incomplète: Lorsque seulement une partie du service est achevée, commepar exemple quelques une de ses fonctionnalités, il y a un risque potentiel de devoirrevenir sur les étapes de conception pour effectuer les « derniers changements ».Malgré qu’il soit possible de laisser l’implémentation du service pour plus tard, toutesles détailles de conception devraient être terminés pour éviter que l’apparition desnouveaux concepts métier ne demandent des changements importants et coûteux.

Service sous-utilisé: Le risque d’avoir « oublié » qu’un service déterminé existe esttout à fait réel. Des problèmes liés à la gestion des registres de services et à lapolitique de communication sont souvent la cause des services peu utilisés.

Chacun des projets d’implémentation doit être évalué depuis la perspective de la gestion desrisques, aussi bien sur le plan financier qu’opérationnel. Au niveau financier, une politique


continuelle de surinvestissement ou de sous-investissement dans le développement desservices peut poser des problèmes de rentabilité et pousser l’initiative SOA vers l’échecdéfinitif. Au niveau opérationnel, la gouvernance SOA peut réduire les risques en développantun équilibre entre les stratégies de formation et « enforcement ». D’une part, une politique deformation efficace garantie que les procédures et les standards d’opération sont connus desutilisateurs et que ces derniers sont en mesure de travailler correctement. La formation est unmécanisme simple nécessitant un certain investissement en « training », « mentoring » et« lecture » [Brown 2007, p. 219] mais qui permet d’éviter que des erreurs prévisibles seproduisent et causent des dommages répétés. D’autre part, une stratégie de « enforcement »permet de capturer les erreurs avant que ces derniers ne deviennent plus sérieux. Grâce aux« check point » périodiques défini il est possible de déceler les erreurs en Design-time et enRun-Time et de les solutionner avant qu’il ne soit trop tard.

Comme on l’a mentionné auparavant, la gestion des risques concerne aussi les aspects desécurité de l’information et à ce niveau il n’existe pas beaucoup de différence entre lagouvernance TI et SOA. En effet, les services web, ou toute autre implémentation SOA,peuvent être gérés en utilisant les mêmes méthodes de gestion de risque utilisés depuis desannées par les responsables TI. Qu’il s’agit d’une architecture traditionnelle ou SOA, lagouvernance doit pouvoir établir une stratégie de sécurité, définir des contrôles, despolitiques, des standards technologiques ayant une portée globale dans leur application. Ellesdoivent aussi implémenter un cadre de gestion permettant définir les actions à mener en casd’occurrence de ces risques.

Pour montrer la manière dont la sécurité pose des problèmes de gestion à SOA, on va utilisercomme exemple les services web. En effet, le premier risque de sécurité est celui lié àl’utilisation même des standards qui malgré leurs nombreux avantages d’interopérabilitéamènent aussi certains risques. Surtout parce que leurs détails de spécification (vulnérabilités,etc.) sont aussi connus de tous les éventuels pirates informatiques inclus. Dans le cas destechnologies propriétaires, il est plus difficile de connaître leur vulnérabilité car leursinterfaces ne sont pas connues de tous. A cela s’ajoute le fait que les services web ont étéconçus dans le but de passer facilement les frontières organisationnelles pour faciliterl’échange d’information.


Figure 20: Communication non sécurisée entre le fournisseur et le consommateur de service [Cf. Ultes-

Nitches 2006, p. 15-19]

Dans un contexte d’utilisation simple tel que celui illustré dans Figure 20, un fournisseur et unconsommateur de service échangent des informations qui ne sont pas protégées contre lesrisques de déni de service (DoS), sniffing, modification et usurpation d’identités. Dans lepremier cas de figure, un service non sécurisé peut facilement être la cible d’attaques de dénide service car une des faiblesses des WS est qu’ils manquent de mécanismesd’authentification et autorisation pouvant identifier les clients ainsi que l’usage qu’ils font duservice. Comme résultat, il est tout à fait possible de submerger le service en augmentant levolume du trafic réseau au moyen de requêtes persistantes et d’une grande quantitéd’information en attachement. La plupart des services ont la caractéristique d’être sans étatmais ceux comme les services de processus peuvent être l’objet d’une attaque de type bufferoverflow en modifiant les informations d’état qu’il conserve dans une session. L’absence decontrôle d’accès permet aussi de déclencher des opérations et d’accéder aux sectionsprivilégiées sans y avoir droit.

Dans le deuxième cas, l’attaque appelée eavesdropping est une technique d’écoute passive desmessages transitant dans un réseau. Souvent, les WS communiquent en passant par plusieursintermédiaires qui routent le message à l’intermédiaire suivant dans la chaîne. Cette situationest idéale pour intercepter les messages et lire son contenu. Sachant que la plupart desattaques viennent de l’intérieur, le message peut être lu après avoir entré dans la zone deconfiance ou de destination, cet à dire, au conteneur du service. La cause de cette vulnérabilitése trouve dans l’absence de mécanismes de cryptage au niveau des messages (faisantabstraction de la pile WS-Security) qui laisse leur contenu circuler en clair à l’intérieur dusystème host du service.

Enfin, le troisième et quatrième cas de figure concerne deux types d’attaques contre l’intégritéet la confidentialité des messages. Dans le contexte des services web on parle d’intercepteursSOAP [Pulier and Taylor 2006, p. 113] qui sont des systèmes crées pour lire, modifier et


contrefaire des données échangés par les services web. Dans le quatrième cas de figure,l’attaque n’a de sens que si le service peut disposer d’une capacité minimaled’authentification comme c’est le cas des services de processus.

4.2 Le Roadmap

L’une des tâches de la gouvernance SOA consiste à gérer le cycle de vie de SOA, cet-à-dire,l’implémentation de SOA à l’échelle de l’entreprise. Dans ce processus l’alignementstratégique a lieu dans la phase initial de SOA et dans la planification du « Roadmap » quidéfini les étapes pour déployer les solutions métier et l’infrastructure requise pour lessupporter [Arch2Arch 2006a, p. 17]. En effet, du moment où le projet SOA est lancé il fautanalyser l’état actuel du métier (objectifs, stratégie, etc.) et des TI (information, data,architectures, etc.) afin d’identifier les problèmes et les avantages potentiels. A ce point lafrontière entre les gouvernances des TI et SOA devient un peu flou car on suppose que lagouvernance des TI est déjà responsable de surveiller de près l’ensemble des biens etressources existants.

Figure 21: Le Roadmap doit inclure les principes de SOA ainsi que l'architecture de référence.

Cependant, dans la phase de planification du Roadmap, cet à dire, de l’état futur d’uneentreprise orientée services on fait toujours référence aux objectifs et stratégies globaux. Dansla Figure 21 on illustre sous forme de diagramme UML le contenu d’un Roadmap. Ce sont unensemble de principes diverses et de formes d’architectures qui sont prises en compte pourson élaboration. L’étiquette « inclus » représente l’inclusion, dans le Roadmap, des règles etcontraintes se référant aux principaux éléments d’un système d’information (données,


information, métier, application, etc.). Ces principes de SOA sont rédigés sur la base desobjectifs et de la stratégie globale et représentent un point important où les responsables deSOA doivent refléter leur détermination à aligner SOA avec les objectifs métiers.

Tableau 5 : Relation entre les solutions métier et l'infrastructure SOA tiré de[Arch2Arch 2006a, p. 11].

Business solutions Services infrastructure

Employee self-serviceProvides a single portal for employees toperform all personal administrative tasks, suchas address change, benefit enrollment, timeand expense reporting, and employeeonboarding

Portal• Authentication, authorization, singlesign-on• Skins/skeletons for a consistent lookand feelEAI• Integration with back-end applications• Business processes that run acrossmultiple systems

Single view of the customer (SVC)Provides an SVC across all business silosbased on roles and information needs of thecustomer

Portal• Authentication, authorization, singlesign-on• Skins/skeletons for a consistent lookand feel• Integration with Business Intelligence(BI) dashboardShared data services• Aggregation of data from multiplesources• Exposure of shared data services toaccess customer informationEnterprise service bus• Capture of events from transactionsystems to populate the customer registry, ODS,synchronize data, etc.• Services infrastructure for 150+ sharedservices

Regulatory complianceRequires business process orchestrations

Service registry• Discovery of all shared business anddata servicesBusiness process management• Execution of business process to identifyabnormalities (based on external events)

Grâce au Tableau 5 on peut remarquer la relation qui existe entre les solutions métier et lesservices SOA qui les supportent. Il s’agit d’un ensemble de pratiques recommandées par[Arch2Arch 2006a, p. 11] qui montrent le potentiel des architectures orientées services às’aligner avec les objectifs métier.


4.3 Planification et exécution de SOA

Avant de présenter les détails de la gouvernance SOA, il est important de prendre un peu derecul afin d’avoir une vue d’ensemble sur la dynamique de SOA, à savoir le cycle de vie deSOA et le cycle de vie des services.

Formellement, un cycle de vie est un scénario (…) d’activités, partant d’une idée (…) jusqu’àson retrait. Il est destiné (…) à coordonner les différents métiers, activités et tâchesnécessaires à la vie d’un système. Dans le domaine logiciel, quelque soit le projet en question,un cycle de vie est toujours composé de trois processus clés [numeraladvance 2008] et[Organisation Internationale de normalisation 2008] :

Processus de base : Ce processus désigne les activités utilisées par les groupes detravail pour initialiser, développer, exploiter et maintenir les solutions logicielles. Enquelque sorte ces sont les processus centraux de création de valeur.

Processus de support : Le terme support regroupe les activités utilisées par lesprocessus de base pour gérer les artefacts (modèles de conception, code source,politiques, etc.) utilisés et générés dans les tâches de base. On y gère aussi lesquestions d’assurance de la qualité, de configuration, etc.

Processus organisationnels : Au niveau organisationnel il est nécessaire d’avoir unensemble de « super » processus de management capables de gérer les processus debase et de support dans une perspective d’optimisation. Ce sont les processus demangement de ressources et d’infrastructure.

Dans le contexte de la gouvernance SOA on fait le plus souvent référence au cycle de vie desservices comme l’objet central autour duquel doivent s’appliquer les mécanismes degouvernance. Cependant on oublie que du point de vue métier SOA est un choix stratégiquequi doit être mis en place étape par étape afin d’assurer son déploiement à grand échelle. C’estpourquoi il est important de considérer son cycle de vie comme un domaine sous laresponsabilité de la gouvernance. Cependant, grand nombre de projets ont été lancés sansaucune structure de gouvernance due au nombre faible de services concernés. C’est seulementaprès une croissance important de l’inventaire des services que la gouvernance entre scène.

Bien qu’il ne soit pas possible de compter sur une procédure unique d’implémentation deSOA, il existe à l’heure actuelle un ensemble de recommandations et « best practices »servant de repère à la mis en place d’un cycle de vie spécifique à chaque entreprise. Dans laFigure 22 on illustre le cycle de vie générique recommandé dans [Arch2Arch 2006a, p. 13].Il s’agit d’une approche de gestion de projet qui organise et coordonnent toutes les activitésd’implémentation de SOA en trois phases principales: l’initialisation du projet, ledéveloppement d’un plan SOA (Roadmap) et l’exécution « Roadmap ».

La première phase concerne le lancement de l’initiative où l’on analyse la pertinence du projetpar rapport aux critères de l’entreprise. Du point de vue de la gestion de projet, cette phaseimplique des activités d’initialisation et d’étude préalable qui sont propres à un projettraditionnel, à savoir la proposition de SOA (proposal), l’analyse des risques et des enjeux


métier, l’établissement des estimations budgétaires et des perspectives de retour surinvestissement, les délais prévus et les recommandations de faisabilité.

Aprèles psupérde l’d’initseronorgan

Le copourafin dgrâced’étaà la c

DéveloppementRoadmap

Exécutiondu Roadmap

Initialisation SOA

Principes SOA et TI

Architectures deréférence

Modèle de maturité

Management deprojet et portefeuille

Application

Données

Cycle de vie desservices

Livrables

Fiche de projet

Rapport de l’état actueldes ressources, etc.

Livrables

Plan de l’état futur(métier et SOA)

Cycle de gouvernance

Révision

Proposal

Alignement, gestiondes risques, etc.

Etat actuel des TI

Compositiondes équipes

Figure 22: Une vue très simplifiée du cycle de vie SOA

s la phase d’initialisation, le cycle génère une série de livrables qui seront appelés danshases restantes. Il s’agit d’un ensemble de documents qui permettent aux cadresieurs d’avoir une idée globale sur les coûts et bénéfices attendus et, par la suite, décideravenir de SOA. La composition des équipes de travail fait aussi partie des activitésialisation car elle permet de mettre en place une structure ordonnée de professionnels quit chargés de diriger et de mettre en place l’architecture et ses composants. Cette structureisationnelle est composée des deux dimensions fondamentales de SOA :

Le groupe métier constitué de plusieurs représentants provenant des niveauxstratégiques et opérationnel tels que le conseil d’administration, le PDG, etresponsables des unités d’affaires.

Le groupe des TI doit être représenté par le responsable des systèmes d’information(CIO), les architectes et développeurs, etc.

ncept de Roadmap a déjà été abordé auparavant (voir section 4.2) lorsqu’on a mentionnéla première fois le cycle de vie SOA. Toutefois, il est important de revenir sur ce sujet’établir une relation entre la gouvernance SOA et ses différents cycles de vie. En effet,à la Figure 22 on peut constater le moment précis où il serait le plus convenable

blir un plan de gouvernance. Selon ce modèle, il pourrait avoir lieu avant ou en parallèleonception des premiers services SOA bien que certaines entreprises attendent (préfère)

Milestones Gouvernance


un niveau de maturité plus avancé pour le faire. Dans touts les cas, il est plus avantageux decommencer le plus tôt possible avec les questions gouvernance pour éviter que l’implantationet évolution de SOA ne deviennent pas un incontrôlée. Pour s’en convaincre il suffitd’imaginer le scénario où les droits et obligations de chacun ne sont pas clairement définis. Sil’un des services en opération pose des problèmes à l’entreprise ou à une de ses unitésd’affaire, il devient impossible de trouver un responsable capable de corriger la situation etl’on se retrouve bloqué jusqu’à qu’une solution ne soit trouvée. Par contre, si la gouvernanceétait déjà en place, une procédure de correction prédéfinie aurait été lancée permettant dereprendre les affaires les plus vite possible.

Cette deuxième phase peut être assimilée au début de la gouvernance SOA car elle estorientée vers les processus de planification et de normalisation. En effet, pour définir lesprincipes SOA et des TI ainsi que l’architecture de référence il faut que l’on est déjà établi lesrègles du jeu et les rôles des participants, à savoir les personnes responsables des architecturesde données, d’information et d’entreprise, les analystes fonctionnels, les directives etexigences métier, etc. Parmi les livrables obtenus à la fin de cette phase se trouventl’architecture de référence et les modèles de maturité et de gouvernance SOA.

Figure 23: Architecture de référence pour SOA Cf. [High, Kinder et al. 2005, p. 25]

Dans la Figure 23 on montre un exemple d’architecture de référence qui tient compte del’ensemble des ressources de TI. Bien que dans ce type de document on ne dit rien sur lagouvernance, il est sous-entendu qu’il est le résultat d’un processus de décision importantconcernant la direction future vers laquelle doit se diriger l’architecture SOA. Pour réussir àimplémenter l’ensemble de cette architecture on doit avancer étape par étape, selon uneapproche évolutive (décider au niveau gouvernance et management) en adoptant lescomposants qui sont réellement nécessaires. Dans cet exemple on peut constater que lesresponsables des TI ont décidé de conserver la couche de systèmes légués ainsi que les

Go

uv

erna

nce

Bu

siness

service

Ma

na

gem

ent

En

terprise

Secu

rity


solutions d’intégration d’applications traditionnelles. Ils sont aussi envisagé l’implémentationd’une couche de services [High, Kinder et al. 2005, p. 25] et d’une couche web intégrée par latechnologie de portails pour donner aux clients une accessibilité total et un point d’entréeunique vers l’ensemble des ressources de l’entreprise. SOA recouvre la totalité des troiscouches de ce modèle de référence en réservant un type de service pour chaque niveau. Parexemple, selon la description fourni par [High, Kinder et al. 2005, p. 26] les services d’accèsqui englobent les services de données, les services « wrapper », et autres, sont utilisés pourétendre les applications déjà en place. Les services d’information encapsulent la logique detraitement de données comme l’accès aux différentes sources de données, le businessintelligence, etc.

Il existe un lien très étroit entre l’architecture de référence et le modèle de maturité. En effet,pour atteindre les objectifs définis dans l’architecture de référence on peut construire unmodèle de maturité constituée d’un ensemble d’étapes clés qui permettront d’évaluer l’étatdans lequel se trouve l’organisation par rapport à SOA. Les indicateurs d’une échelle dematurité sont en quelque sorte les premiers indicateurs de performance dont dispose lagouvernance SOA pour évaluer l’avancement du projet à échelle de l’entreprise. Celaconfirme ce qui a été mentionné jusqu’à maintenant, cet à dire, qu’en plus du cycle de vie desservices, il existe bel et bien un lien entre la gouvernance SOA et le cycle de vie de SOA.

Les niveaux de la Figure 24, à savoir « Fundamental SOA », « Federated SOA » et « process-Enabled SOA » peuvent être utilisés comme des indicateurs de maturité focalisée sur lesservices9. Voici une description générale de chaque niveau de maturité :

1. Le premier niveau de maturité proposé dans cette illustration correspond à uneentreprise qui s’est limité au développement des services d’application. Pour qu’uneentreprise atteigne le niveau fondamental de SOA il faut qu’elle soit en mesure demettre en place une architecture constituée des services de base comme ceux utiliséspour accéder aux sources de données. C’est le niveau d’exigence minimale quiconsiste à exposer les fonctionnalités dont on dispose déjà dans les systèmes « back-end » sous forme de services de bas niveau.

2. Lors du deuxième niveau de maturité on doit mettre en place des services plusélaborés et complexes que ceux décrits ci-dessus. Ils représentant des tâches ou desentités appartenant à des différents domaines de l’entreprise. Ce niveau est supérieur àcelui des services d’application car il s’adresse aux services contenant la logiquemétier d’une tâche, d’une activité ou d’un processus métier. Dans certains modèles,ces services peuvent aussi encapsuler la logique spécifique à une entité de typeconsommateur ou employé.

3. Le dernier niveau de maturité ajoute une couche supplémentaire qui est celle desservices de processus. Ce type de service est très différent des services concertés oucomposés développé dans le niveau précédant. Ces derniers ne maintiennent aucun

9 Un roadmap peut opter pour un modèle de maturité globale (services, applications web, etc.) ou pour plusieursmodèles de maturité différents centrés sur un aspect spécifique.


état conversationnel tandis que les services de processus doivent conserver l’état desinformations propres à un client tout au long de leur utilisation.

Figure 24: Modèle de maturité SOA en trois étapes [Josuttis 2007, Chap. Classification de services].

4.4 La gouvernance des services

Dans la section précédente on a présenté le lien entre la gouvernance et le cycle de vie deSOA. Ce dernier étant un processus de haut niveau englobe tous les aspects de base de lagouvernance SOA, notamment la définition du modèle de gouvernance (organisation,objectifs, etc.) qui sera mis en place au fur et à mesure de la maturité de l’architecture. Unefois que la gouvernance SOA entre en action, le cycle de vie de SOA devient aussi un objet degouvernance qui doit être encadré par des politiques, décisions et mécanismes d’applicationdes politiques (enforcement).

Jusqu’à maintenant on a situé le cycle de vie des services dans la phase d’exécution du cyclede vie de SOA car c’est à cette étape que les activités de développement comme l’analyse, laconception, l’implémentation, le déploiement et la maintenance des services ont lieu pour lapremière fois. Or, le cycle de vie des services regroupe toutes ces activités en trois phasesdistinctes qui sont connues comme les phases Design-Time, Run-Time, Change-Time [Cf.Hoernes and Schwarb 2007].


Figure 25: Les trois phases du cycle de vie des services SOA

Chacune des phases du cycle de vie des services est caractérisée par un ensemble d’élémentsqui revêtent une importance particulière du point de vue de la gouvernance tels que lesacteurs, les services et les artefacts. A chaque phase du cycle de vie, il y a un nombredéterminé d’acteurs responsables d’exécuter certaines tâches comme la capture des besoins oul’implémentation des services. En SOA, le système de gouvernance doit permettre de définirclairement les différents rôles que chacun est autorisé à jouer ainsi que les relations entre cesacteurs.

L’enchaînement des étapes du cycle vie ne se fait pas par hasard, il poursuit un seul objectif,celui de produire des services conforme aux exigences métier. Dans l’approche SOA, lesapplications orientées services sont considérées comme des actifs de l’entreprise quiconsomment des ressources importants, ce qui justifie la mise en place des processus degouvernance chargés d’évaluer leurs performances technique et financières. En tant qu’actifs,ils sont aussi une valeur concrète pour l’entreprise qui est liée au potentiel de réutilisation dechaque service. Il est donc important que la gouvernance SOA crée les mécanismes pour faireappliquer les principes du développement orienté service, en particulier la réutilisation et lacomposition car ceux-ci ont un impact directe sur les comportements final des services.

A la fin de chacune des phases, le cycle de vie produit des résultats tangibles que l’on appelledes artefacts. Un artefact, dans sa forme la plus générique, désigne un document ou autreinformation de support qui est conçus de manière à être réutilisables dans les projets à venir etpas seulement dans les projets courants. Plusieurs aspects concernant les artefacts sont duressort de la gouvernance comme par exemple la définition des points de contrôle (checkpoints) permettant d’assurer l’existence des documents essentiels à la fin de chaque étape.


Avant de passer à la phase suivante du cycle de vie il faut que la gouvernance approuve lesrésultats obtenus en les contrôlant de plus près. Par exemple, en faisant appliquer despolitiques claires sur le format, le contenu et l’emplacement approprié des documents tels queles modèles de données, les fichiers de code, etc.

Dans les prochains chapitres on aura l’occasion d’approfondir un peu plus dans le contenu dechacune des phases du cycle de vie des services. Tout d’abord on expliquera la phase deDesign-Time en mettant en avant certaines notions de base comme la définition et les objectifsqu’elle poursuit. Ensuite on développera plusieurs points concernés par la gouvernanceDesign-Time. Cette même structure sera conservée pour les deux phases restantes,premièrement pour la gouvernance Run-Time et ensuite pour celle du Change-Time.

4.4.1 La phase de « Design-Time »

Comme on peut le constater dans la Figure 25, la phase Design-Time constitue la premièreétape du cycle de vie des services. Elle est composée de deux activités fondamentales, àsavoir l’analyse et capture des exigences métier et la conception et implémentation desservices. Dans la première activité on trouve les tâches liées à l’analyse orienté service desprocessus métier, à savoir la définition des exigences métier, l’identification des processusmétier, la définition des modèles services et l’analyse des fonctionnalités et des systèmesexistantes. Dans la deuxième activité on trouve les tâches de modélisation de services tellesque la décomposition des processus métier en sous-processus, l’identification des opérationscandidates, implémentation des services et la construction des prototypes.

La gouvernance de la phase Design-Time est une discipline de direction qui vise à établir lesprocessus et politiques qui devraient être suivies par l’ensemble des ressources engagées dansle développement des services. Elle poursuit les objectifs suivants :

Promouvoir la réutilisation

Promouvoir l’interopérabilité

Mesurer et comparer la performance des services

Identifier et fournir les bons services

Guider l’implémentation de l’infrastructure nécessaire au support de SOA

La gouvernance Design-Time consiste principalement à implémenter des mécanismes decontrôle (check points) permettant de guider les développeurs dans la création, la publicationet la maintenance des interfaces de service. La création des services SOA est un processus quiselon [Hoernes and Schwarb 2007] peut se décomposer en trois étapes, à savoir le design dehaut niveau, le design détaillé et l’implémentation. Pendant chacune des étapes, le processusde développement est guidé par les mécanismes de gouvernance pour gérer l’alignementstratégique, les risques et les investissements TI. Pour ce faire, elle doit poser les bases de lacréation de services en définissant les principes d’architecture, les modèles de services et lagestion du portefeuille de services.


Quant à la publication des services, le processus est évidemment moins complexe mais ilcomporte certaines décisions importantes qui vont déterminer si un service est prêt pour êtrepublié dans un registre. Ces décisions couvrent tous les domaines de la publication desservices, notamment le registre et les interfaces. On peut citer par exemple, les politiques deréplication des registres et le choix entre les stratégies de fédération ou centralisation desregistres. Les mécanismes de « check-in » et « check-out » [Layer 7 Technologies Inc 2006,p. 3]qui permettent de créer et de modifier les métadonnées concernant les interfaces, lecomportement et les politiques des services. Ce faisant, il est possible de tester l’identité desutilisateurs du registre (développeurs et clients) sur la base d’une politique de sécurité interneà l’entreprise ou étendue (plusieurs entreprises).

Enfin, la maintenance des services est une activité qui se situe entre les phases de Design-Time et de Change-Time. Pour la gouvernance Design-Time il s’agit de gérer ledéveloppement de telle manière qu’il y ait peu des changements à faire dans l’avenir.Lorsqu’un projet de maintenance se présente, on doit décider sur la manière dont ceschangements seront effectués pour que les clients ne soient pas affectés et les SLA respectées.Dans les sections suivantes on abordera plus en détails la gouvernance des processus decréation de services.

Le développement de services

Dans la création de service il y a plusieurs éléments qui doivent être en place pour faciliter lel’implémentation des services. Premièrement, il faut définir les stratégies de développementqui se révèlent les plus intéressantes pour les services en question. On peut choisir entre deuxapproches distinctes, à savoir la stratégie « top-down » et la stratégie « bottom-up ».

La Figure 26 montre le processus implémentant la stratégie « top-down ». Il s’agit en toutd’une séquence de sept étapes qui commence par la définition des ontologies del’organisation (types d’informations, graphe de relations entre ces informations, etc.) ettermine par le déploiement des services. L’analyse effectué dans cette approche permet dedécomposer l’organisation en domaines logiques délimités par les éléments d’informationcommuns (données, information, fonctions, etc.).

Du point de vue de la gouvernance, la décision de déployer cette stratégie se justifie, d’unepart, par la volonté de supporter plusieurs types de services (services de processus, métier etde support), et d’autre part pour guider le développement de services vers une dimensionsupplémentaire de flexibilité et souplesse architecturale ainsi que de réutilisation de services.


Figure 26: Processus top-down défini dans [Erl 2005, p. 364]

La deuxième stratégie qui est nommée « bottom-up » commence par analyser les applicationset services existants afin d’identifier ceux qui seront développés par la suite. On analyse parexemple les fonctionnalités et les données contenues dans les systèmes légués en vud’extraire celles qui feront partie des services candidats. En utilisant cette stratégie oncherche surtout à exposer les fonctionnalités des applications existantes sous la forme deservices et à bénéficier ainsi des caractéristiques propres aux services « wrapper », telles quedes cycles de développement courts permettant de passer d’une architecture orientéecomposants à une SOA de base en très peu de temps, de réduire la complexité dudéveloppement, supporter l’intégration d’application à l’aide de services et promouvoirl’interopérabilité. La Figure 27 montre un exemple de processus proposé par [Erl 2005, p.367] qui consiste en cinq étapes focalisées sur les services d’application de la section 2.2.

Figure 27: Processus bottom-up défini dans[Erl 2005, p. 367]


Design de haut niveau

Pendant l’étape du design de haut niveau, les analystes fonctionnels et les architectes SOAdoivent respecter certaines contraintes pour assurer le succès de SOA. La justification et laspécification des services sont deux exemples de contraintes qui sont utilisées pendant lesétapes de conception [Brown 2007, p. 219]. Il s’agit surtout de garantir aux clients etpropriétaires des services que ces derniers ne peuvent être développés que s’ils passent avecsuccès les mécanismes de justification et de spécification. Pour que le développement d’unservice soit justifié aux yeux de la gouvernance il faut que la gestion du portefeuille aitapprouvé sa faisabilité au niveau financier et métier. Cela veut dire que les coûts additionnelsd’un éventuel développement sont justifiés par le potentiel de réutilisation du service ou parsa stabilité fonctionnelle à long terme [Brown 2007, p. 219]. Du côté de la spécification, lagouvernance doit garantir que celle-ci contient tous les éléments nécessaires décrivant unservice. On parle même de réutilisation de la spécification lorsque celle-ci est conçue enconsidérant son utilisation à long terme qui permet de minimiser les éventuels changementsfuturs.

Dans les sections suivantes on présentera deux éléments de haut niveau qui ont des liens avecles contraintes de spécification et de justification mentionnée ci-dessus. Ces sontrespectivement les principes d’architecture et la gestion du portefeuille de service.

Principes d’architecture

L’un des aspects fondamentaux de la gouvernance SOA concerne la question del’établissement des principes SOA. En effet avant de concevoir les services et leurs modèlesrespectifs, la gouvernance doit établir un ensemble de directives de haut niveau alignées surles objectifs stratégiques de l’entreprise. Les principes SOA doivent donc correspondre à unobjectif métier (par dérivation) en clarifiant la manière dont un service doit exister poursoutenir la stratégie de l’entreprise. En général, les principes d’architecture sont définis dansla phase de conception (Design-Time) et doivent être revus à chaque fois que les objectifsd’affaire sont modifiés. Ils se déclinent en quatre types distincts, à savoir les principesd’architecture, les principes de données, les principes d’application et les principes detechnologie.

Dans le Tableau 6 on montre les quatre types de principes dont on a mentionné ci-dessus.Comme on peut le constater dans ce tableau il ne s’agit pas seulement de questionsd’architecture elle-même mais plutôt de l’architecture et ses composants, à savoir lesservices, les données, et la technologie sous-jacente. Dans la colonne de l’architecture, leprincipe de consistance fourni les directives pour assurer qu’il n’aura pas de conflits dedécisions entre les différents projets. Avant démarrer la conception d’un service lesarchitectes et développeurs doivent tenir compte de la contrainte de consistance pour ne pasintroduire des contradictions dans le comportement de l’architecture, notamment quant auxmécanismes de création, recherche, découverte et utilisation des services. Le degré élevé dediversité technologique typique de SOA et son caractère distribué redonne une importanceparticulière à ce principe car il est important que SOA conserve une certaine cohérence


opérationnelle et fonctionnelle afin de garantir les meilleurs résultats et de faciliter leschangements futures.

Tableau 6: Principes d'architecture

Architecture Services Données Technologie

Consistance

Abstraction

Découplage

Réutilisation

Contrats deservices

Autonomie

Centrésdocuments

Partage

Sécurité

Interopérabilité

Contrôletechnologique

Flexibilité

Un principe d’architecture doit être formulé d’une manière standard et structurée à l’aided’éléments descriptifs simples comme le nom, la définition et les objectifs à atteindre. Le faitd’appuyer l’établissement des principes sur un format prédéfini permet de faciliter leurcompréhension et communication à l’échelle de l’organisation et non uniquement à l’échellede la gouvernance. Par conséquent, le principe de réutilisation des services pourrait êtreformulé comme suit :

Titre : Services réutilisables

Définition : Les services d’application (support, wrapper, etc.) doivent être livrés avecun niveau élevé de réutilisation basé sur une conception suffisamment générique, àl’exception des services de processus encapsulant la logique spécifique à un processusmétier.

Objectifs :

o Eviter le développement de doublons (des services et des fonctionnalités).

o Réduire le cycle de développement pour répondre aux changements plusrapidement.

Caractéristiques de conception : Le contrat de service est considéré comme étantgénérique et flexible de telle façon qu’il soit possible de l’utiliser un même servicedans des scénarios différents. Le service doit pouvoir traiter plusieurs consommateursà la fois et être utilisé par une grande variété de consommateurs.

Conditions d’implémentation : Disposer de l’infrastructure nécessaire pour mener lecontrôle de versions de services, identifier les services existants et rechercherl’ensemble de services de l’organisation. Disposer d’un environnement decomposition de services en temps d’exécution et confier le développement auxanalystes et architectes confirmés pour garantir un niveau élevé de réutilisation.


Le portefeuille de services

La notion de gestion de portefeuille est depuis longtemps utilisée par la gouvernance des TIcomme un instrument de contrôle et de gestion d’applications. Dans le contexte de SOA leportefeuille des services est utilisé pour orienter les décisions que peuvent prendre lesarchitectes et développeurs quant au développement, la réutilisation, l’évaluation et lamaintenance des services [Remenyi 2006, p. 230]. Grâce au portefeuille ces différents acteurspeuvent trouver des réponses aux questions de type :

1. Quels sont les processus métier qui devraient être implémentés comme des services ?

2. Quels services sont-ils planifiés et quels services sont-ils en exécution ?

3. Quels projets doivent-ils être financés dans le court et long terme ?

4. Les modèles de services existants correspondent-ils à l’architecture de référence ?

5. Construire un nouveau service, mettre à jour ou réutiliser un service existant ?

Dans le domaine de la gestion du portefeuille de services, la gouvernance SOA estresponsable de définir un système de priorisation basé sur les concepts tels que lesconsommateurs et fournisseurs de services. En procédant ainsi on peut établir un lien dedépendance entre les projets de création de services qui influera sur l’ordre dans lequel lesservices seront développés. Il est aussi possible de créer ce même système à partir de deuxcritères déterminants comme l’impact et l’urgence des services. Dans ce cas on s’intéresse àl’impact qu’un service potentiel aura sur les processus métier, au même temps que l’on évaluele temps nécessaire pour le rendre opérationnel. Pour que les décisions prises soient baséessur des observations objectives il faut que l’analyse sur l’impact considère aussi bien lesquestions d’ordre financier (estimation de budget, calcul des coûts, etc.) que d’ordrefonctionnel (SOA). Sur la base des résultats de cette analyse on peut donc déterminer l’ordreou la séquence de développement des services individuels.


Figure 28: Classification de services selon la logique encapsulée dans un service.

La gouvernance en Design-Time est aussi responsable de définir un système de classificationde services comme celui de la Figure 28. Dans la section 2.2 concernant les modèles deservices on a déjà présenté une catégorisation de services basés sur la logique sous-jacenteimplémentée par les services. Cependant, il existe d’autres variantes de classification utilisantdes critères complémentaires comme la portée de la logique du service qui sert à dégager les« building blocks » de l’architecture, et une troisième classification basée sur le rôletemporaire qui jouent les services dans le temps d’exécution. Les buildings blocks10 sontutilisés pour apporter une meilleure compréhension de la portée de la logique modélisée parles services, processus et opérations candidates. Leur but est d’identifier et de regrouper lesdifférents niveaux de logique qui pourraient se trouver dans une organisation, tels que lesprocessus, services, activités et tâches et de disposer d’une vue ordonnée, allant de l’unité laplus petite (tâche) jusqu’à la plus grande (processus), qui pourrait être utilisée comme guidedans la conception et modélisation, notamment pour informer sur ce que l’entreprise entendcomme un processus, un service ou une tâche. Pour le portefeuille de service il s’agit d’uneinformation complémentaire aux modèles de services qui est utilisée pour analyser lesservices candidats11.

La troisième forme de classification concerne les rôles assumés par un service pendant sonexécution. Pour être sur qu’un service joue un rôle déterminé il suffit de considérer soncontexte d’utilisation. Si le service est appelé par une application ou un autre service externeil est alors dans le rôle d’un fournisseur, dans le cas contraire où c’est lui qui utilise un serviceexterne il devient un consommateur. Lorsqu’un service n’est ni fournisseur ni consommateur

10 Ce sont des unités de modélisation de services11 Avec le building blocks on peut faire la correspondance directe entre un service candidat et un service concret.


il peut jouer le rôle d’intermédiaire active ou passif entre deux services ou le rôle decontrôleur ou simple membre d’une composition.

Figure 29: Processus du portefeuille de services.

Avant même de commencer à exécuter les activités de gestion de portefeuille, la gouvernanceSOA doit définir les étapes qui conformeront le processus de gestion de portefeuille. Dans laFigure 29 on peut observer un processus de gestion de portefeuille recommandé dans le cadredes « ITIL12 best practices» [Macfarlane and Rudd 2006]. La première étape permet de définirle portefeuille de services en collectant l’ensemble des services existants ainsi que lesinformations les plus pertinentes. Les services candidats doivent aussi être pris enconsidération afin de pouvoir dégager les capacités financières et matérielles dont comptel’entreprise pour développer des nouveaux services. Dans la deuxième étape on analyse lesservices récemment identifiés afin de décider s’il vaut mieux développer un nouveau serviceou simplement réutiliser un service déjà existant. La troisième étape se réfère à la phased’approbation qui marque le lancement du projet de développement proprement dit.L’approbation consiste en contrôler que les étapes précédentes ainsi que les artefacts exigéssoient produits selon les règles préétablies par la gouvernance. Pour terminer, on publie lesdifférentes décisions concernant la suite à donner aux services candidats et on procède àl’allocation des ressources nécessaires.

Le design détaillé

L’étape de design détaillé permet de définir les contrats de services, les types de données etles caractéristiques de design tels que la performance, la fiabilité et la qualité des services

12 ITIL = IT Infrastructure Library


[Hoernes and Schwarb 2007]. Au niveau de la gouvernance, il s’agit de gérer le cycle de viedes contrats de services, la standardisation des données et la conformité du design parrapport aux contraintes de performance, fiabilité et qualité de services. En effet, lagouvernance SOA se charge de définir le contrat de service du point de vue métier endécrivant les capacités fonctionnelles du service ainsi que les différents messages que celui-cidevra échanger avec les autres applications. Comme on peut le voir dans la Figure 30 il existetrois types de contrats de services qui se différencient par la nature du partenaire que l’on aaffaire. En général, les accords sur les niveaux de services (SLA) se situent entre les clients etles services établissant un accord formel sur sa livraison et son utilisation. Les contrats passésentre les domaines d’affaires d’une entreprise sont désignés comme des accords aux niveauxopérationnels (OLA) et lorsque le développement et la livraison des services sont supportéspar des partenaires externes on l’appelle accord de sous-traitance (UC).

Figure 30: Différents types d'accords sur les niveaux de service.

Pour gérer les SLAs en Design-Time on s’intéresse au processus de développement des SLAsqui est très lié au développement des services. Le développement des SLAs a une placecentrale dans le succès de SOA car il permet de produire les accords sur les niveaux deservices qui lieront les clients et les fournisseurs d’une manière formelle. Dans [Maurer,Matlus et al. 2000 p. 7] on rappelle que pour développer une SLA il vaut mieux de suivre uneméthodologie bien déterminé et adaptée aux besoins de chaque organisation. Pour ce faire, ilsrecommandent de prendre en compte les facteurs suivants :

Identifier les besoins : Ce premier facteur permet d’identifier les besoins des clientsqui sont à l’origine de la demande de service. Une question simple permettant decapturer les exigences des clients est de se demander pourquoi ces derniers veulent-t-ils utiliser le service ou quelle est leur motivation principale ?


Définir les objectifs : Le deuxième facteur clés se focalise sur la définition desobjectifs que les clients devraient atteindre en utilisant le service. Il s’agit du butmême du service du point de vue du client mais aussi du point de vue du fournisseurde service. Cette étape permet de mettre en évidence ce que les clients espèrent avoircomment résultats et la mesure dans laquelle ils aimeraient l’obtenir.

Définir les niveaux de services : Le troisième facteur concerne la détermination d’unseuil minimum de niveau de services qui doit être maintenu dans le cadre du contratde service. Cela revient à garantir un minimum de qualité dérivée des besoinscapturés dans la première étape. Il est aussi possible de planifier des actions decorrection en cas de diminution de la qualité de service.

Déterminer la responsabilisation : Enfin, le quatrième et dernier facteur consiste àclarifier les responsabilités que chaque partie, clients et fournisseurs, doit assumerdans tous les cas de figure. Cette prise de responsabilité typique des contrats formelspassés entre deux entités distinctes permet de définir en avance le comportement dechaque partie et de réagir plus rapidement face à l’imprévu.

Le développement des SLA

La gouvernance SOA est responsable de la gestion du cycle de vie des SLA. Cela veut direqu’elle est responsable pour le développement des processus de création et management desSLAs. Dans la Figure 31 on montre l’ensemble des étapes identifiées dans [Maurer, Matlus etal. 2000 p. 18] pour développer et gérer les accords de niveaux de services. Comme on peut leconstater, la seule étape concernant le développement d’une SLA doit prendre enconsidération les différents facteurs décrits ci-dessus, à savoir les besoins des clients, leursobjectifs, les niveaux de services et la responsabilisation. Au même temps, cette figure montrecomment les processus de développement et management partage la plupart des étapes maisen portant un regard différent envers chacune d’elles. En effet, du point de vue dudéveloppement, les quatre dernières étapes sont utilisées pour définir le contenu des SLA quipermettra surtout de mesurer les activités des services et d’examiner ces résultats pour réduirel’impact des erreurs. Cela peut être considéré comme une gestion des métadonnées des SLAs.Par contre, pour le processus de management ces quatre dernières étapes sont effectivementexécutées dans le but de tirer des statistiques sur le comportement des services et définir desnouvelles stratégies.

Un facteur aussi important que les processus que l’on vient de mentionner est celuiconcernant le contenu global des SLA. Pour la gouvernance SOA, il est important de définirun standard de contenu se référant aux SLA afin de réduire les risques d’édition (manquecertaines infos, trop d’information, etc.) lors de l’élaboration d’une SLA. Dans ce contexte,plusieurs éléments sont importants aux yeux de la gouvernance Design-Time, notamment lesinformations concernant la disponibilité, la qualité, et la performance des services ainsi quela qualité du support et de la stratégie de communication.


Figure 31: Processus de développement et management des SLAs [Cf. Maurer, Matlus et al. 2000 p. 18].

Généralement, la disponibilité est un concept qui exprime les besoins de base des clients quiest celui d’avoir le service disponible au moment précis et à l’endroit voulu. Malgré lasimplicité de ce concept, l’interprétation de la disponibilité peut poser des problèmes surtoutlorsqu’on sait que SOA est hautement distribuée et que la fourniture d’un service peutdépendre d’une multitude d’éléments. En effet, la disponibilité d’un service peut être partiellelorsque l’état du service est « disponible » mais que certains éléments rencontrent desproblèmes, comme par exemple, lorsqu’un groupe de clients n’ont pas pu accéder au serviceou certains composants réseaux ne fonctionnent pas. D’autres détailles de disponibilitédevraient être clarifiés lors de la signature des accords de services. Par exemple, comment leclient considère-t-il une augmentation sensible du temps de réponse. Si l’on a affaire à unservice qui est 100 % disponible mais que les autres services dont il dépende ne le sont pas,quel est le degré de disponibilité dans ce cas.

La qualité d’un service est une mesure d’agrégation de l’ensemble des paramètres clés définisdans le SLA. Elle permet par exemple d’avoir une idée claire sur le comportement généraled’un service concernant le temps de réponse, la disponibilité temporelle et physique et lesfréquences d’erreurs. L’autre aspect de contenu SLA est celui de la notification desévénements et de la structure de communication entre les différentes parties. Lacommunication est un concept aussi important que la disponibilité car elle permet de fixer lesflux d’information entre les différentes parties. Un exemple de procédure de communicationlié directement au contenu SLA est l’escalation des problèmes vers les niveaux de support


plus élevés. On peut imaginer qu’une SLA est un bon candidat pour fixer en avance lesinterfaces de support (département, personnes de contact, etc.) ainsi que les responsabilitésquant à la prise en charge des consommateurs du service.

GouvernanceDesign-Time

Time Frame (Availability): Web Services are to beavailable 24 hours per day, Sunday throughSaturday, excluding client-defined national holidays.

QoS : Response errors in less than 1 percent of

connections.

Responsiveness : Less than one second.

Responsabilities :The server is owned by theservice provider, and located on provider’s site.

Metadata and content SLA

Repository

Notification errors

ServiceManager

Web Services

Figure 32: Gouvernance Design-Time des SLA [Cf. webMethods 2005, p. 5]

Dans la Figure 32 on montre un exemple de gouvernance Design-Time consistant à définir leformat d’une SLA. Dans un premier temps un gestionnaire de service fixe le contenu standarddes accords de niveaux de service qui seront appliqués à un groupe de services web. Les SLArésident dans le référentiel (Repositories) et pointent vers les services concernés. Malgré laparticularité de chacune des SLA, l’utilisation des métadonnées permet de garantir un contenuconsistant à l’échelle de l’entreprise. Il est aussi possible de configurer le SLA d’un servicespécifique nécessitant, par exemple, l’implémentation des contrôles de sécurité tels que lesmécanismes d’identification et de contrôle d’accès.

Il est évident que dans le cadre d’un seul travail il est impossible de couvrir toute l’extensionde la gouvernance Design-Time dont la portée va au-delà de ces aspects de design haut niveauet de design détaillé. Les phases d’implémentation telles que le développement descomposants du service (Servlets, EJB, etc.), la réalisation des tests de qualité et opérationnelset le déploiement des services font aussi partie des activités visées par la gouvernance Design-Time. A cela s’ajoute les processus de gestion liés aux politiques de gouvernance quis’étendent à travers tout le cycle de vie des services permettant de contrôler les multitudes derelations dont peut faire l’objet un service donné.

Comme la phase de Run-Time est très centrée sur l’application des politiques de gouvernance,on a expressément réservé cette section pour développer plus en détails le sujet des politiquesdans un environnement faiblement couplé, flexible et rapide comme celui de SOA.


4.4.2 La phase de « Run-Time »

Après les étapes de développement et déploiement, les services se trouvent dans unenvironnement opérationnel où ils vont être exploités par d’autres applications et services.Lorsque l’on a introduit le sujet des architectures orientée services dans la section 3 on a puconstater que SOA est caractérisée, d’une part, par une infrastructure déjà connu, comme celleconstituée des serveurs d’applications, mainframe, et autres composants. D’autre part, elleajoute d’autres éléments nouveaux, tels que les moteurs d’orchestration et les ESB quiauparavant étaient employés dans des contextes d’utilisation spécifiques. En plus, en fonctiondu modèle du service, celui-ci peut résider dans une ou autre couche de l’architecture et êtreen relation avec plusieurs composants internes et externes au domaine auquel il appartient.Par conséquent, plusieurs questions se posent lorsque les services sont exécutés dans unenvironnement si complexe comme celui de SOA. Par exemple, on peut se demander :

Comment peut-on être sûr que les différents composants d’un service (WSDL, SLA,XSD, SOAP, etc.) sont utilisés comme prévu ?

Comment gérer le flux des messages échangés par les services ?

Comment déceler les problèmes de performance, de fiabilité et de sécurité ?

Trouver des réponses aux questions de ce type est justement le domaine de compétence de lagouvernance Run-Time qui se focalise sur plusieurs activités de gestion de services, à savoirle monitoring des contrats, la gestion des processus métier, l’implémentation de la sécuritédes messages et la gestion de la qualité (QoS).

Politiques de gouvernance

Sachant que dans un contrat de service le rôle des interfaces est celui de décrire les capacitésfonctionnelles ainsi que les messages et les protocoles de communication, SOA a besoin d’uncomposant supplémentaire qui permette de décrire comment les consommateurs doivent« converser » avec le service. En effet, grâce aux interfaces du service le consommateur estinformé sur les capacités fonctionnelles de celui-ci ainsi que des contraintes relatives auxmessages qu’il doit lui envoyer et ceux qu’il recevra en retour. Cependant, ces informations selimitent à décrire ce qu’un service est capable de faire tout en omettant les aspects de sécuritéet de qualité des services. Dans le but de combler ces défauts c’est qu’interviennent lespolitiques de gouvernance.

Dans [Ritu and Latha 2008, p. 26] on définit le concept de politique comme étant ;

« a mechanism to configure a behavior of software in ways that are not predictable at policydefinition time».

Les politiques, dans leur forme la plus élémentaires, sont considérées comme des simplesrègles et des contraintes permettant de dicter la manière dont une application ou un servicedoit se comporter. Les significations les plus importantes se trouvant dans ces définitions sontcelles communiquées par les concepts de règles et contraintes. En effet, pour dicter unepolitique (règle) on procède généralement en suivant deux approches distinctes, à savoir


l’approche procédurale et l’approche déclarative. Dans la première, l’application d’unepolitique est définie par l’occurrence d’un événement précis, suivie d’une ou plusieursopérations à réaliser. Un exemple typique du style procédural est celui représenté par lesclauses « if/else » utilisées dans les langages de programmation. Avec l’approche déclarative,les règles sont exprimées d’une manière plus générale qu’auparavant, ce qui permet de direquelles actions doivent se réaliser ou pas. Une liste blanche de sites web peut être vue commeun ensemble de règles déclaratives qui clarifient quels sites web peuvent être visités. Par lamême occasion, elle interdit l’accès aux sites ne se trouvant pas dans cette liste d’accès.

Quant aux contraintes, il s’agit d’un concept très proche de celui de règle mais qui a uneconnotation beaucoup plus négative. Lorsque l’on exprime une politique sous la forme d’unecontrainte c’est parce que l’on veut déclarer les limites physiques et logiques dont fait l’objetune ressource donnée. Cette dimension est en fait très importante dans le contexte de lagestion des services car elle permet de paramétrer plus facilement leur contexte d’exécutionainsi que les propres performances du service.

L’autre terme définissant précisément ce qui est une politique est celui de « mécanisme ». Eneffet, lorsque l’on se réfère aux politiques comme étant des mécanismes on veut dire par làqu’elles doivent être dynamiques plutôt que statiques. C’est d’ailleurs sur ce point que se situela différence principale entre un paramètre de configuration et une politique de gouvernance.Avec le premier, on peut paramétrer le comportement d’une application ou d’un dispositifdonné en lui passant des valeurs connues au moment de la configuration du système. Pourqu’une telle approche se révèle efficace il faut que l’administrateur ait connaissance de tousles variables importantes décrivant le comportement attendu.

Dans le contexte de SOA, cela est loin d’être le cas, surtout dans les environnements où l’on aaffaire à plusieurs clients et fournisseurs de services. Bien qu’il soit toujours possible dedéterminer à l’avance la plupart des scénarios d’utilisation d’un service, la définition desmécanismes (système de politiques) est une approche beaucoup plus efficace que laconfiguration des valeurs statiques. Sans exclure l’utilisation des paramètres de configurationstatiques, la gouvernance SOA fait un usage exhaustif des systèmes de gestion de politiquespour garantir la flexibilité de l’architecture et des services SOA.

Dans le domaine de la gouvernance SOA on distingue plusieurs types de politiques parmilesquelles on peut citer: Les politiques de sécurité qui règlent les aspects de confidentialité,intégrité et contrôle d’accès, aussi bien au niveau de la couche de transport que de la couchedes messages. Les politiques de routage permettant de gérer le flux des requêtes entrant etsortant pour garantir ainsi que les demandes adressées à un service sont en conformité auxpolitiques d’utilisation. Les politiques sur les niveaux de services qui concernent tous lesaspects de la qualité d’un service comme la performance, la fiabilité, la disponibilité et letemps de réponse. Ces politiques étant très souvent référencées dans les SLAs, les OLAs etenfin dans les contrats de sous-traitance. Indépendamment de ces types de politique, il estnécessaire de disposer d’une infrastructure permettant d’implémenter, déployer et maintenirles politiques de services SOA. Le besoin fondamental pour gérer efficacement les politiquesest celui du couplage faible vis-à-vis des couches de services. Autrement dit, de la mêmemanière que l’on découple les SLA et les interfaces des implémentations d’un service, on doitdécoupler aussi la gestion des politiques de gouvernance. Pour ce faire, SOA s’inspire des


systèmes de gestion de réseau basés sur les politiques dont l’architecture est illustrée dans laFigure 33. Comme on peut le voir, il s’git d’un système composé d’une interface utilisateur(console ou graphique) qui permet de définir et de modifier les politiques de services d’unemanière complètement découplée et flexible. En effet, lorsqu’un Service Manager désire créerou modifier une politique, il peut se connecter à l’interface « Policy Mangement » poureffectuer les changements dans une approche déclarative, sans besoin d’ajouter du code deprogrammation. Ensuite, il peut stocker les politiques dans la base de données « PolicyRepository » qui peut aussi exister sous la forme d’annuaire LDAP. Le moteur de traitementdes politiques est représenté par le composant « Policy Decision Point (PDP)» qui instancie,analyse et exécute les règles contenues dans le composant « Policy Repository ». Après letraitement d’une politique donnée, le PDP communique son résultat (sa décision) au « PolicyEnforcement Point (PEP)» pour que ce dernier puisse renforcer son application auprès desclients et fournisseurs de service. Toutefois, le PEP peut aussi consulter directement leRepository sans passer par le serveur de politiques (PDP).

Policy EnforcementPoint

Policy Mangement

Services Layer

Policy Decision PointPolicy Repository

?

Figure 33: Gouvernance Run-Time basée sur les politiques [Cf. Ritu and Latha 2008, p. 31].

Avec un modèle de gestion des politiques comme celui de la Figure 33 la gouvernance Run-Time peut garantir la conformité des requêtes aux contrats de services définis entre les clientset fournisseurs. Chaque demande de service arrivée au PEP est comparée aux paramètresdéfinis dans le SLAs correspondante, ce qui permet de déterminer s’il s’agit d’une requêtevalable au niveau de chaque élément d’un contrat de service (politiques, SLA et interface).

La qualité des services par la sécurité

Les services en SOA sont développés pour répondre à des besoins bien précis en termes dequalité de service qui doivent être garantis pendant leur utilisation. Un service qui est sollicité


par une multitude de clients doit fonctionner d’une manière consistante et conforme auxparamètres de qualité qui apparaissent dans son contrat. Généralement, la qualité d’un servicepeut s’évaluer en tenant compte des éléments tels que la performance, la fiabilité,disponibilité et la sécurité. Pour garantir que chacun de ces éléments se trouve dans un étatvalable, la gouvernance Run-Time est chargée d’implémenter les processus de gestion surlesquels sont basés la sécurité, le monitoring des processus et la résolution de problèmes liée àl’exploitation des services.

La gestion de la sécurité SOA est un domaine qui est pris en charge par la gouvernance SOA.En effet, dans la phase Run-Time on implémente les stratégies de protection des services quiont été définies dans le cadre de la gouvernance TI et pendant la phase Design-Time. Pour cefaire, elle peut déployer les stratégies de sécurité sur plusieurs niveaux de l’architecture,notamment au niveau des protocoles de transport et au niveau des messages. La gouvernanceRun-Time doit donc implémenter les politiques d’authentification et d’autorisation destinéeaux services SOA, ce qui oblige à prendre de décisions importantes concernant lesmécanismes d’identification des utilisateurs. En principe, SOA utilise les mécanismesd’authentification existants comme par exemple, l’authentification via les certificats de lanorme X.509, l’authentification dite de base utilisant un nom d’utilisateur et un mot de passe,le protocole Kerberos d’authentification d’utilisateurs et des services à l’intérieur d’undomaine spécifique et le standard SAML basé sur XML.

En plus des décisions concernant les mécanismes d’identification on doit tenir compte desbesoins de confidentialité et d’intégrité de messages qui sont échangés entre les différentesparties. Comme pour l’authentification et l’autorisation, il existe aussi plusieurs mécanismesde sécurité qui sont utilisés pour protéger le contenu des messages. Parmi ces mécanismes onpeut mentionner la signature des messages XML qui supporte l’intégrité de ces derniers ainsique l’authentification de son émetteur. Le chiffrement des messages XML qui sert à garantirla confidentialité des messages en cachant son contenu par l’application des algorithmes dechiffrement. Tant l’authentification comme la confidentialité et l’intégrité des messages peutêtre implémentée en partie par les protocoles de transport sécurisés tel que SSL. En effet, ceprotocole offre les services de sécurisation de messages mentionné ci-dessus mais il estdépendant du protocole HTTP, ce qui n’est pas recommandé dans un environnement commeSOA qui admet d’autres types de protocoles (SMTP, FTP, etc.).


Gateway

Consumer A Consumer C

LDAP

Consumer B

Firewall

MessageDelivery

MessageDelivery

Services Services

SSL, XML encryptionand signature

XML validation

Figure 34: Gouvernance Run-Time dans la gestion de la sécurité des services.

La Figure 34 montre un exemple de gouvernance Run-Time dans le contexte de la sécurité desservices web. Il s’agit d’un exemple typique d’implémentation de la sécurité où troisconsommateurs envoient des requêtes aux services web résidant dans une SOA. Leconsommateur « A » envoie une requête avec un message SOAP qui est intercepté par uncomposant intermédiaire (Gateway) capable de faire appliquer les politiques de sécuritérelatives aux services web. Dans cette passerelle on a défini une politique concernant surtoutla validation des messages provenant de ce type de consommateur. Si le message s’avèreconforme aux contraintes de validation alors il est autorisé à communiquer avec le fournisseurdu service et le message est délivré à sa destination. Dans le cas du consommateur « B », lemessage n’a pas atteint sa destination et a été effacé parce qu’il ne correspondait pas auxexigences de sécurité. Cela peut survenir par exemple lorsque le consommateur envoi unerequête via un autre canal que celui attendu par le point terminal. La passerelle se charge alorsde renvoyer une réponse Soapfault pour notifier les problèmes survenus ou tout simplementsupprimer la connexion. Au niveau du consommateur « C », la politique de sécurité consiste àcombiner l’envoie d’un message encrypté et signé via WS-Security et transporté par leprotocole SSL. Comme dans les cas précédents la passerelle s’assure que les conditions desécurité sont bien remplies et route les messages vers le destinataire de la requête.

Bien que dans la description cela ressemble assez évident, il faut compter sur l’occurrence decertaines conditions pour pouvoir appliquer les politiques de sécurité comme il a été fait ci-dessus. En effet, l’architecture basée sur une passerelle de sécurité fait souvent appel auxcomposant PEP et PDP mentionnées auparavant car en SOA la sécurité est gérée sous formede politiques. Donc, grâce aux systèmes de gestion de politiques on peut faire appliquer lescontraintes de sécurité aussi bien aux fournisseurs qu’aux consommateurs. A cela s’ajoute le


fait que dans le contexte distribué des services on peut rencontrer un grand nombred’intermédiaire avant que le message n’arrive à destination. Dans une situation idéale, lesconsommateurs et le fournisseur communiquent en « point-to-point » mais la plus part dutemps cela n’est pas possible et la sécurité doit être conservée « end-to-end ». Parconséquence il est important d’implémenter la sécurité de telle manière que le contexte desécurité des messages ne soit pas perdu et l’échange d’information se fasse comme prévu dansle SLA.

L’implémentation de la sécurité peut encore devenir plus complexe, notamment avecl’intégration de services de processus appartenant à des organisations différentes. Lorsqu’unconsommateur provenant de l’extérieur envoie une requête à un service on doit faire en sorteque ses attributs de sécurité restent transparents aux différents partenaires. Autrement dit, ilfaut pouvoir identifier le client pour établir une relation de confiance dans le partage de cesinformations, tout cela malgré les différences dans les modèles de sécurité de chaqueorganisation concernée. Dans ce cas le défi est d’implémenter la portabilité des attributs desécurité à travers les différents partenaires concernés. Par exemple, à l’aide du standardSAML et d’une passerelle comme celle illustrée dans la Figure 34.

La qualité des services par la performance et la fiabilité

Depuis la perspective de la gouvernance Run-Time la qualité des services doit être garantie engérant les aspects de performance et de fiabilité des services. La performance d’une SOA doitêtre évaluée à plusieurs niveaux, notamment au niveau des processus métier, au niveau desdifférents modèles de services et au niveau des applications sous-jacentes. Dans le cas desservices de processus, les problèmes de performance se trouvent au niveau de la compositionde services car dans un contexte comme celui-ci la charge de traitement est normalement plusélevée qu’avec un service simple.

Un bon modèle de gouvernance doit s’intéresser aux compositions de services depuis la phasede Design-Time pour éviter qu’un modèle de composition inefficace n’ait des répercussionsen temps d’exécution (Run-Time). Par exemple, des services à granularité anormal, trop demembres dans une composition et un nombre important d’opérations (validation,transformation, etc.) exécutées par chaque membre, peuvent diminuer de manière sensible lesperformances d’un service de processus. Quant aux services d’application présentés dans lasection 2.2, la performance doit être analysée en tenant compte des applications et systèmessous-jacents. Ici, les problèmes de performances peuvent surgir des sources de donnéesutilisées par les applications sous-jacentes. Autrement dit, si les opérations dans les bases dedonnées deviennent trop lentes, les services d’application seront aperçus comme étant aussilents que les applications qu’ils exposent, surtout dans les échangent synchronisés.

La performance dépend aussi de la quantité de données contenues dans les messages. Si pourdes questions de sécurité on doit inclure dans un message un grand nombre d’informationssupplémentaires, il est clair que le traitement du message prendra beaucoup plus temps qued’habitude. Le même problème peut venir des données attachées aux messages, ou den’importe quelle autre approche susceptible d’augmenter la taille des messages. Par rapport à


ces derniers on peut encore dire qu’un volume trop important de messages peut avoir desincidences négatives sur la performance de l’architecture.

Or, face à ces nombreux risques, que peut faire la gouvernance Run-Time pour conserver laperformance de SOA ? La première réponse à cette question consiste à développer unprocessus de gestion de la performance comme celui de la Figure 35. Dans cette dernière onillustre un processus défini dans le cadre du Framework ITIL qui contient les étapesnécessaires pour mesurer la performance d’un système ou d’un service informatique. Lapremière étape, à savoir celle du contrôle, peut en effet être implémentée dans SOA par lemonitoring des services. Les résultats ainsi obtenus sont ensuite analysés (étape 2) pourextraire les signaux ou les données clés qui permettent de détecter les problèmes liés àl’utilisation des services. Dans la troisième étape il s’agit de définir les différentes solutionsapplicables aux problèmes en question. Enfin, dans la dernière étape qui est celle de la miseen œuvre on implémente les solutions prédéfinies auparavant.

Figure 35: Processus de gestion de la capacité [Cf. Macfarlane and Rudd 2006, p. 55]

D’une manière plus concrète, le processus décrit ci-dessus n’est autre chose qu’un processusde monitoring permettant de gérer et de mesurer la performance d’un système informatique.Dans le cadre de SOA, on utilise aussi le monitoring à plusieurs niveaux de l’architecturecouvrant ainsi presque tous les domaines de celle-ci. Le monitoring étant un exerciced’observation et d’analyse de l’activité d’un système il représente une bonne solution pourdéceler les problèmes de performance posés par les services et par SOA en générale. Donc,pour mieux maîtriser l’ensemble des activités dans une architecture orientée services, il estimportant de pouvoir déterminer les « points d’observation » les plus pertinents où lemonitoring sera effectué. Dans SOA, le monitoring est pratiqué en suivant plusieursapproches différentes et complémentaires. La supervision des activités métier (BusinessActivity Monitoring) est un exemple de monitoring que l’on peut utiliser dans le cadre de lagouvernance Run-Time. Bien qu’il s’agisse d’un concept très différent, il est cependant trèsproche de SOA grâce au lien qu’il garde avec les services de processus. Concrètement cela


consiste à étudier de près les processus métier en collectant des informations provenant dessystèmes d’information concernés par ces processus [Pulier and Taylor 2006, p. 91]. Lesmesures collectées au niveau des processus métier sont interprétées au même niveau, cet-à-dire, au niveau des indicateurs de performance métier. En fonction des résultats mesurés, lespropriétaires des domaines SOA peuvent ensuite définir des actions pour optimiser laperformance des services.

Un autre point d’observation ayant une importance certaine dans la mesure de la performanceSOA est notamment le message lui-même. En analysant le flux de messages on peutdéterminer, par exemple, le nombre de messages traités avec succès dans un intervalle donné,le nombre des messages perdus, la capacité de traitement des plateformes (passerelles,services intermédiaires, etc.) déployées à travers l’architecture et la taille des requêtes et desréponses. Le monitoring des messages est utilisé aussi bien en Design-Time qu’en Run-Time.Cette solution est typiquement implémentée au moyen d’une passerelle applicative ayant lescapacités de lire le contenu des messages transitant par le réseau. Elle peut ainsi différencierles messages en fonction de leur contenu, destination et autres paramètres servant à maintenirune statistique sur l’activité des messages et l’utilisation des services.

Le monitoring des services SOA n’est qu’une première étape dans la gestion de laperformance qui permet d’implémenter l’ensemble d’indicateurs clés de performance. Dans lecas de la gouvernance Run-Time ces indicateurs peuvent informer sur l’état actuel d’unservice, notamment quant à sa disponibilité, le niveau de réutilisation et les niveaux deservices en générale (SLA monitoring). Pour bien gérer ces indicateurs on utilise un tableaude bord contenant les indicateurs spécifiques à SOA montrant les différents niveaux deperformance en temps réel. C’est donc sur la base de ces résultats que la gouvernance Run-Time peut décider des actions à mener, comme celles utilisés dans les domaines tels que larépartition des charges (load balancing ), le « SOA virtualization » et le re-deployment,permettant d’optimiser continuellement la performance.

86

5Etude de cas « e-dec »

Grâce au travail théorique réalisé jusqu’ici on a pu aborder les différents concepts gravitantautour de la gouvernance SOA, plus particulièrement de la gouvernance du cycle de vie desservices. Cependant, dans un scénario réel, après avoir défini d’une manière adéquate leFramework de gouvernance SOA, chacun de ces concepts sont implémentés dans une solutionconcrète et fonctionnelle. L’étude de cas « e-dec », présenté ci-après, permettra de consoliderces connaissances théoriques par une approche pratique de la gouvernance SOA qui seconcrétisera dans le développement d’un prototype.

L’événement déclencheur motivant le développement de la plateforme « e-dec » est lié aunombre croissant du trafic des marchandises enregistré à partir de l’année 2000. Cela est bienconfirmé dans les statistiques des offices de douane publiées dans [AFD 2003] où l’on peutconstater une augmentation passant de 6 millions de déclaration en 1990 à 11 millions en2003. La même tendance s’est poursuivi toutes ces années jusqu’à les chiffres les plus récentspubliés cette année dans [AFD 2007] qui se réfèrent aux 14.4 millions d’importationsenregistrée pendant l’année 2007 (voir le graphique ci-dessous).

Figure 36: Nombre de déclarations (en millions) pendant la période 1995 au 2007. Graphique publié dans

[AFD 2007, p. 23].

Au même temps, les bureaux de douanes ont dû traiter un flux de 570’000 personnes et de350'000 voitures qui sont entrées en Suisse. En plus, les poids lourds transitant par lesdouanes a atteint le nombre de 20'000 camions en 2007 et la quantité de dédouanement parjour a été d’environ 76'000 unités. Tous ces chiffres tirés de [AFD 2007, p. 36] montrentfacilement le dynamisme croissant des activités douanières, qui avant l’année 2003 étaitsupporté par l’ancien système MD90, et que dès lors sont supportées par la plateforme dedéclarations électroniques appelée « e-dec ».

Etude de cas « e-dec » 87

Afin de faire face à ces changements, l’Administration fédérale des douanes (AFD) et l’Officefédéral de l'informatique et de télécommunication (OFIT) ont apporté plusieurs améliorationsau modèle MD90 jusqu’au moment où ce dernier s’est montré insuffisant, ce qui a mis enévidence le besoin de disposer d’un nouveau système adapté aux nouvelles exigences. Voicideux extraits des textes publiés sur le site web de l’AFD décrivant l’état de MD90 ainsi queles différents problèmes posés par cet ancien modèle. Tout d’abord du point de vuetechnique on peut lire ceci :

« Depuis son introduction, le modèle douane 90E a été régulièrement complété defonctions ponctuelles, mais n'a jamais été entièrement revu ou re-conçu. Avec le temps etles volumes croissants – la valeur des importations a augmenté de 34 pour cent entre 1990et 2003 et les exportations même de 53 pour cent -, le modèle douane 90E n'arrivait plus àsatisfaire les exigences. La technique était obsolète, l'environnement avait changé,l'application n'était pas suffisamment flexible, la maintenance devenait de plus en plusonéreuse. Le moment était venu de faire le point ».

Ensuite, on constate que ce qui était sensé d’apporter des solutions est devenu aux yeux desutilisateurs un nœud d’applications distinctes empêchant la réalisation d’un travail efficace.Dans ce contexte l’AFD décrit ce que suit :

« Les évolutions politiques, juridiques, technologiques et économiques de ces dernièresannées ont fait que l'Administration fédérale des douanes dispose actuellement d'une trèslarge palette de produits visant le même objectif, à savoir le dédouanement desmarchandises. Cette palette comprend diverses solutions fondées sur des formulaires ainsique des solutions informatiques pour l'importation, le transit et l'exportation demarchandises ».

En conclusion, le nouveau système de déclaration d’importations et exportations devait êtretechniquement adapté aux environnements actuels du B2B mais aussi être capables d’apporterde vraies améliorations au niveau des processus métier.

5.1 Motivations de la plateforme « e-dec »

Le projet de déclaration électronique « e-dec » est né du besoin de remplacer l’ancien systèmeMD90 qui est devenu très complexe par le nombre élevé de solutions logicielles senséssoutenir les activités (importations, exportations et transit) des douaniers et de leurs clients.Donc, les coûts des opérations et de maintenance de MD90 sont devenus trop importantsmontrant ainsi la limite de ce modèle.

En plus du simple remplacement du modèle MD90, le projet « e-dec » a été développé autourdes objectifs suivants :


Standardisation de l’architecture de déclaration électronique en promouvant uneapproche orientée services et l’utilisation des standards d’échange.

Amélioration des processus d’importation et exportation permettant de réduire letemps de traitement des déclarations et les coûts opérationnels.

Améliorer la qualité des déclarations, l’analyse des risques et le monitoring desactivités.

Fournir aux clients de la douane un ensemble de fonctionnalités sous la forme deservices concertés et de base.

Dans le contexte d’e-dec le terme « client » est utilisé pour désigner les importateurs,exportateurs, transporteurs, et autres entités, qui se sont annoncés auprès de l’administrationdouanière en tant que destinataire ou expéditeur agréé. A leur égard la plateforme procure lesavantages suivants :

Meilleure précision dans le traitement des tests de plausibilité et le calcul desredevances

Liste d’importation et bulletin de délivrance disponibles en format PDF

Réception électronique des quittances de douanes et TVA

Support de plusieurs standards de transmission

Taille de déclarations allant jusqu’à 99’999 positions

Etc.

La plateforme « e-dec » participe aussi à la réalisation de bénéfices financiers pour le comptede la Confédération comme on peut le constater dans la Figure 37. Dans ce graphique on voitune nette augmentation des recettes pendant l’année 2006 où la douane a pu encaisser lemontant de 15 milliards de francs suisses grâce aux dédouanements effectués au moyen de laplateforme « e-dec ».


0.0

2'000.0

4'000.0

6'000.0

8'000.0

10'000.0

12'000.0

1995 2000 2004 2005 2006

Impôt sur le tabac

Impôt huiles min. sur les carburants

Redevance trafic poids lourds

Droits d'entrée

Taxe sur la valeur ajoutée

Total autres (sans taxe sur valuer ajoutée)

Figure 37: Recettes encaissées pour le compte de la Confédération [OFIT 2007, p. 6].

Dans cette même année, il y avait 350 clients inscrits générant un trafic de 40'000 à 50'000déclarations par jour dont le temps réponse, par déclaration (réception et réponse), à étéobservé à environ 3 secondes seulement. On a aussi pu observer une montée en charge de 300déclarations à la minute ayant une taille de 1 à 2500 positions.

5.2 Description de la solution « e-dec »

5.2.1 Modèle métier import

Le modèle d’importation implémenté par le système e-dec a été organisé en plusieurscatégories d’exigences fonctionnelles qui définissent les fonctionnalités développées dans cesystème. Chaque catégorie correspond à un paquetage de fonctions ou tâches associées à unsous-domaine spécifique et bien délimité. Chacune de ces fonctionnalités ont été capturées àl’aide de cas d’utilisation qui décrivent, du point de vue métier, les conditions d’utilisation,les résultats de chaque cas, les relations, les priorités, les données, etc.

Figure 38: Délimitation en packages d’e-dec import

Dans la Figure 38 on montre l’ensemble des paquetages de ce modèle métier. Il s’agit en toutde sept paquetages hébergeant des cas d’utilisation isolés. Le paquetage appelé « declaration »


contient les cas d’utilisation liés aux opérations effectuées sur la déclaration d’importation.On y trouve principalement les fonctionnalités suivantes :

Transmettre, sélectionner, saisir et refuser la déclaration d’importation

Transmettre le résultat

Calculer les redevances

Feuille de contrôle

Bulletin de délivrance

Le deuxième paquetage est délimité par les tâches de contrôle qui sont pour la plupartexécutées manuellement et existaient déjà dans l’ancien modèle MD90. En effet, avant ouaprès la déclaration proprement dite, le bureau douanier peut décider de la nécessité deprocéder à un contrôle physique des marchandises. En plus, un transitaire est pour sa part tenude présenter auprès des autorités douanières les justificatifs permettant de retirer lamarchandise. Toutes ces opérations se font manuellement, soit au bureau de douane, soit chezle destinataire agrée et par conséquent il y a très peu d’interaction avec le systèmeinformatique si ce n’est que pour saisir les résultats des contrôles effectués. La mêmeremarque s’applique au paquetage « Release » composé de deux cas d’utilisation, à savoir« libérer l’envoi » et « enlever l’envoi ».

Le paquetage des fonctionnalités d’administration est appelé « backoffice ». On y trouve lescas d’utilisation concernant les collaborateurs de l’AFD, à savoir : la livraison des donnéesstatistiques et des documents échangés avec les transitaires, la correction de la déclaration,l’archivage des justificatifs, établissement et expédition des quittances, perception etremboursement des recettes et libération du traitement.

5.2.2 Architecture et technologies

Les nouvelles exigences métier présentées par l’AFD lors du lancement du projet e-deccorrespondaient parfaitement aux situations pour lesquelles SOA est justifiée. Comment onpeut lire dans [North 2007, p. 13] l’une des sources de valeur de SOA consiste en sonpotentiel à améliorer la productivité des utilisateurs en donnant la possibilité de remplacer unsystème « spaghetti » (lire les commentaires avancés par l’AFD) par une solution intégrée etunique aux yeux des utilisateurs. Par conséquent, e-dec a été conçue, entre autres fins, pourremplacer les nombreux outils servant aux tâches liées aux déclarations électroniques.

Le système e-dec est basé sur une architecture orientée services composés de quatre couchesprincipales qui sont la couche de présentation, la couche de services métier, la couche deservices génériques et la couche de données. La Figure 39 illustre ce partitionnement àplusieurs niveaux qui nous permet de relever quelques remarques importantes.

Tout d’abord, e-dec repose sur une architecture à accès multicanaux qui consiste à offrir auxclients plusieurs moyens d’invoquer les services qu’elle expose à l’extérieur. En effet, unclient peut utiliser le service EdecImportService par l’intermédiaire d’une plateforme de


courrier électronique et peut aussi le faire par l’intermédiaire d’un service web. Dans tous lescas, les clients doivent respecter les formats de messages supportés par les deux canaux, enl’occurrence, le courriel admet XML et EDIFACT et pour le service web c’est sont lesmessages XML.

Figure 39: Architecture « e-dec ». Graphique tiré de [Innotvation Process Technology 2008, p. 10].

Le premier niveau de la Figure 39 est implémenté par un ESB qui se charge de coordonnerune partie des étapes du processus d’importation. Le bus de services contient les servicesgénériques qui ont un fort potentiel de réutilisation. N’importe quel autre projet comme ceuxconcernant l’exportation et le transit des marchandises, peut les réutiliser pour traiter laréception et la réponse des messages. Parmi ces services on trouve :

service de courriel (mail-service),

service d’identification (authentification et autorisation),

service de conversion de messages (EDIFACT / XML),

service d’archivage de données,


service de validation de messages XML,

service de génération des documents de la réponse.

La présence d’un ESB dans cette architecture se justifie par les nombreux avantages de cettetechnologie dans une SOA. En effet, un bus de services est une solution idéale pour résoudreles problèmes des connexions « point-to-point » qui surviennent lorsque l’architecturecommence à se développer et que de plus en plus de services viennent s’y ajouter. Parmi cesdifficultés il y a notamment la multiplication des connexions et les risques de dépendancesphysiques entre le consommateur et le fournisseur de service. Dans le document deprésentation d’e-dec [Innotvation Process Technology 2008] l’auteur met en avant lescapacités d’un ESB à améliorer l’évolutivité d’une SOA, notamment pour offrir des servicessupplémentaires aux clients. Dans l’absence d’un bus de service il faut recourir à la méthoded’intégration traditionnelle en développant les adaptateurs correspondants.

Un bus de service est un middleware capable de rendre transparente la localisation physiquedes services. Il est donc lui-même un service de routage qui joue le rôle d’intermédiaire actifentre les consommateurs et fournisseurs. Grâce à cette transparence de localisationl’autonomie des services est renforcée ce qui permet à chacun d’évoluer de manièreindépendante sans provoquer des changements de configuration du côté des clients. Laqualification « intermédiaire actif » se réfère à un ESB dont la fonctionnalité de routage ne selimite pas au simple transfère de messages et va jusqu’à inspecter le contenu des messages enfonction des politiques préétablies pour ensuite l’acheminer à la destination correcte. En plusde l’abstraction de localisation, un ESB peut aussi fournir des fonctionnalités detransformation des formats de messages (EDIFACT to XML), prendre en charge plusieursprotocoles de transport (HTTP, SMTP, POP3, JMS, etc.) et différents modèles d’échange demessages (synchrone et asynchrone). Cela ne peut que renforcer la qualité des servicesnotamment en rapport avec la fiabilité dans la remise des messages, la disponibilité desservices et le temps de réponse. La gestion des services et de l’infrastructure de l’ESB se faitau moyen d’une console connectée via JMX13 au ESB ce qui permet de configurer etsurveiller le tout de manière centralisée.

Dans le cas d’e-dec, les services sont publiés dans un registre propriétaire accessible via unSonic ESB. Selon les informations dont dispose l’auteur de ce travail il est impossible de diresi le registre est basé sur le standard UDDI. Quoi qu’il en soit, grâce à ce registre, « e-dec »dispose d’un emplacement central pour la publication des services. Au début du projet il étaitprévu de publier EdecImportService dans une zone de services partagée (SSZ) permettantd’effectuer des tâches de monitoring et de sécurité mais cela n’a pas été fait. Le serviced’authentification et d’autorisation est basé sur un mécanisme centralisé de control d’accès detype LDAP. Ce faisant un utilisateur n’a pas besoin de s’identifier plusieurs fois pour utiliserl’ensemble des services ce qui serait très fastidieux dans un environnement distribué commeSOA. Or, l’implémentation de SOA avec un ESB peut être complétée avec une passerelle desécurité et de routage complètement découplée de l’ESB. C’est justement l’intention duprototype de gouvernance qui est proposé dans ce travail. Il permettrait de développer les

13 JMX est une API basée sur Java pour la gestion runtime des ressources matérielles et logicielles


activités de SLA monitoring pour le compte des transitaires et du service web. En plus,comme service intermédiaire, une telle passerelle permettrait de déléguer les traitements desécurité et de transport comme par exemple, la conversion des requêtes JMS en requêtesHTTP, l’ implémentation d’un service d’authentification unique (SSO) et le contrôle d’accès(requête et réponses) dans les contextes d’intégration avec d’autres partenaires.

Le noyau de la plateforme « e-dec » est constitué d’un ensemble de services métier (businessservices) supportés par une couche métier de type J2EE. Ces services sont spécifiques auprocessus d’importation et pour cette raison ils ont un potentiel de réutilisation inférieur auxservices d’application présentés auparavant. Voici la liste des services métier de la plateformee-dec:

Service de sélection,

Service de calcul des redevances,

Service de test de plausibilité et service de quota.

Cette division en services métier et services d’application correspond tout à fait à ladescription de l’architecture SOA de la section 3.2. En effet, le service EdecImportService estun service de processus qui est spécifique au dédouanement des importations. Il compose parcontre une série de services de base (services d’application ou de support) dans un fluxd’orchestration supporté par la couche ESB. Bien que la Figure 39 ne le montre pasl’interaction entre les services du ESB et ceux de la couche métier se fait par l’intermédiairedes APIs JCA14 et JMS de Java. Grâce à l’interface JCA, qui sert à rendre plus transparentl’interaction entre un composant J2EE et le bus de service, EdecImportService compose leservice d’archivage qui enregistre à son tour la déclaration d’importation. Ensuite, l’interfaceJMS permet au service basé sur la technologie EJB orienté message de communiquer lui aussiavec l’ESB.

14 JCA était planifiée dès le début mais les sauvegardes de données ne sont que de simples opérations d’écrituredans un file system.

94

6Implémentation du prototype « e-

dec Governance »

6.1 Objectifs du prototype « e-dec Governance »

De la présentation de l’étude de cas « e-dec » on peut tirer une remarque importante sur lazone de service partagée (SSZ) où le service EdecImportService est publié pour l’accèsexterne. En effet, cette zone représente une couche complémentaire à celle présentée dans lasection Architecture et technologies contenant les composants d’implémentation tels que lesystème ESB et le serveur d’application.

La SSZ est une plateforme centralisée, déployée pour la publication des points terminaux et laprise en charge des tâches telles que le monitoring des messages et la sécurité des services[Innotvation Process Technology 2008, p. 14]. On peut dire donc que la plateforme « e-dec »est déjà équipée d’un outil de gouvernance Run-Time qui est supporté par cette couche deservices partagée. Cette dernière fonctionne comme un proxy pour les services web qui serontutilisés depuis l’extérieur, mais elle permet aussi de capturer le trafic de messages entre leservice EdecImportService et les transitaires afin renforcer l’application des politiques desécurité et de superviser ainsi le comportement des services.

Le prototype que l’on veut implémenter dans ce travail joue le même rôle que la SSZ de laplateforme « e-dec » à différence qu’il offre plus de capacités dans le traitement des messageset le renforcement (enforcement) des politiques de gouvernance. Notons qu’en principe cesdeux solutions servent à la même chose (monitoring, sécurité, etc.) mais cela ne revient pas àcréer des doublons de fonctionnalités aussi longtemps que l’on adapte leur déploiement demanière à ce que chacun se limite au rôle qui lui est réservé.

Quoi qu’il en soit, le prototype e-dec Governance est réalisé dans un esprit de rechercheexpérimentale afin d’atteindre les objectifs suivants :

1. Consolider les connaissances théoriques présentées tout au long de ce travail ensuivant une approche pratique et proche de la réalité.

2. Implémenter un ensemble de politiques de gouvernance SOA capables de satisfaire lesbesoins d’un service web, en l’occurrence EdecImportService.

3. Présenter et décrire l’outil de gouvernance SOA « SecureSpan Gateway » utilisé pourl’implémentation de solutions de gouvernance à grande échelle, notamment dans le

Implémentation du prototype « e-dec Governance » 95

but de comprendre les forces et les faiblesses d’une solution logicielle typiquementutilisée dans SOA.

Pour ce faire on prêtera une attention particulière aux domaines de la gestion des politiques etdes contrats sur les niveaux de services à l’aide de mécanismes de gouvernances tels que lePolicy Enforcement et SLA monitoring.

6.2 Exigences et besoins

Dans le cadre de ce prototype on a choisi comme point de départ le contrat de service (voirl’annexe Artefacts) déjà existant entre les clients de la plateforme « e-dec » et le service webEdecImportService. Le contrat de service est un document formel [Hüsemann and Rischbeck2007] rédigé par le fournisseur du service, en l’occurrence l’OFIT et l’AFD, réglant tous lesdétails techniques et de niveaux de service qui sont importants pour l’ensemble desutilisateurs.

A partir de ce qui est décrit dans ce document on a identifié les exigences décrites ci-après.Au niveau de la sécurité du service web EdecImportService la première condition imposée parl’AFD consiste à demander une autorisation préalable auprès de la plateforme « e-dec » pourque le client soit reconnu en tant qu’importateur agrée. Cette démarche est la première étapeservant à gérer l’identité des futurs clients qui est utilisée à chaque fois qu’ils accèdent auservice EdecImportService.

Pour effectuer l’authentification, le système « e-dec » utilise une méthode d’authentificationforte consistant à utiliser un certificat numérique, délivré par une autorité de certification del’Office fédéral de l’informatique et de la télécommunication (OFIT). Ces certificats sontutilisés avec le protocole SSL en mode mutuel pour authentifier les deux entités (transitaireset e-dec) engagées dans la communication. C’est l’OFIT elle-même qui assure l’existence del’infrastructure PKI nécessaire à la gestion des certificats X.509 v3 laissant aux clients le soinde les installer dans leurs magasins de certificats (trust store).

Les services de confidentialité et d’intégrité des messages SOAP est donc assuré par la miseen place d’un canal SSL sécurisé entre le transitaire et le service web. La confidentialité estgarantie par les mécanismes de cryptage supportés par ce protocole dès l’instant où lacommunication est établie. L’intégrité est assurée par les mécanismes de signature aussi offertpar le protocole SSL. Par contre, aucune contrainte au niveau de la sécurité des messages n’aété imposée aux transitaires.

Les exigences de qualité de service (QoS) sont définies dans une section SLA du contrat deservice global. Il s’agit d’un ensemble de points qui s’appliquent à tous les transitaires etclients d’e-dec, ce qui veut dire que le service EdecImportService ne réserve pas de traitementspécial pour un type de client donné. Cette SLA tient surtout compte des aspects dedisponibilité et de performances suivants :

Disponibilité (Uptime): Le service doit être disponible 24 heures sur 7 jours àl’exception de deux heures par semaine réservée à la maintenance. Pour dégager le


pourcentage de disponibilité réel on peut utiliser la formule proposée dans leFramework ITIL, plus précisément dans son module de « Availability Management »[Macfarlane and Rudd 2006, p. 41]. Dans cette formule on prend on compte troisparamètres fondamentaux, à savoir les heures de services et le temps d’arrêt et ladisponibilité. Dans le cas d’EdecImportService la disponibilité est établie au niveau de99,5%. Sachant que les heures de services sont de 24 heures * 7 jours (D) et que leservice sera interrompue pendant 2 heures par semaine (DT), alors la disponibilité réelrevient à un niveau de 98.8%.

o FORMULE : Disponibilité réel = ((D—DT)/ D) * 100

Indisponibilité ou temps d’arrêt (Downtime): Un délai de 5 minutes est réservé pourrétablir le service. On doit noter que l’indisponibilité est une notion plus complexequ’elle ne paraît car dans sa composition on trouve des éléments comme les délaisd’identification de problèmes, de réaction et de maintenance, ainsi que le tempsd’établissement du service.

Temps de réponse: En situation normale (20 déclarations par minute) le service assureune performance de 95% en dessous de 10 secondes et de 99% en dessous de 15secondes. Dans une situation extrême où le service doit traiter 170 déclarations parminute, la performance est de 95% en dessous de 20 secondes et de 99% en dessousde 60 secondes.

Fiabilité: Aucune garantie n’est assurée pour la fiabilité des échanges. En casd’interruption de service il appartient aux clients de procéder à une nouvelletransmission de la déclaration d’importation.

Le contrat de service fait aussi référence à un ensemble d’artefacts tels que les schémas XMLdéfinissant la déclaration d’importation, les réponses d’acceptation ou de refus et l’interfacede description du service (WSDL). Dans le contexte des politiques de sécurité, il est importantde tenir compte de ces différents éléments car ils peuvent être utilisés pour protéger le serviceweb de certaines menaces provenant de l’extérieur, notamment grâce à l’application d’unmécanisme de validation des schémas XML.

Quant à l’interface (WSDL), il s’agit de l’élément central du processus de publication et deroutage (WS-routing). En effet, pour effectuer l’enforcement des politiques de gouvernanceon a besoin d’un système intermédiaire, en l’occurrence la passerelle « SecureSpanGateway », dans laquelle on devra publier le service EdecImportService pour que les clientspuissent l’utiliser. Au même temps, on a besoin d’un mécanisme de routage pour guider lesrequêtes vers les points terminaux les plus adaptés aux politiques que l’on aurait défini. Dansle cas où le lecteur voudrait lire le contrat de service il peut soit consulter le SLA dansl’annexe nommé Artefacts, soit accéder à la totalité du contenu dans le site web de l’OFIT[Hüsemann and Rischbeck 2007].


6.3 Architecture du prototype « e-dec Governance »

Lors de la description de l’étude de cas « e-dec » on a pu voir en quoi consiste l’architectureSOA qui expose le service web EdecImportService. Cependant, pour supporter les différentscas d’utilisation qui définissent ce prototype de gouvernance SOA cela n’est pas suffisante.En effet, le service EdecImportService doit être sollicité par plus de 300 clients externes dontle comportement vis-à-vis d’e-dec est réglé par une SLA. Dans l’intérêt des deux parties,aussi bien des clients que du fournisseur, il est nécessaire de disposer d’une solution degestion de politiques, comme celle décrite dans la section 4.4.2, permettant de piloter lesaspects de sécurité et des niveaux de services.

Figure 40 : L'architecture d'e-dec Governance.

Dans l’architecture d’e-dec Governance la première couche, de gauche à droite, est celle destransitaires ou clients d’e-dec. Comme on peut le constater dans la Figure 40, on a représentéles clients externes par une application indépendante (standalone) appelée soapUI [theeviware soapui team 2007]. Cette dernière est utilisée pour créer les requêtes qui serontenvoyées au service web EdecImportService. Grâce à la capacité de soapUI à créer des testsunitaires et/ou groupés, la couche client représente assez bien l’activité qui pourrait générerles clients d’e-dec. Notons que le certificat client est un artefact fondamental pour établir lacommunication et garantir la sécurité. Il est donc nécessaire de pouvoir configurer lespropriétés SSL de soapUI (Keystore/TrustStore) avant d’envoyer des requêtes au service web.

Côté client, les décisions en matière de gouvernance concernent la gestion des artefacts,certificats client et de l’interface de description du service WSDL. Ensuite, on doit pouvoircréer un projet WSDL dans lequel on déclare le point terminal du service EdecImportService.Pour permettre aux clients d’implémenter leurs propres politiques d’utilisation et de s’adapterà celles définies par « e-dec » on peut créer des configurations génériques qui sont applicables


aux messages sortant et entrant de soapUI. On se réfère ici notamment aux attachements WS-Security dans les messages SOAP.

Du côté client (soapUI), on va donc se limiter à créer un projet WSDL contenant l’interfacede description d’EdecImportService. Une fois avoir importé ce fichier, on est en mesure decréer les requêtes que l’on désire envoyer à la plateforme « e-dec » en fonction du casd’utilisation courant. Dans la Figure 41 on montre le projet WSDL que l’on utilise pourréaliser le prototype e-dec Governance. Il s’agit d’un projet créé par les développeurs duservice web EdecImportService pour tester le comportement de ce dernier sous des conditionsparticulières (SAML, SSL, etc.).

Figure 41: Projet e-dec/IPV Web Services dans soapUI.

Comme on peut le constater dans la Figure 41, le service EdecImportService ne possèdequ’un seul type de port constitué d’une seule opération, en l’occurrence, submitEdecImport.En dessous de cette dernière on peut observer les différentes requêtes utilisées pour tester leservice web et qui en même temps peuvent servir au prototype de gouvernance SOA.Plusieurs informations importantes sont affichées dans la partie droite de la copie d’écran, àsavoir les propriétés du WSDL telles que, l’URL où se trouve le fichier, son espace de nomdéclaré dans le WSDL, la liaison concrète pour le type de port EdecImportPortType, laversion de SOAP et le style ou mode de message utilisé. La section « Definition Parts »contient les différents artefacts qui constituent le contrat de service, en l’occurrence ladéclaration d’importation, le message de réponse et la description technique du service. Enfin,dans la section « Operations » il y a une seule ligne car submitEdecImport est la seuleopération déclarée dans le WSDL et elle ne supporte pas la transmission de messages enmode « One-Way ». Autrement dit, elle n’est supporte pas la transmission unidirectionnel carle WSDL défini, au même temps des messages d’entrée, des messages de sortie tels que lesmessages de réponse et d’erreurs.

La couche du fournisseur de service (voir Figure 40) est celle qui contient le service webEdecImportService exposé par la plateforme « e-dec ». Les détails concernant cette partie ont


été présentés dans l’Etude de cas « e-dec » et on a pu constater qu’il s’agissait d’un service deprocessus publié dans une zone SSZ et implémenté dans système ESB et un serveurd’application J2EE. C’est cette couche qui est responsable de valider le certificat client carelle est en relation avec l’autorité de certification AdminCA-CD-T01 qui signe les certificatsdes transitaires. Enfin, plusieurs types de réponses peuvent être générés par le service webselon qu’il s’agisse d’une transmission d’acceptation ou d’un refus. Dans les deux cas, lemessage de réponse peut varier d’une requête à l’autre avec plusieurs documents attachéspour quelques uns et des messages SOAP fault pour d’autres. Il est à noter que le serviceweb EdecImportService ne supporte que le mode synchrone « Request-response » et que touteréponse supplémentaire doit être envoyée par d’autre canal tel que le courrier électronique.

Le troisième composant de l’architecture est représenté par un système de gouvernance SOAcomposé d’une passerelle virtuelle de gestion et d’application de politiques ainsi que d’unmodule d’administration, disponible sous la forme d’une application de bureau ou d’uneapplication web. Ces deux composants représentent le cœur du prototype e-dec Governancecar c’est à ce niveau que l’on envisage de définir et de faire appliquer les politiques desécurité et de niveaux de service. Dans la Figure 40 illustrant les trois couches du prototypede gouvernance, on a représenté le SSG à l’intérieur d’une zone démilitarisée (DMZ) qui peutaussi bien appartenir au réseau du transitaire qu’au réseau de la plateforme e-dec. En effet, laSSG est une plateforme utilisée pour définir et gérer les politiques qui devront respecter tousles participants, à savoir le service web EdecImportService et les applications ou services destransitaires. On peut donc la déployer, soit dans le côté client pour piloter des politiques desécurité strictes, comme le contrôle des messages sortant (requêtes) et des réponses provenantdu réseau WAN (proxy inversé) et la traduction des requêtes HTTP en requêtes JMS. Soit onla déploie dans le réseau du fournisseur de service, ce qui permet d’obtenir les mêmesrésultats, en plus de superviser le respect des SLAs et la qualité de service (QoS). Dans laconfiguration réseau utilisée pour e-dec Governance, la passerelle SSG ne se trouve pasphysiquement dans le réseau de la plateforme « e-dec » mais à l’extérieur de celui-ci.Cependant, du point de vue logique cette configuration ne posera pas de problème majeur carles politiques qui sont définies et gérées par le SSG concerne principalement le service webEdecImportService.

Dans la section suivante on présentera les différentes capacités offertes par la passerelle SSGdans le cadre de la gouvernance SOA. Il est à noter que le choix même de ce type de produitconstitue déjà une décision de gouvernance SOA car son utilisation peut influencer lescaractéristiques finales de SOA, tel que le couplage faible, la réutilisation et les performancesdes services.

6.4 SecureSpan Gateway Virtual Appliance

La passerelle SecureSpan Gateway (SSG) est une solution SOA intégrée permettant à la foisde protéger les services web utilisés depuis l’extérieur et d’implémenter les politiques degouvernance appliquées en temps d’exécution. Dans le domaine de la protectiond’applications et des services web, SSG permet de définir un certain nombre de politiques de


sécurité permettant de garantir les services de confidentialité, intégrité, authentification etautorisation. En effet, cette passerelle fournit les moyens nécessaires pour définir lespolitiques de contrôle d’accès qui seront appliquées à EdecImportService lorsque celui-ci serasollicité par les différents transitaires. Parmi ces politiques de contrôle d’accès on trouveplusieurs variantes d’authentification et d’autorisation qui couvrent la plupart des stratégiesexistantes, comme les mécanismes d’authentification au niveau de la couche de transport(HTTP basic, digest and certificate) et au niveau de la couche de messages (WS-Security,SAML and XML Security).

Figure 42 : Les différentes catégories de politiques implémentées dans la passerelle SSG.

Comme on peut le constater dans la Figure 42, la passerelle SSG ne se limite pas aux aspectsd’authentification. Elle permet aussi de définir d’autres types de politiques de gouvernance,telle que les contraintes de niveaux de service et de traitement de message. En effet, le contratde service (SLA) existant entre EdecImportService et les transitaires est implémenté danscette passerelle au même temps que les politiques de sécurité mentionnées ci-dessus. De cettefaçon on peut garantir aux différents clients (transitaires) que le service webEdecImportService se comporte en conformité aux paramètres de niveaux de services. Dans lecas des messages, SSG supporte plusieurs mécanismes de traitement de messages XML telsque la validation, l’inspection de contenu, le traitement XSLT et le routage des requêtes etréponses.


Chacune des politiques mentionnées ci-dessus sont appliquées en temps d’exécution par lapasserelle SSG. En effet, cette dernière fonctionne comme un « Policy Enforcement Point »(La phase de « Run-Time ») qui contrôle le trafic des messages (requêtes et réponses) pourgarantir leur conformité vis-à-vis des politiques prédéfinies. SSG représente dans le rôled’intermédiaire, le seul point d’accès au service EdecImportService par lequel transitent lesrequêtes et les réponses échangées avec les transitaires. Dans la Figure 43 on montre unexemple de configuration de politiques déployée à l’aide de SSG. Il s’agit d’un ensemble decontraintes imposant aux clients du service web protégé (EdecImportService) d’utilisercomme point d’entrée un canal SSL. Pour que l’utilisateur soit authentifié auprès de lapasserelle il doit fournir son nom d’utilisateur et le mot de passe envoyé avec le mode HTTPDigest. Ensuite, la requête doit passer par une structure logique définie par trois opérateurspropres au standard WS-Policy (ALL, ExactlyOne, OneOrMore). Dans ce cas on peutconstater que pour que la requête soit validée il faut qu’elle passe l’un des deux groupesd’assertions contenues dans l’opérateur OneOrMore (At least one assertion must

evaluate to true). Si la requête passe l’un des ces groupes, elle est alors routée vers unpoint terminal spécifique.

Figure 43 : Policy Enforcement sur les requêtes envoyées à EdecImportService

La passerelle SSG fonctionne aussi comme un point d’intégration d’applications et desservices déployés dans différents domaines de sécurité. Dans ce cas, il devient une extensiondes infrastructures de clés publiques (PKI) avec la capacité de signer et de délivrer descertificats. Elle assure aussi la fédération des identités et le service d’authentification unique(Single Sign-on) en prenant en charge la transmission des assertions d’authentification etautorisations de type SAML.


6.4.1 Le fonctionnement de SSG Manager

Le dernier composant utilisé dans la couche intermédiaire est le module de gestion de lapasserelle SSG. Ce module existe en deux variantes, l’une sous forme d’application de bureauentièrement indépendante et l’autre sous la forme d’une applet accessible via un navigateurweb qui est celle utilisée dans ce prototype. Du point de vue de la gouvernance SOA, legestionnaire SSG permet d’accomplir plusieurs activités relatives à la gouvernance Run-Time,à savoir la gestion interne ou fédérée des identités, l’implémentation et validation despolitiques, le monitoring des services et l’audit des événements.

Pour que la passerelle SSG soit activée pour un service donné, il faut que l’administrateur dusystème puisse accomplir quelques tâches propres au flux de travail proposé par ce module.En principe, ce processus est composé des étapes suivantes :

1. Se connecter au SSG.

2. Gérer les fournisseurs d’identités pour s’assurer que les clients seront identifiés.

3. Publier le service web

4. Analyser les performances de la passerelle pour identifier les violations éventuelles.

Les deux premières étapes concernent l’authentification des utilisateurs de la passerelle et desclients du service web. Grâce aux fournisseurs d’identités, la passerelle compte sur toutes lesinformations nécessaires à l’identification et authentification de ces deux types d’utilisateurs.La troisième étape doit être terminée avant d’associer une politique à un service web. En effet,en publiant le WSDL, SSG intègre par défaut une politique de routage vers le point terminaldéclaré dans l’interface de description. La publication peut se faire de deux manièresdifférents selon si l’on possède ou non le fichier de description (WSDL). Dans le premier cas,il suffit de communiquer l’URL du fichier et dans le deuxième cas il faut fournir lesparamètres nécessaires pour accéder au WSDL localisé dans un registre UDDI externe. Enplus de cela, on peut publier sous différents URL uniques un même WSDL et d’y associer despolitiques spécifiques aux clients qui accèdent par ces différents points. Enfin, la dernièreétape correspond à superviser le comportement des services en regardant de plus près lesoutils de monitoring proposé dans ce module.


Figure 44 : L'interface du Dashboard contenu dans le gestionnaire de SSG.

La Figure 44 est en effet une capture d’écran du Dashboard ou tableau de bord proposé dansle gestionnaire de SSG. Cet outil permet de suivre en temps réel le comportement des servicesgrâce à un ensemble d’indicateurs clés de performances comme le temps de réponse et lenombre de requêtes par seconde. Sous l’onglet « Selection » on mesure aussi les nombre desrequêtes qui ne se sont pas conformé aux politiques (Policy Violation) ainsi que le nombre derequêtes dont le routage n’a pas fonctionné.

En plus des capacités de monitoring en temps réel, SSG conserve un historique desévénements survenus dans la passerelle qui s’avère être un outil efficace pour l’audit desrequêtes et des réponses. Il permet de suivre à partir d’une date donnée les requêtes et lesréponses qui ont transité par la passerelle ainsi que les messages de log associés.

6.4.2 Support et conformité aux standards

Afin d’implémenter les différents types de politiques mentionnées ci-dessus, SSG s’appui surdeux standards WS-Policy et XACML 2.0. Le premier standard (WS-Policy) est unespécification permettant de communiquer d’une manière découplée les contraintes etcapacités d’un service web. Tant les clients comme les fournisseurs peuvent profiter de WS-Policy pour déclarer leurs exigences de sécurité, transactionnelles ou d’autre type, sans besoind’ajouter du code à l’implémentation du service. WS-Policy est un Framework indépendantqui est souvent considéré comme étant le troisième composant d’un contrat de service global(WSDL, SLA, WS-Policy). Il est tout d’abord suffisamment générique pour couvrir la plupartdes domaines (sécurité, fiabilité, transaction, etc.) des services web pour ensuite se décliner enplusieurs spécifications, à savoir WS-PolicyAttachment (liaison WS-Policy et les ressources),


WS-PolicyAssertions (des assertions génériques) et WS-SecurityPolicy (des assertionsspécifiques à la sécurité). Dans le contexte de la gouvernance SOA, le support des standardsindustriels est un facteur très important car il contribue largement à garantir l’interopérabilitéde l’architecture SOA.

6.4.3 Intégration avec des outils de la gouvernance Design-Time

La SSG, telle qu’elle est utilisée dans ce prototype, n’a pas la capacité pour implémenter lescas d’utilisation typiques à la gouvernance Design-Time. Pour ce faire, on a besoin dessystèmes de registre et de référentiels de services qui fournissent les fonctionnalités propres àla gouvernance Design-Time. Dans la version Virtual Appliance utilisée dans ce prototype ona la possibilité d’intégrer celle-ci avec la plateforme de gouvernance, HP SOA SystinetSoftware de HP. Dans ce cas, la SSG continue à assurer les tâches d’une solution degouvernance Run-Time en implémentant les politiques de contrôle d’accès, de sécurité XML,de routage WS, etc. Tandis que la plateforme Systinet offre les capacités nécessaires deDesign-Time, telles que le stockage et la validation des politiques, l’implémentation desprocessus de validation de l’architecture, contrôle de la conformité des services, la gestion descontrats et le catalogue des services.

La SSG admet aussi le rôle d’agent de gestion de service web (WSM) pour le compte de HPSOA Manager. Ce dernier est une plateforme de gestion SOA offrant une large palette defonctionnalités avancées telles que la gestion de la performance, de la sécurité et desexceptions. Il sert aussi comme un point de renforcement de politiques qui peut être combinéavec la SSG dans une configuration Agent-Gateway.

Cette combinaison ressemble fortement au système de gestion de politiques présenté dans lasection La phase de « Run-Time ». La solution de HP joue le rôle de point de décision quistocke les politiques de Run-Time pour que la SSG puisse les appliquer lorsque les messagesSOAP passent par cette dernière. Chaque politique définie dans la SSG peut être envoyée versSystinet pour passer par une étape de validation et de conformité et ensuite être stockée dansle système registre-référentiel.

6.5 Gouvernance Run-Time

La passerelle SSG est un outil de gestion et de gouvernance Run-Time pour les architecturesorientée services. On va donc montrer comment on peut implémenter et renforcer lespolitiques de gouvernance Run-Time (PEP) dans le prototype e-dec Governance. Notons quepour faire de la gouvernance Design-Time il faut pouvoir intégrer la SSG avec des solutionscomplémentaires comme les systèmes de registres et référentiels de service fournis par dessociétés partenaires tels que les produits HP SOA Systinet Software, CentraSite de SoftwareAG, etc.


6.5.1 Publication d’EdecImportService

La première décision à prendre en matière de gouvernance Run-Time est évidemment lapublication du service. Pour utiliser EdecImportService depuis une application externe, il fautque le modèle de gouvernance SOA prévoie la manière dont le service sera exposé auxtransitaires et clients de la douane. Dans ce contexte, SSG offre le choix entre générer unenouvelle interface WSDL et utiliser une interface existante publiée dans un registre UDDI oudans un fichier local. Dans le cas d’EdecImportService on a opté pour la dernière optionconsistant à localiser le WSDL dans un fichier local.

Pour ce prototype, le choix d’un WSDL local n’a pas de répercutions importantes à différenced’un environnement réel de production. L’utilisation d’un WSDL local limite la flexibilité deSOA dans la mesure où elle empêche la réplication en temps réel des éventuels changementseffectués sur l’interface du service. Du point de vue de la gouvernance SOA, une telledécision est importante car elle peut réduire le potentiel de l’architecture global, notammentsa flexibilité et agilité vis-à-vis des nouveaux changements.

Une remarque importante qui revient dans chaque cas d’utilisation est celle liée à la structurede gouvernance et aux différents rôles que celle-ci peut définir. Il fau dire que la SSG vientconfigurée avec un seul rôle qui est celui d’administrateur auquel on assigne tous les droitssur l’ensemble d’objets gérés. Donc, pour publier un service il faut que l’utilisateur soit dansun rôle adéquat tel que celui du Service Manager ou tout autre rôle équivalent.

Figure 45 : Les services web publiées dans la passerelle SSG.

Dans la Figure 45 on peut observer les services qui ont été publiés dans la passerelle SSG. Ils’agit d’EdecImportService et d’un service web non protégé proposé par le site webwww.amazon.fr. Le binding d’EdecImportService définit la liaison SOAP/HTTP pour laseule opération qui contient le service, à savoir submitEdecImport. Tandis que la partieServices expose les points terminaux où se trouve EdecImportService. Une fois cetteopération de publication terminée, les transitaires doivent configurer le point terminal duservice pour qu’il pointe vers le point terminal où se trouve le service intermédiaire, enl’occurrence a passerelle SSG.


6.5.2 Les politiques d’accès pour EdecImportService

Pour qu’un client puisse accéder à EdecImportService il doit présenter un certificat clientdélivré par l’autorité d’identification de la plateforme « e-dec ». Ce certificat est présenté parsoapUI lors de la phase d’authentification mutuelle avec le serveur SSL. En ajoutant unservice intermédiaire tel que celui de la passerelle SSG, il devient plus difficile de satisfairecette exigence car il faut garantir une sécurité end-to-end et non pas point-to-point.

Pour satisfaire cette exigence d’authentification il faut tout d’abord pouvoir authentifier etautoriser les transitaires auprès du service intermédiaire, en l’occurrence la passerelle SSG.Pour ce faire, on a le choix entre utiliser un seul certificat client qui est celui délivré parl’autorité de certification AdminCA-CD-T01 et utiliser deux certificats clients, l’un pourl’authentification auprès de la SSG et l’autre pour la politique de routage HTTPS versEdecImportService.

La première alternative a l’avantage d’être plus simple à mener car elle n’utilise qu’un seulcertificat pour les deux canaux SSL ouvert entre le client soapUI et la SSG, ainsi qu’entre laSSG et la plateforme « e-dec ». Le désavantage de cette solution est qu’elle augmente lespossibilités d’attaques man in the middle consistant à intercepter la clef publique de l’une oudes deux parties. La deuxième alternative est plus sûre tout en répondant aux exigences desécurité SSL mais beaucoup plus difficile à implémenter car elle demande une connaissanceapprofondies dans la gestion fédérées des identités.

Pour implémenter la politique d’accès à EdecImportService on doit procéder comme suit :

1. Le transitaire doit disposer d’un compte utilisateur dans un annuaire LDAP existant oudans la base de données MySQL gérée par la SSG. C’est cette dernière option que l’ona choisi pour le prototype.

2. Il faut aussi établir la relation de confiance avec les certificats qui seront utilisés. Dansce cas, il faut que les transitaires acceptent le certificat de la SSG qui est signé par lapasserelle elle-même jouant le rôle d’autorité de certification. Cette dernière doit àson tour faire de même avec les certificats des transitaires.

3. Enfin, il ne reste qu’à choisir l’assertion de contrôle d’accès SSL with client certificateauthentication.

Pour que cette politique soit validée sans problème il faut combiner l’assertion SSL avec uneseconde assertion Grant Access to Users/Group» ou Athentication. Donc, dans sa forme finalela politique de contrôle d’accès est celle-ci :

SSL with Client Certificate Authentication

Transitaire in Federated Internal Provider


Il est évidemment possible de définir plusieurs alternatives de contrôle d’accès en fonction duclient avec qui on communique. Bien qu’EdecImportService ne l’exige pas on pourraitproposer une politique d’authentification différente pour des clients pour qui le SSL en modemutuel ne serait pas nécessaire. Voici en quoi peut consister cette politique :

6.5.3 Les politiques de sécurité

Souvent, les environnements de production des services web vont au-delà de la sécurité auniveau du protocole de transport pour assurer une sécurité de messages SOAP. La justificationd’une telle démarche, qui est aussi valable pour « e-dec », se réfère au fait que malgrél’utilisation d’un canal sécurisé SSL, rien n’empêche qu’il y ait une attaque interne, déclenchépar un Backdoor lisant le contenu des déclarations d’importation après que celle-ci aientatteint leurs destination.

Dans tous les cas, les idées pour exploiter les vulnérabilités et les limites de SSL ne font pasdéfaut. Par exemple, malgré le service d’authentification de SSL rien n’empêche qu’un clientmécontent essaie une attaque DoS en envoyant des déclarations trop lourdes avec plusieursmégaoctets en attachements. Pour éviter ces types de surprises, la passerelle SSG offre lapossibilité de définir des politiques de Firewall XML comme le fait de contrôler la validitédes requêtes par rapport au schéma XML, contrôler les attachements SOAP en faisant appelaux modules Norton Antivirus que l’on peut intégrer au SSG, imposer l’utilisation de XMLSignature et XML Encryption, etc.

Le service EdecImportService n’exige aucune sécurité au niveau des messages mais il seraitquand même pertinent d’ajouter une assertion de type Validate XML Schema pour être sûr queles requêtes des transitaires respectent bien le schéma référencé dans le WSDL. Cela permetde protéger EdecImportService contre les attaques de type XML Parameter Tampering etXDoS car le contrôle des valeurs de la déclaration d’importation permet de s’assurer que lesparamètres XML n’ont pas été remplacés par des scripts malicieux ou que la structure mêmedu message n’a pas été modifiée. Donc, la politique de sécurité XML pour « e-dec » serait lasuivante:

SSL or TLS Transport

HTTP Basic or Digest or WSS UsernameToken Basic

Transitaire in Identity Internal Provider

Validate XML Schema


6.5.4 L’implémentation du SLA

L’accord sur les niveaux de services de la plateforme « e-dec » n’a pas des restrictionsparticulières sauf la maintenance de 2 heures par semaine qui exige l’arrêt du service. Commele service est sensé être disponible la plupart du temps il n’y a pas besoin de définir uneassertion de disponibilité. Du point de vue technique, l’absence de ce type de disponibilité nechange rien à la manière dont la passerelle SSG se comporte car il n y a pas de restrictiondans le temps et les requêtes vers « e-dec » ne seront jamais filtrées. Cependant, dans l’intérêtd’éviter toute confusion et de veiller au respect de l’accord SLA, on estime que le prototype e-dec Governance doit implémenter explicitement la disponibilité du service.

Dans la description du SLA on peut lire que la charge normale se situe à l’hauteur de 20déclarations par minute et qu’à partir de 170 déclarations par minute on considère que lacharge est extrême. La passerelle SSG permet de limiter le nombre de requêtes par secondepour un client, un groupe de clients, etc. Il est aussi possible de définir un maximum derequêtes concurrentes et de configurer SSG pour qu’il adapte sa réponse au cas où lesrestrictions de SLA seraient violées.

L’accord de niveaux de service pour « e-dec » est implémenté avec les assertions suivantes:

6.5.5 La logique de WS-Policy et les assertions

Chacune des politiques qui ont été développées dans ce prototype traduisent les contraintesd’interaction entre les transitaires et le service EdecImportService. Cependant, pour mieuxcontrôler le traitement de ces assertions, le standard WS-Policy met à disposition une séried’opérateurs logiques qui n’ont pas été utilisés jusqu’ici. Il s’agit des opérateurs ALL,ExactlyOne et OneOrMore. Lorsque le premier opérateur est appliqué aux assertions qu’ilcontient, chacune de ces assertions doivent retourner la valeur « True » pour que la politiquesoit satisfaite. Le deuxième opérateur permet d’implémenter le cas opposé à l’opérateur ALL,c'est-à-dire, qu’une seule assertion doit être évaluée comme « True ». Dans le cas du troisièmeopérateur, au moins une assertion doit retourner vrai pour que la politique soit satisfaite.

Le prototype e-dec Governance fait aussi usage de ces opérateurs pour combiner lesdifférentes assertions. Ce qui suit résume l’ensemble des assertions que conforment lapolitique de gouvernance pour le service EdecImportService:

Availability Time – 00:00:00 to 23:59:59

Availability Day of Week: Monday to Sunday

Rate limit: average 1 msg/second per Authenticated

user (concurrency 170)


Dans la politique de gouvernance Run-Time d’EdecImportService on a utilisé les opérateurslogiques All et OneOrMore. L’opérateur de premier niveau All assertions must be evaluate toTrue, englobe toutes les assertions utilisées dans cette politique. Tout d’abord on a placél’exigence de transport SSL pour dire que l’accès au service web doit se faire par un canalSSL, quelque soit le client. Ensuite, l’opérateur At least one assertion must evaluate to truecontient les assertions d’identification et authentification des clients. Grâce à ce deuxièmeniveau d’assertions, combinées avec l’opérateur OneOrMore, on peut couvrir l’ensembled’alternatives d’authentification et d’identification de ce prototype. Au moins un transitairedoit être identifié et authentifié par la passerelle SSG pour que la politique soit satisfaite. Dansce cas, on a déclaré deux clients, l’un qui représente un transitaire agrée de la plateforme « e-

<All assertions must evaluate to true/>

SSL or TLS Transport

< At least one assertion must evaluate to true/>

<All assertions must evaluate to true/>

SSL with Client Certificate Authentication

Poveda_Transitaire in Federated Internal Provider

/>

< All assertions must evaluate to true

HTTP Basic or Digest or WSS UsernameToken Basic

DLH_Transitaire in Identity Internal Provider

/>

/>

Validate XML Schema

Availability Time – 00:00:00 to 23:59:59

Availability Day of Week : Monday to Sunday

Rate limit: average 1 msg/second per Authenticated user (concurrency 170)

Route to Https://e-dec-a.ssl.admin.ch/services/EdecImportService/V1

/>


dec » et l’autre un transitaire fictif qui n’a pas de certificat client mais possède un compteutilisateur qui lui permet d’envoyer des requêtes à titre d’essaie.

Après que la passerelle SSG est identifié l’un des deux clients, elle peut continuer à évaluer lereste des assertions. Les assertions Validate XML Schema, Availability, Rate limit et Route tohttps, sont placées à la fin de l’assertion de premier niveau All assertions must evaluate totrue pour dire qu’elles s’appliquent à tous les clients du service web. Dans le cas où l’une deces assertions ne soit pas satisfaite c’est alors toute la politique qui échoue.

Bien que le service EdecImportService n’exige pas explicitement la conformité des formatsdes données aux standards industriels, on sait que SOA compte beaucoup sur l’utilisation desstandards pour garantir l’interopérabilité. Dans le cadre de ce prototype on peut encore insérerune assertion globale pour dire que chaque requête doit respecter tel ou tel standard. Parexemple, on peut demander que les clients qui n’ont pas des certificats pour l’authentificationet veulent tester leurs applications auprès d’EdecImportService, d’envoyer des requêtesconforme au standard WS-Security.

6.6 Présentation des résultats

Les résultats obtenus dans ce travail sont en étroite relation avec les objectifs mentionnés ci-dessus. C’est pourquoi on a décidé de développer cette partie en suivant la structure desobjectifs d’e-dec Governance décrits dans la section nommée Exigences et besoins.

6.6.1 Consolidation des connaissances théoriques de SOA

Les concepts et notions théoriques de SOA ont été largement abordés dans l’étude de cas « e-dec » et dans le prototype e-dec Governance. Lors de la description de l’étude de cas on a eul’occasion de présenter les différentes technologies et composants qui conforment cetteplateforme SOA. En commençant par les business cases jusqu’à l’architecture SOA, on s’estservit des concepts théoriques étudiés dans ce travail pour décrire les composants métier ettechniques de la plateforme « e-dec ». L’utilisation du client soapUI a permit de couvrir d’unemanière concrète, c'est-à-dire en faisant référence à la technologie des services web, unepartie importante des concepts orientés services. Ceci est montré par le fait que pour utilisersoapUI en tant que client, on a dû utiliser les concepts tels que les contrats de service WSDL,les représentations des données dans la forme des schémas XML (e-decImport et e-decImportResponse), les portTypes, les messages SOAP et SOAP attachements.

La même remarque s’applique aux notions de gouvernance SOA, plus particulièrement cellesde la gouvernance Run-Time. On y voit comment les modèles de gouvernance Run-Timedécrits dans la section La phase de « Run-Time » ont été repris dans l’implémentation d’e-decGovernance. En effet, ces modèles décrivaient la nécessité d’avoir un système de gestion depolitique où l’on peut stocker et renforcer toutes les assertions de Design-Time, Run-Time etChange-Time. Grâce à e-dec Governance on a pu concrétiser le point d’enforcement (PEP)pour la gouvernance Run-Time, le gestionnaire (SSG Manager) et les politiques elles-mêmes.


Un autre élément important que l’on avait vue dans la partie théorique mais pas du toutobservé dans la pratique c’est sont les différences existantes entre les types de gouvernanceSOA. On a pu constater par exemple que pour faire de la gouvernance Design-Time on abesoin des systèmes de registre et de référentiels de service permettant de stocker etd’appliquer les politiques de Design-Time. En regardant de plus près aux politiques decontrôle d’accès fournies par la SSG on peut montrer cette différence. Dans le cas d’unepolitique d’authentification et autorisation des utilisateurs, la gouvernance Run-Time viseplutôt les consommateurs de services. Tandis que la gouvernance Design-Time vise lesdéveloppeurs, architectes et d’autres participants de la phase de développement d’un service.Le renforcement (enforcement) ou application des politiques ne s’effectue pas au mêmeendroit selon qu’il s’agisse de la gouvernance Design-Time ou de la gouvernance Run-Time.

Depuis la SSG on n’a aucun moyen de renforcer, auprès des développeurs, les politiques deréutilisation des services ou de gérer le portefeuille de service de l’entreprise. Par contre, laSSG est une solution idéale pour implémenter les accords sur les niveaux de services etsuperviser en temps réel le comportement d’EdecImportService. Par ailleurs, on peut aussicontrôler la réutilisation des services en temps d’exécution pour savoir si sa fréquenced’utilisation correspond bien à ce qui avait été planifié. Quoi qu’il en soit, la gouvernanceSOA reste un sujet difficile de maîtriser à cause des connaissances cross-domain dont elle tireprofit.

6.6.2 Le prototype de gouvernance SOA pour EdecImportService

Sans aucun doute le deuxième objectif d’e-dec Governance a été le plus difficile à atteindre.Tout d’abord, parce qu’il a fallut surmonter plusieurs obstacles avant d’arriver à déployercorrectement la passerelle SSG. Le premier obstacle que l’on a surmonté est celui del’installation et configuration de SSG, notamment quant aux détailles de réseau et de gestiondes certificats et des clefs privées. Dans ce contexte, on a dû :

Installer la version Virtual Appliance de la SSG à l’aide du lecteur VMWare Player.

Configurer les détailles de communication et de réseau adaptés au déploiement de ceprototype. Ce point a posé quelques difficultés à cause du nom Fully QualifiedDomain Name (FQDN) qui n’était pas résolu dans la phase de configuration réseau.

Parmi les résultats acquis dans ce deuxième point on peut citer ceux obtenus dans la gestionfédérée des identités. Dans le contrat du service web EdecImportService on exige quel’identité des transitaires soit authentifiée via les mécanismes d’authentification de SSL enmode mutuel. Pour ce faire on a reçu de la part de la plateforme « e-dec » un certificat clientsigné par l’autorité de certification ADMIN-CA-T01 de l’OFIT. Le premier défi à releverconsistait à faire accepter auprès de la SSG les certificats du transitaire ainsi que celui del’autorité de certification. Grâce au mécanisme Identitiy Bridging supporté par la SSG on a puimplémenter le partage des identités entre la SSG, le client soapUI et « e-dec ». Dans une telleconfiguration on a deux domaines de sécurité distincte, à savoir le domaine d’authentificationqui est représenté par ADMIN-CA-T01 et le domaine d’autorisation supporté par la passerelleSSG pour autoriser les transitaires à envoyer des requêtes au service web. Il y a aussi un


client, en occurrence soapUI, qui demande l’accès au service EdecImportService via lapasserelle SSG.

L’Identity Bridging est un mécanisme efficace de gouvernance Run-Time qui a permis à ceprototype de solutionner les problèmes provoqués par les silos d’identités. Tant la plateforme« e-dec » comme la passerelle SSG ont leur propre silo d’identités qu’empêchaient le routagedes requêtes et l’authentification des transitaires. Avec ce mécanisme on a pu partager lesidentités des transitaires entre le client soapUI, la SSG et la plateforme « e-dec » et réussirl’authentification et l’autorisation auprès de celle-ci. Pour que l’authentification mutuel puissefonctionner on a établi la relation de confiance en important le certificat ADMIN-CA-T01dans le magasin de confiance (trust store) de la SSG. Le certificat du serveur (*.ssl.admin.ch)a été aussi importé dans le trust store de la SSG. Ensuite il a fallu créer un fournisseurd’identités fédéré auquel on a attaché les certificats importés et on lui a jouté un nouvelutilisateur qui optionnellement pouvait aussi se voir attacher le certificat client (Test SpediteurPoveda…).

L’implémentation du prototype e-dec Governance a été un moteur de réflexion sur les aspectsde gestion des politiques. En effet, à chaque fois que l’on a dû créer une politique on aconstaté qu’il fallait suivre un même processus itératif et incrémentale résumé dans les étapessuivantes; définition, validation, publication, application et suppression. Réussir àimplémenter une bonne politique n’est pas une chose facile et il faut procéder par étapesjusqu’à obtenir les résultats attendus. Lorsqu’une assertion n’est fonctionne pas comme onl’espère elle peut provoquer une indisponibilité de service non désirée par le fournisseur. Lesmessages d’erreurs, comme « Policy Falsified », « Error message processing » et« authentification failed », indiquent qu’une assertion n’a pas été respectée, et par conséquent,la politique n’est pas satisfaite. Dans le cas du service web EdecImportService, cela estarrivée dans les politiques d’authentification SSL qui demandaient la présentation d’uncertificat client. Si un tel certificat n’existe pas ou que le point terminal n’est pas un SSL,alors la SSG renvoi un message « authentication required ». Si les accréditations présentéespas le client soapUI tels que les mots de passe et les certificats, n’étaient pas reconnues par laSSG, la réponse est évidemment « authentication failed ». Les erreurs dans le traitement desmessages sont retournées dans plusieurs cas de figure. Par exemple, lorsque le fournisseur duservice dépasse le temps (time out) pour répondre à la requête de routage ou qu’une erreurdans la lecture des messages SOAP d’entrée et de sortie (requêtes et réponses). Quoi qu’il ensoit, c’est un message qui a des conséquences importantes pour les politiques car la SSGréagit en stoppant le traitement.

Par rapport à la gestion de la qualité (QoS) on a pu voir comment elle est supportée par unesolution réelle de gouvernance SOA. En premier lieu on peut citer l’implémentation de laSLA dont chaque paramètre a été traduit en une assertion. Bien que les paramètres de quota etde fréquence de requêtes ne sont pas indiqués pour la plateforme « e-dec », on voit jusqu’àquel point on peut renforcer l’accord de service en limitant le nombre des requêtes parseconde pour un client donné ou en fixant de limites maximales dans les requêtesconcurrentes pour qu’aucun client ne monopolise les ressources du fournisseur de service.Sachant que la charge maximale observée a été de 170 messages par minutes, on pourraitlimiter le nombre des requêtes concurrents par client de telle sorte qu’elles ne dépassent cettevaleur. Malgré l’apparente simplicité dans la gestion des SLA, on doit noter que les termes


des accords de services changent très vite et parfois ne sont pas si explicites que l’on aimerait.Par exemple, lorsqu’un ou plusieurs paramètres ne sont pas connus d’avance la difficultéd’assurer la qualité monte d’un cran car ces informations sont d’habitude fixées dans lesassertions d’une SLA.

Tous les aspects de gouvernance SOA tels que la gestion des risques et de la performance,sont présents dans le prototype e-dec Governance. L’assertion de contrôle d’accès parcertificat client via SSL, l’assertion de validation de schéma XML, la protection contre lesattaques SQL (injection SQL, etc.), les assertions de SLA et le monitoring montrent unexemple concret de comment le risque et la performance sont abordés. Les détaillesd’interopérabilité et de conformité ont été pris en compte par l’existence d’une assertion WS-IBSP Compliance exigeant que les messages et la politique adhèrent à la spécification WS-IBasic Security Profile 1.0. Ce faisant, on garanti que les requêtes et réponses n’utilisent quedes éléments compatibles dans chaque élément XML tels que les algorithmes d’encryption, designature, la déclaration des namespaces, etc.

Enfin, les exigences de conformité légale n’ont pas été oubliées dans cette solution car ellessont implicites aux outils de gouvernance SOA. Dans le cas d’e-dec Governance on n’a pasoublié ce domaine qui s’est déjà imposé dans la gouvernance d’entreprise, notamment suite àloi SOX qui promu une meilleure transparence dans la gestion financière des sociétés. Dansce prototype on a défini une politique d’audit permettant d’enregistrer les événementsWARNING et SEVERE déclenchés lors des échangent entre soapUI et le service web d’e-decet dans les opérations d’administration du SSG Manager.

6.6.3 Evaluation de la passerelle virtuelle SecureSpan Gateway

Dans cette dernière étape on aimerait effectuer une petite analyse sur les avantages et lesinconvénients de la passerelle SSG. Dès les phases d’installation et de configuration de laSSG jusqu’à l’implémentation des politiques de Run-Time on a pu se faire une idée de sonpotentiel et de ses inconvénients que l’on aimerait partager avec le lecteur.

L’utilisation de la passerelle SSG dans l’architecture orientée services offre des avantages nonnégligeables dans les domaines de la sécurité et de la gouvernance SOA. Dans cetteexpérience on a trouvé comme positif les points suivants:

Sécurité: La SSG offre une solution efficace au problème de sécurisation des servicesweb et des applications XML. Cette solution est implémentée sous la forme d’un XMLFirewall permettant d’inspecter le contenu des messages SOAP et XML en fonctiondes politiques de sécurité définies par l’administrateur. Les services de confidentialité,non-répudiation, authentification, autorisation et d’intégrité sont supportés à deuxniveaux distincts, au niveau des protocoles Internet comme HTTPS et FTPS, et auniveau des messages XML au moyen des spécifications telles que XML Signature,XML Encryption, WS-Security, etc.

Politiques cross-domain et composition: La SSG ne se limite pas aux politiques desécurité mais elle couvre un grand nombre de domaines comme celui des politiques decontrats et de qualité de services. On peut aussi définir des politiques pour lesdomaines de gestion d’identités, du routage des messages, la traduction des protocoles


de transport (HTTP, JMS, FTP). Le domaine du Compliance est couvert par lespolitiques d’audit et logging permettant de capturer les informations utilisées dans lesrapports opérationnels. Grâce aux opérateurs logiques AND et OR, on peut combinerles assertions dans une séquence logique pour construire une politique dynamique. Lespolitiques peuvent être réutilisées basées dans l’importation et l’utilisation destemplates.

Gestion avancée et centralisé: Pour gérer la SSG on peut utiliser soit une applicationstandalone, soit une applet s’exécutant dans un navigateur web. Chacun de cesmodules d’administration sont basés sur une interface utilisateur graphique trèsintuitive et un support déclaratif dans la gestion des politiques, à l’exception desexpressions régulières, les schémas XML, et autres détailles. Elle permet la gestion entemps réel monitoring et e tableau de bord,

Interopérabilité et extensibilité: On compte sur un ample éventail de standards SOApour assurer l’interopérabilité de la plateforme. Dans ce contexte on a toute la pile desstandards des services web (HTTP, XML, SOAP, WSDL et UDDI). Les standardscomplémentaires WS-Security, WS-Policy, WS-Trust, WS-SecureConversation, WS-MetadataExchange, sont aussi supportés. Possibilité d’intégrer la SSG avec dessystèmes externes et répandus dans le marché de SOA. Par exemple, on peut utiliserdes fournisseurs d’identité Oracle Internet Directory, TivoliLDAP, Microsoft ActiveDirectory et GenericLDAP. Il est aussi possible d’installer des politiques provenantd’autres éditeurs tels qu’Oracle COREid Protected Resource, Sun Java System Accessmanager Protected Resource, Symantec Virus Scanning, etc.

Réplication et répartition de charge: La SSG peut être configurée en mode cluster danslequel on peut avoir plusieurs nœuds SSG partageant les politiques de services, lesfournisseurs identités et les paramètres d’administration. Cette configuration se basesur le déploiement d’un Load Balancer.

115

7Conclusions

La partie théorique de ce travail est le fruit d’une étude approfondie et sérieuse sur lesconcepts élémentaires et plus au moins avancés de trois sujets importants de SOA, à savoir ledéveloppement orienté service, l’architecture SOA et la gouvernance SOA. Cette partie estsans doute celle qui a permit à l’auteur d’avancer d’une manière méthodique dans un sujetcomplexe et vaste comme celui de la gouvernance SOA. En effet, dans mon opinionpersonnelle il serait très difficile de comprendre l’art de la gouvernance si l’on ignore lescaractéristiques de conception des services SOA. Ces propriétés de base, qui sont le faiblecouplage, le contrat de service, la composition, la réutilisation, l’autonomie, l’absence d’état,la localisation et l’abstraction, donnent une idée précise de la nature de ces composantssoftware. Pour les managers, architectes, et autres participants de la gouvernance SOA, ils’agit de conserver ces propriétés tout au long du cycle de vie des services. Par exemple,chaque décision de gouvernance Design-Time doit tenir compte du fait que les services SOAsont réutilisables et, par conséquent, on ne devrait pas engager un projet de développementjusqu’à être sûr qu’il n’y a pas autre service équivalent.

Un autre aspect révélateur en matière de gouvernance est celui des modèles de services. Cesderniers jouent des rôles temporels en fonction de leur contexte d’utilisation. Mais ilsrépondent aussi à un modèle de service bien précis qui est souvent lié à la logique sous-jacente (métier, applicative, etc.) qu’ils implémentent. Connaître la différence existante entreces différents types de services (Processus, Métier, Application) est un atout non négligeablequi permet de se faire une meilleure idée sur la nature de l’inventaire de service SOA d’uneentreprise. Ils permettent aussi d’avoir une image logique de la disposition de l’architecture,notamment sa disposition en couches de services d’application, services métier et services deprocessus. Un service de processus a des caractéristiques particulières qui diffèrent de cellesd’un service métier ou d’application, comme le fait de posséder un état, jouer le rôle decontrôleur et modéliser le comportement d’un processus métier. Donc, les paramètres derisque, de performance et d’alignement stratégique ne sont pas les mêmes que pour les autresmodèles de services.

Quelque soit l’objet de gouvernance, il est évident que les cadres métier et TI doivent avoirune idée globale de l’environnement concerné. Toute la section traitant les sujets del’architecture SOA a permis de faire un grand survol sur les aspects logiques et physiques deSOA. Indépendamment de toute technologie, SOA représente la dernière génération dessystèmes d’information dont la raison d’être est celle de doter les entreprises d’unearchitecture TI flexible, agile et interopérable. Dans le contexte actuel de globalisation desmarchés et de haut niveau concurrentiel, l’agilité de SOA permettrait de devancer sesconcurrents dans les stratégies comme la pénétration de nouveaux marchés. La promesse deflexibilité décrit explicitement combien les technologies précédentes se sont montréesdifficilement adaptables aux nouvelles exigences métier. L’exemple typique est celui des

Conclusions 116

opérations de fusion et d’achats d’entreprise qui posent beaucoup de difficultés lors del’intégration des systèmes d’information (coûts élevés d’intégration et de maintenance, etc.).Cela n’est pas sensé arriver avec les architectures SOA car cette dernière est caractérisée parun grand potentiel de réutilisation et de configuration. A tout ceci s’ajoute l’interopérabilitédes systèmes dans les contextes commerciaux comme le B2B. Grâce à l’utilisation intensivedes standards technologiques l’architecture SOA garanti un niveau élevé d’interopérabilité quiest essentielle pour l’échange d’information entre les entreprises partenaires.

La gouvernance SOA n’est donc pas déliée des notions élémentaires mentionnées ci-dessus,au contraire, elle est caractérisée par un cycle de vie qui est à l’image de celui des services. Eneffet, les concepts de SOA et de gouvernance ne sont que les deux faces d’une mêmemonnaie. Pendant que la première permet de concevoir une solution hautement modulable etflexible, la deuxième fait que cette solution puisse exister à long terme tout en lui permettantd’atteindre les objectifs de flexibilité, réutilisation et interopérabilité. Les phases degouvernance Design-Time, Run-Time et Change-Time définissent donc le modèle degouvernance SOA standard, implémenté par toutes les entreprises de ce marché. Pendant laphase de Design-Time, les décideurs TI et métier se concentreront sur les aspects stratégiquescomme les stratégies de développement (Top-down, Bottom-up ou mixte) à adopter, lemodèle de maturité SOA, l’architecture de référence et la structure de gouvernance clarifiantles rôles et les responsabilités assignés à chaque partie prenantes. Chacun de ces élémentssont ensuite publiés et communiqués afin de fournir vision et direction à l’échelle du projetSOA.

Dans chacune des phases de la gouvernance on doit définir des politiques qui seront stockéesdans le référentiel de services. Les politiques de Design-Time devront être implémentées pourguider le comportement des utilisateurs par rapport à la réutilisation des services existants, audéveloppement basés sur les standards SOA et à la gestion minutieuse des artefacts qu’ilsproduisent (SLA, modèles de données, etc.). Les politiques de la phase de Run-Timepermettent de contrôler le comportement des services et de protéger le fournisseur contre lesmenaces de sécurité en temps d’exécution. Celles-ci sont appliquées dynamiquement par unoutil spécialisé jouant le rôle de point de renforcement de politiques (PEP) dont le but estd’exécuter les assertions de contrôle d’accès, d’authentification et autorisation, d’accord deniveau de service, d’audit et de sécurité.

Enfin, grâce à prototype e-dec Governance on a pu tester une solution de gouvernance prochede la réalité qui a permis d’analyser plus profondément les aspects théoriques et pratiques dela gouvernance SOA. D’une part, on a réalisé dans quelle mesure un outil de gouvernanceRun-Time doit être capable de résoudre les problèmes soulevés par SOA, tels que le silod’identités, la gestion des PKI, la conformité des services aux lois (SOX) et standards del’industrie. D’autre part, il a été possible de montrer la manière dont la SSG gère les risques etla performance des services, au même temps, que sa capacité à intégrer d’autres outils pouroffrir une solution complète et efficace.

117

AArtefacts

Dans cette annexe on a ajouté quelques fragments importants du contrat de service, comme laSLA, une image globale du WSDL et une présentation du fichier des politiques en formatXML. Le but est de faciliter aux lecteurs la recherche des informations mentionnées tout aulong de ce travail.

Tableau 7 : SLA du service web EdecImportService7.1 Accord de niveau de service

7.2 Disponibilité 7.3 Le système doit présenter une disponibilité de 99,5 % (24 heuresx 7 jours).

7.4 Fait exception à ce principe une fenêtre de maintenance de 2heures par semaine. Les fenêtres de maintenance sontannoncées à l'avance.

7.5 Duréed'indisponibilité(non planifiée)

7.6 Après un redémarrage, le service doit être de nouveau disponibledans un délai de 5 minutes

7.7 Temps deréponse (tempsde latence)

7.8 Charge normale: 95 % en dessous de 10 secondes, 99 % endessous de 15 secondes

7.9 Charge extrême: 95 % en dessous de 20 secondes, 99 % endessous de 60 secondes

7.10 Déclarations en douane d'importation: le temps de réponsecorrespond à l'intervalle entre le moment où la déclaration arrivedans le système et le moment où la réponse quitte le système.Le temps de transmission par le réseau public n'est pas pris enconsidération.

7.11 Débit 7.12 Charge normale: jusqu'à 20 déclarations par minute.

7.13 Charge extrême: à partir de 170 déclarations environ par minute.

Artefacts 118

Figure 46: Vue globale de l'interface WSDL

Artefacts 119

Figure 47 : Vue globale du fichier EdecImportService Policy.xml

120

BInstallation et Configuration

Figure 48 : SSG_32bit_VirtualAppliance_v43

Configurer les paramètres de réseau de la SecureSpan Gateway V4.3 en suivant lesinstructions affichées au menu de la console. Pour plus de détailles veuillez lire leparagraphe de la configuration réseau ci-après.

Pour simplifier le déploiement on s’est limitée à déployer la SSG en mode standalone,contrairement au mode cluster. Donc, une fois avoir réglé les paramètres de réseauchoisissez dans le menu l’option 5 pour appliquer les changements effectués. Ensuite,choisissez l’option 2 pour installer une instance de la SSG. Pour plus de détaillesveuillez lire le paragraphe de configuration de la SSG ci-après.

A l’aide d’un navigateur web (Mozillla Firefox ou Internet Explorer) accédez augestionnaire de la SSG au tapant comme URL les adresses suivantes:

o https://<ssghostname>:8443/ssg/soap -> Authentification mutuelle.

o https://<ssghostname>:9443/ssg/soap -> Authentification serveur seulement.

Configuration réseau

Pour configurer correctement cette étape la SSG offre deux options, à savoir un serveurDHCP et une configuration statique. Dans le cas de ce prototype, on a testé les deuxconfigurations et on a préféré l’option statique car avec le serveur DHCP on a rencontré desdifficultés dans la résolution de l’URL depuis le navigateur web. Après avoir choisi l’optionstatique et l’interface réseau (eth0) veuillez vérifier qu’il existe une entrée dans le fichieretc/hosts. Pour ce faire, suivez les indications suivantes:

Installation et Configuration 121

Faire un login en tant qu’utilisateur root en choisissant l’option 3.

Tapez la commande (nano /etc/hosts). Si l’on constate qu’il n y a pas d’entréecorrespondant à la SSG que l’on vient de configurer, veuillez ajouter les lignes commedans la figure ci-dessous. Les adresses IP et les noms d’hôte peuvent être différents deceux présents dans cette configuration pour s’adapter aux propriétés locales du réseauen question.

Figure 49 : Fichier hosts du serveur linux

Jusqu’ici cela devrait être suffisant pour configurer le réseau de la SSG. Cependant, sivous rencontrez un problème de communication entre le navigateur web et la SSG, onrecommande de vérifier le fichier hosts de Windows xp est d’y ajouter les mêmeslignes que dans le fichier /etc/hosts.

Configuration de la SSG

En général, si les étapes de la configuration réseau se sont terminées avec succès il n’y a pasdes problèmes particuliers lors de la configuration de la SSG. On peut donc se limiter àconsulter le manuel d’installation dont une copie a été ajoutée au CD-Rom.

Cependant, pour pouvoir utiliser le prototype e-dec Governance votre système doit satisfaireles conditions suivantes :

Importer le certificat ADMIN-CA-T01 dans le Trust store de la SSG et cocher l’optionSigning client certificates dans l’assistant d’importation de certificats. Importer aussile certificat client. Voir la section Workflow using an X.509 Certificate dans la page321 du document SecureSpan Manger User Manual.

Créer un fournisseur d’identité fédéré avec les attributs suivants :

o Provider Name: Transitaires.

o Credentials Source: X.509 Certificate.

Ajouter un utilisateur fédéré avec les attributs suivants :

o Username: poveda

o X509 Subject Name: CN=Test Spediteur Poveda CP7BJT,OU=Anwendungen, OU=Weisse Seiten, O=admin, C=CH.

o Importer le certificat client depuis le trust store ou depuis un fichier PKCS#12.

Installation et Configuration 122

Pour établir la confiance entre la SSG et le serveur e-dec et permettre que la politique deroutage fonctionne correctement, importez le certificat du serveur. Pour ce faire, il faut suivreles étapes de la section Add Certificate Wizard dans la page 328 du document SecureSpanManger User Manual.

Après avoir terminés les étapes décrites auparavant, il ne reste qu’à importer les politiquesd’EdecImportService. Pour ce faire :

Publier le service en suivant les étapes du chapitre 4 Publishing a SOAP Web Servicedu document SecureSpan Manager User Manual.

Importer dans le gestionnaire SSG le fichier EdecImportService Policy.xml fournidans le CD-Rom. Ensuite, il ne reste qu’à tester l’exécution des politiquesd’EdecImportService.

On devrait voir s’afficher les politiques de la figure ci-après.

Figure 50 : Politiques d'EdecImportService.

Avant d’exécuter les requêtes vers la SSG vérifiez que la clé privée utilisée dans la politiquede routage est celle appartenant au transitaire. Faire de même avec la clef utilisée sur le port8443 de la SSG de sorte que celle-ci soit la clef privée de la SSG. Pour plus d’informationsveuillez consulter les sections Managing Private Keys dans la page 338 et Managing ListenPorts dans la page 24 respectivement.

123

CCD-Rom

Le CD-Rom ci-joint contient les outils et la documentation utilisés dans le développement duprototype e-dec Governance. La Figure 51 montre la structure du CD-Rom ainsi que lesdifférents éléments livrés pour les utilisateurs.

Figure 51: Structure du CD-Rom

Les détails concernant chaque dossier sont présentés dans les tableaux ci-après.

Tableau 8: Contenu du dossier EdecImportService

ADMIN-CA-T01 ADMINCA-Class2 EdecImportService_v_1_0 TestSpediteurPovedaCP7BJT-

SN15695

Autorité de certification

du certificat client

Autorité de certification

du certificat serveur

Interface de description du

service

Certificat client

Tableau 9 : Contenu du dossier SoapUI

edecImportFull.xml edecWS-soapui_2-project.xml soapUI-2.0.2-installer

Déclaration d’importation pour

le Spediteur Poveda

Projet soapUI contenant le requête utilisée pour

tester les politiques.

Fichier d’installation de soapUI.

Tableau 10: Contenu du dossier Virtual SecureSpan Gateway 4.3

EdecImportService

Policy.xml

University_Fribourg_6mth_v4 SSG_4.3_base_appliance_32bit SSM_User_Manua

l_v4.4

Fichier des politiques Licence d’utilisation Image SSG compressée Mode d’emploi

124

Bibliographie

[Abou khaled and Mugellini 2007] Web Services. Cours Web Engineering, Ecoled'ingénieurs de Fribourg, Suisse, 2007.

[AFD 2003] Faits et chiffres 2003. fromhttp://www.ezv.admin.ch/dokumentation/01854/01856/01870/index.html?lang=fr.Retrieved 14.01.2008.

[AFD 2007] Faits et chiffres 2007. fromhttp://www.ezv.admin.ch/dokumentation/01854/01856/index.html?lang=fr. Retrieved14.01.2008.

[Arch2Arch 2006a] SOA Practitioners Guide-Part 1: Why Services-Oriented Architecture.from http://dev2dev.bea.com/pub/a/2006/09/soa-practitioners-guide.html. Retrieved19.08.2007.

[Arch2Arch 2006b] SOA Practitioners Guide-Part 2: SOA Reference Architecture. fromhttp://dev2dev.bea.com/pub/a/2006/09/soa-practitioners-guide.html. Retrieved19.08.2007.

[Arch2Arch 2006c] SOA Practitioners Guide-Part 3: Introduction to Services Lifecycle.from http://dev2dev.bea.com/pub/a/2006/09/soa-practitioners-guide.html. Retrieved19.08.2007.

[Blanc 2007] La grande question de la gouvernance fromhttp://www.directioninformatique.com/DI/client/fr/DirectionInformatique/Nouvelles.asp?id=43073. Retrieved 06.02.2008.

[Bloomberg 2004] SOA Governance: Reengineering IT Governance. zapthink

from http://www.zapthink.com/report.html?id=ZAPFLASH-10272004. Retrieved 01.05.2008.

[Brown 2007] Succeeding with SOA: Realizing Business Value Through Total Architecture,Addison-Wesley Professional, 2007.

[Descloux 2004] Sécurité informatique. Cours de bachelor, Faculté de SES de l'Univesité deFribourg, Suisse, 2004.

http://www.ezv.admin.ch/dokumentation/01854/01856/01870/index.html?lang=fr

http://www.ezv.admin.ch/dokumentation/01854/01856/index.html?lang=fr

http://dev2dev.bea.com/pub/a/2006/09/soa-practitioners-guide.html



http://www.directioninformatique.com/DI/client/fr/DirectionInformatique/Nouvelles.asp?id=43073

http://www.directioninformatique.com/DI/client/fr/DirectionInformatique/Nouvelles.asp?id=43073

http://www.zapthink.com/report.html?id=ZAPFLASH-10272004

Bibliographie 125

[Erl 2005] Service-Oriented Architecture: Concepts, Technology, and Design. Indiana,Prentice Hall PTR, 2005.

[Erl 2007] SOA Principles of Service Design (The Prentice Hall Service-Oriented ComputingSeries from Thomas Erl). Indiana, Prentice Hall PTR, 2007.

[Georgel 2005] IT Business Foundation (ITBF), Analyse du concept ITBF à l'origine de lagouvernance des systèmes d'information. 2005

[Gilardi 2006] Les analyses de gouvernement d'entreprise dans la pratique, CENTRE INFOSA, Fribourg, Suisse, 2006.

[High, Kinder, et al. 2005] IBM SOA Foundation: An architectural introduction andoverview. ws-soa-whitepaper version 1.0. fromhttp://www.ibm.com/developerworks/webservices/library/ws-soa-whitepaper/#download. Retrieved 20.05.2008.

[Hoernes and Schwarb 2007] SOA Governance: Design-time, Change-time, Run-time, Bern,2007.

[Hüsemann and Rischbeck 2007] Contrat de service d'EdectImportService. Office fédéralde l'informatique et de la télécommunication (OFIT), fromhttp://www.ezv.admin.ch/themen/00476/00494/01721/index.html?lang=fr. Retrieved01.04.2007.

[Innotvation Process Technology 2008] SOA Case Study e-dec - electronic customsdeclaration, Bern, 2008.

[Isakov and Ledentu 2005] Gouvernance d'entreprise, Université de Fribourg, Suisse, 2005.

[IT Governance Institute 2003] Board Briefieng on IT Governance. 2 edition. fromhttp://www.itgi.org/AMTemplate.cfm?Section=Board_Briefing_on_IT_Governance&Template=/ContentManagement/ContentDisplay.cfm&ContentID=39649. Retrieved10.05.08.

[Josuttis 2007] SOA in Practice The Art of Distributed System Design, O'Reilly, 2007.

[Laudon, K. and J. Laudon 2001] Les systèmes d'information de gestion, Village Mondial /Pearson Education France, 2001.

http://www.ibm.com/developerworks/webservices/library/ws-soa-whitepaper/#download

http://www.ibm.com/developerworks/webservices/library/ws-soa-whitepaper/#download

http://www.ezv.admin.ch/themen/00476/00494/01721/index.html?lang=fr

http://www.itgi.org/AMTemplate.cfm?Section=Board_Briefing_on_IT_Governance&Template=/ContentManagement/ContentDisplay.cfm&ContentID=39649

http://www.itgi.org/AMTemplate.cfm?Section=Board_Briefing_on_IT_Governance&Template=/ContentManagement/ContentDisplay.cfm&ContentID=39649

Bibliographie 126

[Layer 7 Technologies Inc 2006] Runtime SOA Governance fromhttp://www.layer7tech.com/library/page.html?id=39#wp. Retrieved 10.05.2008.

[Macfarlane and Rudd 2006] Gestion des Services liés aux technologies de l'information(ITSM) : Un guide à l'ITIL, itSMF Ltd, 2006.

[Maurer, Matlus, et al. 2000 ] A Guide to Successful SLA Development and Management.2000

[Mitra 2005] A case of soa governance. IBM developers Works fromhttp://www.ibm.com/developerworks/webservices/library/ws-soa-govern/. Retrieved01.05.2008.

[North 2007] Forrester Consulting. Companion Guide To Software AG’s

SOA Value Assessment. from http://www.softwareag.com/Corporate/res/value/default.asp.Retrieved 20.01.2008.

[numeraladvance 2008] L'ISO 12207- Le référentiel du cycle de vie d'un développemetlogiciel. fromhttp://www.numeraladvance.com/Role_des_Normes/Normes_pour_SI/ISO_12207.htm. Retrieved 10.03.2008.

[OFIT 2007] e-dec aktueller Stand und zukünftige Entwicklung, Bern, 2007.

[Organisation Internationale de normalisation 2008] Ingénierie des systèmes et du logiciel- Processus du cycle de vie du logiciel. fromhttp://www.iso.org/iso/fr/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43447. Retrieved 10.03.2008.

[Pulier and Taylor 2006] Understanding Enterprise SOA. Greenwich, Germany, Manning,2006.

[Remenyi 2006] Proceedings of the 6th European Conference on e-Government. A. C.International. Philipps-Universität Marburg, Germany.

[Ritu and Latha 2008] Policy-Driven Mobile Ad-Hoc Management, Wiley-InterScience,2008.

[the eviware soapui team 2007] soapUI 2.0.2. from http://www.soapui.org/. Retrieved16.06.08.

http://www.layer7tech.com/library/page.html?id=39#wp

http://www.ibm.com/developerworks/webservices/library/ws-soa-govern/

http://www.softwareag.com/Corporate/res/value/default.asp

http://www.numeraladvance.com/Role_des_Normes/Normes_pour_SI/ISO_12207.htm

http://www.numeraladvance.com/Role_des_Normes/Normes_pour_SI/ISO_12207.htm

http://www.iso.org/iso/fr/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43447

http://www.iso.org/iso/fr/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43447

http://www.soapui.org/

Bibliographie 127

[Ultes-Nitches 2006] Security, Département d'informatique, Univertsité de Fribourg, Suisse,2006.

[webMethods 2005] Making the Transformation to Service-Oriented Architecture:Capitalizing the on the next Revolution in IT. Get There Faster, fromhttp://www1.webmethods.com/PDF/Making_the_Transformation_to_SOA.pdf.Retrieved 10.01.2007.

[Weil and Ross 2004] IT Governance: How Top Performers Manage IT Decision Rights forSuperior Results, 2004.

[Wikipédia-gouvernance 2008] Gouvernance d'entreprise. Wikipédia. fromhttp://fr.wikipedia.org/wiki/Gouvernance_d'entreprise. Retrieved 4 février 2008.

[Wikipedia-windows 2008] Windows service. fromhttp://en.wikipedia.org/w/index.php?title=Windows_service&oldid=206853255.Retrieved 29 avril 2008.

http://www1.webmethods.com/PDF/Making_the_Transformation_to_SOA.pdf

http://fr.wikipedia.org/wiki/Gouvernance_d'entreprise

http://en.wikipedia.org/w/index.php?title=Windows_service&oldid=206853255

128

Documents

La gouvernance SOA Ses aspects théoriques et pratiques