JP2005071340A - Method used in client-server distributed system, server and client - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To reduce a turnaround time from a time point of a start of server function calling of a client to server processing completion notification, in synchronous communication of a client-server distributed data system. <P>SOLUTION: A server has: a preprocess registration part 101 registering a preprocess; a post-process registration part 102 registering a post-process; a server instruction part 100 requiring the registration of the preprocess and the post-process; and a server function correlation part 103 correlating the preprocess and the post-process to a server function identifier. When the server 10b receives a requirement message for the server function calling from the client, the server 10b executes the preprocess, transmits a completion message including an execution result of the preprocess to the client 10a, and executes the post-process after transmitting the completion message. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

  The present invention relates to a method, a server, and a client used in a client-server distributed system that performs synchronous communication. More specifically, the server function ends when the client starts calling the server function to the server. The present invention relates to a method, a server, and a client for shortening a turnaround time until a notification of the return.

  In conventional synchronous communication related to a client-server distributed system using an information processing terminal such as a computer, a client calls a server function to the server. The server executes the process of the called server function, and when the process is completed, returns a message indicating completion to the client.

  FIG. 13 is a sequence diagram showing the flow of processing between the server and the client in such a conventional synchronous communication method. In FIG. 13, the timing at which the processing operation can be performed by the client is indicated by hatching. The client calls a server function for the server. The client cannot perform processing until the server notifies that the execution of the server function has been completed. As described above, the time from when the client calls the server function until the completion of the server function is notified is referred to as turnaround time. Since the client cannot perform processing during the turnaround time, a technique for shortening the turnaround time, that is, a technique for shortening the waiting state at the client has been proposed (for example, see Patent Document 1).

  FIG. 14 is a sequence diagram showing a flow of a conventional synchronous communication method described in Patent Document 1. In FIG. 14, the client includes a client command unit for executing processing on the client side to call a server function, and a communication control unit for performing communication with the server. When it becomes necessary to call the server function, the client command unit requests the communication control unit to call the server function. In response to this, the communication control unit immediately returns a completion notification indicating that the server function call has failed to the client command unit. At that time, the communication control unit transmits a request message for requesting execution of the server function to the server by asynchronous communication. The server that has received the request message executes processing of the requested server function. When the server function processing is completed, the server transmits an end message to the client. The communication control unit of the client holds the content of the end message transmitted from the server. When a call to the server function is requested again from the client command unit, the communication control unit notifies the client command unit of completion of the server function based on the content of the held end message.

As described above, when the synchronous communication method described in Patent Document 1 is used, the turnaround time of the client can be shortened.
JP 9-330287 A

  However, in the above-described conventional synchronous communication method, the communication control unit immediately returns a completion notification that the execution of the server function has failed to the client command unit, so that the turnaround time in the client is shortened, When the server function completion notification is returned to the client command unit, the actual server function is not called. Accordingly, there has been a problem that the server function call processing result cannot be confirmed unless the server command is called at least twice by the client command unit.

  In addition, since the timing of completion of server function processing is unknown, the client may execute a second server function call before receiving an end message from the server, causing unnecessary processing. There was a problem to do.

  Therefore, the object of the present invention is that when the server function is executed by the server, the server function is terminated from the time when the server function is started without being called by the client a plurality of times. The synchronous communication method, server, and client of a client-server system that can shorten the turnaround period until receiving the notification of the above.

  In order to solve the above problems, the present invention has the following features. The present invention is a method used in a client-server distributed system in which a client calls a desired server function to a server and the server executes a process corresponding to the called server function, and the process corresponding to the server function And a part of the process corresponding to the server function, which should be executed after the pre-process. A step of registering the process as a post-process, a registered pre-process, a registered post-process, and a step of associating a server function identifier indicating a server function.

  As a result, processing corresponding to the server function is divided into pre-processing and post-processing.

  Preferably, the client further sends a request message including a server function identifier indicating the desired server function to the server in order to request a call to the desired server function, and the server transmits from the client. Receiving the received request message, the server executing the preprocessing associated with the server function identifier included in the request message, the server obtaining the execution result of the preprocessing, and the obtained A step in which the server sends an end message including the execution result of the process to the client; a step in which the server executes post-processing associated with the server function identifier included in the request message after sending the end message; Based on the execution result of the preprocessing by the client that received the termination message It may comprise a step of executing the treatment.

  As a result, an end message is returned to the client at the timing when the preprocessing is executed. Since the minimum necessary information is obtained by the preprocessing, the client can continue the processing after receiving the end message. Therefore, the turnaround time is shortened. Further, since the server executes post-processing after pre-processing, a desired server function is called.

  Preferably, the server further obtains a post-processing execution result, a step in which the server sends a post-processing result message including the post-processing execution result to the client, and a client that has received the post-processing result message performs post-processing. And a step of executing a process based on the execution result.

  As a result, the execution result of the post-processing is notified to the client, so that the client can execute a desired process based on the execution result of the post-processing.

  Preferably, in addition, when there is a cancel instruction for canceling the server function call, the client registers in advance a condition for determining whether to cancel the server function call based on the cancel instruction. And a step for the client to determine whether or not to cancel the server function call according to the cancel instruction when there is a cancel instruction, and a step for the client to cancel the server function call when determined to cancel. Good.

  Accordingly, the server function call can be canceled, so that the turnaround time when an unnecessary server function call is made can be shortened.

  Further, the present invention is a server for executing a server function called from a client, and is a part of processing corresponding to the server function until obtaining minimum information required by the client A pre-processing registration unit for registering as a pre-processing, a post-processing registration unit for registering a process to be executed after the pre-processing as a post-processing, which is a part of the processing corresponding to the server function, A server function associating unit that associates a process, a registered post-process, and a server function identifier indicating a server function.

  Preferably, further, a receiving unit that receives a request message including a server function identifier indicating a server function desired by the client from the client, and a preprocessing associated with the server function identifier included in the request message, Included in the request message after transmitting the end message, the preprocessing execution unit that outputs the execution result, the transmission unit that transmits the end message including the execution result of the preprocessing output by the preprocessing execution unit to the client It is good to provide the post-process execution part which performs the post-process matched with the server function identifier.

  Preferably, the post-processing execution unit outputs a post-processing execution result, and the transmission unit transmits a post-processing result message including the post-processing execution result output by the post-processing execution unit to the client.

  The present invention is also a client for calling a desired server function to a server, and a request including a server function identifier indicating the desired server function in order to request a call for the desired server function. A transmission unit that transmits a message to the server, a reception unit that receives an end message including the execution result of the preprocessing server associated with the server function identifier included in the request message, and the reception unit The server function identifier indicating the server function is a part of the process corresponding to the server function and is the minimum required by the client. The process up to obtaining the information is associated as a preprocess, and is a part of the process corresponding to the server function, after the preprocess Process to be executed is associated with a post-treatment.

  Preferably, the server transmits a post-processing result message including an execution result of the post-processing to the client, the receiving unit receives the post-processing result message transmitted from the server, and the control unit receives the post-processing result message. Processing based on the execution result of the post-processing included in the processing result message may be executed.

  Preferably, in addition, when there is a cancel instruction for canceling the server function call, a cancel condition in which a condition for determining whether to cancel the server function call based on the cancel instruction is registered in advance. When a cancel instruction is issued, the control unit determines whether to cancel the server function call based on the conditions registered in the cancel condition registration unit. Cancel the function call.

  Thus, according to the present invention, the processing corresponding to the server function is divided into preprocessing and postprocessing, and an end message is returned to the client at the timing when the preprocessing is executed. . Since the minimum necessary information is obtained by the preprocessing, the client can continue the processing after receiving the end message. Therefore, the turnaround time is shortened. Further, since the server executes post-processing after pre-processing, a desired server function is called.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

(First embodiment)
FIG. 1 is a block diagram showing an example of the configuration of a client server type system according to the first embodiment of the present invention.

  In FIG. 1, the client server type system includes a client 10a and a server 10b. The client 10a and the server 10b can communicate with each other. Here, a client server system is shown in which a client 10a calls a server function to be executed on the server 10b by synchronous communication to the server 10b.

  If the client 10a and the server 10b are separate devices, the client 10a and the server 10b are, for example, wireless communication by wireless such as Bluetooth, wireless LAN, and infrared, or ISDN, ADSL, serial cable, Communicate with each other by wired communication such as parallel cable. When the client 10a and the server 10b are provided in the same device, the client 10a and the server 10b communicate on processes, tasks, and threads. In FIG. 1, the number of clients 10a and the number of servers 10b is one, but there may be a plurality of clients 10a or a plurality of servers 10b.

  The client 10 a includes a client command unit 104 and a communication control unit 112. The client command unit 104 executes a client-side process and calls a server function according to the process. The communication control unit 112 controls communication between the client command unit 104 and the server 10b.

  The communication control unit 112 includes a synchronous communication unit 105, an asynchronous communication transmission unit 106, and an asynchronous communication reception unit 111. The synchronous communication unit 105 receives the server function call from the client command unit 104 through synchronous communication, and notifies the asynchronous communication transmission unit 106 of the server function call request. The synchronous communication unit 105 receives the end message from the server sent from the asynchronous communication receiving unit 111 and notifies the client command unit 104 of the end of the server function. The asynchronous communication transmission unit 106 receives the call request from the synchronous communication unit 105 and transmits a request message to the server by asynchronous communication. The asynchronous communication receiving unit 111 receives an end message from the server and notifies the synchronous communication unit 105 of completion.

  The server 10b includes a server command unit 100, a preprocessing registration unit 101, a postprocessing registration unit 102, a server function association unit 103, an asynchronous communication reception unit 107, a preprocessing execution unit 108, and an asynchronous communication transmission unit. 109 and a post-processing execution unit 110.

  The preprocessing registration unit 101 registers preprocessing. Here, the pre-processing is a part of processing corresponding to the server function called from the client 10a and means processing until obtaining minimum information necessary for the client 10a. The server 10b transmits the execution result of the preprocessing to the client 10a before executing processing after the preprocessing (postprocessing described later).

  The post-processing registration unit 102 registers post-processing. Here, the post-processing is a part of processing corresponding to the server function called from the client 10a, and is processing to be executed after the server 10b transmits the execution result of the pre-processing to the client 10a, that is, the server This is processing that excludes preprocessing from processing corresponding to a function.

  Examples of pre-processing and post-processing will be described in the examples described later.

  The server command unit 100 requests the pre-processing registration unit 101 or the post-processing registration unit 102 to register pre-processing or post-processing in accordance with an instruction from the server operator. The server command unit 100 may request the pre-processing registration unit 101 and the post-processing registration unit 102 to register pre-processing and post-processing according to an instruction from the connected client, or on the server 10b. Registration of pre-processing and post-processing may be requested to the pre-processing registration unit 101 and the post-processing registration unit 102 in accordance with an instruction from the application being executed.

  The server function association unit 103 creates and holds a table in which server functions, preprocessing, and postprocessing are associated with each other in response to instructions from the preprocessing registration unit 101 and the postprocessing registration unit 102. FIG. 2 is a diagram illustrating an example of a table in which server functions, pre-processing, and post-processing stored in the server function associating unit 103 are associated with each other. As illustrated in FIG. 2, the server function association unit 103 registers pre-processing and post-processing corresponding to an identifier representing a server function (hereinafter referred to as a server function identifier) as a table. In the example shown in FIG. 2, preprocessing 1 is registered as preprocessing for server function A, and postprocessing 2 is registered as postprocessing for server function A. Further, pre-processing 2 is registered as pre-processing of the server function B, and post-processing 1 is registered as post-processing of the server function B. Further, preprocessing 3 is registered as preprocessing of the server function C. When such a table is registered in the server function associating unit 103, for example, when the server function A is requested from the client 10a, the server 10b executes the preprocessing 1, and then displays the execution result as the client 10a. Then, post-processing 2 is executed.

  The asynchronous communication receiving unit 107 receives a server function call request message from the client 10 a and passes it to the server function associating unit 103. The server function association unit 103 requests the preprocessing execution unit 108 to execute preprocessing. The preprocessing execution unit 108 executes preprocessing in response to a request from the server function association unit 103 and returns the execution result to the server function association unit 103. The server function associating unit 103 creates an end message based on the execution result of the preprocessing returned from the preprocessing execution unit 108 and passes it to the asynchronous communication transmission unit 109. The asynchronous communication transmission unit 109 transmits an end message based on the execution result of the preprocessing to the client 10a by asynchronous communication. The server function association unit 103 passes an end message based on the execution result of the preprocessing to the asynchronous communication transmission unit 109, and then causes the postprocessing execution unit 110 to perform postprocessing corresponding to the called server function. The post-processing execution unit 110 executes post-processing in response to a request from the server function association unit 103.

  FIG. 3 is a sequence diagram for explaining an overview of processing between the server 10b and the client 10a in the client server type system according to the first embodiment. Hereinafter, an overview of processing between the server 10b and the client 10a in the client-server system according to the first embodiment will be described with reference to FIG.

  In the client 10a, when the client command unit 104 requests the server function to be called, the communication control unit 112 transmits a request message for calling the server function to the server 10b by asynchronous communication.

  The server 10b that has received the request message executes only the preprocessing corresponding to the requested server function. When the preprocessing is completed, the server 10b transmits an end message to the client 10a and displays the execution result of the preprocessing. Notice. Thereafter, the server 10b performs post-processing.

  Upon receiving the end message from the server 10b, the communication control unit 112 of the client 10a notifies the client command unit 104 that the server function call has been completed. As a result, the client command unit 104 can receive the execution result of the preprocessing.

  FIG. 4 is a flowchart showing details of the operation of the entire client-server system according to the first embodiment of the present invention. The details of the operation of the entire client-server system according to the first embodiment will be described below with reference to FIG. In FIG. 4, steps S201 to S203 indicate the operation of the server 10b. Steps S204 to S205 show the operation of the client 10a. Steps S206 to S210 show the operation of the server 10b. Steps S211 to S212 show the operation of the client 10a.

  First, the preprocessing registration unit 101 of the server 10b receives a preprocessing registration request from the server command unit 100, and performs a registration process (step S201). Next, the post-processing registration unit 102 receives a post-processing registration request from the server command unit 100 and performs registration processing (step S202). Here, each registration request in step S201 and step S202 is performed by the server command unit 100. However, the server 10b receives a registration request from the client command unit 104 of the client 10a, and the registration request is preprocessed. Registration processing may be performed by notifying the registration unit 101 and the post-processing registration unit 102. Note that the timing at which step S201 and step S202 are performed may be when there is an instruction from an operator of the server, when there is an instruction from a connected client, or when it is executed on the server 10b. It may be when there is an instruction from the application.

  Next, the server function associating unit 103 stores the registered pre-process and post-process in association with the server function identifier (step S203). Here, the server function associating unit 103 collectively associates server function identifiers after registration of pre-processing and post-processing. However, at the time of each process registration in step S201 and step S202, Association with a server function identifier may be performed.

  When there is a call request for a specific server function by the client command unit 104 of the client 10a, the synchronous communication unit 105 receives the call request by synchronous communication (step S204). This server function call request includes the server function identifier of the requested server function, transmission source information, transmission destination information, data required for execution of preprocessing, data required for execution of postprocessing, etc. Information and destination information necessary for realizing synchronous communication by asynchronous communication are included.

  Next, the synchronous communication unit 105 that has received the server function call request causes the asynchronous communication transmission unit 106 to transmit a request message for calling the server function to the server 10b by asynchronous communication (step S205).

  Next, the asynchronous communication receiving unit 107 of the server 10b receives a request message from the client 10a (step S206).

  Next, the server function associating unit 103 refers to the held table, determines preprocessing corresponding to the server function identifier included in the received request message, and sends the association to the preprocessing execution unit 108. The preprocess is executed (step S207). In step S207, if the request message received in step S206 includes data necessary for executing the preprocessing, the preprocessing execution unit 108 performs the preprocessing using the data.

  Next, the preprocessing execution unit 108 outputs the execution result of the preprocessing executed in step S207 to the server function association unit 103 (step S208).

  Next, the server function association unit 103 passes the execution result obtained from the preprocessing execution unit 108 to the asynchronous communication transmission unit 109, causes the asynchronous communication transmission unit 109 to create an end message including the execution result, and causes the client 10a to On the other hand, an end message is transmitted by asynchronous communication (step S209). The end message includes information necessary for informing that the server function request has been completed, such as transmission source information and transmission destination information, in addition to the execution result of the preprocessing. Note that the destination of the client 10a serving as the transmission destination is determined based on the transmission source information included in the request message.

  After transmitting the end message in step S209, the server function associating unit 103 determines a post-process corresponding to the server function identifier, and causes the post-process executing unit 110 to execute the post-process (step S210). In step S210, if the request message received in step S206 includes data necessary for executing post-processing, the post-processing execution unit 110 executes post-processing using the data.

  On the other hand, in the client 10a, the asynchronous communication receiving unit 111 receives the end message from the server 10b and notifies the synchronous communication unit 105 (step S211).

  In response, the synchronous communication unit 105 notifies the client command unit 104 that the server function call has been completed (step S212). Note that the completion notification includes the execution result of the preprocessing included in the end message. Upon receiving this notification, the client command unit 104 continues the desired process.

  As described above, according to the first embodiment, the server 10b divides and registers the processing corresponding to the server function into the pre-processing and the post-processing, and when execution of the server function is requested from the client 10a, When the preprocessing corresponding to the server function is executed and the execution of the preprocessing is completed, an end message is transmitted to the client 10a. Therefore, the client 10a can receive the end message and execute a desired process before all the processes corresponding to the server function (that is, pre-processing and post-processing) are executed. Compared with the case where the end message is transmitted to the client 10a after the processing corresponding to is executed and the desired processing is executed, the turnaround time is shortened. In addition, the client 10a can recognize the point in time when the minimum necessary processing corresponding to the server function is completed only by calling the server function only once. Also good.

  In the flowchart shown in FIG. 4, the pre-processing registration (step S201), the post-processing registration (step S202), and the association processing (step S203) are performed in series with the processing after step S204. It was described in. However, these processes are typically performed in advance independently of the processes after step S204.

  In the first embodiment, when the server 10b receives a request message from the client 10a, if the step S201 for registering the preprocessing has not been performed in advance, the server 10b executes the preprocessing. Instead of performing step S207 and step S208 for outputting the execution result of the preprocessing, an end message not including the execution result of the preprocessing may be transmitted in step S209.

  In the first embodiment, as in the server function C shown in FIG. 2, for example, step S202 for registering post-processing is not performed in advance at the time of step S206 for receiving a request message from the client 10a. In this case, the server 10b does not perform step S208 for executing post-processing. That is, it is not essential that both the pre-processing registration shown in step S201 and the post-processing registration in step S202 be performed.

(Modification of the first embodiment)
In the first embodiment, the operation after the post-processing execution in the post-processing execution unit 110 is not particularly defined. However, as a modification of the first embodiment, the server 10b may transmit the post-processing execution result to the client 10a.

  FIG. 5 is a flowchart showing details of the operation of the entire client-server system that can also obtain the execution result of post-processing. The details of the operation of the entire client-server system that can also obtain the execution result of the post-processing will be described below with reference to FIG. In FIG. 5, steps showing the same operations as those of the entire client server type system shown in FIG. 4 are denoted by the same step numbers and description thereof is omitted. In FIG. 5, steps S401 to S402 show the operation of the server 10b. That is, the server 10b executes steps S401 to S402 after executing step S210. Steps S403 to S404 show the operation of the client 10a.

  After the execution of the post-processing in step S210, the post-processing execution unit 110 of the server 10b outputs the execution result of the post-processing to the server function associating unit 103 (step S401).

  Next, the server function association unit 103 passes the execution result of the post-processing to the asynchronous communication transmission unit 109, creates a post-processing result message including the execution result, and causes the client 10a to perform the post-processing by asynchronous communication. A processing result message is transmitted (step S402). The post-processing result message includes post-processing execution results and information necessary for informing that all processing at the server for the server function call has been completed, such as transmission source information and transmission destination information. Note that the destination of the client 10a as the transmission destination is determined based on the transmission source information included in the request message.

  Next, the asynchronous communication receiving unit 111 of the client 10a receives a post-processing result message from the server 10b (step S403).

  Next, the synchronous communication unit 105 notifies the client command unit 104 of the post-processing execution result included in the received post-processing result message, and notifies that all processing at the server for the server function call has been completed. (Step S404). In response to this, the client command unit 104 continues desired processing based on the post-processing execution result.

  As a result, the client can acquire the execution result of the post-processing, and can know that all processing in the server for the call of the server function is completed.

