FR2809511A1 - Systeme et procede de gestion des transactions de composants ejb dans un annuaire accede par ldap - Google Patents

Abstract

La présente invention concerne un procédé de gestion de transactions exécutés par des composants (8) EJB intégrés à un serveur (3) EJB d'un système (1) informatique, le système (1) comportant un annuaire (5) stocké dans des moyens de mémorisation d'une machine ressource (4) et dépourvu de fonctionnalités transactionnelles. Le système (1) selon la présente invention permet d'apporter des mécanismes transactionnelles au serveur (3) EJB et de gérer les fonctionnalités transactionnelles de l'annuaire (5). La présente invention concerne également le système de mise en oeuvre dudit procédé.

Description

SYSTEME ET PROCEDE DE GESTION DES TRANSACTIONS DE COMPOSANTS EJB DANS UN ANNUAIRE ACCEDE PAR LDAP présente invention concerne la technologie Enterprise Java Bean (EJB), plus particulièrement, l'accès transactionnel par LDAP composants EJB dans un annuaire d'un système informatique.

L'art antérieur technologie EJB, Enterprise JavaBeans (terme déposé à titre marque) définit une architecture pour déployer et exécuter des applications distribuees. La spécification de cette architecture a pour but de faciliter et normaliser le développement, le déploiement et l'assemblage au sein plates-formes informatiques de composants logiciels applicatifs, appeles composants EJB. Les composants EJB sont portables, transactionnels, sécurises, multi-utilisateurs, orientés bases de données. Ils sont non seulement indépendants de la machine dans laquelle ils sont installés et de son système d'exploitation mais aussi de la plate-forme à laquelle appartient ladite machine.

