JP2001147811A - Method activation system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To optimize method activation, and to obtain a processed result by the method in real time by an efficient use of computer resources. SOLUTION: An object execution environment part 1 manages a method activation method by request scheduling preliminarily expected for each class as a class policy regardless of a client 3 and a server 4. At the time of the request scheduling of the server 4, a request queue managing part 402 of the server 4 compares a request stored in a request queue table 403 with the class policy, and instructs method activation to a request dispatch part 404 according to a method based on the class policy. Thus, it is possible to realize a method activation for guaranteeing real time performance different for each class.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a server having an object which is a unit encapsulating data and a method. The server that has transmitted and received this information, once accumulates the request in a queue, analyzes the queued requests in order of, for example, the one with the oldest registration time, and starts the method activation of the corresponding object from the result. The present invention relates to a method invocation method of a distributed object-oriented system for realizing a client / server type application that performs a processing result of this method and returns a processing result of the method as a result of a client programming call.

[0002]

2. Description of the Related Art The configuration of a conventional example will be described. FIG. 29 is a diagram showing an example of a general object-oriented system configuration shown in JP-A-4-230543 "Data Structure Used in Object-Oriented System". The system shown as an example in FIG.
U (3010) and an input / output interface (3011), a terminal device (3013) and a data storage device (3030).
18) and a computer system containing external devices such as a printer (3021). In this computer system, a micro instruction code (3007) for controlling these hardware in a programmable manner, an operating system (3006), and a data management device (300)
5) To hide the platform (3002) by the object-oriented programming system (30
04). This implements and configures a distributed object-oriented system in which the application program (3003) can be constructed based on the object-oriented concept.

In order to build an application based on the object-oriented concept, the configuration of a messenger system shown as an example in FIG. , Messenger (313
0) sends a message.

As shown in FIG. 31 as an example, a data structure for identifying an object includes an object identification column (3012) as a fixed portion having a unique object identifier, and a data frame in a data storage device (3018). In this conventional example, the message transmission destination is set so that the message transmission destination can be determined optimally according to the situation. can do.

In this conventional example, as shown in FIG. 29, a computer program (3001) has a configuration in which an application program and an object-oriented programming system are integrated. Consider a case where a method activation is requested between a plurality of application programs (3003) using a messenger (3130) shown as an example in FIG. 30 and an object management table as an example in FIG. When one application program (request side) (3003) requests another application program (3003) for processing by message communication, the requesting application program (3003) uses the object-oriented programming system (3004) of that system. ) Will send the message. The message at this time is sent by a messenger (3130) shown in FIG.
Here, the messenger (3130) refers to the object management table (3123) shown in FIG. 31 to determine the request destination application program (3001) with the corresponding class identifier (3105) and instance identifier (3131).
06) and other application programs (3
001). In such a configuration, the method invocation performed between the application programs (3003) is intensively managed by the object-oriented programming system (3004), and the object management table (312) requested by the result message is managed.
Since the object as the method is uniquely identified from the information of 3), it is not possible to realize a process in consideration of information such as the accumulated number of a plurality of messages from the client and the registration time.

[0006]

The method of activating a conventional object-oriented system is constructed as described above. For this reason, the requests are stored individually. Therefore, without comparing the contents of each request,
Executing the method independently has the following problems. For example, when there are a plurality of identical requests, the same method is activated for the number of the existing requests. Therefore, time, memory, CP
Computer resources such as U are wasted, and a wait state for method activation by another request occurs. There is a problem that the client cannot obtain the processing result requested from the server in real time as expected.

In request scheduling, processing for a request issued by a certain client is blocked during an unpredictable method operation time due to a request stored in a request queue that stores requests before that time. Waiting state), it is not possible to add a constraint on the time from when the request is accumulated in the request queue until it is executed, and the client cannot obtain the method processing result at an appropriate timing There was a problem.

[0008] Regarding a class policy that defines the real-time performance of request scheduling for each class,
There is a problem that it is necessary to perform the comparison between the classes and to define the values, and it is difficult to define an appropriate value corresponding to the tendency of the request actually executed in the server.

[0009] In response to a request that requests the same method of the same class to perform a calculation, a request that requests a calculation with different parameters again due to a change in the situation that occurs during the time when this request is stored in the queue. Re-issued, there is a problem that, in addition to wastefully executing the method invocation by the request with the parameter issued earlier, the processing of the request to invoke the method with the parameter corresponding to the new situation is blocked. .

When calculation requests for a method of a certain class are concentrated, request scheduling is performed based on the time when requests are accumulated in a queue without considering the importance of method activation due to the concentration. Calculation can not be processed quickly,
In addition, there is a problem in that the same calculation for the number of requests is performed, thereby wasting resources.

There is a problem that computer resources are wasted by executing calculations for a method of a certain class by the number of times stored in a queue in a request.

[0012] When the class policy is updated, there is a problem that the information is not reflected in the request scheduling of the already operating server.

When the same request is requested to a plurality of servers, the same method processing result cannot be shared among these servers, so that each server wastes computer resources. There was a point.

According to the present invention, in order to solve the above-described problems, when a single request is processed and a processing result is obtained, a plurality of processing results are returned to a plurality of same requests, thereby obtaining a plurality of processing results. The purpose is to realize a method invocation method for processing requests.

[0015]

A method starting method according to the present invention is a method starting method for receiving a request for starting a method for processing data transmitted from a client. And an object execution environment unit for receiving the request from the server and transmitting the received request to the server. The object execution environment unit further includes method information for specifying a method and conditions for processing a plurality of requests collectively. A class policy repository that stores a plurality of class policies with a plurality of prescribed processing conditions as a class policy, wherein the server further includes:
Searching the class policy repository, specifying the class policy to which the received request belongs based on the method information, and managing a plurality of processing conditions of the specified class policy and a request accumulation status as a status of receiving the request. A request queue management unit, a method call table for storing a plurality of processing conditions managed by the request queue management unit and a request accumulation status, and a method for invoking a method to obtain a processing result;
Referring to the above method call table, if the request accumulation status of the class policy to which the request belongs satisfies the multiple processing conditions, the above processing result is returned to each of the multiple clients that sent the request, and the multiple requests are sent. And a request dispatch unit for performing processing in a lump.

The method invocation method further includes a class policy input interface for inputting the class policy. The object execution environment unit receives the input class policy, and transfers the received class policy to the class policy repository. A class policy management unit for writing is provided.

The request accumulation status is the accumulation number of the received requests, and the multiple processing condition is the boundary accumulation number that determines the boundary value of the request accumulation number when the request dispatch unit processes a plurality of requests collectively. Wherein the request dispatcher processes a plurality of requests when the number of accumulated requests is equal to or greater than the number of boundary accumulations.

The plurality of processing conditions include a limit time indicating a limit time from when the request is received by the request queue management unit until the request is processed, and the server further executes the request in the order in which the requests are received. The request queue management unit registers the received request in the request queue table, registers the time at which the request was received as a registration time, and the method call table includes a The request dispatch unit acquires the limit time of the class policy to which the request belongs from the method call table, and stores the request that activates a method having the same method information as the method information of the method to be activated. Re Detected from Est queue table,
A request that exceeds the limit time from the detected request registration time is extracted, and the processing result is returned to the client that transmitted the extracted request.

The object execution environment section reads a request accumulation state for each class policy from the method call table, analyzes the read request accumulation state, and executes a class policy statistical processing section for changing the plurality of processing conditions. It is characterized by having.

The method information is characterized in that the method information includes a method type for specifying the processing content of the method, and parameters that the client passes to the method.

[0021] The method information includes a method type for specifying the processing content of the method.
The method is characterized by invoking a method using parameters passed to the method specified by the request last received by the message management unit.

The request dispatcher processes the requests in the order in which the request queue manager receives the requests, and processes a plurality of requests when the accumulated number of requests to be processed reaches the boundary accumulated number. It is characterized by the following.

The request dispatcher searches the stored number of requests stored for each class policy, detects a class policy in which the stored number of requests is equal to or larger than the boundary storage number, and adds the detected class policy to the detected class policy. It is characterized by processing the request to which it belongs.

The object execution environment section further includes:
A class policy update information distribution unit that receives a class policy input from the class policy input interface from the class policy management unit, and distributes a plurality of processing conditions of the received class policy to the request queue management unit of the server as update information; The request queue management unit writes the received plurality of processing conditions in a method call table.

The request accumulation status is the accumulation number of the received requests, and the multiple processing condition is the minimum accumulation number that defines the lower limit of the accumulation number of requests when the request dispatcher processes a plurality of requests collectively. The request queue management unit searches the method call table to detect a request in which the accumulated number of requests is equal to or greater than the minimum accumulated number, notifies the detected request to the request dispatch unit, and sends the request dispatch The unit processes a plurality of requests for the request notified from the request queue management unit.

In the method starting method, a plurality of servers are provided, the request dispatch unit stores a processing result of starting the method, and the server further starts a method having the same method information as the method started by itself. And a request comparing unit for comparing and searching for the server and distributing the processing result stored to the searched server.

A recording medium according to the present invention is a computer-readable recording medium recording a program for causing a computer to operate as a method starting method for receiving a request for starting a method for processing data transmitted from a client. A server for invoking a method, an object execution environment unit for receiving a request from the client and transmitting the received request to the server, the object execution environment unit further comprising: method information for specifying a method; A class policy repository that stores a plurality of class policies with a plurality of processing conditions defining conditions for processing a plurality of requests collectively is provided as a class policy.The server further searches the class policy repository and receives the class policy. Request The request queue management unit that specifies the class policy to which the request belongs based on the method information, and manages the multiple processing conditions of the specified class policy and the request accumulation status as the status of receiving the request, and the request queue management unit A method call table that stores the managed multiple processing conditions and request accumulation status, a method is invoked to acquire the processing result, and the method call table is referenced, and the request accumulation status of the class policy to which the request belongs is plural. If the processing conditions are satisfied, the computer is operated as a method activation method including a request dispatch unit that returns the above processing result to each of the plurality of clients that issued the request and collectively processes the plurality of requests. for Characterized by comprising a computer readable recording medium recording the program.

[0028]

DESCRIPTION OF THE PREFERRED EMBODIMENTS Embodiment 1 This embodiment is characterized in that the maximum number of requests for requesting the same method invocation for each class is queued at the same time in advance as a class policy, and the method invocation is performed using the defined class policy. And In the following embodiments, an example in which the present invention is implemented by an object-oriented system will be described as an example.

FIG. 1 shows an object-oriented system for realizing the method starting method of the present invention described as an example in this embodiment. The object-oriented system includes an object execution environment unit (1) for realizing an application configuration based on a distributed object orientation based on a client / server model, a class policy input interface (2) having an interface function for inputting a class policy, and a client. Works as
It is composed of a client (3) for transmitting a request for activating a method, and a server (4) operating as a server.

The object execution environment section (1) has the following components. The object management unit (101)
Manages server status and existing locations. The class policy management unit (102) manages a class policy. The class policy repository (103) stores a plurality of class policies by using method information for specifying a method and a plurality of processing conditions for defining a condition for processing a plurality of requests collectively as a class policy. Therefore, the class policy determines in advance the method of method activation by request scheduling that the client expects for each class. The message communication management unit (104) manages message communication between the client and the server. The request is a method activation request, and the request information is information for identifying a method for which activation is requested by the request and for identifying an activation condition. Therefore, request information is specified for each request. In this specification, the request includes request information.

The client (3) has the following components. The client logic unit (301) is an application that operates as a client. The client message communication management unit (302) transmits the programming interface information called by the client logic unit (301) to the object execution management unit (1) by message communication.

The server (4) includes the following components. The server logic unit (401) is an application that operates as a server. The request queue management unit (402) executes the class policy repository (10
3), the class policy to which the received request belongs is specified based on the method information, and a plurality of processing conditions of the specified class policy and a request accumulation status as a status of receiving the request are managed. Is registered in the method call table, which will be described later, as the request accumulation state as the state in which the request is received. Further, the received request is registered in a request queue table (403) described later. In this embodiment, as a plurality of processing conditions, a boundary value of the accumulation number of requests for each class policy is set as the boundary accumulation number. The request queue table (403) is a database that actually stores requests. Request dispatch unit (4
04) invokes the method to obtain the processing result, and refers to the method call table (406),
When the request accumulation status of the class policy to which the request belongs satisfies a plurality of processing conditions, the processing result is returned to each of the plurality of clients that transmitted the request, and the plurality of requests are processed collectively. In the following description, the result obtained by activating the method may be referred to as a “processing result” or an “execution result”, but they are used in the same meaning. Method call table (40
6) stores a plurality of processing conditions and a request accumulation state managed by the request queue management unit (402). Class policies are associated with method types.

The method starting method according to the present invention described below is realized by a program for causing a computer to operate. Therefore, a program for implementing this method activation method can be recorded on a computer-readable recording medium.
The server logic part (401) of the server (4) is an object part (4) which is an instance generated from the class.
012). Further, the object part (401
2) includes a method (4011) defined by a class.

FIG. 2 shows a request queue table (40).
3) shows an example. The request queue table (403) is a database for registering requests stored in one server (4). Also, the storage number (T0101) is stored in order from the request with the oldest registered time.
Are stored as the request information, and the method specifying information necessary for specifying the method to be activated and the activation information required for activating the method are stored. As the method specifying information, the object type (T0102) and the method type (T01)
03), and specifies the method activated by the request. As method information for each method, parameter 1 information (T0104) and parameter 2 information (T0104)
1015) and return information (T0106). In the following, the parameter 1 information (T0104) and the parameter 2 information (T1015) are
104, T0105).

FIG. 3 shows a class policy repository (10
It is a figure showing an example of 3). The class policy repository (103) stores, as a class policy, method information for specifying a method and a plurality of processing conditions for defining a condition for processing a plurality of requests collectively. In this embodiment, the method information includes method identification information and method activation information. As method specific information,
A class type (T0201) and a method type (T0202) defined for each class are included. Further, as method invocation information for each method, parameter 1 information (T02
03), parameter 2 information (T0204) and return information (T0205). In the following, parameter 1 information (T0203) and parameter 2 information (T02
04) and parameter information (T0203, T0204)
It may be expressed as The class type is a template that defines methods and variables for determining the type of an object. The method type specifies the type of the method. The multiple processing condition is a boundary accumulation number (T0206) which is the maximum number of requests that can be simultaneously registered in the message queue table (401) of one server (4).
Will be described.

FIG. 4 shows a method call table (40).
It is a figure showing an example of 6). This is a database for managing the relationship between the request types stored in one server (4) and the simultaneous storage permitted for the method activated by this request specified by the class policy. In this embodiment, the object type (T030
1), method information (T0302 to T0305),
The request queue management unit receives, as a plurality of processing conditions, a boundary accumulation number (T0306), which is an accumulation number serving as a boundary for judging that a plurality of requests are to be collectively processed, and a request accumulation state as a state of receiving the request. The stored request number (T0306) is stored. The object type is specified in the server from the class type and the method type. The method call table (406) stores the request based on T0302 to T0305 in the class policy repository (10).
3) Classified and stored for each, and further, the server (4)
In the server logic unit (401), an object type (T0301), which is a unit for managing a method,
It is stored in association with the above class policy. The information described above is stored in the request queue management unit (402)
Is registered by As described above, the method call table according to the present embodiment is also referred to as a method call count table because it counts requests and stores the accumulated number as the request accumulation status.

Next, the operation of the object-oriented system in this embodiment will be described. First, in operating this object-oriented system, it is premised that "class policy registration processing" for registering a class policy in the class policy repository (103) has been executed. Therefore, first, the operation of the “class policy registration process” will be described. Next, "request counter registration processing" and "method call counter processing", which are features of the present invention, will be described. The "request counter registration process" means that the server (4) executes the class policy repository (10) of the object execution environment section (1).
This is a process of acquiring the class policy registered in 3) and registering it in the internal method call table (406). "Method call counter processing" refers to processing for generating a method call table (406) from the class policy repository (103). This is performed by the request queue management unit (402). Next, the process from when the client (3) issues a request for activating a method to when the server (4) activates the method is defined as "normal method activating process" and "method activating process by the same request". I will explain separately. In the following description of FIGS. 5 to 10, the case where messages are used to transmit information between components will be described. The message is Mxxxx (xxxx is a number)
It is represented by

First, the operation of the "class policy registration process" will be described with reference to FIG. The class policy is specified by the system administrator. The system administrator inputs a class policy from the class policy input interface (2). The input class policy is the message M
0101 (hereinafter, “message” is omitted) is transmitted to the class policy management unit (102) of the object execution environment unit (1). The class policy management unit (102) that has received M0101 ends the operation as class policy registration processing by storing the class policy received by M0101 and requested to be registered in the class policy repository (103).

Next, the operation of the "request counter registration process" will be described with reference to FIG. The “request counter registration process” includes a “request counter analysis process”, a “class policy search process”, and a “method call table generation process” described below. This "request counter registration process" is a step of registering a request transmitted from the client (3) to the server (4) via the object execution environment unit (1) based on a class policy which is a feature of the present invention. is there. The server message communication management unit (104) of the server (4) converts the received request into a request queue management unit (402).
Pass to The request queue management unit (402) analyzes the request and performs a request counter registration process. When the server (4) receives the request, first,
Perform "request counter analysis processing". The “request counter analysis process” is performed in the method call table (4
06), whether or not the same request as the received request exists is analyzed. The same request in this embodiment refers to a request in which the request has the same object type and the same method type, and further requests a method activation with the same parameter information and the same return information. As a result of this analysis, if the same request already exists in the method call table (406), the method call table (406)
Is incremented (T0307) (FIG. 4) in the table corresponding to. If the same request does not exist, the "class policy search process" and the "method call table generation process" described below are executed.

Next, the operation when the same request does not exist as a result of the "request counter analysis process" will be described with reference to FIG. Request counter table (40
6) A server message communication management unit (40) for acquiring a class policy corresponding to an object mounted in the server from the object execution environment unit (1).
The information specifying the class policy is sent to 5) by M0201. In this embodiment, the information for specifying the class policy corresponds to the method information and the multiple processing conditions, but is not limited to this. Upon receiving M0201, the server message communication management unit (405)
The information for specifying the class policy received by 1 is
The message is sent to the message communication management unit (104) of the object execution environment unit (1) by M0202. Upon receiving M0202, the message communication management unit (104)
Is transmitted to the class policy management unit (102) by M0203. The class policy management unit (102) that has received the M0203 executes a “class policy search process” in order to acquire the class policy from the information specifying the class policy transmitted by the M0203. The "class policy search process" searches the class policy repository (103) for a class policy corresponding to the class requested by the information specifying the class policy. The searched class policy is M0204.
Is sent from the class policy management unit (102) to the message communication management unit (104). The message communication management unit (104) that has received M0204 sends the information of M0204 to the server message communication management unit (405) of the server (4) by M0205. Upon receiving M0205, the server message communication management unit (405)
05 is sent to the method call table (406) by M0206. As a result, the method call table (406) acquires the corresponding class policy by M0206, and then executes “method call counter generation processing”.

Next, the operation of the "method call counter generation process" will be described with reference to FIGS. As shown in FIG. 3, the structure of the acquired class policy is, for each class type (T0201), the one defined in the class.
Method type (T
0202) and parameter information (T0203, T02)
04), return information (T0205), and a boundary storage number (a boundary for determining whether to collectively process a plurality of requests stored in the request queue table (403) of one server (4) for each method ( T02
06). The method method information requested by the received request is specified in this information, and is expanded into one table of the method call table configuration shown in FIG. For example, a method "method_method_of object" Object_1 "whose class type is generated from class_1 by a request.
1 for “in int 100
0, “in int 10”,... And return information are returned as “int”, a table of class_1 whose class type (T0201) shown in FIG. The first table shown in Fig. 4 is created from this information, and the boundary accumulation number (T030) in the method call table (406).
If 6) is blank (the acquired boundary storage number (T0206) of the class policy is blank), it means that the boundary storage number is infinite.

Next, the operation of the "normal method activation process" will be described with reference to FIG. 7, FIG. 8, and FIG. The operation of the normal method activation processing is the most basic operation, and is an operation from the time when a client issues a request to the time when a processing result of a method of a corresponding server is obtained. Further, in the operation of the method activation processing by the same request described later, a case where a plurality of requests are processed collectively will be described.

The client logic unit (301) of the client (3) calls an application interface prepared in advance and issues a request using this application interface. On this occasion,
Request information about the request is also generated. This request is sent to the client message communication management unit (302) by M0301 together with the request information. Upon receiving M0301, the client message communication management unit (302) converts this information into a format that can be transmitted by a message, and sends the information to the message communication management unit (104) of the object execution environment unit (1) in M0302. The message communication management unit that has received M0302,
The information of M0302 is sent to the object management unit (101) in M0303.

The object management unit (101) receiving M0303 analyzes the location and operation state of the server (4) as “server analysis processing” from the request information received in M0303, and After confirming that the server can receive the request, the message communication management unit (104) in M0304 transmits the request information to the corresponding server (4).
Send information to Upon receiving M0304, the message communication management unit (104) sends the information of M0304 to the server message communication management unit (405) of the corresponding server (4) via M0305.

Upon receiving M0305, the server message communication management unit (405) transmits the information of M0305 to M0306.
To the request queue management unit (402). M03
06, the request queue management unit (402)
The information of M0306 is sent to the method call table (406) in M0307. In the method call table (406) that has received M0307, “request counter registration processing” is executed according to an instruction from the request queue management unit (402). Since the details of the “request counter registration process” have been described above, the description is omitted here. After the request counter registration process is performed, the method call table (406) indicates that the process has been completed.
At 0308, the request is sent to the request queue management unit (402).

Upon receiving M0308, the request queue management unit (402) calls the method call table (40).
Instruct 6) to execute “request registration processing”. The “request registration process” registers the request information transmitted in M0306 in the request queue table.

The operation of the "request registration process" will be described with reference to FIG. FIG. 2 shows the structure of the request queue table (403). The request information to be newly registered is assigned a continuous value from the already registered number as the storage number (T0101). And
Object type (T0102), method type (T0
103), parameter information (T0104, T0105)
Etc.), and the registration is completed by expanding the request information in the return information (T0106). Upon completion of the above request registration processing, registration of the request with the server (4) is completed, and the client (3) enters a request response waiting state (FIG. 7).

When the server enters the request response waiting state, the request dispatch unit (404) of the server (4) performs "request dispatch processing" (FIG. 7). In the “request dispatch process”, the request dispatch unit (404) acquires M0309 to the request queue management unit (402), thereby acquiring a request to be processed next. The request queue management unit (402) that has received M0309 performs the “request analysis process”.
Search for the next request to be processed.
The “request analysis process” extracts a request whose accumulation number (T0101) is 1 from the request queue table (403) and analyzes whether or not the extracted request exists in the method call table. Specifically, "Applicable request analysis processing"
Acquires the request whose accumulation number (T0101) is “1” from the table of the request queue table (403), and obtains the object type (T0
102), method type (T0103), parameter information (T0104, T0105), and return information (T0
106) is the object type (T0301) and the method type (T03) of the method call table (406).
02), the parameter information (T0304, T0305) and the return information (T0306) all match, the storage number (T0307) is the boundary storage number (T030).
6) is determined, and the boundary accumulation number (T0
If it does not reach 306), "Normal method startup"
Is determined, and when it reaches the boundary accumulation number (T0306), it is determined that “method activation by the same request”.

In the method call table (406) receiving M0310, the method call table (4)
06) is compared with the request queue table, and the result is stored in the request queue management unit (40
Send to 2). As described above, "relevant request analysis processing"
Ends. The case where the result of "relevant request analysis process" is "normal method invocation" will be described below, and the operation in the case of "method invocation by the same request" will be described in the later "method invocation by the same request". .

The request queue management unit (402), which has determined “normal method activation” by “relevant request analysis processing”, determines that the next request to be processed is “normal method activation” and performs the next processing. The request dispatch unit (4
04). Upon receiving M0312, the request dispatch unit (404) specifies the method to be activated from the information of the request to be processed next, and determines that the method activation is M0.
At 313, an instruction is given to the server logic unit (401). M
The server logic unit (401) instructed to start the method in 0313 sets the specified object (4012)
Of the method (4011) is instructed, and the processing result is sent to the request dispatch unit (404) in M0314. Upon receiving M0314, the request dispatch unit (404) transmits the information of M0314 to M0314.
At 15, the request is sent to the request queue management unit (402). M
Request queue management unit (402) receiving 0315
Is a method call table (40
6) Instruct “request counter deletion processing” for decrementing the accumulated number (T0307) of the executed method call counter. In the method call table (406) that has received M0316, a request counter deletion process is executed. If the decremented accumulation number (T0307) is "0", the data of the class policy is deleted. The request queue management unit (402) that has transmitted M0316 stores the accumulation number (T) of the processed request queue table (403).
1010) deletes the request of “1” and decrements all the storage numbers (T0101) allocated to the remaining requests. Subsequently, the request queue management unit (402) sends the information of M0315 to the server message communication management unit (405) via M0317. M03
Server message communication management unit (405) that has received the message 17
Sends the information of M0317 to the message communication management unit (104) of the object execution management unit (1) in M0318. The message communication management unit that has received M0318
The information of 0318 is sent to the object management unit (101) in M0319. The object management unit that has received M0319 sends the information of M0319 to the message communication management unit (104) in M0320.

The message communication management unit (104) that has received M0320 sends it to the client message communication management unit (302) of the client (3) with the information M0321 of M0320. The client message communication management unit (302) that has received M0321 converts the method processing result received in M0321 from a message to a programming interface, and sends it to the client logic unit in M0322. As a result of the above processing, the client logic unit completes the processing of acquiring the result of the request requested by the programming interface.

The operation of "method activation by the same request" will be described with reference to FIGS. 9, 10 and 11.
This operation is an operation when the “request analysis process” is executed and the result is determined to be “method activation by the same request” as in the case of “normal method activation”. This is the same as the operation of “normal method activation” described above. Therefore, FIG.
The operation up to the “request response waiting state” shown in FIG.

The request queue management unit (402), which determines that the result of the request analysis processing is “method activation by the same request”, indicates that “method activation by the same request” indicates that the request is to be processed next. Is sent to the request dispatch unit (404) in M0402 (FIG. 9). Upon receiving M0402, the request dispatch unit (404) specifies a method to be activated from the information of the request to be processed next, and instructs the server logic unit (401) to activate the method in M0403. The server logic unit (401) instructed to start the method in M0403 instructs the method start of the method (4011) of the specified object (4012), and sends the processing result to the request dispatch unit (404) in M0404. send. The request dispatch unit (40
4) determines whether to return this result to all clients (3) that have issued the same request.

The subsequent operation of returning the method processing result is as follows.
As an example, a case where a response is returned to the client A and the client B shown in FIG. 10 will be described. In the example of FIG. 10, client A (3) is client B
It is assumed that the request issuance time is older than (3).
The request dispatch unit (40) that has received M0404
4) Client A that issued the same request
The information of M0404 is sent to the request queue management unit (402) at (M0405, M0410) to (3) and the client B (3).

The operation of transmitting the calculation result will be described in detail below. First, the operation when transmitting the method processing result to the client A (3) will be described. The request queue management unit (402) sets the request queue table (40) as the request registered at the oldest time.
The request counter deletion processing of decrementing the accumulation number (T0307) of the method call table (406) of the class policy to which the request corresponding to the accumulation number (T0101) of "3" corresponding to "1" belongs to the method call table (406) in M0406. To M040
In the method call table (406) that has received No. 6, request counter deletion processing is executed. In the request counter deletion process, the accumulation number (T0307) of the corresponding table of the method call table (406)
Is decremented. In the example of this description, the result of the decrement is “1”.

In the request queue management unit (402),
After transmitting M0406, in order to transmit the received information of M0405 to client A, the information is transmitted to the server message communication management unit (405) in M0407. Upon receiving M0407, the server message communication management unit (405)
The information is sent to the client message communication management unit (302) of the client A (3) at M0408 via the information object execution environment unit (0407). The operation of the object execution environment unit (1) during this period is exactly the same as that in the case of “normal method activation”, and a description thereof will be omitted.

Upon receiving M0408, the client message communication management unit (302) converts the method processing result received at M0408 from a message to a programming interface, and sends it to the client logic unit at M0409. As a result of the above processing, client A
The client logic unit of (3) completes the method execution result acquisition for acquiring the result of the request requested by the programming interface.

The operation in which the client B (3) that has issued the same request subsequently obtains the method processing result will be described. The request queue management unit (402) that has obtained the method processing result by M0410 stores the number (T0307) of the method call table (406) of the class policy to which the request with the oldest storage number (T0101) of the request queue table (403) belongs. M0411 to delete the request counter
To the method call table (406).
M0411 received method call table (40
In 6), a request counter deletion process is executed. In the request counter deletion process, the accumulated number (T030) of the corresponding table of the method call table (406)
7) is decremented. In the example of this description, the result of the decrement should be “0”. In this case, the entire data of the corresponding class policy is deleted.

In the request queue management unit (402),
After transmitting the M0411, the M0412 sends the information of the M0412 to the server message communication management unit (405) in order to transmit it to the client B. Upon receiving the M0412, the server message communication management unit (405)
M04 via the information object execution environment section (1)
In step 13, the message is sent to the client message communication management unit (302) of the client B (3). The operation of the object execution environment unit (1) during this period is exactly the same as that in the case of “normal method activation”, and a description thereof will be omitted.

Upon receiving M0413, the client message communication management unit (302) converts the method processing result received at M0413 from a message to a programming interface, and sends it to the client logic unit at M0414. As a result of the above processing, client A
The client logic unit of (3) completes the method execution result acquisition for acquiring the result of the request requested by the programming interface.

Referring to FIG. 11, an operation in which real-time method activation set by the class policy is guaranteed by method activation by the same request will be described focusing on the movement of the request queue table (403). The request transmitted from the client (3) is assigned a storage number and stored in the request queue table (403). On the other hand, the request queue management unit (402) sequentially retrieves the storage number (T0101) from "1" and executes the method. In this case, FIG.
As in the example of Example 1, when the storage numbers 2, 3, and 7 perform exactly the same request, the maximum number of storages of the same request is defined by the class policy. The process of returning the method processing result to the accumulation numbers 2, 3, and 7 by one request activation is realized as the method activation by the same request.

As described above, the method activation expected by each request stored in the server queue is monitored, and if the number of identical queued requests reaches the number specified by the class policy, the next identical At the timing when the method invocation for the oldest request among the requests is determined, the processing result of the method executed in response to the request is acquired by all the clients that have made the same request, and the application software and Can implement method invocation transparently from client and server based on independently defined class policies.

In this way, the object execution environment unit (1) that manages the method activation method by request scheduling expected for each class in advance as a class policy independently of the client (3) and the server (4), and the server ( In the request scheduling of (4), the request queue management unit (4) of the server (4)
02) compares the request stored in the request queue table (403) with the class policy,
By instructing the request dispatch unit (404) to start a method according to a method based on the class policy, a method start that guarantees different real-time properties for each class is realized.

In this way, in the request scheduling, the method is started at the timing when the request with the oldest registration time to the queue among the same requests is processed, and the result is transmitted to all the clients that issued the same request. To avoid unnecessary waste of computer resources at the time of request scheduling by minimizing the number of times the same method is executed, and to minimize the number of executions of the same method. And realizing a real-time method invocation method which is transparently realized from a client logic of a client and a server logic of a server based on a class policy.

Embodiment 2 FIG. 12 differs from the object-oriented system configuration diagram for realizing the method activation method of the present invention in the first embodiment in which the items constituting the method call table are changed. In this embodiment, the method call table will be described as a method call limit time table (407).

FIG. 13 shows an example of the request queue table of this embodiment. FIG. 13 shows a structure of the request queue table according to the first embodiment.
In this configuration, a registration time (T0107) for each request is added. FIG. 14 shows an example of the class policy repository of this embodiment. FIG. 14 shows a configuration in which the boundary accumulation number is deleted and a limit time (T0207) is added to the class policy repository configuration in the first embodiment. FIG. 15 shows an example of the method call limit time table (407) according to this embodiment.
FIG. 15 is a table in which the server registers the limit time to be queued for each method invocation type requested by the request, and the class type (T040
1), method type (T0402), time limit (T04)
03).

Next, the operation of the second embodiment will be described. The operation of the second embodiment is different from the operation of the first embodiment in the operation of a request limit time registration process instead of the request counter registration process. The operation of the time generation process will be described, and then the operation of the request dispatch process in the case of the second embodiment will be described.

The processing flow of the request limit time registration processing according to the second embodiment is different from the case of the request counter registration processing according to the first embodiment in that the method call limit time is used instead of the method call table (406) of the server (4). The procedure is exactly the same except that a table (407) is provided and a method call limit time generation process is provided instead of the method call counter generation process. Therefore, the operation unique to the second embodiment will be described below.

In the request limit time registration process, when the server (4) receives a request, it is determined as a “request counter analysis process” by using the method call limit time table (407) whether or not the same request already exists. . The same request according to the present embodiment is determined as a request that requests a method activation for the same method of the same object unlike the first embodiment. As a result of this analysis, if the same request does not already exist, the class policy registered in the class policy repository of the object execution environment is acquired, and the method invocation time limit table (407)
Create a table corresponding to.

