Contained WithinFind More DocumentationFeatured Support Resources | Download this book in PDF (1891 KB)
Part I Instrumentation Using MBeansGiven a resource in the Java programming language—either an application, a service or an object representing a device—its instrumentation is the way that you expose its management interface. The management interface is the set of attributes and operations that are visible to managers that need to interact with that resource. Therefore, instrumenting a resource makes it manageable. This part covers the four ways to instrument a resource:
When you write a standard MBean, you follow certain design patterns so that the method names in your object expose the attributes and operations to static introspection. Dynamic MBeans implement a generic interface and can expose a rich description of their management interface. Model MBeans are MBean templates whose management interface and resource target are defined at runtime. Open MBeans are managed objects that refer only to a limited and predefined set of data types, that can be combined into compound types such as tables. Chapter 1 Standard MBeansA standard MBean is the simplest and fastest way to instrument a resource from scratch: Attributes and operations are simply methods which follow certain design patterns. A standard MBean is composed of the MBean interface which lists the methods for all exposed attributes and operations, and the class which implements this interface and provides the functionality of the resource. The code samples in this chapter are from the files in the StandardMBean example directory located in the main examplesDir/current (see “Directories and Classpath” in the Preface). This chapter covers the following topics:
1.1 Exposing the MBean InterfaceTo expose the MBean interface, first determine the management interface of your resource, that is the information needed to manage it. This information is expressed as attributes and operations. An attribute is a value of any type that a manager can get or set remotely. An operation is a method with any signature and any return type that the manager can invoke remotely. Note – Attributes and operations are conceptually equivalent to properties and actions on JavaBeans objects. However, their translation into Java code is entirely different to accommodate the management functionality. As specified by the Java Management Extensions (JMX) instrumentation, all attributes and operations are explicitly listed in an MBean interface. This is a Java interface that defines the full management interface of an MBean. This interface must have the same name as the class that implements it, followed by the MBean suffix. Because the interface and its implementation are usually in different files, two files make up a standard MBean. For example, the class SimpleStandard (in the file SimpleStandard.java) has its management interface defined in the interface SimpleStandardMBean (in the file SimpleStandardMBean.java). Example 1–1 SimpleStandardMBean Interface
Only public methods in the MBean interface are taken into consideration for the management interface. When present, non-public methods should be grouped separately, to make the code clearer for human readers. 1.1.1 MBean AttributesAttributes are conceptual variables that are exposed for management through getter and setter methods in the MBean interface:
Attribute types can be arrays of objects, but individual array elements cannot be accessed individually through the getters and setters. Use operations to access the array elements, as described in the next section. The following code example demonstrates an attribute with an array type: public String[] getMessages(); public void setMessages(String[] msgArray); The name of the attribute is the literal part of the method name following get, is, or set. This name is case sensitive in all Java Dynamic Management Kit (Java DMK) objects that manipulate attribute names. Using these patterns, we can determine the attributes exposed in Example 1–1:
The specification of the design patterns for attributes implies the following rules:
1.1.2 MBean OperationsOperations are methods that management applications can call remotely on a resource. They can be defined with any number of parameters of any type and can return any type. The design patterns for operations are simple. Any public method defined in the MBean interface that is not an attribute getter or setter is an operation. For this reason, getters and setters are usually declared first in the Java code, so that all operations are grouped afterwards. The name of an operation is the name of the corresponding method. The SimpleStandardMBean in Example 1–1 defines one operation, reset, which takes no parameters and returns nothing. While the following methods define valid operations (and not attributes), to avoid confusion with attributes, these types of names should not be used: public void getFoo(); public Integer getBar(Float p); public void setFoo(Integer one, Integer two); public String isReady(); For performance reasons, you might want to define operations for accessing individual elements of an array type attribute. In this case, use unambiguous operation names: public String singleGetMessage(int index); public void singleSetMessage(int index, String msg); Note – The Java DMK imposes no restrictions on attribute types, operation attribute types, and operation return types. However, the developer must ensure that the corresponding classes are available to all applications manipulating these objects, and that they are compatible with the type of communication used. For example, attribute and operation types must be serializable to be manipulated remotely using the remote method invocation (RMI) or JMX messaging protocol (JMXMP) protocols. 1.2 Implementing an MBeanThe second part of an MBean is the class that implements the MBean interface. This class encodes the expected behavior of the manageable resource in its implementation of the attribute and operation methods. The resource does not need to reside entirely in this class. The MBean implementation can rely on other objects. If the MBean must be instantiated remotely, it must be a concrete class and must expose at least one public constructor so that any other class can create an instance. Otherwise, the developer is free to implement the management interface in any way, provided that the object has the expected behavior. Here is the sample code that implements our MBean interface. Example 1–2 SimpleStandard Class
As in this example, attributes are usually implemented as internal variables whose value is returned or modified by the getter and setter methods. However, an MBean can implement any access and storage scheme to fit particular management needs, provided getters and setters retain their read and write semantics. Methods in the MBean implementation can have side-effects, but it is up to you to ensure that these are safe and coherent within the full management solution. We also see here that by calling the MBeanNotificationInfo class, the MBean can send notifications of different types. In this case, the MBean sends notifications about changes in its attributes when the reset() method is called. As we will see later, management applications never have a direct handle on an MBean. They only have an identification of an instance and the knowledge of the management interface. In this case, the mechanism for exposing attributes through methods in the MBean interface makes it impossible for an application to access the MBean directly. Internal variables and methods, and even public ones, are totally encapsulated and their access is controlled by the programmer through the implementation of the MBean interface. 1.3 Running the Standard MBean ExampleThe examplesDir/StandardMBean directory contains the SimpleStandard.java and SimpleStandardMBean.java files which make up the MBean. This directory also contains a simple agent application which instantiates this MBean, introspects its management interface, and manipulates its attributes and operations. To Run the Standard MBean Example
We will examine how agents work in Chapter 2, Dynamic MBeans, but this example demonstrates how the MBean interface limits the view of what the MBean exposes for management. Roughly, the agent introspects the MBean interface at runtime to determine what attributes and operations are available. You then see the result of calling the getters, setters, and operations. Part II also covers the topics of object names and exceptions which you see when running this example. Chapter 2 Dynamic MBeansA dynamic MBean implements its management interface programmatically, instead of through static method names. To do this, it relies on metadata classes that represent the attributes and operations exposed for management. Management applications then call generic getters and setters whose implementation must resolve the attribute or operation name to its intended behavior. One advantage of this instrumentation is that you can use it to make an existing resource manageable quickly. The implementation of the DynamicMBean interface provides an instrumentation wrapper for an existing resource. Another advantage is that the metadata classes for the management interface can provide human-readable descriptions of the attributes, operations, and the MBean itself. This information could be displayed to a user on a management console to describe how to interact with this particular resource. The code samples in this chapter are from the files in the DynamicMBean example directory located in the main examplesDir/current directory (see “Directories and Classpath” in the Preface). This chapter covers the following topics:
2.1 Exposing the Management InterfaceIn the standard MBean, attributes and operations are exposed statically in the names of methods in the MBean interface. Dynamic MBeans all share the same interface that defines generic methods to access attributes and operations. Because the management interface is no longer visible through introspection, dynamic MBeans must also provide a description of their attributes and operations explicitly. 2.1.1 DynamicMBean InterfaceThe DynamicMBean class is a Java interface defined by the Java Management Extensions (JMX) specification. It specifies the methods that a resource implemented as a dynamic MBean must provide to expose its management interface. Example 2–1 shows the uncommented code for the DynamicMBean interface. Example 2–1 The DynamicMBean Interface
The getMBeanInfo method provides a description of the MBean's management interface. This method returns an dMBeanInfo object that contains the metadata information about attributes and operations. The attribute getters and setters are generic, since they take the name of the attribute that needs to be read or written. For convenience, dynamic MBeans must also define bulk getters and setters to operate on any number of attributes at once. These methods use the Attribute and AttributeList classes to represent attribute name-value pairs and lists of name-value pairs, respectively. Because the names of the attributes are not revealed until runtime, the getters and setters are necessarily generic. In the same way, the invoke method takes the name of an operation and its signature, in order to invoke any method that might be exposed. As a consequence of implementing generic getters, setters, and invokers, the code for a dynamic MBean is more complex than for a standard MBean. For example, instead of calling a specific getter by name, the generic getter must verify the attribute name and then encode the functionality to read each of the possible attributes. 2.1.2 MBean Metadata ClassesA dynamic MBean has the burden of building the description of its own management interface. The JMX specification defines the Java objects used to completely describe the management interface of an MBean. Dynamic MBeans use these objects to provide a complete self description as returned by the getMBeanInfo method. Agents also use these classes to describe a standard MBean after it has been introspected. As a group, these classes are referred to as the MBean metadata classes because they provide information about the MBean. This information includes the attributes and operations of the management interface, also the list of constructors for the MBean class, and the notifications that the MBean might send. Notifications are event messages that are defined by the JMX architecture. See Chapter 8, Notification Mechanism. Each element is described by its metadata object containing its name, a description string, and its characteristics. For example, an attribute has a type and is readable and/or writable. Table 2–1 lists all MBean metadata classes. Table 2–1 MBean Metadata Classes
2.2 Implementing a Dynamic MBeanA dynamic MBean consists of a class that implements the DynamicMBean interface coherently. By this, we mean a class that exposes a management interface whose description matches the attributes and operations that are accessible through the generic getters, setters and invokers. A dynamic MBean class can declare any number of public or private methods and variables. None of these are visible to management applications. Only the methods implementing the DynamicMBean interface are exposed for management. A dynamic MBean can also rely on other classes that might be a part of the manageable resource. 2.2.1 Dynamic Programming IssuesAn MBean is a manageable resource that exposes a specific management interface. The name dynamic MBean refers to the fact that the interface is revealed at runtime, instead of through the introspection of static class names. The term dynamic is not meant to imply that the MBean can dynamically change its management interface. 2.2.2 getMBeanInfo MethodBecause the MBean description should never change, it is usually created one time only at instantiation, and the getMBeanInfo method simply returns its reference at every call. The MBean constructor should therefore build the MBeanInfo object from the MBean metadata classes such that it accurately describes the management interface. And since most dynamic MBeans will always be instantiated with the same management interface, building the MBeanInfo object is fairly straightforward. Example 2–2 shows how the SimpleDynamic MBean defines its management interface, as built at instantiation and returned by its getMBeanInfo method. Example 2–2 Implementation of the getMBeanInfo Method
2.2.3 Generic Attribute Getters and SettersGeneric getters and setters take a parameter that indicates the name of the attribute to read or write. There are two issues to keep in mind when implementing these methods:
The getAttribute method is the simplest, since only the attribute name must be verified. Example 2–3 Implementation of the getAttribute Method
The setAttribute method is more complicated, since you must also ensure that the given type can be assigned to the attribute and handle the special case for a null value. Example 2–4 Implementation of the setAttribute Method
Notice that if a change in your management solution requires you to change your management interface, it will be harder to do with a dynamic MBean. In a standard MBean, each attribute and operation is a separate method, so unchanged attributes are unaffected. In a dynamic MBean, you must modify the generic methods that encode all attributes. 2.2.4 Bulk Getters and SettersThe DynamicMBean interface includes bulk getter and setter methods for reading or writing more than one attribute at once. These methods rely on the classes shown in Table 2–2. Table 2–2 Bulk Getter and Setter Classes
The AttributeList class extends the java.util.ArrayList class. The bulk getter and setter methods usually rely on the generic getter and setter, respectively. This makes them independent of the management interface, which can simplify certain modifications. In this case, their implementation consists mostly of error checking on the list of attributes. However, all bulk getters and setters must be implemented so that an error on any one attribute does not interrupt or invalidate the bulk operation on the other attributes. If an attribute cannot be read, then its name-value pair is not included in the list of results. If an attribute cannot be written, it will not be copied to the returned list of successful set operations. As a result, if there are any errors, the lists returned by bulk operators will not have the same length as the array or list passed to them. In any case, the bulk operators do not guarantee that their returned lists have the same ordering of attributes as the input array or list. The SimpleDynamic MBean shows one way of implementing the bulk getter and setter methods. Example 2–5 Implementation of the Bulk Getter and Setter Methods
2.2.5 Generic Operation InvokerA dynamic MBean must implement the invoke method so that operations in the management interface can be called. This method requires the same considerations as the generic getter and setter:
The implementation in the SimpleDynamic MBean is relatively simple due to the one operation with no parameters. Example 2–6 Implementation of the invoke Method
As it is written, the SimpleDynamic MBean correctly provides a description of its management interface and implements its attributes and operations. However, this example demonstrates the need for a strict coherence between what is exposed by the getMBeanInfo method and what can be accessed through the generic getters, setters, and invoker. A dynamic MBean whose getMBeanInfo method describes an attribute or operation that cannot be accessed is not compliant with the JMX specification and is technically not a manageable resource. Similarly, a class could make attributes or operations accessible without describing them in the returned MBeanInfo object. Since MBeans should raise an exception when an undefined attribute or operation is accessed, this would, again, technically not be a compliant resource. 2.3 Running the Dynamic MBean ExampleThe examplesDir/current/DynamicMBean directory contains the SimpleDynamic.java file that makes up the MBean. The DynamicMBean interface is defined in the javax.management package provided in the runtime JAR file (jmx.jar) of the Java Dynamic Management Kit (Java DMK). This directory also contains a simple agent application that instantiates this MBean, calls its getMBeanInfo method to get its management interface, and manipulates its attributes and operations. To Run the Dynamic MBean Example
This example demonstrates how the management interface encoded in the getMBeanInfo method is made visible in the agent application. We can then see the result of calling the generic getters and setters and the invoke method. Finally, the code for filtering attribute and operation errors is exercised, and we see the exceptions from the code samples as they are raised at runtime. 2.3.1 Comparison With the SimpleStandard ExampleNow that we have implemented both the standard and dynamic types of MBeans, we can compare how they are managed. We intentionally created a dynamic MBean and a standard MBean with the same management interface so that we can do exactly the same operations on them. On the Solaris platform, we can compare the relevant code of the two agent applications with the diff utility (your output might vary):
If the two agent classes had the same name, the only programmatic difference would be the following:
We can see that the only difference between the two example agents handling different types of MBeans is the name of the MBean class that is instantiated. In other words, standard and dynamic MBeans are indistinguishable from the agent's point of view. The JMX architecture enables managers to interact with the attributes and operations of a manageable resource, and the specification of the agent hides any implementation differences between MBeans. Because we know that the two MBeans are being managed identically, we can also compare their runtime behavior. In doing so, we can draw two conclusions:
2.3.2 Dynamic MBean Execution TimeIn the introduction to this chapter we presented two structural advantages of dynamic MBeans, namely the ability to wrap existing code to make it manageable and the ability to provide a self-description of the MBean and its features. Another advantage is that using dynamic MBeans can lead to faster overall execution time. The performance gain depends on the nature of the MBean and how it is managed in the agent. For example, the SimpleDynamic MBean, as it is used, is probably not measurably faster than the SimpleStandard example in Chapter 1, Standard MBeans. When seeking improved performance, there are two situations that must be considered:
Because the dynamic MBean provides its own description, the agent does not need to introspect it as it would a standard MBean. Since introspection is done only once by the agent, this is a one-time performance gain during the lifetime of the MBean. In an environment where there are many MBean creations and where MBeans have a short lifetime, a slight performance increase can be measured. However, the largest performance gain is in the management operations, when calling the getters, setters and invoker. As we shall see in Part II, the agent makes MBeans manageable through generic getters, setters, and invokers. In the case of standard MBeans, the agent must do the computations for resolving attribute and operation names according to the design patterns. Because dynamic MBeans necessarily expose the same generic methods, these are called directly by the agent. When a dynamic MBean has a simple management interface requiring simple programming logic in its generic methods, its implementation can show a better performance than the same functionality in a standard MBean. Chapter 3 Model MBeansA model MBean is a generic, configurable MBean that applications can use to instrument any resource dynamically. It is a dynamic MBean that has been implemented so that its management interface and its actual resource can be set programmatically. This enables any manager connected to a Java dynamic management agent to instantiate and configure a model MBean dynamically. Model MBeans enable management applications to make resources manageable at runtime. The managing application must provide a compliant management interface for the model MBean to expose. It must also specify the target objects that actually implement the resource. Once it is configured, the model MBean passes any management requests to the target objects and handles the result. In addition, the model MBean provides a set of mechanisms for how management requests and their results are handled. For example, caching can be performed on attribute values. The management interface of a model MBean is augmented by descriptors that contain attributes for controlling these mechanisms. The code samples in this chapter are taken from the files in the ModelMBean example directory in the main examplesDir/current directory (see “Directories and Classpath” in the Preface). This chapter covers the following topics:
3.1 RequiredModelMBean ClassThe required model MBean is mandated by the Java Management Extensions (JMX) specification for all compliant implementations. It is a dynamic MBean that lacks any predefined management interface. It contains a generic implementation that transmits management requests on its management interface to the target objects that define its managed resource. The name of the required model MBean class is the same for all JMX-compliant implementations. Its full package and class name is javax.management.modelmbean.RequiredModelMBean. By instantiating this class, any application can use model MBeans. In order to be useful, the instance of the required model MBean must be given a management interface and the target object of the management resource. In addition, the model MBean metadata must contain descriptors for configuring how the model MBean will respond to management requests. We will cover these steps in subsequent sections. The MBean server does not make any special distinction for model MBeans. Internally they are treated as the dynamic MBeans that they are, and all of the model MBean's internal mechanisms and configurations are completely transparent to a management application. Like all other managed resources in the MBean server, the resources available through the model MBean can only be accessed through the attributes and operations defined in the management interface. 3.2 Model MBean MetadataThe metadata of an MBean is the description of its management interface. The metadata of the model MBean is described by an instance of the ModelMBeanInfo class, which extends the MBeanInfo class. Like all other MBeans, the metadata of a model MBean contains the list of attributes, operations, constructors, and notifications of the management interface. Model MBeans also describe their target object and their policies for accessing the target object. This information is contained in an object called a descriptor, defined by the Descriptor interface and implemented in the DescriptorSupport class. There is one overall descriptor for a model MBean instance and one descriptor for each element of the management interface, that is for each attribute, operation, constructor, and notification. Descriptors are stored in the metadata object. As defined by the JMX specification, all classes for describing elements are extended so that they contain a descriptor. For example, the ModelMBeanAttributeInfo class extends the MBeanAttributeInfo class and defines the methods getDescriptor and setDescriptor. A descriptor is a set of named field and value pairs. Each type of metadata element has a defined set of fields that are mandatory, and users are free to add others. The field names reflect the policies for accessing target objects, and their values determine the behavior. For example, the descriptor of an attribute contains the fields currencyTimeLimit and lastUpdatedTimeStamp that are used by the internal caching mechanism when performing a get or set operation. In this way, model MBeans are manageable in the same way as any other MBean, but applications that are aware of model MBeans can interact with the additional features they provide. The JMX specification defines the names of all required descriptor fields for each of the metadata elements and for the overall descriptor. The field names are also described in the API documentation generated by the Javadoc tool for the ModelMBean*Info classes. In Example 3–1 , the application defines a subroutine to build all descriptors and metadata objects needed to define the management interface of the model MBean. Example 3–1 Defining Descriptors and MBeanInfo Objects
3.3 Target Object(s)The object instance that actually embodies the behavior of the managed resource is called the target object. The last step in creating a model MBean is to give the MBean skeleton and its defined management interface a reference to the target object. Thereafter, the model MBean can handle management requests, forward them to the target object, and handle the response. Example 3–2 implements the TestBean class that is the simple managed resource in our example. Its methods provide the implementation for two attributes and one operation. Example 3–2 Implementing the Managed Resource
By default, the model MBean handles a managed resource that is contained in one object instance. This target is specified through the setManagedResource method defined by the ModelMBean interface. The resource can encompass several programmatic objects because individual attributes or operations can be handled by different target objects. This behavior is configured through the optional targetObject and targetType descriptor fields of each attribute or operation. In Example 3–3, one of the operations is handled by an instance of the TestBeanFriend class. In the definition of this operation's descriptor, we set this instance as the target object. We then create the operation's ModelMBeanOperationInfo with this descriptor and add it to the list of operations in the metadata for our model MBean. Example 3–3 Setting Other Target Objects
3.4 Creating a Model MBeanTo ensure coherence in an agent application, you should define the target object of an MBean before you expose it for management. This implies that you should call the setManagedResource method before registering the model MBean in the MBean server. Example 3–4 shows how our application creates the model MBean. First it calls the subroutine given in Example 3–1 to build the descriptors and management interface of the model MBean. Then it instantiates the required model MBean class with this metadata. Finally, it creates and sets the managed resource object before registering the model MBean. Example 3–4 Setting the Default Target Object
The model MBean is now available for management operations and remote requests, just like any other registered MBean. 3.5 Running the Model MBean ExampleThe examplesDir/current/ModelMBean directory contains the TestBean.java file that is the target object of the sample model MBean. This directory also contains a simple notification listener class and the agent application, ModelAgent, which instantiates, configures, and manages a model MBean. The model MBean itself is given by the RequiredModelMBean class defined in the javax.management.modelmbean package provided in the runtime JAR file (jmx.jar) of the Java Dynamic Management Kit (Java DMK). To Run the Model MBean Example
We can then see the result of managing the resource through its exposed attributes and operations. The agent also instantiates and registers a listener object for attribute change notifications sent by the model MBean. You can see the output of this listener whenever it receives a notification, after the application has called one of the attribute setters. Chapter 4 Open MBeansOpen MBeans are dynamic MBeans, with specific constraints on their data types, that allow management applications and their human administrators to understand and use new managed objects as they are discovered at runtime. Open MBeans provide a flexible means of instrumenting resources which need to be open to a wide range of applications compliant with the Java Management Extensions (JMX) specification. To provide its own description to management applications, an open MBean must be a dynamic MBean, with the same behavior and functionality as a dynamic MBean. Thus it implements the DynamicMBean interface and no corresponding open MBean interface is required. The open functionality of open MBeans is obtained by providing descriptively rich metadata and by using exclusively certain predefined data types in the management interface. Because open MBeans build their data types from a predefined set of Java classes, a management application can manage an agent that uses open MBeans, without having to load Java classes specific to that agent. Furthermore, a JMX connector or adaptor only needs to be able to transport classes from the predefined set, not arbitrary Java classes. This means, for example, that a connector could use eXtensible Markup Language (XML) as its transport by defining an XML schema that covers the MBean server operations and the predefined open MBean data types. It also means that a management application could run in a language other than Java. The code samples in this chapter are taken from the files in the OpenMBean and OpenMBean2 example directories located in examplesDir/current (see “Directories and Classpath” in the Preface). This chapter covers the following topics:
4.1 Open MBean Data TypesOpen MBeans refer exclusively to a limited, predefined set of data types, which can be combined into compound types. 4.1.1 Supported Data TypesAll open MBean attributes, method return values, and method arguments must be limited to the set of open MBean data types listed in this section. This set is defined as: the wrapper objects that correspond to the Java primitive types (such as Integer, Long, Boolean), String, CompositeData, TabularData, and ObjectName. In addition, any array of the open MBean data types may be used in open MBeans. A special class, javax.management.openmbean.ArrayType is used to represent the definition of single or multi-dimensional arrays in open MBeans. The following list specifies all data types that are allowed as scalars or as any-dimensional arrays in open MBeans:
In addition the java.lang.Void type may be used, but only as the return type of an operation. 4.1.2 Type Descriptor ClassesOpen types are descriptor classes that describe the open MBean data types. To be able to manipulate the open MBean data types, management applications must be able to identify them. While primitive types are given by their wrapper class names, and arrays can be represented in a standard way, the complex data types need more structure than a flat string to represent their contents. Therefore open MBeans rely on description classes for all the open MBean data types, including special structures for describing complex data. The abstract OpenType class is the superclass for the following specialized open type classes:
The CompositeType, TabularType, and ArrayType classes are recursive, that is, they can contain instances of other open types. 4.2 Open Data InstancesAll of the wrapper classes for the primitive types are defined and implemented in all Java virtual machines, as is java.lang.String. The ObjectName class is provided by the implementation of the JMX specification. You can use the CompositeData and TabularData interfaces to define aggregates of the open MBean data types and provide a mechanism for expressing complex data objects in a consistent manner. All open data instances corresponding to the open MBean types defined in 4.1.1 Supported Data Types, except CompositeData and TabularData instances, are available through the classes of the Java 2 Platform, Standard Edition (J2SE) or JMX specification. 4.2.1 CompositeData and TabularData InstancesThe CompositeData and TabularData interfaces represent complex data types. The JMX specification now includes a default implementation of these interfaces, using the CompositeDataSupport and TabularDataSupport classes respectively. The CompositeData and TabularData interfaces and implementations provide some semantic structure to build aggregates from the open MBean data types. An implementation of the CompositeData interface is equivalent to a map with a predefined list of keys: values are retrieved by giving the name of the desired data item. Other terms commonly used for this sort of data type are record or struct. An instance of a TabularData object contains a set of CompositeData instances. Each CompositeData instance in a TabularData instance is indexed by a unique key derived from its values, as described in 4.2.1.2 TabularDataSupport Class. A CompositeData object is immutable once instantiated: you cannot add an item to it and you cannot change the value of an existing item. TabularData instances are modifiable: rows can be added or removed from existing instances. 4.2.1.1 CompositeDataSupport ClassA CompositeData object associates string keys with the values of each data item. The CompositeDataSupport class defines an immutable map with an arbitrary number of entries, called data items, which can be of any type. To comply with the design patterns for open MBeans, all data items must have a type among the set of open MBean data types, including other CompositeData types. When instantiating the CompositeDataSupport class, you must provide the description of the composite data object in a CompositeType object (see 4.1.2 Type Descriptor Classes). All the items provided through the constructor must match this description. Because the composite object is immutable, all items must be provided at instantiation time, and therefore the constructor can verify that the items match the description. The getOpenType method returns this description so that other objects which interact with a CompositeData object can know its structure. 4.2.1.2 TabularDataSupport ClassThe TabularDataSupport class defines a table structure with an arbitrary number of rows which can be indexed by any number of columns. Each row is a CompositeData object, and all rows must have the same composite data description. The columns of the table are headed by the names of the data items which make up the uniform CompositeData rows. The constructor and the methods for adding rows verify that all rows are described by equal CompositeData instances. The index consists of a subset of the data items in the common composite data structure. This subset must be a key which uniquely identifies each row of the table. When the table is instantiated, or when a row is added, the methods of this class ensure that the index can uniquely identify all rows. Often the index will be a single column, for instance a column containing unique strings or integers. Both the composite data description of all rows and the list of items which form the index are given by the table description returned by the getOpenType method. This method defined in the TabularData interface returns the TabularType object which describes the table (see 4.1.2 Type Descriptor Classes). The access methods of the TabularData class take an array of objects representing a key value which indexes one row and returns the CompositeData instance which makes up the designated row. A row of the table can also be removed by providing its key value. All rows of the table can also be retrieved in an enumeration. 4.3 Open MBean Metadata ClassesTo distinguish open MBeans from other MBeans, the JMX specification provides a set of metadata classes which are used specifically to describe open MBeans. The following interfaces in the javax.management.openmbean package define the management interface of an open MBean:
For each of these interfaces, a support class provides an implementation. Each of these classes describes a category of components in an open MBean. However, open MBeans do not have a specific metadata object for notifications; they use the MBeanNotificationInfo class. Open MBeans provide a universal means of exchanging management functionality and consequently their description must be explicit enough for any user to understand. All of the OpenMBean*Info metadata classes inherit the getDescription method which should return a non-empty string. Each component of an open MBean must use this method to provide descriptions that are suitable for displaying in a graphical user interface. Only the OpenMBeanOperationInfo specifies the getImpact method. Instances of OpenMBeanOperationInfo.getImpact must return one of the following constant values:
The value UNKNOWN cannot be used. 4.4 Running the Open MBean ExamplesThe examples directory provides two examples that demonstrate how to implement and manage an open MBean. 4.4.1 Open MBean Example 1In the first open MBean example, we implement an open MBean and manage it through a simple JMX agent application. We develop a sample open MBean that uses some of the open data types and correctly exposes its management interface at runtime through the OpenMBean*Info classes. We then develop a simple JMX agent for exercising the open MBean, which involves:
The examplesDir/current/OpenMBean directory contains the SampleOpenMBean.java file, which is an open MBean, and the OpenAgent.java file which is a simple JMX agent used to interact with the open MBean. To Run Open MBean Example 1
4.4.2 Open MBean Example 2In the second open MBean example, we implement an open MBean and manage it through a simple JMX manager application. Although it is helpful to run the first open MBean example before this example, it is not obligatory. We develop a sample open MBean that uses some of the open data types and correctly exposes its management interface at runtime through the OpenMBean*Info classes. See the CarOpenMBean.html file in the examplesDir/current/OpenMBean2/docs directory for more detailed information on the data structure of this example. We then develop a simple manager for exercising the open MBean, which involves:
The examplesDir/current/OpenMBean2 directory contains the following source files:
To Run Open MBean Example 2
|
||||||||||||||||||||||||||||||||||||||||||||||||