JPH07225685A - Distributed object-oriented system construction method - Google Patents

Abstract

PURPOSE:To easily construct a distributed object-oriented system composed of partial systems described in an object-oriented language. CONSTITUTION:In a server application 1 described in the object-oriented language, a reception procedure group generation part 22 generates a reception procedure 31 and a dispatch procedure 32 from an open server object 11 extracted by the open class definition extraction part 21 of a compiler 2 for a server and the compiler 23 generates a server application execution form 8. The dispatch procedure 32 is stored in a class object management means 4 and a substitutive server object generation part 5 generates a substitutive server object 61 by the dispatch procedure 32. In a client application 6, a transmission procedure group generation part 71 generates a transmission procedure 81 and a transfer procedure 82 from the substitutive server object 61 by the substitutive class definition extraction part 71 of the compiler 7 for a client and the compiler 73 generates a client application execution form 8.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a computer system connected by a network, in which a plurality of subsystems described in an object-oriented language exist on different computers and these subsystems communicate with each other. The present invention relates to a method of constructing a distributed object-oriented system that functions as an overall system.

[0002]

2. Description of the Related Art In an object-oriented language, communication between objects is described by exchanging messages. However, conventionally, an object operating on a process of a computer is used for message communication to operate on the same process. It was not possible to use an object running on the process of another computer connected to the network in the same way as using the existing object. Even if you try to use it, if you want to communicate messages to objects running in different processes, you have to communicate over the network, so the application developer needs a procedure that allows objects to communicate between processes. Need to be described separately.

A method of modifying an application built for a single machine will be described below. From here onwards, for the sake of brevity, the process that performs the requested processing is called the server, and the process that requests the processing is called the client. When a server application developer writes an object that does some processing using an object-oriented language, the external process must use interprocess communication in order to receive the request from the process outside the application. It is necessary to describe the procedure that receives the sent request, analyzes the request, dispatches the message to the object that is the processing request destination, and returns the execution result to the request sender after executing the message.

On the other hand, when a client application developer uses an object described by another server application developer rather than an object described by a certain object-oriented language, communication between processes is performed instead of normal message transmission. It is necessary to describe a procedure to send a processing request to the process on the server side via and to receive the message execution result returned from the server side process after the processing is executed.

In order to describe the above communication procedure, the application developer needs to acquire knowledge of the language for describing the communication procedure and the network architecture (in addition to the object-oriented language used for application development). It was difficult to actually use objects running on different processes. In the current technology, by using a remote procedure call (hereinafter, referred to as RPC) for inter-process communication, it is possible to reduce the labor for describing a procedure for performing inter-process communication. The method using RPC for application modification will be described below.

When a server application developer develops an object that performs some processing, first, the interface definition file is set to a network architecture that supports RPC so that the object can receive a request from a process outside the application. It is described in an interface definition language (Interface Definition Language, hereinafter referred to as IDL) which is a declarative language provided. The interface in RPC is a unit of functions provided by the server application, and in this case, one object corresponds to one interface. The interface definition file describes the signatures of all the functions provided by the interface. The signature of a function is the function name of the function, the parameter name of the function, the parameter type,
It refers to the type of parameter (whether it is an input-only, output-only, or input / output parameter) and the return value type of the function.

After describing the interface definition file, the IDL compiler (provided by the network architecture that supports RPC) is used to generate the server stub from the interface definition file. Functions that actually perform communication between processes are defined in the stub, and functions that emulate a client that calls those functions are defined for the functions defined in the interface definition file in the server stub. Since the server stub is generated in the language for interprocess communication,
The server application developer then converts the RPC received by the function in the server stub into a message, dispatches the message to the object that is the processing request destination, and describes a procedure in which the execution result is the execution result of the RPC after the message is executed. Furthermore, when the server starts up, the RPC
A server initialization procedure that opens a communication path for reception and closes the communication path when the server terminates is described in the language for interprocess communication.

When using an object described by a server application developer different from an object described by a client application developer, first, an interface definition file corresponding to the object to be used is IDL-compiled to generate a client stub. The client stub defines a function that emulates the function defined in the interface definition file for the client. Next, write a statement that calls a function in the client stub instead of sending a normal message to the object to be used.

As described above, if RPC is used, only the procedure for interprocess communication can be automatically generated. However, for this purpose, an ID for describing the interface is provided separately from the object-oriented language for application development.
There is a problem that you have to learn the language L. In other words, you have to acquire two or more languages.

