JPH1021059A - Software version management system for network system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To surely match the versions of software of an execution client with each other, to prevent inconsistency due to version mismatching, and to actualize stable system operation by replacing a client program of mismatching version on the client side. SOLUTION: On the side of a client machine 2, it is judged whether the version of a client program 13 matches with that of a server program 14 according to a version check result transferred form, a server machine 1. When it is judged that they do not match with each other, the client program 13 is replaced so that its version will matches the version of the server program 14 and a replacing client program 13 is executed. Consequently, when the client program 13 is executed, its version can surely be matched with the version of the server program 14.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a software version management system for a network system, and more particularly, to a software version management system operating on a distributed system. The present invention relates to a software version management method for a network system capable of realizing a stable system operation by ensuring that the version of software of a client to be executed is matched and preventing inconsistency due to version mismatch.

[0002]

2. Description of the Related Art In a conventional software version management system operating on a distributed system, software installed on each machine and its version information are centrally managed by a version management database. This conventional software version management method includes the additional function of software distribution function, such as software distribution function when managing the software and its version information, and retry function when software distribution fails, etc. As a way to ensure the consistency of the software version of each client at the time of distribution, and to manage the version information of the entire distributed system, periodically check the software version of each client and check for version mismatch There is known a configuration in which, when a detection is made, a client whose version does not match is instructed to replace software in order to match the version.

First, a description will be given of a conventional software version management system in which the former schedule function and the retry function in the event of software distribution failure are used to ensure that the versions of the entire system match, with reference to the drawings. FIG. 8 is a flowchart showing a system operation flow in a conventional software version management method. After setting the schedule information such as the distribution destination and the replacement time of the software to be distributed (step S801), the software distribution server performs a software distribution process to the distribution destination client according to the set schedule information, and replaces the software with the client. The file is distributed (step S802). At this time, information such as the software replacement time of the set schedule information is also transmitted to the client.

[0004] Upon receiving the software replacement file distributed from the software distribution server (step S803), the client notifies the software distribution server of the reception result of the software replacement file (step S804). The client receives the software replacement file distributed from the software distribution server, and when the software replacement file is normally received, information such as the software replacement time in the schedule information transmitted and received from the software distribution server. , A software replacement process is performed (step S805).

[0005] The client notifies the software distribution server of the result of the software replacement process (step S806). The software distribution server receives the software replacement file reception confirmation result and the software replacement processing result notified from the client (step S807), and based on the received software distribution result, determines whether the software distribution is normally processed. It is determined whether or not it is (step S808).

When the software distribution server determines that the software distribution has not been processed normally and has failed (step S808), the software distribution server distributes the software to the client again without changing the set schedule information (step S802). . On the other hand, when the software distribution server determines that the software distribution has been normally processed (step S808), it determines whether there is any other software to be replaced (step S809). (Step S80)
1) If not, the process ends.

In this conventional software version control system, when a client periodically replaces software according to schedule information set on the distribution server side, fails when software distribution from the distribution server fails, or when the client fails to replace software. Then, the software is distributed again from the distribution server to perform the software replacement process.

Next, a description will be given of a conventional software version management method in which a software replacement is instructed when the latter version is periodically checked and a version mismatch is detected, with reference to the drawings. Will be explained. FIG. 9 is a flowchart showing a system operation flow in a conventional software version management method. The client periodically sets information required for the version check, and periodically requests the version management server to check the version of the software based on the set information (step S901). At this time,
The client transmits the version information of the client's software, the software version check request information, and the like to the version management server.

When the version management server receives a software version check request from the client (step S902), the version management server checks the software version information of the client based on the version information managed in the version management database, and checks the version of the software. The consistency is confirmed (step S903). The version management server responds by transmitting the version check result information to the client (step S90).
4).

When the client receives the version check result information transmitted from the version management server (step S905), the version of the client software is managed by the version management server based on the received version check result information. It is determined whether or not the version of the software is the same, that is, whether or not the software needs to be replaced (step S906).

If the client software version matches the version managed by the version control server and determines that the client software does not need to be replaced (step S9).
06), the process is terminated as it is. On the other hand, if the client determines that the version of the software of the client does not match the version managed by the version management server and that the replacement of the software of the client is necessary (step S906), the distribution of the software replacement file is performed by the software. A request is made to the distribution server (step S907).

The software distribution server sets schedule information according to the software distribution request from the client (step S908), and distributes the software replacement file to the distribution requesting client based on the set schedule information (step S908). S909).
At this time, information such as the software replacement time of the set schedule information is also transmitted to the client.

When the client receives the software replacement file distributed from the software distribution server (step S910), the client performs a software replacement process according to information such as the replacement time of the received schedule information (step S911).

In this conventional software version management system, a client periodically requests a version management server to check a software version,
If the version of the client does not match the version of the version management server, the client receives software for replacement processing from the software distribution server and performs software replacement processing.

[0015]

According to the former conventional software version control method described above, the client can periodically exchange software according to schedule information set on the distribution server side, and the software distribution from the distribution server can be performed. Failed or the client failed to replace the software,
The software can be replaced again by distributing the software from the distribution server, but if the client program is executed before the software distribution to the client is completed, the version match with the server program is guaranteed. Also, even when the version mismatch is detected, the replacement of the client software cannot be performed at the timing of starting the client program. For this reason, there is a problem that inconsistency due to version mismatch occurs at the time of software execution, and it is difficult to perform a stable system operation.

Further, in the former conventional version control method of software, when a network error or the like occurs, the software for replacement may not be obtained from the distribution server, and thus the software may not be replaced. There was a problem.

In the latter software version control method, the client periodically requests the version control server to check the software version, and when the client version does not match the version control server version, the client The software replacement process can be performed by receiving the software for the replacement process from the software distribution server. However, the software version of the client is regularly checked. Since the replacement is not always performed, it is difficult to always match the versions when executing the client software. For this reason, there is a problem that inconsistency due to version mismatch occurs at the time of software execution, and it is difficult to perform a stable system operation.

In the latter software version management method, a simple match search is also performed for the version check method, so that software whose compatibility is guaranteed between different versions is exchanged or a plurality of different versions are different. It was not able to handle the complicated relationship between the client application and the server.

Further, in the latter software version control system, when a network error or the like occurs, it may become impossible to obtain replacement software from the distribution server, so that the software may not be replaced. there were.

In view of the above, the present invention realizes a stable system operation by executing the software of a client without fail by matching the versions of the software of the client to be executed to prevent inconsistency due to version mismatch. It is another object of the present invention to provide a software version management method for a network system capable of reliably replacing software of a client whose version does not match even if a network error occurs.

[0021]

According to the first aspect of the present invention,
In a software version management method of a network system in which a client and a server are connected via a network, version information setting means for setting version information of a client program required for version checking, and transferring the set version information to the server. Version check request means for making a version check request of the client program by receiving the version information of the client program transferred from the client and receiving the version check request; Version information storage means for storing the version information of the program, and version information of the received client program and read from the version information storage means Version checking means for comparing the version information of the server program with the version information of the server program, and version checking result transferring means for transferring the version checking result to the client; Version mismatch checking means for determining whether the version of the client program does not match the version of the server program based on the version check result transferred from The program switching means for replacing the mismatched client program with the version of the server program and the program executing means for executing the replaced client program are clicked. It is characterized in that provided on Ianto.

According to a second aspect of the present invention, in the first aspect of the present invention, before the version check request is made, a timing designating means for designating a version check timing, and whether the designated version check timing has been reached. The client is provided with timing determination means for determining
If it is determined that the specified version check timing has been reached, the set version information of the client program is transferred to the server and a version check request is made.

The third aspect of the present invention is directed to the first and second aspects.
In the invention according to any one of the above, before performing the version check, a check information setting means for setting version check information used for the version check is provided in the server, and the version check means performs a version check based on the set version check information. A check is performed.

The invention described in claim 4 is the above-mentioned claim 1 or 2.
In the invention according to any one of the above, before performing the version check, a logic setting means for setting a check logic at the time of the version check is provided in the server, and the version check means performs the version check based on the set check logic. It is characterized by the following.

The fifth aspect of the present invention is directed to the first and second aspects.
In the invention according to any one of the above aspects, before performing a version check, a dependency setting unit that sets a dependency relationship between related software is provided in the server, and the version check unit sets a dependency between the set related software. It is characterized in that version checking is performed based on the relationship.

The invention according to claim 6 is the invention according to claims 1 to 5 above.
In the invention according to any one of the above, before replacing the client program, timing setting means for setting the timing of replacing the client program,
A timing determining means for determining whether the set client program replacement timing has been reached is provided in the client, and when the program replacement means determines that the set client program replacement timing has been reached, the client program is switched It is characterized by being replaced.

[0027] The invention of claim 7 provides the above-mentioned claims 1 to 5.
In the invention according to any one of the above, before the client program is replaced, a replacement condition setting means for setting a replacement condition of the client program is provided in the client, and the program replacement means is adapted to the set replacement condition of the client program. It is characterized in that the client program is replaced based on this.

[0028] The invention of claim 8 provides the above-mentioned claims 1-5.
In the invention according to any one of the above, before replacing the client program, a replacement target selection means for selecting a replacement target of the client program is provided in the client, the program replacement means, the replacement target of the selected client program It is characterized in that the client program is replaced based on this.

[0029]

Embodiments of the present invention will be described below with reference to the drawings. Embodiment 1 FIG. FIG. 1 is a block diagram showing a system configuration of a software version management system of a network system according to a first embodiment of the present invention. The machine configuration of the network system includes an arbitrary number of server machines 1 and client machines 2, and each computer is connected to a network via a communication medium 3 such as a LAN. The server machine 1 has a magnetic disk device 5 for storing a software package 4 as a set of application programs, and a magnetic disk device 7 for storing a version management database 6 for managing version information.

