Agent Services

To simplify the development of agents for network, system, application, and service management, the Java Dynamic Management Kit supplies a set of agent services. These services are simply implemented as MBeans which perform some operations on the other MBeans in an agent. Here we list all of the provided agent services and explain each one briefly.

Query and Filtering

Querying and filtering are actually performed by the MBean server itself, not by a separate MBean. This insures that such critical services are always available. Queries and filters are performed in a single operation, whose goal is to select the MBeans upon which management operations are performed.

Usually, a management application will perform a query in order to find the MBeans which will be the target of its management requests. To select MBeans, applications may specify:

• An object name filter - This is an incomplete object name which the MBean server will try to match with the object names of all registered MBeans. All MBeans whose name matches the filter pattern will be selected. Filters may contain wildcards to select sets of MBeans, or a filter may be a complete object name which must be matched exactly. Filter rules are explained in detail in the JMX specification.

• A query expression - A query is an object that represents a set of constraints applied to the attribute of an MBean. For each of the MBeans that passes the filter, the MBean server determines if the current state of the MBean satisfies the query expression. Queries usually test for attribute values or MBean class names.

For example, a filter could select all the MBeans whose object name contains "MyMBeans" and for which the attribute named color is currently equal to "red".

The result of a query operation is a list of MBean object names, which can then be used in other management requests.

Dynamic Loading

Dynamic class loading is performed by loading management applets or m-lets containing MBeans. This service will load classes from an arbitrary network location and create the MBeans that they represent. The m-let service is defined by the JMX specification and makes it possible to create dynamically extensible agents.

A management applet is an HTML-like tag called <MLET> which specifies information about the MBeans to be loaded. It resembles the <APPLET> tag except that it will only load MBean classes. The tag contains information for downloading the class, such as the classname and the location of its class file. You may also specify any arguments to the constructor used to instantiate the MBean.

The m-let service loads a URL which identifies the file containing <MLET> tags, one for each MBean to be instantiated. The service uses a class loader to load the class files into the application's Java virtual machine. It then instantiates these classes and registers them as MBeans in the MBean server.

The m-let 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. For example, a application could make new MBean classes available at some location, generate the m-let file and instruct the m-let service in an agent to load the new MBeans.

Dynamic loading effectively pushes new functionality into agents, allowing management applications to deploy upgrades and implement new resources in their agents.

Monitoring

The monitoring service complies with the JMX specification and provides a polling mechanism based on the value of MBean attributes. There are three monitor MBeans, one for counter attributes, another for gauge-like attributes, and a third for strings. These monitors send notifications when the observed attribute meets certain conditions, mainly equalling or exceeding a threshold.

Monitor MBeans observe the variation of an MBean attribute's value over time. All monitors have a configurable granularity period that determines how often the attribute is polled. Each of the monitors has specific settings for the type of the observed attribute:

• Counter monitor - Observes an attribute of integer type that is monotonically increasing. The counter monitor has a threshold value and an offset value to detect counting intervals. The counter monitor will reset the threshold if the counter rolls over.

• Gauge monitor - Observes an attribute of integer or floating point types that fluctuates within a given range. The gauge monitor has both a high and low threshold, each of which can trigger a distinct notification. The two thresholds can also be used to avoid repeated triggering when an attribute oscillates around a threshold.

• String monitor - Observes an attribute of type String. The string monitor performs a full string comparison between the observed attribute and its match string. A string monitor sends notifications both when the string matches and when it differs at the observation time. Repeated notifications are not sent, meaning that only one notification is sent the first time the string matches or differs.

Monitor notifications contain the name of the observed MBean, the name of the observed attribute, the value which triggered the event, as well as the previous value for comparison. Using this information, listeners know which MBean triggered an event, and they don't need to access the MBean before taking the appropriate action.

Monitor MBeans may also send notifications when certain error cases are encountered during an observation.

Scheduling

The timer service is a notification broadcaster that send notifications at specific dates and times. This provides a scheduling mechanism that may be used to trigger actions in the listeners. Timer notifications may be single events, repeated events or indefinitely repeating events. The timer notifications are sent to all of the service's listeners when a timer event occurs.

The timer service manages a list of dated notifications, each with its own schedule. Users may add or remove scheduled notifications from this list at any time. When adding a notification, users provide its schedule, defined by the trigger date and repetition policy, and information which identifies the notification to its listeners. The timer service uses a single Java thread to trigger all notifications at their designated time.

The timer service may be stopped to prevent it from sending notifications. When it is started again, notifications which could not be sent while the timer was stopped are either sent immediately or discarded, as determined by the configuration of the service.

Like all other agent services, the timer is implemented as an MBean so that it may be registered in an agent and configured by remote applications. However, the timer MBean may also be used as a stand-alone object in any application that needs a simple scheduling service.

For more information regarding the timer service, please refer to the JMX specification document.

Cascading

Cascading is the term used to describe a hierarchy of agents, where management requests may be passed from a master agent to one of its subagents. A master agent connects to other agents, possibly remote, through their connector server components, much like a manager connects to an agent. In a set of cascading agents, all MBeans in a subagent are visible as if registered in their master agent. The master agent hides the physical location of subagents and provides client applications with a centralized access point.

The cascading service is an MBean which establishes a connection to one subagent. For each of the subagent's MBeans, the cascading service instantiates a mirror MBean that is registered in the master agent. The cascading service also defines a filter and query expression which together determine the set of MBeans in the subagent which are mirrored.

The mirror MBean is a sort of proxy that is specific to the cascading service. A mirror MBean exposes the same management interface as its corresponding MBean: all attributes, operations and notifications may be accessed through the mirror MBean. The mirror MBean forwards all management requests through the cascading service to the corresponding MBean in the subagent.

You may define hierarchies of agents of arbitrary complexity and depth. Because mirrored MBeans are registered MBeans, they can be mirrored again in a higher master agent. The cascading service is dynamic, meaning that mirrored MBeans are added or removed as MBeans in a subagent are added or removed.

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 and are not even aware of their master agent.

The cascading service relies on connectors components internally and may therefore be used with any of the following protocols: RMI, HTTP, or HTTPS. The user specifies the protocol and the subagent's address when configuring the cascading service.

Discovering Agents

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:

• The discovery search service which actively finds other agents.

• The discovery support service which listens for other agents to be activated.

Discovery search service

In a discovery search operation, the discovery client 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. All discovery responder which receive the discovery request send a response containing information about the connectors and protocol adaptor which are available in their agent.

Figure 2-4 The Discovery Search Service

A manager application might use the discovery search service during its initialization phase, to determine all agents that are accessible in its network environment.

Discovery Support Service

The discovery support service passively monitor discovery responders in a multicast group. When discovery responders are activated or deactivated, indicating that their agent is starting or stopping, they send a multicast message about their new state. A discovery monitor object listens for discovery responder objects starting or stopping in the multicast group.

By registering listeners with the discovery monitor, a management application may know when agents become available or unavailable. The discovery support message for an agent that is being started also contains the list of its connector and protocol adaptor.

A management application can use the discovery monitor to maintain a list of active agents and the protocols they support.

Defining Relations

The relation service defines and maintains logical relations between registered MBeans. Users define the relation type and establish the relation instance which associates any number of MBeans. The relation service provides query mechanisms to retrieve MBeans that are related to one another.

In the JMX architecture, a relation type is defined by the class and cardinality of MBeans that it associates in named roles. For example, we can say that Books and Owner are roles. Books represents any number of owned books of a given MBean class, and Owner is a single book owner of another MBean class. We might define a relation type containing these two roles and call it Personal Library: it represents the concept of book ownership.

The following diagram represents this sample relation type, as compared to the UML modeling of its corresponding association.

Figure 2-5 The Relation Model Defined by the JMX Specification

Through the relation service, users may create relation types and then create, access, and delete instances of a relation. In our example, a management application may add Book MBeans to a Personal Library relation, or it may replace the MBean in the Owner role with another MBean of the same class. All MBeans are referenced by their object name, so that a relation may be accessed from a remote application.

The relation service is notified when MBeans in a relation are deregistered, and it verifies that any relation involving that MBean still has the required cardinality. For example, if an Owner MBean were deregistered, the relation service would remove any Personal Library relations where that MBean was the designated owner.

The relation service can represent a relation instance either internally or externally. If the user defines a relation instance through the API of the relation service, the relation is represented by internal structures that are not accessible to the user. This is the simplest way to define relations because the relation service handles all coherence issues through its internal structures.

A relation instance may also be a separate MBean object that fulfills certain requirements. The user instantiates and registers these MBeans, insures that they represent a coherent relationship, and places these MBeans under the control of the relation service. This process places the responsibility of maintaining coherency on the user, but external relations have certain advantages: they may implement operations on a relation instance.

For example a Personal Library relation could be implemented by an MBean with an operation called Loan. This operation would search the list of book MBeans for a title and implement some mechanism to mark that book as being on loan. And because external relations are MBeans, these extended operations are available to remote management applications.