JP2002014832A - Network computer system and server - Google Patents

Abstract

PROBLEM TO BE SOLVED: To improve the reliability of the interface of a remote procedure call in a network computer system. SOLUTION: In this network computer system, remote procedure call(RPC) communicating means (stub programs) 22 and 32 include interface identification information 16 generated by hashing from interface definition information (IDL) 11 in an RPC so that communication in the RPC can be performed based on the definition information 11 by using the identification information 16.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a network computer system and a server, and more particularly, to a network computer system and a server using a remote procedure call with improved reliability of an interface between programs.

[0002]

2. Description of the Related Art In a network computer system constituting a distributed processing environment, a remote procedure call (RPC) may be adopted in order for a plurality of programs operating on a server or a client to mutually distribute processing. In the RPC, for example, an application program on a server causes a part of the procedure to be executed by another application program on a client, and receives the result as a return value in the same manner as a normal procedure call.

In RPC, at the time of development, the interface is defined by an interface definition script (ID
L). A program (stub (STUB) program) that supports the application program when executing communication by RPC based on IDL (executes communication by RPC instead).
Is automatically generated. The stub program is compiled into an application program on each of the server and the client. During operation, the application programs on the server and the client execute communication by RPC using the respective stub programs.

[0004]

SUMMARY OF THE INVENTION For various reasons, R
The interface of the PC has been changed and the ID
L may be upgraded (revised). Originally, this would have been reflected in the interface as well, both at the server and at the client.

[0005] However, if the IDL is upgraded, an execution failure may be output due to interface mismatch during operation. For example, as a result of a stub program incorporated in an application program on a server analyzing a transmission packet received from a client and verifying whether the interface matches,
The interface may not match, and execution not possible may be output. Such a situation often occurs because the server (administrator) has not compiled a new stub program. In this case, the processing stops halfway. Until the verification is completed, interface mismatch cannot be detected.

Further, when the IDL is upgraded, an application program may be executed using an inappropriate return value of the RPC at the time of operation, although the IDL is originally mismatched. That is,
Although the IDL is actually changed, the interface may not be changed when viewed as a data packet. This is the case, for example, when the version upgrade does not relate to the format of the transmission packet and the like, but corrects a trivial bug (spelling mistake or the like). In this case, for example, if the format of the transmission packet received from the client matches, the application program that has received this via the stub program on the server returns a return value to the application program on the client. But in this case,
Since the versions do not match, the server application program may have performed an erroneous process. Therefore, there is also a possibility that the application program of the client also executes an erroneous process using an erroneous return value based on the erroneous process.

[0007] In order to prevent such malfunctions, it is desirable to manage the IDL version (version number). However, to manage the version number of IDL, the developer needs to describe the version information in IDL. Since this is troublesome for the developer, the description may be omitted. In addition, since the description is manually managed, the developer may forget the description or may mistake the content. Therefore, there is a case where it is not managed or a case where it is managed but not appropriate. Note that version management of IDL is not required.

[0008] It is an object of the present invention to provide a network computer system in which the reliability of a remote procedure call interface is improved.

Another object of the present invention is to provide a network computer system that reliably detects interface mismatches without managing changes in the interface of a remote procedure call.

It is another object of the present invention to provide a server in which the reliability of a remote procedure call interface is improved.

[0011]

The network computer system of the present invention comprises a remote procedure call (R).
PC) that includes interface identification information generated from the definition information of the communication interface in the PC, and performs RPC communication based on the definition information using the identification information.
PC communication means is provided.

According to the network computer system of the present invention, the interface identification information is generated from the interface definition information of the RPC itself. Therefore, the definition information can be uniquely determined for the RPC interface. As a result, when the interface is changed (IDL is upgraded), it is possible to reliably detect a mismatch between the interfaces during operation. In particular, it is possible to prevent the application program from being executed using an inappropriate return value of the RPC even though the interfaces do not match. In addition, it is possible to eliminate the burden on the developer for managing and describing the version of the interface, and to prevent the occurrence of interface inconsistency due to a human error in the version management and the like.

Further, the network computer system of the present invention comprises: first generating means for generating interface identification information from communication interface definition information in a remote procedure call; and a remote procedure based on the definition information using the identification information. Second generation means for generating RPC communication means for performing communication in a call and adding identification information to the RPC communication means.

