WO2013186851A1 - Information processing system - Google Patents

Abstract

A token queue administration unit (503) comprises a plurality of token queues. The token queues respectively correspond to different services, and store tokens which are information of instances of services for the services respectively corresponding thereto. A rule storage unit (504) stores execution sequence adjustment rule information (5041) whereby an execution sequence adjustment rule for adjusting an execution sequence of the services is defined. A service execution standby evaluation unit (5011) determines whether the token is stored for each token queue, extracts as an execution candidate service the service for which the token is stored in the corresponding token queue, and, employing the execution sequence adjustment rule which is defined in the execution sequence adjustment rule information (5041), determines for each execution candidate service whether to execute the service or to defer the execution of the service.

Description

Information processing system

The present invention relates to a service cooperation technique for linking a plurality of services.
The present invention relates to a service cooperation technology that links a plurality of services used in, for example, a smart meter system.

The smart meter system controls the smart meter with communication function installed in each home from the central system of the electric power company, and periodically collects power meter readings and controls power supply (breaker open / close). Stem to perform.
The smart meter system is attracting attention as a technology for optimizing energy that enables the collected data to be disclosed to each home and detailed analysis of power usage.
A smart meter system is a concentrator (Data Concentrator Unit) (hereinafter referred to as a “DCU”) that collects a plurality of smart meters located near a smart meter (hereinafter also simply referred to as a “meter”), a telephone pole, etc. And a center system (hereinafter also referred to simply as “center”).
The smart meter and DCU are operated unattended.
In addition, the smart meter and the DCU perform communication using a communication network that is not very stable, such as a mobile phone communication network or a PLC (Power Line Communications) communication network.
Since the operation manager exists only in the center, all monitoring and operation must be performed in the center system.

In the smart meter system, it is necessary to process a plurality of applications in one center system.
Examples of applications processed by the center system include a periodic collection job, a meter monitoring control application, and an event detection application.
The periodic collection service is an application for the center system to periodically collect the electric energy and the abnormality flag indicated by the meter.
The meter monitoring control application is an application for issuing an instruction to the meter from the center system.
The event detection application is an application for detecting a power failure / recovery (resumption of power supply after a power failure) detected by a meter.

The load balance of the center system dynamically changes depending on scenes such as changes in demand, power outages, regional disasters, failures related to the power supply of individual households, and maintenance.
Therefore, it is necessary to adjust the load balance in the center system in consideration of the business and the system configuration, such as the priority of the business, the area where the meter is arranged, and whether or not the meter detects an abnormality.
For example, when a certain meter detects an abnormality such as a power failure during regular collection work, a power failure message is sent from the meter through the DCU and the event detection application operates.
Then, a power failure message is transmitted to the operation manager in the center, and the operation manager operates the meter monitoring control application to take a log acquisition from the meter and take measures to solve the failure.
At this time, it is necessary to execute the event detection application and the meter monitoring control application in preference to the regular collection work, and the regular collection work occupies the communication bandwidth with the DCU and meter, and the processing resources of the DCU and meter. In some cases, it is necessary to control such as temporarily suspending the periodic collection work.

The smart meter system is deployed in each home for a long period of time, such as 10 years, and is gradually increased for each area (DCU area).
Depending on the area, the communication network may not be enhanced due to local communication conditions.
For this reason, it is necessary to control the meter in a state where old and new configurations are mixed from the center, and different performance / priority control is required for each area.

Therefore, in consideration of priority control, it is necessary to provide a workload balance mechanism for computers and component devices on the smart meter system.
And the workload balance mechanism needs to be able to be expanded and changed according to the stepwise increase in each area.

In Patent Document 1, for each service included in a flow in an application, a service registry and priority information for each service are set by a service registry.
Further, in Patent Document 1, service matching in consideration of priority can be performed by the matching control unit controlling a computer that executes a service through an adapter.

JP 2008-186105 A

In Patent Document 1, only the computer group in the center is subject to priority control, and only the load balance between computers that execute services is adjusted according to the CPU (Central Processing Unit) load capacity of the computer group in the center. is there.
In the smart meter system, adjustment according to the priority and progress of the service (application) and priority control for components included in the smart meter system such as a meter, a DCU, and a communication device are necessary.
For example, when processing of a low priority service (application) and processing of a high priority service (application) for a specific meter overlap, processing of a low priority service (application) may be interrupted. Although necessary, the technique of Patent Document 1 cannot perform such control.
The smart meter system requires flexible control for determining the next service to be performed based on the status of the component, the priority of other services, the progress of other services, and the like.

The present invention has been made in view of the above, and can flexibly determine the execution of a service and the suspension of the execution of the service based on the status of the component, the priority of other services, the progress of other services, and the like. The main purpose is to do.

An information processing system according to the present invention includes:
An information processing system that manages the execution of multiple services,
A plurality of token storage units, each corresponding to a different service, each storing a token that is service instance information for the corresponding service;
An execution order adjustment rule information storage unit that stores execution order adjustment rule information in which execution order adjustment rules for adjusting the execution order of services are defined;
It is determined whether or not a token is stored for each token storage unit, a service in which the token is stored in the corresponding token storage unit is extracted as an execution candidate service, and the execution order adjustment rule information for each execution candidate service And a service execution determination unit that determines either the execution of the service or the suspension of the execution of the service using the execution order adjustment rule defined in (1).

In the present invention, either execution of a service or suspension of execution of a service is determined using execution order adjustment rule information in which an execution order adjustment rule is defined.
Therefore, based on the status of the component, the progress of other services, etc. by using the execution order adjustment rule reflecting the status of the component, the priority of other services, the progress of other services, etc. It is possible to flexibly determine service execution and service execution suspension.

1 is a diagram illustrating a configuration example of a smart meter system according to a first embodiment. FIG. 3 shows a configuration example of an ESB according to the first embodiment. FIG. 3 is a diagram illustrating an example of a routing file according to the first embodiment. FIG. 3 is a diagram illustrating an example of a token queue according to the first embodiment. FIG. 6 is a diagram illustrating an example of an execution order adjustment rule according to the first embodiment. FIG. 4 is a diagram illustrating an example of a movement rule according to the first embodiment. The figure which shows the example of the rule application corresponding | compatible table which concerns on Embodiment 1. FIG. FIG. 4 is a diagram illustrating an example of a load adjustment rule according to the first embodiment. FIG. 3 is a diagram for explaining a relationship between computers according to the first embodiment. FIG. 3 is a flowchart showing an operation example in the center system according to the first embodiment. FIG. 3 is a flowchart showing an operation example in the center system according to the first embodiment. FIG. 3 is a flowchart showing an operation example in the center system according to the first embodiment. The figure which shows the structural example of the smart meter system which concerns on Embodiment 2. FIG. The figure explaining the relationship between the flow rule substitution part which concerns on Embodiment 2, an adjustment rule, and a routing file. FIG. 10 is a diagram illustrating an example of a configuration / business parameter correspondence table according to the second embodiment. FIG. 10 is a diagram illustrating an example of a configuration selection rule according to the second embodiment. FIG. 10 is a diagram illustrating an example of a configuration selection rule according to the second embodiment. FIG. 9 shows a configuration example of a computer according to a third embodiment. FIG. 10 is a diagram illustrating an example of a routing file according to the third embodiment. FIG. 4 is a diagram showing a hardware configuration example of a computer according to the first to third embodiments.

Embodiment 1 FIG.
As described above, the technique of Patent Document 1 flexibly determines the service to be performed next based on the status of components such as a meter, DCU, and communication device, the priority of other services, the progress of other services, and the like. There is a problem that it cannot be determined (referred to as “Problem 1”).

In the technique of Patent Document 1, the priority parameter, service, and computer are fixed.
The smart meter system is gradually expanded for each area (DCU area) over a long period (for example, 10 years).
For this reason, the area where the new device is installed and the area where the old device is installed are mixed.
The equipment in the new area and the equipment in the old area differ in the communication network capacity, the number of connections that can be accepted by the DCU, the function of the meter, etc., and the constraint conditions for priority control differ.
For example, in the initial configuration, the number of meters in one DCU area is up to 1 million, and the DCU has low specifications, and only one thread is allowed for each communication.
Moreover, each meter is an AMR (Automated Meter Reading) system, and spontaneous communication is not performed.
In the initial configuration, the communication network is poor (for example, the communication network between the meter and the DCU is 192 KBps, and the communication network between the DCU and the center system is also 192 KBps), and priority control is required to effectively use the communication network. It is.
On the other hand, in the latter configuration, the number of meters in one DCU area can be more than 10 million, and the DCU has high specifications, and 10 threads are allowed for each communication.
Further, each meter is an AMI (Advanced Metering Infrastructure) system, and corresponds to HEMS (Home Energy Management System).
In the latter configuration, the communication network is enriched (for example, the communication network between the meter and the DCU is 192 KBps, and the communication network between the DCU and the center system is 100 MBps). However, it is necessary to use more resources on the center side than the initial configuration.
As described above, it is necessary to change the method of priority control and workload balance depending on the area and the equipment used. However, in the technique of Patent Document 1, the computer on the center, the priority parameter, and the service are fixed, and priority is given. There is a problem (referred to as “Problem 2”) that the method of control and workload balancing cannot be changed.

In the present embodiment, in addition to the business application flow, the application load adjustment is performed for the message linkage middleware (ESB: Enterprise Service Bus) that executes services and service flows arranged on the center system. Set adjustment rules.
This adjustment rule is set by the architecture developer with the component elements and service flow in mind.
In the adjustment rule, a rule that enables flexible priority control is defined.
Further, by defining the control for each DCU area generated by the stepwise expansion of the smart meter in the adjustment rule, the control for each DCU area can be separated from the application, and the development of the application can be made efficient.
In the present embodiment, a system linkage platform for executing business applications on a center computer arranged on the center system is realized as message linkage middleware (ESB) for realizing SOA (Service Oriented Architecture). .

SOA is a design method for constructing a system by combining a plurality of services.
A service is a set of software having a function of a meaningful unit and can be called from the outside by a standardized procedure.
Meaningful means something meaningful for business or for humans.
A series of processes configured by combining a plurality of services may be referred to as a process or a service flow.
In system construction based on SOA, it is common to use ESB.
The ESB is middleware that links an external system and a service and links between services.
In ESB, a message router (message bus) is provided, and messages are exchanged between the external system and the service or between the services through the message router, and the cooperation between the external system and the service or between the services is performed. Try to collaborate.

FIG. 1 shows a configuration example of a smart meter system according to the present embodiment.
A center system 1000 corresponding to an example of an information processing system includes a computer 1 (100), a computer 2 (200), and a computer 3 (300).
The computer 1 (100) and the computer 2 (200) of the center system 1000 are connected to a plurality of DCUs 404 via a multi-stage network 401, 402, 403.
A plurality of meters 405 and 406 are connected to the DCU 404.
The computer 1 (100) is also expressed as C1, and the computer 2 (200) is also expressed as C2.
The computer 1 (100) and the computer 2 (200) are also called servers.
Although FIG. 1 shows an example in which the center system 1000 is configured by three center computers, the number of computers in the center system 1000 is arbitrary.

In the center system 1000, the computer 1 (100) and the computer 2 (200) execute various services (periodic collection work, event detection application, meter monitoring control application, etc.).
The computer 3 (300) performs an operation for adjusting the workload balance of the computer 1 (100) and the computer 2 (200).
The computer 1 (100) and the computer 2 (200) have the same functional block configuration.
The computer 1 (100), the computer 2 (200), and the computer 3 (300) each include an ESB (ESB 106, ESB 206, ESB 305), and are linked by an ESB message router.
Then, services on other computers can be called to each other through the ESB message router.
The computers linked by the message router share a routing file described later.
In the routing file, a service flow indicating a service flow (hereinafter, “service flow” is also simply referred to as “flow”) is described.

The configurations of the computer 1 (100) and the computer 2 (200) will be described.
Since the computer 1 (100) and the computer 2 (200) have the same configuration, only the configuration of the computer 1 (100) will be described below.

The communication unit 101 communicates with the DCU 404 via the network 401 or the like.
The communication unit 101 communicates with the computer 2 (200) and the computer 3 (300).
The input / output unit 102 inputs an instruction from the operation manager (user), and outputs a process execution result and the like to the operation manager (user).
The service execution unit 103 executes service application code (code of an application program for realizing a service).
The service application code is stored in the storage unit 104.
The performance statistic update unit 105 totals the tokens in the token queue of the computer 1 (100), and transmits it to the computer 3 (300) as statistical information.
The token queue and token will be described later.
Details of the ESB 106 will be described later with reference to FIG.

In the computer 3 (300), the communication unit 301 communicates with the computer 1 (100) and the computer 2 (200).
The input / output unit 302 inputs an instruction from the operation manager (user), and outputs an execution result of the process to the operation manager (user).
The load adjustment instruction information generation unit 303 acquires statistical information from the performance statistics update unit 105, totals the number of tokens already accepted by the service execution unit 103, and calculates the number of tokens that the service execution unit 103 can further accept. Then, information notifying the calculated token number is output to the computer 1 (100) as load adjustment instruction information.
Similarly, the load adjustment instruction information generation unit 303 acquires statistical information from the performance statistics update unit 205, totals the number of tokens already accepted by the service execution unit 203, and the number of tokens that the service execution unit 203 can further accept. And outputs information notifying the calculated number of tokens to the computer 2 (200) as load adjustment instruction information.
Note that the load adjustment instruction information generation unit 303 corresponds to an example of a token number calculation unit.
The inter-computer statistics sharing unit 304 holds load adjustment rule information 3041.
The load adjustment rule information 3041 defines a load adjustment rule illustrated in FIG.

The load adjustment rule is a rule for making a decision for adjusting the load between the computer 1 (100) and the computer 2 (200).
In FIG. 8, “scene” is a system state set by the operation manager, and in the smart meter system, there are a normal time, a power failure, and the like.
In order to adjust the load of each computer according to the scene, the load adjustment rule information 3041 specifies the number of tokens that can be accepted and the ratio of tokens of each priority for each computer.
In FIG. 8, for example, in “computer: C1” of “scene: normal time”, the number of tokens that can be accepted subtracts the total number of tokens already accepted from 100, which is the upper limit number of tokens accepted. Value.
Similarly, in “computer: C1” of “scene: normal time”, 80% of the acceptable numbers are high priority tokens, 10% are medium priority tokens, and further 10% Is a low priority token.
The load adjustment instruction information generation unit 303 calculates the number of tokens that can be received by the service execution unit 103 and the service execution unit 203 by priority based on the load adjustment rule defined in the load adjustment rule information 3041.

Next, the details of the ESB 106 of the computer 1 (100) and the ESB 206 of the computer 2 (200) will be described with reference to FIG.
Since ESB 106 and ESB 206 have the same configuration, only the configuration of ESB 106 will be described below.
The ESB 106 includes a service control unit 501, a routing file storage unit 502, a token queue management unit 503, a rule storage unit 504, a message router 505, and an inter-ESB interface 506.
Note that the ESB 305 does not need to have the same configuration as that in FIG. 2, and may have at least the message router 505 and the inter-ESB interface 506.

The service control unit 501 adjusts the execution order of services and the workload balance.
The service control unit 501 includes a service execution standby evaluation unit 5011, another server migration unit 5012, a reception unit 5013, and a transmission unit 5014.
Details of the components of the service control unit 501 will be described later.

The routing file storage unit 502 stores a routing file.
In the example of FIG. 2, the routing file storage unit 502 stores three routing files P1 (5021), P2 (5022), and communication service (5023).
Each routing file has the contents shown in FIG. 3, for example.
As shown in FIG. 3, P1 (5021) is a routing file in which the flow of the regular collection work is shown.
In the flow of the routing file, a plurality of services are defined together with the execution order of the services.
In the routing file of P1 (5021), each of a1 to a5 corresponds to a service.
The details of the “a2: communication 1” service are defined in “communication 1: DCU periodic communication” of the communication service (5023).
Similarly, details of the “a3: communication 2” service are defined in “communication 2: meter communication” of the communication service (5023).
P2 (5022) is a routing file of the meter monitoring control application.
Also in the routing file of P2 (5022), each of b1 to b3 corresponds to a service.
In P1 (5021) and P2 (5022), “L”, “M”, and “H” described in the vicinity of each service indicate priorities.
That is, “L” means low priority, “M” means medium priority, and “H” means high priority.
The service priority is not uniform for each service flow.
In the example of FIG. 2, the services: a1 to a3 are “M” (medium priority) in the flow of P1 (5021), but for example, another service “P3” not shown in FIG. In the flow, the services: a1 to a3 may be “L” (low priority) or “H” (high priority).

The token queue management unit 503 is provided with a plurality of token queues.
Each token queue is a double-ended queue corresponding to a different service.
As shown in FIG. 2, the token queue 5031 corresponds to the service a1 and stores the token of the service a1.
Similarly, the token queue 5032 corresponds to the service a2 and stores the token of the service a2.
Each token queue corresponds to an example of a token storage unit.
The token is an object that holds and executes the execution information of the service application, and is information on the service instance.
The service is executed for each token.
Also, the priority of the service is set for the token.
In the token queue, as shown in FIG. 4, the token storage area is divided according to priority.
FIG. 4 illustrates the token queue 5032 of the service a2. The token queue 5032 is divided into a high priority, a medium priority, and a low priority.
The storage area by priority is also referred to as a priority queue.
In FIG. 4, a circle indicated by reference numeral 600 represents a token.
As described above, since the priority of the service is not uniform for each flow, it may occur that the priority of the service a2 is “medium” in one flow and “low” in another flow.

The rule storage unit 504 stores a plurality of rule information.
Specifically, the rule storage unit 504 stores execution order adjustment rule information 5041, movement rule information 5042, and a rule application correspondence table 5043.
Note that the rules described in the execution order adjustment rule information 5041, the movement rule information 5042, and the rule application correspondence table 5043 are collectively referred to as adjustment rules.
The execution order adjustment rule information 5041 defines one or more execution order adjustment rules for adjusting the execution order of services.
The movement rule information 5042 defines one or more movement rules for determining whether or not to move a token between computers.
The rule application correspondence table 5043 defines to which service of which flow described in the routing file the execution order adjustment rule and the movement rule are applied.

In the execution order adjustment rule information 5041, for example, an execution order adjustment rule shown in FIG. 5 is defined.
In the execution order adjustment rule information 5041, the content to be executed when the condition determination statement (if statement) is evaluated and the result of TRUE is obtained and the content to be executed when the result of FALSE is obtained are determined by the script language. is described.
In the execution order adjustment rule information 5041, for example, wait (), stop (), and receive () can be described as the contents to be executed on the result of evaluating the condition judgment expression (if statement).
wait () is an instruction for returning the token extracted from the token queue to the same token queue.
stop () is an instruction to return the token taken out from the token queue to the same token queue and to stop taking out from the token queue.
receive () is a command that causes the reception unit 5103 to send the token extracted from the token queue.
The token sent to the receiving unit 5103 by receive () is sent to the service execution unit 103 by the receiving unit 5013, and the service execution unit 103 executes the service application code of the corresponding service based on the token.
wait () and stop () are instructions for suspending execution of the service of the token extracted from the token queue, and receive () is an instruction for starting execution of the service of the token extracted from the token queue.

In the execution order adjustment rule of FIG. 5, a priority service that is preferentially executed is defined, and a rule that a service other than the priority service is executed when a token is not stored in the token queue of the priority service is defined. ing.
The execution order adjustment rule of FIG. 5 has a rule ID (Identifier) of R1, and in the rule application correspondence table 5043 (FIG. 7), the execution order of services “a1”, “a2”, and “a3” of the flow “P1”. Since it is defined that the adjustment rule (ID: R1) is applied, the if statement in FIG. 5 is evaluated when the tokens of the services “a1”, “a2”, and “a3” are extracted from the token queue. The
In the execution order adjustment rule of FIG. 5, the services “Preparation 2”, “Communication 2”, and “MDM3” of the flow “Meter monitoring control” are defined as the priority services, and the token of the priority service exists in the token queue. If so, the tokens of services “a1”, “a2”, and “a3” are returned to the token queue (wait).
On the other hand, if there is no token for the priority service, tokens for services “a1”, “a2”, and “a3” are sent to the receiving unit 5013 (receive).
As described above, in the execution order adjustment rule information 5041, the adjustment rule for the service execution order is the service attribute (in the case of FIG. 5, the service “preparation 2”, “communication 2”, “ Attribute MDM3 ”).

