JPH10240663A - Service management system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To shorten the waiting time of a user when position information of the new server is registered in a trader by permitting a service preservation object to preserve position information of the new server and a service attribute when the new server is judged to be the server suitable for the policy of a client. SOLUTION: When a service name necessary for the client 40 and a policy at the time of receiving service are inputted, a filter object 50 informs a service retrieval object 70 of necessary service and position information on the filer object 50. A service retrieval object 70 preserves service which the client 40 requests and position information of the filter object 50, retrieves the server which the client 40 requests for the trader 30 and returns it to the filter object 50. The filer object 50 decides the server suitable for the policy of the client 40. The service preservation object 60 preserves position information of the server and a filter result.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a service management system for managing location information of a server in a client / server system in order to promptly receive a service from an optimal server for the client.

[0002]

FIG. 12 is a block diagram showing a conventional service management system SC11 using a trader T1.

[0003] The conventional service management system SC11 comprises:
, SVm are provided in each of the plurality of nodes N11,..., N1m, the trader 21 is provided in the node 21, and the plurality of nodes N31,.
, Cn are provided in each of the servers SV1,..., SVn and the clients C1,..., Cn are distributed and arranged. The trader 21 searches for the server requested by the service attribute using the service attribute as a keyword.

[0004] That is, for example, the client C1
In order to receive a service having a desired service attribute, first, the client C1 sends a desired service attribute to the trader T1, and based on the service attribute, the trader T1 determines a location of a server that provides a service having the service attribute. Information is retrieved, the trader T1 returns the retrieved server location information to the client C1, and the client C1 connects to the server SV1 by using the returned location information of the server SV1, and a desired service is transmitted from the server SV1. Receive.

[0005]

However, in the conventional service management system SC11 using only the mechanism of the trader, every time each of the clients C1 to Cn requests each service, the servers SV1 to SVm are used.
Since the trader T1 searches the required server from among the above, the same number of times as the number of times the trader T1 receives the service,
The trader T1 searches. For this reason, there is a problem that the load of the trader T1 increases as the number of times each client requests a service increases. Also, as the number of requests for a service increases, each client requests a service and then increases the load. There is a problem that the waiting time until the service can be actually received is long.

FIG. 13 is a block diagram showing a conventional service management system SC12 using the cache function CS1.

[0007] The conventional service management system SC12 comprises:
A cache function is provided for each node having a client, and each cache function stores a service provided by each server and location information of the server. For example, the node N31 includes a client C1 and a cache function CS1.

[0008] For example, when the client C1 tries to receive necessary services from the server SV1,
First, the client C1 searches the cache function CS1 for a server SV1 that should provide the service requested by the client C1, and if the corresponding server SV1 exists, the client C1 receives the position information of the server SV1, and Server SV1 to client C1
Receives the service. Therefore, since a cache function for searching for a required service is provided in each node, the time for searching for a required service is short, and therefore, the time from when a user requests a service to when the user actually receives the service is required. There is an advantage that the waiting time can be reduced, and the operation of searching for a required service is performed by each cache function, so that the load on the trader T1 can be reduced.

However, the conventional service management system S
In C12, if the server SV1 providing the service requested by the client C1 is not stored in the cache function CS1, the trader T1 searches for the position information of the server SV1 providing the service requested by the client C1. Therefore, the conventional service management system S
In C12, if the information of the server to be accessed is not stored in the cache function, the time required to search for the required service becomes longer, and the waiting time from when the user requests the service to when the user actually receives the service becomes longer. The problem remains that the load on the trader T1 increases.

That is, in the prior art, since no new data is stored in the cache function, the position information of the new server is stored in the trader, and the service provided by the new server is suitable for the client. In this case, there is a problem that the waiting time from when the user requests the service to when the user actually receives the service becomes long, and there is a problem that the load on the trader increases. Also, if the service provided by the server is changed, the service after the change is not included in the old data stored in the cache function. However, there is a problem that the waiting time from requesting the service to actually receiving the service becomes longer, and that the load on the trader increases.

According to the present invention, when the position information of a new server is registered in a trader or the service provided by the server stored in the trader is changed, the user requests the service and then changes the service. It is an object of the present invention to provide a service management system capable of shortening a waiting time until actually receiving a service and suppressing a load on a trader.

[0012]

According to the present invention, the filter object is notified that the location information of the new server and the service attribute of a predetermined service provided by the new server are newly stored in the trader. If the filter object determines that the new server is a server suitable for the policy of the client, the service storage object stores the position information and the service attribute of the new server in the service storage object.

[0013]

DESCRIPTION OF THE PREFERRED EMBODIMENTS FIG. 1 is a block diagram showing a service management system SC1 according to one embodiment of the present invention.

The service management system SC1 has a plurality of nodes N1, N2, N3. The node N1 has a server 20, the node N2 has a trader 30 and a service search object 70, and the node N3 has a client 40, a filter object 50, and a service storage object 60.

The service management system SC1 includes:
A plurality of nodes having servers such as the server 20 are provided,
The node N1 is an example of the plurality of nodes. The service management system SC1 includes a client 4
0, a plurality of nodes having a filter object 50 and a service storage object 60, and a node N3
Is an example of the plurality of nodes.

The filter object 50 receives a service name of a service required for the client 40 and a policy for receiving the service (specific contents of a service attribute desired by the client 40 among service attributes attached to the service). Then, the service search object 70 is notified of the required service and the position information of the filter object 50.

The following are examples of service names, service attributes, and policies. That is, if the service name is, for example, "movie", its service attributes are "action", "fee", "server location".
For example, the service attribute “action” may be “hard” or “natural”, and the service attribute “charge” may be “high” or “cheap”. The service attribute “server location” may be “distant” or “close”.

The service search object 70 stores necessary services and the position information of the filter object 50,
When notified from the filter object 50, the service requested by the client 40 and the position information of the filter object 50 are stored, and the server 20 requested by the client 40 is searched for the trader 30. Return to 50.

The filter object 50 determines a server suitable for the policy of the client 40. The service storage object 60 stores the server location information and the filter result. Further, when a new server is registered in the trader 30, the service search object 70 performs a service search by a method designated in advance, and notifies the result only to the filter object 50 registered in the service search object 70. .

Further, the filter object 50 determines a server suitable for the policy of the client 40 among the servers stored in the service storage object 60 and the added server. The service storage object 60 stores the location information of the server determined by the filter object 50 and the filter result indicating how suitable the service provided by the server is to the policy. When the service of the server stored in the trader 30 is changed, the service search object 70 performs a service search by a method designated in advance, and outputs the result only to the filter object 50 registered in the service search object 70. Notify.

The filter object 50 determines whether or not the change is suitable for the policy of the client 40. If the change is determined to be preferable, only the filter result of the service storage object 60 is changed. If it is determined that the change is not a suitable change, the service search object 70 searches for a server that provides a necessary service to the client 40, receives the result, and determines a server suitable for the policy of the client 40 from the received result. Then, the service storage object 60 stores the position information of the server 20 and the filter result.

The service search object 70 is
When the server stored in the trader 30 is deleted,
A service search is performed by a method designated in advance, and the search result is notified only to the filter object 50 registered in the service search object 70.

The filter object 50 corresponds to the trader 3
Server deleted from service storage object 6
0, and the service equivalent to the service provided by the deleted server is a service storage object 6
If it is not stored in 0, the service search object 70 searches for a server that provides the service required by the client 40, receives the result, and, based on the received result, a suitable policy for the client 40. The server is determined, and the service storage object 60 stores the location information of the server 20 and the filter result.

FIG. 2 is a diagram showing in detail the filter object 50, the service storage object 60, and the service search object 70 in the service management system SC1.

When the client 40 requests a service, the service management system SC1 sends a request to the server suitable for the client 40 (a preferable server among a plurality of servers including the server 20) without inquiring the trader 30.
It is a system that can promptly request a service.

The filter object 50 has a service notification function 51, a filter table 52, and a filter function 53.

The service storage object 60 has a search function 61, a storage table 62, and a writing function 63.

The service search object 70 has a service search function 71, a service registration function 72, a search result receiving function 73, and a search table 74.

Next, the operation of the service management system SC1 will be described.

FIG. 3 is a flowchart showing the operation of registering the service name, service attribute, and server in the storage table 62 in the above embodiment.

First, the client 40 sends a service name, a service attribute, and a policy to the filter object 50 for a service that may be provided in the future, and stores these data in the filter table 52.
Is stored (S1). Then, the notification function 51 retrieves the service name and service attribute stored in the filter table 52 (S2), and retrieves the retrieved service name,
The service attribute is sent to the service search object 70 together with the position information of the own filter object 50 (S3).

The service registering function 72 stores each data received from the service notifying function 51 in the search table 74 (S4), passes the pointer of the search table 74, and requests the service search function 71 to search (S5). ,
The service search function 71 searches for a service attribute from the search table 74 (S6). Then, based on the service name and the service attribute, the trader 30 searches for the position of the server that can provide the service of the service name (S7).

Then, based on the service name, the position of the filter object 50 which is the destination to which the above-mentioned searched server position is to be sent is searched from the search table 74 (S8). Then, the service name, service attribute, and server location are sent (S9).

The service attribute obtained in this way is
The filter function 53 determines and outputs a filter result indicating how much the policy matches the policy of the client 40 (S
10). If the filter result is equal to or greater than a predetermined threshold L1 (the filter result is, for example, the degree of conformity with the policy is 80%, and the threshold L1 is, for example, 60%) (S11), the service storage object 60 After sending out the name, service attribute, filter result, and server position (S12), it is stored in the storage table 62 (S12).
13).

On the other hand, if the filter result is a predetermined threshold L
If it is smaller than 1, the data received by the filter function 53 is discarded (S15). If there is an object to be registered in the service storage table 60 (S14), the above operation (S1 to S1) is performed.
15) is repeated, and if there are no more objects to be registered, the process ends.

FIG. 4 is a diagram showing in detail the filter object 50, the service storage object 60, and the service search object 70 in the service management system SC1, and is a block diagram particularly explaining a server search operation based on a client request. .

FIG. 5 is a flowchart showing a server search operation based on a client request in the above embodiment.

First, the service name and service attribute of the service desired by the client 40 are sent to the service storage object 60 (S21). Based on the service name and service attribute received by the search function 61 from the client 40, a server position is searched from the storage table 62 (S22), and the searched server position is searched.
Is sent to the client 40 (S23). And
The client 40 connects to the server at the server position received from the search function 61 and receives a desired service (S2).
4).

In this case, the service management object 60
Is provided in the node N3 in which the client 40 is provided.
Since the number of clients accessing the service is small, the waiting time from when the client 40 requests the service to when the user actually receives the service can be shortened.
Further, the load on the trader can be reduced.

When the client 40 issues a service request to the service storage object 60, if the number of service names stored in the storage table 62 is zero, as described later, the service storage object 6
Since 0 responds that the search target is zero, the time until the response result is obtained in the above-described embodiment is shorter than in this case, compared with the case where the trader 30 retrieves and an answer is output.

FIG. 6 is a diagram showing in detail the filter object 50, the service storage object 60, and the service search object 70 in the service management system SC1, and is a block diagram for explaining the operation particularly when a new server is added.

FIG. 7 is a flowchart showing the operation when a new server is added in the above embodiment.

First, the fact that a new server has been added,
The trader 30 notifies the service search object 70 (S31). Based on the service name received from the trader, the service search function 71 searches for a service attribute from the search table 74 (S32), and stores the searched service attribute and the service name corresponding to this service attribute in the service search function 71. Is sent to the trader 30 (S3
3). Then, the trader 30 searches for the corresponding server position (S34), searches the search table 74 for the position of the filter object 50 that is the destination to which the searched server position information is to be sent (S35), and the search is performed. The notification of the addition of the trader, the server position, the service name, and the service attribute are sent to the filter object 50 existing at the position (S36).

