JPH10289119A - Program execution request and its result notification method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To increase an executing speed by compiling previously the name of a communication area which identifies the procedure to be requested, the procedure name and an argument only into a client program out of the interface information. SOLUTION: A client/server system comprises a server program 41 which performs a cooperative operation, a client program 42 and a client computer screen 43. The name of a communication area which identifies the procedue to be requested, the procedure name and an argument. i.e., the name of data to which the procedure name refers only are previusly compiled into a client program out of the interface information on a client and a server which request the program executions and notify these execution results to each other. Meanwhile, the attribute of the argument necessary for execution of the requested procedure is stored in a management data base 415 of the server. Then the received execution request is notified to the client from the server.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a procedure execution method for executing a procedure defined on a computer by calling only a necessary part from a program on another computer.

[0002]

2. Description of the Related Art In order to incorporate and execute a part of a program in a client / server system, it is necessary to determine in advance a procedure to be called between the client / server and data to be transferred. Various methods have been implemented for this. DCE (Dis
Tributed Computing Enviro
nment) RPC (Remote Procedure)
FIG. 8 shows a method in (Re Call). In this method, client / server interface information,
In particular, the name, type, and size of the argument to be passed to and from the procedure on the server to be called from the client are described in IDL (Int
The source information is described (hereinafter, referred to as interface information) in a source format (21 in FIG. 8) in a language called an interface design language (hereinafter referred to as interface information), compiled by an IDL compiler (22 in FIG. 8), and client stub (231 in FIG. 8). , A server stub (241 in FIG. 8) is incorporated in each execution module (23, 24 in FIG. 8) of the client server. According to this method, the above-described interface information between the client and the server is compiled in advance, so that there is an advantage that it can be executed at high speed. However, in the method using the IDL language, it is necessary to synchronize the interface information referred to by the module on the client side and the interface information referred to by the module on the server side, and the interface information is statically compiled in a state where both of them are compiled. It is necessary to incorporate the client stub 231 and the server stub 241 into the module.

FIG. 9 shows a method disclosed in Japanese Patent Application Laid-Open No. 5-289871 as a method of combining applications. In this method, an area (link management table, FIG. 3
When the client requests the server to notify the procedure calling method (313 in FIG. 9), the server registers the procedure calling method in the link management table (314 in FIG. 9). Thereafter, the client retrieves a procedure calling method from the link management table, and calls the procedure (316 in FIG. 9). In this method, the interface information between the client and the server can be dynamically searched, so that it is not necessary to be aware of the procedure call format when creating the client-side program. There is an advantage that the program on the side does not need to be changed synchronously. However, this method solves the problem of the method using the IDL language by dynamically retrieving interface information between the client and the server. However, it is necessary to separately provide an area that can be referred to by both the client and the server. ,
Since the client program dynamically determines the procedure calling method at the time of execution, the processing becomes complicated and the execution speed decreases. That is, the above-mentioned link management table entries need to be prepared for each procedure call of each client on a one-to-one basis. If there are many clients, the number of required entries increases. These entries need to be created, searched, updated, and deleted every time a procedure is called from the client.

[0004]

The conventional program execution method is configured as described above. In the first conventional example, when the interface information is changed, both the client and server modules are recompiled. There is a problem that a large amount of work is required, and that both the client and server modules need to be managed synchronously. In the second conventional example, in a use environment in which a large number of clients simultaneously call a server procedure, there is a problem that accesses are concentrated on the link management table and the effective speed is reduced.

SUMMARY OF THE INVENTION The present invention has been made to solve the above-mentioned problems, and eliminates the synchronous management of a client program and a server program, thereby reducing the complexity of management and improving the execution speed. The purpose is to obtain.

[0006]

According to the present invention, there is provided a method for requesting execution of a program and a method for notifying a result of the program. A name notification step of transmitting a procedure name equivalent to identify a procedure to be performed and determining the requested procedure, and an attribute notification step of transmitting a list of argument names and attributes corresponding to the determined procedure name from the server to the client as configuration information And the client extracts the names and attributes of predetermined arguments necessary for the procedure determined from the various function objects, and collects the extracted argument names and attributes to correspond to the procedure name determined from the client to the server. Argument data transmission step to send The result of executing a predetermined process based on the data of the transmitted parameter data transmitting step from the cement and a result returned sending back from the server to the client.

In the server, a plurality of procedures are collected and identified by a communication area name. In a name notification step transmitted from a client, the procedure is notified by a communication area name, and in an attribute notification step transmitted from the server, a communication step is performed. An attribute notification step for transmitting the names of a plurality of procedures corresponding to the area name as configuration information as a list, and the client selects a desired procedure from the list transmitted in the attribute notification step, and an argument corresponding to the selected procedure Is extracted from the functional object and transmitted from the client in the argument data transmitting step. The extracted argument corresponding to the name of the selected procedure is collected and transmitted.

[0008]

BEST MODE FOR CARRYING OUT THE INVENTION

Embodiment 1 FIG. In the present embodiment, the name of the communication area for identifying the requested procedure, the procedure name, and the name of the data referred to by the procedure name are included in the interface information between the client and the server for notifying the request of the execution of the program (procedure) and the result. Is compiled into the client program in advance, and the attributes of the arguments required for the execution of the requested procedure are stored in the management database on the server. Take a configuration to notify. In addition, a table for managing interface information is provided on the client side by combining the communication area name, the procedure name, the argument name and the attribute notified from the server, and the client program refers to the table to determine the procedure name and the procedure name. Send attributes and arguments to the server. The procedure on the server invokes the procedure according to the notified argument. Further, it associates actual arguments obtained by referring to a plurality of object parts constituting the client-side program with arguments referred to by the procedure. The client-side program is, for example, Windows 9
5 under an operating system (hereinafter abbreviated as OS) using an existing object-oriented visual development language. Therefore, the operation of the client program basically follows these frameworks. An object-oriented visual development language is characterized in that a program is created by selecting and combining object parts (software components having the properties of objects in the object-oriented manner).

Hereinafter, the properties of the object parts will be described. Each object component has a name for identifying each object, and the same type of object component incorporated in the client program is identified by the name. When the client program is started, the initial processing of each object component constituting the client program is started at the same time. Some object parts automatically display the screen of the client computer during operation. Generally, display on the screen is performed in the above-described initial processing. For example, when a program is started, a button object is a "button" that can be clicked on the screen with a mouse
Is displayed. Each object component can transmit and receive a message (which occurs in response to an event, and the source is the OS, the object component, etc.), and performs processing corresponding to the type of message. These processes are defined in advance in the object part as a program. The properties of object parts can be defined by "attributes". Taking the above-mentioned button object as an example, the color of “button” can be defined as “attribute”. For example, "button color"
If it is defined as "red", a red button is displayed on the screen. "Attributes include static definitions that are created during program development and dynamic definitions that can be changed at runtime. The movement of the entire program and the linkage between object parts can be described in a scripting language. A description is given of such a process that the process of the object component is started. Object parts can be created independently, and in the present invention also, the client program uses the independently created object parts.

According to the above-described configuration and method, of the interface information between the client and the server, only the name of the communication area for identifying the requested procedure, the procedure name and the arguments are compiled and incorporated in the client program in advance, Other information is requested from the server in the initial processing of the client program at the time of execution, the name and attribute of each corresponding actual argument are received from the server as additional information, and an interface on the memory of the client created in advance Since the method of recording the information is used, the process of calling the server procedure when executing the program is simple. Further, since the notification of the interface information is performed by communication between the client and the server, an area commonly referred to by both the client and the server is not required. Furthermore, since the above processing is performed only once in the initial processing,
The execution speed of the repeated server procedure call is not reduced. Since the interface information between the client and the server that is statically compiled is only the name of the communication area for identification, the procedure name, and the arguments, even if other interface information is changed due to the change of the server program, the client side There is no need to change the module synchronously, and the recompile scale is small and easy to manage.

The above concept will be described with reference to the drawings based on a specific process for retrieving data from a database existing on a server. For simplicity of description, a case will be described in which only one procedure is assumed for the communication area name. FIG. 1 is an operation flowchart showing a method of executing a program in a client / server system according to the present embodiment. The client program cooperates with the server program. In the figure, reference numeral 11 denotes a flow of the client program 42, and reference numeral 12 denotes a flow of the server program 41. FIG. 2 is a diagram showing the configuration of the server program 41 and the client program 42. In FIG. 2, as an example, the server-side database “ZAIKODATA” 415 is searched by the search key: product code “CODE” input in the input field 431 of the screen 43 of the client computer, and the result is displayed on the screen of the client computer. 43 shows a configuration in a case where the prices are displayed in the display fields of the price “PRICE” and the stock quantity “ZNUM”. In this example, the client program 42 is the server communication object 4
21, input object 425, display object 1
(426), a display object 2 (427), and a button object 428. These are the object parts described above. By increasing the number of object parts constituting the client program 42, a more complicated screen can be displayed.

The client program 42 stores a client-side communication area 422 used as a data area for communication with the server program 41, a "pointer for identifying the communication area" 423, and a communication area management table 424 indicating the configuration of the communication area. Have. The communication area management table 424 includes “field name” as an argument name, “data type” indicating the attribute of the argument, “size”, and “displacement”. The server-side program 41 is a database 4 indicating the configuration of a communication area exchanged between the client and the server.
12, a server communication area 413 used for communication between the server main program 411 and the client program 42,
It is composed of a procedure program 414 called and executed from the client side.

In FIG. 1, a process (step) 111,
112, 113 and 114 are server communication objects 42
1 is an initial process. Processing 125 is processing corresponding to these on the server side, and is performed by the server main program 411. The processing 115 includes the input object 425 and the display object 1 (42
6) Initial processing of the display object 2 (427) and the button object 428. When the initial processing of each object is completed, the client program enters a state 116 of waiting for a message as a processing request from the OS. Thereafter, the client program performs processing according to the type of the message. Processing 119 is processing of an input message of “keyboard input complete”, processing 120 is processing of an update message of “screen display update”, and processing 121 is processing of an activation message of “button click”. As a part of these processes, the attribute of the argument corresponding to the name of the argument is extracted and stored in the client communication area 422 as information 429. Processes 122, 123, and 124 are executed by the server communication object 42 activated by the button object.
This is the first process. The communication area information 423, 424, and 429 including the arguments extracted in the process 122 are sent to the server. The processes 122, 123 on the client side correspond to the processes 126, 127, 128, 129 on the server side. Of these, processing (steps) 126, 127, 129
Is performed by the server main program 411, and the processing 128 is performed by the procedure program 414.

FIG. 3 is a diagram showing in detail a part of the database 412 showing the configuration of the above-mentioned communication area on the server side. The database 51 indicating the configuration of the communication area includes a display 511 storing the communication area name, a table 512 storing information on fields forming the communication area, and a file area 52 storing the procedure program. The display 511 storing the communication area name is a display 512 storing the name of the communication area, the name of the procedure performed by the related server requested by the client, and the names (argument names and attributes) constituting the communication area.
Let the pointer to be an entry. A plurality of tables 512 storing argument names and attributes constituting communication areas are defined corresponding to each entry of the table 511 storing communication area names. The file area 52 stores files 521 to 522 that store procedures executed in response to a request from a client. The file area 52 contains all procedures defined on the server as files, but is omitted in FIG. A display 5 storing the communication area, that is, the argument names and attributes constituting the procedure for receiving the execution request.
Numeral 12 designates a field name as an argument name, a data type and a data size as attributes thereof, and a position (displacement) of each field in the communication area as an entry. In this embodiment, the communication area name “ZAIKOINF” and the procedure name “ZAIKOPROO” are stored in the table 511, and the field “C” is stored in the table 512.
"ODE", "PRICE", and "ZNUM" are defined. In the file area 52, the procedure program "ZAI
KOPRO ”is stored.

FIG. 4 shows the details of the configuration of the data area 422 for storing the extracted arguments on the client side, the pointer 423 for identifying the communication area, and the communication area management table 424. From the pointer 423 for identifying the communication area, that is, the procedure, the communication area management table 424 indicating the configuration of the communication area and the client communication area 422 are pointed. The communication area management table 424 includes a field name, a data type, a data size, and a position (displacement) of this field in the communication area 422. In this embodiment, when the initial processing (111 to 114) of the server communication object in FIG. 1 is completed, the communication area, that is, the pointer 423 for identifying the procedure, has “ZAIKOINF” as the communication area name and the communication area management table. Information of each entry of “CODE”, “PRICE”, and “ZNUM” is stored in the attribute column 424.

Next, the operation will be described mainly with reference to FIGS. When the client-side program is started, each object constituting the client program of FIG. 2 is loaded on the client computer, and the initial processing of each object is executed. In the server communication object 421 in FIG. 2, first, the process (step) 111 in FIG. 1 is executed. Server communication object 42
1 transmits a communication area name "ZAIKOINF" for identifying a requested procedure to the server in this case according to the defined "attribute". When the server receives the transmission data from the client, a process (step) 125 is executed. In the process 125, the database 412 indicating the configuration of the communication area shown in FIG. 3 is stored in the communication area name "ZAIKOINF".
To obtain the configuration information of the display 512 (the field name, which is the name of the argument, the data type, size, and the position (displacement) in the communication area), which are the attributes, and transmit it to the client. The server communication object 421 of the client receives the configuration information of the communication area transmitted from the server (process 112), and the pointer 423 for identifying the communication area shown in FIG. 2 and the area for the communication area management table 424. In the memory. The pointer to the communication area management table 424 is stored in the pointer 423 for identifying the communication area. Further, the communication area management table 424 stores “CODE”, “PRIC” according to the data received from the server.
The information of each entry of "E" and "ZNUM" is stored (step 113). Next, the size of the client-side communication area 422 is obtained, a memory is acquired, and a pointer to the client-side communication area 422 is stored in the field of the pointer 423 for identifying the communication area (step 114).

In a process 115, as an initial process of the input object 425 other than the server communication object constituting the client program, the display object 1 (426), the display object 2 (427), and the button object 428, a screen 43 of the client computer is displayed.
As shown in FIG. 2, an input field 431, display fields 432 and 433, and a button 434 for instructing "execute" are displayed. After the above-described initial processing of each object component is completed, the client program enters a standby state (process 116) waiting for a message from the OS.

Next, a process of searching a database on a server based on a product code input from a client to search for a price and a stock quantity of a product and displaying the price on a screen of a client computer will be described step by step. The operator
When a product code (for example, “MMNN3456”) serving as a search key is input to the input field 431, the OS
A message "keyboard input complete" is transmitted to the client program. When this message is transmitted to the input object, the input object refers to the communication area management table 424 pointed by the pointer 423 for identifying the communication area, and enters the argument name “CODE” defined in its “attribute”. The position of the corresponding client-side communication area 422 is obtained, and the input value is stored in the position as an argument (in this example, "MMNN3456" and step 119). When the operator clicks an “execute” button 434 on the screen of the client computer, the OS
Transmits a message "button click" to the client program. When this message is transmitted to the button object 428, the button object 428 executes the defined “script”: “start processing of the server communication object”. This activates the process (step) 122 of the server communication object 421.
The server communication object has a communication area name “ZAIKOINF” defined in its “attribute” and a procedure name “ZAKOINF”.
IKOPRO ”and the argument data collected and extracted in the client side communication area 422 are transmitted to the server (process 122).

After acquiring the memory for the server-side communication area 413, the server main program 411 stores the argument data in the client-side communication area 422 received from the client (step 126). Next, according to the procedure name "ZAIKOPRO" specified by the client,
From the file area 52 in FIG. 3, the procedure "ZAIKOPR"
The file 521 describing “O” is read into the memory,
Activate the procedure “ZAIKOPRO” 414 (Process 1
27). The procedure “ZAIKOPRO” 414 is a “COD” that is a search key among the contents of the server-side communication area 413.
The product code: "MMNN3456" which is an actual search key is obtained by referring to the field "E". Next, the database “ZAIKODATA” is searched and the price “PRIC” is searched.
E "and the value of the stock quantity" ZNUM "(" 12580 "and" 350 ", respectively). Procedure "ZAIKOPRO" 41
4 stores these values in the “PRIC” of the server-side communication area 413.
The processing is terminated after storing in the fields "E" and "ZNUM" (step 128). Next, the server main program 411 sends the contents of the server-side communication area 413 to the client (processing or step 129). The server communication object 421 on the client side has a server communication area 413.
Is received and stored in the client-side communication area 422 (process 123). Next, the server communication object 42
1 instructs the OS to redraw the screen of the client computer (process 124). The OS issues a “screen display update” message for redrawing. When this message is transmitted to the display object, each of the display objects 1 and 2 refers to the communication area management table 424 pointed by the pointer 423 for identifying the communication area, and the field name defined in its own “attribute” Client-side communication area 422 corresponding to "PRICE" and "ZNUM"
Is obtained, and a value is obtained and displayed in the "price" field and the "stock quantity" field on the screen of the client computer (process 120). In this example, “12580” and “350” which are the respective values on the screen are displayed.

When the operator repeats inputting a value into an input field on the screen of the client computer and pressing an "execute" button, the client program repeatedly executes the processing described above. As a result, the procedure on the server is executed each time, and the price and the stock quantity corresponding to the input value of the product code each time are retrieved from the database on the server and displayed on the screen. As a result of the initial processing (the processing from 111 to 114 in FIG. 1), all the interface information necessary for executing the client program has been created in the memory, and these are sent to the server in the processing 122 in a lump. Even in the repetitive processing, the effective speed does not decrease due to the interface information search. In general, a business program for searching a database on a server as in the above-described example often requires high performance in terms of the number of processes per time, and the “application combining method” described in the prior art is disclosed in Japanese Patent Laid-Open No. 5-289.
871 ", a method of referring to a link management table accessible from both the server and the client each time a procedure is called cannot meet a high performance requirement. As described above, the configuration of the communication area on the server is Even if the database 412 shown is changed, the client program is notified of the changed configuration of the communication area at the time of execution, so that it is not necessary to recompile the client program. If the "size" of "CODE" is changed,
The "position in the communication area" after "PRICE" is changed, but these changes are notified to the client side at the time of execution, and the input object, the display objects 1 and 2 refer to the corresponding field in the changed position information. can do.

Embodiment 2 FIG. In the first embodiment, only one type of procedure is called from the client program. However, since the procedure name is an “attribute” of the server communication object, its type can be dynamically changed at the time of execution depending on the properties of the object component.
For example, in the above embodiment, the price “PRICE”
Instead of the purchase price of the same product is "IPRICE"
Is registered in the database on the server as the other procedure program "ZAI" that operates on the server.
KO-IN ”, which can be activated by the purchase price“ I ”instead of the price“ PRICE ”.
If "PRICE" is retrieved from the database and transmitted to the client program, "purchase price" can be displayed instead of "price" on the screen of the client computer. FIG. 5 shows a configuration of the client program and the server program in the present embodiment. FIG.
5 has the same configuration as that of the pointer 423 for identifying the communication area and the configuration of the communication area management table 424 by adding a list 429 of procedure names that can be called from the client program as shown in FIG. It is possible to select and call a plurality of types of procedures that use the communication area of. FIG. 7 shows a configuration of the database 412 indicating the configuration of the communication area on the server side, which is changed in accordance with the present embodiment. A table 53 showing a list of procedures that can be called on the server is added to the database 51 in the above embodiment. In the table 53, the names of procedures that can be called corresponding to specific communication area names are registered. The registered procedure program is stored in the file area 52. Then, the field storing the procedure name in the table 511 storing the communication area name is changed to a pointer to the table 53. In the present embodiment, the communication area name [ZAIKOIN
F ”,“ ZAIKOPRO ”,
"ZAIKO-IN" is defined.

The operation in the present embodiment will be described with reference to the flow of FIG. In the initial processing of the server communication object, a list of procedure names that can be started on the server is added to the data received from the server for the communication area name “ZAIKOINF”. This data is retrieved from the display 53 of the database (412 in FIG. 5) indicating the configuration of the extended communication area shown in FIG. Further, in process 113, a table 429 showing a list of procedure names is additionally created on the memory of the client. Other initial processing is the same as in the first embodiment. Operator is "price"
When the “purchase price” is retrieved from the database of the server instead of “”, the “procedure name”, which is the attribute of the server communication object, is rewritten in advance to “ZAIKO-IN”. In this state, when a value is entered in the input field on the screen of the client computer and the "button" is clicked, the client program operates as described in the first embodiment, and the server-side procedure "ZAIKO-I"
N ". This program is price "PRICE"
Instead, the purchase price "IPTRICE" is retrieved from the database, and the purchase price is displayed in the "price" field on the screen of the client computer.
As described above, according to the present embodiment, it is possible to easily select a procedure to be executed on the server by designating the client program at the time of execution. Also, in this case, the part of the initial processing related to the execution of the client program is common regardless of the selection of the procedure,
It is not necessary to make an inquiry to the server for each calling procedure and create an entry in the link management table.

[0023]

As described above, according to the present invention, there is no need to provide a special area that can be referred to by both the client and the server for dynamic interface information retrieval. Further, the dynamic interface information search process only needs to be performed at the time of the initial process, and the effective speed required for the interface information search process does not decrease in the second and subsequent repetitive processes. Since there is no need to synchronize and recompile the client program by changing the server program, there is an effect that the management of the client program can be easily performed.

Further, there is an effect that the procedure to be executed on the server can be easily selected in the client program.

[Brief description of the drawings]

FIG. 1 is a flowchart illustrating a processing procedure of a client program and a server program according to Embodiment 1 of the present invention.

FIG. 2 is a diagram showing a configuration example of a client / server system according to the first embodiment.

FIG. 3 is a diagram showing a configuration of a database storing configuration information of a communication area existing on a server side in FIG. 2;

FIG. 4 is a diagram showing a configuration of a data area created on the client side in FIG. 2;

FIG. 5 is a diagram showing a configuration example of a client / server system according to a second embodiment of the present invention.

FIG. 6 is a flowchart illustrating a processing procedure of a client program and a server program according to the second embodiment of the present invention.

FIG. 7 is a diagram showing a configuration of a database storing configuration information of a communication area existing on the server side in FIG. 5;

FIG. 8 is a diagram illustrating a conventional IDL.

FIG. 9 is a diagram illustrating a processing operation in a conventional application combination method.

[Explanation of symbols]

11 Client program flow, 12 Server program flow, 111, 112, 113, 11
5,116 Initial processing of client program, 11
7, 118 Message determination processing of client program, 119, 120, 121, 122, 123, 12
4 Processing of Object Parts of Client Program, 125 Initial Processing of Server Program, 126, 1
27, 128, 129 Processing of server program, 21
IDL source, 22 IDL compiler, 23 client program, 24 server program, 31
Client processing flow, 32 server processing flow, 3
3 link management table, 311, 312, 313, 3
15 Client program processing, 314, 316 server program processing, 41 Configuration of server-side program, 412 Database indicating configuration of communication area, 41
1 server main program, 413 server side communication area,
414 Procedure started by client 415
Server-side database, 42 client program configuration, 421 server communication object, 422 client-side communication area, 423, 424, 429 communication area configuration information, 425 input object, 426,
427 display object, 428 button object, 43 client computer screen, 431,
432, 433, 434 display of each object part,
51 Database indicating the configuration of the communication area, 511 Table of communication area names, 512 Table of fields forming the communication area, 52 File area for storing procedures, 521
522 procedure program file, 53 procedure name list table.

Claims (2)

[Claims] In a system comprising a server receiving a procedure execution request and a client requesting the above procedure, a procedure of transmitting a procedure name corresponding to the above procedure for requesting a process from the client to the server and requesting the server is described. A name notification step for determining, an attribute notification step for transmitting a list of argument names and attributes corresponding to the determined procedure name from the server to the client as configuration information, and a client required for the determined procedure from various functional objects. An extracting step of extracting the names and attributes of the predetermined arguments; an argument data transmitting step of collecting the extracted names and attributes of the arguments and transmitting from the client to the server in accordance with the determined procedure name; The procedure of the argument data transmission step Request a result notification method of a program execution, characterized in that a result return step of returning a client from the server a result of executing a predetermined process based on. 2. A server collects a plurality of procedures and identifies them by a communication area name. In a name notification step transmitted from a client, the server notifies the communication area name, and in an attribute notification step transmitted from the server, the communication step includes: An attribute notification step in which the names of a plurality of procedures corresponding to the area name are transmitted as configuration information as a list. The client selects a desired procedure from the list transmitted in the attribute notification step, and responds to the selected procedure. The argument data transmitting step of extracting an argument to be performed from the function object and transmitting from the client is an argument data transmitting step of collecting and transmitting the extracted arguments corresponding to the name of the selected procedure. Item 1. The program execution request and the result notification method according to item 1.