JP2017016517A - Information processing system, information processing method, and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To update some modules of an application which includes a plurality of modules, without suspending the application, while maintaining processing consistency, with a low load.SOLUTION: An application server 100 includes a module receiving unit 110 and a module generation unit 120. The module receiving unit 110 receives an update of an execution file of each of modules constituting an application. When an execution file of a first module of the modules is updated, the module generation unit 120 generates a new load module using the updated execution file, for the first module. The module generation unit 120 generates a new load module for calling the new load module of the first module, for a second module calling the first module.SELECTED DRAWING: Figure 1

Description

  The present invention relates to an information processing system, an information processing method, and a program, and more particularly, to an information processing system, an information processing method, and a program for updating an application.

  An application running on an application server may be required to operate continuously for 24 hours 365 days. On the other hand, when updating an application for correcting a defect or expanding a function, it is generally necessary to stop the application.

  As an example of a method of continuing the operation of the application at the time of update, there is a method of operating the application before the change and the application after the change at the same time and switching the request distribution destination from the pre-change to the application after the change. Here, when processing is performed on a session configured by a plurality of requests, it is necessary to switch applications for each session in order to maintain consistency of processing within the session. That is, a request for a session that has been processed before the change is distributed to the application before the change, and a request for a new session after the change is distributed to the application after the change.

  FIG. 29 is a diagram illustrating an example of a general application operation continuation method. In the example of FIG. 29, requests are distributed based on a correspondence table (session table) between the session ID (Identifier) and the version of the application that processes the session.

  Furthermore, the application may be configured by a plurality of modules. For example, an application deployed in a Java (registered trademark) EE (Enterprise Edition) application server includes a Web module, an EJB (Enterprise JavaBeans) module, and the like. In this case, the Web module accepts a request from the Web browser of the client terminal, and the EJB module executes back-end processing. An EJB module may also call other EJB modules. In this way, in an application composed of a plurality of modules, if there is no change in the module call interface, the changed module can be updated without updating the module that calls the changed module.

  30 to 33 are diagrams illustrating an example of a general operation continuation method of an application configured by a plurality of modules.

  Here, when updating a module that directly accepts a request, as shown in FIG. 30, update is performed while maintaining the consistency of processing without stopping the application in the same manner as the method of FIG. 29 described above. Can do. However, when a module called from another module is updated, as shown in FIG. 31, the module that directly accepts the request is not updated, so the module before the update of the updated module is called and the module update is not reflected. . Also, as shown in FIG. 32, when the latest module is always called to reflect the module update, the updated module is applied to the session that was started before the module update. Sex is not kept.

  As a method for solving this problem, as shown in FIG. 33, a correspondence table between session IDs and module versions is prepared for each module, and an appropriate version of a called module is selected while passing the session ID between modules. There is a way. In this case, even a module that does not use a session needs to have a correspondence table for version selection. Further, since the module version is selected every time the module is called, the processing load on the application increases.

  Note that in Patent Document 1, as in FIG. 33 described above, when a part of application programs is updated in a system including a plurality of application programs (corresponding to the modules described above), both new and old files are used. A technique for performing the operation is disclosed. In this technique, each time a task is activated, whether to operate the task according to a new file or an old file is selected based on information held by the task.

Japanese Unexamined Patent Publication No. 7-99674

  As described above, in order to update a part of an application composed of multiple modules without stopping the application and maintaining processing consistency, it is necessary to select a version for each module. Application processing load increases.

  The objective of this invention is providing the information processing system, the information processing method, and program which solved the subject mentioned above. That is, an object of the present invention is to provide an information processing system and an information processing system that can update a part of an application composed of a plurality of modules at a low load without stopping the application and maintaining processing consistency. It is to provide a method and a program.

  The information processing system of the present invention receives a module receiving unit that receives an update of an execution file of each of a plurality of modules constituting an application, and an execution file of a first module among the plurality of modules is updated. A new load module using the updated execution file is generated for the first module, and a new load module of the first module is called for the second module that calls the first module. Module generating means for generating a new load module.

  The information processing method of the present invention receives an update of each executable file of a plurality of modules constituting an application, and when the executable file of the first module among the plurality of modules is updated, the first information For a module, a new load module that uses the updated execution file is generated, and a new load module that calls a new load module of the first module is created for a second module that calls the first module. Generate.

  The program of the present invention receives an update of an execution file of each of a plurality of modules constituting an application in a computer, and when the execution file of the first module among the plurality of modules is updated, the first For the second module, a new load module using the updated execution file is generated, and for the second module that calls the first module, a new load module that calls the new load module of the first module To generate the process.

  An effect of the present invention is that an update of a part of an application constituted by a plurality of modules can be realized with a low load while maintaining the consistency of processing without stopping the application.

