JMX specification
(
Reproduced)
1.1 JMX Overview JMX - Java Management Extensions, Java Management Extensions, is an application, device, system, etc. Framework. JMX can span a series of heterogeneous operating system platforms, system architecture, and network transport protocols, flexible development seamless integration systems, networks, and service management applications.
The JMX architecture is divided into the following four levels:
1) Instrumentation Level: The information model is mainly defined. In JMX, various management objects exist in the form of management components, and register to the MBean server when you need to manage. This layer also defines the notification mechanism and some auxiliary metadata classes.
2) Agent Level: It mainly defines various services and communication models. The core of this layer is an MBean server, and all management components need to be registered with it to manage. Registering the management component on the MBean server is not directly communicating with the remote application, and they communicate through the protocol adapter and connectors. The protocol adapter and connectors are also registered with the MBean server in the form of a management component to provide the corresponding services.
3) Distributed Service Level: Mainly defined management interfaces and components that can operate on the agent layer so managers can operate the agent. However, the current JMX specification does not give specific specifications for this layer.
4) Additional Management Protocol API: The defined API is mainly used to support currently existing network management protocols, such as SNMP, TMN, CIM / WBEM, etc.
1.2 Instrumentation Level This layer defines how to implement the specification of JMX management resources. A JMX management resource can be a Java application, a service, or a device that can be developed with Java, or at least use Java to package, and can be placed in a JMX framework, thus becoming a management component of JMX (Managed Bean) , Referred to as MBean. The management component can be a standard, or a dynamic, standard management component complies with the design pattern of the JavaBeans component; the dynamic management component complies with a specific interface, providing greater flexibility.
This layer also defines a notification mechanism and an auxiliary metadata class that implements the management component.
1.2.1 Management Components (MBEAN) In the JMX specification, the management component is defined as follows: it is a Java object that can represent the management resource, which complies with a certain design mode, and requires a specific interface defined by this specification. This definition ensures that all management components indicate managed resources in a standard manner.
The management interface is some information exposed by the managed resource, and can control the managed resources by modifying this information. The management interface of a management component includes:
1) The attribute value that can be contacted;
2) The operation that can be performed;
3) Notification events that can be issued;
4) The builder of the management component.
The management component encapsulates attributes and operations through a public approach and compliance with a specific design pattern to expose to the management application. For example, a read-only attribute is only a GET method in the management component, and both GETs have a SET method representation is a readable and writable attribute.
The remaining JMX components, such as the various services provided by JMX proxy, and as a management component to register to the agent to provide the corresponding service.
JMX does not have any restrictions on the storage location of the management component, and the management component can be stored any position of the class path of the Java virtual machine running the JMX agent, or can be imported from any location on the network.
JMX defines four management components: standard, dynamic, open and model management components. Each management component can be developed according to different environmental needs.
Standard management component
The design and implementation of standard management components is the simplest, and their management interfaces are described by methods name. The implementation of standard management components rely on a set of naming rules, called design patterns. These naming rules define attributes and operations. Checking the standard management component interface and application design modes are called introspection [22]. The JMX agent uses the internal province to see the method and superclars of each registered management component on the MBean server, see if it complies with a certain design mode, decides whether it represents a management component and identifies its properties and operations. 2. Dynamic management components
Dynamic management components provide greater flexibility, which can expose their management interface at runtime. Its implementation is by implementing a specific interface Dynamicmbean (as shown below).
The JMX agent obtains the management interface exposed by the dynamic management component via the GetMBeanInfo method. The object returned by the method is an instance of the MBeanInfo class, which contains the signature of the attributes and operations. Since the call is called to occur after the dynamic management component is registered with the MBean server, the management interface is acquired at the runtime. Unlike standard management components, JMX agents do not need to determine the management interface of dynamic management components through internal provincial mechanisms. Since the interface of DynamicMbean is constant, you can shield the details. Due to this characteristic of the management interface in the runtime, dynamic management components provide greater flexibility.
3. Open management components
Open management components are a specialized dynamic management component, all of which are established around the management component, return type, and attributes are built around a set of predefined data types (String, Integer, Float, etc.), and passed A set of specific interfaces are described in self-description. The JMX agent obtains the management interface of the open management component by getting an OpenMBeanInfo object. OpenMbeanInfo is the subclass of MBeanInfo.
4. Model management components
Model management components are also a specialized dynamic management component. It is prefabricated, universal, and dynamic MBEAN classes, which already contains all the implementations of the necessary default behavior, and allows those implementations that need to be customized at runtime. JMX specification specifies that this class must be implemented as javax.management.modelmbean.requiredModelmbean, the manager to instantiate the class and configure the default behavior of the component and register to the JMX agent to manage the resource. JMX proxy gets a management interface by getting a ModelMbeanInfo object.
Model management components have the following new features [23]:
1) Persistence
A persistent mechanism is defined, and the Java sequence or JDBC can be used to store the status of the model MBean.
2) Notification and log function
You can record each of the notifications and automatically issue attribute change notifications.
3) Attribute value cache
Ability to have a cache attribute value.
1.2.2 Notification Model A management interface provided by a management component allows the agent to control and configure its management resource. However, these interfaces only provide some functions for the management complex distributed system. Typically, management applications need to be reflected when changing status or when specifically changes.
To this end, JMX defines the notification model. The notification model only involves event propagation between management components in the same JMX agent. The JMX Notification Model relies on the following parts:
1) Notification, a generic event type, the type of this class identity event can be used directly, or it can be expanded according to the needs of the transmitted event.
2) NotificationListener interface, the object that is notified is required to implement this interface.
3) NotificationFilter interface, the object as a notification filter needs to be implemented, providing a filter notified filter for the notification listener.
4) NotificationBroadCaster interface, notify the sender to implement this interface, which allows for the listener who wants to get notified registration. Send a universal type notification, any listener gets the notification. Therefore, the listener needs to provide a filter to select the notification you need.
Any type of management component, standard or dynamic, can be used as a notification sender, or as a notification listener, or both.
1.2.3 Auxiliary metadata class auxiliary metadata class is used to describe management components. The auxiliary metadata class is not only used in the provincial standard management components, but also is used by dynamic management components. These classes describe the management interface based on attributes, operations, builders, and notices. The JMX agent manages all management components through these metadata classes regardless of these management components.
Some secondary metadata is as follows:
1) MBeanInfo - contains information about properties, operations, builders, and notifications.
2) MBeanFeatureInfo - is superclass in the following class.
3) MBeanAttributeInfo - used to describe properties in the management component.
4) MBeanConstructorInfo - Used to describe the builder in the management component.
5) MBeanOperationInfo - used to describe the operations in the management component.
6) MBeanparameterInfo - The parameters used to describe the management component operation or builder.
7) MBeanNotificationInfo - The notification used to describe the management component.
1.3 Agent Layer Agent layer is a management entity running on the Java virtual machine, which is active between management resources and managers to directly manage resources and allow these resources to be controlled by remote hypervisors. The agent layer consists of an MBean server and a series of services managed by the managed resource. The figure below shows the composition of the agent layer:
1.3.1 MBean Server MBean Server The core of the agent layer, all management components of the device layer are registered, and the manager only uses it to access the management component.
The management component can be instantiated and registered by the following three methods:
1) Through another management component
2) Management agent itself
3) Remote application
When you register a management component, you must provide a unique object name. Managing applications with this object name to identify management components and operate them. These operations include:
1) Discover management interface management interface
2) Read and write attribute values
3) Execute the operation defined in the management component
4) Note to obtain management components
5) Query management components based on object name and attribute value
1.3.2 Protocol Adapters and Connectors The MBean Server depends on the protocol adapter and connector to communicate with management applications outside the Java virtual machine running the agent. The protocol adapter provides a view of the management component registered in the MBean server through a specific protocol. For example, an HTML adapter can display all registered management components on a web page. Different protocols offer different views.
The connector must also provide an interface to a part of the application to communicate the agent and management applications, ie directed different protocols, the connector must provide the same remote interface to encapsulate the communication process. When the remote application uses this interface, you can interact through the network transparent and proxy, and ignore the protocol itself.
Adapters and connectors make MBean servers to communicate with the management application. Therefore, an agent is to be managed, which must provide at least one protocol adapter or connector. When facing a variety of management applications, the agent can contain a variety of different protocol adapters and connector.
The protocol adapter and connector currently implemented and will be implemented include:
1) RMI connector
2) SNMP protocol adapter
3) IIOP protocol adapter
4) HTML protocol adapter
5) HTTP connector
1.3.3 Agent Service Agent Service You can perform management functions for registered management components. By introducing intelligent management, JMX can help us build a strong management solution. The proxy service itself is also present as a management component or is also controlled by the MBean server. The JMX specification defines the proxy service:
1) Dynamic Class Loading - A new class can be obtained by managing applet services, which can also localize the class libraries located on the network.
2) Monitoring Service - Monitor the property value change of the management component, and notify these changes to all listeners.
3) Time Service - Timed a message or as a scheduler.
4) Relationship services - definition and maintain the interrelationship between management components.
Dynamic class loading
Dynamic class load is implemented by the M-LET (Management Applet) service, which can be downloaded and instantiated from any URL on the network, and then register with the MBean server. In a M-LET service, first is to download a m-let text file, the file is a file in the XML format, the contents of the file identifies all information of the management component, such as the component name, uniquely identifying the component in the MBean server. The object name, etc. Then according to the content of this file, the M-Let service completes the remaining tasks. The following figure illustrates this process:
2. Monitoring services
By using a monitoring service, the attribute value of the management component is regularly monitored, ensuring that it is always in a specific range. When the changes in the attribute value of the monitored exceeds the expected definition, a particular notice will be issued. The JMX specification currently specifies three monitors:
1) The counter monitor, monitor the attribute value of the counter type, is usually integrated, and can only be incremented by certain regulations.
2) Metrical monitor, monitor the attribute value of the metric type, usually the real number, the value can be increased.
3) String Monitor, monitor the properties of the string type.
Each monitors are existing as a standard management component, and when providing services, each monitor is required, and can be dynamically created and configured by the corresponding management component or remote management application.
The following figure illustrates the usage of the counter monitor:
3. Time service
Time services can issue notices in the formulated time and date, or may issue a regular periodic issue of notice, depending on the configuration of the management application. Time service is also a management component that helps the management application to establish a configurable memo to achieve intelligent management services.
4. Relationship services
The JMX specification defines the relationship model between management components. One relationship is the N-dimensional system between the user-defined management component.
Relationship model defines some of the following terms:
1) Role: It is a member identity in a relationship, which contains a role value.
2) Role information: Describe a role in a relationship.
3) Relationship type: Composed of role information, as a template for the creation and maintenance relationship.
4) Relationship: The current contact between management components must meet a relationship type requirement.
5) Role value: The list of management components that are currently able to give a given role in a relationship.
6) Relationship services: It is a management component that can contact and maintain consistency between all relationship types and relationship instances.
In the relational service, the relationship between management components is maintained by a relationship example determined by the relationship type. Only the management components that are registered on the MBean server and can be identified by the object name can be a member of a relationship. Relationship services have never manipulated its members - management components, in order to facilitate finding it only provides an object name.
Relationship services can lock unreasonable relationship types, the same, the creation of unreasonable relationships will also be locked. The amendment to the role value must also follow the consistency check.
Since the relationship is a connection between the registered management components, the relationship is changed when the management component is uninstalled. Relationship services automatically change the role value. All operations such as creation, update, deletion, such as creation, update, deletion, etc., the notice provides information about this operation. The JMX relationship model can only guarantee that all management components meet its design roles, that is, a management component is not allowed to occur in many relationships simultaneously.
1.4 Distribution Service Layer Currently, Sun does not give the specific specification of this layer, which is just a brief description.
This layer specifies the interface to implement the JMX application management platform. This layer defines management interfaces and components that can operate on the proxy layer. These components can:
1) Provide an interface for the management application so that it can interact with the agent layer or JMX management resource via a connector.
2) A view of JMX proxy and all manageable components through a variety of protocols (such as SNMP, HTML, etc.).
3) Distribute management information to construct a distributed system, which is to publish the management information of the high-level management platform to the many JMX agents.
4) Collect the management information of multiple JMX proxy and use the information that users who need to use the user's interested information and form a logical view to the corresponding end user.
5) Provide security guarantees.
By managing application layers and another management agent, and the joint of his equipment layer, you can provide us with a complete network management solution. This solution has brought us a unique advantage: lightweight, deployment, dynamic service, and security as needed.
1.5 Additional Management Protocol API This layer provides some API to support some of the currently existing management protocols.
These additional protocol APIs do not define the functionality of management applications, or the management platform architecture, only defined standard Java APIs and existing network management technology communications, such as SNMP.
Developers from network management platforms and applications can use these APIs to interact with their management environment and package this interaction process in a JMX management resource. For example, a switch running a SNMP agent can be managed by SNMP and packages these management interfaces into a management component. In dynamic network management, these management components can be replaced at any time to adapt to demand.
These APIs can help group developers deploy their management platforms and applications based on the most common industrial standards. The new network management solutions can be integrated with the existing infrastructure, so that existing network management can also use Java technology-based network management applications.
These APIs are currently developed as a stand-alone JSR (Java Specification Request) in JAVA Community Process.
They include:
1) SNMP Manager API
2) CIM / WBEM Manager and Protocol API
1.6 JMX Current Implementation and Application Since Sun releases JMX specification, many large companies have actually active norms or achieve corresponding JMX-based network management systems, and the current main implementation and application are listed below:
1) Sun made a corresponding reference implementation for JMX specification, and developed a new product JDMK (Java Dynamic Management Toolset) for network management, which defines the development process and method of resources, and dynamics. The implementation of JMX Agent, the implementation of remote management applications. At the same time, JDMK also provides a complete architecture to construct a distributed network management system, and provides a variety of protocol adapters and connectors, such as SNMP protocol adapters, HTML protocol adapters, HTTP connectors, RMI connectors.
2) IBM Tivoli implements JMX specification products for Tivolijmx, which provides architectures, design patterns, some API sets, and services for Java management applications and networks.
3) ADVENT development About JMX's products for AdventNet Agent Toolkit, which makes the new SNMP MIB, develop JMX and Java SNMP Agent process automation. 4) J2EE application servers implemented by JBoss use JMX as the micro core, and each module provides corresponding services in the form of management components.
5) The BEA's WebLogic Application Server also uses JMX technology as its own management basis.
6) Kingdee's APUSIC is also a J2EE application server developed by JMX as a kernel.
1.7 Summary This article details the JMX specification. The JMX architecture is divided into four layers, namely equipment layer, agent layer, distributed service layer, and additional protocol API. But Sun currently only realizes the specific specifications of the first two layers, and the rest of the specification is still in the formulation. JMX proxy and remote applications are communicating, requiring at least one connector and protocol adapter.
