Soa PDF

SYSTMES D'INFORMATION
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
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
Dunod, Paris, 2006, 2008

ISBN 978-2-10-053549-1
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.
Quatrime partie La boite outils Web Services

On a prcis dans cet avant propos quil ne faut pas faire damalgame entre SOA et Web Services. Cependant, la conception des spcifications Web Services a t mene dans lobjectif de rpondre au mieux aux enjeux des architectures SOA. Ainsi, les Web Services sont une technologie trs pertinente pour mener une dmarche SOA. Lobjectif de cette partie est de prsenter les diffrentes spcifications qui pourront tre mises en uvre dans le cadre dune architecture SOA base sur les Web Services : spcifications de base des Web Services (SOAP, WSDL, UDDI), spcifications permettant de grer la scurit, la garantie dacheminement, la garantie transactionnelle, le monitoring des services, les aspects composition, orchestration et prsentation.
Cette partie prsente des normes techniques : elle intressera les architectes, chefs de projets et dveloppeurs.
Cinquime partie SOA : une mise en uvre concrte

Une mise en uvre russie dune SOA et de services doit faire correspondre les enjeux mtiers, les contraintes et avantages techniques, au sein du SI local ou entre SI. La partie 5 de ce livre sadresse aux architectes techniques et veut dmystifier une utilisation pragmatique et pertinente des technologies pour bnficier de SOA. Si ce type de solutions est ralisable avec ou sans les Web Services, il est trs important de bnficier des formalismes comme WSDL qui vont structurer la dmarche de production de services, en sappuyant sur des normes comme WSI-Basic Profile. Cette partie dtaille certains aspects techniques permettant dutiliser plus finement et en connaissance de cause les assistants et ateliers logiciels qui fournissent ou accompagnent la production de Web Services. Enfin, on y prsente des solutions permettant daccder diffrentes implmentations dun mme service. Cest lannonce des solutions ESB et SCA, o la conception sabstrait encore plus des contraintes et des volutions techniques.
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.
Table des matires
Prface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Avant-propos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
III V
Premire partie Le cahier des charges des SI agiles

Chapitre 1 De lentropie des Systmes dInformation . . . . . . . . . . . . 1.1 Une brve histoire de linformatique . . . . . . . . . . . . . . . . . . . . 1.1.1 Le mainframe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.2 Les applications client/serveur . . . . . . . . . . . . . . . . . . . . . 1.1.3 Les applications Web . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.4 Un premier bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Lacclration des marchs et ses consquences sur le SI . . . . . . . . . 1.2.1 Le besoin dagilit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2 Lintgration des acteurs externes . . . . . . . . . . . . . . . . . . . . Chapitre 2 Les limites des rponses usuelles . . . . . . . . . . . . . . . . . 2.1 La dmarche durbanisation . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Introduction la mtaphore de la cit . . . . . . . . . . . . . . . . . . 2.1.2 Le modle de rfrence de lurbanisme . . . . . . . . . . . . . . . . . 2.1.3 La ralit du SI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 3 4 4 4 6 6 6 9 9 9 10 12
Table des matires
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Seconde partie Expliquer les concepts SOA

Chapitre 4 Urbanisation et architecture SOA . . . . . . . . . . . . . . . . . 4.1 SOA concrtise le modle durbanisation . . . . . . . . . . . . . . . . . . 4.1.1 Lmergence de pourvoyeurs de services ? . . . . . . . . . . . . . . 4.1.2 EDA, POA, SOA Querelle de chapelles ou vrai dbat ? . . . . . . . 4.2 Au cur de SOA : le concept de service . . . . . . . . . . . . . . . . . . 4.2.1 Identifier les services SOA . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2 Construire de nouveaux services . . . . . . . . . . . . . . . . . . . . . 4.2.3 Grer le cycle de vie des services . . . . . . . . . . . . . . . . . . . . . 4.3 Architecture de rfrence SOA . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Le concept dapplication composite . . . . . . . . . . . . . . . . . . . . 4.3.2 Typologie des applications composites . . . . . . . . . . . . . . . . . . 4.3.3 Topologie des applications composites . . . . . . . . . . . . . . . . . . 4.4 Pour une dmarche SOA gradue . . . . . . . . . . . . . . . . . . . . . . 4.4.1 Pourquoi dbuter une dmarche SOA ? . . . . . . . . . . . . . . . . . 4.4.2 Comment dbuter ? . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.3 Quelles consquences sur le SI ? . . . . . . . . . . . . . . . . . . . . . 29 30 30 33 34 34 35 37 38 38 41 42 43 43 44 44
Table des matires
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.2 Du bus de messages la plate-forme SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (BPM et . . . . . . . . . . . . BAM)
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
Table des matires
Troisime partie SOA : tout repose sur la mthode

Chapitre 7 Dfinir la cible . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1 Application ou solution mtier ? . . . . . . . . . . . . . . . . . . . . . . . 7.1.1 7.1.2 7.1.3 7.1.4 Le point de dpart . . . . . . . . . . . . . . . . Que devient alors la notion dapplication ? . . . . Le concept de solution mtier . . . . . . . . . . La caractristique principale dune solution mtier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 81 81 82 82 83 84 84 84 85 86 87 87 91 91 91 92 93
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
Table des matires
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
Table des matires
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
Quatrime partie La bote outils Web Services

La pile WEB services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 Chapitre 12 Linfrastructure de base . . . . . . . . . . . . . . . . . . . . . . 181 12.1 Implmenter les communications serveur serveur avec SOAP . . . . . . 182 12.1.1 12.1.2 12.1.3 12.1.4 12.1.5 XML-RPC, anctre de SOAP . . . . . . . . . . . . . . . . Les principes de SOAP . . . . . . . . . . . . . . . . . . . Fonctionnement de SOAP . . . . . . . . . . . . . . . . . . Les limites de SOAP . . . . . . . . . . . . . . . . . . . . REST : un concurrent de SOAP pour une intgration lgre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 183 183 184 185
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
Table des matires
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
Cinquime partie SOA : Une mise en uvre concrte

Chapitre 15 SI tendu ou SI local ? . . . . . . . . . . . . . . . . . . . . . . 15.1 La porte des services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.2 Les contraintes de lentreprise tendue . . . . . . . . . . . . . . . . . . . 15.2.1 Un terrain favorable aux Web Services . . . . . . . . . . . . . . . . . 15.2.2 Peut-on opposer lEDI aux WebServices ? . . . . . . . . . . . . . . . 15.3 Lenjeu technique du SI local . . . . . . . . . . . . . . . . . . . . . . . . 15.4 Une approche technique diffrencie . . . . . . . . . . . . . . . . . . . . Chapitre 16 Les atouts de WSDL . . . . . . . . . . . . . . . . . . . . . . . 16.1 Utiliser WSDL comme formalisme pivot . . . . . . . . . . . . . . . . . . 16.1.1 16.1.2 16.1.3 16.1.4 Un socle formel qui dpasse les WebServices . . . Faut-il devenir un gourou du WSDL ? . . . . . . Quelle est la dmarche de production des WSDL ? WSDL rsout-il tous les problmes ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 221 222 222 222 223 224 227 227 227 228 228 230
XVI
Table des matires
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
Sixime partie SOA et Web 2.0

Chapitre 18 Architectures Web 2.0 . . . . . . . . . . . . . . . . . . . . . . 249 18.1 SOA et Web 2.0 : deux approches diffrentes ? . . . . . . . . . . . . . . . 249 18.2 Les mashups : principes, avantages, problmes . . . . . . . . . . . . . . . 251 18.2.1 Un exemple reprsentatif . . . . . . . . . . . . . . . . . . . . . . . . 251 18.2.2 Mashup et SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 18.3 AJAX : principes, avantages & inconvnients . . . . . . . . . . . . . . . 254 18.3.1 Le principe de fonctionnement AJAX . . . . . . . . . . . . . . . . . . 255 18.3.2 AJAX & SOA : les limites . . . . . . . . . . . . . . . . . . . . . . . 258 18.3.3 AJAX & SOA : lments de solution . . . . . . . . . . . . . . . . . . 259 18.4 Construire et intgrer les mashups . . . . . . . . . . . . . . . . . . . . . . 262 18.4.1 Construire les Mashups . . . . . . . . . . . . . . . . . . . . . . . . . 262 18.4.2 Intgrer les Mashups . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 Chapitre 19 REST et Web Services . . . . . . . . . . . . . . . . . . . . . . 265 19.1 REST : les principes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 19.2 Comparaison avec lapproche SOAP . . . . . . . . . . . . . . . . . . . . 273 19.2.1 Constat technique : REST remplit son contrat . . . . . . . . . . . . . . 273 19.2.2 REST est une solution de bon got pour le Web . . . . . . . . . . 274
Table des matires
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 ? . . . . . . . . . . . . . . . . .
275 276 277 279
Septime partie Dcrypter loffre du march

Chapitre 20 Caractristiques de la plate-forme SOA . . . . . . . . . . . . 20.1 Linfrastructure ncessaire pour SOA . . . . . . . . . . . . . . . . . . . . 20.1.1 20.1.2 20.1.3 20.1.4 20.1.5 20.2.1 20.2.2 20.2.3 20.2.4 Le Bus dEntreprise, ou ESB . . . . . . . . . . Le registre des services . . . . . . . . . . . . . Laccs aux rfrentiels de donnes (EII/MDM) Le moteur BPM . . . . . . . . . . . . . . . . Les consoles de suivi SOA . . . . . . . . . . . Latelier de modlisation . . . . . . . Latelier de fabrication . . . . . . . . Latelier dassemblage et de dploiement Latelier dhomologation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 284 285 292 294 298 299 300 301 302 303 303 305 305 307 307 308 319 319 321 328 333 337 340 343 343 345 347
20.2 La chane logicielle SOA . . . . . . . . . . . . . . . . . . . . . . . . . .
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
Le cahier des charges des SI agiles

Lobjectif de cette premire partie est dintroduire les problmatiques de rationalisation et dagilit des Systmes dInformation, puis de prsenter le cahier des charges dun SI en phase avec les attentes actuelles. Ce dernier est envisag sous un angle mtier, puis sous un angle technique. Le premier chapitre prsente lvolution de linformatique et les problmatiques dentropie des SI; il montre que lacclration globale du monde actuel risque daccrotre fortement ces problmes si rien nest fait. Le deuxime chapitre montre que, jusqu prsent, loutillage (architectures, mthodes, techniques) mis disposition des DSI rsout mal ou partiellement les problmatiques de rationalisation du SI. Le troisime chapitre prsente les exigences mtier et techniques que lon peut attendre dune nouvelle dmarche dorganisation et dintgration du SI. Les parties suivantes montreront comment SOA rpond ces diffrentes exigences.
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.
1.1 UNE BRVE HISTOIRE DE LINFORMATIQUE

1.1.1 Le mainframe
Dans lhistoire de linformatique, on a tout dabord conu des applications monolithiques, les sites centraux, o toute la logique de persistance, de traitement, et de prsentation tait agrge dans un ensemble indissociable. Toute linformatique des entreprises tait alors concentre dans un serveur unique : le mainframe. Le mainframe supporte en gnral des applications de gestion essentielles pour lentreprise. Sa principale contrainte technique est dassurer la haute disponibilit et lintgrit des donnes. Ses cots dacquisition et dexploitation sont levs, mais il offre lentreprise un systme totalement cohrent et fiable.
1. De lentropie des Systmes dInformation
1.1.2 Les applications client/serveur

Avec linvention du PC, sont apparues des applications plus lgres, en architecture client/serveur. Ces architectures ont propos de dporter les composants dinterface sur les postes de travail en conservant des serveurs pour la persistance. Elles ont ainsi apport plus de graphisme et plus de sophistication en terme dergonomie. Le faible cot de ces nouvelles applications a permis leur multiplication dans les entreprises. Ces dernires se sont alors dotes de logiciels transverses de messagerie, de gestion financire, daide la dcision, etc. De plus, linformatique a commenc tre utilise par les mtiers et progressivement par tous les profils de lentreprise. Ainsi, les Systmes dInformation ont grandi rapidement, la suite dinitiatives parses des diffrents dpartements et mtiers de lentreprise. Labsence de gouvernance de cette croissance a souvent abouti des duplications dinformations, saisies et gres de manire autonome par ces diffrents services. Par ailleurs, lenthousiasme autour des applications client/serveur a engorg les postes de travail de multiples excutables difficiles maintenir et dots dinterfaces incohrentes. Cette multiplication des interfaces sest rvle complexe matriser et donc improductive pour lutilisateur.
1.1.3 Les applications Web

la fin des annes 1990, les problmatiques de dploiement et de gestion des parcs de PC ont montr les limites des applications client/serveur. De plus, un nouveau besoin sest fait sentir : celui de proposer laccs aux applications non plus seulement aux employs de lentreprise, mais aussi ses clients et partenaires. Ds lors sont apparues les applications Web, auxquelles on accdait laide dun simple navigateur. Elles ont permis dintgrer les clients et partenaires aux processus mtiers de lentreprise et de dvelopper le commerce lectronique. De plus, elles ont amen une rduction des cots de gestion et de licence du parc informatique. La monte en puissance de la programmation oriente objet a accompagn le dveloppement des applications Web avec tous les bnfices quon connat : usage de composants et frameworks, rutilisabilit, modlisation UML, etc. Cependant, les architectures n-Tiers, associes ces technologies, ont augment le morcellement du SI.
1.1.4 Un premier bilan

Chacune des technologies cites dans les paragraphes prcdents a eu sa pertinence un moment donn dans lhistoire de linformatique. De plus, chacune a ses avantages et ses inconvnients.
1.1 Une brve histoire de linformatique
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
Problmatiques Absence de communication, redondance dinformations, htrognit technologique, cots de maintenance
Figure 1.1 Lentropie du SI
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.
1. De lentropie des Systmes dInformation
1.2 LACCLRATION DES MARCHS ET SES CONSQUENCES SUR LE SI

1.2.1 Le besoin dagilit
Chacun sait aujourdhui que la mondialisation des changes a rendu la concurrence plus pre entre les entreprises de tous types. Pour rester comptitives, ces dernires doivent ainsi tre capables de livrer de nouveaux produits de plus en plus vite, en rduisant au maximum les cots de production. Le systme dinformation est impact par cette acclration; dans le cadre de processus de plus en plus informatiss, il est au cur de ces nouvelles exigences de productivit. Les mtiers lui demandent dtre extrmement ractif, pour aider mettre sur le march de nouvelles offres. On parle pour cela dagilit : ce terme dsigne la capacit du SI supporter des volutions rapides. Un corollaire de lacclration des marchs est limportance des fusions/acquisitions qui permettent aux entreprises dasseoir leur position et dlargir leur offre. Cette tendance a aussi des consquences sur le SI. Il doit en effet tre capable dabsorber rapidement dautres systmes informatiques, souvent htrognes sur le plan technologique. On voit l un autre aspect de lagilit, rclame cette fois par la direction de lentreprise. Enfin, lentreprise peut tre amene dvelopper une offre sur la base dune nouvelle technologie. Par exemple, un oprateur tlcom va proposer une nouvelle offre haut dbit en sappuyant sur la technologie WiMax. Dans ce cadre encore, on exigera du SI quil sadapte rapidement aux impacts de cette nouvelle technologie pour supporter la nouvelle offre. Cest encore un exemple dagilit. En rsum, on dit gnralement que les besoins mtiers et stratgiques de lentreprise dessinent une cible atteindre pour le SI. Pour bien servir son entreprise, on dit que ce dernier doit saligner avec les besoins exprims et suivre une trajectoire cohrente avec la cible.
1.2.2 Lintgration des acteurs externes

Les produits de consommation sont de plus en plus construits sur mesure selon les dsidratas des clients. Ainsi, on voit apparatre dans diverses industries des configurateurs qui permettent au client de faonner son produit : par exemple, les configurateurs automobiles permettent aux internautes de choisir, partir dun vaste catalogue, la cylindre, la couleur, les accessoires de leur automobile. Les constructeurs de matriel informatique offrent le mme genre de souplesse. On a vu prcdemment que les applications Web avaient permis la naissance du commerce lectronique en offrant aux consommateurs une interface vers le SI, afin de mener des actes dachat. Avec les configurateurs, on va plus loin puisque le consommateur intervient dans la phase de conception de son article. Il devient donc architecte de son produit.
1.2 Lacclration des marchs et ses consquences sur le SI
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.
2.1 LA DMARCHE DURBANISATION1

2.1.1 Introduction la mtaphore de la cit
La premire rponse historique la rationalisation du SI est la dmarche dite durbanisation. Cette dmarche propose de comparer le SI une ville comprenant des zones, des quartiers et des lots2, puis dappliquer une mthodologie proche celle de lurbanisation traditionnelle pour grer son organisation. Lurbanisation traditionnelle porte sur la rationalisation des rseaux de circulation, dgouts, dlectricit, de gaz, etc.; tandis que lurbanisation des SI travaille
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
2. Les limites des rponses usuelles
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.
2.1.2 Le modle de rfrence de lurbanisme

De mme que leurs homologues travaillant sur la cit physique, les urbanistes de SI utilisent des cartes et des plans diffrents niveaux de lecture. Dans la cit physique, on parle de plan doccupation des sols, de plan du rseau des transports en commun, de plan des rseaux dgouts, etc. De mme, les cartographies du SI sont multiples et abordent diffrents niveaux de technicit. Les urbanistes de SI utilisent gnralement une convention de reprsentation avec 4 niveaux de cartographies que nous appellerons dans la suite le modle de rfrence de lurbanisme. Ces quatre niveaux, prsents dans la figure 2.1, sont les suivants : La vue mtier : elle recense les vnements mtier que lentreprise doit traiter, les processus mtier rpondants ces vnements, les documents utiliss dans les processus, et les acteurs excutant les processus en consultant/laborant les documents. Lexpression Processus Mtier dsigne ici les procdures en vigueur dans lentreprise pour traiter un vnement mtier : ce niveau, on ne se soucie pas encore dautomatiser ces processus via un outil. La vue fonctionnelle : elle dcrit les fonctions du Systme dInformation, telles quon les dcrit dans un cahier des charges en vue de la mise en uvre dune nouvelle application. Les fonctions peuvent tre par exemple : la gestion dun contrat client, la gestion dune expdition de produit, la messagerie lectronique, les agendas partags, etc. Cest au niveau de la vue fonctionnelle que les urbanistes parlent de zones et de quartiers, afin de regrouper les fonctions connexes. La vue applicative : elle recense lensemble des applications informatiques utilises par les acteurs pour remplir des fonctions et outiller des processus. La vue physique : elle recense lensemble des composants dinfrastructure (matriels, infrastructure rseau, outillage de scurit, archivage, outillage dadministration et de monitoring, etc.) qui supportent le SI.
2.1 La dmarche durbanisation
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
Applicatif Logiciels et donnes
Technique
Physique Infrastructure matrielle
Figure 2.1 Le modle de rfrence de lurbanisme
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).
Figure 2.2 La problmatique des silos applicatifs
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 .
2.2 Un outillage au service des urbanistes
13
2.2 UN OUTILLAGE AU SERVICE DES URBANISTES

Ce paragraphe dcrit un certain nombre doutils, conus dans un objectif durbanisation : il prsente leur mode de fonctionnement et leurs limites.
2.2.1 Les outils EAI

Les outils EAI (Enterprise Application Integration) sont des solutions ddies la gestion des changes dinformations entre applications htrognes sur le plan technique. Leur objectif premier est donc de rationaliser le plat de spaghetti voqu plus haut. Ils rpondent gnralement aux besoins suivants : Offrir une interface (un connecteur) vers toutes les typologies dapplications du SI. Acheminer les messages/donnes entre applications. Savoir mener des transformations intermdiaires des messages. Orchestrer les processus dintgration. La figure 2.3 prsente schmatiquement le fonctionnement dun outil dEAI.
ERP Connecteur
Mainframe Connecteur
HUB EAI Routage, transformation, processus dintgration
Connecteur
Connecteur
Connecteur
Connecteur
LDAP Application Web CRM
SGBD
Figure 2.3 Reprsentation schmatique dun outil EAI
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
Figure 2.4 LEAI favorise les silos
2.2.2 Les outils de workflow

Les outils de workflow ont t conus pour permettre dautomatiser rapidement un processus mtier partir de sa modlisation. Ils proposent donc une interface de modlisation, utilisable par des non-informaticiens et un moteur permettant lexcution du processus modlis. Ces outils ne couvrent pas tous les types de processus : il sagit gnralement de processus dit human-driven, car ils sont bass sur des sries de tches effectues par des utilisateurs finaux : demandes, validations, rejets, etc. (cf. partie 3).
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
Figure 2.5 Loutil de Workflow encourage les silos
2.2.3 Les portails Web

Les outils de portail ont t invents pour offrir un point dentre unique, sous la forme dune interface unifie et cohrente aux utilisateurs du SI. Leur objectif tait donc de mettre fin la prolifration de multiples excutables sur le poste utilisateur,
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
Figure 2.6 Fonctionnement des portails de premire gnration
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.
2.2.4 Les langages objets

Les langages objets ont offert des potentiels intressants de rutilisation. En effet, le concept dinterface permet de crer des composants invocables par dautres. Il est ainsi possible de composer des lments pour construire des applications de plus en plus complexes, ou bien de sappuyer sur des briques existantes pour personnaliser leurs fonctions. Ce procd est au cur des concepts de frameworks. Cependant, si les composants objets sont rutilisables au sein dun ensemble applicatif monolithique, ils le sont moins lchelle du SI. En effet, ils offrent une trop forte adhrence leurs technologies dimplmentation (Java, .NET, etc.) pour tre utilisable grande chelle. Ainsi les capacits de rutilisation des langages objets ne sont pas exploitables dans une dmarche durbanisation. Et lobjet, de mme que les outils voqus prcdemment, favorise les silos applicatifs.
18
2.2.5 Un constat de frustration

Les paragraphes prcdents ont montr que la dmarche durbanisation est louable et mme indispensable pour tout SI de taille consquente. Cependant, les solutions dont on disposait jusqu prsent ne donnent pas satisfaction. De fait, la dmarche aboutissait souvent une documentation littraire de la cible du SI urbanise, qui ne dbouchait sur aucune mise en uvre concrte. Les outils traditionnels de type portail, EAI et Workflow disposent dune souplesse limite et fonctionnent selon un mode propritaire. Ils sont un pis-aller, une solution incomplte qui napporte pas entire satisfaction, car ils noffrent pas de vraie alternative au fonctionnement par silo, qui bride lvolutivit du SI.
On verra dans la suite de cet ouvrage que la dmarche SOA offre une solution beaucoup plus complte ces problmatiques durbanisation : elle se base sur des principes indpendants des technologies ou des solutions dditeurs. Elle rpond ainsi aux problmatiques de connectivit et dinteroprabilit. Elle offre une vision plus large et plus satisfaisante pour les urbanistes.
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.
3.1 LES EXIGENCES DES MTIERS

On a vu dans ce qui prcde que linformatique devient omniprsente et donc de plus en plus critique dans lentreprise, et quelle doit saligner avec les besoins mtiers et stratgiques. Lvolution des modes dusage des SI fait apparatre dautres exigences, dcrites dans ce paragraphe.
3.1.1 Dployer rapidement des processus mtiers

Comme voqu dans le paragraphe sur les outils de Workflow, lentreprise a aujourdhui besoin de dployer rapidement des processus mtiers partir dune expression de besoins.
20
3. Le cahier des charges du SI
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.
3.1.3 La DSI doit justifier son budget

Le temps o linformatique tait perue par les directions et les mtiers comme une mcanique mystrieuse et impntrable est rvolu. Les DSI ne peuvent plus, comme dans le pass, disposer de budgets pour investir dans une nouvelle technologie sans justification, ni calcul de retour sur investissement. Linformatique est aujourdhui une source dnergie pour lentreprise au mme titre que llectricit. Ses dpenses doivent donc tre justifies et rationalises; et les DSI doivent travailler sur la prennisation de leurs investissements. De plus, les nouveaux investissements doivent tre penss en terme de rutilisabilit. Ainsi, il nest plus dactualit de dclencher des big bangs , cest--dire de redvelopper entirement un existant dans le seul objectif dutiliser la technologie la plus actuelle. On privilgie plutt lintgration des anciens systmes avec les nouveaux grce des middlewares adapts. Par ailleurs, on favorise le dveloppement de composants ou frameworks rutilisables et capables de sassembler de diverses manires, selon les besoins des mtiers. On verra dans la suite que la dmarche SOA rpond cette exigence dinvestissement informatique en phase avec les besoins mtiers.
3.2 Les exigences techniques
21
3.2 LES EXIGENCES TECHNIQUES

Toute nouvelle dmarche dharmonisation globale reposera ncessairement sur une infrastructure dintgration. Cette infrastructure ne sera pas seulement un systme dacheminement de messages : elle devra offrir des fonctionnalits de gestion de processus, de donnes, dapplication et de suivi. De plus elle proposera des outils de mise en uvre et daide au dploiement. Dans la suite, on dsignera cette infrastructure par le vocable plate-forme dintgration .
3.2.1 Inciter la rutilisation

Valoriser lexistant du SI Cette exigence est la traduction technique de la prennisation des briques existantes du SI (cf. chapitre prcdent). La plate-forme dintgration du SI doit en tout premier lieu intgrer des interfaces vers les diverses typologies dapplications.
Dans les Systmes dInformations un peu consquents, on trouve un certain nombre de familles applicatives : Applications mtiers, trs variables selon le secteur dactivit de lentreprise. Applications de collaboration : progiciels de messagerie, agendas partags, etc. Applications de support : progiciels de gestion des ressources humaines, de la paye, de la comptabilit, etc. Applications dcisionnelles, permettant la remonte dindicateurs de pilotage. Bases rfrentielles. La plate-forme dintgration devra donc proposer une connectivit exhaustive afin de couvrir toutes les typologies dapplications hrites au sein du Systme dInformation.
On verra dans la suite de cet ouvrage que SOA privilgie la notion de best effort , cest--dire que chaque application devra faire de son mieux pour prsenter des interfaces facilement intgrables par les autres. La plate-forme dintgration doit donc offrir des interfaces vers les applications incapables de fournir ce best effort , notamment les applications patrimoniales.
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.
3.2.2 Faciliter les changes tous les niveaux du SI