It is a block diagram which shows the characteristic structure of embodiment of this invention. It is a block diagram which shows the structure of the execution environment of an application in embodiment of this invention. It is a block diagram which shows the structure of the application server 100 implement | achieved by computer in embodiment of this invention. It is a flowchart which shows the module deployment process in embodiment of this invention. It is a flowchart which shows the detail of a module production | generation process in embodiment of this invention. It is a flowchart which shows the detail (continuation of FIG. 5) of the module production | generation process in embodiment of this invention. It is a flowchart which shows a request process in embodiment of this invention. It is a flowchart which shows the detail of the module execution process in embodiment of this invention. It is a figure which shows the structure of the load module 400 loaded into the module execution part 130 in embodiment of this invention. It is a figure which shows the example of the calling relationship between modules in embodiment of this invention. It is a figure which shows the example of the executable file table 151 in embodiment of this invention. It is a figure which shows the example of the version table 161 in embodiment of this invention. It is a figure which shows the example of the load version table 162 in embodiment of this invention. It is a figure which shows the example of the call relationship table 171 in embodiment of this invention. It is a figure which shows the example of the session table 181 in embodiment of this invention. It is a figure which shows the example of the calling relationship between the load modules 400 in embodiment of this invention. It is a figure which shows the other example of the executable file table 151 in embodiment of this invention. It is a figure which shows the other example of the version table 161 in embodiment of this invention. It is a figure which shows the other example of the load version table 162 in embodiment of this invention. It is a figure which shows the other example of the call relationship table 171 in embodiment of this invention. It is a figure which shows the other example of the session table 181 in embodiment of this invention. It is a figure which shows the other example of the calling relationship between the load modules 400 in embodiment of this invention. It is a figure which shows the further another example of the executable file table 151 in embodiment of this invention. It is a figure which shows the further another example of the version table 161 in embodiment of this invention. It is a figure which shows the further another example of the load version table 162 in embodiment of this invention. It is a figure which shows the further another example of the call relationship table 171 in embodiment of this invention. It is a figure which shows the further another example of the session table 181 in embodiment of this invention. It is a figure which shows the further another example of the calling relationship between the load modules 400 in embodiment of this invention. It is a figure which shows the example of the general operation | movement continuation method of an application. It is a figure which shows the example of the operation | movement continuation method of the application comprised with the general several module. It is a figure which shows the other example of the general operation | movement continuation method of the application comprised with the general several module. It is a figure which shows the other example of the general operation | movement continuation method of the application comprised with the general several module. It is a figure which shows the other example of the general operation | movement continuation method of the application comprised with the general several module.

  First, the configuration of the embodiment of the present invention will be described. FIG. 2 is a block diagram showing the configuration of the application execution environment in the embodiment of the present invention. Referring to FIG. 2, the execution environment includes an application server 100, a management terminal 200, and a client terminal 300. The management terminal 200 and the client terminal 300 are connected to the application server 100 via a network or the like.

  The management terminal 200 transmits an execution file of a plurality of program modules (hereinafter simply referred to as modules) constituting the application to the application server 100, and instructs deployment of the application.

  The client terminal 300 transmits a request relating to application processing to the application server 100.

  The application server 100 receives a request from the client terminal 300 and executes application processing. The application server 100 is an embodiment of the information processing system of the present invention.

  The application server 100 includes a module reception unit 110, a module generation unit 120, a module execution unit 130, and a request distribution unit 140. The application server 100 further includes a module storage unit 150, a version information storage unit 160, a call relationship storage unit 170, and a session information storage unit 180.

  The module reception unit 110 receives an updated execution file for each of a plurality of modules constituting the application from the management terminal 200.

  The module storage unit 150 stores the execution file table 151 and the substance of the execution file. The execution file table 151 indicates an execution file of each of a plurality of modules constituting the application.

  11, FIG. 17, and FIG. 23 are diagrams showing examples of the execution file table 151 in the embodiment of the present invention. In the execution file table 151, each module name of a plurality of modules is associated with a version (file version) of the execution file of the module and a file name.

  When the execution file of the first module among a plurality of modules is updated, the module generation unit 120 generates a new load module 400 using the updated execution file for the first module. To the module execution unit 130. Further, the module generation unit 120 generates a new load module 400 that calls the new load module 400 of the first module for the second module that depends on the first module, and loads the new load module 400 to the module execution unit 130. To do.

  FIG. 9 is a diagram showing a configuration of the load module 400 loaded into the module execution unit 130 in the embodiment of the present invention. The load module 400 includes a process execution unit 401 and a calling unit 402.

  The process execution unit 401 executes a process related to the module according to the module execution file. The calling unit 402 calls the process of the load module 400 of another module on which the module depends. When a module depends on a plurality of other modules, a calling unit 402 exists for each of the other modules.

  The module execution unit 130 executes the load module 400 loaded by the module generation unit 120.

  The version information storage unit 160 stores a version table 161 and a load version table 162. The version table 161 shows the latest load module 400 of each module. The load version table 162 shows each load module 400 loaded into the module execution unit 130.

  FIGS. 12, 18 and 24 are diagrams showing examples of the version table 161 in the embodiment of the present invention. In the version table 161, the latest version of the load module 400 (module version) of the module is associated with each module name of the plurality of modules.

  13, 19, and 25 are diagrams showing examples of the load version table 162 in the embodiment of the present invention. In the load version table 162, each module name of the plurality of modules is associated with the module version of the load module 400 of the module and the file version of the execution file.

  The call relationship storage unit 170 stores a call relationship table 171. The call relationship table 171 indicates the call relationship between modules.

  14, FIG. 20, and FIG. 26 are diagrams showing examples of the call relation table 171 in the embodiment of the present invention. In the call relationship table 171, the module name and module version pair of the call source module is associated with the module name and module version pair of the callee module.

  The session information storage unit 180 stores a session table 181. The session table 181 shows the load module 400 to which each session is distributed.

  15, FIG. 21, and FIG. 27 are diagrams showing examples of the session table 181 in the embodiment of the present invention. In the session table 181, the session ID (Identifier) of the session for the module and the module version of the load module 400 that is the distribution destination are associated with the module name of the module.

  The request distribution unit 140 distributes the request received from the client terminal 300 to an appropriate load module 400 based on the session table 181.

  Note that the application server 100 may be a computer that includes a CPU (Central Processing Unit) and a storage medium that stores a program, and that operates by control based on the program.

  FIG. 3 is a block diagram showing a configuration of the application server 100 realized by a computer in the embodiment of the present invention.

  In this case, the application server 100 includes a CPU 101, a storage device 102 (storage medium) such as a hard disk and a memory, a communication device 103 that communicates with other devices, and an input / output device 104 such as a keyboard and a display. The CPU 101 executes a computer program for realizing the module reception unit 110, the module generation unit 120, the module execution unit 130, and the request distribution unit 140. The storage device 102 stores data of the module storage unit 150, the version information storage unit 160, the call relationship storage unit 170, and the session information storage unit 180. The communication device 103 receives a module from the management terminal 200. In addition, the communication device 103 receives a request relating to application processing from the client terminal 300 and transmits a response to the client terminal 300. The input / output device 104 performs input from a user or the like, such as various settings related to the application server 100, and output to the user or the like.

  In addition, each component of the application server 100 may be distributed and arranged in different computers connected by wire or wirelessly.

  Each component of the application server 100 may be an independent logic circuit.

  Next, the operation of the embodiment of the present invention will be described.

<Module deployment processing>
First, module deployment processing will be described. The module deployment process is executed when the management terminal 200 transmits an execution file of a module constituting an application to the application server 100.

  FIG. 4 is a flowchart showing module deployment processing in the embodiment of the present invention.

  The management terminal 200 transmits the module name of the module constituting the application, the file name of the new executable file of the module, and the substance of the executable file to the application server 100 (step S101).

  The module reception unit 110 of the application server 100 receives the module name M, the file name F, and the execution file from the management terminal 200 (step S102).

  The module receiving unit 110 assigns a new module version V of the load module 400 of the module M (Step S103).

  Here, the module reception unit 110 sets a value obtained by adding 1 to the maximum value of the module version for the module M existing in the load version table 162 as a new module version V. Note that if the module M is a new module, the module M does not exist in the load version table 162, so the module reception unit 110 sets “1” for the new module version V for the module M.

  The numbered module version V is also used as the file version of the new execution file F of the module M.

  The module receiving unit 110 registers the received module name M, file name F, and file version V in the execution file table 151. In addition, the module reception unit 110 stores the received executable file F in the module storage unit 150 (step S104).

  The module receiving unit 110 causes the module generation unit 120 to specify the module name M, the module version V, and the file version V, and execute the module generation process (step S105).

  As a result, a new load module 400 using the updated execution file of the file version V is generated and loaded for the module M.

  5 and 6 are flowcharts showing details of the module generation processing (step S105) in the embodiment of the present invention.

  The module generation unit 120 refers to the execution file table 151, and acquires the substance of the execution file F corresponding to the module name M and the file version FV from the module storage unit 150 (step S201).

  The module generation unit 120 analyzes the execution file F and specifies a call destination module S of the execution file F (step S202). Here, for example, when the module M is a Java EE application module, an XML (Extensible Markup Language) file and annotation definition information related to the module are analyzed to identify the callee module S. Further, the module generation unit 120 may identify the callee module S with reference to the call relationship between modules defined in advance by a user or the like.

  If the callee module S does not exist in step S202 (step S203 / N), the module generation unit 120 generates the process execution unit 401 using the execution file F and sets it in the load module 400. The module generation unit 120 loads the generated load module 400 into the module execution unit 130 as the load module 400 of the module version V (Step S210).

  On the other hand, when there is a call destination module S in step S202 (step S203 / Y), the module generation unit 120 selects one of the specified call destination modules S (step S204).

  The module generation unit 120 acquires the latest module version SV for the selected call destination module S from the version table 161 (step S205).

  The module generation unit 120 generates the calling unit 402 so as to call the load module 400 of the version SV of the module S (Step S206). The module generation unit 120 registers a pair of the callee module S and the module version SV and a pair of the caller module M and the module version V in the call relation table 171 (Step S207).

  The module generation unit 120 repeats the processing from step S204 for all the specified callee modules S (step S208).

  The module generation unit 120 generates the process execution unit 401 using the execution file F, and sets it in the load module 400 together with the generated calling unit 402. The module generation unit 120 loads the generated load module 400 into the module execution unit 130 as the load module 400 of the module version V (Step S209).

  The module generation unit 120 registers the module name M, the module version V, and the file version FV in the load version table 162 (step S211).

  Next, the module generation unit 120 acquires the latest module version PV so far for the module M from the version table 161 (step S212).

  When there is no latest module version PV (in the case of a new module) (step S213 / N), the module generation unit 120 registers the module name M and the latest module version V in the version table 161 (step S214). Then, the module generation unit 120 ends the module generation process.

  On the other hand, when there is the latest module version PV (file update) (step S213 / Y), the module generation unit 120 updates the latest module version for the module M in the version table 161 with V (step S215).

  The module generation unit 120 refers to the call relation table 171 and specifies a set of the module name T and the module version TV of the other load module 400 that calls the load module 400 of the module version PV of the module M (step S216).

  If there is no other load module 400 in step S216 (step S217 / N), the module generation unit 120 ends the module generation process.

  In step S216, when another load module 400 exists (step S217 / Y), the module generation unit 120 selects one of the specified module name T and module version TV (step S218).

  The module generation unit 120 assigns a new module version NV of the load module 400 of the module T (Step S219).

  Here, the module generation unit 120 sets a value obtained by adding 1 to the maximum value of the module version of the module T existing in the load version table 162 as the module version NV.

  The module generation unit 120 acquires the file version TFV for the module version TV of the module T from the load version table 162 (step S220).

  The module generation unit 120 recursively executes module generation processing (steps S201 to S222) for the module name T, the new module version NV, and the file version TFV (step S221).

  The module generation unit 120 repeats the processing from step S218 for all the combinations of the other module name T and module version TV specified in step S216 (step S222).

  As a result, a new load module 400 that calls the latest load module 400 of the module M is generated and loaded using the execution file of the latest file version TFV for the module T that calls the module M.

  Similarly, for the module that calls the module T, a new load module 400 that calls the latest load module 400 of the module T is generated and loaded using the execution file of the latest file version.

<Request processing>
Next, request processing will be described. The request processing is executed when the client terminal 300 transmits a request related to application processing to the application server 100.

  FIG. 7 is a flowchart showing request processing in the embodiment of the present invention.

  The client terminal 300 transmits a request for the module M to the application server 100 (step S301).

  The request distribution unit 140 of the application server 100 receives a request for the module M from the client terminal 300 (step S302).

  The request distribution unit 140 acquires a session ID SID from the request (step S303).

  If the session ID is not included in the request (step S304 / N), the request distribution unit 140 assigns a new session ID SID and sets it in the request (step S305). The request distribution unit 140 acquires the latest module version V of the module M from the version table 161 (step S306). The request distribution unit 140 registers the session ID SID, the module name M, and the module version V in the session table 181 (Step S307).

  When the session ID is included in the request (step S304 / Y), the request distribution unit 140 acquires the module version V corresponding to the session ID SID and the module name M from the session table 181 (step S308).

  The request distribution unit 140 transfers the request to the load module 400 of the module version V of the module M (Step S309). The module execution unit 130 executes the process of the load module 400 of the module version V of the module M (Step S310).

  The module execution unit 130 sends the processing result of the load module 400 of the module M as a reply to the client terminal 300 (step S311). Here, the reply includes the session ID set in the request.

  The client terminal 300 receives a reply from the application server 100 (step S312).

  FIG. 8 is a flowchart showing details of the module execution process (step S310) in the embodiment of the present invention.

  The module execution unit 130 receives a request for the load module 400 of the module version V of the module M (step S401).

  The module execution unit 130 executes the process of the module M by the load module 400 of the module version V of the module M (Step S402).

  Here, the process execution unit 401 of the load module 400 executes the process of the module M. Further, when the module M calls another module T, the calling unit 402 of the load module 400 calls the load module 400 of the module version TV of the called module T. Thereby, the module execution process (steps S401 and S402) is recursively executed.

  In the request processing described above, when the session ID is not included in the request, the request distribution unit 140 assigns a new session ID to the request. However, the present invention is not limited to this, and the client terminal 300 may perform session ID numbering. In this case, when the request distribution unit 140 receives a request for a new session including a session ID that is not registered in the session table 181, the request distribution unit 140 performs the processes of steps S306 and S307 described above. When the request distribution unit 140 receives a request including a session ID registered in the session table 181, the request distribution unit 140 performs the process of step S <b> 308 described above.

