JP4198562B2 - Communication client, communication server, communication system, and communication method - Google Patents

Description

The present invention relates to a communication client that communicates with a communication server , a communication server that communicates with a communication client, a communication system that includes the communication client and the communication server, and a communication method that is executed by the communication client or the communication server.

2. Description of the Related Art Conventionally, in a communication system in which communication devices are connected via a network, communication devices are exchanged with each other so that a communication partner device is notified or requested. In such a system, a command is transmitted as an operation request from one device to another device to execute the operation, and an operation execution result is returned from the transmission partner as an operation response.
Further, a part of the communication device constituting the communication system is a communication client, the other part is a communication server, communication between the communication client and the communication server is always transmitted from the communication client to the communication server, It is also known to use a protocol in which a communication response is returned from a communication server to the transmission source communication client.
Thus, an operation request from the communication client to the communication server is described in the communication request and transmitted, and an operation response to the operation request is described in the communication response and returned from the communication server to the communication client.

On the other hand, as a technique for transmitting an operation request from a communication server to a communication client to perform an operation, the following is known.
For example, Patent Document 1 describes that a remote processor transmits a message indicating a command to be executed to a local processor and receives a response to the command.
Also, in this document, when a local processor is placed inside a firewall, a communication request is transmitted from the local processor to a remote processor outside the firewall, and the remote processor sends a response to the communication request to the local processor. A technique is also disclosed in which a command can be transmitted from the outside to the inside of the firewall by transmitting the command.
In this case, the local processor corresponds to the communication client, and the remote processor corresponds to the communication server.
JP 20012733211 A

In addition, such a technique related to an operation request can be applied to a system that remotely controls the operation of an apparatus connected to a communication apparatus. Patent Document 2 discloses a remote operation system for operating a blind and illumination by transmitting a command from a remote operation device having a function of accepting an operation from a user to a remotely operated device having a function of operating a blind and illumination. An example in which such a technique is applied is described. However, this document does not show that a response to the command is transmitted.
JP 2002-135858 A

  By the way, when exchanging messages between a plurality of communication devices, the number of communication devices that transmit commands is not limited to one. It is also possible for a plurality of communication devices to send commands to each other. In this case, the communication device that has received the command is caused to return an execution result to the source of each command. It is requested to be. When such an operation is performed, information transmitted from a certain communication device to a communication partner device may be a command for the communication partner device and an execution result for a command received from the communication partner device.

Conventionally, these commands and execution results are transmitted separately. However, in such a system, it is necessary to establish a communication connection separately when a command is transmitted and when an execution result for a received command is transmitted. Therefore, communication overhead is increased, and there is a problem in efficiency.
At present, there are still many environments in which communication via a network is performed by dial-up connection. In such an environment, the above points are particularly problematic. In such an environment, it may take several tens of seconds to establish a connection, and a fee will be charged each time a connection is established, so increasing the number of connection establishments will increase costs. is there.
The present invention solves such a problem and increases communication efficiency when a plurality of communication devices that transmit and receive a communication request and a communication response to the communication request transmit and receive an operation request and an operation response to the received operation request. For the purpose.

In order to achieve the above object, a communication client according to the present invention includes a server request received from the communication server as a request for performing a predetermined operation and a response to the server request. First storage means for storing a certain operation response, second storage means for storing a client request that is a request for performing a predetermined operation on the communication server, and operations related to each of the server request and the client request The progress status has been processed from state storage means for storing status information indicating whether the progress status is unprocessed, being processed, or processed, and the first storage means. An operation response related to the server request is acquired, and the client request whose progress status is unprocessed is acquired from the second storage unit. A collecting means for, in which a communication request including said collection means and said operation response has acquired and the client requests are provided and transmission means for transmitting to the communication server.

Such a communication client retrieves the server request whose progress status is unprocessed from the first storage means, and operates the server request in an appropriate module determined according to the content of the server request. And request processing means for changing the status information about the server request during processing.
Further, it is preferable that a plurality of the request processing means are operated simultaneously by a plurality of threads.
The transmission means may be a means for transmitting a communication request including a plurality of the operation responses and a plurality of the client requests.

Furthermore, it is preferable that the transmission unit periodically transmits a communication request to the communication server regardless of whether the operation response and the client request are acquired by the collection unit.
Furthermore, when the server request is received from the communication server, the operation response to the server request may be transmitted by being included in the periodic communication request from the next time onward.

The communication server of the present invention stores a client request that is a request to perform a predetermined operation received from the communication client and an operation response that is a response to the client request, in the communication server that communicates with the communication client. The first storage means for performing the operation, and the second storage means for storing a server request for requesting the communication client to perform a predetermined operation; State storage means for storing state information indicating which state is processed, being processed, or processed, and an operation related to the client request whose progress status has been processed from the first storage means A response is acquired, and the server request whose progress status is unprocessed is acquired from the second storage unit. Means and to the communication request received from the communication client, in which the communication response comprising the collector means the operational response and which has acquired said server request is provided and transmitting means for transmitting to the communication client.

In such a communication server, the client request whose progress status is unprocessed is searched from the first storage unit, and the operation related to the client request is executed in an appropriate module determined according to the content of the client request. And request processing means for changing the status information about the client request during processing.
Further, it is preferable that a plurality of the request processing means are operated simultaneously by a plurality of threads.
The transmission means may be a means for transmitting a communication response including a plurality of the operation responses and a plurality of the server requests.

Further, the present invention provides a communication system including a communication client and a communication server, wherein the communication client receives a request from the communication server to perform a predetermined operation and a response to the server request. A first client-side storage unit that stores a response; a second client-side storage unit that stores a client request that is a request to perform a predetermined operation on the communication server; and each of the server request and the client request. With respect to the progress status of the operation, the progress from the client-side status storage means for storing status information indicating whether the status is unprocessed, in-process, or processed, and the progress from the first client-side storage means An operation response related to the server request whose status has been processed is acquired, and the second client A communication request including a client-side collection unit that acquires the client request whose progress status is unprocessed from the side storage unit, and the operation response and the client request acquired by the client-side collection unit. A client-side transmitting means for transmitting, and storing, in the communication server, a client request that is a request to perform a predetermined operation received from the communication client and an operation response that is a response to the client request The server-side storage unit, the second server-side storage unit that stores a server request that is a request for performing a predetermined operation on the communication client, and the progress of the operation related to each of the client request and the server request State information indicating whether the state is in process, in process, or processed The server-side status storage means and the first server-side storage means obtain an operation response related to the client request whose processed progress has been processed, and from the second server-side storage means, the progress A server-side collection unit that acquires the server request whose status is unprocessed, and a communication response that includes the operation response and the server request acquired by the server-side collection unit in response to a communication request received from the communication client Is provided with server-side transmission means for transmitting the message to the communication client.

Also, the communication method of the present invention is a server request that is a request to perform a predetermined operation received from the communication server and a response to the server request in a communication method that is executed by a communication client that communicates with a communication server. A first storage procedure for storing an operation response, a second storage procedure for storing a client request that is a request for performing a predetermined operation on the communication server, and an operation relating to each of the server request and the client request. Regarding the progress status, the status storage procedure for storing state information indicating whether the status is unprocessed, being processed, or processed, and the progress status stored in the first storage procedure has been processed. The client request that has acquired an operation response related to the server request and that has been stored in the second storage procedure and whose progress status is unprocessed A collection procedure for acquiring, at a communication request including the collection procedure the operational response and acquired in the said client request having a transmission step of transmitting to the communication server.

In such a communication method, a server request whose progress status is unprocessed is searched from the server request stored in the first storage procedure, and the server request is assigned to an appropriate module determined according to the content of the server request. It is preferable to further provide a request processing procedure for executing such an operation and changing the state information stored for the server request during processing.
Furthermore, a plurality of processes of the request processing procedure may be executed simultaneously by a plurality of threads.
The transmission procedure may be a procedure for transmitting a communication request including a plurality of the operation responses and a plurality of the client requests.

Furthermore, in the transmission procedure, a communication request may be periodically transmitted to the communication server regardless of whether or not the operation response and the client request are acquired in the collection procedure.
Furthermore, when the server request is received from the communication server, an operation response to the server request may be included in the periodic communication request for the next and subsequent transmissions in the transmission procedure.

According to another communication method of the present invention, in a communication method executed by a communication server that communicates with a communication client, a client request that is a request for performing a predetermined operation received from the communication client, and a response to the client request A first storage procedure for storing the operation response, a second storage procedure for storing a server request that is a request for performing a predetermined operation on the communication client, and each of the client request and the server request Regarding the operation progress status, a status storage procedure for storing status information indicating whether the status is unprocessed, in-process, or processed, and the progress status stored in the first storage procedure is processed. The operation response related to the client request that has been completed is acquired, and the progress status stored in the second storage procedure is not processed. A collection procedure for acquiring the server request, and a transmission for transmitting a communication response including the operation response and the server request acquired in the collection procedure to the communication client in response to the communication request received from the communication client. Procedure.

In such a communication method, a client request whose progress status is not processed is searched from the client request stored in the first storage procedure, and the client request is assigned to an appropriate module determined according to the content of the client request. It is preferable to further provide a request processing procedure for executing such an operation and changing the status information regarding the client request during processing.
Furthermore, it is preferable that a plurality of processes of the request processing procedure are executed simultaneously by a plurality of threads.
The transmission procedure may be a procedure for transmitting a communication response including a plurality of the operation responses and a plurality of the server requests.

According to the communication client, communication server, communication system, and communication method of the present invention as described above, a plurality of communication devices that transmit and receive a communication request and a communication response to the communication request send an operation request to each other and an operation response to the received operation request. In the case of configuring a communication system for transmission and reception, communication efficiency can be increased.

The best mode for carrying out the present invention will be described below with reference to the drawings.
First, FIG. 1 shows a configuration example of a communication system of the present invention configured using the communication apparatus of the present invention.
As shown in FIG. 1, this communication system is configured by connecting a first communication device 1 and a second communication device 2, which are communication devices of the present invention, via a network 10.
The first communication device 1 and the second communication device 2 can be configured as various electronic devices having a communication function and an information processing function, including a computer such as a PC having a communication function. As the network 10, various communication paths capable of network communication can be used regardless of wired or wireless, including the Internet and a LAN (local area network).

Further, the first communication device 1 and the second communication device 2 are mounted with application programs for performing mutual control management. Each of these nodes transmits an “operation request” that is a request for processing for a method of the application program to be implemented by RPC (Remote Procedure Call), and “operation response” is a result of the requested processing. Can be acquired. That is, the first communication device 1 generates a request to the second communication device 2 (hereinafter referred to as a first communication device-side request), delivers it to the second communication device 2, and responds to this request. The second communication device 2 generates a request to the first communication device 1 (hereinafter referred to as a second communication device-side request) and delivers it to the first communication device 1, A response to this request can be acquired.
Here, the method is defined as a logical function that defines the format of input and output. In this case, the operation request is a function call for calling this function (Procedure Call), and the operation response is an execution result of the function called by the function call.

FIG. 2 shows the relationship between these operation requests and operation responses.
FIG. 2A shows a case where an operation request for the second communication device 2 is generated in the first communication device 1. In this case, the first communication device 1 generates a first communication device-side operation request and transmits it to the second communication device 2, and the second communication device 2 that receives the request transmits an operation response to the request. It becomes a model to return.

FIG. 2B shows a case where an operation request for the first communication device 1 is generated in the second communication device 2. In this case, the second communication device 2 generates a second communication device-side request and transmits it to the first communication device 1, and the first communication device 1 that receives the request returns an operation response to the request. It becomes a model.
Here, SOAP (Simple Object Access Protocol) is adopted as a protocol for passing arguments and return values by RPC, and the above operation request and response are described here as SOAP messages.

The feature of the present invention is that when a plurality of communication devices transmit / receive operation requests and operation responses to received operation requests to each other, the operation request to be transmitted to the communication partner device and the communication request device received from the communication partner device. The point is that the operation response to the operation request is transmitted collectively.
As a communication protocol for actually transferring an operation request or an operation response, an appropriate protocol can be adopted according to the system configuration, for example, HTTP (HyperText Transfer Protocol) or SMTP (Simple Mail Transfer Protocol). Can be adopted. However, since the electronic mail transferred by SMTP does not have a correspondence relationship such as a communication request and a communication response, a system employing SMTP is not included in the embodiment of the communication system of the present invention.
Therefore, first, an embodiment in which HTTP is adopted as a communication protocol will be described, and then a case in which SMTP is adopted will be described as a reference example.

[Example when HTTP is adopted: FIGS. 3 to 21]
FIG. 3 shows a configuration example of a communication system to which an embodiment in the case of adopting HTTP is applied.
As shown in FIG. 3, this communication system is configured by connecting an HTTP server 12 and an HTTP client 11 via the Internet 13. However, in order to improve security, the HTTP client 11 is connected to the Internet 13 via the firewall 14. The HTTP server 12 is a communication server and corresponds to the first communication device, and the HTTP client 11 is a communication client and corresponds to the second communication device.

  When communication is performed using HTTP, a node inside the firewall 14 cannot be freely accessed from outside the firewall 14, and a communication response (HTTP request) to a communication request (HTTP request) from the node is not possible. Data can only be sent in the form of (response). Therefore, in this communication system, the node inside the firewall 14 is the HTTP client 11, and the node outside is the HTTP server 12. Therefore, the functions of these nodes need not be limited to the client or server except for communication between them.

  Further, the HTTP server 12 and the HTTP client 11 are mounted with application programs for performing mutual control management as in the case of the first communication device 1 and the second communication device 2 shown in FIG. . Then, an RPC (Remote Procedure Call) can be used to transmit an “operation request” that is a processing request for a method of an application program to be implemented, and to acquire an “operation response” that is a result of the requested processing. It can be done.

FIG. 4 shows the relationship between these operation requests and operation responses.
FIG. 4A shows a case where an operation request for the HTTP server 12 is generated by the HTTP client 11. In this case, the HTTP client 11 generates a client-side operation request (corresponding to a client request; hereinafter also referred to as “client command”) and transmits it to the HTTP server 12, and the HTTP server 12 that has received this request responds to the command. It is a model that returns an operation response (hereinafter also referred to as “command response” or simply “response”).

FIG. 4B shows a case where an operation request for the HTTP client 11 is generated in the HTTP server 12. In this case, the HTTP server 12 generates a server-side operation request (corresponding to a server request, hereinafter also referred to as a “server command”) and transmits it to the HTTP client 11. It is a model that returns motion response.
As described above, the operation request and the operation response are handled symmetrically between the HTTP client 11 and the HTTP server 12 at the RPC level. However, it is not symmetrical at the communication level.

FIG. 5 shows an example of a communication sequence in this communication system.
As shown in this figure, in this communication system, communication always transmits an HTTP request as a communication request from the HTTP client 11 to the HTTP server 12, and an HTTP response is transmitted from the HTTP server 12 as a communication response to the communication request. The procedure is to return to 11. For example, the HTTP server 12 returns an HTTP response X to the HTTP request X transmitted from the HTTP client 11, and similarly returns an HTTP response Y to the HTTP request Y.

  In the HTTP request, a client command that is an operation request transmitted from the HTTP client 11 to the HTTP server 12 and a response (command response) to the server command transmitted from the HTTP server 12 to the HTTP client 11 are described. I am trying to send it. In the HTTP response, a server command that is an operation request transmitted from the HTTP server 12 to the HTTP client 11 and a response (command response) to the client command transmitted from the HTTP client 11 to the HTTP server 12 are described. I am trying to send it.

  Therefore, for example, the client command A can be described in the HTTP request X and transferred, and the command response can be transferred in the HTTP response X corresponding to the HTTP request X. However, the server command C is described and transferred in the HTTP response X corresponding to the HTTP request X, and the command response is transferred in the HTTP request Y that is the next HTTP request.

  In the case of FIG. 4A, the HTTP client 11 can establish a connection with the HTTP server 12 immediately after the client command is generated, and the HTTP request can be delivered including this in the HTTP request. In the case of B), since the firewall 14 installed on the HTTP client 11 side blocks the HTTP request from the HTTP server 12, it is not possible to access the HTTP client 11 from the HTTP server 12 side and immediately deliver the server command.

Note that any number of responses to the client command and the server command can be described in one HTTP request (may be 0), and any number of responses to the server command and the client command (may be 0) 1 Can be described in two HTTP responses. The contents described in one HTTP request or HTTP response are logically transferred collectively.
In this way, the number of connections necessary for transferring necessary information is reduced, and overhead is reduced to improve communication efficiency.

FIG. 6 shows an example of another communication sequence in this communication system.
For the sake of explanation, FIG. 5 shows a very simple sequence example, but FIG. 6 shows an example in which the number of commands and command responses described in each HTTP request and HTTP response is not constant.
Further, when a command is received, it is not necessary to return a response at the next transmission opportunity. For example, as in the client command B shown in FIG. 6, the response is described in the HTTP response X ′ corresponding to the HTTP request X ′ in which the command is described, and the response is described in the subsequent HTTP response Y ′. You may do it.
Of course, the same applies to the server command, and it is not necessary to describe the response to the command in the HTTP request next to the HTTP response describing the server command. And what is necessary is just to describe and transfer in a later HTTP request.

  By the way, each command and command response are generated independently and should be used for processing. Therefore, in order to perform the batch transfer as described above, these commands and command responses are sent before the transfer. A process of combining and separating after transfer is required. Next, a hardware configuration of the HTTP client 11 and the HTTP server 12, a functional configuration for performing such processing, and a procedure of the processing will be described.

FIG. 7 is a diagram illustrating a hardware configuration example of the HTTP client 11 and the HTTP server 12.
As shown in this figure, each of the HTTP client 11 and the HTTP server 12 includes a CPU 31, a ROM 32, a RAM 33, an SD (Secure Digital) card 34, and a network interface card (NIC) 35, which are connected by a system bus 36. ing.

These components will be described more specifically. First, the CPU 31 is a control unit that comprehensively controls the HTTP client 11 or the entire HTTP server 12 by a control program stored in the ROM 32. The ROM 32 is a read-only memory that stores various fixed data including a control program used by the CPU 31.
The RAM 33 is a temporary storage memory used as a work memory or the like when the CPU 31 performs data processing. The SD card 34 is a non-volatile memory that retains stored contents even when the apparatus is turned off. The NIC 35 is a communication means for transmitting / receiving information to / from a communication partner via a network such as the Internet 13.

FIG. 8 is a functional block diagram showing a configuration of functions for performing processing related to commands and command responses among the functions of the HTTP client 11.
Among the functions shown in FIG. 8, the client command pool 41 and the server command pool 42 are provided in any rewritable storage means. For example, it can be provided in the SD card 34, but may be provided in the RAM 33 or an HDD (hard disk drive) (not shown). The functions of the client command generation unit 43, the server command execution result generation unit 44, the transmission message collection unit 45, and the reception message distribution unit 48 are realized by the CPU 31. The functions of the HTTP request transmission unit 46 and the HTTP response reception unit 47 are realized by the CPU 31 and the NIC 35.

These functions will be described in further detail.
First, the client command pool 41 corresponds to a second storage area provided in the HTTP client 11, and is a pool that registers a client command, a response to the command, and identification information of the command in association with each other. The server command pool 42 corresponds to a first storage area provided in the HTTP client 11 and is a pool that registers a server command, a response to the command, and identification information of the command in association with each other. In these pools, a command sheet in a table format is created for each command and information is stored to associate the command with information such as identification information and a response. Further, it is assumed that the storage means provided with these pools correspond to the second and first storage means of the HTTP client 11, respectively.

  The client command generation unit 43 corresponds to a request generation unit. Then, a client command is generated, identification information (ID) for identifying the command is assigned, management information for managing the command is further attached, and these information are associated with each other as a client command sheet in a table format. It has a function of registering in the pool 41. Of these, for example, an application provided in the HTTP client 11 corresponds to a part that generates a client command. In addition, the client command generation unit 43 may be provided with a function of attaching the priority order for causing the HTTP server 12 to execute each command to the generated client command.

FIG. 9 shows an example of the data structure in the client command sheet of the HTTP client 11.
As shown in this figure, in the HTTP client 11, the client command sheet includes “command ID”, “method name”, “input parameter”, “state”, “notification destination of client command execution result”, and “ An area for storing “output parameter” data is provided. Of these, “command ID”, “method name”, and “input parameter” correspond to client commands (and IDs attached thereto), and “status” and “notification destination of client command execution result” are managed. Applicable to information. The “output parameter” is the content of the command response received from the HTTP server 12.

Next, the contents of each item will be described.
First, “method name” is the content of a request to the HTTP server 12, and indicates the type of function to be called in the HTTP server 12. “Input parameter” is data attached to “method name”, and is an argument for calling a function. “Command ID” is identification information for identifying a client command. “Status” is data indicating the progress of processing related to the client command, and changes from “not transmitted” → “waiting for response” → “response received” with the progress of processing.

  The “client command execution result notification destination” is reference information indicating a module that, when receiving a response to the client command described in the sheet, notifies that fact and executes a necessary process. The referenced module is often the application that generated the client command, but this need not be the case. The “output parameter” stores the contents when the command response is received. It is empty until a command response from the HTTP server 12 is received.

  Returning to the description of FIG. 8, the server command execution result generating unit 44 corresponds to a response generating unit. The server command is an application that reads and executes a server command from the server command pool 42. Then, it has a function of generating a response to the server command and registering it in the server command pool 42 in association with the command ID of the server command. The server command received from the HTTP server 12 is registered in the server command pool 42 as a table-format server command sheet in association with an ID for identifying this command and management information for managing this command. ing. The command response generated by the server command execution result generating unit 44 is also registered in the server command sheet for the executed server command.

Further, it is conceivable to provide the server command execution result generating means 44 with a function of reading a plurality of types of server commands from the server command pool 42 and generating a response to each server command. Furthermore, when the server command includes information on the execution priority for causing the HTTP client 11 to execute the processing with priority, it is possible to provide a function for reading and executing the information from the highest priority.
The server command execution result generating unit 44 may be a module that calls an application necessary for executing the server command and executes the command instead of the application itself.

Here, FIG. 10 shows an example of the data structure in the server command sheet of the HTTP client 11.
As shown in this figure, in the HTTP client 11, the server command sheet includes “command ID”, “method name”, “input parameter”, “state”, “output parameter”, and “server command notification destination”. An area for storing the data "is provided. Of these, “command ID”, “method name”, and “input parameter” correspond to the server command (and the ID attached thereto), and “status” and “server command notification destination” are the management information. Applicable. The “output parameter” is the execution result of the server command and is the content of the command response returned by the HTTP client 11.

