Présentation
NOTE DE L'ÉDITEUR
Cet article est la version actualisée de l'article de même nom et de même auteur, publié dans nos éditions en 2008.
RÉSUMÉ
Les systèmes d'information de nombreuses grandes entreprises se sont construits graduellement au cours des dernières décennies sous forme d'applications indépendantes où les informations sont dupliquées. Cela se traduit par des ruptures, citons celle des identifiants, de la chaîne informatique, la temporelle et la géographique. Résoudre ces ruptures est fondamental, car elles sont responsables d’incohérences, de saisies multiples et d’un service peu satisfaisant pour les utilisateurs et l’entreprise. L’architecture informatique SOA REST permet de restructurer le système d’information en simplifiant l’expression des principes, et de fait d’apporter solution à ces problématiques. Cet article présente des principes d'urbanisation fondés sur ce style d'architecture.
Lire cet article issu d'une ressource documentaire complète, actualisée et validée par des comités scientifiques.
Lire l’articleAuteur(s)
-
Jean-Paul FIGER : Directeur Innovation et Nouvelles Technologies, Cap Gemini
INTRODUCTION
Ce guide présente des principes d'urbanisation fondés sur un style d'architecture SOA REST. Ces principes restent valables quel que soit le style d'architecture pour l'urbanisation de tout système d'information complexe.
Ce document est une adaptation dans le cadre d'une architecture SOA REST d'un guide préparé par Th. Moineau – [email protected]
JM. Lapeyre – [email protected]
D. Oddoux – [email protected]
pour la réalisation de systèmes d'information complexes dans une grande entreprise.
L'expertise technique et scientifique de référence
MOTS-CLÉS
VERSIONS
- Version courante de juil. 2018 par Jean-Paul FIGER
DOI (Digital Object Identifier)
Cet article fait partie de l’offre
Technologies logicielles Architectures des systèmes
(240 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive
Présentation
Contexte10. Référentiels passifs
Principe 9 : Référentiels passifs
Un SF Silo (référentiel) n'a pas vocation à avertir les autres SF Silo des modifications de ses données.
Les raisons de ce principe sont multiples (figure 11).
Tout d'abord, nous avons vu que le pilotage des activités et des processus métiers était dévolu aux SF pilotes. Avertir pour action un autre SF d'une modification d'une donnée est un morceau de processus qui doit donc être piloté par un SF Pilote, non dans un SF Silo.
D'autre part, la diffusion d'information par ce genre de mécanismes (dit de « push ») imposerait la mise en place de protocoles complexes pour traiter correctement de manière robuste les impondérables de la vie réelle. En effet, lors de la mise à jour de la donnée, il est possible qu'un des SF à avertir ne soit pas disponible (panne machine ou maintenance programmée – il ne faut pas oublier que la haute disponibilité coûte très cher en développement et en exploitation, et qu'il faut la réserver aux composants pour lesquels il existe une réelle justification métier).
Il faudrait donc définir un mécanisme permettant de ré-émettre les avis de modification – tout en garantissant que les avis ne peuvent pas être dupliqués (imaginez les conséquences de la duplication d'un ordre de débit d'un compte). Il faudrait aussi définir les règles de diffusion, car avertir tous les SF de toutes les mises à jour de toutes les données demanderait une bande passante et une capacité machine astronomique. En effet, il ne faut pas oublier que, dans une approche basée sur des référentiels, le taux de mise à jour par référentiel est bien plus élevé que dans le cas d'un système cloisonné par application et géographiquement. Afin de respecter le principe de couplage faible entre processus de SF différents, il serait nécessairement à la charge des différents SF d'indiquer au référentiel les données dont les modifications les intéressent. Ce mécanisme d'abonnement ajouterait encore à la complexité des protocoles à définir.
Il est donc beaucoup plus facile de mettre en place dans les référentiels des services qui permettent aux autres SF Pilotes de connaître les données qui ont été modifiées sur une période de temps donnée – charge aux SF Pilotes d'utiliser ce service et d'accéder aux...
L'expertise technique et scientifique de référence
Cet article fait partie de l’offre
Technologies logicielles Architectures des systèmes
(240 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive
Référentiels passifs
L'expertise technique et scientifique de référence
Cet article fait partie de l’offre
Technologies logicielles Architectures des systèmes
(240 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive
