JP2005259106A - Mediating device, distributed processing system, data transfer method, program, and recording medium - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To constitute a communication system in which the management labor of destination information is reduced when certain communication equipment transmits an operation request to a plurality of communication equipment and receives an operation response to the operation request, and which is stably operated even when system configuration is changed. <P>SOLUTION: A mediating server 12 for mediating communication between terminal equipment 10 and a plurality of processing servers 13 receives an operation request from the terminal equipment 10, and transmits the received operation request to the processing server 13 being the destination of transfer according to the classification. Also, each processing server 13 receives the operation response to the operation request from the terminal equipment 10, and transmits the operation response to the terminal equipment 10. In this case, the mediating server 12 receives the plurality of operation requests in a batch from the terminal equipment 10, and transmits the operation responses received from the respective processing servers 13 to the terminal equipment 10 in a batch. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

  The present invention includes an intermediary device that mediates communication between a first communication device and a plurality of second communication devices, a terminal device, and a plurality of processing servers, and an intermediary server that mediates communication between them. A distributed processing system, a data transfer method for transmitting and receiving an operation request and an operation response between the first communication device and the plurality of second communication devices via the intermediary device as described above, and a computer as described above The present invention relates to a program for functioning as a device and a computer-readable recording medium on which such a program is recorded.

  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 from one device to another device as an operation request to execute the operation, and an operation execution result is returned from the transmission partner as an operation response.

Such a technique is disclosed in, for example, Patent Document 1, in which a remote processor transmits a message indicating a command to be executed to a local processor and receives a response to the command. Is described.
Also, in this document, when a local processor is arranged 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.
Japanese Patent Application Laid-Open No. 2001-273211

In addition, the technology related to the operation request can be applied to a system that remotely controls the operation of the device connected to the communication device. 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 indicate that a response to the command is transmitted.
JP 2002-135858 A

  By the way, when trying to use some service provided in response to a command, it is conceivable that a device that provides the service differs depending on the command. Then, in a system that sends a command specifying a destination as in the past, in such a case, the appropriate destination is grasped for each command, and if the command is not sent to the device, the service is used. I couldn't. Therefore, there is a problem that the management burden of the destination information is heavy.

  In addition, if the service provider changes or the system configuration changes, it may be necessary to change the command transmission destination. In such a case, the transmission destination of each terminal device must be changed. If the change is not notified, the service cannot be used. Therefore, when the destination information cannot be normally managed, there is a problem that the use of the service is hindered.

  The present invention solves such a problem, and when a certain communication device transmits an operation request to a plurality of communication devices and receives an operation response to the operation request, reduces the burden of managing destination information and system configuration It is an object of the present invention to make it possible to configure a communication system that can be stably operated even when the change is made.

To achieve the above object, an intermediary device according to the present invention is an intermediary device that mediates communication between a first communication device and a plurality of second communication devices, and receives an operation request from the first communication device. A first receiving means for receiving, a first transmitting means for transmitting each operation request received by the receiving means to a second communication device as a transfer destination according to the type of the operation request; A second receiving means for receiving an operation response to the operation request transferred from the first communication apparatus from the communication apparatus, and each operation response received by the second receiving means to the first communication apparatus. And a second transmitting means for transmitting.
In such an intermediary device, the first receiving means is provided with means for collectively receiving a plurality of operation requests from the first communication device, and the second transmission means is provided with the second reception. Means may be provided for collectively transmitting the operation responses received by the means to the first communication device.

Alternatively, in an intermediary device that mediates communication between the first communication device and the plurality of second communication devices, the operation request has been transferred from the first communication device and transferred from the second communication device. A first receiving unit that receives an operation response to the operation request, and a second communication that is a transfer destination of each operation request and operation response received by the first receiving unit according to the type of each operation request and operation response. An operation request to be transferred from the second communication device to the first communication device and an operation response to the operation request transferred from the first communication device; And a second transmission means for transmitting each operation request and each operation response received by the second reception means to the first communication device.
In such an intermediary device, the first receiving unit collectively receives an operation request from the first communication device and an operation response to the operation request transferred from the second communication device. Means may be provided, and the second transmitting means may be provided with means for collectively transmitting each operation request and each operation response received by the second receiving means to the first communication device.

Further, in any one of the intermediary devices described above, for each operation request or operation response received from the first communication device, the transfer destination information of the operation request or operation response belonging to that group is stored for each required group. A storage means may be provided, and a transfer destination determination means for determining a transfer destination of an operation request or an action response to be transmitted by the first transmission means with reference to transfer destination information stored in the storage means may be provided. .
Further, the transfer destination determining means may be provided with means for determining a transfer destination of an operation request or an operation response whose transfer destination information is not stored in the storage means as a predetermined transfer destination.
Further, the group may be provided for each name space used in SOAP, the operation request is a SOAP request, and the operation response is a SOAP response.

  Further, in the intermediary device that mediates communication between the first communication device and the plurality of second communication devices, the SOAP request and the second communication device are transferred from the first communication device. A first receiving means for receiving a SOAP response to the SOAP request in a state described in the HTTP request, and transferring each SOAP request and SOAP response received by the first receiving means in accordance with the type of each SOAP request and SOAP response A first transmission means for transmitting in a HTTP request to the second communication apparatus, a SOAP request to be transferred from each of the second communication apparatuses to the first communication apparatus, and the first The SOAP response to the SOAP request transferred from the communication device is used as an HTTP response. The second receiving means for receiving in the loaded state, and each SOAP request and each SOAP response received by the second receiving means are described in the HTTP response to the HTTP request received by the first receiving means. You may provide the 2nd transmission means to transmit to the said 1st communication apparatus.

  In such an intermediary device, the first receiving means sends the SOAP request from the first communication device and the SOAP response to the SOAP request transferred from the second communication device to one HTTP request. The means for receiving in the state described in the above is provided, and each SOAP request and each SOAP response received by the second receiving means are sent to the second transmitting means with respect to the HTTP request received by the first receiving means. There may be provided means for describing in one HTTP response and transmitting it to the first communication device.

  The distributed processing system of the present invention is a distributed processing system comprising a plurality of processing servers and an intermediary server that mediates communication between each processing server and the terminal device. First receiving means for receiving an operation request from the first transmitting means, first transmitting means for transmitting each operation request received by the receiving means to a processing server as a transfer destination according to the type of the operation request, and each of the processing servers Second receiving means for receiving an operation response to the operation request from the terminal device, and second transmitting means for transmitting each operation response received by the second receiving means to the terminal device, Each processing server executes a receiving means for receiving an operation request for the processing server from the terminal device from the intermediary server, and an operation related to the operation request received by the means. As a result means for generating an operation response to the operation request, the operation response thereof means is generated is provided with a transmission means for transmitting to the intermediary server.

  In such a distributed processing system, in the mediation server, the first receiving means is provided with means for collectively receiving a plurality of operation requests from the terminal device, and the second transmitting means is provided with the first It is preferable to provide means for collectively transmitting the operation responses received by the two receiving means to the terminal device.

  Further, in a distributed processing system including a plurality of processing servers and an intermediary server that mediates communication between each processing server and the terminal device, the intermediary server sends an operation request and the processing from the terminal device. A first receiving unit that receives an operation response to an operation request from the server, and a process that transfers each operation request and operation response received by the first receiving unit according to the type of each operation request and operation response First transmission means for transmitting to the server; second reception means for receiving an operation request to be transferred to the terminal device from each processing server; and an operation response to the operation request from the terminal device; A second transmission unit configured to transmit each operation request and each operation response received by the second reception unit to the terminal device; and the processing server from the terminal device to the processing server. Receiving means for receiving an operation request to be received and an operation response to the operation request addressed to the terminal device from the intermediary server, and executing an operation related to the operation request received by the means, and sending an operation response to the operation request as an execution result Means for generating and transmitting means for transmitting the operation response generated by the means and the operation request addressed to the terminal device to the mediation server may be provided.

  In such a distributed processing system, in the intermediary server, the first receiving means is provided with means for collectively receiving an operation request from the terminal device and an operation response to the operation request from the processing server. The second transmission means may be provided with means for collectively transmitting each operation request and each operation response received by the second reception means to the terminal device.

  Further, in a distributed processing system including a plurality of processing servers and an intermediary server that mediates communication between each processing server and the terminal device, the intermediary server sends the SOAP request and the processing from the terminal device. A first receiving means for receiving a SOAP response to the SOAP request from the server in a state described in the HTTP request, and each SOAP request and SOAP response received by the first receiving means are changed to each SOAP request and SOAP response. A first transmission means that transmits an HTTP request written in an HTTP request to a processing server serving as a transfer destination according to the type, a SOAP request to be transferred from each processing server to the terminal device, and a SOAP for the SOAP request from the terminal device Response to HTTP response The second receiving means that receives in the state described in the above, and each SOAP request and each SOAP response received by the second receiving means are described in the HTTP response to the HTTP request received by the first receiving means. A second transmission means for transmitting to the terminal device, and in each processing server, a SOAP request from the terminal device to the processing server and a SOAP response to the SOAP request addressed to the terminal device in an HTTP request. The receiving means that receives from the mediation server in the described state, the means for executing the operation related to the SOAP request received by the means, and generating the SOAP response to the SOAP request as the execution result, and the SOAP response generated by the means And SO addressed to the terminal device A P request may be provided with transmitting means for transmitting to the intermediary server described in an HTTP response to the HTTP request received by the receiving means of the processing server.

  In such a distributed processing system, in the intermediary server, a state in which a SOAP request from the terminal device and a SOAP response to the SOAP request from the processing server are described in one HTTP request as the first receiving means. And receiving each SOAP request and each SOAP response received by the second receiving means, and one HTTP response for the HTTP request received by the first receiving means. It is good to provide the means to transmit to the said terminal device described in above.

The data transfer method of the present invention is a data transfer method for transmitting and receiving an operation request and an operation response between a first communication device and a plurality of second communication devices via an intermediary device. A first reception procedure for receiving an operation request from the first communication device, and a first transmission procedure for transmitting each operation request received in the reception procedure to a second communication device as a transfer destination according to the type of the operation request. Transmission procedure, a second reception procedure for receiving an operation response to the operation request transferred from the first communication device from each of the second communication devices, and each received in the second reception procedure A second transmission procedure for transmitting an operation response to the first communication device is executed.
In such a data transfer method, the first reception procedure includes a procedure for receiving a plurality of operation requests collectively from the first communication device, and the second transmission procedure includes the second transmission procedure. It is good to provide the procedure which transmits each operation response received by the receiving procedure to the said 1st communication apparatus collectively.

Further, in a data transfer method for transmitting and receiving an operation request and an operation response between a first communication device and a plurality of second communication devices via an intermediary device, the intermediary device is transferred from the first communication device, A first reception procedure for receiving an operation request and an operation response to the operation request transferred from the second communication device, and each operation request and operation response received in the first reception procedure are set to each operation. A first transmission procedure for transmitting to a second communication device as a transfer destination according to the type of request and operation response; an operation request to be transferred from each second communication device to the first communication device; A second reception procedure for receiving an operation response to the operation request transferred from the first communication device, and each operation request and each operation response received in the second reception procedure are sent to the first communication device. A second sending procedure to send to It may be caused to execute.
In such a data transfer method, in the first reception procedure, an operation request from the first communication device and an operation response to the operation request transferred from the second communication device are collectively received. It is preferable to provide a procedure for transmitting each operation request and each operation response received in the second reception procedure to the first communication device in a batch in the second transmission procedure.

  Further, in a data transfer method for transmitting and receiving an operation request and an operation response between a first communication device and a plurality of second communication devices via an intermediary device, the intermediary device is transferred from the first communication device, A first reception procedure for receiving a SOAP request and a SOAP response to the SOAP request transferred from the second communication device in a state described in the HTTP request, and each SOAP request received in the first reception procedure And a SOAP response from the second communication device, the first transmission procedure for transmitting the SOAP request in accordance with the type of the SOAP request and the SOAP response to the second communication device serving as a transfer destination in the HTTP request, A SOAP request to be transferred to one communication device and a SOAP request transferred from the first communication device. The second reception procedure for receiving the SOAP response to the est in the state described in the HTTP response, and each SOAP request and each SOAP response received in the second reception procedure are received in the first reception procedure. You may make it perform the 2nd transmission procedure described in the HTTP response with respect to an HTTP request, and transmitting to the said 1st communication apparatus.

  In such a data transfer method, in the first reception procedure, a SOAP request from the first communication device and a SOAP response to the SOAP request transferred from the second communication device are sent as one HTTP request. The procedure for receiving in the state described above is provided, and each SOAP request and each SOAP response received in the second reception procedure are added to the second transmission procedure with respect to the HTTP request received by the first reception procedure. You may provide the procedure described in one HTTP response and transmitting to the said 1st communication apparatus.

According to another aspect of the present invention, there is provided a program for causing a computer to function as an intermediary device that mediates communication between a first communication device and a plurality of second communication devices. A first receiving means for receiving an operation request from the communication apparatus; and a first transmitting means for transmitting each operation request received by the receiving means to a second communication apparatus serving as a transfer destination according to the type of the operation request. The second receiving means for receiving an operation response to the operation request transferred from the first communication apparatus from each of the second communication apparatuses, and the operation responses received by the second receiving means are described above. It is a program for making it function as a 2nd transmission means to transmit to a 1st communication apparatus.
In such a program, the first receiving unit is provided with a function of collectively receiving a plurality of operation requests from the first communication device, and the second transmitting unit is provided with the second receiving unit. It is preferable to provide a function for collectively transmitting the operation responses received by the first communication apparatus.

In a program for causing a computer to function as an intermediary device that mediates communication between a first communication device and a plurality of second communication devices, the computer requests the operation request from the first communication device. And a first receiving means for receiving an operation response to the operation request transferred from the second communication device, and each operation request and operation response received by the first receiving means. First transmission means for transmitting to the second communication device as the transfer destination according to the type of the operation response, the operation request to be transferred from each of the second communication devices to the first communication device, and the first Second receiving means for receiving an operation response to the operation request transferred from the communication device, and transmitting each operation request and each operation response received by the second receiving means to the first communication device. Second to Or as a program for causing to function as signal means.
Further, in such a program, the first receiving means collectively receives an operation request from the first communication device and an operation response to the operation request transferred from the second communication device. And a function of collectively transmitting each operation request and each operation response received by the second receiving unit to the first communication device.

  In a program for causing a computer to function as an intermediary device that mediates communication between a first communication device and a plurality of second communication devices, the computer receives a SOAP request from the first communication device. And a first receiving means for receiving a SOAP response to the SOAP request transferred from the second communication apparatus in a state described in the HTTP request, and each SOAP request and SOAP received by the first receiving means. From the first transmission means for transmitting the response in the form of an HTTP request to the second communication device as the transfer destination according to the type of each SOAP request and SOAP response, and from each of the second communication devices, A SOAP request to be transferred to the communication device, and transferred from the first communication device A second receiving means for receiving a SOAP response to the OAP request in a state described in the HTTP response, and each SOAP request and each SOAP response received by the second receiving means are received by the first receiving means. It is good also as a program for functioning as a 2nd transmission means described in the HTTP response with respect to the HTTP request which transmitted to the said 1st communication apparatus.

  In such a program, the first receiving unit describes the SOAP request from the first communication device and the SOAP response to the SOAP request transferred from the second communication device in one HTTP request. A function for receiving in the state, and each SOAP request received by the second receiving means and each SOAP response to the second transmitting means for one HTTP request received by the first receiving means. It is good to provide the function described in an HTTP response and transmitting to the said 1st communication apparatus.

  The recording medium of the present invention is a computer-readable recording medium on which any one of the above programs is recorded.

  According to the intermediary device, distributed processing system, or data transfer method of the present invention as described above, a communication system in which a certain communication device transmits an operation request to a plurality of communication devices and receives an operation response to the operation request. In the configuration, it is possible to reduce the burden of managing destination information and to configure a communication system that can be stably operated even when the system configuration is changed. Further, according to the program of the present invention, a computer can be made to function as the mediation device described above to realize its characteristics, and similar effects can be obtained. According to the recording medium of the present invention, the above effect can be obtained by causing a computer not storing the above program to read and execute the program.

The best mode for carrying out the present invention will be described below with reference to the drawings.
Embodiment
First, one embodiment of a mediation server that is a mediation device of the present invention and a distributed processing system that is a communication system configured using the mediation server will be described. FIG. 1 is a block diagram showing the configuration of the distributed processing system.

As shown in FIG. 1, this distributed processing system includes a terminal device 10 that is a first communication device, a plurality of processing servers 13 that are second communication devices, and an intermediary server 12 that mediates communication between them. Is provided. Of these, the terminal device 10 is arranged in the installation environment of the customer (user side), and these and the mediation server 12 can communicate with each other via the Internet 14. When the function provided by the processing server 13 is used from the terminal device 10, only the request is transmitted from the terminal device 10 to the mediation server 12, and the mediation server 12 transfers the request to the appropriate processing server 13. The system which can utilize the function which the processing server 13 provides is comprised.
Note that the terms “mediation server” and “processing server” are used here to facilitate the understanding of the system. Is not intended to be limiting.

  The terminal device 10 may be a known PC (personal computer) having a communication function. However, a communication device in which various electronic devices are provided with a communication function may be considered. For example, a printer, a FAX device, and the like. Communicate to image processing devices such as digital copiers, scanner devices, digital multifunction devices, network home appliances, vending machines, medical equipment, power supply devices, air conditioning systems, gas / water / electric metering systems, automobiles, aircraft, etc. A communication device having a function can be considered.

Further, a plurality of terminal devices 10 can be provided as indicated by broken lines, and different types of devices can be mixed.
Further, the terminal device 10 in each customer environment is connected to a LAN (Local Area Network), but the LAN is connected to the Internet 14 via a firewall 11 in consideration of security.

  Here, since the firewall 11 is normally set to block communication requests from the outside, the mediation server 12 only has to transmit a communication request such as an HTTP (Hyper Text Transfer Protocol) request to the inside of the firewall 11. Information cannot be transmitted to the terminal device 10. Therefore, in order for the mediation server 12 and the terminal device 10 to exchange information, it is necessary to employ a special protocol.

In addition, although only two processing servers 13 connected to the mediation server 12 are shown here, they can be arranged in various hierarchical structures, and the arrangement can be changed during the operation of the system. It is. Even in this case, since the transfer destination of the command is managed by the mediation server 12 as will be described later, it is possible to easily cope with a change in the system configuration by changing the data of the transfer destination management.
Furthermore, here, the connection between the processing server 13 and the mediation server 12 is indicated by a line different from the Internet 14, but it is of course possible to adopt a configuration in which these can communicate via the Internet 14.

  In such a distributed processing system, the processing server 13 is mounted with an application program for performing an operation according to an operation request from the terminal device 10 or transmitting an operation request to the terminal device 10. . The mediation server 12 has an application program for mediating transmission / reception of an operation request and an operation response to the operation request between the terminal device 10 and each processing server 13. Further, the mediation server 12 is also mounted with an application program for realizing a function as a processing server. Each of these nodes in this distributed processing system, including the terminal device 10, transmits an “operation request” that is a request for processing for a method of an application program to be implemented by RPC (remote procedure call). It is possible to acquire an “operation response” that is a result of the processed processing.

  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. The content of the request by the operation request includes a notification without a meaningful execution result.

FIG. 2 shows the relationship between these operation requests and operation responses. In this figure, the presence of the firewall 11 is not considered.
FIG. 2A shows a case where an operation request for the processing server 13 is generated in the terminal device 10. In this case, the terminal device 10 generates a terminal device side operation request a, and the processing server 13 that has received the request via the mediation server 12 returns an operation response a to the operation request.

  At this time, as will be described later, on the terminal device 10 side, it is not necessary to know to which processing server 13 the operation request is finally transferred, and if the operation request is simply transmitted to the mediation server 12. The intermediary server 12 transfers the operation request to an appropriate processing server 13, receives an operation response from the processing server 13, and returns it to the terminal device 10. Further, it can be assumed that the terminal device side operation request a is sequentially mediated by a plurality of mediation servers 12 and reaches the processing server 13.

  FIG. 2A also shows a case in which not only the response a but also a delay notification a ′ is returned. When the processing server 13 receives the terminal device side operation request a from the connected intermediary server 12 and determines that a response to the operation request cannot be returned during connection with the processing server 13, a notification is made that the response is delayed. This is because the connection state is once disconnected, and a response to the operation request is delivered again at the time of subsequent connection.

FIG. 2B shows a case where an operation request for the mediation server 12 is generated in the terminal device 10. In this case, for example, the terminal device 10 generates a terminal device side operation request b, and the intermediary server 12 that has received the request returns an operation response b to the operation request. However, also in this case, it is not necessary to deal with the terminal device 10 differently from the case of FIG. If the operation request is transmitted to the mediation server 12 as in the case of FIG. 2A, the mediation server 12 side determines the operation request to be executed by itself and recognizes that it should execute by itself. Instead of transferring to the processing server 13, an operation related to the operation request is executed.
Also in the case of FIG. 2B, returning the delay notification b ′ when the response cannot be returned immediately is the same as in the case of FIG.

FIG. 2C shows a case where an operation request for the terminal device 10 is generated in the processing server 13. In this case, the processing server 13 generates a processing server side operation request c, and the terminal device 10 that receives the processing server side operation request c via the mediation server 12 returns an operation response c to the operation request.
FIG. 2D shows a case where an operation request for the terminal device 10 is generated by the mediation server 12. In this case, the mediation server 12 generates a mediation server-side operation request d, and the terminal device 10 that receives the mediation server-side operation request d returns an operation response d to the operation request.

2C and 2D, it is not necessary for the terminal device side to recognize which server the operation response is returned to, and if all the operation responses are transmitted to the intermediary server 12, the intermediary is performed. The server 12 side forwards it to an appropriate partner (including myself).
The delay notification is the same as in FIGS. 2A and 2B in the cases of FIGS.
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.

  In this embodiment, when a communication device such as the terminal device 10 transmits / receives an operation request and an operation response to the received operation request to / from a plurality of communication partners such as the processing server 13 as described above, the transmission / reception is performed. An intermediary server 12 is provided as an intermediary device that mediates the process, and the intermediary server 12 forwards the operation request to the processing server 13 as a transfer destination according to the type of the operation request received from the terminal device 10, and the operation response from the processing server 13 Is returned to the terminal device 10 that is the source of the operation request. Here, the operation request may be transmitted only from the communication device, and the communication partner may transmit only the operation response to the operation request to the communication device.

  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), SMTP (Simple Mail Transfer Protocol). Alternatively, FTP (File Transfer Protocol) or the like can be employed. Here, an example in which HTTP is adopted will be described.

Next, this embodiment will be described using a more specific example.
Here, as a more specific embodiment of the distributed processing system shown in FIG. 1, from the image processing apparatus 100 as the first communication apparatus to the sales management server 103a and the information distribution server 103b as the second communication apparatuses, respectively. A remote management system that uses the service provided by, and mediates communication between these devices by the device management server 102 that is an intermediary device of the present invention will be described. In this system, the image processing apparatus 100 can also use a service provided by the device management server 102.
FIG. 3 is a conceptual diagram showing an example of the configuration of the distributed processing system. However, the terminal device 10 is changed to the image processing device 100, and only specific names are given to the respective servers, which are different from FIG. Therefore, the description about the whole system configuration is omitted.

  Here, an example in which only one image processing apparatus 100 is provided is shown, but a plurality of terminal apparatuses including this may be provided as shown in FIG. In the following description, in order to simplify the description, it is basically assumed that the terminal device is only one image processing device 100. However, the present invention can be easily extended and applied even when a plurality of terminal devices are provided. In order to be able to do so, an example in which there are a plurality of terminal devices is shown for some processes and data without particular notice. Even in this case, if one of the plurality of terminal apparatuses is handled as the image processing apparatus 100, the present invention can be applied to the system shown in FIG.

By the way, the image processing apparatus 100 is a digital multi-function peripheral having functions such as copying, facsimile, and scanner, and a function for communicating with an external apparatus, and an application program for providing a service related to these functions is installed. It is what.
The device management server 102 has a function of providing services related to remote management and maintenance of the image processing apparatus 100 in addition to a function as a mediation server that mediates communication between the processing server and the image processing apparatus 100.
The sales management server 103a has a function of providing services related to order reception and sales of consumables and supplies in the image processing apparatus 100. The information distribution server 103b has a function of providing a service for distributing various information such as news, guidance, and product introduction to the user of the image processing apparatus 100.

Then, 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.
In the following description, the device management server 102 will be referred to as an intermediary server 102, and the sales management server 103a and the information distribution server 103b will be collectively referred to as a processing server 103, unless specifically describing the contents of the service. To do.

FIG. 4 shows the relationship between these operation requests and operation responses. In this figure, the presence of the firewall 11 is not considered.
FIG. 4A shows a case where an operation request for the processing server 103 is generated in the image processing apparatus 100. In this case, the image processing apparatus 100 generates an image processing apparatus side operation request a (hereinafter also referred to as a “terminal apparatus command”), and the processing server 103 that has received the request via the mediation server 102 performs an operation for this command. It is a model that returns a response a (hereinafter also referred to as “command response” or simply “response”). It can be assumed that the operation request a on the image equipment side is sequentially mediated by a plurality of mediation servers 102 and reaches the processing server 103.

FIG. 4B shows a case where an operation request for the mediation server 102 is generated in the image processing apparatus 100. In this case, for example, the image processing apparatus 100 generates an image processing apparatus-side operation request b, and the mediation server 102 that has received the request returns an operation response b to the command.
4A and 4B, the image processing apparatus 100 does not need to know where the operation request is finally transferred in the same manner as in FIG. It is.

FIG. 4C shows a case where an operation request for the image processing apparatus 100 is generated in the processing server 103. In this case, the processing server 103 generates a processing server side operation request c (hereinafter also referred to as “processing server command”), and the image processing apparatus 100 that has received the request via the mediation server 102 responds to the operation request. It is a model that returns an operation response c.
FIG. 4D shows a case where an operation request for the image processing apparatus 100 is generated in the mediation server 102. In this case, the mediation server 102 generates a mediation server side operation request (hereinafter also referred to as “mediation server command”) d, and the image processing apparatus 100 that has received the request returns an operation response d to the command. Become.

In the case of FIGS. 4C and 4D, the image processing apparatus 100 does not need to know where the operation response is finally transferred, as in FIG. It is.
In addition, in all of FIGS. 4A to 4D, when a response cannot be returned immediately, a delay notification is returned as in the case of FIG.
As described above, the operation request and the operation response are handled symmetrically between the image processing apparatus 100 and the processing server 103 and between the image processing apparatus 100 and the mediation server 102 at the RPC level. However, it is not symmetrical at the communication level.

Next, a communication sequence in this communication system will be described.
First, FIG. 5 shows an example of a communication sequence between the image processing apparatus and the mediation server.
As shown in this figure, the image processing apparatus 100 and the mediation server 102 communicate with each other by transmitting and receiving an HTTP request that is a communication request and an HTTP response that is a communication response to the communication request.

  However, since there is a firewall 11 between the image processing apparatus 100 and the mediation server 102, as shown in this figure, communication always sends an HTTP request as a communication request from the image processing apparatus 100 to the mediation server 102. The procedure is performed by returning an HTTP response from the mediation server 102 to the image processing apparatus 100 as a communication response to the communication request. For example, the mediation server 102 returns an HTTP response X to the HTTP request X transmitted by the image processing apparatus 100, and similarly returns an HTTP response Y to the HTTP request Y.

  The HTTP request from the image processing apparatus 100 includes a terminal device command that is an operation request to the mediation server 102 or the processing server 103 from the image processing apparatus 100, and the image processing apparatus 100 from the processing server 103 via the mediation server 102. A response (command response) to the processing server command transmitted to the image processing apparatus and a response to the mediation server command transmitted from the mediation server 102 to the image processing apparatus 100 are described and transmitted.

As for the terminal device command, the image processing apparatus 100 only needs to know that it should be transmitted to either the mediation server 102 or the processing server 103.
The HTTP response from the mediation server 102 includes a processing server command that is an operation request from the processing server 103 to the image processing apparatus 100, and a mediation server command that is an operation request from the mediation server 102 to the image processing apparatus 100. A response to the terminal device command from the image processing apparatus 100 to the mediation server 102 or the processing server 103 is described and transmitted.

As long as the response to which terminal device command is known, it is not necessary to be able to specifically identify which intermediary server 102 or processing server 103 is the response. When a delay notification is transmitted, a delay notification may be described instead of the response.
Further, as can be seen from this example, for example, the terminal device commands A and B are described in the HTTP request X and transferred, and the response or delay notification is transferred in the HTTP response X corresponding to the HTTP request X and transferred. can do. However, the processing server command C and the mediation server command D are described and transferred in the HTTP response X corresponding to the HTTP request X, and the response or delay notification is described in the HTTP request Y that is the next HTTP request. Will be transferred.

  Further, in the case of FIG. 4A or 4B described above, the image processing apparatus 100 can establish a connection with the mediation server 102 immediately after generating the terminal apparatus command, and deliver it including the HTTP request. However, in the case of FIG. 4C or 4D, since the firewall 11 installed on the image processing apparatus 100 side blocks the HTTP request from the mediation server 102, the image processing apparatus 100 immediately from the mediation server 102 side. Will not be able to access the processing server command.

Next, FIG. 6 shows an example of a communication sequence between the mediation server and the processing server.
There is not always a firewall between the mediation server 102 and the processing server 103. However, in order to eliminate the load of managing the other party on the processing server 103 side and managing the timing for requesting communication, as shown in FIG. An HTTP request is transmitted to the processing server 103, and an HTTP response is returned from the processing server 103 to the mediation server 102 as a communication response to the communication request. For example, the processing server 103 returns an HTTP response Z to the HTTP request Z transmitted from the mediation server 102, and similarly returns an HTTP response W to the HTTP request W.

  Then, the HTTP request is a response to the terminal device command received from the image processing apparatus 100 and the processing server command transmitted to the image device 100, and the one received from the image processing apparatus 100 should be transferred to the processing server 103. The judgment is described and transmitted. In addition, the HTTP response includes a processing server command, which is an operation request addressed to the image processing apparatus 100 from the processing server 103, and a response to the terminal device command transferred to the processing server 103, and is transmitted. When a delay notification is transmitted, a delay notification may be described instead of the response.

It should be noted that the terminal device command, the mediation server command, the processing server command, and the response and delay notification to these can be described in one HTTP request or HTTP response in any number (may be 0). The contents described in one HTTP request or HTTP response are logically transferred collectively.
In this way, by transferring operation requests and operation responses with different destinations and sources in a batch, the number of connections required to transfer necessary information is reduced, overhead is reduced, and communication efficiency is reduced. Can be achieved.

FIG. 7 shows an example of another communication sequence between the image processing apparatus and the mediation server.
For the sake of explanation, FIGS. 5 and 6 show a very simple sequence example, but FIG. 7 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 delay notification is transmitted in response to a command, it is not necessary to return a response at the next transmission opportunity. For example, the HTTP response Y ′ next to the HTTP response X ′ describing the delay notification as in the terminal device command B shown in FIG. May be.
Of course, the same applies to the mediation server command and the processing server command, and it is not necessary to describe a response to the command in the HTTP request next to the HTTP request in which the delay notification is described. And what is necessary is just to describe and transfer to a subsequent HTTP request.

By the way, each command and command response is generated independently and should be used for processing. In order to perform batch transfer as described above, it is necessary to combine these commands and command responses before transfer and separate them after transfer. Next, a hardware configuration of each device, a functional configuration for performing such processing, and a procedure of the processing will be described.
In addition, in order to simplify description, description of processing regarding delay notification is omitted in the following description.

First, FIG. 8 shows an outline of the hardware configuration of the mediation server.
FIG. 8 is a block diagram illustrating a schematic configuration example of the mediation server 102.
The mediation server 102 includes a modem 121, a communication terminal 122, an external connection I / F (interface) 123, an operator terminal 124, a control device 125, a file server 126, and the like.
The modem 121 communicates with the image processing apparatus 100 on the device user side (for example, a user destination using the image processing apparatus) via a public line (not shown), and modulates and demodulates data to be transmitted and received. The communication terminal 122 controls communication by the modem 121. The modem 121 and the communication terminal 122 serve as communication means.

The external connection I / F 123 is an interface for performing communication via a network such as the Internet 14 or a dedicated line. Then, communication is performed with the image processing apparatus 100 on the device user side and the processing server 103 via this. A proxy server for security management may be provided.
The operator terminal 124 accepts input of various data by operations on an input device such as a keyboard by an operator. The input data includes, for example, customer information such as their IP address and telephone number (calling destination telephone number) used when communicating with the image processing apparatus 100 in each customer's environment.

  The control device 125 includes a microcomputer (not shown) composed of a CPU, ROM, RAM, and the like, and controls the entire mediation server 102 in an integrated manner. The CPU operates in accordance with a required program (executes the required program as necessary), and various processes can be performed by selectively using each unit as necessary.

The file server 126 includes a storage device such as a hard disk device (not shown), in which the IP address and telephone number of the image processing apparatus 100 in each customer's environment, data received from those apparatuses, identification of the image processing apparatus to be managed Information, data input from the operator terminal 124, a transfer destination table to be described later indicating the transfer destination of each command and command response, and various data such as a program according to the present invention are stored as a database (DB).
The configuration of the management device is not limited to this, and can be configured using, for example, one PC.

Next, FIG. 9 shows a hardware configuration of the image processing apparatus.
Here, the image processing apparatus 100 is configured as a digital multi-function peripheral having functions of a printer, a facsimile (FAX) apparatus, a digital copying machine, a scanner apparatus, a document management apparatus, etc. As shown in FIG. ASIC (Application Specific Integrated Circuit) 202, SDRAM 203, flash memory (nonvolatile memory) 204, NRS memory 205, PHY (physical media interface) 206, NVRAM (nonvolatile memory) 207, operation unit 209, HDD (hard disk drive) 210, modem 211, PI (personal interface) 212, FCU (fax control unit) 213, USB (Universal Serial Bus) 214, IEEE (Institute of Electrical and Electronic Engineers) 1394_215, engine interface And a chromatography scan (I / F) 216 and the engine unit 217,. These configurations are hardware resources for performing image processing such as image reading, image formation, and image information transmission.

The CPU 201 is arithmetic processing means that performs data processing (control of each function) via the ASIC 202.
The ASIC 202 is a multi-function device including a CPU interface, an SDRAM interface, a local bus interface, a PCI interface, a MAC (Media Access Controller), an HDD interface, and the like. It helps to improve the efficiency of development of applications (application software) and common system services.
Further, the ASIC 202 is directly connected to an operation unit 209 such as an operation panel that receives an operation command of each engine unit, and a PHY 206 is also directly connected thereto. Further, the FCU 213, USB 214, IEEE 1394_215, and engine I / F 216 are connected via the PCI bus 218, and the modem 211, PI 212, and the like are directly connected as necessary.

The CPU 201 functions as a processing unit that processes information by reading out a necessary control program from a storage unit such as the flash memory 204 or the HDD 210 via the ASIC 202, and developing and executing the program on the SDRAM 203 or the like. be able to.
The SDRAM 203 is a main memory used as a program memory for storing various programs including an OS, a work memory used when the CPU 201 performs data processing, and the like. In place of the SDRAM 203, a DRAM or SRAM may be used.

  The flash memory 204 stores, for example, a boot loader (boot program) that activates the image processing apparatus 100, an OS image that is an OS file, a program memory that stores various programs for performing processing to be described later, and various fixed parameters. This is a non-volatile memory (storage means) used as a fixed parameter memory or the like, and holds the stored contents even when the power is turned off. Instead of the flash memory 204, a nonvolatile RAM in which a backup circuit using a RAM and a battery is integrated, or another nonvolatile memory such as an EEPROM may be used.

The NRS memory 205 is a non-volatile memory that stores an NRS application described later, and an NRS function can be added as an option.
The PHY 206 is an interface for communicating with an external device via a LAN.
The NVRAM 207 stores, for example, a model number memory that stores a model number that is identification information of the image processing apparatus 100, a memory that stores initial values for operations by the operation unit 209, and initial values for each application (APL). Non-volatile memory (storage means) used as a memory for storing counter information (charging counter data, etc.), a memory for storing setting information of itself and a communication partner, network address information, protocol information, etc. The stored contents are retained even when the power is turned off. As the NVRAM 207, a nonvolatile RAM in which a backup circuit using a RAM and a battery is integrated, or a nonvolatile memory such as an EEPROM or a flash memory can be used.

The operation unit 209 is operation display means (operation means and display means).
The HDD 210 is a storage unit (recording medium) that stores and saves data regardless of whether the power is on or off. The HDD 210 can store the above-described program in the flash memory 204, other data, or data in the NVRAM 207. In addition, data that is subject to processing such as collection, update, and transmission periodically may be stored in the HDD 210.
The modem 211 is modulation / demodulation means. When transmitting data to the intermediary server 102 via the public line, the modem 211 modulates the data so that it can be sent to the public line. When the modulated data sent from the mediation server 102 is received, the data is demodulated.

The PI 212 includes an interface conforming to the RS485 standard, and is connected to a public line via a line adapter (not shown).
The FCU 213 controls communication with an external apparatus such as a digital copying machine or a digital multifunction peripheral having a FAX apparatus or a modem function (FAX communication function) via a public line.
USB 214 and IEEE 1394 — 215 are USB standard and IEEE 1394 standard interfaces for communicating with peripheral devices, respectively.
The engine I / F 216 is an interface for connecting the engine unit 217 to the PCI bus.
The engine unit 217 is a post-processing unit that performs post-processing such as sorting, punching, and stapling on a sheet on which an image is formed by the plotter engine, or an image reading / forming engine including a known scanner engine and plotter engine. Etc.

  In such an image processing apparatus 100, when the power is turned on (power on), the CPU 201 activates the boot loader in the flash memory 204 via the ASIC 202, reads the OS image in the flash memory 204 according to the boot loader, and reads it as the SDRAM 203. And load it into a usable OS. When the OS deployment is completed, the OS is started. After that, various functions can be realized by reading a program such as an application in the flash memory 204 or an NRS application in the NRS memory 205 as needed, loading the program into the SDRAM 203, developing it, and starting it. .

Next, FIG. 10 shows a hardware configuration of the processing server.
As shown in this figure, each processing server 103 includes a CPU 301, a ROM 302, a RAM 303, an SD (Secure Digital) card 304, and a network interface card (NIC) 305, which are connected by a system bus 306.

These components will be described more specifically. First, the CPU 301 is a control unit that comprehensively controls the entire processing server 103 using a control program stored in the ROM 302. The ROM 302 is a read-only memory that stores various fixed data including a control program used by the CPU 301.
A RAM 303 is a temporary storage memory used as a work memory or the like when the CPU 301 performs data processing. The SD card 304 is a non-volatile memory that holds stored contents even when the power of the apparatus is turned off. The NIC 305 is a communication unit for transmitting / receiving information to / from a communication partner via a network such as the Internet 14.
It goes without saying that hardware may be added to these basic configurations as necessary.

Next, the functional block diagram of FIG. 11 shows the configuration of functions for performing processing related to commands and command responses among the functions of the mediation server 102.
Among the functions shown in FIG. 11, the terminal device command pool 41, the mediation server command pool 42, the transmission message pool 51 for transmission, and the message pool 52 for reception are provided in any rewritable storage means. For example, it can be provided in a flash memory or SDRAM or HDD in the control device 125, but it may be provided in the file server 126. The functions of the terminal device command execution result generation means 43, the mediation server command generation means 44, the message collection means 45, the message distribution means 47, and the message transfer means 48 are realized by the CPU of the control device 125. The functions of the HTTP server function unit 46 and the HTTP client function unit 49 are realized by the CPU of the control device 125 and the external connection I / F 123. The function of the transfer destination information storage unit 50 is realized by a non-volatile storage unit such as a flash memory or HDD in the control device 125.

These functions will be described in further detail.
First, the terminal device command pool 41 determines the terminal device commands received from the image processing apparatus 100 that the mediation server 102 itself should execute, the responses to these commands, the identification information of this command, and the transmission source It is a pool that is registered in association with the information.

The mediation server command pool 42 is a pool that registers mediation server commands in association with responses to the commands, identification information of the commands, destination information of the commands, and the like.
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.

  The terminal device command execution result generation unit 43 corresponds to a response generation unit. The terminal device command handler 43a is an application that reads out and executes a terminal device command from the terminal device command pool 41. The terminal device command handler 43a generates a response to the terminal device command, and a command ID of the terminal device command. In association with the terminal device command pool 41. The terminal device command received from the image processing apparatus 100 is registered in the terminal device command pool 41 as a table-format terminal device command sheet in association with an ID for identifying the command and management information for managing the command. I try to keep it. The command response generated by the terminal device command execution result generating unit 43 is also registered in the terminal device command sheet for the executed terminal device command when registering it in the terminal device command pool 41.

It is also conceivable to provide the terminal device command handler 43a with a function of reading out a plurality of types of terminal device commands from the terminal device command pool 41 and generating a response to each terminal device command. Further, when the terminal device command includes information on the execution priority for causing the mediation server 102 to execute the processing in priority, a function for preferentially reading out and executing the information from the higher priority may be provided. .
Note that the terminal device command handler 43a may be a module that calls an application necessary for execution of a terminal device command and executes the command instead of the application itself.

Here, FIG. 12 shows an example of the data structure in the terminal device command sheet of the mediation server 102.
As shown in this figure, in the intermediary server 102, the terminal device command sheet includes “command ID”, “transmission source information”, “method name”, “input parameter”, “state”, “output parameter”, And an area for storing “command notification destination” data. Of these, “command ID”, “method name”, and “input parameter” correspond to terminal device commands (and IDs attached thereto), and “status” and “command notification destination” are management information. Applicable. The “output parameter” is the execution result of the mediation server command, and is the content of the command response returned by the mediation server 102.

The contents of each data will be described.
First, “method name” is the content of a request to the mediation server 102 and indicates the type of function to be called in the mediation server 102. “Input parameter” is data attached to “method name”, and is an argument for calling a function.
“Transmission source information” indicates identification information of a command transmission source, that is, a device that has generated the command. In the case of a terminal device command, the identification information of the image processing apparatus 100 is registered here. This information is information indicating a destination when a response to the command is transmitted.
Since all terminal device commands to be stored in the terminal device command pool 41 are to be executed by the mediation server 102 itself, it is not necessary to manage the destination of the command.

  “Command ID” is identification information for identifying a terminal device command. “Status” is data indicating the status of processing related to the terminal device command. As the processing progresses, “Unprocessed” → “Processing completed” → “Response completed” or “Unprocessed” → “Processing” → “ The process proceeds from “Process completed” to “Responded”. The “output parameter” stores a response generated by the terminal device command execution result generation unit 43. It is empty until the execution of the terminal device command ends and the above “status” becomes “processing complete”. The “command notification destination” is reference information indicating a module that executes a terminal device command.

  Returning to the description of FIG. 11, the mediation server command generation unit 44 corresponds to a request generation unit. Then, an intermediary server command is generated, identification information (ID) for identifying the command is assigned, destination information of this command and management information for managing this command are attached, and these information are associated with each other in a table format. As a mediation server command sheet in the mediation server command pool 42. This processing is performed by the mediation server command generation handler 44a, and among them, for example, an application provided in the mediation server 102 corresponds to the portion that generates the mediation server command. Further, the mediation server command generation handler 44a may be provided with a function of attaching the priority order for causing the image processing apparatus 100 to execute each command to the generated mediation server command.

Here, FIG. 13 shows an example of the data structure in the mediation server command sheet of the mediation server 102.
As shown in this figure, in the mediation server 102, the mediation server command sheet includes “command ID”, “destination information”, “method name”, “input parameter”, “state”, and “command execution result notification”. An area for storing data of “first” and “output parameter” is provided. Of these, “command ID”, “method name”, and “input parameter” correspond to the intermediary server command (and the ID assigned thereto), and “status” and “notification destination of command execution result” are managed. Applicable to information. The “output parameter” is the content of the command response received from the image processing apparatus 100 that is the destination of the command.

The contents of each item will be described.
First, “method name” is the content of a request to the image processing apparatus 100 and indicates the type of function to be called in the image processing apparatus 100. “Input parameter” is data attached to “method name”, and is an argument for calling a function.
“Destination information” indicates identification information of a device that is to execute a command, that is, a device that is a destination of the command. In the case of a mediation server command, the identification information of the image processing apparatus 100 is registered here. As identification information, an ID, a unique name, an IP address, or the like can be used.
Since the mediation server command is always generated by the mediation server 102 itself, it is not necessary to manage the command transmission source information.

“Command ID” is identification information for identifying a mediation server command. “Status” is data indicating the progress of processing related to the terminal device command, and changes from “not transmitted” → “waiting for response” → “response received” as the processing proceeds.
The “command execution result notification destination” is reference information indicating a module that, when receiving a response to the mediation server command described in the sheet, notifies that fact and executes a necessary process. The module to be referred to is often a handler that registers the mediation server command, but it is not always necessary. The “output parameter” stores the contents when the command response is received. It is empty until a command response from the image processing apparatus 100 is received.

Returning to the description of FIG. 11 again, the message collecting means 45 corresponds to the collecting means. Then, the command response generated by the terminal device command execution result generation unit 43 is read from the terminal device command pool 41 in association with the command ID and the transmission source information of the terminal device command corresponding to the command response, and the mediation server command generation unit The intermediary server command generated by 44 is associated with the command ID and destination information of this command and read out from the intermediary server command pool 42, and further, the transfer described in the transfer message sheet of the transfer message pool 52 for reception, which will be described in detail later A function to read a message for use and generate a transmission message therefrom.
When priority is specified for a command response, a terminal device command, or a message for transfer, it is conceivable that the message collection unit 45 reads the messages in descending order of priority.

  Here, the transmission message is a description of the command response, the command, and the command ID as a SOAP message in XML (Extensible Markup Language) that is a structured language. The 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 command response and the content of the command are described in the SOAP body. In communication using SOAP, a message called a SOAP envelope (envelope) made up 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 transfer message is stored in the SOAP envelope state described in XML so that it can be used as it is as a transmission message.

  The HTTP server function unit 46 includes an HTTP response transmission unit 46a that transmits an HTTP response and an HTTP request reception unit 46b that receives an HTTP request. The HTTP response transmission unit 46 a corresponds to the second transmission unit, and has a function of generating an HTTP response describing the transmission message generated by the message collection unit 45 and transmitting the HTTP response to the image processing apparatus 100. At this time, any number of transmission messages may be included in one HTTP response, and transmission messages related to command responses, transmission messages related to mediation server commands, and transmission messages related to transfer messages may be arbitrarily mixed. Of course, transmission messages related to transfer messages generated by different processing servers may be mixed.

  Therefore, the HTTP response transmission unit 46a transmits all the transmission messages generated by the message collection unit 45 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, this HTTP response is transmitted when the message collection means 45 attempts to read out a mediation server command, a command response, a transfer message or the like, and there is no data to be read, and as a result a SOAP message to be transmitted is generated. This is also done when there is no such thing. This reading attempt is performed when the HTTP request receiving unit 46b receives an HTTP request from the image processing apparatus 100.
This is because the HTTP request cannot be transmitted from the mediation server 102 to the image processing apparatus 100 through the firewall 11 as described above.

The HTTP request receiving unit 46 b corresponds to a first receiving unit and has a function of receiving an HTTP request from the image processing apparatus 100. And here, in the HTTP request, the received message including the terminal device command and the command ID associated with the command, the response to the mediation server command or the processing server command and the received message including the command ID associated with the command, The received message including the message is arbitrarily mixed.
Here, the received message describes the above command, response, command ID, and the like as a SOAP message. Whether the message is addressed to the mediation server 102 or the message to be transferred to another device such as the processing server 103 is not distinguished at the time of reception, and includes information on the destination and transfer destination for that purpose. There is no need to be.

The message distribution unit 47 has a function of distributing and registering data included in the HTTP request received by the HTTP request reception unit 46b in the terminal device command pool 41, the mediation server command pool 42, and the transmission transfer message pool 51.
Specifically, referring to the transfer destination table stored in the transfer destination information storage means 50, the transfer destination determination means determines the transfer destination according to the received command and command response type and functions as the result. Based on this, determine the pool to be registered. Although details will be described later, the transfer destination table describes a transfer destination table in which a transfer destination of commands and command responses belonging to each group of commands and command responses is determined. Then, by searching the transfer destination table using the command or command response as a key, information on the transfer destination to which the command or command response should be transferred can be acquired.

  If the transfer destination of the received command (terminal device command) is the intermediary server 102 itself, a terminal device command sheet is provided in the terminal device command pool 41 for the terminal device command and the command ID associated with the command. register. Further, if the transfer destination of the received command response is the mediation server 102 itself, the response is a response to the mediation server command. Therefore, the mediation stored in the mediation server command pool 42 is a command ID associated with the command. The corresponding mediation server command is identified by collating with the command ID of the server command sheet, and is registered as an “output parameter” for the mediation 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).
On the other hand, for commands and command responses other than the mediation server 102 as a transfer destination, the messages related to the commands and command responses are registered in the transmission message pool 51 for transmission in order to transfer them to other devices. When registering in the transmission message pool 51 for transmission, a transfer message sheet is created and registered.

FIG. 14 shows an example of data structure in the transfer message sheet.
As shown in this figure, the transfer message command sheet of the transfer message pool 51 for transmission is provided with areas for storing “transfer destination information”, “entity header information”, and “message XML data”.
Of these, in the “transfer destination information”, information on the transfer destination determined according to the type of command or command response received by the message distribution unit 47 is registered. In the “entity header information”, information of the entity header of the part in which the message is described (details will be described later) is registered, and in the “message XML data”, the contents of the SOAP envelope related to the message are registered. Here, since the message for transfer may be transferred as it is regardless of the content of the message, it is not necessary to convert the data format of the SOAP envelope.
When the message distribution unit 47 registers a message in the transmission message pool 51 for transmission, the header that describes the transmission source information of the message is referred to by referring to the transmission source information of the HTTP request in which the message is described. Is generated and added to the entity header information.

  Returning to the description of FIG. 11 again, the message transfer means 48 reads the transfer message registered in the transfer message pool 51 for transmission to generate a transmission message, and also receives the HTTP response reception means of the HTTP client function unit 49. 49b has a function of registering the received message in the reception transfer message pool 52.

First, regarding generation of a transmission message, a transfer message to be transmitted to the transfer destination is read for each transfer destination. At this time, since the message is registered in the state of the SOAP envelope described in XML in the transfer message sheet, it can be used as it is as a transfer message. In addition, the SOAP message is attached with an entity header registered in the “entity header information” of the same sheet, and a transmission part describing the message is generated.
As for registration in the transfer message pool for reception 52, a transfer message sheet for registering the received message is created and registered. However, the format of this sheet is slightly different from the case of the transmission message pool 51 for transmission.

FIG. 15 shows an example of the data structure in the transfer message sheet of the reception transfer message pool 52.
As shown in this figure, the transfer message sheet of the reception transfer message pool 52 has an area for storing “entity header information” and “message XML data”.

Of these, the entity header information of the part in which the message was described (details will be described later) is registered in the “entity header information”, and the contents of the SOAP envelope related to the message are registered in the “message XML data”. Register. Here, the point that it is not necessary to convert the data format of the SOAP envelope is the same as in the case of the transmission message pool 51 for transmission.
In the case of the transfer message pool for reception 52, there is no item of “transfer destination information”, but this is because information on the transfer path of the message is described in the entity header.

  Returning to the description of FIG. 11 again, the HTTP client function unit 49 includes an HTTP request transmission unit 49a that transmits an HTTP request and an HTTP response reception unit 49b that receives an HTTP response. The HTTP request transmission unit 49 a corresponds to the first transmission unit, and has a function of generating an HTTP request that describes the transmission message generated by the message transfer unit 48 and transmitting the HTTP request to the processing server 103. 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 an image device command may be arbitrarily mixed. In the first place, when transferring a message, it is not necessary to recognize the content of the message as long as the transfer destination can be recognized. A transmission message related to a command, a command response, or a transfer message with different transmission sources may be mixed.

  Therefore, the HTTP request transmission unit 49a transmits all the transmission messages generated by the message transfer unit 48 for one transfer destination in one HTTP request regardless of any of the transmission messages. Yes. However, it is also conceivable to set an upper limit on the number of transmission messages included in one HTTP request.

  This HTTP request is transmitted when the message transfer means 48 attempts to read a transfer message for a certain transfer destination, and there is no read data, and as a result, a SOAP message to be transmitted is not generated. It is also what you 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 desired to be transmitted from the processing server 103 to the mediation server 102, the information cannot be transmitted unless communication is requested from the mediation server 102. Even if there is no data to be transmitted from the mediation server 102, by periodically transmitting a communication request to each processing server 103 and giving an opportunity to transmit information from each processing server 103 to the mediation server 102. Therefore, it is possible to prevent information that needs to be transferred from staying in the processing server 103 for a long period of time.

  Of course, the reading by the message transfer means 48 and the subsequent transmission of the HTTP request by the HTTP request transmission means 49a may be appropriately performed in addition to the regular timing. For example, when information that needs to be transmitted urgently is registered in the transmission message pool 51 for transmission, the message distribution unit 47 may notify the message transfer unit 48 to read out the information.

  The HTTP response receiving unit 49b corresponds to a second receiving unit and has a function of receiving an HTTP response from the processing server 103. In this case, the HTTP response includes a received message including a processing server command and a command ID associated with the command, and a received message including a response to the terminal device command and a command ID associated with the command. It is mixed and included.

  The received message describes the command, response, command ID, and the like as a SOAP message. Since these are messages to be transferred to the image processing apparatus 100, they are registered in the reception transfer message pool 52 by the message transfer means 48 as described above, read out by the message collection means 45 at an appropriate timing, and HTTP. The response is transmitted to the image processing apparatus 100 by the response transmission unit 46a.

  Note that at the time of registration in the reception transfer message pool 52, it is not necessary to change the correspondence depending on where the message is transferred. When the message collection unit 45 reads a message from the reception transfer message pool 52 and generates a transmission message, the message collection unit 45 tries to transmit the message from among the transfer route information described in the “entity header information”. The entity header part is generated after the destination information is deleted.

Next, FIG. 16 shows an example of an HTTP request received from the image processing apparatus 100 by the mediation server 102 having such a function.
In this HTTP request, as shown in FIG. 16, a multi-part message according to MIME (Multipurpose Internet Mail Extension) is described as a body part, and in each part, an entity header is described, and detailed information is provided. Although not shown, a SOAP envelope is embedded. In the example of FIG. 16, in the HTTP body of the HTTP request, each element divided by “MIME_boundary” constitutes 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 in the HTTP request and delivered includes a terminal device command, a response to the mediation server command, and a response to the processing server command.
FIG. 17 shows an example of an HTTP response transmitted from the mediation server 102 having such a function to the image processing apparatus 100.

As shown in FIG. 17, this HTTP response is different only in the HTTP request shown in FIG. 16 and the HTTP header part, and the detailed illustration is omitted in the body part 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 are naturally different according to the contents of the command and command response.
The SOAP envelope embedded in the HTTP response and delivered includes one that describes a mediation server command, one that describes a processing server command, and one that describes a response to a terminal device command.

Next, FIG. 18 shows an example of an HTTP request transmitted from the mediation server 102 to the processing server 103.
As shown in FIG. 18, this HTTP request has the same format as the HTTP request shown in FIG. However, the contents of the SOAP envelope naturally differ according to the contents of the command and command response. The SOAP envelope embedded in the HTTP request and delivered includes a terminal device command and a response to the processing server command.

  In addition, information indicating the source of the SOAP message described in the part is added to the entity header of each part by the message distribution unit 47 of the mediation server 102 as an “X-Received-From” header. As will be described later, the processing server 103 can determine a response to the terminal device command and a transfer path of the processing server command based on this information.

An example of an HTTP response received by the mediation server 102 from the processing server 103 is shown in FIG.
As shown in FIG. 19, this HTTP response has the same format as the HTTP response shown in FIG. However, 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 description of a processing server command and a description of a response to a terminal device command.

  In addition, information indicating the transfer route and destination of the SOAP message described in the part is added to the entity header of each part as an X-Send-To header. The message collection unit 45 of the mediation server 102 can recognize the message transfer destination based on this information.

The HTTP request and HTTP response in the above format are one message that can be transferred, and a plurality of SOAP envelopes of each part can be combined and generated without changing the format. In addition, by dividing the HTTP request and HTTP response in such a format and extracting the SOAP envelope of each part, the HTTP request or HTTP can be exchanged with another communication apparatus having a normal web service (SOAP RPC) function. It can also be used as it is for communication in which one SOAP envelope is described in the response.
In the messages exchanged between the image processing apparatus 100 and the mediation server 102 as shown in FIGS. 16 and 17, it is not necessary to describe the destination of the SOAP message and the transfer route.

Next, specific examples of the parts described in these HTTP requests or HTTP responses are shown in FIGS.
FIG. 20 shows an example of a part in which terminal device commands for the mediation server (device management server) 102 are described.
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, the URIs of “http://www.example.com/header” and “http://www.example.com/maintenance/server” The specified 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.example.com/header”. It can be seen that the XML tag with the namespace prefix “” belongs to the namespace specified by the URI “http://www.example.com/maintenance/server”.

Also, in the SOAP header, “12345” that is the ID of this terminal device command is described as the content of the XML tag of “request ID”.
In the SOAP body, an “abnormality notification” tag is described immediately below the “Body” tag as information for specifying a method to be called in the mediation server 102 (corresponding to “method name”, indicating the type of command), and As elements of the lower tag “error ID” and “description”, an argument for calling the method is described (corresponding to “input parameter”). Here, the notification content of the abnormality notification is described.

  Note that the message described in this part is to be executed by the mediation server 102 is recognized by the message distribution unit 47 of the mediation server 102 according to the type of command. Accordingly, the command destination and transfer destination are not described in this part, and it is not necessary for the image processing apparatus 100 to recognize in which apparatus the command is finally executed.

FIG. 21 shows an example of a part describing a response to the terminal device command shown in FIG.
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 declaration of the namespace is the same as the example shown in FIG. In the SOAP header, “12345” that is the ID of the terminal device command that generated the response is described as the content of the XML tag of “command ID”.

The SOAP body is provided with an “abnormal notification response” tag (indicating the type of command response) immediately below the “Body” tag to indicate that it is a response to the “abnormal notification” command. The contents of the command response are described. Here, information indicating that the abnormality notification has been normally received is described. This information is stored in the “output parameter” item of the terminal device command sheet in the image processing apparatus 100 as will be described later.
In this distributed processing system, since it is not necessary for the image processing apparatus 100 to recognize which apparatus the command response is generated from, the transmission source of the command response is not described in this part.

FIG. 22 shows a description example of a part when a terminal device command for the processing server (sales management server) 103 a is transferred from the image processing device 100 to the mediation server 102.
Also in this example, as in the case of FIG. 20, the “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 an attribute of the “Envelope” tag as in the case of FIG. And here, in addition to the namespace defined as a standard in SOAP, the URIs of “http://www.example.com/header” and “http://www.example.com/sales/server” The specified namespace is declared.
In the SOAP header, “12346” that is the ID of this image device command is described as the content of the XML tag of “request ID”.

In the SOAP body, a “paper order” tag is described immediately below the “Body” tag as information for specifying a method to be called in the processing server 103a. Arguments when calling the method are described. Here, the order contents of the paper are described.
Note that the message distribution means 47 of the mediation server 102 recognizes that the command described in this part should be transferred to the processing server 103a according to the type of command. Accordingly, neither the command destination nor the transfer destination is described in this part, and it is not necessary for the image processing apparatus 100 to recognize which apparatus will eventually execute this command.

FIG. 23 shows a description example of a part when the command shown in FIG. 22 is transferred from the mediation server 102 to the processing server 103a.
Since this part is used when the same command as shown in FIG. 22 is transferred to the processing server 103a, almost the same contents as the part shown in FIG. 22 are described. However, an “X-Received-From” header is added to the entity header, and information indicating that the command described in this part is transmitted from “Cilent_A” (referred to as the image processing apparatus 100) is described. Yes. This information is used to designate a transfer path when a command response is returned after the command is executed.

Although the identification information of the image processing apparatus 100 that is the command transmission source is described here, if the command is transferred across a plurality of apparatuses, an “X-Received-From” header is sent for each transfer. Are sequentially added, and the identification information of the device that is the transmission source nearest to the device that generated the part is described in the lowermost row and the device that is the transmission source of the command is described in the lowermost row.
Again, it is not necessary to describe the destination of the command in the part. This is because the intermediary server 102 only recognizes a transfer destination to which the command is transferred next, and does not need to recognize which device is finally transferred.

FIG. 24 shows a description example of a part when a response to the terminal device command to the processing server 103a is transferred from the processing server 103a to the mediation server 102.
Also in this example, as in the case of FIG. 21, 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.

In addition, the transfer path when the command response is transferred from the mediation server 102 is described in the “X-Send-To” header. Here, the identification information of the image processing apparatus 100 that is the final destination is described. However, when the transfer path extends to a plurality of apparatuses, a plurality of “X-Send-To” headers are provided to form the path. The identification information of the device is sequentially described, and the identification information of the device serving as the next transfer destination is described at the bottom and the final destination is described at the top.
Also in this example, the namespace declaration is the same as in the example shown in FIG. In the SOAP header, “12346” that is the ID of the terminal device command that generated the response is described as the content of the XML tag of “command ID”.

In the SOAP body, a “paper order Response” tag is provided immediately below the “Body” tag to indicate that it is a response to the “paper order” command, and the contents of the command response are described in the lower tag. The Here, information indicating that the paper order has been successfully received and information for notifying the charge are described.
In this distributed processing system, since it is not necessary for the mediation server 102 to recognize which device the command response is generated from, the source of the command response is not described in this part.

FIG. 25 shows a description example of a part when the command response shown in FIG. 24 is transferred from the mediation server 102 to the image processing apparatus 100.
Since this part is used when the same command response as that shown in FIG. 24 is transferred to the image processing apparatus 100, almost the same contents as the part shown in FIG. 24 are described. However, since there is no longer any need for transfer path information to transfer to the image processing apparatus 100, the “X-Send-To” header in the entity header portion is deleted.

FIG. 26 shows an example of a part describing a mediation server command for the image processing apparatus.
Also in this example, as in the case of FIG. 20, the “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. Since the command can be directly transferred from the mediation server 102 to the image processing apparatus 100, an “X-Send-To” header indicating transfer path information is not described.

Also, the name space is declared as an attribute of the “Envelope” tag as in the case of FIG. And here, in addition to the namespace defined as a standard in SOAP, the URIs of “http://www.example.com/header” and “http://www.example.com/maintenance/client” The specified namespace is declared.
In the SOAP header, “98765” that is the ID of this mediation server command is described as the content of the XML tag of “request ID”.

In the SOAP body, a “temperature sensor value acquisition” tag is described as information specifying a method to be called in the image processing apparatus immediately below the “Body” tag, and as an element of a lower tag “sensor ID”, Arguments when calling the method are described. Here, the ID of the sensor for acquiring the sensor value is described.
In addition, since the image processing apparatus 100 can recognize that a command response to the received command should be transmitted to the mediation server 102 for the time being, information on the command transmission source is described in the part. Absent.

FIG. 27 shows an example of a part describing a response to the mediation server command shown in FIG.
Also in this example, as in the case of FIG. 21, 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 mediation 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 immediately below the “Body” tag to indicate that it is a response to a “temperature sensor value acquisition” command. The contents are described. Here, information on the temperature value indicated by the sensor whose value is requested is described.

  Note that the command response described in this part is for the mediation server command and that the mediation server 102 is the destination, so that the message distribution unit 47 of the mediation server 102 recognizes according to the type of the command response. is there. Therefore, it is not necessary to describe the destination and transfer destination of the command response in this part, and it is not necessary for the image processing apparatus 100 to recognize to which apparatus the command response is finally transferred.

FIG. 28 shows a description example of a part when a processing server command for the image processing apparatus is transferred from the processing server 103 a to the mediation server 102.
Also in this example, as in the case of FIG. 20, the “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. In addition, the processing server 103a can recognize the transfer path and destination of the command, and the transfer path for transferring the command from the mediation server 102 to the destination is “X-Send-To” as in FIG. ”In the header.

Further, as in the case of FIG. 20, the namespace is declared as an attribute of the “Envelope” tag. And here, in addition to the namespace defined as a standard in SOAP, the URIs of “http://www.example.com/header” and “http://www.example.com/sales/client” The specified namespace is declared.
In the SOAP header, “77777” that is the ID of this processing server command is described as the content of the XML tag of “request ID”.

In the SOAP body, a “new product information notification” tag is described immediately below the “Body” tag as information for designating a method to be called in the image processing apparatus 100, and tags “product name” and “unit price” below that tag are described. As an element, an argument for invoking the method is described. Here, the brand name and unit price of the new product are described.
As will be described later, since the intermediary server 102 can transfer the command response to an appropriate transfer destination without knowing where the command has been transmitted from, information on the command transmission source is described in the part. Not done.

FIG. 29 shows a description example of a part when the processing server command shown in FIG. 28 is transferred from the mediation server 102 to the image processing apparatus 100.
Since this part is for transferring the same processing server command as that shown in FIG. 28 to the image processing apparatus 100, almost the same contents as the part shown in FIG. 28 are described. However, since there is no longer any need for transfer path information to transfer to the image processing apparatus 100, the “X-Send-To” header in the entity header portion is deleted.
On the image processing apparatus 100 side, it is possible to recognize that the command response to the received command should be transmitted to the mediation server 102 for the time being, and it is not necessary to recognize where the command response is transferred thereafter. In the part, information of the command transmission source is not described.

FIG. 30 illustrates a description example of a part when the response to the processing server command illustrated in FIG. 28 is transferred from the image processing apparatus 100 to the mediation server 102.
Also in this example, as in the case of FIG. 21, 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, “77777” that is the ID of the processing server command that generated the response is described as the content of the XML tag of “command ID”.
In the SOAP body, a “new product information notification” response tag is provided immediately below the “Body” tag to indicate that it is a response to the “new product information notification” command. The contents are described. Here, information indicating that the notification has been normally received is described.

  Note that the message distribution means 47 of the mediation server 102 recognizes that the command response described in this part is for the processing server command and should be transferred to the processing server 103a according to the type of the command response. . Therefore, it is not necessary to describe the destination and transfer destination of the command response in this part, and it is not necessary for the image processing apparatus 100 to recognize to which apparatus the command response is finally transferred. Further, the mediation server 102 does not need to know which device the command response is finally transferred to.

FIG. 31 shows a description example of a part when the command response shown in FIG. 30 is transferred from the mediation server 102 to the processing server 103a.
Since this part is for transferring the same command response as that shown in FIG. 30 to the processing server 103a, almost the same contents as the part shown in FIG. 30 are described. Although the “X-Received-From” header is added to the entity header portion as in the case of FIG. 23, it is not necessary to receive a response to the command response, so this description is not essential here. The point that the destination of the command response is not described in the part is the same as in FIG.

  Next, processing executed in the mediation server 102 having the configuration and functions described above will be described with reference to the flowcharts of FIGS. The processing shown in these flowcharts requires the CPU of the control device 125 (in the description of FIGS. 32 to 41, unless otherwise specified, this CPU is simply referred to as “CPU”). This is done by executing a control program.

First, FIG. 32 shows a flowchart of basic operations of message collection and distribution processing.
When an HTTP request is transmitted from the image processing apparatus 100, the CPU starts the process shown in the flowchart of FIG.
First, the HTTP request is received from the image processing apparatus 100 (S11), and the HTTP body of the received HTTP request is divided into parts (S12). Here, the division into parts is to divide into elements divided by “MIME_boundary”, and here, all parts are divided.

Thereafter, the message distribution process in step S13 is repeated for all the parts obtained by the division in order. Then, when these processes are performed for all the parts, the process proceeds to the next step S14.
In the processing so far, steps S11 and S12 are processing of the first reception procedure, and here, the CPU functions as the HTTP request receiving means 46b. In step S13, the CPU functions as the message distribution unit 47.

The processing after step S14 is processing related to transmission of an HTTP response to the image processing apparatus 100. In this process, first, the CPU performs a transfer message collection process (S14). This process is a process of collecting messages to be transferred from the reception transfer message pool 52 to the image processing apparatus 100, and includes a process of generating a part related to transfer from the collected messages.
Thereafter, a mediation server command collection process is performed (S15). This process is a process of collecting a mediation server command to be transmitted from the mediation server command pool 42 to the image processing apparatus 100, and includes a process of generating a part by a SOAP envelope from the collected data.

Next, terminal device command execution result collection processing, which is a response to the terminal device command, is collected (S16). This process is a process of collecting command responses to be transmitted from the terminal apparatus command pool 41 to the image processing apparatus 100, 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 S14 to S16 are merged into one, an HTTP response including all the parts is generated (S17), and the HTTP response is transmitted to the image processing apparatus 100 (S18). Note that the processes in steps S14 to S16 may be in any order.
In the processing so far, the CPU functions as the message collecting means 45 in steps S14 to S16. Steps S17 and S18 are processes of the second transmission procedure. Here, the CPU functions as the HTTP response transmission unit 46a.

Next, the processing shown in the flowchart of FIG. 32 will be described using the flowchart shown in detail one by one.
FIG. 33 is a flowchart showing the details of the message distribution process shown in FIG.

  In this process, the CPU first acquires the name space URI of the tag immediately below the Body tag from the SOAP message of the target part (S21). As shown in the examples of FIGS. 20 to 31, in the SOAP message, a tag indicating the type of command or command response is described in the tag immediately below the Body tag. Further, a namespace prefix (for example, “ns” in the case of FIG. 20) is attached to this tag. From this namespace prefix and the definition contents of the namespace in the “Envelope” tag, The tag namespace URI can be obtained. Further, since the namespace URI is used for tag grouping, commands or command responses having the same namespace URI can be considered as commands or command responses belonging to the same group.

Next, the transfer destination table stored in the transfer destination information storage means 50 is searched using the acquired name space URI as a key, and the transfer destination information of the message of the target part is acquired (S22).
An example of this transfer destination table is shown in FIG.
As shown in this figure, in the transfer destination table, information on transfer destinations of commands or command responses belonging to the name space is described for each name space URI. The transfer destination information is preferably stored as an IP address, a host name, or the like. At this time, of course, the same transfer destination may be associated with different name space URIs.

  Then, by searching this table using the namespace URI acquired in step S21 as a key, the transfer destination of the message of the target part can be acquired. At this time, it is not necessary to distinguish whether the message of the target part relates to a command or a command response. For example, if the target part is the part shown in FIG. 20, the tag immediately below the “Body” tag belongs to the namespace “http://www.example.com/maintenance/server”. It can be seen that the transfer destination of the message related to the part is the mediation server 102 itself. If the name space URI is not included in the transfer destination table, error processing may be performed.

Next, it is determined whether or not the transfer destination acquired in step S22 is the mediation server 102 (self) (S23). If it is itself, it can be seen that the target part is a response to the mediation server command or a terminal device command to be executed by the mediation server.
Therefore, it is determined which of the target parts is. FIG. 33 describes that it is determined whether or not the response is to the mediation server command (S24). This determination can be made based on whether or not the “SOAPAction” header exists in the target part, or based on the content of the “X-SOAP-Type” header.

And if it is a response with respect to a mediation server command, the process which concerns on the registration of the response will be performed by step S25 thru | or S28.
That is, first, the SOAP envelope of the part is analyzed and converted into data in a format that can be registered in the mediation server command sheet (S25), the mediation server command corresponding to the response is searched from the mediation server command pool 42, and the mediation server Response data is registered in the “output parameter” item of the mediation server command sheet for the command (S26). The command response is assumed to have the same command ID as the information that is given at the time of transmission of the mediation server command as information of “command ID”, and the mediation server command search is performed using this information as a key. Can do.

  When the data registration is completed, the “status” of the mediation server command sheet in which the data is registered is changed to “response received” to indicate that (S27). Then, the notification destination registered in the “command execution result notification destination” is notified that a response has been received (S28). By this notification, the application or the like that generated the mediation 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 image processing apparatus 100 generates a mediation server command for acquiring the sensor value of the temperature sensor of the image processing apparatus 100, when this command is transmitted to the image processing apparatus 100, The processing device 100 returns a command response including the requested sensor value. Upon receiving this command response, the mediation server (device management server) 102 searches for the mediation server command to which the response is based on the command ID included therein, and associates it with the found mediation server command. Register the command response. Then, it notifies the application corresponding to the occurrence of the abnormality registered as the command execution result notification destination that the response has been received. If the application receives this notification and refers to the mediation server command sheet, the application can acquire the execution result of the generated command from the “output parameter” item.
When the process up to step S28 is completed, the process in FIG. 33 is terminated and the process returns to the original process.

If the response is not a response to the mediation server command in step S24, the target part is a terminal device command to be executed by the mediation server, and thus processing related to registration of the command is performed in steps S29 to S33.
That is, first, the SOAP envelope of the part is analyzed and converted into data that can be registered in the terminal device command sheet (S29), and a terminal device command sheet for registering the terminal device command is created in the terminal device command pool 41. Then, the terminal device command, the command ID, and the transmission source information are registered in the terminal device command sheet (S31).

  Here, the contents of the terminal device command are registered in the “method name” and “input parameter” items of the terminal device command sheet, and the command ID described in the part is registered in the “command ID” item. As for “source information”, the source information of the HTTP request in which the target part is described can be acquired and registered. Also, if there is an “X-Received-From” header in the entity header of the target part, its content is also registered as transfer path information. In addition, the initial value of “state” is “unprocessed”, and the initial value of “output parameter” is NULL.

When the registration to the above items is completed, reference information to the handler (terminal device command handler 43a) for executing the method stored in the “method name” of the terminal device command sheet is prepared in advance. A search is made by referring to the information on the correspondence between the method and the handler (S32), and the found reference information is registered in the “command notification destination” item of the terminal device command sheet (S33).
When the process up to step S33 is completed, the process in FIG. 33 is terminated and the process returns to the original process.

If the transfer destination is not itself in step S23, the message of the target part is to be transferred to another device, and therefore, processing related to registration of the transfer message is performed in steps S34 to S36.
That is, first, a transfer message sheet for registering the message is created in the transmission transfer message pool 51 (S34), and the message and transfer destination information of the message are registered in the transfer message sheet (S35).

Here, the entity header of the target part is directly registered in the “entity header information” item, and the contents of the SOAP envelope are registered as they are in the “message XML data” item. Also, for “transfer destination information”, the information acquired in step S22 is registered.
When the registration to the above items is completed, an “X-Received-From” header is added to the end of the entity header registered in “Entity header information”, and the target part is used as the message sender information. The information of the transmission source of the HTTP request that has been described is described (S36).
When the process up to step S36 is completed, the process in FIG. 33 is terminated and the process returns to the original process.
After the process of FIG. 33 is completed, the process returns to the process of FIG. 32. As shown in this figure, if there is a next part, the process of FIG. 33 is repeated for that part.

Next, FIG. 35 shows the transfer message collection process shown in step S14 of FIG. 32 in more detail.
In this process, the CPU first transfers a transfer message sheet in which the transmission source of the HTTP request received in step S11 in FIG. Are collected (S41). The information registered in the transfer message sheet in the reception transfer message pool 52 is as shown in FIG. 15, and the “X-Send-To” header is registered in the “entity header information” item. Has been.

Next, the processing of steps S42 and S43 is repeated for all the transfer message sheets collected in step S41.
In this process, first, a part of the transfer message described in the target transfer message sheet is generated (S42). In this process, the entity header registered in the “entity header information” item is added to the SOAP envelope registered in the “message XML data” item of the target sheet. However, the contents of the bottom “X-Send-To” header in the entity header do not need to be transmitted to the transfer destination device, so this header is removed.
When the part creation is completed, the target transfer message sheet is deleted from the reception transfer message pool 52 (S43). Then, when these processes are performed on all the collected sheets, the process proceeds to step S15 in FIG.

Next, FIG. 36 shows the process after step S15 in FIG. 32 in more detail.
In this process, the CPU firstly receives from the mediation server command pool 42 the mediation server command sheet whose destination information is equal to the transmission source of the HTTP request received in step S11 in FIG. 32 and whose “status” is “unsent”. The contents of “method name” and “input parameter” are collected as a mediation server command to be transmitted, and the contents of “command ID” are also collected as the command ID of the command (S51). The “state” of “unsent” indicates that the command has not been transmitted to the image processing apparatus 100 after being generated by the mediation server command generation unit 44, and therefore the image processing apparatus 100 is based on this. You can extract commands to send to.

  Thereafter, the processes in steps S52 to S54 are repeated for all the mediation server commands collected in step S51. In the processing of this part, first, the target mediation server command and its command ID are converted into an XML document (SOAP envelope) in which these pieces of information are included in the SOAP body and the SOAP header (S52). A header is added to generate a part related to the target command (S53). Then, the “status” of the mediation server command sheet describing the target mediation server command is changed to “waiting for response” (S54). The “status” of “waiting for response” indicates that the command has been transmitted to the image processing apparatus 100.

Then, when these processes are performed for all collected mediation server commands, the process proceeds to step S55.
Here, the CPU sends the source information from the terminal device command pool 41 equal to the source of the HTTP request received in step S11 of FIG. The content of “output parameter” is collected as a command response to the terminal device command to be transmitted, and the content of “command ID” is also collected as the command ID of the corresponding terminal device command (S55). In the mediation server 102, the “state” of “processing completed” indicates that the processing corresponding to the terminal device command has been generated by the terminal device command execution result generation unit 43 and has not yet been notified to the image processing apparatus 100. Therefore, the command response to be transmitted to the image processing apparatus 100 can be extracted based on this.

  Thereafter, the processing of steps S56 to S58 is repeated for all command responses collected in step S55 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 (SOAP envelope) in which the information is included in the SOAP body and the SOAP header (S56). An entity header is added to generate a part related to the target command (S57). These processes are the same as the processes in steps S52 and S53 except that the objects are different. Then, the “status” of the terminal device command sheet in which the target command response is described is changed to “responded” (S58). The “status” of “response completed” indicates that the command response has been notified to the image processing apparatus 100 here.

Then, after all the processes so far are completed, the CPU merges the parts generated in step S53, S57 or step S42 in FIG. 35 to generate a multi-part HTTP response as shown in FIG. The image is transmitted to the image processing apparatus 100 (S59), and the process is terminated.
As described above, by performing the message distribution and collection processing described with reference to FIGS. 32 to 36, the mediation server 102 collectively receives a plurality of operation requests and operation responses from the image processing apparatus 100. Even when a destination is not attached to them, an appropriate transfer destination can be automatically recognized and a response corresponding to the transfer destination can be performed. Also, a plurality of operation requests and operation responses that are generated by the device or received from another device and that should be transferred to the image processing device 100 can be transferred to the image processing device 100 in a lump.

Note that the change of the “state” performed in step S54 or S58 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. The same applies to the deletion of the transfer message sheet performed in step S43 of FIG.
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 response 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 such a case, the memory capacity can be reduced as in the case of the transmission side.

Next, processing relating to execution of a terminal device command will be described.
FIG. 37 is a flowchart showing an example of this process.
As processing related to the execution of the terminal device command, first, the processing shown in the flowchart of FIG. 37 is performed after the processing of step S33 shown in FIG. 33, that is, immediately after registering the terminal device command in the terminal device command pool 41. Can be considered. In this process, the CPU functions as the terminal device command execution result generation unit 43.

  In this process, first, an application is called based on the “command notification destination” information in the terminal device command sheet for the registered terminal device command, and the “method name” and “input parameter” data are passed. The process related to the terminal device command is executed (S61). Note that the processing related to the terminal device command itself is not shown in this flowchart, but is separately executed by the CPU using a handler.

  When this is completed, the execution result is acquired and registered in the “output parameter” item of the terminal device command sheet (S62), and at the same time, the “state” of the terminal device command sheet is changed to “processing completed”. Indicates completion (S63). By performing the above processing, the terminal device command can be executed, and the result can be sent to the image processing apparatus 100 as a command response.

Further, as processing related to the execution of the terminal device command, the processing shown in the flowchart of FIG. 38 is performed independently of the processing related to transmission / reception of the message with the image processing device 100 shown in FIG. You can also. Also in this process, the CPU functions as the terminal device command execution result generation unit 43.
This process is started when the CPU starts up the mediation server 102. In this process, first, it is determined whether or not there is a terminal device command sheet whose “state” is “unprocessed” in the terminal device command pool 41 (SX1). Wait until As described above, the state of “unprocessed” is an initial value of “state” in the terminal device command sheet, and indicates that no processing is performed after registration of the command.

If a “unprocessed” terminal device command sheet is found in step SX1, one of the terminal device command sheets is processed, and the “status” of the terminal device command sheet is changed to “processing” (SX2).
Thereafter, the same processing of steps S61 to S63 as in the case of FIG. 37 is performed to execute the terminal device command described in the terminal device command sheet to be processed.

The above processing may be performed simultaneously by a plurality of threads (for example, 4 threads). Since the “status” of the terminal device command sheet that is the processing target is not “unprocessed”, even if processing is performed simultaneously by multiple threads, it is not possible to duplicate one terminal device command sheet as the processing target. Absent.
If the processing as described above is performed, the terminal device command can be executed at an arbitrary timing, so that even if there is a command that takes time to execute, the subsequent processing will not be delayed. Then, in order from the end of execution, the result can be sent to the image processing apparatus as a command response.

Next, FIG. 39 shows a flowchart of processing related to message transfer with the processing server. This process is executed by the CPU at an appropriate timing for any one of the transfer destinations described in the transfer destination table shown in FIG. 34 (here, the processing server 103).
In this process, first, a transfer message sheet in which the target transfer destination is registered in the item “transfer destination information” is collected from the transmission transfer message pool 51 (S71). Then, the processes in steps S72 and S73 are repeated for all the transfer message sheets collected in step S71.

  In these processes, first, a part of the transfer message described in the target transfer message sheet is generated (S72). In this process, the entity header registered in the “entity header information” item is added to the SOAP envelope registered in the “message XML data” item of the target sheet.

When the creation of the part is completed, the target transfer message sheet is deleted from the transmission transfer message pool 51 (S73). Then, when these processes are performed for all the collected sheets, the generated parts are merged into one (S74), and a multipart HTTP request as shown in FIG. (S75).
In the processing so far, the CPU functions as the message transfer means 48 in steps S71 to S73. Steps S74 and S75 are processes of the first transmission procedure. Here, the CPU functions as the HTTP request transmission unit 49a.
Note that the deletion of the transfer message sheet performed in step S73 may be performed after the transmission is actually completed, as in the case of step S43 in FIG. 35 described above.

  Next, an HTTP response is received from the target transfer destination as a communication response to the transmitted HTTP request (S76). Then, the HTTP body of the received HTTP response is divided into each part (S77). Here, the division into each part is to divide into elements divided by “MIME_boundary” as in the case of step S12 in FIG. 32, and here, all parts are divided.

Thereafter, the processes in steps S78 and S79 are repeated for all the parts obtained by the division in order.
In these processes, a transfer message sheet for registering a target message is first created in the reception transfer message pool 52 (S78), and the target message is registered in the transfer message sheet (S79). Here, the entity header of the target part is directly registered in the “entity header information” item, and the contents of the SOAP envelope are registered as they are in the “message XML data” item. The “X-Send-To” header is not deleted at this point.

When these processes are performed for all the parts obtained in step S77, the process of FIG. 39 is terminated.
In the above processing, steps S76 and S77 are processing of the second reception procedure, and here, the CPU functions as the HTTP response receiving means 49b. In steps S78 and S79, the CPU functions as the message transfer means 48.

Here, FIG. 40 shows a flowchart of processing relating to execution timing control of the message transfer processing shown in FIG.
This process is started when the CPU starts up the mediation server 102. In this process, the message transfer process shown in FIG. 39 is sequentially performed on all transfer destinations described in the transfer destination table shown in FIG. 34 at regular intervals. In this case, even when the same transfer destination appears in the transfer destination table a plurality of times, it is sufficient to perform one message transfer process for one transfer destination.

  As described above, when the message transfer process is periodically performed for all the transfer destinations to which the message can be transferred and the HTTP request as the communication request is transmitted, the communication from the mediation server 102 to the transfer destination is always performed as an intermediary. Even when it is performed by transmitting a communication request from the server 102 side, an opportunity to transmit information from the transfer destination to the intermediary server 102 can be given, and information that needs to be transferred to the intermediary server 102 can be transmitted over a long period of time. Can be prevented from staying in the processing server 103 or the like.

  It goes without saying that the message transfer process may be performed as appropriate in addition to the regular timing. For example, when information that needs to be transmitted urgently is registered in any of the pools, the message distribution unit 47 may notify the message transfer unit 48 to perform the message transfer process. In this way, when a command is registered, it can be immediately transferred to the transfer destination.

  As described above, by performing the processing related to message transfer shown in FIGS. 39 and 40, for each of a plurality of transfer destinations, the operation request and the operation response to be transferred to the transfer destination are collectively transferred. The operation request and the operation response to be transmitted to the image processing apparatus 100 from the transfer destination can be collectively received and stored in a state that can be independently transmitted to the image processing apparatus 100.

Note that when only the command from the image processing apparatus 100 needs to be handled, the processing shown in the flowchart of FIG. 41 may be performed instead of or in addition to the processing shown in FIGS. Conceivable.
This process is started when the CPU starts up the mediation server 102, as in the case of FIG. In this process, first, it is determined whether or not there is a transfer message sheet describing the command in the transmission transfer message pool 51 (S91), and if not, the process waits until such a transfer message sheet is found.

  If a transfer message sheet describing the command is found in step S91, one of them is targeted for processing, and the contents of the “X-Received-From” header described in the transfer message sheet are stored (S92). Then, referring to the “transfer destination information” of the target sheet, an HTTP request describing the transfer message (SOAP request) described in the target sheet is transmitted to the transfer destination (S93). When a transfer message is generated, a necessary HTTP header may be attached to the SOAP envelope registered in the “message XML data” item. At this time, the entity header information registered in the item “entity header information” can be used.

  Thereafter, an HTTP response to the transmitted HTTP request is received from the transfer destination (S94), and this should contain a SOAP response to the transmitted SOAP request. Therefore, a transfer message sheet is created in the reception transfer message pool 52, and the contents of the SOAP message described in the received HTTP response are registered in the created transfer message sheet (S95). For this registration, the SOAP envelope part is registered as it is in the “message XML data” item, and the necessary part in the HTTP header is registered in the “entity header information” item.

Then, an “X-SOAP-Type” header and “Response” are added to the “entity header information” of the created transfer message sheet, and an “X-Send-To” header is added. The contents of the stored “X-received-From” header are described here (S96). And it returns to step S91 and repeats a process.
With the above processing, the command response can be acquired from the command transfer destination and the contents can be registered in the reception transfer message pool 52. Therefore, the registered command response is registered by the processing of FIG. 39 and FIG. Similarly, the message can be collected by the message collecting unit 45 and transmitted to the image processing apparatus 100.

Further, if such processing is performed, the command can be transferred and executed even when the transfer destination apparatus does not support batch transfer as shown in FIG. If a command is registered, it can be immediately transferred to the transfer destination.
Above, description of the process regarding the transfer of each command and command response executed in the mediation server 102 is completed.

Next, a functional configuration for handling commands and command responses on the image processing apparatus 100 side will be described. The hardware is as described with reference to FIG.
FIG. 42 is a functional block diagram illustrating a configuration of functions for performing processing related to commands and command responses among the functions of the image processing apparatus 100.
Among the functions shown in FIG. 42, the terminal device command pool 141 and the server-side command pool 142 are provided in any rewritable storage means. For example, it can be provided in the NVRAM 207, but may be provided in the SDRAM 203 or the HDD 210. The functions of the terminal device command generation unit 143, the server side command execution result generation unit 144, the message collection unit 145, and the message distribution unit 147 are realized by the CPU 201. Further, the function of the HTTP client function unit 146 is realized by the CPU 201 and the PHY 206.

  In the image processing apparatus 100, since the command is transmitted from the mediation server 102 or the processing server 103, the common handling is performed. The mediation server command and the processing server command are collectively referred to as “server side command”.

These functions will be described in further detail.
First, the terminal device command pool 141 is a pool that registers terminal device commands, responses to the commands, and identification information of the commands in association with each other. The server-side command pool 142 is a pool that registers server-side commands, responses to the commands, and identification information of the commands 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.

  The terminal device command generation unit 143 corresponds to a request generation unit. Then, a terminal device command is generated, identification information (ID) for identifying this command is assigned, management information for managing this command is attached, and these information are associated to form a terminal device command sheet in a table format. It has a function of registering in the terminal device command pool 141. Among these, for example, an application provided in the image processing apparatus 100 corresponds to a part that generates a terminal device command. Further, the terminal device command generation means 143 may be provided with a function of attaching the priority order when executing each command at the transfer destination to the generated terminal device command.

Here, FIG. 43 shows an example of the data structure in the terminal device command sheet of the image processing apparatus 100.
As shown in this figure, in the image processing apparatus 100, the terminal device command sheet includes “command ID”, “method name”, “input parameter”, “state”, “command execution result notification destination”, and An area for storing “output parameter” data is provided. Of these, “command ID”, “method name”, and “input parameter” correspond to terminal device commands (and IDs assigned thereto), and “status” and “command execution result notification destination” are managed. Applicable to information. The “output parameter” is the content of the command response returned from the device that executes the process related to the command.

  The content of each item is the same as the content of the item of the same name in the terminal device command sheet or the mediation server command sheet in the mediation server 102, and thus description thereof is omitted. Note that if the image processing apparatus 100 transmits a terminal device command to the mediation server 102, it is not necessary to recognize which apparatus is subsequently transferred to be processed, and therefore, the item of “destination information” is Not provided.

  Returning to the description of FIG. 42, the server-side command execution result generation unit 144 corresponds to a response generation unit. The server-side command pool 142 is an application that reads and executes server-side commands. Then, it has a function of generating a response to the server side command and registering it in the server side command pool 142 in association with the command ID of the server side command. The server-side command received from the mediation server 102 is registered in the server-side command pool 142 as a table-side server-side command sheet in association with the ID for identifying this command and management information for managing this command. I am trying to keep it. Then, the command response generated by the server-side command execution result generation unit 144 is also registered in the server-side command sheet for the executed server-side command.

Further, it is conceivable that the server-side command execution result generation unit 144 has a function of reading a plurality of types of server-side commands from the server-side command pool 142 and generating a response to each server-side command. Further, when the server-side command includes information on the execution priority for causing the image processing apparatus 100 to execute the processing with priority, a function of preferentially reading out and executing the information from the highest priority may be provided. It is done.
The server-side command execution result generating unit 144 may be a module that calls an application necessary for execution of the server-side command and executes the command instead of the application itself.

Here, FIG. 44 shows an example of the data structure in the server-side command sheet of the image processing apparatus 100.
As shown in this figure, in the image processing apparatus 100, the command sheet on the server side includes “command ID”, “method name”, “input parameter”, “state”, “output parameter”, and “command notification”. An area for storing “first” data is provided. Of these, “command ID”, “method name”, and “input parameter” correspond to server side commands (and IDs attached thereto), and “status” and “command notification destination” are management information. Applicable. The “output parameter” is the execution result of the server side command and is the content of the command response returned by the image processing apparatus 100.

  The content of each item is the same as the content of the item of the same name in the mediation server command sheet or the terminal device command sheet in the mediation server 102, and thus description thereof is omitted. Note that if the image processing apparatus 100 transmits a response to the server-side command to the mediation server 102, it is not necessary to recognize to which apparatus it will be forwarded, so the item “source information” is Not provided.

  Returning to the description of FIG. 42 again, the message collecting means 145 corresponds to the collecting means. Then, the command response generated by the server side command execution result generation unit 144 and the command ID of the server side command corresponding to the command response are read from the server side command pool 142 in association with each other, and the terminal device command generation unit 143 generates The terminal device command and the command ID of this command are associated with each other, read from the terminal device command pool 141, and have a function of generating a transmission message therefrom.

Note that when the execution priority is specified in the command response or the terminal device command, it is conceivable that the message collection unit 145 reads the execution priority in descending order.
The description format and generation method of the transmission message are the same as those described for the mediation server 102.

The HTTP client function unit 146 includes an HTTP request transmission unit 146a that transmits an HTTP request and an HTTP response reception unit 146b that receives an HTTP response.
The HTTP request transmission unit 146a corresponds to the transmission unit, and has a function of generating an HTTP request including the transmission message generated by the message collection unit 145 and transmitting it to the mediation server 102. At this time, any number of transmission messages may be included in one HTTP request, and transmission messages related to command responses and transmission messages related to terminal device commands may be arbitrarily mixed.

  Therefore, the HTTP request transmission unit 146a transmits all the transmission messages generated by the message collection unit 145 in one HTTP request regardless of any of the 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 message collection means 145 attempts to read out a terminal device 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 desired to be transmitted from the mediation server 102 to the image processing apparatus 100, it cannot be transmitted unless communication is requested from the image processing apparatus 100. Even if there is no data to be transmitted from the image processing apparatus 100, a communication request is periodically transmitted to the mediation server 102, and an opportunity to transmit information from the mediation server 102 to the image processing apparatus 100 is provided. Therefore, it is possible to prevent information that needs to be transferred from staying in the mediation server 102 for a long period of time.

  Needless to say, the reading by the message collecting unit 145 and the subsequent transmission of the HTTP request by the HTTP request transmitting unit 146a may be appropriately performed in addition to the periodic timing. For example, when information that needs to be transmitted urgently is registered in any pool, the terminal device command generation unit 143 or the server-side command execution result generation unit 144 notifies the message collection unit 145 to that effect and reads out the information. You may make it perform.

The HTTP response receiving unit 146b corresponds to a receiving unit and has a function of receiving an HTTP response from the mediation server 102. In this case, the HTTP response includes a received message including a server-side command and a command ID associated with the command, and a received message including a response to the terminal device command and a command ID associated with the command. It is mixed and included.
Here, the description format of the received message is the same as that described for the mediation server 102.

The message distribution unit 147 corresponds to a distribution unit. The HTTP response receiving unit 146b has a function of distributing and registering data included in the HTTP response received in the terminal device command pool 141 and the server-side command pool 142.
Specifically, a server-side command and a command ID associated with the command are registered in the server-side command pool 142 by providing a server-side command sheet, and a response to the terminal device command is associated with the command. The command ID is compared with the command ID of the terminal device command sheet stored in the terminal device command pool 141 to identify the corresponding terminal device command, and is registered as an “output parameter” for the terminal device command.
The data conversion method at the time of registration is the same as that described for the mediation server 102.

  Next, processing executed in the image processing apparatus 100 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 201 of the image processing apparatus 100 executing a required control program.

First, FIG. 45 shows a flowchart of basic operations of message collection and distribution processing.
The CPU 201 starts the process shown in the flowchart of FIG. 45 when the message collection unit 145 tries to read out the terminal device command, the command response, and the like.
First, terminal device command collection processing is performed (S111). This process is a process of collecting terminal apparatus commands to be transmitted from the terminal apparatus command pool 141 to the mediation server 102, and includes a process of generating a part by a SOAP envelope from the collected data.

  Next, a server-side command execution result collection process that is a response to the server-side command is performed (S112). This process is a process of collecting command responses to be transmitted from the server-side command pool 142 to the mediation server 102, 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 S111 and S112 are merged into one, an HTTP request including all the parts is generated (S113), and the HTTP request is transmitted to the mediation server 102 (S114).
In the processing so far, the CPU 201 functions as the message collection unit 145 in steps S111 and S112, and functions as the HTTP request transmission unit 146a in steps S113 and S114.

  Next, an HTTP response is received from the mediation server 102 as a communication response to the HTTP request (S115). Then, the HTTP body of the received HTTP response is divided into parts (S116). Here, the division into parts is to divide into elements divided by “MIME_boundary”, and here, all parts are divided.

  Thereafter, the processes of steps S117 to S119 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 response to the terminal device command (S117). And if it is a response with respect to a terminal device command, a response notification process will be performed (S118). If the response is not a response to the terminal device command, the server-side command registration processing is performed because the server-side command is described (S119).

After step S118 or S119, the process returns to step S117, and the process is repeated for the next part. Then, when these processes are performed for all parts, the process shown in the flowchart of FIG. 45 is terminated.
In the processing so far, the CPU 201 functions as the HTTP response receiving unit 146b in steps S115 and S116, and functions as the message distribution unit 147 in steps S117 to S119.

Next, the processing shown in the flowchart of FIG. 45 will be described using the flowchart shown in detail one by one.
FIG. 46 is a flowchart showing in more detail the process up to step S114 in FIG.

  In this process, the CPU 201 first sends the contents of the “method name” and “input parameter” of the terminal device command sheet whose “state” is “unsent” from the terminal device command pool 141 to be transmitted. And the contents of “command ID” are also collected as the command ID of the command (S121). The “status” of “unsent” indicates that the command is not yet notified to the mediation server 102 after the command is generated by the terminal device command generation means 143, and is transmitted to the mediation server 102 based on this. You can extract commands to be used.

  Thereafter, the processes in steps S122 to S124 are repeated for all terminal device commands collected in step S121 in order. In these processes, first, the target terminal device command and its command ID are converted into a SOAP envelope in which these pieces of information are included in the SOAP body and the SOAP header (S122), and an entity header is added thereto. A part related to the target command is generated (S123). Then, the “status” of the terminal device command sheet that describes the target terminal device command is changed to “waiting for response” (S124). The “status” of “waiting for response” indicates that the command has been notified to the mediation server 102.

  After all of these are completed, the CPU 201 sends, from the server-side command pool 142, the contents of the “output parameter” of the server-side command sheet whose “state” is “processing completed” in the command response to the server-side command. Collected as kimono, the contents of “command ID” are also collected as the command ID of the corresponding server side command (S125). The “status” of “processing completed” indicates that the processing corresponding to the server-side command has been generated by the server-side command execution result generation unit 144 and has not yet been notified to the mediation server 102. The command response to be transmitted to the mediation server 102 can be extracted based on the above.

  Thereafter, the processes in steps S126 to S128 are repeated for all command responses collected in step S125 in order. In these processes, first, the target command response and the command ID collected together with the response are converted into a SOAP envelope in which these pieces of information are included in the SOAP body and the SOAP header, respectively (S126), and an entity header is added thereto. This is the process of generating a part related to the target command response (S127). These processes are the same as the processes in steps S122 and S123, except that the objects are different. Then, the “status” of the server side command sheet that describes the target command response is changed to “responded” (S128). “Status” of “Responded” indicates that the command response has been notified to the mediation server 102.

After all the processes so far are completed, the CPU 201 merges the parts generated in step S123 or S127, generates a multi-part HTTP request as shown in FIG. 16, and transmits it to the mediation server 102. (S129).
Note that the change of the “state” performed in step S124 or S128 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.
Thus, the process related to the transmission of the HTTP request is finished, and the process proceeds to the process corresponding to step S115 and subsequent steps in FIG.

FIG. 47 is a flowchart showing in more detail the processing of step S115 and subsequent steps in FIG. The process subsequent to step S129 in FIG. 46 corresponds to step S131 in this figure.
In this process, the CPU 201 first waits for reception of an HTTP response to the transmitted HTTP request, and receives this from the mediation server 102 (S131). When this is received, the HTTP body is analyzed and divided into parts (S132).
Thereafter, the processes in steps S133 to S142 are repeated for each part obtained by the division in order.

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

If the response is a response to the terminal device command in step S133, processing related to registration of the response in steps S134 to S137 is performed.
That is, first, the SOAP envelope of the part is analyzed and converted into data in a format that can be registered in the terminal device command sheet (S134), the terminal device command corresponding to the command response is searched from the terminal device command pool 141, and the terminal Command response data is registered in the “output parameter” item of the terminal device command sheet for the device command (S135). Note that the command response is assumed to have the same command ID as the information attached to the terminal device command when it is transmitted, and the search for the terminal device command is performed using this information as a key. Can do.

  When the data registration is completed, the “status” of the terminal device command sheet in which the data is registered is changed to “response received” to indicate that (S136). Then, the notification destination registered in “command execution result notification destination” is notified that a response has been received (S137). By this notification, the application or the like that has generated the terminal device 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 terminal device command for performing abnormality notification, when this command is transmitted to the mediation server 102, the mediation server 102 returns a command response indicating that the command has been received correctly. come. When receiving this command response, the image processing apparatus 100 searches for a terminal device command based on the command ID included therein, and associates the command response with the found terminal device command. Register. 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 terminal device command sheet, the application can acquire the execution result of the generated command from the item “output parameter”.
When the processing up to step S137 is completed, if there is a next part, the processing from step S133 is repeated for that part.

On the other hand, if the response is not a response to the terminal device command in step S133, the part is a part related to the server-side command, and therefore processing related to registration of the command is performed in steps S138 to S142.
That is, the SOAP envelope of the part is first analyzed and converted into data that can be registered in the server-side command sheet (S138), and a server-side command sheet for registering the server-side command is created in the server-side command pool 142. Then, the server side command and the command ID are registered in the server side command sheet (S140).

  Here, the contents of the server-side command are registered in the “method name” and “input parameter” items of the server-side command sheet, and the command ID described in the part is registered in the “command ID” item. In addition, the initial value of “state” is “unprocessed”, and the initial value of “output parameter” is NULL.

  When the registration to the above items is completed, reference information to a handler (included in the server-side command execution result generation unit 144) for executing the method stored in the “method name” of the server-side command sheet is displayed. Then, a search is made by referring to information on the correspondence relationship between the method and the handler prepared in advance (S141), and the found reference information is registered in the “command notification destination” item of the server-side command sheet (S142).

When the processing up to step S142 is completed, if there is a next part, the processing from step S133 is repeated for that part.
When the processes in steps S133 to S142 are completed for all parts, the process shown in the flowchart of FIG. 47 is terminated.

  By performing the processing as described above, the image processing apparatus 100 can collectively transmit the operation request to be transmitted to the mediation server 102 and the operation response to the operation request received from the mediation server 102 to the mediation server 102. it can. In addition, the operation request from the mediation server 102 or the processing server 103 and the operation response to the operation request transmitted to the mediation server 102 can be received from the mediation server 102 and processed together.

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 mediation server 102, each part may be transmitted sequentially each time it is generated, or each part may be processed sequentially for each part.
Further, as processing related to the execution of the server-side command, the processing described with reference to FIG. 37 or 38 for the mediation server 102 may be executed for the server-side command sheet.

  By the way, if the operation request generated by the image processing apparatus 100 is transmitted to the intermediary server 102 for the time being, the intermediary server 102 transfers the operation request to an appropriate transfer destination (the processing server 103 or the like), and acquires an operation response therefrom. Come back. Therefore, the image processing apparatus 100 may perform the transmission / reception process on the assumption that the operation related to all the operation requests is executed by the mediation server 102.

Also, an operation request received by the image processing apparatus 100 is received from the mediation server 102 and an operation response is returned to the mediation server 102 without grasping which device has actually been generated. Therefore, the image processing apparatus 100 may perform transmission / reception processing assuming that all the operation requests are generated by the mediation server 102.
Above, description of the process regarding the transfer of each command and command response executed in the image processing apparatus 100 is finished.

Next, a functional configuration for handling commands and command responses on the processing server 103 side will be described. The hardware is as described with reference to FIG.
FIG. 48 is a functional block diagram showing a configuration of functions for performing processing relating to commands and command responses among the functions of the processing server 103.

  Each function illustrated in FIG. 48 is realized by the CPU 301 of the processing server 103 executing a required control program to control the operation of each unit of the processing server 103. Among these functions, the processing server command pool 241 and the terminal device command pool 242 are provided in a rewritable storage unit such as the RAM 303. The functions of the processing server command generation unit 243, the terminal device command execution result generation unit 244, the message collection unit 245, and the message distribution unit 247 are realized by the CPU 301. The function of the HTTP server function unit 246 is realized by the CPU 301 and the NIC 305. The path information storage unit 250 is provided in a rewritable nonvolatile storage unit such as the SD card 304.

The function of each means shown in FIG. 48 will be described in further detail.
First, the processing server command pool 241 is a pool that registers processing server commands in association with responses to the commands, identification information of the commands, command destinations, transmission source information, and the like. The terminal device command pool 242 is a pool for registering terminal device commands in association with responses to the commands, identification information of the commands, information on the destinations and transmission sources of the commands, and the like.

  The processing server command generation unit 243 corresponds to a request generation unit. Then, a processing server command is generated, identification information (ID) for identifying the command is assigned, destination information of the command and management information for managing the command are attached, and the information is associated with each other in a table format. The processing server command sheet has a function of registering in the processing server command pool 241. Among these, for example, an application provided in the processing server 103 corresponds to the part that generates the processing server command. The data structure in the processing server command sheet of the processing server 103 is the same as the data structure in the mediation server command sheet of the mediation server 102 shown in FIG.

Note that the processing server command generation unit 243 registers not only the final destination as the destination information but also the route information up to the transfer to the destination in the processing server command sheet. The route information can be acquired from the route information storage unit 250.
That is, the route information storage unit 250 stores the destination of the command (or other information) and the route information when the command is transmitted to the destination in association with each other as a route information table. By searching this route information table using the destination as a key, it is possible to obtain route information until the destination is transferred.

FIG. 49 shows an example of this route information table.
In this example, a table in which four image processing apparatuses are registered is shown. For the image processing apparatuses A and B, information indicating that the command only needs to be transferred via the mediation server 102 is registered, but for the image processing apparatuses C and D, information indicating that the route is unknown. Is registered.

  Here, since the system configuration is such that communication is not requested from the terminal device from the processing server 103 side, the operator inputs the terminal device ID based on information such as a user registration postcard, and then transferred from the terminal device. When the information has never been received, for example, it is not possible to recognize through which intermediary server 102 the command should be transferred to the terminal device, so that a state in which the route information is unknown may occur.

As will be described later, the information in the route information table can be automatically updated by referring to the message information described in the HTTP request received by the processing server 103, or manually by the operator of the processing server 103. You can also enter it with.
In addition, a transfer route for transferring through a plurality of mediation servers can be registered, but only one type of route is registered for each terminal device.

  Returning to the description of FIG. 48, the terminal device command execution result generation unit 244 corresponds to a response generation unit. The terminal device command is an application that reads and executes a terminal device command from the terminal device command pool 242. Then, it has a function of generating a response to the terminal device command and registering it in the terminal device command pool 242 in association with the command ID of the terminal device command. The terminal device command received from the mediation server 102 is associated with an ID for identifying the command, source information of the command (becomes destination information of the command response), and management information for managing the command. A terminal device command sheet is registered in the terminal device command pool 242 as a format terminal device command sheet. The command response generated by the terminal device command execution result generation unit 244 is also registered in the terminal device command sheet for the executed terminal device command.

Further, it is conceivable to provide the terminal device command execution result generation means 244 with a function of reading a plurality of types of terminal device commands from the terminal device command pool 242 and generating a response to each terminal device command. Further, the terminal device command execution result generation unit 244 may be a module that calls an application necessary for executing the terminal device command and executes the command, instead of the application itself.
Further, the data structure in the terminal device command sheet of the processing server 103 is the same as the data structure in the terminal device command sheet of the mediation server 102 shown in FIG.

Next, the message collecting unit 245 corresponds to the collecting unit. Then, the command response generated by the terminal device command execution result generating unit 244 is read from the terminal device command pool 242 in association with the command ID and the transmission source information of the terminal device command corresponding to the command response, and the processing server command generating unit The processing server command generated by H.243 is associated with the command ID and destination information of this command, read from the processing server command pool 241, and has a function of generating a transmission message therefrom.
The description format and generation method of the transmission message are the same as those described for the mediation server 102.

The HTTP server function unit 246 includes an HTTP response transmission unit 246a that transmits an HTTP response and an HTTP request reception unit 246b that receives an HTTP request.
The HTTP response transmission unit 246a corresponds to the transmission unit, generates an HTTP response including the transmission message generated by the message collection unit 245 as a communication response to the HTTP request received from the mediation server 102, and transmits the HTTP response to the mediation server 102. It has the function to do. 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 processing server command may be arbitrarily mixed. Of course, transmission messages with different destinations can be mixed.

  Further, the HTTP response transmission unit 246a transmits all the transmission messages generated by the message collection unit 245 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 message collection unit 245 attempts to read out the processing server command, 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 mediation server 102 is received.
This is because the processing server 103 does not have an HTTP client function unit even if reading is attempted in other situations, and therefore cannot send an HTTP request by itself and transfer a transmission message to the mediation server 102.

The HTTP request receiving unit 246b corresponds to a receiving unit and has a function of receiving an HTTP request from the mediation server 102. In this example, the HTTP request includes a received message including a terminal device command and a command ID associated with the command and transfer path information, a response to the processing server command, and a command ID and transfer path information associated with the command. And a received message including any are included.
The description format of the received message is the same as that described for the mediation server 102.

The message distribution unit 247 corresponds to a distribution unit. The HTTP request receiving unit 246b has a function of distributing and registering data included in the HTTP request received in the processing server command pool 241 and the terminal device command pool 242.
Specifically, a terminal device command and a command ID and transfer path information (registered as transmission source information) associated with the command are registered in the terminal device command pool 242 by providing a terminal device command sheet, and a processing server For a response to a command, the command ID associated with the response is compared with the command ID of the processing server command sheet stored in the processing server command pool 241 to identify the corresponding processing server command sheet, and the processing server command Register in the “Output Parameter” field of the sheet.
The data conversion method at the time of registration is the same as that described for the mediation server 102.

Next, processing executed in the processing server 103 having the configuration and functions described above will be described.
FIG. 50 shows a flowchart of basic operations related to message transmission / reception with the mediation server. The processing shown in this flowchart is performed by the CPU 301 of the processing server 103 executing a required control program.

When an HTTP request is transmitted from the mediation server 102, the CPU 301 starts processing shown in the flowchart of FIG.
First, the HTTP request is received (S211). Then, the HTTP body of the received HTTP request is divided into parts (S212). Here, the division into parts is to divide into elements divided by “MIME_boundary”, and here, all parts are divided.

Thereafter, the processes of steps SY and S213 to S215 are repeated for all the parts obtained by the division in order. In this process, first, a route information table update process for updating the route information table shown in FIG. 49 is performed (SY), and then it is determined whether or not the target part is a part describing a response to the processing server command. (S213). If it is a response to the processing server command, a response notification process is performed (S214). If the response is not a response to the processing server command, the terminal device command is registered because the terminal device command is described (S215).

After step S214 or S215, the process returns to step S213, and the process is repeated for the next part. Then, when these processes are performed for all parts, the process proceeds to the next step S216.
In the processing so far, in steps S211 and S212, the CPU 301 functions as an HTTP request reception unit 246b, and in steps S213 to S215, functions as a message distribution unit 247.

Next, the CPU 301 performs processing server command collection processing (S216). This processing is processing for collecting processing server commands to be transmitted from the processing server command pool 241 to the mediation server 102, and includes processing for generating a part based on the SOAP envelope from the collected data.
Next, terminal device command execution result collection processing, which is a response to the terminal device command, is collected (S217). This process is a process of collecting command responses to be transmitted from the terminal device command pool 242 to the mediation server 102, 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 S216 and S217 are merged into one, and an HTTP response including all the parts is generated (S218), and the HTTP response is used as a communication response to the HTTP request received in step S211. The message is transmitted to the mediation server 102 (S219), and the process is terminated.
In the processing so far, the CPU 301 functions as the message collection unit 245 in steps S216 and S217, and functions as the HTTP response transmission unit 246a in steps S218 and S219.

Next, the processing shown in the flowchart of FIG. 50 will be described using the flowchart shown in detail one by one.
FIG. 51 is a flowchart showing in more detail the process up to step S215 in FIG.
In this process, the CPU 301 first receives an HTTP request from the mediation server 102 (S221). When this is received, the HTTP body is analyzed and divided into parts (S222).

Thereafter, the processes of Step SY and Steps S223 to S232 are repeated for each part obtained by the division sequentially.
Regarding these processes, step SY will be described later. Steps S223 to S232 are substantially the same as steps S133 to S142 described for the image processing apparatus 100 with reference to FIG. 47. Basically, what is a terminal device command in the processing of FIG. 47 is a processing server command here, and what is a server side command is a terminal device command, and accordingly, the name of the command sheet Are only different.

The other difference is that in step S230, information on the transfer path (contents of the “X-Received-From” header) is extracted from the entity header of the part in which the terminal device command is described, and “source information” is extracted. In addition, the information on the transmission source of the HTTP request is also registered in the same item as information on the latest transfer route.
Therefore, description of other points is omitted.
When the processes of step SY and steps S223 to S232 are completed for all parts, the process shown in the flowchart of FIG. 51 is terminated, and the process proceeds to the process corresponding to step S216 and subsequent steps of FIG.

FIG. 52 is a flowchart showing in more detail the processing of step S216 and subsequent steps in FIG. The processing subsequent to step S227 or 232 in FIG. 51 corresponds to step S241 in this figure.
In this processing, first, the CPU 301 first extracts from the processing server command pool 241 the processing server command sheet whose transfer destination is the same as the transmission source of the HTTP request received in step S211 and whose “status” is “unsent”. The contents of “method name” and “input parameter” are collected as a processing server command to be transmitted, and the contents of “command ID” are also collected as the command ID of the command (S241).

Here, in the “destination information”, route information related to command transfer is registered with reference to the route information table, so that information on the transmission source of the HTTP request is described as a transfer destination directly transferred from the processing server 103. This sheet can be recognized as a sheet in which a command to be transmitted in the HTTP response to the HTTP request is described.
Further, the “state” of “unsent” indicates that the command is not yet notified to the mediation server 102 after the command is generated by the processing server command generation means 243, and therefore the mediation server 102 is based on this. You can extract commands to send to.

Thereafter, the processing in steps S242 to S244 is repeated for all processing server commands collected in step S241.
In these processes, first, the target processing server command and its command ID are converted into SOAP envelopes in which these pieces of information are included in the SOAP body and the SOAP header (S242), and an entity header is added thereto. A part related to the target command is generated (S243). In step S243, transfer path information is described in the entity header using the “X-Send-To” header described above with reference to “destination information”. At this time, information on a target to which an HTTP response is to be transmitted is no longer necessary and will not be described.
Then, the “status” of the processing server command sheet describing the target processing server command is changed to “waiting for response” (S244). The “status” of “waiting for response” indicates that the command has been transmitted to the mediation server 102.

  After all of these are completed, the CPU 301 determines from the terminal device command pool 242 that the latest transfer destination is the same as the transmission source of the HTTP request received in step S211 and the “status” is “processing complete”. Are collected as command responses to be transmitted among the command responses to the terminal device command, and the contents of “command ID” are also collected as the command ID of the corresponding terminal device command (S245).

Here, since the route information related to the transfer is registered in the “source information” when the terminal device command is received, the information of the source of the HTTP request is described as the transfer destination directly transferred from the processing server 103. This sheet can be recognized as a sheet in which a command to be transmitted in the HTTP response to the HTTP request is described.
Further, the “state” of “processing completed” indicates that the processing corresponding to the terminal device command has been generated by the terminal device command execution result generation unit 244 and has not yet been transmitted to the mediation server 102. Based on this, a command response to be transmitted to the mediation server 102 can be extracted.

  Thereafter, the processes in steps S246 to S248 are repeated for all command responses collected in step S245 in order. In these processes, first, the target command response and the command ID collected together with the response are converted into a SOAP envelope in which these pieces of information are included in the SOAP body and the SOAP header (S246), and an entity header is added thereto. Then, a part related to the target command is generated (S247).

In step S247, transfer path information is described in the entity header using the “X-Send-To” header described above with reference to “source information”. At this time, information on a target to which an HTTP response is to be transmitted is no longer necessary and will not be described. That is, the content of the “X-Send-To” header may be the same as the content of the “X-Received-From” header described when the corresponding terminal device command is received.
Then, the “status” of the terminal device command sheet in which the target command response is described is changed to “response completed” (S248). The “status” “response completed” indicates that the command response has been transmitted to the mediation server 102.

After all the processes so far are completed, the CPU 301 merges the parts generated in step S243 or S247, generates a multipart HTTP response, and transmits it to the mediation server 102 as a response to the received HTTP request. (S249).
Note that the change of the “state” performed in step S244 or S248 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.
Thus, the process illustrated in FIG. 52 is finished.

Next, FIG. 53 shows a flowchart of the route information table update process shown in FIG.
In this process, the CPU 301 first determines whether or not there is an “X-Received-From” header in the target part, that is, whether or not path information is described in the entity header (S251).
If there is an “X-Received-From” header, the value of the first “X-Received-From” header is acquired as the transmission source information of the target part, and the remaining “X-Received-From” header is obtained as route information. And the transmission source information of the HTTP request received in step S211 of FIG. 50 (S252). On the other hand, if there is no “X-Received-From” header, the source information of the HTTP request is acquired as the source information of the target part, and the fact that there is no route information is stored (S253).

In any case, it is next determined whether or not the transmission source of the target part is registered in the route information table (S254). If registered, it is determined whether or not the route information matches the registered content (S255). If the route information matches, it is not necessary to change the content of the route information table. To return to the original process.
If not registered in step S254, the source information is registered as the terminal device ID in the route information table in order to newly register the part source in the route information table, and the corresponding route information is used as the step information. The route information acquired in S252 or S253 is registered.

If they do not match in step S255, the route information for the transmission source terminal device ID is replaced with the route information acquired in step S252 or S253, and the route information is updated. This includes the case where the original route information is unknown.
After step S256 or S257, in order to reflect the updated contents of the route information table in the command sheet already registered in the pool, from the processing server command pool 241 and the terminal device command pool, the destination or transmission source (intermediate transfer route) Is not included), a command sheet that matches the transmission source of the target part (transmission source information acquired in step S252 or S253) is extracted (S258).

Then, all the extracted sheets are sequentially targeted, and the destination information or the transmission source information of the target sheet is replaced according to the contents of the changed route information table (S259). At this time, only the transfer path is replaced, and the final destination or command transmission source is not changed.
When all the above processes are completed, the process shown in the flowchart of FIG. 53 is terminated, and the process returns to the original process.

  By performing the processing described with reference to FIGS. 50 to 53 as described above, the processing server 103 operates in response to operation requests to be transmitted to various image processing apparatuses 100 and operation requests received from the image processing apparatus 100. Responses can be sent to the mediation server 102 in a batch. In addition, the operation request from the image processing apparatus 100 and the operation response to the operation request transmitted to the image processing apparatus 100 can be collectively received from the mediation server 102 and processed. Furthermore, even when a communication request is not transmitted from the processing server 103, an operation request or an operation response can be delivered to an appropriate mediation server 102 that mediates communication to the image processing apparatus 100.

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 mediation server 102, each part may be transmitted sequentially each time it is generated, or each part may be processed sequentially for each part.
Further, as processing relating to execution of the image device command, processing similar to that described with reference to FIG. 37 or 38 may be executed for the mediation server 102.
Above, description of the process regarding the handling of each command and command response performed in the process server 103 is complete | finished.

Here, in the remote management system described above with reference to FIG. 54, a series of operations performed in each device from when the image processing device 100 generates a terminal device command to be executed by the processing server 103 until receiving a response to the command. The process of is shown. FIG. 55 shows a series of processing performed in each apparatus from when the processing server 103 generates a processing server command addressed to the image processing apparatus 100 until receiving a response to the command.
Since each of the processes shown in these figures is one of the processes already described, detailed description thereof is omitted. However, in the remote management system described above, by performing such a process, the processing server Transmission and reception of commands and command responses between the image processing apparatus 103 and the image processing apparatus 100 can be performed by the mediation server 102.

  As can be seen from the above description, in this remote management system, the mediation server 102 is provided, and communication between the image processing apparatus 100 and the processing server 103 is performed via the mediation server 102. Thus, even when the image processing apparatus 100 does not recognize the existence of the processing server 103 and does not recognize to which apparatus the command or the command response is to be finally transferred, the image processing apparatus The command or command response transmitted by 100 can be transferred to an appropriate transfer destination. This is because the mediation server 102 transfers the command and command response received from the image processing apparatus 100 with an appropriate transfer destination determined according to the type.

  As a result, it is possible to reduce the burden of destination information management in the image processing apparatus 100 which is a terminal apparatus installed in the customer side environment. That is, when changing the configuration of the service provided by the mediation server 102 or the processing server 103 on the function providing side, the content of the transfer destination table stored in the mediation server 102 for changing the transfer path of the command or command response It is possible to respond by changing That is, since it is possible to cope with maintenance only on the service provider side, destination information management is very easy.

  In addition, it is common to manage commands hierarchically by dividing them into groups, but adding or deleting commands within the same group is possible by defining the correspondence between types and transfer destinations for each group. Even if it is done, there is no need to change the transfer destination table. Therefore, it is possible to reduce the management burden of destination information in the mediation server 102. Since commands in the same group are normally processed by the same application, there is usually no particular problem even if the transfer destination is the same.

  Further, if the command and the command response are described as a SOAP request and a SOAP response, data standardized in XML can be transmitted and received, so that the transmitted and received data can be reused effectively. That is, it is possible to easily perform processing such as automatically registering received data in an in-house system or automatically generating a home page for displaying received data using a technology such as XSLT (XML Stylesheet Language Transform).

  Furthermore, in the SOAP message, the tag name space is often defined, but if the transfer destination is specified for each tag name space related to the command or the command response, the transfer destination can be easily managed. It is. In this case, the detailed classification of the name space relating to the designation of the transfer destination and the name space relating to the definition of the namespace prefix are not necessarily the same.

  Further, by adopting the configuration described above in each device constituting the remote management system, the operation request and the operation response to be transmitted and received between the devices are either the operation request or the operation response, and the final Regardless of where the transfer destination is, it is possible to send and receive all at once, so it establishes a communication connection by negotiating separately for each operation request transmission and operation response transmission and for each final transfer destination. This is unnecessary, and communication efficiency can be improved by reducing communication overhead.

This effect increases as the number of image processing apparatuses 100 increases and the number of operation requests and response to be transferred between the processing server 103 or the mediation server 102 and the image processing apparatus 100 increases.
In particular, for the image processing apparatus 100, since all operation requests and operation responses can be transferred to and from the intermediary server 102, communication timing management becomes easy.

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.
By doing this, each device easily separates the operation request and the operation response received in a batch into individual messages, and whether it is an operation request or an operation response. Appropriate processing can be performed according to the type and transfer destination.

  In addition, each of the operation request and the operation response is expressed in a format that can generate a single message that can be transferred by combining a plurality without changing the format. By making it possible to return to individual operation requests and response that can be divided and transferred, it is possible to reduce the processing load when combining and dividing the operation requests and response.

  Further, for communication between the image processing apparatus 100 and the mediation server 102, a communication request is always issued from the image processing apparatus 100 to perform communication, and an operation request or the like from the mediation server 102 to the image processing apparatus 100 is transmitted. By performing the response to the communication request, even when the image processing apparatus 100 is provided inside the firewall, the operation request and the operation response can be transmitted and received without being aware of the existence of the firewall. it can. 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 a communication request is periodically transmitted from the image processing apparatus 100 to the mediation server 102, transmission of information from the mediation server 102 to the image processing apparatus 100 is delayed for a long time. Can prevent the situation.
Similarly, regarding communication between the mediation server 102 and the processing server 103, if a communication request is always issued from the mediation server 102 and communication is performed, which mediation server can be a communication partner on the processing server 103 side. Even if it is not managed, an operation request and an operation response can be transmitted and received without any problem. Therefore, it is possible to reduce the management burden of the communication destination on the processing server 103 side.
In this case, if the communication request is periodically transmitted from the mediation server 102 to the processing server 103, the transmission of information from the processing server 103 to the mediation server 102 is delayed for a long time. Can be prevented.

  In addition, each device has a command pool for registering operation requests executed by itself and a command pool for registering operation requests generated by itself, and operations generated by each application or received from other devices By storing requests and operation responses in these pools, it is possible to generate and transmit / receive operation requests and operation responses without considering the transmission timing for the transfer destination. Therefore, the process timing management can be simplified, and the 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, the transfer of the operation request and the operation response can be performed without considering the reception timing from the communication partner. Therefore, timing management can be simplified, and the design and development of the apparatus becomes easy.

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 the operation corresponding to the operation response is stored and transmitted. If it is performed in association with the identification information of the request, even when a plurality of operation requests and operation responses are included in one message (here, an HTTP message), the correspondence relationship between the operation request and the operation response through the identification information. Can be easily recognized.
In addition, if priority is given to operation requests, and execution is performed in descending order or responses are transmitted, urgent operations are performed preferentially and the responses are also returned preferentially. Can do.

  In the mediation server 102, if a transfer message pool is provided and an operation request and an operation response that merely mediates the transfer are registered separately for those that are generated or executed by itself, Processing different from other messages can be performed. For example, since a message related to transfer does not need to be interpreted (for example, there is no need to deserialize XML), it can be registered in the transfer message pool in the form as received. Further, when searching for a message to be transferred to the processing server 103, the search range can be narrowed. Therefore, by providing the transfer message pool, the processing load of the message transfer mediation process in the mediation server 102 can be reduced.

[Modification of Embodiment]
Next, a modification of the above-described embodiment will be described.
First, in the above-described embodiment, an example in which a message is transmitted and received between a terminal device such as the image processing apparatus 100 and the processing server 103 via only one mediation server 102 has been described. Of course, transmission / reception may be performed via the apparatus.
An example of such a distributed processing system is shown in FIG.

In this example, the terminal device A can send and receive messages to and from the processing server D via two mediation servers, the mediation server B and the mediation server C. In this case, the functions of the mediation servers B and C are the same as those of the mediation server 102 in the above-described embodiment. The function of the processing server D is the same as that of the processing server 103.
In this case, the message transferred in the direction from the terminal device to the processing server is described in the communication request, and the message transferred in the reverse direction is described in the communication response to the communication request and transferred.
Further, which device is the first communication device and which communication device is the second communication device is relatively determined with respect to each intermediary server. Specifically, the device that transmits the communication request to the mediation server is the first communication device, and the partner device to which the mediation server transmits the communication request is the second communication device. Alternatively, a device that transmits a message that does not describe a transfer destination can be considered as a first communication device, and a device that transmits a message that describes a transfer destination can be considered as a second communication device.

  In this distributed processing system, the intermediary server B stores the message of the type to be transferred to the processing server D that the transfer destination is the intermediary server C (where this is finally transferred). You do not need to remember it). The intermediary server C stores a message indicating that the transfer destination of the message of the type to be transferred to the processing server D is the processing server D. By setting the transfer destination in this way, the message transmitted from the terminal device A to the mediation server B can be further transferred to the processing server D via the mediation server C.

  At this time, when the message transferred from the terminal device A to the mediation server B is further transferred to the mediation server C, the “X-Received-From” header contains “terminal device A” as transmission source information. Information is written. When this is further transferred to the processing server D, information of “mediation server B” is added to the next “X-Received-From” header as transmission source information. Further, the processing server D can recognize that the mediation server C is also a transfer path from the transmission source information of the HTTP request in which this message is described.

Therefore, it can be understood that the message transmitted to the terminal device A on the processing server D side may be transferred via the route of the mediation server C → the mediation server B → the terminal device A. Therefore, the processing server D can describe the route information in the message transmitted to the terminal device A by the “X-Send-To” header (need to describe the information of the mediation server C that is the direct transfer destination). Not)
Then, the mediation server corresponding to the transfer route can transfer the message to the next transfer destination and finally transfer the message to the terminal device A by referring to the route information. At this time, when the message is transferred, the route information indicating the transfer destination is deleted, and the next transfer destination is shown at the bottom.

In the above configuration, as can be seen from the description in FIG. 56, the processing server uses the same route as the content of the “X-Received-From” header described in the message transferred from the terminal device to the processing server. The contents of the “X-Send-To” header described in the message transferred from the terminal to the terminal device are exactly the same.
In the above-described embodiment, an example has been described in which the addition of the “X-Received-From” header is performed on the reception side and the deletion of the “X-Send-To” header is performed on the transmission side. Not required. Conversely, the “X-Received-From” header may be added on the transmission side, and the “X-Send-To” header may be deleted on the reception side.

FIG. 57 shows still another configuration example of the distributed processing system.
As shown in this figure, in the distributed processing system of the present invention, it is not necessary to have one intermediary server that communicates directly with the terminal device. Further, the processing server does not need to be configured to send and receive messages only with one intermediary server. As described above, one intermediary server may send and receive messages to and from a plurality of terminal devices.
Even in this case, the message transferred from the terminal device to the processing server describes the information of the transmission source and the transfer route, and the intermediate server in the middle stores the information of the transfer destination for each message type. Since the message transferred from the processing server to the terminal device includes information on the transfer route and the destination, the message can be transferred to an appropriate partner by referring to these.

In the distributed processing system having such a configuration, the route information table in the processing server J is as shown in FIG. That is, regarding the terminal device A, the processing server J can recognize that the message can be transferred through a transfer path such as the terminal device A⇔mediation server F⇔mediation server G⇔processing server J. As for the terminal device B, it can be recognized that the message can be transferred through a transfer path such as the terminal device B⇔mediation server H⇔processing server J.
For the terminal devices C and D, the route has not been registered yet. However, for example, when the processing server J receives a message from the terminal device D, it recognizes the route of the terminal device D⇔mediation server F⇔mediation server G⇔processing server J from the information of the transfer route of the message, and routes it. It can be registered in the information table.

Similarly, when a message is received from a terminal device that is not registered in the route information table, such as the terminal device E, the route of the terminal device E⇔mediation server H⇔processing server J is similarly determined from the message transfer route information. Can be recognized and registered in the route information table. However, it may be possible to respond to a message from a terminal device that has not been registered in the route information table in advance and return an error and not newly register it in the route information table.
It goes without saying that various configurations other than the configurations shown in FIGS. 56 and 57 can be adopted as the distributed processing system. However, if it is possible to transmit a message from one terminal device to a plurality of mediation servers, it becomes necessary to manage the message destination on the terminal device side. Therefore, it is preferable that each terminal device can transmit a message to only one mediation server.

  In these distributed processing systems, including the distributed processing system of the above-described embodiment, it is not always necessary to distinguish between the processing server and the mediation server. In such a case, the functions of these servers may be those obtained by adding the function related to the route information storage unit 250 described for the processing server 103 to the function described for the mediation server 102 in the embodiment.

  In a device in which information other than itself is not registered as a transfer destination in the transfer destination table, all processing related to the received operation requests and response is performed by itself. The message transfer means is not used, and as a result, it functions as a processing server. Therefore, in this way, it is possible to arbitrarily function the same apparatus as both the processing server and the mediation server simply by changing the contents of the transfer destination table, so that the system configuration can be easily changed.

On the contrary, it is also possible to make the mediation server a device specialized for mediating messages without providing the mediation server with a function for performing processing related to an operation request or generating an operation request. In this case, the terminal device command pool, the mediation server command pool, the terminal device command execution result generation means, and the mediation server command generation means are unnecessary. Therefore, it is possible to simplify the configuration of the mediation server, reduce design and development, and reduce costs.
It is also conceivable that a communication request can be transmitted from the processing server to the mediation server, and a message relating to the operation request or the operation response can be described in the communication request and transferred.

  Further, in the above-described embodiment, as the transfer destination table in the mediation server 102, as shown in FIG. 34, for each name space URI, information on the transfer destination of a command related to a command or a command response belonging to that name space is stored. An example using what has been described was described. However, it is also conceivable to transfer a message whose transfer destination is not clearly defined in the transfer destination table to a predetermined transfer destination.

  In this case, as shown in FIG. 59, an item “default” is provided in the transfer destination table, and the name space URI of the command or command response is not registered in the transfer destination table, the “default” column It is conceivable that a message related to the command or command response is transferred to the transfer destination registered in. In this case, in the message distribution process as shown in FIG. 33, when the namespace URI is not registered in the transfer destination table in step S22, the message transfer destination of the target part is registered in the “default” column. It is good to make it the forwarding destination that has been made.

As a system configuration using the transfer destination table shown in FIG. 59, for example, the configuration shown in FIG. 60 can be considered. That is, in the distributed processing system shown in FIG. 3, the general management server 103c is additionally provided. Then, the transfer table shown in FIG. 59 is stored in the device management server 102, and all messages that are neither processed by the device management server 102 nor transferred to the sales management server 103a or the information distribution server 103b are stored. The data is transferred to the general management server 103c.
By doing so, it is not necessary to specify transfer destination information corresponding to all commands and command responses that can be handled in the mediation server 102, so that system design and management are facilitated.

  In this case, the message received by the general management server 103c does not need to be processed by itself, and may be forwarded to another device. Further, in this case, the transfer destination table used by the integrated management server 103c does not have the “default” item as shown in FIG. 34, but has the “default” item as shown in FIG. May be. Furthermore, the transfer destination registered in the item “default” may be the same as the transfer destination registered in the transfer destination table in association with one of the name space URIs.

It is also conceivable to use a transfer destination table as shown in FIG. 61 in each intermediary server. That is, it is also conceivable that only the command or command response to be processed by itself is registered as the transfer destination, and all other commands and command responses are transferred to the next transfer server.
In this case, for example, the distributed processing system is configured as shown in FIG. 62, a plurality of mediation servers are arranged in series, and each mediation server sends a message related to commands and command responses other than those to be processed by itself, The data can be transferred sequentially to the next server. If the system is configured in this way, each intermediary server need only store information on commands and command responses to be processed by itself and other command and command response transfer destinations. And management becomes even easier.

Each mediation server does not need to know how the message is processed in the message transfer destination mediation server or processing server. Can be freely determined without notifying the transfer source intermediary server. Therefore, if the company that provided the intermediary server sends the processing related to the message to a subcontractor, or the company that has received an order for the subcontracting sends the processing to a subcontractor, this configuration is adopted. This is particularly effective because the company that has received an order for processing can freely configure the system.
The processing server N at the last stage does not provide the “default” item in the transfer destination table, and performs error processing for commands and command responses whose name space URI is not registered in the transfer destination table. By doing so, it becomes possible to appropriately deal with commands that are completely unrelated.

  Furthermore, if it is only necessary to support a configuration in which a plurality of mediation servers are directly arranged as shown in FIG. 62, information as shown in FIG. 63 is stored in each mediation server instead of the transfer destination table. You may make it leave. In other words, the name space URI to which the method to be processed by itself and the ID of the transfer destination server that transfers other commands may be stored.

FIG. 64 shows a flowchart of processing when the received message is handled using the information shown in FIG. The process shown in FIG. 64 is such that the processes of step SA and step SB are performed instead of steps S22 and S23 of the process shown in FIG.
That is, when the information shown in FIG. 63 is used, the processing shown in FIG. 64 is performed in the message distribution processing in the basic flow of message transmission / reception shown in FIG. In step S21, the name space URI of the command or command response related to the message is acquired from the SOAP message of the target part. In step SA, the name space URI is “name to which the method to be processed by itself belongs” shown in FIG. It is determined whether or not it is included in the “space URI”.

If it is included, the command or command response should be processed by itself, so the process proceeds to step S24 and the subsequent steps, and the same processing as in the case of FIG. 33 is performed. If it is not included, the command or command response is to be transferred to the next mediation server, so that the message destination is registered as “transfer destination server ID” shown in FIG. 63 in step SB. It is set to “next mediation server”, and the process proceeds to step S 34 and subsequent steps to register the target message in the transmission message pool 51 for transmission.
If each intermediary server is caused to execute the processing as described above, it is possible to appropriately transfer the message with only the information as shown in FIG. When such a process is adopted, there is only one transfer destination server. Therefore, when the message transfer process as shown in FIG. 39 is performed, all of the registered transfer message pools 51 are registered. Messages may be collected and transmitted to a predetermined transfer destination. Therefore, it is not essential to manage the message transfer destination in the transfer message sheet as shown in FIG.

It should be noted that a plurality of servers are registered as “forwarding server IDs”, and the forwarding destination of a message related to a command to be forwarded to another server is determined by scheduling according to the reception date and time of the message, the source of the message, or random , It may be distributed to each server. In this way, it is possible to prevent messages from being concentrated on the transfer destination server and to distribute the processing load.
Further, a similar process may be performed for the command response. In this case, if a database that can be referred to in common by each device that may receive the message is provided and the received message is pooled here, the command response is sent to the device that sent the command. Even if it does not arrive, the transmission source device can refer to the command response by accessing the database.

  In addition, even a message related to a command that can be processed by itself may be transferred to another server depending on circumstances, for example, when sufficient resources necessary for processing by itself cannot be secured. In this case, the transfer destination server may be provided with a function for processing the same command as that of the transfer source server. In this way, when the processing load is concentrated on some servers, the processing can be efficiently distributed to a plurality of servers with simple processing.

In the above-described embodiment, the example in which the message transfer between the devices is performed in multipart has been described. However, this is not essential. For example, when the commands handled by the entire system are only those directed from the terminal device to the mediation server or processing server, a method in which only one SOAP message is described in one HTTP request or HTTP response, for example, mediation Processing as described with reference to FIG. 41 in the server 102 can also be employed. This eliminates the need for each device to support a special transfer protocol such as a multipart, thereby reducing design and development efforts and reducing costs.
Further, even if commands handled by the entire system are only directed to the intermediary server or processing server from the terminal device, the above-described effects can be obtained in the same manner by performing multi-part transfer as described above. .

  In each of the above-described embodiments, SOAP is adopted as an upper protocol for realizing RPC, and the application directly implements RPC by operating the pool. However, CORBA (Common Object Request) is used between the application and the pool. Application development efficiency may be further improved by providing a bridge (message conversion function) with Broker Architecture) or JAVA (registered trademark) RMI (Remote Method Invocation).

Further, in the above-described embodiment, the exchange of commands and command responses to each node is performed by a SOAP message described in XML. However, the present invention is not limited to this, and is described in another format. It may be.
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 addition, in the above-described embodiment, not only the SOAP standard protocol but also a unique protocol combining SOAP and MIME multipart is adopted in addition to this, so that the SOAP envelope included in the HTTP request or HTTP response can be changed. Although they are treated as completely independent, the SOAP attachment defined as the SOAP related specification embeds the link to the SOAP envelope of the second part or later in the SOAP envelope of the first part included in the HTTP response. It is also possible to adopt a configuration in which these are transferred in association with each other. The same applies when adopting SMTP.

  Note that when SMTP is adopted as a message transfer protocol, the message is described in an e-mail and transmitted, but a plurality of messages are described in one e-mail using MIME multipart or the like. It is possible to do. Therefore, instead of the above-described HTTP request and HTTP response, it is possible to use an e-mail and a return e-mail. However, since e-mail does not have a corresponding relationship such as a communication request and a response, the timing of the first transmission and the response to the first transmission must be managed independently. In addition, since e-mail may take a long time to reach the destination, it is preferable to use HTTP as a transfer protocol for smooth operation of the system.

  Although the example in which the image processing apparatus 100 and the mediation server 102 are connected via the Internet 14 has been described here, various communication paths that can perform network communication regardless of wired or wireless are used. Can do. Various communication paths can be similarly used between the mediation server 102 and the processing server 103.

Furthermore, the configuration of the distributed processing system is not limited to the one described above, and it goes without saying that the present invention can be applied to a distributed processing system other than the remote management system and any communication system.
For example, the “terminal device” in the above-described embodiment is merely a “terminal” in the distributed processing system, and does not need to function as a “terminal” in the customer environment. That is, the backbone server in the customer's environment is connected as a “terminal device” to the distributed processing system as in the above-described embodiment, and the information acquired from this is processed and distributed to other devices in the customer's environment. Various configurations can also be adopted.

Further, the processing servers do not have to be devices for executing different commands. For example, in the mediation server, the transfer destination may be determined by referring not only to the type of operation request or operation response but also to the information of the message transmission source. In this way, even if the number of terminal devices that transmit operation requests increases and the load on the processing server becomes excessive, the processing server can be easily processed by dividing the processing server into a certain number of terminal devices. Dispersion can be achieved. Even in this case, since there is no need to notify the terminal device side of the distributed contents of the processing, the burden of changing the system configuration can be minimized.
Further, for the operation request from the terminal device side, the transfer destination can be dynamically changed according to the contents, for example, by monitoring the communication traffic by the mediation server. Even in this case, since the processing server has a function of returning an operation response by designating an appropriate transfer path, the operation response can be accurately returned to the source of the operation request.

In addition, a device corresponding to the mediation server may be installed in the customer environment so that messages related to a plurality of terminal devices can be collectively transferred. In this case, the mediation server and the terminal device in the customer's environment can be connected by a LAN, so a general communication protocol used for communication in the LAN is applied to the communication between them. Is possible.
Therefore, if such a protocol conversion function is provided in the intermediary server in the customer's environment, even a terminal device that does not support a special protocol can be used in a distributed processing system that uses a special protocol such as multipart transfer. The effect mentioned above can be acquired by connecting.

And even if this is done, since the mediation server and the terminal device in the customer's environment usually communicate via a network with limited communication partners, the processing load of the negotiation can be reduced. Even if the number of times increases, the communication efficiency does not decrease so much. Furthermore, since it is not necessary for the terminal device to correspond to a complicated communication protocol, it is possible to reduce labor and cost for configuring the system as a whole.
In this case, the connection between the mediation server in the customer's environment and the terminal device is not limited to the LAN, but a serial connection conforming to the RS-485 standard, a parallel connection conforming to the SCSI (Small Computer System Interface) standard, etc. You may go by. For example, in the case of the RS-485 standard, up to five terminal devices can be connected in series to the mediation server.

  Further, if no intermediary server is provided in the customer's environment, each terminal device individually makes a periodic communication request as described above in order to prevent stagnation of information transmission. Therefore, a large number of communication requests are flooded into the function providing side mediation server 102. Therefore, when a large number of terminal devices are provided in the customer environment, it is preferable that an intermediary server is also provided in the customer environment and the intermediary server makes a regular communication request as a representative.

  In this case, a system configuration as shown in FIG. 65 can be considered. In this figure, network home appliances such as a television receiver 10a and a refrigerator 10b, a medical device 10c, a vending machine 10d, a weighing system 10e, and an air conditioning system 10f are examples of managed devices that are separately provided with the customer environment side mediation server 112. Cite. As an example of a managed device that does not have the customer environment side mediation server 112 separately, an automobile 10g and an aircraft 10h are cited. In addition, it is preferable that an apparatus that moves over a wide range, such as an automobile 10g or an aircraft 10h, also has a firewall (FW) 11 function. Further, even if there is a firewall 11 between the customer environment side mediation server 112 and the function providing side mediation server 102, a communication request is always issued from the customer environment side mediation server 112 to transfer a message. Thus, there is no particular problem in message transfer.

Further, it is not necessary for the function providing side to provide the mediation server 102 and the processing server 103 by the same vendor. As long as the transfer destination of the command can be grasped in each intermediary server, it does not matter how the function is provided in the transfer destination processing server.
Therefore, on the terminal device side, commands to a plurality of processing servers that provide functions such as sightseeing spot guidance, timetable guidance, ticket reservation, and accommodation reservation are transmitted, and the XML data of each command response is processed and combined. If processing such as conversion into an HTML document is performed, the mediation server can also provide a service similar to a so-called portal site that provides the functions of a plurality of sites within one web page.

Further, in the above-described embodiment, the example has been described in which the terminal device does not describe the message regarding the destination or the transfer destination in the operation request and the operation response transmitted to the mediation server. However, on the terminal device side, the destination of the processing server to which the terminal device command should be transmitted and the information of the transmission source of the processing server command are grasped, and the destination is described in the command and command response transmitted to the mediation server. Also good.
In such a case, information on a destination and a transmission source may be described in a SOAP header in a SOAP message, and this may be described in a terminal device command sheet or a server side command sheet for management.

In addition, when the destination described in the operation request and operation response received from the terminal device is only itself or a device that can communicate directly, the mediation server does not provide a transfer destination table and is described in the SOAP header. The destination may be registered in the transfer message sheet as the transfer destination. When the destination can include a device to be transferred via another mediation server, the correspondence between the destination information and the device that is the direct transfer destination is stored as a transfer destination table. It is conceivable to determine the transfer destination of the next stage with reference to the table.
In any case, in order to interpret the contents of the SOAP header, it is necessary to deserialize the SOAP message once.

Even in such a configuration, the effect of improving the communication efficiency by collectively transferring operation requests addressed to a plurality of terminal devices from the processing server to the mediation server is the same as in the case of the above-described embodiment. Is obtained. This effect is particularly large when the mediation server is the above-described customer environment side mediation server.
Similarly, when the mediation server sends operation requests from a plurality of processing servers destined for the terminal device to the terminal device in a batch and receives operation responses to those operation requests in a batch, the communication efficiency is similarly improved. The effect is obtained. This effect is particularly significant when the mediation server is provided on the function providing side.
These effects can be obtained even when only an operation request from the processing server side and an operation response to the operation server are handled without handling an operation request from the terminal device side.
Needless to say, the modifications described above can be applied in combination within a consistent range.

  The program according to the present invention is a program for causing a computer to function as an intermediary device that mediates communication between the first communication device and the plurality of second communication devices. By executing it, the effects as described above can be obtained.

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, if the mediation device, distributed processing system, data transfer method, program, or recording medium of the present invention is used, a communication device transmits an operation request to a plurality of communication devices, and an operation response to the operation request. In the case of configuring a communication system that receives a message, it is possible to reduce the burden of managing destination information and to configure a communication system that can be stably operated even when the system configuration is changed.
Accordingly, by applying the present invention to such a communication system or an intermediary device that mediates communication in such a communication system, a communication system that reduces the burden of managing destination information and that can be easily changed is configured. Can do.

It is a block diagram which shows the structure of one Embodiment of the mediation server which is a mediation apparatus of this invention, and the distributed processing system which is a communication system comprised using the mediation server. It is a figure which shows the relationship between the operation request in the distributed processing system shown in FIG. 1, and an operation response. It is a block diagram which shows the structure of the remote management system which is a further example of the distributed processing system shown in FIG. FIG. 4 is a diagram illustrating a relationship between an operation request and an operation response in the remote management system illustrated in FIG. 3. It is a figure which similarly shows the example of the communication sequence between an image processing apparatus and a mediation server. It is a figure which similarly shows the example of the communication sequence between a mediation server and a processing server. It is a figure which shows another example of the communication sequence shown in FIG. It is a block diagram which shows the outline of the hardware constitutions of the mediation server shown in FIG. FIG. 2 is a block diagram schematically illustrating a hardware configuration of the image processing apparatus. It is a block diagram which shows the outline of the hardware constitutions of a processing server similarly.

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 mediation server shown in FIG. It is a figure which shows the example of the data structure in the terminal device command sheet | seat of the mediation server shown in FIG. It is a figure which similarly shows the example of the data structure in a mediation server command sheet. It is a figure which shows the example of the data structure in the transfer message sheet in the transfer message pool for transmission similarly. It is a figure which similarly shows the example of the data structure in the transfer message sheet in the transfer message pool for a reception. FIG. 4 is a diagram illustrating an example of an HTTP request received by the mediation server illustrated in FIG. 3 from the image processing apparatus. It is a figure which similarly shows the example of the HTTP response which a mediation server transmits to an image processing apparatus. It is a figure which similarly shows the example of the HTTP request which a mediation server transmits to a processing server. It is a figure which similarly shows the example of the HTTP response which a mediation server receives from a processing server. It is a figure which shows the example of the part which described the terminal device command with respect to a mediation server in the remote management system shown in FIG.

It is a figure which shows the example of the part which described the response with respect to the terminal device command similarly shown in FIG. It is a figure which shows the example of description of the part at the time of transferring similarly the terminal device command with respect to a processing server (sales management server) from an image processing apparatus to a mediation server. FIG. 23 is a diagram illustrating a description example of a part when the terminal device command illustrated in FIG. 22 is transferred from the mediation server to the processing server. FIG. 23 is a diagram illustrating a description example of a part when the response to the terminal device command illustrated in FIG. 22 is transferred from the processing server to the mediation server. FIG. 25 is a diagram illustrating a description example of a part when the command response illustrated in FIG. 24 is transferred from the mediation server to the image processing apparatus. It is a figure which shows the example of description of the part which described the mediation server command with respect to an image processing apparatus similarly. FIG. 27 is a diagram illustrating a description example of a part in which a response to the intermediary server command illustrated in FIG. 26 is described. It is a figure which shows the example of description of the part at the time of transferring the processing server command with respect to an image processing apparatus from a processing server to a mediation server. FIG. 29 is a diagram showing a description example of a part when the processing server command shown in FIG. 28 is transferred from the mediation server to the image processing apparatus. FIG. 29 is a diagram illustrating a description example of a part when the response to the processing server command illustrated in FIG. 28 is transferred from the image processing apparatus to the mediation server.

FIG. 31 is a diagram showing an example of part description when the command response shown in FIG. 30 is transferred from the mediation server to the processing server (sales management server). 4 is a flowchart showing basic operations of message collection and distribution processing related to communication with an image processing apparatus in the mediation server shown in FIG. 3. FIG. 33 is a flowchart showing message distribution processing shown in FIG. 32. FIG. It is a figure which shows the example of the transfer destination table which the mediation server shown in FIG. 3 memorize | stores. It is a flowchart which shows the transfer message collection process shown to step S14 of FIG. 32 in detail. It is a flowchart which shows the process after step S15 of FIG. 32 in detail. It is a flowchart which shows an example of the process regarding execution of the terminal device command in the mediation server shown in FIG. It is a flowchart which shows the other example. FIG. 4 is a flowchart showing processing relating to message transfer with a processing server in the mediation server shown in FIG. 3. FIG. 40 shows a flowchart of processing relating to execution timing control of the message transfer processing shown in FIG. 39.

4 is a flowchart illustrating another example of processing related to transfer of a terminal device command in the mediation server illustrated in FIG. 3. FIG. 4 is a functional block diagram illustrating a configuration of functions for performing processing relating to commands and command responses among the functions of the image processing apparatus illustrated in FIG. 3. It is a figure which shows the example of the data structure in the terminal device command sheet | seat of the image processing apparatus shown in FIG. It is a figure which similarly shows the example of the data structure in a server side command sheet. 4 is a flowchart showing basic operations of message collection and distribution processing in the image processing apparatus shown in FIG. 3. It is a flowchart which shows the process to step S114 of FIG. 45 in detail. It is a flowchart which shows the process after step S115 of FIG. 45 in detail. 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 processing server shown in FIG. It is a figure which shows the example of the path | route information table which the process server shown in FIG. 3 memorize | stores. 4 is a flowchart showing basic operations of message collection and distribution processing in the processing server shown in FIG. 3.

It is a flowchart which shows the process to step S215 of FIG. 50 in detail. It is a flowchart which shows the process after step S216 of FIG. 50 in detail. FIG. 51 is a flowchart showing the contents of a route information table update process shown in FIG. 4 is a flowchart showing a series of processing performed in each device from when the image processing device generates a terminal device command to be executed by the processing server until receiving a response to the command in the remote management system shown in FIG. 3. Similarly, it is a flowchart showing a series of processes performed in each apparatus from when the management server generates a management apparatus command addressed to the image processing apparatus to when a response to the command is received. It is a figure which shows another structural example of the distributed processing system which is embodiment of this invention. It is a figure which shows the further another structural example. FIG. 58 is a diagram showing a storage example of a route information table in the processing server J shown in FIG. 57. FIG. 35 is a diagram showing another example of the transfer destination table shown in FIG. 34. FIG. 60 is a diagram illustrating a configuration example of a distributed processing system when the transfer destination table illustrated in FIG. 59 is used.

It is a figure which shows another example of a transfer destination table. FIG. 62 is a diagram showing a configuration example of a distributed processing system when the transfer destination table shown in FIG. 61 is used. FIG. 63 is a diagram showing an example of data that can be used in place of the transfer destination table when the distributed processing system is configured as shown in FIG. 62. FIG. 36 is a flowchart corresponding to FIG. 33 and showing an example of message distribution processing executed when the data shown in FIG. 63 is used. It is a figure which shows another example of a structure of the distributed processing system which is embodiment of this invention.

Explanation of symbols

10: Terminal device 11: Firewall 12, 102: Mediation server 13, 103: Processing server 14: Internet 41, 141, 242: Terminal device command pool 42: Mediation server command pool 43, 244: Terminal device command execution result generation means 43a : Terminal device command handler 44: Mediation server command generation means 44a: Mediation server command generation handler 45, 145, 245: Message collection means 46, 246: HTTP server function unit 46a, 246a: HTTP response transmission means 46b, 246b: HTTP request Reception means 47, 147, 247: Message distribution means 48: Message transfer means 49, 146: HTTP client function unit 49a, 146a: HTTP request transmission means 49b, 146b: HTTP Ponce reception means 50: Transfer destination information storage means 51: Transmission message pool for transmission 52: Transfer message pool for reception 100: Image processing device 112: Customer environment side mediation server 125: Control device 142: Server side command pool 143: Terminal device Command generation means 144: Server side command execution result generation means 201, 301: CPU
241: Processing server command pool 243: Processing server command generation means 244: Terminal device command execution result generation means 250: Path information storage means

Claims (28)

An intermediary device that mediates communication between a first communication device and a plurality of second communication devices,
First receiving means for receiving an operation request from the first communication device;
First transmission means for transmitting each operation request received by the reception means to a second communication device as a transfer destination according to the type of the operation request;
Second receiving means for receiving an operation response to the operation request transferred from the first communication device from each of the second communication devices;
An intermediary device comprising: a second transmission unit configured to transmit each operation response received by the second reception unit to the first communication device. The intermediary device according to claim 1,
The first receiving means is provided with means for collectively receiving a plurality of operation requests from the first communication device,
An intermediary device, characterized in that said second transmission means is provided with means for collectively transmitting each operation response received by said second reception means to said first communication device. An intermediary device that mediates communication between a first communication device and a plurality of second communication devices,
A first receiving means for receiving an operation request from the first communication device and an operation response to the operation request transferred from the second communication device;
First transmission means for transmitting each operation request and operation response received by the first reception means to a second communication device as a transfer destination according to the type of each operation request and operation response;
Second receiving means for receiving, from each of the second communication devices, an operation request to be transferred to the first communication device and an operation response to the operation request transferred from the first communication device;
An intermediary device comprising: a second transmission unit configured to transmit each operation request and each operation response received by the second reception unit to the first communication device. The intermediary device according to claim 3,
The first receiving means includes means for collectively receiving an operation request from the first communication device and an operation response to the operation request transferred from the second communication device,
An intermediary device, characterized in that said second transmission means is provided with means for collectively transmitting each operation request and each operation response received by said second reception means to said first communication device. The intermediary device according to any one of claims 1 to 4,
For each operation request or operation response received from the first communication device, for each required group, storage means for storing transfer destination information of the operation request or operation response belonging to the group,
An intermediary device comprising transfer destination determination means for determining a transfer destination of an operation request or an operation response to be transmitted by the first transmission means with reference to transfer destination information stored in the storage means . The intermediary device according to claim 5, wherein
The intermediary apparatus, wherein the transfer destination determining means includes means for determining a transfer destination of an operation request or an operation response whose transfer destination information is not stored in the storage means as a predetermined transfer destination. The intermediary device according to claim 5 or 6,
The intermediary device, wherein the group is provided for each name space used in SOAP, the operation request is a SOAP request, and the operation response is a SOAP response. An intermediary device that mediates communication between a first communication device and a plurality of second communication devices,
A first receiving means for receiving a SOAP request from the first communication device and a SOAP response to the SOAP request transferred from the second communication device in a state described in the HTTP request;
First transmission means for transmitting each SOAP request and SOAP response received by the first reception means in a HTTP request to the second communication apparatus serving as a transfer destination according to the type of each SOAP request and SOAP response; ,
A SOAP request to be transferred to the first communication device and a SOAP response to the SOAP request transferred from the first communication device are received from each of the second communication devices in a state described in the HTTP response. A second receiving means;
Second transmission for transmitting each SOAP request and each SOAP response received by the second receiving means to the first communication device by describing them in an HTTP response to the HTTP request received by the first receiving means. And an intermediary device. The intermediary device according to claim 8, wherein
The first receiving means receives the SOAP request and the SOAP response to the SOAP request transferred from the second communication device from the first communication device in a state described in one HTTP request. Providing means,
Each SOAP request and each SOAP response received by the second receiving means are stored in the second transmitting means in one HTTP response to the HTTP request received by the first receiving means. An intermediary device comprising means for transmitting to the communication device. A distributed processing system comprising a plurality of processing servers and a mediation server that mediates communication between each processing server and a terminal device,
In the mediation server,
First receiving means for receiving an operation request from the terminal device;
First transmission means for transmitting each operation request received by the reception means to a processing server as a transfer destination according to the type of the operation request;
Second receiving means for receiving an operation response to the operation request from the terminal device from each processing server;
A second transmission unit configured to transmit each operation response received by the second reception unit to the terminal device;
For each processing server,
Receiving means for receiving, from the mediation server, an operation request for the processing server from the terminal device;
Means for executing an operation related to the operation request received by the means and generating an operation response to the operation request as an execution result;
A distributed processing system, comprising: a transmission unit configured to transmit an operation response generated by the unit to the mediation server. The distributed processing system according to claim 10,
In the mediation server,
The first receiving means is provided with means for collectively receiving a plurality of operation requests from the terminal device,
The distributed processing system, wherein the second transmitting means is provided with means for collectively transmitting the operation responses received by the second receiving means to the terminal device. A distributed processing system comprising a plurality of processing servers and a mediation server that mediates communication between each processing server and a terminal device,
In the mediation server,
First receiving means for receiving an operation request and an operation response to the operation request from the processing server from the terminal device;
First transmission means for transmitting each operation request and operation response received by the first reception means to a processing server as a transfer destination according to the type of each operation request and operation response;
Second receiving means for receiving, from each processing server, an operation request to be transferred to the terminal device and an operation response to the operation request from the terminal device;
A second transmission unit configured to transmit each operation request and each operation response received by the second reception unit to the terminal device;
For each processing server,
Receiving means for receiving, from the mediation server, an operation request for the processing server from the terminal device and an operation response to the operation request addressed to the terminal device;
Means for executing an operation related to the operation request received by the means and generating an operation response to the operation request as an execution result;
A distributed processing system comprising: a transmission unit configured to transmit an operation response generated by the unit and an operation request addressed to the terminal device to the mediation server. The distributed processing system according to claim 12,
In the mediation server,
The first receiving means is provided with means for collectively receiving an operation request and an operation response to the operation request from the processing server from the terminal device,
The distributed processing system, wherein the second transmitting means is provided with means for collectively transmitting each operation request and each operation response received by the second receiving means to the terminal device. A distributed processing system comprising a plurality of processing servers and a mediation server that mediates communication between each processing server and a terminal device,
In the mediation server,
A first receiving unit configured to receive a SOAP request and a SOAP response to the SOAP request from the processing server in a state described in the HTTP request from the terminal device;
First transmission means for transmitting each SOAP request and SOAP response received by the first reception means in a HTTP request to a processing server serving as a transfer destination according to the type of each SOAP request and SOAP response;
A second receiving means for receiving, from each processing server, a SOAP request to be transferred to the terminal device and a SOAP response to the SOAP request from the terminal device in a state described in an HTTP response;
A second transmitting means for transmitting each SOAP request and each SOAP response received by the second receiving means to the terminal device in a HTTP response to the HTTP request received by the first receiving means; Provided,
For each processing server,
Receiving means for receiving a SOAP request from the terminal device to the processing server and a SOAP response to the SOAP request addressed to the terminal device from the mediation server in a state described in an HTTP request;
Means for executing an operation related to the SOAP request received by the means and generating a SOAP response to the SOAP request as an execution result;
Provided is a transmission means for transmitting the SOAP response generated by the means and the SOAP request addressed to the terminal device to the intermediary server in the HTTP response to the HTTP request received by the reception means of the processing server. A distributed processing system characterized by The distributed processing system according to claim 14,
In the mediation server,
The first receiving means includes means for receiving a SOAP request from the terminal device and a SOAP response to the SOAP request from the processing server in a state described in one HTTP request,
The terminal device described in the second transmitting means by describing each SOAP request and each SOAP response received by the second receiving means in one HTTP response to the HTTP request received by the first receiving means. A distributed processing system, characterized in that means for transmitting is provided. A data transfer method for transmitting and receiving an operation request and an operation response between a first communication device and a plurality of second communication devices via an intermediary device,
In the mediating device,
A first reception procedure for receiving an operation request from the first communication device;
A first transmission procedure for transmitting each operation request received in the reception procedure to a second communication device serving as a transfer destination according to the type of the operation request;
A second receiving procedure for receiving an operation response to the operation request transferred from the first communication device from each of the second communication devices;
And a second transmission procedure for transmitting each operation response received in the second reception procedure to the first communication device. The data transfer method according to claim 16, comprising:
In the first reception procedure, a procedure for collectively receiving a plurality of operation requests from the first communication device is provided.
A data transfer method characterized in that the second transmission procedure includes a procedure for collectively transmitting the operation responses received in the second reception procedure to the first communication device. A data transfer method for transmitting and receiving an operation request and an operation response between a first communication device and a plurality of second communication devices via an intermediary device,
In the mediating device,
A first reception procedure for receiving, from the first communication device, an operation request and an operation response to the operation request transferred from the second communication device;
A first transmission procedure for transmitting each operation request and operation response received in the first reception procedure to a second communication device as a transfer destination according to the type of each operation request and operation response;
A second reception procedure for receiving, from each of the second communication devices, an operation request to be transferred to the first communication device, and an operation response to the operation request transferred from the first communication device;
A data transfer method comprising: executing a second transmission procedure for transmitting each operation request and each operation response received in the second reception procedure to the first communication device. The data transfer method according to claim 18, comprising:
In the first reception procedure, a procedure for collectively receiving an operation request from the first communication device and an operation response to the operation request transferred from the second communication device is provided.
A data transfer method characterized in that the second transmission procedure includes a procedure for collectively transmitting each operation request and each operation response received in the second reception procedure to the first communication device. . A data transfer method for transmitting and receiving an operation request and an operation response between a first communication device and a plurality of second communication devices via an intermediary device,
In the mediating device,
A first reception procedure for receiving a SOAP request from the first communication device and a SOAP response to the SOAP request transferred from the second communication device in a state described in the HTTP request;
A first transmission procedure in which each SOAP request and SOAP response received in the first reception procedure is described in an HTTP request and transmitted to a second communication apparatus serving as a transfer destination according to the type of each SOAP request and SOAP response; ,
A SOAP request to be transferred to the first communication device and a SOAP response to the SOAP request transferred from the first communication device are received from each of the second communication devices in a state described in the HTTP response. A second receiving procedure;
A second transmission in which each SOAP request and each SOAP response received in the second reception procedure are described in an HTTP response to the HTTP request received in the first reception procedure and transmitted to the first communication device. A data transfer method characterized by causing a procedure to be executed. The data transfer method according to claim 20, wherein
A procedure for receiving, in the first reception procedure, a SOAP request from the first communication device and a SOAP response to the SOAP request transferred from the second communication device in a state described in one HTTP request. Provided,
In the second transmission procedure, each SOAP request and each SOAP response received in the second reception procedure are described in one HTTP response to the HTTP request received by the first reception procedure. A data transfer method characterized in that a procedure for transmission to a communication device is provided. A program for causing a computer to function as an intermediary device that mediates communication between a first communication device and a plurality of second communication devices,
The computer,
First receiving means for receiving an operation request from the first communication device;
First transmission means for transmitting each operation request received by the reception means to a second communication device as a transfer destination according to the type of the operation request;
Second receiving means for receiving an operation response to the operation request transferred from the first communication device from each of the second communication devices;
A program for causing each operation response received by the second receiving means to function as a second transmitting means for transmitting to the first communication device. The program according to claim 22, wherein
The first receiving means is provided with a function of collectively receiving a plurality of operation requests from the first communication device,
A program characterized in that the second transmitting means is provided with a function of collectively transmitting each operation response received by the second receiving means to the first communication device. A program for causing a computer to function as an intermediary device that mediates communication between a first communication device and a plurality of second communication devices,
The computer,
A first receiving means for receiving an operation request from the first communication device and an operation response to the operation request transferred from the second communication device;
First transmission means for transmitting each operation request and operation response received by the first reception means to a second communication device as a transfer destination according to the type of each operation request and operation response;
Second receiving means for receiving, from each of the second communication devices, an operation request to be transferred to the first communication device and an operation response to the operation request transferred from the first communication device;
A program for causing each operation request and each operation response received by the second receiving means to function as second transmitting means for transmitting to the first communication device. A program according to claim 24, wherein
The first receiving unit is provided with a function of collectively receiving an operation request from the first communication device and an operation response to the operation request transferred from the second communication device,
A program characterized in that the second transmission means is provided with a function of collectively transmitting each operation request and each operation response received by the second reception means to the first communication device. A program for causing a computer to function as an intermediary device that mediates communication between a first communication device and a plurality of second communication devices,
The computer,
A first receiving means for receiving a SOAP request from the first communication device and a SOAP response to the SOAP request transferred from the second communication device in a state described in the HTTP request;
First transmission means for transmitting each SOAP request and SOAP response received by the first reception means in a HTTP request to the second communication apparatus serving as a transfer destination according to the type of each SOAP request and SOAP response; ,
A SOAP request to be transferred to the first communication device and a SOAP response to the SOAP request transferred from the first communication device are received from each of the second communication devices in a state described in the HTTP response. A second receiving means;
Second transmission for transmitting each SOAP request and each SOAP response received by the second receiving means to the first communication device by describing them in an HTTP response to the HTTP request received by the first receiving means. Program to function as a means. The program according to claim 26, wherein
A function of receiving, in the first receiving unit, a SOAP request from the first communication device and a SOAP response to the SOAP request transferred from the second communication device in a state described in one HTTP request. Provided,
Each SOAP request and each SOAP response received by the second receiving means are stored in the second transmitting means in one HTTP response to the HTTP request received by the first receiving means. A program provided with a function of transmitting to a communication device. A computer-readable recording medium on which the program according to any one of claims 22 to 27 is recorded.

Images