Next, the contents of each data will be described.
First, “method name” is the content of a request to the HTTP client 11 and indicates the type of function to be called in the HTTP client 11. “Input parameter” is data attached to “method name”, and is an argument for calling a function. “Command ID” is identification information for identifying a server command. “Status” is data indicating the status of processing related to the server command. As the processing progresses, “Unprocessed” → “Processing completed” → “Responded” or “Unprocessed” → “Processing” → “Processing” “Complete” → “Responded”. The “output parameter” stores a response generated by the server command execution result generating unit 44. It is empty until the execution of the server command ends and the above “status” becomes “processing complete”. The “server command notification destination” is reference information indicating a module that executes a server command.

Returning to the description of FIG. 8 again, the transmission message collecting means 45 corresponds to the collecting means. Then, the command response generated by the server command execution result generating unit 44 is associated with the command ID of the server command corresponding to the command response and read from the server command pool 42, and the client command generated by the client command generating unit 43 and this It has a function of reading from the client command pool 41 in association with the command ID of the command and generating a transmission message from these.
When the execution priority is specified in the command response or the client command, it is conceivable that the transmission message collection unit 45 reads the messages in descending order of execution priority.

Here, the transmission message is a description of the command response, command, and command ID described above as a SOAP message in XML (Extensible Markup Language) that is a structured language. Then, the transmission message collecting unit 45 generates one SOAP message as a transmission message for one command response or command. At this time, the command ID of each command is described in the SOAP header, and the contents of the command response and the client command are described in the SOAP body. In communication using SOAP, a message called a SOAP envelope (envelope) composed of a SOAP header and a SOAP body is written in XML and exchanged using a protocol such as HTTP.
Generation of a SOAP message from such a command or command response can be performed by executing a required conversion program (serializer) generated based on WSDL (Web Service Description Language) and serializing the data. .

The HTTP request transmission unit 46 corresponds to the transmission unit and has a function of generating an HTTP request including the transmission message generated by the transmission message collection unit 45 and transmitting the HTTP request to the HTTP server 12. At this time, any number of transmission messages may be included in one HTTP request, and a transmission message related to a command response and a transmission message related to a client command can be arbitrarily mixed.
Therefore, the HTTP request transmission means 46 transmits all the transmission messages generated by the transmission message collection means 45 in one HTTP request regardless of which of these transmission messages. However, it is also conceivable to set an upper limit on the number of transmission messages included in one HTTP request.

By the way, this HTTP request is transmitted when the transmission message collection means 45 attempts to read out a client command, a command response, etc., when there is no data to be read and consequently a SOAP message to be transmitted is not generated. Also do. This reading attempt is made periodically. For example, it is possible to read out every 60 minutes by a timer.
This is because, as described above, even if there is information to be transmitted from the HTTP server 12 to the HTTP client 11, it cannot be transmitted unless communication is requested from the HTTP client 11. Even if there is no data to be transmitted from the HTTP client 11, a communication request is periodically transmitted to the HTTP server 12 to give an opportunity to transmit information from the HTTP server 12 to the HTTP client 11. Can be prevented from staying in the HTTP server 12 for a long period of time.

  Of course, the reading by the transmission message collecting unit 45 and the subsequent transmission of the HTTP request by the HTTP request transmitting unit 46 may be appropriately performed at other than the regular timing. For example, when information that needs to be transmitted urgently is registered in any of the pools, the client command generation unit 43 or the server command execution result generation unit 44 notifies the transmission message collection unit 45 of the fact and reads it. You may make it let.

Next, the HTTP response receiving unit 47 corresponds to a receiving unit and has a function of receiving an HTTP response from the HTTP server 12. Here, in the HTTP response, a received message including a server command and a command ID associated with the command and a received message including a response to the client command and a command ID associated with the command are arbitrarily mixed. Included.
Here, the received message is a message in which the above command, response, and command ID are described as a SOAP message.

The received message distribution unit 48 corresponds to a distribution unit. The HTTP response receiving unit 47 has a function of distributing and registering data included in the HTTP response received in the client command pool 41 and the server command pool 42.
Specifically, a server command and a command ID associated with the command are registered in the server command pool 42 by providing a server command sheet, and for a response to the client command, the command ID associated with the command is the client ID. The corresponding client command is identified by comparing with the command ID of the client command sheet stored in the command pool 41, and registered as an “output parameter” for the client command.
At this time, the HTTP response is divided and each received message included therein is extracted, and the data is converted into a format necessary for registration in the table. This conversion is a required conversion generated based on WSDL. This can be done by executing a program (deserializer).

Next, FIG. 11 shows an example of an HTTP request transmitted from the HTTP client 11 having such a function to the HTTP server 12.
In this HTTP request, as shown in FIG. 11, a multi-part message according to MIME (Multipurpose Internet Mail Extension) is described as a body part, and each part includes an entity header and a detailed description. Although not shown, a SOAP envelope is embedded. In the example of FIG. 11, in the HTTP body of the HTTP request, each element divided by “MIME_boundary” forms an independent first part, second part, third part, and fourth part. The number of parts that can be included in the body is not limited to four. Any number is possible including zero.
The SOAP envelope embedded and delivered in the HTTP request includes a client command and a response to the server command.

FIG. 12 shows an example of an HTTP response received by the HTTP client 11 having such a function from the HTTP server 12.
As shown in FIG. 12, this HTTP response is different only in the HTTP request shown in FIG. 11 and the HTTP header part, and the body part is not shown in detail as in the case of the HTTP request. However, a multi-part SOAP envelope according to MIME is described. The contents of the SOAP envelope naturally differ according to the contents of the command and command response.
The SOAP envelope embedded and delivered in the HTTP response includes a server command written and a response to the client command written.

Next, specific examples of the parts described in these HTTP requests or HTTP responses are shown in FIGS.
FIG. 13 shows an example of a part describing a client command.
In this example, first, information indicating whether the SOAP message described in this part is a SOAP request or a SOAP response is described in the “X-SOAP-Type” header of the entity header part. . In this example, the value “Request” indicates a SOAP request, that is, a SOAP message in which a command is described.
The “SOAPAction” header indicates the content of the SOAP request. In this example, the content of the request is indicated by a URI (Uniform Resource Identifier) “http: // www. Since the “SOAPAction” header is not added when the SOAP message is a SOAP response, the message receiving side determines whether the SOAP message is a SOAP request or a SOAP response based on the presence or absence of this header. You can also

  The namespace is declared as an attribute of the “Envelope” tag. And here, in addition to the namespace defined as a standard in SOAP, it is specified by URIs of “http://www.foo.com/header” and “http://www.foo.com/server”. The namespace is declared. Therefore, it can be seen that the XML tag with the namespace prefix “n” belongs to the namespace specified by the URI “http://www.foo.com/header”. It can be seen that the XML tag with the namespace prefix “” belongs to the namespace specified by the URI “http://www.foo.com/server”.

  In the SOAP header, “12345” that is the ID of this client command is described as the content of the XML tag of “request ID”. In the SOAP body, an “abnormality notification” tag is described as information for designating a method stored in the “method name” of the client command sheet, and elements of the lower tag “error ID” and “description” The argument stored in “input parameter” is described. Here, the notification content of the abnormality notification is described.

FIG. 14 shows an example of a part describing a response to a client command.
In this example, first, the value of the “X-SOAP-Type” header in the entity header portion is described as “Response”, so that the SOAP message described in this part is a SOAP response, that is, a command. It indicates that the message is a SOAP message describing a response.
Also in this example, the namespace declaration is the same as in the example shown in FIG. In the SOAP header, “12345” that is the ID of the client command that generated the response is described as the content of the XML tag of “command ID”. The SOAP body is provided with an “abnormality notification response” tag for indicating a response to the “abnormality notification” command, and the content of the command response is described in a lower tag. Here, information indicating that the abnormality notification has been normally received is described. This information is stored in the “output parameter” item of the client command sheet.

FIG. 15 shows an example of a part describing a server command.
Also in this example, as in the case of FIG. 13, “Request” in the value of the “X-SOAP-Type” header indicates that the SOAP envelope described in this part is a SOAP request, and “SOAPAction” The contents of the SOAP request are indicated by the header information.

Also, the name space is declared as the attribute of the “Envelope” tag, as in the case of FIG. And here, in addition to the namespace defined as a standard in SOAP, it is specified by URIs of “http://www.foo.com/header” and “http://www.foo.com/client”. The namespace is declared.
In the SOAP header, “98765” that is the ID of this client command is described as the contents of the XML tag of “request ID”. In the SOAP body, a “temperature sensor value acquisition” tag is described as information for designating a method to be stored in the “method name” of the server command sheet, and as an element of the lower tag “sensor ID”, Arguments to be stored are described in “Input parameters”. Here, the ID of the sensor for acquiring the sensor value is described.
In addition, as a case where a server transmits such a command, the case where it is going to identify the cause of abnormality by receiving the abnormality notification from a client etc. can be considered, for example.

FIG. 16 shows an example of a part describing a response to a server command.
Also in this example, as in the case of FIG. 14, the value of the “X-SOAP-Type” header in the entity header portion is described as “Response”, so that the SOAP message described in this part becomes a SOAP response. It is shown that.
Also in this example, the namespace declaration is the same as in the example shown in FIG. In the SOAP header, “98765”, which is the ID of the server command that generated the response, is described as the content of the XML tag of “command ID”. The SOAP body is provided with a “temperature sensor value acquisition Response” tag for indicating that it is a response to the “temperature sensor value acquisition” command, and the content of the command response is described in a lower tag. Here, information on the temperature value indicated by the sensor whose value is requested is described.

  Next, processing executed in the HTTP client 11 having the configuration and functions described above will be described with reference to the flowcharts of FIGS. The processing shown in these flowcharts is performed by the CPU 31 of the HTTP client 11 executing a required control program.

First, FIG. 17 shows a flowchart of basic operations of message collection and distribution processing.
The CPU 31 of the HTTP client 11 starts the process shown in the flowchart of FIG. 17 when the transmission message collection unit 45 tries to read out a client command, a command response, or the like.
First, client command collection processing is performed (S11). This process is a process of collecting client commands to be transmitted from the client command pool 41 to the HTTP server 12, and includes a process of generating a part by a SOAP envelope from the collected data.

Next, server command execution result collection processing, which is a response to the server command, is collected (S12). This process is a process of collecting command responses to be transmitted from the server command pool to the HTTP server 12, and also includes a process of generating a part by a SOAP envelope from the collected data.
Thereafter, the parts generated in the processes of steps S11 and S12 are merged into one, an HTTP request including all the parts is generated (S13), and the HTTP request is transmitted to the HTTP server 12 (S14).
In the processing so far, the CPU 31 functions as the transmission message collection unit 45 in steps S11 and S12, and functions as the HTTP request transmission unit 46 in steps S13 and S14.

Next, an HTTP response is received from the HTTP server 12 as a communication response to the HTTP request (S15). Then, the HTTP body of the received HTTP response is divided into parts (S16). Here, the division into parts is to divide into elements divided by “MIME_boundary”, and here, all parts are divided.
Thereafter, the processes in steps S17 to S19 are repeated for all the parts obtained by the division in order. In this process, it is first determined whether or not the target part is a part describing a server command (S17). If it is a server command, a server command registration process is performed (S18). If it is not a server command, it is a part in which a response to the client command is described, so a response notification process is performed (S19).

