test

Getting Started with the Java Dynamic Management Kit 5.0

Chapter 2 Architectural Components

This chapter presents the components of the Java Dynamic Management Kit (DMK) and explains how you can use them in a complete management solution.

This chapter contains the following sections:

MBeans

The instrumentation level of the JMX specification defines standards for making resources manageable in the Java programming language. The instrumentation of a manageable resource is provided by one or more management beans, or MBeans. An MBean is a Java object that exposes attributes and operations for management. 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 is managed. For example, attribute patterns enable you to distinguish 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 resource that you want to make accessible through an agent can be represented as an MBean. Both the agent application and remote managers can access MBeans in an agent. MBeans can generate notification events that are sent to all local or remote listeners. For more information about managing MBeans remotely, see Communication Components.

You can make resource accessible through Java DMK agents even if they are not instrumented as MBeans, by using MBean Interceptors. See MBean Interceptors for details.

You can also download MBeans from a web server and plug them 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 any downtime. 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 PCs or Web phones.

There are four types of 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 straightforwardly in a Java interface. The method names of this interface determine getters and setters for attributes and the names of operations. The class implementation of this interface contains the equivalent methods for reading and writing the MBean's attributes and for invoking its operations, respectively.

The management interface of a standard MBean is static, and this interface is exposed statically. Standard MBeans are static because the management interface is defined by the source code of the Java interface. Attribute and operation names are determined at compilation time and cannot be altered at runtime. Changes to the interface must be recompiled.

Standard MBeans are the quickest and easiest type of MBeans to implement. They are suited to creating MBeans for new manageable resources and for data structures that are defined in advance and are unlikely to change often.

Dynamic MBeans

Dynamic MBeans do not have getter and setter methods for each attribute and operation. Instead, they have generic methods for getting or setting an attribute by name, and for invoking operations by name. These methods are common to all dynamic MBeans and are defined by the DynamicMBean interface.

The management interface is determined by the set of attribute and operation names to which these methods respond. The getMBeanInfo method of the DynamicMBean interface must also return a data structure that describes the management interface. This metadata contains the attribute and operation names, their types, and the notifications that can be sent if the MBean is a broadcaster.

Dynamic MBeans provide a simple way to wrap existing Java objects that do not follow the design patterns for standard MBeans. You can also implement them to access resources that are not based on Java technology by using the Java Native Interface (JNI).

The management interface of a dynamic MBean is static, but this interface is exposed dynamically when the MBean server calls its getMBeanInfo method. The implementation of a dynamic MBean can be complex, for example, if it determines its own management interface based on existing conditions when it is instantiated.

Model MBeans

A model MBean is a generic, configurable, dynamic MBean that you can use to instrument a resource at runtime. A model MBean is an MBean template. The caller tells the model MBean what management interface to expose. The caller also determines how attributes and operations are implemented, by designating a target object on which attribute access and operation invocation are actually performed.

The model MBean implementation class is mandated by the JMX specification and therefore is always available for instantiation in an agent. Management applications can use model MBeans to instrument resources on the fly.

To instrument a resource and expose it dynamically, you need to:

The management interface of a model MBean is dynamic, and it is also exposed dynamically. The application that configures a model MBean can modify its management interface at any time. It can also change its implementation by designating a new target object.

Management applications access all types of MBeans in the same manner, and most applications are not aware of the various MBean types. However, if a manager understands model MBeans, it can obtain additional management information about the managed resource. This information includes behavioral and runtime metadata that is specific to model MBeans.

Open MBeans

Open MBeans allow management applications and the users to understand and use new managed objects as they are discovered at runtime. These MBeans are called open because they rely on a small, predefined set of universal Java types and they advertise their functionality.

Management applications and open MBeans are thus able to share and use management data and operations at runtime without requiring the recompiling, reassembly, or expensive dynamic linking of management applications. In the same way, human operators can use the newly discovered managed object intelligently without having to consult additional documentation.

To provide its own description to management applications, an open MBean must be a dynamic MBean. Beyond the DynamicMBean interface, there is no corresponding open interface that must be implemented. Instead, an MBean earns its openness by providing a descriptively rich metadata and by using only certain predefined data types in its management interface.

An open MBean has attributes, operations, constructors, and possibly notifications like any other MBeans. It is a dynamic MBean with the same behavior and all of the same functionality. It also has the responsibility of providing its own description. However, all of the object types that the MBean manipulates, its attribute types, its operation parameters and return types, and its constructor parameters, must belong to a defined set of basic data types. It is the developer's responsibility to implement the open MBean fully by using these data types only.

An MBean indicates whether it is open or not through the MBeanInfo object it returns. Open MBeans return an OpenMBeanInfo interface. This interface is implemented by OpenMBeanInfoSupport, which inherits from MBeanInfo. If an MBean is marked as open in this manner, it is a guarantee that a management application compliant with the JMX specification can immediately make use of all attributes and operations without requiring additional classes.

Since open MBeans are also dynamic MBeans and they provide their own description, the MBean server does not check the accuracy of the OpenMBeanInfo object. The developer of an open MBean must guarantee that the management interface relies on the basic data types and provides a rich, human-readable description. As a rule, the description provided by the various parts of an open MBean must be suitable for displaying to a user through a graphical user interface (GUI).

The MBean Server

The MBean server is a registry for JMX manageable resources, which it exposes to management requests. It provides a protocol-independent and information model independent framework with services for manipulating JMX manageable resources.

If you choose to register a resource's MBean with the MBean server, it becomes visible to management applications and exposed to management requests. The MBean server makes no distinction between the types of MBeans. Standard, dynamic, model and open MBeans are managed in exactly the same manner.

You can register objects in the MBean server through:

The MBean server responds to the following management requests on registered MBeans:

The MBean server never provides the programmatic reference of its MBeans. It treats an MBean as an abstraction of a management entity, not as a programmatic object. All management requests are handled by the MBean server, which dispatches them to the appropriate MBean, thus ensuring the coherence in an agent.

An MBean is identified by a unique symbolic name, called its object name. The object name can be assigned either by the entity registering the MBean or by the MBean itself, if its implementation has been designed to provide one. Managers give this object name to designate the target of their management requests.

It is possible to have multiple MBean servers within the same Java virtual machine, each managing a set of resources.

Communication Components

Connectors and protocol adaptors interact with the Java communication objects such as sockets to establish connections and respond to requests from other host machines. Connectors and protocol adaptors enable agents to be accessed and managed by remote management applications.

An agent can contain any number of connectors or protocol adaptors, enabling it to be managed simultaneously by several managers, through different protocols. The agent application is responsible for coordinating all the ports on which it intends to receive requests.

Connectors

Connectors establish a point-to-point connection between an agent and a management application, each running in a separate Java virtual machine. The Java DMK provides connectors for the HTTP/TCP, HTTP/SSL, and RMI protocols. Every connector provides the same remote API, which frees management applications from any protocol dependency.

A connector is composed of two parts:

Therefore, a Java application that instantiates a connector client can perform all management operations that are available through the agent's MBean server.

In the client-server model, it is the connector client that initiates all connections and all management requests. An agent is identified by an address that contains the agent's hostname and port number. The target agent must contain an active connector server for the desired protocol. The address object is protocol-specific and can contain additional information needed for a given protocol.

The connector client uses this address to establish a connection with its corresponding connector server. A connector client can establish only one connection at a time. This implies that a manager instantiates one connector client for each agent it contacts. The management application must wait for the connector to be online, meaning that a connection is established and ready to send requests.

Management applications can then invoke one of the methods of the connector client to issue a request. These methods have parameters that define the object name of the MBean and the attribute or operation name to which the request applies. If the request has a response, it will be returned to the caller.

A connector hides all the details of the protocol encoding from the Java applications. Agent and manager exchange management requests and responses based on the JMX architecture. The underlying encoding is hidden and is not accessible to the applications.

Connector Heartbeat

All connectors provided in the Java DMK implement a heartbeat mechanism. The heartbeat enables both the agent and manager applications to detect when a connection is lost, either because the communication channel is interrupted or because one of the applications has been stopped.

The connector client and connector server components exchange heartbeat messages periodically. When a heartbeat is not returned or an expected heartbeat is not received, both components begin a retry and timeout period. If the connection is not reestablished, both the connector client and the connector server free the resources allocated for that connection.

The heartbeat mechanism is only configurable on the manager side, the connector server simply replies to heartbeats. The manager application can set the retry policy as determined by the heartbeat period and the number of retries. The manager application can also register for heartbeat notifications that are sent whenever a connection is established, retried, reestablished, lost, or terminated.

Proxy MBeans

A proxy MBean is an object that represents a specific MBean instance and that makes it easier to access that MBean. A management application instantiates a proxy so that it has a simple handle on a registered MBean, instead of needing to access the MBean server.

The manager can access MBeans by invoking the methods of their proxy object. The proxy formulates the corresponding management request to the MBean server. The operations are those that are possible on an MBean:

Because dynamic MBeans expose their management interface only at runtime, they cannot have a specific proxy MBean. Instead they have a generic proxy whose methods have an extra parameter to specify the attribute or operation name. Figure 2–1 shows management components interacting with both standard and dynamic MBeans through both standard and generic proxies. Notice that a generic proxy can also represent a standard MBean.

Figure 2–1 Binding Proxy MBeans to Local and Remote Servers

Binding proxy MBeans to Local and Remote Servers

Figure 2–1 also shows that proxies can be instantiated either locally in the agent or remotely in the manager. Since the MBean server and the connector client have the same API, management requests to either of them are identical. This creates a symmetry so that the same management components can be instantiated either in the agent or in the manager application. This feature contributes to the scalability of Java dynamic management applications.

A standard proxy is generated from a standard MBean using the proxygen compiler, supplied with the Java DMK. The resulting class then needs to be loaded wherever the proxy will be instantiated. Generic proxies provide less of an abstraction but do not need to be generated. They are part of the Java DMK libraries and are thus always available.

MBean Interceptors

As stated previously, the Java DMK does not require every MBean in a Java DMK agent to be represented by a Java object in that agent. MBean interceptors enable you to intercept operations on MBeans and handle them arbitrarily. Handling them can involve handing the request to other interceptors, possibly after logging or authenticating them for security. Alternatively, handling can involve processing the request directly. For example, with very volatile MBeans, direct handling avoids having to keep up with the creation and deletion of objects. Instead, the managed object is effectively synthesized when there is a request on it, which for volatile objects happens much less often than creation and deletion.

Protocol Adaptors

Protocol adaptors have only a server component and provide a view of an agent and its MBeans through a different protocol. They can also translate requests formulated in this protocol into management requests on the JMX agent. The view of the agent and the range of possible requests depends upon the given protocol.

For example, Java DMK provides an HTML adaptor that presents the agent and its MBeans as HTML pages viewable in any web browser. Because the HTML protocol is text based, only data types that have a string representation can be viewed through the HTML adaptor. However, this is sufficient to access most MBeans, view their attributes, and invoke their operations.

Due to limitations of the chosen protocol, adaptors have the following limitations:

The SNMP adaptor provided in the Java DMK is limited by the constraints of SNMP. The richness of the JMX architecture cannot be translated into SNMP, but all the operations of SNMP can be imitated by methods of the MBean server. This translation requires a structure of MBeans that imitates the MIB. While an SNMP manager cannot access the full potential of the JMX agent, the MBeans representing the MIB are available for other managers to access and incorporate into their management systems.

In general, a protocol adaptor tries to map the elements of the JMX architecture into the structures provided by the given protocol. There is no guarantee that this mapping is complete or fully accurate. However, specification efforts are currently under way to define fully and standardize the mappings between the JMX architecture and the most widespread management protocols such as SNMP, CORBA, TMN, and CIM/WBEM. For more details, see the Java Community ProcessSM web site at:

http://java.sun.com/aboutJava/communityprocess/

The Notification Model

The JMX architecture defines a notification model that enables MBeans to broadcast notifications. Management applications and other objects register as listeners with the broadcaster MBean. In this way, MBeans can signal asynchronous events to any interested parties.