(Second Embodiment)
In the second embodiment of the present invention, in addition to the function shown in the first embodiment, the client can process not only the end message but also a cancel message indicating that the server function call has been canceled. The client that has received the cancel message cancels the server function call. Hereinafter, the second embodiment will be described with reference to the drawings.

  FIG. 6 is a block diagram showing an example of the overall configuration of a client server type system according to the second embodiment of the present invention. 6, components having the same functions as those shown in FIG. 1 are denoted by the same reference numerals and description thereof is omitted.

  In FIG. 6, the client 10 c according to the second embodiment includes a client command unit 104 c and a communication control unit 502. The communication control unit 502 includes a synchronous communication unit 105c, an asynchronous communication transmission unit 106, an asynchronous communication reception unit 111c, and a cancellation condition registration unit 501.

  The cancel condition registration unit 501 registers a condition for determining whether or not to cancel the server function call based on information included in the cancel message.

  FIG. 7 is a flowchart showing the operation of the entire client-server system according to the second embodiment. Hereinafter, with reference to FIG. 7, an operation of canceling the end message waiting state by the client will be described. In FIG. 7, the same operations as those shown in FIG. 4 are denoted by the same step numbers and the description thereof is omitted.

  The client command unit 104c registers in advance in the cancellation condition registration unit 501 a condition for determining whether or not to cancel the server function call based on the cancellation message when the client 10c receives the cancellation message (step 501). S601). Note that the operation in step S601 may be performed at any timing before or after the operations in steps S201, S202, S203, and S204, or may be performed in advance independently of these operations.

  In step S602, the asynchronous communication receiver 111c of the client 10c receives an end message or a cancel message from the server 10b. Note that the message received by the asynchronous communication receiving unit 111c in step S602 is any of the end message transmitted by the server 10b in step S209, the cancel message transmitted by the client command unit 104c, and the cancel message transmitted by another client 50a. It is.

  Next, the asynchronous communication receiving unit 111c determines whether the message received in step S602 is a cancel message or an end message (step S603). If it is an end message, the client 10c proceeds to the operation of step S212.

  On the other hand, when the message is a cancel message, the asynchronous communication receiving unit 111c determines whether to cancel the server function call based on the determination condition registered in the cancellation condition registration unit 501 registered in step S601 (step S601). S604).

  If it is determined in step S604 that the server function call is cancelled, the asynchronous communication receiving unit 111c notifies the synchronous communication unit 105c that the server function call is cancelled. In response, the synchronous communication unit 105c notifies the client command unit 104c that the server function call has been canceled (step S605). As a result, the client command unit 104c exits the synchronous return waiting state. On the other hand, if it is determined in step S604 that the server function call is not cancelled, the asynchronous communication receiving unit 111c returns to the operation in step S602 and resumes message reception.

  As described above, according to the second embodiment, the communication control unit 502 of the client 10c can receive a cancel message in addition to the end message. If the cancel message is received, the server function call processing is canceled. Conditions for determining whether or not can be registered. When the communication control unit 502 receives a cancel message, the communication control unit 502 determines whether to cancel the server function call processing based on the above condition. If it is determined to cancel, the call to the client server function is canceled halfway. Accordingly, the turnaround time is shortened.

  Note that the client 10c may discard the end message when the end message is transmitted from the server 10b after canceling the server function call.

(Modification 1 of 2nd Embodiment)
The asynchronous communication transmitting unit 106 of the client 10c that canceled the server function call because the cancel message was received not only sends a request message but also a client server cancel message indicating that the server function call has been canceled to the server 10b. You may send it. At this time, the asynchronous communication receiving unit 107 of the server 10b may receive not only a request message but also a client server cancel message as a message sent from the asynchronous communication transmitting unit 106. When the client-server cancel message is received by the asynchronous communication receiving unit 107, the server 10b may interrupt or end the execution of the server function so that a response to the server function call is not transmitted to the client 10c. Details of this operation are shown in FIG.

  FIG. 8 is a flowchart showing the operation of the entire client-server system when the client notifies the server that the server function call has been canceled. Hereinafter, the operation of the entire client-server system when the client cancels the server function call will be described with reference to FIG. In FIG. 8, steps showing the same operations as those in FIG. 7 are denoted by the same step numbers and description thereof is omitted.

  If it is determined in step S604 that the server function call is cancelled, the asynchronous communication receiving unit 111c notifies the synchronous communication unit 105c that the server function call is canceled (step S605). In response, the synchronous communication unit 105c causes the asynchronous communication transmission unit 106 to transmit a client server cancel message to the server 10b (step S701).

  After outputting the execution result of the preprocessing (step S208), the server 10b determines whether a client server cancel message from the client 10c has been received (step S702). If it is determined in step S702 that the client server cancel message has not been received, the server 10b proceeds to the operation in step S209. On the other hand, when determining that the client server cancel message has been received, the server 10b proceeds to the operation of step S206 for receiving a new request message from the client 10c without performing the operations of steps S209 and S210. Suspend or terminate server function execution.

  According to the above method, when the client server cancel message is transmitted from the client 10c to the server 10b, the server 10b does not need to transmit a response to the server function call to the client 10c. That is, the server 10b does not notify the client 10c of the execution result of the preprocessing after executing the preprocessing. Further, even if post-processing is registered in step S202, the server 10b does not have to execute post-processing that is no longer necessary.

