EP1687719A1 - Dispositif et procédé asynchrones et automatiques de transmission de résultats entre objets communicants - Google Patents

Dispositif et procédé asynchrones et automatiques de transmission de résultats entre objets communicants

Info

Publication number
EP1687719A1
EP1687719A1 EP04805534A EP04805534A EP1687719A1 EP 1687719 A1 EP1687719 A1 EP 1687719A1 EP 04805534 A EP04805534 A EP 04805534A EP 04805534 A EP04805534 A EP 04805534A EP 1687719 A1 EP1687719 A1 EP 1687719A1
Authority
EP
European Patent Office
Prior art keywords
identifier
empty
empty object
content
message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP04805534A
Other languages
German (de)
English (en)
Inventor
Denis Caromel
Romain Quilici
Christian Delbe
Ludovic Henrio
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Institut National de Recherche en Informatique et en Automatique INRIA
Original Assignee
Institut National de Recherche en Informatique et en Automatique INRIA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Institut National de Recherche en Informatique et en Automatique INRIA filed Critical Institut National de Recherche en Informatique et en Automatique INRIA
Publication of EP1687719A1 publication Critical patent/EP1687719A1/fr
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services

Definitions

  • the invention relates to the field of communications by remote procedure calls (of RPC type for Remote Procedure Call) between a local process and a remote process.
  • RPC communications can use objects in the sense of object-oriented language.
  • a so-called calling process sends a request to a called process, the calling process blocking its execution until receiving the result of its request by the called process.
  • the communications established between the processes are of the asynchronous RPC type, that is to say that the source process continues its execution after the sending (or filing) of a request (ditmessage from call).
  • the target process first finishes the execution of its current tasks then executes the remote method in parallel with the execution of the source process and makes available the parameters of the response at the end execution of the remote method.
  • the source process can thus obtain its response parameters.
  • the invention improves the situation.
  • the invention relates to a method for managing a remote method call in object-oriented language, by asynchronous communication, between a local process of a station and a process distant from another station, such a call comprising a request for one of the processes, followed by a response from the other process, this process consisting in a- detecting the transmission of an empty object as a parameter of a request or a response before sending a process local to a remote process, the calculation of the content of this empty object and its provision having been requested from a knowing process, b- to process the empty object with a view to making the content of this object available to the remote process, c- to continue sending said request or response on a processing condition satisfied.
  • the invention also relates to a computer station, comprising
  • a protocol module capable of processing, by asynchronous communication, remote method calls between a local process and a process remote from another station, such a call comprising a request from one of the processes, followed by 'a response from the other process.
  • the computer station comprises: a suitable monitor, on detection of the event that an empty object intervenes as a parameter of a request or a response to be sent by the local process to the remote process , the calculation of the content of this empty object and its provision having been requested to a knowing process, at. process the empty object in order to make the content of this object available to the remote process,. continue sending the request or response on a processing condition satisfied.
  • the computer device according to the invention can include numerous additional characteristics which can be taken separately and / or in combination and which will be explained in the detailed description.
  • FIG. 1 represents a network of stations communicating by calling asynchronous remote methods or procedures (RPC),
  • RPC remote methods or procedures
  • FIG. 2 illustrates the communication between two stations in FIG. 1 using the asynchronous RPC remote procedure call
  • FIG. 3-1 illustrates a network of stations using the asynchronous RPC remote procedure call with return of results according to the invention
  • FIG. 3-2 illustrates in detail the components of a station according to the invention
  • FIG. 4 is a flowchart illustrating the method of sending a request or result for asynchronous RPC communications
  • FIG. 5 is a flowchart detailing a first embodiment of a method associated with the shipment and called in step 702 of FIG. 4,
  • FIG. 6 is a flowchart detailing a first embodiment of a method for automatic continuation of results associated with the first embodiment of the method of FIG. 5,
  • FIG. 7 is a flowchart detailing a second and a third embodiment of the method associated with the shipment and called up in step 702 of FIG. 4,
  • FIG. 8 is a flowchart detailing a second embodiment of the method of automatic continuation of results associated with the second embodiment of the method of FIG. 7,
  • FIG. 9 is a flowchart detailing a third embodiment of the method of automatic continuation of results associated with the third embodiment of the method of FIG. 7,
  • FIG. 10 is a flowchart detailing a waiting process by necessity of result according to the invention.
  • FIG. 11 illustrates a method of receiving a message after sending a message from step 708 of FIG. 10,
  • FIG. 12 is a flow chart detailing a fourth embodiment of the method of automatic continuation of results associated with the methods of FIGS. 10 and 11.
  • FIG. 1 shows a network of stations communicating with each other.
  • "Computer station” means any computer element capable of exchanging data.
  • this element could be a mobile communication terminal like a mobile phone or a laptop, or on the contrary a fixed communication terminal like a computer PC type.
  • Each station ST1, ST2, STO comprises an operating system ST1-2, ST2- 2, STO-2, a memory ST1-4, ST2-4, STO-4 not shared, a process PI, P2, PO working in object-oriented language, and an ST1-6, ST2-6, STO-6 communications protocol module of the communications type by asynchronous remote procedure call (RPC) type of procedures or procedures capable of working with objects in the sense of object oriented language.
  • RPC remote procedure call
  • This protocol module is capable of processing, by asynchronous communication, RPC remote method calls between a local process and a process distant from another station.
  • the protocol module includes a library of objects comprising methods or functions which allow calling methods remotely.
  • the term "process" denotes an instruction program which may include calls to methods, operations by way of example.
  • the environment constituted by an operating system ST1-2, a non-shared memory ST1-4, and a communication protocol module ST1-6 makes it possible to execute local processes correcting PI in object-oriented language.
  • Each station is linked to the other stations by a link which can be physical or virtual, for example cables, optical fibers or radio waves. More precisely and by way of example, each station can be connected to a network 10 by a link 10-ST1, 10-ST2, 10-ST0, the stations being thus linked together.
  • the asynchronous RPC type protocol module allows for a so-called client PI process to call a method of the so-called server P2 process located in the station ST2.
  • This call A is also called a request and includes parameters Pa.
  • a request is an object representing a method call and comprising the method and the call parameters.
  • the PI client process includes an object with a local method with the same name as the remote method to call.
  • This local method of the station ST1 calls certain methods in the object library of the protocol module, for example a library of Java® type. The latter support network connections, the passage of Pa parameters and the return of results also called RES response.
  • the PI client process deposits the request with its call parameters in the station ST2 and then continues its execution.
  • the P2 server process finishes executing its tasks in progress before call the local method of station ST2 with the call parameters and return the response RA, that is to say the result to station ST1.
  • the client process PI does not call the local method but only files a request on the side of the station ST2 and then continues its execution.
  • the server process P2 continues its current execution during the filing of the request then responds to the request by sending a response to the client process PI.
  • any process on the network uses the asynchronous RPC type protocol module library to establish communications by remote method calls.
  • any process can be both client and server, namely to send and receive a request.
  • We will therefore speak of a source or local process when the process sends requests or responses, of target or remote process when the process receives requests or responses.
  • the communications established between the processes are of the asynchronous type, that is to say that the source process continues its execution after the sending (or filing) of a request (call message) or of a response.
  • the target process first finishes the execution of its current tasks then executes the remote method in parallel with the execution of the source process and makes available the parameters of the response at the end execution of the remote method.
  • the source process can thus obtain its response parameters.
  • an object is identified by an identifier and includes a structure which can either be empty or include content (parameter values, methods).
  • the representation of a response not yet determined can be an object identifier indicated as empty or partially empty. This object is linked to a flag indicating that this object is empty or partially empty.
  • the object can be completely empty, i.e. an object whose content is still unknown, or as partially empty, i.e. an object whose content is only partially known.
  • This empty object identifier names an object whose content, or at least part of it, will be the response to a given request.
  • a request or response sent by a local process to a remote process can have parameters including one or more ids of empty objects. More specifically, a request sent by a client process to a server process can have parameters comprising one or more identifiers of empty objects. Likewise, a response sent by a server process to a client process can have parameters comprising one or more identifiers of empty objects. In these cases, it is important that remote processes can get the content of these empty objects once they are available.
  • knowing the content of an empty object is essential.
  • an empty object identifier is used by a process.
  • use of an empty object identifier is meant an operation for which determining the content of this object is necessary.
  • An operation is said to be strict and can be, without limitation, an addition, a subtraction, a division, a multiplication if the identifier of the object names an object representing a number.
  • Figure 3-1 illustrates the network of stations in Figure 1. Identical references to those in Figure 1 denote the same elements.
  • the source process PI creates an empty object identifier ID-01 representing the response to the request RPCO-a, serializes the request as presented in FIG. 4 described below , deposits in station ST0 the request RPCOa with its call parameters which include the identifier of the empty object ID-01 then continues its execution.
  • the request is received, deserialized, then put on hold in a queue of requests to be processed by the target process PO.
  • the target process also called knowing process in particular during the creation of the request RPCO-a.
  • the target process PO When the content of the empty object is obtained by the target process PO, the CRES result pair comprising the content CONT-01 and the identifier ID-01 of the empty object is made available.
  • the target process PO obtains the content CONT-01 of the empty object by calculation and is called the knowing process.
  • the PO process can also store the identifier of the PI process associated with the identifier of the empty object in order to return the result to the PI process by the response R0.
  • the CONT-01 content can itself contain the identifier of another empty object whose content will be calculated by another process.
  • the identifier of this object can either be used by the PI process or passed as a parameter in an RPCl-a request to the target process P2 as shown in Figure 3-1.
  • the PI process When the content of the empty object is known to the PI process, it updates the empty object by integrating the content into the structure of the empty object.
  • Figure 3-2 illustrates in more detail the modules capable of working in relation to the PI process.
  • the station includes the following components:
  • a detector for example a serializer ST1-20, in relation to the PI process and suitable for detecting the event that an empty object identifier intervenes as a parameter of a request or a response to be sent by the process local PI to another remote P2 process, - an update module ST1-16 able, from the identifier of an empty object and the determined content of this empty object, to integrate this content into the structure of the empty object, and thus update the empty object - a monitor ST1-12 in connection with the detector ST1-20 and the local PI process and clean, in response to the detection of the detector, to intercept the shipment, to process the empty object in order to make the content available from this object to the remote process and continue sending the request or response on a satisfied processing condition.
  • an update module ST1-16 able, from the identifier of an empty object and the determined content of this empty object, to integrate this content into the structure of the empty object, and thus update the empty object - a monitor ST1-12 in connection with the detector ST1-20 and the local PI process and
  • the monitor comprises a set of processes called intervention processes which are executed according to whether the process is a source or knowing process, a knowing process being that which calculates the content of an empty object.
  • the monitor includes a process called waiting by necessity, a process associated with sending a request / result, a process called automatic continuation. The execution of this latter process can be carried out in parallel and independently of the other processes.
  • the function of this automatic continuation process is to convey the determined contents of empty objects to all the processes likely to need them.
  • the monitor also works with at least one table called TCR Content Table to indicate the identifier of empty objects and the identifier of a process.
  • This table is used to transmit the content of the empty object to the identified process.
  • Such a table will be used either in the knowing process or in all the processes having transmitted an empty object identifier, for example a source process, according to the embodiment of the invention as developed below.
  • the process PO adds in its Table of Contents to be retransmitted TCR0 the couple comprising the identifier ID-01 of the empty object and the identifier ID- P1 of the source process to which the content of the empty object is to be sent.
  • FIGS. 4 to 9 For the embodiments of FIGS. 4 to 9, one places oneself on FIG. 3-1 in the case where the process PI has sent a request RPCO-a to the process knowing PO and seeks to send to the process P2 a request RPCl-a including the identifier ID-01 of the empty object or in the case where the PI process has received an empty object identifier ID-01 created by another process of the network.
  • Figure 4 illustrates the serialization of a request or response before it is sent.
  • a first object among the parameters of the request or of the response to be sent is serialized.
  • the serialization mechanism which allows the request or the response to be sent after copying it, includes in particular a detection of an empty object. To this detection is added a management of this empty object thanks to the call of a method associated with the sending of a message according to FIG. 5 or FIG. 7 for example. If, in step 704, the parameters of the request or of the response include other objects, these are also serialized by recursive call of the method of FIG. 5 or of FIG. 7 before sending the request or the answer.
  • FIG. 5 proposes a method associated with the sending of a message (request or response) according to a first embodiment.
  • this message can be the message RPCl-a in FIG. 3-1 having for parameter an empty object identifier ID-01 and sent by the process PI to the process P2.
  • the structure of a first object is traversed in step 206. If the structure of the object comprises a content known in step 208, the serialization mechanism of step 704 of FIG.
  • step 4 continues . If the structure of the object has no fully known content, for example the object includes a flag indicating that the object is empty as in the case of RPCl-a, the object is detected as a empty object in step 210. The sending of the request or the response is then suspended in step 212 and this as long as the empty object is not updated in the source process PI in step 214. The method returns to step 704 of FIG. 4 to serialize another object of the request or of the response. Once all the objects of the request or of the response have been serialized, the sending of the message is continued, for example the sending of the message RPCl-a from the process PI to the process P2.
  • the PI process monitor is able to wait for the reception of a message sent by the knowing process, the message comprising the content and the identifier of the empty object, said reception being the processing condition satisfied.
  • FIG. 6 illustrates an automatic continuation method according to the first embodiment of the invention.
  • the process knowing PO takes care of the request, it checks whether the content of the empty object identified by ID-01 is available. As soon as it is available in step 220, it is looked up in the table TCRO of the process knowing PO, the identifier of the source process associated with the identifier ID-01 of the empty object. Thus, the content and the identifier of the empty object are sent to the PI source process. Data from the TCRO table is cleared as the contents of empty objects are sent to the processes listed in this table.
  • FIG. 7 proposes a second and a third embodiment of the method associated with the sending of a message (request or response).
  • the second embodiment may be entitled “Transmission of results by the transmitting processes of empty objects”
  • the third embodiment may be entitled “Passing with order of retransmission by the transmitting processes of empty objects”.
  • the message RPCl-a comprising an empty object identifier ID-01 and sent from the process PI to the process P2.
  • the structure of an object of the message is traversed in step 706 by the serializer of the PI process. If the structure of the object comprises a content known in step 708, the serialization mechanism of step 704 in FIG. 7 continues. If the structure of the object has no known content or has partially known content, for example the object includes a flag indicating that the object is empty, the object is detected as an empty object at step 710. We then speak of interception of the sending in the case of a sending of a request or a response. The empty object is then processed in step 712 by the monitor ST1-12.
  • This processing includes several possibilities depending on the implementation of the method - either, in step 712-2, the storage in a table or a local list called Table of Contents to be Retransmitted TCR, for example TRC1 linked to the PI process, of the identifier the empty object and the identifier of the destination process, for example ID-P2, to which the content of this object must be sent, - either, in step 712-3, from the identifier of the empty object, for example ID-01, extracting the identifier of the knowing process, for example PO (called knowing), suitable for calculating the content of this empty object and adding the knowing process to the TCR table, for example TCRO of the PO process, the identifier of the empty object and the identifier of the destination process to which the content of this object must be sent.
  • This addition can be carried out after sending a message from the source process to the knowing process, for example from the PI process to the PO process, asking the knowing process to transmit the content of the object to the destination process, for example P2.
  • the Table of Contents to Retransmit TCR of the source process PI contains the pairs of empty object identifiers ID-OBJ-NID associated with the target process identifiers ID-P to which the content d 'at least one empty object must be retransmitted.
  • the monitor ST1-12 adds the torque (ID-P2, ID-01) to the table TCR1 of the source process PI. This addition corresponds to a processing condition satisfied, which triggers the sending of the request RPC1 to the target process P2.
  • the identifier of the process knowing PO is extracted from the identifier of the empty object ID-01.
  • the couple (ID-01, ID-P2) is added to the Table of Contents to Retransmit TCRO of the process knowing PO.
  • the source process PI can send a message to the process knowing PO requesting the retransmission of the result including the identifier and the content of the empty object to the target process P2.
  • the source process PI sends the request RPC1 to the target process P2.
  • the source process PI can inform the target process P2 of the identifier of the knowing process PO if the latter has no extraction process.
  • the process P2 can ask the process knowing the direct transmission of the content of the empty object to the next target process.
  • FIG. 8 illustrates a second embodiment of the automatic continuation method linked to the method associated with the sending of a message carrying out the processing of step 712-2 of FIG. 7.
  • This method is carried out for each process Px, x being an integer which can designate the process knowing PO and any process having retransmitted the empty object ID-01, that is to say a process PI, P2.
  • step 412 the monitor of the process Px is in the waiting phase for the availability of the result comprising the identifier and the content of the empty object (ID-01, CONT-01).
  • the update module of the latter updates the object by integrating the content into the structure of the object and sends by a message (for example the message RI between the PI process and the P2 process in Figure 3-1) this object updated to all the target processes, i.e. the processes whose ID-P identifiers in the TCRx table are associated with the identifier of the empty object ID-01 in step 414.
  • the result becomes available in all the target processes.
  • the target processes having retransmitted the empty object await the result in step 412, that is to say the empty object updated.
  • these target processes receive this result, they become source processes by performing step 414, that is to say that they retransmit by a message the empty object updated to all the target processes of their table TCR whose ID-P identifiers are associated with the empty object identifier ID-01. This iteration is carried out until all the processes having retransmitted the empty object receive the updated object.
  • the method is first carried out by the knowing process then, iteratively, by any process having retransmitted the empty object and receiving the updated object.
  • this embodiment allows the retransmission of the content of the empty object by a source process to the target process as soon as the content is available in the source process and the updating of the empty object has been carried out by the process. source.
  • This retransmission can be done iteratively and by a synchronous RPC type communication.
  • FIG. 9 illustrates a third embodiment of the automatic continuation method linked to the method associated with the sending of a message performing the processing of step 712-3 of FIG. 7.
  • step 612 the process monitor knowing PO is in the waiting phase for making the result of the request RPCO-a available.
  • This result includes the identifier and the content of the empty object (ID-01, CONT-01).
  • the module for updating the latter updates the empty object by integrating the content into the structure of the object and the monitor sends this updated object by a message R2 to all the target processes, that is to say to all the processes whose identifiers ID-P in the table TCRO are associated with the identifier of the empty object ID-01 in step 614.
  • the updated object becomes available locally in all these target processes.
  • the monitor of the computer station of the local process is clean, after execution of the sending of the request or the response and a Once the content of the empty object is available in the local process, send the identifier of the empty object associated with its content to the processes whose identifiers in the table are associated with the identifier of the empty object.
  • Figures 10, 11 and 12 illustrate a fourth embodiment of the invention which applies to the detection of the use of an empty object by the PI process by way of example.
  • the method associated with sending a message does not require any particular processing and the sending is carried out with or without the presence of an empty object detected.
  • FIG. 10 illustrates a waiting process by necessity according to the fourth embodiment of the invention.
  • step 702 the use by a PI process of an empty object identified by ID-01 is detected.
  • step 704 execution of the PI process is suspended.
  • the PI process monitor extracts from the identifier ID-01 of the empty object, the process identifier knowing ID-PO capable of calculating and making available the content of the object empty.
  • step 708 the PI process monitor sends the knowing process PO a first Transmit message (ID-01, ID-P1) with the identifier ID-01 of the empty object and the identifier ID-P1 of the process PI.
  • This message requires, once the content of the empty object has been made available, the transmission by the process PO to the process PI of a second message (ID-01, CONT-01) with the identifier and the content of the empty object.
  • the PI process monitor waits for the empty object to be updated by the PI process update module. This update of the empty object corresponds to a satisfied processing condition that the monitor detects to continue the execution of the use made of the object identified in step 712.
  • FIG. 11 illustrates the method of reception of the first message of step 708 by the process knowing PO.
  • the monitor of the PO process checks whether the content CONT-01 of the object identified ID-01 in the first message received exists in the Table of Calculated Contents TCC held by the process knowing PO as indicated in the figure 12. If this is the case, the monitor retrieves the content of the empty object and its identifier in the TCC table and, in step 718, sends a second message comprising the identifier and the content of the empty object (ID-01, CONT-01) to the PI process using this object. If this is not the case, in step 717, the monitor of the PO process adds, in its Table of Contents to be Retransmitted TCRO, the data pair (ID-P1, ID-01) which has been passed in parameters with the first message.
  • FIG. 12 illustrates an automatic continuation method according to the fourth embodiment of the invention.
  • the process monitor knowing PO waits for the result (ID-01, CONT-01) comprising the identifier and the content of the empty object to be available. Once this result is available, it is added to the table TCC of the process knowing PO in step 722 and then sent to all the processes in the table TCRO of PO for which the identifiers are associated with the identifier of the empty object.
  • the PO process calculates the content of the empty object at once and then sends the identifier-content of the empty object pair to all processes awaiting results thanks to the TCC and TCRO tables held in memory by the process knowing PO.
  • the monitor of the computer station of the knowing process is able to work with a first table TCRO comprising pairs of data associating identifiers of empty objects and process identifiers and a second table TCC comprising pairs of data associating identifiers empty objects and the contents of those objects.
  • the monitor of the computer station of the knowing process is also clean, once having added in the second table the identifier of the empty object and its calculated content, to send a message comprising the identifier and the content of the empty object . to the local process after checking that the identifier of the empty object is in the second table and. processes whose identifier in the first table is associated with the identifier of the empty object, identifiers which have been added in the first table on a message from the PI process.
  • This embodiment of the monitor of the invention using the TCC and TCR tables allows overall management of the processes waiting for the same empty object content identified for the use of this object.
  • the intervention processes of the first, second and third embodiments of the invention are accompanied by a process ensuring the consistency of the automatic updating of the content of the empty object when the identifier of an empty object is used by the process P in a station, namely a process of waiting by necessity which suspends the execution in progress and does not resume it until the content of the empty object is known.
  • Each computer station comprises a local process, a protocol module and a monitor so that each local process can be local, distant from another process of another station or knowing for the calculation of the content of an empty object.
  • Each computer station can include one or more local processes, each process having a protocol module and a monitor.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention concerne un procédé de gestion d'appel de méthodes à distance en langage orienté objet, par une communication asynchrone, entre un processus local d'une station et un processus distant d'une autre station, un tel appel comprenant une requête de l'un des processus, suivie d'une réponse de l'autre processus. Ce procédé consiste a- à détecter la transmission d'un objet vide comme paramètre d'une requête ou d'une réponse avant son envoi d'un processus local à un processus distant (710), le calcul du contenu de cet objet vide et sa mise à disposition ayant été demandés à un processus sachant, b- à traiter l'objet vide en vue de mettre à disposition le contenu de cet objet (712) au processus distant, c- à poursuivre l'envoi de ladite requête ou de ladite réponse sur une condition de traitement satisfaite.

