Zones

Overview of Zones

Zones provide a logical grouping of one or more Realms which maintain active connections to each other. Realms can be a member of zero or one zone, but a realm cannot be a member of more than one zone . Realms within the same zone will forward published channel messages to other members of the same zone, if there is necessary interest on corresponding nodes.
Note: The forwarding of messages between realms in a zone applies only to messages on channels, not to messages on queues. Messages on queues are not forwarded between realms in a zone.

Clusters can also be members of zones. In this case, the cluster as a whole is treated as a single member of a zone. Members of a zone should be well-connected, i.e., always connected to all other zone members, however this is not enforced.

Zones are uniquely identifiable, and two disparate zones with the same name can co-exist.

Interest Propagation

Using zones, Universal Messaging can deliver channel messages between realms and clusters when interest from one realm or cluster has been registered on another realm or cluster in the same zone. Here the term "interest" means that the realm wishes to receive a copy of messages that are sent originally to a channel of the same name on another realm within the same zone. This "interest" only arises on a realm when a client subscribes to a channel on the realm; if there is no such client on the realm, there is no "interested" client, so no interest propagation occurs.

A realm will forward its own interest in a particular channel to all realms directly connected to it within the same zone. When a realm receives a notification of interest from another realm within the same zone it will add an entry within its interest manager and begin to directly forward messages to this realm.

The mechanism within any given zone is as follows. The description assumes that there are several realms in the zone; we'll refer to the realm you are working on as the source realm and all the other realms as remote realms:

  • When a client subscribes to a channel on the source realm, the source realm indicates to the remote realms that it wishes to receive any messages sent to the channel on the remote realms. In other words, the source realm propagates interest for this channel to the remote realms.
  • Once interest from the source is registered on the remote realms, messages published to the channel on any of the remote realms in the zone will be propagated to the source realm.

Example: Propagating Interest within a Zone

In the example above we see that a client has subscribed to a channel on realm A. The Interest Manager for realm A forwards a notification to all other realms within the same zone (realm B and realm C). Realm B and realm C now know that they should begin to forward messages they receive for this channel to realm A.

As both realm B and realm C are members of the same zone they do not propagate this interest any further. Therefore realm B knows that realm C has no local subscriber and will not forward messages to realm C. Similarly, realm C will not forward messages to realm B.

Propagating Interest between Zones

You can propagate interest between zones using by manually creating static joins, for example:

Note: Currently, a realm cannot be a member of more than one zone, so you cannot define a realm that is common to two zones. Therefore interest propagation between two zones using a common realm is not supported.

Administration of Zones

You can perform the following functions using both the Administration API and the Enterprise Manager:

  • Create a new zone
  • Add a realm to a zone
  • Remove a realm from a zone
  • List the zone which a realm currently belongs to

Administration of Zones using the Administrative API

The Administration API provides classes for performing the required administrative functions. These classes are summarized in the following outline example:

public class nRealmNode {
    ....
    public nZoneManager getZoneManager();
    ....
}

public class nZoneManager {
    ...
    public static nZone createZone(String zoneName);
    public boolean joinZone(nZone zone);
    public boolean leaveZone(nZone zone);
    public nZone getZone();
    ...
} 

Administration of Zones using the Enterprise Manager

The Enterprise Manager provides menu items for performing the required administrative functions.

When you select a realm in the Enterprise Manager, you can perform the following functions within the context of the realm:

  • Specify that the realm is a member of the given zone. If the zone does not exist already, it is created as part of this process. Currently, a realm cannot be a member of more than one zone.
  • Remove the realm from a zone. If there are no more realms in the zone, the zone continues to exist, but its functionality is deactivated.
  • Check which zone the realm belongs to.

See the documentation of the Enterprise Manager for details.

Examples of Message Propagation

Example 1

  1. A message on a given channel is published to Realm F in Zone B.
  2. Servers D and E in the same zone have registered interest in the channel, so Server F forwards the message to these servers.
  3. Realm E has a local subscriber, so server E delivers the message to the local subscriber. Realm E has no static joins so will not forward the message any further.
  4. Realm D has a static join to Realm B. It will forward this message over the static join to Realm B.
  5. Realm B receives the message through a static join and therefore forwards the message to all members of its own zone that have registered interest.
  6. Realm A has registered interest as it has a local subscriber. It therefore receives this message and delivers it to the local subscriber. There are no other realms with interest so it does not forward the message further.

Example 2

  1. A message is published to a channel on Realm I in Zone C.
  2. Realm I forwards the message to all realms in the same zone where interest has been registered (Realm H, Realm G), as it is the initial receiver of the message.
  3. Realm H forwards the received message to its subscriber. Server H has no statically configured joins so does not forward the message any further.
  4. Realm G receives the message and forwards it over the static joins to Realm C in Zone A and Realm D in Zone B.
  5. Realm C receives the message and forwards it to all members in Zone A that have interest.
  6. Realm A and Realm B deliver the message to their subscribers.
  7. Realm D receives the message and forwards it to all members of Zone B that have interest. Therefore it sends the message to Realm F. Realm E has no interest and therefore it does not forward the message to this server.
  8. Realm F delivers the message to its subscriber.