technologie LDAP (Leightweight Directory Access Protocol Protocole léger d'accès à un annuaire) est à ce jour un standard ouvert définissant une méthode d'accès et de mise à jour de données dans un service d'annuaire distribué de type objet.

il n'existe pas dans la spécification de la technologie EJB possibilité de gérer l'accès transactionnel des composants EJB dans moyens de stockage accédé par LDAP. Par ailleurs, le service d'annuaire accède par LDAP n'offre pas systématiquement de fonctionnalités transactionnelles. Une transaction est un ensemble d'opérations qui sont soit toutes effectuées, soit toutes annulées. Une transaction doit présenter les propriétés d'atomicité, de consistance, d'isolation et de durabilité.

Une transaction présente la propriété d'atomicité lorsqu'elle est realisée de manière complète ou pas du tout. En cas d'erreur dans l'une des opérations de la transaction, aucune opération n'est effectuée et les données reprennent leur état initial.

Une transaction présente la propriété d'isolation lorsqu'elle s'exécute manière indépendante à d'autres transactions.

Une transaction présente la propriété de consistance lorsqu'elle fait passer les données d'un état consistant à un autre état consistant, à savoir les caractéristiques invariables sont préservées d'un état ' un autre. La consistance est apportée par l'application elle-même.

Une transaction présente la propriété de durabilité lorsqu'une fois terminée, ses effets sont toujours persistants. La durabilité apportée par moyens de stockage.

Un but de la présente invention consiste à assurer la gestion de l'accès transactionnel des composants EJB dans un annuaire tel qu'un annuaire accédé par LDAP.

Un but de la présente invention consiste à assurer la gestion de l'accès transactionnel des composants EJB dans un annuaire dépourvu de fonctionnalités transactionnelles.

Un but de la présente invention consiste à garantir aux transactions les propriétés d'atomicité et d'isolation. Résumé de l'invention Dans ce contexte, la présente invention propose un procedé de gestion transactions exécutées par des composants EJB intégres à un serveur d'un système informatique, le système comportant un annuaire stocké dans des moyens de mémorisation d'une machine ressource (4) dépourvu fonctionnalités transactionnelles, procédé permettant créer, lire, modifier et/ou supprimer des données de l'annuaire, operations requises cours desdites transactions, au moyen d'une ressource transactionnelle d'une interface de programmation applicative API JNDITX adaptée fonctionnement des composants EJB.

La présente invention concerne également le système informatique de mise en ceuvre dudit procédé.

Présentation des figures D'autres caractéristiques et avantages de l'invention apparaîtront à la lumière la description qui suit, donnée à titre d'exemple illustratif et non limitatif la présente invention, en référence au dessin annexé dans lequel la figure est une vue schématique d'une forme de réalisation du système selon l'invention.

Description d'une forme de réalisation de l'invention Comme le montre la figure 1, un système informatique 1 est distribué et composé de machines 2 à 4 et 6 organisées en un ou plusieurs réseaux 7. Une machine est une unité conceptuelle très large, de nature matérielle et logicielle. Les machines peuvent être très diverses, telles que stations de travail, serveurs, routeurs, machines spécialisées. machine comprend au moins un processeur, au moins une mémoire, eventuellement un ou plusieurs périphériques... Seuls les composants machines du système 1 caractéristiques de la présente invention seront decrits, les autres composants étant connus de l'homme du métier.

II est à noter que les machines 2-4 et 6 sont susceptibles d'être regroupées les unes aux autres de diverses façons. La figure 1 représente un exemple de forme de réalisation de l'invention.

Le système informatique 1 selon la présente invention comporte au moins une machine 2 client, au moins une machine serveur 3 d'application appelé serveur EJB, au moins une machine ressource 4 qui dans la forme de réalisation décrite, comporte un annuaire 5 accédé par LDAP et appelé ci-après annuaire 5 LDAP, des moyens 6 de mémorisation descripteur de déploiement. Le système 1 est basé sur une architecture a trois niveaux avec serveur d'application.

L'application est entendue au sens large, à savoir tout module logiciel permettant réaliser un ensemble de procédures et de traitements destinés exemple à résoudre des problèmes administratifs, scientifiques ou techniques. Dans l'exemple illustré sur la figure 1, l'application ne peut être representée car elle est constituée de modules logiciels nombreux et variés suivant l'application sur des machines également variées.

La machine serveur 3 et la machine ressource 4 sont entendues au sens large, à savoir toute entité respectivement offrant des services aux machines clientes 2, contenant des informations nécessaires au fonctionnement des applications. Dans la forme de réalisation selon l'invention telle illustrée sur la figure , un composant 8 EJB est un module logiciel tournant sur la partie serveur de l'application, à savoir le serveur 3 EJB, serveur 3 EJB comprend au moins un module logiciel appelé source de données spécifique pour LDAP. La source de données spécifique pour LDAP contient le mécanisme nécessaire pour créer un contexte particulier de travail JNDI et donc un contexte particulier de travail LDAP. source de données est une entité logique fournissant un contexte de travail pour effectuer des opérations sur des données : lesdites données sont externes au serveur 3 EJB et stockées dans l'annuaire 5 LDAP. Une source données permet de récupérer un contexte travail pour effectuer des opérations. Les requêtes de création modification, suppression, recherche, lecture sont effectuées sur ledit contexte de travail. Les sources 9 de données disponibles font partie de la configuration du serveur Les composants EJB sont tenus de passer par une source 9 de données pour obtenir un contexte de travail. Un contexte de travail est contenu dans une entité plus large appelée ressource transactionnelle 10. Chaque source 9 de données gère une liste 11 de ressources 10 transactionnelles dans des moyens de mémorisation 12 de ressources tels que la memoire du serveur 3.

Le descripteur de déploiement est stocké dans moyens 6 de mémorisation tels qu'un disque dur et associe entre autres composant 8 EJB au contexte de l'annuaire 5 : le descripteur contient le nom de la source 9 de données sur lequel le composant EJB fonctionne. déploiement consiste notamment à configurer le composant EJB à partir descripteur de déploiement. Le serveur 3 EJB comprend un contrôleur 13 de transactions assurant la gestion des transactions pour le compte des composants 8 EJB. Toutes les transactions effectuées sur le serveur 3 utilise le controleur 13 de transactions. Le contrôleur 13 de transactions maintient la relation entre la transaction et les différentes ressources 10 transactionnelles engagées dans la transaction.

Dans la présente invention, la base de données utilisee pour lire, stocker, modifier les données sur lesquelles opèrent les transactions est l'annuaire 5 LDAP. Toute autre base de données ne disposant pas de moyens permettant de gérer les transactions pourrait être utilisée.

Le système 1 comporte un contrôleur 14 de ressources pour chaque base 5 de données interrogée par une transaction. Dans la forme de réalisation illustree sur la figure 1, le contrôleur 14 de ressource fait partie intégrante du serveur 3 EJB. Cependant, le contrôleur de ressource peut être indépendant dudit serveur 3 : le contrôleur 14 de ressources est par exemple un pilote intégré à la machine 4 ressource.

Le controleur 14 de ressource comporte une interface de programmation applicative ou API 15 JNDITX permettant de gérer les fonctionnalités transactionnelles et une API standard permettant d'accéder à LDAP, l'API 16 JNDI. Les données de l'annuaire 5 sont accédées par LDAP au travers du contrôleur 14 de ressources, soit des API 15 JNDITX et 16 JNDI. Des services de stockage 4a et de nommage 4b des machines 4 ressource sont utilisés à partir de l'API 16 JNDI. L'API 16 J est utilisée pour le nommage et le stockage.

L'API ITX 15 contrôle les ressources 10 transactionnelles dont l'existence enregistrée dans la liste 11. Les ressources 10 transactionnelles créent et utilisent un objet 17 de contexte un objet 18 de gestion transactions. Les ressources 10 transactionnelles gèrent les relations ces composants 17, 18 avec les transactions.

L'objet 17 de contexte permet d'établir l'accès composants 8 EJB avec l'annuaire 5. L'objet 17 de contexte indique caractéristiques suivantes : type d'annuaire, dans la forme de réalisation illustrée le type LDAP, adresse hypertoile (URL - Uniform Ressource Locator) de connexion vers l'annuaire 5. L'adresse hypertoile constitue une adresse définissant routage pour accéder à un composant logiciel déterminé dans un réseau que Internet. Les ordres des composants au cours d'une transaction pour créer une entrée dans l'annuaire 5 bind ), pour supprimer une entrée de l'annuaire ( unbind ), pour effectuer une lecture dans l'annuaire ( getAttributes ), pour modifier une entrée dans l'annuaire ( modifyAttributes ), ... sont transmis à l'annuaire 5 l'intermédiaire de l'objet 17 de contexte.

