Management Services

To simplify the development of agents for network, system, application, and service management, the Java Dynamic Management Kit 4.1 supplies a set of management services. These services are simply manageable resources, implemented as MBeans. These MBeans can perform management operations on other MBeans, allowing agents to manage resources.

Mlet

The management applet or Mlet service is a dynamic class loading service which enables an agent to obtain MBeans from an arbitrary network location. The Mlet service assists you in the development of dynamically extensible agents. The Mlet service enables MBeans to be downloaded dynamically from a remote URL as and when they are required. The agent does this by loading an Mlet text file, which specifies information on the MBeans to be obtained. The information on each MBean is specified in a single instance of a tag, called an MLET tag. The location of the Mlet text file is specified by the URL. When an Mlet text file is loaded, an instance of each MBean specified in the file is created and registered in the MBean server.

The Mlet service is implemented as an MBean and instantiated and registered in the MBean server. Thus, it can be used either by other MBeans or by management applications.

Query and Filtering

The Query and Filtering service helps applications select the MBeans upon which management operations are performed. The selection can be based upon:

• an object name expression -- the MBean server will use pattern-matching on the names of the MBeans. The matching features for the name components are explained in detail in the v1.0 public release 2 of the Java Management Extensions Specifications (JMX).

• the presence and values of specific attributes in object names.

  For example, a filter could select all the MBeans for which the attribute color is red. The query and filtering service is not implemented as an MBean. It is part of the infrastructure of the MBean server. The query and filter service can be used by both the agent and by the manager to perform filtered retrieval of MBeans.

  Query expressions adhere to the Java Management extensions specification and can be built to retrieve collections of MBeans in one operation. The query expressions are based on the values of MBean attributes. Query expressions are used as filters and allow you to retrieve MBeans according to their attribute values within an MBean server.

Monitoring

The Monitoring service complies with the Java Management extensions specification and introduces a particular family of MBeans, the monitor MBeans, which enable you to observe the variation over time of attribute values of other MBeans. It does this by observing numerical values and strings. These monitor MBeans observe the attributes of another MBean, referred to as the observed MBean. The observed MBean is monitored at intervals specified by the granularity period. The type of the observed attribute is one of the types supported by the specific monitor sub-class which is used. The monitor derives a value from this observation, called the derived gauge. This derived gauge is either the exact value of the observed attribute, or the difference between two consecutive observed values of this attribute.

A notification is sent by the monitor MBeans when the value of the derived gauge satisfies one of a set of conditions. Thus monitor MBeans can notify other objects of several types of changes in the target. The conditions are specified when the monitor is initialized. Monitor MBeans may also send notifications when certain error cases are encountered during the observation.

Information on the value of an attribute within an MBean may be provided by three different monitors:

• Counter monitor -- observes attributes with integer types.

• Gauge monitor -- observes attributes with integer or floating point types.

• String monitor -- observes attributes with string types.

All three types of monitor MBeans extend the abstract Monitor class, which defines common attributes and operations.

For more information regarding the Monitoring service, refer to the Java Management Extensions Instrumentation and Agent Specification, v1.0 document.

Timer

The Timer service enables you to create and send notifications at specific dates and times, thus providing a scheduling mechanism based either on a one-time notification or on a repeated, periodic notification. The notifications or notification events are sent to all objects registered to receive notification events emitted by the Timer service. You can register an object to enable it to receive notification events by adding a notification listener interface.

The Timer class manages a list of dated notification events and provides a method which allows you to add notifications to the list or remove notifications from the list. If any of the notification events in the list have dates that have passed, the Timer service either sends them immediately or discards them. You can define this behavior by setting the sendPastNotifications flag.

The Timer service provides two types of timer notifications:

• One-time notification: notification events that occur only once.

• Periodic notification: notification events that are repeated with a defined periodicity and/or number of occurrences.

This behavior is defined by the parameters passed to the Timer service when the notification event is added to the list of notifications.

For more information regarding the Timer service, refer to the Java Management extensions specifications.

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.

Discovery

The Discovery service enables you to discover Java Dynamic Management agents in a network. Only agents that have a discovery responder registered in their MBean server can be discovered using this service.

The Discovery service can be functionally divided into two parts:

• Discovery search service.

• Discovery support service.

Discovery search service

The Discovery Search service consists of a discovery client that initiates the discovery operation and a discovery responder, each instance of which supplies the return information about the agent in which it is registered. The return information is represented in the discovery client by a discovery response object.