Other than RPC, there are the following distributed object oriented environments for constructing a distributed object oriented system. COOL (System Support for Distrib) is a distributed operating system.
uted Programming; Lea, Lodger et al .; Communicatio
ns of the ACM, Sep. 1993, pp. 37-47), when a server application developer describes an object, I
When the interface definition of an object is described using DL, COL creates an interface object which is a virtual object from the interface definition. With this mechanism, it is not necessary to describe the procedure for performing inter-process communication, but the server application developer needs to acquire IDL in addition to the object-oriented language as in the case of directly using RPC.

When an object on the client side sends a message to another object, it corresponds to the object that is operating on the client side and wants to use, regardless of where the message destination object is actually operating. Send a message to the interface object that is The interface object that received the message performs normal message transmission to the destination object if the corresponding destination object is operating on the client side, and the destination object operates on a process other than the client. If so, the processing request is sent to the server-side object via RPC.

DOWL, a distributed object-oriented language
(The DOWL Distributed Object-Oriented Language; A
chauer, Bruno; Communications of the ACM, Sep. 199
3, pp. 48-55) and Japanese Patent Laid-Open No. 5-12025, a client side defines a virtual object corresponding to the server side object to be used. If the client sends a message to a virtual object running on the same process, the message is sent to the server-side object via interprocess communication. Note that Japanese Patent Laid-Open No. 5-12025 is limited to the case of transmitting a message between objects described in different object-oriented languages.

In this mechanism, the server application developer describes a virtual object and provides it to the client application developer, or the client application developer refers to an object definition (in an object-oriented language) on the server side to create a virtual object. Need to be described.

[0014]

The method for making an object running on a different process available using an ordinary message communication than an object running on a certain process has been described above. However, it is not possible to easily build a distributed object-oriented system with only one object-oriented language because it is necessary to learn languages other than application description languages to describe communication procedures and interface definition files, etc. .

However, if it becomes possible to send a message from an object on the client side to an object on the server side in the same manner as a message can be sent to an object on the client side, the application developer exists on a plurality of different computers. A distributed object-oriented system that functions as an entire system by communicating with other partial systems can be described in only one object-oriented language, which facilitates system construction.

The present invention provides a distributed object system construction method for automatically generating a communication procedure for adapting an application to a network environment when the application developer describes the application in one object-oriented language. Has an aim.

[0017]

According to the present invention, when a server application is written in an object-oriented language, a class object that can receive a request from a process outside the application inherits the attributes of the public class object. From the definition of the class object that inherits the attributes of the public class object that was extracted when compiling (from now on, also referred to as public server object), the receiving procedure that receives the request sent from the external process and the request received by the receiving procedure as a message It is characterized by creating a dispatch procedure for dispatching to an object which is a destination.

According to the present invention, the public server object is registered in the class object management means after compiling the server application, and the dispatch procedure corresponding to the public server object is stored in the class object management means when the public server object is registered. Characterize.

The present invention further provides for writing a client application in an object-oriented language,
By designating a public server object to be used after searching the class object management means, a virtual server corresponding to the designated public server object, and a virtual server corresponding to the designated public server object by the dispatch procedure accumulated in the class object management means. Class object that inherits the attributes of the proxy class object (hereinafter also referred to as the proxy server object)
After writing a client application program that generates a message and sends a message to the generated proxy server object, from the definition of the proxy server object extracted when compiling the client application, to the public server object operating on the external process It is characterized by generating a sending procedure for sending a request and a forwarding procedure for dispatching a message sending to a proxy server object to the sending procedure.

[0020]

Function When the application is written, the server application developer only needs to inherit the attributes of the public class object from the class object that can receive requests from processes outside the application. Generate the reception procedure and dispatch procedure necessary to receive the request from the server application execution form. Furthermore, by registering the public server object in the class object management means, other users can reuse the object.

After searching the class object management means, the client application developer specifies a class object to be used and creates a proxy server object. The client can use the public server object of the server only by sending a message to the proxy server object. When the system compiles the application, it generates the send procedure and the transfer procedure necessary to transfer the message sent to the proxy server object to the corresponding public server object, and generates the client application executable form.

[0022]

EXAMPLE An example of the present invention will be described in detail below.
FIG. 1 is a block diagram showing the configuration of an object-oriented language system which is an embodiment of the present invention. 1 is a server application, 11 is a public server object that is a class object that inherits the attributes of a public class object, 2 is a server compiler, 21 is a public class definition extraction unit that extracts a public server object from a server application, and 22 is an extraction Receive procedure 31 and dispatch procedure 3 from the public server object 11
2, a reception procedure group generation unit for generating 2, a compiler for 23,
Reference numeral 3 is a server application execution type generated by compiling the server application 1, the reception procedure 31, and the dispatch procedure 32.

The class object management means 4 registers the public server object 11 and stores the dispatch procedure 32 generated from the definition of the public server object 11 to be registered. After searching the class object management means 4, the proxy server object generator 5 dispatches the dispatch procedure 3 corresponding to the public server object 11 to be used.
The proxy server object 61 is generated from 2.

Reference numeral 6 is a client application, 7 is a client compiler, 71 is a proxy class definition extractor for extracting a proxy server object which is a definition of a class object that inherits the attributes of the proxy class object from the client application, and 72 is the extracted proxy. A transmission procedure group generation unit 73 generates a transmission procedure 81 and a transfer procedure 82 from the server object 61, 73 is a compiler, and 8 is a client application execution type generated by compiling the client application, the transmission procedure 81, and the transfer procedure 82.

Next, the steps for developing the server application shown in FIG. 1 will be described with reference to the flowchart shown in FIG. The steps of server application development are as follows. First, the server application developer describes the server application 1 in a certain object-oriented language (901). Here, as an example, an application will be described in which a bus for transportation from / to a terminal building is allocated as needed based on data of aircraft departing / arriving at an airport.

The server application developer then inherits the attributes of the public class object from the classes described in step (901) to the class that can send a message from outside the application (902). All classes in the server application are considered as private classes unless they inherit the attributes of public class objects. Messages cannot be sent to private objects from outside the application. However, by allowing the class in the server application to inherit the attributes of the public class object, it becomes possible to send a message to the public class object from a process other than the process in which the application is operating for the first time.

In the server application 1, in addition to the object that assigns a shuttle bus, information such as the aircraft model and the bus used for transportation is defined as an object. In this embodiment, all objects that are used only internally by the application are defined as private objects, and only the object 11 that creates a schedule inherits the attributes of the public class object to become a public server object. After the public class object 11 is made to inherit the attributes of the public class object, the server compiler 2 is used to generate the server application executable form 3. The server compiler 2 first uses the public class definition extracting unit 21 to extract the definition of the class object that inherits the attributes of the public class object (903). In this embodiment, the definition of the object 11 for creating a schedule is extracted from the server application 1.

Next, a reception procedure 31 and a dispatch procedure 32 are generated from the definition of the public server object 11 extracted by the reception procedure generation unit 22 (90).
4). In this example, a reception procedure 31 and a dispatch procedure 32 that can receive a message to the public server object 11 transmitted by a process other than the process in which the server application 1 is operating are generated. When the products are prepared, the compiler 23 compiles and links the server application 1, the reception procedure 31, and the dispatch procedure 32 (905) to generate the server application executable form 3 (906).

In order to make the published class object 11 available to other users, after the server application execution form 3 is created, the class object 11 is registered in the class object management means 4 and created from the definition of the class object 11. The dispatch procedure 32 thus created is accumulated (907). When registering a published class object, it is possible to register a document that describes how to use the object in addition to the corresponding dispatch procedure.

The flowchart of FIG. 3 is a flow chart showing the detailed processing procedure of the processing step of step (903) of FIG. 2 and the processing steps of step (904) of FIG. 2 are shown. Each processing procedure will be described below.

The steps of extracting the public class definition shown in FIG. 3 are as follows. The input is the server application and the output is the definition of the class object that inherits the attributes of the public class object. First, it is checked whether there is a class definition to be processed (911). If there are steps (91
2) is executed, and if not, the extraction of the public class definition is completed. If there is a class definition to process, check whether the class definition inherits the attributes of the public class object (9
12). If it is inherited, execute step (913),
If not, step (911) is executed. If the attributes of the public class object are inherited, the class definition is extracted (913). In this embodiment, the class definition of the class object 11 published by the server application 1 is extracted.

The steps of generating the reception procedure of FIG. 4 are as follows. The input is the class definition extracted in the public class definition extraction step, and the output is the reception procedure 31.