The filter function 53 retrieves the filter result R1 corresponding to the service name received from the storage table 62 (S37). If the same service as the service name received by the filter function 53 does not exist in the storage table 62 (S37). S38) In other words, if the same service as the service provided by the new server does not exist in the storage table 62, this service is an object to be stored in the storage table 62, and the following processing is executed. That is, the filter function 53 determines a filter result indicating how much the service attribute of the service provided by the new server matches the policy of the client 40 (S44), and determines whether the filter result is equal to or greater than the predetermined threshold L1. If there is any (S45), the service name, service attribute, filter result, and server location are sent to the service storage object 60 (S46), and these data are stored in the storage table 62 (S47).
If the filter result is smaller than the predetermined threshold L1, the data received by the filter function 53 is discarded (S
48).

On the other hand, if the same service as the service name received by the filter function 53 exists in the storage table 62 (S38), it indicates to what extent the service attribute received from the service search object 70 matches the policy. The filter result R1n is calculated (S40). If the filter result R1n is smaller than R1 (S41), the data received from the service search object 70 is discarded because there is no need to update (S43), and the filter result R1n is obtained.
Is equal to or greater than R1 (S41), the same service name in the service storage object 60 is updated (S42).

FIG. 8 is a diagram showing in detail the filter object 50, the service storage object 60, and the service search object 70 in the service management system SC1, and is a block diagram for explaining the operation when the service contents of the server are changed.

FIG. 9 is a flowchart showing the operation when the service content of the server is changed in the above embodiment.

First, the trader 30 notifies the service search object 70 that the service content of the server has been changed.
(S51). On the basis of the service name received from the trader 30, the service search function 71 searches for a service attribute from the search table 74 (S52), and searches the searched service attribute and the service name corresponding to this service attribute for the service search function 71. Is sent to the trader 30 (S53). Then, the trader 30 searches for the corresponding server position (S54), searches the search table 74 for the position of the filter object 50 that is the destination to which the searched server position information should be sent (S55), and searches the searched position. The server sends the notification of the change of the trader, the server position, the service name, and the service attribute to the filter object 50 existing in (1) (S56).

The filter function 53 retrieves the filter result R1 corresponding to the service name received from the storage table 62 (S57), and the filter result R1 corresponding to the service name received by the filter function 53 exists in the storage table 62. If not (S58), since there is no object to be changed in the storage table 62, the server position, service name, and service attribute sent from the search result receiving function 73 are discarded (S59).

On the other hand, if the filter result R1 corresponding to the service name received by the filter function 53 exists in the storage table 62 (S58), the target to be changed is in the storage table 62. A filter result R1r indicating how much the received service attribute matches the policy is calculated (S60). If the filter result R1r is equal to or greater than R1, (S6
1) Update the same service name in the service storage object 60 (S62). On the other hand, the filter result R1r
Is smaller than R1 (S61), the data received from the service search object 70 is discarded (S6).
3).

FIG. 10 is a diagram showing in detail the filter object 50, the service storage object 60, and the service search object 70 in the service management system SC1, and is a block diagram particularly explaining the operation when a server is deleted.

FIG. 11 is a flowchart showing the operation at the time of deleting a server in the above embodiment.

First, the trader 30 notifies the service search object 70 that the server has been deleted (S
71). Based on the service name received from the trader 30, the service search function 71 searches for a service attribute from the search table 74 (S72), and compares the searched service attribute with the service name corresponding to this service attribute. 71 sends it to the trader 30 (S7).
3). Then, the trader 30 searches for the corresponding server position (S74), searches the search table 74 for the position of the filter object 50 that is the destination to which the searched server position information is to be sent (S75), and searches the searched position. The server sends the notification of the deletion of the trader, the server position, the service name, and the service attribute to the filter object 50 existing in (1) (S76).

Then, the service name of the server to be deleted,
The service attribute and the location of the server are sent to the service storage object 60 (S77).
The corresponding data is deleted (S78).

Here, the filter function 53 is the search function 6
The remaining number of service names stored in the storage table 62 is detected via 1 (S79), and if the remaining number of service names is not zero (some service names are stored in the storage table 62). If there is no problem, but the remaining number of the service name is zero (if no service name is stored in the storage table 62) (S80), the waiting time when the client 40 executes the service search. The following processing is performed to prevent the search for the long trader 30 from being executed.

That is, the filter function 53 passes the service name (the service name obtained from the filter table 52 or the like) and the position information of the filter object to the service search function 71 (S81).
Searches for a service attribute from the search table 74 (S
82). Then, based on the service name and the service attribute, the trader 30 searches for the position of the server that can provide the service of the service name (S83). Based on the service name, the position of the filter object 50 which is the destination to which the searched server position is to be sent is searched from the search table 74 (S84). The attribute and the server position are sent (S85).

The service attribute obtained in this way is
The filter function 53 determines a filter result indicating how much the policy matches the policy of the client 40 (S8).
6). If the filter result is equal to or more than a predetermined threshold L2 (the filter result is, for example, the degree of matching with the policy is 80%, and the threshold L2 is, for example, 40%) (S87), the service storage object 60 After sending out the name, service attribute, filter result, and server position (S88), it is stored in the storage table 62 (S8).
9). On the other hand, if the filter result is smaller than the predetermined threshold L2, the data received by the filter function 53 is discarded (S90). The threshold L2 used in step S11 is used as the threshold L2 used in step S87.
A value lower than 1 may be set. Threshold L2 is changed to threshold L1
When the data to be stored in the storage table 62 cannot be obtained when the same value is set as the threshold L2, the threshold L2 is set to the threshold L1.
By setting to a lower value, the storage table 6
There is a possibility that data to be stored in 2 can be obtained.

The service name is 1 in the storage table 62.
If none is stored, based on the service name retrieved again from the filter table 52, as described above,
Instead of storing service attributes and server location information from the trader 30 in the storage table 62, the client 40
At the time of server location search from, the search function 61 may be instructed to reply that the search target does not exist, such as "the search target does not exist in the storage table". Even in this configuration, when no service name is stored in the storage table 62, the trader 30 is not made to search when searching for the server position from the client 40, so that it is possible to prevent the waiting time from becoming long. .

According to the above embodiment, when the position information of a new server is registered in the trader or when the service provided by the server stored in the trader is changed,
Since the data stored in the storage table 62 is updated, when the client 40 searches for a service, new data is always stored in the storage table 60, and a new server can be registered and a server can be quickly changed. Therefore, since the trader does not have to search, the waiting time from when the user requests the service until the user actually receives the service can be shortened, and the storage table 62 can sufficiently cope with the service search. Thus, the load on the trader can be reduced.

[0060]

According to the present invention, when the position information of a new server is registered in the trader or when the service provided by the server stored in the trader is changed, the user requests the service. And the waiting time until the service is actually received can be shortened, and the load on the trader can be reduced.

[Brief description of the drawings]

FIG. 1 is a block diagram of a service management system SC1 according to an embodiment of the present invention.

FIG. 2 is a diagram showing in detail a filter object 50, a service storage object 60, and a service search object 70 in the service management system SC1.

FIG. 3 is a flowchart showing an operation of registering a service name, a service attribute, and a server in a storage table 62 in the embodiment.

FIG. 4 is a diagram illustrating in detail a filter object 50, a service storage object 60, and a service search object 70 in the service management system SC1, and is a block diagram illustrating a server search operation based on a client request, in particular.

FIG. 5 is a flowchart showing a server search operation based on a client request in the embodiment.

FIG. 6 is a diagram showing in detail a filter object 50, a service storage object 60, and a service search object 70 in the service management system SC1, and is a block diagram for explaining an operation particularly when a new server is added.

FIG. 7 is a flowchart showing an operation when a new server is added in the embodiment.

FIG. 8 is a diagram showing in detail a filter object 50, a service storage object 60, and a service search object 70 in the service management system SC1, and is a block diagram for explaining an operation particularly when the service content of the server is changed.

FIG. 9 is a flowchart showing an operation when the service content of the server is changed in the embodiment.

FIG. 10 shows a filter object 50, a service storage object 60,
FIG. 3 is a diagram showing a service search object 70 in detail;
FIG. 4 is a block diagram illustrating an operation when a server is deleted.

FIG. 11 is a flowchart showing an operation at the time of deleting a server in the embodiment.

FIG. 12 is a block diagram showing a conventional service management system SC11 using a trader T1.

