d'information ou comment tirer partie des standards d'Internet dans les entreprises. par Jean-Paul Figer, ARMOSC Publi le 26 dcembre 2008 - Mis jour le 30 dcembre 2008
Mail Imprimer XML source de l'article Share on facebookShare on twitterShare on pinterest_shareShare on linkedinShare on google_plusone_shareMore Sharing Services59 Principales rubriques Contexte Modularit et encapsulation Scurit Unicit de la localisation d'une information Unicit de la localisation du pilotage des activits Garantie de la cohrence fonctionnelle Asynchronisme des pilotes Non-exclusivit des donnes Services sans tats Rfrentiels passifs Annexes Annexe 1 : le style d'architecture REST Annexe 2 : [Optimistic locking] Annexe 3 : Les alertes, les affaires et les indicateurs mtier Ce guide prsente des principes d'urbanisation fonds sur un style d'architecture REST. Quelques lments du style REST sont fournis en annexe 1. J'ai aussi crit un article dtaill sur REST ici. Ces principes restent valables quel que soit le style d'architecture pour l'urbanisation de tout systme d'information complexe. Cet article a t publi sous le numro H6000 dans la rubrique Architecture des systmes des Techniques de l'Ingnieur. Contexte
2 Les Systmes d'Information de la plupart des grandes entreprises se sont construits graduellement au cours des vingt dernires annes sous forme d'applications indpendantes o les informations sont dupliques. Ceci se traduit par les cinq fameuses ruptures : Rupture des applications : les mises jour des donnes ne sont pas rpercutes entre applications ; Rupture des identifiants : une mme information est accessible via de multiples identifiants. Par exemple un mme article est identifi diffremment par l'application de gestion des commande et par l'application de gestion des stocks, ce qui rend les rpercutions des mises jour difficiles voire impossibles ; Rupture de la chane informatique : les changes entre applications ne sont pas industrialiss, ce qui entrane des dfauts de traitement et des erreurs dans la rpercutions des mises jour ; Rupture temporelle : les dlais de rpercussion des mises jour d'information entre applications sont longs (plusieurs semaines voire plusieurs mois) ; Rupture gographique : les donnes sont disperses dans les applications implantes dans les diffrentes entits gographiques (pays par exemple). Il en rsulte des incohrences, des saisies multiples et un service peu satisfaisant pour les utilisateurs et pour l'entreprise.
Pour rsoudre ces ruptures, il est souvent dcid de restructurer le systme d'information autour de rfrentiels de donnes transverses accessibles et utiliss par l'ensemble des traitements informatiques comme indiqu sur la figure ci-dessus. Ce choix, qui pourrait paratre purement technique, a en fait de nombreuses implications au niveau mtier et fonctionnel. Ce choix impose le respect d'un corpus de principes de conception, sous peine soit de rintroduire les ruptures soit de rendre ingrable la complexit du systme d'information. L'objet de ce document est d'expliciter les principaux principes de ce corpus. Ce choix a aussi des implications importantes au niveau de la conception applicative et de l'exploitation informatique. Pour simplifier l'expression des principes, on se place dlibrment dans un style d'architecture informatique REST. Pour des dtails sur le style REST, voir en annexe 1 et l'article sur ce site)
3 Cet article emploie les concepts issues du modle MDA -Model Driven Architecture- de l'OMG -Object Management Group-. Ce modle dfinit 3 vues principales : CIM -Computation Independent Model- ou modle mtier ; PIM -Platform Independent Model- qui est SOA REST ; PSM -Platform Specific Model- qui dans le cas de REST est une transformation triviale. Les principales caractristiques du style d'architecture REST qui sont utilises dans ce document sont : La notion de Ressource dsigne par un identificateur unique global URI ; Le protocole sans tat HTTP qui permet d'obtenir une reprsentation de la ressource souvent appele information dans ce document ; Des liens hypermdias pour donner accs au contenu des informations (donnes et mtadonnes) et pour spcifier les transitions entre tats des traitements ; Les types MIME comme text/xml, text/html, image/jpeg, application/pdf, video/mpeg pour la reprsentation des ressources. Il n'y a pas de raison qu'un nouveau protocole ne soit pas mieux adapt REST que le protocole HTTP. Il faut cependant noter que les protocoles plus anciens ne fournissent pas suffisamment de mtadonnes ou ncessitent trop d'interactions avec le rseau. Modularit et encapsulation
Principe 1 : Modularit et encapsulation Le Systme d'Information est partitionn en sous-ensembles fortement cohrents et faiblement coupls : les Services Fonctionnels (SF). Ce principe est un principe li au systme d'information et n'est pas un principe mtier. Il dcoule de 2 raisons principales : Complexit de ralisation : il est illusoire de vouloir construire un SI de la taille d'un SI d'entreprise, en particulier d'une grande entreprise, en un seul morceau et il est ncessaire de le dcouper en sous-ensembles plus faciles apprhender ; Facilit de maintenance : dans un SI de la taille d'un SI d'entreprise, il est indispensable de pouvoir modifier une partie du SI tout en contrlant les impacts, en particulier la localisation de
4 ces impacts, de manire ne pas avoir reconstruire et requalifier l'ensemble du SI chaque volution. Pour cela, on segmente le SI suivant des critres fonctionnels par identification de sous- ensembles fortement cohrents et faiblement coupls : fortement cohrents : les donnes et les traitements l'intrieur d'un sous-ensemble sont conceptuellement proches ; faiblement coupls : une volution d'un sous-ensemble impacte au minimum les autres sous- ensembles. Ces sous-ensembles sont appels Services Fonctionnels (SF). Il s'agit d'une structuration purement fonctionnelle, les aspects applicatifs ou techniques n'entrent pas en ligne de compte ce niveau. Les Services Fonctionnels sont de 2 types : Services Fonctionnels Silos (SFS): ils fournissent l'ensemble du SI les services lis leurs donnes - c'est leur dimension silo de donnes ou rfrentiels Services Fonctionnels Pilotes (SFP) : ils fournissent la ralisation d'un ensemble de traitements. Afin de maximiser la facilit de maintenance du systme d'information, il est essentiel de limiter et de contrler les impacts d'une modification locale de l'implmentation d'un SF - par exemple lors de la correction d'un bogue ou d'une volution non fonctionnelle pour amliorer les performances ou lors d'un changement de plate-forme technologique. Dans ce cadre, les SF doivent masquer les dtails internes de leur implmentation, en particulier la structuration interne du stockage de leurs donnes. Les SF ne donnent donc accs leurs donnes que via des offres de services prcisment dcrites et publies. Ceci est rsum dans la rgle suivante : Rgle 1a Les SF Silo encapsulent leurs donnes et communiquent via des offres de services dcrites et publies. Scurit "...La faiblesse du modle habituel de dfense d'un primtre, gnralement utilis par les entreprises, est devenue douloureusement vidente." Rapport PITAC de fvrier 2005 remis au Prsident des Etats-Unis : Cyber Security, a crisis of Prioritization La dfense d'un primtre habituellement employe par les entreprises consiste protger l'intrieur d'un systme informatique contre un attaquant venu de l'extrieur. Les inconvnients sont nombreux : Ds que la barrire est franchie (vulnrabilit logicielle, erreur oprateur,...), l'attaquant peut compromettre l'ensemble des systmes sans gure plus d'efforts que pour en compromettre un ; Il n'y a pas de protection contre un attaquant de l'intrieur ; La distinction intrieur/extrieur disparat avec la prolifration des quipements connects, le Wi- Fi, la complexit des rseaux. Il convient donc de remplacer le modle "dfense d'un primtre" par un modle plus raliste, la suspicion rciproque. On remplace la dialectique : Question : Qui dois-je craindre ?
5 Rponse : j'interdis ! par Question : En qui puis-je avoir confiance ? Rponse : j'authentifie et j'autorise. Cette distinction permet de dcoupler les contraintes de la scurit du SI de celles de l'infrastructure technique. La scurit repose sur la scurisation des changes deux deux, pas sur la scurit d'une zone ou d'un rseau. Chaque service authentifie les demandes et autorise ou n'autorise pas chaque transaction. Si ncessaire le canal de communication (HTTPS) ou tout ou partie de la transaction peut tre chiffr pour garantir l'intgrit et la confidentialit des informations.
Principe 2: Scurit La scurit est fonde sur une infrastructure de confiance : authentification rciproque des acteurs avant d'autoriser les changes. Chaque SF gre ses propres rgles d'autorisations. Une rgle de scurit stricte stipule que les flux de contrle sont toujours l'initiative du destinataire (mode Pull). Chaque SF garde donc un contrle total sur ses donnes. La raison de ce principe est l'augmentation des risques cause par la concentration de l'ensemble des donnes dans un ensemble de rfrentiels. Le piratage d'un des rfrentiels aura potentiellement des impacts sur l'ensemble des traitements de l'entreprise. Il devient donc essentiel d'isoler de manire stricte les lments auxquels le monde extrieur a accs et qui sont potentiellement la cible des pirates informatiques. Seul le SF peut modifier ses donnes son initiative. Afin de se prmunir, autant que possible, de l'imagination des pirates informatiques qui pourraient trouver des failles dans les mcanismes de scurit, il est ncessaire de pouvoir dconnecter 'physiquement' un SF en cas de suspicion d'intrusion. Il s'agit alors d'un mode dgrad, par exemple les commandes des internautes seront traites plus lentement. La dure de cette dconnection dpend des analyses effectuer et potentiellement de la dure de la mise en place de nouveaux mcanismes, ce qui peut prendre plusieurs jours. Ceci justifie la rgle suivante : Rgle 2a : Chaque SF doit pouvoir fonctionner temporairement de manire autonome. Cette rgle amliore la scurit et la robustesse des systmes en limitant la propagation des incidents.
6 Unicit de la localisation d'une information
Principe 3 : Unicit de la localisation d'une information Une information est gre en un point unique du systme d'information. Il peut exister des copies des informations pour assurer l'archivage, certains recoupements en temps diffr ou d'autres raisons. Ces copies ne sont pas accessibles directement par les rfrentiels ou les traitements du systme d'information. L'objectif de ce principe est de garantir le maintien de l'intgrit et de la fracheur des informations dans le Systme d'Information. Il s'agit ici de bien distinguer le concept de donne du concept d'information : une mme donne peut correspondre des informations diffrentes. Par exemple, l'adresse courante d'un client et l'adresse indique sur une facture peuvent tre la mme donne mais pas ncessairement la mme information : si le client a coch la case 'livraison mon adresse habituelle' alors il s'agit de la mme information, sinon il s'agit de la mme donne mais de deux informations diffrentes - cette distinction est importante en particulier si le client vient de faire une demande de changement d'adresse par courrier postal et passe une commande par internet avant que le changement d'adresse ne soit effectif. Le principe ci-dessus s'applique aux informations et pas aux donnes : les donnes doivent tre dupliques quand il s'agit d'informations diffrentes. La premire partie du principe est le fondement de l'approche permettant d'viter les ruptures et l'incohrence des informations. La deuxime partie du principe reconnat le caractre particulier des copies du systme d'information : Les traitements de ces copies ne participent pas de manire synchrone l'activit courante de l'entreprise ; Ces traitements ont besoin d'une structuration spcifique des donnes pour permettre les recoupements, et ces traitements n'ont pas besoin d'informations fraches (au contraire, ils utilisent en gnral des historiques, souvent des informations de millsimes prcdents). Une consquence importante de ce principe est la suivante : Rgle 3a Les modles de donnes des rfrentiels sont disjoints deux deux. Cette consquence implique le concept d'identifiant unique informatique ou URI dans le modle REST. Dans la plupart des cas, cet identifiant unique sera un URL fourni par un service rfrentiel, c'est dire le lien vers la ressource qui fournit l'information. Lorsque cette information n'existe pas dans le systme ou
7 n'est pas un document numrique, il est possible d'utiliser un URN comme par exemple pour un livre urn:isbn:3-540-43081-4 Rgle 3b Chaque information du Systme Informatique possde un URI, qui vrifie les 4 proprits : non-signifiance : un identifiant n'a pas de signification. non-modification : un identifiant ne peut pas tre modifi. non-rutilisation : un identifiant ne peut pas tre rutilis mme aprs destruction de la donne associe. non-destruction : un identifiant ne peut pas tre dtruit mme s'il n'est plus utilis. Cet URI qui permet de grer des relations entre les diffrentes informations du systme d'information. Un rfrentiel contient donc ses donnes et des URI permettant de pointer vers les informations des autres rfrentiels. La proprit de non-signifiance est une consquence du principe d'unicit de la localisation d'une information (principe 3) : si l'identifiant tait signifiant alors il y aurait duplication d'information et donc fort risque d'incohrence. Prenons par exemple le numro de scurit sociale d'une personne. Ce numro ne peut pas servir comme identifiant informatique car on pourrait en dduire la date de naissance de la personne ; si jamais il s'avrait que la date donne lors de l'attribution du numro tait fausse alors il faudrait corriger la date de naissance dans le rfrentiel des personnes - mais alors tous les autres applicatifs qui utilisent le numro de scurit sociale pour en dduire l'ge donneraient des rsultats incohrents. Pour viter ces incohrences, on pourrait imaginer de changer l'identifiant pour y mettre la bonne date de naissance mais il faudrait alors diffuser cette modification dans tous les rfrentiels qui font rfrence cette personne. Il faudrait donc soit grer dynamiquement la liste des rfrentiels qui font rfrence cette personne, soit avertir tous les rfrentiels. Dans les deux cas, il s'agit de mcanismes complexes et difficiles rendre rsistants tous les types de pannes possibles. Il est clair qu'il est beaucoup plus simple et robuste d'utiliser des identifiants non signifiants et d'invoquer le rfrentiel des personnes pour connatre la date de naissance. La proprit de non-modification permet de garantir la prennit des identifiants. En effet, comme nous l'avons vu, un URI peut tre stock dans d'autres rfrentiels. Si on modifiait cet identifiant, alors les rfrences contenues dans les autres rfrentiels deviendraient invalides et les relations entre ces informations ne pourraient plus tre faites. Il faudrait donc avertir les autres rfrentiels de la modification pour qu'ils la prennent en compte. Comme ci-dessus, on pourrait diffuser la modification l'ensemble des rfrentiels mais cela gnrerait un gigantesque trafic de messages de modification dans un systme de la taille d'un systme d'information d'entreprise. On pourrait aussi ne diffuser qu'aux rfrentiels qui font rfrence cet URI, ce qui imposerait de grer une liste inverse des rfrences ; autrement dit un rfrentiel devrait savoir tout moment qui fait rfrence chacune de ses informations - c'est clairement un mcanisme complexe et difficile rendre robuste aux erreurs. Dans les deux cas, il faudrait grer les cas d'indisponibilit des rfrentiels (panne ou maintenance programme), ce qui ajouterait un niveau de complexit et de risque de dysfonctionnement. Les proprits de non-rutilisation et de non-destruction servent garantir que les identifiants feront bien toujours rfrence l'information laquelle ils doivent faire rfrence - autrement dit, viter que la commande de Mme Michu ne soit attribue plus tard par erreur M. Martin (c'est essentiel pour la traabilit lgale). Unicit de la localisation du pilotage des activits
8
Principe 4 : Unicit de la localisation du pilotage des activits L'utilisation du systme d'information est modlise sous forme d'activits mtier. Une activit mtier est une unit de travail, telle que vue par l'utilisateur final, et doit respecter la rgle des 4 units suivante : unit de lieu, unit de temps, unit d'acteur et d'action. Toute activit mtier est pilote de bout en bout sans dlgation par un unique service fonctionnel Pilote (SFP), qui enchane des demandes de services des services fonctionnels Silo. La premire partie du principe se justifie par le besoin pour un systme d'information d'entreprise d'un minimum de normalisation et d'homognisation des concepts de modlisation au niveau mtier et par la cohrence ergonomique qui en dcoule, ceci pour viter la cration d'un capharnam prjudiciable la fois aux informaticiens et, aussi, aux utilisateurs. La seconde partie de ce principe est l'quivalent au niveau des traitements de l'unicit de la localisation des informations (principe 3). Sa justification en est similaire : il s'agit de rendre le systme d'information modulaire en limitant les couplages forts (on notera que la rgle des 4 units de lieu, de temps, d'acteur et d'action garantit dj une forte cohrence de l'activit donc un couplage plus faible avec l'extrieur). En effet, clater le pilotage d'une activit sur plusieurs SFP signifierait que ces SFP se passeraient le relais en cours d'une interaction, interaction qui est pourtant vue par l'utilisateur comme une unit de travail. Pour viter les ruptures ergonomiques et smantiques, ce changement de pilote ncessiterait une forte connaissance rciproque des SFP, jusqu'au niveau de l'enchanement de leurs crans, et entranerait donc un couplage fort qui conduirait complexifier et rigidifier le systme d'information - donc des cots et des dlais de maintenance fortement accrus. D'autre part, les cascades de passages de relais successifs de SFP en SFP rendraient trs complexe le traitement des cas non nominaux - en particulier les erreurs. En effet si une erreur (fonctionnelle ou technique) se produisait dans le troisime SFP au bon endroit dans le bon cran, o il est fort possible qu'il faille retourner dans le premier SFP qui est celui qui porte l'enjeu de l'activit. Pour garantir une ergonomie acceptable l'utilisateur, il faudrait donc introduire un couplage fort entre les diffrents SFP de la cascade. Bien entendu, ce principe ne doit pas tre utilis pour recrer un systme d'information cloisonn ; le SFP responsable de l'activit doit faire les demandes de services appropris vers les services fonctionnels Silos appropris. Certains traitements ne respectent pas la rgle des 4 units : il s'agit d'enchanements d'activits soit sur des priodes temporelles diffrentes soit par des acteurs diffrents. Ces traitements doivent aussi tre
9 pilots - mais sans introduire de couplage fort entre SF. Pour cela on introduit le protocole de syndication/publication ATOM qui est dtaill en annexe. Garantie de la cohrence fonctionnelle
Principe 5 : Garantie de la cohrence fonctionnelle Une information est proprit de son service fonctionnel Silo qui est seul responsable de la garantie de sa cohrence fonctionnelle. Ce principe peut paratre une simple consquence du principe d'unicit de la localisation de l'information (principe 3) ; c'est en fait un changement de paradigme fort mais subtil dont les consquences sont nombreuses. Dans un systme d'information en mode cloisonn, les informations sont totalement gres par une application, qui connat tous les traitements pouvant agir sur celles-ci. Le concepteur d'une application peut donc, quand il spcifie un traitement, prendre en compte les besoins des autres traitements de l'application - par exemple, interdire certaines modifications des donnes qui sont tout fait correctes dans le cas particulier de ce traitement mais qui introduiraient des incohrences dans d'autres traitements de l'application. Cette approche a montr ses limites : quand l'application grossit, le risque d'oublier une de ces interdpendances caches devient grand et augmente trs significativement les cots et dures des actions de maintenance volutive de l'application - au point parfois de figer le systme d'information par peur d'introduire des rgressions dues ces interdpendances implicites difficilement matrisables. Dans un systme d'information en mode cloisonn structur en nombreuses petites applications, cette approche tentante est souvent source de gains en dure de ralisation, pourvu que l'on accepte les ruptures applicatives, la duplication des informations et leurs incohrences potentielles - incohrences que l'on peut parfois amoindrir par de gros travaux priodiques dits de remise en cohrence (habituellement tous les quelques mois). Dans le cadre d'un systme d'information d'entreprise structur autour de rfrentiels, la limite dcrite ci- dessus prend vite toute sa mesure et il est illusoire de croire que l'on pourra construire (et encore moins maintenir) un systme d'information bas sur des interdpendances implicites, qui seraient ncessairement en grand nombre (du simple fait de sa taille). Il est donc ncessaire de rendre explicite toutes les interdpendances. Le lieu le plus adapt pour cela est le service fonctionnel Silo dans sa dimension Rfrentiel : les services fonctionnels Silos sont donc les seuls garants de la cohrence transverse des informations. Les consquences sont multiples.
10 Rgle 5a Aucun traitement ne peut supposer le respect, mme temporaire, d'une rgle de cohrence d'un ensemble d'informations si cette rgle n'est pas explicitement garantie par un service fonctionnel Silo. En effet, comme les informations sont accessibles par tous les traitements, rien ne garantit qu'un autre traitement n'ait pas modifi ces informations sans prendre en compte cette contrainte de cohrence - contrainte dont il n'a pas avoir connaissance. Si cette contrainte est absolument ncessaire pour garantir l'intgrit du traitement (voire du systme d'information en entier), alors il faudra durant la phase de conception allouer un service fonctionnel la responsabilit de la rgle de cohrence correspondante. Cette rgle de cohrence devra tre explicitement et prcisment dcrite dans la spcification du rfrentiel (SF Silo). Il s'agit ici de trouver le bon quilibre entre trop peu de rgles dans les rfrentiels, au risque de ne plus garantir la cohrence transverse du systme d'information, et trop de rgles dans les rfrentiels, au risque de faire porter aux rfrentiels de rgles qui ne sont pas fondamentales. Il ne faut pas en particulier que les rgles garanties par les rfrentiels ne soient en totale abstraction avec l'aspect dynamique du monde rel - par exemple le strict respect d'une rgle du genre une situation B est interdite si une situation A s'est produite dans le pass n'est possible que si l'on oublie que la situation A tait peut-tre une erreur de saisie. Rgle 5b Aucun traitement ne peut faire d'hypothse sur l'histoire d'une information, en dehors de l'historique gr par un rfrentiel. Cette rgle peut sembler une consquence simple du rle transverse des rfrentiels (par exemple, un autre traitement peut avoir modifi l'information). Elle va cependant l'encontre d'une habitude des concepteurs d'applications en mode cloisonn qui font souvent des hypothses du genre : si tel attribut est telle valeur c'est que tel traitement l'a positionn et comme je sais que ce traitement vrifie ceci, je peux donc faire cela sans risque . Dans une approche base sur des rfrentiels transverses de telles hypothses ne sont simplement plus valides car rien ne garantit qu'un traitement a modifi un attribut donn. S'il est ncessaire de savoir si un certain traitement mtier a t appliqu sur une donne, alors il faut explicitement stocker cette information dans un rfrentiel (par exemple dans le cadre d'un client, ajouter un attribut signifiant que ses capacits de paiement ont t vrifies). Un traitement n'a pas savoir qui, en terme applicatif, a t le support du traitement mtier : le fait que l'information soit stocke dans le rfrentiel lui suffit (sinon on introduirait des interdpendances caches). Bien sr, la signification de cette information doit tre clairement dfinie par le rfrentiel et accepte par tous. Ces deux rgles s'appliquent mme si le traitement est celui qui a cr ces donnes. Ceci peut paratre vident mais n'est pas intuitif, en particulier pour les concepteurs habitus des applications en mode cloisonn propritaires exclusifs de leurs donnes. Asynchronisme des pilotes
11
Principe 6 : Asynchronisme des pilotes (ou l'illusion du temps absolu pour les pilotes) Les services fonctionnels Pilotes ne peuvent prsupposer qu'ils seront synchroniss sur une mme base temporelle, en particulier vis vis de la mise jour des donnes des rfrentiels Ce principe dcoule pour partie de la complexit, voir l'impossibilit, de synchroniser un ensemble de processus aussi vaste celui d'une entreprise dans sa globalit et pour partie du besoin de faible couplage entre les diffrents services fonctionnels. En effet, la plupart des processus sont souvent initialiss de manire indpendante par des acteurs distincts qui ont des contraintes temporelles diffrentes. Ces contraintes sont souvent hors du contrle de l'entreprise (contraintes lgislatives ou imposes par un acteur externe pour des raisons commerciales). Par exemple, un avis d'imposition doit tre envoy l'adresse connue de l'usager au moment de la signature du rle mais un usager peut demander un changement d'adresse entre la signature du rle et l'mission de l'avis. Une solution tentante consisterait interdire les demandes de changement d'adresse pendant les priodes entre la signature des rles et l'missions des avis. Ceci imposerait une contrainte forte l'usager - contrainte qui n'est pas conforme la volont actuelle de l'Administration Fiscale. D'autre part, il faudrait vrifier qu'aucun autre processus ncessitant ce changement d'adresse n'interviendra durant cette priode. Il est clair que l'on introduirait un couplage fort entre les processus, couplage qui conduirait une rigidit forte du systme d'information et des processus mtier. Il est important de noter que ce phnomne est une consquence intrinsque de la mise en place des rfrentiels transverses ; les applications en mode cloisonn qui grent leurs propres copies des informations n'ont pas ce genre de problmes, mais au prix d'une incohrence des informations et d'un service dgrad pour l'entreprise, ses clients ou ses partenaires. Il ne sert donc rien d'essayer de combattre ce phnomne, mais il s'agit bien de l'accepter car la solution est simple : il suffit de garder un historique de toutes les modifications des informations des rfrentiels. Avec cet historique, le processus de changement d'adresse peut s'excuter tout moment car le pilote en charge de la cration de l'avis demandera au rfrentiel non pas la dernire adresse connue de l'usager mais bien son adresse au moment de la signature du rle fiscal. Ceci se rsume dans la rgle suivante : Rgle 6a Toutes les modifications des informations des rfrentiels sont places dans un historique.
12 Cette historique impose tous les silos de partager une base de temps commune, c'est dire une horloge commune. D'un point de vue technique les mcanismes correspondants existent et sont simples mettre en oeuvre (serveurs de temps). Cette rgle s'applique aussi, en conjonction avec la rgle de non-destruction des identifiants, la suppression des donnes : Rgle 6b Les informations ne sont pas dtruites mais marques comme invalides partir d'une certaine date. Cette rgle soulve la question des purges et des archivages. Les concepts de purge et d'archivages sont lis aux contraintes physiques des supports de stockage de masse (disques durs) : ces supports avaient auparavant des capacits trs limites ncessitant de purger et d'archiver les donnes les plus anciennes ou peu utilises. Ceci imposait la mise en place de mcanismes complexes, en particulier pour rapatrier les donnes archives en cas de besoin et pour les purger nouveau. Ces mcanismes, dj compliqus dans le cadre d'une application dans un systme d'information cloisonn, deviennent extrmement complexes dans le cadre de l'ensemble d'un systme d'information d'entreprise centr sur des rfrentiels transverses. La trs forte augmentation des capacits des systmes de stockage permet actuellement de se passer de ces mcanismes dans la plupart des cas et donc de simplifier trs significativement la conception du systme d'information. D'autre part, la gnralisation des obligations d'audit (traabilit industrielle ou contraintes de type Sarbanes-Oxley) imposent la non destruction de la plupart des donnes historiques de l'entreprise. Une attention particulire doit tre mise dans les cas o la destruction relle des informations est une obligation lgale forte (par exemple les contraintes CNIL) ; il s'agit alors de vrifier l'impact de cette obligation sur l'ensemble des processus. Une autre consquence de ce principe est la prconisation de permettre l'activation simultane des traitements conversationnels et non conversationnels (les travaux par lots [batch]). En effet, il est habituel de rserver les traitements non conversationnels pour la nuit, en dehors des heures de travail quand les ressources matrielles (les machines) ne sont pas utilises par les traitements conversationnels. Ceci permet d'optimiser l'utilisation des ressources matrielles. Cette rgle de bon usage des ressources s'est souvent transforme au fil du temps en une rgle fonctionnelle et les concepteurs ont souvent tir parti de cette exclusion pour faciliter la rdaction des spcifications fonctionnelles. Ceci est clairement un couplage entre processus, dont nous avons vu les inconvnients. De plus, dans le cadre de rfrentiels transverses gographiques, le territoire couvert par un pilote peut tre dispers sur plusieurs fuseaux horaires, ce qui impose un large talement des horaires de disponibilit des traitements conversationnels. Les exclusions fonctionnelles entre traitements conversationnels et non conversationnels imposent donc : soit de rduire trs fortement la fentre temporelle disponible pour les traitements non conversationnels, soit de demander aux employs de certains pays de travailler hors des horaires habituels dans leur pays. Ce phnomne est encore amplifi par l'Internet o l'exprience a montr que les internautes exigent une plage d'ouverture des services trs tale, voire continue (24h sur 24h et 7 jours sur 7). Ceci justifie donc la rgle suivante : Rgle 6c Les activits doivent tre modlises de manire permettre l'activation simultane des activits conversationnelles et des activits non conversationnelles.
13 Cette rgle qui peut paratre contraignante est en fait simple mettre en oeuvre grce l'historisation des donnes (rgle 6a) et au concept classique de date de valeur (celui qui est utilis par toutes les banques et que l'on retrouve sur les relevs bancaires que nous recevons tous). Non-exclusivit des donnes
Principe 7 : Non-exclusivit des donnes (mme de manire temporaire) Les services fonctionnels Pilotes ne peuvent rserver, mme de manire temporaire, un accs exclusif une donne d'un rfrentiel. Ce principe est en fait trs similaire au principe d'asynchronisme (principe 6), avec une dimension supplmentaire lie la complexit des donnes. Dans les applications en mode cloisonn, la gestion des potentiels conflits d'accs entre plusieurs utilisateurs sur une mme donne est gnralement faite via des mcanismes de rservation : l'utilisateur annonce son intention de travailler sur une donne et l'application en interdit l'accs (au moins en modification) aux autres utilisateurs. Ce mcanisme de verrouillage des donnes est gnralement mis en oeuvre quand l'activit de l'utilisateur est relativement longue : de quelques heures quelques jours. Dans le cas d'un systme bas sur des rfrentiels transverses, une telle rservation impliquerait qu'aucun autre processus de l'ensemble du systme fiscal ne pourrait modifier cette donne. Cette rservation, qui tait voulue et acceptable sur une sous-partie du systme d'information, prend une ampleur difficilement contrlable quand elle s'applique sur l'ensemble du systme. En effet la smantique de la rservation devient vite complexe dfinir prcisment et entrane rapidement un couplage fort entre processus - couplage dont nous avons vu les inconvnients majeurs. Prenons l'exemple d'un contribuable dont on est en train de changer la situation fiscale. Cette modification peut prendre plusieurs minutes voir plusieurs heures, en particulier si l'agent est interrompu (tlphone) ou si l'agent doit chercher des informations supplmentaires. On pourrait donc vouloir 'rserver' les donnes du contribuable pour viter que quelqu'un d'autre ne les modifie en mme temps ou n'applique des traitements sur ces donnes en cours de modifications. Mais o pourrait tre stocke cette 'rservation' ? Si elle tait stocke dans le SF pilote de l'activit qui rserve, alors soit il faudrait introduire un couplage fonctionnel fort entre les SF, soit les processus des autres SF n'appliqueraient pas cette 'rservation' et pourraient donc modifier les donnes, ce qui rendrait inutile la rservation. Il faudrait donc stocker cette rservation dans le rfrentiel propritaire de la donne. D'autre part, quel serait le primtre d'application de cette 'rservation' : le client, son adresses, ses
14 moyens de paiement, ses commandes - en lecture ou en criture ? Devrait-on refuser une demande de changement d'adresse d'un client sous prtexte que l'on est en train de traiter une commande ? Devrait-on refuser un paiement ? Ensuite, se pose la question de la dure de la rservation : une rservation bloque depuis longtemps est- elle due au fait que le traitement qui a pos la raison de la rservation est toujours valide (attente d'information par courrier) ou bien au fait que l'utilisateur a t interrompu et va bientt continuer ou bien au fait qu'il a compltement oubli. Pour grer le dernier cas, il serait tentant de mettre en place un mcanisme de libration de rservation. Le mcanisme simple qui consiste tout librer tous les soirs n'est adapt qu'aux cas o l'objectif de la rservation est limit dans le temps, ce qui exclut tous les cas de rservation lie la cohrence des donnes. Dans les autres cas, il faudrait mettre en place des mcanismes complexes, par exemple envoyer des messages l'utilisateur pour lui demander de librer les donnes ou annuler toutes les modifications faites par cet utilisateur. Comme on le voit, cette simple volont de rserver une donne engendre une norme complexit fonctionnelle et/ou des contraintes mtier fortes. Il faut donc comparer le gain obtenu par rapport une situation o la donne n'est pas rserve. Or les objectifs annoncs de telles rservations sont doubles : Garantie d'une cohrence : Il s'agit de garantir une rgle de cohrence fonctionnelle considre comme importante par le processus qui rserve la donne et dont il ne veut pas qu'elle soit perturbe par un autre processus. Comme cette rservation est temporaire, rien ne garantit que cette rgle sera respecte ensuite par les autres processus : la rservation n'apporte donc aucune garantie relle. Comme nous l'avons vu dans le principe de gestion de la cohrence (principe 5), si une rgle de cohrence doit tre respecte par tous alors elle doit tre garantie de manire permanente par un rfrentiel et la rservation est alors inutile. Gestion d'une incohrence temporaire : Il s'agit de permettre de manire temporaire le non respect d'une rgle de cohrence garantie par le rfrentiel. Il est donc ncessaire de bloquer l'accs la donne pour 'cacher' ce non-respect temporaire et viter que d'autres processus appliquent des traitements sur des donnes incohrentes. Dans ce cas, on voit bien que l'on est en train d'essayer de dvoyer le principe 5 ci-dessus : la garantie de la cohrence par les rfrentiels. Il est alors beaucoup plus simple de garder cet tat intermdiaire incohrent dans le SF pilote et de mettre jour les rfrentiels ds que les donnes sont cohrentes du point de vue du rfrentiel. Il est important ici de noter qu'il ne s'agit pas d'attendre que les donnes soient cohrentes du point de vue du pilote - nous avons vu au paragraphe prcdent que c'tait inutile - mais bien du point de vue du rfrentiel de manire ne pas recrer des applications en mode cloisonn et rendre au plus tt les donnes disponibles tous les processus. Les objectifs de la rservation de donnes, qui semblaient importants premire vue et qui pouvaient tre utiles dans systme d'information en mode cloisonn, ne sont donc plus pertinents dans une approche base sur des rfrentiels transverses. Il est noter que ce principe entrane des volutions dans l'ergonomie de certains traitements : la structuration du systme d'information autour de grands rfrentiels transverses impose une volution du dialogue homme-machine pour passer d'une logique o l'utilisateur se voit refuser une activit a priori car la donne est verrouille une logique o il se voit demander son avis a posteriori en cas de conflit. Ceci est dtaill dans l'annexe Optimistic locking . Enfin, il est important de noter que ce principe s'applique aussi pour le traitement qui a cr la donne. Ceci peut paratre vident mais n'est pas intuitif pour les concepteurs habitus des applications en mode cloisonn propritaires exclusifs de leurs donnes. Services sans tats
15
Principe 8 : Services sans tats Les services fonctionnels Silo fournissent des offres de services sans tat - laissant toujours le rfrentiel dans un tat cohrent. Le concept de service sans tat signifie que chaque activation du service est traite de manire indpendante sans rfrence aux prcdentes activations des services du SF (autrement bien sr que via les donnes stockes dans le rfrentiel). En clair, on doit fournir chaque appel du service toutes les donnes ncessaires pour traiter la demande. Cependant, tous les services fonctionnels Pilotes traitent un enchanement d'activits. Ils apparaissent donc comme des services avec tat, c'est dire des services qui s'inscrivent dans le cadre d'une session et dont les rsultats dpendent des services prcdemment invoqus dans la session. Le SF devrait garder et grer localement un tat pour chacun des clients connects. Un exemple de session est illustr par un site de commerce en ligne o l'utilisateur se connecte et ouvre une session, se 'promne' sur le site et dpose des articles dans son caddie ; le contenu du caddie est maintenu entre les diffrentes invocations du service de dpose d'un article mais il disparat la fin de la session. Dans le cadre des interactions avec un humain, le concept de session est souvent ncessaire pour offrir une ergonomie approprie aux activits des utilisateurs. Comment peut-on maintenir une session en respectant le principe 8 de Service sans tat ? Il existe de nombreuses solutions dont la description dtaille dpasse le cadre de ce document. Dans une architecture REST, la manire la plus naturelle consiste maintenir l'tat de l'application sur le poste client dans un URI ou dans un ensemble d'URI. Si le volume de donnes de session est important ou si on veut maintenir l'tat au-del de la session sur le poste client, il suffit de crer un URI temporaire dans un service de persistance. Dans le cadre des services offerts par les SF Silo, il s'agit d'une session purement informatique entre deux lments logiciels. De telles sessions et les protocoles d'interaction associs sont relativement complexes spcifier car il faut dfinir les ressources qui seront visibles dans la session mais pas hors de la session et dfinir les services lis la gestion de la session (ouvrir, fermer, annuler, reconnecter, etc...) ; il faut aussi faire le lien entre les ressources et les services de gestion de session, sans oublier les cas inhabituels (par exemple, que faire si une session est ouverte sans activits depuis longtemps : la laisser ouverte indfiniment au risque de bloquer des ressources inutilement si l'initiateur de la session a oubli de la fermer ou la fermer au risque de perdre les donnes de la session ?).
16 Au niveau technique, la gestion des sessions consomme des ressources matrielles. Cette consommation, qui tait relativement facile matriser dans un systme cloisonn au niveau applicatif et gographique, deviendrait difficilement contrlable dans un systme bas sur des rfrentiels transverses. En effet, chaque SF Silo devrait alors tre capable de grer potentiellement des sessions pour tous les SF Pilotes et pour tous les traitements de l'ensemble des utilisateurs. Le nombre de session grer simultanment par un SF Silo serait une combinaison du nombre d'utilisateur (plusieurs dizaines plusieurs centaine de milliers d'utilisateurs pour une grande entreprise) et du nombre de traitements qu'un utilisateur peut drouler en parallle (habituellement 2 3). On voit que les ressources matrielles mettre en oeuvre seraient trs significatives. Or l'utilisation de sessions correspondrait aux objectifs suivants : permettre une rservation temporaire d'une donne ou d'un ensemble de donnes pendant la dure de la session permettre de crer des tats temporairement incohrents d'une donne ou d'un ensemble de donnes pendant la dure de la session Nous avons vu ci-dessus que ces objectifs ne sont plus pertinents dans un systme d'information bas sur des rfrentiels transverses. Il n'est donc pas utile, et mme contre-productif, d'autoriser les SF Silo fournir des services tat. Ceci justifie la premire partie du principe ci-dessus. La seconde partie du principe est une consquence simple du rle de garant de la cohrence fonctionnelle des donnes par les services fonctionnels Silo : tout moment les informations du SF Silo, telles que visibles par les autres SF via les services, doivent respecter les rgles de cohrence garanties par le SF. Ce principe a une consquence importante sur la structure et la granularit des services exports par un SF : Rgle 8a Les services exports par les SF Silo sont atomiques et de granularit moyenne. Les services sont atomiques dans le sens o chaque service est trait de manire complte inscable. Si au niveau technique un service fonctionnel Silo peut traiter en parallle plusieurs services, au niveau fonctionnel tout se passe comme si les services taient traits les uns aprs le autres - en particulier, si l'excution d'un service d'un SF ncessite la mise jour de plusieurs objets du rfrentiel de ce SF, alors un service de lecture ne pourra s'insrer au milieu de ces critures. Les services sont de granularit moyenne dans le sens o une granularit trop fine ne permettrait pas de garantir que les rgles de cohrence fonctionnelle sont toujours garanties. Par exemple, si une rgle de cohrence porte sur plusieurs objets, alors un service permettant la mise jour simultane de ces objets est ncessaire - car sinon il faudrait plusieurs demandes de services pour retrouver un tat cohrent et on crerait un tat potentiellement incohrent entre les diffrentes invocations des services. Il est important de noter dans cette rgle que atomique ne veut pas dire minuscule mais bien inscable. Il n'y a donc pas de contradiction entre services atomiques et services de granularit moyenne : dans un systme d'information centr sur des rfrentiels transverses les services sont de 'gros atomes'. Comment traiter la validation deux phases ?
17
La deuxime objection souvent faite pour justifier des Services avec tat est la validation deux phases (two phase commit). Supposons qu'un SF Pilote ncessite l'enchanement de deux SF Silos, par exemple, l'enregistrement d'une commande suivi d'un paiement. L'enregistrement de la commande modifie l'tat des stocks de manire permanente. Que faire si le paiement n'est pas accept par la banque ? Il existe au moins 4 mthodes : Abandonner. C'est la solution la plus simple. Elle n'est pas toujours possible comme dans l'exemple choisie car l'tat des stocks serait incorrect. Recommencer. C'est une solution n'employer que si elle a une chance raisonnable de succs. Si le serveur de la banque a rpondu que la carte tait en opposition, il ne sert rien de ressayer. Compenser. La compensation peut tre automatique, au bout d'un certain dlai ou sur demande explicite d'annulation de commande. C'est la bonne solution dans ce cas. Coordonner. Faire une ressource temporaire qui assure la synchronisation. Cette mthode n'est pas recommande car on introduit nouveau des couplages forts entre ressources. Rfrentiels passifs
18 Principe 9 : rfrentiels passifs Un service fonctionnel Silo (rfrentiel) n'a pas vocation avertir les autres SF Silo des modifications de ses donnes. Les raisons de ce principe sont multiples. Tout d'abord nous avons vu que le pilotage des activits et des processus mtiers tait dvolu aux services fonctionnels Pilotes. Avertir pour action un autre service fonctionnel d'une modification d'une donne est un morceau de processus qui doit donc tre pilot par un service fonctionnel Pilote pas par un service fonctionnel Silo. D'autre part, la diffusion d'information par ce genre de mcanismes (dit de push) imposerait la mise en place de protocoles complexes pour traiter correctement de manire robuste les impondrables de la vie relle. En effet, lors de la mise jour de la donne, il est possible qu'un des services avertir ne soit pas disponible (panne machine ou maintenance programme). Il ne faut pas oublier que la haute disponibilit cote trs cher en dveloppement et en exploitation et qu'il faut la rserver aux composants pour lesquels il existe une relle justification mtier. Il faudrait donc dfinir un mcanisme permettant de rmettre les avis de modification tout en garantissant que les avis ne peuvent pas tre dupliqus (imaginez les consquences de la duplication d'un ordre de dbit d'un compte). Il faudrait aussi dfinir les rgles de diffusion, car avertir tous les services de toutes les mises jour de toutes les donnes demanderait une bande passante et une capacit machine astronomique. En effet il ne faut pas oublier que dans une approche base sur des rfrentiels, le taux de mise jour par rfrentiel est bien plus lev que dans le cas d'un systme cloisonn par application et par gographie. Afin de respecter le principe de couplage faible entre processus de services diffrents, il serait ncessairement la charge des diffrents services fonctionnels d'indiquer au rfrentiel les donnes dont les modifications les intressent ; ce mcanisme d'abonnement ajouterait encore la complexit des protocoles dfinir. Il est donc beaucoup plus facile de mettre en place dans les rfrentiels des mthodes qui permettent aux services pilotes de connatre les donnes qui ont t modifies sur une priode de temps donne. C'est donc chaque service Pilote, d'utiliser ces mthodes et d'accder aux historiques des modifications (cf. rgle 6a). Dans beaucoup de cas, ces mcanismes peuvent se simplifier par l'emploi d'un standard de publication des modifications. Prenons l'exemple des flux ATOM (RSS) sur l'Internet. Chaque site qui modifie ses informations met simultanment jour son ou ses flux ATOM (RSS). Un service qui doit tre inform des modifications va s'abonner ce flux, c'est dire le lire quand il en a besoin. Il pourra alors dtecter une mise jour et la traiter. Il y a dcouplage total entre le SF producteur qui publie son rythme et le SF consommateur qui va lire son rythme. Ceci se rsume dans la rgle suivante : Rgle 9a Les SF Silo (rfrentiels) doivent fournir des services ou des flux permettant aux SF Pilotes de connatre les donnes qui ont t modifies. Il est noter que ces services sont trs simples dfinir et raliser ds lors que les informations existent dans des historiques (rgle 6a). Il faut aussi noter que ces flux peuvent tre gnrs dynamiquement la demande pour gnrer facilement des alertes. Par exemple un moteur de recherche peut renvoyer les rsultats sous la forme d'un flux ATOM. Une modification du rsultat dtecte par un SF permet de gnrer une alerte. Envoyer vos remarques, suggestions ou questions Jean-Paul Figer Jean-Paul Figer, 1958-2013 J'ai travaill pendant 40 ans Capgemini. Cependant les opinions exprimes dans ces articles n'engagent que moi et ne reprsentent pas la position de Capgemini.
19 Pour tre inform des nouveaux articles, inscrivez-vous avec votre adresse mail
Annexe 1 : le style d'architecture REST Voici quelques dfinitions prcises, pour la plupart extraites du MDA de l'OMG. Architecture d'un systme L'architecture d'un systme est dfinie par un ensemble de classes d'lments et par les contraintes appliques ces lments. Les classes d'lments d'une architecture regroupent : les composants logiciels ; les connecteurs (proprits externes de ces composants) ; les relations entre les composants et les connecteurs. Les contraintes sur les lments sont dfinies en fonction des caractristiques attendues d'une architecture comme maximiser l'indpendance ou l'extensibilit, minimiser les temps de rponse, faciliter la rutilisation, etc... Service C'est une fonction logicielle autonome [self contained] qui accepte des requtes et qui renvoie des rponses au travers d'une interface standard bien dfinie. Les technologies employes pour raliser un service comme le langage de programmation ne font pas partie de la dfinition d'un service. Services sans tat [Stateless] Toutes les donnes ncessaires au traitement sont fournies l'appel du service qui renvoie une rponse sans conserver d'tat. C'est une contrainte forte pour garantir l'extensibilit et la rutilisation. Comment raliser des applications avec tat avec des services sans tat ? Le plus simple consiste conserver l'tat de l'application chez le client. Le systme est alors extensible car indpendant du nombre de clients. Si l'tat doit persister au del d'une session, il faut conserver l'tat dans des donnes persistantes. Modle [pattern] Un modle [pattern] est dfini par Martin Fowler ("Analysis Patterns", 1997) comme "une ide qui a t utile dans un contexte particulier et qui le sera probablement dans d'autres contextes". Cette notion de modle est valide tous les niveaux, depuis le morceau de code qui rsout un problme particulier jusqu' un groupe de fonctions dans un domaine comme les tlcommunications ou la comptabilit. Style d'architecture Un style d'architecture est une classe d'architectures de systmes qui ont des modles communs. Un style d'architecture dfinit une famille de systmes en terme de modles de structure, un vocabulaire
20 de composants et de connecteurs et des rgles ou contraintes sur leurs relations. L'volution des styles d'architecture est gnralement lie l'volution de la technologie. Architectures orientes service [SOA] SOA est un style d'architecture qui se dfinit par : un couplage lche [loose coupling] entre les composants logiciels pour ne pas dpendre de l'tat d'autres services et pour faciliter la rutilisation des services sans tat [stateless scalabilty] et l'ventuelle orchestration des services fortement interoprables ce qui implique l'utilisation de vocabulaires de donnes trs bien dfinis. Historique de REST REST est l'acronyme de "Representational State Transfer" invent par Roy T. Fielding dans sa dissertation "an architecture style of networked systems". Roy T. Fielding participe depuis 1994 aux travaux du W3C sur les sujets URI, HTTP, HTML et WebDAV et a t le co-fondateur du projet Apache, le serveur Web qui quipe 60% des sites Web de tout l'Internet. REST dcrit les caractristiques du Web qui en ont fait son succs. L'explication de la signification de REST telle que donne par Roy T. Fielding est la suivante "Representational State Transfer voque l'image du fonctionnement d'une application Web bien construite : un rseau de pages Web (une machine tats finis virtuelle) o l'utilisateur progresse dans l'application en cliquant sur des liens (transition entre tats) ce qui provoque l'affichage de la page suivante (reprsentant le nouvel tat de l'application) l'utilisateur qui peut alors l'exploiter". REST, un style d'architecture REST est un style d'architecture, pas un standard. Il n'existe donc pas de spcifications de REST. Il faut comprendre le style REST puis concevoir des applications ou des services Web selon ce style. REST concerne l'architecture globale d'un systme. Il ne dfinit pas la manire de raliser dans les dtails. En particulier, des services REST peuvent tre raliss en PHP, .NET, JAVA, COBOL ou autre. Bien que REST ne soit pas un standard, il utilise des standards. En particulier : URI comme syntaxe universelle pour adresser les ressources ; HTTP comme protocole de communication ; Des liens hypermedia dans des documents (X)HTML et XML pour reprsenter la fois le contenu des informations et la transition entre tats de l'application, Les types MIME comme text/xml, text/html, image/jpeg, application/pdf, video/mpeg pour la reprsentation des ressources. Les contraintes du style REST Le style REST s'exprime par des contraintes sur l'architecture. Chaque contrainte procure des avantages et des inconvnients . Les principales contraintes sont : Client-Serveur Sparation entre interface utilisateur et donnes ; Evolution indpendante des composants.
21 Sans tat [Stateless] Visibilit : chaque requte rvle tout ; Fiabilit : il est facile de rparer une erreur ; Extensibilit [scalability] : l'tat du service ne dpend pas ni de la requte ni du nombre de clients. Charge rseau : augmente le nombre ou la taille des requtes. Cache Rendement [Efficiency] du rseau : limine des interactions ; Extensibilit : les clients ont le "droit" d'utiliser des donnes en cache ; Performances : l'utilisateur peroit un temps de rponse plus rapide. Donnes en cache : quelquefois primes. Interface uniforme Identification des ressources ; manipulation des ressources par des reprsentations ; messages auto-descriptifs ; hyperliens pour maintenir l'tat de l'application ; Simplicit : nombre limit d'oprations ; Dcouplage entre application et interface. Performances : adaptation aux interfaces. Systme en couches Simplicit : le systme peut tre construit par tapes ; Scurit : encapsulation de systmes existants. Performances : augmentation des appels systme. Code sur demande Simplification du client ; Evolutivit. Les lments du style REST Les principaux lments du style REST sont les donnes (ressources), les connecteurs (HTTP) et les composants (clients, serveurs, cache, proxies). Ressource Une ressource est tout ce qui peut tre nomm : un document, la mto de Paris, une collection d'autres ressources. Une ressource est nomme par un identificateur de ressources [Uniform Resource Identifier - URI]. L'tat actuel de la ressource peut tre obtenu par une reprsentation. Une reprsentation est compose de mtadonnes et de donnes. Habituellement, les mtadonnes sont celles du protocole HTTP et les donnes sont reprsentes par des types MIME, le plus utilis tant le XML Connecteurs Un connecteur est une interface abstraite entre les composants pour communiquer par un rseau. Le connecteur habituel du style REST est le protocole HTTP. C'est un protocole sans tat [stateless] avec un nombre trs limit d'oprations (GET, POST, PUT, DELETE) et une grande richesse de mtadonnes. Composants Les composants "excutent" les requtes et les rponses. Par exemple, un agent utilisateur [user agent] envoie des requtes et traite les rponses. Si c'est un navigateur, il prsente les rsultats contenus dans la rponse. Un serveur reoit des requtes et fournit les reprsentations des ressources demandes. Un serveur mandataire [proxy] agit la fois comme un client et comme un serveur.
22 Le travail de l'architecte Le premier travail consiste identifier et nommer les ressources (au lieu de dfinir des API !). En aucun cas un URI ne doit tre la consquence d'un dveloppement. Il faut bien sr prfrer un nommage logique http://www.example.com/message/1234 un nommage physique http://www.example.com/message.asp?numero=1234 pour masquer une implmentation spcifique. Les ressources doivent tre identifies par des noms, pas par des verbes. Les ressources reprsentent des tats, pas des actions. C'est d'ailleurs la grande diffrence avec des techniques du type RPC ou Objet qui dtaillent l'infini des actions (mthodes). Les URI ne doivent pas changer car vous ne saurez jamais qui dtient des vieilles rfrences : liens dans d'autres pages, utilisateurs dans leurs favoris, notes sur un bout de papier. Il faut donc intgrer si ncessaire le numro de version dans l'URI. Le contenu des bases de donnes ou les entits mtiers doivent avoir des URI. Tout navigateur devient un client du pauvre trs utile pour les tests. Les rfrences peuvent se trouver dans d'autres mdias comme des messages ou de la documentation. Le XSLT devient utilisable pour prsenter, inclure ou transformer les donnes XML. La toute puissance du HTTP GET et de la reprsentation hypermdia permet grce des liens de construire la navigation ou de fournir progressivement des dtails. L'tat d'une application est donn par une URI. C'est le client qui tire les reprsentations des ressources. Chaque requte doit comporter toutes les indications ncessaires pour son excution et ne doit pas s'appuyer sur un contexte stock sur le serveur. Tous les services de l'application doivent donc tre sans-tat (stateless). La reprsentation des donnes doit s'appuyer sur des standards comme utf-8 pour le jeu de caractres, le XML ou le XHTML pour la syntaxe des documents et des vocabulaires spcifiques (Dublin Core, RSS, Atom...) pour la smantique des donnes. C'est le rle de l'architecte de bien spcifier tous les standards de l'application. Il faut noter que l'URI logique ne contient pas d'indication sur la manire dont chaque ressource labore ses rponses. C'est ce qu'on appelle un couplage lche [loosely coupled]. C'est un principe gnral d'architecture des systmes informatiques trop souvent oubli qui devient "naturel" avec REST. Annexe 2 : [Optimistic locking] Comme nous l'avons vu au de non-exclusivit des donnes (principe 7), il n'est pas possible de rserver mme temporairement une donne. Une consquence de ce principe est qu'une donne peut potentiellement tre modifie par un utilisateur pendant qu'un autre utilisateur est en train de l'diter. Supposons par exemple que l'utilisateur veuille modifier l'adresse d'un client. Il effectue pour cela une activit dans le SF Pilote appropri. Il est fort probable que l'interface homme machine pour cette activit affiche un ensemble d'information sur le client, dont l'adresse courante. Notre utilisateur commence saisir la nouvelle adresse mais il est interrompu par un appel tlphonique. Pendant ce temps un autre utilisateur effectue une activit qui a pour consquence de modifier l'adresse du client. Notre premier utilisateur qui reprend son activit la fin de sa conversation tlphonique n'est pas au courant de la modification faite par l'autre utilisateur et risque donc de l'craser. En gnral, ceci ne pose pas de problme fonctionnel, car le rsultat habituellement est le mme que dans le cas tout fait valide o le second utilisateur avait fait sa modification en premier, par exemple quelques minutes avant que le premier utilisateur ne commence. Dans certains cas, le traitement fait par le pilote dpend de la valeur initiale de la donne. Il est alors important de vrifier avant les mises jour dans les SF Silo que la valeur n'a pas chang durant le traitement de l'activit par l'utilisateur. La solution classique pour traiter ce genre de scnario consiste introduire dans le service de modification d'une donne la dernire valeur connue par le pilote. Le SF Silo
23 compare celle-ci avec la valeur courante dans le rfrentiel ; en cas de divergence, une erreur est retourne au pilote qui peut alors, si ncessaire, afficher un message l'utilisateur indiquant que la valeur a t modifie entre temps et lui demandant, par exemple, la conduite tenir. Il convient cependant de relativiser la frquence et l'importance de ces cas : 1. La frquence de tels conflits sera rare, et bien moindre que celle des refus a priori par verrouillage, car comme nous l'avons vu au principe 7, l'approche par rservation impose un primtre de verrouillage assez large puisque l'on ne sait pas a priori o pourrait intervenir le conflit. 2. En gnral les activits ne sont pas en rel conflit - dans l'exemple des adresses ci-dessus il est trs probable que les adresses entres par les deux utilisateurs seront les mmes car un contribuable habite une seule adresse (le fait que deux activits ont t lances est srement d l'activation par le client de deux filires de changement d'adresse - par exemple une dclaration au registre du commerce et une saisie directe via un formulaire en ligne sur le site web de l'entreprise). 3. Dans les cas de rel conflit, ce conflit aurait d tre trait de toute faon - il n'y a donc globalement ni charge supplmentaire vers les utilisateurs ni augmentation du primtre applicatif. Au contraire, la potentialit d'une incohrence est dtecte plus vite et peut tre rsolue avant que les consquences ne se propagent dans le reste du systme d'information. La structuration du systme d'information autour de grands rfrentiels transverses impose donc une volution du dialogue homme-machine pour passer d'une logique o l'utilisateur se voit refuser une activit a priori car la donne est verrouille une logique o il se voit demander son avis a posteriori en cas de conflit. Annexe 3 : Les alertes, les affaires et les indicateurs mtier Certains traitements ne respectent pas la rgle des 4 units : il s'agit d'enchanements d'activits soit sur des priodes temporelles diffrentes soit par des acteurs diffrents. Ces traitements doivent aussi tre pilots - mais sans introduire de couplage fort entre les services fonctionnels. Pour cela on introduit les concepts d'alertes et d'affaires, qui sont dtaills ci-dessous. Les traitements qui ne respectent pas la rgle des 4 units, sont des enchanements d'activits prsentant des discontinuits : Discontinuits temporelles : c'est le cas o il existe des interruptions invitables dans le droulement du traitement - par exemple, quand il faut demander des informations complmentaires un client. Discontinuits d'acteurs : c'est le cas o un acteur n'est pas habilit pour l'ensemble d'un traitement - par exemple, un employ d'un centre d'appel enregistre une demande d'un client, qui sera prise en compte par un autre employ ayant la qualification et l'habilitation approprie. Discontinuits d'actions : c'est le cas o un ensemble d'acteurs excutent un ensemble d'actions non strictement synchronises, dans le cadre d'un macro-processus - par exemple la gestion des campagnes promotionnelles qui regroupe des activits de dfinition des tarifs, de saisies des commandes, de bilan de la campagne, etc. Dans de nombreuses organisations, l'affectation des traitements se fait au niveau des structures et pas au niveau de l'employ. Les traitements sont routs une structure et c'est le chef de cette structure qui les affecte un employ (ou ce sont les employs qui piochent dans la liste de traitements affecte la structure). Tous ces traitements doivent aussi tre pilots - mais sans introduire de couplage fort entre SF. Pour cela on introduit le concept d'alerte. Une alerte permet une activit de demander l'activation ultrieure d'une autre activit dans un contexte donn. Les alertes sont routes automatiquement de manire asynchrone vers la structure approprie puis affecte un employ; un contexte attach l'activit permet l'employ de connatre les paramtres de
24 l'activit (en particulier l'identification du client). Afin de ne pas introduire de couplage fort et de respecter les 4 rgles d'unicit, l'activit mettrice de l'alerte ne s'intresse pas au rsultat de l'alerte ; c'est la responsabilit de l'activit lie l'alerte de prendre en charge l'ensemble des traitements ncessaires, au besoin via la cration d'une autre alerte. Conformment la rgle 3b ci-dessus, le contexte d'une alerte est constitu d'un ensemble d'URI- les valeurs associes sont donc stockes au pralable dans un rfrentiel (sinon il faudrait que le systme de routage des alarme ait une connaissance intime de la structure interne de l'ensemble des donnes du systme d'information, avec toutes les consquences que l'on connat en terme de cots et dlais de maintenance). Le concept d'alerte induit un certain couplage entre activits et donc entre les SF pilotes dans le sens o une activit (et donc son SF pilote) est autorise connatre les autres activits automatises par le Systme d'Information, y compris dans d'autres SF. Ce couplage reste cependant relativement lche et est considr comme acceptable. Dans certains cas, il est important de suivre l'enchanement des diverses activits. Par exemple, le traitement d'un contentieux avec un client pourra mettre en oeuvre des activits de plusieurs employs ; il faut pouvoir coordonner ces activits et pouvoir disposer tout moment d'un rapport sur l'tat d'avancement de cet ensemble d'activits. Il faut dans ce cas crer une affaire qui regroupe l'ensemble des informations ncessaires au traitement et au suivi de ce traitement. Ces affaires sont des donnes mtier comme les autres ; elles sont donc proprit d'un SF silo et sont mises jour par les diverses activits associes au traitement. La coordination des diffrentes activits est aussi une activit (conversationnelle ou non conversationnelle) qui partir des informations associes l'affaire peut demander, via le mcanisme des alertes, l'activation des activits ncessaires au traitement de l'affaire. Il existe bien videmment, dans un systme d'information de la complexit d'un SI d'entreprise, plusieurs types d'affaires qui ont peu en commun : le traitement d'un contentieux de paiement n'a rien voir avec le traitement de cration d'un client. Dans le cas des macro-processus, il faut pouvoir en suivre l'avancement global. On utilise pour cela des indicateurs mtiers - par exemple, le nombre de commandes en cours, le nombre d'impays, le volume de vente d'un produit, etc. Ces indicateurs sont des donnes mtier comme les autres : ils sont proprits d'un SF Silo, sont mis jour par les diverses activits et sont consultables par des activits suivant diffrents format suivant l'objectif vis par l'activit (par exemple affichage du nombre total de commandes pour information commerciale, affichage du nombre de commandes traiter pour pilotage de l'activit des employs, etc...). Il est important de noter que le concept d'alertes est li l'organisation du travail en correspondance avec la structuration de l'organisation ; la structuration des alertes et les mcanismes de routage sont donc indpendant de tout concept mtier - ceci justifie que toutes les alertes soient gres par un unique SF transverse, permettant de garantir la forte cohrence du concept (par exemple, concentrer les impacts un seul SF en cas de changement de mode d'organisation). Au contraire pour les affaires et les indicateurs, leur diversit et le manque de points communs la fois dans leur structuration et dans leurs logiques justifient que les diffrents types d'affaire et d'indicateurs soient gres par des SF spcifiques, permettant de garantir la faible couplage entre les diffrents types (par exemple, pouvoir modifier le traitement des affaires de contentieux de paiement sans impacter le traitement des contentieux de commande).