FIG. 5 shows an example of the execution order adjustment rules described in the execution order adjustment rule information 5041, and rules using other evaluation criteria may be used.
For example, an execution order adjustment rule that the service of the token with the highest priority is executed may be defined.
In addition, an execution order adjustment rule associated with a DCU area related to service execution may be defined.
For example, an execution order adjustment rule may be defined in which a service that collects data from another area can be executed only when there is no token for the service that collects data from the DCU area A.
In addition, an execution order adjustment rule associated with the load (number of tokens) of the computer to be evaluated (for example, computer 1 (100)) and the load (number of tokens) of another computer (for example, computer 2 (200)) is defined. It may be.
Furthermore, it may be an execution order adjustment rule in which a condition judgment expression including the object variable of the load adjustment rule information 3041 (FIG. 8) described above is included as an evaluation criterion.
The load adjustment rule information 3041 is rule information for adjusting load balance between computers.
Different execution order adjustment rules may be used for each DCU area.

In the movement rule information 5042, for example, a movement rule shown in FIG. 6 is defined.
In the movement rule information 5042, the contents to be executed when the condition determination sentence (if sentence) is evaluated and the TRUE result is obtained and the contents to be executed when the FALSE result is obtained are described in a script language. ing.
In the execution order adjustment rule information 5041, for example, sendTo () and leave () can be described as the contents to be executed on the result of evaluating the condition judgment expression (if statement).
sendTo () is an instruction to move a token taken out from a token queue of a certain computer (for example, computer 1 (100)) to a token queue of another computer (for example, computer 2 (200)).
Leave () does not move the token taken out from the token queue of a certain computer (for example, computer 1 (100)) to the token queue of another computer (for example, computer 2 (200)), but instead of that computer (for example, computer 1 ( 100)) to return to the token queue.

In the movement rule of FIG. 6, a priority service that is executed with priority is defined, and a token is moved from a computer that stores a token for the priority service to another computer that does not store a token for the priority service. Is defined.
The migration rule in FIG. 6 has a rule ID of R2, and the rule application correspondence table 5043 (FIG. 7) stipulates that the migration rule (ID: R2) is applied to all services.
That is, the if statement in FIG. 6 is evaluated when all service tokens are taken out of the token queue.
In the movement rule of FIG. 6, the services “Preparation 2”, “Communication 2”, and “MDM3” of the flow “Meter monitoring control” are defined as the priority services, and the token of the priority service exists in the computer 1 (100). If the token of the priority service does not exist in the computer 2 (200), the token taken out in the computer 1 (100) is moved to the computer 2 (200) token queue (sendTo).
On the other hand, if the above condition is not satisfied, the token taken out by the computer 1 (100) is returned to the original token queue (leave).
As described above, in the movement rule information 5042, the token movement rule indicates the service attribute (in the case of FIG. 6, the attributes “service“ preparation 2 ”,“ communication 2 ”, and“ MDM3 ”in the flow“ meter monitoring control ”). Defined in relation to.
Further, in the migration rule information 5042, a computer having a priority service token is defined as a token migration source, and a computer having no priority service token is defined as a token migration destination.

FIG. 6 shows an example of the execution order adjustment rule information 5041, which may be a movement rule using other evaluation criteria.
For example, a movement rule may be defined in which a token having a priority level lower than a specific level is moved to another computer.
In addition, a movement rule associated with a DCU area related to service execution may be defined.
For example, a movement rule for moving a token of a service that collects data from the DCU area A to another computer may be defined.
In addition, a movement rule is defined that associates the load (number of tokens) of the computer to be evaluated (for example, computer 1 (100)) with the load (number of tokens) of another computer (for example, computer 2 (200)). Also good.
Furthermore, it may be execution order adjustment rule information 5041 in which a condition judgment expression including the object variable of the load adjustment rule information 3041 (FIG. 8) described above is included as an evaluation criterion.
Different movement rules may be used for each DCU area.

The message router 505 is a message bus that allows a service to communicate without being aware of a communication protocol or the like.
The inter-ESB interface 506 provides an interface between ESBs.

The service control unit 501 is configured for each ESB service and is a function that performs cooperation and priority control between services when executing a flow according to a routing file.
For example, the service control unit 501 determines the start of execution of the service or suspension of execution for each token, and moves the token to another computer for load balance adjustment according to priority control.

FIG. 9 shows the relationship between each element of the service control unit 501 and the adjustment rule, and the relationship between each element of the service control unit 501 and other elements.

The service execution standby evaluation unit 5011 determines whether to execute the service for each token or not to execute in standby mode according to the adjustment rule.
The service execution standby evaluation unit 5011 extracts the first token from the token queue for each token queue, and mainly refers to the execution order adjustment rule information 5041 and the rule application correspondence table 5043 as illustrated in FIG. The execution of the service corresponding to or the suspension of execution of the service is determined.
The service execution standby evaluation unit 5011 corresponds to an example of a service execution determination unit.

The other server moving unit 5012 moves the token to another computer based on the determination according to the adjustment rule.
The other server moving unit 5012 takes out the token from the tail end of the token queue for each token queue, and mainly refers to the moving rule information 5042 and the rule application correspondence table 5043, and puts the taken out token into the token queue of another computer. It is determined whether or not to move, and when it is determined to move the token, the token to be moved is moved to the token queue of another computer.
The other server moving unit 5012 corresponds to an example of a token moving unit.

In addition, the service execution standby evaluation unit 5011 may determine whether to execute the service or wait for execution with reference to the load adjustment instruction information 702 according to the execution order adjustment rule described in the execution order adjustment rule information 5041. is there.
The other server moving unit 5012 may determine whether to move the token to another computer with reference to the load adjustment instruction information 702 according to the movement rule described in the movement rule information 5042. .
The load adjustment instruction information 702 is information generated by the load adjustment instruction information generation unit 303.
In the load adjustment instruction information 702, the computer statistical information includes, for example, the number of tokens that can be received by the service execution unit (for example, the service execution unit 103 of the computer 1 (100)) in which the service execution standby evaluation unit 5011 is mounted. Is information indicated by priority.
The inter-server adjustment information is information indicating, for example, the number of tokens for which services are being executed by another computer (for example, computer 2 (200)) and the number of tokens in the token queue according to priority.
By referring to the load adjustment instruction information 702, the service execution standby evaluation unit 5011 can determine the load level of its own computer and the load level of another computer, and can determine whether to execute the service or wait for execution. .
Further, the other server moving unit 5012 refers to the load adjustment instruction information 702 to determine the load level of the own computer and the load level of the other computer, and determines whether or not to move the token to the other computer. Can be determined.
The load adjustment instruction information generation unit 303 generates load adjustment instruction information 702 using the computer statistical information 701 and the load adjustment rule information 3041 generated by the performance statistics update unit 105 of each computer.
In the server execution load statistics included in the computer statistical information 701, the number of tokens for which services are being executed is indicated by priority.
In the service request load statistics, the number of tokens in the token queue is indicated by priority.
As illustrated in FIG. 8, the load adjustment rule information 3041 is information in which the number of tokens that can be accepted and the ratio of tokens of each priority are designated for each computer.

The receiving unit 5013 acquires the token whose service execution has been determined by the service execution standby evaluation unit 5011 from the service execution standby evaluation unit 5011, outputs the acquired token to the service execution unit 103, and provides the service execution unit 103 with the service. Run application code.

The transmission unit 5014 acquires the token after the execution result of the service application code of the service execution unit 103 is stored, and transmits the acquired token to the message router 505.
Note that the message router 505 to which the token is sent from the transmission unit 5014 passes the token of the service to be executed next to the transmission unit 5014 in accordance with the routing file (FIG. 3).
The transmission unit 5014 stores the token passed from the message router 505 in the token queue of the corresponding service.

The normal ESB service control function is composed of an internal queue of a single message router, a function corresponding to the reception unit 5013, a function corresponding to the transmission unit 5014, and a service application code, and a token extracted from the internal queue. Only the service application is executed and passed to the message router, and there is no function to perform token priority control, transfer to another server, or service execution standby according to the adjustment rules.

Next, the operation of the center system 1000 of this embodiment will be described.
10 and 11 show a flow of operations in which the service execution standby evaluation unit 5011 extracts a token from the queue and determines execution or standby of the service using the execution order adjustment rule information 5041.
Note that the service execution standby evaluation unit 5011 performs the operations of FIGS. 10 and 11 for each token queue (that is, for each service).

In st11, the service execution standby evaluation unit 5011 investigates whether or not a token is included in each priority queue of the token queue.

In st12, the service execution standby evaluation unit 5011 ends the process when there is no priority queue including the token.
On the other hand, if there is a priority queue including a token, the process proceeds to st13.
A service having a priority queue that includes a token corresponds to an example of an execution candidate service.

In st13, the service execution standby evaluation unit 5011 selects the highest priority queue from the priority queues including the token, and the subsequent processing is performed on the selected priority queue.

In st14, the first token in the priority queue selected in st13 is taken out.

In st15, the service execution standby evaluation unit 5011 examines the rule application correspondence table 5043, and whether an execution order adjustment rule to be applied to the current target service is defined in the rule application correspondence table 5043 (the rule for the service name) Whether the ID is defined).

In st16, when there is no execution order adjustment rule to be applied to the currently targeted service, the service execution standby evaluation unit 5011 transits to st113.
On the other hand, when there is a rule to apply, the service execution standby evaluation unit 5011 transits to st17.

In st17, the service execution standby evaluation unit 5011 generates an object variable for the execution order adjustment rule.

In st18, the service execution standby evaluation unit 5011 evaluates the conditional expression of the rule content corresponding to the rule ID.

In st19, the service execution standby evaluation unit 5011 selects a function according to the evaluation result of the conditional expression.

In st110, the service execution standby evaluation unit 5011 transitions to st111 when wait () is selected, transitions to st112 when stop () is selected, and transitions to st113 when receive () is selected. .

In st111, the service execution standby evaluation unit 5011 puts the token extracted in st14 in the head of the priority queue of the extraction source in order to wait for the execution of the service.

In st112, the service execution standby evaluation unit 5011 puts the token extracted in st14 at the head of the priority queue of the extraction source, and stops subsequent token extraction from the priority queue of the extraction source.

In st113, the service execution standby evaluation unit 5011 transmits the extracted token to the reception unit 5013, and the reception unit 5013 receives the token.

In st114, the receiving unit 5013 transmits the token to the service execution unit 103, and the service execution unit 103 accepts the token and executes the service application code of the corresponding service.

In st115, the service execution unit 103 stores the execution result of the service application code in a token.

In st116, the service execution unit 103 transmits the token to the transmission unit 5014, and the transmission unit 5014 transmits the token to the message router 505.

In st117, the message router 505 determines the next service from the routing file, and the transmission unit 5014 stores the token of the next service in the priority queue of the corresponding token queue.

FIG. 12 shows a flow of operations in which the other server moving unit 5012 takes out the token from the queue and determines whether or not to move the token using the movement rule information 5042.
The other server moving unit 5012 performs the operation of FIG. 12 for each token queue (that is, for each service).

In st21, the other server moving unit 5012 investigates whether or not a token is included in each priority queue of the token queue.

In st22, the other server moving unit 5012 ends the process when there is no priority queue including the token.
On the other hand, if there is a priority queue including a token, the process proceeds to st23.

In st23, the other server moving unit 5012 selects the highest priority queue from the priority queues including the token, and the subsequent processing is performed on the selected priority queue.

In st24, the last token of the priority queue selected in st23 is taken out.

In st25, the other server moving unit 5012 examines the rule application correspondence table 5043, and whether the migration rule to be applied to the current target service is defined in the rule application correspondence table 5043 (rule ID is defined for the service name) Is determined).

In st26, when there is no migration rule to be applied to the current target service, the other server migration unit 5012 transitions to st30.
On the other hand, when there is a rule to apply, the service execution standby evaluation unit 5011 transits to st27.

In st30, the other server moving unit 5012 returns the token extracted in st24 to the same position in the priority queue of the extraction source, and extracts the token immediately before the token extracted in st24.
Thereafter, the other server moving unit 5012 repeats the operations of st25 and st26.

In st27, the other server moving unit 5012 generates an object variable of the movement rule.

In st28, the other server moving unit 5012 evaluates the conditional expression of the rule content corresponding to the rule ID.

In st29, the other server moving unit 5012 selects a function according to the evaluation result of the conditional expression.

In st210, the other server moving unit 5012 transitions to st211 when sendTo () is selected, and transitions to st212 when leave () is selected.

In st211, the other server moving unit 5012 moves the token to the token queue of the computer specified by the movement rule.

In st212, the other server moving unit 5012 returns the token extracted in st24 to the same position in the priority queue from which it was extracted.

The effect of the first embodiment will be described.
According to the first embodiment, the load can be adjusted with the granularity of service execution of the routing flow.
Then, the queue-based priority control using the adjustment rule enables flexible priority processing that takes into account the case where there is a priority service as the subsequent processing.
Also, in this embodiment, it is possible to adjust the load according to the scene while making a situation determination using the conditional expression of the adjustment rule, instead of adjusting the load balance only with the CPU load and the single service priority. Become.
For this reason, the problem 1 can be solved.

Embodiment 2. FIG.
FIG. 13 shows a configuration example of the smart meter system according to the second embodiment.
Compared to the configuration of FIG. 1, in FIG. 13, a flow rule replacement unit 107 is added to the computer 1 (100), and a flow rule replacement unit 207 is added to the computer 2 (200).
Other elements in FIG. 13 are the same as those in FIG.
The flow rule replacement unit 107 and the flow rule replacement unit 207 replace the flow of the routing file to be executed and the adjustment rule with different ones based on the business parameters when the smart meter application is activated.
Since the operations of the flow rule replacement unit 107 and the flow rule replacement unit 207 are the same, the operation of the flow rule replacement unit 107 will be described below.

FIG. 14 is a diagram for explaining the operation of the flow rule replacement unit 107.
In the present embodiment, it is assumed that there are a plurality of variations in the processing algorithm for realizing a certain service.
A service having a plurality of variations in the processing algorithm is referred to as a special service.
In the example of FIG. 14, “communication 1” is a special service.
There are two processing algorithms, “DCU communication replacement flow A” and “DCU communication replacement flow B”, as processing algorithms for realizing the “communication 1” service.
For example, the flow rule replacing unit 107 inputs a service flow start request of “P1: periodic collection” from the user and business parameters related to the service flow of “P1: periodic collection”.
Here, it is assumed that the business parameter input by the flow rule replacement unit 107 is the DCU ID.
Based on the input business parameter (DCU ID) and the business parameter rule / flow replacement setting file, the flow rule replacement unit 107 performs “DCU communication replacement flow” for “Communication 1” of “P1: Periodic collection”. A ”or“ DCU communication replacement flow B ”is selected.
Then, the service execution unit 103 performs “communication 1” according to the processing algorithm (“DCU communication replacement flow A” or “DCU communication replacement flow B”) selected by the flow rule replacement unit 107 in “P1: periodic collection”. Service.
In the present embodiment, “adjustment rule A” and “adjustment rule B” are set for “communication 1” of “P1: periodic collection”.
Based on the input business parameter (DCU ID) and the business parameter rule / flow replacement setting file, the flow rule replacement unit 107 sets “adjustment rule A” for “communication 1” of “P1: periodic collection”. Alternatively, “adjustment rule B” is selected.
Then, the service execution standby evaluation unit 5011 applies the adjustment rule (“adjustment rule A” or “adjustment rule B”) selected by the flow rule replacement unit 107 to the token of “communication 1”, The start or standby of the “communication 1” service is determined.
The other server moving unit 5012 applies the adjustment rule (“adjustment rule A” or “adjustment rule B”) selected by the flow rule replacement unit 107 to the token of “communication 1”, It is determined whether or not to move the token of “communication 1” to another computer.
The flow rule replacement unit 107 corresponds to an example of a start request input unit, an algorithm selection unit, and a rule selection unit.

FIG. 15 shows an example of a configuration / business parameter correspondence table included in the business parameter rule / flow replacement setting file.
16 and 17 show examples of configuration selection rules included in the business parameter rule / flow replacement setting file.
FIG. 15 shows configurations A and B, and it is defined that “adjustment rule A” is used for configuration A and “DCU communication replacement flow A” is used.
Further, it is defined that “adjustment rule B” is used for configuration B, and “DCU communication replacement flow B” is used.
The configuration selection rule in FIG. 16 defines that “configuration A” is selected if the ID of the DCU input as the business parameter is “0” to “1000”.
On the other hand, the configuration selection rule in FIG. 17 defines that “configuration B” is selected when the ID of the DCU input as the business parameter is from “1001” to “10000”.
In this way, the flow rule replacement unit 107 performs “DCU communication replacement flow” for the service “communication 1” based on the input business parameter (DCU ID) and the business parameter rule / flow replacement setting file. A ”or“ DCU communication replacement flow B ”is selected, and“ adjustment rule A ”or“ adjustment rule B ”is selected.

Next, the effect of Embodiment 2 is demonstrated.
The flow rule replacement unit 107 can switch the adjustment rule and the flow of the routing file at the start of the flow according to the service parameter.
When a DCU area (DCU ID) is used as a parameter, priority control and workload balance suitable for each area can be performed by switching the rule depending on the area.
For this reason, the problem 2 can be solved.

Embodiment 3 FIG.
FIG. 18 shows a configuration example of the computer 3 (300) of the third embodiment.
In the present embodiment, the configuration other than the computer 3 (300) is the same as that in FIG.
Compared with the configuration of the computer 3 (300) shown in FIG. 1 or FIG. 13, a system configuration reservation management unit 306, a system component reservation service 307, and system configuration reservation information 308 are added in FIG.
The system configuration reservation management unit 306 manages the usage status of system components other than the center system 1000 among the system components in the smart meter system between services, and manages whether each system component can be used.
The system component reservation service 307 holds information on the usage status of each system component other than the center system 1000.
The system configuration reservation information 308 is a service for changing the usage status of system components other than the center system 1000.
In the present embodiment, the routing file illustrated in FIG. 19 is used.
Compared with the communication service flow 5023 of FIG. 3, the communication reservation is performed in the communication service flow 5024 of FIG.
Further, the routing file of FIG. 19 includes a system component reservation service for communication reservation with the DCU, the communication device, and the meter.

In the present embodiment, in the execution order adjustment rule information 5041, for example, when a system component reservation service is defined as a priority service, and a token of the system component reservation service does not exist, a service other than the system component reservation service It is possible to describe an execution order adjustment rule that is executed.
With this execution order adjustment rule, the system component reservation service is executed with priority over other services.

The effect of the third embodiment will be described.
The system configuration reservation management unit 306, the system component reservation service 307, and the system configuration reservation information 308 enable priority control in consideration of system components other than the center system 1000.
That is, priority control is possible not only for applications on the center system 1000 but also for system components included in the smart meter system such as meters, DCUs, and communication devices.

As described above, in the first to third embodiments, the service cooperation apparatus using the message cooperation middleware (ESB) for executing the service and the service flow in the smart meter system has been described.
In Embodiments 1 to 3, in addition to the business application flow, the service execution function and the ESB container adjustment function are provided for the purpose of adjusting the load of individual applications in consideration of components and flows. A service cooperation device with priority control has been described.

