FR2816080A1 - Procede de propagation de contextes d'invocation a travers un systeme distribue a objets - Google Patents
Procede de propagation de contextes d'invocation a travers un systeme distribue a objets Download PDFInfo
- Publication number
- FR2816080A1 FR2816080A1 FR0013917A FR0013917A FR2816080A1 FR 2816080 A1 FR2816080 A1 FR 2816080A1 FR 0013917 A FR0013917 A FR 0013917A FR 0013917 A FR0013917 A FR 0013917A FR 2816080 A1 FR2816080 A1 FR 2816080A1
- Authority
- FR
- France
- Prior art keywords
- activity
- context
- interceptor
- request
- incoming request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/465—Distributed object oriented systems
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Multi Processors (AREA)
- Stored Programmes (AREA)
Abstract
Procédé de propagation de contextes d'invocation à travers un système distribué à objets, ledit système comportant une interface API de gestion d'activités et chaque objet étant associé à un intercepteur et à un authentificateur de contexte de requête entrante reçue par l'intercepteur lors d'une invocation dudit objet. Selon l'invention, ledit procédé comprend les opérations consistant à : - créer un gestionnaire d'activités destiné à l'intercepteur pour, notamment, d'une part, établir une association entre une activité d'un objet consécutive directement à une requête entrante invoquant ledit objet et le contexte de ladite requête entrante tel qu'identifié par l'authentificateur de contexte, et, d'autre part, récupérer le contexte dudit gestionnaire d'activités et l'associer à la requête sortante de l'objet,- ajouter à ladite interface API de gestion d'activités une méthode destinée à récupérer le contexte courant du gestionnaire d'activités et de l'associer à toute activité de l'objet consécutive indirectement à la requête entrante. Application à la sécurité des systèmes distribués à objets.
Description
<Desc/Clms Page number 1>
La présente invention concerne un procédé de propagation de contextes d'invocation à travers un système distribué à objets.
L'invention trouve une application avantageuse dans tous les cas où il est nécessaire de connaître, notamment par leur contexte, l'ordre causal des interactions entre les objets, c'est-à-dire, de connaître pour chaque invocation, quelles sont les invocations qu'elle a engendrées. On sait en effet que les services offerts par ce type de système distribué à objets sont réalisés par des interactions entre les objets qui le composent, l'invocation d'un service pouvant ainsi engendrer une succession d'appels à des méthodes de différents objets.
L'invention s'applique plus particulièrement à la sécurité des systèmes distribués à objets. Il est fréquent que l'accès à une méthode d'un objet soit conditionné par l'identité de l'initiateur, le plus souvent l'utilisateur. Pour contrôler l'accès aux méthodes des objets, il est donc nécessaire de fournir l'identité du client à tous les objets participant à la réalisation du service demandé.
Dans d'autres applications, comme la supervision ou l'audit, il est également nécessaire de connaître l'identité, et, plus généralement, le contexte des différents intermédiaires ayant participé à la réalisation du service.
Le standard CORBA (Common Object Request Broker Architecture) de l'OMG (Object Management Group) propose un certain nombre de spécifications destinées au développement d'infrastructures de communication orientées objets. Parmi ces spécifications, on trouve celle des intercepteurs.
Les intercepteurs s'intercalent entre l'ORB (Object Request Broker), le noyau de l'infrastructure de communication, et les objets applicatifs, et permettent de réaliser des traitements sur les requêtes entrantes ou sortantes de manière transparente pour les objets applicatifs. Ils sont donc naturellement utilisés pour implémenter des services que l'on veut transparents pour les objets applicatifs : audit, contrôle d'accès, supervision, etc.
Un certain nombre d'implémentations de ces spécifications CORBA propose un service d'intercepteurs. En revanche, aucun de ces produits ne
<Desc/Clms Page number 2>
permet la propagation transparente d'informations ; la propagation ne pouvant se faire sans que les objets applicatifs ne participent explicitement. Il devient alors impossible dans certains cas d'implémenter des services totalement transparents pour les objets applicatifs.
Les intercepteurs permettent donc de réaliser des actions sur les requêtes entrantes ou sortantes de façon transparente pour l'objet CORBA. La plupart des ORB implémentant cette notion d'intercepteur n'offrent pas, en revanche, de mécanisme de propagation transparente de l'information. Le problème réside dans le fait qu'un intercepteur n'a aucun moyen de savoir, dans tous les cas, qu'elle est la relation entre les requêtes entrantes et les requêtes sortantes. Pour offrir un mécanisme de propagation transparent, il est nécessaire pour un intercepteur de savoir, pour chaque requête sortante, si elle est consécutive à une requête entrante, et si oui laquelle, ou s'il s'agit d'une requête envoyée spontanément par l'objet.
Comme on peut le voir sur la figure 1 qui illustre le mécanisme d'invocation d'un objet applicatif dans un système à intercepteur connu, lorsqu'un objet applicatif reçoit une invocation une nouvelle activité Ai pour le traitement de cette invocation est créée au moyen d'une interface de programmation applicative (API pour Application Programming Interface ) de gestion d'activités. Un authentificateur identifie le contexte de l'invocation et donc l'activité créée. Si l'objet utilise cette même activité Ai pour réaliser une invocation d'un autre objet, l'intercepteur peut directement vérifier qu'il s'agit d'une requête sortante consécutive à la requête entrante et lui associer le contexte identifié par l'authentificateur. Seul ce cas de figure ne soulève aucune ambiguïté. En effet, si la requête reçue engendre la création d'une nouvelle activité A2 dédiée à l'invocation d'un autre objet, l'intercepteur n'est plus en mesure de savoir si cette invocation est consécutive à la requête entrante ou s'il s'agit d'une requête spontanée A3. Il est donc impossible de propager le contexte relatif aux requêtes entrantes des invocations de l'objet.
Dans ce cas, la propagation du contexte nécessite une modification du code des objets applicatifs. Il est en effet nécessaire de demander explicitement à l'application d'associer le contexte de la requête entrante à la nouvelle activité créée A2. Or, les codes des objets applicatifs ne sont généralement pas disponibles pour que les développeurs puissent effectuer cette modification.
<Desc/Clms Page number 3>
Les services d'infrastructure offerts par les systèmes distribués à objets actuels ne permettent donc pas de déterminer de manière transparente l'ordre causal des invocations. La présente invention est destinée à enrichir les services offerts par ces infrastructures pour garantir cette propriété de traçabilité transparente.
Aussi, le problème technique à résoudre par l'objet de la présente invention est de proposer un procédé de propagation de contextes d'invocation à travers un système distribué à objets, ledit système comportant une interface API de gestion d'activités et chaque objet étant associé à un intercepteur et à un authentificateur de contexte de requête entrante reçue par l'intercepteur lors d'une invocation dudit objet, procédé qui permettrait de déterminer l'ordre causal des invocations de manière transparente et donc, de connaître l'identité des objets impliqués dans la réalisation d'un service, ainsi que l'ordre dans lequel ils sont activés, sans que les objets eux-mêmes n'aient à intervenir directement dans le processus, offrant donc notamment la possibilité de mettre en place une politique de contrôle d'accès fine.
La solution au problème technique posé consiste, selon, la présente invention, en ce que ledit procédé comprend les opérations consistant à : - créer un gestionnaire d'activités destiné à l'intercepteur pour, notamment, d'une part, établir une association entre une activité d'un objet consécutive directement à une requête entrante invoquant ledit objet et le contexte de ladite requête entrante tel qu'identifié par l'authentificateur de contexte, et, d'autre part, récupérer le contexte dudit gestionnaire d'activités et l'associer à la requête sortante de l'objet, - ajouter à ladite interface API de gestion d'activités une méthode destinée à récupérer le contexte courant du gestionnaire d'activités et de l'associer à toute activité de l'objet consécutive indirectement à la requête entrante.
Ainsi, en créant un gestionnaire d'activités et en enrichissant l'API offerte par le langage de développement pour la gestion d'activités (création, synchronisation, destruction,...), le procédé de l'invention permet de maintenir à jour les associations entre tous les types d'activités et les contextes d'invocation. Ces associations peuvent ensuite être utilisées par les intercepteurs pour récupérer les contextes associés aux requêtes sortantes.
<Desc/Clms Page number 4>
La propagation des contextes ne nécessite alors plus l'intervention des objets applicatifs, ce qui permet le développement de services totalement transparents.
Le procédé selon l'invention fonctionne de la manière suivante. Lorsque l'intercepteur reçoit une requête, il en extrait le contexte et demande au gestionnaire d'activités de créer une association entre ce contexte et l'activité courante consécutive directement à la requête entrante. L'invocation est ensuite transmise à l'objet applicatif.
Si cette même activité est utilisée par l'objet applicatif pour invoquer un autre objet, l'intercepteur peut directement récupérer le contexte relatif à l'activité courante en interrogeant le gestionnaire d'activités et l'associer à la requête sortante.
Lorsque l'objet applicatif désire crée une nouvelle activité pour invoquer un autre objet, il doit utiliser l'APi de gestion d'activités enrichie. La nouvelle activité créée par cette API, consécutive indirectement à la requête entrante, hérite du contexte de l'activité mère. Il suffit alors à l'intercepteur de récupérer directement le contexte de l'activité courante, à savoir l'activité fille, et l'associer à la requête sortante.
Si l'activité courante n'est pas consécutive, directement ou indirectement, à une requête entrante, aucun contexte ne lui est associé. C'est le cas notamment lorsque l'objet applicatif invoque spontanément un autre objet. Dans ce cas, l'activité n'a pas été créée pour gérer une requête entrante. Elle n'est pas non plus la fille d'une activité dédiée à la gestion d'une requête entrante.
Elle n'est donc associée à aucun contexte.
La description qui va suivre en regard des dessins annexés, donnés à titre d'exemples non limitatifs, fera bien comprendre en quoi consiste l'invention et comment elle peut être réalisée.
La figure 2 est un schéma d'un système distribué à objets fonctionnant selon le procédé conforme à l'invention.
La figure 3 est une variante du système distribué de la figure 2.
On se placera dans le cas où le besoin exprimé pour sécuriser le système distribué à objets des figures 2 et 3 est de pouvoir propager de manière transparente jusqu'au serveur et à travers l'objet applicatif le contexte particulier consistant en l'identité du client, initiateur des invocations.
<Desc/Clms Page number 5>
De manière connu, le système distribué représenté aux figures 2 et 3 comporte une interface API de gestion d'activités définie par la classe Thread standard comprenant la méthode Thread ().
Les objets (client, applicatif et serveur) comportent des intercepteurs aptes à modifier les requêtes pour y ajouter et extraire un contexte d'invocation, notamment la liste des identités des objets impliqués dans la chaîne d'invocation.
Par ailleurs, Il est prévu que les intercepteurs comprennent un mécanisme d'authentification, par exemple SSL, entre les objets. Ce mécanisme est classiquement utilisé par les intercepteurs pour permettre à un objet serveur d'authentifier le contexte d'une requête entrante invoquée par un objet client.
De manière à pouvoir propager les contextes d'invocation à travers le système distribué, il est créé un gestionnaire d'activités ThreadManager offrant aux intercepteurs une API leur permettant : - d'ajouter une nouvelle association (méthode setContext) entre l'activité courante et le nouveau contexte correspondant à la requête entrante (paramètre context).
- de récupérer, s'il existe, le contexte associé à l'activité courante (méthode getContext).
- de supprimer l'association entre l'activité courante et son contexte (méthode deleteContext). void setContext (Object context)
Object getContext () void deletecontexto
Cet objet est une classe à instance unique (et donc partagé par tous les objets du même processus, et donc en particulier par les intercepteurs) qu'il est possible de récupérer de la manière suivante : private static ThreadManager manager = Thread Manager. getl nsta nceo ;
Object getContext () void deletecontexto
Cet objet est une classe à instance unique (et donc partagé par tous les objets du même processus, et donc en particulier par les intercepteurs) qu'il est possible de récupérer de la manière suivante : private static ThreadManager manager = Thread Manager. getl nsta nceo ;
<Desc/Clms Page number 6>
De même, la propagation transparente des contextes nécessite d'enrichir l'API de gestion des activités afin d'associer le contexte courant à une nouvelle activité créée par l'objet applicatif.
Deux méthodes sont possibles pour enrichir une API : modifier l'API offerte par le langage de programmation ou développer une API spécifique héritant de l'API standard et enrichissant les méthodes qu'elle propose. La première approche offre un niveau de transparence maximal. En revanche, il est nécessaire dans ce cas de disposer des sources du langage de développement, ce qui n'est pas toujours possible. L'exemple présenté ici consiste à développer une API spécifique selon la deuxième approche.
Une classe FtThread permet d'associer un contexte à chacune de ses instances. Cette classe hérite de la classe Thread standard et offre les mêmes constructeurs (i. e. les mêmes signatures). Une méthode supplémentaire getContext permet de récupérer le contexte associé à une activité.
FtThread ()
FtThread (Runnable target)
FtThread (Runnable target, String name)
FtThread (String name)
FtThread (ThreadGroup group, Runnable target)
FtThread (ThreadGroup group, Runnable target, String name)
FtThread (ThreadGroup group, String name)
Object getContext ()
Pour permettre une propagation d'informations, les objets applicatifs doivent utiliser cette classe pour la création d'activités.
FtThread (Runnable target)
FtThread (Runnable target, String name)
FtThread (String name)
FtThread (ThreadGroup group, Runnable target)
FtThread (ThreadGroup group, Runnable target, String name)
FtThread (ThreadGroup group, String name)
Object getContext ()
Pour permettre une propagation d'informations, les objets applicatifs doivent utiliser cette classe pour la création d'activités.
En Java par exemple, deux méthodes sont possibles pour créer une activité. La première consiste à créer une classe héritant de la classe FtThread. public class ExtendThread extends FtThread {
ExtendThread public void runo }
La création et l'exécution de l'activité sont alors réalisées de la manière suivante :
ExtendThread public void runo }
La création et l'exécution de l'activité sont alors réalisées de la manière suivante :
<Desc/Clms Page number 7>
ExtendThread thread = new ExtendThread (target) ; thread start (),
La seconde méthode consiste à créer une classe implémentant l'interface
Runnable. public class ImplementThread Implements Runnable { lmplementthreado public void runo }
La création et l'exécution de l'activité sont alors réalisées de la manière suivante : lmplementthread thread = new ImplementThread(), new FtThread (thread). start (),
Le procédé de propagation de contextes conforme à l'invention fonctionne selon les opérations suivantes représentées sur la figure 2 : 1. Lorsque l'intercepteur de l'objet applicatif reçoit une requête, il authentifie le client, crée un contexte contenant l'identité du client et associe ce contexte à l'activité courante Ai, consécutive directement à la requête entrante, en utilisant le gestionnaire d'activités ThreadManager créé.
2. Si l'objet applicatif utilise cette même activité A,, pour invoquer le serveur, l'intercepteur récupère le contexte associé à cette activité en utilisant le gestionnaire d'activités ThreadManager et insère l'identité du client dans la requête envoyée.
3. Pour créer une nouvelle activité A, 2, consécutive indirectement à la requête entrante, et l'utiliser pour invoquer le serveur, l'objet applicatif doit utiliser l'API de gestion d'activités enrichie FtThread. La nouvelle activité A, 2 ainsi créée est alors associée de manière transparente au contexte de l'activité
A,,.
A,,.
<Desc/Clms Page number 8>
4. Le gestionnaire d'activités ThreadManager permet à l'intercepteur de récupérer le contexte associé à l'activité A, 2 et d'ajouter l'identité du client à la requête sortante.
5. Lorsque l'objet applicatif invoque le serveur de manière spontanée, c'est à dire. en utilisant une activité A, 3 qui n'a pas été engendrée par la réception d'une requête, l'intercepteur peut alors vérifier que l'activité courante A, 3 n'est associée à aucun contexte. L'identité du client n'est donc pas ajoutée à la requête sortante.
6. A la réception d'une requête, l'intercepteur du serveur authentifie l'objet applicatif et extrait le contexte associé à la requête. Il peut alors déterminer quel est le chemin suivi par la requête reçue.
Le serveur peut également utiliser le gestionnaire d'activités ThreadManager pour récupérer le contexte associé à l'activité courante et donc déterminer le chemin parcouru par la requête.
La figure 3 illustre une variante du procédé de l'invention dans laquelle l'objet applicatif stocke les requêtes entrantes dans une file de messages et utilise un ensemble (i. e. un"poo/') d'activités destiné à transmettre les requêtes reçues aux destinataires appropriés. Les API offertes ne suffisent plus pour permettre une propagation transparente d'informations. Ces activités ne sont, en effet, associées à aucun contexte.
En revanche, elles permettent aux développeurs de services de sécurité d'offrir des API permettant de gérer ce type de cas spécifique. Dans l'exemple proposé en regard de la figure 2, il suffit aux développeurs de créer une API de gestion d'une file de messages offrant notamment deux méthodes (put et get) permettant respectivement de déposer et de récupérer un message dans la file.
La méthode put permet d'associer le contexte de l'activité courante au message déposé dans la file. La méthode get permet d'associer le contexte du message retiré à l'activité courante.
La variante de la figure 3 fonctionne de la manière suivante : 1. L'intercepteur détermine le contexte de la requête entrante et l'associe à l'activité courante Ai en utilisant le gestionnaire d'activités ThreadManager.
2. L'objet applicatif utilise la méthode put pour insérer le message dans la file de messages. Le contexte de l'activité courante Ai est associé de manière transparente au message.
<Desc/Clms Page number 9>
3. L'objet applicatif retire un message de la file de messages en utilisant la méthode get. Le contexte du message est associé à l'activité courante A2.
4. L'intercepteur récupère le contexte de l'activité courante A2.
Claims (2)
1-Procédé de propagation de contextes d'invocation à travers un système distribué à objets, ledit système comportant une interface API de gestion d'activités et chaque objet étant associé à un intercepteur et à un authentificateur de contexte de requête entrante reçue par l'intercepteur lors d'une invocation dudit objet, caractérisé en ce que ledit procédé comprend les opérations consistant à : - créer un gestionnaire d'activités destiné à l'intercepteur pour, notamment, d'une part, établir une association entre une activité d'un objet consécutive directement à une requête entrante invoquant ledit objet et le contexte de ladite requête entrante tel qu'identifié par l'authentificateur de contexte, et, d'autre part, récupérer le contexte dudit gestionnaire d'activités et l'associer à la requête sortante de l'objet, - ajouter à ladite interface API de gestion d'activités une méthode destinée à récupérer le contexte courant du gestionnaire d'activités et de l'associer à toute activité de l'objet consécutive indirectement à la requête entrante.
2-Procédé selon la revendication 1, caractérisé en ce qu'il comprend également une opération consistant à créer une interface API de gestion d'une file de messages, offrant deux méthodes permettant respectivement de déposer un message dans la file et d'associer le contexte de l'activité courante au message déposé dans la file, et de récupérer un message dans la file et d'associer le contexte du message retiré à l'activité courante.
Priority Applications (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0013917A FR2816080B1 (fr) | 2000-10-30 | 2000-10-30 | Procede de propagation de contextes d'invocation a travers un systeme distribue a objets |
| EP01983631A EP1330711A1 (fr) | 2000-10-30 | 2001-10-10 | Procede de propagation de contextes d'invocation a travers un systeme distribue a objets |
| PCT/FR2001/003120 WO2002037277A1 (fr) | 2000-10-30 | 2001-10-10 | Procede de propagation de contextes d'invocation a travers un systeme distribue a objets |
| JP2002539961A JP2004513429A (ja) | 2000-10-30 | 2001-10-10 | 分散オブジェクトシステムを通じた呼び出しのコンテキストの伝播方法 |
| US10/427,874 US20030236926A1 (en) | 2000-10-30 | 2003-04-30 | Method of propagating invocation contexts through a distributed object system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0013917A FR2816080B1 (fr) | 2000-10-30 | 2000-10-30 | Procede de propagation de contextes d'invocation a travers un systeme distribue a objets |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2816080A1 true FR2816080A1 (fr) | 2002-05-03 |
| FR2816080B1 FR2816080B1 (fr) | 2003-01-31 |
Family
ID=8855896
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0013917A Expired - Fee Related FR2816080B1 (fr) | 2000-10-30 | 2000-10-30 | Procede de propagation de contextes d'invocation a travers un systeme distribue a objets |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US20030236926A1 (fr) |
| EP (1) | EP1330711A1 (fr) |
| JP (1) | JP2004513429A (fr) |
| FR (1) | FR2816080B1 (fr) |
| WO (1) | WO2002037277A1 (fr) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7653905B1 (en) * | 2004-09-08 | 2010-01-26 | American Express Travel Related Services Company, Inc. | System and method for management of requests |
| US20070033640A1 (en) * | 2005-07-22 | 2007-02-08 | International Business Machines Corporation | Generic context service in a distributed object environment |
| US8135741B2 (en) * | 2005-09-20 | 2012-03-13 | Microsoft Corporation | Modifying service provider context information to facilitate locating interceptor context information |
| US20070120865A1 (en) * | 2005-11-29 | 2007-05-31 | Ng Kam L | Applying rendering context in a multi-threaded environment |
| WO2011013116A1 (fr) * | 2009-07-25 | 2011-02-03 | Irina Kleingon | Procédés pour une production de masse de logiciels |
| US10313358B2 (en) * | 2016-08-02 | 2019-06-04 | Capital One Services, Llc | Systems and methods for proximity identity verification |
| CN113254112A (zh) * | 2021-04-29 | 2021-08-13 | 杭州天谷信息科技有限公司 | 一种请求和接口的关联方法及系统 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1999028819A2 (fr) * | 1997-12-04 | 1999-06-10 | Hewlett-Packard Company | Passerelle dans systeme oriente objets |
| US5920863A (en) * | 1997-05-31 | 1999-07-06 | International Business Machines Corporation | System and method for supporting transactions for a thin client lacking a persistent store in a distributed object-oriented environment |
| JP2000020329A (ja) * | 1998-07-03 | 2000-01-21 | Hitachi Ltd | オブジェクト間コンテキスト伝播方式 |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5680610A (en) * | 1995-01-19 | 1997-10-21 | Unisys Corporation | Method and apparatus for testing recovery scenarios in global transaction processing systems |
| US5687372A (en) * | 1995-06-07 | 1997-11-11 | Tandem Computers, Inc. | Customer information control system and method in a loosely coupled parallel processing environment |
| US6134601A (en) * | 1996-06-17 | 2000-10-17 | Networks Associates, Inc. | Computer resource management system |
| US5893912A (en) * | 1997-08-13 | 1999-04-13 | International Business Machines Corporation | Thread context manager for relational databases, method and computer program product for implementing thread context management for relational databases |
| US6804711B1 (en) * | 1997-10-06 | 2004-10-12 | Mci, Inc. | Method and apparatus for managing call processing services in an intelligent telecommunication network |
| US6363411B1 (en) * | 1998-08-05 | 2002-03-26 | Mci Worldcom, Inc. | Intelligent network |
| US6393481B1 (en) * | 1997-10-06 | 2002-05-21 | Worldcom, Inc. | Method and apparatus for providing real-time call processing services in an intelligent network |
| US6728964B1 (en) * | 1998-06-13 | 2004-04-27 | Intel Corporation | Monitoring function |
| US20010042058A1 (en) * | 1998-07-09 | 2001-11-15 | Robert J. Harrington | Apparatus and method for managing memory use by software objects |
| AU3352500A (en) * | 1999-01-29 | 2000-08-18 | Iona Technologies Inc. | Method and system for dynamic configuration of interceptors in a client-server environment |
| US6742015B1 (en) * | 1999-08-31 | 2004-05-25 | Accenture Llp | Base services patterns in a netcentric environment |
-
2000
- 2000-10-30 FR FR0013917A patent/FR2816080B1/fr not_active Expired - Fee Related
-
2001
- 2001-10-10 EP EP01983631A patent/EP1330711A1/fr not_active Withdrawn
- 2001-10-10 WO PCT/FR2001/003120 patent/WO2002037277A1/fr active Application Filing
- 2001-10-10 JP JP2002539961A patent/JP2004513429A/ja active Pending
-
2003
- 2003-04-30 US US10/427,874 patent/US20030236926A1/en not_active Abandoned
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5920863A (en) * | 1997-05-31 | 1999-07-06 | International Business Machines Corporation | System and method for supporting transactions for a thin client lacking a persistent store in a distributed object-oriented environment |
| WO1999028819A2 (fr) * | 1997-12-04 | 1999-06-10 | Hewlett-Packard Company | Passerelle dans systeme oriente objets |
| JP2000020329A (ja) * | 1998-07-03 | 2000-01-21 | Hitachi Ltd | オブジェクト間コンテキスト伝播方式 |
Non-Patent Citations (3)
| Title |
|---|
| NARASIMHAN P., MOSER L. E., MELLIAR-SMITH P. M.: "USING INTERCEPTORS TO ENHANCE CORBA", COMPUTER, IEEE COMPUTER SOCIETY PRESS, US, vol. 32, no. 7, July 1999 (1999-07-01), pages 62 - 68, XP002171364, ISSN: 0018-9162, Retrieved from the Internet <URL:http://ieeexplore.ieee.org/iel5/2/16817/00774920.pdf> [retrieved on 20010706] * |
| OBJECT MANAGEMENT GROUP, INC.: "THE COMMON OBJECT REQUEST BROKER: ARCHITECTURE AND SPECIFICATION. REVISION 2.3", OMG, June 1999 (1999-06-01), pages 21-1 - -21-9, XP002171365, Retrieved from the Internet <URL:http://cgi.omg.org/cgi-bin/doc?formal/98-12-01.pdf> [retrieved on 20010706] * |
| PATENT ABSTRACTS OF JAPAN vol. 2000, no. 04 31 August 2000 (2000-08-31) * |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2002037277A1 (fr) | 2002-05-10 |
| EP1330711A1 (fr) | 2003-07-30 |
| JP2004513429A (ja) | 2004-04-30 |
| FR2816080B1 (fr) | 2003-01-31 |
| US20030236926A1 (en) | 2003-12-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP2441207B1 (fr) | Procédé cryptographique d'authentification anonyme et d'identification séparée d'un utilisateur | |
| EP2936782B1 (fr) | Procédé de traitement de requêtes d'accès et navigateur web | |
| EP2901279B1 (fr) | Dispositif et procede de gestion de l'acces a un ensemble de ressources informatiques et reseaux dans un systeme informatique en nuage | |
| EP3812997B1 (fr) | Procédé et appareil de traitement de données se basant sur chaîne de blocs, et serveur | |
| FR2950214A1 (fr) | Procede de demande de verification de donnees profil utilisateur d’un site de reseau social. | |
| EP2318976A1 (fr) | Procede et systeme permettant de securiser un logiciel | |
| FR2964812A1 (fr) | Procede d'authentification pour l'acces a un site web | |
| EP3087706B1 (fr) | Procédé et système de communication entre navigateurs web, utilisant un environnement de communication unifiée | |
| EP3446436B1 (fr) | Procédé d'obtention par un terminal mobile d'un jeton de sécurité | |
| FR2816080A1 (fr) | Procede de propagation de contextes d'invocation a travers un systeme distribue a objets | |
| FR3022661A1 (fr) | Procede et dispositif de codage de fichiers sources pour la livraison securisee de code source | |
| FR3102589A1 (fr) | Système ouvert et sécurisé de traitement de demande de signature électronique et procédé associe | |
| EP3803745B1 (fr) | Système transactionnel sécurisé dans une architecture p2p | |
| EP1506480A2 (fr) | Procede de controle d'acces a des ressources cryptographiques | |
| Aune et al. | Footprints on the blockchain: Information leakage in distributed ledgers | |
| CA2988357A1 (fr) | Procede de chiffrement, procede de chiffrement, dispositifs et programmes correspondants | |
| EP4156647A1 (fr) | Messagerie éphémère dans une plateforme décentralisée de messagerie chiffrée de bout en bout | |
| EP1506479A2 (fr) | Procede pour accomplir des fonctions cryptographiques dans une application informatique | |
| EP2863321A1 (fr) | Procédé et système de génération automatique de documents à partir d'un index | |
| EP3896634A1 (fr) | Procede de traitement d'une transaction effectuee par une entite debitrice aupres d'une entite creditrice cible | |
| WO2024133604A1 (fr) | Procédé de sécurisation de la saisie des chiffres d'un code personnel didentification, et dispositif correspondant. | |
| FR3041450A1 (fr) | Architecture client/serveur pour l'administration d'un supercalculateur | |
| FR3107128A1 (fr) | Procédé et dispositif d'évaluation de correspondance d'ensembles de données structurées protégées par le chiffrement | |
| WO2024121075A1 (fr) | Procédé de génération d'une application de traitement d'au moins un flux multimédia, dispositif et programme d'ordinateur associés | |
| EP3948596A1 (fr) | Procédé d'exécution de code sécurisé, dispositifs, système et programmes correspondants |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| ST | Notification of lapse |
Effective date: 20090630 |