Savoir grer diffrentes typologies de flux La plate-forme dintgration doit tre capable de vhiculer des informations entre les applications selon diffrents modes dchange, suivant diffrents formats, et diffrents niveaux dintgration.
Les modes dchanges adresser sont les suivants : change synchrone (architecture couple) : dans ce cas, lapplication appelante attend la rponse sa requte avant de continuer ses traitements. HTTP est un mode classique dchange synchrone. change asynchrone (architecture dcouple) : dans ce cas, la demande est place dans une queue dattente et le traitement en cours nest pas interrompu. Il prendra en compte la rponse sa requte lorsque celle-ci sera disponible. Parmi les systmes dchange asynchrones les plus classiques, on peut citer les middlewares orients message, ou tout simplement les protocoles de messagerie. Mode Publish and Suscribe : dans ce contexte, la plate-forme dintgration met disposition des abonnements des flux dinformations. Les applications dsireuses dtre informes de changements au sein du SI peuvent sabonner ces flux. Un cas classique est une souscription aux informations dvolution dun rfrentiel mtier. Information par dclenchement : dans ce cas, cest un vnement applicatif qui provoque lchange dinformation. La plate-forme dintgration dtecte un changement au sein dune des applications du SI et notifie les lots applicatifs concerns. On peut citer lexemple de larrive dun nouveau collaborateur dans lentreprise : son insertion dans le logiciel de gestion des ressources humaines dclenche la cration dune bote mail.
Assurer la scurit des changes inter-applicatifs

Rappels gnraux sur la scurita Les spcialistes analysent gnralement les besoins de scurit dune plate-forme suivant cinq fondamentaux : Lauthentification : elle consiste sassurer de lidentit dun utilisateur avant de lui donner laccs un systme ou une application.
a. Pour en savoir plus sur les notions de scurit, voir Scurit des Architectures Web, Guillaume Plouin, Julien Soyer, Marc-ric Trioullier, Dunod, 2004.
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).
Assurer une garantie dacheminement

Rappels sur la garantie dacheminement La plupart des protocoles de transport utiliss en informatique noffrent pas de garantie de livraison suffisante pour des transactions applicatives. Des protocoles comme HTTP et SMTP offrent bien un contrle technique sur les erreurs de transmission,
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.
Grer les transactions distribues

Rappel sur les transactions distribues Le cadre des transactions distribues est celui o lon doit crire des donnes dans un rfrentiel partir de traitements concurrents et distribus. Ce type de transaction ncessite un middleware assurant la cohrence des accs en criture : le moniteur transactionnel. Les transactions distribues fonctionnement gnralement selon le principe twophase commit : Premire phase : le moniteur transactionnel demande chaque ressource dtre prte soit valider toutes les modifications, soit les rvoquer. Seconde phase : si toutes les prparations sont OK le moniteur demande toutes les ressources de valider les modifications (commit ), sinon il demande toutes les ressources de tout rvoquer ( roll back ).
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.
3.2.3 Reposer sur des rfrentiels de mta-donnes

Pour offrir au SI une vision de ses capacits dintgration, il est important que la plate-forme dispose dun rfrentiel des applications prtes lintgration. Ce dernier doit rfrencer les modes daccs aux lots applicatifs et pointer sur les dictionnaires dcrivant leur langage dchange. Il doit aussi savoir localiser les diffrentes
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.
3.2.4 Piloter la plate-forme
Prsentation
Composition & Coordination
Pilotage
Garantie dacheminement
Transactions
Scurit
Rfrentiels
changes & transformations
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
Expliquer les concepts SOA

SOA1, Services et Web Services2 sont des terminologies trs la mode. La plupart des publications, prsentations ou confrences sur ces thmes saccompagnent quasi systmatiquement de dfinitions le plus souvent diffrentes les unes des autres. En recherchant le terme SOA sur Google, il est possible datteindre plus de 40 millions de liens Internet, et prs de 400 millions pour Web Services ! Lobjectif de cette deuxime partie est donc de clarifier les concepts utiliss, en premier lieu la notion de services et darchitecture de services puis celle de composition de services. Il introduit une architecture de rfrence positionnant les diffrents concepts. Il clarifie galement pourquoi les Web Services sont utiles, mais pas indispensables. Le second chapitre sattache dcrire les fondements du concept dorientation service et notamment la notion de contrat et de messages. Enfin le dernier chapitre introduit les outils mettre en place de faon progressive en regard de larchitecture SOA de rfrence.
1. SOA (Service Oriented Architecture, ou architecture oriente services) tant lacronyme anglosaxon le plus couramment rpandu, il sera utilis tout au long de ce livre. 2. Web Services (WS) est la terminologie anglo-saxonne quivalente Services Web. La notation abrge WS-* est utilise pour dsigner les standards sy rapportant.
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
4. Urbanisation et architecture SOA
4.1 SOA CONCRTISE LE MODLE DURBANISATION

SOA, ou Architecture Oriente Service : le concept met demble en avant limportance de larchitecture du SI. La dmarche SOA a en effet pour objectif gnral de faire voluer cette architecture afin de rpondre aux problmes dcrits dans la partie 1. Il est donc important de montrer comment le modle gnral durbanisation vu en partie 1 volue avec SOA. Cest lobjet de ce sous-chapitre. La rponse SOA au syndrome des silos, propose une stratgie danticipation capable de se gnraliser lchelle de lentreprise. Cette stratgie repose et prolonge lhabitude prise par les urbanistes de modliser des couches dabstraction entre le monde rel des processus et les technologies sous-jacentes. Cette approche concrtise la vue logique, ou vue des Services (le terme tant progressivement dfini partir du prochain paragraphe). La vue des services rpertorie les fonctions mtier sous-jacentes, pour beaucoup dj existantes et tablies, et les prsente sous forme de services.
4.1.1 Lmergence de pourvoyeurs de services ?

Quest-ce quun service ? Un service, au sens SOA, met disposition dacteurs (humains ou logiciels) intervenants dans des processus mtiers, un accs vers une ou plusieurs fonctions mtiers. Un service concrtise le lien entre la couche mtier (constituant le ct consommateur) et les implmentations dans le SI (constituant le ct fournisseur) en prenant sa charge un contrat (ralis par le ct pourvoyeur).
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
4.1 SOA concrtise le modle durbanisation
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.
Caractristiques gnrales dun service

Lanalogie avec le monde rel permet de dterminer les principales caractristiques dun service. Vu du consommateur, le service doit offrir une valeur ajoute ainsi quune garantie de qualit du service rendu. Un service de distribution de billet de banque ne sera pas utilis sil est trop lent ou sil commet des erreurs. Le consommateur peroit donc un service comme : un composant respectant un Contrat de service : tous les distributeurs respectent le mme contrat de service, savoir dlivrer des billets aprs que lutilisateur ait fourni les informations ncessaires; un composant de type Bote Noire : il nest pas ncessaire de savoir comment cela fonctionne; un composant autonome : les dpendances ventuelles entre services ne sont pas visibles. Vu du pourvoyeur, le service est le plus souvent synonyme de comptition et donc damlioration de la valeur ajoute. Par exemple, la concurrence entre banques pousse ces dernires enrichir le service fourni par un distributeur (consultation de compte, recharge de carte etc.) et en amliorer lergonomie. Le pourvoyeur devra donc proposer des services : Homognes (donc faciles utiliser pour le client) : un service de distribution est quasiment standardis dans chaque pays (sans avoir lire 300 pages de notice !). Performants. Offrants une qualit mesurable : ceci permet de choisir le plus comptitif un instant donn. Indpendants du contexte du client : cest un gage de rutilisation pour le bnfice du plus grand nombre, mme si des lments contractuels peuvent venir dicter des restrictions dutilisation.
4.1 SOA concrtise le modle durbanisation
33
4.1.2 EDA, POA, SOA Querelle de chapelles ou vrai dbat ?

Mme si SOA est le nouveau terme la mode, il ne faut pas pour autant jeter aux oubliettes de lhistoire des modles architecturaux intressants tels que EDA ou POA. Il est en effet intressant de positionner ces modles pour affiner la prsentation de SOA.
EDA ( Event Driven Architecture) est un modle darchitecture posant comme principe fondateur la propagation automatise des vnements mtiers dans le Systme dInformation. Lobjectif est dviter, autant que possible, la dsynchronisation de multiples rfrentielsa, et surtout dassurer un traitement en temps rel de ces vnements, ni trop tard ou, pire, jamais effectu.
a. Un vnement tant souvent porteur de nouvelles informations dupliquer dans le SI pour cause dhtrognit de ce SI.
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
4.2 AU CUR DE SOA : LE CONCEPT DE SERVICE

4.2.1 Identifier les services SOA
SOA propose donc un modle darchitecture informatique bas sur lmergence dune couche de services. Ces services offrent une vue logique des traitements et donnes existant dj ou dvelopper. Chaque service encapsule ces traitements et donnes et masque ainsi lhtrognit du systme dinformation. Lexemple suivant (figure 4.2) illustre le propos. Un service gestion des clients offre par exemple une vision client unifie. Pour cela il agrge les informations parses dans le SI : il rcupre la fiche didentit du client et les noms des contacts dans le logiciel CRM, le contrat du client dans lERP et les ventuels contentieux dans un outil spcialis. Tout ce travail dagrgation est masqu aux utilisateurs de ce service. Le service gestion du catalogue produit met disposition les informations sur les produits de lentreprise. Ce service masque laccs lERP (rcupration des tarifs), laccs loutil de PLM (rcupration de certaines caractristiques techniques), et laccs au Catalogue Marketing (promotions en cours). Le service gestion des stocks met disposition les informations rcupres soit dans le mainframe de lentreprise (pour les usines et les entrepts) soit dans les serveurs des filiales non intgres.
Remarque importante : les grands progiciels propritaires sont eux aussi condamns adopter cette approche SOA pour tre plus flexibles. Ils doivent en effet autoriser une rutilisation plus facile de leurs fonctions dans des processus traversant les frontires des silos applicatifs, au sein dune entreprise, voire autoriser cette rutilisation dans des processus traversant les frontires des entreprises.
Service
Service
Service
Client
Catalogue produit
Stock
Rfrentiels, Applications hrites & Ressources techniques
Figure 4.2 Encapsuler lexistant par des services
4.2 Au cur de SOA : le concept de service
35
4.2.2 Construire de nouveaux services

Bien videmment lexemple qui prcde est incomplet. Pour le complter, on peut par exemple introduire la gestion de prise de commande. Lors dune prise de commande, il faut dabord vrifier que le client existe et son contrat est valide, puis vrifier que les produits existent dans le catalogue, dterminer ensuite quels entrepts possdent les stocks pour fournir les produits commands et enfin lancer la livraison. De plus, un partenaire commercial (concessionnaire, agent) doit pouvoir effectuer une prise de commande via Internet. La solution au sens SOA est dajouter un service gestion de commande figure 4.3 qui utilisera les services dj en place pour excuter le traitement dcrit ci-dessus.
Service
Commande
Service
Service
Service
Client
Catalogue produit
Stock
Figure 4.3 Cration dun nouveau service par composition
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 Catalogue produit
Service Stock
Service Annuaire des services
Service
Logistique livraison
Figure 4.4 Composition et interoprabilit
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);
4.2 Au cur de SOA : le concept de service
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).
4.2.3 Grer le cycle de vie des services

Identifier les services mettre en place
Lidentification des services est une tape clef pour le succs de SOA. Quels sont les critres didentification ? Un service est identifiable et na de relle justification que sil satisfait au moins un des trois critres suivants : Le service est mutualis au sein dune forte population dapplications consommatrices informatiquement, il permet la rutilisation. Le service facilite lintermdiation avec un fonctionnement existant interne un SI (par exemple, il est plus simple daller au bureau de Poste, que de porter chaque fois un colis chez son destinataire !) informatiquement, il permet linteroprabilit, offerte via Internet dautres SI. Le service est ncessaire un enchanement plus global dactivits via un processus mtier informatiquement, il autorise son emploi dans une composition.
Mettre en place les services

Puisquil doit relier concrtement des processus/tches mtiers avec des applications et progiciels volutifs et rpartis, un service nest pas uniquement un concept : il existe bel et bien en tant que composant logiciel excutant une tche spcifique plus ou moins ambitieuse pour le consommateur (par exemple : Rechercher une information, excuter un processus de prise de commande). La mise en place dun service distingue donc dune part la modlisation du contrat qui dcrit le service rendu, dautre part limplmentation du service, qui doit respecter le contrat dfini, et enfin les modalits de dploiement. Les modalits de dploiement incluent la localisation du service dans la vue Physique (adresse du service), le protocole daccs ce service, ainsi que les contraintes de scurit ou de qualit dexcution respecter. Remarquons cependant que le modle SOA ne prjuge nullement du fait quun service soit simplement un aiguilleur de la demande de service vers un logiciel existant : le service peut implmenter lui-mme le traitement demand. Dans ce cas le pourvoyeur se confond avec le fournisseur de services.
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.
Maintenir les services

La gestion des volutions dun service est un point clef, qui passe par la gestion de versions et dvolutions de composants logiciels ( ne pas confondre avec la gestion de variantes dcrites dans le chapitre 5). Cette gestion nest pas en soi une nouveaut apporte par SOA; cependant, les services tant la pierre angulaire de lapproche, SOA impose une mise en place rigoureuse de cette gestion. En outre, il pourra savrer trs utile, notamment en cas de multiples consommateurs dun mme service, de savoir distinguer : les principaux statuts dun service. Par exemple : En Dfinition , En Test (ou Bouchon1 ), En Production ( ou Public ) et En Retrait (ou Obscolete ); les principaux rles dintervention et leurs taches associes chaque volution de statut : le responsable catalogue, le responsable solution mtier2, le responsable conception, le responsable implmentation, le responsable exploitation, le responsable des services transverses, etc. Cela met en exergue de faon plus gnrale limportance de loutillage associ la dmarche : le chapitre 6 prsente un premier aperu de cet outillage, puis la partie 7 le dtaille.
4.3 ARCHITECTURE DE RFRENCE SOA

4.3.1 Le concept dapplication composite
Qui peut consommer des services ? Rpondre cette question ncessite dintroduire un nouveau type dapplications, qualifies de composites dans une appro1. Lanalogie du bouchon dsigne ici une implmentation provisoire permettant dutiliser le service avant que sont implmentation vritable ne soit rendue disponible. 2. Voir le chapitre 7.
4.3 Architecture de rfrence SOA
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
Figure 4.5 Larchitecture de rfrence SOA
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.
La ncessit du contexte de composition

Lorsque le service est partie prenante dune composition, il doit tre sollicit en cohrence avec les autres services composs. Ceci implique de partager un contexte dchange entre les services. Ce contexte permet le passage dinformations entre plusieurs services, que ce soit des informations mtier ou des informations caractre
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.
Une application composite devient son tour un service !

Ces applications peuvent sexposer leur tour sous forme de service contractualis pour leurs consommateurs.
Applications Interactives Application Interactive Front Office
Applications Composites
Processus Mtier
Figure 4.6 Une composition est un service
4.3 Architecture de rfrence SOA
41
4.3.2 Typologie des applications composites

Zoom sur lorchestration de services au sein dun processus mtier
Un processus mtier au sens SOA est vu comme un enchanement plus ou moins automatis de services effectu par un unique intermdiaire, le chef dorchestre . Do le nom dorchestration de processus pour ce type de composition. La logique de cet enchanement (squentiel, parallle, etc.) est dcrite, comme dans le workflow classique, par un modle dorchestration directement excut par le chef dorchestre, appel moteur dautomatisation de processus (BPM1). Lorchestration dcrit galement la logique de contrle et le flux de donnes internes dun processus mtier.
Quelle diffrence entre workflow traditionnel et processus mtier SOA ? Un processus SOA exclut a priori lhomme dans la boucle. Il sagit donc de processus de type e-Business, recevant et traitant automatiquement les vnements mtier.
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.).
Zoom sur la composition interactive de services

Larchitecture MVC2 est larchitecture de rfrence des applications composites interactives. MVC est bien connue dans le monde de la programmation objet et permet disoler dune part un modle mtier, dautre part des vues interactives rendues par un moteur graphique sur de linformation en provenance du modle, et enfin des contrleurs de dialogues. Cette architecture doit tre revue avec lapproche SOA (cf. le chapitre 10 pour plus de dtails) : Le modle mtier nest plus local lapplication, mais encapsul dans un ou plusieurs services mtier. Le contrleur MVC doit donc coordonner lappel ces services et se transforme donc en coordinateur , capable deffectuer une squence dinvocations attendues. Au fur et mesure des invocations, le coordinateur doit en gnral prserver un ensemble dinformations communes entre les services. Le modle MVC est donc remplac par un contexte local lapplication (voir ci-dessus le paragraphe La ncessit du contexte de composition ).
1. BPM Business Process Management. 2. MVC Model-View-Controler est la terminologie anglo-saxonne signifiant Modle Vue Contrleur.
42
Traiter rejet
Commande
Vrifier commande
Vrifier engagement
Envoyer commande au fournisseur
Service #1 Service #2 Service #3

Facture
Mettre en paiement
Alerter Attendre x jours
Figure 4.7 Illustration dune composition orchestre de services
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.
4.3.3 Topologie des applications composites

Il existe plusieurs topologies de dploiement client/serveur des applications composites, comme lillustre la figure 4.8.
Topologie client lourd

Lapplication composite (Moteur graphique et implmentation MVC revisite ) rside, dans ce cas, sur le ct poste client. Elle labore les vues en local sur ce poste client. Elle appelle des services hbergs par le(s) serveur(s). La communication client services peut soit utiliser XML, soit reposer sur des technologies moins gourmandes en bande passante mais confines lintrieur du SI (EJB, DCOM).
Topologie client lger

Lapplication composite rside sur le serveur : elle labore les vues et envoie ces vues un moteur graphique distant : le navigateur Web. Lapplication composite fait alors appel des technologies de pages web dynamiques spcifiques, plus ou moins standardises (e.g. jsp, jsf, struts, asp, asp.net, etc.).
Topologie client distant

Lapplication composite devient dans ce cas un service. Le client est alors un portail distant, qui utilise un protocole de communication ddie pour dialoguer avec ce ser-
4.4 Pour une dmarche SOA gradue
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
Rseau
Rseau
Services
Services
Services
Figure 4.8 Topologie de dploiement des applications composites
4.4 POUR UNE DMARCHE SOA GRADUE

4.4.1 Pourquoi dbuter une dmarche SOA ?
La dmarche SOA peut obir plusieurs types de stratgie de la Direction Informatique et/ou des matrises douvrage : Stratgie pilote par les mtiers : les besoins mtiers imposent linformatique dvoluer. Stratgie pilote par les technologies : lvolution des technologies offre des opportunits aux mtiers (par exemple, lintroduction des mobiles et Internet comme nouveaux canaux de communication).
1. WSRP Web Services for Remote Portlets, cf. la partie 4.
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).
4.4.2 Comment dbuter ?

SOA ne se dcrte pas : il est ncessaire de mettre en place une dmarche progressive dadoption. Sur le plan de lurbanisation, cette dmarche ciblera en priorit le silo mtier dont les modifications peuvent laisser esprer un retour sur investissement rapide. Elle stendra progressivement aux autres silos. Sur le plan de lorganisation, on mettra en place en priorit un plan dacculturation des quipes, y compris les quipes de production, trop souvent ngliges au dmarrage alors quelles devront, comme toujours, finir par assumer le fonctionnement du SI, 24 heures sur 24 et 365 jours par an, quelles que soient ses volutions. On dfinira en parallle un cycle de vie global, tel que celui prsent dans le chapitre 11.
4.4.3 Quelles consquences sur le SI ?

Le SI doit rpondre des exigences plus techniques, savoir : Une garantie de performance : Cela implique de dcrire, mesurer et contrler une qualit des prestations la fois en amont de la sollicitation de services (il sagit de laccessibilit), pendant lexcution (il sagit de la fiabilit) et jusquen aval (il sagit alors de la disponibilit). Une fourniture dinfrastructure : Elle fait face lvolutivit et au changement de taille prvisible tout en se prmunissant de lhtrognit technologique (donc des formats, protocoles, patrimoine existant, etc.) mais aussi de
4.4 Pour une dmarche SOA gradue
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.
4.4.4 Quels problmes cls ?

Que le primtre dune dmarche SOA soit lchelle dun lot, dun silo applicatif ou du SI, elle reste empreinte dune ambition certaine. Elle ncessite donc de bien apprhender les risques encourus. Ces risques portent notamment sur : La modlisation adquate des services et des processus (partie 3, chapitres 8 et 9). La conception des applications composites, en tenant compte des spcificits de SOA (partie 3, chapitre 10). La maturit progressive des quipes, en matire de pratiques durbanisation, de dveloppement et dintgration (partie 3, chapitre 11). La comprhension des normes et standards (partie 4) et leur matrise (partie 5). Le choix des outils et le dploiement de ces outils en une infrastructure cohrente, compatible avec lexistant et administre (partie 7).
4.4.5 Premier bilan

Cet ouvrage sefforce de prsenter le primtre des notions connatre pour envisager au mieux lvolution du SI dans le respect du cadre SOA, que cette volution soit ambitieuse ou plus modeste. Il est cependant important de noter une divergence certaine dintrt entre les diffrents acteurs du monde SOA. Beaucoup dditeurs se proccupent surtout doutiller la vue technique , la plus lie aux technologies dinfrastructure et aux serveurs dapplications. Cependant lobjectif principal dune entreprise sengageant dans une dmarche SOA concerne la rationalisation du mtier et de lorganisationnel (par consquent la vue mtier et la vue logique ou vue des services ) : par consquent, il est bien plus important de raisonner architecture, mthodologie et organisation, que de raisonner technologies et normes. SOA est, dabord et avant tout, une dmarche architecturale et organisationnelle : le choix des technologies et des outils reste secondaire. Il est parfaitement possible de mener une dmarche SOA sans utiliser les Web Services, mme si ces outils prsentent des avantages indniables (cf. partie 5).
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).
4.5 QUELQUES IDES REUES SUR SOA

4.5.1 Ce que SOA nest PAS !
Plusieurs amalgames sont entretenus par le marketing de fournisseurs en mal de vente, quil est ncessaire de clarifier ici.
SOA nest pas une technologie. SOA est dabord un ensemble de concepts constituant un modle cohrent darchitecture pour faciliter la flexibilit du SI via lmergence de services intgrant/rutilisant des applicatifs existants et, par ailleurs SOA est une dmarche progressive dapplication de ce modle.
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.
4.5 Quelques ides reues sur SOA
47
SOA ne se rduit pas la mise en place dun broker dintgration (EAI).
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).
4.5.2 Ce que SOA ne dit PAS !

SOA ne rsout pas les problmes existants dans les implmentations : Si les concepts SOA peuvent apporter un cadre pour lagilit et la rutilisation dun existant, SOA ne rsout pas pour autant les problmes dimplmentation dun existant telle que la simplification ou loptimisation dun code vieillissant ou trop monolithique, la non adquation des algorithmes mtier ou leur difficult voluer pour supporter de nouvelles rgles de gestion, des performances insuffisantes, etc.
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.
5.1 FORMALISER LES SERVICES

5.1.1 Service et contrats
Le concept de service a fait ressortir ce qui relie dun ct des consommateurs, ou client, requrant le service, et de lautre des pourvoyeurs capables de proposer le service (e.g. Lire lhistorique de commande, Mettre jour le statut de livraison, etc.). Il est ds lors ncessaire de formaliser ce lien entre consommateur et pourvoyeur, afin que la rutilisation du service en soit facilite et, sil y a lieu, son interoprabilit garantie : on introduit alors comme on la vu le concept de contrat.
50
5. Au cur de SOA : le concept dorientation service
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
Opration 1(requte, rponse) Opration 2 (requte, rponse)
Implmentation
Contrat
Figure 5.1 La notion de 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).
5.1.2 Service et messages

Lorsquun consommateur souhaite utiliser (requrir) une opration dun service, il lui transmet un message transportant sa requte.
On notera ds prsent, que les requtes des consommateurs et rponses des pourvoyeurs seffectuent uniquement par messages1, tandis que les invocations dans le SI seffectuent selon une technologie propre chaque lot.
1. La notion de message entre service est approfondie au chapitre 5.
5.1 Formaliser les services
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
Figure 5.2 Lchange de messages entre consommateur et pourvoyeur
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
5.2 SPCIFIER UN CONTRAT DE SERVICE

5.2.1 Que contient un contrat de base ?
Ce contrat minimaliste est encore souvent appel, par abus de langage, contrat dinterface. Il est constitu dune liste dune ou plusieurs oprations1. Chaque opration est dcrite par les messages de requte et de rponse changs avec les consommateurs du service : le triplet [nom de lopration, message de requte, message de rponse] est appel signature de lopration2. Les messages doivent aussi transporter des informations mtiers, dites srialises. Pour cela le contrat doit aussi prciser la structure et le format de chaque information. Les oprations sont accessibles via un ou plusieurs protocoles de communication. Enfin, le service est localis sur une ressource physique donne, autrement dit, en gnral, un serveur. Protocole et localisation du service sont dpendants dune technologie rseau donne. En revanche, oprations et signatures sont indpendantes de toute technologie. Pour obtenir un service, de mme que pour offrir un service, consommateur et pourvoyeur du service devront respecter ce contrat cest--dire se conformer un protocole de communication et changer des messages entrants et/ou sortants dfinis par le contrat.
Indpendant de la technologie
Informations mtier Contient Message Reoit Interface du service
Invoqu via Protocole de transport Utilise Adresse du service
Figure 5.3 La description dun contrat de base

1. linstar de mthodes disponibles sur un objet en programmation objet. 2. linstar dune signature de fonction dans la programmation procdurale.
Dpendant de la technologie
5.2 Spcifier un contrat de service
53
5.2.2 Contrat et qualit de service

Lexigence de qualit
La contractualisation du service doit traduire la volont dun accord entre consommateur et pourvoyeur non seulement sur les rponses apportes par le service, mais aussi sur la qualit du service. En gnral le consommateur souhaite non seulement que le service rponde ses demandes, mais encore quil le fasse vite et sans erreur ! Le consommateur doit donc non seulement connatre loffre de services (le contrat de base ), mais aussi les garanties offertes par le pourvoyeur, garanties qui peuvent proposer un ou plusieurs niveaux de qualit selon le service disponible. Cest lintrt du pourvoyeur doffrir de telles garanties : en effet, face une absence de garantie, tout consommateur sera rticent utiliser un service. En effet, mme si une premire utilisation se passe bien, un consommateur na pas de garantie sur la rptition de ce bon fonctionnement. Un pourvoyeur offrant des garanties maximise lutilisation de son service et ainsi le rentabilise. Le pourvoyeur doit donc communiquer ouvertement sur ses capacits et mettre en regard ces capacits avec les exigences du consommateur. En retour, le pourvoyeur pourra exiger que le client respecte certaines contraintes et obligations dutilisation. Ces contraintes sont autant de directives respecter. Les directives expriment la ncessit de prendre en compte certaines rglementations et contraintes internes (mode daccs) ou externes, et sappliquent en gnral une catgorie (ou groupe) de services.
Garanties de service
Interface
Contrat
Directives demploi
Figure 5.4 Le contrat tendu
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.
SLA Garanties de service
Interface
Contrat
Directives demploi
Figure 5.5 Le contrat avec SLA
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.
5.2 Spcifier un contrat de service
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)
Implmentation#2 (version de test)
Implmentation#3 (version de prod)
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.
5.2.3 Matriser la coordination de services

