This provides a highly desirable management integration, as many IT operations departments want to be able to monitor the health of their computers, networks, application servers, and any applications that depend on them from the same console and using the same familiar tools.

The OVO WebLogic Server SPI uses the JMX MBean server within the WebLogic Server runtime and derives some of its information from the MBeans present in that server. The HP SPI may be used by developers in three ways:

Look at the OVO Metrics Guide for the full set of OpenView-supplied metrics. These provide a comprehensive view of the internal operation of the WebLogic Server, adding the cross-correlation of items supplied by the base MBeans.

User-Defined Metrics in HP OpenView Operations
Application developers can, if necessary, add their own metrics using the features of the OVO console. By defining their own metrics, developers help the operator to monitor the applications by allowing new combinations of data to be derived from existing sources. These user-defined metrics are fully described in the HP OVO Administrator's Guide.

Writing Custom, Application-Specific MBeans
The JMX features previously described leave the software designer with the problem of deciding which application objects are in need of management visibility and which are not. Should all business objects be capable of being manipulated through their aassociated MBean, or just a chosen few?

The software designer has the option of mapping one MBean to one or to many business objects, depending on the need for management of them.

If one business object depends completely on another to get the work done (i.e., they are in a "uses" relationship), then there is an argument for managing them using one MBean. Correspondingly, if objects are entirely independent of each other in the business context, the designer can choose to have a management view of each one, using separate MBeans.

It is unlikely that all objects in any system will need a dedicated MBean of their own. The software designer chooses the Java object or EJB that he or she wishes to visualize and control using a management tool. The rules described above regarding conforming to certain interfaces or building a separate MBean object are then applied. Finally, the developer will register the new MBean with the appropriate MBean server process. In the case of the developer using WebLogic Server, that server is the BEA-supplied MBean server.

From that point onward, the MBean is manageable using JMX-aware tools. The associated business object is manageable to the degree that its behavior is detemined by its guardian MBean. Developers may find that the WebLogic-supplied MBeans are suitable for their management needs. However, there are situations where each object as an independent unit of management is not enough. For example, if I need to know how many users have abandoned their ShoppingCart objects and how many have not, then I may need to create an aggregation MBean that counts the number of relevant associations and allows this number to be seen at the management level.

Second, I may wish to have a listener MBean, for example, whose job it is to watch for users abandoning their ShoppingCart objects without taking them to the checkout phase. This is a custom MBean that I will need to register in my own application code with the MBean server and thus expose it to the tools.

Summary
The HP OpenView Smart Plug-in technology provides management of the J2EE application server's internal objects without the application developer having to do extra coding work. Using the OpenView SPI to extend the metrics it supplies to the operator also gives us a powerful tool for manageability of our application.

Tracking in a J2EE Application with OpenView Transaction Analyzer
Many developers are concerned with finding the bottlenecks that inhibit high performance in their J2EE applications. This is not an easy task due to the distributed nature of these applications. Developers have found, in many cases, that instrumenting their application with calls that conform to the Application Response Measurement (ARM) API is more intrusive on their applications than they wish to be. This API is designed to allow for detailed accounting of CPU time spent in sections of the application. It is in use in some designs for close monitoring of the processor time spent in certain key areas of a program.

There are now tools on the market, such as the OpenView Transaction Analyzer (OVTA), that use ARM measurement and logging techniques without needing the application developer to make program changes. By exploiting purpose-built class loaders and byte code manipulation, these tools can intercept the entry and exit points from each method in an application, whether that method is in a JSP, servlet, or EJB, and report the time it consumes through ARM calls. The latter calls log data to a separate measurement server that collects the logs for subsequent processing and display without further interference on the application. The ARM API is therefore completely hidden from the application developer and is built into the tool. The degree of accuracy provided by ARM is maintained.

This is a very powerful method for analyzing the full J2EE application at development time, or even later at deployment time, for performance bottlenecks. The application developer has to make no changes to code to carry this process out. Figure 3 provides a snapshot of the type of screen that HP's OVTA product produces to aid the developer in performance analysis. It can trace quickly down to the point of the problem in a complex application.

In Figure 3, highlighted in red is the key culprit for performance concerns with this particular application. This tool fulfills the final requirement for the application developer in building manageability into an application, that of tracking the paths through the code.

Conclusion
This article discussed a number of technologies and standards for enabling the manageability aspects of a J2EE or Web services application. Different technologies have benefits based on the nature of the application they are managing and the environment in which they are set.

The lowest level is that of application logging. Applications that already have some logging built in can benefit from this approach without change. This provides a base level of monitoring in the manageability hierarchy.

For those applications that are built on Java and J2EE and adhere to the standards in those fields, JMX poses an attractive choice. JMX and SNMP-style management are not mutually exclusive - JMX agents can generate events that are SNMP compatible.

Many applications will require a combination of two or more of the technologies surveyed here to fully satisfy their operational management needs. The technologies are not competing with each other for the application programmer's attention. Instead, they should be regarded as a spectrum-of-choice of levels of sophistication in manageability.

Developers should always consider the functionality implemented by the management platform that will be used by the operations staff, before proceeding to instrument their application code with these technologies. Some management platforms provide many of the features required without resorting to extra coding work.

References