The JMX notification model enables a listener to register only once and still receive all the various notifications that an MBean can broadcast. A listener object can also register with any number of broadcasters, but it must then sort all notifications it receives according to their source.

Local Notification Listeners

In the simplest case, listeners are objects in the same application as the broadcaster MBean. The listener is registered by calling the addNotificationListener method on the MBean. The MBean server exposes the same method so that listeners can also be added to an MBean identified by its symbolic name.

In Figure 2–2, one listener has registered directly with the MBean and another has registered through the MBean server. The end result is the same, and both listeners will receive the same notifications directly from the broadcaster MBean.

Figure 2–2 Adding Local Listeners on the Agent Side

Adding Local Listeners on the Agent Side

Remote Notification Listeners

The connector client interface also exposes the addNotificationListener method so that notifications can be received in remote management applications. Standard proxies expose this method as well and transmit any listener registrations through the connector client.

Listeners do not need to be aware that they are remote. The connector transmits registration requests and forwards notifications back to the listeners. The whole process is transparent to the listener and to the management components.

As shown in Figure 2–3, the connector components implement a complex mechanism for registering remote listeners and forwarding notifications. Because notifications are based on the Java event model, broadcasters cannot send notifications outside their Java virtual machine. So the connector server instantiates local listeners that receive all notifications and place them in a cache buffer, waiting to be sent to the manager application. The enables the connector to avoid saturating the communication layer in case of a burst of notifications.

Figure 2–3 Adding Remote Listeners on the Manager Side

Adding Remote Listeners on the Manager Side

Notifications either can be pushed from the agent to the connector client as they are received, or they can be pulled periodically at the client's request. The pushing mechanism is the simplest, but the pull mechanism can be used to group notifications and reduce bandwidth usage. In either case the connector client then acts as a broadcaster and sends the notifications to their intended listeners.

The management application configures the forwarding mechanism through the connector client. The manager can choose either push or pull mode, and in pull mode it can set the pull interval and the caching policy. The manager should set these parameters according to the notification emission rate, to avoid saturating the communication layer and yet receive notifications in a timely manner.

Agent Services

To simplify the development of agents for network, system, application, and service management, the Java DMK supplies a set of agent services. These services are implemented as MBeans that perform some operations on the other MBeans in an agent. All the provided agent services are briefly explained in this section.

Querying and Filtering

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

Usually, a management application performs a query to find the MBeans that will be the target of its management requests. To select MBeans, applications can specify:

For example, a filter could select all the MBeans whose object names contain 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 loads 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> that specifies information about the MBeans to be loaded. It resembles the <APPLET> tag, except that it loads only MBean classes. The tag contains information for downloading the class, such as the classname and the location of its class file. You can also specify any arguments to the constructor that is used to instantiate the MBean.

The m-let service loads a URL that 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, an application could make new MBean classes available at a 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 equaling 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 monitor has specific settings for the type of the observed attribute:

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

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

Scheduling

The timer service is a notification broadcaster that sends notifications at specific dates and times. This provides a scheduling mechanism that can be used to trigger actions in the listeners. Timer notifications can 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 can 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 that identifies the notification to its listeners. The timer service uses a single Java thread to trigger all notifications at their designated time.

You can stop the timer service to prevent it from sending notifications. When you start it again, notifications that 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 can be registered in an agent and configured by remote applications. However, the timer MBean can also be used as a stand-alone object in any application that needs a simple scheduling service.

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

Cascading

Cascading is the term used to describe a hierarchy of agents, where management requests are 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 that 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 that together determine the set of MBeans in the subagent that is 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 can be accessed through the mirror MBean, which forwards all management requests through the cascading service to the corresponding MBean in the subagent.

You can 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 works only 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 connector components internally and can therefore be used with the RMI, HTTP, or HTTPS protocols. The user specifies the protocol and the subagent's address when configuring the cascading service.

Discovering Agents

With the discovery service you can discover Java dynamic management agents in a network. Only agents that have a discovery responder registered in their MBean server can be discovered when you use this service.

