URBANISATION & ARCHITECTURE ORIENTÉE SERVICE (SOA) Quelques bonnes pratiques pour leur mise en œuvre LIVRE BLANC
A PROPOS DE L AUTEUR Cyrille Devaux, Directeur chez Aubay Management Titulaire d un DESS en Intelligence artificielle, reconnaissance des formes et robotique, et d un Executive MBA (HEC), Cyrille Devaux est le plus globe-trotter des experts en technologies et systèmes d information Aubay. Après une adolescence passée à Abidjan (Côte d Ivoire), Cyrille Devaux fait ses études supérieures à l Université Paul Sabatier de Toulouse et part ensuite effectuer son service militaire civil pendant 2 ans à l Ecole Nationale des Sciences de l Informatique à Tunis (Tunisie). Cyrille Devaux débute sa carrière en 1992 au Centre de Maquettage des Systèmes d Information et de Communication de la DGA (Délégation Générale pour l Armement) pour le compte de Cap Gemini. En 1995, il rejoint Marben et part en mission chez TELMEX au Mexique. De retour en France, il occupe successivement les fonctions de consultant ou chef de projet chez EDF, Bouygues, Neuf Telecom, AXA ou encore IBM. C est chez Marben, devenu Sligos puis Atos, qu il rencontre Christian Aubert (plus tard, fondateur du Groupe Aubay), Christophe Andrieux (Directeur Général Délégué de Aubay France) et François Hisquin. En 1998, en collaboration avec ce dernier, et fort de son expérience dans le conseil et le service client, dans les secteurs aussi divers que l industrie, la défense, les télécoms, la banque et l assurance, il crée OCTO Technology, cabinet spécialisée dans l architecture de systèmes d information. En 1999, il part ouvrir et diriger l agence espagnole d OCTO à Madrid jusqu au rachat du cabinet par le Groupe Aubay, qu il rejoint en 2002, en qualité de Directeur Technique. A 42 ans, Cyrille Devaux occupe le poste de Directeur au sein de Aubay Management, département spécialisé dans le conseil. Bibliographie : Livre blanc ECM (2006), Livre Blanc EAI (1999). Aubay est une société de conseil en technologies et intégration de systèmes d informations, réseaux et télécoms fondée en 1997. La société dispose de plus de 2000 collaborateurs répartis dans 6 pays (France, Belgique, Luxembourg, Italie, Espagne et Portugal). En 2007, Aubay a réalisé un chiffre d affaires de 155,3 millions d euros et une marge opérationnelle de 9,5%. Ont également participé à la constitution de ce livre blanc : Lionel BOURCERET, Barbara GORY, Luc BERNARD. Pour tous renseignements complémentaires : cdevaux@aubay.com ou pesteves@aubay.com 2008 AUBAY. Tous droits réservés Les informations contenues dans ce document représentent le point de vue actuel de Aubay sur les sujets exposés, à la date de publication. Dans la mesure où les éditeurs cités doivent s adapter aux conditions changeantes du marché, Aubay ne peut pas garantir l exactitude des informations présentées après la date de publication. Les noms de produits ou de sociétés dans ce document peuvent être les marques déposées de leurs propriétaires respectifs. Urbanisation & Architecture Orientée Service (SOA) - 2
SOMMAIRE 1 INTRODUCTION...5 2 URBANISATION & SOA, LE COUPLE GAGNANT POUR UN SI AGILE...6 2.1 Urbanisation du SI...6 2.2 Principes directeurs de l urbanisation...8 2.3 Règles d or de l urbanisation...8 3 LA DEMARCHE SOA...12 3.1 Concept de service...12 3.2 Fiche signalétique d un service...14 3.3 Contrat de service...14 3.4 Un exemple de modèle SOA...15 3.5 Typologie de services...16 3.5.1 Service Applicatif (ou Use Case)...16 3.5.2 Service Fonctionnel...17 3.5.3 Service Entité (ou Service C.R.U.D.)...17 3.5.4 Service Transverse (ou d Infrastructure)...18 3.5.5 Service Host...18 3.6 Identification des services...18 3.7 Référentiel des services...21 4 BONNES PRATIQUES...24 4.1 Gestion des versions et variantes...24 4.2 Gestion des libellés...25 4.3 Gestion des transactions...27 4.4 Gestion des données de références...28 4.4.1 Définition d un référentiel...29 4.4.2 Principaux types de référentiel...30 4.4.3 Métadonnées d un référentiel...30 4.4.4 Services d accès aux référentiels...31 4.5 Gestion des valorisations par défaut...34 4.6 Gestion des exceptions...35 4.7 Gestion de la sécurité...36 4.8 Utilisation d un bus de service...38 4.9 Préconisations d organisation...40 5 CONCLUSION...41 6 REFERENCES...43 7 GLOSSAIRE...44 Urbanisation & Architecture Orientée Service (SOA) - 3
TABLE DES FIGURES Figure 1 : La démarche d Urbanisation en 4 volets de connaissance 6 Figure 2 : La cascade des règles d or de l urbanisation 9 Figure 3 : Exemple de POS fonctionnel 11 Figure 4 : Le modèle SOA 12 Figure 5 : Eléments logiciels d un service 13 Figure 6 : Composantes d un service 13 Figure 7 : Exemple de modèle SOA 16 Figure 8 : Le Service Applicatif 16 Figure 9 : Le Service Fonctionnel 17 Figure 10 : Le Service Entité 17 Figure 11 : Le Service Transverse 18 Figure 12 : Exemple de regroupement de services en composant 20 Figure 13 : Exemple de diagramme d architecture applicative (sous MEGA) 21 Figure 14 : Description complète d un composant SF 21 Figure 15 : Exemple de site web contenant le référentiel SOA (sous MEGA) 21 Figure 16 : Cycle de vie SOA 24 Figure 17 : Gestion des versions de services 25 Figure 18 : Gestion des libellés scénario 1 25 Figure 19 : Gestion des libellés scénario 2 25 Figure 20 : Gestion des libellés scénario 3 26 Figure 21 : Gestion des libellés scénario 4 26 Figure 22 : Rupture de l intégrité transactionnelle 27 Figure 23 : Transaction - solution actuelle 27 Figure 24 : Transaction solution intermédiaire 27 Figure 25 : Référentiels partagés pour les données de production 30 Figure 26 : Référentiels dupliqués pour les données de nomenclature 30 Figure 27 : Couche d accès simple aux données des référentiels 32 Figure 28 : Gestion des clones 32 Figure 29 : Gestion des données de référence 32 Figure 30 : Données de références cas particulier 33 Figure 31 : Valeurs par défaut scénario 1 34 Figure 32 : Valeurs par défaut scénario 2 34 Figure 33 : Valeurs par défaut scénario 3 34 Figure 34 : Valeurs par défaut scénario 4 34 Figure 35 : Exemple d un cas d erreur nécessitant de lever une exception 35 Figure 36 : Architecture SOA sécurisée 36 Figure 37 : Zone implicite de confiance 36 Figure 38 : Architecture ESB 38 Figure 39 : Rôles et fonctions en relation avec une SOA 39 Urbanisation & Architecture Orientée Service (SOA) - 4
1 INTRODUCTION La capacité d une entreprise à faire évoluer son système d information pour faire face aux changements qu elle rencontrera (fusion, acquisition ou cession d activités...) constitue une des clefs de sa compétitivité. Contribuant à cette capacité d alignement du Système d Information avec les métiers de l entreprise, l urbanisation utilise la cartographie comme principal outil support de son activité. Elle permet d une part de réaliser l inventaire du patrimoine de l entreprise et, d autre part, de mesurer les analyses d impact du système cible, et ceci sur les plans métier, fonctionnel, technique, voire organisationnel. Par ailleurs, l'évolution récente des technologies de l'information et le développement rapide des services sur le Web ont impulsé de nouvelles approches qui permettent de mettre en place des architectures d entreprise plus souples, plus évolutives, et plus aptes à satisfaire les besoins d'agilité de l'entreprise. Dans ce contexte, les objectifs des départements «Architecture Urbanisation - Méthode» de la plupart des grandes entreprises visent aujourd hui à rationaliser et rendre plus modulaire leur patrimoine applicatif pour gagner en flexibilité et répondre plus rapidement aux sollicitations des Métiers ou de la réglementation en vigueur 1. Le présent ouvrage s inscrit dans cette démarche de progrès puisqu il propose d identifier et de formaliser quelques règles d urbanisme et il exposera un certain nombre de bonnes pratiques d une démarche d Architecture Orientée Service (SOA). Il est le fruit de l expérience des consultants Aubay qui interviennent régulièrement sur des missions de conseil en stratégie technologique pour le compte de nos grands clients 2. Le présent livre blanc est composé de 3 chapitres. Le deuxième chapitre introduit les concepts relatifs à l urbanisation et à la SOA. Notons que ce chapitre n a pas vocation à être exhaustif dans son contenu, de nombreux ouvrages traitant déjà de la question. Le troisième chapitre, représentant le cœur du document, présentera certaines règles (ou bonnes pratiques) qui ont souvent été mises en place dans le cadre d une démarche mixte «Urbanisation / SOA». 1 SOX, Bale II, LOLF 2 AGF, Société Générale, GMF Urbanisation & Architecture Orientée Service (SOA) - 5
2 URBANISATION & SOA, LE COUPLE GAGNANT POUR UN SI AGILE Tout acteur du développement d application devrait pouvoir répondre sans ambiguïté aux questions suivantes : Quel modèle d architecture applicative faut-il adopter selon le type d application? Comment accéder aux données et traitements déjà présents dans le patrimoine applicatif? Comment sont gérées les données de références de l entreprise? Quelles règles de communication faut-il suivre entre applications? Existe-t-il au sein de l entreprise un annuaire des services partagés? comment y accéder? Comment contribuer à l enrichissement de cet annuaire? Répondre à ces questions revient en fait à définir certaines règles d urbanisation du SI et à clarifier les principes architecturaux pour le développement des nouvelles applications. Le métier d'architecte technique (ou de système informatique) existe depuis longtemps. Celui d'urbaniste, parfois nommé architecte d entreprise (ou de système d information), est en revanche beaucoup plus récent. Urbaniste et architecte sont aujourd'hui deux métiers complémentaires dont les rôles sont fondamentaux dans la conception, l'implantation et l évolution de systèmes durables. Ensembles, l architecte et l urbaniste disposent d une vision globale à la fois des processus, des informations et de leurs interdépendances. A ces deux fonctions, il convient d ajouter celle d'administrateur de référentiel de données dont l objet est d'assurer une définition précise des règles de gestion et un propriétaire unique (dans le sens objet du principe) à chaque information manipulée par l organisation. Voir à ce sujet le chapitre 4.4 de ce document. 2.1 Urbanisation du SI Urbanisation du SI : Action de structurer de façon cohérente et modulaire le SI en définissant les niveaux de représentation, en répartissant les éléments et les responsabilités qui y sont liées par niveaux, et en définissant les règles communes ou spécifiques. Urbanisation & Architecture Orientée Service (SOA) - 6
Urbaniser le système d information, c est donc définir un cadre cohérent, stable et modulaire dans lequel viendront s insérer les développements informatiques. Deux grandes préoccupations vont ainsi guider la démarche d urbanisation : la désimbrication des systèmes, des différents métiers puis des différentes activités de façon à éviter l enchevêtrement des applications informatiques correspondantes. Ce découplage a pour contrepartie la mise en place de référentiels communs 3. la recherche du juste équilibre entre subsidiarité 4 et mutualisation, la difficulté de cet exercice est de placer la responsabilité du système au plus près du terrain pour rendre l entreprise plus réactive tout en réalisant des économies d échelle et en garantissant la cohérence de l ensemble. La cartographie du SI La cartographie considère en général quatre visions du système d'information : la vision métier qui décrit les processus ou activités que le SI doit supporter, la vision fonctionnelle qui décrit les fonctions du SI permettant de représenter les processus, la vision applicative décrivant l'ensemble des éléments applicatifs du SI, la vision technique décrivant l'architecture technique (matériels, logiciels et technologies utilisés). Cartographie métier Les systèmes d information doivent être cartographiés du point de vue métier : Les objets manipulés sont des processus, acteurs, rôle, objets métiers L exploitation des cartographies métiers se fait au travers : o des études d'impacts (par exemple, lors d une fusion d activité ou lors de l éclatement d'activités) o des études d optimisation des processus (par l analyse des points sensibles des processus). Cette vue définit par conséquent des domaines et les processus métiers qui relient ces domaines par des flots de données. Ces informations doivent être transposables d une entreprise à une autre. Cartographie fonctionnelle Les systèmes d information doivent être cartographiés du point de vue fonctionnel : Les objets manipulés sont des domaines d activité, des domaines de responsabilité, Le découpage doit s effectuer autour d invariants métiers (objets métiers, fonctions ), Les échanges doivent être identifiés entre domaines fonctionnels, Des référentiels communs doivent être identifiés autour des objets ou données métiers. Cette vue représente la mise en œuvre particulière du métier dans l entreprise mais doit restée découplée des solutions techniques de mise en œuvre informatique. Cartographie applicative Les systèmes informatiques doivent être cartographiés du point de vue applicatif (ou logiciel) : Les objets manipulés sont des applications, des composants logiciels, des bases de données On y identifie les modes de communication entre composants (synchrone/asynchrone, MOM/fichier/DB/http,...), On y précise les outils communs (ex : modules communs de gestion des logs, des traces, des statistiques ) On précise les standards techniques (choix) et les règles de gestion concernant les plateformes logicielles (ex : distinguer l environnement de développement de celui de production). La vue applicative est la partie automatisée du SI. Elle va décrire les solutions technologiques retenues pour réaliser certaines fonctionnalités du SI Cartographie technique Les systèmes d information doivent être cartographiés du point de vue technique (ou matériel) : Les objets manipulés sont du matériel (serveurs ), du câblage, des bâtiments, etc. On y précise les règles de gestion des plates-formes (i.e. une seule plate-forme pour N applications ou N platesformes pour une application ; plate-forme 24x7 ) On précise les règles de dimensionnement des tuyaux, les contraintes d exploitation, de sécurité. 3 Un chapitre entier sera consacré à ce point majeur d une architecture d Entreprise. 4 Subsidiarité : Le principe de subsidiarité est une maxime politique selon laquelle la responsabilité d'une action publique doit être allouée à la plus petite entité capable de résoudre le problème d'elle-même. C'est donc le souci de veiller à ne pas faire à un niveau élevé ce qui peut l'être avec autant d'efficacité à une échelle plus faible. Urbanisation & Architecture Orientée Service (SOA) - 7
2.2 Principes directeurs de l urbanisation Quatre principes directeurs dirigent l élaboration des règles de l urbanisation : Cohérence forte / couplage faible Le processus métier global d une entreprise est découpé en zones, contenant chacun des quartiers, comprenant à leur tour des blocs pour lesquels les données et les traitements présentent une forte cohérence (cohérence forte) et une frontière bien délimitée avec les blocs connexes (couplage faible). Pas de dépendance temporelle entre blocs, chacun opérant de manière asynchrone par rapport aux autres. Encapsulation Le bloc est seul propriétaire de ses données et de ses traitements. Ses données sont masquées pour les autres blocs, un bloc ne peut donc accéder aux données d'un autre bloc qu'en faisant appel aux services que propose celui-ci. Mutualisation Partager les éléments du SI qui peuvent être utilisés par plusieurs blocs : - Par la mise en œuvre de référentiels d objets, - Par le déploiement d une infrastructure d échange (EAI ou ESB), - Par la mise en œuvre progressive d une approche orientée «service» (SOA). Echanges contrôlés A la frontière de chaque bloc, les échanges avec l'extérieur se font au moyen d'interfaces publiques et éventuellement par l'intermédiaire d'une infrastructure fédératrice (annuaire). Chaque bloc produit des résultats et des rapports avec un format standard sans présumer des destinataires. Chaque interface est gérée par version pour prendre en compte le cycle de vie des blocs et de l infrastructure de communication. 2.3 Règles d or de l urbanisation De ces principes directeurs découlent un certain nombre de règles pour l implémentation d une démarche d Urbanisation. Ces règles se situent sur trois plans : au niveau «Stratégique», en rapport avec les grandes orientations communiquées par la Direction Générale (ou Comité Directeur) ; au niveau «Tactique», relevant plus d une politique de gouvernance du Système d Information et enfin au niveau «Opérationnel», en rapport avec des choix de mise en œuvre. Nous reprendrons ci-après dans le détail les règles du niveau «Tactique» puis le reste du document sera exclusivement consacré à la mise en place de la dernière règle de niveau opérationnelle : la mise en place d une SOA. Urbanisation & Architecture Orientée Service (SOA) - 8
R1 : Respecter les zones d urbanisme (ou Plan d Occupation des Sols) Tout système doit s'inscrire dans une et une seule "zone d'urbanisme" (premier découpage macroscopique). On distribue ainsi les systèmes applicatifs 5 dans les zones : de présentation/acquisition (couche de front office ou commerciaux), de traitements métiers (couche de back office ou de gestion), d'échange et diffusion (couche middleware), de gestion des référentiels, de fonctions support à l entreprise (SI Financier, SI Ressources Humaines), de pilotage et de reporting. Par exemple, un système ne devrait pas cumuler des préoccupations commerciales (simulations de devis, règles de gestion simplifiées) et des préoccupations administratives (caractéristiques contractuelles des contrats, règles de gestion rigoureuses). Autre exemple, une application ne doit pas gérer à la fois des contrats et assurer la production de statistiques d'aide à la décision (qui est la vocation d'un système de pilotage). Gains attendus Eviter la redondance fonctionnelle Meilleure évolutivité du Système d Information (limitation de l'imbrication des traitements) Pilotage plus simple de l évolution du système d information par une vision d ensemble urbanisée permettant d appréhender plus rapidement l impact d une évolution fonctionnelle ou technologique, de localiser les zones de progrès, par exemple, grâce à des métriques calculées à partir de la cartographie. R2 : Limiter les nouveaux développements Réutiliser (au sens «mutualisation» et non «réplication») plutôt qu acheter, acheter plutôt que développer, développer seulement pour acquérir un avantage compétitif certain et durable. En cas de développement, il faut veiller à respecter les standards et normes de l entreprise. Gains attendus Réduction de la diversité du patrimoine applicatif Réduction des coûts 5 On définit un SA comme étant le regroupement de fonctions métiers au sein d une même entité informatique Urbanisation & Architecture Orientée Service (SOA) - 9
R3 : Contrôler les flux d information entre applications La gestion des échanges doit être pilotée par un bus de communication inter-applicatifs (type, EAI, ESB, MOM selon besoin). Une bonne gestion des flux est particulièrement importante pour la cohérence du SI et elle doit respecter un certain nombre de principes : Tous les flux doivent être identifiés (donc inscrits dans la cartographie), Tout flux doit être préférentiellement basé sur un échange asynchrone de type Message, Tout SA échange avec l extérieur via une couche d abstraction normalisée et documenté, Tous les flux doivent être gérés par un unique outil central (type bus de communication inter-applicatifs). Gains attendus Fiabilité et cohérence des échanges de données, Pilotage et traçabilité des événements, Analyse statistiques des flux, Sécurisation de la mise en production des nouvelles versions d échanges, R4 : Partager les données communes Les données communes de l entreprise sont contenues dans des bases dites référentielles. Un référentiel ne contient que des informations de référence. Une information de référence est principalement caractérisée par son partage entre plusieurs systèmes applicatifs et par un fort accès consultatif. Un référentiel peut aussi concerner les données communes de nomenclature (paramètres applicatifs). Pour chaque référentiel, il est nécessaire de bien identifier sa localisation et de développer une architecture d'échange (normalisée et indépendante) d'informations entre les applications pour permettre la circulation des informations présentes dans les référentiels. Gains attendus Vision commune des informations de référence de l entreprise, évitant ainsi aux applications toute divergence ou désynchronisation sémantique sur une donnée, Mutualisation des infrastructures de gestion des tables communes. R5 : Partager les traitements métiers Les traitements métiers doivent être encapsulés sous forme de services réutilisables. Le catalogue des services devra être géré via un annuaire. Mesure d avancement Une démarche d Urbanisation est un projet de longue haleine. Il s agit donc de bien mesurer au fur et à mesure des mois qui passent l avancement de cette démarche de progrès! A cette fin, le Club Urba a formalisé un outil de suivi de l avancement au travers le calcul d un indice d avancement. Graphiquement, il se représente ainsi : Urbanisation & Architecture Orientée Service (SOA) - 10
La suite du document se focalisera plus précisément sur la dernière règle énoncée : partager les traitements métiers. Nous donnerons ainsi quelques bonnes pratiques relatives à la mise en place des Architectures Orientées Services. Urbanisation & Architecture Orientée Service (SOA) - 11
3 LA DEMARCHE SOA L architecture orientée services (SOA) s inscrit dans une démarche d urbanisation qui guide la mise en place des applications «métiers» et fixe la frontière entre réutilisation de l existant (mainframe ) et nouveaux développements. L architecture SOA favorise la réutilisation fonctionnelle au travers de l approche service. Cette approche est un modèle d'interaction applicative mettant en œuvre des composants logiciels avec une forte cohérence interne et des couplages externes «lâches». Elle permet en outre de contractualiser la mise à disposition des grandes fonctions métier de l entreprise et induit une mise à disposition homogène de ces fonctions. De plus cette approche permet d envisager de manière uniforme la mise en place de fonctions communes comme l administration, l exploitation, la sécurité, etc. 3.1 Concept de service Conceptuellement, un service expose une fonction métier ou technique, qui doit : avoir le sens le plus universel pour une réutilisation optimale, être stable et pérenne, donc indépendante de son implémentation. Le service est de préférence autonome, favorisant ainsi le couplage faible entre services. Il implique de gérer un contexte d appel transmis mais non mémorisé (service «sans état»). Il fonctionne en toute transparence, fournissant des informations sur son exécution, ses performances Un service est donc une prestation élémentaire : assurée au bénéfice : - D une application, - D un processus métier, - D un autre service. partagée entre plusieurs applications, processus ou services, documentée et publiée, - Dans le référentiel des Services, - Dans les cartographies d urbanisation. conforme à une structure d implémentation modèle (selon sa typologie). Urbanisation & Architecture Orientée Service (SOA) - 12
Techniquement, un service, c est un ensemble d opérations exposées et accessibles aux consommateurs. La composante «Interface» est une description des Entrées / Sorties pour l ensemble des méthodes du service 6 (voir le chapitre sur le contrat de service). L implémentation représente la réponse codée à la fourniture des fonctionnalités exposées par l interface. Elle peut être de diverses natures car, étant masquée aux utilisateurs du service, le choix d une technique de mise en œuvre (technologies Web Service ou EJB ou connexion directe JDBC ) n a en principe pas d impact sur son exécution (à part un impact de performance mais qui est alors explicitement indiqué dans le contrat de service). L aspect Mapping est une couche technique (optionnelle) de mise en relation entre deux éléments de natures distincts (ex : objet java coté Service & structure à plat coté host, éventuellement au travers de l utilisation d un outil type hibernate). Les bouchons sont nécessaires pour les phases de tests et font partie intégrante des éléments logiciels du service. Concrètement, un service, c est l ensemble de composants suivants : 6 On utilisera indifféremment le terme «Service» pour désigner le composant ou l une de ses opérations. Urbanisation & Architecture Orientée Service (SOA) - 13
Du point de vue des outils support à l utilisation des services, les choix sont partagés de la façon suivante : La partie Descriptif (les spécifications du service) sera mémorisée dans un outil référentiel 7 constituant ainsi le référentiel des Services de l entreprise. La partie Code (l implémentation du service et des tests associés) sera gérée avec l outil retenu de gestion des versions des développements informatiques (Ex : Source Safe, CVS ). 3.2 Fiche signalétique d un service La fiche signalétique d un service est la carte d identité du service. Elle expose en quelques lignes les tenants et aboutissants du service. C est donc une composante essentielle de la partie descriptive et documentaire du service. Elle reprend l ensemble des éléments suivants : Nom du service Version actuelle Compatibilité avec autres versions Date de mise en service Date de péremption Entités métiers manipulées Applications clientes utilisatrices du service 8 Processus métiers clients (option) Sous services utilisés (ou appelés par le service décrit) 3.3 Contrat de service La valeur d une architecture de services repose sur des contrats qui garantissent stabilité, assurance et performance entre interlocuteurs. Un contrat de service spécifie un contrat d interface (nature des informations fournies et générées) et une qualité de service attendue et admise par les parties prenantes : Le contrat d interface caractérise les conditions d utilisation et garantit un service sans état à des fins de mutualisation (type de traitement, données d entrée et données de sortie, contraintes de sécurité). La qualité de service porte sur la disponibilité (éventuelle via la mise en place de solutions dégradées), la réactivité (temps de latence/délai d exécution, débit), la sécurité et, éventuellement, le coût de fonctionnement. Concrètement, le contrat de service se compose donc des éléments suivants : Politique d Utilisation - Description des interfaces d appel - Description des paramètres d appel Politique de sécurité - Authentification du demandeur - Gestion des droits d accès - Cryptage des informations Politique de robustesse - Présence d un Secours, mode dégradé/différé, reprise Politique de performance - Réactivité du service - Seuils d alerte, statistiques périodiques Politique d administration (suivi qualité de service) - Taux de disponibilité, indisponibilité maximale. 7 Repository de Service (WSRR chez IBM, MEGA V2007 ) 8 Utile pour l analyse d impact d une modification apportée sur un service. Urbanisation & Architecture Orientée Service (SOA) - 14
WSDL (Web Service Description Language) Description (basée sur XML) d une Interface publique d'accès à un service. Précise plusieurs aspects dont principalement : Le protocole de communication (binding) Les opérations exposées par le service (porttype) Le format de paramètres requis pour communiquer avec ce service (message) Syntaxe : Exemple de description WSDL d un service de contrôle d une adresse postale : 3.4 Un exemple de modèle SOA Une architecture SOA est donc basée sur la notion de service tel que décrit précédemment. Cependant, il reste de nombreux aspects à déterminer et à figer dans un modèle d entreprise. L agencement de ces services forme l architecture SOA (ou le modèle SOA) retenue pour l entreprise. Urbanisation & Architecture Orientée Service (SOA) - 15
Dans ce modèle, figurent plusieurs types de service. On parle alors de typologie de service comme décrit ci-après. 3.5 Typologie de services Il existe plusieurs catégories de services selon que l on les classe par nature de services (catégorisation verticale sur la figure 7) ou domaines de services (catégorisation horizontale). 3.5.1 Service Applicatif (ou Use Case) 9 Le Service Applicatif permet de mettre en œuvre la logique applicative d une application telle qu elle a été identifiée par les cas d utilisation ou les processus métiers. Ce service est fortement lié à la logique de l application qui a nécessité sa création ; en général, il n est donc pas réutilisable, hors du contexte de l application. Le service applicatif active des règles de gestion qui vont conduire, dans le contexte de l application, à la modification d une grappe d objets métier. 9 Au sens UML du terme. Urbanisation & Architecture Orientée Service (SOA) - 16
3.5.2 Service Fonctionnel Le Service Fonctionnel permet d exposer des traitements métiers identifiés comme réutilisables dans des contextes variables (ex: calcul de devis). Le service fonctionnel travaille sur des objets métiers et fait donc appel à des services Entité ou Transverse. Dans le cas de l exposition d un service Host de haut niveau (et correspondant fonctionnellement à un SF), on s oblige à créer un SE de passage (prise en compte de la gestion du mapping ). La Valeur Ajoutée du SF réside dans ses caractéristiques particulières (mais arbitraire car dépendant du modèle SOA que l on décide d établir) : Le SF peut faire appel à des services plus élémentaires ou externes (partenaires). C est la notion d orchestration. Le SF représente la couche logicielle où seront prises en compte la gestion de la sécurité, des règles métiers déportées (ex : calculs globaux sur des listes) ou encore des libellés (voir plus loin dans le paragraphe). 3.5.3 Service Entité (ou Service C.R.U.D.) 10 Le Service Entité expose les opérations basiques suivantes : Créer un nouvel objet métier dans le référentiel concerné. Rechercher un ensemble d objets métier selon des critères de recherche. Lire un objet métier selon une clef d accès unique. Exporter un objet vers un format donné (excel, pdf ). Mettre à jour un objet métier. Ce type de service permet de faire la transition entre le monde des référentiels de données et le monde de l application. Il s agit de transformer des données provenant d horizons hétérogènes en objets métier utilisables par les applications mettant 10 Signifie «Create Research Update Destruction» (les 4 opérations élémentaires sur un objet) Urbanisation & Architecture Orientée Service (SOA) - 17
en œuvre la SOA, et d assurer l opération inverse afin d enregistrer les modifications réalisées dans l application. Ces services sont importants dans la mesure où ils permettent de rendre les applications indépendantes du format de stockage des données métiers ainsi que de leur localisation. Concernant l opération de recherche, il est intéressant de raisonner en «niveau de profondeur» sur l objet métier retourné. En effet, un objet métier est généralement lié à d autres objets («Clients» avec «contrats», «contrat» avec «sinistres» ). Se pose alors la question de savoir quelle «grappe» d objet voulait en pratique l utilisateur qui demande un objet Veut-il simplement l objet métier racine ou veut-il un ensemble plus large d objets, tous reliés à l objet racine, origine de la requête? Pour répondre à ces différents cas, il est d usage de paramétrer les requêtes de recherche avec un type (ou scénario) de recherche. Ainsi, selon le scénario précisé, la requête retournera l objet métier seul ou un ensemble d objet selon une profondeur donnée sur la grappe d objet. Bien évidemment, le programmeur du composant CRUD installera des contrôles afin d éviter qu une requête mal définie tente de ramener «l ensemble du SI» 3.5.4 Service Transverse (ou Infrastructure) Un Service Transverse offre des services dont la problématique n est pas uniquement métier. Un service transverse peut éventuellement être client d autres services transverses mais cette dépendance est peu souhaitable. Exemples de Services transverses : Service de log Service de gestion du Contexte Utilisateur Service de gestion des libellés 3.5.5 Service Host Dans la majorité des grandes entreprises, l existant est aussi constitué d applications Mainframe. Les applications du HOST doivent alors être exposées au travers de services Host accessibles par les applications distribuées. Le pont entre les deux milieux (Host et distribué) peut se faire de différentes manières, nombreux sont les logiciels d infrastructure 11 qui se proposent d encapsuler et d exposer les services HOST (IMS, CICS ) à l extérieur. 3.6 Identification des services L identification des services est une étape importante dans la démarche SOA 12. On cherche en effet à identifier des Services Métier Réutilisables : Service : interaction unitaire avec le SI, comprenant une interface et exposé par un composant logiciel Métier : s exprime en langage métier, indépendamment de l implémentation. Réutilisable : tous processus de l entreprise qui mobilisent cette fonction devraient utiliser le même service 11 Il est possible de disposer d un serveur d applications sur le HOST, facilitant ainsi la communication avec l extérieur du Host. 12 On notera l effort particulier de IBM dans la formalisation d une méthode d identification des services. La méthode SOMA. Urbanisation & Architecture Orientée Service (SOA) - 18
Cette démarche s appuie sur plusieurs axes à la fois : Analyse des processus métiers (ou approche Top-Down) Analyse des objectifs métiers Analyse de l existant (ou approche Bottom-up) et sur le bon sens! SOMA : Méthode d origine IBM, est un support méthodologique à l alignement d une business architecture et d une architecture orientée service par une analyse combinée top-down (business driven, process based) et bottom-up (réutilisation des systèmes existants ou en projet). La première étape «identification des services candidats» peut suivre 3 approches. Le Domain decomposition est une analyse de processus métier. Elle répond donc aux règles de l analyse de processus. Le souci principal est d obtenir une analyse appropriée à la décomposition en services par l application des principes suivants : Identifier l événement métier déclencheur. N utiliser que des termes métier (sans lien avec les applications ni la technologie). Reste à savoir à quel niveau de décomposition s arrêter? Suivre la Rule of thumb 3 levels mais d autres critères peuvent s ajouter : Tâche unitaire. Issue d un acteur unique d une organisation unique. Complétude nécessaire pour aborder la tâche suivante. Contient au moins une interaction avec le système d information. Éventuellement transactionnelle. A la fin de cette phase, chaque tâche devient un service candidat pour ajout dans le portefeuille des services candidats. Goal Service Modeling consiste à identifier les objectifs Métier portés par le ou les processus (ex : Améliorer une productivité, un chiffre d affaire, une qualité de service, la qualité d information ). Dans cette phase, vont être recherchés les services qui permettent d informer de l atteinte de ces objectifs : Recherche de l existence de services cohérents avec les objectifs. Identifier les indicateurs clé de performance (KPI) : quelle est l information nécessaire à un manager responsable du processus pour valider l atteinte des objectifs? Définir les services qui vont permettre d obtenir cette information. Enfin, l Analyse des systèmes existants passera par : Faire la liste des fonctions des systèmes existants. Identifier les fonctions qui sont dans le périmètre fonctionnel du domaine mais qu on ne trouve pas dans le portefeuille des services candidats. Urbanisation & Architecture Orientée Service (SOA) - 19
La deuxième étape de la méthode revient à sélectionner les services à exposer puis spécifier les services ainsi retenus. La sélection repose sur une analyse de chaque service, le LITMUS, test sur 10 critères : 1. Fonction métier : la fonction correspond à une activité d un processus du métier 2. Réutilisation : plusieurs consommateurs sont identifiés pour le service. 3. Recomposabilité : il est possible de réutiliser le service dans le cadre d autres modes opératoires 4. Granularité : il n y a pas de possibilité d élargir la granularité du service pour augmenter sa réutilisation 5. Redondance : il n y a pas d autre service qui présente les mêmes entrées sorties et le même périmètre fonctionnel 6. Pas de gestion d état : les données d entrée et les données persistantes sont suffisantes pour que la fonction s exécute. Il ne tient pas compte des interactions passées. 7. Ininterruptible, sans action de l utilisateur : la fonction, telle qu elle serait implémentée, s utilise en une seule interaction. 8. Encapsulation : la fonction, telle qu elle serait implémentée n a pas besoin de traitements ou données implicites ou complémentaires, imposés par l implémentation. 9. Description externalisable : la fonction, telle qu elle serait implémentée, peut être exposée comme un web service 10. Qualité de service : la fonction, telle qu elle serait implémentée, répond à la qualité de service demandée La troisième étape, celle relevant des Décisions d implémentation, ne constituent pas un processus simple. Ces décisions reposent sur les savoirs faire de l architecte, sur la base des éléments recueillis lors des phases précédentes. SOMA ne propose pas de démarche particulière à ce niveau. L identification pertinente des services est un critère important pour la bonne qualité du SI global. Cependant, vu la grande quantité de services possibles pour les SI des grandes entreprises, il n est pas envisageable de créer autant de composants (au sens du composant logiciel autonome et déployé sur un serveur) que de services qui auront été identifiés. Il s agira donc, dans un second temps de réflexion, de regrouper les services au sein de composants. Les services sont alors appelés «Opérations» du composant qui par extension, peut parfois prendre le nom de service Assez naturellement, la politique de regroupement consistera à regrouper au sein d un même composant les services traitant des mêmes entités (ou objets) métiers mais il pourra éventuellement être tenu compte d autres critères de regroupement comme les contraintes liées au contrat de service (regroupement des opérations à fort besoin de disponibilité au sein d un même composant versus opérations non critiques). Urbanisation & Architecture Orientée Service (SOA) - 20
3.7 Référentiel des services Le référentiel des services sera l unique source d information mise à disposition de la DSI en général et des équipes de développement en particulier. Il contiendra une sorte de répertoire des services ainsi que la cartographie des applications utilisatrices des services. Figure 13 : Exemple de diagramme d architecture applicative (sous MEGA) Le référentiel doit également contenir la description des contrats de service, le détail des opérations (au format WSDL par exemple), la liste des applications utilisant le service et une vision des données (sous forme de Diagramme de classe) des objets manipulés. Figure 14 : Description complète d un composant SF Ces informations seront évidement exposées et consultables via un site Intranet. Figure 15 : Exemple de site Web contenant le référentiel SOA (sous MEGA) Urbanisation & Architecture Orientée Service (SOA) - 21