Next, the software configuration will be described. First, software related to version control on the server machine 1 includes a version management database 6 that records version information of each software on each network, and a version management server program 8 that receives a version check request from the client machine 2. , An action description file 9 that defines the version check method.

The software related to version management on the client machine 2 side is an action description file 1 that defines the operation of the software before and after a version check request to the version management server program 8.
1 and a version management client program 12 that issues a version check request.

The applications operating in the distributed system environment are an application client program 13 and an application server program 14. The activation of the client program 13 is performed through the version management client program 12. The software distribution and the software replacement after the version check are performed by the distribution program 16 of the server machine 1 sending the software package 4 to the distribution program 217 of the client machine 2.

Next, the structure of the action description file will be described. FIG. 2 is a diagram showing a configuration of the action description file 11 on the client machine 2 shown in FIG. The action description file 11 on the client machine 2 includes a description 211 relating to the timing at which a version check is performed, and software after the version check reveals that the versions differ between the client program and the server program. A description 212 regarding the replacement method is made. As the software replacement method, information such as when to replace software, which software to replace, and the like are defined.

Next, FIG. 3 shows the server machine 1 shown in FIG.
FIG. 3 is a diagram showing a configuration of an action description file 9 above.
The action description file 9 on the server machine 1 contains
A description 411 relating to a software version check method is made. “Product” is used for both the action description files 9 and 11 on the client side and the server side.
221, 321 and "Program" 222, 322
Tag name.

"Program" means an individual application program, and the corresponding program name is described following "Program". “Produc
t "means a group of programs, and the group of programs is usually set in business units,
The product name is described following "Product".
Within each "Product" tag, multiple "Pro"
A "gram" tag can be described.
This is to provide a unique version checking method for each application program included in “product”.

The configuration of the action description file 11 on the client machine 2 side includes a part 213 for specifying conditions before version check and a default operation for processing after mismatch detection for a corresponding product, and a program included in a certain product. Part 21 that describes the one not using the default coping method
4

The action description file 11 of the server machine 1 has a structure 311 for checking a version mismatch and a default operation relating to the subsequent operation of the relevant product, and a program 3 included in a certain product. And a part 312 for describing a device that does not use the default check method. The version management method according to the present invention is capable of managing products or programs.

FIG. 4 is a flowchart showing a system operation flow in the software version management system of the network system according to the first embodiment of the present invention. Version control server on server machine 1
The program 8 always operates to receive a version check request from the client machine 2 at an arbitrary timing, and waits for a version check request from the client machine 2. Client program 13
Is started by the version control client program 1.
2 is performed.

When the version management client program 12 of the client machine 2 is started, it first reads the action description file 11 (step S1). Version control client program 12
Reads the action description file 11 and determines that it is necessary to check the version for executing the application (step S2). If the version is required for checking the version number of the own program, the application name, the product name, etc. The information is set, the set version information is transferred to the version management server program 8 of the server machine 1, and a version check request is made (step S3).

When the version management server program 8 of the server machine 1 receives the version information transferred from the client machine 2 and receives a version check request (step S4), the action on the server machine 1 is performed. The description file 9 is read (step S5). And the version control server program 8
According to the check method described in the action description file 9, the client program 13 and the server
A version check process between the programs 14 is performed (step S6), and a version check result of whether or not the client program 13 and the server program 14 are the same version is used as the version management of the client machine 2 which has issued the version check. It returns to the client program 12 (step S7).

The version management client program 12 of the client machine 2 receives the version check result transferred from the server machine 1 (step S8), and informs that the versions of the client program and the server program match. When the notification of the version check result is received (step S9), the application client program 13 is subsequently started (step S10).

On the other hand, when the version management client program 12 of the client machine 2 determines that the versions of the client program 13 and the server program 14 do not match (step S9).
It is determined immediately whether the software replacement is to be performed (step S11). If the version management client program 12 of the client machine 2 determines that the software replacement is to be performed immediately (step S11), the version management client program 12 performs the software replacement according to the action description file 11 (step S12).
The application client program 13 is started (step S13).

When the version management client program 12 of the client machine 2 determines that the software is not to be replaced immediately (step S1).
1) It is determined whether to activate the client program 13 (step S14). client·
Version control client program 1 of machine 2
When it is determined that the client program 13 is to be activated (step S14), the client 2 activates the client program 13 (step S15), and instructs software replacement according to the action description file 11 (step S16). .