According to the network computer system of the present invention, the identification information of the interface is generated from the definition information of the interface of the RPC itself, and this is used for the RPC performing the communication in the remote procedure call.
It is added to the communication means. Therefore, without the burden of the developer on the management and description of the interface version,
In effect, the management and the like can be performed, and it is possible to prevent the occurrence of interface mismatch and the like due to a human error or the like in the management and the like.

[0015]

FIG. 1 is a configuration diagram of a network computer system, showing the configuration of a network computer system according to the present invention.

The network computer system comprises a plurality of network computers 20, 30, and a network 40 connecting them. Each of the network computers 20 and 30 includes, for example, a server 20 and a client 30 and has a remote procedure call (RP).
Communication between computers is performed by C). Each of the server 20 and the client 30 may be plural. The network computer system includes, for example, a development host computer 1 in addition to the server 20 and the client 30.
0 is provided.

The host computer 10 has a stub (STU) for developing the server 20 and the client 30.
B) A generator 12, a compiler and a linker 17 are provided. The stub generator 12, the compiler and the linker 17 are realized by a program that exists on a main memory (not shown) constituting the host computer 10 and is executed on a CPU (not shown) constituting the host computer 10. . Further, the host computer 10
An interface definition script (IDL) 11, an application (source or object) program (server application) 18 running on the server 20, and an application (source or object) program (client application) 19 running on the client 30;
It is provided on an auxiliary storage (not shown) such as a magnetic disk device.

The host computer 10 may be connected to the server 20 or the like via a network 40 as shown by a dotted line in FIG. In this case, a stub program 15 described later is distributed to the server 20 and the like via the network 40. In addition, the stub generator 12, the compiler and the linker 17 are provided with upgraded IDLs.
Stub program 15 based on (corrected IDL) 11 '
Since it is necessary to generate (22, 23), the server 20
And the client 30 (not shown). In this case, the modified IDL 11 'is provided to the server 20 and the client 30 by a flexible disk or the like.

The stub generator 12 generates a stub program (or stub code) 15. The stub program 15 supports the application program when performing communication by RPC. That is, instead of the application programs (21, 31), RPC
RPC communication means 15 (22, 3
2). For this generation, stub generator 1
2 comprises a first generating means 13 and a second generating means 14. The first generation unit 13 generates interface identification information 16 from the interface definition information (IDL) 11 for communication in RPC. The second generation means 14
RP performing communication in RPC based on definition information 11
C communication means 15 is generated, and identification information 16 is added to the RPC communication means 15.

In this example, the definition information 11 comprises an interface definition script (IDL) 11. ID
L11 defines a communication interface in RPC. The identification information 16 includes a hash value (hash code) 16 generated from the definition information 11. Therefore, in this example, the hash value 16 as the identification information 16 is generated from the IDL 11 by hashing, and the IDL 1
1, a stub program 15 is generated. Then, the hash value 16 is added (embedded) to the stub program 15. To this end, the stub generator 12 has a hash function. As a hash function,
For example, using the well-known RSA-MD5: RFC1321,
For example, a message digest of 16 bytes is used.
As the stub program 15, a stub program (client stub) 32 on the client 30 (which becomes) and a stub program (server stub) 22 on the server 20 (which becomes) are generated.

Here, an example of the IDL 11 is shown in FIG.
In FIG. 2, the IDL 11 describes various information of the RPC interface. The IDL 11 is a text file as shown in FIG. The entire IDL 11 of FIG. 2 is used for hashing. The hash value 16 generated as a result of hashing is a 16-byte hexadecimal number as shown in FIG.

FIG. 3 shows an example of the server stub 22. The server stub 22 actually has two hash values 16
(161, 162) is held. For example, hash value 1
61 is a transmission packet 5 received from the client 30
This is for comparison with the hash value 16 embedded in 0. The server stub 22 analyzes the received identification information 16 and, if it does not match the identification information 161, the server stub 22 returns error information to the client 30 that is the transmission source of the received identification information 16. Hash value 162
When the server 20 transmits the transmission packet 50 to the client 30, the server 20 embeds the transmission packet 50 in the transmission packet 50. The server stub 22 also holds two error values 221 and 222. Error values 221 and 222 are
This is an error message returned to the client 30 when the comparison result between the hash value 161 and the hash value 16 embedded in the transmission packet 50 received from the client 30 does not match. The error values 221 and 222 are properly used depending on the type of error. Note that the client stub 32 has a similar configuration.