After step S18 or S19, the process returns to step S17, and the process is repeated for the next part. Then, when these processes are performed for all the parts, the process shown in the flowchart of FIG. 17 ends.
In the processing so far, the CPU 31 functions as the HTTP response receiving unit 47 in steps S15 and S16, and functions as the received message distribution unit 48 in steps S17 to S19.

Next, the processing shown in the flowchart of FIG. 17 will be described using the flowchart shown in detail one by one.
FIG. 18 is a flowchart showing in more detail the processing of steps S11 to S14 in FIG.

  In this process, the CPU 31 of the HTTP client 11 first sends the contents of the “method name” and “input parameter” of the client command sheet whose “state” is “unsent” from the client command pool 41 to be transmitted. Collected as a command, the contents of “command ID” are also collected as the command ID of the command (S21). The “status” of “unsent” indicates that the command is not yet sent to the HTTP server 12 after the command is generated by the client command generation unit 43, and is transmitted to the HTTP server 12 based on this. You can extract power commands.

  Thereafter, the processing of steps S22 to S24 is repeated for all client commands collected in step S21 in order. In these processes, first, the target client command and its command ID are converted into an XML document in which these pieces of information are included in the SOAP body and the SOAP header, respectively (S22), and a SOAP envelope that becomes a part related to the target command. Is generated (S23). Then, the “status” of the client command sheet describing the target client command is changed to “waiting for response” (S24). The “status” of “waiting for response” indicates that the command has been notified to the HTTP server 12.

  After all of these are completed, the CPU 31 collects the contents of the “output parameter” of the server command sheet whose “state” is “processing completed” from the server command pool 42 as a command response to the server command to be transmitted. The contents of “command ID” are also collected as the command ID of the corresponding server command (S25). The “status” of “processing completed” indicates that the process corresponding to the server command has been generated by the server command execution result generation unit 44 and has not been notified to the HTTP server 12 yet. The command response to be transmitted to the HTTP server 12 can be extracted.

  Thereafter, the processes in steps S26 to S28 are repeated for all command responses collected in step S25 in order. In these processes, first, the target command response and the command ID collected together with the response are converted into an XML document in which these pieces of information are included in the SOAP body and the SOAP header, respectively (S26). This is a process for generating a SOAP envelope (S27). These processes are the same as the processes in steps S22 and S23 except that the objects are different. Then, the “status” of the server command sheet in which the target command response is described is changed to “responded” (S28). The “status” “response completed” indicates that the HTTP server 12 has been notified of the command response.

After all the processes so far are completed, the CPU 31 merges the parts generated in step S23 or S27, generates a multi-part HTTP request as shown in FIG. 11, and transmits it to the HTTP server 12. (S29).
Note that the change of the “state” performed in step S24 or S28 may be performed after the transmission is actually completed. In this way, even if a communication error occurs, the command and command response that were about to be transmitted can be sent again, so that the reliability of the system is improved.
This completes the processing related to the transmission of the HTTP request, and proceeds to the processing corresponding to step S15 and subsequent steps in FIG.

FIG. 19 is a flowchart showing in more detail the processing of step S15 and subsequent steps in FIG. The process subsequent to step S29 in FIG. 18 corresponds to step S31 in this figure.
In this process, the CPU 31 of the HTTP client 11 first waits for reception of an HTTP response to the transmitted HTTP request and receives it from the HTTP server 12 (S31). When this is received, the HTTP body is analyzed and divided into parts (S32).
Thereafter, the processes in steps S33 to S39 are repeated for each part obtained by the division in order.

  In the processing of this part, first, it is determined whether or not the target part is a server command (S33). As described above, since there is a possibility that the HTTP response includes a server command and a response to the client command, it is determined which is the target part. This determination can be made based on whether or not a SOAPAction header exists in the target part, or based on the contents of the X-SOAP-Type header.

  If it is not a server command in step S33, the part is a response to the client command, so the XML document of the part is analyzed and converted into data in a format that can be registered in the client command sheet (S34). A client command corresponding to the command response is searched, and command response data is registered in the item “output parameter” of the client command sheet for the client command (S35). Note that the command response is assumed to have the same command ID as that given at the time of transmission of the client command as the information of “command ID”, and the search for the client command can be performed using this information as a key. .

  When the data registration is completed, the “status” of the client command sheet in which the data is registered is changed to “response received” to indicate that (S36). Then, the notification destination registered in the “client command execution result notification destination” is notified that a response has been received (S37). By this notification, the application or the like that generated the client command can recognize that there is a response to the generated command and can perform processing according to the response.

For example, when an application that issues an abnormality notification generates a client command for notifying the HTTP server 12 of an abnormality, when this command is transmitted to the HTTP server 12, the HTTP server 12 receives a command response indicating that it has been correctly received. Will return. Upon receiving this command response, the HTTP client 11 searches for a client command based on the command ID included therein, and registers the command response in association with the found client command. . Then, it notifies the application that issued the abnormality notification that is registered as the execution result notification destination of the command that there was a response. If the application receives this notification and refers to the client command sheet, the application can acquire the execution result of the generated command from the “output parameter” item.
When the processing up to step S37 is completed, if there is a next part, the processing from step S33 is repeated for that part.

  On the other hand, if it is a server command in step S33, the XML document of the part is analyzed and converted into data in a format that can be registered in the server command sheet (S38), and a server command sheet corresponding to the server command is created, It is registered in the server command pool together with the command ID (S39). Here, the contents of the server command are registered in the “method name” and “input parameter” items of the server command sheet, and the command ID described in the part is registered in the “command ID” item. In addition, in the item “notification destination of server command”, reference information to an application that executes a method stored in “method name”, information on a correspondence relationship between a prepared method and the application, etc. Refer to and register. The initial value of “state” is “unprocessed”, and the initial value of “output parameter” is NULL.

When the process up to step S39 is completed, if there is a next part, the process from step S33 is repeated for that part.
When the processes of steps S33 to S39 are completed for all parts, the process shown in the flowchart of FIG. 19 is terminated.
By performing the processing as described above, the HTTP client 11 can collectively transmit the operation request to be transmitted to the HTTP server 12 and the operation response to the operation request received from the HTTP server 12 to the HTTP server 12. . Further, the operation request from the HTTP server 12 and the operation response to the operation request transmitted to the HTTP server 12 can be collectively received from the HTTP server 12 and processed.

In this example, all parts to be transmitted are generated and then merged for transmission, and all parts are received and then divided into each part for processing. There is no need to do this.
As for transmission, first, an HTTP header may be transmitted, and thereafter each time a part is generated, the part is sequentially transmitted, and data indicating that is transmitted when transmission of all parts is completed. Even in this case, if the data transmitted in these processes is one logically continuous HTTP request having only one HTTP header, it can be transferred in one session, and the negotiation process is performed once. Therefore, the same effect as when merging and transmitting can be obtained. In addition, since the memory capacity required for the buffer for data to be transmitted can be reduced, large data can be handled by a low-cost communication device.
Also, the receiving side can sequentially perform the processes related to each part each time each part is received. In this case, the capacity can be reduced as in the case of the transmission side.

Next, processing related to execution of the server command will be described.
FIG. 20 is a flowchart showing an example of this process.
As processing related to the execution of the server command, it is conceivable that the processing shown in the flowchart of FIG. 20 is performed after the processing of step S39 shown in FIG. 19, that is, immediately after the server command is registered in the server command pool 42. . In this process, the CPU 31 of the HTTP client 11 functions as the server command execution result generating unit 44.

In this process, first, an application is called based on the “server command notification destination” information in the server command sheet for the registered server command, and the “method name” and “input parameter” data is passed to the server. Processing related to the command is executed (S41). The processing related to the server command is not shown in this flowchart, but is executed separately by the CPU 31.
When this is completed, the execution result is registered in the “output parameter” item of the server command sheet (S42), and the “status” of the server command sheet is changed to “processing completed” to indicate that the processing is completed. (S43), the processing returns to the original processing of FIG.
By performing the above processing, the server command can be executed, and the result can be sent to the HTTP server 12 as a command response.

Further, as a process related to the execution of the server command, it may be considered that the process shown in FIG. 21 is executed independently of the process shown in FIG. Also in this process, the CPU 31 of the HTTP client 11 functions as the server command execution result generation unit 44.
In this case, the CPU 31 starts processing shown in the flowchart of FIG. 21 at an appropriate timing.

In this process, first, it is determined whether or not there is a server command sheet having a “status” of “waiting for processing” in the server command pool (SX1), and if not, the server command pool waits until such a server command sheet is added. To do. When such a server command sheet is found, one of them is set as a processing target, and the “status” of the server command sheet is changed to “processing” (SX2).
Thereafter, the processing of steps S41 to S43 similar to the case of FIG. 20 is performed to execute the server command described in the server command sheet to be processed, and when this is completed, the processing returns to step SX1 and the processing is repeated.

  The above processing may be performed simultaneously by a plurality of threads (for example, 4 threads). Since the “state” of the server command sheet that is the processing target is not “waiting for processing”, even if processing is performed simultaneously by a plurality of threads, one server command sheet is not redundantly processed.

If the processing as described above is performed, the server command can be executed at an arbitrary timing. Therefore, even if there is a command that takes time to execute, the subsequent processing is not delayed. Then, in order from the end of execution, the result can be sent to the HTTP server 12 as a command response.
Above, description of the process regarding the transfer of each command and command response executed in the HTTP client 11 is completed.

Next, the functional configuration on the HTTP server 12 side will be described. As hardware, as described with reference to FIG. 7, the same hardware as the HTTP client 11 can be used. Accordingly, in the description of the HTTP server 12 below, the same reference numerals as those of the HTTP client 11 are used when referring to hardware components.
FIG. 22 is a functional block diagram showing a configuration of functions for performing processing related to commands and command responses among the functions of the HTTP server 12.
Among the functions shown in FIG. 22, the server command pool 141 and the client command pool 142 are provided in any rewritable storage means. For example, it can be provided in the SD card 34, but may be provided in the RAM 33 or an HDD (hard disk drive) (not shown). The functions of the server command generation unit 143, the client command execution result generation unit 144, the transmission message collection unit 145, and the reception message distribution unit 148 are realized by the CPU 31. The functions of the HTTP response transmission unit 146 and the HTTP request reception unit 147 are realized by the CPU 31 and the NIC 35.

These functions will be described in further detail.
First, the server command pool 141 corresponds to a second storage area provided in the HTTP server 12, and is a pool that registers a server command, a response to the command, and identification information of the command in association with each other. The client command pool 142 corresponds to a first storage area provided in the HTTP server 12, and is a pool that registers a client command, a response to the command, and identification information of the command in association with each other. Further, it is assumed that the storage means provided with these pools correspond to the second and first storage means of the HTTP server 12, respectively.

  The server command generation unit 143 corresponds to a request generation unit. Then, a server command is generated, identification information (ID) for identifying this command is assigned, management information for managing this command is added, and the server command is associated with these information as a server command sheet in a table format. It has a function of registering in the pool 141. Among these, for example, an application provided in the HTTP server 12 corresponds to a part that generates a server command. In addition, the server command generation unit 143 may be provided with a function to be added to the server command that has generated a priority order for causing the HTTP client 11 to execute each command.