First, it is checked whether there is a method to be processed (921). If there is, step (922) is executed, and if not, the generation of the receiving procedure is ended. If there is a method to process, a function header is first generated (922). For the function name, an appropriate name is generated based on the method name. Next, the input / output definition of the function is generated. The function parameter name uses the same name as the method name. The data type of the function parameter converts the data type of the method parameter into the data type of the language used for interprocess communication.

After generating the function header, the body of the function is generated. First, a sentence for receiving a communication packet is generated by the transmission procedure (923). A transmission procedure of a client application uses interprocess communication to transmit a processing request to a reception procedure on the server side.

Next, a statement for extracting the input function parameter from the communication packet is generated (924). The communication packet is disassembled by a method according to the communication protocol used for interprocess communication. After disassembling the communication packet, a dispatch procedure call statement is generated (925). A dispatch procedure call is used to send a message to an object that is a processing request destination.

Since the result of the message transmission is returned to the receiving procedure via the dispatch procedure, a statement for storing the result in the reply packet as an output function parameter is generated (926). The reply packet is created by a method according to the communication protocol used for interprocess communication. Finally, a sentence for transmitting the reply packet to the transmission procedure that has transmitted the communication packet is generated (927). Now that one function definition has been generated, the process returns to step (921). In this embodiment, the receiving procedure 3 is defined from the definition of the public server object 11.
1 is generated.

The steps of generating the dispatch procedure of FIG. 5 are as follows. The input is the class definition extracted in the public class definition extraction step, and the output is the dispatch procedure. First, it is checked if there is a method to process (931). If there is, execute step (932),
If not, the generation of the dispatch procedure ends. If there is a method to process, first create a function header (9
32). For the function name, an appropriate name is generated based on the method name. Next, the input / output definition of the function is generated. The function parameter name uses the same name as the method name. The data type of the function parameter converts the data type of the method parameter into the data type of the language used for interprocess communication.

After generating the function header, the body of the function is generated. First, based on the function parameter, a statement for restoring the message transmission statement to the object which is the processing request destination is generated (933). Next, a statement that causes the restored message to be executed is generated (934), and finally a statement that uses the message execution result as the function execution result is generated (935). Now that one function definition has been generated, the process returns to step (931). In this embodiment, the dispatch procedure 32 is generated from the definition of the public server object 11.

This concludes the description of the server application development steps. From here, the steps of developing the client application of FIG. 1 will be described based on the flowchart of FIG. The steps of client application development are as follows.

First, the client application developer searches the class objects available in the class object management means 4 (941). At the time of search, in addition to the information on the registered class object, if a document or the like explaining how to use the object is registered, those files can also be viewed.

The class object management means can only see the method header of the registered class object. The header is generated based on the accumulated dispatch procedure.

If there is a class object that can be used by the client application developer, the class object management means 4 specifies that the class object will be used. In this example, it is assumed that the client application developer is developing an airport management application as the client application 6 and uses the public server object 11 that allocates a bus for transportation from an airport terminal building to an aircraft as a server.

After designating the class object to be used,
The client application developer uses the proxy server object generation unit 5 to generate a proxy server object corresponding to the class object specified in (942) from the dispatch procedure 32 stored in the class object management means 4 (943). In this embodiment, a public server object 1 that creates a schedule
The proxy server object 61 corresponding to 1 is generated. The proxy server object is a class object that inherits the attributes of the proxy server class, and the client can send a message to the proxy server object to send a message to the public class object of the corresponding server.

Next, the client application developer writes a statement for sending a message to the proxy server object from the client application written in a certain object-oriented language (944). In this example, it is assumed that the airport management application, which is the client application 6, allocates the flight of the aircraft to each gate of the airport and then sends a message to the proxy server object 61 to create the schedule of the transfer bus. After the client application is completed, the client compiler 7 is used to generate the client application executable form 8. The client compiler 7 first uses the proxy class definition extraction unit 71 to extract the definition of the class object that inherits the attributes of the proxy class object (945).

Next, from the definition of the object 61 extracted by the transmission procedure group generation unit 72, the transmission procedure 8
1 and the transfer procedure 82 are generated (946). In this embodiment, a transmission procedure 81 and a transfer procedure 82 for transferring the message transmitted from the client application 6 to the proxy server object 61 to the public server object 11 of the server application 1 are generated. When the products are prepared, the compiler 73 compiles and links the client application 6, the transmission procedure 81, and the transfer procedure 82 (947) to generate the client application executable form 8 (948).

The flow charts of FIGS. 7 and 8 respectively include steps (943), (945), and (945) of FIG.
The flowcharts of FIGS. 9 and 10 are flowcharts showing the detailed processing procedure of the processing step of the processing step of step (946) in FIG. Each processing procedure will be described below.

The steps for generating the proxy server object shown in FIG. 7 are as follows. The input is a dispatch procedure stored in the class object management means 4, and the output is a proxy server object which is a class object inheriting the attributes of the proxy class object.

First, a class object is generated (9
51). The name of the class object generates the same name as the name of the corresponding public server object on the server side. Next, it is checked whether there is a function to be processed (952). If there is, step (953) is executed, and if not, the generation of the proxy server object ends. If there is a function to be processed, first, a method header is generated (953). The method name generates the same name as the method name of the corresponding public object on the server side. Next, the input / output definition of the method is generated. Generate the same parameter name and data type of the method of the public object on the server side that also corresponds to the parameter name and data type of the method. Finally, generate the method body. A statement for calling the transfer procedure is generated based on the parameter to the method (954).

Now that one method definition has been generated, the process returns to step (951). In this embodiment, the dispatch procedure 3 stored in the class object management means 4
A proxy server object is generated from 2.

The steps of extracting the proxy class definition in FIG. 8 are as follows. The input is the client application and the output is the definition of the class object that inherits the attributes of the proxy class object.

First, it is checked whether there is a class definition to be processed (961). If so, (962) is executed, and if not, the extraction of the proxy class definition ends. If there is a class definition to be processed, it is checked if the class definition inherits the attributes of the proxy class object (962). If it is inherited, step (963) is executed, otherwise step (96) is executed.
Execute 1). If the attribute of the proxy class object is inherited, the class definition is extracted (963). In this embodiment, the class definition of the proxy server object 61 is extracted from the client application 6.

The generation steps of the transmission procedure of FIG. 9 are as follows. The input is the class definition of the class object extracted in the extraction step of the proxy class definition, and the output is the transmission procedure.

First, it is checked whether there is a method to be processed (971). If there is, the step (972) is executed, and if not, the generation of the transmission procedure ends. If there is a method to process, a function header is first generated (972). For the function name, an appropriate name is generated based on the method name. Next, the input / output definition of the function is generated. The function parameter name uses the same name as the method parameter name. The data type of the function parameter converts the data type of the method parameter into the data type of the language used for interprocess communication.

After the function header is generated, the body of the function is generated. First, a statement for storing the input function parameter in the communication packet is generated (973). The communication packet is created by a method according to the communication protocol used for interprocess communication. Next, a sentence for transmitting the communication packet to the corresponding receiving procedure is generated (974). The processing request is transmitted to the receiving procedure on the server side using interprocess communication.

Since the result of message transmission is returned from the receiving procedure after message execution, a sentence for receiving a reply packet storing the processing result is generated (975). A statement for extracting the output function parameter from the reply packet is generated (976). The reply packet is disassembled by a method according to the communication protocol used for interprocess communication. Finally, a statement for returning the output function parameter extracted from the reply packet to the transfer procedure as the function execution result is generated (97
7).

Now that one function definition has been generated, step (971) is executed. In this embodiment, the transmission procedure 61 is generated from the class definition of the proxy server object 61 extracted in the proxy class definition extraction step.

The steps of generating the transfer procedure of FIG. 10 are as follows. The input is the class definition extracted in the extraction step of the proxy class definition, and the output is the transfer procedure.

First, it is checked whether there is a method to be processed (981). If there is, the step (982) is executed, and if not, the generation of the transfer procedure ends. If there is a method to process, a function header is first generated (982). For the function name, an appropriate name is generated based on the method name. Next, the input / output definition of the function is generated. The function parameter name uses the same name as the method name. The data type of the function parameter converts the data type of the method parameter into the data type in the language used for interprocess communication.

After generating the function header, the body of the function is generated. First, a statement for calling a transmission procedure corresponding to a function is generated based on the function parameter (983). Finally,
A statement is generated in which the execution result of the transmission procedure returned as the message transmission result is the execution result of the transfer procedure (98
4). Now that one function definition has been generated, step (9
Return to 81). In this embodiment, a transfer procedure 62 is generated from the class definition of the proxy server object 61 extracted in the proxy class definition extraction step.

The process flow when the object in the client sends a message to the proxy server object 61 is as follows. The method of the proxy server object 61, which is the destination of the message, calls the corresponding transfer procedure 82, and the transfer procedure 82 calls the corresponding transmission procedure 81. The called transmission procedure 82 transmits a processing request to the corresponding reception procedure 31 on the server side.

The receiving procedure 31 on the server side calls the corresponding dispatch procedure 32 after receiving the processing request.
The dispatch procedure 32 dispatches a message to the public server object 11 that is the processing request destination. After the method is executed, the execution result of the method is returned to the dispatch procedure 32. The dispatch procedure 32 returns the received execution result to the receiving procedure 31, and the receiving procedure 31
Returns the execution result to the transmission procedure 81 that has transmitted the processing request. The transmission procedure 81 returns the received processing result to the transfer procedure 82, and the transfer procedure 82 returns the received execution result to the method as the result of message transmission.

[0062]

As described above, according to the present invention, a server application developer can make a request from a process external to the application by simply causing the public class object to inherit the attributes of the public class object during application development. Generates a receiving procedure and a dispatching procedure required to receive a server application execution form. Further, by registering the published class object in the class object management means, other users can reuse the class object.

The client application developer is
After searching the class object management means, a class object to be used is designated to generate a proxy server object. The client can use the public server object of the server simply by sending a message to the proxy server object. The system creates the client application executable by creating the send and transfer procedures required to transfer the message sent to the proxy server object to the public server object of the corresponding server.

[Brief description of drawings]

FIG. 1 is a diagram illustrating the principle of the present invention.

FIG. 2 is a diagram showing steps of server application development.

FIG. 3 is a diagram showing steps of extracting a public class definition.

FIG. 4 is a diagram showing steps of receiving procedure generation.

FIG. 5 is a diagram showing steps of dispatch procedure generation.

FIG. 6 is a diagram showing steps of client application development.

FIG. 7 is a diagram showing steps of proxy server object generation.

FIG. 8 is a diagram showing a step of extracting a proxy class definition.

FIG. 9 is a diagram showing steps of transmission procedure generation.

FIG. 10 is a diagram showing steps of transfer procedure generation.

[Explanation of symbols]

1: server application, 11: public server object, 2: server compiler, 21: public class definition extraction unit, 22: reception procedure group generation unit, 23: compiler, 3: server application execution form, 31: reception procedure, 32 : Dispatch procedure, 4: Class object management means, 5: Proxy server object generation unit,
6: client application, 61: proxy server object, 7: client compiler, 71:
Proxy class definition extraction unit, 72: Transmission procedure group generation unit, 7
3: compiler, 8: client application execution type, 81: transmission procedure, 82: transfer procedure.

 ─────────────────────────────────────────────────── ─── Continuation of front page (72) Inventor Takahiro Seki 5030 Totsuka-cho, Totsuka-ku, Yokohama-shi, Kanagawa Prefecture Hitachi Ltd. Software Development Division

Claims (3)

[Claims] 1. In an object-oriented language system on a computer system connected by a network, when an application program is written in a certain object-oriented language, a class open to a class object that can accept a processing request from a process outside the application program. Inheriting the attributes of the objects, extracting the definition of the class objects that inherit the attributes of the public class objects when compiling the application program, and the message sent from the external process from the extracted definitions of those class objects Generate a receiving procedure that receives a message, and a dispatch procedure that dispatches the message received by the receiving procedure to the object to which the message is sent. Distributed Object Oriented system construction method characterized by comprising the that step. 2. A distributed object-oriented system construction method according to claim 1, wherein a class object that inherits the attributes of the public object is registered in a class object management means after construction of an application program execution form, and a class object to be registered. A method for constructing a distributed object-oriented system, further comprising the step of accumulating the dispatch procedure corresponding to. 3. The method of constructing a distributed object-oriented system according to claim 2, further comprising the step of designating a class object to be used after searching the class object management means, and the class object management means corresponding to the designated class object. Generating a class object that inherits the attributes of a proxy class object, which is a virtual class corresponding to the specified class object, from the dispatch procedure accumulated in
A definition of a class object that inherits the attributes of a proxy class object when the application program is compiled after building an application program capable of sending a message to the class object according to claim 1 by sending a message to the generated class object. To extract messages, to create a send procedure that sends a message to an external process from the definition of those extracted class objects, and dispatch a message send to a class object that inherits the attributes of the proxy class object to the send procedure. A method for constructing a distributed object-oriented system characterized by including a step of generating a transfer procedure.