Cascading

Cascading agents enable you to use Java Dynamic Management Kit to implement a hierarchy of master agents and sub-agents. A master agent connects to other agents, possibly remote, through their connector server. In a set of cascading agents, the MBeans in a sub-agent are visible as if registered in their master agent. The master agent hides the physical location of sub-agents and provides client applications with a centralized access point.

The Cascading service provides cascading agents, which enable you to implement a hierarchy of master agents and sub-agents. In a set of cascading agents, the MBeans in a sub-agent are visible as if registered in the master agent. The cascading mechanism only works in one direction: while master agents can manipulate objects in their sub-agents, sub-agents have no visibility of their master agent. Cascading is controlled by the master agent and it can choose to make its sub-agents visible or not to the managing application.

The master agent:

• Hides the physical location of sub-agents and provides client applications with a centralized access point.

• Filters the MBeans it wants to cascade: for example, MBeans that belong to a certain domain.

• Cascades any sub-agent in the same manner, independently of the specific communication protocol used.

The Cascading service is implemented by an MBean called a CascadingAgent. For each sub-agent that the master agent communicates with, a CascadingAgent MBean should be registered in the master agent. Once you have registered the cascading agent, you need to instantiate all the MBeans in the sub-agents and start all communications between the master agent and its sub-agents. This is done using the start method. The cascading hierarchy is dynamic, enabling you to have as many levels as you require.

You can also decide which MBeans you want to cascade to, by means of filtering.

This filter contains:

• An ObjectName pattern in order to filter the MBeans in the sub-agents based on their ObjectNames.

• A QueryExp object for filtering based upon values of the MBeans' attributes, classes, and so on.

This filtering is defined when creating each CascadingAgent MBean. Only the MBeans that satisfy these filtering criteria will be seen as MBeans present in the master agent. Once the CascadingAgent MBean is active, all the required MBeans of the sub-agents will be seen as local MBeans, as if they were registered in the master agent. For this reason, the domain part of object names on each of the sub-agents must be chosen to avoid naming space conflict. All MBeans in a cascade hierarchy must have unique object names.

The CascadingAgent MBean must use a communication protocol to communicate with the sub-agent it needs to cascade. You must specify the protocol and the address of the cascading agent (sub-agent) you want to contact when you create the CascadingAgent MBean. The MBeans in the sub-agents are represented in the master agent by special dynamic MBeans. They behave as generic Proxy MBeans in a manager which represents MBeans in a cascading agent and are known as CascadeGenericProxy MBeans. For each cascading MBean, a new CascadeGenericProxy MBean is created and registered in the master agent. All the operations performed on CascadeGenericProxy MBeans in the master agent are transferred to the corresponding MBeans in the sub-agents. All notification events emitted by MBeans in sub-agents are received in the master agent. The unregistration of an MBean in a sub-agent results in the unregistration of the MBean it represents in the master agent, and vice versa.