accueilLogicielsDéveloppement et Qualité LogicielsQualité logicielle
 

Directory Management and Administration System

Descriptif du framework sur lequel sont construits les agents d’administration et de gestion des annuaire LDAP au sein de la DSI


Contexte et motivations

La DSI a mis en place dans le cadre de l’urbanisation de son système d’information un annuaire Central du CNRS LDAP et par la suite des annuaires secondaires.

L’Annuaire Central CNRS contient l’ensemble des personnes agissant au sein des structures du CNRS. Le périmètre (de l’ordre de 100 000 entrées) et la fréquence de mise à jour, souhaitée aussi courte que possible, sont tels que les techniques d’import de masse classiques sont inadaptées.

La nécessité d’outils et d’automates de maintenance et d’administration d’annuaire s’est imposée.

Nous appellerons agent ou robot le logiciel en charge d’un annuaire.

Nature et flux d’informations

Les annuaires ne génèrent pas et ne gèrent pas d’information, leurs fonctions sont de les rendre accessibles et exploitables à travers le protocole LDAP. Aussi ces informations sont-elles issues de Sources de Données de Référence.

Source de Données de Référence

Les Sources de Données de Référence sont des applications ou des dépôt de données reconnus compétents qui fournissent les informations fonctionnelles de référence.

Elles sont responsables de

  • la cohérence métier,
  • de la validité des données,
  • de la présentation ou de la fourniture des informations à répercuter dans l’annuaire.

L’agent se charge de traduire ces informations en termes LDAP pour les intégrer dans l’annuaire.

Propagation des informations

Les informations sont propagées des Sources de Données de Référence à un annuaire par l’agent DMAS. Elles ne s’arrêtent pas forcément à ce stade, un agent DMAS peut les propager au delà. Dans le cas d’annuaires répartis il est possible de créer des agents DMAS répartis : chacun surveillant alors son propre annuaire.

Agent

A chaque annuaire à mettre sous tutelle correspondent une situation et une problématique propres. Pour y répondre il y a plusieurs solutions :

  • Créer autant de programmes ad-hoc qui répondront "en dur" ponctuellement à une problématique,
  • Paramétrer un automate adaptable.

Le framework DMAS permet de "monter" un tel automate que nous appellerons agent.

Un agent est donc une entité regroupant flots et taches administratives en charge d’un ou plusieurs annuaires

Principes de fonctionnement

Les principes de fonctionnement sont basés sur la logique de la chaîne de fabrication. Il y a :

  • un ordre de fabrication, c’est l’évènement,
  • un panier pour regrouper les pièces de fabrication, c’est le paquet,
  • une fiche de suivie pour identifier la demande, accrochée au paquet des ouvriers ou automates spécialisés pour assurer une tache ou un poste de travail,
  • des stocks de pièces, ce sont les Sources de Données de Référence
  • une zone de stockage, c’est l’annuaire.

Cinématique générale

La cinématique est de type évènementielle. Un évènement initiale déclenche l’ensemble des transformations qui mène à l’annuaire.

  • Récupération (active ou passive) des évènements en provenance d’une source de données.
  • Caractérisation de l’évènement, préparation d’un paquet/panier associé.
  • Envoi sur une chaîne de traitement.
  • Recherche d’informations complémentaires.
  • Transformation des données du paquet/panier, assemblage.
  • Écriture dans l’annuaire.
  • transmission éventuelle du descriptif de la modification vers d’autres agents.

Communication

Ces agents peuvent communiquer via un broker de messages asynchrone de type JMS

Composants majeurs du framework

La perception des évènements

La perception des évènements est de la responsabilité du Scanner. Le Scanner peut être actif (ex : il balaye une table SQL) ou passif (ex : il écoute sur un port). Il représente la prise en compte d’une nature d’évènement : son arrêt ou sa mise en pause reviennent à couper le flux d’évènement, et donc par conséquent à arrêter l’impact d’une Source de Données de Référence sur l’annuaire.

  • Il est le point d’entrée de la chaîne de transformation.
  • Il maintient une boucle évènementielle et gère le dialogue logique entre la source de donnée et la chaîne de traitement.
  • Il peut déléguer la communication proprement dite avec la Source de Données de Référence à un composant de type Exchange à même d’interpréter les données fournies car il est le seul à savoir quelle est sa nature et sa structure.

