Mobile scenario

The following set of experiments consider a more dynamic scenario in which subscriptions are unsubscribed and resubscribed at different brokers. The experiment is designed to reflect scenarios such as a distributed gaming application.

Figure 4.16: Tiered topology for the mobile scenario

The setup consists of a 5000 subscribers and 40 publishers distributed randomly across the brokers in the topology shown in Fig.4.16. In a distributed online game, each broker may be responsible for managing a portion of the game world, so as players move in the game, they will reconnect to different brokers in the network [45,12].

In addition, there are four subscriptions, one per region in Fig.4.16that are interested in all publications. We refer to these subscribers as monitors and they may represent interest management servers in an online game. As load conditions may trigger migrations of these interest management servers, these subscriptions may need to be resubscribed

at other brokers.

We consider two cases: one where only the monitors move at a rate of one movement every 2 minutes for a total of 6 hours, and another where in addition to the movement of the monitor subscriptions, the others subscriptions move at a rate of 60 movements per minute for the entire duration of the experiment. The non-monitor subscriptions only move within their region in the topology. In both cases, publishers scattered among the brokers do not move.

Fig. 4.17(a) shows the congestion at the core broker when only the monitor sub- scriptions move. We see that the active covering algorithm suffers from a large and growing input queue, whereas the incremental algorithm has virtually no congestion. When all subscriptions move in Fig.4.17(b), there is no significant change in the conges- tion, indicating that it is the movement of the broad monitor subscriptions that cause the congestion.

In terms of the routing tables, Fig. 4.17(c)shows that with the active covering algo- rithm the average number of entries in the broker routing tables fluctuates during the experiment. These fluctuations are a consequence of the active covering algorithm at- tempting to maintain compact routing tables when covering subscriptions are removed, particularly the monitoring subscription. This is why there the introduction of the move- ment of smaller subscriptions in Fig. 4.17(d) has little effect on the routing table size. The incremental algorithm, on the other hand, has a much smaller and more stable rout- ing state in both cases. The reason for the stable performance is that the incremental algorithm effectively maintains the monitor subscriptions even after they move away, and so after a few movements, these subscriptions exist virtually everywhere in the network and “hide” the movement of the other subscriptions. Interestingly, this means that with subscription pruning, the presence of movement can actually result in smaller routing tables than when there is no movement.

Chapter 4. Incremental filter aggregation 103

traffic, but it turns out that this traffic is distributed mostly among the more lightly loaded brokers in the system. Fig. 4.17(e) shows the average number of publications traversing each tier of brokers in the topology. In both algorithms, the brokers in the upper tiers are more heavily loaded, with the incremental algorithm imposing more traf- fic due to the false positives. However, when we isolate this false positive traffic in Fig. 4.17(f), we see that it is the more lightly loaded lower tier brokers that are required to carry most of the false positive load, helping to distribute publication load.

0 5000 10000 15000 20000 25000 30000 35000 0 2 4 6 8 10 12 14 16 18

Messages in input queue

Time (h) active covering

sub packing lazy covering selective pruning

(a) Queue size (move monitors)

0 5000 10000 15000 20000 25000 30000 35000 0 2 4 6 8 10 12 14 16 18

Messages in input queue

Time (h) active covering

lazy covering sub packing selective pruning

(b) Queue size (move all)

0 500 1000 1500 2000 2500 0 2 4 6 8 10 12 14 16 18 20

Average # routing table entries

Time (h)

lazy covering active covering sub packing selective pruning

(c) Routing table size (move monitors)

0 500 1000 1500 2000 2500 0 2 4 6 8 10 12 14 16 18 20

Average # routing table entries

Time (h)

lazy covering active covering sub packing selective pruning

(d) Routing table size (move all)

1000 2000 3000 4000 5000 6000 7000 Tier 1

(core) Tier 2 Tier 3 Tier 4

Publications

Broker tier active covering (move monitors) selective pruning (move monitors) active covering (move all) selective pruning (move all)

(e) Total publication traffic

0 5 10 15 20 25 30 35 Tier 1

(core) Tier 2 Tier 3 Tier 4

False positive publications

Broker tier

selective pruning (move monitors) selective pruning (move all)

0.1 8.4 20.3 30.0 8.5 7.2 20.3 28.5

(f) False positive publications

Chapter 5

Distributed execution engine

This chapter develops the NI ˜NOS distributed process execution engine. Section 5.1 de- scribes how a BPEL process is mapped to the NI ˜NOS system architecture, and Section5.2

presents an evaluation of this platform.

5.1

Distributed process execution

NI ˜NOS is a distributed business process execution architecture. It leverages the PADRES publish/subscribe system by transforming a BPEL business process into fine-grained publish/subscribe agents that collaborate to realize the original process. These agents interact using publish/subscribe messages and take advantage of some of the in-network processing capabilities available in PADRES. To simplify management, NI ˜NOS allows processes to be deployed and monitored in a centralized manner, again exploiting some of the decoupling properties of the PADRES publish/subscribe system.