WO2013145197A1 - 分散処理におけるサービス検索方法、プログラム、およびサーバ装置 - Google Patents

分散処理におけるサービス検索方法、プログラム、およびサーバ装置 Download PDF

Info

Publication number
WO2013145197A1
WO2013145197A1 PCT/JP2012/058268 JP2012058268W WO2013145197A1 WO 2013145197 A1 WO2013145197 A1 WO 2013145197A1 JP 2012058268 W JP2012058268 W JP 2012058268W WO 2013145197 A1 WO2013145197 A1 WO 2013145197A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
information
search
server
service search
Prior art date
Application number
PCT/JP2012/058268
Other languages
English (en)
French (fr)
Inventor
山本哲
川島和也
Original Assignee
富士通株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 富士通株式会社 filed Critical 富士通株式会社
Priority to JP2014507163A priority Critical patent/JP5979223B2/ja
Priority to PCT/JP2012/058268 priority patent/WO2013145197A1/ja
Publication of WO2013145197A1 publication Critical patent/WO2013145197A1/ja
Priority to US14/461,593 priority patent/US20140358967A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/951—Indexing; Web crawling techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload

Definitions

  • the present invention relates to a service search method, a program, and a server device in a distributed processing system.
  • the client requests a search to a specific server
  • the specific server searches the status of other servers, selects a server that meets the request, and replies to the client.
  • the specific server inquires whether the requested server can be accepted, and if not accepted, selects another server and continues the inquiry until it can be accepted.
  • this prior art has a problem that when the number of search requests from clients on the network increases, the load on a specific server that accepts the search requests increases.
  • this prior art discloses a technique in which a plurality of service processing devices cooperate based on an instruction, and the service processing device must also cooperate while making an inquiry to a specific server called a search server. I must. For this reason, this conventional technique also has a problem that the load on a specific server increases.
  • an object of the present invention is to avoid load concentration on a specific server.
  • a service search method in a plurality of servers that perform a service wherein route information is generated by exchanging server attribute information with another server, and a service search request is issued from a service search request source Is received by referring to its own attribute information to determine whether or not it matches the service search condition stored in the service search request, and if it is determined that the match is not established, Based on the route information, a server that has no search record in the search history information added to the service search request is selected, and the server that has selected the service search request with the information of its own server added as the search history information is the selected server. If it is determined that a match is established, the search request response is service-searched based on the route information generated by its own server. Provided that the notice to the requester.
  • FIG. 1 is a configuration diagram of a server node 100 that is a server device that performs a service in which a plurality of apparatuses are connected to each other via a network according to an embodiment of the present invention.
  • An attribute information database (hereinafter referred to as “attribute information DB”) 101 accumulates attribute information including service information and resource information regarding its own server node 100.
  • the route information notification unit 102 periodically refers to the attribute information DB 101 to generate, for example, a Hello message 113 including service information and resource information related to the own server node 100. Then, the route information notification unit 102 periodically notifies the Hello message 113 to the other server nodes 100 connected to the network via the message transmission unit 103, for example.
  • the message receiving unit 104 receives a message from another server node 100.
  • the message distribution unit 105 distributes the Hello message 113 to the route information generation unit 106 and the search request message 114 to the search determination unit 108 among the messages received by the message reception unit 104.
  • the route information generation unit 106 generates route information based on the attribute information included in the Hello message 113 from the other server node 100 received via the message reception unit 104 and the message distribution unit 105. At this time, for example, the route information generation unit 106 adds the priority of the service search calculated based on the attribute information to the route information. Then, the route information generation unit 106 updates the route information database (hereinafter referred to as “route information DB”) 107 so as to include the generated route information. That is, the route information DB 107 is a database that accumulates route information generated by the route information generation unit 106 based on attribute information exchanged with the other server node 100.
  • the search determination unit 108 executes the following operation.
  • the search determination unit 108 determines whether or not it matches the service search condition stored in the service search request message 114 by referring to its own attribute information stored in the attribute information DB 101.
  • the server node 100 having no search results in the search history information added to the service search request message 114 is stored in the route information DB 107. Select based on the current route information. At this time, for example, the search transfer unit 109 selects the server node 100 having a high priority included in the route information. Then, the search transfer unit 109 transfers the service search request message 114 to which the information of its own server node 100 is added as search history information to the selected server node 100 via the message transmission unit 103.
  • the search result notification unit 110 executes the following process when the search determination unit 108 determines that a match is established.
  • the search result notification unit 110 sends a search result message 115, which is a response to the service search request message 114, to the service search request message 114 via the message transmission unit 103 based on the route information generated by the server node 100 of itself. Notify the requester.
  • the service registration unit 111 registers or deletes service information of the local server node 100 accumulated in the attribute information DB 101.
  • a human may manually register a service using a human interface, or may be registered by batch processing (API or command) at the time of machine startup.
  • the node information monitoring unit 112 monitors the resource of its own server, and updates the service information and resource information of the own server node 100 accumulated in the attribute information DB 101 based on the monitoring result.
  • the service search request message 114 from the client node is received by any server node 100 among the plurality of server nodes 100 connected by the network. If the received service search request message 114 cannot be processed by the own node, the service search request message 114 is transferred to another server node 100 determined from the route information DB 107. If any server node 100 can process the service search request message 114 in its own node, the search process is executed, the search result is stored in the search result message 115, and the service search request message 114 is requested. Notify the original client node, for example. With such a control operation, it is not necessary to concentrate on a specific node for service search, and load distribution becomes possible. Based on the route information exchanged in advance with each other, it is possible to determine the optimum service execution node at the time of search.
  • C1 indicates a client node
  • SX indicates a service search server node.
  • the configuration of FIG. 2 has a configuration in which these nodes are connected to each other in one subnet 201.
  • the following processes (1) to (4) correspond to the processing arrows (1) to (4) in FIG. 2, respectively.
  • the service search server node SX that has received a search request from the client node C1 performs a search and returns a result to the client node C1.
  • Information on each server node is collected in the service search server node SX and registered in the database.
  • the service search server node SX receives a service search request from the client node C1.
  • the service search server node SX refers to its own database, selects the server node Si that meets the request of the client node C1, and inquires whether it can be accepted. If the inquiry cannot be accepted, the database is referred to again to select another server node Si, and the inquiry is continued until it can be accepted.
  • the service search server node SX returns the search result to the client node C1.
  • the server node 100 having the configuration of FIG. 1 executes the distributed processing described below, thereby realizing load distribution.
  • the server node may be a virtual machine.
  • a large number of server nodes Si are connected to each other in one subnet 301 that is a network to which the Hello message 113 can reach.
  • a client node Cj that uses them is connected to an arbitrary server node Si from inside and outside the subnet 301.
  • the specific service search server node SX as shown in FIG. 2 is not necessary.
  • the route information notification unit 102 (FIG. 1) in each server node Si reads from the attribute information DB 101 in the own node using the Hello message 113 indicated by the solid line group with double arrows in FIG. 3.
  • the attribute information is periodically broadcast to other server nodes Si.
  • the broadcast timing of the Hello message 113 may be when the own node is activated or when a specific event occurs.
  • FIG. 4 is a diagram illustrating a data configuration example of the Hello message 113.
  • a broadcast address in the subnet 301 (FIG. 3) is stored.
  • the source address 402 the address of the own node is stored.
  • the service information 403 a service ID (identifier) of a search service, a service name, a service specification, and the like are stored.
  • the node information 404 as resource information, hardware resource information of the server node 100 (Si) such as CPU (central processing unit) type, CPU usage rate, memory usage rate, hard disk usage rate, etc. is stored. .
  • FIG. 5 is a diagram illustrating a data configuration example of the attribute information DB 101.
  • the CPU usage rate, the memory usage rate, etc. are stored as resource information in association with the server node ID (identification information) (description example “server node 5” in the figure).
  • the value is accumulated.
  • the node information monitoring unit 112 in FIG. 1 monitors the hardware resources of the own node, for example, periodically, at startup, or when an event occurs, and is updated based on the monitoring result. The monitoring is performed by executing a command for acquiring the CPU usage rate, the memory usage rate, and the like.
  • the following service information is stored in association with the service ID of the search service (description example “service 1001” or “service 1002” in the figure).
  • the service name is a character string. For example, a notation indicating a distributed file system, for example, “hdfs_system: //...” Is set in the URI.
  • the service specific information is, for example, the capacity of the hard disk.
  • the path information notification unit 102 in FIG. 1 generates a Hello message 113 having a data configuration as illustrated in FIG. 4 by referring to the attribute information DB 101 having a configuration as illustrated in FIG. To do.
  • each server node Si when the route information generation unit 106 (FIG. 1) in each server node Si receives a Hello message 113 broadcast from another server node Si, it generates route information with priority, Registration or information update is performed on the route information DB 107 (FIG. 1).
  • FIG. 6 is a diagram illustrating a data configuration example of the route information DB 107.
  • route information server identification information of the transfer destination server (description example “server node 2” or “server node 4” in the figure) and priority information corresponding to each server identification information (description example “80” in the figure) Or “60”) is registered.
  • the server identification information may be the host name or destination address of the server node 100, for example.
  • the path information generation unit 106 in FIG. 1 determines the priority for each server node Si (FIG. 3), for example, using a predetermined evaluation function.
  • This evaluation function is included in the CPU information, the CPU usage rate, the memory usage rate, the hard disk usage rate, and the service information included in the local node information as resource information in the Hello message 113 having the configuration illustrated in FIG.
  • the service load factor is defined as a parameter. For example, the lower the CPU usage rate, the higher the priority. Depending on how each server node Si in the network is to be used, it is possible to determine how to determine the priority.
  • FIG. 7 is a diagram for explaining the transfer operation of the service search request message 114 of FIG. 1 in the present embodiment.
  • the server node Si, the client node Cj, and the subnet 301 are the same as those shown in FIG. In the following description, the configuration of FIG. 1 is referred to as needed.
  • the following processes I, II, III IV (III IV-1, III IV-2), and IV (IV-1, IV-2) are the same numbered parts enclosed by the squares in FIG. Indicates.
  • FIG. 8 is a diagram illustrating a data configuration example of a service search request message. Each row of I, III ⁇ (a), and III (b) in FIG. 8 shows the data structure of the service search request message 114 handled in the following processes of I and III.
  • the client node C1 transmits a service search request message 114 having a data structure shown as I in FIG. 8 to an arbitrarily designated server node, for example, S5.
  • the arrow “I” from C1 to S5 in FIG. 8 the service search request message 114 stores the address of the client node C1 (description example “C1” in I in the figure) as the request source.
  • the address of the server node S5 (description example “S5” in I in the figure) is stored.
  • predetermined service search conditions are stored.
  • the service search condition in the service search request message 114 received by the own node is obtained by referring to the attribute information DB 101 of the own node. It is determined whether it corresponds to.
  • III-1 When the determination result in the search determination unit 108 is NG (not in the condition), the service search request message 114 is passed to the search transfer unit 109.
  • III-2) The search transfer unit 109 refers to the route information DB 107 to determine the transfer destination server node, and sends the address of the server node (III (a) in FIG. 8) to the request destination of the service search request message 114.
  • Description example “S3”) is stored, and the own node ID (description example “S5” in III (a) in the figure) is added to the searched list which is the search history information of the service search request message 114, and the server node ( Transfer to S3).
  • the search transfer unit 109 refers to the route information DB 107 to determine the transfer destination server node, and sends the address of the server node (III (b) in FIG. 8) to the request destination of the service search request message 114.
  • Description example “S1”) is stored, and the own node ID (description example “S3” in III (b) in the figure) is added to the searched list (search history information) of service search request message 114, and server node ( Transfer to S1).
  • the search determination unit 108 When the search determination unit 108 also receives the service search request message 114 in the server node S1, the service search condition in the service search request message 114 received by the own node is obtained by referring to the attribute information DB 101 of the own node. It is determined whether it corresponds to.
  • the service search request message 114 from the client node C1 is received by an arbitrary server node S5.
  • the server node S5 ⁇ S3 ⁇ S1 is transferred, and the search process is executed at the server node S1.
  • the search result is stored in the search result message 115 at the server node S1, and notified to, for example, the client node C1 that is the transmission source of the service search request message 114.
  • the service search request message 114 from the client node Cj can be received by any server node Si and can be transferred to the searchable server node Si. This enables load distribution that does not concentrate on a specific node. Based on the route information exchanged in advance and stored in the route information DB 107, an appropriate service execution node can be determined at the time of search.
  • the search for a plurality of server nodes Si can be specified in the service search condition stored in the service search request message 114.
  • the search result notification unit 110 notifies the transmission result of the search result message 115 described above to the transmission source of the service search request message 114 and executes the following process. . If the number of servers specified by the service search condition is not 1, the search result notifying unit 110 reduces the number of server nodes Si specified by the service search condition in the service search request message 114 by 1 and then transfers the search transfer unit. 109 is instructed to transfer the service search request message 114. With such a configuration, it is possible to execute a service search process for the service search request message 114 using a plurality of server nodes Si while distributing the load among the plurality of server nodes Si.
  • FIG. 9 is a flowchart showing a search determination process for realizing the search determination unit 108 of FIG. This flowchart is realized, for example, as an operation in which a CPU 1701 shown in FIG. 17 to be described later executes a control program stored in the memory 1702.
  • service search conditions are extracted from the service search request message 114 (step S901).
  • step S902 the attribute information DB 101 in FIG. 1 is referred to, and it is determined whether the service search condition extracted in step S901 is satisfied (step S902).
  • step S903 If the service search condition is satisfied (Yes in step S903), the service search request message 114 is notified to the search result notification unit 110 (step S904). Thereafter, the control process of the search determination process is terminated.
  • step S903 If the service search condition is not satisfied (No in step S903), the service search request message 114 is notified to the search transfer unit 109 (step S905). Thereafter, the control process of the search determination process is terminated.
  • FIG. 10 is a flowchart showing search result notification processing for realizing the search result notification unit 110 of FIG. This flowchart is realized, for example, as an operation in which a CPU 1701 shown in FIG. 17 to be described later executes a control program stored in the memory 1702.
  • the request source is extracted from the service search request message 114 (see FIG. 8) (step S1001).
  • step S1002 the search result is stored, and a search result message 115 storing the request source extracted in step S1001 is generated (step S1002).
  • step S1003 the search result message 115 generated in step S1002 is transmitted to the request source (step S1003).
  • the search result notification process of FIG. 10 is ended as it is by the end of the process of step S1003.
  • service search conditions are extracted from the service search request message 114 (step S1004).
  • step S1006 If the number of nodes is 1 (Yes in step S1006), the search result notification process in FIG.
  • step S1006 If the number of nodes is not 1 (No in step S1006), the number of server nodes Si specified by the service search condition in the service search request message 114 is reduced by 1 (step S1007).
  • a search transfer process described later with reference to FIG. 11 is started to transfer the service search request message 114 (step S1008). Thereafter, the control process of the search notification process is terminated.
  • the service search request message 114 can be further transferred to allow other server nodes Si to perform the search processing.
  • FIG. 11 is a flowchart showing a search transfer process for realizing the search transfer unit 109 of FIG. This flowchart is realized, for example, as an operation in which a CPU 1701 shown in FIG. 17 to be described later executes a control program stored in the memory 1702.
  • the searched list (search history information) (see FIG. 8) of the service search request message 114 is extracted (step S1101).
  • destination candidates are extracted from the path information DB 107 in order from the server node Si with the highest priority (step S1102).
  • step S1103 It is determined whether there is a destination candidate (step S1103). If there is a destination candidate and the determination in step S1103 is Yes, it is determined whether or not the destination candidate is included in the searched list (search history information) extracted in step S1101 (step S1104).
  • step S1106 determines whether the destination candidate is included in the searched list and the determination in step S1106 is Yes. If the destination candidate is included in the searched list and the determination in step S1106 is Yes, the process returns to step S1102, and the next destination candidate is extracted from the route information DB 107.
  • step S1107 If the destination candidate is not included in the searched list and the determination in step S1106 is No by the loop processing of steps S1102 to S1106, the server candidate Si of the destination candidate is the request destination of the service search request message 114 (see FIG. 8). It is set (step S1107).
  • the service search request message 114 is sent back to the transfer source server node (backtracked), and the following processing is performed. Is executed.
  • the transfer source server node (identified from the searched list) is set as the request destination of the service search request message 114 (step S1105).
  • step S1107 or S1105 the own node is added to the searched list of the service search request message (the number of lists is incremented by 1) (step S1108).
  • the service search request message 114 is transferred via the message transmission unit 103 (step S1109). Thereafter, the control process of the search transfer process is terminated.
  • FIG. 12 is a flowchart showing a route information notification process for realizing the route information notification unit 102 of FIG. This flowchart is realized, for example, as an operation in which a CPU 1701 shown in FIG. 17 to be described later executes a control program stored in the memory 1702.
  • the buffer of the Hello message 113 is acquired.
  • the broadcast address is set as the destination address (401 in FIG. 4).
  • the address of the own node is set as the transmission source address (402 in FIG. 4), and “Hello” is set as the message type (“type” field in FIG. 14 described later) (step S1201).
  • the service information registered in the attribute information DB 101 of the own node is set in the service information (403 in FIG. 4) of the Hello message 113. Further, the resource information registered in the attribute information DB 101 of the own node is set in the own node information (404 in FIG. 4) of the Hello message 113 (step S1202).
  • the Hello message 113 generated in steps S1201 and S1202 is notified to the message transmission unit 103 and transmitted (step S1203). Thereafter, the route information notification process in FIG. 12 is terminated.
  • FIG. 13 is a flowchart showing route information generation processing for realizing the route information generation unit 106 of FIG. This flowchart is realized, for example, as an operation in which a CPU 1701 shown in FIG. 17 to be described later executes a control program stored in the memory 1702.
  • the service information (403 in FIG. 4) and the own node information (404 in FIG. 4) of the received Hello message 113 are acquired, and the priority is determined from the service information and the own node information as resource information (step S1301). ).
  • step S1302 the transmission source address (402 in FIG. 4) of the received Hello message 113 is acquired (step S1302). Let this be LS.
  • Step S1303 the route information DB 107 is searched, and it is determined whether or not there is a record corresponding to the LS acquired in Step S1302 (Step S1303).
  • step S1303 determines whether the priority of the acquired route information DB 107 is updated with the priority determined in step S1301 (step S1304). Thereafter, the route information generation process in FIG. 13 is terminated.
  • step S1303 determines whether the LS entry acquired in step S1302 is created in the route information DB 107 is created in the route information DB 107, and the priority determined in step S1301 is set in the created entry (step S1305). Thereafter, the route information generation process in FIG. 13 is terminated.
  • FIG. 14 is a diagram illustrating a data format example of the Hello message 113.
  • the “symbol”, “length”, “request number”, “request time”, “category”, “type”, “status”, and “option” fields constitute the header part of the Hello message 113.
  • a value indicating the Hello message 113 is stored as the message type.
  • Address length indicates the length of an IP (Internet Protocol) address for accepting requests.
  • Request port indicates a port number for accepting a request.
  • Address indicates an IP address for accepting a request.
  • “Option” is an option field, and stores the service information 403, own node information (resource information) 404, etc. of FIG.
  • FIG. 15 is a diagram illustrating a data format example of the service search request message 114.
  • the header part of the service search request message 114 is the same as the header part of the Hello message 113 shown in FIG. In that case, a value indicating the service search request message 114 is stored in the “type” field as the message type.
  • “Limit” sets the upper limit of the number of searches. When there is no upper limit, 0 is set. “Reserve” is a reserved field.
  • the “query length” stores the length of the conditional expression of the service search condition. In “query”, a conditional expression of a service search condition is stored at a 4-byte boundary.
  • “Keys” stores a list of attribute keys acquired when the search is successful. In “history”, history information of a passing node at the time of transfer, that is, a searched list (search history information) is stored.
  • FIG. 16 is a diagram illustrating a data format example of the search result message 115.
  • the header part of the search result message 115 is the same as the header part of the Hello message 113 shown in FIG.
  • the “type” field stores a value indicating the search result message 115 as the message type.
  • a search result (1: detection, 2: search end, 3: search timeout) is stored.
  • Hop count stores the number of hops.
  • the length of the URI is stored in “uri length”.
  • uri a URI indicating the location of the search result at a 4-byte boundary is stored.
  • attr attribute information corresponding to the requested attribute key is stored.
  • FIG. 17 is a configuration diagram of a hardware system capable of realizing the system of the present embodiment.
  • FIG. 17 is a diagram illustrating an example of a hardware configuration of a computer that can realize the system as software processing.
  • the computer shown in FIG. 17 includes a CPU 1701, a memory 1702, an input device 1703, an output device 1704, an external storage device 1705, a portable recording medium driving device 1706 into which a portable recording medium 1709 is inserted, and a communication interface 1707. These are connected to each other by a bus 1708.
  • the configuration shown in the figure is an example of a computer that can implement the above system, and such a computer is not limited to this configuration.
  • the CPU 1701 controls the entire computer.
  • the memory 1702 is a memory such as a RAM that temporarily stores a program or data stored in the external storage device 1705 (or the portable recording medium 1709) when executing a program, updating data, or the like.
  • the CUP 1701 performs overall control by reading the program into the memory 1702 and executing it.
  • the input / output devices 1703 and 1704 detect an input operation by a user using a keyboard, a mouse, or the like, notify the detection result to the CPU 1701, and output data transmitted by the control of the CPU 1701 to a display device or a printing device.
  • the external storage device 1705 is, for example, a hard disk storage device. Mainly used for storing various data and programs.
  • the portable recording medium driving device 1706 accommodates a portable recording medium 1709 such as an optical disc, SDRAM, or CompactFlash (registered trademark), and has an auxiliary role for the external storage device 1705.
  • a portable recording medium 1709 such as an optical disc, SDRAM, or CompactFlash (registered trademark)
  • CompactFlash registered trademark
  • the communication interface 1707 is a device for connecting, for example, a LAN (local area network) or WAN (wide area network) communication line.
  • the system according to the present embodiment is realized by the CPU 1701 executing a program equipped with the functions shown in FIG. 1 or the functions realized by the flowcharts of FIGS. 9 to 13.
  • the program may be distributed by being recorded in, for example, the external storage device 1705 or the portable recording medium 1709, or may be acquired from the network by the network connection device 1707.
  • Si server node 101 Attribute information DB (database) 102 route information notifying unit 103 message transmitting unit 104 message receiving unit 105 message distributing unit 106 route information generating unit 107 route information DB (database) 108 Search determination unit 109 Search transfer unit 110 Search result notification unit 111 Service registration unit 112 Node information monitoring unit 113 Hello message 114 Service search request message 115 Search result message 201, 301 Subnet 401 Destination address 402 Source address 403 Service information 404 Self Node information Cj Client node SX Service search server node 1701 CPU 1702 Memory 1703 Input device 1704 Output device 1705 External storage device 1706 Portable recording medium driving device 1707 Communication interface 1708 Bus 1709 Portable recording medium