The discovery service can be functionally divided into two parts:

Discovery Search Service

In a discovery search operation the discovery client sends a discovery request to a multicast group and waits for responses. To be found by the discovery service, the agents must have a DiscoveryResponder registered in their MBean server. All discovery responders that receive the discovery request send a response containing information about the connectors and protocol adaptor that are available in their agent.

Figure 2–4 The Discovery Search Service

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 monitors 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 knows when agents become available or unavailable. The discovery support message for an agent that is being started also lists 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 that 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, if 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. You could define a relation type containing these two roles and call it Personal Library. This represents the concept of book ownership.

Figure 2–5 compares this sample relation type to the unified modeling language (UML) model of its corresponding association.

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

The Relation Model Defined by the JMX Specification

Through the relation service, users can create relation types and then create, access, and delete instances of a relation. In the preceding example, a management application can add Book MBeans to a Personal Library relation, or it can 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 can be accessed from a remote application. An MBean does not need to know what relations it participates in. New kinds of relations can be added to an agent without having to modify the code of the MBeans they link.

The relation service is notified when MBeans in a relation are unregistered, and it verifies that any relation involving that MBean still has the required cardinality. For example, if an Owner MBean were unregistered, 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 can also be a separate MBean object that fulfills certain requirements. The user instantiates and registers these MBeans, ensures 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 can 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.

Security

The Java DMK provides several security mechanisms to protect your agent applications. As is always the case, simple security that enforces management privileges is relatively easy to implement, whereas full security against mischievous attacks requires a more sophisticated implementation and deployment scheme. However, in all cases the security mechanisms preserve the Java dynamic management architecture and management model.

The following sections give an overview of the security features provided through components of the Java DMK.

Password Protection

Password-based protection restricts client access to agent applications. All HTTP-based communication provides login- and password- based authentication, as does the SNMP protocol adaptor.

Password protection can be used to associate managers with a set of privileges that determine access right to agents. The user is free to implement whatever access policy is needed on top of the password authentication mechanism. The SNMP protocols also provide password protection to agent applications. See SNMPv1 and SNMPv2 Security and SNMPv3 Security.

HTTP Connectors

Both HTTP and HTTPS connectors provide login and password-based authentication. The server component contains the list of allowed login identifiers and their passwords. Management applications must specify the login and password information in the address object when establishing a connection.

If the list of recognized clients is empty, the default behavior is to perform no authentication and grant access to all clients.

HTML Protocol Adaptor

Because the HTML protocol adaptor relies on HTTP messaging, it also implements password protection. The agent application specifies the list of allowed login identifiers and their passwords when creating the HTML adaptor. When password protection is enabled in HTML, the web browser usually displays a dialog box for users to enter their login and passwords.

In general, the security mechanisms of a protocol adaptor depend on the security features of the underlying protocol. The ability to use security mechanisms also depends on the functionality of the management console. If your web browser does not support the password dialog, you cannot access a password-protected HTML adaptor.

Context Checking

Whereas password protection grants all-or-nothing access, context checking enables the agent application to filter each management request individually. Context checking can be associated with password protection to provide multiple levels of security.

All management requests that arrive through a connector or HTML protocol adaptor are inspected by the agent application to determine if they are authorized. The management application filters requests based on the type of request, the MBean for which they are intended, or the values that are provided in the operation.

For example, context checking could allow an agent to implement a read-only policy that refuses attribute set operations, all operation invocation, and does not allow MBean registration or unregistration. A more selective filter could just ensure that the agent cannot be disconnected: it would disallow MBean unregistrations, stop operations, and invocations that contain null parameters, but only when applied to connector servers or protocol adaptor MBeans.

In addition, requests through connector clients can be filtered by an operation context field, which could be a password or any other identifying data. The context object is provided by the management application, and it will be sent to the connector server along with each request. The agent can verify this context and potentially reject the request if the context is considered invalid or inappropriate for the operation.

To make this context checking possible, the agent provides:

Figure 2–6 Context Checking Using Stackable MBean Server Objects

Context Checking Using Stackable MBean Server Objects

In Figure 2–6, a context checker object has been inserted between the connector and the MBean server. Because a context checker object implements the MBeanServer interface, the connector interacts with it in exactly the same way as it did with the MBean server. This stacked object retains a reference to the real MBean server, to which it forwards all requests that are allowed. The context checker can also perform any other action, such as log all filtered requests and trigger a notification when an invalid request is received.

For security reasons, only the agent application can insert or remove stackable MBean server objects. This operation is not exposed to management applications, which cannot even detect whether requests are being filtered. However, the context checker might respond with an exception message that explains why a request was denied.

Data Encryption

The last link in the security chain is the integrity of data that is exchanged between agent and managers. Two issues need to be considered simultaneously:

Authentication:

Both agent and manager must be certain of the other's identity.

Privacy:

The data of a management request should be tamper-proof and undecipherable to nontrusted parties.

These issues are usually resolved by a combination of electronic signatures and data encryption. Again, the implementation is protocol-dependent.

The SNMP protocols also provide password protection to agent applications. See SNMPv1 and SNMPv2 Security and SNMPv3 Security.

HTTP/SSL

The HTTPS connector enables Java managers to access a Java dynamic management agent using HTTP over Secure Socket Layer (SSL). SSL security is implemented in the Java 2 platform. The HTTP/SSL connector provides identity authentication based on the Challenge-Response Authentication Mechanism using MD5 (CRAM-MD5). The HTTPS connector server requires client identification by default.

The behavior of the HTTP/SSL connector is governed by the particular SSL implementation used in your applications. For data encryption, the default cipher suites of the SSL implementation are used. The SSL implementation must be compliant with the SSL Standard Extension API.

Secure Dynamic Loading

The m-let service downloads Java classes from arbitrary locations over the network. If you want to do so, you can enable code signing to ensure that only trusted classes can be downloaded. Secure loading relies on code signing.

On the Java 2 platform, the java.lang.SecurityManager property determines if code signing is enforced. When this security is enabled, again only class files signed by a trusted party will be loaded. On the Java 2 platform, users invoke the keytool, jarsigner, and policytool utilities to define their security policies.

The SNMP Toolkit

The Java Dynamic Management Kit provides a toolkit for integrating SNMP management into a JMX architecture. SNMP management includes:

For more information regarding the SNMP toolkit, refer to the Java Dynamic Management Kit 5.0 Tools Reference and the Java Dynamic Management Kit 5.0 Tutorial.

Developing an SNMP Agent

An SNMP agent is an application that responds to SNMP requests formulated as get, set, getnext, and getbulk operations on variables defined in a MIB. This behavior can be fully mapped onto the MBean server and MBean resources of a Java dynamic management agent, provided that those MBeans specifically implement the MIB. An SNMP agent can be issued either with or independently from an MBean server.

There exist two SNMP protocol adaptors: one that supports SNMPv1 and v2, and another introduced in the Java DMK 5.0 that supports SNMPv3 as well as the two previous versions. All features added in the Java DMK 5.0 therefore support SNMPv3 USM MIBs, providing user-based security, and scoped MIBs, that can be registered in the adaptor using a context name. The performance of SNMP has also been improved since Java DMK 5.0, by the addition of multithread support in SNMP adaptors and timers.

The SNMP protocol adaptors respond to requests in SNMP and translate the requests into management operations on the specific MIB MBeans. The SNMP adaptors also send traps, the equivalent of a JMX agent notification, in response to SNMP events or errors.

The SNMP protocol adaptors can manage an unlimited number of different MIBs. These MIBs can be loaded or unloaded dynamically, by registering and unregistering the corresponding MBeans. The adaptors attempt to respond to an SNMP request by accessing all loaded MIBs. However, MIBs are dynamic only through the agent application, and the SNMP protocol does not support requests for loading or unloading MIBs.

One advantage of the dual JMX–SNMP agent is that MIBs can be loaded dynamically in response to network conditions, or even in response to SNMP requests. Other Java dynamic management applications can also access the MIB through its MBean interface. For example, the value of a MIB variable might be computed in another application and written by a call to the MBean setter.