L’avantage du découplage Scanner/Exchange est de pouvoir implémenter un composant communiquant avec n’importe quel média ou support sans remettre en cause la logique générale :

base SQL, broker JMS, répertoire FTP, POP3, Web services

Ainsi une source de données supplémentaire peut se greffer sans difficulté.

Initialisation

Une fois l’évènement récupéré, l’agent crée un paquet Pack qui va suivre l’évènement tout le long de son traitement.

Le Pack a trois fonctions :

  • identifier l’évènement
  • permettre son suivi
  • servir de support de stockage

A chaquePackest associée une carte d’identité Card qui définie :

  • identifiant de l’évènement
  • application : l’application d’origine
  • domaine : le domaine métier concerné
  • identifiant applicatif : l’identifiant du sujet de l’évènement dans l’applicatif d’origine

LePacksupporte :

  • les données d’origine,
  • les données de travail,
  • le statut (succès ou échec),
  • le message de justification,
  • l’exception à la source du rejet.

Sélection de la chaine de traitement

En fonction des informations disponibles (telles que domaine, application, etc... ) l’agent va consulter son registre de chaînes disponibles et trouver la chaine adaptée.

Chaine de traitement

Chaque chaine de traitement est constituée d’une suite de Handler (gestionnaire). Un Handler est l’équivalent d’un robot sur une chaine de fabrication d’automobile.

Chaque Handler :

  • reçoit un Pack en entrée,
  • effectue un ensemble d’opérations élémentaires dessus,
    • ajout, modification ou vérification d’information
  • transmet lePackmodifié au Handler suivant,
  • retourne le Pack.

Un Handler, en plus d’être une unité de traitement, est aussi un contrôleur qualité. Il peut estimer qu’une condition est incompatible ou qu’une erreur est irrémédiable et renvoyer le paquet sans transmission au Handler suivant.

Organisation

L’organisation générale d’une instance DMAS permet d’administrer et faire fonctionner plusieurs composants autonomes en même temps.

Cette organisation repose sur la notion d’ensembles autonomes d’objets appelé contextes, eux mêmes contenus dans un conteneur de contexte.

Contextes

Un contexte est une unité de traitement autonome et complète. Autonome signifie que cette unité de traitement ne dépend pas de l’état d’une autre pour fonctionner. Par contre un contexte peut avoir besoin en entrée du flux résultant d’un autre contexte pour travailler, mais que cette dépendance sur les données doit rester asynchrone et faible : les contextes sont découplés entre eux.

Ils peuvent travailler dans des environnements totalement isolés, y compris au niveau java via le mécanisme de classLoader.

Un contexte contient un ensemble d’objet qui œuvrent ensemble pour remplir des taches désignées. Ainsi un contexte peut s’assimiler à un environnement. Par exemple nous pouvons imaginer au sein du même Container d’avoir

  • un contexte de mise à jour d’annuaire pour le développement,
  • un pour l’étude d’évolution
  • et un de recette.

ou encore une ferme de contextes en cascade

  • l’un met à jour un annuaire central et écrit dans une file
  • un second écoute la file et met à jour une base de donnée
  • un troisième scrute la base et et averti par mail des utilisateurs clefs.

Avec cette architecture, tous les scénarios sont (quasiment) possibles

ContextContainer

Le ContextContainer DMAS est le composant qui contient tous les composants DMAS en général et les contextes en particulier.

  • Il est le premier composant à démarrer
  • Il est responsable de la mise en place des services communs transverses
  • Il gère les contextes et les threads associés, c’est à dire qu’il peut :
    • Les charger,
    • les décharger,
    • les rafraichir.

Outils et moyens

Le développement du framework a débuté en 2003 et se poursuit toujours.

Les outils utilisés sont actuellement

Contact : marc.dexet@dsi.cnrs.fr


Ce framework devrait prochainement être ouvert en Open Source.


ARESU
Direction des Systèmes d'Information du CNRS

358 rue P.-G. de Gennes
31676 LABEGE Cedex

Bâtiment 1,
1 Place Aristide Briand
92195 MEUDON Cedex



 

 

Direction des Systèmes d'Information

Pôle ARESU

Accueil Imprimer Plan du site Credits