Description

Dispositif et procédé asynchrones et automatiques de transmission de résultats entre objets communicants
L'invention concerne le domaine des communications par appels de procédures à distance (de type RPC pour Remote Procédure Call) entre un processus local et un processus distant.
Ces communications de type RPC peuvent utiliser des objets au sens du langage orienté- objet. Dans le cadre des communications de type RPC synchrone, un processus dit appelant envoie une requête à un processus appelé, le processus appelant bloquant son exécution jusqu'à recevoir le résultat de sa requête par le processus appelé.
Dans le cadre de l'invention, les communications établies entre les processus sont de type RPC asynchrone, c'est-à-dire que le processus source poursuit son exécution après l'envoi (ou dépôt) d'une requête (ditmessage d'appel). Ainsi, dans le cas d'une requête, le processus cible finit d'abord l'exécution de ses tâches en cours puis exécute la méthode distante en parallèle avec l'exécution du processus source et met à disposition les paramètres de la réponse en fin d'exécution de la méthode distante. Le processus source peut ainsi obtenir ses paramètres de réponse.
Toutefois, ce type de communication RPC asynchrone ne prévoit pas de gestion de communication de ces résultats entre processus, ce qui peut entraîner des blocages lorsque l'exécution d'opérations ou l'envoi de messages nécessite ces résultats.
L'invention vient améliorer la situation.
L'invention concerne un procédé de gestion d'appel de méthodes à distance en langage orienté objet, par une communication asynchrone, entre un processus local d'une station et un processus distant d'une autre station, un tel appel comprenant une requête de l'un des processus, suivie d'une réponse de l'autre processus, ce procédé consistant à a- à détecter la transmission d'un objet vide comme paramètre d'une requête ou d'une réponse avant son envoi d'un processus local à un processus distant, le calcul du contenu de cet objet vide et sa mise à disposition ayant été demandés à un processus sachant, b- à traiter l'objet vide en vue de mettre à disposition le contenu de cet objet au processus distant, c- à poursuivre l'envoi de ladite requête ou de ladite réponse sur une condition de traitement satisfaite.
L'invention concerne également une station informatique, comprenant
- un environnement, capable d'exécuter un ou des processus locaux en langage orienté-objet,
- un module de protocole, capable de traiter, par une communication asynchrone, des appels de méthodes à distance entre un processus local et un processus distant d'une autre station, un tel appel comprenant une requête de l'un des processus, suivie d'une réponse de l'autre processus.
Selon une caractéristique de l'invention, la station informatique comprend: un moniteur apte, sur une détection de l'événement qu'un objet vide intervient comme paramètre d'une requête ou d'une réponse à envoyer par le processus local au processus distant, le calcul du contenu de cet objet vide et sa mise à disposition ayant été demandés à un processus sachant, à . traiter l'objet vide en vue de mettre à disposition le contenu de cet objet au processus distant, . poursuivre l'envoi de la requête ou de la réponse sur une condition de traitement satisfaite.
Le dispositif informatique selon l 'invention peut comprendre de nombreuses caractéristiques supplémentaires qui pourront être prises séparément et/ou en combinaison et qui seront exposés dans la description détaillée.
D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-après, ainsi que des dessins annexés sur lesquels:
- la figure 1 représente un réseau de stations communicant par appels de méthodes ou de procédures à distance (RPC) asynchrone,
- la figure 2 illustre la communication entre deux stations de la figure 1 utilisant l'appel de procédure à distance RPC asynchrone, - la figure 3-1 illustre un réseau de stations utilisant l'appel de procédure à distance RPC asynchrone avec retour de résultats selon l'invention,
- la figure 3-2 illustre en détail des composants d'une station selon l'invention,
- la figure 4 est un ordinogramme illustrant le procédé d'envoi de requête ou de résultat pour des communications RPC asynchrones,
- la figure 5 est un ordinogramme détaillant une première réalisation d'un procédé associé à l'envoi et appelé à l'étape 702 de la figure 4,
- la figure 6 est un ordinogramme détaillant une première réalisation d'un procédé de continuation automatique de résultats associée à la première réalisation du procédé de la figure 5,
- la figure 7 est un ordinogramme détaillant une deuxième et une troisième réalisation du procédé associé à l'envoi et appelé à l'étape 702 de la figure 4,
- la figure 8 est un ordinogramme détaillant une deuxième réalisation du procédé de continuation automatique de résultats associée à la deuxième réalisation du procédé de la figure 7,
- la figure 9 est un ordinogramme détaillant une troisième réalisation du procédé de continuation automatique de résultats associée à la troisième réalisation du procédé de la figure 7,
- la figure 10 est un ordinogramme détaillant un procédé d'attente par nécessité de résultat selon l'invention,
- la figure 11 illustre un procédé de réception de message après envoi de message de l'étape 708 de la figure 10,
- la figure 12 est un ordmogramme détaillant une quatrième réalisation du procédé de continuation automatique de résultats associée aux procédés des figures 10 et 11.
Les dessins contiennent, pour l'essentiel, des éléments de caractère certain. Ils pourront donc non seulement servir à mieux faire comprendre la description, mais aussi contribuer à la définition de l'invention, le cas échéant.
La figure 1 représente un réseau de stations communicants entre-elles. On entend par "station informatique" tout élément informatique capable d'échanger des données. Ainsi, cet élément pourra être un terminal de communication mobile comme un téléphone mobile ou un ordinateur portable, ou au contraire un terminal de communication fixe comme un ordinateur de type PC. Chaque station ST1, ST2, STO comprend un système d'exploitation ST1-2, ST2- 2, STO-2, une mémoire ST1-4, ST2-4, STO-4 non partagée, un processus PI, P2, PO travaillant en langage orienté-objet, et un module de protocole de communications ST1-6, ST2-6, STO-6 de type communications par appels de méthodes ou de procédures à distance de type RPC (pour Remote Procédure Call) asynchrone capable de travailler avec des objets au sens du langage orienté objet. Ce module de protocole est capable de traiter, par une communication asynchrone, des appels de méthodes à distance RPC entre un processus local et un processus distant d'une autre station. Le module de protocole comprend une bibliothèque d'objets comprenant des méthodes ou fonctions qui permettent l'appel de méthodes à distance. Le terme "processus" désigne un programme d'instructions qui peut comprendre des appels de méthodes, des opérations à titre d'exemple. L'environnement constitué par un système d'exploitation ST1-2, une mémoire non partagée ST1-4, et un module de protocole de communications ST1-6 permet d'exécuter des processus locaaux corrime PI en langage orienté-objet.
Chaque station est reliée aux autres stations par un lien qui peut être physique ou virtuel, par exemple des câbles, des fibres optiques ou des ondes radio. De façon plus précise et à titre d'exemple, chaque station peut être reliée à un réseau 10 par un lien 10-ST1, 10-ST2, 10- ST0, les stations étant ainsi reliées entre-elles.
Comme illustré sur la figure 2, le module de protocole de type RPC asynchrone permet pour un processus PI dit client d'appeler une méthode du processus P2 dit serveur situé à distance dans la station ST2. Cet appel A est appelé aussi requête et comprend des paramètres Pa. Au sens du langage orienté-objet, une requête est un objet représentant un appel de méthode et comprenant la méthode et les paramètres d'appels. Pour que l'appel de cette méthode ressemble à un appel d'une méthode locale, le processus client PI comprend un objet ayant une méthode locale de même nom que la méthode distante à appeler. Cette méthode locale de la station ST1 appelle certaines méthodes dans la bibliothèque d'objet du module de protocole, par exemple une bibliothèque de type Java®. Ces dernières prennent en charge les connexions réseaux, le passage des paramètres Pa et le retour des résultats appelé aussi réponse RES. Lors d'un appel de type RPC asynchrone, le processus client PI dépose la requête avec ses paramètres d'appel dans la station ST2 puis continue son exécution. Du côté de la station ST2, le processus serveur P2 finit l'exécution de ses tâches en cours avant d'appeler la méthode locale de la station ST2 avec les paramètres d'appel et de retourner la réponse R-A, c'est-à-dire le résultat à la station ST1.
Ainsi, le processus client PI n'appelle pas la méthode locale mais dépose seulement une requête du côté de la station ST2 puis continue son exécution. De façon parallèle, le processus serveur P2 continue son exécution en cours lors du dépôt de la requête puis répond à la requête en renvoyant une réponse au processus client PI.
Bien évidemment, tout processus du réseau utilise la bibliothèque du module de protocole de type RPC asynchrone pour établir des communications par appels de méthodes à distance. De manière générale, tout processus peut être à la fois client et serveur, à savoir émettre une requête et en recevoir. On parlera donc de processus source ou local lorsque le processus envoie des requêtes ou des réponses, de processus cible ou distant lorsque le processus reçoit des requêtes ou des réponses.
Les communications établies entre les processus sont de type asynchrone, c'est-à-dire que le processus source poursuit son exécution après l'envoi (ou dépôt) d'une requête (message d'appel) ou d'une réponse. Ainsi, dans le cas d'une requête, le processus cible finit d'abord l'exécution de ses tâches en cours puis exécute la méthode distante en parallèle avec l'exécution du processus source et met à disposition les paramètres de la réponse en fin d'exécution de la méthode distante. Le processus source peut ainsi obtenir ses paramètres de réponse.
Dans le cadre de communications de type RPC asynchrone utilisant des objets au sens du langage orienté-objet, lorsqu'un processus envoie une requête, la réponse peut tarder ce qui peut bloquer l'exécution du processus. Un processus peut ne pas attendre la réponse à une requête et se servir de la représentation de cette réponse non encore déterminée. De manière générale, un objet est identifié par un identifiant et comprend une structure qui peut soit être vide, soit comprendre un contenu (valeurs de paramètres, méthodes). Ainsi, la représentation d'une réponse non encore déterminée peut être un identifiant d'objet indiqué comme vide ou partiellement vide. Cet objet est lié à un drapeau (flag) indiquant que cet objet est vide ou partiellement vide. L'objet peut être complètement vide, c'est-à-dire un objet dont le contenu est encore inconnu, soit comme partiellement vide, c'est-à-dire un objet dont le contenu n'est que partiellement connu. Cet identifiant d'objet vide nomme un objet dont le contenu, ou au moins une partie de celui-ci, sera la réponse à une requête donnée.
Une requête ou une réponse envoyée par un processus local à un processus distant peut avoir des paramètres comprenant un ou plusieurs identifiants d'objets vides. Plus précisément, une requête envoyée par un processus client à un processus serveur peut avoir des paramètres comprenant un ou plusieurs identifiants d'objets vides. De la même manière, une réponse envoyée par un processus serveur à un processus client peut avoir des paramètres comprenant un ou plusieurs identifiants d'objets vides. Dans ces cas, il est important que les processus distants puissent obtenir le contenu de ces objets vides une fois que ceux-ci sont disponibles.
Dans certains cas, connaître le contenu d'un objet vide est indispensable. Par exemple, lorsqu'un identifiant d'objet vide est utilisé par un processus. On entend par "utilisation" d'un identifiant d'objet vide, une opération pour laquelle déterminer le contenu de cet objet est nécessaire. Une opération est dite stricte et peut être à titre non limitatif une addition, une soustraction, une division, une multiplication si l'identifiant de l'objet nomme un objet représentant un nombre. Dans le cas d'une utilisation, il est nécessaire que le processus puisse obtenir le contenu de l'objet vide afin d'exécuter l'opération.
Un mécanisme de gestion de transmission des contenus d'objets vides vers les processus en ayant besoin apparaît nécessaire.
La figure 3-1 illustre le réseau de stations de la figure l.Les références identiques à celles de la figure 1 désignent les mêmes éléments.
Les communications RPC asynchrones entre les processus PI et PO décrites maintenant sont représentées par des flèches en traits tiretés.
Lors d'un appel RPCO-a de type RPC asynchrone, le processus source PI crée un identifiant d'objet vide ID-01 représentant la réponse à la requête RPCO-a, sérialise la requête comme présenté sur la figure 4 décrite ci-après, dépose dans la station ST0 la requête RPCOa avec ses paramètres d'appel qui comprennent l'identifiant de l'objet vide ID-01 puis continue son exécution. Dans la station STO, la requête est reçue, désérialisée, puis mise en attente dans une file de requêtes à traiter par le processus cible PO. Ainsi, le calcul du contenu de cet objet vide et sa mise à disposition sont demandés au processus cible appelé aussi processus sachant notamment lors de la création de la requête RPCO-a. Lorsque le contenu de l'objet vide est obtenu par le processus cible PO, le couple de résultat CRES comprenant le contenu CONT-01 et l'identifiant ID-01 de l'objet vide est mis à disposition. Le processus cible PO obtient le contenu CONT-01 de l'objet vide par calcul et est appelé processus sachant.
Le processus PO peut également stocker l'identifiant du processus PI associé à l'identifiant de l'objet vide afin de renvoyer le résultat au processus PI par la réponse R0.
Le contenu CONT-01 peut lui-même contenir l'identifiant d'un autre objet vide dont le contenu sera calculé par un autre processus.
Une fois l'objet vide créé dans le processus PI, l'identifiant de cet objet peut être soit utilisé par le processus PI soit passé en paramètre dans une requête RPCl-a au processus cible P2 comme indiqué sur la figure 3-1.
Lorsque le contenu de l'objet vide est connu du processus PI, celui-ci met à jour l'objet vide en intégrant le contenu dans la structure de l'objet vide.
La figure 3-2 illustre plus en détail les modules aptes à travailler en relation avec le processus PI.
La station comprend les composants suivants :
- un détecteur, par exemple un sérialisateur ST1-20, en relation avec le processus PI et propre à détecter l'événement qu'un identifiant d'objet vide intervient comme paramètre d'une requête ou d'une réponse à envoyer par le processus local PI à un autre processus P2 distant, - un module de mise à jour ST1-16 apte, à partir de l'identifiant d'un objet vide et du contenu déterminé de cet objet vide, à intégrer ce contenu à la structure de l'objet vide, et ainsi mettre à jour l'objet vide - un moniteur ST1-12 en liaison avec le détecteur ST1-20 et le processus local PI et propre, en réponse à la détection du détecteur, à intercepter l'envoi, à traiter l'objet vide en vue de mettre à disposition le contenu de cet objet au processus distant et à poursuivre l'envoi de la requête ou de la réponse sur une condition de traitement satisfaite.
Le traitement de l'objet vide, qui sera développé plus loin, comprend soit
- l'attente du contenu et l'arrêt de l'exécution de l'événement durant cette attente, la condition de traitement satisfaite correspondant à la réception du contenu ou la mise à jour de l'objet vide par rintégration de son contenu une fois obtenu, - le stockage de données qui identifient l'objet vide et un processus auquel le contenu de l'objet vide doit être acheminé, l'exécution de l'événement étant alors poursuivie sans que le contenu de l'objet vide ne soit connu,
- le fait de continuer l'exécution de l'événement.
Dans le cas d'une utilisation d'un identifiant d'objet vide par le processus PI, la détection de cet utilisation est automatiquement réalisée car l'accès à cet objet vide est bloquée de part la sémantique du langage objet. Il sera développé plus loin le traitement réservé après la détection d'une telle utilisation.
Le moniteur comprend un ensemble de processus appelés processus d'intervention qui sont exécutés selon que le processus est un processus source ou sachant, un processus sachant étant celui qui calcule le contenu d'un objet vide. Le moniteur comprend un processus dit d'attente par nécessité, un processus dit associé à l'envoi de requête/résultat, un processus dit de continuation automatique. L'exécution de ce dernier processus peut être effectuée parallèlement et indépendamment des autres processus. Ce processus de continuation automatique a pour fonction d'acheminer les contenus déterminés d'objets vides vers tous les processus susceptibles d'en avoir besoin.
Le moniteur travaille par ailleurs avec au moins une table dite Table de Contenus à Retransmettre TCR indiquant l'identifiant d'objets vides et l'identifiant d'un processus.
Cette table sert à la transmission du contenu de l'objet vide au processus identifié. Un telle table sera utilisée soit dans le processus sachant soit dans tous les processus ayant transmis un identifiant d'objet vide, par exemple un processus source, en fonction du mode de réalisation de l'invention comme développé ci-après.
Dans le cas de la requête RPCO-a de la figure 3-1 par exemple, le processus PO ajoute dans sa Table de Contenus à Retransmettre TCR0 le couple comprenant l'identifiant ID-01 de l'objet vide et l'identifiant ID-P1 du processus source auquel le contenu de l'objet vide doit être envoyé.
Les fonctions de ces différents composants sont détaillés dans la description des organigram- mes des figures 4 à 12 ci-après. La description sera faite en parallèle avec la figure 3-1.
Pour les modes de réalisations des figures 4 à 9, on se place sur la figure 3-1 dans le cas où le processus PI a envoyé une requête RPCO-a au processus sachant PO et cherche à envoyer au processus P2 une requête RPCl-a comprenant l'identifiant ID-01 de l'objet vide ou dans le cas où le processus PI a reçu un identifiant d'objet vide ID-01 créé par un autre processus du réseau.
La figure 4 illustre la sérialisation d'une requête ou d'une réponse avant son envoi. A l'étape 702, un premier objet parmi les paramètre de la requête ou de la réponse à envoyer est sérialisé. Le mécanisme de la sérialisation, qui permet l'envoi de la requête ou de la réponse après copie de celle-ci, comprend notamment une détection d'un objet vide. A cette détection est ajoutée une gestion de cet objet vide grâce à l'appel d'un procédé associé à l'envoi d'un message selon la figure 5 ou la figure 7 par exemple. Si, à l'étape 704, les paramètres de la requête ou de la réponse comprennent d'autres objets, ceux-ci sont également sérialisés par appel récursif du procédé de la figure 5 ou de la figure 7 avant l'envoi de la requête ou de la réponse.
Les figures 5 et 6 illustrent un premier mode de réalisation du moniteur selon l'invention. Ce mode de réalisation s'applique lors de l'envoi d'objets vides par un processus source à travers les paramètres d'une requête ou d'une réponse. Ce mode peut être nommé "Attente sur tentative de transmission". Lors de la sérialisation de la requête ou de la réponse selon la figure 4, la figure 5 propose un procédé associé à l'envoi d'un message (requête ou réponse) selon un premier mode de réalisation. A titre d'exemple, ce message peut être le message RPCl-a de la figure 3-1 ayant pour paramètre un identifiant d'objet vide ID-01 et envoyé par le processus PI au processus P2. Dans le message, la structure d'un premier objet est parcourue à l'étape 206. Si la structure de l'objet comprend un contenu connu à l'étape 208, le mécanisme de sérialisation de l'étape 704 de la figure 4 continue. Si la structure de l'objet n'a pas de contenu entièrement connu, par exemple l'objet comprend un drapeau (flag) indiquant que l'objet est vide comme dans le cas de RPCl-a, l'objet est détecté comme un objet vide à l'étape 210. L'envoi de la requête ou de la réponse est alors suspendu à l'étape 212 et ceci tant que l'objet vide n'est pas mis à jour dans le processus source PI à l'étape 214. Le procédé retourne à l'étape 704 de la figure 4 pour sérialiser un autre objet de la requête ou de la réponse. Une fois que tous les objets de la requête ou de la réponse ont été sérialisés, l'envoi du message est poursuivi, par exemple l'envoi du message RPCl-a du processus PI au processus P2.
Dans cette réalisation, le moniteur du processus PI est apte à attendre la réception d'un message envoyé par le processus sachant, le message comprenant le contenu et l'identifiant de l'objet vide, ladite réception étant la condition de traitement satisfaite.
La figure 6 illustre un procédé de continuation automatique selon le premier mode de réalisation de l'invention. Sur la figure 3-1, on se place dans le cas du processus source PI ayant envoyé une requête RPCO-a à un processus sachant PO pour connaître le contenu d'un identifiant d'objet vide ID-01. Lorsque le processus sachant PO se charge de la requête, il vérifie si le contenu de l'objet vide identifié par ID-01 est disponible. Dès que celui-ci est disponible à l'étape 220, il est recherché dans la table TCRO du processus sachant PO, l'identifiant du processus source associé à l'identifiant ID-01 de l'objet vide. Ainsi, le contenu et l'identifiant de l'objet vide sont envoyés au processus source PI. Les données de la table TCRO sont effacées au fur et à mesure que le contenu des objet vide est envoyé aux processus répertoriés dans cette table.
Une fois que ce résultat est reçu par le processus PI, son module de mise à jour met à jour l'objet vide en intégrant le contenu dans la structure de l'objet avant de poursuivre l'envoi de la requête RPCl-a au processus P2 comme indiqué par les procédés des figures 4 et 5. Pour chaque objet de la requête ou de la réponse, la figure 7 propose une deuxième et une troisième réalisation du procédé associé à l'envoi d'un message (requête ou réponse). La deuxième réalisation peut être intitulée "Transmission des résultats par les processus transmetteurs d'objets vides" et la troisième réalisation peut être intitulée " Passage avec ordre de retransmission par les processus transmetteurs d'objets vides". On se place dans le cas du message RPCl-a comprenant un identifiant d'objet vide ID-01 et envoyé du processus PI au processus P2. La structure d'un objet du message est parcouru à l'étape 706 par le sérialisateur du processus PI. Si la structure de l'objet comprend un contenu connu à l'étape 708, le mécanisme de sérialisation de l'étape 704 de la figure 7 continue. Si la structure de l'objet n'a pas de contenu connu ou a un contenu partiellement connu, par exemple l'objet comprend un drapeau (flag) indiquant que l'objet est vide, l'objet est détecté comme un objet vide à l'étape 710. On parle alors d'interception de l'envoi dans le cas d'un envoi d'une requête ou d'une réponse. L'objet vide est alors traité à l'étape 712 par le moniteur ST1-12. Ce traitement comprend plusieurs possibilités selon la réalisation du procédé - soit, à l'étape 712-2, le stockage dans une table ou une liste locale appelée Table des Contenus à Retransmettre TCR, par exemple TRC1 lié au processus PI, de l'identifiant de l'objet vide et de l'identifiant du processus de destination, par exemple ID-P2, auquel le contenu de cet objet doit être envoyé, - soit, à l'étape 712-3, à partir de l'identifiant de l'objet vide, par exemple ID-01, l'extraction de l'identifiant du processus sachant, par exemple PO (appelé sachant), propre à calculer le contenu de cet objet vide et l'ajout dans la table TCR du processus sachant, par exemple TCRO du processus PO, de l'identifiant de l'objet vide et de l'identifiant du processus de destination auquel le contenu de cet objet doit être envoyé. Cet ajout peut se réaliser après l'envoi d'un message du processus source au processus sachant, par exemple du processus PI au processus PO, demandant au processus sachant de transmettre le contenu de l'objet au processus de destination, par exemple P2.
Dans le cas de l'étape 712-2, la Table des Contenus à Retransmettre TCR du processus source PI contient les couples d'identifiants d'objets vides ID-OBJ-NID associés aux identifiants de processus cibles ID-P auxquels le contenu d'au moins un objet vide doit être retransmis. Le moniteur ST1-12 ajoute le couple (ID-P2, ID-01) à la table TCR1 du processus source PI. Cet ajout correspond à une condition de traitement satisfaite, ce qui déclenche l'envoi de la requête RPC1 au processus cible P2. Dans le cas de l'étape 712-3, l'identifiant du processus sachant PO est extrait de l'identifiant de l'objet vide ID-01. Le couple (ID-01, ID-P2) est ajouté dans la Table des Contenus à Retransmettre TCRO du processus sachant PO. Pour cela, le processus source PI peut envoyer un message au processus sachant PO demandant la retransmission du résultat comprenant l'identifiant et le contenu de l'objet vide au processus cible P2. Sur une condition de traitement satisfaite qui peut être l'extraction de l'identifiant du processus sachant pour un objet vide donné, l'envoi du message demandant la retransmission, l'ajout dans la table TCRO du couple (ID-01, ID-P2), le processus source PI envoie la requête RPC1 au processus cible P2.
Au moment de l'extraction de l'identifiant du processus sachant PO, le processus source PI peut informer le processus cible P2 de l'identifiant du processus sachant PO si celui-ci n'a pas de procédé d'extraction. Ainsi, si l'identifiant de l'objet vide est utilisé comme paramètre d'une requête par le processus P2, ce dernier pourra demander au processus sachant la transmission directe du contenu de l'objet vide au prochain processus cible.
La figure 8 illustre un deuxième mode de réalisation du procédé de continuation automatique lié au procédé associé à l'envoi d'un message réalisant le traitement de l'étape 712-2 de la figure 7.
Ce procédé est effectué pour chaque processus Px, x étant un entier pouvant désigner le processus sachant PO et tout processus ayant retransmis l'objet vide ID-01, c'est-à-dire un processus PI, P2.
A l'étape 412, le moniteur du processus Px est en phase d'attente de disponibilité du résultat comprenant l'identifiant et le contenu de l'objet vide (ID-01, CONT-01). Une fois que ce résultat est disponible dans le processus Px, le module de mise à jour de ce dernier met à jour l'objet en intégrant le contenu à la structure de l'objet et envoie par un message (par exemple le message RI entre le processus PI et le processus P2 sur la figure 3-1) cet objet mis à jour à tous les processus cibles c'est-à-dire les processus dont les identifiants ID-P dans la table TCRx sont associés à l'identifiant de l'objet vide ID-01 à l'étape 414. Ainsi, à l'étape 416, le résultat devient disponible dans tous les processus cibles. De manière itérative, les processus cibles ayant retransmis l'objet vide attendent le résultat à l'étape 412, c'est-à-dire l'objet vide mis à jour. Dès que ces processus cibles reçoivent ce résultat, ils deviennent processus sources en effectuant l'étape 414, c'est-à-dire qu'ils retransmettent par un message l'objet vide mis à jour à tous les processus cibles de leur table TCR dont les identifiants ID-P sont associés à l'identifiant de l'objet vide ID-01. Cette itération s'effectue jusqu'à ce que tous les processus ayant retransmis l'objet vide reçoivent l'objet mis à jour.
Le procédé est d'abord effectué par le processus sachant puis, de manière itérative, par tout processus ayant retransmis l'objet vide et recevant l'objet mis à jour.
Ainsi, ce mode de réalisation permet la retransmission du contenu de l'objet vide par un processus source au processus cible dès que le contenu est disponible dans le processus source et que la mise à jour de l'objet vide a été réalisée par le processus source. Cette retransmission peut se faire de manière itérative et par une communication de type RPC synchrone.
La figure 9 illustre un troisième mode de réalisation du procédé de continuation automatique lié au procédé associé à l'envoi d'un message réalisant le traitement de l'étape 712-3 de la figure 7.
Sur la figure 9, à l'étape 612, le moniteur du processus sachant PO est en phase d'attente de mise à disposition du résultat de la requête RPCO-a. Ce résultat comprend l'identifiant et le contenu de l'objet vide (ID-01, CONT-01). Une fois que ce résultat est disponible dans le processus sachant PO, le module de mise à jour de ce dernier met à jour l'objet vide en intégrant le contenu à la structure de l'objet et le moniteur envoie cet objet mis à jour par un message R2 à tous les processus cibles c'est-à-dire à tous les processus dont les identifiants ID-P dans la table TCRO sont associés à l'identifiant de l'objet vide ID-01 à l'étape 614. Ainsi, à l'étape 616, l'objet mis à jour devient disponible localement dans tous ces processus cibles.
Dans ce mode de réalisation de l'invention, le moniteur de la station informatique du processus local est propre, après exécution de l'envoi de la requête ou de la réponse et une fois le contenu de l'objet vide disponible dans le processus local, à envoyer l'identifiant de l'objet vide associé à son contenu aux processus dont les identifiants dans la table sont associés à l'identifiant de l'objet vide.
Les figures 10, 11 et 12 illustrent un quatrième mode de réalisation de l'invention qui s'applique à la détection de l'utilisation d'un objet vide par le processus PI à titre d'exemple. Dans ce mode de réalisation, le procédé associé à l'envoi d'un message (requête ou réponse) ne nécessite pas de traitement particulier et l'envoi est effectué en présence ou non d'objet vide détecté.
La figure 10 illustre un procédé d'attente par nécessité selon le quatrième mode de réalisation de l'invention. A l'étape 702, l'utilisation par un processus PI d'un objet vide identifié par ID-01 est détecté. A l'étape 704, l'exécution du processus PI est suspendu. A l'étape 706, le moniteur du processus PI extrait à partir de l'identifiant ID-01 de l'objet vide, l'identifiant du processus sachant ID-PO apte à calculer et à mettre à disposition le contenu de l'objet vide. A l'étape 708, le moniteur du processus PI émet au processus sachant PO un premier message Transmettre(ID-01, ID-P1) avec l'identifiant ID-01 de l'objet vide et l'identifiant ID-P1 du processus PI. Ce message requiert, une fois le contenu de l'objet vide mis à disposition, la transmission par le processus PO au processus PI d'un second message (ID-01, CONT-01) avecl'identifiantetle contenu de l'objetvide. Al'étape 710, 1e moniteur du processus PI attend que l'objet vide soit mis à jour par le module de mise à jour du processus PI. Cette mise à jour de l'objet vide correspond à une condition de traitement satisfaite que le moniteur détecte pour poursuivre l'exécution de l'utilisation faite de l'objet identifié à l'étape 712.
Sur la figure 11 illustre le procédé de réception du premier message de l'étape 708 par le processus sachant PO. A l'étape 716, le moniteur du processus PO vérifie si le contenu CONT-01 de l'objet identifié ID-01 dans le premier message reçu existe dans la Table des Contenus Calculés TCC tenue par le processus sachant PO comme indiqué sur la figure 12. Si c'est le cas, le moniteur récupère le contenu de l'objet vide et son identifiant dans la table TCC et, à l'étape 718, envoie un second message comprenant l'identifiant et le contenu de l'objet vide (ID-01, CONT-01) au processus PI utilisant cet objet . Si ce n'est pas le cas, à l'étape 717, le moniteur du processus PO ajoute, dans sa Table de Contenus à Retransmettre TCRO, le couple de données (ID-P1, ID-01) qui a été passé en paramètres avec le premier message.
La figure 12 illustre un procédé de continuation automatique selon le quatrième mode de réalisation de l'invention. Ainsi, à l'étape 720, le moniteur de processus sachant PO attend que le résultat (ID-01, CONT-01) comprenant l'identifiant et le contenu de l'objet vide soit disponible. Une fois ce résultat disponible, il est ajouté dans la table TCC du processus sachant PO à l'étape 722 puis envoyé à tous les processus de la table TCRO de PO pour lesquels les identifiants sont associés à l'identifiant de l'objet vide. En d'autres termes, le processus PO calcule en une fois le contenu de l'objet vide puis envoie le couple identifiant- contenu de l'objet vide à tous les processus en attente de résultat grâce aux tables TCC et TCRO tenues en mémoire par le processus sachant PO.
Ainsi, le moniteur de la station informatique du processus sachant est propre à travailler avec une première table TCRO comprenant des couples de données associant des identifiants d'objets vides et des identifiants de processus et une seconde table TCC comprenant des couples de données associant des identifiants d'objets vides et les contenus de ces objets. Le moniteur de la station informatique du processus sachant est également propre, une fois avoir ajouté dans la deuxième table l'identifiant de l'objet vide et son contenu calculé, à émettre un message comprenant l'identifiant et le contenu de l'objet vide . au processus local après avoir vérifié que l'identifiant de l'objet vide est dans la seconde table et . aux processus dont l'identifiant dans la première table est associé à l'identifiant de l'objet vide, identifiants qui ont été ajoutés dans la première table sur un message du processus PI.
Cette réalisation du moniteur de l'invention utilisant les tables TCC et TCR permet une gestion globale des processus en attente d'un même contenu d'objet vide identifié pour l'utilisation de cet objet.
Bien qu'il soit fait mention de tables de données, le terme "table" peut tout aussi bien désigner une liste de données associées entre-elles et le terme "liste" peut tout aussi bien désigner une table de données. Ainsi, ces mode de réalisation permettent la retransmission du contenu associé à un objet vide à tous les processus ayant un identifiant de cet objet vide dès que le contenu a été calculé par le processus sachant.
Les processus d'intervention des premier, deuxième et troisième modes de réalisation de l'invention sont accompagnés d'un processus assurant la cohérence de la mise à jour automatique du contenu de l'objet vide lorsque l'identifiant d'un objet vide est utilisé par le processus P dans une station, à savoir un processus d'attente par nécessité qui suspend l'exécution en cours et ne la reprend qu'une fois le contenu de l'objet vide connu.
Chaque station informatique comprend un processus local, un module de protocole et un moniteur de sorte que chaque processus local puisse être local, distant par rapport à un autre processus d'une autre station ou sachant pour le calcul du contenu d'un objet vide. Chaque station informatique peut comprendre un ou plusieurs processus locaux, chaque processus ayant un module de protocole et un moniteur.
L'invention n'est pas limitée aux mode de réalisation décrit ci-dessus mais s'étend à d'autres modes de réalisation. Ainsi, les procédés développés peuvent être utilisés alternativement ou en combinaison en fonction des performances souhaitées.