The SNMP protocol adaptors also send inform requests from an SNMP agent to an SNMP manager. The SNMP manager sends an inform response back to the SNMP agent.

SNMP MIB Compiler – mibgen

The mibgen tool takes as input a set of SNMP MIBs and generates standard MBeans that you can customize. MIBs can be expressed using either structure of management information (SMI) v1 or SMI v2 syntax.

A MIB is like a management interface. It defines what is exposed, but it does not define how to compute the exposed value. Therefore, MBeans generated by mibgen need to be customized to provide the definitive implementation. The MIB is implemented through Java objects, meaning that it has access to all Java runtime libraries and all features of the dynamic agent where it will be instantiated.

The mibgen compiler parses an SNMP MIB and generates the following:

The resulting classes should be made accessible in the agent application. When the single MBean representing the whole MIB is registered in the MBean server, all the associated groups are automatically instantiated and registered as well.

The mibgen compiler supports all data structure of SMI v1 and v2 protocols, including:

The Java DMK also provides an example program, showing how an agent can act as an SNMP master agent to access MIBs implemented remotely in subagents. This allows SNMP managers to access hierarchies of agents through a single master agent. In this way, some MIBs can be implemented by native devices and others can be implemented in JMX agents, yet this heterogeneous architecture is completely transparent to the manager issuing a request.

SNMP Manager API

The SNMP manager API simplifies the development of Java applications for managing SNMP agents. Its classes represent SNMP manager concepts such as sessions, parameters, and peers through Java objects. Using this API, you can develop an application that can issue requests to SNMP agents.

For example, you could create an SNMP resource using the SNMP manager API. You would define a management interface that corresponds to your resource's MIB, in which variables are easily mapped as MBean attributes. In response to calls on the attribute getters and setters, your MBean would construct and issue an SNMP request to the SNMP agent that represents the resource.

The SNMP manager API supports requests in the SNMP v1, v2 or v3 protocol, including inform requests for communicating between SNMP managers. The manager API is used to access any compliant SNMP agent, including those developed with the use of the Java DMK.

SNMPv1 and SNMPv2 Security

Because of backward compatibility, Java DMK 5.0 implements the security aspects of the SNMP protocol v1 and v2. However, you should implement the superior security mechanisms of SNMPv3, which are added in the Java DMK 5.0.

SNMPv1 and SNMPv2 Access Control

SNMPv1 and v2 define an access control mechanism similar to password authentication. Lists of authorized manager host names are defined in an access control list (ACL) stored in a file on the agent side, called the IP ACL file. There are no passwords, but logical community names (IP addresses) can be associated with authorized managers to define sets of allowed operations.

The SNMP adaptor performs access control if an ACL file is defined. Because SNMP is a connection—free protocol, the manager host and community are verified with every incoming request. By default, the file is not loaded and any SNMP manager can send requests.

The ACL file is the default access control mechanism in the SNMP protocol adaptor. However, you can replace this default implementation with your own mechanism. For example, if your agent runs on a device with no file system, you could implement access control lists through a simple Java class.

SNMPv1 and SNMPv2 Encoding

SNMP requests follow the standardized Basic Encoding Rules (BER) for translating management operations into data packets. At the communication level, an SNMP request is represented by an array of bytes in a UDP protocol packet. The SNMP components in the Java DMK provide access to the byte encoding of these packets.

Your applications can customize the encoding and decoding of SNMP requests, as follows:

SNMPv3 Security

The main addition to Java DMK 5.0 provided by SNMPv3 is the possibility of secure SNMP operation. The SNMPv3 security in Java Dynamic Management Kit 5.0 implements the following SNMP RFCs:

RFC 2571

Architecture

RFC 2572

Message Processing and Dispatching

RFC 2574

USM

The SNMPv3 protocol implementation provides:

Despite the differences between the previous versions of SNMP and SNMPv3, agents in Java DMK 5.0 can respond to requests from any version if the SNMPv3 protocol adaptor is used. SNMP v1 and v2 requests have greater security constraints than v3 requests in an agent compatible with SNMPv3.

