1

Principes d'urbanisation pour un systme

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).