9.4 Best Practices
| Not all of the lessons we have learned with JMX are easily classified in the lifecycle of an MBean or MBeanServer. This section contains the miscellaneous advice we wanted to present to you, so the subsections here are independent of each other. 9.4.1 MBean GranularityAn MBean should be created to represent a functional component of your application. You should not end up with one MBean per component or class in your application, unless your components are very coarse-grained. When looking at your application and trying to decide how many MBeans you need for which components and classes, resist the temptation to create an MBean for each component. Step back and look at your application from a functional view, remembering that MBeans can manage across components. Ask yourself what those who are managing this application while it is running will want to manage, check the status of, and reconfigure. What would they say the functional areas of your application are? Let's look at our tack catalog example. In the tack catalog we had an item, category and catalog, but we developed manageability only for the catalog. Now let's expand the tack catalog for online shopping (remember this is a fictitious and simple example) and see how we chose which components to manage. Now we have the following functions that we need to provide to customers:
We have seen an example of a catalog application having the following business operations: public interface Catalog { public Category createCategory(String name) throws CategoryExistsException; public Category getCategory(String name); public Map getCategories(); public void removeCategory(Category category) throws NoSuchCategoryException; public void removeCategory(String name) throws NoSuchCategoryException public void classify(Item item, Category category); public void declassify(Item item, Category category); public void increaseInventory(Item item, int amount); public void decreaseInventory(Item item, int amount) throws InventoryUnderflowException; public Item createItem(String name, int price, int quantity) throws ItemExistsException; public List getItems(); public void removeItem(Item item) throws NoSuchItemException; public void removeItem( int catalogno) throws NoSuchItemException; } Let's look at the Shopping Cart application in more detail. It could have components and methods like these:
In this case you should create MBeans for the Catalog and Shopping Cart applications. You don't really need an MBean for the Order Status Check and Shipper Status Check functions because they are managed as part of the Shopping Cart application. We've already seen the following catalog MBeanInfo :
Other information that could be part of MBeanInfo data includes some time-related attributes about response times:
You could also have operations to put the catalog online or take it offline:
And you could have notification from the catalog for events that require attention from an administration ”for example, "Item list response time exceeded maximum allowable." The Shopping Cart MBeanInfo could have similar types of information, operations, and notifications:
As these examples show, the information you are tracking for the application consists of aggregations rather than instances of carts. This information helps you determine if the application is accessible and functioning well enough to keep customers from feeling restless. This section was meant to stress that there does not need to be a direct correlation between MBeans and important objects or concepts in your application. But rather, you need to decide what the appropriate level of management granularity for your application is, in this case by catalogs and shopping carts. 9.4.2 Application Self-ManagementSelf-management means that an application's MBeans completely manage the application, requiring no third-party or enterprise management system. There are two granularities here: First, the application is accompanied by a JMX-based application-specific management application. Second, the application instantiates MBeans, monitor MBeans, and adapters to handle its management. This management can happen entirely local to a particular MBeanServer. 9.4.2.1 Application-Specific ManagerJMX was designed to be a single instrumentation able to feed both enterprise managers and application-specific managers. Most applications of any complexity will need to be accompanied by a management and administrative application. JMX can provide the necessary infrastructure. The advantages of providing an application-specific manager are that you can create a much more intuitive and detailed presentation to the administrator and you can provide much more detailed configuration and recovery support. It is not uncommon for some of the MBeans' attributes to be managed exclusively by the application-specific manager. A subset, often the more coarse-grained or aggregated data, is exposed to enterprise managers. If the management application is running in the same JVM, you don't even need an adapter to interact with the MBeanServer. If the management system is running in a separate JVM, you will need at least a simple RMI or HTTP adapter to communicate with the remote MBeanServer. If you write your own application-specific manager, you should consider providing the following functionality:
Of course, you can pick any subset of this functionality as well, depending on your application, its criticality, its complexity, and how much you like writing management applications. 9.4.2.2 Local Monitoring and RecoveryEvery JMX MBeanServer supports monitoring, timers, and notifications. This means that every MBeanServer is capable of monitoring its local applications and responding to notifications. If you are going to use local monitoring, you can instantiate monitor MBeans (see Chapter 7) to watch values of specific attributes of specific MBeans. These monitor MBeans, as well as your application-specific MBeans, may send notifications. This means that you need to have an instance of NotificationListener implemented. A notification can be another MBean; an adapter to a local manager, e-mail sender, or pager; or just a class of your choosing. The NotificationListener class that you implement can react any number of ways to a notification. It can do one or more of the following:
There is a trade-off between self-management, or local management, and enterprise management. Local management is attractive because it works regardless of the state of the network and has many fewer dependencies on other applications. Because there are fewer dependencies, there are also fewer points of failure in management and recovery. This makes the management much more reliable per failure. You can also monitor and react with a much higher frequency because you do not incur the overhead of going between JVMs on a system or over networks. The Achilles' heel here is that if the local host is failing, there may not be an external manager to recover any of it. In addition, local management actions have only local knowledge. They cannot know the state of the entire application or enterprise. It may not always be appropriate to recover a resource if other parts of the enterprise are stressed. Another issue to be aware of is double management. This is the case where there is local management, which the enterprise manager is not aware of, and enterprise management. Effectively you end up with two sets of monitors and potentially two duplicate, different, or even conflicting responses. Our advice here is to use JMX to instrument your application for your own management system as well as enterprise managers. To reduce IT resource use, perform monitoring in the local host. Automatic responses to notifications should be implemented locally only if a larger context is not required to ensure the operation is correct. To reduce redundant management, provide a means to " turn off" management functions that execute locally in favor of that responsibility being taken over and provided by an enterprise management system. Obviously there are trade-offs for each of these decisions, but these are fair guidelines. 9.4.3 Resource SchemaJMX is a model-less manageability architecture. This means that JMX does not require you to use any particular naming conventions for your attributes or operations. Nor does it provide you any standard way to represent management data. The lack of an explicit resource model makes JMX very flexible. It is possible to represent nearly any resource type and data in JMX MBeans. You do not have to try to fit your existing information into someone else's model. Nor do you have to figure out how to extend an existing model when your application doesn't fit neatly into the existing model. The downside of not having a resource model is that because there is no standard, accepted vocabulary for common management terms and relationships, every MBean may have its own variation for the same type of data. For example, a basic state variable can be named state , status , currentState , or availability . Its values can be boolean , strings as in "up/down" or "available/unavailable", or even multivalued, as in "up/degraded/failed/down". It can become very difficult for a management system to realize that all of these represent the same kind of data and they can all be normalized and used to update colors in a topology screen. It may also be hard for the system to determine how to aggregate the status to get a broader system status. This lack of consistent terminology for management systems ends up requiring custom integration of every MBean and its meanings into management systems through the JMX adapter to that management system. Sometimes this can require some custom integration in the management application itself. One of the goals of JMX was to enable the development of general-purpose management applications that can "understand" the MBeans presented to it without custom development. You can see that the lack of a common model seriously jeopardizes this goal. More than a few management data models are being developed by standards bodies ”for example, SNMP MIBs from the IETF, and CIM from the DMTF. Of these, CIM is probably the best suited as a basic model for building MBeans. CIM is a closer match to JMX in the concepts of operations, attributes, notifications and metadata. SNMP MIBs represent attributes and events well, but the operations concepts can be difficult to translate intuitively. CIM addresses the device, system, and networking disciplines very well. The models there are fairly complete, stable, and easy to extend. It is reasonably easy to figure out where your device or system belongs relative to the model. If you are developing an application or middleware, it is more difficult to use the CIM model. Although not yet complete, the models for the application are under active development. It requires quite a bit of work to understand the CIM model and understand the best way to extend it for your own purposes. Even so, we recommend that you use the CIM model as much as you can. If you cannot use the model as is, at least use the CIM vocabulary for variable names and relationships. For example, CIM uses status for status or state; if at all possible your MBeans should use status for status as well. Following this approach increases the odds that management systems will be able to understand and manage your MBean appropriately. This approach may decrease the amount of development you have to do in JMX adapters or in management applications. If you have a mismatch in terminology or names but the semantics are very close, you can use the ProtocolMap object in the model MBean descriptors (see Chapter 4) to tell the adapter to relate the attribute in the MBean to the attribute in the CIM model. If you find a CIM model that is close to your needs, it is relatively easy to generate MBeans from the model. There are tools available from Sun that generate MBeans from both CIM models and SNMP MIBs. Figure 9.11 shows a CIM UML diagram of the core model and the managed system element taken from the "Common Information Model (CIM Core ) Model, Version 2.4" white paper (available at http://www.dmtf.org/standards/documents/CIM/DSP0111.pdf). Figure 9.11. The Core Model and the Managed Element ManagedSystemElement is a basic class that most other CIM classes eventually derive from. Here is a standard-MBean interface that could be generated for ManagedSystemElement : public interface ManagedSystemElementMBean { String getName(); void setName(String newName); String GetStatus(); void SetStatus(String newStatus); DateTime getInstallDate(); void setInstallDate(String newDate); } ManagedSystemElement MBeans can be members of component and SystemComponent relationships MBeans for starters. We would represent these relationships, or CIM associations, by creating new JMX relationship MBeans. In conclusion, using CIM models as the basis for your MBeans is not a trivial effort. But it yields the following benefits: You are future-proofing your MBeans, you are increasing the odds that your MBeans will be understood by other management systems, and you may get new ideas from the CIM model to improve your management design. 9.4.4 Notifications and LoggingIt is important to recognize the difference between messages that should be logged and messages that should be notifications. If you have an existing application, it can be tempting to send a notification for every logged message, but doing so could flood your MBeanServer, adapter, and management systems with notifications that are just thrown away or merely logged again. Messages that should be logged should be logged not only to record problems and failures, but also to provide an audit trail, record the progress of transactions, and record the use of features or invocations of functions. Logged messages are used later ”usually not while the application is running ”to do problem determination, root failure analysis, usage analysis, and performance analysis. All of these analyses can be used to tune the network, system, or application to improve performance of the more highly used or critical functions. Some of these logged messages should be JMX notifications. Messages about failures or events that require automated responses or recovery, or operator action, should be JMX notifications. There are several ways that you can send messages from your application as JMX notifications. First, if your application is the MBean, you would simply implement the NotificationBroadcaster interface or extend the NotificationBroadcasterSupport class and send the notification from your application where appropriate. You would find a sendNotification() method invocation wherever you logged a critical message. Another common pattern is to instrument a logging application to send the notification. Many complex applications use special logging components or utilities. Such a utility can be modified to send a JMX notification when certain messages are being logged. Or JMX logging can be based on the severity of the message. If you have control of the code, you can modify the logging component to accept a flag to indicate if the message should be a notification or not. Some analysis tools run relatively frequently (every hour or so). If the notifications do not require a response immediately or in real time, you can build the sending of JMX notifications into these types of log analysis tools. Daily analysis tools run probably too infrequently for it to make sense to send JMX notifications from them. 9.4.5 Federation OptionsWhen you are developing distributed applications, you may need to have several MBeanServers distributed across your application. You may have one MBeanServer per JVM, host, or functional component. When you try to build your management application, or represent your application to an enterprise manager, you will need to locate and access the MBeans across all the MBeanServers. This is called MBeanServer federation. Another common scenario in which MBeanServer federation will be necessary is when you are building applications that will execute in JMX-enabled middleware, like application servers and messaging systems. The middleware will have at least one of its own MBeanServers, and you may have your own MBeanServer for your application. In fact, in an application server every application that is executing may have its own MBeanServer instance. The application server's management system will need to recognize its own MBeanServer, as well as all the guest MBeanServers and their MBeans. You will need to deal with MBeanServers designed to talk together in the distributed-application case, as well as those being absorbed unknowingly by another MBeanServer in the middleware case. Basically you have to decide what your application or manager is going to "see": one MBeanServer ”perhaps the local one ”or a whole raft of MBeanServers with well-defined relationships. In this section we will examine the single-agent view, along with several implementation models, and the multiple-agent view for implementing MBeanServer federation. 9.4.5.1 Single-Agent ViewWith a single-agent view, the application or manager interacts with one MBeanServer. Application and manager development is much easier because they don't have to find the right MBeanServer to make a request on an MBean. That MBeanServer is responsible for aggregating all of the MBeans in the MBeanServers with which it is federated. This is very convenient because the application or manager can interact with a local MBeanServer that has services and adapters to interact with other local or remote MBeanServers. The location of the federated MBeanServers does not change how the application or manager is programmed to interact with its MBeanServer. For the sake of this discussion, we will refer to the single-agent MBeanServer as the master MBeanServer. The MBeanServers that the master interacts with (and the application does not) will be referred to as subordinate MBeanServers. You can choose from several federation patterns to support a single-agent-view topology. In fact, applications and managers can't tell the difference among any of the single-agent-view implementations . In all cases they get a large list of MBeans when they invoke the MBeanServer's queryMBeans() method, and then they use the MBean name with the local MBeanServer to access the target MBean. The following list describes the single-agent-view topologies:
9.4.5.2 Multiple-Agent ViewThe multiple-agent-view approach to federation, as shown in Figure 9.15, puts the onus for aggregation on the application or manager. This approach adds complexity to the applications managers that use it. They must now deal with finding remote MBeanServers, figuring out which MBeanServer owns the MBean it wants, performing broadcasts if necessary, and aggregating the results. On the other hand, this approach requires no special adapters in subordinate MBeanServers, nor does it require a master MBeanServer that understands how to communicate with and aggregate MBeanServers. Figure 9.15. Multiple-Agent View If you decide to have your application see all the MBeanServers, you must have a well-defined mechanism to be able to find all the MBeanServers it should communicate with. This mechanism could be configured into the application, or it could be discovered during runtime. One approach would be to add a small adapter to all MBeanServers that update a simple registry as they initialize. We recommend implementing a single-agent view for federation. Which implementation option you choose depends on your requirements. If you anticipate having an enormous number of MBeanServers and MBeans, you should use the request propagation via a directory model because it is the most scalable. If you require ease of implementation, the request propagation via broadcast is the easiest to implement reliably. Request propagation via proxy is a good trade-off of performace for ease of implementation. |
EAN: 2147483647
Pages: 115