(Modification 2 of the second embodiment)
In the above description, when the client 10c receives the cancel message, the asynchronous communication transmitting unit 106 of the client 10c cancels the server function call and transmits the client server cancel message to the server 10c. The asynchronous communication transmitter 106 of the client 10c that has transmitted the server cancel message may transmit a resume message for resuming execution of the interrupted server function. At this time, the asynchronous communication receiving unit 107 of the server 10b can receive not only the request message and the client server cancel message but also the resume message. When the server 10b is notified of a restart message to resume execution of the server function interrupted by the client 10c, the server 10b executes post-processing that was not executed because the client server cancel message was sent. The execution of the interrupted server function can be resumed. Details of this operation are shown in FIG.

  FIG. 9 is a flowchart showing the operation of the entire client-server system when the client notifies the server of a resume message. Hereinafter, the operation of the entire client-server system when the client notifies the server of a restart message will be described with reference to FIG. 9, steps showing the same operations as in FIG. 8 are given the same step numbers, and descriptions thereof are omitted.

  In step S701, after the client 10c transmits a client server cancel message to the server 10b, the client command unit 104c determines whether or not a restart message to resume execution of the interrupted server function should be transmitted to the server 10b. (Step S801). When transmitting the restart message, the client command unit 104c causes the synchronous communication unit 105c and the asynchronous communication transmission unit 106 to transmit the restart message to the server 10b (step S802). Note that the operation in step S801 may be performed at an arbitrary timing as long as it is after the operation in step S701.

  After step S205, the server 10b receives a request message or a resume message from the client 10c (step S803).

  Next, the server 10b determines whether the message received in step S803 is a request message or a restart message (step S804). If it is determined that the message is a request message, the server 10b proceeds to the operation of step S207. On the other hand, if it is determined that the message is a restart message, the server 10b proceeds to the operation of step S210 and executes post-processing.

  According to the above method, when a resume message is transmitted from the client 10c to the server 10b after the client server cancel message is received, the server 10b performs post-processing that is not executed when the server function call is canceled. Will be executed. Therefore, the execution of the interrupted server function can be resumed.

  Next, specific examples of the server function, pre-processing, and post-processing will be described to describe embodiments of the present invention.

(First embodiment)
The first embodiment of the present invention is a client server type system when an image decoding server is used as a server.

  Conventionally, when the client has requested the server to decode an image as a server function, the server transmits the decoding result to the client after the image decoding process at the server is finished. I was trying to return. However, in such a processing flow, the layout display on the client is delayed. Therefore, the image decoding server according to the first embodiment of the present invention registers, as preprocessing, processing for acquiring the size of an image in the image decoding processing, and performs postprocessing on the processing for decoding the image. Register as Thereby, the delay of the layout display can be eliminated. In the preprocessing here, information regarding the size of the image after decoding is obtained as the minimum necessary information on the client side.

  FIG. 10 is a sequence diagram schematically showing the flow of processing in the client server type system according to the first embodiment. As shown in FIG. 10, when the client selects a URL (step S1), the client transmits image data indicated by the URL to the image decoding server and requests image decoding as a server function (step S2). .

  In response, the image decoding server acquires the image size from the transmitted image data as preprocessing (step S3), and transmits the image size to the client as the execution result of the preprocessing (step S4).

  The client waits for layout information that is the image size (step S5). When the image size is sent, the client displays the layout in which the area in which the image is embedded is white based on the image size (step S6).

  The image decoding server executes image decoding as post-processing after the pre-processing (step S7). When the post-processing is completed, the image decoding server notifies the client of the decoded image as a post-processing result (step S8).

  In response, the client displays the image sent to the white area (step S9).

  As described above, in the first embodiment, only information relating to the minimum image size required when the client performs layout display is acquired in the pre-processing first, and the server transmits the information to the client. Thereafter, decoding of the image is executed as post-processing, and the decoded image is transmitted from the server to the client. As a result, the client can start the layout process without waiting for the server decoding process to be completed.