L'objet 18 de gestion des transactions est utilisé contrôleur 13 de transactions pour gérer les transactions et effectuer opérations transactionnelles standards de validation à deux phases two-phase commit ). opérations transactionnelles standards validation à deux phases, à savoir de préparation ( prepare ), de validation commit ), d'annulation ( rollback ), d'oubli ( forget ), rétablissement- récupération recovery ), ainsi que les opérations servant a délimiter la transaction, a savoir les opérations de mise en marche ( start ), de terminaison ( end ) sont implémentées dans l'objet 8 de gestion des transactions. délimitation de la transaction est réalisee automatiquement par le serveur EJB ou par le client, de manière explicite, le lancement et la gestion du protocole à deux phases par le contrôleur 13 transactions.

La ressource 10 transactionnelle tient à jour un journal 19 des modifications par transaction. Le journal est contenu lors du traitement de la transaction l'API 15 dans des moyens 20 de stockage de journaux tels qu'une mémoire du serveur 3 ou une mémoire de toute autre machine en liaison avec ressource 10 transactionnelle. Lors du procédé de validation à deux phases, et plus particulièrement la phase de préparation, le journal 19 est enregistré dans des moyens 20' de mémorisation persistants tel un disque dur. journal 19 comprend deux parties : le journal de l'état données avant modifications et le journal de l'état des données apres modifications appelées respectivement journal avant et journal après. ressource 1 gère la concurrence d'accès des transactions à l'aide d'une table 21 concurrence d'accès mémorisé dans des moyens 22 stockage tables tels qu'une antémémoire du serveur 3 EJB par exemple.

Le contrôleur 13 de transactions gère une liste 23 des objets 18 gestion transactions dans des moyens 24 de stockage de ressources tels qu'une memoire du serveur 3 ou une mémoire de toute autre machine en liaison avec le contrôleur 13 de transactions.

Le systeme 1 informatique selon la présente invention comporte moyens permettant d'intégrer les mécanismes transactionnels propres a l'annuaire au serveur EJB 3 et d'offrir les fonctionnalités transactionnelles absentes l'annuaire 5.

Lesdits moyens comprennent l'API 15 JNDITX comportant au moins une ressource 10 transactionnelle permettant d'assurer l'accès à l'annuaire 5 en gérant les mécanismes transactionnels nécessaires à cet accès. La ressource transactionnelle est enregistrée dans le serveur EJB dans la liste 11 ressources gérée par la source 9 de données spécifique pour LDAP. Les caractéristiques de la technologie EJB, de l'annuaire LDAP et de l'interface JNDI nécessaires à la compréhension de l'invention sont exposées dans ce qui suit.

Dans la technologie EJB, le composant 8 EJB est portable à travers tout type de serveurs et de systèmes d'exploitation. Le composant EJB encapsule des ensembles complets de comportements.

Les composants EJB dans la technologie EJB sont de deux types : le composant EJB de type session et le composant EJB de type entité.

Le composant EJB de type session, appelé ci-apres composant EJB session, représente un unique client dans le serveur 3 EJB. Un client communique avec le serveur EJB en appelant des méthodes appartenant aux composants EJB session. Un composant EJB session exécute une tâche pour ledit client. Lorsque la communication avec le client est interrompue, le composant EJB session correspondant n' plus valable -: il n'est pas persistant. Le composant EJB session subsiste le temps d'un appel de méthode ou d'une session client.

composant EJB de type entité, appelé ci-apres composant EJB entité, représente un enregistrement de données dans un moyen de stockage tel qu'une base de données.

présente invention se base sur les composants de type entité. Quelques rappels sur les principales caractéristiques de l'annuaire LDAP et de l'interface JNDI sont faits dans ce qui suit pour permettre de mieux comprendre l'invention.

Les caractéristiques d'un annuaire LDAP sont les suivantes # L'unite de stockage est appelée une entrée LDAP 25 (figure 1 # A entrée LDAP est associé un certain nombre d'informations qui lui sont propres ; ces informations sont appelées les attributs l'entrée.

Une entrée 25 est identifiée de manière non ambiguë l'intermédiaire d'un nom 26 unique, appelé le dn (nom distinctif - distinguished name).

# L'annuaire 5 LDAP possède un fichier de configuration appelé le schéma 27, qui définit les différents types d'entrées admissibles.

La figure 1 représente une entrée 25 LDAP. L'entrée 25 LDAP est représentée par le dn 26 et une liste 28 d'attributs. Chaque attribut de la liste 28 est constitué d'un nom (d'une clé sur la figure 1) et d'une série de valeurs.

Pour manipuler les entrées 25 d'un annuaire 5, le langage java offre les types Attribute et Attributes. Le type java Attribute ( javax.naming.Directory.Attribute ) dans la présente forme de réalisation représente un attribut LDAP identifié par un nom, et une série de valeurs associées audit attribut. Une ligne de la liste 28 d'attributs vue plus haut est de type Attribute. Le type java Attributes ( javax.naming.Directory.Attributes ) représente une liste constituée d'une collection d'éléments de type Attribute. La liste 28 d'attributs d'une entrée LDAP est de type Attributes.

L'entrée 25 LDAP se caractérise, comme vu précédemment, par un nom (dn 26), de type chaîne de caractères et par une succession d'objets type Attribute formant un unique objet de type Attributes (liste 28). Le est formé en partie par le couple < nom d'attribut, valeur d'attribut> d'un attribut particulier appelé attribut de nommage. opérations d'accès en lecture/écriture aux données des bases données sont réalisées au moyen d'interface programmatique applicative, API. L'API 16 JNDI (Java Naming and Dirëctory Interface - Interface java nommage et annuaire) permet un accès en lecture/écriture à différents services nommage et/ou de stockage dont par exemple un service d'annuaire accédé par LDAP.

La présente invention porte sur les transactions effectués par composants 8 EJB d'entité pour le compte de client 2 dans l'annuaire LDAP.

Comme développé dans ce qui suit, la présente invention permet d'apporter transactions traitées par les composants 8 EJB et nécessitant l'accès LDAP à des données de l'annuaire 5, les propriétés d'atomicite et d'isolation.

système 1 fonctionne de la manière suivante.

Lorsque le serveur 3 EJB démarre, il prend connaissance différentes sources de données configurées et notamment de la source données spécifique pour LDAP et les initialise : les sources 9 de données sont instanciées et le serveur 3 les enregistre dans le service de nommage. A partir ce moment, les composants 8 EJB qui ont besoin d'accéder a une source de données peuvent le faire par l'intermédiaire du service de nommage: il leur suffit de l'interroger pour récupérer une source de données valide.

