 | |
Technical Overview
IntroductionThe Java Dynamic Management Kit (Java DMK) is a Java application programming interface (API) and a set of development tools for designing and implementing a new generation of management applications. As an implementation of the Java Management Extensions (the JMX specification) and JMX Remote API, the product provides a framework for the management of Java objects through Java technology-based applications. The Java DMK provides a complete architecture for designing distributed management systems. A Java technology-based solution can embed management intelligence into your agents, provide an abstraction of your communication layer, and be upgraded and extended dynamically. Your management applications can also take advantage of other Java technology APIs, such as Swing components for user interfaces and the Java DataBase Connectivity (JDBC) API for database access. In addition, the Java DMK provides a complete toolkit for the simple network management protocol (SNMP), the most widespread legacy architecture for network and device management. This gives you the advantages of developing both Java dynamic management agents and managers that can interoperate with existing management systems. An implementation of much of the SNMPv3 protocol also provides security mechanisms for your management operations.
Instrumenting Resources as MBeansA resource can be any entity, physical or virtual, that you wish to make available and control through your network. Physical resources can be devices such as network elements or printers. Virtual resources include applications and computational power that are available on a particular host. A resource is seen through its management interface: this is the set of attributes, operations, and notifications that a management application can access.To instrument a resource is to develop the Java object that represents the resource's management interface. The JMX specification defines how to instrument a resource according to certain design patterns. These patterns resemble those of the JavaBeans component model: an attribute has getters and setters, operations are represented by their Java methods, and notifications rely on the Java event model. Therefore, a Managed Bean, or MBean, is the instrumentation of a resource in compliance with JMX specification design patterns. If the resource itself is a Java application, it can be its own MBean, otherwise, an MBean is a Java wrapper for native resources or a Java representation of a device. MBeans can be distant from the managed resource, as long as they accurately represent its attributes and operations. The MBean developer determines what attributes and operations are available through the MBean. Device manufacturers and application vendors can provide the MBeans that plug into their customers' existing agents. Management solution integrators can develop the MBeans for resources that have not been previously instrumented. Because MBeans follow the JMX specification, they can be instantiated in any JMX-compliant agent. This makes them portable and independent of any proprietary management architecture.
Java Dynamic Management ArchitectureThe following diagram illustrates the architecture of a Java dynamic management solution. The key components in this architecture are described below.
In this example, the MBeans for two resources are registered with the agent's MBean server. An agent service such as monitoring is registered as another MBean. The agent contains a connector server for one of the following protocols: Remote Method Invocation (RMI), or JMX Messaging Protocol (JMXMP). It also contains a protocol adaptor, either for SNMP or HTML. An agent can have any number of communicator components, one for each of the protocols and for each of the ports through which it wishes to communicate. The remote manager is a Java application running on a distant host. It contains the connector client for the chosen protocol and proxy MBeans representing the two resources. When the connector client establishes the connection with the agent's connector server, the other components of the application can issue management requests to the agent. For example, it can call the proxy objects to invoke an operation on the first resource and configure the monitoring service to poll the second resource. The HTML adaptor gives a view of the agent through a web browser, which provides a simple user interface. Each MBean is represented as a separate HTML page, from which the user can interact with text fields to set attributes and click on buttons to invoke operations. There is also an administration page for creating or removing MBeans from the MBean server.
Exposing MBeans in a Smart AgentA Java dynamic management agent follows the client-server model: the agent responds to the management requests from any number of client applications that wish to access the resources it contains. The agent centralizes all requests, dispatches them to the target MBeans and returns any responses. The agent handles the communication issues involved with receiving and sending data, so that the MBeans do not have to.The central component of an agent is the MBean server. It is a registry for MBean instances and it exposes a generic interface through which clients can issue requests on specific MBeans. Clients can ask for the description of an MBean's management interface, in order to know what resource is exposed through that MBean. Using this information, the client can then formulate a request to the MBean server to get or set attributes, invoke operations or register for notifications. MBeans are only accessible through requests to the MBean server. Manager applications never have the direct reference of an MBean, only a symbolic object name that identifies the MBean in the agent. This preserves the client-server model and is essential to the implementation of query and security features. The MBean server also provides the framework that allows agent services to interact with MBeans. Services are themselves implemented as MBeans, that interact with resource MBeans to perform a defined task. For example, a manager could decide to monitor a given MBean attribute: it instantiates the monitoring service MBean, configures the threshold, and registers to receive the alarms that might occur. The manager no longer needs to poll the agent, it will automatically be notified whenever the attribute exceeds the threshold. The library of services contains the logic that is necessary for implementing advanced management policies: scheduling events, monitoring attributes, establishing and enforcing relations, discovering other agents, creating subagent hierarchies, and downloading new MBean objects. You can also develop your own service MBeans to meet your management needs, such as logging and persistence services that are typically platform-dependent.
Accessing Agents RemotelyJava DMK enables you to access agents and their resources easily from a remote application. All components for handling the communication are provided, both in the agent and for the client application. The same API that is exposed by the MBean server in the agent is also available remotely to the manager. This symmetry effectively makes the communication layer transparent. Management applications perform requests by getting or setting attributes or invoking operations on an MBean identified by its symbolic name. Proxy objects provide a further level of abstraction by representing an MBean remotely and handling all communication. The manager can be designed and developed as if all resources were local. The communication components also handle notification forwarding, so that remote managers can register to receive notifications from broadcasting MBeans. Management applications developed in the Java programming language use connectors to make the communication layer transparent. Connectors for the RMI, RMI/IIOP and JMXMP protocols are provided, as defined by the JMX Remote API, all with the same API for interchangeability. Adaptors provide a view of an agent through other protocols for management applications which are not based on Java technology. For example, the HTML adaptor represents MBeans as web pages that can be viewed in any web browser. The SNMP adaptor can expose special MBeans that represent an SNMP MIB and respond to requests in the SNMP protocols. It is possible to use the SNMP adaptor without registering the MIB in the MBean server. All connectors and adaptors are implemented as MBeans. Management applications can therefore create, configure and remove communication resources dynamically, according to network conditions or available protocols. Each protocol can have its own built-in security mechanisms, for example SSL, SASL, or SNMPv3 security. Security aspects linked to each protocol are therefore handled at the connector or adaptor layer, making them transparent to the MBean developer. The flexibility of communicator MBeans and the availability of connectors for multiple protocols make it possible to deploy management solutions in heterogeneous network environments. The adaptors create a bridge between agents that are based on the JMX architecture and existing management systems. You can also create your own connectors and adaptors to accommodate proprietary protocols and future management needs. The SNMP ToolkitThe Java DMK provides a toolkit for integrating SNMP management into a JMX architecture-based solution. This includes:
The MBeans representing a MIB are generated automatically by the
Java DMK provides two SNMP protocol adaptors: one that supports SNMPv1 and v2, and another introduced in 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. 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. 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 protocols, 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. The SNMP support added in Java DMK 5.0 also allows you to build a master agent that groups together several SNMP subagents and exports their information through a single point of access. The master agent registers subagents to handle a MIB or a part of a MIB, and also converts requests from the SNMP version supported by the manager into the version supported by the subagent. SNMPv3 SecurityFor reasons of backward compatibility, Java DMK implements the security aspects of the SNMP protocols v1 and v2. However, since Java DMK v5.0, it implements the superior security mechanisms of SNMPv3. Java DMK now implements the following SNMP RFCs, as defined by the Internet Engineering Task Force (IETF): RFC 2571, RFC 2572, RFC 2574, and RFC 2576. The SNMPv3 protocol implementation provides:
|
| |||||||||||||||||||||||||||||||||||||||||||||
| | |||||||||||||||||||||||||||||||||||||||||||||
Oracle is reviewing the Sun product roadmap and will provide guidance to customers in accordance with Oracle's standard product communication policies. Any resulting features and timing of release of such features as determined by Oracle's review of roadmaps, are at the sole discretion of Oracle. All product roadmap information, whether communicated by Sun Microsystems or by Oracle, does not represent a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. It is intended for information purposes only, and may not be incorporated into any contract.
| ||||||||||||
Print-friendly Version
Figure 2: Management by SNMP