As described above, in the present embodiment, the version information of the client program 13 required for the version check is set on the client machine 2 side.
The set version information is transferred to the server machine 1 to make a version check request, and the server machine 1 receives the version information of the client program 13 transferred from the client machine 2 and receives the version check request. , Received client
After the version information of the program 13 and the version check of the server program 14 read from the version management database 6 are performed, the result of the version check is transferred to the client machine 2. Further, in the present embodiment, the client machine 2 determines whether the versions of the client program 13 and the server program 14 do not match based on the version check result transferred from the server machine 1. If it is determined that they do not match, the client program 1 whose version does not match
3 is replaced with the version of the server program 14, and the replaced client program 1
3 is executed. Therefore, when the client program 13 is executed, the version of the client program 13 to be executed can be surely matched with the version of the server program 14, so that inconsistency due to version mismatch does not occur when the client program 13 is executed. And stable system operation can be performed. Therefore, it is possible to always guarantee processing in an environment where the versions match.

In this embodiment, the client
Since the client program 13 whose version did not match is replaced on the machine 2 side, the client program 13 can be reliably replaced even if a network error occurs, compared to the case where the software is received from a conventional distribution server and replaced. .

Embodiment 2 This embodiment relates to claim 2
Only the characteristic portions according to the present invention will be described, and description will be made with reference to FIGS. In the first embodiment, a case has been described in which, after setting the version information of the client program 13 on the client machine 2 side, the set version information is immediately transferred to the server machine 1 to make a version check request. In the present embodiment, the version check timing is specified in the action description file 11 of the client machine 2, and when the version management client program 12 determines that the specified version check timing has been reached, the setting is performed. The version information of the client program 13 is transferred to the server machine 1 to make a version check request. In this case, since the version check can be performed at the designated timing, the version check can be performed efficiently. Hereinafter, a specific description will be given with reference to the drawings.

FIG. 5 is a diagram showing a description example regarding the version check timing setting in the action description file 11 shown in FIG. 1 according to the second embodiment of the present invention.
In the application execution environment, in order to reliably check whether or not the software version is the same between the client and the server, the version may be checked at the time of starting the application.

However, depending on the application, it is often unnecessary to always check the version. The present embodiment is characterized in that the timing at which the version check process is performed when the application is started is performed according to the action description file 11. In the action description file 11, one of the followings is specified: program startup (every) / first time of the day (1st) / check not performed (none).

For the application 2 (app. 2) of the action description file 11, the setting 502 is to execute a check every time the program is started. For the application 1 (app. 1), the first one in a day is set. This is a setting 501 for performing the check only the first time. The operation of the version management client program 13 in the state where the setting has been performed will be described with reference to the flowchart of FIG.

When the version management client program 12 of the client machine 2 starts, it reads the action description file 11 and obtains information on whether or not to execute a version check from the Check field. As a result, the version management client program 12, for example,
In the setting of app. When it is determined that the version check needs to be performed, such as when the server 2 is started (step S2), the version information of the set client program is stored in the version management server of the server machine 1.
The program is transferred to the program 8, and a version check request is made (step S3).

On the other hand, the version management client program 12 of the client machine 2 uses, for example, the app. If it is determined that it is not necessary to perform a version check as in the second and subsequent startups when the server 1 is started several times in succession (step S2), the version management server program 8 of the server machine 1 is notified. The client program 13 is started without issuing a version check request (step S10).

As described above, in this embodiment, the version check timing is specified in the action description file 11 of the client machine 1 and the specified version check timing is reached by the version management client program 12. If it is determined that the version information of the set client program is transferred to the server machine 1 and a version check request is made, the version check can be performed at the designated timing.
Version checking can be performed efficiently. For example, it is not necessary to perform a version check or download software every time the application is started. For this reason, it is not necessary to perform a version check that is unnecessary for the operation of the system, so that it is possible to prevent the performance from being degraded and the load from being carelessly increased.

Embodiment 3 This embodiment relates to claim 3
Only the features according to the present invention will be described, and will be described with reference to FIGS. In the first embodiment, when a version check request is received from the client machine 2 by the version management server program 8, the received version information of the client program and the version information of the server program read from the version management database 6 are transmitted. In the present embodiment, the version check information used for the version check is set in the action description file 9 of the server machine 1 before performing the version check. The action description file 9 is generated by the version management server program 8.
The system is configured to perform a version check based on the version check information read from (steps S5 and S6). In this case, since the version check can be performed based on the set version check information, a flexible version interpretation method suitable for the software can be designated. Hereinafter, a specific description will be given with reference to the drawings.