The USM MIB is accessible remotely and is not registered to the SNMPv3 adaptor by default.

The USM MIB can be registered in an MBean server, thus making it accessible through the HTML adaptor. This is particularly useful when debugging, although it does create a security risk. Exposing the USM MIB through SNMP without the MBean server, however, is not insecure.

Users can also be configured into an agent by means of an ASCII text file that acts as an initial configuration template for all agents created.

SNMPv3 Authentication and Privacy

Inside SNMP domains, every SNMP entity is issued a unique identifier, the engine ID. Java DMK 5.0 provide a set of classes to allow you to generate engine IDs based on, amongst other identifiers, host names, internet protocol (IP) addresses, port numbers and Internet assigned numbers authority (IANA) numbers.

There are two types of SNMP entity:

Authoritative agent entities receive get, set, getnext, and getbulk requests and send traps. Nonauthoritative agents send informs.

Authoritative manager entities receive informs. Nonauthoritative managers send get, set, getnext and getbulk requests and informs, and receive traps. The engine ID and the number of times the engine has booted can be stored and persisted in the SNMPv3 security file, so that the timeliness of the incoming requests can be verified.

Under SNMPv3 there are three levels of security:

Managers and agents are both configured with a username, allowing the manager specific access to that agent. The username has an associated password. Both the agent and the manager sides must be configured according to the desired security policy. For requests to be authenticated, the manager and the agent must share knowledge of the authentication password associated with the username. For requests to be encrypted, the manager and the agent must additionally share knowledge of the privacy password associated with the username.

Unsecured SNMP Requests

When an agent receives a request from a manager, it checks its LCD. If the user is found in the LCD, the request is granted. No timeliness checking is performed, and the content of the request is not encrypted.

Authenticated Requests

The agent checks the identity of the originator of the request as previously described and then checks the timeliness of the request to ensure that it has not been delayed or intercepted for improper purposes. To monitor the timeliness of the arrival of requests, both manager and agent maintain synchronized clocks, and the manager's local notion of the authoritative engine's time of sending is included in the request. If the difference between the time of sending included in the request and the time of receipt recorded by the agent exceeds 150 seconds, then the request is not considered timely and is rejected.

Once the timeliness of the request has been confirmed, the request is authenticated using either of the HMAC-MD5 or HMAC-SHA protocols. These protocols check that the message digest included in the message matches the one computed locally in the receiving agent.

Authenticated and Encrypted Requests

If privacy has been activated, the content of the request is encrypted, using the DES encryption protocol provided by the Java cryptography extension (JCE) from JDK 1.4. The secure hash algorithm (SHA) and MD5 encryption protocols provided in JDK 1.2 are also used. The requests are decrypted and forwarded once the identity of the sender and the timeliness of the request have been established.

Error Messages

If any of the preceding checks fail, one of the following errors will be generated:

unknownUser

Unregistered user

unknownEngineID

Unregistered SNMP entity

encryptionFailed

Encryption error

unsupportedSecurityLevel

Unsupported security level

authentificationFailed

Password error

notInTimeWindow

Timeliness error

Note –

You can optionally implement alternative authentication and encryption algorithms. You cannot, however, plug in customized security or access control models in Java Dynamic Management Kit 5.0, although this will be possible in future versions.

SNMPv3 Access Control

SNMPv3 access control differs from the access control defined by versions 1 and 2, in that it is based on contexts and user names, rather than on IP addresses and community strings. The configuration for SNMPv3 access control is located in a text file, called the user ACL file. See the Java Dynamic Management Kit 5.0 Tutorial for information about the user ACL file and how to configure it.

When managers send a requests to an agent, the agent authenticates and, if necessary, decrypts the request, as explained earlier. It then passes the request through SNMP context-checking filters to determine whether it is authorized.

SNMPv3 Security Configuration

The configuration for SNMPv3 user-based security is located in a text file, called the security file. Each SNMP engine has its own security file. See the Java Dynamic Management Kit 5.0 Tutorial for information about the user security file and how to configure it.

You can view examples of security files at:

installDir/SUNWjdmk/jdmk5.0/examples/Snmp