La gouvernance SOA Ses aspects théoriques et pratiques

Transcription

1 Département d Informatique Université de Fribourg, Suisse 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: otto.povedahernandez@unifr.ch Travail de master en Informatique de Gestion Encadré par : 1 er lecteur: Dr Stefan Hüsemann 2 nd lecteur: Prof. Dr Jacques Pasquier-Rocha Fribourg, 21 Juillet 2008

2 Table des matières 1 Introduction Motivation Objectifs Structure Les services La notion de service Modèles de services Caractéristiques des services Les rôles Spécifications et technologies Architecture orientée services L évolution de SOA Les couches d application, métier et de processus Les outils de registre et référentiel de services La gouvernance SOA Introduction Les risques de SOA L origine de la gouvernance des TI Le contenu de la gouvernance des TI Relation entre la gouvernance TI et SOA Le Roadmap Planification et exécution de SOA La gouvernance des services La phase de «Design-Time» La phase de «Run-Time» Etude de cas «e-dec» Motivations de la plateforme «e-dec» Description de la solution «e-dec» i

3 5.2.1 Modèle métier import Architecture et technologies Implémentation du prototype «e-dec Governance» Objectifs du prototype «e-dec Governance» Exigences et besoins Architecture du prototype «e-dec Governance» SecureSpan Gateway Virtual Appliance Le fonctionnement de SSG Manager Support et conformité aux standards Intégration avec des outils de la gouvernance Design-Time Gouvernance Run-Time Publication d EdecImportService Les politiques d accès pour EdecImportService Les politiques de sécurité L implémentation du SLA La logique de WS-Policy et les assertions Présentation des résultats Consolidation des connaissances théoriques de SOA Le prototype de gouvernance SOA pour EdecImportService Evaluation de la passerelle virtuelle SecureSpan Gateway Conclusions A Artefacts B Installation et Configuration C CD-Rom Bibliographie...124

4 Liste des figures Figure 1: Composants d un service [Erl 2005, p. 296] 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] 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] Figure 4: Spécifications des Services Web [Abou khaled and Mugellini 2007, p. 15] Figure 5: Structures de données de la spécification UDDI Figure 6: Messages SOAP et des contrats WSDL [Abou khaled and Mugellini 2007, p. 29 and p. 45] Figure 7: Vision par application et vision intégrée Figure 8: Découplage entre les processus et les applications Figure 9: Une vue d'ensemble sur l'architecture SOA Figure 10: Les différentes couches de services Figure 11: Exemple d un diagramme BPMN [Josuttis 2007, Chap. Business Process Modeling] Figure 12: Le registre publie les contrats de services qui sont consultés par les clients potentiels Figure 13: Exemple des nombreux documents produits dans chaque étape du cycle de vie de services Cf. [Arch2Arch 2006c, p. 8] Figure 14: Conformité légale et stratégiques fait de la pression sur SOA Figure 15: Faible couplage implémenté par les services web [Pulier and Taylor 2006, p. 78] Figure 16: Le contenu de la gouvernance d'entreprise Figure 17: Le concept de l'it business foundation. Image tirée de [Georgel 2005, p. 2] Figure 18: Les principaux domaines de la gouvernance TI [IT Governance Institute 2003, p. 20]... 50

5 Figure 19 Structure de gouvernance TI et SOA Figure 20: Communication non sécurisée entre le fournisseur et le consommateur de service [Cf. Ultes-Nitches 2006, p ] Figure 21: Le Roadmap doit inclure les principes de SOA ainsi que l'architecture de référence Figure 22: Une vue très simplifiée du cycle de vie SOA Figure 23: Architecture de référence pour SOA Cf. [High, Kinder et al. 2005, p. 25] Figure 24: Modèle de maturité SOA en trois étapes [Josuttis 2007, Chap. Classification de services] Figure 25: Les trois phases du cycle de vie des services SOA Figure 26: Processus top-down défini dans [Erl 2005, p. 364] Figure 27: Processus bottom-up défini dans[erl 2005, p. 367] Figure 28: Classification de services selon la logique encapsulée dans un service Figure 29: Processus du portefeuille de services Figure 30: Différents types d'accords sur les niveaux de service Figure 31: Processus de développement et management des SLAs [Cf. Maurer, Matlus et al p. 18] Figure 32: Gouvernance Design-Time des SLA [Cf. webmethods 2005, p. 5] 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 Figure 35: Processus de gestion de la capacité [Cf. Macfarlane and Rudd 2006, p. 55] Figure 36: Nombre de déclarations (en millions) pendant la période 1995 au Graphique publié dans [AFD 2007, p. 23] Figure 37: Recettes encaissées pour le compte de la Confédération [OFIT 2007, p. 6] Figure 38: Délimitation en packages d e-dec import Figure 39: Architecture «e-dec». Graphique tiré de [Innotvation Process Technology 2008, p. 10] Figure 40 : L'architecture d'e-dec Governance Figure 41: Projet e-dec/ipv Web Services dans soapui Figure 42 : Les différentes catégories de politiques implémentées dans la passerelle SSG.. 100

6 Figure 43 : Policy Enforcement sur les requêtes envoyées à EdecImportService Figure 44 : L'interface du Dashboard contenu dans le gestionnaire de SSG Figure 45 : Les services web publiées dans la passerelle SSG Figure 46: Vue globale de l'interface WSDL Figure 47 : Vue globale du fichier EdecImportService Policy.xml Figure 48 : SSG_32bit_VirtualAppliance_v Figure 49 : Fichier hosts du serveur linux Figure 50 : Politiques d'edecimportservice Figure 51: Structure du CD-Rom

7 Liste des tableaux Tableau 1 : Catégories de services Tableau 2: Mécanismes de gouvernance d'entreprise Tableau 3 : Relation entre les solutions métier et TI Tableau 4: Quelques paramètres utilisés pour mesurer la performance des services Tableau 5 : Relation entre les solutions métier et l'infrastructure SOA tiré de [Arch2Arch 2006a, p. 11] Tableau 6: Principes d'architecture Tableau 7 : SLA du service web EdecImportService Tableau 8: Contenu du dossier EdecImportService Tableau 9 : Contenu du dossier SoapUI Tableau 10: Contenu du dossier Virtual SecureSpan Gateway

8 Résumé L architecture orientée services (SOA) est une approche architecturale de dernière génération qui permet de passer d une vision «application» à une vision «services». Elle réunit en un seul nom un grand nombre de concepts tels que, la composition, l abstraction, l autonomie, le couplage faible, la modélisation et le monitoring des processus métier, etc. Du point de vue technique, elle s appuie sur une infrastructure large et hautement distribuée contenant des composants 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 est pas 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 souplesse organisationnelle). Par conséquent, il est nécessaire d accompagner l adoption de cette approche avec un modèle de gouvernance approprié que l on connaît comme la gouvernance SOA. Cette dernière est en effet une extension de la gouvernance des TIs qui consiste en définir et faire appliquer un ensemble de règles et principes (politiques) spécifiques à chaque phase du cycle de vie d un service. La gouvernance en Design-Time désigne les mécanismes et procédures permettant de contrôler les aspects fonctionnels et techniques de l architecture et des services. La gouvernance Run-Time se focalise principalement sur les mécanismes de contrôle que l on devrait exercer sur les opérations de déploiement, monitoring et management de la qualité des services (QoS). Enfin, sachant que la seule constante en informatique s appelle «le changement», SOA n échappe pas à ce principe et doit reposer sur la gouvernance en Change-Time qui désigne la manière de contrôler, surveiller et maî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 et composants.

9 Liste des acronymes Acronyme Signification SOA Service-Oriented Architecture BPM Business Process Management MDB Message-Driven Beans SSZ Shared Service Zone LDAP Lightweight Directory Access Protocol ESB Enterprise Service Bus TI Technologie de l information AFD Administration fédérale des douanes WS Web Service e-dec Electronic declaration SOX Sarbanes-Oxley SAML Security Assertions Markup Language DMZ Demilitarized Zone SSG SecureSpan Gateway PKI Public Key Infrastructure UDDI Universal Description Discovery and Integration WSS WS-Security WSDL Web Service Definition Language SOAP Simple Object Access Protocol

10 1 Introduction 1.1 Motivation L architecture orientée service (SOA) se présente comme un concept innovant qui permet aux entreprises d atteindre un niveau élevé de flexibilité et d interopérabilité. On dit souvent qu elle est la technologie la mieux adaptée aux nouvelles exigences du marché où une organisation doit être capable de réagir rapidement aux changements produits dans son environnement (intérieur comme à l extérieur). Par exemple, lorsqu une entreprise réalise une stratégie d achat d un concurrent, elle doit intégrer les différents systèmes et applications pour bénéficier de l effet de synergie qu une telle opération est sensé générer. Si l architecture en place est de type SOA, l interopérabilité devient plus facile grâce à l utilisation des standards ouverts supportés par l ensemble de fournisseurs de logiciels. Cette possibilité de faire interagir des services hétérogènes (services de comptabilité avec ceux du département de finance) montre la portée transversale de l architecture SOA et laisse imaginer tous les avantages que l on peut tirer d une telle approche. Malgré cela, le caractère dynamique et distribué de SOA représente aussi un risque pour l entreprise si celle-ci ne parvient pas à définir les règles et directives permettant de bien contrôler et évaluer l 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 niveau de service (SLA) touchant les aspects de performance et sécurité, sont quelques exemples des problèmes survenus lorsque l implémentation SOA n est pas suivie d un cadre de gouvernance adapté. Sans la gouvernance, SOA est destinée à l échec car elle manquerait du support nécessaire pour gérer les différents éléments qui la composent. Ces éléments, possédant aussi bien de caractéristiques techniques que stratégiques, nécessitent une structure organisationnelle qui permette de refléter les rôles et responsabilités des parties prenantes (TI et métier). Par la gouvernance, chaque entreprise peut définir ses propres objectifs qu elle aimerait atteindre en adoptant une SOA ainsi que les ressources de TI dont elle a besoin. Les entreprises peuvent aussi prévoir les différents types de décisions à prendre lorsque certains scénarios se réalisent afin 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 et d optimiser le potentiel de SOA dans tous les scénarios possibles, comme par exemple la réutilisation des services partagés par les différents départements d une organisation. Dans ce cas la gouvernance permettrait de gérer les conflits éventuels pouvant survenir lors du partage d un service par plusieurs clients, notamment lorsque l on doit appliquer des mises à jour importantes qui représentent toujours un danger pour les clients du service. D autres processus et outils définis au niveau de la gouvernance permettraient d accroître la visibilité 9

11 Introduction 10 sur l infrastructure des TI et de mener une gestion en temps réel des services existants. Ainsi tout changement effectué au niveau des processus métier peut être répliqué en configurant les services afin de les adapter aux nouvelles exigences, selon les politiques définies dans les phases de développement et de maintenance. 1.2 Objectifs L objectif principal est de comprendre la vision qui sous-entend le paradigme SOA et d approfondir dans les aspects théoriques et pratiques de la gouvernance. On aimerait aussi appliquer les connaissances acquises par l étude de cas «e-dec». Voici une description plus détaillée des objectifs poursuivis dans ce travail : 1. Tout d abord on aimerait aborder les fondements de l architecture orientée services afin de 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 les avantages et désavantages qu elle possède. 2. Une fois avoir posé les fondements de SOA, le second objectif est d approfondir sur les aspects théoriques et pratiques de la gouvernance SOA qui permet de répondre à la question «Comment les entreprises parviennent-elles à gérer l architecture SOA avec efficacité». 3. Le dernier objectif est d implémenter la gouvernance SOA (Run-Time) dans le cadre de l étude de cas «e-dec». Dans cette partie on aimerait proposer un prototype de gouvernance pour le service web e-dec, notamment dans les domaines de la gestion de politiques 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 une introduction générale dans le domaine du développement orienté services et de l architecture SOA. Elle aborde les principes de la conception des services et les bases conceptuels sur lesquelles repose SOA. 2. la deuxième partie, constituée du chapitre 4, traite les aspects théoriques de la gouvernance SOA qui doivent être maîtrisés pour mieux comprendre ce qui se cache derrière ce terme. Ce chapitre développe le sujet de la gouvernance SOA en suivant une 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 des services.

12 Introduction 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 la pratique. 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 se diriger vers une solution orientée service. Ensuite, on présente un survol des différents composants que constituent son architecture, en particulier les services jusqu à maintenant déployés. Enfin, on aborde la proposition de gouvernance du service web EdecImportService consistant, d une part à implémenter à l aide de deux outils 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 de services qui pourraient se révéler utiles dans la gestion du service EdecImportService.

13 2 Les 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 une tierce 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 deux parties, entreprise et client, implique l existence de certains accords et contrats traitant sur certains aspects importants comme la quantité et la qualité du service, la manière dont il devrait ê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 entre elles 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 une plateforme de support, d un ou plusieurs canaux de distribution et d un système de retour de marchandises. Dans le contexte des solutions logicielles, le terme service a été utilisé pour désigner un type d application qui s exécute en arrière plan pour fournir un support système. C est le cas des services 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 des applications traditionnelles car ils sont régis par des principes de base spécifiques au paradigme de développement orienté services. Avec SOA, le concept d application, tel qu on le connaît depuis longtemps, change radicalement pour laisser la place au concept de composition de services ou aux applications composées [Erl 2007, p. 91]. En effet, il ne s agit pas de construire une application spécifique pour chaque exigence métier qui vient d être identifiée mais plutôt de composer des nouvelles configurations de services permettant de satisfaire les besoins utilisateur. Donc, on peut dire qu un service est un module logiciel contenant une interface publique affichant ses fonctionnalités, et une implémentation dont les dé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 ou d une tâche en unités de traitement autonomes et réutilisables que l on appelle services. Ces derniers 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 faire ainsi qu un ensemble de règles pour gérer cette information [Brown 2007, p. 2]. A première vue cela ressemble à la définition d un composant, tel qu il est décrit dans l orientation objet. 12

14 Les services 13 Mais en regardant de plus près on s aperçoit qu un service ne se limite pas à une implémentation et une interface uniquement sinon qu il est constitué d une structure beaucoup 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 interface d un service expose la signature des fonctionnalités qu il supporte au même temps que décrit son emplacement et comportement global. Le contrat désigne aussi bien l interface technique que 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 un objet émetteur et un objet récepteur indépendamment de la manière dont ce message est réellement transmis. Cela veut dire que le terme message désigne un concept général plutôt qu un format physique avec un en-tête, un corps de message et des attachements. Dans le paradigme orienté service, le terme messages désigne aussi bien un concept abstrait que le format spécifique utilisé pour les échanges entre un service et son client. Il doit contenir, en plus des données elles-mêmes, des métadonnées décrivant le destinataire, des informations sur 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 qui est celle de collection de fonctionnalités ou de conteneur de comportement bien défini. Se référer aux services comme une collection permet de dire qu un service sert à exposer une ou plusieurs 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 sousjacente ainsi que l autonomie d un service. Dans la Figure 1 on montre l architecture d un service partitionnée en trois couches logiques, à savoir le service, les fonctionnalités et les messages. La couche du service représente le containeur de fonctionnalités et le contrat de service. Les différentes fonctionnalités appartenant au même domaine fonctionnel utilisent les messages reçus en entrée et renvoient les messages résultants des traitements qu elles sont effectuées. Dans une implémentation spécifique, telle que celle des services web, on change le

15 Les services 14 terme de fonctionnalité par celui d opération. Si l implémentation du service est basée sur le modèle de composants et d objets, alors on appelle les fonctionnalités, des méthodes [Erl 2007, 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 formes de 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ères propres à une catégorie de service. Jusqu à maintenant il n y a pas de taxonomie de référence sur laquelle on s appuie pour présenter les différents modèles de services, mais par contre, on trouve dans la pratique un certain nombre de classifications permettant de connaître les types de services, ainsi que les critères de choix qui les différencient. Dans [Erl 2007, p. 43] l auteur présente trois modèles de services, à savoir les services de support (utility services), les services métier centrés sur les entités (entity services) et les services métier centrés sur les tâches (task services). Par ailleurs, dans [Josuttis 2007, Chap. Service Classification] l auteur classe 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 (process services). Dans la plupart des cas, ces différents modèles sont équivalents et parfois identiques. Certains services métier, comme ceux centrés sur les entités, peuvent être assimilés aux services de base car ils encapsulent les fonctionnalités métier contenues dans les systèmes et applications existantes (back-end). Les services métier centrés sur les tâches sont équivalents aux services concertés qui se chargent de composer d autres services dans l exécution d un sous-processus quelconque. 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 de services qui se distinguent en fonction de trois critères principaux tels que, le potentiel de réutilisation du service, le modèle logique qu il représente (métier, support, etc.) et le domaine fonctionnel qui définit la portée de la logique sous-jacente. Dans le cadre de ce travail 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 permettrait d 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étier et faisant appel aux techniques d orchestration. Les services métier pouvant exister à plusieurs niveaux désignent aussi bien les sous-processus et les tâches que les entités métier. Les services d application se réfèrent aux traitements de support technique et générique utilisés

16 Les services 15 par la plupart d applications. Au même temps, ils désignent les fonctionnalités encapsulées dans 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érature mentionnée ci-dessus. Il s agit d une liste des services que l on assigne à chaque groupe en vue de faciliter le transfert de connaissances, du domaine des applications traditionnelles au domaine des solutions orientées services où les termes métier et application sont déjà bien connus. La première colonne du tableau contient la liste des services considérés comme des services de processus car ils permettent de modéliser le flux de travail d un processus en coordonnant l interaction entre plusieurs services. Concrètement, il s agit de modéliser un processus d affaire en rassemblant plusieurs services en un seul flux de travail. Ce processus est connu sous le nom de composition de services et concerne surtout les services de haut niveau tel que les services d orchestration, contrôleurs, etc. Ces derniers interagissent avec des services dits enfants (situés en-dessous d eux) tels que, les services d entité, afin exécuter le processus mé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écution d 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éfinit dans le cadre de certaines règles métier. Formellement on les appelle services de tâche (task services ou task-centric services) et services d entité (entity services ou entity-centric services) et services d application. Comme son nom l indique, les premiers contiennent la logique 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, leur potentiel de réutilisation est réduit par rapport aux autres services. Une particularité de ces services est qu ils sont caractérisés par un contexte fonctionnel large concernant plusieurs domaines 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 partie du 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

17 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 celui trouvé dans les services de tâches. Par contre, la portée fonctionnelle des services d entités est limitée au domaine de l entité en question. Les services d application appartiennent à une catégorie de services de bas niveau qui permettent de développer des fonctionnalités centrées sur l infrastructure et la technologie sous-jacente. On les appelle aussi des services d infrastructure (infrastructure services) ou services de technologie (technology services). En effet, ce modèle de service englobe un ensemble de services dont la caractéristique principale est qu ils sont indépendants de la logique métier de haut niveau. Parmi ces services il y a les services d accès aux données (data services), les services de support (utility services) et les services d encapsulation de systèmes existants 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. En effet, un service de support tel que le service de gestion de sécurité peut être utilisé par n importe quel service métier afin d effectuer l identification et authentification des utilisateurs. 2.3 Caractéristiques des services Indépendamment des différents types de services déjà mentionnés, un service possède un ensemble de caractéristiques essentielles qui permettent de juger de son potentiel et intérêt conforme au paradigme «service-orientation». Chaque caractéristique est associée à un principe 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 services réutilisables en encapsulant la logique métier à un niveau assez générique pour qu elle soit utilisée dans plusieurs contextes. Cependant, tous les services n ont pas besoin d avoir le même degré de réutilisation. Il y a des services qui sont spécifiques à un processus d affaire particulier et dans ce cas ils ne sont pas réutilisables car les autres processus ne peuvent pas l utiliser. Mais on trouve aussi des services que l on appelle «agnostic services» qui ont un haut degré de réutilisation car ils encapsulent une logique de traitement suffisamment gé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é à plusieurs consommateurs de services qui peuvent s en servir individuellement ou en accès concurrentiel. Les services centrés sur les entités (entity-centric services) ont un fort potentiel de réutilisation. Par exemple, le service «produit» qui représente une entité d affaire de l entreprise peut être utilisé dans les processus «Approvisionnement» et «livraison». Les services de support (utility services) encapsulent les détails d implémentation qui sont

18 Les services 17 communs à beaucoup de services et applications, et par conséquent, sont utilisés dans plusieurs scénarios différents. Les services sans état Les opérations ou les méthodes d un service peuvent exécuter leurs traitements sans maintenir un é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 du consommateur du service. Ce faisant, il peut rester disponible pour d autres clients et supporter la montée en charge (scalability) lorsqu il y a plusieurs accès simultanés. Souvent les données d état sont stockées dans les messages qui peuvent contenir de la logique de traitement indépendante au service. On doit distinguer entre l état d un service et l information d état que ce dernier pourrait contenir. 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 temporel du 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, pendant l exécution du service, les informations et les données spécifiques à la tâche concernée. Ces sont 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 des informations d état pour gérer le déroulement du processus qu ils implémentent. Un moteur d orchestration leur permet de maintenir la trace des informations de session et de contexte ainsi que de gérer le flux d exécution (composition) pour que les services s exécutent dans l ordre définit. Le contrat des services Un contrat doit être décrit de manière appropriée pour permettre aux consommateurs de juger de l utilité du service et de connaître la manière dont il fonctionne. Pour ce faire, il est né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 les services d une manière détaillée et normalisée. C est aussi un accord formel entre le fournisseur et le consommateur concernant l utilisation du service. Dans [Erl 2007, p. 127] on le 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 comme ré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.

19 Les services 18 Dans le cas des services web, le contrat de service est représenté par plusieurs documents. Un document de description appelé «WSDL document» qui contient une description centrée sur les aspects techniques du service. Les documents XSD pour définir les structures de données XML embarquées dans les messages. Les documents «policy description» utilisés pour dé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 ses fonctionnalité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ôle le 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 les proprié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 doivent pouvoir évoluer indépendamment l un de l autre [Brown 2007, p. 41]. C est ce que l auteur de [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, les propriétaires puissent réaliser les changements nécessaires. Ces changements concernent aussi bien l interface du service, les documents du contrat, le traitement métier encapsulé dans les fonctionnalité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 de service [Erl 2007, p. 299]. Elle concerne le niveau de contrôle exercé par le service sur la logique d application, l environnement d exécution dans lequel il réside et les ressources partagées. Un service est complètement autonome lorsqu il est déployé dans un containeur d exécution qui lui dédié et dispose de toutes les ressources nécessaires comme s il en était le propriétaire. Cela ne veut pas dire que d autres services ne peuvent pas accéder aux mêmes ressources 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 se ré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 autres ressources sont accédées par d autres services. Il existe aussi l autonomie partagée (Shared Autonomy) qui a lieu lorsque l implémentation du service est utilisée par des systèmes et applications externes. Les services «wrappers» sont caractérisés par ce type d autonomie car ils encapsulent un traitement métier déjà existant que l on invoque depuis d autres applications. Enfin, la composition de service tend à rendre moins autonomes les contrôleurs et services intermédiaires car ils dépendent des membres de la composition pour réaliser leurs tâches [Erl 2007, p. 298]. D une certaine manière, une application composée crée des dépendances

20 Les services 19 d utilisation qui transfèrent l autonomie individuelle d un service vers un niveau d autonomie collectif. 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 et CONTIENT-UN entre les classes. Concrètement, il s agit d un exercice d assemblage pendant 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, un objet peut obtenir le comportement désiré sans forcement l implémenter lui-même. A son tour, 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 orientation objet et se base sur la même idée d assemblage ou agrégation mais en garantissant beaucoup plus 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 ou des 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 deux services 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 se produit lorsqu il y a un seul niveau d interaction entre les services (point-to-point). En principe, on est en présence de la composition lorsqu il y a au moins deux services, en plus du contrô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 but est d avoir des pièces (les services) les plus indépendantes possibles pour faciliter l évolution future des applications. Pour ce faire, il est important que tant les consommateurs comme les fournisseurs puissent évoluer indépendamment l un de l autre pour s adapter aux changements imposés par leur environnement respectifs, sans mettre en péril l interopérabilité. Le contexte d utilisation garantissant le plus faible niveau de couplage est celui où le service expose ses fonctionnalités au travers d un contrat ou d une interface. Cependant, la simple existence d un contrat ne garantit pas à lui seul l indépendance entre les deux parties. Il faut que son contenu ne garde aucune relation avec les détails de fonctionnement, tels que la technologie, l implémentation des ressources (base de données, système de fichiers, systèmes légués, etc.) et la logique sous-jacente. Si le contrat de service contient une dépendance quelconque envers un composant de son environnement il y aura un effet de transmission de dépendances qui couplera le consommateur au sous-système du service. Ce comportement

21 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 agit de dépendances internes (contrat et implémentation du service) qui peuvent avoir lieu si l on ne 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 de générer certaines parties du service à partir d un code ou d un modèle physique existant. En effet, lorsqu un contrat est construit automatiquement, à partir d un code existant, au même temps on court le risque de créer une dépendance depuis le contrat vers le code utilisé pour dériver ce contrat. Par exemple, en utilisant une interface et des classes Java pour générer le fichier de description WSDL on crée une relation étroite entre cette interface, le contrat et le sché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) le fichier WSDL pour qu il corresponde avec la version actuelle du service. Les types de donné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 Beans et Object) 1. Dans la Figure 2 on présente deux exemples de «coupling inheritance» dans lesquels on crée le contrat à partir d un code existant. Le premier (à gauche) correspond à l exemple décrit cidessus 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 certaines caractéristiques propriétaires. Un exemple typique est celui de schémas XML générés à partir de 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 le code 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 de donnés standards des schémas XML.