(Second embodiment)
The second embodiment of the present invention is a client server type system in the case of using a Kana Han server for character conversion as a server.

  Conventionally, when a server attempts to perform prediction data acquisition processing when a client designates a kanji candidate, the acquisition processing takes time, and thus it takes time to display prediction data on the client. On the other hand, when a client requests acquisition of candidates from the server in order to improve the response related to the prediction data display, it takes time for the client to display candidates if the acquisition of prediction data is also requested. Therefore, the kana-han server for character conversion according to the second embodiment of the present invention registers a process for extracting candidates as a pre-process in the process of character conversion, and performs a process for acquiring prediction data. Register as post-processing. In the preprocessing here, information regarding the character conversion candidate is obtained as the minimum necessary information on the client side.

  FIG. 11 is a sequence diagram schematically showing the flow of processing in the client-server system according to the second embodiment. As shown in FIG. 11, when the client inputs kana (step S11), the client requests the kana-han server for character conversion to acquire conversion candidates (step S12).

  In response, the kana-han server for character conversion extracts conversion candidates corresponding to the transmitted kana as the preprocessing (step S13), and transmits the conversion candidates to the client as the execution result of the preprocessing (step S13). S14).

  The client waits for processing until a conversion candidate is notified from the kana-han server for character conversion (step S15). When the conversion candidate is sent, the client displays the conversion candidate (step S16). Next, the client selects one of the conversion candidates and notifies the determined result (step S17). Here, it is assumed that “dog” is selected.

  The kana-han server for character conversion arranges prediction data corresponding to conversion candidates as post-processing after pre-processing (step S18). For example, when “狗” is selected, “play with” is set as prediction data, and when “dog” is selected, “I hate” and “name of” are extracted as prediction data and arranged. Here, since “dog” is selected, the kana-han server for character conversion notifies the client of prediction data corresponding to “dog” as a post-processing result (step S19).

  In response, the client displays the notified prediction data (step S20).

  As described above, in the second embodiment, the conversion candidate extraction process is set as a pre-process, the prediction data arrangement process is set as a post-process, and the server controls the client when the conversion process extraction process is completed. Return. Accordingly, the display of conversion candidates by the client and the arrangement of the prediction data by the server are executed in parallel, so that the response time for displaying the prediction data at the time when the kanji candidate is specified can be shortened. .

(Third embodiment)
The third embodiment of the present invention is a client server type system when a moving image application server is used as a server.

  In the third embodiment, an active state indicates a state in which an application is an operation target. An inactive state indicates that the application is not an operation target. The application used in the third embodiment may be a resident application or a non-resident application. Here, the resident application refers to an application that remains in an inactive state after an inactive request. A non-resident application refers to an application that completely stops when an inactive request is made. In the following description, it is assumed that each application is a resident application.

  In a mobile terminal such as a mobile phone, when receiving a request for a telephone call, the telephone application rings a ringtone to inform the user that an incoming call has been received. The video application server plays a video with sound. Normally, since a mobile terminal cannot output two or more sounds at the same time, the contention mediation app determines the contention between applications (for example, the phone app and the video app server), and each application is loaded from the active state. Transition to the active state. Conventionally, when there is an incoming call when the video application server is in the active state, the telephone application requests the contention arbitration application to make the telephone application active. Next, the contention arbitration application requests the video application server to place the video application in an inactive state. In response to the inactive request, the moving image application server stops the sound together with the moving image, stores the information on the way, and then returns to the competitive arbitration application that the moving image application has become inactive. In response, the contention arbitration app returns to the phone app that the phone app may be activated. Then, the phone application starts ringtone. Therefore, in the conventional method, the telephone application has to wait for the ringtone to start until the intermediate information is stored by the video application. Therefore, the turnaround period was long.

  Therefore, when there is an inactivity request, the video application according to the third embodiment of the present invention registers a process for stopping the video and audio as a pre-process in the process of inactivating the video application. Suppose that the process of saving the video application intermediate information as a file is registered as a post-process.

  FIG. 12 is a diagram schematically illustrating a processing flow in the client-server system according to the third embodiment. As shown in FIG. 12, when the telephone application is in an inactive state (step S21), it is assumed that there is an incoming call notification (step S22). In response to this, the telephone application transmits a request for determining whether or not the telephone application may be activated to the competitive arbitration application through synchronous communication (step S23), and waits for a synchronous return (step S35). .

  In response to this, the contention mediation application waiting for the event (step S24) transmits a request for bringing the video app to the inactive state to the video app server by synchronous communication (step S25), and waits for a synchronous return (step S31). )

  The moving image application server that was in the active state (step S26) stops the moving image and the sound that are being executed (step S27) and enters an inactive state (step S28) as preprocessing. Next, the video application server transmits an OK notification that the video application server is in an inactive state to the competitive arbitration application (step S29). Thereafter, the moving image application server stores the intermediate information of the moving image application as a file as post-processing (step S30). The intermediate information includes information related to the stop point, a moving image display position, color adjustment information, and the like. By storing these halfway information as a file, the moving image application server can reproduce the moving image from the middle when reproducing the moving image display.

  When receiving the OK notification from the video application server, the contention arbitration application that has been waiting for the synchronization return (step S31) cancels the waiting for the synchronization return (step S32) and notifies the OK notification that the phone application may be activated. The message is transmitted to the telephone application (step S33) and the event is waited (step S34).

  In response to the OK notification from the contention arbitration server, the telephone application enters an active state after waiting for a synchronous return (step S35) (step S36) and starts ringing the telephone application (step S37). As a result, no audio contention occurs.

  As described above, in the third embodiment, by registering a minimum process that does not cause audio conflict as a pre-process and registering a process that is prepared for replaying a moving image as a post-process. , Turnaround period in phone app and competitive mediation app can be shortened.

  As described above, the method, the server, and the client used in the client server type system according to the present invention can shorten the turnaround time from the start of the server function request of the client by the synchronous communication to the server function end notification. Therefore, it is useful for devices and systems with low hardware performance such as mobile phones and PDAs.