Claims

Revendications
1. Procédé de gestion d'appel de méthodes à distance en langage orienté objet, par une communication asynchrone, entre un processus local d'une station et un processus distant d'une autre station, un tel appel comprenant une requête (RPC) de l'un des processus (PI;
P2), suivie d'une réponse (R-A) de l'autre processus (P2; PI), caractérisé en ce qu'il consiste, a- à détecter la transmission d'un objet vide comme paramètre d'une requête ou d'une réponse avant son envoi d'un processus local à un processus distant (210, 710), le calcul du contenu de cet objet vide et sa mise à disposition ayant été demandés à un processus sachant, b- à traiter l'objet vide en vue de mettre à disposition le contenu de cet objet (212,712) au processus distant, c- à poursuivre l'envoi de ladite requête ou de ladite réponse (108) sur une condition de traitement satisfaite.
2. Procédé selon la revendication 1, caractérisé en ce que le procédé consiste à a- détecter l'événement qu'un objet vide doit être utilisé par un processus local (702), et suspendre l'exécution de l'utilisation de l'objet vide par le processus local (704) b- bl- à extraire de l'objet vide comprenant un identifiant, l'identifiant du processus sachant apte à calculer et mettre à disposition le contenu de l'objet vide (706), b2- à émettre au processus sachant un premier message ayant des premières données comprenant l'identifiant de l'objet vide et l'identifiant du processus local et requérant la transmission au processus local d'un second message ayant des secondes données comprenant le contenu et l'identifiant de l'objet vide (708), c- à attendre la réception dudit second message par le processus local et une fois ce second message reçu, à mettre à jour l'objet vide et à continuer l'exécution de l'utilisation.
3. Procédé selon la revendication 2, caractérisé en ce que l'étape b2- consiste en outre, b2-l sur réception du premier message par le processus sachant, à vérifier si l'identifiant de l'objet vide est dans une seconde table comprenant des couples de données associant des identifiants d'objets vides et le contenu de ces objets(716), b2-2-i dans l'affirmative, à émettre au processus local le second message (718) b2-2-ii dans la négative, - à ajouter les premières données dans une première table comprenant des couples de données associant des identifiants d'objets vides et des identifiants de processus (717).
4. Procédé selon la revendication 3, caractérisé en ce que l'étape b2-2-ii consiste en outre, une fois le contenu de l'objet vide mis à disposition (720),
- à ajouter les secondes données dans la seconde table (722),
- à émettre le second message aux processus dont les identifiants dans la première table sont associés à l'identifiant de l'objet vide (724).
5. Procédé selon la revendication 1, caractérisé en ce que l'étape b- consiste en outre, par le processus local, à attendre la réception d'un message envoyé par le processus sachant (212), le message comprenant le contenu et l'identifiant de l'objet vide, et sur réception dudit message, à continuer à l'étape c avec l'objet vide mis à jour.
6. Procédé selon la revendication 1, caractérisé en ce que l'étape b- consiste en outre, par le processus local, à ajouter l'identifiant de l'objet vide associé à l'identifiant du processus distant dans une table comprenant des couples de données associant des identifiants d'objets vides et des identifiants de processus (712-2) et à continuer à l'étape c.
7. Procédé selon la revendication 6, caractérisé en ce que l'étape c. consiste, une fois l'envoi exécuté, à cl- attendre que le contenu de l'objet vide est disponible dans le processus local (412), c2- une fois le contenu disponible, envoyer le contenu et l'identifiant de l'objet vide aux processus dont les identifiants dans ladite table sont associés à l'identifiant de l'objet vide
(414).
8. Procédé selon la revendication 1, caractérisé en ce que l'étape b- consiste en outre, par le processus local, bl- à extraire de l'objet vide comprenant un identifiant, l'identifiant du processus sachant apte à calculer et à mettre à disposition le contenu de l'objet vide, b2- à émettre au processus sachant un premier message ayant des premières données comprenant l'identifiant de l'objet vide associé à l'identifiant du processus distant, ce message requérant que le processus sachant transmette au processus distant un second message ayant des secondes données comprenant l'identifiant de l'objet vide associé à son contenu (712-3).
9. Procédé selon la revendication 8, caractérisé en ce que l'étape c consiste également, par le processus sachant et sur réception du premier message, à cl- à ajouter les premières données dans une table comprenant des couples de données associant des identifiants d'objets vides et des identifiants de processus (712-3).
10. Procédé selon l'une des revendications 8 et 9, caractérisé en ce que l'étape c consiste de plus, par le processus local et après l'envoi exécuté, à cl- attendre que le contenu de l'objet vide est disponible dans le processus local (612), d2- une fois le contenu disponible, envoyer l'identifiant de l'objet vide associé à son contenu aux processus dont les identifiants dans ladite table sont associés à l'identifiant de l'objet vide (614).
11. Station informatique, comprenant
- un environnement (ST1-2, ST1-4, ST1-6), capable d'exécuter un ou des processus locaux
(PI) en langage orienté-objet, - un module de protocole (ST1-6), capable de traiter, par une communication asynchrone, des appels de méthodes à distance (RPC) entre un processus local (PI) et un processus distant (P2) d'une autre station, un tel appel (RPC) comprenant une requête (A) de l'un des processus (PI; P2), suivie d'une réponse (R-A) de l'autre processus (P2; PI), caractérisée en ce qu'elle comprend: un moniteur(STl-12) apte, sur une détection de l'événement qu'un objet vide intervient comme paramètre d'une requête ou d'une réponse à envoyer par le processus local (PI) au processus distant (P2), le calcul du contenu de cet objet vide et sa mise à disposition ayant été demandés à un processus sachant, à . traiter l'objet vide en vue de mettre à disposition le contenu de cet objet au processus distant, . poursuivre l'envoi de la requête ou de la réponse sur une condition de traitement satisfaite.
12. Station informatique selon la revendication 11, caractérisé en ce que le moniteur(STl-12) est en outre apte, sur une détection de l'événement qu'un objet vide doit être utilisé par le processus local,
- à extraire de l'objet vide comprenant un identifiant, l'identifiant d'un processus sachant apte à calculer et mettre à disposition le contenu de l'objet vide,
- à émettre au processus sachant un premier message ayant des premières données comprenant l'identifiant de l'objet vide et l'identifiant du processus local et requérant la transmission au processus local d'un second message ayant des secondes données comprenant le contenu et l'identifiant de l'objet vide, - à attendre la réception dudit second message par le processus local, ladite réception étant la condition de traitement satisfaite.
13. Station informatique selon la revendication 12, caractérisé en ce que le moniteur(STl-12) de la station informatique du processus sachant étant propre - à travailler avec une première table comprenant des couples de données associant des identifiants d'objets vides et des identifiants de processus et une seconde table comprenant des couples de données associant des identifiants d'objets vides et les contenus de ces objets,
- à émettre le second message .au processus local après avoir vérifié que l'identifiant de l'objet vide du premier message est dans la seconde table . aux processus dont l'identifiant dans la première table est associé à l'identifiant de l'objet vide après avoir ajouté les premières données dans la première table et une fois avoir ajouté les secondes données dans la seconde table après calcul du contenu de l'objet vide.
14. Station informatique selon la revendication 11, caractérisé en ce que le moniteur(STl-12) est apte à attendre la réception d'un message envoyé par le processus sachant, le message comprenant le contenu et l'identifiant de l'objet vide, ladite réception étant la condition de traitement satisfaite.
15. Station informatique selon la revendication 11, caractérisé en ce que le moniteur(STl-12) est apte à ajouter l'identifiant de l'objet vide associé à l'identifiant du processus distant dans une table comprenant des couples de données associant des identifiants d'objets vides et des identifiants de processus, cet ajout étant la condition de traitement satisfaite.
16. Station informatique selon la revendication 15, caractérisé en ce qu'une fois le contenu de l'objet vide disponible dans le processus local, le moniteur(STl-12) est propre à transmettre l'identifiant et le contenu de l'objet vide à des processus dont les identifiants dans ladite table sont associés à l'identifiant de l'objet vide.
17. Station informatique selon la revendication 11 , caractérisé en ce que le moniteur(STl-12) est apte à
- à extraire de l'objet vide comprenant un identifiant, l'identifiant d'un processus sachant apte à calculer et à mettre à disposition le contenu de l'objet vide,
- à émettre au processus sachant un premier message ayant des premières données comprenant l'identifiant de l'objet vide associé à l'identifiant du processus distant, ce premier message requérant la transmission au processus distant d'un second message ayant des secondes données comprenant le contenu et l'identifiant de l'objet vide, l'émission du premier message étant la condition de traitement satisfaite.
18. Station informatique selon la revendication 17, caractérisé en ce que le moniteur(STl-12) de la station informatique du processus sachant étant propre, sur réception du premier message,
- à ajouter les premières données dans une table comprenant des couples de données associant des identifiants d'objets vides et des identifiants de processus.
19. Station informatique selon l'une des revendications 17 et 18, caractérisé en ce que le moniteur de la station informatique du processus local est propre, après exécution de l'envoi de la requête ou de la réponse et une fois le contenu de l'objet vide disponible dans le processus local, à envoyer l'identifiant de l'objet vide associé à son contenu aux processus dont les identifiants dans la table sont associés à l'identifiant de l'objet vide (614).
20. Réseau de stations informatiques selon l'une des revendications 11 à 19, chaque station informatique comprenant un processus local, un module de protocole et un moniteur de sorte que chaque processus local puisse être local, distant par rapport à un autre processus d'une autre station ou sachant pour le calcul du contenu d'un objet vide.
EP04805534A 2003-11-26 2004-11-24 Dispositif et procédé asynchrones et automatiques de transmission de résultats entre objets communicants Ceased EP1687719A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0313876A FR2862830B1 (fr) 2003-11-26 2003-11-26 Dispositif et procede asynchrones et automatiques de transmission de resultats entre objets communicants.
PCT/FR2004/003005 WO2005055060A1 (fr) 2003-11-26 2004-11-24 Dispositif et procede asynchrones et automatiques de transmission de resultats entre objets communicants