The DiscoveryClient class provides methods to discover agents. The discovery operation is initiated by the discovery client that sends a discovery request to a multicast group and waits for responses. The agents must have a DiscoveryResponder registered in their MBean server in order to be found by the discovery service.

Discovery support service

The Discovery Support service enables you to monitor discovery responders in a multicast group. A DiscoveryMonitor object listens for discovery responder objects registering or deregistering in the multicast group. When the discovery monitor hears a discovery responder registering or deregistering, it sends a discovery responder notification to its listener. The notification is an instance of the Java class that implements the DiscoveryResponderNotification interface.

The DiscoveryMonitor is an MBean that listens for DiscoveryResponder objects registering or deregistering within a specific multicast group. A discovery responder listener is an instance of the Java class that implements the DiscoveryResponderListener interface. For example, it may be implemented to update a list of agents in the network.

Relation

The Relation service enables you to manage relations and provides query mechanisms to retrieve these relations. The Relation service is an MBean which is accessed and managed both remotely, in the remote management application, and locally. It enables you to create, access, and delete relations and create, retrieve, and delete relation types, whilst allowing you to maintain the consistency of relations where referenced MBeans are deregistered. The Relation service expects a relation to be managed by it to support the Relation interface javax.management.relation.Relation. The Relation service also expects a relation type to support the Relationtype interface javax.management.relation.RelationType. The Relation service sends a notification every time a relation is created, accessed or deleted.

You can decide to create a relation as an MBean. However, a relation does not necessarily have to be an MBean. There are two ways you can create a relation:

• Create a simple relation directly in the Relation service

  • It is not an MBean.

  • It is automatically added to the Relation service.

• Create a relation as an MBean

  • Create the relation.

  • Register the relation MBean in the MBean server.

  • Add the relation MBean to the Relation service, so that it will be considered a relation.

Using the Relation service, you can:

• Retrieve relations between MBeans.

• Retrieve specific roles within a relation: roles are lists of MBeans in a relation, eachidentified by an object name

• Define new relations.

• Remove relations.

A relation can be represented in two ways:

• As a separate whole object, referencing MBeans in roles of the relation.

• The roles of the relation can be directly part of MBeans involved in the relation, referencing other involved MBeans.

A relation is of a given relation type. A relation type provides the following role information:

• Name of the role.

• Cardinality of the role.

• Class name of the MBean to be referenced in each role.

In the Java Dynamic Management Kit, a relation is defined by a set of roles. The MBeans involved in a relation are referred to within the relationship by their object names.

Heartbeat

The Heartbeat service enables a Java Dynamic Management Kit manager to detect when the connection to a Java Dynamic Management Kit agent has been lost or terminated, and vice-versa. This is done through the specific connector part of either the manager or the agent. It is assumed that a manager has a connector client and an agent has a connector server.

The Heartbeat service is manager-driven in that all heartbeat operations are configured on the manager side. The connector client implements the HeartBeatClientHandler interface. At predefined intervals, the manager, through it's connector client, sends out a request to the agent, through the agent's connector server. The connector server listens for these requests and responds to this request. You can specify the request time intervals yourself.

Connection loss of an agent

If the connector client receives no response to the request from the connector server at the time the next request is due to be sent, the connector client may try re-sending the request. The number of times the request is resent depends on the value you set. By default, the connector client will try to resend the request six times. The time lapse (known as the HeartBeatPeriod) between retries is ten seconds. Therefore, the connector client will wait for a response for sixty seconds (HeartBeatPeriod x HeartBeatRetries). You may change the values of both the HeartBeatPeriod and HeartBeatRetries. If no response is received after the allotted time, the connector client will register the agent as being no longer alive and the connector client will clean up all its resources and specific agent information by:

• sending connection lost notifications to all registered heartbeat notification listeners.

• stopping the pull mechanism, if this is the method used for notifications.

• disconnecting the connector client.

However, if one of the retries is successful the connection to the connector server will be reestablished and a connection reestablished notification will be sent to all registered heartbeat notification listeners.

Connection loss of a manager

The connector server waits for a request to be sent from the connector client. It waits for the allocated time (HeartBeatPeriod x HeartBeatRetries). If the connector server receives no request from the connector client after this allotted time , sixty seconds by default, the particular connector client will be registered as being no longer alive and all information specific to that connector client will be cleaned up on the connector server side.