FIG. 6 is a diagram showing the contents of the action description file 9 shown in FIG. 1 according to the third embodiment of the present invention.
When checking the software version, the information used as a reference for the check is large. The information used as the check criterion includes a file creation date (“date”),
A file name (for example, in the case of a product name including a version), version information (“revision”) embedded in a file or a module, and registration contents in the version management database 6 (“config”
g "), for example, when a product or application group is collectively version-managed).

However, although there is a lot of information serving as a reference for the version check, it is difficult to perform a version check by combining them. In this embodiment,
“Information” fields 611 and 616
File creation date (“date”) / version information embedded in the software (“revision”) / contents registered in version management database 6 (“confi
g ”), the information used for the version check is set.

For example, in FIG. 6, regarding the product PRO1, "con" is added to the Information field.
Since the “fig” is described, the version check based on the version management database 6 has priority. The version management server program 8
Is based on the information described in this Information
Perform version comparison. In the case of the example of FIG. 6, for example, the client program 13 and the server program 14
Version included in the module (revisi
Even if there is a difference in on), if there is no difference in the registered contents of the version management database 6, it is determined that there is no difference between the client program 13 and the server program 14.

As described above, in this embodiment, before performing the version check, the version check information used for the version check is set in the action description file 9 of the server machine 1, and the version management server program 8 Since the version check is performed based on the set version check information, the version check can be performed based on the set version check information. Therefore, a flexible version interpretation method suitable for the software is specified. be able to. For this reason, different version information can be dealt with by software, and efficient system operation can be realized.

Embodiment 4 This embodiment relates to claim 4
Only the features according to the present invention will be described, and will be described with reference to FIGS. In the first embodiment, when a version check request is received from the client machine 2 by the version management server program 8, the received version information of the client program and the version information of the server program read from the version management database 6 are transmitted. Has been described, the version check is performed by comparing the action description file 9 with the action description file 9 before the version check is performed.
The check logic information at the time of version check is set in advance, and the version management server program 8 performs a version check based on the check logic information read from the action description file 9 (steps S5 and S6). In this case, since the version check can be performed based on the set check logic information, a flexible version interpretation method suitable for software can be designated.

This embodiment relates to a version check algorithm. In an actual system, it is desirable that the versions of the client / server type applications distributed in the network environment be the same for the same product. However, in an actual system environment, there are environments in which software replacement cannot be easily performed, such as in a case where a server machine is continuously operated for 24 hours. In such an environment, if the version of the application between the client and the server is different, it is known that there is no perfect match of the versions in order to minimize software replacement, but there is no operational problem. If so, it is desirable to regard it as a version match.

In the present embodiment, the “Algorithm” fields 611 and 616 are provided in the action description file 9 of the server machine 1, and the versions of the client program 13 and the server program 14 must completely match ( "Complete") / If the version is within a specific range, it is considered that the version matches ("range").
Concept of version check (exact match or partial match)
Make settings related to

As described above, in the present embodiment, the version management server program 8 is configured to perform a version check based on the check logic information set in the action description file 9,
A flexible version interpretation method can be specified according to the software. Therefore, it is possible to cope with a complicated environment, such as an environment in which different versions of software are mixed, which cannot be coped with only by simple version comparison, by customizing the version check algorithm.

Embodiment 5 This embodiment relates to claim 5
Only the features according to the present invention will be described, and will be described with reference to FIGS. In the first embodiment, when a version check request is received from the client machine 2 by the version management server program 8, the received version information of the client program 13 and the version of the server program 14 read from the version management database 6 are received. Although the case where the version check is performed by comparing with the information has been described, in the present embodiment, before performing the version check, the dependency information between the softwares related to the action description file 9 is set, and the version management is performed. The server program 8 performs a version check based on the dependency information between related software read from the action description file 9 (steps S5 and S6). In this case, since the version check can be performed based on the set dependency information between the related software, the version check of all the software having the dependency can be collectively performed.

The present embodiment relates to a version checking method in which software dependencies are considered. In a distributed system environment, there are many applications that depend on each other. For example, product 1
Are included in the client program client1 and the server program ser
ver2 exists, and as an application included in the product 2, the client program client
2 and the server program server2 exist.

Here, when only the application program included in the product 2 is distributed in the distributed system environment, the client program client 1 and the server program serv included in the product 1
Although the versions between er1 and er1 match, there may be a problem that the client program client1 cannot be executed or an error occurs in the execution result. This is Product 1
This occurs because the software in the product uses the function in the product 2.

In the present embodiment, as shown in FIG. 6, the field "depende
ncy "613, 618, and by describing the dependency information between the product PRO1 and the product PRO2, when issuing a request for SERVER1 in the product PRO1, when checking the version at the time of activation, not only the product PRO1 but also the product PRO1 is checked. Product PRO
A version match is checked by performing comparison processing with the version in 2.

As described above, in the present embodiment, the version management server program 8 is configured to perform a version check based on the dependency information between related software set in the action description file 9. Since mutual dependency can be specified for software having a dependency over management units, efficient system operation can be realized. In the present embodiment, when one piece of software is replaced, software that is dependent on the software can be replaced, so that the burden on the system administrator can be reduced.

Embodiment 6 FIG. This embodiment relates to claim 6
Only the characteristic portions according to the present invention will be described and will be described with reference to FIGS. In the first embodiment, when the version management client program 12 determines that the software is to be replaced immediately when the versions of the client program 13 and the server program 14 do not match (step S9) (step S11). ), The case of exchanging software has been described. In the present embodiment, the action description file 11 is replaced before the client program 13 is exchanged.
The timing for replacing the client program 13 is set in advance, and when the replacement timing of the set client program 13 is reached by the version management client program 12 (step S1).
1) The client program 13 is configured to be replaced. In this case, when the set replacement timing of the client program 13 is reached, the client program 13 can be replaced.
Software replacement according to the system operation can be performed.

The present embodiment relates to a method of replacing software when a difference occurs between the version information of the client program 13 and the version information of the server program 14 as a result of the version check. When the version check reveals that the version is not the correct version for operating the application in the distributed system environment, it is usually desirable to replace the application. Here, this application replacement work is particularly difficult when the number of client machines 2 is large or the system is operating, and the version inconsistency is resolved by a software replacement method according to the system environment. It is desirable to do.

The present embodiment relates to a method for replacing software whose version does not match when the version check in accordance with the description content of the action description file 11 fails. The description of the action description file 11 is as follows:
This corresponds to the portion 212 in FIG. FIG. 7 shows the 212 shown in FIG.
It is a figure which shows the specific description example of a part. In the present embodiment, when it is determined that software replacement is necessary as a result of the version check, means for designating the timing at which the actual program replacement work is performed is provided. As for the replacement timing, immediately after the mismatch is detected by the version check (“now”), the application operates even after the mismatch is detected, immediately after the application itself ends (“after”), the replacement is performed by specifying the time (“time”, the business end time is replaced) Etc.) can be set. “Now”, “after”, “ti”
Any information of "me" is described in the "When" field of the action description file 11 of the server machine 1.

The program app-a in the description example of the action description file 11 in FIG. 7 is a setting for immediately performing the replacement 711 without performing the actual processing of the application when the version mismatch is detected. -B is a setting for performing the exchange (717) of the midnight hours (outside of business hours). The operation will be described with reference to FIGS.

When the version management client program 12 of the client machine 2 is activated and detects a mismatch of the version check, the version control client program 12 determines the replacement condition in the processing of step 9 in FIG. Then, the version management client program 12 writes the product PR in FIG.
If it is necessary to immediately replace the server with the OX (step S11), the distribution program is notified of necessary software conditions, and the client program 1
3 is replaced (step S1).
2).

The version management client program 12 of the client machine 2 confirms the replacement environment and starts the application of the replaced client program 13 (step S13). On the other hand, the version control client program 12
When the replacement of business hours belonging to the product PRO-Y of FIG. 7 is specified as the description of the action description file 11, the version management client program 12 executes the application distribution processing necessary for the schedule function provided by the system. Is registered (step 16). The registered contents include a distribution time and designation of a product to be distributed.

As described above, in the present embodiment, before replacing the client program 13, the timing for replacing the client program 13 is set in the action description file 11, and the timing is set by the version management client program 12. When the replacement timing of the client program 13 is reached (step S11), the client program 13 is replaced. When the replacement timing of the set client program 13 is reached,
Since the client program 13 can be replaced, software replacement according to the system operation can be performed.

In the present embodiment, for example, when the software is to be replaced immediately but cannot be replaced, it is possible to specify in advance that the software should be replaced at night or replaced after a series of operations are completed. For this reason,
Since the software replacement schedule can be flexibly set according to the system requirements, efficient system operation can be realized.

Embodiment 7 This embodiment relates to claim 7
Only the characteristic portions according to the present invention will be described and will be described with reference to FIGS. In the first embodiment, when the version management client program 12 determines that the software is to be replaced immediately when the versions of the client program 13 and the server program 14 do not match (step S9) (step S11). Although the case of exchanging software has been described, in the present embodiment, before exchanging the client program 13, the conditions for exchanging the client program 13 are set in the action description file 11 of the client 2. The configuration is such that the client program 13 is replaced by the version management client program 12 based on the set replacement condition of the client program 13. In this case, the client programs 13 can be exchanged based on the set exchange conditions of the client programs 13. Therefore, for example, version checks are frequently performed for those having a high degree of importance. Software replacement can be realized.

In the present embodiment, when it is determined that the client program 13 needs to be replaced as a result of the version check, the client program 13 set in advance is set.
The exchange is performed according to the exchange condition of the program 13. Usually, when replacing software, the replacement cannot be performed while the software to be replaced is operating. Therefore, when the business is being performed in the actual system, it is sometimes difficult to perform the replacement work in terms of time. Emergency replacement is often required, regardless of whether work is in progress or not. It applies, for example, to frequently used software, specific terminals performing important tasks, and very important specific tasks.