The compiler and linker 17 links the client stub 15 (32) to the compiled client application (source) 19 to obtain a load module (client RM) 33 of the executable format of the client application. Is installed on the client 30. Further, the compiler and linker 17 links the server stub 15 (22) to the compiled version of the server application (source) 18 to obtain a load module (server RM) 23 in the executable form of the server application. Install on 20. Note that the client RM 33 is also called a client application, and the server RM 23
Is also a server application.

Server 2 which is a network computer
0 has a plurality of (executable) server applications 23. Each of the plurality of server applications 23 is provided according to each of the services (procedures called) provided by the server 20. Each of the plurality of server applications 23 includes a stub program (server stub) 22. The client 20, which is a network computer, includes a plurality of (executable) client applications 33. Each of the plurality of client applications 33
Are provided in accordance with each of the processes (applications) to be executed. Each of the plurality of client applications 33 includes a stub program (client stub) 32.

Server 2 which is a network computer
0 and the client 30 in the form of a load module,
Each has stub programs 22 and 32 (15) as RPC communication means. Stub programs 22 and 32
Is the definition information 1 of the communication interface in the RPC.
RPC communication is performed based on the definition information 11 including the interface identification information 16 generated from 1. Specifically, in the client 30, the RPC communication unit 32 transmits at least the identification information 16. In the server 20, the RPC communication unit 22 analyzes at least the received identification information 16.

The server 20 and the client 30 communicate with each other via the network 40 according to the RPC. In this communication, the identification information 16 is added to the head of the transmission data (or to the transmission packet at the head). Therefore, in this example, as described above, the hash value 16 that is the identification information 16 generated from the IDL 11 that is the definition information 11 is stored in the first transmission packet.

The client stub 32 transmits at least the hash value 16 as the identification information 16. Therefore, the stub program 15 generated as the client stub 32 has a function of transmitting the hash value 16. The server stub 22 analyzes at least the hash value 16 as the received identification information 16. Therefore, the stub program 15 generated as the server stub 22
Has a function of analyzing the hash value 16. Note that, in practice, the client stub 32 also receives the received identification information 16.
May be analyzed, and the server stub 22 may also transmit the identification information 16, so that both may be the same.

The server 20 and the client 30 include transmission processing units 24 and 34, respectively, for performing inter-computer communication. Further, the client 30 includes a display device 35 for displaying a processing result or the like in the client application 31 and an input device 36 for inputting an instruction for a processing in the client application 31.

FIG. 4 shows a flow of processing for generating the stub programs 22 and 32.

The developer creates the IDL 11 (step S1), and thereafter activates the stub generator 12 (step S2).

The stub generator 12 reads the IDL 11 (step S3) and hashes the IDL 11, thereby calculating a hash value 16 from this (step S4). Thereafter, the stub generator 12 generates the client stub 32 (Step S5). The hash value 16 is embedded in the client stub 32 as the identification information 16. Also, the stub generator 12 generates the server stub 22 (step S
6). The same hash value 16 is embedded in the server stub 22 as the identification information 16.

The developer builds (built-in) a client application (also referred to as APL, hereinafter the same) 33 in the client 30 (step S7). That is, the client stub 32 is linked to the compiled (31) of the client application 19 by the compiler and linker 17 to obtain a load module (client RM) 33 of the client application 19, and this is installed in the client 30.

Further, the developer builds (built-in) the server application 23 in the server 20 (step S8). That is, the server application 1 is generated by the compiler and the linker 17.
By linking the server stub 22 to the compiled version (21) of the server application 8, a load module (server RM) 23 of the server application 18 is obtained, and this is installed in the server 20.

FIG. 5 shows the RPC in the client 30.
1 shows a communication processing flow.

The client application 31 (of the client RM 33) requests the client stub 32 (of the client RM 33) to call the server 20 (step S11).

The client stub 32 performs a process of creating transmission data (step S12). In this creation process, the client stub 32 embeds the hash value 16 held by itself in the head of the data (step S1).
3), a transmission packet 50 is generated by assembling the parameters (step S14), and the transmission is requested to the transmission processing unit 34.

The transmission processing unit 34 of the client 30 receiving the request performs communication processing. That is, the transmission processing unit 34
Transmits the transmission packet 50 to the server 20 (step S15). This transmission processing corresponds to step S21 in FIG. Upon receiving a response from the server 20, the transmission processing unit 34 receives the processing result (step S16). This receiving process corresponds to step S29 in FIG. After this,
The processing in the client 30 returns to the client application 31 via the client stub 32 (step S17).