FIG. 13 is a block diagram showing a conventional service management system SC12 using a cache function CS1.

[Explanation of symbols]

 SC1: Service management system, N1, N2, N3: Node, 20: Server, 30: Trader, 40: Client, 50: Filter object, 51: Service notification function, 52: Filter table, 53: Filter function, 60: Service Storage object, 61: search function, 62: storage table, 63: writing function, 70: service search object, 71: service search function, 72: service registration function, 73: search result receiving function, 74: search table.

Claims (9)

[Claims] 1. A server that provides a predetermined service, a client that receives a service from each server, location information of each server, and a service name and service attribute of the service provided by each server are stored. In a service management system having a trader, a service storage object that stores location information of a server suitable for the policy of the client and a service name of a service that can be provided by a server suitable for the policy of the client; The service name of the service desired to be used, the service attribute and the policy of the service desired by the client are stored, and the location information of the server and the service name stored in the service storage object are stored in the service. Depending on the degree to which the attribute matches the policy , A filter object to be registered and changed; and when the filter object is notified that the location information of the new server and the service attributes of the services that can be provided by the new server are newly stored in the trader. Service management, characterized in that, if the filter object determines that the new server is a server suitable for the policy of the client, the service storage object stores location information and service attributes of the new server. system. 2. The method according to claim 1, wherein when the filter object is notified that a service that can be provided by a server corresponding to the server location information stored in the service storage object has been changed, the filter object has changed. If the filter object determines that the degree of conformity of the policy in the service is higher than the degree of conformity of the policy in the service before the change, the service attribute before the change corresponding to the corresponding service name is changed after the change. A service management system, wherein the service storage object changes to the service attribute of (1). 3. The server according to claim 1, wherein a request for registration, change, or deletion of a service provided by the server to the client is sent from the server to the trader, and the registration, change, or deletion of the service is performed. Is executed by the trader, performs a service search for searching for a location of a server that provides a predetermined service, and has a service search object for notifying the filter object of the result of the service search. The service search object Stores the service name and service attribute requested by the client and the location information of the filter object, detects the registration / change / deletion information of the server stored by the trader, and registers the searched server.・ Change / delete information is stored in the file registered in the service search object. Service management system and notifying only the object. 4. The server according to claim 1, wherein the filter object is an object for outputting a suitable degree of the server checked based on a policy of the client, and the service storage object is a server storage object of the server. A service management system, which is an object for storing a suitable degree and position information. 5. The server according to claim 1, wherein, when notified that a new server has been added to the trader, the filter object includes server location information stored in the service storage object; It is determined whether or not to change the degree of the new server, which is checked based on the policy of the client, and if it is determined that the new server is more suitable, the position information of the new server and the new A service management system, wherein the service management system is an object for changing a suitable degree of a server. 6. The method according to claim 1, wherein when the filter object is notified that a service of the server stored in the trader has been changed, the change of the service is notified to the policy of the client. It is determined whether or not the change is preferable, and if it is determined that the change is preferable, only the suitable degree of the server is changed. A service management object for causing a service search object to search, searching for a server suitable for the policy of the client based on the search result, and changing the location information of the server and the degree of the server suitable; system. 7. The filter object according to claim 1, wherein, when notified that the server stored in the trader has been deleted from the trader, the filter object deletes the server deleted from the trader. Delete, if no service equivalent to the service provided by the server exists in the service storage object,
The server of the service is searched by the service search object, a server suitable for the policy of the client is searched based on a search result of the service search object, and location information of the server and a suitable degree of the server are stored. A service management system characterized by being an object. 8. The service storage object according to claim 1, wherein the service storage object has a storage table for storing a service name and server location information, and stores the service name in the storage table when the server is deleted. When the number of service names to be reduced to zero, based on the service name and the policy registered in the filter object, the service name newly retrieved from the trader and the location information of the server are stored. A service management system characterized by being an object. 9. The service storage object according to claim 1, wherein the service storage object has a storage table for storing a service name and server location information, and is stored in the storage table when the server is deleted. When the number of service names to be reduced becomes zero, an object that notifies the client that there is no server location information to be searched in the storage table when the client requests service search from the client. A service management system, characterized in that: