> Zone
> Zones restrict the behavior of routes, so you can configure complex routing paths. Zones affect topic messages, but not queue messages.
> Basic Operation
> A zone is a named set of routes. Every route belongs to a zone. A zone affects the forwarding behavior of its routes:

> ● | In a multi-hop (mhop) zone, topic messages travel along all applicable routes to all servers connected by routes within the zone.

> ● | In a one-hop (1hop) zone, topic messages travel only one hop (from the first server).

> ● | Queue messages travel only one hop, even within multi-hop zones.

> For example, Figure 34 depicts a set of servers connected by routes within a multi-hop zone, Z1. If a client sends a message to a global topic on server B, the servers forward the message to A, C, D and E (assuming there are subscribers at each of those servers). In contrast, if Z1 were a one-hop zone, B would forward the message to A, C and D—but D would not forward it E.
> Figure 34 Zones: multi-hop
> Eliminating Redundant Paths with a One-Hop Zone
> Figure 35 illustrates an enterprise with four servers:

> ● | B1 and B2 serve producers at branch offices of an enterprise.

> ● | M serves consumers at the main office, which process the messages from the branches.

> ● | R serves consumers that record messages for archiving, auditing, and backup.

> The goal is to forward messages from B1 and B2 to both M and R. The routing graph seems to contain a cycle—the path from B1 to M to B2 to R duplicates the route from B1 to R. However, since these routes belong to the one-hop zone Z2, it is impossible for messages to travel the longer path. Instead, this limitation results in the desired result—forwarding from B1 to M and R, and from B2 to M and R.
> Figure 35 Zones: one-hop
> Overlapping Zones
> A server can have routes that belong to several zones. When zones overlap at a server, the routing behavior within each zone does not limit routing in other zones. That is, when a forwarded message reaches a server with routes in several zones, the message crosses zone boundaries, and its hop count is reset to zero.
> Figure 36 illustrates an enterprise with one-hop zones connecting all the servers in each of several cities in a fully-connected graph. Zone TK connects all the servers in Tokyo; zone NY connects all the servers in New York; zone PA connects all the servers in Paris. In addition, the multi-hop zone WO connects one server in each city.
> When a client of server TK3 produces a message, it travels one hop to each of the other Tokyo servers. When the message reaches TK1, it crosses into zone WO. TK1
> forwards the message to NY1, which in turn forwards it to PA1. When the message reaches NY1, it crosses into zone NY (with hop count reset to zero); NY1 forwards it one hop to each of the other New York servers. Similarly, when the message reaches PA1, it crosses into zone PA (with hop count reset to zero); PA1 forwards it one hop to each of the other Paris servers.
> Figure 36 Zones: overlap

Copyright © TIBCO Software Inc. All Rights Reserved.