To summarize, the benefits of the Java DMK include:
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
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, 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 exposed for management.
Any of the provided communication components can be used to respond to remote requests, and you can develop new adaptors and 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 it is 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 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 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.0 supports multihome interfaces, allowing you to work in environments where the are multiple network protocols available. The multihome interface service means that Java DMK 5.0 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.
By definition, all agents and manager applications developed with the Java DMK 5.0 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 unregistered with the MBean server in an agent while it 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 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 they 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.
The Java DMK 5.0 extends the SNMP support of previous Java DMK releases to include the SNMPv3 protocol. This means that Java DMK benefits from the security and administration services offered by SNMPv3.
The 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 Security.
The SNMP support in the Java DMK 5.0 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 performs two main functions:
It 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. It can also be a proxy, representing a remote SNMP agent, to which the request will be forwarded
It converts requests from the SNMP version supported by the manager into the version supported by the subagent. It also converts the responses back, and converts the traps sent by the sub agent into the version used by the manager.