FIG. 23 shows an example of the data structure in the server command sheet of the HTTP server 12.
As shown in this figure, the server command sheet of the HTTP server 12 is slightly different in that the command described in the server command sheet is a server command and the transmission destination and the transmission source of the command response are the HTTP client 11. However, an area for storing data similar to the client command sheet of the HTTP client 11 shown in FIG. 9 is provided. As for “notification destination of server command execution result”, although the name of the item differs according to the fact that the command described in this sheet is a server command, the content is “notification destination of client command execution result” in FIG. Is the same.

  Returning to the description of FIG. 22, the client command execution result generating unit 144 corresponds to a response generating unit. The client command is an application that reads and executes a client command from the client command pool 142. Then, it has a function of generating a response to the client command and registering it in the client command pool 142 in association with the command ID of the client command. The client command received from the HTTP client 11 is registered in the client command pool 142 as a client command sheet in a table format in association with an ID for identifying this command and management information for managing this command. ing. The command response generated by the client command execution result generation unit 144 is also registered in the client command sheet for the executed client command.

In addition, it is conceivable that the client command execution result generation unit 144 has a function of reading a plurality of types of client commands from the client command pool 142 and generating a response to each client command. Furthermore, when the client command includes information on the execution priority for causing the HTTP server 12 to execute the processing with priority, it is possible to provide a function of preferentially reading and executing the information from the highest priority.
The client command execution result generating unit 144 may be a module that calls an application necessary for executing the client command and executes the command instead of the application itself.

Here, FIG. 24 shows an example of the data structure in the client command sheet of the HTTP server 12.
As shown in this figure, the client command sheet of the HTTP server 12 is slightly different in that the command described in the client command sheet is a client command and the transmission source or the transmission destination of the command response is the HTTP client 11. However, an area for storing data similar to the server command sheet of the HTTP client 11 shown in FIG. 10 is provided. The “client command notification destination” has the same name as the “server command notification destination” in FIG. 10, although the item names differ depending on the fact that the command described in this sheet is a server command. It is.

Returning to the description of FIG. 22 again, the transmission message collecting means 145 corresponds to the collecting means. Then, the command response generated by the client command execution result generating unit 144 and the command ID of the client command corresponding to this command response are read out from the client command pool 42, and the server command generated by the server command generating unit 143 and this It has a function of reading from the server command pool 141 in association with the command ID of the command and generating a transmission message therefrom.
Note that when the execution priority is specified in the command response or the server command, it is conceivable that the transmission message collection unit 145 reads the messages in descending order of execution priority.
The format of the transmission message is the same as that of the HTTP client 11.

The HTTP response transmission unit 146 corresponds to the transmission unit, generates an HTTP response including the transmission message generated by the transmission message collection unit 145 as a communication response to the HTTP request received from the HTTP client 11, and transmits the HTTP response to the HTTP client 11. It has a function to transmit. At this time, any number of transmission messages may be included in one HTTP response, and a transmission message related to a command response and a transmission message related to a server command may be arbitrarily mixed.
Therefore, the HTTP response transmission unit 146 transmits all the transmission messages generated by the transmission message collection unit 145 in one HTTP response regardless of any of the transmission messages. However, an upper limit may be set for the number of transmission messages included in one HTTP response.

By the way, the HTTP response is transmitted when the transmission message collecting means 145 attempts to read out a server command, a command response, etc., even when there is no data to be read and a SOAP message to be transmitted as a result is not generated. Is what you do. This reading attempt is performed when an HTTP request from the HTTP client 11 is received.
This is because the HTTP request cannot be transmitted from the HTTP server 12 across the firewall 14 to the HTTP client 11 as described above.

The HTTP request receiving unit 147 corresponds to a receiving unit and has a function of receiving an HTTP request from the HTTP client 11. In the HTTP request, a client message and a received message including a command ID associated with the command are arbitrarily mixed with a received message including a response to the server command and a command ID associated with the command. Included.
Here, the received message is a message in which the above command, response, and command ID are described as a SOAP message.

The received message distribution unit 148 corresponds to a distribution unit. The HTTP request receiving unit 147 has a function of distributing and registering data included in the HTTP request received in the server command pool 141 and the client command pool 142.
Specifically, a client command and a command ID associated with the command are registered in the client command pool 142 by providing a client command sheet, and for a response to the server command, the command ID associated with the command is stored in the server The corresponding server command is identified by comparing with the command ID of the server command sheet stored in the command pool 141, and registered as an “output parameter” for the server command.

At this time, the HTTP request is divided and each received message included therein is extracted, and the data is converted into a format necessary for registration in the table. This conversion is a required conversion generated based on WSDL. This can be done by executing a program (deserializer).
Since the HTTP request received by the HTTP server 12 having such a function is transmitted from the HTTP client 11, it has been described with reference to FIG. 11 in the description of the function of the HTTP client 11, for example. Since the HTTP response transmitted by the HTTP server 12 is also transmitted to the HTTP client 11 and received by the HTTP client 11, it has been described with reference to FIG. 12, for example. The contents of the parts included in these are also as described with reference to FIGS.

  Next, processing executed in the HTTP server 12 having the configuration and functions described above will be described with reference to the flowcharts of FIGS. The processing shown in these flowcharts is performed by the CPU 31 of the HTTP server 12 executing a required control program.

First, FIG. 25 shows a flowchart of basic operations of message collection and distribution processing.
When the HTTP request is transmitted from the HTTP client 11, the CPU 31 of the HTTP server 12 starts the process shown in the flowchart of FIG. 25.
First, the HTTP request is received (S111). Then, the HTTP body of the received HTTP request is divided into parts (S112). Here, the division into parts is to divide into elements divided by “MIME_boundary”, and here, all parts are divided.

  Thereafter, the processes in steps S113 to S115 are repeated for all the parts obtained by the division in order. In this process, it is first determined whether or not the target part is a part describing a client command (S113). If it is a client command, a client command registration process is performed (S114). If the command is not a client command, a response notification process is performed because the response to the server command is described (S115).

After step S114 or S115, the process returns to step S113, and the process is repeated for the next part. Then, when these processes are performed for all the parts, the process proceeds to the next step S116.
In the processing so far, the CPU 31 functions as the HTTP request receiving unit 147 in steps S111 and S112, and functions as the received message distribution unit 148 in steps S113 to S115.

Next, the CPU 31 performs server command collection processing (S116). This process is a process of collecting server commands to be transmitted from the server command pool 41 to the HTTP client 11, and includes a process of generating a part by a SOAP envelope from the collected data.
Next, the client command execution result collection process, which is a response to the client command, is collected (S117). This process is a process of collecting command responses to be transmitted from the client command pool to the HTTP client 11, and also includes a process of generating a part by a SOAP envelope from the collected data.

Thereafter, the parts generated in the processes of steps S116 and S117 are merged into one to generate an HTTP response including all the parts (S118), and the HTTP response is used as a communication response to the HTTP request received in step S111. The data is transmitted to the HTTP client 11 (S119), and the process is terminated.
In the processing so far, the CPU 31 functions as the transmission message collection unit 145 in steps S116 and S117, and functions as the HTTP response transmission unit 146 in steps S118 and S119.

Next, the processing shown in the flowchart of FIG. 25 will be described using the flowchart shown in more detail one by one.
FIG. 26 is a flowchart showing in more detail the processing of steps S111 to S115 in FIG.
In this process, the CPU 31 of the HTTP server 12 first receives an HTTP request transmitted from an HTTP client (S121). When this is received, the HTTP body is analyzed and divided into parts (S122).
Thereafter, the processes in steps S123 to S129 are repeated for each part obtained by the division in order.

  In the processing of this part, first, it is determined whether or not the target part is a client command (S123). As described above, since there is a possibility that the HTTP request includes a client command and a response to the server command, it is determined which is the target part. This determination can be made based on whether or not a SOAPAction header exists in the target part, or based on the contents of the X-SOAP-Type header.

  If it is not a client command in step S123, the part is a response part to the server command, so the XML document of the part is analyzed and converted into data in a format that can be registered in the server command sheet (S124). The server command corresponding to the command response is searched from 141, and the command response data is registered in the “output parameter” item of the server command sheet for the server command (S125). The command response is assumed to have the same command ID as that given at the time of transmission of the server command as information of “command ID”, and the search for the server command can be performed using this information as a key. .

  When the data registration is completed, the “status” of the server command sheet in which the data is registered is changed to “response received” to indicate that (S126). Then, it notifies the notification destination registered in “notification destination of server command execution result” that there is a response (S127). By this notification, the application or the like that generated the server command can recognize that there is a response to the generated command, and can perform processing according to the response.

For example, when an application corresponding to the occurrence of an abnormality in the HTTP client 11 generates a server command for acquiring the sensor value of the temperature sensor of the HTTP client 11, when this command is transmitted to the HTTP client 11, the HTTP client 11 requests A command response including the sensor value is returned. Upon receiving this command response, the HTTP server 12 searches for a server command based on the command ID included therein, and registers the command response in association with the found server command. . Then, the application corresponding to the occurrence of the abnormality registered as the command execution result notification destination is notified of the response. If the application receives this notification and refers to the server command sheet, the application can acquire the execution result of the generated command from the “output parameter” item.
When the processing up to step S127 is completed, if there is a next part, the processing from step S123 is repeated for that part.

  On the other hand, if it is a client command in step S123, the XML document of the part is analyzed and converted into data in a format that can be registered in the client command sheet (S128), and a client command sheet corresponding to the client command is created, It is registered in the client command pool together with the command ID (S129). Here, the contents of the client command are registered in the “method name” and “input parameter” items of the client command sheet, and the command ID described in the part is registered in the “command ID” item. In addition, in the item “client command notification destination”, reference information to an application that executes a method stored in “method name”, information on a correspondence relationship between a prepared method and the application, etc. Refer to and register. The initial value of “state” is “unprocessed”, and the initial value of “output parameter” is NULL.

When the processing up to step S129 is completed, if there is a next part, the processing from step S123 is repeated for that part.
When the processing of steps S123 to S129 is completed for all parts, the processing shown in the flowchart of FIG.
This completes the processing related to the reception of the HTTP request, and proceeds to processing corresponding to step S116 and subsequent steps in FIG.

FIG. 27 is a flowchart showing in more detail the processing of step S116 and subsequent steps in FIG. The processing subsequent to step S127 or S129 in FIG. 26 corresponds to step S131 in this figure.
In this process, the CPU 31 of the HTTP server 12 first sends the contents of the “method name” and “input parameter” of the server command sheet whose “state” is “unsent” from the server command pool 141 to be transmitted. Collected as a command, the contents of “command ID” are also collected as the command ID of the command (S131). In the HTTP server 12, the “state” of “unsent” indicates that the command has not yet been notified to the HTTP client 11 after the command is generated by the server command generation unit 143. A command to be transmitted to the HTTP client 11 can be extracted.

  Thereafter, the processes in steps S132 to S134 are repeated for all the server commands collected in step S131 in order. In these processes, first, the target server command and its command ID are converted into an XML document in which these pieces of information are included in the SOAP body and the SOAP header, respectively (S132), and a SOAP envelope which becomes a part related to the target command. Is generated (S133). Then, the “status” of the server command sheet describing the target server command is changed to “waiting for response” (S134). Here, the “status” of “waiting for response” indicates that the command has been notified to the HTTP client 11.

  After all of these are completed, the CPU 31 collects the contents of the “output parameter” of the client command sheet whose “state” is “processing completed” from the client command pool 142 as a command response to the client command to be transmitted. The contents of “command ID” are also collected as the command ID of the corresponding client command (S135). In the HTTP server 12, the “status” of “processing completed” indicates that the processing corresponding to the client command has been generated by the client command execution result generating unit 144 and has not yet been notified to the HTTP client 11. Therefore, the command response to be transmitted to the HTTP client 11 can be extracted based on this.

  Thereafter, the processes in steps S136 to S138 are repeated with all command responses collected in step S135 as targets. In these processes, first, the target command response and the command ID collected together with the response are converted into XML documents in which these pieces of information are included in the SOAP body and the SOAP header (S136). This is a process for generating a SOAP envelope (S137). These processes are the same as the processes in steps S132 and S133 except that the objects are different. Then, the “status” of the client command sheet that describes the target command response is changed to “response completed” (S138). The “status” of “response completed” indicates that the command response has been notified to the HTTP client 11 here.

