Chapter 1 What is the Java Dynamic Management^TM Kit ?

Introduction

The Java Dynamic Management^TM Kit is a Java^TM based solution for building and distributing management intelligence into system, application, and network devices. It achieves this by providing a set of Java classes and tools that simplify the development of dynamically extensible agents.

An agent is an application which provides one or more services. Agents act as invisible assistants, alerting you to potential problems throughout the network or performing management tasks without human intervention. Agents are smart, autonomous, and dynamic. They can download management services from the management web server, pulling new management services as soon as they become available. This allows new management services to be implemented and started at any time.

How Is It Different?

Firstly, network management, under the current paradigm, is performed by management applications. These management applications are aided by agents. The agents act as interpreters and filters, sending commands to the network elements they control and collecting information about them. They are usually situated near the network elements they control, which means that these agents are limited in nature, as they contain little management intelligence and can only perform basic network management operations.

Secondly, and from a wider perspective, existing system, application, and network management systems are implemented with diverse protocols and technologies. Developers must choose a single management technology for a portion of the target market. In some cases, developers may implement multiple management technologies, in order to provide more complete coverage of their potential markets. Frequently, developers choose not to implement any management technology, in order not to be encumbered in the market.

The Java Dynamic Management Kit solves both of these problems. It is a single suite of products offering a uniform instrumentation for managing system, application, and network management systems. It is also a key enabling technology for the service-driven network. The service-driven network is a new approach to the provision of network computing that concentrates on the services you want to provide. These services range from the low-level services that manage relationships between networked devices to the value-added services you provide to end-users. These services drive your network. With the Java Dynamic Management Kit, services are incorporated directly into agents. Agents are granted permission to perform management tasks themselves, enabling management intelligence to be distributed throughout the whole network.

Thus, the Java Dynamic Management Kit opens the door to new types of lightweight, flexible management applications that can be created, deployed, enhanced or deleted in real time.

What Other Benefits Does It Offer?

The Java Dynamic Management Kit is different in that it offers more functionality than any other network management product of its kind. This unique combination of features gives the Java Dynamic Management Kit a wide domain of application.

The Java Dynamic Management Kit 4.1 supports management protocols, such as SNMP. It also uses a dynamic web-based pull mechanism enabling new services to be downloaded from the Web server at runtime. Services are not only implemented inside devices, but can also be network-based, stored as files in very simple Web pages in the same way as Java technology-based applets. This dynamic, on-demand paradigm means that it is no longer necessary to know what will need to be configured, managed, and monitored in the future or in advance of network deployment. Services can be created and downloaded as needed. Autonomous management functionality is yet another key feature of the Java Dynamic Management Kit, allowing a very large installed base to be managed.

How Does It Work?

The Java Dynamic Management Kit relies on Java Management extensions (JMX) principles to manage resources. In order to ensure that your resource is a manageable resource, you need to make sure that it adheres to the JMX specification, as the JMX instrumentation level provides a specification for implementing JMX manageable resources. Manageable resources are implemented as Managed Beans, or simply MBeans. An MBean is a manageable resources that conforms to certain design patterns and may be any resource you wish to manage (for example, an application, an implementation of a service, a device, a user, and so forth). These resources are developed in Java, or at least offer a Java wrapper, and have been instrumented so that they can be managed by JMX-compliant applications. For more information regarding MBeans, please refer to "MBeans".

The Java Dynamic Management Kit 4.1 implements the v1.0 public release 2 of the Java Management Extensions Specifications (JMX). JMX defines an architecture, design patterns, APIs, and services for application and network management, all under a single umbrella specification. The Java Dynamic Management Kit 4.0 was the first commercial product to implement the first public release of the Java Management extensions specifications (JMX). For more information regarding JMX, see the Java Management Extensions specifications document provided with the Java Dynamic Management Kit 4.1.

One of the greatest advantages of the Java Dynamic Management Kit is that it allows you to manage resources from a remote location. Thus, you can manipulate proxy objects which transparently map onto MBeans in a remote agent.

You can access all remote JMX manageable resources by:

• Getting an attribute value.

• Changing an attribute value.

• Invoking an operation.

• Receiving a notification emitted by a manageable resource.

The manager can also add new remote JMX manageable resources by:

• Using existing Java classes already loaded in the agent.

• Using new classes downloaded from an arbitrary location.

The Java Dynamic Management Kit greatly simplifies the development of management applications by providing multi-protocol communication between the manager side and the agent side. Devices or applications can be managed directly via a basic Web browser or through an existing SNMP management application. An extensible set of protocol adaptors (for example, HTTP, SNMP) and connectors (for example, HTTP/SSL, RMI) are provided to allow developers to adapt their applications to the local communication environment.

To create brand new agents, use a managed object generator (proxygen), which is provided with the Java Dynamic Management Kit. With this tool, you can create applications with automatically-generated remote access modules that handle communication support and protocol transparency. Simply put, you can create a proxy object for each JMX object you wish to manage remotely.

The Java Dynamic Management Kit 4.1 also provides a toolkit for developing SNMP agents and managers, including the mibgen compiler, which takes as input a set of SNMP MIBs and generates standard MBeans that implement the MIBs.

What Development Tools Are Provided?

The Java Dynamic Management Kit provides:

• A management architecture which supports the JMX specification. This architecture, in turn, provides a set of Web-based mechanisms for automatic propagation of management services across the network to the agents.

• An agent framework, which includes a library of reusable core agent services in the form of management components based on the JavaBeans^TM architecture. New services can be plugged in and old services removed as management requirements evolve. The services supplied include the following: monitoring, timer, mlet, relation, cascading, discovery, and filtering.

• Service creation tools, which include:

  • A managed object generator (proxygen), which helps developers to create their own specific Java technology-based client management services.

  • A Java technology-based SNMP MIB Compiler (mibgen) which takes an SNMP MIB as input and outputs a set of Managed Beans. These MBeans implement the MIBs, enabling the JDMK agent to be managed by an SNMP manager.

Key Concepts

Figure 1-1 below shows the key concepts for the Java Dynamic Management Kit 4.1.

The five keywords are MBean server, MBeans, protocol adaptors, connectors, and proxy MBeans.

Figure 1-1 Key Concepts for the Java Dynamic Management Kit 4.1

MBean Server

The MBean server, referred to as the framework in Java Dynamic Management Kit 3.x versions versions, is a registry for JMX manageable resources which are exposed to management operations in an agent. It provides a management framework with services for manipulating JMX manageable resources that is protocol-independent and information model-independent. All management operations performed on these resources are done through the MBean server management interface. You can create and manage objects by registering them within the MBean server, thus, making them visible to management applications. The MBean server includes a library of reusable core agent services in the form of manageable objects, as specified by Java Management extensions (JMX). These services include mlet, timer, monitoring and filtering.

You can register objects in the MBean server through:

• The agent application itself.

• A remote management application (through a connector or a protocol adaptor).

Any JMX manageable resource that you want to access for management operations must be registered in the MBean server. This MBean needs to be assigned a unique object name. The manager and the agent then use this object name to identify the object on which it is to perform a management operation. If you do not specify the object name explicitly, the MBean implementation may itself provide a name by default. It is possible to have multiple MBean servers within the same Java Virtual Machine (JVM)..

MBeans

JMX's instrumentation level provides standards for implementing JMX manageable resources. The instrumentation of a given manageable resource is provided by one or more Managed Beans, or MBeans (previously written m-beans). An MBean is a Java object that conforms to certain design patterns for exposing attributes and operations. These attributes and operations enable any Java Dynamic Management agent to recognize and manage the MBean. The design patterns for MBeans give the developer explicit control over how a resource, device or application will be managed. For example, attribute patterns enable you to make the distinction between a read-only and a read-write property in an MBean. The set of all attributes and operations exposed to management through the design patterns is called the management interface of an MBean. Any object that you want to make accessible through the MBean server must be represented as an MBean, including the resources you want an agent to manage, and any services that you want to provide to manage these resources. MBeans can both generate and propagate notification events to remote management applications. For more information regarding managing MBeans remotely, please refer to "Proxy MBeans" and Figure 1-5. MBeans must be developed according to the rules specified by Java Management extensions (JMX).

The JMX architecture enables you to carry out certain operations on a particular agent, by going through that agent's MBean server. These operations are as follows:

• Manage existing MBeans by:

  • Listing MBeans.

  • Enabling MBean attributes to be accessed both locally and remotely.

  • Enabling new MBeans to be instantiated and registered both locally and remotely.

  • Performing operations defined by the MBeans.

  • Receiving notifications emitted by MBeans.

  • Discovering the management interface of MBeans.

  • Allowing you to develop a generic manager.

  • Providing a view of the MBean through a specific protocol.

You can manage a new MBean as soon as it is registered within the MBean server. An MBean can be created and registered by:

• Another object within the agent.

• A remote management application connected to the agent.

MBeans can also be downloaded from a Web server and plugged into an agent at any time, in response to a demand from the management application. This is called dynamic class loading and means that future services and applications can be loaded on-the-fly and without downtime once they have been deployed on the network. For example, dynamic class loading can be used to provide rapid, low-cost delivery of end-user applications across very large bases of Java technology-enabled devices, such as desktop PC's or Web phones.

The management services supplied with the Java Dynamic Management Kit are implemented as MBeans. You can also write the MBeans representing objects you wish to manage. These objects could include the actual resources you want to manage and the value-added services provided to help manage resources. The Java Dynamic Management Kit 4.1 does not impose any restrictions on where compiled MBean classes are stored. They can be stored at any location specified in the CLASSPATH environment variable of the agent, or at a remote site.

You can develop two types of MBeans:

• Standard MBeans.

• Dynamic MBeans.

Standard MBeans

Standard MBeans are Java objects that conform to certain design patterns derived from the JavaBeans component model. Standard MBeans allow you to define your management interface as a Java Interface and this interface, in turn, defines the handles of that particular resource that are exposed to management. The methods for reading and writing the MBean's attributes and for invoking its operations are described in this management interface. Standard MBeans are defined statically, in that the elements of their management interface are defined at compilation time and cannot be controlled or altered at runtime. They are the quickest and easiest type of MBeans to implement when you want to create new MBeans for new manageable resources and where their data structure is defined in advance and is unlikely to change often.

Dynamic MBeans

Dynamic MBeans allow your application or domain specific manager to define the management interface for a resource at run time. This provides a simple way to wrap existing non-MBean style or even non-Java^TM technology based resources and offers greater flexibility than standard MBeans. Dynamic MBeans are more suited to management structures that change over time and are, hence, dynamic. Dynamic MBeans allow manageable resources to be flexible because they have a pre-defined interface which allows attributes and operations to be exposed only at run time.

Proxy MBeans

A proxy MBean (referred to as a client bean or c-bean in Java Dynamic Management Kit 3.x versions versions) represents the manager view of the managed MBean, where the manager has been developed using the remote MBean server interface. This interface makes the functionality of the MBean server available in the remote management application (also referred to as the manager) and lets the manager interact directly with the MBean server of the agent, or instantiate proxy MBeans to manipulate remote MBeans transparently.

The manager accesses an MBean by performing operations on the proxy MBean, which are then propagated to the MBean. These operations are:

• Getting or setting attributes.

• Invoking operations.

• Propagating notifications emitted by the MBean to the remote manager application.

A Proxy MBean is generated from an MBean by using the proxygen compiler, supplied with the Java Dynamic Management Kit 4.1. A proxy MBean can only be generated from a standard MBean and is created to mirror an existing MBean. Proxy MBeans are ideal when the management interface does not need to change over time, hence, where the attributes and operations available are stable.

Generic Proxy MBeans

A generic proxy MBean acts in the same manner as a proxy MBean. However, you do not generate generic proxy MBeans using the proxygen compiler as with proxy MBeans, but simply by creating a new instance of a generic proxy MBean. Generic proxy MBeans are ideal when you want to perform operations on one MBean and when you know that the attributes and operations of that MBean will change. For example, sometimes you may have write permissions on an attribute and other times you may only be able to read the attribute. This makes generic proxy MBeans the perfect solution for dynamic management systems, where an MBean's properties are likely to change at run time. Generic proxy MBeans can be used to manage either standard MBeans or dynamic MBeans, thus, can mirror both types of MBeans.

Connectors And Protocol Adaptors

Connectors and Protocol Adaptors allow agents to be accessed and managed by remote custom management applications. These applications could be outside the agent's Java Virtual Machine (JVM). This is illustrated in Figure 1-1 .

Connectors (referred to as adaptors in Java Dynamic Management Kit 3.x versions) connect the MBean server to management applications and enable MBeans to be instantiated and managed remotely. Every connector provides the same remote management interface, but through a different protocol, which allows remote management applications to connect to agents transparently through the network, regardless of the specific protocol. One or more connector clients can be connected to the MBean server, providing views through specific protocols of the MBeans instantiated and registered with the MBean server. The Java Dynamic Management Kit provides connectors for most major internet protocols (for example, HTTP/TCP, HTTP/SSL and RMI) .

