The 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 Java Management Extensions (JMX), the product provides a framework for the management of Java objects through Java technology-based applications. Because the product is also an implementation of the JMX Remote API, it allows your management applications to monitor and manage resources through your network.
The Java DMK provides a complete architecture for designing distributed management systems. A Java technology-based solution can embed management intelligence into your agents, can provide an abstraction of your communication layer, and can be upgraded and extended dynamically. Your management applications can also take advantage of other Java APIs such as Swing components for user interfaces and the JDBCTM 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.
This chapter contains the following sections:
1.1 Introduction to the Java DMK gives an overview of the product architecture and functionality.
1.2 Key Concepts describes the main components of the Java DMK.
1.3 Benefits of a Java Dynamic Management Solution highlights the benefits of the product for designers and developers.
1.4 Overview of the Product Documentation describes the product documentation delivered with the Java DMK.
This section addresses these fundamental questions about the Java DMK:
Why use Java dynamic management technology?
What is the Java Dynamic Management Kit?
How is a Java dynamic management solution developed?
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.
In the past, network management was usually performed by large, centralized management applications. These management applications monitored and modified their network by tightly controlling their agents. In addition, agents were usually situated in or near the network elements they controlled, which meant that these agents were limited in nature. The agents usually contained little management intelligence and could perform only basic network management operations.
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.
When you implement Java dynamic management technology, the interface to resources is standardized, meaning your management applications can use any technology you 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 the management services can control resources through standard interfaces, they are dynamically interchangeable. When new services become available, these services can be downloaded and be plugged in dynamically to upgrade the capabilities of a smart agent. 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 the following advantages.
Compliance with the JMX specification and the JMX Remote API specification, for managing Java objects through Java applications, as developed through the Java Community ProcessSM(JCPSM).
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. This architecture can also 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. If your services are network-based, you can download them through simple web pages in the same way as Java technology-based applets.
You can connect to your agents remotely, using the connector protocols that were standardized in JMX Remote API. Using the remote method invocation (RMI) and JMX messaging protocol (JMXMP) connectors, you can access agents across a network with the connectors remaining completely invisible to either end of the connection. These connections can be secured using the Secure Sockets Layer (SSL) security mechanism with the RMI connectors, and with the more advanced Simple Authentication and Security Layer (SASL) protocol with the JMXMP connector.
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 are 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 Java DMK is a compliant implementation of the following specifications:
The JMX specification
The JMX Remote API specification
The programmatic components of the Java DMK include the following.
New standard communication modules – Version 5.1 of Java DMK defines APIs for accessing JMX agents remotely. This version includes new standard communication modules that based on RMI and JMXMP protocols, as defined by the JMX Remote API specification. The JMXMP connector is a custom connector that has been created especially for the JMX Remote API. JMXMP is based on Java serialization over transmission control protocol (TCP) connections.
RMI, hypertext transport protocol (HTTP), and secure HTTP (HTTPS) communication modules. You can still use the legacy communication modules based on the RMI, HTTP, and HTTPS protocols that were included in previous versions of the product. These legacy communication modules are deprecated in Java DMK 5.1.
HTML adaptor. The Java DMK 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, new and legacy systems for cascading agent hierarchies, dynamic agent discovery, and components for implementing security mechanisms.
SNMP API. Applications that rely on the SNMP APIs can integrate into existing network management systems and can help these systems migrate towards a more dynamic, service-based approach to network management.
SNMPv3 compliance. Java DMK 5.1 provides an implementation of SNMPv3 security to protect your systems from outside interference.
Security mechanisms. Java DMK 5.1 allows you to choose the level of security you require. For example, for an RMI connector over JRMP, you can use an RMI socket factory, so that the connection between client and server uses the Secure Socket Layer (SSL). A more advanced level of security is available with the standard JMXMP connector, which is based on the Java Secure Socket Extension (JSSE), the Java Authentication and Authorization Service (JAAS), and the Simple Authentication and Security Layer (SASL).
The development tools are implemented as two standalone applications:
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.
proxygen – This tool is a proxy object generator for use with legacy connectors. The proxygen tool simplifies the development of Java technology-based management applications. Proxy objects make the communication layer transparent to the manager application. Note that if you require proxies for standard connectors, you should use the dynamic proxies provided by J2SE (java.lang.reflect.Proxy), not the proxygen tool. The proxygen tool is deprecated in Java DMK 5.1.
Finally, the Java DMK includes 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 various aspects of the functionality of the Java DMK.
A tutorial that explains the programming examples and a reference guide for the standalone tools.
Both online HTML and PDF file formats for all documents. The HTML format complies with the accessibility standards for electronic and information technology covered by section 508 of the Rehabilitation Act Amendments of 1998.
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 management level defined by the JMX Remote API specification describes how to use standard connectors to access agents remotely, and how to implement the associated security aspects. Using the Java DMK, you can design and develop a distributed management solution relying on all three levels, and compliant with both specifications.
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 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 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.
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 that the agent contains. The agent centralizes all requests, dispatches the requests to the target MBeans, and returns any responses. The agent, rather than the MBeans, handles the communication issues involved with receiving and sending data.
The central component of an agent is the MBean server. The MBean server is a registry for MBean instances, that 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 an MBean attribute. The manager 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, 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 the following.
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, RMI/IIOP and JMXMP protocols are provided, as defined by the JMX Remote API, all with the same API for interchangeability. The legacy RMI and HTTP-based connectors from previous versions of Java DMK are retained for reasons of backwards compatibility, but are deprecated in version 5.1. Wherever possible, you should migrate your remote agents to the standard JMX Remote API connectors.
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.
Figure 1–1 illustrates the key concepts of the Java DMK and shows how the components relate to each other.
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 either the RMI or JMXMP connector protocols. The agent 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 one for each of the ports through which it communicates.
The remote manager is a Java application running on a distant host. The manager 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, the connector client can call the proxy objects to invoke an operation on the first resource and configure the monitoring service to poll the second resource.
With the HTML adaptor, you can view the agent through a web browser, which provides a simple user interface. Each MBean is represented as a separate HTML page, from which you can interact with text fields to set attributes and click buttons to invoke operations. The HTML adaptor also provides an administration page for creating or removing MBeans from the MBean server.
Each of these concepts is further defined in Chapter 2, Architectural Components.
To summarize, the benefits of the Java DMK include the following.
Simplified design and development of instrumentation, smart agents, and remote managers
Deployment flexibility through protocol independence and SNMP compatibility
Dynamic extensibility and scalability
Secure SNMPv3 access
Secure standard communication modules with remote managers
The JMX architecture standardizes the elements of a management system. All three levels, instrumentation, agent, and manager, are isolated and their interaction is defined through the API. This design makes it possible to have modular development, in which each level is designed and implemented independently. Also, component reuse is possible. Services developed for one JMX agent will work in all JMX agents.
At the instrumentation level:
MBeans need only to define their management interface and map the variables and methods of their resource to the attributes and operations of the interface.
MBeans can be instantiated into any agent that is compliant with the JMX specification.
MBeans do not need to know anything about communication with the outside world.
At the agent level:
The MBean server handles the task of registering MBeans and transmitting management requests to the designated MBean.
Any MBean compliant with the JMX specification can be registered and be exposed for management.
Any of the provided communication components can be used to respond to remote requests, and you can develop new adaptors and new connectors to respond to proprietary requests.
The library of agent services provides management intelligence in the agent, such as autonomous operation in the case of a network failure.
At the manager level:
All management requests on an MBean server are available remotely through a connector.
Notification forwarding is already implemented for you.
Proxies provide an abstraction of the communication layer and simplify the design of the management application.
Basic management tasks are implemented in the agent by the agent services.
At all three levels, the modularity also means the simple designs can be implemented rapidly, and then additional functionality can be added as needed. You can have a prototype running after your first day of development, because of the programming examples provided in the product.
The design of MBeans, agents, and managers does not depend in any way on the protocol that an agent uses for communicating with external applications. All interactions with MBeans are handled by the MBean server and are thus defined by the JMX APIs.
The provided connectors rely on the API and do not expose any communication details. A connector server, connector client pair can be replaced by another pair without loss of functionality, assuming both protocols are in the network environment. Applications can thus switch protocols according to real-time conditions. For example, if a manager must access an agent behind a firewall, it can instantiate and use an HTTP connector.
Because MBeans and agents are protocol independent, they can be accessed simultaneously through any number of protocols. Connector servers and protocol adaptors can handle multiple connections, so your agent needs only one of them for each protocol to which it responds. The MBean server also supports simultaneous requests, although MBeans are responsible for their own synchronization issues.
New connectors for new protocols can be developed and be used without rewriting existing MBeans or external applications. All that is required is that the new connector client expose the remote API.
The Java DMK 5.1 supports multihome interfaces, allowing you to work in environments where multiple network protocols are available. The multihome interface service means that Java DMK 5.1 offers complete support of the internet protocol version 6 (IPv6), provided it is running on a platform that is IPv6 compatible, namely JDKTM version 1.4 and higher.
By definition, all agents and manager applications developed with the Java DMK 5.1 are extensible and scalable. The library of agent services is always available. Managers can instantiate new services when needed and later remove them to minimize memory usage. This is especially useful for running agents on small footprint devices.
In the same way, MBeans can be registered and be unregistered with the MBean server in an agent while the agent is running. This is useful to represent application resources that can come and go on a given host. The scalability enables an agent to adapt to the size and complexity of its managed resources, without having to be restarted or be reinstalled.
The dynamic loading service can download and instantiate MBeans from an arbitrary location. Therefore, you can 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. This is effectively a push mechanism that can be used to deploy services and applications to customers.
In addition, open MBeans contribute to the flexibility and scalability of management systems by enabling management applications to use new managed objects as the objects are created.
Finally, conformance to the JMX specification ensures that all components that are compatible with the JMX specification can be incorporated into Java dynamic management agents, whether they are manageable resources, new services, or new communication components.
Java DMK supports SNMPv1 and v2 fully, and implements much of SNMPv3. A single agent can respond to requests from any version of SNMP.
For more information about security using the SNMPv3 protocol, see 2.6 Security.
The SNMP support in Java DMK 5.1 allows you to build a master agent. An SNMP master agent groups together several SNMP subagents and exports their information through a single point of access. The master agent performs the following two main functions.
Registers subagents to handle a MIB or a part of a MIB. A subagent can provide a local implementation of the MIB, in the form of the usual Java DMK SnmpMibAgent class. The master agent can also be a proxy, representing a remote SNMP agent, to which the request will be forwarded.
Converts requests from the SNMP version supported by the manager into the version supported by the subagent. The master agent also converts the responses back, and converts the traps sent by the subagent into the version used by the manager.
Java DMK includes both printable and online documentation, as well as a set of programming examples.
You can view HTML documentation after installation of the product. On the machine where you installed the product, open one of the following URLs in any browser:
The page contains links to all the product documentation that is supplied online with Java DMK.
Complete PDF versions of the books listed in the preceding section are also supplied with the CD—ROM release of Java DMK 5.1. These files are also located in the /doc directory on the CD-ROM.
The documents are formatted for U.S. Letter paper size (8.5 × 11 inches), but they can be loaded by any appropriate document viewer or printed directly to any printer. The text area on each page fits on most standard paper sizes.
Sample applications that demonstrate most of the functionality of the Java DMK are provided in the examples package of the product. If you installed this package, the Java source files and README text files for these applications are located in subdirectories:
The examples in the /legacy subdirectory demonstrate the features that have been deprecated in Java DMK version 5.1, but retained for reasons of backwards compatibility.
In the Solaris operating environment, you need to be root user to write to this directory. To compile the example programs, users should copy the examples hierarchy to a more accessible location.
The README file for each example gives a brief explanation of the source files and the instructions for running its application. Further explanation for most examples is available in the Java Dynamic Management Kit 5.1 Tutorial.
The API documentation generated by the Javadoc utility provides the full description of all classes, interfaces, and methods in the Java DMK APIs.
The generated API documentation for the Java DMK is found in the following location after installation: