FR2752468A1 - Systeme integre de communication de donnees et d'acces aux donnees incluant l'interface de donnees d'application - Google Patents

Systeme integre de communication de donnees et d'acces aux donnees incluant l'interface de donnees d'application Download PDF

Info

Publication number
FR2752468A1
FR2752468A1 FR9710395A FR9710395A FR2752468A1 FR 2752468 A1 FR2752468 A1 FR 2752468A1 FR 9710395 A FR9710395 A FR 9710395A FR 9710395 A FR9710395 A FR 9710395A FR 2752468 A1 FR2752468 A1 FR 2752468A1
Authority
FR
France
Prior art keywords
application
data
event
client application
server
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
Application number
FR9710395A
Other languages
English (en)
Other versions
FR2752468B1 (fr
Inventor
Pradeep Jain
Ahmed Shamim
Serge J Dacic
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Services Petroliers Schlumberger SA
Original Assignee
Services Petroliers Schlumberger SA
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Priority claimed from US08/758,833 external-priority patent/US6647432B1/en
Application filed by Services Petroliers Schlumberger SA filed Critical Services Petroliers Schlumberger SA
Publication of FR2752468A1 publication Critical patent/FR2752468A1/fr
Application granted granted Critical
Publication of FR2752468B1 publication Critical patent/FR2752468B1/fr
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/03—Arrangements for converting the position or the displacement of a member into a coded form
    • G06F3/041—Digitisers, e.g. for touch screens or touch pads, characterised by the transducing means
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/02—Input arrangements using manually operated switches, e.g. using keyboards or dials
    • G06F3/0202—Constructional details or processes of manufacture of the input device
    • G06F3/021—Arrangements integrating additional peripherals in a keyboard, e.g. card or barcode reader, optical scanner
    • G06F3/0213—Arrangements providing an integrated pointing device in a keyboard, e.g. trackball, mini-joystick
    • 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/54—Interprogram communication
    • G06F9/542—Event management; Broadcasting; Multicasting; Notifications
    • 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/54—Interprogram communication
    • G06F9/543—User-generated data transfer, e.g. clipboards, dynamic data exchange [DDE], object linking and embedding [OLE]

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Human Computer Interaction (AREA)
  • Multimedia (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention concerne un système intégré de communication de données et d'accès aux données comportant une première antémémoire (119) connectée à une première application (24c1) et des premiers moyens de conversion connectés à l'antémémoire (119) et assurant l'interface entre un premier opérateur de la première application et l'antémémoire (119) pour recevoir des données originales et les convertir en données, la première application (24c1) mémorisant les données dans l'antémémoire (119) et une base de données (110) lorsqu'elle établit un état d'enregistrement persistant ou transitoire, une seconde application (26c1) vérifiant l'existence de données dans la base de données (110) indépendamment de la première application (24c1) et exprimant un intérêt dans ces données via un serveur (26c2) recevant de la première application toutes les versions modifiées des données et les mémorisant dans l'antémémoire (121) et la base de données (110) si l'application (26c1) établit l'état d'enregistrement persistant.

Description

SYSTèME INTEGRE DE COMMUNICATION DE DONNEES ET
D'ACCUS AUX DONNEES INCLUANT L'INTERFACE DE
DONNEES D 'APPLICATION
Domaine de l'invention
La présente invention concerne un système de communication de données et d'accès aux données intégré, et, plus particulièrement, un système de communication de données adapté pour pratiquer un événement dans une première application, créer un objet de données à l'aide de la première application pendant la pratique de l'événement, et le communiquer entre la première application et une antémémoire et une base de données suivant la pratique de l'événement en mémorisant de manière indépendante l'objet de données dans l'antémémoire et dans la base de données pendant un état d'enregistrement persistant ou transitoire ; et un système d'accès aux données adapté pour accéder de manière indépendante, à la base de données par une seconde application afin de récupérer l'objet de données, déterminer un intérêt porté par la seconde application aux versions créées ultérieurement de ltobjet de données, exprimer l'intérêt porté par la seconde application aux objets de données en transmettant un objet d'intérêt à partir de la seconde application vers la première application via une application serveur, et transmettre les versions créées ultérieurement de l'objet de données directement à partir de la première application vers la seconde application.
Les programmes informatiques qui fonctionnent avec un réseau comportent souvent de multiples programmes fonctionnant simultanément. I1 est fréquemment nécessaire que des informations, telles que des événements, soient transférées d'un premier programme vers un autre, soit au sein d'un même poste de travail, soit à travers un réseau de postes de travail informatiques interconnectés. Un opérateur au niveau d'un des postes de travail peut traiter des informations en utilisant différents programmes fonctionnant simultanément dans le poste de travail ou sur le réseau de postes de travail. L'opérateur peut aussi récupérer des informations en utilisant de multiples programmes informatiques s exécutant simultanément dans le même poste de travail ou sur le réseau de postes de travail interconnectés. I1 est par conséquent important que les informations soient transférées rapidement et facilement entre les multiples programmes fonctionnant sur un seul poste de travail ou sur plusieurs postes de travail interconnectés.
La technologie du logiciel multifenètre est appliquée dans le cas où il est important pour un opérateur d'afficher et d'interagir avec de multiples programmes s'exécutant simultanément dans un système informatique comprenant un ou plusieurs postes de travail postes de travail interconnectés. Une "fenêtre" est définie comme étant une partie d'un écran d'affichage, tel qu'un tube à rayons cathodiques (CRT). La fenêtre recouvre moins de la totalité de l'écran. En résultat, il peut y avoir de multiples fenêtres sur l'écran à un instant donné. D'une manière typique, l'utilisateur déplace un curseur sur l'écran en utilisant un dispositif d'entrée connu sous le nom de souris ou en utilisant de multiples touches sur un clavier. Le curseur peut être déplacé d'une première fe nêtre vers une autre sur l'écran, et, lorsque le curseur est présent à l'intérieur d'une fenêtre particulière sur l'écran, l'utilisateur/opérateur est placé en communication avec le programme d'application qui produit cette fenêtre particulière sur l'écran. En résultat, l'opérateur peut accéder à de multiples programmes d'application différents, accomplissant par conséquent des tâches mul tiples sans avoir à charger un nouveau programme à chaque fois qu'une nouvelle tâche doit être effectuée.
Cependant, lors d'un accès simultané à de multiples programmes d'application différents s'exécutant sur un poste de travail ou sur un réseau de postes de travail, il est souvent nécessaire pour un utilisateur/opérateur de transférer des informations d'un premier programme à fenêtes s' exécutant dans un premier poste de travail vers un autre programme à fenêtres s'exécutant soit dans le premier poste de travail, soit dans un second poste de travail différent connecté au premier poste de travail via le réseau. Le transfert d'informations entre programmes fonctionnant dans un en vironnement multifenetre est décrit dans la présente description ; cependant, un tel environnement multifenêtre n'est pas nécessaire à l'implémentation de l'invention décrite dans la présente description, telle que revendiquée.
I1 existe au moins trois techniques habituelles pour transférer des informations entre programmes fonctionnant simultanément dans un système informatique.
La première technique habituelle est appelée "couper et coller". Celle-ci consiste à pointer sur et à sélectionner des informations, telles que du texte ou des données, dans une fenêtre pour les mettre en surbrillance et, ainsi, les séparer des autres informations dans la fenêtre. L'utilisateur appuie sur un bouton ou une touche spéciale qui déplace les informations sélectionnées vers une zone de mémoire spécialement désignée par le système d'exploitation et connue sous le nom de "mémoire de collage" ou "presse-papiers". L'utilisateur déplace alors le curseur vers une autre fenêtre qui est adaptée pour recevoir les informations. Un "bouton coller" ou commande est sollicité par l'utilisateur pour récupérer les informations mémorisées à partir de la zone de mémoire désignée et pour les placer au niveau de l'emplacement indiqué par le curseur. Il est à noter que toutes les étapes de ce procédé sont exécutées par l'utilisateur.
La deuxième technique habituelle établit .une connexion programmée entre deux programmes, lesquels peuvent afficher chacun des informations dans une fenêtre.
Les deux programmes doivent etre conçus pour répondre à une commande d'entrée prédéterminée qui amène le déplacement d'informations d'un programme vers un autre. Cette opération peut aussi s'effectuer entièrement sous la commande de l'utilisateur et requiert une entrée utilisateur pour fonctionner. Chaque chemin de communication entre paires de programmes doit être programmé dans le code des deux programmes, ce qui crée un système rigide. Il est aussi difficile d'ajouter de nouveaux chemins de communication ou de modifier des chemins de communication existants.
La troisième technique habituelle est décrite dans le brevet U.S. 5 448 738 au nom de Good et autres, délivré le 5 Septembre 1995, et dans la demande de brevet européen 0 380 211 publiée le 1 Août 1990 et intitulée "Method for Information Communication between Concurrently Operating Computer Programs" au nom de William E.
Good et autres (appelé par la suite "exposé de Good"), dont les descriptions sont incorporées, par référence, dans la description de la présente demande. Dans l'exposé de Good, l'utilisateur se connecte avec des programmes d'application via un ou plusieurs affichages à fenêtres et un dispositif d'entrée sur un poste de travail informatique. Un ou plusieurs codes d'informations et un ou plusieurs programmes d'application correspondants sont enregistrés avec un programme régulateur (connu en tant que "serveur"). En résultat, une liste est formée dans le programme régulateur, la liste incluant une pluralité de codes d'informations et une pluralité correspondante d'identificateurs de programme d'application. Ensuite, lorsqu ' un premier programme d'application veut envoyer des informations d'événements vers un second programme d'application différent s'exécutant simultanément. , un modèle, qui inclut des informations d'événements et un code d'informations correspondant, est créé par le premier programme d'application et le modèle est transmis par le premier programme d'application au programme régulateur. Le code d'informations contenu dans le modèle provenant du premier programme d'application est comparé au code d'informations contenu dans la liste enregistrée avec le programme régulateur. Si une coïncidence entre codes d'informations est déterminée, les informations d'événements associées au code d'informations du modèle sont communiquées au programme d'application qui est associé au code d'informations contenu dans la liste enregistrée avec le programme régulateur.
L'exposé de Good est similaire à celui d'autres outils de la technique antérieure habituels pour permettre une communication inter-traitement entre programmes d'application, lesquels sont tous basés sur des "techniques client-serveur". Des exemples de tels outils habituels incluent le "X Window System" et le "Tooltalk" de Sun. Dans l'exposé de Good, ainsi que dans les autres outils habituels, lorsque les techniques client-serveur de la technique antérieure sont utilisés, la totalité des données à communiquer entre les applications des programmes informatiques s ' exécutant simultanément doivent être acheminées via un programme serveur (le "programme serveur" étant similaire au "programme régulateur" dans l'exposé de Good). Si de nombreuses applications s'exécute tant simultanément existent dans le réseau, le serveur ou le régulateur peut avoir à transmettre un trop grand nombre de messages d'événements à un instant donné quelconque. Ceci aboutit à un débit plus lent, ainsi qu'à un trafic accru sur le réseau. De plus, lorsque la technique client-serveur de la technique antérieure est utilisée, l'utilisateur/opérateur exécutant un premier programme d'application ne peut envoyer que certains messages d'informations d'événements présélectionnés vers un second programme d'application. C'est-à-dire que l'utilisateur ne peut envoyer qu'un ensemble fixé de messages d'informations d'événements prédéfinis qui sont admis par le réseau du système ; il ne peut définir ni personnaliser ses propres messages d'informations d'événements pour les transmettre au second programme d'application. Par exemple, si une taille de police de caractères a été modifiée dans une première application, en utilisant la technique client-serveur habituelle (dans laquelle tous les messages d'événements doivent être acheminés via le serveur), il n'existe aucune manière de communiquer la taille de police modifiée, modifiée dans une première application, à une autre application du réseau du fait que la "taille de police modifiée" ne fait pas partie de l'ensemble fixé de messages d'informations d'événements prédéfinis admis à être transmis d'une première application vers une autre application sur le réseau. De plus, lorsque la technique client-serveur habituelle est utilisée, des données d'informations d'événements particulières doivent toujours être communiquées à partir d'une première application de programme informatique vers un programme serveur et à partir du programme serveur vers une seconde application de programme. Par ailleurs, ce programme serveur peut ne pas savoir si d'autres applications de programmes sont intéressées par la réception de ces données d'événements particulières. En résultat, lorsque le serveur reçoit les données d'informations d'événements particulières en provenance du premier programme d'application, le serveur doit alors déterminer. Si d'autres applications sont intéressées par la réception de ces données d'événements par ticulières. Si aucune autre application n'est intéressée par la réception des données d'événements particulières, le programme serveur a gaspillé ses ressources à manipuler les données d'événements. particulières du fait que celles-ci ne seront jamais communiquées à aucune autre application.
En outre, les données communiquées pendant l'utilisation des outils habituels sont faiblement structurées (forment des "globes") et ne fournissent aucun mécanisme pour contrôler les erreurs dans les données communiquées. C'est la responsabilité des programmes d'application d'interpréter les données d'une manière correcte et de manipuler les conditions d'erreur. Par conséquent, lorsque les outils habituels sont utilisés, la capacité du programmeur d'applications à intercommuniquer des structures de données complexes entre des applications de programmes informatiques s' exécutant simultanément est très limitée.
Comme noté précédemment les outils habituels ne fournissent aucun mécanisme susceptible de permettre aux programmeurs d'applications d'étendre d'une manière sélective ou de personnaliser le type d'événements et/ou de données susceptibles de pouvoir être intercommuniquées entre applications s' exécutant simultanément, en cours d'exécution dans un ou plusieurs postes de travail informatiques. En résultat, l'absence a'un niveau suffisamment élevé d'abstraction en termes de programmation dans ces outils habituels amène les programmeurs d'applications à faire appel à des solutions de bas niveaux, tels que des formats de données sur diverses plates-formes et rendez-vous de communication (tels qu'un nom de propriété connu d'une fenêtre connue, comme dans le "X Window System" de la technique antérieure).
Enfin, ces outils habituels ne permettent pas aux utilisateurs finaux d'applications de commander faci lement le flux de données ni de visualiser la façon dont sont connectées les applications entre elles.
De plus, les outils habituels ont une interface différente de celle de l'invention de la demande en connexion avec les procédés utilisés pour traiter les événements et la mémorisation persistante. Lorsque des données étaient écrites dans une première application en cours d'exécution, il était demandé à l'auteur de ces données de suivre un certain nombre d'étapes spécifiques, pendant l'introduction de ces données, en vue de la communication de ces données à une seconde application différente.
Lorsque les données étaient introduites dans la première application, ces données étaient toujours communiquées à la seconde application via l'application régulatrice et, lorsque la seconde application réceptrice recevait ces données à partir de l'application régulatrice, la seconde application réceptrice ne possédait pas une "granularité" fine par rapport au type de données reçues.
C'est-à-dire que la seconde application réceptrice pouvait, par exemple, recevoir des "données de forage" ; cependant, la seconde application réceptrice ne pouvait recevoir ni sous-ensemble spécifique ni type de ces données de fortage.
Par conséquent, une "nouvelle structure" était nécessaire pour permettre une communication rapide et un partage de données complexes, pour fournir un puissant langage d'écriture des structures de données, et garantir un certain degré d'extensibilité lors de l'utilisation de types de données et d'événements définis par une application. De plus, cette "nouvelle structure" doit aussi permettre aux utilisateurs finaux d'applications tournant sur des postes de travail de visualiser le réseau de connectivités entre les applications tournant sur les postes de travail en permettant aux utilisateurs finaux travaillant au niveau de ces postes de travail de commander la communication de données inter-traitement entre programmes d'application informatiques s'exécutant simultanément dans des environnements à un ou plusieurs postes de travail informatiques.
La "nouvelle structure" référencée ci-dessus est décrite dans une demande antérieure en cours de procédure déposée le 12/04/96 sous le numéro 08/758 833 et intitulée "Distributed Framework for Intertask Communication Between Workstation Applications", Shamin Ahmed et
Serge J. Dacic (appelée par la suite "Application ITC"), dont la description est incorporée, par référence, dans la présente description.
Bien que non-décrite dans l"'Application ITC", la "nouvelle structure" utilise un dispositif sous-jacent appelé "Interface de Données d'Application" décrit dans la description. Lorsque cette "Interface de Données d'Application" est implémentée dans le Système de Communication de Données et d'Accès aux Données Intégré de la présente invention, une première application de ce Système est admise à rechercher d'une manière indépendante l'existence de certaines données nouvellement créées dans une base de données, indépendamment d'une deuxième ou d'une troisième application s'exécutant simultanément dans ce Système, dans le but ultime d'exprimer éventuellement un intérêt à l'égard des versions créées et mises à jour ultérieurement de ces données et de les recevoir, lesquelles peuvent être générées par la deuxième ou la troisième application de ce Système.
Cependant, les systèmes habituels ne permettent pas à une première application dans le système de rechercher l'existence de certaines données mémorisées indépendamment des autres applications s'exécutant simultanément dans le système. Par exemple, si un système habituel inclut des première et seconde applications s'exécutant simultanément, si la première application est intéressée par la recherche de l'existence de certaines données, celle-ci doit le faire en interrogeant la seconde application. La première application ne peut rechercher l'existence de ces données indépendamment de la seconde application.
En conséquence, il existe un besoin pour un système de communication de données et d'accès aux données intégré, comportant au moins un premier et un deuxième programmes d'application s'exécutant simultanément , qui permette à la seconde application de mémoriser certaines données dans une antémémoire et une base de données lorsqu'elle est établie dans un état d'enregistrement persistant ou transitoire, permettant par conséquent à la première application de rechercher d'une manière indépendante l'existence de telles données, indépendamment de la seconde application, en interrogeant la base de données quant à la présence de telles données dans le but ultime d'exprimer un intérêt à l'égard d'une version ultérieurement modifiée quelconque de telles données et de la recevoir.
Exposé de l'invention
En conséquence, un but essentiel de la présente invention consiste à fournir un système de communication de données et d'accès aux données intégré qui inclue au moins une première application et une seconde application s'exécutant simultanément dans ledit système et qui soit adapté pour permettre à la seconde application de mémoriser certaines données dans une seconde antémémoire et une base de données lorsque la seconde application établit un état d'enregistrement persistant ou transitoire, permettant par conséquent à la première application de rechercher d'une manière indépendante l'existence de telles données, indépendamment de la seconde application, en in terrogeant la base de données quant à l'existence de telles données dans le but ultime d'exprimer un intérêt à l'égard d'une version ultérieurement modifiée quelconque de telles données et de la recevoir.
Un autre but de la présente invention consiste à fournir le système de communication de données et d'accès aux données intégré tel que mentionné ci-dessus qui soit de plus adapté pour permettre à la seconde application de mémoriser certaines données dans la seconde antémémoire, mais non dans la base de données lorsque la seconde application établit un état d'enregistrement mémoire.
Un autre but de la présente invention consiste à fournir le système de communication de données et d'accès aux données intégré tel que mentionné ci-dessus qui comporte en outre une première antémémoire connectée fonctionnellement à la première application et des premiers moyens de conversion connectés fonctionnellement à la première antémémoire et assurant l'interfaçage entre un premier opérateur de la première application et la première antémémoire pour recevoir des données ayant un premier format à partir du premier opérateur et convertir les données ayant le premier format en données ayant un deuxième format, la première application mémorisant les données ayant le deuxième format dans la première antémémoire et dans la base de données lorsque la première application établit l'état d'enregistrement persistant ou transitoire, la seconde application recherchant d'une manière indépendante l'existence de telles données ayant le deuxième format, indépendamment de la première application, en interrogeant la base de données quant à l'exis- tence de telles données ayant le deuxième format, en exprimant un intérêt à l'égard de telles données ayant le deuxième format, en recevant toutes les versions ultérieurement modifiées de telles données ayant le premier format, et en mémorisant les versions ultérieurement modifiées de telles données ayant le deuxième format dans la seconde antémémoire.
Un but supplémentaire de la présente invention consiste à fournir le système de communication de données et d'accès aux données intégré tel que mentionné cidessus qui comporte en outre des seconds moyens de conversion connectés fonctionnellement à la seconde antémémoire et assurant l'interfaçage entre un second opérateur de la seconde application et la seconde antémémoire pour recevoir des données ayant le deuxième format à partir de la seconde antémémoire et convertir de telles données ayant le deuxième format en données ayant un troisième format, les données ayant le troisième format étant présentées au second opérateur de ladite seconde application.
Conformément à ces buts de la présente invention, ainsi qu'à d'autres, un système de communication de données et d'accès aux données intégré conformément à la présente invention comporte : une première application, une première antémémoire connectée fonctionnellement à la première application, et une première unité de conversion connectée fonctionnellement à la première antémémoire et assurant l'interfaçage entre un premier opérateur de la première application et la première antémémoire ; une seconde application, une seconde antémémoire connectée fonctionnellement à la seconde application, et une seconde unité de conversion connectée fonctionnellement à la seconde antémémoire et assurant l'interfaçage entre un second opérateur de la seconde application et la seconde antémémoire ; une base de données connectée fonctionnellement à la première antémémoire et à la seconde antémémoire ; et un serveur connecté fonctionnellement à la première application et à la seconde application.
En fonctionnement, le premier opérateur pratique un "événement" et la pratique de cet "événement" introduit des données ayant un premier format dans la première unité de conversion. La première unité de conversion convertit les données ayant le premier format en d'autres données ayant un deuxième format. La première application reçoit les données ayant le deuxième format et mémorise les données ayant le deuxième format dans la première antémémoire et dans la base de données lorsque la première ou la deuxième application établit un état d'enregistrement persistant ou transitoire. D'autre part, la première application mémorise les données ayant le deuxième format dans la première antémémoire, mais ne mémorise pas de telles données dans la base de données lorsqu'un état d'enregistrement mémoire est établi. La seconde application interroge la base de données quant à la présence de données ayant le deuxième format et la seconde unité de conversion convertit les données ayant le deuxième format en d'autres données ayant un troisième format, les données ayant le troisième format étant présentées au second opérateur de la seconde application. Le second opérateur introduit un objet d'intérêt dans ladite unité de conversion, exprimant par conséquent un intérêt dans les "versions ultérieurement modifiées des données" créées par la première application, mais l'objet d'intérêt ne subit aucune conversion dans l'unité de conversion. La seconde. application transmet l'objet d'intéret au serveur et le serveur retransmet l'objet d'intérêt à la première application. La première unité de conversion reçoit l'objet d'intérêt, mais l'objet d'intérêt ne subit aucune conversion dans la première unité de conversion, et l'objet d'intéret est présenté au premier opérateur de la première application. Le premier opérateur repratique le même "événement" et la repratique de ce même "événement" introduit les "versions ultérieurement modi fiées des données" ayant le premier format dans la première unité de conversion. L'unité de conversion convertit la "version ultérieurement modifiée des données ayant le premier format" en une "version ultérieurement modifiée des données ayant le deuxième format", et les données ultérieurement modifiées ayant le deuxième format sont mémorisées dans la première antémémoire. Si la première application établit l'état d'enregistrement persistant, la "version ultérieurement modifiée des données ayant le deuxième format" est aussi mémorisée dans la base de données. Cependant, si la première application établit l'état d'enregistrement transitoire ou l'état d'enregistrement mémoire, la "version ultérieurement modifiée des données ayant le deuxième format" n'est pas mémorisée dans la base de données.
Les règles relatives aux états d'enregistrement sont les suivantes : un ensemble de données originales est mémorisé dans l'antémémoire et la base de données pendant l'état d'enregistrement persistant ou transitoire, mais les données modifiées ultérieurement, produites après la production de l'ensemble de données originales, ne sont pas mémorisées dans la base de données pendant l'état d'enregistrement transitoire. De plus, les données originales et les données modifiées ne sont pas mémorisées dans la base de données pendant un état d'enregistrement mémoire.
Lorsque la "version ultérieurement modifiée des données ayant le deuxième format" est mémorisée dans la première antémémoire associée à la première application, ces données sont communiquées directement à partir de la première application vers la seconde application sans enregistrer ces données avec le serveur. Lorsque la seconde application reçoit ces données, la "version ultérieurement modifiée des données ayant le deuxième format" est mémorisée dans la seconde antémémoire, et de telles don nées ayant le deuxième format sont alors introduites dans la seconde unité de conversion. La seconde unité de conversion convertit la "version ultérieurement modifiée des données ayant le deuxième format" en une "version ultérieurement modifiée des données ayant un troisième format". En résultat, la "version ultérieurement modifiée des données ayant le troisième format" est présentée au second opérateur de la seconde application pour qu'il puisse en tenir compte.
D'autres applications possibles de la présente invention apparaîtront clairement à la lecture de la description détaillée faite ci-après. Il doit être compris, cependant, que la description détaillée et les exemples spécifiques, bien que représentant un mode préféré de réalisation de la présente invention, ne sont donnés qu 'à titre d'illustration, du fait que divers changements et diverses modifications conformes à l'esprit et situés dans la portée de la présente invention apparaîtront évidents à l'homme du métier à la lecture de la description détaillée qui va suivre.
Brève description des dessins
Une parfaite compréhension de la présente invention découlera de la lecture de la description détaillée du mode préféré de réalisation présenté cidessous, et des dessins annexés, qui ne sont donnés qu'à titre d'illustration et ne sont nullement destinés à limiter la présente invention, et sur lesquels les figures 1 à 32 sont présentées en connexion avec la première partie de la présente description intitulée "Structure Distribuée pour Communications Inter-tâches entre Applications sur Poste de Travail
- la figure 1 illustre un poste de travail informatique comportant un affichage qui inclut un ou plu sieurs affichages à fenêtres représentant l'exécution d'un ou de plusieurs programmes d'application client ;
- la figure 2 illustre une pluralité de programmes d'application client qui affichent une pluralité correspondante d'affichages à fenêtres sur un ou plusieurs postes de travail similaires à celui représenté sur la figure 1, chacune de la pluralité d'applications client étant interconnectée aux autres par un dispositif de communication inter-tâche (ITC) qui comporte un programme d'application serveur et une ou plusieurs applications client individuelles,
- la figure 3 illustre un premier poste de travail exécutant une première application client et un second poste de travail exécutant une seconde application client et mémorisant aussi le logiciel d'application serveur ;
- la figure 4 illustre une construction plus détaillée de la première application client (logiciel client 1) et la seconde application client (logiciel client 2) dans les premier et second postes de travail de la figure 3
- la figure 5 illustre une construction plus détaillée du Code d'Interface Homme-Machine ITC de la figure 4
- les figures 6 à 13b illustrent une construction détaillée, ainsi que le fonctionnement, de la structure ITC (Noyau ITC) de la figure 4
- les figures 14 à 25 illustrent une construction détaillée du Logiciel d'Affichage avec Interaction de l'opérateur de la figure 5
- la figure 14 illustre les icônes d'état et l'icône de diffusion;
- les figures 15a à 15e illustrent l'icône de filtre d'événements avec son affichage en sous-fenêtre et
- les figures 16 à 25 illustrent l'utilisation de ces icônes sur un affichage à fenêtres affiché sur un écran d'affichage d'un poste de travail ;
- les figures 26 et 27 illustrent une construction détaillée du logiciel de Lancement IHITC de la figure 5
- la figure 26A illustre une construction détaillée de la "Liste construite d'Evénements ITC" 80 qui est illustrée sur la figure 26 ;
- les figures 28 et 29 illustrent une construction détaillée du Logiciel "Envoyer Un Evénement" de la figure 5
- les figures 30 et 31 illustrent une construction détaillée du Logiciel "Recevoir Un Evénement" de la figure 5
- la figure 32 illustre un Modèle de Sessions de Communications Inter-tâches (ITC) référencé dans la partie structure ITC de la "Description Détaillée du Mode
Préféré de Réalisation" ;
- les figures 33 à 35 illustrent à nouveau les dessins des figures 6, 8A et 9A ; et
- les figures 36 à 44 sont présentées à titre de référence en relation avec une description des concepts associés au "Système de Communication de Données et d'Accès aux Données Intégré" de la présente invention.
Description du mode de réalisation préféré
La présente description est divisée en deux parties
(1) une première partie (Partie 1) intitulée "Structure Distribuée pour Communications Inter-tâches entre Applications sur Poste de Travail". L'invention de cette première partie décrit comment des communications inter-tâches directes (ITC) sont réalisées entre program mes d'application informatiques fonctionnant simultanément , s' exécutant dans un ou plusieurs postes de travail informatiques, qui fournissent un affichage à fenêtres à un opérateur, et
(2) une seconde partie (Partie 2) conformément à la présente invention intitulée "Système de Communication de Données et d'Accès aux Données Intégré incluant l'Interface de Données d'Application".
Partie 1 : Structure distribuée pour communications inter-tâches entre applications sur poste de travail
En se reportant à la figure 1, un poste de travail informatique est illustré, lequel comporte un affichage qui inclut un ou plusieurs affichages à fenêtres représentant l'exécution d'un ou de plusieurs programmes d'application client.
Sur la figure 1, un poste de travail informatique 10 est illustré. Le poste de travail comporte un moniteur 12, un processeur 14, un clavier 16 et une souris 18. Le moniteur 12 comporte un tube à rayons cathodiques (CRT) qui fournit un écran d'affichage 12a. Sur la figure 1, l'écran d'affichage 12a comporte une pluralité de fenêtres 12b affichées sur celui-ci, chaque fenêtre 12b étant affichée sur l'écran d'affichage 12a en réponse à l'exécution, au sein du poste de travail 10, d'un programme d'application client séparé. Comme noté ci-après sur la figure 2, chacune de la pluralité de fenêtres 12b fournit un affichage qui est différent de données relatives à un puits de forage à partir desquelles un opérateur peut interpréter si oui ou non des dépôts souterrains d'hydrocarbures sont présents à l'intérieur d'une formation terrestre. Un opérateur assis au niveau du poste de travail 10 utilise la souris 18 pour sélectionner diverses fenêtres parmi les fenêtres 12b afin de visualiser et/ou manipuler ou sélectionner les données contenues dans cette fenêtre.
En se reportant à la figure 2, une pluralité de programmes d'application client (appelés par las suite "applications client") sont illustrés, lesquels affichent une pluralité correspondante d'affichages à fenêtres sur l'un parmi une pluralité de postes de travail similaires au poste de travail 10 représenté sur la figure 1 et qui sont interconnectés par l'intermédiaire d'un dispositif de communication inter-tâche (ITC).
Sur la figure 2, une pluralité d'applications client 20 sont interconnectées ensemble via un dispositif de communication inter-tâche (ITC) 22. On rappelle qu'une "application client" est un programme informatique qui s'exécute dans le poste de travail 10 de la figure 1 et qui est responsable de l'affichage de l'une des fenêtres 12b sur l'écran d'affichage 12a du moniteur 12 du poste de travail 10 de la figure 1. Le dispositif ITC 22 de la figure 2 permet à chacune des applications client 20 de communiquer directement avec les autres. D'une manière générale, comme représenté sur la figure 6, le dispositif
ITC 22 est un terme générique qui inclut une première application client et une seconde application client qui sont mutuellement interconnectées, comme représenté sur la figure 6. Le dispositif ITC 22 de la figure 2 permet à toutes les applications client 20 de communiquer directement et simultanément les unes avec les autres. En résultat, des événements pratiqués dans une première application client 20 peuvent être visualisés simultanément dans une autre application client 20. Cette capacité fonctionnelle sera décrite d'une manière plus détaillée ultérieurement dans la description.
En se reportant à la figure 3, un système comportant une paire de postes de travail interconnectés (tous deux similaires au poste de travail 10 de la figure 1) est représenté.
Sur la figure 3, un premier poste de travail 24 est interconnecté à un second poste de travail. 26. Le premier poste de travail 24 comporte un processeur 24a connecté à un bus système 24d, un affichage 24b (similaire à l'écran d'affichage 12a de la figure 1) connecté au bus système 24d, une mémoire 24c connectée au bus système 24d, et une interface utilisateur 24e (la souris 18 et le clavier 16 de la figure 1) connectée au bus système 24d. Le second poste de travail 26 comporte un processeur 26a connecté à un bus système 26d, un affichage 26b (similaire à l'écran d'affichage 12a de la figure 1) connecté au bus système 26d, une mémoire 26c connectée au bus système 26d, et une interface utilisateur 26e (la souris 18 et le clavier 16 de la figure 1) connectée au bus système 26d. Le premier poste de travail 24 est connecté électriquement ou optiquement au second poste de travail 26, via une liaison de communication 28.
La mémoire 24c du premier poste de travail 24 mémorise un premier programme d'application client appelé "logiciel d'application client 1" 24cl, et la mémoire 26c du second poste de travail 26 mémorise un second programme d'application client appelé "logiciel d'application client 2" 26cl. Cependant, la mémoire 26c du second poste de travail 26 mémorise aussi un logiciel serveur 26c2. Le logiciel serveur 26c2 distribue des objets d'intérêt entre applications client. On se reportera au "programme régulateur" qui est décrit dans le brevet U.S. 5 448 738 intitulé "Method for Information Communication between Concurrently Operating Computer Programs". Le logiciel d'application client 1 24cl, lorsqu'exécuté par le processeur 24a, produit une image visuelle sur l'affichage 24b qui est similaire à celle des applications client 20 représentées sur la figure 2. D'une manière similaire, le lo giciel d'application client 2 26cl, lorsqu'exécuté par le processeur 26a, crée une image visuelle sur l'affichage 26b qui est similaire à celles des autres applications client 20 représentées sur la figure 2. La fonction du système représenté sur la figure 3 apparaîtra clairement à la lecture des parties qui vont suivre de la présente description.
En se reportant à la figure 4, une construction plus détaillée du logiciel d'application client 1 24cl et du logiciel d'application client 2 26cl de la figure 3 est illustrée.
Sur la figure 4, le logiciel d'application client 1 24cl et le logiciel d'application client 2 26cl comportent chacun : (1) un premier ensemble de logiciels, appelé par la suite "Code d'Interface Homme-Machine ITC" 32, et (2) un second ensemble de logiciels appelé par la suite "Code de Structure ITC (Noyau ITC)" 34. D'un point de vue fonctionnel, un code d'application interne invoque le Code d'Interface Homme-Machine 32, et le Code d'Interface Homme-Machine 32 invoque le Code de Structure 34. Le
Code d'Interface Homme-Machine 32 et le Code de Structure
ITC 34 seront décrits plus en détails dans la description et les fonctions du Code d'Interface Homme-Machine 32 et du Code de Structure 34 apparaîtront clairement à la lecture des parties qui vont suivre de cette description.
En se reportant à la figure 5, une construction plus détaillée du Code d'Interface Homme-Machine ITC 32 de la figure 4 est illustrée.
Sur la figure 5, le Code d'Interface Homme
Machine 32 de la figure 4 est constitué de quatre parties : (1) un logiciel d'Affichage avec Interaction de l'opérateur 32d, (2) un logiciel de Lancement
IH(Interface Homme-Machine)-ITC 32a connecté fonctionnellement au logiciel d'Affichage avec Interaction de l'opé- rateur 32d, (3) un logiciel "Envoyer Un Evénemen." 32b connecté fonctionnellement au logiciel de Lancement
IH-ITC 32a, et (4) un logiciel "Recevoir Un Evénement" 32c connecté fonctionnellement au logiciel de Lancement
IH-ITC 32a. Le Code de Structure ITC (Noyau ITC) 34 sera connecté fonctionnellement à la fois au logiciel "Envoyer
Un Evénement" 32b et au logiciel "Recevoir Un Evénement" 32c. Le logiciel d'Affichage avec Interaction de l'opéra- teur 32d va créer des affichages d'icônes sur les fenêtres 12b de l'écran d'affichage 12a, et affichera aussi, sur les fenêtres 12b, les "informations d'événements" qui sont demandées par d'autres applications client (cela sera décrit ultérieurement dans cette description).
En fonctionnement, en se reportant à la figure 5, un opérateur situé au niveau d'un poste de travail 10 de la figure 10, qui exécute une application client particulière, visualisera une variété d'icônes sur un affichage à fenêtres 12b sur l'écran d'affichage 12a du poste de travail de la figure 1 pour cette application client particulière. L'opérateur cliquera "sur" une ou plusieurs des icônes pour permettre ainsi à un objet d'intérêt parmi des "informations d'événements" particulières d'être transmis à partir de l'application client particulière (par exemple, à partir de l'application client 1 24cl de la figure 3) vers d'autres applications client (par exemple, l'application client 2 26cl de la figure 3) via le serveur 26c2. Le logiciel d'Affichage avec Interaction de l'opérateur 32d de la figure 5 va afficher l'affichage à fenêtres 12b et l'icône ou les plusieurs icônes de l'affichage à fenêtres 12b sur l'écran d'affichage 12a du poste de travail de la figure 1. Lorsque l'opérateur clique "sur" l'icône ou les plusieurs icônes de l'affichage à fenêtres 12b, le logiciel d'Affichage avec Interaction de l'opérateur 32d en informe le logiciel de Lancement
IH-ITC 32a, et le logiciel de Lancement IH-ITC 32a active le logiciel "Envoyer Un Evénement" 32b. Le logiciel "Envoyer Un Evénement" 32b ordonne au Code de Structure
ITC 34 de l'application client particulière (par exemple, l'application client 1) d'envoyer l'objet d'intérêt contenu dans les informations d'événements particulières aux autres applications client (par exemple, l'application client 2) via le serveur 26c2. Lorsque les autres applications client produisent les informations d'événements demandées, les autres applications client envoient les informations d'événements demandées directement au Code de Structure ITC 34 de l'application client particulière sans passage à travers le serveur 26c2 ni enregistrement.
Lorsque les informations d'événements demandées sont re çues par l'application client particulière (par exemple, client 1), le Code de Structure ITC 34 de l'application client particulière, à son tour, informe le logiciel "Recevoir Un Evénement" 32c de l'application client particulière. Le logiciel "Recevoir Un Evénement" 32c de l'application client particulière informe le logiciel de
Lancement IH-ITC 32a de l'application client particulière que les informations d'événements demandées ont été re çues en provenance d'une autre application client. Le logiciel de Lancement IH-ITC 32a de l'application client particulière, à son tour, ordonne au logiciel d'Affichage avec Interaction de l'Opérateur 32d de l'application client particulière d'afficher les "informations d'événements" demandées sur l'écran d'affichage 12a du poste de travail 10 de la figure 1.
Chacune de ces quatre parties du Code d'Interface Homme-Machine 32 sera décrite ultérieurement dans la description.
En se reportant aux figures 3 et 6 à 13b, le fonctionnement du Code de Structure ITC (Noyau ITC) 34 de chaque application client, telle que l'application client 1 24cl et l'application client 2 25cul, est illustré.
Chaque application client inclut le Code de
Structure ITC (Noyau ITC). Par exemple, le logiciel d'application client 1 24cl et le logiciel d'application client 2 26cl de la figure 3 incluent chacun un Code de
Structure ITC 34. Le Code de Structure ITC 34 associé à une application client particulière quelconque interagit fonctionnellement avec le serveur 26c2 et le Code de
Structure ITC 34 associé à chaque autre application client. Par exemple, le Code de Structure ITC 34 de l'ap- plication client 1 24cl dans le premier poste de travail 24 de la figure 3 interagit fonctionnellement avec le logiciel serveur 26c2 et le Code de Structure ITC 34 du logiciel d'application client 2 26cl dans le second poste de travail 26. Le Code de Structure 34 d'une première application client 24cl transmet des objets d'intérêt au serveur 26c2 ; celui-ci transmet des informations d'événements associées à un événement "X" au Code de Structure 34 d'une seconde application client 26cl ; et reçoit des informations d'événements associées à un événement "X" à partir du Code de Structure 34 de la seconde application client 26cl. Cette interaction fonctionnelle entre le
Code de Structure 34 d'une première application client 24cl et le serveur 26c2 et le Code de Structure 34 d'autres applications client 26cl est décrite d'une manière plus détaillée dans les paragraphes qui vont suivre en référence aux figures 3 et 6 à 13b des dessins.
Sur les figures 3 et 6, en se reportant initialement à la figure 6, une représentation schématique de haut niveau de la distribution d'événements et d'intérêts est illustrée.
Sur la figure 3, on notera que le logiciel d'application client 1 24cl se trouve dans le premier poste de travail 24 et que le logiciel d'application client 2 26cl et le logiciel serveur 26c2 se trouvent dans le second poste de travail 26.
Sur la figure 6, une Application Client 1 24cl (appelée par la suite "Application 1") est interconnectée à une Application Client 2 26cl (appelée par la suite "Application 2"), l'Application 1 et l'Application 2 étant connectées à un serveur ITC 26c2. "L'Application
Client 1" 24cl de la figure 6 représente le logiciel d'application client 1 24cl de la figure 3, "l'Application Client 2" 26cl de la figure 6 représentant le logiciel d'application client 2 26cl de la figure 3, et le serveur ITC 26c2 de la figure 6 représentant le logiciel serveur 26c2 de la figure 3. Lorsque l'Application
Client 1 24cl de la figure 6 est exécutée dans le premier poste de travail 24 de la figure 3, un affichage à fenêtres (similaire à l'un des affichages à fenêtres 12b de la figure 1) apparaît sur l'écran d'affichage du moniteur du premier poste de travail 24. D'une manière similaire, lorsque l'Application Client 2 26cl de la figure 6 est exécutée dans le second poste de travail 26 de la figure 3, un autre affichage à fenêtres (similaire à l'un des affichages à fenêtres 12b de la figure 1) apparaît sur l'écran d'affichage du moniteur du second poste de travail 26. Les affichages à fenêtres apparaissant sur les deux moniteurs des premier et second postes de travail 24 et 26 peuvent être n'importe lesquels de ceux représentés sur la figure 2.
Sur la figure 6, on suppose que l'Application
Client 1 24cl ("Application 1") exécute une première application client. De plus, on suppose que l'Application
Client 2 26cl ("Application 2") exécute une seconde application client et, pendant l'exécution de la seconde application client par l'Application 2, certaines "informations d'événements" sont produites par l'Application 2.
Le terme "informations d'événements" et/ou le terme "événement" seront définis dans les trois paragra phes qui vont suivre par l'intermédiaire des trois exemples suivants.
A titre de premier exemple, pendant l'exécution de la seconde application client par l'Application 2 au niveau du second poste de travail 26, l'opérateur assis au niveau du second poste de travail 26 peut utiliser la souris 18 de la figure 1 pour placer un curseur sur l'une des fenêtres 12b de la figure 1 et pour sélectionner ainsi certaines informations dans cette fenêtre 12b. La "sélection." de certaines informations sur cette fenêtre 12b par l'Application 2 au niveau du poste de travail 26 peut impliquer soit un déplacement du curseur, soit un effacement d'informations ou une création d'informations.
La "sélection" de ces certaines informations dans cette fenêtre 12b constitue un "événement" et cet événement produit des "informations d'événements". L'Application 1 peut être intéressée par la réception de ces informations d'événements.
A titre de deuxième exemple, l'Application 1 est exécutée en France et implique une étude de la géologie du sol. L'Application 2 est exécutée à Houston et implique une application pétrophysique qui examine la pression dans un puits de forage. Il n'y a rien de commun entre l'Application 1 et l'Application 2, à l'exception d'un paramètre : la pression au niveau d'une certaine profondeur sous terre. L'Application 1 peut souhaiter examiner la courbe de pression en fonction de la profondeur produite dans l'Application 2. Par conséquent, la courbe de pression en fonction de la profondeur dans l'Application 2 et toute modification apportée sur celleci par un opérateur au niveau du second poste de travail 26 constituent des "informations d'événements". l'Application 1 est intéressée par la réception de ces informations d'événements.
A titre de troisième exemple, appelé "poursuite de curseur", l'Application 1, s'exécutant dans le premier poste de travail 24 de la figure 3, affiche une carte comportant des coordonnées x, y et z et un opérateur au niveau du premier poste de travail 24 peut déplacer un curseur sur la carte, ce qui produit des "informations d'événements" x, y et z. Cependant, l'Application 2, s'exécutant dans le second poste de travail 26 de la figure 3, visualise une représentation tridimensionnelle en "cube" d'un réservoir souterrain et l'Application 2 peut être intéressée par la réception des "informations d'événements" x, y et z à partir de l'Application 1 à chaque fois que des informations d'événements sont produites par l'Application 1. Par conséquent, lorsque l'opérateur au niveau du premier poste de travail 24 exécutant l'Application 1 déplace le curseur sur la carte, les "informations d'événements" x, y et z sont produites à partir de l'Application 1. Si l'Application 2 a préalablement exprimée un intérêt pour la réception de ces "informations d'événements" et lorsque les informations d'événements sont produites par l'Application 1, l'Application 1 dans le premier poste de travail 24 envoie ces "informations d'événements" à l'Application 2 dans le second poste de travail 26.
Sur la figure 6, lorsque l'Application 1 24cl exécute la première application client, on suppose que l'Application 1 est intéressée par la réception de certaines "informations d'événements particulières" à partir de l'Application 2 26cl lorsque l'Application 2 produit ces informations d'événements particulières. Dans ce cas, l'Application 1 24cl produit un signal "objet d'intéret" (qui est véhiculé le long de la ligne 36 sur la figure 6) à partir de l'Application 1 24cl vers le serveur ITC 26c2. Le serveur 26c2 informe l'Application 2 26cl de l'intérêt que porte l'Application 1 aux informations d'événements particulières en repropageant le signal "objet d'intérêt" mentionné ci-dessus à partir du serveur 26c2 vers l'Application 2 26cl (le long de la ligne 38 sur la figure 6). Le signal "objet d'intérêt" en provenance de l'Application 1 contient un identificateur qui identifie d'une manière unique l'Application 1. Par conséquent, lorsque l'Application 2 reçoit le signal d'objet d'intérêt (à partir de la ligne 38 sur la figure 6), l'Application 2 26cl sait que l'Application 1 24cl est intéressée par la réception des "informations d'événements particulières" lorsque les informations d'événements particulières sont produites par l'Application 2.
En résultat, lorsque l'Application 2 produit les "informations d'événements particulières" (c'est-à-dire, lorsque l'opérateur au niveau du poste de travail 26 sélectionne quelque chose en plaçant la souris 18 dans une fenêtre 12b et en appuyant sur un bouton de la souris), du fait que l'Application 2 sait que l'Application 1 est intéressée par la réception des informations d'événements particulières, l'Application 2 envoie ces informations d'événements particulières "directement" à l'Application 1 (via la ligne 40). c est-à-dire que les informations d'événements particulières ne sont pas envoyées à partir de l'Application 2 26cl vers le serveur 26c2 (via la ligne 38) ni à partir du serveur 26c2 vers l'Application 1 24cl (via la ligne 36). Du fait que le serveur 26c2 n'est pas impliqué dans le transfert des informations d'événements particulières à partir de l'Application 2 vers l'Application 1, un temps de traitement appréciable est économisé. En résultat, la "Structure Distribuée pour
Communications Inter-tâches entre Applications sur Poste de Travail" de la présente invention est "extensible".
C'est-à-dire que pour un programme d'application client particulier s'exécutant dans un poste de travail tel que représenté par l'une des fenetres 12b affichées sur la figure 1, un développeur d'applications peut définir (1) le type d'événements que l'application client particulière va recevoir à partir d'une autre application client s'exécutant concurremment, et (2) le type de données associées aux événements qui seront reçues à partir des autres applications client à chaque fois que ces événements seront transmis à partir des autres applications client.
Sur la figure 7, un organigramme de l'enregistrement et de la distribution d'objets d'intérêt est illustré. Cet organigramme décrit certains des concepts décrits ci-dessus en référence à la figure 6. Sur la figure 7, lorsque l'Application Client 1 24cl souhaite enregistrer un intérêt dans un événement (c'est-à-dire, lorsque l'Application 1 souhaite enregistrer un intérêt dans un événement du fait qu'elle souhaite recevoir des informations en provenance d'une ou de plusieurs autres applications client lorsque les autres applications client pratiquent ou exécutent l'événement), un certain nombre d'étapes de traitement sont pratiquées par l'Application 1 24cl, le serveur 26c2 et l'Application 2 26cl
1. Sur la figure 7, dans le bloc 24cl(a), l'Application Client 1 24cl ("Application 1") inclut deux parties : (1) une première application client ("application client 1"), et (2) un client pour une Communication Inter-tâche (ITC) ("client ITC") . Lorsque l'Application 1 exécute la première application client et si la première application client requiert des informations concernant un événement que l'on appellera par la suite "événement X", la première application client enregistre un intérêt dans l'événement X avec le client ITC en envoyant un "objet d'intérêt" au client ITC. L'objet d'intérêt contient un "jeton d'événements".
2. Sur la figure 7, dans le bloc 24cl(b), le client ITC mémorise certains jetons d'événements. Lorsque le client ITC reçoit l'objet d'intérêt à partir de la première application client, le client ITC vérifie le jeton d'événements présent dans l'objet d'intérêt en localisant une coïncidence entre le jeton d'événements contenu dans l'objet d'intérêt et un jeton d'événements catalogué dans une base de données. Lorsqu'une coïncidence entre jetons d'événements est localisée, le client ITC va "enregistrer un rappel d'application" ; c'est-à-dire que le client ITC va envoyer un signal de confirmation en retour à la première application client.
3. Sur la figure 7, dans le bloc 24cl(c), le client ITC envoie alors un signal d"'objet d'intérêt" au serveur ITC 26c2.
4. Sur la figure 7, dans le bloc 26c2(a), le serveur ITC reçoit le signal d"'objet d'intérêt" en provenance du client ITC et, en réponse à celui-ci, le serveur ITC enregistre (c'est-à-dire, le serveur ITC mémorise à l'intérieur de celui-ci) des données ou des informations relatives à l'intérêt manifesté dans l'événement
X que la "première application client" de "l'Application 1" a précédemment produit. On rappelle que la première application client de l'Application 1 a préalablement indiqué (en envoyant le signal d"'objet d'intérêt" au serveur ITC) qu'elle souhaite recevoir certaines informations à partir des autres applications client qui sont produites lorsque "l'événement X" est exécuté ou pratiqué par les autres applications client.
5. Sur la figure 7, dans le bloc 26c2(b), lorsque le serveur ITC enregistre les informations relatives à l'intérêt manifesté par la première application client dans la réception des informations d'événements X à partir d'autres applications client conformément au bloc 26c2 (a) , le serveur ITC diffuse vers toutes ces autres applications client un tel intérêt manifesté par la première application client. En résultat, toutes les autres applications client (c'est-à-dire, tous les autres programmes d'application client exécutés dans tous les postes de travail du réseau de postes de travail) savent que la première application client de l'Application 1 24cl est intéressée par la réception de certaines informations spécifiques à partir des autres applications client, les informations spécifiques étant produites à partir des. autres applications client uniquement lorsque "l'événement
X" est exécuté ou pratiqué par les autres applications client.
6. Sur la figure 7, dans les blocs 24cl(a), 24cl(b), ..., et 24cl(N), toutes les autres applications client ("application client 2" 26cl(a), "application client 3" 26cl(b), . .., et "application client N" 26cl(N)) enregistrent (c'est-à-dire mémorisent) l'intérêt manifesté par la première application client pour la réception d'informations relatives à "l'événement X" à chaque fois que l'une quelconque ou que la totalité des application client 2, application client 3, ..., et application client N pratiquent ou exécutent "l'événement X".
Sur les figures 8a et 8b, un autre organigramme de l'enregistrement et de la distribution d'objets d'intérêt (qui décrit des concepts similaires aux concepts décrits ci-dessus en relation avec les organigrammes des figures 6 et 7) est illustré. Dans l'organigramme des figures 8a et 8b, "l'application client 1" 24cl ("Application 1") est représentée comme étant en communication avec le serveur 26c2 et "l'application client 2" 26cl ("Application 2"), comme illustré précédemment sur les figures 6 et 7. Cependant, de plus, sur les figures 8a et 8b, deux autres applications client sont illustrées : "application client 3" 42 ("Application 3") et "application client 4" 44 ("Application 4"). En fonctionnement, en se reportant aux figures 8a et 8b, on suppose aux fins de la description que l'Application 1, l'Appli cation 2, l'Application 3 et l'Application 4 représentent des programmes d'application client qui s'exécutent dans quatre (4) postes de travail différents similaires au poste de travail de la figure 1. On suppose en outre que chacune des quatre applications (Application 1 à Application 4) produit un affichage à fenêtres au niveau de son poste de travail respectif similaire à l'affichage à fenêtres 12b représenté sur la figure 1. On suppose en outre que l'Application 1 de la figure 8a est représentée par le "logiciel client 1" 24cl sur la figure 3, que l'Application 2 de la figure 8a est représentée par le "logiciel client 2" 26cl sur la figure 3, et que le serveur 26c2 de la figure 8a est représenté par le "logiciel serveur" 26c2 sur la figure 3. Sur les figures 8a et 8b, l'Application 1 24cl enregistre un intérêt dans un événement ITC appelé "événement X" (les mécanismes réels situés derrière l'enregistrement de cet objet d'intérêt seront mieux compris en référence à la figure 14). Un objet d'intérêt est envoyé à partir de l'Application 1 24cl vers le serveur 26c2 via la ligne 46 sur la figure 8a.
Lorsque l'objet d'intérêt est reçu par le serveur 26c2, le serveur 26c2 enregistre, au sein de celui-ci, l'intérêt manifesté par l'Application 1 24cl dans l'événement
X. Le serveur 26c2 redistribue alors l'objet d'intérêt à : "l'Application 2" 26cl via la ligne 48, "l'Application 3" 42 via la ligne 50, et "l'Application 4" 44 via la ligne 52. Lorsque le serveur 26c2 redistribue l'objet d'intérêt de l'Application 1 aux autres applications client, Applications 2, 3 et 4, les autres applications client (Applications 2, 3 et 4) enregistrent dans celles-ci l'intérêt manifesté par l'Application 1 à l'égard de l'événement X.
Sur les figures 9a et 9b, une représentation schématique de haut niveau de la propagation d'événements utilisant une communication entre homologues est illus trée. On rappelle d'après les figures 8a et 8b que l'Application 1 24cl a transmis un signal "objet d'intérêt" au serveur 26c2 et que le serveur 26c2 a redistribué ce signal "objet d'intérêt" à l'Application 2 26cl. Le signal "objet d'intérêt" (qui identifie l'Application 1 comme étant sa source) a été enregistré dans l'Application 2 comme provenant de l'Application 1 et exprime un intérêt de l'Application 1 dans certaines informations spécifiques susceptibles d'être produites par l'Application 2 lorsqu'un "événement X" est pratiqué ou exécuté par l'Application 2. En résultat, sur les figures 9a et 9b, du fait que le signal "objet d'intérêt" préalablement envoyé à l'Application 2 par le serveur 26c2 identifie l'Application 1 comme étant le demandeur de telles informations spécifiques concernant "l'événement X", lorsque l'Application 2 26cl pratique ou exécute "l'événement X", les certaines informations spécifiques mentionnées cidessus concernant l'exécution ou la pratique de "l'événement X" sont envoyées directement à partir de "l'Application 2" 26cl vers "l'Application 1" 24cl (c'est-à-dire que les certaines informations spécifiques mentionnées ci-dessus ne sont pas transmises de l'Application 2 au serveur 26c2 ni du serveur 26c2 à l'Application 1 ; le serveur 26c2 est évité).
La transmission des certaines informations spécifiques mentionnées ci-dessus (concernant la pratique par l'Application 2 de l'événement X) directement à partir de l'Application 2 vers l'Application 1, sans passage à travers le serveur ni enregistrement, est une amélioration par rapport à la description de Good et autres de la technique antérieure, référencée dans l'arrière-plan technologique de la présente description. On rappelle que, dans la description de Good et autres, toutes les données à communiquer entre programmes d'application informatiques s'exécutant simultanément doivent être acheminées par l'intermédiaire d'un programme serveur ou d'un programme régulateur intermédiaire.
Sur les figures 10a et 10b, un schéma de haut niveau représentant la diffusion multiple d'informations d'événements à partir de l'Application 2 vers de multiples autres applications client intéressées est illustré.
En se reportant brièvement aux figures 8a et 8b, on rappelle qu'un objet d'intérêt a été envoyé à partir de l'Application 1 24cl vers le serveur 26c2, via la ligne 46 sur la figure 8a. On rappelle en outre que, lorsque l'objet d'intérêt a été reçu par le serveur 26c2, le serveur 26c2 a enregistré, à l'intérieur de celui-ci, l'intérêt manifesté par l'Application 1 24cl dans l'événement X. Le serveur 26c2 a alors redistribué l'objet d'intérêt à "l'Application 2" 26cl via la ligne 48, "l'Application 3" 42 via la ligne 50, et "l'Application 4" 44 via la ligne 52. Cependant, maintenant que l'objet d'intérêt, dans "l'événement X", a été redistribué par le serveur 26c2 aux Applications 2, 3 et 4, si l'une quelconque ou la totalité des Applications 2, 3 et/ou 4 pratiquent ou exécutent "l'événement X", l'Application responsable (2, 3 et/ou 4) transmet des informations concernant "l'événement X" directement en retour au demandeur, qui est l'Application 1 24cl, sans ré-enregistrement avec le serveur 26c2 ni passage à travers celui-ci (le serveur 26c2 reste inactif)
Par conséquent, sur les figures 10a et 10b, on suppose que le demandeur de l'événement X est à la fois "l'Application 1" 24cl et "l'Application 4" 44 (l'Application 1 et l'Application 4 ont toutes deux précédemment envoyé un objet d'intérêt dans "l'événement X" au serveur 26c2, et le serveur 26c2 a redistribué cet objet d'intérêt dans l'événement X à l'Application 2). Par conséquent, l'Application 2 sait que les Applications 1 et 4 sont intéressées par la réception d'informations concernant la pratique de "l'événement X". En résultat, lorsque "l'Application 2" 26cl pratique ou exécute "l'événement X", des informations concernant l'exécution de "l'événement X" sont envoyées directement à partir de l'Application 2 à la fois vers "l'Application 1" 24cl et vers "l'Application 4" 44 (les informations relatives à l'exécution de l'événement X ne sont pas ré-enregistrées par le serveur 26c2 ni ne sont acheminées par celui-ci et, en résultat, le serveur 26c2 est évité).
Sur les figures ila et îlb, un schéma de haut niveau représentant la "révocation d'intérêts" est illustré. On suppose que l'Application Client 1 24cl (Application 1) a préalablement enregistré un intérêt dans l'événement X avec le serveur 26c2 (en envoyant un objet d'intérêt au serveur), et, ensuite, que le serveur 26c2 a redistribué cet objet d'intérêt dans l'événement X à l'Application Client 2 26cl (Application 2), à l'Application Client 3 42 (Application 3), et à l'Application
Client 4 44 (Application 4). Ensuite, on suppose que l'Application 1 souhaite révoquer son intérêt dans "l'événement X". Pour révoquer son intérêt dans "l'événement X", l'Application 1 envoie un "objet de révocation" au serveur 26c2 (via la ligne 46 sur la figure 11), "l'objet de révocation" représentant l'indication par l'Application 1 aux autres applications client qu'elle ne souhaite plus recevoir aucune information concernant la pratique ou l'exécution, par d'autres applications, de "l'événement X". En réponse à la réception de l'objet de révocation, le serveur 26c2 supprime l'enregistrement, à l'intérieur de celui-ci, de l'intérêt manifesté par l'Application 1 dans la réception d'informations relatives à l'exécution, par d'autres applications client, de "l'événement X" lorsque l'événement X est pratiqué par d'autres applications. Ensuite, le serveur 26c2 redistribue l'objet de révocation, provenant de 1'Appli cation 1, à toutes les autres applications client c'est-à-dire que, sur la figure lla, le serveur 26c2 redistribue l'objet de révocation à l'Application 2 (via la ligne 48), à l'Application 3 (via la ligne 50) et à l'Application 4 (via la ligne 52). Lorsque les autres applications client (Applications 2, 3 et 4) reçoivent "l'objet de révocation", les autres applications client (Applications 2, 3 et 4) suppriment l'enregistrement de l'intérêt manifesté par l'Application 1 dans "l'événement
X". En résultat, aucune information concernant la pratique ou l'exécution, par les autres Applications Client 2, 3 ou 4, de l'événement X, n'est envoyée vers l'Application 1.
Sur les figures 12a et 12b, un schéma de haut niveau de la révocation implicite d'un intérêt pour un client déconnecté est illustré. On suppose que l'Application 1 24cl meurt ou se termine, tandis qu'elle possède des intérêts actifs en suspens. On rappelle que l'Application 1 possède des intérêts actifs en suspens du fait que l'Application 1 a précédemment transmis un objet d'intérêt dans "l'événement X" (et, peut-être, dans d'autres événements) au serveur 26c2 et que le serveur 26c2 a précédemment redistribué cet objet d'intérêt dans l'évé- nement X, et dans d'autres événements, aux autres applications client, "Application 2" 26cl, "Application 3" 42 et "Application 4" 44. Sur les figures 12a et 12b, si l'Application 1 meurt ou se termine, le serveur 26c2 avertit la fin de l'Application 1. Lorsque le serveur 26c2 avertit la fin de l'Application 1 24cl (le programme de l'Application 1 cesse de s'exécuter), le serveur 26c2 supprime l'enregistrement, au sein de celui-ci, de tous les intérêts en suspens que l'Application 1 a précédemment envoyés au serveur 26c2 (via la ligne 46). Ensuite, le serveur 26c2 distribue un "objet de révocation" correspondant à tous les intérêts en suspens de l'Applîca- tion 1 dans tous les événements à toutes les autres applications client, c'est-à-dire à "l'Application 2" 26cl, "l'Application 3" 42 et "l'Application 4" 44 sur la figure 12. Lorsque les autres applications. . .client (Applications 2, 3 et 4) reçoivent l'objet de révocation en provenance du serveur 2Gc2 associé à tous les intérêts en suspens de l'Application 1 dans tous les événements, les autres applications client (Applications 2, 3 et 4 sur la figure 12) suppriment l'enregistrement de tous les intérêts manifestés dans tous les événements que "1 'Application Client 1" 24cl a précédemment transmis aux
Applications 2, 3 et 4 via le serveur 26c2.
Sur les figures 13a et 13b, un schéma de haut niveau représentant la distribution d'intérêts en suspens dans une nouvelle application client est illustré. On suppose maintenant qu ' une nouvelle application client, "Application Client 5" 50 ("Application 5"), sur la figure 13a, commence à s'exécuter dans un poste de travail du réseau de postes de travail, similaire au poste de travail 10 de la figure 1. Lorsque le programme de l'Application 5 s'exécute, une fenêtre est affichée sur le poste de travail, laquelle est similaire aux affichages à fenêtres 12b de la figure 1. Lorsque l'Application 5 commence à s' exécuter, l'Application 5 s'enregistre ellemême avec le serveur 26c2 sur la figure 13 en envoyant un "signal d'enregistrement" (via une ligne 52 sur la figure 13) à partir de "l'Application 5" 50 vers le serveur 26c2. En réponse au "signal d'enregistrement", le serveur 26c2 enregistre, au sein de celui-ci, l'existence de la nouvelle application client, "l'Application 5" 50. On suppose maintenant que les "Application 2" 26cl, "Application 3" 42 et "Application 4" 44 sur la figure 13 ont envoyé précédemment vers le serveur 26c2 un "objet d'intérêt" dans un événement, appelé "événement X", et, éventuellement, dans d'autres événements. Dans ce cas, après que le serveur 26c2 ait enregistré au sein de celui-ci l'existence de la nouvelle "Application 5" Client, le serveur 26c2 redistribuera les objets d'intérêt provenant de toutes les autres applications client (Applications 2, 3 et 4) à la nouvelle "Application 5"
Client (via une ligne 54 sur la figure 13a). Dans l'exemple de la figure 13a, le serveur 26c2 redistribue à l'Application 5 : (1) l'intérêt exprimé précédemment par l'Application 2 dans l'événement X et dans d'autres événements, (2) l'intérêt exprimé précédemment par l'Application 3 dans l'événement X et dans d'autres événements, et (3) l'intérêt exprimé précédemment par l'Application 4 dans l'événement X et dans d'autres événements (appelés ci-après "intérêts exprimés précédemment"). Lorsque la nouvelle "Application 5" Client 50 reçoit les intérêts exprimés précédemment (c'est-à-dire, les objets d'intérêt) dans l'événement X et dans d'autres événements (qui proviennent des Applications 2, 3 et 4) à partir du serveur 26c?, "l'Application 5" enregistre, au sein de celle-ci, les intérêts précédemment exprimés. Lorsque de tels intérêts précédemment exprimés (c'est-à-dire, les objets d'intérêt) en provenance des Applications 2, 3 et 4 sont enregistrés au sein de l'Application 5, l'Application 5 sait que les Applications 2, 3 et 4 requièrent certaines informations spécifiques concernant l'exécution et/ou la pratique de "l'événement X" et d'autres événements. En résultat, lorsque l'événement X ou d'autres événements sont exécutés par l'Application 5, l'Application 5 envoie ces certaines informations spécifiques directement aux Applications 2, 3 et 4 (ces certaines informations spécifiques ne passent pas par le serveur 26c2 ni ne sont enregistrées par celui-ci comme cela était le cas dans la description de Good).
En se reportant aux figures 14 à 25, une description détaillée du fonctionnement du logiciel d'Affi chage avec Interaction de l'Opérateur 32d de la figure 5 est illustrée.
Dans les paragraphes ci-dessus, le fonctionnement de la Structure ITC 34 de la figure 4 a été décrit en relation avec le logiciel d'application client 1 et le logiciel d'application client 2 24cl et 26cl mémorisés dans les postes de travail de la figure 3. On rappelle que la Structure ITC 34 de l'application client 1 24cl sur la figure 6 a envoyé des demandes pour des informations d'événements (associées à "l'événement X") au serveur 26c2, après quoi le serveur 26c2 a envoyé cette demande d'informations d'événements vers l'application client 2 26cl. Cependant, lorsque l'application client 2 pratique ou exécute "l'événement X", les informations d'événements associées à l'événement X sont envoyées directement à partir de l'application client 2 vers l'application client 1 (via la ligne 40 sur la figure G) sans passage par le serveur 26c2 ni enregistrement avec celui-ci.
Cependant, l'opérateur assis au niveau du second poste de travail 26 sur la figure 3 peut décider combien d'informations d'événements, s'il y a lieu, associées à "l'événement X" seront transmises à partir du second poste de travail 26, et l'opérateur assis au niveau du premier poste de travail 24 sur la figure 3 peut décider combien d'informations d'événements, s'il y a lieu, associées à "l'événement X" seront reçues dans le premier poste de travail 24.
Les opérateurs peuvent prendre cette décision et agir sur la base de cette décision en utilisant certaines "icônes" qui apparaissent à l'intérieur de chaque affichage à fenêtres (12b de la figure 1) sur l'écran d'affichage (12a sur la figure 1) de leur poste de travail particulier (10 sur la figure 1). Par exemple, l'opérateur au niveau d'un poste de travail peut cliquer sur une première icône et autoriser l'émission ou la réception de toutes les informations d'événements vers et à partir de son application client, ou l'opérateur peut cliquer sur une deuxième icône et désactiver complètement l'émission ou la réception de toutes les informations d'événements vers ou à partir de son application client, ou l'opérateur peut cliquer sur une troisième icône et choisir sélectivement combien et quel type d'informations d'événements seront émises à partir de son application client ou seront reçues par celle-ci.
Les paragraphes qui vont suivre décrivent chacune des icônes et leur fonction. Les icônes apparaissent au niveau du coin inférieur droit de chaque affichage à fenêtres (12b sur la figure 1) de l'écran d'affichage (12a sur la figure 1) du poste de travail 10. I1 existe trois types principaux d'icônes : l'icône d'état 60, l'icône de diffusion 62 et l'icône de filtre à événements 64. Il existe trois types d'icônes d'état 11 icône d'état ouvert 60a, l'icône d'état fermé 60b et l'icône d'état verrouillé 60c.
Sur la figure 14, les icônes d'état 60 et l'icone de diffusion 62 sont illustrées. Les icônes d'état 60 incluent l'icône d'état ouvert 60a, l'icône d'état fermé 60b et l'icône d'état verrouillé 60c. Chacune de ces icônes va maintenant être décrite.
Icône d'état ouvert 60a de la figure 14
L'icône d'état ouvert 60a est accessible à un opérateur et apparaît dans le coin inférieur droit d'un affichage à fenêtres (similaire à l'affichage à fenêtres 12b de la figure 1) . L'opérateur assis au niveau d'un poste de travail (analogue au poste de travail 24 ou 26 sur la figure 3) localise un affichage à fenêtres (12b sur la figure 1) sur l'écran d'affichage (12a sur la fi gure 1) et clique sur l'icône d'état ouvert 60a qui apparaît dans le coin inférieur droit de l'affichage à fenêtres 12b. Lorsque l'opérateur clique sur l'icône d'état ouvert 60a d'un affichage à fenêtres 12b pour une.application client particulière, cette application client particulière est ouverte et reçoit toutes les informations d'événement en provenance d'autres applications client de plus, cette application client particulière est ouverte et transmet toutes les informations d'événement aux autres applications client. Par exemple, un opérateur peut modifier une taille de police (qui est un "événement" qui produit des "informations d'événement").
Si l'opérateur clique "sur" l'icône d'état ouvert 60a pour un programme d'application client particulier, les informations d'événements relatives à un changement de taille de police sont transmises à toutes les autres applications client intéressées qui ont demandé les informations d'événement relatives à un changement de taille de police (via un objet d'intérêt dans l'événement relatif à un changement de taille de police envoyé par les autres applications client à l'application client particulière via le serveur intervenant).
Par exemple, si un opérateur assis au niveau du poste de travail 24 de la figure 3 clique sur l'icône d'état ouvert 60a sur l'affichage à fenêtres 12b de la figure 1 pour l'application client 1 24cl de la figure 3, l'application client 1 24cl recevra toutes les informations d'événements demandées à partir de l'application client 2 26cl de la figure 3, et l'application client 1 transmettra toutes les informations d'événements demandées à l'application client 2 26cl.
Icône d'état fermé 60b de la figure 14
L'icône d'état fermé 60b est accessible à un opérateur et apparaît dans le coin inférieur droit d'un affichage à fenêtres (similaire à l'affichage à fenêtres 12b de la figure 1) . L'opérateur assis au niveau d'un poste de travail (tel que le poste de travail 24 ou 26 sur la figure 3) peut localiser un affichage à fenêtres (12b sur la figure 1) sur l'écran d'affichage (12a sur la figure 1) et clique sur l'icône d'état fermé 60b qui apparaît dans le coin inférieur droit de l'affichage à fenêtres. Lorsque l'opérateur clique sur l'icône d'état fermé 60b d'un affichage à fenêtres 12b pour une application client particulière, cette application client particulière est fermée et ne recevra aucune information d'événements à partir d'autres applications client, et cette application client particulière est fermée et ne transmettra aucune information d'événements aux autres applications client.
Par exemple, si un opérateur assis au niveau du poste de travail 24 de la figure 3 clique sur l'icône d'état fermé 60b sur l'affichage à fenêtres 12b de la figure 1 pour l'application client 1 24cl de la figure 3, l'application client 1 24cl ne recevra aucune information d'événement demandée en provenance de l'application client 2 26cl de la figure 3, et l'application client 1 ne transmettra aucune information d'événement demandée à l'application client 2 26cl.
Icone d'état verrouillé 60c
L'icône d'état verrouillé 60c est accessible à la fois à un opérateur et au programmeur d'une application client particulière. L'icône d'état verrouillé 60c apparait dans le coin inférieur droit d'un affichage à fenêtres (12b sur la figure 1) de l'application client particulière. Dans certains cas, l'opérateur au niveau d'un poste de travail peut cliquer "sur" l'icône d'état ouvert 60a dans un affichage à fenêtres 12b associé à l'application client particulière. Cependant, le programmeur de l'application peut avoir précédemment décidé que, pour l'application client particulière mentionnée précédemment, absolument aucune information d'événements ne peut être transmise à partir de cette application client particulière, ni reçue de celle-ci. En résultat, le programmeur de l'application, qui a programmé l'application client particulière, peut avoir demandé (d'une manière interne, à l'intérieur du code de l'application client particulière) que l'application client particulière soit fermée (comme s'il avait été clique "sur" l'icône d'état fermé 60b). Dans ce cas, l'icône d'état verrouillé 60c apparaît pour cliquer "sur", d'elle-même, en réponse à la spécification qui veut que l'application client particulière soit fermée, laquelle spécification est insérée à l'intérieur du code de l'application client particulière.
Un état instable pourrait amener l'icône d'état verrouillé 60c à se comporter comme si l'on avait automatiquement cliqué "sur" celle-ci.
Cependant, l'opérateur pourrait aussi cliquer "sur" l'icône d'état verrouillé 60c. Lorsque l'on clique "sur" l'icône d'état verrouillé 60c, ceci équivaut à cliquer "sur" l'icône d'état fermé 60b. C'est-à-dire que lorsque l'on clique "sur" l'icone d'état verrouillé 60c, aucune information d'événement ne sera reçue par une application client particulière à partir d'autres applications client (via la ligne 40 sur la figure 6), aucune information d'événements ne sera envoyée à partir de l'application client particulière vers d'autres applications client, et aucun objet d'intérêt associé à un événement particulier ne sera envoyé par l'application client particulière vers le serveur 26c2 (via la ligne 36 sur la figure 6) pour etre transmis en outre à d'autres applications client (via la ligne 38 sur la figure 6).
Icône de diffusion 62
L'icône de diffusion 62 apparaît dans le coin inférieur droit d'un affichage à fenêtres particulier (12b sur la figure 1) qui est produit par un programme d'application client particulier, tel que l'application client 1 ou l'application client 2 de la figure 3, s'exécutant au sein d'un poste de travail (10 sur la figure 1) . On suppose que, pour ce programme d'application client particulier, on a cliqué "sur" l'icône d'état fermé 60b pendant une certaine période de temps. Une pluralité d'événements nouvellement créés (tels que changements de taille de police, changements de couleur, ou traits interrompus) qui ont été produits pendant cette période de temps ne seront pas transmis par l'application client particulière aux autres applications client intéressées s' exécutant dans le poste de travail en question ou dans d'autres postes de travail du réseau de postes de travail. Cependant, lorsqu'un opérateur assis au niveau du poste de travail (10 sur la figure 1) clique "sur" l'icône de diffusion 62 à l'intérieur de l'affichage à fenêtres 12b en utilisant la souris (18 sur la figure 1), la totalité des événements de la pluralité d'événements nouvellement créés dans l'application client particulière 12b, qui ont été produits par un opérateur au niveau du poste de travail 10 pendant la période de temps mentionnée ci-dessus lorsque l'on a cliqué "sur" l'icône d'état fermé 60b, seront transmis simultanément à partir de l'application client particulière à toutes les autres "applications client intéressées" s'exécutant dans le réseau de postes de travail (les termes "applications client intéressées" indiquant que des "objets d'intérêt" dans les événements nouvellement créés ont été précédemment transmis à partir des autres applications client au serveur 26c2 et à partir du serveur 26c2 à l'application client particulière).
Sur les figures 15a à 15e est illustrée l'icône de filtre à événements 64. L'icône de filtre à événements 64 va être décrite dans le paragraphe suivant.
Icône de filtre à événement 64
Sur la figure 5, on rappelle que chaque application client, telle que l'application client 1 24cl et l'application client 2 26cl de la figure 3, inclut un logiciel de Lancement IH-ITC 32a (voir figure 5). Le logiciel de Lancement IH-ITC 32a inclut une "liste d'événements" codée et mémorisée et une "liste de fonctions" correspondant, respectivement, à la "liste d'événements" (cette liste d'événements et cette liste de fonctions correspondante seront décrites avec plus de détails dans la présente description en référence à la figure 26 des dessins).
Par conséquent, lorsqu'une application client particulière (telle que l'application client 1 ou l'application client 2 de la figure 3) envoie un objet d'intérêt dans un "événement X" à une autre application client via le serveur 26c2 dans le but de recevoir des informations d'événements à partir des autres applications client concernant la pratique de cet événement X, "l'événement X" doit, par nécessité, être l'un des événements contenus dans la "liste d'événements" (de la figure 26) codée à l'intérieur du logiciel de Lancement IH-ITC 32a de la figure 5 pour cette application client particulière.
D'une manière similaire, si une application client particulière a l'intention d'envoyer des "informations d'événements" à d'autres applications client qui sont associées à la pratique par l'application client particulière d'un "événement particulier", cet "événement particulier" doit être l'un des événements mémorisés dans la "liste d'événements" (de la figure 26) codée à l'intérieur du logiciel de Lancement IH-ITC 32a de la figure 5 pour cette application client particulière.
En conséquence, du fait que chaque application client particulière est dite être "intéressée" par la réception d'une pluralité "d'informations d'événements" associée à une pluralité d'événements à partir d'autres applications client, la pluralité d'événements sont mémorisés dans la "liste d'événements" codée à l'intérieur du logiciel de Lancement IH-ITC 32a (voir figure 26 pour la "liste d'événements") pour ladite application client particulière. D'une manière similaire, du fait que chaque application client particulière envoie des "informations d'événements" associées à une pluralité d'événements aux autres applications client intéressées, les événements de cette pluralité d'événements sont mémorisés dans la "liste d'événements" codée dans le logiciel de Lancement
IH-ITC 32a.
Cependant, en utilisant l'icône de filtre à événements 64 de la figure 15, un opérateur ou un utilisateur, surveillant l'application client particulière sur un affichage à fenêtres (12b sur la figure 1) au niveau de son poste de travail (10 sur la figure 1) peut décider d'une manière sélective du nombre d'événements parmi la pluralité d'événements contenus dans la liste d'événements codée dans le logiciel de Lancement IH-ITC 32a qu'il transmettra à d'a d'événements contenus dans la liste d'événements codée dans le logiciel de Lancement IH-ITC 32a qu'il recevra à partir des autres applications client, via le serveur 26c2.
Sur les figures 15a à 15e, l'icône de filtre à événements 64 des figures 15a Wet 15b est située dans le coin inférieur droit de chaque affichage à fenêtres 12b sur l'écran d'affichage 12a d'un poste de travail 10.
Comme représenté sur la figure 15b, lorsque l'opérateur au niveau du poste de travail 10 utilise la souris 18 pour cliquer "sur" l'icône de filtre à événements 64 qui apparaît sur un affichage à fenêtres 12b, un affichage en sous-fenêtre 64a représenté sur la figure 15c est présenté à l'opérateur sur l'écran d'affichage 12a.
Sur la figure 15c, l'affichage en sous-fenêtre 64a (qui apparaît sur l'écran d'affichage 12a du poste de travail 10 lorsqu'un opérateur clique "sur" l'icône de filtre à événements 64 contenue dans un affichage à fenêtres 12b pour une application client particulière) inclut trois colonnes : (1) la colonne "émettre" 64al, (2) la colonne "recevoir" 64a2, et (3) la colonne "messages" ou "événements" 64a3. Une pluralité de messages ou d'événements 64a3A sont imprimés sous la colonne "messages" 64a3. Les messages de cette pluralité de messages ou d'événements 64a3A représentent une pluralité d'événements pour lesquels : (1) une pluralité correspondante d'informations d'événements pourraient être reçues à partir d'autres applications client, et (2) une pluralité correspondante d'informations d'événements pourraient être envoyées ou transmises vers d'autres applications client. Une pluralité de boîtes "émettre" 64alA apparaissent sous la colonne "émettre" 64al, et une pluralité de boîtes "recevoir" 64a2A apparaissent sous la colonne "recevoir" 64a2. Pour chacun des messages de la pluralité de messages 64a3A, il existe une boîte "émettre" 64alA et une boîte "recevoir" 64a2A. Un opérateur utiliserait la souris 18 de la figure 1 pour cliquer dans une boîte "émettre" et/ou une boîte "recevoir" pour chacun des événements de la pluralité d'événements 64a3A.
Si l'opérateur clique dans une boîte "émettre" 64alA pour un message ou un événement particulier (l'un des événements 64a3A sur la figure 15c) pour une application client particulière, des "informations d'événements" associées à cet événement particulier sont, en fait, envoyées à partir de l'application client particulière vers les autres applications client qui ont exprimé un intérêt dans l'événement particulier en association avec l'application client particulière ; cependant, si l'opérateur n'a pas cliqué dans la boîte "émettre" 64alA pour cet événement particulier 64a3A associé à cette application client particulière, aucune "information d'événements" associée à cet événement particulier 64a3A ne sera envoyée par l'application client particulière vers les autres applications client qui ont exprimé un intérêt dans l'élément particulier en association avec l'application client particulière.
De plus, si l'opérateur a cliqué à l'intérieur d'une boîte "recevoir" 64a2A pour un message ou un événement particulier 64a3A associé à une application client particulière, des "informations d'événements" associées à cet événement particulier 64a3A sont, en fait, reçues en provenance d'autres applications client par l'application client particulière en réponse à cet événement particulier ; cependant, si l'opérateur n'a pas cliqué dans la boîte "recevoir" 64a2A pour cet événement particulier 64a3A pour cette application client particulière, aucune "information d'événements" associée à cet événement particulier 64a3A ne sera reçue en provenance des autres applications client par l'application client particulière en réponse à cet événement particulier.
Sur les figures 15d et 15e, on considère des exemples de l'utilisation du filtre à événements 64 et de l'utilisation consécutive de l'affichage en sous-fenêtre 64a associé à ce filtre à événements 64.
Dans l'exemple de la figure 15d, quatre événements apparaissent sous la colonne "événements" 64a3 de l'affichage en sous-fenêtre 64a du filtre à événements 64 (apparaissant dans un affichage à fenêtres 12b sur l'écran d'affichage 12a d'un poste de travail 10 associé à une application client particulière) (1) changer couleur, (2) changer épaisseur, (3) changer forme, et (4) poursuite curseur. On notera, pour chacun de ces événements, si l'on a cliqué ou non "sur" les boîtes "émettre" 64alA et/ou "sur" les boîtes "recevoir" 64a2A (en plaçant ou non une marque noire dans la boîte).
Sur la figure 15d, en prenant chaque événement dans l'ordre, pour l'événement "changer couleur" de la figure 15d, on n'a pas cliqué sur la boite "émettre" lAl, ni sur la boîte "recevoir" 2A1. En résultat, pour l'événement "changer couleur" associé à l'application client particulière, aucune information d'événements pour l'évé- nement "changer couleur" ne sera transmise aux autres applications client, et aucune information d'événements pour l'événement "changer couleur" ne sera pas reçue en provenance d'autres applications client.
Sur la figure 15d, pour l'événement "changer épaisseur", on a cliqué sur la boîte "émettre" 1A2, mais pas sur la boîte "recevoir" 2A2. En résultat, pour l'événement "changer épaisseur" associé à l'application client particulière, des informations d'événements associées à l'événement "changer épaisseur" seront transmises à d'autres applications client, mais aucune information d'événements pour l'événement "changer épaisseur" ne sera re çue en provenance d'autres applications client.
Sur la figure 15d, pour l'événement "changer forme", on n'a pas cliqué sur la boîte "émettre" 1A3, mais l'on a cliqué sur la boîte "recevoir" 2A3. En résultat, pour l'événement "changer forme" associé à l'application client particulière, aucune information d'événements pour l'événement "changer forme" ne sera transmise à d'autres applications client, mais des informations d'événements associées à l'événement "changer forme" seront reçues en provenance d'autres applications client.
Sur la figure 15d, pour l'événement "poursuite curseur", on a cliqué sur la boîte "émettre" 1A4 et sur la boîte "recevoir" 2A4. En résultat, pour l'événement "poursuite curseur" associé à l'application client particulière, des informations d'événements associées à l'événement "poursuite curseur" seront transmises à d'autres applications client, et des informations d'événements associées à l'événement "poursuite curseur" seront reçues en provenance d'autres applications client.
Cependant, dans l'exemple de la figure 15e, les quatre memes événements apparaissent sous la colonne "événements" 64a3 de l'affichage en sous-fenêtre 64a du filtre à événement 64 (apparaissant dans un affichage à fenêtres 12b sur l'écran d'affichage 12a d'un poste de travail 10 associé à une application client particulière) : (1) changer couleur, (2) changer épaisseur, (3) changer forme, et (4) poursuite curseur. L'affichage en sous-fenêtre 64a sur la figure 15e comporte en outre une boite "tout" 64a4 située sous la colonne "émettre" 64al et une autre boîte "tout" 64a5 sous la colonne "recevoir" 64a2. Lorsque l'on clique "sur" une boîte "tout", cela équivaut à cliquer "sur" chacune des boîtes ("émettre" ou "recevoir") individuelles situées au-dessus de la boite "tout" ; cependant, si l'on ne clique pas "sur" la boîte "tout", il est nécessaire de cliquer ou non individuellement "sur" chacune des boîtes individuelles situées au dessus de la boîte "tout". Par exemple, on notera que l'on a cliqué "sur" la boîte "tout" 64a5 située sous la colonne "recevoir" 64a2, mais que l'on n'a pas cliqué "sur" la boîte "tout" 64a4 située sous la .colonne "émettre" 64al. Du fait que l'on a clique "sur" la boîte "tout" 64a5 située sous la colonne "recevoir" 64a2, cela équivaut à avoir cliqué "sur" toutes les boîtes "recevoir" 2A1, 2A2, 2A3 et 2A4 contenues dans l'affichage en sous-fenêtre 64a sur le figure 15e. Cependant, du fait que l'on n'a pas cliqué "sur" la boîte "tout" 64a4 située sous la colonne "émettre" 64al, il est nécessaire de cliquer ou non individuellement "sur" chacune des boîtes individuelles lAl, 1A2, 1A3 et 1A4. En résultat, sur la figure 15e, l'événement "changer couleur" ne sera pas envoyé à partir de l'application client particulière vers d'autres applications client, mais sera reçu par l'application client particulière en provenance d'autres applications client. De plus, l'événement "changer épaisseur" sera envoyé par l'application client particulière vers d'autres applications client et sera reçu par l'application client particulière en provenance d'autres applications client. L'événement "changer forme" ne sera pas envoyé par l'application client particulière vers d'autres applications client, mais sera reçu par l'application client particulière en provenance d'autres applications client. L'événement "poursuite curseur" sera envoyé par l'application client particulière vers les autres applications client, et sera reçu par l'application client particulière en provenance des autres applications client.
Le fonctionnement du filtre à événements 64 et de sa sous-fenetre 64a seront à nouveau décrits cidessous en relation avec la description de la figure 26 et du fonctionnement de la présente invention.
Sur les figures 16 à 23, des exemples de l'utilisation de toutes les icônes des figures 14 et 15a, incluant l'icône d'état ouvert 60a, l'icône d'état fermé 60b, l'icône d'état verrouillé 60c, l'icône de diffusion 62, et l'icône de filtre à événements 64 sont illustrés.
Sur la figure 16, un affichage à fenêtres, qui pourrait être l'un des affichages à fenêtres 12b de la figure 1, comporte un groupe d'icônes dans le coin inférieur droit de l'affichage à fenêtres, les icônes incluant une icône d'état fermé 60b, une icône de diffusion 62, et une icône de filtre à événements 64.
Sur la figure 17, un autre affichage à fenêtres 12b comporte une icône d'état fermé 60b et une icône de diffusion 62 situées dans le coin inférieur droit de l'affichage à fenêtres 12b.
Sur la figure 18, un autre affichage à fenêtres 12b comporte une icône d'état ouvert 60a et une icône de diffusion 62 situées dans le coin inférieur droit de l'affichage à fenêtres 12b.
Sur la figure 19, un autre affichage à fenêtres 12b comporte une icône d'état verrouillé 60c et une icône de diffusion 62 situées dans le coin inférieur droit de l'affichage à fenêtres 12b.
Sur les figures 20 à 23, en se reportant initialement à la figure 20, un opérateur voit une fenêtre maître 12bl sur l'écran d'affichage 12a de la figure 1 et, en utilisant la souris 18 de la figure 1, l'opérateur peut ensuite obtenir un certain nombre de sous-fenêtres représentées sur les figures 21, 22 et 23. Par exemple, la fenêtre maître 12bl de la figure 20 inclut une icône d'état ouvert 60a et une icône de diffusion 62 situées dans le coin inférieur droit de la fenêtre. Cependant, la fenêtre maître 12bl de la figure 20 inclut aussi une boîte 70. Si l'opérateur utilise la souris 18 pour cliquer sur la boîte 70 dans la fenêtre maître 12bl de la figure 20, en plus de la fenêtre maître 12bl, une première sous-fenêtre 12b2 représentée sur la figure 21 sera présentée à l'opérateur sur l'écran d'affichage 12a du poste de travail 10 de la figure 1. La première sous-fenêtre 12b2 inclut une icône d'état ouvert 60a et une icône de diffusion 62 situées dans le coin inférieur droit de la première sous-fenêtre 12b2. La première sous-fenêtre 12b2 inclut une deuxième boîte 72 et une troisième boîte 74. Si l'opérateur utilise la souris 18 pour cliquer sur la deuxième boîte 72 de la première sous-fenêtre 12b2 de la figure 21, une deuxième sous-fenêtre 12b3 représentée sur la figure 22 est présentée à l'opérateur sur l'écran d'affichage 12a du poste de travail 10 de la figure 1. La deuxième sous-fenêtre 12b3 inclut une icône d'état verrouillé 60c et une icône de diffusion 62 situées dans le coin inférieur droit de la deuxième sous-fenêtre 12b3. Si l'opérateur utilise la souris 18 pour cliquer sur la troisième boîte 74 de la première sous-fenêtre 12b2 de la figure 21, une troisième sous-fenêtre 12b4 représentée sur la figure 23 est présentée à l'opérateur sur l'écran d'affichage 12a du poste de travail 10 de la figure 1. La troisième sous-fenêtre 12b4 inclut une icône d'état fermé 60b et une icône de diffusion 62 dans le coin inférieur droit de la troisième sous-fenêtre 12b4.
Les paragraphes ci-dessus ont décrit la structure et la fonction des icônes d'état qui incluent l'icône d'état ouvert 60a, l'icône d'état fermé 60b et l'icône d'état verrouillé 60c, en plus de l'icône de diffusion 62 et de l'icône de filtre à événements 64. Chacune de ces icônes apparaît dans le coin inférieur droit d'une fenêtre 12b sur la figure 1. Cependant, il reste une icône supplémentaire à décrire, laquelle est appelée icône "Evénement Gestionnaire d'Application Restauré", qui apparaît dans le coin inférieur gauche de l'affichage à fenêtres 12b de la figure 1 (non pas dans le coin droit dans lequel les autres icônes décrites ci-dessus apparaissent). L'icône "Evénement Gestionnaire d'Application
Restauré" va maintenant être décrite en détail.
Icône "événement gestionnaire d'application restauré" 76
Sur les figures 1, 24 et 25, chacune des fenêtres 12b de la figure inclut une icône "Evénement Gestionnaire d'Application Restauré" 76 (figure 24) qui est située dans le coin inférieur gauche de la fenêtre 12b.
Par exemple, l'une des fenêtres 12b de la figure 1 peut inclure la fenêtre 12b5 de la figure 24.
Sur la figure 24, la fenêtre 12b5 inclut l'icône "Evénement Gestionnaire d'Application Restauré" 76 située dans le coin inférieur gauche de la fenêtre 12b5. On suppose maintenant qu'une multitude de fenêtres 12b sont présentées à l'opérateur sur l'écran d'affichage 12a du poste de travail 10 de la figure 1. On suppose en outre que l'opérateur souhaite accéder à une application client particulière à partir du poste de travail 10 ; cependant, la multitude de fenêtres 12b sur l'écran d'affichage 12a encombrent l'écran d'affichage 12a et, en résultat, il est très difficile pour l'opérateur d'accéder à l'application client particulière.
Sur les figures 1 et 24, pour accéder à l'application client particulière, l'opérateur va trouver l'icône "Evénement Gestionnaire d'Application Restauré" 76 dans le coin inférieur gauche d'une fenêtre 12b quelconque de l'écran d'affichage 12a de la figure 1. L'une des fenêtres 12b de la figure 1 peut inclure la fenêtre 12b5 de la figure 24. La fenêtre 12b5 de la figure 24 inclut l'icône "Evénement Gestionnaire d'Application Restauré" 76 dans le coin inférieur gauche et une icône d'état verrouillé 60c et une icône de diffusion 62 dans le coin inférieur droit de la fenêtre 12b5. En utilisant la souris 18, l'opérateur clique "sur" l'icône "Evénement
Gestionnaire d'Application Restauré" 76 de la figure 24.
En réponse, une fenêtre de lancement principale 12b6, illustrée sur la figure 25, est affichée sur l'écran d'affichage 12a du poste de travail 10 de la figure 1.
Sur les figures 2 et 25, la fenêtre de lancement principale 12b6 de la figure 25 inclut une pluralité d icônes d'application client 78 différentes représentant une pluralité respective de programmes d'application client différents. Le poste de travail 10 de la figure 1 exécutera un programme particulier quelconque parmi les programmes d'application client différents si et lorsque l'opérateur situé au niveau du poste de travail 10 de la figure 1 utilisera la souris 18 pour cliquer "sur" l'icône d'application client 78 de la figure 25 qui correspond à ce programme d'application client particulier.
On se reportera, par exemple, aux différentes applications client 20 représentées sur la figure 2. Chacune de la pluralité d'applications client 78 différentes représentées sur la figure 25 peut représenter l'une parmi la pluralité d'applications client 20 représentées sur la figure 2.
En se reportant aux figures 26, 26A et 27, la construction détaillée et le fonctionnement du logiciel de Lancement IH-ITC 32a de la figure 5 sont illustrés.
Sur la figure 26, le logiciel de Lancement 1H-
ITC 32a de la figure 5 inclut les blocs de code suivants (mais n' est pas limité à ceux-ci) (1) "Construire Liste d'Evénements ITC" 80 (2) "Fonction 1 d'appel à réception de l'Evénement 1" 82, (3) "Fonction 2 d'appel à réception de l'Evénement 2" 84, (4) "Appeler itc hi Filter And Session" 86, (5) "Fonction d'appel à diffusion" 88, et (6) "Appeler itc~hi~Delete" 90.
Le bloc "Construire Liste d'Evénements ITC" 80 de la figure 26 est illustré avec plus de détails sur la figure 26A.
Chacun de ces blocs de code est décrit cidessous.
"Construire liste d'événements ITC" 80 "Fonction i d'appel à réception de l'événement 1" 82 "Fonction 2 d'appel à réception de l'événement 2" 84
Sur les figures 3, 4, 5 et 6, on rappelle d'après les figures 3 et 4 que l'application client 1 24cl a été mémorisée dans la mémoire 24c du premier poste de travail 24 de la figure 3 et que l'application client 2 26cl a été mémorisée dans la mémoire 26c du second poste de travail 26 de la figure 3. L'application client 1 24cl et l'application client 2 26cl incluent chacune (1) le Code d'Interface Homme-Machine ITC 32, et (2) le
Code de Structure ITC (Noyau ITC) 34 de la figure 4. Le
Code de Structure ITC (Noyau ITC) 34 a été décrit cidessus en référence aux figures 6 à 13. Le Code d'Interface Homme-Machine ITC 32 de la figure 4 comporte quatre parties : le logiciel de Lancement IH-ITC 32a de la figure 5, le logiciel "Envoyer Un Evénement" 32b de la figure 5, le logiciel "Recevoir Un Evénement" 32c de la figure 5, et le logiciel d'Affichage avec Interaction de l'Opérateur 32d de la figure 5.
Lorsque l'application client 1 24cl souhaite recevoir des "informations d'événements" concernant un "événement X" à partir de l'application client 2 26cl, l'application client 1 envoie un "objet d'intérêt" dans l'événement X au serveur 26c2 sur les figures 3 et 6. En réponse à la réception par le serveur 26c2 de "l'objet d'intérêt" dans l'événement X en provenance de l'application client 1, le serveur 26c2 : (1) enregistre l'intérêt exprimé par l'application client 1 dans l'événement X, et (2) redistribue cet objet d'intérêt dans l'événement X à partir du serveur 26c2 vers l'application client 2 26cl.
Lorsque l'application client 2 26cl pratique ou exécute l'événement X, les informations d'événements associées à la pratique de l'événement X dans l'application client 2 sont envoyées directement à partir de l'application client 2 vers l'application client 1 (via la ligne 40 de la figure 6) sans passage par le serveur 26c2 ni enregistrement.
D'une manière similaire, l'application client 2 26cl de la figure 3 envoie un objet d'intérêt dans l'événement X au serveur 26c2, et le serveur 26c2 : (1) enregistre l'intérêt exprimé par l'application client 2 dans les informations d'événements associées à l'événement X, et (2) envoie l'objet d'intérêt dans l'événement X à l'application client 1 24cl. Lorsque l'application client 1 24cl pratique ou exécute l'événement X, les informations d'événements associées à l'événement X sont envoyées directement par l'application client 1 24cl à l'application client 2 26cl (via la ligne 40 sur la figure 6) sans passage par le serveur 26c2 ni enregistrement.
Par conséquent, chaque programme d'application client, incluant l'application client 1 24cl et l'application client 2 26cl de la figure 3, doit enregistrer et mémoriser l'identité de tous les événements spécifiques (tels que "l'événement X"), ainsi que leurs objets d'intérêt et leurs fonctions, auxquels s'intéresse cette application client particulière.
Sur la figure 26, chaque programme d'application client particulier, incluant l'application client 1 24cl et l'application client 2 26cl de la figure 3 qui ont produit deux des affichages à fenêtres 12b de la figure 1, mémorise une "liste d'événements ITC" 80, une "liste de fonctions" 82, 84 correspondant, respectivement, à la "liste d'événements ITC" 80, et une "liste d'objets d'intérêt" correspondant, respectivement, à la "liste de fonctions" et à la "liste d'événements ITC" 80.
En résultat, sur la figure 26, le bloc 80 appelé "Construire Liste d'Evénements ITC" mémorise une liste d'événements dans laquelle une pluralité d'événements (c'est-à-dire, événement 1, événement 2, événement 3, ..., événement N) sont mémorisés. Les blocs 80, 84 mémorisent une pluralité de fonctions (c'est-à-dire, fonction 1, fonction 2, fonction 3, ... fonction N), qui correspondent, respectivement, à la pluralité d'événements du bloc 80, la pluralité de fonctions étant récupérées à partir de la mémoire et exécutées en réponse à la réception (par la Structure ITC 34 de la figure 5 d'une application client particulière) d'une pluralité respective d'événements transmis à l'application client particulière à partir des autres applications client.
Par exemple, une première fonction sur la figure 26 appelée "Fonction 1 d'appel à réception de l'Evénement 1" 82 représente la fonction associée à "l'événement 1" dans le bloc "Construire Liste d'Evénements ITC" 80. Une seconde fonction sur la figure 26 appelée "Fonction 2 d'appel à réception de 1'Evénement 2" 84 représente la fonction associée à "l'événement 2" dans le bloc "Construire Liste d'Evénements ITC" 80.
De plus, sur la figure 26A, le bloc 80 de la figure 26 mémorise aussi une pluralité "d'objets d'intérêt" correspondant, respectivement, à la pluralité "d'événements". Par exemple, sur la figure 26A, le bloc 80 de la figure 26, qui est appelé "Construire Liste d'Evénements ITC", comportera au moins deux colonnes d'informations mémorisées : (1) une première colonne 80a mémorisant une pluralité d'événements 80a, tels que l'Evénement 1, l'Evénement 2, l'Evénement 3, . .., et l'Evénement N ; et (2) une seconde colonne 80b mémorisant une pluralité d'objets d'intérêt 80b qui correspondent, respectivement, à la pluralité d'événements 80a, tels que "l'Objet d'Intérêt 1" associé à "l'Evénement 1", "l'Objet d'Intérêt 2" associé à "l'Evénement 2", "l'Objet d'Intérêt 3" associé à "l'Evénement 3", ..., et "l'Objet d'Intérêt N" associé à "l'Evénement N".
Par conséquent, lorsque le programme d'application client particulier commence à s'exécuter, du fait que l'application client particulière a mémorisé une "liste d'événements ITC", l'application client particulière enverra l'objet d'intérêt, associé à chacun des événements contenus dans la "liste d'événements ITC" mémorisée, à partir de l'application client particulière vers les autres applications client, via le serveur 26c2, comme représenté sur la figure 6.
De plus, si l'ensemble particulier d'objets d'intérêt correspondant à un ensemble particulier d'événements est envoyé par l'application client particulière 24cl vers les autres applications client 26cl via le serveur 26c2, si la "liste d'événements ITC" dans les autres applications client 26cl inclut l'ensemble particulier d'événements mentionné ci-dessus, et lorsque les autres applications client 26cl pratiquent ou exécutent l'ensem- ble particulier d'événements, les autres applications client 26cl enverront un ensemble particulier d'informations d'événements associé à l'ensemble particulier d'événements, directement, à l'application client particulière (via la ligne 40 sur la figure 6), sans enregistrer ces informations d'événements avec le serveur 26c2, et l'application client particulière recevra cet ensemble particulier d'informations d'événements.
De plus, lorsque d'autres applications client envoient un objet d'intérêt dans un événement X à l'application client particulière via le serveur 26c2, du fait que l'application client particulière mémorise une "liste d'événements ITC" et une liste correspondante "d'objets d'intérêt" associée à la liste d'événements
ITC, l'objet d'intérêt reçu à partir de l'autre application client est comparé par l'application client particulière à la "liste d'objets d'intérêt" de la figure 26A mémorisée dans l'application client particulière, et, si une coïncidence est trouvée, l'événement qui correspond à l'objet d'intérêt coïncidant (c'est-à-dire, "l'événement
X") sera transmis à partir de l'application client particulière directement vers les autres applications client (directement via la ligne 40 sur la figure 6)
De plus, pour chaque application client particulière dans laquelle une "liste d'événements ITC" est mémorisée, une "liste de fonctions" 82, 84 correspondante doit être mémorisée en correspondance, respectivement, avec la "liste d'événements ITC" mémorisée. En résultat, lorsqu'une autre application client pratique ou exécute "l'événement X" demandé, les informations d'événements associées à cet événement X seront envoyées directement à partir de cette autre application client vers l'application client particulière (via la ligne 40 sur la figure 6) sans passer par le serveur ni être enregistrées. Lorsque les informations d'événements associées à l'événement
X sont reçues par l'application client particulière, les informations d'événements reçues sont comparées par l'application client particulière à la "liste d'événements
ITC" 80 et à la "liste de fonctions" 82, 84 correspondante, mémorisée dans l'application client particulière.
Lorsqu une coïncidence est trouvée, par l'application client particulière, entre les informations d'événements reçues à partir de l'autre application client et "un événement particulier" de la "liste d'événements ITC" 80, la "fonction particulière" 82, 84 qui est associée à cet "événement particulier" est automatiquement rappelée à partir de la mémoire 24c, 26c, la "fonction particulière" 82, 84 étant exécutée par le processeur 24a ou 26a de la figure 3 dans le poste de travail 10 qui exécute l'application client particulière. Le logiciel d'Affichage avec
Interaction de l'Opérateur 32d de la figure 5 fera en sorte que la "fonction particulière" (c'est-à-dire, les informations d'événements reçues, telles que changer profondeur, changer couleur ou changer épaisseur de trait) soit affichée sur l'écran d'affichage 12a du poste de travail 10 de la figure 1.
Appeler itc hi filter and session 86
Sur la figure 26, le bloc "Appeler itc hi ilter And Session" 86 est la partie du logiciel de Lancement IH-ITC 32a de la figure 5 qui assure la fonction "interface homme-machine".
Sur la figure 5, on remarquera l'emplacement intermédiaire du logiciel de Lancement IH-ITC 32a entre le logiciel d'Affichage avec Interaction de l'Opérateur 32d, qui affiche les icônes et les informations d'événements, et le logiciel "Envoyer Un Evénement" 32b qui envoie des informations d'événements vers d'autres applications client et le logiciel "Recevoir Un Evénement" 32c qui reçoit des informations d'événements en provenant de celles-ci.
Sur la figure 26, du fait que le bloc "Appeler itc hi Filter And Session" 86 fait partie intégrante du logiciel de Lancement IH-ITC 32a, il est évident compte tenu de l'emplacement intermédiaire du logiciel de Lancement IH-ITC 32a de la figure 5 (situé entre le logiciel d'Affichage avec Interaction de l'Opérateur 32d et les logiciels "Envoyer Un Evénement" 32b et "Recevoir Un Evénement" 32c) que le bloc "Appeler itc~hi~Filter And Session" 86 du logiciel de Lancement IH-ITC 32a de la figure 26 fonctionnera de la même manière qu'un coordinateur entre deux extrémités pour recevoir des informations à partir d'une première extrémité et, en réponse à celles-ci, commander l'autre extrémité.
Par exemple, sur les figures 5 et 26, le bloc "Appeler itc hi ilter And Session" 86 recevra des informations d'événements en provenance du logiciel "Recevoir
Un Evénement" 32c (les informations d'événements provenant d'une autre application client et étant associées à un événement X) et, en réponse à celles-ci, commandera le logiciel d'Affichage avec Interaction de l'Opérateur 32d pour afficher les informations d'événements associées à l'événement X sur l'écran d'affichage 12a de la figure 1 pour une application client particulière.
Dé plus, sur les figures 5 et 26, le bloc "Appeler itc hi ilter And Session" 86 recevra des informations d'événements (par exemple, paramètres, couleur, épaisseur, taille de police modifiés) à partir du logiciel d'Affichage avec Interaction de l'Opérateur 32d d'une application client particulière et, en réponse à celles-ci, commandera le logiciel "Envoyer Un Evénement" 32b qui ordonnera en outre à la Structure ITC 34 d'envoyer les informations d'événements mentionnées ci-dessus aux autres applications client intéressées.
Par conséquent, le bloc "Appeler itc hi Filter
And Session" 86 établira toutes les connexions c'est-à-dire : il enverra tous les objets d'intérêt à partir de la "Liste d'Evénements ITC" 80 d'une application client particulière vers le serveur 26c2 pour que ceux-ci soient en outre transmis aux autres applications client ; il associera les informations d'événements re çues en provenance des autres applications client à une fonction particulière 82, 84 de la figure 26 dans une application client particulière pour exécuter cette fonction particulière dans l'application client particu lière ; il amènera le logiciel d'Affichage avec Interaction de l'Opérateur 32d à construire les diverses icônes (icônes d'état 60, icône de diffusion 62, icône de filtre à événements 64) à afficher dans une application client particulière sur l'écran d'affichage 12a ; et il indiquera une application client particulière à la Structure ITC (Noyau ITC) 34 de la figure 5 qui, à son tour, indiquera au serveur 26c2 que l'application client particulière est intéressée par la pluralité d'événements qui sont énumérés dans la liste "Liste d'Evénements ITC" 80 de la figure 26.
*Fonction d'appel à diffusion 88
Sur la figure 26, le bloc "Fonction d'appel à diffusion" 88 du logiciel de Lancement IH-ITC 32a de la figure 5 est associé au bloc "Appeler itc~hi~Filter And
Session" 86. Pour expliquer la fonction du bloc "Fonction d'appel à diffusion" 88, il est nécessaire de rappeler la fonction de l'icône de diffusion 62 de la figure 14.
Lorsqu'un opérateur clique "sur" l'icône de diffusion 62 pour une application client particulière 12b au niveau d'un poste de travail 10 en utilisant la souris 18, dans la plupart des cas, la totalité des événements d'une pluralité d'événements nouvellement créés dans l'application client particulière, qui ont été produits par un opérateur au niveau du poste de travail 10 pendant une période de temps donnée après avoir cliqué "sur" 1 icone d'état fermé 60b, seront simultanément transmis à partir de l'application client particulière à toutes les autres "applications client intéressées" s'exécutant sur le réseau de postes de travail.
Par exemple, pour une application client particulière dans laquelle des événements particuliers constitués d'événements de couleur, d'événements de taille de police, et d'événements d'épaisseur de trait, peuvent être transmis à d'autres applications client et reçus en provenance de celles-ci, lorsque l'opérateur de l'application client particulière clique "sur" l'icône de diffusion 62 après l'écoulement d'une période de temps donnée après avoir cliqué "sur" l'icône d'état fermé 60b, dans la plupart des cas, des informations d'événements associées à tous les événements particuliers seront transmises aux autres applications client.
Cependant, le bloc "Fonction d'appel à diffusion" 88 permettra au développeur d'une application client particulière de décider si oui ou non des informations associées à "tous" les événements particuliers seront transmises aux autres applications client lorsque l'opérateur cliquera "sur" l'icône de diffusion 62. Plus particulièrement, en utilisant la "Fonction d'appel à diffusion" 88, des informations d'événements associées à "certains" des événements particuliers (qui ont été nouvellement créés dans l'application client particulière après que -l'opérateur ait cliqué "sur" l'icône d'état fermé) seront transmises aux autres applications client lorsque l'opérateur cliquere "sur" l'icône de diffusion 62.
Sur les figures 5 et 26, lorsque l'opérateur clique "sur" l'icone de diffusion 62 pour une application client particulière après l'écoulement d'une période de temps donnée après avoir cliqué "sur" l'icône d'état fermé 60b, le logiciel d'Affichage avec Interaction de l'Opérateur 32d de la figure 5 pour cette application client particulière avertitra au logiciel de Lancement
IH-ITC 32a de la figure 5 que l'opérateur a cliqué "sur" l'icône de diffusion 62. En réponse, le bloc "Appeler itc hi Filter And Session" 86 du logiciel de Lancement
IH-ITC 32a de la figure 26 se référera au bloc "Fonction d'appel à diffusion" 88 du logiciel de Lancement IH-ITC 32a et l'appellera.
On suppose qu'une "pluralité d'événements nouvellement créés" ont été pratiqués et exécutés par l'application client particulière entre l'instant où l'opérateur exécutant l'application client particulière a cliqué "sur" l'icône d'état fermé 60b et l'instant où celui-ci a cliqué "sur" l'icône de diffusion 62.
Le bloc "Fonction d'appel à diffusion" 88 déterminera si "tous" les événements ou "certains" des événements de la "pluralité d'événements nouvellement créés" seront transmis aux autres applications client en réponse à l'activation de l'icône de diffusion 62 par l'opérateur exécutant l'application client particulière. Le bloc "Fonction d'appel à diffusion" 88 déterminera combien d'événements parmi la "pluralité d'événements nouvellement créés" (c'est-à-dire, certains, tous, ou aucun) seront transmis aux autres applications client.
Sur les figures 5 et 26, en utilisant l'exemple ci-dessus, pour une application client particulière dans laquelle des événements particuliers, constitués d'événements de couleur, d'événements de taille de police, et d'événements d'épaisseur de trait, peuvent être transmis vers d'autres applications client et reçus en provenance de ces dernières, lorsque l'opérateur de l'application client particulière clique "sur" l'icône de diffusion 62 après l'écoulement d'une période de temps donnée après avoir cliqué "sur" l'icône d'état fermé 60b et lorsque le logiciel d'Affichage avec Interaction de l'Opérateur 32d de la figure 5 avertit au logiciel de Lancement IH-ITC 32a que l'icône de diffusion 62 a été activée, le bloc "Appeler itc hi Filter And Session" 86 appelle et extrait le bloc "Fonction d'appel à diffusion" 88 du logiciel de
Lancement IH-ITC 32a, et, en réponse à ceci, le bloc "Fonction d'appel à diffusion" 88 peut demander que les informations d'événements associées à seulement certains des événements, tels qu'aux événements de couleur seulement par exemple, soient transmises aux autres applications client.
Appeler itc hi delete 90
Sur les figures 5 et 26, lorsque l'application client particulière cesse de s'exécuter (c'est-à-dire, lorsque l'opérateur au niveau du poste de travail 10 ferme une fenêtre 12b représentant l'application client particulière), le logiciel d'Affichage avec Interaction de l'Opérateur 32d de la figure 5 en avertit le logiciel de Lancement IH-ITC 32a. En réponse, le bloc "Appeler itc~hi~Delete" 90 du logiciel de Lancement IH-ITC 32a en avertit la Structure ITC 34 et la Structure ITC 34 avertit le serveur 26c2 que l'application client particulière est fermée. En réponse, le serveur 26c2 supprime l'enregistrement d'une partie ou de tous les objets d'intérêt mémorisés dans celui-ci qui sont associés à l'application client particulière, et, ensuite, le serveur 26c2 en avertit toutes les autres applications client. En réponse, les autres applications client suppriment l'enregistrement des intérêts exprimés par l'application client particulière dans certains événements enregistrés précédemment. En résultat, les autres applications client n'enverront aucune information d'événements correspondant aux événements préalablement enregistrés à l'application client particulière.
Sur la figure 27, le code de programme réel qui correspond au logiciel de Lancement IH-ITC 32a des figures 5 et 26 est illustré.
En se reportant aux figures 28 et 29, la construction détaillée et le fonctionnement du logiciel "Envoyer Un Evénement" 32b de la figure 5 sont illustrés.
Sur la figure 28, le bloc "Envoyer Un Evénement" 32b de la figure 5 inclut deux blocs de code : (1) "Chercher Structure de Données à Envoyer" 92, et (2) "Appeler itc hi Transmit Event" 94. Chacun de ces blocs de code sera décrit individuellement.
Chercher structures de données à envoyer 92
Sur la figure 28, le bloc de code "Chercher
Structure de Données à Envoyer" 92 répond à trois types différents de données d'entrée : (1) des données d'entrée résultant d'une interaction utilisateur, (2) des données d'entrée provenant d'une Base de Données, et (3) des données d'entrée provenant d'un Flux d'E/S (entrée/sortie).
Sur les figures 5 et 28, le logiciel d'Affichage avec Interaction de l'Opérateur 32d répond aux modifications qui sont apportées à une application client particulière par un opérateur assis au niveau d'un poste de travail 10 de la figure 1 en produisant des données d'entrée du type "interaction utilisateur" qui sont ensuite entrées sur le bloc de code "Chercher Structure de
Données à Envoyer" 92 associé au logiciel "Envoyer Un
Evénement" 32b. Par exemple, lorsque l'opérateur assis au niveau du poste de travail 10 de la figure 1 travaille avec une application client particulière, telle que représentée par l'un des affichages à fenêtres 12b de la figure 1, l'opérateur peut changer la couleur, ou la taille de police, ou il peut apporter d'autres modifications à l'application client particulière. Si ces modifications se trouvent dans la liste d'événements du bloc "Construire Liste d'Evénements ITC" 80 de la figure 26 et lorsqu'une autre application client a demandé des informations d'événements associées à ces modifications, le logiciel d'Affichage avec Interaction de l'Opérateur 32d de la figure 5 répond aux modifications apportées par l'opérateur à l'application client particulière en avertissant le logiciel de Lancement IH-ITC 32a.
Le bloc "Appeler itc hi Filter And Session" 86 du logiciel de Lancement IH-ITC 32a fournit ls.infprma- tions suivantes au bloc "Chercher Structure de Données à
Envoyer" 92 du logiciel "Envoyer Un Evénement" 32b de la figure 28 : (1) le nom de l'événement qui est associé aux modifications mentionnées ci-dessus qui ont été apportées par l'opérateur à l'application client particulière, et (2) les données ou les informations d'événements qui sont associées à l'événement dénommé mentionné ci-dessus.
Cependant, il existe deux autres origines possibles quant aux informations (nom de l'événement, et données ou informations d'événements associées à l'événement dénommé) que fournit le logiciel de Lancement IH-ITC 32a au bloc "Chercher Structure de Données à Envoyer" 92 du logiciel "Envoyer Un Evénement" 32b de la figure 28 (1) données d'entrée provenant d'une Base de données, et (2) données d'entrée provenant d'un Flux d'E/S.
Appeler itc hi transmit event 94
On va maintenant décrire le bloc "Appeler itc~hi~Transmit Event" 94.
Sur la figure 28, lorsque le bloc "Chercher
Structure de Données à Envoyer" 92 du logiciel "Envoyer
Un Evénement" 32b de la figure 28 reçoit (1) le nom de l'événement qui est associé aux modifications qui ont été apportées par l'opérateur à l'application client particulière, et (2) les données ou les informations d'événements qui sont associées à l'événement dénommé mentionné ci-dessus, un appel au logiciel "itc hi~Transmit Event" 94 est effectué. Le logiciel "itc hi Transmit Event" 94 transmettra le nom de l'événement et les données ou les informations d'événements, associées à cet événement dé nommé, à la Structure ITC (Noyau ITC) 34 de l'application client particulière des figures 4 et 5. Par exemple, pour un événement de profondeur, les données de profondeur et le nom d'événements de profondeur seront envoyés, par le logiciel "itc hi Transmit Event" 94, à la Structure ITC (Noyau ITC) 34. Pour un événement de couleur, les nouvelles données de couleur et le nom de l'événement de couleur seront envoyés, par le logiciel "itc hi Transmit
Event" 94, au Noyau ITC 34.
Sur la figure 29, le code de programme réel qui correspond au logiciel "Envoyer Un Evénement" 32b des figures 5 et 28 est illustré.
En se reportant aux figures 30 et 31, la construction détaillée et le fonctionnement du logiciel "Recevoir Un Evénement" 32c de la figure 5 sont illus trés.
Sur la figure 30, on suppose qu'une l'application client particulière envoie une pluralité d'objets d'intérêt aux autres applications client via le serveur 26c2, et qu'une ou plusieurs des autres applications client vont, en réponse, envoyer les événements demandés directement à l'application client particulière via la ligne 40 sur la figure 6. La Structure ITC (connue aussi comme "Noyau ITC") 34 associée à l'application client particulière recevra l'événement ou les plusieurs événements à partir de la ligne 40 de la figure 6 en provenance des autres applications client.
Appeler fonction de réception 96.
Sur les figures 5 et 30, la Structure (Noyau)
ITC 34 de l'application client particulière va entrer les événements reçus (qui sont reçus en provenance des autres applications client via la ligne 40 de la figure 6) sur le logiciel "Recevoir Un Evénement" 32c de la figure 5.
Le logiciel "Recevoir Un Evénement" 32c de la figure 5 inclut un bloc de code qui sera appelé par la suite code "Appeler Fonction de Réception" 96.
On rappelle d'après les figures 26 et 26A que le bloc 82, mémorisé dans le logiciel de Lancement IH-ITC 32a de la figure 5 d'une application client particulière et qui est appelé "Construire Liste d'Evénements ITC", a mémorisé une liste d'événements, une liste de fonctions correspondant respectivement à la liste d'événements, et une liste d'objets d'intérêt correspondant respectivement à la liste d'événements et à la liste de fonctions. Le code "Appeler Fonction de Réception" 96 du logiciel "Recevoir Un Evénement" 32c des figures 5 et 30 compare les événements reçus (reçus en provenance des autres applications client via le Noyau ITC 34) à la pluralité d'événements énumérés dans le bloc "Construire Liste d'Evénements ITC" 80, mémorisés dans le logiciel de Lancement IH-ITC 32a de l'application client particulière, et, lorsqu'une ou plusieurs coïncidences sont trouvées entre un événement reçu et un événement mémorisé dans le bloc "Construire Liste d'Evénements ITC" 80, le code "Appeler Fonction de Réception" 96 amène les fonctions particulières (82, 84 de la figure 26) associées aux événements coïncidents à être exécutées par le processeur (24a, 26a de la figure 3) de l'application client particulière. Sur la figure 30, lorsque les fonctions associées aux événements coïncidents sont exécutées par le processeur de l'application client particulière, l'application client particulière réagit en conséquence, comme indiqué par le bloc "Application pour Réagir" 98 de la figure 30 ; c'est-à-dire que les fonctions seront affichées sur la fenêtre 12b de l'écran d'affichage 12a.
Sur la figure 31, le code de programme réel qui correspond au logiciel "Recevoir Un Evénement" 32c des figures 5 et 30 est illustré.
En se reportant à la figure 32, un Modèle de
Sessions de Communication Inter-tâche (ITC) est illustré.
Sur la figure 1, un poste de travail 10 est illustré, celui-ci comportent un écran d'affichage 12a affichant une pluralité de fenêtres 12b différentes. Du fait que chaque fenêtre 12b représente un programme d'application client 10 différent s' exécutant dans le poste de travail, un poste de travail 10 unique peut par conséquent exécuter simultanément une pluralité de programmes d'application client 20 différents. Sur la figure 2, la pluralité de fenêtres 12b différentes ou de programmes d'application client 20 différents affichés sur l'écran d'affichage 12a pourraient inclure ou être constitués d'une pluralité d'applications client 20 différentes, telles que modelling (modélisation) ou cross view (vue en coupe) ou map view (vue de carte) ou 3D view (vue 3D) ou seismic (sismique) ou well view (vue de puits) ou ELAN ou litho ou Bor view.
La figure 32 illustre la pluralité d'applications client 20 différentes s' exécutent dans le poste de travail 10. Par exemple, sur la figure 32, une première application client 100, une deuxième application client 102 et une troisième application client 104 peuvent s'exécuter simultanément dans le poste de travail 10 de la figure 1. Un gestionnaire de données de programme d'application 106 gère les applications client 100, 102, 104 qui s exécutent concurremment. Les applications client 100, 102, 104 peuvent être à l'écoute (108) d'objets d'intéret reçus en provenance d'une autre application client via le serveur 26c2, et, lorsque les objets d'intérêt associés à un événement particulier sont reçus par les applications client 100, 102, 104, les applications client 100, 102, 104 envoient (110) l'événement particulier directement à l'autre application client (mais non par l'intermédiaire du serveur).
Une description fonctionnelle des opérations du
Procédé et du Dispositif à Structure Distribuée de la présente invention pour les Communications Inter-tâches entre Applications sur Poste de Travail est proposée dans les paragraphes qui vont suivre en référence aux figures 1 à 31 des dessins.
On suppose qu'une pluralité de postes de travail, similaires au poste de travail 10 de la figure 1, sont interconnectés ensemble de la manière représentée sur la figure 2. Chaque poste de travail 10 de la pluralité comporte au moins un affichage à fenêtres 12b présenté à l'opérateur sur l'écran d'affichage 12a du poste de travail 10. Chaque affichage à fenêtres 12b sur chaque poste de travail 10 est produit par le logiciel d'Affichage avec Interaction de l'Opérateur 32d de la figure 5 d'un "programme d'application client" (connu autrement en tant que "application client") et chaque application client peut présenter à un opérateur, assis devant le poste de travail 10, une représentation fonctionnelle différente. Par exemple, comme représenté sur la figure 2, une première application client 20 peut présenter à l'opérateur présent au niveau du poste de travail 10 une représentation fonctionnelle adaptée à la modélisation, une autre application client 20 peut présenter à l'opérateur une représentation fonctionnelle de "Cross View", et une autre peut présenter à l'opérateur une représentation fonctionnelle de "Map View" ou "3D View" ou "Seismic" ou "Well View" ou "ELAN" ou "Litho" ou "Bor View". Par conséquent, comme indiqué sur la figure 2, une pluralité d'applications client 20 différentes sont interconnectées ensemble par le procédé et le dispositif à "Structure
Distribuée" de la présente invention adaptés pour permettre une communication inter-tâche entre applications sur poste de travail.
L'un des postes de travail 26 de la figure 3, représentant une première application client 20 de la figure 2, mémorise le serveur 26c2, ainsi que sa propre application client particulière 26cl, comme représenté sur la figure 3, et l'autre poste de travail 24, représentant une autre application client 20 de la figure 2, mémorise sa propre application client particulière 24cl de la figure 3.
On suppose qu'un opérateur au niveau d'un poste de travail 24 de la figure 3 visualise la diagraphie 12b représentée sur la figure 16 sur un affichage à fenêtres 12b de l'écran d'affichage 12a de la figure 1, la diagraphie 12b de la figure 16 incluant l'icône d'état fermé 60b, l'icône de diffusion 62, et 1 icone de filtre à événements 64 apparaissant dans le coin inférieur droit de la diagraphie 12b. L'opérateur ne clique pas "sur" l'icône d'état fermé 60b, et l'opérateur ne clique pas "sur" l'icône de diffusion 62 ni sur l'icône de filtre à événements 64. En résultat, "la porte est ouverte" pour l'opérateur ; c'est-à-dire que tous les événements préalablement demandés auprès d'autres applications client seront reçus par l'application client diagraphie 12b à partir des autres applications client, et tous les événements créés par l'opérateur sur l'application client diagraphie 12b, qui ont précédemment été demandés par les autres applications client, seront envoyés par l'application client diagraphie 12b vers les autres applications client intéressées.
En résultat, lorsque l'affichage à fenêtres 12b, sur l'écran d'affichage 12a du poste de travail 24 de la figure 3 affichant l'application client diagraphie 12b de la figure 16, est appelé par l'opérateur, le logiciel d'Affichage avec Interaction de l'Opérateur 32d de la figure 5 : (1) affiche l'application client diagraphie 12b de la figure 16 dans la fenêtre 12b de l'écran d'af fichage 12a du poste de travail 24 de la figure 3, et (2) ordonne au bloc "Appeler itc hi Filter And Session" 86 de la figure 26 du logiciel de Lancement IH-ITC 32a de la figure 5 d'envoyer les objets d'intérêt 80b de la figure 26A, associés à la pluralité d'événements 80a contenus dans la "liste d'événements ITC" 80 du logiciel de Lancement IH-ITC 32a de la figure 5, au logiciel "Envoyer Un
Evénement" 32b de la figure 5. Le logiciel "Envoyer Un
Evénement" 32b, à son tour, envoie les objets d'intérêt 80b à la Structure ITC 34 de l'application client 24cl associée à la diagraphie 12b de la figure 5. La Structure
ITC 34 de l'application client 24cl associée à la diagraphie 12b envoie les objets d'intérêt 80b au serveur 26c2 via la ligne 36 de la figure 6. Le serveur 26c2 enregistre les objets d'intérêt dans celui-ci et envoie les objets d'intérêt à toutes les autres applications client 20 de la figure 2 incluant l'application client 2 26cl représentée sur la figure 6. La Structure ITC 34 de l'application client 2 26cl envoie les objets d'intérêt reçus au logiciel "Recevoir Un Evénement" 32c de la figure 5, qui, à son tour, envoie les objets d'intérêt reçus vers le bloc "Appeler itc hi Filter And Session" 86 de la figure 26 du logiciel de Lancement IH-ITC 32a de la figure 5 de l'application client 2 26cl. Le bloc "Appeler itc hi Filter And Session" 86 de l'application client 2 26cl compare les objets d'intérêt reçus aux objets d'intérêt 80b mémorisés dans la "Liste d'Evénements ITC" 80 des figures 26 et 26A de l'application client 2. Lorsqu une coïncidence est trouvée entre un objet d'intérêt reçu et l'un des objets d'intérêt 80b de la figure 26A pour l'application client 2 correspondant à un événement particulier, tel qu'un "événement N", le bloc "Appeler itc hi Filter And Session" 86 envoie "l'événement N" au logiciel "Envoyer Un Evénement" 32b de la figure 5 de l'application client 2 26cl qui, à son tour, envoie "l'événement N" à la Structure ITC 34 de l'application client 2 26cl de la figure 5. La Structure ITC 34 de l'application client 2 26cl de la figure 5 envoie directement "l'événement N" vers l'application client 24cl associée à la diagraphie de la figure 6 via la ligne 40 de la figure 6 sans qu'il soit nécessaire d'enregistrer "l'événement N" avec le serveur intervenant 26c2 ni de l'y faire passer.
On suppose maintenant que l'opérateur au niveau du poste de travail 24 de la figure 3, visualisant l'application client associée à la diagraphie 12b de la figure 16 sur la fenêtre 12b de l'écran d'affichage 12a clique "sur" l'icône de filtre à événements 64 de la figure 16. L'action de "cliquer sur" l'icône de filtre à événements 64 de la figure 16 fait apparaître la sous-fenêtre 64a de l'icône de filtre à événements sur les figures 15c, 15d et 15e. La sous-fenêtre 64a comporte une pluralité d'événements énumérés dans celle-ci, la pluralité d'événements étant constituée des événements (événement 1, événement 2, événement 3, ..., et événement
N) représentés sur la figure 26A.
Sur la figure 15e, on suppose que l'opérateur clique "sur" la partie "tout" 64a4 et 64a5 de la colonne "émettre" et "recevoir" 64al et 64a2 de la sous-fenêtre 64a de l'icône de filtre à événements. En résultat, lorsque l'application client 24cl associée à la diagraphie 12b envoie les objets d'intérêt de la figure 26A vers le serveur 26c2 de la figure 6 et lorsque le serveur 26c2 envoie les objets d'intérêt vers l'application client 2 26cl, l'application client 2 envoie les informations d'événements associées à l'un quelconque ou à la totalité des événements 1, ..., N directement à l'application client 1 via la ligne 40 de la figure 6, et l'application client 1 24cl reçoit tous les événements.
Inversement, lorsque l'application client 2 26cl envoie les objets d'intérêt 80b de la figure 26A au serveur 26c2 de la figure 6 et lorsque le serveur 26c2 envoie les objets d'intérêt vers l'application client 1 24cl associée à la diagraphie, l'application client 1 envoie les informations d'événements associées à l'un quelconque ou à la totalité des événements 1, ..., N directement à l'application client 2 via la ligne 40 de la figure 2, et l'application client 2 26cl reçoit tous les événements.
Cependant, on suppose que l'opérateur visualisant la sous-fenêtre 64a de l'icône de filtre à événements 64 de la figure 15e (de l'application client 24cl associée à la diagraphie 12b des figures 3 et 16 sur le poste de travail 24 de la figure 3) clique sur "envoyer" (lAl sur la figure 15e) mais non sur "recevoir" (2A1 sur la figure 15e) pour l'événement 1, mais clique à la fois sur "envoyer" (1A2, 1A3, 1A4) et sur "recevoir" (2A2, 2A3 et 2A4) pour tous les autres événements, événement 1, événement 2, ..., et événement N dans la sous-fenêtre 64a associée à l'icône de filtre à événements de la figure 15e. L'application client 24cl associée à la diagraphie envoie l'événement 1 à l'application client 2 26cl de la figure 3 via la ligne 40 de la figure 6 (lorsque l'application client 2 a demandé l'événement 1 à partir de l'application client 1 associée à la diagraphie, via le serveur), mais l'application client 24cl associée à la diagraphie ne reçoit pas l'événement 1 en provenance de l'application client 2 26cl de la figure 3 via la ligne 40 de la figure 6 (lorsque l'application client 1 associée à la diagraphie a demandé l'événement 1 à partir de l'application client 2 via le serveur). Cependant, tous les autres événements, événement 2, événement 3, ..., et événement N, seront reçus à partir de l'application client 2 par l'application client 24cl associée à la dia graphie et seront envoyés vers l'application client 2 par l'application client 24cl associée à la diagraphie.
PARTIE 2 : Système de Communication de Données et d'Accès aux Données Intégré incluant l'interface de Données d'Application.
Dans la première partie intitulée ci-dessus "Structure Distribuée pour Communications Inter-tâches entre Applications sur Poste de Travail" (appelée par la suite "Application ITC"), un procédé et un dispositif à
Structure Distribuée ont été décrits pour permettre des communications inter-tâches directes (ITC) entre programmes d'application informatiques fonctionnant simultanément serveur avertit alors en outre à la seconde application client l'intérêt porté par la première application client aux informations d'événements. Lorsque la seconde application client pratique un événement qui produit des informations d'événements, la seconde application client envoie ces informations d'événements directement à la première application client sans d'abord enregistrer ces informations d'événements avec le serveur. A tire d'exemple, on va examiner les figures 33 à 35 qui vont permettre de revoir le concept référencé ci-dessus.
En se reportant aux figures 33 à 35, les dessins des figures 6, 8A et 9A sont à nouveau illustrés.
Sur la figure 33, une application client 1 24cl envoie un objet d'intérêt, via la ligne 36, au serveur 26c2 demandant la réception de certaines informations d'événements lorsque l'application client 2 26cl pratique un événement qui produit ces informations d'événements.
Le serveur 26c2 transmet cette demande, via la ligne 38, directement à l'application client 2 26cl. Lorsque l'application client 2 26cl pratique un événement qui produit ces informations d'événements demandées, l'application client 2 26cl envoie les informations d'événements demandées, via la ligne 40, directement à l'application client 1 24cl sans enregistrer les informations d'événements demandées avec le serveur 26c2.
Sur la figure 34, l'application 1 (App 1) 24cl demande ces informations d'événements en envoyant l'objet d'intérêt, via la ligne 46, au serveur 26c2, et le serveur 26c2 transmet cet objet d'intérêt à l'application 2 (App 2) 26cl via la ligne 48, à l'application 3 (App 3) 42 via la ligne 50, et à l'application 4 (App 4) 44 via la ligne 52.
Sur la figure 35, lorsque "App 2" 26cl pratique un événement qui produit ces informations d'événements, "App 2" 26cl transmet les informations d'événements de mandées directement à "App 1" 24cl sans d'abord enregistrer ces informations d'événements avec le serveur 26c2 (le serveur reste inactif).
En se reportant aux figures 36 à 44, le "Système de Communication de Données et d'Accès aux Données Intégré" conformément à la présente invention est illustré.
On va maintenant se reporter aux figures 36 à 39.
Sur la figure 36, un "Système de Communication de Données et d'Accès aux Données Intégré" est illustré, lequel inclut une "Interface de Données d'Application" ou "ADI" 115 qui est interconnectée fonctionnellement entre une mémoire de données ou base de données 110, une Application A (ou première application client) 24cl, et une
Application B (ou seconde application client) 26cl. l'Interface de Données d'Application 115 écrit un "Item de données X" dans la base de données 110, et exécute une fonction de rappel dans l'Application B 26cl.
Sur la figure 37, une autre construction du "Système de Communication de Données et d'Accès aux Données Intégré" de la figure 36 est illustrée. En particulier, l'Interface de Données d'Application (ADI), implémentée dans le système de la figure 37, est décrite cidessous sous l'angle de la fonction que "l'ADI" remplit dans le système de la figure 37 par rapport au transfert et à la communication de données initialement créées et ultérieurement modifiées entre une première application client et son antémémoire, une base de données, un serveur et une seconde application client et son antémémoire.
Sur la figure 37, le Système de Communication de Données et d'Accès aux Données Intégré de la figure 36 inclut une première application client 24cl qui est connectée fonctionnellement au serveur 26c2 via une con nexion fonctionnelle 36, comme mentionné précédemment. La première application client 24cl est aussi connectée fonctionnellement à la seconde application client 26cl via la connexion fonctionnelle 40. La seconde application client 26cl est aussi connectée fonctionnellement au serveur 2Gc2 via la connexion fonctionnelle 38. Lá première application client 24cl inclut une "Application 1" 111, qui communique avec le serveur 26c2, et une antémémoire (antémémoire 1) 119 connectée fonctionnellement à "l'Application 1" via l'Interface de Données d'Application (ADI) 115. "L'antémémoire 1" 119 mémorise un Objet de données 119 qui est produit par "l'Application 1".
"L'antémémoire 1" 119 qui mémorise l'Objet de Données 119 répond à une commande "créer", une commande "supprimer", une commande "placer", une commande "chercher" et une commande "sélectionner" provenant de "l'Application 1".
La seconde application client 26cl inclut aussi une "Application 2" 117 qui communique avec le serveur 26c2 et une antémémoire (antémémoire 2) 121 connectée fonctionnellement à "l'Application 2" via l'Interface de Données d'Application (ADI). "L'antémémoire 2" 121 mémorise un Objet de Données 121 qui est produit par "l'Application 2" (habituellement, l'Objet de Données dans "l'antémémoire 2" est le même que l'Objet de Données mémorisé dans "l'antémémoire 1") . "L'antémémoire 2" 121 qui mémorise l'Objet de Données répond aussi à une commande "créer", une commande "supprimer", une commande "placer", une commande "chercher" et une commande "sélectionner" provenant de "l'Application 2". Ces commandes seront décrites ultérieurement. "L'Application 1" est connectée fonctionnellement à une base de données 110 via deux connexions fonctionnelles (connexion 112 et connexion 114) dans le but de mémoriser des données dans la base de données 110 lorsque "l'antémémoire 1" est établie dans un état transitoire ou lorsque "l'antémémoire 1" est établie dans un état persistant. "L'Application 2" est aussi connectée fonctionnellement à la base de données 110 via deux connexions fonctionnelles (connexion 116 et connexion 118) dans le but de mémoriser des données dans la base de données 110 lorsque "l'antémémoire 2" est établie dans un état transitoire ou lorsque "l'antémémoire 2" est établie dans un état persistant. Lorsque "l'Application 1" mémoriser des données dans la base de données 110 pendant l'état transitoire, elle le fait via la connexion fonctionnelle 112 ; cependant, lorsque "l'Application 1" mémorise des données dans la base de données 110 pendant l'état persistant, elle le fait via la connexion fonctionnelle 114. D'une manière similaire, lorsque "l'Application 2" mémorise des données dans la base de données 110 pendant l'état transitoire, elle le fait via la connexion fonctionnelle 116 ; cependant, lorsque "l'Application 2" mémorise des données dans la base de données 110 pendant l'état persistant, elle le fait via la connexion fonctionnelle 118. Les termes transitoire et persistant seront définis ultérieurement dans la description. La base de données 110 mémorise une pluralité d'Objets de Données, incluant un Objet de Données 110a.
Habituellement, l'Objet de Données 110a contenu dans la base de données 110 est le même que l'Objet de
Données contenu dans "l'antémémoire 1" et l'Objet de Données contenu dans "l'antémémoire 2". En réponse à la commande "placer" provenant de "l'Application 1" et reçue par "l'antémémoire 1" 119 qui mémorise l'Objet de Données 119, "l'antémémoire 1" de la première application client 24cl est établie dans l'un des trois états d'enregistrement séparés : l'état d'enregistrement persistant, l'état d'enregistrement transitoire ou l'état d'enregistrement mémoire. Lorsque "l'antémémoire 1" est établie dans l'un de ces états d'enregistrement, "l'antémémoire 2" est au tomatiquement établie dans le même état d'enregistrement que "l'antémémoire 1". D'une manière similaire, en réponse à la commande "placer" provenant de "l'Application 2" et reçue par "l'antémémoire 2" 121 qui mémorise l'Objet de Données 121, "l'antémémoire 2" de la seconde application client 26cl est établie dans l'un des trois états d'enregistrement séparés référencés ci-dessus l'état d'enregistrement persistant, l'état d'enregistrement transitoire ou l'état d'enregistrement mémoire.
Lorsque "l'antémémoire 2" est établie dans l'un de ces états d'enregistrement, "l'antémémoire 1" est aussi automatiquement établie dans le même état d'enregistrement que "l'antémémoire 2".
Sur la figure 37, comme noté précédemment, les antémémoires 119, 121 qui mémorisent les premier et second Objets de Données 119, 121 sont adaptées chacune pour recevoir une commande "créer", une commande "supprimer", une commande "placer", une commande "chercher" ou une commande "sélectionner" à partir de "l'Application 1" et de "l'Application 2", respectivement. Lorsque les antémémoires 119, 121 mémorisant les
Objets de Données 119, 121 reçoivent l'une quelconque de ces commandes, "l'antémémoire 1" ou "l'antémémoire 2" répond en conséquence. Par exemple, lorsque les antémémoires 119, 121 mémorisant les Objets de Données 119, 121 reçoivent chacune la commande "placer" à partir de "l'Application 1" et de "l'Application 2", respectivement, "l'antémémoire 1" ou "l'antémémoire 2" est établie dans l'état d'enregistrement persistant, dans l'état d'enregistrement transitoire ou dans l'état d'enregistrement mémoire ; et, après l'établissement de "l'état d'enregistrement" approprié, les Objets de Données 119, 121 peuvent alors être modifiés ou changés par "l'Application 1" ou "l'Application 2".
Lorsque, en réponse à la commande "placer", "1 'Application 1" établit l'état d'enregistrement persistant, et lorsque "l'Application 1" crée ensuite un "ensemble original de données" et, ensuite, modifie ou change l'ensemble original de données pour créer des "données modifiées", à la fois "l'ensemble original de données" et les "données modifiées" sont mémorisés dans la base de données 110 via la connexion fonctionnelle 114 (du fait que l'état d'enregistrement persistant a été établi). D'autre part, lorsque, en réponse à la commande "placer", "l'Application 1" établit l'état d'enregistrement transitoire, et lorsque "l'Application 1" crée ensuite "l'ensemble original de données" et crée ensuite les "données modifiées", "l'ensemble original de données" est mémorisé dans la base de données 110 via la connexion fonctionnelle 112, cependant, les "données modifiées" ne sont pas mémorisées dans la base de données 110 (du fait que l'état d'enregistrement transitoire a été établi).
D'autre part, lorsque, en réponse à la commande "placer", "l'Application 1" établit l'état d'enregistrement mémoire, et lorsque "l'Application 1" crée ensuite "l'ensemble original de données" et crée ensuite les "données modifiées", aucune des données de "l'ensemble original de données" et aucune des "données modifiées" n'est mémorisée dans la base de données 110 (du fait que l'état d'enregistrement mémoire a été établi).
D'une manière similaire, lorsque, en réponse à la commande "placer", "l'Application 2" établit l'état d'enregistrement persistant, et lorsque "l'Application 2" crée ensuite un "ensemble original de données" et modifie ou change ensuite l'ensemble original de données pour créer des "données modifiées", à la fois "l'ensemble original de données" et les "données modifiées" sont mémorisés dans la base de données 110 via la connexion fonctionnelle 118 (du fait que l'état d'enregistrement per sistant a été établi). D'autre part, lorsque, en réponse à la commande "placer", "l'Application 2" établit l'état d'enregistrement transitoire, et lorsque "l'Application 2" crée ensuite "l'ensemble original de données" et crée ensuite les "données modifiées", "l'ensemble original de données" est mémorisé dans la base de données 110 via la connexion fonctionnelle 116, cependant, les "données modifiées" ne sont pas mémorisées dans la base de données 110 (du fait que l'état d'enregistrement transitoire a été établi). D'autre part, lorsque, en réponse à la commande "placer", "l'Application 2" établit l'état d'enregistrement mémoire, et lorsque "l'Application 2" crée ensuite "l'ensemble original de données" et crée ensuite alors les "données modifiées", aucune des données de "l'ensemble original de données" et aucune des "données modifiées" n' est mémorisée dans la base de données 110 (du fait que l'état d'enregistrement mémoire a été éta bli).
Lorsque l'antémémoire 119 ou 121 mémorisant l'Objet de Données 119 ou 121 reçoit la commande "créer", et lorsque l'état d'enregistrement persistant ou transitoire a été établi, "l'Application 1" ou "l'Application 2" crée et mémorise un autre Objet de Données 110a dans la base de données 110. Lorsque l'antémémoire 119 ou 121 mémorisant l'Objet de Données 119 ou 121 reçoit la commande "sélectionner", "l'Application 1" ou "l'Application 2" sélectionne un Objet de Données 110a mémorisé dans la base de données 110, et lorsque l'antémémoire 119, 121 mémorisant l'Objet de Données 119 ou 121 reçoit la commande "chercher", "l'Application 1" ou "l'Application 2" récupère l'Objet de Données sélectionné 110a dans la base de données 110. Lorsque l'antémémoire 119 ou 121 mémorisant les Objets de Données 119 ou 121 reçoit la commande "supprimer", "l'Application 1" ou "l'Application 2" supprime l'Objet de Données 110a de la base de données 110.
Sur les figures 38a et 38b, des schémas fonctionnels sont présentés, lesquels illustrent les définitions du transfert de données transitoire et du transfert de données persistant.
Sur la figure 38a, la définition d'un transfert de données transitoire est illustrée. Sur la figure 38a, une interface de données d'application 115 aide au transfert de données à partir d'une application source 111 et d'une antémémoire temporaire 119. Du fait que, sur la figure 38a, la fonction d'un transfert de données transitoire est illustrée, les données originales initialement créées résidant couramment dans la mémoire temporaire 119 seront écrites dans la base de données 110 ; cependant, du fait que l'on se trouve dans le mode transfert de données transitoire, aucune autre donnée modifiée correspondante ne sera écrite dans la base de données 110. Sur la figure 38a, l'ADI 115 aide aussi à la lecture des données mémorisées initialement dans la base de données 110 pour les transférer dans une autre antémémoire temporaire 121, et, à partir de la mémoire temporaire 121, vers l'application destinataire 117 pour obtenir les données modifiées via la connexion fonctionnelle 40.
Sur la figure 38b, la définition d'un transfert de données persistant est illustrée. Sur la figure 38b, une interface de données d'application 115 aide aussi au transfert de données entre une application source 111 et une antémémoire temporaire 119. Du fait que, sur la figure 38b, la fonction d'un transfert de données persistant est illustrée, les données originales initialement créées résidant couramment dans l'antémémoire temporaire 119 seront écrites dans la base de données 110 ; cependant, du fait que l'on se trouve dans le mode transfert de données persistant, toutes les autres versions modifiées correspondantes des données seront aussi écrites dans la base de données 110. Sur la figure 38b, l'ADI 115 aide aussi à la lecture des données mémorisées- initiale- ment depuis la base de données 110 vers une autre antémémoire temporaire 121, et depuis l'antémémoire temporaire 121 vers l'application destinataire 117.
Sur la figure 39, un organigramme est illustré, lequel décrit le fonctionnement du système de communication de données interactif des figures 36 et 37. En particulier, l'organigramme de la figure 39 décrit le fonctionnement de "l'Interface de Données d'Application (ADI)" implémentée d'une manière inhérente dans le système de la figure 37 qui gouverne le transfert et la communication des données initialement créées et ultérieurement modifiées par l'intermédiaire du système de la figure 37. Sur la figure 39, les étapes fonctionnelles suivantes sont suivies par le système de la figure 37, lesquelles étapes sont gouvernées par l'Interface de Données d'Application de la présente invention
(1) App 1 (111) crée un Objet de Données 110a dans une antémémoire tandis qu'elle se trouve dans le mode transitoire ou persistant, et mémorise ensuite l'Objet de Données nouvellement créé dans la base de données 110, bloc 124,
(2) App 2 (117) interroge/lit l'Objet de Données 110a dans la base de données 110, bloc 126,
(3) App 2 (117) envoie un objet d'intérêt au serveur 26c2, bloc 128,
(4) le serveur 26c2 enregistre l'intérêt exprimé par App 2 dans l'Objet de Données 110a et distribue l'objet d'intérêt à App 1 (111), bloc 130,
(5) App 1 (111) produit un Objet de Données pour l'événement "X", bloc 134,
(6) App 1 (111) envoie une notification à App 2 (117) et met à jour l'Objet de Données 110a dans la base de données 110 lorsque App 1 se trouve dans le mode persistant, bloc 136, et
(7) App 1 envoie un Objet de Donnéesmis à jour pour l'événement "X" directement à App 2, via la ligne 40, sans enregistrer l'Objet de Données mis à jour avec le serveur, bloc 138.
Chacune de ces étapes dans l'organigramme de la figure 39 va être décrite en détail dans la description qui va suivre du fonctionnement du Système de Communication de Données et d'Accès aux Données Intégré de la figure 37, le flux séquentiel des données à travers. un tel
Système étant gouverné par l'Interface de Données d'Application (ADI) de la présente invention.
Sur la figure 37, une description du fonctionnement du "Système de Communication de Données et d'Accès aux Données Intégré" de la figure 37, incluant l'Interface de Données d'Application 115 implémentée ici, va être faite dans les paragraphes qui vont suivre en référence à la figure 37.
Sur la figure 37, on suppose que "l'Application 1" de la première application client 24cl a établi l'état d'enregistrement mémoire. Tandis qu'elle se trouve dans l'état d'enregistrement mémoire, "l'Application 1" crée de "nouvelles données", mémorise ces nouvelles données dans l'antémémoire 119 sous la forme d'un Objet de Données 119, change/modifie ces nouvelles données pour créer ainsi des "données modifiées", mémorise à nouveau les données modifiées dans l'antémémoire 119 sous la forme d'un nouvel Objet de Données 119, modifie continûment les "données modifiées", créant ainsi des "données modifiées supplémentaires", et mémorise à nouveau les données modifiées supplémentaires dans l'antémémoire 119 sous la forme d'un nouvel Objet de Données supplémentaire 119. Du fait que cette fonction s'exécute après l'établissement dans l'état d'enregistrement mémoire de "l'Application 1", aucune des données nouvellement ou ultérieurement créées n'est mémorisée en tant qu'Objet de Données 110a dans la base de données 110, c'est-à-dire que les nouvelles données, les données modifiées, et les données modifiées supplémentaires ne sont pas mémorisées en tant qu'Objet de Données 110a dans la base de données 110.
On suppose maintenant que "l'Application 1" établit l'état d'enregistrement persistant ou transitoire en produisant la commande "placer" qui est reçue par l'antémémoire 119. Par conséquent, l'antémémoire 119 est maintenant établie dans l'état d'enregistrement persistant ou transitoire. Lorsque l'état d'enregistrement persistant ou transitoire est établi par "l'Application 1", on suppose que "l'Application 1" pratique un événement (appelé "événement X") et produit par conséquent un ensemble de "données originales et nouvellement créées".
Lorsque les "données originales et nouvellement créées" sont produites par "l'Application 1", du fait que l'état d'enregistrement persistant ou transitoire a été établi, l'ADI 115 répond à "l'Application 1" en mémorisent les "données originales et nouvellement créées" sous la forme de l'Objet de Données 119 dans l'antémémoire 119 de la première application client 24cl ; et, de plus, l'ADI 115 répond aussi à "l'Application 1" en mémorisant les "données originales et nouvellement créées" sous la forme de l'Objet de Données 110a dans la base de données 110.
Par conséquent, les Objets de Données 119 et 110a ont tous deux été créés en réponse à la fonction de l'ADI 115, et comme résultat direct de celle-ci, en réponse à la pratique de l'événement X par "l'Application 1" pendant l'établissement de ltétat d'enregistrement persistant ou transitoire. Cependant, si l'état d'enregistrement mémoire avait été établi, l'ADI 115 aurait mémorisé les "données originales et nouvellement créées" dans l'antémémoire 119 sous la forme de l'Objet de Données 119 ; mais l'ADI 115 n'aurait pas mémorisé les "données originales et nouvellement créées" dans la base de données 110 sous la forme de l'Objet de Données 110a.
Si "l'Application 1" établit l'état d'enregistrement persistant, "l'antémémoire 1" et "l'antémémoire 2" sont toutes deux établies dans l'état d'enregistrement persistant. En résultat, la connexion fonctionnelle 118 indicative de l'état d'enregistrement persistant est maintenant ouverte et "l'Application 2" de la seconde application client 26cl peut mettre à jour l'Objet de Données 110a dans la base de données 110 à chaque fois que l'Objet de Données 110a est changé ou modifié par "l'Application 2". "L'Application 2" de la seconde application client 26cl interroge la base de données 110, via la connexion fonctionnelle 118, et remarque que l'Objet de Données 110a (qui a été mémorisé précédemment dans la base de données 110 par "l'Application 1") existe et est mémorisé dans la base de données 110. Lorsque "l'Application 2" remarque cet Objet de Données 110a, "l'Application 2" de la seconde application client 26cl devient intéressée par la réception d'une quantité plus importante de données associées à cet Objet de Données 110a à partir de "l'Application 1" de la première application client 24cl à chaque fois que "l'Application 1" pratique à nouveau ou continue de pratiquer "l'événement
X" qui a créé l'Objet de Données 110a dans la base de données 110. En résultat, "l'Application 2" de la seconde application client 26cl envoie un objet d'intérêt au serveur 26c2 via la connexion fonctionnelle 38. Le serveur 26c2 enregistre cet objet d'intéret en provenance de "l'Application 2" et transmet cet objet d'intérêt à "l'Application 1" de la première application client 24cl via la connexion fonctionnelle 36. A chaque fois que "l'Application 1" de la première application client 24cl pratique à nouveau "l'événement X" en créant ainsi des "données nouvellement mises à jour", les "données nouvel lement mises à jour" associées à la pratique de "l'événement X" sont transmises directement à partir de "l'Application 1" à "l'Application 2" via la connexion fonctionnelle 40 de la figure 37, sans passer par le.serveur 26c2 ni y être enregistrées.
On suppose maintenant que "l'Application 1" de la première application client 24cl établit l'état d'enregistrement persistant en produisant la commande "placer" qui est reçue par l'antémémoire 119. En résultat, "l'antémémoire 1" et "l'antémémoire 2" sont toutes deux établies dans l'état d'enregistrement persistant. On suppose maintenant que "l'Application 1" de la première application client 24cl commence à pratiquer "l'événement
X". Pendant la pratique de "l'événement X" par "l'Application 1", certaines "données originales et nouvellement créées" sont produites par "l'Application 1" et certaines "données ultérieurement modifiées supplémentaires" sont produites ensuite par "l'Application 1". En d'autres termes, pendant la pratique de "l'événement X" par "l'Application 1", les données résultant de la pratique de l'événement X changent constamment. Du fait que "l'Application 1" de la première application client 24cl est établie dans l'état d'enregistrement persistant, l'ADI 115 répond à "l'Application 1" en mémorisant les "données originales et nouvellement créées" en tant qu'Objet de Données 110a dans la Base de Données 110 via la connexion fonctionnelle 114, et l'ADI réagit en outre à "l'Application 1" en mémorisant en outre les "données ultérieurement modifiées supplémentaires" en tant qu'Objet de Données 110a dans la Base de Données 110 via la connexion fonctionnelle 114.
On suppose maintenant que "l'Application 1" de la première application client 24cl établit l'état d'enregistrement transitoire en produisant la commande "placer" qui est reçue par l'antémémoire 119 qui mémorise l'Objet de Données 119. En résultat, "l'antémémoire 1" et "l'antémémoire 2" sont toutes deux établies dans l'état d'enregistrement transitoire. Du fait que "l'antémémoire 1" est établie dans l'état d'enregistrement transitoire, à chaque fois que des "données originales et nouvellement créées" sont produites par "l'Application 1" du fait de la pratique par "l'Application 1" de "l'événement X", l'ADI 115 répond à "l'Application 1" en mémorisant ces "données originales et nouvellement créées" en tant qu'Objet de Données 110a dans la Base de Données 110 via la connexion fonctionnelle 112. Cependant, pendant la pratique continue de "l'événement X" par "l'Application 1", des "données modifiées et ultérieurement créées" sup- plémentaires sont produites par "l'Application 1". Du fait que "l'antémémoire 1" est établie dans l'état d'enregistrement transitoire, l'ADI 115 répond à "l'Application 1" en ne mémorisant aucune des "données modifiées et ultérieurement créées" en tant qu'Objet de
Données 110a dans la Base de Données 110.
On suppose maintenant que "l'Application 1" établit l'état d'enregistrement mémoire en produisant la commande "placer" qui est reçue par l'antémémoire 119. Du fait que "l'antémémoire 1" est établie dans l'état d'enregistrement mémoire, si des "données originales nouvellement créées" sont produites par "l'Application 1", et si des "données ultérieurement modifiées supplémentaires" sont produites par "l'Application 1", aucune des "données originales nouvellement créées" et aucune des "données ultérieurement modifiées supplémentaires" n'est mémorisée dans la Base de Données 110 en tant qu'Objet de Données 110a.
On va maintenant se reporter aux figures 40 à 44.
Sur la figure 40, un port 142 est connecté fonctionnellement à une antémémoire 144 (il peut s'agir aussi d'une mémoire tampon) qui mémorise un Objet de Données 144, et l'Objet de Données 144 est connecté fonctionnellement à une Base de Données 110. Le port 142 inclut un convertisseur 142a. Le port 142 répond à une commande de lecture, au niveau d'une borne 142b, et à une commande d'écriture au niveau d'une borne 142c. Le port 142 est un manipulateur opaque qui peut être utilisé pour accéder à des structures associées. Il s'agit d'un type spécial de manipulateur de fichiers dans lequel le manipulateur lui-même contient toutes les informations pour accéder aux données. Le port 142 est décrit d'une manière détaillée dans la "Description Détaillée du Mode Préféré de Réalisation" faite ci-après. Le port 142 se trouve toujours dans l'état d'enregistrement mémoire, comme indiqué par la référence numérique 146 sur la figure 40.
Sur la figure 41, le port 142 inclut un convertisseur 142a. Le port 142 est adapté pour transférer des données entre une borne de sortie 148 (qui interconnecte fonctionnellement le port 142 et l'antémémoire 144 qui mémorise l'Objet de Données 144) et la borne de commande de lecture 142b ou la borne de commande d'écriture 142c.
Lorsque les données sont transférées entre la borne de sortie 148 et la borne de commande de lecture 142b ou la borne de commande d'écriture 142c, les données sont soumises à un traitement de conversion à l'intérieur du convertisseur 142a. Par exemple, si les données sont trans
I férées à partir de la borne de sortie 148 et vers la borne de commande de lecture 142b, les données sont converties, par le convertisseur 142a, à partir d'un format
A (au niveau de la borne 148) en un format B (au niveau de la borne 142b) ; cependant, si les données sont transférées à partir de la borne de commande d'écriture 142c vers la borne de sortie 148, les données sont reconverties, par le convertisseur 142a, du format B (borne 142c) au format A (borne 148). être converties d'une unité de mesure métrique en une unité de mesure anglaise ou canadienne. La signification de cette fonction va devenir évidente à la lecture de la description fonctionnelle qui va suivre du . du.Système de
Communication de Données et d'Accès aux Données Intégré de la présente invention, qui inclut l'Interface de Données d'Application 115, en référence aux figures 42 à 44.
Sur la figure 42, une construction plus détaillée du convertisseur 142a du port 142 de la figure 41 est illustrée. Sur la figure 42, lorsque les données sont transférées entre la borne de sortie 148 et la borne de commande de lecture 142b ou la borne de commande d'écriture 142c, les données passent à travers une pluralité d'unités de conversion, telles que décrites ci-après les données passent à travers une unité de conversion 142au constituée d'une porte, une unité de conversion 142a2 constituée d'un filtre, une unité de conversion de coordonnées 142a3, une unité de conversion de type de valeur d'unité 142a4 et/ou une unité de conversion utilisateur 142a5. Chacune de ces unités de conversion 142al à 142a5 est décrite en détail dans la "Description Détaillée du Mode Préféré de Réalisation" faite ci-dessous.
Sur la figure 43, à titre d'exemple, des données provenant d'un "domaine de données" sont écrites sur le port 142 via la borne de commande d'écriture 142c.
Lorsque ces données sont écrites sur le port 142 via la borne de commande d'écriture 142c, ces données sont soumises à une première conversion dans l'unité de conversion 142al constituée d'une porte définie par l'utilisateur ; ensuite, les données sont soumises à une deuxième conversion dans l'unité de conversion 142a2 constituée d'un filtre ; ensuite, les données sont soumises à une troisième conversion dans l'unité de conversion de type de valeur d'unité 142a4 ; et, ensuite, les données sont soumises à une quatrième conversion dans l'unité de con version utilisateur 142a5. Après que les données ont été soumises à une conversion dans l'unité de conversion utilisateur 142a5, les données converties passent dans l'antémémoire 144 qui mémorise l'Objet de Données 144. via la borne de sortie 148. Un exemple de conversion typique exécutée par le convertisseur 142a du port 142, similaire à la conversion décrite ci-dessus sur les figures 42 et 43, va être décrit ci-dessous en référence à la figure 44 des dessins.
Sur la figure 44, le Système de Communication de Données et d'Accès aux Données Intégré de la figure 37 est à nouveau illustré ; cependant, sur la figure 44, la première application client 24cl et la seconde application client 26cl du Système de Communication de Données et d'Accès aux Données Intégré comportent en outre chacune le dispositif de la figure 40, c'est-à-dire le port 142 incluant le convertisseur 142a connecté fonctionnellement à l'antémémoire 119, 121 qui mémorise l'Objet de
Données 119, 121. Par exemple, la première application client 24cl inclut un "port 1" 142 (incluant un "convertisseur 1" 142a) connecté fonctionnellement à l'antémémoire (antémémoire 1) 119 qui mémorise l'Objet de
Données 119, et la seconde application client 26cl inclut un "port 2" 142 (incluent un "convertisseur 2" 142a) connecté fonctionnellement à l'antémémoire (antémémoire 2) 121 qui mémorise l'Objet de Données 121. De plus, une "fonction" 120 est associée à "l'antémémoire 1" 119, et une "fonction" 122 est associée à "l'antémémoire 2" 121.
Le but de la "fonction" 120, 122 dans le Système de Communication de Données et d'Accès aux Données Intégré de la figure 44 apparaîtra évident à la lecture de la description qui va suivre du fonctionnement de la présente invention.
Une description du fonctionnement du Système de
Communication de Données et d'Accès aux Données Intégré de la figure 44, incluant la fonction de l'Interface de
Données d'Application (ADI) 115, va être faite dans les paragraphes qui vont suivre en référence à la figure 44.
Sur la figure 44, on suppose que la première application client 24cl est utilisée en un premier lieu sur la terre où l'on utilise un premier système de mesure pour exprimer les données (par exemple, l'unité de mesure anglaise) et que la seconde application client 26cl est utilisée en un second lieu sur la terre où l'on utilise un second système de mesure pour exprimer les données (par exemple, l'unité de mesure canadienne). La première application client 24cl est un programme d'application à fenêtres présenté à un premier opérateur assis au niveau d'un premier poste de travail installé dans le premier lieu sur la terre, et la seconde application client 26cl est un autre programme d'application à fenetres présenté à un second opérateur assis au niveau d'un second poste de travail installé dans le second lieu sur la terre.
"L'Application 1" 111 de la première application client 24cl représente un programme d'application particulier qui est exécuté ; et, pendant l'exécution de "l'Application 1", un certain type de données est demandé par le premier opérateur visualisant la première application client 24cl. Pendant l'exécution de "l'Application 1", un "événement" est pratiqué par "l'Application 1".
Pour obtenir le certain type de données demandé, le premier opérateur visualisant la première application client 24cl fournit ce certain type de données en écrivant un "premier type de données exprimées avec les unités de mesure anglaises", via la borne de commande d'écriture 142c, sur le "port 1" 142 de la première application client 24cl. Le convertisseur 142a du "port 1" 142 reçoit le "premier type de données exprimées avec les unités de mesure anglaises" et convertit le "premier type de données exprimées avec les unités de mesure anglaises" en un "premier type de données exprimées avec les unités de mesure métriques". Le "port 1" 142 dans la première application client 24cl a déjà été établi dans l'état d'enregistrement mémoire en réponse à la commande "placer" re çue par le "port 1" 142. Le "premier type de données exprimées avec les unités de mesure métriques", qui est délivré en sortie par le "port 1" 142, est entré sur "l'antémémoire 1" l19,et est mémorisé en tant qu'Objet de
Données 119 dans "l'antémémoire 1" de la première application client 24cl. On suppose que "l'antémémoire 1" a été précédemment établie dans l'état d'enregistrement persistant. En résultat, le "premier type de données exprimées avec les unités de mesure métriques", qui est temporairement mémorisé dans "l'antémémoire 1" 119 en tant qu'Objet de Données 119 de la première application client 24cl, peut maintenant être transféré à partir de "l'antémémoire 1" 119 vers la base de données 110, via la connexion fonctionnelle "persistante" 114, et mémorisé dans celle-ci sous la forme d'un Objet de Données 110a.
En résultat, "l'Application 1" a pratiqué un "événement", et, lorsque cet "événement" a été pratiqué par ""l'Application 1", certaines "informations d'événements" ont été produites par "l'Application 1". Ces "informations d'événements" ont été mémorisées dans la base de données 110 sous la forme de l'Objet de Données 110a, l'Objet de Données 110a représentant le "premier type de données exprimées avec les unités de mesure métriques" mentionné ci-dessus.
Le second opérateur visualisant la seconde application client 26cl lit l'Objet de Données 110a (représentant le "premier type de données exprimées avec les unités de mesure métriques") en délivrant une commande de lecture via la borne de commande de lecture 142b du "port 2" de la seconde application client 26cl. En résultat, le "premier type de données exprimées avec les unités de mesure métriques", mémorisé en tant qu'Objet de
Données 110a de la base de données 110, est transféré à partir de la base de données 110 vers "l'antémémoire 2" 121, via la connexion fonctionnelle "persistante" 118, et est mémorisé temporairement dans "l'antémémoire 2" 121 en tant qu'Objet de Données 121 de la seconde application client 26cl. Ce transfert du "premier type de données exprimées avec les unités de mesure métriques" à partir de la base de données 110 vers "l'antémémoire 2" peut s' ef- fectuer du fait que "l'Application 2" 117 a déjà établi ltétat d'enregistrement persistant en réponse à la commande "placer" reçue dans "l'antémémoire 2" 121. Le "premier type de données exprimées avec les unités de mesure métriques", maintenant mémorisé dans "l'antémémoire 2" 121 en tant qu'Objet de Données 121 de la seconde application client 26cl, est transféré à partir de "l'antémémoire 2" 121 sur le "port 2" 142 de la seconde application client 26cl. Le convertisseur 142a du "port 2" convertit le "premier type de données exprimées avec les unités de mesure métriques11 reçu en "premier type de données exprimées avec les unités de mesure canadiennes".
Lorsque le convertisseur 142a convertit le "premier type de données exprimées avec les unités de mesure métriques" en "premier type de données exprimées avec les unités de mesure canadiennes", le second opérateur visualisant la seconde application client 26cl peut maintenant lire le "premier type de données exprimées avec les unités de mesure canadiennes" en délivrant une commande de lecture via la borne de commande de lecture 142b du "port 2" 142 de la seconde application client 26cl. On suppose que, lorsque le second opérateur de la seconde application client 26cl visualise (sur l'écran d'affichage de son poste de travail) le "premier type de données exprimées avec les unités de mesure canadiennes", le second opérateur de la seconde application client 26cl devient inté ressé par la réception d'une quantité plus importante de "données ultérieurement créées et mises à jour" associées au "premier type de données exprimées avec les unités de mesure canadiennes". Du fait de cet intérêt accru dans les "données ultérieurement créées et mises à jour" sur la partie du second opérateur de la seconde application client 26cl, le second opérateur exprime cet intérêt en écrivant un "objet d'intérêt" à partir de la borne de commande d'écriture 142c sur le "port 2" 142 de la seconde application client 26cl. Cet "objet d'intérêt" n'est pas converti par le convertisseur 142a ; au contraire, "l'objet d'intérêt" passe directement à "l'antémémoire 2" 121. Lorsque "l'objet d'intérêt" est reçu par "l'antémémoire 2" 121, la "fonction" 122 est établie. Maintenant que la "fonction" 122 est établie, lorsque les "données ultérieurement créées et mises à jour" sont reçues dans "l'antémémoire 2" en provenance de la première application client 24cl via la connexion fonctionnelle 42, la fonction particulière associée à ces "données mises à jour" est implémentée par "l'Application 2" 117 et cette fonction particulière est présentée au second opérateur de la seconde application client 26cl pour qu'il la visualise sur l'écran d'affichage de son poste de travail. L'ADI 115 de la seconde application client 26cl passe "l'objet d'intérêt" à "l'Application 2" 117, après quoi, "l'Application 2" 117 de la seconde application client 26cl passe cet "objet d'intérêt" au serveur 26c2 via la connexion fonctionnelle 38. Le serveur 26c2 enregistre "l'objet d'intérêt" reçu en provenance de la seconde application client 26cl, et, ensuite, le serveur 26c2 transmet cet "objet d'intérêt" à "l'Application 1" 111 de la première application client 24cl. L'ADI 115 de la première application client 24cl passe cet "objet d'intérêt" à "l'antémémoire 1" 119. Lorsque cet "objet d'intérêt" est reçu par le "port 1" 142, celui-ci ne su bit aucune conversion dans le convertisseur 142a ; au contraire, il est lu à partir du "port 1" 142 via la borne de lecture 142b et il est présenté au premier opérateur de la première application client 24cl pour être visualisé sur l'écran d'affichage du poste de travail du premier opérateur. Lorsque cet "objet d'intérêt" est reçu par "l'Application 1" 111, "l'objet d'intérêt" est associé à un "événement" particulier de la "Liste d'Evénements ITC" 80 de la figure 26A.
On suppose maintenant que "l'Application 1" 111 repratique le même "événement" qui a produit initialement les "informations d'événements" représentant le "premier type de données exprimées avec les unités de mesure métriques". On rappelle que le "premier type de données exprimées avec les unités de mesure métriques" a été mémorisé dans la base de données 110 en tant qu'Objet de Données 110a. Lorsque "l'Application 1" repratique ce même "événement", "l'Application 1" produit les "données ultérieurement créées et mises à jour" demandées. On rappelle que "l'Application 2" de la seconde application client 26cl a déjà exprimée son intérêt dans les "données ultérieurement créées et mises à jour".
Lorsque "l'événement" est repratiqué, "l'Application 1" 111 de la première application client 24cl s'exécute, et l'exécution de "l'Application 1" nécessite que certaines "données d'entrée mises à jour exprimées avec les unités de mesure anglaises" soient fournies par le premier opérateur de la première application client 24cl. Le premier opérateur fournit par conséquent ces "données d'entrée mises à jour exprimées avec les unités de mesure anglaises" en écrivant ces données sur le "port 1" 142 de la première application client 24cl via la borne d'écriture 142c. Les "données d'entrée mises à jour exprimées avec les unités de mesure anglaises" fournies par le premier opérateur représentent les "données ultérieurement créées et mises à jour" qui ont été demandées par la seconde application client 26cl. Le convertisseur 142a du "port 1" convertit les "données d'entrée mises à jour exprimées avec les unités de mesure anglaises" en "données d'entrée mises à jour exprimées avec les unités de mesure métriques", et les "données d'entrée mises à jour exprimées avec les unités de mesure métriques" sont temporairement mémorisées dans "l'antémémoire 1" 119 sous la forme d'un Objet de Données 119 de la première application client 24cl. Cependant, à ce niveau, l'ADI 115 de la première application client 24cl transfère ces "données d'entrée mises à jour exprimées avec les unités de mesure métriques" à partir de "l'antémémoire 1" vers "l'Application 1", et "l'Application 1" transfère ces "données d'entrée mises à jour exp-rimées avec les unités de mesure métriques" directement à partir de "l'Application 1" vers "l'Application 2" de la seconde application client 26cl via la connexion fonctionnelle 40 de la figure 44 sans enregistrer ces "données d'entrée mises à jour" avec le serveur 26c2. Les "données d'entrée mises à jour exprimées avec les unités de mesure métriques" sont aussi mémorisées dans la base de données 110 si "l'antémémoire 1" a été établie dans l'état d'enregistrement persistant.
Les "données d'entrée mises à jour exprimées avec les unités de mesure métriques" sont reçues et temporairement mémorisées dans "l'antémémoire 2" 121 de la seconde application client 26cl sous la forme de l'Objet de Données 121. La présence des "données d'entrée mises à jour exprimées avec les unités de mesure métriques" mémorisées dans "l'antémémoire 2" sous la forme de l'Objet de Données 121 de la seconde application client 26cl active la "fonction" 122. Les "données d'entrée mises à jour exprimées avec les unités de mesure métriques" sont transférées à partir de "l'antémémoire 2" vers le "port 2" 142 de la seconde application client 26cul ; et le convertisseur 142e du "port 2" 142 convertit les "données d'entrée mises à jour exprimées avec les unités de mesure métriques" en "données d'entrée mises à jour exprimées avec les unités de mesure canadiennes". Du fait que la "fonction" 122 e été activée, le "fonction" 122 affiche les "données d'entrée mises à jour exprimées avec les unités de mesure canadiennes" dans la fenêtre (12b de le figure 1) de "l'Application 2" qui est affichée sur l'écran d'affichage du poste de travail du second opérateur. Le second opérateur visualisant la seconde application client 26cl peut maintenant lire les "données d'entrée mises à jour exprimées avec les unités de mesure ca nadiennes".
Entent ainsi décrite, il est évident que le présente invention peut être modifiée de nombreuses manières. De telles modifications ne doivent pas être considérées comme s 'écartant de l'esprit ni de le portée de le présente invention, et il va de soi que toute modification susceptible d'apparaître évidente à l'homme du métier réside dans le portée des revendications annexées.

Claims (12)

REVENDICATIONS
1. Système de communication de données et d'accès aux données, caractérisé en ce qu'il comporte
une première application (24cl) adaptée pour s'exécuter dans ledit système,
une seconde application (26cl) adaptée pour s'exécuter simultanément avec ladite première application dans ledit système, ladite seconde application (26cl) étant adaptée pour établir un état d'enregistrement mémoire ou un état d'enregistrement persistant ou un état d'enregistrement transitoire,
une antémémoire (121) associée fonctionnellement à ladite seconde application (26cl), et
une base de données (110) associée fonctionnellement à ladite première application (24cl) et à ladite antémémoire (119),
ladite seconde application (26cl) produisant un ensemble original de données et mémorisant ledit ensemble original de données dans ladite antémémoire (121) lorsque ladite seconde application (26cl) établit ledit état d'enregistrement mémoire ou ledit état d'enregistrement persistant ou ledit état d'enregistrement transitoire,
ladite seconde application (26cl) mémorisant ledit ensemble original de données dans ladite base de données (110) lorsque ladite seconde application établit ledit état d'enregistrement persistant ou ledit état d'enregistrement transitoire,
ladite seconde application (26cl) ne mémorisant pas ledit ensemble original de données dans ladite base de données (110) lorsque ladite seconde application établit ledit état d'enregistrement mémoire,
ladite première application (24cl) s'interrogeant d'une manière indépendante sur l'existence dudit ensemble original de données, indépendamment de la seconde application (26c2), en interrogeant ladite base de données (110) dans la recherche dudit ensemble original de données,
ladite première application (24cl) exprimant un intérêt dans une version ultérieurement modifiée dudit ensemble original de données lorsque ladite première application interroge ladite base de données (110) dans la recherche dudit ensemble original de données et localise ledit ensemble original de données dans ladite base de données (110),
ladite première application (24cl) recevant ladite version ultérieurement modifiée dudit ensemble original de données à partir de ladite seconde application (26cl) lorsque ladite première application (24cl) exprime ledit intérêt dans les données ultérieurement modifiées et ladite seconde application (26cl) produit lesdites données ultérieurement modifiées.
2. Système selon la revendication 1, caractérisé en ce que la première application (24cl) est adaptée pour établir ledit état d'enregistrement mémoire ou ledit état d'enregistrement persistant ou ledit état d'enregistrement transitoire.
3. Système selon la revendication 2, caractérisé en ce qu'il comporte en outre
une antémémoire supplémentaire (144) associée fonctionnellement à ladite première application (24cl), ladite base de données (110) étant associée fonctionnellement à ladite antémémoire (119) et à ladite antémémoire supplémentaire (144),
ladite première application (24cl) mémorisant les données ultérieurement modifiées dans ladite antémémoire supplémentaire (144) pendant l'état d'enregistrement mémoire ou l'état d'enregistrement persistant ou 1 'état d'enregistrement transitoire.
4. Système selon la revendication 3, caractérisé en ce que ladite première application (24cl) mémorise lesdites données ultérieurement modifiées dans ladite base de données (110) pendant ledit état d'enregistrement persistant.
5. Système selon la revendication 4, caractérisé en ce que ladite première application (24cl) ne mémorise pas lesdites données ultérieurement modifiées dans ladite base de données (110) pendant ledit état d'enregistrement mémoire et ledit état d'enregistrement transitoire.
6. Système selon la revendication 5, caractérisé en ce qu'il comporte en outre un serveur (26c2) associé fonctionnellement à ladite première application (24cl) et à ladite seconde application (26cl),
ladite première application (24cl) étant adaptée pour transmettre un objet d'intérêt audit serveur (26c2),
ladite première application (24cl) transmettant ledit objet d'intérêt audit serveur (26c2) lorsque ladite première application exprime ledit intérêt dans ladite version ultérieurement modifiée dudit ensemble original de données.
7. Système selon la revendication 6, caractérisé en ce que ledit serveur (26c2) est adapté pour retransmettre ledit objet d'intérêt lorsque ledit objet d'intérêt est reçu par ledit serveur (26c2) à partir d'une application, et en ce que
ledit serveur (26c2) retransmet ledit objet d'intérêt à ladite seconde application (26cl) lorsque ledit objet d'intérêt est reçu par ledit serveur (26c2) à partir de ladite première application (24cl).
8. Système selon la revendication 7, caractérisé en ce que ladite seconde application (26cl) transmet ladite version ultérieurement modifiée dudit ensemble original de données directement à ladite première application (24cl) sans enregistrer les données ultérieurement modifiées à l'aide dudit serveur (26c2) lorsque ladite seconde application (26cl) reçoit ledit objet d'intérêt à partir dudit serveur (26c2),
ladite première application (24cl) recevant ladite version ultérieurement modifiée dudit ensemble original de données à partir de ladite seconde application (26cl).
9. Procédé de communication de données entre une première application (24cl) et une base de données (110) et permettre l'accès auxdites données de ladite base de données (110) à une seconde application (26cl), mis en oeuvre dans un système de communication de données et d'accès aux données incluant la première application (24cl) et la seconde applications (26cl) s' exécutent simultanément avec ladite première application et une base de données (110) associée fonctionnellement à la première et à la seconde application, ladite première application et ladite seconde application étant adaptées pour établir un état d'enregistrement mémoire, un état d'enregistrement persistant ou un état d'enregistrement transitoire, caractérisé en ce qu'il comporte les étapes consistant à:
(a) produire un ensemble original desdites données par l'intermédiaire de ladite première application (24cl) et mémoriser ledit ensemble original desdites données dans ladite base de données (110) lorsque ladite première application établit ledit état d'enregistrement persistant ou ledit état d'enregistrement transitoire, ledit ensemble original desdites données n'étant pas mémorisé dans ladite base de données (110) lorsque ladite première application (24cl) établi ledit état d'enregistrement mémoire, et
(b) accéder par l'intermédiaire de ladite seconde application (26cl) audit ensemble original desdites données de ladite base de données (110), indépendamment de ladite première application (24cl), après que ledit ensemble original desdites données ait été mémorisé dans ladite base de données (110) par ladite première application (24cl).
10. Procédé selon la revendication 9, caractérisé en ce que ledit système de communication de données et d'accès aux données comporte en outre une première antémémoire (119) associée à ladite première application (24cl), une seconde antémémoire (121) associée à ladite seconde application (26cl), et un serveur (26c2) connecté fonctionnellement aux première et seconde applications, et en ce que l'étape de production (a) comporte en outre les étapes consistant à
(al) mémoriser ledit ensemble original desdites données dans ladite première antémémoire (119) lorsque ladite première application (24cl) établit ledit état d'enregistrement persistant ou ledit état d'enregistrement transitoire ou ledit état d'enregistrement mémoire.
11. Procédé selon la revendication 10, caracté- risé en ce qu il comporte en outre les étapes consistant à:
(c) transmettre un objet d'intérêt à partir de ladite seconde application (26cl) audit serveur (26c2) lorsque ledit ensemble original desdites données mémorisées dans ladite base de données (110) fait l'objet d'un accès, indépendamment de ladite première application (24cl), par ladite seconde application (26cl),
(d) retransmettre ledit objet d'intérêt à partir dudit serveur (26c2) vers ladite première application (24cl), et
(e) produire, par ladite première application (24cl), une version ultérieurement modifiée dudit ensemble original desdites données.
12. Procédé selon la revendication 11, caractérisé en ce qu'il comporte en outre les étapes consistant à:
(f) mémoriser, par ladite première application (24cl), les données ultérieurement modifiées dans ladite première antémémoire (119) lorsque ladite première application établit ledit état d'enregistrement persistant ou ledit état d'enregistrement transitoire ou ledit état d'enregistrement mémoire,
(g) mémoriser, par ladite première application (24cl), lesdites données ultérieurement modifiées dans ladite base de données (110) lorsque ladite première application établit ledit état d'enregistrement persistant, et ne pas mémoriser, par ladite première application (24cl), lesdites données ultérieurement modifiées dans ladite base de données (110) lorsque ladite première application établit ledit état d'enregistrement transitoire ou ledit état d'enregistrement mémoire.
FR9710395A 1996-08-15 1997-08-14 Systeme integre de communication de donnees et d'acces aux donnees incluant l'interface de donnees d'application Expired - Fee Related FR2752468B1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US2368996P 1996-08-15 1996-08-15
US2394596P 1996-08-19 1996-08-19
US08/758,833 US6647432B1 (en) 1996-08-19 1996-12-04 Distributed framework for intertask communication between workstation applications

Publications (2)

Publication Number Publication Date
FR2752468A1 true FR2752468A1 (fr) 1998-02-20
FR2752468B1 FR2752468B1 (fr) 2006-08-04

Family

ID=27362152

Family Applications (1)

Application Number Title Priority Date Filing Date
FR9710395A Expired - Fee Related FR2752468B1 (fr) 1996-08-15 1997-08-14 Systeme integre de communication de donnees et d'acces aux donnees incluant l'interface de donnees d'application

Country Status (1)

Country Link
FR (1) FR2752468B1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0374512A2 (fr) * 1988-12-19 1990-06-27 Hewlett-Packard Company Surveillance des objets d'une base de données
US5339392A (en) * 1989-07-27 1994-08-16 Risberg Jeffrey S Apparatus and method for creation of a user definable video displayed document showing changes in real time data
US5430875A (en) * 1993-03-31 1995-07-04 Kaleida Labs, Inc. Program notification after event qualification via logical operators

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0374512A2 (fr) * 1988-12-19 1990-06-27 Hewlett-Packard Company Surveillance des objets d'une base de données
US5339392A (en) * 1989-07-27 1994-08-16 Risberg Jeffrey S Apparatus and method for creation of a user definable video displayed document showing changes in real time data
US5430875A (en) * 1993-03-31 1995-07-04 Kaleida Labs, Inc. Program notification after event qualification via logical operators

Also Published As

Publication number Publication date
FR2752468B1 (fr) 2006-08-04

Similar Documents

Publication Publication Date Title
FR2752469A1 (fr) Structure repartie pour communication intertache entre applications de postes de travail
US11740877B2 (en) Application authoring using web-of-sheets data model
US7640252B2 (en) Systems and methods for generating prediction queries
Britton et al. IT architectures and middleware: strategies for building large, integrated systems
US5883626A (en) Docking and floating menu/tool bar
CN101013362B (zh) 用于设计工作流的可扩展框架
Fowler et al. Web application design handbook: Best practices for web-based software
US8412741B2 (en) Product network management system and method
US5911075A (en) Query selection for a program development environment
US6256676B1 (en) Agent-adapter architecture for use in enterprise application integration systems
US6292827B1 (en) Information transfer systems and method with dynamic distribution of data, control and management of information
US8499036B2 (en) Collaborative design process
EP1515239A1 (fr) Procédé et systéme de manipulation de données issues de bases de données multidimensionnelles à l'aide d'un tableur
FR2740884A1 (fr) Interface administrateur pour base de donnees dans un environnement informatique distribue
US20200125336A1 (en) System and method for enhancing component based development models with auto-wiring
US6073139A (en) Integrated data communication and data access system including the application data interface
EP2612236A1 (fr) Procède de recueil de données a caractères événementiel de formulaires électroniques
US12066983B2 (en) Building collaborative data processing flows
EP0610594A1 (fr) Système de conception et de fabrication assistée par ordinateur
CA2370693C (fr) Systeme et methode de pilotage d'un processus decisionnel lors de la poursuite d'un but globale dans un domaine d'application determine
US20050132329A1 (en) Method and system for establishing a hierarchically structured web site for e-commerce
FR2752468A1 (fr) Systeme integre de communication de donnees et d'acces aux donnees incluant l'interface de donnees d'application
Seroter et al. Applied Architecture Patterns on the Microsoft Platform: An In-depth, Scenario-driven Approach to Architecting Systems Using Microsoft Technologies
Rankl et al. SAP screen personas applications for post-implementation business requirements
FR3102594A1 (fr) Ensemble de génération d’application, méthode et programme associés

Legal Events

Date Code Title Description
RN Application for restoration
FC Decision of inpi director general to approve request for restoration
PLFP Fee payment

Year of fee payment: 19

ST Notification of lapse

Effective date: 20170428