Référence : CNRS / DSI / REFERENTIELS / Référentiels_applications_v5.doc Date : janvier 2005 Version : 5.0 Auteurs : Equipe Référentiels du projet RUE (Référentiels Urbanisation EAI) Passage de la version 1.0 à 2.0 : Prise en compte des orientations fixées par le groupe de travail sur l Urbanisation Passage de la version 2.0 à 3.0 : découpage du document en deux parties : la première sur les généralités et la seconde sur la mise en œuvre des référentiels partagés. Passage de la version 3.0 à 4.0 : précision sur la localisation applicative des référentiels partagés (reformulation en 4.1). Passage de la version 4.1 à 5.0 : précision sur les fonctions et services pour les référentiels partagés. Objet du document : - Citer les principaux objectifs de la mise en œuvre des référentiels partagés - Lister le vocabulaire autour des référentiels partagés - Poser les règles d'identification des référentiels partagés - Aider à la définition de référentiels partagés - Définir les fonctions des applications sur les référentiels partagés - Préciser les services applicatifs autour des référentiels partagés DSI.
Sommaire 1. OBJECTIFS DE LA MISE EN ŒUVRE DES REFERENTIELS PARTAGES...2 2. VOCABULAIRE SUR LES REFERENTIELS PARTAGES...3 3. DEFINITION D'UN REFERENTIEL PARTAGE...5 3.1. COMPOSITION D'UN REFERENTIEL PARTAGE...5 3.2. LOCALISATION D'UN REFERENTIEL PARTAGE...5 4. LES META-INFORMATIONS D UN REFERENTIEL PARTAGE...7 4.1. DEFINITION SEMANTIQUE D'UNE INFORMATION DE REFERENCE...7 4.2. VALIDITE DES INFORMATIONS DE REFERENCE...7 4.3. STATUT DE L'ETAT DES INFORMATIONS DE REFERENCE...7 4.4. ORIGINE DE L'INFORMATION DE REFERENCE...7 4.5. LES PROPRIETAIRES DES REFERENTIELS PARTAGES...7 4.6. LES CIRCUITS DE MISE A JOUR DES REFERENTIELS PARTAGES...7 4.7. LA MISE A DISPOSITION DE CES META-INFORMATIONS...8 5. LES FONCTIONS SUR LES REFERENTIELS PARTAGES PRESENTES DANS LES APPLICATIONS...9 5.1. LES FONCTIONS DANS LES APPLICATIONS PROPRIETAIRES...9 5.1.1. Fonction de mise à jour...9 5.1.2. Fonction d'administration...9 5.1.3. Fonction de consultation...9 5.1.4. Fonction de référencement...9 5.2. LES FONCTIONS DANS LES APPLICATIONS UTILISATRICES...9 5.2.1. Fonction de mise à jour...9 5.2.2. Fonction de référencement... 10 6. LES SERVICES APPLICATIFS POUR LES REFERENTIELS PARTAGES... 11 6.1. CARTOGRAPHIE GENERALE DES FLUX D INFORMATIONS DE REFERENCE...11 6.2. LES SERVICES DANS LES APPLICATIONS PROPRIETAIRES...12 6.2.1. Service de consultation... 12 6.2.2. Service d exposition... 12 6.2.3. Service d introduction de références... 12 6.2.4. Service de gestion des dépendances référentielles... 13 6.3. LES SERVICES DANS LES APPLICATIONS UTILISATRICES...13 6.3.1. Service d exposition... 13 6.3.2. Service d introduction de références... 13 7. SYNTHESE DES FONCTIONS ET SERVICES APPLICATIFS REFERENTIELS PARTAGES... 14 7.1. SCHEMA POUR UNE DUPLICATION DE REFERENTIEL ENTRE APPLICATIONS...14 7.2. SCHEMA POUR UNE PRISE EN COMPTE DE REFERENCES EXTERNES AU CNRS...15 7.3. SCHEMA POUR UNE DEPENDANCE REFERENTIELLE ENTRE REFERENTIELS...16 7.4. SCHEMA POUR UN PARTAGE DE REFERENTIEL ENTRE APPLICATIONS SANS DUPLICATION...17 CNRS / DSI / REFERENTIELS / Référentiels_applications_v5.doc janvier 2005 1
1. OBJECTIFS DE LA MISE EN ŒUVRE DES REFERENTIELS PARTAGES Dans le cadre de la démarche d urbanisation mise en œuvre sur le SI de gestion du CNRS, une réflexion a été menée autour de la notion de référentiel pour un système d information. Cette étude a mis en avant des préconisations sur les référentiels, leur gestion et leur partage. Deux principaux objectifs sont recherchés : un meilleur partage des informations de référence, en terme de qualité et de maîtrise des échanges de référence, une meilleure réactivité du SI face aux évolutions des informations de référence. Pour atteindre un meilleur partage, la démarche s appuie sur une définition claire et partagée de chaque référentiel au travers de fiches référentiel partagé établissant un contour précis du partage de référentiel sur les aspects sémantique, propriété, administration et description. Des modélisations de données (format pivot) avec un ajout systématique de méta informations, et des cartographies applicatives de flux complètent la description. La réactivité accrue du SI est envisagée par un couplage faible entre les applications utilisatrices des informations de référence. Les informations de référence sont par nature peu mises à jour mais fortement partagées (contrairement aux informations de gestion par exemple). Les informations de référence nécessitent ainsi un fort partage entre les applications du SI, partage qui peut complexifier la prise en compte des évolutions structurelles des informations de référence. Il est donc important de découpler les applications utilisatrices des informations de référence en minimisant les liens directs entre les applications. Cette réduction des liens directs entre applications, ainsi que la maîtrise des échanges de référence, est un des objectifs de la mise en œuvre de l outil EAI WebMethods pour le SI de gestion du CNRS. CNRS / DSI / REFERENTIELS / Référentiels_applications_v5.doc janvier 2005 2
2. VOCABULAIRE SUR LES REFERENTIELS PARTAGES Parmi les préconisations émises dans le cadre de la démarche d urbanisation, une d entre elles introduit une classification des référentiels. Ainsi, on distingue : les référentiels dits «externes» qui sont constitués de données issues de l extérieur du SI CNRS mais utilisées par le SI de gestion du CNRS, les référentiels spécifiques au SI CNRS : ceux-ci peuvent être découplés en référentiels dits d organisation (structurels) et en référentiels dits internes (non structurels). Egalement, une préconisation porte sur la localisation des référentiels (application propriétaire ou cliente). Il en ressort notamment 2 types de localisation : dans une application de gestion qui sera alors propriétaire du référentiel, dans une application dédiée à la gestion du référentiel, de fait propriétaire du référentiel. Une autre préconisation tient à enrichir la qualification des informations de référence. Ainsi il est préconisé de compléter les informations de chaque référentiel par des méta informations précisant : la (ou les) période(s) de validité de l'information de référence (ex.: exercice, année, période, date d'effet,...), le statut (état(s) de référence) de l'information de référence (ex.: provisoire, attente validation, validée, active, inactive, en cours de création, en cours de modification,...), l'origine de l'information de référence (ex.: date de création, créateur, référentiel propriétaire,...). Enfin, une dernière préconisation évoque des services de partage (mode exposition et accès) des référentiels. Ces services sont portés par les applications de gestion : mode exposition si l application est propriétaire du référentiel, mode accès si l application est cliente du référentiel. Ainsi, tout référentiel peut être qualifié de maître dans son application propriétaire (en mode exposition) et d esclave dans une application utilisatrice (en mode accès). Le cas échéant, la possibilité d enrichissement (soit en référence, soit en descriptif) d un référentiel par une application cliente est autorisée. La mise en place d une infrastructure d EAI, autour de WebMethods, doit faciliter la mise en œuvre de ces services de partage d informations de référence entre des applications du SI. Pour cela, l outil d EAI exposera les fonctionnalités suivantes : possibilité de mettre en œuvre des modèles de données (formats pivots) représentant la structure des référentiels, possibilité de mettre en place un mécanisme de publication et abonnement pour les applications propriétaires et clientes des référentiels, publication des référentiels dans l EAI à partir des applications propriétaires, avec prise en charge des étapes suivantes : o le cas échéant, détection automatique des modifications apportées au référentiel dans l application propriétaire, o transformation des données du format de l application source vers le format pivot choisi pour le o référentiel, publication du référentiel au format pivot. Deux types de publication pourront être mis en œuvre : - publication complète de tout le contenu du référentiel, - publication limitée aux modifications apportées au référentiel (ajout, suppression ou modifications des données du référentiel dans l application propriétaire). abonnement des applications clientes aux référentiels qui les intéressent, avec : o transformation des données du format pivot vers le format de l application cliente, o le cas échéant, mise à jour des données dans l application cliente. Cette mise à jour sera faite soit par suppression et remplacement des données préexistantes, soit par mise à jour différentielle. gestion des échanges de données à mettre en œuvre pour l alimentation des référentiels externes : o traitement automatique de la réception des données, CNRS / DSI / REFERENTIELS / Référentiels_applications_v5.doc janvier 2005 3
o transformation des données source au format pivot choisi pour le référentiel avec possibilité de valider ou enrichir les données par un acteur humain, o mise à jour des données dans les applications propriétaires des référentiels. La mise à disposition de référentiels peut s illustrer ainsi : Illustration de la mise à disposition de référentiels. CNRS / DSI / REFERENTIELS / Référentiels_applications_v5.doc janvier 2005 4
3. DEFINITION D'UN REFERENTIEL PARTAGE 3.1. COMPOSITION D'UN REFERENTIEL PARTAGE Un référentiel contient des informations de référence. Une information de référence est principalement caractérisée par la stabilité de sa définition et par un fort accès consultatif. Le partage entre plusieurs fonctions (zone, quartier ou bloc) est aussi un préalable à tout classement d une information dans la zone référentielle. 3.2. LOCALISATION D'UN REFERENTIEL PARTAGE Il n est pas envisagé de regrouper tous les référentiels dans une base unique centralisée. Selon l opportunité (au niveau applicatif, existence d un PGI ou utilisation par plusieurs PGI ou...) et selon des règles d urbanisation, les référentiels partagés peuvent être : Soit présents dans des applications dédiées exclusivement à la gestion de référentiels partagés, Soit portés dans les applications prenant en charge des fonctions de gestion du SI. Les règles d urbanisation, à considérer comme critère d éligibilité d une application de gestion du SI en tant que propriétaire d un référentiel partagé, sont les suivantes : 1. principe de cohérence forte : il convient d examiner les liens du référentiel avec le métier auquel l application de gestion répond : o o si le référentiel est fortement lié avec le métier de l application, alors l application de gestion peut être choisie pour porter le référentiel (principe de cohérence forte), si le référentiel n a pas d adhérence ou très peu avec le métier de l application, alors il est préférable que l application de gestion ne porte pas le référentiel (cohérence faible). 2. cycle d évolution du référentiel : il convient également d identifier le cycle d évolution (caractère stable ou instable) du référentiel en terme de délai entre 2 changements de description, de périmètre : o o si le cycle d évolution est court, alors les applications de gestion n ont pas vocation à porter le référentiel, si le cycle d évolution est long, alors les applications de gestion peuvent être choisies pour porter le référentiel. Pour la construction de notre SI, nous souhaitons privilégier la règle 1 quelles que soient les conclusions de la règle 2. En effet, dans le cas d un cycle d évolution court, une cohérence forte avec une application de gestion nécessitera une adaptation de cette application pour intégrer l évolution du référentiel. Le gain recherché en découplant l application et le référentiel ne serait alors pas obtenu puisque l impact de l évolution sera à prendre en considération dans l application de gestion. C est pourquoi, il est jugé préférable de donner la priorité à la règle 1 et de faire porter le référentiel par l application de gestion en cohérence forte avec le référentiel. CNRS / DSI / REFERENTIELS / Référentiels_applications_v5.doc janvier 2005 5
Le tableau suivant résume les critères d éligibilité d une application pour porter un référentiel : Cohérence référentiel application de gestion Cohérence forte Cohérence faible Localisation du référentiel Application de gestion propriétaire Application spécifique Référentiel propriétaire Pour chaque référentiel, il est nécessaire de bien identifier sa localisation et de développer une architecture d'échange (normalisé, anonyme et indépendant) d'informations entre les applications pour faciliter la circulation des informations présentes dans les référentiels partagés. (cf. volet EAI du projet RUE Référentiel - Urbanisation - EAI)). CNRS / DSI / REFERENTIELS / Référentiels_applications_v5.doc janvier 2005 6
4. LES META-INFORMATIONS D UN REFERENTIEL PARTAGE Pour chaque référentiel partagé, les méta informations décrites ci-après sont recensées dans un document spécifique dénommé «fiche référentiel partagé». 4.1. DEFINITION SEMANTIQUE D'UNE INFORMATION DE REFERENCE Toute information identifiée comme information de référence doit obligatoirement faire l'objet d'une définition explicite permettant notamment : - d'apporter une vision claire et précise du contour de cette information de référence (aucune ambiguïté ne doit exister sur les limites et le contenu de cette information de référence) - une adhésion de tous les «consommateurs» sur la définition et le contour qu'elle porte (partage de la définition). 4.2. VALIDITE DES INFORMATIONS DE REFERENCE Dans la mesure du possible, toute information identifiée comme information de référence doit être accompagnée de méta-informations sur la période de validité de l'information comme information de référence (ex.: exercice, année, période, date d'effet,...). 4.3. STATUT DE L'ETAT DES INFORMATIONS DE REFERENCE Afin de mieux qualifier l information de référence, notamment lors de son utilisation par une fonction du SI, il faut essayer de donner, à toute information identifiée comme information de référence,des métainformations sur le statut de ou des état(s) de référence de l'information de référence (ex.: provisoire, attente validation, validée, active, inactive,...). 4.4. ORIGINE DE L'INFORMATION DE REFERENCE Dans la mesure du possible, toute information identifiée comme information de référence doit obligatoirement être accompagnée de méta-informations sur l'origine de l'information de référence (ex.: date de création, créateur,...). 4.5. LES PROPRIETAIRES DES REFERENTIELS PARTAGES Tout référentiel partagé doit avoir un propriétaire désigné explicitement. Pour identifier le propriétaire d'un référentiel, le principe de "primo-créateur" est à privilégier, à savoir que le propriétaire est au plus proche de la création de l'information de référence. Dans des cas plus complexes, en second lieu, il peut être envisagé d identifier qui a le droit de suppression sur ces informations pour en déterminer le propriétaire. 4.6. LES CIRCUITS DE MISE A JOUR DES REFERENTIELS PARTAGES Les circuits de mise à jour doivent être identifiés clairement. Des responsables (notion de rôles plutôt que d'individus) des mises à jour doivent être déterminés et recensés. CNRS / DSI / REFERENTIELS / Référentiels_applications_v5.doc janvier 2005 7
4.7. LA MISE A DISPOSITION DE CES META-INFORMATIONS La mise à disposition des méta informations est effectué sur le site des Référentiels partagés dans l espace Urbanisation du site de la DSI (http://www.dsi.cnrs.fr/description_referentiel/). CNRS / DSI / REFERENTIELS / Référentiels_applications_v5.doc janvier 2005 8
5. LES FONCTIONS SUR LES REFERENTIELS PARTAGES PRESENTES DANS LES APPLICATIONS 5.1. LES FONCTIONS DANS LES APPLICATIONS PROPRIETAIRES 5.1.1. Fonction de mise à jour Des fonctions de création, de modification et de suppression sont à mettre en oeuvre dans l'application propriétaire du référentiel. Dans le cas (à considérer comme marginal) d un référentiel porté par plusieurs applications (multisources applicatives soit en terme de références, soit en terme de descriptions), les fonctions de mise à jour, mises en œuvre dans chacune des applications propriétaires, doivent être limitées au seul périmètre de propriété des applications. 5.1.2. Fonction d'administration Des fonctions de validation du référentiel sont à prévoir dans l'application propriétaire du référentiel : - validation de références introduites dans l'application propriétaire, - le cas échéant, validation de références proposées par les applications utilisatrices du référentiel auxquelles l'application propriétaire doit apporter une réponse à la demande d'ajout de référence. Ces fonctions de validation doivent permettre de gérer des validations soit en mode centralisé, soit en mode réparti, et être configurées de telle sorte à obtenir des validations implicites (sans intervention du(es) administrateur(s)) ou des validations explicites. 5.1.3. Fonction de consultation Des fonctions de consultation du référentiel sont à prévoir dans l'application propriétaire du référentiel pour effectuer des recherches au sein du référentiel: 5.1.4. Fonction de référencement Des fonctions de référencement dans le référentiel sont à prévoir dans l'application propriétaire. Elles ont pour objectif de permettre l intégration de références dépendantes issues d un référentiel porté par une autre application et pour lequel une dépendance référentielle a été établie. Le référencement consiste à attribuer une identification, dans le référentiel dépendant, de la référence provenant du référentiel source de la dépendance. 5.2. LES FONCTIONS DANS LES APPLICATIONS UTILISATRICES 5.2.1. Fonction de mise à jour Des fonctions de création, de modification et de suppression sont à mettre en oeuvre dans les applications utilisatrices de référentiel. Elles ont pour but de prendre en compte les évolutions des informations de référence dans leur référentiel d origine (référentiel maître). CNRS / DSI / REFERENTIELS / Référentiels_applications_v5.doc janvier 2005 9
5.2.2. Fonction de référencement Pour un référentiel donné, dans le cas où des applications utilisatrices n identifient pas les références selon les mêmes règles que l application propriétaire du référentiel, des fonctions de référencement sont à prévoir dans les applications utilisatrices. Elles ont pour objectif d attribuer une identification conforme aux règles de l application utilisatrice à partir des références reçues provenant de l application propriétaire. CNRS / DSI / REFERENTIELS / Référentiels_applications_v5.doc janvier 2005 10
6. LES SERVICES APPLICATIFS POUR LES REFERENTIELS PARTAGES Le partage des informations de référence est présenté dans le cadre de l utilisation de l EAI webmethods. Les échanges d'informations (descriptions et valeurs) sont à privilégier en XML. 6.1. CARTOGRAPHIE GENERALE DES FLUX D INFORMATIONS DE REFERENCE Le schéma suivant représente les flux d informations de référence : - Dans le cas de références externes au CNRS introduites dans notre SI (flux bleus), - Dans le cas de partage de références entre plusieurs applications de notre SI (flux verts), - Dans le cas de dépendances référentielles entre référentiels (flux rouges), - Dans le cas d identifications différentes d une même référence entre plusieurs applications (flux marrons). CNRS / DSI / REFERENTIELS / Référentiels_applications_v5.doc janvier 2005 11 11
6.2. LES SERVICES DANS LES APPLICATIONS PROPRIETAIRES 6.2.1. Service de consultation Un service de consultation est à mettre en oeuvre dans l'application propriétaire du référentiel. Il doit permettre de présenter le contenu du référentiel à toute application utilisatrice sans pour autant que cette dernière n ait à dupliquer le référentiel parmi ses données. Il sera donc appelé par les applications utilisatrices du référentiel. Cependant, 2 contextes sont à distinguer : - Liaison synchrone : dans ce cas, l application utilisatrice fera appel directement au service de l application propriétaire, - Hors liaison synchrone (asynchrone court et long) : dans ce cas, il est préconisé de passer par l EAI pour appeler le service porté par l application propriétaire. Il sera alors possible notamment de bénéficier des fonctions EAI de transformations (format pivot) et d enrichissement le cas échéant. 6.2.2. Service d exposition Un service d exposi tion est à mettre en oeuvre dans l'application propriétaire du référentiel. Il doit permettre : - d exposer les évolutions du contenu d un référentiel à toute application utilisatrice possédant une duplication du référentiel parmi ses données (le circuit préconisé est que le service de publication de l EAI s appuie sur le service d exposition de l application propriétaire ; ainsi, les publications d informations de référence, effectuées par l EAI, sont déclenchées par l activation du service d exposition de l application propriétaire), - d exposer, le cas échéant, dans le cadre de dépendances référentielles, l identification des références dépendantes dans le référentiel dépendant (l EAI prenant en charge la gestion des références croisées et dépendantes). 6.2.3. Service d introduction de références Un service d introduction de référence est à mettre en oeuvre dans l'application propriétaire du référentiel. Il sert à prendre en compte, dans l application propriétaire, les références externes au CNRS qui seront préparées soit par l EAI (passage automatisable au format attendu CNRS) soit par le service lui-même (passage semi-automatisable au format attendu CNRS nécessitant une intervention manuelle). Il sera appelé par l EAI dès lors que des évolutions de contenu seront détectés par l EAI (avec ou sans préparation EAI au format attendu CNRS). CNRS / DSI / REFERENTIELS / Référentiels_applications_v5.doc janvier 2005 12 12
6.2.4. Service de gestion des dépendances référentielles Un service de gestion des dépendances référentielles est à mettre en oeuvre dans l'application propriétaire du référentiel dépendant. Il sert à prendre en compte, dans l application propriétaire du référentiel dépendant, les informations de référence et leurs évolutions du référentiel pour lequel une dépendance référentielle a été établie. Il sera appelé par le service d abonnement supporté par l EAI pour lequel l application propriétaire du référentiel dépendant aura souscrit. 6.3. LES SERVICES DANS LES APPLICATIONS UTILISATRICES 6.3.1. Service d exposition Un service d exposition est à mettre en oeuvre dans les applications utilisatrices de référentiels. Il doit permettre d exposer, le cas échéant, les ré-identifications de référence dans des applications utilisatrices qui gèrent une identification différente de celle de l application propriétaire (l EAI prenant en charge la gestion des références croisées entre applications). Ce service appelle le service de publication de l EAI. 6.3.2. Service d introduction de références Un service d introduction de référence est à mettre en oeuvre dans les applications utilisatrices de référentiels. Il sert à prendre en compte, dans chaque application utilisatrice dupliquant les référentiels, les évolutions de contenu des référentiels. Il sera appelé par le service d abonnement supporté par l EAI pour lequel les applications utilisatrices auront souscrit. CNRS / DSI / REFERENTIELS / Référentiels_applications_v5.doc janvier 2005 13 13
7. SYNTHESE DES FONCTIONS ET SERVICES APPLICATIFS REFERENTIELS PARTAGES 7.1. SCHEMA POUR UNE DUPLICATION DE REFERENTIEL ENTRE APPLICATIONS CNRS / DSI / REFERENTIELS / Référentiels_applications_v5.doc janvier 2005 14 14
7.2. SCHEMA POUR UNE PRISE EN COMPTE DE REFERENCES EXTERNES AU CNRS CNRS / DSI / REFERENTIELS / Référentiels_applications_v5.doc janvier 2005 15 15
7.3. SCHEMA POUR UNE DEPENDANCE REFERENTIELLE ENTRE REFERENTIELS CNRS / DSI / REFERENTIELS / Référentiels_applications_v5.doc janvier 2005 16 16
7.4. SCHEMA POUR UN PARTAGE DE REFERENTIEL ENTRE APPLICATIONS SANS DUPLICATION CNRS / DSI / REFERENTIELS / Référentiels_applications_v5.doc janvier 2005 17 17