JPH04107741A - Draw-out system for service procedure in rpc - Google Patents

Abstract

PURPOSE:To enable a service procedure to be added by preparing a data base representing the correspondence of the new routine of the service procedure in a program at RPC(Remote Procedure Call) server side, and another program which executes actual service. CONSTITUTION:Firstly, it is judged whether or not the correspondence of a requested program procedure exsits in a service procedure definition file, and when no definition file exists, or no correspondence of the requested program procedure exists in the definition file, a result of 'no such procedure' is repeated, and no service for a designated procedure is executed. On the contrary, when the definition file exists, or the correspondence of the requested service procedure exists in the definition file, the program designated by execpath in the definition executes actual processing for the service procedure. In such a way, it is possible to execute the addition of the service procedure on the program at existing RPC server side without re-gener-ating a module.

Description

[Detailed Description of the Invention] [Industrial Application Field] This invention is based on RPC (Remote Proceeding)
In a computer with re Ca1l) function, R
This topic relates to program creation using a PC and subsequent program improvement.

[Conventional technology]

RPC programs are broadly divided into client and server programs.

The server-side engineering program registers its own program number in a port map, a program that has information about the RPC server program, and assigns multiple procedure numbers (service procedures) to one program number. have.

On the other hand, the program on the client side specifies the program number of the server for which it wants to receive service, queries the above port map for the program number, and if it turns out that the specified program exists, it also sends a request for the program number. Specify the procedure and output the service request.

Each service procedure on the server side must describe the processing for executing the actual service in response to a service request from the target side program.

With current RPC, in order to add a new service using RPC, it is necessary to create a new program on the server side. This is because each service procedure must already be incorporated into the program when the server-side program is created.

Also, in order to create a new program on the server side and register it in the port map, the program must be running at all times.

[Problem to be solved by the invention]

In the traditional RPC mechanism, as mentioned above, adding a service procedure always means creating a new server-side program, and registering for a port map requires the server-side program to be running, so it is more complicated. memory and may reduce the processing power of the host computer.

The present invention was made to solve the above-mentioned problems, and it is an object of the present invention to add a service procedure to an existing RPC server without having to recreate (recompile) a module.

In other words, in RPC, which has already become a standard function mainly on workstations, it is possible to add service procedures later, in addition to the current method of storing each program's own service procedures inside the load module. It is.

[Means to solve the problem]

In addition to the current standard RPC functions, the service procedure outgoing method in RPC according to the present invention includes a new routine for service requests built into the program in the RPC server side program, and support for the necessary program number, procedure number, etc. Additional service procedures can be referenced by using a database that represents the service procedure and a separate program that executes the actual service.

[For production]

The service procedure outgoing method in RPC in this invention is such that the RPC
Improve modularity on the C server side.

〔Example〕

An embodiment of the present invention will be described below with reference to the drawings.

In FIG. 1, 101 is an excerpt of the part of the RPC server side program that executes processing for each service procedure, 102 is a definition file of the RPC service procedure that can be accessed for each RPC program, and 103 is an RPC This is the part that executes the actual service request.

Now, considering the current RPC server side program, at 1-01 in Figure 1, "default
:'' processing results always existed only in the case of "else" shown in the figure.

In case 2, if the service procedure does not correspond to each "case" statement in the figure, "no. 5" is required.
uch procedure'.

Therefore, the process 104 (additional program to the RPC server program) shown in FIG. 1 is added to the RPC server side program, and a mechanism is provided that makes it possible to add any RPC service procedure.

The processing required at 104 in FIG. 1 is shown in the flowchart of FIG.

This process is executed when the requested service procedure does not exist in the RPC server side program.

First, the service procedure definition file is referenced (function getrpcprocent()). In other words, it is determined whether or not there is a correspondence for the requested program procedure in the definition file (step 5201);
If there is no definition file, or if there is no correspondence to the requested program procedure in the definition file, the result of "no 5uch procedure" is repeated and the service for the specified procedure is not executed (step 5202). If there is a definition file, or if there is a correspondence for the requested program procedure in the definition file, then the program specified by execpath in the definition file is
Execute processing for the actual service procedure.

At this time, the RPC server side program entrusts the processing to the child process, and waits until it receives the results obtained by the child process (steps 3203 to 3203).
Step 5206).

Although the type of data received as a result differs depending on each service, the data type can be guaranteed by describing the type in the definition file.

In this state, the RPC server side program that received the result of the child process was able to confirm that it had finished processing the service procedure, so it performed the same function as the other "case" statements in Figure 1. It turns out.

On the other hand, FIG. 3 shows a flowchart of a program that is started by the RPC server side program and executes processing for an actual service procedure.

Here, the argument is interpreted based on the argument type ("argutype" in Figure 1) obtained from the definition file (step S301), and the process for the requested service procedure is executed using the interpreted argument (step S301).
Step 5302) L. Create result data to be returned to the RPC server side program according to the type of result obtained from the definition file (resulttype in Figure 1).Step 5303) The process of using the RPC server and transferring the data to the RPC server side program is executed (step 5304).

In addition, in the above embodiment, the process was explained as being confined only within the RPC server machine, similar to the conventional RPC server side program, but adding the host name to the format of the service procedure definition file and the process By using a network-accessible means as a means of intercommunication, it can also be used as a network-transparent function.

[Effects of the Invention] As described above, according to the present invention, it is possible to add any service procedure to one RPC server side program, so it is possible to easily add a service procedure, and it is also easy to develop software. This has the effect of facilitating maintenance.

[Brief explanation of drawings]

FIG. 1 is an explanatory diagram showing the configuration of programs and files necessary on the RPC server side according to an embodiment of the present invention, and FIG.
FIG. 1 is a flowchart showing the processing operations necessary for the present invention in FIG. 1, and FIG. 3 is a flowchart showing the processing operations necessary for service procedures that can be added to each RPC service. In the figure, 101-RPC server side program 10:l”--Service procedure definition file 10
3-Service Execution 104-RPC This is an additional program for the C server side program. In each figure, the same reference numerals indicate the same or equivalent parts.

Claims (1)

[Claims] R consisting of a client program and a server program
A PC (Remote Procedure Call) program includes: a routine for a service request built into the server program; a program number necessary to execute the routine;
A method for accessing a service procedure in RPC, characterized in that it is possible to refer to additional service procedures by using a database that shows the correspondence of procedure numbers, etc., and a separate program that executes the actual service.