The operation of the method call limit time generation processing will be described with reference to FIGS. The structure of the acquired class policy is, as shown in FIG.
0201), the method type (T020), which is one or more method method information defined in the class,
2) and parameter information (T0203, T0204),
The return information (T0205) includes a limit time (T0207), which is the maximum time during which the method is processed during normal method startup. The method method information requested by the received request is specified in this information, and is expanded in the method call limit time table shown in FIG. For example, for the method method_1 of the object Object_1 whose class type is generated from the class_1 by the request, the parameters are “in int1000” and “in
int 10 ", ... and return information is" int "
Is performed, a table whose class type (T0201) shown in FIG. 14 is class_1 is acquired as a class policy, and a first table shown in FIG. 15 is created from this information. If the time limit (T0207) of the method call time limit table (407) is blank, it means that only normal method activation is performed.

The operation of the request analysis processing in the second embodiment will be described. Request queue management unit (40
In the corresponding request analysis processing executed by 2), first,
The request whose accumulation number (T0101) is “1” is obtained from the request queue table (403), and the object type (T010) of the request information is acquired.
2), the class type (T040) of the method type (T0103) and the method invocation limit time table (407)
1) Search for a case where all of the method types (T0402) match, and acquire the corresponding time limit (T0403). Next, each table of the request queue table (403) is searched, and the request of the accumulation number “1” is obtained.
Object type (T0102), method type (T0103), and parameter information (T010) of the request information
4, T0105) and the return information (T0106) all match, referring to each registration time (T0107), and judging that the request has passed the corresponding time limit as "method activation by the same request". I do. If one (request with the accumulation number "1") has passed the limit time, or if there is no such request, it is determined that "normal method activation" and the processing is continued.

As described above, the requests accumulated in the queue of the server are monitored, and if the same request is queued for more than the time specified by the class policy and is in an execution waiting state, the same request is executed next. When it is determined that the method is invoked for the oldest request in the above, the request from the client is returned by returning the processing result of the method executed in response to the request to all other clients that made the same request. Method can be invoked with restrictions on the queued time.

Embodiment 3 FIG. 16 shows an example of a configuration in which a class policy statistical process is added to the object execution of the object-oriented system configuration for realizing the method activation method of the present invention in the first embodiment. 105 is
A class policy statistical processing unit (105) for reading the request accumulation status for each class policy from the method call table (406) and analyzing the read request accumulation status to change the plurality of processing conditions.
It is. In this embodiment, the request accumulation status is
The case where the number is the accumulated number of requests will be described as an example.

Next, the operation of the third embodiment will be described with reference to FIG. First, the class policy repository (10
The operation of the class policy periodic update process for periodically updating 3) will be described. Then, in order to statistically calculate the class policy from the number of actual requests,
The operation of class policy statistical processing for collecting method method information performed by a request from each server will be described.

The operation of the class policy statistical processing will be described with reference to FIG. This operation is a process that is executed before the request registration process is executed by the server (4) in the normal method activation operation according to the first embodiment and the request response waiting state is entered.

After the request queue management unit (402) executes the request registration processing, the server message communication management unit (405) uses M0501 to determine the class and method information of the method of the object activated based on the registered request. Send to Upon receiving M0501, the server message communication management unit (405) sends the information of M0501 to the message communication management unit (104) of the object execution environment unit (1) via M0502. The message communication management unit (104) that has received M0502
02 is sent to the class policy statistical processing unit (105) in M0503. The class policy statistical processing unit (105) that has received M0503 accumulates the received class and method information.

The operation of the class policy periodic update process will be described. The class policy statistical processing unit (105), which collects the class and method information required for method activation in the entire object-oriented system, collects an appropriate class policy from the information collected at a predetermined cycle. , And instructs the class policy management unit (102) to update the class policy repository. The class policy management unit (10
In 2), the contents of the class policy repository (103) are updated.

As described above, the class policy that defines the real-time property of method invocation for each class is obtained by monitoring the status of a request from a client that is actually being executed in an object-oriented system to a server, and statistically determining the status at regular time intervals. The calculation makes it possible to automatically set the class policy according to the latest situation.

Further, it is possible to automatically update the value of the class policy reflecting the status of the request transmitted to the server at regular intervals.

Embodiment 4 FIG. 18 shows a method call table (4
06) are changed. In this embodiment, the method call table (406) will be described as a method call totalization table (408). FIG.
Shows the configuration of the method call totaling table (408), which is composed of a class type (T0501), a method type (T0502), and an accumulation number (T0503).

Next, the operation of the fourth embodiment will be described. First, the operation of the request totaling registration process executed instead of the request counter registration process of the first embodiment will be described. Subsequently, the operation of the method call totalization process executed instead of the method call totalization generation process of the first embodiment will be described, and subsequently, the operation of the method activation process by the same request as the request dispatch process will be described.

The processing flow of the request totaling registration processing according to the fourth embodiment is almost the same as the request counter registration processing according to the first embodiment, except for the following operation. In the request totaling registration process, when the server (4) receives the request, the method call totaling table (408) determines whether or not the same request already exists, as "request totaling analysis process". The same request according to the present embodiment is determined as a request that requests a method activation for the same method of the same object unlike the first embodiment. Specifically, this means a case where the class type (T0501) and the method type (T0502) of the method call totalization table (408) are the same. As a result of this analysis, if the same request already exists, the accumulated number (T0503) of the corresponding table of the method call totaling table (408)
Is incremented, and if it does not exist, the class policy registered in the class policy repository of the object execution environment part is acquired, and the operation by “method call totaling table generation processing” is started.

The method activation method of this embodiment can be applied when the client (3) wants to obtain the processing result of the method activation requested by the request and the processing result of the method using the latest parameters. Therefore, in the case of a request whose parameters must be the same as when the request was sent, it is necessary to apply the method activation method of the first embodiment.

The operation of the method call tally generation process will be described with reference to FIG. 3 and FIG. The structure of the acquired class policy is, as shown in FIG.
For each 1), method type (T0202) and parameter information (T0203, T0204) and return information (T0205), which are one or more method method information defined for the class, and the method is a normal method invocation , Which is the maximum queuing number to be processed at the boundary accumulation number (T0206). Among the information, the method method information requested by the received request is specified, and is expanded into one table of the method call totaling table configuration shown in FIG. For example, upon request, the class type is class_1
The parameter is “in i” for the method method_1 of the object Object_1 generated from
nt 1000 ”,“ in int 10 ”,... and return information by“ int ”, a class type (T0201) shown in FIG. 19 and a method type (T0502) shown in FIG.
The first table is acquired as a class policy, and the first table shown in FIG. 19 is created from this information.

The operation of the request analysis process in the fourth embodiment will be described. Request queue management unit (40
In the corresponding request analysis processing executed by 2), first,
The request whose accumulation number (T0101) is “1” is obtained from the request queue table (403), and the object type (T010) of the request information is acquired.
2) Search for a case where the method type (T0103) and the class type (T0501) and the method type (T0502) of the call totaling table (408) all match, and obtain the corresponding accumulation number (T0503). If the accumulated number (T0503) is "1", it is determined that "normal method activation". When the accumulation number (T0503) is not "1", each table of the request queue table (403) is searched, and a request having the same accumulation number "1" is searched. The same request means the object type (T0102) and the method type (T010) of the request information.
The case where 3) and the return information (T0305) match is determined as the same request and “method activation by the same request” is determined.

The operation of the method activation process by the same request according to this embodiment is almost the same as the operation of the method activation process by the same request according to the first embodiment. However, the process for starting the method described below is different. The request queue management unit (402), which has determined that the result of the corresponding request analysis processing is “method activation by the same request”, indicates that “method activation by the same request” and the information of the request to be processed next in M402. Request dispatch unit (404)
Send to However, the information for the next request to be processed is
The accumulation number (T0) of the request queue table (403)
101) is the parameter information (T
0104, T0105) and return information (T0106)
Is used.

As described above, the requests stored in the server queue are monitored, and if the number of stored requests for the same method of the same object reaches the number specified by the class policy, the next request in the same request By instructing the method calculation from the latest parameter information and return information in the same request at the timing when the method is started for the oldest request, the client can always obtain the latest method calculation result.

Embodiment 5 FIG. 20 is a flowchart of the relevant request analysis process according to the fifth embodiment. Next, the operation of the request analysis process in the fifth embodiment will be described with reference to FIG. In the fifth embodiment, the operation of the corresponding request analysis process is different from the operation of the first embodiment. The operation will be described below with reference to FIGS. 1, 3, and 20. In the corresponding request analysis process started by the request queue management unit (402), the accumulation number (T0101) registered in the request queue table (403)
Sends the information of the request with “1” to the method call table (406) in M0601. In the method call table (406) that has received M0601, the class type, method type, parameter information, and return information of the received request information are respectively the object type (T030) of the method call table (406).
1), method type (T0302), parameter information (T0303, T0304), and return information (T030)
5) retrieves the exact same table, analyzes whether there is any table whose storage number (T0307) has reached the boundary storage number (T0306), and if so, determines that the request is the same request. , If not reached, it is determined that the request is not the same, and the result is referred to as M0602.
To the request queue management unit (402).

When the request queue management unit (402) receives M0602, when the same request is notified, a method activation process by the same request is performed on the request. If it is notified that the requests are not the same, the request queue table (40
Similarly, for the storage number (T0101) next to 3), M
0601 and M0602 are determined, and M0602 is determined.
If the notification that the request is not the same is received, the process is further continued. If it is determined that all the requests in the request queue table (403) are not the same request by the above processing, the normal method activation processing is performed for the request with the accumulation number “1”.

As described above, the requests accumulated in the queue of the server are monitored, and when the number of identical requests reaches the number specified by the class policy, at the timing of the first request scheduling after this registration. Priority is given to executing the method corresponding to the request with the oldest registration time among the same requests, and the result is returned to all clients that issued the same request. Method can be invoked according to.

Further, in this way, the method activation according to the class policy which is not caught by the time when the client issues the request is realized.

Embodiment 6 FIG. FIG. 21 is a configuration diagram of a class policy repository in the sixth embodiment.
FIG. 22 is a configuration diagram of a method call table according to the sixth embodiment. FIG. 21 is a diagram showing an example of the class policy repository according to the sixth embodiment. FIG. 21 shows a configuration in which the minimum accumulation number (T0208) is added to the class policy repository in the first embodiment instead of the boundary accumulation number (T0206).
FIG. 22 shows an example of a method call table according to the sixth embodiment. FIG. 22 shows the method call table according to the first embodiment in which the minimum storage number (T030) is used instead of the boundary storage number (T0306).
8) is added.

Next, the operation of the sixth embodiment will be described. First, an operation of a method call counter generation process different from the first embodiment will be described, and then, an operation of a request dispatch process different from the first embodiment will be described.

The operation of the method call counter generation process will be described with reference to FIGS. 21 and 22. As shown in FIG. 21, the structure of the acquired class policy is, for each class type (T0201), a method type (T0) which is one or more method method information defined for the class.
202) and parameter information (T0203, T020)
4), return information (T0205), and a minimum accumulation number (T0208) which is a minimum accumulation number at which the method is processed by normal method activation. Among the information, the method method information requested by the received request is specified, and is expanded into one table of the method call table configuration shown in FIG. For example, if the class type is class_
The parameter “in” for the method method_1 of the object Object_1 generated from the
int 1000 "," in int 10 ", ...
And a request in which the return information is returned as “int”, a table whose class type (T0201) shown in FIG. 22 is class_1 is acquired as a class policy,
The first table shown in FIG. 22 is created from this information. If the minimum accumulation number (T0308) in the method call table (407) is blank, it means that only normal method activation is performed.

The operation of the request analysis processing in the sixth embodiment will be described. Request queue management unit (40
In the corresponding request analysis processing executed by 2), first,
The request whose accumulation number (T0101) is “1” is obtained from the request queue table (403), and the object type (T010) of the request information is acquired.
2), method type (T0103), parameter information (T0104, T0105), and return information (T010)
6) is a method call table (40)
6) Object type (T0301) and method type (T03) in the object information method call table
02), the parameter type (T0303, T0304) and the return information (T0305). If the corresponding table exists, it is determined whether or not the storage number (T0307) of the table has reached the minimum storage number (T0308), and if so, it is determined that "method activation by the same request". If the corresponding table does not exist, it is determined that “normal method activation”. There is a corresponding table, but the storage number (T0307) of the table is the minimum storage number (T030).
If the number has not reached 8), the accumulation number (T0101) is selected from the request queue table (403).
Obtains the request of “2”, similarly determines whether “normal method activation” or “method activation by the same request”. If it cannot be determined, the request of the next storage number (T0101) is further processed. Continue the analysis. In the above, the case where the parameter information matches when judging the same method has been described. However, an embodiment in which the same method is determined when the parameters are not the same may be considered. In the above description, the number of accumulated requests is adopted as the multiple processing condition. However, it is also conceivable that the limit time described in the second embodiment is additionally set as the multiple processing condition.

As described above, the requests stored in the server queue are monitored, and if the number of queued identical requests does not reach the number specified in the class policy, the next oldest request among the identical requests Suspends the method invocation even if it is determined that the method has been activated, and executes the method invocation corresponding to the request with the oldest registration time among the same requests when the specified number has been reached. By sending back to all issued clients, the number of method invocations executed in response to requests can be minimized.

Embodiment 7 FIG. FIG. 23 shows a class policy update information distribution unit (106) in the object execution environment unit for the object-oriented system in the first embodiment.
FIG. Next, the operation of the class policy update information distribution process according to the seventh embodiment will be described with reference to FIG. In the class policy update information distribution process, the class policy management unit (102) of the object execution environment unit (1) receives M0101 in the operation of the class policy registration process described in the first embodiment,
When the class policy repository registration processing is executed, this is the processing of distributing the updated information of the class policy to the associated server (4).

After executing the class policy repository registration process, the class policy management unit (102) notifies the class policy update information distribution unit (106) of the updated class policy information in M0701. Class policy repository update information distribution unit (10
In 6), the object management unit (101) is queried in M0702 to search for a running server (4) in order to distribute the updated class policy information to the associated server (4). Upon receiving M0702, the object management unit (101) stores the information of the operating server (4) in M07.
At 03, it is returned to the class policy update information distribution unit (106). In the class policy update information distribution unit (106) receiving the M0703, the acquired operating server (4)
Update class policy information is notified to all.

In the following description, the operation of notifying one server (4) of the updated class policy information will be described. The class policy update information distribution unit (106)
The updated class policy information is sent to the message communication management unit (104) in M0704. Upon receiving M0704, the message communication management unit stores the information of M0704 in M0705.
The server message communication management unit (40) of the server (4)
Send to 5). Upon receiving M0705, the server message communication management unit (405) transmits the information of M0705 to M070.
At 6 the message is sent to the request queue management unit (402). M0
The request queue management unit (402) having received 705 refers to the method call table (406) and refers to the object type (T010) of the update class policy information.
2), method type (T0103), parameter information (T0104, T0105), and return information (T010)
If there is a table that matches all of 6), the boundary accumulation number (T0306) of the table is updated to the value of the update class policy information.

As described above, when the class policy is updated, by distributing the update information to the server already executed in the object-oriented system, the method can be always started based on the latest class policy. .

Embodiment 8 FIG. FIG. 25 shows a configuration in which a request comparison unit (409) is added to the server of the object-oriented system according to the first embodiment. The request comparison unit (409) compares and searches for a method started by itself and another server that starts the method with the same method information, and distributes the stored processing result to the searched server. FIG. 26 shows the request queue table (4
03) is added to the processing result (T0108). In this embodiment, as an example, a case where the processing result is stored in the request queue table (403) by the request dispatch unit (404) will be described.

Next, the operation of the eighth embodiment will be described. In the eighth embodiment, the method is executed in the server (4) by the processing described in the first embodiment, and after the result is transmitted to the request queue management unit (402) in M0314 and M0315, The method execution result is registered in the client (3) issuing the same request to the server (4) and another server in which the same request is queued. Therefore, first, FIG.
The process of searching the server (4) A that has executed the method using the server 8 for another server that is operating will be described as an operation server search process. Next, the operation of the same request comparison process for registering the method execution result in one of the servers (4) B will be described with reference to FIG. Next, the server (4)
The operation of performing the corresponding request analysis process and the method activation process in B will be described.

Referring to FIG. 28, the server (4) sets the object management unit (101) of the object execution environment unit (1).
Next, an operation of inspecting another operating server will be described. In the request comparison unit (409) of the server (4), M09
At 01, the server message communication management unit (405) is requested to search for an operation server. The server message communication management unit (405) that has received M0901,
1 is sent to the message communication management unit (104) of the object execution environment unit (1) in M0902. M0
The message communication management unit (104) that has received 902 sends the information of M0902 to the object management unit (101) in M0903. The object management unit (101) that has received M0903 sends the active server list information to the message communication management unit (104) in M0904. Upon receiving M0904, the message communication management unit
The information of 0904 is sent to the server message communication management unit (405) of the server (4) in M0905. M0905
The server message communication management unit (405) receiving the
The information of M0905 is sent to the request comparison unit (409) in M0906.