The block diagram which shows an example of a structure of the client server type | system | group system which concerns on the 1st Embodiment of this invention. The figure which shows an example of the table which matched the server function hold | maintained at the server function matching part 103, the pre-process, and the post-process. The sequence diagram for demonstrating the outline | summary of the process between the server 10b and the client 10a in the client server type | system | group system which concerns on 1st Embodiment. The flowchart which shows the detail of operation | movement of the whole client server type system which concerns on the 1st Embodiment of this invention. A flowchart showing details of the operation of the entire client-server system that can also obtain the execution result of post-processing The block diagram which shows an example of the whole structure of the client server type system which concerns on the 2nd Embodiment of this invention The flowchart which shows operation | movement of the whole client server type system which concerns on 2nd Embodiment. Flow chart showing the operation of the entire client-server system when the client notifies the server that the server function call has been canceled Flowchart showing the operation of the entire client server system when the client notifies the server of a resume message The sequence diagram which shows typically the flow of a process in the client server type | system | group system which concerns on a 1st Example. The sequence diagram which shows typically the flow of a process in the client server type | system | group system which concerns on a 2nd Example. The sequence diagram which shows typically the flow of a process in the client server type | system | group system which concerns on a 3rd Example. Sequence diagram showing flow of processing between server and client in conventional synchronous communication method Sequence diagram showing the flow of the conventional synchronous communication method described in Patent Document 1

Explanation of symbols

10a, 10c, 50a Client 10b Server 100 Server command unit 101 Pre-processing registration unit 102 Post-processing registration unit 103 Server function association unit 104, 104c Client command unit 105, 105c Synchronous communication unit 106, 116 Asynchronous communication transmission unit 107 Asynchronous communication Reception unit 108 Pre-processing execution unit 109 Asynchronous communication transmission unit 110 Post-processing execution unit 111, 111c Asynchronous communication reception unit 112 Communication control unit 501 Cancel condition registration unit 502 Communication control unit

Claims (10)

A method used in a client-server distributed system in which a client calls a desired server function to a server and the server executes a process corresponding to the called server function,
A part of the processing corresponding to the server function, the step of registering the processing up to obtaining the minimum information required by the client as preprocessing;
Registering a process to be executed after the pre-process as a post-process that is a part of the process corresponding to the server function;
The method comprising: associating the registered pre-process, the registered post-process, and a server function identifier indicating the server function. The client transmits a request message including a server function identifier indicating the desired server function to the server in order to request a call to the desired server function;
The server receiving the request message sent from the client;
The server executing pre-processing associated with the server function identifier included in the request message;
The server obtaining the execution result of the preprocessing;
The server transmitting an end message including the obtained execution result of the preprocessing to the client;
A server executing post-processing associated with the server function identifier included in the request message after transmitting the termination message;
The method according to claim 1, further comprising a step of executing processing based on an execution result of the preprocessing by the client that has received the termination message. Further, the server obtains an execution result of the post-processing;
The server sending a post-processing result message including an execution result of the post-processing to the client;
The method according to claim 2, further comprising the step of executing processing based on an execution result of the post-processing by the client that has received the post-processing result message. Further, when there is a cancel instruction for canceling the server function call, the client registers in advance a condition for determining whether to cancel the server function call based on the cancel instruction. Step to put
If there is a cancel instruction, the client determines whether to cancel the call to the server function according to the cancel instruction; and
The method according to claim 2, further comprising: canceling the call to the server function if it is determined to cancel. A server for executing a server function called from a client,
A part of the process corresponding to the server function, a pre-processing registration unit for registering a process until obtaining the minimum information required by the client as a pre-process,
A post-processing registration unit that is a part of the process corresponding to the server function and registers a process to be executed after the pre-process as a post-process;
A server comprising: a server function association unit that associates the registered pre-process, the registered post-process, and a server function identifier indicating the server function. A receiving unit that receives from the client a request message including a server function identifier indicating a server function desired by the client;
A preprocessing execution unit that executes preprocessing associated with the server function identifier included in the request message and outputs an execution result;
A transmission unit that transmits an end message including the execution result of the preprocessing output by the preprocessing execution unit to the client;
The server according to claim 5, further comprising: a post-processing execution unit that executes post-processing associated with the server function identifier included in the request message after transmitting the end message. The post-processing execution unit outputs an execution result of the post-processing,
The server according to claim 6, wherein the transmission unit transmits a post-processing result message including an execution result of the post-processing output from the post-processing execution unit to the client. A client for calling a desired server function to a server,
A transmission unit that transmits a request message including a server function identifier indicating the desired server function to the server in order to request a call to the desired server function;
A receiving unit that receives from the server an end message including an execution result by the server of the preprocessing associated with the server function identifier included in the request message;
A control unit that executes processing based on the execution result of the preprocessing received by the receiving unit;
The server function identifier indicating the server function is a part of the process corresponding to the server function, and the process until obtaining the minimum information required by the client is associated as a preprocess, Furthermore, the client is a part of a process corresponding to the server function, and a process to be executed after the preprocess is associated as a postprocess. The server sends a post-processing result message including an execution result of the post-processing to the client;
The receiving unit receives the post-processing result message transmitted from the server;
The client according to claim 8, wherein the control unit executes processing based on an execution result of the post-processing included in the received post-processing result message. Further, when there is a cancel instruction for canceling the call to the server function, cancel condition registration for pre-registering a condition for determining whether to cancel the call to the server function based on the cancel instruction Part
When there is a cancel instruction, the control unit determines whether or not to cancel the call to the server function based on the conditions registered in the cancellation condition registration unit. The client of claim 9, canceling the call.

Images