FIG. 6 shows a communication processing flow by the RPC in the server 20.

The transmission processing unit 24 of the server 20 receives the transmission packet 50 from the client 30 (step S
21), search and select the server stub 22 to be started (step S22), and start the server stub 22 (step S23). Step S21 corresponds to step S15 in FIG.

The started server stub 22 analyzes the received transmission data. That is, the server stub 22 checks whether the received hash value 16 is equal to the hash value 16 embedded in the server stub 22 (step S24).

If they are equal, the server stub 22 analyzes subsequent parameters of the transmission packet 50 (Step S).
25), and starts the server application 21 (step S2)
6) Wait for a response. The started server application 21 performs a predetermined process using the analyzed subsequent parameter,
The processing result is returned to the server stub 22 (step S2
7). The server stub 22 sets the processing result from the server application 21 as a return value (return value) (Step S2
8) Request the transmission processing unit 24 for a reply.

The transmission processing unit 24 returns a result to the client 30 according to the request from the server stub 22 (step S29). This processing corresponds to step S16 in FIG.
Corresponding to

On the other hand, the hash value 16 received in step S24 and the hash value 16
If is not equal, the server stub 22 sets an error value (step S30) and requests the transmission processing unit 24 to return. Thereafter, step S29 is executed.

FIGS. 7 and 8 are explanatory diagrams of the interface version detection processing using the hash value 16.

In FIG. 7, when developing the application programs 23 and 33 adopting the RPC, an interface definition script (IDL) 11 is prepared by the developer. The IDL 11 describes an RPC interface.

The stub generator 12 generates a stub program 15 based on the IDL 11. The stub generator 12 generates identification information (hash value) 16 from the IDL 11 by hashing. The stub generator 12 adds the generated identification information 16 to the stub program 15 (the server stub 22 and the client stub 32).

The identification information 16 may be any information that can uniquely specify (the version of) the IDL 11. Therefore, the identification information 16 is version information of the IDL 11. For example, the identification information 16 includes a hash value 16 (hash value) generated from the IDL 11. That is, the identification information 16 is generated by hashing the IDL 11 itself. There is virtually no probability that the hash values 16 collide with each other. Therefore, the hash value 16 can uniquely specify (the version of) the IDL 11. ID
Since the version information of L11 is generated by hashing the IDL11 itself, there is no need for the developer to describe and manage the version number of the IDL11 in the IDL11.
There is no human error in the version information of L11.

The stub program 15 is incorporated into an application program by compiling and linking executed by the compiler and linker 17. That is, the server stub 22 and the client stub 32 are linked to the compiled server application 21 and client application 31, respectively. Thereby, the server application 21
Load module (server RM) 23 and client application 31 load module (client RM)
33 are obtained.

When operating the application programs 23 and 33 adopting the RPC, the application programs 23 and 3 on the server 20 and the client 30 are operated.
3 executes communication by RPC according to the respective stub programs 22, 32 (15). For example, the client stub 32 generates a transmission packet 50 to be transmitted,
The hash value 16 which is the identification information 16 added to the self is added to the head. Server stub 22 that received this
Extracts the hash value 16 from the transmission packet 50 and compares it with the hash value 16 added to itself. If they match, IDL11 (version)
Will match. Therefore, it is guaranteed that the subsequent communication is correct.

In FIG. 8, after the development of FIG. 7, the IDL (modified IDL) 11 'upgraded (revised) is created by the developer by changing the interface of the RPC. Thus, as described above, the stub generator 12 generates a stub program 15 'based on the modified IDL 11', and generates a new hash value (new hash value) 16 'from the modified IDL 11'. If there is a version upgrade of IDL11, even if it is not a change of the format of the transmission packet but a mere bug fix,
The modification is always reflected in the hash value 16. That is, before and after the version upgrade, the hash values 16 and 1
6 'will always be different. Therefore, also from this point, the hash value 16 can uniquely specify (the version of) the IDL 11.

Normally, the stub generator 12
In both the client 30 and the server 20, the client stub 32 'in which the new hash value 16' is embedded.
And a server stub 22 '. In addition,
After generating the new hash value 16 ′, the stub generator 12 compares the hash values 16 and 16 ′, and if there is no difference between them, determines that the interface change is not related to the RPC communication. , Do not generate a new client stub 32 'and server stub 22'. As a result, unnecessary updates are not performed.