After all the processes so far are completed, the CPU 31 merges the parts generated in step S133 or S137, generates a multi-part HTTP response as shown in FIG. 12, and transmits it to the HTTP client 11. .
Note that the change of the “state” performed in step S134 or S138 may be performed after the transmission is actually completed. In this way, even if a communication error occurs, the command and command response that were about to be transmitted can be sent again, so that the reliability of the system is improved.

  In this example, all parts to be transmitted are generated and then merged for transmission, and all parts are received and then divided into each part for processing. There is no need to do so. As in the case of the HTTP client 11, it is possible to sequentially transmit each time each part is generated, or to sequentially perform processing relating to each part each time each part is received.

Next, processing related to execution of a client command will be described.
FIG. 28 is a flowchart showing an example of this process.
As processing related to the execution of the client command, it is conceivable that the processing shown in the flowchart of FIG. 28 is performed after the processing of step S129 shown in FIG. 27, that is, immediately after the client command is registered in the client command pool 42. . In this process, the CPU 31 of the HTTP server 12 functions as the client command execution result generation unit 144.

  In this process, first, an application is called based on the “client command notification destination” information in the client command sheet for the registered client command, and the “method name” and “input parameter” data is passed to the client command sheet. Processing related to the command is executed (S141). The processing related to the client command is not shown in this flowchart, but is executed separately by the CPU 31.

When this is completed, the execution result is registered in the “output parameter” item of the client command sheet (S142), and the “status” of the client command sheet is changed to “processing completed” to indicate that the processing is completed. (S143), the process returns to the original process of FIG.
By performing the above processing, the client command can be executed, and the result can be sent to the HTTP client 11 as a command response.

In addition, as processing related to the execution of the client command, it is conceivable to execute the processing shown in FIG. 29 independently of the processing shown in FIG. Also in this process, the CPU 31 of the HTTP server 12 functions as the client command execution result generation unit 144.
In this case, the CPU 31 starts processing shown in the flowchart of FIG. 29 at an appropriate timing.

In this process, first, it is determined whether or not there is a client command sheet whose “status” is “waiting for processing” in the client command pool (SY1), and if not, wait until such a client command sheet is added. To do. When such a client command sheet is found, one of the client command sheets is set as a processing target, and the “status” of the client command sheet is changed to “processing” (SY2).
Thereafter, the same processing of steps S141 to S143 as in the case of FIG. 28 is performed to execute the client command described in the client command sheet to be processed. When this is completed, the processing returns to step SY1 and the processing is repeated.
The above processing may be performed simultaneously by a plurality of threads as in the case of the HTTP client 11.

If the processing as described above is performed, the client command can be executed at an arbitrary timing. Therefore, even if there is a command that takes time to execute, the subsequent processing is not delayed. Then, in order from the end of execution, the result can be sent to the HTTP client 11 as a command response.
Above, description of the process regarding the transfer of each command and command response executed in the HTTP server 12 is completed.

  The HTTP client 11 and the HTTP server 12 are provided with each function as described above, and by performing each process, an operation request to be transmitted from the transmission source to the communication partner and an operation for the operation request received from the communication partner. Responses can be sent to the communication partner in a batch, so there is no need to negotiate separately for transmission of operation requests and transmission of operation responses to establish communication connections, reducing communication overhead. Communication efficiency.

The reason why the operation request and the operation response can be transmitted in a batch is that they are converted into serialized data and converted into a transmission message described in a structured language format. In this way, operation requests and operation responses having different formats can be easily combined and transmitted as one transmission content logically.
In this way, the receiving side also receives the operation response to the operation request transmitted to the communication partner and the operation request from the communication partner at the same time, and easily separates the received content into individual messages. However, appropriate processing can be performed depending on whether it is an operation request or an operation response.

  Further, if a communication request is always issued from one device and communication is performed, and an operation request or the like is transmitted from the communication partner to the communication request source as a response to the communication request, the communication request issuing side Even in a communication system in which a device (communication client) is provided inside a firewall, it is possible to send and receive operation requests and responses without being aware of the presence of the firewall. In addition, since the communication request and the communication response correspond to each other, timing management at the communication level is easy.

In this case, if the communication request is periodically transmitted from the one device to the communication partner, the information transmission from the outside to the inside of the firewall is stagnated for a long time. Can be prevented.
In addition, by creating a client command pool or server command pool and storing operation requests and response generated by each application in these pools, the generation of operation requests and response can be made to the communication partner. This can be done without considering the transmission timing. Therefore, processing performed by an application or the like can be simplified, and design and development are facilitated.

Even in such a case, by providing a collection means for reading out an operation request or an operation response to be transmitted to a communication partner from the pool, information to be transmitted can be transmitted without omission when performing communication.
Also, by providing distribution means for separating received operation requests and responses and storing them in an appropriate pool, the received information is stored in the pool, so that the operations related to the received operation requests are executed. In addition, the processing after receiving the operation response can be performed without considering the reception timing from the communication partner. Therefore, processing performed by an application or the like can be simplified, and design and development are facilitated.

Also, identification information such as an ID is attached to the generated operation request so that the operation request is associated with the identification information when the operation request is stored and transmitted, and an operation corresponding to the operation response is also stored and transmitted. If it is performed in association with the identification information of the request, even when a plurality of operation requests and responses are included in one message (here, an HTTP message), the correspondence between the operation request and the operation response via the identification information. Can be easily recognized.
In addition, if priority is given to operation requests, and execution is performed in order from the highest, or responses are transmitted, urgent operations are preferentially executed and responses are also preferentially returned. Can do.

[Reference example when adopting SMTP: FIGS. 30 to 35]
Next, a reference example when adopting SMTP as a communication protocol will be described. This reference example has much in common with the above-described embodiment in which HTTP is adopted, so the description of the common points will be omitted or simplified, and the differences will be mainly described.
First, FIG. 30 shows a configuration example of a communication system to which a reference example in the case of adopting SMTP is applied.

  In this communication system, as shown in FIG. 30, LAN_A connecting communication apparatus A and mail server A ′, and LAN_B connecting communication apparatus B and mail server B ′ are respectively connected to firewall A and firewall B. It is connected to the Internet 13 through the network. In addition, a mail server A is provided on the LAN_A side and a mail server B is provided on the LAN_B side at positions accessible from the outside through a firewall. The communication device A corresponds to the first communication device, and the communication device B corresponds to the second communication device.

  When communication is performed using SMTP, information transfer between the communication device A and the communication device B is performed by electronic mail. For example, when information is transmitted from the communication device B to the communication device A, the communication device B transmits an e-mail addressed to the communication device A as shown by a broken line in FIG. Send to '. Then, the e-mail is transferred to the mail server A ′ that is directly accessed by the communication device A through the mail servers B ′, B, and A sequentially. Although not shown in the figure, usually, transfer is performed between the mail server B and the mail server A via another mail server.

  Then, as indicated by the alternate long and short dash line, the communication device A periodically accesses the mail server A ′, so that an electronic mail addressed to the communication device A can be received. Information transfer is completed. Information transfer from the communication device A to the communication device B can be performed in the reverse procedure, and the communication device A and the communication device B are symmetrical with respect to the information transfer. However, providing the mail servers A ′ and B ′ is not essential, and the communication device A may directly communicate with the mail server A, and the communication device B may directly communicate with the mail server B. Also, the mail server for receiving mail and the mail server for transmitting mail may be different.

In such a communication system, each LAN is provided with a mail server at a location accessible from the outside, so that an electronic mail can be transferred across the firewall.
In this reference example, communication apparatus A and communication apparatus B do not communicate with each other after directly negotiating, but it is possible to transfer information between each other.

  Further, similarly to the first communication device and the second communication device shown in FIG. 1, the communication device A and the communication device B also have an application program for performing mutual control management. Then, by RPC, it is possible to transmit an “operation request” that is a request for processing for a method of an application program to be installed, and to acquire an “operation response” that is a result of the requested processing. Yes.

  FIG. 31 shows the relationship between these operation requests and operation responses. At the operation request level, the relationship between the communication device A and the communication device B is the same as the relationship between the HTTP client 11 and the HTTP server 12 already described. It is symmetrical. However, in the case of SMTP, the communication device A and the communication device B have a symmetrical relationship even at the communication level, which is different from the case of HTTP.

FIG. 32 shows an example of a communication sequence in this communication system.
As described above, in this communication system, communication between the communication device A and the communication device B is performed using electronic mail. An electronic mail has a transmission source and a destination, and it is possible to send a reply from the destination to the transmission source. However, the first electronic mail and the reply are completely independent, and there is no relationship between the communication request and the communication response as in the case of HTTP.
Accordingly, communication may be performed first from either communication device, and it is not necessary to send e-mails alternately. Here, e-mail is first sent from communication device A to communication device B. An example in the case of sending and sending and receiving a total of three e-mails alternately is shown.

In these electronic mails, an operation request (command) for a transmission destination (destination) and an operation response (command response or simply “response”) to a command received from the transmission destination are described and transmitted. This is the same regardless of which of the communication devices A and B is the transmission source.
Therefore, for example, the command a on the communication device A side can be described and transferred in the electronic mail x, and the command response from the communication device B can be described and transferred in the subsequent electronic mail y. Further, the communication device B side command c can be described and transferred in the electronic mail y, and the command response from the communication device A can be described and transferred in the subsequent electronic mail z.

Note that an arbitrary number (or 0) of responses to the operation request and the operation response can be described in one e-mail. The content described in one e-mail is one message, and naturally it is logically transferred collectively. In this way, the number of e-mails for transferring necessary information is reduced, overhead is reduced, and communication efficiency is improved.
Similarly to the HTTP described with reference to FIG. 6, the command response need not be described in the first e-mail sent after receiving the command.

  Next, a functional configuration for performing a process of combining and separating commands and command responses in the communication apparatus A and the communication apparatus B and a procedure of the process will be described. As for the hardware configuration, the same configuration as that of the HTTP client 11 shown in FIG. 7 in the description of the embodiment using HTTP can be used.

FIG. 33 is a functional block diagram corresponding to FIG. 8 showing a configuration of functions for performing processing related to commands and command responses among the functions of the communication apparatus A.
33, the communication device A side command pool 51, the communication device B side command pool 52, the communication device A side command generation means 53, and the communication device B side command execution result generation means 54 are respectively shown in FIG. This function corresponds to the client command pool 41, the server command pool 42, the client command generation means 43, and the server command execution result generation means 44, and the names are changed due to different names of the devices.