Externaliser la squence dinvocation de services
La notion de composition introduite au prcdent chapitre fait ressortir le concept de contrat externalis tendu un service souhaitant enchaner plusieurs autres services. Ceci implique que des garanties ou SLA soit donc nouveau dfinie pour chaque composition. Au-del de lorchestration, la collaboration est un autre type de coordination automatise principalement utilise pour de la synchronisation entre plusieurs processus mtiers. La collaboration permet chaque processus de se limiter connatre et seulement utiliser les documents ou messages entrants et sortants dautres processus en interaction avec lui, sans avoir connatre le droulement prcis (interne) de chacun dentre eux.
Ds lors, la diffrence majeure entre les systmes traditionnels de workflow et les moteurs de composition interactive ou automatise est la capacit de dcrire la squence, non seulement sparment de limplmentation, mais surtout sparment
5.3 Mettre en production et exploiter les services
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).
Vrifier la cohrence entre processus

Au-del de la composition relative lexcution de squence de services, se pose aussi la question de la cohrence entre plusieurs squences ds la phase de dfinition des services. En effet, dans certains cas mixant des processus implants entre diffrents acteurs (usine, entrept, agent commercial), une description des dialogues entre les processus, appele chorgraphie, servira de meta-modle et permettra de dcrire la cohrence entre les principaux vnements changs entre processus. La figure 5.7 rsume les nuances de terminologie pour la coordination de services au travers de lexemple dune rservation de voyages impliquant la composition automatise dun service de rservation dhtel et dun service de rservation de billet davion.
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
Orchestration 1) Demande Vol Capacit Htelier
1) Rception Demande 2) Fourniture offre 3) Rception Slection 4) Envoi confirmation Rsa. Voyage
2) Demande Htel 3) Rsa. Vol 4) Rsa. Htel
Chorgraphie
1) Rception Demande 2) Fourniture offre 3) Rception Slection 4) Envoi confirmation
Interface
Orches.
Chane Htelire
Interface
Chorgraphie Interaction entre entits
Orchestration Composition dentits
Interaction sur lentit
Figure 5.7 Notions lies la coordination de services
5.3 METTRE EN PRODUCTION ET EXPLOITER LES SERVICES

Pour tre complte, une description de services doit aussi comporter : dune part, les lments relatifs la configuration et la gestion de variantes des services;
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.
5.3.1 Le dploiement des services

Sil est utile du point de vue de la flexibilit de dcrire explicitement le contrat dun service, il est tout autant utile, pour sa mise en production, de dcrire aussi explicitement les dpendances quil peut avoir vis--vis dautres services. linstar de spcifications existantes, mais fortement couples une technologie (comme celles des EJB ou des frameworks dinjection de dpendances comme Spring pour Java), lutilisation dune norme, indpendante de la technologie dimplmentation et dexcution des services, permettra dunifier ce descriptif, quil sagisse de services dploys en technologies .NET, Java, Web Services, etc. Ce besoin crucial pour la russite de lapproche service a induit lmergence de la norme SCA (cf. partie 4 chapitre 14).
5.3.2 La gestion des variantes dun service

Le concept de variante de service dsigne lintrt voire lobligation de pouvoir paramtrer lors de son dploiement le comportement dun service. Prenons le cas dun service bancaire dvaluation du risque associ un portefeuille boursier : ce service est dploy dans chaque filiale, et doit donc raisonner chaque fois dans une unit montaire diffrente ($, , , etc.) tout en appliquant les mmes rgles prudentielles, cest--dire en utilisant la mme implmentation. Lobjectif dune gestion de variante est de ne pas tre contraint implmenter autant de versions dun service que de cas pouvant se prsenter. Cette flexibilit se paie par : la complexit accrue des tests du service; la complexit dimplmentation du service, dans les cas les plus complexes; lorsque le nombre de configurations augmente sensiblement, un outil ddi se rvlera indispensable pour grer et centraliser le paramtrage des variantes. Trois techniques principales sont exposes ici, et doivent tre retenues suivant les contraintes de chaque projet.
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.
5.3 Mettre en production et exploiter les services
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.
Lapproche assertive Lusage de langages dassertions

Cette technique peut sappliquer pour contrler de faon diffrencie laccs au service (ce consommateur a-t-il le droit dutiliser le service ?) et/ou les messages dinvocation et de rponse du service (ce message est-il valide lorsque cest ce consommateur qui lenvoie ?) et/ou le contexte dinvocation (le contexte est-il complet lors de linvocation ? lors de la rponse ?) et/ou le respect du SLA (les conditions de scurit sont-elles remplies ? etc.). La technique sappuie sur la dfinition de pr ou de post conditions dterminant soit le dclenchement effectif du service, soit lenvoi dune rponse. Ces pr et post conditions sont excutes par un outil appropri. La crativit dans ce domaine est intense, mais hlas ne contribue pas faire merger un candidat incontestable ! On citera nanmoins la Programmation Orient Aspect comme candidat srieux2. Sur le plan de la modlisation, OCL (Object Constraints Language), li UML et encore trop peu connu, pourra se rvler pertinent dans une optique MDA (cf. chapitre 11), cest--dire coupl un gnrateur de code vers loutil cible.
1. Cf. la bible de rfrence : Design Patterns Elements of Reusable Object-Oriented Software, Erich Gamma et alii, Addison-Wesley, 1995. 2. Le recours des langages exotiques comme Eiffel parat dfinitivement proscrire. Le recours des langages construits au dessus de Java ou C# (Jcontractor, Jass, JMSAssert, .NetContract, etc.) est plus raliste, mais attendra la maturit de lun de ces outils.
60
5.3.3 Le suivi des services

Concernant la supervision, un modle classique consiste instrumenter chaque service au moyen dun agent plus ou moins intrusif (par exemple agent JMX ou WMI). Cet agent est notamment en charge de dater chaque message entrant ou sortant, en retransmettant ces mesures auprs dune console centrale. Cette console doit fournir des moyens simples dexprimer des filtres et des rgles de corrlations entre les mesures tablies afin de ne pas noyer lexploitant sous une masse inutilisable de chiffres.
5.4 POUR UNE DESCRIPTION FORMELLE EXPLICITE DU CONTRAT DE SERVICE

Il apparat clairement le besoin de spcifier progressivement chaque service, depuis sa phase didentification jusqu sa phase de dploiement, en passant par son implmentation et sa mise au point. Le recours une fiche type permet de regrouper lensemble des caractristiques dcrire.
Carte didentit
Contrat(s) Technique(s) Opration #2 Opration #1
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 : :
Cas dusage : Service(s) Consommateur(s) : Service(s) Consomm(s) :
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) :
Figure 5.8 Exemple de fiche modle spcifiant un service
5.4 Pour une description formelle explicite du contrat de service
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.
5.4.1 Bilan des contraintes et des bnfices

Un contrat de service satisfait les critres suivants : Formalis : le contrat est dfini dans un langage formalis, WSDL par exemple. Publi : le contrat est publi, accessible et comprhensible par les consommateurs. Concentr sur une mission fonctionnelle et une seule : le service est clairement positionn dans la taxonomie des services (mtier versus technique, gros grain versus grain fin). tanche : le contrat ne fait pas rfrence limplmentation du service. Il est en ce sens une bote noire. Explicite sur la Qualit de Service. Le service lui-mme (plus exactement, son implmentation) satisfait les critres suivants : Autonome : il faut favoriser le couplage faible entre services. Isol des aspects techniques client/serveur : le pourvoyeur spare la logique mtier de la logique de communication client/service). Flexible : le paramtrage de variante doit tre possible sans intervention sur le code, et tre aussi tardif que possible, au moment du dploiement si possible. Sans tat : le service ne garde pas de trace de ses invocations successives, cest au consommateur de sen proccuper. Transparent : le service fournit des informations sur son excution, ses performances, etc. Les bnfices sont nanmoins nombreux : Lusage de contrats explicites assure lindpendance dvolution entre consommateur et pourvoyeur. Lusage de contrats stables et publics, li une dmarche dhomologation systmatique, favorise la rutilisation des services. Lexpression de niveaux de qualit de service contribue la mise en place progressive dun suivi proactif. Les techniques de compositions interactives et orchestres, permettent denvisager un dcouplage de la logique de coordination mtier et des services dj disponibles.
5.4 Pour une description formelle explicite du contrat de 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
6. Lmergence dune plate-forme SOA
6.1 LMERGENCE DU CONCEPT DE BUS DE MESSAGES

Le consommateur dun service invoque ce service en lui envoyant un message de requte, et en attendant ventuellement un message de rponse. Lensemble des messages changs entre consommateur et pourvoyeur de service transite via un outil que lon qualifiera pour linstant du terme relativement vague de bus de messages SOA.
Consommateur
Bus de message SOA
Interface
Implmentation
Figure 6.1 Le bus de messages SOA
6.1.1 Bus de messages et contrats formaliss

Les contrats de service doivent tre formaliss : ceci permet aux consommateurs de dlguer au bus de message le soin de vrifier que les messages changs sont bien conformes aux contrats concerns. Les EAI apportaient initialement leur formalisme propritaire. Il conviendra donc de recourir un vocabulaire plus universel (do XML) et si possible via lusage de standards WS-* (cf. chapitre 12)1. Pour oprer ces vrifications, ce bus doit accder un rfrentiel enregistrant les contrats de service WSDL, ou registre des services.
6.1.2 Bus de Messages et protocoles sous-jacents

Lapproche SOA souhaite isoler les consommateurs des technologies utilises par les fournisseurs pour implmenter les services, mais elle souhaite galement isoler pourvoyeurs et consommateurs des protocoles de communication utilisables pour changer les messages.
1. Il serait dailleurs plus conforme lhistoire, de dire que WSDL (et les autres standards de base, comme SOAP voir plus loin) sont apparus en premier, et que les difficults de mise en uvre de ces standards ont, dans un second temps, suscites les rflexions menant la cristallisation de lapproche architecturale SOA.
6.1 Lmergence du concept de Bus de Messages
67
Consommateur
Bus de message SOA Registre
Vrification Interface
Implmentation
Figure 6.2 Le bus de message SOA et le registre de contrats
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.
6.1.3 Les modes dchange de messages

Il est fondamental de comprendre quun service ne ncessite pas obligatoirement une requte et une rponse. Le modle dinteraction (entrant seul, sortant seul, entrant/ sortant etc.) devra faire lobjet dune formalisation dans le contrat de base.
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.
6.2 Du bus de messages la plate-forme SOA
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.
6.2 DU BUS DE MESSAGES LA PLATE-FORME SOA

Au fur et mesure de la progression du dploiement des services et de la volont dune industrialisation lchelle globale de lentreprise, se justifie le besoin dune infrastructure capable de couvrir lensemble des besoins identifis dans cette partie. La figure 6.3 prsente les diffrents ingrdients de ce qui constitue une vritable plate-forme de mise en place des Applications et des Services. Cette plate-forme regroupe : Le bus de service1 pour unifier les communications entre services.
Portail
Application Composite Application Composite
Moteur BPM (orchestration) Processus Mtier
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
Figure 6.3 Les composants dune plate-forme SOA

1. La terminologie anglo-saxonne utilise le terme Enterprise Service Bus (ESB) .
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.
6.2.1 Le contrle et la supervision des services

Les aspects qualit de service ont t prcdemment largement voqus. Il est donc ncessaire de superviser cette qualit. On parlera de SAM, Service Activity Management. La supervision dun service consiste le surveiller et agir sur ses paramtres oprationnels pour quil satisfasse les demandes des consommateurs et les contraintes des pourvoyeurs. De manire gnrale, elle couvre diffrentes fonctionnalits parmi lesquelles le suivi des erreurs, de la performance, de la qualit et de la scurit. Cette supervision SAM repose sur lutilisation dindicateurs visualisant et synthtisant des mesures prises sur des services unitaires. La difficult est de fournir une console unifie permettant doffrir diffrentes vues en dtail ou en synthse adaptes
Consommateur
Bus de message SOA
Contrle & Mesure Interface
Implmentation
Indicateurs
Alertes
Facturation & pnalits
Figure 6.4 La supervision de la qualit de service, ou SAM

1. La terminologie anglo-saxonne utilise le terme service registry . 2. La terminologie anglo-saxonne utilise le terme Business Process Management (BPM) . 3. La terminologie anglo-saxonne utilise le terme Enterprise Information Integration (EII) . 4. La terminologie anglo-saxonne utilise le terme Business Activity Monitoring (BAM) et on introduit par analogie le SAM, Service Activity Monitoring .
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.
La planification des capacits de linfrastructure

Une vision futuriste, prne par les cabinets de veille (Gartner, etc.) et les grands diteurs, met en avant la possibilit non seulement de dtecter mais encore danticiper sur lvolution des performances. On parle alors danticipation de la demande1. Cette vision est en fait le point de jonction entre deux tendances lourdes de linformatique : lapproche SOA dune part, et le concept de grille de calcul virtuelle dautre part. Le concept de grille dsigne simplement la possibilit de considrer lensemble des composants de linfrastructure (PC, CPU dun serveur multi-processeurs, bande
1. La terminologie anglo-saxonne parle de Capacity Planning.
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
Bux de message SOA
Interface
Implmentation
Indicateurs
Alertes
Facturation & Pnalits
Adaptation
Allocation de Ressources
Figure 6.5 Supervision et capacity planning
6.2.2 Rle dun registre de service

Ds que le nombre de services homologus devient important, le dialogue entre consommateurs (les dveloppeurs dapplications composites et de services composs) et pourvoyeurs de services devient de plus en plus difficile en point point.
Dans une multitude de services, comment un ventuel consommateur sait-il seulement que le service dont il a besoin existe dj ? Rpondre cette question, conduit au concept de registre de services, ou annuaire.
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).
6.2.3 Laccs aux rfrentiels (services CRUD)

Il sagit dun distributeur de requtes et dinformations. Une nouvelle gnration dETL1 orient service (baptise solutions EII/ECI2 suivant les diteurs) merge pour faciliter lagrgat voire la synchronisation temps rel de services dinformations ou de contenus distribus sur plusieurs sources dans le back-end du SI. Ceci permet de rpondre des besoins de haute disponibilit, en lecture (voire en criture), sur les donnes des rfrentiels de lentreprise. Ces solutions permettent aussi la fabrication rapide de la mise en correspondance entre des vues logiques et des donnes ( linstar des modles conceptuels de donnes) en les exposant comme autant de services. Ainsi il devient possible de centraliser en un seul point les rgles de SLA, de suivi (ou gouvernance) et de mise en cache de donnes rparties. Cet intermdiaire apporte ainsi laccs plusieurs sources via une seule requte et dispose de technologies complmentaires aux ETL, EAI ou BPM3 tels que la gestion de cache, de la scurit, de lindexation ou de loptimisation de requtes distribues. Reste alors grer lexternalisation et la conservation de tous les descripteurs dinformation ainsi que les contextes de services. Souvent baptiss outils de MDM4
1. Extraction Transformation Load : outil dextraction, de transformation et de rechargement de donnes. 2. Enterprise Information/Content Integration. 3. Business Process Mangement : outil dautomatisation des processus. 4. Master Data Management.
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.
6.2.4 Gestion et supervision des processus mtiers (BPM et BAM)2

Une infrastructure de gestion des processus mtiers SOA (encore appel Business Process Management BPM) englobe plusieurs composants : La modlisation amont des processus mtiers. Celle-ci comporte, en gnral, une description des dactivits dun processus (sa squence interne), dont certaines pourront se rduire invoquer un service ou une composition de services implmente de faon programmatique. Lexcution des processus mtiers. Il sagit de lorchestration de processus dcrite prcdemment, traitement des vnements mtiers, sollicitation dun utilisateur humain ou dun service (automatique) pouvant recouvrir lui-mme une orchestration de services, une intgration un ou plusieurs systmes back-end, etc. Le suivi et lexploitation aval des processus mtiers (pilotage de la performance oprationnelle ou technologique dont le suivi de lexcution des services). Les outils de BAM se basent sur les fonctionnalits de SAM pour : La consultation de ltat des processus. La consultation ou ldition de statistiques la vole : par exemple, combien de processus de tel type sur telle priode, combien dexceptions traites actuellement par telle personne ? Ceci doit pouvoir se personnaliser laide de tris et de filtres, que doit pouvoir effectuer un responsable oprationnel laide de son propre poste de travail (cf. le chapitre 9 de la partie 3). La gestion dalertes : Par exemple, un processus bloqu depuis plus dun certain temps doit-il dclencher un processus alternatif ou une action humaine. Il peut y avoir par ailleurs un aspect plus dcisionnel, comme ltablissement de statistiques agrges sur plusieurs axes, construites en temps diffrs ou ncessitant un gnrateur dtat. Un outil de BAM peut senvisager directement cbl au systme dinformation, mais pourra tirer toute sa valeur ajoute quune fois intgr au systme de gestion des processus mtiers en y capturant et en reconsolidant les vnements mtiers. Cela implique en gnral le recours un moteur de rgles (BRM3) ainsi quun serveur de traitement des vnements (CEP4). Le moteur BRM permet de dfinir des rgles mtiers, au travers dune console dassistance, effectuant des filtrages ou fonctions de corrlations sur une base dvnements et messages mis ou reus capturs par le
1. Certaines solutions globales se proclament alors EIMS (Enterprise Information Management System). Elle propose daller du connecteur SQL orient service jusquau MDM avec gestion de variantes des dfinitions et une rconciliation des smantiques sans oublier un gnrateur unifi de requtes vers des sources multiples. 2. Business Activity Monitoring. 3. BRM (Business Rules Management). 4. CEP (Complex Event Processing).
6.3 La chane de fabrication SOA
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.
6.3 LA CHANE DE FABRICATION SOA

Une architecture SOA devra sappuyer sur le triptyque suivant : des applications composites et des services; une infrastructure dchange;
Portail
Application Composite Application Composite
Moteur BPM (orchestration) Processus Mtier
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
Chane de fabrication SOA
Figure 6.6 La chane de fabrication complte de la plate-forme SOA
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).
6.3.1 Industrialiser pour mieux livrer

linstar du mode de fabrication rencontr dans lindustrie, les outils ncessaires aux dveloppeurs, testeurs, responsable dinterface homme machine, responsable mtiers, responsable qualit, architectes, etc., se fdrent progressivement autour dune chane plus ou moins automatise de fabrication des services. Les services ainsi raliss en bout de chane suivent un certain nombre dtapes systmatiques (voire automatiques), ils sont tests, fiabiliss et rpondent aux exigences suivant la mthodologie retenue par lentreprise pourvoyeuse de services. En outre, il pourra savrer plus ou moins ncessaire, selon le volume de services, ainsi que la diversit et lactivit des quipes, de fdrer cette chane autour dun rfrentiel homogne. Ce rfrentiel servira ds la conception des services (on parle alors de catalogue de services lorsquil sagit dlments principalement descriptifs et informationnels ou dannuaire lorsquil sagit dlments relis au code source et/ou la gnration de code). Le rfrentiel peut encore stendre jusquau dploiement et lexcution des services (on parle alors de registre de services ). Il permet ainsi de grer en cohrence plusieurs vues et profils dintervenants autour du cycle de vie de chaque service (par exemple, la vue de lanalyste et des cas et impacts dutilisation, la vue du concepteur, du testeur, et de larchitecte, la vue de conformit aux rglementations, la vue des statistiques dutilisation pour le pilotage etc.). On notera que si ce type de rfrentiel peut initialement samorcer aisment laide dun simple serveur de fichiers ou dun wiki collaboratif, il devra progressivement voluer en proposant en amont une structuration des donnes gres, ainsi quen aval des tableaux synthtiques et cohrents pour chaque profil agrgeant une ou plusieurs sources dinformations parfois distribues selon le patrimoine ou la complxit de limplmentation retenue par lentreprise. Cette chane doit donc se concevoir, se fiabiliser et se prenniser au fur et mesure des projets du programme SOA de lentreprise (cf. le chapitre 11 de la partie 3). Autrement dit, il ne faut pas ncessairement chercher la chane idale ds le premier projet.
1. La terminologie anglo-saxonne est celle de software factory .
6.3 La chane de fabrication SOA
77
6.3.2 Modliser pour mieux rutiliser

Lapproche SOA peut parfois donner tendance croire que le mot dveloppement est condamn disparatre. Force est de reconnatre quil faut quand mme encore dvelopper, ne serait-ce que des faades dappels des implmentations existantes. ce titre, il est important de constater que si la fabrication de services sur de nouvelles implmentations peut rester assez naturelle et directe, celle de services construits sur des implmentations existantes pourra, dans certains cas dimbrications, ncessiter un travail important de rcriture voire de migration de ces applications trop monolithiques . Il ny a donc pas de miracle ! De toute faon, un dveloppeur sera au moins prsent pour les services mtiers pivots (mme sils encapsulent laccs aux rfrentiels ou des moteurs de rgles) ainsi que pour les nouvelles applications composites orientes services . Sur le plan de la modlisation, SOA est un aboutissement des dmarches entreprises pour concevoir des architectures objets. Architecte et Responsable de dveloppement peuvent donc envisager pour certaines Applications Orientes Services une assistance la gnration du code depuis une modlisation pralable : cest le rapprochement souhaitable entre lapproche MDA1 et lapproche SOA, dcrite au chapitre 11 de la partie 3.
6.3.3 Paramtrer la supervision

Les outils de SAM et BAM sont associs un atelier de paramtrage. Celui-ci doit en outre permettre de : dcrire les indicateurs clefs de la performance mtier, notamment dans le squencement des processus mtiers, ainsi que dans le suivi des directives contrler et leurs paramtres possibles pour chaque service mtier, (intensit de sollicitation, temps entre activits, statuts du processus, etc.); dtablir un mode de relev (par exemple via agent ou modle de collecte intermdiaire); de choisir un mode des rendus : via des reprsentations statiques proposant des tableaux ou rapports exportables en tableur, PDF ou donnes brutes, etc.; via des reprsentations interactives ddies ou unifies au sein dune interface homme-machine de type Portail, Frontal dcisonnel ou console permettant plus facilement de descendre plus ou moins en profondeur dans la supervision; de choisir le mode dalerte (par messages de type e-mail, SMS, bote de dialogue sur lcran dun oprateur, nouveau processus ou services dclencher, etc.). Le
1. Approche Model Driven Architecture (MDA).
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
SOA : tout repose sur la mthode

Lobjectif de cette partie est de fournir un guide pratique permettant de vaincre le syndrome de la page blanche lors du lancement dun projet SOA : comment dbuter puis mener bien un tel projet ? Comment modliser services et applications composites ? Quest-ce quun Processus Mtier dans le contexte SOA ? Comment organiser un projet SOA ? Quels sont les piges viter ? Quels sont les thmes sur lesquels matrise douvrage et matrise duvre doivent collaborer troitement ? Telles sont les exemples de questions auxquelles cette partie se propose de rpondre. Pour dbuter un projet, il faut dabord en dfinir le primtre au sein du systme dinformation : le chapitre 7 montre que raisonner en terme dapplication nest plus suffisant et propose le concept de solution mtier pour remdier cette insuffisance. Il sagit ensuite danalyser et de modliser larchitecture mettre en uvre. Pierre angulaire de lapproche SOA, cette dmarche a pour objectif de dcrire les choix structurants en terme de composants construire, avec leur typologie, et les relations entre ces composants. Il sagit de guider ainsi les responsables de projet et les architectes dans leur dmarche de spcification, de modlisation et de choix doutils.
80
SOA : tout repose sur la mthode
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.
7.1 APPLICATION OU SOLUTION MTIER ?

7.1.1 Le point de dpart
Pour dbuter un projet informatique, il est ncessaire den connatre la cible. Pour cela, on raisonne en gnral en terme de besoin, et de rponse ce besoin en terme dapplication : application de gestion des commandes, application de gestion du catalogue produit, application de centre dappel, etc. Quest-ce qui caractrise une application ? Elle est la fois : une unit mtier : 1 application = la rponse 1 attente majeure dune ou plusieurs directions mtier; une unit organisationnelle au sein de la direction des tudes : 1 application = 1 projet raliser, 1 ligne budgtaire identifie, 1 quipe ddie; une unit technique au sein de la direction de larchitecture et des outils : 1 application = 1 architecture et des outils de dveloppement; et une unit au sein de la direction de la production : 1 application = 1 infrastructure matrielle et logicielle de base complter et intgrer, puis 1 excutable dployer, administrer et supporter.
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.
7.1.2 Que devient alors la notion dapplication ?

Application = services ? Mais dun point de vue mtier, ce qui intresse les utilisateurs, ce ne sont pas les services mais bien les applications composites dont ils sont amens se servir, et qui automatisent tout ou partie des processus mtier. Un service en soi nest en effet pas directement utilisable sur le plan des usages mtier, il nintresse les utilisateurs quau travers de ces fameuses applications composites. Il est alors tentant de poser application = application composite. Mais on ne peut dployer une application composite sans que les services dont elle est cliente soient eux-mmes dploys. Dautant que certains services nexistent peut-tre pas encore. De plus, il ny a pas ncessairement une seule application composite mettre en place pour satisfaire le besoin mtier, mais plusieurs applications composites : processus mtier, application interactive permettant aux utilisateurs finaux dintervenir dans les processus ou de traiter les exceptions leves par ces processus, application back office permettant dadministrer les rfrentiels et les processus mtier, etc.
7.1.3 Le concept de solution mtier

Il devient donc ncessaire de raisonner en terme de solution mtier. Une solution mtier regroupe les diffrents macro-composants ncessaires la satisfaction des besoins utilisateurs. Une solution mtier regroupera donc : Le ou les processus mtier qui organisent le traitement des vnements mtier reus par lentreprise, et peuvent tre plus ou moins automatiss. La ou les applications interactives front office qui outillent les processus mtier, et permettent aux utilisateurs finaux de participer au traitement des vnements mtier. La ou les applications composites back office qui permettent dadministrer les rfrentiels (en particulier, les applications de mise jour des codiers1 et rfrentiels de paramtrage) et les processus mtier (en particulier, les applications de monitoring des processus). Les services utiliss par les diffrentes applications composites, notamment les services mtier.
1. Les codiers sont les rfrentiels permettant de centraliser et de mettre jour les diffrentes nomenclatures utilises dans lentreprise.
7.1 Application ou solution mtier ?
83
Les rfrentiels accds par les services. Les ressources techniques utilises par les applications composites ou par les services.
7.1.4 La caractristique principale dune solution mtier

Par rapport au concept classique dapplication, la solution mtier garde donc bien une unit mtier : elle regroupe tout ce qui est ncessaire la satisfaction du besoin mtier. Mais sur le plan de la direction informatique ? La solution mtier nest plus vraiment une unit de dploiement physique, car tout ou partie des rfrentiels, des ressources techniques, et surtout des services utiliss est sans doute dj ralis et physiquement dploy. Et cest certainement un des avantages de larchitecture SOA que de permettre la rutilisation de ce qui fonctionne dj en production. La solution mtier nest pas non plus une unit technique en soi, car lun des objectifs de SOA est bien de mettre en place une infrastructure logicielle rutilisable entre les diffrentes solutions mtier : autrement dit, ce nest pas la solution mtier de dfinir sa propre architecture (Web Services versus EJB), dassembler son propre framework applicatif, de choisir ses outils (ESB), etc. Chaque solution doit
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.
7.2 PRSENTATION DU CAS DCOLE

Ce paragraphe prsente le cas dcole qui nous servira de fil rouge, puis prsente la solution mtier que ce projet fil rouge doit livrer aux utilisateurs finaux.
7.2.1 Lentreprise concerne

Lentreprise concerne est un distributeur dnergie (gaz et lectricit) dEurope de lOuest. Ses clients sont soit des particuliers, soit des entreprises, PME et grands comptes. Le mtier de cette entreprise est donc (i) de grer et maintenir un rseau de distribution de fluide sur son territoire de chalandise, (ii) dinstaller chez ses clients des Points De Distribution (PDD) branchs sur son rseau, et (iii) de facturer la consommation releve dans chaque Point De Distribution. Cette entreprise est ce quon appelle gnralement un oprateur de rseau. Jusqu prsent, cet oprateur distribuait lnergie fournie par le monopole national de production dnergie, dont il tait de facto une filiale. Son systme dinformation tait donc intgr dans celui du monopole, puisque ses clients taient exactement ceux du monopole de production.
7.2.2 Contexte mtier

Sous la pression des instances europennes, la libralisation du march de lnergie est en route, et notre oprateur de rseau doit souvrir des producteurs alternatifs.
7.2 Prsentation du cas dcole
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.
7.2.3 Objectifs du projet

Loprateur souhaite mettre en place dans une premire tape un portail destin aux producteurs. Ce portail permet un producteur de demander un service loprateur, tel que la mise en place dun nouveau Point De Distribution, ou la consultation des relevs de consommation associs un PDD. La mise en place du portail saccompagne de la mise en place des processus back office de traitement de ces demandes. Il sagit par exemple de planifier et lancer les interventions des quipes techniques dintervention sur les PDD. Pour cela la solution mtier sappuie sur des applications existantes (planification des interventions, gestion des comptes-rendus dintervention). Le premier objectif mtier est donc de permettre un producteur dmettre manuellement ces demandes de prestation via des formulaires proposs par le portail, et de traiter ensuite ces demandes. Dans une seconde tape, il sagit de faire face laccroissement prvisible des demandes de prestation, accroissement li louverture aux particuliers. Loprateur souhaite donc relier directement le systme dinformation de chaque producteur son propre systme dinformation. Le deuxime objectif mtier du projet est donc que chaque producteur envoie directement ses demandes via un protocole spcifique du monde de lnergie (protocole standard bas sur XML). Formul autrement : il sagit de mettre en place un accs multi-canal loffre de prestations de service de loprateur de rseau. Quel que soit le canal dacheminement de la demande de prestation, loprateur souhaite ne pas multiplier ses quipes commerciales : le troisime objectif mtier est de rechercher une automatisation maximale des processus de traitement des demandes de prestation. Le dernier objectif mtier est bien videmment doptimiser les cots et encore plus les dlais du projet.
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).
7.2.4 Cas dutilisation gnral

Scnario dusage
Les diffrentes tapes du scnario gnral dutilisation de PORTOS sont : tape 1 : Via le portail, un producteur dment authentifi demande une prestation : Lutilisateur peut sinterrompre en cours de saisie (concept de demande brouillon ). Lutilisateur peut galement consulter un certain nombre dinformations : sur les demandes en cours, sur les PDD qui lui sont affects, sur les relevs de consommation associs ses PDD, etc. tape 2 : PORTOS enregistre la demande et cre un processus mtier automatis de traitement de la demande. tape 3 : Le processus planifie les interventions des quipes techniques sur le terrain, puis lance ces interventions (envoi de message lquipe concerne en temps et en heure). tape 4 : Chaque producteur peut demander au systme ltat davancement de chacune de ses demandes. Ceci implique donc lexistence dune base historique des demandes . tape 5 : Le systme avertit le fournisseur par mail de certains vnements mtier : refus de la demande, fin de traitement de la demande.
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.
7.2.5 Contenu de la solution mtier

La solution mtier PORTOS comprendra donc au moins les composants suivants : Application interactive : demander une prestation. Processus mtier : traiter automatiquement une demande de prestation. Application interactive : rechercher une demande dj transmise. Application interactive : consulter ltat dune demande particulire. Application interactive : rechercher les Points De Distribution utiliss par le producteur. Application interactive : consulter les relevs de consommation associs un PDD. Services : services mtier daccs linformation. Services : services dinterface avec les systmes existants. Rfrentiels mtier : demandes, PDD, relev de consommation, identits des utilisateurs du portail nous ne prcisons pas ici si ces rfrentiels sont dupliqus ou non, cette problmatique sera aborde dans le chapitre 8. Si une dcision de duplication tait prise, la solution mtier devrait intgrer une application de rplication de donnes. Rfrentiel technique : journal de bord de lutilisation du systme.
7.2.6 Architecture gnrale envisage

La figure 7.2 prsente larchitecture trs gnrale de la solution envisage. Cette architecture tient compte ds le dpart de la contrainte de scurisation, sparant et isolant front office et back office. Les applications interactives seront intgres un portail qui assure ses utilisateurs un accs homogne sur le plan ergonomique, unifi sur le plan de la scurit daccs, et intgr sur le plan technique. Le portail assure galement laccueil et linformation des utilisateurs. Cette information concerne aussi bien les services offerts via le portail (informations marketing et commerciales, informations juridiques, accs dautres sites web, etc.), que le mode demploi de ces services (guides dutilisation, FAQ). Les demandes envoyes automatiquement via un flux XML seront accueillies par un serveur baptis Frontal XML . Ce frontal effectue les tches suivantes : sauvegarder tous les flux reus, afin de garantir quaucune demande ne sera perdue ds lors quelle est reue par loprateur de rseau;
88
7. Dfinir la cible
Producteur dnergie
Envoi automatique dune demande de prestation
Utilisateur du portail (FRONT OFFICE) Internet
Frontal XML
Portail
Distributeur dnergie
Processus
Services
Administrateurs Processus & Administrateur Rfrentiels (BACK OFFICE)
Accs existant
Rfrentiels
Figure 7.2 Architecture gnrale de la solution mtier PORTOS
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.
8.1 ARCHITECTURE DE SERVICES : LES QUESTIONS CLEF

8.1.1 La typologie des services
La premire question concerne la typologie des services : existe-il plusieurs catgories de service ? La rponse est clairement oui. Rgle : on distinguera (i) les services mtier et (ii) les services techniques.
92
8. Modliser les services
Les services mtier

Le rle dun service mtier est doffrir un ensemble cohrent de traitements mtier : cela peut concerner par exemple laccs la vision client (obtenir un ensemble synthtique dinformation sur le client, ltat de ses comptes, lhistorique de ses relations avec lentreprise), ou la simulation dun crdit immobilier, ou le calcul dimpts et de taxes diverses, etc. Un service mtier peut tre soit un service daccs des informations, soit un service de calcul et de vrification de rgles mtier, soit une composition des deux.
Les services techniques

Le rle dun service technique est de donner accs une ressource technique donne : on citera par exemple laccs aux bases de donnes relationnelles, au CICS dun mainframe, une imprimante, un systme de GED, un outil de log, une messagerie, un EAI, etc. Un service technique est trs souvent gnrique : il nest pas li une ressource particulire mais une catgorie de ressources. Par exemple, un service dimpression ne sera pas li une imprimante particulire, mais une catgorie dimprimante : il prendra en paramtre ladresse de limprimante sur laquelle sortiront les informations imprimer. Un service mtier peut sappuyer sur un ou plusieurs services techniques pour excuter ses traitements. Un service mtier synthse de la vision client pourra par exemple sappuyer sur un service technique daccs SQL, sur un service technique daccs CICS (si on suppose que les informations ncessaires cette synthse sont rparties entre des rfrentiels lgataires sur mainframe et des rfrentiels plus rcents sous SGBDR), et sur un service technique dimpression.
8.1.2 La granularit des services

La seconde question concerne la granularit des services. Le terme de granularit a t introduit lorsque les vanglistes de lobjet ont constat sur le terrain que modliser un objet client ou un objet facture ntait pas de mme nature que modliser un objet adresse lectronique : les premiers sont des gros objets, et contiennent eux-mmes dautres objets, alors que les seconds sont de petits objets, avec peu dattributs. On parle dobjets gros grain et dobjets grain fin , traduction de lamricain coarse grain et fine grain . On retrouve la mme problmatique dans le monde SOA : il y a des services gros grain et des services grain plus fin. Les services gros grain accdent aux services grain fin pour effectuer leurs traitements. Le paragraphe suivant approfondit cette rflexion en proposant une typologie des services mtier, lie leur granularit.
8.2 Modliser les services
93
8.2 MODLISER LES SERVICES

Lobjectif de ce sous-chapitre est de proposer une dmarche de modlisation montrant concrtement comment merge, tape par tape, une typologie hirarchique de services, lie la granularit de ces services. On illustre ces tapes au travers du fil rouge, mais en prcisant demble que cette dmarche et surtout ses rsultats sont dsormais suffisamment prouvs pour que lon puisse en garantir lapplicabilit la plupart des projets SOA, notamment dans le monde de la gestion. On sintresse donc principalement aux services mtier.
8.2.1 tape 1 : les services CRUD

Les services mtier qui mergent spontanment au dmarrage dun projet SOA sont les services CRUD (acronyme anglais qui signifie Create Read Update Delete). Ces services permettent de crer, rechercher, mettre jour et supprimer de linformation dans les rfrentiels du systme dinformation. Comment modliser ces services ? Chaque service CRUD est associ un objet mtier racine 1, et offre lensemble des oprations permettant de crer, rechercher et mettre jour les instances de cet objet mtier. Mais quest-ce quun objet mtier racine ? Cest un objet mtier qui constitue un point dentre dans le systme dinformation. Par exemple, le Client, le Contrat liant lentreprise et le client, la Commande, le Catalogue des produits, la Facture peuvent tre autant dobjet mtier racine . A contrario, ladresse bancaire dun Client sera un objet mtier mais ne sera pas un objet racine du systme dinformation. En terme dUrbanisation, on peut dire quun bloc durbanisation est en charge de grer un objet mtier racine2 et repose sur un ensemble doprations CRUD, regroupes dans un service. Un service CRUD se focalise donc sur les oprations universelles de manipulation de linformation. Ces oprations sont : Crer un nouvel objet mtier racine (plus exactement crer une nouvelle instance de la classe mtier) : par exemple, crer le client [nom prnom] est une opration offerte par le service CRUD associ lobjet mtier client .
1. Du point de vue informationnel, un objet mtier est une catgorie, ou classe, dindividus ayant les mmes attributs et obissant aux mmes rgles de gestion mtier. Un individu tant une chose concrte (un contrat) ou abstraite (un intervalle de temps), une personne concrte (personne physique) ou abstraite (personne morale), un lieu Du point de vue technique, un objet mtier logiciel est construit avec le concept de classe des langages objet. On parlera dinstance pour dsigner un individu appartenant la classe, sur le plan informationnel comme sur le plan technique. 2. Ou un petit nombre dobjets mtier racines fortement lis entre eux, comme la Commande et la Ligne de Commande, ou le Catalogue produit et ses Rubriques.
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.
tape 1 bis : les services techniques

Certains services techniques mergent galement trs rapidement, en liaison avec les services CRUD (cest pourquoi on parle dtape 1 bis), comme par exemple les services de communication avec les systmes existants, les services daccs aux rfrentiels SQL, et les services de gestion de log.
Application au fil rouge

La figure 8.1 illustre lapplication de ltape 1/1 bis sur lexemple fil rouge . La figure met en vidence la ncessit de scuriser laccs aux services offerts par le systme dinformation. De ce fait, le portail est situ dans une zone dmilitarise (DMZ), et le dialogue entre portail et service doit franchir le pare-feu, ce qui conduit utiliser de prfrence les web services, cest--dire HTTP, comme protocole de communication (par rapport dautres outils tels que les EJB Session par exemple)2. Dans cette architecture, pour traiter une demande de prestation, le portail accde via les services CRUD aux rfrentiels pour (1) vrifier les droits de lutilisateur, (2) sauvegarder la demande de prestation, (3) accder la base Contrat pour vrifier que la demande correspond bien aux termes dun contrat valide entre lOprateur et le Demandeur, (4) accder au Gestionnaire de Processus pour crer un nouveau processus automatis de traitement de cette demande, (5) envoyer si besoin un mail un responsable commercial de lOprateur (6) enregistrer des logs si besoin. Le portail peut galement rechercher des informations sur les Points De Distribution, sur ltat dune demande, etc.
1. Lopration de suppression ne doit pas tre supprime, car elle peut tre utilise, par exemple en phase dintgration, par une application de purge des rfrentiels de tests. 2. On consultera avec profit le livre de rfrence : Scurit des Architectures Web, G. PLOUIN et alii, DUNOD diteur, 2004.
95
Portail
Accs scuris Web Service
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.
Analyse des tapes 1 et 1bis

Larchitecture obtenue met en vidence lissue de ces tapes un socle de services que lon pressent comme fortement rutilisables. Un premier pas important est donc franchi mais quels sont les dfauts de cette architecture ? Le premier problme concerne les performances et provient de la granularit trop fine des services mis en place. Une telle architecture conduit en effet multiplier les appels aux (web) services CRUD et aux (web) services techniques. Ceci se traduit par une utilisation intensive des outils de traduction [message XML objets mtier
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.
8.2.2 tape 2 : Les Services Applicatifs

Ltape 2 de la dmarche propose vise donc rsoudre ces problmes. Elle consiste mettre en place des services faades, cest--dire des services de haut niveau qui masquent aux applications composites les services CRUD, de trop bas niveau.

La figure 8.2 illustre le propos. On cre un service faade enregistrer demande , service qui est appel par le portail une fois quun utilisateur a rempli puis valid un formulaire de demande de prestation. Les services mis en place sont des services de haut niveau, directement lis aux applications composites concernes. Cest pourquoi on parlera de Services Applicatifs. Une application dlgue donc un ou plusieurs Services Applicatifs le soin de coordonner les appels aux services CRUD et aux services techniques, et limplmentation des rgles de gestion mtier.
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
5 Service Applicatif Processus
EnregistrerDemande
CRUD
CRUD
CRUD
Ressource
Ressource
Ressource
Utilisateurs
Demandes
Contrats
Messagerie
Journal de Bord
EAI
Figure 8.2 Deuxime tape : mergence des Services Applicatifs
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.
8.2.3 tape 3 : Les Services Fonctionnels

La dernire tape vise donc mettre en place des Services Mtier encapsulant tout ou partie des rgles de gestion et des traitements mtier. On les appellera de ce fait des Services Fonctionnels, par analogie avec les fonctions mtier qui regroupent dans les systmes classiques un ensemble cohrent de rgles et traitements mtier. Un Service Fonctionnel sappuie le cas chant sur un ou des services CRUD pour lire les informations mtier dont il a besoin et/ou sauvegarder les informations mtier quil a modifies/cres.

La figure 8.3 illustre le propos sur notre fil rouge , en mettant en vidence trois services fonctionnels : Un Service Fonctionnel associ la gestion des demandes. Un Service Fonctionnel associ la cration dun nouveau processus mtier afin de traiter une nouvelle demande.
Portail
Service Applicatif
Processus
enregistrerDemande 5 2 Service fonctionnel Service fonctionnel Service fonctionnel
creerDemande verifierDemande 3 6
planifierRDV confirmerRDV
creerProcessus 4
CRUD
CRUD
CRUD
Ressource
Ressource
Ressource
Utilisateurs
Demandes
Contrats
Messagerie
Journal de Bord
EAI
Figure 8.3 Troisime tape : mergence des services Fonctionnels
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.
8.2.4 Synthse de la dmarche : modliser larchitecture de services

La figure 8.4 illustre le rsultat de cette dmarche.
Applications Interactives
Applications Composites
Application Interactive Front Office
Application Interactive Back Office
Processus Mtier
SA SF SF
CRUD
CRUD
CRUD
CRUD
Ressource
Ressource
Accs Ressource
Accs Accs Ressource
Accs Ressource
Accs Ressource
Accs Ressource
Accs Ressource
Rfrentiels & Ressources
Figure 8.4 Synthse de larchitecture propose
8.3 Zoom sur les services CRUD
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.
8.3 ZOOM SUR LES SERVICES CRUD

Les services CRUD jouent un rle important dans une architecture SOA. Ce chapitre propose une description plus dtaille de ces services.
8.3.1 Quelles sont les oprations offertes par un service CRUD ?

Un service CRUD est, rappelons-le, associ un objet mtier racine , et rsulte de la ncessit pour une application SOA dinterroger et de mettre jour le(s) rfrentiel(s) dans lequel sont enregistres de faon persistante les informations dcrivant les instances de cet objet mtier. Un tel service offre en gnral les oprations suivantes : Crer un nouvel objet mtier dans le rfrentiel concern. Rechercher un ensemble dobjets mtier selon des critres de recherche : par exemple, rechercher lensemble des clients avec le critre {habite dans la commune identifie par le code postal 91190} . Lire un objet mtier selon une clef daccs unique, que ce soit une clef technique (exemple : primary key dun SGBDR), ou une clef mtier (exemple : numro de scurit sociale). Lire une collection dobjets mtier selon une collection de clefs daccs uniques : il sagit dune variante batch de lopration prcdente, qui permet doptimiser la performance de la recherche en base de donnes. Mettre jour un objet mtier. Archiver un objet mtier ou un ensemble dobjets mtier. Certains architectes prfreront sparer dans deux services distincts ce qui relve de la Recherche dans les rfrentiels (opration de Lecture et de Recherche), et ce qui relve de la Mise jour de ces rfrentiels, autrement dit, avoir un service R et un service CUD . Ceci pour mieux contrler laccs aux services de mise jour, critiques quand au maintien de lintgrit des rfrentiels. On peut galement, en fonction des besoins, ajouter des oprations, qui sans tre strictement CRUD, nen sont pas moins fort utiles, comme : Imprimer un objet mtier.
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.
8.3.2 La signature des oprations CRUD

La signature dune opration regroupe le nom de cette opration, et la liste de ses paramtres dentre et de sortie. Sinterroger sur la signature des principales oprations CRUD permet de mettre en vidence quelques questions clefs concernant lefficacit de ces oprations.
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.
8.3.3 Services CRUD et rfrentiels mtier

Position du problme : partager ou rpliquer ?
Les services CRUD ont pour mission daccder aux rfrentiels de lentreprise. Mais ces rfrentiels sont-ils centraliss, ou rpliqus ? La question peut se poser de faon plus gnrale : les solutions mtier partagent-elles le(s) mme(s) rfrentiel(s) mtier, ou pas ? Si lon reprend lexemple fil rouge , on voit que la solution mettre en place grera son propre rfrentiel demande de prestation , mais elle aura besoin daccder (au moins en lecture) aux informations Fournisseurs et contrats , Points de Distribution , Relevs de consommation . Or ces informations existent probablement dj dans des rfrentiels du Systme dInformation, chaque rfrentiel tant gr par une application responsable de sa mise jour.
Solution SOA P Existant A Existant B
Partager les informations
Solution SOA P Existant A Existant B Rpliquer les informations
Rplicateur
Figure 8.5 Partage ou rplication des rfrentiels mtier
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
Rpliquer & Agrger les informations
Agrgateur
Figure 8.6 Rplication + agrgation des rfrentiels mtier

1. Ces silos sont : le SI commercial (qui donne la vision contractuelle), le SI facturation (qui donne ltat des paiements du client vis vis de la facturation), le SI Contentieux (qui dit si le client est ou a t en situation de contentieux), le SI Marketing (qui retrace lhistorique des offres promotionnelles envoyes au client), etc.
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.
8.3.4 Un service CRUD nest pas un DAO !

Nous terminerons cette synthse sur les services CRUD par une remarque importante : limplmentation dun service CRUD ne se rduit pas simplement lcriture dune requte SQL et la transformation du rsultat de cette requte en un ensemble dobjets Java ou C# ! Prenons par exemple une opration de mise jour du Compte Client. Comme lillustre la figure 8.7, cette opration peut inclure : Lexcution de rgles mtier contrlant lintgrit des donnes mises jour. La vrification pralable que les rfrentiels accds fonctionnent correctement (pour faire face une panne, cf. prcdent). Lappel au service de persistance pour mettre jour la ou les tables du rfrentiel compte client . Lappel au service de persistance pour mettre jour une table daudit, permettant de tracer lcriture, la date dexcution, lutilisateur concern ventuellement, lappel un service technique pour lenvoi dun message un responsable commercial. Rgle : un service CRUD nest pas simplement un DAO (Data Access Object)a, mais bien un vritable Service Mtier.
a. Le concept de DAO est un des patterns architecturaux proposs dans le cadre de J2EE.
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
Appliquer les rgles dintgrit Vrifier la disponibilit des rfrentiels
Mettre jour Compte client
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
Figure 8.7 Un service CRUD est un vrai service mtier !
8.4 ZOOM SUR LES SYSTMES EXISTANTS

Laccs aux systmes existants est un thme rcurrent de toute dmarche SOA, puisque lun des avantages de cette dmarche est prcisment de valoriser/rutiliser ces systmes existants, en vitant une refonte big bang du systme dinformation le plus souvent irraliste. Les services mtier mis en place doivent donc accder aux informations et traitements implments par ces systmes existants. Certains services mtier ne seront mme que de simples faades. Un service faade est un intermdiaire qui permet ses clients (applications ou services de haut niveau) raliss en nouvelles technologies daccder des fonctions mtier existantes sans se soucier de lhtrognit technologique. Comment alors concevoir ces faades ? Rgle : il y a deux grands types de solution architecturale pour intgrer faades SOA et applications existantes : une solution dite dcentralise et une solution dite centralise .
8.4 Zoom sur les systmes existants
109
8.4.1 Intgration dcentralise

La solution dcentralise consiste faire voluer le systme existant pour quil offre lui-mme les faades, par exemple sous forme de web services. Les faades seront galement appeles services lgataires. Dans ce type de solution, les services de haut niveau (applicatif ou fonctionnel) accdent alors ces services lgataires de faon homogne, comme ils accdent aux services CRUD, via les mmes middlewares de communication (Web Service, EJB, ESB). Ce type de solution est intressant (voire la seule envisageable) lorsque la solution SOA mettre en place doit accder des sites gographiquement distants et disposant de leur propre informatique locale, comme cest le cas des magasins, des agences, des usines ou encore des entrepts de stockage. Cette informatique locale repose souvent sur des technologies propritaires plus ou moins anciennes, difficiles daccs par les technologies rcentes associes SOA. Comme ces applications locales sont souvent trs efficaces, complexes et bien rdes, il nest pas question de les rcrire : do lintrt de les encapsuler via des services lgataires locaux . Ces services lgataires permettent par exemple de lancer un traitement local (lancement dune fabrication, demande de rassort) ou de rcuprer des informations locales ces sites (tat davancement dune commande, niveau de stock dun produit). Les figures 8.8 et 8.9 prsentent cette intgration dcentralise via des faades, selon que ces faades sont implmentes directement avec la technologie locale ou
Solution SOA Processus Services
Intranet
Middleware daccs
Existant Site local
Service lgataire Java
Appli
Figure 8.8 Intgration dcentralise/service lgataire intgr sur le systme local
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).
Solution SOA Processus Services
Intranet
Middleware daccs
Site local Service lgataire Java, C#
Existant Appli
Figure 8.9 Intgration dcentralise/service lgataire install sur un frontal
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.
8.4.2 Intgration centralise

La solution centralise consiste installer les faades sur un ou des serveurs entourant le mainframe, et encapsuler directement laccs au(x) systme(s) existant(s) dans ces faades.
8.5 Zoom sur les services de haut niveau
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
Service technique Accs Legacy
Accs Legacy
Site central
Existant
Figure 8.10 Intgration centralise via un service technique
8.5 ZOOM SUR LES SERVICES DE HAUT NIVEAU

Spcifier et modliser un service de haut niveau (Service Applicatif, Service Fonctionnel), cest avant tout tudier comment un tel service fait appel dautres services on parle galement de composition de services. Un service faisant appel un autre service obit en premier lieu la rgle de base de SOA : le service appelant utilise le contrat propos par le service appel,
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 :
8.5 Zoom sur les services de haut niveau
113
Type de service Service mtier Applicatif (SA)
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.
Service mtier Fonctionnel (SF)
Moyenne Forte.
Dpend du contexte.
Forte, puisque lorchestrabilit est lun des critres de modlisation de ces services.
Service mtier CRUD
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.
9.1 QUEST-CE QUUN PROCESSUS SOA ?

9.1.1 Bref rappel sur les processus mtier
Un processus mtier dcrit lensemble des activits que lentreprise doit excuter pour traiter un vnement mtier qui lui est adress. Un vnement mtier peut par
116
9. Modliser les processus
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.
9.1.2 Processus Mtier et contexte SOA

Depuis le dbut des annes 90, lapproche workflow a considr essentiellement les processus mtier sous un angle humain : un processus est vu dans cette approche comme orchestrant une suite dinterventions humaines pour traiter lvnement mtier dclencheur.2 Lapproche SOA a pris en compte ds le dpart les processus mtier, en privilgiant une approche entirement automatise : un processus est vu comme un chef dorchestre enchanant une suite dappel des services mtier. On parle dailleurs communment dorchestration de processus. Le concept dactivit est assimil dans ce cas un appel de service mtier, et il ny a plus a priori d homme dans la boucle .
1. Soulignons dailleurs quune activit peut tre plus ou moins dcompose afin de pouvoir tre attribue plusieurs acteurs diffrents. 2. La littrature amricaine parle de human-driven business process management .
9.2 Modliser les processus : les tapes clefs
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.
9.2 MODLISER LES PROCESSUS : LES TAPES CLEFS

Le chapitre prsente les 3 tapes principales de la modlisation dun processus mtier de type e-Business : (1) exprimer le besoin mtier, (2) analyser et complter le processus obtenu et enfin (3) concevoir un modle de processus excutable par un moteur BPEL.
9.2.1 Premire tape : lexpression du besoin

La premire tape de modlisation dcrit le processus avec le point de vue mtier de la matrise douvrage. Le modle rsultant a en gnral deux caractristiques : il dcompose trs finement le processus mtier; il liste les exceptions mtier leves par le processus. Dans le contexte du fil rouge , le modle MOA2 du processus de traitement dune demande de prestation est prsent dans la figure 9.1.
1. BPMN est dsormais sous lgide de lOMG (Object Management Group) pour venir enrichir UML et linitiative BPDM et permettre terme une correspondance notamment avec XPDL visant linterchangeabilit des reprsentations entre outils de modlisation (promu lui par le WfMC). 2. MOA = Matrise dOuvrAge, cest--dire lensemble des utilisateurs et sponsors mtier.
118
Vrifier doublon demande
OK
Vrifier contrat demandeur
OK
Vrifier contentieux demandeur
OK
Exception demande dj traite
Exception demande non autorise
Exception demandeur en contentieux
Envoyer CRR intervention
Demander intervention
Planifier intervention
Calculer cot intervention
tablir facture
Figure 9.1 Modle de Processus/vision MOA
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.
Notifier au demandeur le rejet de la demande via un mail Vrifier recevabilit demande OK OK
Planifier intervention Exception planification impossible
Analyser lexception et recycler la demande, via une intervention humaine Exception intervention impossible Envoyer CRR intervention Demander intervention
OK
Grer facture
Figure 9.2 Modle de Processus/vision MOE
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 .

