Universal Messaging 9.12 | Administration Guide | Universal Messaging Enterprise Manager | Administration Using Enterprise Manager | Realm Administration | Realm Federation
 
Realm Federation
As well as clustering technology, Universal Messaging supports the concept of a federated namespace which enables realm servers that are in different physical locations to be viewed within one logical namespace.
Note: Clustering and Realm Federation are mutually exclusive. If a realm is a member of a cluster, you cannot use the realm for federation. Similarly, if a realm is part of a federation, the realm cannot be used for clustering.
If you consider that a Universal Messaging namespace consists of a logical representation of the objects contained within the realm, such as resources and services: a federated namespace is an extension to the namespace that allows remote realms to be visible within the namespace of other realms.
For example, if we had a realm located in the UK (United Kingdom), and 2 other realms located in the US (United States) and DE (Germany), we can view the realms located in DE and US within the namespace of the UK realm. Federation allows us to access the objects within the DE and US realms from within the namespace of the UK realm.
It is possible to add realms to a Universal Messaging namespace using the Universal Messaging Administration API or by using the Enterprise Manger as described below.
Adding Realms
The first step in order to provide federation is to add the realms. Adding a realm to another realm can be achieved in 2 ways. The first way simply makes a communication connection from one realm to another, so the realms are aware of each other and can communicate. This allows you to create a channel join between these realms.
Note: For a description of the general principles involved in creating channel joins, see the section Creating Channel Joins. The description details the usage based on the Enterprise Manager, but the same general principles apply if you are using the API.
The second option also makes a new communication connection, but if you specify a 'mount point', the realm you add will also be visible within the namespace of the realm you added it to.
Mount Points
Providing a mount point for added realms is similar to the mount point used by file systems when you mount a remote file system into another. It specifies a logical name that can be used to access the resources within the mounted realm. The mount point is therefore the entry point (or reference) within the namespace for the realm's resources and services.
For example, if I have a realm in the UK, an wish to add to it a realm in the US, I could provide a mount point of '/us' when adding the US realm to the UK realm. Using the mount point of '/us', I can then access the channels within the US realm from my session with the UK realm. For example, if I wanted to find a channel from my session with the UK realm, and provided the channel name '/us/customer/sales', I would be able to get a local channel reference to the '/customer/sales' channel within the US realm.
Using the Enterprise Manager to add realms
In order to add a realm to another realm, first of all you need to select the realm node from the namespace that you wish to add the realm to. Then, right-click on the realm node to display the menu options available for a realm node. One of the menu options is labelled 'Add Realm to Namespace', clicking on this menu option will display a dialog that allows you to enter the RNAME of the realm you wish to add and an optional mountpoint. This dialog is shown in the image below.
The RNAME value in the dialog corresponds to the realm interface you wish the 2 realms to communicate using. The mount point corresponds to the point within the namespace that the realm will be referenceable.
The image below shows the namespace for a realm that has had 2 realms mounted within its namespace, called 'eur' and 'us' respectively. As you can see the resources within both the mounted realms are also displayed as part of the namespace of the 'node1' realm.
Sessions connected to the 'node1' realm now have access to three channels. These are :
*'/global/orders' which is a local channel
*'/eur/orders' which is actually a channel on another Universal Messaging Realm which has been added to this namespace under the mountpoint '/eur'
*'/us/orders' which is actually a channel on another Universal Messaging Realm which has been added to this namespace under the mountpoint '/us'
Example Use of Federation : Remote Joins
Once you have added the realms to one another, it is possible to create remote joins between the channels of the realms. This is very useful when considering the physical distance and communications available between the different realms. For example, if you wish all events published to the /customer/sales channel in the UK realm to be available on the /customer/sales channel in the US realm, one would create a join from the /customer/sales channel in the UK to the /customer/sales channel on the US realm, so all events published onto the uk channel would be sent to the us channel.
Federation and remote joins provide a huge benefit for your organization. Firstly, any consumers wishing to consume events from the uk channel would not need to do so over a WAN link, but simply subscribe to their local sales channel in the us. This reduces the required bandwidth between the us and uk for your organization, since the data is only sent by the source realm once to the joined channel in the us, as opposed to 1...n times where n is the number of consumers in the us. Remote joins are much more efficient in this respect, and ensure the data is available as close (physically) to the consumers as possible.
Note: For a description of the general principles involved in creating channel joins, see the section Creating Channel Joins. The description details the usage based on the Enterprise Manager, but the same general principles apply if you are using the API.

Copyright © 2013-2019 | Software AG, Darmstadt, Germany and/or Software AG USA, Inc., Reston, VA, USA, and/or its subsidiaries and/or its affiliates and/or their licensors.