The transmission message collection unit 45 and the reception message distribution unit 48 correspond to the units having the same names shown in FIG. However, it differs from the example shown in FIG. 8 in that the format of data for transmission and reception is a format corresponding to SMTP. However, individual SOAP messages corresponding to commands and command responses are the same as those in FIG.
The mail transmission unit 56 and the mail reception unit 57 correspond to the transmission unit and the reception unit, respectively. However, the HTTP request transmission unit 46 and the HTTP response reception unit illustrated in FIG. 47 is different.

  That is, the mail transmission unit 56 has a function of generating an electronic mail addressed to the communication apparatus B including the transmission message generated by the transmission message collecting unit 45 and transmitting the electronic mail to the mail server A ′. Note that the communication device A is not involved in the subsequent transfer of electronic mail. Further, FIG. 8 shows that any number of transmission messages may be included in one electronic mail, and transmission messages related to command responses and transmission messages related to commands on the communication apparatus A side can be arbitrarily mixed. This is the same as in the example.

  The mail receiving means 57 has a function of periodically accessing the mail server A ′ to check whether there is a new mail addressed to the communication apparatus A and receiving it when there is a new mail. And here, the received e-mail includes a received message including the communication device B side command and a command ID associated with the command, a response to the communication device A side command and a command ID associated with the command. Messages are arbitrarily mixed and included.

Next, FIG. 34 shows an example of an electronic mail that the communication apparatus A having such a function transmits to the communication apparatus B.
In this e-mail, as in the case of the HTTP request shown in FIG. 11, a multipart message according to MIME (Multipurpose Internet Mail Extension) is described as a body part, and a SOAP envelope is embedded in each part. It is. That is, the body portion is the same as that in the HTTP request.

However, unlike the HTTP request, the header portion describes information such as From indicating the source address of the e-mail, To indicating the destination address, and Subject indicating the title.
The e-mail transmitted from the communication device B to the communication device A is obtained by replacing the contents of From and the contents of To in the header.
Further, the contents of the SOAP envelope described in these electronic mails are the same as those in the case of the HTTP request or the HTTP response. However, the part of the entity header of each part is partially different from that of HTTP because the data encoding method is different.

  Next, processing executed in the communication apparatus A having the configuration and functions described above will be described with reference to the flowcharts of FIGS. The processing shown in these flowcharts is performed by the CPU of the communication apparatus A executing a required control program.

First, FIG. 35 shows a flowchart of the basic operation of processing at the time of message transmission.
The CPU of the communication apparatus A starts the process shown in the flowchart of FIG. 35 when the transmission message collection unit 45 tries to read out the communication apparatus A side command, command response, and the like.
First, the communication device A side command collection processing is performed (S51). This process is a process of collecting communication apparatus A side commands to be transmitted from the communication apparatus A side command pool 51 to the communication apparatus B, and includes a process of generating a SOAP envelope part from the collected data.

Next, the communication device B side command execution result collection process, which is a response to the communication device B side command, is collected (S52). This process is a process of collecting command responses to be transmitted from the communication apparatus B-side command pool 52 to the communication apparatus B, and also includes a process of generating a SOAP envelope part from the collected data.
Thereafter, the parts generated in the processes of steps S51 and S52 are merged into one to generate an e-mail including all the parts (S53), and the e-mail is transmitted to the communication device B (S54). The process is terminated.

In the above processing, the CPU 31 functions as the transmission message collecting unit 45 in steps S51 and S52, and functions as the mail transmission unit 56 in steps S53 and S54.
These processes correspond to the processes of steps S11 to S14 shown in FIG. 17, but in the case of SMTP, there is a relationship such as a communication request and a communication response between the transmission and reception of an e-mail. Therefore, the processing ends here, and when an electronic mail is received, the processing shown in FIG. 36 is separately performed.

FIG. 36 shows a flowchart of the basic operation of processing at the time of message reception.
The CPU of the communication device A periodically accesses the mail server A ′, and when there is a new e-mail addressed to the communication device A, it starts the process shown in the flowchart of FIG.
In this process, first, a new email is received (S61). Then, the body (text) of the received e-mail is divided into parts (S62). Here, the division into parts is to divide into elements divided by “MIME_boundary”, and here, all parts are decomposed.

  Thereafter, the processes in steps S63 to S65 are repeated for all parts in order. In this process, first, it is determined whether or not the target part is a part describing a communication device B side command (S63). And if it is a communication apparatus B side command, a communication apparatus B side command registration process will be performed (S64). If the command is not the communication device B side command, the response notification process is performed because the response is a part describing the response to the communication device A side command (S65).

After step S63 or S64, the process returns to step S63, and the process is repeated for the next part. Then, when these processes are performed for all the parts, the process shown in the flowchart of FIG. 36 ends.
In the above processing, the CPU 31 functions as the mail receiving means 57 in step S61, and functions as the received message distribution means 48 in steps S62 to S65.
These processes correspond to the processes in steps S15 to S19 shown in FIG.

The processing related to the execution of the communication apparatus B side command is the same as the processing related to the execution of the server command described with reference to FIGS.
Above, description of the process regarding the transfer of each command and command response performed in the communication apparatus A is completed.
Note that the functions of the communication device B and the processing executed in the communication device B are exactly the same as those of the communication device A except that the meanings of the communication device A side command and the communication device B side command are reversed. Therefore, explanation is omitted.

As described above, the present invention can also be applied to a case where communication is performed using a protocol that does not necessarily correspond to transmission and return of information, such as SMTP. Also in this case, the operation request to be transmitted from the transmission source to the communication partner and the operation response to the operation request received from the communication partner can be transmitted to the communication partner in a lump. And the transmission of the operation response need not be transferred in separate units, and communication overhead can be reduced and communication efficiency can be increased.
If e-mail is used for communication, information can be easily transferred to the inside of the firewall.

[Modification of Example and Reference Example: FIG. 37]
Next, modified examples of the above-described embodiment and reference example will be described.
First, in the above-described embodiments and reference examples, the present invention has been described by taking a communication system including two communication devices as an example in order to simplify the description. However, the present invention is not limited to communication systems including more communication devices. Of course, it is also possible to apply to the communication apparatus which comprises such a communication system.
For example, the embodiment in the case of adopting HTTP can be applied to a communication system as shown in FIG.

This communication system connects a management apparatus 102, which is a communication apparatus having a communication function, and a managed apparatus 100, which is also a communication apparatus having a communication function, via a network including the Internet 13, and the management apparatus 102 The remote management system is configured to manage the managed device 100.
Here, specific examples of the managed device 100 include image processing devices such as printers, scanners, copiers, and digital multifunction devices having these functions, as well as network home appliances and vending machines having communication functions. Various electronic devices having a communication function are conceivable, including medical devices, power supply devices, air conditioning systems, measuring systems such as gas, water, and electricity, and computers that can be connected to a network.

In this remote management system, an intermediary device 101 that is a communication device that mediates communication between the management device 102 and the managed device 100 is provided, and the management device 102 and the managed device 100 are connected to this intermediary device. Communication is performed via 101.
The intermediary device 101 and the managed device 100 have various hierarchical structures depending on the usage environment. For example, in the installation environment A shown in FIG. 37, the intermediary device 101a that can establish a connection with the management device 102 by HTTP has a simple hierarchical structure that follows the managed devices 100a and 100b. Since only one managed device 100 is installed, the load increases only by installing one intermediary device 101.

  Therefore, the mediation device 101b that can establish an HTTP connection with the management device 102 follows not only the managed devices 100c and 100d, but also another mediation device 101c, and this mediation device 101c further follows the managed devices 100e and 100f. A hierarchical structure is formed. In this case, the information issued from the management device 102 for remotely managing the managed devices 100e and 100f is sent via the mediation device 101b and the mediation device 101c, which is a lower node thereof, to the managed device 100e or 100f. Will be reached. Note that a firewall 14 is installed in each installation environment in consideration of security.

Even in such a remote management system, the present invention can be applied by treating the intermediary device 101 as an HTTP client and the management device 102 as an HTTP server.
In this case, when a command is to be transmitted from the management apparatus 102 to the managed apparatus 100, a command “send a command to the managed apparatus 100” is transmitted to the mediation apparatus 101, and the command is It is conceivable that a command is transmitted to the managed device 100 as an operation. In addition, a command is transmitted to the mediation device 101 by designating one of the managed devices 100 as a destination, and the mediation device 101 is caused to transfer a command destined for other than itself to the destination. Is also possible.

In addition, when sending and receiving commands and command responses between three or more nodes, this information is also included in the command and command response messages so that the source and destination of the commands can be identified. It is better to manage it by describing it.
In addition, if a mail server is provided, a reference example in the case of adopting SMTP can be applied to such a communication system.

Furthermore, modifications other than those described above can be applied to the present invention. For example, a client command sheet and a server command sheet registered in the client command pool 41 and the server command pool 42 may be described as XML documents. The “input parameter” may be saved as an XML document before deserialization, or the “output parameter” may be saved as an XML document after serialization.
Further, there may be a limit on the information amount of commands and command responses to be transmitted / received. In particular, if the amount of information of commands to be received is limited, the amount of memory used can be suppressed when the receiving side is a device with a limited memory capacity.