Publications (1)

Publication Number Publication Date
EP1687719A1 true EP1687719A1 (fr) 2006-08-09

Family

ID=34531294

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04805534A Ceased EP1687719A1 (fr) 2003-11-26 2004-11-24 Dispositif et procédé asynchrones et automatiques de transmission de résultats entre objets communicants

Country Status (7)

Country Link
US (1) US20070147277A1 (fr)
EP (1) EP1687719A1 (fr)
JP (1) JP2007517279A (fr)
CN (1) CN1902590B (fr)
CA (1) CA2546888C (fr)
FR (1) FR2862830B1 (fr)
WO (1) WO2005055060A1 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8855036B2 (en) * 2007-12-21 2014-10-07 Powerwave Technologies S.A.R.L. Digital distributed antenna system
US8549094B2 (en) * 2011-06-30 2013-10-01 International Business Machines Corporation Facilitating communication between isolated memory spaces of a communications environment
CN103095785B (zh) * 2011-11-08 2016-04-06 阿里巴巴集团控股有限公司 远程过程调用方法和***、客户端及服务器
JP5389210B2 (ja) * 2012-03-21 2014-01-15 株式会社東芝 通信管理プログラム及びクライアント装置
US11170067B2 (en) * 2017-12-13 2021-11-09 Google Llc Methods, systems, and media for updating a webpage rendered with cached content

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05290003A (ja) * 1992-04-13 1993-11-05 Matsushita Electric Ind Co Ltd 非同期型遠隔手続き呼び出し装置
CA2115464C (fr) * 1994-02-11 1998-12-15 William G. O'farrell Traitement concurrent dans des systemes paralleles et quasi paralleles orientes objets
US5694598A (en) * 1994-10-12 1997-12-02 U S West Technologies, Inc. Method for mapping data between a relational format and an object-oriented format
JPH0916417A (ja) * 1995-06-27 1997-01-17 Hitachi Ltd メッセージ通信方法およびメッセージ通信システム
US6920636B1 (en) * 1999-12-15 2005-07-19 Microsoft Corporation Queued component interface passing for results outflow from queued method invocations
US6868447B1 (en) * 2000-05-09 2005-03-15 Sun Microsystems, Inc. Mechanism and apparatus for returning results of services in a distributed computing environment
US7051341B2 (en) * 2001-12-14 2006-05-23 International Business Machines Corporation Method, system, and program for implementing a remote method call
US7150004B2 (en) * 2002-08-21 2006-12-12 International Business Machines Corporation Programmatically serializing complex objects using self-healing techniques

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO2005055060A1 *

