Java Dynamic Management Kit 3.2 Programming Guide | ||||
---|---|---|---|---|
![]() | ![]() | ![]() | ![]() |
Cascading agents enable you to use Java Dynamic Management Kit to implement a hierarchy of master agents and subagents. A master agent connects to other agents, possibly remote, through their adaptor server. In a set of cascading agents, the m-beans in a subagent are visible as if registered in its master agent. The master agent hides the physical location of subagents and provides client applications with a centralized access point.
The cascading mechanism only works in one direction: while master agents can manipulate objects in their subagents, subagents have no visibility of their master agent. Cascading is controlled by the master agent: it can choose to make its subagents visible or not to the managing application. However, the cascading mechanism is implemented as an m-bean, so the managing client can control the whole hierarchy of agents.
Cascading makes several agents and their m-beans all visible at the same level. For this reason, the domain part of object names on each of the subagents must be chosen to avoid naming space conflict. All m-beans in a cascade hierarchy must have unique object names.
The cascading agent service can be implemented using the following adaptors:
RMI
HTTP/UDP
HTTP/TCP
HTTP/SSL
IIOP
A master agent instantiates a remote agent object for each subagent it communicates with. A remote agent object uses the adaptor client API to communicate with a subagent. When a client application sends a management request to a master agent, the master agent's framework applies that request to all of its locally instantiated m-beans and repeats the request to any active subagents. From master agent to subagent, the request is applied to all remote m-beans in an active cascading hierarchy.
For example, a management client may request the list of all object names with a certain class part. The master agent will pass this request along to any subagents visible through an active remote agent object. The responses received will be combined with the list of local m-beans with the given class part, and the result will be returned to the manager. From the manager's point of view, all m-beans are present in the master agent.
Figure 16-1 shows a master agent and two subagents. In this example, the cascading service is inactive. A manager connected to the master agent cannot "see" the objects instantiated in the subagents. Any management operations on the master agent will not concern the objects in the subagents.
However, the manager can control the remote agent objects. Let us suppose the manager decides to activate both remote agents. Figure 16-2 shows the same agents, but now, the cascading service is active. The manager is still only connected to the master agent, however, management operations will be propagated down the hierarchy and apply to the objects in the subagents. The propagation is transparent to the manager to which all objects appear to be in the master agent.
It is important to understand that the objects only appear to be in a master agent from the manager's perspective. All m-bean instances remain in the agent where they were created and registered. This means that objects from different subagents cannot interact, even if they appear to be in the same agent.
However, m-beans in a master agent can perform operations on those in a subagent. When an m-bean interacts with its framework, it also has a visibility of any subagents which are represented by an active remote agent in the same framework. This visibility also extends to any cascading hierarchy implemented by the subagent. In general, m-beans can operate on any subagent hierarchy rooted in their own framework. However, there is never any "upwards" visibility, from a subagent to a master agent.
The remote agent object is an instance of the com.sun.jaw.impl.agent.services.cascading.RemoteAgent Java class. Example 16-1 shows how to instantiate and activate a remote agent within a master agent using the RMI protocol. Since the remote agent is registered in the framework, Java Dynamic Management applications connected to this master agent will be able to activate and deactivate the cascading functionality.
Example 16-1. Instantiating a Remote Agent
String host = InetAddress.getLocalHost().getHostName(); String port = "1099"; String protocol = "rmi"; RemoteAgent ra = (RemoteAgent) cmf.newObject( "com.sun.jaw.impl.agent.services.cascading.RemoteAgent", cmf.getDomain() + "com.sun.jaw.impl.agent.services.cascading.RemoteAgentMO" + ".host=" + host + ",port=" + port + ",protocol=" + protocol ); // Activates the cascading agent service ra.performStart(); |
When using the cascading agent service with RMI adaptors, you must run the rmiregistry command for each additional RMI adaptor on the master agent machine, specifying the port number that the additional adaptor will use:
prompt% rmiregistry portNumber |
You must also run the rmiregistry command on the master agent machine if the subagent does not use the default RMI port number (1099). In this case, specify the port number that the subagent is using.
Since the remote agent exposes an adaptor client within the agent, the agent must have access to the c-beans of all m-beans in its cascading hierarchy. This implies that all c-bean interfaces and stub classes must be available somewhere in the path defined by the agent's CLASSPATH environment variable.
If a c-bean cannot be found in the master agent's CLASSPATH, then the corresponding m-bean will not be made visible. This provides robustness by not generating an error when the cascading architecture is not properly configured. However, the error information is available in debugging messages. See Setting the Class Path in Chapter 9 for more information.
![]() | ![]() | ![]() |
Discovery Service | ![]() | Interoperating With SNMP |