SOA Pas A Pas 0

Xebia IT Architects SAS 10/12 Avenue de lArche 92419 Courbevoie Cedex Tl : 01 46 91 76 16 www.xebia.
fr
SOA pas pas Une exprience relle

. . . . . . . . . .
Copyright Xebia 2006
SOA pas pas Copyright Xebia 2006 Toute reproduction mme partielle interdite
SOA pas pas

Une exprience relle
Prface
Nous sommes un certain nombre, quadras et quinquas de linformatique assister, pantois, la prolifration de spcialistes dun genre nouveau : les spcialistes SOA . Nous avons de la chance. Ces gourous auto proclams que certains amateurs de bon vin qualifieraient dAONC (Appellation dOrigine Non Contrle), ne sont pas avares de leurs conseils et leur nombre grandit aussi rapidement que celui des spcialistes eCommerce au moment du gonflement de la bulle Internet des annes 2000. A quels saints doit-on se vouer ? Laffaire nest pas simple et nous navons pas la prtention de vous apporter une rponse toute faite. Lhumilit est lune des 10 valeurs en vigueur chez Xebia Ce guide na pas dautre ambition que de partager une exprience concrte de la mise en place de SOA par des consultants de Xebia. Il dresse, pour vous, une liste des chantiers que nous pensons tre incontournables pour les entreprises engages sur la voie des Architectures Orientes Services. Nous esprons que vous prendrez plaisir le lire.
Luc Legardeur Prsident Xebia
Table des matires

Prface ...............................................................................................................................................................2 Table des matires............................................................................................................................................3 Table des illustrations ......................................................................................................................................3 1 Introduction.................................................................................................................................................4 1.1 1.2 2 Enjeux dune SOA..................................................................................................................................4 Les deux approches : Top Down ou Bottom Up ....................................................................................4
Dmarche ....................................................................................................................................................6 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 Conception oriente Services ................................................................................................................6 Interconnexion technique.......................................................................................................................8 Lintermdiation fonctionnelle ..............................................................................................................10 Socle de dveloppement : industrialisation et solidification.................................................................12 Mise en place dun catalogue de services (Registry) ..........................................................................14 La gestion des paramtres (MDM) ......................................................................................................15 La ncessit des formats pivots...........................................................................................................16 La contextualisation des services ........................................................................................................18 La supervision et la gestion de la scurit...........................................................................................20 Batch et SOA .......................................................................................................................................22 Positionnement de certaines briques concourant SOA ....................................................................23
Conclusion ................................................................................................................................................25 3.1 Apprhender SOA................................................................................................................................25
Annexes ...........................................................................................................................................................26 3.2 3.3 Nomenclature.......................................................................................................................................26 Glossaire ..............................................................................................................................................26
Table des illustrations

Figure 1 - Bottom-up & Top-down.......................................................................................................................5 Figure 2 - Echange entre services ......................................................................................................................8 Figure 3 - Intermdiation fonctionnelle .............................................................................................................10 Figure 4 - Principes d'un MDM ........................................................................................................................15 Figure 5 - Sans format pivot, multiplication des formats...................................................................................17 Figure 6 - Formats pivots par domaine .............................................................................................................17 Figure 7 - Contextualisation des services .........................................................................................................19 Figure 8 - BAM ..................................................................................................................................................21 Figure 9 - Batch et fil de l'eau ...........................................................................................................................22 Figure 10 - Fonctions d'un EAI / ESB ...............................................................................................................24
1 Introduction
1.1 Enjeux dune SOA
Une entreprise, ou plus communment une organisation est un systme au sens de la thorie gnrale des systmes or, comme la montr labondante littrature sur le sujet, un systme est confront quatre dfis majeurs : Linteraction : un systme change avec dautres voire avec lui-mme (feedback), Pour une entreprise cela signifie les partenariats, les relations clients & fournisseurs, etc. La totalit : le systme doit tre vu dans son ensemble et ne doit pas tre rduit lune de ses parties. Lorganisation : les relations entre les composants dun mme systme sont tout aussi importantes que les composants eux mme. Il ne suffit pas de dcrire statiquement la cartographie dune entreprise, la dynamique des changes est primordiale apprhender. La complexit : elle est lie lenvironnement dans lequel le systme volue, son organisation, ses objectifs.
SOA a pour objectif de rpondre ces quatre enjeux : Faciliter linteraction par lexposition de services en sappuyant sur des concepts forts comme linteroprabilit et la rutilisation. La dfinition des services dans SOA impose une relle rflexion mtier prenant en compte la stratgie de lentreprise dans sa globalit. Larchitecture de services doit tre en phase avec lorganisation et traduire la dynamique des changes afin de dfinir des services rutilisables. Les S.I. sont de plus en plus complexes, dune part cause dvolutions technologiques incessantes mais aussi cause de changements permanents dans les organisations, dans la lgislation, etc. En rendant flexible le S.I., SOA permet de mieux grer ces changements tant technologiques, mtiers, organisationnels que rglementaires.
1.2 Les deux approches : Top Down ou Bottom Up

La question de la bonne approche a donn naissance bien des crits et des thories chacune sous tendant des positions, selon nous, trop dogmatiques.
Le point de vue de Xebia dans ce domaine est simple : Bien quune approche Top-Down soit prfrable dans le cadre dune dmarche SOA, elle nest cependant que rarement possible car elle signifie une refonte de tout ou partie du S.I, juge bien souvent trop coteuse et trop risque. Il est donc bien souvent obligatoire de passer, au moins temporairement ( lchelle dun schma directeur cela signifie quelques annes), par une phase de conception ascendante (Bottom-up).
Cest dans les approches Bottom-up que les technologies de types EAI et ESB prennent tout leur sens puisquelles permettent dans un premier temps de faire communiquer, entre elles, les diffrentes briques applicatives tout en garantissant leur totale indpendance et tanchit les unes vis--vis des autres. Cependant, lapproche Bottom-Up seule ne permet pas de mettre en place une SOA. Il sagira tout au mieux dune mise en mode services . Ces services seront vus localement et ne sinscriront pas dans une Architecture Oriente Services lchelle de lentreprise. La bonne solution est donc de mixer les deux dmarches, Top-Down pour une portion du S.I. qui est en cours de refonte (ou refondre) et Bottom-Up pour le reste, ce qui concourt au bon fonctionnement de lensemble au quotidien.
La conclusion de ce chapitre dintroduction est donc bien la suivante : une SOA na aucun sens si lon ne veut pas impacter lexistant. Le mot-clef du trigramme SOA est donc bien Architecture et pas Services. En faisant une mtaphore avec le btiment, on ne fait pas de larchitecture en repeignant les murs et en changeant la tuyauterie.
Figure 1 - Bottom-up & Top-down
2 Dmarche
2.1 Conception oriente Services
2.1.1 Objectifs & dmarche Nous nallons pas ici justifier la dmarche de conception en elle-mme qui est une vidence dans la mise en place de SOA. La dmarche de conception des services dans SOA a pour objectifs : Didentifier les services ; De catgoriser les services ; De regrouper les services ; De formaliser les services.
Le premier chantier servira identifier les services concourant la cible darchitecture. Ces services peuvent tre issus dune conception from scratch (refonte, re-conception) ou dinterfaces masquant lexistant.
Une fois identifis, les services doivent tre typs , on distingue trois grandes catgories : Services organisationnels : gnralement issus des cas dutilisation ou actes de gestion mtiers (par exemple : dclarer un sinistre, ouvrir un compte bancaire, passer une commande, etc.). Les rgles contenues dans ces services sont intimement lies la structure de lentreprise et donc plus sujettes changement. Les services organisationnels sont les services de haut niveau. Ce sont eux qui orchestrent dautres services, services organisationnels ou services mtiers. Les services organisationnels sont ceux exposs un utilisateur via une IHM. Services mtier : contenant les rgles mtiers ou lis la lgislation donc rputs stables. Ces services ne sont normalement pas accessibles directement par les utilisateurs. Ils sont orchestrs par les services organisationnels. Leur complexit est limite et ils doivent rpondre des besoins lmentaires simples. On trouve dans cette catgorie par exemple lire contrat recherche client , calculer montant facture . Services techniques : purement techniques et dont lexistence est pilote et dcide par linformatique et non par le mtier.
Pour viter davoir une architecture avec plusieurs centaines voire milliers de services flottants , il est ncessaire de les regrouper au sein de composants. Gnralement on considre quun composant contient une dizaine une quinzaine de services maximum. Pour plus de souplesse, ces composants peuvent aussi tre regroups au sein dautres composants et ainsi de suite, toujours en respectant la mtrique de 10 15.
Pour adresser tous ces enjeux, une phase de modlisation est donc ncessaire. Cette phase nest envisageable quavec laide dun outil et une mthode de modlisation adhoc.
Les enjeux de la modlisation sont : Eviter la redondance dans le systme : Si chaque responsable technique dun systme dcide de lui-mme ce quil veut exposer, de la redondance sinstallera moyen terme. Seule une vue densemble du S.I. permet de juger de la pertinence dun service. Assurer la rutilisabilit : Pour tre rentable, un service doit tre utilis plus dune fois. Seuls les experts mtiers sont mme de garantir cette rutilisation. Impliquer les utilisateurs dans le S.I. Dfinir la cible durbanisation et la trajectoire pour latteindre.
2.1.2 Critres de vigilance
Mthodologie de conception
Une mthodologie approprie doit tre choisie pour identifier les services.
Choix de loutil de modlisation
Une tude doit tre mene pour vrifier les points suivants : Compatibilit UML, Gnrateurs dj disponibles, Facilit de cration de nouveaux gnrateurs, Possibilit de faire du reverse engineering. Ces points permettront dindustrialiser le passage des modles de conception la cible technologique (approche MDA).
2.2 Interconnexion technique

2.2.1 Objectifs & dmarche Nous nous accordons tous pour dire que SOA consiste exposer en mode service des programmes, des transactions ou des mthodes / oprations l'extrieur de l'application qui les hberge en vue de leur rutilisation. Il est primordial de comprendre que cette exposition est une vision informatique, ce qui ne permet pas dassurer la prennit long terme des services exposs. En effet ceux ci ne seront pas ncessairement aligns sur la stratgie business de lentreprise. Cependant, cette premire tape est utile pour construire le socle technique sur lequel sappuiera ultrieurement une vritable SOA. Ce socle technique se dcoupe en trois composantes majeures : Les services ; La couche de transport ; Les connecteurs. Ce qui se rsume sur le schma suivant :
Figure 2 - Echange entre services
Un projet SOA ne se rsume pas une composante EAI / ESB ou WebServices qui ne sont que des moyens de la mise en uvre. Il y a lieu dtudier, en fonction du contexte du S.I., la ou les meilleures solutions mettre en place. Par consquent, le transport nest pas ncessairement un M.O.M. (Middleware Orient Messages). Il peut parfaitement sagir dune connexion http sur laquelle circulent des messages SOAP ou encore daccs EJB Remote (RMI/IIOP). Par exemple, la dcision de prendre un EAI est lie aux choix stratgiques de lentreprise en termes dinterconnexion. La plupart des EAI du march offrent nativement bon nombre de connecteurs pour accder aux systmes Legacy (MVS, AS400, ) mais on trouve aussi des solutions permettant dexposer par exemple des transactions CICS ou IMS en WebServices. Les critres de slection dun EAI sont nombreux (asynchronisme, routage, existence de connecteurs, outil de BPM, ) et nous ne nous tendrons pas sur le sujet qui a donn lieu de nombreuses tudes chez Xebia ou ailleurs.
Quelque soit le choix effectu, il est ncessaire de masquer aux services les problmatiques dinterconnexions techniques. En effet, le point de vigilance, vritable fil rouge qui guide toute dmarche SOA, est la rversibilit technologique. Lintermdiation technique doit donc pouvoir tre change sans impact sur les services. Pour ce faire il existe de bonnes pratiques de gnie logiciel (design patterns) qui simplmentent par simple ingnierie et ne ncessitent pas lacquisition de logiciels coteux.
Dissociation code mtier / code technique dexposition
Les services identifis ne doivent pas connatre par quels mcanismes techniques ils invoquent dautres services ou sont eux mme invoqus.
Connecteurs
Les connecteurs doivent tre gnriques, donc agnostiques vis--vis du mtier et surtout rutilisables donc au sein dun socle technique (framework).
Scurit des messages
La scurit (perte de messages, preuves, intgrit, ) doit tre traite par les connecteurs.
2.3 Lintermdiation fonctionnelle

2.3.1 Objectifs & dmarche Lintermdiation fonctionnelle est ncessaire pour aborder deux points fondamentaux de toute dmarche SOA : La transcodification : Translation didentifiants ; Traduction de rfrentiels ; Localisation des services et du systme propritaire de lobjet mtier. Lagrgation : Exposition de services consolidant des informations de plusieurs domaines fonctionnels.
Figure 3 - Intermdiation fonctionnelle
Chaque systme travaille avec ses propres identifiants mtier, une transcodification est donc ncessaire pour permettre une mise en commun de services (on parle de translation didentifiant). Cette translation consiste associer pour un identifiant dun systme (un client, un contrat, ), un identifiant banalis et unique sur tout le S.I. dans le cadre dun index.
Lagrgation fonctionnelle consiste mettre disposition des services unifiant les rponses de plusieurs autres services. Lexemple typique est celui de la synthse client qui consiste prsenter de manire consolide la fois les informations du client mais aussi des informations sur son compte ou ses contrats. Cette agrgation prend sa charge les services transverses couvrant plusieurs domaines.
Ces services trouvent leur place dans des outils dEAI / ESB ou alors en java natif (La JSR-207 traite tout particulirement de lorchestration de service en Java).
Architecture & conception fonctionnelle
Un architecte fonctionnel doit tre clairement identifi et responsable du chantier de conception fonctionnelle. Les services dintermdiation fonctionnelle doivent tre conus par les quipes fonctionnelles et donc spcifis par eux.
2.4 Socle de dveloppement : industrialisation et solidification

2.4.1 Objectifs & dmarche La clef de la russite dune architecture, quelle soit SOA ou pas, mais plus forte raison si elle est SOA, rside dans la solidit du socle technique. Ce socle doit tre matris tant dans son dveloppement que son exploitation. Les dveloppements doivent tre spars en deux domaines distincts : Les composants techniques ; Le mtier.
Les composants techniques, gnralement regroups sous la terminologie framework, doivent permettre un dveloppement rapide et notamment masquer au dveloppeur mtier toutes les problmatiques techniques comme par exemple : Laccs un service distant (WebService, M.O.M. ou EJB) ; La gestion des transactions ; La scurit ; La gestion des instances dobjets ; Laccs aux donnes ; Pr & post traitements de services ; LIHM ; Etc.
Lensemble de ces points doit tre trait dans un Document dArchitecture Applicative et Technique (D.A.A.T.). Les principes clefs sont dobtenir un framework garantissant : La facilit dextension (ajout de nouvelles fonctionnalits techniques) ; Un systme dclaratif pour les composants mtiers (ajout de nouveaux composants par simple paramtrage) ; Un haut niveau de paramtrage (transaction dclarative par exemple et donc non gre au niveau du code) ; Une contextualisation des services (Cf. paragraphe 2.8, La contextualisation des services page 18) ; La rversibilit technologique (dans la limite du choix du langage dimplmentation).
On comprend aisment quune trs haute technicit est requise (et cest l, lun des mtiers de Xebia). Ce framework peut tre dvelopp en interne et / ou s'appuyer sur des framework du march. Quelque soit le choix, la ralisation du D.A.A.T. est essentielle mme si un framework du march est retenu ne serait-ce que pour justifier ce choix. En effet, le D.A.A.T. a pour vocation premire la justification des dcisions darchitecture.
La mise en uvre dun socle technique doit traiter aussi de l'exploitabilit des applications notamment la gestion des alertes sur incidents et la supervision. Une plate-forme dintgration est galement ncessaire. Elle comprend au minimum : Un outil de gestion de bugs ; Un composant dintgration continue ; La documentation projet (manuel du dveloppeur, javadoc du framework, ) ; Un rfrentiel commun pour les ressources partages (bibliothques jar, utilitaires, .) ; Etc.
Quelque soit la dmarche projet choisie, il nest jamais mauvais de rappeler que les tests unitaires ne sont pas seulement ncessaires mais un passage obligatoire (et que trop souvent rduits leur plus simple expression). Parmi ces tests unitaires, dans une architecture SOA, nous retrouvons la notion des bouchons. Pour des contraintes projets, les services fournisseurs ne sont pas ncessairement finis en mme temps que les consommateurs. Pour que chaque dveloppement puisse se faire de manire la plus isole possible en attendant lintgration de bout en bout il est ncessaire ds les phases amonts de dfinir les bouchons permettant cette isolation. Bien plus que les bouchons, les moyens techniques de gestion de ces bouchons doivent tre tudis en dtail. Cela inclut : La gnration ; La gestion du cycle de vie (versionning) ; La production a plus ou moins grande chelle dun nombre reprsentatif de cas de tests.
La dmarche de solidification couvre donc : Lindustrialisation des dveloppements ; Lindustrialisation des tests unitaires ; Lindustrialisation des tests dintgration.
2.5 Mise en place dun catalogue de services (Registry)

2.5.1 Objectifs & demarche Le catalogue de service est un incontournable pour matriser les services. Ce catalogue offre plusieurs fonctionnalits et doit au minimum : Faciliter le fonctionnement de linfrastructure dchanges : Assurer la correspondance entre les diffrents noms que peut porter chaque service dans les diffrents sous-systmes ; Routage ; Transcodification et uniformisation des codes (y compris les codes erreurs). Consolider la connaissance mtier : tre la rfrence unique portant la connaissance des services de lentreprise ; Porter la connaissance des formats dchanges ; Distinguer les services qui ncessitent une rponse de ceux qui nen attendent pas ; Identifier lappartenance fonctionnelle de chaque flux ; Grer les versions. Le catalogue assure donc la cohrence entre les diffrentes nomenclatures des applications.
Il traite aussi la dimension routage savoir qu partir des informations de contexte il offre la possibilit de dterminer le service cible, le mode daccs (M.O.M., Web Services, ), les ressources associes (nom de la file MQ, URL daccs).
Le catalogue doit tre et rester lunique point de rfrencement des services.
Modlisation & conception du catalogue
Le catalogue doit tre modlis par un architecte fonctionnel.
Couverture des besoins
La mise en uvre dun catalogue dans sa totalit est un projet denvergure. Il est possible den restreindre le primtre mais le minimum requis est : Transcodification Routage Rfrencement des schmas XML
2.6 La gestion des paramtres (MDM)

2.6.1 Objectifs & demarche Une architecture SOA manipule une grande quantit de donnes. Nous avons dj voqu le catalogue de services mais le framework lui-mme sera compos de plusieurs centaines voire milliers de paramtres. A cela sajoutent les rfrentiels mtiers (catalogue produits, tables de scoring, ) qui gnralement bnficient chacun de leurs propres crans de gestion. Le MDM permet dobtenir une vue centralise et unifie de lensemble des paramtres techniques et fonctionnels du Systme dInformations. Lunification des donnes permet de sassurer quune modification sera correctement propage dans les systmes sappuyant dessus ce qui masque la complexit de la rplication. La vue centralise permet de nutiliser quun seul outil pour lensemble de sa gestion. Enfin, un outil de MDM dfinit des profils associs des donnes ce qui permet de restreindre certaines modifications une catgorie de personnes (notion de rle). La force de ce genre doutil est de pouvoir tre utilise par les fonctionnels pour ladministration des rfrentiels, le dveloppement pour le paramtrage applicatif et lexploitation pour le paramtrage technique.
Figure 4 - Principes d'un MDM
Processus de travail
La mise en place dun outil de MDM ne se substitue pas une rflexion sur le processus global de gestion des donnes (qui fait quoi et quand). Les outils de MDM se focalisent gnralement sur la gestion des donnes. Il est la charge de lentreprise de dvelopper les composants permettant de grer les imports / exports entre le modle unifi du MDM et les diffrents systmes existants.
Connecteurs techniques
2.7 La ncessit des formats pivots

2.7.1 Objectifs & demarche Lorsque l'architecture SOA s'tend sur le S.I., le danger est de voir se multiplier les formats d'changes. Leur matrise peut savrer difficile, notamment en cas de changement de structure de donnes rutilises dans plusieurs flux. De mme lorsquun nouveau consommateur apparat cela engendre de nouveaux dveloppements au niveau de la couche dintermdiation ce qui, la longue, est coteux en dveloppement et en maintenance. Une bonne solution consiste dterminer des formats pivots, gnralement par grands domaines fonctionnels, idalement au niveau de l'entreprise. Ces formats pivots sont des reprsentations communes, mtiers, partages et admises par tous. Cela implique quune donne aura toujours la mme signification quelque soit le point de vue fonctionnel. Un cueil courant dans la dtermination des formats pivots est de prendre le modle dj en place dans un back-end. A moins que ce modle nait bnfici dune tude fonctionnelle avance et aboutie, on saperoit quil est gnralement un modle logiciel c'est--dire non partag et non partageable par dfinition. Les formats pivots vont de pair avec une administration de donnes car la correspondance entre les donnes dans chaque systme et les formats pivots doit bien entendu tre clairement identifie et gre. Enfin, ces formats pivots mais cela est vrai quelque soit le format, pivot ou non doivent tre versionns et ainsi que leur cycle de vie, gr.
Figure 5 - Sans format pivot, multiplication des formats
Figure 6 - Formats pivots par domaine
Etape des ngociations
La ngociation des formats pivots entre diffrents acteurs mtier de lentreprise est un travail de longue haleine, difficile mais indispensable sur le long terme. Le ROI est par contre trs rapide puisque les nouveaux services sappuieront sur ce format pivot.
Dcision de ne pas faire de formats pivots
Devant lampleur du chantier il est tentant de dcider de ne pas dfinir de formats pivots. Les risques encourus sont la multiplicit de connexions EAI pour assurer linteroprabilit ce qui a pour consquence immdiate de multiplier les dveloppements et la maintenance.
2.8 La contextualisation des services