In this embodiment, the action description file 11 of the client machine 2 contains “Whether”
Fields 712 and 717 are provided, and when a version mismatch notification is received from a version check response from the version control server program 8 of the server machine 1, "Whe" of the action description file 11 is received.
depending on the contents of the "other" field.
Version control client program 1 of machine 2
2 carries out a replacement process of the client program 12 which did not match (steps S11, S12). For example, in FIG. 7, for the product PRO-X, information on the number of times of version mismatch (times) is described, and when the version difference is detected N times or more for the same application, the software of the client program 13 is replaced. Is carried out.

As described above, in the present embodiment, before replacing the client program 13, the conditions for replacing the client program 13 are set in the action description file 11 of the client 2, and the version management client program 12 Since the configuration is such that the client program 13 is replaced based on the set replacement condition of the client program 13, the client program 13 can be replaced based on the set replacement condition of the client program 13. For this reason, for example, it is possible to implement flexible software replacement in accordance with the environment and business contents, such as frequently checking the version of a software having a high importance.

Embodiment 8 FIG. This embodiment relates to claim 8
Only the characteristic portions according to the present invention will be described and will be described with reference to FIGS. In the first embodiment, when the version management client program 12 determines that the software is to be replaced immediately when the versions of the client program 13 and the server program 14 do not match (step S9) (step S11). ), The case of exchanging software (step S12) has been described. However, in the present embodiment, as a result of the version check, the client program 13
When it is determined that the replacement is necessary, means for selecting the client program 13 to be replaced is provided. When a difference in the version of the client program 13 is detected in each client machine 2 in the distributed system environment and it is determined that the client program 13 needs to be replaced, the client program 1
In order to minimize the effect on the running business due to the replacement work in Step 3, all the software groups that constitute a specific business are not replaced collectively, but only the minimum necessary application programs. It is desirable to replace them.

In the present embodiment, “What” fields 713 and 718 are provided in the action description file 11, and when a product mismatch is detected between machines, the “What” field is described from among the corresponding products. Replace only modules (executable files). For example, in FIG.
Assuming that the OX is composed of 100 modules, and it is necessary to replace the client program 13 due to version mismatch, instead of replacing all the 100 modules, the description of 3 in the “What” field Module “prog_1”, “pr
og_2 ”and“ prog — 3 ”are replaced.

As described above, in this embodiment, before replacing the client program 13, the condition for selecting the client program 13 to be replaced is set in the action description file 11 of the client machine 2, and the version is set. The management client program 12 is configured to replace the client program 13 based on the set replacement target client program 13. In this case, the client programs 13 can be replaced based on the set client program 13 to be replaced, so that the related client programs 13 can be replaced in units of modules rather than all at once. . Therefore, it is possible to replace modules in accordance with the system and business requirements,
It is possible to realize an efficient system operation in which unnecessary modules are not replaced as much as possible.

[0082]

According to the first aspect of the present invention, the client side required for the version check on the client side.
Set the version information of the program, transfer the set version information to the server and make a version check request. On the server side, receive the version information of the client program transferred from the client and accept and receive the version check request. After checking the version information of the client program and the version of the server program read from the version management database, the version check result is transferred to the client machine.
On the client side, based on the version check result transferred from the server, determine whether the versions of the client program and server program do not match, and if they determine that they do not match, the versions do not match Since the client program is replaced so as to match the version of the server program and the replaced client program is configured to be executed, when the client program is executed, the version of the client program to be executed is changed to the server program.
Since it can be surely matched with the program version, it is possible to prevent inconsistency due to version mismatch when executing the client program,
A stable system operation can be performed. Therefore,
Processing can always be guaranteed in an environment where the versions match.

Further, according to the first aspect of the present invention, since the client program whose version does not match is replaced on the client side, a network error occurs more than in the case where the software is replaced by receiving the software from the conventional distribution server. However, the client program can be surely replaced.

According to the second aspect of the invention, the version check timing is designated to the client,
If it is determined that the specified version check timing has been reached, the version information of the set client program is transferred to the server and a version check request is made, so that the version check can be performed at the specified timing. As a result, version checking can be performed efficiently. For example, it is not necessary to perform a version check or download software every time the application is started. For this reason, it is not necessary to perform a version check that is unnecessary for the operation of the system, so that it is possible to prevent the performance from being degraded and the load from being carelessly increased.

According to the third aspect of the present invention, before performing a version check, version check information used for the version check is set in the server, and the version check is performed based on the set version check information. With this configuration, a version check can be performed based on the set version check information, so that a flexible version interpretation method suitable for software can be specified. For this reason, different version information can be dealt with by software, and efficient system operation can be realized.

According to the fourth aspect of the present invention, by performing a version check based on the check logic information set in the server, it is possible to specify a flexible version interpretation method suitable for software. For this reason, even in an environment where software of different versions coexist, such as an environment where simple version comparison is not enough, version checking and
This can be handled by customizing the algorithm.

According to the fifth aspect of the present invention, the configuration is such that the version check is performed based on the dependency information between the related software set in the server. On the other hand, you can specify mutual dependencies,
Efficient system operation can be realized. For example, when one piece of software is replaced, software that is dependent on the software can be replaced, so that the burden on the system administrator can be reduced.

