Академический Документы
Профессиональный Документы
Культура Документы
SOA
Le guide de larchitecte du SI
Xavier Fournier-Morel, Pascal Grojean Guillaume Plouin, Cyril Rognon
Prface de Luc Fayard
MANAGEMENT
2e dition
SOA
Le guide de larchitecte
Management dun projet systme dinformation Principes, techniques, mise en uvre et outils 4e dition Chantal Morley 416 pages Dunod, 2004
Dvelopper un projet internet Nouvelles logiques et pratiques prouves Claude Salzman 272 pages Dunod, 2001
Management dun projet systme dinformation Principes, techniques, mise en uvre et outils 4e dition Chantal Morley 416 pages Dunod, 2004
SOA
Le guide de larchitecte du SI
Xavier Fournier-Morel
Responsable du ple architecture de SQLI Suisse
Pascal Grojean
Responsable de SQLI Consulting
Guillaume Plouin
Responsable de la veille technologique du groupe SQLI
Cyril Rognon
Responsable "capitalisation et R&D" de SQLI Consulting
2e dition
Toutes les marques cites dans cet ouvrage sont des marques dposes par leurs propritaires respectifs.
Source : digitalvision
Prface
loge de louverture. Rgle numro un : le client a toujours raison. Rgle numro deux : si jamais le client a tort, relire la rgle numro un. Le fameux slogan des magasins amricains Stew Leonard pourrait sappliquer au systme dinformation, en prenant le mot client dans toutes ses acceptions. Car ce qui a vraiment chang ces dernires annes en informatique, cest peut-tre cela : un regard diffrent sur son environnement, la comprhension quun beau projet est forcment un travail en commun, non seulement des hommes mais aussi des ressources et des outils. Cest sans doute cette force de louverture qui pousse la webisation des applications dentreprise dune part et aux SOA (Services Oriented Architecture) dautre part. Cette architecture oriente services fut dabord lance comme un concept la mode et elle aurait pu terminer comme nombre dentre eux, dans larrire-salle des fausses bonnes ides. Mais elle fut rapidement relaye par des vraies mthodes et des outils. Au point de devenir peut-tre le levier le plus important aujourdhui dans la modernisation de linformatique. Un autre des grands avantages des SOA et des services web est de renforcer le lien entre fournisseurs et utilisateurs : difficile en effet de relier des composants mtiers sans se pencher sur ces mtiers ! On a vu alors cette chose impensable quelques annes auparavant, la constitution de groupes de projets multidisciplinaires ou les spcialistes de la technologie et ceux de lentreprise commenaient enfin se parler dgal gal ! Cette ide que linnovation rside plus dans lusage que dans la technologie ellemme est probablement la vraie rvolution. Elle change le regard des crateurs de produits high-tech qui ne les conoivent plus en fonction de spcifications purement techniques mais comme une rponse aux besoins du march. Elle implique les utilisateurs beaucoup plus tt dans le processus de la conception. En intgrant la notion de SOA, linformatique ne fait que se mettre au diapason du business moderne o le client est roi, le marketing one to one et le travail collaboratif.
IV
Prface
Mais nous nen sommes quau dbut de cette nouvelle re, le jargon est encore l, les explications ne sont pas toujours des plus claires. Cet ouvrage est donc le bienvenu. Dautant que les SOA ne sont quune solution nouvelle un vieux problme : ce nest pas dhier en effet que datent les rflexions sur les composants et la sparation des applications en couches. Ni SOA ni web services ne sont la panace : larchitecture homogne et fluide cest bien, les donnes standardises cest mieux. La multiplicit des normes et des standards, la dcomposition trop accentue peut-tre des diffrentes briques, le difficile passage du concept la ralit, autant dobstacles franchir. Pour obtenir cette informatique moderne, fluide, agile dont tout le monde rve, il reste encore beaucoup de travail faire. Mais les SOA sont sans doute une tape incontournable. Luc Fayard Directeur de la rdaction de 01 Informatique
Avant-propos
Les problmatiques de communication et dintgration entre les applications htrognes au sein dune entreprise sont un vieux dfi de linformatique. On a tent par le pass de les rsoudre par diverses mthodes et technologies : scripts pilots par batch, changes de fichiers par FTP, middleware orients message, EAI, etc. Avec Corba, on a essay dapporter une rponse standardise la problmatique, mais sans rencontrer de rel succs dcisif. Or lempilement des applications au fil du temps a conduit une situation intenable de silos tanches . Labsence de solution architecturale efficace pour rsoudre ce problme a plong les systmes dinformation dans une situation de blocage vis--vis des exigences des mtiers. Les architectures orientes services (SOA) offrent aujourdhui un nouveau modle et une formidable opportunit pour rsoudre ces problmatiques. Elles vont mme beaucoup plus loin puisquelles permettent de mettre le systme dinformation au service des mtiers, en procdant son alignement avec les processus dentreprise. Cet ouvrage a pour objectif de prsenter et de recadrer la dfinition et les usages de SOA. Il sagit dexposer les concepts de service dans larchitecture du systme dinformation, sans tomber dans le pige de la description de limplmentation technique. En effet, trop de personnes confondent aujourdhui SOA et Web Services. Les auteurs souhaitent se dmarquer des divers livres blancs disponibles sur le sujet en faisant la part entre leffet de mode, le marketing des diteurs et lapport vritable de ces types darchitecture par rapport ce quils appellent le cahier des charges des SI agiles . Ils proposent de lister les questions se poser pour dployer SOA bon escient, en mettant laccent sur une mthodologie pertinente qui recouvre les aspects architecturaux et organisationnels. Un modle dimplmentation technique est alors propos au travers des Web Services et dautres approches bases sur JEE. Un clairage est donn sur la vision des architectures de services propose par les acteurs du Web 2.0, et sur le caractre complmentaire plutt que contradictoire de cette vision avec lapproche SOA.
VI
Avant-propos
Enfin, les auteurs prsentent lensemble des outils ncessaires la mise en uvre et la maintenance dune architecture SOA, et font le point sur les rponses des diteurs de logiciels ces besoins.
Premire partie Le cahier des charges des SI agiles Lobjectif de cette premire partie est dintroduire les problmatiques de rationalisation des systmes dinformation, puis de prsenter un cahier des charges pour disposer dun SI en phase avec les attentes actuelles.
Elle prsente tout dabord un historique de lvolution des systmes dinformation et montre comment ces derniers sont souvent complexes et peu cohrents. Elle voque ensuite le besoin d agilit des SI dans le contexte actuel dacclration de lconomie mondiale. Elle explique, de plus, pourquoi les outils dont disposaient jusqu prsent les DSI rpondaient mal leur problmatique de bonne cohrence. Enfin, elle aborde les exigences mtiers et techniques que lon peut attendre dune nouvelle dmarche dorganisation et dintgration du SI. La suite de louvrage montrera comment SOA rpond ces exigences.
Cette partie introductive est accessible tous les profils : matrises duvre comme matrises douvrage.
Seconde partie Prsentation de lapproche SOA Lobjectif de cette deuxime partie est de clarifier les concepts utiliss, en commenant par la notion de services et darchitecture de services, puis dintroduire la composition de services. Elle prsente une architecture de rfrence positionnant les diffrents concepts. Elle clarifie galement pourquoi les Web Services sont utiles, mais pas indispensables.
Elle sattache dcrire les fondements du concept de service et notamment la notion de contrat et de messages. Enfin, elle introduit les outils mettre en place de faon progressive en regard de larchitecture SOA de rfrence.
Cette partie est conceptuelle. Elle est accessible tous les profils de matrises duvre, mais aussi aux matrises douvrage qui dsirent apprhender en profondeur les architectures fonctionnelles ralisables avec SOA.
Troisime partie SOA : Tout repose sur la mthode La partie 3 prsente les principaux aspects mthodologiques de lapproche SOA, avec deux points de vue complmentaires : la modlisation de larchitecture et le cycle de vie dun projet SOA.
Cette partie traite dabord de la modlisation des services. Est aborde ensuite la modlisation des processus mtier, ladoption de SOA par les entreprises tant en grande partie lie la volont de mettre en place de nouveaux processus mtier.
Avant-propos
VII
Enfin, le chapitre sur la modlisation des applications interactives propose dtudier limpact de SOA sur le classique modle MVC. Le chapitre sur le cycle de vie dun projet met en vidence les impacts de SOA sur les diffrentes tapes dun cycle de vie logiciel. Loutillage de ce cycle de vie conduit aborder les aspects productivit et examiner la relation entre SOA et MDA. SOA nest pas une mode mais une volution profonde de la faon de penser le systme dinformation : les quipes doivent donc mrir, et la partie 3 se clt sur la prsentation dun modle de maturit architecturale, complmentaire dune dmarche dindustrialisation de dveloppements de Type CMM-I.
Cette partie mthodologique vise les architectes et chefs de projets.
VIII
Avant-propos
Cette partie est trs technique : elle sadresse aux chefs de projets techniques et dveloppeurs qui mettront en place SOA sur le terrain.
Sixime partie. SOA et Web 2.0 La blogosphre oppose souvent les approches SOA et Web 2.0. Une thse rgulirement avance suggre que SOA serait une dmarche lourde et complexe tandis que le Web 2.0 proposerait la simplicit et lagilit. Cette partie montre comment les deux approches ne sopposent pas, mais sont au contraire complmentaires. Elle explique en dtail les concepts et principes darchitecture qui sous-tendent le Web 2.0 : Mashups, Ajax et REST. Enfin, elle analyse cette approche Web 2.0 dans la perspective de construire une SOA dentreprise, en mettant en avant ses avantages et ses inconvnients en vitant un engouement aveugle comme un dnigrement systmatique.
Cette partie traite dalternatives en termes darchitecture technique. Elle intressera les architectes, chefs de projets techniques et dveloppeurs.
Septime partie Dcrypter loffre du march Cette dernire partie dresse un panorama des outils disponibles pour btir, hberger, excuter et administrer les solutions mtier SOA. Elle prcise le primtre de lESB (Enterprise Service Bus), en liste les principales fonctions techniques. Elle prsente les outils complmentaires de lESB, comme le registre des services, lorchestrateur, le distributeur de requtes CRUD ou le cache de donnes. Elle introduit de ce fait, le concept de plate-forme SOA, encore appele APS, Application Platform Suite. Elle se termine par une prsentation des diteurs qui proposent un outillage SOA. Si cette prsentation nest pas exhaustive, elle donne les critres permettant daboutir un choix doutils raisonn.
Cette partie intressera les architectes et quipes dexploitation, responsables de choisir les bons outils pour construire et maintenir une SOA.
Remerciements Les auteurs tiennent tout dabord remercier leurs pouses pour leur patience et leur soutien pendant les longs mois de la rdaction de ce livre. Leur reconnaissance va aussi Bruno LEYSSENE et Yahya EL MIR, directeurs du groupe SQLI, qui ont sponsoris et rendu possible ce projet. Le soutien dEmmanuel BOUCHET, directeur de SQLI Suisse, a aussi t dun grand secours. Enfin, ils remercient des collgues et amis qui ont bien voulu relire louvrage et les faire bnficier de leurs remarques pertinentes : Jean-Christophe BROQUAIRE, Zakaria EL MOUJAHID, Jacques KHA, Xavier LINAIS, Pascal CADET, Gabriel KASTENBAUM et Hugues MARGUET.
Prface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Avant-propos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
III V
2.2 Un outillage au service des urbanistes . . . . . . . . . . . . . . . . . . . . 2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 Les outils EAI . . . . . . Les outils de workflow . . Les portails Web . . . . . Les langages objets . . . . Un constat de frustration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13 13 14 15 17 18 19 19 19 20 20 21 21 22 24 25
Chapitre 3 Le cahier des charges du SI . . . . . . . . . . . . . . . . . . . . 3.1 Les exigences des mtiers . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Dployer rapidement des processus mtiers . . . . . . . . . . . . . . . . 3.1.2 Les mtiers ont besoin dune vision temps rel sur le business . . . . . . 3.1.3 La DSI doit justifier son budget . . . . . . . . . . . . . . . . . . . . . 3.2 Les exigences techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 3.2.2 3.2.3 3.2.4 Inciter la rutilisation . . . . . . . . . . . Faciliter les changes tous les niveaux du SI Reposer sur des rfrentiels de mta-donnes . Piloter la plate-forme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
XI
4.4.4 Quels problmes cls ? . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.5 Premier bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Quelques ides reues sur SOA . . . . . . . . . . . . . . . . . . . . . . . 4.5.1 Ce que SOA nest PAS ! . . . . . . . . . . . . . . . . . . . . . . . . 4.5.2 Ce que SOA ne dit PAS ! . . . . . . . . . . . . . . . . . . . . . . . Chapitre 5 Au cur de SOA : le concept dorientation service . . . . . . . 5.1 Formaliser les services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 Service et contrats . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.2 Service et messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Spcifier un contrat de service . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Que contient un contrat de base ? . . . . . . . . . . . . . . . . . 5.2.2 Contrat et qualit de service . . . . . . . . . . . . . . . . . . . . . . 5.2.3 Matriser la coordination de services . . . . . . . . . . . . . . . . . . 5.3 Mettre en production et exploiter les services . . . . . . . . . . . . . . . 5.3.1 Le dploiement des services . . . . . . . . . . . . . . . . . . . . . . . 5.3.2 La gestion des variantes dun service . . . . . . . . . . . . . . . . . . 5.3.3 Le suivi des services . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 Pour une description formelle explicite du contrat de service . . . . . . . 5.4.1 Bilan des contraintes et des bnfices . . . . . . . . . . . . . . . . . . Chapitre 6 Lmergence dune plate-forme SOA . . . . . . . . . . . . . . . 6.1 Lmergence du concept de Bus de Messages . . . . . . . . . . . . . . . . 6.1.1 6.1.2 6.1.3 6.1.4 6.2.1 6.2.2 6.2.3 6.2.4 Bus de messages et contrats formaliss . . Bus de Messages et protocoles sous-jacents Les modes dchange de messages . . . . . Et la scurit ? . . . . . . . . . . . . . . Le contrle et la supervision des services . Rle dun registre de service . . . . . . . . Laccs aux rfrentiels (services CRUD) Gestion et supervision des processus mtiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45 45 46 46 47 49 49 49 50 52 52 53 56 57 58 58 60 60 62 65 66 66 66 68 68 69 70 72 73 74 75 76 77 77
6.3 La chane de fabrication SOA . . . . . . . . . . . . . . . . . . . . . . . 6.3.1 Industrialiser pour mieux livrer . . . . . . . . . . . . . . . . . . . . . 6.3.2 Modliser pour mieux rutiliser . . . . . . . . . . . . . . . . . . . . . 6.3.3 Paramtrer la supervision . . . . . . . . . . . . . . . . . . . . . . . .
XII
7.2 Prsentation du cas dcole 7.2.1 7.2.2 7.2.3 7.2.4 7.2.5 7.2.6
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lentreprise concerne . . . . . Contexte mtier . . . . . . . . Objectifs du projet . . . . . . . Cas dutilisation gnral . . . . Contenu de la solution mtier . Architecture gnrale envisage
Chapitre 8 Modliser les services . . . . . . . . . . . . . . . . . . . . . . . . 8.1 Architecture de services : les questions clef . . . . . . . . . . . . . . . . . 8.1.1 La typologie des services . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.2 La granularit des services . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Modliser les services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.1 8.2.2 8.2.3 8.2.4 tape 1 : les services CRUD . . . . . . . . . . . tape 2 : Les Services Applicatifs . . . . . . . . . tape 3 : Les Services Fonctionnels . . . . . . . . Synthse de la dmarche : modliser larchitecture de . . . . . . . . . . . . . . . services . . . . . . . . . . . . . . . . . . . .
. 93 . 96 . 98 . 100
8.3 Zoom sur les services CRUD . . . . . . . . . . . . . . . . . . . . . . . . . 101 8.3.1 8.3.2 8.3.3 8.3.4 Quelles sont les oprations offertes par un service CRUD ? La signature des oprations CRUD . . . . . . . . . . . . Services CRUD et rfrentiels mtier . . . . . . . . . . . Un service CRUD nest pas un DAO ! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 102 104 107
8.4 Zoom sur les systmes existants . . . . . . . . . . . . . . . . . . . . . . . 108 8.4.1 Intgration dcentralise . . . . . . . . . . . . . . . . . . . . . . . . . 109 8.4.2 Intgration centralise . . . . . . . . . . . . . . . . . . . . . . . . . . 110 8.5 Zoom sur les services de haut niveau . . . . . . . . . . . . . . . . . . . . 111
XIII
Chapitre 9 Modliser les processus . . . . . . . . . . . . . . . . . . . . . . 9.1 Quest-ce quun processus SOA ? . . . . . . . . . . . . . . . . . . . . . . 9.1.1 Bref rappel sur les processus mtier . . . . . . . . . . . . . . . . . . . 9.1.2 Processus Mtier et contexte SOA . . . . . . . . . . . . . . . . . . . 9.2 Modliser les processus : les tapes clefs . . . . . . . . . . . . . . . . . . 9.2.1 Premire tape : lexpression du besoin . . . . . . . . . 9.2.2 Deuxime tape : lanalyse du processus et limpact sur le primtre de la solution mtier . . . . . . . . . . 9.2.3 Troisime tape : la conception dun processus excutable 9.2.4 Conclusion : rsum mthodologique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
115 115 115 116 117 117 119 120 123 123 124 126 128 131 132 133 134 140 144 145 147 147 148 150 151 152 154 156 156 158 159 160 161 162
9.3 Modliser une Architecture BPM dans un cadre SOA . . . . . . . . . . 9.3.1 Comment dterminer lacteur devant intervenir sur un processus ? . . . 9.3.2 Comment un acteur sait-il quil doit intervenir ? . . . . . . . . . . . . 9.4 La solution mtier revisite . . . . . . . . . . . . . . . . . . . . . . . . . Chapitre 10 Modliser les applications composites interactives . . . . . . . 10.1 Le modle MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2 SOA : Le modle MVC revisit . . . . . . . . . . . . . . . . . . . . . . 10.2.1 10.2.2 10.2.3 10.2.4 Le concept de Contexte . . . . . . . . . . . . . . . . . . . . Concept de transaction longue SOA . . . . . . . . . . . . . Architecture du coordinateur dune application composite SOA Et la Vue ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapitre 11 Organiser un projet SOA : dmarche, acteurs, outils . . . . . 11.1 Planifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.1 Utilisation de la dmarche . . . . . . . . . 11.1.2 tablir (ou faire voluer) le plan durbanisme 11.1.3 Spcifier larchitecture SOA . . . . . . . . 11.1.4 Grer le programme SOA . . . . . . . . . 11.1.5 Dvelopper une solution mtier . . . . . . . 11.1.6 Dvelopper un service rutilisable . . . . . . 11.1.7 Adapter un Systme Existant . . . . . . . . 11.1.8 Mettre en place le framework SOA . . . . . 11.1.9 Mettre en place linfrastructure SOA . . . . 11.1.10 Intgrer une solution mtier . . . . . . . . 11.1.11 Intgrer le suivi BAM/SAM . . . . . . . . 11.1.12 Intgrer le Systme dInformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
XIV
11.2 Organiser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 11.2.1 11.2.2 11.2.3 11.2.4 Acteurs . . . . Responsabilits . Coordination . Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 163 164 164
11.3 Outiller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 11.3.1 Le framework SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 11.3.2 Les outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 11.3.3 Outils et productivit : SOA et MDA . . . . . . . . . . . . . . . . . . 166 11.4 Industrialiser : vers un modle de maturit SOA . . . . . . . . . . . . . . 169 11.4.1 Les modles de maturit . . . . . . . . . . . . . . . . . . . . . . . . . 169 11.4.2 Le modle PSAUMM . . . . . . . . . . . . . . . . . . . . . . . . . . 171 11.4.3 Les capacits du modle . . . . . . . . . . . . . . . . . . . . . . . . . 172
12.2 Dfinir un contrat de service avec WSDL . . . . . . . . . . . . . . . . . 186 12.2.1 Fonctionnement de WSDL . . . . . . . . . . . . . . . . . . . . . . . 186 12.2.2 Les limites de WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . 189 12.3 Dcouvrir des services avec le registre UDDI . . . . . . . . . . . . . . . . 190 12.3.1 Principes de UDDI . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 12.3.2 Aspects techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 12.3.3 Les limites de UDDI . . . . . . . . . . . . . . . . . . . . . . . . . . 191 Chapitre 13 Les rponses aux exigences techniques . . . . . . . . . . . . . 195 13.1 Grer la scurit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 13.1.1 La scurit dans le cadre des Web Services . . . . . . . . . . . . . . . 196 13.1.2 Le framework WS-Security . . . . . . . . . . . . . . . . . . . . . . . 197
XV
13.1.3 Les spcifications de scurit moins abouties . . . . . . . . . . . . . . . 13.1.4 Les spcifications pour la fdration didentit . . . . . . . . . . . . . . 13.2 Grer la garantie dacheminement . . . . . . . . . . . . . . . . . . . . . 13.2.1 Les spcifications disponibles . . . . . . . . . . . . . . . . . . . . . . 13.3 Grer les transactions distribues . . . . . . . . . . . . . . . . . . . . . . 13.3.1 Les spcifications disponibles . . . . . . . . . . . . . . . . . . . . . . 13.3.2 Synthse sur les transactions distribues . . . . . . . . . . . . . . . . . 13.4 Superviser les services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.4.1 WS-DM (OASIS) . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.4.2 WS-Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapitre 14 La composition de services . . . . . . . . . . . . . . . . . . . . 14.1 Agrger les services au sein dune interface . . . . . . . . . . . . . . . . 14.1.1 WSRP (OASIS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.2 Coordonner les services . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.2.1 WS-BPEL (OASIS) . . . . . . . . . . . . . . . . . . . . . . . . . . 14.2.2 WS-CAF (OASIS) . . . . . . . . . . . . . . . . . . . . . . . . . . 14.2.3 SCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
199 202 204 204 206 206 207 207 207 208 211 212 212 213 213 216 217
XVI
16.2 WSDL et interoprabilit . . . . . . . . . . . . . . . . . . . . . . . . . . 231 16.1.1 Une raction rapide au dmarrage rat des WebServices . . . . . . . . . 231 16.1.2 Une norme dinteroprabilit de premier niveau : WS-I Basic Profile . . 231 16.3 Dmystifier lutilisation de WSDL : le style utiliser . . . . . . . . . . . . 232 16.3.1 16.3.2 16.3.3 16.3.4 16.3.5 RPC ou Document . . . . . Litteral ou Encoded . . . . . Conformit avec WS-I . . . Comparaison des styles . . . Bilan de lutilisation des Styles . . . . . . . . . . . . . . . . WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 232 233 233 237
Chapitre 17 Choisir la technologie dimplmentation . . . . . . . . . . . . . 241 17.1 Respecter la granularit des services . . . . . . . . . . . . . . . . . . . . . 241 17.2 Triptyque salutaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 17.3 Standardiser lappel au service . . . . . . . . . . . . . . . . . . . . . . . . 244
XVII
19.3 Recommandations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19.3.1 Hors du tout Web , REST perd de sa pertinence . . . . . . . . . . 19.3.2 Le verbe SOA en opposition aux ressources REST . . . . . . . . . . . 19.4 Comment choisir entre REST et SOAP ? . . . . . . . . . . . . . . . . .
Chapitre 21 Aide au choix . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.1 Introduction lanalyse par grille de critres . . . . . . . . . . . . . . . . 21.2 La grille de critres SOA . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2.1 Les critres gnraux . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2.2 Les critres techniques . . . . . . . . . . . . . . . . . . . . . . . . . Chapitre 22 Tous vers SOA ! . . . . . . . . . . . . . . . . . . . . . . . . . 22.1 Les communauts rivalisant . . . . . . . . . . . . . . . . . . . . . . . . . 22.1.1 22.1.2 22.1.3 22.1.4 Le camp des vendeurs SOA gnralistes . . . . Des spcialistes SOA vendeurs dinfrastructure . La revanche des Solutions Mtiers commerciales Lessor des gnralistes Open Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22.2 Une classification des solutions se dgage . . . . . . . . . . . . . . . . . Annexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Glossaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Le WSDL document literal wrapped au format WSDL 2.0 . . . . . . . . Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PREMIRE PARTIE
1
De lentropie des Systmes dInformation
Objectif
Ce chapitre rappelle brivement lvolution des technologies informatiques et ses consquences en terme dentropie pour le Systme dInformation. Il fait ainsi le constat de la difficult maintenir un SI homogne et rationnel. Il prsente ensuite les volutions des marchs mondialiss, avec comme consquence des exigences croissantes des mtiers vis--vis du SI.
Par consquent, aucune entreprise na fait le choix de la table rase chaque changement de gnration technologique. La conservation de ce biotope htrogne sexplique aussi par les contraintes organisationnelles et financires qui rsulteraient dun tel changement. Ainsi, les directions informatiques ont d faire face des parcs informatiques trs morcels et surtout des applications peu mme de communiquer ou de partager des informations. Comme voqu prcdemment, linformatique simmisce dans tous les mtiers et le PC devient omniprsent sur les bureaux de tous collaborateurs de lentreprise. On parle pour cela dinformatique pervasive : la multiplication des applications devrait donc saccentuer.
Poste utilisateur
Navigateur Web
Interface C/S
Interface C/S
Interface C/S
Interface 3270
Application 1
Application 2
Progiciel 1
Progiciel 2
SGBD
Mainframe
Monde Web
Monde client/serveur
Le constat est donc le suivant : les DSI doivent trouver un moyen dorganiser et de matriser cette htrognit. Ils doivent aussi rationaliser la mise en commun dinformations transverses lentreprise : les fameux rfrentiels.
Lentreprise sappuie donc sur le SI pour produire en flux tendu, offrir des produits personnaliss, livrer plus vite, et cela sans augmenter ses effectifs. Par consquent le SI fait face de nouvelles exigences : Il doit offrir de plus en plus de portes dentres aux consommateurs et soustraitants. Il doit supporter des processus de plus en plus automatiss et faisant intervenir une grande varit dacteurs. Il doit offrir une disponibilit toute preuve.
On verra dans la suite que la dmarche SOA propose des solutions pour rpondre cette exigence dintgration des acteurs externes dans les processus mtiers.
En rsum
On a vu que lvolution de linformatique a conduit des SI htrognes et difficiles maintenir. Par ailleurs, la gnralisation de loutil informatique dans les directions mtiers fait que les utilisateurs attendent toujours plus du SI. Il devient donc vital de trouver des moyens de mieux grer et homogniser le SI.
2
Les limites des rponses usuelles
Objectif
Le chapitre prcdent a montr les problmatiques dentropie du SI. Nous allons maintenant prsenter les solutions proposes jusqu ce jour pour tenter sa rationalisation, et en brosser les principales limites.
1. Pour en savoir plus sur la dmarche durbanisation : Le projet durbanisation du systme dinformation, Christophe Longp, Dunod, 2001. 2. Dans la cit physique, un lot est un pt de maison, tandis quen informatique, cest une application obtenue par dveloppement spcifique ou achat de progiciel.
10
essentiellement sur les processus mtiers, la communication inter-applicative et sur la mise en place de rfrentiels transverses. Le travail sur les rfrentiels est une dmarche organisationnelle de longue haleine. Il consiste lister les informations dupliques au sein de lentreprise, puis essayer de les rapprocher sur la base de clefs didentification uniques : numro de commande, numro de produit, identifiant client, etc. Les outils techniques ne jouent pas un rle important dans cette dmarche. Cependant, elle peut sappuyer sur des outils de ddoublonnage des donnes, comme les MDM (cf. partie 7). Par contre des outils sont proposs dans la dmarche durbanisation dans le cadre des changes inter-applicatifs, de lautomatisation des processus mtiers, de lhomognisation des interfaces : ils sont prsents dans la suite de ce chapitre.
11
Les vues processus et fonctionnelles reprsentent les besoins des mtiers : elles sont abstraites. A contrario, les vues applicatives et physiques reprsentent des implmentations bien relles. Toute la difficult de la dmarche durbanisation rside dans lintersection entre une vision abstraite idale et une ralit concrte que doivent intgrer les problmatiques terre terre de maintenance, mise jour, dploiement, intgration avec lexistant, pannes, etc.
Mtier Processus et documents
Mtier
Fonctionnel Fonctions
Technique
En particulier, le risque quencourent les urbanistes est de produire des quantits importantes de documents abstraits qui ne mnent dans la pratique aucune action concrte sur le terrain. Ce travers est comparable celui des architectes qui conoivent des tours dun kilomtre de haut et ne les construisent jamais. De fait, dans des entreprises de taille importante, la dmarche durbanisation a parfois pour seul objectif de connatre lexistant, de disposer dune vue densemble du SI.
On verra dans la suite que SOA offre une solution innovante pour grer linterface entre les besoins des mtiers et limplmentation technique. La dmarche SOA facilite ainsi le travail des urbanistes.
12
2.1.3 La ralit du SI
Comme on la vu dans le chapitre prcdent, le SI doit faire face une grande htrognit technologique. De plus les applications sont gnralement mal quipes pour communiquer avec les autres blocs du SI. On parle pour cela de fonctionnement en silo . Chaque silo est gnralement autonome et isol en terme de processus, dinterface homme/machine, de socle technique. Ainsi la vision par couche des urbanistes se heurte aujourdhui une ralit technique qui entrave leur dmarche globale de rationalisation (cf. figure 2.2).
Il en rsulte de nombreux dsagrments, tels que : Limpossibilit de mettre en place des processus mtier rellement transverses, car ces processus devraient accder des fonctions enfouies dans des technologies diverses. La duplication des objets et des rgles mtier dans les rfrentiels, donc lobligation des doubles saisies, la difficult davoir une vision client unifie, etc. La difficult dvolution des applications due la complexit engendre par la varit des technologies qui rsulte de lhistoire du SI. La difficult profiter des opportunits technologiques. Limpossibilit de rutiliser des composants logiciels. Dans ce contexte les communications inter-applicatives sont souvent gres au cas par cas, par des liens un un en fonction des besoins : cest le fameux syndrome du plat de spaghettis .
13
ERP Connecteur
Mainframe Connecteur
Connecteur
Connecteur
Connecteur
Connecteur
SGBD
Les outils EAI ptissent malheureusement dun certain nombre de dfauts : Lacquisition et le dploiement dun outil EAI sont trs onreux. De plus, ces outils ncessitent un paramtrage long et fastidieux avant les premiers changes de messages entre applications.
14
Les solutions EAI sont propritaires : chacune utilise ses mcanismes propres pour offrir les services prsents prcdemment. Ainsi, le SI devient trs dpendant de lditeur de la solution. Elles ne disposent pas toujours de lexhaustivit des connecteurs ncessaires lentreprise. Tout repose sur loutil EAI : il est ainsi le passage oblig, le bouc missaire et le Single Point of Failure de tous les processus dintgration. Enfin les outils EAI ne rsolvent pas la problmatique du fonctionnement en silo : ils proposent un principe de rectification aprs coup, un systme palliatif (cf. figure 2.4).
On verra dans la suite que, a contrario, la dmarche SOA rsout les problmatiques de fonctionnement en silo de manire proactive.
EAI
15
Tout comme les outils dEAI, les solutions de workflow souffrent de limitations : Elles sont propritaires : chacune utilise ses mcanismes propres pour modliser et dployer les processus mtiers. Ainsi, le SI devient trs dpendant de lditeur de la solution. Elles sont limites en terme dintgration avec des processus supports par dautres applications. Elles sont limites des typologies de processus bien spcifiques : elles ne sont donc pas gnralisables lensemble de lentreprise. Elles ncessitent une adaptation des applications existantes si celles-ci doivent sintgrer au processus mtier. Enfin les outils de workflow sont gnralement utiliss au niveau dun dpartement de lentreprise, donc dun silo : ils ne prennent pas en compte les processus globaux et donc encouragent le fonctionnement en silo (cf. figure 2.5).
Processus transverse ?
Workflow 1
Workflow 2
Workflow 3
16
et dagrger les interfaces Web si celles-ci sont multiples (cf. les grandes entreprises qui comptent jusqu 50 intranets). Les portails de premire gnration proposaient pour cela des batteries de connecteurs capables dintgrer des interfaces dapplication client/serveur, mainframe ou autre. Ces connecteurs permettaient de transformer des interfaces technologiquement htrognes en interfaces Web laide dapplets Java, dActive X ou dopration de revamping 1 (cf. figure 2.6).
Connecteur Web Application Web Connecteur messagerie Messagerie Portail Utilisateur portail connecteur mainframe Mainframe Client SGBD SGBD Connecteur progiciel ERP
Ces outils portails de premire gnration souffraient comme les outils prcdents de dfauts : Ils ncessitaient un paramtrage long et fastidieux. Ils taient propritaires : chacune utilise ses mcanismes propres pour agrger les interfaces. Ainsi, le SI devient trs dpendant de lditeur de la solution. Ils ne disposaient pas toujours de lexhaustivit des connecteurs ncessaires lentreprise. Ils proposaient une interface non personnalisable et ne prenaient pas en compte la diversit des accdants potentiels : collaborateurs, clients, fournisseurs, mais aussi processus B2B automatiss.
1. On dsigne par ce terme les systmes de transformation dinterface lourde en interface Web.
17
Enfin les portails de premire gnration ne rsolvaient pas la problmatique du fonctionnement en silo : au contraire, ils lencourageaient en proposant de contourner le problme par un systme palliatif (cf. figure 2.7).
Figure 2.7 Le portail de premire gnration encourage les silos On verra dans la suite que les portails de dernire gnration utilisent des protocoles standard pour accder aux applications (cf. partie 4), et quils leur imposent une structuration plus volutive, conforme aux vux des urbanistes.
18
En rsum
Les outils dEAI, portail et de Workflow ont propos des solutions parcellaires pour mener bien lurbanisation du SI. Il apparat clairement que, dans le cadre de cette dmarche, lindpendance vis-vis dune technologie ou dun diteur donn est essentielle. On verra dans la suite comment SOA permet cette indpendance.
3
Le cahier des charges du SI
Objectif
Le chapitre prcdent a montr que la dmarche durbanisation telle quelle a t mene jusqu prsent noffrait pas entire satisfaction pour rationaliser le SI. Lobjectif de ce chapitre est maintenant de dfinir : Quelles fonctions devraient offrir un SI pour mieux rpondre aux besoins des mtiers de lentreprise. Quelles fonctions devraient offrir une plate-forme dintgration pour satisfaire les urbanistes.
20
Le Systme dInformation doit donc proposer des outils permettant de modliser puis de dployer les processus dans un temps court et en limitant les dveloppements spcifiques. Ces outils doivent tre plus souples et plus gnralistes que les outils de Workflow. On verra dans la suite que lapproche SOA propose des solutions pour rpondre au besoin de dployer rapidement des processus mtiers.
3.1.2 Les mtiers ont besoin dune vision temps rel sur le business
Pour faire face lacclration des marchs voque prcdemment, les mtiers doivent aujourdhui disposer dindicateurs en temps rel sur lactivit de lentreprise : Ils doivent pouvoir accder aux informations consolides sur un client donn : coordonnes, contrats, commandes en cours, fiches de satisfactions, etc. Ils doivent de mme disposer dindicateurs sur le cycle de vie dun produit donn : commandes en cours, facturation, stocks, capacit dapprovisionnement, etc. Ils doivent enfin disposer dindicateurs sur le comportement et lefficacit des processus mtier automatiss. Pour satisfaire ce type dexigence, le Systme dInformation doit tre capable de donner une visibilit sur les processus et les rfrentiels dentreprise, et ceci quel que soit le point dentre. Il doit pouvoir dcloisonner les applications monolithiques et faciliter la circulation dinformations en son sein. Il doit aussi tre agnostique sur le plan technologique, cest--dire quil ne doit pas rencontrer de point de blocage li une htrognit technologique.On verra dans la suite que la dmarche SOA propose des solutions pour rpondre ce besoin dindicateurs en temps rel.
21
Composer les nouvelles applications On a vu prcdemment que le SI doit proposer des applications rutilisables et capables de sassembler de diverses manires, selon les besoins des mtiers.
La plate-forme dintgration devra donc offrir des mcanismes techniques permettant de composer les applications quelles soient interactives, semi-automatises, ou automatises. Ces aspects seront dtaills dans la partie 2.
Ouvrir les interfaces On a vu dans le chapitre 1 que le SI doit offrir des interfaces pour toutes les typologies dutilisateurs, en particulier les clients et les fournisseurs.
22
La plate-forme dintgration devra donc offrir des mcanismes techniques permettant de mettre disposition des Interfaces Homme-Machine sur la base de la composition dapplications voque dans le paragraphe prcdent. Ces interfaces pourront tre adaptes par les utilisateurs externes au SI selon leur environnement et leur charte graphique. Elles pourront aussi tre accdes par des processus automatiques.
23
La confidentialit : elle consiste empcher la lecture dinformations par des personnes non habilites ou malintentionnes. Lintgrit : elle dsigne la capacit sassurer de la non-altration des informations dorigine, quelle soit accidentelle ou malveillante. La disponibilit : elle concerne la garantie sur le bon fonctionnement dune application, sa rsistance vis--vis des pannes accidentelles et des attaques incapacitantes. La traabilit : elle consiste stocker des traces de toutes les interactions des utilisateurs avec les applications afin de pouvoir dtecter des attaques ou des dysfonctionnements. La disponibilit et la traabilit sont des problmatiques dexploitation : elles relvent des aspects SLA, voqus dans la partie 2 de cet ouvrage. Lauthentification peut tre gre de diverses manires : identifiant/mot de passe, gnrateur de mot de passe usage unique, biomtrie, etc. cependant, la manire la plus lgante dauthentifier un accdant est dutiliser un certificat numrique au format X509. Le certificat est lquivalent dune carte didentit dans le monde numrique : il permet de sauthentifier, mais aussi de signer numriquement des documents. Des certificats sont, par exemple, utiliss dans le cadre de la tl-dclaration des impts sur Internet. La signature lectronique, la confidentialit et lintgrit sont gnralement assures par des algorithmes cryptographiques. On en distingue trois grandes familles : Les algorithmes clef secrte comme triple DES ou AES : ils sont bass sur un secret partag, la valeur de la clef. Les algorithmes clef publique comme RSA ou DSA : ils utilisent des paires des clefs, appeles clef publique et clef prive. Les algorithmes de calcul dempreinte comme MD5 ou SHA1 : ils associent un document une sorte didentifiant unique qui permet de vrifier son intgrit. SSL est, par exemple, un cas classique dusage de ces algorithmes pour assurer la confidentialit des changes.
La plate-forme dintgration doit proposer une rponse aux problmatiques de lencart prcdent. En particulier : Authentifier les accdants au SI, en particulier si ceux-ci sont des personnes externes lentreprise (clients, fournisseurs). Assurer la confidentialit et lintgrit des changes, en particulier si ceux-ci mettent en jeu des tiers externes lentreprise. Assurer la disponibilit des services (cf. exigences du chapitre 2).
24
mais ce contrle est de trs bas niveau : il ne permet pas de notifier un groupe de services quun message est bien arriv ou quune squence de messages est arrive dans le bon ordre. Lusage dun systme de garantie dacheminement est essentiel en architecture distribue, dautant plus quon ne traite pas des changes point point mais des changes entre de nombreux services. Il est particulirement recommand dans le cadre dchanges asynchrones et de gestion de queues de messages, o la perte de contrle sur lacheminement des donnes se rvle assez frquente sans infrastructure ad-hoc.
La plate-forme dintgration devra offrir les garanties prsentes dans lencart prcdent : Notifier quun message est bien arriv. Notifier quune squence de messages est arrive dans le bon ordre.
La plate-forme dintgration devra offrir les garanties prsentes dans lencart prcdent. De plus, lorsque les processus mtiers mettent en uvre de nombreuses tapes intermdiaires avant criture des transactions dans les rfrentiels, on parle de transactions longues (cf. partie 3). La plate-forme dintgration devra aussi savoir grer ces typologies de transactions.
25
versions disponibles des applications et cela en environnement de production, de recette, de dveloppement, etc. Pour assurer lauthentification et la gestion des droits des accdants, la plateforme devra, en outre, disposer dun rfrentiel des utilisateurs internes et externes au SI. De plus, il peut tre ncessaire de dployer un rfrentiel consolid de description des donnes : il sagit notamment dquivalence smantique entre concepts mtier, de tables de rfrences qui pointent vers les rfrentiels dentreprise grce des clefs didentification uniques, etc. Ce rfrentiel permet en particulier de dupliquer des donnes mtiers en conservant une matrise sur leur intgrit. Enfin, au cours de processus mettant en jeu plusieurs applications, il peut tre utile que la plate-forme joue un rle de traducteur. La traduction effectuer par la plate-forme dintgration consistera transposer des messages dune syntaxe donne vers une autre. Elle devra pour cela disposer des dictionnaires propres chaque application, cest--dire dun rfrentiel des grammaires utilises par chacune dentre elles. Le besoin de traduction requiert donc un rfrentiel des dictionnaires de traduction.
Prsentation
Pilotage
Garantie dacheminement
Transactions
Scurit
Rfrentiels
Connectivit
Processus Donnes
Progiciels
Mainframe
Figure 3.1 Lensemble du cahier des charges technique dune plate-forme dintgration
26
La plate-forme dintgration doit tre capable de fournir un reporting aux directions mtiers et la DSI. Il sagit ici de produire des vues et des tats de synthse sur le droulement des processus mtiers sous-tendus par les outils dintgration. La console de suivi doit fournir une grande varit de mcanismes dalertes, et sintgrer aux outils dcisionnels et de reporting, voire directement aux interfaces dutilisateurs externes. Il sagit aussi, terme, dtre capable dajuster les ressources selon la demande, de consolider lexprience acquise par des pratiques de rsolution dincidents. En complment, il est ncessaire dassurer un suivi technique des changes. Ce suivi bas niveau permet de remonter des alertes aux quipes dexploitation sur des dysfonctionnements techniques. Ces dernires seront intgres dans des outils classiques de monitoring.
En rsum
Ce chapitre rcapitule les exigences des mtiers et de la DSI vis--vis dun SI agile. Les mtiers expriment aujourdhui leurs exigences en ces termes : Le SI doit tre capable de sadapter rapidement une fusion ou une rorganisation des quipes. Le SI doit tre capable de fusionner ou faire coexister des socles techniques htrognes. Le SI doit tre capable de dployer rapidement des processus sur la base dun modle fourni par les mtiers. Le SI doit offrir des interfaces pour les clients et les fournisseurs. Le SI doit offrir une disponibilit toute preuve. Le SI doit offrir des indicateurs en temps rel sur lactivit de lentreprise. Le SI doit prenniser ses briques existantes et favoriser la rutilisation. La figure 3.1 rcapitule les exigences techniques. On verra dans les parties 2 et 3, que SOA apporte des rponses mthodologiques et architecturales lensemble de ces exigences. Par ailleurs, la partie 4 prsentera en dtail, dans le cadre des Web Services, les technologies qui rpondent aux exigences techniques. Enfin, les parties 5 7 proposeront une vision concrte, technique et industrielle, de SOA.
SECONDE PARTIE
4
Urbanisation et architecture SOA
Objectif
Le sujet SOA est trs vaste et ncessite de dfinir prcisment de quoi on parle ! En effet, ainsi quen tmoigne une consultation rapide sur Internet, de nombreuses dfinitions sont proposes, depuis celles proposes par lencyclopdie WikiPediaa jusqu celles des groupes de normalisation ddis de lOASISb. Toutes ces dfinitions cherchent tablir un modle de rfrence standard permettant une comprhension commune des lments cls se rattachant SOA. Lobjectif premier de ce chapitre est de proposer une dfinition synthtique et claire des notions caches derrire les trois lettres SOA . partir dun modle darchitecture, il prsente les concepts clefs tels que le concept de services et le concept de composition de service, en mettant en vidence la relation qui doit stablir entre les clients des services et les fournisseurs de ces services. Le chapitre introduit ensuite le concept dapplication composite, en sattachant aux diffrences par rapport aux applications traditionnelles. Une dernire partie se consacre dmystifier certaines ides prconues sur ce quest ou nest pas une Architecture Oriente Service.
a. Wikipedia consultable sur http://www.wikipedia.org. b. OASIS Organization for the Advancement of Structured Information Standards. Les membres du comit ddi et le modle de rfrence SOA amorc ds 2005 sont mentionns sur http://www.oasis-open.org/.
30
Le regroupement de fonctions doit avoir un sens sur le plan mtier : le consommateur du service na pas se proccuper de la faon dont ces fonctions sont implmentes et a fortiori des technologies sous-jacentes. Le terme de service est introduit par analogie avec le monde rel : lorsquil utilise un service de distribution de billets de banque via un distributeur automatique de billets, le consommateur de ce service na pas connatre le fonctionnement technique du distributeur et encore moins le dtail de ses connexions avec les serveurs des diffrentes banques impliques. Cette simplicit, lie un effort de standardisation du dialogue homme-machine, permet nimporte quel consommateur de (r)utiliser le service avec un minimum deffort cognitif. Un service vise donc tre simple demploi et rutilisable. Par exemple, un service de calcul de montant dune commande permet un utilisateur de ce service dobtenir un montant toutes taxes comprises. Ce calcul peut faire appel un moteur de tarification et un calculateur de taxe, mais lutilisateur na pas sen proccuper sauf ventuellement pour prciser lunit montaire
31
utiliser. De mme, lutilisateur na pas ou plus savoir que le moteur de tarification doit rcuprer des informations du catalogue produit (tarif de base et promotions en vigueur), et accder au progiciel de gestion de contrats clients (pour rcuprer les avantages tarifaires consentis au client).1
Consommateur
Mtier
Internet
Pourvoyeur
Services Mtier
Fournisseur
Technique
Figure 4.1 SOA, une liaison entre vue mtier et vue informatique1
Lessor dInternet permet galement denvisager daccder des services offerts par le SI dune autre entreprise. Rciproquement, il est envisageable douvrir ses propres services au monde extrieur de faon contrle (accs extranet) ou non (accs internet). Un service doit donc tre interoprable via Internet au moins pour certains dentre eux. Pour faciliter la rutilisation et linteroprabilit, tout service SOA devra fournir le rsultat de ses traitements sous une forme normalise, cest--dire comprhensible par tous. Un service SOA dialogue avec ses consommateurs sous une forme standardise, tant sur le plan technique que sur le plan mtier.
1. Les relations dtailles entre les diffrentes vues darchitectures rpondent des rgles de cohrence 2 2. Elles ne sont pas illustres par la figure pour viter dalourdir le schma.
32
La standardisation technique passe par lutilisation dun vocabulaire spcifiant les formats et la structure des donnes changes. Le meta-langage XML simpose souvent pour ce faire, mme si lon peut tout fait utiliser SOA sans XML (cf. syntaxe .NET, Java, etc.). La standardisation mtier passe en revanche obligatoirement par la promulgation dun langage dcrivant la smantique des donnes changes. Certaines grammaires XML (RDF, OWL) vont aussi dans ce sens, mme si dautres conventions sont possibles. Il devient ainsi progressivement possible de sortir du fameux paradigme du plat de spaghettis pour passer, au cas par cas, au plat de lasagnes , en couche.
33
Ce modle a donn lieu, initialement, la mise en place des fameux outils EAI (sur la base de MOM1 vnementiel). Le problme est quen ne touchant pas aux applications elles-mmes, lEAI suppose que ces applications sont capables de recevoir un vnement mtier entrant, de le traiter, et de renvoyer si besoin un vnement mtier vers dautres applications. Autrement dit, elle suppose que le processus de traitement de lvnement mtier est pris en compte implicitement dans chaque application concerne. Cette hypothse est le plus souvent fausse : EDA ne permet donc pas une relle automatisation des processus mtiers. Do lmergence du modle POA.
POA (Process Oriented Architecture) est un modle darchitecture posant comme principe fondateur que toute application du SI doit tre modlise comme un processus, et comme consquence la ncessit de mettre en place un moteur (de type workflow) pour automatiser ces processus.
Le point de dpart de POA est important : en considrant que toute application du SI traite en ralit un vnement mtier, ce modle recentre les efforts de modlisation sur lobjectif prioritaire du SI, savoir la capture, le traitement et lhistorique des vnements mtiers. Le problme principal est que ce modle ne se proccupe pas vraiment de la faon dinterfacer les processus mtiers avec les applications existantes. Do lavantage de lapproche SOA. On peut cependant considrer que lvolution certes rcente de SOA conduit intgrer la problmatique POA dans le modle SOA. Autrement dit, le modle SOA propose non seulement une vision service de larchitecture du SI, mais galement une vision processus (cf. chapitre 9). On peut galement considrer que SOA constitue laboutissement de la dmarche EDA, en prenant en compte les aspects propagation dvnement et synchronisation des rfrentiels .
1. MOM Middleware Orient Messages.
34
Service
Service
Service
Client
Catalogue produit
Stock
35
Service
Commande
Service
Service
Service
Client
Catalogue produit
Stock
Cet exemple met en lumire un principe trs important de lapproche SOA : Lapproche SOA favorise la construction de nouveaux services par composition de services existants.
36
La composition de services ne sarrte pas non plus aux frontires du SI. Admettons, par exemple, que lon souhaite complter le service Gestion de commande pour permettre un utilisateur de demander au service, lors de la prise de commande, le calcul de la date et de lheure de livraison. On veut galement lui permettre de demander, lorsque la commande a t prise, dinterroger le service pour savoir o en est la livraison. La solution au sens SOA, illustre par la figure 4.4, sera de recourir un service offert par le SI du transporteur choisi, le service gestion des livraisons . Le service commande fera appel ce service, dabord pour obtenir une date prvisionnelle de livraison, ensuite pour connatre lavancement de cette livraison. On remarquera au passage que ce concept de service peut avoir une traduction au niveau financier, puisque laccs ce service logistique peut dans certains cas tre payant (cf. concept de SLA dtaill au chapitre suivant). Cest un exemple concret du rapprochement informatique mtier favoris par SOA.
Service
Commande
Service Client
Service Stock
Service
Logistique livraison
Cet exemple met en vidence quelques points clefs dans la dmarche didentification des services : limportance pour le service composite dexposer son tour une interface via un contrat; limportance du concept de granularit (composition de compositions);
37
le besoin du maintien dun contexte entre les services (cf. le paragraphe La ncessit du contexte de composition introduit dans le chapitre suivant) : ici par exemple, les lignes de commande; lintrt dutiliser un rfrentiel des services homologus pour pouvoir choisir entre diffrents services logistiques de livraison; le type de composition choisir pour organiser la squence dinvocations de service (orchestration automatise versus enchanement humain de tches).
38
Distinguer contrat versus implmentation dune part, et implmentation directe du traitement versus aiguillage , a bien entendu pour avantage dterminant de pouvoir faire voluer le SI par tape : dans une premire tape, le service dlgue un traitement un existant, dans une deuxime tape le service rcupre sa charge le traitement pour de multiples raisons (performances, cot de maintenance de lexistant, volont de mettre en place un moteur de rgles de gestion externalisant les rgles de calcul, etc.). Si le service continue respecter le mme contrat entre les deux tapes, les clients du service nauront pas tre modifis.
39
che SOA, cest--dire construites en composant des appels de services. Remarquons bien que lapproche Service ne peut apporter sa valeur ajoute aux utilisateurs finaux que via ces applications composites. Une architecture de rfrence se dessine donc peu peu pour toute architecture oriente service.
Applications Composites Applications Interactives Application Interactive Front Office Application Interactive Back Office
Processus Mtier
Batchs
Service
Service
Service
Service
Un service peut donc tre consomm soit par : un utilisateur, via une application composite interactive, un systme traditionnel (applicatif non SOA : batch ou autre application), un processus mtier, un autre service SOA.
40
technique, scuritaires (par exemple, ticket dauthentification, etc.) ou transactionnels (par exemple : date de dbut dune transaction, etc.). Cependant tous les services nont pas forcment besoin dun contexte transactionnel. Ceci est dautant plus vrai si la ressource du SI encapsule par le service nest pas elle-mme transactionnelle (e.g : un serveur de fichiers). Ds lors, un service ou une composition de service doivent expliciter leur mode de prise en compte du contexte : Service sans contexte : Lchange contient lintgralit des informations requises par le pourvoyeur. Service avec contexte : Le contexte est pass par valeur ou par variable durant les changes entre le consommateur et le pourvoyeur. Ceci oblige le service connatre plus de chose sur le client et pourra donc influencer lvolutivit, la performance, et la rutilisation du service. Lapproche SOA implique de grer le concept de contexte. Le contexte nest pas uniquement transactionnel, mais aussi mtier. Il est important de noter que le Contexte est fourni au service par son consommateur : le service na pas mmoriser (stocker) ce contexte. Tout service doit tre sans tat. Cette problmatique est lie au concept de transaction longue. Ces lments sont dtaills au chapitre 10, ddi la modlisation des applications composites.
Applications Composites
Processus Mtier
41
On verra au chapitre 9 que cette diffrence est dans la ralit beaucoup moins tranche. Les fournisseurs de solutions distinguent traditionnellement lorchestration de processus , pour dsigner une coordination nintervenant quau niveau de services mtiers, de lorchestration de services dsignant un processus dintgration technique avec une ou plusieurs sources back-ends y compris des workflows applicatifs invoquant des services techniques daccs bas niveau ou natif certaines ressources (mainframe, systme de messagerie, etc.).
42
Traiter rejet
Commande
Vrifier commande
Vrifier engagement
Facture
Mettre en paiement
Zoom sur lordonnancement de services Un batch peut lui aussi rutiliser des services (e.g : le calcul de facturation dun contrat dassurance lors de sa tacite reconduction est en gnral effectu en batch). Le point clef est alors classiquement les performances de ces services. Il peut tre ncessaire damnager le contrat de services pour prendre en compte ce type dutilisation du service.
43
vice. Lapplication composite transmet ses vues sous un format standardis (cf. WSRP1 dcrit dans la partie 4). Le portail distant va alors agrger diffrentes vues, fournies par ses propres applications locales et par lapplication composite distante.
Browser Rseau
Rseau
Application Composite
Application Composite
Rseau
Application Composite
Rseau
Services
Services
Services
44
Stratgie pilote par les cots : des cots de maintenance trop levs, la surmultiplication de licences, etc., peuvent imposer une refonte profonde de certains silos du SI. Ltude des besoins mtiers fait ressortir trois axes fondamentaux : La mise en place de processus mtiers rationaliss et automatiss (e-Business) : ce besoin est li lessor dInternet comme canal de communication entre entreprises permettant une intgration en quasi zro dlai de leurs SI respectifs. Ce besoin est certainement lincitation la plus forte actuellement pour entamer une dmarche SOA, car elle prsente un retour sur investissement potentiel attrayant pour les matrises douvrage. La capitalisation des informations notamment pour faire merger la fameuse vision client unifie dans loptique client/fournisseur : ceci peut ncessiter dagrger et de mettre en correspondance des donnes disparates. La suppression des multiples saisies manuelles afin de garantir la synchronisation des informations dupliques, en dfinissant un seul matre pour chaque information duplique (afin de supprimer les multiples saisies manuelles).
45
la complexit des mtiers, en prenant en compte des variantes spcifiques, des rglementations particulires, etc. Lintgrit des biens informatiques : Son but est de maintenir des rfrentiels ou chaque fonction na plus quune et une seule place de rfrence dans le SI, tout en assurant la prservation, la fois en interne et en externe, des donnes, des changes et des systmes.
46
Lapproche SOA dfendue dans ce livre souhaite donc avant tout fournir des lments pour satisfaire cette ambition mtier : do limportance des aspects modlisation de larchitecture (partie 3), la ncessit de faire la part de lutile et du futuriste dans le catalogue de normes disponibles (partie 4), lutilit davoir un premier retour dexprience sur la technique sous-jacente (partie 5), et enfin la ncessit de se doter de critres de comparaison dune offre dsormais plthorique (partie 7).
SOA est utilisable quil sagisse de technologies JEE, .NET, ou autres, via des implmentations propritaires ou Open Source, etc. Ce modle darchitecture dlgue en outre une plate-forme transversale linfrastructure dintgration.
SOA ne signifie pas Web Services. lintrieur des frontires du SI, SOA peut se raliser sans Web Services, sans mme dailleurs utiliser le Web ou les technologies du Web. Web services ne signifie pas SOA. linverse, il est aussi erron de croire quen exposant des Web Services, tous les concepts SOA seront respects (cf. la prsentation de REST dans la partie 4). SOA noblige en rien au synchrone. Au contraire lintgration asynchrone de services est tout autant possible voire recommandable pour pallier des pics de monte en charge o la fiabilit pourrait se retrouver compromise en utilisation synchrone. (e.g. : Lappel synchrone de deux services respectivement disponibles 99 %, fournit un service qui ne sera plus disponible qu 99 x 99 = 98,01 %). SOA nest pas de lorient objet avec un peu plus de marketing. La diffrence fondamentale est que lapproche Objet a souvent t dans le pass synonyme de big bang et a de ce fait dcourag les bonnes volonts malgr les promesses (relles) de rutilisation. Lapproche SOA est de ce fait plus pragmatique.
Lapproche oriente objet et lapproche oriente services sont cependant trs complmentaires, lune comme modle darchitecture lautre comme technologie efficace dimplmentation de ce modle pour les nouvelles applications et services.
47
Une hirondelle ne fait pas le printemps, et la mise en place dun outil ne fait pas merger spontanment les services et encore moins les processus mtiers.
SOA nest pas une solution miracle : SOA nest pas une solution cl en main, ni un dogme gnrique universellement applicable. Elle ncessite un effort en continu, hors de tout effet de mode.
Une architecture par construction se doit dtre toujours adapte aux besoins de chaque entreprise (existant, schma directeur, budget, planning, maturit des quipes, etc.). De ce point de vue, lmergence de la couche de services ncessite un travail en continu, pour identifier les services valeur ajoute , vrifier que les services rpondent aux besoins qui mergent, et rciproquement que les besoins mergeant ciblent bien les services existants. Il sagit galement dun effort global au niveau du SI ou tout au moins dun silo important du SI. La dmarche SOA reste donc inopportune pour les applications embarques fortes contraintes techniques ou les petites applications dpartementales. Le niveau minimal de besoin est typiquement lmergence de services mtiers pour la cration, la consultation, ou la modification sur des entits mtiers (e.g : le client, la facture, le fournisseur, etc.) ou des services techniques (e.g : les traces, les notifications, les impressions, etc.) (cf. chapitre 8).
Ces lments pourront nanmoins dsormais tre traits en procdant silos aprs silos, sans impact pour les applications consommatrices ds lors que celles-ci feront rfrences des descriptions stables de contrats de services (cf. chapitre 5).
SOA ncessite un langage mtier commun.
Les avantages de la contractualisation ayant t couverts prcdemment, il reste important de souligner nanmoins la difficult au sein dune entreprise et a fortiori pour une ou plusieurs entreprises, de se mettre techniquement daccord sur un langage mtier commun, ou langage pivot , pour faciliter lchange de donnes valide dans le temps et pertinent en terme dusage (exactitude et prcision par rapport au besoin).
48
Au-del du principe gnral de lutilisation dun tel langage pivot, lensemble de cet enrichissement smantique se traduit par lajout de mta-donnes exprimes le plus souvent dans une grammaire XML au moyen de balises plus ou moins normalises avec leurs valeurs associes. Il doit par ailleurs conserver un caractre extensible, permettant daccueillir une communaut grandissante de consommateurs.
SOA est une affaire de compromis.
Sur la centralisation des services versus le clonage de ces services : lavantage de la ractivit li lunicit des services un niveau global, doit tre confront la performance quautorise localement la redondance des donnes et des traitements. Sur un langage pivot gnralis lensemble de lentreprise versus des langages locaux : adopter un langage pivot dans lchange permet de limiter les risques dincomprhension entre consommateurs et pourvoyeurs de service. Pouvoir tendre, ou particulariser les changes au gr des changements requis, vite que le consommateur et le pourvoyeur se retrouvent bloqus par une version spcifique de service (cf. chapitre 5 sur la notion de message et de gestion de variantes). Sur louverture du SI versus la scurit : louverture du SI, notamment au moyen des services Web, possde une contre partie en matire de scurit. niveau de scurit constant, les surcots dinvestissement (DMZ, Firewall, VPN, etc.) et dexploitation induits par louverture du SI ne sont pas ngligeables.
SOA ne rsout pas la gestion des performances en production : lide du service unique et rutilisable reprise dans un contexte dexcution synchrone exacerbe les problmatiques de disponibilit et de capacit monter en charge diffrents services.
En rsum
SOA se traduit dans larchitecture, par une vue ddie la convergence et lunification du SI : la vue des Services. Un service est contractualis entre un consommateur et un pourvoyeur. La composition de service permet denvisager tout type de flux dinteraction avec les services en respectant les principes lis la notion de service. Vu de lutilisateur final, la valeur ajoute des services se peroit au travers dapplications composites, dont il convient de comprendre la typologie et de spcifier la topologie de dploiement. SOA se met en place au travers dune dmarche fixant un point dquilibre conciliant plusieurs compromis la fois, dont principalement le retour sur investissement attendu, les cots et dlais, la performance et bien sr la flexibilit.
5
Au cur de SOA : le concept dorientation service
Objectif
Ce chapitre approfondit le concept de service, pierre angulaire de la dmarche SOA. Tout sorganise autour du contrat de service, indissociable du concept de service, et en dtaille progressivement les lments constituants. Ce faisant, le chapitre parcourt le cycle de vie dun service, depuis son identification jusqu son dploiement. Dans ce parcours du cycle de vie, le chapitre ne prsente que les points spcifiques de la dmarche SOA par rapport au cycle de vie classique dun composant logiciel.
50
Pour demander un service, le consommateur met une requte vers le pourvoyeur. Celui-ci renvoie (en gnral) une rponse. chaque couple (requte, rponse) correspond une opration effectue par le service : lopration est excute par le service sur rception de la requte associe et est charge de renvoyer la rponse. Le contrat spcifie donc la liste des oprations offertes par le service et, pour chaque opration la requte et la rponse.
Interface
Implmentation
Contrat
Linterface ne dtaille pas comment les oprations sont implmentes : il masque au consommateur comment lexcutant travaille, cest--dire comment il est implment, et avec quelle technologie. Le contrat peut-tre formalis dans nimporte quel langage respectant un standard, interne lentreprise ou partag en respectant un standard bas sur XML (cf. WSDL dcrit en partie 4). Sans ce contrat, lmetteur et le receveur de requtes dinvocations devraient prsupposer quils utilisent, par exemple, le mme langage informatique ou du moins des technologies compatibles par nature, et quils sont dans des conditions prtablies de bonne communication pour changer. Or, pour deux applications prises au hasard dans la cartographie dun SI, et plus forte raison entre SI, force est de reconnatre quau final ces deux postulats ne se vrifient spontanment quexceptionnellement. Remarque : lorientation Service peut donc sappliquer des fonctions lies des concepts mtiers (par exemple, calculer le montant dune commande) aussi bien qu des concepts techniques (par exemple : enregistrer des traces).
51
Le message est transport sur le rseau via un protocole de communication formalisant et organisant les changes sur le rseau. En retour, et lorsque cela sera ncessaire, le client recevra un autre message, qui sera galement transport via le mme protocole ou un autre protocole de communication.
Client
1 Requte
2 Rponse Opration 2
Interface
Cela traduit une volont de faible couplage entre le pourvoyeur de service et le consommateur de service. Le pourvoyeur est, de ce fait, libre damliorer ou de changer volont limplmentation du service pourvu quil respecte son contrat dengagements initiaux avec chaque consommateur. Le faible couplage permet donc au pourvoyeur, ds lors quil ne touche pas au contrat, de matriser : une plus grande diversit de consommateurs (tous les cas de dialogues tant explicitement dcrits dans le contrat); la garantie de la qualit de son service (respect des conditions dutilisations, suivi de lutilisation, etc.); les modifications de limplmentation de son service (par exemple pour suivre les rglementations, optimiser la performance, etc.). Le faible couplage permet par ailleurs au consommateur : une facilit de dveloppement (pas besoin de connatre limplmentation); une fiabilit de transaction (le contrat est explicite, il ny a donc pas de surprise) ; un changement possible de fournisseur (en cas de non satisfaction), si le fournisseur alternatif accepte de respecter le mme contrat.
52
Indpendant de la technologie
Dpendant de la technologie
53
Interface
Contrat
Directives demploi
Satisfaire les exigences (ou attentes) du consommateur implique dassocier chaque garantie une mesure permettant de vrifier que les capacits attendues sont bien mises disposition par le pourvoyeur. Rciproquement, satisfaire les directives imposes par le pourvoyeur implique dassocier chaque directive une faon de vrifier le respect de cette directive. Le contrat tendu par les garanties et directives dfinit ainsi le service rendu par le pourvoyeur, tant sur le plan mtier, que sur le plan dune qualit mesurable. Ds lors, le consommateur se rfrera ce descriptif complet pour choisir et utiliser le service en pleine connaissance du rsultat en attendre.
54
Concept de SLA Ce contrat tendu peut aller jusqu couvrir les obligations dun vritable SLA1 rsultant dune ngociation entre le consommateur et le pourvoyeur. Pour mettre en uvre ce SLA, un contrat dutilisation rpertoriant les conditions particulires admises pour un consommateur donn devra en gnral venir complter le contrat de qualit de service ainsi que le contrat de base, vus prcdemment.
Ce contrat dutilisation pourra dfinir par exemple : lidentification du consommateur ou dune famille ou regroupement de consommateurs ; le nombre de transactions consommables dans une plage de temps; les plages dexclusivit ventuelles; les cas ou nombre derreurs acceptables; le respect de dbit ou temps de rponses; etc. Un accord de SLA est ncessaire ds lors que pourvoyeur et consommateur(s) du service nappartiennent pas la mme entreprise voire la mme entit dentreprise en cas de refacturation interne. Cependant, la question se pose tout autant au sein de trs grands comptes souhaitant travailler en mode de refacturation interne.
Interface
Contrat
Directives demploi
La ngociation du SLA portera sur : Laspect mtier : la Dure de mise disposition du service donc de la validit du SLA ( ne pas confondre avec la sous-dure daccessibilit du service);
1. Issu de la terminologie anglo-saxonne Service Level Agreement (SLA) , utilise notamment par les oprateurs de rseau, les socits doutsourcing, etc.
55
les garanties de performances (temps de rponses et nombre daccs simultans); les garanties de disponibilit incluant le mode de calcul de sa mesure; les garanties de scurit : un client du service veut tre sr que le pourvoyeur limitera laccs du service certains profils de salaris de ce client. Laspect support technique : le mode de surveillance et dalerte en cas de problme : ce mode pourra tre priodique ou permanent, en prcisant les points de mesures accessibles au consommateur; le mode de rsolution de problmes lors de la remonte de dfauts concernant la dlivrance du service conformment au SLA ainsi que les temps de prise en compte, les ventuels outils ou infrastructure et moyens disponibles pour la gestion de tickets. Laspect financier comprenant : le cot dun appel de service pour le consommateur en regard des ressources et garanties proposes; le cot dun dfaut de qualit pay en compensation par le pourvoyeur du nonrespect de laccord (en particulier pour indisponibilit ou non-performance).
Comment sassocient contrat, SLA et service ? Les liens entre contrat, SLA et implmentation dun service ne sont pas bijectifs, comme lillustre la figure 5.6.
SLA#1
SLA#2
SLA#3
Contrat #2
Contrat #1
Interface #1
Implmentation#1 (bouchon)
Figure 5.6 Les liens entre contrat, SLA et implmentation dun service
Un mme contrat de service peut tre associ plusieurs implmentations. Un premier exemple typique concerne les services dinformations. Une premire implmentation sera prvue pour un accs public et un niveau de SLA gratuit, et une seconde implmentation sera plus riche pour un accs, cette fois, authentifi et un niveau de SLA payant.
56
Un autre exemple est dassocier systmatiquement chaque service une implmentation bouchon permettant aux consommateurs de tester sans attendre limplmentation complte de ce service. Ceci constitue dailleurs une bonne pratique SOA. Un mme contrat de service peut tre associ plusieurs SLA. Par exemple, certains consommateurs de services bancaires sont prts payer plus cher pour obtenir des informations boursires en temps rel, alors que dautres se contenteront dune fourniture priodique, toutes les heures par exemple. Autre exemple, un premier SLA pourra concerner des utilisateurs externes lentreprise, et un autre SLA concerner une filiale de cette entreprise. La diffrence pourra porter sur les conditions de facturation, les contraintes scuritaires, etc. Un SLA peut concerner simultanment plusieurs (contrats de) services. Il sagit dans ce cas dviter de multiplier les SLA, potentiellement longs ngocier. Une mme implmentation de service peut (parfois) servir plusieurs contrats. Peut-il enfin y avoir plusieurs contrats sur une mme et unique implmentation de service ? Oui, si le pourvoyeur souhaite masquer certaines possibilits dutilisation certains consommateurs mais cest un cas de figure plus rare, car il vaut peuttre mieux proposer plusieurs oprations dans le mme contrat, certaines oprations tant rserves certains profils de consommateur.
57
du contrat de base afin de garder une flexibilit de recomposition et donc de matriser la coordination (cf. le chapitre 14 de la partie 4).
Capacit Transporter
Consommateur
Pourvoyeur expose
Chorgraphie
1) Rception Demande 2) Fourniture offre 3) Rception Slection 4) Envoi confirmation
Interface
Orches.
dfini But
Capacit Voyagiste
Compagnie Arienne
Chorgraphie
Capacit exige Rsa. Avion + Hotel Interface exige 1) 2) 3) Envoi Demande Slection Offre Rception confirmation
Interface
1) Rception Demande 2) Fourniture offre 3) Rception Slection 4) Envoi confirmation Rsa. Voyage
Chorgraphie
1) Rception Demande 2) Fourniture offre 3) Rception Slection 4) Envoi confirmation
Interface
Orches.
Chane Htelire
Interface
58
dautre part les lments de packaging et de dploiement de ces packages de services (en tenant compte des dpendances de composition inter services); et enfin, les indicateurs relatifs la supervision du service.
Lapproche dclarative
Cette technique sapplique pour changer la valeur dun paramtre global. Les paramtres globaux sont dclars dans le contrat de service, plus exactement dans la partie dploiement de ce contrat, via lusage dune simple grammaire XML.
59
Cest lapproche adopte par la norme SCA (cf. partie 4). Cette technique a quelques inconvnients : elle se limite des variantes trs simples : changement de valeur dun paramtre de type simple (string, date, monnaie, etc.); elle se limite aux paramtres dfinis trs tt, ds la phase de modlisation; lajout dynamique de nouveaux paramtres nest pas possible.
Lapproche programmatique
Cette technique sapplique lorsque le service doit utiliser des variantes de certaines rgles mtiers ou des variantes dalgorithme de calcul. Elle prsuppose le recours un langage objet pour implmenter les services. On appliquera les patterns Objets appropris1, en particulier le pattern Stratgie (pour paramtrer dynamiquement le service par un comportement, ou stratgie). On vitera en revanche le recours trop systmatique lhritage, qui peut favoriser des propagations automatiques de comportements non souhaites lors de la dmultiplication des variantes. Cette technique a linconvnient dintroduire subrepticement la ncessit pour un consommateur de connatre les stratgies en question, cest--dire de connatre (une partie de) limplmentation du service, ce qui est contraire SOA.
60
Carte didentit
Nom : Version : Catgorie : Mission : Nature : Mtier Technique Granularit : Applicative Fonctionnel CRUD
Dpendances
Version : Version : : Adresse Adresse : (Entre) : Signature Message requte : : Signature (Sortie) Protocole : Message rponse : Implmentation : Protocole : Structure des informations Structure des informations : : Cas derreurs Cas derreurs : :
SLA(s)
Directives Opration #2 Assertion #1 Utilisation : Scurit Mtier Utilisation : Scurit Mtier Cible : Cible : Contexte / Variante : Contexte / Variante : Pr-Condition : Pr-Condition : Post-Condition : Post-Condition :
Validit : Contact : Niveau de qualit : Niveau interoprabilit : Ressources garanties : Indicateurs : Niveau de suivi : Mode de surveillance : Mode de rsolution : Cots : Condition(s) particulire(s) :
61
Que doit contenir cette fiche descriptive ? Il sagit des lments techniques ncessaires aux diffrents acteurs du SI : urbanistes, consommateur (responsables et dveloppeurs dapplication), pourvoyeurs (responsable du service et responsables de services composant ce service), quipe dadministration du rfrentiel de services, quipe dintgration. Toutes ces informations sont autant de mta-donnes quil faut viter doublier ou denfouir dans limplmentation logicielle des services. Les normes et outils ncessaires ne couvrent pas encore vraiment lintgralit de ces notions (cf. le standard WS-Policy dcrit au chapitre 13 de la section 4), mais cela ne doit pas freiner le dmarrage de la dmarche SOA. Cette fiche descriptive inclut notamment : La carte didentit du service permettant la publication du service et sa recherche dans un rfrentiel : nom du service, mission (en une phrase), classification du service (mtier/technique). Le contrat de service comment. Les directives techniques (scurisation, etc.). Le ou les accords de SLA. La matrice de rutilisation du service, cest--dire lensemble des liens des applications et/ou services consommant ce service, et lensemble des services composs (donc consomms) par ce service. Les paramtres de variantes de dploiement. Lhistorique des versions du service. Dventuelles contraintes dutilisation, listes sous forme de pr-conditions et de post-conditions textuelles conditionnant la consommation du service ce qui est contradictoire avec lexigence dautonomie du service, certes, mais apparat comme utile dans certains cas. partir de lensemble de ces fiches, il est possible dditer diffrents guides de mise en uvre : Un guide dutilisation des services lusage du consommateur, cest--dire une description mode demploi comprenant le contrat tendu voire laccord de SLA lorsque cela est justifi. Un guide de publication et de recherche, cest--dire un ensemble dinformation permettant un tiers de retrouver le service suivant certains critres de classification. Un guide de scurisation dcrivant les rgles que le service adopte pour authentifier et identifier ses consommateurs, ainsi quventuellement les rgles de protection prive (chiffrement, etc.) ou de non rpudiation de sa sollicitation. Un guide de dploiement lusage des quipes dintgration et de production dcrivant le ou les protocoles daccs, limplmentation dployer des services assembls par composition au sein de ce service, etc.
62
Un guide de supervision mtier, destin aux matrises douvrage, cest-dire la prsentation des indicateurs permettant de suivre les SLA. Un guide de supervision technique, destin aux quipes dexploitant, cest-dire la prsentation des indicateurs permettant de suivre la performance technique du service.
63
Le recours des techniques de prise en compte des variantes contribue fiabiliser lusage dun service malgr des contextes divergents de consommation et facilite son dploiement.
En rsum
Le contrat de service ralis par le pourvoyeur exprime un mode dinvocation au travers de messages. Il doit tre tendu par des garanties, selon des directives au profit dun ou plusieurs consommateurs, et rutilisable par composition pour un pourvoyeur de service de plus haut niveau. La richesse de ces concepts lis au service implique un effort certain lors de la spcification des services et des SLA, les normes et outils ntant pas encore complets. Cest pourquoi la mise en place dune fiche type de description de service simpose. Lexpression de niveaux de qualit de services diffrents, contribue la mise en place progressive dun suivi proactif, autorisant un dcouplage jusqu lexploitation. Plusieurs bnfices sont retirer de la formalisation du service.
6
Lmergence dune plate-forme SOA
Objectif
Lchange de messages entre consommateurs et pourvoyeurs de service implique la mise en place dun middleware adapt : le bus de messages. Le premier objectif du chapitre est de prsenter le rle et la place dun tel bus dans le cadre de SOA. Mais le bus lui seul ne suffit pas. Dploiement des services, orchestration de processus, capacit daccder aux systmes existants, suivi de la qualit de service, etc. sont autant de besoins identifis prendre en compte avec SOA. Il conviendra dy rpondre via les outils adquats. Le deuxime objectif du chapitre est de prsenter de faon synthtique lensemble de ces outils et de mettre ainsi en vidence lmergence dune vritable plateforme cohrente dinfrastructure SOA. Enfin, la ncessit dindustrialiser le dveloppement des services dans un cadre productif et selon une mthodologie adapte, conduit au concept de chane de fabrication des services, dont la prsentation constitue le troisime objectif du chapitre. Cette prsentation, synthtique, sera approfondie aux chapitres 20 et 21 de la partie 7, tandis que le chapitre 22 fournira un rapide tour dhorizon de loffre.
66
Consommateur
Interface
Implmentation
67
Consommateur
Vrification Interface
Implmentation
Si lon prend une analogie du monde rel, cela peut se comparer un service postal offrant dacheminer un courrier reu sous forme lectronique, soit comme un courrier papier en recommand, soit comme un fax, soit comme un courrier lectronique scuris. Or pour quun message soit transportable sur une grande varit de protocoles, quils soient bass sur un mode texte (comme HTTP) ou binaire (comme MQ, JMS ou CICS), il doit tre transport dans une enveloppe normalise. Lenveloppe prcise dans un en-tte ladresse du service, une demande daccus de rception, lencodage ou la compression du contenu transport, des informations de scurit, etc. Lindpendance vis--vis des protocoles de transport conduit privilgier lusage naturel dune structuration de lenveloppe et du contenu en XML. Le W3C recommande depuis 2003 SOAP v1.2 comme protocole de messagerie standardis pour les services Web (cf. La section 4, dtaillant notamment les avantages de SOAP par rapport REST). En conclusion, un bus de messages fournit un mcanisme de communication commun aux consommateurs et pourvoyeurs en imposant : Une langue commune : la grammaire ou schma des contrats de base, ventuellement retraduite vers WSDL. Des directives communes (les ordres de messages). Une infrastructure de transport de haut niveau : Il sagit de masquer la varit des protocoles de transport effectivement utiliss en les retraduisant vers un message standardis extensible comme SOAP autrement dit, et pour faire bref, il est possible (i.e. la norme ninterdit pas) de transporter des messages SOAP sur des protocoles aussi divers que HTTP, FTP, SMTP, JMS, etc.
Ceci renforce le principe SOA Web Services. Comme on la vu, lapproche Service ne peut se rduire la seule mise en uvre des protocoles Web Services. SOA est dabord un modle de conception darchitecture, les WS-* ne sont quun moyen de
68
dployer les services sur une infrastructure Web, et sont mettre en balance avec dautres techniques pouvant dans des contextes moins ambitieux dinteroprabilit se rvler plus optimum (cf. Corba, EJB Session, .NET Assembly, etc.).
Ainsi, il sera fondamental de veiller ce que le bus dispose de moyens doptimiser les ventuelles tapes de retraductions internes et noblige pas, par exemple, lorsque consommateur et pourvoyeur sont dans des technologies compatibles, un surcot de performance.
Ainsi par exemple, le consommateur sabonnant un service de presse, souhaite le faire grce une seule requte, lui permettant de disposer en retour de nombreuses rponses (autant que le rclameront les choix aux critres retenus dans son abonnement ou sa slection). Un service peut donc se contenter dune simple invocation entrante, de mme quil peut imposer une rponse pour chaque requte entrante, ou encore sobliger renvoyer une rponse ou une erreur (pour signifier sa non rponse). La varit des interactions bilatrales ou multilatrales entre services est donc prendre en compte par le bus de messages (cf. les caractristiques dcrites au chapitre 18).
6.1.4 Et la scurit ?
Une architecture SOA doit rpondre aux problmatiques de scurit prsente dans la partie 1. Elle doit rpondre en particulier aux questions suivantes : Comment sassurer de lidentit du fournisseur, du pourvoyeur ou du consommateur du Service ? Comment dfinir et exposer les droits daccs un Service ? Comment assurer la confidentialit des changes ? Comment assurer la conservation des messages lors dun change sensible mettant en jeu plusieurs partenaires ? Etc. Dans le cadre dune architecture SOA, la scurit peut tre aborde de manire traditionnelle : En mettant en place une scurit par le rseau (Firewall, DMZ, VPN, etc.). En utilisant une scurit au niveau protocolaire (SSL, IPSEC, etc.). En dployant des systmes dauthentification (LDAP, certificats, etc.). Etc.
69
Cependant, la scurisation des messages changs suivant ces mthodes peut se relever complexe lorsque de nombreux tiers entrent en jeu dans cet change. Ainsi, il peut tre plus intressant de reporter les oprations de chiffrement menes au niveau protocolaire sur les corps des messages eux-mmes. Ce principe est celui de lchange des e-mails scuriss avec S/MIME : ce sont les corps des e-mails qui sont chiffrs et non les protocoles SMTP et POP. Ces aspects sont dtaills dans la partie 4 au chapitre 13.
Application Composite
Application Composite
Portail
Application Composite
Consoles de Suivi
SAM
BAM
Bus de message SOA Registre des services CRUD Accs aux donnes Container de service Administration Plate-forme
CRUD
Service
Service
Rfrentiels existants
70
Lannuaire de service (ou registre1) pour faciliter la localisation des contrats de services. Lorchestrateur2 pour excuter les processus automatiss. Le requteur daccs aux rfrentiels existants3 pour unifier laccs aux donnes. Le moniteur de services et de processus 4 pour utiliser en cohrence des directives dexploitation et unifier la remonte pertinente dindicateurs par profil.
Consommateur
Implmentation
Indicateurs
Alertes
71
aux besoins oprationnels de linformatique interne, mais aussi aux besoins des mtiers internes voire des consommateurs finaux. noter que la console de suivi SAM peut aussi tre unifie avec une console de production dj en place dans lentreprise (par exemple Tivoli, HPOpenView, Patrol ou Microsoft). Ceci tant dautant plus ncessaire si les indicateurs intgrer sparpillent depuis le niveau rseau, jusquaux invocations de messages (voire la disponibilit des personnes humaines ventuellement impliques). La dtermination des bons indicateurs mtiers et techniques est un processus par nature adaptatif et itratif. Par consquent, il est vital de pouvoir positionner ces indicateurs et rgles dune faon la moins intrusive possible dans limplmentation, do le recours des descriptifs explicites plus ou moins extensibles utiliss en pr/post compilation ou mieux en raction des vnements. Diffrents niveaux de suivi sont bien entendu envisageables : Un premier niveau se contente de visualiser les indicateurs daccessibilit, de performance et de disponibilit plus ou moins individualiss sur chaque opration de chaque service. Un second niveau permet dautomatiser le suivi du niveau de qualit de service ngoci, via la dfinition de seuils et dalerte. Un troisime niveau cherche tablir un diagnostic de dysfonctionnement voire corriger en temps rel le dysfonctionnement. Lexpression de directives permet par exemple dexprimer des rgles pour limiter le nombre de demandes au-del dun certain seuil de saturation des ressources alloues lopration dun service. Des rgles permettront au contraire dallouer ou retirer des ressources au fur et mesure des demandes sur un service. Dautres rgles peuvent aussi faciliter ltablissement dun niveau de priorit de prise en compte dun message entrant afin de rguler la charge dune infrastructure dexcution de services. Un point dlicat concerne le lien entre supervision SAM et respect des SLA en ce qui concerne limpact financier du non respect de ces SLA. Le lien entre SAM et systme de facturation reste encore du domaine du futur.
72
passante du rseau, etc.) comme des ressources banalises auxquelles on peut affecter dynamiquement des tches de traitements machine. Dans ce cadre, la possibilit danticipation de la demande dsigne la capacit dexploiter les indicateurs mesurs pour proposer lallocation au Bus de Message de ressources existantes (bande passante par exemple), voire la mise en place de nouvelles ressources.
Consommateur
Interface
Implmentation
Indicateurs
Alertes
Adaptation
Allocation de Ressources
Lintroduction dune infrastructure servant de registre dintermdiation entre pourvoyeurs et consommateurs se rvle donc de plus en plus utile. Ce registre offre les cas dusage suivants : le pourvoyeur publie la description de son service dans le registre (fiche didentit, contrat, SLA, etc.). La fiche didentit contient la catgorisation du service (cest--dire les mots cls qui en faciliteront la recherche);
73
le consommateur recherche un service correspondant son niveau dexigences auprs du registre; le registre transmet au consommateur la ou les descriptions correspondant sa recherche. Le registre peut aussi jouer un rle de zone de publication des implmentations de services valids et faciliter ainsi les dploiements sur plusieurs environnements (pour le dveloppement, le test, la pr-production etc.).
Le registre peut-il sutiliser dans un cadre plus large que celui du SI dune seule entreprise ? Il reste difficile ce jour dutiliser dynamiquement des services auparavant inconnus , notamment sur le plan commercial et juridique. Mais du fait que lentreprise peut par exemple fdrer un rseau de partenaires commerciaux, il peut tre ncessaire douvrir le registre ces partenaires.
Sans verser dans lambition des annuaires plantaires, il nen demeure pas moins intressant douvrir son registre de service au sein dun primtre dlimit, ou bien, mettre en rseau son registre avec ceux de partenaires agrs. (cf. les topologies de registre dcrites dans le chapitre 20 de la partie 7).
74
par la plupart des diteurs, ils facilitent pour chaque branche de lentreprise le partage de la mme dfinition dentits, par exemple le client ou la facture1.
75
serveur CEP. Ceci permet en outre dexploiter automatiquement des tendances. Par exemple, afin de dterminer si une prise de commandes suit un cycle particulier doccurrence et au-del dexploiter nouveau cette information soit en dclenchant un nouveau processus mtiers soit en routant lvnement vers un oprateur humain. Le systme CEP permet, durant lexcution des processus mtiers, de confirmer lapplicabilit des rgles ainsi dfinies, chelle de certains seuils. Il devra alors mettre dautres vnements synthtisant plus haut niveau les vnements unitaires ainsi corrls. La clef rside donc dans le traitement en temps rel de flux dvnements pouvant atteindre plusieurs centaines de milliers par seconde dans le domaine boursier par exemple. Ainsi, il devient possible dassurer un cycle complet, durable et damlioration continue, depuis la modlisation, lexcution, le suivi et jusqu loptimisation des processus.
Application Composite
Application Composite
Application Composite
Portail
Consoles de Suivi
SAM
BAM
Bus de message SOA Registre des services Accs aux donnes CRUD CRUD Service Service Container de service Administration Plate-forme
Rfrentiels existants
76
mais aussi des ateliers de modlisation, dveloppement, paramtrage et dploiement des applications, des services et de linfrastructure. Du modle dinterface de services aux modles de processus, du dveloppement au dploiement, ces ateliers, doivent constituer une vritable chane de fabrication SOA1, pour permettre dappliquer de faon productive une logique mthodologique (cf. chapitre 11 de la partie 3).
77
78
paramtrage peut aussi porter sur les seuils et rgles de mise en escalade ainsi que sur le niveau de dtail restituer (frquence de rafrachissement, verbosit des traces, etc.).
En rsum
Bien que SOA soit avant tout une approche architecturale, il ne saurait tre question de ngliger linfrastructure requise pour le dploiement, lexcution et la supervision des Applications, Processus et Services. On constate larrive de multiples nouveaux outils ncessaire SOA, comme le bus de communication, le registre de services, ou lorchestrateur de processus. Cette infrastructure peut inclure les outils ncessaires pour les administrateurs mtiers, notamment les consoles BAM et SAM. Lutilisation de ces outils BAM est un stade ultime de maturit sur une plateforme SOA, puisquil requiert la fois une modlisation prcise des performances, une gestion des capacits, et la remonte en temps rel des ressources disponibles. Il est dans ce cas souhaitable de commencer par un systme SAM.
TROISIME PARTIE
80
Les services sont les composants de base de lapproche SOA : le chapitre 8 propose une dmarche pour modliser ces composants. Cependant, comme on la vu dans la partie prcdente, SOA ne se rduit pas la mise en place de services. Il est galement ncessaire de modliser les nouvelles applications composites (processus mtier et applications interactives) clientes de ces services. Le chapitre 9 montre tout dabord comment toute architecture SOA doit prendre en compte la dimension processus mtier . Le chapitre 10 dcrit ensuite larchitecture dune application interactive, en revisitant le modle architectural traditionnel de ces applications. Un projet SOA reste un projet informatique : les questions de robustesse et de performance sont des facteurs analyser ds le dpart, et seront donc abordes dans ces chapitres, en se focalisant uniquement sur les spcificits SOA. Une fois la cible dfinie et son architecture modlise, il est possible de proposer une organisation et une dmarche pour raliser et dployer cette cible. Le chapitre 11 propose une rflexion sur ce thme sensible, car il touche la dimension humaine du mtier de linformatique. Cette partie est consacre la modlisation dune architecture SOA lors des phases dexpression de besoin et de spcifications1 dun projet : elle se veut donc indpendante de toute technologie permettant de raliser des services et des applications composites. On espre ainsi convaincre concrtement le lecteur que SOA nest dcidment pas rductible la seule mise en uvre des technologies Web Services.
1. Si lon respecte le cycle de vie dfini par la mthode Unified Process (UP) associe UML, ces phases correspondent aux phases dexpression de besoin, danalyse et de conception gnrale dcrites dans UP.
7
Dfinir la cible
Objectif
Lobjectif de ce chapitre est de prsenter le concept de solution mtier, puis dillustrer ce concept en lappliquant un cas dcole, que le chapitre dcrit, et qui servira de fil rouge pour les parties 3, 4 et 5 de cet ouvrage.
82
7. Dfinir la cible
Or larchitecture de rfrence SOA fait voler en clat cette unit, en distinguant diffrents types de composants : Les services, dpositaires de la logique mtier. Les applications composites , orientes utilisateur final, qui sont clientes des services. Les rfrentiels, sur lesquels sappuient les services.
83
Les rfrentiels accds par les services. Les ressources techniques utilises par les applications composites ou par les services.
Applications Composites Application Interactive Application Interactive Front Office Application Interactive Back Office Processus Mtier
Service
Service
Service
Figure 7.1 Une solution mtier sappuie sur le modle de rfrence SOA
84
7. Dfinir la cible
bien entendu contribuer ces choix communs, mais elle ne doit pas en toute rigueur en tre responsable. De plus, le fait que des services mtier soient rutiliss par diffrentes solutions ou que linfrastructure logicielle soit partage entre ces solutions a bien entendu un impact positif sur le budget prsent aux directions mtier, mais sur le plan des usages et de la finalit mtier, ce nest pas la proccupation premire de ces directions. La proccupation premire dune direction mtier est que ses utilisateurs soient efficaces dans leur mtier, cest--dire quils puissent traiter un vnement mtier de bout en bout, en tant productifs (nombre dvnements traits par heure/jour/ semaine) et ractifs (dure de traitement moyen dun vnement, etc.). De ce fait, toute solution mtier est dabord et avant tout une unit dintgration : le responsable dune solution mtier garantit ses clients (la ou les directions mtier) que lensemble des composants impliqus dans la solution dont il est responsable rponde collectivement (cest--dire de faon intgre) aux besoins exprims. Il offre ainsi une garantie de bonne fin. Cette intgration porte donc sur les diffrents composants illustrs par la figure 7.1.
85
Ces producteurs veulent distribuer leur nergie vers leurs propres clients, via les points de distribution et le rseau grs par loprateur. Ce rseau reprsente en effet un investissement si considrable, quil nest pas concevable que chaque producteur alternatif se dote de son propre rseau de distribution. Cette ouverture est inluctable. Loprateur souhaite transformer cette contrainte lgale en une opportunit commerciale : les producteurs alternatifs deviennent en quelque sorte de nouveaux clients, auxquels loprateur doit fournir des services, payants, sur un pied dgalit avec lex monopole national de production dnergie. Louverture la concurrence se fait progressivement : dans un premier temps, les producteurs alternatifs sont autoriss servir les clients professionnels. Dans un second temps, la concurrence concerne galement les clients particuliers.
86
7. Dfinir la cible
Pour rpondre ces objectifs, et malgr la relative jeunesse de cette approche, il est dcid de sappuyer sur une architecture SOA, pour bnficier des avantages de cette approche, notamment : Mise en place de processus automatiss flexibles. Rutilisation des processus et des services quel que soit le canal denvoi dune demande de service (mise en place dune approche multi-canal). Intgration avec les systmes existants via des services spcifiques. Le projet se nomme PORTOS (Portail Oprateur Rseau pour la Transmission de demandes, Orient SOA).
Contraintes principale
Les contraintes du projet sont principalement les suivantes : La solution doit grer la volumtrie des demandes de prestation, lie louverture la clientle des particuliers. La solution doit tre volutive peu de frais, afin doffrir de plus en plus de services aux producteurs alternatifs : consultation de leurs factures, paiement en ligne, etc. La mise en place progressive de ces offres doit tre aussi lgre que possible.
87
La solution doit tre scurise. La solution doit tre mise en place dans des dlais courts.
88
7. Dfinir la cible
Producteur dnergie
Frontal XML
Portail
Distributeur dnergie
Processus
Services
Accs existant
Rfrentiels
contrler la syntaxe XML des flux reus, cest--dire sassurer que chaque information contenue dans un flux respecte sa dfinition (contenue dans un schma XML); aiguiller chaque flux vers le gestionnaire de processus.
Un pattern architectural ? Le fil rouge prsent est un cas dcole qui est de facto gnrique. Ds lors quune entreprise souhaite ouvrir son systme dinformation ses clients via le canal Internet, la solution mtier quelle devra mettre en place distinguera dune part un front office et dautre part un back office. Le front office sera en gnral compos de deux canaux daccs : un accs interactif via un portail, intgrant des applications composites interactives, et un accs de type EDI, via un frontal rceptionnant des flux XML. Le front office accdera un back office, offrant (1) des processus mtier (un processus dans le cadre SOA tant lui-mme considr comme un service de haut niveau), (2) des services (services mtier, services techniques) et (3) des applications interactives de back office.
89
Les chapitres suivants vont nous permettre de prciser le contenu de cette architecture, en modlisant certains de ces composants, en faisant apparatre des composants complmentaires, et (dans les parties suivantes) en prcisant les outils/normes/ langages utiliss et leur mise en uvre concrte.
En rsum
Le concept dapplication nest plus adapt au contexte SOA. Il est prfrable de parler de solution mtier. Une solution mtier comprend lensemble des composants ncessaires pour rendre le service attendu par les utilisateurs mtier. Elle garantit leur bonne intgration fonctionnelle et technique, y compris lintgration des composants dj en production.
8
Modliser les services
Objectif
Lobjectif de ce chapitre est de prsenter une dmarche de modlisation des services dployer. Par dfinition, lapproche SOA consiste avant tout mettre en place des services rutilisables et/ou interoprables. Or une fois dfini ce concept de service, commencent les difficults : que sont donc ces services ? Y a-t-il plusieurs sortes de services ? Quelles sont les prcautions prendre pour obtenir une modlisation acceptable ? Comment prendre en compte les systmes existants ? En bref, une fois leffervescence de la nouveaut passe, il sagit de modliser une architecture de service, et dutiliser cette architecture pour concevoir, dvelopper et dployer une premire version de la bibliothque de services. Les premiers projets SOA ont fait merger cette architecture de service par tapes, chaque tape faisant apparatre des forces et des faiblesses de larchitecture mise en place. Le chapitre sappuie sur le fil rouge pour mettre en vidence ces diffrentes tapes, et permettre ainsi de gagner du temps. On verra galement que le critre de performance joue un rle clef, comme souvent.
92
93
94
Rechercher dans le ou les rfrentiels concerns lensemble des objets mtier satisfaisant un critre de recherche : par exemple, rechercher lensemble des clients habitant la Haute Savoie . Mettre jour un objet mtier existant : par exemple, mettre jour ladresse lectronique du client Jean Martin . Supprimer un objet mtier comme il est rare de dtruire rellement un Objet Mtier dans un systme de gestion, le delete sera souvent complt1 par une opration darchivage. Pour lire ou crire un objet mtier racine , le service CRUD associ accdera en gnral plusieurs tables du rfrentiel concern (table client , table adresse ), voire plusieurs rfrentiels. Un service CRUD masque donc la complexit intrinsque du modle dobjets mtier manipul. Ces services CRUD sont importants, car ils sont fortement rutilisables par les solutions mtier.
95
Portail
4 Processus
CRUD
CRUD
CRUD
Ressource
Ressource
Ressource
Utilisateurs
Demandes
Contrats
Messagerie
Journal de Bord
EAI
Figure 8.1 Premire tape : les services CRUD et les services techniques
Pour viter de surcharger la figure, la liste des services CRUD nest pas exhaustive. Les services CRUD ncessaires sont associs aux objets mtier suivants : Demandes : le service CRUD associ permet notamment denregistrer une demande et deffectuer des recherches sur la base des Demandes. Fournisseurs et Contrats : le service CRUD associ permet notamment de rechercher si le fournisseur mettant une demande de prestation possde un contrat en bonne et due forme, puis de lire ce contrat en base. PDD : le service CRUD associ permet notamment deffectuer des recherches sur les PDD utiliss par un fournisseur. Utilisateurs portail (gestion de lidentit) : le service CRUD associ permet notamment de rechercher le profil dun utilisateur identifi.
96
JAVA] si on utilise JAVA comme langage dimplmentation des services. Or cette utilisation est coteuse en temps CPU voire en mmoire. Le deuxime problme concerne la rutilisabilit. On peut le rsumer en se posant la question suivante : dans cette architecture, o sont les traitements mtier proprement dit, et en particulier les rgles de gestion ? En associant directement applications composites (le portail, le Gestionnaire de Processus) et services CRUD, larchitecture contraint lapplication effectuer elle-mme ces traitements mtier. Do deux dfauts : il ny a pas de rutilisation possible de ces traitements et de plus lapplication composite devient obse. Cette architecture nest donc pas facile mettre en uvre pour les concepteurs dapplication composite, et noptimise pas la rutilisation de logiciel. Le troisime problme, et pas le moindre, concerne la robustesse de larchitecture : les Web Services ne sont pas transactionnels. Il ny a donc aucune solution simple pour rendre cette architecture robuste. Des travaux sont certes en cours sur ce sujet, mais dune part ils ne sont pas ce jour termins, et, une fois termins, il restera dune part en valuer la facilit de mise en uvre et les performances, et dautre part attendre la maturit des implmentations.
Analyse de ltape 2
Cette tape rsout certains des problmes lists prcdemment mais pas tous. Sur le plan des performances, larchitecture minimise dsormais laccs du portail aux Web Services. De plus, comme le Service Applicatif est du bon ct de la barrire (cest--dire du pare-feu), il peut faire appel aux Services CRUD sans utiliser les protocoles WS, donc sans utiliser les transformations XML langage dimplmentation (cf. partie 5). De ce fait, les performances du portail sont meilleures.
97
Portail
EnregistrerDemande
CRUD
CRUD
CRUD
Ressource
Ressource
Ressource
Utilisateurs
Demandes
Contrats
Messagerie
Journal de Bord
EAI
De plus, la vie du concepteur du portail est simplifie : larchitecture met sa disposition un ou quelques services de trs haut niveau, et na plus se proccuper des services de granularit trop fine. Mais il reste encore des dfauts importants. Sur le plan de la rutilisabilit, cette solution ne fait que dplacer le problme. Lapplication composite nest plus obse, mais ce sont le ou les Services Applicatifs qui risquent de ltre. De plus, cette solution, si elle facilite la mise en uvre du portail, ne concerne pas le Gestionnaire de Processus, car les Services Applicatifs ne sont pas rellement rutilisables puisque spcifiques dune application composite, le portail en loccurrence. Le Gestionnaire de Processus est donc toujours contraint daccder aux services de grain fin . Sur le plan de la robustesse, il est possible dutiliser un mcanisme tel que les EJB Session pour implmenter laccs aux services CRUD. Ce mcanisme supporte un protocole transactionnel de type commit deux phases . Il serait donc possible damliorer la robustesse de larchitecture en se reposant sur les EJB, sans perdre en performance. Mais il est ncessaire de noter que certaines ressources techniques ne sont malheureusement pas des ressources transactionnelles : par exemple, un systme classique de gestion de fichier ou un gestionnaire de mail ne sont pas, en gnral, transactionnels. Autrement dit, mlanger dans un mme Service Applicatif laccs des ressources transactionnelles (les rfrentiels SQL) et des ressources non transactionnelles revient avoir un service non transactionnel : le protocole de
98
commit deux phases ne fonctionnera pas et larchitecture ne sera pas plus simple rendre robuste quavant, malgr le recours aux EJB.
Portail
Service Applicatif
Processus
creerDemande verifierDemande 3 6
planifierRDV confirmerRDV
creerProcessus 4
CRUD
CRUD
CRUD
Ressource
Ressource
Ressource
Utilisateurs
Demandes
Contrats
Messagerie
Journal de Bord
EAI
99
Un Service Fonctionnel associ la gestion automatise de la prise de rendezvous. Plus prcisment, le Service Applicatif enregistrer la demande de prestation , appel par le portail, fait lui-mme appel au Service Fonctionnel crer une demande puis au Service Fonctionnel crer le processus mtier associ cette nouvelle demande . Le Service Fonctionnel crer une demande excute les traitements suivants : Appel du service technique (non reprsent sur la figure) crer un numro unique de demande : ce service permet de rcuprer un numro unique didentification auprs du rfrentiel. Appel du service CRUD Crer Demande (correspondant la sauvegarde dans le rfrentiel concern des informations du formulaire, avec le numro unique didentification de la demande). Appel du service CRUD Mettre jour Historique de la Demande : ltat de la demande devient [demande enregistre]. Le Service Fonctionnel crer le processus mtier associ une demande excute les traitements suivants : Excution de la rgle de gestion Extraire de la demande les paramtres dappel du gestionnaire de processus . Appel du service Crer un processus dans le BPM ce service renvoie lidentit Id_processus du processus cr. Appel du service CRUD Mettre jour Demande : {demande.processus = Id_processus} . Appel du service technique Mettre jour le journal de Bord . On remarquera que le Service Fonctionnel crer une demande peut tre considr comme transactionnel, car il fait appel des services CRUD qui reposent euxmmes sur une ressource transactionnelle (le SGBDR). En revanche, le Service Fonctionnel crer un processus nest pas transactionnel, car ni le moteur de gestion de processus ni le journal de bord (cest--dire le systme de gestion de fichier) ne sont une ressource transactionnelle.
Analyse de ltape 3
Larchitecture obtenue rsout les problmes voqus auparavant. La facilit de mise en uvre de cette architecture est meilleure, car les concepteurs des Applications Composites, en particulier les concepteurs des processus mtier, se voient proposer des services de haut niveau plus facilement rutilisables.
Le prix payer pour obtenir une telle architecture, cest la rflexion qui doit prsider lmergence de la bibliothque de services fonctionnels. Si en effet les Services Applicatifs et les services CRUD mergeront relativement rapidement, il nen va pas de mme pour les Services Fonctionnels.
100
La modlisation des Services Fonctionnels sera guide par une double rflexion : Rflexion fonctionnelle, top down : les Services Fonctionnels mergent soit de la modlisation des processus mtier chaque tape dun processus implique lappel un Service Fonctionnel , soit de la modlisation des traitements et rgles de gestion mtier un Service Fonctionnel regroupera un ensemble cohrent de rgles et/ou de traitements. Rflexion technique, bottom up : le concepteur sarrange pour que le regroupement des services de bas niveau (CRUD et technique) se fasse de faon ce quun maximum de Services Fonctionnels soient transactionnels. On remarquera galement que larchitecture SOA propose ninterdit pas un Service Applicatif (ni mme une application composite) dappeler directement un service CRUD, lorsque cest utile. La dmarche propose nest pas de multiplier les couches de services pour le plaisir, ni driger en dogme des pratiques o le bon sens doit primer avant tout.
Applications Interactives
Applications Composites
Processus Mtier
SA SF SF
CRUD
CRUD
CRUD
CRUD
Ressource
Ressource
Accs Ressource
Accs Ressource
Accs Ressource
Accs Ressource
Accs Ressource
101
Rgle : appliquer une dmarche ayant pour objectif la mise en place dune typologie de service fonde sur la granularit des services et leur spcialisation. Cette typologie constitue de facto un guide de modlisation pour larchitecte des services.
102
Exporter un objet mtier vers un format donn (les principaux formats tant XML, PDF, CSV pour EXCEL). Importer un objet mtier partir dun format donn.
Opration de lecture
La signature dune opration de lecture est la suivante :
LireXXX(ClefDeLecture, ScenarioDeChargement, Contexte)
XXX doit tre remplac par le nom de lobjet racine concern : lireClient, lireDemandeDePrestation, lireContrat, etc. Expliquons le rle de chacun des paramtres dappel de cette opration. Clef de lecture : la clef de lecture contient les informations ncessaires la lecture de lobjet : ce peut tre une clef mtier simple ou complexe, une clef primaire daccs SQL, etc. Contexte de lappel : ce paramtre contient lensemble des informations dj obtenues par lapplication qui fait appel lopration. Par exemple, le contexte contiendra le profil de lutilisateur qui a initialis la session dutilisation de lapplication. Ce profil peut tre utilis pour contrler que lapplication ou lutilisateur ont bien le droit daccder au service concern. Le chapitre 10 revient en dtail sur ce concept de Contexte. Scnario de chargement : ce paramtre dcrit le scnario de chargement des informations relies lobjet racine . Pourquoi ce paramtre scnario ? Pour une raison fondamentale : un objet mtier nest jamais isol, il est toujours reli dautres objets mtier par un graphe de relations. Par exemple, un Client sera reli son Contrat, ses Demandes de Prestations, ses Factures etc. Le Contrat est lui-mme reli lhistorique des volutions du Contrat. La Facture est relie un Paiement, etc. En consquence, lorsque le dveloppeur fait appel une opration de lecture dun objet racine , il doit prciser quels sont les objets relis dont il a besoin. Dans certains cas, il naura besoin que de lobjet racine lui-mme. Dans dautres cas, il aura besoin de tout le graphe dobjets relis. Par exemple, dans certains cas, il voudra uniquement lire les informations du Client (nom, adresse), dans dautres cas il voudra obtenir le Client, son Contrat et les dernires demandes de Prestation, dans dautres cas encore il voudra le Client et ses Factures, etc.
103
Peut-on viter dutiliser un tel paramtre ? Par exemple, pourquoi ne pas tout lire dun coup ? Pour des raisons de performance : le risque tant de ramener de fil en aiguille lensemble du rfrentiel en une seule malheureuse lecture ! A contrario, pourquoi ne pas sen tenir une lecture paresseuse , cest--dire la lecture de lobjet racine lui-mme, sans tenir compte de ses relations ? Tout simplement parce que dans beaucoup de cas une telle lecture nest pas suffisante, il est ncessaire de lire certains objets relis pour que lapplication cliente puisse travailler. Or une stratgie purement paresseuse conduit multiplier les appels aux oprations de lecture ce qui nest pas non plus favorable aux performances : en utilisant le concept de scnario de chargement , le dveloppeur des oprations de lecture peut au contraire optimiser ce chargement.
Opration de recherche
La signature gnrale dune opration de recherche est la suivante :
rechercherListeXXX(ListeCriteres, Contexte)
listeCritres : cette liste contient lensemble des critres de recherche qui vont permettre de restreindre la recherche dans le rfrentiel : Un critre de recherche est un triplet [nomAttribut | oprateur logique | valeur]. Le nom de lattribut dsigne lun des attributs dcrivant lobjet mtier concern (exemple : la date de signature du contrat client). Loprateur logique permet de comparer lattribut dun objet mtier la valeur du critre. Par exemple, on recherchera tous les contrats qui ont t signs avant telle date, ou dans lintervalle temporel [date1, date2], ou aprs telle date. avant , inclus dans , aprs sont autant doprateurs logiques. La liste des oprateurs logiques admissibles pour un attribut dpend en gnral du type de cet attribut. Contexte de lappel : ce paramtre contient lensemble des informations dj obtenues par lapplication qui fait appel lopration (cf. chapitre 10) : Le contexte contiendra par exemple le profil de lutilisateur de lapplication. Ce profil peut permettre de filtrer les informations accessibles cet utilisateur : celui-ci naura par exemple accs quaux contrats de tel ou tel type, ou quaux clients habitant Marseille. Cest donc un critre de recherche supplmentaire, impos par le systme pour respecter une rgle de confidentialit (lapplication appelante ne peut pas y droger). Remarquons quil ny a pas de paramtre scnario dans la signature de base dune opration de recherche. Lappel par une application une opration de recherche dbouche ensuite sur laffichage par cette mme application dune liste plus ou moins longue dobjets mtier : lobjectif est doptimiser laffichage de cette liste, et il semble inutile de ramener beaucoup dinformation sur chaque objet de la liste, donc a fortiori il parat inutile de chercher des objets mtier relis ces objets.
104
Cependant, un lecteur expriment objectera que certaines des informations affiches nappartiennent pas ncessairement lobjet mtier lui-mme, mais un des objets qui lui sont relis. Par exemple, si on veut afficher la liste des fournisseurs dnergie, il peut tre intressant dafficher pour chaque fournisseur le code postal de son sige social. Or ce code postal nest pas directement un attribut de lobjet fournisseur mais un attribut de lobjet adresse gographique associ au fournisseur. Dans ce cas, un paramtre scnario peut savrer utile.
Rplicateur
105
Si on admet que la solution de gestion des demandes accde ces rfrentiels matres via les services appropris, la consquence immdiate est que la robustesse de cette solution sera celle du maillon le plus faible. Ce principe de partage des informations, consquence a priori logique de lapproche SOA, est sain en thorie; mais il risque dtre contradictoire avec une contrainte forte de fiabilit. Une solution de type e-Business doit le plus souvent satisfaire des contraintes de disponibilit, de type 24/24 7/7. Dans ce type de situation, il sera donc ncessaire de dupliquer tout ou partie de certains rfrentiels. Cette dcision de dupliquer les informations utilises par la solution mtier implique la mise en place dune fonction de rplication. La figure 8.5 illustre les deux solutions possibles.
Rpliquer ou agrger ?
La partie 2 a mis en vidence que lun des intrts de SOA tait de fournir aux applications une vision unifie des informations mtier. Prenons un exemple typique, frquent dans les grands systmes dinformation : le problme de la vision client . Lobjectif est de fournir aux acteurs commerciaux une vision unifie de la situation dun client vis--vis de lentreprise (fiche didentit, contrats en cours, historique des commandes, historiques des paiements, historique du support aprsvente, etc.). Or cette situation est en gnral clate entre diffrents silos informatiques1 : il est donc ncessaire de fournir une vision unifie en agrgeant diffrentes informations issues de ces silos. Cette vision peut tre virtuelle : lopration de lecture offerte par le service CRUD vision client va chercher la vole les informations ncessaires dans les diffrents rfrentiels. Mais on peut galement prfrer, pour les raisons de robustesse
Solution SOA P Existant A Existant B Existant C
Agrgateur
106
voques prcdemment, ou pour des raisons de performances, mettre en place un rfrentiel vision client dupliquant concrtement les informations ncessaires. La figure 8.6 illustre ce cas.
Avantages et inconvnients
Rpliquer une information implique que la solution SOA naura pas ncessairement accs la toute dernire version de cette information, en fonction du mode et de la frquence de rplication. Il existe en effet deux modes de rplication : en batch, ou bien au fil de leau (ds que linformation matre est modifie, elle est rplique). Dans certains cas, le mode batch de rplication nest pas acceptable sur le plan mtier : cela peut tre le cas des relevs de consommation sils sont mis jour au fil de leau. Dans ce cas, les informations doivent tre accdes en temps rel : donc la rplication devrait se faire au fil de leau , ce qui peut tre trs coteux (cot de loutil sous-jacent, complexit du paramtrage de cet outil, baisse des performances du rfrentiel rpliqu, etc.). La dcision de rpliquer une information suppose donc danalyser la frquence de mise jour de cette information et dtudier la frquence possible de rplication. A contrario, partager un rfrentiel implique que ce rfrentiel central verra sa charge de travail augmenter : la performance des accs doit tre troitement surveille. La question de la rplication des informations mtier se pose donc ds le dpart de la conception des services CRUD dans un contexte SOA. La rponse dpend du compromis faire entre un certain nombre de critres de dcision, rsums par le tableau 8.1.
Tableau 8.1 Critres de dcision
Duplication des informations Pro > Robustesse de la solution SOA. > Performance meilleure. > La fonction de duplication peut tre dote de capacit de transformation du format des donnes, pour simplifier le dveloppement des services CRUD. > Les informations mtier dupliques ne sont pas ncessairement jour (dpend de la frquence de duplication) certaines informations fortement transactionnelles ne peuvent tre dupliques. > Si les donnes dupliques sont mises jour, ncessit de rtro-propager ces mises jour vers la donne de rfrence complexit de la solution. > La solution est plus coteuse (prvoir la fonction de rplication/agrgation). Partage des informations > Les informations mtier partages sont toujours jour. > La solution SOA est plus simple dployer.
Cons
> La robustesse de la solution dpend de la robustesse du rfrentiel central. > Les performances doivent tre sous surveillance permanente (monte en charge de ce rfrentiel central). > Les services CRUD doivent ventuellement effectuer des transformations de format pour satisfaire les besoins de la solution mtier.
107
Si on prend la dcision de dupliquer les informations, alors il faut inclure une fonction de rplication ou rplication + agrgation de donnes dans le primtre du projet SOA. Cette fonction sappuiera sur un outil : compte tenu de la diversit des besoins de rplication, loffre des middlewares ddis1 est large, des outils de type ETL qui deviennent de plus en plus sophistiqus en matire de rplication, jusquaux outils de type MDM dont nous parlerons en partie 7 pour les aspects agrgation + rplication. Si au contraire on prend la dcision de partager les informations, alors il sera ncessaire de rpondre deux questions : Comment rendre les solutions mtier aussi rsistantes que possible une panne dun des rfrentiels, puis sa remise en service ? Le minimum vital tant dviter quune telle panne nentrane un plantage brutal de la solution. Comment faire face la monte en charge du rfrentiel ? La premire question implique une rflexion sur la conception des services CRUD daccs au rfrentiel. Ces services doivent, avant daccder effectivement au rfrentiel, sassurer que celui-ci est en fonctionnement.
1. Sans parler des solutions propritaires offertes par chaque grand offreur de SGBD, ou des solutions de rplication physique lies la mise en place dun SAN.
108
CRUD
Accs Ressource
Accs SQL (CREATE) la table audit des critures
Accs Ressource
Accs SQL (UPDATE) au rfrentiel compte
Accs Ressource
Envoi dun mail au commercial en charge du client
109
Intranet
Middleware daccs
Appli
110
quelles sont implmentes sur un serveur frontal galement local. Le choix dpend des capacits de cette technologie locale supporter ou non des services crits dans un langage moderne (lAS/400 permet par exemple de raliser et dhberger directement des faades Java).
Intranet
Middleware daccs
Existant Appli
Les avantages de cette solution dcentralise sont (i) de prserver un existant rd, (ii) de faire raliser les services lgataires par les informaticiens en charge de ces applications locales, et (iii) disoler totalement la solution mtier SOA de toute adhrence avec les technologies locales . Le premier point clef pour le succs dune solution dcentralise rside dabord dans le choix du bus de communication entre la solution mtier SOA et les services lgataires distants. Ce bus doit tre compatible avec les technologies locales. Un second point clef rside dans la ncessit de synchroniser fortement le projet de dveloppement de la solution mtier SOA dune part, et le projet de dveloppement des services lgataires dautre part.
111
Cette solution est intressante lorsquil sagit daccder une application du systme central (le fameux mainframe) dj structure sous forme de services, ou quil est facile de modifier pour quelle offre (dans sa technologie native) lquivalent de services. Certains lecteurs constateront en effet que la dmarche SOA leur rappelle quelque chose : il est indniable que mme dans le monde mainframe, pour ne pas parler du monde objet, des architectes et responsables dapplication ont, comme Mr Jourdain pour la prose, adopt une dmarche SOA avant lheure. Dans ce cas, laccs direct au(x) application(s) existante(s) en sera nettement facilit. Dans une solution centralise, les dveloppeurs des faades SOA accdent directement un service technique daccs au middleware de communication avec le(s) systme(s) existant(s), que ce soit un EAI, un MOM (MQ Sries par exemple), un moniteur transactionnel (TUXEDO le plus souvent) ou une passerelle oriente mainframe IBM (passerelle CICS ou IMS).
Services
Solution SOA
Accs Legacy
Site central
Existant
112
sans rien savoir de son implmentation. Tant que le service appel respecte ce contrat, limplmentation de ce service appel peut voluer ad libitum (par exemple, pour optimiser les performances, enregistrer des traces, mieux scuriser laccs au service, etc.), sans que le service appelant nait en tenir compte. dictons en second lieu quelques rgles mthodologiques simples de composition, rgles dcoulant de la typologie des services. Rgle : deux services mtier de mme niveau ne peuvent sappeler entre eux, sauf exception. Rgle : un service mtier utilise un/des services mtier de niveau(x) infrieur(s) et un/des services techniques. Rgle : un service technique nappelle pas un autre service technique, sauf exception (journalisation des oprations). Rgle : un service nappelle pas un service dun niveau suprieur. Les appels se font en cascade, de haut en bas de la hirarchie. Rgle : un service doit tre utilis au moins une fois soit par une application composite, soit par un autre service, sinon son utilit est douteuse. La composition de services jouant comme on le voit un rle important pour construire dautres services, il est important de se doter doutils et de normes facilitant cette composition. Cest ce que lon verra dans la partie 4 avec lintroduction la norme SCA (Services Composition Architecture).
En rsum
Limportance de la typologie et de la granularit des services ne saurait tre sous estime dans la russite de la mise en place dune Architecture Oriente Service. Les diffrentes catgories de service prsentes dans ce chapitre permettent de satisfaire les exigences de rutilisabilit, dinteroprabilit et dorchestrabilit au sein des processus mtier. Le tableau suivant rsume notre propos :
113
Granularit
Rutilisabilit
Interoprabilit avec lextrieur du SI Forte : ce sont les services qui ont vocation tre accessible de lextrieur du SI.
Orchestrabilit
Forte.
Sans objet : un SA est spcifique dune application composite interactive, cest-dire spcifique dun besoin mtier prcis. Moyenne (pour les services de type accs des informations de synthse) forte (accs des traitements de simulation tarifaire.). Forte.
Sans objet.
Moyenne Forte.
Dpend du contexte.
Forte, puisque lorchestrabilit est lun des critres de modlisation de ces services.
Faible.
Sans objet : un service CRUD ne doit pas tre directement accessible. Sans objet : un service technique ne doit pas tre directement accessible. Sans objet, dans la mesure o un systme existant na pas t conu pour tre ouvert sur lextrieur via Internet.
Faible.
Service Technique
Moyenne Forte.
Forte.
Sans objet, ces services doivent tre encapsuls dans des services fonctionnels. Faible Moyenne (attention aux performances).
Service Lgataire
Forte.
Faible Moyenne (dpend du contexte, notamment de la structure mme du systme existant accd par le service lgataire).
9
Modliser les processus
Objectif
Lobjectif de ce chapitre est de prciser ce quon entend par processus mtier dans un contexte SOA. Le concept de processus mtier est encore plus vieux que le concept de workflow, et il est indispensable den prciser la smantique dans ce contexte. La clef dune dmarche SOA centre sur les processus rside dans lobtention dune bonne modlisation des processus. Comme pour les services, les tapes successives de modlisation des processus mtier sont mises en vidence en prenant appui sur notre exemple fil rouge . Le chapitre montre en quoi la vision mtier des processus doit imprativement tre complte par une vision technique de ces processus, et dgage les principes de modlisation quil est ncessaire de respecter. Centrer le systme dinformation sur les processus ne ncessite pas seulement de bien modliser ces processus. Il est galement ncessaire de modliser larchitecture de dploiement des processus, en mettant en vidence limpact sur lutilisateur final.
116
exemple tre lenvoi dune commande, une demande de prestation de service, une demande de simulation de crdit, lenvoi dune facture, etc. Le processus mtier est dfini par : Lvnement mtier dclencheur , qui est lorigine du processus, mais galement les vnements mtier que le processus change avec le monde extrieur (par exemple : vnement envoi dune lettre au client rclamant des informations complmentaires pour traiter la demande, et vnement rception de la rponse du client ). Les activits qui doivent tre excutes, et les rgles conditionnant le passage dune activit une autre. Pour chaque activit, et en fonction des choix dorganisation de lentreprise, lacteur (ou le groupe dacteur) qui doit excuter lactivit1. Il est indispensable de bien diffrencier modle de processus et processus (ou instance de processus). Un modle de processus dcrit de faon gnrique comment lentreprise ragit un type dvnement mtier; une instance de processus associe ce modle traite un vnement mtier individuel. Par exemple : le processus traitement de la demande de prestation no XYZ en date du 5 mars 2007 mise par la socit Martin sera associ au modle de processus dcrivant comment lentreprise gre un vnement mtier traitement dune demande de prestation . Le concept de processus mtier est troitement associ au concept de Gestion des Processus Mtier (ou BPM : Business Process Management). Lide fondamentale tant que le systme dinformation soit paramtr par les modles de processus : la description dun processus nest plus enfouie dans le logiciel, mais externalise sous forme de modle, et il existe un outil spcifique, le moteur BPM, qui excutera les instances de processus associes au(x) modle(s). Lavantage clef obtenu est de pouvoir faire voluer facilement les processus sans toucher aux applications associes.
117
Le succs de SOA vient en grande partie de cette prise en compte de ce quon pourrait appeler les processus e-business : un processus e-business est un processus automatis, cr suite une interaction entre une entreprise et son cosystme via le Web. Lexprience montre que les directions informatiques convainquent leur direction gnrale de financer le tournant SOA par lintrt de la mise en place de tels processus e-business. Lintrt est tel quil a suscit lmergence de normes et outils ddis. Un modle de processus SOA, cest--dire la description de lorchestration du processus partir de services mtiers, sera ainsi dcrite grce un langage ddi cet usage et standardis par les acteurs du monde SOA : BPEL (Business Process Execution Language) est dsormais reconnu sur le march pour lexcution dune telle orchestration. BPEL, tant une grammaire XML, il reste illisible pour une matrise douvrage, un formalisme mtier est galement envisag. Pour la phase danalyse, de pilotage et doptimisation, ce jour, seul BPMN1 (Business Process Modeling Notation) propose une base graphique normalise mais encore incomplte. En outre ne sont pas encore pris en compte la modlisation daspects mtiers traditionnels tels que les cots, les temps, les risques, les indicateurs, etc. Un processus associ un tel modle sera cr et excut par un orchestrateur BPEL , qui joue le rle dun moteur de workflow classique.
118
OK
OK
OK
Demander intervention
Planifier intervention
tablir facture
Le processus dbute par lanalyse de la demande de prestation mise : est-elle recevable par lentreprise eu gard diffrents critres mtier ? Il se poursuit par lenvoi dune demande de planification au systme de planification des interventions (on fait ici lhypothse simplificatrice qu une prestation correspond une et une seule intervention sur le terrain, cest--dire une intervention sur un Point De Distribution dnergie). Le systme de planification renvoie une date dintervention ainsi que lidentit de lquipe dintervention. Le moment venu, le processus lance lintervention (via un mail lquipe), envoie un compte-rendu dintervention au demandeur, calcule la facture et lmet vers le demandeur. Un tel modle permet la MOE de bien comprendre les objectifs poursuivis par la MOA. Cependant, dun point de vue technique, ce modle nest pas directement exploitable pour les raisons suivantes : Le modle est dcoup trop finement : excut tel quel par un moteur BPEL, il conduirait multiplier lappel des services de grain fin, ce qui induit des problmes de performances. Le modle liste les exceptions mtier, mais ne prcise pas comment ces exceptions sont traites. Il existe dautres exceptions, dordre technique, qui ne sont pas mises en vidence : par exemple, que se passe-t-il si le systme de planification ne rpond pas ? Que se passe-t-il si lintervention nest plus possible la date planifie pour une raison quelconque, ou si la messagerie lectronique est hors service ? Le problme de la granularit du modle de processus est directement li au problme de la granularit des services, dj voqu dans le prcdent chapitre. Il faut insister sur ce point, en dictant le principe suivant : La vision MOA dun processus SOA ne fait pas directement merger les services orchestrer : pour rsoudre ce problme, il est ncessaire de regrouper les activits du processus pour faire apparatre les services fonctionnels.
119
La gestion des exceptions pose un double problme. Dune part, il est ncessaire davoir une vision exhaustive des causes possibles de dysfonctionnement du processus, et pour cela ne pas hsiter appliquer la loi de Murphy ( tout ce qui peut poser problme posera problme un jour ou lautre ). Dautre part, il est ncessaire de savoir qui traite les exceptions dans un processus automatis, et comment. Rpondre cette question, cest rflchir la place de lhomme dans le systme , et mettre en vidence les composants complmentaires (services, applications composites) permettant de traiter ces exceptions. En bref, cette premire tape conduit une deuxime tape qui doit prciser le primtre de la solution mtier incluant le processus, en dfinissant (1) les services rellement orchestrs par le processus (services fonctionnels, services techniques) et (2) les applications composites permettant de traiter les exceptions.
9.2.2 Deuxime tape : lanalyse du processus et limpact sur le primtre de la solution mtier
La deuxime tape vise donc analyser le processus mtier pour prciser le primtre de la solution mtier associe ce processus. Cette analyse doit satisfaire aux exigences de granularit des services et dexhaustivit de la gestion des exceptions. Ce modle est obtenu en appliquant les principes suivants : regrouper certaines activits du processus vision MOA , pour minimiser le nombre de services appels, et faire merger les services fonctionnels; dcrire succinctement la faon dont les exceptions sont traites, en interaction avec la matrise douvrage qui statue en dernier ressort.
Analyser lexception et recycler la demande, via une intervention humaine Exception intervention impossible Envoyer CRR intervention Demander intervention
OK
Grer facture
120
La figure 9.2 dcrit le rsultat obtenu pour le modle de processus du fil rouge . On remarquera que lon peut grer les exceptions de deux faons : si lexception rsulte de lapplication dune rgle de gestion par un service appel par le processus, elle peut tre traite automatiquement (exemple : si le demandeur est en contentieux car il na pas rgl ses prcdentes factures, alors le processus envoie une lettre ou un mail notifiant le rejet de la demande); si lexception rsulte dun problme extrieur au processus (exemple : un systme extrieur, sollicit, ne rpond pas dans les dlais), elle ne peut en gnral tre traite que par une intervention humaine. Le traitement des exceptions par une intervention humaine conduit donc au concept de recyclage, qui se traduit par le scnario suivant : le processus mtier lve une exception et signale cette exception un acteur humain; lacteur humain tudie lexception : il peut dcider de clore la demande, ou bien il intervient pour dbloquer cette demande; le dblocage dune demande entrane automatiquement la cration dun processus dit de recyclage. Ce processus de recyclage peut ou non rutiliser certains services orchestrs par le processus normal .
Analyser lexception
La figure 9.3 met en vidence la ncessit de modliser non seulement le processus mtier en lui-mme, mais galement les moyens de traiter certaines exceptions, faute de quoi la solution mtier dploye ne sera pas complte.
121
introduire dans le modle les exceptions de type time out , cest--dire les temps dattente de la rponse dun systme externe (systme de planification par exemple), et la faon de traiter les exceptions.
OK
Planifier intervention
OK
Signaler lexception un acteur humain Intervention impossible
Planification impossible
Mettre jour tat demande Envoyer CRR intervention
Intervention effectue
Demander intervention
Grer facture
Mme ce stade de conception du processus, le dialogue avec la matrise douvrage est plus que jamais indispensable, car certaines dcisions, apparemment techniques, peuvent la concerner trs directement, comme le prcisent les paragraphes suivants.
122
Portail
Demande recevable
Demande refuse
Intervention planifie
Processus Mtier
Intervention demande
Intervention effectue
Intervention facture
Il sera donc ncessaire dajouter dans le processus un ou des appels un service CRUD de mise jour de ltat de la demande. Cet ajout peut tre direct (on ajoute directement au modle de processus les tapes de mise jour de la demande, comme lillustre notre exemple) ou indirect (on ajoute ces mises jour dans les services fonctionnels). Le lecteur attentif objectera juste titre que lajout direct dans le modle de processus des appels un service CRUD (donc grain fin) nest pas conforme lobjectif gnral de granularit gros grain des services orchestrs par le moteur de Processus. Mais positionner les appels ce service dans les services fonctionnels risque de rendre ces services fonctionnels non rutilisables par dautres applications composites. Cette dcision est donc prendre au cas par cas.
123
124
mtier. Il sagit donc de modliser les principaux composants de cette solution et de montrer les interactions entre ces composants. On remarquera au passage que certaines offres BPEL du march (Oracle, IBM, BEA, etc.) commencent offrir des composants prenant en compte la dimension humaine : ce qui suit peut tre aussi utilis comme guide de comparaison de ces offres. Les composants modliser doivent permettre de rpondre deux questions clefs : Comment linfrastructure SOA connat-elle lacteur qui doit intervenir sur le processus ? Comment lacteur concern sait-il quil a quelque chose faire ?
Organisation
Le service de routage
Ce service a pour objectif de dterminer quel acteur doit traiter lexception ou, plus gnralement, quel acteur doit intervenir sur le processus. On parle daiguiller ou de router le processus vers lacteur devant intervenir, do le nom du service. Tout dabord, on remarquera que, le plus souvent, le routage seffectuera non pas vers un acteur nominatif, mais vers un groupe dacteurs ayant le mme profil et runis dans une mme cellule de travail (une cellule pouvant tre : une agence commerciale, une direction rgionale, une cellule de gestion au sein du sige de lentreprise, etc.).
125
Pour effectuer ce routage, le service de routage sappuie sur deux concepts fondamentaux permettant de rpartir le travail au sein dune organisation : Le concept de portefeuille de processus. Le concept de portefeuille dobjets mtier. Le portefeuille de processus dune cellule de gestion est lensemble des modles de processus sur lesquels la cellule a le droit dintervenir. Par exemple, toute cellule agence commerciale dpartementale peut intervenir sur un processus de demande de prestation et notamment en traiter les exceptions. Le portefeuille dobjets mtier est lensemble des objets mtier (ou plus exactement des instances mtier) sur lesquels la cellule a le droit dintervenir. Par exemple, la cellule agence commerciale du dpartement 59 peut intervenir sur tout ce qui concerne les clients localiss dans ce dpartement. On utilisera souvent des portefeuilles de clients (notion classique dans le monde de la gestion), mais on peut galement avoir des portefeuilles contrats par exemple. Pour router un processus instanci sur le modle de processus X et traitant un vnement mtier initi par le client Y, le service de routage procde en trois temps, comme le montre la figure 9.6 : le service de routage calcule lintersection entre lensemble des cellules pouvant intervenir sur le modle de processus X, et lensemble des cellules ayant Y dans leur portefeuille client. Pour cela, il interroge le service Organisation pour avoir les informations ncessaires (tape 2 de la figure); lorsque le service de routage a dtermin la ou les cellules susceptibles dintervenir, le service dtermine le ou les acteurs ayant le profil pour intervenir. Pour cela, il interroge nouveau le service Organisation (tape 3 de la figure); enfin, le service de routage met jour le rfrentiel grant ltat des processus en associant au processus lidentit du ou des acteurs pouvant intervenir (tape 4 de la figure). Par exemple, seuls les acteurs de profil consultant commercial senior et appartenant la cellule agence commerciale dpartementale 59 pourront intervenir sur une exception associe une demande de prestation mise par un client de ce dpartement.
Le service dorganisation
Les informations ncessaires au fonctionnement du routage sont gres par un rfrentiel ddi, le rfrentiel Organisation. Le service Organisation est le service de type CRUD permettant dinterroger et de mettre jour ce rfrentiel Organisation. Les informations gres via ce rfrentiel sont en premier lieu les informations classiques : acteurs, hirarchie organisationnelle des cellules, profils des acteurs. Le rfrentiel contient galement pour chaque cellule le portefeuille dactivit et le portefeuille client/contrat grs par cette cellule.
126
Le rfrentiel peut galement contenir dautres types dinformation, permettant de grer un routage plus prcis, comme par exemple les informations sur la disponibilit des acteurs (acteur en vacances, acteur en arrt maladie, intrimaire, stagiaire, etc.).
Bureau
Corbeille 4
Modles
Processus
Routage
Orchestrateur
Organisation
127
Aprs avoir rcupr le profil de lacteur associ (tape 1 de la figure), le poste de travail affiche la corbeille ddie cet acteur (tape 2). La corbeille utilise ensuite ce profil pour rcuprer et afficher la liste des (instances de) processus sur lesquels lacteur doit intervenir : elle accde pour cela au service de gestion de ltat des processus (tape 3). En slectionnant un processus dans cette liste, lacteur invoque ipso facto lapplication qui permet dintervenir sur ce processus (tape 4).
Tableau 9.1 Les diffrents types de corbeille
Type de corbeille Corbeille individuelle Acteur utilisant ce type de corbeille Tout acteur appartenant lentreprise (par exemple : gestionnaire, responsable commercial, tl-acteur, etc.). Principales fonctions de ce type de corbeille > Afficher la liste des activits affectes nominativement lacteur (activits traiter, activits en cours de traitement). > Offrir des fonctions de tri et de filtre sur la liste (par exemple : afficher uniquement les activits concernant un client X). > Afficher la liste des activits affectes la cellule de lacteur concern. > Autoriser un acteur sauto-affecter une activit non encore affecte nominativement. Une activit affecte nominativement disparat de la corbeille de groupe. > Offrir des fonctions de tri et de filtre. > Afficher la liste des activits affectes la cellule ou aux cellules supervises par le responsable. > Autoriser le responsable changer laffectation dune activit. > Offrir des fonctions de tri et de filtre. > Offrir une fonction dhistorique. > Permettre la mise en place dalerte (une alerte est un filtre spcial permettant de dtecter quune activit na pas t traite avant un temps T, T paramtrable). > Afficher la liste des vnements mtier mis par lacteur externe. > Permettre lacteur de demander ltat du processus traitant un des vnements mtier de la liste.
Corbeille de groupe
Acteurs appartenant une mme cellule de gestion. Ils auront donc deux corbeilles leur disposition : corbeille individuelle et corbeille de groupe.
Corbeille de Supervision
Corbeille simplifie
Acteur externe lentreprise (par exemple, client mettant des demandes vers lentreprise).
Ce fonctionnement est hlas trop simple pour tre utile sur le terrain : lexprience montre que les besoins des diffrents acteurs concerns impliquent daller nettement plus loin en matire de fonctionnalit de la corbeille. Plusieurs questions se posent en effet :
128
Comme on la vu, un processus peut tre rout non pas vers un acteur mais vers une cellule : dans ce cas, comment se passe la rpartition du travail entre les acteurs de la cellule ? La liste des instances de processus peut tre fort longue : comment lacteur peut-il organiser son travail via sa corbeille ? Un responsable de cellule doit tre capable de superviser le travail de sa cellule : comment peut-il faire ? On retiendra que rpondre ces questions implique de mettre en place une typologie de corbeilles, en fonction du type dacteur concern. Le tableau 9.1 esquisse une telle typologie.
En rsum
Lun des intrts de lapproche SOA repose sur la possibilit de mettre en place des processus mtier de type e-business : cest en tout cas un avantage clef aux yeux des directions mtier, qui permet de justifier les investissements ncessaires une telle approche.
129
La modlisation de ces processus repose sur un dialogue troit entre matrise douvrage et matrise duvre. Ce dialogue doit tre guid par les quelques questions fondamentales que pose cette modlisation : granularit des services, traitement des exceptions mtier, traitement des exceptions techniques et qualit des services, etc. Cette modlisation conduit sinterroger sur la place fondamentale des acteurs humains dans ces processus automatiss. La mise en place de services et dapplications human driven compltant linfrastructure SOA (BPEL) permet de rpondre efficacement cette interrogation.
10
Modliser les applications composites interactives
Objectif
Lobjectif de ce chapitre est de fournir des pistes concrtes pour la modlisation des applications composites interactives. La phase dexpression de besoin de ces applications interactives repose sur les outils classiques que sont la description des cas dutilisation et le maquettage dcran. Le cadre UML, et les mthodes associes UML, telle que UP (Unified Process) cest--dire les outils utiliss jusqualors pour les dveloppements dobjets logiciels ce cadre convient pour cette phase. Limpact de SOA sur la modlisation des applications interactives concerne donc principalement les phases danalyse et surtout de conception de ces applications interactives. Depuis 1980, le modle MVC (Modle Vue Contrleur) est le modle de rfrence : lobjectif principal du chapitre est donc de revisiter ce modle, aprs en avoir rappel les caractristiques fondamentales. On introduit notamment le concept de Contexte local lapplication composite. Le chapitre introduit galement le concept de Transaction Longue, en expliquant en quoi ce concept a non seulement une dimension technique mais galement une dimension mtier.
132
2 Modle
Cette dynamique se dcompose en 4 grandes tapes : tape 1 : via un moyen dinteraction quelconque (clavier, souris, voix) gr par le moteur graphique, lutilisateur envoie une demande daction au Contrleur ; tape 2 : le Contrleur reoit cette demande, linterprte et en dduit le ou les actions demander au Modle Mtier. Le Modle Mtier est activ, et il doit renvoyer un objet rsultat ;
133
tape 3 : une fois le rsultat produit, le Contrleur choisit la Vue qui doit afficher ce rsultat lutilisateur final; tape 4 : une fois active, la Vue labore le flux graphique (page HTML, cran Windows, animation Flash, etc.) partir des informations de lobjet rsultat , puis envoie ce flux vers le moteur graphique (navigateur Web, Windows, interprteur Flash, etc.) ledit moteur devra interprter ce flux pour afficher la page ou la fentre graphique.
Contexte
Mtier
Mtier
Mtier
Mtier
Ressource
134
Cette dynamique se dcompose en 6 grandes tapes (en gras, les tapes qui apparaissent ou qui voluent par rapport au modle MVC classique) : tape 1 : lutilisateur final envoie une demande lapplication; tape 2 : le Coordinateur reoit cette demande, linterprte et en dduit le ou les services mtier et/ou techniques appeler; tape 3 : au fur et mesure de lappel de chaque service, le Coordinateur rcupre des informations, quil va stocker provisoirement dans un Contexte local pour laborer le rsultat afficher. Le Contexte a pu galement intervenir lors de ltape 2, en fournissant au Coordinateur des paramtres dappel des services; tape 4 : une fois le rsultat obtenu par appel au(x) service(s) et stock dans le Contexte, le Coordinateur choisit la Vue qui doit afficher ce rsultat lutilisateur final; tape 5 : la Vue rcupre dans le Contexte les informations afficher; tape 6 : la Vue labore le flux graphique renvoyer vers le moteur graphique. La suite du chapitre revient sur trois questions fondamentales de cette dynamique : (1) Comment grer un Contexte local une application composite ? (2) Quelle la consquence de lexistence de plusieurs contextes locaux en parallle pouvant accder au mme objet mtier ? (3) Quelle est larchitecture de ce que nous avons appel le Coordinateur dans le modle MVC/SOA ? Le chapitre conclut sur ce que pourrait devenir une Vue dans ce contexte SOA.
10.2.1
Le concept de Contexte
135
Le Contexte est le composant dans lequel lapplication composite va stocker pendant la dure de la session de travail les objets mtier dont elle a besoin pour rpondre aux demandes de lutilisateur associ cette session. Il y a donc une instance de Contexte par Session de travail.
Session de travail
t1
t2
t3 Temps
t4
Le Contexte est lquivalent de lobjet HttpSession propos par J2EE, si lon veut, mais cest un concept dabord architectural, indpendant de toute technologie, donc utilisable aussi bien en architecture client lger que client lourd1. On notera que ce concept de Contexte sapplique aussi bien aussi aux applications composites interactives, quaux processus mtier voqus au chapitre prcdent. Dans le cas des Processus Mtier, on parlera galement de gestion de Dossier (le concept de Dossier est identique au concept de Contexte ici dcrit).
136
Session de travail
t1
t2
t3 Temps
t4
1 2 3
2 Lire relev 3 Contexte(t3) Client Site A PDD A1 PDD A2 relev A2a relev A2b relev A2c Site B
2 Maj relev 3 Contexte(t4) Client Site A PDD A1 PDD A2 relev A2a relev A2b relev A2c Site B
CRUD
CRUD
CRUD
La figure 10.4 prsente lvolution du contexte dans la session de travail prsente plus haut, avec lapplication dune stratgie paresseuse . Le choix de la stratgie adopter dpend des besoins mtier, car chaque stratgie a ses avantages et ses inconvnients. La stratgie par anticipation autorise une navigation fluide entre les informations, puisque ces informations sont dj contenues dans le contexte, qui joue ici un rle de cache. Mais lanticipation prsente galement des inconvnients indniables : certaines informations seront inutiles (cest--dire jamais utilises pendant la session de travail de lutilisateur), et surtout le temps de chargement peut tre prohibitif lapplication risque en effet de souffrir du syndrome jai besoin dun objet mtier racine, et en fait je charge toute la base via les relations entre objets mtier . La stratgie paresseuse multiplie les chargements : lavantage principal est que chaque chargement individuel est plus performant que dans la stratgie prcdente, notamment le premier chargement, mais la navigation sera moins fluide du point de vue de lutilisateur final, surtout si les services CRUD daccs aux informations sont des web services distribus. Cette analyse du choix de stratgie de chargement conforte la mise en place de la notion de scnario de chargement, introduite au chapitre modliser les services (Paragraphe zoom sur les services CRUD ). Cette notion permet en effet de moduler le choix tout anticiper ou rien anticiper , en fonction du besoin mtier.
137
La stratgie paresseuse pose de plus un problme de gestion des doublons dans le Contexte. Pour expliquer ce problme de doublon, on sappuie sur lexemple du graphe dobjets mtier (diagramme de classe UML) de la figure 10.5.
Fournisseur dnergie
Client 1..n
1..n Facture
Admettons que lapplication charge dabord un objet de la classe client et les objets site , PDD et Relev qui lui sont rattachs, puis que lapplication effectue un chargement complmentaire avec les objets contrats , factures , et les objets qui leur sont rattachs. Sans prcaution particulire, les services de chargement vont crer des doublons de chaque objet relev , cest--dire deux instances de la classe relev (une par chargement) correspondant la mme information, alors quil ne devrait y avoir quune instance. Le graphe dobjet est alors incohrent, et posera des problmes notamment lors de la sauvegarde1. Une solution ce problme gnrique est de dlguer au Contexte le soin de dtecter lapparition de doublons (par comparaison des identits mtier ou des identits techniques).
138
Pourquoi, en poussant le raisonnement, ne pas considrer que le Contexte est le seul et unique paramtre dappel de tous les services mtier, en entre et en sortie ? Dabord parce que cette simplification radicale se ferait au dtriment de la robustesse de linvocation dun service. En effet, les outils sous-jacents (middleware web service, par exemple) ne pourraient plus contrler le typage des paramtres dentre, alors que cette capacit de contrle est un des atouts de ces outils. Ensuite, parce que lutilisateur dun service, cest--dire le concepteur de lapplication composite, ne peut plus, la seule lecture du contrat de service, comprendre ce que le service va produire comme rsultat. Cette simplification se ferait donc au dtriment de la rutilisation et de la robustesse des services mtier, et est donc proscrire.
139
2 3 4
a. U1 charge O1 est un raccourci commode pour U1 demande son exemplaire de lapplication dafficher O1, et pour cela lapplication (i) interroge le rfrentiel concern pour rcuprer les donnes (SQL ou autre) ncessaires, (ii) cre une instance de lobjet O1, (iii) remplit cette instance avec ces donnes (utilisation des get et des set), et (iv) met cette nouvelle instance dans le Contexte ddi U1 .
140
des chargements complmentaires, cest--dire invoquant si besoin les services CRUD associs. Lavantage principal de cette orientation est que le concepteur/dveloppeur de toute Application Composite na plus se proccuper de lappel des services CRUD et du remplissage du Contexte; il se contente dutiliser les services offerts par le Contexte. Linconvnient est videmment de complexifier la mise en place du service de gestion de Contexte.
10.2.2
141
Mais ce nest pas suffisant : il faut aussi se prmunir contre le cas de figure o une des sessions de travail se contente dutiliser un objet mtier, sans ncessairement le modifier. Cas de figure illustr par le tableau 10.3.
Tableau 10.3 Conflit entre un crivain et un lecteur
tape Travail de lutilisateur U1 U1 charge dans son Contexte lobjet O1 pour consultation . O1 est dans une version initiale v1, nous lcrirons O1v1. U2 charge dans son Contexte lobjet O1v1 pour modification . U1 travaille sur les objets de son Contexte. Ce travail peut dpendre de la valeur de O1v1. U2 modifie lobjet O1, qui devient lobjet O1v2. U2 sauvegarde via le Contexte lobjet O1v2. U1 continue travailler mais il ne sait pas que O1 est modifi : son travail peut en devenir incohrent ! Travail de lutilisateur U2
142
143
tape
Lapplication veut poser un verrou pour Consultation sur un objet mtier = lutilisateur U1 veut uniquement consulter cet objet mtier.
Lapplication veut poser un verrou pour Modification sur un objet mtier = lutilisateur U1 veut probablement modifier cet objet mtier.
Lapplication doit au minimum alerter lutilisateur risquant de modifier linformation attention ! Mr U2 risque galement de modifier cette information, vous risquez de perdre vos travaux respectifs . Si lapplication ne bloque pas lutilisateur U1, elle doit cependant tracer laction de U1 et/ou envoyer un mail lutilisateur U2.
a. Le service de verrouillage peut tre utilis par une application Composite Interactive ou par un Processus Mtier.
144
getLocks(businessObject) : cette opration permet de rcuprer lensemble des verrous poss sur un objet mtier. removeLock(user, businessObject, lockMode) : cette opration permet de supprimer un verrou. setLock(user, businessObject, lockMode) : cette opration permet de poser un verrou du type dfini sur lobjet mtier.
10.2.3
Il est possible de prciser le comportement dun coordinateur dans une architecture tenant compte des concepts de Contexte et de Transaction longue. La figure 10.6 dtaille larchitecture du coordinateur du modle MVC revisit.
Vue 1
Action 1
Graphe de Navigation
Vue i 4
Action
Action n 4 1 Composant fourni par le framework SOA Composant Dvelopper laide du framework SA
Contexte
Scurit
Verrou
Le composant Aiguilleur rcupre la demande mise par lutilisateur et rcupre si besoin les informations transmises dans la demande via un formulaire. Un composant Action, une fois slectionn puis activ par le composant Aiguilleur, a un comportement relativement gnrique : (i) il contrle le droit de lutilisateur utiliser cette action et/ou accder aux objets mtier concerns (accs au service de scurit) (ii) il verrouille si besoin un objet mtier (accs au service de ver-
Aiguilleur
Action 2
145
rouillage mtier) (iii) il active le ou les Services Applicatifs ncessaires (iv) il met jour le contexte (accs au service de gestion de contexte). Les composants Aiguilleur et Gestionnaire du graphe de navigation sont fournis par un framework, baptis CAF (Composite Application Framework) dans la littrature. Rgle : mettre en place un framework CAF, regroupant les outils (composants gnriques MVC) et services (verrou, contexte) permettant de dvelopper les applications interactives.
10.2.4
Et la Vue ?
Chaque vue affiche un ou plusieurs objets mtier contenus dans le Contexte. La vue devient un assemblage de panneaux, chaque panneau est associ un objet mtier. Une tendance actuelle est de modliser une vue laide dun formalisme XML. Ce formalisme permet de : lister les diffrents panneaux; pour chaque panneau, dcrire les composants graphiques afficher. Dans le cas dun formulaire classique, il sagira essentiellement de champs de saisie; lister les activateurs affichs par la vue (activateur = bouton, hyperlien, menu et item de menu); pour chaque champ de saisie, spcifier le lien entre le champ et lattribut de lobjet mtier concern; pour chaque activateur, spcifier laction appeler. Une fois modlise, cette description peut tre soit interprte par un plug-in de navigateur ou un moteur ddi (attention aux problmes de performance), soit utilise pour gnrer le code de la Vue dans une cible approprie (client lger ou client lourd). Ceci fera galement partie du framework CAF. On notera que de tels formalismes existent dj (on citera XFORMS du W3C, XUL de la fondation MOZILLA, XAML de MICROSOFT).
En rsum
La mise en place dune dmarche de modlisation dune architecture SOA ne se rduit pas lmergence dune bibliothque de services rutilisables : limpact de SOA sur les applications interactives ne doit pas tre sous-estim. Cela conduit revisiter le modle classique MVC. Ce travail fait merger naturellement les concepts de Transaction Longue et de Gestion de Contexte. Ces concepts ne sont pas triviaux, mais lexprience montre que la vraie difficult est de prendre
146
conscience que ces problmes existent et doivent dune faon ou dune autre tre pris en compte. Enfin, lutilisation dun framework orient application composite (CAF) permet dhomogniser la mise en uvre de larchitecture propose sur lensemble des solutions mtier.
11
Organiser un projet SOA : dmarche, acteurs, outils
Objectif
Lobjectif de ce chapitre est de prsenter des principes gnraux de mthode et dorganisation ds lors quune direction informatique sengage avec lappui de ses matrises douvrage dans une orientation SOA. Le chapitre prsente en premier lieu le concept de Programme SOA et la dmarche mthodologique associe ce concept. Cette dmarche se prsente sous la forme dtapes, ventuellement dclines en sous-tapes. Chaque tape de la dmarche est mise en uvre par des acteurs de lorganisation regroups en quipes projet et quipes transverses. Ces quipes se coordonnent via des comits priodiques. Enfin ces acteurs utilisent des outils. Acteurs, Structures et Outils sont dcrits dans les diffrents sous-chapitres qui leur sont ddis.
11.1 PLANIFIER
La dmarche mthodologique dcrite dans ce chapitre permet dlaborer le planning dun projet en le dcomposant en tapes. Cette dmarche est prsente par la figure 11.1 (en gris fonc les tapes probablement dj ralises en totalit ou partiellement au moment de ladoption de SOA).
148
Grer le programme SOA Dployer les outils et plate-formes pour concevoir, dvelopper & intgrer
Dvelopper Dvelopper une unesolution solutionmtier mtier Dvelopper un (des) Dvelopper un (des) Dvelopper un Dvelopper un(des) (des) service(s) mtier rutilisable(s) service(s) mtier rutilisable(s) service(s) mtier rutilisable(s) service(s) mtier rutilisable(s) Adapter un Adapter Systme Existant un Systme Existant
Intgrer le SI Dvelopper un Proof Of Concept Mettre en place le framework de dveloppement SOA Mettre en place linfrastructure (ESB) Hw/Sw SOA
11.1.1
Utilisation de la dmarche
La figure 11.1 prsente un enchanement macroscopique et chronologique des diffrentes tapes. Cet enchanement chronologique doit tre adapt en fonction du contexte propre chaque projet SOA. Autrement dit, limportant ici est la liste des tapes, car elles sont gnriques. En revanche lenchanement chronologique dpend du contexte de chaque projet : il est en effet probable que le dveloppement des solutions et services se fera par versions successives, ce que la figure 11.1 ne fait pas apparatre. Par exemple, un service pourra dabord avoir une version 0 sous forme de service bouchon , afin de permettre le dmarrage au plus tt des tests des applications clientes du service. Une version 1 de qualification fonctionnelle permettra ensuite la MOA de valider concrtement le service vis--vis de lexpression de besoin et la MOE de corriger les bogues. Une version 2 de dploiement sur un site pilote donnera un retour dexprience suffisant la MOA pour rectifier une expression de besoin incomplte ou inadapte. En cas de rectification, une version 3 sera ralise pour le dploiement gnralis du service.
11.1 Planifier
149
150
On dcrit maintenant chaque tape de la dmarche de faon synthtique par lun des paragraphes ci-dessous, chaque description comprenant les rubriques suivantes : objectif de ltape dans la dmarche; description gnrale; lments en entre; livrable(s) de ltape (en prcisant si ncessaire quel(s) acteur(s) sadresse la livraison); acteur(s) responsable(s) ou participant(s) llaboration des livrables; outil(s); points clefs.
11.1.2
Objectif
Description gnrale
Lobjectif gnral est dtablir ou de faire voluer le plan dUrbanisme du SI en appliquant lapproche processus e-Business de lorientation SOA.
lment(s) en entre
stratgie mtier dvolution de lentreprise.
Livrable(s)
plan durbanisation : principes dvolution des processus mtier : spcifier le modle des vnements mtier pris en compte et larchitecture gnrale des processus associs; principes dvolution des fonctions mtier : en particulier, prciser les changes entre les diffrentes fonctions; principe dvolution des informations mtier : Spcifier le modle unifi (ou modle pivot) des objets mtier. Prciser larchitecture gnrale des rfrentiels associs : dcider de rpliquer ou non certaines informations, dcider dagrger certaines informations pour obtenir linformation pivot ; principes dvolutions technologiques du SI; indicateurs de performance (KPI : Key Performance Indicators) : performance mtier de chaque processus; performance technique gnrale des applications, des services et des rfrentiels;
11.1 Planifier
151
planification gnrale des volutions : livraison de tous ces livrables vers lquipe Programme SOA (pour quelle puisse dbuter ses travaux dorganisation et de planification), et vers la Direction Gnrale pour vrification de ladquation avec la stratgie de lentreprise.
Acteur(s)
quipe Urbanisme. quipe programme SOA (ds sa mise en place).
Points clefs
1 Cette tape utilise une dmarche moderne durbanisation du SI. Cette dmarche sappuie sur un rfrentiel mthodologique durbanisation gnral1, et applique les recommandations du prsent livre, notamment le chapitre 4 SOA et Urbanisation et le chapitre 9 Modlisation des Processus Mtier .
11.1.3
Objectif
Description gnrale
Cette tape a pour premier objectif dtablir la rpartition des travaux mener en une ou plusieurs solutions mtier, une ou plusieurs quipes dadaptation du SI existant, et/ou en une ou plusieurs quipes de dveloppement de service. Cette rpartition dpend des paramtres classiques en gestion de projet : charge de travail et dimensionnement taille humaine des quipes; dlai envisag; comptences ncessaires. Le deuxime objectif est de prciser le primtre de chaque solution mtier, et de fournir les moyens de tester chaque solution. Le troisime objectif est de spcifier les services mtier rutilisables dvelopper. Le quatrime objectif est de prciser si et comment les solutions mtier cooprent et sintgrent entre elles. Le cinquime objectif est de spcifier les services techniques attendus du framework SOA.
1. Tel que celui dcrit dans [Le Projet durbanisation du SI/C Longp/DUNOD diteur/2004].
152
lment(s) en entre
Plan durbanisation.
Livrable(s)
Primtre des solutions mtier : pour chaque solution mtier : modle du ou des processus mtier impliqus, use cases des applications composites interactives, fiche de description des Services Applicatifs associs aux applications; pour chaque solution mtier : liste des contraintes non fonctionnelles (NFR) pesant sur les processus et les applications. Liste des services mtier rutilisables : pour chaque service mtier, fiche de description du service; cration et mise jour de la matrice de rutilisation des services. Liste des adaptations du SI existant : pour chaque service mtier lgataire, fiche de description du service. Liste des fonctionnalits attendues du framework SOA, en particulier liste des services techniques : pour chaque service technique, fiche de description du service. Pour chaque Solution Mtier, cahier de recette mtier et jeux de tests associs.
Acteur(s)
quipe Urbanisme. quipe programme SOA. quipe Architecture Applicative.
Points clefs
1 La matrice de rutilisation des services liste les services, et en face de chaque service, positionne les solutions et/ou les services de plus haut niveau utilisant ce service. Cette matrice permet de suivre le niveau de rutilisation globale des services, et met en vidence des anomalies analyser (un service utilis par aucune solution, ou une solution nutilisant que des services qui lui sont ddis).
11.1.4
Objectif
Description gnrale
Lobjectif de coordination inclut les tches suivantes : Planifier lensemble des travaux, dfinir les tches (WBS) et dfinir les livrables.
11.1 Planifier
153
Organiser les diffrentes quipes de ralisation, affecter les tches. Prciser le cycle de vie logiciel et synchroniser les quipes : Organiser les runions (comits de suivi, runions de travail). Communiquer (mise jour de lintranet projet, modrer les forums sur le wiki, publier une lettre dinformation, etc.). Suivre les livraisons des diffrentes quipes vers lquipe Intgration. Grer le budget du programme SOA (si ncessaire, grer la sous-traitance). Organiser le changement culturel, notamment mettre en place un plan de formation adapt au contexte (les comptences existantes au sein de la direction informatique et au sein de la MOA) et la cible (les comptences acqurir). Organiser le dploiement des outils et plates-formes ncessaires la modlisation, au dveloppement, lintgration et la qualification des solutions, services et framework SOA. Contrler la qualit : Organiser les revues orientes qualit (revues darchitecture, de code, de documentation). Organiser les revues orientes rutilisation. Organiser les recettes (recettes fonctionnelles, qualification de pr production). Organiser le suivi des Fiches de Fait Technique (cest--dire les corrections danomalies et les demandes dvolution). Grer et animer la communication avec toutes les parties concernes.
lment(s) en entre
Les diffrents livrables des tapes du projet.
Livrable(s)
Planning tenu jour. Budget tenu jour. Plan qualit tenu jour (ce document prcise lorganisation, les points de synchronisation, le cycle de vie, les moyens et outils de contrle de la qualit, etc.). Lettre dinformation priodique.
Acteur(s)
quipe programme SOA.
Outil(s)
Intranet projet (publication des documents, accs aux outils de gestion des anomalies, accs aux rapports de tests, etc.).
154
Wiki de dialogue entre les diffrents intervenants. Outil de planification de projet (permettant le suivi du reste faire). Outil de suivi budgtaire.
Points clefs
1 La description qui prcde repose sur la rgle suivante : Rgle : le responsable MOE du programme SOA doit avoir la responsabilit globale de larchitecture SOA, des solutions mtier, des services, de larchitecture applicative et de linfrastructure spcifique SOA. Lexprience montre que, trop souvent, pour des raisons historiques ou politiques, certaines quipes ne sont pas rattaches au responsable du programme, or ces drogations sont toujours sources de dsagrment, car elles favorisent les classiques parties de ping-pong ce nest pas ma responsabilit, mais la sienne . Pour combattre ce facteur dentropie, il y a au moins une rgle respecter : Rgle : lquipe Intgration doit tre rattache au responsable du programme SOA, pour lui permettre de vrifier le bon avancement des travaux de tous les intervenants dans le programme. 2 Autre point clef important, qui est galement une source potentielle de dsagrment (point non spcifique SOA, mais que SOA rend plus critique) : le suivi du reste faire nest pas uniquement le suivi des charges ncessaires pour terminer les dveloppements, mais aussi le suivi du reste industrialiser . Autrement dit, une solution mtier ou un service ne sont considrs comme termins quune fois intgrs, qualifis et dbogus.
11.1.5
Objectif
Description gnrale
Lobjectif principal est de sassurer que lensemble des composants de la solution mtier sera livr en respectant dlais, cots et adquation aux besoins. Le responsable de la solution mtier est donc un chef dorchestre sassurant que chaque fournisseur de composant livre en temps et en heure. La ralisation de certains de ces composants (services mtier, framework SOA) est dlgue dautres quipes, pour maximiser la rutilisation de ces composants et lutilisation des comptences.
11.1 Planifier
155
Dautres composants peuvent tre directement pris en charge par lquipe solution : Application composite. Processus mtier. Certains services mtier, soit parce quils sont spcifiques de la solution (Services Applicatifs) soit parce quils ne sont pas encore dvelopps (services Fonctionnels) cf. ci-dessous le paragraphe points clefs de lorganisation .
lment(s) en entre
Spcification du primtre de la solution. Services mtier rutilisables (pour chaque service : spcification puis service bouchon dans un premier temps, service oprationnel dans un second temps). Framework SOA et outillage associ. Formation spcifique sur le framework et loutillage. Plate-forme de dveloppement, plate-forme de tests. Fiche(s) de Fait Technique concernant la solution, mise(s) par lquipe Intgration (lors du droulement du programme).
Livrable(s)
Lensemble des composants de la solution. Les composants sont assembls, tests, packags, documents. Livraison lquipe Intgration avec un bordereau de livraison rcapitulant les composants livrs et leur numro de version, les Fiches de Fait Technique prises en compte dans la livraison, etc. Fiche(s) de Fait Technique concernant les services mtier ou le framework SOA ou linfrastructure SOA : livraison aux quipes concernes et lquipe Programme SOA (pour impact budget/planning).
Acteur(s)
quipe Solution Mtier. quipe(s) Services Mtier (fournisseur(s) de composants mtier). quipe Architecture Applicative (fournisseur du framework SOA et de ses composants techniques, et des outils associs).
Points clefs
1 Le dveloppement dune solution mtier peut parfaitement rutiliser les mthodes et outils classiques dans le monde objet (SOA ne rinvente pas la roue sur ces sujets) : Contrle des risques et de la qualit totale avec CMMI. Dmarche itrative avec UP. Modlisation avec UML, complt avec BPMN pour les processus.
156
11.1.6
Objectif
Description gnrale
Lobjectif principal est de concevoir, coder et tester le service mtier et ses oprations.
lment(s) en entre
Fiche de description du service raliser. Framework SOA et outillage associ. Formation spcifique sur le framework SOA et loutillage. Fiche(s) de Fait Technique concernant le service, mise(s) par les quipes Solution utilisatrices ou lquipe Intgration (lors du droulement du programme).
Livrable(s)
Description WSDL du service : livraison lquipe durbanisme et lquipe dintgration pour vrifier le respect du contrat de service, livraison aux solutions mtier pour prparer et/ou vrifier la conception de leurs composants. Implmentation bouchon : livraison aux solutions mtier pour leurs tests. Implmentation oprationnelle : livraison aux solutions mtier pour leurs tests, livraison lquipe intgration. Fiche(s) de Fait Technique concernant le framework SOA ou linfrastructure SOA : livraison lquipe concerne et lquipe Programme SOA (pour impact budget/planning).
Acteur(s)
quipe service mtier . quipe urbanisme (contrle voire participation la conception du service).
Points clefs
Rgle : livrer un service bouchon aussi rapidement que possible aux solutions mtier utilisatrices, si possible en mme temps que la publication officielle du contrat de service WSDL.
11.1.7
Objectif
Adapter un systme existant son utilisation dans une solution mtier SOA.
11.1 Planifier
157
Description gnrale
Lobjectif est de fournir un service daccs un systme existant (cf. chapitre 7.4 zoom sur les systmes existants ). Cela implique dans certains cas de faire voluer le systme lui-mme. Lurbanisation puis ltude darchitecture SOA se seront assures de la faisabilit (technique et conomique) de ces volutions.
lment(s) en entre
Plan durbanisme et architecture SOA (spcification des adaptations). Fiche de description du service raliser (pour concevoir le service). Framework SOA et outillage associ (pour raliser le service). Formation spcifique sur le framework SOA et loutillage. Fiche(s) de Fait Technique concernant le service, mise(s) par les quipes Solution utilisatrices ou lquipe Intgration (lors du droulement du programme).
Livrable(s)
Description WSDL du service : livraison lquipe durbanisme pour vrifier le respect du contrat de service, livraison aux solutions mtier pour prparer et/ou vrifier la conception de leurs composants. Implmentation bouchon : livraison aux solutions mtier pour leurs tests. Implmentation oprationnelle : livraison lquipe intgration. Fiche(s) de Fait Technique concernant le framework SOA ou linfrastructure SOA : livraison lquipe concerne et lquipe Programme SOA (pour impact budget/planning).
Acteur(s)
quipe de maintenance du systme existant. quipe urbanisme (contrle voire participation la conception du service).
Points clefs
1 La livraison de service bouchon est encore plus sensible dans ce contexte daccs un systme existant. Il est en effet frquent que, vu le cot dinstallation de ces services, les solutions mtier attendent la phase dintgration pour se confronter aux services dans leur version oprationnelle. 2 Ces adaptations sont confies aux quipes charges de la maintenance des systmes existants. Compte tenu des technologies en jeu, cest souvent la seule faon de faire, et cest de plus une source de motivation pour ces quipes, condition quelles soient correctement formes et accompagnes sur les nouvelles technologies et nouvelles architectures. Elles peuvent en retour apporter leur longue exprience des processus dindustrialisation du logiciel.
158
11.1.8
Objectif
Livrer aux quipes de ralisation un framework SOA, ses services techniques et ses outils.
Description gnrale
Lobjectif est dlaborer et de livrer aux dveloppeurs un framework permettant de raliser les applications et services SOA. Cet objectif implique soit de dvelopper soit de choisir (en les adaptant si besoin) des composants chez les diteurs ou dans le monde Open source, et dintgrer ces composants dans un tout cohrent. Cet objectif implique galement de dvelopper ou de choisir des outils de productivit pour faciliter la mise en uvre du framework.
lment(s) en entre
Spcification du framework (au dmarrage du programme). Fiche(s) de Fait Technique concernant le framework mise(s) par les autres quipes, en particulier lquipe Intgration (lors du droulement du programme).
Livrable(s)
Framework SOA. Outillage associ. Guide de mise en uvre et exemples de code. Formation spcifique sur le framework et loutillage. Fiche(s) de Fait Technique concernant linfrastructure SOA : livraison lquipe concerne et lquipe Programme SOA (pour impact budget/planning).
Acteur(s)
quipe Architecture Applicative (responsable). quipe(s) solution et/ou quipe(s) service , si lquipe leur dlgue la ralisation ou ladaptation de certains services techniques du framework (cf. paragraphe organisation ci-dessous). quipe Infrastructure SOA.
Points clefs
1 Le framework est la clef de vote des dveloppements : sa qualit est donc lune des conditions du succs de tout programme SOA. Il est ncessaire de minimiser les risques ds le dmarrage de ce programme. La mise au point du framework et de linfrastructure, mais aussi lapprentissage sur le terrain des bonnes pratiques SOA, le test des performances de linfrastructure sous-jacente constitue autant de raisons en faveur du dveloppement dun POC.
11.1 Planifier
159
Rgle : pour minimiser le risque framework , il faut dvelopper un prototype, ou POC (Proof Of Concept), sous forme dune solution mtier simplifie (mais raliste sur le plan mtier) centre sur la mise en uvre du framework et de linfrastructure logicielle et matrielle. Ce dveloppement doit, si possible, se faire en avance de phase par rapport au dmarrage des solutions mtier.
11.1.9
Objectif
Description gnrale
Lobjectif est de choisir, installer, paramtrer, qualifier et prparer lexploitation dune infrastructure SOA complte, aussi bien sur le plan logiciel (ESB, EII, cf. partie 6) que matriel (load balancing, cluster, etc.). Une telle infrastructure peut, pour des projets importants, inclure de nombreux composants. Cet objectif implique donc un travail important, dautant que ces outils sont nouveaux et ncessitent donc au pralable une appropriation culturelle intensive.
lment(s) en entre
Plan durbanisation (notamment orientations technologiques, listes des NFR). Spcification du framework (pour mettre en vidence des besoins particuliers en matire dinfrastructure : connecteurs particuliers, par exemple). Fiche(s) de Fait Technique concernant lInfrastructure SOA mise(s) par les autres quipes, en particulier lquipe Intgration.
Livrable(s)
Infrastructure SOA installe et paramtre sur les diffrentes plates-formes concernes. Outils (guide de mise en uvre) et formation lusage de lquipe Architecture Applicative et des quipes de dveloppement.
Acteur(s)
quipe infrastructure SOA.
Points clefs
1 Linstallation de cette infrastructure concerne lensemble des plates-formes du programme SOA : tests, intgration, qualification fonctionnelle, qualification technique, et bien sr production.
160
2 La mise au point de cette infrastructure potentiellement complexe milite galement en faveur dun POC (cf. paragraphe prcdent).
Description gnrale
Lobjectif est dintgrer chaque solution mtier, en effectuant les diffrentes catgories de test ncessaires, comme illustr par la figure 11.2.
OK
KO
Tests de pr-production
KO
Corrections
Les tests dassemblage permettent notamment de vrifier le respect des contrats de service par le client (la solution mtier) et par le fournisseur (le service). Les tests de Bon Fonctionnement mtier concernent : Pour les nouveaux composants : la vrification du respect des exigences mtier (pr-recette de prparation de la recette MOA). Pour les composants dj intgrs : la vrification de la non rgression fonctionnelle.
lment(s) en entre
Solution mtier installe sur la plate-forme dintgration, avec bordereau de livraison. Infrastructure SOA installe et paramtre sur la plate-forme dintgration. Cahier de recette mtier et jeux de tests associs.
11.1 Planifier
161
Livrable(s)
Fiche(s) de Fait Technique concernant la solution mtier, les services mtier utiliss, le framework SOA ou lInfrastructure SOA : livraison aux quipes concernes et lquipe Programme SOA (pour impact budget/planning).
Acteur(s)
quipe Intgration. quipes de dveloppement (assistance la mise en uvre de la solution et lanalyse des problmes). quipe Urbanisme (assistance aux tests mtier).
Points clefs
1 La solution mtier intgrer peut inclure des services mtier bouchons lorsquil sagit de services daccs aux systmes existants ou de services de communication avec une autre solution mtier. Ltape dintgration globale niveau SI prendra en charge la vrification de ces accs en vraie grandeur . Ceci afin dviter une synchronisation trop troite entre les diffrents dveloppements concerns. Cette dcision daccepter ou non des services bouchons est prendre au niveau Programme SOA.
Description gnrale
Lobjectif est de mettre en place une solution de type BAM et SAM, partir doutils BAM/SAM, en paramtrant ces outils (notamment en terme de profil daccs), et ventuellement en ralisant des dveloppements complmentaires.
lment(s) en entre
Plan durbanisation (notamment dfinition des KPI suivre). Infrastructure SOA installe et paramtre sur les diffrentes plates-formes concernes (les outils de BAM/SAM sappuieront sur des composants de cette infrastructure).
Livrable(s)
Infrastructure BAM et SAM installe et paramtre sur les diffrentes platesformes concernes. Outils (guide dutilisation) et formation lusage des utilisateurs finaux et des quipes de production.
162
Acteur(s)
quipe Solution BAM/SAM cette quipe peut ou non faire partie de lquipe architecture applicative. quipe Infrastructure.
Points clefs
1 On parle ici de solutions BAM/SAM, et non pas uniquement doutils BAM/SAM. Lexprience montre en effet que les outils disponibles dans linfrastructure SOA doivent tre en gnral complts/adapts : par exemple, un outil de BAM doit, pour des raisons ergonomiques, tre intgr dans la Corbeille des responsables (cf. tableau 9.1). Autre exemple, il peut tre ncessaire de mettre en place un vritable portail orient SAM, permettant de consulter en temps quasi rel la performance de chaque service.
Description gnrale
Le premier objectif est de vrifier que les solutions mtier coexistent sans effet de bord au sein du SI. Le deuxime objectif est de vrifier que chaque solution mtier accde correctement aux systmes existants via les services concerns (cest--dire quon teste les solutions mtier non plus avec les services bouchons mais avec les vrais services daccs). Le troisime objectif est de vrifier que les solutions mtier devant communiquer entre elles (via lESB) le font correctement. Le quatrime objectif est de vrifier le bon fonctionnement de certains services techniques transverses au niveau SI, ce qui implique notamment : Les tests dvaluation des outils de scurit (cf. partie 4 pour une prsentation des normes et outils de la scurit dans un contexte SOA). Les tests dvaluation des solutions de rplication.
lment(s) en entre
Solutions mtier installes sur la plate-forme dintgration, avec bordereau de livraison. Infrastructure SOA installe et paramtre sur la plate-forme dintgration. Cahier de recette mtier et jeux de tests globaux.
11.2 Organiser
163
Livrable(s)
Fiche(s) de Fait Technique concernant les solutions mtier, les services utiliss, ou lInfrastructure SOA : livraison aux quipes concernes, lquipe Urbanisme, et lquipe Programme SOA (pour impact budget/planning).
Acteur(s)
quipe Intgration. quipes de dveloppement (assistance la mise en uvre des solutions et lanalyse des problmes). quipe Urbanisme (assistance aux tests mtier et lanalyse des problmes globaux).
11.2 ORGANISER
11.2.1 Acteurs
Les principales quipes impliques sont (liste rcapitulative) : quipe(s) Solution mtier (dont quipe BAM/SAM) (SOL). quipe(s) Services mtier (SER). quipe(s) Maintenance des Systmes Existants (MAIN). quipe Architecture applicative et ateliers de mise en uvre (ARCH). quipe Architecture infrastructure (INF). quipe Administration des composants (ADM). quipe Intgration (INT). quipe Programme SOA (PROG). quipe Urbanisme (URBA). Sponsor Matrise dOuvrage (SPON). quipe Matrise dOuvrage (MOA).
11.2.2
Responsabilits
Le tableau 11.1 fournit le diagramme RACI de lorganisation. Pour chaque tape de la dmarche SOA, le diagramme prcise qui est Responsable, Acteur, Cooprant ou Inform. Le Responsable est celui qui contrle en dernier ressort les livrables de ltape, lActeur est celui qui produit les livrables, le Cooprant participe activement llaboration des livrables, lInform est inform des travaux et fournit si besoin des informations.
164
C C I
A A
I C C C I I C C C
I R C C C C C C C C C C C
A
I I I I I I I I
RA
I I I I C C C
RA
RA
I I C I C I I C I C
RA
C C I I
RA
I C I
RA RA RA
11.2.3
Coordination
La coordination implique classiquement la mise en place de comits priodiques : Comit de Programme SOA : gestion de la synchronisation des plannings et allocation de ressources, prise de dcision concernant les points durs. Comit durbanisation SOA : notamment suivi de la matrice solutions/services. Comit de suivi solution mtier : notamment suivi de lintgration progressive de la solution. Comit de suivi architecture : notamment suivi de la mise en place et de la mise au point du framework SOA et de linfrastructure SOA.
11.2.4
Communication
Lun des objectifs clefs de lutilisation de lapproche SOA est de maximiser la rutilisation de services (mtier et technique). Cela passe par le bon fonctionnement de la relation client fournisseur entre les quipes solution mtier (les clients), et les quipes services mtier et architecture applicative/framework (les fournisseurs). Or rutiliser ne se dcrte pas : si une quipe Solution na pas confiance dans les composants dun de ses fournisseurs, elle ne les rutilisera pas, quelles que soient les
11.3 Outiller
165
obligations qui pseront sur elle. Cest normal : on ne peut pas demander un responsable de Solution de sengager sur des dlais et des cots, et en mme temps lui imposer des freins ou ce quil peroit comme tel. Ce manque de confiance arrive trs souvent, car les informaticiens ne sont pas des adeptes naturels de la communication intensive : cette absence de communication, si elle nest pas combattue, impliquera que chacun interprte dans son coin les spcifications, ce qui conduit invitablement des incomprhensions1. Cette confiance fonctionne dans les deux sens : si un fournisseur saperoit quun client est de mauvaise foi (en tant atteint du syndrome NIH2, par exemple, ou en ne faisant pas leffort ncessaire dappropriation du composant fourni), cela dmotivera ce fournisseur. Crer les conditions de la confiance, tel est le point clef de la rutilisation. Cela passe par : Crer les opportunits de communiquer entre quipes : les comits ne suffisent pas, il faut galement des runions dinformation et dchanges rgulires. Organiser des changes culturels : un architecte va par exemple tre dtach quelques semaines dans une quipe solution pour adapter le framework de dveloppement. Autre exemple, un dveloppeur de lquipe Solution S1 va tre dtach dans une quipe Service Mtier pour dvelopper ou adapter un Service Mtier dont la solution S1 est la premire cliente . Ces changes sont trs efficaces, car ils nempitent pas sur les prrogatives des responsables dquipes fournisseur tout en rassurant les responsables clients sur la bonne prise en compte de leurs besoins. Mettre en place des outils simples comme support de la communication, tel un WIKI permettant dune part daccder simplement aux documentations disponibles, dautre part de consulter la roadmap des composants et solutions, et enfin de garder une trace des FAQ. Mais crer la confiance ne signifie pas laxisme. Lquipe Programme SOA doit mettre en place des revues priodiques darchitecture, permettant de contrler cette rutilisation.
11.3 OUTILLER
11.3.1 Le framework SOA
Le framework SOA est loutil de base pour concevoir et dvelopper les solutions et les services : il concrtise larchitecture applicative SOA.
1. Citons le cas caricatural mais hlas rel de la perte de la sonde Mars Climate Orbiter en 1999, parce quune quipe logicielle avait raisonn en mtre, et une autre en miles ! 2. NIH = Not Invented Here.
166
On rappellera quun framework comprend deux types de composants : Les composants gnriques : un tel composant est un squelette de code complter par le dveloppeur (dans le monde objet, on parlera de rutilisation par hritage) : comme exemple de composant gnrique, on citera le composant squelette de Service Applicatif , le composant squelette daction , etc. Les services techniques, prts lemploi aprs paramtrage : comme exemple, on citera le service log , le service impression de rapport , le service verrouillage mtier , etc. Le framework SOA est lui-mme compos de (sous) frameworks : Le framework CAF ddi aux Applications Interactives. Le framework ddi aux Processus Mtier, bas sur un moteur dorchestration BPEL. Le framework Services, notamment en ce qui concerne les services CRUD (orient objet mtier racine) et les accs aux rfrentiels. ventuellement, un framework orient Rgles de Gestion IF, THEN, ELSE.
11.3.2
Les outils
Pour faciliter la mise en uvre de ce framework, et garantir un niveau de productivit suffisant, il faut mettre en place un outillage complet. La figure 11.3 prsente un panorama gnral des ateliers logiciels mettre en place au sein de ce quon peut baptiser de chane de fabrication SOA. Latelier de Modlisation comprend lensemble des diteurs de modlisation graphiques (UML, BPMN, formalisme propritaire.) ou textuels (diteur XML). Latelier de Production comprend lensemble des outils de dveloppement manuel et de gnration automatique de code1. Latelier de Composition comprend lensemble des outils permettant dassembler les composants partir dautres composants. Latelier dHomologation comprend lensemble des outils de tests permettant de tester et qualifier les composants SOA, en particulier les services.
11.3.3
La productivit obtenue laide de cette chane de fabrication SOA est un lment clef du succs de lapproche SOA telle que dcrite dans ce livre. Il ne saurait tre question que les avantages dune telle approche soient obtenus au dtriment de cette productivit, partir du moment o les investissements consentir sont raliss.
1. Exemples : ECLIPSE, RAD, NETBEANS, VISUAL STUDIO.NET, etc.
11.3 Outiller
167
Chane de fabrication SOA SOA Atelier de Modlisation Atelier de Composition Atelier de Production Atelier dHomologation Service Service Service Service
Service
CRUD CRUD
Il est donc logique que lapproche architecturale SOA se rapproche de lapproche MDA, Model Driven Architecture. Il ne sagit pas ici de cder la tentation du mariage futuriste de deux acronymes trs la mode en ce dbut de XXIe sicle, mais bien dtudier comment, en restant pragmatique, il est possible dorienter les ides MDA vers la gnration de composants SOA.
La dmarche MDA prne la gnration automatique de code partir de modles UML. Plus prcisment, il sagit, partir de modles UML reprsentant le mtier informatiser (modles PIM : Platform Independant Model), de raffiner par tape ces modles pour en faire des modles PSM ( Platform Specific Model) permettant in fine une gnration de code complte, sans passer par ltape criture de logiciel la main . Les modles PIM sont indpendants de toute technologie, les modles PSM sont associs une technologie cible (Java/Swing/RMI, J2EE/Spring, J2EE/EJB, VB/ .NET, etc.).
168
Modles graphiques
DSL
Composants logiciels
Processus BPMN
BPEL
Coordinateur
Use Case
Diagramme Activit
Service
CRUD
par le moteur dorchestration de processus (BPM). Dautre part, il met en vidence les applications interactives ncessaires pour faire intervenir lhomme dans la boucle (cf. chapitre 9 et ses exemples de processus BPMN). Toute application interactive est dcrite son tour, par un diagramme de Cas dUtilisation, dcrivant linteraction entre lutilisateur et la solution. Elle est associe : Un diagramme dactivit dcrivant le comportement du Coordinateur de lapplication, cest--dire la cinmatique de navigation entre les vues de lapplication et les services appels (cf. chapitre 10) lors des interactions utilisateur solution. Un diagramme de classe listant et dcrivant les services appels (Services Applicatifs/Services Fonctionnels). Les applications interactives dune mme solution sont galement associes un diagramme de classe modlisant les objets mtier utiliss.
Modles PSM
partir de ces modles graphiques, il est possible de gnrer les modles PSM. La dmarche propose est lgrement diffrente dune approche MDA centre sur UML :
169
en effet, le modle PSM dun composant nest pas un modle UML annot, mais un document XML obissant une syntaxe spcifique du type de composant concern1. Par exemple, chaque Vue pourra tre dcrite par un fichier au format XFORMS ou XUL, tandis que chaque Coordinateur sera dcrit par un graphe de navigation XML au format jsf-config.xml. Les diagrammes de services permettent de gnrer les contrats dinterface WSDL. partir de ces contrats, il est galement possible de composer des services de plus haut niveau, via un diteur SCA. Le modle des Objets Mtier quant lui permet de gnrer les Services CRUD daccs aux rfrentiels. Il permet galement denrichir les Vues gnres (le typage des attributs dun objet mtier permet de gnrer le contrle de saisie correspondant)2.
11.4.1
Cela explique lapparition puis le succs de modle de maturit, dont le plus connu est le modle CMM-I (Capability Maturity Model Integrated). Un modle de maturit dfinit dune part les capacits quune organisation (une direction informatique, une SSII, etc.) doit acqurir pour matriser un certain type de comptence informatique, et dautre part dfinit les niveaux de maturit que cette organisation atteindra successivement, permettant ainsi den mesurer les progrs. La dfinition dun tel modle dans le contexte SOA est dautant plus ncessaire quil sagit dune volution, voire une rvolution, dans la faon dapprocher le Systme dInformation dune entreprise. Des travaux ont vu rcemment le jour pour
1. Ces syntaxes spcifiques sont autant de DSL (Domain Specific Language). Dans la mesure o ces langages sont dclaratifs et non programmatiques, il sagit cependant bien dune dmarche respectant lesprit MDA. Il ny a pas lieu dopposer lapproche DSL (dfendue par MICROSOFT) de lapproche MDA (dfendue par le reste du monde regroup dans lOMG). 2. Le lien entre fichiers XML Vue et fichier XML mta modle mtier nest pas reprsent sur la figure 11.4 pour ne pas la surcharger.
170
dfinir un modle de maturit appliqu au contexte SOA. On citera par exemple les travaux dIBM1 et de MICROSOFT2. Lexprience des auteurs les a conduits dfinir un modle de maturit SOA, baptis PSAUMM : Practical, Service-oriented Architecture, Unified Maturity Model. Ce modle est compos de 5 axes de progression, comme le met en vidence la figure 11.5.
PSAUMM Practical, Service-oriented Architecture Unified Maturity Model
Gouvernance
Capacits dfinir, garantir et anticiper la Qualit de Service Capacits modliser et construire des services par assemblage et orchestration Capacits dvelopper, dployer et maintenir rapidement des services performants Capacits publier, partager et grer des services rutilisables Capacits modliser, construire et publier des services fiables
Flexibilit
Productivit
Rutilisation
Interoprabilit
La progression se fait sur ces axes de faon indpendante, selon la situation initiale et les objectifs de lentreprise.
PSAUMM et CMMI
On notera que lobjectif de PSAUMM est dvaluer la maturit de larchitecture SOA mise en place. Ce type de modle est donc parfaitement complmentaire de CMMI, qui lui a pour objectif dvaluer la maturit des quipes dans la matrise du cycle de vie logiciel. Il est probable que le modle CMMI aura une dure de vie suprieure un modle de maturit orient Architecture, si lon en juge par lhistoire de linformatique depuis 30 ans. Cest dailleurs une raison suffisante pour distinguer un modle de maturit orient gnie logiciel et un modle de maturit orient architecture SOA 3. La suite du chapitre dcrit les niveaux de maturit du modle et les capacits associes.
1. Modle SIMM = Service Integration Maturity Model cf. par exemple : SOA compliance : initial steps in a longer journey/J. Falkl et alii/www.ibm.com/dcembre 2005. 2. Modle ESOMM = Enterprise Service Orientation Maturity Model cf. par exemple : Enable the Service Oriented Enterprise/William Oellermann/The MS Architecture Journal, no 7/avril 2006. 3. Certains modles de maturit SOA essaient en effet de modifier directement CMMI en lui faisant prendre en compte des aspects architecturaux prcis. Ce nest clairement pas lorientation de PSAUMM et des modles de ce type.
171
11.4.2
Le modle PSAUMM
Le modle comprend 3 niveaux de maturit, comme le montre la figure 11.6. Cette figure liste galement les capacits mises en jeu en fonction de laxe de progression et du niveau de maturit.
Niveau 0 Pr SOA
ESB synch
ESB asynch EAI Gouvernance > SLA interne > SAM basique > Concept de contrat > Composition locale > Atelier & framework > Cycle dv > Services CRUD > Atelier tests Rutilisation > Langage pivot Interoprabilit > SLA externe > BAM > SAM / Portail > Orchestration BPEL + Services Workflow > Asynchronisme > Atelier / Modlisation BPMN > Cycle dploiement > Versionning > Testabilit des Processus > WSDL, SOAP > CAF > Cycle volution SLA > SOA capacity planning > Composition & Paramtrage SCA > MDM > Atelier / DSL + Gnration de code > Cycle volution > Annuaire de services > ESB > WS Policy / Security
Flexibilit
Productivit
Le niveau 0 correspond la situation initiale des entreprises ayant dune part entrepris un effort durbanisation de leur systme (EAI) et dautre part ayant adopt les technologies Objet pour le dveloppement de leurs nouvelles applications. Le niveau 1 correspond la situation dmergence des services mtier au sein des nouvelles applications, la mise en place des capacits de dveloppement rapide, et la mise en place de la dmarche dcrite dans le prsent chapitre. Le niveau 2 correspond la mise en place des processus e-business, la mise en place des capacits dintgration et de dploiement rapide, et louverture du systme dinformation. Le niveau 3 correspond la gnralisation de lapproche SOA au systme dinformation, la capacit dvolution des services rutiliss, et la capacit danticiper sur le dimensionnement du systme en fonction des besoins mtier.
172
11.4.3
On dcrit dans ce sous-chapitre les diffrentes capacits acqurir progressivement. On notera une rgle intangible : Rgle : lacquisition des capacits PSAUMM implique la mise en place concomitante dun vritable plan de formation et daccompagnement.
Axe Interoprabilit
La premire capacit acqurir sur cet axe concerne la mise en place dun premier ensemble de services CRUD : cet objectif implique la dfinition dun langage pivot , bas sur la modlisation des Objets Mtier accds via les Services. La deuxime capacit concerne la matrise des Web Services, ncessaires dune part louverture du systme dinformation, et dautre part la mise en uvre des Processus e-Business. Cette capacit peut tre ncessaire ds le premier niveau de maturit architectural, en fonction des objectifs gnraux de lentreprise. La troisime capacit concerne la matrise de larchitecture des Applications Composites : cela implique la comprhension des concepts de Contexte et de Transaction longue, et la mise en place dun framework (CAF). La quatrime capacit concerne le dploiement dun ESB complet, tel que dcrit au chapitre 17. La cinquime capacit concerne la matrise des aspects avancs de SOA, notamment dans le domaine de la scurit.
Axe Rutilisation
La premire capacit acqurir sur cet axe concerne la mise en place dun atelier dhomologation orient vers les tests des services dvelopper : lobjectif est de garantir le niveau de qualit des services prsents comme rutilisables. La deuxime capacit concerne la matrise du versionning des services. La troisime capacit concerne la matrise des tests des Processus. Elle sappuie sur la premire capacit de cet axe, mais implique en sus un travail sur les plates-formes de test et dintgration, les jeux de tests et les outils despionnage des Processus. La quatrime capacit concerne la publication des services dans un annuaire de Services.
Axe Productivit
La premire capacit acqurir sur cet axe concerne la mise en place dun atelier de fabrication, orient objet. Latelier est organis autour dun rfrentiel permettant de grer les versions des composants et les configurations des solutions mtier obtenues par assemblage des composants.
173
La deuxime capacit concerne la dfinition dun cycle de dveloppement des composants SOA. Ce cycle dfinit les modalits de travail en quipe (en lien avec la mise en place du rfrentiel voqu prcdemment). La troisime capacit acqurir sur cet axe concerne la possibilit de gnrer tout ou partie des services CRUD partir dune description des Objets Mtier. La quatrime capacit a pour objectif la mise en place dun atelier permettant la modlisation de Processus et la gnration du code BPEL associ. Cet atelier permet galement de grer le versionning des modles. La cinquime capacit concerne la dfinition dun cycle dintgration et de dploiement. Complment du cycle de dveloppement, ce cycle dfinit les diffrentes tapes menant des tests unitaires au dploiement oprationnel. Il affine le cycle prsent par la figure 11.2. La sixime capacit a pour objectif la mise en place dun atelier de Composition de services et dapplication composite interactive. Cet atelier inclut les diteurs XML permettant dditer ou de modifier les fichiers DSL voqus au sous-chapitre Outillage. La septime capacit concerne la dfinition du cycle dvolution (maintenance corrective, maintenance volutive) des solutions mtier et des services. Ce cycle prcise galement la procdure utiliser en cas durgence (correction dun bogue bloquant la production).
Axe Flexibilit
La premire capacit acqurir sur cet axe concerne la matrise du concept de contrat de service. Il correspond lmergence dun ensemble de services, en gnral les services CRUD (cf. axe Interoprabilit). La deuxime capacit concerne lapprentissage de la composition de services en utilisant des outils dInjection de Dpendance tels que SPRING1. On parlera de composition locale de service puisque ce type doutil ne sait composer que des services Java. La troisime capacit concerne la mise en place dune infrastructure de gestion de processus mtier SOA, incluant la prise en compte de la dimension humaine. La mise en place de processus mtier faisant appel des systmes existants peut induire lutilisation dune messagerie asynchrone, ou MOM, ou linterfaage avec un EAI asynchrone existant. La quatrime capacit porte donc sur la matrise de lasynchronisme dans une architecture SOA. La cinquime capacit concerne la matrise de la composition gnralise de services, matrise permettant in fine la mise en place dune taxonomie de services de grain plus ou moins fin. Cette matrise implique la mise en place dun atelier de composition de services orient SCA.
1. Cf. la prsentation de la relation entre SPRING et SCA, partie 4, chapitre 14.
174
La sixime capacit concerne la mise en place dun outil de rplication + agrgation de type EII ou MDM1. Cette capacit est optionnelle, car elle dpend de larchitecture SOA mettre en place, elle-mme dpendante de lurbanisation du SI. La septime capacit concerne lusage dun moteur de rgles (BRMS2) bas sur le rfrentiel MDM et permettant de constituer une chane dagilit intgre depuis le BPM.
Axe Gouvernance
La premire capacit acqurir sur cet axe concerne lapprentissage de la notion de SLA. Cette notion sera dploye dans un premier temps au sein du Systme dInformation de lentreprise. La deuxime capacit concerne la mise en place dun premier niveau de SAM. Cela peut passer par lobtention de traces de performance permettant danalyser et corriger les problmes survenus en production. La troisime capacit concerne la mise en place de SLA entre lentreprise et ses clients : ce niveau, un SLA nest plus uniquement un concept Technique mais galement un concept Business. La quatrime capacit concerne la mise en place dun portail SAM. Lide de base est de permettre un accs unifi un ensemble de statistiques de performances. Un tel outil permet aux responsables danticiper sur dventuels problmes en dtectant des dgradations plus ou moins progressives des performances de production. La cinquime capacit concerne la mise en place de capacits de BAM (intgrant un mode vnementiel de capture de lensemble des indicateurs de performance mtiers placs sur les processus mtiers), afin davoir le mme niveau de consolidation dinformation que pour le SAM, mais cette fois pour les mtiers. Ces capacits peuvent sintgrer au portail SAM prcdemment voqu, en fonction des outils utiliss et des utilisateurs cibls. Un SLA peut voluer au cours du temps. Par ailleurs un mme service peut avoir simultanment plusieurs niveaux de SLA selon le client du service. La sixime capacit vise matriser le cycle de vie des SLA notamment par lvaluation systmatique de limpact dun changement de SLA dun service sur les solutions utilisatrices. La gnralisation de la dmarche SOA, la multiplication des processus automatiss, laccs aux rfrentiels ou la duplication des informations, impliquent une monte en charge de linfrastructure SOA : la septime capacit a donc pour objectif de pouvoir anticiper sur cette monte en charge pour viter tout problme en production. Cette capacit peut impliquer la possibilit de simuler les processus mtier avant leur dploiement.
1. Cf. partie 3, chapitre 7, pour lintroduction cette problmatique, et partie 7, chapitre 20, pour la description de ces outils. 2. BRM (Business Rules Management System).
175
En rsum
Ladoption dune dmarche SOA implique la mise en place dun programme SOA, englobant Solution(s) Mtier, Services, Architecture et Infrastructure. Une rflexion sur la planification et lorganisation de ce programme simpose alors. Cette adoption ne pourra se faire que progressivement : do lutilit dvaluer la maturation de cette adoption en utilisant un modle de maturit bas sur les capacits : PSAUMM (Practical, Service-oriented Architecture, Unified Maturity Model). Ce modle dcrit la maturit de larchitecture SOA progressivement mise en place, et est donc parfaitement complmentaire du modle CMMI. Enfin, il est ncessaire de rflchir la productivit des dveloppements : il nest pas possible de sacrifier la productivit pour rechercher les bnfices de lapproche SOA en terme de flexibilit des processus mtier et de rutilisation de lexistant.
QUATRIME PARTIE
178
La figure suivante prsente la pile des grammaires Web Services regroupes en couches. Les cinq couches sont les suivantes : Les normes fondamentales pour la mise en uvre des Web Services (SOAP, WSDL, UDDI). Les spcifications qui rpondent aux exigences de scurit, de garantie dacheminement et dintgrit transactionnelle. Les spcifications qui permettent le pilotage et la supervision des services.
179
Les spcifications permettant la coordination ou la composition des services. Les spcifications qui permettent la prsentation des services. Cette reprsentation repose sur la vision GXA de Microsoft et IBM. Les couches gris clair (scurit, garantie dacheminement, intgrit transactionnelle, supervision, coordination/composition) de cette figure sont les plus rcentes et les moins stabilises.
Prsentation (WSRP)
Composition & Coordination (WS-*) Normes / Drafts OASIS & autres Pilotage (WS-*) Garantie dacheminement (WS-*)
Transactions (WS-*)
Scurit (WS-*)
La figure fait apparatre les normes crites par le Consortium W3C, aujourdhui stabilises et reconnues par tous les acteurs du monde informatique. Elle prsente aussi les spcifications en cours dcriture par divers groupes de normalisation pas toujours daccord entre eux. Par consquent, il est souvent risqu demployer une de ces spcifications sans avoir valu sa compatibilit avec les autres. La maturit et le caractre oprationnel de chacune de ces spcifications seront voqus dans les chapitres correspondants.
12
Linfrastructure de base
Objectif
Ce chapitre aborde les couches basses des Web Services (cf. figure 12.1), cest--dire : La communication avec SOAP. La description dun contrat de service avec WSDL. Lannuaire des services UDDI. Pour chacune dentre elles, il prsente dabord les objectifs qui ont pilot lcriture des spcifications, puis lvolution des usages conscutifs aux retours terrains.
Prsentation (WSRP)
Composition & Coordination (WS-*) Normes / Drafts OASIS & autres Pilotage (WS-*) Garantie dacheminement (WS-*)
Transactions (WS-*)
Scurit (WS-*)
182
XML-RPC1 date de 1995. Cest une technologie dinvocation de service distance base sur XML et HTTP, donc indpendante du langage dimplmentation. Son mode de fonctionnement consiste en linvocation distance dune mthode de classe objet. Pour mener bien cette invocation dans un environnement Internet, la signature de mthode est traduite en XML et les paramtres sont passs selon le mme principe. Si lon considre le service de demande dintervention prsent dans le fil rouge, la requte XML-RPC permettant de demander ltat davancement dune demande prendra ainsi la forme suivante :
<?xml version="1.0" ?> <methodCall> <methodName>ServiceIntervention.recupererEtatDemande</methodName> <params> <param> <value><i4>42</i4></value> </param> <param> <value><i4>108</i4></value> </param> </params> </methodCall>
On retrouve entre les balises <methodName> le nom de la mthode permettant de rcuprer ltat de la demande dintervention et entre les balises <value> la valeur de lidentifiant de la demande (<i4> signifie que le paramtre est ici un entier). XML-RPC connat une dizaine de types trs primitifs, ce qui en fait une grammaire simple apprhender, mais trs rudimentaire en terme de capacit dinvocation. Par ailleurs, la technologie ne propose pas de notion de description de linterface du service : ainsi les 2 parties impliques dans linvocation doivent se concerter pour se mettre daccord sur ladresse du service, ses mthodes, ses paramtres, etc. De plus, il ny a pas non plus de normalisation des erreurs dans XML-RPC. Cette technologie est donc utilise aujourdhui dans des cas trs simples, mais inadapte des architectures distribues complexes.
1. RPC signifie Remote Procedure Call.
183
12.1.2
SOAP a t conu partir de 1998, afin dtendre les possibilits de XML-RPC. Lacronyme signifie Simple Object Access Protocol, cest--dire protocole simplifi pour laccs des objets distants. SOAP a t pens dune part pour tre indpendant de limplmentation technique du service, dautre part pour passer au travers des firewalls, et ainsi permettre linvocation de services situs dans des Systmes dInformation partenaires. SOAP gre lchange de messages XML : cest la couche basse des architectures Web Services. Ce protocole applicatif peut sappuyer sur diffrents protocoles de transport pour des changes synchrones ou asynchrones (cf. Partie 1) : HTTP : changes synchrones; Java RMI : changes synchrones; .NET Remoting : changes synchrones; SMTP : changes asynchrones; FTP : changes asynchrones; Java JMS : changes asynchrones; .NET MSMQ : changes asynchrones; etc. Par ailleurs, SOAP dsigne les informations changes dans une syntaxe correspondant aux fonctions applicatives, contrairement XML-RPC qui utilise uniquement des nommages techniques et primitifs. De plus, SOAP permet la srialisation/dsrialisation de tout objet mtier, sous une forme XML utilisable quelle que soit la technologie dimplmentation. Enfin, SOAP normalise la gestion des erreurs.
12.1.3
Fonctionnement de SOAP
Le message SOAP est compos de deux parties : La partie Header porte des informations complmentaires pour le traitement des donnes (identification de lmetteur du message, rgles de scurit pour la lecture du message, algorithme de chiffrement utiliser pour la lecture du message, etc.). La partie Body porte les donnes propres au message, et matrialise la requte ou la rponse SOAP (structure de donnes spcifique). Lexemple suivant prsente, dans le cadre du fil rouge, la demande davancement sur une intervention en SOAP :
184
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <recupererEtatDemande> <NumeroDistributeur>42</NumeroDistributeur> <NumeroDemande>108</NumeroDemande> </recupererEtatDemande > </soap:Body> </soap:Envelope>
On constate dans lexemple que la lecture du message SOAP est relativement aise par un humain grce la souplesse du langage XML qui permet un nommage proche des fonctionnalits mtiers. La figure 12.2 rcapitule le fonctionnement de SOAP.
Message SOAP Enveloppe SOAP SOAP Header XML SOAP Body XML Couche de Transport : HTTP, SMTP, etc. Traverse les firewalls
Invocation du service
Interface Web Service Technologies propritaires C, C++, Java VB, C#, PHP, Perl, Cobol, etc.
Composants mtiers
12.1.4
Si les messages XML utiliss dans SOAP sont facilement lisibles par des humains, ils sont assez verbeux ce qui entrane des problmatiques en terme de performance : Dune part, le poids dun message SOAP (cod en mode texte) est beaucoup plus important quun message cod en binaire, ce qui a un impact sur son temps dacheminement.
185
Dautre part, le travail de construction et de lecture du message par les applications impliques dans la communication est gourmand en terme de temps processeur. Lorsque HTTP est le protocole de transport utilis avec SOAP, on peut rsoudre cette problmatique de performance avec des botiers acclrateurs XML. Le rle de ces botiers est de dcharger les middlewares dintgration des tches de gestion des flux XML. Compte tenu du cot dune telle solution, on prfre souvent remplacer HTTP par un protocole propritaire mais plus performant comme RMI avec Java. Cette stratgie nest possible que lorsque la problmatique dinteroprabilit nest pas prsente, cest--dire lintrieur du SI. Par ailleurs, certains dveloppeurs reprochent SOAP la complexit de sa syntaxe et se tournent vers du Plain Old XML ou XML simple et basique. Ces personnes mettent alors en uvre XML-RPC ou REST.
12.1.5
REST signifie REpresentational State Transfer. Il dsignait lorigine un principe darchitecture bas sur la distribution de mdias lis entre eux par des hypertextes ( la manire du Web). Aujourdhui, le terme est employ pour dsigner une architecture dintgration de services allge. REST est en effet beaucoup plus simple que SOAP. Il utilise les diffrentes mthodes du protocole HTTP (GET, POST, PUT, et DELETE) pour consulter ou mettre jour des donnes distantes. Ainsi le nombre de verbes (mthode du protocole applicatif) nest pas extensible contrairement SOAP mais directement li aux verbes du protocole de transport. REST nest pas proprement parler un protocole dinvocation distance : il sagit essentiellement dun protocole destin des services CRUD (cf. Partie 3) utilisant des messages XML pour laccs des ressources distantes. Par ailleurs, REST affecte une adresse URI1 chacune des ressources accder. De ce fait, les URL sont particulirement lisibles et les requtes sont fortement simplifies. Lexemple suivant prsente, dans le cadre du fil rouge, la demande davancement sur une intervention en REST :
http (methode GET)://www.portos.org/ServiceIntervention/recupererEtatDemande/ NumeroDistributeur/42 NumeroDemande/108
REST est largement utilis pour les intgrations au niveau de linterface utilisateur dans des services sur Internet. Ces services comme Flickr ou del.icio.us2 sont
1. URI signifie Uniform Resource Identifier. Il sagit dun format dadressage sur le Web. 2. On les regroupe parfois sous lappellation Web 2.0.
186
destins permettre des internautes de partager des informations entre plusieurs applications. Leurs besoins en intgration sont donc trs simples. REST est donc destin des dveloppeurs de sites Web : en aucun cas, cette technologie ne peut tre utilise pour des compostions de services au sein dapplications mtiers complexes. Ce nest donc pas un concurrent srieux pour SOAP dans le cadre des architectures SOA. Enfin, REST, de mme que XML-RPC, ne rpond pas au besoin de description de linterface du service (cf. Partie 2).
<data types> (schma XML associ) Indpendant de la technologie Objets mtier <parts> Contient Message Reoit <operation> Interface du service <Port Type> Invoqu via Protocole de transport Utilise Adresse du service <port> <message>
Dpendant de la technologie
<binding>
187
Les paramtres dentre et sortie de ces oprations. Le typage de ces paramtres. Les points dentre (URL) des oprations. La figure 12.3 montre comment WSDL traduit ces notions dans sa grammaire normalise. Les concepts sous-jacents sont prsents en dtail dans la seconde partie de cet ouvrage. WSDL ne couvre que le contrat minimal dcrit dans cette partie, cest-dire la seule mthode dinvocation et non un engagement sur la qualit de service. WSDL constitue un contrat pour linvocation technique de service Web, sur lequel les applications clientes peuvent sappuyer pour connatre les oprations et leurs arguments. Ainsi chaque application pourra paramtrer de manire automatique cette invocation de service. Lexemple suivant prsente, dans le cadre du fil rouge, la dfinition en WSDL 1.1 du service de demande davancement sur une intervention. On considre que le service, intitul ServiceIntervention, a comme paramtre dentre un numro de demande entier, et comme paramtre de sortie un tat davancement de la demande sous la forme dune chane de caractres.
<?xml version="1.0"?> <! root element wsdl:definitions defines set of related services > <wsdl:definitions xmlns:si="http://www.portos.com/ServiceIntervention" xmlns:bo="http://www.portos.com/bo" xmlns:soap="http://schemas.xmlsoap.org/ wsdl/soap/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http:// www.w3.org/2001/XMLSchema" targetNamespace="http://www.portos.com/ ServiceIntervention" name="ServiceIntervention"> <wsdl:types> <xsd:schema targetNamespace="http://www.portos.com/bo"> <xsd:element name="recupererEtatDemande"> <xsd:annotation> <xsd:documentation>le type wrapped de recupration de ltat de la demande</xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:element name="NumeroDemande" type="xsd:int"/> <xsd:element name="NumeroDistributeur" type="xsd:int"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="recupererEtatDemandeResponse"> <xsd:annotation> <xsd:documentation>le type wrapped de la rponse</xsd: documentation> </xsd:annotation>
188
<xsd:complexType> <xsd:sequence> <xsd:element name="EtaDemande" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema> </wsdl:types> <wsdl:message name="recupererEtatDemande"> <wsdl:part name="parameters" element="bo:recupererEtatDemande"/> </wsdl:message> <wsdl:message name="recupererEtatDemandeResponse"> <wsdl:part name="parameters" element="bo:recupererEtatDemandeResponse"/> </wsdl:message> <wsdl:portType name="ServiceInterventionPort"> <wsdl:operation name="recupererEtatDemande"> <wsdl:input message="si:recupererEtatDemande"/> <wsdl:output message="si:recupererEtatDemandeResponse"/> </wsdl:operation> </wsdl:portType> <wsdl:binding name="ServiceInterventionBinding" type="si:ServiceInterventionPort"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/ soap/http"/> <wsdl:operation name="recupererEtatDemande"> <wsdl:input> <soap:body use="literal"/> </wsdl:input> <wsdl:output> <soap:body use="literal"/> </wsdl:output> <soap:operation soapAction="urn:#recupererEtatDemande"/> </wsdl:operation> </wsdl:binding> <wsdl:service name="ServiceIntervention"> <wsdl:port name="ServiceInterventionPort" binding="si:ServiceInterventionBinding"> <soap:address location="http://services.portos.com/wsdl/ ServiceIntervention"/> </wsdl:port> </wsdl:service> </wsdl:definitions>
Nota : lexemple prsent respecte la spcification WSDL 1.1 et non la spcification WSDL 2.0. En effet, WSDL 1.1 fait partie des normes dinteroprabilit WS-I (cf. partie 5).
189
Lexemple montre bien le caractre verbeux de WSDL. Cependant, il est dans la pratique assez rare dcrire le corps du fichier la main : la plupart des environnements de dveloppement savent en effet gnrer le fichier WSDL sur la base des caractristiques du service dvelopp. Certains autres permettent de le construire sur une base visuelle (cf. figure 12.4).
12.2.2
Comme prcis dans le paragraphe prcdent, WSDL ne dcrit dans sa version actuelle que le contrat minimal , cest--dire la mcanique dinvocation du service. Il ne permet pas de dcrire (cf. partie 2) : La plaquette commerciale du service. Les engagements vis--vis du service (SLA). La tarification ventuelle du service. Etc.
Un certain nombre de spcifications additionnelles en cours dcriture visent combler ces manques : WS-agreement (initie par IBM et soumise au W3C) : cette grammaire XML vise dfinir les garanties sappliquant sur un contrat de service. Elle aborde la description des parties en prsence, du niveau de service rendu, des garanties apportes (disponibilit, temps dinactivit, etc.), du mode de contrle de la disponibilit des services. WSMO, Web Service Modeling Ontology (ESSI1) : cette initiative vise crer des grammaires XML pour dcrire des services dans un domaine mtier particulier, afin de pouvoir comparer les offres de divers vendeurs (par exemple dcrire les offres de vente de musique en ligne). La prennit des spcifications cites ci-dessus nest pas assure : elles sont intressantes uniquement pour avoir une vision prospective des axes dvolution des contrats de service. Enfin, il existe par ailleurs une spcification plus gnraliste et plus mature qui peut tre utilise pour dcrire les directives sappliquant sur un contrat de service : il sagit de WS-Policy. Elle sera prsente dans le chapitre 13.
1. European Semantic Systems initiative.
190
Service 1. Tentative dinvocation 2. Pas de rponse 3. Recherche dun service de remplacement 4. Description du service de mto 2 Utilisateur portail Portail Service 5. Connexion au service de mto 2
Mto 1
Registre UDDI
Mto 2
191
Ces aspects sont dcrits en dtail dans la partie 2 de cet ouvrage. Les annuaires UDDI peuvent tre autonomes ou se fdrer en rseaux de registres la manire des DNS ou des autorits de certification. Ils peuvent tre privs, publics ou semi-publics, cest--dire accessibles uniquement par des partenaires. On distingue ainsi trois types de registres : Registre dentreprise : ces annuaires sont situs sur un rseau priv, et servent de rfrentiels des services disponibles en interne. Cest aujourdhui le principal usage des annuaires UDDI. Registre fdr avec des partenaires : ces annuaires peuvent avoir une gestion dlgue un tiers ou bien tre synchroniss avec dautres rfrentiels. Leur architecture doit tre soigne pour assurer leur scurit : ils peuvent en effet tre la cible de pirates. Registre public : ces annuaires devraient thoriquement tre lis les uns aux autres la manire de DNS afin de constituer un registre mondial des services invocables depuis Internet. Dans la pratique, ils sont inexistants : seuls quelques annuaires de tests sont proposs par Microsoft, IBM et Xmethods.
12.3.2
Aspects techniques
Le fournisseur de service publie son contrat WSDL dans lannuaire UDDI en lassociant la description de la socit et la catgorie de service concerne. La description des catgories de services nest pas normalise : elle est laisse lapprciation du fournisseur de registre, ce qui limite la possibilit de registre interoprable lchelle dInternet. On retrouve ici la problmatique dontologie, voque dans le paragraphe 12.2.2 Les limites de WSDL. Chaque service de lannuaire est identifi par une clef unique, sorte de clef primaire du registre. UDDI normalise la notion daffiliation entre les registres, permettant la mise en uvre darchitectures fdres entre annuaires de plusieurs partenaires. Avec la version 3 de la norme, il est possible de signer lectroniquement un contrat WSDL lors de sa publication afin de certifier quil mane bien dune socit connue et non dun pirate malveillant.
12.3.3
On fait aujourdhui un constat dchec sur la dcouverte et lintgration automatiques qui taient un des fondements de la conception de UDDI. Les concepteurs de la norme avaient en effet sous-estim la ncessit de ngociation financire et de contractualisation qui empchent toute ide dautomatisation de laccs un service payant. De plus, avec les nouvelles rglementations de type Sarbanes-Oxley, il nest pas envisageable de se connecter un prestataire dont on ignore tout. Lobjectif
192
initial de mettre en uvre un annuaire de services lchelle dInternet na donc pas t atteint. Cependant, dans le contexte dun systme dinformation sorientant vers une architecture SOA, il est tout fait pertinent de mettre en uvre un registre interne des services. Ce registre constitue un rfrentiel dentreprise au mme titre quun annuaire LDAP ou une base de clients. Il permet de dcrire et localiser les services avec leurs diffrentes versions, jouant un rle complmentaire lintranet de la DSI souvent utilis pour dcrire les infrastructures techniques de lentreprise.
Message SOAP
2. Interrogation du registre
3. Invocation du service
1. Publication du contrat Registre UDDI Contrat WSDL Interface Web Service C, C++, Java VB, C#, PHP, Perl, Cobol, etc.
Composants mtiers
De plus, il existe, dans le cadre du framework WS-Policy, une spcification appele WS-PolicyAttachment qui permet dajouter une politique daccs un service donn (cf. paragraphe sur WS-Policy). Lannuaire UDDI peut donc, en intgrant cette description, grer la politique daccs aux services de lentreprise. Il prend ainsi un rle structurant dans linfrastructure de scurit de lentreprise. Certains analystes y voient le vrai intrt des registres UDDI.
193
En rsum
La figure 12.6 propose un rcapitulatif des normes prsentes dans ce chapitre. Elle positionne : SOAP, pour lchange des messages dinvocation des services; WSDL, pour la description de contrat de services, quelle que soit la technologie dimplmentation sous-jacente; UDDI, comme rfrentiel des services disponibles.
13
Les rponses aux exigences techniques
Objectif
Ce chapitre aborde la seconde couche des spcifications Web Services prsentes en introduction de cette partie (cf. figure 13.1). Il dcrit les spcifications permettant : La scurit sur la base du socle WS-Security. La garantie dacheminement. La garantie transactionnelle. Le monitoring des services. Ces spcifications correspondent au cahier des charges technique de la premire partie.
En introduction, une norme gnraliste WS-Policy et WS-Policy Attachment (GXA) Le framework WS-Policy permet de dfinir toute politique associe un service. Il offre une grammaire normalise pour dcrire des politiques de scurit, de garantie de service (SLA) ou autre. Il est donc destin enrichir la description des services au sein des annuaires UDDI.
196
Prsentation (WSRP)
Composition & Coordination (WS-*) Normes / Drafts OASIS & autres Pilotage (WS-*)
Transactions (WS-*)
Scurit (WS-*)
Cette spcification ne rentre donc pas dans lun des sous groupes de ce chapitre (scurit, transaction, etc.). Par contre, on y fera rfrence dans plusieurs dentre eux. WS-Policy ne prcise pas comment lier la politique un service donn. A contrario, WS-Policy Attachment se prsente sous la forme dun fichier spar qui permet de lier la politique au service.
La scurisation des Web Services est possible avec les mthodes traditionnelles notamment la mise en uvre de tunnels SSL pour assurer la confidentialit des appels Web Services ou lutilisation didentifiant/mot de passe pour assurer lauthentification dune application cliente dun web service. Elle est toute indique pour des changes point point. Cependant, dans le cadre dchange de messages SOAP entre plus de deux services, le nombre de tunnels SSL et points dauthentification devient exponentiel : en effet, pour changer des messages entre quatre services, il faudra dployer quatre certificats SSL et authentifier chacun des trois autres services sur chaque service invoqu (voir figure 13.2). Ce mode de fonctionnement devient vite ingrable, cest pourquoi on prfre intgrer la gestion de la scurit au sein des messages SOAP. Ce chapitre a pour objectif de prsenter les spcifications permettant la scurisation des Web Services au travers de mthodes bases sur les messages SOAP eux-mmes.
1. Pour un rappel gnral sur les notions de scurit, voir partie 1.
197
Identifiant/mot de passe pour service 2 Identifiant/mot de passe pour service 3 Identifiant/mot de passe pour service 4
Identifiant/mot de passe pour service 1 Identifiant/mot de passe pour service 2 Identifiant/mot de passe pour service 4
Service 1
Service 3
Message SOAP Identifiant/mot de passe pour service 1 Identifiant/mot de passe pour service 2 Identifiant/mot de passe pour service 3
Identifiant/mot de passe pour service 1 Identifiant/mot de passe pour service 3 Identifiant/mot de passe pour service 4
Service 4
Figure 13.2 Scuriser les Web Services avec les mthodes traditionnelles
13.1.2
Le framework WS-Security
WS-Security ou WSS constitue un framework de base pour la scurisation des Web Services. Il sappuie sur un certain nombre de sous-normes, prsentes dans la suite de ce paragraphe.
198
Il devient ainsi possible, lors de la transmission de messages SOAP, dauthentifier lexpditeur, dassurer lintgrit des donnes et dassurer la non-rpudiation des changes. Lutilisation de XML Signature suppose bien entendu la mise en uvre de procdures pour distribuer des certificats numriques aux services et de routines pour vrifier les signatures.
SAML (OASIS)
SAML signifie Security Assertion Markup Language. Cest une grammaire XML normalise par lOASIS qui permet dattester lauthentification dun client souhaitant accder plusieurs services, en vitant ainsi ce client de sauthentifier autant de fois quil y a de services invoqus. SAML permet ainsi dassurer le Single Sign On, lauthentification tant assure par un service technique ddi cette tche. Une fois lauthentification effectue, ce service de scurit distribue aux autres services des assertions ou jetons de scurit SAML, au travers desquels il certifie avoir bien men lauthentification des accdants et sengage sur leur identit. Il utilise pour cela des mcanismes de signature numrique et de chiffrement bass sur XML Encryption et XML Signature. Lauthentification au sein du service de scurit peut tre base sur des identifiants/ mots de passe, des tickets Kerberos, des certificats X509, des certificats PGP, etc.
199
WS-Security
SAML
XML Signature
XML Encryption
SOAP
Remarque : WS-Security est aussi parfois appel WSS ou encore SOAP Message Security. De fait, les variations de nommage des spcifications Web Services sont un facteur important de confusion pour leurs utilisateurs.
13.1.3
Les spcifications prsentes dans ce paragraphe sappuient sur le framework WSSecurity. Elles sont gnralement en cours dcriture et peu stabilises. Elles manent de consortiums dditeurs : elles ne sont donc prises en charge par aucun organisme de normalisation. Par consquent, leur implmentation est assure par une minorit de serveurs dapplications.
XACML (OASIS)
XACML est une spcification gre par lOASIS et stabilis depuis quelques annes. Elle na donc pas tout fait sa place dans la rubrique des spcifications inabouties. Cependant, elle nest pas implmente aussi frquemment que les prcdentes. Son usage est plutt marginal, do sa prsence dans ce chapitre. XACML signifie eXtensible Access Control Markup Language. Son objectif est de complter SAML en prcisant les habilitations de laccdant. Elle dcrit donc des droits pour des accdants ou des groupes daccdants vis--vis de services.
SPML (OASIS)
SPML signifie Service Provisioning Markup Language. Cette spcification a t propose par WaveSet, diteur rachet par Sun, puis ratifie par lOASIS. Elle porte sur le provisioning des annuaires de scurit, cest--dire sur la gestion des comptes utilisateurs dans diffrentes applications disposant de bases didentifiants/ mot de passe autonomes. SPML peut traiter trois cas dusage classiques de provisioning : Un collaborateur est embauch dans une socit : il faut alors crer ses comptes pour Windows, la messagerie, lintranet, etc.
200
Un collaborateur change de statut dans la socit : il faut pouvoir modifier ses droits ou ses comptes vis--vis des applications. Un collaborateur quitte la socit : il est ncessaire de dsactiver lensemble de ses comptes applicatifs. SPML est donc une grammaire XML normalise qui permet dchanger des messages de cration/modification/suppression de compte entre des services. Avec lusage de SPML, on considre que la centralisation des comptes de scurit nest pas ncessaire et que lon ne va pas lencontre de la multiplication des annuaires de scurit. Cette approche est oppose mais complmentaire celle de la fdration didentit, prsente dans la suite de ce chapitre.
WS-SecurityPolicy (GXA)
WS-SecurityPolicy est une dclinaison de WS-Policy dans le cadre des politiques de scurit. WS-SecurityPolicy est utilisable dans le cadre de WS-Security, WS-SecureConversation et WS-Trust (cf. suite de ce chapitre). WS-SecurityPolicy indique : Quels modes dauthentification sont accepts par le service. Si le service dlgue son authentification un tiers, quels types dassertions de scurit il accepte (tickets SAML, Kerberos, ou autres). Si le service manipule des donnes confidentielles et exige des changes sur un mode chiffr. Lexemple ci-dessous prsente le formalisme dune politique de scurit exigeant une authentification par identifiant/mot de passe (mot clef : UsernameToken).
<wsse:SecurityTokenReference> <wsse:Reference URI="#SecurityToken-c4dc7e55-7c3d-43ed-b615-0b62a14009c7" ValueType="http:// docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile1.0#UsernameToken"/> </wsse:SecurityTokenReference>
WS-Trust (GXA)
Le principe de WS-Trust est de demander un service technique, le Security Token Service, de servir de relais de confiance entre deux services qui nutilisent pas les mmes mthodes dauthentification ou les mmes typologies dassertions de scurit. Ainsi le Security Token Service doit tre capable de : Traduire les assertions de scurit dun formalisme (par exemple SAML) un autre (par exemple Kerberos) pour les services en prsence. Servir de relais de confiance entre les services en prsence, car ces derniers lui font tous deux confiance.
201
Le Security Token Service joue ainsi un rle de tiers dintermdiation entre deux univers qui ne parlent pas le mme langage et o les rgles de scurit sont diffrentes. Pour les lecteurs familiers avec la PKI, le Security Token Service est comparable lautorit denregistrement qui joue le rle dintermdiaire entre lautorit de certification et les demandeurs de certificats. Pour donner une image comprhensible par tous, on pourrait considrer deux pays (Isral et la Palestine) qui nont aucune relation de confiance, mais qui de faon ponctuelle peuvent sappuyer sur la France, qui a des relations diplomatiques avec ces deux pays, pour se transmettre des informations fiables.
WS-SecureConversation (GXA)
WS-SecureConversation dfinit une extension de WS-Security qui permet de mener une session scurise pour les changes entre deux services. Cest en quelque sorte lquivalent dune session SLL en peer-to-peer entre Web Services. WS-SecureConversation commence par une phase dinitialisation au cours de laquelle les deux partenaires se mettent daccord sur les clefs de chiffrement utiliser tout au long de la session (cf. SSL Handshake pour les connaisseurs en scurit). Lors de longues sessions chiffres, le protocole permet dconomiser de la complexit syntaxique par rapport WS-Security. De manire synthtique, WS-SecureConversation permet de simplifier les messages WS-Security lorsquon a affaire des changes longs et rpts entre deux services. noter : WS-SecureConversation peut sappuyer sur WS-Trust.
WS-Privacy (GXA)
WS-Privacy est un projet en cours dcriture par un consortium dditeurs. Cette spcification aura pour objectif de dfinir une politique sur la gestion des donnes prives des clients/utilisateurs. Il sagit de se mettre au clair vis--vis des utilisateurs et du lgislateur (la CNIL en France) sur la problmatique pineuse de la conservation des donnes prives.
WS-Authorization (GXA)
WS-Authorization est de mme un projet en cours dcriture. La grammaire XML sous-jacente nest donc pas disponible. Il semblerait que ce soit une spcification concurrente de XACML, donc voue dfinir des droits daccs sur des services. Elle est propose par IBM et Microsoft pour tre plus cohrente avec lensemble des spcifications prsentes dans ce chapitre.
202
13.1.4
Entreprise A
Entreprise B
Accs Service
Serveur identit A
Serveur identit B
Service B1
Accs Service
203
Les modes dinteractions entre services et serveurs didentit peuvent suivre de multiples cas dusage (plus complexes que ceux de la figure 13.4) afin de faire face tous les scnarios de dlgation didentit. La fdration didentit est un principe un peu droutant au premier abord, mais il se rvle prcieux lorsquon souhaite ouvrir ses services des partenaires sans avoir grer leurs utilisateurs. Par ailleurs, il permet lutilisateur de ne mmoriser quun seul couple didentifiant/mot de passe pour les applications internes et externes lentreprise.
Le projet Liberty
Le projet Liberty est la premire proposition de spcification pour assurer la fdration didentit. La spcification Liberty est gre par un consortium spcifique appel Liberty Alliance, regroupant la majorit des acteurs de linformatique lexception notable de Microsoft. La spcification est stabilise depuis 2003 et implmente par de nombreux produits du march. Par contre, les entreprises utilisant les principes de fdration didentit sont encore rares, ces concepts tant encore jeunes et plutt complexes apprhender. La spcification Liberty est en ralit un vaste framework compos de nombreuses sous-normes que nous ne dcrirons pas en dtail dans cet ouvrage. Elle sappuie sur le framework WS-Security, mais pas sur les spcifications inabouties prsentes dans le chapitre prcdent (cf. figure 13.5). Par consquent, elle est stable, mais ne bnficie pas de la modularit des spcifications prcdemment cites, contrairement WS-Federation prsent dans le paragraphe suivant.
Projet Liberty
WS-Security
SAML
XML Signature
XML Encryption
SOAP
WS-Federation (GXA)
WS-Federation est une spcification concurrente Liberty et beaucoup plus rcente propose par un consortium dditeurs intgrant Microsoft. Elle est encore peu stabilise et ne dispose que de trs peu dimplmentations. Elle sappuie en revanche sur les spcifications prcdentes : WS-Security, WS-Trust, WS-SecurityPolicy. Elle apparat globalement moins complexe mettre en uvre que Liberty.
204
De plus elle bnficie du soutien des grands diteurs, y compris Microsoft, ce qui lui donne une chance de supplanter Liberty.
Bilan sur la scurisation des Web services Pour conclure ce sous-chapitre sur la scurit, il faut retenir que le framework WSSecurity forme une base stabilise sur laquelle on peut sappuyer pour mettre en uvre une architecture SOA. Il est donc aujourdhui possible dadresser les bases fondamentales de la scurit : confidentialit, authentification, intgrit, non rpudiation. Les normes Liberty sont quant elles stabilises et implmentes par les grands diteurs, mais elle risque de souffrir de la concurrence de WS-Federation. Ainsi, pour parer toutes les ventualits, la socit Ping Identity, diteur majeur de la fdration didentit, a dcid dimplmenter les deux spcifications. La prennit des spcifications GXA peut sembler plus alatoire, mais elles bnficient du support dIBM et Microsoft. Ces derniers devraient travailler dans les prochaines annes sa prennisation. Il est cependant un peu tt pour les mettre en uvre. La figure 13.6 suivante prsente le modle GXA pour la scurit.
SOAP
WS-Reliability (OASIS)
WS-Reliability est une grammaire XML normalise par lOASIS depuis 2004. Elle offre aux messages SOAP les garanties dacheminement et de traitement suivantes :
1. Pour un rappel gnral sur la garantie dacheminement, voir partie 1.
205
Garantie que le message a t reu au moins une fois, et notification de cette rception. Garantie que le message na t reu quune seule fois. Dtection et limination des duplications. Garantie sur lordre de rception des messages : ils seront reus dans leur ordre dmission. WS-Reliability dfinit pour cela des commandes XML insrer dans les en-ttes et les corps des messages SOAP. La spcification permet ensuite de notifier les parties en prsence des rsultats dacheminement.
WS-ReliableMessaging (GXA)
Cette spcification a t crite en parallle WS-Reliability par un groupe pilot par IBM et Microsoft sans concertation avec lOASIS. Elle offre le mme primtre que WS-Reliability, mais est incompatible avec cette dernire. Face cette divergence de normalisation, certains diteurs comme BEA ont dcid dimplmenter les deux spcifications. Selon IBM et Microsoft, WS-ReliableMessaging est plus adapt pour fonctionner avec WS-Security, WS-SecureConversation et plus gnralement avec GXA. Depuis mai 2005, des travaux sont en cours pour fusionner les deux spcifications et donner la gestion de la norme rsultante lOASIS.
206
WS-ReliableMessaging
WS-RM Policy
WS-Reliability
WS-Policy
SOAP
SOAP
OASIS
GXA
13.3.1
WS-Coordination (GXA)
Cette spcification propose une grammaire XML pour coordonner des transactions distribues. Elle fonctionne sur la base dun service de coordination jouant le rle de moniteur transactionnel. Les services dsirant participer la transaction doivent tout dabord sinscrire auprs dun service denregistrement en utilisant un formalisme de messages normaliss. WS-Coordination offre ensuite un systme de propagation du contexte transactionnel entre les services2. Les messages changs peuvent tre scuriss via WS-Security, WS-Trust et WSSecureConversation (cf. chapitre 13.1).
WS-AtomicTransaction (GXA)
WS-AtomicTransaction sappuie sur WS-Coordination. La spcification prcise les mcanismes utiliser pour grer les transactions atomiques et permet de traiter les transactions two-phase commit (variantes Durable et Volatile) dans un contexte Web Service.
1. Pour un rappel gnral sur les transactions distribues, voir partie 1. 2. Le concept de Contexte est prsent dans la partie 3, chapitre 9 de cet ouvrage. Le contexte offert par WS-Coordination est plus restrictif que ce dernier.
207
WS-BusinessActivity (GXA)
WS-BusinessActivity sappuie sur WS-Coordination. La spcification prcise les mcanismes utiliser pour grer des transactions longues et les processus de compensation.
13.3.2
WS-AtomicTransaction
WS-BusinessActivity
WS-Coordination
SOAP
WS-DM signifie Web Services Distributed Management. Cette spcification a t crite par lOASIS sur la base dune norme plus ancienne : WS-Manageability. WS-Manageability tait une proposition dIBM, Computer Associates et HP soumise lOASIS en 2003. Cette spcification tait conue pour assurer la supervision de serveurs sur la base dun langage normalis et donc indpendant des agents propritaires (SNMP ou autres) qui rendent la gestion de parcs de serveurs complexe et coteuse. LOASIS a largi le scope de WS-Manageability pour proposer un framework plus complet : WS-DM sapplique aux appareils lectroniques professionnels ou grand public. Elle permet par exemple une imprimante de signaler que son encre est puise, un projecteur vido de signaler une ampoule en fin de vie. WS-DM dcrit deux sous-normes : MUWS (Management Using Web Services), qui permet de superviser tout appareil prsentant une interface ad hoc sous la forme de Web Service. MOWS (Management of Web Services), qui permet de superviser les Web Service.
208
Ds lors quune ressource publie son tat sous la forme de Web Service, WS-DM permet : dinspecter son tat (en attente, occup, satur, arrt, dficient, etc.), de suivre ses mtriques de fonctionnement, de rcuprer des alertes. La grammaire WS-DM dcrit en particulier comment : Un client accde aux informations de monitoring de la ressource. Un client gre les paramtres de la ressource ou sabonne aux alertes publies la ressource. Un client informe la ressource dun vnement de gestion.
13.4.2
WS-Management
WS-Management est une proposition concurrente de Microsoft et des principaux constructeurs de matriel informatique. La spcification est oriente gestion de parc et des ressources rseaux. Elle propose de superviser des PC, serveurs, terminaux mobiles de tous types, et accessoirement des Web Services. Elle a t soumise la DMTF1, un organisme de normalisation qui traite plus particulirement de la gestion des ressources en rseau dentreprise. WS-Management Catalog est une sous-spcification de WS-Management. Elle a pour objectif de proposer un rfrentiel des ressources disponibles (une sorte de registre UDDI orient rseau). Ce catalogue dcrit pour chaque ressource son emplacement, sa version, son fournisseur, ses oprations accessibles, ses proprits. La grammaire XML propose par WS-Management est beaucoup moins complte que WS-DM. De plus, elle semble encore en cours dcriture. Elle offre cependant lavantage dtre plus simple implmenter que WS-DM pour des terminaux simples. Par ailleurs, la force de frappe de Microsoft ainsi que sa matrise des systmes dexploitation en entreprise pourrait bien limposer face WS-DM.
En rsum
Pour conclure ce chapitre, il faut retenir que : Pour scuriser une architecture SOA, on peut sappuyer sur le socle WS-Security les autres spcifications prsentes tant sujettes voluer. Dans le cadre spcifique de la fdration didentit, on prfrera les spcifications Liberty aujourdhui oprationnelles et implmentes par les diteurs.
1. Distributed Management Task Force.
209
La gestion de la garantie dacheminement reste encore immature. Il en est de mme pour la gestion des transactions, dautant plus que WS-CAF, prsent dans le chapitre suivant, entre en partie en conflit avec les spcifications dcrites dans ce chapitre. Pour ce qui concerne la supervision, WS-DM est sans aucun doute la norme la plus aboutie aujourdhui. Mais lavenir pourrait faire pencher la balance du ct de WS-Management.
14
La composition de services
Objectif
On dcrit ici les spcifications permettant : La composition interactive de services au sein dun portail. La composition automatise des services au sein dun orchestrateur. Lassemblage de services dans lobjectif de crer des applications composites.
Prsentation (WSRP)
Composition & Coordination (WS-*) Normes / Drafts OASIS & autres Pilotage (WS-*)
Transactions (WS-*)
Scurit (WS-*)
212
Ce chapitre explicite, dans le cadre des Web Services, les notions prsentes dans la partie 2 de cet ouvrage. Il sort un peu du cadre strict des Web Services car il aborde SCA, une spcification qui sapplique dautres technologies comme Java, .NET, etc.
WSRP signifie Web Services for Remote Portlets. Cette spcification issue de lOASIS dcrit comment intgrer facilement des services au sein dune interface de portail. WSRP permet un service dassocier aux messages SOAP un modle de prsentation qui pourra tre consomm par un portail compatible WSRP. La plupart des portails actuels sont compatibles avec cette spcification : ils peuvent donc intgrer la portlet1 sans aucun dveloppement.
Consommateur WSRP Fournisseur WSRP
Un service WSRP peut tre consomm par une application interactive qui ne serait pas un portail. Ainsi le dveloppeur dapplication composite interactive na plus besoin de construire linterface utilisateur sur la base de linvocation du service : celle-ci est prdfinie et auto-gnre.
1. Une portlet est un fragment de page dans une interface de portail.
213
Le protocole permet de srialiser les donnes non plus au niveau des messages, mais directement au niveau de la couche de prsentation (la session, les URLS ou boutons dactions, ainsi que le fragment de rendu lui-mme). WSRP permet aussi la publication et la dcouverte des Portlets au travers dun registre UDDI. Enfin, une prochaine volution du standard devrait intgrer les problmatiques de dialogue inter-portlets (cf. normes de gestion de contexte).
BPEL signifie Business Process Execution Language. La spcification a t initialement propose par Microsoft, IBM et BEA en 2002 : elle tait intitule BPEL4WS (Business Process Execution Language for Web Services). Sa gestion a ensuite t reprise par lOASIS et son nom a t mis en conformit avec la notation WS-*. Cependant, on parle le plus souvent de BPEL et non de WS-BPEL.
214
Manipulation1 des donnes dchange entre les services (commandes : assign, copy). Regroupement de squence dinvocations de services (commande : scope). Gestion des erreurs (commandes : throw, rethrow). Gestion de procdures de compensation (commande : compensate). BPEL ne fournit pas de reprsentation graphique normalise des processus. BPMN (Business Process Modeling Notation) a t conu dans cet esprit, mais la normalisation reste pauvre en regard des possibilits de la grammaire dexcution. En attendant, certains environnements du march proposent donc la leur. Lexemple de la figure 14.3 sinspire de lun dentre eux.
Enfin, BPEL fournit des mcanismes dextension permettant de dlguer des langages de bas niveau des parties de processus trop complexes pour tre prise en charge directement par la grammaire XML elle-mme.
Limites de BPEL 1.1 Gestion de sous-processus Si BPEL 1.1 propose de regrouper des squences dinvocation de services (les scopes), cette fonctionnalit se limite offrir une facilit dcriture. La grammaire est en effet incapable de grer des processus et sous-processus : BPEL travaille forcment trs faible granularit, ce qui nest pas satisfaisant pour dcrire des processus trs complexes ou pour permettre de capitaliser sur des processus.
On peut grer des sous-processus comme des processus parallles, mais on perd dans ce cas le contexte du processus global.
1. Il sagit de manipulation simple : BPEL 1.1 na pas vocation faire des transformations de grammaire XML.
215
Gestion de contexte
La gestion de contexte propose par BPEL se rsume du couper/coller de donnes entre rsultat dun service et paramtres dinvocation du service suivant : elle est donc trs rudimentaire, et cela complique considrablement lutilisation de BPEL. De fait, il est ncessaire de prvoir une gestion de Contexte, via un service de Gestion de Contexte tel que dcrit dans la partie 2, ou, au minimum, dintroduire dans BPEL des appels des morceaux de code Java ou autre pour effectuer facilement ce couper/coller.
216
Enfin lextension BPELJ permettra linvocation directe de composants crits java, lobjectif tant ici de sacrifier linteroprabilit offerte par SOAP au profit de la performance dexcution.
14.2.2
WS-CAF (OASIS)
WS-CAF signifie Composite Application Framework. Cette spcification issue de lOASIS dcrit comment construire une application composite sur la base de Web Services (cf. partie 2 pour la dfinition des applications composites). De mme que WS-Security, WS-CAF est un framework qui repose sur des sousspcifications : WS-CTX, WS-CF et WS-TXM. WS-CAF est la frontire entre les spcifications de gestion de la composition de service et celles de gestion des transactions. Par consquent, certaines sous-spcifications de WS-CAF peuvent entrer en concurrence avec celle dcrites dans le paragraphe 13.3, tandis que dautres entrent en concurrence avec BPEL dcrit dans le paragraphe prcdent. WS-CAF est la somme des trois spcifications suivantes : WS-CTX (Context Management) permet dchanger un contexte entre lapplication composite cratrice du contexte et les services invoqus. WS-CTX est donc concurrent de WS-Coordination. WS-CF (Coordination Framework) permet de partager un contexte et de grer un enchanement dactivits transactionnelles ou non : synchroniser les participants, diffuser des informations, envoyer des alertes, etc. WS-CF a donc un recouvrement fonctionnel partiel avec BPEL. WS-TXM (Transaction Management) permet de grer les aspects transactionnels si cela est ncessaire. La spcification traite des transactions 2 phases commit et des transactions longues. Elle entre donc en concurrence avec WS-AtomicTransaction et WS-BusinessActivity.
WS-CAF
WS-TMX
WS-CF
WS-CTX
SOAP
217
WS-CAF est un exemple trs reprsentatif des problmatiques de concurrence entre les spcifications Web Services. Il est dautant plus complexe apprhender que WS-CAF et BPEL sont deux normes gres par lOASIS. La vision de lOASIS semble tre la suivante : utiliser WS-CAF uniquement pour la gestion des transactions, utiliser BPEL pour la partie orchestration de haut niveau.
14.2.3
SCA
SCA signifie Service Component architecture. Cette spcification rcemment mise dans sa version 1.0 par un groupement de plusieurs diteurs vient dtre propose lOASIS pour normalisation. La prsence de SCA dans cette partie peut paratre discutable : en effet, il sagit dune spcification pour la composition de service indpendante de la technologie Web Services. SCA peut tre utilise avec des Web Services, mais aussi avec des services crits et Java, .NET, COBOL ou C++. On a choisi de la prsenter dans ce chapitre car elle complte la vision sur les spcifications de composition de services. Les problmatiques adresses par SCA sont les suivantes : Redploiement dun service sans impacter les clients consommateurs de ce service. Packaging dun service constitu de composants locaux ou distribus. Paramtrage technique du service au travers de fichiers XML. SCA propose une grammaire XML pour expliciter comment un service se construit statiquement sur la base dautres services. La spcification ne repose pas, contrairement BPEL, sur un moteur dorchestration. Il sagit en revanche dinvocation point point entre un service composite et le ou les services sous-jacents. SCA spcifie un modle dassemblage des services, en prcisant la dpendance du service appelant vis--vis des autres. La spcification dcrit si les appels de service sont : Synchrones ou asynchrones. Scuriss ou non.
Externe
Implmentation BPEL, C++, Java C#, Cobol, etc. Contrat WSDL ou Java
Externe
218
Transactionnels ou non. Sils offrent une garantie dacheminement ou non. SCA dfinit donc la mthode dinvocation et dencapsulation des services dans un langage XML, indpendant de la technologie utilise pour appeler ces services. Cette technologie peut tre SOAP, RMI, .Net Remoting, etc. La spcification est donc parfaitement adapte une architecture SOA htrogne o lon utiliserait de linvocation Java au sein du rseau local, et de linvocation SOAP lors dchange avec des partenaires (ces aspects seront explicits dans la partie 5 de cet ouvrage). SCA permet doffrir des containers de service SCA , qui se chargent dautomatiser lassemblage et le dploiement des services en interprtant les fichiers XML. Cest la gnralisation au contexte SOA des containers EJB, et surtout du container de service SPRING. Beaucoup plus simple mettre en uvre que les containers EJB 2.x, cet outil popularise linjection de dpendance, et de ce fait il facilite notablement lassemblage de solutions. Mais SPRING est limit au monde Java : SCA est en quelque sorte la gnralisation aux web service de SPRING.
Module SCA
Service
Composant SCA
Externe
En rsum
Pour conclure ce chapitre, il faut retenir que les spcifications de composition de services sont plurielles, mais quelles nadressent pas exactement les mmes besoins. BPEL est cependant la grammaire la plus utilise ce jour. Pour ce qui concerne lassemblage de services au sein dapplications composites, SCA offre une norme trs intressante qui gnralise la notion de container bien connue des architectes Java ou .NET.
CINQUIME PARTIE
220
Quels sont les choix techniques faire au lancement de limplmentation dune solution mtier ? Quels outils ou techniques vont faciliter les dveloppements et lexploitation ? Cette partie veut donc dmystifier le dmarrage de la mise en place dune solution qui respecte les principes SOA et souhaite en tirer des bnfices. Il ne sagit pas dun rfrentiel systmatique qui rpond toutes les questions mais dun ensemble de points clefs pour le bon dmarrage des projets. Le chapitre 15 prsente les diffrences techniques dans le contexte du SI tendu et du SI local. Le chapitre 16 montre les atouts de WSDL comme un formalisme pivot capable de dpasser le cadre des WebServices. On y aborde aussi quelques aspects techniques clefs pour montrer quelques bonnes pratiques de conception. Le chapitre 17 conclut sur les diffrents cas de figures techniques selon les typologies de service et prsente une dmarche pour sadapter aux volutions des contraintes techniques.
15
SI tendu ou SI local ?
Objectif
Ce chapitre se donne pour objectif didentifier les contraintes mtiers et techniques pour prparer une solution conforme SOA : savoir o utiliser ou non des Web Services. Comment faire ces choix sans tre un devin ou avoir un recul technique de 10 ans ? Cette problmatique est notamment exprime dans le cas de services offrir des partenaires, et dans le cas de services internes composant le SI local. Cette division SI tendu et SI Local est analyse et relativise.
222
Dun ct il doit tre accessible aux SI extrieurs sans prsupposer de leur plateforme technique et de lautre permettre une intgration au SI interne dont la plateforme est connue. Il se peut que les conditions daccs au service diffrent pour les partenaires et pour le SI interne. Ne serait-ce que pour viter de sortir du SI pour y retourner, mais aussi pour des raisons de scurit, par exemple. Certaines caractristiques de solutions mtiers permettent didentifier clairement les contraintes minimums prendre en compte.
Dans le cas dun service de haut niveau partager avec des SI distant, on ne peut pas prsupposer des technologies de plate-forme. De plus, les protocoles doivent rester les plus simples possible afin de matriser les outils de scurit, monitoring, et fiabilit. Le WebService (au sens srialisation XML) rgne sur ce terrain et la stabilit du protocole porteur http est trs adapte. Ces technologies sont encore jeunes et ne traitent pas aujourdhui de tous les aspects techniques des changes. Certains aspects restent fragiles voire peu adapts, comme la gestion de transactions, lutilisation de contextes distribus, la mesure de la qualit de service et la garantie de performance. Ces aspects sont tous en cours de stabilisation par les technologies WebServices comme le montre la partie 4. Lapproche SOA passe aussi par une typologie des services adapte. Des Services Applicatifs gros grain qui sont les seuls tre exposs aux SI distants sont les premiers bnficier de linteroprabilit et lindpendance technique des WebServices. Les services internes seront plus proches des contraintes techniques lies la distribution synchrone, les transactions, etc.
15.2.2
Les technologies EDI dominent les changes inter-entreprises existants. Les technologies XML et WebService en particulier sont souvent perues comme un concurrent des solutions EDI. Le dbat nest pas termin. Les socits et les diteurs qui ont beaucoup investi dans des solutions EDI denvergure sont sceptiques et affichent la suprmatie de lEDI en termes de performance, de scurit et de qualit de service. Les pionniers XML et les diteurs ayant opt pour des solutions XML/Web Services dfendent pour leur part la rapidit de mise en place, la flexibilit et lvolutivit offertes par ces solutions. LEDI est aujourdhui mature et permet de matriser parfaitement les changes massifs de donnes. Ces changes reprsentent souvent des vnements de gestion, ce qui les rend comparables des demandes dappels de services. En revanche, les technologies WebServices proposent un systme dinvocation lunit.
223
Cette diffrence notoire ouvre la voie vertueuse : la complmentarit de lassociation de lEDI existante avec les technologies XML. La mise en place de services dchange via des WebServices est en effet trs rapide et flexible. Elle permet dintervenir vite l o une solution EDI demanderait un travail plus important. Des flux dchanges XML sur ces technologies sont trs adapts des changes ponctuels de petite taille. Les solutions EDI offrent, quant elles, plus de garanties sur des changes massifs, mais aussi bien plus de contraintes.
224
Les contraintes de dploiement non connues ou changeantes peuvent tre rsolues plus tard par la multiplicit des formes de dploiement dun service. Le chapitre 16 prsentera les choix faire lors de la mise en uvre des services au sein dun SI.
WSDL
SOAP
WSDL
Encodage binaire
XML
Autre norme de type Remoting : IDL CORBA, EJB, .NET TCP Interface Java, C#
Encodage binaire
Sans objet
Lemploi de linfrastructure SOA se justifie plusieurs niveaux dans lurbanisation du SI, quils sagissent de simples applicatifs, de silos, ou de processus inter silos. Au sein dune application, SOA permet, via composition, la cration de nouveaux services ou la rutilisation et lorchestration de services existants, en gnral
225
non distribus (POxO). Au niveau dun silo, SOA permet la communication entre applications, en gnral via un bus synchrone ou asynchrone. Au niveau inter silos, SOA senvisage en gnral via un bus asynchrone et ventuellement via des Web Services lorsque les silos sont physiquement et gographiquement distribus. Enfin, au niveau du SI tendu, SOA utilise des Web Services synchrones et sans doute asynchrones lorsque les normes le permettront.
En rsum
Les services tendus lextrieur de lentreprise sont la cible premire des technologies WebService. A contrario, les services de grain fin restent des composants non distribus, rutiliss par des services de plus gros grain. Entre ces deux extrmes, les services de grain plus ou moins moyen (Services Applicatifs, Services Fonctionnels) seront distribus ou non distribus, et en cas de distribution, seront accds via Web Service, ou via une technologie classique. La frontire est donc floue entre SI distant et SI local vu de la mise en uvre SOA. Le tout WS est en tout cas une erreur.
16
Les atouts de WSDL
Objectif
Ce chapitre dmontre dans un premier temps un intrt rel utiliser WSDL comme formalisme universel de dfinition des services. Il prsente aussi des bonnes pratiques de la mise en place de ces dfinitions. Dans un second temps, il aborde deux points pratiques de lutilisation des spcifications des WebServices : les normes dinteroprabilit et lutilisation des styles de messages SOAP. Il sagit de points techniques de bas niveau, mais leur utilisation a souvent tendance tre empirique ou historique parce que pas toujours matrise. Il sagit donc de donner les bases suffisantes leur utilisation approprie. Dmystifier le WSDL, cest faciliter son utilisation et sa gnralisation.
Les WebServices ne sont pas la seule forme technique de rponse au sein dune architecture SOA (cf. tableau 15.1, les cas dusage des protocoles). Faut-il pour autant utiliser un formalisme de description des contrats de service diffrent pour chacun des cas ? On a vu dans la partie 4 que le langage de description des WebService dfinit linterface dutilisation dun service dans sa partie abstraite. Cette dfinition peut aussi servir la mise en uvre de forme POxO ou Remoting des services par simple gnration.
228
Cette vision permet de rentabiliser les comptences WSDL dune quipe qui pourra les exercer avec ou sans la prsence de WebServices proprement dit, en utilisant la partie abstraite du WSDL comme un formalise de dfinition de service. WSDL est un socle intressant pour bnficier des apports du mta-langage XML : Ce langage est notamment auto-descriptif, il autorise lextensibilit de syntaxe, il permet une validation automatique des types de donnes, etc. Btir sur ce socle permettra de bnficier davances technologiques, ne serait-ce que les amliorations des technologies de transport en terme de performance ou de gestion de nouveau protocoles ou middlewares.
16.1.2
La rponse est non. De nombreux outils ddis au monde XML permettent dj une reprsentation graphique dun WSDL, comme, par exemple, XMLSPy dAltova Software, ou dautres diteurs ddies comme Stylus Studio, ou OxygenXML. De plus, les approches MDA ont favoris la projection de modles UML vers une expression WSDL. Il est maintenant possible de modliser un WSDL en UML. Le PIM1 contiendra la partie abstraite du WSDL : Dfinitions, Types, PortTypes (interfaces), messages, et Parts. Le reste sera port par le PSM : binding, services et ports. Les outils WSAD/RAD, Sun One Studio, Visual Studio, etc., permettent dj une modlisation UML des WebServices. Des modles et profils UML existent et pourront tre utiliss terme dans tous les outils du march, quils soient Open Source ou propritaires. La connaissance de quelques notions importantes mais peu nombreuses sera utile afin de piloter ces outils en bnficiant au mieux des technologies SOA et WebServices. Le chapitre 16.3 Dmystifier lutilisation de WSDL : le Style utiliser prsente quelques points sensibles pour guider les concepteurs et dveloppeurs des services.
16.1.3
229
outils fonctionnent pour des projets de petite taille et indpendant dun SI mtier complet. Cette approche amne souvent une utilisation technologique nivele par le bas du service Web. Elle ne permet pas vraiment lintgration du point de vue mtier dans le processus, alors que cest un des bnfices majeurs des SOA. En revanche, cette approche est un atout majeur sil faut prototyper daprs un existant, ou adapter temporairement une solution ou si lon a peu ou pas de problmatique mtier tendue qui rpond des enjeux sur la dure et la capitalisation. Lapproche par le code nest donc pas foncirement conforme la dmarche SOA. Il sagit avant tout de raccourcis technologiques pour obtenir une base rapide une description WSDL quil faudra adapter aux contraintes fonctionnelles dans une approche par les modles si on veut bnficier des apports de SOA. Repartir des modles permet de faire cohabiter lexpertise mtier avec la matrise duvre. Les modles obtenus permettent de simuler au plus tt les scnarios fonctionnels validant le dcoupage et le potentiel de rutilisation. Les outils sont aujourdhui de plus en plus mme de supporter cette dmarche.
Sparation et capitalisation
La facilit de maintenance est toujours au cur des proccupations de la matrise duvre. Il se rvle de ce point de vue trs bnfique de distinguer dans un contrat WSDL laspect Abstrait (ce qui est indpendant de la technologie et des protocoles) et laspect Concret (ce qui est dpendant). Cette distinction classique permet de joindre ou rutiliser des sous-parties de modles WSDL et de les redployer loisir : le WSDL est classiquement sparable en 3 parties : Les schmas dune part, qui dfinissent les informations contenues dans les messages reus/mis par le service : ces schmas peuvent prexister avant la notion de service car ils reprsentent les entits mtier. Une dfinition abstraite du service, contenant sa description sans les modalits dimplmentation (protocole et dploiement). Une partie concrte qui propose les liaisons dune interface selon un certain format avec un protocole donn une adresse donne.
230
WSDL permet dimporter des WSDL et des schmas. La partie concrte dun contrat WSDL peut donc importer les dfinitions abstraites des services qui eux mme peuvent importer des schmas. Cette dmarche apporte une plus grande facilit de maintenance et de lisibilit.
Schma Schema Schema Modle Modle des donnes Modledes desdonnes donnes Contraintes contraintes Import Dfinition DfinitionAbstraite Abstraite Dfinition Abstraite Signature du Signature duservice service Signature du service Types Types (description (description des des donnes) donnes) Types (description des donnes) Messages Messages (paramtres) (paramtres) Messages (paramtres) PortTypes PortTypes (interfaces) (Interfaces) PortTypes (Interfaces) Import Projection Concrte Dclaration des liaisons Binding (format et protocole) Services (localisation)
Lors de la modification dun service, on peut encore composer des WSDL en procdant par extension. Limportation offre un mcanisme proche de lhritage qui permet de ne pas modifier des WSDL dj en production. Principe : utiliser les mcanismes de schma et dimportation pour construire de faon modulaire les contrats WSDL.
16.1.4
La rponse est videmment non. WSDL se cantonne la description dun service en terme statique. Dans ce rle, il est ncessaire et suffisant. La norme WSDL 2 tendra son primtre en intgrant des lments de qualit de service. En revanche, rien ne permet actuellement dtendre le contrat aux aspects qualit de service, la composition, le monitoring, etc., en utilisant WSDL 1.1. Des extensions spcifiques non normes sont disponibles en dehors de tout standard. Ces aspects sont abords par dautres normes et ont vocation tre portes par les infrastructures accueillant les services : serveurs dapplication et ESB. La partie 7 aborde les Bus de services ESB. On cantonnera donc le WSDL ce quil fait bien.
231
16.1.1
Les organismes de standardisation et les grands diteurs ont collabor mettre en place ces gardes fous au travers de lorganisation WS-I pour WebServices-Interoperabilit . Il sagit de restreindre une partie des liberts offertes par les spcifications la base des WebServices, soit pour simplifier les choix des implmentations, soit pour masquer des portions des spcifications qui taient trop floues pour une implmentation canonique et stable. Chaque sous-ensemble trait par WS-I est appel un Profile. La premire de ces normes est appele le Basic-Profile. Les Profiles suivants portent sur la scurit des WebServices. WS-I fournit aussi des applications exemples et des outils de tests afin dintgrer au mieux les recommandations.
On trouvera les travaux WS-I cette adresse : http://www.ws-i.org/
16.1.2
Basic-Profile 1.0 est le premier rsultat des travaux sur le renforcement de linteroprabilit des WebServices. Ce Profile porte sur les aspects statiques des WebServices. Basic-Profile contraint principalement la dfinition des messages SOAP et la dfinition des services. Il sagit en soit dune centaine de recommandations/restrictions lmentaires sur les messages SOAP (uniquement lattention des moteurs) et sur les descriptions WSDL. Ici, il sagit de simplifier le WSDL pour simplifier les choix des dveloppeurs et des outils ddition et de modlisation des services. Les outils de gnration intgrent la vrification et la conformit WS-I Basic Profile. On peut par exemple citer AXIS du groupe Apache, dont les gnrateurs sont conformes Basic Profile 1.0. WS-I Basic Profile 1.0 porte sur la spcification WSDL 1.1, ce qui explique le choix de cet ouvrage de montrer des exemples de WSDL correspondant cette version. Cette norme continuera dvoluer pour prendre en compte tous les lments qui apportent une garantie dinteroprabilit. Enfin, WS-I Basic Profile 1.0 a pour objectif de faciliter la gnration de code partir de spcifications WSDL. Initialement, ce travail vise simplifier le traitement du WSDL par les moteurs SOAP. Mais cet avantage est disponible pour tous les autres moteurs ou gnrateurs exploitant WSDL. WS-I renforce donc la stabilit des
232
formalisations WSDL et des outils WSDL-Centriques. Cela donne encore du poids lutilisation du WSDL comme un formalisme pivot quelle que soit la technologie dimplmentation des services.
16.3.1
RPC ou Document
Les styles principaux de communication dun WebService doivent tre Document ou RPC1. Les noms choisis par la spcification WSDL sont trompeurs car ces deux styles nont rien voir avec un modle de programmation par message ou par appel de fonction. Le style sapplique uniquement au mcanisme de traduction dun binding WSDL lors de la construction dun message SOAP. Les services suivent leur modle de programmation indpendamment de ces choix. Ainsi, on peut utiliser le style RPC dans un WebService pour envoyer un message un consommateur asynchrone de type JMS/Websphere MQ/MS MQ, etc.
16.3.2
Litteral ou Encoded
On retrouve la mme prcision pour Litteral ou Encoded qui sont des notions utilises lors du mapping du WSDL vers SOAP lenvoi ou la rception des messages. Litteral est explicite : le corps du message SOAP contient des fragments littraux XML simples. Le seul contenu du WSDL permet leur identification et leur utilisation. Encoded ajoute des informations de srialisation/d-srialisation entre XML et une plate-forme donne. Ce qui rend cette technique alatoire en terme dinter1. RPC : Remote Procedure Call, appel dune procdure distance.
233
oprabilit. Un exemple de message SOAP simple pour montrer la diffrence entre Literal et Encoded est disponible plus loin. Pourquoi cette norme ? Encoded ajoute aussi la normalisation dun attribut Href qui permet de rfrencer dans ce dialecte un autre nud dun arbre XML, offrant ainsi la capacit inne de traiter des graphes dlments, graphes qui ne sont pas exprimables en XML Schma.
16.3.3
Les styles XXX-Encoded ne sont pas conformes WS-I Basic-Profile comme on peut sy attendre car ils imposent des mta-informations dencodage/dcodage qui peuvent tre dpendantes dune plate-forme. Ces pratiques sont un risque en terme dinteroprabilit. On trouvera normment de services RPC-Encoded dans les existants avec lesquels il faut compter. Si linteroprabilit doit coexister avec lutilisation de cet existant, on peut devoir encapsuler ces services dans un WSDL conforme WS-I.
16.3.4
La partie concrte du WSDL comprend des informations sur le protocole de communication avec le service. Le binding est loccasion de choisir les facettes de SOAP utilises. Souvent, les choix de binding sont peu compris, ou historiques. Il est facile de montrer comment une connaissance superficielle peut aiguiller ces choix. Considrons le service ServiceIntervention et lopration rcuprer tat demande. La signature en Java de ce service serait exprime comme suit :
public Interface ServiceIntervention { public String rcuprerEtatDemande( } int numeroDemande, int numeroDistributeur);
Lutilisation de Java est fortuite. De mme que lutilisation dlments de code a un simple caractre indicatif qui ne remet pas en cause une approche par les modles. Ce service peut tre vu de diffrente manire par le couple WSDL/SOAP.
Le style RPC
Commenons par les modes RPC/Encoded et Literal. Si RPC/Encoded nest par conforme WS-I Basic Profile 1.0, il sert dillustration au propos pour montrer que limpact RPC /Document Literal/ encoded affecte uniquement la communication SOAP. Le changement de encoded vers Literal impacte seulement la partie WSDL concrte. Le message SOAP est impact. Dans la figure 16.2, le contenu du message SOAP contient des lments XML qui ne sont pas exprims dans un schma. On ne peut pas valider systmatiquement ce contenu avec les techniques classiques offertes par la plate-forme XML. Seul le
234
Contrat WSDL
Message SOAP <soap:envelope> <soap:body> <recupererEtatDemande> <numero xsi:type=xsd:int>42</numero> <distributeur xsi:type=xsd:int>108</distributeur> </recupererEtatDemande> </soap:body> </soap:envelope>
Les messages <wsdl:message name=recupererEtatDemandeRequest> <wsdl:part name=numero type=xsd:int/> <wsdl:part name=distributeur type=xsd:int/> </wsdl:message> Le service & ses oprations <wsdl:portType name=serviceGererLesDemandes> <wsdl:operation=recupererEtatDemande> <wsdl:input=recupererEtatDemandeRequest/> </wsdl:operation> </wsdl:portType>
ESB
recupererEtatDemande
type des parts des messages SOAP est accessible. Si une contrainte du WSDL est plus complexe quune validation superficielle de formulaire, il faudra traiter cette validation avec du dveloppement et ventuellement lutilisation de composants annexes. Lors de lutilisation du style RPC/Literal, seul le message SOAP sera simplifi, car il ne porte plus les instructions dencodage dcodage.
<soap :envelope> <soap :body> <recupererEtatDemande> <numero>42</numero> <distributeur>108</distributeur> </recupererEtatDemande> </soap :body> </soap :envelope>
Le style Document/Literal
Le mode Document/Encoded nest pas du tout reconnu par la norme WS-I et reste une possibilit inusite. Il est bon pour tous de lignorer et un exemple ne servirait pas le propos. Le mode Document/Literal est en revanche important : dans ce mode, le WSDL doit maintenant obligatoirement contenir le schma des messages.
235
Le message SOAP de la figure 16.3 contient les lments NumeroDemande et NumeroDistributeur, lments qui sont dfinis dans un schma. On peut donc valider lensemble du message SOAP en se basant sur le seul schma. Le moteur SOAP ou lESB pourra le faire. Cest la plus-value de ce mode. Il permet la validation des donnes entrantes dun service avec lensemble de la technologie des schmas. Cest une garantie importante pour celui qui passe par exemple un contexte intgralement en paramtre. En revanche, le WSDL est plus complexe crire. Cette complexit est en gnral prise en charge par la sophistication des outils de cration/modlisation. Un autre avantage du mode document rside dans le traitement du message SOAP par le rcepteur : dans le mode Document/Literal, le rcepteur nest pas oblig dattendre davoir reu la totalit du message pour le traiter, il peut le traiter au fil de leau ds la rception des premiers octets. Exprim plus techniquement, ce mode nimpose pas la lecture via DOM du message SOAP, il permet de donner accs ce message via des API plus performantes comme SAX ou StAX. Ce point est crucial pour la mise lchelle et la performance dune infrastructure de WebService. Cette spcificit technique permet galement de matriser la consommation de mmoire des appels de services. Lors du passage au style Document/Literal, le nom de lopration a t perdu. Le code du service doit pouvoir dcider de lopration effectuer selon les donnes
Typage Contrat WSDL riche <wsdl:types> <xsd:schema> <xsd:element name=elementNumero type=xsd:int/> <xsd:element name=elementDistributeur type=xsd:int/> </xsd:schema> </wsdl:types> <wsdl:message name=recupererEtatDemandeRequest> <wsdl:part name=numero element=bo:elementNumero/> <wsdl:part name=distributeur element=bo:elementDistributeur/> </wsdl:message> <wsdl:portType **identique**> <wsdl:binding **style = document use=literal**>
ESB
Validation du contenu
recupererEtatDemande
236
du document. La programmation sera donc potentiellement plus complexe que lors du style RPC. De plus, le message SOAP nest pas conforme WS-I Profile qui interdit plusieurs enfants dans la balise <soap:body>. Cette restriction rend Document/Literal pas toujours conforme. En rsum, ce mode offre deux avantages incontestables, au prix de trois inconvnients : + Linfrastructure SOA est capable de valider les messages reus (vis--vis des schmas XML). + Les performances sont au rendez-vous. Le contrat WSDL du service est potentiellement plus complexe. Limplmentation du service est galement plus complexe (elle doit dcouvrir elle-mme le nom de lopration appele). Ce mode est conforme WS-I Basic Profile sous certaines restrictions.
Message SOAP <soap:envelope> <soap:body> <recupererEtatDemande> <Numero>42</attributNumero > <Distributeur>108</attributDistributeur > </recupererEtatDemande> </soap:body> </soap:envelope>
Typage Contrat WSDL riche <wsdl:types> <xsd:schema> <xsd:element name=recupererEtatDemande/> <xsd:complexType> <xsd:sequence> <xsd:element name=Numero type=xsd:int/> <xsd:element name=Distributeur type=xsd:int/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema> </wsdl:types>
<wsdl:message name=recupererEtatDemandeRequest> <wsdl:part name=parameters element=bo:recupererEtatDemande/> </wsdl:message> <wsdl:portType **identique**> <wsdl:binding **identique**>
ESB
recupererEtatDemande
237
de lopration en lment parent des lments du corps du message SOAP. Cette astuce permet de se conformer au WS-I Basic Profile car cet lment sera la balise <soap:body> contrairement au message prcdent. Un premier intrt, par rapport au mode Document/Literal est de supprimer la complexit de limplmentation puisque le nom de lopration est dsormais prsent dans le message. Dans ce mode, le message en entre a une unique <part> nomme parameters qui doit tre un lment sans attribut et non un type complexe. Le nom de cet lment est le nom de lopration. La conformit WS-I Basic Profile est assure. Le message en sortie aura des contraintes analogues et son nom sera le nom de lopration suffixe par Response , ce qui est une des contraintes de WS-I BP 1.0.
16.3.5
Formaliser les informations transportes dans les messages changs par les services dans un schma XML est payant, cela permet dutiliser des outils de binding lorsque lon traite ces informations sur une plate-forme donne et de faire valider les appels au service. Les dveloppeurs pourront traiter rapidement ces schmas pour faire apparatre les objets de transfert ou directement les objets mtiers utiliss par les implmentations des services. Principe : il est ncessaire dutiliser systmatiquement des schmas pour dcrire ses donnes, la place de simples contraintes de type associes un lment. Ces avantages lgitiment une monte en comptences des quipes de matrise duvre. Lutilisation de style RPC est cantonne lexploitation dexistant RPC encoded utilis pour traiter des graphes dlments. Ce style non conforme WS-I BP 1.1 sera migrer ou traiter comme une contrainte historique. Lusage du style Document/Literal Wrapped est aujourdhui un standard. Bien quun peu plus complexe, il satisfait les critres techniques de performance, cohrence et interoprabilit. Principe : favoriser lusage du mode Document/Literal Wrapped autant que possible. RPC encoded a t largement utilis, il est donc utile de le connatre pour grer lexistant, quitte encapsuler ou faire migrer celui-ci., On peut aussi noter que le style RPC autorise le polymorphisme qui disparatra avec WSDL 2.0. Il sagit donc dune contrainte de compatibilit ascendante. Mais WSDL a le bon got dtre en XML, donc facilement manipulable. Si un rfrentiel de service a t gnr avec des outils, il y a de fortes chances de pouvoir migrer automatiquement lensemble des dclarations.
238
Le W3C offre un outil de conversion de WSDL 1.1 en WSDL 2.0. Cet outil est fourni par le W3C. Il fonctionne dautant mieux que le WSDL est conforme WS-I Basic Profile 1.0. Lintrt en terme de prennit de ces normes est dmontr. http://www.w3.org/2006/02/WSDLConvert.html
RPC/Literal
Impose une lecture DOM des messages, donc des contraintes mmoire.
Document/Encoded
Non conforme WS-I Basic Profile. Messages et WSDL complexe. Le nom de lopration a disparu : le dispatching peut devenir complexe.
Document/Literal
conforme WS-I Basic Profile, mais avec des restrictions. Permet une lecture via SAX ou StAX pour ne pas tre contraint par la taille des messages. Validation du message possible. Conforme WS-I Basic Profile. Validation du message possible. Le nom de lopration accessible.
Document/Literal Wrapped
Wrapped nest pas une spcification WSDL. Mais cela devient un standard de facto. Messages et WSDL encore un peu plus complexe.
En rsum
WSDL est un formalisme de description de service ouvert de multiples technologies. Cest un lment de prennit et de convergence. Il est un moyen dAssurer les enjeux fonctionnels en respectant une approche par les modles. La formalisation WSDL des services Legacy est un plus non ngligeable afin de permettre aux quipes nouvelles technologies de composer avec ces services.
239
La conformit avec WS-I est payante : linteroprabilit est au rendez-vous, ainsi que la performance et la prennit. Lusage du style Document/Literal Wrapped est aujourdhui un standard. Il rassemble les critres techniques de performance, cohrence et interoprabilit. Les outils grent tous les styles ainsi que la conformit WS-I pour la plupart : grce ces outils, utiliser ces normes et les spcificits de WSDL reste simple. Lapproche par les modles qui permet un plus grand contrle des WSDL utiliss semble encore une fois plus adapte.
17
Choisir la technologie dimplmentation
Objectif
Ce chapitre aborde les choix de dploiement des services en fonction des contraintes techniques. Il sagit de ne pas hypothquer la future cartographie technique du SI par des choix trop restrictifs. La matrise duvre doit systmatiser sa rflexion pour avancer le plus tt possible sans avoir connatre toutes les contraintes ds le dbut.
242
Applicatif enregistrerDemande
CRUD Utilisateur
CRUD Demande
Dpend du contexte. On doit se prmunir de choix qui hypothquent le futur et offrir toutes les possibilits. Sans objet : un service CRUD ne doit pas tre directement accessible.
Les temps dappel et dexcution doivent tre ngligeables vis--vis des services appelant.
243
Les services CRUD doivent rester au sein du SI Local et ne gagnent rien tre distribus. Ils seront les reprsentants les plus simples de cette typologie.
244
245
sation des principes SOA sur des infrastructures de petite et de grande taille sans dployer de solution surdimensionne. Dautre part, on trouve aussi des solutions comme WSIF1 qui propose linstar de SCA datteindre un service dfini en WSDL dont limplmentation nest pas limite la technologie Web Service. Ces concepts de solutions SOA lgres procdent toutes des principes OCP (Open Close Principle) du dveloppement Objet : le code doit tre ferm aux modifications et ouvert aux extensions. On veut quune volution mtier ne change pas du code dj test. Seul lajout de code est tolr.
WSIF : un adaptateur de service WSIF, ou Web Service Invocation Framework, est une initiative IBM qui se pose en intermdiaire de lappel au service afin de stabiliser le code appelant et de pouvoir opter pour la performance maximale sans impact sur le code de lapplication mtier. Ce projet a t donn en 2002 la fondation Apache par IBM. On trouve une version encore plus avance dans le serveur dapplication Websphere. Ce composant Java dinvocation de service veut stabiliser le code de lappelant. Lappel du service est uniquement bas sur la partie abstraite du WSDL. Lobjectif de fournir un appel de service standardis est conforme au design Orient Objet et aux problmatiques SOA. Le dveloppeur utilisant WSIF ninteragit pas avec le protocole choisi, SOAP ou autre. Seule linterface dfinie par le WSDL est expose. lappel, WSIF permet par extension du WSDL de dfinir des binding classiques SOAP comme des binding vers JAVA (accs POJO) ou EJB ou JMS. WSIF permet une invocation via un proxy gnr ou dynamiquement dcouvert. Il permet dappeler tout service dfini en WSDL au travers de son API disponible aujourdhui en Java. Au sein du WSDL, on peut dclarer plusieurs binding. Le choix du binding utiliser peut aussi tre dclar lutilisation. Cela permet de configurer les appels de services sans intervenir sur le code applicatif. Les diffrents binding correspondant au SOAP traditionnel ou une extension WSDL sont grs par un composant nomm Provider. Les Providers disponibles grent aujourdhui Java, SOAP, EJB et JMS. Cest le Provider qui gre toute la spcificit technique de ces protocoles et extensions. Grce divers Providers, le changement de moteur SOAP utilis devient transparent au sens du service. Il est possible de crer ses propres providers. WSIF est une solution lgante pour les moteurs BPEL qui doivent appeler des services sans payer systmatiquement le prix dappel WebService au sein de son SI. http://ws.apache.org/wsif.
On cherche la stabilit de lappelant, une continuit annonce du principe CAF qui avance par composition de services (voir le chapitre 5 de la partie 2 sur les variantes de services). Les rponses base de Spring ou WSIF proposent de dployer
1. WSIF : Web Services Invocation Framework. Projet du groupe Apache.
246
ces techniques sans solliciter des infrastructures trs complexes inutilement. Le succs de ces concepts vient de cette simplicit : tout le monde na pas besoin dassurer de la haute disponibilit et des services transactionnels synchrones distribus. Du moins, tous les services du SI nont pas ces contraintes. Cette spcification annonce des produits WSDL-centriques dont la continuit sera SCA, Il sagit doutils et dinfrastructures de composants qui misent sur lavenir du WSDL utilis comme un formalise pivot. Ces outils se conforment aux normes et souvrent aux extensions WSDL pour prendre en compte le plus de diversit technique possible. Les extensions WSDL sont les socles pour offrir de nombreux protocoles et modes de localisation. Ils impactent plus particulirement les parties concrtes des descriptions de services. Cest le cas de WSE1 de Microsoft, qui apporte la compatibilit avec Windows Communication Framework, ou des extensions communment offertes par les ESB : protocole de transfert FTP, MOM, scurit et signature lectronique, etc.
En rsum
La Capitalisation WSDL permet de facilement accder un service quel que soit le mode de dploiement choisi parmi le triptyque WS/Remoting/Simple Composant. Disposer de toutes ces facettes techniques dun service permet ainsi dtre flexible. Les choix de dploiement dpendent des typologies de services et des contraintes techniques des plates-formes de production. Les solutions ESB compatibles SCA permettront de mieux en mieux un assemblage et un appel des services standardiss, conformment la philosophie de Spring. Cette volution dplace la complexit vers ladministration de la plateforme, en suivant lexemple des serveurs dapplication. Enfin, du ct des consommateurs de service, une technologie telle que WSIF, qui prfigure en partie SCA, permet de masquer compltement le triptyque un consommateur : celui-ci invoque le service de faon totalement indpendante du mode de dploiement du service, ce qui reprsente le stade ultime de lindpendance de SOA vis--vis des technologies et des middlewares.
SIXIME PARTIE
248
On notera demble que le prsuppos nest pas dopposer ici SOA et Web 2.0, comme tentent de le faire quelques vanglistes zls ayant dcouvert une nouvelle terre promise. SOA est avant tout une approche durbanisation, de modlisation et darchitecture : elle nest pas lie une technologie particulire mme si les Web Services y jouent un rle important. Le Web 2.0 offre de nouvelles perspectives pour construire une SOA et ce sont ces perspectives qui sont au cur de la prsente rflexion. Pour prciser le primtre de cette rflexion, il faut bien voir que louverture du systme dinformation via le Web 2.0 recouvre deux grandes facettes : une facette fonctionnelle, qui voit la mise en place de nouveaux outils & usages : outils collaboratifs de cration et de partage dinfo : blog, wiki, espace lecteurs des journaux lectroniques; outils de classification collective des infos; rseaux sociaux, etc. une facette architecturale et technique, qui voit lmergence de nouveaux outils et techniques : diteurs de Mashups, composants AJAX, services REST. La rflexion se concentre sur la facette technique, la question centrale tant : peuton faire du SOA avec ces technologies Web 2.0 ? Si oui, comment ? (de la mme faon quil y a 10 ans, la question tait : peut-on faire des applications informatiques client/serveur avec les techniques Web 1.0 ?). La simplicit est un facteur souvent mis en avant par ces vanglistes Web 2.0 : est-ce une promesse tenable ? Lobjectif de cette partie est donc de prsenter ces diffrents concepts et den proposer une analyse aussi objective que possible, en ayant toujours lesprit quun Systme dInformation est un peu plus complexe quun simple site Web. En bref, peut-on commencer parler de SOA 2.0 ? Cette partie comprend deux chapitres. Le chapitre 18 propose une analyse des concepts architecturaux fondateurs des applications interactives du Web 2.0. Le chapitre 19 prsente le style darchitecture REST, et le positionne par rapport au style darchitecture propos par les Web Services.
18
Architectures Web 2.0
Objectif
Lobjectif de ce chapitre est de prsenter lapproche Web 2.0 sur le plan architectural. Il prsente dabord la philosophie SOA du Web 2.0, en pointant les diffrences dapproche avec une SOA classique (cest--dire telle que prsente dans les chapitres prcdents). Puis il propose un zoom sur les outils et technologies permettant de construire un Mashup, cest--dire une application composite Web 2.0.
250
Un Systme dinformation est classiquement structur (cf. chapitre 4, figure 4.5) selon une architecture trois tages : tage applications interactives , tage logique mtier , tage informations & rfrentiels . Lapproche propose jusquici peut tre rsume en disant que SOA structure puis donne accs ltage logique mtier de lentreprise. Lobjectif dune SOA est de construire au sein de cet tage une hirarchie de services, en jouant sur la granularit et la composition de services. Ces services sont utiliss par des applications composites : processus ou applications interactives. Pour construire ces services, on mixe plusieurs approches : approche top down : identifier les services applicatifs ncessaires pour les applications, ce qui implique de modliser ces applications clientes (cf. chapitres 9 et 10); approche bottom up : identifier les services CRUD permettant daccder aux informations mtier, en particulier les informations structures (stockes dans les bases de donnes relationnelles); approche meet in the middle : identifier les services fonctionnels, construire les services applicatifs par composition de services (CRUD, fonctionnels, techniques). Le Web 2.0 propose une vision quelque peu diffrente. Tout part en fait des donnes. Ces donnes ont en gnral deux caractristiques : dune part elles ne sont pas ou peu structures (il peut sagir de documents, dimages, de vidos, etc.), et dautre part elles sont distribues dans diffrents sites Web (comme ceux de Google, Amazon, Wikipdia, eBay, etc.). Le premier objectif du Web 2.0 est dabord de fournir tout un chacun ces donnes, via lapproche architecturale REST. Il sagira, en bref, de mettre en place des services daccs CRUD aussi simples que possible. Le second objectif est de permettre de construire, aussi rapidement que possible, des applications exploitant ces services daccs : cest le concept de Mashups. Un Mashup est une application composite au sens strict du terme, puisquil sagit de combiner plusieurs services (REST principalement, mais pas uniquement) pour construire une application finale. Cette application est excute dans un contexte navigateur Web et sappuie fortement sur JavaScript. Si lon revient la structuration en tage du SI, voque en dbut de section, alors on peut dire que, via le concept de Mashups, et la technologie AJAX, le Web 2.0 ouvre ltage applications interactives aux internautes. Via le concept REST, le Web 2.0 propose une nouvelle faon daccder aux informations de ltage bases dinformations . La figure 18.1 prsente cette approche en regard de lapproche SOA classique . Elle suppose quun Mashup peut aussi bien tre utilis par un internaute pour interagir avec lentreprise, que par un salari au sein mme de lentreprise.
251
Applications Composites Mashup Application Interactive Application Interactive Front Office Application Interactive Back Office Processus Mtier Mashup Mashup
Service
Service
Service
CRUD REST
CRUD REST
Les sections suivantes prsentent une analyse architecturale de lvolution des applications interactives via le Web 2.0.
18.2.1
Un exemple reprsentatif
Dans le cadre de lexemple gnral Fil Rouge, prsent au chapitre 7 (section 7.2), un exemple classique dun Mashup consistera visualiser sur une carte (gographique ou satellite) les Points De Distribution, ou PDD, (cest--dire les compteurs gaz et/ou les compteurs lectriques), approvisionns par un producteur X et situs sur une commune dont lutilisateur du Mashup aura saisi au pralable le nom. Cest un Mashup, orient SI, puisquil sagit dagrger des informations gographiques peu structures (une carte) et des descriptions structures (la description de chaque PDD). La logique de cette application est dcrite dans le tableau 18.1.
252
tape 2
tape 3
tape 4
Il existe de nombreux fournisseurs de carte, dont le premier a t Google Maps, mais aussi Yahoo Maps, via Michelin, etc.
tape 5
Ce type dexemple, bien que simple, est dsormais trs courant, avec lexplosion de lusage des informations go rfrences, non seulement sur le Web, mais aussi dsormais sur les tlphones mobiles accdant au Web et au GPS. La figure 18.2 donne un exemple de rendu, construit avec Google Maps .
253
18.2.2
Mashup et SOA
On constate limportance de lorientation Service pour construire un Mashup. Mais en quoi cet exemple se distingue-t-il des applications composites classiques, dcrites au chapitre 10 ?
Interoprabilit
Une application faisant appel des services est dpendante de ces services sous trois aspects : elle dpend du nom de lopration invoque : getMap(), rechercherDpartementsDeFrance(), etc.; elle dpend de la localisation du service (son adresse), mais sur ce point il ny a pas de diffrence fondamentale entre les approches; elle dpend de la dfinition et du format des informations changes via cette opration. Un Mashup invoque un service en respectant la philosophie REST (prsent au chapitre 19) : on notera que cette philosophie implique que le nom des oprations soit standardis, contrairement une approche SOA classique. Ces noms standardiss sont en fait ceux des commandes HTTP (GET, POST, etc.). Un Mashup ne dpend donc pas du nom des oprations offertes par un service REST. En revanche, elle dpend fortement du format des informations, cest--dire de la faon dont ces informations sont encodes pour voyager sur la toile. A priori, cet encodage devrait tre bas sur XML. Cependant, XML tant considr comme complexe par certaines communauts Web 2.0, les services REST renvoient souvent leurs informations encodes selon des formats supposs plus simples. Un format populaire est le format JSON. JSON veut dire JavaScript Object Notation. JSON est un format textuel reprenant le formalisme des objets JavaScript. Autrement dit, JSON est un moyen de transporter des objets JavaScript en les srialisant/d-srialisant. Voici un exemple dencodage JSON :
{"localisation" : {"id" : "36290", "commune" : "MeziereEnBrenne", "destination" : "maison de la pisciculture", "adresse" : "3 place de la mairie" } }
Dans la perspective adopte dans ce chapitre, lintrt est quun document encod en JSON est immdiatement transformable en un objet JavaScript, donc manipulable facilement par tout script JavaScript, cest--dire par tout Mashup. La mthode la plus immdiate (et la plus rapide) pour ce faire est :
Var monObjet = eval(document_json);
254
Mais si le document contient un code malicieux, eval conduit une catastrophe. La mthode prfrable est dutiliser un parseur disponible sous JavaScript, qui nexcute pas mais dcode et transforme. On fera cependant attention aux performances dudit parseur .
Ergonomie
Lobjectif des crateurs des premiers Mashups tait non seulement fonctionnel : lagrgation dinformations, mais galement technique : une ralisation aussi simple et aussi proche du Web que possible, et compltement indpendante des querelles de chapelle linguistiques (Java versus C# versus PHP versus Ruby, etc.). Pour satisfaire cet objectif, la construction des Mashups sappuie fortement sur les standards du Web : HTML et JavaScript. Construire lapplication dcrite dans le tableau 18.1, cest, dans la logique Web, avant tout crire des pages HTML (pour laffichage des informations et le dialogue homme-machine). Cependant, ce retour aux sources du Web 1.0 est apparu insatisfaisant : le dialogue Web classique (cest--dire via le protocole HTTP) oblige chaque interaction utilisateur recharger une page HTML complte, et de plus offre des composants graphiques limits et plus que rustiques. Cest la raison pour laquelle est apparu AJAX, cur architectural du Web 2.0 et des Mashups, et objet de la prochaine section.
255
recherch, le composant lance une requte de recherche (sans rechargement de la page accueillant ce composant) et affiche le rsultat dans une liste (liste pagine de surcrot, puisque la liste obtenue peut tre longue).
Champ de saisie
dpartement
A|
Rsultat de la recherche
18.3.1
256
Cette manipulation seffectue via DOM, Document Object Model. DOM spcifie comment les lments dune page HTML sont manipulables directement dans une fonction JavaScript.
On dfinit ensuite, toujours dans la page HTML, lendroit o sera affiche la carte :
<div id="google_map_div" style="width : 500px; height : 300px">
</div> Puis on dfinira (dans la page HTML), les fonctions JavaScript ncessaires. La premire fonction est la fonction appele lors du clic sur le bouton : recupererPDDEtAfficherUneCarteAvecAjax(). Code exemple : <script language="javascript" type="text/javascript"> var requete = new XMLHttpRequest(); function recupererPDDEtAfficherUneCarteAvecAjax() { //tape 1 requete.open("GET", URL du service de recherche PDD, true); //tape 2 requete.onreadystatechange = ajaxCallback_AfficherCarte; //tape 3 requete.send(null); } Premire tape de cette fonction : elle prcise lobjet XMLHttpRequest le service invoquer (il sagit du service de recherche des PDD). Deuxime tape : elle prcise cet objet XMLHttpRequest la fonction callback que lobjet devra appeler une fois que le service invoqu aura renvoy son rsultat. La fonction callback affichera le rsultat obtenu. Troisime tape : la fonction demande lobjet XMLHttpRequest de sexcuter, cest--dire denvoyer la requte au service. La fonction callback, ajaxCallback_AfficherCarte, affichera une carte puis les diffrentes adresses. Elle utilise pour cela des objets et fonctions JavaScript, notamment lobjet reprsentant une carte, GMap2, qui sont fournis par Google (ou le fournisseur choisi). Voici ce que serait cette fonction (dans une version simplifie pour le propos) :
257
function ajaxCallback_afficherCarte() { //la fonction cre une nouvelle carte via un objet javascript GMap2 //(dfini par Google), en prcisant cette carte o elle doit //safficher dans la page HTML var carte = new GMap2( document.getElementById("google_map_div")); //le rsultat de la requte est disponible dans lobjet XMLHttpRequest : //var resultat = requete.responseText //pour chaque adresse de PDD dans le rsultat, la fonction cre //et affiche ce que Google appelle un marqueur, cf les objets //de lillustration 18.2. Les fonctions de cration de marqueur : //Gmarker(), et daffichage dun marqueur sur une carte : addOverlay(), //sont fournies par Google. For(i=0; i< resultat.length; i++){ var adresse = resultat.localisations.localisation[i].adresse var marqueur = new GMarker(adresse); carte.addOverlay(marqueur);} } </script> La figure 18.4 synthtise ce principe de fonctionnement.
event
5 1
Function (associe lvnement)
XmlHttpRequest
CRUD
CRUD
CRUD
258
Les principes prsents ici paraissent simples et ils le sont. Cependant, lorsquil sagit de dvelopper des comportements plus sophistiqus (champ auto compltant), les choses se compliquent nettement. Do lapparition de bibliothques de composants AJAX, prtes lemploi (ou presque), sous forme de tag HTML, telles que DOJO, PROTOTYPE, SCRIPTACULOUS, DWR, et plus rcemment JQUERY, EXT Chaque composant dune telle bibliothque encapsule le principe dcrit ci-dessus : il contient les fonctions JavaScript ncessaires (dont la fameuse fonction callback), et il est (souvent) associ un tag permettant une insertion aise dans une page HTML.
18.3.2
Une application AJAX conduit donc naturellement envisager de connecter directement le navigateur (plus exactement un composant AJAX) un service CRUD distant. On en revient donc une architecture qui ressemble furieusement une architecture de type client/serveur, avec un client plus ou moins lourd. Sous couvert de revenir techniquement aux fondamentaux du Web via HTML et JavaScript, on peut donc lgitimement se demander si, au contraire, AJAX ne sen loigne pas sur le plan architectural. Le Web 1.0 a en effet permis de (re)centraliser sur des serveurs les applications interactives, via les architectures JEE par exemple, et les frameworks associs. Ceci a permis de rsoudre un certain nombre de soucis endmiques du client/serveur, que ce soit en termes de performance des changes client/serveur, de monte en charge, ou de dploiement dapplication. Or, le Web 2.0 disloque ce type darchitecture, en localisant une partie des traitements applicatifs ct navigateur Web, cest--dire ct client. Par ailleurs, les services CRUD invoqus via AJAX seront dune granularit plus ou moins faible. De plus, laccs ce type de service sera frquent, puisque le nombre de clients sera lev. En bref, cest peu prs tout ce qui a t dnonc comme des pratiques risque dans les chapitres prcdents, notamment sur le plan des performances. On remarquera enfin que JavaScript a une rputation sulfureuse de langage non industriel , contrairement Java, C#, ou mme PHP. Il est vrai que pendant longtemps JavaScript a souffert dun manque doutils (dbogueur, outils de tests, diteur de code volu). La situation a volu, mais reste moins satisfaisante que pour dautres outils. De plus, obliger le dveloppeur matriser JavaScript, cest lobliger tre bilingue, puisquil devra galement connatre Java ou C# ou (voire trilingue si on y ajoute XML ou une variante). On voit donc quAJAX pose des problmes architecturaux indniables dans le cadre dune SOA. Mais les qualits ergonomiques des applications AJAX sont elles seules un argument puissant en faveur de cette approche, AJAX devrait sinscrire durablement dans le paysage des applications y compris de gestion. Il est donc ncessaire
259
de gommer les inconvnients indniables que lon vient de dcrire. Le paragraphe qui suit liste les rponses apportes par la communaut du Web 2.0.
18.3.3
260
Face ce dsordre, deux approches sopposent : la premire sappelle tout sur le client et la seconde tout sur le serveur .
RIA ou RDA ?
Cette approche tout sur le client est clairement un retour au client/serveur base de client lourd, mme si la prsence du navigateur fait croire une approche client lger .
261
On parle dailleurs dapplication riche (RIA pour Rich Internet Application), et non plus lgre. Si on sintresse cette approche, autant alors sintresser des technologies matures telles que FLEX dAdobe, qui de plus bnficie de la prsence de bons frameworks MVC tels que PureMVC. Et pourquoi alors sembarrasser du navigateur, qui impose quelques contraintes fortes ? Cest prcisment la dmarche dADOBE avec son offre AIR1, qui peut sinterprter comme AIR = FLEX sans le navigateur Web . Dans ce cadre, la distinction RIA versus RDA (Rich Desktop Application) nexiste plus rellement.
Approche tout sur le serveur La seconde approche, tout sur le serveur , consiste proposer au dveloppeur un framework lui permettant de dvelopper une application vnementielle en Java, ct serveur. Mais au lieu de sexcuter effectivement du ct serveur, lenvironnement associ au framework contient un compilateur qui va gnrer partir du code Java, le code JavaScript embarqu dans les pages HTML envoyes au navigateur. Lapproche tout sur le serveur est donc une appellation un peu trompeuse, puisque lapplication sexcute en partie ct client. Cette approche est reprsente par le framework GWT (Google Web Toolkit).
Lobjectif est donc de concilier les avantages dAJAX (bonne ergonomie de lapplication, programmation vnementielle) tout en bnficiant dune approche plus industrielle (la programmation seffectuant en Java, GWT masque compltement au dveloppeur le JavaScript et la manipulation de composants AJAX).
Application composite
Services
Lefficacit de cette approche en termes de performance dpend de la qualit du compilateur et de larchitecture sous-jacente. Lintrt indniable de cette approche
1. Adobe Integrated Runtime.
262
doit donc tre tempr par la ncessit de contrler les performances de lapplication produite. GWT suscite beaucoup dintrt, car il pourrait rconcilier les tenants du Web 2.0 dune part, et les nostalgiques de la programmation vnementielle des clients lourds et de sa puissance expressive. Lessor du poids lourd Google laisse esprer un avenir intressant ce framework.
Dvelopper un Mashup reste encore une affaire de techniciens. Cependant, certains acteurs importants du Web, et non des moindres, essaient de promouvoir des diteurs de modlisation graphique et de gnration de Mashups. On citera Yahoo avec Yahoo Pipes, IBM avec QEDWiki, Microsoft avec Popfly Lide de dpart est la suivante : on remarquera quun Mashup, tel que celui dcrit dans lexemple du tableau 18.1, est en fait une sorte de pipe ( la Unix) : le Mashup reoit un premier flux dinformation (la commune), utilise ce flux pour rcuprer un deuxime flux (les adresses) et enfin injecte ce deuxime flux dans une carte.
Un diteur de Mashups tel que Yahoo ! Pipes (cf. figure 18.6) fonctionnera donc idalement de la faon suivante :
263
le dveloppeur de Mashups slectionne un ou plusieurs flux dinformation dentre , en prcisant le type de flux (flux RSS, flux WS-*, flux JSON, etc.); le dveloppeur applique ce ou ces flux des oprations logiques : slection dune information particulire dans le flux (le code postal par exemple), tri ou filtre des informations, slection ou au contraire agrgation dinformation, etc. : lobjectif tant dobtenir un flux dinformation rsultat ; le dveloppeur slectionne un objet graphique pour visualiser ce flux rsultat ; enfin, le dveloppeur via loutil donne un nom au Mashup et le transforme en un widget que lon peut afficher dans un agrgateur de flux (cf. le paragraphe suivant). On remarquera au passage quun diteur de Mashups digne de ce nom est accessible via le web : ce nest pas un client lourd la ECLIPSE ou Visual Studio. Pour que cette approche ait un quelconque intrt dans le cadre dune SOA oriente SI, lditeur de Mashups doit satisfaire quelques critres fondamentaux. Loutil doit en priorit permettre de travailler sur des flux dinformations structures, et pas uniquement des flux dinformation de type news issus de blog, de wiki, etc. Ces flux structurs proviendront des bases de donnes SQL, ou de Web Services dcrits en WSDL. Les objets graphiques ne peuvent pas tous tre des cartes la Google Maps : lditeur de Mashups doit donc permettre de construire des objets graphiques daffichage de rsultat, tels que des formulaires (affichage de donnes issues des bases de donnes) ou des graphiques (affichage de chiffres, statistiques, etc.). Enfin, il doit tre simple dutilisation. Le nud du problme est l : il faudra (pour linstant ?) choisir entre simplicit et richesse des informations traites. Du plus simple (Yahoo Pipes !, Open Kapow, Dapper) aux plus sophistiqus (Jackbe1, Datamashups2, BEA Aqualogic Pages3), les outils ne manquent pas : il conviendra donc dajouter aux critres numrs ci-dessus, le critre industriel de prennit, bien que ce critre comporte toujours une part de subjectivit. Certains critiquent cette approche Mashups en trouvant ce type doutil trop simple pour les dveloppeurs dentreprise, et trop complexe pour les utilisateurs finaux . Cependant, la prolifration des macros Excel ou VB dans les entreprises devrait convaincre que beaucoup dutilisateurs finaux sont aptes utiliser un outil de dveloppement pourvu que celui-ci soit adapt leur besoin. Et la pression qui pse sur les paules des dveloppeurs les rend ouverts aux outils de productivit mme sils ne sont pas parfaits.
1. http://jackbe.com/ 2. http://datamashups.com/ 3. http://www.bea.com/enterprise/pages
264
En conclusion, on conseillera donc dvaluer cette approche sur des besoins SI certes simples, mais rels : on pense par exemple lencapsulation dun moteur de recherche, lutilisation de cartes gographiques, ou laffichage de donnes de type tableau de bord dcisionnel synthtique .
18.4.2
Certains sites dagrgation destins au grand public permettent dintgrer trs facilement des Mashups sous la forme de pages composites. Les plus connus sont Netvibes ou iGoogle. Ces sites offrent une bibliothque de Mashups sur tagres, gnralement intitules Widgets , que lon positionne dans la page par simple drag and drop. Cette approche Web 2.0 pour la construction de portails personnaliss connat un tel engouement quelle influence les offres de portails des grands diteurs (Microsoft, BEA, IBM, etc.). De plus, les acteurs du Web 2.0 ont normalis le format des Widgets sous la norme UWA (Universal Widget API). Cette norme connat, elle aussi, un fort engouement et est en cours dimplmentation par les grands diteurs.
19
REST et Web Services
Objectif
Ce chapitre se propose de prsenter REST et danalyser cette solution en comparaison avec une approche Web Service. La complexit est un reproche souvent fait aux technologies associes aux solutions SOA. Ce nest pas compltement injustifi, mais le prsent ouvrage prvient le lecteur : si le mtier na pas denjeux douverture dentreprise, de besoin de structuration du SI, ni de pilotage par les processus, alors cette complexit ne sert personne. En revanche, sil faut orchestrer le SI, le structurer et le prparer une ouverture matrise, alors il faut sattendre payer lentre dans une dmarche SOA. La vraie complexit est dans limpact sur lorganisation, mais certaines communauts incriminent la galaxie des normes WS-* et les fameux Web Services, derniers reprsentants du vice de complexit en date. Cette perception est largement due une utilisation nave de ces technologies : sans typologie de service, la granularit fait faire systmatiquement les pires choix de performances, surtout si on considre lanti-pattern SOA=Web Service, dnonc plusieurs fois dans cet ouvrage. Reste que la mise en uvre des technologies au service dune SOA comprend des complexits la hauteur des enjeux mtiers associs. En revanche, il existe une riche gamme de rponses technologiques, plus ou moins complexes, qui traitent telle ou telle partie du cahier des charges techniques SOA. Parmi ces technologies, on trouve deux grandes familles a priori opposes. Dun ct les Web Services et les normes WS-*, parangon de la complexit et de la richesse, et de lautre ct, larchitecture REST et sa philosophie de la simplicit.
266
Le dbat REST contre les solutions WS-* est-il un simple dbat technique ? A priori non. Ce chapitre dcrypte les deux aspects fondateurs des divergences de ces approches. Le premier aspect est effectivement technique : REST choisit dlibrment des directions opposes des principes de SOAP, avec des succs et des limites quon dcouvrira ci-aprs. Lautre aspect concerne les modles architecturaux reprsentant les interactions entre systmes : les solutions WS-* sont guides par les verbes (les oprations offertes par les services) alors que le monde REST voit les systmes dinformation comme un ensemble de noms , ou de choses (cest--dire les ressources informationnelles de lentreprise, vues comme des entits navigables). Avant de prsenter ces deux aspects, le chapitre propose une rapide introduction aux principes de REST.
267
Client HTTP
http://www.masociete.com/contrats/chombier
1
GET
2
rponse
Serveur HTTP
que la page reprsente la ressource (au sens ensemble dinformations lmentaires) associe ltat. Si lutilisateur utilise un hyperlien affich dans la reprsentation du contrat, cest-dire dans la page HTML associe au contrat, il quitte ltat associ la reprsentation de la ressource contrat pour accder un autre tat, associ une autre ressource, par exemple la liste des dernires factures . Autrement dit, la navigation typique du Web est assimile des transferts dun tat un autre tat, chaque tat tant li la reprsentation (HTML, XHTML, etc.) dune ressource informationnelle. Do le nom : REST = REpresentational State Transfer. REST nest pas un standard, mais un style darchitecture. Le Web est un bel exemple de systme base de REST cest mme larchtype du style REST ! La plupart des services existants, dont certains de longue date (depuis 1995 environ), commande de livre, dictionnaires en ligne, services de traduction, etc. sont des Services REST. Nous sommes tous les monsieur Jourdain du Web ayant de grandes chances davoir dj utilis REST sans le savoir. Ceci explique que toute implmentation informatique se voulant conforme REST repose sur les standards du Web et certains standards documentaires classiques : HTTP (pour le protocole et les services lmentaires daccs aux ressources), URL (pour la localisation des ressources), XML/HTML/XHTML/GIF/JPEG/, etc. (pour la Reprsentations de Resource), text/XML, text/html, image/gif, image/jpeg, etc. (pour les Types de Ressource, Types MIME).
268
Client HTTP
http://www.masociete.com/produits/optomahd70
1
GET
2
rponse
Serveur HTTP
le dtail dun produit : get detailed information about a particular part ; la mise jour dun produit; la commande dun produit : submit a Purchase Order Cette requte sappuiera sur un POST; la suppression dune commande. La figure 19.3 montre (de faon simplifie) comment ces services seront implments avec le style REST, et leur quivalent en Web Services.
Style WS-*
lireCatalogueProduits()
mettreAJourProduit(produit)
creerCommande(commande)
supprimerCommande(IdCommande)
Accs en lecture Dans une implmentation REST, il ny a pas vraiment de services daccs linformation : cest la ressource elle-mme qui est accessible par un simple GET. Si on
269
prend lexemple de la lecture de la liste des produits, cette lecture seffectuera en invoquant lURL suivante :
http://www.masociete.com/produits
Cette invocation se traduit classiquement dans le monde WEB par une requte HTTP GET. La rponse cette invocation est une ressource dont le type repose sur un standard du Web, par exemple, une page HTML ou un document XML. Si besoin, il est possible de paramtrer les services de lecture pour avoir tel ou tel type de sortie, par exemple avec un paramtre de requte HTTP :
http://www.masociete.com/produits?format=xml
Si on veut utiliser REST en lieu et place des WS-* pour mettre en place des services de lecture dinformation, la rponse sera encode en XML. Lexemple ci-dessous est le document XML catalogue des produits .
//liste des produits, en XML, avec des liens xlinks (norme) en plus des ids < ?xml version="1.0" ?> <cat :catalogue xmlns :cat=http://www.mondepot.com xmlns :xlink=http://www.w3.org/1999/xlink xmlns :xsi=http://www.w3.org/2001/XMLSchema-instance xsi :schemaLocation="http://www.mondepot.com http://www.mondepot.com/ catalogue.xsd"> <cat :produit id="00042" xlink :href="http://www.mondepot.com/produits/ 00042"/> <cat :produit id="00108" xlink :href="http://www.mondepot.com/produits/ 00108"/> <cat :produit id="00666" xlink :href="http://www.mondepot.com/produits/ 00666"/> <cat :produit id="00747" xlink :href="http://www.mondepot.com/produits/ 00747"/> </cat :catalogue>
On remarquera que le document XML catalogue contient, pour chaque produit, dune part lidentifiant de ce produit, mais galement un hyperlien vers la description (la reprsentation si on veut tre puriste) dudit produit. En XML, cet hyperlien est signal par lattribut xlink. Lapplication catalogue Web effectuera la lecture dun produit en invoquant cet hyperlien, cest--dire lURL prsente dans le document prcdent :
http://www.masociete.com/produits/00042?format=xml //dtail en GET ! ! !
270
On note la cohrence dans les ressources appeles et leur reprsentation : des liens successifs, exprims via xlink, sont utiliss soit pour donner accs un ensemble de rsultats, soit pour donner accs au dtail des reprsentations offertes lutilisateur. Cette dmarche de dcouverte dynamique est particulirement adapte des changes internaute informations Web. On notera aussi quon nexpose pas des ressources physiques, mais toujours des ressources logiques, via le mcanisme dURL. Limplmentation de laccs ces ressources offre donc un niveau de dcouplage suffisant pour permettre de tout changer ct serveur. Et ce, mme si lurl change, car on peut utiliser par exemple la rponse HTTP 302 moved pour signaler lapplication cliente ce changement dURL. Ce dernier exemple montre lintrt de lapproche REST : en sappuyant pleinement sur HTTP (non seulement sur les request mais aussi sur les response), il est possible de faire face des situations dvolution du SI pas forcment triviales.
Recherches complexes Reste maintenant aller au-del de ces premiers exemples relativement simples : quid dune requte du monde rel, avec des vrais filtres lis un acte mtier ?
Comment par exemple reprsenter la requte donnez-moi les franchises suprieures 200 euros associes aux objets assurs de type vranda dans le contrat habitation de Mr Chombier . Est-ce reprsentable avec la fameuse technique de lURL simple et sympathique ? La rponse est oui jusqu un certain niveau.
http://www.masociete.com/contrat/chombier/habitation/risque/veranda/franchises ?montantmin=200
ou bien :
http://www.masociete.com/contrat/chombier/habitation/franchises ?risque=veranda&montantmin=200
271
Mais la philosophie REST nous demande de nous prparer aux requtes dune certaine complexit en proposant un formulaire dchange, remplir par lappelant. Les rponses seront encore une fois une reprsentation contenant des liens vers les dtails utiliser. De cette manire, les URL compliques qui demandent une connaissance de la manire dont nous nous organisons en offrant nos services ne sont pas gnres par les clients, mais par le fournisseur
Cration dun objet mtier Comment crer une nouvelle ressource, par exemple un nouvel objet mtier commande , puisque par dfinition, cet objet, avant sa cration, nexiste pas et na donc pas dURL ?
La solution REST propose est en gnral de mettre disposition une URL spcifique de la cration dun objet mtier. Cette URL est invoque via une requte POST, qui transportera la description de lobjet crer. Cette description sera un document XML, produit par un internaute via un formulaire HTML (on revient la soumission classique dun formulaire Web). Ce document peut aussi tre produit par un SI externe. En reprenant lexemple du fabriquant de produit, le service REST de commande dun produit se traduira par la publication dune URL de soumission dune commande. Lapplication cliente doit crer (via un formulaire ou un programme) une instance XML conforme la description dune commande. Le service de commande devra rpondre, aprs cration de la commande, par lexposition dune URL daccs la commande cre. Ceci permettra ensuite au client de retrouver sa commande plus tard. La commande est alors devenue une ressource partage identifie par URI. Conforme la description dune commande , a-t-on dit : mais comment garantir que lapplication cliente va mettre une commande conforme ? Il faut pour cela que la description XML de la commande soit conforme un format dcid lavance, on parle de format pivot : dans ce contexte, ce sera un schma XSD dcrivant une commande type. Cest la contrainte dinteroprabilit classique permettant un client et un service de se comprendre mutuellement. Dans le monde des WS-*, la norme WSDL est la rponse cette contrainte : elle permet de dcrire et de publier ces schmas de conformit. Mais dans le monde REST ? Ce problme, aprs avoir t ni, a fini par tre reconnu comme un vrai problme. Un dbat sest mme engag sur lopportunit dutiliser WSDL pour cela. On parle aussi de WRDL (Web Ressource Description Language), car des absolutistes de REST trouvent WSDL trop WS-* centric, et souhaitent une approche plus simple et (surtout ?) ddie. Le schma dcrivant une commande serait alors rendu public dans le contrat de service via WSDL, ou WRDL, ou via un simple document schma XSD hberg par le site web. Lintrt dun langage comme WSDL ou WRDL est de proposer ensuite des serveurs prts lemploi (SOAP/ WSDL ou REST/WRDL) capables de vrifier eux-mmes la conformit dune requte au schma de description. Si on utilise un
272
Client HTTP
http://www.masociete.com/produits/commande
PO.xml
Conformit PO.xsd
... /produits/commande/po571842
POST
rponse
simple schma WSDL, ce sera au ralisateur du service de cration de commande de vrifier en premier lieu que la commande est bien conforme. Linstance XML de commande est transmise, comme on la vu, comme une donne transporte par une simple requte HTTP POST. On retrouve ici des caractristiques bien connues de lunivers WS-* et des messages bass sur SOAP. Les prcautions prendre sont donc les mmes que dans les appels distants de type SOAP : trouver le moyen de garantir les paramtres dappel et un nommage ou une reconnaissance de lopration appele ( comparer avec le Document/Wrapped mentionn lors du chapitre 5). La diffrence entre REST et WS-* est donc beaucoup plus tnue que les vanglistes du WEB 2.0 veulent bien le reconnatre, en tout cas sur cette gamme de services ralistes que sont lappel dune opration de recherche complexe ou de cration/affectation, cest--dire les services dont la smantique dpasse le simple nom de la ressource.
Caractristiques En conclusion, les caractristiques dun rseau bas sur REST sont les suivantes :
Tout le systme est compos uniquement de ressources, et chaque ressource est nomme par une URI. Linteraction avec le systme est de type client-serveur, synchrone, par systme de pull .
273
Linterface dinvocation est standardise et uniforme pour toutes les ressources (i.e., HTTP GET, POST, PUT, DELETE). Linvocation dune ressource est sans tat : chaque requte cliente a toute linformation ncessaire pour la comprendre et ne repose pas sur un contexte stock sur le serveur. Toute rponse une invocation doit tre capable dtre identifie comme cachable ou non-cachable afin de permettre de matriser la performance. Les reprsentations (clientes) des ressources sont lies par des URL pour permettre aux clients de progresser dun tat un autre.
19.2.1
Du point de vue du dfenseur de REST, la sentence est sans appel. REST rsout tout et les Web Services nous font perdre du temps et de largent.
274
Les intermdiaires et mdiateurs du Web ont besoin de requtes claires : proxy, filtrages durl, cache, etc. Les changements dtats et les options de continuits sont clairs en REST et lutilisation de xlink permet mme leur accs des acteurs automatiques. Limposition du POST par SOAP droute tous les mdiateurs classiques du Web. Dans le monde WS/SOAP, cette connaissance doit tre apprhende par le client. Linterface gnrique la REST a tout pour sduire, notamment les applications dveloppement rapide de style Mashups, qui demandent un accs normalis au SI. GET/POST/PUT/DELETE sont encore un avocat de la simplicit de REST dans le domaine Web. WSDL et SOAP offrent potentiellement une smantique spcifique chaque interface de service dploye. Certains y voient le critre dinteroprabilit de REST sur le Web. Par analogie, SOAP fait ici preuve dingrence technique. Prenons le cas dun service courrier : toutes les dcisions de routage des courriers se font sur la lecture des informations extrieures lenveloppe, REST serait alors analogue la poste, alors que WS/SOAP nous proposerait de fonctionner en ouvrant tous les courriers. Une premire solution pour le monde des WS-* concerne la mise en place de la norme WS-Transfer. Cette norme veut en effet permettre denrichir les changes SOAP avec des URL et des mthodes standardises bases sur les mthodes HTTP. La simplicit REST dans le monde WS-* ? Une veille active sur lavenir de cette norme simpose. Une solution plus gnrale pour SOAP pourrait tre une volution vers le fameux Web smantique, qui permettrait des acteurs automatiques de dcouvrir le fonctionnement des messages SOAP, leur sens. Ce nest pas lentreprise aujourdhui de faire de la veille sur le Web smantique, et on laissera cette approche technologique faire ses preuves, probablement moyen/long terme.
19.2.2
Attention : interoprabilit, transitions claires, utilisation maximale des intermdiaires, les caractristiques allchantes de REST sont bases sur le Web uniquement ! Cest--dire un monde client / serveur strictement synchrone. Or, les accs asynchrones de MOM, JMS, SMTP et autres offrent des proprits supplmentaires : asynchronisme, multicast, robustesse, fiabilit, etc. Lapproche message a sa propre lgitimit, que lapproche Web ne remet pas en cause. Le monde WS-* a reconnu cette lgitimit, pas le monde REST. REST versus WS-* est donc dans les faits plutt une opposition REST vs SOAP. Nous tombons dans un problme technique, principalement sur le fait que les tnors du Web veulent construire sur le Web par essence synchrone et rien dautre.
19.3 Recommandations
275
Un autre point important : malgr les dbats et initiatives autour de WRDL, le monde REST continue de voir les annuaires de services comme des chimres inutiles : UDDI est bien trop compliqu, son protocole daccs est largement suppl par un bon fichier WRDL/WSDL et autres schmas derrire un honnte serveur HTTP. On reconnatra que ce constat nest pas faux : autant WSDL & SOAP (contrairement ce qui est crit ici ou l) sont largement utiliss dans le monde du SOA dentreprise, autant UDDI na pas eu le mme succs. Cependant, WS-* ou REST, se pose de la mme faon le problme du versioning, de la dcouverte dynamique dun service, etc. La seule rponse REST est que les ressources se dcouvrent par requtes successives via des contenus RDF/RSS qui guident le client vers la bonne ressource de manire explicite, ce qui veut dire en fournissant des URL au sens REST. La robustesse de la simplicit peut se payer par un nombre croissant dallers retours. Et RDF nest pas encore dun emploi trs rpandu
19.3 RECOMMANDATIONS
REST reprend linfrastructure en place en termes de cache/scurit (premier niveau), accs HTTP et connectivit dynamique sans grande planification. Les problmes sont lorthogonalit avec lexistant Web et la philosophie Web uniquement (proxy, cache, etc.). Dans une architecture strictement Internet (mise en place de site Web, etc.), SOAP pose plusieurs problmes : URI cache dans lenveloppe (gr par WS-transfer/adressing); objectif/mthode cache dans lenveloppe; oprations spcifiques (oppos GET/PUT/DELETE/POST). REST permet de respecter les fondamentaux techniques de larchitecture Web et den bnficier. Si lon souhaite utiliser REST, quelques recommandations simposent :
Bonnes pratiques REST Pour les usages Web centric, voici le rsum des bonnes pratiques REST : 1. Toute ressource expose doit tre identifie par une URI. 2. Prfrer les URI logiques aux URI physiques : http://www.masociete.com/gizmos/747 (souhaitable) http://www.masociete.com/gizmos/747.html (moins souhaitable) Les URI logiques sont des interfaces de faades pratiques pour modifier limplmentation sans prvenir le client. 3. En corollaire, utiliser des noms dans les URI, la place de verbes. Les ressources sont des choses et non des actions.
276
4. Toute requte GET doit navoir aucun effet de bord. Elle doit rester safe . 5. Utiliser des liens dans vos rponses aux requtes ! En connectant votre rponse dautres ressources, vous permettez vos clients dtre autoguids sur la suite des oprations. (En opposition avec tout est dcider avec les donnes fournies ). 6. Minimiser lutilisation de Query String : http://www.masociete.com/gizmo/747 (souhaitable) http://www.masociete.com/gizmo?gizmo-id=747 (moins souhaitable) Laccs direct au dtail de la demande de ressource est plus efficace que daller chercher ce qui est demand dans la query String. 7. Utiliser le / dans une URI pour reprsenter une relation parent/enfant, matre/ dtail, composite/composant. 8. Fournir les accs graduels aux donnes aux clients : une reprsentation devrait fournir des liens pour obtenir ses dtails . 9. Toujours utiliser GET lorsquil sagit de fournir une reprsentation. Ne pas utiliser POST.
Avant de gnraliser REST dans une SOA dentreprise, on se trouvera bien, cependant, de rflchir auparavant aux questions qui sont listes ci-aprs.
19.3.1
SOAP reprend sa lgitimit dans un systme de participation clos , cest--dire o les participants sont prts se mettre daccord en amont, en termes doptimisation et dinterface mtier. Or, selon les chapitres prcdents, une SOA riche concerne prcisment ces acteurs.
Appel doprations
Les oprations de recherche complexe et de soumission de nouveaux lments mtier sont naturellement traites dans un POST dans un cadre REST. Or si lon observe, comme on la fait prcdemment, les contraintes dutilisation des mthodes POST dans cette architecture, on y retrouve tous les principes respecter pour obtenir un change stable tel que prn par les Web Services au sens SOAP ! Les donnes, qui voyagent dans la partie data de la requte HTTP, sont souvent encapsule par un format XML. De plus, dans un SI, ces donnes seront structures, et lies entre elles via un graphe dobjet. Quil y ait une enveloppe SOAP ou non ne change donc pas grand-chose limplmentation ct serveur. Ce serveur devra inclure obligatoirement les composants de traitement de ce type de requte : parsers, validateurs, routage par rapport au contenu dun document, scurit tout est retrouv ici dans la soumission de donnes, il ny a pas de diffrence entre REST et SOAP. Certains aficionados de REST rpondent en prnant ATOM comme format dchange, voire JSON ou des formats dchanges adapts au Web : ces formats sont supposs moins contraignant/consommateurs que du SOAP + schmas classiques.
19.3 Recommandations
277
Mais les normes ATOM sont des normes XML quoi quil en soit. De plus, elles ne sont pas encore compltement stabilises. Enfin, elles sont en but la concurrence de RSS au sein du monde WEB 2.0, ce qui fait que leur adoption gnralise (condition de leur succs en dehors de ce monde) nest pas acquise. Quant JSON et consort, les formats natifs accessibles en JavaScript, ils sont videmment trs intressants comme on la vu au chapitre prcdent. Cependant on lude souvent la difficult les produire, et leur utilisation simple se cantonne une fois de plus au Web et la partie cliente. En conclusion, REST, comme SOAP, implique la ncessit dencadrer la description des changes de donnes de faon formelle et valide. Les solutions REST existent certes, et sont relativement faciles utiliser sur les clients qui utilisent nativement ces reprsentations (JSON); de plus les flux sont plus clairs que les schmas privs car leur description est standardise (ATOM). Mais leur pleine utilisation repose sur un fort pouvoir auto descriptif (dcouverte par lapplication du sens des donnes au fil de leau), pouvoir peu utilis par les applications clientes actuelles. De plus, les problmatiques clefs de grappe dinformations et de scenarii de chargement (exposes au chapitre 8, section 8.3.2) ne sont pas prises en compte par ces formats dchanges : en particulier, il ny a pas de rponse pour les requtes qui rapportent des grappes dobjets complexes dont certaines ne sont pas entirement charges (chargement par ncessite). Il ny a pas de rponse non plus pour les accs pagins (sur une collection de rsultats trop importante) dans un SI dentreprise, il ny a pas que des accs squentiels simples ! ATOM annonce quil va apporter des solutions, mais nous sommes au mme niveau de visibilit que pour les publicits autour de WS-Transfer ou WS-Enumeration La gestion des POST demandera ct serveur des infrastructures de gestion de contexte adaptes, correspondant aux structures dj abordes dans le cas des solutions WS-*.
Contexte asynchrone
Les technologies WS-* sont dores et dj armes pour les besoins de couplage asynchrone. REST ne propose rien ici, part un travail la charge du client. La sentence est sans appel si une interface asynchrone doit tre ncessairement expose aux clients extrieurs. Ici, les mdiateurs nouveaux de type ESB ont toute leur place. Les WS-* sont en terrain conquis, ou presque.
19.3.2
Nous avons vu que les diffrences technologiques montrent des gammes dutilisations optimales diffrentes pour une technologie REST et une technologie de Web Services base sur SOAP. Mais il y a une approche plus fondamentale encore que REST vs SOAP. En prenant du recul, REST vs WS-* reste dactualit, ou plutt REST (accs des informations : orientation nom de choses ) vs RPC (accs des traitements :
278
orientation verbe). On est ici dans la reprsentation du mtier soit par des noms soit par des verbes. Lensemble des mthodologies qui permettent de faire merger des services conformes aux enjeux mtiers utilise des reprsentations base dactions, doprations au service des processus de lentreprise. Cet ouvrage a dj montr quil est difficile et ncessaire de faire apparatre une typologie de service pertinente pour bnficier des apports dune SOA. Lapproche REST semble ici ajouter une complexit entre les besoins mtiers et une solution technique : tout service (par exemple les services fonctionnels, cf. chapitre 8) sont-ils modlisables sous forme de ressources REST ? Il faudra donc de toute faon adapter les mthodes durbanisation du SI aux approches REST. Dun ct, REST propose donc une universalit technologique, HTTP et ses verbes choisis associs une reprsentation CRUD & reprsentation plus ou moins standard (ATOM) pour les ressources de lentreprise vues comme des donnes. De lautre ct, WS-* prne la reprsentation explicite des donnes ET des verbes spcifiques aux services exposs. SOAP est alors le premier reprsentant du middleware dchange, ignorant mme le protocole de transport. Dans ce contexte technique, les deux approches ont lieu dexister, peuvent coexister et senrichir lune et lautre. La communaut REST rflchit sur lutilit dun WSDL like pour dcrire les data changes et souhaite laborer WRDL (Ressource), cest--dire la reprsentation dun contrat au sens REST. Ds lors que le client doit parcourir une grappe dobjets complexe, les verbes vont reprendre le dessus, mme si une approche REST se propose de les gnrer au besoin. Les URL montres aux paragraphes prcdents pour illustrer des requtes plus complexes que donne-moi le contrat no 1080042 illustrent ce point. Lapproche REST implique de dcouvrir ces verbes et ressources nommes lors de lutilisation. Tant que ces utilisations successives dappels/liens transmis sont adaptes aux besoins tant en termes de contraintes fonctionnelles que de contraintes de performances, REST est effectivement une solution dimplmentation fiable. En revanche, si performance ou richesse dchange imposent plus de connaissance rciproque, alors les solutions WS-* sont une solution qui dpasse le problme de la technologie pour apporter des solutions adaptes lexpression mme des enjeux mtiers. REST est donc efficace et ligible si : les oprations de lecture GET sont sans tat et rptables n fois : ce qui implique par exemple quil ny a pas de problmatique de verrou en lecture; les oprations de modification et de suppression/archivage sont idempotentes, cest--dire que lon peut les demander n fois sans introduire dincohrence : relance suite une perte de connexion, pour vrification, etc. Effectivement, au sens HTTP/Web du terme, pour des ressources classiques sur Internet, ces proprits sont vraies. Si les services ainsi exposs conservent ces pro-
279
prits, alors les solutions apportes par REST sont trs adaptes. On peut demander n fois un GET sur une ressource et le rsultat sera le mme. On peut demander n fois laltration dune ressource, par PUT ou DELETE, et le serveur Web saura faire le traitement une seule fois et continuer sans effet pour le client (la ressource est modifie, la ressource nexiste pas). Il ne faut pas se voiler la face : quels que soient les problmes sous-jacents REST, la simplification apparente par rapport aux WS-* et WSDL reste attractive. Lapproche code2wsdl (par rapport lapproche wsdl2code , thoriquement mieux adapte, mais moins simple) permet de gnrer plus facilement les web services, au risque de gnrer des services de granularit peu ou pas adapts. Mais elle ne masque quen partie la complexit WS-*. REST a donc sa place dans les solutions dimplmentations des SOA. Cependant, REST va devoir se pencher srieusement sur la reprsentation des informations manipules pour bien se positionner dans lapproche Mashups : cette approche repose en effet sur une description formelle des informations. Standardiser les verbes ne suffit pas pour btir rapidement des applications simples. ATOM est sans doute un premier lment de rponse, mais le passage WRDL ou quivalent risque de se rvler ncessaire dans ce cas, la diffrence entre REST et WS-* sestompera ncessairement un peu plus.
280
Pour identifier son besoin, il est donc ncessaire de savoir ce que lon souhaite standardiser : une dmarche SOA commence bien avant de se demander si REST ou WS-* sera la colonne vertbrale de linteroprabilit.
REST
WS-* (SOAP)
ESB synch
ESB asynch
Lecture Recherche
GET(URI)
Modification
PUT(URI, Ressource)
Suppression Archivage
DETELE(URI)
Soumission Opration X
operationX()
En rsum
Le Web 2.0 tend remplacer SOA comme terme la mode, dans les gros titres de la blogosphre. Certains tentent dopposer les deux approches, alors que le Web 2.0 reprsente dans les faits une nouvelle approche pour construire une SOA. Aprs en avoir rappel les principes, la prsentation des aspects applications composites du Web 2.0 a mis en vidence les avantages et les inconvnients de cette approche pour btir une SOA. Avantage en termes de simplicit et dergonomie pour lutilisateur final, inconvnient en termes dimmaturit et de difficult de maintenance ds lors que lapplication dpasse le cadre de quelques pages Web. Il nest donc pas certain quil faille dj parler de SOA 2.0.
SEPTIME PARTIE
1. Les outils ne sont pas valus dans la grille de critres pour viter lobsolescence trop rapide du contenu de cette partie.
20
Caractristiques de la plate-forme SOA
Objectif
Lobjectif est ici de dresser un panorama des modules potentiellement utiles pour un environnement permettant de construire, dhberger, dexcuter et dadministrer les solutions mtiers SOA. De lensemble des offres en matire dinfrastructure SOA merge le concept dESB (Entreprise Service Bus), mais force est de constater que cest un concept attrapetout aux contours flous. Ce chapitre souhaite donc prciser le primtre de ce quest un ESB, en lister les principales fonctions techniques, et prsenter les outils complmentaires de lESB, tels que le registre des services, lorchestrateur, le distributeur de requtes CRUD ou le cache de donnes. Il introduit de ce fait le concept de plate-forme SOA, encore appele APS, Application Platform Suite. Lexpos se veut une prsentation architecturale, indpendante de tout vendeur particulier. Associ au chapitre suivant, qui rcapitule les critres discriminants par module, il constitue ainsi un guide prliminaire permettant lquipe charge de linfrastructure SOA deffectuer un choix clair doutils.
284
BPM (Orchestration)
Bus de message
Administration ESB
SCA
SERVICE SERVICE SERVICE
Gestion Scurit
CRUD
CRUD
Dploiement
EII
APS
nouveaux rfrentiels
Existant SI
285
Que recouvre exactement lappellation ESB ? Au sens strict du terme, il sagit dabord du bus de communication de messages et dvnements mtiers : ce composant permet un consommateur (une application interactive, un service, un moteur de BPM externe) daccder un service. Ce bus est associ aux outils de suivi technique SAM. Sous la pression marketing des diteurs, le primtre de lESB saccompage souvent dun conteneur de service SCA, dun moteur de routage et embrasse parfois un moteur de rgles mtiers, un moteur dorchestration BPEL accompagns de consoles dadministration. Malheureusement, il nest pas rare de voir certains diteurs englober sous la dnomination ESB la totalit des composants prsents sur la figure 18.1, y compris le portail composite, laccs aux rfrentiels avec des outils MDM/EII, voire certains ateliers de la chane de fabrication ! Les comparaisons entre outils deviennent alors difficiles, tant les fonctionnalits finissent par tre nombreuses. Il conviendra donc de prendre garde la modularit et louverture des constituants regroups. Dans la suite du chapitre, on prend rsolument le parti de restreindre lappellation ESB au seul composant responsable du transport et de lacheminement des messages entre client et services. Lappellation APS (Application Platform Suite) dsigne quand elle lensemble des composants dinfrastructure prsente par la figure 20.1, y compris la chane de fabrication.
20.1.1
Les besoins
Un ESB doit permettre un dveloppeur dapplications ou de services composites daccder aux services disponibles de faon standardise, flexible et transparente. Cela implique concrtement de rendre les consommateurs des services aussi indpendants que possible : Du protocole de communication utilis par le consommateur et/ou par le service : le consommateur doit pouvoir accder au service via HTTP, mais aussi via FTP, JMS, JCA, SMTP, RMI, .NET Remoting etc. De la technologie de dploiement des services : que ce service soit dploy comme Web Service, composant .NET, comme EJB ou comme un simple composant COM, Java ou PHP, le consommateur doit dans lidal y accder de la mme faon. De la localisation des services. Symtriquement, lESB doit permettre un dveloppeur de services de dployer ses services quels que soient la technologie et le protocole de communication choisis. De plus, afin de faciliter ladoption de lapproche SOA, on impose de plus en plus un ESB doffrir des outils daccs des composants existants, notamment aux rfrentiels lgataires (EII/MDM).
286
287
Clients BPM
ESB Moteur De transformation des messages (XSL-T) Moteur de rgles de routage des messages
Accs aux Services Accs aux Services (HTTP, JMS,) (HTTP, JMS,)
SAM
Services locaux
Services Distants
Service
Service
Service
Le bus de message assure le transport et la scurisation des messages entre les diffrents serveurs impliqus dans le dploiement des clients et des services. Les adaptateurs de protocole permettent lESB de supporter divers protocoles de communication dans son dialogue avec les consommateurs et les pourvoyeurs de services. LESB pourra aussi se voir muni de connecteurs directs afin de faciliter laccs lexistant sans couche service. Le moteur de routage assure laiguillage des messages vers leurs destinataires selon des rgles. Le moteur de transformation assure la conversion syntaxique de format de messages entre deux protocoles (si le protocole dinvocation du service par le consommateur est diffrent du protocole dactivation du service par lESB). Il peut aller plus loin, en assurant galement une conversion smantique des informations XML changes entre consommateurs et services (cf. les remarques du paragraphe Transformer les messages ). Les paragraphes ci-dessous reviennent sur quelques points clefs de lESB.
Appeler un service Le bus met disposition des consommateurs de services plusieurs modes dappel (ou mode dinteraction) de ces services :
Mode synchrone. Mode asynchrone one way .
288
Mode asynchrone avec call back . Mode asynchrone publication/abonnement . Mode conversationnel. Le mode daccs synchrone bloque le consommateur en attendant la rponse du service. Cest le mode classique daccs, similaire demploi un appel procdural dans un langage de programmation. Le mode asynchrone one way libre le consommateur ds que celui-ci a appel le service. Autrement dit, le consommateur nattend pas de rponse du service. Ce mode a t popularis par les MOM (Message Oriented Middleware) puis par les EAI. Il permet notamment de propager des vnements entre applications. Le consommateur peut demander une garantie dacheminement du message ou pas. Le mode asynchrone avec call back libre le consommateur ds que celui-ci a appel le service, mais le consommateur prcise lors de son appel quil souhaite obtenir une rponse ultrieurement. Pour cela, le consommateur spcifie au service appel quelle opration celui-ci doit rappeler pour envoyer sa rponse : cette opration est appele call back. Le mode asynchrone publication/abonnement permet un consommateur de transfrer de linformation simultanment vers plusieurs services, sans se soucier du nombre et de lidentit de ces services. Lide de base est de permettre un service de sabonner (suscribe) une publication de message. Lorsquun consommateur publie (publish) un tel message, cest lESB de prendre en charge la diffusion de ce message tous les abonns intresss. Ce mode de communication permet notamment la diffusion dvnements ou dinformations (propagation des taux de changes ou de la cotation dune action vers le front office et le back office dune salle de march, par exemple). Enfin, le mode conversationnel permet au consommateur dengager une conversation avec le service appel, une conversation tant une suite dappels et de rponses. Lintrt de ce mode est dallger le travail de lESB, qui na plus crer chaque appel de service un nouveau contexte de travail : ce contexte technique, gr et stock par lESB, est partag entre chaque appel/rponse.
Transformer les messages La question se pose de savoir sil faut aussi ajouter, au sein du bus, un moteur de traduction, linstar dun interprte servant dintermdiaire dans la vie relle.
Cette inclusion peut constituer un pige. En effet, lobjectif premier du traducteur est deffectuer des transformations syntaxiques entre protocoles de communication. Mais il peut tre tentant dutiliser ce traducteur pour lui faire jouer un rle dEAI/ ETL, cest--dire un rle de transformateur smantique de donnes mtier, en rfrence un langage pivot dfinissant la smantique de ces donnes. Or dans une approche SOA, ce sont les services mtier qui doivent se charger dune telle transformation ou adaptation, ce qui est nettement plus flexible.
289
Le fonctionnement dynamique
Sans rentrer dans des dtails techniques inutiles, il est intressant de comprendre dans les grandes lignes le fonctionnement dun ESB pour bien marquer la diffrence avec un simple appel de Web Service sur HTTP. La figure 20.3 propose un diagramme de squence illustrant ce fonctionnement sur lapplication fil rouge . Une demande de prestation saisie sur le portail par un fournisseur est envoye via un connecteur JMS (protocole asynchrone) lESB.
ESB Adaptateur JMS Routage Transport interne scuris Transport interne scuris Transformation Adaptateur HTTP Service
n o p q r s t
290
Le connecteur transforme la demande en un message interne ESB et envoie ce message au moteur de routage. Celui-ci dtermine la localisation du service mtier appeler (cest un Service Applicatif, cf. chapitre 8), en fonction de la demande dpose. Le mcanisme de transport interne lESB achemine le message de faon scurise vers le nud de rattachement du Service Applicatif. L, le moteur de transformation de lESB transforme le message reu dans un message au format attendu par le service. Si on suppose que le service est dploy comme Web Service, le message va tre traduit en format SOAP. Le message est transmis ladaptateur appropri ici, ladaptateur http. Ladaptateur invoque le service. Le lecteur peut lgitimement se demander si lESB ne devient pas une usine gaz : pourquoi ne pas se contenter de dployer un simple frontal Web Service (tel que loutil Open Source Axis 1.x) ? De nombreuses raisons militent en faveur dune solution ESB pour un dploiement industriel de SOA au niveau de lentreprise1 : Lapplication utilisant le frontal JMS nest pas bloque par lappel du service, ce qui peut tre un lment important de la performance globale de la solution. Lacheminement de lappel peut tre scuris par lESB sans intervention des quipes en charge des solutions ou des services. Le consommateur peut dlguer lESB la dtermination de limplmentation du service appeler (via SCA) : cela peut notablement faciliter le dcouplage de lvolution des clients dun ct et des services de lautre. Ce dcouplage peut galement permettre de masquer la vritable adresse dun service web un consommateur externe au systme dinformation, ce qui contribue la scurisation des accs. LESB offre un niveau de supervision (console SAM) que noffre pas un simple frontal Web Service. En fait, loffre ESB va probablement se structurer dune faon comparable la situation actuelle des serveurs dapplication dans le monde Java : lapparition doffres trs compltes tels que les serveurs IBM WEBSPHERE ou BEA WEBLOGIC na pas entran la disparition dun outil tel que TOMCAT. Le niveau de maturit de lappropriation de la dmarche SOA par une direction informatique la fera probablement passer progressivement dune architecture ESB simple et localise, une architecture plus complte, dploye au niveau de lentreprise.
Le dploiement
On se bornera rappeler quil en va de lESB, comme des autres outils de messagerie : il y a deux topologies de dploiement dun ESB, la topologie dcentralise (chaque pourvoyeur de service est un nud de communication supportant une rplique du
1. Axis dans sa version 2.x propose dailleurs un certain nombre de fonctionnalits qui le rapproche dun ESB.
291
noyau ESB) et la topologie centralise (lESB est un hub de communication centralis sur une machine). La topologie dcentralise est la plus robuste (la perte dun nud de communication na pas dimpact sur les autres nuds), mais aussi la plus complexe installer et configurer. La figure 20.3 adopte cette topologie.
Le transport des messages et vnements est-il pour autant unifi (et standardis) ? Sur le papier, on la vu, le bus ESB est indpendant par dfinition des technologies utilises dans le SI. Dans la pratique1, lESB nest pas encore aussi universel. Il est vrai que cette universalit est rendu complexe par la trs grande diversit des technologies classiques , telles que les moniteurs transactionnels (CICS, Tuxedo) et les EAI (WebMethods) dans la banque et lassurance, les MOM (MQ series dIBM ou RendezVous de Tibco) dans les salles de march, Corba dans les tlcoms, les ERP dans lindustrie, et plus gnralement les middlewares du monde Java (RMI/JMS/EJB), ceux de Microsoft (.NETRemoting/ DCOM), etc. Il convient alors de rechercher un degr dunification via la ralisation de bridges entre lESB et la technologie lgataire vise.
1. Ceci restant vrai actuellement pour la majorit des diteurs.
292
Par ailleurs, il est possible denvisager une priode de transition entre EAI et ESB. Par exemple, les architectes du SI pourront envisager lEAI pour tablir les grandes dpartementales du SI, en mme temps que lESB pour les boulevards priphriques du SI et les autoroutes inter-SI.
20.1.2
Les besoins
Les dveloppeurs dapplications consommatrices ont besoin daccder aux contrats dcrivant les services pour en prendre connaissance. Linfrastructure (ESB) a galement besoin daccder non seulement aux contrats, mais galement la description des dpendances entre services et ventuellement aux implmentations de ces services. Le concept de Registre de Service recouvre la rponse aux deux besoins : Le besoin dun annuaire de services, contenant uniquement les contrats de service, et permettant de rendre public ces contrats et de les consulter. Le besoin dun rfrentiel de services, contenant non seulement les contrats, mais galement la description des dpendances entre services et ventuellement les implmentations de ces services.
En fonction du primtre de lESB associ et de lintgration du registre cet ESB, le registre peut galement grer les modles de processus, les grammaires mtiers, les scripts de transformation de messages, les rgles de routage, les portlets, etc.
Le terme neutre de registre de services regroupe ces fonctions dannuaire et de rfrentiel. Lannuaire peut supporter ou non la norme UDDI (cf. partie 4, chapitre 12). Le rfrentiel de service est li au support de la norme SCA (cf. partie 4, chapitre 14). Lintroduction du concept de registre de services est donc clairement structurante pour SOA.
Larchitecture
La figure 20.4 prsente les fonctions dun tel registre. Les principales fonctions attendre dun tel registre sont donc : La publication des contrats et des implmentations, via une intgration plus ou moins pousse avec les ateliers de la chane de fabrication des services. La classification des services : Documentation pour les consommateurs. Indexation sur le plan technique (messages, interfaces, protocoles acceptables, SLA etc.). Indexation sur le plan mtier (domaine sectoriel, couverture gographique, tarification, rglementation, etc.).
293
portail Service
BPM
Consommateurs de Services
crateur de Services
La gestion des services : Stockage des implmentations. Gestion des modifications, des versions, des variantes, de plusieurs environnements (e.g. : tude, test, pr-production, production, etc.). Gestion des dpendances entre services. La recherche (scurise) dun service : Recherche interactive (pages de documentation gnres souvent Web). Recherche programmatique (requte de slection).
Le dploiement
Il existe potentiellement trois topologies principales de registres, comme lillustre la figure 20.5 : Rfrentiel centralis : Il apparat suffisant dans un contexte dutilisation interne lentreprise pourvu que les consommateurs ne soient pas eux-mmes trop rpartis; en revanche il ne peut convenir un contexte inter-entreprise. Multiples Rfrentiels de services : Cette topologie est prfrable si la contribution des pourvoyeurs de services est trs rpartie sans quun besoin dunification pour les consommateurs soit ncessaire (par exemple, registres verticaux par domaines sectoriels).
294
Rfrentiel de services fdr : Il sagit dune combinaison des deux cas prcdents, cette topologie donne lillusion dun unique rfrentiel pour le consommateur de service, tandis que des rfrentiels locaux chacun des pourvoyeurs sont physiquement distribus et fdrs.
Atelier
browser
Atelier
C/S
Pourvoyeurs de Contrats
Consommateurs de Descriptons
browser
Atelier
Rfrentiel de services #1
C/S
Atelier
C/S Atelier
Consommateurs de Descriptions
browser Atelier
20.1.3
Les besoins
Laccs CRUD aux informations mtiers est un enjeu important de la cration dune bibliothque de services rutilisables, comme on la vu partie 3 chapitre 8. La cration de services CRUD nest pas aussi triviale quil peut paratre, il existe donc un besoin fort en matire doutillage la fabrication et lexcution de tels services. Ce besoin peut tre gradu du plus simple au plus complexe, selon le niveau de sophistication et de performance requis. Le premier besoin, prioritaire, est la gnration de services CRUD partir dune description des Informations Mtier manipuler. Ce besoin est couvert par les outils de type EII1 ou directement par un module de la chane de fabrication.
1. La terminologie anglo-saxonne retenue est celle dEnterprise Information Integration (EII).
295
Le deuxime besoin porte sur la ncessit dagrger des donnes de base pour reconstituer ces informations mtiers. Ce besoin se retrouve lorsque les rfrentiels concerns existent dj, et quil nest pas possible de les unifier sans les modifier trop profondment. On a dj cit lexemple classique de linformation mtier client , qui agrge des informations personne morale (= lentreprise cliente), personne physique (= les correspondants dans cette entreprise cliente), adresses gographiques (adresse de livraison, adresse de facturation), adresses bancaires historique des commandes , historique des paiements , contacts marketing , etc. On peut galement citer une autre utilit : celui dharmoniser laccs aux bases clientes des diffrentes filiales dune mme socit : le besoin est alors deffectuer des correspondances smantiques entre les concepts, en utilisant des mta-informations (par exemple, la correspondance nom du client = nom-client = last name = customerName , etc.). Ces besoins sont couverts par les EII les plus avancs.
Les principes du MDM Le Master Data Management gre des tables mtiers de rfrences mises jour en fonction dune politique de rplication paramtrable, et visibles au travers de services. Contrairement lEII qui ncessite la disponibilit temps rel des sources, le MDM stocke les donnes. Il sagit donc de collecter et concentrer toutes les donnes relatives un objet mtier (client, fournisseur, produits) ainsi que leurs meta-donnes de structuration (cls daccs sur la source dorigine matre, la version, un ou plusieurs champs contextuels tels que la dernire commande, etc.) afin quelles soient partages lchelle de toute lentreprise voire du secteur industriel dans un format pivot. Il sagit principalement des donnes servant de point dentre aux processus mtiers. Chaque valeur est unique et dispose dun identifiant unique (elle a fait lobjet dun processus de mise en conformit/qualit). Elle peut tre versionne (via les mtadonnes) en vue dune exploitation analytique. Le rfrentiel du MDM peut lui-mme tre dupliqu pour des raisons de performances ( condition de rester lidentique de loriginal). Le MDM peut aussi servir pour la traabilit des donnes et permet de soulager les processus dintgration par les donnes. Il contribue une volont damlioration des processus transverses plusieurs dpartements dans lentreprise (par exemple, les lments tels que contractualiss au dpart par une quipe commerciale, puis tels que facturs par une quipe comptable, ou tels que fabriqus par une filiale, etc.). Ceci permet de dgager les donnes clefs utiles chaque dpartement mtier. Les caractristiques diffrenciatrices du MDM, sont principalement : La nature des donnes centralises (ddie produit, client, organisation etc.) avec ou sans meta-donnes. Le type de pivot ( construire ou prt lemploi1). La qualit des donnes (cest le point le plus dlicat car il se heurte aux aspects organisationnels : nettoyage de donnes non utiles, conformit de structure et de valeurs, suppression des doublons, etc.). Le type dadministration (batch ou temps rel).
1. Il existe en effet des MDM spcialiss dans la consolidation de donnes Clients (CDI : Customer Data Integration) ou la consolidation de donnes Catalogue Produit (PDI : Product Data Integration).
296
Le troisime besoin porte sur la ncessit de rpliquer les donnes agrges pour accrotre les performances daccs ces informations ou pour garantir la robustesse de la solution mtier (cf. partie 3 chapitre 7). Ce besoin, qui recouvre galement le deuxime besoin, est couvert par une nouvelle race doutils, baptise MDM Master Data Management. On notera dans ce cas quil est utile qu la fois les donnes et les mta-donnes soient disponibles et unifies dans le MDM, mme si dans ce cas, certaines donnes dont la frquence de modification est trop leve, ne peuvent pas tre rpliques.
Larchitecture
La fonction premire daccs CRUD repose sur le concept de mta modle mtier. Ce mta modle reprend le modle mtier en y ajoutant des informations ncessaires la mcanique daccs : par exemple, est-ce que lattribut code postal de ladresse du fournisseur est utilis comme critre de Recherche sur la base fournisseur (le R de CRUD) ? La fonction dagrgation repose sur le concept de Vue de donnes : ce concept est similaire celui propos par les SGBD relationnels. Une vue dfinit une information virtuelle via une agrgation de donnes. Une vue dcrit donc : Les types de donnes de base, agrgs pour former la vue (par exemple : la vue fournisseur est lagrgation dune personne physique et dun contrat ). La correspondance entre attributs (par exemple, nomDuClient = customerName, etc.). Les informations daccs technique aux donnes agrges (par exemple : la personne physique est accde via une cl primaire SQL, le contrat est accd via un identifiant SAP). La fonction de rplication repose sur les concepts de Cache de rplication et de Politique de Rplication. Le Rfrentiel Cache contient les donnes rpliques, considres comme des donnes matres (do le nom de Master Data Management), et constitue un cache dinformations unifies. Une politique de rplication dfinit la frquence et les modalits de rplication entre chaque rfrentiel source de donnes, et le rfrentiel matre . La figure 20.6 prsente en consquence lensemble de linfrastructure associe un tel outil daccs aux rfrentiels. Cette infrastructure comprend des outils de modlisation, une console dadministration, et un moteur dexcution. En pointill, les fonctions spcifiques dun outil de type MDM. Chaque connecteur permet daccder un type de rfrentiel en utilisant le dialecte attendu par ce type. Le dialecte support en standard est bien sr SQL. Laccs des progiciels reconnus peut galement tre propos. Certains outils EII/MDM prtendent galement offrir laccs des fichiers plats (fichiers Excel, etc.). La fonction de rplication excute les rplications de donnes en appliquant les politiques de rplication dfinies au pralable et dployes via la console dadministration de loutil. Elle sappuie sur les connecteurs de donnes.
297
La fonction de transformation agrge les donnes en utilisant la dfinition des Vues de donnes modlises dans latelier logiciel et dployes via la console dadministration de loutil. La fonction de gestion du rfrentiel matre assure la gestion de ce cache persistant. Elle propage ventuellement les modifications apportes aux informations sur ce rfrentiel vers les rfrentiels sources.
Clients BPM Infrastructure daccs aux donnes (EII / MDM) CRUD Chane de fabrication SOA Administration EII / MDM Atelier de modlisation des Vues Scurit Cache Transformation des donnes donnes matresses Dploiement Vues Rplication des donnes Paramtrage Vues Politiques Connecteurs Connecteurs Connecteurs CRUD CRUD CRUD
Les services encapsulent cette mcanique EII/MDM, et offrent les oprations CRUD utilisables par les clients. En fonction de loutil, soit ces services accdent directement au transformateur de donnes, qui sappuie sur la dfinition des vues pour cibler en temps rel les rfrentiels source des donnes agrger, soit ils accdent uniquement au rfrentiel matre.
Le dploiement
Les diffrences entre un outil MDM et un outil EII tiennent au fait que lEII accde en temps rel aux rfrentiels sources, et na pas besoin doffrir de rplication de donnes et donc pas de cache de consolidation : il a donc un champ dapplication plus large en terme daccs aux donnes (tout type de donnes est accessible via un
298
EII, y compris les donnes fortement transactionnelles), mme sil reste ncessaire de veiller aux performances daccs. Certains outils proposent de gnrer le code des services CRUD, ce qui est moins souple en terme de dploiement, mais plus sr en terme de qualit de code et doptimisation des performances. Il nest pas besoin de rappeler combien ces performances daccs sont critiques pour la performance globale de toute solution mtier.
20.1.4
Les besoins
Le moteur BPM
Le besoin principal porte sur la capacit modliser les processus mtiers, et pouvoir utiliser ces modles pour paramtrer directement le moteur dexcution de processus. Les processus concerns sont principalement des processus e-business, plus ou moins automatiss, dans lesquels il doit tre possible de faire intervenir des acteurs humains.
Larchitecture
La figure 20.7 prsente larchitecture du moteur et les outils associs (atelier de modlisation, console dadministration, console de monitoring BAM). Les outils lis au workflow humain ont t dcrits au chapitre 9.
Moteur BPM Workflow Humain Organisation Routage Corbeilles Administration BPM Gestion Scurit Modles de processus Gestion des instances de processus Moteur de rgles Contexte Dploiement
Atelier de Simulation
instances
299
20.1.5
Les besoins
Comme tout logiciel, les solutions mtiers SOA doivent faire lobjet dune surveillance en production, ou monitoring. Le besoin de monitoring spcifique de SOA est double : Paramtrer et visualiser des indicateurs sur le comportement des services : cest le besoin SAM Service Activity Monitoring. Paramtrer et visualiser des indicateurs sur le comportement des processus : cest le besoin BAM Business Activity Monitoring. Via la console SAM, un exploitant ou un responsable de service pourra visualiser en temps rel le comportement de chaque service : courbe du nombre daccs en fonction de lheure, temps de rponse moyen/minimal/maximal, volumtrie des paramtres dentres/sorties, erreurs dtectes, etc. Il pourra galement visualiser le dpassement de seuils et ainsi dtecter des alertes. Ces donnes SAM sont historises, ce qui permet de revenir sur le comportement dun service sur plusieurs jours, et de surveiller par exemple une ventuelle dgradation progressive de la qualit de service. Via la console BAM, un administrateur de processus, un responsable dune solution mtier ou un responsable de la matrise douvrage pourront visualiser en temps rel le comportement dun processus (date de dmarrage, tat actuel, dure dexcution de chaque activit, exception leve, etc.). Ils pourront galement visualiser le dpassement de seuils (exemple : un processus tarde se terminer) et ainsi mettre des alertes. Ces donnes BAM sont historises, ce qui permet dtablir des statistiques sur le comportement dun ensemble de processus : par exemple, quel est le temps moyen dexcution dun type de processus, quelle est la frquence dune exception donne, etc. Le besoin gnral en matire de paramtrage BAM/SAM porte donc sur : La politique de recueil des donnes temps rel (frquence, type de trace). Le choix des indicateurs visualiser en agrgeant les traces recueillies. La dfinition dalertes sur dpassement de seuil critique. La dfinition dhistorique consolidant les donnes temps rel. Lexport des donnes dans un format appropri (Excel). La dfinition de rapports danalyse dcisionnelle (ceci pouvant tre dlgu des outils dcisionnels existants, condition quil soit possible dexporter les donnes ncessaires).
Dans un futur plus ou moins proche, les outils BAM/SAM devraient permettre danticiper sur lvolution des ressources du systme, en offrant la possibilit : deffectuer des simulations de charge partir des statistiques obtenues, de la description de larchitecture (services) et des modles de processus concerns,
300
de dfinir des rgles dutilisation automatique des ressources on demand par segmentations et auto ajustement de ces ressources, en plus ou en moins.
Larchitecture
Les caractristiques essentielles sont : Une instrumentation de chaque composant et de linfrastructure (ESB, moteur BPM), par des sondes (ou agents) distribues. Un ou plusieurs serveurs de recueil et darchivage des traces recueillies par les sondes. Une console dadministration du monitoring, permettant de paramtrer les niveaux de sensibilit des contrles, avertissements, erreurs et options dinstrumentation. Les consoles BAM/SAM elles-mmes, incluant les outils de restitutions, allant du simple indicateur aux outils de statistiques et prsentation personnalisables. Elles peuvent inclure des vues graphiques, des tableaux, des visualisations dalertes, etc.. Des interfaces dintgration avec des outils dexploitation systmes et rseaux, avec une solution dcisionnelle (notamment via lusage dun serveur de corrlation dvnements CEP), voire avec une solution de facturation de lutilisation des services, etc.
301
Les tests dintgration continue de services, permettant tout fournisseur de service souhaitant tester au plus tt son implmentation, de solliciter celle-ci sans attendre la ralisation des implmentations de services dont il dpend. Il utilise pour se faire, en lieu et place, des services bouchons permettant de fournir un rsultat au travers de jeux dessai rpondant aux interfaces convenues1. Etc.
20.2.1
Latelier de modlisation
Lobjectif de latelier est de proposer des diteurs (graphiques ou textuels) permettant de modliser les diffrents composants logiciels dune mme solution mtier. Il permet dentamer une dmarche MDA (cf. encart MDA chapitre 11). Il doit comprendre au minimum : Un modeleur UML. Un modeleur XML.
Latelier UML
Le modeleur UML permet de modliser et grer les diffrents modles mtiers (modle de processus, modle dobjets mtiers, modle de cas dutilisation, etc.), encore appel PIM (Platform Independant Model). Le modeleur UML offre aussi dans lidal de grer des documents textuels dcrivant ces composants (cas dutilisation, fiche descriptif des services, etc.). Cet atelier supporte si possible la notation BPMN pour modliser les processus mtiers dune faon lisible par la matrise douvrage et transformable en WS-BPEL par larchitecte. Il peut aussi offrir un mcanisme dexport XPDL, lui aussi exploitable par les quipes techniques.
302
Certains diteurs proposent galement un simulateur de processus. Un tel outil simule lexcution de processus associs un ou plusieurs modles de processus, en tenant compte, dune part, des performances mesures au pralable par loutil de surveillance, dautre part, dhypothses sur les vnements mtier traiter, et enfin, dhypothses sur les capacits de linfrastructure. Cela permet, en thorie, danalyser limpact dune volution du modle de processus, avant de dployer cette volution. Cela navait que peu dintrt dans le cadre dune gestion de workflow, mais devient intressant pour anticiper dventuels problmes ou apprcier le gain de ractivit dans le cas de processus automatiss par des machines.
Latelier XML
Le modeleur XML permet de dfinir et grer les composants logiciels laide de vocabulaires XML spcialiss, ou DSL. Ces modles sont des PSM (Platform Specific Model) car ils ciblent une architecture ou une technologie particulire. Le modeleur UML est associ des gnrateurs assurant la transformation PIM (UML) PSM (DSL). Les DSL cibls pour les outils bass sur WS-* sont : BPEL pour les processus mtier; WSDL pour les contrats de base des services mtiers; WS-SecurityPolicy pour les directives de scurit; WS-Policy pour les autres directives; BOXML (Business Objects XML) pour les Objets Mtiers et la gnration des services CRUD; XFORMS, XUL ou XAML pour les Vues des Applications Interactives; xxx-config.xml (xxx = Struts, JSF ou quivalent) pour les Contrleurs de navigation; SCA.xml pour les dpendances entre services. Le premier avantage dun tel atelier est donc de supporter les phases dexpression de besoin et danalyse des solutions mtiers, en permettant de modliser services, processus mtiers et applications composites, comme la illustr la partie 3. Le deuxime avantage de cet atelier est dapporter le niveau de productivit ncessaire.
20.2.2
Latelier de fabrication
Latelier de fabrication comprend dune part un atelier de codage manuel et dautre part des gnrateurs de code.
303
20.2.3
Latelier dassemblage permet de compiler et construire les diffrents livrables composants une solution mtier. Ce processus dassemblage est pilot par une description de ces livrables et par une description du processus de livraison lui-mme. Latelier permet notamment de rassembler automatiquement les services en modules de dploiement. Pour cela, un diteur permet de dcrire les dpendances entre services et de spcifier la composition des modules grce aux fichiers SCA (cf. la description de SCA la partie 4). Une fois les livrables construits, latelier les dploie sur la plate-forme vise (plate-forme dintgration, plate-forme dhomologation, plate-forme de recette, etc.)
20.2.4
Latelier dhomologation
Latelier dhomologation permet deffectuer lensemble des tests ncessaires la mise au point des solutions mtier et des services : tests dassemblage, tests de bon fonctionnement, tests de performance, etc. Idalement, un tel atelier est organis autour dun outil de gestion des tests, qui assure dune part la planification des tests, dautre part permet de lancer lexcution de ces tests et darchiver les rsultats obtenus. Cet outil de gestion collabore avec les diffrents outils de tests disponibles. Les outils de tests de service permettent de spcifier et dexcuter des scnarios de tests de services, ce qui implique de : Dfinir un ensemble de messages WSDL de requtes, ainsi que la rponse attendue pour chaque requte. Dfinir les scnarios de tests, cest--dire lenchanement de messages envoyer. Dfinir des configurations de tests (il faut simuler N consommateurs simultanment actifs, par exemple). Lancer une campagne (on appelle campagne une excution dun ou plusieurs scnarios associs une configuration particulire). Les outils de tests de Processus SOA permettent de la mme faon de spcifier des scnarios dinjection de messages dans un processus BPEL, avec simulation pos-
304
sible de charge. La figure 20.9 dcrit le cycle complet mettant en relation modlisation, tests, supervision et simulation. La mise en place progressive de ce cycle est lun des lments cls permettant de mesurer la maturit dune dmarche SOA.
Tests Processus
Processus homologus
En rsum
Le dploiement de solutions SOA repose sur une infrastructure complte. Il est donc important de bien comprendre le rle et la place de chacun des composants de cette infrastructure. Lensemble des briques potentielles dune Application Platform Suite reste ajuster en fonction du contexte de chaque architecture mise en uvre. SOA ne peut simplmenter au travers dun seul et mme outil, produit voire mme fournisseur. Plusieurs composants de la plate-forme sont slectionner en fonction des points dagilit les plus critiques rsoudre entre les mtiers et linformatique. De nombreuses autres techniques traditionnelles dintgration demeurent toujours valables mais dans des cas dutilisation en gnral plus restreints.
21
Aide au choix
Objectif
Dans la partie 4, on a pu constater que les standards autour des Web Services sont encore peu stabiliss, lexception du socle de base. Par consquent, les solutions du march font aujourdhui leurs propres choix dimplmentation. De plus, compte tenu de la richesse de linfrastructure SOA dcrite au chapitre prcdent, tous les offreurs ne peuvent ou ne souhaitent pas offrir lensemble des modules de cette plate-forme. Ainsi est-il commun de rencontrer dimportants carts de primtre dans les platesformes disponibles. Lobjectif de ce chapitre est de proposer une aide au choix parmi les solutions SOA du march. Le lecteur qui dsire dployer une infrastructure en support son architecture SOA trouvera ici des critres danalyse lui permettant de faire un choix raisonn.
306
ment constitues de la matrise douvrage du projet, des architectes en charge de la mise en uvre de la solution (quipe infrastructure et quipe architecture applicative, cf. chapitre 11). La grille de critres pourra aussi tre rcupre auprs dun tiers ayant effectu un choix de solution similaire (autre matrise duvre, cabinet de conseil, institution de recherche, etc.). Pondration de la grille de critres. Il sagit ici dattribuer chaque critre une pondration sur une chelle gnralement de 1 4 (priorit critique, haute, moyenne, ou basse). Ainsi les sponsors du projet pourront quantifier de manire extrmement prcise les critres les plus importants leurs yeux. Analyse des solutions : il est ensuite temps de confronter les offres du march la grille. Cette tape peut seffectuer au travers de la documentation de la solution (disponible sur Internet ou auprs de lditeur), ou bien en rencontrant les diteurs pour les soumettre aux questions de la grille. On donnera alors une note pour chacun des critres (par exemple 1 point si telle caractristique, 1 autre point si tel supplment sur la caractristique et zro point autrement).
Coefficient de pondration Haute Moyenne Basse Critique Haute Moyenne Min
N 1. 2. 3. 4. 5. 6.
Intitul du critre Prennit de loffre Interface de consultation associe Incorporation une architecture plus globale Nb clients, principales rfrences Cot fixe propos Cot rcurrent propos
Note 1 2 0 2 2 1 Max
Commentaires
Solution 1
66 %
66%
Critres commerciaux
Critres connectivt
307
Agrgation des rsultats : cette tape consiste analyser les notes et les pondrations afin den sortir des indicateurs. Ces indicateurs, graphiques si possible, seront les outils daide la dcision pour arrter la solution cible. La figure 21.1 propose un exemple dextrait de grille de critres et un exemple de graphe daide la dcision.
21.2.1
Les critres prsents ici revtent un caractre gnraliste : ils sont en effet pertinents pour toutes les dmarches de choix doutils. Ils relvent du bon sens et peuvent tre utiliss pour faire un premier filtrage dans le cas o trop de candidats initiaux se prsenteraient.
Tableau 21.1 Critres gnraux pour une prslection doffres SOA
No G1 Intitul du critre Rfrences Commentaires Nombre de rfrences en production attestant de la stabilit et de lexprience de la solution en situation de production. Maturit du fournisseur et recul sur les enjeux et problmatiques. Ergonomie des interfaces destines aussi bien aux concepteurs, dveloppeurs, administrateurs ou aux mtiers. Prise en compte et couverture de ltat de lart. Existence dune API publique et documente permettant de faire voluer la solution en cas de besoins spcifiques. Capacit de la solution se dployer sur des infrastructures prexistantes (serveurs dapplication, base de donnes).
G2 G3
G4 G5
G6
Portabilit
308
No G7
Commentaires Capacit dintgration avec lexistant, connectivit, caractre ouvert de la solution pour permettre lchange de modules. Homognit des outils et consoles dadministration dune part et suivi dautre part. Capacit grer la production et lexploitation selon les besoins. Aspect non boite noire . Service aprs vente et support du fournisseur disponibles. Impact organisationnel. Sparation des rles dans la solution. Stabilit financire du fournisseur de solution, caractre stratgique de la solution dans son offre. Lorsque la prise en main ncessite une part de dveloppement spcifique, facilit et rapidit de ce dveloppement. Cots dacquisition en licences. Cots de support, de formation, de maintenance. Respects des normes et standards (cf. partie 4 pour les standards Web Services). Robustesse, disponibilit, rsistance aux pannes de la solution et capacit rpondre aux politiques de scurit et dintgrit (pouvant ncessiter un POC1). Capacit monter en charge (pouvant ncessiter un POC).
G8
Maintenance
G17
Performance
1. POC signifie Proof Of Concept. Cest un prototype permettant de valider les fonctions avances par le fournisseur.
21.2.2
Cette famille de critres se dcompose en sous-rubriques, qui sappuient sur la description du chapitre 20 : Socle : il sagit de qualifier la compltude du socle technique (en premier lieu lESB), sa capacit rpondre toutes les attentes techniques de part la richesse de ses frameworks de base. Infrastructure de Coordination : il sagit ici de linvocation de services au sein de lESB, quelle soit issue dun change point point, compos, orchestr ou collaboratif. En particulier la capacit de le faire sans recourir du code : Protocoles de Transports : on qualifie ici les protocoles de transport pris en charge par la plate-forme la fois en entre ou en sortie.
309
Routage : on qualifie ici les modes dacheminement des messages pris en charge par la plate-forme. Transformation : il sagit ici de traduire un message dun format dans un autre. Connecteurs directs : il sagit de la capacit de la plate-forme sinterfacer directement avec des sources dinformations (sans recours un serveur applicatif tiers ou un service). Infrastructure dinformations : il sagit des caractristiques essentielles du distributeur de requtes (EII) et/ou du rplicateur dinformations (MDM). Registre de services : on qualifie lannuaire de services et sa richesse fonctionnelle en tant que gestionnaire du rfrentiel SOA. Administration : il sagit ici dassurer une gestion cohrente unifie des rfrentiels dinfrastructure SOA (annuaire de services, mta-donnes, vues logiques, etc.) et de la scurit. Ceci doit pouvoir se raliser au sein dquipes rparties. Suivi : cette rubrique traite du suivi des changes par linformatique et les dcideurs mtiers cest--dire du SAM et BAM. Chane de fabrication : il sagit ici de lensemble des outils fournis par la solution pour modliser, gnrer ou implmenter, tester et dployer les services et les compositions. Prsentation de compositions : les composants permettant la mise en uvre rapide dinterfaces utilisateurs pour applications composites interactives ou semi-automatises, comme par exemple un portail web, un client riche, etc. Primtre mtier : cette rubrique se rapporte la fourniture complmentaire de solutions mtiers dj SOA (cf. chapitre 22). Les tableaux suivants toffent la description de ces diffrentes sous-familles de critres.
Socle de la plate-forme
Tableau 21.2 Les critres de couverture du socle SOA
No S1 S2 S3 S4 S5 Intitul du critre Dveloppement Test Excution Stockage Topologie Commentaires Proposition dune API complte permettant de dvelopper des extensions la plate-forme. Outillage pour mener des simulations, des tests dexcution avant connexion aux applications relles. Environnement dexcution distribuable (si possible bas sur un serveur dapplication du march). Intgration dun rfrentiel consolid pour le fonctionnement de la solution (paramtrage). Choix dune topologie de bus versus topologie de hub.
310
Coordination
Tableau 21.3 Principaux critres dune infrastructure de coordination SOA
No I1 Intitul du critre Orchestration Commentaires Fourniture dun moteur capable dexcuter des orchestrations de processus (gnralement suivant la spcification BPEL). Fourniture dun moteur de rgles capable de traiter des algorithmes complexes de routage dactivits dans un processus. Fourniture dun moteur capable dexcuter des squences par interventions humaines. Fourniture dun framework de gestion de contexte mtier. Support dvnements et de protocole de communication directe entre processus.
I2
Rgles de coordination
I3 I4 I5
I-P7 I-P8
311
No I-P9
Intitul du critre Mode Messages .NetRemoting Mode Query/Reply DCOM Transactionnel Tuxedo, CICS, IMS
Commentaires Fourniture dun adaptateur de protocoles capable dinvoquer des services distants en technologie Microsoft.NetRemoting. Fourniture dun adaptateur de protocoles capable dinvoquer des services distants en technologie Microsoft DCOM. Fourniture dun adaptateur de protocoles capable dacheminer des messages suivant des moteurs transactionnels du march (BEA, IBM, etc.).
I-P10
I-P11
Routage de messages
Tableau 21.5 Les critres techniques du routage SOA
No I-R1 Intitul du critre Rgles de flux Explicites/ Implicites Commentaires Fourniture dun moteur capable de prendre en charge diffrentes typologies de rgles de routage des messages incluant lutilisation de len-tte ou du contenu du message. Fourniture dun moteur garantissant la livraison et lacheminement des messages. Fourniture dun moteur proposant un service de souscription dvnements et de leur propagation. (cf. support de WS-Notification1). Support de MTOM et/ou dun acclrateur XML. Fourniture dun moteur assurant lutilisation dinfrastructures parallles.
I-R2
Garantie de dlivrance
I-R3
Publication/Abonnement
I-R4 I-R5
1. WS-Notification au sein de lOASIS semble rallier les diteurs pour amorcer la standardisation Web services des concepts de publication/abonnement voqus au chapitre 20.
Transformation de messages
Tableau 21.6 Les critres techniques pour la transformation en SOA
No I-T1 Intitul du critre Extensibilit de messages Commentaires Utilisation interne dun meta-language, du protocole SOAP pour lenrichissement de messages ou la prise en compte de protocoles propritaires ou nouveaux. Fourniture dun moteur de transformation des formats de messages sur le principe dun format pivot (souvent via XSLT).
I-T2
312
No I-T3
Commentaires Mise en correspondance dun message entrant avec un message sortant (fabrication visuelle, gnration de scripts, etc.). Fourniture dun moteur de transformation des messages ASCII en binaire. Fourniture dun moteur de transformation des messages binaires en ASCII (gnralement base 64).
I-T4
I-T5
Connecteurs directs
Tableau 21.7 Principaux connecteurs directs SOA
No I-C1 Intitul du critre Utilisation de donnes du SI Utilisation dapplications du SI Commentaires Fourniture de connectivit vers des bases des donnes relationnelles, annuaire dentreprise, etc. Fourniture de connectivit vers des progiciels mtiers ou des technologies spcifiques (SAP, Oracle Applications, Java, .NETnatif). Fourniture de connectivit dchanges inter entreprises (protocoles EDI, B2B). Fourniture de connectivit standard bas niveau (HTTP, FTP, SMTP, etc.).
I-C2
I-C3
I-C4
I-I2
Requteur unifi
I-I3
I-I4
313
No I-I5
Commentaires Utilisations transverses pour de multiples entits dinformation (client, produit, RH, etc.) et prise en compte de mta-donnes personnalises. Nettoyage de donnes non utiles, conformit de structure et de valeurs, gestion des doublons, etc. Utilisation des donnes dentreprise restituables sous plusieurs APIs (SQL, XPath/XQuery, Web Services, JDBC, ODBC).
I-I6 I-I7
Registre de services
Tableau 21.9 Principaux critres du registre SOA
No R1 R2 R3 Intitul du critre Dcouverte Rfrentiel Analyse dimpact Commentaires Capacit du registre offrir des fonctions dannuaire UDDI. Capacit du registre offrir des fonctions de rfrentiel public de services (Classification, contrat tendu, etc.). Capacit du registre offrir des fonctions danalyses dimpacts du changement dun contrat de service ou dun SLA. Capacit du registre offrir des fonctions dadministration, notamment en matire de rgles de validation et publication. Capacit du registre offrir des outils de contribution collaboratif (gestion de versions, de configurations. modification par des intervenants diffrents).
R4
Publication
R5
Contribution collaborative
Scurit
Tableau 21.10 Principaux critres de la scurit pour SOA
No S6 Intitul du critre Annuaire/Registre de scurit Authentification Habilitations Commentaires Fourniture dun registre pour la dfinition de politique de scurit. Souplesse de niveau dapplicabilit (par opration, par service, par groupements de services etc.). Fourniture doutils pour authentifier les accdants (X509, Token, etc.). Fourniture doutils pour grer les droits des accdants (suivant les spcifications XACML, WS-Authorization).
S7 S8
314
No S9
Commentaires Fourniture doutils pour propager le contexte de scurit des accdants entre services (suivant les spcifications SAML, WS-Trust, WS-Federation, Liberty, etc.). Fourniture doutils de signature lectronique pour assurer la non-rpudiation des actes des utilisateurs des services (suivant la spcification XML Signature). Fourniture doutils pour assurer la confidentialit des messages changs entre services (suivant les spcifications SSL, XML Encryption, WS-SecureConversation).
S10
Non rpudiation
S11
Confidentialit
Interfaces dadministration
Tableau 21.11 Principaux critres de ladministration SOA
No A1 Intitul du critre Gestion des configurations Commentaires Fourniture dune interface de configuration/paramtrage de la plate-forme. Cette interface permet aussi le dploiement des services (cf. SCA dcrit dans la partie 4). Fourniture dune interface de gestion du registre des services (contrats mtier, technique). Fourniture dune interface de gestion et contrle des politiques de la plate-forme : politique de scurit, politique sur les garanties dacheminement, SLA, etc. Ajustement et dlgation de plusieurs rles dadministration. Disponibilit dun accs 100 % Web en cas dhbergement distant.
A2
Gestion de registre
A3
Gestion de directives
A4
Suivi de performances
Tableau 21.12 Principaux critres du suivi de performance SOA
No P1 Intitul du critre Suivi oprationnel des services Commentaires Fourniture dun agent ou mcanisme de suivi technique remontant ltat (en attente, occup, satur, arrt, dficient, etc.), les performances et lexcution des services (messages et excution). Fourniture dun outillage de suivi remontant ltat, les performances et les erreurs dexcution des processus.
P2
315
No P3 P4 P5
Commentaires Persistance des valeurs dindicateurs et API daccs aux donnes historises. Intgration avec des outils de surveillance temps rel (console Tivoli, Patrol, HP, etc.). Fourniture ou intgration avec des outils de gnration de synthse graphiques, tableaux, textes et dagrgations dcisionnelles. Choix dun rendu et dun niveau de dtails. Fourniture dune interface de suivi des processus, avec choix des indicateurs et alertes lisibles par les mtiers remontant ltat, les performances et lexcution de processus et la corrlation dvnements (CEP). Mcanisme de vrifications de seuils par rgles et directives permettant dajuster les ressources en plus ou en moins. Mcanisme de rgulation des demandes.
P6
Suivi Mtier
P7
Ajustement de ressources
Atelier de conception
Tableau 21.13 Principaux critres de latelier de conception SOA
No F1 Intitul du critre Modles de processus mtiers Modles de compositions interactives Commentaires Fourniture dun outil graphique (type BPMN) permettant de modliser les processus mtiers excuter sur la plateforme SOA. Fourniture dun outil permettant de dfinir (puis gnrer) les reprsentations utilisateurs ainsi que leur cinmatique denchanement (en particulier, dans le cadre de Workflow). Il peut comporter un diteur textuel ou graphique du langage de reprsentation graphique (type XML, XHTML, XAML, XUL). Intgration ou interfaage avec un outil UML. Fourniture dun outil graphique permettant de modliser larchitecture globale de lenvironnement SOA de lentreprise. Fourniture dun outil graphique permettant de modliser les infrastructures physiques qui sous-tendent larchitecture SOA (machines serveurs et environnement rseau, comme des DMZ1). Intgration ou interfaage avec un outil UML.
F2
F3 F4
F5
Modles dinfrastructure
F6
Modle de traitements
1. DMZ signifie Zone Dmilitarise : il sagir de zones rseaux spcifiques, servant hberger des serveurs semiprotgs.
316
No F7
Intitul du critre Modlisation de donnes et de vues sur les donnes Simulation de processus
Commentaires Fourniture dun outil graphique permettant de travailler sur les modles de donnes, en particulier dans le cadre de mise en uvre de services CRUD (outillage EII/MDM). Capacit simuler lexcution de processus mtier pour valuer limpact dune modification (performance notamment).
F8
Atelier de fabrication
Tableau 21.14 Principaux critres de latelier de fabrication SOA
No F9 Intitul du critre Composition de services Dveloppement de composants Gnration automatique du code Fourniture de gnrateur de documentation Commentaires Fourniture dun outil de composition de services supportant ou non la norme SCA. Intgration ou interfaage avec un atelier de dveloppement de code (Java, C#). Fourniture de gnrateurs du code partir de modles (UML ou XML). Fourniture de gnrateurs du documentation partir des descripteurs de contrats (fiches de services, catalogue de services, indicateurs de processus, guide dutilisation des services lusage du consommateur, guide de scurisation, guide de dploiement lusage des quipes dintgration, guide de supervision mtier (SLA), destin aux matrises douvrage, etc.). Capacit de dveloppement de rgles IFTHENELSE.
F10
F11
F12
F13
Portails Composites1
Tableau 21.15 Principaux critres de linterface de prsentation SOA
No M1 Intitul du critre Composition IHM Commentaires Fourniture de composants de prsentation des services sous forme dIHM composite. Il sagit gnralement dun portail compatible avec WSRP. Linterface composite est alors un agrgat de Portlets , fragments dinterface du portail.
317
No M2
Commentaires Fourniture de composants de prsentation pour divers types de terminaux (PC, PDA, tlphone, etc.). ces composants pourront gnrer des contenus formats du standard XHTML ou Xforms. Fourniture de composants graphiques Ajax, support des formats RSS et outil de conception visuelle pour laggrgation de flux XML, support du protocole ATOM. Support des widgets UWA.
M3
Primtre mtier
Tableau 21.16 Principaux critres de couverture mtier SOA
No M3 M4 Intitul du critre Gestion dinformations dEntreprise (ECM1) Gestion de donnes internes dentreprise (GRH, GRC, Gestion Projet, ERP) Gestion de donnes externes dentreprise (SCM, eCommerce) Commentaires Progiciels SOBA de gestion de contenu, de documents, de connaissances. Progiciels SOBA de gestion des ressources humaines, de la relation client, des produits, des projets, etc.
M5
En rsum
Ce chapitre a donn une vision de premier niveau de la dmarche de choix doutil dans le cadre de la mise en uvre dune plate-forme SOA. Les critres proposs ici sont un point de dpart pour une analyse densemble. Ces grilles de choix devront tre adaptes chaque dmarche SOA. Les critres aussi bien organisationnels, financiers et techniques devront tre dtaills pour permettre une comparaison globale juste et pertinente.
22
Tous vers SOA !
Objectif
La communaut des prtendants est immense. Ils sont issus des brokers Corba, de lEAI ou de lETL, du monde des applications mtiers, de la gestion dinformations au sens large, voire mme du poste client, de la scurit ou de la gestion de la performance ou mme tout simplement encore du rachat de logiciels. Cest aujourdhui lensemble de la communaut des diteurs, quils soient caractre commercial ou libre, qui sintresse donc fournir tout ou partie des briques ncessaires la plate-forme SOA prcdemment dcrite. Ceci remet en cause progressivement lensemble des outils de ralisation et de production en place dans les SI et les quipes informatiques mais apporte aussi de nouveaux outils pour les mtiers. Une nouvelle typologie semble se dgager progressivement lchelle du march.
320
Lillustration de la figure 22.1 synthtise les principaux acteurs du moment en distinguant cinq catgories principales : Les vendeurs gnralistes : Il sagit doffres caractre commercial mais ne constituant pas, loin sans faut, lintgralit du portefeuille du fournisseur logiciel. On retrouve principalement ici IBM, Microsoft ou Sun. Les vendeurs spcialistes : Bien que toujours caractre commercial, ces solutions constituent cette fois la grande majorit du portefeuille dun spcialiste logiciel, ou du moins le cur de sa stratgie logicielle. Ce sont, pour la plupart, des acteurs historiques ayant su anticiper sur lenrichissement de leur produit dinfrastructure dintgration respectif. Ils sont issus du monde du transactionnel et des serveurs applicatifs, du MOM vnementiel ou de lEAI tels que BEA, TIBCO ou WebMethods.
SOA Ready
Les diteurs de progiciels : Il sagit principalement des diteurs de progiciels applicatifs comme SAP ou Oracle. Se retrouvent galement dans cette catgorie les grands acteurs de la gestion de contenu au niveau entreprise (EMCDocumentum, OpenText ou Interwoven). Les communauts Open Source : Avec lessor des normes et standard (cf. partie 4), des communauts reconnues de dveloppement de logiciels libres abritent dsormais de nombreux sous-projets visant notamment certaines briques centrales dinfrastructure SOA comme le bus, lorchestrateur ou la
321
chane de fabrication logicielle. Se distinguent notamment les communauts Apache, Eclipse, ObjectWeb et RedHat. Les constructeurs matriels : La recherche de loptimisation des performances est un axe faisant aussi merger un ensemble dacteurs proposant directement des botiers matriels en guise de modules pour une plate-forme SOA. Cela couvre notamment lacclration de traitements XML, XSLT, XQuery ou protocoles WS-*, le routage et la transformation de messages de services (bus de services), la scurit et le respect de directives, mais aussi le suivi des services et jusquau contrle du flux amont (messages, ou vnements) des applications clientes. Ce march se consolide actuellement via de nombreux rachats significatifs comme celui de Datapower (par IBM), Reactivity (par Cisco), Sarvega et Conformative (par Intel), ou dautres restant encore spcialistes indpendants et souvent pionniers, linstar de Layer 7 Technologies, F5 Networks, Forum Systems, Solace Systems, Sonoa Systems, LogLogic, Xambala On notera que de nombreux fournisseurs SOA commerciaux trouvent aujourdhui intrt investir plus ou moins dans lopen source, soit pour revendre des distributions plus avances bases sur souche open source (exemple IBM), soit pour fournir des distributions en double licences (exemple Active EndPoints), soit enfin pour fournir des distributions avec assemblage, support et maintenance propre (exemple RedHat, Iona, etc.). Si le modle conomique open source a le mrite de rduire le cot initial dacquisition, il ne rduit pas toujours pour autant le cot total. Il peut mme se rvler moins conomique long terme pour certaines organisations. Il convient donc dans ce processus de slection de plates-formes de ne pas faire de raccourcis trop htifs.
22.1.1
IBM
Class (selon les analystes) premier ou second diteur de logiciels lchelle mondiale, IBM nannonce pas moins de 30 produits pour SOA rpartis sur quatre gammes : Lotus, WebSphere, Information Management et Tivoli. Lditeur est par ailleurs capable de commercialiser des solutions globales : matriels, logiciels, services, conseil et financement. Au sein de la gamme WebSphere, se trouve principalement WebSphere Business Integration qui regroupe la famille des produits commerciaux de la plate-forme SOA IBM, bass sur socle ddition Eclipse et socle dexcution du serveur applicatif WebSphere ( WAS )1. On y retrouve notamment :
1. WAS WebSphere Application Server dispose dextensions (Features Packs) permettant le support de fonctionnalits comme EJB3 SCA/SDO, les protocoles WS-* et Web2 sans attendre le support intgral dune nouvelle version JEE.
322
WBM WebSphere Business Modeler est latelier de modlisation des processus et rgles mtiers. Il permet aussi la dfinition fonctionnelle dcrans, formulaires ou indicateurs de performance. Il apporte en outre, des moyens de simuler et doptimiser les processus, via la remonte de mesures captures lexcution (cf. plus bas WBM ). Loutil permet lexport XPDL2 et BPEL2 pour alimenter dautres chanes (par exemple le moteur de workflow FileNet ou lenvironnement pour dveloppeurs WID ). La version tendue WebSphere Publishing Server fournit quant elle, un portail Web collaboratif pour runir plusieurs rles changeant autour de la modlisation mtier. WID WebSphere Integration Developer est latelier ddi la construction de solutions mtiers SOA. Il intgre en outre la reprise des conceptions mtiers issues de WBM, selon des choix techniques, notamment gnration dcrans WorkPlace, JSF ou Portlets, prise en compte dextensions BPEL2 spcifiques pour les tches humaines, la gestion de contexte, etc.). Il permet deffectuer lassemblage des composants au travers doutils ddition graphique assiste (XML, XSD, WSDL, SCA, etc.) en vue du dploiement sur les serveurs BPM ou ESB de lditeur (cf. plus bas). WID peut, le cas chant, proposer un cycle de conception itratif en approche descendante (par analyse de diffrences et fusion) ainsi quune traabilit dimpacts potentiels sur la conception mtier initiale, en cas dapproche remontante. WebSphere ESB 1 est le socle ESB Java/SCA/SDO tandis que WebSphere Message Broker constitue un ESB alternatif bas sur ESQL et le middleware historique de lditeur. Ces deux dclinaisons disposent de mcanismes de clustering et dexploitation diffrents du fait de leur socle WAS et MQ respectif. En outre ils bnficient dsormais de WTX WebSphere Transformation eXtender , issu du rachat Ascential, permettant de produire visuellement des transformations complexes et de les exposer en services. On notera que IBM, linstar dautres diteurs commerciaux comme BEA ou Oracle, mise sur la norme SCA et non sur JBI considr comme trop restrictif Java. Le recours possible lenvironnement de dveloppement Rational permet de fluidifier la fabrication de services Java, notamment au travers dateliers ddis larchitecture, la conception et la gnration de squelettes des services. WSRR WebSphere Service Registry and Repository , issu du rachat BuildForge et port sur socle WAS, fournit un rfrentiel et un registre de services. Il gre le stockage des mtadonnes de services, leur classification et jusquau cycle de vie via une machine tats permettant de maintenir un statut et un processus de validation. Il peut tre utilis directement depuis Eclipse pour de lanalyse dimpacts, ainsi qu lexcution avec WESB pour effectuer du routage dynamique par genration java. Il peut aussir servir au monitoring pour des mtadonnes dynamiques, tel un temps de rponse, exploitable ensuite via Tivoli ITCAM for SOA (cf. plus bas).
1. noter quil existe aussi une offre ESB WebSphere Message Broker sur socle WebSphere MQ en lieu et place de WAS, ainsi quune offre ESB matrielle sur systme hardware XI50.
323
WebSphere Process server constitue lenvironnement serveur dexcution BPM clusterisable et distribuable de Big Blue. Construit sur WESB, il fournit dsormais plusieurs types de composantes sous forme SCA (BPEL/WS-BPEL, tches humaines, machine tats, moteur de rgles). Lensemble peut en outre sappuyer sur des services dinformations mtiers (maps SDO), une slection dynamique des services ainsi que WebSphere Virtual Member Manager pour implmenter un service organisation (cf. Chapitre 9 Router les processus). WebSphere Business Monitor possde deux dclinaisons pour le BAM incluant un serveur dvnements. Lune reste simplifie sur seule base de tableaux de bords Web2.0, socle WAS et capture dvnements au format CBE sur JMS/MQ. Lautre permet une analyse dcisionnelle beaucoup plus riche en ajoutant DB2, Cube Views, AlphaBlox ainsi que WebSphere Portal permettant un requtage interactif multidimensionnel et une personnalisation par profils. Cette offre WBI peut encore stendre au-del avec : WebSphere Adapters qui fournit un ensemble de connecteurs techniques gratuits (FTP, email, etc.) et de connecteurs payants notamment pour les progiciels reconnus du march. Chaque connecteurs se veut bidirectionnel et peut communiquer avec le BAM sous forme vnementielle. Loffre WebSphere Partner Gateway spcifique aux adaptateurs B2B (et ncessitant encore une intgration bas niveau manuelle via JMS ou MQ) devrait, terme, rejoindre ce modle SOA vnementiel. WebSphere Business Fabric , alias Webify sinscrit au-del de linfrastructure pour fournir des frameworks de productivit mtiers dclins verticalement par secteur tel que la banque, lassurance, la sant, les tlcommunications, etc. Ce produit apporte ici les premires briques dun difice mtier pr-packag sur base SOA/BPM. En outre cela permet de disposer de modles de services, modles de processus, modles dindicateurs, modles de directives, modles de tableaux de bord, etc. Bien que rcent, ce type de produits, apporte une relle plus value sur la notion dindustrialisation de solutions mtiers et rejoint dsormais les initiatives de passage SOA des grands progiciels de gestion type ERP ou CRM (SAP, Oracle, etc.) Pour la scurit SOA, IBM place dsormais en avant son offre matrielle DataPower . Celle-ci, se dcoupe ce jour en trois types de boitiers : XA35 pour lacclration XML; XS40 pour le pare-feu XML, les Web Services, lhabilitation, lencodage, et WS-Security; XI50 embarque quant lui les possibilits prcdentes, et permet aussi le mixage de protocoles, la transformation any-to-any grce WTX et un dploiement via console Web ou Eclipse pour satisfaire des besoins de configuration ou de dveloppement. On notera ici que les chaines de transforma-
324
tions WTX peuvent gnrer directement du micro code ou du code C++ et sont exposables comme des services. Les produits ddis la prsentation dans le cadre Web2/SOA/BPM ne sont pas en reste chez ce gant du logiciel. On y retrouve notamment WebSphere Portal qui demeure linterface utilisateur pour accueillir la prsentation Web Java native des processus et la prise en compte ventuelle de WSRP. IBM propose aussi un Mashup Starter Kit avec un serveur dalimentation et dagrgation de flux dinformations ainsi quun outil RAD dassemblage baptis QEDwiki pour la ralisation rapide de mashups dentreprise sur base de services de contenus ou de donnes. Sur le socle Eclipse RCP et Lotus8, IBM reformule galement son offre de collaboration, WorkPlace, et propose une dclinaison client riche composite ( Expeditor ) ainsi que son offre de gestion documentaire SOA (FileNet Web Services/OpenClient). La gamme Lotus stoffe aussi en outils de dveloppement et dexcution avec un environnement unifi dinterfaces utilisateurs composites pouvant accueillir composants NSF, composants Java/Eclipse, composants portlets JSR168, etc. Dans sa gamme Information Management, IBM tend son portefeuille dinfrastructure pour les services dinformation. Outre la proposition SDO Service Data Object visant fournir un mcanisme unifi de reprsentation et daccs des sources htrognes de donnes. Lancien produit DB2 Information Integrator (Websphere Federation Server) est galement intgr WebSphere afin de fournir des services daccs en temps rel aux sources de donnes de type EII. Deux briques MDM (issues du rachat successif de Trigo et DWL) apportent respectivement la structuration de produits (WebSphere Product Center) et de clients (WebSphere Customer Center) malgr des philosophies dutilisation non harmonises ce jour. Lditeur dispose aussi dune mcanique ETL robuste et de connecteurs B2B/EDI (issu de lacquisition Ascential) ainsi que dune offre de services danalyse dcisionnelle via le rcent rachat de Cognos. Enfin, la gamme Tivoli fournit les outils de surveillance bas niveau, la gestion didentit ( TIM1 complt du rachat MetaMerge), la scurit des Web Services ( TAM2 ), et le monitoring dapplications composites (ITCAM3).
Microsoft
La firme de Redmond nest plus prsenter. Depuis longtemps reconnu pour ses logiciels sur le poste client, elle continue se valoriser sur le serveur et apparat de plus en plus complte, notamment dans le cadre de lvolution de sa technologie .NET. Son socle technique, depuis sa version 3, senrichit pour SOA, et dispose dsormais dun mcanisme unifi de communication baptis Windows Communication Foundation WCF ainsi que dun moteur de workflow baptis Windows Workflow Foundation WWF .
1. Tivoli Identity Manager. 2. Tivoli Access Manager. 3. Tivoli Composite Application Manager for SOA.
325
WCF fournit un modle programmatique permettant de dcoupler limplmentation des choix de dploiement de services (choix de protocoles http ou tcp, choix de format dencodage binaire ou soap, choix de ports, niveau de scurit, mode transactionnel, asynchronisme, etc.). Il harmonise lensemble des technologies Microsoft (COM, DCOM, MSMQ, Enterprise Services, .NETRemoting, Web Services, REST XML), notamment en monde distribu. Il utilise les capacits dannotations du langage .NET en proposant une externalisation et un dcoupage du contrat de base et du contrat tendu. WCF peut aussi gnrer des traces WMI en vnementiel, appliquer par AOP des pre/post-traitements transversaux (behaviors) diffrents niveaux de granularit, et dispose dune console technique baptis TraceViewer . Le moteur WWF, galement intgr au framework souche, fournit quant lui, un modle programmatique et un serveur dexcution de workflows applicatifs. Au-del et dans loptique darchitecture ncessitant la prise en compte dun mdiateur devant grer une varit de transformations de messages et de routages, Microsoft propose son produit Biztalk Server, entirement ralis en interne, et actuellement dans sa cinquime version (2006 R2). Celui-ci peut dsormais bnficier de nombreux connecteurs rcrits selon le mcanisme WCF, et directement packag au sein de Biztalk, notamment pour des changes techniques (type fichier, mail etc.) mais aussi pour les formats des progiciels du march et pour le B2B dont la norme AS2 pour lEDI sur Internet. Biztalk offre une plate-forme complte avec un orchestrateur de processus bas sur WWF et pouvant tirer parti dun moteur de rgles techniques paramtrables ( BRE ) ainsi quun outillage visuel de modlisation de processus et une gestion de formulaires pouvant sappuyer sur le produit de conception graphique ddi MSInfoPath et sur le portail MOSS 2007. Loffre comprend en outre, un serveur dintgration orient messages (bas sur MSMQ) avec transformation des donnes. Ce serveur sappuie sur des pipelines prdfinis facilitant la ralisation de rgles de transformations et de routage de donnes XML. Le rfrentiel des donnes ou des messages peut sappuyer en outre sur les nouvelles capacits de rplications et de gestion de files dattente ou dintgration par messages offertes par SQL Server 2005 SSB . Lditeur dispose aussi de rponses sur les besoins dadministration et exploitation unifie au travers dune cartouche pour Microsoft Operation Manager . Malgr une dpendance certaine la base de donnes SQL Server pour le stockage des messages, Microsoft offre aussi un module BAM au travers de SQL Server 2005 Integration Services pour la collecte dindicateurs, et dextensions OLAP Analysis Services ou de rapports Reporting Services directement exploitables dans MSExcel ou au travers de portlets WebParts MSSharePoint . Ce BAM dispose dintercepteurs configurables permettant notamment dtendre le contrle de directives de services via des produits tiers
326
spcialiss (par exemple AmberPoint ou SOA Software). Enfin le rcent rachat de Stratature, laisse entrevoir lmergence progressive dune solution MDM part entire, notamment pour lanalyse consolide de donnes. Ce produit pourra aussi complter judicieusement loffre de progiciels Office Business. Bas actuellement sus le registre Systinet, Microsoft vise limplmentation dun rfrentiel de services, processus et donnes ainsi quun suivi des ressources IT au sein de la prochaine version de son systme dexploitation Windows. Ceci permettra den faire tirer profit lensemble des applications serveurs crites avec MS .NET, ainsi que les prochaines versions de son offre collaborative MOSS2007 ou de son offre progiciel de gestion, mais aussi Biztalk pour lhistorisation des traitements et transactions sur messages. Microsoft ne prsente donc pas Biztalk comme une rponse lESB, mais fournit pour cela un rfrentiel de pratiques architecturales baptis ESB Guidance sous la forme dune communaut open source, affichant clairement autour de .NET et Biztalk, une volont nouvelle dinteroprabilit multi-technologiques vers PHP, Java1, etc. Sur le plan du dveloppement, et dj linitiative de SOAP, le gant du logiciel poursuit une volont affiche dun usage rpandu du mta langage XML dans tous ces produits (cf. GXA) et implmente le support tendu de Web Services via WSE. Au travers de Dynamic Systems Initiative, lditeur soutient aussi SML dans le but de dcrire, mesurer dynamiquement et contrler le contrat tabli sur les composants dune infrastructure. Microsoft investit galement sur la productivit des quipes de conception, dveloppement, tests et dploiement, notamment au travers des extensions apportant une intgration trs forte avec Visual Studio Team System, sa chane de fabrication logicielle, et lenrichissement progressif de designers de DSL2 ddis chaque rle dans le but dindustrialiser la conception SOA. Microsoft nest pas en reste sur la prsentation de services, notamment avec la monte en puissance de Silverlight faisant converger approche Web2, RIA et 3D mais aussi doutils de fabrication rapide, graphique, et hberg de mashups composites comme PopFly. Au-del des produits de cette plate-forme SOA, Microsoft a dj prvu dutiliser les nouvelles moutures plus modulaires dOffice et des Smarts Documents pour combiner approche Service et mode hberg via ce que lditeur dmarque en Software + Service ou S+S 3. Cela permettra dune part denvisager lusage de multiples outils Microsoft directement excut et packag distance, mais aussi de combiner de manire transparente les avantages dinterfaces riches, du Web et de la puissance de serveurs hbergs. On peut dj entrevoir de consommer un simple service de messagerie combin un service de base de donnes, jusqu un service final de type CRM.
1. On y dcouvre notamment lexistence de JNBridge pour envisager la connectivit de Biztalk avec un serveur JMS du march. 2. Voir ce titre, larrive de produits tiers comme SOA Factory chez Avanade. 3. Voir par exemple Microsoft Live Services ou Online Services from Microsoft (Exchange Hosted Services, Microsoft Biztalk Services, etc.).
327
SUN
Loffre est issue du rachat de Seebeyond et transforme une nouvelle fois le portefeuille de logiciels dtenu par SUN. Malgr lhomognit actuelle de la suite rachete, rebaptise JCAPS (Java Composite Application Platform Suite), lditeur californien ne cache plus son ambition en matire open source. Il a dailleurs fourni lui-mme la premire implmentation JBI1 OpenSource baptise OpenESB . Lenvironnement NetBeans, rival dclar de lIDE Eclipse, et notamment apprci pour sa productivit avec le serveur dapplication JEE de Sun JSAS, fait galement parti de cette offre pour en constituer le socle. SUN prserve donc dans JCAPS et de manire commerciale lESB eGate incluant un rfrentiel et un registre de services UDDI, le BPM eInsight capable de ralis des invocations BPEL de web services ou de composants Java ou EJB et muni dun modeleur BPMN, ainsi que des facilits pour le B2B (eWay Adaptors, eXchange Integrator et eXpressway Integrator) issus de ce rachat. La suite est supporte sur plusieurs systmes dexploitation (Solaris, Windows, autres Unix et Linux). Peuvent aussi sy ajouter latelier de supervision BAM eBAM Studio, le portail JSPS et un outil de composition dinterface CWI ainsi quun gestionnaire de rfrences croises eView Studio orient client. En termes dinfrastructure, SUN propose JSDS un annuaire reconnu sur le march, JSAM pour la gestion daccs et la fdration didentit selon Liberty Alliance ainsi que Identity Manager pour le contrle de directives et lapprovisionnement didentits. On notera galement eTL pour la synchronisation de donnes. SUN distribue avec JCAPS un environnement unifi pour la conception de compositions, baptis Enterprise Designer. Ce dernier regroupent dans un mme outil, les objets de prsentation (crans et formulaires, flot de navigation, feuilles de styles, etc.), les services quelque soit leur granularit et les processus mtiers. Enterprise Designer propose aussi laccs la configuration dans les diffrents modules de JCAPS ainsi quun mappeur de collaboration permettant de raliser des intgrations entre systmes bases sur des objets communs (format pivot) relis via des fonctions (rgles mtiers crites par un profil technique) et sur lesquels pourront se baser les services mtiers puis les services composites ou les orchestrations en processus mtiers. Il permet enfin, par ce rfrentiel centralis, la gestion de projets et celle du dploiement multi-environnements (tests, production, etc.). Une console Web baptise Enterprise Manager apporte un suivi et une administration SAM galement centralise pour les plateformes dexcution, le suivi des SLA sur les messages de services ainsi quun suivi graphique de lexcution des processus mtiers. Lditeur fournit enfin des frameworks acclrateurs de SOA, notamment Common Service Framework CSF pour le suivi des services et Service Governance Framework SGF pour le
1. Pour faire trs bref, on dira que JBI vise standardiser la messagerie interne de lESB, telle que la figure 18.3 lillustre, et surtout la faon dont un module ESB (traducteur, routeur, connecteur) dialogue sur cette messagerie interne.
328
contrle de conformits des directives. Du ct des moteurs graphiques, SUN propose une alternative open source Microsoft Silverlight et Adobe Flex baptis JavaFX, offrant un mme langage de scripts disponible aussi bien pour des postes clients riches, clients Web ou Mobiles consommateurs de services Web2 ou SOA.
22.1.2
BEA
Acteur depuis seulement 1995, la rputation de BEA nest plus faire dans le monde des middlewares (moniteur transactionnel Tuxedo rachet Novell, MOM JMS, serveur dapplication, broker dintgration, etc.). Faisant suite son approche de frameworks dapplications via la gamme WebLogic , BEA a lanc depuis prs de trois ans, une nouvelle gamme baptise AquaLogic et ddie lapproche SOA. Aqualogic souhaite aujourdhui couvrir un primtre de bout en bout (baptis entreprise 360 ) pour une infrastructure globale destine des applications composites transverses et multi-technologiques dans lentreprise : Prsentations composites : ALUI AquaLogic User Interaction est une plate-forme (issue du rachat Plumtree) pour la ralisation, lexcution et ladministration dapplications de type portail, Widgets Ajax et Web flow avec contexte de composition. ESC Enterprise Social Computing est une plate-forme pour la ralisation, lexcution et le suivi dapplications de type mashups Web2 pour les besoins dutilisateurs finaux et de dveloppeurs de Widgets (il permet en outre le mixage rapide de flux RSS, WS-* avec un outil de recherche collaborative et un mcanisme de scurisation et de statistiques sur ces flux). Mtiers composites : destins servir de plate-forme dintgration pour les processus et services mtiers, AL BPM AquaLogic Business Process Management , issu du rachat de Fuego, est un orchestrateur de processus automatiss et interactifs aujourdhui pleinement intgr au bus de services ALSB AquaLogic Service Bus . Ces deux serveurs peuvent en outre respectivement bnficier de consoles BAM et SAM (cf. Workspace 360). Deux ateliers de modlisation complmentaires, sur socle Eclipse, sparent dune part, lactivit danalyse et optimisation mtier des processus, et dautre part lintgration de services aux processus. noter galement, WebLogic Event Server , permettant de faire de la corrlation statistique dvnements afin de remonter des vnements synthtiques pour la console BAM. Les tableaux de bords BAM peuvent tre exposs travers une prsentation composite. Donnes composites et Services composites : ALDS AquaLogic Data Services et WLI WebLogic Integration fournissent linfrastructure SOA pour les quipes techniques. Ils permettent respectivement la ralisation, lexcu1. Cette catgorie tant vaste, le livre ne peut retenir certains diteurs ultra spcialistes actuellement en pointe sur des modules particuliers tel que Amberpoint, HP/Systinet ou SOA Software pour la gouvernance, Intalio sur le BPM, ou Orchestra Networks sur le MDM.
329
tion, ladministration et la scurisation de services de donnes (cf. EII) ou lorchestration de services de traitements, via des connecteurs pour les protocoles techniques standards et les systmes patrimoniaux. Ce socle respecte dsormais la spcification SDO. Dploiement et virtualisation. Dans cette vision, BEA mise dsormais au-del de JBI (Java) et propose dj le support de SCA pour linteroprabilit multi-language et le choix tardif du mode de dploiement. Un nouveau module ( Service Assembly Manager ) doit dailleurs y tre ddi. A noter dans ce mme cadre, linitiative mSA micro Service Architecture ainsi que lessor de produits de virtualisation ( Barre Metal ) intgrant la JVM et le serveur Java de BEA. Par ailleurs, BEA sefforce denrichir une usine logicielle pour couvrir lensemble du cycle de vie dapplications composites. Cette initiative, baptise Workspace 360 , vise un environnement unifi et collaboratif adressant la fois, les analystes mtiers, les architectes, les dveloppeurs et jusquaux exploitants et responsables dapplications. Bien que les ateliers frontaux soient bass sur socle Eclipse open source, ils restent soumis licences payantes contrairement dautres fournisseurs concurrents. Les consoles dadministration sont galement unifies sur base des fonctionnalits disponibles dans les modules de prsentation composite. Cette vision 360 permet donc de couvrir des proccupations danalyse et doptimisation, de conception (rutilisation, dpendances, configuration, etc.), de ralisation (implmentation et intgration) mais aussi de production (suivi) et de pilotage (retour sur utilisation, etc.) autour dun rfrentiel central baptis ALER (AquaLogic Enterprise Repository) . Ce dernier, issu du rachat de Flashline par BEA, permet une gestion lectronique du cycle des artefacts de composition (contrats de services, directives de conception etc.) avec de nombreuses ouvertures pour une consultation ou une publication pour la panoplie doutils prsents dans lentreprise sur le dveloppement, le test, la gestion de configuration, la gestion documentaire, le registre dexcution des services1 etc. En matire de gouvernance des services, BEA tend dsormais cette gamme en fournissant ALES (Aqualogic Enterprise Security) pour servir de console centrale dautorisation, de distribution des directives et de vrification de leur dploiement. Enfin, ALSM Aqualogic Service Manager permet le suivi technique de la mise en service (SAM) et fourni une cartographie du trafic laide dagents par technologie de messages. BEA participe trs activement par ailleurs, aux cts de Microsoft et dIBM, la dfinition des standards ddis la mise en uvre des Web Services ainsi quaux efforts de normalisation pour SOA en contexte htrognes de technologies (SCA, etc.). noter enfin, que linfrastructure Aqualogic peut aussi sintgrer avec un registre tiers comme celui de Systinet (Mercury) ou un BAM spcialis comme celui de AmberPoint ou un MDM orient client comme celui de Purisma.
1. BEA propose dailleurs un OEM baptis ALSR (Aqualogic Service Registry) fournissant un registre de services notamment pour le contrle de directives lexcution.
330
Tibco
Est-il besoin de rappeler la signification du nom TIBCO (The Information Bus COmpany) ? Cet acteur historique du monde de la finance grce son robuste middleware asynchrone orient publication/abonnement RendezVous , reste aujourdhui un pure-player trs prsent. LEAI historique de lditeur sest vu initialement tendu dun conteneur Web Service BusinessWorks . Cette dualit sestompe pour laisser place un vritable ESB unifiant la transformation et le routage de messages ou dvnements. Les connecteurs directs EAI/B2B font galement la forte valeur ajoute de BusinessWorks. Un module registre ActiveMatrix Registry propose la solution Systinet en OEM mais dautres annuaires restent possibles, tandis que ActiveMatrix PolicyManager propose une traabilit des entrants/sortants ainsi que des fonctionnalits de cryptage pour la scurisation des services. Le module XML-Canon permet limport/export XML de tout composant du rfrentiel oprationnel dexcution et assure une organisation cohrente et scurise des donnes, des services et des processus. Le module dorchestration iProcess est dsormais intgr BusinessWorks et dispose dune trs riche supervision mtier BAM bientt capable de proposer des assistants pour acclrer le choix dindicateurs notamment grce une slection de type dentrants selon la performance des services par consultation directe de ActiveMatrix. Tibco BAM peut aussi bnficier dun gestionnaire dvnements mtiers complexes BusinessEvents proposant un cache distribu pour la corrlation en mmoire dune trs grande quantit dvnements. iProcess supporte la gestion de transactions et de processus longs et bnficie de TBR comme moteur de rgles. Tibco propose gratuitement BusinessStudio comme outil de modlisation mtier sur socle Eclipse avec support de notation BPMN, import/export XPDL et prochainement BPDL permettant de combiner processus et rgles. Il permet aussi des simulations destination de maitrise douvrage et un affinage de conception par un architecte ralisant le cblage des processus sur les services par interrogation dun annuaire UDDI ou du bus BusinessWorks. BusinessStudio permet un dploiement direct dans iProcess et Tibco Asset Central qui apporte un versionning au niveau fichiers (XPDL, WSDL) dun mme projet. Collaborative Information Manager est la rponse MDM de Tibco. Issu de lacquisition de Velosel, initialement ddi un rfrentiel produit, il peut dsormais jouer le rle dun meta-catalogue et tire parti dune intgration avec BusinessStudio, BusinessEvents et le B2B. TIBCO dispose aussi dune solution ETL DataExchange . Lditeur propose la fabrication de portails avec PortalBuilder mais aussi un environnement de composition RIA General Interface avec un environnement intgr de dveloppements (IDE) open source1, des composants Ajax sur tagres et un Bus Ajax qui permet une communication multiplexe, filtrable et voire streame pour pousser des flux de donnes vers la couche de prsentation accdant aux services. Ce bus de prsentation permet en outre de corrler les vnements de la cou1. Voir galement la communaut en ligne Tibco Developer Network.
331
che cliente et ceux de la couche serveur afin de produire des tableaux de bord temps rel sur de gros volumes dinformations par exemple. Enfin, Tibco amorce galement ActiveMatrix Service Grid pour une virtualisation de services dans un seul conteneur pouvant accueillir des services composants SCA et JBI distribuables en multi-technologies avec gestion de leur disponibilit, scurit et une administration centralise
Progress/Sonic Software
Dsormais filiale de Progress Software, Sonic Software est le premier acteur avoir revendiqu une solution en topologie distribue. Le cur de transport Sonic MQ repose sur un bus asynchrone distribu, dvelopp en interne, sur lequel Sonic ESB propose des fonctionnalits de routage et transformations techniques de messages ainsi que dun conteneur pour WS-*. On peut aussi y adjoindre XML Server pour un traitement (XSLT, XQuery) optimis et un stockage XML natif ou Sonic Database Service pour acclrer la ralisation de services CRUD sur des accs SQL des bases de donnes relationnelles. Le discriminant majeur de loffre tant la souplesse de distribution en segments du bus toute en gardant des capacits de configuration et dadministration centralises. Bien quil soit possible de lui reprocher une frontire trop lgre entre outils de dveloppements et outils dadministration, ainsi quune dpendance au serveur applicatif fourni, Sonic dispose dune infrastructure volutive pour la monte en charge. Loffre peut se complter avec : DataXtend qui apporte une infrastructure pour concevoir et excuter des services dinformations sur des sources de donnes htrognes. Il propose notamment un environnement de conception sur base Eclipse pour raliser des vues logiques (par transformation, agrgation, validation et application de logiques mtiers sur des donnes) et fournit un framework dexcution capable dauditer les services ainsi gnrs et dploys en EJB, Web Services, etc. Lensemble peut reposer sur un socle unifi de connectivits via DataDirect, et apporte aussi des capacits daccs temps rel (en lecture ou mise jour), de synchronisation et mise en correspondance de donnes (type EII) ainsi que la possibilit de construire des hubs locaux de donnes pour des accs plus performants sur de multiples rfrentiels. Apama, un moteur de corrlation dvnements (type CEP) pour lanalyse et le suivi temps rels dvnments techniques ou mtiers. Ce moteur peut sutiliser avec Apama BAM qui fournit des tableaux de bords accdant aux rgles du moteur ainsi quun environnment RAD de ralisation de consoles adhoc. Lditeur propose dsormais galement, la solution TeamWorks BPM de Lombardi en OEM qui se retrouve intgre par Sonic Software au bus Sonic ESB. Ceci permet la ralisation dorchestration mtiers sur des systmes fortement distribus,
332
tout en apportant un environnement de modlisation confortable pour des acteurs mtiers. On notera enfin lajout rcent du portefeuille Actional au sein de Progress Software qui positionne dsormais cet acteur dans les leaders de ladministration de services et du contrle de directives de services exposs au sein du SI de lentreprise. Lditeur propose enfin OpenEdge une plate-forme de gnie logiciel unifie pour la conception et lexcution de solution SOA base sur ABL Advanced Business Language. Reprenant les concepts de Progress 4GL, il stend en outre dun atelier ddi aux architectes, dun Studio pour dveloppeurs acclrant la fabrication dinterfaces utilisateurs et dapplications composites interactives sur des objets logiques, en passant par la localisation et jusquau dploiement, la gestion de configuration et la gnration automatique de code en particulier autour des contrats et de la composition de services.
Software AG / WebMethods
Acteur historique depuis 35 ans des bases de donnes lgataire avec ADABAS et le langage NATURAL sur Mainframe, lditeur allemand trouve dsormais un nouvel essor suite lacquisition de WebMethods qui vient enrichir fortement sa plateforme SOA et former ainsi une nouvelle division ddie. Constitu au dpart de son rfrentiel natif XML ( Tamino ), la suite dabord baptise Crossvision et ddie notamment aux services dinformations, devient WebMethods Product Suite. Elle est fournie par dfaut sur le serveur applicatif JBoss, mais reste portable sur dautres serveurs applicatifs. Au sein de la plate-forme, WebMethods BPMS apporte un orchestrateur BPEL de processus ainsi quun bus de services WebMethods ESB pour le routage, la transformation de messages et la connectivit des rfrentiels patrimoniaux varis. Pour le BAM, lditeur met laccent sur les indicateurs de performances et loptimisation des processus et de linfrastructure par analyse de patterns au sein dun historique. Ce principe de mesures et surveillance mtier se retrouve galement dclin pour les changes B2B ou SAP. La suite regroupe enfin un EII, baptis Webmethods Information Integrator , pour les vues unifies temps rel ainsi que WebMethods MDM , un MDM gnraliste. Software AG dispose par ailleurs dun moteur de workflow cibl pour les interactions humaines et, dun environnement de composition Ajax ou SWT disponible en mode autonome ou plug-ins sur Eclipse. Enfin, Legacy Integrator permet douvrir les donnes et applications, notamment du mainframe, en les exposant comme des services Web. Un registre et rfrentiel, baptis CentraSite, est utilisable par chaque module et sert la fois pour lenregistrement et le dploiement de modles de donnes, de services, ou de descriptions de processus. Il constitue loffre centrale de gouvernance SOA pour Software AG et saccompagne dune initiative communautaire rejointe par plusieurs autres diteurs (Fujitsu, AmberPoint, Novell, etc.).
333
Iona
Faisant parti des leaders pour son broker Corba, Iona a cette fois choisi de parier sur un moteur fortement paramtrable par les adaptateurs de protocoles, baptis Artix . En outre Iona mise sur limplmentation facilite de nombreux patterns dintgrations. Une branche de dveloppement spare, Celtix , base sur un principe similaire, fait dsormais partie du projet Open Source CXF (cf. Apache plus loin).
22.1.3
SAP
Le leader des progiciels de gestion intgr a trac une route faisant sa force depuis son origine, le tout paramtrable . Une volution majeure le conduit actuellement une refonte progressive de son offre selon deux axes : en la rendant pilotable par les processus, autrement dit en externalisant ces processus de limplmentation des fonctionnalits de gestion ou daccs aux donnes; et composable avec des modules mtiers non-SAP. Cette nouvelle stratgie est baptis Enterprise SOA. Lambition de cette flexibilit amorce en 2003, doit aussi reposer sur une infrastructure que lditeur allemand entreprend aussi de fabriquer en interne sous le nom Netweaver . Il sagit plus particulirement, dune infrastructure pour les mtiers. Elle est compose dun Portail, dun systme BPM et BAM ainsi que dun cache MDM avanc (disponible sparment), mme si lditeur nenvisage pas de rivaliser directement avec les fournisseurs dinfrastructure IT. Lutilisation de ce MDM avec cache permet dutiliser un format pivot logique et normalis dinformations SAP et non-SAP reposant sur des rfrentiels physiques distribus de donnes. Au cur, SAP fait voluer, son serveur dintgration initialement baptis XI et servant relier des modules SAP en utilisant le protocole propritaire ALE1, pour en faire un bus Process Integration PI capable daccueillir une varit (surtout technique) de protocoles du march, donc en particulier des composants mtiers non SAP expo1. ALE tablit un dialogue entre modules SAP distribus et serveurs dEDI.
334
ss en services. On notera nanmoins que ce bus souffre encore du manque de certaines fonctionnalits cl, comme le mcanisme de publication / abonnement. Mme sil ne faut pas attendre la disparition de lABAP, cette volution majeure offre ainsi un premier niveau douverture, dautant quun rfrentiel de services baptis Enterprise Services Repository ESR permet galement une dfinition centralise et cohrente des processus mtiers, des services SAP ou non-SAP ainsi que des objets macroscopiques dinformations business objects accdant aux principales entits de donnes gres par SAP. Ce rfrentiel utilise une approche MDA pour gnrer galement le squelette des interfaces dimplmentations en ABAP Objet ou Java. noter que la modlisation visuelle de processus senvisage ce jour via des outils tiers en OEM, notamment Aris IDS Sheer, rebaptise ARIS for SAP Netweaver capable daccder ESR et fournir une dfinition externalise du procesus. De mme que la gestion didentit est propose via la solution Siemens par exemple, ou les connecteurs directs via iWay ou Seeburger B2B. SAP franchit aussi le pas de la modlisation visuelle dinterfaces homme machine composant des services dentreprise et fournit un atelier baptis Visual Composer, minimisant le recours lcriture de code pour la ralisation dapplications composites simples. Aprs les premires livraisons de lERP R/3 refondu sur Netweaver, SAP poursuit en mme temps la gnralisation de lusage du mta-langage XML et des normes WS-* (y compris au-dessus de ses langages de communications propritaires IDOC, RFC et BAPI). Il gnralise ce titre lutilisation de dfinition smantiques globales des structures dinformation SAP, stockes au sein de ESR, et partages par des Web Services baptiss Enterprise Services minimisant ainsi les transformations de formats ncessaires pour les consommateurs de plusieurs de ces services. Mme si la tendance gnrale est de fournir des implmentations natives ABAP et des compositions Java1, ce dcouplage permet galement de masquer la dualit des implmentations du fournisseur quelles soient ABAP et/ou Java. Dans le mme temps, SAP modernise aussi lenvironnement de conception des services Java via SAP Netweaver Composition Environment bas sur Eclipse. Enfin, ES Workplace permet de dcouvrir les solutions mtiers SAP bases sur ces Enterprise Services mais aussi de construire un assemblage spcifique. SAP prpare ainsi une bascule de son modle conomique en amorant une approche SaaS2 avec des annonces comme sa prochaine solution baptise BusinessByDesign (nom de code A1S) destine aux entreprises de taille moyennes.
Oracle (PeopleSoft/Siebel)
Outre Oracle Applications, les rachats successifs de grands progiciels tel que PeopleSoft puis Siebel engage actuellement Oracle dans un vaste chantier stratgique dintgration et de r-implmentation progressive de lensemble des primtres fonctionnels de ce patrimoine logiciel tendu. Encore plutt reconnu pour son SGBDR,
1. vitant ainsi la base installes des clients historiques SAP de trop gros efforts de migrations purement techniques. 2. SaaS Software As A Service.
335
cette vision baptise Fusion prennise dsormais doublement le positionnement de lditeur sur SOA. En effet, il doit la fois investir massivement dans linfrastructure dune plate-forme SOA complte ( Fusion middleware ) du fait de la diversit des offres intgrer, mais doit dans le mme temps, dmontrer les nouveaux bnfices dagilit mtier qui rsulte dune capacit de construction flexible et productive de multiples solutions mtiers modulaires ( Fusion Applications ). Ces solutions sont ainsi construites sur une nouvelle architecture baptise AIA fournissant des modles mtiers pivots servant de rfrence par mtier via des schmas XSD publics et ouverts et des processus mtiers BPEL pr cbls. Lditeur envisage dadresser galement de manire pr-package dans AIA, une vingtaine de secteurs dentreprise sur plusieurs annes. Les premires apparaissant actuellement dans le monde des tlcommunications et de la gestion de la relation clients. A noter aussi que AIA restera ouvert aux intgrateurs, partenaires et diteurs de logiciels tiers afin denvisager par co-dveloppement dautres compositions (modles et processus) de ces applications modulaires sur des systmes externes selon des directives et un programme formalis par Oracle. Lambition affiche est forte. Il sagit, non seulement, de rassembler ses offres de gestion ERP (Finances, CRM, RH) mais aussi de les dployer sur la base dune infrastructure dj reconnus sur le march, notamment avec : lindpendance du socle serveur applicatif JEE, mme si des facilits dadministration sajoutent en cas dusage du serveur applicatif Oracle AS; la gnralisation de luage de Coherence un cache java distribu issu du rachat Tangosol offrant des capacits de traitements massivement parallles et dallocation dynamique de ressources (cf. Grid 10g et Fusion Mesh 11g) pour plusieurs modules de lditeurs (orchestrateur, workflow, moteurs de rgles, ESB, etc) et galement disponible sparemment pour des solutions dvelopper en spcifique, par exemple dans les domaines forte contraintes de performances comme la finance, les tlcommunicatons, les jeux, etc. BPEL Process Manager , un moteur dorchestration de processus trs complet (issu du rachat du spcialiste Collaxa) est capable de prendre en compte les processus longs et les processus humains. Il permet un maintien en cohrence de la dfinition des processus durant les allers-retours de la conception mtier et technique via BPA Suite et lenvrionement jDevelopper. BPA Suite embarque en OEM plusieurs modules Aris1 de IDS Sheer, une solution de BPA2 leader du march. Cet environement propose ainsi un serveur rfrentiel des artefacts de conception, la possibilit de dfinir des indicateurs mtiers3 via la mise en place de sondes pour la solution BAM, puis de remonter les mesures collectes vers la simulation.
1. Notament pour la modlisation de processus mtiers en reprsentation EPC ou BPMN, la modlisation darchitecture, la simulation de processus et la publication de modles. 2. BPA Business Performance Analysis ou outils de modlisation et simulation. 3. KPI Key Performance Indicator.
336
Enfin, Oracle ESB , qui est un bus de services incluant une compression binaire des changes SOAP avec Oracle BPM Lditeur prvoit dej le support de SCA et SDO. noter galement une harmonisation progressive des consoles dadministration au sein de Oracle Enterprise Manager ainsi que des amliorations ergonomiques du fait de lusage de composants graphiques de haut niveau (jsf), un suivi mtier et technique de chaque instance de processus et la prise en compte progressive dadministration de contrats tendus jusquau SLA. Oracle dispose aussi dune offre complte de gestion didentit (issue des rachats dOblix, Thor, et Octet-String. Cette infrastructure se retrouve donc dj capable de rivaliser avec les spcialistes, mme si les Fusion Applications ne peuvent encore en tirer les pleins bnfices. Sans surprise, la firme de Larry Ellison possde dsormais plusieurs types de MDM orients client (notamment issu du rachat SIEBEL UCM ), mais aussi orients produits et finance, qui pourraient faire lobjet dune prochaine globalisation dinfrastructure de donnes distribues dynamiques. Lditeur nest pas en reste, sur lapproche ROA1 dans le cadre de la prsentation de services dinformations grce dune part son framework ADF permettant de construire rapidement des mises en correspondances de composants graphiques de haut niveau (jsf) et de multiples sources dinformations de type Web Services ou bases de donnes. Sur cette base, Oracle ajoute dj une nouvelle plate-forme baptise WebCenter mixant une approche Web2 et portail collaboratif pour assembler et consommer des services ROA et reconstruire ainsi efficacement de multiples espaces Web dchanges sur des informations ou services distribus en interne, sur Internet ou chez des tiers runis selon des techniques simples et dsormais prouves de marquage (tags) et flux RSS. Oracle sattaque galement au march de la gestion de contenus dentreprise avec la refonte de ses anciennes offres ( iFS et Files ) et le rachat du portefeuille logiciel Stellent pour viser lunification des contenus accessibles par services et Web Services. Cette nouvelle suite de produits Oracle Content Management Solutions servira dsormais de socle pr-intgr de persistance des contenus pour la plateforme WebCenter du mme diteur (cf. plus haut) en proposant des interfaces orientes services daccs au contenus via la norme JCR.
337
soit une approche de construction dun modle unifi encapsulant tout contenu et exposant des nouveaux services dinformations (cf. Vignette, BEA, IBM FileNet, EMC Documentum, etc.). La granularit des interfaces et leur valeur ajoute mtier peuvent varier : soit par la fourniture de services techniques de type CRUD XML (SOAP RPC/DOC), Java ou .NET (c.f. Day, Alfresco, etc.); soit par lajout de services administratifs grce lutilisation dun moteur dintgration des contenus, ou dapprovisionnement de sources de contenus rparties (cf. BEA, Interwoven, Oracle, Vignette, etc.) dans loptique dun rfrentiel virtuel ou consolid; soit par des services organisationnels transverses de scurit (droits daccs front ou back-office), ou de conformit des normes de qualits, de lgislations, etc. (cf. Documentum, OpenText, etc.). Il est possible denvisager que certains CMS produisent directement des rendus de contenus composables laide de langages comme XUL ou XAML. Ainsi SOA apporte des rponses pour proposer un modle darchitecture de mise en uvre des concepts ECM1 pour : faciliter laccs homogne vers des rfrentiels htrognes (par cloisonnement des implmentations) = Approche Library de lECM; apporter une flexibilit (re)assembler plusieurs sources/fonctionnalits existantes en crant plus de valeur (ex : recherche unifie) = Approche Bestof-breed de lECM; fournir un suivi extensible de la performance des sources et processus de contenus intgrs = Approche Factory de lECM.
22.1.4
Apache
La communaut Apache fournit depuis plus de trois ans une implmentation open source de rfrence pour linvocation de Web services baptise Axis . Si Axis na pas encore atteint le niveau dunification des transports disponibles dans les ESB commerciaux, la nouvelle version Axis 2, incorpore un support tendu de WS-* (WSDL2, asynchronisme, support multi-transports dont JMS, gnration multi-proxy C ou Java, multi-bindings dont XMLBeans, JAX-WS et WSIT2, WS-Policy etc.). La commu1. Cf. les travaux de AIIM (Association for Information and Image Management) pour linteroprabilit entre solutions ECM, baptis iECM . 2. WSIT (Web Services Interoperability Technologies) permet linteroprabilit des Web Services entre Java et WCF (le conteneur de services Microsoft intgr .NET 3.x).
338
naut galement repris Xfire (anciennement CodeHaus) et Celtix (anciennement Iona/ObjectWeb), dsormais rebaptis CXF , pour automatiser le dveloppement de services en Java la fois sur WS-* et REST et fournir un serveur de Web Services allg voire XML maison . ServiceMix , ce jour toujours en phase dincubation auprs de Apache, souhaite adopter la philosophie dESB modulaire (via JBI, configuration Spring et serveur JMS ActiveMQ embarqu) tout en supportant plusieurs conteneurs de Web Services (dont Axis, CXF, JAX-WS,). Son stade de maturit nest ce jour pas encore atteint. On peut aussi y adjoindre : ODE (Orchestration Director Engine) orchestrateur de processus pouvant la fois supporter le standard WS-BPEL 2.0 et les versions BPEL 1.x. Il est issu de Fivesight/PXE (repris aussi par Intalio). Ce projet a rcemment termin son incubation Apache. Il supporte en outre le framework WSIF. Synapse (contribution de Sonic) ddi la mdiation de Web Services (notamment transformation, routage ainsi que mesure et traceabilit). Synapse ninclut pas de connecteurs ou adaptateurs de protocoles et suppose donc une focalisation Web Services (SOAP). Il peut en revanche se prsenter comme composant JBI. Tuscany incubation Apache des spcifications OSOA1 (i.e. SCA, SDO et DAS) dclines pour plusieurs technologies (notamment Java, C++ et PHP) et pour laquelle des plugins Eclipse de productivit apparaissent via le projet STP. Camel framework facilitant lunification de mdiations et transformations selon des patterns dintgration dentreprise types. Enfin noublions pas que Apache, dlivre aussi Geronimo , serveur applicatif Java complet et modulaire, certifi ce jour JEE 1.5, supportant plusieurs conteneurs Web (Tomcat ou Jetty), plusieurs conteneurs Jax-WS (Axis2 et CXF) et pouvant accueillir ServiceMix, ainsi que ActiveMQ (pour le support de JMS). Lensemble constitue ainsi une implmentation de rfrence, dsormais en concurrence avec dautres suites SOA Open Source comme RedHat/Jboss+jBossESB ou Sun/Glassfish+OpenESB ou encore ObjectWeb/JonAS+Petals.
ObjectWeb/OW2
Fond en 2002 par Bull, lInria et France Telecom, ObjectWeb dlivre aujourdhui des solutions open source reconnues comme Enhydra (serveur dapplication Java/ XML), JORAM (bus messages conforme JMS), JonAS (implmentation des spcifications JEE TM).
1. OSOA (Open Service Oriented Architecture) Collaboration est un groupe dindustriels regroups en vue de standardiser la dfinition de conteneurs de services composites multi-technologies pour les traitements ou les donnes.
339
Dans le cadre du consortium OW2, la communaut ainsi largie, a logiquement fortement mis sur JBI au travers de Petals initialise par EBM WebSourcing (SSLL Toulousaine) conjointement avec une entreprise Brsilienne, Fossil E-Commerce. Cet ESB a pour ambition de prendre en compte les problmatiques denvironnements dintgration hautement distribus (via JORAM) capables de traiter de plusieurs dizaines plusieurs centaines de containers de services, notamment dans un contexte de fournisseur dhbergement (Integration Service Provider). Cette infrastructure peut en outre bnficier du serveur de traitements parallles (Grid) baptis ProActive disponible auprs de la mme communaut. LESB Petals fournit, ce jour, plusieurs Binding Components (notamment pour les protocoles techniques FTP, JMS, Soap, Mail, etc.) ainsi que plusieurs Service Engines (CSV, Pojo, RMI, XSLT) mais reste nanmoins dans une approche trs technique rserver aux intgrateurs spcialiss.
RedHat
ce jour, moins avanc que les deux communauts vues prcdemment, Jboss pourrait rattraper son retard par le choix de lacquisition de Rosetta et de son rachat par RedHat. Le support sur JEE 1.5 retard fin 2007, proposera ainsi un serveur applicatif tendu dot de fonctionnalit de messagerie synchrone ou asynchrone unifie par JMS mais nanmoins capable dexploiter : un moteur de transformation XSLT et Smooks (Java); son moteur de rgles ( Drools ) par programmation via assertions pour un routage dynamique bas sur le contenu; le moteur de transition dtats ( jBPM ) qui bnficie dj dun plugins de productivit dans Eclipse; un registre de service Jax-R et UDDI; un rfrentiel persistant des vnements. RedHat semble aussi se rapprocher de solutions comme ActiveBPEL (cf. plus loin) pour supporter une suite plus complte incluant lorchestration de processus.
340
JBoss MQ, Joram OpenJms). Sa configuration seffectue par fichiers XML sous forme de composants Java beans Spring. ActiveBPEL est un orchestrateur de processus disponible en dclinaison Java et .NET. Il inclut un modeleur galement en open source. Des extensions payantes permettent de disposer de fonctionnalits avances comme le support de WS-Security, des facilits dadministration, de suivi et de tolrance aux pannes. Plusieurs autres communauts dlivrent par ailleurs certaines briques du puzzle, notamment pour la chane de fabrication dcrite au chapitre 20. La fondation Eclipse fournissait dj WTP (WebTools Project) aujourdhui intgr Eclipse Europa qui propose loutillage ncessaire au dveloppement de services Web sur base Eclipse. Il permet en outre la cration de WSDL partir de code Java ou linverse et offre des outils daide ldition et la mise au point des descripteurs et des messages. BPELDesigner devrait apporter prochainement un diteur BPEL. Le projet STP (SOA Tools Platform) initialis par la fondation Eclipse, vise fournir les outils ncessaires la mise en uvre darchitectures orientes services en se conformant aux travaux SCA. Il rutilisera lditeur de fichiers WSDL fourni par WTP, mais ambitionne de couvrir lensemble du cycle de vie incluant la conception, la configuration, lassemblage, le dploiement et la supervision. Le projet ATF (Ajax Toolkit Framework) galement en incubation au sein de Eclipse, propose un framework extensible pour enrichir des environnements de dveloppements Web2 au dessus de diffrents moteurs dexcution Ajax (comme Dojo, Zimbra, Rico, Script.aculo.us, etc.). Il offre notamment des fonctionnalits dditions et mise au point (debug) de Javascript, feuilles de styles CSS, arbre DOM avec contrle des syntaxes respectives, etc. NetBeans est un environnement de dveloppement Java libre soutenu par SUN. Il concurrence directement Eclipse. Il propose en plus dun IDE Java complet, des perspectives de modlisation utiles pour une approche BPM/ SOA avec notamment un modeleur productif pour la construction de schmas XSD, ainsi que des facilits pour la modlisation de services, WSDL et de processus mtiers BPEL.
341
En rsum
Lunanimit des acteurs ne doit pas cacher ltendue du chemin restant parcourir pour la grande majorit des offres. Si le march est loin dtre aujourdhui parvenu une maturit, une tendance de spcialisation reste prvisible lchelle du march des solutions.
Annexes
GLOSSAIRE
DMZ A AJAX AOP APS Asynchronous JavaScript And XML Aspect Oriented Programming Application Platform Suite B BAM BI BPA BPM BRM Business Activity Monitoring Business Intelligence Business Performance Analysis Business Process Management Business Rule Management EJB ESB ETL EAI ECI EDA EDI EII EIMS DSL
DCOM Distributed Common Object Model E Enterprise Application Integration Enterprise Content Integration Event Driven Architecture change de Donnes Informatises Enterprise Information Integration Enterprise Information Management System Enterprise Java Beans Enterprise Service Bus Extract, Transform and reLoad F FTP File Transfer Protocol G GXA Global XML Architecture I IDE IECM IIOP Integrated Development Environment Interoperable Enterprise Content Management Internet Inter-ORB Protocol
BOXML Business Object eXtensible Markup Language BPEL BPMN Business Process Execution Language Business Process Modeling Notation C CDI CEP CICS CMMI CMS Customer Data Integration Complex Event Processing Customer Information Control System Capability Maturity Model Integrated Content Management System
CORBA Common Object Request Broker Architecture CRUD Create, Read, Update, Delete
344
Annexes
IMS ISP
Information Management System Integration Service Provider J SaaS SAM SCA SDO SI SLA SOA SOAP
S Software As A Service Service Activity Monitoring Service Component Architecture Service Data Object Systme dInformation Service Level Agreement Service Oriented Architecture Simple Object Access Protocol
Java Business Integration Java Extended Enterprise Java Management Extension Java Message Service M
Message Oriented Middleware Model Driven Architecture Master Data Management Message Queuing Multipurpose Internet Mail Extensions
S/MIME Secured Multipurpose Internet Mail Extensions SMTP SOBA STP Simple Mail Transfer Protocol Service Oriented Business Application SOA Tools Plateform U UDDI UML Universal Description and Discovery Interface Unified Modeling Language W W3C WMI WSDL WSRP World Wide Web Consortium Windows Management Instrumentation Web Service Description Language Web Services Remote Portlet X XHTML eXtensible Hypertext Markup Language XML XSLT eXtensible Markup Language eXtensible StyleSheet Language Transformation eXtensible Application Markup Language eXtensible User-interface Language
MTOM Message Transmission Optimization Mechanism O OASIS OCL OOP OMG Organization for the Advancement of Structured Information Object Constraints Language Object Oriented Programming Object Management Group P PDI POC POP POA PSM PIM Product Data Integration Proof of Concept Post Office Protocol Process Oriented Architecture Platform Specific Model Platform Independant Model R REST RMI ROA Representational State Transfer Remote Method Invocation Resource Oriented Architecture
XAML XUL
345
346
Annexes
<wdsl:operation name="recupererEtatDemande" pattern="http:// www.w3.org/2006/01/wsdl/in-out"> <wdsl:input xmlns:bo="http://www.portos.org/bo" element="bo:recupererEtatDemande"/> <wdsl:output xmlns:bo="http://www.portos.org/bo" element="bo:recupererEtatDemandeResponse"/> </wdsl:operation> </wdsl:interface> <wdsl:binding xmlns:wsoap="http://www.w3.org/2006/01/wsdl/soap" name="ServiceInterventionBinding" interface="si:ServiceInterventionPort" type="http://www.w3.org/2006/01/wsdl/soap" wsoap:version="1.1" wsoap:protocol=http://www.w3.org/2006/01/soap11/bindings/HTTP> <wdsl:operation ref="si:recupererEtatDemande" wsoap:soapAction="urn:#recupererEtatDemande"/> </wdsl:binding> <wdsl:service name="ServiceIntervention" interface="si:ServiceInterventionPort"> <wdsl:endpoint name="ServiceInterventionPort" binding="si:ServiceInterventionBinding" address="http://services.portos.com/wsdl/ServiceIntervention"/> </wdsl:service> </wdsl:description>
Index
A
Adaptateurs de protocoles 286 Agent 60, 300 Agilit 6 Agrger 295 AJAX 254, 255, 258 Ajustement 315 Alerte 74, 299 Alfresco 337 Algorithme 23 Aligner 6 AmberPoint 329 Annuaire 70, 72, 190, 284, 292 Apache 321, 337 Application composite 39 interactive 131 Approche Objet 46 par le code 228 par les modles 228 APS (Application Platform Suite) 283, 285 Aqualogic 328 Architecture client / serveur 4 de rfrence 27, 39 n-Tiers 4 Asynchrone 22, 277 Atelier 300, 302 dhomologation 303 de conception 315 de fabrication 316 de modlisation 298 de paramtrage 77 ATOM 276 Authentification 22, 313
BEA 320, 328 BI 315 Bibliothque 258 Biztalk Server 325 Bouchon 301 BOXML 302 BPEL 117, 166, 213 BPEL 1.1 214 BPEL 2.0 215 BPEL4People 215 BPEL4WS 213 BPELJ 216 BPM 41, 298 BPMN 117, 214, 301 Bus 65 de communication 285 de messages 66 de service 69 ESB 230
C
Cache 296, 312 CAF 166 Call back 288 Capacit 53 Cartographie 10 Chane de fabrication 65, 76, 284, 294, 300, 309 Chiffrement 69 Chorgraphie 57 Classification 292 Client 29 CMM-I 169 Collaboration 56, 310 Composer 21 Composition 27, 35, 36, 37, 56, 57, 309 de services 111 Condition 59, 61 Confidentialit 23 Conformit avec WS-I 233
Connecteur 13, 16, 287, 309, 312 Connectivit 21 Console 60, 71, 297, 298, 300 Consommateur 49, 51 Container 218 de services 284 Contexte 37, 39, 41, 102, 103, 134, 310 transactionnel 40 Contractualisation 47, 53 Contrainte 61 Contrat 36, 38, 42, 49, 50, 51, 52, 55, 57, 61, 62, 66 de service 186, 243 WSDL 230 Convergence 48 Conversationnel 288 Coordinateur 41, 133, 144 Coordination 56, 57, 62, 308, 310 CORBA 310 Corbeille 126 Couplage 51 faible 62 lche 244 Cot 308 CRUD 258
D
DCOM 311 Dclenchement 22 Dcouverte 190 Dfinition dentits 74 Dlivrance 311 Dmarche 43, 45 Dpendance 292, 293 Dploiement 4, 37, 58, 69, 285, 290, 303 Directive 53, 61, 314 Disponibilit 23
B
B2B 312 BAM 74, 284, 309, 315
348
Index
Distributeur de requtes 73 Document 232 Documentum 337 DOM 256 Donnes matres 296 DSL 302
H
Htrognit 5 Historique 299 HTML 254, 256 HTTP 253, 266, 270 GET 269
E
EAI 13, 14, 47, 66 change 22 ECI 73 Eclipse 321 EDA 33 EDI 222, 312 diteur de Mashups 262 EII 73, 309 EII / MDM 294 EIMS 74 EMC-Documentum 320 Encoded 232 En-tte 67 Entits mtiers 47 Enveloppe 67 ESB 284 ETL 73 vnement mtier 33, 302 Exigence 53
I
IBM 320, 321 Indpendance 18 Indicateur 20, 58, 70, 71 Injection de dpendance 244 Instrumentation 300 Intgrit 23 Interface 21, 50 Intermdiation 37, 72 Interoprabilit 36, 37, 308 Interoprable 31 Interwoven 320, 336
MOM 310 Moniteur 70 transactionnel 24 Monitoring 26, 299, 300, 315 Moteur dexcution 298 de rgles 38, 77, 310 de transformation 287 MTOM 311 Multi-Canal 317 MVC 41, 132, 133, 259, 260
N
Netvibes 264 Netweaver 333 Niveaux de qualit 53 Normalisation 29 Note 306 Nouveaux outils 281, 319
J
JavaScript 253 JBI 291 JMS 310 JMX 60 JSON 253, 260, 276
O
OASIS 178 ObjectWeb 321 OCL 59 OpenText 320 Opration 50, 52, 56 Oracle 320 Orchestrateur 70 Orchestration 41, 56, 74, 213, 310 de services 116 Orient Aspect 59 Outils dadministration 284 de monitoring 284
L
Langages objets 17 Liberty Alliance 203 Litteral 232 Localisation 52, 285
F
Faade 96, 108 Fdration didentit 202 Fournisseur 29 Frameworks 17
M
Mainframe 3 Mashup 250, 251, 259, 262, 263 Maturit 304 MDA 59, 77, 166, 301 MDM 73, 295, 296, 309 Mercury 333 Message 50, 52, 66, 310 Messagerie 67, 286 Mesure 70 Mta-donnes 48, 61, 309, 313 Microsoft 320 Middleware 65 Migration 77 Mode dinteraction 287 Modle dinteraction 68 de maturit SOA 169 de processus 302 Modlisation 74, 300, 316
G
Garantie 44, 53, 55 dacheminement 23, 204 Gnrateur 302 de code 59 Gnration 300, 316 Gestion en configuration 300 GET 273 Google Maps 252 GPS 252 Granularit 36 Grille 305, 307 de calcul 71 Guide 61 GWT 261 GXA 178, 326
P
Paramtrage 76 Parseur 254 Passerelle 286 Patterns 59 Performance 71, 223, 290 Pilotage 74 Piloter 25 PIM 301 Planification 71 Plat de spaghettis 12 Plate-forme 65, 69 dintgration 21 SOA 319 POA 33 POJO, PlainOld Java Object 223
Index
349
Politique 195, 296 Pondration 306 PONO, Plain Old.NET Object 223 Portabilit 307 Portail 15, 16, 212, 284 Portlet 212 POST 268, 273 Pourvoyeur 30, 49, 51 POxO 223, 227, 243 Processus mtier 19, 41, 115, 152 Productivit 302 Programme SOA 149, 152 Projet Liberty 203 Protocole 52, 67, 224, 285, 308 Provisioning 199 PSM 302 Publication 73, 292, 313 Publication / abonnement 288 Publish and Suscribe 22
S
SAM 70, 284, 309 SAML 198 SAP 320, 333 SCA 58, 112, 169, 217, 284, 291, 302, 303, 316, 329 Scnarios dinjection 303 Scurit 22, 68, 196 Security Token Service 201 Serveur didentit 202 Services 30, 34 Applicatifs 96 CRUD 73, 93, 101, 104, 107, 135, 166, 294 dorganisation 125 de gestion des processus 126 de routage 124 du Mainframe 229 Fonctionnels 98 lgataires 109 mtier 92, 156 techniques 92 Seuil 299 SI local 223 Signature 52 Silo 12, 14, 15, 44, 47 Simulateur 302 SLA 54, 56, 61, 73, 313 SOAP 272, 273, 310 Socle 308 Solution mtier 81, 152, 154 Souplesse 6 SPE 215 Spcification 178 SPML 199 SPRING 218 Spring 58, 244 SSL 196 Standardisation 32 Statistique 74, 299 STP 340 Stratgie 43 Structuration 295 STRUTS 259 Style Document / Literal 234 Wrapped 236, 237 RPC 233 WSDL 237 Suivi 60, 62, 70, 309, 314 Sun 320 Superviser 207 Supervision 70 Synchrone 22, 46, 288
T
Taxonomie 62 Technologie 46 Temps rel 20 Test 301, 303 Tibco 320 Topologie 290, 293, 309 Traabilit 23, 295 Trace 300 Traduction 25 Transaction distribue 24, 206 longue 40, 140 Transformation 286, 288, 309, 311 Transport 67, 310 des messages 291 Typologie des services 222, 241
U
UDDI 190, 275, 313 UML 59, 301, 315 Urbanisation 9, 30, 44 Urbanisme 10 URI 266 URL 267 UWA 264
Q
Qualit 44, 53 de service 32, 62, 70, 230 des donnes 295, 313
R
Rapports danalyse 299 RDA 261 RDF 275 RedHat 321 Rfrentiel 10, 24, 37, 66, 77, 285, 292, 293, 296, 297, 313 Registre 66, 70, 72, 292, 313 dentreprise 191 fdr 191 public 191 Rgle 59, 73, 300, 316 Rplication 295 Rpliquer 296 Reporting 26 Requte CRUD 312 Requteur 70, 312 REST 185, 250, 265, 266, 267, 272, 278, 279 Rutilisabilit 20 Rutilisation 37, 61, 62 RIA 261 RMI 310 Routage 286, 309, 311 RPC 232
V
Variante 48, 57, 58, 61, 62, 293, 300 dcrite 38 Version 48, 61, 293 Vignette 337 Vision client 44 Vue 42 de donnes 296 des Services 30 logique 309, 312
W
W3C 178 Web 1.0 247 Web 2.0 185, 247 Web smantique 274 Web Service 265 Web Services 27, 46 WebMethods 320 Widget 264 WMI 60 Workflow 14, 15, 41, 56, 310 WRDL 271, 278 WS-* 266, 279
350
Index
WS-agreement 189 WS-AtomicTransaction 206 WS-Authorization 201 WS-BusinessActivity 207 WS-CAF 140, 216 WS-CF 216 WS-Coordination 206 WS-CTX 216 WSDL 186, 224, 227, 271 WSDL 2.0 237 WS-DM 207 WS-Enumeration 277 WS-Federation 203 WS-I 231 WS-I Basic Profile 231 WSIF 245 WS-Manageability 207
WS-Management 208 WS-Management Catalog 208 WSMO 189 WS-Policy 192, 195, 200 Attachment 196 WS-Privacy 201 WS-Reliability 204 WS-ReliableMessaging 205 WS-RM Policy 205 WSRP 43, 212, 316 WSS 197 WS-SecureConversation 201 WS-Security 198 WS-SecurityPolicy 200, 203 WS-Transfer 274, 277 WS-Trust 200, 203 WS-TXM 216
X
XACML 199, 201 XAML 145, 302, 315 XFORMS 145, 169, 302 XML Encryption 197 Signature 197 XMLHttpRequest 255, 256 XML-RPC 182 XSD 271 XSLT 311 XUL 145, 169, 302, 315
Y
Yahoo Pipes 263
INFOPRO
Xavier Fournier-Morel, Pascal Grojean Guillaume Plouin, Cyril Rognon Prface de Luc Fayard
MANAGEMENT DES SYSTMES D'INFORMATION APPLICATIONS MTIERS TUDES, DVELOPPEMENT, INTGRATION EXPLOITATION ET ADMINISTRATION
SOA
Le guide de larchitecte du SI
Cet ouvrage sadresse aux responsables des systmes dinformation, aux matrises douvrage et matrises duvre, aux quipes dexploitation. Les architectures orientes services (SOA) offrent un nouveau modle qui permet de construire des systmes informatiques volutifs et rapidement adaptables. Cet ouvrage en prsente les concepts et les usages de manire dtaille. Il se propose de guider le lecteur dans la mise en uvre dune architecture SOA en dcrivant une mthodologie et en prsentant les outils indispensables leur concrtisation. La premire partie dresse le cahier des charges dun SI idal, moderne et agile . La deuxime explique en dtail lapproche SOA. La troisime traite dabord de la modlisation des services et des processus mtier, puis de limpact de SOA sur la gestion de projet. La quatrime montre comment les standards et outils associs aux Web Services sinscrivent dans une dmarche SOA. La cinquime dtaille certains aspects techniques dun cas rel. La sixime positionne SOA vis--vis de Web 2.0. La dernire partie dresse un panorama de loffre du march.
2 e dition
Les auteurs font partie de SQLI Consulting, dpartement conseil du groupe SQLI, spcialiste depuis 15 ans du conseil et de lintgration des nouvelles technologies. PASCAL GROJEAN anime SQLI Consulting, et CYRIL ROGNON en est le directeur Capitalisation et R&D . GUILLAUME PLOUIN est responsable de la veille technologique du groupe SQLI. XAVIER FOURNIER-MOREL est responsable du ple architecture de SQLI Suisse. Leur exprience les a particulirement sensibiliss aux problmatiques durbanisation, de construction et de maintenance de systmes complexes.
ISBN 978-2-10-053549-1
www.dunod.com