WO2013171879A1 - ジョブ実行システム、ジョブ実行プログラム、ジョブ実行方法 - Google Patents

ジョブ実行システム、ジョブ実行プログラム、ジョブ実行方法 Download PDF

Info

Publication number
WO2013171879A1
WO2013171879A1 PCT/JP2012/062644 JP2012062644W WO2013171879A1 WO 2013171879 A1 WO2013171879 A1 WO 2013171879A1 JP 2012062644 W JP2012062644 W JP 2012062644W WO 2013171879 A1 WO2013171879 A1 WO 2013171879A1
Authority
WO
WIPO (PCT)
Prior art keywords
job
approval
group
unit
computer
Prior art date
Application number
PCT/JP2012/062644
Other languages
English (en)
French (fr)
Inventor
諒 花房
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to PCT/JP2012/062644 priority Critical patent/WO2013171879A1/ja
Priority to US14/398,999 priority patent/US9836711B2/en
Priority to JP2014515427A priority patent/JP5965999B2/ja
Publication of WO2013171879A1 publication Critical patent/WO2013171879A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G06Q10/06316—Sequencing of tasks or work
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals

Definitions

  • the present invention relates to a technique for executing a calculation job using computer resources.
  • distributed processing such as grid computing is attracting attention.
  • One application example of distributed processing is calculation of total sales.
  • the total sales amount is obtained by adding all the amounts of each transaction registered as transaction data. If the number of transactions is small, processing can be completed in a short time even with one computer, but if the number of transactions is large, it takes a long time to calculate the total sales, so transaction data is stored on multiple computers. By dividing and distributing and executing the calculation in a distributed manner on each computer, the calculation result can be obtained in a short time.
  • Patent Document 1 describes a technology related to distributed computing technology.
  • the job ticket (61) can be stored, the job ticket provides a reference to the job, the job includes one or more resources, and the processor (80) A job ticket service (60) for accessing the job ticket for execution, an authentication mechanism (94) capable of verifying the identity of the processor attempting to access the job ticket, and the authentication An authority that can receive the identification from a mechanism and provide the processor with authority to access the job ticket, wherein the processor accesses the one or more resources when accessing the job ticket; Providing mechanism (92). Is disclosed (see summary).
  • FIG. 1 is a configuration diagram of a job execution system 1000 according to Embodiment 1.
  • FIG. It is a figure which shows the structure and data example of approval request DB240. It is a figure which shows the structure and data example of approval result DB250. It is a figure which shows the structure and data example of resource information DB410. It is a figure which shows the structure and data example of division
  • FIG. 11 is a diagram showing an operation flow of the job execution system 1000 when the group management unit 140 adopts the group structure shown in FIGS. 8 to 10.
  • FIG. 11 is a diagram showing an operation flow of the job execution system 1000 when the group management unit 140 adopts the group structure shown in FIGS. 8 to 10.
  • the computer node 100 is a computer that executes arithmetic jobs, and a plurality of computers are provided.
  • the user submits a job of a higher-level application (for example, a sales aggregation job of an accounting application) to the computer node 100.
  • the computer node 100 to which the application job is input divides the application job into a plurality of calculation jobs (for example, a total job for each store) and distributes it to other computer nodes 100.
  • Each computer node 100 executes the received calculation job.
  • the plurality of computer nodes 100 share and execute application jobs.
  • the computer node 100 includes a job reception unit 110, a resource operation detection unit 120, an approval control unit 130, a group management unit 140, a job control unit 150, and a resource division unit 160.
  • the group management unit 140 groups a plurality of operation jobs and assigns the same group ID.
  • the operation jobs received by each computer node 100 inherit the group ID of the group from the operation job before distribution. A method of sharing the group ID among a plurality of calculation jobs will be described later.
  • the job control unit 150 generates and executes individual calculation jobs based on the application job received by the job reception unit 110, or distributes and executes calculation jobs to other computer nodes 100 and receives the results.
  • the job control unit 150 may receive a calculation job from another computer node 100. In this case, the calculation job is executed. A method by which the job control unit 150 generates individual calculation jobs will be described later.
  • the resource dividing unit 160 distributes a computer resource to be accessed by the other computer node 100 to execute the calculation job to the other computer node 100.
  • the resource dividing unit 160 divides a portion of the data file that needs to be accessed by another computer node 100 and distributes the divided data file to the other computer node 100. To do.
  • the request reception unit 210 receives the approval request issued by the approval control unit 130, and searches the approval result DB 250 to determine whether an answer (approval result) to the approval request is input. When the approval result is not found, the request reception unit 210 registers the approval request in the approval request DB 240. When the approval result is found, the request reception unit 210 returns the approval result to the approval control unit 130.
  • the approval unit 220 transmits a list of approval requests registered in the approval request DB 240 to the approver terminal 300 in response to a request from the approver terminal 300. Also, the approval result for the approval request is received from the approver terminal 300 and registered in the approval request DB 240. The approval unit 220 aggregates the answers registered in the approval request DB 240, determines a final approval result for the group, and stores the result in the approval result DB 250. The final approval result will be described again in FIG. All computing jobs belonging to the approved group are allowed to access computer resources used in the course of the job.
  • the priority determination unit 230 determines the priority of the approval request registered in the approval request DB 240. This priority is an index for determining in which order approval requests should be processed.
  • the approver can execute the approval process with reference to the priority. For example, when the approval level needs to be obtained from a plurality of approvers, the priority can be increased as the approval request has a larger number of approvers requiring approval.
  • the approver terminal 300 is a terminal for the approver to input an answer to the approval request.
  • the approver terminal 300 inquires of the approval server 200 whether there is an unanswered approval request.
  • the approver terminal 300 displays a list of unanswered approval requests on a screen described with reference to FIG.
  • the approver enters the answer on the screen.
  • the approval server 200 receives the response and stores it in the approval request DB 240.
  • Each functional unit included in each computer shown in FIG. 1 can be configured as hardware such as a circuit device that realizes these functions, or a program that implements the same function and a CPU (Central Processing Unit) that executes the program. ) Or the like.
  • a CPU Central Processing Unit
  • FIG. 2 is a diagram showing a configuration of the approval request DB 240 and data examples.
  • the approval request DB 240 is a database that holds unanswered approval requests, and can be configured by storing a data file holding data in a storage device such as an HDD (Hard Disk Drive).
  • FIG. 2 illustrates the configuration of the table format, other formats may be used. Since the method and data format for configuring the database are the same for other databases, the description of the database described below is omitted.
  • the group ID field 241 holds a group ID created by the group management unit 140.
  • the representative job ID field 242 holds an ID of a calculation job representing the group designated by the group ID field 241.
  • the resource ID field 243 holds the ID of a computer resource that needs to be approved when accessing it among computer resources that need to be accessed in order to execute an arithmetic job included in the group specified by the group ID field 241.
  • the request source field 244 holds information for identifying the computer node 100 that issued the approval request. Here, an IP address and a port number are illustrated.
  • the approver ID field 245 holds the ID of the approver who should reply to the approval request.
  • the pre-division resource ID field 247 holds the ID of the pre-division resource when the computer resource designated by the resource ID field 243 is created by the resource division unit 160. Since this field can also be acquired from the division information DB 420 described later, it is not always necessary to provide this field in the approval request DB 240.
  • the worker ID field 248 is an ID of a user who has input an application job that is a source for generating a calculation job included in each group.
  • the application job ID field 249 is an ID of the application job.
  • (Approval request list creation process 2) An approval request that belongs to the same group as the approval request for which an answer has already been input to the response field 246 and that has the same resource to be approved (the resource ID field 243 if not divided, and the resource ID 247 before division if divided) For, the approver should enter the same approval result. Therefore, the approval unit 220 excludes those corresponding to the above from the approval request list returned to the approver terminal 300.
  • the group ID field 251 holds the ID of the group for which the approval unit 220 has finally determined the approval result. This field corresponds to the group ID field 241.
  • the resource ID field 252 holds the ID of a computer resource that is accessed by an operation job included in the group specified by the group ID field 251. This field corresponds to the resource ID field 243 if not divided, and corresponds to the resource ID 247 before division if divided.
  • the approval result 253 holds the final approval result for the group specified by the group ID field 251.
  • FIG. 4 is a diagram illustrating a configuration of the resource information DB 410 and a data example.
  • the resource information DB 410 is a database for enumerating computer resources that need to be approved for access and specifying the approver.
  • the resource information DB 410 has a resource ID field 411 and an approver ID field 412.
  • the resource ID field 411 holds the ID of a computer resource that requires approval when accessing.
  • the approver ID field 412 holds the ID of the approver who approves access to the computer resource specified by the resource ID field 411.
  • the approval control unit 130 of the computer node 100 issues an approval request to the approval server 200.
  • the approval unit 220 specifies an approver who should reply to the approval request.
  • the group ID field 421 is an ID of a group to which an operation job that uses computer resources belongs.
  • the post-division resource ID field 422 is an ID generated by the resource division unit 160 among the computer resources used by the operation job belonging to the group specified by the group ID field.
  • the pre-division resource ID field 423 is an ID of the computer resource from which the resource division unit 160 generates the computer resource specified by the post-division resource ID 422.
  • the resource dividing unit 160 registers the correspondence relationship before and after the division in the division information DB 420 when dividing the computer resource and distributing it to other computer nodes 100.
  • the pre-division resource ID field 247 of the approval request DB 240 can be derived from information registered in the division information DB 420.
  • the approver needs to determine whether or not the computer resource after the division is accessible.
  • the computer resource ID after the division is not necessarily the same as the computer resource ID before the division, and it may not be possible to determine whether access is possible only by the computer resource ID.
  • the correspondence relationship between the computer resource IDs before and after the division may be read from the division information DB 420, replaced with the computer resource ID before the division, and presented to the approver. This is because the security level required for the computer resources before and after the division is considered to be approximately the same, so if it is possible to determine whether or not the computer resources before the division can be accessed, it is sufficient to perform the approval work.
  • FIG. 6 is a screen image of the approval request list screen 310 displayed by the approver terminal 300.
  • the approval request list screen 310 is a screen for displaying a list of approval requests registered in the approval request DB 240, and includes an approval request table 311, an update button 312, an approval button 313, and a reject button 314.
  • the approver causes the approval request list screen 310 to be displayed on the display of the approver terminal 300 when performing the approval work.
  • the ID of the approver is designated.
  • the login ID of the approver may be used.
  • the approver terminal 300 inquires the approval server 200 for an unanswered approval request using the approver ID as a key.
  • the approval unit 220 creates an approval request list related to the approver from the approval request DB 240 by the method described in the approval request list creation processes 1 to 3, and transmits the approval request list to the approver terminal 300.
  • the approver terminal 300 displays the approval request list on the approval request table 311 on the screen. It is not always necessary to display all the fields included in the approval request DB 240 on the screen, and only information necessary for the approver to perform the approval work may be displayed. About a priority, the value determined by the priority determination part 230 with the above-mentioned method should be notified to the approver terminal 300, and this may be displayed.
  • the approver inputs an answer to the approval request by pressing the approval button 313 or the reject button 314.
  • the update button 312 is pressed.
  • the approval server 200 receives the response input by the approver from the approver terminal 300 and registers it in the response field 246 of the approval request DB 240. The subsequent processing is as described above.
  • FIG. 7 is a diagram for explaining the approval of the job group created by the group management unit 140 and the entire job group. Here, the flow of processing from when the user submits an application job to when each computer node issues an approval request is shown. Hereinafter, each step shown in FIG. 7 will be described.
  • the job control unit 150 replaces the sales total job submitted by the user with a calculation job executed by the computer. If it describes in connection with the example of a sales totaling job, it will be thought that the calculation job etc. which add the sales of each store will be produced
  • Figure 7 Step 3: Request for resource division approval
  • the job control unit 150 divides the arithmetic job generated in step 2 and assigns it to another computer node 100.
  • the group management unit 140 groups the operation jobs before and after the division, assigns the same group ID, and delivers them as parameters to each operation job.
  • which group each calculation job belongs to may be managed on an appropriate database.
  • the data file in which the sales results are recorded is divided for each store and distributed to the computer nodes 100 that are responsible for the aggregation of the store.
  • the resource operation detection unit 120 detects that fact.
  • the approval control unit 130 issues an approval request for the access to the approval server 200.
  • the approver answers the approval request using the approver terminal 300.
  • the approval unit 220 registers the final approval result for the group in the approval result DB 250.
  • Step 7 Step 4: Distribute split jobs
  • the job control unit 150 distributes the divided operation job to each computer node 100.
  • the resource dividing unit 160 distributes the divided computer resources to the corresponding computer nodes 100. At this time, the correspondence relationship between the group ID to which the corresponding operation job belongs and the computer resource ID before and after the division is registered in the division information DB 420.
  • the approval unit 220 searches the approval result DB 250 using the group ID related to the approval request as a key. In the processing flow shown in FIG. 7, since the approval result has already been registered for the group in step 3, the approval unit 220 uses this to reply to the approval request. This eliminates the need for the approver to input an answer for each approval request generated from the post-division job, thereby reducing the burden on the approver.
  • the job control unit 150 of each computer node 100 obtains an approval result indicating that the group is permitted to access the computer resource, the job control unit 150 executes each operation job and obtains an approval result indicating that the access is not permitted. If this happens, cancel the job execution.
  • the group management unit 140 has been described as grouping a plurality of calculation jobs. At this time, the frequency of approval requests and the approval target differ depending on the range in which the operation jobs are grouped.
  • various configuration examples will be described regarding the range of operation jobs to be grouped. The detailed operation of the job execution system 1000 will also be described. Other configurations are the same as those of the first embodiment.
  • FIG. 8 is a diagram illustrating an example in which a divided job generated by duplicating a calculation job and a calculation job derived from the division job belong to the same group.
  • the job duplicating unit 151 creates a divided operation job by duplicating the representative operation job generated from the application job. Furthermore, there may be a derivative job in charge of partial processing in the divided operation job.
  • the approval result for the representative calculation job is not applied to the divided calculation job. This is effective when it is not desired to pass the approval result for the representative calculation job to the divided calculation job.
  • the group to which the job generated by duplication belongs is a newly created group if the duplication source job does not belong, and becomes the group if the duplication source job belongs to the group.
  • the group to which a job generated by a method other than duplication belongs is the same as the job of the generation source.
  • FIG. 9 is a diagram illustrating an example in which a divided job generated by duplicating a calculation job and a calculation job derived from the division job belong to different groups.
  • the approver does not know the content of the derived job derived from the divided operation job, even when approving the approval request generated from the divided operation job, the approval request generated from the derived job is not necessarily approved. In such a case, it is desirable that the divided operation job and the derived operation job belong to different groups.
  • the group to which the job generated by duplication belongs is the group created by the duplication source job. Jobs created by methods other than duplication are unaffiliated.
  • FIG. 10 is a diagram showing an example in which operation jobs related to before and after the division belong to the same group. This corresponds to the group structure described in the first embodiment.
  • the group structure shown in FIG. 10 is effective when it is desired to approve calculation jobs before and after the division. This is also effective when it is desired that the approval result for the calculation job before the division be inherited by the calculation job after the division.
  • the group to which the job generated by duplication belongs is the same as the duplication source job.
  • a group to which a job generated by a method other than duplication belongs is the same as the job of the generation source.
  • FIG. 11 is a diagram illustrating an example in which an application job and an operation job generated from the job belong to the same group.
  • the approver wants to perform approval from the application job stage, the group structure shown in FIG. 11 is effective.
  • the group to which the job generated by duplication belongs is the same as the duplication source job.
  • a group to which a job generated by a method other than duplication belongs is the same as the job of the generation source.
  • FIG. 12 is a diagram showing an operation flow of the job execution system 1000 when the group management unit 140 adopts the group structure shown in FIGS. 8 to 10.
  • the group management unit 140 adopts the group structure shown in FIGS. 8 to 10.
  • an example is shown in which a computation job divided between two computer nodes 100 is distributed.
  • each step of FIG. 12 will be described.
  • Step S1201 When a user submits an application job to the computer node 100 or another computer node 100 distributes an operation job, the job reception unit 110 receives the job. The job reception unit 110 determines which group the received job belongs to, for example, based on a delivered parameter.
  • Step S1202 to S1203 If the job has reached the end stage, the job is ended, and if there are remaining steps to be executed, the process proceeds to step S1203 (S1202).
  • the job control unit 150 acquires the next step of the calculation job to be executed (S1203).
  • Step S1204 The resource operation detection unit 120 determines whether or not the next step to be executed uses a computer resource that requires approval when accessing. If used, the process flow described in FIG. 14 described later is executed in step S1205, and if not used, the process skips to step S1207.
  • Step S1206 The approval control unit 130 receives an approval result as to whether or not the computer resource can be used from the approval server 200. If the approval result indicating that the use is permitted is received, the process proceeds to step S1207. If the approval result indicating that the use is not permitted is received, the job control unit 150 ends the calculation job currently being executed in error.
  • Step S1207 The job control unit 150 determines whether or not to generate a child job (divided job) in order to share and execute a calculation job together with other computer nodes 100. This determination may be performed, for example, according to the assumed calculation job load, or may be manually specified by the user. If a child job is to be generated, the process advances to step S1208; otherwise, the process acquired in step S1203 is executed, and the process returns to step S1202.
  • the job control unit 150 determines the computer node 100 that requests to execute the divided job (S1208).
  • the resource dividing unit 160 divides the computer resource that issued the approval request in step S1205 and distributes it to the computer node 100 that requests the divided job (S1209).
  • the resource dividing unit 160 registers the correspondence relationship between the computer resources before and after the division in the division information DB 420 (S1210).
  • the group management unit 140 creates a group to which the divided jobs belong and assigns a group ID (S1211).
  • the job control unit 150 generates a divided job, for example, by duplicating a calculation job, and associates the divided job with a group ID (S1212). The divided job subsequently takes over the group ID.
  • the job control unit 150 distributes the divided job to other computer nodes 100 and executes it (S1213).
  • Steps S1211 to S1213: Supplement 1 If the attacker knows the value of the group ID to which the divided job belongs, the computer resource may be illegally accessed using the group ID. In order to prevent this, for example, a method of generating a group ID using a random number in step S ⁇ b> 1211 or encrypting the group ID when transmitting it to another computer node 100 can be considered.
  • Steps S1211 to S1213 Supplement 2
  • the computer node 100 to which the divided job is distributed executes the same processing as steps S1201 to S1217. That is, when the divided job is further divided, the same processing as in step S1207 and thereafter is executed, and when not further divided, the child job is not generated in step S1207 and the processing is executed alone.
  • Steps S1214 to S1217 The job control unit 150 aggregates and aggregates the results of the divided jobs executed by each computer node 100 (S1214). If a new group is created in step S1211, the process flow described later with reference to FIG. 16 is executed in step S1216. If not created, the process skips to step S1217 (S1215). The resource dividing unit 160 deletes the information registered in the division information DB 420 in step S1210 (S1217).
  • FIG. 13 is a diagram showing an operation flow of the job execution system 1000 when the group management unit 140 adopts the group structure shown in FIG.
  • each step of FIG. 13 will be described. Steps similar to those in FIG. 12 are denoted by the same reference numerals, but the order of the steps is different from that in FIG. The following description will focus on the points different from FIG. 12 and the newly added steps.
  • Step S1301 After the job reception unit 110 receives the job, the group management unit 140 determines whether the group to which the job belongs is specified by a parameter or the like. When the user first inputs an application job, a group to which the application job belongs has not yet been created, and a new group is created in step S1211. When a job after the operation job generated from the application job is received, a group to which the application job as a derivation source has already been created has been skipped to step S1202.
  • Step S1202 This step is the same as that in FIG. 12, except that steps S1215 to S1216 are executed after this step.
  • the group structure of FIGS. 8 to 10 since the group structure of FIGS. 8 to 10 is adopted, the group may be deleted when all the arithmetic jobs are completed, whereas in FIG. Since there are cases where it remains, the group is deleted immediately before the job is finished.
  • Step S1206 This step is the same as that in FIG. 12, except that steps S1302 to S1303 are executed after this step. These steps are the same as steps S1215 to S1216. For the same reason as step S1202, the group is deleted immediately before the job ends in error.
  • Step S1210 Step S1210
  • the process proceeds to step S1212 after this step.
  • the subsequent steps are the same as in FIG. However, the group deletion is executed immediately after step S1202 and immediately after step S1206 as described above.
  • FIG. 14 is a diagram showing details of step S1205. Hereinafter, each step of FIG. 14 will be described.
  • Step S1401 The approval control unit 130 of the computer node 100 checks the partition information DB 420 by using the ID of the computer resource as a key in order to check whether or not there is a pre-partition resource that is a source for generating the computer resource related to the approval request. Search for.
  • Step S1402 If the pre-division resource is found in step S1401, the approval control unit 130 searches the resource information DB 410 using the pre-division resource as a key. If no pre-division resource is found in step S1401, the resource information DB 410 is searched using the computer resource related to the approval request as a key.
  • Step S1403 to S1404 If a corresponding record is found on the resource information DB 410 in step S1402, the approval control unit 130 determines that approval is required when accessing the computer resource, and issues an approval request to the approval server 200 in step S1404. . If no corresponding record is found on the resource information DB 410, no approval is required when accessing the computer resource, and the process is terminated.
  • Steps S1405 to S1407 The request reception unit 210 of the approval server 200 receives an approval request (S1405).
  • the approval unit 220 executes the same processing as steps S1401 to S1402. If a pre-division resource is found, the group related to the pre-division resource is subject to approval. If the pre-division resource is not found, the group related to the approval request is set as the approval target (S1406 to S1407).
  • Steps S1408 to S1409 The approval unit 220 searches the approval result DB 250 using the group to which the calculation job related to the approval request belongs and the computer resource set as the approval target in step S1407 as keys (S1408). If the corresponding approval result is found, the process skips to step S1412, and if not found, the process proceeds to step S1410 (S1409).
  • Steps S1410 to S1411 If no corresponding record is found on the approval result DB 250 in step S1408, the approval unit 220 determines that the approval request has not been answered, and the approver who should respond to the approval request from the resource information DB 410. Is searched (S1410). The approval unit 220 registers the approval request in the approval request DB 240 together with the approver identified in step S1410 (S1411). When there are a plurality of corresponding approvers, a record is registered for each approver.
  • Step S1412 This step is a continuation of point A in FIG.
  • the approval unit 220 determines a final approval result for the approval request by the method described above, and registers the approval result in the approval result DB 250.
  • the approval unit 220 returns the final approval result registered in the approval result DB 250 to the computer node 100 (S1413).
  • the approval control unit 130 of the computer node 100 receives the approval result (S1414).
  • the approval unit 220 searches the approval request DB 240 using the group ID 251 and resource ID 252 of the final approval result registered in the approval result DB 250 as keys.
  • the approval unit 220 deletes the corresponding record from the approval request DB 240. More specifically, not only the resource ID 243 but also the pre-division resource ID 247 is searched using the resource for which the approval result is given as a key, and the hit record is deleted.
  • FIG. 15 is a diagram illustrating a process in which the approver inputs an answer to the approval request using the approver terminal 300. Hereinafter, each step of FIG. 15 will be described.
  • the approver terminal 300 requests the approver server 200 to transmit a list of unanswered approval requests (S1501).
  • the approval unit 220 searches the approval request DB 240 using the ID of the approver as a key, and acquires a list of corresponding approval requests (S1502).
  • the approval unit 220 deletes the answered ones from the list of approval requests acquired in step S1502. Specifically, the approval request for which the answer field 246 has already been input is first deleted. Next, the approval request whose group ID field 241 and resource ID field 243 are the same as the approved approval request is further deleted.
  • Step S1503 Supplement
  • Step S1504 The approval unit 220 leaves only any one of the approval requests remaining in step S1503 that have the same group ID field 241 and resource ID field 243, and deletes the others.
  • Step S1504 Supplement
  • the resources with the same resource before division are combined into one. That is, after selecting an arbitrary record from the group of records grouped by the pair of the group ID field 241 and the resource ID field 243, the pair of the group ID field 241 and the resource ID field 247 before division is also grouped. Select any one from the list to reduce the number of records. In other words, after selecting an arbitrary record from the group of records grouped by the pair of the group ID field 241 and the resource ID field 243, the pair of the group ID field 241 and the resource ID field 247 before splitting is also grouped. Choose any one from to reduce the number of records.
  • the priority determination unit 230 determines the priority to be answered by the approver for the approval request remaining in step S1504, and assigns the priority to each approval request (S1505).
  • the approval unit 220 transmits a list of approval requests to which priority is given to the approver terminal 300 (S1506).
  • FIG. 15 Steps S1507 to S1508
  • the approver inputs an answer to the approval request on the approval request list screen 310 described with reference to FIG. 6 (S1507).
  • the approval unit 220 receives the response and records the response in the response field 246 of the approval request DB 240 (S1508).
  • FIG. 15 Steps S1509 to S1510
  • the approval unit 220 totals the answer fields 246 input by each approver, and determines the final approval result by the above-described method (S1509). If the final approval result can be confirmed, the process proceeds to point A in FIG. 14; otherwise, the process flow ends (S1510).
  • FIG. 16 is a diagram showing details of step S1216. Hereinafter, each step of FIG. 16 will be described.
  • Step S1601 The group management unit 140 of the computer node 100 searches the division information DB 420 using the group IDs of all the jobs to which it belongs as a key, and deletes the corresponding record. Since the process similar to this step is also executed by the approval server 200 in step S1605, it may be omitted.
  • the group management unit 140 requests the approval server 200 to delete the group corresponding to the record searched in step S1601 (S1602).
  • the approval unit 220 of the approval server 200 deletes the corresponding records from the approval result DB 250, the approval request DB 240, and the division information DB 420 using the requested group ID as a key (S1603 to S1605). This is because these records are not necessary after all jobs belonging to the group are completed. Thereby, for example, it is possible to prevent an attack that illegally obtains the approval result and illegally accesses the computer resource.
  • the job execution system 1000 can employ any of the group structures described with reference to FIGS. As a result, an appropriate approval operation can be performed according to the job characteristics and the authority of the approver described with reference to FIGS.
  • Priority determination method 1 When approval requests are received from a plurality of groups for the same computer resource, it is desirable to determine the approval result for that computer resource early and notify the request source. Therefore, it is conceivable that the approval request for such a computer resource has a higher priority as the number of related groups increases.
  • the number of approval requests related to a computer resource can be counted by grouping records using the resource ID field 243 of the approval request DB 240 as a key (for example, using a SQL group by phrase).
  • Priority determination method 2 When approval requests are received from a plurality of operation jobs belonging to the same group, it is assumed that the group is executed by a large number of nodes (occupies a lot of calculation resources). Therefore, it is possible to increase the priority of approval requests from the group as the number of computation jobs related to the approval request increases.
  • the number of approval requests for each group can be counted by grouping records using the group ID field 241 of the approval request DB 240 as a key.
  • the higher the number of records the higher the priority is set.
  • (Priority determination method 3) If the number of approved computer resources related to the same group is large, it is considered that the number of computer resources that a job belonging to the group needs to access is large. In this case, it is assumed that the number of computer resources secured by the group is large. Therefore, it is possible to increase the priority of approval requests from the group as the number of computer resources related to the approval request that belong to the same group increases.
  • the number of computer resources for each group can be counted by grouping records using the group ID field 241 and resource ID field 243 of the approval request DB 240 as keys.
  • the computer node 100 executes a job using the computer resource until the approval server 200 transmits an approval result indicating that the access to the computer resource is permitted to the computer node 100. It is necessary in terms of security measures to prevent this from happening. The following can be considered as a specific method for realizing this.
  • Access control method for authorization 1 When a computer resource used by a job is a data file, the data file is encrypted in advance to ensure security. When the approval server 200 transmits an approval result indicating that access to the computer resource is permitted, the approval server 200 also transmits the decryption key to the computer node 100. Thus, since the data file cannot be read until an appropriate approval result is obtained, even if the data file is accessed, the job cannot be executed.
  • each computer can be replaced, or can be consolidated on a certain computer.
  • the function unit of the approval server 200 is mounted on any computer node 100.
  • the job duplicating unit 151 and the resource dividing unit 160 may not be necessary for the computer node 100 that executes only divided jobs and does not generate further divided jobs or derived jobs. That is, it is only necessary that the function units described in the above embodiments are provided in a manner that does not impair the purpose of the distributed system as the entire job execution system 1000.
  • the above components, functions, processing units, processing means, etc. may be realized in hardware by designing some or all of them, for example, with an integrated circuit.
  • Each of the above-described configurations, functions, and the like may be realized by software by interpreting and executing a program that realizes each function by the processor.
  • Information such as programs, tables, and files for realizing each function can be stored in a recording device such as a memory, a hard disk, an SSD (Solid State Drive), or a recording medium such as an IC card, an SD card, or a DVD.