According to the sixth aspect of the present invention, the timing for replacing the client program is set in the client before the replacement of the client program. Because the program was configured to be replaced, the client
When the program replacement timing is reached, the client program can be replaced, so that software replacement can be performed in accordance with system operation.

According to the seventh aspect of the present invention, before replacing the client program, the client program replacement conditions are set in the client,
Since the configuration is such that the client programs are exchanged based on the set exchange conditions of the client programs, the client programs can be exchanged based on the set exchange conditions of the client programs. For this reason, for example, it is possible to implement flexible software replacement in accordance with the environment and business contents, such as frequently checking the version of a software having a high importance.

According to the eighth aspect of the present invention, a condition for selecting a client program to be replaced is set in the client before replacing the client program, and the set client program to be replaced is set.
Since the client program is configured to be replaced based on the program, the client program can be replaced based on the set client program to be replaced.
Instead of replacing programs in a lump, the programs can be replaced in module units. Therefore, it is possible to perform replacement in units of modules according to the system and business requirements, so that efficient system operation in which unnecessary replacement of modules is minimized can be realized.

[Brief description of the drawings]

FIG. 1 is a block diagram showing a system configuration of a software version management system of a network system according to a first embodiment of the present invention.

FIG. 2 is a diagram showing a configuration of an action description file on the client machine shown in FIG.

FIG. 3 is a diagram showing a configuration of an action description file on the server machine shown in FIG.

FIG. 4 is a flowchart showing a system operation flow in the software version management method of the network system according to the first embodiment of the present invention.

FIG. 5 is a diagram showing a description example regarding a version check timing setting in an action description file according to the second embodiment of the present invention.

FIG. 6 is a diagram showing contents of an action description file according to the third embodiment of the present invention.

FIG. 7 is a diagram showing contents of an action description file according to the sixth embodiment of the present invention.

FIG. 8 is a flowchart showing a system operation flow in a conventional software version management method.

FIG. 9 is a flowchart showing a system operation flow in a conventional software version management method.

[Explanation of symbols]

1 server machine, 2 client machines, 3
Communication media, 4 software package, 5, 7 magnetic disk unit, 6 version control database, 8
Version control server program, 9, 11 action description file, 12 version control client program, 13 client program, 1
4 Server program, 16, 17 distribution program.

Claims (8)

[Claims] In a software version management system of a network system in which a client and a server are connected via a network, version information setting means for setting version information of a client program required for version check, and the set version information Requesting means for transferring a client program to the server and requesting a version check of the client program provided in the client, receiving the version information of the client program transferred from the client and receiving the version check request Means,
Comparing the version information of the server program with the version information of the received client program and the version information of the server program read from the version information storage means, and comparing the version information of the client program with the version information of the server program. Version checking means for performing a version check on the server and version check result transferring means for transferring the result of the version check to the client, wherein the version of the client program is determined based on the version check result transferred from the server.
Version mismatch determination means for determining whether the version does not match the version of the program, and, when determining that the version does not match, replaces the client program whose version does not match with the version of the server program. A software version management system for a network system, wherein a client is provided with program replacement means and program execution means for executing the replaced client program. 2. Before making a version check request,
A timing designating means for designating the timing of the version check and a timing judging means for judging whether or not the timing of the designated version check has been provided in the client, and the version check requesting means has reached the designated timing of the version check. 2. The software version management system for a network system according to claim 1, wherein when it is determined that the version information of the set client program is transferred to the server, a version check request is made. 3. A server having a check information setting means for setting version check information to be used for the version check before performing the version check, wherein the version check means performs a version check based on the set version check information. The software version management method for a network system according to any one of claims 1 and 2, wherein: 4. A server which is provided with logic setting means for setting a check logic at the time of version check before performing a version check, wherein the version check means performs a version check based on the set check logic. 4. The software version management system for a network system according to claim 1, wherein: 5. The server according to claim 1, further comprising a dependency setting unit for setting a dependency between related software before performing the version check.
4. The software version management method for a network system according to claim 1, wherein a version check is performed based on a set dependency between related software. 6. A client includes: timing setting means for setting a timing for replacing a client program before replacing the client program; and timing determining means for determining whether or not the timing for replacing the set client program has been reached. , The program replacement means includes a client
6. The software version management method for a network system according to claim 1, wherein a client program is replaced when it is determined that a program replacement timing has been reached. 7. Before replacing a client program, a replacement condition setting means for setting a replacement condition of the client program is provided in the client, and the program replacement means is configured to replace the client program based on the set replacement condition of the client program. 6. The software version management method for a network system according to claim 1, wherein the programs are exchanged. 8. Before replacing the client program, the client is provided with replacement target selection means for selecting a client program to be replaced, and the program replacement means replaces the selected client program to be replaced. The software version management method for a network system according to claim 1.