The operation of the same request comparison process will be described with reference to FIG. In this processing, the method execution is performed in the first embodiment, and the method execution result is M0405.
Is a process of transmitting this information to another operating server after being notified to the server (4) A. The request queue management unit (402) of the server (4) A sends the method method information and the method execution result to the request comparison unit (409) in M0801. The request comparison unit (409) that has received M0801, executes an operation server search process, and searches for another server that is operating by the operation described above. Hereinafter, an operation of notifying the server (4) B of the method method information and the method execution result from the result of the operation server search processing will be described.

The request comparing unit (409), which has determined the notification of the method execution result to the server (4) B,
The information received at 801 is sent to the server message communication management unit (405) at M0802. Upon receiving M0802, the server message communication management unit (405)
02 is sent to the server message communication management unit (405) of the server (4) B in M0803. Upon receiving the M0803, the server message communication management unit (405)
The information of 803 is transmitted to the request comparison unit (4
09). The request comparison unit (40) that has received M0804 sends the information of M0804 to the request queue management unit (402) in M0805. The request queue management unit (402) receiving M0805 executes a processing result registration process. In the processing result registration processing, the request queue table (403) is searched, and each of the object type, the method type, the parameter information, and the return information of the method / method information received in 0805 is
Object type (T0102) and method type (T0
103) and parameter information (T0104, T0105)
If there is a table that matches the return information (T0106), the method execution result is registered in the processing result (T0108) of the table.

The operation of the request analysis process in the eighth embodiment will be described. Request queue management unit (40
In the corresponding request analysis processing executed by 2), first,
The request whose accumulation number (T0101) is “1” is acquired from the request queue table (403), and it is determined whether the method execution result is registered in the processing result (T0108) of the request information and registered. If it has been registered, it is determined that “method execution result has been registered”, and if not registered, it has been determined that “method execution result has not been registered”. Next, each table of the request queue table (403) is searched to determine “method activation by the same request” or “normal method activation” as in the first embodiment.

In the method call table (406) receiving M0310, the method call table (4
06) is compared with the request queue table, and the result is stored in the request queue management unit (40
Send to 2). Thus, the corresponding request analysis processing ends. If the result is “no method execution result registration”, the processing is continued as in the first embodiment. However, if “method execution result is registered”, the object execution method is different. The different processing will be described.

The request queue management unit (402), which has determined that “method execution result has been registered” by the corresponding request analysis processing, determines that the next request to be processed is “method execution result has been registered”, 403) of the corresponding table (T010
8) as a method execution result in M0312 to the request dispatch unit (404). Upon receiving M0312, the request dispatch unit (404) determines that the result of the next request to be processed is a method execution result, and sends this information to the request dispatch unit (404) in M0314 as a processing result. Thereafter, the same processing as in the first embodiment is performed.

As described above, the requests accumulated in the queue of the server are monitored, and when the number of identical requests reaches the boundary accumulation number, it is determined that the method activation for the next oldest request among the identical requests is performed next. In addition to returning the processing result of the method executed in response to the request to the client that made the same request at the timing, if the same request is stored in another server, the server In the request scheduling of the above, if the method invocation for the oldest request in the same request is determined next, the method execution is not performed and the already acquired method execution result is transmitted to Can minimize the number of identical method invocations.

Embodiment 9 FIG. In the above embodiment, the boundary processing number, the limit time, and the minimum storage number have been described as an example of the plurality of processing conditions, but the present invention is not limited to this. It goes without saying that the method activation method according to the present invention can be realized by setting a plurality of predetermined processing conditions other than those described above. Further, in the above-described embodiment, there may be a plurality of clients and servers, or one or more clients and servers. Also, the case where the method starting method according to the present invention is realized in an object-oriented system has been described as an example, but the present invention is not limited to this. The present invention can also be applied to a system other than the object-oriented system, which activates a method for processing data.

[0111]

As described above, according to the method invocation method according to the present invention, when the number of requests accumulated in the queue of the server reaches the number specified by the class policy, the same request is next transmitted. Since the processing result of method invocation for the oldest request can be shared among all clients making the same request, the degree of freedom of the application software is based on the class policy specified independently of the application software. Without hindering the execution, real-time method activation can be realized by effective use of computer resources.

As described above, according to the present invention, when the same request is queued for more than the time specified by the class policy and is in a waiting state for execution, the next oldest request among the same requests Since it is possible to share the processing result of the method executed in response to the corresponding request between other clients that made the same request when it is determined that the method is started, the queue of the request from the client cannot be predicted. There is an effect that a restriction can be added to the ing time based on the class policy.

As described above, according to the present invention, the class policy that defines the real-time property of method invocation for each class is dynamically calculated from the status of a request from a client actually executed in an object-oriented system to a server. Therefore, there is an effect that the method can be started based on a class policy that always reflects the latest situation.

As described above, according to the present invention, when the number of requests for the same method of the same object reaches the number specified by the class policy, the method activation for the next oldest request among the same requests is executed. Method calculation from the parameter information and return information of the latest request at the same time, and the result can be shared between clients. Therefore, the client always uses the latest method regardless of the request transmission timing. There is an effect that a processing result can be obtained.

As described above, according to the present invention, when the number of identical requests reaches the number specified by the class policy, the time queued at the first request scheduling timing after this registration is performed. Regardless of the order, the method can be invoked with priority, so that there is an effect that priority processing of method activation can be performed not only according to the time when the request was issued but also according to the situation where the same requests are concentrated. .

As described above, according to the present invention, it is possible to start a method when the number of queued identical requests reaches the prescribed number of the class policy. There is an effect that request scheduling with a minimum level can be performed.

As described above, according to the present invention, the updated information of the class policy can be delivered to the server already executed in the object-oriented system, so that the latest class policy is always reflected. There is an effect that the method can be started.

As described above, according to the present invention, it is possible to share the restriction on the method invocation by the same request among a plurality of servers. Therefore, there is an effect that a real-time method invocation method can be performed in the entire distributed object-oriented system by effectively using computer resources while minimizing the method invocation.

[Brief description of the drawings]

FIG. 1 is a diagram showing an example of an object-oriented system configuration for implementing a method activation method according to the present invention in a first embodiment.

FIG. 2 is a configuration diagram of a request queue table according to the first embodiment.

FIG. 3 is a configuration diagram of a class policy repository in the first embodiment.

FIG. 4 is a configuration diagram of a method call table according to the first embodiment.

FIG. 5 is a flowchart of a class policy registration process according to the first embodiment.

FIG. 6 is a flowchart of a request counter registration process according to the first embodiment.

FIG. 7 is a flowchart of a normal method activation process according to the first embodiment.

FIG. 8 is a flowchart of a normal method activation process according to the first embodiment.

FIG. 9 is a flowchart of a method activation process by the same request according to the first embodiment.

FIG. 10 is a flowchart of a method activation process by the same request according to the first embodiment.

FIG. 11 shows a corresponding request analysis process in the first embodiment.

FIG. 12 is a diagram showing an example of an object-oriented system configuration for implementing a method activation method according to the present invention in a second embodiment.

FIG. 13 is a configuration diagram of a request queue table according to the second embodiment.

FIG. 14 is a configuration diagram of a class policy repository according to the second embodiment.

FIG. 15 is a diagram illustrating a method call limit time table according to the second embodiment.

FIG. 16 is a diagram showing an example of an object-oriented system configuration for implementing a method activation method according to the present invention in a third embodiment.

FIG. 17 is a flowchart of a class policy statistical process according to the third embodiment.

FIG. 18 is a diagram illustrating an example of an object-oriented system configuration that implements a method activation method according to the present invention in a fourth embodiment.

FIG. 19 is a diagram showing an example of a method call aggregation table configuration according to the fourth embodiment.

FIG. 20 is a flowchart of a relevant request analysis process according to the fifth embodiment.

FIG. 21 is a diagram illustrating an example of a class policy repository configuration according to the sixth embodiment.

FIG. 22 is a configuration diagram of a method call table according to the sixth embodiment.

FIG. 23 is a diagram illustrating an example of an object-oriented system configuration that implements a method activation method according to the present invention in a seventh embodiment.

