FR2821942A1 - System for simultaneously monitoring and testing distinct processes executed independently on information systems, comprises monitoring and testing module connected to processes by multiplexing - Google Patents

Abstract

At a starting stage (ST) distinct processes (Pi) and their groups of tasks (A(k1),B(k2)) and tasks (a(k3),b(k4)) are noted and a protocol (P) which includes commands (Ci), responses (Ri) and events (Ei) is considered. At a second stage (A) commands are issued and in a third stage (B) multiplexing is used to relay the commands to the processes and transmit responses and events back to the protocol to give an abstract representation (RA) An Independent claim is also included for the method of monitoring and testing a number of distinct processes independently executed on distinct information systems

Description

<Desc / Clms Page number 1>

METHOD AND SYSTEM FOR MONITORING AND CONTROLLING SIMULTANEOUS EXECUTION OF A PLURALITY OF SEPARATE PROCESSES EXECUTED INDEPENDENTLY ON COMPUTER SYSTEMS.

 The multiplication of data exchanges by separate computer systems, networked for example, has experienced an unprecedented boom, due to the establishment of the Internet and the creation of sites for access to information, services and / or commercially available products, on the one hand, and the regular increase in computing power allocated to the aforementioned computer systems, on the other hand.

At the same time, the development of high-level languages, such as the JAVA language, has made it possible for the general public to make available specific applications executed for example in interactive mode between terminals constituting the aforementioned separate computer systems, these applications being executed in the form of specific distinct processes.

 While the problem of securing transactions between the aforementioned processes has been solved by satisfactory solutions implementing embedded computer systems, such as microprocessor cards, provided with cryptographic means, allowing the implementation of encryption / decryption data transmitted or received, the multiplication of specific separate processes above also poses the problem of the reliability of the execution of these processes, the concept of reliability above covering, at least partially, the concept of securing transactions implemented between parties to these transactions.

<Desc / Clms Page number 2>

At present, the aforementioned high-level languages, such as for example the JAVA language, are capable of enabling the implementation of protocols for monitoring and controlling the execution of a given process executed by a given computer system. , more commonly referred to as a debug protocol. The execution of this type of protocol implements commands addressed to the process object of the monitoring and control operation, responses addressed by this same process and events specific to this process and makes it possible to generate an abstract representation of this process and all the tasks of the latter, tasks organized into a hierarchy of task groups.

 The implementation of such protocols can be performed, when the process is executed via a JAVA program, or corresponding to a semantics close to the JAVA language, from a software tool for monitoring and control of the JAVA program. runtime, says debugging tool, JDWP protocol client for JAVA WIRE DEBUG PROTOCOL. The JDWP protocol is specified by the company SUN MICROSYSTEMS. The complete specifications of the JDWPO protocol are available on the website http: // java. sun. com / j2se / 1. 3 / docs / guide / jpda / jdwp-spec. html.

 Such a protocol can be implemented, on the one hand, by any JAVA virtual machine version 1.2 and 1.3 providing a debugging mode and, on the other hand, by any debugging tool in accordance with the specifications of the JDWP protocol. The use of such a protocol makes it possible, in particular, to strongly separate the debugging tool itself from its target machine, that is to say from the executed process object tracking and execution control or debugging. This

<Desc / Clms Page number 3>

forte séparation est rendue possible grâce aux caractéristiques intrinsèques de ce type de protocole selon lesquelles, d'une part, la seule connaissance du processus soumis au débogage dont dispose l'outil de débogage provent du protocole JDWP en tant que tel, l'outil de débogage n'ayant pas à accéder aux fichiers de code objet compilés de l'application exécutée selon le processus à déboguer alors que l'accès par l'outil de débogage aux fichiers du code source de l'application peut être effectué aux seules fins d'affichage de ses derniers en mode texte, en l'absence de toute interprétation, alors que, d'autre part, les commandes du protocole JDWP sont génériques et indépendantes de l'application à déboguer et utilisent notamment des identificateurs d'objets ou de classes numériques de tailles variables, ce qui permet bien entendu une mise en oeuvre adaptée à une grande variété de processus cibles à déboguer.

strong separation is made possible by the intrinsic characteristics of this type of protocol according to which, on the one hand, the only knowledge of the debugging process available to the debugging tool comes from the JDWP protocol as such, the debugging that does not have access to the compiled object code files of the application that is running according to the process being debugged, while access by the debugging tool to the source code files of the application can be done for the sole purpose of display of the latter in text mode, in the absence of any interpretation, while, on the other hand, the commands of the JDWP protocol are generic and independent of the application to be debugged and use particular identifiers of objects or numerical classes of variable sizes, which of course allows an implementation adapted to a wide variety of target processes to debug.

 For this reason, each target process to be debugged, consisting of a JDWPO server on which the debugging tool connects, does not have to be a JAVA virtual machine, but must simply behave as such.

 It is an object of the present invention to provide a method and system for monitoring and controlling the simultaneous execution of a plurality of distinct independently executed processes on separate computer systems accessible by network.

 In particular another object of the present invention is the implementation of a method and a system for monitoring and controlling the simultaneous execution of a plurality of distinct processes executed.

<Desc / Clms Page number 4>

r indépendamment sur des systèmes informatiques distincts à partir d'un protocole de suivi et de contrôle d'exécution, dit protocole de débogage, autorisant une forte séparation de l'outil de débogage proprement dit de chacun des processus soumis au débogage simultané, protocole de débogage tel que le protocole JDWPO.

r independently on separate computer systems from an execution monitoring and control protocol, called the debugging protocol, allowing a strong separation of the debugging tool itself from each of the processes subjected to simultaneous debugging, protocol de debug debugging such as the JDWPO protocol.

 The system and method for monitoring and controlling the simultaneous execution of a plurality of separate processes executed independently on separate computer systems, objects of the present invention, operate on each of these processes containing a set of tasks organized into a hierarchy groups of tasks. The execution of each of these processes is monitored individually and controlled by means of a protocol for monitoring and control of execution independent of each of these processes, this protocol making it possible, from commands addressed to a process, to responses addressed by this process and specific events of this process, to engender an abstract representation of this process.

 They are remarkable in that this system allows for and this method consists of, by means of a single link support of the specific tracking and execution control protocol, generating at least one specific tracking and execution control command. according to this specific monitoring and execution control protocol, multiplex, on the one hand, all the commands generated in accordance with the control protocol and specific execution monitoring to each of these processes, and, on the other hand, ensure the transmission of the responses and events from each process. All

<Desc / Clms Page number 5>

r des commandes de suivi et de contrôle d'exécution, des réponses et des événements multiplexés constituant cette représentation abstraite est configurée par l'opération de multiplexage selon une combinaison formant un processus virtuel unique regroupant l'ensemble des tâches de chacun des processus contrôlés, ce qui permet d'assurer le suivi et le contrôle d'exécution simultané de cette pluralité de processus sur cette liaison unique.

r tracking and execution control commands, responses and multiplexed events constituting this abstract representation is configured by the multiplexing operation in a combination forming a single virtual process grouping all the tasks of each of the controlled processes, which makes it possible to ensure the monitoring and control of simultaneous execution of this plurality of processes on this single link.

 The method and system objects of the present invention are applicable to the simultaneous execution monitoring and control of a plurality of separate processes executed independently on computer systems, which computer systems can be accessed in a network. These systems can themselves be separate, and consist of an embedded system, such as a microprocessor card. At least one of these distinct processes can be implemented by means of a sequence of interpreted sequential instructions, commonly referred to as Anglo-Saxon scripting.

 The method and system that are the subject of the present invention will be better understood on reading the description and on observing the following drawings in which: FIG. 1a represents, by way of illustration, a flowchart of the method of monitoring and simultaneous execution control of a plurality of separate processes executed independently on separate computer systems, in accordance with the object of the invention; FIG. 1b represents, by way of illustration, a detail of implementation of the multiplexing operation of

<Desc / Clms Page number 6>

r procédé objet de l'invention tel que représenté en figure la ; - la figure le représente, à titre illustratif, un exemple de constitution d'une combinaison formant un processus virtuel unique regroupant l'ensemble des tâches de chacun des processus distincts contrôlés ; - la figure 2a représente, à titre illustratif, un schéma synoptique de l'architecture du système de suivi et de contrôle d'exécution simultané d'une pluralité de processus distincts exécutés indépendamment sur des systèmes informatiques conforme à l'objet de la présente invention ; - la figure 2b représenté, à titre illustratif, un schéma fonctionnel d'un multiplexeur permettant la mise en oeuvre du système de suivi et de contrôle d'exécution simultané d'une pluralité de processus distincts exécutés indépendamment sur des systèmes informatiques, objet de l'invention, tel que représenté en figure 2a ; - la figure 2c représente, à tire illustratif, un diagramme d'état d'un cycle de vie d'un traitement mis en oeuvre dans le multiplexeur représenté en figure 2b ; - la figure 2d représente, à tire illustratif, un organigramme de la création et de l'exécution de tout traitement, par le module de gestion des traitements inclus dans le multiplexeur illustré en figure 2b ; - la figure 2e représente, à tire illustratif, un diagramme séquentiel d'échange de messages de commande, de messages de réponse entre le module 1 de suivi et de contrôle d'exécution et le module 2 de multiplexage, d'une part, et de messages de sous-commande, de messages de sous-réponse entre le module 2 de multiplexage et

r method object of the invention as shown in Figure la; FIG. 1 represents, by way of illustration, an example of constituting a combination forming a single virtual process grouping together all the tasks of each of the distinct controlled processes; FIG. 2a represents, by way of illustration, a schematic diagram of the architecture of the system for monitoring and controlling the simultaneous execution of a plurality of distinct processes executed independently on computer systems in accordance with the subject of the present invention. ; FIG. 2b represented, by way of illustration, a block diagram of a multiplexer enabling the implementation of the system for monitoring and controlling the simultaneous execution of a plurality of distinct processes executed independently on computer systems, object of invention, as shown in Figure 2a; FIG. 2c represents, as an illustration, a state diagram of a life cycle of a processing implemented in the multiplexer represented in FIG. 2b; FIG. 2d represents, as an illustration, a flowchart of the creation and execution of any processing, by the processing management module included in the multiplexer illustrated in FIG. 2b; FIG. 2e represents, for illustrative purposes, a sequential diagram for exchanging control messages, response messages between the tracking and execution control module 1 and the multiplexing module 2, on the one hand, and subcommand messages, sub-response messages between the multiplexing module 2 and

<Desc / Clms Page number 7>

r--------------------------------------------------différents processus distincts Pl à P3 correspondant à la configuration de ces processus telle qu'illustrée en figure le, d'autre part ; - la figure 3a représente, à titre illustratif, un exemple de mise en oeuvre d'application du procédé et du système de suivi et de contrôle d'exécution simultané d'une pluralité de processus distincts exécutés indépendamment sur des systèmes informatiques dans le cas où les processus sont des processus de type GSM, serveur

OTA ; - la figure 3b représente, à titre illustratif, un exemple de mise en oeuvre d'application du procédé et du système de suivi et de contrôle d'exécution simultané d'une pluralité de processus distincts exécutés indépendamment lorsque l'un de ces processus est mis en oeuvre par une interprétation d'un langage séquentiel.

r ------------------------------------------------- different distinct processes P1 to P3 corresponding to the configuration of these processes as illustrated in FIG. 1a, on the other hand; FIG. 3a represents, by way of illustration, an exemplary implementation of the method and the system for monitoring and controlling the simultaneous execution of a plurality of separate processes executed independently on computer systems in the case where processes are processes of type GSM, server

OTA; FIG. 3b represents, by way of illustration, an exemplary implementation of the method and the system for monitoring and controlling the simultaneous execution of a plurality of distinct processes executed independently when one of these processes is implemented by an interpretation of a sequential language.

 The method of monitoring and controlling the simultaneous execution of a plurality of separate processes executed independently on computer systems will now be described in conjunction with Figure la and the following figures.

 In a general manner, a plurality of distinct processes is considered, each process being denoted by Pi, where i denotes the index identifying the process and can be a priori any and between 1 and n. We consider a set of processes Pi each containing a set of tasks, these tasks being organized into a hierarchy of task group.

 One considers thus the starting situation ST in which the groups of tasks for any process Pi are noted A [kil and B [k2l the tasks are noted with [k3l and b [k4l

<Desc / Clms Page number 8>

r indépendamment du nombre de tâches et/ou de groupes de tâches considérés et des valeurs de ki, k2, k3 et k4. Les paramètres entre crochets correspondant à des identificateurs locaux particuliers, lesquels seront explicités ultérieurement dans la description.

r irrespective of the number of tasks and / or groups of tasks considered and the values of ki, k2, k3 and k4. Parameters between brackets corresponding to particular local identifiers, which will be explained later in the description.

 In this starting situation ST one considers the implementation of a protocol of follow-up and control of execution, this protocol making it possible to control each process Pli the execution of each of these processes being followed individually and controlled by the intermediary of the aforementioned protocol.

 The monitoring and execution control protocol is independent of each of the processes Pi and allows, from commands Ci addressed to a process, the process Pi, responses Ri addressed by this process to this command, these responses Ri, and finally, specific Ei events of this process, to generate an abstract representation of this process and all the tasks of this process thanks to the aforementioned answers and events. At the start step ST, the protocol is noted P {Ci, Ei, Ri} = P.

 In general, it is indicated that the method, which is the subject of the present invention, consists in implementing the aforementioned protocol independently for each distinct Pi process, and, thanks to this independence and to the abstract representation of each of the distinct processes Pi , to obtain simultaneous monitoring and control of the execution of each of the aforementioned distinct processes.

 With reference to FIG. 1a, the method which is the subject of the present invention then consists, in a step A, in generating at least one command Ci for monitoring and control

<Desc / Clms Page number 9>

r d'exécution pour au moins l'un des processus distincts Pi, cette commande étant bien entendu engendrée conformément au protocole de suivi et de contrôle d'exécution choisi. Bien entendu, on comprend que l'étape A peut être réalisée ou répétée pour l'ensemble des processus Pi distincts afin d'assurer le suivi et le contrôle d'exécution simultané de la pluralité des processus distincts précités.

r execution for at least one of the separate processes Pi, this command being naturally generated in accordance with the chosen protocol for monitoring and execution control. Of course, it will be understood that step A can be performed or repeated for the set of distinct processes Pi in order to ensure the simultaneous execution monitoring and control of the plurality of the aforementioned distinct processes.

 Step A is then followed by a step B of multiplexing the set of commands Ci, Ri responses and Ei events engendered in accordance with the above-mentioned control and execution monitoring protocol P.

 The aforementioned multiplexing operation is denoted MUX {Ci, Ri, Vil.

 The multiplexing operation performed in step B allows, firstly, after processing, the retransmission of each control and execution control command to each of the aforementioned separate processes Pi, and secondly, after processing , retransmitting the responses Ri and Ei events from the aforementioned processes Pi to the process of monitoring and execution control, the multiplexing operation substantially performing a translation operation of the addressing commands and responses and events, as will be described below.

 According to a particularly remarkable aspect of the method, object of the present invention, the set of follow-up and execution control commands, responses and multiplexed events constituting the abstract representation is configured by the multiplexing operation in a combination forming a process

<Desc / Clms Page number 10>

r---------------------------------------------------------virtuel unique regroupant l'ensemble des tâches de chacun des processus contrôlés.

r ------------------------------------------------- -------- unique virtual grouping all the tasks of each controlled process.

 In step B of FIG. 1a, the abstract representation, according to the single virtual process combination, is denoted RA = UVP {Ci, Ri, Ei}.

 The preceding notation indicates that the single virtual process groups together all the tasks of each of the controlled processes. This procedure makes it possible to ensure the simultaneous execution monitoring and control of the plurality of processes Pi mentioned above, as will be described in more detail later in the description.

 A more detailed description of the multiplexing operation B shown in FIG. 1a will now be given in connection with FIG.

 In order to multiplex the combination forming a single virtual process grouping all the tasks of each of the controlled processes, the aforementioned multiplexing operation may advantageously consist, in one step, B1 to assign a unique local identifier IDL = k [0, 2M [to each constituent element of a distinct process, an element constituted for example by a task or a group of tasks. The aforementioned allocation operation is performed in accordance with the chosen specific tracking and execution control protocol, in which each task or group of tasks is assigned a unique numeric identifier at each distinct process Pi concerned. So every task or group of tasks or any other element of a separate Pi process is

<Desc / Clms Page number 11>

r-------------------------------identifié par l'identificateur local distinct qui lui est associé.

r ------------------------------- identified by the distinct local identifier associated with it.

 However, such a local identifier does not, on its own, identify the distinct process Pi to which the aforementioned task or task group belongs.

 For this reason, the step B1 is followed by a step B2 consisting of associating with each separate controlled process and with the unique virtual process a specific process reference Pur1. This operation allows, in addition to discrimination and identification of each distinct process Pi, to install the single virtual process in a specific process different from the separate processes Pi controlled, but processed, from the point of view of the multiplexing and the tracking protocol and Execution behavior, similar to the follow-up processing and execution control of each separate process Pi by the specific tracking and execution control protocol chosen.

i 2 1, représentative de chaque processus distinct For this purpose, the specific process reference PRi may be defined as a numerical value taken from a set of numerical values, representative of the set of specific process reference values. More specifically, one of the specific reference values among this set of specific process reference values is reserved for assignment as a single virtual process reference. By way of non-limiting example, the specific reference value assigned as a single virtual process reference may be the value s = 0, with each separate controlled process Pi being reserved a value

i 2 1, representative of each distinct process

<Desc / Clms Page number 12>

r contrôlé. Dans ces conditions, le couple formé par un identificateur local IDL = k et une valeur de référence spécifique, constituant une référence de processus spécifique, est représentatif de l'élément de la représentation abstraite du processus distinct contrôlé associé à cet identificateur local, pour i 1, respectivement d'un élément virtuel constitutif de la combinaison formant le processus virtuel unique, pour i=0=8. Ainsi, l'ensemble E des valeurs de référence de processus spécifique peut être défini comme E= [0, n].

r controlled. Under these conditions, the pair formed by a local identifier IDL = k and a specific reference value, constituting a specific process reference, is representative of the element of the abstract representation of the separate controlled process associated with this local identifier, for i 1, respectively of a virtual element constituting the combination forming the single virtual process, for i = 0 = 8. Thus, the set E of the specific process reference values can be defined as E = [0, n].

 In order to allow the identification of the aforementioned couples in accordance with the selected specific monitoring and execution control protocol, in which any task or group of tasks is assigned a unique numerical identifier, the aforementioned step B2 is followed by a step B3 consisting in associating with any pair formed by a local identifier IDL = k and by a specific process reference value a separate global identifier IDG. By way of nonlimiting example, each distinct global identifier can be chosen from a set G of specific numerical values, defined by G = [0, 2P [where P is a given integer. Thus, the set of global identifiers belonging to the set G, which are obtained for each virtual task group constituting the combination forming the single virtual process, makes it possible to ensure the multiplexing operation by mapping global identifiers together. and local identifiers by separate controlled process.

 With regard to the implementation of step B3, it is indicated that obtaining a unique numerical value IDG representative of a pair (i, IDL) can be set to

<Desc / Clms Page number 13>

r oeuvre par calcul de valeurs croissantes dans l'ensemble G des valeurs retenues ou par appel d'une fonction de codage/décodage, laquelle, à un couple (i, IDL), fait correspondre une valeur numérique unique IDG.

It works by calculating increasing values in the set G of the values retained or by calling a coding / decoding function, which, at a pair (i, IDL), matches a unique numerical value IDG.

The multiplexing process for implementing the method, object of the present invention, will be described in an illustrative manner with reference to FIG.

In FIG. 1c, the different processes Psi ... Pi ... Pn are represented.

The process Pl is deemed, following the reception of commands Ci, to transmit responses Ri concerning the task group A [14], B [16] comprising the unique task a [15] and the task group B [16] consisting of in a group of tasks C [17] itself formed tasks b [18] and c [19].

The process Pi, for i = 2, following the receipt of commands Ci is deemed to transmit responses Ri relative to a task group A [0] consisting of a single task al.

The process Pn, for n = 3, following commands Cn is deemed to transmit responses relating to a task group A [10] formed by a task a [12] and a task b [13] and by another group of tasks B [ll] comprising a task C [14] and another task group C [15], itself formed by two tasks d [16] and [17]. It is understood that apart from the responses Ri, one of the separate processes Pi or other can also transmit events, denoted Ei, Ei or En respectively.

Each task group from a separate controlled process Pi is assigned a global identifier

<Desc / Clms Page number 14>

r IDG, IDG=O, à IDG=5 dans l'exemple donné, cet identificateur global fédérateur et traducteur permettant d'établir la combinaison précédemment mentionnée dans la description, cette combinaison consistant en une pluralité d'objets virtuels, distincts des objets de représentation abstraite, et formant le processus virtuel unique regroupant l'ensemble des tâches et groupe de tâches de chacun des processus distincts contrôlés. Le mode opératoire séquentiel de l'opération de multiplexage permettant la mise en oeuvre d'une telle combinaison sera décrit ultérieurement dans la description.

r IDG, IDG = O, at IDG = 5 in the example given, this unifying global identifier and translator making it possible to establish the combination previously mentioned in the description, this combination consisting of a plurality of virtual objects, distinct from the objects of the abstract representation, and forming the single virtual process grouping all the tasks and task group of each of the separate controlled processes. The sequential operation of the multiplexing operation allowing the implementation of such a combination will be described later in the description.

 A more detailed description of a system for monitoring and controlling the simultaneous execution of a plurality of distinct processes executed independently on separate computer systems according to the subject of the present invention will now be given in connection with FIGS. 2d.

0 protocole JDWP, afin de donner des éléments concrets de mise en oeuvre d'un tel système, et du procédé correspondant. In general, it is indicated that the system, which is the subject of the present invention, will be described in the case where the protocol P of monitoring and control of execution is a

0 JDWP protocol, to give concrete elements of implementation of such a system, and the corresponding method.

 However, it is indicated that any protocol distinct from the JDWP protocol can be implemented as long as the processes Pi behave as virtual machines meeting the criterion of strict independence of the protocol for monitoring and control of execution and distinct processes Pi implemented simultaneously. In addition to the strict criterion of independence mentioned above, the protocol for monitoring and controlling the independent execution of each of the

<Desc / Clms Page number 15>

r processus Pi doit permettre la mise en oeuvre d'une représentation abstraite de chaque processus et de l'ensemble des tâches de chacun des processus P mentionnés.

Pi process must allow the implementation of an abstract representation of each process and the set of tasks of each process P mentioned.

 In these conditions, as shown in FIG. 2a, the system SY, which is the subject of the invention, comprises a module 1 for monitoring and execution control enabling implementation of the protocol P for monitoring and execution control.

 In the case of the implementation of a JDWP protocol, the module 1 for monitoring and control of execution is constituted by a single and standard debugging tool normally commercially available for example.

 In addition, the SY system, which is the subject of the invention, comprises a multiplexing module 2, which is interconnected, on the one hand, with the execution monitoring and control module 1, and on the other hand, with each of the processes The aforementioned interconnections are implemented via a single link, supporting the implementation of the protocol P monitoring and execution control.

 With regard to the physical implementation of the module 1 for monitoring and control of execution and the module 2 of multiplexing, it is indicated that the implementation of these may be any provided that the links between the module 1 monitoring and execution control and the multiplexing module 2, on the one hand, and between the multiplexing module 2 and each of the separate processes Pi, on the other, are constituted by links allowing the application of the debugging protocol P, it is

<Desc / Clms Page number 16>

r à dire dans l'exemple de mise en oeuvre présentement 1 décrit, du protocole JDWP
D'une manière plus spécifique, on indique que le module 2 de multiplexage permet, d'une part, après traitement, la retransmission des commandes Ci engendrées par le module 1 de suivi et de contrôle d'exécution vers les processus distincts Pi, et d'autre part, après traitement, la retransmission des réponses Ri ainsi que des événements Ei engendrés et en provenance des processus distincts Pi.

r to say in the implementation example currently 1 described, the JDWP protocol
More specifically, it is indicated that the multiplexing module 2 makes it possible, on the one hand, after processing, to retransmit the commands Ci generated by the execution monitoring and control module 1 to the separate processes Pi, and on the other hand, after processing, the retransmission of the responses Ri as well as events Ei generated and coming from the separate processes Pi.

 Under these conditions, the abstract representation RA is configured by the multiplexing module 2 in a combination forming a single virtual process, the UVP process {Ci, Ri, Ei} previously mentioned in the description and described in connection with FIG. 1c.

 Such an arrangement resulting from the multiplexing construction makes it possible to monitor and control simultaneous execution by multiplexing the set and the plurality of distinct processes Pi.

 It will thus be understood, with reference to FIG. 1c, that for a set of distinct processes Pi comprising at least one group of tasks, the aforementioned combination comprises a virtual task group associated with each of the distinct processes Pi by the multiplexer module 2.

Each virtual task group comprises the hierarchy of task groups and corresponding separate process tasks, constituting the abstract representation RA according to the unique virtual process UVP {Ci, Ri, Ei}.

 In the more particular case where the protocol P of monitoring and execution control is the JDWP protocol,

<Desc / Clms Page number 17>

r le module 1 de suivi et de contrôle d'exécution est configuré en mode client JDWP 0. Chaque système informatique distinct et le processus Pi distinct conduit par ce dernier, constitue alors une machine configurée en

mode serveur JDWPO, laquelle peut être identifiée par un nom unnomdemachinearbitraireMNipar exemple.

r Runtime Monitoring and Execution Module 1 is configured in JDWP 0 client mode. Each separate computer system and the separate Pi process driven by it, is then a machine configured as a

JDWPO server mode, which can be identified by a name such as anmachinearmachineMNipar example.

0 protocole JDWP On comprend ainsi, que le système SY, objet e l'invention, permet à partir d'une pluralité de processus distincts Pi de constituer un processus virtuel unique dans lequel, chaque groupe de tâches et bien entendu chaque tâche, associés à chaque processus distinct Pi conserve son individualité et la spécificité de ses réponses, ce qui permet bien entendu d'assurer le suivi et le contrôle d'exécution simultané de l'ensemble des processus distincts Pi. Under these conditions, the tracking and execution control module 1 configured in JDWP client mode and each of the machines configured in JDWP server mode executing each separate process Pi, are connected to the multiplexing module 2 by any communication channel, of which the only constraint is the transmission of orders, responses and events according to the

It is thus understood that the system SY, which is the subject of the invention, makes it possible, from a plurality of distinct processes Pi, to constitute a single virtual process in which each group of tasks and, of course, each task, associated with each distinct process Pi retains its individuality and the specificity of its responses, which of course makes it possible to monitor and control the simultaneous execution of all the distinct processes Pi.

 A more detailed description of the multiplexer module 2 in a specific nonlimiting implementation mode will now be given in connection with FIG. 2b.

 In general, it is indicated that the multiplexing module 2 comprises at least one management module 20

<Desc / Clms Page number 18>

r des commandes émises par le module 1 de suivi et de contrôle d'exécution, et un module 21 de gestion des événements transmis par les processus distincts Pi. Le module de gestion des événements 21 est précédé d'un module séparateur 23 permettant d'assurer la séparation des messages de sous-réponse respectivement de sous- événements, engendrés par chaque processus distinct Pi.

r commands issued by the module 1 monitoring and execution control, and a module 21 for managing events transmitted by the separate processes Pi. The event management module 21 is preceded by a separator module 23 allowing separating the sub-response or sub-event messages generated by each distinct process Pi.

 In general, it is indicated that the designation of sub-event, sub-response or sub-command messages respectively designates messages of events, responses and commands respectively compliant with the JDWP protocol and transiting between the module. multiplexing 2 and one of the separate processes Pi.

 In the same way, control messages, respectively, response messages or event messages, are denoted by any JDWP protocol message transiting between the multiplexing module 2 and the execution monitoring and control module 1.

 In the context of the implementation of the multiplexing module 2, represented in FIG. 2b, it is indicated that the separator module 23 of the sub-response messages / sub-event messages can be constituted by a conventional module, the JDWP protocol authorizing the discrimination of the response messages and the event messages, ie sub-response messages and sub-event messages according to the system, object of the present invention, by simple discrimination of a field value introduced in the aforementioned messages for this purpose.

<Desc / Clms Page number 19>

r Enfin, le module 2 de multiplexage comprend un module de gestion des traitements 22, lequel permet, sous le contrôle du module 20 de gestion des commandes, de créer un traitement pour chaque commande reçue. Chaque traitement créé permet, d'une part, d'envoyer des messages de sous-commande vers et de recevoir les messages de sousréponse correspondant à ces messages de sous-commande venant des processus distincts contrôlés, et, d'autre part, d'envoyer le message de réponse correspondant à la commande considérée vers le module 1 de suivi et de contrôle d'exécution.

Finally, the multiplexing module 2 comprises a processing management module 22, which allows, under the control of the command management module 20, to create a processing for each command received. Each created process makes it possible, on the one hand, to send subcommand messages to and to receive the sub-response messages corresponding to these subcommand messages coming from the different controlled processes, and, on the other hand, to send the response message corresponding to the command in question to the module 1 tracking and execution control.

 The processing management module 22 furthermore makes it possible, under the control of the event management module 21, to create a processing for each sub-event message received from one of the distinct controlled processes P1. These latter processes make it possible to on the one hand, to send subcommand messages to and to receive the sub-response messages corresponding to these subcommand messages from the separate controlled processes Pi, and, on the other hand, to send messages of event to module 1 tracking and execution control.

 In a general manner, the processing management module 22, which creates and executes the aforementioned processes, comprises a module 220 for managing the multiplexing of the identifiers, whereas the event management module 21 makes it possible to simultaneously process a plurality of subnodes. -events to transmit subcommands to separate processes Pi. The command management module 20 allows, on the contrary, to simultaneously process several commands via the

<Desc / Clms Page number 20>

 identifier multiplexing management module 220 to generate the subcommands for each of the distinct processes Pi.

 The overall operation of the multiplexing module 2 shown in FIG. 2b can be summarized as follows. The control messages transmitted by the tracking and execution control module 1 are transmitted to the multiplexer 2 and in particular to the command management module 20, which, via the processing management module 22, generates a message. appropriate treatment according to the content of the aforementioned command message. This processing, once executed, provides a JDWP packet constituting a response message, which is of course transmitted to the module 1 for monitoring and execution control. During its execution, the processing implemented by the processing management module 22 is able to transmit subcommand messages, these subcommand messages being in accordance with the JDWPO protocol mentioned above, to some of the Pi processes. , these subcommand messages being of course depending on the command message which triggered the creation of the processing. In addition, the processing implemented by the processing management module 22 may also receive a corresponding sub-response message and continue the calculation according to the content of the aforementioned sub-response message.

 More specifically, it is indicated that the sub-event messages designate the JDWP packets e from the separate processes Pi but that do not constitute sub-response messages. It is recalled that the discrimination between sub-event messages and

<Desc / Clms Page number 21>

r messages de sous-réponse est effectuée au niveau du module 23 séparateur sous-réponse/sous-événement. Sur discrimination d'un message de sous-événement, ce message est transmis au module 21 de gestion des événements, lequel engendre un traitement approprié en fonction du contenu du message de sous-événement précité. On rappelle également, que le traitement précité engendré par le module 21 de gestion des événements peut, si nécessaire, au cours de l'exécution de ces derniers, envoyer des messages de sous-commande à certains des processus distincts Pi, recevoir les messages de sous-réponse correspondants et continuer le calcul en fonction des contenus de ces derniers. Lorsque le traitement est terminé, traitement défini par le module de gestion des événements 21, le module 22 de gestion des traitements, qui a exécuté le traitement précité, fournit un paquet JDWP constitutif d'un message d'événement, lequel est transmis au module 1 de suivi et de contrôle d'exécution.

r sub-response messages is performed at sub-response / sub-event separator module 23. On discrimination of a sub-event message, this message is transmitted to the event management module 21, which generates an appropriate processing according to the content of the aforementioned sub-event message. It is also recalled that the aforementioned processing generated by the event management module 21 can, if necessary, during the execution of the latter, send subcommand messages to some of the distinct processes Pi, receive the messages of corresponding sub-responses and continue the calculation according to the contents of the latter. When the processing is finished, processing defined by the event management module 21, the processing management module 22, which has executed the aforementioned processing, provides a JDWP packet constituting an event message, which is transmitted to the module 1 monitoring and control of execution.

 Several processes implemented in the multiplexing module 2 can be executed simultaneously. In particular, at a given time, several processes may be waiting for a sub-response message to a subcommand message sent previously. The processing management module 22 then orders the execution of the various processes, manages the sending of the subcommands to the different distinct processes Pi and the reception of the corresponding sub-responses, as well as the sending of the response messages respectively event messages. to module 1 monitoring and control of execution.

<Desc / Clms Page number 22>

r Une description plus détaillée de la mise en oeuvre d'un traitement au niveau du module de multiplexage 2 et en particulier du module 22 de gestion des traitements, sera maintenant donnée en liaison avec les figures 2c et 2d.

A more detailed description of the implementation of a processing at the level of the multiplexing module 2 and in particular of the processing management module 22, will now be given in connection with FIGS. 2c and 2d.

 In general, it is recalled that the notion of processing concerns, at the level of the processing management module 22, the implementation of the operations enabling the construction of the abstract representation, configured according to a combination forming a single virtual process, composed of as many groups of tasks as controlled processes, according to the object of the present invention. This concept of treatment is therefore specific to the method and the system, objects of the present invention, each T processing implementing a plurality of states, which will be described in relation to Figure 2c above.

 With reference to the above-mentioned figure, it is indicated that each processing T, following its creation under control either by the command management module 20 or by the event management module 21, can be in the available state, either in the off state or in the completed state.

 As represented in FIG. 2c above, the different states of each treatment T can advantageously be managed in the following manner: in the available state, the processing T can be executed, the execution being represented by the arrow in FIG. closed loop on the aforementioned available state; in the blocked state, the processing T is waiting for a sub-response message consecutive to a

<Desc / Clms Page number 23>

r message de sous-commande. Dans l'état bloqué précité, il est alors possible d'extraire du traitement T un message de sous-commande et un numéro identificateur i de processus Pi, auquel le traitement T a envoyé le message de sous-commande précité ; - dans l'état terminé, le traitement T permet d'extraire un paquet JDWP, lequel constitue un message de réponse ou un message d'événement transmis au module 1 de suivi et de contrôle d'exécution.

r subcommand message. In the aforementioned blocked state, it is then possible to extract from the processing T a subcommand message and a process identifier number Pi, to which the processing T has sent the aforementioned subcommand message; in the finished state, the processing T makes it possible to extract a packet JDWP, which constitutes a response message or an event message transmitted to the module 1 for monitoring and execution control.

 A more detailed description of the overall operating mode of the processing management module 22 will now be given in connection with FIG. 2d.

 FIG. 2d represents an implementation flowchart, given by way of non-limiting example, of the scheduling of the execution of the treatments T. Of course, other embodiments of the aforementioned processes can be envisaged, or if necessary, be entrusted to the control of the operating system of the multiplexer module 2.

 The embodiment shown in FIG. 2d illustrates the management of the processes, which may each occupy all the states represented in FIG. 2c and indicate, for all the treatments, the transition from a state to a state. other state, when receiving a sub-response.

 The operating mode represented in FIG. 2d corresponds to the case where for any one of the distinct processes Pi subjected to a monitoring and a simultaneous execution control according to the method, object of the present invention, this monitoring and this execution control. is generating a process sub-response message

<Desc / Clms Page number 24>

r distinct Pi considéré, ce message de sous réponse étant transmis au module multiplexeur 2, cette sous-réponse étant attendue par l'un des traitements T bloqué géré par le module 22 de gestion des traitements. Le traitement correspond, par exemple, à la transformation d'un message de commande en une succession de couples de messages de sous-commande et de sous-réponse pour constituer la représentation abstraite selon le processus virtuel unique.

r distinct Pi considered, this sub-response message being transmitted to the multiplexer module 2, this sub-response being expected by one of the blocked processing T managed by the processing management module 22. The processing corresponds, for example, to the transformation of a control message into a succession of pairs of subcommand and subresponse messages to constitute the abstract representation according to the single virtual process.

 Under these conditions, the process of treatment management comprises at least one step 1000 of availability test of an SR sub-response message from a separate controlled process Pi. On positive response in step 1000 of the aforementioned test , a step 1001 of testing for the existence of a blocked processing waiting for this sub-response message from the distinct process Pi considered is provided. The negative response to the test step 1001 of blocked processing existence is followed by a return to the availability test step 1000, the absence of such a blocked processing denoting an error of this process, this under -response is then ignored. The positive response to the existence test step 1001 of a blocked treatment T is followed by a step 1002 of unblocking this blocked treatment T and communicating the subresponse SR to this treatment. Following the unblocking step 1002 or on the negative response in the availability test step of a sub-response 1000, a step 1003 of the availability test of another processing is scheduled. In the test 1003, the treatment is noted T ', this treatment may or may not be distinct from the treatment T.

<Desc / Clms Page number 25>

r----------------------------------------------------------. La réponse négative à l'étape de test 1003 de disponibilité d'un autre traitement T', est suivie d'un retour à l'étape de test 1000 de disponibilité d'une sousréponse, tous les traitements étant alors bloqués. La réponse positive à l'étape de test de disponibilité 1003 d'un autre traitement T', est suivie d'une étape d'exécution d'un pas de calcul de cet autre traitement, cette étape d'exécution étant notée 1004.

r ------------------------------------------------- ---------. The negative response to the test step 1003 of availability of another treatment T 'is followed by a return to the test step 1000 of availability of a sub-response, all the processing being then blocked. The positive response to the availability test step 1003 of another processing T 'is followed by a step of executing a calculation step of this other processing, this execution step being denoted 1004.

Pi.. La commande SC'et i', identificateur de Pi,, sont extraits du traitement T'en fonction des impératifs de ce dernier. Following the execution step 1004, a step 1005 of testing for the existence of a blockage of this other processing is provided. The positive response to the process blocking test step 1005 T ', resulting from the request by this processing of the transmission of a subcommand SC' to a separate process Pi ,, is followed by a step 1006 sending this SC_ subcommand to this other process

Pi .. The command SC 'and i', identifier Pi ,, are extracted from the processing T 'according to the imperatives of the latter.

 On a negative response to the test 1005 for the existence of a blocking of the treatment T ', a test step 1007 of the end of the treatment relating to this other treatment is provided.

The positive response to the test step 1007 at the end of this processing is followed by a step 1008 of transmitting a response message or an event message, extracted from the processing T ', to the module 1 monitoring and control of execution. The negative response in the test step 1007 is followed by a return to the test step 1000 of availability of an under-response from any controlled discrete process.

 Various representative examples of the processing T created to respond to a command message in

<Desc / Clms Page number 26>

r provenance du module 1 de suivi et de contrôle d'exécution seront maintenant donnés ci-après.

From the tracking and execution control module 1 will now be given below.

 There are generally three types of possible behavior: 1. The contents of the control message are transformed and sent as a subcommand message to a distinct process Pi determined. Following receipt of the corresponding sub-response message, the content of this sub-response message is transformed and returned as a response message to the initial command message, to the tracking and execution control module 1. The treatment T is then completed.

2. The content of the command message is analyzed and a response is constructed directly by the processing T and sent to the module 1 for monitoring and execution control.

3. The process T exchanges a sequence of subcommand messages / subreport messages with the different distinct processes Pi. Several subcommand messages may possibly be sent to the same process Pi or to different distinct processes. Depending on the corresponding sub-response messages, the processing T builds the response to the initial command.

These three types of behavior make it possible to construct the abstract representation RA, configured by the multiplexing operation according to the combination forming the single virtual process composed of the groups of tasks corresponding to each controlled process, each group of tasks containing the hierarchy of tasks of the process. separate correspondent.

<Desc / Clms Page number 27>

r----------------------------------------------------------. Dans le but d'illustrer chacun des trois comportements possibles, un exemple sera donné afin de montrer comment le module de multiplexage 2 transmet au module 1 de suivi et de contrôle d'exécution toutes les tâches de l'ensemble des processus distincts Pi sous la forme d'un processus virtuel unique, en relation avec la figure 2e.

r ------------------------------------------------- ---------. In order to illustrate each of the three possible behaviors, an example will be given in order to show how the multiplexing module 2 transmits to the monitoring and execution control module 1 all the tasks of the set of distinct processes Pi under the form of a single virtual process, in relation with Figure 2e.

In particular, it is recalled that, in the framework of the p JDWP protocol, the tasks of a process designated by threads in English language, are organized into groups of tasks designated by thread groups. Each task group contains a set, possibly empty group of tasks and a set, possibly empty of tasks.

 The global hierarchy of tasks in a Pi process is then defined by a set of root task groups.

 Each task also contains dynamic information associated with the execution of the corresponding task, which dynamic information can consist of an execution stack and more generally an internal state of execution of the task. The tracking and execution control module 1 can then access this state by means of specific JDWP commands implemented in the case of the JDWP protocol. The execution monitoring and control module 1 can also control the execution. execution of each task, for example, suspend this execution using other specific commands.

 To access the task hierarchy, the specific tracking and execution control protocol, JDWP uses, among other things, the following commands:

<Desc / Clms Page number 28>

Cl : VirtualMachine. ToplevelThreadGroups : renvoie la liste des identificateurs des groupes de tâches racines i C2 : ThreadGroupReference. Children : envoie le contenu d'un groupe de tâches ; C3 : ThreadReference. Name et ThreadGroupReference. Name : renvoie le nom associé à une tâche ou à un groupe de tâches donné.

Cl: VirtualMachine. ToplevelThreadGroups: Returns the list of identifiers for root task groups i C2: ThreadGroupReference. Children: sends the contents of a task group; C3: ThreadReference. Name and ThreadGroupReference. Name: Returns the name associated with a given task or group of tasks.

 Typically, the JDWP execution protocol is used to launch the command C1 and then recursively C2 to know the whole hierarchy of the tasks and groups of tasks and finally the command C3.

With the identifier, the local identifier, of all the tasks, the JDWP tracking and execution control process can then use specific commands to access their execution status and control this execution.

The answers to the aforementioned orders will now be described below:
The command Cl, as such, contains no data outside the codes which denote the type of command, class code 1, command code 5 in this case. The format of the answer is given by the table below:

<Desc / Clms Page number 29>

<Tb>
<tb> int <SEP> groups <SEP> (Number <SEP> of <SEP> thread <SEP> groups <SEP> that <SEP> follow)
<tb><SEP> number of <SEP><SEP> groups that <SEP> follow.
<Tb>

(Repeated <SEP> groups <SEP> times)
<tb> Repeated <SEP> groups <SEP> times
<tb> threadGroupID <SEP> group <SEP> (A <SEP> top <SEP> level <SEP> thread <SEP> group)
<tb> Groups <SEP> of <SEP><SEP> Tasks of <SEP> First <SEP> Level
<tb> (root)
<Tb>

In the above table, "threadGroupID" refers to a task group identifier. This identifier is an integer that can be used to find the ThreadGroup object associated with the task group. Indeed, in JAVA @ language, the JDWP protocol being relative to this language, each group of tasks, respectively each task, is represented by a JAVA @ object, instance of the class, java. lang. ThreadGroup, respectively java. lang. Thread or subclass.

 Task and task group identifiers are therefore taken in the same space as the object identifiers that the JDWP specific tracking and execution control protocol is likely to retrieve, for example by requesting the value of a variable the separate Pi process subject to monitoring and enforcement.

C2 command
The C2 command contains the following information:

<Desc / Clms Page number 30>

<Tb>
<tb> threadGroupID <SEP> Group <SEP><SEP><SEP><SEP><SEP><SEP><SEP> ID
<tb> (The <SEP> thread <SEP> group <SEP> object <SEP> ID).
<Tb>

The response to this command C2, then has the following format:

<Tb>
<tb> int <SEP> ChildThread <SEP> Number <SEP> of <SEP> Tasks <SEP> girls
<tb> s
<tb> (The <SEP> number <SEP> of <SEP> child <SEP> threads).
<Tb>

Repeated <SEP> childThreads <SEP> times <SEP>:
<tb> threadID <SEP> ChildThread <SEP> Identification <SEP> of <SEP> task <SEP> girl
<tb> (A <SEP> direct <SEP> child <SEP> thread <SEP> ID).
<tb> int <SEP> Chai <SEP> 1 <SEP> groups <SEP> Number <SEP> of <SEP> groups <SEP> of <SEP><SEP> threads
<tb> (The <SEP> number <SEP> of <SEP> child <SEP> thread <SEP> groups).
<Tb>

Repeated <SEP> childGroups <SEP> times <SEP>:
<tb> threadGroup <SEP> childGroup <SEP> SEP <SEP> Identification <SEP><SEP>Group> Tasks
<tb> ID <SEP> son
<tb> (A <SEP> direct <SEP> child <SEP> thread <SEP> group <SEP> ID).
<Tb>

 This response lists the identifiers for all tasks in this task group, followed by the list of all subtasks.

Order C3
The command C3 actually comprises 2 separate commands, relating to the reference of the task group respectively to the task reference. For the task group reference, the format of the command is as follows:

<Desc / Clms Page number 31>

<Tb>
<tb> threadGroupID <SEP> group <SEP> Identification <SEP> of <SEP> groups <SEP> of <SEP> tasks
<tb> (The <SEP> thread <SEP> group <SEP> object <SEP> ID).
<Tb>

The response gives the name of the task group as a string in the format:

<Tb>
<tb> string <SEP> groupName <SEP><SEP><SEP> name <SEP> group of <SEP> tasks
<tb> (The <SEP> thread <SEP>group's<SEP> name)
<Tb>

With respect to the job reference command, the contents of the command and the response are substantially identical to those of the task group reference command, described above.

 From the formats of the commands and responses previously described, the behavior of the multiplexing module 2 on receipt of one of these commands transmitted by the module 1 monitoring and execution control, will now be described. In other words, a processing T associated with each of the aforementioned commands will now be explained.

 It is indicated firstly that the processing T have at their disposal the coding and decoding functions of the identifiers. In general, the processing T receives local identifiers generated by the distinct processes Pi, these identifiers conforming to the JDWP protocol being constituted by integers. The coding functions make it possible, from the local identifiers and from a specific reference allocated to each distinct process Pi, to calculate IDG global identifiers.

<Desc / Clms Page number 32>

conformes et compatibles au protocole de suivi et de contrôle d'exécution spécifique, JDWP.

compliant and compatible with the specific performance monitoring and control protocol, JDWP.

 Conversely, the decoding functions make it possible, from global IDG identifiers, to find, on the one hand, the reference of the distinct process, and, on the other hand, the local identifier to the abstract representation of the latter.

 These coding / decoding functions are denoted respectively: 'must (i, IDL), i representing the distinct process specific reference,' demuxt (IDG), t designating one of the types of identifiers provided for in the tracking protocol and specific execution control such as objectID.

 It is further recalled that the arbitrary reference value specific process i = e = 0 is reserved for the designation of virtual objects generated by the method and system objects of the invention to establish the combination forming the single virtual process.

 To represent the virtual task groups associated with each distinct process Pi, the multiplexing module 2 begins by constructing identifiers to reference the task groups that it has generated. By way of nonlimiting example, it is assumed that the multiplexing module 2 uses, for each separate controlled process Pi, the local identifiers IDL, varying from 1 to n, which corresponds to the global identifiers IDG, according to the relation: VirtualThreadGroupi = mUXobjectID (E, i) = IDG

<Desc / Clms Page number 33>

Dans ces conditions, le module de multiplexage 2 1 peut répondre immédiatement à la commande Cl et la réponse 1 à cette commande est de la forme :

Under these conditions, the multiplexing module 2 1 can respond immediately to the command Cl and the response 1 to this command is of the form:

<Tb>
<tb> groups <SEP> n <SEP> Number <SEP> of <SEP><SEP> groups of <SEP><SEP> tasks that
<tb> follow
<tb> (Number <SEP> of <SEP> thread <SEP> groups <SEP> that
<tb> follow)
<tb> groupl <SEP> Virtual <SEP><SEP> Group <SEP><SEP>Tasks><SEP> First <SEP> Level
<tb> ThreadGroup, <SEP> (root)
<tb> (A <SEP> top <SEP> level <SEP> thread <SEP> group)
<tb> ...
<tb> group, <SEP> Virtual <SEP><SEP> Group of <SEP><SEP>Tasks><SEP> First <SEP> Level
<tb> ThreadGroupn <SEP> (root)
<tb> (A <SEP> top <SEP> level <SEP> thread <SEP> group)
<Tb>

By this response, the multiplexing module 2 indicates that the groups of root tasks transmitted to the module 1 monitoring and execution control, are the virtual groups created by the multiplexing module 2, itself.

On receipt of the command C2, containing the group identifier in the group field, the multiplexing module 2 then performs the following processing: - decoding of the group identifier, included in the command, using a function demultiplexing; if this decoding produces an error, it is because the identifier is malformed, that is to say that it has not been previously returned in a response of the multiplexing module 2. The response to the command is then an error code and the processing is complete;

<Desc / Clms Page number 34>

r --------------------------------------------------- - dans le cas contraire, la fonction de démultiplexage renvoie un numéro de processus distinct Pi, en l'occurrence l'indice i, et un identificateur local désigné par IDL=localGroup au processus distinct Pi considéré, selon la relation : demuXobjectID (group) = (i, localGroup) et qui désigne alors le groupe de tâches dans le processus distinct Pi précité. Il existe alors deux possibilités :

- si le numéro de processus distinct i vaut la valeur arbitraire s, ainsi que mentionné précédemment dans la description, cela signifie en fait que le groupe de tâches auquel le module 1 de suivi et de contrôle d'exécution fait référence concerne l'un des groupes virtuels créés par le module 2 de multiplexage.

r ------------------------------------------------- - - otherwise, the demultiplexing function returns a distinct process number Pi, in this case the index i, and a local identifier designated by IDL = localGroup to the distinct process Pi considered, according to the relation: demuXobjectID ( group) = (i, localGroup) and which then designates the task group in the distinct process Pi above. There are two possibilities:

if the distinct process number i is the arbitrary value s, as previously mentioned in the description, it means in fact that the group of tasks to which the execution monitoring and control module 1 refers relates to one of the virtual groups created by the multiplexing module 2.

The local identifier localGroup is then a number j between 1 and n. The descendants of this virtual group are actually the roots of the hierarchy of tasks of the distinct process Pj. For this reason, the processing T associated with the command C2 transmits the subcommand Cl to the distinct process Pj of identifier j.

While waiting for the subreponse of the distinct process Pj, the processing manager module 22 can of course execute other processes created to process another command or a sub-event from one of the processes. distinct from j or not. On receipt of the sub-response sent by the process Pj in response to the subcommand C1, the processing of the initial command may continue, however. This sub-answer is given according to the following format:

<Desc / Clms Page number 35>

<Tb>
<tb> groups <SEP> m <SEP> Number <SEP> of <SEP> groups <SEP> of <SEP><SEP> tasks that
<tb> follow
<tb> groups <SEP> m <SEP> Number <SEP> of <SEP> groups <SEP> of <SEP><SEP> tasks that
<tb> follow
<tb> (Number <SEP> of <SEP> thread <SEP> groups <SEP> that
<tb> follow)
<tb> group, <SEP> localGroup <SEP><SEP> group of <SEP><SEP><SEP> tasks first <SEP> level
<tb> (A <SEP> top <SEP> level <SEP> thread <SEP> group)
<tb> group, <SEP> localGroupm <SEP><SEP> Group of <SEP><SEP><SEP>Tasks> First <SEP> Level
<tb> (A <SEP> top <SEP> level <SEP> thread <SEP> group)
<Tb>

In this subresponse, the m localGroupm identifiers localGroupm designate the root task groups of the distinct process Pj and are naturally local identifiers to the aforementioned process. To build the response to the initial command, the command C2, it is then necessary to transform these local identifiers into global identifiers by the multiplexing function muXobjectID, this response consisting of listing these identifiers as the descendant groups of the virtual task group and to indicate that this task group does not contain any task itself. Under these conditions, the processing T builds the response in the following format:

<Desc / Clms Page number 36>

<Tb>
<tb> childthreads <SEP> 0 <SEP> Number <SEP> of <SEP> Tasks <SEP> girls
<tb> (The <SEP> number <SEP> of <SEP> child <SEP> threads).
<tb> childcroups <SEP> m <SEP> Number <SEP> of <SEP> groups <SEP> of <SEP><SEP> threads
<tb> (The <SEP> number <SEP> of <SEP> child <SEP> thread
<tb> groups).
<tb> childGroup1 <SEP> muxobjectio <SEP><SEP> Identifier of <SEP><SEP> Group of <SEP>
<tb> tasks <SEP> thread
<tb> (j, <SEP> localgroup1)
<tb> (A <SEP> direct <SEP> child <SEP> thread <SEP> group <SEP> ID).
<tb> childGroupm <SEP> muXobjectID <SEP><SEP> Identifier of <SEP><SEP> Group of
<tb> tasks <SEP> thread
<tb> (j, <SEP> localGroupm)
<tb> (A <SEP> direct <SEP> child <SEP> thread <SEP> group <SEP> ID).
<Tb>

 If, on the other hand, the index i of the distinct process Pi does not have the value s, ie i W g = 0, the aforementioned number corresponds to a real distinct process number between 1 and n. The tracking and execution control module 1 has therefore designated a real task group, belonging to the distinct process Pi, of identifier i, and asked for its threads, task groups and tasks. For this reason, the processing of the multiplexing module 2 consists in sending the separate process Pi a type C2 subcommand with the parameter localGroup and then transforming the subresponse by replacing the local identifiers by global identifiers obtained by the aforementioned multiplexing function.

 Thus, upon receipt of a sub-response of the following form:

<Desc / Clms Page number 37>

<Tb>
<tb> childthreads <SEP> m <SEP> Number <SEP> of <SEP><SEP> girls
<tb> (The <SEP> number <SEP> of <SEP> child <SEP> threads).
<tb> childThreadl <SEP> LocalThreadl <SEP><SEP> Identifier for <SEP> task <SEP> girl
<tb> (A <SEP> direct <SEP> child <SEP> thread <SEP> ID).
<tb> childThreadm <SEP> Local <SEP> Threadm <SEP><SEP> Identifier for <SEP> Task <SEP> Girl
<tb> (A <SEP> direct <SEP> child <SEP> thread <SEP> ID).
<tb> childGroups <SEP> p <SEP> Number <SEP> of <SEP> groups <SEP> of <SEP><SEP> threads
<tb> (The <SEP> number <SEP> of <SEP> child <SEP> thread
<tb> groups).
<tb> childGrouPl <SEP> Local <SEP> groups <SEP><SEP> Identifier of <SEP><SEP> Group of
<tb> tasks <SEP> thread
<tb> (A <SEP> direct <SEP> child <SEP> thread <SEP> group <SEP> ID).
<tb> chUdGroupp <SEP> LocaJGroupp <SEP><SEP> Identifier of <SEP><SEP> Group of
<tb> tasks <SEP> thread
<tb> (A <SEP> direct <SEP> child <SEP> thread <SEP> group <SEP> ID).
<Tb>

<Desc / Clms Page number 38>

r Le traitement T se termine en renvoyant au module 1 1 de suivi et de contrôle d'exécution la réponse 1 suivante :

r The processing T ends by returning to the tracking and execution control module 1 1 the following answer 1:

<Tb>
<tb> childThreads <SEP> m <SEP> Number <SEP> of <SEP> Tasks <SEP> girls
<tb> (The <SEP> number <SEP> of <SEP> child <SEP> threads).
<tb> childThread <SEP> muxobjectID <SEP><SEP> Identifier for <SEP> task <SEP> girl
<tb> (i, <SEP> local <SEP> Thread1) <SEP> (A <SEP> direct <SEP> child <SEP> thread <SEP> ID).
<tb> chjJdThreadm <SEP> muxobjectID <SEP><SEP> Identifier for <SEP> task <SEP> girl
<tb> (i, <SEP> local <SEP> Threadm) <SEP> (A <SEP> direct <SEP> child <SEP> thread <SEP> ID).
<tb> childGroups <SEP> p <SEP> Number <SEP> of <SEP> groups <SEP> of <SEP><SEP> threads
<tb> (The <SEP> number <SEP> of <SEP> child <SEP> thread
<tb> groups).
<tb> childGrouPl <SEP> mUXobjectID <SEP><SEP> Identifier of <SEP><SEP> Group of
<tb> tasks <SEP> thread
<tb> (i, <SEP> localGroupl)
<tb> (A <SEP> direct <SEP> child <SEP> thread <SEP> group <SEP> ID).
<Tb>

...
<tb> childGroupp <SEP> muxobjectiD <SEP><SEP><SEP><SEP> Identifier
<tb> tasks <SEP> thread
<tb> (i, <SEP> localgroupp)
<tb> (A <SEP> direct <SEP> child <SEP> thread <SEP> group <SEP> ID).
<Tb>

r ------------------------------------------------Enfin, le traitement de la commande C3 déclinée en référence de groupe de tâches ou en référence de tâches consiste, de façon similaire, à décoder l'identificateur donné en argument par la fonction de démultiplexage. Si cette fonction renvoie un numéro de processus distinct Pi, index j. différent de la valeur arbitraire e=0, le traitement T continue en envoyant, au processus distinct Pi précité, la même sous-commande en ayant remplacé l'identificateur global par l'identificateur local donné par la fonction de décodage des identificateurs, c'est à dire la fonction de démultiplexage, puis en renvoyant directement comme réponse la sous-réponse à cette sous-

r ------------------------------------------------ Finally , the processing of the command C3 declined in task group reference or task reference is similarly to decode the identifier given in argument by the demultiplexing function. If this function returns a separate process number Pi, index j. different from the arbitrary value e = 0, the processing T continues by sending, to the distinct process Pi above, the same subcommand having replaced the global identifier with the local identifier given by the decoding function of the identifiers, c ' that is, the demultiplexing function, then returning the sub-response to this sub-response directly as a response.

<Desc / Clms Page number 39>

r commande qui contient en fait le nom demandé. Si au contraire la fonction de démultiplexage renvoie la valeur arbitraire e=0, et comme identificateur local un numéro de processus j, index du processus distinct Pj, le traitement renvoie directement un nom arbitraire associé au processus distinct Pj précité. Ce nom arbitraire peut avoir été indiqué en paramètre au module 2 de multiplexage lors de son lancement. Il peut s'agir des chaînes de caractères "Pj"par exemple.

r command that actually contains the requested name. If on the other hand the demultiplexing function returns the arbitrary value e = 0, and as local identifier a process number j, index of the distinct process Pj, the processing directly returns an arbitrary name associated with the distinct process Pj mentioned above. This arbitrary name may have been indicated as a parameter to the multiplexing module 2 when it is launched. It can be strings of characters "Pj" for example.

 The complete processing of the aforementioned commands C1 to C3 specific to the JDWP protocol has been given in detail. With reference to the above-mentioned commands, it is understood that, by means of the multiplexing functions of the identifiers, the multiplexing module 2 enables the module 1 for monitoring and execution control to manage a single JDWPO link, to simultaneously understand the n process Pl with i E [1, n] connected to the multiplexing module 2 and in particular to see their hierarchy of tasks in the form of a single hierarchy forming a single virtual process, composed of as many groups of tasks as of processes controlled.

Regarding the processing of each JDWP command these processes will not be described in detail because the really different processing at the level of the multiplexing module 2 are in fact few. The following general indications will however be indicated:
Most of the time, the content of a command entering the multiplexing module 2 contains identifiers which, decoded, make it possible to identify a

<Desc / Clms Page number 40>

r processus distinct Pi, d'indice i. La commande est alors simplement passée au processus distinct considéré en remplaçant les identificateurs globaux par leur identificateur local au niveau du processus Pi. La réponse est transformée de façon réciproque en remplaçant les identificateurs locaux par leur codage global.

r distinct process Pi, index i. The command is then simply passed to the distinct process considered by replacing the global identifiers by their local identifier at the level of the process Pi. The response is transformed reciprocally by replacing the local identifiers by their global encoding.

 The commands relating to the tasks and task groups undergo a specific specific processing for mixing the task hierarchies of each of the separate processes as described in detail above.

 When the control concerns virtual elements, created from scratch by the multiplexing module 2 itself, such as, for example, the virtual task groups previously described in the description, specific processing local to the multiplexing module 2 is executed. For example, if the class of a virtual task group object is requested, the multiplexing module 2 directly responds "java.lang.ThreadGroup" without going through a separate process.

 The commands relating to the references of the JAVA classes @ require, as well as the tasks, a particular treatment. Indeed, several classes of the same name can coexist in different processes.

To distinguish these different versions of the same class, it is possible to use the notion of class loader, also called "class loader" in English language. Just as task groups are used to prioritize tasks, class loaders are used to prioritize classes. In JAVA, each class is associated with a given "class loader" and two classes associated with two different "class loader" are always

<Desc / Clms Page number 41>

,--------------------------------------------- : considérées comme différentes même si ces deux classes ont le même nom. De plus, chaque machine virtuelle JAVAS possède un"class loader"système distinct. Pour gérer toutes les classes de tous les processus distincts Pi, le module de multiplexage 2 peut alors procéder de la façon suivante : chaque classe d'un processus distinct Pi, d'indice i associé à un"class loader"différent du"class loader"système de i reste associé à ce"class loader", son identificateur local est simplement convenablement multiplexé avec les identificateurs des objets tels que

les"class loaders"des autres processus distincts. En revanche, si une classe est associée au"class loader" système du processus distinct Pi, indice i, alors dans la représentation présentée au module 1 de suivi et de contrôle d'exécution, le module de multiplexage 2 l'associe à un"class loader"virtuel représentant le

"class loader"système de ce processus considéré. Enfin, le"class loader"système du processus virtuel unique simulé par le module de multiplexage 2 lui-même est réservé aux classes des objets virtuels créés par le module de multiplexage 2 comme les groupes de tâches virtuels ou les"class loaders"virtuels. De cette manière, il n'existe pas de risque de mélange des classes portant le même nom mais provenant de processus distincts différents.

, ---------------------------------------------: considered different even if these two classes have the same name. In addition, each JAVAS virtual machine has a separate "class loader" system. To manage all the classes of all the distinct processes Pi, the multiplexing module 2 can then proceed as follows: each class of a distinct process Pi, of index i associated with a "class loader" different from the "class loader""i system remains associated with this" class loader ", its local identifier is simply properly multiplexed with object identifiers such as

the class loaders of the other distinct processes. On the other hand, if a class is associated with the "class loader" system of the distinct process Pi, index i, then in the representation presented to the module 1 of monitoring and execution control, the multiplexing module 2 associates it with a " class loader "virtual representing the

"class loader" system of this considered process. Finally, the "class loader" system of the single virtual process simulated by the multiplexing module 2 itself is reserved for classes of virtual objects created by the multiplexing module 2 such as virtual task groups or virtual class loaders. In this way, there is no risk of mixing classes with the same name but from different distinct processes.

 If necessary, the processing of the JDWP command 9 may be more complex. This is the case, for example, for JDWP protocol commands that query the overall state of the system subject to monitoring and execution control. For example, the VirtualMachine command. AllClasses of the JDWP protocol returns the

<Desc / Clms Page number 42>

r liste des identificateurs de toutes les classes couramment chargés dans le processus soumis au suivi et au contrôle d'exécution. Pour traiter une telle commande au niveau du module de multiplexage 2, on comprend que ce dernier doit envoyer cette commande à tous les processus distincts Pi connectés au module de multiplexage 2 puis concaténer toutes les sous-réponses pour former la réponse globale à la commande précitée.

r list of the identifiers of all the classes currently loaded in the process submitted to the monitoring and execution control. To process such a command at the level of the multiplexing module 2, it is understood that the latter must send this command to all the separate processes Pi connected to the multiplexing module 2 and then concatenate all the sub-responses to form the overall response to the aforementioned command .

 A specific example of implementation of the method that is the subject of the present invention, by means of a set of instructions in accordance with the JDWP protocol will now be given in connection with FIG. 2e, for a configuration of distinct controlled processes Pi corresponding to the example given. and described in connection with FIG. 1c, the commands implemented corresponding to the commands C1, C2, C3 previously described. With reference to the aforementioned figures, the module 1 for monitoring and execution control transmits, to the multiplexing module 2, a command C1 having for object the return by the multiplexing module 2 of the list of identifiers of the groups of root tasks. It is understood in particular that from the pairs E = 0 and i = [1, 2, 3] the multiplexing module 2 associates with the pairs (s, l), (8, 2) and (s, 3) the values global identifiers IDG = [0, 1, 2] according to the association table TAB, of FIG. 2e. This association table can be established by prior communication to module 2 of the parameter i = [1, 2, 3] making it possible to identify the distinct controlled processes Pi = [Pi, P2, P3].

<Desc / Clms Page number 43>

r Le module 2 de multiplexage répond directement à la commande Cl par l'envoi d'une réponse RI contenant les identificateurs globaux IDG avec IDG EE [0, 1, 2] représentatifs, au moins partiellement, du processus virtuel unique constitué par les processus distincts contrôlés Pi, P2 et P3.

r The multiplexing module 2 directly responds to the command C1 by sending an IR response containing the IDG global identifiers with IDG EE [0, 1, 2] representative, at least partially, of the unique virtual process constituted by the processes separate controlled Pi, P2 and P3.

 The set of distinct controlled processes P1, P2 and P3 being known from the module 1 for monitoring and control of execution by the global identifiers of the virtual task groups 0,1, 2, the latter then proceeds to a successive exploration of the groups of tasks and tasks that make up each separate controlled process.

So, successively: For the process Pl: IDG = 0
Sending a C3 command to the multiplexing module 2 to obtain the return of the name associated with a task group or a task. The command C3 is sent to the multiplexing module 2 with the value of the global identifier, IDG = 0;
The multiplexer module 2 sends a response R3 to the command C3 containing the name of the distinct controlled process "Pi" or simply the value of i = 1, these elements being calculated from the association table TAB1.

 In the hypothesis of an exploration "width first", other commands C3 and R3 responses, symbolized in Figure 2e by successive points can be generated to obtain the name of the separate process associated or more simply the value i = 2, i = 3 corresponding.

<Desc / Clms Page number 44>

r Le module 1 de suivi et de contrôle d'exécution procède ensuite à l'exploration des tâches et groupes de tâches du processus distinct contrôlé Pi par :
Envoi d'une commande C2 au module 2 de multiplexage avec la valeur de l'identificateur global IDG=0.

r The tracking and execution control module 1 then proceeds to the exploration of the tasks and task groups of the separate controlled process Pi by:
Sending a C2 command to the multiplexing module 2 with the value of the global identifier IDG = 0.

 The multiplexing module 2 sends to the distinct controlled process P1, discriminated from the association table TABU, a subcommand SC1 corresponding to a command C1 previously described.

sous-commande SC1 comprenant les identificateurs locaux IDL=14 et IDL=16 des groupes de tâches A [14] et B [16] du processus distinct contrôlé Pi de la figure le. The separate controlled process P1 sends to the multiplexing module 2 a subreponse SR1 to this

SC1 subcommand comprising the local identifiers IDL = 14 and IDL = 16 of task groups A [14] and B [16] of the separate controlled process Pi of FIG.

The multiplexer module 2 then calculates the global identifiers IDG = [3, 4] corresponding to the pairs i = 1 (1,14) and (1,16) according to the association table TAB2. It transmits to the tracking and execution control module 1 a response R2 comprising global identifiers IDG = [3, 4] representative of groups of tasks A [14] and B [16] constituting the distinct controlled process Pi.

Task group task crawling can be deferred to perform "first breadth" crawling, with runtime tracking and execution module 1 running to crawl task groups and separate controlled process tasks P2.

<Desc / Clms Page number 45>

r Pour le processus P2 : IDG=l L'envoi d'une commande C3 pour l'obtention du nom du processus distinct P2 aété suppose exécutée, comme dans le cas du processus distinct Pi précédemment décrit.

For the process P2: IDG = 1 The sending of a command C3 to obtain the name of the distinct process P2 has been assumed to be executed, as in the case of the distinct process Pi previously described.

 Sending a C2 command to the multiplexing module 2, with the value of the global identifier, IDG = 1.

 The multiplexing module 2 sends to the separate controlled process P2, discriminated from the association table TAB1, a subcommand SC2 corresponding to a command C1 described above.

 The controlled separate process P2 sends to the multiplexing module 2 an SR2 sub-response to this subcommand SC2 comprising the local identifier IDL = 0 of the task group A [0] of the separate controlled process P2 of FIG.

 The multiplexer module 2 then calculates the global identifier IDG = 5 corresponding for i = 2 to the pair (2,0) according to the association table TABr.

L'exploration"largeur d'abord"peut être poursuivie pour le processus distinct contrôlé P3 mais ne sera pas décrite pour ce dernier. It transmits to the tracking and execution control module 1 a response R2 to the command C2 comprising the global identifier IDG = 5, representative of the task group A [0] element of the separate controlled process P2.

The exploration "width first" can be continued for the separate controlled process P3 but will not be described for the latter.

 This exploration break "width first" is represented by the dashed lines.

 To ensure a complete exploration of the separate controlled P2 process, it is then necessary

<Desc / Clms Page number 46>

d'effectuer une exploration en profondeur au moyen d'une commande C2.

perform an in-depth exploration using a C2 command.

 The tracking and execution control module 1 transmits a command C2 to the multiplexer module 2 with the global identifier IDG = 5.

 The multiplexer module 2 sends to the distinct controlled process P2, discriminated from the association table TABr a subcommand SC2 corresponding to a command C2 relating to the task group A [0] for obtaining the identifier of the one or more The child tasks in this task group and the child task group (s) in this task group.

 Controlled distinct process P2 refers to this subcommand SC2 a subreponse SR2 containing the only local identifier IDL = 1 of task a [1], no hierarchical task group lower than group A [0] does not exist.

 The multiplexer 2 calculates the global identifier IDG = 6 for the pair i = 2 (2.1) according to the association table TABr + It transmits to the module 1 tracking and execution control the response message R2 in response to the command C2 comprising the global identifier IDG = 6 representative of the task a [1] of the process P2.

 Of course, the different association tables TAB1, TAB2, ..., TABr, TAB ,,, are successively calculated and stored in a memory for example in order to conduct the monitoring and the execution control of the set.

 An example application of the method and system for monitoring and controlling the simultaneous execution of a plurality of separate processes executed independently

<Desc / Clms Page number 47>

r sur des systèmes informatiques distincts sera maintenant donné en liaison avec la figure 3.

r on separate computer systems will now be given in connection with Figure 3.

In FIG. 3 above, there is shown by way of nonlimiting example, a plurality of distinct applications constituting distinct processes P1, P2, P3 and P4, each application possibly being, via a debugging driver. , networked via the Internet for example, this network providing a simple support for the JDWP protocol
More specifically, it is indicated that the process P1 is for example constituted by an embedded system such as a card, such as a bank card or SIM card, to which is associated a card reader and a so-called debugging driver allowing to constitute a JAVAS virtual machine authorizing the implementation of the JDWPO protocol.

The P2 process is implemented by a GSM mobile telephone terminal, which is connected to the Internet network via a debugging driver of the same nature as in the case of the separate process Pi and thus also allowing the implementation of the JDWP protocol. By way of nonlimiting example, it is indicated that the process Pi and the process P2 are for example linked by an ISO 7816 link, the application and the process P 1 which may consist, for example, in a payment application of the telephone units consumed by the GSM terminal and in particular by the process P2 driven by the latter.

 The separate process P3 is a process carried out by an SMS radio station connected by SMS radio link to the GSM terminal driving the distinct process P2 mentioned above.

<Desc / Clms Page number 48>

r La station SMS est elle-même reliée par le réseau Internet à un serveur de type OTA, pour serveur On The Air, ce serveur étant lui-même constitué par une machine virtuelle -JAVA@ reliée au réseau Internet, cette machine permettant

1 &commat; la mise en oeuvre du protocole JDWP.

r The SMS station is itself connected by the Internet to an OTA server, for On The Air server, this server being itself constituted by a virtual machine -JAVA @ connected to the Internet, this machine allowing

1 &commat; the implementation of the JDWP protocol.

 The separate process P4 is a database server consisting of the same by a virtual machine JAVA this server being connected on the one hand to the OTA server driving the separate process P3 and, on the other hand, to the Internet.

 The simultaneous execution monitoring and control system SY, which is the subject of the present invention, is itself interconnected to the Internet network in order to allow the implementation of the method of monitoring and controlling the simultaneous execution of all the distinct processes Pi to P4 previously mentioned.

 More specifically, it is indicated that the module 1 for monitoring and execution control is connected to the module 2 multiplexer via a single link for conducting the JDWP protocol mentioned above. The module 2 multiplexer is itself connected to the Internet network by a link allowing of course the implementation of the JDWP protocol vis-à-vis all separate processes.

 Thus, in a nonlimiting manner, the multiplexer module 2 can be installed in any machine and the module 1 tracking and control of execution and the module 2 multiplexer constituting the SY system, in accordance with the object of this invention,

<Desc / Clms Page number 49>

 then be relocated to any point on the Internet.

 Finally, the method and system that are the subject of the present invention appear particularly well suited to monitoring and controlling the execution of applications in the case where one of the distinct controlled processes is not constituted by a JAVA® virtual machine but simply by a program consisting of a sequence of interpreted sequential instructions, more commonly referred to as a "script" in Anglo-Saxon language. Such a mode of implementation will now be described with reference to FIG. 3b.

utilise assez communément, dans le contexte JAVA CARD@, un "script"pour engendrer des instructions de type APDU à destination de la carte à microprocesseur. Ces instructions sont transmises par un protocole spécifique ISO 7816 par exemple. More particularly as illustrated for the separate controlled process P1 of FIG.

quite commonly uses, in the JAVA CARD @ context, a "script" to generate APDU-type instructions for the microprocessor card. These instructions are transmitted by an ISO 7816 specific protocol for example.

 These APDU type instructions, usually in the form of a list, are sent in sequence to the card but may include some control structures such as loops or logic tests, for example.

The separate P2 process is implemented through the interpretation of the "script". In addition, a debugging driver makes it possible to ensure a link that complies with the chosen specific monitoring and performance control protocol, in this case the JDWPO protocol in the example of FIG. 3b. The debug driver acts on the interpretation process under the control of the JDWP protocol.

1

<Desc / Clms Page number 50>

r Le procédé objet de la présente invention apparaît particulièrement avantageux dans la mesure où celui-ci permet decontrôler l'envoidesinstructions APDU et de suivre la progression de l'exécution par interprétation du

"script" ; la seule condition réside dans le fait que la sémantique du langage du"script"est suffisamment simple et correspond sensiblement à un sous-ensemble de la sémantique du langage JAVA.

The method which is the subject of the present invention appears to be particularly advantageous insofar as it makes it possible to control APDU instructions and to monitor the progress of the execution by interpretation of the

"script"; the only condition is that the semantics of the "script" language are sufficiently simple and correspond substantially to a subset of the semantics of the JAVA language.

 In this case, the aforementioned condition being satisfied, the method which is the subject of the invention, for any distinct process implemented by an interpretation of the instructions of a sequential language, is such that the virtual abstract representation of this process comprises at least one only task, in a single task group, this unique task being associated with the sequence of interpreted instructions. Thus, the execution of this interpretation is tracked and controlled through the specific protocol, JDWPO, from the commands, responses and events relating to that single task.

 When, in a particular way, the specific protocol chosen is the JDWP protocol, the virtual abstract representation comprises, besides the only task in a single group of tasks associated with the succession of interpreted instructions, a single class and a single method in this class.

 Under the aforementioned conditions, the set of control points of the "script" constituted for example by each line of the latter, can be represented by a virtual line, to which a global identifier IDG

<Desc / Clms Page number 51>

r est associé, dans l'unique méthode de l'unique classe de cette représentation virtuelle.

r is associated, in the unique method of the unique class of this virtual representation.

A suitable adaptation of the interpreter of the "script" to construct the aforementioned virtual abstract representation, by means of the introduction of IDL local identifiers for example, makes it possible to follow and control the execution by interpretation of the latter in accordance with the object method. of the present invention, in particular when the execution monitoring and control protocol chosen is the JDWP protocol
Under these conditions, the method and system objects of the present invention make it possible to track and control the simultaneous execution of a plurality of distinct processes and interpretations of instructions of sequential languages such as "scripts" .

appliquette, JAVA CARDs à partir d'une seule interface de contrôle.Thus, and particularly advantageously, they make it possible to ensure the simultaneous execution monitoring and control of a "script" generating APDU instructions and an application, also called

applet, JAVA CARDs from a single control interface.

Claims (11)

 1. A system for tracking and controlling the simultaneous execution of a plurality of separate processes executed independently on separate computer systems, each of these processes containing a set of tasks organized into a hierarchy of task groups, execution each of said processes being individually tracked and controlled through a specific tracking and execution control protocol independent of each of said processes, said protocol allowing an abstract representation of each process and the set of tasks of each process, characterized in that said system comprises: a monitoring and execution control module for implementing said monitoring and execution control protocol; multiplexing means interconnected, on the one hand, with said execution monitoring and control module, and, on the other hand, with each of said distinct processes, said multiplexing means making it possible to configure said abstract representation in a combination forming a single virtual process grouping together all the tasks of each of the controlled processes, which makes it possible to monitor and control the simultaneous execution by multiplexing of said plurality of processes.

 2. System according to claim 1, characterized in that, for a set of distinct processes comprising at least one group of tasks, said combination comprises a virtual task group associated with each of said processes, each virtual task group. <Desc / Clms Page number 53>  r comprising the hierarchy of the task groups of the corresponding process, the set of virtual task groups and said task groups associated with each of these virtual task groups constituting said abstract representation according to a single virtual process.

 3. System according to one of claims 1 or 2, characterized in that for a specific tracking and execution control protocol and a connection between said tracking and execution control module and said multiplexer means, on the one hand, and between said multiplexer means and each separate process, on the other hand, the exchange of information between said tracking and execution control module and said multiplexer means consists of an exchange of control messages, messages response and event messages, and in that the exchange of information between said multiplexer means and each distinct process consists of an exchange of subcommand messages, sub-response messages or sub-event messages respectively, said multiplexer means receiving control messages, sub-response messages and sub-event messages and transmitting response messages, subcommand messages and messages; event messages, this transmission being performed with reference to said grouping of the set of tasks of each of the controlled processes constituting said abstract representation according to a single virtual process.  4. System according to claim 3, characterized in that said multiplexer means comprise at least: <Desc / Clms Page number 54>  r a command management module issued by said monitoring and execution control module; an event management module transmitted by each process; a processing management module simultaneously allowing: under the control of said command management module, to create a processing for each command received, said processing making it possible, on the one hand, to send sub-command messages to and receiving the corresponding sub-response messages from these processes, and, on the other hand, sending the response message corresponding to this command to said execution tracking and control module; under the control of said event management module, to create a processing for each sub-event message received from one of said processes, said processing allowing, on the one hand, to send subcommand messages to and receiving the corresponding sub-response messages from these processes, and on the other hand, sending event messages to said execution tracking and control module.

 5. System according to claim 4, characterized in that said abstract representation being formed by means of identifiers, said processing management module includes a multiplexing management module of said identifiers, said identifiers comprising global identifiers associated with said combination constituting said unique virtual process and <Desc / Clms Page number 55>  r local identifiers associated with the abstract representation of each of the distinct controlled processes, said multiplexing management module allowing the mapping between global identifiers and local identifiers, and vice versa.

 6. System according to one of claims 4 or 5, characterized in that the execution of the processing management by said processing management module comprises at least: a step of testing the availability of a sub-response from one of said distinct processes, and on a positive response to said subresponse availability test step; a test step of existence of a blocked processing waiting for this sub-response, the negative response to said test step of existence of a blocked processing being followed by a return to said availability test step and the positive response to said test step of existence of a blocked treatment being followed by a step of unblocking said blocked processing, and following said step of unblocking said blocked processing, and, in addition, on a negative response to said step availability test of an under-response; an availability test step for execution of a processing, the negative response to this availability test step for execution being followed by a return to said availability test step of a sub-response and the positive response to this an availability test step for execution being followed by a step of executing a calculation step of this processing, and following this execution step; <Desc / Clms Page number 56>  r a test step of existence of a blockage of this treatment, the positive response to this test step of existence of a blockage of this treatment resulting from the request by this treatment of the emission of a sub-system. command to a process being followed by a step of sending this subcommand to this process, and following the negative response to this test step of existence of a blockage of this processing; an end-of-treatment test step, the positive response to this end-of-treatment test step being followed by a step of transmitting a response message or an event message by said multiplexer means tracking and execution control module and the negative response to this end of processing test step being followed by a return to said availability test step of an under-response from any other process.

 7. System according to one of claims 1 to 6, characterized in that said monitoring protocol and execution control constituting a specific monitoring and execution control protocol is the JDWPO protocol.  A method of tracking and controlling the concurrent execution of a plurality of distinct independently executed processes on separate computer systems, each of which processes a set of tasks organized into a hierarchy of task groups, the execution of each said processes being individually tracked and controlled through a specific tracking and execution control protocol independent of each of said processes, said protocol <Desc / Clms Page number 57>  r allowing, from commands addressed to a process, responses addressed by this process and specific events of this process, to generate an abstract representation of this process and all the tasks of this process, characterized in that that this method consists, by means of a single link supporting said specific tracking and execution control protocol: to generate at least one follow-up and execution control command in accordance with said monitoring and control protocol of specific execution; multiplexing all the commands, responses and events generated in accordance with said specific control and execution monitoring protocol, the multiplexing operation making it possible, on the one hand, to route each control and monitoring command to execution to each of said processes, and, on the other hand, the transmission of the responses and events from each process, the set of follow-up and execution control commands, responses and multiplexed events constituting said abstract representation. configured by said multiplexing operation in a combination forming a single virtual process grouping together the set of tasks of each of the monitored processes, thereby providing simultaneous execution monitoring and control of said plurality of processes on said single link .

 9. Method according to claim 8, characterized in that the abstract representation of each distinct controlled process being formed of elements associated with each <Desc / Clms Page number 58>  r to a single local identifier, said elements comprising the tasks or groups of tasks of said distinct controlled process, said multiplexing operation comprises: - associating with each distinct controlled process and the virtual process a specific process reference, one of the specific process reference values from the set of specific process reference values being representative of said single virtual process from said multiplexing operation, the pair formed by a local identifier and a specific process reference value being representative of the element of the abstract representation of the separate controlled process associated with this local identifier, respectively of a virtual element constituting said combination forming said single virtual process; associating with any pair formed by a local identifier and a specific process reference value a distinct global identifier, the set of distinct global identifiers obtained for each virtual task group constituting said combination forming said single virtual process, the setting correspondence between global identifiers and local identifiers by controlled distinct processes making it possible to perform said multiplexing operation.

 Method according to one of claims 8 or 9, characterized in that said specific monitoring and execution control protocol is the JDWP protocol. <Desc / Clms Page number 59>  r ------------------------------------------------- - 11. Method according to one of claims 8 to 10, characterized in that, for any distinct process implemented by an interpretation of the instructions of a sequential language, said virtual abstract representation of said process comprises at least one task in a only group of tasks associated with the sequence of interpreted instructions, the execution of this interpretation being monitored and controlled by means of said specific protocol from the commands, the responses and the events relating to this single task, which makes it possible to performing the control and the simultaneous monitoring of the execution of a plurality of processes, at least one of these processes being implemented by an interpretation of instructions of a sequential language.