Processus Mtier nominal
Analyser lexception
Processus Mtier de recyclage
Figure 9.3 Concept de recyclage
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.
9.2.3 Troisime tape : la conception dun processus excutable

La troisime tape de modlisation vise produire un modle de processus excutable par le moteur de processus1. Ce modle est obtenu en appliquant les principes suivants : introduire dans le modle les services de gestion des exceptions;
1. Plus exactement, cette tape vise produire un modle qui, traduit dans le formalisme dexcution (BPEL dans le contexte SOA), sera (i) fonctionnellement complet et (ii) techniquement excutable avec les performances attendues.
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.
Envoyer et sauvegarder lettre refus KO
Time out : pas de rponse du planificateur
Vrifier recevabilit demande
OK
Planifier intervention

OK
Mettre jour tat demande

Signaler lexception un acteur humain Intervention impossible
Planification impossible

Mettre jour tat demande Envoyer CRR intervention

Intervention effectue
Mettre jour tat demande
Demander intervention
Grer facture
Envoyer et sauvegarder facture
Figure 9.4 Modle de processus excutable par un moteur dorchestration
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.
La gestion des time-out

Premier exemple de ce dialogue ncessaire entre MOA et MOE : la gestion des timeout. Admettons par exemple que loprateur de rseau sous-traite certaines interventions sur le terrain une socit de service : dans ce cas, le systme de planification nest plus gr dans le SI de loprateur, mais dans celui de la socit de service. Le processus mtier reste identique, mais cette socit de service doit sengager ce que son systme de planification fournisse une rponse en moins de x secondes, sous peine de pnalit. Ce type de clause fait partie intgrante du contrat de sous-traitance, via le SLA ngocier. Plus gnralement, lorsquun processus mtier fait appel un service offert par un systme extrieur, le contrat de service doit inclure un SLA sur la ractivit de ce service (cf. partie 2).
122
La gestion de ltat du processus

Second exemple du dialogue avec la matrise douvrage : le modle propos par la figure 9.4 introduit des tapes de mise jour de ltat de la demande. En effet, lorsquun processus mtier dure longtemps, il est en gnral impratif, sur le plan marketing, de permettre au demandeur de poser via le portail la question o en est le traitement de ma demande ? . Cela implique de modliser les diffrents tats de cette demande. Un tel modle est prsent par le diagramme dtat UML (simplifi) de la figure 9.5.
Portail
Demande de prestation en cours de rdaction Demande enregistre
Demande recevable
Demande refuse
Intervention planifie
Processus Mtier
Intervention demande
Intervention effectue
Intervention facture
Figure 9.5 Diagramme dtats de la demande de prestation
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.
9.3 Modliser une Architecture BPM dans un cadre SOA
123
9.2.4 Conclusion : rsum mthodologique

Lapproche mthodologique propose pour modliser un processus mtier SOA est rsume par les principes suivants. Tout processus repose sur lorchestration de services mtiers dont la granularit ne doit pas tre trop fine (cf. la distinction orchestration de processus et orchestration de services dcrite prcdemment). Un processus sans exception nexiste pas : le modlisateur doit, pour chaque activit du processus, se poser la question des exceptions possibles. Un processus entirement automatis nexiste pas : la gestion des exceptions implique en gnral de mettre lhomme dans la boucle . Un processus mtier peut en cacher un autre (par exemple, un processus de recyclage des exceptions). Si un processus fait appel un service externe la solution mtier dont il fait partie, le fournisseur de ce service doit sengager formellement sur la qualit de service (performances notamment). Si un processus risque de durer longtemps ( lchelle humaine), il peut tre ncessaire de mettre en place : (a) au sein du processus, une mise jour de ltat du processus aprs chaque activit effectue et (b) une application composite complmentaire permettant au demandeur dinterroger ltat du processus.
9.3 MODLISER UNE ARCHITECTURE BPM DANS UN CADRE SOA

Lintervention dun acteur humain dans un processus e-Business est un problme clef, qui conditionne clairement la validit de lapproche SOA dans ce domaine. Sur le plan mtier, cette intervention comme on la vu est le plus souvent indispensable, car il nest pas possible dautomatiser tous les traitements, en particulier le traitement des exceptions. Sur le plan informatique, se pose la question de la redondance entre workflow traditionnel , et gestion de processus SOA. Autrement dit, peut-on utiliser une infrastructure SOA comme unique outil de gestion de processus, que ces processus soient human driven ou e-business cest--dire automatiss ? Or le standard SOA actuel (BPEL) souffre dun pch originel : la non prise en compte de la dimension humaine1. Ce qui suit propose un modle de solution BPM compltant linfrastructure BPEL pour quelle puisse prendre en compte les interventions humaines dans des processus
1. Cf. la partie 4 pour une prsentation de BPEL sur le plan technique.
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 ?
9.3.1 Comment dterminer lacteur devant intervenir sur un processus ?

Pour rpondre cette question, linfrastructure BPM SOA (cest--dire lorchestrateur de service) fait appel un service de routage. Ce service de routage sappuie sur un service dorganisation et un service de gestion de ltat des processus, comme lillustre la figure 9.6.
1 Modles Processus Routage Orchestrateur
Organisation
Services de gestion des processus
Figure 9.6 Router le processus
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.).
Le service de gestion des processus

Le rfrentiel grant ltat des processus permet de savoir, pour une instance de processus donne, dans quel tat est ce processus, et, si le processus doit faire intervenir un acteur humain, quel(s) est(sont) le (ou les) acteur(s) concern(s). Le service de gestion des processus est le service de type CRUD permettant dinterroger et de mettre jour ce rfrentiel Processus.
9.3.2 Comment un acteur sait-il quil doit intervenir ?

Linfrastructure BPM SOA met disposition de chaque acteur humain une application composite appele Corbeille, traduction libre de Worklist souvent utilis dans le monde anglo-saxon (on parlera aussi dAgenda, ou de ToDoList). La fonction premire du composant corbeille est dinterroger le service de gestion des processus pour connatre les processus sur lesquels lacteur doit intervenir. La figure 9.7 illustre ce fonctionnement.
Applications interactives de gestion des processus
2 Application Composite Interactive
Bureau
Corbeille 4
Modles
Processus
Routage
Orchestrateur
Organisation
Services de gestion des processus
Figure 9.7 Intervenir sur un processus
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
Responsable dune cellule de Gestion ou dun ensemble de cellule (service, dpartement).
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.
9.4 LA SOLUTION MTIER REVISITE

La solution mtier dcrite dans le chapitre 7 voit donc son primtre slargir notablement, en lui ajoutant les composants suivants : lapplication composite daffichage et de correction des exceptions; le processus de recyclage des demandes corriges (et ventuellement les services fonctionnels associs); les services de gestion de lhomme dans la boucle : service de routage, service dorganisation; les rfrentiels associs : base organisation, base des instances de processus; les applications composites corbeille individuelle et corbeille simplifie (et, si besoin, les applications corbeille de groupe et corbeille de supervision ). Il est important de noter que certains de ces composants sont gnriques, cest-dire rutilisables dans nimporte quel processus mtier SOA : il sagit des services et application (corbeilles) orients lhomme dans la boucle . Une fois dvelopps pour une solution mtier, ces composants seront donc fortement rutilisables pour une autre solution mtier. Linvestissement consentir sera donc amorti rapidement.
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.
9.4 La solution mtier revisite
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
10. Modliser les applications composites interactives
10.1 LE MODLE MVC

Depuis les annes 80, le modle MVC est le modle architectural de rfrence pour concevoir des applications graphiques interactives. Ce modle distingue trois grands types de composants : le Contrleur : ce composant reoit les demandes en provenance de lutilisateur final et contrle le comportement de lapplication interactive pour rpondre ces demandes; le Modle Mtier : ce composant contient la logique et les informations mtier ncessaires pour rpondre aux demandes de lutilisateur; la Vue : ce composant affiche les informations attendues par lutilisateur final. Ce modle darchitecture est trs li lapproche oriente Objet : le Contrleur et la Vue sont des objets techniques, le Modle Mtier tant vu comme un ensemble dObjets Mtier activs par le Contrleur. La figure 10.1 illustre la dynamique gnrale de cette architecture.
Clic Moteur Graphique 1 4 3 Vue VUE VUE Contrleur
2 Modle
Figure 10.1 Le modle MVC classique
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 ;
10.2 SOA : Le modle MVC revisit
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.
10.2 SOA : LE MODLE MVC REVISIT

Limpact le plus vident de lapproche SOA sur cette architecture MVC concerne le Modle. Celui-ci nest plus local lapplication, mais encapsul sous forme de services, comme on la vu dans les chapitres prcdents. De ce fait, le Contrleur nactive plus directement ce Modle Mtier, mais fait appel un ou plusieurs Services. Le Contrleur devient ainsi fondamentalement un Coordinateur dappel de services. La figure 10.2 illustre la dynamique gnrale de larchitecture MVC revisite.
V M Clic Moteur Graphique 6 4 Vue VUE VUE 5 Coordinateur 1
Contexte
Mtier
Mtier
Mtier
Mtier
Ressource
Figure 10.2 Le modle MVC revisit dans un contexte SOA
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
Pourquoi ce concept de Contexte ?

Lorsquil utilise une application composite, lutilisateur final entame une vritable session de travail. Dans cette session, lutilisateur naccde pas (en gnral) un seul objet mtier isol, mais il navigue dans un graphe dobjets mtier. Par exemple, dans le fil rouge , lorsque lutilisateur final active lapplication composite consulter et rectifier les Relevs de Consommation , il souhaite naviguer du Fournisseur aux Clients desservis par ce fournisseur, dun Client ses Sites de fourniture1, dun Site aux Points de Distribution desservis sur ce site, dun Point de Distribution lhistorique des Relevs de Consommation, etc. La figure 10.3 prsente un exemple de session de travail.
1. On suppose ici que le Client est une entreprise qui possde plusieurs Sites gographiques (usines, entrepts), et que chaque Site peut possder plusieurs Points De Distribution (donc plusieurs compteurs) correspondant par exemple plusieurs types dnergie fournie.
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
Consulter le client et ses sites
Consulter les PDDs dun site
Consulter les relevs dun PDD
Mettre jour un relev
Figure 10.3 Session de travail
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).
Contexte et lecture des informations mtier

Il est important de noter que le remplissage, ou chargement, du Contexte avec les informations mtier, peut se faire selon deux grands types de stratgie : stratgie par anticipation : lapplication charge en une seule fois lensemble des informations mtier ncessaires dans le contexte, cest--dire quelle appelle le service CRUD pertinent avec un scnario de chargement en profondeur (cf. chapitre 8, zoom sur les services CRUD ); stratgie paresseuse : lapplication charge une information dans le contexte, uniquement quand lutilisateur demande cette information. Cela revient charger les informations une par une.
1. De plus, et sans rentrer dans le dtail technique, si on souhaite consulter en parallle les informations de deux clients A et B, via deux onglets du navigateur, la httpSession sera unique, alors que lapplication devra crer deux contextes bien distincts, lun ddi au client A et lautre au client B.
136
Session de travail
t1
t2
t3 Temps
t4
1 2 3
Lire PDDs Contexte(t2) Client Site A PDD A1 PDD A2 Site B
2 Lire client + site(s) 3 Contexte(t1) Client Site A Site B
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
Figure 10.4 Session de travail, contexte, chargement paresseux
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 Contrat 1..n
1..n Site Gographique
1..n Facture
1..n Point De Distribution
1..n Relev de Consommation
Figure 10.5 Modle mtier et gestion de doublon
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).
Contexte et invocation des services mtier

La question aborde ici porte sur lutilisation du Contexte comme paramtre dappel dun service mtier.
1. Le moteur de mapping objet/relationnel refusera de sauvegarder deux objets correspondant la mme ligne dune table SQL.
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.
Contexte et sauvegarde des informations mtier

Lors dune session de travail, lutilisateur ne fait pas (en gnral) que consulter des informations mtier : il les met jour, ou il en cre de nouvelles. Comme lutilisateur doit avoir un droit lerreur , cest--dire la possibilit de revenir en arrire ou de modifier plusieurs fois la mme information dans la mme session de travail, les mises jour quil effectue ne seront pas immdiatement rpercutes vers le ou les rfrentiels concerns. Lapplication attendra la fin de session1 pour sauvegarder ces mises jour ou cration. La conception de cette mcanique de sauvegarde du Contexte nest pas triviale. Cette mcanique devra tout dabord parcourir un ou plusieurs graphes dobjet mtier, plus ou moins complexes (cest--dire un graphe avec des relations u-naires et naires entre les objets). chaque nud du graphe, elle devra dcider si le (ou les) objet(s) correspondant(s) doi(ven)t tre sauvegard(s) ou non (ce qui correspond soit au fait que lobjet a t modifi, soit au fait quil vient dtre cr). Enfin, la mcanique devra faire appel, chaque nud sauvegarder, un service CRUD dcriture dans un rfrentiel, en grant les aspects transactionnels. Pourquoi compliquer cette mcanique de sauvegarde en faisant la diffrence entre objet sauvegarder et objet quil nest pas utile de sauvegarder ? Pourquoi ne pas faire de sauvegarde du Contexte en bloc ? Rponse : pour se prmunir contre la situation dcrite par le tableau 10.1. Supposons que travaillent simultanment deux utilisateurs avec la mme application composite, et sur les mmes objets mtier (le mme client, etc.), et supposons que la mcanique de sauvegarde travaille en bloc : le tableau 10.1 illustre les diffrentes tapes du travail de chacun des utilisateurs.
1. Dtecter la fin dune session de travail est un problme classique dans le cas des sites Internet. Cest pourquoi il sera toujours demand explicitement lutilisateur de signaler cette fin de session. Lapplication ne peut pas dcider seule (via un time out) de sauvegarder les informations saisies par cet utilisateur.
139
Tableau 10.1 Inconvnient de la sauvegarde en bloc du Contexte

tape Travail de lutilisateur U1 U1 charge a dans son Contexte les objets O1 pour consultation et O2 pour modification . O1 est dans une version initiale v1, nous lcrirons O1v1. U2 charge dans son Contexte lobjet O1v1 pour modification . U2 modifie lobjet O1, qui devient lobjet O1v2. U2 sauvegarde via le Contexte lobjet O1v2. U1 modifie O2, puis sauvegarde en bloc son Contexte : cest la version O1v1 qui est sauvegarde, donc il y a perte du travail de lutilisateur 2 ! Travail de lutilisateur U2
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 .
Vers le concept de Service de Gestion de Contexte

Tout ce qui prcde montre que le Contexte nest pas un simple container dobjets mtier : on peut considrer le Contexte comme un vritable service, proposant une Application Composite le contrat de service contenant les oprations suivantes : crer un nouveau Contexte; crire un objet dans un Contexte cette opration dtecte et vite les doublons; rcuprer un objet prsent dans un Contexte; sauvegarder un Contexte cette opration ne sauvegarde dans le ou les rfrentiels concerns que les objets modifis ou nouvellement crs dans ce Contexte, et prend en charge laspect transactionnel de lcriture dans ces rfrentiels; supprimer un Contexte. Certaines architectures SOA vont plus loin dans lutilisation du Contexte : il est en effet possible de faire du Contexte un intermdiaire entre dune part les Applications Composites, et dautre part les services CRUD daccs au(x) rfrentiel(s). Lide de base dune telle architecture est quune Application Composite dlgue son Contexte le soin de rcuprer les informations mtier et dappliquer la stratgie de chargement adquate. Lapplication Composite se contente ensuite dinterroger le Contexte pour rcuprer les informations dont elle a besoin (pour afficher un cran ou pour appeler un service mtier de calcul), le Contexte effectuant si besoin
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.
Conclusion : vers la normalisation du Contexte ?

En conclusion, cette vision du Contexte en tant que service part entire est partage par la communaut SOA, qui de ce fait a entrepris rcemment un effort de standardisation autour des normes WS-CAF (Composite Application Framework), et plus particulirement de la norme WS-Context (cf. partie 4). Cet effort est cependant loin dtre achev car un tel standard implique de proposer des rponses universelles aux questions non triviales dcrites ici.
10.2.2
Concept de transaction longue SOA
Pourquoi ce concept de transaction longue ?

La discussion sur la sauvegarde du Contexte a mis en vidence une question importante pour la modlisation dune application composite : que se passe-t-il quand deux utilisateurs finaux travaillent sur le mme objet mtier (sur le mme client, sur la mme facture) ? Lutilisateur, lorsquil entame une session de travail et cre donc implicitement un Contexte de travail , va en effet manipuler les informations de ce Contexte pendant un laps de temps long , par opposition la dure de vie dune transaction atomique de mise jour dun rfrentiel. On parle de transaction longue , parce que la Session de travail se compte en minutes, en dizaine de minutes, voire en heures. Ce terme de transaction longue a donc t adopt pour bien faire la diffrence avec ce quon nomme usuellement sous le terme de Transaction. Une Transaction, que lon devrait appeler Transaction Courte , doit respecter les critres de base ACID : la transaction doit tre Atomique, Cohrente, Isole et Durable. Or deux Sessions de Travail ne peuvent plus tre considres comme isoles lune de lautre, car lchelle de temps est ici lchelle humaine et non plus lchelle de temps du micro processeur sous-jacent (cf. partie 1). En bref, il y a un risque bien rel de collision entre deux utilisateurs. Ce problme nest pas apparu avec lmergence de SOA, mais ladoption dune dmarche SOA fera immanquablement apparatre cette problmatique.
Les problmes rsoudre

Il faut dabord se prmunir contre le cas de figure o les deux sessions de travail modifient effectivement le mme objet mtier. Cas de figure illustr par le tableau 10.2.
141
Tableau 10.2 Conflit entre deux crivains

tape Travail de lutilisateur U1 U1 charge dans son Contexte lobjet O1 pour modification . O1 est dans une version initiale v1, nous lcrirons O1v1. U2 charge dans son Contexte lobjet O1v1 pour modification . U2 modifie lobjet O1, qui devient lobjet O1v2. U2 sauvegarde via le Contexte lobjet O1v2. U1 modifie O1, qui devient O1v3, puis sauvegarde son Contexte : cest la version O1v3 qui est sauvegarde, donc il y a perte du travail de lutilisateur 2 ! Travail de lutilisateur U2
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
Comment alors se prmunir contre ces risques ?
142
Une solution possible : le verrouillage mtier

Une premire solution possible repose sur lutilisation dun verrouillage optimiste 1. Mais ce type de solution ne protge pas contre le cas de figure prsent par le tableau 10.3. Pour protger compltement le travail dun utilisateur contre les effets dun travail parallle dun autre utilisateur, un mcanisme de verrouillage mtier doit tre mis en place. Lobjectif de cette solution est simple : permettre une application composite de prvenir un de ses utilisateurs quun autre utilisateur est dj en train de travailler (en lecture ou en criture) sur un objet mtier. Une application composite, lorsquelle va charger dans un Contexte un Objet Mtier, pose un verrou mtier sur cet objet mtier. Ce verrou peut tre un verrou pour Consultation (lapplication ne modifiera pas cet objet mtier), ou un verrou pour Modification . Une autre session de travail, souhaitant galement charger le mme Objet Mtier, vrifiera dabord systmatiquement la prsence ou non dun verrou sur cet objet. Sil ny a pas de verrou, alors le chargement peut avoir lieu. Ce verrou est gr comme un vritable objet mtier, avec ses attributs (objet verrouill, identit de lutilisateur posant le verrou, date de verrouillage, type de verrou), et son rfrentiel ddi de persistance.
Verrouillage mtier et dialogue avec la Matrise dOuvrage

Mais que se passe-t-il si une application composite dtecte la prsence dun verrou sur lobjet mtier quelle souhaite charger ? Doit-elle bloquer la session de travail, cest--dire empcher lutilisateur daller plus loin (si on souhaite une priorit lintgrit des donnes) ? Doit-elle simplement alerter lutilisateur, sans le bloquer ? Il ny a pas de rponse universelle cette question, seule la matrise douvrage sera mme de rpondre, en fournissant un tableau tel que le tableau 10.8, propos titre indicatif. On notera que sur le plan technique, la mise en place de cette solution de verrouillage ne repose sur aucun mcanisme technique de verrouillage de bas niveau, li par exemple la Base de Donnes Relationnelles. En cas de plantage du systme dinformation, la gestion du dverrouillage peut se faire de faon trs simple, en supprimant lensemble des verrous prsents dans le rfrentiel ddi.
1. Le verrouillage optimiste repose sur lassociation tout objet mtier dune date de dernire mise jour. Lorsquune application charge dans son contexte un objet mtier, elle charge galement cette date. Au moment de sauvegarder lobjet mtier, lapplication relit la date. Si la valeur obtenue cet instant diffre de la premire valeur, cela veut dire quune autre session de travail a entre temps modifi en parallle cet objet mtier, et quil y a conflit. Le verrouillage est dit optimiste car on suppose que les conflits sont rares. Le problme est que si on na pas besoin de sauvegarder lobjet parce que celui-ci nest pas modifi, il ny a pas de vrification de la date de mise jour.
143
Tableau 10.4 Rsolution des conflits de verrouillage

Il existe dj un verrou dj pos pour Consultation par lutilisateur U2 (ou par le processus P2a) A priori, cest un cas passant : deux utilisateurs ne faisant que consulter un objet mtier, peuvent travailler en parallle sur cet objet. Cela peut cependant impliquer de devoir grer plusieurs verrous pour Consultation sur le mme objet mtier (relation 1.N entre 1 objet mtier et ses verrous), afin de pouvoir alerter tous les utilisateurs consultant cet objet lorsquun verrou en criture sera pos (cas ci-dessous). Lapplication doit au minimum alerter lutilisateur risquant de modifier linformation attention ! Mr U2 travaille dj sur cette information, vous risquez de gner son travail . Si lapplication ne bloque pas lutilisateur U1, elle doit alors tracer laction de U1 et/ou envoyer un mail lutilisateur U2. Il existe dj un verrou dj pos pour Modification par lutilisateur U2 (ou par le processus P2) Lapplication doit au minimum alerter lutilisateur voulant lire linformation : attention ! Mr U2 (ou : le processus P2) travaille dj sur cette information mtier et risque de modifier linformation en parallle .
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.
Conclusion : vers un service de gestion des verrous

La ncessit de mettre en place une gestion de verrou mtier dpend de lanalyse des risques de collision entre utilisateurs, analyse mener avec la matrise douvrage. La vision SOA du Systme dInformation conduit augmenter ce risque, puisque les rfrentiels sont de plus en plus intgrs et accds en temps rel. La mise en place dun service technique de gestion des verrous mtier peut donc savrer indispensable. Ce service offre aux applications composites le contrat dfini par les oprations suivantes : isLocked(businessObject) : cette opration permet de savoir si un verrou est dj pos sur lobjet 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
Architecture du coordinateur dune application composite SOA
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.
V Clic Moteur Graphique 1 M
Vue 1
Action 1
Graphe de Navigation
Vue i 4
Vue i+1 5 Vue m
Action
Action n 4 1 Composant fourni par le framework SOA Composant Dvelopper laide du framework SA
Contexte
Scurit
Verrou
Figure 10.6 Architecture dun coordinateur dapplication composite
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
11. Organiser un projet SOA : dmarche, acteurs, outils
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 chaque solution mtier
Recetter chaque solution mtier
tablir le plan durbanisme Spcifier larchitecture SOA
Intgrer le SI Dvelopper un Proof Of Concept Mettre en place le framework de dveloppement SOA Mettre en place linfrastructure (ESB) Hw/Sw SOA
Intgrer le suivi BAM / SAM
Figure 11.1 Dmarche mthodologique
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
Le concept de Programme SOA

La figure 11.1 repose par ailleurs sur lhypothse quil y aura plusieurs solutions mtier dvelopper en parallle, compte tenu de lampleur du projet. Do lintroduction du concept de Programme SOA , et la mise en place dune structure ddie la gestion de ce programme, afin den assurer la coordination au quotidien, notamment sur le plan de la rutilisation. De ce point de vue, un tel Programme verra la mise en place dune ou plusieurs quipes ddies la ralisation de Services Mtier rutilisables, en particulier les services mtier CRUD ddis laccs aux objets mtier racines (client, fournisseur, demande de prestation, PDD, etc.). Remarque importante : lorsquon parle dans ce chapitre dacteur et dquipe, il sagit de rle et de responsabilit, pas de personnes physiques. Un acteur ou une quipe peuvent donc dsigner une personne temps partiel sur quelques jours, aussi bien que plusieurs personnes temps plein sur plusieurs mois voire sur plusieurs annes.
Application lexemple Fil Rouge

Si lon reprend lexemple fil rouge , on peut penser que ltape plan durbanisme puis ltape architecture SOA feront apparatre une charge de travail prvisionnelle importante. Do la ncessit de mettre en place non pas une solution mtier unique, mais un programme SOA coordonnant trois quipes orientes solutions mtier et quatre quipes orientes services mtier : quipe solution mtier traitement et suivi dune demande de prestation : cest le cur de cible , justifiant la mise en place dune dmarche SOA. Cest la solution mtier initialement prvue. quipe solution mtier recherche dinformation sur les Points de Distribution, les Relevs de Consommations, les Contrats . Cette solution merge pour viter que lquipe prcdente ne devienne trop plthorique. quipe solution mtier portail dAccueil et Gestion de linformation , base sur la mise en uvre dun outil de gestion de contenu et dun portail. Cette solution merge car elle requiert des comptences spcifiques (comptence en gestion de contenus non structurs et outils associs, comptence en web design, etc.). quipe ddie au service de gestion des Demandes de Prestation et au service de gestion des Fournisseurs mettant ces demandes. quipe ddie aux services de gestion des Clients, de leurs Contrats, et de leurs Sites Gographiques. quipe ddie aux services daccs aux PDD et aux relevs de consommation associs. quipe ddie au service de gestion de lorganisation (description des utilisateurs de la solution, de leur profil, etc.).
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
tablir (ou faire voluer) le plan durbanisme
tablir la stratgie dvolution du Systme dInformation.
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
Spcifier larchitecture SOA
Spcifier chaque solution mtier et chaque service.
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
Grer le programme SOA
Coordonner lensemble des quipes et assurer le contrle Qualit du projet.
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
Dvelopper une solution mtier
Assurer le dveloppement et la livraison dune solution mtier.
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
Dvelopper un service rutilisable
Assurer le dveloppement et la livraison dun service mtier.
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
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
Mettre en place le framework SOA
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
Mettre en place linfrastructure SOA
Installer une infrastructure logicielle et matrielle SOA.
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).
11.1.10 Intgrer une solution mtier