FIG. 24 is a flowchart of a class policy repository update information distribution process according to the seventh embodiment.

FIG. 25 is a diagram showing an example of an object-oriented system configuration for implementing a method activation method according to the present invention in the eighth embodiment.

FIG. 26 is a diagram illustrating an example of a request queue table configuration according to the eighth embodiment.

FIG. 27 is a flowchart of an identical request comparison process according to the eighth embodiment.

FIG. 28 is a flowchart of the same server search process according to the eighth embodiment.

FIG. 29 is a system configuration diagram of a conventional example.

FIG. 30 is a diagram showing a conventional message system.

FIG. 31 is a diagram showing a data structure of a conventional example.

[Explanation of symbols]

1 Object execution environment section, 2 class policy input interface, 3 clients, 4 servers, 101
Object management unit, 102 class policy management unit, 103 class policy repository, 104 message communication management unit, 105 class policy statistical processing unit, 106 class policy update information distribution unit, 301
Client logic section, 302 client message communication management section, 401 server logic section, 402
Request queue management unit, 403 request queue table, 404 request dispatch unit, 405 server message communication management unit, 406 method call table, 407 method call limit time table, 408 method call total table, 409 request comparison unit, 4011 method, 4012 object Part, T0101 accumulation number, T0102 object type, T0103 method type, T0104
Parameter 1 information, T0105 Parameter 2 information,
T0106 return information, T0107 registration time, T0
108 processing result, T0201 class type, T020
2 Method type, T0203 Parameter 1 information, T
0204 parameter 2 information, T0205 return information, T0206 boundary accumulation number, T0207 limit time,
T0208 Minimum accumulation number, T0301 Object type, T0302 Method type, T0303 Parameter 1 information, T0304 Parameter2 information, T0305
Return information, T0306 boundary accumulation number, T0307
Number of accumulation, T0308 Minimum accumulation number, T0401 class type, T0402 method type, T0403 limit time, T0501 class type, T0502 method type, T0503 Number of accumulation, M0101 to M0102, M
0201 to M0206, M0301 to M0323, M0
402 to M0414, M0501 to M0503, M06
01 to M0602, M0701 to M0706, M080
1 to M0805, M0901 to M0906 Message, 3001 computer program, 3002 computer platform, 3003 application program, 3004 object-oriented programming, 3005 database management device, 3006 operating system, 3007 micro instruction code, 3008 input / output interface, 3009 RA
M, 3010 CPU, 3011 input / output interface, 3012 connection cable, 3013 terminal device, 3
014 connection cable, 3016 user, 3017
Connection cable, 3018 Data storage device, 3019
External database, 3020 connection cable, 3021
Printer, 3121 Method A, 3122 Method B, 3123 Object Management Table, 3124 Data Frame, 3125 Loaded Class Table, 3126 Signal Line, 3127 Signal Line, 3128 Signal Line, 3129
Signal line, 3130 messenger, 3101 object identification configuration, 3102 object identification column, 31
03 access address, 3104 format, 3105 class identifier, 3106 instance identifier, 3107
Object management table (OMT), 3108 object identification column, 3109 instance data frame address.

Claims (13)

[Claims] 1. A method starting method for receiving a request for starting a method for processing data transmitted from a client, wherein a server for starting the method, a request from the client is received, and the received request is sent to the server. And an object execution environment unit for transmitting. The object execution environment unit further includes, as a class policy, a plurality of method information for specifying a method and a plurality of processing conditions for defining a condition for processing a plurality of requests collectively. The server further comprises a class policy repository for storing a class policy, wherein the server further searches the class policy repository, specifies a class policy to which the received request belongs based on method information, and performs a plurality of processes of the specified class policy. Conditions and requests Request queue management unit that manages the request accumulation status as the status of receiving the request, a method call table that stores the multiple processing conditions managed by the request queue management unit and the request accumulation status, And, referring to the above method call table, if the request accumulation status of the class policy to which the request belongs satisfies the plural processing conditions, the above processing result is returned to each of the plural clients that transmitted the request. And a request dispatch unit for processing a plurality of requests collectively. 2. The method starting method further comprises a class policy input interface for inputting the class policy, wherein the object execution environment unit receives the input class policy, and converts the received class policy into the class policy. 2. The method starting method according to claim 1, further comprising a class policy management unit for writing to a repository. 3. The request accumulation state is the accumulation number of received requests. The plurality of processing conditions is a boundary that defines a boundary value of the accumulation number of requests when the request dispatcher processes a plurality of requests collectively. 2. The method activation method according to claim 1, wherein the request dispatch unit processes a plurality of requests when the number of stored requests is equal to or larger than the boundary storage number. 4. The multiple processing condition includes a limit time indicating a limit time from when the request is received by the request queue management unit to when the request is processed, and the server further includes a request reception order. A request queue table for registering the request in the request queue management unit. The request queue management unit registers the received request in the request queue table,
The time at which the request was received is registered as a registration time, the method call table stores the limit time as a plurality of processing conditions, and the request dispatch unit obtains the limit time of the class policy to which the request belongs from the method call table. , A request to start a method having the same method information as the method information of the method to be started is detected from the request queue table, a request that exceeds the limit time from the registration time of the detected request is extracted, and the extracted request is transmitted. 2. The method activation method according to claim 1, wherein the processing result is returned to a client that has performed the method. 5. The class policy statistical processing for changing the plurality of processing conditions by reading the request accumulation status for each class policy from the method call table and analyzing the read request accumulation status. 4. The method starting method according to claim 3, further comprising a unit. 6. The method according to claim 1, wherein the method information includes a method type for specifying a processing content of the method, and a parameter that the client passes to the method.
Or the method invocation method described in 3. 7. The method information includes a method type for specifying the processing content of the method, and the request dispatch unit is specified by a request last received by a message management unit among requests having the same method information. 4. The method starting method according to claim 3, wherein the method is started using a parameter passed to the method. 8. The request dispatching unit processes requests in the order in which the request queue management unit receives the requests. When the accumulated number of requests to be processed reaches the boundary accumulation number, the request dispatching unit processes a plurality of requests. 4. The method starting method according to claim 3, wherein the method is processed. 9. The request dispatcher searches a stored number of requests stored for each class policy, detects a class policy in which the stored number of requests is equal to or larger than the boundary storage number, and detects the detected class. 4. The method activation method according to claim 3, wherein requests belonging to the policy are processed. 10. The object execution environment unit further receives a class policy input from a class policy input interface from the class policy management unit, and sets a plurality of processing conditions of the received class policy as update information in a request queue of a server. 3. The method activation method according to claim 2, further comprising a class policy update information distribution unit that distributes the plurality of processing conditions to a method call table. 11. The request accumulation state is an accumulation number of received requests, and the plurality of processing conditions is a minimum value that defines a lower limit of the number of accumulated requests when the request dispatcher processes a plurality of requests collectively. The request queue management unit searches the method call table for a request in which the request accumulation number is equal to or greater than the minimum accumulation number, notifies the request dispatch unit of the detected request, 2. The method activation method according to claim 1, wherein the request dispatch unit processes a plurality of requests for the request notified from the request queue management unit. 12. The method starting method includes a plurality of servers, a request dispatch unit stores a processing result of starting the method, and the server further starts a method having the same method information as a method started by itself. 2. The method activation method according to claim 1, further comprising a request comparison unit for comparing and searching for another server that performs the search, and distributing a processing result stored to the searched server. 13. A method for activating a method on a computer-readable recording medium storing a program for causing a computer to operate as a method activating method for receiving a request for activating a method for processing data transmitted from a client. And an object execution environment unit that receives a request from the client and sends the received request to a server. The object execution environment unit further collects method information specifying a method and a plurality of requests. A class policy repository for storing a plurality of class policies with a plurality of processing conditions defining a condition to be processed as a class policy. The server further searches the class policy repository to find a class to which the received request belongs. A request queue management unit that specifies a policy based on method information and manages a plurality of processing conditions of the specified class policy and a request accumulation status as a status of receiving a request, and a plurality of processes managed by the request queue management unit A method call table that stores the conditions and the request accumulation status, and a method is invoked to obtain the processing result, and the method call table is referred to, and the request accumulation status of the class policy to which the request belongs satisfies the plural processing conditions. In the case where there is a recording of a program for operating a computer as a method activation method including a request dispatch unit for returning the above processing result to each of a plurality of clients that issued the request and processing the plurality of requests collectively did Method Invocation method characterized by comprising the computer-readable recording medium.