Abstract

　分散処理システムにおけるサービス検索に関し、特定のサーバへの負荷の集中を回避する。経路情報生成部１０６は、属性情報ＤＢ１０１に蓄積されているサービス情報およびリソース情報を含む属性情報を他のサーバノード１００との間で交換して経路情報を生成し経路情報ＤＢ１０７に蓄積する。検索転送部１０９は、検索判定部１０８にてサービス検索条件がマッチしないとき、サービス検索依頼メッセージ１１４中の検索履歴情報に検索実績がないサーバを経路情報ＤＢ１０７から選択して転送する。検索結果通知部１１０は、検索判定部１０８にてサービス検索条件がマッチしたときに、検索結果メッセージ１１５をサービス検索依頼メッセージ１１４の送信元へ通知する。

Description

分散処理におけるサービス検索方法、プログラム、およびサーバ装置
　分散処理システムにおけるサービス検索方法、プログラム、およびサーバ装置に関する。
　複数のサーバがネットワークによって接続された分散処理システムにおいて、クライアントからあるサービスの検索依頼が発生した場合に、複数のサーバから一つ以上のサーバを選択して検索を実行する必要がある。
　このような検索を実行するための従来技術として、次のようなものがある。クライアントは、特定のサーバに対して検索を要求し、その特定のサーバが他のサーバの状況を検索して要求に合うサーバを選択し、クライアントに回答する。このとき、特定のサーバは要求にあったサーバが受付けが可能か問合せを行い、受付け不可ならば他のサーバを選択し受付け可能となるまで問い合わせを続ける。
　しかし、この従来技術では、ネットワーク上のクライアントからの検索要求の数が増加したときに、それらの検索要求を受け付ける特定のサーバの負荷が増大するという問題点を有していた。
　また、他の従来技術として確実性高く連携情報を伝達し効率的に連携処理を行うことができるサービス処理装置及び連携処理システムを提供するために、各サービスを連携させるための指示書を各サービスを提供するサービス処理装置間で順次伝達していく。これにより、各サービス処理装置で指示書に基づいたサービスが順次実行されて一連のサービスの連携処理が行われるシステムが知られている（例えば特許文献１）。伝達される指示書には、各サービス毎に、各サービスを行うサービス処理装置を指定するための属性情報が記述される。サービス処理装置は、指示書を次のサービス処理装置に伝達するにあたり、受信した指示書内の次のサービスを行うサービス処理装置を指定するための属性情報に基づいてサービス処理装置を検索し、送信先を決定する。サービス処理装置は、該決定された送信先に指示書を送信する。
　しかし、この従来技術は、指示書に基づいて複数のサービス処理装置が連携する技術を開示しているものであって、サービス処理装置はやはり検索サーバという特定のサーバに問合せをしながら連携しなければならない。このため、この従来技術でも、特定のサーバの負荷が増大するという問題点を有していた。
特開２００５－２２８２５２号公報
　そこで、本発明は、特定のサーバへの負荷の集中を回避することを目的とする。
　態様の一例では、サービスを行なう複数からなるサーバにおけるサービス検索方法であって、サーバの属性情報を他のサーバとの間で交換することにより経路情報を生成し、サービス検索依頼元からサービス検索依頼を受信したときに、自身の属性情報を参照することにより、自身が前記サービス検索依頼に格納されているサービス検索条件にマッチするか否かを判定し、マッチが成立しないと判定した場合に、前記サービス検索依頼に付加されている検索履歴情報に検索実績がないサーバを前記経路情報に基づいて選択し、自身のサーバの情報を前記検索履歴情報として付加した前記サービス検索依頼を前記選択したサーバに転送し、マッチが成立すると判定した場合に、自身のサーバが生成した経路情報を基に検索依頼応答をサービス検索依頼元へ通知することを備える。
　サービス検索について、特定ノードに集中して検索する必要がなく負荷分散が可能になる。検索時点で適切なサービス実施ノードを決定することが可能となる。
本発明の実施形態におけるサーバノードの構成図である。 従来技術の動作を説明する図である。 本実施形態における属性情報の交換動作を説明する図である。 Ｈｅｌｌｏメッセージのデータ構成例を示す図である。 属性情報ＤＢのデータ構成例を示す図である。 経路情報ＤＢのデータ構成例を示す図である。 本実施形態におけるサービス検索依頼メッセージの転送動作を説明する図である。 サービス検索依頼メッセージのデータ構成例を示す図である。 検索判定処理の制御動作例を示すフローチャートである。 検索結果通知処理の制御動作例を示すフローチャートである。 検索結果転送処理の制御動作例を示すフローチャートである。 経路情報通知処理の制御動作例を示すフローチャートである。 経路情報生成処理の制御動作例を示すフローチャートである。 Ｈｅｌｌｏメッセージのデータフォーマット例を示す図である。 サービス検索依頼メッセージのデータフォーマット例を示す図である。 検索結果メッセージのデータフォーマット例を示す図である。 本実施形態のシステムを実現可能なハードウェアシステムの構成図である。
　以下、本発明を実施するための形態について図面を参照しながら詳細に説明する。
　図１は、本発明の実施形態による互いに複数台がネットワークによって接続されるサービスを行なうサーバ装置であるサーバノード１００の構成図である。
　属性情報データベース（以下、「属性情報ＤＢ」と呼ぶ）１０１は、自サーバノード１００に関するサービス情報とリソース情報を含む属性情報を蓄積する。
　経路情報通知部１０２は、定期的に、属性情報ＤＢ１０１を参照することにより、自サーバノード１００に関するサービス情報とリソース情報を含む例えばＨｅｌｌｏメッセージ１１３を生成する。そして、経路情報通知部１０２は、このＨｅｌｌｏメッセージ１１３を、メッセージ送信部１０３を介して、ネットワークに接続される他のサーバノード１００に例えば定期的に通知する。
　メッセージ受信部１０４は、他のサーバノード１００からのメッセージを受信する。メッセージ振分け部１０５は、メッセージ受信部１０４が受信したメッセージのうち、Ｈｅｌｌｏメッセージ１１３を経路情報生成部１０６に、検索依頼メッセージ１１４を検索判定部１０８にそれぞれ振り分ける。
　経路情報生成部１０６は、メッセージ受信部１０４およびメッセージ振分け部１０５を介して受信された他サーバノード１００からのＨｅｌｌｏメッセージ１１３に含まれる属性情報に基づいて、経路情報を生成する。このとき例えば、経路情報生成部１０６は、属性情報に基づいて計算したサービス検索の優先度を経路情報に付加する。そして、経路情報生成部１０６は、生成した経路情報を含むように、経路情報データベース（以下、「経路情報ＤＢ」と呼ぶ）１０７を更新する。すなわち、経路情報ＤＢ１０７は、他サーバノード１００との間で交換した属性情報に基づいて経路情報生成部１０６によって生成された経路情報を蓄積するデータベースである。
　検索判定部１０８は、メッセージ受信部１０４およびメッセージ振分け部１０５を介してクライアントノードまたは他サーバノード１００からサービス検索依頼メッセージ１１４を受信したときに、以下の動作を実行する。検索判定部１０８は、属性情報ＤＢ１０１に蓄積されている自身の属性情報を参照することにより、自身がサービス検索依頼メッセージ１１４に格納されているサービス検索条件にマッチするか否かを判定する。サービス検索条件としては例えば、
　　サービスＩＤ＝“分散バッチサービス”
　　ＣＰＵ使用率＜＝２０％
　　必要数＝５
のような指定がなされる。
　検索転送部１０９は、検索判定部１０８でマッチが成立しないと判定した場合に、サービス検索依頼メッセージ１１４に付加されている検索履歴情報に検索実績がないサーバノード１００を、経路情報ＤＢ１０７に蓄積されている経路情報に基づいて選択する。このとき例えば、検索転送部１０９は、経路情報に含まれる優先度が高いサーバノード１００を選択する。そして、検索転送部１０９は、自身のサーバノード１００の情報を検索履歴情報として付加したサービス検索依頼メッセージ１１４を、メッセージ送信部１０３を介して、選択したサーバノード１００に転送する。
　検索結果通知部１１０は、検索判定部１０８でマッチが成立すると判定した場合に、次の処理を実行する。検索結果通知部１１０は、自身のサーバノード１００が生成した経路情報を基に、サービス検索依頼メッセージ１１４に対する応答である検索結果メッセージ１１５を、メッセージ送信部１０３を介して、サービス検索依頼メッセージ１１４の依頼元へ通知する。検索結果メッセージ１１５によって、検索結果、条件を満たすサーバのアドレス(ＵＲＩ等)が返却される。前述のサービス検索依頼メッセージ１１４中のサービス検索条件として、例えば必要数＝５が設定されていれば、検索結果は５回受けとることになる。
　サービス登録部１１１は、属性情報ＤＢ１０１が蓄積する自サーバノード１００のサービス情報の登録または削除を行う。ヒューマンインタフェースによって人間が手動でサービス登録を行ったり、マシン起動時のバッチ処理（ＡＰＩやコマンド)等で登録されてよい。
　ノード情報監視部１１２は、自身のサーバのリソースを監視し、監視の結果に基づいて属性情報ＤＢ１０１が蓄積する自サーバノード１００のサービス情報及びリソース情報を更新する。
　以上の本実施形態の構成により、例えばクライアントノードからのサービス検索依頼メッセージ１１４は、ネットワークによって接続された複数のサーバノード１００のうちの任意のサーバノード１００にて受信される。そして、受信したサービス検索依頼メッセージ１１４が自ノードで処理できない場合には、サービス検索依頼メッセージ１１４を、経路情報ＤＢ１０７から決定される他のサーバノード１００に転送する。いずれかのサーバノード１００にて、サービス検索依頼メッセージ１１４を自ノードで処理できる場合は、検索処理を実行し、その検索結果を、検索結果メッセージ１１５に格納して、サービス検索依頼メッセージ１１４の依頼元の例えばクライアントノードに通知する。このような制御動作により、サービス検索について、特定ノードに集中して検索する必要がなく負荷分散が可能になる。あらかじめ相互に交換している経路情報に基づいて、検索時点で最適なサービス実施ノードを決定することが可能となる。
　図１の構成を有する本発明の実施形態の動作について、以下に詳細に説明する。
　まず、本実施形態との対比を明確にするために、従来のサービス検索方法の例について、図２を用いて説明する。図２において、Ｃ１はクライアントノード、Ｓｉ（ｉ＝１～４）はサーバノード、ＳＸはサービス検索サーバノードを示す。図２の構成は、一つのサブネット２０１内で、これらの各ノードが相互に接続された構成を有する。以下の（１）～（４）の処理は、それぞれ図２中の（１）～（４）の処理の矢印と対応している。
　クライアントノードＣ１から検索依頼を受信したサービス検索サーバノードＳＸが、検索を行い、クライアントノードＣ１に結果を返す仕組みになっている。
（１）サービス検索サーバノードＳＸに各サーバノードの情報（リソース情報、ハードスペック、サービス等）の情報を集め、データベースに登録する。
（２）クライアントノードＣ１からサービス検索依頼を、サービス検索サーバノードＳＸが受ける。
（３）サービス検索サーバノードＳＸは自ノードのデータベースを参照し、クライアントノードＣ１の要求にあったサーバノードＳｉを選び、受付が可能か問い合わせる。問合せで、受付不可なら再度データベースを参照して他のサーバノードＳｉを選び受付可能になるまで問合せを続ける。
（４）サービス検索サーバノードＳＸは、クライアントノードＣ１に検索結果を返信する。
　以上の（１）～（４）の制御処理を実行する従来技術の構成では、検索要求を行うクライアントノードの数がＣ１だけでなく他のにも増加したときに、それらの検索要求を受け付けるサービス検索サーバノードＳＸの負荷が増大してしまう。
　そこで、本実施形態では、図１の構成を有するサーバノード１００が以下に説明する分散処理を実行することにより、負荷分散を実現する。
　図３は、図１に示される構成を有する本実施形態における属性情報の交換動作を説明する図である。図３において、Ｃｊ（ｊ＝１，２）はクライアントノード、Ｓｉ（ｉ＝１～５）は図１の構成を有するサーバノード１００を示す。なお、サーバノードは、仮想マシンであってもよい。図３の構成では、Ｈｅｌｌｏメッセージ１１３が到達可能なネットワークである一つのサブネット３０１内で、多数のサーバノードＳｉが相互に接続される。さらに、任意のサーバノードＳｉに、サブネット３０１の内外から、それらを利用するクライアントノードＣｊが接続される。本実施形態では、従来技術と異なり、図２にあったような、特定のサービス検索サーバノードＳＸは不要である。
　図３の構成で、各サーバノードＳｉ内の経路情報通知部１０２（図１）は、図３の両矢印付き実線群で示されるＨｅｌｌｏメッセージ１１３を用い、自ノード内の属性情報ＤＢ１０１から読み出した属性情報を、他のサーバノードＳｉに定期的にブロードキャストする。あるいは、Ｈｅｌｌｏメッセージ１１３のブロードキャストのタイミングは、自ノードの起動時、特定のイベントの発生時等であってもよい。
　図４は、Ｈｅｌｌｏメッセージ１１３のデータ構成例を示す図である。宛先アドレス４０１としては、サブネット３０１（図３）内のブロードキャストアドレスが格納される。送信元アドレス４０２としては、自ノードのアドレスが格納される。サービス情報４０３としては、検索サービスのサービスＩＤ（識別子）、サービス名、サービススペック等が格納される。リソース情報としての自ノード情報４０４としては、ＣＰＵ（中央演算処理装置）種別、ＣＰＵ使用率、メモリ使用率、ハードディスク使用率等の、サーバノード１００（Ｓｉ）のハードウェアのリソース情報が格納される。
　これらのサービス情報およびリソース情報は、図１の属性情報ＤＢ１０１を参照して取得される。図５は、属性情報ＤＢ１０１のデータ構成例を示す図である。
　属性情報ＤＢ１０１には、図１のサーバノード１００に関して、サーバノードＩＤ（識別情報）（図中の記載例「サーバノード５」）に対応させて、リソース情報としてＣＰＵ使用率、メモリ使用率などの値が蓄積されている。これらのリソース情報は、図１のノード情報監視部１１２が、自ノードのハードウェアリソースを例えば定期的、起動時、またはイベント発生時に監視し、その監視結果に基づいて更新される。監視は、ＣＰＵ使用率、メモリ使用率などを取得するコマンドを実行することで行われる。
　また、属性情報ＤＢ１０１には、検索サービスのサービスＩＤ（図中の記載例「サービス１００１」または「サービス１００２」）に対応させて、次のサービス情報が蓄積される。サービス名、ＵＲＩ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｉｄｅｎｔｉｆｉｅｒ：統一資源識別子）、およびサービス固有情報（サービススペック）等である。サービス名は、文字列である。ＵＲＩには、例えば分散ファイルシステムを示す表記、例えば「ｈｄｆｓ＿ｓｙｓｔｅｍ：／／・・・」が設定される。サービス固有情報は、例えばハードディスクの容量である。
　図１の経路情報通知部１０２は、図５に例示されるような構成を有する属性情報ＤＢ１０１を参照することにより、図４に例示されるようなデータ構成を有するＨｅｌｌｏメッセージ１１３を生成し、ブロードキャストする。
　図３の説明に戻り、各サーバノードＳｉ内の経路情報生成部１０６（図１）は、他のサーバノードＳｉからブロードキャストされるＨｅｌｌｏメッセージ１１３を受信すると、優先順位付きの経路情報を生成し、経路情報ＤＢ１０７（図１）に対して登録または情報の更新を行う。
　図６は、経路情報ＤＢ１０７のデータ構成例を示す図である。経路情報として、転送先サーバのサーバ識別情報（図中の記載例「サーバノード２」または「サーバノード４」）と、各サーバ識別情報に対応する優先度の情報（図中の記載例「８０」または「６０」）が登録される。サーバ識別情報は例えば、サーバノード１００のホスト名または宛先アドレスであってよい。図１の経路情報生成部１０６は、例えば所定の評価関数によって、各サーバノードＳｉ（図３）ごとの優先度を決定する。この評価関数は例えば、図４に例示される構成を有するＨｅｌｌｏメッセージ１１３内のリソース情報として自ノード情報に含まれるＣＰＵ種別、ＣＰＵ使用率、メモリ使用率、ハードディスク使用率や、サービス情報に含まれるサービスによる負荷率等をパラメータとして定義される。例えばＣＰＵ使用率の小さいほうが優先度が高い等である。ネットワーク内の各サーバノードＳｉをどう使いたいかによって、優先度の決定の仕方を決めることができる。
　図７は、本実施形態における図１のサービス検索依頼メッセージ１１４の転送動作を説明する図である。図７において、サーバノードＳｉ、クライアントノードＣｊ、およびサブネット３０１は、図３に示されるものと同様である。以下の説明では、随時、図１の構成を参照する。また、以下のＩ、II、III （III ―１、III ―２）、およびIV（IV－１、IV－２）の各処理は、図７中の四角で囲まれた同じ番号の部分の処理を示す。また、図８は、サービス検索依頼メッセージのデータ構成例を示す図である。図８中のＩ、III （ａ）、およびIII （ｂ）の各行が、以下のＩおよびIII の各処理で扱われるサービス検索依頼メッセージ１１４のデータ構造を示している。
（Ｉ）クライアントノードＣ１は、任意に指定されるサーバノード例えばＳ５に、図８のＩとして示されるデータ構造を有するサービス検索依頼メッセージ１１４を送信する。図７中のＣ１からＳ５へ向かう「Ｉ」の矢印が該当する。図８に示されるように、このサービス検索依頼メッセージ１１４には、依頼元として、クライアントノードＣ１のアドレス（図中Ｉの記載例「Ｃ１」）が格納される。依頼先として、サーバノードＳ５のアドレス（図中Ｉの記載例「Ｓ５」）が格納される。また、所定のサービス検索条件が格納される。
（II）サーバノードＳ５では、検索判定部１０８が、サービス検索依頼メッセージ１１４を受信すると、自ノードの属性情報ＤＢ１０１を参照することにより、自ノードが受信したサービス検索依頼メッセージ１１４中のサービス検索条件に該当するかを判定する。
（III －１）検索判定部１０８での判定結果がＮＧの（条件にあっていない）場合、サービス検索依頼メッセージ１１４を検索転送部１０９に渡す。
（III －２）検索転送部１０９は、経路情報ＤＢ１０７を参照して転送先のサーバノードを決定し、サービス検索依頼メッセージ１１４の依頼先にそのサーバノードのアドレス（図８中III （ａ）の記載例「Ｓ３」）を格納し、サービス検索依頼メッセージ１１４の検索履歴情報である検索済リストに自ノードＩＤ（図中III （ａ）の記載例「Ｓ５」）を追加して、サーバノード（Ｓ３）に転送する。図７中のＳ５からＳ３へ向かう「III ―２」の矢印が該当する。
　以降、転送先でも同様な処理が行われる。
（II）すなわち、サーバノードＳ３では、検索判定部１０８が、サービス検索依頼メッセージ１１４を受信すると、自ノードの属性情報ＤＢ１０１を参照することにより、自ノードが受信したサービス検索依頼メッセージ１１４中のサービス検索条件に該当するかを判定する。
（III －１）検索判定部１０８での判定結果がＮＧの場合、サービス検索依頼メッセージ１１４を検索転送部１０９に渡す。
（III －２）検索転送部１０９は、経路情報ＤＢ１０７を参照して転送先のサーバノードを決定し、サービス検索依頼メッセージ１１４の依頼先にそのサーバノードのアドレス（図８中III （ｂ）の記載例「Ｓ１」）を格納し、サービス検索依頼メッセージ１１４の検索済リスト（検索履歴情報）に自ノードＩＤ（図中III （ｂ）の記載例「Ｓ３」）を追加して、サーバノード（Ｓ１）に転送する。図７中のＳ３からＳ１へ向かう「III ―２」の矢印が該当する。
（II）サーバノードＳ１でも、検索判定部１０８が、サービス検索依頼メッセージ１１４を受信すると、自ノードの属性情報ＤＢ１０１を参照することにより、自ノードが受信したサービス検索依頼メッセージ１１４中のサービス検索条件に該当するかを判定する。
（IV－１）検索判定部１０８での判定結果がＯＫの（条件に合った）場合、サービス検索依頼メッセージ１１４が検索結果通知部１１０に渡される。
（IV－２）検索結果通知部１１０は、サービスの検索結果が格納された検索結果メッセージ１１５を作成し、依頼元のクライアントノードC1に送信する。図７中のＳ１からＳ２を経由してＣ１へ向かう「IV―２」の矢印が該当する。
　以上の図７に示される動作例により、例えばクライアントノードＣ１からのサービス検索依頼メッセージ１１４は、任意のサーバノードＳ５にて受信される。そして、受信したサービス検索依頼メッセージ１１４が自ノードで処理できない場合には、サーバノードＳ５→Ｓ３→Ｓ１と転送されて、サーバノードＳ１にて検索処理が実行される。その検索結果は、サーバノードＳ１にて検索結果メッセージ１１５に格納されて、サービス検索依頼メッセージ１１４の送信元の例えばクライアントノードＣ１に通知される。このような制御動作により、クライアントノードＣｊからのサービス検索依頼メッセージ１１４は、任意のサーバノードＳｉにて受信することができ、検索可能なサーバノードＳｉに転送することができる。これにより、特定ノードに集中しない負荷分散が可能になる。あらかじめ相互に交換し経路情報ＤＢ１０７に蓄積している経路情報に基づいて、検索時点で適切なサービス実施ノードを決定することが可能となる。
　ここで、サービス検索依頼メッセージ１１４に格納されているサービス検索条件において複数のサーバノードＳｉに対する検索が指定されるように構成することができる。この場合、検索結果通知部１１０は、検索判定部１０８でマッチが成立すると判定した場合に、前述した検索結果メッセージ１１５をサービス検索依頼メッセージ１１４の送信元へ通知するとともに、次の処理を実行する。検索結果通知部１１０は、サービス検索条件が指定するサーバの数が１でなければ、サービス検索依頼メッセージ１１４中のサービス検索条件が指定するサーバノードＳｉの数を１減らした上で、検索転送部１０９に、そのサービス検索依頼メッセージ１１４の転送を指示する。このような構成により、複数のサーバノードＳｉ間で負荷分散を図りながら、かつ複数のサーバノードＳｉを使ってサービス検索依頼メッセージ１１４に対するサービス検索処理を実行することが可能となる。
　図９は、図１の検索判定部１０８を実現する検索判定処理を示すフローチャートである。このフローチャートは例えば、後述する図１７に示されるＣＰＵ１７０１がメモリ１７０２に記憶された制御プログラムを実行する動作として実現される。
　まず、サービス検索依頼メッセージ１１４からサービス検索条件が取り出される（ステップＳ９０１）。
　次に、図１の属性情報ＤＢ１０１が参照され、ステップＳ９０１で取り出されたサービス検索条件を満たしているかが判定される（ステップＳ９０２）。
　サービス検索条件を満たしているならば（ステップＳ９０３の判定がＹｅｓ）、サービス検索依頼メッセージ１１４が検索結果通知部１１０に通知される（ステップＳ９０４）。その後、検索判定処理の制御処理を終了する。
　サービス検索条件を満たしていないならば（ステップＳ９０３の判定がＮｏ）、サービス検索依頼メッセージ１１４が検索転送部１０９に通知される（ステップＳ９０５）。その後、検索判定処理の制御処理を終了する。
　図１０は、図１の検索結果通知部１１０を実現する検索結果通知処理を示すフローチャートである。このフローチャートは例えば、後述する図１７に示されるＣＰＵ１７０１がメモリ１７０２に記憶された制御プログラムを実行する動作として実現される。
　まず、サービス検索依頼メッセージ１１４から依頼元が取り出される（図８参照）（ステップＳ１００１）。
　次に、検索結果が格納され、ステップＳ１００１で取り出された依頼元が格納された検索結果メッセージ１１５が生成される（ステップＳ１００２）。
　次に、ステップＳ１００２で生成された検索結果メッセージ１１５が、依頼元に送信される（ステップＳ１００３）。
　ここで、サービス検索依頼メッセージ１１４が複数のサーバノードＳｉに対する検索を指定していなければ、ステップＳ１００３の処理の終了により、そのまま図１０の検索結果通知処理を終了する。
　一方、サービス検索依頼メッセージ１１４に格納されているサービス検索条件において複数のサーバノードＳｉに対する検索が指定されていれば、図１０の破線で示されるステップＳ１００４からＳ１００８までの一連の処理が実行される。
　まず、サービス検索依頼メッセージ１１４からサービス検索条件が取り出される（ステップＳ１００４）。
　次に、サービス検索条件のノード数が１か否かが判定される（ステップＳ１００５）。
　ノード数が１であれば（ステップＳ１００６の判定がＹｅｓ）、そのまま図１０の検索結果通知処理を終了する。
　ノード数が１でなければ（ステップＳ１００６の判定がＮｏ）、サービス検索依頼メッセージ１１４中のサービス検索条件が指定するサーバノードＳｉの数が１減らされる（ステップＳ１００７）。
　その上で、図１１で後述する検索転送処理を起動して、そのサービス検索依頼メッセージ１１４の転送を行わせる（ステップＳ１００８）。その後、検索通知処理の制御処理を終了する。
　ステップＳ１００４～Ｓ１００８の処理により、ステップＳ１００３にて検索結果メッセージ１１５を返信した後、さらにそのサービス検索依頼メッセージ１１４を転送して、他のサーバノードＳｉに検索処理を行わせることが可能となる。
　図１１は、図１の検索転送部１０９を実現する検索転送処理を示すフローチャートである。このフローチャートは例えば、後述する図１７に示されるＣＰＵ１７０１がメモリ１７０２に記憶された制御プログラムを実行する動作として実現される。
　まず、サービス検索依頼メッセージ１１４の検索済リスト（検索履歴情報）（図８参照）が取り出される（ステップＳ１１０１）。
　次に、経路情報ＤＢ１０７から、優先順位の高いサーバノードＳｉから順に、宛先候補が取り出される（ステップＳ１１０２）。
　宛先候補があるか否かが判定される（ステップＳ１１０３）。
　宛先候補があって、ステップＳ１１０３の判定がＹｅｓならば、宛先候補が、ステップＳ１１０１で取り出された検索済リスト（検索履歴情報）に含まれるか否かが判定される（ステップＳ１１０４）。
　宛先候補が検索済リストに含まれてステップＳ１１０６の判定がＹｅｓならば、ステップＳ１１０２に戻って、経路情報ＤＢ１０７から次の宛先候補が取り出される。
　ステップＳ１１０２～Ｓ１１０６のループ処理により、宛先候補が検索済リストに含まれずにステップＳ１１０６の判定がＮｏになると、サービス検索依頼メッセージ１１４の依頼先（図８参照）に、宛先候補のサーバノードＳｉが設定される（ステップＳ１１０７）。
　一方、ステップＳ１１０２～Ｓ１１０６のループ処理により、宛先候補がなくなってステップＳ１１０３の判定がＮｏになると、そのサービス検索依頼メッセージ１１４を転送元のサーバノードに送り返す（バックトラックする）ために、次の処理が実行される。サービス検索依頼メッセージ１１４の依頼先に、転送元のサーバノード（検索済リストからわかる）が設定される（ステップＳ１１０５）。
　ステップＳ１１０７またはＳ１１０５の処理の後、サービス検索依頼メッセージの検索済リストに自ノードが追加される（リスト数が＋１される）（ステップＳ１１０８）。
　最後に、サービス検索依頼メッセージ１１４が、メッセージ送信部１０３を介して転送される（ステップＳ１１０９）。その後、検索転送処理の制御処理を終了する。
　図１２は、図１の経路情報通知部１０２を実現する経路情報通知処理を示すフローチャートである。このフローチャートは例えば、後述する図１７に示されるＣＰＵ１７０１がメモリ１７０２に記憶された制御プログラムを実行する動作として実現される。
　まず、Ｈｅｌｌｏメッセージ１１３のバッファが取得される。このとき、宛先アドレス（図４の４０１）にブロードキャストアドレスが設定される。また、送信元アドレス（図４の４０２）に自ノードのアドレスが設定され、メッセージ種別（後述する図１４の「ｔｙｐｅ」フィールド）に「Ｈｅｌｌｏ」が設定される（以上、ステップＳ１２０１）。
　次に、自ノードの属性情報ＤＢ１０１に登録されているサービス情報が、Ｈｅｌｌｏメッセージ１１３のサービス情報（図４の４０３）に設定される。また、自ノードの属性情報ＤＢ１０１に登録されているリソース情報がＨｅｌｌｏメッセージ１１３の自ノード情報（図４の４０４）に設定される（以上、ステップＳ１２０２）。
　そして、ステップＳ１２０１およびＳ１２０２により生成されたＨｅｌｌｏメッセージ１１３が、メッセージ送信部１０３に通知されて送信される（ステップＳ１２０３）。その後、図１２の経路情報通知処理を終了する。
　図１３は、図１の経路情報生成部１０６を実現する経路情報生成処理を示すフローチャートである。このフローチャートは例えば、後述する図１７に示されるＣＰＵ１７０１がメモリ１７０２に記憶された制御プログラムを実行する動作として実現される。
　受信されたＨｅｌｌｏメッセージ１１３のサービス情報（図４の４０３）と自ノード情報（図４の４０４）が取得され、サービス情報とリソース情報としての自ノード情報とから優先度が決定される（ステップＳ１３０１）。
　次に、受信されたＨｅｌｌｏメッセージ１１３の送信元アドレス（図４の４０２）が取得される（ステップＳ１３０２）。これをＬＳとする。
　次に、経路情報ＤＢ１０７が検索され、ステップＳ１３０２で取得されたＬＳに対応するレコードが存在するか否かが判定される（ステップＳ１３０３）。
　ステップＳ１３０３の判定がＹｅｓならば、取得した経路情報ＤＢ１０７の優先度を、ステップＳ１３０１で決定された優先度によって更新される（ステップＳ１３０４）。その後、図１３の経路情報生成処理を終了する。
　ステップＳ１３０３の判定がＮｏならば、経路情報ＤＢ１０７にステップＳ１３０２で取得されたＬＳのエントリが作成され、作成されたエントリにステップＳ１３０１で決定された優先度が設定される（ステップＳ１３０５）。その後、図１３の経路情報生成処理を終了する。
　図１４は、Ｈｅｌｌｏメッセージ１１３のデータフォーマット例を示す図である。
　「ｓｙｍｂｏｌ」「ｌｅｎｇｔｈ」「ｒｅｑｕｅｓｔ　ｎｕｍｂｅｒ」「ｒｅｑｕｅｓｔ　ｔｉｍｅ」「ｃａｔｅｇｏｒｙ」「ｔｙｐｅ」「ｓｔａｔｕｓ」および「ｏｐｔｉｏｎ」の各フィールドは、Ｈｅｌｌｏメッセージ１１３のヘッダ部を構成する。この中で特に、「ｔｙｐｅ」フィールドには、メッセージの種別として、Ｈｅｌｌｏメッセージ１１３であることを示す値が格納される。
　「ａｄｄｒｅｓｓ　ｌｅｎｇｔｈ」は、要求受付用のＩＰ（インターネットプロトコル）アドレスの長さを示す。「ｒｅｑｕｅｓｔ　ｐｏｒｔ」は、要求受付用のポート番号を示す。「ａｄｄｒｅｓｓ」は、要求受付用のＩＰアドレスを示す。「ｏｐｔｉｏｎ」は、オプションフィールドであり、図４のサービス情報４０３、自ノード情報（リソース情報）４０４などが格納される。
　図１５は、サービス検索依頼メッセージ１１４のデータフォーマット例を示す図である。
　サービス検索依頼メッセージ１１４のヘッダ部は、図１４に示されるＨｅｌｌｏメッセージ１１３のヘッダ部と同じである。その場合、「ｔｙｐｅ」フィールドには、メッセージの種別として、サービス検索依頼メッセージ１１４であることを示す値が格納される。
　「ｌｉｍｉｔ」は、検索件数の上限値が設定される。上限なしの場合は０が設定される。「ｒｅｓｅｒｖｅ」は、予約フィールドである。「ｑｕｅｒｙ　ｌｅｎｇｔｈ」は、サービス検索条件の条件式の長さが格納される。「ｑｕｅｒｙ」は、４バイト境界でサービス検索条件の条件式が格納される。「ｋｅｙｓ」は、検索成功時に取得する属性キーのリストが格納される。「ｈｉｓｔｏｒｙ」は、転送時の通過ノードの履歴情報すなわち検索済リスト（検索履歴情報）が格納される。
　図１６は、検索結果メッセージ１１５のデータフォーマット例を示す図である。
　検索結果メッセージ１１５のヘッダ部は、図１４に示されるＨｅｌｌｏメッセージ１１３のヘッダ部と同じである。その場合、「ｔｙｐｅ」フィールドには、メッセージの種別として、検索結果メッセージ１１５であることを示す値が格納される。
　「ｒｅｓｕｌｔ」には、検索結果（１：検出、２：検索終了、３：検索タイムアウト）が格納される。「ｈｏｐ　ｃｏｕｎｔ」にはホップ数が格納される。「ｕｒｉ　ｌｅｎｇｔｈ」には、ＵＲＩの長さが格納される。「ｕｒｉ」には、４バイト境界で検索結果の場所を示すＵＲＩが格納される。「ａｔｔｒ」には、要求された属性キーに対応する属性情報が格納される。
　図１７は、本実施形態のシステムを実現可能なハードウェアシステムの構成図である。
　図１７は、上記システムをソフトウェア処理として実現できるコンピュータのハードウェア構成の一例を示す図である。
　図１７に示されるコンピュータは、ＣＰＵ１７０１、メモリ１７０２、入力装置１７０３、出力装置１７０４、外部記憶装置１７０５、可搬記録媒体１７０９が挿入される可搬記録媒体駆動装置１７０６、及び通信インタフェース１７０７を有し、これらがバス１７０８によって相互に接続された構成を有する。同図に示される構成は上記システムを実現できるコンピュータの一例であり、そのようなコンピュータはこの構成に限定されるものではない。
　ＣＰＵ１７０１は、当該コンピュータ全体の制御を行う。メモリ１７０２は、プログラムの実行、データ更新等の際に、外部記憶装置１７０５（或いは可搬記録媒体１７０９）に記憶されているプログラム又はデータを一時的に格納するＲＡＭ等のメモリである。ＣＵＰ１７０１は、プログラムをメモリ１７０２に読み出して実行することにより、全体の制御を行う。
　入出力装置１７０３、１７０４は、ユーザによるキーボードやマウス等による入力操作を検出し、その検出結果をＣＰＵ１７０１に通知し、ＣＰＵ１７０１の制御によって送られてくるデータを表示装置や印刷装置に出力する。
　外部記憶装置１７０５は、例えばハードディスク記憶装置である。主に各種データやプログラムの保存に用いられる。
　可搬記録媒体駆動装置１７０６は、光ディスクやＳＤＲＡＭ、コンパクトフラッシュ（登録商標）等の可搬記録媒体１７０９を収容するもので、外部記憶装置１７０５の補助の役割を有する。
　通信インタフェース１７０７は、例えばＬＡＮ（ローカルエリアネットワーク）又はＷＡＮ（ワイドエリアネットワーク）の通信回線を接続するための装置である。
　本実施形態によるシステムは、図１に示される各機能または図９～図１３のフローチャート等で実現される機能を搭載したプログラムをＣＰＵ１７０１が実行することで実現される。そのプログラムは、例えば外部記憶装置１７０５や可搬記録媒体１７０９に記録して配布してもよく、或いはネットワーク接続装置１７０７によりネットワークから取得できるようにしてもよい。
　１００、Ｓｉ　サーバノード
　１０１　属性情報ＤＢ（データベース）
　１０２　経路情報通知部
　１０３　メッセージ送信部
　１０４　メッセージ受信部
　１０５　メッセージ振分け部
　１０６　経路情報生成部
　１０７　経路情報ＤＢ（データベース）
　１０８　検索判定部
　１０９　検索転送部
　１１０　検索結果通知部
　１１１　サービス登録部
　１１２　ノード情報監視部
　１１３　Ｈｅｌｌｏメッセージ
　１１４　サービス検索依頼メッセージ
　１１５　検索結果メッセージ
　２０１、３０１　サブネット
　４０１　宛先アドレス
　４０２　送信元アドレス
　４０３　サービス情報
　４０４　自ノード情報
　Ｃｊ　クライアントノード
　ＳＸ　サービス検索サーバノード
　１７０１　ＣＰＵ
　１７０２　メモリ
　１７０３　入力装置
　１７０４　出力装置
　１７０５　外部記憶装置
　１７０６　可搬記録媒体駆動装置
　１７０７　通信インタフェース
　１７０８　バス
　１７０９　可搬記録媒体

Claims (12)

  1. 　サービスを行なう複数からなるサーバにおけるサービス検索方法であって、サーバの属性情報を他のサーバとの間で交換することにより経路情報を生成し、サービス検索依頼元からサービス検索依頼を受信したときに、自身の属性情報を参照することにより、自身が前記サービス検索依頼に格納されているサービス検索条件にマッチするか否かを判定し、マッチが成立しないと判定した場合に、前記サービス検索依頼に付加されている検索履歴情報に検索実績がないサーバを前記経路情報に基づいて選択し、自身のサーバの情報を前記検索履歴情報として付加した前記サービス検索依頼を前記選択したサーバに転送し、マッチが成立すると判定した場合に、自身のサーバが生成した経路情報を基に検索依頼応答をサービス検索依頼元へ通知する　ことを備えることを特徴とする分散処理におけるサービス検索方法。
  2. 　前記経路情報を生成するときに、前記交換した属性情報に基づいて計算したサービス検索の優先度を前記経路情報に付加し、
    　前記サービス検索依頼を転送するときに、前記経路情報に含まれる優先度が高いサーバを選択する、
    　ことを備えることを特徴とする付記１に記載の分散処理におけるサービス検索方法。
  3. 　前記サービス検索依頼に格納されている前記サービス検索条件において複数のサーバに対する検索が指定され、
    　前記マッチが成立すると判定した場合に、前記サービス検索条件が指定するサーバの数が１でなければ、前記サービス検索依頼に格納されている検索履歴情報に検索実績がないサーバを前記経路情報に基づいて選択し、前記サービス検索条件が指定するサーバの数を１減らすとともに自身のサーバの情報を検索履歴情報として付加した前記サービス検索依頼を前記選択したサーバに転送する、
    　ことをさらに備えることを特徴とする付記１または２のいずれかに記載の分散処理におけるサービス検索方法。
  4. 　前記属性情報はサービス情報とリソース情報を含み、
    　前記サービス情報の登録または削除を行い、
    　自身のサーバのリソースを監視し、前記監視の結果に基づいて前記リソース情報を更新する、
    　ことをさらに備えることを特徴とする請求項１ないし３のいずれかに記載の分散処理におけるサービス検索方法。
  5. 　サービスを行なう複数からなるサーバに、
    　サービス情報とリソース情報を含む属性情報を他の前記サーバとの間で交換することにより経路情報を生成する機能と、
    　サービス検索依頼を受信したときに、自身の前記属性情報を参照することにより、自身が前記サービス検索依頼に格納されているサービス検索条件にマッチするか否かを判定する機能と、
    　前記マッチが成立しないと判定した場合に、前記サービス検索依頼に格納されている検索履歴情報に検索実績がないサーバを前記経路情報に基づいて選択し、自身のサーバの情報を検索履歴情報として付加した前記サービス検索依頼を前記選択したサーバに転送する機能と、
    　前記マッチが成立すると判定した場合に、自身のサーバが生成した経路情報を基に前記サービス検索依頼に対する検索結果の応答を前記サービス検索依頼の送信元へ通知する機能と、
    　を実行させるためのプログラム。
  6. 　前記経路情報を生成するときに、前記交換した属性情報に基づいて計算したサービス検索の優先度を前記経路情報に付加する機能と、
    　前記サービス検索依頼を転送するときに、前記経路情報に含まれる優先度が高いサーバを選択する機能と、
    　を前記サーバに実行させることを特徴とする付記５に記載のプログラム。
  7. 　前記サービス検索依頼に格納されている前記サービス検索条件において複数のサーバに対する検索が指定され、
    　前記マッチが成立すると判定した場合に、前記サービス検索条件が指定するサーバの数が１でなければ、前記サービス検索依頼に格納されている検索履歴情報に検索実績がないサーバを前記経路情報に基づいて選択し、前記サービス検索条件が指定するサーバの数を１減らすとともに自身のサーバの情報を検索履歴情報として付加した前記サービス検索依頼を前記選択したサーバに転送する機能を前記サーバに実行させるための付記５または６のいずれかに記載のプログラム。
  8. 　前記サービス情報の登録または削除を行う機能と、
    　自身のサーバのリソースを監視し、前記監視の結果に基づいて前記リソース情報を更新する機能と、
    　を前記サーバに実行させることを特徴とする付記５ないし７のいずれかに記載のプログラム。
  9. 　サービスを行なう複数からなるサーバ装置であって、
    　サービス情報とリソース情報を含む属性情報を他の前記サーバとの間で交換することにより経路情報を生成する経路情報生成部と、
    　サービス検索依頼を受信したときに、自身の前記属性情報を参照することにより、自身が前記サービス検索依頼に格納されているサービス検索条件にマッチするか否かを判定する検索判定部と、
    　前記マッチが成立しないと判定した場合に、前記サービス検索依頼に格納されている検索履歴情報に検索実績がないサーバを前記経路情報に基づいて選択し、自身のサーバの情報を検索履歴情報として付加した前記サービス検索依頼を前記選択したサーバに転送する検索転送部と、
    　前記マッチが成立すると判定した場合に、自身のサーバが生成した経路情報を基に前記サービス検索依頼に対する検索結果の応答を前記サービス検索依頼の送信元へ通知する検索結果通知部と、
    　を備えることを特徴とするサーバ装置。
  10. 　前記経路情報生成部は、前記経路情報を生成するときに、前記交換した属性情報に基づいて計算したサービス検索の優先度を前記経路情報に付加し、
    　前記検索転送部は、前記サービス検索依頼を転送するときに、前記経路情報に含まれる優先度が高いサーバを選択する、
    　ことを備えることを特徴とする付記９に記載のサーバ装置。
  11. 　前記サービス検索依頼に格納されている前記サービス検索条件において複数のサーバに対する検索が指定され、
    　前記マッチが成立すると判定した場合に、前記検索結果通知部は、前記サービス検索条件が指定するサーバの数が１でなければ、前記サービス検索依頼中の前記サービス検索条件が指定するサーバの数を１減らした上で、前記検索転送部に、前記サービス検索依頼の転送を指示する、
    　ことをさらに備えることを特徴とする付記９または１０のいずれかに記載のサーバ装置。
  12. 　前記サービス情報の登録または削除を行うサービス登録部と、
    　自身のサーバのリソースを監視し、前記監視の結果に基づいて前記リソース情報を更新するノード情報監視部と、
    　をさらに備えることを特徴とする付記９ないし１１のいずれかに記載のサーバ装置。
