Getting Started with the Java Dynamic Management Kit 4.2

Chapter 1 The Java Dynamic ManagementTM Kit

The Java Dynamic ManagementTM Kit is a JavaTM 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 JMXTM specification), the product provides a framework for the management of Java objects through Java technology-based applications.

The Java Dynamic Management Kit 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 APIs such as Swing components for user interfaces and the JDBCTM API for database access.

In addition, the Java Dynamic Management Kit 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.

Contents:

Introduction

In this section, we answer these fundamental questions about the Java Dynamic Management Kit:

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.

Why Use 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 only perform 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 allows 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 may need to implement multiple management technologies, in order 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 they communicate through a Java Dynamic Management agent, management applications 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 Dynamic Management Kit provides a distributed model that is protocol independent: management applications rely on the API, not on any one protocol.

The Java Dynamic Management Kit brings new solutions to the management domain through:

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 for you 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 can also be network-based, downloaded 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 Dynamic Management Kit a wide domain of application as it integrates the current and future management standards.

What Is the Java Dynamic Management Kit?

The Java Dynamic Management Kit is a Java API with 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 Dynamic Management Kit include:

The development tools are implemented as two standalone applications:

Finally, the Java Dynamic Management Kit contains complete documentation for developers:

How Do I Develop a Java Dynamic Management Solution?

The intstrumentation 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 Dynamic Management Kit extends the agent services and defines the distributed management features for accessing agents remotely. A distributed management solution relies on all three levels.

Instrument Your Resources as MBeans

A 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 some host. A resource is seen through its management interface: this 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 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 may provide the MBeans that plug into their customer's existing agents. Management solution integrators may develop the MBeans for resources which 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.

Expose Your MBeans in a Smart Agent

A 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 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 may 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 manager 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 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: it 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, 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 of new MBean objects. You may also develop your own service MBeans to meet your management needs, such as logging and persistence services which are typically platform dependent.

Access Your Agents Remotely

Finally, the Java Dynamic Management Kit allows you to access agents and their resources very 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 simply 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 may 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 Java-based. For example, the HTML adaptor represents MBeans as web pages that can be viewed in any Web browser. The SNMP adaptor exposes special MBeans that represent an SNMP MIB and responds to requests in both SNMP v1 and v2 protocols.

All connectors and adaptors are themselves implemented as MBeans. Management applications may therefore create, configure and remove communication resources dynamically, according to network conditions or available protocols. Of course, the agent application may also implement security features that prevent unwanted operations on the communicator MBeans.

The flexibility of communicator MBeans and the availability of connectors for multiple protocols makes 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 may also create your own connectors and adaptors to accommodate proprietary protocols and future management needs.

Key Concepts

The diagram in Figure 1-1 gives a visual representation the key concepts of the Java Dynamic Management Kit 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 the following protocols: RMI, HTTP, or HTTPS. 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.

Figure 1-1 Key Concepts of the Java Dynamic Management Kit

Graphic

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 may 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 lets us view 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.

We will further define and describe each of these concepts in Chapter 2: "Architectural Components".

Advantages of a Java Dynamic Management Solution

To summarize, the benefits of the Java Dynamic Management Kit include:

Simplified Design and Development

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 makes it possible to have modular development, each level being 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:

At the agent level:

At the manager level:

At all three levels, the modularity also means the simple designs may be implemented rapidly, and then additional functionality may be added as it is needed. You can have a prototype running after your first day of development, thanks to the programming examples provided in the product.

Protocol Independence

The design of MBeans, agents, and managers does not depend in any way on the protocol an agent uses for communicating with external applications. All interactions with MBeans are necessarily handled by the MBean server and thus defined by the APIs of the Java Management extensions.

The provided connectors rely on this API and do not expose any communication details. A connector server-conector client pair may be replaced by another without loss of functionality, assuming both protocols are in the network environment. Applications may thus switch protocols according to real-time conditions. For example, if a manager must access an agent behind a firewall, it may instantiate and use an HTTP connector.

Because MBeans and agents are protocol-independent, they may be accessed simultaneously through any number of protocols. Connector servers and protocol adapters can handle multiple connections, so your agent only needs one of them for each protocol to which it would like to respond. The MBean server also supports simultaneous requests, although MBeans are responsible for their own sychronization issues.

New connectors for new protocols can be developed and used without rewriting existing MBeans or external applications. All that is required is that the new connector client expose the remote API.

Dynamic Extensibility And Scalability

By definition, all agents and manager applications developed with the Java Dynamic Management Kit are extensible and scalable. The library of agent services is always available: managers may instantiate new services when they are 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 may be registered and unregistered with the MBean server in an agent while it is running. This is useful to represent application resources which may come and go on a given host. The scalability allows an agent to adapt to the size and complexity of its managed resources, without having to be restarted or reinstalled.

The dynamic loading service can download and instantiate MBeans from an arbitrary location. Therefore, it is possible to extend the functionality of a running agent by making new classes available at an arbitrary location and requesting that the agent load and instantiate them. This is effectively a push mechanism that can be used to deploy services and applications to customers.

Finally, JMX conformance insures that all JMX-compatible components can be incorporated into Java Dynamic Management agents, whether they are manageable resources, new services, or new communication components.