Abstract

　コンピュータリソースを用いて演算ジョブを実行するために承認が必要となる場合において、承認処理の負担を軽減する。　本発明に係るジョブ実行システムは、複数の演算ジョブをグループ化してグループ単位で承認を依頼し、グループに対する承認を得た場合はそのグループに含まれる全演算ジョブが承認されたものとして取り扱う。

Description

ジョブ実行システム、ジョブ実行プログラム、ジョブ実行方法
　本発明は、コンピュータリソースを用いて演算ジョブを実行する技術に関する。
　データ量の増加に伴い、グリッド・コンピューティングのような分散処理が注目を集めている。分散処理の１つの適用例として総売上高の算出がある。ここでは、取引データとして登録された各取引の金額をすべて加算して総売上高を求めるものとする。取引数が少ない場合は１台のコンピュータでも短時間で処理を終えることができるが、取引数が多い場合は総売上高の算出に長時間かかってしまうため、複数台のコンピュータに取引のデータを分割して配布し、各コンピュータ上で計算を分散実行することにより、短時間で計算結果を得ることができる。
　下記特許文献１には、分散コンピューティング技術に関する技術が記載されている。同文献では、『分散コンピュータネットワークにおいてリソースに対するセキュリティを確保したアクセスを提供する。』ことを課題として、『ジョブチケット（６１）を格納することができ、該ジョブチケットがジョブに対する参照を提供し、該ジョブが１つまたは複数のリソースを含み、プロセッサ（８０）が該ジョブを実行するために前記ジョブチケットにアクセスするものである、ジョブチケットサービス（６０）と、該ジョブチケットへのアクセスを試みているプロセッサの識別を検証することができる認証機構（９４）と、該認証機構から前記識別を受取ることができ前記プロセッサに対し前記ジョブチケットにアクセスする権限を提供することができ、前記プロセッサが、前記ジョブチケットにアクセスする時に前記１つまたは複数のリソースにアクセスする、権限付与機構（９２）とを具備する。』という技術が開示されている（要約参照）。
　下記特許文献２では、ネットワーク上に配置されたデータファイルに対するアクセスを制御する技術が記載されている。同文献では、『ネットワークに接続された端末におけるファイル操作を検出した際に、その操作の承認の可否を決定することにより、操作を制御する技術を提供する。』ことを課題として、『サーバＳの操作情報取得部２１は、端末Ｃから操作情報を取得する。承認依頼部２２は、取得した操作情報に基づき、承認者を特定し、承認者情報を取得すると共に、特定した承認者に承認依頼を送信する。承認結果受信部２３は、各承認者からの承認結果を受信し、集計部２４に渡す。集計部２４は、承認者情報および承認結果を取得し、所定条件を満たすと集計結果を生成する。承認可否判定部２５は、集計部２４から集計結果を取得し、操作情報と集計結果に基づき、承認の可否を判定する。制御部２６は、承認可否判定部２５による判定結果に基づき、所定の制御を実行する。』という技術が開示されている（要約参照）。
特開２００３－１２２５４０号公報 特開２００９－２３０２５７号公報
　アクセスするために承認を要するコンピュータリソースを用いて演算ジョブを実行する場合には、演算ジョブを開始する前にそのコンピュータリソースを使用することについて承認を得なければならない。分散コンピューティング環境においては、コンピュータリソースと演算ジョブがともに分散しているため、個々のコンピュータリソースと演算ジョブについて個別に承認を実施する必要があると考えられる。これは特に、承認者が手作業によって承認を実施する場合において、承認者にとって過剰な負担になる。
　上記特許文献１に記載されている技術では、ジョブチケットにアクセスするプロセッサを認証し、認証されたプロセッサへアクセス権限を付与する。この技術では、各プロセッサを個別に認証する必要があると考えられる。また同文献では、認証処理を通過したプロセッサについてはジョブチケットへアクセスする権限を自動的に付与しているので、承認者が個々のジョブチケットについて承認作業を個別に実施することは想定されていないと考えられる。
　上記特許文献２に記載されている技術では、ファイルに対するアクセスを承認者が承認しているが、分散コンピューティング環境については考慮されていない。また、同文献に記載されている技術をそのまま分散コンピューティング環境に導入すると、個々の演算ジョブやコンピュータリソースについて個別に承認を実施しなければならないので、承認者にとっての負担が大きくなると考えられる。
　本発明は、上記のような課題に鑑みてなされたものであり、コンピュータリソースを用いて演算ジョブを実行するために承認が必要となる場合において、承認処理の負担を軽減することを目的とする。
　本発明に係るジョブ実行システムは、複数の演算ジョブをグループ化してグループ単位で承認を依頼し、グループに対する承認を得た場合はそのグループに含まれる全演算ジョブが承認されたものとして取り扱う。
　本発明に係るジョブ実行システムによれば、個々の演算ジョブについて個別に承認を実施する必要がなくなるので、承認処理の負担を軽減することができる。
　上記した以外の課題、構成、および効果は、以下の実施形態の説明により明らかになるであろう。
実施形態１に係るジョブ実行システム１０００の構成図である。 承認依頼ＤＢ２４０の構成とデータ例を示す図である。 承認結果ＤＢ２５０の構成とデータ例を示す図である。 リソース情報ＤＢ４１０の構成とデータ例を示す図である。 分割情報ＤＢ４２０の構成とデータ例を示す図である。 承認者端末３００が表示する承認依頼一覧画面３１０の画面イメージである。 グループ管理部１４０が作成するジョブグループとジョブグループ全体に対する承認について説明する図である。 演算ジョブを複製することにより生成した分割ジョブと、分割ジョブから派生した演算ジョブとを同じグループに所属させる例を示す図である。 演算ジョブを複製することにより生成した分割ジョブと、分割ジョブから派生した演算ジョブとを異なるグループに所属させる例を示す図である。 分割前後に係る演算ジョブを同じグループに所属させる例を示す図である。 アプリケーションジョブとこれから生成した演算ジョブを同じグループに所属させる例を示す図である。 グループ管理部１４０が図８～図１０に示すグループ構造を採用する場合における、ジョブ実行システム１０００の動作フローを示す図である。 グループ管理部１４０が図１１に示すグループ構造を採用する場合における、ジョブ実行システム１０００の動作フローを示す図である。 ステップＳ１２０５の詳細を示す図である。 承認者が承認者端末３００を用いて承認依頼に対する回答を入力する処理を説明する図である。 ステップＳ１２１６の詳細を示す図である。
＜実施の形態１：システム構成＞
　図１は、本発明の実施形態１に係るジョブ実行システム１０００の構成図である。ジョブ実行システム１０００は、コンピュータリソースを用いて演算ジョブを実行するシステムであり、計算機ノード１００、承認サーバ２００、承認者端末３００、リソース情報データベース（ＤＢ）４１０、分割情報データベース（ＤＢ）４２０を備える。これらはネットワークを介して互いに接続されている。
　計算機ノード１００は、演算ジョブを実行するコンピュータであり、複数台設けられている。ユーザは、上位アプリケーションのジョブ（例えば経理アプリケーションの売上集計ジョブ）を計算機ノード１００に投入する。アプリケーションジョブが投入された計算機ノード１００は、そのアプリケーションジョブを複数の演算ジョブ（例えば店舗毎の集計ジョブ）に分割し、他の計算機ノード１００へ配布する。各計算機ノード１００は、受け取った演算ジョブを実行する。これにより、複数の計算機ノード１００がアプリケーションジョブを分担して実行することになる。
　計算機ノード１００は、ジョブ受付部１１０、リソース操作検知部１２０、承認制御部１３０、グループ管理部１４０、ジョブ制御部１５０、リソース分割部１６０を備える。
　ジョブ受付部１１０は、ユーザが投入したアプリケーションジョブ、または他の計算機ノード１００が配布した演算ジョブを受け取り、そのジョブがいずれのグループに属するかを判定する。ジョブが属するグループについては後述する。ジョブ受付部１１０が受け取ったジョブは、ジョブ制御部１５０によって実行される。
　リソース操作検知部１２０は、ジョブ制御部１５０が実行するジョブがコンピュータリソースにアクセスする必要がある場合、その旨を検知する。ここでいうコンピュータリソースは、例えば演算ジョブを実行する際に用いるデータファイルまたはデータベースのテーブル、他の計算機ノード１００、などが考えられる。以下では説明の便宜上、コンピュータリソースとして、演算ジョブを実行する際に用いるデータファイルを例に動作を説明する。例えば経理アプリケーションの例においては、演算ジョブがアクセスするデータファイルとして、全店舗の売上実績を記録したデータファイルが考えられる。
　承認制御部１３０は、リソース操作検知部１２０がコンピュータリソースへのアクセスを検知した場合、そのコンピュータリソースにアクセスするために承認を要するか否かを判定する。判定手法については後述する。承認を要する場合、承認制御部１３０は承認依頼を承認サーバ２００へ発行する。承認者がその承認依頼に対して回答（承認結果）を入力した後、承認制御部１３０はその承認結果を承認サーバ２００から受け取ってジョブ制御部１５０に通知する。承認依頼が生じてから承認者が回答を入力するまではタイムラグがあるので、承認制御部１３０は承認依頼に対する回答を即時に得られるとは限らない。ただし後述するように、同じグループに属する演算ジョブに対して既に承認者が回答を入力していた場合は、即座に回答を得ることができる。
　グループ管理部１４０は、複数の演算ジョブをグループ化し、同一のグループＩＤを付与する。同じグループに属する演算ジョブを複数の計算機ノード１００に配布する場合、各計算機ノード１００が受け取る演算ジョブは、そのグループのグループＩＤを、配布前の演算ジョブから引き継ぐ。グループＩＤを複数の演算ジョブ間で共有する手法については後述する。
　ジョブ制御部１５０は、ジョブ受付部１１０が受け取ったアプリケーションジョブに基づき個々の演算ジョブを生成して実行し、または他の計算機ノード１００へ演算ジョブを配布して実行させその結果を受け取る。ジョブ制御部１５０は、他の計算機ノード１００から演算ジョブを受け取る場合もある。この場合はその演算ジョブを実行する。ジョブ制御部１５０が個々の演算ジョブを生成する手法については後述する。
　ジョブ制御部１５０はさらに、ジョブ複製部１５１を備える。ジョブ複製部１５１は、演算ジョブを複製することにより分割する機能部である。複製された演算ジョブは複製元の演算ジョブと同じ処理を実行するが、処理対象となるデータファイルなどが異なる。
　リソース分割部１６０は、ジョブ制御部１５０が他の計算機ノード１００へ演算ジョブを配布する場合において、他の計算機ノード１００が演算ジョブを実行するためアクセスするコンピュータリソースを他の計算機ノード１００へ配布する。例えば演算ジョブを実行するためデータファイルにアクセスする必要がある場合、リソース分割部１６０はそのデータファイルのうち他の計算機ノード１００がアクセスする必要がある部分を分割して他の計算機ノード１００へ配布する。
　承認サーバ２００は、計算機ノード１００が備える承認制御部１３０より承認依頼を受け取って承認結果を回答するコンピュータである。承認サーバ２００は、コンピュータリソースに対するアクセスを、グループ管理部１４０が作成したグループ単位で承認する。承認サーバ２００は、依頼受付部２１０、承認部２２０、優先度判定部２３０、承認依頼データベース（ＤＢ）２４０、承認結果データベース（ＤＢ）２５０を備える。
　依頼受付部２１０は、承認制御部１３０が発行した承認依頼を受け取り、その承認依頼に対する回答（承認結果）が入力されているか否か、承認結果ＤＢ２５０から検索する。承認結果が見つからない場合、依頼受付部２１０はその承認依頼を承認依頼ＤＢ２４０へ登録する。承認結果が見つかった場合、依頼受付部２１０はその承認結果を承認制御部１３０へ返信する。
　承認部２２０は、承認者端末３００からのリクエストに応じて承認依頼ＤＢ２４０に登録されている承認依頼のリストを承認者端末３００へ送信する。また、承認者端末３００から承認依頼に対する承認結果を受け取り、承認依頼ＤＢ２４０へ登録する。承認部２２０は、承認依頼ＤＢ２４０に登録されている回答を集計し、グループに対する最終的な承認結果を決定して承認結果ＤＢ２５０に格納する。最終的な承認結果については後述の図２で改めて説明する。承認されたグループに属する全ての演算ジョブは、ジョブの過程で使用するコンピュータリソースにアクセスすることを許可される。
　優先度判定部２３０は、承認依頼ＤＢ２４０に登録されている承認依頼の優先度を判定する。この優先度は、どの順序で承認依頼を処理すべきかを定めるための指標となる。承認者はこの優先度を参考にして、承認処理を実施することができる。優先度の高低は、例えば複数の承認者から承認を得なければならない場合において、承認を要する承認者の人数が多い承認依頼ほど優先度を高くする、などの手法が考えられる。
　承認依頼ＤＢ２４０、承認結果ＤＢ２５０、リソース情報ＤＢ４１０、分割情報ＤＢ４２０については、後述の図２～図５で説明する。
　承認者端末３００は、承認者が承認依頼に対する回答を入力するための端末である。承認者端末３００は、未回答の承認依頼があるか否かを承認サーバ２００へ問い合わせる。承認者端末３００は、後述の図６で説明する画面上に未回答の承認依頼のリストを表示する。承認者はその画面上で回答を入力する。承認サーバ２００はその回答を受け取って承認依頼ＤＢ２４０に格納する。
　図１に示す各コンピュータが備える各機能部は、これらの機能を実現する回路デバイスなどのハードウェアとして構成することもできるし、同様の機能を実装したプログラムとこれを実行するＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）などの演算装置を用いて構成することもできる。
　図２は、承認依頼ＤＢ２４０の構成とデータ例を示す図である。承認依頼ＤＢ２４０は未回答の承認依頼を保持するデータベースであり、データを保持するデータファイルをＨＤＤ（Ｈａｒｄ　Ｄｉｓｋ　Ｄｒｉｖｅ）などの記憶装置に格納することによって構成することができる。図２ではテーブル形式の構成を例示したが、その他の形式でもよい。データベースを構成する手法およびデータ形式については他のデータベースについても同様であるため、以降に説明するデータベースについてはその記載を省略する。
　承認依頼ＤＢ２４０は、グループＩＤフィールド２４１、代表ジョブＩＤフィールド２４２、リソースＩＤフィールド２４３、依頼元フィールド２４４、承認者ＩＤフィールド２４５、回答フィールド２４６、分割前リソースＩＤフィールド２４７、作業者ＩＤフィールド２４８、アプリケーションジョブＩＤフィールド２４９を有する。承認依頼ＤＢ２４０の各レコードが１つの承認依頼に相当する。承認者端末３００は承認依頼ＤＢ２４０に格納されているレコードを取得し、後述の図６で説明する画面上に取得したレコードを表示する。
　グループＩＤフィールド２４１は、グループ管理部１４０が作成したグループのＩＤを保持する。代表ジョブＩＤフィールド２４２は、グループＩＤフィールド２４１が指定するグループを代表する演算ジョブのＩＤを保持する。リソースＩＤフィールド２４３は、グループＩＤフィールド２４１が指定するグループに含まれる演算ジョブを実行するためにアクセスする必要があるコンピュータリソースのうちアクセスする際に承認を要するもののＩＤを保持する。依頼元フィールド２４４は、承認依頼を発行した計算機ノード１００を識別する情報を保持する。ここではＩＰアドレスとポート番号を例示した。承認者ＩＤフィールド２４５は、承認依頼に対して回答すべき承認者のＩＤを保持する。
　回答フィールド２４６は、承認者が承認者端末３００上で入力した回答を保持する。承認結果ＤＢ２５０とは別に本フィールドを設けているのは、承認者が複数いる場合を想定しているためである。
　そこで本実施形態１では、承認者端末３００から入力された承認結果をいったん承認依頼ＤＢ２４０上に格納し、グループに属する演算ジョブに対する承認結果がある程度（必ずしも全部でなくともよい）集まった段階で、承認部２２０がそのグループに対する最終的な承認結果を判定することとした。例えば、同じグループに属する演算ジョブに対する承認結果の多数決によって、そのグループに対する最終的な承認結果を判定することができる。その他適当な手法を用いて判定してもよい。承認部２２０は、グループに対する最終的な承認結果を承認結果ＤＢ２５０に格納する。
　分割前リソースＩＤフィールド２４７は、リソースＩＤフィールド２４３が指定するコンピュータリソースがリソース分割部１６０によって作成されたものである場合、その分割前のリソースのＩＤを保持する。本フィールドは後述する分割情報ＤＢ４２０から取得することもできるので、必ずしも承認依頼ＤＢ２４０内に設けなくともよい。
　作業者ＩＤフィールド２４８は、各グループに含まれる演算ジョブを生成する元になったアプリケーションジョブを投入したユーザのＩＤである。アプリケーションジョブＩＤフィールド２４９は、そのアプリケーションジョブのＩＤである。
　承認部２２０は、承認者端末３００から承認依頼のリストを送付するよう要求するリクエストを受け取ると、その承認者のＩＤをキーにして承認依頼ＤＢ２４０を検索してその承認者が回答を入力すべき承認依頼のリストを取得する。承認部２２０は、以下の処理により承認者端末３００へ返信すべき承認依頼リストを作成する。これにより、同じ内容の承認依頼に対して何度も回答を要求することを避けることができる。
（承認依頼リスト作成処理その１）
　既に回答フィールド２４６へ回答が入力されている承認依頼については改めて承認者端末３００上で提示する必要はない。そこで承認部２２０は、承認者端末３００へ返信する承認依頼リストから回答済のものを除外する。
（承認依頼リスト作成処理その２）
　既に回答フィールド２４６へ回答が入力されている承認依頼と同じグループに属し、かつ承認対象リソース（分割されていなければリソースＩＤフィールド２４３、分割されていれば分割前リソースＩＤ２４７）も同じである承認依頼については、承認者が同じ承認結果を入力するはずである。そこで承認部２２０は、承認者端末３００へ返信する承認依頼リストから上記に該当するものを除外する。
（承認依頼リスト作成処理その３）
　未回答の承認依頼のうち、同じグループに属し、かつリソースＩＤフィールド２４３も同じである承認依頼が複数存在する場合は、そのなかのいずれか１つを残してその他の承認依頼は承認依頼ＤＢ２４０から削除する。承認者はこれらの承認依頼に対して同じ回答を入力するであろうし、後述するようにグループ全体に対して承認結果が得られればそのグループに属する全ての演算ジョブに対して同じ承認結果が適用されるので同じグループに属するいずれかの承認依頼に対して回答が得られれば十分だからである。
　図３は、承認結果ＤＢ２５０の構成とデータ例を示す図である。承認結果ＤＢ２５０は演算ジョブのグループに対する最終的な承認結果を保持するデータベースであり、グループＩＤフィールド２５１、リソースＩＤフィールド２５２、承認結果２５３を有する。
　グループＩＤフィールド２５１は、承認部２２０が最終的に承認結果を決定したグループのＩＤを保持する。本フィールドはグループＩＤフィールド２４１に対応する。リソースＩＤフィールド２５２は、グループＩＤフィールド２５１が指定するグループに含まれる演算ジョブがアクセスするコンピュータリソースのＩＤを保持する。本フィールドは分割されていなければリソースＩＤフィールド２４３、分割されていれば分割前リソースＩＤ２４７に対応する。承認結果２５３は、グループＩＤフィールド２５１が指定するグループに対する最終的な承認結果を保持する。
　図４は、リソース情報ＤＢ４１０の構成とデータ例を示す図である。リソース情報ＤＢ４１０は、アクセスする際に承認を要するコンピュータリソースを列挙するとともに、その承認者を特定するためのデータベースである。リソース情報ＤＢ４１０は、リソースＩＤフィールド４１１、承認者ＩＤフィールド４１２を有する。
　リソースＩＤフィールド４１１は、アクセスする際に承認を要するコンピュータリソースのＩＤを保持する。承認者ＩＤフィールド４１２は、リソースＩＤフィールド４１１が指定するコンピュータリソースに対するアクセスを承認する承認者のＩＤを保持する。
　計算機ノード１００の承認制御部１３０は、承認サーバ２００に対して承認依頼を発行する。承認部２２０は、その承認依頼に対して回答すべき承認者を指定する。
　図５は、分割情報ＤＢ４２０の構成とデータ例を示す図である。分割情報ＤＢ４２０は、リソース分割部１６０がコンピュータリソースを分割した場合、その分割前後の対応関係を管理するためのデータベースである。分割情報ＤＢ４２０は、グループＩＤフィールド４２１、分割後リソースＩＤフィールド４２２、分割前リソースＩＤフィールド４２３を有する。
　グループＩＤフィールド４２１は、コンピュータリソースを使用する演算ジョブが属するグループのＩＤである。分割後リソースＩＤフィールド４２２は、グループＩＤフィールドが指定するグループに属する演算ジョブが使用するコンピュータリソースのうち、リソース分割部１６０が生成したもののＩＤである。分割前リソースＩＤフィールド４２３は、分割後リソースＩＤ４２２が指定するコンピュータリソースをリソース分割部１６０が生成する元になったコンピュータリソースのＩＤである。
　リソース分割部１６０は、コンピュータリソースを分割して他の計算機ノード１００へ配布するとき、分割前後の対応関係を分割情報ＤＢ４２０へ登録する。承認依頼ＤＢ２４０の分割前リソースＩＤフィールド２４７は、分割情報ＤＢ４２０に登録されている情報から導き出すことができる。
　演算ジョブが分割後のコンピュータリソースを使用する場合においては、承認者は分割後のコンピュータリソースに対するアクセス可否を判断する必要がある。しかし、分割後のコンピュータリソースＩＤは必ずしも分割前のコンピュータリソースＩＤと同様であるとは限らず、コンピュータリソースＩＤのみではアクセス可否を判断することができない場合がある。このような場合には、分割情報ＤＢ４２０から分割前後それぞれのコンピュータリソースＩＤの対応関係を読み出し、分割前のコンピュータリソースＩＤに置き換えて承認者へ提示すればよい。分割前後のコンピュータリソースそれぞれに求められるセキュリティレベルは同程度であると考えられるので、分割前のコンピュータリソースに対するアクセス可否を判断することができれば、承認作業を実施するのに十分だからである。
　図６は、承認者端末３００が表示する承認依頼一覧画面３１０の画面イメージである。承認依頼一覧画面３１０は、承認依頼ＤＢ２４０内に登録されている承認依頼のリストを表示する画面であり、承認依頼テーブル３１１、更新ボタン３１２、承認ボタン３１３、却下ボタン３１４を有する。
　承認者は、承認作業を実施するとき、承認者端末３００のディスプレイ上に承認依頼一覧画面３１０を表示させる。このとき、当該承認者のＩＤを指定しておく。例えば当該承認者のログインＩＤなどを用いればよい。承認者端末３００は、その承認者ＩＤをキーにして承認サーバ２００へ未回答の承認依頼を問い合わせる。
　承認部２２０は、承認依頼リスト作成処理その１～３で説明した手法により承認依頼ＤＢ２４０から当該承認者に関連する承認依頼リストを作成し、承認者端末３００へ送信する。承認者端末３００は、承認依頼テーブル３１１上にその承認依頼リストを画面表示する。必ずしも承認依頼ＤＢ２４０が備える全フィールドを画面表示する必要はなく、承認者が承認作業を実施するために必要な情報のみを表示すればよい。優先度については、優先度判定部２３０が上述の方法によって判定した値を承認者端末３００へ通知し、これを表示すればよい。
　承認者は、承認ボタン３１３または却下ボタン３１４を押下することにより、承認依頼に対する回答を入力する。承認依頼リストを承認サーバ２００から再取得する場合は、更新ボタン３１２を押下する。承認サーバ２００は、承認者が入力した回答を承認者端末３００から受け取って承認依頼ＤＢ２４０の回答フィールド２４６に登録する。以後の処理は先に説明した通りである。
＜実施の形態１：ジョブグループについて＞
　図７は、グループ管理部１４０が作成するジョブグループとジョブグループ全体に対する承認について説明する図である。ここではユーザがアプリケーションジョブを投入してから各計算機ノードが承認依頼を発行するに至る処理の流れを示した。以下、図７に示す各ステップについて説明する。
（図７：ステップ１：売上集計ジョブ）
　ユーザは、上位アプリケーションを介してアプリケーションジョブを計算機ノード１００へ投入する。ここでは経理アプリケーションの全店舗売上集計ジョブを投入したものと仮定する。
（図７：ステップ２：加算ジョブ生成）
　ジョブ制御部１５０は、ユーザが投入した売上集計ジョブを、コンピュータが実行する演算ジョブとして置き換える。売上集計ジョブの例に即して述べると、各店舗の売上を加算する演算ジョブなどを生成することになると考えられる。以下では便宜上、同例を用いて説明する。
（図７：ステップ３：リソース分割承認依頼）
　演算ジョブの処理負荷が大きい場合、ジョブ制御部１５０はステップ２で生成した演算ジョブを分割して他の計算機ノード１００に割り当てる。グループ管理部１４０は、分割前後の演算ジョブをグループ化して同一のグループＩＤを割り当て、各演算ジョブにパラメータとして引き渡しておく。あるいは、各演算ジョブがいずれのグループに属しているかについて、適当なデータベース上で管理してもよい。このとき、分割後の演算ジョブが使用するコンピュータリソースを併せて配布する必要がある。ここでは売上実績を記録したデータファイルを店舗毎に分割し、その店舗の集計を担当する計算機ノード１００へ配布することとする。データファイルを分割する際に、データファイルに対するアクセスが発生するので、リソース操作検知部１２０はその旨を検知する。承認制御部１３０は、そのアクセスに対する承認依頼を承認サーバ２００へ発行する。承認者は承認者端末３００を用いてその承認依頼に対し回答する。承認部２２０は、当該グループに対する最終的な承認結果を承認結果ＤＢ２５０に登録する。
（図７：ステップ４：分割ジョブを配布）
　ジョブ制御部１５０は、分割後の演算ジョブを各計算機ノード１００へ配布する。
（図７：ステップ４：分割リソースを配布）
　リソース分割部１６０は、分割後のコンピュータリソースを、対応する計算機ノード１００へ配布する。このとき、対応する演算ジョブが属するグループＩＤと、分割前後のコンピュータリソースＩＤとの間の対応関係を、分割情報ＤＢ４２０へ登録しておく。
（図７：ステップ５：承認依頼）
　各計算機ノード１００のジョブ制御部１５０は、受け取った演算ジョブを実行する。この過程において、分割後のコンピュータリソースにアクセスする場合、リソース操作検知部１２０がその旨を検知し、承認制御部１３０はそのコンピュータリソースに対するアクセス可否について承認サーバ２００へ承認依頼を発行する。このとき、分割後の演算ジョブが属するグループＩＤを併せて承認サーバ２００へ通知する。
（図７：ステップ６：承認）
　承認部２２０は、承認依頼に係るグループＩＤをキーにして、承認結果ＤＢ２５０を検索する。図７に示す処理フローでは、ステップ３において既に当該グループに対して承認結果が登録されているので、承認部２２０はこれを用いて承認依頼に対し回答する。これにより、承認者が分割後ジョブから発生した承認依頼に対して逐一回答を入力する必要がなくなるので、承認者の負担を軽減することができる。各計算機ノード１００のジョブ制御部１５０は、グループに対してコンピュータリソースへのアクセスを許可する旨の承認結果を得た場合は各演算ジョブを実行し、アクセスを許可しない旨の承認結果を得た場合はジョブの実行を中止する。
＜実施の形態１：まとめ＞
　以上のように、本実施形態１に係るジョブ実行システム１０００は、演算ジョブを分割して各計算機ノード１００へ配布する際に、各演算ジョブをグループ化して同じグループＩＤを割り当てておく。各計算機ノード１００は、分割後の演算ジョブを実行する際に承認サーバ２００へ承認依頼を発行する。承認サーバ２００はグループに対する承認結果を回答し、各計算機ノード１００はこれにしたがって演算ジョブを制御する。この構成によれば、承認者はグループに対する承認結果をいったん回答すれば、以後の分割後ジョブから生じる承認依頼に対して逐一回答する必要がなくなるので、承認者の負担を軽減することができる。
＜実施の形態２＞
　実施形態１では、グループ管理部１４０が複数の演算ジョブをグループ化することについて説明した。このとき、どの範囲で演算ジョブをグループ化するかにより、承認依頼の発生頻度や承認対象が異なる。本発明の実施形態２では、グループ化する演算ジョブの範囲について種々の構成例を説明する。また、ジョブ実行システム１０００の詳細動作について併せて説明する。その他の構成は実施形態１と同様である。
　図８は、演算ジョブを複製することにより生成した分割ジョブと、分割ジョブから派生した演算ジョブとを同じグループに所属させる例を示す図である。ジョブ複製部１５１はアプリケーションジョブから生成された代表演算ジョブを複製することにより、分割演算ジョブを生成する。さらに分割演算ジョブのなかで、部分的な処理を担当する派生的なジョブが発生する場合もある。
　図８に示す例では、代表演算ジョブと分割演算ジョブは異なるグループに属することになるので、代表演算ジョブに対する承認結果は分割演算ジョブに対して適用されない。これは代表演算ジョブに対する承認結果を分割後の演算ジョブに引き継がせたくない場合に有効である。
　図８に示す例においては、複製によって生成したジョブが所属するグループは、複製元ジョブが無所属であれば新たに作成したグループとなり、複製元ジョブがグループに所属していればそのグループとなる。複製以外の方法によって生成したジョブが所属するグループは、生成元のジョブと同じである。
　図９は、演算ジョブを複製することにより生成した分割ジョブと、分割ジョブから派生した演算ジョブとを異なるグループに所属させる例を示す図である。分割演算ジョブから派生する派生ジョブの内容を承認者が知らない場合には、分割演算ジョブから生じた承認依頼を承認する場合においても、派生ジョブから生じる承認依頼を必ずしも承認するとは限らない。このような場合には、分割演算ジョブと派生演算ジョブを異なるグループに属させることが望ましい。
　図９に示す例においては、複製によって生成したジョブが所属するグループは、複製元ジョブが作成したグループとなる。複製以外の方法によって生成したジョブは、無所属となる。
　図１０は、分割前後に係る演算ジョブを同じグループに所属させる例を示す図である。これは実施形態１で説明したグループ構造に対応する。分割前後の演算ジョブを一括して承認したい場合には、図１０に示すグループ構造が有効である。また、分割前の演算ジョブに対する承認結果を分割後の演算ジョブにも継承させたい場合にも同様に有効である。
　図１０に示す例においては、複製によって生成したジョブが所属するグループは、複製元ジョブと同じである。複製以外の方法によって生成したジョブが所属するグループも、生成元のジョブと同じである。
　図１１は、アプリケーションジョブとこれから生成した演算ジョブを同じグループに所属させる例を示す図である。承認者がアプリケーションジョブの段階から承認を実施したい場合には、図１１に示すグループ構造が有効である。
　図１１に示す例においては、複製によって生成したジョブが所属するグループは、複製元ジョブと同じである。複製以外の方法によって生成したジョブが所属するグループも、生成元のジョブと同じである。
　図１２は、グループ管理部１４０が図８～図１０に示すグループ構造を採用する場合における、ジョブ実行システム１０００の動作フローを示す図である。ここでは２つの計算機ノード１００の間で分割した演算ジョブを配布する例を示した。以下、図１２の各ステップについて説明する。
（図１２：ステップＳ１２０１）
　ユーザがアプリケーションジョブを計算機ノード１００へ投入するか、または他の計算機ノード１００が演算ジョブを配布すると、ジョブ受付部１１０はそのジョブを受け付ける。ジョブ受付部１１０は、受け取ったジョブがいずれのグループに属するかを、例えば引き渡されるパラメータに基づき判定する。
（図１２：ステップＳ１２０２～Ｓ１２０３）
　ジョブが終了段階に達している場合はそのジョブを終了し、実行すべきステップが残っている場合はステップＳ１２０３へ進む（Ｓ１２０２）。ジョブ制御部１５０は、実行すべき演算ジョブの次のステップを取得する（Ｓ１２０３）。
（図１２：ステップＳ１２０４）
　リソース操作検知部１２０は、次に実行すべきステップが、アクセスする際に承認を要するコンピュータリソースを使用するか否かを判定する。使用する場合はステップＳ１２０５において後述の図１４で説明する処理フローを実行し、使用しない場合はステップＳ１２０７へスキップする。
（図１２：ステップＳ１２０６）
　承認制御部１３０は、承認サーバ２００よりコンピュータリソースを使用してよいか否かについての承認結果を受け取る。使用を許可する旨の承認結果を受け取った場合はステップＳ１２０７へ進み、使用を許可しない旨の承認結果を受け取った場合はジョブ制御部１５０が現在実行している演算ジョブをエラー終了する。
（図１２：ステップＳ１２０７）
　ジョブ制御部１５０は、演算ジョブを他の計算機ノード１００とともに分担して実行するため子ジョブ（分割ジョブ）を生成するか否かを判定する。この判定は、例えば想定される演算ジョブの負荷に応じて実施してもよいし、ユーザが手動で指定してもよい。子ジョブを生成する場合はステップＳ１２０８へ進み、生成しない場合はステップＳ１２０３で取得した処理を実行してステップＳ１２０２へ戻る。
（図１２：ステップＳ１２０８～Ｓ１２１０）
　ジョブ制御部１５０は、分割ジョブを実行するよう依頼する計算機ノード１００を決定する（Ｓ１２０８）。リソース分割部１６０は、ステップＳ１２０５で承認依頼を発行したコンピュータリソースを分割し、分割ジョブを依頼する計算機ノード１００へ配布する（Ｓ１２０９）。リソース分割部１６０は、分割前後のコンピュータリソースの対応関係を、分割情報ＤＢ４２０へ登録する（Ｓ１２１０）。
（図１２：ステップＳ１２１１～Ｓ１２１３）
　グループ管理部１４０は、分割ジョブを所属させるグループを作成し、グループＩＤを付与する（Ｓ１２１１）。ジョブ制御部１５０は、例えば演算ジョブを複製するなどして分割ジョブを生成し、その分割ジョブとグループＩＤを対応付ける（Ｓ１２１２）。分割ジョブは以後そのグループＩＤを引き継ぐ。ジョブ制御部１５０は、分割ジョブを他の計算機ノード１００へ配布し、実行させる（Ｓ１２１３）。
（図１２：ステップＳ１２１１～Ｓ１２１３：補足その１）
　分割ジョブが属するグループＩＤの値が攻撃者に知られると、そのグループＩＤを用いてコンピュータリソースへ不正にアクセスされる可能性がある。これを防ぐためには、例えばステップＳ１２１１において乱数を用いてグループＩＤを生成する、グループＩＤを他の計算機ノード１００へ送信する際に暗号化する、などの手法が考えられる。
（図１２：ステップＳ１２１１～Ｓ１２１３：補足その２）
　分割ジョブを配布された計算機ノード１００は、ステップＳ１２０１～Ｓ１２１７と同様の処理を実行する。すなわち、分割ジョブをさらに分割する場合にはステップＳ１２０７以降と同様の処理を実行し、さらに分割しない場合にはステップＳ１２０７において子ジョブを生成せず単独で処理を実行する。
（図１２：ステップＳ１２１４～Ｓ１２１７）
　ジョブ制御部１５０は、各計算機ノード１００が実行した分割ジョブの結果を集約して集計する（Ｓ１２１４）。ステップＳ１２１１において新たなグループを作成した場合はステップＳ１２１６において後述の図１６で説明する処理フローを実行し、作成しなかった場合はステップＳ１２１７へスキップする（Ｓ１２１５）。リソース分割部１６０は、ステップＳ１２１０で分割情報ＤＢ４２０へ登録した情報を削除する（Ｓ１２１７）。
　図１３は、グループ管理部１４０が図１１に示すグループ構造を採用する場合における、ジョブ実行システム１０００の動作フローを示す図である。以下、図１３の各ステップについて説明する。図１２と同様のステップについては同じ符号を付しているが、ステップの順序が図１２とは異なる。以下、図１２と異なる点および新たに追加されたステップを中心に説明する。
（図１３：ステップＳ１３０１）
　ジョブ受付部１１０がジョブを受け取った後、グループ管理部１４０は、そのジョブが属するグループがパラメータ等によって指定されているか否かを判定する。ユーザが最初にアプリケーションジョブを投入した場合は未だそのアプリケーションジョブを所属させるグループが作成されていないため、ステップＳ１２１１で新たにグループを作成する。アプリケーションジョブから生成した演算ジョブ以降のジョブを受け取った場合は、既に派生元であるアプリケーションジョブが所属するグループが作成されているので、ステップＳ１２０２へスキップする。
（図１３：ステップＳ１２０２）
　本ステップは図１２と同様であるが、本ステップの次にステップＳ１２１５～Ｓ１２１６を実行する点が図１２とは異なる。図１２においては図８～図１０のグループ構造を採用しているため演算ジョブが全て終了した時点でグループを削除すればよいのに対し、図１３においては演算ジョブが終了してもアプリケーションジョブが残っている場合があるので、ジョブを終了する直前にグループを削除することとした。
（図１３：ステップＳ１２０６）
　本ステップは図１２と同様であるが、本ステップの次にステップＳ１３０２～Ｓ１３０３を実行する点が図１２とは異なる。これらのステップはステップＳ１２１５～Ｓ１２１６と同様である。ステップＳ１２０２と同様の理由により、ジョブをエラー終了する直前でグループを削除することとしたものである。
（図１３：ステップＳ１２１０）
　図１３においては、ジョブを受け付けた直後にグループを作成しているので、本ステップの次はステップＳ１２１２へ進む。以後のステップは図１２と同様である。ただしグループ削除については上述の通りステップＳ１２０２の直後とステップＳ１２０６の直後に実行することとした。
　図１４は、ステップＳ１２０５の詳細を示す図である。以下、図１４の各ステップについて説明する。
（図１４：ステップＳ１４０１）
　計算機ノード１００の承認制御部１３０は、承認依頼に係るコンピュータリソースを生成する元になった分割前リソースが存在するか否かを確認するため、そのコンピュータリソースのＩＤをキーにして分割情報ＤＢ４２０を検索する。
（図１４：ステップＳ１４０２）
　承認制御部１３０は、ステップＳ１４０１において分割前リソースが見つかった場合は、その分割前リソースをキーにしてリソース情報ＤＢ４１０を検索する。ステップＳ１４０１において分割前リソースが見つからなかった場合は、承認依頼に係るコンピュータリソースをキーにしてリソース情報ＤＢ４１０を検索する。
（図１４：ステップＳ１４０３～Ｓ１４０４）
　承認制御部１３０は、ステップＳ１４０２においてリソース情報ＤＢ４１０上に該当するレコードが見つかった場合は、そのコンピュータリソースにアクセスする際に承認を要すると判断し、ステップＳ１４０４において承認サーバ２００へ承認依頼を発行する。リソース情報ＤＢ４１０上に該当するレコードが見つからなかった場合は、そのコンピュータリソースにアクセスする際に承認は必要ないので、本処理を終了する。
（図１４：ステップＳ１４０５～Ｓ１４０７）
　承認サーバ２００の依頼受付部２１０は、承認依頼を受け付ける（Ｓ１４０５）。承認部２２０は、ステップＳ１４０１～Ｓ１４０２と同様の処理を実行する。分割前リソースが見つかった場合はその分割前リソースに係るグループを承認対象とする。分割前リソースが見つからなかった場合は承認依頼に係るグループを承認対象とする（Ｓ１４０６～Ｓ１４０７）。
（図１４：ステップＳ１４０８～Ｓ１４０９）
　承認部２２０は、承認依頼に係る演算ジョブが属するグループと、ステップＳ１４０７において承認対象として設定したコンピュータリソースとをキーにして、承認結果ＤＢ２５０を検索する（Ｓ１４０８）。該当する承認結果が見つかった場合はステップＳ１４１２へスキップし、見つからなかった場合はステップＳ１４１０へ進む（Ｓ１４０９）。
（図１４：ステップＳ１４１０～Ｓ１４１１）
　承認部２２０は、ステップＳ１４０８において承認結果ＤＢ２５０上に該当するレコードが見つからなかった場合は、当該承認依頼は未回答であると判断し、リソース情報ＤＢ４１０からその承認依頼に対して回答すべき承認者を検索する（Ｓ１４１０）。承認部２２０は、ステップＳ１４１０で特定した承認者と併せて、承認依頼を承認依頼ＤＢ２４０に登録する（Ｓ１４１１）。該当する承認者が複数存在する場合は、個々の承認者についてそれぞれレコードを登録する。
（図１４：ステップＳ１４１２）
　本ステップは、後述する図１５のポイントＡの続きである。承認部２２０は、先に説明した手法により承認依頼に対する最終的な承認結果を決定し、承認結果ＤＢ２５０にその承認結果を登録する。
（図１４：ステップＳ１４１３～Ｓ１４１４）
　承認部２２０は、承認結果ＤＢ２５０に登録されている最終承認結果を計算機ノード１００へ返信する（Ｓ１４１３）。計算機ノード１００の承認制御部１３０は、その承認結果を受信する（Ｓ１４１４）。
（図１４：ステップＳ１４１５）
　承認部２２０は、承認結果ＤＢ２５０に登録されている最終承認結果のグループＩＤ２５１とリソースＩＤ２５２をキーにして、承認依頼ＤＢ２４０を検索する。承認部２２０は、該当する承認依頼ＤＢ２４０のレコードを削除する。具体的には、承認結果が出たリソースをキーとして、リソースＩＤ２４３だけでなく、分割前リソースＩＤ２４７も検索してヒットしたレコードを削除する。
　図１５は、承認者が承認者端末３００を用いて承認依頼に対する回答を入力する処理を説明する図である。以下、図１５の各ステップについて説明する。
（図１５：ステップＳ１５０１～Ｓ１５０２）
　承認者端末３００は、承認者サーバ２００に対し、未回答の承認依頼のリストを送信するよう要求する（Ｓ１５０１）。承認部２２０は、その承認者のＩＤをキーにして承認依頼ＤＢ２４０を検索し、該当する承認依頼のリストを取得する（Ｓ１５０２）。
（図１５：ステップＳ１５０３）
　承認部２２０は、ステップＳ１５０２で取得した承認依頼のリストのなかから、回答済のものを削除する。具体的には、回答フィールド２４６が既に入力されている承認依頼をまず削除する。次に、グループＩＤフィールド２４１とリソースＩＤフィールド２４３が回答済の承認依頼と同じである承認依頼をさらに削除する。
（図１５：ステップＳ１５０３：補足）
　承認依頼のリスト作成時は、分割前リソースが同じ分割後リソースに対する承認依頼があった場合、その中の１つでも回答済みなら、同じ分割前リソースを持つ他の分割後リソースも回答済みと判断する。すなわち、グループＩＤフィールド２４１とリソースＩＤフィールド２４３のペアだけでなく、グループＩＤフィールド２４１と分割前リソースＩＤフィールド２４７のペアでもグループ化し、その中のいずれかが回答済みであれば、回答済みと判断する。
（図１５：ステップＳ１５０４）
　承認部２２０は、ステップＳ１５０３で残った承認依頼のうち、グループＩＤフィールド２４１とリソースＩＤフィールド２４３が同じものについては、そのなかのいずれか任意の１つのみを残し、その他は削除する。
（図１５：ステップＳ１５０４：補足）
　承認依頼のリスト作成時は、分割前リソースが同じものを１つにまとめる。すなわち、グループＩＤフィールド２４１とリソースＩＤフィールド２４３のペアでグループ化したレコード群の中から任意の１つを選んだ後、グループＩＤフィールド２４１と分割前リソースＩＤフィールド２４７のペアでもグループ化し、その中から任意の１つを選び、レコード数を削減する。つまり、グループIDフィールド241とリソースIDフィールド243のペアでグループ化したレコード群の中から任意の1つを選んだ後、グループIDフィールド241と分割前リソースIDフィールド247のペアでもグループ化し、その中から任意の1つを選び、レコード数を削減する。
（図１５：ステップＳ１５０５～Ｓ１５０６）
　優先度判定部２３０は、ステップＳ１５０４で残った承認依頼について、承認者が回答すべき優先度を判定し、各承認依頼にその優先度を付与する（Ｓ１５０５）。承認部２２０は、優先度を付与した承認依頼のリストを承認者端末３００へ送信する（Ｓ１５０６）。
（図１５：ステップＳ１５０７～Ｓ１５０８）
　承認者は、図６で説明した承認依頼一覧画面３１０上で、承認依頼に対する回答を入力する（Ｓ１５０７）。承認部２２０は、その回答を受け取り、承認依頼ＤＢ２４０の回答フィールド２４６へその回答を記録する（Ｓ１５０８）。
（図１５：ステップＳ１５０９～Ｓ１５１０）
　承認部２２０は、各承認者が入力した回答フィールド２４６を集計し、上述の手法により最終的な承認結果を判定する（Ｓ１５０９）。最終的な承認結果を確定することができる段階に至っている場合は図１４のポイントＡへ進み、それ以外であれば本処理フローを終了する（Ｓ１５１０）。
　図１６は、ステップＳ１２１６の詳細を示す図である。以下、図１６の各ステップについて説明する。
（図１６：ステップＳ１６０１）
　計算機ノード１００のグループ管理部１４０は、所属する全てのジョブが終了したグループのＩＤをキーにして分割情報ＤＢ４２０を検索し、該当するレコードを削除する。本ステップと同様の処理はステップＳ１６０５において承認サーバ２００も実行するので、省略してもよい。
（図１６：ステップＳ１６０２～Ｓ１６０５）
　グループ管理部１４０は、ステップＳ１６０１で検索したレコードに対応するグループを削除するよう、承認サーバ２００へ要求する（Ｓ１６０２）。承認サーバ２００の承認部２２０は、依頼されたグループＩＤをキーにして、該当するレコードを承認結果ＤＢ２５０、承認依頼ＤＢ２４０、分割情報ＤＢ４２０からそれぞれ削除する（Ｓ１６０３～Ｓ１６０５）。グループに属する全てのジョブが終了した後は、これらのレコードは必要ないからである。これにより、例えば承認結果を不正に取得してコンピュータリソースへ不正アクセスするような攻撃を防ぐことができる。
＜実施の形態２：まとめ＞
　以上のように、本実施形態２に係るジョブ実行システム１０００は、図８～図１１で説明したグループ構造のうちいずれかを採用することができる。これにより、図８～図１１でそれぞれ説明したようなジョブの特性や承認者の権限などに応じて、適切な承認作業を実施することができる。
＜実施の形態３＞
　実施形態１～２では、優先度判定部２３０が承認依頼の優先度を判定する手法として、多数決に係る承認者数が多いものを優先することを説明した。本発明の実施形態３では、優先度を判定するその他の手法について説明する。これらの手法は実施形態１～２で説明したものに代えて用いることもできるし、ジョブの性質等に応じて判定手法を入れ替えるなどによって併用してもよい。
（優先度の判定手法その１）
　同じコンピュータリソースに対して複数のグループから承認依頼が届いている場合、そのコンピュータリソースについては承認結果を早く決定して依頼元へ通知することが望ましいと考えられる。そこで、このようなコンピュータリソースに係る承認依頼は、関連するグループの数が多いほど優先度を高くすることが考えられる。コンピュータリソースに係る承認依頼の件数は、承認依頼ＤＢ２４０のリソースＩＤフィールド２４３をキーにしてレコードをグループ化する（例えばＳＱＬのｇｒｏｕｐ　ｂｙ句を用いる）ことによりカウントできる。
（優先度の判定手法その２）
　同じグループに属する複数の演算ジョブから承認依頼が届いている場合、グループが多数のノードで実行されている（多くの計算資源を占有している）と想定される。そこで、承認依頼に係る演算ジョブのうち同じグループに属するものが多いほど、そのグループからの承認依頼の優先度を高くすることが考えられる。グループ毎の承認依頼の件数は、承認依頼ＤＢ２４０のグループＩＤフィールド２４１をキーにしてレコードをグループ化することによりカウントできる。グループ化した承認依頼のうち、依頼元が同じものを１つにまとめたとき、レコード数が多いものほど優先度を高く設定する。
（優先度の判定手法その３）
　同じグループに係る承認済のコンピュータリソース数が多い場合、そのグループに属するジョブがアクセスする必要があるコンピュータリソース数が多いと考えられる。この場合、そのグループが確保しているコンピュータリソースの数が多いと想定される。そこで、承認依頼に係るコンピュータリソースのうち同じグループに属するものが多いほど、そのグループからの承認依頼の優先度を高くすることが考えられる。グループ毎のコンピュータリソースの件数は、承認依頼ＤＢ２４０のグループＩＤフィールド２４１とリソースＩＤフィールド２４３をキーにしてレコードをグループ化することによりカウントできる。
＜実施の形態４＞
　以上の実施形態１～３において、承認サーバ２００がコンピュータリソースへのアクセスを許可する旨の承認結果を計算機ノード１００へ送信するまでは、計算機ノード１００はそのコンピュータリソースを用いたジョブを実行することができないようにしておくことが、セキュリティ対策の上で必要である。これを実現する具体的な手法として、以下のようなものが考えられる。
（承認に関するアクセス制御手法その１）
　ジョブが使用するコンピュータリソースがデータファイルである場合、セキュリティを確保するため、そのデータファイルをあらかじめ暗号化しておく。承認サーバ２００は、コンピュータリソースに対するアクセスを許可する旨の承認結果を送信する際に、その復号キーを併せて計算機ノード１００へ送信する。これにより、適正な承認結果を得るまではそのデータファイルを読み取ることができないので、仮にそのデータファイルへアクセスしてもジョブを実行することはできない。
（承認に関するアクセス制御手法その２）
　手法その１と同様の手法として、データファイルに対するアクセス権限を付与することが考えられる。例えばファイルシステム上のアクセス権限設定により、データファイルに対するアクセスをあらかじめ禁止しておく。承認サーバ２００は、コンピュータリソースに対するアクセスを許可する旨の承認結果を送信する際に、アクセス権限を付与する情報を併せて計算機ノード１００へ送信する。
（承認に関するアクセス制御手法その３）
　上記手法その１～その２は、データベースに対するアクセスにおいても有用である。すなわち、データベース上のデータをあらかじめ暗号化しておくか、またはデータベースに対するアクセス権限を付与することにより、同様の効果を発揮することができる。
（承認に関するアクセス制御手法その４）
　ジョブが使用するコンピュータリソースが計算機ノード１００の演算リソース（例えばＣＰＵやメモリ）である場合、ファイアウォールの設定などにより、その計算機ノード１００に対する通信をあらかじめ遮断しておく。承認サーバ２００は、コンピュータリソースに対するアクセスを許可する旨の承認結果を送信する際に、ファイアウォールの設定を変更し、アクセス元の計算機ノード１００とアクセス先の計算機ノード１００との間の通信を許可する。
　本発明は上記した実施形態に限定されるものではなく、様々な変形例が含まれる。上記実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施形態の構成の一部を他の実施形態の構成に置き換えることもできる。また、ある実施形態の構成に他の実施形態の構成を加えることもできる。また、各実施形態の構成の一部について、他の構成を追加・削除・置換することもできる。
　例えば、各コンピュータが備える機能部を入れ替えることもできるし、あるコンピュータ上に集約することもできる。具体的には、いずれかの計算機ノード１００上に承認サーバ２００の機能部を実装することが考えられる。あるいは、分割ジョブのみを実行し、さらなる分割ジョブや派生ジョブを生成しない計算機ノード１００については、ジョブ複製部１５１とリソース分割部１６０は必要ないであろう。すなわち、ジョブ実行システム１０００全体として、以上の実施形態で説明した各機能部が、分散システムの趣旨を損なわない態様で設けられていればよい。
　上記各構成、機能、処理部、処理手段等は、それらの一部や全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ）等の記録装置、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に格納することができる。
　１００：計算機ノード、１１０：ジョブ受付部、１２０：リソース操作検知部、１３０：承認制御部、１４０：グループ管理部、１５０：ジョブ制御部、１６０：リソース分割部、２００：承認サーバ、２１０：依頼受付部、２２０：承認部、２３０：優先度判定部、２４０：承認依頼ＤＢ、２５０：承認結果ＤＢ、３００：承認者端末、４１０：リソース情報ＤＢ、４２０：分割情報ＤＢ、１０００：ジョブ実行システム。