PCT/JP2012/058268 2012-03-28 2012-03-28 分散処理におけるサービス検索方法、プログラム、およびサーバ装置 WO2013145197A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2014507163A JP5979223B2 (ja) 2012-03-28 2012-03-28 分散処理におけるサービス検索方法、プログラム、およびサーバ装置
PCT/JP2012/058268 WO2013145197A1 (ja) 2012-03-28 2012-03-28 分散処理におけるサービス検索方法、プログラム、およびサーバ装置
US14/461,593 US20140358967A1 (en) 2012-03-28 2014-08-18 Service search method and server device in distributed processing

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2012/058268 WO2013145197A1 (ja) 2012-03-28 2012-03-28 分散処理におけるサービス検索方法、プログラム、およびサーバ装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14/461,593 Continuation US20140358967A1 (en) 2012-03-28 2014-08-18 Service search method and server device in distributed processing

Publications (1)

Publication Number Publication Date
WO2013145197A1 true WO2013145197A1 (ja) 2013-10-03

Family

ID=49258561

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2012/058268 WO2013145197A1 (ja) 2012-03-28 2012-03-28 分散処理におけるサービス検索方法、プログラム、およびサーバ装置

Country Status (3)

Country Link
US (1) US20140358967A1 (ja)
JP (1) JP5979223B2 (ja)
WO (1) WO2013145197A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018081444A (ja) * 2016-11-15 2018-05-24 ソフトバンク株式会社 ユーザーサポートシステム、ユーザーサポートプログラム及びユーザーサポート方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11195048A (ja) * 1997-10-31 1999-07-21 Fujitsu Ltd 分散検索システムおよび分散検索システムにおける検索装置
JP2004227140A (ja) * 2003-01-21 2004-08-12 Toshiba Corp 検索連携プログラム及び検索システム並びに検索方法

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3710961B2 (ja) * 1999-06-22 2005-10-26 富士通株式会社 分散検索装置および分散検索プログラム記憶媒体
JP2002015215A (ja) * 2000-06-30 2002-01-18 Hitachi Ltd マルチメデア情報配信システムおよび携帯情報端末装置
JP2004240834A (ja) * 2003-02-07 2004-08-26 Nippon Telegr & Teleph Corp <Ntt> サービス生成方法およびプログラム
WO2006101169A1 (ja) * 2005-03-23 2006-09-28 Ihc Corp. 認証システム
CN101681566B (zh) * 2007-05-30 2012-05-02 株式会社纳维泰 地图显示系统、地图显示装置及地图显示方法
CN102084386A (zh) * 2008-03-24 2011-06-01 姜旻秀 利用数字内容关联元信息的关键字广告方法及其关联系统
JP4548503B2 (ja) * 2008-04-01 2010-09-22 ソニー株式会社 サーバ装置、ネットワークシステム、データ転送方法およびプログラム
JP4739364B2 (ja) * 2008-04-08 2011-08-03 株式会社日立製作所 サービス使用経路出力システム、管理サーバ、サービス使用経路出力方法、およびサービス使用経路出力プログラム
CN102326051A (zh) * 2009-02-20 2012-01-18 株式会社纳维泰 路径向导系统、路径检索服务器及路径向导方法
WO2010122652A1 (ja) * 2009-04-23 2010-10-28 株式会社ナビタイムジャパン 経路案内システム、経路探索サーバ、経路案内仲介サーバおよび経路案内方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11195048A (ja) * 1997-10-31 1999-07-21 Fujitsu Ltd 分散検索システムおよび分散検索システムにおける検索装置
JP2004227140A (ja) * 2003-01-21 2004-08-12 Toshiba Corp 検索連携プログラム及び検索システム並びに検索方法

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018081444A (ja) * 2016-11-15 2018-05-24 ソフトバンク株式会社 ユーザーサポートシステム、ユーザーサポートプログラム及びユーザーサポート方法