22 Les services 21 Une autre variante plus évidente menant à ce type de couplage est celle où l on utilise une solution propriétaire pour implémenter un service. Dans ce cas on peut espérer que le contrat contient quelques éléments propriétaires et non standards, comme par exemple un protocole de 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 celle montrée dans la Figure 3. Il s agit d un service dont le code est étroitement lié à un processus métier ou un autre service, comme c est le cas des services implémentés pour supporter un service 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 est déterminé en fonction du code, soit parce que ce code est déjà couplé aux ressources externes et il est utilisé pour générer le contrat. Donc, la dépendance fonctionnelle du contrat envers une 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és fonctionnelles du service. Ce faisant, les propriétaires, tels que les architectes et les dé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éutiliser pour ne pas redévelopper une ressource qui existe déjà, ainsi on évite d ajouter un service ou un logique métier redondant. S ils n existent pas, les développeurs peuvent développer des nouveaux services selon les exigences identifiées. C est pourquoi il est important que lors de la phase de conception (Design-Time), le service soit décrit d une manière précise dans les documents 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?

23 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 une manière transparente, sans qu il y ait besoin de connaître les détails physiques de sa localisation. Ils peuvent juger de l utilité du service avant de s en servir et même jouer la concurrence 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 claire et précise, les informations descriptives (méta information) des services. Elles concernent le service lui-même, l infrastructure de communication, les politiques et règles d utilisation, les critères de recherche, etc. L abstraction des services L abstraction est étroitement liée à l utilisation des services de la part des ses clients potentiels. En effet, un service met à disposition des consommateurs un ensemble d informations publiques qui sont importantes pour son exploitation. Ces informations présentées sous forme de contrats sont l interface entre le service et ses clients permettant de mettre en place un mécanisme d utilisation, simple et transparent, des différentes fonctionnalités. Pour les consommateurs et les propriétaires l abstraction représente une vue externe du service qui est facile à comprendre et à utiliser. Elle empêche aux applications et personnes d accéder directement à l implémentation des services. La simplicité est l un des objectifs poursuivit par le principe d abstraction. Tandis que l encapsulation cache les détails d implémentation d un service, l abstraction montre les informations essentielles nécessaires pour bien comprendre le service, tout en excluant celles qui ne sont pas pertinentes. Publier un service avec toutes les informations qui contient ses fonctionnalités rend complexe son exploitation et tend à coupler fortement ses consommateurs. Par exemple, en publiant les détails de communication, comme l adresse physique, les consommateurs seront obligés d accéder directement aux fonctionnalités du service, ce qui crée une dépendance entre eux. Par contre, si l on fait correspondre cette adresse à un nom quelconque (URI), les consommateurs auront toujours accès au service indépendamment de la situation physique de ce dernier. Donc, le service est libre de changer d emplacement tout en restant disponible. A l instar de l encapsulation, l abstraction est aussi une manière de cacher les détails d 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 cache celles qui ne le sont pas. Les détails techniques sur le langage de programmation dans lequel

24 Les services 23 est écrit l implémentation ainsi que l infrastructure de communication sont des informations qui devront être cachées à l extérieur car elles ne concernent que le développement et la maintenance du service. Autrement dit, le contrat de service doit être clair et précis mais sans aborder les détails superflus des informations qu il contient car, comme déjà dit, le risque de coupler 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 et services. Parfois la frontière de certains de ces rôles n est pas définie clairement car tout dépend du contexte d utilisation à partir duquel on décrit le service. Mais ce qui est certain c est qu un service peut jouer plusieurs rôles à la fois, montrant ainsi leur flexibilité. Ces rôles sont: Fournisseur de service : En principe, un service est toujours un fournisseur car il contient des fonctionnalités qui peuvent être invoquées depuis une source quelconque capable de communiquer via des messages. Généralement, un fournisseur se trouve en dehors du système qui l a invoqué. Pour satisfaire la requête qui lui a été envoyé, le service traite le message entrant et exécute le traitement demandé. Consommateur de service : Ce rôle peut être assumé par un service ou une application utilisant une plateforme de communication basée sur les messages. Généralement, un consommateur 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 service intermédiaire chargé d effecteur des traitements supplémentaires avant que le message de requête ne parvienne au consommateur du service. Si le service intermédiaire se limite 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 processus d affaires ou sont reliées dans une séquence d exécution permettant d accomplir une tâche déterminée, on est en présence d une composition de services. Le service de plus haut niveau gérant la composition dans son ensemble joue le rôle de contrôleur. Les autres 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 ces descriptions englobent une certaine flexibilité. Par exemple, dans le contexte de la composition de services un contrôleur peut être considéré comme étant un consommateur car il utilise d autres services. Par contre, l inverse n est pas toujours vrai car le consommateur peut être un programme externe qui n est pas un service. Au même temps, un sous-contrôleur peut être vu comme un fournisseur s il est appelé par un membre de la composition dans la séquence d exécution. Dans le contexte de ce travail, on préfère utiliser l analogie avec le modèle client-serveur [Erl 2005, p. 119] pour dire que les rôles, fournisseur, consommateur et intermédiaire, sont

25 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 de composition 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 de ce nouveau paradigme. La spécification la plus utilisée pour implémenter les solutions orientées services est celle des services web. Ces derniers représentent une nouvelle génération d applications qui s appuient sur un ensemble de standards et protocoles ouverts pour 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ède tous les éléments nécessaires pour implémenter une solution orientée services. Les caractéristiques des services, tels qu elles sont définis par l orientation service, sont pour la plupart supportées par les WS. C est le cas par exemple pour la localisation et découverte des services, 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ée des couches de protocoles : enregistrement et découverte, description de services et la couche de messages. La première couche de cette spécification supporte très bien le principe de découverte et localisation de services. En effet, une fois qu on a développé un service il faut que celui-ci soit accessible, via le Web, aux applications qu aimeraient l utiliser. Pour ce faire, on l enregistre dans un annuaire basé sur un ensemble de structures de données

26 Les services 25 standards et dont l accès se fait par l intermédiaire de protocoles universels, compréhensibles par toutes les applications. La deuxième couche, à savoir celle de la description de service offre tous les éléments né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és mises à disposition par le WS. On doit y décrire toutes les opérations, les paramètres d entrée et sortie de chaque opération, la localisation du service, le protocole de communication, les aspects de sécurité, etc. Les contrats des WS représentent un moyen concret de supprimer les dépendances entre les services, et par conséquence sont propice pour garantir le faible couplage. La troisième couche fournit un mécanisme efficace pour que les services puissent échanger des messages entre eux. Un WS supporte plusieurs patterns de messages, comme les messages à 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 qui permettent de publier un service d une façon standard pour que les clients potentiels puissent les découvrir et les utiliser. Pour ce faire, UDDI permet de stocker la description exacte du fournisseur associée aux informations d un ou plusieurs partenaires consommateurs ou fournisseurs de service. Chaque entreprise de l annuaire contient un ou plusieurs services qu elle a décidé de publier. Les informations concernant un service sont reparties en deux structures de données qui sont réservées pour contenir les détails techniques tels que, l URL pour 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 documents WSDL et SOAP, contenant la description de l interface et le protocole de messages respectivement. De cette façon, UDDI garanti la possibilité de chercher un service selon des diverses critères tels que, le type de fournisseur, sa zone géographique ou l entreprise propriétaire du service. Figure 5: Structures de données de la spécification UDDI.

27 Les services 26 Comme on l a déjà mentionné dans la section 2.3, le contrat de service est le document qu assure la description des services. Dans le contexte des WS, on s appuie sur le langage WSDL (langage basé sur XML) pour implémenter cette description dans un format interprétable, aussi bien par les fournisseurs que par les consommateurs. Un document WSDL est constitué de quatre éléments répartis sur deux niveaux de description, un abstrait et l autre concret. Dans la description abstraite, il y a l élément type qui contient la définition des données simples et complexes qui sont utilisés dans les messages. L élément message permet de définir les messages utilisés par le WS grâce aux informations sur le mode de message supporté, les données contenues dans le message ainsi que quelques informations sur le protocole de message SOAP et les erreurs liés aux messages. Le troisième élément est celui qui contient l ensemble d opérations supportées par le service, il porte le nom de porttype. Ce dernier défini l interface abstraite du service web qui consiste en un ensemble d opérations et des 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 possible d accéder au service. Chaque port, ici déclaré, doit contenir une URL pointant vers l 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 de message SOAP. Le format des messages définis par SOAP est très simple. Il y a d abord une première partie appelée Envelope représentant l enveloppe du message. Sa fonction première est de servir de containeur pour le corps du message mais il constitue aussi un moyen d indiquer le début et la fin d un message. Il contient l élément Header, définit comme optionnel, où se trouvent les instructions de traitement, les informations de sécurité et les données de routage. L élément Body est obligatoire et fait aussi partie de l élément Enveloppe. C est ici où l on trouve le contenu du message, comme par exemple, la valeur de

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

29 3 Architecture orientée services 3.1 L évolution de SOA L architecture orientée services fait son apparition afin de résoudre certains inconvénients posés par les approches architecturales qui l ont précédé. Afin de décrire la manière dont SOA s est installée, l auteur présente d une manière générale les deux visions qui ont guidé le développement d applications précédant SOA. Pendant longtemps les entreprises ont soutenu leurs activités en s appuyant sur des systèmes et applications spécifiques à une fonction (achats, finances, etc.) particulière. Dans cette configuration l ensemble d applications est développé, ou acheté, pour répondre aux besoins et exigences actuels tout en veillant à rendre facile leur évolution future. A chaque application correspond un projet de développement qu en principe n a pas de liens avec d autres projets de même type. En simplifiant on peut dire qu à chaque spécification métier correspond une nouvelle application ou une extension de celle déjà existante. C est ce que [Laudon and Laudon 2001, p. 737] appelle une vision par application du développement de systèmes d entreprises. Dans le court terme, cette approche s est révélée très efficace car elle a permis d identifier des besoins 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 à se manifester. L entreprise peut se retrouver avec un nombre croissant de systèmes et applications 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 sa charge de travail au lieu de l alléger. Au niveau des processus d affaires, ceux-ci se caractérisent pour être rigides et difficiles à modifier car ils tendent à être fortement couplés aux solutions logicielles qui les implémentent. L illustration de gauche de la Figure 7 montre l architecture globale d une entreprise qui se base sur cette vision. Le niveau «Fonctions» contient les différentes fonctions que l on trouve dans une entreprise, à savoir finance, comptabilité, production, etc. En dessous de celles-ci il y a les processus métier ainsi que les systèmes de gestion correspondants. Les processus sont spécifiques à un domaine fonctionnel et chaque système supporte l ensemble des processus d affaires d une fonction particulière. Comment on peut le constater, il n y a pas 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 de plusieurs applications, l utilisateur n a pas d autres choix que de disposer d une boîte à outils logiciel complexe qui peut être difficile à gérer. Il doit maîtriser des informations supplémentaires comme l emplacement de chaque application et l ordre logique dans lequel il 28

30 Architecture orientée services 29 peut les utiliser. Sur le plan du développement, il est sûr que l on multiplie les fonctionnalités redondantes, ce qui représente un gaspillage de ressources et un retour sur investissement faible. 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 un pas important dans l évolution de SOA. En effet, pour remédier aux inconvénients soulignés auparavant, les entreprises ont réfléchit à la possibilité d intégrer leurs systèmes. Cela a permis de passer d une vision par application à une vision intégrée des ressources, ce qui veut dire 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 ont implémenté des interfaces pour favoriser le flux d informations à différents niveaux et fonctions. Dans la Figure 7, l illustration de droite montre une vue intégrée de l entreprise. Le niveau des processus n est plus vertical mais horizontale montrant leur transversalité. Chaque processus est implémenté par une ou plusieurs applications qui communiquent entre elles via des interfaces ou de middleware spécifiques. Malgré les améliorations apportées par l approche d intégration d application, les solutions ainsi obtenues sont complexes et représentent une dépense financière importante. En plus, la diversité des plateformes dans la couche de systèmes tend à créer de nombreuses contraintes techniques et de sécurité. Quant aux processus d affaires, ils sont restés fortement couplés aux applications, 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 nouvelle vue sur l ensemble des ressources d une organisation. C est une vision focalisée sur les affaires qui permet de découpler les processus de la couche de systèmes afin de doter l entreprise d une indépendance total vis-à-vis des applications. Ce faisant, il est possible de dé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 aussi une couche de services entre le niveau de processus et celui des applications. Ces services

31 Architecture orientée services 30 sont conçus et développés conforme aux principes de l orientation service présentés dans le chapitre 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 architecture d entreprise. La première figure illustre la nécessité de supprimer le couplage direct qui existe entre les processus et les systèmes afin de rendre l architecture plus flexible. Chaque couplage fort est éliminé pour faire de la place à une couche de services SOA capable de garantir le faible couplage et de diminuer les nombreuses connections (relations) créées avec l approche par application. Dans la deuxième figure on montre une représentation logique de cette couche 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 processus d affaire pendant que les services de bas niveau encapsulent le comportement d une application particulière. Il est intéressant de noter que tous les services résident dans une même couche (représentation logique) car, à différence des applications, ils sont intrinsèquement interopérables grâce à l utilisation des standards. Cette couche commune montre aussi la vision fédérée que SOA porte sur les ressources de l entreprise afin de mieux les coordonner.

32 Architecture orientée services 31 Figure 9: Une vue d'ensemble sur l'architecture SOA. SOA est une architecture orientée service parce qu elle permet de substituer les applications traditionnelles par des modules logiciels appelés services. Une telle substitution ne se fait pas en supprimant les applications qui existent déjà sinon en encapsulant leurs fonctionnalités dans une couche de service. Toutes les fonctionnalités conservant un certain lien fonctionnel sont 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-ci n 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 peut contenir un nombre limité de services, souvent dédié à exposer les fonctionnalités des applications résidantes dans la couche de systèmes. Au fur et à mesure de la maturité de SOA on ajoute des nouveaux services, ce qui fait que la couche de service devient de plus en plus complexe. Pour mieux gérer cette complexité, les architectes et les développeurs partitionnent la couche de service en plusieurs couches qui reflètent les modèles de services présentés dans le chapitre Modèles de services, à savoir les services d application, les services métier et les services 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 en réalité tout dépend des exigences et stratégies spécifiques à chaque architecture.

33 Architecture orientée services 32 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 de services) et d un système d annuaire contenant un référentiel de tous les services existants. La couche de services d application est souvent implémentée en premier car elle permet d 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 est dé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 les applications existantes en les exposants sous forme de services. En effet, cette couche représente un niveau d abstraction de la couche de systèmes qu encapsulent les détails propres à chaque technologie et aux plateformes sous-jacentes. Par conséquence, chaque service entretient une relation simple (un-à-un) avec l application qu il représente car par définition un service doit avoir un seul domaine fonctionnel bien défini. Le fait de cacher les implémentations propriétaires avec des technologies standards permet implicitement l existence d une couche d intégration souple et évolutive. Dans ce cas, chaque système compte sur un adaptateur ou wrapper servant d interface vers les clients. Il sert aussi d intermédiaire entre les consommateurs et les fournisseurs de services, ce qui est un bon moyen pour concrétiser le faible couplage. La couche de services d application peut contenir d autres types de services à l instar de ceux proposés par la plupart de Framework d applications. Principalement, cela concerne les services de support et d infrastructure chargés de gérer des opérations communes à toutes les applications comme les services de logging qui permettent de tracer les sessions d un utilisateur et les services de gestion d exception offrant un mécanisme de contrôle des

34 Architecture orientée services 33 exceptions [Arch2Arch 2006b, p. 23]. Il y a aussi les services de données qui servent à écrire et à lire les données résidant dans le tiers de persistance d une application externe. Dans la Figure 10 on montre deux instances de ce type de service donnant accès aux données des clients 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 éliminer les fonctionnalités en doublons et par conséquent il est tout à fait envisageable d avoir deux services qui font la même chose mais pour le compte de systèmes distincts. Par exemple, le service «consumer data» peut exister sous deux versions, une spécifique aux clients d un système CRM et l autre encapsulant les données des clients d un système de gestion de factures. La couche intermédiaire contient les services métier qui sont chargés de représenter les entités et 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ées dans le contexte d un domaine métier spécifique. En plus, il est aussi possible de placer des services à granularité plus importante comme les services de traitement qui renvoient des ré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 les doublons identifiés dans la couche d application. Pour ce faire, il suffit de collectionner dans un service les différentes fonctionnalités en doublons pour les exposer dans un contexte fonctionnel bien défini. Par exemple, si dans la couche d application on a identifié deux services «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 pour effectuer 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 10 contiennent la logique de traitement nécessaire à l exécution automatique d une tâche. Par exemple, le service de gestion de commandes permettrait à une application de passer les commandes d un client et d enregistrer les données les plus importantes. Pour ce faire, elle compose les services d entités «produit» et «client» mais il doit aussi exposer des opérations, telle que «commander». Par contre, le service de gestion de clients utilise les services 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 des fournisseurs 2. En plus des deux niveaux déjà mentionnés, SOA permet la mis en place d une couche supplémentaire contenant les services de processus. Comme son l indique, il s agit d un ensemble de services encapsulant le flux de travail des processus métier pour que ces derniers puissent s exécuter d une manière automatisée. Un service de ce type aura toujours une contrepartie 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 outils BPM (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.

35 Architecture orientée services 34 spécifiques au métier concerné. Ensuite, les processus sont contrôlés via les fonctionnalités d analyse et de monitoring en temps réel permettant d identifier les problèmes potentiels qui pourraient 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érations exécutées par une ou plusieurs départements d une organisation. Pour qu un service puissent les implémenter correctement ils font appel à d autres services plus spécialisés et réutilisables qu ils composent dans séquence de traitement logique. Ce faisant, les services de processus doivent contrôler le flux de travail pour déterminer l ordre des opérations que chaque participant est tenu de respecter. Donc, un service de processus peut être vu comme un «chef d orchestre» qui est chargé de diriger l exécution d une composition de services. Dans la Figure 10, on peut voir deux instances de services de processus qui implémentent les processus métier «approvisionnement» et «ventes». Afin d accomplir ses tâches, le service d approvisionnement compose deux services de la couche métier, à savoir «gestion de commandes» et «gestion d achats» qui permettent de tirer des informations centrales telles que les produits à réapprovisionner et les fournisseurs respectifs. Pour le service de vente le principe est le même car il se sert de la couche métier pour exécuter la séquence d opérations dont il est constitué.

36 Architecture orientée services Les outils de registre et référentiel de services La concrétisation des principes de conception de services ne doit pas uniquement se focaliser sur le développement des services eux-mêmes. Elle doit passer aussi par la disponibilité de mécanismes de support capables d implémenter ces mêmes principes mais d une manière plus globale. Comme il a été dit auparavant, les principes, tels que la découverte et localisation de services, le couplage faible et la réutilisation sont implémentés grâce au développement d un contrat qui décrit toutes les informations pertinentes d un service. Cependant, cela ne repré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 gestion de 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 a présenté la spécification UDDI dans la section concernant les services web. Cependant, la frontière entre registre et référentiel n est pas tout à fait claire ce qui parfois fait croire qu il s agit de deux termes équivalents. Mais en réalité, il s agit de deux composants distincts gérant le même type d entité (les services) mais sous deux angles différents. Le registre gère les 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 registre représente le catalogue de services permettant aux fournisseurs de publier leurs services pour les rendre accessibles aux consommateurs. Cette accessibilité est aussi nécessaire pour les propriétaires des services, comme les architectes, développeurs et analystes, qui doivent disposer 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 ainsi qu un ensemble de fonctionnalités comme la classification, recherche et localisation de service. Du point de vue des consommateurs et fournisseurs, le registre contribue à réduire la dépendance d utilisation de sorte que tout changement dans l implémentation d un service n entraîne pas d autres modifications au niveau des clients. Pour les propriétaires, le registre est un composant central qui permet de configurer les services au temps d exécution, de contrô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, comme par exemple la sécurité et la disponibilité. Parallèlement à l utilisation des services, il y a toute la question concernant la gestion et gouvernance du cycle de vie des services. Un référentiel de service est le composant de SOA permettant aux gestionnaires et développeurs de gérer les services indépendamment de la technologie. Pour ce faire, il permet de stocker la définition des services et processus métier ainsi que leurs relations. Il offre aussi la possibilité de définir des règles et politiques d utilisation qui doivent être respectées par les consommateurs et fournisseurs. Le principe de réutilisabilité est largement implémenté par les référentiels car, grâce aux métadonnées qu ils contiennent, il est possible d identifier des relations de dépendance entre les services, et de déterminer si un service existe déjà et dans quelle mesure il satisfait le besoin que l on cherche à supporter. De manière générale, on peut dire que le référentiel est la base de données contenant tous les documents liés au cycle de vie, à savoir les définitions, les

37 Architecture orientée services 36 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 ne sont pas obligatoires dans une architecture orientée services, d au moins aux premières étapes de maturité de SOA. Cependant, lorsque le nombre de services augmente il devient de plus en plus nécessaire de mettre en place un référentiel pour soutenir le processus de gouvernance et le management de services [Arch2Arch 2006b, p. 32]. Cela veut dire que le référentiel est complètement indépendant de l environnement d exécution des services, ce qui n est pas le cas pour le registre. Enfin, malgré les différences entre ces deux composants il n est pas rare de trouver des solutions combinant plusieurs référentiels et registres dans un même produit.

38 4 La 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 qui est celui de la gouvernance SOA. En effet, les objectifs techniques et métier poursuivis par SOA ne peuvent pas être atteints sans avoir une structure de gouvernance propre à ce type de projet. Le caractère hautement distribué de SOA, les promesses de faible couplage, la composition 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 jamais atteint si le cycle de vie des services n est pas aligné avec sur les objectifs stratégiques de l entreprise. En général, SOA est caractérisée par un ensemble de processus de conception, d utilisation et de mise à jour de services qui sont difficile à concrétiser sans avoir une maitrise total des aspects de management et de gouvernance. En effet, la gouvernance SOA permet d encadrer les différentes étapes de conception, d utilisation et de mise à jour mentionnées ci-dessus, par la mise en place d une structure de responsabilités visant à clarifier les rôles et les prises de dé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érer l ensemble des artefacts propres à chacune de ces étapes du cycle de vie des services. Les politiques, 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 ensuite dicter les actions à prendre. On trouve plusieurs exemples concrets de gouvernance SOA dans des domaines tels que la clarification de la stratégie SOA liée aux objectifs métiers de l entreprise. Les décisions relatives au Roadmap et à l architecture de référence qui permettent 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 des dé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 peut toucher presque chaque élément de SOA. C est pourquoi on a décidé de traiter dans la suite de ce travail les étapes de gouvernance Design-Time et Run-Time qui sont celles qui se différencient les plus et peuvent apporter plus de compréhension à ce sujet. Bien que la gouvernance Change-Time ait ses propres particularités, comme la gestion des versions et le choix des stratégies de mise à jour (big bang, évolutive, etc.), on peut considérer qu elle est toujours présente dans la gouvernance en Design-Time et Run-Time. 37

39 La gouvernance SOA 38 Pour ne rien laisser dans l oublie on commencera cette partie par l exposition des motivations qui justifient l existence d un Framework de gouvernance dans le cadre de SOA, son origine et sa relation avec la gouvernance d entreprise et TI. Il s agit en effet d un chapitre qui présente la gouvernance SOA d une manière très générale sans se focaliser sur aucun aspect particulier. Ensuite, c'est-à-dire, dans les chapitres cinq et six on approfondira davantage sur les questions de gouvernance Design-Time et Run-Time en essayant de présenter les différents sujets à l aide des illustrations explicites pour montre en quoi consiste ces étapes. Enfin, le lecteur assistera à l implémentation d un prototype de gouvernance Run-Time qui sera développé avec un outil professionnel utilisé dans le déploiement et de renforcement (enforcement) des politiques de gouvernance 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 de l entreprise. Il est connu que les organisations possèdent des structures organisationnelles bien définies qui reflètent l assignation des responsabilités auprès de son personnel. A chaque niveau de cette structure on trouve des spécialistes qui ont leur propre agenda et qui ne sont pas forcement d accord avec l implantation d une nouvelle architecture d entreprise, surtout s ils se voient affectés par de tels changements. Ce refus aux changements causé par la politique organisationnelle [Laudon and Laudon 2001, p. 98] d une entreprise est un problème connu qui surgit lorsqu on veut modifier ou implanter un nouveau système d information. Donc, SOA n échappe pas à cette règle car elle introduit des nouveaux rôles que, 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 (SOA implémente des processus métier) on peut espérer qu elle impacte directement ou indirectement ces structures organisationnelles. Un autre facteur de risque lié aux questions d organisation est celui des méthodes de développement utilisé dans SOA. En effet, pour bien implémenter SOA et ses composants individuels on doit introduire une approche de développement différente de celle utilisée jusqu à présent pour les applications orientées composants. Cette nouvelle approche devrait inclure les étapes de recherche et d identification de services en vue de faciliter leur réutilisation et de raccourcir le temps de développement par rapport aux méthodes traditionnelles [Arch2Arch 2006c, p. 16]. Ces étapes sont essentielles pour optimiser les investissements réalisés dans les TIs car elles permettent de s assurer que l on n a pas des services 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 nouvelles ressources à l échelle de toute l entreprise. Des ressources techniques telles que les moteurs BPM, les ESB, les registres, et les référentiels qui sont nécessaires pour fournir un bon support aux nouveaux services mais aussi à ceux déjà déployés. Donc, ces composants techniques doivent être intégrés dans l infrastructure des TI suivant un plan d exécution bien défini. Dans ce cas, le risque est lié à l éventuel couplage avec les solutions propriétaires des vendeurs comme Microsoft et Sun MicroSystems. Le plan d exécution de la stratégie SOA

40 La gouvernance SOA 39 doit au moins mentionner l obligation de disposer de produits basés sur les protocoles et standards 3 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 à une contrainte de compatibilité par rapport aux services qui viendront après. Même lorsqu on prétend garantir l interopérabilité en comptant sur les standards il peut arriver que les services ne soient pas universellement accessibles. Cela veut dire que SOA devrait permettre l 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 on doit prendre de décisions sur le nombre de standards de données que les services doivent supporter tout en veillant à leur prolifération incontrôlée 4. Un autre risque lié aussi au cycle de vie de SOA (cycle de services inclus) est l absence d un mécanisme de partage des nombreux documents ou artefacts générés à la fin de chaque étape du cycle de vie. Que ce soit sous la forme d un système de registre ou d un inventaire manuel de services, il est important de pouvoir publier les services ainsi que leurs documents. Ces derniers sont aussi importants que les services eux-mêmes car ils sont essentiels pour leur utilisation actuel et future [Brown 2007, p. 223]. Par conséquence, la négligence des documents 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.

41 La gouvernance SOA 40 Aligner le TI avec les réglementations dictée par le haut management et l environnement de l entreprise (lois, normes, etc.) est l un de soucis de la gouvernance TI et SOA car à présent les technologies de l information sont le moyen «par excellence» avec lequel les entreprise réalisent la plupart de ses activités, inclus la gouvernance d entreprise elle-même [Bloomberg 2004]. Donc, il est important de disposer d un cadre de procédures et de politiques qui dictent le comportement de SOA dans des scénarios comme l intégration d applications, l échange d information (interne et externe) et le commerce B2B. Comme pour le cas de la gouvernance d 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 statistique citée dans l article [Mitra 2005, The importance of IT and SOA governance] confirme cette tendance de la manière suivante : «( ) firms with a well exercised IT governance have had 20 percent greater profit margins than their counterparts who make very little or no investment in IT governance, (...) 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 une SOA pour effectuer leurs transactions commerciales. Il s agit d une illustration basée sur la conformité 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 SOA comme les niveaux métier sont tous les deux soumis aux contraintes de conformité provenant de l extérieur de l entreprise. Cependant, SOA est encore exposée aux différentes exigences internes qui dictent (SOA guidée par le business) comment elle doit être implémentée pour supporter correctement les affaires d une organisation. C est pourquoi on a représenté les deux architectures avec des formes différentes, rectangulaires et ovales, car cela permet de montrer l influence de certains aspects de conformité sur le comportement de SOA.

42 La gouvernance SOA 41 Mis à part les aspects de conformité, toute implémentation de SOA doit surmonter les défis concernant 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é. En effet, lorsqu on entend dire que SOA permet d implémenter une architecture agile et flexible on ne mentionne jamais les contraintes de sécurité inhérentes à l interaction entre deux ou plusieurs services. En principe pour qu un service puisse être utilisé de manière sécurisée il faut qu on puisse compter sur des mécanismes d identification permettant d authentifier un client ou un consommateur. Il faut aussi que les droits d accès aient été identifiés pour garantir que le client utilise les ressources dont il a vraiment le droit de manipuler. Les informations échangées par les services doivent aussi être protégées contre la modification et l interception de messages qui pourraient survenir d une tierce partie. Dans un environnement faiblement couplé, tel que celui promue par SOA, certains modèles de sécurité traditionnels, notamment l embarquement de la logique de sécurité dans l implémentation du service, ne sont pas recommandés car il faut que les services restent autonomes (portables) et réutilisables partout ils seront déployés, sans recourir à des changements couteux. A cela s ajoutent les contraintes d interopérabilité des services qui est basé sur l utilisation exhaustive des standards industriels à tous les niveaux de collaboration possibles (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 un contexte d intégration tel que celui du Supply Chain Management où les partenaires ont 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ètement flexible qui permet à plusieurs entreprises de location de voitures de rester informées sur les horaires d une compagnie aérienne. Pour ce faire, les différents systèmes communiquent à

43 La gouvernance SOA 42 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 location de voitures peut s abonner au service de la compagnie aérienne et devenir client du service web qu elle expose. Il est aussi possible d ajouter dans cette architecture d autres partenaires pour 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 au niveau 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 lesquelles ils se basent (XML, SOAP, WSDL, UDDI) ont été conçues dans l hypothèse des échanges ouverts 5. Donc, on peut dire que n importe quel client (abonné ou pas) peut accéder au service proposé 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 contexte réel, les différents partenaires (Figure 15) se trouvent dans des domaines de sécurité différents caractérisés par leurs propres politiques de sécurité, des stratégies de gestion d identités particulières, des dispositifs de détection d intrusion, etc. Dans ce contexte, il faut permettre que les services collaborent entre eux, comme dans les cas de chorégraphie et composition de service, 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 davantage les applications, les services et les machines que les personnes elles-mêmes [Pulier and Taylor 2006, p. 111]. En effet, lors de l exécution d un processus métier impliquant plusieurs partenaires, comme l exemple de la Figure 15, la sécurité doit avoir lieu de manière automatisée et sans aucune intervention humaine. Les phases d authentification et autorisation sont déléguées aux différentes plateformes SOA de sorte que chaque service reste, au même temps, accessible et protégé. Dans les cas de l implémentation SOA par les services web, on doit considérer aussi la capacité des messages SOAP sur HTTP de passer les firewalls sans trop 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ères traditionnelles (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, leur disponibilité 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 la qualité n est pas supporté, SOA n est pas capable de dire si ses services sont assez rapides ou pas, et de garantir la reprise de panne dans le meilleur délai possible. Le deuxième point est celui qui permet de mieux planifier l infrastructure de services pour que ces derniers soient accessibles comme prévu. Si l on ne fait pas attention aux aspects de disponibilité, il y a un risque 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 modules logiciels dont le domaine fonctionnel doit rester bien défini. En découplant les aspects fonctionnels du service de ceux concernant la sécurité on évite l introduction d un domaine autre que celui défini par frontière fonctionnel du service.

44 La gouvernance SOA 43 services peut varier dans le temps pour toucher les extrêmes de la sur-utilisation et la sousutilisation. Dans ce cas, la surveillance de leur disponibilité permettrait de prendre de décision sur une éventuelle réplication afin de maintenir la performance (respect du SLA) ou abandonner son exploitation [Pulier and Taylor 2006, p. 127]. Enfin, les accords au niveau de service 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 des indicateurs importants tels que le temps nécessaire pour traiter une requête, les nombre de messages reçus et envoyés toutes les heures, le nombre de transactions rejetées et acceptées par jour, etc. Donc, pour garantir le succès à long terme de SOA il est apparu un concept déjà connu dans le haut management d entreprise qui est celui de la gouvernance. Cette dernière est un processus de régulation et de contrôle qui permet d avoir une visibilité étendue sur différents aspects clés d une organisation. Dans le contexte des systèmes d information on a vu en premier la gouvernance TI qui concentre ses efforts sur les processus de décision affectant directement les systèmes d information (personnes, logiciels, matériel, etc.). La gouvernance SOA étend les principes et pratiques de la gouvernance TI et établi un cadre de gouvernance focalisé sur les architectures orientées services. C est dans ce contexte qu il est possible de minimiser les risques énumérés ci-avant L origine de la gouvernance des TI De nos jours, les entreprises de type société anonyme sont équipées de mécanismes de gouvernance permettant d aligner les intérêts des dirigeants sur celui des actionnaires. Les premiers, qui détiennent le contrôle opérationnel de l entreprise, possèdent une grande marge de 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 objectifs stratégiques, ce qui est une source importante de conflit avec les propriétaires (problème Principal-Agent cité dans le cours [Isakov and Ledentu 2005, Chap. 1]. Ces derniers, connus comme des actionnaires, apportent le capital nécessaire à la marche des affaires mais ne disposent 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 donnant naissance à la gouvernance d entreprise. Ces problèmes existent depuis longtemps à cause de la dissociation entre la propriété et la gestion qui caractérise la structure des sociétés anonymes. 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 une part, il y a des coûts tels que les dépenses de contrôle, des dépenses de dédouanement et des pertes provenant du manque de cohérence entre la propriété et la gestion. D autre part, il y a des coûts importants lorsque les cadres dirigeants engagent la société dans des projets inutiles ayant un grand potentiel de risque. Par conséquence, si les coûts augmentent, les bénéfices annuels sont affectés directement entraînant une diminution des résultats financiers et même mettre en péril la pérennité de l entreprise.

45 La gouvernance SOA 44 La gouvernance d entreprise est un modèle de haut management composé d un grand nombre d acteurs impliqués dans différents dispositifs de surveillance et mécanismes d incitation et des contraintes. Une définition formelle très citée dans les travaux de gouvernance est celle que l on trouve dans [Wikipédia-gouvernance 2008, Gouvernance d'entreprise] : «La gouvernance d entreprise est l ensemble des processus, réglementations, lois et institutions 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 la gouvernance d entreprise. On y aperçoit les processus tels que l audit, l OPA, les rémunérations et la surveillance. Les réglementations et lois sont représentées par les codes de bonnes pratiques et les droits de votes des actionnaires. Quant aux institutions, elles peuvent se présenter sous la forme de comités ou tout autre organe de contrôle comme le conseil d administration, les organes de révision et les marchés. Le tout décrivant de manière générale le contenu de la gouvernance d entreprise [Gilardi 2006, Chap 2.1]. Tableau 2: Mécanismes de gouvernance d'entreprise Mécanismes internes Conseil d administration Système de rémunération Organe de révision Activisme des actionnaires Structure de financement Mécanismes externes Marché d actions Réviseurs de la société Agences de notation Lois et réglementations Marché d obligations

46 La gouvernance SOA 45 Pour mieux comprendre la notion de gouvernance d entreprise, il ne suffit pas de se contenter avec une définition formelle. En effet, au-delà des concepts de base présentés ci-dessus, le gouvernement d entreprise est un système de relations qui agissent comment des mécanismes de 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égories distinctes de ces mécanismes comme le montre le Tableau 2. En principe, un système de gouvernance d entreprise se base sur un processus global constitué de quatre phases, à savoir l exécution des mécanismes internes, la divulgation des informations, l exécution des mécanismes externes et l application des sanctions. Les mécanismes internes ont pour mission d améliorer sensiblement la direction de l entreprise en veillant, entre autres, à minimiser les coûts engendrés par les conflits d intérêts. Chaque tâche réalisée à ce niveau permet de produire 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 les excès provenant de la gouvernance interne. Les mécanismes externes sont une sorte de pression «naturelle» (agences de notation, etc.) contre les procédés contraires aux intérêts des propriétaires. Comme moyen d action, ils offrent la possibilité de sanctionner la direction de 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 pour introduire les questions concernant la gouvernance des technologies de l information et de la communication (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 inspire profondément des principes de la gouvernance d entreprise et maintient des liens de dépendances avec cette dernière. On pourrait même dire, selon mon opinion personnelle, que si 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 TI trouve son origine dans la gouvernance d entreprise, il y a une certaine divergence quant aux principes régissant la gouvernance des TI. Depuis la perspective américaine on considère que la gouvernance des TI existe comme un résultat direct de la gouvernance d entreprise, plus précisément à partir de la loi SOX 6 adoptée en 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 approche managériale nécessaire, vu le rôle de plus en plus stratégique joué par les systèmes d information. Elle est centrée sur les aspects de performance des TI et leur apport concret aux objectifs stratégiques de l organisation. Plus concrètement, aucune entreprise ne peut fonctionner sans le support des infrastructures informatiques et plus généralement des systèmes d information. Que ce soit pour faire de transactions importantes ou pour communiquer des données simples, on utilise des personnes, des machines et des logiciels pour 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 comptes certifiées et les rend ainsi pénalement responsables. Elle assure aussi l indépendance des auditeurs.

47 La gouvernance SOA 46 (fondation) des affaires de n importe quelle organisation. Ceci est connu comme le concept de l 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 dire qu ainsi comme la gouvernance d entreprise résout certains conflits et améliore la performance de l entreprise, la gouvernance des TI optimise la performance de l infrastructure des TI et se révèle un moyen efficace d aligner les intérêts des différents responsables. Les dirigeants des TI peuvent être vus comme (dans le rôle) la direction dans le modèle de gouvernance d entreprise et ils doivent opérer dans l intérêt des propriétaires des systèmes qu ils administrent, à savoir les cadres dirigeants, et plus généralement, l entreprise dans son ensemble. On dit que les cadres dirigeants (haut mangement) sont les propriétaires des TI car les budgets globaux dont dispose le département informatique est approuvé par ces cadres dirigeants. Cependant, la gouvernance de la TI est un domaine à part entière qui s est développé pour répondre aux différents besoins apparus dernièrement avec l importance stratégique des systèmes d information. Elle englobe aussi bien des questions financières comme des aspects de gestion et organisation. Dans [Georgel 2005, p. 6] l auteur identifie huit piliers sur lesquels est 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 des processus, la valeur économique des ressources informatiques, la gestion de la gouvernance et des ressources humains, le contrôle et l audit des processus et des systèmes, la gestion de la performance des services délivrés et l alignement sur la stratégie de l entreprise et les processus. Dans la suite ces différents éléments seront présentés plus en détails.

48 La gouvernance SOA Le contenu de la gouvernance des TI Jusqu à maintenant on s est limité à décrire de manière globale le concept de gouvernance des TI en présentant séparément les deux interprétations fondamentales utilisées par les experts des 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 au centre 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é de l organisation aux exigences légales et à optimiser la performance fonctionnelle des TI, le tout au profit de la gouvernance supérieure et globale de l organisation» [Blanc 2007]. Il existe cependant beaucoup d autres définitions décrivant de manière plus formelle ce qui est la gouvernance des TI. Par exemple, selon [Weil and Ross 2004, p. 8] la gouvernance des TI désigne : «La spécification d un cadre de droits décisionnels et des responsabilités en vu d encourager des comportements souhaitables dans l utilisation des TI» (Notre Traduction). Dans la première définition mentionnée ci-dessus on remarque que la gouvernance se focalise sur 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 partie de l ensemble des mécanismes de la gouvernance globale (d entreprise) instaurées dans l organisation. Dans ce contexte on peut faire référence aux objectifs stratégiques de l entreprise qui posent les fondations pour que la gouvernance des TI puisse à son tour définir sa vision et ses propres objectifs. Par exemple, si l un des objectifs majeurs concerne la fourniture d un service rapide et sûr à ses clients, ce même objectif devrait être traduit au niveau 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 faut d 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 de la gouvernance d entreprise on a mentionné l organe de révision, le conseil d administration et l actionnariat en tant que mécanismes de gouvernance veillant sur les intérêts de l entreprise. Avec la gouvernance des TI il se passe la même chose, il faut qu il y ait en place des organismes portant des responsabilités bien spécifiques et bénéficiant de certains pouvoirs de contrôle sur les opérations exécutées au moyen des systèmes d information. C est à ce moment 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 leurs responsabilités et objectifs.

49 La gouvernance SOA 48 chacun est invité à prendre. Par exemple, on défini les personnes autorisées (qui) à prendre de décisions sur l architecture des applications (type de décisions), le contexte et le lieu approprié dans lequel ces décisions doivent être prises (où) et les procédures pour prendre de telles 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ègles et normes dictées par les corps de direction ainsi que les lois auxquels est soumise l organisation. Dans ce cas, les responsables de la gouvernance des TI vont établir des politiques de différente nature et à différents niveaux. Un exemple typique de ce qui peut être une 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 niveau des infrastructures des TI qu au niveau de l architecture globale afin de garantir l existence de tous les aspects de la sécurité informatique 8. Ces politiques doivent répondre à des questions de 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 celles mentionné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èmes d information. Cela est un aspect très important dans la gouvernance des TI car elle dicte, en quelque sorte, ce qui est permit ou pas dans chaque pays. Un exemple concret est celui qui fait référence aux risques encourus par les entreprises américaines ou étrangères implantées aux USA. En effet, les entreprises qui sont sur le sol américain sont assujetties à la loi sur l embargo imposée par le gouvernement à certain pays qu il juge dangereux. Dans un scénario comme celui-ci, la gouvernance des TI devrait veiller à empêcher qu aucun service informatique de l entreprise ne soit utilisé par des compagnies opérant sur ces pays car une telle violation entrainerait des conséquences graves tant d ordre financière comme d ordre pénal. Actuellement en Suisse il existe un projet de modernisation du droit des sociétés anonymes et du droit comptable. Comme dans le cas de la SOX citée auparavant, elle cherche à renforcer la gouvernance d entreprise, confère plus de souplesse à la structure du capital et promu l utilisation des TI dans l assemblée générale. Dans ce dernier point il y a une référence directe 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é.

50 La gouvernance SOA 49 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ère par visioconférence et mettre sur pied une assemblée générale virtuelle grâce à l Internet ou Intranet. Du point de vue des TI ces modifications posent un certain nombre de défis, notamment au niveau de la qualité des données à publier, des processus de publication de rapports et l incorporation des nouvelles règles métier dans l infrastructure des TI. Pour ce faire, la gouvernance des TI doit définir certains principes autour des applications, des données et des règles métier utilisées dans les systèmes d information. Par exemple, si l entreprise compte sur 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 des systèmes hautement automatisés et fiables permettant de se rapprocher du risque zéro lors de la génération des rapports et la saisie des données par les employés. En l occurrence, on se réfère aux systèmes de la Business Intelligence (BI) offrant des fonctionnalités d extraction et consolidation de données ainsi que la génération automatique de rapports 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 TI qui se focalise sur la gestion efficace de chaque aspect lié aux services. La manière dont ces derniers doivent être gérés diffère des pratiques jusqu à maintenant utilisées par rapport aux systèmes traditionnels dû aux changements importants induits par SOA. Par contre, il ne s agit pas d un projet de refonte de gouvernance mais plutôt d une suite basée sur les piliers déjà existants dans la gouvernance des TI. Dans la Figure 18 on peut voir ces différents piliers, ou domaines d intérêt, ainsi que leur relation dans un modèle de gouvernance TI. Ces piliers sont l alignement des stratégies métier et TI, la valeur des livrables (Value delivery), la gestion de la performance, le management des ressources et des infrastructures et la maîtrise des risques sur le plan technologique [Mitra 2005, Governance responsibilites].

51 La gouvernance SOA 50 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 le dé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 TI commencent à fournir de la valeur (actifs, etc.) à l entreprise. La valeur dérivée des TIs permet de satisfaire les besoins stratégiques et opérationnels exprimés par le niveau métier. Il s agit de lui fournir tous les services espérés (Just-in-Time) avec l infrastructure correcte et le personnel adéquat. Afin de permettre la continuité de l activité TI, il est important d effectuer une gestion proactive et réactive des risques liés aux actifs. En effet, aujourd hui les systèmes d information sont exposés à plusieurs dangers qui peuvent mettre en péril l entreprise la plus solide 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, pour avoir une meilleure visibilité sur les opérations et la stratégie adoptée on doit mettre en place un système de mesure de la performance TI. Dans ce domaine on s intéresse au monitoring des résultats permettant d établir un bilan actuel de l état du TI dans l entreprise et de fixer des nouveaux objectifs. En principe, la mesure de la performance se réalise selon quatre perspectives différentes, à savoir les clients, les objectifs financiers, les processus métier et le capital humain [IT Governance Institute 2003, p. 29]. Dans la gouvernance SOA, l alignement stratégique s étend au domaine des applications orientées services ou applications composées. Il n est concerne ni les applications orientées composants ni les architectures client-serveur traditionnels car cela est déjà pris en charge au niveau 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 les niveaux d investissements en SOA (finance, personnel, infrastructure, etc.) qui correspondent le mieux avec les besoins métier. Garanti les niveaux de service SOA adéquats pour que la stratégie métier puisse être déployée avec flexibilité et rapidité et prend des décisions sur les stratégies d implémentation de SOA.

52 La gouvernance SOA 51 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 de l alignement stratégique. En principe, il est important que la gouvernance des TI puisse établir une relation avec le niveau métier. Elle peut se faire au moyen des outils d analyse stratégique, par exemple avec l application des méthodes de portefeuille et d analyse de la chaîne de valeur qui sont employées tant pour les directions métier que pour les directions des TI. Comme on peut le constater dans ce tableau il n y a pas de relation directe entre les stratégies métier et l infrastructure des TI. Cela s explique en partie par le fait que les stratégies comme celle de domination par les coûts, peuvent se décliner en plusieurs solutions métier distinctes (petits prix ou cash-flow réinvestis) et ne déclarent aucun concept se référant directement aux TI. C est ensuite que grâce aux mécanismes de gouvernance (méthodes de gestion de portefeuille, etc.) qu il est possible de déterminer le potentiel des TI dans un contexte précis et de fournir une direction claire aux unités de gestion des TI (gestion des risques, gestion de configuration, etc.) pour l implantation de ces solutions.

53 La gouvernance SOA 52 Figure 19 Structure de gouvernance TI et SOA. Dans le contexte de SOA, la colonne «Solutions TI» du Tableau 3 est évidemment implémentée d une autre manière. Ces solutions TI sont implémentées avec la technologie de services et demandent quelques adaptations des structures de gouvernance existantes. Comme on peut le voir dans la Figure 19, une structure de gouvernance TI se compose principalement de trois niveaux, à savoir le niveau stratégique, le centre d excellence en gouvernance et le niveau de gestion TI. SOA introduit en plus une nouvelle entité connue sous le nom de domain ownership [Bloomberg 2004] qui permet de décomposer une entreprise en plusieurs domaines de services ayant en commun un contexte métier. A l intérieur d un domaine de service, les cadres métier et TI doivent assurer la qualité des applications et des services SOA en prenant en charge toutes les phases de leur cycle de vie. Ils sont responsables par exemple de maintenir les interfaces avec les services d autres domaines et de négocier leurs propres niveaux de services (SLA). Selon [Bloomberg 2004] dans chaque domaine on doit trouver une liste de rôles comme celle qui suit : Développeurs de domaine : Dans cette catégorie on trouve les personnes impliquées dans 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 le domaine vis-à-vis des cadres métier. Il est chargé de gérer le domaine comme une unité de service informatique fournissant des services aux unités métier et aux autres domaines de services SOA. Analyste fonctionnel orienté service : C est le rôle assigné aux personnes chargées de capturer les besoins métier et d identifier les services SOA à implémenter. Ils produisent aussi les modèles de données et travaillent en collaboration avec les différents architectes. Line of business representative : Responsable de capturer les services métier qui devront être supportés par l initiative SOA. Pour ce faire il communique les besoins métier aux responsables TI.

54 La gouvernance SOA 53 Service tester : C est le rôle assigné aux développeurs ou autre personnel SOA pour dé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 la gouvernance TI se centre sur quatre axes principaux, à savoir les rendements financiers, la satisfaction 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 aspect spécifique de l efficacité des solutions TI et la valeur que celles-ci ajoutent aux affaires de l entreprise. Ils permettent de disposer des indicateurs de performance clés permettant de savoir 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 gouvernance TI. 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 architecture et 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, la gouvernance TI continue à utiliser les modèles économiques cités ci-dessus, tandis que la gouvernance SOA fourni les informations telles que les statistiques de fréquence d utilisation des 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 en doublons, si possible, qu il appartient à plusieurs projets à la fois (réutilisable) et qu il ne soit pas 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 service pour retourner une réponse au consommateur (important dans le mode synchrone) et l indisponibilité sont des données liées à la performance. Dans le cas des services web, le temps de réponse est un paramètre à surveiller de près car l un des inconvénients de XML/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 la performance SOA, notamment le niveau de granularité des fonctionnalités, des messages et du service et les opérations de transformation effectués par les «nodes» de traitement de messages. 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

55 La gouvernance SOA 54 La gestion de la qualité du service (QoS) représente un autre aspect de la gestion de la performance SOA. La qualité des services est une question qui touche aussi bien la performance Run-Time que celle de Design-Time. Quoi qu il en soit, la gestion des QoS est souvent implémentée à l aide d outils d administration de service qui permettent de définir des paramètres de qualité et de les comparer avec ceux définis au niveau des SLAs. Au design-time il existe des principes et des patterns orientés service qui permet de garantir la qualité en fonction du modèle de service que l on veut développer. Les grandes lignes de la QoS sont fournies principalement par les contrats de services comme le SLA qui établit les niveaux 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 le management des processus métier comme une des facettes de la gestion de la performance SOA. En effet, les services de processus supportent les processus métier qui eux à leurs tours sont 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 BPM permet de changer d une manière dynamique le flux des opérations afin d optimiser les résultats. Parallèlement au module de gestion de processus, les outils BPM fournissent un module d orchestration [Arch2Arch 2006c, p. 23] pour répercuter rapidement les changements effectués au niveau des processus sur les services. Donc, les mesures relevées au niveau des processus métier supportés par SOA permettent aussi de faire une analyse de corré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 au domaine 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 investissements financiers en TI, la sécurité de l information et les risques opérationnels. Pour mettre en place un 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.) auquel l entreprise correspond le plus. Cette étape d analyse comportementale permet de comprendre jusqu à quel point les systèmes d information peuvent rester protégés des éléments internes et externes à 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 menace pour un projet TI et SOA. A partir de cette analyse l entreprise est en mesure d estimer en termes de probabilité la réalisation d un risque et les conséquences possibles. L analyse de l impact qui est une méthode permettant de capturer les pertes potentielles (totales et partielles) suite à l occurrence d un risque. Elle fourni une description détaillée sur la nature de dommages, les ressources nécessaires pour les contrôler et les délais toléré pour que les services soient rétablis.

56 La gouvernance SOA 55 La gestion de la continuité des services permet d établir un plan de conduite des affaires dans tous les cas de figure [Descloux 2004, Chap. Plan de sécurité]. Dans le cas du rétablissement de la continuité après un sinistre, il fait référence au plan de reprise graduelle, intermédiaire ou immédiate. La gouvernance TI et SOA doit choisir parmi les stratégies de gestion de risque telles que la mitigation, 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 place d une infrastructure de protection caractérisée par des mécanismes de contrôles internes et des plateformes de sécurité informatique. Le transfert du risque est stratégie permettant de partager les risques encourus ou de les 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 des problèmes majeurs. Dans le contexte de SOA, la gestion des risques vise le cycle de vie des services pour réduire et 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 aux besoins métier car elles ne peuvent pas supporter le flux de travail comment on aurait voulu. 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 est le 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 et unique projet ne sont pas convenables pour SOA car toute possibilité de réutilisation est 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 projet seulement et dont les caractéristiques ne s ajustent pas aux utilisations futures. Conception incomplète: Lorsque seulement une partie du service est achevée, comme par exemple quelques une de ses fonctionnalités, il y a un risque potentiel de devoir revenir 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, toutes les détailles de conception devraient être terminés pour éviter que l apparition des nouveaux 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 est tout à fait réel. Des problèmes liés à la gestion des registres de services et à la politique 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 des risques, aussi bien sur le plan financier qu opérationnel. Au niveau financier, une politique

57 La gouvernance SOA 56 continuelle de surinvestissement ou de sous-investissement dans le développement des services peut poser des problèmes de rentabilité et pousser l initiative SOA vers l échec définitif. Au niveau opérationnel, la gouvernance SOA peut réduire les risques en développant un équilibre entre les stratégies de formation et «enforcement». D une part, une politique de formation efficace garantie que les procédures et les standards d opération sont connus des utilisateurs et que ces derniers sont en mesure de travailler correctement. La formation est un mé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 se produisent 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 en Run-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 de sécurité de l information et à ce niveau il n existe pas beaucoup de différence entre la gouvernance 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 des années par les responsables TI. Qu il s agit d une architecture traditionnelle ou SOA, la gouvernance doit pouvoir établir une stratégie de sécurité, définir des contrôles, des politiques, des standards technologiques ayant une portée globale dans leur application. Elles doivent aussi implémenter un cadre de gestion permettant définir les actions à mener en cas d occurrence de ces risques. Pour montrer la manière dont la sécurité pose des problèmes de gestion à SOA, on va utiliser comme 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 des technologies propriétaires, il est plus difficile de connaître leur vulnérabilité car leurs interfaces 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 faciliter l échange d information.

58 La gouvernance SOA 57 Figure 20: Communication non sécurisée entre le fournisseur et le consommateur de service [Cf. Ultes- Nitches 2006, p ] Dans un contexte d utilisation simple tel que celui illustré dans Figure 20, un fournisseur et un consommateur de service échangent des informations qui ne sont pas protégées contre les risques de déni de service (DoS), sniffing, modification et usurpation d identités. Dans le premier cas de figure, un service non sécurisé peut facilement être la cible d attaques de déni de service car une des faiblesses des WS est qu ils manquent de mécanismes d authentification et autorisation pouvant identifier les clients ainsi que l usage qu ils font du service. Comme résultat, il est tout à fait possible de submerger le service en augmentant le volume 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 état mais ceux comme les services de processus peuvent être l objet d une attaque de type buffer overflow en modifiant les informations d état qu il conserve dans une session. L absence de contrôle d accès permet aussi de déclencher des opérations et d accéder aux sections privilégiées sans y avoir droit. Dans le deuxième cas, l attaque appelée eavesdropping est une technique d écoute passive des messages transitant dans un réseau. Souvent, les WS communiquent en passant par plusieurs intermédiaires qui routent le message à l intermédiaire suivant dans la chaîne. Cette situation est idéale pour intercepter les messages et lire son contenu. Sachant que la plupart des attaques viennent de l intérieur, le message peut être lu après avoir entré dans la zone de confiance 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 (faisant abstraction de la pile WS-Security) qui laisse leur contenu circuler en clair à l intérieur du systè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 intercepteurs SOAP [Pulier and Taylor 2006, p. 113] qui sont des systèmes crées pour lire, modifier et

59 La gouvernance SOA 58 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é minimale d 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 alignement stratégique a lieu dans la phase initial de SOA et dans la planification du «Roadmap» qui défini les étapes pour déployer les solutions métier et l infrastructure requise pour les supporter [Arch2Arch 2006a, p. 17]. En effet, du moment où le projet SOA est lancé il faut analyser 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 la frontière entre les gouvernances des TI et SOA devient un peu flou car on suppose que la gouvernance des TI est déjà responsable de surveiller de près l ensemble des biens et ressources 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 une entreprise orientée services on fait toujours référence aux objectifs et stratégies globaux. Dans la Figure 21 on illustre sous forme de diagramme UML le contenu d un Roadmap. Ce sont un ensemble de principes diverses et de formes d architectures qui sont prises en compte pour son élaboration. L étiquette «inclus» représente l inclusion, dans le Roadmap, des règles et contraintes se référant aux principaux éléments d un système d information (données,

60 La gouvernance SOA 59 information, métier, application, etc.). Ces principes de SOA sont rédigés sur la base des objectifs et de la stratégie globale et représentent un point important où les responsables de SOA 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-service Provides a single portal for employees to perform all personal administrative tasks, such as address change, benefit enrollment, time and expense reporting, and employee onboarding Single view of the customer (SVC) Provides an SVC across all business silos based on roles and information needs of the customer Portal Authentication, authorization, single sign-on Skins/skeletons for a consistent look and feel EAI Integration with back-end applications Business processes that run across multiple systems Portal Authentication, authorization, single sign-on Skins/skeletons for a consistent look and feel Integration with Business Intelligence (BI) dashboard Shared data services Aggregation of data from multiple sources Exposure of shared data services to access customer information Enterprise service bus Capture of events from transaction systems to populate the customer registry, ODS, synchronize data, etc. Services infrastructure for 150+ shared services Regulatory compliance Requires business process orchestrations Service registry Discovery of all shared business and data services Business process management Execution of business process to identify abnormalities (based on external events) Grâce au Tableau 5 on peut remarquer la relation qui existe entre les solutions métier et les services 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.

61 La gouvernance SOA Planification et exécution de SOA Avant de présenter les détails de la gouvernance SOA, il est important de prendre un peu de recul afin d avoir une vue d ensemble sur la dynamique de SOA, à savoir le cycle de vie de SOA 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âches né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 de travail pour initialiser, développer, exploiter et maintenir les solutions logicielles. En quelque sorte ces sont les processus centraux de création de valeur. Processus de support : Le terme support regroupe les activités utilisées par les processus 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 les questions d assurance de la qualité, de configuration, etc. Processus organisationnels : Au niveau organisationnel il est nécessaire d avoir un ensemble de «super» processus de management capables de gérer les processus de base et de support dans une perspective d optimisation. Ce sont les processus de mangement de ressources et d infrastructure. Dans le contexte de la gouvernance SOA on fait le plus souvent référence au cycle de vie des services comme l objet central autour duquel doivent s appliquer les mécanismes de gouvernance. Cependant on oublie que du point de vue métier SOA est un choix stratégique qui doit être mis en place étape par étape afin d assurer son déploiement à grand échelle. C est pourquoi il est important de considérer son cycle de vie comme un domaine sous la responsabilité de la gouvernance. Cependant, grand nombre de projets ont été lancés sans aucune structure de gouvernance due au nombre faible de services concernés. C est seulement aprè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 de SOA, 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 la Figure 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és d implémentation de SOA en trois phases principales: l initialisation du projet, le dé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 projet par rapport aux critères de l entreprise. Du point de vue de la gestion de projet, cette phase implique des activités d initialisation et d étude préalable qui sont propres à un projet traditionnel, à savoir la proposition de SOA (proposal), l analyse des risques et des enjeux

62 La gouvernance SOA 61 métier, l établissement des estimations budgétaires et des perspectives de retour sur investissement, les délais prévus et les recommandations de faisabilité. Livrables Fiche de projet Rapport de l état actuel des ressources, etc. Livrables Plan de l état futur (métier et SOA) Cycle de gouvernance Initialisation SOA Développement Roadmap Exécution du Roadmap Révision Proposal Alignement, gestion des risques, etc. Etat actuel des TI Composition des équipes Milestones Principes SOA et TI Architectures de référence Modèle de maturité Management de projet et portefeuille Application Données Cycle de vie des services Gouvernance Figure 22: Une vue très simplifiée du cycle de vie SOA Après la phase d initialisation, le cycle génère une série de livrables qui seront appelés dans les phases restantes. Il s agit d un ensemble de documents qui permettent aux cadres supérieurs d avoir une idée globale sur les coûts et bénéfices attendus et, par la suite, décider de l avenir de SOA. La composition des équipes de travail fait aussi partie des activités d initialisation car elle permet de mettre en place une structure ordonnée de professionnels qui seront chargés de diriger et de mettre en place l architecture et ses composants. Cette structure organisationnelle est composée des deux dimensions fondamentales de SOA : Le groupe métier constitué de plusieurs représentants provenant des niveaux stratégiques et opérationnel tels que le conseil d administration, le PDG, et responsables 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. Le concept de Roadmap a déjà été abordé auparavant (voir section 4.2) lorsqu on a mentionné pour la première fois le cycle de vie SOA. Toutefois, il est important de revenir sur ce sujet afin d établir une relation entre la gouvernance SOA et ses différents cycles de vie. En effet, grâce à la Figure 22 on peut constater le moment précis où il serait le plus convenable d établir un plan de gouvernance. Selon ce modèle, il pourrait avoir lieu avant ou en parallèle à la conception des premiers services SOA bien que certaines entreprises attendent (préfère)

63 La gouvernance SOA 62 un niveau de maturité plus avancé pour le faire. Dans touts les cas, il est plus avantageux de commencer le plus tôt possible avec les questions gouvernance pour éviter que l implantation et évolution de SOA ne deviennent pas un incontrôlée. Pour s en convaincre il suffit d imaginer le scénario où les droits et obligations de chacun ne sont pas clairement définis. Si l un des services en opération pose des problèmes à l entreprise ou à une de ses unités d affaire, il devient impossible de trouver un responsable capable de corriger la situation et l 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 de reprendre les affaires les plus vite possible. Cette deuxième phase peut être assimilée au début de la gouvernance SOA car elle est orientée vers les processus de planification et de normalisation. En effet, pour définir les principes SOA et des TI ainsi que l architecture de référence il faut que l on est déjà établi les règles du jeu et les rôles des participants, à savoir les personnes responsables des architectures de données, d information et d entreprise, les analystes fonctionnels, les directives et exigences métier, etc. Parmi les livrables obtenus à la fin de cette phase se trouvent l architecture de référence et les modèles de maturité et de gouvernance SOA. Gouvernance Business service Management Enterprise Security 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 de l ensemble des ressources de TI. Bien que dans ce type de document on ne dit rien sur la gouvernance, il est sous-entendu qu il est le résultat d un processus de décision important concernant 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 une approche évolutive (décider au niveau gouvernance et management) en adoptant les composants qui sont réellement nécessaires. Dans cet exemple on peut constater que les responsables des TI ont décidé de conserver la couche de systèmes légués ainsi que les

64 La gouvernance SOA 63 solutions d intégration d applications traditionnelles. Ils sont aussi envisagé l implémentation d une couche de services [High, Kinder et al. 2005, p. 25] et d une couche web intégrée par la technologie de portails pour donner aux clients une accessibilité total et un point d entrée unique vers l ensemble des ressources de l entreprise. SOA recouvre la totalité des trois couches de ce modèle de référence en réservant un type de service pour chaque niveau. Par exemple, selon la description fourni par [High, Kinder et al. 2005, p. 26] les services d accès qui 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 de traitement de données comme l accès aux différentes sources de données, le business intelligence, 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 un modèle de maturité constituée d un ensemble d étapes clés qui permettront d évaluer l état dans lequel se trouve l organisation par rapport à SOA. Les indicateurs d une échelle de maturité sont en quelque sorte les premiers indicateurs de performance dont dispose la gouvernance SOA pour évaluer l avancement du projet à échelle de l entreprise. Cela confirme ce qui a été mentionné jusqu à maintenant, cet à dire, qu en plus du cycle de vie des services, 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 les services 9. Voici une description générale de chaque niveau de maturité : 1. Le premier niveau de maturité proposé dans cette illustration correspond à une entreprise qui s est limité au développement des services d application. Pour qu une entreprise atteigne le niveau fondamental de SOA il faut qu elle soit en mesure de mettre en place une architecture constituée des services de base comme ceux utilisés pour accéder aux sources de données. C est le niveau d exigence minimale qui consiste à exposer les fonctionnalités dont on dispose déjà dans les systèmes «backend» 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 des entité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 logique mé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 type consommateur ou employé. 3. Le dernier niveau de maturité ajoute une couche supplémentaire qui est celle des services de processus. Ce type de service est très différent des services concertés ou composé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 plusieurs modèles de maturité différents centrés sur un aspect spécifique.

65 La gouvernance SOA 64 état conversationnel tandis que les services de processus doivent conserver l état des informations 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 de SOA. Ce dernier étant un processus de haut niveau englobe tous les aspects de base de la gouvernance 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. Une fois que la gouvernance SOA entre en action, le cycle de vie de SOA devient aussi un objet de gouvernance qui doit être encadré par des politiques, décisions et mécanismes d application des politiques (enforcement). Jusqu à maintenant on a situé le cycle de vie des services dans la phase d exécution du cycle de vie de SOA car c est à cette étape que les activités de développement comme l analyse, la conception, l implémentation, le déploiement et la maintenance des services ont lieu pour la première fois. Or, le cycle de vie des services regroupe toutes ces activités en trois phases distinctes qui sont connues comme les phases Design-Time, Run-Time, Change-Time [Cf. Hoernes and Schwarb 2007].

66 La gouvernance SOA 65 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éments qui revêtent une importance particulière du point de vue de la gouvernance tels que les acteurs, les services et les artefacts. A chaque phase du cycle de vie, il y a un nombre déterminé d acteurs responsables d exécuter certaines tâches comme la capture des besoins ou l implémentation des services. En SOA, le système de gouvernance doit permettre de définir clairement les différents rôles que chacun est autorisé à jouer ainsi que les relations entre ces acteurs. 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, les applications orientées services sont considérées comme des actifs de l entreprise qui consomment des ressources importants, ce qui justifie la mise en place des processus de gouvernance 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 de chaque service. Il est donc important que la gouvernance SOA crée les mécanismes pour faire appliquer les principes du développement orienté service, en particulier la réutilisation et la composition 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 appelle des artefacts. Un artefact, dans sa forme la plus générique, désigne un document ou autre information de support qui est conçus de manière à être réutilisables dans les projets à venir et pas seulement dans les projets courants. Plusieurs aspects concernant les artefacts sont du ressort de la gouvernance comme par exemple la définition des points de contrôle (check points) permettant d assurer l existence des documents essentiels à la fin de chaque étape.

67 La gouvernance SOA 66 Avant de passer à la phase suivante du cycle de vie il faut que la gouvernance approuve les résultats obtenus en les contrôlant de plus près. Par exemple, en faisant appliquer des politiques claires sur le format, le contenu et l emplacement approprié des documents tels que les 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 de chacune des phases du cycle de vie des services. Tout d abord on expliquera la phase de Design-Time en mettant en avant certaines notions de base comme la définition et les objectifs qu elle poursuit. Ensuite on développera plusieurs points concernés par la gouvernance Design-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 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 des services. Dans la première activité on trouve les tâches liées à l analyse orienté service des processus métier, à savoir la définition des exigences métier, l identification des processus métier, la définition des modèles services et l analyse des fonctionnalités et des systèmes existantes. Dans la deuxième activité on trouve les tâches de modélisation de services telles que la décomposition des processus métier en sous-processus, l identification des opérations candidates, implémentation des services et la construction des prototypes. La gouvernance de la phase Design-Time est une discipline de direction qui vise à établir les processus et politiques qui devraient être suivies par l ensemble des ressources engagées dans le 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 de contrôle (check points) permettant de guider les développeurs dans la création, la publication et la maintenance des interfaces de service. La création des services SOA est un processus qui selon [Hoernes and Schwarb 2007] peut se décomposer en trois étapes, à savoir le design de haut niveau, le design détaillé et l implémentation. Pendant chacune des étapes, le processus de développement est guidé par les mécanismes de gouvernance pour gérer l alignement stratégique, les risques et les investissements TI. Pour ce faire, elle doit poser les bases de la création de services en définissant les principes d architecture, les modèles de services et la gestion du portefeuille de services.

68 La gouvernance SOA 67 Quant à la publication des services, le processus est évidemment moins complexe mais il comporte certaines décisions importantes qui vont déterminer si un service est prêt pour être publié dans un registre. Ces décisions couvrent tous les domaines de la publication des services, notamment le registre et les interfaces. On peut citer par exemple, les politiques de réplication des registres et le choix entre les stratégies de fédération ou centralisation des registres. 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, le comportement et les politiques des services. Ce faisant, il est possible de tester l identité des utilisateurs 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 DesignTime et de Change-Time. Pour la gouvernance Design-Time il s agit de gérer le dé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 ces changements 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 de cré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 le l implémentation des services. Premièrement, il faut définir les stratégies de développement qui se révèlent les plus intéressantes pour les services en question. On peut choisir entre deux approches 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 tout d une séquence de sept étapes qui commence par la définition des ontologies de l organisation (types d informations, graphe de relations entre ces informations, etc.) et termine par le déploiement des services. L analyse effectué dans cette approche permet de décomposer l organisation en domaines logiques délimités par les éléments d information communs (données, information, fonctions, etc.). Du point de vue de la gouvernance, la décision de déployer cette stratégie se justifie, d une part, par la volonté de supporter plusieurs types de services (services de processus, métier et de support), et d autre part pour guider le développement de services vers une dimension supplémentaire de flexibilité et souplesse architecturale ainsi que de réutilisation de services.

69 La gouvernance SOA 68 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 applications et services existants afin d identifier ceux qui seront développés par la suite. On analyse par exemple les fonctionnalités et les données contenues dans les systèmes légués en vu d extraire celles qui feront partie des services candidats. En utilisant cette stratégie on cherche surtout à exposer les fonctionnalités des applications existantes sous la forme de services et à bénéficier ainsi des caractéristiques propres aux services «wrapper», telles que des cycles de développement courts permettant de passer d une architecture orientée composants à une SOA de base en très peu de temps, de réduire la complexité du développement, supporter l intégration d application à l aide de services et promouvoir l 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]

70 La gouvernance SOA 69 Design de haut niveau Pendant l étape du design de haut niveau, les analystes fonctionnels et les architectes SOA doivent respecter certaines contraintes pour assurer le succès de SOA. La justification et la spé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 et propriétaires des services que ces derniers ne peuvent être développés que s ils passent avec succès les mécanismes de justification et de spécification. Pour que le développement d un service soit justifié aux yeux de la gouvernance il faut que la gestion du portefeuille ait approuvé sa faisabilité au niveau financier et métier. Cela veut dire que les coûts additionnels d un éventuel développement sont justifiés par le potentiel de réutilisation du service ou par sa stabilité fonctionnelle à long terme [Brown 2007, p. 219]. Du côté de la spécification, la gouvernance doit garantir que celle-ci contient tous les éléments nécessaires décrivant un service. On parle même de réutilisation de la spécification lorsque celle-ci est conçue en considérant son utilisation à long terme qui permet de minimiser les éventuels changements futurs. Dans les sections suivantes on présentera deux éléments de haut niveau qui ont des liens avec les contraintes de spécification et de justification mentionnée ci-dessus. Ces sont respectivement 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 de l établissement des principes SOA. En effet avant de concevoir les services et leurs modèles respectifs, la gouvernance doit établir un ensemble de directives de haut niveau alignées sur les objectifs stratégiques de l entreprise. Les principes SOA doivent donc correspondre à un objectif métier (par dérivation) en clarifiant la manière dont un service doit exister pour soutenir la stratégie de l entreprise. En général, les principes d architecture sont définis dans la phase de conception (Design-Time) et doivent être revus à chaque fois que les objectifs d affaire sont modifiés. Ils se déclinent en quatre types distincts, à savoir les principes d architecture, les principes de données, les principes d application et les principes de technologie. 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 questions d architecture elle-même mais plutôt de l architecture et ses composants, à savoir les services, les données, et la technologie sous-jacente. Dans la colonne de l architecture, le principe de consistance fourni les directives pour assurer qu il n aura pas de conflits de décisions entre les différents projets. Avant démarrer la conception d un service les architectes et développeurs doivent tenir compte de la contrainte de consistance pour ne pas introduire des contradictions dans le comportement de l architecture, notamment quant aux mécanismes de création, recherche, découverte et utilisation des services. Le degré élevé de diversité technologique typique de SOA et son caractère distribué redonne une importance particulière à ce principe car il est important que SOA conserve une certaine cohérence

71 La gouvernance SOA 70 opérationnelle et fonctionnelle afin de garantir les meilleurs résultats et de faciliter les changements futures. Tableau 6: Principes d'architecture Architecture Consistance Abstraction Découplage Services Réutilisation Contrats services Autonomie Données de Centrés documents Partage Sécurité Technologie Interopérabilité Contrôle technologique Flexibilité Un principe d architecture doit être formulé d une manière standard et structurée à l aide d éléments descriptifs simples comme le nom, la définition et les objectifs à atteindre. Le fait d appuyer l établissement des principes sur un format prédéfini permet de faciliter leur compréhension et communication à l échelle de l organisation et non uniquement à l échelle de la gouvernance. Par conséquent, le principe de réutilisation des services pourrait être formulé comme suit : Titre : Services réutilisables Définition : Les services d application (support, wrapper, etc.) doivent être livrés avec un 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 processus mé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 plus rapidement. Caractéristiques de conception : Le contrat de service est considéré comme étant générique et flexible de telle façon qu il soit possible de l utiliser un même service dans 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 le contrôle de versions de services, identifier les services existants et rechercher l ensemble de services de l organisation. Disposer d un environnement de composition de services en temps d exécution et confier le développement aux analystes et architectes confirmés pour garantir un niveau élevé de réutilisation.

72 La gouvernance SOA 71 Le portefeuille de services La notion de gestion de portefeuille est depuis longtemps utilisée par la gouvernance des TI comme un instrument de contrôle et de gestion d applications. Dans le contexte de SOA le portefeuille des services est utilisé pour orienter les décisions que peuvent prendre les architectes et développeurs quant au développement, la réutilisation, l évaluation et la maintenance des services [Remenyi 2006, p. 230]. Grâce au portefeuille ces différents acteurs peuvent 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 est responsable de définir un système de priorisation basé sur les concepts tels que les consommateurs et fournisseurs de services. En procédant ainsi on peut établir un lien de dépendance entre les projets de création de services qui influera sur l ordre dans lequel les services seront développés. Il est aussi possible de créer ce même système à partir de deux critè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 évalue le temps nécessaire pour le rendre opérationnel. Pour que les décisions prises soient basées sur des observations objectives il faut que l analyse sur l impact considère aussi bien les questions d ordre financier (estimation de budget, calcul des coûts, etc.) que d ordre fonctionnel (SOA). Sur la base des résultats de cette analyse on peut donc déterminer l ordre ou la séquence de développement des services individuels.

73 La gouvernance SOA 72 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 classification de services comme celui de la Figure 28. Dans la section 2.2 concernant les modèles de services on a déjà présenté une catégorisation de services basés sur la logique sous-jacente implémentée par les services. Cependant, il existe d autres variantes de classification utilisant des 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ôle temporaire qui jouent les services dans le temps d exécution. Les buildings blocks10 sont utilisés pour apporter une meilleure compréhension de la portée de la logique modélisée par les services, processus et opérations candidates. Leur but est d identifier et de regrouper les différents niveaux de logique qui pourraient se trouver dans une organisation, tels que les processus, services, activités et tâches et de disposer d une vue ordonnée, allant de l unité la plus petite (tâche) jusqu à la plus grande (processus), qui pourrait être utilisée comme guide dans la conception et modélisation, notamment pour informer sur ce que l entreprise entend comme un processus, un service ou une tâche. Pour le portefeuille de service il s agit d une information complémentaire aux modèles de services qui est utilisée pour analyser les services candidats11. La troisième forme de classification concerne les rôles assumés par un service pendant son exécution. Pour être sur qu un service joue un rôle déterminé il suffit de considérer son contexte d utilisation. Si le service est appelé par une application ou un autre service externe il est alors dans le rôle d un fournisseur, dans le cas contraire où c est lui qui utilise un service externe il devient un consommateur. Lorsqu un service n est ni fournisseur ni consommateur Ce sont des unités de modélisation de services Avec le building blocks on peut faire la correspondance directe entre un service candidat et un service concret.

74 La gouvernance SOA 73 il peut jouer le rôle d intermédiaire active ou passif entre deux services ou le rôle de contrô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 gouvernance SOA doit définir les étapes qui conformeront le processus de gestion de portefeuille. Dans la Figure 29 on peut observer un processus de gestion de portefeuille recommandé dans le cadre des «ITIL12 best practices» [Macfarlane and Rudd 2006]. La première étape permet de définir le portefeuille de services en collectant l ensemble des services existants ainsi que les informations les plus pertinentes. Les services candidats doivent aussi être pris en considération afin de pouvoir dégager les capacités financières et matérielles dont compte l entreprise pour développer des nouveaux services. Dans la deuxième étape on analyse les services récemment identifiés afin de décider s il vaut mieux développer un nouveau service ou simplement réutiliser un service déjà existant. La troisième étape se réfère à la phase d 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és soient produits selon les règles préétablies par la gouvernance. Pour terminer, on publie les diffé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 et les caractéristiques de design tels que la performance, la fiabilité et la qualité des services 12 ITIL = IT Infrastructure Library

75 La gouvernance SOA 74 [Hoernes and Schwarb 2007]. Au niveau de la gouvernance, il s agit de gérer le cycle de vie des contrats de services, la standardisation des données et la conformité du design par rapport aux contraintes de performance, fiabilité et qualité de services. En effet, la gouvernance SOA se charge de définir le contrat de service du point de vue métier en décrivant les capacités fonctionnelles du service ainsi que les différents messages que celui-ci devra échanger avec les autres applications. Comme on peut le voir dans la Figure 30 il existe trois types de contrats de services qui se différencient par la nature du partenaire que l on a affaire. En général, les accords sur les niveaux de services (SLA) se situent entre les clients et les services établissant un accord formel sur sa livraison et son utilisation. Les contrats passés entre les domaines d affaires d une entreprise sont désignés comme des accords aux niveaux opérationnels (OLA) et lorsque le développement et la livraison des services sont supportés par 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 SLAs qui est très lié au développement des services. Le développement des SLAs a une place centrale dans le succès de SOA car il permet de produire les accords sur les niveaux de services qui lieront les clients et les fournisseurs d une manière formelle. Dans [Maurer, Matlus et al p. 7] on rappelle que pour développer une SLA il vaut mieux de suivre une méthodologie bien déterminé et adaptée aux besoins de chaque organisation. Pour ce faire, ils recommandent de prendre en compte les facteurs suivants : Identifier les besoins : Ce premier facteur permet d identifier les besoins des clients qui sont à l origine de la demande de service. Une question simple permettant de capturer les exigences des clients est de se demander pourquoi ces derniers veulent-tils utiliser le service ou quelle est leur motivation principale?

76 La gouvernance SOA 75 Définir les objectifs : Le deuxième facteur clés se focalise sur la définition des objectifs que les clients devraient atteindre en utilisant le service. Il s agit du but même du service du point de vue du client mais aussi du point de vue du fournisseur de service. Cette étape permet de mettre en évidence ce que les clients espèrent avoir comment 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 un seuil minimum de niveau de services qui doit être maintenu dans le cadre du contrat de service. Cela revient à garantir un minimum de qualité dérivée des besoins capturés dans la première étape. Il est aussi possible de planifier des actions de correction 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 assumer dans tous les cas de figure. Cette prise de responsabilité typique des contrats formels passés entre deux entités distinctes permet de définir en avance le comportement de chaque 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 dire qu elle est responsable pour le développement des processus de création et management des SLAs. Dans la Figure 31 on montre l ensemble des étapes identifiées dans [Maurer, Matlus et al p. 18] pour développer et gérer les accords de niveaux de services. Comme on peut le constater, la seule étape concernant le développement d une SLA doit prendre en considération les différents facteurs décrits ci-dessus, à savoir les besoins des clients, leurs objectifs, les niveaux de services et la responsabilisation. Au même temps, cette figure montre comment les processus de développement et management partage la plupart des étapes mais en portant un regard différent envers chacune d elles. En effet, du point de vue du développement, les quatre dernières étapes sont utilisées pour définir le contenu des SLA qui permettra surtout de mesurer les activités des services et d examiner ces résultats pour réduire l 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 effectivement exécutées dans le but de tirer des statistiques sur le comportement des services et définir des nouvelles stratégies. Un facteur aussi important que les processus que l on vient de mentionner est celui concernant le contenu global des SLA. Pour la gouvernance SOA, il est important de définir un standard de contenu se référant aux SLA afin de réduire les risques d édition (manque certaines 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 les informations concernant la disponibilité, la qualité, et la performance des services ainsi que la qualité du support et de la stratégie de communication.

77 La gouvernance SOA 76 Figure 31: Processus de développement et management des SLAs [Cf. Maurer, Matlus et al p. 18]. Généralement, la disponibilité est un concept qui exprime les besoins de base des clients qui est celui d avoir le service disponible au moment précis et à l endroit voulu. Malgré la simplicité de ce concept, l interprétation de la disponibilité peut poser des problèmes surtout lorsqu on sait que SOA est hautement distribuée et que la fourniture d un service peut dépendre d une multitude d éléments. En effet, la disponibilité d un service peut être partielle lorsque l état du service est «disponible» mais que certains éléments rencontrent des problèmes, comme par exemple, lorsqu un groupe de clients n ont pas pu accéder au service ou 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 le client considère-t-il une augmentation sensible du temps de réponse. Si l on a affaire à un service 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éfinis dans le SLA. Elle permet par exemple d avoir une idée claire sur le comportement générale d un service concernant le temps de réponse, la disponibilité temporelle et physique et les fré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. La communication est un concept aussi important que la disponibilité car elle permet de fixer les flux d information entre les différentes parties. Un exemple de procédure de communication lié directement au contenu SLA est l escalation des problèmes vers les niveaux de support

78 La gouvernance SOA 77 plus élevés. On peut imaginer qu une SLA est un bon candidat pour fixer en avance les interfaces de support (département, personnes de contact, etc.) ainsi que les responsabilités quant à la prise en charge des consommateurs du service. Gouvernance Design-Time Repository Web Services Service Manager Notification errors Metadata and content SLA Time Frame (Availability): Web Services are to be available 24 hours per day, Sunday through Saturday, 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 the service provider, and located on provider s site. 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 le format d une SLA. Dans un premier temps un gestionnaire de service fixe le contenu standard des accords de niveaux de service qui seront appliqués à un groupe de services web. Les SLA résident dans le référentiel (Repositories) et pointent vers les services concernés. Malgré la particularité de chacune des SLA, l utilisation des métadonnées permet de garantir un contenu consistant à l échelle de l entreprise. Il est aussi possible de configurer le SLA d un service spécifique nécessitant, par exemple, l implémentation des contrôles de sécurité tels que les mé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 extension de la gouvernance Design-Time dont la portée va au-delà de ces aspects de design haut niveau et de design détaillé. Les phases d implémentation telles que le développement des composants du service (Servlets, EJB, etc.), la réalisation des tests de qualité et opérationnels et le déploiement des services font aussi partie des activités visées par la gouvernance DesignTime. A cela s ajoute les processus de gestion liés aux politiques de gouvernance qui s étendent à travers tout le cycle de vie des services permettant de contrôler les multitudes de relations 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 politiques dans un environnement faiblement couplé, flexible et rapide comme celui de SOA.

79 La gouvernance SOA La phase de «Run-Time» Après les étapes de développement et déploiement, les services se trouvent dans un environnement 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 pu constater que SOA est caractérisée, d une part, par une infrastructure déjà connu, comme celle constituée des serveurs d applications, mainframe, et autres composants. D autre part, elle ajoute d autres éléments nouveaux, tels que les moteurs d orchestration et les ESB qui auparavant étaient employés dans des contextes d utilisation spécifiques. En plus, en fonction du modèle du service, celui-ci peut résider dans une ou autre couche de l architecture et être en 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 un environnement 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 la gouvernance Run-Time qui se focalise sur plusieurs activités de gestion de services, à savoir le 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és fonctionnelles ainsi que les messages et les protocoles de communication, SOA a besoin d un composant 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 est informé sur les capacités fonctionnelles de celui-ci ainsi que des contraintes relatives aux messages qu il doit lui envoyer et ceux qu il recevra en retour. Cependant, ces informations se limitent à 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 les politiques 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 policy definition time». Les politiques, dans leur forme la plus élémentaires, sont considérées comme des simples règles et des contraintes permettant de dicter la manière dont une application ou un service doit se comporter. Les significations les plus importantes se trouvant dans ces définitions sont celles communiquées par les concepts de règles et contraintes. En effet, pour dicter une politique (règle) on procède généralement en suivant deux approches distinctes, à savoir

80 La gouvernance SOA 79 l approche procédurale et l approche déclarative. Dans la première, l application d une politique est définie par l occurrence d un événement précis, suivie d une ou plusieurs opérations à réaliser. Un exemple typique du style procédural est celui représenté par les clauses «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 dire quelles actions doivent se réaliser ou pas. Une liste blanche de sites web peut être vue comme un ensemble de règles déclaratives qui clarifient quels sites web peuvent être visités. Par la mê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 une connotation beaucoup plus négative. Lorsque l on exprime une politique sous la forme d une contrainte c est parce que l on veut déclarer les limites physiques et logiques dont fait l objet une ressource donnée. Cette dimension est en fait très importante dans le contexte de la gestion des services car elle permet de paramétrer plus facilement leur contexte d exécution ainsi que les propres performances du service. L autre terme définissant précisément ce qui est une politique est celui de «mécanisme». En effet, 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 situe la 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 dispositif donné en lui passant des valeurs connues au moment de la configuration du système. Pour qu une telle approche se révèle efficace il faut que l administrateur ait connaissance de tous les 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 a affaire à plusieurs clients et fournisseurs de services. Bien qu il soit toujours possible de déterminer à l avance la plupart des scénarios d utilisation d un service, la définition des mécanismes (système de politiques) est une approche beaucoup plus efficace que la configuration des valeurs statiques. Sans exclure l utilisation des paramètres de configuration statiques, la gouvernance SOA fait un usage exhaustif des systèmes de gestion de politiques pour garantir la flexibilité de l architecture et des services SOA. Dans le domaine de la gouvernance SOA on distingue plusieurs types de politiques parmi lesquelles 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 couche des messages. Les politiques de routage permettant de gérer le flux des requêtes entrant et sortant pour garantir ainsi que les demandes adressées à un service sont en conformité aux politiques d utilisation. Les politiques sur les niveaux de services qui concernent tous les aspects de la qualité d un service comme la performance, la fiabilité, la disponibilité et le temps de réponse. Ces politiques étant très souvent référencées dans les SLAs, les OLAs et enfin dans les contrats de sous-traitance. Indépendamment de ces types de politique, il est nécessaire de disposer d une infrastructure permettant d implémenter, déployer et maintenir les politiques de services SOA. Le besoin fondamental pour gérer efficacement les politiques est celui du couplage faible vis-à-vis des couches de services. Autrement dit, de la même manière que l on découple les SLA et les interfaces des implémentations d un service, on doit découpler aussi la gestion des politiques de gouvernance. Pour ce faire, SOA s inspire des

81 La gouvernance SOA 80 systèmes de gestion de réseau basés sur les politiques dont l architecture est illustrée dans la Figure 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 une manière complètement découplée et flexible. En effet, lorsqu un Service Manager désire créer ou modifier une politique, il peut se connecter à l interface «Policy Mangement» pour effectuer les changements dans une approche déclarative, sans besoin d ajouter du code de programmation. Ensuite, il peut stocker les politiques dans la base de données «Policy Repository» qui peut aussi exister sous la forme d annuaire LDAP. Le moteur de traitement des 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 le traitement d une politique donnée, le PDP communique son résultat (sa décision) au «Policy Enforcement Point (PEP)» pour que ce dernier puisse renforcer son application auprès des clients et fournisseurs de service. Toutefois, le PEP peut aussi consulter directement le Repository sans passer par le serveur de politiques (PDP). Policy Mangement Policy Repository Policy Decision Point? Policy Enforcement Point Services Layer 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 RunTime peut garantir la conformité des requêtes aux contrats de services définis entre les clients et fournisseurs. Chaque demande de service arrivée au PEP est comparée aux paramètres définis dans le SLAs correspondante, ce qui permet de déterminer s il s agit d une requête valable 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 de qualité de service qui doivent être garantis pendant leur utilisation. Un service qui est sollicité

82 La gouvernance SOA 81 par une multitude de clients doit fonctionner d une manière consistante et conforme aux paramètres de qualité qui apparaissent dans son contrat. Généralement, la qualité d un service peut 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 état valable, la gouvernance Run-Time est chargée d implémenter les processus de gestion sur lesquels 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 qui ont été définies dans le cadre de la gouvernance TI et pendant la phase Design-Time. Pour ce faire, 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 gouvernance Run-Time doit donc implémenter les politiques d authentification et d autorisation destinée aux services SOA, ce qui oblige à prendre de décisions importantes concernant les mécanismes d identification des utilisateurs. En principe, SOA utilise les mécanismes d authentification existants comme par exemple, l authentification via les certificats de la norme 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 un domaine spécifique et le standard SAML basé sur XML. En plus des décisions concernant les mécanismes d identification on doit tenir compte des besoins de confidentialité et d intégrité de messages qui sont échangés entre les différentes parties. Comme pour l authentification et l autorisation, il existe aussi plusieurs mécanismes de sécurité qui sont utilisés pour protéger le contenu des messages. Parmi ces mécanismes on peut mentionner la signature des messages XML qui supporte l intégrité de ces derniers ainsi que l authentification de son émetteur. Le chiffrement des messages XML qui sert à garantir la confidentialité des messages en cachant son contenu par l application des algorithmes de chiffrement. 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, ce protocole offre les services de sécurisation de messages mentionné ci-dessus mais il est dépendant du protocole HTTP, ce qui n est pas recommandé dans un environnement comme SOA qui admet d autres types de protocoles (SMTP, FTP, etc.).

83 La gouvernance SOA 82 Consumer A Consumer B Consumer C XML validation SSL, XML encryption and signature Firewall Gateway LDAP Message Delivery Message Delivery Services Services 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é des services web. Il s agit d un exemple typique d implémentation de la sécurité où trois consommateurs envoient des requêtes aux services web résidant dans une SOA. Le consommateur «A» envoie une requête avec un message SOAP qui est intercepté par un composant 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 surtout la validation des messages provenant de ce type de consommateur. Si le message s avère conforme aux contraintes de validation alors il est autorisé à communiquer avec le fournisseur du service et le message est délivré à sa destination. Dans le cas du consommateur «B», le message n a pas atteint sa destination et a été effacé parce qu il ne correspondait pas aux exigences de sécurité. Cela peut survenir par exemple lorsque le consommateur envoi une requête via un autre canal que celui attendu par le point terminal. La passerelle se charge alors de renvoyer une réponse Soapfault pour notifier les problèmes survenus ou tout simplement supprimer 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 le protocole SSL. Comme dans les cas précédents la passerelle s assure que les conditions de sé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 de certaines conditions pour pouvoir appliquer les politiques de sécurité comme il a été fait cidessus. En effet, l architecture basée sur une passerelle de sécurité fait souvent appel aux composant PEP et PDP mentionnées auparavant car en SOA la sécurité est gérée sous forme de politiques. Donc, grâce aux systèmes de gestion de politiques on peut faire appliquer les contraintes de sécurité aussi bien aux fournisseurs qu aux consommateurs. A cela s ajoute le

84 La gouvernance SOA 83 fait que dans le contexte distribué des services on peut rencontrer un grand nombre d intermédiaire avant que le message n arrive à destination. Dans une situation idéale, les consommateurs et le fournisseur communiquent en «point-to-point» mais la plus part du temps cela n est pas possible et la sécurité doit être conservée «end-to-end». Par conséquence il est important d implémenter la sécurité de telle manière que le contexte de sécurité des messages ne soit pas perdu et l échange d information se fasse comme prévu dans le SLA. L implémentation de la sécurité peut encore devenir plus complexe, notamment avec l intégration de services de processus appartenant à des organisations différentes. Lorsqu un consommateur provenant de l extérieur envoie une requête à un service on doit faire en sorte que ses attributs de sécurité restent transparents aux différents partenaires. Autrement dit, il faut pouvoir identifier le client pour établir une relation de confiance dans le partage de ces informations, tout cela malgré les différences dans les modèles de sécurité de chaque organisation concernée. Dans ce cas le défi est d implémenter la portabilité des attributs de sécurité à travers les différents partenaires concernés. Par exemple, à l aide du standard SAML 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 en gé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 des différents modèles de services et au niveau des applications sous-jacentes. Dans le cas des services de processus, les problèmes de performance se trouvent au niveau de la composition de 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 phase de Design-Time pour éviter qu un modèle de composition inefficace n ait des répercussions en temps d exécution (Run-Time). Par exemple, des services à granularité anormal, trop de membres 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 les performances d un service de processus. Quant aux services d application présentés dans la section 2.2, la performance doit être analysée en tenant compte des applications et systèmes sous-jacents. Ici, les problèmes de performances peuvent surgir des sources de données utilisées par les applications sous-jacentes. Autrement dit, si les opérations dans les bases de données deviennent trop lentes, les services d application seront aperçus comme étant aussi lents 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 pour des questions de sécurité on doit inclure dans un message un grand nombre d informations supplémentaires, il est clair que le traitement du message prendra beaucoup plus temps que d habitude. Le même problème peut venir des données attachées aux messages, ou de n importe quelle autre approche susceptible d augmenter la taille des messages. Par rapport à

85 La gouvernance SOA 84 ces derniers on peut encore dire qu un volume trop important de messages peut avoir des incidences négatives sur la performance de l architecture. Or, face à ces nombreux risques, que peut faire la gouvernance Run-Time pour conserver la performance de SOA? La première réponse à cette question consiste à développer un processus de gestion de la performance comme celui de la Figure 35. Dans cette dernière on illustre un processus défini dans le cadre du Framework ITIL qui contient les étapes nécessaires pour mesurer la performance d un système ou d un service informatique. La première étape, à savoir celle du contrôle, peut en effet être implémentée dans SOA par le monitoring des services. Les résultats ainsi obtenus sont ensuite analysés (étape 2) pour extraire 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 solutions applicables aux problèmes en question. Enfin, dans la dernière étape qui est celle de la mise en œ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 processus de 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 architecture couvrant ainsi presque tous les domaines de celle-ci. Le monitoring étant un exercice d observation et d analyse de l activité d un système il représente une bonne solution pour dé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 est important de pouvoir déterminer les «points d observation» les plus pertinents où le monitoring sera effectué. Dans SOA, le monitoring est pratiqué en suivant plusieurs approches différentes et complémentaires. La supervision des activités métier (Business Activity Monitoring) est un exemple de monitoring que l on peut utiliser dans le cadre de la gouvernance Run-Time. Bien qu il s agisse d un concept très différent, il est cependant très proche de SOA grâce au lien qu il garde avec les services de processus. Concrètement cela

86 La gouvernance SOA 85 consiste à étudier de près les processus métier en collectant des informations provenant des systèmes d information concernés par ces processus [Pulier and Taylor 2006, p. 91]. Les mesures 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, les propriétaires des domaines SOA peuvent ensuite définir des actions pour optimiser la performance des services. Un autre point d observation ayant une importance certaine dans la mesure de la performance SOA est notamment le message lui-même. En analysant le flux de messages on peut dé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 des ré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 les capacités de lire le contenu des messages transitant par le réseau. Elle peut ainsi différencier les messages en fonction de leur contenu, destination et autres paramètres servant à maintenir une 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 la performance qui permet d implémenter l ensemble d indicateurs clés de performance. Dans le cas de la gouvernance Run-Time ces indicateurs peuvent informer sur l état actuel d un service, notamment quant à sa disponibilité, le niveau de réutilisation et les niveaux de services en générale (SLA monitoring). Pour bien gérer ces indicateurs on utilise un tableau de bord contenant les indicateurs spécifiques à SOA montrant les différents niveaux de performance en temps réel. C est donc sur la base de ces résultats que la gouvernance RunTime peut décider des actions à mener, comme celles utilisés dans les domaines tels que la répartition des charges (load balancing ), le «SOA virtualization» et le re-deployment, permettant d optimiser continuellement la performance.

87 5 Etude de cas «e-dec» Grâce au travail théorique réalisé jusqu ici on a pu aborder les différents concepts gravitant autour de la gouvernance SOA, plus particulièrement de la gouvernance du cycle de vie des services. Cependant, dans un scénario réel, après avoir défini d une manière adéquate le Framework de gouvernance SOA, chacun de ces concepts sont implémentés dans une solution concrète et fonctionnelle. L étude de cas «e-dec», présenté ci-après, permettra de consolider ces connaissances théoriques par une approche pratique de la gouvernance SOA qui se concrétisera dans le développement d un prototype. L événement déclencheur motivant le développement de la plateforme «e-dec» est lié au nombre croissant du trafic des marchandises enregistré à partir de l année Cela est bien confirmé dans les statistiques des offices de douane publiées dans [AFD 2003] où l on peut constater une augmentation passant de 6 millions de déclaration en 1990 à 11 millions en La même tendance s est poursuivi toutes ces années jusqu à les chiffres les plus récents publiés cette année dans [AFD 2007] qui se réfèrent aux 14.4 millions d importations enregistré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 Graphique publié dans [AFD 2007, p. 23]. Au même temps, les bureaux de douanes ont dû traiter un flux de personnes et de 350'000 voitures qui sont entrées en Suisse. En plus, les poids lourds transitant par les douanes a atteint le nombre de 20'000 camions en 2007 et la quantité de dédouanement par jour a été d environ 76'000 unités. Tous ces chiffres tirés de [AFD 2007, p. 36] montrent facilement le dynamisme croissant des activités douanières, qui avant l année 2003 était supporté par l ancien système MD90, et que dès lors sont supportées par la plateforme de déclarations électroniques appelée «e-dec». 86

88 Etude de cas «e-dec» 87 Afin de faire face à ces changements, l Administration fédérale des douanes (AFD) et l Office fédéral de l'informatique et de télécommunication (OFIT) ont apporté plusieurs améliorations au 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. Voici deux extraits des textes publiés sur le site web de l AFD décrivant l état de MD90 ainsi que les différents problèmes posés par cet ancien modèle. Tout d abord du point de vue technique on peut lire ceci : «Depuis son introduction, le modèle douane 90E a été régulièrement complété de fonctions ponctuelles, mais n'a jamais été entièrement revu ou re-conçu. Avec le temps et les volumes croissants la valeur des importations a augmenté de 34 pour cent entre 1990 et 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 plus oné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 des utilisateurs 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ères années ont fait que l'administration fédérale des douanes dispose actuellement d'une très large palette de produits visant le même objectif, à savoir le dédouanement des marchandises. Cette palette comprend diverses solutions fondées sur des formulaires ainsi que des solutions informatiques pour l'importation, le transit et l'exportation de marchandises». En conclusion, le nouveau système de déclaration d importations et exportations devait être techniquement adapté aux environnements actuels du B2B mais aussi être capables d apporter de 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ème MD90 qui est devenu très complexe par le nombre élevé de solutions logicielles sensés soutenir 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 importants montrant ainsi la limite de ce modèle. En plus du simple remplacement du modèle MD90, le projet «e-dec» a été développé autour des objectifs suivants :

89 Etude de cas «e-dec» 88 Standardisation de l architecture de déclaration électronique en promouvant une approche orientée services et l utilisation des standards d échange. Amélioration des processus d importation et exportation permettant de réduire le temps 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 des activités. Fournir aux clients de la douane un ensemble de fonctionnalités sous la forme de services 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 administration douanière en tant que destinataire ou expéditeur agréé. A leur égard la plateforme procure les avantages suivants : Meilleure précision dans le traitement des tests de plausibilité et le calcul des redevances 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 à positions Etc. La plateforme «e-dec» participe aussi à la réalisation de bénéfices financiers pour le compte de la Confédération comme on peut le constater dans la Figure 37. Dans ce graphique on voit une nette augmentation des recettes pendant l année 2006 où la douane a pu encaisser le montant de 15 milliards de francs suisses grâce aux dédouanements effectués au moyen de la plateforme «e-dec».

90 Etude de cas «e-dec» 89 12' ' '000.0 Impôt sur le tabac Impôt huiles min. sur les carburants Redevance trafic poids lourds 6'000.0 Droits d'entrée Taxe sur la valeur ajoutée Total autres (sans taxe sur valuer ajoutée) 4' ' 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'000 dé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 300 déclarations à la minute ayant une taille de 1 à 2500 positions. 5.2 Description de la solution «e-dec» Modèle métier import Le modèle d importation implémenté par le système e-dec a été organisé en plusieurs catégories d exigences fonctionnelles qui définissent les fonctionnalités développées dans ce système. Chaque catégorie correspond à un paquetage de fonctions ou tâches associées à un sous-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 tout de sept paquetages hébergeant des cas d utilisation isolés. Le paquetage appelé «declaration»

91 Etude de cas «e-dec» 90 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 plupart exécutées manuellement et existaient déjà dans l ancien modèle MD90. En effet, avant ou après la déclaration proprement dite, le bureau douanier peut décider de la nécessité de procéder à un contrôle physique des marchandises. En plus, un transitaire est pour sa part tenu de présenter auprès des autorités douanières les justificatifs permettant de retirer la marchandise. Toutes ces opérations se font manuellement, soit au bureau de douane, soit chez le destinataire agrée et par conséquent il y a très peu d interaction avec le système informatique si ce n est que pour saisir les résultats des contrôles effectués. La même remarque 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 les cas d utilisation concernant les collaborateurs de l AFD, à savoir : la livraison des données statistiques 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 et remboursement des recettes et libération du traitement Architecture et technologies Les nouvelles exigences métier présentées par l AFD lors du lancement du projet e-dec correspondaient parfaitement aux situations pour lesquelles SOA est justifiée. Comment on peut lire dans [North 2007, p. 13] l une des sources de valeur de SOA consiste en son potentiel à améliorer la productivité des utilisateurs en donnant la possibilité de remplacer un système «spaghetti» (lire les commentaires avancés par l AFD) par une solution intégrée et unique aux yeux des utilisateurs. Par conséquent, e-dec a été conçue, entre autres fins, pour remplacer 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 couches principales qui sont la couche de présentation, la couche de services métier, la couche de services 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 aux clients plusieurs moyens d invoquer les services qu elle expose à l extérieur. En effet, un client peut utiliser le service EdecImportService par l intermédiaire d une plateforme de

92 Etude de cas «e-dec» 91 courrier électronique et peut aussi le faire par l intermédiaire d un service web. Dans tous les cas, les clients doivent respecter les formats de messages supportés par les deux canaux, en l occurrence, le courriel admet XML et EDIFACT et pour le service web c est sont les messages 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 coordonner une partie des étapes du processus d importation. Le bus de services contient les services génériques qui ont un fort potentiel de réutilisation. N importe quel autre projet comme ceux concernant l exportation et le transit des marchandises, peut les réutiliser pour traiter la ré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,

93 Etude de cas «e-dec» service de validation de messages XML, service de génération des documents de la réponse. 92 La présence d un ESB dans cette architecture se justifie par les nombreux avantages de cette technologie dans une SOA. En effet, un bus de services est une solution idéale pour résoudre les problèmes des connexions «point-to-point» qui surviennent lorsque l architecture commence à se développer et que de plus en plus de services viennent s y ajouter. Parmi ces difficultés il y a notamment la multiplication des connexions et les risques de dépendances physiques entre le consommateur et le fournisseur de service. Dans le document de présentation d e-dec [Innotvation Process Technology 2008] l auteur met en avant les capacités d un ESB à améliorer l évolutivité d une SOA, notamment pour offrir des services supplémentaires aux clients. Dans l absence d un bus de service il faut recourir à la méthode d intégration traditionnelle en développant les adaptateurs correspondants. Un bus de service est un middleware capable de rendre transparente la localisation physique des services. Il est donc lui-même un service de routage qui joue le rôle d intermédiaire actif entre les consommateurs et fournisseurs. Grâce à cette transparence de localisation l autonomie des services est renforcée ce qui permet à chacun d évoluer de manière indépendante sans provoquer des changements de configuration du côté des clients. La qualification «intermédiaire actif» se réfère à un ESB dont la fonctionnalité de routage ne se limite pas au simple transfère de messages et va jusqu à inspecter le contenu des messages en fonction des politiques préétablies pour ensuite l acheminer à la destination correcte. En plus de l abstraction de localisation, un ESB peut aussi fournir des fonctionnalités de transformation des formats de messages (EDIFACT to XML), prendre en charge plusieurs protocoles de transport (HTTP, SMTP, POP3, JMS, etc.) et différents modèles d échange de messages (synchrone et asynchrone). Cela ne peut que renforcer la qualité des services notamment en rapport avec la fiabilité dans la remise des messages, la disponibilité des services et le temps de réponse. La gestion des services et de l infrastructure de l ESB se fait au moyen d une console connectée via JMX13 au ESB ce qui permet de configurer et surveiller 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 un Sonic ESB. Selon les informations dont dispose l auteur de ce travail il est impossible de dire si 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 était prévu de publier EdecImportService dans une zone de services partagée (SSZ) permettant d effectuer des tâches de monitoring et de sécurité mais cela n a pas été fait. Le service d authentification et d autorisation est basé sur un mécanisme centralisé de control d accès de type LDAP. Ce faisant un utilisateur n a pas besoin de s identifier plusieurs fois pour utiliser l ensemble des services ce qui serait très fastidieux dans un environnement distribué comme SOA. Or, l implémentation de SOA avec un ESB peut être complétée avec une passerelle de sécurité et de routage complètement découplée de l ESB. C est justement l intention du prototype 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

94 Etude de cas «e-dec» 93 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 de sécurité et de transport comme par exemple, la conversion des requêtes JMS en requêtes HTTP, 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 (business services) supportés par une couche métier de type J2EE. Ces services sont spécifiques au processus d importation et pour cette raison ils ont un potentiel de réutilisation inférieur aux services d application présentés auparavant. Voici la liste des services métier de la plateforme e-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 à la description de l architecture SOA de la section 3.2. En effet, le service EdecImportService est un service de processus qui est spécifique au dédouanement des importations. Il compose par contre une série de services de base (services d application ou de support) dans un flux d orchestration supporté par la couche ESB. Bien que la Figure 39 ne le montre pas l interaction entre les services du ESB et ceux de la couche métier se fait par l intermédiaire des APIs JCA14 et JMS de Java. Grâce à l interface JCA, qui sert à rendre plus transparent l interaction entre un composant J2EE et le bus de service, EdecImportService compose le service d archivage qui enregistre à son tour la déclaration d importation. Ensuite, l interface JMS permet au service basé sur la technologie EJB orienté message de communiquer lui aussi avec 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 écriture dans un file system.

95 6 Implémentation du prototype «edec 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 la zone de service partagée (SSZ) où le service EdecImportService est publié pour l accès externe. En effet, cette zone représente une couche complémentaire à celle présentée dans la section Architecture et technologies contenant les composants d implémentation tels que le système ESB et le serveur d application. La SSZ est une plateforme centralisée, déployée pour la publication des points terminaux et la prise 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 de services partagée. Cette dernière fonctionne comme un proxy pour les services web qui seront utilisés depuis l extérieur, mais elle permet aussi de capturer le trafic de messages entre le service EdecImportService et les transitaires afin renforcer l application des politiques de sé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 la plateforme «e-dec» à différence qu il offre plus de capacités dans le traitement des messages et le renforcement (enforcement) des politiques de gouvernance. Notons qu en principe ces deux 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 de maniè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 recherche expérimentale afin d atteindre les objectifs suivants : 1. Consolider les connaissances théoriques présentées tout au long de ce travail en suivant une approche pratique et proche de la réalité. 2. Implémenter un ensemble de politiques de gouvernance SOA capables de satisfaire les besoins d un service web, en l occurrence EdecImportService. 3. Présenter et décrire l outil de gouvernance SOA «SecureSpan Gateway» utilisé pour l implémentation de solutions de gouvernance à grande échelle, notamment dans le 94

96 Implémentation du prototype «e-dec Governance» but de comprendre les forces et les faiblesses d une solution logicielle typiquement utilisée dans SOA. Pour ce faire on prêtera une attention particulière aux domaines de la gestion des politiques et des contrats sur les niveaux de services à l aide de mécanismes de gouvernances tels que le Policy 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 (voir l annexe Artefacts) déjà existant entre les clients de la plateforme «e-dec» et le service web EdecImportService. Le contrat de service est un document formel [Hüsemann and Rischbeck 2007] rédigé par le fournisseur du service, en l occurrence l OFIT et l AFD, réglant tous les détails techniques et de niveaux de service qui sont importants pour l ensemble des utilisateurs. 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 par l AFD consiste à demander une autorisation préalable auprès de la plateforme «e-dec» pour que le client soit reconnu en tant qu importateur agrée. Cette démarche est la première étape servant à gérer l identité des futurs clients qui est utilisée à chaque fois qu ils accèdent au service EdecImportService. Pour effectuer l authentification, le système «e-dec» utilise une méthode d authentification forte consistant à utiliser un certificat numérique, délivré par une autorité de certification de l Office fédéral de l informatique et de la télécommunication (OFIT). Ces certificats sont utilisés avec le protocole SSL en mode mutuel pour authentifier les deux entités (transitaires et e-dec) engagées dans la communication. C est l OFIT elle-même qui assure l existence de l infrastructure PKI nécessaire à la gestion des certificats X.509 v3 laissant aux clients le soin de 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 mise en place d un canal SSL sécurisé entre le transitaire et le service web. La confidentialité est garantie par les mécanismes de cryptage supportés par ce protocole dès l instant où la communication est établie. L intégrité est assurée par les mécanismes de signature aussi offert par 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 de service global. Il s agit d un ensemble de points qui s appliquent à tous les transitaires et clients d e-dec, ce qui veut dire que le service EdecImportService ne réserve pas de traitement spécial pour un type de client donné. Cette SLA tient surtout compte des aspects de disponibilité 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 95

97 Implémentation du prototype «e-dec Governance» pourcentage de disponibilité réel on peut utiliser la formule proposée dans le Framework ITIL, plus précisément dans son module de «Availability Management» [Macfarlane and Rudd 2006, p. 41]. Dans cette formule on prend on compte trois paramètres fondamentaux, à savoir les heures de services et le temps d arrêt et la disponibilité. Dans le cas d EdecImportService la disponibilité est établie au niveau de 99,5%. Sachant que les heures de services sont de 24 heures * 7 jours (D) et que le service sera interrompue pendant 2 heures par semaine (DT), alors la disponibilité réel revient à 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é pour rétablir le service. On doit noter que l indisponibilité est une notion plus complexe qu elle ne paraît car dans sa composition on trouve des éléments comme les délais d identification de problèmes, de réaction et de maintenance, ainsi que le temps d établissement du service. Temps de réponse: En situation normale (20 déclarations par minute) le service assure une performance de 95% en dessous de 10 secondes et de 99% en dessous de 15 secondes. Dans une situation extrême où le service doit traiter 170 déclarations par minute, la performance est de 95% en dessous de 20 secondes et de 99% en dessous de 60 secondes. Fiabilité: Aucune garantie n est assurée pour la fiabilité des échanges. En cas d interruption de service il appartient aux clients de procéder à une nouvelle transmission de la déclaration d importation. Le contrat de service fait aussi référence à un ensemble d artefacts tels que les schémas XML définissant la déclaration d importation, les réponses d acceptation ou de refus et l interface de description du service (WSDL). Dans le contexte des politiques de sécurité, il est important de tenir compte de ces différents éléments car ils peuvent être utilisés pour protéger le service web de certaines menaces provenant de l extérieur, notamment grâce à l application d un mécanisme de validation des schémas XML. Quant à l interface (WSDL), il s agit de l élément central du processus de publication et de routage (WS-routing). En effet, pour effectuer l enforcement des politiques de gouvernance on a besoin d un système intermédiaire, en l occurrence la passerelle «SecureSpan Gateway», dans laquelle on devra publier le service EdecImportService pour que les clients puissent l utiliser. Au même temps, on a besoin d un mécanisme de routage pour guider les requêtes vers les points terminaux les plus adaptés aux politiques que l on aurait défini. Dans le cas où le lecteur voudrait lire le contrat de service il peut soit consulter le SLA dans l annexe nommé Artefacts, soit accéder à la totalité du contenu dans le site web de l OFIT [Hüsemann and Rischbeck 2007]. 96

98 Implémentation du prototype «e-dec Governance» 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 architecture SOA qui expose le service web EdecImportService. Cependant, pour supporter les différents cas 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 dont le 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 de gestion de politiques, comme celle décrite dans la section 4.4.2, permettant de piloter les aspects 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 des transitaires 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 [the eviware soapui team 2007]. Cette dernière est utilisée pour créer les requêtes qui seront envoyées au service web EdecImportService. Grâce à la capacité de soapui à créer des tests unitaires et/ou groupés, la couche client représente assez bien l activité qui pourrait générer les clients d e-dec. Notons que le certificat client est un artefact fondamental pour établir la communication et garantir la sécurité. Il est donc nécessaire de pouvoir configurer les proprié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 pouvoir cré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 97

99 Implémentation du prototype «e-dec Governance» aux messages sortant et entrant de soapui. On se réfère ici notamment aux attachements WSSecurity dans les messages SOAP. Du côté client (soapui), on va donc se limiter à créer un projet WSDL contenant l interface de description d EdecImportService. Une fois avoir importé ce fichier, on est en mesure de créer les requêtes que l on désire envoyer à la plateforme «e-dec» en fonction du cas d utilisation courant. Dans la Figure 41 on montre le projet WSDL que l on utilise pour réaliser le prototype e-dec Governance. Il s agit d un projet créé par les développeurs du service web EdecImportService pour tester le comportement de ce dernier sous des conditions particuliè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ède qu 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 le service 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 nom déclaré dans le WSDL, la liaison concrète pour le type de port EdecImportPortType, la version 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 la dé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 seule opération déclarée dans le WSDL et elle ne supporte pas la transmission de messages en mode «One-Way». Autrement dit, elle n est supporte pas la transmission unidirectionnel car le WSDL défini, au même temps des messages d entrée, des messages de sortie tels que les messages de réponse et d erreurs. La couche du fournisseur de service (voir Figure 40) est celle qui contient le service web EdecImportService exposé par la plateforme «e-dec». Les détails concernant cette partie ont 98

100 Implémentation du prototype «e-dec Governance» été présentés dans l Etude de cas «e-dec» et on a pu constater qu il s agissait d un service de processus publié dans une zone SSZ et implémenté dans système ESB et un serveur d application J2EE. C est cette couche qui est responsable de valider le certificat client car elle est en relation avec l autorité de certification AdminCA-CD-T01 qui signe les certificats des transitaires. Enfin, plusieurs types de réponses peuvent être générés par le service web selon qu il s agisse d une transmission d acceptation ou d un refus. Dans les deux cas, le message de réponse peut varier d une requête à l autre avec plusieurs documents attachés pour quelques uns et des messages SOAP fault pour d autres. Il est à noter que le service web EdecImportService ne supporte que le mode synchrone «Request-response» et que toute ré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 SOA composé d une passerelle virtuelle de gestion et d application de politiques ainsi que d un module d administration, disponible sous la forme d une application de bureau ou d une application web. Ces deux composants représentent le cœur du prototype e-dec Governance car c est à ce niveau que l on envisage de définir et de faire appliquer les politiques de sécurité et de niveaux de service. Dans la Figure 40 illustrant les trois couches du prototype de gouvernance, on a représenté le SSG à l intérieur d une zone démilitarisée (DMZ) qui peut aussi bien appartenir au réseau du transitaire qu au réseau de la plateforme e-dec. En effet, la SSG est une plateforme utilisée pour définir et gérer les politiques qui devront respecter tous les participants, à savoir le service web EdecImportService et les applications ou services des transitaires. On peut donc la déployer, soit dans le côté client pour piloter des politiques de sécurité strictes, comme le contrôle des messages sortant (requêtes) et des réponses provenant du réseau WAN (proxy inversé) et la traduction des requêtes HTTP en requêtes JMS. Soit on la déploie dans le réseau du fournisseur de service, ce qui permet d obtenir les mêmes résultats, en plus de superviser le respect des SLAs et la qualité de service (QoS). Dans la configuration réseau utilisée pour e-dec Governance, la passerelle SSG ne se trouve pas physiquement 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 car les politiques qui sont définies et gérées par le SSG concerne principalement le service web EdecImportService. Dans la section suivante on présentera les différentes capacités offertes par la passerelle SSG dans le cadre de la gouvernance SOA. Il est à noter que le choix même de ce type de produit constitue déjà une décision de gouvernance SOA car son utilisation peut influencer les caractéristiques finales de SOA, tel que le couplage faible, la réutilisation et les performances des services. 6.4 SecureSpan Gateway Virtual Appliance La passerelle SecureSpan Gateway (SSG) est une solution SOA intégrée permettant à la fois de protéger les services web utilisés depuis l extérieur et d implémenter les politiques de gouvernance appliquées en temps d exécution. Dans le domaine de la protection d applications et des services web, SSG permet de définir un certain nombre de politiques de 99

101 Implémentation du prototype «e-dec Governance» sécurité permettant de garantir les services de confidentialité, intégrité, authentification et autorisation. En effet, cette passerelle fournit les moyens nécessaires pour définir les politiques de contrôle d accès qui seront appliquées à EdecImportService lorsque celui-ci sera sollicité par les différents transitaires. Parmi ces politiques de contrôle d accès on trouve plusieurs variantes d authentification et d autorisation qui couvrent la plupart des stratégies existantes, 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 aspects d 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 contrat de service (SLA) existant entre EdecImportService et les transitaires est implémenté dans cette passerelle au même temps que les politiques de sécurité mentionnées ci-dessus. De cette façon on peut garantir aux différents clients (transitaires) que le service web EdecImportService se comporte en conformité aux paramètres de niveaux de services. Dans le cas des messages, SSG supporte plusieurs mécanismes de traitement de messages XML tels que la validation, l inspection de contenu, le traitement XSLT et le routage des requêtes et réponses. 100

102 Implémentation du prototype «e-dec Governance» Chacune des politiques mentionnées ci-dessus sont appliquées en temps d exécution par la passerelle 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) pour garantir leur conformité vis-à-vis des politiques prédéfinies. SSG représente dans le rôle d intermédiaire, le seul point d accès au service EdecImportService par lequel transitent les requêtes et les réponses échangées avec les transitaires. Dans la Figure 43 on montre un exemple de configuration de politiques déployée à l aide de SSG. Il s agit d un ensemble de contraintes imposant aux clients du service web protégé (EdecImportService) d utiliser comme point d entrée un canal SSL. Pour que l utilisateur soit authentifié auprès de la passerelle il doit fournir son nom d utilisateur et le mot de passe envoyé avec le mode HTTP Digest. Ensuite, la requête doit passer par une structure logique définie par trois opérateurs propres au standard WS-Policy (ALL, ExactlyOne, OneOrMore). Dans ce cas on peut constater que pour que la requête soit validée il faut qu elle passe l un des deux groupes d 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 un point 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 des services déployés dans différents domaines de sécurité. Dans ce cas, il devient une extension des infrastructures de clés publiques (PKI) avec la capacité de signer et de délivrer des certificats. 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 et autorisations de type SAML. 101

103 Implémentation du prototype «e-dec Governance» Le fonctionnement de SSG Manager Le dernier composant utilisé dans la couche intermédiaire est le module de gestion de la passerelle SSG. Ce module existe en deux variantes, l une sous forme d application de bureau entièrement indépendante et l autre sous la forme d une applet accessible via un navigateur web qui est celle utilisée dans ce prototype. Du point de vue de la gouvernance SOA, le gestionnaire 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 des politiques, 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 du systè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 des clients du service web. Grâce aux fournisseurs d identités, la passerelle compte sur toutes les informations 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 terminal déclaré dans l interface de description. La publication peut se faire de deux manières diffé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 les paramètres nécessaires pour accéder au WSDL localisé dans un registre UDDI externe. En plus de cela, on peut publier sous différents URL uniques un même WSDL et d y associer des politiques 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 les outils de monitoring proposé dans ce module. 102

104 Implémentation du prototype «e-dec Governance» 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é dans le gestionnaire de SSG. Cet outil permet de suivre en temps réel le comportement des services grâce à un ensemble d indicateurs clés de performances comme le temps de réponse et le nombre de requêtes par seconde. Sous l onglet «Selection» on mesure aussi les nombre des requêtes qui ne se sont pas conformé aux politiques (Policy Violation) ainsi que le nombre de requê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 des requêtes et des réponses. Il permet de suivre à partir d une date donnée les requêtes et les réponses qui ont transité par la passerelle ainsi que les messages de log associés Support et conformité aux standards Afin d implémenter les différents types de politiques mentionnées ci-dessus, SSG s appui sur deux standards WS-Policy et XACML 2.0. Le premier standard (WS-Policy) est une spécification permettant de communiquer d une manière découplée les contraintes et capacités d un service web. Tant les clients comme les fournisseurs peuvent profiter de WSPolicy pour déclarer leurs exigences de sécurité, transactionnelles ou d autre type, sans besoin d ajouter du code à l implémentation du service. WS-Policy est un Framework indépendant qui 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 plupart des domaines (sécurité, fiabilité, transaction, etc.) des services web pour ensuite se décliner en plusieurs spécifications, à savoir WS-PolicyAttachment (liaison WS-Policy et les ressources), 103

105 Implémentation du prototype «e-dec Governance» WS-PolicyAssertions (des assertions génériques) et WS-SecurityPolicy (des assertions spécifiques à la sécurité). Dans le contexte de la gouvernance SOA, le support des standards industriels est un facteur très important car il contribue largement à garantir l interopérabilité de l architecture SOA 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 les cas d utilisation typiques à la gouvernance Design-Time. Pour ce faire, on a besoin des systè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 on a la possibilité d intégrer celle-ci avec la plateforme de gouvernance, HP SOA Systinet Software de HP. Dans ce cas, la SSG continue à assurer les tâches d une solution de gouvernance 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 de Design-Time, telles que le stockage et la validation des politiques, l implémentation des processus de validation de l architecture, contrôle de la conformité des services, la gestion des contrats et le catalogue des services. La SSG admet aussi le rôle d agent de gestion de service web (WSM) pour le compte de HP SOA Manager. Ce dernier est une plateforme de gestion SOA offrant une large palette de fonctionnalités avancées telles que la gestion de la performance, de la sécurité et des exceptions. 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 la section La phase de «Run-Time». La solution de HP joue le rôle de point de décision qui stocke les politiques de Run-Time pour que la SSG puisse les appliquer lorsque les messages SOAP passent par cette dernière. Chaque politique définie dans la SSG peut être envoyée vers Systinet pour passer par une étape de validation et de conformité et ensuite être stockée dans le 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 architectures orientée services. On va donc montrer comment on peut implémenter et renforcer les politiques de gouvernance Run-Time (PEP) dans le prototype e-dec Governance. Notons que pour faire de la gouvernance Design-Time il faut pouvoir intégrer la SSG avec des solutions complémentaires comme les systèmes de registres et référentiels de service fournis par des sociétés partenaires tels que les produits HP SOA Systinet Software, CentraSite de Software AG, etc. 104

106 Implémentation du prototype «e-dec Governance» Publication d EdecImportService La première décision à prendre en matière de gouvernance Run-Time est évidemment la publication du service. Pour utiliser EdecImportService depuis une application externe, il faut que le modèle de gouvernance SOA prévoie la manière dont le service sera exposé aux transitaires et clients de la douane. Dans ce contexte, SSG offre le choix entre générer une nouvelle interface WSDL et utiliser une interface existante publiée dans un registre UDDI ou dans un fichier local. Dans le cas d EdecImportService on a opté pour la dernière option consistant à localiser le WSDL dans un fichier local. Pour ce prototype, le choix d un WSDL local n a pas de répercutions importantes à différence d un environnement réel de production. L utilisation d un WSDL local limite la flexibilité de SOA dans la mesure où elle empêche la réplication en temps réel des éventuels changements effectués sur l interface du service. Du point de vue de la gouvernance SOA, une telle décision est importante car elle peut réduire le potentiel de l architecture global, notamment sa flexibilité et agilité vis-à-vis des nouveaux changements. Une remarque importante qui revient dans chaque cas d utilisation est celle liée à la structure de gouvernance et aux différents rôles que celle-ci peut définir. Il fau dire que la SSG vient configurée avec un seul rôle qui est celui d administrateur auquel on assigne tous les droits sur l ensemble d objets gérés. Donc, pour publier un service il faut que l utilisateur soit dans un 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. Il s agit d EdecImportService et d un service web non protégé proposé par le site web Le binding d EdecImportService définit la liaison SOAP/HTTP pour la seule opération qui contient le service, à savoir submitedecimport. Tandis que la partie Services expose les points terminaux où se trouve EdecImportService. Une fois cette opération de publication terminée, les transitaires doivent configurer le point terminal du service pour qu il pointe vers le point terminal où se trouve le service intermédiaire, en l occurrence a passerelle SSG. 105

107 Implémentation du prototype «e-dec Governance» Les politiques d accès pour EdecImportService Pour qu un client puisse accéder à EdecImportService il doit présenter un certificat client délivré par l autorité d identification de la plateforme «e-dec». Ce certificat est présenté par soapui lors de la phase d authentification mutuelle avec le serveur SSL. En ajoutant un service intermédiaire tel que celui de la passerelle SSG, il devient plus difficile de satisfaire cette 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 et autoriser 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é par l autorité de certification AdminCA-CD-T01 et utiliser deux certificats clients, l un pour l authentification auprès de la SSG et l autre pour la politique de routage HTTPS vers EdecImportService. La première alternative a l avantage d être plus simple à mener car elle n utilise qu un seul certificat pour les deux canaux SSL ouvert entre le client soapui et la SSG, ainsi qu entre la SSG et la plateforme «e-dec». Le désavantage de cette solution est qu elle augmente les possibilités d attaques man in the middle consistant à intercepter la clef publique de l une ou des deux parties. La deuxième alternative est plus sûre tout en répondant aux exigences de sécurité SSL mais beaucoup plus difficile à implémenter car elle demande une connaissance approfondies 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 ou dans la base de données MySQL gérée par la SSG. C est cette dernière option que l on a choisi pour le prototype. 2. Il faut aussi établir la relation de confiance avec les certificats qui seront utilisés. Dans ce cas, il faut que les transitaires acceptent le certificat de la SSG qui est signé par la passerelle 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 certificate authentication. Pour que cette politique soit validée sans problème il faut combiner l assertion SSL avec une seconde assertion Grant Access to Users/Group» ou Athentication. Donc, dans sa forme finale la politique de contrôle d accès est celle-ci : SSL with Client Certificate Authentication Transitaire in Federated Internal Provider 106

108 Implémentation du prototype «e-dec Governance» Il est évidemment possible de définir plusieurs alternatives de contrôle d accès en fonction du client avec qui on communique. Bien qu EdecImportService ne l exige pas on pourrait proposer une politique d authentification différente pour des clients pour qui le SSL en mode mutuel ne serait pas nécessaire. Voici en quoi peut consister cette politique : SSL or TLS Transport HTTP Basic or Digest or WSS UsernameToken Basic Transitaire in Identity Internal Provider Les politiques de sécurité Souvent, les environnements de production des services web vont au-delà de la sécurité au niveau du protocole de transport pour assurer une sécurité de messages SOAP. La justification d 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 aient atteint leurs destination. Dans tous les cas, les idées pour exploiter les vulnérabilités et les limites de SSL ne font pas défaut. Par exemple, malgré le service d authentification de SSL rien n empêche qu un client mécontent essaie une attaque DoS en envoyant des déclarations trop lourdes avec plusieurs mégaoctets en attachements. Pour éviter ces types de surprises, la passerelle SSG offre la possibilité 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 appel aux modules Norton Antivirus que l on peut intégrer au SSG, imposer l utilisation de XML Signature et XML Encryption, etc. Le service EdecImportService n exige aucune sécurité au niveau des messages mais il serait quand même pertinent d ajouter une assertion de type Validate XML Schema pour être sûr que les requêtes des transitaires respectent bien le schéma référencé dans le WSDL. Cela permet de protéger EdecImportService contre les attaques de type XML Parameter Tampering et XDoS car le contrôle des valeurs de la déclaration d importation permet de s assurer que les paramètres XML n ont pas été remplacés par des scripts malicieux ou que la structure même du message n a pas été modifiée. Donc, la politique de sécurité XML pour «e-dec» serait la suivante: Validate XML Schema 107

109 Implémentation du prototype «e-dec Governance» L implémentation du SLA L accord sur les niveaux de services de la plateforme «e-dec» n a pas des restrictions particulières sauf la maintenance de 2 heures par semaine qui exige l arrêt du service. Comme le service est sensé être disponible la plupart du temps il n y a pas besoin de définir une assertion de disponibilité. Du point de vue technique, l absence de ce type de disponibilité ne change rien à la manière dont la passerelle SSG se comporte car il n y a pas de restriction dans le temps et les requêtes vers «e-dec» ne seront jamais filtrées. Cependant, dans l intérêt d éviter toute confusion et de veiller au respect de l accord SLA, on estime que le prototype edec 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 20 déclarations par minute et qu à partir de 170 déclarations par minute on considère que la charge est extrême. La passerelle SSG permet de limiter le nombre de requêtes par seconde pour un client, un groupe de clients, etc. Il est aussi possible de définir un maximum de requêtes concurrentes et de configurer SSG pour qu il adapte sa réponse au cas où les restrictions de SLA seraient violées. L accord de niveaux de service pour «e-dec» est implémenté avec les assertions suivantes: 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) La logique de WS-Policy et les assertions Chacune des politiques qui ont été développées dans ce prototype traduisent les contraintes d interaction entre les transitaires et le service EdecImportService. Cependant, pour mieux contrôler le traitement de ces assertions, le standard WS-Policy met à disposition une série d 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 il contient, chacune de ces assertions doivent retourner la valeur «True» pour que la politique soit 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ème opé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 les différentes assertions. Ce qui suit résume l ensemble des assertions que conforment la politique de gouvernance pour le service EdecImportService: 108

110 Implémentation du prototype «e-dec Governance» <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 /> Dans la politique de gouvernance Run-Time d EdecImportService on a utilisé les opérateurs logiques All et OneOrMore. L opérateur de premier niveau All assertions must be evaluate to True, 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 canal SSL, quelque soit le client. Ensuite, l opérateur At least one assertion must evaluate to true contient les assertions d identification et authentification des clients. Grâce à ce deuxième niveau d assertions, combinées avec l opérateur OneOrMore, on peut couvrir l ensemble d alternatives d authentification et d identification de ce prototype. Au moins un transitaire doit être identifié et authentifié par la passerelle SSG pour que la politique soit satisfaite. Dans ce cas, on a déclaré deux clients, l un qui représente un transitaire agrée de la plateforme «e- 109

111 Implémentation du prototype «e-dec Governance» dec» et l autre un transitaire fictif qui n a pas de certificat client mais possède un compte utilisateur 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 le reste des assertions. Les assertions Validate XML Schema, Availability, Rate limit et Route to https, sont placées à la fin de l assertion de premier niveau All assertions must evaluate to true pour dire qu elles s appliquent à tous les clients du service web. Dans le cas où l une de ces 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 formats des données aux standards industriels, on sait que SOA compte beaucoup sur l utilisation des standards pour garantir l interopérabilité. Dans le cadre de ce prototype on peut encore insérer une assertion globale pour dire que chaque requête doit respecter tel ou tel standard. Par exemple, on peut demander que les clients qui n ont pas des certificats pour l authentification et veulent tester leurs applications auprès d EdecImportService, d envoyer des requêtes conforme 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 cidessus. C est pourquoi on a décidé de développer cette partie en suivant la structure des objectifs d e-dec Governance décrits dans la section nommée Exigences et besoins 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 «edec» et dans le prototype e-dec Governance. Lors de la description de l étude de cas on a eu l occasion de présenter les différentes technologies et composants qui conforment cette plateforme SOA. En commençant par les business cases jusqu à l architecture SOA, on s est servit des concepts théoriques étudiés dans ce travail pour décrire les composants métier et techniques de la plateforme «e-dec». L utilisation du client soapui a permit de couvrir d une manière concrète, c'est-à-dire en faisant référence à la technologie des services web, une partie importante des concepts orientés services. Ceci est montré par le fait que pour utiliser soapui 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 edecimportresponse), les porttypes, les messages SOAP et SOAP attachements. La même remarque s applique aux notions de gouvernance SOA, plus particulièrement celles de la gouvernance Run-Time. On y voit comment les modèles de gouvernance Run-Time décrits dans la section La phase de «Run-Time» ont été repris dans l implémentation d e-dec Governance. En effet, ces modèles décrivaient la nécessité d avoir un système de gestion de politique où l on peut stocker et renforcer toutes les assertions de Design-Time, Run-Time et Change-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. 110

112 Implémentation du prototype «e-dec Governance» Un autre élément important que l on avait vue dans la partie théorique mais pas du tout observé dans la pratique c est sont les différences existantes entre les types de gouvernance SOA. On a pu constater par exemple que pour faire de la gouvernance Design-Time on a besoin des systèmes de registre et de référentiels de service permettant de stocker et d appliquer les politiques de Design-Time. En regardant de plus près aux politiques de contrôle d accès fournies par la SSG on peut montrer cette différence. Dans le cas d une politique d authentification et autorisation des utilisateurs, la gouvernance Run-Time vise plutôt les consommateurs de services. Tandis que la gouvernance Design-Time vise les dé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ême endroit 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 de réutilisation des services ou de gérer le portefeuille de service de l entreprise. Par contre, la SSG est une solution idéale pour implémenter les accords sur les niveaux de services et superviser en temps réel le comportement d EdecImportService. Par ailleurs, on peut aussi contrôler la réutilisation des services en temps d exécution pour savoir si sa fréquence d utilisation correspond bien à ce qui avait été planifié. Quoi qu il en soit, la gouvernance SOA reste un sujet difficile de maîtriser à cause des connaissances cross-domain dont elle tire profit 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éployer correctement la passerelle SSG. Le premier obstacle que l on a surmonté est celui de l installation et configuration de SSG, notamment quant aux détailles de réseau et de gestion des 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 ce prototype. Ce point a posé quelques difficultés à cause du nom Fully Qualified Domain 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 gestion fédérée des identités. Dans le contrat du service web EdecImportService on exige que l identité des transitaires soit authentifiée via les mécanismes d authentification de SSL en mode mutuel. Pour ce faire on a reçu de la part de la plateforme «e-dec» un certificat client signé par l autorité de certification ADMIN-CA-T01 de l OFIT. Le premier défi à relever consistait à faire accepter auprès de la SSG les certificats du transitaire ainsi que celui de l autorité de certification. Grâce au mécanisme Identitiy Bridging supporté par la SSG on a pu implémenter le partage des identités entre la SSG, le client soapui et «e-dec». Dans une telle configuration on a deux domaines de sécurité distincte, à savoir le domaine d authentification qui est représenté par ADMIN-CA-T01 et le domaine d autorisation supporté par la passerelle SSG pour autoriser les transitaires à envoyer des requêtes au service web. Il y a aussi un 111

113 Implémentation du prototype «e-dec Governance» client, en occurrence soapui, qui demande l accès au service EdecImportService via la passerelle SSG. L Identity Bridging est un mécanisme efficace de gouvernance Run-Time qui a permis à ce prototype 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 routage des requêtes et l authentification des transitaires. Avec ce mécanisme on a pu partager les identités des transitaires entre le client soapui, la SSG et la plateforme «e-dec» et réussir l authentification et l autorisation auprès de celle-ci. Pour que l authentification mutuel puisse fonctionner on a établi la relation de confiance en important le certificat ADMIN-CA-T01 dans 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 fournisseur d identités fédéré auquel on a attaché les certificats importés et on lui a jouté un nouvel utilisateur qui optionnellement pouvait aussi se voir attacher le certificat client (Test Spediteur Poveda ). L implémentation du prototype e-dec Governance a été un moteur de réflexion sur les aspects de gestion des politiques. En effet, à chaque fois que l on a dû créer une politique on a constaté qu il fallait suivre un même processus itératif et incrémentale résumé dans les étapes suivantes; 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 étapes jusqu à obtenir les résultats attendus. Lorsqu une assertion n est fonctionne pas comme on l espère elle peut provoquer une indisponibilité de service non désirée par le fournisseur. Les messages 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 est arrivée dans les politiques d authentification SSL qui demandaient la présentation d un certificat 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ées pas le client soapui tels que les mots de passe et les certificats, n étaient pas reconnues par la SSG, la réponse est évidemment «authentication failed». Les erreurs dans le traitement des messages sont retournées dans plusieurs cas de figure. Par exemple, lorsque le fournisseur du service dépasse le temps (time out) pour répondre à la requête de routage ou qu une erreur dans la lecture des messages SOAP d entrée et de sortie (requêtes et réponses). Quoi qu il en soit, c est un message qui a des conséquences importantes pour les politiques car la SSG réagit en stoppant le traitement. Par rapport à la gestion de la qualité (QoS) on a pu voir comment elle est supportée par une solution réelle de gouvernance SOA. En premier lieu on peut citer l implémentation de la SLA dont chaque paramètre a été traduit en une assertion. Bien que les paramètres de quota et de 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 par seconde pour un client donné ou en fixant de limites maximales dans les requêtes concurrentes 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 pourrait limiter le nombre des requêtes concurrents par client de telle sorte qu elles ne dépassent cette valeur. Malgré l apparente simplicité dans la gestion des SLA, on doit noter que les termes 112

114 Implémentation du prototype «e-dec Governance» 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 les assertions 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 par certificat client via SSL, l assertion de validation de schéma XML, la protection contre les attaques SQL (injection SQL, etc.), les assertions de SLA et le monitoring montrent un exemple concret de comment le risque et la performance sont abordés. Les détailles d interopérabilité et de conformité ont été pris en compte par l existence d une assertion WS-I BSP Compliance exigeant que les messages et la politique adhèrent à la spécification WS-I Basic Security Profile 1.0. Ce faisant, on garanti que les requêtes et réponses n utilisent que des éléments compatibles dans chaque élément XML tels que les algorithmes d encryption, de signature, la déclaration des namespaces, etc. Enfin, les exigences de conformité légale n ont pas été oubliées dans cette solution car elles sont implicites aux outils de gouvernance SOA. Dans le cas d e-dec Governance on n a pas oublié 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. Dans ce prototype on a défini une politique d audit permettant d enregistrer les événements WARNING et SEVERE déclenchés lors des échangent entre soapui et le service web d e-dec et dans les opérations d administration du SSG Manager Evaluation de la passerelle virtuelle SecureSpan Gateway Dans cette dernière étape on aimerait effectuer une petite analyse sur les avantages et les inconvénients de la passerelle SSG. Dès les phases d installation et de configuration de la SSG jusqu à l implémentation des politiques de Run-Time on a pu se faire une idée de son potentiel 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 non négligeables dans les domaines de la sécurité et de la gouvernance SOA. Dans cette expérience on a trouvé comme positif les points suivants: Sécurité: La SSG offre une solution efficace au problème de sécurisation des services web et des applications XML. Cette solution est implémentée sous la forme d un XML Firewall permettant d inspecter le contenu des messages SOAP et XML en fonction des 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 à deux niveaux distincts, au niveau des protocoles Internet comme HTTPS et FTPS, et au niveau 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 de sécurité mais elle couvre un grand nombre de domaines comme celui des politiques de contrats et de qualité de services. On peut aussi définir des politiques pour les domaines de gestion d identités, du routage des messages, la traduction des protocoles 113

115 Implémentation du prototype «e-dec Governance» de transport (HTTP, JMS, FTP). Le domaine du Compliance est couvert par les politiques d audit et logging permettant de capturer les informations utilisées dans les rapports opérationnels. Grâce aux opérateurs logiques AND et OR, on peut combiner les assertions dans une séquence logique pour construire une politique dynamique. Les politiques peuvent être réutilisées basées dans l importation et l utilisation des templates. Gestion avancée et centralisé: Pour gérer la SSG on peut utiliser soit une application standalone, soit une applet s exécutant dans un navigateur web. Chacun de ces modules d administration sont basés sur une interface utilisateur graphique très intuitive et un support déclaratif dans la gestion des politiques, à l exception des expressions régulières, les schémas XML, et autres détailles. Elle permet la gestion en temps réel monitoring et e tableau de bord, Interopérabilité et extensibilité: On compte sur un ample éventail de standards SOA pour assurer l interopérabilité de la plateforme. Dans ce contexte on a toute la pile des standards des services web (HTTP, XML, SOAP, WSDL et UDDI). Les standards complémentaires WS-Security, WS-Policy, WS-Trust, WS-SecureConversation, WSMetadataExchange, sont aussi supportés. Possibilité d intégrer la SSG avec des systèmes externes et répandus dans le marché de SOA. Par exemple, on peut utiliser des fournisseurs d identité Oracle Internet Directory, TivoliLDAP, Microsoft Active Directory et GenericLDAP. Il est aussi possible d installer des politiques provenant d autres éditeurs tels qu Oracle COREid Protected Resource, Sun Java System Access manager Protected Resource, Symantec Virus Scanning, etc. Réplication et répartition de charge: La SSG peut être configurée en mode cluster dans lequel on peut avoir plusieurs nœuds SSG partageant les politiques de services, les fournisseurs identités et les paramètres d administration. Cette configuration se base sur le déploiement d un Load Balancer. 114

116 7 Conclusions La partie théorique de ce travail est le fruit d une étude approfondie et sérieuse sur les concepts élémentaires et plus au moins avancés de trois sujets importants de SOA, à savoir le développement orienté service, l architecture SOA et la gouvernance SOA. Cette partie est sans doute celle qui a permit à l auteur d avancer d une manière méthodique dans un sujet complexe et vaste comme celui de la gouvernance SOA. En effet, dans mon opinion personnelle il serait très difficile de comprendre l art de la gouvernance si l on ignore les caractéristiques de conception des services SOA. Ces propriétés de base, qui sont le faible couplage, 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 composants software. Pour les managers, architectes, et autres participants de la gouvernance SOA, il s 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 SOA sont réutilisables et, par conséquent, on ne devrait pas engager un projet de développement jusqu à ê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. Ces derniers jouent des rôles temporels en fonction de leur contexte d utilisation. Mais ils répondent aussi à un modèle de service bien précis qui est souvent lié à la logique sousjacente (métier, applicative, etc.) qu ils implémentent. Connaître la différence existante entre ces différents types de services (Processus, Métier, Application) est un atout non négligeable qui permet de se faire une meilleure idée sur la nature de l inventaire de service SOA d une entreprise. 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 de processus. Un service de processus a des caractéristiques particulières qui diffèrent de celles d un service métier ou d application, comme le fait de posséder un état, jouer le rôle de contrôleur et modéliser le comportement d un processus métier. Donc, les paramètres de risque, de performance et d alignement stratégique ne sont pas les mêmes que pour les autres modèles de services. Quelque soit l objet de gouvernance, il est évident que les cadres métier et TI doivent avoir une idée globale de l environnement concerné. Toute la section traitant les sujets de l architecture SOA a permis de faire un grand survol sur les aspects logiques et physiques de SOA. Indépendamment de toute technologie, SOA représente la dernière génération des systèmes d information dont la raison d être est celle de doter les entreprises d une architecture TI flexible, agile et interopérable. Dans le contexte actuel de globalisation des marchés et de haut niveau concurrentiel, l agilité de SOA permettrait de devancer ses concurrents dans les stratégies comme la pénétration de nouveaux marchés. La promesse de flexibilité décrit explicitement combien les technologies précédentes se sont montrées difficilement adaptables aux nouvelles exigences métier. L exemple typique est celui des 115

117 Conclusions 116 opérations de fusion et d achats d entreprise qui posent beaucoup de difficultés lors de l 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 par un 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 intensive des standards technologiques l architecture SOA garanti un niveau élevé d interopérabilité qui est 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. En effet, les concepts de SOA et de gouvernance ne sont que les deux faces d une même monnaie. Pendant que la première permet de concevoir une solution hautement modulable et flexible, la deuxième fait que cette solution puisse exister à long terme tout en lui permettant d atteindre les objectifs de flexibilité, réutilisation et interopérabilité. Les phases de gouvernance Design-Time, Run-Time et Change-Time définissent donc le modèle de gouvernance SOA standard, implémenté par toutes les entreprises de ce marché. Pendant la phase de Design-Time, les décideurs TI et métier se concentreront sur les aspects stratégiques comme les stratégies de développement (Top-down, Bottom-up ou mixte) à adopter, le modèle de maturité SOA, l architecture de référence et la structure de gouvernance clarifiant les rôles et les responsabilités assignés à chaque partie prenantes. Chacun de ces éléments sont ensuite publiés et communiqués afin de fournir vision et direction à l échelle du projet SOA. Dans chacune des phases de la gouvernance on doit définir des politiques qui seront stockées dans le référentiel de services. Les politiques de Design-Time devront être implémentées pour guider le comportement des utilisateurs par rapport à la réutilisation des services existants, au développement basés sur les standards SOA et à la gestion minutieuse des artefacts qu ils produisent (SLA, modèles de données, etc.). Les politiques de la phase de Run-Time permettent de contrôler le comportement des services et de protéger le fournisseur contre les menaces de sécurité en temps d exécution. Celles-ci sont appliquées dynamiquement par un outil spécialisé jouant le rôle de point de renforcement de politiques (PEP) dont le but est d exécuter les assertions de contrôle d accès, d authentification et autorisation, d accord de niveau de service, d audit et de sécurité. Enfin, grâce à prototype e-dec Governance on a pu tester une solution de gouvernance proche de la réalité qui a permis d analyser plus profondément les aspects théoriques et pratiques de la gouvernance SOA. D une part, on a réalisé dans quelle mesure un outil de gouvernance Run-Time doit être capable de résoudre les problèmes soulevés par SOA, tels que le silo d identités, la gestion des PKI, la conformité des services aux lois (SOX) et standards de l industrie. D autre part, il a été possible de montrer la manière dont la SSG gère les risques et la performance des services, au même temps, que sa capacité à intégrer d autres outils pour offrir une solution complète et efficace.

118 A Artefacts Dans cette annexe on a ajouté quelques fragments importants du contrat de service, comme la SLA, une image globale du WSDL et une présentation du fichier des politiques en format XML. Le but est de faciliter aux lecteurs la recherche des informations mentionnées tout au long de ce travail. Tableau 7 : SLA du service web EdecImportService 7.1 Accord de niveau de service 7.2 Disponibilité Durée d'indisponibilité (non planifiée) Temps de réponse (temps de latence) Débit Le système doit présenter une disponibilité de 99,5 % (24 heures x 7 jours). Fait exception à ce principe une fenêtre de maintenance de 2 heures par semaine. Les fenêtres de maintenance sont annoncées à l'avance. Après un redémarrage, le service doit être de nouveau disponible dans un délai de 5 minutes Charge normale: 95 % en dessous de 10 secondes, 99 % en dessous de 15 secondes 7.9 Charge extrême: 95 % en dessous de 20 secondes, 99 % en dessous de 60 secondes 7.10 Déclarations en douane d'importation: le temps de réponse correspond à l'intervalle entre le moment où la déclaration arrive dans 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 en considération Charge normale: jusqu'à 20 déclarations par minute Charge extrême: à partir de 170 déclarations environ par minute. 117

119 Artefacts 118 Figure 46: Vue globale de l'interface WSDL

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

121 B Installation et Configuration Figure 48 : SSG_32bit_VirtualAppliance_v43 Configurer les paramètres de réseau de la SecureSpan Gateway V4.3 en suivant les instructions affichées au menu de la console. Pour plus de détailles veuillez lire le paragraphe 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éseau choisissez 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étailles veuillez 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 au gestionnaire de la SSG au tapant comme URL les adresses suivantes: o -> Authentification mutuelle. o -> Authentification serveur seulement. Configuration réseau Pour configurer correctement cette étape la SSG offre deux options, à savoir un serveur DHCP et une configuration statique. Dans le cas de ce prototype, on a testé les deux configurations et on a préféré l option statique car avec le serveur DHCP on a rencontré des difficultés dans la résolution de l URL depuis le navigateur web. Après avoir choisi l option statique et l interface réseau (eth0) veuillez vérifier qu il existe une entrée dans le fichier etc/hosts. Pour ce faire, suivez les indications suivantes: 120

122 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ée correspondant à la SSG que l on vient de configurer, veuillez ajouter les lignes comme dans la figure ci-dessous. Les adresses IP et les noms d hôte peuvent être différents de ceux présents dans cette configuration pour s adapter aux propriétés locales du réseau en question. Figure 49 : Fichier hosts du serveur linux Jusqu ici cela devrait être suffisant pour configurer le réseau de la SSG. Cependant, si vous rencontrez un problème de communication entre le navigateur web et la SSG, on recommande de vérifier le fichier hosts de Windows xp est d y ajouter les mêmes lignes 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 pas des 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 satisfaire les conditions suivantes : Importer le certificat ADMIN-CA-T01 dans le Trust store de la SSG et cocher l option Signing client certificates dans l assistant d importation de certificats. Importer aussi le certificat client. Voir la section Workflow using an X.509 Certificate dans la page 321 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.

123 Installation et Configuration 122 Pour établir la confiance entre la SSG et le serveur e-dec et permettre que la politique de routage fonctionne correctement, importez le certificat du serveur. Pour ce faire, il faut suivre les étapes de la section Add Certificate Wizard dans la page 328 du document SecureSpan Manger User Manual. Après avoir terminés les étapes décrites auparavant, il ne reste qu à importer les politiques d EdecImportService. Pour ce faire : Publier le service en suivant les étapes du chapitre 4 Publishing a SOAP Web Service du document SecureSpan Manager User Manual. Importer dans le gestionnaire SSG le fichier EdecImportService Policy.xml fourni dans le CD-Rom. Ensuite, il ne reste qu à tester l exécution des politiques d 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 politique de routage est celle appartenant au transitaire. Faire de même avec la clef utilisée sur le port 8443 de la SSG de sorte que celle-ci soit la clef privée de la SSG. Pour plus d informations veuillez consulter les sections Managing Private Keys dans la page 338 et Managing Listen Ports dans la page 24 respectivement.