Also Published As

Publication number Publication date
CA2546888C (fr) 2011-07-12
FR2862830B1 (fr) 2006-02-24
WO2005055060A1 (fr) 2005-06-16
JP2007517279A (ja) 2007-06-28
US20070147277A1 (en) 2007-06-28
CN1902590A (zh) 2007-01-24
CA2546888A1 (fr) 2005-06-16
FR2862830A1 (fr) 2005-05-27
CN1902590B (zh) 2010-09-15

Similar Documents

Publication Publication Date Title
CN112118565B (zh) 多租户服务灰度发布方法、装置、计算机设备和存储介质
EP2215773B1 (fr) Procédé et système de gestion d'un basculement dans un environnement distribué qui utilise une affinité de session
EP2791798B1 (fr) Bus logiciel
US8880698B2 (en) Storage of content data in a peer-to-peer network
US8788565B2 (en) Dynamic and distributed queueing and processing system
CN108958922B (zh) 用于执行任务的方法和装置
US8745635B2 (en) Managing business process messaging
US20110054879A1 (en) Accelerated Execution for Emulated Environments
CN111427701A (zh) 一种工作流引擎***和业务处理方法
US20080065730A1 (en) Method and system for automatically resending messages based on server status
US20090182816A1 (en) Method and system for managing j2ee and .net interoperating applications
CA2546888C (fr) Dispositif et procede asynchrones et automatiques de transmission de resultats entre objets communicants
CN109218338B (zh) 信息处理***、方法和装置
US9722956B2 (en) Managing electronic mail for an end-user that is unavailable
FR2994782A1 (fr) Procede et systeme d'execution de protocoles de chargement de donnees
US11811894B2 (en) Reduction of data transmissions based on end-user context
US10831590B2 (en) Error handling
US8527650B2 (en) Creating a checkpoint for modules on a communications stream
US9130881B2 (en) Direct return to source (DRS) routing of customer information control systems (CICS) transactions
US9325808B2 (en) Message handling in a data processing system
CN114979308B (zh) 一种消息处理的方法和装置
US8761818B2 (en) Converged dialog in hybrid mobile applications
US20140380300A1 (en) Dynamic configuration framework
CN117201572A (zh) 远程服务调用方法、装置、设备及存储介质
EP3949457A1 (fr) Transmission de messages dans un contexte multi-terminaux

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20060602

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LU MC NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20080117

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20171214