In the above-described embodiment and reference example, SOAP is adopted as the upper protocol for realizing RPC, and the application directly implements RPC by operating the pool. However, CORBA (Common Application development efficiency may be further improved by providing a bridge (message conversion function) with Object Request Broker Architecture (JAVA) or JAVA (registered trademark) RMI (Remote Method Invocation).
That is, in the embodiment and the reference example described above, the command and the response of the command response between the HTTP client 11 and the HTTP server 12 are performed by a SOAP message described in XML. It is not limited and may be described in other formats.

  In addition, in the above-described embodiment and reference example, not only the SOAP standard protocol but also a unique protocol combining SOAP and MIME multipart is included in the HTTP request or HTTP response. The SOAP envelope will be treated as completely independent, but with the SOAP attachment defined as the SOAP related specification, the SOAP envelope of the first part included in the HTTP response is linked to the SOAP envelope of the second and subsequent parts. You may make it the structure which embeds and links | relates and delivers these. The same applies to the case of electronic mail using SMTP.

Furthermore, as an example of adopting HTTP as an embodiment as a data communication protocol positioned below an upper protocol such as SOAP, the example has been described. However, other protocols such as FTP (File Transfer Protocol) are also used for this lower protocol. May be adopted.
Furthermore, the configuration of the communication system is not limited to that described above.

  The program according to the present invention causes a computer to function as an apparatus such as the HTTP client 11, the HTTP server 12, or the communication apparatuses A and B, which are communication apparatuses that can communicate with other communication apparatuses as communication partners. The above-described effects can be obtained by causing a computer to execute such a program.

Such a program may be stored in a storage means such as a ROM or HDD provided in the computer from the beginning, but a non-volatile recording such as a CD-ROM or flexible disk, SRAM, EEPROM, memory card or the like as a recording medium. It can also be recorded on a medium (memory) and provided. Each procedure described above can be executed by installing a program recorded in the memory in a computer and causing the CPU to execute the program, or causing the CPU to read and execute the program from the memory.
Furthermore, it is also possible to download and execute an external device that is connected to a network and includes a recording medium that records the program, or an external device that stores the program in the storage unit.

As described above, when a communication client, a communication server, a communication system, or a communication method is used, a plurality of communication apparatuses that transmit and receive a communication request and a communication response to the communication request send an operation request to each other and an operation response to the received operation request. In the case of configuring a communication system for transmission and reception, communication efficiency can be increased.
Therefore, by applying the present invention to such a communication system, a communication system with a small communication load can be configured.

It is a figure which shows the structural example of the communication system of this invention. FIG. 2 is a diagram illustrating a relationship between an operation request and an operation response in the communication system illustrated in FIG. 1. It is a figure which shows the structural example of the communication system in the case of employ | adopting HTTP as a communication protocol. FIG. 4 is a diagram illustrating a relationship between an operation request and an operation response in the communication system illustrated in FIG. 3. It is a figure which shows the example of the communication sequence in the communication system shown in FIG. It is a figure which shows the other example. FIG. 4 is a diagram illustrating a hardware configuration example of an HTTP client and an HTTP server illustrated in FIG. 3. It is a functional block diagram which shows the structure of the function for performing the process regarding a command and a command response among the functions of the HTTP client shown in FIG. It is a figure which shows the example of the data structure in the client command sheet memorize | stored in the client command pool shown in FIG. It is a figure which shows the example of the data structure in the server command sheet memorize | stored in the server command pool shown in FIG.

It is a figure which shows the example of the HTTP request which the HTTP client shown in FIG. 3 transmits to an HTTP server. It is a figure which shows the example of the HTTP response which the HTTP client shown in FIG. 3 receives from an HTTP server. It is a figure which shows the example of the part which described the client command. It is a figure which shows the example of the part which described the response with respect to a client command. It is a figure which shows the example of the part which described the server command. It is a figure which shows the example of the part which described the response with respect to a server command. 4 is a flowchart showing basic operations of message collection and distribution processing in the HTTP client shown in FIG. 3. It is a flowchart which shows the process of the part of FIG.17 S11 thru | or S14 in detail. It is a flowchart which shows the process of the part after FIG.17 S15 in detail. 4 is a flowchart illustrating an example of processing related to execution of a server command in the HTTP client illustrated in FIG. 3.

It is a flowchart which shows the other example. It is a functional block diagram which shows the structure of the function for performing the process regarding a command and a command response among the functions of the HTTP server shown in FIG. It is a figure which shows the example of the data structure in the server command sheet memorize | stored in the server command pool shown in FIG. It is a figure which shows the example of the data structure in the client command sheet memorize | stored in the client command pool shown in FIG. 4 is a flowchart showing basic operations of message collection and distribution processing in the HTTP server shown in FIG. 3. It is a flowchart which shows the process of the part of FIG.25 S111 thru | or S115 in detail. It is a flowchart which shows the process of the part after step S116 of FIG. 25 in detail. 4 is a flowchart showing an example of processing related to execution of a client command in the HTTP server shown in FIG. 3. It is a flowchart which shows the other example. It is a figure which shows the structural example of the communication system of the reference example in the case of employ | adopting SMTP as a communication protocol.

FIG. 31 is a diagram showing a relationship between an operation request and an operation response in the communication system shown in FIG. 30. FIG. 31 is a diagram showing an example of a communication sequence in the communication system shown in FIG. 30. FIG. 31 is a functional block diagram corresponding to FIG. 8, illustrating a configuration of functions for performing processing relating to commands and command responses among the functions of the communication device A illustrated in FIG. 30. FIG. 31 is a diagram illustrating an example of an electronic mail transmitted from the communication apparatus A illustrated in FIG. 30 to the communication apparatus B. FIG. 31 is a flowchart showing a basic operation of processing at the time of message transmission in communication apparatus A shown in FIG. 30. FIG. Similarly, it is a flowchart showing a flowchart of a basic operation of processing at the time of message reception. It is a figure which shows another structural example of the communication system of this invention.

Explanation of symbols

1: First communication device 2: Second communication device 10: Network 11: HTTP client 12: HTTP server 13: Internet 14: Firewall 31: CPU
32: ROM 33: RAM
34: SD card 35: NIC
41, 142: Client command pool 42, 141: Server command pool 43: Client command generation means 44: Server command execution result generation means 45, 145: Transmission message collection means 46: HTTP request transmission means 47: HTTP response reception means 48, 148: Received message distribution means 51: Communication apparatus A side command pool 52: Communication apparatus B side command pool 53: Communication apparatus A side command generation means 54: Communication apparatus B side command execution result generation means 56: Mail transmission means 57: Mail Receiving means 100: Managed apparatus 101: Mediating apparatus 102: Management apparatus 143: Server command generating means 144: Client command execution result generating means 146: HTTP response transmitting means 147: HTTP request receiving means

Claims (21)

In a communication client that communicates with a communication server,
First storage means for storing a server request received from the communication server, which is a request to perform a predetermined operation, and an operation response which is a response to the server request;
Second storage means for storing a client request which is a request to perform a predetermined operation on the communication server;
Status storage means for storing status information indicating whether the server request and the progress status of the operation relating to each of the client requests are in an unprocessed, in-process, or processed state;
An operation response related to the server request whose progress status has been processed is acquired from the first storage means, and the client request whose progress status is unprocessed is acquired from the second storage means. Collecting means;
A communication client comprising: a transmission unit configured to transmit a communication request including the operation response acquired by the collection unit and the client request to the communication server. The communication client according to claim 1,
Retrieving the server request whose progress status is unprocessed from the first storage means, causing an appropriate module determined according to the content of the server request to execute an operation related to the server request, and A communication client comprising request processing means for changing the status information during processing. The communication client according to claim 2,
A communication client, wherein the plurality of request processing means operate simultaneously in a plurality of threads. The communication client according to any one of claims 1 to 3,
The communication client is characterized in that the transmission means is means for transmitting a communication request including a plurality of the operation responses and a plurality of the client requests. The communication client according to any one of claims 1 to 4,
The communication client, wherein the transmission unit periodically transmits a communication request to the communication server regardless of whether the operation response and the client request are acquired by the collection unit. The communication client according to claim 5,
When receiving the server request from the communication server, the communication client transmits an operation response to the server request included in the periodic communication request after the next time. In a communication server that communicates with a communication client,
First storage means for storing a client request received from the communication client as a request to perform a predetermined operation and an operation response as a response to the client request;
Second storage means for storing a server request which is a request to perform a predetermined operation on the communication client;
Status storage means for storing status information indicating which status is unprocessed, being processed, or processed for the progress status of the operation relating to each of the client request and the server request;
An operation response related to the client request whose progress status has been processed is acquired from the first storage means, and the server request whose progress status is not processed is acquired from the second storage means. Collecting means;
A communication server comprising: a transmission unit configured to transmit a communication response including the operation response acquired by the collection unit and the server request to the communication client in response to a communication request received from the communication client. The communication server according to claim 7,
The client request whose progress status is unprocessed is searched from the first storage means, and an appropriate module determined according to the content of the client request is caused to execute an operation related to the client request. A communication server comprising request processing means for changing the status information during processing. The communication server according to claim 8,
A communication server, wherein the plurality of request processing means operate simultaneously in a plurality of threads. The communication server according to any one of claims 7 to 9,
The communication server is a means for transmitting a communication response including a plurality of the operation responses and a plurality of the server requests. In a communication system comprising a communication client and a communication server,
The communication client is
First client-side storage means for storing a server request received from the communication server, which is a request to perform a predetermined operation, and an operation response which is a response to the server request;
Second client-side storage means for storing a client request that is a request to perform a predetermined operation on the communication server;
Client-side state storage means for storing state information indicating whether the server request and the progress of the operation relating to each of the client requests are in an unprocessed, in-process, or processed state;
The client from which the progress status has been processed is acquired from the first client-side storage means, and the progress status is unprocessed from the second client-side storage means. A client-side collection means to obtain the request;
Client-side transmission means for transmitting a communication request including the operation response acquired by the client-side collection means and the client request to the communication server;
The communication server is
First server-side storage means for storing a client request received from the communication client, which is a request to perform a predetermined operation, and an operation response which is a response to the client request;
Second server-side storage means for storing a server request that is a request to perform a predetermined operation for the communication client;
A server-side state storage unit that stores state information indicating which state is unprocessed, being processed, or processed with respect to the progress of the operation according to each of the client request and the server request;
The server from which the progress status has been processed is acquired from the first server-side storage means, and the progress status is unprocessed from the second server-side storage means. A server-side collection means for obtaining a request;
Server-side transmission means for transmitting a communication response including the operation response acquired by the server-side collection means and the server request to the communication client in response to a communication request received from the communication client. Communication system. A communication method to be executed by a communication client that communicates with a communication server,
A first storage procedure for storing a server request received from the communication server as a request to perform a predetermined operation and an operation response as a response to the server request;
A second storage procedure for storing a client request that is a request to perform a predetermined operation on the communication server;
A status storage procedure for storing status information indicating which status is unprocessed, being processed, or processed for the progress status of the operation related to each of the server request and the client request;
The client that has acquired the operation response related to the server request that has been processed in the first storage procedure and that has been processed, and that has been processed in the second storage procedure and that has not yet been processed. A collection procedure to retrieve the request;
A communication method, comprising: a transmission procedure for transmitting a communication request including the operation response acquired in the collection procedure and the client request to the communication server. The communication method according to claim 12, comprising:
The server request stored in the first storage procedure is searched for a server request in which the progress status is not processed, and an appropriate module determined according to the content of the server request performs an operation related to the server request. A communication method comprising: a request processing procedure for changing the status information stored for the server request during processing. The communication method according to claim 13, comprising:
A communication method, wherein a plurality of processes of the request processing procedure are simultaneously executed by a plurality of threads. The communication method according to any one of claims 12 to 14,
The communication method is characterized in that the transmission procedure is a procedure of transmitting a communication request including a plurality of the operation responses and a plurality of the client requests. The communication method according to any one of claims 12 to 15,
In the transmission procedure, a communication method periodically transmits a communication request to the communication server regardless of whether or not the operation response and the client request are acquired in the collection procedure. The communication method according to claim 16, comprising:
When the server request is received from the communication server, an operation response to the server request is included in the periodic communication request from the next time in the transmission procedure and transmitted. A communication method executed by a communication server that communicates with a communication client,
A first storage procedure for storing a client request received from the communication client as a request to perform a predetermined operation, and an operation response as a response to the client request;
A second storage procedure for storing a server request which is a request to perform a predetermined operation on the communication client;
A status storage procedure for storing status information indicating whether the status of operations related to each of the client request and the server request is unprocessed, being processed, or processed;
The server that has acquired the operation response related to the client request that has been processed in the first storage procedure and that has been processed, and that has been processed in the second storage procedure and that has not yet been processed. A collection procedure to retrieve the request;
A communication method comprising: a transmission procedure for transmitting a communication response including the operation response acquired in the collection procedure and the server request to the communication client in response to a communication request received from the communication client. The communication method according to claim 18, wherein
The client request stored in the first storage procedure is searched for a client request whose progress status is not processed, and an appropriate module determined according to the content of the client request executes an operation related to the client request. A communication method comprising a request processing procedure for changing the status information of the client request during processing. The communication method according to claim 19, wherein
A communication method, wherein a plurality of processes of the request processing procedure are simultaneously executed by a plurality of threads. A communication method according to any one of claims 18 to 20, comprising:
The communication method is characterized in that the transmission procedure is a procedure of transmitting a communication response including a plurality of the operation responses and a plurality of the server requests.

Images