However, suppose that the server 20 did not compile (and link) the stub program 15 'based on the modified IDL 11', even though it was created. It is assumed that the client 30 has been compiled (and linked) as described above. In this case, at the time of operation, for example, the client stub 32 ′ transmits the transmission packet 50 to which the new hash value 16 is added at the head thereof to the server stub 22. Server stub 22 that received this
Is the new hash value 16 ′ extracted from the transmission packet 50 and the (old) hash value 1
Compare with 6. Therefore, since they do not match, the ID
The server stub 22 notifies the client stub 32 'of an error, assuming that L11 (version) does not match.

Therefore, when the first transmission packet 50 is analyzed, it can be detected that the IDLs 11 do not match. Thus, it is possible to prevent the application programs 23 and 33 from being executed using an inappropriate return value of the RPC. Further, since it is not necessary to analyze the subsequent packets, there is no waste in processing. Contrary to the above, the same applies to a case where a new client stub 32 'is not compiled in the client 30. In addition, if the user mistakenly uses the old server stub 22 or client stub 32
The same is true even if you have started Further, for example, in the server 20, the server stub 22 (accordingly,
The same applies to the case where IDL 11) is changed without permission.

FIGS. 9 and 10 are network computer system configuration diagrams showing the configuration of a general-purpose RPC system using the network computer system (RPC system) of FIG.

In the RPC system of FIG. 1, it is necessary to prepare an IDL 11 and a stub generator 12 according to each of the application programs (subroutines) in the server 20. Further, in order to introduce an interface check based on the hash value 16 into an existing RPC system, it is necessary to change an existing program to perform the processing.

Therefore, as shown in FIG. 9, the RPC shown in FIG.
The system is adopted as a base RPC system. That is, the RPC server system 200 and the RPC client system 300 correspond to the server 20 and the client 30 in FIG. 1, respectively. Communication between the server 20 and the client 30 in FIG. 9 is performed by one RPC server system 200 and one RPC client system 30.
Depends on 0. RPC server system 20 as a base
0 and the communication between the RPC client system 300 and the actual application programs 21A and 31A (therefore, communication between the application programs)
A single universal interface 60 performs unified communications. Between the general-purpose interface 60 and the actual application programs 21A and 31A,
Each is a marshalling program (or code) 22A
And 32A are present. Marshalling program 22
A and 32A perform various processes executed by stub programs (stub programs 22 and 32 in FIG. 1) in a normal RPC system.

That is, as can be seen from FIG. 9, the server 20 and the client 30 in FIG. 9 constitute a hierarchical communication means. The marshalling programs 22A and 32A, which are lower-level RPC communication means, use the interface identification information 16
including. The identification information 16 is generated from a definition part that defines a communication interface in RPC in the application program 21A on the server 20 that executes communication by RPC. Marshalling program 22
A and 32A perform communication in the RPC based on the definition part using the identification information 16. The RPC server system 200 and the RPC client system 300 (the server stub 222 and the client stub 332), which are upper RPC communication means, perform RPC communication based on the definition information of the RPC communication interface.

The interface identification information 16 is generated from the above defined portion of the application program 21A by the stub generator 12A as the first generation means. The marshalling programs 22A and 32A as lower RPC communication means are generated by the stub generator 12A as second generation means based on the definition part. Server stub 2 as upper RPC communication means
The 22 and the client stub 332 are generated based on the definition information (IDL) 11 of the communication interface in the RPC by the stub generator 12, which is a third generation unit, based on the definition information 11.

That is, as shown in FIG. 10, the server stub 222 in the RPC server system 200
It is generated by the stub generator 12 based on the DL 11. At this time, the hash value (1
6) is not generated. Therefore, the server stub 222 in this example does not have the identification information 16 (in this point, it is different from the example of FIG. 1). The server stub 222 and the server application 221 constitute (the load module 223 of) the RPC server system 200. Client stub 332 in RPC client system 300
The same applies to. The client stub 332 and the client application 331 constitute (the load module 333 of) the RPC client system 300.
In FIG. 10, the compiler and linker (1
7), illustration of the transmission processing units (24, 34) is omitted.

On the other hand, the marshalling program (server marshalling) 22A on the server 20 is generated by the stub generator 12A based on the interface definition section on the source code 21A 'of the server application 21A. At this time, a hash value 16 from the interface definition unit is generated. Therefore, server marshalling 2
2A has identification information 16 consisting of a hash value 16.
Similarly, the marshalling program (client marshalling) 32A on the client 30 is generated by the stub generator 12A based on the interface definition section on the source code 21A 'of the server application 21A, and the hash value 16 from the interface definition section is embedded. . Therefore, client marshalling 32
A also has identification information 16 consisting of a hash value 16.

FIG. 11 is a diagram showing an example of the interface definition section on the source code 21A 'of the server application 21A. The interface definition part on the source code 21A 'includes a parameter part shown in FIG.
(B). These are the definition information regarding the communication between the server marshalling 22A and the server application 21A.

FIG. 12 is a flowchart of the process of generating a marshalling program.

The developer creates the source code 21A 'of the server application 21A (step S31), and thereafter activates the stub generator 12A (step S3).
2). It is assumed that the RPC server system 200 and the RPC client system 300 have already been generated by processing similar to the example in FIG.

The stub generator 12A reads the source code 21A 'of the server application 21A (step S33), and calculates a hash value 16 from the interface definition section on the source code 21A' (step S3).
4).

The stub generator 12 generates the client marshalling 32A (step S35).
A hash value 16 is embedded as identification information 16 in the client marshalling 32A.

The stub generator 12A generates the server marshalling 22A (step S36). The same hash value 16 is embedded in the server marshalling 22A as the identification information 16.

The client application 33A is built (built-in) in the client 30 (step S37). That is, the client marshalling 32A is linked to the compiled (31A) of the client application by the compiler and linker (17) to obtain the load module (client RM) 33A of the client application, which is installed in the client 30.

The server application 23A is built (built-in) in the server 20 (step S38). That is, the server application 21A ′ is compiled by the compiler and the linker (17) into the server marshalling 22A.
Is linked to obtain a load module (server RM) 23A of the server application 21A ', and this is installed in the server 20.

FIG. 13 shows the RP in the client 30.
9 is a communication processing flow by C.

The client application 31A (of the client RM 33A) converts the call of the server 20 into a client marshalling 32A (of the client RM 33A).
(Step S41).

The client marshalling 32A performs transmission data creation processing (step S42). In this process, the client marshalling 32A embeds the hash value 16 at the head of the activation parameter 51 (step S43), generates the activation parameter 51 by assembling the parameters (step S44), sends this to the general-purpose interface 60, and sends it to the general-purpose interface 60. Is requested (step S45).

The requested general-purpose interface 60 is
Via the PC client system 300 and the RPC server system 200, (the server application 21 of the server 20)
Start A). This processing corresponds to step S51 in FIG. RPC client system 300 and RP
The processing between the C server systems 200 is similar to the example of FIG. When receiving a response from the server 20, the general-purpose interface 60 receives the processing result (step S4).
6). This receiving process corresponds to step S58 in FIG. Thereafter, the processing in the client 30 returns to the client application 31A via the client marshalling 32A (step S47).

FIG. 14 is a flowchart of a communication process by the RPC in the server 20.

The general-purpose interface 60 of the server 20
Client 3 via the RPC server system 200
0 is received (step S51). This processing corresponds to step S45 in FIG. The general-purpose interface 60 is a server marshalling 2 to be started.
2A is searched and selected (step S52), and the server marshalling 22A is activated (step S53).

The activated server marshalling 22A analyzes the received activation parameters 51. That is, the server marshalling 22A checks whether the received hash value 16 is equal to the hash value 16 embedded therein (step S54).

If equal, server marshalling 22A
Analyzes the parameters subsequent to the start parameter 51 (step S55), starts the server application 21A (step S56), and waits for a response. The activated server application 21A performs a predetermined process using the analyzed subsequent parameter, and returns the processing result to the server marshalling 22A. The server marshalling 22A sets the processing result from the server application 21A as a return value (return value) (step S57), and requests the general-purpose interface 60 to return.

The general-purpose interface 60 returns the result to the client 30 via the RPC server system 200 according to the request from the server marshalling 22A (step S58). This processing corresponds to step S in FIG.
Corresponding to 46.

On the other hand, the hash value 16 received in step S54 and the hash value 16
Is not equal, the server marshalling 22A
An error value is set (step S59), and a reply is requested to the general-purpose interface 60. Thereafter, step S58 is executed.

Although the present invention has been described with reference to the embodiments, the present invention can be variously modified within the scope of the gist.

For example, in the above embodiment, the identification information 16 is generated by hashing the IDL 11, but the present invention is also applicable to a program having no IDL 11, such as JAVA (registered trademark) RMI (remote method invocation). it can. In JAVARMI,
An interface definition and a stub program are generated from an application (source or object) program 18 of the server 20. Therefore, it does not have IDL11. Therefore, as shown in FIG. 15, as the definition information 11, a definition part 181 that defines an interface of RPC communication provided by the application program 18 on the server 20 that executes communication by RPC is used.
The hash value 16 is generated from the definition part 181. The stub program 15 (22, 32) is generated based on the definition part 181. This is similar to the embodiment of FIG. 10 described above.

Further, the above-described embodiment is based on the RP (in a narrow sense).
Although the case of performing inter-computer communication using C has been described, the present invention is also applicable to an object request broker (ORB), which is a technology developed from RPC. In this case, instead of the IDL 11, the identification information 16 may be generated by hashing the ODL, which is an interface definition script defining the communication interface in the ORB, as the definition information 11. That is, the present invention can be widely applied to all RPC deformation techniques. Therefore, in this specification, RPC includes an application or utilization technology of RPC such as ORB (a technology based on RPC).

(Supplementary Note 1) An RPC that includes identification information of the interface generated from definition information of a communication interface in a remote procedure call, and performs communication in the remote procedure call based on the definition information using the identification information. A network computer system comprising communication means.
(1)

(Supplementary Note 2) The network computer system according to Supplementary Note 1, wherein the identification information includes a hash value generated from the definition information.

(Supplementary note 3) The network computer system according to supplementary note 1, wherein the identification information is added to the head of the data in the communication.

(Supplementary Note 4) An RPC that includes identification information of the interface generated from definition information of a communication interface in a remote procedure call, and performs communication in the remote procedure call based on the definition information using the identification information. A client comprising communication means, wherein the RPC communication means transmits at least the identification information.

(Supplementary note 5) The supplementary note 4, wherein the definition information includes a definition part that defines a communication interface in the remote procedure call included in an application program on a server that executes communication by a remote procedure call. The mentioned client.

(Supplementary Note 6) An RPC that includes identification information of the interface generated from definition information of a communication interface in a remote procedure call, and performs communication in the remote procedure call based on the definition information using the identification information. A server comprising communication means, wherein the RPC communication means analyzes at least the received identification information. (2)

(Supplementary Note 7) The received identification information is analyzed, and if the identification information does not match the identification information of the received identification information, error information is returned to the client that is the transmission source of the received identification information. The server according to supplementary note 6.

(Supplementary Note 8) A computer readable program recording medium for storing a program for realizing a network computer system, the medium including identification information of the interface generated from definition information of a communication interface in a remote procedure call, A program recording medium storing a program for causing the network computer system to execute at least a process of transmitting the identification information in a communication process in the remote procedure call based on the definition information.

(Supplementary Note 9) A computer-readable program recording medium for storing a program for realizing a network computer system, the medium including identification information of the interface generated from definition information of a communication interface in a remote procedure call, A program recording medium storing a program for causing the network computer system to execute at least a process of analyzing the received identification information in a communication process in the remote procedure call based on the definition information.

(Supplementary Note 10) First generating means for generating identification information of the interface from the definition information of the interface of the communication in the remote procedure call, and using the identification information in the remote procedure call based on the definition information. A network computer system comprising: RPC communication means for performing communication; and second generation means for adding the identification information to the RPC communication means. (3)

(Supplementary note 11) The network computer system according to supplementary note 10, wherein the definition information comprises an interface definition script that defines a communication interface in the remote procedure call.

(Supplementary Note 12) The supplementary note 10, wherein the definition information includes a definition part that defines an interface of communication in the remote procedure call included in an application program on a server that executes communication by a remote procedure call. The network computer system as described.

(Supplementary note 13) The network computer system according to supplementary note 10, wherein the identification information comprises a hash value generated from the definition information.

(Supplementary Note 14) A computer-readable program recording medium for storing a program for realizing a network computer system, wherein a first interface information is generated from definition information of a communication interface in a remote procedure call. Generating RPC communication means for performing communication in the remote procedure call based on the definition information, and adding the identification information to the RPC communication means;
A program recording medium storing a program for causing the network computer system to execute the generation processing of the above.

(Supplementary Note 15) An application program on a server that executes communication by a remote procedure call, the application program having a definition part defining an interface of communication in the remote procedure call. Lower RPC communication means for performing communication in the remote procedure call based on the definition portion using the identification information, and in the remote procedure call based on the definition information of the communication interface in the remote procedure call. A network computer system, comprising: upper RPC communication means for performing communication. (4)

(Supplementary Note 16) From the definition part of the application program on the server which executes communication by a remote procedure call and which includes a definition part for defining an interface of communication in the remote procedure call, identification information of the interface is obtained. First generation means for generating a lower RPC communication means for performing communication in the remote procedure call based on the definition part, and second generation means for adding the identification information to the lower RPC communication means. And a third generating means for generating a higher-level RPC communication means for performing communication in the remote procedure call based on definition information of a communication interface in the remote procedure call. (5)

[0098]

As described above, according to the present invention,
In the network computer system, by generating the identification information of the interface of the RPC from the definition information of the interface itself, the definition information can be uniquely defined for the interface. Therefore, even if the interface is changed, the interface is not matched. In particular, it is possible to prevent an application program from being executed using an inappropriate return value of the RPC even though the interfaces do not match. It is possible to eliminate the burden on the developer for version management and description, and to prevent the occurrence of interface inconsistency due to human error in version management and the like.

Further, according to the present invention, in the network computer system, the identification information of the interface of the RPC is generated from the definition information of the interface itself and added to the RPC communication means for performing the communication in the RPC, so that the interface of the interface is generated. Since the management and the like can be effectively performed without burdening the developer on the management and the description of the version, it is possible to prevent the occurrence of interface inconsistency due to a human error in the management and the like. .

[Brief description of the drawings]

FIG. 1 is a configuration diagram of a network computer system.

FIG. 2 is a diagram illustrating an example of an IDL.

FIG. 3 is a diagram illustrating an example of a server stub.

FIG. 4 is a flowchart of a generation process of a stub program.

FIG. 5 is a communication processing flow by RPC in a client.

FIG. 6 is a communication processing flow by RPC in a server.

FIG. 7 is an explanatory diagram of interface version detection processing.

FIG. 8 is an explanatory diagram of interface version detection processing.

FIG. 9 is a configuration diagram of a network computer system.

FIG. 10 is a configuration diagram of a network computer system.

FIG. 11 is a diagram illustrating an example of an interface definition unit.

FIG. 12 is a flow of processing for generating a marshalling program.

FIG. 13 is a communication processing flow by RPC in a client.

FIG. 14 is a communication processing flow by RPC in the server.

FIG. 15 is an explanatory diagram of interface version detection processing.

[Explanation of symbols]

11 Definition Information or Interface Definition Script (IDL) 12 Stub Generator 15 Stub Program 16 Identification Information (Hash Value) 20 Server 21 Server Application (Application Program) 22 Server Stub (Stub Program) 30 Client 31 Client Application (Application Program) 32 Client Stub (stub program) 40 Network

Claims (5)

[Claims] An RPC communication means including identification information of the interface generated from definition information of a communication interface in a remote procedure call, and performing communication in the remote procedure call based on the definition information using the identification information. A network computer system comprising: 2. An RPC communication means including identification information of the interface generated from definition information of a communication interface in a remote procedure call, and performing communication in the remote procedure call based on the definition information using the identification information. A server, wherein the RPC communication unit analyzes at least the received identification information. 3. A first generating means for generating identification information of the interface from interface definition information of a communication in a remote procedure call, and performing communication in the remote procedure call based on the definition information using the identification information. A network computer system comprising: an RPC communication unit that performs the communication; and a second generation unit that adds the identification information to the RPC communication unit. 4. The identification information of the interface generated from the definition part of a program which is an application program on a server which executes communication by a remote procedure call and has a definition part defining an interface of communication in the remote procedure call. Lower RPC communication means for performing communication in the remote procedure call based on the definition portion using the identification information, and performing communication in the remote procedure call based on definition information of a communication interface in the remote procedure call. A network computer system comprising: an upper RPC communication unit for performing the communication. 5. The interface identification information is generated from an application program on a server that executes communication by a remote procedure call, the identification information of the interface comprising a definition part defining an interface of communication in the remote procedure call. First generating means for generating lower RPC communication means for performing communication in the remote procedure call based on the definition part, and second generating means for adding the identification information to the lower RPC communication means; A third generation means for generating a higher-level RPC communication means for performing communication in the remote procedure call based on definition information of a communication interface in the remote procedure call.