<Specific example>
Next, a specific example of the operation of the embodiment of the present invention will be described.

  FIG. 10 is a diagram illustrating an example of a calling relationship between modules in the embodiment of the present invention. Here, it is assumed that the application includes four modules A, B, C, and D as shown in FIG. Further, as shown in FIG. 10, it is assumed that the client terminal 300 calls the module A, the module A calls the module B, the module B calls the module C, and the module C calls the module D.

  Further, it is assumed that module A: “A. war”, module B: “B. jar”, module C: “C. jar”, and module D: “D. jar” exist as execution files of each module. Furthermore, as an execution file updated (changed) for each module, module A ′: “A-modified.war”, module C ′: “C-modified.jar”, module C ″: “C-modified-2” .Jar "exists. Here, “′” given to the module name indicates a module whose execution file has been changed.

  First, in the state where no load module 400 is loaded, the execution files “D.jar”, “C.jar”, “B.jar”, “A” of modules D, C, B, and A from the management terminal 200 are displayed. .War "in turn and assume that the application has been deployed.

  In this case, the execution file table 151, the version table 161, the load version table 162, and the call relationship table 171 are respectively as shown in FIGS. 11, 12, 13, and 14 by the module deployment process described above. Is set.

  16, FIG. 22, and FIG. 28 are diagrams showing an example of a calling relationship between the load modules 400 in the embodiment of the present invention. “A (b, c)” given to the load module 400 indicates the load module 400 of the module a and the module version b, and indicates that the load module 400 uses the execution file of the file version c.

  In this case, the calling relationship between the load modules 400 is as shown in FIG.

  Here, it is assumed that a request for a new session (session ID “101”) for module A is received.

  In this case, the session table 181 is set as shown in FIG. 15 by the request processing described above. For the request with the session ID “101”, the load modules 400 “A (1, 1)”, “B (1, 1)”, “C (1, 1)”, and “ D (1,1) "is executed.

  Next, it is assumed that the execution file “C-modified.jar” of the module C ′ is received from the management terminal 200.

  In this case, the execution file table 151, the version table 161, the load version table 162, and the call relation table 171 are respectively as shown in FIGS. 17, 18, 19, and 20 by the module deployment process described above. Updated. The calling relationship between the load modules 400 is as shown in FIG.

  Here, it is assumed that a request for a new session (session ID “102”) for module A is received after module C is updated.

  In this case, the session table 181 is set as shown in FIG. 21 by the request processing described above. In response to the request with the session ID “102”, the load modules 400 “A (2, 1)”, “B (2, 1)”, “C ′ (2, 2)” in FIG. “D (1, 1)” is executed. For the request with the session ID “101”, the load modules 400 “A (1, 1)”, “B (1, 1)”, “C (1, 1)” in FIG. “D (1, 1)” is executed.

  Further, it is assumed that the execution file “A-modified.war” of the module A ′ is received from the management terminal 200 and the execution file “C-modified-2.jar” of the module C ″ is received.

  In this case, the execution file table 151, the version table 161, the load version table 162, and the call relation table 171 are respectively as shown in FIGS. 23, 24, 25, and 26 by the module deployment process described above. Updated. The calling relationship between the load modules 400 is as shown in FIG.

  Here, it is assumed that a new session request (session ID “103”) for module A is received after module A is updated but before module C ′ is updated. Further, it is assumed that a new session request (session ID “104”) is received for module A after the module C ′ is updated.

  In this case, the session table 181 is set as shown in FIG. 27 by the request processing described above. In response to the request with the session ID “104”, the load modules 400 “A ′ (4,3)”, “B (3,1)”, “C ″ (3,3)” in FIG. And "D (1, 1)" is executed. Further, in response to the request with the session ID “103”, the load modules 400 “A ′ (3, 3)”, “B (2, 1)”, “C ′ (2, 2)” in FIG. , “D (1,1)” is executed.

  Thus, the operation of the embodiment of the present invention is completed.

  Next, a characteristic configuration of the embodiment of the present invention will be described. FIG. 1 is a block diagram showing a characteristic configuration of an embodiment of the present invention.

  Referring to FIG. 1, the application server 100 (information processing system) includes a module reception unit 110 and a module generation unit 120.

  The module reception unit 110 receives an update of each executable file of a plurality of modules constituting the application.

  When the execution file of the first module among a plurality of modules is updated, the module generation unit 120 generates a new load module 400 using the updated execution file for the first module. . Further, the module generation unit 120 generates a new load module 400 that calls the new load module 400 of the first module for the second module that calls the first module.

  Next, the effect of the embodiment of the present invention will be described.

  According to the embodiment of the present invention, an update of a part of an application composed of a plurality of modules can be realized with a low load while maintaining the consistency of processing without stopping the application. The reason is that when the execution file of the first module is updated, the module generation unit 120 calls the new load module 400 that calls the new load module 400 of the first module for the second module that calls the first module. It is for producing | generating.

  As a result, the calling relationship between the load modules 400 using the updated execution file is added while maintaining the calling relationship between the load modules 400 using the execution file before the update. Therefore, by selecting the load module 400 of the module that directly receives a request from the client terminal 300 according to the session ID, consistency of application processing is maintained before and after the execution file is updated. It is.

  As a result, if the load module 400 of a module that directly receives a request from the client terminal 300 is determined, the load module 400 of another module is determined. Therefore, it is not necessary to select the module version of the load module 400 between modules. For example, it is not necessary to prepare a correspondence table between the session ID and the module version of the load module 400 for each module, and select the module version of the load module 400 to be called while delivering the session ID between the modules. For this reason, an increase in processing load accompanying the selection of the load module 400 between modules can be suppressed.

  While the present invention has been described with reference to the embodiments, the present invention is not limited to the above embodiments. Various changes that can be understood by those skilled in the art can be made to the configuration and details of the present invention within the scope of the present invention.

  For example, the module generation unit 120 may store the analysis result of the execution file call destination module (step S202) in the module generation process described above in an analysis result storage unit (not shown) or the like. In this case, when the analysis result is already stored in the analysis result storage unit, the module generation unit 120 uses the analysis result. In the module generation process of the caller module when the load module 400 of the callee module is updated, the execution file is not updated. Therefore, the analysis of the executable file can be omitted by using the analysis result stored in the analysis result storage unit.

100 Application server 101 CPU
DESCRIPTION OF SYMBOLS 102 Storage device 103 Communication device 104 Input / output device 110 Module reception part 120 Module generation part 130 Module execution part 140 Request distribution part 150 Module storage part 160 Version information storage part 170 Call relation storage part 180 Session information storage part 151 Execution file table 161 Version table 162 Load version table 171 Calling relation table 181 Session table 200 Management terminal 300 Client terminal 400 Load module 401 Processing execution part 402 Calling part

Claims (9)

Module accepting means for accepting update of each executable file of a plurality of modules constituting the application;
When the execution file of the first module among the plurality of modules is updated, a new load module using the updated execution file is generated for the first module, and the first module is generated. Module generating means for generating a new load module for calling a new load module of the first module for the second module for calling
An information processing system with The module generation means recursively repeats generating a new load module that calls a new load module of the second module for the third module that calls the second module.
The information processing system according to claim 1. Furthermore, when a request for a new session for any one of the modules is received, the session is associated with the latest load module of the module, and requests subsequent to the received request for the session are A request distribution unit that distributes to the associated load module;
The information processing system according to claim 1 or 2. The module generation means uses the latest execution file of the module when the execution file of any of the plurality of modules is updated or a new load module of the called module is generated. Call the latest load module of the called module, create a new load module for the module,
The information processing system according to claim 1. The module generation means includes a processing execution unit that performs processing related to the module based on the latest execution file of the module, and a calling unit that calls the latest load module of the module that is the calling destination of the module Generate
The information processing system according to claim 4. Accept update of each executable file of multiple modules that make up the application,
When the execution file of the first module among the plurality of modules is updated, a new load module using the updated execution file is generated for the first module, and the first module is generated. For the second module that calls, generate a new load module that calls the new load module of the first module,
Information processing method. Further, recursively repeating generation of a new load module for calling a new load module of the second module for the third module for calling the second module,
The information processing method according to claim 6. Furthermore, when a request for a new session for any one of the modules is received, the session is associated with the latest load module of the module, and requests subsequent to the received request for the session are Distribute to the associated load module,
The information processing method according to claim 6 or 7. On the computer,
Accept update of each executable file of multiple modules that make up the application,
When the execution file of the first module among the plurality of modules is updated, a new load module using the updated execution file is generated for the first module, and the first module is generated. For the second module that calls, generate a new load module that calls the new load module of the first module,
A program that executes processing.

Images