Lors du déploiement, le nom de la source 9 de données spécifique à l'accès à une base de données et son protocole d'accès, dans l'exemple illustré spécifique à l'accès à l'annuaire LDAP, est écrite dans le descripteur 6 de déploiement. Le composant 8 EJB est déployé sur la source 9 de données LDAP dont le nom figure dans son descripteur de déploiement.

Lorsque rendu nécessaire par un appel client, le serveur 3 crée une instance d'un composant EJB et démarre éventuellement une nouvelle transaction.

Au moyen nom de la source 9 de données LDAP figurant dans le descripteur de deploiement, le composant 8 EJB interroge le service de nommage pour récupérer ladite source 9 de données LDAP. Le composant 8 EJB interroge la source 9 de données LDAP pour obtenir un contexte de travail JNDI. La source de données LDAP implémente une méthode permettant au composant d'obtenir un contexte pour la transaction en cours. Le contexte de travail marche de pair avec l'objet 18 de gestion transaction au sein d'un objet plus global qui est la ressource transactionnelle. Le composant ne voit que l'objet 17 de contexte sur lequel passe ses requêtes à destination de l'annuaire et ne voit pas la ressource 10 transactionnelle; cependant, l'API JNDITX gère l'association entre l'objet 17 et l'objet 18.

Un objet transaction contenant les caractéristiques de transaction en cours créé dans le contrôleur 13 de transaction pour cette transaction. C'est sur cet objet transaction géré par le controleur 13 de transaction que vont venir s'enregistrer les différents objets 18 gestion de transaction qui sont engagés dans la transaction. Le controleur 13 de transaction sait ainsi sur quel objet il doit effectuer les étapes préparation (prepare) et de validation (commit). Le contrôleur 13 de transactions tient à jour la liste 23 des objets 18 de gestion des transactions engagées dans la transaction en question.

La source 9 de données LDAP gère une liste 11 ressources 10 transactionnelles de manière à optimiser l'utilisation machines 4 ressource et ameliorer ainsi les performances. Chaque source 9 de données gère une liste lui est propre.

A une source 9 de données est associée une liste 1 de ressources 10 transactionnelles disponibles. Une ressource 10 transactionnelle, soit un objet 17 de contexte et un objet 18 de gestion des transactions, est associée à une instance composant 8 EJB pour une transaction donnée.

Plusieurs instances d'un même composant 8 EJB peuvent partager un objet 17 (donc un objet 18 et une ressource 10) mais deux instances de deux composants 8 déployées sur deux sources de données différentes accèdent à l'annuaire à travers deux objets 17 distincts.

Lorsque composant 8 requiert un contexte de travail auprès de la source 9 de données, la source 9 interrogée extrait de la liste 11 une ressource 10 transactionnelle. Soit il existe une ressource 10 transactionnelle disponible, dans ce cas elle est utilisée. Soit il n'existe pas de ressource transactionnelle et la source de données doit en créer une.

L'objet ressource 10 transactionnelle créé est enregistré au sein du serveur 3 EJB par mécanismes standards d'enregistrement de ressource.

Comme indique plus haut, le composant EJB ne voit l'objet 17 de contexte sur lequel il passe ses requêtes à destination l'annuaire et ne voit pas la ressource 10 transactionnelle associée.

L'objet ressource 10 transactionnelle gère le lien entre la transaction, l'objet 17 de contexte et l'objet 18 de gestion des transactions : pour une transaction donnée, une instance de composant EJB utilise l'objet 17 de contexte pour accéder à l'annuaire, pendant que l'objet 18 de gestion de transaction associé est enregistré auprès du contrôleur 13 transaction par ressource 10 transactionnelle, comme vu plus haut.

Le composant 8 EJB effectue les requêtes associées à transaction provenant de la machine 2 client sur le contexte fourni par source 9 de donnees LDAP. Les requêtes sont interceptées par l'API JNDITX du controleur 14 de ressource. L'API 15 JNDITX réalise traitements nécessaires à la gestion des transactions. Pour chacune requêtes effectuées sur l'annuaire au cours d'une transaction, l'objet intercepte la requete et effectue la requête dans les moyens 20 de stockage de journal, en prenant soin de stocker dans le journal 19 avant, l'état l'entrée avant la requête, et dans le journal 19 après, l'état de l'entrée après la requête.

L'ensemble des modifications que le composant 8 EJB souhaite opérer sur les données de l'annuaire 5 sont conservées dans les moyens 20 de stockage de journal pour une ressource 10 donnée.

La ressource 10 transactionnelle traite la concurrence d'accès au moyen de la table 21 dans laquelle elle indique les entrées accédées par la transaction en cours. Chacune des entrées accédées cours d'une transaction est verrouillée globalement dans la table des entrées accédées partagées par l'ensemble des transactions. ressource 10 transactionnelle verrouille les entrées 25 de l'annuaire 5 accédées par la transaction en cours en introduisant le dn 26 de ces entrées dans la table 21 de concurrence d'accès: aucune autre transaction ne peut alors accéder à ces entrées pendant la durée de la transaction concernée.

La sauvegarde et le verrouillage des entrées de l'annuaire 5 sont effectués pour chacune des opérations de modification de la transaction.

Le journal avant et le journal après ainsi que la table 21 sont gérés dans l'API JNDITX, et ne sont pas liés à une ressource 10 transactionnelle donnée mais à une transaction donnée, puisque ces informations sont partagees par toutes les ressources 10 transactionnelles d'une transaction. cours de la transaction, qui comprend un certain nombre de requêtes transactionnelles, des objets 18 ont été enregistrés auprès du contrôleur 13 de transaction ; des entrées dans la table 21 entrées accédees ont été verrouillées ; des enregistrements ont été creés dans le journal 19 avant et dans le journal 19 après :l'annuaire 5 n'a encore été modifie. Tout s'est passé en mémoire. Si un problème survient à ce stade, l'annuaire 5 conserve le même état puisqu'il n'a pas encore éte modifié. fin de la transaction est décidé par le serveur EJB ou par le client le controleur 13 de transactions reçoit un ordre de validation "commit". II décide alors d'engager le processus de validation à deux phases pour finir la transaction. II consulte la liste des objets 18 engagés dans la transaction, et leur applique les opérations de validation à deux phases. Chacun des objets 18 reçoit un ordre de préparation prepare (1 ère phase), puis si tout se passe bien, un ordre de validation commit (2ème phase). En cas de problème pendant la première phase, la transaction ne peut passer à l'étape de validation et chacun des objets 18 reçoit un ordre d'annulation rollback pour rétablir l'état initial. C'est ce mécanisme orchestré par le contrôleur 13 de transactions qui assure l'atomicité de la transaction.

A la fin de la transaction, le contrôleur 13 de transactions amorce et conduit le protocole de validation à deux phases Les opérations de préparation, de validation, d'annulation, d'oubli sont implémentées dans le contrôleur 14 de ressources. Le contrôleur 13 de transactions fait appel à l'objet 18 de gestion des transactions lorsqu'il souhaite exécuter l'une de ces quatre opérations.

Les opérations du protocole à deux phases sont implémentées de la manière suivante dans l'objet 18 de gestion des transactions. contrôleur de transaction transmet un ordre préparation sur chacun objets 18 d'une transaction donnée. L'opération de préparation consiste sauvegarder l'état des différentes entrées 25 LDAP de l'annuaire 5 avant toute modification par la transaction concernée journal 19 avant dans moyens 20 de stockage persistants du journal. cas d'erreurs, de pannes autres problèmes survenant au cours la transaction, le controleur de transactions va décider que celle-ci ne peut etre réalisée dans son entier et qu'il vaut mieux rétablir l'état initial: entrées LDAP reprendront leurs états initiaux sauvegardés à partir informations du journal avant. L'objet 18 de gestion des transactions verrouille l'accès sur chacune des entrées 25 LDAP destinées à être modifiées la transaction.

Les entrees verrouillées, l'objet 18 de gestion des transactions applique les modifications stockées dans le journal après et requises la transaction.

Les entrees 25 LDAP sont constituées, lues, modifiées ou supprimées dans la partie l'annuaire LDAP indiquée par le contexte. composant 8 EJB opère sur les données de l'annuaire 5 par l'intermédiaire contrôleur 14 de ressource.

