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.
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
8. Non-exclusivité des données
Principe 7 : Non-exclusivité des données (même de manière temporaire)
Les SF Pilotes ne peuvent réserver, même de manière temporaire, un accès exclusif à une donnée d'un référentiel.
Ce principe est en fait très similaire au principe d'asynchronisme (principe 6), avec une dimension supplémentaire liée à la complexité des données (figure 8).
-
Dans les applications en mode cloisonné, la gestion des potentiels conflits d'accès entre plusieurs utilisateurs, sur une même donnée, est généralement faite via des mécanismes de réservation : l'utilisateur annonce son intention de travailler sur une donnée et l'application en interdit l'accès (au moins en modification) aux autres utilisateurs. Ce mécanisme de verrouillage des données est généralement mis en œuvre quand l'activité de l'utilisateur est relativement longue : de quelques heures à quelques jours.
-
Dans le cas d'un système basé sur des référentiels transverses, une telle réservation impliquerait qu'aucun autre processus de l'ensemble du système fiscal ne puisse modifier cette donnée.
Cette réservation, qui était voulue et acceptable sur une sous-partie du système d'information, prend une ampleur difficilement contrôlable quand elle s'applique sur l'ensemble du système. En effet, la sémantique de la réservation devient vite complexe à définir précisément et entraîne rapidement un couplage fort entre processus – couplage dont nous avons vu les inconvénients majeurs.
Prenons l'exemple d'un contribuable dont on est en train de changer la situation fiscale. Cette modification peut prendre plusieurs minutes, voire plusieurs heures, en particulier si l'agent est interrompu (téléphone) ou si l'agent doit chercher des informations supplémentaires. On pourrait donc vouloir « réserver » les données du contribuable pour éviter que quelqu'un d'autre ne les modifie en même temps, ou n'applique des traitements sur ces données en cours de modifications.
Mais où pourrait être stockée cette « réservation » ? Si elle était stockée dans le SF pilote de l'activité qui réserve, alors, soit il faudrait introduire un couplage fonctionnel fort entre les SF, soit les processus des autres SF n'appliqueraient pas cette...
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
Non-exclusivité des données
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