2.8.1 Objectifs & demarche La contextualisation est un point clairement dfini sous lappellation Execution Context par lOasis, organisme de rfrence en matire de SOA : The execution context of a service interaction is the set of infrastructure elements, process entities, policy assertions and agreements that are identified as part of an instantiated service interaction, and thus forms a path between those with needs and those with capabilities. []The execution context is not limited to one side of the interaction; rather it concerns the totality of the interaction including the service provider, the service consumer and the common infrastructure needed to mediate the interaction. While there may be third parties, for example, government regulators, who set some of the conditions for the execution context, this merely increases the conditions and constraints needing to be coordinated and may require additional information exchange to complete the execution context.
Chaque service doit tre contextualis c'est--dire que son comportement varie en fonction du contexte dans lequel il s'excute.
Le contexte est considr comme flottant et toujours prsent au cours de lchange entre le consommateur (du service) et le fournisseur (du service). Cest donc au socle technique (typiquement le framework voqu au paragraphe 2.4, Socle de dveloppement : industrialisation et solidification , page 12) de prendre sa charge ce mcanisme de passage du contexte entre les diffrentes strates de larchitecture logicielle. Mais ce contexte doit aussi tre vu dun point de vue architecture logique et dfini, de mme que pour les formats pivots, avec une vue densemble du S.I.
Figure 7 - Contextualisation des services
La contextualisation nest pas exclusivement ddie aux changes inter-applications mais aussi lors dinvocations intra-applications et cela tout particulirement pour la gestion de version du service appel.
Transport du contexte
Le passage du contexte entre chaque couche dune application et entre deux applications doit tre bien tudi et outill.
2.9 La supervision et la gestion de la scurit

2.9.1 Objectifs & demarche Lors du dploiement dune infrastructure SOA se pose ncessairement la problmatique de la scurit dune part et de la supervision dautre part.
Traitons tout dabord laspect scurit ; celui-ci peut tre dcoup en trois parties : Scurit daccs pour un profil (utilisateur) un service ; Scurit daccs entre les services (quel service peut accder quels autres) ; Scurit des donnes (chiffrement partiel ou total). Le premier point peut tre gr en scurisant laccs au niveau front office (authentification classique , SSO, ) ou en grant un niveau dhabilitation avec la notion de carte didentit XML permettant de valider laccs des services pour un profil donn (normes XACML et SAML). Les accs entre services peuvent tre adresss de plusieurs manires : par des contrles auprs du catalogue de services mais aussi en utilisant les fonctions natives fournies par limplmentation technique (par exemple la scurit au niveau des EJB). Le chiffrement des donnes, sil est partiel, est trait soit de manire spcifique, soit en sappuyant sur les standards du march au niveau des WebServices avec le standard WS-Security. Quant au chiffrement complet, lutilisation de SSL, avec https, au niveau du M.O.M. ou des EJB est prconise mais avec un risque de dgradation des performances.
Concernant la supervision, la notion de BAM (Business Activity Monitoring) intervient alors et consiste : Agrger les informations (logs, alertes, messages snmp) de suivis des diffrentes applications ; Consolider et prsenter ses donnes sous une vue unifie permettant de reproduire lensemble dun acte de gestion ou dun processus sur le S.I. ; Remonter des alertes.
Pour ce faire il est important de dfinir des formats de logs standards, en sappuyant par exemple sur CBE (Common Base Event) et donc de mettre en place des identifiants de corrlation mtier permettant de suivre un processus de bout en bout. Lidentifiant de corrlation doit videmment tre propag par les services y compris lors dappels en cascade et doit apparatre dans les traces applicatives et les remontes dalertes.
Figure 8 - BAM
Le BAM ne se substitue cependant ni une supervision technique du socle comme par exemple lutilisation du rseau ou les espaces disques ni une supervision des performances (temps de rponse des services). 2.9.2 Critres de vigilance
Habilitation ou scurit
Il est important de classifier correctement problmatiques et de ne pas les mlanger : Les problmatiques daccs ;
les
La notion de pouvoir (ex : contrle fonctionnel sur des montants) ; La segmentation (qui peut voir quoi) ; La confidentialit des donnes ; La notion de preuve (piste daudit).
2.10 Batch et SOA

2.10.1 Objectifs & demarche La notion de batch ncessite un chapitre part entire car se pose invitablement, lorsque lon parle de rutilisabilit en SOA, la question des batchs. En SOA, les services sont vus comme unitaires alors que les batchs sont bien souvent considrs sous un angle ensembliste (traitements par lots). La rgle en la matire est simple : il faut repenser lapproche et considrer les batchs comme des services unitaires autant que possible. Lidal est dadopter autant que possible une approche batch fil de leau ce qui revient une dmarche vnementielle dans laquelle les informations sont pousses ds que possible. La diffrence avec un appel de service classique est que lvnement se fait en mode asynchrone pur (lappelant nattend donc pas de rponse). Dans ce cas prcis, un M.O.M. prend toute sa valeur puisque si le service distant nest pas disponible, lappelant nest pas bloqu et linformation sera achemine ds que faire se peut. Dans les cas o une approche ensembliste est requise, il est dangereux de vouloir rutiliser les services conus dans le cadre de lapproche SOA car la tentation sera grande de faire des compromis et donc soit de dnaturer le service soit de pnaliser les performances globales du batch. La consquence de la non rutilisation de service est bien sr la duplication invitable de rgles mtiers. Cette duplication nest pas gnante outre-mesure si elle est correctement documente et accept de tout le monde.
Figure 9 - Batch et fil de l'eau
Fil de leau ou ensembliste
La dcision entre les deux modes appartient aux quipes fonctionnelles et peut tre prise au cas par cas.
2.11 Positionnement de certaines briques concourant SOA

2.11.1 Moteur de rgles Lutilisation dun moteur de rgles apparat trs vite comme une vidence dans la mise en place de SOA. En effet, une architecture SOA donne de lagilit sur linterconnexion et lenchainement des services entre eux ; Le moteur de rgles donne de lagilit au sein du service lui-mme. Ce moteur de rgles peut tre implment : Soit sous forme dun service auquel cas une mme rgle peut tre partage entre plusieurs applications y compris de technologie diffrentes ; Soit en mode natif dans le service ce qui nest possible que si le moteur de rgles partage la technologie dimplmentation de lapplication. Il ny a pas de rponse prcise quant aux critres de choix entre les deux modes il faut trouver le bon compromis entre rutilisation et performance. De mme, il est tentant de tout externaliser dans le moteur de rgles, nanmoins si on considre les typologies suivantes : Rgles mtiers ; Rgles organisationnelles ; Pr & post conditions sur les services ; Rgles dorchestration (enchanement). Seules les trois premires se prtent cet usage sachant que seules les rgles complexes sont intressantes externaliser. Les rgles mtiers simples, comme des totaux, peuvent demeurer en langage natif.
2.11.2 Workflow Le workflow est vu ici au sens workflow humain c'est--dire une brique logicielle mettant en uvre des processus longs incluant la fois des actions informatises et des actions non informatises ncessitant lintervention dun humain. Le workflow dans une architecture SOA peut tre vu videmment comme un consommateur de services mais aussi, et cela est souvent moins anticip, comme un fournisseur. En effet, un objet mtier peut trs bien tre sous le contrle dun workflow pour les dmarches administratives lies la rglementation (dlai de prise en compte dune rclamation) mais aussi sous le contrle dun applicatif mtier pour les actes de gestion courts. Lapplicatif mtier interagira donc avec le workflow pour : Dune part lalerter dactions mtier sur lobjet mtier ; Dautre part vrifier ladquation entre lacte de gestion et ltat de lobjet dans le cas dactions non-humaines (notion dhabilitation inter-processus).
2.11.3 EAI / ESB LEAI est un ensemble de technologies que lon dcoupe en trois parties : Les connecteurs ; La couche de transport (M.O.M.) ; Le courtier. Les connecteurs sont les interfaces techniques qui permettent de faire la passerelle entre le M.O.M. et la technologie cible laquelle on souhaite accder (une transaction IMS, un programme Java). Le M.O.M. soccupe du bon acheminement des messages. Le courtier plusieurs rles, tout dabord celui de router les messages vers la bonne cible mais peu aussi tre un orchestrateur de petit processus.
LESB remplit les mmes fonctions quun EAI sauf quil sappuie exclusivement sur les standards du march (WebServices et J2EE principalement).
Figure 10 - Fonctions d'un EAI / ESB
3 Conclusion
3.1 Apprhender SOA
SOA est rellement une approche novatrice qui amne reconsidrer le S.I. dans son ensemble. La consquence immdiate de cet tat de fait est une complexit inhrente lapproche puisque toutes les composantes du S.I. doivent tre prises en considration. Chaque chantier mentionn dans ce document est un sujet part entire et ncessite un approfondissement. La dmarche doit sinscrire dans un schma directeur 5 ou 10 ans. Les investissements humains et financiers sont importants et tout calcul de ROI savre tre un exercice prilleux voire impossible. Limplication du plus haut niveau de Management de lentreprise est donc ncessaire.
Annexes
3.2 Nomenclature
SOA brassant des technologies diverses mais aussi des concepts mtiers tout aussi varis, il est important dtablir une terminologie, et de positionner une topologie du Systme dInformations. La dfinition de ce vocabulaire permet dchanger autour de concepts compris et partags par tous ce qui facilite lchange et le dialogue.
3.3 Glossaire
Consommateur (Service) Container EJB Un service consommateur est celui qui initie lchange avec un fournisseur.
Serveur spcifique, rattach un serveur dapplications, dans lequel sexcute les EJB et grant leur cycle de vie mais aussi la load-balancing. Data Access Object, design pattern UML permettant de masquer la technologie de persistance au service appelant. Entity Java Bean, API JEE permettant la ralisation de composants fonctionnant en architecture n-tiers & distribus. Il existe plusieurs types dEJB : Entity (Entit) : pour la persistance des donnes, il en existe deux sortes : BMP (Bean Managed Persistence) pour lequel il faut produire le code daccs aux donnes. CMP (Container Managed Persistence) pour lequel le conainer gre laccs aux donnes. Session : contenant les services mtier, deux sortes existent: Stateless (sans tat) : ne garde pas la mmoire de la conversation utilisateur. Satetfull (avec tat) : garde la mmoire de la conversation utilisateur. Message Driven : lEJB est activ rception dun message via un M.O.M.
DAO
EJB
Fournisseur (Service) M.O.M.
Un service fournisseur est un service qui rpond une sollicitation.
Middleware Orient Message. Technologie permettant lchange de messages asynchrone entre systmes. Lorchestration est une opration algorithmique denchainement de services. Plain Old Java Object, classe Java simple, nhritant daucune classe ou nimplmentant aucune interface issues dun quelconque framework Java.
Orchestration POJO
Post conditions
Partie algorithmique dterministe dun service, rpondant par vrai ou faux en aval du traitement du service. En cas de rponse affirmative, le consommateur la garantie que le service pourra rpondre correctement. Partie algorithmique dterministe dun service, rpondant par vrai ou faux en amont du traitement du service. En cas de rponse affirmative, le consommateur la garantie que le service sexcutera correctement. Mode denchanement de services dans lequel chacun appel le suivant. Un service expose un algorithme spcifi de manire formelle au travers dune signature de service et potentiellement des pr- et post-conditions. Standard XML pour spcifier les structures de donnes (types, lments et attributs).
Pr conditions
Propagation Service
XML Schema (XSD)

SOA Pas A Pas 0

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

SOA Pas A Pas 0

Încărcat de

Drepturi de autor:

Formate disponibile

Xebia IT Architects SAS 10/12 Avenue de lArche 92419 Courbevoie Cedex Tl : 01 46 91 76 16 www.xebia.

SOA pas pas Une exprience relle

SOA pas pas

Luc Legardeur Prsident Xebia

Table des matires

Table des illustrations

1.2 Les deux approches : Top Down ou Bottom Up

Figure 1 - Bottom-up & Top-down

2.1.2 Critres de vigilance

Choix de loutil de modlisation

2.2 Interconnexion technique

Figure 2 - Echange entre services

2.2.2 Critres de vigilance

Dissociation code mtier / code technique dexposition

Scurit des messages

2.3 Lintermdiation fonctionnelle

Figure 3 - Intermdiation fonctionnelle

2.3.2 Critres de vigilance

Architecture & conception fonctionnelle

2.4 Socle de dveloppement : industrialisation et solidification

2.5 Mise en place dun catalogue de services (Registry)

Le catalogue doit tre et rester lunique point de rfrencement des services.

2.5.2 Critres de vigilance

Modlisation & conception du catalogue

Le catalogue doit tre modlis par un architecte fonctionnel.

Couverture des besoins

2.6 La gestion des paramtres (MDM)

Figure 4 - Principes d'un MDM

2.6.2 Critres de vigilance

2.7 La ncessit des formats pivots

Figure 5 - Sans format pivot, multiplication des formats

Figure 6 - Formats pivots par domaine

2.7.2 Critres de vigilance

Etape des ngociations

Dcision de ne pas faire de formats pivots

2.8 La contextualisation des services

Figure 7 - Contextualisation des services

2.8.2 Critres de vigilance

2.9 La supervision et la gestion de la scurit

2.10 Batch et SOA

Figure 9 - Batch et fil de l'eau

2.10.2 Critres de vigilance

Fil de leau ou ensembliste

2.11 Positionnement de certaines briques concourant SOA

Figure 10 - Fonctions d'un EAI / ESB

Fournisseur (Service) M.O.M.

Un service fournisseur est un service qui rpond une sollicitation.

XML Schema (XSD)

S-ar putea să vă placă și