The service execution function has been described as having the following functions.
1) Flow definition defining service flow, routing file including system component reservation service, and ESB bus controlled by the routing file 2) Service control function for calling service application logic configured by the following functions a ) Priority queue that holds service instances as tokens for each priority b) Whether to take out the token from the tail of the priority queue, evaluate it using the adjustment rule setting file and load adjustment instruction information, and move to another server C) Service for determining whether to execute a service or to wait without executing it, taking out a token from the head of the priority queue and evaluating it using the adjustment rule setting file and load adjustment instruction information Execution wait evaluation function d) Service execution wait Receiving function that receives a token from the machine evaluation function and executes the service application code e) A transmission function that generates a token after execution from the result of the service application code and makes a transition to the next service 3) The entire computer of the system linkage server Self-server performance statistics update function that collects performance information (such as CPU load) and statistical information on tokens on the priority queue of each service and sends them to computer statistical information of the ESB container coordination function

Moreover, it demonstrated that the adjustment function between containers between ESBs has the following functions.
1) Inter-computer statistical sharing function for sharing computer statistical information including server execution load statistics and service request load statistics for each server with multiple ESBs 2) From inter-computer statistical sharing function and system component reservation service, A load adjustment instruction generation function for creating a load adjustment instruction message for the system linkage computer.

In the first to third embodiments, it has been described that the service execution function has the following functions.
According to the business parameter rule / flow replacement setting file, a flow for switching a flow to be started in accordance with parameters such as a token area to be executed (DCU area) from a parameter at the start of the flow such as a token area to be executed (DCU area).・ Rule replacement function.

In the first to third embodiments, it has been described that the inter-ESB container adjustment function has the following functions.
System configuration reservation information including the configuration and usage status of smart meter devices, a system configuration reservation management function for managing system configuration reservation information, and a system component reservation service for system configuration reservation from an application.

Finally, a hardware configuration example of the computer 1 (100), the computer 2 (200), and the computer 3 (300) shown in the first to third embodiments will be described with reference to FIG.
Hereinafter, a hardware configuration example of the computer 1 (100) will be described. However, the following description is applicable to the computer 2 (200) and the computer 3 (300).
The computer 1 (100) is a computer, and each element of the computer 1 (100) can be realized by a program.
As a hardware configuration of the computer 1 (100), an arithmetic device 901, an external storage device 902, a main storage device 903, a communication device 904, and an input / output device 905 are connected to the bus.

The arithmetic device 901 is a CPU that executes a program.
The external storage device 902 is, for example, a ROM (Read Only Memory), a flash memory, or a hard disk device.
The main storage device 903 is a RAM (Random Access Memory).
The communication device 904 is a communication card, for example.
The input / output device 905 is, for example, a mouse, a keyboard, a display device, or the like.
The “storage unit 104”, “routing file storage unit 502”, “token queue management unit 503”, and “rule storage unit 504” described in the first to third embodiments are the external storage device 902 or the main storage device 903. Realized.

The program is normally stored in the external storage device 902, and is loaded into the main storage device 903 and sequentially read into the arithmetic device 901 and executed.
The program is described as “˜unit” shown in FIG. 1 (except for “storage unit 104”, “routing file storage unit 502”, “token queue management unit 503”, and “rule storage unit 504”). It is a program that realizes the function.
Further, an operating system (OS) is also stored in the external storage device 902. At least a part of the OS is loaded into the main storage device 903, and the arithmetic device 901 executes “OS” shown in FIG. ”Is executed.
The service application code is also stored in the external storage device 902, and is executed by the arithmetic device 901 sequentially in a state loaded in the main storage device 903.
In the description of the first to fourth embodiments, “determination”, “determination”, “determination”, “extraction”, “examination”, “evaluation”, “ Execution ”,“ Settings ”,“ Registering ”,“ Selecting ”,“ Generating ”,“ Inputting ”,“ Outputting ”,“ Receiving ”,“ Sending ” The information, data, signal values, and variable values indicating the results of the processing described as “etc.” are stored in the main storage device 903 as files.
In addition, data received from the DCU or meter is stored in the main storage device 903 or the external storage device 902.
Further, the encryption key / decryption key, random number value, and parameter may be stored in the main storage device 903 as a file.

The configuration in FIG. 20 is merely an example of the hardware configuration of the computer 1 (100). The hardware configuration of the computer 1 (100) is not limited to the configuration illustrated in FIG. There may be.

100 computer 1, 101 communication unit, 102 input / output unit, 103 service execution unit, 104 storage unit, 105 performance statistics update unit, 106 ESB, 107 flow rule replacement unit, 200 computer 2, 201 communication unit, 202 input / output unit , 203 Service execution unit, 204 Storage unit, 205 Performance statistics update unit, 206 ESB, 207 Flow rule replacement unit, 300 Computer 3, 301 Communication unit, 302 Input / output unit, 303 Load adjustment instruction information generation unit, 304 Between computers Statistics sharing unit, 305 ESB, 306 system configuration reservation management unit, 307 system component reservation service, 308 system configuration reservation information, 401 network, 402 network, 403 network, 404 DCU, 405 meter, 406 meter 501 Service control unit, 502 Routing file storage unit, 503 Token queue management unit, 504 Rule storage unit, 505 Message router, 506 Inter-ESB interface, 1000 Center system, 3041 Load adjustment rule information, 5011 Service execution standby evaluation unit, 5012, etc. Server move unit, 5013 receive unit, 5014 send unit, 5031 token queue, 5032 token queue, 5033 token queue, 5034 token queue, 5034 token queue, 5036 token queue, 5041 execution order adjustment rule information, 5042 move rule information, 5043 rule Application table.

Claims (15)

1. An information processing system that manages the execution of multiple services,
   A plurality of token storage units, each corresponding to a different service, each storing a token that is service instance information for the corresponding service;
   An execution order adjustment rule information storage unit that stores execution order adjustment rule information in which execution order adjustment rules for adjusting the execution order of services are defined;
   It is determined whether or not a token is stored for each token storage unit, a service in which the token is stored in the corresponding token storage unit is extracted as an execution candidate service, and the execution order adjustment rule information for each execution candidate service An information processing system comprising: a service execution determination unit that determines either service execution or service execution suspension using an execution order adjustment rule defined in 1.
2. The execution order adjustment rule information storage unit
   Execution order adjustment rule stores execution order adjustment rule information defined in association with service attributes,
   The service execution determination unit
   For each execution candidate service, the verification of the execution candidate service attribute and the execution order adjustment rule of the execution order adjustment rule information, and the verification of the other execution candidate service attribute and the execution order adjustment rule of the execution order adjustment rule information Do at least one,
   The information processing apparatus according to claim 1, wherein for each execution candidate service, one of service execution and service execution suspension is determined.
3. The execution order adjustment rule information storage unit is
   Execution in which an execution order adjustment rule is defined in which a priority service to be executed is indicated and a service other than the priority service is executed when no token is stored in the token storage unit of the priority service Store order adjustment rule information,
   The service execution determination unit
   When a token is stored in the token storage unit of the priority service, determine execution of the priority service extracted as an execution candidate service, determine suspension of execution of execution candidate services other than the priority service,
   3. The information processing system according to claim 1, wherein when a token is not stored in the token storage unit of the priority service, execution of an execution candidate service other than the priority service is determined.
4. Each token store is
   Stores tokens with priorities set,
   The execution order adjustment rule information storage unit is
   Stores execution order adjustment rule information in which an execution order adjustment rule that the service of the token having the highest priority is executed among two or more tokens stored in two or more token storage units is stored. ,
   The service execution determination unit
   Check the priority of the token stored in the corresponding token storage unit for each extracted execution candidate service,
   Determine the execution of the execution candidate service with the highest token priority,
   The information processing system according to any one of claims 1 to 3, wherein the suspension of execution of another execution candidate service is determined.
5. Each token store is
   Storing tokens with priority-specific storage areas and priorities set in the corresponding priority storage areas,
   The service execution determination unit
   For each execution candidate service, the storage area with the highest priority is selected from the storage areas by priority of the corresponding token storage unit, and the storage area storing the token is stored at the top of the selected storage area. Extract the tokens
   5. The information processing system according to claim 1, wherein execution of a service for the extracted token or suspension of execution of the service is determined.
6. The information processing system further includes:
   A service execution unit that accepts a token of the service determined to be executed by the service execution determination unit, and executes a service corresponding to the received token;
   A token number calculating unit for counting the number of tokens already accepted by the service execution unit and calculating the number of tokens further accepted by the service execution unit;
   The service execution determination unit
   Using the execution order adjustment rule of the execution order adjustment rule information and the token number calculated by the token number calculation unit and further acceptable by the service execution unit, service execution and service for each execution candidate service The information processing system according to any one of claims 1 to 5, wherein one of the suspension of execution of the information is determined.
7. Each token store is
   Stores tokens with priorities set,
   The token number calculation unit
   The number of tokens already accepted by the service execution unit is aggregated by priority, and the number of tokens further accepted by the service execution unit is calculated by priority,
   The service execution determination unit
   For each execution candidate service, a token that matches a predetermined condition is extracted from the corresponding token storage unit,
   For each execution candidate service, the priority of the extracted token, the execution order adjustment rule of the execution order adjustment rule information, and the priority calculated by the token number calculation unit and further accepted by the service execution unit The information processing system according to claim 6, wherein either the service execution or the service execution suspension is determined using the token number.
8. The information processing system further includes:
   A start request input unit for inputting a service flow start request including a plurality of services and inputting parameters related to the service flow;
   In the case where the service flow requested to start includes a special service having a plurality of types of variations in the processing algorithm, based on the parameters input by the start request input unit, the plurality of processing algorithms of the special service An algorithm selection unit for selecting a specific processing algorithm from the inside;
   The service execution unit
   8. The information processing system according to claim 6, wherein the special service is executed according to a processing algorithm selected by the algorithm selection unit.
9. The execution order adjustment rule information storage unit is
   Stores execution order adjustment rule information in which multiple execution order adjustment rules are defined,
   The information processing system further includes:
   A start request input unit for inputting a service flow start request including a plurality of services and inputting parameters related to the service flow;
   Based on the parameters input by the start request input unit for a specific service included in the service flow for which the start request has been made, from among a plurality of execution order adjustment rules defined in the execution order adjustment rule information A rule selection unit for selecting a specific execution order adjustment rule;
   The service execution determination unit
   When the specific service is extracted as the execution candidate service, using the execution order adjustment rule selected by the rule selection unit, either execution of the service or suspension of execution of the service is performed for the specific service. 9. The information processing system according to claim 1, wherein the information processing system is determined.
10. An information processing system that manages the execution of multiple services,
    A plurality of service execution units each executing a service;
    A plurality of token storage units, each of which corresponds to a different service execution unit, each storing a token which is service instance information;
    A movement rule information storage unit for storing movement rule information in which token movement rules are defined;
    Based on the movement rule defined in the movement rule information, for each service execution unit, decide whether or not to move the token stored in the corresponding token storage unit to the token storage unit of another service execution unit And a token moving unit that moves the token stored in the token storage unit of the service execution unit that has decided to move the token to the token storage unit of another service execution unit.
11. The movement rule information storage unit
    The token movement rule stores movement rule information defined in association with service attributes,
    The token moving unit is
    For each service execution unit, the token stored in the corresponding token storage unit is matched with the attribute of the service to which the token corresponds and stored in the token storage unit of the other service execution unit. Performing at least one of the matching of the attribute of the service supported by the token and the movement rule of the movement rule information,
    The information processing according to claim 10, wherein for each service execution unit, it is determined whether or not to move a token stored in a corresponding token storage unit to a token storage unit of another service execution unit. apparatus.
12. The movement rule information storage unit
    The priority service to be executed with priority is indicated, and the token of the priority service is not stored in the corresponding token storage unit from the service execution unit in which the token of the priority service is stored in the corresponding token storage unit In the service execution part of, the movement rule information that defines the movement rule that moves the token is stored,
    The token moving unit is
    The service execution unit in which the token of the priority service is stored in the corresponding token storage unit is extracted as the movement source service execution unit, and the service execution unit in which the token of the priority service is not stored in the corresponding token storage unit Extract as the destination service execution part,
    The information according to claim 10 or 11, wherein any token stored in the token storage unit of the source service execution unit is transferred to the token storage unit of the destination service execution unit. Processing system.
13. The token moving unit is
    The token stored in the tail end of the token storage unit of the source service execution unit is moved to the token storage unit of the destination service execution unit. The information processing system described.
14. Each service execution unit
    Sequentially accept tokens stored in the corresponding token store, execute the service corresponding to the received token,
    The information processing apparatus further includes:
    Each service execution unit has a token number calculation unit that totals the number of tokens already accepted and each service execution unit further calculates the number of tokens that can be accepted,
    The token moving unit is
    A token storage unit corresponding to each service execution unit using the movement rule defined in the movement rule information and the number of tokens calculated by the token number calculation unit and further acceptable by each service execution unit. The information processing system according to any one of claims 10 to 13, wherein it is determined whether or not to move the token stored in the token storage unit of another service execution unit.
15. Each token store is
    Stores tokens with priorities,
    The token number calculation unit
    Aggregate the number of tokens that each service execution unit has already accepted by priority, calculate the number of tokens that each service execution unit can accept further by priority,
    The token moving unit is
    Stored in the transfer rule defined in the transfer rule information, the number of tokens by priority calculated by the token number calculation unit, which can be further accepted by each service execution unit, and the token storage unit of each service execution unit For each service execution unit, it is determined whether to move the token stored in the corresponding token storage unit to the token storage unit of another service execution unit The information processing system according to claim 14.

Images