Also Published As

Publication number Publication date
US20140358967A1 (en) 2014-12-04
JPWO2013145197A1 (ja) 2015-08-03
JP5979223B2 (ja) 2016-08-24

Similar Documents

Publication Publication Date Title
EP1783954B1 (en) System and method for discovering network resources
JP2007066161A (ja) キャッシュシステム
JP6438719B2 (ja) 通信システム、および、通信プログラム
JP2005266917A (ja) 分散資源獲得システム、分散資源獲得方法および分散資源獲得用プログラム
JP5847185B2 (ja) コンテンツ中心のネットワーク環境でグループ変更に関する情報を用いるコンテンツ共有方法及び装置
JP5437785B2 (ja) 認証方法、変換装置、中継装置、及び該プログラム
JP2009296128A (ja) 情報処理装置、情報処理装置の制御方法及びコンピュータプログラム
JP4410608B2 (ja) Ｗｅｂサービス提供方法
JP2008234206A (ja) 情報送信システム、情報処理装置、情報管理装置及び情報送信方法
KR101337151B1 (ko) 송신원을 식별하는 정보 처리 장치 및 그 제어 방법
EP2802108B1 (en) Data-centric communications system and data forwarding method
JP2005322222A (ja) 通信機能付加方法、プログラム、記録媒体及び通信装置
JP5979223B2 (ja) 分散処理におけるサービス検索方法、プログラム、およびサーバ装置
JP2016144186A (ja) 通信情報制御装置、中継システム、通信情報制御方法、および、通信情報制御プログラム
US9509657B2 (en) Information processing apparatus, relay method, and computer-readable storage medium
JP2001060157A (ja) アプリケーション間メッセージ交換方式
JP4107252B2 (ja) 通信中継装置、通信中継方法、および通信中継プログラム
JP2011114805A (ja) 通信装置及び方法、並びにプログラム
KR20090042542A (ko) 더미 메시지를 이용하여 웹 서비스의 품질 데이터를추출하는 방법
JP4291174B2 (ja) Ｗｅｂサービス委譲処理方法及び実施装置並びに処理プログラム
JP5434268B2 (ja) 分散保存システム、データファイル分散保存方法及びプログラム
JP5907132B2 (ja) 中継装置、プログラム及び通信システム
JP2005202618A (ja) コンテンツ配信管理方法、コンテンツ配信装置、コンテンツ配信システム、プログラムおよび記録媒体
JP6211487B2 (ja) 分散システム、データ取得方法及びコンピュータプログラム
JP2005157613A (ja) 情報管理装置

Legal Events

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

Ref document number: 12872991

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2014507163

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12872991

Country of ref document: EP

Kind code of ref document: A1