L'opération de validation consiste, une fois l'ensemble des modifications effectuées pendant la préparation, à déverrouiller les accès aux entrées 25 LDAP pour les rendre accessibles aux autres transactions, et à supprimer le journal avant des moyens 20 de stockage.

L'opération d'annulation consiste, si un problème survient lors de l'opération de préparation, à revenir en arrière, à extraire du journal 19 avant l'état initial des différentes entrées concernées et à réappliquer cet état, puis à déverrouiller l'accès à l'annuaire 5 ou aux entrées 25 LDAP. Le processus de validation à deux phases étant terminé, les ressources 10 engagées dans la transaction sont remises dans la liste 11 de ressources transactionnelles de la source de données.

L'isolation des transactions est apportée par le journal après des données est géré en mémoire pendant la transaction et qui est relatif à une transaction donnée ; les autres transactions ne voient pas ces modifications et ne peuvent accéder aux entrées qui sont verrouillées dans la table globale des entrées accédées. L'isolation des transactions est garantie aussi par la table 21 enregistrée dans les moyens 22 de stockage.

Chaque transaction ne voit que la partie des moyens 22 qui la concerne; table 21 empêche deux transactions de travailler sur les mêmes entrées. ailleurs, verrouillage réalisé lors de l'opération de préparation avant l'application des différentes modifications et le déverrouillage réalisé apres l'application desdites modifications garantissent également l'isolation modifications sont vues toutes en même temps des autres transactions lors de la liberation des verrous sur les entrées accédées pendant la phase validation ou pas du tout.

L'atomicité est apportée par le contrôleur de transaction, soit phase préparation s'est bien passée et l'ensemble des modifications a été appliqué, soit la phase de préparation s'est mal passée, et on rétablit l'état precedent à l'aide du journal avant. présente invention concerne donc un procédé de gestion de transactions exécutés par les composants 8 EJB intégrés au serveur 3 EJB du systeme 1 informatique, le système 1 comportant l'annuaire 5 stocké dans moyens de mémorisation de la machine ressource 4 et dépourvu de fonctionnalités transactionnelles, procédé permettant de créer, lire, modifier et/ou supprimer des données de l'annuaire 5, opérations requises au cours desdites transactions, au moyen de la ressource 10 transactionnelle de l'interface de programmation applicative API 15 JNDITX adaptée fonctionnement des composants 8 EJB. source 9 de données spécifique du protocole d'accès à l'annuaire 5 fournit au composant 8 EJB un contexte de travail propre audit protocole d'accès. source 9 de données gère une liste 11 de ressources 10 transactionnelles stockée dans les moyens 12 de memorisation de ressources et fournit au composant 8 EJB souhaitant exécuter une transaction un contexte de travail lié à une ressource 10 transactionnelle pour ladite transaction. ressource 10 transactionnelle enregistre dans le journal 19 l'ensemble des modifications opérées sur l'annuaire 5 par transactions ainsi des données de l'annuaire 5 avant toutes modifications.. ressource 10 transactionnelle traite la concurrence d'accès des transactions dans l'annuaire 5 à l'aide de la table 21 de traitement de la concurrence d'accès stockée dans les moyens 22 de memorisation de tables. contrôleur 13 de transactions gère la liste 23 ressources transactionnelles nécessaires à la transaction traitée, la este 23 étant mémorisée dans des moyens 24 de stockage de ressources.

La présente invention concerne également le système informatique comprenant la machine client 2, le serveur 3 EJB comportant des composants 8 EJB exécutant des transactions requises par machine client 2 et le contrôleur 13 de transactions, l'annuaire dépourvu de fonctionnalités transactionnelles et stocké dans des moyens de mémorisation de la machine 4 ressource, l'interface de programmation applicative API 15 JNDITX traitant les opérations requises par les transactions dans l'annuaire 5 au moyen de la ressource 10 transactionnelle adaptée au fonctionnement des composants EJB. Le systeme comprend la source 9 de données spécifique protocole d'accès à l'annuaire 5 gérant la liste 11 de ressources 10 transactionnelles mémorisée dans les moyens 12 de mémorisation de ressources.

Le systeme comprend les moyens 20, 20' de stockage journal 19 sauvegardant données de l'annuaire 5 avant toutes modifications et les modifications operées sur ledit annuaire 5 par les transactions.

Le système comprend les moyens 24 de stockage ressources permettant de stocker la liste 23 des machines 4 ressources necessaires à la transaction traitée.

Le système comprend les moyens 22 de mémorisation de tables permettant de stocker les tables 21 de traitement de la concurrence d'accès des transactions à l'annuaire 5.

Claims (1)

REVENDICATIONS . Procédé permettant de créer, lire, modifier et/ou supprimer des donnees manière transactionnelle dans une base (5) de données stockée dans moyens de mémorisation d'une machine ressource (4) et dépourvue de fonctionnalités transactionnelles, au moyen d'une ressource 0) transactionnelle d'une interface de programmation applicative API 5) JNDITX, le procédé étant adapté au moyen d'une source (9) de donnees specifique au fonctionnement de composants (8) EJB effectuant transactions gérés dans un serveur (3) EJB disposant d'un contrôleur transactions. 2. Procédé selon la revendication 1, caractérisé en ce que une source (9) données spécifique du protocole d'accès à l'annuaire (5) fournit au composant (8) EJB un contexte de travail propre audit protocole d'accès. 3. Procédé selon la revendication 2, caractérisé en ce que la source (9) de données gère une liste (11) de ressources (10) transactionnelles stockée dans des moyens (12) de mémorisation de ressources et fournit au composant (8) EJB souhaitant exécuter une transaction un contexte de travail lié à une ressource (10) transactionnelle pour ladite transaction. Procédé selon l'une des revendications 1 à 3, caractérisé en ce que la ressource (10) transactionnelle enregistre dans un journal (19) l'ensemble modifications opérées sur l'annuaire (5) par les transactions. Procédé selon l'une des revendications 1 à 4, caractérisé en ce la ressource (10) transactionnelle enregistre dans un journal (19) des donnees l'annuaire (5) avant toutes modifications. Procédé selon l'une des revendications 1 à 5, caractérisé en ce que la ressource (10) transactionnelle traite la concurrence d'accès des transactions dans l'annuaire (5) à l'aide d'une table (21) de traitement de la concurrence d'accès stockée dans des moyens (22) de mémorisation de tables. Procédé selon l'une des revendications précédentes, caractérisé en ce la ressource (10) transactionnelle comprend un objet 7) de contexte permettant d'établir l'accès des composants (8) EJB à l'annuaire (5) et un objet (18) de gestion des transactions utilisé par un contrôleur (13) de transactions pour gérer les transactions et effectuer opérations transactionnelles standards de validation à deux phases Procédé selon la revendication 7, caractérisé en ce que le contrôleur (13) transactions gère une liste (23) d'objets (18) de gestion transactions necessaires à la transaction traitée, la liste (23) étant mémorisée dans des moyens (24) de stockage de ressources. 9. Système informatique comprenant une machine client un serveur (3) gérant des transactions pour le compte de composant (8) EJB au moyen d'un contrôleur (13) de transactions, une base données (5) depourvue de fonctionnalités transactionnelles et stockée dans des moyens mémorisation d'une machine (4) ressource, interface de programmation applicative API (15) permettant aux composants EJB d'effectuer des opérations de manière transactionnelle à destination de la base de données (5) au moyen d'une ressource (10) transactionnelle. Système selon la revendication 9, caractérisé en ce comprend une source (9) de données spécifique du protocole d'accès a l'annuaire (5) gerant une liste (11) de ressources (10) transactionnelles mémorisée dans moyens (12) de mémorisation de ressources.

1 . Système selon l'une des revendications 9 ou 10, caractérisé en ce comprend des moyens (20, 20') de stockage d'un journal (19) sauvegardant données de l'annuaire (5) avant toutes modifications et les modifications opérées sur ledit annuaire (5) par les transactions. Système selon l'une des revendications 9 à 11, caractérisé en ce comprend des moyens (24) de stockage de ressources permettant stocker une liste (23) d'objets (18) de gestion des transactions nécessaires a transaction traitée. Système selon l'une des revendications 9 à 12, caractérisé en ce comprend des moyens (22) de mémorisation de tables permettant de stocker tables (21) de traitement de la concurrence d'accès des transactions a l'annuaire (5).