This section addresses these fundamental questions about the Java DMK:
Why use Java dynamic management technology?
What is the Java Dynamic Management Kit?
How do I develop a Java dynamic management solution?
If this is your first contact with the product, the answers to these questions should help you understand how your management needs can be solved using Java dynamic management technology.
Old Way – Network management is usually performed by large, centralized management applications. These management applications monitor and modify their network by tightly controlling their agents. The agents act as relays for the network resources they represent, translating commands and collecting raw data and status information. Agents are usually situated in or near the network elements they control, which means that these agents are limited in nature. They usually contain little management intelligence and can perform only basic network management operations.
New Way – A Java dynamic management agent exposes its resources in a standard way and provides management services directly at the resource level. These services provide the intelligence that enables agent applications to perform management tasks autonomously. This frees the management application from routine tasks such as polling and thus reduces the network load as well.
Old Way – From a wider perspective, existing management systems for networks and applications 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 might need to implement multiple management technologies to provide more complete coverage of their potential markets. Due to the limitations of both approaches, vendors frequently choose not to implement any management technology.
New Way – The interface to resources is standardized, meaning that device vendors and application developers can finally agree: they can use any technology they want. As long as management applications communicate through a Java dynamic management agent, they can access any resource.
The same flexibility applies to the management services that are deployed in the agents. Because they can control resources through standard interfaces, they are dynamically interchangeable. In order to upgrade the capabilities of a smart agent, new services can be downloaded and plugged in dynamically when they become available. Finally, the Java DMK provides a distributed model that is protocol independent. Management applications rely on the API, not on any one protocol.
The Java DMK brings new solutions to the management domain through:
Compliance to the JMX specification, for managing Java objects through Java applications, as developed through the Java Community Process(SM).
A single suite of components that provides uniform instrumentation for managing systems, applications, and networks, and that provides universal access to these resources.
A flexible architecture that distributes the management load and that can be upgraded in real time for the service-driven network.
The service-driven network is a new approach to network computing that concentrates on the services you want to provide. These range from the low-level services that manage relationships between network devices to the value-added services you provide to end users. These services drive your network and management needs. In addition, autonomous agent functionality makes it possible to manage a very large installed base.
With the Java dynamic management architecture, services can be incorporated directly into agents. Agents are given the intelligence to perform management tasks themselves, enabling management logic to be distributed throughout the whole network. New services can be downloaded from a web server at runtime using a dynamic pull mechanism. Services are not only implemented inside devices, but they can also be network-based, meaning that you can download them through 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 will be created, enhanced and deployed as needed. This unique combination of features gives the Java DMK a wide domain of application as it integrates the current and future management standards.
The Java DMK is a Java API that includes all its class and interface objects, development tools that speed up the development process, and a complete set of documentation.
The programmatic components of the Java DMK include:
A management architecture – The architecture is a conforming implementation of the JMX specification API, both the instrumentation and the agent levels.
Communication modules – The Java DMK defines APIs for accessing JMX agent remotely. The product includes communication modules based on the RMI, HTTP, and HTTPS protocols. It also includes an HTML adaptor, which supports access to an agent from a web browser.
Agent services – The library of supplied services includes monitoring, scheduling, dynamic loading, defining relations, cascading agent hierarchies, dynamic agent discovery, and components for implementing security mechanisms.
SNMP APIs – Applications that rely on the SNMP APIs can integrate into existing network management systems and help these systems migrate towards a more dynamic, service-based approach to network management.
SNMPv3 compliance – Java DMK 5.0 implements SNMPv3 security to protect your systems from outside interference.
The development tools are implemented as two standalone applications:
proxygen – This tool is a proxy object generator that simplifies the development of Java technology-based management applications. Proxy objects make the communication layer transparent to the manager application.
mibgen – This tool is used when developing SNMP agents. A management information base (MIB) represents the management interface of resources in an SNMP agent, and mibgen generates the corresponding Java objects.
Finally, the Java DMK contains complete documentation for developers:
The full description of all classes, interfaces and methods in the APIs, generated by the Javadoc utility.
The source code for programming examples, which demonstrate all functionality of the product.
A tutorial that explains the programming examples and a reference guide for the standalone tools.
Both online HTML and printable file formats for all documents.
The complete JMX specifications document: the Java DMK 5.0 implements the JMX Specification v1.1.
The instrumentation level of the JMX specification describes how to represent a resource as a Java object. The JMX agent level describes how resources interact with an agent. The Java DMK extends the agent services and defines the distributed management features for accessing agents remotely. A distributed management solution relies on all three levels.
A resource can be any entity, physical or virtual, that you want 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 some host. A resource is seen through its management interface, that is, the set of attributes, operations, and notifications that a management application may 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 a certain design pattern. These patterns resemble those of the JavaBeansTM 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 the JMX 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 customer's 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 agent that is compliant with the JMX specification. This compliance makes the MBeans portable and independent of any proprietary management architecture.
A Java dynamic management agent follows the client-server model. The agent responds to the management requests from any number of client applications that want 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 don't 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, to find out what resource is exposed through that MBean. Using this information, the manager can then formulate a request to the MBean server to get or set attributes, invoke operations, or register for notifications.
MBeans are accessible only through requests to the MBean server. Manager applications never have the direct reference of an MBean, only a symbolic object name which 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, which interact with resource MBeans to perform some task. For example, a manager could decide to monitor some MBean attribute. The manager instantiates the monitoring service MBean, configures the threshold, and registers to receive the alarms that may occur. The manager no longer needs to poll the agent, but 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, such as:
Scheduling events
Monitoring attributes
Establishing and enforcing relations
Discovering other agents
Creating subagent hierarchies
Downloading of new MBean objects
You can also develop your own service MBeans to meet your management needs, such as logging and persistence services, which are typically platform dependent.
Finally, the Java 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, HTTP/TCP and HTTP/SSL protocols are provided, 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 HTTPS, 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 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.