JP2000047890A - Distributed object managing system, its object selecting method and storage medium recording its processing program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a distributed object managing system, its object selecting method which improve the performance of the whole distributed object system and a storage medium recording its processing program. SOLUTION: The system is provided with a means for selecting an optimal object by considering the number of references of each object of a calling object, the machine performance of a host and the CPU using rate and memory using rate of a server machine in which objects 2b and 3b exists, and the speed of a network between a client 1 and hosts in which the objects 2b and 3b exist. Thus, the client 1 can use an optimal target object without caring about the load of the target object in a distributed object environment.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a technique for selecting one target object from a plurality of objects in response to an object call request from a client in a distributed object system, and more particularly to improving the performance of the entire system. More particularly, the present invention relates to a distributed object management system, an object selection method thereof, and a recording medium recording a processing program thereof.

[0002]

2. Description of the Related Art In a distributed object environment (system), a communication function provided by an ORB (Object Request Broker) regardless of whether an object exists on a local computer or a remote computer on a network. Thus, the application on the client side and the object on the server side can communicate with each other without being aware of the location of the object.

Therefore, an object management system for managing the location of an object is provided. This object management system finds an object that the client calls for an object and selects it as a target object. However, the conventional object management system, when there are a plurality of objects that are the same as the object requested from the client, that is, when the same application runs on a plurality of servers, without considering the load state of the object, round robin ( The target object was selected by brute force.

Japanese Patent Application Laid-Open No. 10-40118 discloses a "client / server system and client terminal device" which proposes a load distribution technique in a case where objects performing the same processing exist in a plurality of processes of the same server. I have. However, with this technology, when the same application runs on multiple servers, only the distribution of processing is performed based on whether or not a process is being used. Has not been taken into account.

[0005]

The problem to be solved is that, in the prior art, the selection of the target object is not performed in consideration of the load on the server. SUMMARY OF THE INVENTION An object of the present invention is to provide a distributed object management system capable of solving the problems of the prior art and improving the performance of the distributed object system as a whole, an object selecting method thereof, and a recording medium recording a processing program thereof. That is.

[0006]

In order to achieve the above object, in a distributed object management system according to the present invention, a method for selecting an object thereof, and a recording medium on which a processing program is recorded, a plurality of identical objects (common objects) are provided. Information that affects the execution of each common object, such as the performance (CPU speed) of the server machine where each common object exists, the speed of the network between the client and the server machine, and the memory / CPU usage of the server machine And the best object is selected as the target object based on this information.

[0007] Also, the identification information used for calling the selected object is converted into the identification information of the self-management system, and is notified to the client on the external network, and the object calling from the client is called using the converted identification information. Receiving avoids a direct connection to the target object from a client on an external network such as the Internet.

[0008]

Embodiments of the present invention will be described below in detail with reference to the drawings. FIG. 1 is a block diagram showing a configuration of a distributed object management system according to the present invention according to the present invention and a first embodiment of a distributed object system using the same. This example shows a configuration of a distributed object system in a LAN (Local Area Network) environment, and when an object management system (described as “management program” in the figure) 6 selects a target object, A client 1 composed of a computer device and a target object directly communicate with each other, and the client 1 is connected to an ORB (Object Request Broker) 5 with servers 2, 3 and a management server 4 each composed of a computer device. .

A client application ("AP-C1" in the figure) 1a on the client 1 and a server application ("AP-C" in the figure) on the servers 2 and 3 are shown.
S1 "," AP-S2 ") 2a, 3a, and
The object management system 6 on the management server 4
A message is transmitted and received by B5. The object management system 6 is configured by reading a program recorded on a recording medium (not shown) such as an FD (flexible disk) into a hard disk device or the like in the management server 4, and includes an object management unit 6a and a target selection unit. 6b, a load information collection unit 6c, and an object management information unit 6d.

The object management system 6 uses CORB
A (Common ORB architecture, Colva) object information is managed, and it is necessary to start at least one in the domain. Further, such an object management system 6 can be activated plural times, and it is conceivable to apply different evaluation methods for each object management system. In this case, it is desirable to activate one object management system for each group and use the object selection method according to the present invention which is considered to be optimal for the group.

As described above, there may be a case where a plurality of object management systems are activated in the same domain. For the sake of simplicity, in this example, a system using one object management system will be described. I will do it. Further, the object management system 6 can operate on a computer (client 1, server 2, 3) on which the client application 1a or the server applications 2a, 3a operate, but in the example of FIG. Shows that an object management system 6 is activated on the management server 4.

When the server applications 2a and 3a are started, objects of the Rep1 interface (in the figure,
2b and 3b are generated on the server 2 and the server 3, respectively. It is assumed that each of the server applications 2a and 3a generates a plurality of objects. Here, for simplification of description, it is assumed that a single object is generated.

When each of the server applications 2a and 3a generates the objects 2b and 3b of the Rep1 interface after starting, the object management system 6
Is registered in the object information. Then, the client application 1a on the client 1 executes Rep1
When a request for invoking an object of the interface is made, the object management system 6 selects an object that performs optimal processing from among the registered objects 2b and 3b as a target object, and notifies the client application 1a of the target object. Give information.

As described above, each of the server applications 2a and 3a is
Since the object information is registered in the object management system 6, it is necessary to start the object management system 6 before starting the server applications 2a and 3a. Hereinafter, the operations of the client 1, the servers 2, 3, the management server 4, and the object management system 6 will be described in detail with reference to FIGS.

FIG. 2 is a flowchart showing an example of the processing operation of the server in FIG. When the server applications 2a and 3a are executed on the servers 2 and 3, the object management system 6 is searched for on the network (LAN 7) ("initial phase") (step 101), and the object management system 6 is triggered by object creation. Is requested to register an object ("registration phase") (step 102). After that, it becomes a waiting state for processing request,
A process execution request is received from the client 1 ("execution phase") (step 103).

FIG. 3 is a flowchart showing an example of the processing operation of the client in FIG. After the client application 1a is started, the client 1 searches the object management system 6 ("initial phase").
(Step 201), when an object is called (“object calling phase”) (Step 20)
2) requesting the object management system 6 to acquire information on the target object, acquiring an object reference (object identification information) from the object management system 6, and using this object reference to the servers 2 and 3 A request is made ("execution phase") (step 203). Here, if the object is not registered in advance, the client 1
Cannot make a call.

FIG. 4 is a flowchart showing an example of the processing operation of the object management system in FIG. After receiving the object registration request from the servers 2 and 3 (“registration phase”) (step 301), the object management system 6 receives the object call request from the client 1 (step 302). Upon receiving this object call request, the object management system 6 selects an object (target object) that performs the optimal processing (“target selection phase”).
(Steps 303 to 308 / details will be described later). Then, upon receiving the end notification from the server applications 2a and 3a, the registered object information is deleted ("end phase") (step 309).

FIG. 5 is an explanatory diagram showing an example of a processing flow in the distributed object system in FIG. 1, and FIG.
Is an explanatory diagram showing an example of object management information registered in the object management information section in FIG. 1, and FIG. 7 is an explanatory diagram showing an example of target selection criterion information used in the target selecting section in FIG.

Object management information 6e illustrated in FIG.
Are the host name 6f and the repository ID 6
g, object name 6h, object reference 6
i, the number of references 6j, the machine performance 6k, the network speed 61, and the host usage status 6m.

The host name 6a has information for identifying the server machine such as "Server1" or "Server2", the repository ID 6g has identification information common to the same object, and the object name 6h has an identification unique to each object. Information is Object Reference 6
In i, an object reference determined for calling an object from a client is registered. In reference number 6j, the number of clients of the caller is registered. In machine performance 6k, the capacity of a memory provided in the server machine or the server The number of operating clocks of the CPU of the machine is registered in the network speed 6l, the transfer rate of the network between the server and the client, and in the host usage state 6m, the respective usage rates of the memory and the CPU of the server machine are registered. Is done.

In the example of FIG. 6, two servers having the same object are registered. That is, "Se
On two server machines having host names “rver1” and “Server2”, the repository ID 6g is “ID”
The same object of “L: Rep1: 1.0” is managed with different object names (“o1”, “o2”).

In particular, the machine performance 6k, the network speed 6l, and the host use situation 6m are unique to the present embodiment, and the registration information indicates "Server"
The performance of two server machines, "1" and "Server2", is managed. That is, “Server1” is
The memory capacity is half that of “Server2” and C
Information that the PU speed (operation clock) is twice and the network speed is half is registered, and a situation where the memory usage is twice and the CPU usage is 1/3 times is registered.

The items constituting the target selection criterion information 6n shown in FIG. 7 include a priority 6o, an update timing 6v for machine information, and an update timing 6w other than machine information. In the update timing 6w other than the machine information, it is specified that the other information (other than the machine load information) is updated every time the object is called.

Further, the priority 6o is the number of references 6
p, memory 6q, clock 6r, network speed 6
s, memory occupancy 6t, and CPU usage 6u. Each item in this priority 6o (reference number 6p, memory 6q, clock 6r, network speed 6s, memory occupancy 6t, CPU usage 6u) ), The respective ratios (R1 to
R6%) is given in advance.

The operation of the distributed object system in FIG. 1 will be described below with reference to FIGS. 5 to 7 and FIGS. As described above, when the server applications 2a, 3a are started on the servers 2, 3, the ORB
The object management system 6 on the network (LAN 7) is searched by the function 5 (step 1 in FIG. 2).
01). Subsequently, when the objects 2b and 3b are generated by the server applications 2a and 3a, a request for registering the objects is made to the object management system 6.
(Step 102 in FIG. 2).

In response to this request, the object management unit 6a
Indicates that the object 2b,
3b is added. When the registration request of the object is completed, the host name, the object name, the repository ID (IDentifier, identifier), and the client 1 are stored in the object management information section 6d in the object management system 6 in the information shown in FIG. Object reference used for call request is set
(Step 301 in FIG. 4). Such object registration processing is performed only when the server applications 2a and 3a generate the objects 2b and 3b.

Thus, the objects 2b and 3b on the servers 2 and 3 are registered in the object management information section 6d. When the client application 1a is started in the client 1, the object management system 6 on the network (LAN 7) is searched by the function of the ORB 5 (step 201 in FIG. 3).

When the client application 1a issues a request for calling an object (step 20 in FIG. 3).
2), through the ORB 5, the object management system 6
The object management unit 6a transmits a target object selection request to the target selection unit 6b (step 30 in FIG. 4).
2). Here, the client application 1a
It is assumed that a call request for the Rep1 object has been made without specifying a host name or an object name (step 303 in FIG. 4).

The target selection unit 6b refers to the object management information unit 6d and searches for all the same Rep1 objects specified by the client application 1a (step 304 in FIG. 4). For the Rep1 object, the object 2b and the object 3b are registered in the object management information section 6d. Therefore, the target object is determined in consideration of the loads of the objects 2b and 3b and the servers 2 and 3 (see FIG. 4). Step 305).

That is, the target selection unit 6b requests the load information collection unit 6c for information required for selecting a target object according to the preset target selection reference information shown in FIG. As illustrated in FIG. 7, in the target selection criterion information, as a priority of each item, a ratio (R1 to R6) of the entire load information, a timing of updating the load information, and the like can be designated. In this example, an item designated as having a ratio of 0% in the entire load information is not a target of the load information. The target selection criterion information can be updated even while the object management system 6 is running, and its setting can be dynamically changed.

FIG. 6 shows information used for selecting a target object. The reference number of the object, the performance information of the server machine (memory capacity, CP
U clock), network speed between server and client, and server (host) usage rate (memory / C
PU usage rate) is collected. Target selector 6b
Requests the load information collecting unit 6c to acquire the load information shown in FIG.

When collecting the load information, the load information collecting unit 6c refers to the target selection reference information shown in FIG. 7 and checks whether the latest information should be obtained from the servers 2 and 3.
Gather only the information you need. Then, the contents of the object management information section 6d are updated with the acquired load information of the servers 2 and 3 (Step 306 in FIG. 4). The target selection unit 6b includes the contents of the object management information unit 6d,
Based on the target selection criterion information of FIG. 7, an optimal target object, that is, a target object with a small load is selected.

In order to comprehensively evaluate the load information in the selection of such a target object, the one with the most load or the one with the worst performance in each item is set as a reference value. An example in which the load status of each object is determined by numerically determining whether or not there is a load and multiplying the value by an arbitrary ratio in the overall evaluation is described below.

In the example of the object management information shown in FIG. 7, for the sake of explanation, the load information of each object represents a value by a magnification relative to a reference value. Considering this case, the load value L1 for the object 2b of the server 2 is: L1 = (r × 2 × R1) + (m × R2) + (c × 2 × R
3) + (n × R4) + (w × 2 × R5) + (b × R6)

Similarly, the object 3b of the server 3
Load value L2 is calculated for the target selection unit 6b
Compares the load values L1 and L2, determines that the larger the value is, the less the load is applied, and selects the target object. Here, assuming that the load value L1 <the load value L2 holds, the target selection unit 6b selects the object 3b as the target object (Step 307 in FIG. 4).

Then, the target selection unit 6b passes the object reference of the object 3b on the server 3 to the object management unit 6a,
a transmits the object reference passed from the target selection unit 6b to the client application 1a (step 308 in FIG. 4). The above is the target selection phase.

When the client application 1a executes the processing by the object 3b using the received object reference, the server application 3a responds to the request of the client application 1a (step 203 in FIG. 3, step 10 in FIG. 2).
3). Steps 203 and 103 are repeated, and the client application 1a issues a service request to the object 3b.

When the object management system 6 is notified of the end of the server application 3a, the object management unit 6a deletes the information of the object 3b from the object management information 6d (step 3 in FIG. 4).
09).

Next, as a second embodiment of the present invention, taking the case where the client 1 accesses an object in the intranet via the Internet, in particular, the client (1) is operated by a proxy (proxy server) operating on a firewall. An example will be described in which an external client 1 does not directly access an object in an intranet by making only a proxy aware of the object from the outside.

FIG. 8 is a block diagram showing a configuration of the distributed object management system according to the present invention and a distributed object system using the same according to a second embodiment of the present invention.
In this example, the management proxy 60 as the distributed object management system of the present invention is activated on the firewall 41. As shown, the client 10 and the externally connected computer 40 are connected via the Internet 70, and the externally connected computer 40 and the server 2 and the server 3 are connected over the LAN 7 by the ORB 5.

On the client 10, a client application (described as "AP-C2" in the figure) 11 operates. The server application 2a operates on the server 2 and the server application 3a operates on the server 3, and are the same server application responding to a request from the client application 11, respectively.
When the server applications 2a and 3a are started,
Rep1 objects 2b and 3b are generated on server 2 and server 3, respectively.

The external connection computer 40 comprises a firewall 41 and a management proxy 60. Although the management proxy 60 receives a connection from the client application 11 through the firewall 41, the registration and selection / management operation of the object are the same as those in the embodiment in FIG. The management proxy 60 includes an object management unit 6a, a target selection unit 6b, a load information collection unit 6c,
A relay communication unit 61 and a relay information management unit 62 are provided in addition to the object management information unit 6d.

While the management proxy 60 is running, the server applications 2a, 3
When a is started, the object information of the server applications 2a and 3a is registered in the management proxy 60.
When executing the processing by the server applications 2a and 3a via the Internet 70, the client application 11
From the management proxy 60 to the server application 2a, 3
The object information of “a” is acquired, and processing is executed based on the acquired information.

The operation of the management proxy 60 operating on the firewall 41 will be described below. FIG.
9 is a flowchart showing an operation example of the management proxy in FIG. 8 according to the present invention. This example shows an outline of the processing of the management proxy 60 operating on the firewall 41 of FIG. 8, and the processing on the server 2, 3 and client 10 side is the same as that of FIG. Description is omitted.

In FIG. 9, when the management proxy 60 receives an object registration request from the server applications 2a, 3a, the management proxy 60
The object is registered in the object management information section 6d (“registration phase”) (step 401). Thereafter, when the client application 11 issues a request for calling an object, the management proxy 60 is transmitted through the ORB 5.
Is requested to select a target object (target selection phase) (steps 402 to 409).

After the target object is determined, when the client application 11 makes a processing request, the management proxy 60
And relay the communication between the server application 2a and the server application 3a. Then, upon receiving the communication end notification from the client application 11, the communication between the client 10 and the servers 2 and 3 is ended (relay communication phase) (steps 410 to 412). Further, when the server applications 2a and 3a become inactive or the objects 2b and 3b are deleted, the object information registered in the object management information section 6d is deleted (end phase) (step 413).

FIG. 10 is an explanatory diagram showing an example of the processing flow in the distributed object system in FIG.
FIG. 1 is an explanatory diagram showing a registration example of the relay information management unit in FIG. In the relay information 62a shown in FIG.
Each object (“Obj1”, “Obj2”) 62
Items b, 62c include a client address 62d, a repository ID 62e, an object name 62f, an object reference 62g, and identification information 62h. In the identification information 62h, information for identifying a server that executes a process requested by a client application associated with the client address 62d, the object reference 62g, the repository ID 62e, and the object name 62f is set.

The operation of the distributed object system in FIG. 8 will be described below with reference to FIGS. 10, 11, and 2, 3, and 9. In the same manner as described with reference to FIG.
When the server application 2a, 3a is started,
a obtains the location of the management proxy 60 by the function of the ORB 5 (step 101 in FIG. 2). Thereafter, the server applications 2a and 3a make an object registration request to the object management unit 6a (step 1 in FIG. 2).
02), the object 2 is stored in the object management information section 6d.
b and 3b are registered (step 401 in FIG. 9).

The client application 11
After the location of the management proxy 60 is obtained by the function of the RB 5 (step 201 in FIG. 3), the Rep1 object is called (step 202 in FIG. 3). Hereinafter, the target selection phase will be described.

The management proxy 60 transmits the object call request of the client application 11 to the ORB 5
Received through the server, the target selection unit 6b selects an optimal target object based on the information acquired by the load information collection unit 6c (Steps 402 to 40 in FIG. 9).
7). This target object selection method is shown in FIG.
Therefore, the description is omitted here. Here, as in the case of FIG. 5, it is assumed that the object 3b has been selected as the optimal object (target object).

When the target object is determined in this way, the target selection unit 6b changes the address in the object reference of the object 3b, which is the target object, to the address of the management proxy 60, and then passes it to the object management unit 6a. Then, the object reference, repository ID, and object name before the change are stored in the relay information management unit 62 as the relay information shown in FIG. 11 together with the address of the client 10 (step 408 in FIG. 9).

Further, the object management section 6a transmits the changed object reference to the client application 11. (Step 409 in FIG. 9). The client application 11 transmits an object invocation request using the object reference received from the object management unit 6a in this manner,
For example, a Rep1 object is called.

The management proxy 60 that has received an object invocation request from the client application 11
The communication relay unit 6c refers to the registration contents of the relay information management unit 62 using the repository ID and the object name as keys, determines that the original connection destination of the client application 11 is the server 3, and furthermore, Part 6
c obtains the object reference from the relay information management unit 62, and calls the object 3b of the server 3 using this object reference (step 410 in FIG. 9).

Then, the client application 1
1 requests execution of a process using the object reference received from the object management unit 6a.
(Step 203 in FIG. 3), the management proxy 60 receives the request from the client application 11 through the ORB 5 by the communication relay unit 6c, and acquires the address and the identification information of the server 3 from within the relay information management unit 62. , Request a service to the object 3b.

When receiving the reply from the object 3b, the communication relay unit 6c transmits the reception information from the object 3b to the client 10 based on the identification information in the relay information management unit 62 and the address of the client 10. (Step 41 in FIG. 9).
1). Hereinafter, step 203 in FIG. 3 and step 1 in FIG.
03 is repeated, and the client application 11 and the object 3b transmit and receive a message.

In this case, the client application 11 looks as if it is receiving a service from the object 3b which is the target object, but actually connects to the management proxy 60 using the received object reference and 60, the object reference is dynamically changed and the client 10 is changed to the target object (object 3b).
Is sending a request from

When the connection termination request is transmitted from the client application 11 to the object 3b, the relay communication unit 6c deletes the relay communication information of the client application 11 and the object 3b from the relay information management unit 62 (step 412 in FIG. 9). ). Then, the object 3b is deleted by the server application 3a,
When the server application 3a becomes inactive, the object management unit 6a deletes information on the object 3b from the object management information 6d (step 41 in FIG. 9).
3).

As described above with reference to FIGS. 1 to 11, in the distributed object management system and the object selection method according to the present embodiment, an object call request from a client in a distributed object environment is
When there are a plurality of request target objects, the target object is selected in consideration of the load of the object and the server (host machine) executing the object.

That is, when an object is called, the reference number of each object to be called, the machine performance of the server (host) where the object exists, the CPU utilization and the memory utilization of the server machine, and the communication between the client and the server where the object exists. Select the optimal object considering the speed of the network. As a result, in the distributed object environment, the client application can use the optimum target object without changing the application and without being conscious of the load on the target object, thereby improving the processing of the entire system. be able to.

For a connection from a client on the external network, a target object that performs optimal processing can be used in a form in which the target object is completely hidden from the client.

The present invention is not limited to the embodiment described with reference to FIGS. 1 to 11, and can be variously modified without departing from the gist thereof. Further, since an object of the present invention is to select a target object that performs processing optimal for a request from a client application, a case where a plurality of server applications update the same database will not be described.

[0062]

According to the present invention, when the same application runs on a plurality of servers, when an object is called, not only information on whether or not a process is used, but also the object to be called (target object) A target object can be selected in consideration of the load of each existing server, and the performance of the entire distributed object system can be improved.

[Brief description of the drawings]

FIG. 1 is a block diagram showing a configuration of a distributed object management system according to the present invention and a first embodiment of a distributed object system using the configuration.

FIG. 2 is a flowchart illustrating an example of a processing operation of a server in FIG. 1;

FIG. 3 is a flowchart illustrating an example of a processing operation of a client in FIG. 1;

FIG. 4 is a flowchart illustrating an example of a processing operation of the object management system in FIG. 1;

FIG. 5 is an explanatory diagram showing an example of a processing flow in the distributed object system in FIG. 1;

FIG. 6 is an explanatory diagram showing an example of object management information registered in an object management information section in FIG. 1;

FIG. 7 is an explanatory diagram showing an example of target selection criterion information used in a target selection unit in FIG. 1;

FIG. 8 is a block diagram showing a configuration of a distributed object management system according to the present invention and a second embodiment of a distributed object system using the same.

FIG. 9 is a flowchart illustrating an operation example of the management proxy in FIG. 8 according to the present invention;

FIG. 10 is an explanatory diagram showing an example of a processing flow in the distributed object system in FIG. 8;

FIG. 11 is an explanatory diagram showing a registration example of a relay information management unit in FIG. 8;

[Explanation of symbols]

1, 10: client, 1a, 11: client application ("AP-C"), 2, 3: server, 2
a, 3a: server application (“AP-S1”,
“AP-S2”), 2b, 3b: Object (“Ob
j1 ”,“ Obj2 ”), 4: management server, 5: ORB
(Object request broker), 6: object management system (“management program”), 6a: object management unit, 6b: target selection unit, 6c: load information collection unit, 6d: object management information unit, 6e:
Object management information, 6f: host name, 6g: repository ID, 6h: object name, 6i: object reference, 6j: number of references, 6k: machine performance, 61: network speed, 6m: host use status, 6n : Target selection criteria information, 6o: priority,
6p: reference number, 6q: memory, 6r: clock, 6s: network speed, 6t: memory occupancy,
6t: CPU usage rate, 6v: Update timing of machine information, 6w: Update timing other than machine information, 7: LA
N, 40: external connection computer, 41: firewall, 60: management proxy, 61: relay communication unit, 62:
Relay information registration unit, 62a: relay information, 62b, 62c:
Object, 62d: client address, 62
e: repository ID, 62f: object name, 62
g: object reference, 62h: identification information, 7
0: Internet.

Claims (8)

[Claims] 1. A distributed object system in which a client and a server are connected by an object request broker (ORB), wherein a target object called by the client is selected from each of a plurality of objects generated by the server. Storage means for storing the same object (common object) generated by the plurality of servers in association with each server that has generated each of the plurality of servers; CP
A collection unit for collecting and storing information on load affecting the execution of each common object including the U performance for each common object; and a storage unit for determining whether an object called and requested by a client is a common object. And a selecting means for selecting an object having the minimum load as the target object by referring to the load information collected by the collecting means when a common object is requested. Characteristic distributed object management system. 2. The distributed object management system according to claim 1, wherein the collection means includes, as the load information to be collected for each common object, a reference number of each common object together with a CPU performance of each server. A distributed object management system, which collects a memory usage rate and a CPU usage rate of a server, and a speed of a network between a client and a server. 3. The distributed object management system according to claim 1, wherein each of the loads affecting the execution of the common object including the CPU performance of each of the servers has a different weight. The distributed object management system is characterized in that the object is assigned and converted into a numerical value, and the selecting means selects, as the target object, an object having a minimum sum of numerical values of the loads. 4. The distributed object management system according to claim 1, wherein the identification information used for calling the target object selected by said selection means is converted into the identification information of its own management system, and Conversion means for notifying clients on the network;
Identification storage means for storing the client that has notified the converted identification information and the identification information before conversion in association with each other, and accepting a request for calling an object using the converted identification information from a client on the external network And a relay unit for relaying communication between the client on the external network and the target object based on the storage content of the identification storage unit. 5. The distributed object management system according to claim 4, wherein the distributed object management system is provided on a firewall that controls connection with a client on the Internet. 6. A distributed object system in which a client and a server are connected by an object request broker (ORB), and a target object called by the client is selected from a plurality of objects generated by the server. Storing the same object (common object) generated by the plurality of servers in a first storage device in association with each server that has generated the object. Collecting information on the load affecting the execution of each common object including the CPU performance of each server that has generated the common object for each common object and storing the information in a second storage device; Objects are common Determining whether or not the object is an object by referring to the storage content of the first storage device; and, when a common object is requested, referring to the load information stored in the second storage device. Selecting an object having a minimum value as the target object. 7. The object selecting method of the distributed object management system according to claim 6, wherein the identification information used for calling the selected target object is converted into the identification information of the self-management system and notified to the client on the external network. Performing the conversion, storing the converted identification information in the storage device in association with the client that has notified the converted identification information, and the object using the converted identification information from the client on the external network. And relaying communication between the client on the external network and the target object based on the contents stored in the storage device. 8. A recording medium for recording data and a program to be read and processed by a computer, wherein each step in the object selection method of the distributed object management system according to claim 6 is performed by a computer. A program for causing a computer to execute the program.