A connector is composed of two parts:

• A connector server on the agent side.

• A connector client on the manager side.

The interface of the remote MBean server is implemented by the connector client. Connectors allow management applications to be ported onto a manager site, offering the same level of functionality at both the agent and manager side while ensuring seamless, transparent connectivity.

Protocol Adaptors only have a server component and provide connection between a remote management application and an agent, via a specific network protocol. From a manager side, you can view and manage all MBeans registered in the MBean server. This can be achieved by directly accessing the MBean server's interface through a given protocol. For example, a web browser accesses the HTML protocol adaptor directly and, therefore, a client of the HTML protocol adaptor is an HTML browser. Similarly, an SNMP manager accesses the SNMP adaptor directly. Therefore, a client of the SNMP adaptor is an SNMP manager.

In addition, the Java Dynamic Management Kit provides an SNMP toolkit that allows you to generate MBeans that support standard or proprietary MIB's, enabling new Java technology-based agents to be integrated into existing network infrastructures, including most SNMP-based management products.

Connectors and protocol adaptors enable management applications to:

• Find existing MBeans through their object names.

• Get or set attributes of existing MBean instances.

• Invoke operations on existing MBean instances.

• Instantiate an MBean and register the new MBean instance.

• Receive notifications from known MBeans (except through the HTML adaptor).

For an agent to be managed remotely, it must include at least one connector or protocol adaptor. However, an agent can include any number of connectors or protocol adaptors, enabling it to be managed remotely by many managers, through different protocols. Proxy MBeans, at the manager side, are used to perform management operations on the corresponding MBeans at the agent side. These MBeans are registered with the MBean server in a manner that is protocol-independent. You need to call the start method to start connectors and protocol adaptors. This allows you to specify the port number before you start them.

JMX MBean Notification Model

The management interface of an MBean allows an MBean's agent to perform control and configuration operations on the managed resources. The JMX MBean notification model allows MBeans to broadcast management notifications. Management applications and other objects register as listeners with the broadcaster MBean. The JMX MBean notification model enables a listener to register only once and still receive all different notifications that may occur in the broadcast.

Adding a local Notification Listener at the agent side

If you want to add a Notifcation Listener at the agent side, you need to call the addNotificationListener method on the MBean server. The MBean server calls the addNotificationListener on the MBean. This is illustrated in Figure 1-2.

Figure 1-2 Adding local listeners at the agent side

Adding remote Notification Listener at the manager side

You can also add a Notification Listener, addNotificationListener remotely, on the manager side. You can add a notification listener on a proxy MBean, as illustrated in Figure 1-3.

To add a listener to the manager side, call the appropriate addNotificationListener operation from proxy MBean A. This will transmit a call to the agent side and a local listener will be created internally to represent the remote listener (internal listener 1 in Figure 1-3). This local listener will then be created in the MBean server. This local listener in turn will receive and forward all notifications to the remote, internal listener. This is a protocol-dependent listener and is handled by the connector server. It is in charge of sending notifications throughout the network, from the agent side to the manager side.

Figure 1-3 Adding remote listeners at the manager side 1

You can also add a listener to the manager side directly, through the interface of the connector client. To do this, call the addNotificationListener operation from the connector client interface.

Figure 1-4 Adding remote listeners at the manager side 2

Remote Notification Mechanism

The ClientNotificationHandler public interface specifies the methods for a connector to allow a notification listener to receive notifications from a remote MBean in an agent. The ClientNotificationHandler interface is implemented by HTTP and RMI connector clients at the manager side. To forward a notification from the agent to the connector client you can configure the connector to use either push or pull mode. In pull mode, the connector server on the agent side buffers all notifications until the connector client requests, or pulls, them. The forwarding period can be set to control the frequency with which notifications are pulled from the connector server. In push mode, the connector server forwards every notification to the connector client as it is received. In the Java Dynamic Management Kit 4.1 the forwarding period is not used in push mode, notifications are forwarded immediately. Figure 1-5 illustrates this process in terms of the Pull mechanism and the Push mechanism.

The Push Mechanism

You can choose to use the Push Mechanism to push notifications from an agent to a manager. When the connectors run the Push Mechanism , the connector server forwards the notifications to the connector client as soon as they are emitted by the MBeans. For example, you can register an object at the manager side as a listener for notifications emitted by MBean A. Thus, when MBean A, at the agent side, emits a notification, the HTTP, HTTP/SSL or RMI connector forwards this notification to the connector client at the manager side.

The Pull Mechanism

You can choose to use the Pull Mechanism to forward notifications from an agent to a manager. This is useful, for instance, when the agent is unable to connect to a manager. For example, if there is a fire-wall in place between the agent side and the manager side. You can use the Pull Mechanism to pull notifications from the agent side to the manager side. When you create the remote MBean server you need to set the mechanism mode and the pull period. The pull period is the time period between pulls. Pulls occur when the HTTP, HTTP/SSL or RMI connector server at the agent side is instructed by the manager to attempt to pull notifications. Thus, the manager decides when, and how often, it wants to retrieve notifications . For example, the pull frequency could be set to try to get notifications every thirty seconds or every minute.

Figure 1-5 Remote Notification Mechanism

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.

Security

The Java Dynamic Management Kit 4.1 provides certain levels of security. The following sections provide an overview of the security services provided with the Java Dynamic Management Kit.

Connectors and Protocol Adaptors

The HTML protocol adaptor, the HTTP/SSL connector and the HTTP/TCP connector all provide login/password authentication. In this authentication scheme, the client object and the server object contain authentication information. The server side object contains an array of objects that contains authentication information for all known clients. When a client attempts to login, the login/password object that it sends is compared with the array to see whether the client is in the list of permitted clients. If the list of permitted clients is null, no client authentication is performed by the protocol adaptor; access is granted to all clients.

HTML

The HTML protocol adaptor is an HTML server that enables web browsers to access a Java Dynamic Management Kit agent through the HTTP communications protocol. When an HTML protocol adaptor is instantiated, it creates a TCP/IP socket and waits for incoming requests. By default, the HTML adaptor listens for incoming requests on port 8082. The HTML protocol adaptor provides login/password authentication.

The HTML protocol adaptor is provided as a tool for debugging and speeding up the development of agents. As such, it has certain limitations; for example it does not display complex types or multi-dimensional arrays.

Security on the manager side is handled by the HTML browser. On the server side, you need to provide a list of agents for which you want to provide security for, in order for those agents to be run securely.

HTTP/SSL

The HTTP/SSL connector enables Java managers to access a Java Dynamic Management Kit agent using HTTP over SSL (Secure Sockets Layer). SSL security is implemented in Java 2. It also allows these management applications to access an agent across proxy servers. By default, the HTTP/SSL connector listens for incoming requests on port 8084. The HTTP/SSL connector provides login/password authentication based on 'CRAM-MD5' (Challenge-Response Authentication Mechanism using MD5). The HTTP/SSL adaptor server requires client authentication by default.

The behavior of the HTTP/SSL connector is governed by the particular SSL implementation used in your applications. The cipher suites that are enabled are the defaults of the SSL implementation. The SSL implementation must be compliant with the SSL Standard Extension API.

The Java Dynamic Management Kit 4.1 is compliant with the Java Secure Socket Extension 1.0 (JSSE) API. JSSE provides an API framework and reference implementation for security protocols.

HTTP/TCP

The HTTP/TCP connector enables Java managers to access a Java Dynamic Management Kit agent using HTTP over a TCP/IP connection. It also allows these management applications to access an agent across proxy servers. By default, the HTTP/TCP adaptor listens for incoming requests on port 8081. The HTTP/TCP connector provides login/password authentication.

SNMP

The Java Dynamic Management Kit allows for two levels of security in SNMP:

• Community-based security via Access Control Lists.

• PDU encryption/filtering via the Snmp PDU factory.

The default implementation of the Snmp PDU factory does not provide any security. It only provides standard BER encoding/decoding of SNMP PDUs. However, you may replace the default Snmp PDU factory and implement encryption/filtering, based upon several factors:

• The host or community of the SNMP manager in a message before it is decoded.

• The type or contents of a request after it is decoded.

• Some encryption of the raw data.

Security on the agent side

On the agent side, the Java Dynamic Management Kit default implementation provides community-based security over Access Control List (ACL) files.

The ACL file is the default access control mechanism in the SNMP protocol adaptor. However, you may replace this default implementation with your own specification. For example, if your agent runs on a device with no file system, you could implement a mechanism which does not rely on the jdmk.acl file, by registering your own custom implementation with the SNMP protocol adaptor.

As outlined above, PDU encryption is not provided by default. However, you may provide any kind of security via PDU encryption/filtering by registering your own implementation of the Snmp PDU factory with the SNMP protocol adaptor. An example of such a secure agent is provided with Java Dynamic Management Kit 4.1.

Security on the manager side

On the manager side, a community-string can be specified via SnmpParameters upon the emission of a request. PDU encryption/decryption can also be implemented by registering your own implementation of the Snmp PDU factory, associated with either:

• The SNMP Peer, which is used for:

  • Encoding PDU requests.

  • Decoding received PDU responses.

• The SNMP Event Report Dispatcher, which is used for:

  • Decoding received PDU traps or inform requests.

  • Encoding PDU inform responses.

Mlet

As outlined in "Mlet", the Mlet service is a class and library loading service which enables agents to obtain MBeans remotely. An agent does this by loading a remote text file that contains information about the MBeans to be obtained. The location of the text file is specified by a URL and the information about each MBean to be obtained is specified in a single instance of a tag, called the MLET tag.

Mlet security

The Java Dynamic Management Kit 4.1 offers security within the Mlet service. Security differs between the JDK 1.1x and Java 2 Java runtime environments. This is explained in the following sections.

JDK 1.1x

The default behavior of the Java Virtual Machine forbids you to download classes and native libraries across the network. For secure operation of the Mlet service, the Java Dynamic Management Kit provides a simple implementation of a security manager, called com.sun.jdmk.AgentSecurityManager, which accepts incoming libraries. This security manager extends the java.lang.SecurityManager interface and you must install it as the default security manager in the Java virtual machine on which the agent is running.

Code signing must also be employed to ensure the secure operation of class and library loading services. The Mlet service allows you to load .jar files that have been signed using the javakey utility. The machine where the agent is running must have the signer's certificate in its keystore. Otherwise, the service will be unable to load .jar files signed by that particular signer. The class loader must have access to the signer's certificate, that is, the signer's certificate must be stored in the keystore on the machine on which the agent is running.

Registering the Mlet Service with the MBean server

The Mlet service is registered in one of the following ways:

• Security Mode.

  • The security mode of the Mlet Service is specified at instantiation time through a parameter passed in the Mlet constructor.

  • If no secure parameter is specified, the service assumes insecure mode to be enabled.

Java 2

Code signing must also be employed to ensure the secure operation of the class and library loading services. The Mlet service allows you to load .jar files that have been signed using the jarsigner utility. The machine where the agent is running must have the signer's certificate in its keystore. Otherwise, the service will be unable to load .jar files signed by that signer. The class loader must have access to the signer's certificate, that is, the signer's certificate must be stored in the keystore on the machine on which the agent is running.

As well as jarsigner, the java.lang.SecurityManager provides the keytool and Policy Tool utilities. You can use keytool to manage your keystore and Policy Tool to create and modify the external policy configuration files that define your installation's security policy.

The SNMP Toolkit

The Java Dynamic Management Kit 4.1 provides a toolkit for developing SNMP agents and managers. This includes:

• Developing An SNMP Agent.

• SNMP MIB (Management Information Bases) Compiler --mibgen.

• SNMP Protocol Adaptor.

• SNMP Manager API.

Developing An SNMP Agent

Developing an SMNP Agent using the Java Dynamic Management Kit involves four steps:

• Generating Java code by running mibgen on the target SNMP MIB.

• Filling in the get and set operations in the generated Java code.

• Configuring the SNMP adaptor.

• Registering the MIBs with the SNMP adaptor.

mibgen parses an SNMP MIB and generates the following:

• An MBean representing the whole MIB.

• A class mapping symbolic names with object identifiers.

• Classes representing SNMP groups/entries as MBeans (and the corresponding metadata class).

• Classes representing SNMP tables.

• Classes representing SNMP enumerated types.

MBeans generated by mibgen need to be updated to provide the definitive implementation.

SNMP agents developed with the Java Dynamic Management Kit are extensible in that MIBs can be added or removed during an agent's lifetime. They are open, as SNMP is not the only protocol available, and HTTP, HTML and RMI protocol adaptors can also be used to access the agent. They can be SNMP-only because the SNMP adaptor can be used alone and the MBean server is not mandatory.

SNMP MIB Compiler -- mibgen

The mibgen compiler takes as input a set of SNMP MIBs and generates standard MBeans that you can customize. MIBs can be expressed using SNMP v1 or SNMP v2 syntax.

The mibgen compiler is able to process:

• Tables with cross references indexed across several MIBs.

• MIBs that contain both v1 and v2 definitions.

• Nested groups.

• Default value variables.

The mibgen compiler also generates the Java source code required for representing a whole MIB in an SNMP agent. Table objects provide methods for adding and removing entries from the table.

When the whole MIB file is registered in the MBean server, all the associated groups are automatically instantiated and added to the MBean server. The Java Dynamic Management Kit 4.1 supports nested SNMP groups in MIB definitions, enabling you to register groups below groups in the MIBs.

SNMP Protocol Adaptor

The SNMP adaptor implements the SNMP v1 and v2 protocol stack. The protocol adaptor is able to manage an unlimited number of different MIBs. By providing a unified view of all the MIBs, the SNMP adaptor solves the sub-agent problem that commonly occurs with SNMP. The SNMP protocol adaptor allows MIBs to be loaded or unloaded dynamically. This enables a MIB to be loaded into, updated, and unloaded from an agent while it is running.

SNMP Manager API

The SNMP manager API is a set of Java classes that simplify the development of applications for managing SNMP agents. The agents may be developed using the Java Dynamic Management Kit 4.1, or by other means. The javax.management.snmp.manager package contains the classes and interfaces which make up the main components and functions of the API.

The Java Dynamic Management Kit 4.1 also provides an example program, showing how an SNMP proxy is used to allow a manager to access two MIBs (one local and one remote) through a single proxy agent The source code for the proxy object and the sample application is available in the Snmp/Proxy example directory located in the main examplesDir.

For more information regarding the SNMP toolkit, refer to the Java Dynamic Management Kit 4.1 Tools Reference, Java Dynamic Management Kit 4.1 Tutorial and Java Management Extensions Instrumentation and Agent Specification, v1.0 documents.

Benefits Of The Java Dynamic Management Kit

Benefits of the Java Dynamic Management Kit 4.1 include:

• Dynamic extensibility and scalability.

• Easy management of Java applications.

• Easy development of smart agents.

• Protocol independence.

Figure 1-6 Flexible and Dynamic Management Architecture

Dynamic Extensibility And Scalability

The Java Dynamic Management Kit 4.1 simplifies the development of extensible agents. An agent is able to instantiate Java classes loaded from an arbitrary location. Therefore, it is possible to extend the functionality of a running agent by making new classes available at an arbitrary location and requesting that the agent load and instantiate them.

Agents developed using the Java Dynamic Management Kit 4.1 are also scalable. MBeans can be registered and unregistered with the MBean server in an agent while it is running. By registering and un-registering new MBeans, the agent can use only what it needs when it needs it. This feature enables the size and complexity of an agent to be modified while the agent is running, without having to stop the agent.

Easy Management Of Java Applications

The MBean server enables easy management of Java applications. For a Java application to be manageable, it only needs to be modified so that it:

• Instantiates the MBean server and a connector.

• Registers the objects that, in conjunction with their states, accurately represent the application.

The only restriction is that the registered objects have to be instances of an MBean. This is not a serious restriction, as it does not force the existing design to be changed, nor does it require a fixed class inheritance scheme. When you design an MBean, you do not need to explicitly take into account the interaction of the MBean with the MBean server or the adaptors. This is handled for you by the design patterns for MBeans. An application that includes the MBean server and a connector provides remote access for management operations without the need for any further development.

Easy Development Of Smart Agents

Agents developed using the Java Dynamic Management Kit 4.1 are smart agents. A smart agent provides the services needed to process management requests. In a smart agent, much of the processing can be done locally in the agent itself, reducing the load on the network connection between the agent and the manager. This also enables an agent to continue to work if the connection between it and its manager is lost.

Protocol Independence

The design patterns for MBeans do not depend in any way on the protocol an agent uses for communicating with external applications. This is because the connectors interact with MBeans through the MBean server. New connectors (with new protocols) can be developed and used without rewriting existing MBeans or external applications. All that is required is that the new connector is able to interact with the MBean server.