WO2010090027A1 - 分散型イベント配信システムにおけるブローカノードおよびイベントトピック制御方法 - Google Patents

分散型イベント配信システムにおけるブローカノードおよびイベントトピック制御方法 Download PDF

Info

Publication number
WO2010090027A1
WO2010090027A1 PCT/JP2010/000684 JP2010000684W WO2010090027A1 WO 2010090027 A1 WO2010090027 A1 WO 2010090027A1 JP 2010000684 W JP2010000684 W JP 2010000684W WO 2010090027 A1 WO2010090027 A1 WO 2010090027A1
Authority
WO
WIPO (PCT)
Prior art keywords
event
topic
node
event topic
control message
Prior art date
Application number
PCT/JP2010/000684
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 US13/147,675 priority Critical patent/US20110307603A1/en
Priority to JP2010549406A priority patent/JPWO2010090027A1/ja
Publication of WO2010090027A1 publication Critical patent/WO2010090027A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • 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/50—Network services
    • H04L67/55—Push-based network services

Definitions

  • the present invention relates to a distributed event distribution system, and more particularly to a broker node and an event topic control method in the distributed event distribution system.
  • Event distribution systems are widely used.
  • the event distribution system pushes a change in a state (ie, an event) such as a baseball game score change, a stock price change, and a weather change in real time from an event server (publisher) to an event client (subscriber).
  • a state ie, an event
  • This is a distribution system.
  • the event distribution procedure from the Publisher to the Subscriber is as follows. 1) Sending an advertise message 2) Sending a subscribe message 3) Creating a routing table 4) Sending a publish message; and 5) Forwarding a publish message
  • the event distribution system is divided into a centralized event distribution system that operates the event distribution system by a single server node and a distributed event distribution system that operates the event distribution system by a plurality of broker nodes.
  • a distributed event distribution system will be briefly described with reference to FIGS.
  • FIG. 1 is a diagram showing an example of a network configuration for generally explaining an event distribution system.
  • events are distributed from a plurality of publishers (hereinafter referred to as “Publishers”) PUB to a plurality of subscribers (hereinafter referred to as “Subscribers”) SUB through a network of a plurality of broker nodes EB.
  • Subscribers a plurality of publishers
  • Subscribers subscribers
  • a network having two publishers (PUB X , PUB Y ), two subscribers (SUB Z , SUB W ), and six broker nodes EB A -EB E Is illustrated.
  • FIG. 2 is a network configuration diagram for explaining the transmission of the Advertise message.
  • the Publisher notifies the event distribution system of what kind of event is to be distributed by an Advertise message.
  • the PublisherPUB decides an event topic (hereinafter referred to as “event Topic”, here “Kanto weather”) distributed by itself, and transmits it in an Advertise message (Adv).
  • the event Topic represents a topic of information transmitted using the event Topic. Publishers and Subscribers can use the same event Topic to send and receive events on the same topic.
  • the event Topic may have a hierarchical relationship with other event Topic.
  • the hierarchical relationship that there is is illustrated.
  • a filtering rule can be described in the Advertise message.
  • the Filtering rule can describe an arbitrary condition regarding the content of the event. Examples include keywords included in the event and the time zone when the event was sent.
  • the content of the event is described in XML, it can be described using Xpath. In the example shown in FIG. 2, PUB X designates “Kanagawa weather” and PUB Y designates “Tokyo weather” as filtering rules.
  • the Advertise message is first transmitted to the broker node to which the publisher is directly connected, and then the forwarding process is repeated by the broker node and delivered to the broker node called the rendezvous node.
  • the rendezvous node is selected from a plurality of broker nodes for each event Topic. If there is no broker node corresponding to the event Topic when the Advertise message is transmitted, it is newly selected.
  • PUB X sends an Advertise message Adv1 to broker node EB A , which is forwarded from EB A to rendezvous node EB F.
  • PUB Y sends an Advertise message Adv2 to broker node EB B , which is forwarded from EB B to rendezvous node EB F.
  • the broker node that transfers the Advertise message creates the Advertisement table AT when transferring the Advertise message.
  • the event Topic and Filtering rules described in the received Advertise message Adv are registered, and information for identifying the node of the immediately preceding hop is registered.
  • an advertisement table AT A including information such as the event Topic “Kanto weather”, Filtering rule “Kanagawa”, “PUB X ” identifying the immediately preceding hop node is generated in the broker node EB A.
  • the advertisement tables AT B and AT F are respectively created in the same manner.
  • FIG. 3 is a network configuration diagram for explaining the transmission of a Subscribe message.
  • the Subscriber notifies the event distribution system of what event is desired to be received by a Subscribe message.
  • the Subscriber determines an event Topic to be received, and transmits the event Topic in a Subscribe message. If the event to be received is limited to a narrower range of contents in the event Topic, a Filtering rule can be described in the Subscribe message in addition to the event Topic.
  • SUB Z designates “Yokohama weather” as the filtering rule in the Subscribe message Sub1
  • SUB W designates “Kawasaki weather” as the filtering rule in the Subscribe message Sub2.
  • the Subscribe messages Sub1 and Sub2 are repeatedly transferred by the broker node toward the rendezvous node EB F corresponding to the event Topic, similarly to the Advertise message.
  • a routing table is generated at the broker node as described below.
  • the event delivery system creates an event routing table for event delivery based on the Advertise message and the Subscribe message.
  • a broker node that transfers an Advertise message creates an Advertisement table AT when transferring the Advertise message.
  • the broker node creates a subscription table ST when transferring a subscription message.
  • the event Topic and Filtering rules described in the received Subscribe message Sub are registered, and information for identifying the node of the immediately preceding hop is registered.
  • the broker node merges the Filtering rules to reduce the table size or reduce the number of times the Subscribe message is transferred.
  • the broker node EB C has these Filtering rules “Yokohama” and “Kawasaki”. Is merged with “Kanagawa”.
  • the rendezvous node EB F that has received the Subscribe message Sub3 can transfer the Subscribe message Sub3 to the further broker node EB A by referring to the already created Advertisement table AT F.
  • the Subscribe message Sub3 is transferred on the reverse path of the Advertise message, and the Filtering rule specified by the Subscriber is registered in the broker node on the route. As described below, this makes it possible to filter the Publish message in the vicinity of the Publisher, thereby preventing unnecessary event distribution.
  • FIG. 4 is a network configuration diagram for explaining the transfer of the Publish message.
  • the Publish message is sequentially transferred by each of the broker nodes EB A , EB F , and EB C referring to the Subscription table. All Publish messages are basically delivered to the subscriber via the rendezvous node.
  • the broker node performs transfer only when the contents of the event of the Publish message are included in the range of the Filtering rule described in the Subscription table. For example, in FIG. 4, the broker node EB C, in order to Filtering rule notified from the broker node EB E "Kanagawa / Kawasaki" does not include the contents of the Publish message event, the Publish for broker node EB E Does not forward messages.
  • the event Topic is determined by estimating the occurrence frequency of events in advance. In other words, when the occurrence frequency is estimated to be high, the event Topic is narrowed to realize load balancing of the rendezvous node. When the occurrence frequency is estimated to be low, the event Topic is widened and the number of Subscribe messages and the routing table size are increased. Was achieved.
  • the method of estimating the event occurrence frequency in advance and determining the event Topic cannot flexibly cope with a change in load status.
  • an object of the present invention is to provide a broker node and an event topic control method that can flexibly cope with a change in an event transfer load in a distributed event distribution system.
  • the broker node dynamically changes the event topic for transferring the event according to the fluctuation of the transfer load and the monitoring means for monitoring the fluctuation of the transfer load of the event applied to the own node for each event rule. And a control means for notifying another node of an instruction accompanying the change by a control message.
  • the event topic control method monitors the change in the transfer load of the event applied to the own node for each event rule, and dynamically changes the event topic for transferring the event according to the change in the transfer load, An instruction associated with the change is notified to another node by a control message.
  • a publisher node is a publisher node in a distributed event distribution system having a plurality of broker nodes, and is an advertisement transmission means for transmitting an advertise message and a publish message for transmitting a publish message.
  • the control message is instructed by the control message for the new event topic or the merge destination event topic indicated by the control message.
  • the rendezvous node is sent as the final destination, and the new event topic or the merge destination event topic is displayed in the control message.
  • a control means for controlling so that a specific event topics that are instructed to use the cement transfer transmits the publish message to the rewritten to new events topic or the merge destination event topic.
  • the subscriber node is a subscriber node in a distributed event distribution system having a plurality of broker nodes, and receives a publish message and a subscribe transmission means for transmitting a subscribe message.
  • a control message instructing change of an event topic is received from a publish receiving means and a broker node
  • a Subscribe message describing a new event topic or merge destination event topic instructed in the control message is instructed in the control message.
  • a distributed event distribution system includes a publisher node that transmits an advertise message and a publish message, a subscriber node that transmits a subscribe message and receives the publish message.
  • a plurality of broker nodes that perform event transfer processing from the publisher node to the subscriber node, each broker node monitoring a change in event transfer load on the own node for each event rule, and the transfer
  • FIG. 1 It is a figure which shows the network structural example for demonstrating generally an event delivery system. It is a network block diagram for demonstrating transmission of an Advertise message. It is a network block diagram for demonstrating transmission of a Subscribe message. It is a network block diagram for demonstrating the transfer of a Publish message. It is a block diagram which shows the functional structure of the broker node containing the event Topic control apparatus by 1st Embodiment of this invention.
  • (A) is a figure which shows an example of a Subscription table
  • (B) is a figure which shows an example of Advertisement table. It is a figure which shows an example of the notification policy set to the transfer load fluctuation notification policy management table. It is a figure which shows an example of the control policy set to the event Topic control policy management table.
  • the broker node EB In a network as shown in FIG. 1, the broker node EB according to the present embodiment is provided with an event monitoring unit and an event Topic control unit which will be described later.
  • the event Topic represents a topic of information transmitted using the event Topic. Publishers and Subscribers can use the same event Topic to send and receive events on the same topic.
  • the event Topic may have a hierarchical relationship with other event Topic.
  • the event monitoring unit When transferring an event that matches a specific rule (hereinafter referred to as an event rule), the event monitoring unit measures the load applied to the node, and the transfer load fluctuation for the event rule is a specific pattern (hereinafter referred to as a transfer load fluctuation). If the pattern matches, the event rule and the transfer load fluctuation pattern are notified to the event Topic control unit.
  • the event monitoring unit estimates that a transfer load of an event that matches a specific event rule matches a specific transfer load fluctuation pattern based on a specific policy (transfer load fluctuation estimation policy), and the event rule and the transfer load The variation pattern may be notified to the event Topic control unit.
  • the event topic control unit receives a notification from the event monitoring unit, creates a new event topic or deletes the event topic, and transmits an event topic control message to the broker node, the publisher, and the subscriber related to the event topic. Notify new creation or deletion.
  • an event Topic control message is received from another broker node, the message is transferred to another broker node, the Publisher, or the Subscriber.
  • the broker node EB dynamically changes the event topic in accordance with a change in the load of event transfer, and notifies the other node by an instruction accompanying this change by the control message. Can respond flexibly to fluctuations in the load.
  • the configuration and operation of the broker node will be described in more detail.
  • FIG. 5 is a block diagram showing a functional configuration of a broker node including the event Topic control device according to the first embodiment of the present invention
  • FIG. 6A is a diagram showing an example of a Subscription table
  • FIG. 6B is a diagram illustrating an example of the Advertisement table.
  • the broker node EB functionally includes a subscription table 101, an advertisement table 102, a routing table management unit 103, and an event transfer unit 104, and further includes an event monitoring unit 105 and a transfer load change notification policy management table 106. And an event topic control unit 107 and an event topic control policy management table 108.
  • the Subscription table 101 and the Advertisement table 102 information on the event Topic, the filtering rule, and the next hop is registered for each entry ID as illustrated in FIG.
  • the routing table management unit 103 transfers the Advertisement message and the Subscribe message received from the adjacent broker node EB, Subscriber, or Publisher, and updates the Subscription table 101 or the Advertisement table 102 based on the information included in the received message. .
  • the routing table management unit 103 registers the adjacent node that has transferred the message to the own node in the Advertisement table 102 together with the event Topic and Filtering rules included in the Advertise message as the next hop.
  • the routing table management unit 103 When receiving the Subscribe message, the routing table management unit 103 registers the adjacent node that has transferred the message to the own node in the Subscription table 101 as a Next hop together with the event Topic and Filtering rules included in the Subscribe message.
  • the Filtering rule of the entry and the Filtering rule included in the received Subscribe message are merged. can do. For example, it is assumed that an entry having the event Topic “Kanto weather” and the filtering rule “/ Kanagawa / Yokohama” has already been registered in the Subscription table 101. Then, when a Subscribe message having the event Topic “Kanto weather” and the filtering rule “/ Kanagawa / Kawasaki” is received, an entry in which the Filtering rule is merged with “/ Kanagawa /” can be created and the existing entry can be deleted. it can. As a result, an increase in the size of the subscription table 101 is suppressed, and the time required for table search can be saved.
  • the received Subscribe message is transferred to the adjacent broker node on the route from the local node to the rendezvous node.
  • the event Topic of the Subscribe message is the same as the entry already registered in the Subscription table, and the relationship between the filtering rule F_sx of the entry and the filtering rule F_sy of the Subscribe message is “F_sy is included in F_sx”.
  • F_sx) the Subscribe message is not transferred. For example, if F_sy is / Yokohama / and F_sx is / Kanagawa /, the Subscribe message is not transferred.
  • the event transfer unit 104 When the event transfer unit 104 receives a publish message from the adjacent broker node EB or publisher, the event transfer unit 104 refers to the subscription table 101 and searches for an entry in which the received publish message is the same as the event topic and the event content matches the filtering rule. Then, the Publish message is transferred to the next hop registered in the searched entry.
  • the transfer load fluctuation estimation policy is registered in the transfer load fluctuation notification policy management table 106, and the event monitoring unit 105 determines that the transfer load fluctuation related to the specific event rule is based on the transfer load fluctuation estimation policy. It may be estimated that matches. In this case, the event rule and the estimated transfer load fluctuation pattern are notified to the event Topic control unit 107.
  • Event rules First, the event rule will be described. Examples of event rules are as follows.
  • Filtering rules (A) Filtering rule registered in Subscription table or Advertisement table; Arbitrary condition to be satisfied by event notified by Publish message; Keyword included in event and time zone of transmission. If the event content is described in XML, a rule described using Xpath can be considered; (B) Filtering rule set in advance: Same as (2.a) above.
  • the event rule can be expressed by a combination of the event Topic (1) and other rules. That is, the event Topic is always described in each event rule. A plurality of event topics may be specified in a single event rule.
  • the event Topic specified in the event rule is referred to as “target event Topic”.
  • Examples of the load measured by the event monitoring unit 105 include the following parameters.
  • Network bandwidth A network bandwidth that is occupied to transfer an event that matches the event rule.
  • CPU time CPU time required to transfer an event that matches the event rule. For example, the required CPU time increases as the filtering rules applied to the event become more complex.
  • various parameters can be considered as the load to be measured. These parameters may be used alone or in combination with a plurality of parameters.
  • transfer load fluctuation patterns include the following.
  • the transfer load exceeds or falls below a preset threshold value.
  • various patterns can be considered as transfer load fluctuation patterns. These patterns can be used alone, or a plurality of patterns can be combined and used as one transfer load fluctuation pattern.
  • the transfer load fluctuation notification policy management table 106 registers as a notification policy what kind of transfer load fluctuation pattern is detected for each event rule and notified to the event Topic control unit 107.
  • FIG. 7 is a diagram showing an example of a notification policy set in the transfer load fluctuation notification policy management table.
  • the event load that matches the event Topic “Kanto weather” and the filtering rule “/ Kanagawa / Yokohama” matches any pattern of A, B, (C ⁇ E), or (D ⁇ F).
  • a notification to the event Topic control unit 107 is generated.
  • (C ⁇ E) is a logical product of C and E, and means the following pattern. That is, the event monitoring unit 105 measures the network bandwidth and CPU usage rate used for event transfer, and refers to the transfer load fluctuation notification policy management table 106, so that the network bandwidth in the event rule exceeds 1 Mbps. (Pattern C), whether the CPU usage rate exceeds 50% (Pattern E) is determined. When both patterns C and E are satisfied (C ⁇ E), the event monitoring unit 105 notifies the event Topic control unit 107 of the event rule and the transfer load variation pattern of the (C ⁇ E).
  • the estimated policy consists of observed events and estimated events.
  • the event monitoring unit 105 estimates that an event described as an estimated event has occurred or will occur in the future.
  • Transfer events that match the event rules ⁇ Transfer load of events that match the event rules matches the transfer load fluctuation pattern
  • various events can be considered as observed events. These events can be used alone, or a plurality of events can be combined and used as one observation event.
  • the estimated event is a change in the transfer load for a specific event rule.
  • a single estimated event may be estimated from a plurality of observed events, or a plurality of estimated events may be estimated from a single observed event.
  • a single estimated event may be estimated from a logical expression obtained by combining a plurality of observed events with logical symbols such as AND and OR. For example, IF (observed event A AND observed event B), THEN (estimated event C); that is, if observed event A and observed event B are observed, the occurrence of estimated event C is estimated.
  • An estimated event may be estimated from time series conditions of a plurality of observed events. For example, when event B is observed within 10 minutes after observation of event A, the occurrence of estimated event C after 1 hour is estimated.
  • Event Topic Control Unit of Broker Node When receiving the load fluctuation notification from the event monitoring unit 105, the event Topic control unit 107 refers to the event Topic control policy management table 108, as will be described later. A new creation or deletion is performed, and an event Topic control message is transmitted. The event Topic control message notifies the broker node EB or the publisher or subscriber related to the event Topic of new creation or deletion of the event Topic.
  • the event Topic control policy management table 108 a control policy in which the notification content from the event monitoring unit 105 and the operation content of the event Topic control unit 107 are described is set.
  • the event Topic control unit 107 includes the control policy.
  • Event Topic is created / deleted according to the above.
  • FIG. 8 is a diagram showing an example of a control policy set in the event Topic control policy management table.
  • Event Topic to be created or deleted (2) A transfer load fluctuation pattern notified from the event monitoring unit 105.
  • an event Topic corresponding to the event rule whose transfer load variation pattern is measured or estimated is newly created. For example, when it is notified that the transfer load exceeds a threshold for an event that matches the event rule of event Topic: “Kanto weather” and Filtering rule: “Kanagawa / Yokohama /”, the event Topic, “ Yokohama weather "is newly created.
  • the event Topic corresponding to the event rule whose transfer load variation pattern is measured or estimated is deleted. For example, when it is notified that the transfer load has fallen below the threshold for an event that matches the event rule of event Topic: “Yokohama weather”, the event Topic “Yokohama weather” is deleted.
  • the event Topic control unit 107 immediately creates or deletes the event Topic. If it is estimated that the notification content will occur in the future, the event Topic is created or deleted at the timing described in the notification content. For example, when it is notified that the estimated event A occurs after 10 minutes, the event Topic is created or deleted after 10 minutes.
  • a rendezvous node responsible for the new event Topic is selected from other broker nodes EB. Then, in the event Topic control message, the created new event Topic, the new rendezvous node, and the event rule (including the target event Topic) notified from the event monitoring unit 105 are described and transmitted to create the new event Topic. Notify other nodes.
  • an event Topic (hereinafter referred to as a merge destination event Topic) that matches the event Topic to be deleted is determined from the existing event Topic. For example, when the event Topic “Yokohama weather” is deleted, “Kanto weather” is selected from the existing event Topic as the merge destination event Topic. Therefore, an event that has been transferred using the event Topic “Yokohama weather” is deleted and then transferred using “Kanto weather”. Subsequently, the event topic control unit 107 describes the merge destination event topic and the event rule notified from the event monitoring unit 105 (if the target event topic is included, the target event topic becomes the deletion target event topic). The event Topic control message is transmitted, and the deletion of the existing event Topic is notified to other nodes.
  • the creation and deletion of the event Topic may be performed simultaneously. For example, if a single event Topic control message is used to notify both the deletion of the event Topic and the creation of the event Topic, and the newly created event Topic is notified as the merge destination event Topic of the deletion target event Topic, the event Topic is moved. Can be realized.
  • creation and deletion of multiple event topics may be notified at the same time, an existing event topic is deleted, a plurality of event topics are newly created, and a plurality of newly created event topics are set as merge destination event topics. If notified, division of an existing event Topic into a plurality of event Topics can also be realized.
  • the operation content of the event topic control unit 107 is described for each event rule and transfer load variation pattern.
  • ID 1
  • a new event Topic is created.
  • a policy is described.
  • the event topic control unit 107 transfers an event topic control message with reference to the subscription table 101 and the advertisement table 102.
  • an entry that matches the target event Topic described in the event Topic control message is searched from the Subscription table 101 and / or the Advertisement table 102, and the event Topic is moved to the next hop described in the entry. Forward control messages.
  • the event Topic control message may not be forwarded to the described next hop.
  • the reason is that the next hop does not transfer an event using the new event Topic (more specifically, transfer of an event that matches the rule described in the event Topic control message). By doing so, the number of event Topic control message transfers can be suppressed.
  • an existing event Topic is to be deleted, an entry matching the target event Topic described in the event Topic control message is searched from the Subscription table 101 and / or the Advertisement table 102, and the next hop described in the entry is searched. And event Topic control message.
  • An entry that matches the deletion target event Topic may be deleted from the Subscription table 101 and the Advertisement table 102 immediately after the transfer of the event Topic control message or after a certain time has passed. In this way, unnecessary entries can be deleted quickly, and publishers and subscribers can delete Advertise messages and Subscribe messages (that is, Advertises indicating that events of the deletion target event Topic will not be sent and received in the future). Messages and Subscribe messages) are not required to be transmitted, and traffic generated by the transfer of the messages can be suppressed. If the event Topic control message is not deleted, it is only necessary to delete the Advertise message and Subscribe message stating that the event of the deletion target event Topic will not be transmitted / received in the future.
  • routing table management unit 103 The functions of the routing table management unit 103, the event transfer unit 104, the event monitoring unit 105, and the event topic control unit 107 described above can be realized by executing a program on a program control processor such as a CPU.
  • FIG. 9 is a block diagram schematically showing a functional configuration of a publisher in the present embodiment.
  • the Publisher PUB includes an Advertise transmission unit 201, an event generation unit 202, a Publish transmission unit 203, and an event Topic control message reception unit 204.
  • the Advertise transmission unit 201 describes the event Topic in the Advertise message, and transmits it to the broker node that is directly connected to the local node with the rendezvous node in charge of the event Topic as the final destination.
  • the event generation unit 202 detects some state change, that is, an event, and notifies the Publish transmission unit 203 of the change.
  • Examples of the event generation unit 202 include a sensor device that detects a change in weather and an application that detects the presence of a user.
  • the Publish transmission unit 203 describes the event Topic corresponding to the event together with the event notified from the event generation unit 202 in the Publish message, and transmits it to the broker node directly connected to the own node.
  • a single value may be set in advance for the event Topic, or a rule for determining the event Topic may be set based on the event content.
  • the event topic control message reception unit 204 receives an event topic control message from the broker node, rewrites and transfers the event topic of the publish message transmitted by the publish transmission unit 203, and sends an advertise message to the advertise transmission unit 201. Execute.
  • the final destination of the Publish message is rewritten to the rendezvous node responsible for the new event Topic and transferred to the broker node directly connected to the own node. Further, it instructs the Advertise transmission unit 201 to transmit the Advertise message in which the new event Topic is described with the rendezvous node in charge of the new event Topic as the final destination.
  • the event to be deleted Topic is an event Topic that has been added by an event Topic control message in the past, that is, if an event Topic control message notifying the creation of a new event to be deleted has been received, the event Topic to the event to be deleted Topic Cancel rewriting.
  • the event Topic of the merge destination is specified in the received event Topic control message
  • the event rewritten to the deletion target event Topic is rewritten to the merge destination event Topic.
  • the merge destination event Topic is not designated, the event is transmitted with the event Topic originally set in the own node. If the event to be deleted Topic is not an event Topic that was added in the past by an event Topic control message (that is, an event Topic that was originally set in the local node), an event that matches the event Topic to be deleted is set as a merge destination event Topic. Try to rewrite.
  • the publisher function described above can be realized by executing a program on a program control processor such as a CPU.
  • FIG. 10 is a block diagram schematically showing a functional configuration of a subscriber according to the present embodiment.
  • the Subscriber SUB includes a Subscribe transmission unit 301, an event Topic control message reception unit 302, and a Publish reception unit 303.
  • the Subscribe sending unit 301 describes the event Topic in the Subscribe message, and sends the rendezvous node in charge of the event Topic to the broker node directly connected to the own node as the final destination.
  • the event Topic control message receiving unit 302 receives the event Topic control message from the broker node, rewrites and transfers the event Topic of the Publish message received by the Publish receiving unit 303, and instructs the Subscribe sending unit 301 to send the Subscribe message.
  • the Publish receiving unit 303 receives the Publish message, extracts an event from the received message, and passes it to an application (not shown).
  • the event Topic control message receiving unit 302 intercepts a Publish message including an event that matches the event rule described in the message after receiving the message.
  • the event Topic of the event is rewritten to a new event Topic. Further, it instructs the Subscribe transmitting unit 301 to transmit a Subscribe message in which the new event Topic is described, with the rendezvous node in charge of the new event Topic as the final destination.
  • the event to be deleted Topic is an event Topic that has been added by an event Topic control message in the past, that is, if an event Topic control message notifying the creation of a new event to be deleted has been received, the event Topic to the event to be deleted Topic Cancel rewriting.
  • the event Topic of the merge destination is specified in the received event Topic control message
  • the event rewritten to the deletion target event Topic is rewritten to the merge destination event Topic.
  • the merge destination event Topic is not designated, the event is transmitted with the event Topic originally set in the own node. If the event to be deleted Topic is not an event Topic that was added in the past by an event Topic control message (that is, an event Topic that was originally set in the local node), an event that matches the event Topic to be deleted is set as a merge destination event Topic. Try to rewrite.
  • Subscriber function can be realized by executing a program on a program control processor such as a CPU.
  • Event Topic Control Operation Next, the operation of the distributed event distribution system according to the present embodiment will be described. First, the operation when creating a new event Topic will be described with reference to the examples shown in FIGS.
  • the transfer load fluctuation notification policy management table 106 is provided in the broker node EB, and an event rule and a transfer load fluctuation pattern (that is, a notification policy) are set in advance.
  • an event rule and a transfer load fluctuation pattern that is, a notification policy
  • the event monitoring unit 105 detects that the event transfer load of a specific event rule matches the transfer load variation pattern by referring to the transfer load variation notification policy management table 106 (or estimates that it matches)
  • the event rule and the transfer load fluctuation pattern are notified to the event Topic control unit 107.
  • the event topic control unit 107 When receiving a load change notification from the event monitoring unit 105, the event topic control unit 107 creates a new event topic corresponding to the notified event rule and selects a rendezvous node from among broker nodes.
  • the distributed event distribution system shown in FIG. 11 will be described as an example.
  • FIG. 11 is a network diagram for explaining a procedure for creating a new event Topic in the distributed event distribution system according to the present embodiment.
  • the broker node EB F is selected as the rendezvous node responsible for the event Topic “Kanto weather”.
  • the contents shown in FIG. 7 are set as the notification policy in the transfer load fluctuation notification policy management table 106 of the broker node EB F.
  • the event Topic control unit 107 of the broker node EB F creates an event Topic control message, and refers to the Advertisement table and the Subscription table to the next hop that matches the event rule notified from the event monitoring unit 105. Send a control message.
  • FIG. 12 is a network diagram for explaining an event Topic control message transmission procedure in the distributed event distribution system according to the present embodiment. However, FIG. 12 shows an operation after the operation of the distributed event distribution system shown in FIG. 11 is completed.
  • the broker node EB F creates an event Topic control message shown in FIG. 12 as "ETC", with reference to the Advertisement table AT F and Subscription table ST F itself and transmits the event Topic control message ETC.
  • ETC event Topic control message
  • the Subscription table ST F event Topic control message ETC is transferred to the broker node EB C.
  • the broker nodes EB A and EB C transfer the received event Topic control message ETC with reference to the Advertisement table and the Subscription table.
  • Next Hop no transfer event Topic control message, for example from the broker node EB C and EB A to EB F
  • the transfer of the event Topic control message ETC referring to the advertisement table and the subscription table of each broker node is repeated, and finally the event Topic control message ETC transmits an event using the newly created event Topic.
  • All Publishers and Subscribers here, PUB X and SUB Z ) that receive data.
  • FIG. 13 is a network diagram for explaining an event delivery path construction procedure in the distributed event delivery system according to the present embodiment. However, FIG. 13 shows an operation after the operation of the distributed event distribution system shown in FIG. 12 is completed.
  • the PublisherPUB X and the SubscriberSUB Z that have received the event Topic control message ETC directly connect the Advertise message and the Subscriber node in which the new event Topic is described with the rendezvous node EB 3 notified by the event Topic control message ETC as the final destination. Send to. As a result, an event delivery path corresponding to the new event Topic is constructed.
  • the PublisherPUB X When receiving the event Topic control message ETC, the PublisherPUB X transmits an Advertise message describing the new event Topic “Weather in Yokohama” with the new rendezvous node EB 3 described in the event Topic control message ETC as the final destination. This message is transferred at the broker nodes EB 1 and EB 2 (an entry in the Advertisement table is created as in the case of normal Advertise message transfer), and reaches the new rendezvous node EB 3 .
  • the Subscriber SUB Z receives the event Topic control message ETC, the Subscriber SUB 3 describes the new event Topic “Weather in Yokohama” with the new rendezvous node EB 3 described in the event Topic control message ETC as the final destination.
  • a new entry is created on the subscription table of the broker nodes EB 4 , EB 3 , EB 2 , and EB 1 .
  • FIG. 14 is a network diagram for explaining an event transfer procedure in the distributed event distribution system according to the present embodiment. However, FIG. 14 shows an operation after the operation of the distributed event distribution system shown in FIG. 13 is completed.
  • the event can be transferred using the newly created event Topic.
  • the event topic control message reception unit 204 of the publisher PUB X intercepts the event, and the event of the event Rewrite Topic to new event Topic. Accordingly, the Publish message is transferred to the Subscriber SUB Z using the new event Topic. That is, the event is transferred using the event distribution path corresponding to the new event Topic created in the above-described steps. Since the event transfer using the new event Topic is transferred via the rendezvous node EB 3 in charge of the new event Topic, the load is distributed among the rendezvous nodes.
  • the event topic control message reception unit 302 of the subscriber SUB Z rewrites the event topic pic of the event received using the new event topic and passes it to the publish reception unit 303.
  • PublisherPUB X rewrites the event Topic of the event matching / Kanagawa / Yokohama with “weather in Yokohama” and transmits it.
  • the event is transferred to the Subscriber SUB Z via the new rendezvous node EB 3 by the event delivery path constructed by the operation shown in FIG.
  • FIG. 15 is a network diagram for explaining a procedure for deleting an event Topic in the distributed event distribution system according to the present embodiment. However, FIG. 15 shows an operation after the operation of the distributed event distribution system shown in FIG. 14 is completed.
  • the event monitoring unit 105 detects or matches that the event transfer load of a specific event rule matches the transfer load fluctuation pattern, The event rule and the transfer load fluctuation pattern are notified to the event Topic control unit 107.
  • the event topic control unit 107 selects the target event Topic of the notified event rule as the deletion target event Topic, and selects the merge destination event Topic and the rendezvous node.
  • the event Topic control unit 107 creates an event Topic control message ETC, refers to the Advertisement table and the Subscription table, and sends the event Topic control message ETC to the next hop that matches the event rule notified from the event monitoring unit 105. Send.
  • the broker node that transfers the event Topic control message ETC deletes an entry that matches the deletion target event Topic described in the event Topic control message. As a result, the event delivery path used for event transfer of the deletion target event Topic is deleted.
  • the broker node EB 3 detects or estimates that the change in the transfer load of the event Topic “Yokohama weather” matches the transfer load change pattern associated with the deletion of the event Topic.
  • the event Topic control message ETC shown in FIG. 5 is created, and the message is transmitted to the next hop of the entry having the event Topic “Yokohama weather” registered in the Advertisement table and the Subscription table.
  • the event Topic control message ETC is sequentially transferred to the next hop of the entry having the event Topic “Yokohama weather” registered in the Advertisement table and the Subscription table by the broker node that has received the event Topic control message ETC, and finally the event Topic “Yokohama It is delivered to Publisher PUB X and Subscriber SUB Z that send and receive events using “weather”.
  • each broker node EB 1 to EB 4 that has transferred the event Topic control message ETC deletes the entry having the event Topic “Weather in Yokohama” from the Advertisement table and the Subscription table. As a result, the event delivery path used for transferring the event Topic “Yokohama weather” is deleted.
  • the broker node When the event transfer load increases or is expected to increase, the broker node according to the present embodiment creates a new event Topic and newly selects a rendezvous node that is responsible for the new event Topic, and then sends it to the Publisher or Subscriber. Instructs to create a new event delivery path.
  • the event delivery path is newly created by transmitting the Advertise message and the Subscribe message to the rendezvous node in which the Publisher or Subscriber receiving the instruction is newly selected.
  • Publisher and Subscriber send and receive events using a new event distribution path for some or all events.
  • the load of event transfer has increased or is expected to increase
  • the load of the existing event distribution path can be distributed to the newly created event distribution path.
  • the broker node when the event event transfer load is reduced or expected to decrease, deletes the existing event Topic and the merge destination event Topic that should be used for transmission / reception of the event after the deletion.
  • the event delivery path corresponding to the deleted event Topic is instructed to the Publisher or Subscriber.
  • the Publisher or Subscriber Upon receiving the instruction, deletes the event delivery path by transmitting an Advertise message or Subscribe message.
  • the existing event delivery path when the event transfer load is reduced or expected to decrease, the existing event delivery path can be deleted to reduce the overhead associated with maintaining the event delivery path. .
  • the Publisher and the Subscriber transmit / receive an event transmitted / received using the deleted event Topic using the merge destination event Topic.
  • the event can be transmitted and received even after the event delivery path is deleted.
  • the broker node has an event rule that can be added as a condition in addition to an event Topic, such as a filtering rule and an attribute of a publish message, and the event monitoring unit in the broker node sets each event rule. This is to monitor the transfer load.
  • the broker node creates a new event Topic corresponding to an event rule whose transfer load is increased or is expected to increase, selects a new rendezvous node, and transfers the event rule to the Publisher and Subscriber together with the new event Topic and the new rendezvous node. Notify and instruct to create a new event delivery path.
  • the Publisher and Subscriber Upon receiving the instruction, the Publisher and Subscriber transmit and receive an event that matches the notified event rule using the new event distribution path after creating the new event distribution path.
  • the method according to the present embodiment that is, a method in which a plurality of event distribution paths used for event transmission / reception of the same event Topic are prepared and the load distribution is performed by using the event distribution path by a method such as round robin Efficient.
  • the broker node can newly create or delete an event distribution path without grasping individual publishers and subscribers.
  • the reason is that the event Topic control message is transmitted and transferred in the broker node with reference to the Advertisement table and the Subscription table.
  • the Advertisement table and the Subscription table the next hop of the route to the Publisher and Subscriber that transmits and receives an event that matches the event Topic and Filtering rule is registered for each event Topic and Filtering rule.
  • the broker node forwards the event Topic control message to the Next hop of the Advertisement table and Subscription table that match the event rule of the event Topic control message, so that each broker node does not have to know the individual publishers and subscribers.
  • the event Topic control message can be delivered to the Publisher and Subscriber.
  • the broker node When there are a very large number (for example, 10 million) of Publishers and Subscribers, and when connection and disconnection to the event delivery path of Publishers and Subscribers are frequently performed, the broker node has an IP address of each Publisher or Subscriber. Although it is unrealistic to always grasp the participation state in the event distribution path, the broker node according to the present embodiment can cope with such a case.
  • Second Embodiment The second embodiment of the present invention has the same basic configuration as the first embodiment, but the reach of the event Topic control message is set near the broker node that created the new event Topic. The point which can restrict
  • FIG. 16 is a network diagram showing an event distribution path of the event Topic “Kanto weather”. As described above, the event distribution path 401 is set from the rendezvous node in charge of “weather in Kanto” to a plurality of publishers and subscribers.
  • FIG. 17 is a network diagram showing an event distribution path of the event Topic “Yokohama Weather” in the first embodiment of the present invention.
  • the event Topic control message reachable range 403 is the end of the event delivery path. That is, all the publishers and subscribers are reached. In other words, an event delivery path for a new event Topic “Yokohama Weather” is newly constructed from the end.
  • FIG. 18 is a network diagram showing an event distribution path of the event Topic “Yokohama Weather” in the second embodiment of the present invention.
  • the reach 501 of the event Topic control message is limited to the vicinity of the rendezvous node responsible for the event Topic “Kanto weather”.
  • the event delivery path of the new event Topic “Yokohama Weather” uses the same route as the event Topic “Kanto Weather” near the end of the Publisher and Subscriber, and the different route is used for the event Topic “Kanto” Only in the vicinity of the rendezvous node in charge of
  • the reach of the event Topic control message is limited to the vicinity of the broker node that has created the new event Topic.
  • FIG. 19 is a block diagram showing a functional configuration of a broker node including an event Topic control device according to the second embodiment of the present invention, and FIG. 20 is set in the event Topic control policy management table. It is a figure which shows an example of the control policy which is set. It should be noted that blocks having the same functions as those of the broker node in the first embodiment shown in FIG.
  • the broker node EB functionally includes a subscription table 101, an advertisement table 102, a routing table management unit 103, and an event transfer unit 104, and further includes an event monitoring unit 105 and a transfer load change notification policy management table 106.
  • the event topic control unit 601 functionally includes a TTL control unit 601a for setting / changing the reach of the event topic control message, as will be described later.
  • the broker node EB in the present embodiment and the broker node EB in the first embodiment shown in FIG. 5 are different in the functions of the event Topic control unit 601 and the event Topic control policy management table 602, and further the event Topic control message receiving unit. 603, Subscribe transmission unit 604 and Advertise transmission unit 605 are different. Hereinafter, this different point will be described in detail.
  • the event Topic control unit 601 in FIG. 19 has a TTL control unit 601a as a reach control function for arbitrarily controlling the reach for an event Topic control message.
  • the reach of the event Topic control message can be arbitrarily controlled as follows. For example, a TTL (Time To Live) value is set at a node that creates an event Topic control message, and when transferring an event Topic control message received from another broker node, the TTL value is reduced by 1 and the TTL value is zero. Otherwise, the sequence is executed, and if the TTL value becomes zero, the event Topic control message is received and not transferred.
  • TTL Time To Live
  • the control policy set in the event Topic control unit 601 is an extension of the control policy of the first embodiment shown in FIG. That is, the TTL value set in the event Topic control message is set as a part of the operation content corresponding to the event rule and the transfer load fluctuation pattern.
  • the calculation of the TTL when transferring the event Topic control message received from another broker node can be flexibly changed according to its own load. Basically, a process of subtracting 1 is performed at the time of transfer. For example, when the load is extremely low, the event Topic control message transfer range (that is, a range for constructing a new event delivery path) is reduced by 5 at the time of transfer. ) Can be limited to the vicinity of itself. On the other hand, when the load is large, the transfer range can be expanded by increasing the TTL by one.
  • the event Topic control unit 601 in this embodiment decrements TTL by 1 when transferring an event Topic control message received from another broker node.
  • TTL value becomes zero
  • the event Topic control message reception unit 603 To receive the event Topic control message.
  • the event Topic control message reception unit 603 is the same as the event Topic control message reception unit (204, 302) of the Publisher or Subscriber in the first embodiment shown in FIGS. Receive processing. Specifically, it is as follows.
  • the event Topic control message receiving unit 603 When an adjacent broker node transfers an event Topic control message to its own node by referring to the Advertisement table, the event Topic control message receiving unit 603 is connected to the event Topic control message receiving unit 204 of the Publisher in the first embodiment. Similar processing is performed. In other words, the event Topic control message receiving unit 603 sends an Advertise message describing the new event Topic notified by the event Topic control message to the Advertise transmission unit 605, and a new rendezvous node notified by the event Topic control message. Instruct to send as final destination.
  • the event rule described in the event Topic control message is referred to, and the Publish message including an event that matches the event rule is intercepted. Then, the event Topic of the Publish message is rewritten to the new event Topic notified by the event Topic control message.
  • the event is distributed using the new event Topic. That is, the event is distributed using the new event distribution path created when the new event Topic is created.
  • the event Topic control message receiving unit 603 is connected to the event Topic control message receiving unit 302 of the Subscriber in the first embodiment. Similar processing is performed. That is, the event Topic control message receiving unit 603 sends a Subscribe message describing the new event Topic notified by the event Topic control message to the Subscribe sending unit 604, and a new rendezvous node notified by the event Topic control message. Instruct to send as final destination.
  • the publish message including the event of the new event Topic is intercepted by referring to the new event Topic described in the received event Topic control message. Then, the event Topic of the Publish message is rewritten to the target event Topic described in the event rule. After rewriting, the event is distributed using the target event Topic. That is, the event is distributed using the event distribution path for distributing the event of the target event Topic that has existed before the creation of the new event Topic.
  • the Subscribe transmission unit 604 receives a command from the event Topic control message reception unit 603, receives a Subscribe message describing the new event Topic notified by the event Topic control message, and a new rendezvous node notified by the event Topic control message. Send as final destination.
  • the Advertise sending unit 605 receives the instruction from the event Topic control message receiving unit 603 and sends the Advertise message describing the new event Topic notified by the event Topic control message to the new rendezvous node also notified by the event Topic control message. Send as final destination.
  • routing table management unit 103 event transfer unit 104, event monitoring unit 105, event Topic control unit 601, event Topic control message reception unit 603, Subscribe transmission unit 604, and Advertise transmission unit 605 are the same as those described above. It can also be realized by executing a program on a program control processor.
  • a) Overhead associated with new creation and deletion of an event delivery path can be suppressed. Specifically, it is as follows.
  • the broker node that transmits the event Topic control message can arbitrarily control the reach by setting the TTL of the event Topic control message. Further, the broker node whose TTL of the event Topic control message becomes 0 at the time of transfer can transmit the Advertise message and the Subscribe message instead of the Publisher and the Subscriber. This eliminates the need to transfer the event Topic control message to the end of the event delivery path (that is, Publisher, Subscriber), and it is possible to suppress the overhead associated with newly creating and deleting the event delivery path.
  • the range in which a new event distribution path is created can be controlled in accordance with fluctuations in the event transfer load. This is because the broker node that transmits or forwards the event Topic control message can change the TTL value of the event Topic control message in accordance with the fluctuation of the event transfer load. For example, the larger the detected increase in the load, the larger the TTL value can be set, so that the event Topic control message reaches a wide range, and a new event distribution path can be created in a wider range. become.
  • the present invention is applicable to broker node-based distributed event delivery systems in general.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Accounting & Taxation (AREA)
  • Development Economics (AREA)
  • Finance (AREA)
  • Economics (AREA)
  • Game Theory and Decision Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Marketing (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

　ブローカノードは、分散型イベント配信システムにおいてイベントの転送処理を行うブローカノードであって、イベント転送負荷の変動に柔軟に対応するために、イベントルール毎に自ノードにかかるイベントの転送負荷の変動を監視する監視手段と、転送負荷の変動に応じて当該イベントを転送するためのイベントトピックを動的に変更し、この変更に伴う指示を制御メッセージ（イベントＴｏｐｉｃ制御メッセージ）により他のノードへ通知する制御手段とを備えている。

Description

分散型イベント配信システムにおけるブローカノードおよびイベントトピック制御方法
　本発明は分散型イベント配信システムに係り、特に分散型イベント配信システムにおけるブローカノードおよびイベントトピック制御方法に関する。
　イベント配信システムが広く利用されている。イベント配信システムは、野球の試合のスコア変化、株価の変化、天候の変化など、何らかの状態の変化(すなわちイベント)をリアルタイムかつプッシュでイベントサーバ（パブリッシャ：Ｐｕｂｌｉｓｈｅｒ）からイベントクライアント（サブスクライバ：Ｓｕｂｓｃｒｉｂｅｒ）へ配信するシステムである。イベント配信システムにおいて、ＰｕｂｌｉｓｈｅｒからＳｕｂｓｃｒｉｂｅｒへのイベントの配信手順は次の通りである。
１）アドバタイズ（Ａｄｖｅｒｔｉｓｅ）メッセージの送信
２）サブスクライブ（Ｓｕｂｓｃｒｉｂｅ）メッセージの送信
３）ルーティングテーブルの作成
４）Ｐｕｂｌｉｓｈメッセージの送信；および５）Ｐｕｂｌｉｓｈメッセージの転送
　イベント配信システムは単一のサーバノードによりイベント配信システムを運用する集中型イベント配信システムと複数のブローカノードによりイベント配信システムを運用する分散型イベント配信システムに分けられる。以下、非特許文献１に基づき、分散型イベント配信システムについて図１～図４を参照しながら簡単に説明する。
　図１はイベント配信システムを一般的に説明するためのネットワーク構成例を示す図である。ここでは、複数のパブリッシャ（以下、Ｐｕｂｌｉｓｈｅｒと記す。）ＰＵＢから複数のサブスクライバ（以下、Ｓｕｂｓｃｒｉｂｅｒと記す。）ＳＵＢへ複数のブローカノードＥＢのネットワークを通してイベントが配信される。ただし、以下の説明では、簡略化するために、２つのＰｕｂｌｉｓｈｅｒ（ＰＵＢＸ、ＰＵＢＹ）と、２つのＳｕｂｓｃｒｉｂｅｒ（ＳＵＢＺ、ＳＵＢＷ）と、６つのブローカノードＥＢＡ－ＥＢＥとを有するネットワークを例示する。
１）Ａｄｖｅｒｔｉｓｅメッセージの送信
　図２はＡｄｖｅｒｔｉｓｅメッセージの送信を説明するためのネットワーク構成図である。Ｐｕｂｌｉｓｈｅｒは、どのようなイベントを配信するかをＡｄｖｅｒｔｉｓｅメッセージによりイベント配信システムへ通知する。まず、ＰｕｂｌｉｓｈｅｒＰＵＢは自身が配信するイベントトピック（以下、イベントＴｏｐｉｃと記す。ここでは「関東の天気」）を決め、Ａｄｖｅｒｔｉｓｅメッセージ（Ａｄｖ）に記載して送信する。なお、イベントＴｏｐｉｃは、当該イベントＴｏｐｉｃを用いて発信される情報のトピックを表す。ＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒが同一のイベントＴｏｐｉｃを用いることで同一トピックのイベントの発信、受信を行うことが可能になる。イベントＴｏｐｉｃは他のイベントＴｏｐｉｃとの階層関係を持っていてもよい。ここでは、「日本の天気」の下位に「関東の天気」、「東海の天気」・・・があり、「関東の天気」の下位に「東京の天気」、「横浜の天気」・・・がある、という階層関係を例示する。
　Ｐｕｂｌｉｓｈｅｒは自身が配信するイベントがイベントＴｏｐｉｃ内のさらに狭い範囲の内容に限定される場合、イベントＴｏｐｉｃに加えて、フィルタリング（Ｆｉｌｔｅｒｉｎｇ）ルールをＡｄｖｅｒｔｉｓｅメッセージに記載することができる。Ｆｉｌｔｅｒｉｎｇルールはイベントの内容に関する任意の条件を記述することができる。イベントに含まれるキーワードや発信された時間帯などが例として挙げられる。また、イベントの内容がＸＭＬで記述される場合はＸｐａｔｈを用いて記述することが考えられる。図２に示す例では、ＰＵＢＸが「神奈川の天気」、ＰＵＢＹが「東京の天気」をＦｉｌｔｅｒｉｎｇルールとして指定している。
　Ａｄｖｅｒｔｉｓｅメッセージは最初にＰｕｂｌｉｓｈｅｒが直接接続しているブローカノードに対して送信され、その後ブローカノードにより転送処理が繰り返されてランデブーノードと呼ばれるブローカノードへ届けられる。ランデブーノードは、後述するように、イベントＴｏｐｉｃ毎に複数のブローカノードから選択される。Ａｄｖｅｒｔｉｓｅメッセージ送信時にイベントＴｏｐｉｃに対応するブローカノードが存在しない場合には新規に選択される。図２によれば、ＰＵＢＸがＡｄｖｅｒｔｉｓｅメッセージＡｄｖ１をブローカノードＥＢＡへ送信し、ＥＢＡからランデブーノードＥＢＦへ転送される。同様に、ＰＵＢＹがＡｄｖｅｒｔｉｓｅメッセージＡｄｖ２をブローカノードＥＢＢへ送信し、ＥＢＢからランデブーノードＥＢＦへ転送される。
　Ａｄｖｅｒｔｉｓｅメッセージを転送するブローカノードは、転送する際にＡｄｖｅｒｔｉｓｅｍｅｎｔテーブルＡＴを作成する。ＡｄｖｅｒｔｉｓｅｍｅｎｔテーブルＡＴには、受信したＡｄｖｅｒｔｉｓｅメッセージＡｄｖに記載されたイベントＴｏｐｉｃ、Ｆｉｌｔｅｒｉｎｇルールが登録されるほか、直前ホップのノードを識別する情報が登録される。ここでは、ブローカノードＥＢＡに、イベントＴｏｐｉｃ「関東の天気」、Ｆｉｌｔｅｒｉｎｇルール「神奈川」、直前ホップのノードを識別する「ＰＵＢＸ」などの情報を含むアドバタイズメント（Ａｄｖｅｒｔｉｓｅｍｅｎｔ）テーブルＡＴＡが生成される。ブローカノードＥＢＢおよびランデブーノードＥＢＦでも、同様にしてＡｄｖｅｒｔｉｓｅｍｅｎｔテーブルＡＴＢおよびＡＴＦがそれぞれ作成される。
２）Ｓｕｂｓｃｒｉｂｅメッセージの送信
　図３はＳｕｂｓｃｒｉｂｅメッセージの送信を説明するためのネットワーク構成図である。Ｓｕｂｓｃｒｉｂｅｒは、どのようなイベントを受信したいかをＳｕｂｓｃｒｉｂｅメッセージによりイベント配信システムへ通知する。Ｓｕｂｓｃｒｉｂｅｒは、受信したいイベントＴｏｐｉｃを決め、Ｓｕｂｓｃｒｉｂｅメッセージに記載して送信する。受信したいイベントがイベントＴｏｐｉｃ内のさらに狭い範囲の内容に限定される場合には、イベントＴｏｐｉｃに加えて、ＦｉｌｔｅｒｉｎｇルールをＳｕｂｓｃｒｉｂｅメッセージに記載することができる。ここでは、ＳＵＢＺがＳｕｂｓｃｒｉｂｅメッセージＳｕｂ１にＦｉｌｔｅｒｉｎｇルールとして「横浜の天気」を、ＳＵＢＷがＳｕｂｓｃｒｉｂｅメッセージＳｕｂ２にＦｉｌｔｅｒｉｎｇルールとして「川崎の天気」を、それぞれ指定している。
　ＳｕｂｓｃｒｉｂｅメッセージＳｕｂ１およびＳｕｂ２は、Ａｄｖｅｒｔｉｓｅメッセージと同様に、イベントＴｏｐｉｃに対応したランデブーノードＥＢＦへ向けてブローカノードにより転送処理が繰り返し行われる。この転送処理を行う際に、次に述べるようにブローカノードでルーティングテーブルが生成される。
３）ルーティングテーブルの作成
　イベント配信システムは、ＡｄｖｅｒｔｉｓｅメッセージおよびＳｕｂｓｃｒｉｂｅメッセージに基づいて、イベント配信のためのイベントルーティングテーブルを作成する。図２に示すように、Ａｄｖｅｒｔｉｓｅメッセージを転送するブローカノードは、転送する際にＡｄｖｅｒｔｉｓｅｍｅｎｔテーブルＡＴを作成する。図３に示すように、ブローカノードはＳｕｂｓｃｒｉｂｅメッセージを転送する際、サブスクリプション（Ｓｕｂｓｃｒｉｐｔｉｏｎ）テーブルＳＴを作成する。
　ＳｕｂｓｃｒｉｐｔｉｏｎテーブルＳＴには、受信したＳｕｂｓｃｒｉｂｅメッセージＳｕｂに記載されたイベントＴｏｐｉｃ、Ｆｉｌｔｅｒｉｎｇルールが登録されるほか、直前ホップのノードを識別する情報が登録される。ただし、複数のＳｕｂｓｃｒｉｂｅメッセージＳｕｂにおいてＦｉｌｔｅｒｉｎｇルールの地域範囲が重複する場合には、当該ブローカノードはＦｉｌｔｅｒｉｎｇルールをマージして、テーブルサイズの抑制を図ったり、Ｓｕｂｓｃｒｉｂｅメッセージの転送回数を減らしたりする。
　たとえば、ブローカノードＥＢＣは、ＳｕｂｓｃｒｉｂｅメッセージＳｕｂ１のＦｉｌｔｅｒｉｎｇルールが「神奈川／横浜」であり、ＳｕｂｓｃｒｉｂｅメッセージＳｕｂ２のＦｉｌｔｅｒｉｎｇルールが「神奈川／川崎」であるから、これらのＦｉｌｔｅｒｉｎｇルール「横浜」および「川崎」を「神奈川」にマージする。これによって、ランデブーノードＥＢＦへ転送するＳｕｂｓｃｒｉｂｅメッセージ数を１つ（Ｓｕｂ３）に減らし、ランデブーノードＥＢＦで作成されるテーブルエントリの数も１つに抑制することができる（ＳｕｂｓｃｒｉｐｔｉｏｎテーブルＳＴＦ）。
　また、ＳｕｂｓｃｒｉｂｅメッセージＳｕｂ３を受信したランデブーノードＥＢＦは、既に作成されたＡｄｖｅｒｔｉｓｅｍｅｎｔテーブルＡＴＦを参照することで、更に先のブローカノードＥＢＡへＳｕｂｓｃｒｉｂｅメッセージＳｕｂ３を転送することができる。これにより、ＳｕｂｓｃｒｉｂｅメッセージＳｕｂ３がＡｄｖｅｒｔｉｓｅメッセージのリバースパスを転送されることになり、経路上のブローカノードにＳｕｂｓｃｒｉｂｅｒの指定したＦｉｌｔｅｒｉｎｇルールが登録されていく。これによって、以下で述べるように、Ｐｕｂｌｉｓｈｅｒの近くでＰｕｂｌｉｓｈメッセージのフィルタリングを行うことが可能になり、不要なイベントの配信が防止される。
　以上の動作によりＰｕｂｌｉｓｈｅｒからランデブーノードを経由し、Ｓｕｂｓｃｒｉｂｅｒへ至るイベント配信ツリーが作成されることになる。
４）Ｐｕｂｌｉｓｈメッセージの送信
　イベントが発生すると、Ｐｕｂｌｉｓｈｅｒは、イベントＴｏｐｉｃおよびイベントを記載したＰｕｂｌｉｓｈメッセージをイベント配信システムへ送信する。
５）Ｐｕｂｌｉｓｈメッセージの転送
　図４はＰｕｂｌｉｓｈメッセージの転送を説明するためのネットワーク構成図である。Ｐｕｂｌｉｓｈメッセージは、ブローカノードＥＢＡ、ＥＢＦ、ＥＢＣの各々がＳｕｂｓｃｒｉｐｔｉｏｎテーブルを参照することで順次転送される。Ｐｕｂｌｉｓｈメッセージは基本的に全てランデブーノードを経由してＳｕｂｓｃｒｉｂｅｒへ配信されることになる。
　ブローカノードは、Ｓｕｂｓｃｒｉｐｔｉｏｎテーブルに記載されたＦｉｌｔｅｒｉｎｇルールの範囲内にＰｕｂｌｉｓｈメッセージのイベントの内容が含まれる場合にのみ転送を行う。例えば、図４において、ブローカノードＥＢＣは、ブローカノードＥＢＥから通知されたＦｉｌｔｅｒｉｎｇルール「神奈川／川崎」にＰｕｂｌｉｓｈメッセージのイベントの内容が含まれないため、ブローカノードＥＢＥに対しては当該Ｐｕｂｌｉｓｈメッセージの転送は行わない。
Peter Pietzuch and Jean Bacon Hermes: A Distributed Event-Based Middleware Architecture 1st International Workshop on Distributed Event-Based Systems (DEBS'02), http://www.doc.ic.ac.uk/~peter/manager/doc/prp-debs 2002-hermes.pdf
　上述した非特許文献１に記載されたような分散型イベント配信システムでは、イベントＴｏｐｉｃの決め方が重要となる。例えば、日本の天気に関するイベントを配信する場合、イベントＴｏｐｉｃを「日本の天気」といったように広い範囲でとるとランデブーノードには「日本の天気」に含まれるイベントが全て配信されることとなる。このために、台風が接近した場合などイベントの発生頻度が高くなった場合、ランデブーノードのＰｕｂｌｉｓｈメッセージ転送負荷は非常に高くなってしまう。
　一方でイベントＴｏｐｉｃを「横浜の天気」といったように狭い範囲でとった場合、地域毎にランデブーノードが選択されることでランデブーノードの負荷は分散されるが、多数のイベントＴｏｐｉｃが並立することになる。このために、上述したようなＦｉｌｔｅｒｉｎｇルールのマージが行われず、Ｓｕｂｓｃｒｉｂｅメッセージ数やルーティングテーブル数が増加してしまう。
　このように上述した分散型イベント配信システムでは、事前にイベントの発生頻度を推定してイベントＴｏｐｉｃを決めていた。すなわち、発生頻度が高いと見積もられる場合にはイベントＴｏｐｉｃを狭くとることでランデブーノードの負荷分散を実現し、発生頻度が低いと見積もられる場合にはイベントＴｏｐｉｃを広くとりＳｕｂｓｃｒｉｂｅメッセージ数やルーティングテーブルサイズの抑制を実現していた。
　しかしながら、当初の見積もりと比較してイベントの発生頻度が高くなれば、ランデブーノードへ負荷が集中することになり、低くなれば負荷分散の効果に比べＳｕｂｓｃｒｉｂｅメッセージ数やルーティングテーブルサイズ等のコストの方が大きくなる。このように事前にイベントの発生頻度を推定してイベントＴｏｐｉｃを決めておく方式では、負荷の状況変化に柔軟に対応することができない。
　そこで、本発明の目的は、分散型イベント配信システムにおいてイベント転送負荷の変動に柔軟に対応することができるブローカノードおよびイベントトピック制御方法を提供することにある。
　本発明によるブローカノードは、イベントルール毎に自ノードにかかるイベントの転送負荷の変動を監視する監視手段と、転送負荷の変動に応じて当該イベントを転送するためのイベントトピックを動的に変更し、この変更に伴う指示を制御メッセージにより他のノードへ通知する制御手段とを備えたことを特徴とする。
　本発明によるイベントトピック制御方法は、イベントルール毎に自ノードにかかるイベントの転送負荷の変動を監視し、転送負荷の変動に応じて当該イベントを転送するためのイベントトピックを動的に変更し、変更に伴う指示を制御メッセージにより他のノードへ通知することを特徴とする。
　本発明によるパブリッシャ（Ｐｕｂｌｉｓｈｅｒ）ノードは、複数のブローカノードを有する分散型イベント配信システムにおけるパブリッシャノードであって、アドバタイズ（Ａｄｖｅｒｔｉｓｅ）メッセージを送信するアドバタイズ送信手段と、パブリッシュ（Ｐｕｂｌｉｓｈ）メッセージを送信するパブリッシュ送信手段と、ブローカノードからイベントトピックの変更を指示する制御メッセージを受信すると、前記制御メッセージで指示された新規イベントトピックまたはマージ先イベントトピックを記載したアドバタイズ（Ａｄｖｅｒｔｉｓｅ）メッセージを前記制御メッセージで指示されたランデブーノードを最終宛先として送信し、前記制御メッセージで前記新規イベントトピックまたは前記マージ先イベントトピックをイベントの転送に用いるよう指示された特定のイベントトピックを前記新規イベントトピックまたは前記マージ先イベントトピックに書き換えたパブリッシュメッセージを送信するように制御する制御手段とを備えたことを特徴とする。
　本発明によるサブスクライバ（Ｓｕｂｓｃｒｉｂｅｒ）ノードは、複数のブローカノードを有する分散型イベント配信システムにおけるサブスクライバノードであって、サブスクライブ（Ｓｕｂｓｃｒｉｂｅ）メッセージを送信するサブスクライブ送信手段と、パブリッシュ（Ｐｕｂｌｉｓｈ）メッセージを受信するパブリッシュ受信手段と、ブローカノードからイベントトピックの変更を指示する制御メッセージを受信すると、前記制御メッセージで指示された新規イベントトピックまたはマージ先イベントトピックを記載したＳｕｂｓｃｒｉｂｅメッセージを前記制御メッセージで指示されたランデブーノードを最終宛先として送信するように指示する制御手段とを備えたことを特徴とする。
　本発明による分散型イベント配信システムは、アドバタイズ（Ａｄｖｅｒｔｉｓｅ）メッセージおよびパブリッシュ（Ｐｕｂｌｉｓｈ）メッセージを送信するパブリッシャ（Ｐｕｂｌｉｓｈｅｒ）ノードと、サブスクライブ（Ｓｕｂｓｃｒｉｂｅ）メッセージを送信し、前記パブリッシュメッセージを受信するサブスクライバノードと、パブリッシャノードからサブスクライバノードへのイベントの転送処理を行う複数のブローカノードとを備え、各ブローカノードは、イベントルール毎に自ノードにかかるイベントの転送負荷の変動を監視する監視手段と、前記転送負荷の変動に応じて当該イベントを転送するためのイベントトピックを動的に変更し、この変更に伴う指示を制御メッセージにより他のノードへ通知する制御手段とを有すること特徴とする。
　本発明によれば、分散型イベント配信システムにおいてイベント転送負荷の変動に柔軟に対応することができる。
イベント配信システムを一般的に説明するためのネットワーク構成例を示す図である。 Ａｄｖｅｒｔｉｓｅメッセージの送信を説明するためのネットワーク構成図である。 Ｓｕｂｓｃｒｉｂｅメッセージの送信を説明するためのネットワーク構成図である。 Ｐｕｂｌｉｓｈメッセージの転送を説明するためのネットワーク構成図である。 本発明の第１実施形態によるイベントＴｏｐｉｃ制御装置を含むブローカノードの機能的構成を示すブロック図である。 （Ａ）はＳｕｂｓｃｒｉｐｔｉｏｎテーブルの一例を示す図、（Ｂ）はＡｄｖｅｒｔｉｓｅｍｅｎｔテーブルの一例を示す図である。 転送負荷変動通知ポリシ管理テーブルに設定されている通知ポリシの一例を示す図である。 イベントＴｏｐｉｃ制御ポリシ管理テーブルに設定されている制御ポリシの一例を示す図である。 本実施形態におけるＰｕｂｌｉｓｈｅｒの機能的構成を概略的に示すブロック図である。 本実施形態におけるＳｕｂｓｃｒｉｂｅｒの機能的構成を概略的に示すブロック図である。 本実施形態による分散型イベント配信システムにおける新規イベントＴｏｐｉｃの作成手順を説明するためのネットワーク図である。 本実施形態による分散型イベント配信システムにおけるイベントＴｏｐｉｃ制御メッセージの送信手順を説明するためのネットワーク図である。 本実施形態による分散型イベント配信システムにおけるイベント配信パスの構築手順を説明するためのネットワーク図である。 本実施形態による分散型イベント配信システムにおけるイベント転送手順を説明するためのネットワーク図である。 本実施形態による分散型イベント配信システムにおけるイベントＴｏｐｉｃの削除手順を説明するためのネットワーク図である。 イベントＴｏｐｉｃ「関東の天気」のイベント配信パスを示すネットワーク図である。 本発明の第１実施形態におけるイベントＴｏｐｉｃ「横浜の天気」のイベント配信パスを示すネットワーク図である。 本発明の第２実施形態におけるイベントＴｏｐｉｃ「横浜の天気」のイベント配信パスを示すネットワーク図である。 本発明の第２実施形態によるイベントＴｏｐｉｃ制御装置を含むブローカノードの機能的構成を示すブロック図である。 イベントＴｏｐｉｃ制御ポリシ管理テーブルに設定されている制御ポリシの一例を示す図である。
１．第１実施形態
　図１に示すようなネットワークにおいて、本実施形態によるブローカノードＥＢには、後述するイベント監視部とイベントＴｏｐｉｃ制御部とが設けられている。なお、既に述べたように、イベントＴｏｐｉｃは、当該イベントＴｏｐｉｃを用いて発信される情報のトピックを表す。ＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒが同一のイベントＴｏｐｉｃを用いることで同一トピックのイベントの発信、受信を行うことが可能になる。イベントＴｏｐｉｃは他のイベントＴｏｐｉｃとの階層関係を持っていてもよい。
　イベント監視部は、特定のルール(以下、イベントルール)に合致するイベントを転送する際、自ノードにかかる負荷を測定し、当該イベントルールについて転送負荷の変動が特定のパターン（以下、転送負荷変動パターン）にマッチする場合に、当該イベントルールと転送負荷変動パターンとをイベントＴｏｐｉｃ制御部へ通知する。イベント監視部は、特定のポリシ（転送負荷変動推定ポリシ）に基づいて特定のイベントルールに合致するイベントの転送負荷が特定の転送負荷変動パターンにマッチすることを推定し、当該イベントルールと転送負荷変動パターンをイベントＴｏｐｉｃ制御部へ通知してもよい。
　イベントＴｏｐｉｃ制御部はイベント監視部からの通知を受け、イベントＴｏｐｉｃの新規作成または削除を行うと共に、イベントＴｏｐｉｃ制御メッセージを送信することで当該イベントＴｏｐｉｃに関係するブローカノードおよびＰｕｂｌｉｓｈｅｒ、ＳｕｂｓｃｒｉｂｅｒへイベントＴｏｐｉｃの新規作成または削除を通知する。また、他のブローカノードからイベントＴｏｐｉｃ制御メッセージを受信した場合には、当該メッセージを他のブローカノードまたはＰｕｂｌｉｓｈｅｒ、Ｓｕｂｓｃｒｉｂｅｒへ転送する。
　このように、本実施形態によるブローカノードＥＢは、イベント転送の負荷の変動に応じてイベントトピックを動的に変更し、この変更に伴う指示を制御メッセージにより他のノードへ通知するので、イベント転送の負荷の変動に柔軟に対応できる。以下、ブローカノードの構成および動作をより詳細に説明する。
１．１）ブローカノードの構成
　図５は本発明の第１実施形態によるイベントＴｏｐｉｃ制御装置を含むブローカノードの機能的構成を示すブロック図、図６（Ａ）はＳｕｂｓｃｒｉｐｔｉｏｎテーブルの一例を示す図、図６（Ｂ）はＡｄｖｅｒｔｉｓｅｍｅｎｔテーブルの一例を示す図である。
　図５において、ブローカノードＥＢは、機能的に、Ｓｕｂｓｃｒｉｐｔｉｏｎテーブル１０１、Ａｄｖｅｒｔｉｓｅｍｅｎｔテーブル１０２、ルーティングテーブル管理部１０３およびイベント転送部１０４を有し、さらに、イベント監視部１０５および転送負荷変動通知ポリシ管理テーブル１０６と、イベントＴｏｐｉｃ制御部１０７およびイベントＴｏｐｉｃ制御ポリシ管理テーブル１０８とを有する。Ｓｕｂｓｃｒｉｐｔｉｏｎテーブル１０１およびＡｄｖｅｒｔｉｓｅｍｅｎｔテーブル１０２には、図６に例示するように、エントリＩＤ毎に、イベントＴｏｐｉｃ、Ｆｉｌｔｅｒｉｎｇルールおよびネクストホップに関する情報がそれぞれ登録される。
　ルーティングテーブル管理部１０３は、隣接するブローカノードＥＢ、ＳｕｂｓｃｒｉｂｅｒまたはＰｕｂｌｉｓｈｅｒから受信したＡｄｖｅｒｔｉｓｅｍｅｎｔメッセージおよびＳｕｂｓｃｒｉｂｅメッセージを転送するとともに、受信したメッセージに含まれる情報を元にしてＳｕｂｓｃｒｉｐｔｉｏｎテーブル１０１またはＡｄｖｅｒｔｉｓｅｍｅｎｔテーブル１０２を更新する。
　Ａｄｖｅｒｔｉｓｅメッセージを受信した場合、ルーティングテーブル管理部１０３は、Ａｄｖｅｒｔｉｓｅメッセージに含まれるイベントＴｏｐｉｃ、Ｆｉｌｔｅｒｉｎｇルールと共に、当該メッセージを自ノードへ転送した隣接ノードをＮｅｘｔホップとしてＡｄｖｅｒｔｉｓｅｍｅｎｔテーブル１０２に登録する。
　Ｓｕｂｓｃｒｉｂｅメッセージを受信した場合、ルーティングテーブル管理部１０３は、Ｓｕｂｓｃｒｉｂｅメッセージに含まれるイベントＴｏｐｉｃ、Ｆｉｌｔｅｒｉｎｇルールと共に、当該メッセージを自ノードへ転送した隣接ノードをＮｅｘｔホップとしてＳｕｂｓｃｒｉｐｔｉｏｎテーブル１０１に登録する。
　なお、すでにＳｕｂｓｃｒｉｐｔｉｏｎテーブル１０１に登録されているエントリのイベントＴｏｐｉｃおよびＮｅｘｔホップと、受信したＳｕｂｓｃｒｉｂｅメッセージのそれらとが同一の場合、当該エントリのＦｉｌｔｅｒｉｎｇルールと受信したＳｕｂｓｃｒｉｂｅメッセージに含まれるＦｉｌｔｅｒｉｎｇルールとをマージすることができる。例えば、Ｓｕｂｓｃｒｉｐｔｉｏｎテーブル１０１に既にイベントＴｏｐｉｃ「関東の天気」、Ｆｉｌｔｅｒｉｎｇルール「/神奈川/横浜」を持つエントリが登録されているとする。そして、イベントＴｏｐｉｃ「関東の天気」、Ｆｉｌｔｅｒｉｎｇルール「/神奈川/川崎」を持つＳｕｂｓｃｒｉｂｅメッセージを受信した場合、Ｆｉｌｔｅｒｉｎｇルールを「/神奈川/」にマージしたエントリを作成し、既存エントリを削除することができる。これによりＳｕｂｓｃｒｉｐｔｉｏｎテーブル１０１のサイズ増加が抑制され、テーブル検索にかかる時間を節約できる。
　受信したＳｕｂｓｃｒｉｂｅメッセージは自ノードからランデブーノードへの経路上にある隣接ブローカノードへ転送する。なお、ＳｕｂｓｃｒｉｂｅメッセージのイベントＴｏｐｉｃが既にＳｕｂｓｃｒｉｐｔｉｏｎテーブルに登録されているエントリと同一であり、かつ当該エントリのＦｉｌｔｅｒｉｎｇルールＦ＿ｓｘとＳｕｂｓｃｒｉｂｅメッセージのＦｉｌｔｅｒｉｎｇルールＦ＿ｓｙとの関係が「Ｆ＿ｓｙがＦ＿ｓｘに含まれる（Ｆ＿ｓｙ⊆Ｆ＿ｓｘ）」場合、Ｓｕｂｓｃｒｉｂｅメッセージの転送を行わない。例えばＦ＿ｓｙが/横浜/、Ｆ＿ｓｘが/神奈川/であれば、Ｓｕｂｓｃｒｉｂｅメッセージの転送を行わない。
　一度ランデブーノードへ到達した後のＳｕｂｓｃｒｉｂｅメッセージを受信した場合には、Ａｄｖｅｒｔｉｓｅｍｅｎｔテーブル１０２を参照し、同一イベントＴｏｐｉｃのエントリに登録されたＮｅｘｔホップへ転送することができる。ただし、ＳｕｂｓｃｒｉｂｅメッセージのＦｉｌｔｅｒｉｎｇルールＦ＿ｓｙと当該エントリのＦｉｌｔｅｒｉｎｇルールＦ＿ｓｚとの重なりが空集合の場合（Ｆ＿ｓｙ∩Ｆ＿ｓｚ＝φ）、Ｓｕｂｓｃｒｉｂｅメッセージの転送を行わない。
　イベント転送部１０４は、隣接ブローカノードＥＢまたはＰｕｂｌｉｓｈｅｒからＰｕｂｌｉｓｈメッセージを受信すると、Ｓｕｂｓｃｒｉｐｔｉｏｎテーブル１０１を参照し、受信したＰｕｂｌｉｓｈメッセージとイベントＴｏｐｉｃが同じでイベント内容がＦｉｌｔｅｒｉｎｇルールに合致するエントリを検索する。そして、検索されたエントリに登録されているＮｅｘｔホップへ当該Ｐｕｂｌｉｓｈメッセージを転送する。
　次に、本実施形態によるイベントＴｏｐｉｃ制御装置におけるイベント監視部１０５および負荷変動通知ポリシ管理テーブル１０６と、イベントＴｏｐｉｃ制御部１０７およびイベントＴｏｐｉｃ制御ポリシ管理テーブル１０８と、について詳細に説明する。
１．２）ブローカノードのイベント監視部
　イベント監視部１０５は、特定のルール(以下、イベントルール)に合致するイベントを転送する際、自ノードにかかる負荷を測定する。そして、当該イベントルールに関する転送負荷の変動が転送負荷変動通知ポリシ管理テーブル１０６に登録されている特定のパターン（以下、転送負荷変動パターン）とマッチするかどうかを判定する。この転送負荷変動パターンにマッチする場合には、当該イベントルールと当該転送負荷変動パターンとをイベントＴｏｐｉｃ制御部１０７へ通知する。
　また、転送負荷変動通知ポリシ管理テーブル１０６に転送負荷変動推定ポリシを登録しておき、イベント監視部１０５は特定イベントルールに関する転送負荷の変動が転送負荷変動推定ポリシに基づいて特定の転送負荷変動パターンにマッチすることを推定してもよい。この場合には、当該イベントルールと推定された転送負荷変動パターンとをイベントＴｏｐｉｃ制御部１０７へ通知する。
＜イベントルール＞
　まずイベントルールについて説明する。イベントルールの例としては以下のようなものが考えられる。
（１）イベントＴｏｐｉｃ
　イベントＴｏｐｉｃそのもの。必ず設定される。
（２）Ｆｉｌｔｅｒｉｎｇルール：
　（ａ）ＳｕｂｓｃｒｉｐｔｉｏｎテーブルやＡｄｖｅｒｔｉｓｅｍｅｎｔテーブルに登録されているＦｉｌｔｅｒｉｎｇルール；Ｐｕｂｌｉｓｈメッセージにより通知されるイベントが満たすべき任意の条件；イベントに含まれるキーワードや発信された時間帯など。また、イベントの内容がＸＭＬで記述される場合はＸｐａｔｈを用いて記述されたルールが考えられる；
　（ｂ）事前に設定したＦｉｌｔｅｒｉｎｇルール：上記（２．ａ）と同じ。
（３）Ｐｕｂｌｉｓｈメッセージの属性に基づくルール
　イベントの内容そのものではなく、イベントを伝送するＰｕｂｌｉｓｈメッセージの属性情報、たとえばＨＴＴＰやＳＩＰの他ＴＣＰ、ＵＤＰ、ＩＰのヘッダー情報に関するルール：
　（ａ）Ｐｕｂｌｉｓｈメッセージのサイズ；
　（ｂ）Ｐｕｂｌｉｓｈメッセージの送信元Ｓｕｂｓｃｒｉｂｅｒ；
　（ｃ）Ｐｕｂｌｉｓｈメッセージに添付されたファイルの種類（静止画、動画、音声）。
　この他にも様々なルールが考えられる。イベントルールは、上記（１）のイベントＴｏｐｉｃとその他のルールとの組み合わせによって表現されうる。すなわち、各イベントルールには必ずイベントＴｏｐｉｃが記載される。単一のイベントルールに複数のイベントＴｏｐｉｃが指定されていてもよい。以下、イベントルールに指定されたイベントＴｏｐｉｃを「ターゲットイベントＴｏｐｉｃ」と呼ぶ。
＜転送負荷変動パターン＞
　イベント監視部１０５が測定する負荷としては以下のようなパラメータが挙げられる。
・頻度：上記イベントルールに合致するイベントを単位時間当たりに転送する回数。
・ネットワーク帯域：上記イベントルールに合致するイベントを転送するために占有されるネットワーク帯域。
・ＣＰＵ時間：上記イベントルールに合致するイベントの転送に必要なＣＰＵ時間。例えば当該イベントに適用するＦｉｌｔｅｒｉｎｇルールが複雑なほど必要なＣＰＵ時間は増加する。
　この他にも測定する負荷として様々なパラメータが考えられる。これらパラメータは単独で用いられてもよいし、複数のパラメータを組み合わせて測定してもよい。
　転送負荷変動パターンとしては、つぎのようなものが挙げられる。
（１）転送負荷が事前に設定した閾値を上回る、または下回る。
（２）一定時間内の転送負荷の最小値と最大値の差、すなわち転送負荷の変動幅が事前に設定した閾値を上回る、または下回る。
　この他にも転送負荷変動パターンとして様々なパターンが考えられる。これらのパターンは単独で用いることもできるし、複数のパターンを組み合わせて一つの転送負荷変動パターンとして用いることもできる。
　転送負荷変動通知ポリシ管理テーブル１０６には、各イベントルールについてどのような転送負荷変動パターンを検出した場合にイベントＴｏｐｉｃ制御部１０７へ通知するかが通知ポリシとして登録されている。
　図７は転送負荷変動通知ポリシ管理テーブルに設定されている通知ポリシの一例を示す図である。例えばＩＤ＝１のエントリでは、イベントＴｏｐｉｃ「関東の天気」、Ｆｉｌｔｅｒｉｎｇルール「/神奈川/横浜」にマッチするイベントの転送負荷がＡ、Ｂ、（ＣΛＥ）、（ＤΛＦ）のいずれかのパターンにマッチした場合に、イベントＴｏｐｉｃ制御部１０７への通知が発生する。また、ＩＤ＝４やＩＤ＝５のエントリでは、イベントルールとしてイベントＴｏｐｉｃのみが記載されている。
　一例として（ＣΛＥ）は、ＣとＥとの論理積であり、次のようなパターンを意味する。すなわち、イベント監視部１０５は、イベント転送に利用するネットワーク帯域およびＣＰＵ使用率を測定し、転送負荷変動通知ポリシ管理テーブル１０６を参照することで、当該イベントルールでのネットワーク帯域が１Ｍｂｐｓを超えているか（パターンＣ）、ＣＰＵ使用率が５０％を超えているか（パターンＥ）を判定する。パターンＣおよびＥの両方を満たしたとき（ＣΛＥ）に、イベント監視部１０５は、当該イベントルールと当該（ＣΛＥ）の転送負荷変動パターンとをイベントＴｏｐｉｃ制御部１０７へ通知する。
＜推定ポリシ＞
　推定ポリシは観測事象と推定事象で構成される。イベント監視部１０５は観測事象として記述された事象が観測された場合、推定事象として記述された事象が起きたこと、または将来起きることを推定する。
　観測事象としては以下の事象が挙げられる。
・イベントルールに合致するイベントを転送
・イベントルールに合致するイベントの転送負荷が転送負荷変動パターンにマッチ
　この他にも観測事象として様々な事象が考えられる。これらの事象は単独で用いることもできるし、複数の事象を組み合わせて一つの観測事象として用いることもできる。
　推定事象は、特定のイベントルールについての転送負荷の変動である。
　観測事象と推定事象の組み合わせは様々な組み合わせを用いることができる。例えば、複数の観測事象から単一の推定事象を推定したり、単一の観測事象から複数の推定事象を推定したりしてもよい。また、複数の観測事象をＡＮＤやＯＲ等の論理記号で組み合わせた論理式から単一の推定事象を推定してもよい。たとえば、ＩＦ(観測事象Ａ　ＡＮＤ　観測事象Ｂ)、ＴＨＥＮ（推定事象Ｃ）；すなわち観測事象Ａおよび観測事象Ｂを観測したならば推定事象Ｃの発生を推定する。複数の観測事象の時系列的条件から推定事象を推定してもよい。たとえば、事象Ａを観測後１０分以内に事象Ｂを観測した場合には推定事象Ｃの１時間後の発生を推定する。
１．３）ブローカノードのイベントＴｏｐｉｃ制御部
　イベントＴｏｐｉｃ制御部１０７は、イベント監視部１０５からの負荷変動通知を受けると、後述するように、イベントＴｏｐｉｃ制御ポリシ管理テーブル１０８を参照してイベントＴｏｐｉｃの新規作成または削除を行うと共に、イベントＴｏｐｉｃ制御メッセージを送信する。イベントＴｏｐｉｃ制御メッセージにより、当該イベントＴｏｐｉｃに関係するブローカノードＥＢまたはＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒへイベントＴｏｐｉｃの新規作成または削除を通知する。
　また、他のブローカノードＥＢからイベントＴｏｐｉｃ制御メッセージを受信した場合には、当該メッセージを他のブローカノードＥＢまたはＰｕｂｌｉｓｈｅｒ、Ｓｕｂｓｃｒｉｂｅｒへ転送する。
　イベントＴｏｐｉｃ制御ポリシ管理テーブル１０８には、イベント監視部１０５からの通知内容とイベントＴｏｐｉｃ制御部１０７の動作内容とが記述された制御ポリシが設定されており、イベントＴｏｐｉｃ制御部１０７は、この制御ポリシに従ってイベントＴｏｐｉｃの作成・削除を行う。
＜制御ポリシ＞
　図８はイベントＴｏｐｉｃ制御ポリシ管理テーブルに設定されている制御ポリシの一例を示す図である。
　制御ポリシでは、以下２つの動作内容とイベント監視部１０５からの通知内容との関係が記述される。
（１）作成または削除するイベントＴｏｐｉｃ
（２）イベント監視部１０５から通知される転送負荷変動パターン。
　転送負荷変動パターンとして、転送負荷が閾値を上回った(または将来上回ると推定される)と通知された場合、または、転送負荷が閾値として設定された変動幅以上に増加した（または将来増加すると推定される）と通知された場合は、当該転送負荷変動パターンが測定または推定されたイベントルールに対応するイベントＴｏｐｉｃを新規に作成する。例えば、イベントＴｏｐｉｃ：「関東の天気」、Ｆｉｌｔｅｒｉｎｇルール：「神奈川/横浜/」のイベントルールにマッチするイベントについて転送負荷が閾値を上回ったと通知された場合は、当該イベントに対応するイベントＴｏｐｉｃ、「横浜の天気」を新規に作成する。
　また、転送負荷変動パターンとして転送負荷が閾値を下回った（または将来下回ると推定される）と通知された場合、または転送負荷が閾値として設定された変動幅以上に低下した(または将来低下すると推定される)と通知された場合は、当該転送負荷変動パターンが測定または推定されたイベントルールに対応するイベントＴｏｐｉｃを削除する。例えば、イベントＴｏｐｉｃ：「横浜の天気」のイベントルールにマッチするイベントについて転送負荷が閾値を下回ったと通知された場合は、イベントＴｏｐｉｃ「横浜の天気」を削除する。
＜イベントＴｏｐｉｃの作成または削除＞
　イベント監視部１０５からの通知内容が実際に測定したもの（または、現時点で起きている事象として推定したもの）であれば、イベントＴｏｐｉｃ制御部１０７は即時にイベントＴｏｐｉｃの作成または削除を行う。通知内容が将来起きると推定したものであれば、通知内容に記載されたタイミングでイベントＴｏｐｉｃの作成または削除を行う。例えば１０分後に推定事象Ａが起きると通知された場合は、１０分後にイベントＴｏｐｉｃの作成または削除を行う。
＜イベントＴｏｐｉｃ制御メッセージの作成・削除＞
　新規にイベントＴｏｐｉｃを作成する場合、新規イベントＴｏｐｉｃを担当するランデブーノード（新規ランデブーノード）を他のブローカノードＥＢから選択する。そして、イベントＴｏｐｉｃ制御メッセージに、作成した新規イベントＴｏｐｉｃと新規ランデブーノード、さらにイベント監視部１０５から通知されたイベントルール（ターゲットイベントＴｏｐｉｃが含まれる）を記載して送信し、新規イベントＴｏｐｉｃの作成を他のノードへ通知する。
　イベントＴｏｐｉｃの削除を行う場合、削除対象のイベントＴｏｐｉｃにマッチするイベントＴｏｐｉｃ（以下、マージ先イベントＴｏｐｉｃ）を既存のイベントＴｏｐｉｃの中から決める。例えば「横浜の天気」というイベントＴｏｐｉｃを削除する場合、マージ先イベントＴｏｐｉｃとして「関東の天気」を既存のイベントＴｏｐｉｃの中から選択する。したがって、イベントＴｏｐｉｃ「横浜の天気」を利用して転送していたイベントは削除された後、「関東の天気」を利用して転送される。続いて、イベントＴｏｐｉｃ制御部１０７は、マージ先イベントＴｏｐｉｃと、イベント監視部１０５から通知されたイベントルール（ターゲットイベントＴｏｐｉｃが含まれる場合はターゲットイベントＴｏｐｉｃが削除対象イベントＴｏｐｉｃとなる。）とを記載したイベントＴｏｐｉｃ制御メッセージを送信し、既存イベントＴｏｐｉｃの削除を他のノードへ通知する。
　なお、イベントＴｏｐｉｃの作成と削除は同時に行ってもよい。たとえば、一つのイベントＴｏｐｉｃ制御メッセージによって、イベントＴｏｐｉｃの削除およびイベントＴｏｐｉｃの作成の両方を通知し、削除対象イベントＴｏｐｉｃのマージ先イベントＴｏｐｉｃとして新規に作成したイベントＴｏｐｉｃを通知すれば、イベントＴｏｐｉｃの移動を実現することができる。
　また、複数のイベントＴｏｐｉｃについて作成と削除を同時に通知してもよく、既存のイベントＴｏｐｉｃを削除し、複数のイベントＴｏｐｉｃを新規作成するとともに、新規に作成した複数のイベントＴｏｐｉｃをマージ先イベントＴｏｐｉｃとして通知すれば、既存のイベントＴｏｐｉｃの複数のイベントＴｏｐｉｃへの分割を実現することもできる。
　図８に例示するように、イベントルールおよび転送負荷変動パターン毎にイベントＴｏｐｉｃ制御部１０７の動作内容が記述されている。たとえばＩＤ＝１のエントリでは、図７に示したイベントルールＩＤ＝１－３に合致するイベントの転送負荷の変動パターンが転送負荷変動パターンＡにマッチした場合に、イベントＴｏｐｉｃを新規作成する、というポリシが記載されている。また、ＩＤ＝２、ＩＤ＝７のエントリのようにワイルドカード（＊印）などを用い、任意のイベントルールについて特定の転送負荷変動パターンに転送負荷の変動がマッチした場合の動作内容を記載することもできる。
＜イベントＴｏｐｉｃ制御メッセージの転送＞
　イベントＴｏｐｉｃ制御部１０７は、Ｓｕｂｓｃｒｉｐｔｉｏｎテーブル１０１およびＡｄｖｅｒｔｉｓｅｍｅｎｔテーブル１０２を参照してイベントＴｏｐｉｃ制御メッセージを転送する。新規イベントＴｏｐｉｃ作成時であれば、イベントＴｏｐｉｃ制御メッセージに記載されたターゲットイベントＴｏｐｉｃと合致するエントリをＳｕｂｓｃｒｉｐｔｉｏｎテーブル１０１および／またはＡｄｖｅｒｔｉｓｅｍｅｎｔテーブル１０２から検索し、当該エントリに記載されたＮｅｘｔホップへとイベントＴｏｐｉｃ制御メッセージを転送する。
　検索したエントリに記載されたＦｉｌｔｅｒｉｎｇルール（Ｆ＿ｐ）とイベントＴｏｐｉｃ制御メッセージに記載されたルール（Ｆ＿ｑ）とに重複範囲がない場合、すなわちＦ＿ｐ∩Ｆ＿ｑ＝φ（空集合）の場合は、当該エントリに記載されたＮｅｘｔホップへとイベントＴｏｐｉｃ制御メッセージを転送しなくてもよい。その理由はＮｅｘｔホップが新規イベントＴｏｐｉｃを利用したイベントの転送（より詳しく言えばイベントＴｏｐｉｃ制御メッセージに記載されたルールに合致するイベントの転送）を行うことがないためである。こうすることで、イベントＴｏｐｉｃ制御メッセージの転送回数を抑制するこができる。
　既存のイベントＴｏｐｉｃを削除する場合であれば、イベントＴｏｐｉｃ制御メッセージに記載されたターゲットイベントＴｏｐｉｃと合致するエントリをＳｕｂｓｃｒｉｐｔｉｏｎテーブル１０１および／またはＡｄｖｅｒｔｉｓｅｍｅｎｔテーブル１０２から検索し、当該エントリに記載されたＮｅｘｔホップへとイベントＴｏｐｉｃ制御メッセージを転送する。イベントＴｏｐｉｃ制御メッセージの転送を契機としてイベントＴｏｐｉｃ制御メッセージの転送直後または一定時間経過後に削除対象イベントＴｏｐｉｃと合致するエントリをＳｕｂｓｃｒｉｐｔｉｏｎテーブル１０１、Ａｄｖｅｒｔｉｓｅｍｅｎｔテーブル１０２から削除してもよい。こうすることで、不要なエントリの削除を迅速に行える他、不要エントリ削除のためにＰｕｂｌｉｓｈｅｒおよびＳｕｂｓｃｒｉｂｅｒがＡｄｖｅｒｔｉｓｅメッセージおよびＳｕｂｓｃｒｉｂｅメッセージ（すなわち削除対象イベントＴｏｐｉｃのイベントの送受信を今後行わない旨記載されたＡｄｖｅｒｔｉｓｅメッセージおよびＳｕｂｓｃｒｉｂｅメッセージ）を送信する必要がなくなるため、当該メッセージの転送により発生するトラヒックを抑制することができる。なお、イベントＴｏｐｉｃ制御メッセージの転送を契機に削除しない場合は、削除対象イベントＴｏｐｉｃのイベントの送受信を今後行わない旨記載されたＡｄｖｅｒｔｉｓｅメッセージおよびＳｕｂｓｃｒｉｂｅメッセージを転送したタイミングで削除すればよい。
　なお、上述したルーティングテーブル管理部１０３、イベント転送部１０４、イベント監視部１０５およびイベントＴｏｐｉｃ制御部１０７の機能は、それぞれプログラムをＣＰＵ等のプログラム制御プロセッサ上で実行することにより実現されうる。
２．Ｐｕｂｌｉｓｈｅｒの構成
　図９は本実施形態におけるＰｕｂｌｉｓｈｅｒの機能的構成を概略的に示すブロック図である。ＰｕｂｌｉｓｈｅｒＰＵＢは、Ａｄｖｅｒｔｉｓｅ送信部２０１、イベント発生部２０２、Ｐｕｂｌｉｓｈ送信部２０３、および、イベントＴｏｐｉｃ制御メッセージ受信部２０４からなる。
　Ａｄｖｅｒｔｉｓｅ送信部２０１は、イベントＴｏｐｉｃをＡｄｖｅｒｔｉｓｅメッセージに記載し、当該イベントＴｏｐｉｃを担当するランデブーノードを最終宛先として自ノードと直接接続するブローカノードへ送信する。
　イベント発生部２０２は何らかの状態の変化、すなわちイベントを検出しＰｕｂｌｉｓｈ送信部２０３に通知する。イベント発生部２０２の例としては天候の変化を検出するセンサデバイスや、ユーザのプレゼンスを検出するアプリケーションなどが挙げられる。
　Ｐｕｂｌｉｓｈ送信部２０３はイベント発生部２０２から通知されたイベントとともにイベントに対応するイベントＴｏｐｉｃをＰｕｂｌｉｓｈメッセージに記載し、自ノードと直接接続するブローカノードへ送信する。イベントＴｏｐｉｃは事前に単一の値を設定しておいてもよいし、イベント内容に基づいてイベントＴｏｐｉｃを決めるためのルールを設定しておいてもよい。
　イベントＴｏｐｉｃ制御メッセージ受信部２０４は、ブローカノードからのイベントＴｏｐｉｃ制御メッセージの受信、Ｐｕｂｌｉｓｈ送信部２０３が送信したＰｕｂｌｉｓｈメッセージのイベントＴｏｐｉｃの書き換えおよび転送、Ａｄｖｅｒｔｉｓｅ送信部２０１へのＡｄｖｅｒｔｉｓｅメッセージ送信の指示などを実行する。
＜イベントＴｏｐｉｃの書き換え＞
　イベントＴｏｐｉｃ制御メッセージを受信した場合、新規イベントＴｏｐｉｃの作成の通知であれば当該メッセージ受信以降、メッセージに記載されたイベントＴｏｐｉｃおよびルールに合致するイベントを含むＰｕｂｌｉｓｈメッセージをインターセプトし、当該イベントのイベントＴｏｐｉｃを新規イベントＴｏｐｉｃに書き換える。
　また、Ｐｕｂｌｉｓｈメッセージの最終宛先は新規イベントＴｏｐｉｃを担当するランデブーノードに書き換え、自ノードと直接接続するブローカノードへ転送する。また、Ａｄｖｅｒｔｉｓｅ送信部２０１に対して、新規イベントＴｏｐｉｃが記載されたＡｄｖｅｒｔｉｓｅメッセージを、新規イベントＴｏｐｉｃを担当するランデブーノードを最終宛先として送信するよう指示する。
　また、既存イベントＴｏｐｉｃの削除の通知であれば、以下のように処理する。削除対象イベントＴｏｐｉｃが過去にイベントＴｏｐｉｃ制御メッセージによって追加されたイベントＴｏｐｉｃの場合、すなわち削除対象イベントの新規作成を通知するイベントＴｏｐｉｃ制御メッセージを受信済みの場合は、削除対象イベントＴｏｐｉｃへのイベントＴｏｐｉｃの書き換えを中止する。
　また、受信したイベントＴｏｐｉｃ制御メッセージにマージ先のイベントＴｏｐｉｃが指定されている場合は、削除対象イベントＴｏｐｉｃへ書き換えられていたイベントをマージ先イベントＴｏｐｉｃに書き換えるようにする。なお、マージ先イベントＴｏｐｉｃが指定されていない場合、イベントはもともと自ノードに設定されていたイベントＴｏｐｉｃで送信される。削除対象イベントＴｏｐｉｃが過去にイベントＴｏｐｉｃ制御メッセージによって追加されたイベントＴｏｐｉｃでない場合（すなわち元々自ノードに設定されていたイベントＴｏｐｉｃの場合）は、削除対象イベントＴｏｐｉｃに合致するイベントをマージ先イベントＴｏｐｉｃに書き換えるようにする。
　なお、上述したＰｕｂｌｉｓｈｅｒの機能は、プログラムをＣＰＵ等のプログラム制御プロセッサ上で実行することにより実現されうる。
３．Ｓｕｂｓｃｒｉｂｅｒの構成
　図１０は本実施形態におけるＳｕｂｓｃｒｉｂｅｒの機能的構成を概略的に示すブロック図である。ＳｕｂｓｃｒｉｂｅｒＳＵＢはＳｕｂｓｃｒｉｂｅ送信部３０１、イベントＴｏｐｉｃ制御メッセージ受信部３０２およびＰｕｂｌｉｓｈ受信部３０３からなる。
　Ｓｕｂｓｃｒｉｂｅ送信部３０１はイベントＴｏｐｉｃをＳｕｂｓｃｒｉｂｅメッセージに記載し、当該イベントＴｏｐｉｃを担当するランデブーノードを最終宛先として自ノードと直接接続するブローカノードへ送信する。
　イベントＴｏｐｉｃ制御メッセージ受信部３０２はブローカノードからのイベントＴｏｐｉｃ制御メッセージの受信、Ｐｕｂｌｉｓｈ受信部３０３が受信するＰｕｂｌｉｓｈメッセージのイベントＴｏｐｉｃの書き換えおよび転送、Ｓｕｂｓｃｒｉｂｅ送信部３０１へのＳｕｂｓｃｒｉｂｅメッセージ送信の指示を行う。
　Ｐｕｂｌｉｓｈ受信部３０３はＰｕｂｌｉｓｈメッセージを受信し、受信メッセージからイベントを取り出してアプリケーション（図示せず）に渡す。
＜イベントＴｏｐｉｃの書き換え＞
　イベントＴｏｐｉｃ制御メッセージ受信部３０２は、受信したイベントＴｏｐｉｃ制御メッセージが新規イベントＴｏｐｉｃの作成の通知であれば、当該メッセージ受信以降、メッセージに記載されたイベントルールに合致するイベントを含むＰｕｂｌｉｓｈメッセージをインターセプトし、当該イベントのイベントＴｏｐｉｃを新規イベントＴｏｐｉｃに書き換える。また、Ｓｕｂｓｃｒｉｂｅ送信部３０１に対して、新規イベントＴｏｐｉｃが記載されたＳｕｂｓｃｒｉｂｅメッセージを、新規イベントＴｏｐｉｃを担当するランデブーノードを最終宛先として送信するよう指示する。
　また、既存イベントＴｏｐｉｃの削除の通知であれば、以下のように処理する。削除対象イベントＴｏｐｉｃが過去にイベントＴｏｐｉｃ制御メッセージによって追加されたイベントＴｏｐｉｃの場合、すなわち削除対象イベントの新規作成を通知するイベントＴｏｐｉｃ制御メッセージを受信済みの場合は、削除対象イベントＴｏｐｉｃへのイベントＴｏｐｉｃの書き換えを中止する。
　また、受信したイベントＴｏｐｉｃ制御メッセージにマージ先のイベントＴｏｐｉｃが指定されている場合は、削除対象イベントＴｏｐｉｃへ書き換えられていたイベントをマージ先イベントＴｏｐｉｃに書き換えるようにする。なお、マージ先イベントＴｏｐｉｃが指定されていない場合、イベントはもともと自ノードに設定されていたイベントＴｏｐｉｃで送信される。削除対象イベントＴｏｐｉｃが過去にイベントＴｏｐｉｃ制御メッセージによって追加されたイベントＴｏｐｉｃでない場合（すなわち元々自ノードに設定されていたイベントＴｏｐｉｃの場合）は、削除対象イベントＴｏｐｉｃに合致するイベントをマージ先イベントＴｏｐｉｃに書き換えるようにする。
　なお、上述したＳｕｂｓｃｒｉｂｅｒの機能は、プログラムをＣＰＵ等のプログラム制御プロセッサ上で実行することにより実現されうる。
４．イベントＴｏｐｉｃ制御動作
　次に、本実施形態による分散型イベント配信システムの動作について説明する。まず新規にイベントＴｏｐｉｃを作成する際の動作について図１１～図１４に示した例を参照しながら説明する。
４．１）新規イベントＴｏｐｉｃの作成
＜転送負荷変動パターンの検出＞
　上述したように、ブローカノードＥＢには転送負荷変動通知ポリシ管理テーブル１０６が設けられ、予めイベントルールと転送負荷変動パターン（すなわち通知ポリシ）が設定されている。イベント監視部１０５は、転送負荷変動通知ポリシ管理テーブル１０６を参照することで特定のイベントルールのイベントの転送負荷が転送負荷変動パターンにマッチしたことを検出すると（または、マッチすると推定すると）、当該イベントルールと転送負荷変動パターンとをイベントＴｏｐｉｃ制御部１０７へ通知する。
＜ランデブーノードの選択＞
　イベントＴｏｐｉｃ制御部１０７は、イベント監視部１０５から負荷変動通知を受けると、通知されたイベントルールに対応するイベントＴｏｐｉｃを新規に作成するとともにブローカノードの中からランデブーノードを選択する。以下、図１１に示した分散型イベント配信システムを例にとって説明する。
　図１１は本実施形態による分散型イベント配信システムにおける新規イベントＴｏｐｉｃの作成手順を説明するためのネットワーク図である。ここでは、イベントＴｏｐｉｃ「関東の天気」を担当するランデブーノードとしてブローカノードＥＢＦが選択されているものとする。さらに、ブローカノードＥＢＦの転送負荷変動通知ポリシ管理テーブル１０６には通知ポリシとして図７に示す内容が設定されているものとする。
　例えばブローカノードＥＢＦは、イベントＴｏｐｉｃ「関東の天気」、Ｆｉｌｔｅｒｉｎｇルール「/神奈川/横浜」にマッチするイベントの転送頻度が６０００イベント/secであると測定すると、図７におけるＩＤ＝１のエントリにヒットし、ＩＤ＝１に記載された内容がイベントＴｏｐｉｃ制御部１０７に通知される。イベントＴｏｐｉｃ制御部１０７は、通知された内容を用いてイベントＴｏｐｉｃ制御ポリシ管理テーブル１０８を検索する。図８に示す制御ポリシがイベントＴｏｐｉｃ制御ポリシ管理テーブル１０８に登録されている場合、今回の例における通知内容はＩＤ＝１のエントリとマッチするので、イベントＴｏｐｉｃ制御部１０７はイベントＴｏｐｉｃを新規に作成し、ランデブーノードを選択する。図１１に示した例では、新規イベントＴｏｐｉｃとして「横浜の天気」が作成され、当該イベントＴｏｐｉｃを担当するランデブーノードとしてブローカノードＥＢ３が選択されている。
＜イベントＴｏｐｉｃ制御メッセージの送信＞
　次に、ブローカノードＥＢＦのイベントＴｏｐｉｃ制御部１０７はイベントＴｏｐｉｃ制御メッセージを作成し、ＡｄｖｅｒｔｉｓｅｍｅｎｔテーブルおよびＳｕｂｓｃｒｉｐｔｉｏｎテーブルを参照してイベント監視部１０５から通知されたイベントルールに合致するＮｅｘｔホップへ当該イベントＴｏｐｉｃ制御メッセージを送信する。
　図１２は、本実施形態による分散型イベント配信システムにおけるイベントＴｏｐｉｃ制御メッセージの送信手順を説明するためのネットワーク図である。ただし、図１２は、図１１に示した分散型イベント配信システムの動作が完了した後の動作を示している。
　まず、ブローカノードＥＢＦは、図１２に「ＥＴＣ」として示されるイベントＴｏｐｉｃ制御メッセージを作成し、自身のＡｄｖｅｒｔｉｓｅｍｅｎｔテーブルＡＴＦおよびＳｕｂｓｃｒｉｐｔｉｏｎテーブルＳＴＦを参照して当該イベントＴｏｐｉｃ制御メッセージＥＴＣを送信する。ここでは、ＡｄｖｅｒｔｉｓｅｍｅｎｔテーブルＡＴＦのＩＤ＝１のエントリをヒットするので、そのＮｅｘｔホップのブローカノードＥＢＡへ転送される。ＩＤ＝２のエントリについては、イベントＴｏｐｉｃ制御メッセージに記載されたＦｉｌｔｅｒｉｎｇルールと当該エントリに登録されているＦｉｌｔｅｒｉｎｇルールとの間に重複範囲がないため、ブローカノードＥＢＢへの転送は行われない。ＳｕｂｓｃｒｉｐｔｉｏｎテーブルＳＴＦについては、ブローカノードＥＢＣへイベントＴｏｐｉｃ制御メッセージＥＴＣが転送される。
　ブローカノードＥＢＡおよびＥＢＣは、受信したイベントＴｏｐｉｃ制御メッセージＥＴＣをＡｄｖｅｒｔｉｓｅｍｅｎｔテーブルおよびＳｕｂｓｃｒｉｐｔｉｏｎテーブルを参照して転送する。なお、ＮｅｘｔホップがイベントＴｏｐｉｃ制御メッセージの直前の転送元と同じ場合は転送を行わない（たとえばブローカノードＥＢＣやＥＢＡからＥＢＦへのイベントＴｏｐｉｃ制御メッセージの転送は行わない）。以下同様にして、各ブローカノードのＡｄｖｅｒｔｉｓｅｍｅｎｔテーブルおよびＳｕｂｓｃｒｉｐｔｉｏｎテーブルを参照したイベントＴｏｐｉｃ制御メッセージＥＴＣの転送が繰り返され、最終的にイベントＴｏｐｉｃ制御メッセージＥＴＣは、新規に作成したイベントＴｏｐｉｃを利用したイベントの送信および受信を行う全てのＰｕｂｌｉｓｈｅｒおよびＳｕｂｓｃｒｉｂｅｒ（ここでは、ＰＵＢＸとＳＵＢＺ）へ届けられる。
＜イベント配信パスの構築＞
　図１３は、本実施形態による分散型イベント配信システムにおけるイベント配信パスの構築手順を説明するためのネットワーク図である。ただし、図１３は図１２に示した分散型イベント配信システムの動作が完了した後の動作を示している。
　イベントＴｏｐｉｃ制御メッセージＥＴＣを受信したＰｕｂｌｉｓｈｅｒＰＵＢＸ、ＳｕｂｓｃｒｉｂｅｒＳＵＢＺは、イベントＴｏｐｉｃ制御メッセージＥＴＣで通知されたランデブーノードＥＢ３を最終宛先として、新規イベントＴｏｐｉｃを記載したＡｄｖｅｒｔｉｓｅメッセージおよびＳｕｂｓｃｒｉｂｅメッセージを直接接続するブローカノードへ送信する。これにより新規イベントＴｏｐｉｃに対応するイベント配信パスが構築される。
　ＰｕｂｌｉｓｈｅｒＰＵＢＸは、イベントＴｏｐｉｃ制御メッセージＥＴＣを受信すると、イベントＴｏｐｉｃ制御メッセージＥＴＣに記載された新規ランデブーノードＥＢ３を最終宛先として、新規イベントＴｏｐｉｃ「横浜の天気」を記載したＡｄｖｅｒｔｉｓｅメッセージを送信する。本メッセージはブローカノードＥＢ１、ＥＢ２において転送処理が行われ（通常のＡｄｖｅｒｔｉｓｅメッセージの転送時と同様、Ａｄｖｅｒｔｉｓｅｍｅｎｔテーブルのエントリが作成される）、新規ランデブーノードＥＢ３へと到達する。　また、ＳｕｂｓｃｒｉｂｅｒＳＵＢＺも同様に、イベントＴｏｐｉｃ制御メッセージＥＴＣを受信すると、イベントＴｏｐｉｃ制御メッセージＥＴＣに記載された新規ランデブーノードＥＢ３を最終宛先として、新規イベントＴｏｐｉｃ「横浜の天気」を記載したＳｕｂｓｃｒｉｂｅメッセージを送信する。既に説明した通常のＳｕｂｓｃｒｉｂｅメッセージの転送処理と同様に、ブローカノードＥＢ４、ＥＢ３、ＥＢ２、ＥＢ１のＳｕｂｓｃｒｉｐｔｉｏｎテーブル上に新規にエントリが作成される。
　こうして、新規イベントＴｏｐｉｃを利用したイベントの送受信を行うＰｕｂｌｉｓｈｅｒＰＵＢＸとＳｕｂｓｃｒｉｂｅｒＳＵＢＺとを結ぶイベント配信パスが構築される。
＜新規イベントＴｏｐｉｃを利用したイベントの転送＞
　図１４は、本実施形態による分散型イベント配信システムにおけるイベント転送手順を説明するためのネットワーク図である。ただし、図１４は、図１３に示した分散型イベント配信システムの動作が完了した後の動作を示している。
　イベント配信パスの構築完了後、新規に作成したイベントＴｏｐｉｃを利用したイベントの転送が可能になる。ＰｕｂｌｉｓｈｅｒＰＵＢＸのイベントＴｏｐｉｃ制御メッセージ受信部２０４は、イベントＴｏｐｉｃ制御メッセージにより通知されたイベントルールに合致したイベントを含むＰｕｂｌｉｓｈメッセージがＰｕｂｌｉｓｈ送信部２０３から送信されると、それをインターセプトし、当該イベントのイベントＴｏｐｉｃを新規イベントＴｏｐｉｃへ書き換える。これによって、Ｐｕｂｌｉｓｈメッセージは新規イベントＴｏｐｉｃを利用してＳｕｂｓｃｒｉｂｅｒＳＵＢＺへと転送される。つまり、上述したステップにより作成された新規イベントＴｏｐｉｃに対応するイベント配信パスを利用して転送される。新規イベントＴｏｐｉｃを利用したイベントの転送は新規イベントＴｏｐｉｃを担当するランデブーノードＥＢ３を経由して転送されるため、ランデブーノード間で負荷が分散されることになる。ＳｕｂｓｃｒｉｂｅｒＳＵＢＺのイベントＴｏｐｉｃ制御メッセージ受信部３０２は、新規イベントＴｏｐｉｃを利用して受信したイベントのイベントＴｏｐｉｃを書き換え、Ｐｕｂｌｉｓｈ受信部３０３に渡す。
　ＰｕｂｌｉｓｈｅｒＰＵＢＸは/神奈川/横浜にマッチするイベントのイベントＴｏｐｉｃを「横浜の天気」に書き換えて送信する。当該イベントは図１３に示した動作で構築されたイベント配信パスにより新規のランデブーノードＥＢ３を経由してＳｕｂｓｃｒｉｂｅｒＳＵＢＺへと転送される。
４．２）イベントＴｏｐｉｃの削除
　図１５は、本実施形態による分散型イベント配信システムにおけるイベントＴｏｐｉｃの削除手順を説明するためのネットワーク図である。ただし、図１５は図１４に示した分散型イベント配信システムの動作が完了した後の動作を示している。
　イベントＴｏｐｉｃの削除時には、イベントＴｏｐｉｃ作成時と同様に、イベント監視部１０５は、特定のイベントルールのイベントの転送負荷が転送負荷変動パターンにマッチしたことを検出した場合またはマッチすると推定した場合に、当該イベントルールと転送負荷変動パターンをイベントＴｏｐｉｃ制御部１０７へ通知する。イベントＴｏｐｉｃ制御部１０７は、イベント監視部１０５から通知を受けると、通知されたイベントルールのターゲットイベントＴｏｐｉｃを削除対象イベントＴｏｐｉｃとして選択し、マージ先イベントＴｏｐｉｃおよびランデブーノードを選択する。
　次に、イベントＴｏｐｉｃ制御部１０７は、イベントＴｏｐｉｃ制御メッセージＥＴＣを作成し、ＡｄｖｅｒｔｉｓｅｍｅｎｔテーブルおよびＳｕｂｓｃｒｉｐｔｉｏｎテーブルを参照してイベント監視部１０５から通知されたイベントルールに合致するＮｅｘｔホップへイベントＴｏｐｉｃ制御メッセージＥＴＣを送信する。イベントＴｏｐｉｃ制御メッセージＥＴＣの転送を行うブローカノードは、イベントＴｏｐｉｃ制御メッセージに記載された削除対象イベントＴｏｐｉｃに合致するエントリを削除する。これにより削除対象イベントＴｏｐｉｃのイベント転送に用いられていたイベント配信パスが削除されることになる。
　図１５において、ブローカノードＥＢ３は、イベントＴｏｐｉｃ「横浜の天気」のイベントの転送負荷の変動がイベントＴｏｐｉｃの削除と対応付けられた転送負荷変動パターンと一致したことを検出または推定すると、図１５に示したイベントＴｏｐｉｃ制御メッセージＥＴＣを作成し、Ａｄｖｅｒｔｉｓｅｍｅｎｔテーブル、Ｓｕｂｓｃｒｉｐｔｉｏｎテーブルに登録されたイベントＴｏｐｉｃ「横浜の天気」を持つエントリのＮｅｘｔホップへ当該メッセージを送信する。
　イベントＴｏｐｉｃ制御メッセージＥＴＣは、それを受信したブローカノードによってＡｄｖｅｒｔｉｓｅｍｅｎｔテーブル、Ｓｕｂｓｃｒｉｐｔｉｏｎテーブルに登録されたイベントＴｏｐｉｃ「横浜の天気」を持つエントリのＮｅｘｔホップへと順次転送され、最終的にイベントＴｏｐｉｃ「横浜の天気」を用いたイベントの送受信を行うＰｕｂｌｉｓｈｅｒＰＵＢＸ、ＳｕｂｓｃｒｉｂｅｒＳＵＢＺへと届けられる。イベントＴｏｐｉｃ制御メッセージＥＴＣの転送を行った各ブローカノードＥＢ１～ＥＢ４は転送後、イベントＴｏｐｉｃ「横浜の天気」を持つエントリをＡｄｖｅｒｔｉｓｅｍｅｎｔテーブル、Ｓｕｂｓｃｒｉｐｔｉｏｎテーブルから削除する。これにより、イベントＴｏｐｉｃ「横浜の天気」のイベントの転送に利用されていたイベント配信パスが削除される。
４．３）効果
　本発明の第１実施形態によれば、次のような効果を得ることができる。
ａ）イベント転送の負荷の変動に柔軟に対応できる。その理由は、本実施形態による分散型イベントシステムでは、イベント転送の負荷の変動に応じてイベント配信パスの新規作成や削除が動的に行われるためである。
　イベント転送の負荷が増加した、または増加すると見込まれる場合、本実施形態によるブローカノードは新規にイベントＴｏｐｉｃを作成するとともに当該新規イベントＴｏｐｉｃを担当するランデブーノードを新規に選択して、ＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒへ新規にイベント配信パスを作成するよう指示する。指示を受けたＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒが新規に選択されたランデブーノードへＡｄｖｅｒｔｉｓｅメッセージやＳｕｂｓｃｒｉｂｅメッセージを送信することで新規にイベント配信パスが作成される。
　さらにＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒは、一部またはすべてのイベントを新規イベント配信パスを利用してイベントの送受信を行う。以上の動作により本発明の分散型イベント配信システムではイベント転送の負荷が増加した、また増加すると見込まれる場合、既存のイベント配信パスの負荷を新規に作成されたイベント配信パスへ分散することができる。
　また、イベントイベント転送の負荷が減少した、または減少すると見込まれる場合、本実施形態によるブローカノードは、既存のイベントＴｏｐｉｃを削除するとともに、削除後にイベントの送受信に利用すべきマージ先イベントＴｏｐｉｃを既存のイベントＴｏｐｉｃから選択して、ＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒへ削除したイベントＴｏｐｉｃに対応するイベント配信パスを削除するよう指示する。指示を受けたＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒは、ＡｄｖｅｒｔｉｓｅメッセージやＳｕｂｓｃｒｉｂｅメッセージを送信することでイベント配信パスが削除される。これにより本実施形態による分散型イベント配信システムでは、イベント転送の負荷が減少した、または減少すると見込まれる場合、既存のイベント配信パスを削除してイベント配信パス維持に伴うオーバヘッドを削減することができる。
　また、ＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒはイベント配信パス削除後、削除したイベントＴｏｐｉｃを利用して送受信していたイベントをマージ先イベントＴｏｐｉｃを利用して送受信する。これによりイベント配信パス削除後もイベントの送受信を行うことができる。
ｂ）同一のイベントＴｏｐｉｃにより送受信されているイベントの中から転送負荷が増加した、または増加すると見込まれるイベントのみを別のイベント配信パスを利用して送受信できる。その理由は、本実施形態によるブローカノードにはイベントＴｏｐｉｃに加えＦｉｌｔｅｒｉｎｇルールやＰｕｂｌｉｓｈメッセージの属性なども条件として追加可能なイベントルールが設定されており、ブローカノード内のイベント監視部がイベントルール毎に転送負荷の監視を行うためである。
　ブローカノードは転送負荷が増加した、または増加すると見込まれるイベントルールに対応する新規イベントＴｏｐｉｃを作成すると共に新規ランデブーノードを選択して、これら新規イベントＴｏｐｉｃと新規ランデブーノードと共にイベントルールをＰｕｂｌｉｓｈｅｒ、Ｓｕｂｓｃｒｉｂｅｒへ通知して新規イベント配信パスを作成するよう指示する。指示を受けたＰｕｂｌｉｓｈｅｒ、Ｓｕｂｓｃｒｉｂｅｒは新規イベント配信パス作成後、通知されたイベントルールにマッチするイベントを新規イベント配信パスを利用して送受信する。これにより同一のイベントＴｏｐｉｃにより送受信されているイベントの中から転送負荷が増加した、または増加すると見込まれるイベントのみを別のイベント配信パスを利用して送受信できる。
　本実施形態による方式は、単純負荷分散方式、すなわち同一イベントＴｏｐｉｃのイベント送受信に利用するイベント配信パスを複数用意し、ラウンドロビン等の方法でイベント配信パスを使い分けて負荷分散を行う方式と比べて、効率がよい。
　例えば、イベントＴｏｐｉｃ「Ａ」のイベントの送受信に利用するイベント配信パスを考える。単純負荷分散方式では「Ａ」のイベントの送受信を行う全てのＳｕｂｓｃｒｉｂｅｒ、Ｐｕｂｌｉｓｈｅｒが複数のイベント配信パス全てに接続する必要がある。つまり、「Ａ」の送受信を行う全てのＳｕｂｓｃｒｉｂｅｒ、Ｐｕｂｌｉｓｈｅｒが複数のランデブーノードに対してＳｕｂｓｃｒｉｂｅメッセージ、Ａｄｖｅｒｔｉｓｅメッセージを送信する必要がある。
　これに対して、本実施形態によれば、「Ａ」のイベントの送受信を行うＳｕｂｓｃｒｉｂｅｒ、Ｐｕｂｌｉｓｈｅｒのうち、特に転送負荷が増加した、または増加すると見込まれるイベントルールに対応するイベントを送受信するＳｕｂｓｃｒｉｂｅｒ、Ｐｕｂｌｉｓｈｅｒのみが新規に作成されたイベント配信パスに接続する。このため、イベント配信パスを複数用意して負荷分散を行う場合、本実施形態では単純負荷分散方式と比較してＳｕｂｓｃｒｉｂｅ、Ａｄｖｅｒｔｉｓｅメッセージの転送に伴うオーバヘッドを低くすることができる。
ｃ）ブローカノードが個々のＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒを把握することなくイベント配信パスの新規作成や削除を行うことができる。その理由は、ブローカノードにおいてイベントＴｏｐｉｃ制御メッセージの送信、転送がＡｄｖｅｒｔｉｓｅｍｅｎｔテーブル、Ｓｕｂｓｃｒｉｐｔｉｏｎテーブルを参照して行われるためである。Ａｄｖｅｒｔｉｓｅｍｅｎｔテーブル、Ｓｕｂｓｃｒｉｐｔｉｏｎテーブルには、イベントＴｏｐｉｃ、Ｆｉｌｔｅｒｉｎｇルール毎に当該イベントＴｏｐｉｃおよびＦｉｌｔｅｒｉｎｇルールにマッチするイベントの送受信を行うＰｕｂｌｉｓｈｅｒ、Ｓｕｂｓｃｒｉｂｅｒへの経路のＮｅｘｔホップが登録されている。このため、ブローカノードがイベントＴｏｐｉｃ制御メッセージを、イベントＴｏｐｉｃ制御メッセージのイベントルールにマッチするＡｄｖｅｒｔｉｓｅｍｅｎｔテーブル、ＳｕｂｓｃｒｉｐｔｉｏｎテーブルのＮｅｘｔホップへ転送することにより、各ブローカノードが個々のＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒを把握することなく、イベントＴｏｐｉｃ制御メッセージをＰｕｂｌｉｓｈｅｒ、Ｓｕｂｓｃｒｉｂｅｒへ届けることが可能になる。
　極めて多数の（例えば１０００万台の）ＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒが存在する場合やＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒのイベント配信パスへの接続や切断が頻繁に行われる場合において、ブローカノードが個々のＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒのＩＰアドレスやイベント配信パスへの参加状態を常時把握することは非現実的であるが、本実施形態によるブローカノードはこうしたケースにも対応できる。
ｄ）イベント配信パス削除時のＡｄｖｅｒｔｉｓｅｍｅｎｔ、Ｓｕｂｓｃｒｉｐｔｉｏｎテーブルのエントリ削除を迅速に行うことができる。その理由はブローカノードが削除対象イベントＴｏｐｉｃのイベントの送受信を今後行わない旨記載されたＡｄｖｅｒｔｉｓｅメッセージおよびＳｕｂｓｃｒｉｂｅメッセージがＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒから送信されることを待つことなく、イベントＴｏｐｉｃの削除を通知するイベントＴｏｐｉｃ制御メッセージの受信をトリガとして、削除対象イベントＴｏｐｉｃを含むエントリをＡｄｖｅｒｔｉｓｅｍｅｎｔテーブル、Ｓｕｂｓｃｒｉｐｔｉｏｎテーブルから削除することができるためである。
５．第２実施形態
　本発明の第２実施形態は、その基本的構成は上記第１実施形態と同様であるが、イベントＴｏｐｉｃ制御メッセージの到達範囲を、新規イベントＴｏｐｉｃ作成を行ったブローカノードの近傍に制限できる点が第１実施形態と異なっている。まず、この点について、図１６～図１８を用いて説明する。
　図１６はイベントＴｏｐｉｃ「関東の天気」のイベント配信パスを示すネットワーク図である。上述したように、「関東の天気」を担当するランデブーノードから複数のＰｕｂｌｉｓｈｅｒおよびＳｕｂｓｃｒｉｂｅｒへのイベント配信パス４０１が設定されている。
　図１７は、本発明の第１実施形態におけるイベントＴｏｐｉｃ「横浜の天気」のイベント配信パスを示すネットワーク図である。第１実施形態によれば、イベントＴｏｐｉｃ「関東の天気」を担当するランデブーノードがイベントＴｏｐｉｃ「横浜の天気」の新規作成を行った場合、イベントＴｏｐｉｃ制御メッセージ到達範囲４０３は、イベント配信パスの末端、すなわち全てのＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒまで至る。言い換えれば、末端から新たに新規イベントＴｏｐｉｃ「横浜の天気」のイベント配信パスが構築される。
　図１８は、本発明の第２実施形態におけるイベントＴｏｐｉｃ「横浜の天気」のイベント配信パスを示すネットワーク図である。上述した第１実施形態の場合とは異なり、第２実施形態では、イベントＴｏｐｉｃ制御メッセージの到達範囲５０１がイベントＴｏｐｉｃ「関東の天気」を担当するランデブーノードの近傍に限定される。すなわち、新規イベントＴｏｐｉｃ「横浜の天気」のイベント配信パスは、ＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒの末端付近ではイベントＴｏｐｉｃ「関東の天気」と共通の経路が利用され、異なる経路が利用されるのはイベントＴｏｐｉｃ「関東の天気」を担当するランデブーノードの近傍のみである。
　このように第２実施形態では、イベントＴｏｐｉｃ制御メッセージの到達範囲を、新規イベントＴｏｐｉｃ作成を行ったブローカノードの近傍に制限する。これにより以下の効果を期待できる。
（１）末端までイベントＴｏｐｉｃ制御メッセージが届くのを待つ必要がないため、新規イベントＴｏｐｉｃ作成時に迅速にイベント配信パスを構築することが可能になる。
（２）イベントＴｏｐｉｃ制御メッセージ転送に伴うオーバヘッドを抑制することができる。末端付近ではイベントＴｏｐｉｃ制御メッセージの転送が行われないため、末端付近でのイベントＴｏｐｉｃ制御メッセージの転送に伴うネットワーク帯域の消費やブローカノードの計算資源消費が抑制される。
（３）ブローカノードにおけるＡｄｖｅｒｔｉｓｅｍｅｎｔテーブルおよびＳｕｂｓｃｒｉｐｔｉｏｎテーブルのサイズを抑制できる。末端付近でのブローカノードでは新規イベントＴｏｐｉｃ作成に伴うＡｄｖｅｒｔｉｓｅｍｅｎｔテーブルおよびＳｕｂｓｃｒｉｐｔｉｏｎテーブルへのエントリ追加が行われないため、テーブルサイズを抑制することができ、これによりテーブル検索時間の短縮が期待できる。
　以下、本発明の第２実施形態によるイベントＴｏｐｉｃ制御システムについて詳細に説明する。
５．１）ブローカノードの構成および動作
　図１９は本発明の第２実施形態によるイベントＴｏｐｉｃ制御装置を含むブローカノードの機能的構成を示すブロック図、図２０はイベントＴｏｐｉｃ制御ポリシ管理テーブルに設定されている制御ポリシの一例を示す図である。なお、図５に示す第１実施形態におけるブローカノードと同じ機能を有するブロックには同一の参照番号を付して説明は省略する。
　図１９において、ブローカノードＥＢは、機能的に、Ｓｕｂｓｃｒｉｐｔｉｏｎテーブル１０１、Ａｄｖｅｒｔｉｓｅｍｅｎｔテーブル１０２、ルーティングテーブル管理部１０３およびイベント転送部１０４を有し、さらに、イベント監視部１０５および転送負荷変動通知ポリシ管理テーブル１０６と、イベントＴｏｐｉｃ制御部６０１およびイベントＴｏｐｉｃ制御ポリシ管理テーブル６０２と、イベントＴｏｐｉｃ制御メッセージ受信部６０３、Ｓｕｂｓｃｒｉｂｅ送信部６０４およびＡｄｖｅｒｔｉｓｅ送信部６０５とを有する。イベントＴｏｐｉｃ制御部６０１は、後述するように、イベントＴｏｐｉｃ制御メッセージの到達範囲を設定／変更するためのＴＴＬ制御部６０１ａを機能的に含む。
　本実施形態におけるブローカノードＥＢと図５に示す第１実施形態におけるブローカノードＥＢとは、イベントＴｏｐｉｃ制御部６０１およびイベントＴｏｐｉｃ制御ポリシ管理テーブル６０２の機能が異なっており、さらにイベントＴｏｐｉｃ制御メッセージ受信部６０３、Ｓｕｂｓｃｒｉｂｅ送信部６０４およびＡｄｖｅｒｔｉｓｅ送信部６０５を有する点が異なっている。以下、この異なる点について詳細に説明する。
＜イベントＴｏｐｉｃ制御部＞
　図１９におけるイベントＴｏｐｉｃ制御部６０１は、イベントＴｏｐｉｃ制御メッセージに対して、その到達範囲を任意に制御する到達範囲制御機能としてＴＴＬ制御部６０１ａを有する。イベントＴｏｐｉｃ制御メッセージの到達範囲は次のようにして任意に制御されうる。たとえば、イベントＴｏｐｉｃ制御メッセージを作成するノードでＴＴＬ（Ｔｉｍｅ　Ｔｏ　Ｌｉｖｅ）値を設定し、他のブローカノードから受信したイベントＴｏｐｉｃ制御メッセージを転送する際にそのＴＴＬ値を１だけ減じ、ＴＴＬ値がゼロでなければ転送し、ＴＴＬ値がゼロになれば当該イベントＴｏｐｉｃ制御メッセージを受信して転送しない、というシーケンスを実行する。
　図２０に示すように、イベントＴｏｐｉｃ制御部６０１に設定される制御ポリシは、図８に示す第１実施形態の制御ポリシを拡張したものである。すなわち、イベントルールと転送負荷変動パターンに対応する動作内容の一部として、イベントＴｏｐｉｃ制御メッセージへ設定するＴＴＬ値が設定される。自ノードの負荷が大きい場合にはより広い範囲で新規イベント配信パスの構築を実施する、といったポリシで到達範囲を制御する。例えば、同一のイベントルールについて、転送頻度が５０００イベント/sec以上の場合はＴＴＬ＝５に設定し、１００００イベント/sec以上の場合はＴＴＬ＝７に設定するなどである。
　また、他のブローカノードから受信したイベントＴｏｐｉｃ制御メッセージを転送する際のＴＴＬの計算も自身の負荷に応じて柔軟に変更することができる。基本的には、転送の際に１減じる処理を行うが、たとえば自身の負荷がきわめて低い場合には転送の際に５減じるなどしてイベントＴｏｐｉｃ制御メッセージ転送範囲（すなわち新規イベント配信パスの構築範囲）を自身の近傍に制限することができる。逆に、自身の負荷が大きい場合には、ＴＴＬを逆に１増やすなどして転送範囲を拡大することも可能である。このようにイベントＴｏｐｉｃ制御メッセージ転送時のＴＴＬ計算方法を転送するブローカノードの負荷に応じて変更することにより、新規イベントＴｏｐｉｃの作成を行ったブローカノードから離れた場所の負荷状況をも反映してイベント配信パスの構築の範囲を制御することできる。
　本実施形態におけるイベントＴｏｐｉｃ制御部６０１は、他のブローカノードから受信したイベントＴｏｐｉｃ制御メッセージを転送する際にＴＴＬを１だけデクリメントするが、そのＴＴＬ値がゼロになると、イベントＴｏｐｉｃ制御メッセージ受信部６０３へイベントＴｏｐｉｃ制御メッセージの受信処理を行うよう指示する。
＜イベントＴｏｐｉｃ制御メッセージ受信部＞
　イベントＴｏｐｉｃ制御メッセージ受信部６０３は、イベントＴｏｐｉｃ制御部６０１からの指示を受けて、図９および図１０に示す第１実施形態におけるＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒのイベントＴｏｐｉｃ制御メッセージ受信部（２０４、３０２）と同様の受信処理を行う。具体的には、次の通りである。
１）隣接するブローカノードがＡｄｖｅｒｔｉｓｅｍｅｎｔテーブルを参照して自ノードへイベントＴｏｐｉｃ制御メッセージを転送した場合には、イベントＴｏｐｉｃ制御メッセージ受信部６０３は第１実施形態におけるＰｕｂｌｉｓｈｅｒのイベントＴｏｐｉｃ制御メッセージ受信部２０４と同様の処理を行う。すなわち、イベントＴｏｐｉｃ制御メッセージ受信部６０３は、Ａｄｖｅｒｔｉｓｅ送信部６０５に対して、イベントＴｏｐｉｃ制御メッセージで通知された新規イベントＴｏｐｉｃを記載したＡｄｖｅｒｔｉｓｅメッセージを、同じくイベントＴｏｐｉｃ制御メッセージで通知された新規ランデブーノードを最終宛先として送信するよう指示する。
　また、自ノードがＰｕｂｌｉｓｈメッセージを転送する際に、イベントＴｏｐｉｃ制御メッセージに記載されたイベントルールを参照し、当該イベントルールに合致するイベントを含んだＰｕｂｌｉｓｈメッセージをインターセプトする。そして、当該ＰｕｂｌｉｓｈメッセージのイベントＴｏｐｉｃをイベントＴｏｐｉｃ制御メッセージで通知された新規イベントＴｏｐｉｃに書き換える。こうして、当該イベントは新規イベントＴｏｐｉｃを利用して配信される。すなわち新規イベントＴｏｐｉｃ作成時に作成された新規のイベント配信パスを利用して配信される。
２）隣接するブローカノードがＳｕｂｓｃｒｉｐｔｉｏｎテーブルを参照して自ノードへイベントＴｏｐｉｃ制御メッセージを転送した場合には、イベントＴｏｐｉｃ制御メッセージ受信部６０３は第１実施形態におけるＳｕｂｓｃｒｉｂｅｒのイベントＴｏｐｉｃ制御メッセージ受信部３０２と同様の処理を行う。すなわち、イベントＴｏｐｉｃ制御メッセージ受信部６０３は、Ｓｕｂｓｃｒｉｂｅ送信部６０４に対して、イベントＴｏｐｉｃ制御メッセージで通知された新規イベントＴｏｐｉｃを記載したＳｕｂｓｃｒｉｂｅメッセージを、同じくイベントＴｏｐｉｃ制御メッセージで通知された新規ランデブーノードを最終宛先として送信するよう指示する。
　また、受信したイベントＴｏｐｉｃ制御メッセージに記載された新規イベントＴｏｐｉｃを参照し、新規イベントＴｏｐｉｃのイベントを含むＰｕｂｌｉｓｈメッセージをインターセプトする。そして、当該ＰｕｂｌｉｓｈメッセージのイベントＴｏｐｉｃをイベントルールに記載されたターゲットイベントＴｏｐｉｃに書き換える。書き換え後、当該イベントはターゲットイベントＴｏｐｉｃを利用して配信される。すなわち、新規イベントＴｏｐｉｃ作成以前から存在したターゲットイベントＴｏｐｉｃのイベントを配信するためのイベント配信パスを利用して配信される。
＜Ｓｕｂｓｃｒｉｂｅ送信部＞
　Ｓｕｂｓｃｒｉｂｅ送信部６０４は、イベントＴｏｐｉｃ制御メッセージ受信部６０３からの指示を受けてイベントＴｏｐｉｃ制御メッセージで通知された新規イベントＴｏｐｉｃを記載したＳｕｂｓｃｒｉｂｅメッセージを、同じくイベントＴｏｐｉｃ制御メッセージで通知された新規ランデブーノードを最終宛先として送信する。
＜Ａｄｖｅｒｔｉｓｅ送信部＞
　Ａｄｖｅｒｔｉｓｅ送信部６０５は、イベントＴｏｐｉｃ制御メッセージ受信部６０３からの指示を受けてイベントＴｏｐｉｃ制御メッセージで通知された新規イベントＴｏｐｉｃを記載したＡｄｖｅｒｔｉｓｅメッセージを、同じくイベントＴｏｐｉｃ制御メッセージで通知された新規ランデブーノードを最終宛先として送信する。
　なお、ルーティングテーブル管理部１０３、イベント転送部１０４、イベント監視部１０５、イベントＴｏｐｉｃ制御部６０１、イベントＴｏｐｉｃ制御メッセージ受信部６０３、Ｓｕｂｓｃｒｉｂｅ送信部６０４およびＡｄｖｅｒｔｉｓｅ送信部６０５の上述した機能は、ＣＰＵ等のプログラム制御プロセッサ上でプログラムを実行することにより実現することもできる。
５．２）効果
　本発明の第２実施形態によれば、既に述べた第１実施形態による効果に加えて、次のような効果を得ることができる。
ａ）イベント配信パスの新規作成、削除に伴うオーバヘッドを抑制できる。具体的には次の通りである。イベントＴｏｐｉｃ制御メッセージを送信するブローカノードは、イベントＴｏｐｉｃ制御メッセージのＴＴＬを設定することにより、その到達範囲を任意に制御することができる。さらに、転送時にイベントＴｏｐｉｃ制御メッセージのＴＴＬが０となったブローカノードは、Ｐｕｂｌｉｓｈｅｒ、Ｓｕｂｓｃｒｉｂｅｒの代わりにＡｄｖｅｒｔｉｓｅメッセージ、Ｓｕｂｓｃｒｉｂｅメッセージの送信を行うことができる。これにより、イベントＴｏｐｉｃ制御メッセージをイベント配信パスの末端（すなわちＰｕｂｌｉｓｈｅｒ、Ｓｕｂｓｃｒｉｅｂｒ）まで転送する必要がなくなり、イベント配信パスの新規作成、削除に伴うオーバヘッドを抑制することが可能になる。
ｂ）イベント転送の負荷の変動に応じてイベント配信パスを新規作成する範囲を制御できる。なぜならば、イベントＴｏｐｉｃ制御メッセージを送信または転送するブローカノードがイベントＴｏｐｉｃ制御メッセージのＴＴＬの値をイベントの転送負荷の変動に応じて変更することができるからである。例えば検出した負荷の増加幅が大きいほど、ＴＴＬに大きな値を設定することでイベントＴｏｐｉｃ制御メッセージを広範囲に到達させ、より広い範囲でイベント配信パスが新規に作成されるようにするといったことが可能になる。
　以上、実施形態および実施例を参照して本願発明を説明したが、本願発明は上記実施形態および実施例に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
　この出願は、２００９年２月５日に出願された日本特許出願２００９－２４５９０を基礎とする優先権を主張し、その開示の全てをここに取り込む。
　本発明はブローカノード・ベースの分散型イベント配信システム一般に適用可能である。
　１０１　Ｓｕｂｓｃｒｉｐｔｉｏｎテーブル
　１０２　Ａｄｖｅｒｔｉｓｅｍｅｎｔテーブル
　１０３　ルーティングテーブル管理部
　１０４　イベント転送部
　１０５　イベント監視部
　１０６　転送負荷変動通知ポリシ管理テーブル
　１０７　イベントＴｏｐｉｃ制御部
　１０８　イベントＴｏｐｉｃ制御ポリシ管理テーブル
　２０１　Ａｄｖｅｒｔｉｓｅ送信部
　２０２　イベント発生部
　２０３　Ｐｕｂｌｉｓｈ送信部
　２０４　イベントＴｏｐｉｃ制御メッセージ受信部
　３０１　Ｓｕｂｓｃｒｉｂｅ送信部
　３０２　イベントＴｏｐｉｃ制御メッセージ受信部
　３０３　Ｐｕｂｌｉｓｈ受信部
　４０１　イベント配信パス
　４０２　イベントＴｏｐｉｃ制御メッセージ
　４０３　イベントＴｏｐｉｃ制御メッセージ到達範囲
　５０１　イベントＴｏｐｉｃ制御メッセージ到達範囲
　６０１　イベントＴｏｐｉｃ制御部
　６０２　イベントＴｏｐｉｃ制御ポリシ管理テーブル
　６０３　イベントＴｏｐｉｃ制御メッセージ受信部
　６０４　Ｓｕｂｓｃｒｉｂｅ送信部
　６０５　Ａｄｖｅｒｔｉｓｅ送信部
　ＰＵＢ　パブリッシャ（Ｐｕｂｌｉｓｈｅｒ）
　ＳＵＢ　サブスクライバ（Ｓｕｂｓｃｒｉｂｅｒ）
　ＥＢ　ブローカノード（Ｅｖｅｎｔ　Ｂｒｏｋｅｒ）

Claims (37)

  1. 　分散型イベント配信システムにおいてイベントの転送処理を行うブローカノードであって、
    　イベントルール毎に自ノードにかかるイベントの転送負荷の変動を監視する監視手段と、
    　前記転送負荷の変動に応じて当該イベントを転送するためのイベントトピックを動的に変更し、この変更に伴う指示を制御メッセージにより他のノードへ通知する制御手段とを備えた
    　ことを特徴とするブローカノード。
  2. 　前記制御手段は、イベントトピックの新規作成、削除または移動を行う請求項１に記載のブローカノード。
  3. 　前記制御手段は、前記制御メッセージの到達範囲を制御するための到達範囲制御手段を有する請求項１または請求項２に記載のブローカノード。
  4. 　前記到達範囲制御手段は、前記転送負荷の変動に応じて前記制御メッセージのＴＴＬ（Ｔｉｍｅ　Ｔｏ　Ｌｉｖｅ）値を設定する請求項３に記載のブローカノード。
  5. 　前記到達範囲制御手段は、他のブローカノードから到達した制御メッセージを転送する際に、ＴＴＬ値を前記転送負荷の変動に応じて変更する請求項４に記載のブローカノード。
  6. 　前記制御手段は、他のブローカノードから到達した制御メッセージのＴＴＬ値が０になると、当該制御メッセージを転送せずに受信する請求項５に記載のブローカノード。
  7. 　前記制御手段は、イベントトピックを新規に作成する場合、当該新規イベントトピックを担当するランデブーノードを他のブローカノードから新規に選択し、前記イベントの転送のための前記新規イベントトピックと前記ランデブーノードとを前記制御メッセージにより他のノードへ通知する請求項１から請求項６のうちのいずれか１項に記載のブローカノード。
  8. 　前記制御手段は、特定イベントルールにマッチするイベントの転送負荷が所定の増加パターンにマッチする場合、当該特定イベントルールに対応するイベントトピックを新規に作成し、当該新規イベントトピックを担当するランデブーノードを他のブローカノードから新規に選択し、前記特定のイベントルールにマッチするイベントの転送に前記新規イベントトピックと前記ランデブーノードを通るイベント配信パスとを用いるように前記制御メッセージにより他のノードへ指示する請求項７に記載のブローカノード。
  9. 　前記制御手段は、イベントトピックを削除する場合、当該イベントトピックを削除した後に前記イベントの転送に利用するマージ先イベントトピックを既存のイベントトピックから選択し、前記イベントの転送のための前記マージ先イベントトピックを前記制御メッセージにより他のノードへ通知する請求項１から請求項６のうちのいずれか１項に記載のブローカノード。
  10. 　前記制御手段は、特定イベントルールにマッチするイベントの転送負荷が所定の減少パターンにマッチする場合、当該特定イベントルールに対応するイベントトピックを削除し、当該イベントトピックを削除した後に前記特定イベントルールにマッチするイベントの転送に利用するマージ先イベントトピックを既存のイベントトピックから選択し、前記特定のイベントルールにマッチするイベントの転送に前記マージ先イベントトピックを用いるように前記制御メッセージにより他のノードへ指示する請求項９に記載のブローカノード。
  11. 　前記制御手段は、イベントトピックを移動する場合、当該イベントトピックを削除した後に前記イベントの転送に利用するマージ先イベントトピックを新規に作成し、当該マージ先イベントトピックを担当するランデブーノードを他のブローカノードから新規に選択し、前記イベントの転送のための前記マージ先イベントトピックおよび前記ランデブーノードを前記制御メッセージにより他のノードへ通知する請求項１から請求項６のうちのいずれか１項に記載のブローカノード。
  12. 　前記制御手段は、特定イベントルールにマッチするイベントの転送負荷が所定の変動パターンにマッチする場合、当該特定イベントルールに対応するイベントトピックを削除し、当該イベントトピックを削除した後に前記特定イベントルールにマッチするイベントの転送に利用するマージ先イベントトピックを新規に作成し、当該マージ先イベントトピックを担当するランデブーノードを他のブローカノードから新規に選択し、前記特定のイベントルールにマッチするイベントの転送に前記マージ先イベントトピックと前記ランデブーノードを通るイベント配信パスとを用いるように前記制御メッセージにより他のノードへ指示する請求項１１に記載のブローカノード。
  13. 　アドバタイズメント（Ａｄｖｅｒｔｉｓｅｍｅｎｔ）テーブルおよびサブスクリプション（Ｓｕｂｓｃｒｉｐｔｉｏｎ）テーブルを更に有し、
    　前記制御手段は、前記制御メッセージを送信する際、前記Ａｄｖｅｒｔｉｓｅｍｅｎｔテーブルまたは前記Ｓｕｂｓｃｒｉｐｔｉｏｎテーブルのエントリから前記特定イベントルールにマッチするエントリを検索し、当該エントリに登録されているネクストホップへ前記制御メッセージを送信し、
    　他のブローカノードから受信した制御メッセージを転送する際、当該受信した制御メッセージで指示された前記特定イベントルールにマッチするエントリを前記Ａｄｖｅｒｔｉｓｅｍｅｎｔテーブルまたは前記Ｓｕｂｓｃｒｉｐｔｉｏｎテーブルのエントリから検索し、当該エントリに登録されているネクストホップへ前記受信した制御メッセージを転送する
    　請求項１から請求項１２のうちのいずれか１項に記載のブローカノード。
  14. 　前記制御手段は、自ノードからの前記制御メッセージの送信または前記他のブローカノードから受信した制御メッセージの転送をトリガとして、前記Ａｄｖｅｒｔｉｓｅｍｅｎｔテーブルまたは前記Ｓｕｂｓｃｒｉｐｔｉｏｎテーブルから、前記制御メッセージで指示された前記特定イベントルールにマッチするエントリを削除する請求項１３記載のブローカノード。
  15. 　分散型イベント配信システムにおいてイベントの転送処理を行うブローカノードにおけるイベントトピック制御方法であって、
    　イベントルール毎に自ノードにかかるイベントの転送負荷の変動を監視し、
    　前記転送負荷の変動に応じて当該イベントを転送するためのイベントトピックを動的に変更し、
    　前記変更に伴う指示を制御メッセージにより他のノードへ通知する
    　ことを特徴とするイベントトピック制御方法。
  16. 　前記変更は、イベントトピックの新規作成、削除または移動である請求項１５に記載のイベントトピック制御方法。
  17. 　さらに、前記制御メッセージの到達範囲を制御する請求項１５または請求項１６に記載のイベントトピック制御方法。
  18. 　前記転送負荷の変動に応じて前記制御メッセージのＴＴＬ（Ｔｉｍｅ　Ｔｏ　Ｌｉｖｅ）値を設定することにより前記到達簡易を制御する請求項１７に記載のイベントトピック制御方法。
  19. 　他のブローカノードから到達した制御メッセージを転送する際に、ＴＴＬ値を前記転送負荷の変動に応じて変更することにより前記到達範囲を制御する請求項１８に記載のイベントトピック制御方法。
  20. 　他のブローカノードから到達した制御メッセージのＴＴＬ値が０になると、当該制御メッセージを転送せずに受信する請求項１９に記載のイベントトピック制御方法。
  21. 　イベントトピックを新規に作成する場合、当該新規イベントトピックを担当するランデブーノードを他のブローカノードから新規に選択し、
    　前記イベントの転送のための前記新規イベントトピックと前記ランデブーノードとを前記制御メッセージにより他のノードへ通知する
    　請求項１５から請求項２０のうちのいずれか１項に記載のイベントトピック制御方法。
  22. 　イベントトピックを削除する場合、当該イベントトピックを削除した後に前記イベントの転送に利用するマージ先イベントトピックを既存のイベントトピックから選択し、
    　前記イベントの転送のための前記マージ先イベントトピックを前記制御メッセージにより他のノードへ通知する
    　請求項１５から請求項２０のうちのいずれか１項に記載のイベントトピック制御方法。
  23. 　イベントトピックを移動する場合、当該イベントトピックを削除した後に前記イベントの転送に利用するマージ先イベントトピックを新規に作成し、
    　当該マージ先イベントトピックを担当するランデブーノードを他のブローカノードから新規に選択し、
    　前記イベントの転送のための前記マージ先イベントトピックおよび前記ランデブーノードを前記制御メッセージにより他のノードへ通知する
    　請求項１５から請求項２０のうちのいずれか１項に記載のイベントトピック制御方法。
  24. 　複数のブローカノードを有する分散型イベント配信システムにおけるパブリッシャ（Ｐｕｂｌｉｓｈｅｒ）ノードであって、
    　アドバタイズ（Ａｄｖｅｒｔｉｓｅ）メッセージを送信するアドバタイズ送信手段と、
    　パブリッシュ（Ｐｕｂｌｉｓｈ）メッセージを送信するパブリッシュ送信手段と、
    　ブローカノードからイベントトピックの変更を指示する制御メッセージを受信すると、前記制御メッセージで指示された新規イベントトピックまたはマージ先イベントトピックを記載したアドバタイズ（Ａｄｖｅｒｔｉｓｅ）メッセージを前記制御メッセージで指示されたランデブーノードを最終宛先として送信し、前記制御メッセージで前記新規イベントトピックまたは前記マージ先イベントトピックをイベントの転送に用いるよう指示された特定のイベントトピックを前記新規イベントトピックまたは前記マージ先イベントトピックに書き換えたパブリッシュメッセージを送信するように制御する制御手段と
    　を備えたことを特徴とするパブリッシャノード。
  25. 　複数のブローカノードを有する分散型イベント配信システムにおけるサブスクライバ（Ｓｕｂｓｃｒｉｂｅｒ）ノードであって、
    　サブスクライブ（Ｓｕｂｓｃｒｉｂｅ）メッセージを送信するサブスクライブ送信手段と、
    　パブリッシュ（Ｐｕｂｌｉｓｈ）メッセージを受信するパブリッシュ受信手段と、
    　ブローカノードからイベントトピックの変更を指示する制御メッセージを受信すると、前記制御メッセージで指示された新規イベントトピックまたはマージ先イベントトピックを記載したＳｕｂｓｃｒｉｂｅメッセージを前記制御メッセージで指示されたランデブーノードを最終宛先として送信するように指示する制御手段と
    　を備えたことを特徴とするサブスクライバノード。
  26. 　分散型イベント配信システムにおいて、
    　アドバタイズ（Ａｄｖｅｒｔｉｓｅ）メッセージおよびパブリッシュ（Ｐｕｂｌｉｓｈ）メッセージを送信するパブリッシャ（Ｐｕｂｌｉｓｈｅｒ）ノードと、
    　サブスクライブ（Ｓｕｂｓｃｒｉｂｅ）メッセージを送信し、前記パブリッシュメッセージを受信するサブスクライバノードと、
    　パブリッシャノードからサブスクライバノードへのイベントの転送処理を行う複数のブローカノードとを備え、
    　各ブローカノードは、
    　イベントルール毎に自ノードにかかるイベントの転送負荷の変動を監視する監視手段と、
    　前記転送負荷の変動に応じて当該イベントを転送するためのイベントトピックを動的に変更し、この変更に伴う指示を制御メッセージにより他のノードへ通知する制御手段とを有する
    　こと特徴とする分散型イベント配信システム。
  27. 　前記ブローカノードの前記制御手段は、イベントトピックの新規作成、削除または移動を行う請求項２６に記載の分散型イベント配信システム。
  28. 　前記ブローカノードの前記制御手段は、前記制御メッセージの到達範囲を制御するための到達範囲制御手段を有する請求項２６または請求項２７に記載の分散型イベント配信システム。
  29. 　前記到達範囲制御手段は、前記転送負荷の変動に応じて前記制御メッセージのＴＴＬ（Ｔｉｍｅ　Ｔｏ　Ｌｉｖｅ）値を設定する請求項２８に記載の分散型イベント配信システム。
  30. 　前記到達範囲制御手段は、他のブローカノードから到達した制御メッセージを転送する際に、ＴＴＬ値を前記転送負荷の変動に応じて変更する請求項２９に記載の分散型イベント配信システム。
  31. 　前記到達範囲制御手段は、他のブローカノードから到達した制御メッセージのＴＴＬ値が０になると、当該制御メッセージを転送せずに受信する請求項３０に記載の分散型イベント配信システム。
  32. 　分散型イベント配信システムにおいてイベントの転送処理を行うブローカノードにおけるプログラム制御プロセッサをイベントトピック制御装置として機能させるプログラムであって、
    　イベントルール毎に自ノードにかかるイベントの転送負荷の変動を監視し、
    　前記転送負荷の変動に応じて当該イベントを転送するためのイベントトピックを動的に変更し、
    　前記変更に伴う指示を制御メッセージにより他のノードへ通知する
    　ように前記プログラム制御プロセッサを機能させることを特徴とするプログラム。
  33. 　前記変更は、イベントトピックの新規作成、削除または移動である請求項３２に記載のプログラム。
  34. 　さらに、前記制御メッセージの到達範囲を制御する請求項３２または請求項３３に記載のプログラム。
  35. 　前記転送負荷の変動に応じて前記制御メッセージのＴＴＬ（Ｔｉｍｅ　Ｔｏ　Ｌｉｖｅ）値を設定することにより前記到達簡易を制御する請求項３４に記載のプログラム。
  36. 　他のブローカノードから到達した制御メッセージを転送する際に、ＴＴＬ値を前記転送負荷の変動に応じて変更することにより前記到達範囲を制御する請求項３５に記載のプログラム。
  37. 　他のブローカノードから到達した制御メッセージのＴＴＬ値が０になると、当該制御メッセージを転送せずに受信する請求項３６に記載のプログラム。
PCT/JP2010/000684 2009-02-05 2010-02-04 分散型イベント配信システムにおけるブローカノードおよびイベントトピック制御方法 WO2010090027A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US13/147,675 US20110307603A1 (en) 2009-02-05 2010-02-04 Broker node and event topic control method in distributed event distribution system
JP2010549406A JPWO2010090027A1 (ja) 2009-02-05 2010-02-04 分散型イベント配信システムにおけるブローカノードおよびイベントトピック制御方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2009-024590 2009-02-05
JP2009024590 2009-02-05

Publications (1)

Publication Number Publication Date
WO2010090027A1 true WO2010090027A1 (ja) 2010-08-12

Family

ID=42541936

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2010/000684 WO2010090027A1 (ja) 2009-02-05 2010-02-04 分散型イベント配信システムにおけるブローカノードおよびイベントトピック制御方法

Country Status (3)

Country Link
US (1) US20110307603A1 (ja)
JP (1) JPWO2010090027A1 (ja)
WO (1) WO2010090027A1 (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013031068A1 (ja) * 2011-09-02 2013-03-07 日本電気株式会社 イベント通知サービス方法およびシステム
WO2013145467A1 (ja) * 2012-03-26 2013-10-03 日本電気株式会社 メッセージングシステム、トピック管理装置、メッセージング方法及びプログラム
WO2014203728A1 (ja) * 2013-06-19 2014-12-24 日本電気株式会社 メッセージ制御システム、メッセージ制御装置、メッセージ制御方法及びプログラム
WO2016200595A1 (en) * 2015-06-09 2016-12-15 Intel Corporation System, apparatus and method for managing lifecycle of secure publish-subscribe system
US10412033B2 (en) 2015-02-26 2019-09-10 Fujitsu Limited Event notification method, event notification device, and storage medium

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014194452A1 (zh) * 2013-06-03 2014-12-11 华为技术有限公司 消息发布与订阅的方法及装置
TW201545510A (zh) 2014-05-30 2015-12-01 Ibm 在分散式計算系統中進行訊息路由的方法
US9871754B2 (en) * 2014-07-17 2018-01-16 Sohrab F. Modi Communicating messages between publishers and subscribers in a mesh routing network
GB2532490B (en) * 2014-11-21 2017-02-22 Ibm Publish/subscribe messaging using message structure
US9785490B2 (en) 2014-12-23 2017-10-10 Document Storage Systems, Inc. Computer readable storage media for dynamic service deployment and methods and systems for utilizing same
US10225219B2 (en) * 2016-02-22 2019-03-05 International Business Machines Corporation Message delivery in a message system
CN107145489B (zh) * 2016-03-01 2020-12-01 阿里巴巴集团控股有限公司 一种基于云平台的客户端应用的信息统计方法和装置
US11567910B2 (en) 2016-11-15 2023-01-31 Hyland Uk Operations Limited Reducing reliance on content management system resources in a content management system
US10754901B2 (en) * 2017-01-09 2020-08-25 Alfresco Software, Inc. Analytics of electronic content management systems using a staging area database
US11281731B2 (en) 2017-01-13 2022-03-22 Hyland Uk Operations Limited. Providing access with separate authentication to secure content in repositories
US11032383B2 (en) * 2017-08-15 2021-06-08 Microsoft Technology Licensing, Llc Event delivery
US10681164B2 (en) * 2018-05-03 2020-06-09 Microsoft Technology Licensing, Llc Input and output schema mappings
US11863626B2 (en) * 2021-08-31 2024-01-02 Accenture Global Solutions Limited Complex system for message downlink channel control

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003083703A1 (en) * 2002-03-28 2003-10-09 Precache, Inc. Method and apparatus for reliable and efficient content-based routing and query and response in a publish-subscribe network
JP2007234014A (ja) * 2006-02-21 2007-09-13 Nec Lab America Inc スケーラブルなコンテンツベースのイベントマルチキャストプラットフォーム

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5913040A (en) * 1995-08-22 1999-06-15 Backweb Ltd. Method and apparatus for transmitting and displaying information between a remote network and a local computer
US5870605A (en) * 1996-01-18 1999-02-09 Sun Microsystems, Inc. Middleware for enterprise information distribution
US6975876B1 (en) * 2000-11-17 2005-12-13 Thomas Cast System and method for performing throttle control in a SMPP gateway
JP2007257357A (ja) * 2006-03-23 2007-10-04 Fujitsu Ltd サーバおよび接続先サーバ切替制御方法
US7924730B1 (en) * 2006-10-30 2011-04-12 Solace Systems, Inc. Method and apparatus for operations, administration and maintenance of a network messaging layer

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003083703A1 (en) * 2002-03-28 2003-10-09 Precache, Inc. Method and apparatus for reliable and efficient content-based routing and query and response in a publish-subscribe network
JP2007234014A (ja) * 2006-02-21 2007-09-13 Nec Lab America Inc スケーラブルなコンテンツベースのイベントマルチキャストプラットフォーム

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013031068A1 (ja) * 2011-09-02 2013-03-07 日本電気株式会社 イベント通知サービス方法およびシステム
JPWO2013031068A1 (ja) * 2011-09-02 2015-03-23 日本電気株式会社 イベント通知サービス方法およびシステム
WO2013145467A1 (ja) * 2012-03-26 2013-10-03 日本電気株式会社 メッセージングシステム、トピック管理装置、メッセージング方法及びプログラム
WO2014203728A1 (ja) * 2013-06-19 2014-12-24 日本電気株式会社 メッセージ制御システム、メッセージ制御装置、メッセージ制御方法及びプログラム
US10412033B2 (en) 2015-02-26 2019-09-10 Fujitsu Limited Event notification method, event notification device, and storage medium
WO2016200595A1 (en) * 2015-06-09 2016-12-15 Intel Corporation System, apparatus and method for managing lifecycle of secure publish-subscribe system
US10230696B2 (en) 2015-06-09 2019-03-12 Intel Corporation System, apparatus and method for managing lifecycle of secure publish-subscribe system

Also Published As

Publication number Publication date
US20110307603A1 (en) 2011-12-15
JPWO2010090027A1 (ja) 2012-08-09

Similar Documents

Publication Publication Date Title
WO2010090027A1 (ja) 分散型イベント配信システムにおけるブローカノードおよびイベントトピック制御方法
US8677011B2 (en) Load distribution system, load distribution method, apparatuses constituting load distribution system, and program
EP2030414B1 (en) Self-managed distributed mediation networks
US7457257B2 (en) Apparatus, system, and method for reliable, fast, and scalable multicast message delivery in service overlay networks
JP4915848B2 (ja) オーバーレイネットワークでピア・ツー・ピアのファイル送受信を行うコンピュータプログラム
CN103795805A (zh) 基于sdn的分布式服务器负载均衡方法
Xie et al. Cutting long-tail latency of routing response in software defined networks
Kim et al. Efficacy of techniques for responsiveness in a wide-area publish/subscribe system
US20180302490A1 (en) Dynamic content delivery network (cdn) cache selection without request routing engineering
CN114978978A (zh) 一种算力资源调度方法、装置、电子设备及介质
Ascigil et al. A native content discovery mechanism for the information-centric networks
CN104917825A (zh) 一种面向实时流计算平台的负载均衡方法
CN105656786B (zh) 一种基于快、慢表的路由器查表方法
CN105745905A (zh) 在网络之内传输和存储内容
CN109922161B (zh) 动态云内容分发网络的内容分发方法、系统、设备及介质
JP6662195B2 (ja) 情報セントリックネットワーキングにおけるインテリジェント・ルーティング
JP2017073688A (ja) 通信ネットワークシステム
EP2940967B1 (en) Content-centric networking
CN105335362B (zh) 实时数据的处理方法及系统、即时处理系统
CN107404438A (zh) 网络路由方法和网络路由系统
EP2785017B1 (en) Content-centric networking
JP5598474B2 (ja) ネットワーク設計システム、ネットワーク設計方法、データ転送経路決定方法、ネットワーク設計プログラム
JP2007233700A (ja) キャッシュシステム、負荷監視サーバ、キャッシュ管理サーバ及びキャッシュサーバ。
CN105592124A (zh) 一种分布式虚拟现实系统网络构建方法
US20170251045A1 (en) Efficient file routing system

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: 10738368

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2010549406

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 13147675

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 10738368

Country of ref document: EP

Kind code of ref document: A1