Claims (20)

  1. 　コンピュータリソースを用いて演算ジョブを実行するジョブ制御部と、
    　前記コンピュータリソースを用いて前記演算ジョブを実行する可否について承認を依頼しその承認結果を受け取る承認制御部と、
    　複数の前記演算ジョブをグループ化したグループを作成するグループ管理部と、
    　を備え、
    　前記承認制御部は、
    　　前記グループ管理部が作成した前記グループに含まれる前記演算ジョブに対する前記承認を依頼し、前記承認結果として前記グループに対する承認結果を受け取り、
    　前記ジョブ制御部は、
    　　前記グループに対して実行を許可する旨の前記承認結果を前記承認制御部が受け取った場合は、そのグループに含まれる各前記演算ジョブをそれぞれ実行し、
    　　前記グループに対して実行を許可しない旨の前記承認結果を前記承認制御部が受け取った場合は、そのグループに含まれる各前記演算ジョブを実行しない
    　ことを特徴とするジョブ実行システム。
  2. 　前記ジョブ実行システムは、
    　　前記演算ジョブを複製することによって生成した子ジョブを他の計算機ノードに対して配布して実行させるジョブ複製部を備え、
    　前記グループ管理部は、
    　　前記ジョブ複製部が生成した前記子ジョブをグループ化し、
    　前記承認制御部は、
    　　前記子ジョブを含む前記グループに対する前記承認を依頼する
    　ことを特徴とする請求項１記載のジョブ実行システム。
  3. 　前記ジョブ実行システムは、
    　　前記コンピュータリソースを分割して前記他の計算機ノードへ配布するリソース分割部を備え、
    　前記ジョブ複製部は、
    　　前記リソース分割部が前記他の計算機ノードへ配布した前記コンピュータリソースを用いて前記子ジョブを実行するよう前記他の計算機ノードへ指示し、
    　前記承認制御部は、
    　　前記グループ管理部が作成した前記グループに含まれる前記演算ジョブのうち前記リソース分割部が分割する前の前記コンピュータリソースを使用する演算ジョブである分割前演算ジョブに対する前記承認を依頼し、
    　前記ジョブ制御部は、
    　　前記分割前演算ジョブの実行を許可する旨の前記承認結果を前記承認制御部が受け取った場合は、前記グループ管理部が作成した前記グループに含まれる前記演算ジョブのうち前記リソース分割部が分割する前後双方に係る前記コンピュータリソースを使用する演算ジョブをいずれも実行する
    　ことを特徴とする請求項２記載のジョブ実行システム。
  4. 　前記コンピュータリソースは、暗号化されたデータファイルであり、
    　前記承認制御部は、
    　　前記グループに対して実行を許可する旨の前記承認結果とともに、前記コンピュータリソースを復号するための復号鍵を併せて受け取り、
    　前記ジョブ制御部は、
    　　前記復号鍵を用いて復号した前記コンピュータリソースを用いて前記演算ジョブを実行する
    　ことを特徴とする請求項１から３のいずれか１項記載のジョブ実行システム。
  5. 　前記ジョブ実行システムは、
    　　前記演算ジョブが使用する際に承認を要する前記コンピュータリソースのＩＤを記憶するリソース情報記憶部を備え、
    　前記承認制御部は、
    　　前記演算ジョブが使用する前記コンピュータリソースのＩＤが前記リソース情報記憶部に格納されている場合は、そのコンピュータリソースを用いて前記演算ジョブを実行する可否について前記承認を依頼し、
    　前記ジョブ実行部は、
    　　前記演算ジョブが使用する前記コンピュータリソースのＩＤが前記リソース情報記憶部に格納されていない場合は、前記承認制御部が前記承認を依頼していなくとも、そのコンピュータリソースを用いて前記演算ジョブを実行する
    　ことを特徴とする請求項１から４のいずれか１項記載のジョブ実行システム。
  6. 　前記ジョブ複製部は、前記子ジョブを生成する際に、
    　　前記演算ジョブが属する前記グループのＩＤを複製元の前記演算ジョブから複製後の前記子ジョブへ引き継ぎ、または、前記演算ジョブもしくは前記子ジョブが使用する前記コンピュータリソースのＩＤを前記グループのＩＤとともに記憶装置へ格納しておき、
    　前記承認制御部は、
    　　前記子ジョブが複製元の前記演算ジョブから引き継いだ前記ＩＤを取得し、または、演算ジョブもしくは前記子ジョブが使用する前記コンピュータリソースに対応する前記グループのＩＤを前記記憶装置から読み出すことにより、前記演算ジョブまたは前記子ジョブがいずれの前記グループに属するかを特定する
    　ことを特徴とする請求項２または３記載のジョブ実行システム。
  7. 　前記グループ管理部は、
    　　同じ前記演算ジョブを複製することによって生成された前記子ジョブおよびその子ジョブから派生した演算ジョブを、同じ前記グループとしてグループ化する
    　ことを特徴とする請求項６記載のジョブ実行システム。
  8. 　前記グループ管理部は、
    　　同じ前記演算ジョブを複製することによって生成された前記子ジョブを同じ前記グループとしてグループ化し、前記子ジョブから派生した演算ジョブはそのグループには含めない
    　ことを特徴とする請求項６項記載のジョブ実行システム。
  9. 　前記グループ管理部は、
    　　同じ前記演算ジョブを複製することによって生成された前記子ジョブ、その子ジョブから派生した演算ジョブ、および前記子ジョブの複製元となった前記演算ジョブを、同じ前記グループとしてグループ化する
    　ことを特徴とする請求項６記載のジョブ実行システム。
  10. 　前記ジョブ複製部は、
    　　上位アプリケーションから投入されたアプリケーションジョブから派生するジョブを前記演算ジョブとして処理し、
    　前記グループ管理部は、
    　　同じ前記演算ジョブを複製することによって生成された前記子ジョブ、その子ジョブから派生した演算ジョブ、前記子ジョブの複製元となった前記演算ジョブ、および前記子ジョブの複製元となった前記演算ジョブの派生元である前記アプリケーションジョブを、同じ前記グループとしてグループ化する
    　ことを特徴とする請求項６記載のジョブ実行システム。
  11. 　前記ジョブ実行システムは、
    　　前記承認制御部が発行した前記承認の依頼を承認するか否かを判定しその承認結果を前記承認制御部へ通知する承認部を備える
    　ことを特徴とする請求項１から１０のいずれか１項記載のジョブ実行システム。
  12. 　前記承認部は、
    　　前記承認制御部が発行した前記承認の依頼を承認する場合であって、かつ前記コンピュータリソースが暗号化されたデータファイルである場合は、前記コンピュータリソースを復号するための復号鍵を、前記承認の依頼に対する承認結果とともに前記承認制御部へ送信する
    　ことを特徴とする請求項１１記載のジョブ実行システム。
  13. 　前記ジョブ実行システムは、
    　　前記承認部が承認した前記依頼に係る前記グループのＩＤを格納する承認結果記憶部を備え、
    　前記承認部は、
    　　承認した前記依頼に係る前記グループに含まれている全ての前記演算ジョブが終了するまで、前記承認結果記憶部が格納している前記グループのＩＤを前記承認結果記憶部上に保持しておき、
    　　前記承認結果記憶部上にＩＤを保持している前記グループと同じ前記グループについて前記依頼を受け取ると、その依頼を承認するか否かを判定することなく、承認した旨の承認結果を前記承認制御部へ通知する
    　ことを特徴とする請求項１１または１２記載のジョブ実行システム。
  14. 　前記グループ管理部は、
    　　前記グループに含まれる全ての前記演算ジョブが終了するとそのグループを削除し、
    　前記承認部は、
    　　前記グループが削除された後、前記承認結果記憶部が保持している前記承認結果のうち削除された前記グループに係るものを削除する
    　ことを特徴とする請求項１３記載のジョブ実行システム。
  15. 　前記ジョブ実行システムは、
    　　前記承認部が前記承認を実施すべき順序を規定する承認優先度を判定する優先度判定部を備え、
    　前記優先度判定部は、
    　　前記依頼の数が多い前記グループに係る前記承認ほど前記承認優先度を高くする
    　ことを特徴とする請求項１１から１４のいずれか１項記載のジョブ実行システム。
  16. 　前記ジョブ実行システムは、
    　　前記承認部が前記承認を実施する順序を規定する承認優先度を判定する優先度判定部を備え、
    　前記承認部は、
    　　複数の承認者から受け取った前記依頼に対する承認結果に基づき前記承認の依頼を承認するか否かを判定し、
    　前記優先度判定部は、
    　　前記承認部が前記承認の依頼を承認するか否かを判定するために必要になる前記承認者の人数が多い前記承認ほど前記承認優先度を高くする
    　ことを特徴とする請求項１１から１５のいずれか１項記載のジョブ実行システム。
  17. 　前記ジョブ実行システムは、
    　　前記承認部が前記承認を実施すべき順序を規定する承認優先度を判定する優先度判定部を備え、
    　前記優先度判定部は、
    　　前記承認依頼に係る前記演算ジョブが多く含まれている前記グループに係る前記承認ほど前記承認優先度を高くする
    　ことを特徴とする請求項１１から１６のいずれか１項記載のジョブ実行システム。
  18. 　前記ジョブ実行システムは、
    　　前記承認部が前記承認を実施すべき順序を規定する承認優先度を判定する優先度判定部を備え、
    　前記優先度判定部は、
    　　前記グループに含まれる前記演算ジョブが使用する前記コンピュータリソースのうち前記承認が済んでいるものが多い前記グループに係る前記承認ほど前記承認優先度を高くする
    　ことを特徴とする請求項１１から１７のいずれか１項記載のジョブ実行システム。
  19. 　コンピュータリソースを用いて演算ジョブを実行するジョブ制御ステップと、
    　前記コンピュータリソースを用いて前記演算ジョブを実行する可否について承認を依頼しその承認結果を受け取る承認制御ステップと、
    　複数の前記演算ジョブをグループ化したグループを作成するグループ管理ステップと、
    　をコンピュータに実行させ、
    　前記承認制御ステップでは、前記コンピュータに、
    　　前記グループ管理ステップで作成した前記グループに含まれる前記演算ジョブに対する前記承認を依頼させ、前記承認結果として前記グループに対する承認結果を受け取らせ、
    　前記ジョブ制御ステップでは、前記コンピュータに、
    　　前記グループに対して実行を許可する旨の前記承認結果を前記承認制御ステップで受け取った場合は、そのグループに含まれる各前記演算ジョブをそれぞれ実行させ、
    　　前記グループに対して実行を許可しない旨の前記承認結果を前記承認制御ステップで受け取った場合は、そのグループに含まれる各前記演算ジョブを実行させない
    　ことを特徴とするジョブ実行プログラム。
  20. 　コンピュータリソースを用いて演算ジョブを実行するジョブ制御ステップと、
    　前記コンピュータリソースを用いて前記演算ジョブを実行する可否について承認を依頼しその承認結果を受け取る承認制御ステップと、
    　複数の前記演算ジョブをグループ化したグループを作成するグループ管理ステップと、
    　を有し、
    　前記承認制御ステップでは、
    　　前記グループ管理ステップで作成した前記グループに含まれる前記演算ジョブに対する前記承認を依頼し、前記承認結果として前記グループに対する承認結果を受け取り、
    　前記ジョブ制御ステップでは、
    　　前記グループに対して実行を許可する旨の前記承認結果を前記承認制御ステップで受け取った場合は、そのグループに含まれる各前記演算ジョブをそれぞれ実行し、
    　　前記グループに対して実行を許可しない旨の前記承認結果を前記承認制御ステップで受け取った場合は、そのグループに含まれる各前記演算ジョブを実行しない
    　ことを特徴とするジョブ実行方法。
PCT/JP2012/062644 2012-05-17 2012-05-17 ジョブ実行システム、ジョブ実行プログラム、ジョブ実行方法 WO2013171879A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/JP2012/062644 WO2013171879A1 (ja) 2012-05-17 2012-05-17 ジョブ実行システム、ジョブ実行プログラム、ジョブ実行方法
US14/398,999 US9836711B2 (en) 2012-05-17 2012-05-17 Job execution system, job execution program, and job execution method
JP2014515427A JP5965999B2 (ja) 2012-05-17 2012-05-17 ジョブ実行システム、ジョブ実行プログラム、ジョブ実行方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2012/062644 WO2013171879A1 (ja) 2012-05-17 2012-05-17 ジョブ実行システム、ジョブ実行プログラム、ジョブ実行方法

Publications (1)

Publication Number Publication Date
WO2013171879A1 true WO2013171879A1 (ja) 2013-11-21

Family

ID=49583321

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2012/062644 WO2013171879A1 (ja) 2012-05-17 2012-05-17 ジョブ実行システム、ジョブ実行プログラム、ジョブ実行方法

Country Status (3)

Country Link
US (1) US9836711B2 (ja)
JP (1) JP5965999B2 (ja)
WO (1) WO2013171879A1 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9722777B2 (en) * 2013-08-01 2017-08-01 Visa International Service Association Homomorphic database operations apparatuses, methods and systems
US10514993B2 (en) * 2017-02-14 2019-12-24 Google Llc Analyzing large-scale data processing jobs
US10713090B2 (en) * 2018-05-17 2020-07-14 American Express Travel Related Services Company, Inc. Context aware prioritization in a distributed environment using tiered queue allocation
US10885537B2 (en) * 2018-07-31 2021-01-05 Visa International Service Association System and method for determining real-time optimal item pricing

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004302741A (ja) * 2003-03-31 2004-10-28 Fujitsu Ltd グリッドコンピューティングを用いたシステムにおけるリソース提供方法，そのシステムにおける監視装置，その監視装置用プログラムおよびそのシステムにおけるリソース提供端末用プログラム
JP2007226472A (ja) * 2006-02-22 2007-09-06 Nec Corp ジョブ定義確認システム、その方法およびプログラム
WO2007105512A1 (ja) * 2006-03-10 2007-09-20 Matsushita Electric Industrial Co., Ltd. 回送データ管理システム
JP2007264794A (ja) * 2006-03-27 2007-10-11 Fujitsu Ltd 並列分散処理プログラム及び並列分散処理システム
JP2009059293A (ja) * 2007-09-03 2009-03-19 Hitachi Software Eng Co Ltd ジョブ管理システム
JP2009230357A (ja) * 2008-03-21 2009-10-08 Hitachi Software Eng Co Ltd ジョブ運用管理システム
JP2009230257A (ja) * 2008-03-19 2009-10-08 Sky Co Ltd 承認システムおよび承認プログラム

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3982168B2 (ja) * 2000-11-13 2007-09-26 コクヨ株式会社 購買管理システム、購買管理方法、及び購買管理用プログラム
US20020184535A1 (en) * 2001-05-30 2002-12-05 Farah Moaven Method and system for accessing a resource in a computing system
US7073174B2 (en) 2001-06-05 2006-07-04 Hewlett-Packard Development Company, L.P. Use of job tickets to secure resource access
JP2005352697A (ja) * 2004-06-09 2005-12-22 Canon Inc コンピュータシステム、及び該システムにおけるジョブの割り当て方法
US8413135B2 (en) * 2006-10-30 2013-04-02 At&T Intellectual Property I, L.P. Methods, systems, and computer program products for controlling software application installations
US8069251B2 (en) * 2007-06-01 2011-11-29 Adobe Systems Incorporated System and/or method for client-driven server load distribution
US8719801B2 (en) * 2008-06-25 2014-05-06 Microsoft Corporation Timing analysis of concurrent programs
US7600253B1 (en) * 2008-08-21 2009-10-06 International Business Machines Corporation Entity correlation service
JP4939588B2 (ja) * 2009-10-30 2012-05-30 インターナショナル・ビジネス・マシーンズ・コーポレーション クラウド・コンピューティングにおいて、コンピューティング・サービスを法的監査要件が満たされるように個々のジョブに分割し、個々のジョブの分散実行計画をユーザに提示するための方法、コンピュータ・プログラム及び装置
CN102118261B (zh) * 2009-12-30 2014-11-26 上海中兴软件有限责任公司 一种数据采集的方法、数据采集装置及网管设备
US9311612B2 (en) * 2010-12-22 2016-04-12 Sap Se System and method for improved service oriented architecture
US8982384B2 (en) * 2011-02-18 2015-03-17 Xerox Corporation Methods and systems for brokering printing device capacity
EP2498488A1 (en) * 2011-03-09 2012-09-12 Thomson Licensing Method and system digital for processing digital content according to a workflow

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004302741A (ja) * 2003-03-31 2004-10-28 Fujitsu Ltd グリッドコンピューティングを用いたシステムにおけるリソース提供方法，そのシステムにおける監視装置，その監視装置用プログラムおよびそのシステムにおけるリソース提供端末用プログラム
JP2007226472A (ja) * 2006-02-22 2007-09-06 Nec Corp ジョブ定義確認システム、その方法およびプログラム
WO2007105512A1 (ja) * 2006-03-10 2007-09-20 Matsushita Electric Industrial Co., Ltd. 回送データ管理システム
JP2007264794A (ja) * 2006-03-27 2007-10-11 Fujitsu Ltd 並列分散処理プログラム及び並列分散処理システム
JP2009059293A (ja) * 2007-09-03 2009-03-19 Hitachi Software Eng Co Ltd ジョブ管理システム
JP2009230257A (ja) * 2008-03-19 2009-10-08 Sky Co Ltd 承認システムおよび承認プログラム
JP2009230357A (ja) * 2008-03-21 2009-10-08 Hitachi Software Eng Co Ltd ジョブ運用管理システム

Also Published As

Publication number Publication date
US20150127413A1 (en) 2015-05-07
US9836711B2 (en) 2017-12-05
JPWO2013171879A1 (ja) 2016-01-07
JP5965999B2 (ja) 2016-08-10

Similar Documents

Publication Publication Date Title
US11334562B2 (en) Blockchain based data management system and method thereof
CN113711536B (zh) 从区块链网络中提取数据
US7571473B1 (en) Identity management system and method
JP5858796B2 (ja) 権限委譲システム、およびその権限委譲システムにおけるサーバーシステム、および権限委譲システムを制御する制御方法
EP2585970B1 (en) Online service access controls using scale out directory features
US6952780B2 (en) System and method for ensuring secure transfer of a document from a client of a network to a printer
US8438266B2 (en) File sharing administration
US9769137B2 (en) Extensible mechanism for securing objects using claims
US7353542B2 (en) Storage system, computer system, and method of authorizing an initiator in the storage system or the computer system
EP2405607B1 (en) Privilege management system and method based on object
CN110032571A (zh) 业务流程处理方法、装置、存储介质及计算设备
US20110214165A1 (en) Processor Implemented Systems And Methods For Using Identity Maps And Authentication To Provide Restricted Access To Backend Server Processor or Data
US20070136291A1 (en) Access control for elements in a database object
JP2011197903A (ja) アクセス制御情報配布装置、アクセス制御情報配布プログラム、アクセス制御システム、及びアクセス制御情報配布方法
US11693948B2 (en) Verifiable labels for mandatory access control
JP5965999B2 (ja) ジョブ実行システム、ジョブ実行プログラム、ジョブ実行方法
KR102376254B1 (ko) 분산 식별자 관리 방법 및 장치
CN115552441A (zh) 低信任特权访问管理
CN106407832B (zh) 一种用于数据访问控制的方法及设备
US20070088931A1 (en) Method and apparatus to authorize cross-partition commands
US20230368185A1 (en) Public trust ledger smart contract token transfer in a database system
JP3756457B2 (ja) アクセス制御付ディレクトリ機能装置及びプログラム
US20230054904A1 (en) Layered-Infrastructure Blockchain-Based System for Software License Distribution
JP7327781B2 (ja) マッチング支援装置、マッチング支援方法、コンピュータプログラム及び記録媒体
CN114070856A (zh) 数据处理方法、装置、系统、运维审计设备和存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12876761

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2014515427

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 14398999

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12876761

Country of ref document: EP

Kind code of ref document: A1