Objectif
Intgrer et valuer une solution mtier.
Description gnrale
Lobjectif est dintgrer chaque solution mtier, en effectuant les diffrentes catgories de test ncessaires, comme illustr par la figure 11.2.
Tests de bon fonctionnement mtier Tests dassemblage entre composants OK
Tests de monte en charge
Tests de robustesse Tests de performances unitaires KO OK
OK
KO
Tests de pr-production
KO
Corrections
Figure 11.2 Dmarche mthodologique dintgration
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.
11.1.11 Intgrer le suivi BAM/SAM

Objectif
Installer, paramtrer, complter une solution BAM (Business Activity Management) + SAM (Service Activity Management).
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.
11.1.12 Intgrer le Systme dInformation

Objectif
Vrifier que toutes les solutions mtier cooprent ensemble et avec les systmes existants.
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
Tableau 11.1 Diagramme RACI

PROG ARCH SPON URBA MAIN MOA SER INT C I I I I I INF C C C C C tapes tablir le plan durbanisme Spcifier larchitecture SOA Grer le programme SOA Dvelopper une solution mtier Dvelopper les services mtier Adapter un Systme existant Mettre en place larchitecture et le framework SOA Mettre en place linfrastructure SOA Intgrer une solution mtier Intgrer le suivi BAM/SAM Intgrer le Systme dInformation R ADM C I I I I I C I I SOL
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
Outils et productivit : SOA et MDA
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 CRUD CRUD
CRUD CRUD
Figure 11.3 Rle et place des outils du framework SOA
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.).
La figure 11.4 prsente une dmarche MDA adapte au contexte SOA.
Modles Graphiques (PIM)

La modlisation mtier dbute sa phase de structuration technique grce une formalisation UML/BPMN des processus mtier. Un tel formalisme du modle de processus permet de gnrer le fichier BPEL associ, qui lui est directement excutable
168
Modles graphiques
DSL
Composants logiciels
Processus BPMN
BPEL
Coordinateur
Use Case
Graphe de Navigation (XML)
Diagramme Activit
Vue Mtier (XFORMS..)
Vues (JSP, ASP) Container de services
Composition SA/SF (SCA)
Diagramme de Classe / Service
Contrat SA / SF (WSDL) Contrat S. CRUD (WSDL)
Service
CRUD
Diagramme de Classe / Objets Mtier
Mta modle Mtier (BOXML)
Figure 11.4 SOA et MDA : une approche possible
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 :
11.4 Industrialiser : vers un modle de maturit SOA
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 INDUSTRIALISER : VERS UN MODLE DE MATURIT SOA

Le problme rcurrent de toute dmarche informatique est tout simplement de lappliquer, et si possible avec rigueur. Les bonnes rsolutions ne suffisent pas. Or lapplication dune telle dmarche ne se fait pas instantanment, pour une raison simple : elle implique une appropriation culturelle par une quipe dtres humains. Il ne sagit pas seulement de former cette quipe, mais galement de lui permettre dacqurir progressivement de lexprience, cest--dire de mrir vis--vis dun paradigme technique nouveau.
11.4.1
Les modles de maturit
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
Figure 11.5 Modle PSAUMM : les axes de progression
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
Niveau 1 SOA services
Niveau 2 SOA ouvert
Niveau 3 SOA virtualis
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
Figure 11.6 Modle PSAUMM : niveaux de maturit et capacits associes
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
Les capacits du modle
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
La bote outils Web Services

Comme on la vu dans les prcdentes parties, SOA est une approche darchitecture et ne fait pas dhypothse sur la technologie de mise en uvre. En particulier, lamalgame souvent fait entre SOA et les Web Services est une erreur de comprhension de SOA. Cependant, la conception des spcifications Web Services a t mene dans lobjectif de rpondre au mieux aux enjeux des architectures SOA. Ainsi, les Web Services sont une technologie trs pertinente pour mener une dmarche SOA. Lobjectif de cette partie est de parcourir les diffrentes spcifications qui pourront tre mises en uvre dans le cadre dune architecture SOA base sur les Web Services. Le chapitre 12 prsente les spcifications de base des Web Services : SOAP, WSDL, UDDI. Le chapitre 13 prsente les spcifications permettant de grer la scurit, la garantie dacheminement, la garantie transactionnelle, le monitoring des services. Le chapitre 14 prsente les spcifications permettant de grer les aspects composition, orchestration et prsentation.
178
La bote outils Web Services
LA PILE WEB SERVICES

Rappels sur les organismes de normalisation Dans lhistoire de la normalisation des Web Services, le consortium W3C (World Wide Web Consortium) a bti les fondations : il a normalis SOAP, WSDL et UDDI, normes prsentes au chapitre 12. La mise en uvre des Web Service a alors fait apparatre des besoins de spcifications plus compltes afin de pouvoir adresser lensemble de la pile Web Service prsente dans le paragraphe suivant. Le consortium W3C na pas voulu prendre en charge lcriture de lensemble de ces spcifications, cest pourquoi lOASIS (Organization for the Advancement of Structured Information Standards), organisme de normalisation initialement charg de la gestion de la norme documentaire SGMLa, a repris le flambeau. LOASIS a pris en charge lvolution de UDDI, tandis que le W3C conservait la gestion de SOAP et WSDL. Puis lorganisme a commenc travailler sur lcriture des nouvelles spcifications ncessaires la compltion de la pile Web Services. Sont alors apparus de nombreux regroupements dacteurs de linformatique qui crivaient des spcifications, parfois contradictoires entre elles, et les proposaient parfois, mais pas toujours, lOASIS pour ratification. Ces initiatives individuelles expliquent le foisonnement qui rgne autour des spcifications WS-*. Parmi ces regroupements dditeurs, il faut signaler le partenariat dIBM et Microsoft autour dune vision commune de larchitecture des Web Services, appele GXA, Global XML Architecture. Les propositions de GXA sont indpendantes de lOASIS mais elles ont un poids important de part le soutien dIBM et Microsoft. Par ailleurs, Microsoft a dcid de proposer une implmentation de rfrence de GXA dans un framework.NET appel WSE, Web Services Enhancements. Dans cette partie, on a pris le parti de prsenter les spcifications issues du W3C, de lOASIS et de GXA. On sest aussi arrt sur le travail de la Liberty Alliance, essentiel dans le cadre de la fdration didentit. On a ignor de nombreuses spcifications plus exotiques et dont lavenir est incertain. Leur dnombrement complet serait en effet une tche titanesque et peu intressante pour le lecteur.
a. SGML est lanctre de XML. LOASIS tait donc pertinent sur le sujet Web Services.
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.
La pile WEB 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-*)
Description & Dcouverte (WSDL, UDDI) Nomes W3C changes (SOAP)
La pile des grammaires Web Services
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-*)
Figure 12.1 Les couches basses de la pile Web Services
182
12. Linfrastructure de base
12.1 IMPLMENTER LES COMMUNICATIONS SERVEUR SERVEUR AVEC SOAP

12.1.1 XML-RPC, anctre de SOAP
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.
12.1 Implmenter les communications serveur serveur avec SOAP
183
12.1.2
Les principes de SOAP
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.
Application invoquant le service
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
Figure 12.2 Fonctionnement de SOAP
12.1.4
Les limites de SOAP
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.
12.1 Implmenter les communications serveur serveur avec SOAP
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 : un concurrent de SOAP pour une intgration lgre
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).
12.2 DFINIR UN CONTRAT DE SERVICE AVEC WSDL

12.2.1 Fonctionnement de WSDL
WSDL signifie Web Service Description Langage. Comme son nom lindique, il sagit dun langage XML normalis pour dcrire le mode de fonctionnement dun Web Service. Il permet ainsi de dcrire les modalits dinvocation distante dun Web Service, en particulier : Les oprations possibles au sein du service.
Description dun contrat de service basique Grammaire WSDL 1.1 associe
<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>
Figure 12.3 Les lments de la grammaire WSDL
12.2 Dfinir un contrat de service avec WSDL
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).
12.2 Dfinir un contrat de service avec WSDL
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).
Figure 12.4 Construction de contrat WSDL au travers dun outil WYSIWYG
12.2.2
Les limites de WSDL
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
12.3 DCOUVRIR DES SERVICES AVEC LE REGISTRE UDDI

12.3.1 Principes de UDDI
UDDI signifie Universal Description, Discovery, and Integration. Comme son nom lindique, il sagit dun systme dannuaire qui permet un fournisseur de dcrire son Service, puis au client de dcouvrir le Service et de sy connecter. UDDI est lorigine une norme du W3C crite en 2000. LOASIS a repris sa gestion et a sorti la version 3 en 2004. Un annuaire UDDI est construit sur la base des normes WSDL et SOAP. Ainsi les services y sont dcrits en WSDL et on accde lannuaire via des requtes SOAP. On y trouve trois types dinformations : Les Pages Blanches, qui dcrivent les fournisseurs de services. Les Pages Jaunes, qui dcrivent les catgories de services. Les Pages Vertes, qui dcrivent les contrats WSDL. UDDI complte donc le contrat WSDL par des mta-donnes sur le fournisseur du service. UDDI a t conu pour permettre la dcouverte et lintgration automatique dun service. Par exemple, un portail paramtr pour intgrer un service de mtorologie peut, si son service habituel ne rpond pas, aller en chercher un autre dans un annuaire UDDI et sy connecter sans aucune intervention humaine (cf. figure 12.5).
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
Figure 12.5 Exemple de dcouverte et intgration automatique
12.3 Dcouvrir des services avec le registre UDDI
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
Les limites de UDDI
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.
Application invoquant le service
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
Figure 12.6 Linfrastructure de base des Web Services
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.
12.3 Dcouvrir des services avec le registre 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
13. Les rponses aux exigences techniques
Prsentation (WSRP)
Composition & Coordination (WS-*) Normes / Drafts OASIS & autres Pilotage (WS-*)
Garantie dacheminement (WS-*)
Transactions (WS-*)
Scurit (WS-*)
Figure 13.1 La seconde couche de la pile Web Services
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.
13.1 GRER LA SCURIT1

13.1.1 La scurit dans le cadre des Web Services
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.
13.1 Grer la scurit
197
Identifiant/mot de passe pour service 2 Identifiant/mot de passe pour service 3 Identifiant/mot de passe pour service 4
Service 1
Service 3
Clef SSL service 1
Clef SSL 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
Service 2 Clef SSL service 2 Clef SSL 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.
XML Encryption (W3C)

XML Encryption est une spcification du W3C qui permet dassurer la confidentialit des informations en chiffrant un sous-ensemble dun message XML. Son mode de fonctionnement est le suivant : on applique des mcanismes de chiffrement clef secrte ou clef publique sur une partie du message SOAP. Il devient ainsi possible, lors de la transmission de messages XML, dassurer la confidentialit dune partie des donnes vis--vis de certains services. XML Encryption fournit une grammaire XML standardise pour dcrire les mthodes de chiffrement des donnes. Elle permet de mettre en uvre des procdures automatises pour assurer la confidentialit des changes.
XML Signature (W3C)

XML Signature est une autre spcification du W3C qui permet dassurer la nonrpudiation dun message SOAP en appliquant une signature numrique sur un sousensemble dun flux XML.
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.
WS-Security (OASIS) : un framework bas sur les spcifications prcdentes

WS-Security est initialement une proposition de Microsoft, IBM, et Verisign reprise par lOASIS. Cest un framework de scurisation des Web Services bas en particulier sur les standards dcrits plus haut : XML Encryption, XML Signature, et SAML. WS-Security propose de scuriser de manire intrinsque les messages SOAP : Assurer lintgrit dun fragment du message SOAP en le signant avec XML Signature. Assurer la confidentialit dun fragment du message SOAP avec XML Encryption. Certifier lidentit de laccdant auprs du serveur SOAP avec SAML ou Kerberos1. WSS dcrit ainsi des scnarios dchanges entre Web Services en y associant des pratiques de scurisation. La figure 13.3 prsente le framework WS-Security. Ce framework est aujourdhui standardis et implment dans les serveurs dapplication du march en technologie JEE et .NET. Il est donc possible de le mettre en uvre dans le cadre darchitecture SOA.
1. Kerberos nest pas prsent dans ce chapitre : il sagit un protocole permettant de dlguer lauthentification un tiers la manire de SAML. Cependant il nest pas bas sur XML mais sur des messages spcifiques.
13.1 Grer la scurit
199
WS-Security
SAML
XML Signature
XML Encryption
SOAP
Figure 13.3 Le framework WS-Security
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 de scurit moins abouties
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.
13.1 Grer la scurit
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
Les spcifications pour la fdration didentit
Introduction la fdration didentit

La fdration didentit est une approche darchitecture qui propose dtablir des liens de confiance de manire distribue entre des Services Applicatifs et des rfrentiels utilisateurs, appels serveurs didentit. Le serveur didentit est une sorte dannuaire LDAP amlior, capable dauthentifier des accdants pour le compte dapplications internes ou externes lentreprise sur la base des technologies Web Services. Il fournit aussi des fonctions de Single Sign On. Le principal objectif de la fdration didentit est de faciliter les changes entre partenaires sans avoir dupliquer les rfrentiels utilisateurs et donc en faisant de la dlgation de gestion des utilisateurs sur la base de liens de confiance entre entreprises. La figure 13.4 illustre ce mode de fonctionnement : Lorsquun utilisateur A interne lentreprise A accde un service A1, lauthentification est base sur le serveur didentit A interne. Lorsquun utilisateur B externe lentreprise A accde un service A2, lauthentification est base sur le serveur didentit B de son entreprise. Lorsquun utilisateur B accde un service A2 externe son entreprise et un service B1 interne son entreprise, les deux services dappuient sur le serveur didentit B de son entreprise. Lutilisateur B bnficie ainsi de Single Sign On entre deux services manant de deux structures diffrentes.
Relation de confiance
Entreprise A
Entreprise B
Service A1 Dlgation Authentification Dlgation Authentification
Accs Service
Serveur identit A
Serveur identit B
Dlgation Authentification Service A2 SSO entre services A2 & B1
Service B1
Accs Service
Accs Service Utilisateur A Utilisateur B
Figure 13.4 Fonctionnement de la fdration didentit
13.1 Grer la scurit
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
Figure 13.5 La pile de fdration didentit Liberty
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.
WS-SecureConversation (SLL en peer-to-peer)
WS-Federation (fdration didentit)
WS-Authorization (droits daccs)
WS-SecurePolicy (politique de scurit)
WS-Trust (tiers de confiance)
WS-Privacy (protection donnes prives)
WS-Security (framework de scurit)
XML Signature (signature numrique messages)
XML Encryption (chiffrement messages)
SOAP
Figure 13.6 La pile de scurit selon GXA
13.2 GRER LA GARANTIE DACHEMINEMENT1

13.2.1 Les spcifications disponibles
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.
13.2 Grer la garantie dacheminement
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.
WS-RM Policy (GXA)

WS-RM Policy est une dclinaison de WS-Policy au mme titre que WS-SecurityPolicy. Cette grammaire XML permet donc de dfinir une politique sur la garantie dacheminement. Elle dcrit en particulier : Le fait quun service exige une garantie dacheminement base sur WS-ReliableMessaging. Les temps dacheminement maximum attendus par le service. Le dlai avant racheminement dun message. Le dlai dattente maximum du message de confirmation de lacheminement. Etc. La spcification a t propose lOASIS en mai 2005, elle est en cours de ratification et devrait donc passer rapidement dans le giron de lOASIS.
Synthse sur la garantie dacheminement

La figure 13.7 rcapitule les grammaires XML de la garantie dacheminement. Il semble que lOASIS devrait court terme rcuprer la gestion des spcifications de garantie dacheminement (gestion de lacheminement et politique sur la garantie dacheminement) et mettre fin au flou qui rgne depuis quelques annes autour de cette problmatique dans les Web Services.
206
WS-ReliableMessaging
WS-RM Policy
WS-Reliability
WS-Policy
SOAP
SOAP
OASIS
GXA
Figure 13.7 Les piles de garantie dacheminement selon OASIS et GXA
13.3 GRER LES TRANSACTIONS DISTRIBUES1

Les spcifications prsentes dans ce chapitre ont t proposes par un groupe dacteurs men par IBM et Microsoft, et qui comprend notamment BEA et IONA. Elles ont ensuite t proposes lOASIS, et sont en cours de ratification.
13.3.1
Les spcifications disponibles
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.
13.4 Superviser les services
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
Synthse sur les transactions distribues
La figure 13.8 rcapitule les grammaires XML de gestion des transactions.
WS-AtomicTransaction
WS-BusinessActivity
WS-Coordination
SOAP
Figure 13.8 La pile de gestion transactionnelle selon GXA
13.4 SUPERVISER LES SERVICES

13.4.1 WS-DM (OASIS)
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.
13.4 Superviser les services
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-*)
Garantie dacheminement (WS-*)
Transactions (WS-*)
Scurit (WS-*)
Figure 14.1 Les couches suprieures de la pile Web Services
212
14. La composition de services
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.
14.1 AGRGER LES SERVICES AU SEIN DUNE INTERFACE

14.1.1 WSRP (OASIS)
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
Feuille de style Portlet Service Portail compatible WSRP Compatible WSRP
Figure 14.2 La consommation de portlet avec 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.
14.2 Coordonner les services
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).
14.2 COORDONNER LES SERVICES

14.2.1 WS-BPEL (OASIS)
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.
BPEL 1.1 : une premire version

BPEL a pour objectif de dcrire un langage de programmation de haut niveau , par opposition des langages considrs comme de bas niveau : Java, .NET, COBOL, etc. Tandis que les langages de bas niveaux font appel des composants et des API, BPEL invoque des services. BPEL dispose dune algorithmique simplifie qui rappelle celle des langages de bas niveau : Boucles while, switch (disponible aujourdhui avec la version 1.1). Boucles if-then-else, repeatUntil, forEach (disponibles dans la future version 2.0). La composition des services sappuie sur les contrats WSDL : ils sont parcourus par lorchestrateur de services et indispensables pour leur assemblage, puis leur invocation. La spcification offre plus largement les fonctionnalits suivantes pour grer lorchestration du processus : Type dappels et dattente de rponse de la part de services (commandes : invoke, receive, reply, wait). Invocation de services en srie (commande : sequence). Invocation des services en parallle (commande : flow).
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.
Figure 14.3 Exemple dinvocation de services en parallle et en srie
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.
Gestion des interventions humaines

De plus, le reproche que lon fait le plus souvent BPEL 1.1 est son incapacit grer des tches humaines (cf. partie 3).
Apports de BPEL 2.0

BPEL 2.0 est actuellement ltat de brouillon lOASIS : la spcification dfinitive devrait sortir courant 2006. Parmi ses nouveauts, on trouve : La gestion de lalgorithmie if-then-else, repeatUntil, forEach (cf. paragraphe prcdent). La gestion des activits de compensation lchelle dun scope. La prise en charge de transformation XSLT dans le cadre de la gestion des variables. Par ailleurs, un certain nombre dextensions doivent sortir avec BPEL 2.0. Ces extensions seront gres de manire indpendante car les diffrents acteurs de la normalisation ne sont pas daccord sur leur pertinence. Lextension la plus intressante est BPEL4People : elle permettra de grer les fameuses people activity , cest--dire de mlanger des Workflows humains aux activits dorchestrations de processus. BPEL4People permettra en particulier de grer des corbeilles de tches et des chanes de validations entre acteurs au sein dune hirarchie. BPEL4People semble donc offrir la convergence tant attendue entre les processus automatiques (orchestration) et les processus humains (Workflow). Il semble que certains puristes aient considr au sein de lOASIS que cette extension sortait du scope de BPEL et aient donc refus de linclure dans BPEL 2.0. De plus, BPEL4People conduit des modifications assez profondes de lexistant BPEL, et il nest pas vident que beaucoup dditeurs suivent cette extension. Dautant quil existe des solutions moins coteuses et plus flexibles, comme celle propose dans la partie 3. Parmi les autres extensions venir, on attend SPE (Sub Processes Extension) une norme qui permettra la gestion des sous processus avec imbrication et gestion partage de contexte.
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
Figure 14.4 La composition selon lOASIS
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.
Proprits de configuration Composant SCA
Contrat WSDL ou Java

Service Service
Externe
Implmentation BPEL, C++, Java C#, Cobol, etc. Contrat WSDL ou Java
Externe
Contrat WSDL ou Java
Figure 14.5 Un container SCA
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
Composant SCA Composant SCA
Figure 14.6 Encapsulation de containers SCA
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
SOA : Une mise en uvre concrte

Le but de cette partie est de donner accs des retours dexpriences concrets, sur la mise en uvre des Services au sein de projets SOA, locaux au SI ou destins ouvrir le SI sur le monde extrieur (projet inter SI) Les chapitres prcdents ont initi les rflexions avec la dfinition pralable du primtre dune solution mtier et la modlisation des services et applications de cette solution. Il sagit maintenant de confier aux quipes concernes la ralisation des services ou dune infrastructure de services telle que dfinie prcdemment. Des questions/rponses permettront dlaguer lunivers des possibles afin de permettre un dmarrage rapide de ce chantier de mise en uvre de services au sein dune architecture daccueil. Parmi les principales questions pour le matre duvre des services, on retrouve : Tous les services ont-ils les mmes contraintes ? Quelles sont les conventions et normes utiliser ?
220
SOA : Une mise en uvre concrte
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.
15.1 LA PORTE DES SERVICES

Aprs la reconnaissance des enjeux mtiers et de la conservation de lexistant, les DSI doivent dployer des solutions au sein du SI. La problmatique de services et darchitecture daccueil des services est souvent spare en deux espaces distincts : SI local et SI distant. Les caractristiques de ces deux espaces de services sont diffrentes, ce qui peut faciliter certains choix. En revanche, la frontire nest pas toujours durable ou parfaitement identifie. Tel service peut par exemple tre destination des partenaires et du SI local en mme temps. Le service Intervention illustr dans les parties prcdentes reste un cas intressant dcrire pour la mise en uvre. La drglementation demande doffrir ce service des partenaires externes mais il faut continuer y accder par le SI interne. Le mme service aura, alors, des contraintes techniques dexploitation diffrentes.
222
15. SI tendu ou SI local ?
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.
15.2 LES CONTRAINTES DE LENTREPRISE TENDUE

15.2.1 Un terrain favorable aux Web Services
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
Peut-on opposer lEDI aux WebServices ?
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.
15.3 Lenjeu technique du SI local
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.
15.3 LENJEU TECHNIQUE DU SI LOCAL

Au sein du SI local, selon les caractristiques requises par les services (son mode de transaction, le support de la charge, la scurit, etc.), il ny a pas ncessairement de contrainte dinteroprabilit forte. La ou les plates-formes du SI local sont connues et globalement homognes. Sur une telle plate-forme, les services distribus utiliseront les techniques de Remoting classiques, comme .NET TCP Remoting, ou CORBA, RMI/IIOP et lensemble des protocoles synchrones bass sur une distribution rseau des services. Les services de grain le plus fin (CRUD par exemple) seront implments sous la forme technique la plus simple. Dans le monde Java, il sagit des POJO, PlainOld Java Object , qui sont de simples classes Java, respectant la norme JavaBean. Leur quivalent .NET est le PONO, Plain Old.NET Object , une simple classe indpendante des conteneurs offerts par .NET. On peut gnraliser ces POJO/PONO toutes les plates-formes avec cet acronyme : POxO qui dsigne des composants simples. Le principe technique majeur est dviter une communication WebService entre deux composants de la mme application, au sein de la mme plate-forme technique, et situs sur un mme serveur ou deux serveurs relis sans intermdiaire par rseau trs haut dbit. Pourquoi un tel principe ? Dabord pour des contraintes de performance. Cette contrainte de performance porte sur le temps dexcution ET le temps dinvocation. Le temps dinvocation dun Web Service inclut des traitements potentiellement coteux (transformation XML, vrification du typage des donnes). Si un service est critique en temps dexcution ET quil participe un enchanement de services lui-mme critique, il est donc opportun denvisager des services les plus basiques possibles, donc ni WebServices, ni Remoting ou messaging, mais POxO. Que faire si les services pr-existants ont des contraintes de robustesse (?) lors de leur rutilisation ? Les technologies Remoting apportent des rponses en terme de transaction et scurit, les Web Services permettent la validation avance des paramtres et la scurit. Tout dialogue prvoir avec des plates-formes non dfinies implique en revanche de prvoir un accs WebService.
224
15. SI tendu ou SI local ?
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.
15.4 UNE APPROCHE TECHNIQUE DIFFRENCIE

Lorsque lon considre globalement les cas dusage des services dans le SI tendu ou local, on peut proposer des techniques adaptes. En partant de lide matresse que SOA ne se limite pas aux Web Services, une premire approche des cas dusage est synthtise dans le tableau suivant :
Tableau 15.1 Les cas dusage des protocoles
Cas dusage Services fortement standardiss, ouvert sur Internet. Services fortement standardiss, ouvert sur Internet. Services fortement standardiss, internes au SI. Services faiblement standardiss, ouvert sur Internet (WEB 2.0). Services fortement standardiss, lis un existant, et internes au SI. Services localiss au sein dune application ou dun groupe dapplication. Contrat de service WSDL encodage SOAP Protocole de transport Web (HTTP)
WSDL
SOAP
Autre protocole : FTP, SMTP, etc. Protocole gnraliste : JMS, REST
WSDL
Encodage binaire
XML propritaire non WSDL
XML
Autre norme de type Remoting : IDL CORBA, EJB, .NET TCP Interface Java, C#
Encodage binaire
Protocole spcialis : IIOP, RMI
Sans objet
Sans objet (appel local une JVM ou une CLR)
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
15.4 Une approche technique diffrencie
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.
16.1 UTILISER WSDL COMME FORMALISME PIVOT

16.1.1 Un socle formel qui dpasse les WebServices
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
16. Les atouts de WSDL
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
Faut-il devenir un gourou du WSDL ?
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
Quelle est la dmarche de production des WSDL ?
Approche par les modles ou approche par le code ?

Tous les outils permettent deux approches : Partir des modles de services reprsents en UML puis en dernire instance par le WSDL (approche par les modles) et formalismes associs. A contrario, gnrer ces modles WSDL partir du code des services existant (approche par le code). Microsoft publie beaucoup sur ses outils et leur capacit grer lapproche par le code. Il sagit dune stratgie oriente vers les communauts de dveloppeurs. Ces
1. Cf. chapitre 11 pour un bref rappel sur MDA et les modles PIM et PSM.
16.1 Utiliser WSDL comme formalisme pivot
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.
WSDL et systme existant

Dans le cas de rutilisation complte de lexistant, par exemple des services Mainframe dun SI, il est toujours payant de repartir dune modlisation WSDL (ou UML) de ces services afin dy intgrer toutes les contraintes mtier dutilisation qui seront prendre en compte par les nouveaux composants applicatifs client. Les quipes de dveloppement utilisant les nouvelles technologies ont souvent t dsorientes par les spcifications des services du Mainframe. Ce manque dexprience et le fait que leur formation ne comprend pas toujours une prsentation concrte des grands systmes psent sur leur comprhension et leur efficacit travailler avec cet existant. Une formalisation WSDL de ces services sera un pont immdiat entre ces technologies.
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)
Figure 16.1 Trois aspects distincts dun WSDL
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
WSDL rsout-il tous les problmes ?
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.
16.2 WSDL et interoprabilit
231
16.2 WSDL ET INTEROPRABILIT

Lavnement des services Web a donn lieu une promesse dinteroprabilit facilite. Hlas, ce vu pieux a t rapidement contrari. Entre divers mondes technologiques, force tait de constater que sans garde fou, les WebServices savraient une technologie de plus avec son lot de nouveaux problmes.
16.1.1
Une raction rapide au dmarrage rat des WebServices
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
Une norme dinteroprabilit de premier niveau : WS-I Basic Profile
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 DMYSTIFIER LUTILISATION DE WSDL : LE STYLE UTILISER

Le syndrome de la page blanche revient lorsquil faut dcider du style dchange utiliser pour tel WebService. Il existe 4 styles : RPC/encoded, RPC/Literal, Document/ encoded et Document/Literal. Souvent le choix entre ces styles a t guid par le premier exemple trouv sur un site Internet. La majeure partie des dveloppeurs ne connat pas les diffrences profondes induites par les styles. Or le choix du style peut influer notablement sur la prennit et la performance dune solution WebServices. La production de WSDL tant souvent confie des outils, paramtrer efficacement ces outils en terme de style SOAP requiert une connaissance minimum pour viter de propager un mauvais choix sur tous les WSDL gnrs.
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.
16.3 Dmystifier lutilisation de WSDL : le style utiliser
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
Conformit avec WS-I
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
Comparaison des styles
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
Typage Simple autoris
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>
<wsdl:binding **style = RPC use=encoded**>
ESB
Grer les demandes
Encoder le message (spcifique)
recupererEtatDemande
Dcoder le message (spcifique)
Figure 16.2 Style RPC/Encoded
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
Message SOAP <soap:envelope> <soap:body> <elementNumero>42</elementNumero> <elementDistributeur> 108</elementDistributeur> </soap:body> </soap:envelope>
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
par moteur XML/Schma

Grer les demandes Encoder le message (XML)
Validation du contenu
Dcoder le message (XML) Routage vers une opration
Figure 16.3 Style Document/Literal
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.
Le style Document/Literal wrapped

Enfin, il reste le mode Document/Literal wrapped, qui nest pas dans la norme WSDL mais qui est massivement utilis et dfendu par Microsoft. Il sagit dajouter le nom
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
Validation du contenu par moteur XML/Schema
Grer les demandes
Encoder le message (XML)
Dcoder le message (XML)
Figure 16.4 Style Document/Literal wrapped
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
Bilan de lutilisation des Styles WSDL
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
Voici un tableau rcapitulatif des diffrents styles :

Style RPC/Encoded Avantages Nom de lopration accessible au distpatcheur recevant lappel. Messages et WSDL trs simple. Traite des graphes dlments. Conforme WS-I Basic Profile. Nom de lopration accessible. Messages et WSDL trs simple. N/A Inconvnients Non conforme WS-I Basic Profile. Impossible de valider les appels. Verbeux par les informations de codage/dcodage.
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.
17.1 RESPECTER LA GRANULARIT DES SERVICES

La typologie des services voque dans la partie 3 fait ressortir plusieurs niveaux. La granularit sera un facteur clef de slection des technologies pour les services de plus haut et de plus bas niveau. On peut dployer le mme service de deux manires diffrentes. Il sagit de deux instances du mme service avec diffrents protocoles, voire mme diffrentes implmentations. Le Service Applicatif, de plus haut niveau sera le type mme de service gros grain exposer dans le SI tendu. Sa granularit en fait un service forte valeur dont lexcution peut justifier une performance moyenne. Les services fonctionnels peuvent offrir une grande varit de granularit et dutilisation. Ces services sont faits pour tre agrgs en un service de plus haut niveau. On trouve tous les cas dimplmentation ce niveau, selon le besoin de performance et de contrle de la qualit de service.
242
17. Choisir la technologie dimplmentation
Portail Application distante Client
Accs scuris Web service
Applicatif enregistrerDemande
Serveur dapplication Local SA1
SI Application distante Client
Accs Interne Remoting/MOM
Service fonctionnel Intervention creerDemande verifierDemande
Applicatif Serveur dapplication Local SA2 enregistrerDemande
Accs Interne Remoting
Accs Simple POxO
Accs Simple POxO
CRUD Utilisateur
CRUD Demande
Serveur dapplication Local SA3
Service fonctionnel planifierRDV confirmerRDV
Figure 17.1 Typologie et dploiement de services Tableau 17.1 Granularit et typologie

Type de service Service mtier applicatif (SA) Performance Ces services reprsentent souvent des oprations complexes pour lesquelles un client peut accepter un temps de traitement lourd. On peut aussi les utiliser dans des contextes avec un besoin de SLA. Les temps de traitements sont variables selon les fonctionnalits. Interoprabilit avec lextrieur du SI On ne peut pas imposer la plate-forme technique au client du SI tendu. Contraintes techniques Sans contraintes de performance majeure, les solutions WebServices sont les plus indiques. On peut aussi redployer des versions SLA du service, soit en Remoting soit avec des ESB assurant le SLA. Souvent des besoins de transactions et de distribution qui imposent une faade Remoting. Certainement le plus ouvert tous les cas techniques. Faible. De simples POxO doivent pouvoir raliser ces services.
Service mtier fonctionnel (SF)
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.
Service mtier CRUD
Les temps dappel et dexcution doivent tre ngligeables vis--vis des services appelant.
17.2 Triptyque salutaire
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.
17.2 TRIPTYQUE SALUTAIRE

Un service sera soit un WebService, soit un simple objet, soit un service distribu de type Remoting. Cette approche peut se systmatiser en utilisant le WSDL de description dun service pour produire systmatiquement cet ensemble : une interface et une implmentation du service sous sa forme la plus simple (PoxO); accompagn dune faade technologique Web Services; dune ou plusieurs faades Remoting (synchrone et/ou asynchrone). Les outils de gnration de code produisent couramment au minimum une faade WebService et une implmentation Remoting partir du WSDL. On peut aussi gnrer ses propres implmentations (squelette de code) sil est utile de conserver une certaine indpendance vis--vis des outils et des serveurs dapplications utiliss. Pourquoi systmatiser ce jeu de faades ? Afin de crer un contexte dutilisation matrisable. Limplmentation systmatique sous forme de POxO permet de constituer des quipes de dveloppement de services constitues de dveloppeurs peu spcialiss, sans devoir reposer sur des experts de toutes les technologies de Remoting et des WebServices. Cette dmarche permet de ne pas avoir passer trop de temps sur le mode dutilisation du service avant sa production, quil soit synchrone ou asynchrone, distribu ou non, dploy sur plusieurs sites ou dans un unique environnement, etc. Au besoin, selon les contraintes et les possibilits techniques de dploiement, on pourra utiliser telle faade ou bien le service POxO directement. Les gains sont multiples : Uniformiser lexpression des contrats de services, en conservant ds leur identification la slection des technologies prsentes dans les tableaux prcdents. Dduire limplmentation POxO (squelette de code) du contrat WSDL. Dduire linterface Remoting du contrat WSDL. Limplmentation du traitement sera indpendante de la visibilit technique de linfrastructure. Une grande partie des choix sera reporte la phase dintgration o lon est mieux inform de lensemble des contraintes prendre en compte. Les cots sont connus. En systmatisant cette approche, on connat la surcharge de production dun service selon ses quipes et ses contraintes de dveloppement. Il sera alors possible de dcider si le cot constat est compens par la flexibilit apporte. Ce bilan est spcifique aux enjeux dune entreprise qui lui permettra une valuation prcise de ses priorits.
244
17.3 STANDARDISER LAPPEL AU SERVICE

Voir les services au travers dintermdiaires permet de stabiliser le code de lappelant, ce qui est fondamental dans une dmarche dapplication composite appelant divers services susceptibles dvoluer. La solution intgre est lESB (bientt associ un container SCA), qui permet de paramtrer quel service rpond un appel et sous quelles conditions (noms, contrat, etc.). Cette solution dcharge les dveloppeurs des complexits et contraintes daccs un service, pris en charge par un module dinfrastructure de services. On retrouve le mode de fonctionnement des serveurs dapplication qui prennent en charge la complexit de dploiement, scurit, activation, etc., des applications. Les ESB ne sont pas indispensables dans tous les contextes. En attendant les conteneurs SCA, il reste des solutions programmatiques utilisant des Proxy et des conteneurs lgers. Le framework Spring propose une gestion dclarative des services bass sur linjection de dpendances. Ce type de produit permet notamment lutiliSpring : un conteneur de services lger Spring est une des solutions lgres dassemblage de service les plus en vogue. Utilisable en environnement J2EE et .NET, ce framework technique est dot dun ensemble de composants. Sa plus value majeure au sens des services est le conteneur lger de Spring, appel aussi conteneur dinjection de dpendance. Linjection de dpendance est une technique qui permet dtablir dynamiquement ou statiquement lassociation (ou dpendance) entre le consommateur dun service et une implmentation spcifique, au travers dune interface. Le consommateur na pas de connaissance de limplmentation particulire, il ne connat quune interface (Java ou C#). Cest lintgrateur qui choisit limplmentation cible au moment du dploiement. Ce mcanisme est particulirement adapt aux changements dimplmentation, pour des besoins de tests ou de bouchon, ou dadaptation des contraintes techniques diffrentes selon les cas dutilisation. Ce composant, qui connat un grand succs, soppose aux conteneurs J2EE ou .NET qui offrent une surenchre de fonctionnalits. Il sagit ici de fournir une gestion automatise et dclarative de la configuration et de lassociation des consommateurs et des implmentations de services au sein dune application. La configuration permet de dire quelle classe dimplmentation fournira quel service logique et de lier au dmarrage tous les services rels ainsi dfinis. Cest la base dun couplage lche entre services. On obtient du coup une grande flexibilit dans le dploiement des services : par exemple, la mise en place de services bouchons sur des plates-formes de dveloppement ou de tests est immdiate. Lassociation dun ensemble dimplmentations est dclarative et le dveloppeur na pas besoin de connatre plus que linterface dutilisation du service. Spring offre donc une base technique et une approche par les interfaces conforme la philosophie SOA. Cest la raison pour laquelle il a fortement inspir la norme SCA (cf. partie 4, chapitre 14).
17.3 Standardiser lappel au service
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.
1. Web Services Enhancement : amlioration et extensions proposes par Microsoft.
SIXIME PARTIE
SOA et Web 2.0

Les parties prcdentes du livre, en particulier les parties 3 et 5, portent essentiellement sur lutilisation de SOA pour rnover le Systme dInformation (SI), en conservant tout ou partie des applications existantes. Cette rnovation saccompagne dun effort de modularit afin de rendre ainsi le SI plus flexible. La mise en place de nouveaux processus mtier ainsi que louverture du SI dautres SI sont les principales justifications (mtier) de ladoption dune telle approche SOA. Or, le thme de louverture du SI aux clients de lentreprise prend de plus en plus dimportance avec lapparition de la vague Web 2.0 . Il sagit de permettre ces clients (ainsi quaux prospects, partenaires, etc.) dinteragir directement avec lentreprise, sans intermdiaire. Le Web 1.0 faisait de linternaute un lecteur dinformation, un acheteur, et un navigateur dans le rseau. Le Web 2.0 prtend dsormais faire de linternaute un acteur beaucoup plus dynamique, avec les avantages et les inconvnients que cela suppose pour lentreprise. Linternaute cre dsormais de linformation : il donne son avis sur le site de lentreprise, anime un blog, discute avec dautres clients sur un wiki, cre de la rumeur ou contribue valuer la qualit des services et des produits, explique comment il utilise ou il a abandonn tel ou tel produit Certains pensent quil faudrait ouvrir galement ce type de fonctions aux salaris de lentreprise. Lobjectif de la prsente partie est de proposer une rflexion sur ce type douverture du SI, et ainsi de positionner SOA vis--vis du Web 2.0.
248
SOA et Web 2.0
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.
18.1 SOA ET WEB 2.0 : DEUX APPROCHES DIFFRENTES ?

Comme on la vu (chapitres 4 et 8 notamment), louverture du SI avec SOA a dbut par la ralisation et la publication de Web Service. Ces Web Services sont essentiellement des faades : elles recueillent les requtes issues de lextrieur du SI, effectuent les contrles de scurit ncessaires, puis transfrent la requte vers le SI cur de mtier . Une telle requte sera traite (en gnral) par un processus mtier.
250
18. Architectures Web 2.0
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.
18.2 Les mashups : principes, avantages, problmes
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
Rfrentiels, Applications hrites & ressources techniques
Figure 18.1 Web 2.0 versus SOA ?
Les sections suivantes prsentent une analyse architecturale de lvolution des applications interactives via le Web 2.0.
18.2 LES MASHUPS : PRINCIPES, AVANTAGES, PROBLMES

Les Mashups sont des applications composites publies et accessibles sur le Web. Les services appels sont des services fournis par diffrents sites Web. Lobjectif premier dun Mashup est dagrger (intgrer, synthtiser) des informations provenant de diffrentes sources.
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
Tableau 18.1 Cas dutilisation du Mashup Fil Rouge

tape tape 1 Description de ltape Lutilisateur fournit lapplication la zone gographique concerne, par exemple le dpartement. Lutilisateur prcise, sil le souhaite, la zone concerne, par exemple en choisissant la commune concerne. Lapplication rcupre la liste des PDD prsents dans la commune dsigne et approvisionns par X. Lapplication rcupre une carte correspondant la commune dsigne. Lapplication affiche la carte et les PDDs. Service appel Service de recherche des dpartements franais. Service de recherche des communes du dpartement choisi ltape 1. Service de recherche des PDD. Fournisseur de linformation Base de donnes go-postales, fournie par ou achete un Service Postal.
tape 2
Base de donnes go-postales.
tape 3
Base de donnes industrielles, propre lentreprise.
tape 4
Service de lecture dune carte.
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 .
Figure 18.2 Un Mashup orient donnes go rfrences
18.2 Les mashups : principes, avantages, problmes
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.
18.3 AJAX : PRINCIPES, AVANTAGES & INCONVNIENTS

La cration dAJAX a pour objectif doffrir une ergonomie dcente aux utilisateurs du Web 2.0. Il sagit donc : doffrir des composants graphiques (nettement) plus volus que ceux offerts par HTML; doffrir un confort dutilisation accru : il sagit dviter le rechargement systmatique dune page HTML chaque action de lutilisateur, qui nuit la ractivit des interfaces homme-machine; de sappuyer nanmoins sur le Web et ses ingrdients de base : le navigateur, HTML, JavaScript, HTTP. Dans le Mashup dcrit par le tableau 18.1, les composants graphiques volus seront par exemple un champ de saisie auto compltant pour la saisie du dpartement, ou un composant afficheur de carte , etc. La figure 18.3 illustre1 le fonctionnement dun composant de type champ de saisie auto compltant : ds que lutilisateur a saisi la premire lettre du dpartement
1. Cette illustration a t obtenue avec la bibliothque AJAX EXT JS : http://extjs.com/. Il est important de noter que la recherche est lance partir de la saisie du x-ime caractre, x tant paramtrable.
18.3 AJAX : principes, avantages & inconvnients
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|
01 Ain 02 Aisne 03 Allier 04 Alpes-de-Haute-Provence 05 Hautes-Alpes 06 Alpes-Maritimes
Rsultat de la recherche
Figure 18.3 Un exemple de composant AJAX
18.3.1
Le principe de fonctionnement AJAX
AJAX sappuie sur trois fonctions clefs du Web

Pour satisfaire ces objectifs, AJAX sappuie sur trois fonctionnalits clefs du navigateur et de son acolyte JavaScript. Dabord, la capacit du navigateur dtecter des vnements utilisateurs (cliquer avec la souris, positionner le curseur dans un champ de saisie) et invoquer une fonction JavaScript lorsquil dtecte un tel vnement. Ce sont les fameux onClick=fonction1(), onFocus=fonction2(), etc. Ensuite, AJAX exploite les proprits dun objet central : XMLHttpRequest. Cet objet encapsule lappel un service via HTTP, plus exactement lappel une URL Internet, puis transmet le rsultat de cet appel une fonction appele CallBack. Cette fonction callback est crite par le dveloppeur AJAX. Il est important de noter que cet aller et retour nimplique pas le rechargement de la page HTML qui contient le code dutilisation de XMLHttpRequest. Le rsultat de linvocation de lURL est a priori encod en XML, do la signification de AJAX : Asynchronous (parce quon ne recharge pas la page) JavaScript (parce que le code est crit en JavaScript et inclut dans une page HTML) And XML. Sauf que dans certains cas, on nutilise pas XML mais JSON. La troisime fonctionnalit clef est le fait quune fonction JavaScript peut manipuler la page HTML qui linvoque, pour en modifier le contenu. Cest justement ce qui est souhait : la fonction callback voque plus haut aura prcisment pour objectif de modifier la page HTML pour afficher le rsultat de linvocation de XMLHttpRequest.
256
Cette manipulation seffectue via DOM, Document Object Model. DOM spcifie comment les lments dune page HTML sont manipulables directement dans une fonction JavaScript.
Fonctionnement dune application AJAX

Cette section dcrit le principe de construction dune application AJAX telle que celle prsente dans le tableau 18.1. Le concepteur commencera par inclure dans le corps de la page (statique) HTML un bouton qui, une fois le dpartement puis la commune saisis par lutilisateur, permettra de lancer (via la gestion dvnement) laffichage de la carte (cf. figure 18.1) :
<p><input type="button" value="afficher la carte" onClick="recupererPDDEtAfficherUneCarteAvecAjax();"></p>
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
objet DOM reprsentant un lment de la page
5 1
Function (associe lvnement)
XmlHttpRequest
Function callback(){ //affiche rsultat! }
CRUD
CRUD
CRUD
Figure 18.4 Principe de fonctionnement AJAX
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
AJAX & SOA : les limites
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
AJAX & SOA : lments de solution
Performance des services CRUD

Pour amliorer laccs ces services, il est possible de bnficier de la mise en place dun cache dinformation. Dans lexemple du Mashup fil rouge , la mise en place dun cache pour les tapes 1 et 2 peut savrer trs intressante : dans la mesure o les informations sont stables (on najoute pas frquemment un nouveau dpartement franais ou une nouvelle commune), lefficacit du cache sera maximale.
Architecture des Mashups

Le Web 2.0, on la vu, conduit subrepticement rpartir lapplication composite entre le client (avec les composants AJAX) et le serveur, qui doit au minimum grer laffichage et la navigation entre les pages HTML (devenues moins nombreuses, puisque plus riches). Ceci a conduit mlanger les frameworks classiques, tels que STRUTS ou les implmentations JSF, avec des bibliothques de composants AJAX. Lobjectif est de permettre au dveloppeur de continuer utiliser ses outils prfrs, associs un langage industriel . Il sagit galement de lui viter au maximum de toucher JavaScript. Mais ceci conduit une architecture complexe construire, comprendre (pour les dveloppeurs) et maintenir. La complexit provient dabord du fait que lapplication MVC est spare en deux : la Vue est en grande partie gre ct client, les Contrleurs sont cartels entre le client et le serveur, le Modle reste ct serveur, mais est partiellement rpliqu sur le client (via des objets JavaScript). On remarquera que la programmation cliente devient vnementielle, alors que la programmation serveur reste une gestion de navigation entre pages (en ce qui concerne STRUTS et quivalents). En ce qui concerne les JSF, la coexistence de deux architectures vnementielles, sur le client et sur le serveur, rend lintgration AJAX JSF complexe. En particulier, du fait de cette sparation client/serveur et de la diffrence dapproche vnementielle/navigationnel, quelques questions dlicates se posent. Tout dabord, que devient la gestion de ltat de lapplication ? Or, bien grer ltat de lapplication est important puisque cela conditionne son comportement. Doit-on distinguer entre un macro tat (o en est-on dans la navigation entre pages ?) et un micro tat (dans quel tat se trouve la page, compose de composants AJAX ?) ? Ensuite, que devient la gestion de contexte, dans le cas dapplications composites associes des sessions de travail longues (cf. 10.2) ? O positionner le contexte, qui agit comme un container dobjets mtier : sur le client ? Sur le serveur ?
260
Face ce dsordre, deux approches sopposent : la premire sappelle tout sur le client et la seconde tout sur le serveur .
Approche tout sur le client

La premire approche consiste considrer que tout se joue ct client, et quil est inutile de sencombrer dun framework MVC ct serveur. Lapplication cliente dialogue directement avec des services, via XML ou JSON. Deux avantages peuvent tre accords cette approche. Dune part, elle simplifie larchitecture et elle rend effectivement le client indpendant du ou des langages dimplmentation des services; dautre part, le prototypage dapplication est sans doute plus simple. Elle a trois inconvnients majeurs. Tout dabord, cette approche suppose que les services sauront retourner les informations ncessaires dans le bon formalisme. Or, cette hypothse nest pas toujours vrifie au sein du SI : les services qui existent dj sous forme de WS-* ou dEJB, ou les services reposant sur des donnes mainframes, devront tre modifis pour retourner du JSON, par exemple. moins de dvelopper une hirarchie de services, avec des services CRUD encapsuls par des services applicatifs chargs du travail de traduction de format : cette approche raliste nest pourtant pas celle actuellement propose par la majorit des tenants du Web 2.0. Le deuxime inconvnient de cette approche est quelle suppose que les services accds par lapplication cliente sont tous hbergs par le serveur do provient la page HTML hbergeant cette application cliente. Cette contrainte basique du Web peut tre contourne, mais au prix dune complexification du client. Le troisime inconvnient de cette approche tout sur le client AJAX est quelle semble considrer que le modle MVC est mort, et que lon peut donc sen passer. Les critiques de MVC oublient que cette approche a trouv son origine dans la programmation vnementielle de clients trs lourds (Windows, Smalltalk) puis sest adapte la programmation navigationnelle oriente clients trs lgers. Cest donc quelle dpasse ces clivages, parce quelle apporte une garantie de raliser des applications modulaires, maintenables et adaptes aux besoins. La conclusion sera donc simple : tant quil nexistera pas de vritables framework JavaScript MVC , il sera dconseill voire improductif dutiliser cette approche pour dvelopper des applications de gestion stratgiques. Et mme pour dvelopper des sites Web, on se trouvera bien de prendre les prcautions ncessaires pour viter le bricolage.
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
Figure 18.5 La mise en uvre de GWT (source : http://web2.wsj.com)
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.
18.4 CONSTRUIRE ET INTGRER LES MASHUPS

18.4.1 Construire les Mashups
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.
Figure 18.6 La cration de Mashup avec Yahoo ! Pipes
Un diteur de Mashups tel que Yahoo ! Pipes (cf. figure 18.6) fonctionnera donc idalement de la faon suivante :
18.4 Construire et intgrer les mashups
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
Intgrer les Mashups
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.
Figure 18.7 La composition de Widgets avec Netvibes
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
19. REST et Web Services
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.
19.1 REST : LES PRINCIPES

Quest-ce que REST ? Il sagit dun modle darchitecture proche des origines du Web. Le dbat REST versus Web Service a rempli blogs, forums, magasines en ligne, ou livres blancs ces deux dernires annes. REST est le tenant de la simplicit utile face lusine tentaculaire des Web Service et des normes WS-* associes. Au premier abord, il est vrai que REST est un exemple rutilant de simplicit, en expliquant que linfrastructure Web existante est un socle parfaitement suffisant pour faire (presque) tout ce qui est ncessaire une SOA. REST signifie Representationnal State Transfert : cest un concept formalis en 2000 par Roy Fielding. Ce style darchitecture est cens reprsenter lessence dune architecture Web bien fonde et efficace : un rseau de ressources (vue comme une machine tats virtuelle) au travers desquelles lutilisateur avance dans son application en utilisant des liens (transition dtat) qui lui donnent accs dautres ressources (tat de lapplication) qui lui sont transmises et rendues pour son utilisation. Il sagit du style darchitecture aujourdhui communment utilis dans une infrastructure Web. Ce style prne la standardisation des services pour garantir linteroprabilit, une approche assez sense en soi. Pour REST, le monde est un ensemble de ressources, accessibles par quatre services uniquement, reprsents par les mthodes HTTP: GET, PUT, POST, DELETE. Tout est ensuite affaire didentification de ces ressources, via le concept dURI. Depuis le milieu des annes 1990, nous avons vu clore des solutions denvergure bases sur cette architecture, et en premier lieu le Web lui-mme (au sens de rseau de sites). Lide est de reconnatre dans cette technologie un support pour implmenter une SOA au sens de cet ouvrage. Supposons que lapplication Fil Rouge gre des contrats dabonnement dans un contexte Web 2.0. Laccs un contrat, par exemple le contrat de Michel Chombier dans la figure 19.1, place lapplication dans un tat donn. Cet tat est associ la visualisation dune page HTML (page affichant les informations du contrat) : on dit
19.1 REST : les principes
267
Client HTTP
http://www.masociete.com/contrats/chombier
... /contrats/chombier/factures /contrats/chombier/echeanchier /contrats/chombier/risques
1
GET
2
rponse
Serveur HTTP
Figure 19.1 Linvocation de services avec REST
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).
Illustration avec un systme de gestion de commande

Si on prend lexemple dun fabriquant de produit (par exemple un fournisseur de compteurs) voulant ouvrir son SI en sappuyant sur REST, il dploiera un ensemble de services ouverts sur le Web pour ses nombreux clients : la liste de ses produits : get a list of parts ;
268
Client HTTP
http://www.masociete.com/produits/optomahd70
... /produits/optomahd70/detail /produits/optomahd70/avis /produits/optomahd70/similaires
1
GET
2
rponse
Serveur HTTP
Figure 19.2 Systme de gestion de commande avec REST
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 REST GET(URI) PUT(URI, resource)
Style WS-*
lireCatalogueProduits()
mettreAJourProduit(produit)
POST(URI, resource) DELETE(URI)
creerCommande(commande)
supprimerCommande(IdCommande)
Figure 19.3 Style REST versus style WS-*
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
La rponse sera un document XML comme suit :

< ?xml version="1.0" ?> <pro:produit 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/ produit.xsd"> <produit-id>00042</produit-id> <nom>produit-X</nom> <description>Le produit quil vous faut</description> <tarif>le tarif de base</tarif> <documentation xlink :href="http://www.mondepot.com/produits/00747/ documentation"/> <categorie> une catgorie </categorie> <stock> 12 </stock> </pro :produit>
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
Les exemples prcdents sont des implmentations envisageables.
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
Serveur HTTP PO.xsd
Figure 19.4 Utilisation de schma XML
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 .
19.2 Comparaison avec lapproche SOAP
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 COMPARAISON AVEC LAPPROCHE SOAP

Comment traiter ces mmes besoins avec SOAP ? Les chapitres prcdents ont montr comment utiliser des Web Services, des schmas et des messages SOAP pour exposer tel ou tel service. Comme on a commenc le voir, il y a quelques diffrences avec lapproche REST. Les envois de message SOAP sont, en mode Web/HTTP uniquement, ports par des requtes de type POST : ils nutilisent pas dURL spcifique autre que celle du bus de service ou du gestionnaire de message SOAP offert par le serveur. Linformation de routage est masque dans lenveloppe SOAP. Il y a autant de smantiques telles que lireCatalogueProduits(), afficherDetailProduit(IdProduit), ou bien encore commanderProduit(commande), que de services exposs. La volont est dexposer des contrats dirigs par le verbe. Le standard SOAP offre un systme de contrleur unifi. Cette politique de masquage des URL classiques nous fait perdre par avance la simplicit du GET : les serveurs de cache et de proxy ne pourront pas nous aider ici. Labstraction qui veut servir des standards dinteroprabilit se fait donc au dtriment des services dune infrastructure Web existante en termes de cache, scurit par filtrage durl, etc. Elle demande linstallation et la mdiation dune nouvelle gamme de logiciel : les bus de service/ESB/Listener, etc. ncessaires pour permettre louverture de lenveloppe SOAP et accder aux diffrentes informations de routage, scurit, etc. De plus, chaque rponse, il nest pas ncessaire au sens de SOAP et des Web Services de proposer des accs de type url pour avancer dans la consommation des services. Les Web Services partent du principe que le client se renseigne sur le contrat du service, ses schmas et la smantique de ses interfaces. Le client doit savoir comment avancer dans le dtail.
19.2.1
Constat technique : REST remplit son contrat
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
REST est une solution de bon got pour le Web
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
Hors du tout Web , REST perd de sa pertinence
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
Le verbe SOA en opposition aux ressources REST
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-
19.4 Comment choisir entre REST et SOAP ?
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.
19.4 COMMENT CHOISIR ENTRE REST ET SOAP ?

En conclusion, WS-*/SOAP et REST sont deux solutions dimplmentations lgitimes. REST se cantonne aux seuls principes darchitecture de la solution informatique alors que WS-* accompagne les MOA et MOE dans des scenarii plus profonds au sens de lexpression dun SI, notamment en accompagnant la modlisation et la typologie des services et informations mtier, et en incitant rflchir sur les politiques dorganisation. La principale diffrence est le choix de ce qui est offert en standard : REST standardise les verbes et les architectures techniques, alors que WS-* standardise lexpression des changes et les moyens dexposer des services spcifiques. Dans de nombreux cas, le premier niveau de standard REST pourra tre suffisant. Cest le lieu de prdilection des applications rapides de style MASHUPS, condition de se cantonner (pour linstant du moins) aux informations non structures. Dans les cas o les interactions avec les SI sont plus complexes (asynchronisme, scurit, verrouillage des informations) et que les contrats sont fortement contraints, SOAP trouve toute sa lgitimit. Cest--dire que la complexit sous-jacente de ces solutions est une rponse une relle complexit des enjeux mtiers, pas un gadget technologique.
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)
getInfoX() getObjetMetierY getContratByNumber() update(InfoX(infoX) updateObjetMetierY() updateContrat(contrat,..) deleteInfoX(idX) deleteObjetMetier(idY) archiveContrat(idContrat)
Modification
PUT(URI, Ressource)
Suppression Archivage
DETELE(URI)
Soumission Opration X
POST(URI) Data (xsd, xml)
operationX()
Figure 19.5 Synthse des diffrences entre REST et SOAP
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
Dcrypter loffre du march

Le but de cette septime partie est en premier lieu de caractriser les outils dinfrastructure ncessaires au dploiement des solutions SOA, comme le bus dentreprise, le registre de services, ou lorchestrateur, mais aussi les nouveaux outils disponibles pour la direction informatique, principalement la chane de fabrication logicielle pour SOA, et la console de suivi unifie des services et processus. Lengouement que suscite lapproche SOA conduit loffre doutils devenir plthorique : une grille de critres de comparaison est donc propose pour servir daide au choix. Enfin, les acteurs majeurs sont introduits de faon synthtique : lobjectif est de brosser un rapide panorama de loffre, sans dtails inutiles du fait de lvolution rapide du march.1
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
20. Caractristiques de la plate-forme SOA
20.1 LINFRASTRUCTURE NCESSAIRE POUR SOA

Linfrastructure SOA est prsente par la figure 20.1. Cette infrastructure comprend les composants suivants (les sous-chapitres suivants dtaillent leurs fonctions respectives) : Le bus dacheminement des messages dappels de services, associ un annuaire de service, souvent baptis ESB Enterprise Software Bus. Le moteur dorchestration des processus, destin au BPM (Business Process Management). Le container de services supportant la norme SCA. Les outils permettant daccder aux rfrentiels existants (EII/MDM). Les outils de suivi (BAM, SAM). Les outils dadministration. Le portail composite, regroupant les applications composites et offrant ainsi un point daccs unique aux utilisateurs des diffrentes applications interactives et processus mtier disponibles. La chane de fabrication des composants SOA (services et Applications Composites).
Portail & Applications Composites
Consoles de Suivi SOA SAM BAM
Chane de fabrication SOA Atelier de Modlisation Atelier de Composition Atelier de Production

SERVICE
BPM (Orchestration)
Bus de message
Administration ESB
SCA
SERVICE SERVICE SERVICE
Gestion Scurit
Atelier dHomologation MDM
CRUD
CRUD
Dploiement
EII
APS
nouveaux rfrentiels
Existant SI
Figure 20.1 Les modules dinfrastructure SOA
20.1 Linfrastructure ncessaire pour SOA
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
Le Bus dEntreprise, ou ESB
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
Les caractristiques technologiques

De ce fait, le bus doit dans lidal : Supporter WSDL comme langage universel de description des services (mme si le service est dploy en tant quEJB par exemple). Dialoguer avec les clients et les services via des protocoles htrognes : Non WS-* (e.g. Natif HTTP, MQ, JMS, .NET, BAPI, CICS, etc.). WS-* (e.g. SOAP, WS-RM, WS-Adressing, etc.). Proposer plusieurs modes dappel de service (synchrone, asynchrone). Tracer les appels de services : Stockage de compteurs techniques, avertissements, erreurs. Accs indirect (fichier, base de donnes) ou direct (HTTP, JMS, WMI, JMX, SNMP) de ces traces vers une console de suivi technique SAM. Assurer la scurisation des messages. Proposer lhbergement de services composites locaux (support de la norme SCA). Proposer une console dadministration pour son paramtrage et le dploiement des services. Pour satisfaire ces objectifs, la plupart des ESB sappuient sur une approche messagerie asynchrone . Cela veut dire que, quels que soient les protocoles dappel consommateur ESB, et ESB service, lESB transforme en interne ces appels en messages. Il assure ensuite le transfert et le routage en toute transparence vis vis des consommateurs et pourvoyeurs du service. Le routage est bas sur len-tte dun message, qui prcisera destinataire et protocole, mais un routage volu pourra prendre en compte le contenu du message. De plus, le routage peut se faire avec ou sans accus de rception, avec ou sans garantie dacheminement, etc. Ces caractristiques, font de lESB une sorte de passerelle universelle , laboutissement, diront certains, de la longue marche dbute avec RPC et poursuivie avec CORBA, DCOM, RMI, EJB, les middleware orients messages, JMS, les moniteurs transactionnels (TUXEDO), les brokers dintgration asynchrones (EAI), etc.
Larchitecture dun ESB

La figure 20.2 prsente les diffrentes briques fonctionnelles ncessaires pour que lESB satisfasse ses objectifs. Les composants registre de services , SAM et EII/MDM sont dcrits plus loin. On sen tient, dans ce sous-chapitre, ce que lon peut appeler le cur de lESB, cest--dire : Le bus de message. Les adaptateurs de protocoles et connecteurs directs. Le moteur de transformation des messages. Le moteur de routage des messages. Le container SCA de services locaux.
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,)
Bus de transport scuris des messages (ESB Core) Registre
SAM
Accs aux Donnes (EII / MDM)
SCA Service Service
Accs aux Services (local, HTTP, JMS, JCA)
Services locaux
Services Distants
Service
Service
Service
Figure 20.2 Zoom sur lESB
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
Router les messages

Quelles sont les mta-donnes permettant de router un message vers un service ? En gnral, le bus prendra en compte les paramtres suivants : Les informations contenues dans le contrat de service : adresse, protocole de transport (informations fournies par le contrat WSDL). La qualit de service demand (par exemple : garantie dacheminement et tolrance aux pannes, dlai maximum de rponse, etc.) (informations fournies dans lidal par un fichier WS-Policy). Lentte et/ou le corps du message. Les rgles de transformations (XSLT, XQuery, langage natif, etc.) appliquer lors de la conversion vers le protocole interne de lESB.
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
Protocoles supports par lESB
Messagerie interne de lESB
Figure 20.3 Fonctionnement de lESB
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.
ESB versus EAI

Force est de constater que certains EAI se sont retrouvs du jour au lendemain, baptiss du terme la mode dESB. Quelques caractristiques marquent cependant des diffrences notables.
En quoi lESB diffre-t-il du broker EAI ? Le support des Web Services et plus gnralement des normes WS*- (WSDL et BPEL par exemple), JBI et SCA est un premier point important. Le monde de lEAI est en effet un monde propritaire et monolithique, alors que le monde ESB se doit (par dfinition) de favoriser louverture, la modularit tout en supportant une topologie dcentralise. Il peut dans ce cadre intresser plus largement les communauts Open Source, mme si ce jour les initiatives restent, linstar des brokers EAI, en retard des produits commercialiss. Le second point concerne lutilisation de XML comme langage universel permettant de dfinir un modle pivot des contrats (messages) mtiers manipulables aussi bien dans lESB (transport des documents XML dans les messages ESB) que dans les clients et les services eux-mmes (transformation document XML objets mtier). Le troisime point concerne la possibilit de publier des services via le Web. Le quatrime point concerne le support dun registre de services, permettant un dploiement dynamique de limplmentation du service invoqu ainsi quun contrle des contrats. Le cinquime point concerne le routage de messages, plus sophistiqu avec SOAP et ses extensions, notamment scuritaires.
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
Le registre des services
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
Chane de fabrication Services SOA atelier 2
Registre Publication Recherche 1 Classification Localisation
Administration Registre Gestion Scurit Dploiement
crateur de Services
ESB (bus de transport & moteur de routage)
Figure 20.4 Zoom sur le registre 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
Rfrentiel de services central
C/S
Pourvoyeurs de Contrats
Consommateurs de Descriptons
browser Atelier Atelier
browser
Atelier
Rfrentiel de services #1
C/S
Atelier
C/S Rfrentiel de services #2
C/S Atelier
Consommateurs de Descriptions
browser Atelier
Atelier Pourvoyeurs de Contrats Rfrentiel de services partag
Fdration Rfrentiel de services partag
Atelier Pourvoyeurs de Contrats
Figure 20.5 Les topologies dun registre de service
20.1.3
Les besoins
Laccs aux rfrentiels de donnes (EII/MDM)
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
Services accs aux donnes matresses Gestion du rfrentiel matre
Sources de donnes matresses
Fichiers XML EXCEL NOTES
SGBDR ORACLE SYBASE DB2 MySQL
API Progiciels BAPI SAP ORACLE FUSION
Figure 20.6 Zoom sur laccs aux rfrentiels
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.
Annuaire Entreprise statistiques corrlation
Suivi BAM console alertes
Chane SOA Atelier de modlisation de processus
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 paramtrage des rgles de routage
Orchestrateur automatique de services (BPEL)
Atelier de Simulation
Appel Services via ESB
instances
SERVICE Infrastructure BPM
Figure 20.7 Zoom sur le BPM
299
20.1.5
Les besoins
Les consoles de suivi SOA
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.
20.2 LA CHANE LOGICIELLE SOA

Les ateliers de dveloppement senrichissent de plus de plug-ins et frameworks permettant de complter des actions spcialises ncessaires chaque rle et peuvent tre intgrs pour former une chane de fabrication logicielle1 la plus dterministe et automatise possible. Ainsi SOA nchappe pas la ncessit dharmoniser les tches ncessaires autour des services et de leur description formelle. En outre apparaissent progressivement des acclrateurs pour : La modlisation visuelle de processus mtier et la codification explicite de la logique de squence. La gnration dinterfaces ou de squelettes de services partir de diagrammes UML. La modlisation des formulaires pilots par les grammaires vitant la saisie brute de fragments XML. La gestion en configuration de variantes de services, soit pour agir ds la conception, soit pour permettre lexcution le fonctionnement de plusieurs variantes en bonne cohabitation.
1. Software Factory en terminologie anglo-saxonne.
20.2 La chane logicielle SOA
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.
Chane de fabrication SOA Modlisation des processus Simulation des processus
Plate-forme SOA Excution des processus Supervision des processus
Figure 20.8 Modlisation et simulation de processus

1. Il est une pratique frquente de proposer que chaque fournisseur produise en mme temps que le contrat du service, le jeu dessai permettant de tester le service rendu.
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.
Atelier logiciel de codage

Cet atelier nest pas spcifique lapproche SOA. Il sappuie donc sur les ateliers existants (ECLIPSE, IBM RAD, SUN NetBeans, Visual Studio.Net, etc.).
20.2 La chane logicielle SOA
303
Gnrateurs automatiss de code

Latelier de fabrication inclue galement des gnrateurs assurant la transformation PSM code. Ces gnrateurs cibleront : Les formulaires de consultation ou modification, crans/pages back office, etc. Le code des services CRUD. Le code des proxys daccs aux services via lESB, etc.
20.2.3
Latelier dassemblage et de dploiement
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.
Chane de fabrication SOA Fabrication des tests
Modlisation des processus
Simulation des processus
Tests Processus
Plate-forme intgration SOA Injection de charge Excution des processus
Supervision des processus
Processus homologus
Plate-forme production SOA Excution des processus Charge relle
Supervision des processus
Figure 20.9 Tests des processus
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.
21.1 INTRODUCTION LANALYSE PAR GRILLE DE CRITRES

Le principe gnral de lanalyse par grille de critres consiste mener une tude en vue du choix dun outil, et ce sur la base de listes de critres permettant de qualifier et de comparer de manire dtaille une famille de solutions. Cette dmarche passe par les tapes suivantes : Dfinition des critres de choix de la solution sur la base des besoins identifis par les quipes impliques dans le projet. Ces quipes sont gnrale-
306
21. Aide au choix
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
Critres prennit diteur 100 %

100%
Critres respect des standards
66 %
66%
Critres commerciaux
33 % Critres monitoring technique

33%
Support de la norme BPEL
Critres monte en charge
Critres routage & transformation
Critres connectivt
Critres monitoring BAM
Figure 21.1 Outils danalyse par grille de critres
21.2 La grille de critres SOA
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 LA GRILLE DE CRITRES SOA

Ce paragraphe prsente les lments prendre en compte dans la grille de critres dans le cadre dune dmarche de choix de plate-forme SOA. Les critres prsents ici sont des mta-critres, cest--dire quils offrent une vision de premier niveau de la grille. Ils devront tre affins en fonction des besoins prcis identifis par les quipes impliques dans le projet de dploiement de plateforme SOA.
21.2.1
Les critres gnraux
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
Appropriation Prise en main
G4 G5
Richesse fonctionnelle volutivit
G6
Portabilit
308
21. Aide au choix
No G7
Intitul du critre Interoprabilit
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
G9 G10 G11 G12
SAV Organisation Prennit Cots de dveloppement
G13 G14 G15 G16
Cots directs Cots indirects Standards Fiabilit
G17
Performance
1. POC signifie Proof Of Concept. Cest un prototype permettant de valider les fonctions avances par le fournisseur.
21.2.2
Les critres techniques
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
21. Aide au choix
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
Workflow interactif Contexte Mtier Collaboration
Protocoles de Transport de messages

Tableau 21.4 Les critres techniques des transports SOA
No I-P1 I-P2 I-P3 Intitul du critre Mode Query/Reply HTTP et HTTPS Mode Message SOAP+WS-Security Mode Message Passing SMTP et SMTPS Mode Fichier FTP et SFTP Mode Message IIOP Mode Asynchrone MOM Commentaires Fourniture dun adaptateur de protocoles capable dacheminer des messages (entrants et sortants) en HTTP et version scurise. Fourniture dun adaptateur de protocoles capable dinvoquer des services en technologie SOAP et variante WS-Security. Fourniture dun adaptateur de protocoles capable dacheminer des messages SMTP (Simple Mail Transport Protocol ) et version scurise. Fourniture dun adaptateur de protocoles capable dacheminer des fichiers en FTP et variante scurise. Fourniture dun adaptateur de protocoles capable dinvoquer des services en technologie CORBA IIOP. Fourniture dun adaptateur de protocoles capable dacheminer des messages en technologie de Middleware Orient Message du march (MQSeries, MSMQ,TibcoMQ, etc.) incluant le mode publication/abonnement dvnements. Fourniture dun adaptateur de protocoles capable dacheminer des messages en API Java unifie JMS (Java Message Service). Fourniture dun adaptateur de protocoles capable dinvoquer des services distants en technologie Java RMI.
I-P4 I-P5 I-P6
I-P7 I-P8
Message Asynchrone JMS Mode Query/Reply RMI
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
Optimisation de messages GRID
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
Gestion dun dictionnaire de messages
312
21. Aide au choix
No I-T3
Intitul du critre Outils de Mapping
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
Convertisseur Texte Plat XML Convertisseur Binaire XML
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
Utilisation de donnes lextrieur du SI Utilisation gnrique technique
I-C4
Intgration dinformation dentreprise

Tableau 21.8 Principaux critres dune infrastructure de services dinformation SOA
No I-I1 Intitul du critre Extraction, Injection, Ddoublonnage Commentaires Fourniture dun moteur capable danalyser et de mener des transformations en masse sur des sources de donnes htrognes et rparties. Utilisation des langages gnriques (Xpath, Xquery, Xupdate) pour la formulation de requtes CRUD distribues. Outils graphiques de fabrications de vues logiques sur plusieurs sources. Rplication dinformations, stockage et gestion de donnes ou mta-donnes matres (MDM).
I-I2
Requteur unifi
I-I3
Constructeur de vues unifies Cache persistant de donnes
I-I4
313
No I-I5
Intitul du critre Extensibilit du cache
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
Qualit des donnes Multiples APIs pour client de donnes
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
21. Aide au choix
No S9
Intitul du critre Propagation du contexte de scurit
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
Interaction en quipes rparties
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
Suivi oprationnel des processus
315
No P3 P4 P5
Intitul du critre Traces Monitoring Outils de reporting, BI
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
Modles de services Modles darchitecture
F5
Modles dinfrastructure
F6
Modle de traitements
1. DMZ signifie Zone Dmilitarise : il sagir de zones rseaux spcifiques, servant hberger des serveurs semiprotgs.
316
21. Aide au choix
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
Support des Rgles de coordination
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.
1. Critres uniquement spcifiques SOA.
317
No M2
Intitul du critre Multi-Canal
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
Support de composition Web2
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
Progiciels SOBA de gestion des commandes, de la chane de sous-traitance, etc.
1. ECM Enterprise Content Management est la terminologie anglo-saxonne usuelle.
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.
22.1 LES COMMUNAUTS RIVALISANT

Un livre entier ne suffirait pas dcrire loffre de chaque diteur. Cest pourquoi nest prsent ici quun bref aperu des acteurs les plus frquemment rencontrs. Le dtail de chaque offre nest pas fourni du fait de changements encore trop frquents dans la stratgie et le packaging des fournisseurs logiciels et/ou matriels.
320
22. Tous vers SOA !
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
Figure 22.1 Les principaux acteurs du march
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
22.1 Les communauts rivalisant
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
Le camp des vendeurs SOA gnralistes
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
22. Tous vers SOA !
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
22. Tous vers SOA !
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
22. Tous vers SOA !
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
22. Tous vers SOA !
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
Des spcialistes SOA vendeurs dinfrastructure1
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
22. Tous vers SOA !
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
22. Tous vers SOA !
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).
Encore beaucoup dautres acteurs de niche

Force est de reconnatre, que de nombreux outils ou utilitaires sont aujourdhui fournis par des socits beaucoup moins connues, notamment pour complter la chane logicielle. Sil reste impossible den faire ici la liste exhaustive, il est classique de rencontrer par exemple ceux de Altova, Stylus Studio, Aris, Mega, MetaStorm pour la modlisation des processus et des services, ou dautres plus cibls comme OnMap, BlueOxide qui facilitent la cartographie ou la modlisation collaborative, etc. On peut galement citer HP pour la gestion des performances et des services.
22.1.3
SAP
La revanche des Solutions Mtiers commerciales
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
22. Tous vers SOA !
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
22. Tous vers SOA !
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.
Les diteurs ECM en SOA

Les diteurs de solutions dEnterprise Content Management (ECM) cherchent unifier les fonctionnalits de leurs diffrents modules de gestion de contenus (contenus documentaire, contenus web, contenus multimdia, collaboration sur les contenus, etc.). Ladoption dune architecture SOA pour structurer les produits leur permet : soit une approche consistant exposer des services autour des oprations disponibles sur le contenu (cf. Interwoven, Oracle, etc.);
1. ROA (Resource Oriented Architecture) dsignant un e approche SOA simplifie base dune interface rduite un simple CRUD dans le but de manipulation dinformations (ou resource en anglais cf. Partie 6).
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
Lessor des gnralistes Open Source
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
22. Tous vers SOA !
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.
Dautres spcialistes du libre

On notera enfin la maturit progressive de plusieurs communauts pour certains modules de la plate-forme SOA en logiciel libre (Open Source). Mule est un bus de services Java aujourdhui reconnu sur le march et se prsente en challenger direct des grandes communauts Open Source prcdemment cites. Sa prise en main se rvle facile. Il dispose en outre dune documentation trs complte (guide utilisateur, guide du dveloppeur, cookbook, javadoc, etc.), dune communaut active (CodeHaus) et dun support professionnel payant (MuleSource). Son principe de fonctionnement ncessite un serveur de messagerie JMS externe (plusieurs sont possibles ActiveMQ,
340
22. Tous vers SOA !
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.
22.2 Une classification des solutions se dgage

Ainsi quen tmoignent les descriptions prcdentes, plusieurs catgories doutils se structurent progressivement pour couvrir lensemble du cycle de vie dune architecture SOA. Il est dores et dj possible de les grouper en sept familles ainsi que lillustre la figure 22.2.
22.2 Une classification des solutions se dgage
341
Solutions Mtiers SOA
Chane de Fabrication SOA
Infrastructure de Coordination SOA
Frameworks de Scurit SOA
Frameworks de Connectivit SOA
Chane de Supervision SOA
Solutions dInformation SOA
Figure 22.2 Les sept familles de solutions en route vers SOA
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
D DeMilitarized Zone Domain Specific Language
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
JBI JEE JMX JMS
Java Business Integration Java Extended Enterprise Java Management Extension Java Message Service M
MOM MDA MDM MQ MIME
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
Le WSDL document literal wrapped au format WSDL 2.0
345
LE WSDL DOCUMENT LITERAL WRAPPED AU FORMAT WSDL 2.0

Ce document a t ralis automatiquement par une transformation XSLT.
<?xml version="1.0"?> <wdsl:description xmlns:wsdl="http://www.w3.org/2006/01/wsdl" xmlns:si="http://www.distribution.com/ServiceIntervention" targetNamespace="http://www.distribution.com/ServiceIntervention"> <wdsl:types> <xsd:schema xmlns:bo="http://www.portos.org/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.org/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> <xsd:complexType> <xsd:sequence> <xsd:element name="EtaDemande" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema> </wdsl:types> <wdsl:interface name="ServiceInterventionPort">
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
Photocomposition : SCM, Toulouse
INFOPRO
TYPE DOUVRAGE L'ESSENTIEL SE FORMER RETOURS D'EXPRIENCE
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
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.
RSEAUX & TLCOMS
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

Soa PDF

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Soa PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

SYSTMES D'INFORMATION

Dunod, Paris, 2006, 2008

Quatrime partie La boite outils Web Services

Cinquime partie SOA : une mise en uvre concrte

Table des matires

Premire partie Le cahier des charges des SI agiles

Table des matires

Seconde partie Expliquer les concepts SOA

Table des matires

6.2 Du bus de messages la plate-forme SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (BPM et . . . . . . . . . . . . BAM)

Table des matires

Troisime partie SOA : tout repose sur la mthode

Table des matires

Table des matires

Quatrime partie La bote outils Web Services

Table des matires

Cinquime partie SOA : Une mise en uvre concrte

Table des matires

Sixime partie SOA et Web 2.0

Table des matires

275 276 277 279

Septime partie Dcrypter loffre du march

20.2 La chane logicielle SOA . . . . . . . . . . . . . . . . . . . . . . . . . .

Le cahier des charges des SI agiles

1.1 UNE BRVE HISTOIRE DE LINFORMATIQUE

1. De lentropie des Systmes dInformation

1.1.2 Les applications client/serveur

1.1.3 Les applications Web

1.1.4 Un premier bilan

1.1 Une brve histoire de linformatique

Problmatiques Absence de communication, redondance dinformations, htrognit technologique, cots de maintenance

Figure 1.1 Lentropie du SI

1. De lentropie des Systmes dInformation

1.2 LACCLRATION DES MARCHS ET SES CONSQUENCES SUR LE SI

1.2.2 Lintgration des acteurs externes

1.2 Lacclration des marchs et ses consquences sur le SI

2.1 LA DMARCHE DURBANISATION1

2. Les limites des rponses usuelles

2.1.2 Le modle de rfrence de lurbanisme

2.1 La dmarche durbanisation

Applicatif Logiciels et donnes

Physique Infrastructure matrielle

Figure 2.1 Le modle de rfrence de lurbanisme

2. Les limites des rponses usuelles

Figure 2.2 La problmatique des silos applicatifs

2.2 Un outillage au service des urbanistes

2.2 UN OUTILLAGE AU SERVICE DES URBANISTES

2.2.1 Les outils EAI

HUB EAI Routage, transformation, processus dintgration

LDAP Application Web CRM

Figure 2.3 Reprsentation schmatique dun outil EAI

2. Les limites des rponses usuelles

Figure 2.4 LEAI favorise les silos

2.2.2 Les outils de workflow

2.2 Un outillage au service des urbanistes

Figure 2.5 Loutil de Workflow encourage les silos

2.2.3 Les portails Web

2. Les limites des rponses usuelles

Figure 2.6 Fonctionnement des portails de premire gnration

2.2 Un outillage au service des urbanistes

2.2.4 Les langages objets

2. Les limites des rponses usuelles

2.2.5 Un constat de frustration